もと @moto_ai_jp
AI学習 › AIエンジニアリング講座・実践編 › 第3部 › 第6回

第3部 コンテキスト · 第6回 / 全20回 · 15分くらい

AIが一度に読める量には限りがある。何で埋まっているかを知る

AIが一度に読める量（コンテキストウィンドウ）は年々大きくなりました。それでも、たくさん入れるほど良い答えが返るわけではありません。この回では、その窓が実際に何で埋まっているのか、多く入れると何が起きるのかを、研究とドキュメントを根拠に確かめます。

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20

履修 0 / 20 回

この回を読み終えると、できるようになること

  1. コンテキストウィンドウに入っているものを5種類言え、どれが大きくなりやすいかを説明できる
  2. 入れる量が増えると答えの質が下がる理由を、「途中が読み落とされる」「文脈が長いと劣化する」の2つの報告から説明できる
  3. 会話を切る・まとめる・道具の出力を絞る、の3つの手を使い分けられる

専門用語は、初めて出たところで括弧に短い説明を付けています。説明が長くなるものには ※番号を付け、ページの終わりの用語メモにまとめました。

1窓の中には、何が入っているか

コンテキストウィンドウ※1に入っているのは、自分が打った文だけではありません。Claude Code の場合、おおよそ次のものが入っています。

中身いつ入るか大きさ
システムの指示最初から一定
道具の説明（ファイル操作、検索、MCP※2 の道具など）最初から、または必要になったとき道具の数による
CLAUDE.md、メモリ最初から書いた量だけ
これまでの会話やりとりのたびに増えるどんどん増える
道具を使った結果（読んだファイル、コマンドの出力）道具を使うたびに増えるいちばん大きくなりやすい

長い作業では、ファイルを読んだ結果やコマンドの出力が、窓の大半を占めることがよくあります。大きなログを1回丸ごと読ませるだけで、それまでの会話より多くの量を使うこともあります。

2入れれば入れるほど良くなる、わけではない

Anthropic の記事「Effective context engineering for AI agents」では、AIには人の作業記憶のように「注意を向けられる量」に限りがあり、トークンを1つ足すたびにその余力が少しずつ減る、と説明されています。そのうえで、望む結果を出すのに必要な、いちばん小さくて中身の濃い情報の組み合わせを探すのが、文脈を設計するときの基本だとしています。

この考えを裏づける報告が2つあります。

  • 途中が読み落とされる：Liu らの「Lost in the Middle」（2023）は、必要な情報が文脈の最初か最後にあると成績が高く、真ん中にあると大きく下がると報告しています
  • 長くなるほど劣化する：Chroma の調査「Context Rot」（2025）は、18のモデルで、簡単な課題でも入力が長くなるほど成績が不安定になり、その下がり方は一様ではない、と報告しています

長い会話の後半で、最初に決めたルールが守られなくなるのは、この2つが重なって起きていると考えられます。

3MCP の道具は、つないだだけでは窓をあまり使わない

以前は、MCP サーバーをたくさんつなぐと、使っていない道具の説明まで毎回窓に入っていました。今の Claude Code にはツール検索という仕組みがあり、会話の始めに読み込むのは道具の名前とサーバーの説明だけで、道具の詳しい定義は必要になったときに読み込まれます。ドキュメントには「MCP サーバーを増やしても、窓への影響は小さい」と書かれています。

実践編の最初の版では「使っていない道具も、存在するだけで窓を使う」と書いていました。今の仕組みに合わせて訂正します。

代わりに気をつけたいのは、道具を使った結果の大きさです。Claude Code は、MCP の道具の出力が1万トークンを超えると警告を出し、既定では2万5千トークンで打ち切ります。大きな検索結果や一覧を返す道具は、1回使うだけで窓のかなりの部分を使います。

4会話を切るのも、文脈の設計のうち

話題が変わったら、新しい会話を始めるほうが良い結果になることが多いです。前の話題の材料は、次の話題には雑音になるからです。

長くなった会話を要約して窓を空ける仕組みもあります。これをコンパクション※3と呼び、Claude Code は窓がいっぱいに近づくと自動で行います。ただ、要約である以上、細かい事実や決めたことの一部は落ちます。続きに必要なことはファイルに書き出してから切るのが確実です。これは第17回の「何日も続く作業」でも中心になる考え方です。

5プロンプトキャッシュは「費用」を減らすもので、「量」は減らさない

