第 2 章 Q1　コンテキストの扱い方｜「AI 開発してます」を見極める 10 の質問

Q1. コンテキストの扱い方

長いプロンプトを書く以外に、実際の案件でコンテキストをどう設計・管理していますか？トークン数や履歴の扱いなど、実務で工夫している点を教えてください。
出典: @voidwarriorchan の投稿（2026-08-25）

この章で分かること

「プロンプトを書く」ことと「コンテキストを設計する」ことが、なぜ別の作業なのか
渡すトークンが増えるほど精度が落ちる「コンテキスト腐敗（context rot）」という現象の仕組み
情報を渡す順番が結果を左右する理由と、実務での配置の原則
長い会話や長時間タスクでコンテキストを保つための代表的な3つの技法
この質問への良い回答・弱い回答の見分け方

この質問は何を聞いているのか

質問はわざわざ「長いプロンプトを書く以外に」と前置きしている。ここに核心がある。プロンプトエンジニアリング（= 指示文の書き方を工夫すること）とコンテキストエンジニアリング（= モデルに渡すトークンの集合全体を選び続けること）は別物であり、質問は後者を尋ねている。

コンテキストとは、モデルが1回の応答生成で参照できるトークン（= モデルが文章を扱う最小単位。単語・部分語・文字などに対応する）の集合を指す。プロンプトの文面だけでなく、システムへの指示・ツール（= 検索やファイル読み込みなど、モデルが「使いたい」と要求できる外部機能。その説明文＝ツール定義もトークンとして渡される）・外部データ・会話履歴まで含まれる。プロンプトを書くのは1回きりの作業だが、コンテキストの取捨選択は渡すたびに繰り返す反復作業であり、関係しそうな情報が増え続けるたびに何を残すか選び直す必要がある。

つまりこの質問は、「プロンプトの言い回しではなく、システム指示・ツール・外部データ・会話履歴を含めたトークン集合全体を、実務でどう設計・管理し続けているか」を尋ねている。候補者が「1回良いプロンプトを書けば終わり」という段階で止まっているか、本番運用で繰り返される設計問題として捉えているかを見極めることができる。

図 2-1　上: 候補情報(システム指示・ツール・外部データ・履歴・メモリ)を選別(curate)してコンテキストウィンドウに渡し、推論結果を次の候補情報へ戻すループを推論のたびに繰り返す。下: プロンプトエンジニアリングは1回書けば完成する作業、コンテキストエンジニアリングは毎ターン反復する作業という対比。

コンテキストは有限で目減りする資源 — attention budget と context rot

モデルが1回の応答生成で参照できる全テキストの上限をコンテキストウィンドウという。学習データとは別物のモデルの「作業記憶」で、システムプロンプト（= 会話の冒頭でモデルに与える土台の指示）・全メッセージ（ツール結果・画像・文書含む）・ツール定義・出力（内部の思考過程も含む）まですべて数えられ、キャッシュしていても消費量自体は変わらない。「窓が大きいほど詰め込んでよい」わけではなく、トークン数が増えるほど正確さと想起精度が下がる現象が知られている。これがコンテキスト腐敗（context rot）で、劣化の度合いはモデルにより異なるが傾向自体は全モデルに共通する。コンテキストは「限界効用が逓減する有限資源（= 足せば足すほど1トークン追加の効き目が小さくなる、限りある資源）」であり、モデルにも一種の「注意の予算（attention budget）」があって、トークンを1つ足すたびに目減りしていく。

背景には構造的な理由がある。主流モデルのTransformerは、コンテキスト中の全トークンが互いに関連づけ（注意）を計算する仕組みを持ち、トークン数nに対し組み合わせはn²のペアに増え、長くなるほど、各ペアの関係を捉える力が薄く引き伸ばされる。劣化は「崖」ではなく、なだらかな「勾配」である。ベクトルデータベース企業Chromaの技術レポート（Anthropic・OpenAIの公式ドキュメントがcontext rotの出典として参照）は18種類のモデルを評価し、関連部分に絞った短い入力（平均約300トークン）と無関係な履歴を含む長い入力（平均約113,000トークン）を比較すると、すべてのモデルで前者の方がはっきり高い性能を示した。話題は近いが答えではない文（distractor）が1つ混ざるだけでも性能が下がり、4つで更に悪化する。入力が長いほどその影響は増幅する。「大きなウィンドウが出れば解決する」という楽観は成り立たない。

