00:00:00100万トークンのコンテキストウィンドウは大きな進化に聞こえますが、実際には多くの人が認識しているよりもはるかに悪いものです。
00:00:05これこそが、Claude Codeの開発者であるTarikが記事を書いた理由です。
00:00:09Claude Codeが100万トークンになって初めて性能が落ちるとか、100万あれば心配無用だと思っているなら、それは間違いです。
00:00:17劣化はウィンドウの半分どころか、もっとずっと早い段階から始まっています。
00:00:21そして多くの人が解決策として飛びつく「圧縮」は、たいてい状況を悪化させます。
00:00:24この動画の最後には、Anthropicのチームが行っているのと同じ方法で、Claude Codeの性能低下を防ぐ方法が正確にわかります。
00:00:31モデル自体は非常に強力なのに、Claude Codeは性能が落ちたと感じることがあります。
00:00:35ハルシネーション（幻覚）が増えたり、以前出した指示を何度も繰り返す必要があったり、長い目で見ると指示を忘れてしまうことに気づいたかもしれません。
00:00:44私たちが長時間タスクを実行していた時にも、Claudeのパフォーマンスが低下したと感じました。
00:00:48しかし、それには明確な理由があります。
00:00:50Opus 4.5以降のモデルはすべて、従来の20万ではなく、100万トークンのコンテキストウィンドウを搭載しています。
00:00:56このアップグレードにより、これまでの問題のほとんどが解決したように聞こえますが、それは理論上の話に過ぎません。
00:01:03以前よりも多くの情報を一度にウィンドウに収め、ドキュメントや情報でグラウンディング（根拠付け）して、Claudeがタスクから逸脱しないようにできるようになったからです。
00:01:12100万のウィンドウがあれば、以前直面していたようなコンテキスト問題をあまり気にせず、長時間タスクを実行できる扉が開かれます。
00:01:19しかし、問題はこれらすべてが完全に解決されたわけではないということです。
00:01:22100万のコンテキストウィンドウは、実は諸刃の剣なのです。
00:01:26Claudeがより長く、より多くの情報を一度に保持できるのは確かですが、それには代償が伴います。
00:01:30「コンテキスト腐敗」の扉を開いてしまうのです。
00:01:32コンテキスト腐敗とは、ウィンドウ内の情報量が増えるにつれてモデルのパフォーマンスが低下することを意味します。コンテキストが膨れ上がると、注目すべき対象が増え、焦点が定まらなくなるからです。
00:01:42100万トークンもの容量があるとコンテキストは過密状態になり、20万の時よりもClaudeの推論を妨害する情報がはるかに多く存在することになります。
00:01:53コンテキスト腐敗は、極端に肥大化した時だけに起こるわけではありません。
00:01:57Claude Codeの作成者によると、コンテキスト腐敗は30万から40万トークンあたり、つまり容量のわずか40%程度の使用率で実際に発生し始めます。
00:02:07ですから、ウィンドウサイズに関係なく、コンテキスト腐敗を防ぐための対策が必要です。
00:02:11これを知ることで、100万のコンテキストウィンドウとの付き合い方が実際に変わるはずです。
00:02:15では、手短に復習しましょう。
00:02:16コンテキストウィンドウとは、モデルが一度に見るすべてのもので、これまでの会話、Claude.mdファイル、システムプロンプト、セッションで読み込んだファイル、すべてのツール呼び出し結果を含みます。
00:02:26プロンプトごとに情報が増え、ウィンドウがいっぱいになると、要約してウィンドウをフレッシュにするのが「圧縮」です。
00:02:32コンテキストを適切に管理しないと、エージェントが失敗する4つのパターンがあります。
00:02:37これは長期間実行するエージェントでより顕著になり、問題となります。
00:02:401つ目は先ほど議論した「コンテキスト汚染」で、これが起こる理由もそこにあります。
00:02:452つ目は「ゴールドリフト（目標の乖離）」です。
00:02:46これは、一度に集中すべきことが多すぎるためにエージェントが本来の目的から外れてしまう、簡単に言えば、取り組むべきゴールを忘れてしまう現象です。
00:02:55Claude Codeを使っている時、UIを特定の見た目にしたいと指定したにもかかわらず、それが守られず、改めてゴールを思い出させなければならない、といった経験があるかもしれません。
00:03:053つ目は「メモリの破損」で、実行中にエージェントの内部状態や保持している事実が不正確になり、そのまま誤った状態に基づいて行動し続ける時に発生します。
00:03:14エージェントが長時間稼働すると原因の特定が難しく、どこでミスが生じたのか不明瞭になりがちです。
00:03:21例えば、エージェント自身がファイルを1つの形式で書き込んだ後、現在のコンテキストにはないサブエージェントがそのファイルを修正するようなケースです。
00:03:29エージェントは自分自身の古い記憶を参照して、ファイルが最初に作成した時の形式のままであるかのように操作を続けます。
00:03:37最後は「決定の不正確さ」です。
00:03:39これは、エージェントがほぼ同一の状況で矛盾した選択をすることです。例えば、ある場所ではエラーハンドリングにこのパターンを使い、別の場所では別のパターンを使うといったことです。
00:03:48これらの問題はすべてコンテキストが適切に管理されていない時に起こり、エージェントの長期的なパフォーマンスに影響を与えます。
00:03:53これらこそが、ほとんどのエージェント開発プラットフォームが最適化しようとしている要因です。
00:03:57Claudeに何かを頼んで完了した後、次の指示として考えられる選択肢が5つあります。
00:04:06それぞれは、あなたの次のプロンプト次第です。
00:04:08それぞれを適切に使えば、Claudeとの作業は大幅に改善されます。
00:04:12「そのまま続ける」のが最も自然な選択ですが、他の選択肢を使えばより効果的にコンテキストを管理できます。
00:04:18そのため、同じ流れを続けるべきか、新しいセッションを始めるべきかを慎重に判断する必要があります。
00:04:24コンテキストが膨らんだ場合、コンテキストを削減する2つの方法があります。1つ目は先ほど説明した「圧縮」で、既存の内容を要約することです。
00:04:32しかし、どのタイミングで要約するかを明確にする必要があります。要約は情報を削るため、あなたには重要に見えてもClaudeには不要と判断された詳細が失われる可能性があるからです。
00:04:41その結果、重要なコンテキストがウィンドウから消えてしまうかもしれません。
00:04:44Claudeの自動圧縮に任せるのではなく、自分で制御する方が良いでしょう。タスクの途中で自動圧縮がトリガーされると、要約がさらに乱雑になるからです。
00:04:52Claudeは重要だと思うものだけを残し、必要ないと判断したものをすべて削除する傾向があるため、圧縮中のClaudeは最も信頼できません。
00:05:00その時点でのClaudeは要約だけに集中しており、本来ならClaudeを賢くしているシステムプロンプトなどのサポートコンテキストが剥ぎ取られています。
00:05:08Claudeは「何が重要か」という独自の仮定に強く依存するため、圧縮の判断を誤ることがよくあります。
00:05:14不適切な圧縮は、モデルがあなたの作業の方向性を明確に判断できない時に起こります。
00:05:19例えば、長いデバッグセッションで自動圧縮の後に何らかの警告が出た場合、その特定の警告を修正するよう指示しても、Claudeは何の話か分からなくなります。
00:05:29これはセッション全体がデバッグ作業として捉えられ、デバッグ活動の一般的な要約だけが保持され、具体的な警告はノイズとして削除されたために起こります。
00:05:39「直近バイアス」が事態をさらに悪化させます。
00:05:41圧縮がトリガーされると、プロンプトは作業中の「直近の詳細」を優先して保持しようとします。
00:05:46そのため、古くても依然として重要な情報が無視されたり、省かれたりします。
00:05:50以前に何かが不適切に行われていたとしても、圧縮後にはモデルがそのことを認識していない可能性があります。
00:05:54圧縮時にはツール呼び出しの履歴が完全には保存されないため、モデルはプロジェクトの全状態ではなく、トランスクリプトレベルの要約にしかアクセスできないからです。
00:06:01自動圧縮のタイミングを制御するフラグは設定できますが、もっと頻繁に自分自身で積極的に管理すべきです。
00:06:07コンテキスト腐敗が出始める30万から40万トークンの範囲で圧縮をトリガーし、必ず自分自身で圧縮指示を出してください。明示的な指示がある方がClaudeはより注意深く反応するからです。
00:06:22どの決定事項、制約、発見された問題を次のウィンドウに引き継ぐべきか、何を優先すべきかをClaudeに伝えてください。
00:06:27ですから、新鮮なスタートを切りたい時ではなく、前のタスクフローからのコンテキストを新しいウィンドウに引き継ぎたい時に「圧縮」を押すべきです。
00:06:34次に進む前に、スポンサーからのメッセージです。
00:06:37Verdantは、アイデアを製品として出荷するまでを支援するAIプラットフォームです。
00:06:41ビルドの最中、ようやく調子が出てきたという時に、クレジットが尽きてしまうことがあります。
00:06:45AIが突然止まり、勢いがそがれてしまいます。
00:06:47どんなAIコーディングツールもこれを行いますが、Verdantは違います。
00:06:50クレジットがゼロになったら、エコモードに切り替えてください。これは追加料金なしでAIを動かし続けられるモードです。
00:06:56中断もなければ、追加チャージも、失われる勢いもありません。
00:06:59ただビルドを続けるだけです。
00:07:00クレジットがある時でも、Claude、GPT、Geminiのどれを使うか選ぶのに悩む必要はありません。
00:07:04Verdantのマルチプランモードは、3つすべてを決定委員会のように連動させ、モデルの選択に悩むことなく、より良いプランを提供します。
00:07:10さらに柔軟性が必要ですか？
00:07:11BYOK機能を使えば、自分のAPIキーを直接Verdantに繋ぐことができます。
00:07:15会社のClaudeやGPTのクレジットを使えば、プラットフォーム側の料金はかかりません。
00:07:18実際に使った分だけ支払えば良いのです。
00:07:20100クレジットと7日間の試用期間が提供されます。
00:07:23ピン留めされたコメントのリンクから、Verdantを無料で試してみてください。
00:07:262つ目の選択肢は「clear」コマンドを使うことで、すべてのコンテキストを削除し、空のコンテキストで新しいセッションを開始します。
00:07:32圧縮とは異なり、何も引き継がれず、再度提供したものだけがコンテキストウィンドウに残ります。
00:07:37圧縮と同様に、コンテキストが切れた時だけ「clear」を使うべきではありません。
00:07:41関連のないタスクに切り替えるなら、セッションをクリアして最初から始めるのは非常にスムーズで、前のタスクが新しいタスクに干渉することはありません。
00:07:49例えば、アプリケーションのテストケースを作成するようエージェントに指示した場合、そのテストケースがどのように生成されたかの詳細は保持したくないかもしれません。
00:07:57同じコンテキスト内でデバッグを続けるのではなく、新しいセッションを開始できます。
00:08:01そうすれば、テストケースを生成した経緯に影響されることなく、Claudeはアプリケーションのデバッグに効果的に取り組めます。
00:08:08もう一つのアプローチとして、clearと圧縮を組み合わせる方法があります。
00:08:12これを使えば、残したい情報だけを保持し、その他すべてを破棄できます。
00:08:16考え方は、保持したい情報を構造化JSONフォーマットでキャプチャするというものです。
00:08:21カスタムコマンドを作成すれば、頻繁に再利用できます。
00:08:24そのコマンドの中に、完全なタスク、現在の状態、制約、発見された問題、その他Claudeに保持させたい詳細を網羅したJSON構造を含め、それをファイルに保存するよう指示します。
00:08:35このアプローチは、両方の手法の良いとこ取りができます。
00:08:38コマンドを実行すると、会話全体とアプリケーションの現在の状態を分析してファイルに保存します。これは通常の圧縮では確実に保持できないものです。
00:08:48スキーマは散文よりも厳格なため、Claudeが定義された構造に従うことで、何が重要かをより一貫性を持って正確に表現できます。
00:08:56情報がファイルに保存されたら、clearコマンドを使ってコンテキストウィンドウからすべてを安全に削除できます。
00:09:02その後、新しいセッションを開始し、Claudeにそのドキュメントを参照してコンテキストを収集し、そこから次のタスクを実装するよう指示すれば良いのです。
00:09:14先述の通り、コンテキストが大きくなると、情報量が増えて注目対象が競合するため、エージェントの焦点がずれることがあり、これは100万のコンテキストウィンドウでより顕著になります。
00:09:23この実践は、先ほど議論したゴールドリフト問題と、決定の一貫性問題の両方に対処するのに役立ちます。
00:09:29長時間タスクをひたすら進める代わりに、時々作業を一時停止し、これまでの成果と制約、その他の重要な要素について要約させるのが有効です。
00:09:39こうすることで、本来のゴールが再強化され、重要な詳細がコンテキストウィンドウの古いセクションに埋もれることなく、より最近の箇所に引き戻されます。
00:09:48これにより、重要な情報がエージェントの作業コンテキスト内で新鮮に保たれ、圧縮中に失われたり、時間とともに希薄になったりする可能性が減ります。
00:09:56そうしてエージェントは本来のタスクに沿った状態を保ち、決定の一貫性を維持できるようになります。
00:10:02また、コンテンツを楽しんでいただけたなら、ぜひ「hype」ボタンを押してください。そのようなコンテンツを増やし、より多くの人に届ける助けになります。
00:10:09サブエージェントは目立たないかもしれませんが、コンテキストを管理する上で非常に重要な手段です。
00:10:14各サブエージェントは独立したインスタンスであり、独自の専用コンテキストウィンドウ、フルツールアクセス権、タスク完了に必要な権限を持っています。
00:10:22それらはメインエージェントから提供された個別のコンテキストで割り当てられた作業を実行し、最終出力のみをメインコンテキストに返します。
00:10:30そのため、サブエージェントが行ったすべてのツール呼び出し、読み込んだファイル、ウェブ検索、中間的な推論はすべてサブエージェント自身のコンテキストに留まり、メインエージェントのコンテキストを汚染しません。
00:10:40これはコンテキスト腐敗を減らす効果的な方法です。リサーチタスクが最もわかりやすい例でしょう。
00:10:45エージェントが複数のウェブサイト、ページ、ソースを調べる時、その生の情報をすべてメインコンテキストに連続して追加したくはないはずです。
00:10:53そのような場合、サブエージェントが独立して作業を処理し、最終的な統合結果だけを返せば良いのです。
00:10:58サブエージェントを使う前に自問すべき重要な問いは、中間ステップへのアクセスが後で必要か、それとも最終出力だけが必要か、ということです。
00:11:07Claude Codeもサブエージェントのオーケストレーションを独自に管理しており、タスクを処理するために自動的にエージェントを生成できます。
00:11:13しかし時として、タスクを隔離された状態で処理させるために、プロンプトでサブエージェントへの委任を明示的に指定する必要があります。
00:11:20リサーチタスク、リファクタリング、要約、ドキュメント生成などを行う場合は、メインエージェントではなく、サブエージェントを使って分離することを検討してください。
00:11:30最後になりますが、「巻き戻し」は単なる修正よりも重要です。なぜなら、不適切あるいは誤った部分をコンテキストウィンドウから取り除き、正しい状態だけを維持できるからです。
00:11:40Claudeがミスをした時、多くの人は別のアプローチを再プロンプトしようとします。
00:11:44しかし、より良い選択肢は、巻き戻してから、次のプロンプトで正しい方向性を示すことです。
00:11:49巻き戻しコマンドを使うか、エスケープキーを2回押せばそれができます。
00:11:53巻き戻した後は、その時点から要約することも可能で、そこまでの会話は有益なコンテキストとして保存しつつ、問題を引き起こした部分だけを取り除くことができます。
00:12:01巻き戻しには複数の利点があります。
00:12:03第一に、物事がうまくいかなくなった箇所を取り除くことでコンテキストウィンドウがきれいになり、その結果、正しい実装だけを保持したクリーンな圧縮要約が作られます。
00:12:12重要な情報をピン留めしていても、エージェントがゴールから逸脱したセクションを持ち越すことがなくなるため、決定の不一致やゴールドリフトを減らすことができます。
00:12:21サブエージェントを使っている場合、巻き戻しを行うことで、誤ったアプローチが作業状態に含まれることなく、タスクを引き継ぐ際に、よりクリーンで正確なコンテキストを渡すことができます。
00:12:30同様に、ハンドオフ（受け渡し）コマンドを使用する場合でも、破損したり古い状態ではなく、アプリケーションの正しい状態をキャプチャできます。
00:12:37ですので、何度も前向きに修正するのではなく、巻き戻す習慣をつけましょう。そうすれば、エージェントはセッション全体を通して常にクリーンで正確な状態から作業を開始できます。
00:12:45動画は以上です。
00:12:47このチャンネルを応援し、このような動画作りを助けてくださるなら、下のスーパーサンクスボタンからご支援いただけます。
00:12:54いつもご視聴ありがとうございます。また次の動画でお会いしましょう。