コンテキスト・エンジニアリングとは、LLM に渡す情報の種類・構造・順序・量を総合的に設計する技術です。プロンプトの文言を磨くだけでは届かない精度の壁を、情報設計の観点から突破するアプローチとして注目されています。

対象読者は、AI プロダクトの開発者・プロンプト設計担当者・LLM を業務に組み込もうとしているエンジニアです。「プロンプトを改善しても回答精度が上がらない」「複雑なタスクで文脈が途切れる」といった課題を感じている方に特に役立つ内容となっています。

本記事では、コンテキスト・エンジニアリングの基本概念から、情報の選択・圧縮・配置という設計原則、そして実践的な導入ステップまでを体系的に解説します。読み終えた後には、自社の LLM 活用における情報設計の改善ポイントを具体的に把握できる状態を目指しています。

結論: コンテキスト・エンジニアリングとは、LLM に渡す情報全体を設計・最適化する技術であり、プロンプト単体の改善を超えた精度向上を実現する。

この概念は、プロンプトエンジニアリングとどう違うのか、「コンテキスト」が指す情報の範囲はどこまでか、そしてなぜ今注目されているのかという3つの観点から整理します。

最初は「プロンプトをもっと丁寧に書けば精度が上がる」と考えがちですが、実際にはプロンプトの文言よりも「何を・どの順番で・どれだけ渡すか」という情報設計全体のほうが、LLM の出力品質に大きく影響するケースが多くあります。

この認識の転換が、プロンプトエンジニアリングとコンテキスト・エンジニアリングの本質的な違いです。

両者の違いを整理すると、以下のようになります。

• プロンプトエンジニアリング: 指示文の書き方・構造・トーンを最適化する。主に「どう命令するか」に焦点を当てる
• コンテキスト・エンジニアリング: LLM に渡す情報全体（背景知識・会話履歴・ツール出力・外部データなど）の選択・圧縮・配置を設計する。「何を・どの形で渡すか」に焦点を当てる

たとえば、カスタマーサポートの自動応答を構築する場面を考えてみてください。プロンプトの言い回しをどれだけ洗練させても、顧客の過去の注文履歴や問い合わせ経緯がコンテキストに含まれていなければ、LLM は的外れな回答を返し続けます。問題の根本は「指示の質」ではなく「情報の欠落」にあるわけです。

LangChain チームは 2025 年 7 月に公開したブログ記事の中で、コンテキスト管理の主要戦略を「Write / Select / Compress / Isolate」の 4 つに分類しています。これはプロンプトの最適化とは明確に異なる設計レイヤーです。

コンテキストとは、LLM が推論を行う際に参照できるすべての情報を指します。プロンプトに書いたテキストだけでなく、より広い範囲の要素が含まれます。

コンテキストを構成する主な要素は以下の通りです。

• システムプロンプト: モデルの役割・制約・出力形式など、タスク全体を規定する指示
• ユーザー入力: 会話の直近のメッセージや質問
• 会話履歴: 過去のやり取りのログ（ターン数が増えるほど消費トークンも増加）
• 外部知識: RAG で取得したドキュメント、データベースの検索結果、API レスポンス
• ツール定義・実行結果: エージェント構成における関数スキーマや呼び出し結果
• 構造化メモ: 長期タスクで蓄積される中間状態や要約（Anthropic が "structured note-taking" と呼ぶ手法）

タスクが単純な Q&A であれば、システムプロンプトとユーザー入力だけで十分なケースが多いです。一方、複数ステップにまたがるエージェントタスクの場合は、会話履歴・ツール実行結果・外部知識を組み合わせて管理する必要があります。どの要素をコンテキストに含めるかは、タスクの複雑さと要求される精度によって変わります。

重要なのは、これらすべてがトークンウィンドウという有限のリソースを共有している点です。Google Cloud の公式情報によれば、現行モデルでは 100 万〜200 万トークンのウィンドウが利用可能になっていますが、無制限ではありません。

「プロンプトをいくら磨いても、なぜか精度が上がらない」——そう感じた経験がある開発者は少なくないはずです。コンテキスト・エンジニアリングへの注目が高まった背景には、LLM の性能進化と実務要件の複雑化という二つの潮流があります。

注目を集めた主な要因は以下の通りです。

