コンテキスト設計の実践パターン

この記事の目的

コンテキストエンジニアリングが示す原則(最小十分・重要情報を埋もれさせない・静的動的の分離・実行時取得)を、実際にどう並べ・どれだけ割り当て・どう取得し・どう前処理し・どう測るかという実践パターンに落とせるようになります。原則は分かったが具体の設計で手が止まる、という状態を解消します。

対象読者

• コンテキストエンジニアリングLLM に渡す情報の全体(システムプロンプト・ツール定義・履歴・資料・状態)を、構成要素の選択・配置・ライフサイクルとして設計する営み。原則は コンテキストエンジニアリング、実践パターンは コンテキスト設計の実践パターンの原則は理解し、実際のコンテキスト構成を設計・改善する段階のエンジニア
• 長い対話・大量の参照資料を扱う Agent で、品質とコストを両立させたいエンジニア

前提知識

• コンテキストエンジニアリング — 設計原則(本記事はその実践詳解)
• 注意機構とコンテキストウィンドウの仕組み — レイアウトの根拠となる理論
• メモリと状態管理 — 履歴という動的部分の基礎

本文

概要: 原則記事との分担

なお、1 つのプロンプト内部の配置(プロンプトエンジニアリングの上級パターンの構造化)と、コンテキスト全体(システム・ツール定義・履歴・資料の総体)のレイアウトは別の粒度です。本記事は後者を扱います。

レイアウトの設計: 更新頻度で層を分ける

コンテキスト全体を「どの順に並べるか」は、更新頻度を第一の軸にすると設計判断が単純になります。前方に置くほどプロンプトキャッシュプロンプトの固定部分(前方一致)の処理結果を再利用し、入力コストと応答開始までの時間を削減する仕組み。固定部分を先頭に置くプロンプト構造が前提。が効き、後方(末尾)に置くほど直近性で注意が向く、という 2 つの性質(注意機構とコンテキストウィンドウの仕組み)を、更新頻度の低い順に並べることで同時に満たせます。

図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

• キャッシュ境界を意識する: 前方の固定ブロックにタイムスタンプ・セッション ID などの可変値が 1 つでも混じると、それ以降のキャッシュが毎回無効になります(コスト管理)。可変値は後方の専用ブロックへ隔離します
• 末尾に「現在の指示」を再掲する: 長い資料の後にタスク定義を短く繰り返すと、中間に置いたときより確実に参照されます(中間の想起が弱くなる性質への対処)
• ツール定義の常駐を疑う: 使用頻度の低いツールの定義は、前方に常駐させる価値があるか(トークンを毎回占有する)を検討します。フェーズによってツールセットを切り替える設計も選択肢です

予算の設計: コンテキストを配分する

「上限に入るか」ではなく「各要素にどれだけ割り当てるか」を設計します。コンテキストウィンドウを予算とみなし、セクション別に配分するのが実践的です。

• セクション別バジェット: システム + ツール定義(固定)/ 検索結果(上位 N 件・M トークンまで)/ 履歴(直近 K ターン + 要約)/ 出力用の余白、というように上限を要素ごとに決めます。とくに出力用の余白の確保は忘れられがちで、入力で埋め尽くすと生成が途中で打ち切られます
• 計測を先に用意する: 実際に何がどれだけ占有しているかは、想像ではなく計測します。要素別のトークン内訳をトレースに残すと、肥大の主因(たいてい履歴か検索結果)がすぐ分かります(可観測性とトレーシング、トークナイザとトークン経済)
• 超過時の縮退規則を決める: 予算を超えたときに何を削るかを、実行時に慌てて決めるのではなく規則化します(古い履歴から要約 → 検索件数を減らす → それでも溢れるなら停止して報告)。「入るだけ入れて溢れたら末尾を捨てる」実装は、最も重要な直近の指示を捨てる事故を生みます

取得戦略: 事前ロードと実行時取得の設計

コンテキストエンジニアリングの「事前ロードより実行時取得(just-in-time)」を、判断基準まで具体化します。