図 2-2　左: トークン数が増えるほど想起精度は崖ではなく勾配としてなだらかに落ちる(概念図)。右: 第三者評価では、無関係な情報を含む長い入力(full)は、関連部分だけの短い入力(focused)より一貫して性能が低い(概念図。棒の高さの差は傾向を示す目安で、出典に具体数値の記載はない)。

情報を渡す位置が結果を左右する — Lost in the Middle

2023年発表の論文「Lost in the Middle: How Language Models Use Long Contexts」は、関連情報をコンテキスト中のどこに置くかで性能が大きく変わることを実証した。先頭または末尾にあるときは高い性能を示す一方、中央付近に置かれると性能が大きく落ちるU字型の傾向が観測された。実験モデルは2023年当時のもので絶対値を現行モデルに当てはめることはできないが、「位置によって精度が変わりうる」という性質は、自分のシステムを評価するときに確認すべき項目として扱う。

長文脈対応モデルでもこの位置依存性は解消されなかった。GPT-3.5-Turboでは、関連文書が多い設定（20〜30文書）で答えが中央付近にあると、文書をまったく与えない場合（closed-book）の精度を下回るケースさえ確認された。質問文を文書の前後に配置する手法は単純な検索タスクではほぼ満点まで性能を押し上げたが、複数文書の質問応答タスクではほとんど傾向を変えなかった。取得文書数を20件から50件に増やしても性能改善はわずかで、長さとレイテンシ（応答が返るまでの時間）だけが増える結果になった。

図 2-3　関連情報が先頭・末尾にあると精度は高いが、中央にあると急落するU字型の傾向。GPT-3.5-Turboの20〜30文書設定では、中央付近の精度が「文書ゼロ」の基準値(56.1%)さえ下回った。

何を先に渡すか — 配置の設計原則

システムプロンプトは細かすぎても曖昧すぎても失敗する。「Aの場合は必ずX、Bの場合は必ずY」と場合分けを細かく書き込みすぎた指示は、想定外の状況に弱く保守も難しい。抽象的すぎる指示は判断材料を与えない。両極端の中間の「ちょうど良い高度」を狙う。「最小」は「短い」ではなく無駄をそぎ落とすことを指し、例も網羅列挙ではなく典型的で多様な3〜5個に絞る。

配置の順序にも根拠がある。Anthropicの公式ドキュメントは、Claudeで20,000トークンを超える長文データを扱う場合、長い文書を先頭に、今回の質問・タスク指示・例を末尾に置くと性能が改善すると記しており、テストでは応答品質が最大30%改善した（特に複雑な複数文書入力で効果が大きい）としている（2026-08時点。実験の詳細は非公開）。GoogleもGeminiで質問を末尾に置くことを推奨している。複数文書はXMLタグ（= <documents>のように山括弧で区切りを付ける目印）で囲み出典を添えると混同しにくい。

<documents>
  <document index="1">
    <source>annual_report_2023.pdf</source>
    <document_content>
      ...
    </document_content>
  </document>
</documents>

(この後に、今回の質問を置く)

この「先頭に静的な内容、末尾に動的な内容」という並びは、位置依存性の回避だけでなく、費用の面でも理にかなっている。システム指示・ツール定義・長文データのように毎回変わらない部分を先頭にまとめておくと、その部分だけを使い回せる仕組み（詳しくは次章で扱うプロンプトキャッシュ）が働きやすくなる。逆に、現在時刻や今回だけのユーザー入力のような毎回変わる部分は末尾に置く。位置バイアスを避ける設計と、キャッシュを効かせる設計が、同じ「静的は先頭・動的は末尾」という一つの原則に収束する。

図 2-4　ツール定義・システム指示・長文データという変わらない部分を先頭にまとめ、今回の質問だけを末尾に置く。先頭は位置バイアスとキャッシュ効率の両方で有利、末尾は動的なので毎回処理される。AnthropicのAPIではシステムプロンプトはメッセージより前に置かれる別フィールドなので図の位置になる。ユーザーメッセージの中では、長文データを先に、今回の質問・タスク指示・例を後に置く。