• コンテキストウィンドウの大幅拡張: Google Cloud の公式情報によれば、現行モデル（例: Gemini 3.1）は 100 万〜200 万トークンのコンテキストウィンドウに対応しています。扱える情報量が増えた分、「何を入れるか」の設計が精度を左右するようになりました
• エージェント型 AI の普及: 単発の質問応答から、複数ステップにわたる自律的なタスク実行へとユースケースが移行しています。Anthropic が 2025 年 9 月に公開した技術記事では、長期タスク向けの文脈圧縮（compaction）や構造化ノートといった手法が紹介されており、情報設計の重要性が改めて示されました
• コスト最適化の観点: Google Cloud の公式情報によれば、コンテキストキャッシュの活用によって最大 90% のコスト削減が見込めるとされており、情報設計はパフォーマンスだけでなく運用コストにも直結する課題となっています

LangChain チームが 2025 年 7 月に公開したブログでも、コンテキスト管理を「Write / Select / Compress / Isolate」の 4 戦略として体系化しており、業界全体で共通言語が形成されつつあります。

結論: プロンプトの文言を磨くだけでは、LLM が必要とする情報を適切に受け取れず、精度向上には構造的な限界がある。

トークンウィンドウの制約、文脈の欠落、複雑タスクへの対応不足——これら三つの問題は、プロンプト単体の改善では解消しにくい。各 H3 でその理由を具体的に掘り下げる。

コンテキストウィンドウが広がれば、すべての情報を詰め込めばよいと考えがちです。しかし実際は、無差別に情報を増やすほど LLM の回答精度が下がるケースが報告されています。

問題の核心は情報密度にあります。トークンウィンドウとは、モデルが一度に処理できる文字・単語の上限量を指します。Google Cloud の公式情報によれば、現行の主要モデルは 100 万〜200 万トークンという広大なウィンドウを持つものも登場しています。しかし、ウィンドウが広いことと、その中の情報を正確に活用できることは別の話です。

具体的には、以下のような問題が起きやすくなります。

• 重要情報の埋没: 大量のテキストの中に核心的な指示や事実が埋まると、モデルがそれを見落とす傾向がある
• ノイズによる混乱: 関連性の低い情報が多いほど、モデルが誤った根拠を参照するリスクが高まる
• コストの増大: 不要なトークンを送り続けると API コストが膨らむ一方、精度は向上しない

LangChain チームが 2025 年 7 月に公開したブログでは、コンテキスト管理の戦略として「Write / Select / Compress / Isolate」という 4 つの分類を提示しています。単に情報を追加する（Write）だけでなく、選択・圧縮・分離という操作が不可欠だという考え方です。

トークンウィンドウは「容量」ではなく「舞台」と捉えるのが適切です。舞台に不要な小道具を並べるほど、主役の演技が霞んでしまいます。

文脈が欠落したとき、LLM は「知らない」と答えるのではなく、不完全な情報から「それらしい回答」を生成してしまう点が問題です。

誤回答が発生しやすいパターンは主に次の3つです。

• 代替情報による補完: 必要な情報が渡されていないと、LLM は学習データの中から「最も近い知識」で空白を埋める。結果として、実際の仕様とは異なる古い情報や一般論が回答に混入する
• 指示の意図を誤解する: 背景情報がないまま曖昧な指示を受けると、LLM は複数ある解釈のうち「統計的に多い解釈」を選ぶ。担当者が意図したニュアンスとずれた回答が返ってくる
• 前後の会話を参照できない: 長い対話の中でウィンドウの外に押し出された情報は参照されず、矛盾した回答や繰り返しが発生する

条件分岐の観点で整理すると、タスクが単発の質問応答であれば欠落の影響は小さく抑えられますが、複数ステップにまたがるタスクや専門ドメインの判断を伴う場合は、文脈の欠落が連鎖的に誤りを拡大させる傾向があります。

これらのパターンに共通するのは、「モデルの能力不足」ではなく「情報設計の不備」が原因だという点です。渡す情報の種類・順序・粒度を適切に設計することで、同じモデルでも回答品質が大きく変わります。プロンプトの言い回しを調整する前に、まずコンテキストに何が欠けているかを診断することが精度向上への近道です。

「プロンプトを工夫し続けているのに、タスクが複雑になるほど出力がブレる——なぜだろう？」と感じた経験はないでしょうか。