同じ前置き（システムの指示や長い資料）を何度も送るときは、プロンプトキャッシュ※4で費用と待ち時間を減らせます。ただし、キャッシュが効いても、AIが読む量そのものは変わりません。窓の中身が多すぎて答えの質が落ちている問題は、キャッシュでは直りません。

「安くなったから、全部入れておこう」と考えると、費用は抑えられても、質のほうで損をします。

6いま窓に何が入っているかを確かめる

Claude Code では /context を打つと、いまの窓の使われ方が部品ごとに表示されます。大きな作業の前に、何もしていない状態で一度確かめておくと、どの部品が重いのかがわかります。

確かめた結果が重ければ、手は3つあります。

  1. 常に読ませているものを減らす：CLAUDE.md やメモリの見直し（第7・8回）
  2. 道具の出力を絞る：ログは全部ではなく末尾だけ、検索は件数を絞って、と頼む
  3. 会話を切る：続きに必要なことをファイルに書いてから、新しい会話にする

誤解よくある思い違い

窓が大きいモデルなら、資料は全部入れたほうがよい

入る量と、うまく使える量は別です。長くなるほど読み落としや劣化が起きやすいので、必要な部分を選んで入れます。

MCP サーバーをつなぎすぎると、それだけで窓が埋まる

今の Claude Code はツール検索で道具の定義を必要なときに読み込むので、つないだだけの影響は小さくなっています。気をつけるのは、道具を使った結果の大きさです。

プロンプトキャッシュを使えば、長い文脈の問題は解決する

キャッシュが減らすのは費用と待ち時間です。AIが読む量は変わらないので、質の問題は残ります。

演習手を動かして確かめる

演習1

10万行あるログの中から、昨日起きたエラーの原因を調べたいとします。窓を無駄に使わない頼み方を考えてください。

答えを見る

ログを丸ごと読ませずに、道具で絞ってから読ませる頼み方にします。たとえば「まず昨日の日付で絞り、ERROR を含む行だけを数えて、多い順に5種類を出して。そのあと、いちばん多いものの前後20行だけを読んで原因を考えて」。必要な部分だけが窓に入るので、原因を考える段階でも注意が散りません。

演習2

長い会話の後半で、最初に決めた「ファイル名は日付から始める」というルールが守られなくなりました。考えられる理由と、手を2つ挙げてください。

答えを見る

理由は、会話が長くなって最初の指示が窓の「真ん中」に埋もれた、または要約（コンパクション）のときに落ちた、と考えられます。手は、①そのルールを CLAUDE.md に書いて毎回読ませる、②会話をいったん切って、必要なことをファイルに書いてから新しく始める、の2つです。絶対に守らせたいなら、第9回のフックでファイル名を確かめる手もあります。

頼み方そのまま使える頼み方の例

これから大きな作業を始める前に、窓の使い方を見直したいです。
1. 今の会話で、窓を大きく使っているものを大きい順に3つ挙げてください（推測なら推測と書く）
2. 次の作業（下に書く）で、読ませる必要がないものはどれですか
3. 道具の出力を絞るなら、どう頼めばよいですか
変更はせず、案だけ出して止まってください。

次の作業：（ここに書く）

自分は、何もしていない状態で /context を見て、思っていたより常に読ませているものが多いことに気づきました。外してみても、困ったことはほとんどありませんでした。

用語メモ本文の ※番号の説明

  1. ※1コンテキストウィンドウ AIが1回の応答を作るときに、一度に読める文章の量の上限。トークンの数で表す。会話・資料・道具の結果など、AIに見えているものは全部この中に入る。 本文へ戻る ↩
  2. ※2MCP（Model Context Protocol） AIアプリと外部のサービスやデータをつなぐための共通の決まり。MCP サーバーを用意すると、Claude Code などからそのサービスの機能を「道具」として使えるようになる。 本文へ戻る ↩
  3. ※3コンパクション（compaction） 窓がいっぱいに近づいた会話を要約し、その要約から新しい窓で続ける仕組み。窓は空くが、要約で細かい情報の一部が落ちる。 本文へ戻る ↩
  4. ※4プロンプトキャッシュ 前回と同じ前置き部分を API 側で覚えておき、2回目以降の計算を省いて、費用と待ち時間を減らす仕組み。読む量そのものは変わらない。 本文へ戻る ↩

出典確かめた資料（2026年10月時点）

読めたらチェック

この回：0 / 3