実務では何をするのか

トークン数は感覚ではなく実測する。公式のカウント機能（Anthropicのcount_tokens。APIの呼び出し先の1つで、無料だが推定値）を使うとよい。たとえばClaudeは4.7以降のモデルで新しいトークナイザ（テキストをトークンに変換する仕組み）に切り替わり、同じ文章でも約30%多くトークンを消費する（2026-08時点）。旧モデルで測った数値を流用せず、使うモデルで数え直す。

情報を「どこまで先に渡すか」にも設計判断がある。関連データを検索して埋め込む事前ロード型と、ファイルのパスやURLのような短い目印だけを保持し必要時にツールで都度取得するjust-in-time型（= 必要になった時点で都度取得する方式）があり、前者は速いが古くなりやすく、後者は新鮮だが探索が甘いと迷子になる。Anthropicは一部の場面では両者を組み合わせるハイブリッドが最も効果的になりうるとし、Anthropicのコーディング用エージェントClaude Codeは、プロジェクトの指示を書いたファイルCLAUDE.md（= 起動時に必ず読み込まれる説明書）を先読みし、個々のソースファイルは検索で都度取得する構成を採っている。Anthropicは、変化の少ない内容（法務・金融など）ほどハイブリッドが向く可能性があるとしている。

知識ベースが大きい場合は検索拡張生成（RAG。関連断片だけ検索してプロンプトに追加する手法）を検討する。約20万トークン（500ページ程度）に収まるなら全文を渡す方が単純だが、超える規模では断片ごとに文書全体での位置づけを補ってから索引を作る手法が取りこぼしを大きく減らす。Anthropicの実験では取得件数は上位20件が5・10件より効果的だった。Lost in the Middleでは取得件数を20件から50件に増やしても改善は1〜1.5%程度にとどまった。ツール定義もコンテキスト設計の一部で、システムの機能をそのまま露出しただけの汎用ツール（例: 連絡先を全件返すlist_contacts）は不要な情報を大量に読ませる。用途を絞った名前と識別子、情報量を絞る仕組みが無駄遣いを防ぐ。

長時間タスクの履歴管理には大きく3つの技法がある。

技法	向いている場面
compaction(要約して新しい窓を始める)	やり取りが多く流れを保ちたいタスク
structured note-taking(外部メモリに書き出す)	マイルストーンが明確な段階的開発
sub-agent(別コンテキストに切り出す)	並列に探索できる複雑な調査

compactionは会話を要約し新しいウィンドウで続行する仕組み、structured note-takingは進捗をファイルなど外部に書き出し読み戻す仕組み、sub-agentは探索を別コンテキストに任せ要約だけを受け取る仕組みである。sub-agentは詳細な過程を隔離できる代わり、通常の会話より多くのトークンを消費する。何を残し何を捨てるかの詳細は、後述する「コンテキストウィンドウの調整」の章で扱う。

図 2-5　事前ロードは推論の前に埋め込み検索(embedding)などで関連データを取り出し、まとめてウィンドウへ入れる(速いが索引が古くなりうる)。必要時取得(just-in-time)はファイルパスやURLなどの識別子だけを持ち、ツールで都度取得する往復が起きる。ハイブリッドは設定ファイルを起動時に一括、個々のファイルは都度取得と使い分ける。Anthropicは変化の少ない領域(法務・金融など)ほどハイブリッドが向くとしている。

回答を見極めるポイント

良い回答に含まれる要素

プロンプトエンジニアリングとの違いを、対象範囲（システム指示・ツール・履歴・外部データを含む全トークン集合）と時間軸（毎ターンの反復的選択）の2軸で説明できる
「コンテキストは限界効用が逓減する有限資源」という前提を、なぜそうなるか（Transformerの構造など）とあわせて説明できる
情報を渡す順番（長い文書を先に、質問を末尾に、変わらない情報を先頭に）を意識して設計している
長時間タスクの履歴管理に、要約・外部メモリ・別コンテキスト切り出しといった技法の使い分けがある
トークン数を実測している、モデル更新で数え方自体が変わりうることを知っている

弱い回答のサイン