「要件定義→設計→コード生成→テスト仕様作成」を一連の流れで処理させようとすると、プロンプト設計の限界が顕在化しやすくなります。理由は大きく三つあります。まず、単一のプロンプトは「今どのステップにいるか」という状態を保持できないため、ステップが進むにつれて前の文脈が失われ、矛盾した出力が生まれやすくなります。次に、前のステップの出力を次のステップの入力として動的に渡す仕組みがなく、ユーザーが手動で貼り直す運用になりがちです。さらに、複数の制約や役割を一つのプロンプトに詰め込むと、モデルがどの指示を優先すべきか判断できず、曖昧な回答を返す傾向があります。

Anthropicが公開した技術記事でも、長期タスクにおける文脈管理の重要性が強調されており、サブエージェントが最終的に1,000〜2,000トークン程度の要約を返す構成が紹介されています。これはプロンプト単体ではなく、情報の構造と受け渡し方を設計することで初めて複雑なタスクに対応できることを示す好例です。

プロンプト設計はあくまで「一回の問いかけ」を最適化する技術です。複雑なタスクに必要なのは、情報をどう選び、どう圧縮し、どのタイミングでモデルに渡すかという設計——すなわちコンテキスト・エンジニアリングの視点です。

「何を渡すか」だけでなく、「どの順で」「どの量だけ」LLMに渡すか——コンテキスト・エンジニアリングとは、この三つを体系的に設計する技術である。

以降では、コンテキストを構成する要素の整理から、情報の選択・圧縮・配置という設計作業、さらにRAGやメモリ管理との関係まで、全体像を順に解説する。

コンテキストは「プロンプト本文だけ」と考えがちですが、実際にはLLMの出力品質を左右する情報源はもっと広い範囲に及びます。LangChainが整理したコンテキスト設計の概念を参考に、構成要素を以下の5つに分類できます。

• システムプロンプト: AIの役割・制約・出力フォーマットを定義する土台。ここが曖昧だと後続の情報がどれだけ正確でも出力がブレやすくなります
• ユーザー入力: 実行時にユーザーが与える指示や質問。意図が不明瞭なほど誤回答のリスクが高まります
• 外部知識（RAGで取得した文書など）: タスクに必要なドメイン情報や最新データ。社内ドキュメントやデータベースからの検索結果がここに相当します
• 会話履歴・メモリ: 過去のやり取りや中間結果。Anthropicの事例では、長期タスクで会話を要約・圧縮する「compaction」手法により、コンテキストウィンドウを効率的に管理しています
• ツール出力・構造化データ: コード実行結果、API レスポンス、スプレッドシートなど、エージェントが取得した構造化情報

これら5要素は互いに補完関係にあります。たとえば外部知識を充実させても、会話履歴に矛盾する前提が残っていると、LLMはどちらを優先すべきか判断できず出力が不安定になります。

設計上の重要な観点は、各要素の「鮮度」と「関連性」を常に意識することです。古い情報や無関係なデータを混入させると、情報密度が下がり精度が低下します。

コンテキスト設計の実務は、「選択」「圧縮」「配置」の3つの作業に分解できます。それぞれが独立した判断軸を持ち、どれか一つを疎かにすると精度が落ちます。

選択：何をコンテキストに含めるか

タスクに無関係な情報を含めるほど、モデルは本質的な情報を見つけにくくなります。選択の基準は「このタスクの回答に直接影響するか」という一点に絞ります。

• 関連度の高い文書・履歴のみを絞り込む
• ユーザーの発話意図に合わせてフィルタリングする
• 不要な前提説明や冗長な例示は除外する

圧縮：情報をどう凝縮するか

LangChain の整理では、コンテキスト管理の戦略として「Compress（圧縮）」が独立した設計作業として位置づけられています。長い会話履歴やドキュメントは要約・箇条書き化によってトークンを節約しつつ、意味の密度を保つことが目標です。タスクが単発の質問応答であれば簡易な要約で十分ですが、長期にわたるエージェント処理の場合は Anthropic が示す compaction（会話要約による文脈圧縮）のような段階的な圧縮が有効です。

配置：どの順序で渡すか

同じ情報でも、渡す順序によってモデルの注意の向き方が変わります。一般的に、最も重要な情報は冒頭か末尾に置くと参照されやすい傾向があります。