• JIT のコスト: 実行時取得は「検索してから答える」ための追加のループ往復とレイテンシを生みます(レイテンシ最適化)。使用確率が高く小さいものまで JIT にすると、遅く高くなります
• ハイブリッド(目次 + 本文): 大きなマニュアルは「目次・見出しだけ事前ロード + 本文は読み出しツールで取得」が定番です。モデルが全体像を把握したうえで必要箇所だけ引けます
• JIT の攻撃面も評価する: 実行時取得は非信頼入力と外部送信の経路を増やすため、送信先・取得量・取得後の権限制約を設計します。 事前ロードの過剰は静かに品質を蝕みますが、取得漏れは「検索してから答えて」という観測可能・改善可能な失敗として現れます(原則記事と同じ判断)

資料の前処理: どの形で渡すか

同じ資料でも、渡す前の加工形態で品質もコストも変わります。

判断の要点は、下流のタスクが要求する精度です。正確な引用・数値が要るなら全文か抜粋、方針判断だけなら要約、というように後段の用途から逆算します。要約で渡すと「元資料にない細部を聞かれても答えられない」という制約が生まれることを、渡す時点で意識します。

統合と競合: 複数情報源をどう束ねるか

複数の資料・情報源を渡すと、必ず競合(食い違い)と重複が起きます。放置するとモデルが恣意的にどちらかを採用し、再現性が失われます。

• 出所を明示する: 各資料に出所(文書名・更新日・信頼度)を付けて渡すと、モデルが品質上の優先順位を判断しやすくなり、回答の検証にも使えます。信頼度ラベルは品質上の優先付けであり、防御ではありません。非信頼資料を指示や権限の根拠にせず、危険操作はコード側で制限します
• 競合の解決規則を渡す: 「新しい更新日を優先」「一次情報発信源そのものの情報(論文の原典・公式ドキュメント・公式ブログ・規格本文・法令)。解説・まとめ(二次情報)と区別し、根拠は一次情報に置くのが情報リテラシーの基本。二次情報は「存在を知る」までに使い、一次まで遡って確かめる。を優先」「食い違う場合は両論併記して確認を促す」など、競合時の振る舞いを指示に含めます。指示がなければ運任せになります
• 重複を除く: 同一内容の版違い・重複チャンクは前処理で除きます(希釈と混乱の元)。検索段での重複排除は RAG 実装パターンが扱います
• 鮮度: 古い資料が混じると自信のある誤答の元になります(ケーススタディ: 社内ナレッジ Agentの鮮度問題)。更新日をメタデータで渡し、古いものの扱いを規則化します

計測と改善: 効いているセクションを見つける

コンテキストは「入れた分だけ効く」わけではありません。どのセクションが品質に寄与しているかを測らないと、無駄な要素を運び続けます。

• アブレーション(除去実験): あるセクション(例示・特定の資料・履歴の一部)を抜いて評価セットを回し、スコアが下がらなければそれは効いていない候補です(Agent 評価の基礎)。1 セクション 1 実験で交絡を避けます
• 失敗の帰属: 失敗ケースで「必要な情報がコンテキストにあったのに使われなかった(配置・希釈の問題)」のか「そもそも無かった(取得の問題)」のかを切り分けます。前者はレイアウト、後者は取得戦略の改善に向かいます
• コストと品質の同時計測: セクションを増減させたときの品質とトークンコストを両方見ます。品質が変わらずコストだけ増える要素は、削減候補です

実務での注意点

アンチパターン

チェックリスト

関連トピック

• コンテキストエンジニアリング — 設計原則(本記事の前提・正本)
• コンテキストの圧縮と隔離 — 履歴が増え続ける動的部分への対処(対の記事)
• 注意機構とコンテキストウィンドウの仕組み — レイアウトの理論的根拠
• RAG 実装パターン — 検索・重複排除の実装
• コスト管理 — プロンプトキャッシュとトークンコストの実務
• プロンプトエンジニアリングの上級パターン — プロンプト内部(1 呼び出し)の配置

参考資料

• Effective context engineering for AI agents(Anthropic)  — コンテキストを有限資源として設計する原則(アクセス日: 2026-07-07)

TODO・未確認事項

なし