「長いプロンプトを書く以外に」という前提を無視し、プロンプトの書き方の工夫だけを答える
「コンテキストウィンドウが大きいモデルを使えば解決する」と答える（Anthropicの公式資料は「大きなウィンドウを待てば解決するとは考えにくい」「コンテキストが多いほど良いわけではない」と記している立場）
「とにかく多くの情報を入れる」ことを無条件に良いと考えている（件数を増やしても効果は乏しく、話題は近いが答えではない文（distractor）が1つ混ざるだけでも性能が下がる）
キャッシュされた部分はコンテキストウィンドウを消費しないと誤解している

深掘り質問の例

大きなコンテキストウィンドウを持つモデルに切り替えれば、この問題は解決すると思いますか。なぜそう考えますか
システムプロンプトに情報を詰め込みすぎて、かえって性能が落ちた経験はありますか
検索拡張生成（RAG）を使わずに済ませた、あるいは使うべきだと判断した基準は何ですか

つまずきポイント

「コンテキストウィンドウが大きい＝何でも詰め込んでよい」と思い込みがちだが、実際にはトークンが増えるほど想起精度が下がる。窓の大きさは上限であって、目標ではない。

「キャッシュしておけばコンテキストを消費しない」と誤解しやすいが、キャッシュは料金の計算方法を変えるだけで、コンテキストウィンドウの消費量そのものは変わらない。

「情報は多く渡すほど正確になる」と考えがちだが、関連情報が長い入力の中央に埋もれると精度はむしろ落ち、取得件数を増やしても改善は頭打ちになる。話題は近いが答えではない文（distractor）が1つ混ざるだけでも性能が下がり、4つで更に悪化する。入力が長いほどその影響は増幅する。

「プロンプトを書くこと」と「コンテキストを設計すること」を同じ作業だと思いがちだが、前者は1回の記述作業、後者はモデルに何かを渡すたびに繰り返される選別作業である。

理解度チェック

Q1. コンテキストエンジニアリングは、プロンプトエンジニアリングと何が違いますか？

対象範囲と時間軸の2点が違う。プロンプトエンジニアリングは指示文の書き方に絞った1回きりの作業。コンテキストエンジニアリングはシステム指示・ツール・外部データ・履歴まで含む全トークン集合を、渡すたびに選び直す反復作業である。

Q2. 「コンテキスト腐敗（context rot）」とは何ですか？なぜ起きますか？

トークン数が増えるほど情報を正確に思い出す能力が下がる現象。全トークンが互いに関連づけを計算するTransformerの構造上、トークン数nに対しn²の組み合わせが生じ、長くなるほど注意の焦点が薄く引き伸ばされることが背景にある。

Q3. 「Lost in the Middle」という研究は何を示しましたか？

関連情報が先頭または末尾にあるときは高精度、中央付近だと精度が大きく落ちるU字型の傾向を示した。GPT-3.5-Turboでは20〜30文書の設定で、中央付近の精度が「文書ゼロ」の基準値（56.1%）さえ下回った。長文脈対応モデル（16K版・100K版）でもこの傾向は解消されなかった。

Q4. 長時間タスクでコンテキストを保つための代表的な3つの技法は何ですか？

要約して新しい窓で続けるcompaction、進捗を外部メモリに書き出して読み戻すstructured note-taking、探索を別コンテキストに切り出し要約だけ受け取るsub-agentの3つ。それぞれやり取りの多い会話・段階的開発・並列に探索できる調査に向く。

まとめ

コンテキストエンジニアリングは、プロンプト文面ではなくモデルに渡すトークン集合全体を、毎ターン選び直す反復作業である
コンテキストは限界効用が逓減する有限資源であり、トークンが増えるほど想起精度が下がる「コンテキスト腐敗」が起きる
情報を渡す位置は結果を左右する。長い文書は先頭、質問は末尾、変わらない情報は先頭にまとめるのが原則
事前ロードとjust-in-timeにはトレードオフがあり、Anthropicは変化の少ない内容ほどハイブリッドな戦略が効果的になりうるとしている
長時間タスクの履歴管理にはcompaction・structured note-taking・sub-agentという使い分けがある

次章では、この配置の原則が経済面でどう効いてくるかを、プロンプトキャッシュとセマンティックキャッシュという2つの仕組みから見ていく。

Q1 コンテキストの扱い方