「RAG を導入したのに、なぜか回答の質が安定しない」と感じた経験はないでしょうか。その原因の多くは、RAG 自体の問題ではなく、取得した情報をコンテキストにどう組み込むかという設計の問題に起因しています。

RAG（検索拡張生成）とメモリ管理は、コンテキスト・エンジニアリングの主要な実装手段に位置づけられます。両者の関係を整理すると次のようになります。

• RAG: 外部知識ベースから関連チャンクを動的に取得し、コンテキストに「書き込む（Write）」操作に相当する
• メモリ管理: 過去の会話履歴や中間状態を保持・圧縮し、必要な情報だけを「選択（Select）／圧縮（Compress）」してコンテキストに渡す操作に相当する

LangChain チームは、コンテキスト管理の主要戦略を「Write / Select / Compress / Isolate」の 4 軸で整理しています。この枠組みで見ると、RAG は Write 戦略の代表例であり、メモリ管理は Select と Compress の組み合わせとして機能します。

Anthropic の技術記事では、長期タスク向けのエージェント設計において「compaction（会話要約による文脈圧縮）」と「structured note-taking（構造化ノートによる記憶管理）」が重要な技術として挙げられています。サブエージェントが最終的に 1,000〜2,000 トークン程度の要約を返す構成も紹介されており、これはまさにコンテキスト圧縮の実装例です。

結論: コンテキスト設計に関する誤解を放置すると、改善施策が的外れになる。

コンテキスト・エンジニアリングには「プロンプトを長くすれば十分」「ファインチューニングで代替できる」といった誤解がつきまとう。各 H3 でそれぞれの誤解を整理し、正しい設計判断の指針を示す。

プロンプトを長くすれば精度が上がる、と最初は考えがちです。しかし実際は、情報量を増やすよりも「何を・どの順で・どれだけ渡すか」を設計するほうが効果的なケースが多く報告されています。

長いプロンプトが逆効果になる主な理由は次の3点です。

• 注意の希薄化: トークン数が増えるほど、モデルの注意機構が重要な情報に集中しにくくなる傾向があります
• ノイズの混入: 関連性の低い情報が増えると、モデルが誤った手がかりを参照するリスクが高まります
• コスト・レイテンシの増大: 不必要に長い入力は処理コストと応答時間を押し上げます

Google Cloud の公式ページでは、現行モデル（例: Gemini 3.1）が100万〜200万トークンのコンテキストウィンドウに対応する一方、コンテキストキャッシュによる最大90%のコスト削減も紹介されています。ウィンドウが広がったことで「詰め込めば解決する」という発想が生まれやすくなっていますが、コスト最適化の観点からも、不要な情報を削ぎ落とす設計が重要です。

LangChain チームが提唱する "Write / Select / Compress / Isolate" のフレームワークでも、Select（必要な情報だけを選ぶ） と Compress（圧縮して密度を上げる） が独立したステップとして位置づけられています。これは、量の増加ではなく質の最適化こそがコンテキスト設計の核心であることを示しています。

プロンプトの長さは手段であり、目的ではありません。

ファインチューニングは「モデルの知識や振る舞いを更新する」技術であり、コンテキスト・エンジニアリングとは目的が根本的に異なります。この区別を曖昧にしたまま「ファインチューニングすれば精度が上がるはず」と進めると、コストと時間を費やしても期待した効果が得られないケースが少なくありません。

両者の役割を整理すると、次のように分かれます。

• ファインチューニング: モデル自体のパラメータを更新し、特定のトーン・形式・ドメイン語彙への適応を強化する
• コンテキスト・エンジニアリング: 推論時に渡す情報の構造・順序・密度を最適化し、モデルが正しく推論できる状況をつくる

誤回答の原因が「必要な情報がコンテキストに存在しない」または「情報の提示順が不適切」である場合、ファインチューニングでは根本解決になりません。モデルがいくら学習しても、推論時に渡されていない情報を正確に補完することは難しいためです。

判断軸としては、タスクごとに最新情報や外部データが必要な場合はコンテキスト設計で対応し、モデルの出力スタイルや専門語彙の定着が目的の場合はファインチューニングが有効です。多くの実務課題は前者に該当するため、まずコンテキスト設計の改善を先に試みることが合理的な順序といえます。

ファインチューニングはコストと学習データの準備が伴う重い施策です。コンテキスト・エンジニアリングによる改善を先に尽くしてから、それでも解決しない部分に限定して検討するアプローチが、現場での費用対効果を高める上で現実的です。

