Skip to Content
Docs02. 設計コンテキストエンジニアリング
中級context-engineeringmemory更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

コンテキストエンジニアリング

この記事の目的

LLM に渡すコンテキスト全体 — システムプロンプト・ツール定義・履歴・参照資料・作業状態 — を有限資源として設計できるようになります。「何を・いつ・どれだけ渡すか」の設計原則を持ち、品質・コスト・安定性を同時に改善する打ち手を選べる状態がゴールです。

対象読者

  • Agent の品質改善で「プロンプトの文言修正」以外の手段を持ちたいエンジニア
  • コンテキスト肥大によるコスト・品質問題に取り組むエンジニア

前提知識

本文

概要: プロンプトの「文言」から「構成」へ

コンテキストエンジニアリング(context engineering)とは、LLM の 1 回の呼び出しに渡される情報の全体を、構成要素の選択・配置・ライフサイクルとして設計する営みです。

プロンプトエンジニアリングモデルへの入力(指示・例・データ・形式)を設計して、出力の品質・形式・安定性を高める技法の総称。技法の効果はモデル世代で変わるため、評価で検証してから採用する。(指示文言の工夫)がコンテキストの一部を磨くのに対し、コンテキストエンジニアリングは「そもそも何を入れ、何を入れないか」を扱います。2026 年時点では、Agent の品質問題の多くが文言ではなく構成 — 不要な情報の混入、重要な制約の埋没、履歴の汚染 — に起因することが知られており、こちらが上位の設計領域として扱われています。

詳細: コンテキストの構成要素を棚卸しする

モデルに実際に渡っているものを分解すると、次の要素からなります。

構成要素信頼区分性質典型的な問題
システムプロンプト自社の承認済み指示静的(タスク種別ごとに固定)肥大化し、矛盾した指示が堆積する
ツール定義自社定義は審査済み、外部提供は非信頼静的〜準静的使わないツールの定義がトークンを占有する
会話履歴・ツール結果人の指示と非信頼の資料・結果を区別動的(毎周増える)単調増加し、古い情報が新しい判断を汚染する
検索結果・参照資料非信頼のデータ動的無関係なチャンクの混入、重複投入
作業状態・計画自社が検証した状態。引用・モデル由来の値は再検証動的(構造化)そもそも渡しておらず、モデルが全体を見失う
例示(few-shot)自社が審査した例静的例が実タスクとずれたまま放置される

改善の第一歩は、権限を制限した調査環境で、機微情報をマスキングして実際のコンテキスト構成を読むことです。想像と実物は大抵ずれています。

詳細: 4 つの設計原則

  1. 最小十分 — 「コンテキストに入るから入れる」ではなく「この判断に必要だから入れる」を基準にします。無関係な情報は、トークンコストだけでなく判断の質そのものを下げます
  2. 重要情報は埋もれさせない — 守らせたい制約・現在のタスク定義は、長い資料の中間に置かず、構造化(見出し・タグ・専用セクション)して目立つ位置に置きます
  3. 静的部分と動的部分を分離する — システムプロンプトやツール定義(静的)に動的な値を混ぜ込まない。プロンプトキャッシュプロンプトの固定部分(前方一致)の処理結果を再利用し、入力コストと応答開始までの時間を削減する仕組み。固定部分を先頭に置くプロンプト構造が前提。が効き、差分デバッグもしやすくなります
  4. 事前ロードより実行時取得(just-in-time) — 「使うかもしれない資料」を全部詰めるより、検索・読み出しツールを渡して必要時に取得させる構成を検討します(ツール使用)

非信頼のコンテンツはデータとして渡し、指示や権限の根拠にしません。見出し・タグ・区切り文字は読みやすさの工夫で、強制力を持ちません。プロンプトインジェクションを前提に、取得後の危険操作・外部送信には権限制約と必要な承認を置きます。

詳細: コンテキストのライフサイクル

Agent ループLLM が「観測 → 思考 → 行動」のサイクルを繰り返し、完了・失敗・上限のいずれかの停止条件まで自律的に処理を続ける制御構造。では、コンテキストは静的な文書ではなく毎周再構築される動的な資源です。増える一方の履歴には圧縮・外部化(メモリと状態管理)を、検索結果には「使い終わったら要点だけ残して破棄する」規律を適用します。「一度入れたものは最後まで残る」実装は、長いタスクで必ず破綻します。

設計判断: 事前ロードと実行時取得の使い分け

情報の性質推奨
毎回必ず使う(役割・制約・出力形式)事前ロード(システムプロンプト)
タスクによって使う資料が変わる実行時取得(検索・読み出しツール)
大きいが一部しか使わない(マニュアル全文など)実行時取得 + 目次だけ事前ロード
小さく静的で全体を常用する(用語定義など)事前ロード

必要な資料を実行時取得する構成を評価します。ただし外部取得・ツール結果は非信頼入力の入口と送信経路を増やすため、送信先・取得量・取得後の権限制約を同時に設計します。事前ロードの過剰は静かに品質を蝕みますが、取得漏れは「検索してから答えて」という改善可能な失敗として観測できるからです。

実務での注意点

アンチパターン

  • 「とりあえず全部入れる」 → 重要な制約が埋没し、コストは増え、品質はむしろ下がる → 要素ごとに「この判断に必要か」を問い、最小十分に絞る
  • システムプロンプトに動的情報(日時・ユーザー名・直近データ)を直接埋め込む → プロンプトキャッシュが効かず、バージョン管理・デバッグも困難になる → 動的情報は専用のメッセージ・構造化ブロックに分離する
  • 文言の改善だけを繰り返す → 実際に渡っている全体(履歴の汚染・無関係チャンク)を見ないまま、効果の薄い調整に時間を使う → コンテキスト全文をダンプして読む手段を最初に用意する

チェックリスト

  • 非信頼の入口を列挙し、その処理後の危険操作・送信に権限制約または承認がある
  • 実際に送信されるコンテキスト全文を確認する手段(ダンプ・トレース)がある
  • 各構成要素について「なぜ入っているか」を説明できる
  • 静的部分と動的部分が分離されている(キャッシュ境界が意識されている)
  • 重要な制約が構造化された目立つ位置にある
  • コンテキスト上限に近づいたときの挙動が定義されている
  • 大きい資料に just-in-time 取得を検討した

関連トピック

参考資料

TODO・未確認事項

Workflow 型 vs Agent 型の使い分けコンテキスト設計の実践パターン