「コンテキスト設計はエンジニアのタスクだから、自分には関係ない」——そう思っているビジネス担当者やプロダクトオーナーは少なくないでしょう。しかし実際には、コンテキスト設計の質を左右する判断の多くは、ドメイン知識を持つ非エンジニアにしか下せません。

コンテキスト設計には、大きく分けて2種類の意思決定が伴います。

• 技術的な実装判断：トークンの圧縮方法、RAG の検索ロジック、メモリ管理の仕組みなど
• 情報設計の判断：どの情報をAIに渡すべきか、どの順序で提示するか、何を省くか

後者は業務プロセスや顧客対応の文脈を理解していないと決められません。たとえば、カスタマーサポート向けのAIを構築する場合、「よくある問い合わせのどのカテゴリを優先するか」「回答に含めるべき注意事項は何か」といった判断は、現場担当者や業務企画者が主導すべき領域です。

エンジニアが「何でも渡せる」状態を作ったとしても、渡す情報の取捨選択を誤れば、AIの出力品質は上がりません。情報設計の誤りは、プロンプトの書き方を工夫しても補いきれない根本的な問題になりえます。

実践的には、以下のような役割分担が機能しやすい傾向があります。

• 業務担当者・PO：渡すべき情報の優先順位付け、ユースケース定義、出力品質の評価
• エンジニア：情報の取得・圧縮・注入の実装、パフォーマンス最適化

コンテキスト・エンジニアリングをチーム全体の設計活動として捉え直すことが、LLM 活用の精度を底上げする第一歩になります。

結論: LLM の精度向上は、コンテキストの「何を・どこに・どう置くか」という設計原則に依存する。

情報の配置順序・密度・動的な切り替えの3点が、回答品質を左右する主要な設計変数です。各原則の詳細は以降の H3 で解説します。

「とにかく情報を詰め込めば精度が上がる」と考えがちですが、実際はコンテキストの配置順序が回答品質を大きく左右します。

LLM はコンテキストウィンドウ全体を均等に参照するわけではなく、入力の前半に置かれた情報をより強く参照する傾向があります。これは「プライマシー効果」として知られており、長いコンテキストの中盤に埋もれた情報は見落とされやすいことが実験的に報告されています。

この特性を踏まえると、設計の基本原則は自然と決まってきます。まずタスク定義・制約・ゴールを最前段に置き、モデルが何をすべきかを最初に把握できるようにします。次に最も関連度の高いドキュメントや事実を続け、RAG で取得した参照文書は冒頭寄りに配置するのが基本です。補足情報や背景知識は後段にまとめます。必須でない情報を前段に置くとノイズになるためです。また、例示（few-shot）はタスク定義の直後に配置すると、手順の直前に文脈が揃い、モデルが引き継ぎやすくなります。

たとえば、社内文書を参照して回答するチャットボットを設計する場合、システムプロンプトの冒頭に「回答範囲・トーン・禁止事項」を明記し、その直後に検索で取得した関連チャンクを配置します。ユーザーの質問文はその後に続ける構成が、回答の一貫性を高めやすいとされています。

コンテキストに含める情報が多ければ多いほど精度が上がる、という考え方は必ずしも正しくありません。無関係な情報や冗長な表現が混入すると、LLM は本来注目すべき情報を見落としやすくなります。

ノイズ除去の基本は「タスクに関係しない情報を物理的に取り除く」ことです。具体的には次の観点で整理します。

• 重複排除: 同じ事実が複数箇所に書かれている場合、1 か所に集約する
• 不要な前置き・免責文の削除: 「本ドキュメントは〜を目的として作成されました」のような定型文はモデルにとって意味を持ちにくい
• メタ情報の取捨選択: ファイル名・更新日・作成者などは、タスクに必要な場合のみ残す

情報密度を高めるうえで有効なのが、LangChain が提唱する「Compress（圧縮）」戦略です。長い文書を要約してからコンテキストに挿入することで、限られたトークン枠の中に本質的な情報だけを詰め込めます。

判断の基準として、タスクが単一ドキュメントの参照で完結する場合はフル挿入でも問題になりにくいですが、複数ソースを組み合わせる場合は各ソースを事前に圧縮してから渡すことを検討してください。後者では、圧縮しないままトークンを消費すると、後半のソースが実質的に参照されにくくなるリスクがあります。

また、箇条書きや見出しを使った構造化フォーマットも情報密度の向上に寄与します。散文よりも構造化されたテキストのほうが、モデルが情報を参照しやすい傾向があります。

「同じシステムプロンプトで全タスクをこなしているのに、なぜ特定の質問だけ精度が落ちるのだろう？」という疑問は、多くの開発現場で共有されています。その原因の多くは、コンテキストが静的に固定されていることにあります。

動的コンテキスト生成とは、ユーザーの入力内容やタスクの種類に応じて、LLM に渡す情報を実行時に組み替える設計アプローチです。固定のプロンプトではなく、状況に合わせて必要な情報だけを選び出してコンテキストを構築します。

具体的には、以下のような切り替えが該当します。

• タスク種別による切り替え: 要約タスクには文書全体、Q&A タスクには検索で絞り込んだ関連チャンクのみを渡す
• ユーザー属性による切り替え: 初心者向けには基礎説明を、上級者向けには詳細仕様を優先して挿入する
• 会話履歴の圧縮と選択: 長期の対話では全履歴ではなく、直近の重要なやり取りと要約のみを保持する

LangChain が提唱する「Write / Select / Compress / Isolate」という分類も、この動的な情報管理を体系化したものです。特に「Select（選択）」と「Compress（圧縮）」の組み合わせが、タスクに応じた切り替えの核心となります。

実装上の注意点として、切り替えロジックが複雑になるほどメンテナンスコストが上昇する傾向があります。まずは「タスク種別が 2〜3 種類に絞れるか」を確認し、シンプルな条件分岐から始めるのが現実的なアプローチです。

概念を理解したら、次は実装に落とし込む段階だ。課題の診断からコンテキスト構造の設計・実装まで、2つのステップで具体的な進め方を解説する。

最初は「プロンプトをもっと丁寧に書けば精度が上がる」と考えがちですが、実際には課題の根本がコンテキスト設計にある場合、プロンプトの書き直しを繰り返しても改善は頭打ちになります。まず診断によって「何が問題か」を特定することが、次のステップへの最短経路です。

診断では、以下の観点でプロンプト設計の現状を棚卸しします。

• 情報の欠落: LLM が回答に必要な背景情報（業務ルール・用語定義・過去の会話など）を受け取れているか
• 情報の過多・ノイズ: 関係のない情報が混入し、モデルの注意が分散していないか
• 配置の問題: 重要な指示や参照情報がプロンプトの末尾に置かれ、前段の長い文章に埋もれていないか
• 文脈の非一貫性: 複数のターンやエージェント間で、前提となる情報が引き継がれているか

具体的な診断手順としては、まず実際に誤回答や精度低下が起きたケースのログを一定数収集します。次に各ケースで「モデルが持っていたコンテキスト」と「正しい回答に必要だったコンテキスト」のギャップを言語化します。このギャップが繰り返し同じパターンで現れる場合、それが設計上のボトルネックです。

診断結果は簡単な表形式で整理すると、次の設計フェーズに引き渡しやすくなります。

Step 1 の診断で課題が明確になったら、次はコンテキスト構造を具体的に設計・実装する段階です。

設計の基本は、LangChain チームが提唱する「Write / Select / Compress / Isolate」の 4 操作を軸に考えることです。

• Write（書き込み）: 会話履歴や中間結果を構造化ノートとして保存し、後続ステップで参照できる形にする
• Select（選択）: RAG やメモリストアから、現在のタスクに関連する情報だけを絞り込む
• Compress（圧縮）: Anthropic が推奨する compaction（会話要約）のように、不要なトークンを削減して情報密度を高める
• Isolate（分離）: サブエージェントにサブタスクを委譲し、メインコンテキストへのノイズ混入を防ぐ

タスクの性質によって重点を変えることが重要です。単発の Q&A タスクであれば Select と Compress を優先し、長期にわたるエージェント型タスクであれば Write と Isolate を中心に設計するとよいでしょう。

実装時は、まず小さな単位で試すことを推奨します。

1. 既存プロンプトの先頭にシステムコンテキスト（役割・制約・出力形式）を明示的に分離して配置する
2. 関連ドキュメントを RAG で動的に挿入し、静的な長文プロンプトを置き換える