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

学習目標

• コンテキストウィンドウの予算とコンテキスト劣化の意味を説明し、1リクエストの予算表を作る。
• 質問から必要な情報を逆算し、必要な資料だけを選ぶ。
• 長い文書と質問を品質が高まる順序に配置し、文書に出典とバージョンを付ける。
• 長い文書では先に根拠を引用させ、結論を十分に支える引用か確認する。
• 会話の要約・圧縮と検索拡張の原理を説明し、検索の失敗と回答の失敗を分けて診断する。
• 信頼できない外部の内容を、指示と分離して配置する。

はじめに

あるコンサルティング会社の分析担当者が、年次報告書5件を丸ごと入れ、「今年の業界の主要な変化を3つ」と尋ねました。コンテキストウィンドウは十分に大きく、リクエストはエラーなく処理されました。ところが、回答に挙がった3つのうち1つは、3件目の報告書の付録にある脚注1行を誇張したものでした。しかも、5件の報告書が共通して強調していた変化は抜けていました。分析担当者は「全部入れたのに、なぜ見落としたのか」と尋ねました。答えは、その問いの中にあります。全部入れたから、見落としたのです。モデルが脚注を創作したわけではありません。何が重要かを見分ける手がかりなしに数十万トークンを受け取り、広いウィンドウの中で、無関係な脚注が重要な情報と同じ場所を奪い合っていただけです。

この章では、指示文の外側、つまりモデルが一度に見るものすべてを扱います。コンテキストが限られた資源である理由から始め、予算表の作り方、必要な情報だけを選ぶ方法、文書のメタデータと配置順序、先に引用を得る方法と引用機能、検索拡張の原理と失敗の診断、会話の要約と圧縮、長時間働くエージェントの戦略、プロンプトキャッシュ、信頼できない内容の置き場所を順に見ていきます。「さらに深く」では、長いウィンドウと検索のどちらを選ぶか、ツールの設計、会話状態をサーバーに任せる際の注意点を扱います。

重要な概念

コンテキストは机の上の空間

広い机には書類をたくさん広げられますが、多いほど今必要な1枚を探しにくくなります。Anthropicはコンテキストウィンドウ（context window）を、応答時に参照する全テキストと応答自体を入れる、学習データとは異なる「作業記憶」と説明し、大きければ自動的によくなるわけではないと強調しています。出力も同じウィンドウで数えるかはベンダー・モデルで異なります。トークンが増えるほど正確さと想起能力が下がる**コンテキスト劣化（context rot）**があるためです。

Anthropicのコンテキストエンジニアリングの記事は、これを注意力の予算と説明します。Transformerでは全トークンがほかの全トークンと関係するため、n個なら関係はn²に増え、新たなトークンごとに有限の注意力を分け合います。目標は「望む結果の確率を最大にする、できるだけ小さく信号密度の高いトークン集合」、すなわち有用な情報が詰まった最小の集合です。プロンプトエンジニアリングが指示文を整える仕事なら、コンテキストエンジニアリングはモデルが見る全トークンを毎回選ぶ仕事です。

コンテキストウィンドウの予算表

予算を組むには、まず何がウィンドウを占めるかを知る必要があります。Anthropicのドキュメントによると、システムプロンプト、messages内のすべてのメッセージ（ツール結果、画像、文書を含む）、ツール定義、そしてモデルがそのターンに生成する出力（思考を含む）が、すべてウィンドウに入ります。プロンプトキャッシュから読み込んだトークンも、ウィンドウを占めます。キャッシュは料金を下げるだけで、ウィンドウの空きを増やすわけではありません。トークン数は言語や表記によって異なるため、韓国語の資料でも文字数で概算せず、トークン計数機能を使って実際の入力を測ってみます。

出力のための余裕は、特に忘れられがちです。ウィンドウが広くても、1回のリクエストの出力には別の上限があります。Anthropicのドキュメントによると、100万トークンのウィンドウを持つ最新モデルでも、1回のリクエストの出力は最大128k（約12万8千）トークンです。長い報告書全体を書き直させると、入力は収まっても、出力が上限に達して途切れ、stop_reasonはmax_tokensになります。公式ドキュメントは、上限を上げるか、続けて生成するよう案内しています。成果物が長くなるタスクでは、最初から区間を分け、用語集のような共通基準を区間ごとに一緒に入れます。

必要な情報だけ選ぶ

資料を入れる前に、質問から逆算します。

1. 質問を下位の論点に分ける。 「下半期の価格戦略のリスク」を原価変動、競合価格、需要変動に分ける。
2. 論点ごとに必要な資料を書く。 原価には仕入単価表、競合価格には9月の価格調査を対応させる。
3. 必須と補助を分ける。 ないと答えが誤る資料と、あると豊かになる資料を分ける。
4. 原文か抜粋か選ぶ。 条項比較など文言が重要なら原文、背景説明なら抜粋・要約とする。
5. 予算を超える場合は、補助資料から外す。 外す順序を、あらかじめ決めておく。
6. 根拠のない論点を明示する。 資料がない論点については、モデルにも「資料なし」と伝え、一般知識で補わないようにする。

費用削減だけが目的ではありません。別製品、別年度、別部署の資料が混ざれば、それ自体が誤答の材料になります。

文書に出典・バージョン・適用範囲を付ける

内容だけを入れても、モデルには、どの文書が最新で、どの文書がどこに適用されるのかわかりません。文書ごとにメタデータを付けます。

<documents>
  <document index="1">
    <source>出張費規程第4条</source>
    <version>2026-07-01改定</version>
    <applies_to>正社員、国内出張</applies_to>
    <document_content>{{RULE_4}}</document_content>
  </document>
  <document index="2">
    <source>出張費規程第4条</source>
    <version>2025-01-01改定（廃止済み）</version>
    <applies_to>2026-06-30以前の出張精算にのみ適用</applies_to>
    <document_content>{{RULE_4_OLD}}</document_content>
  </document>
</documents>

Anthropicのガイドは、複数の文書を入れる場合、各文書を<document>で囲み、<document_content>や<source>などの下位タグで、内容とメタデータを分けるよう勧めています。改定日、施行日、適用対象は、モデルが「どの文書に従うべきか」を判断する根拠になります。メタデータがなければ、同じ条項の新旧バージョンが一緒に検索されたときに、モデルが両方を混ぜて答える可能性があります。

メタデータは、文書同士の内容が一致しないとき、さらに重要になります。単に「総合せよ」と指示すると、モデルは矛盾する内容を1文に無理にまとめたり、片方を黙って捨てたりします。共通して確認できる内容、数値や定義が異なる内容、一方にしかない内容を分けて整理させ、解決のルールを定めます。たとえば、「同じ条項の新旧バージョンなら、質問の基準日に施行されているほうに従う」とします。ルールで解決できない矛盾は、解決しようとせず、「矛盾：文書1と文書3が異なる」と報告させます。

長い文書は前、質問は最後

Anthropicは、2万トークンを超える長い入力では、長い文書を質問・指示・例よりも前に置くよう勧めています。公式のテストでは、質問を最後に置くと、特に複雑な複数文書の入力で、応答の品質が最大30%向上しました。Geminiのガイドも、具体的な質問をいちばん最後に置き、「上の情報に基づいて」のように、前の資料とつなぐ表現を使うよう勧めています。OpenAIのガイドは、リクエストごとに変わるコンテキストを末尾近くに置く構成を例示しています。画像も同様です。Anthropicのドキュメントは、画像をテキストよりも先に置き、複数ある場合は「Image 1:」「Image 2:」のようにラベルを付け、名前で参照するよう案内しています。

公式の推奨は出発点であって、すべてのタスクに当てはまる法則ではありません。中核となる行動制約を前に、長い資料をその後に、具体的な質問をいちばん最後に置く構成を基本とし、重要なタスクでは、配置を変えた版と比較して確かめます。

先に引用を得る

長い文書から回答を得るとき、最大の危険は、文書にない内容が混ざることです。公式ガイドは、作業に入る前に、関連する箇所をまず引用させるよう勧めています。モデルは引用を選ぶ過程で関連する内容に集中し、人は引用と原文をすぐに照合できます。Anthropicのハルシネーション低減ドキュメントは、さらに2つの方法を加えています。関連する引用がなければ、ないと明示させること。そして、回答を書いた後、主張ごとに裏付けとなる引用を探させ、見つからなかった主張は撤回させることです。

1. 質問に関連する原文を<quotes>内に番号付きでそのまま転記する。
   関連文がなければ「関連する引用なし」とだけ書く。
2. <quotes>内だけを根拠として<answer>に答え、主張ごとに引用番号を付ける。
3. 引用番号を付けられない主張は除く。

引用があっても十分な根拠とは限りません。さらに3点を確認します。

引用機能と検索結果ブロック

プロンプトによって引用を得る代わりに、ベンダーの引用機能を使うこともできます。AnthropicのCitations機能は、文書の引用を有効にすると、引用した部分のテキストブロックに、原文での位置（一般のテキストは文字位置、PDFはページ番号、カスタムブロックはブロック番号）を付けて返します。引用なしで出された主張があるかどうかは、別に確認します。公式ドキュメントが挙げる利点は3つです。引用されたテキスト（cited_text）は出力トークンに数えられないこと、APIが引用を解析するため、提供された文書を指す有効な位置が保証されること、そして自社の評価では、プロンプト方式よりも関連性の高い文を引用したということです。

平文とPDFは文単位で引用します。書き起こしや箇条書きで単位を自分で決めるなら、カスタムブロックにします。構造化出力とは併用できず、引用を有効にした文書とoutput_config.formatを同じリクエストに入れると400エラーです。両方必要なら呼び出しを分けます。

自社検索結果はAnthropicのsearch_resultブロック（出典、題名、内容）に入れると、ウェブ検索のような出典付き引用を得られます。GeminiのGoogle検索グラウンディングは、モデルが検索の要否を判断して検索し、応答区間ごとに出典URLを付けます。頻繁に変わる公開情報には検索グラウンディング、社内資料には社内検索結果を使い、併用時は文ごとに根拠の種類を区別します。

検索拡張の仕組み

検索拡張生成（RAG、retrieval-augmented generation）は、モデルが知らない資料を、質問された時点で探して入れる方法です。図書館の司書が質問を聞き、関係のある本を数冊だけ選んで机に載せてくれる様子に似ています。

AnthropicのContextual Retrievalの記事は、第1段階の問題を指摘しています。文書を切り分けると、「売上が前四半期より3%増えた」といった断片から、どの会社の、どの期間の話なのかが失われます。解決策は、断片ごとに文書全体を参照した短い説明（通常50〜100トークン）を付けて埋め込みを作り、同じテキストでBM25のインデックスも作ることです。埋め込み検索は、意味が似た文章を探すことには強い一方、エラーコードやモデル名のように文字が厳密に一致する必要がある検索語には弱く、単語の一致に基づくBM25が、その弱点を補います。記事の実験では、検索の失敗率は、文脈付きの埋め込みだけで35%、BM25を加えると49%、さらに再ランキングを加えると67%減りました。

すべての問題に検索が必要なわけではありません。同じ記事は、知識ベースが20万トークンより小さければ、検索段階を作らず、資料全体を入れたうえで、プロンプトキャッシュによって費用と遅延を減らしてもよいと説明しています。資料が小さい場合は、最も単純な方法が、最もよい方法かもしれません。

検索の失敗と回答の失敗を分ける

RAGが誤答したとき、まずプロンプトを直すのはよくある誤りです。まずどの段階で失敗が生じているかを切り分けます。

1. 正解の根拠が保存先にあったか。 なければ資料の問題である。
2. 検索結果の上位に、正解の根拠があったか。 なければ検索の問題である。クエリ生成、インデックス、検索方式を修正する。
3. 根拠がコンテキストに入ったか。 再ランキングや選別で落ちたなら基準を直す。
4. 根拠が入っていたのに、回答が間違っていたか。 この段階で初めて、生成段階、つまり指示・配置・引用の方法を修正する。

判別には、質問と正解の根拠文書をあらかじめ対応させた評価セットが必要です。第5章で扱う評価セットの用途の1つです。

会話の要約と圧縮

会話が長くなると、履歴を減らす必要があります。最もよく使われる方法は前半を要約することですが、要約では細かな文言が失われます。特に要約を何度も繰り返すと、数値、日付、条件が「適切な水準」「近いうちに」のような表現に丸められてしまいます。そのため、要約は「あらすじ」ではなく、「業務状態の記録」として設計します。

<conversation_state>
  確定条件：納品数量1,200個、納期11月14日、個別ビニール包装
  未解決の質問：ロゴ印刷色（顧客が見本確認後に返信予定）
  決定履歴：10月20日に単価合意（見積書Q-2026-118）
  次の行動：見本への返信が来たら印刷仕様を確定
</conversation_state>

確定値は元の表現で残し、決定と提案を分け、各項目の由来をたどれるようにします。直近数ターンを原文で残し、会話の流れを保ちます。

ベンダーの機能を使うこともできます。Anthropicは、サーバー側の圧縮（compaction）をベータ版として提供し、古いターンをモデルが書いた要約に置き換えて、会話を続けられるようにしています。標準の要約で必要な情報が抜け落ちる場合は、自分で要約用の指示を書きます。さらに細かく制御する場合は、コンテキスト編集機能を使い、古いツール結果や思考ブロックを、ルールに沿って削除します。何を必ず残すべきかは、業務担当者が決めます。

長時間働くエージェントの戦略

何時間にもわたってツールを呼び出すエージェントは、コンテキストがすぐに埋まります。Anthropicの記事が紹介する手法と、それぞれに適した状況は、次のとおりです。

必要時の読み込みは遅いものの、古い索引の問題を避け、コンテキストを軽く保ちます。一部を先に入れ、残りは必要時に探す混合方式もあります。

プロンプトキャッシュと配置

プロンプトキャッシュは、リクエストごとに共通するプレフィックス（先頭部分）を保存して次のリクエストで再利用する機能です。要点は先頭部分が一字一句同じであることです。Anthropicはtools、system、messagesの順でプレフィックスを構成し、キャッシュ地点まで100%同一ならヒットします。OpenAIも対応モデルでは既定で有効にし、レンダリング後の先頭部分全体が一致すれば再利用します。

費用の仕組みも把握しておきます。Anthropicのドキュメントによると、キャッシュへの書き込みは通常の入力料金より少し高く（5分キャッシュは1.25倍）、キャッシュからの読み込みは、はるかに安くなります（大半のモデルで通常の入力料金の10%）。標準の有効期間は5分で、使うたびに更新され、1時間という選択肢もあります。OpenAIは、最新モデルでは1,024トークン以上のプロンプトをキャッシュし、キャッシュによって出力の生成方法は変わらないと説明しています。

信頼できない内容の位置

ウェブページ、受信メール、ユーザーがアップロードしたファイル、ツール結果のように、制御できない出所の内容には、モデルを操ろうとする文が潜んでいることがあります。これを、間接プロンプトインジェクションと呼びます。ユーザーが直接攻撃する直接インジェクションとは異なり、ユーザーは信頼できても、モデルが代わりに読む第三者の内容が攻撃経路になります。OWASPのLLMアプリケーションの10大リスク（2025）は、これを最初のリスクに挙げ、RAGやファインチューニングでも完全には防げないと説明しています。

Anthropicの配置原則は次のとおりです。

1. 第三者の内容はシステムや通常のユーザーテキストではなく、ツール結果（tool_result）内だけに入れる。
2. 「知らない送信者からの受信メール本文」など、内容と出所をツール説明や結果構造に示す。
3. ツール、参照文書、検索結果に由来する内容は信頼できないデータであり、システムや元のユーザー依頼を上書きできないとシステムプロンプトに明記する。
4. 外部の文字列は、できるだけJSONオブジェクトに入れる。JSONのエスケープによって境界を明確にし、攻撃者が引用符やタグを閉じて指示領域に抜け出せないようにする。
5. 自分の指示はツール結果に入れない。疑われたり無視されたりする可能性がある。
6. 突破時に備え最小権限とする。不要な秘密に触れさせず、ツール権限を狭め、危険な行動には人の承認を置く。

ユーザーが直接ルールを崩す直接インジェクション（脱獄）には、軽いモデルで入力を検査する、既知の攻撃文で検証する、拒否方法をシステムに定める、繰り返すユーザーに対処することをAnthropicは勧めています。OWASPも、行動範囲制限、出力形式検証、入出力フィルタリング、最小権限、危険行動の人の承認、外部内容の分離表示、攻撃を想定した試験を挙げます。最も信頼される場所には、最も信頼できる内容だけを置きます。

さらに深く

長いウィンドウに全部入れるか、検索するか

ウィンドウが大きくなるにつれ、「検索せずに、全部入れればよいのでは」という質問が増えました。答えは、タスクによって異なります。Googleの長いコンテキストに関するドキュメントは、単一の情報を探すテストでは高い正確さが得られるものの、複数の情報を同時に探す必要があるときには、同じ正確さは得られないと説明しています。また、質問を送るたびに入力トークンの料金を再び支払い、入力が長いほど、最初のトークンが出るまでの遅延も増えます。

ツール設計もコンテキスト設計

エージェントにとって、ツールは手であり目でもあります。ツール定義とツール結果もコンテキストを占めるため、ツールをどう設計するかが、コンテキストの品質を左右します。Anthropicの記事は、ツールがトークン効率のよい情報を返し、機能の重複を最小限にするべきだと説明しています。また、「人間のエンジニアが、どのツールを使うべきかをはっきり言えないなら、エージェントもうまく選べない」と指摘しています。

Anthropicのツール定義のドキュメントは、各ツールの説明を少なくとも3〜4文で非常に詳しく書くことが、ツールの性能に最も重要な要素だとしています。何をするのか、いつ使い、いつ使わないのか、パラメータの意味、返さない情報を書きます。似た操作は、actionパラメータを持つ1つのツールにまとめ、複数のサービスにまたがる場合は、サービス名を接頭語として付けます。ツール結果には、次の判断に必要なフィールドと、意味のある識別子だけを入れます。膨らんだ結果は、コンテキストを浪費します。

会話状態をサーバーに任せるとき

履歴をベンダーに任せる方法もあります。OpenAI Responses APIはprevious_response_idで応答をつなぎ、Conversations APIは永続的な会話オブジェクトを保存します。公式によると、previous_response_idでつないでも先行応答の入力トークンは再課金されます。保存応答は既定で30日保持し、storeをfalseにすると応答オブジェクトを保存しません。ただし悪用監視ログ（既定で最大30日）など別の保持方針があるため、データ方針も確認します。会話オブジェクトにはこの30日期限は適用されません。費用と保管規程に合う方式を選びます。

推論モデルとツールを併用する際は、前の推論の痕跡も渡します。OpenAIは関数呼び出し後に推論アイテム（reasoning items）を返すことを強く勧め、非保存モードでは暗号化された推論内容（encrypted_content）を渡すよう案内します。Anthropicは思考ブロックも含めAPIの返したassistantターンをそのまま追加するよう勧め、一部最新モデルでは思考ブロックより前の会話を編集するとエラーや破棄が起きると説明しています。ルール変更は履歴を書き換えず、第1章の会話途中のシステムメッセージのように追加します。

実務の場面

あおぞら物流：400の規程を探す質問応答ボット

物流企業「あおぞら物流」は、400件の社内規程文書を検索して回答する質問応答ボットを運用しています。社員の不満は3つあります。回答はもっともらしいものの、どの規程なのかわからないこと。出張費の質問に、休暇の規程が混ざって出てくること。そして、7月に改定された宿泊費の上限を尋ねると、以前の金額が出てくることがある点です。

担当のムンさんは、まず回答に失敗した質問50個を集め、段階ごとに判別しました。正解の根拠が保存先になかった質問は3個でした。検索上位30件の中に正解の根拠がなかった質問は14個で、その大半は、「第4条の2」のような条項番号で尋ねた質問でした。残り33個は、根拠がコンテキストに入っていたにもかかわらず、回答が間違っていました。ムンさんは、現在の構造も調べました。質問がいちばん上にあり、その下に検索結果30件が境界表示なしで次々と貼り付けられ、最後が「答えよ」で終わっていました。

診断に合わせ、段階ごとに処方を変えました。

1. 資料。 根拠がなかった3つの質問は、規程ではなく、お知らせ掲示板にしか載っていなかった内容だった。該当するお知らせを規程の担当部署に渡し、規程へ組み込んでもらうことにした。
2. 検索。 条項番号や規程名のように、厳密な文字列で探す質問のため、意味検索に単語一致検索を加えた。クエリ生成の段階で、質問の業務分類（出張、休暇、購買）を先に判定し、検索フィルターとして使わせることにした。
3. 選別。 関連度で再ランキングし、上位5件だけ残した。
4. 配置とメタデータ。 残した規程ごとに<document>タグと規程番号、改定日、適用対象を付けて前方に置き、質問をいちばん最後に移した。廃止された版は通常の検索から除外するが、質問に過去の日付がある場合は、その時点で有効だった版を一緒に入れるようにした。
5. 生成。 回答する前に、関連する条文を<quotes>に転記させ、回答の最後に規程番号と改定日を書かせた。同じ条項の新旧バージョンが両方入った場合は、質問の基準日に合うほうに従い、判断できなければ、両方のバージョンを示すようにした。

「ウィンドウに余裕があるので、検索結果を50件に増やそう」という意見は受け入れませんでした。失敗のかなりの部分が、無関係な規程の混入によって生じており、増やせば、その問題が大きくなるだけだったからです。改善後、同じ50個の質問をもう一度実行すると、大半は正解の根拠とともに正しく回答し、入力トークンは以前の4分の1程度に減りました。社員は、回答に付いた規程番号を使って、原文をすぐに探せるようになりました。

あかり日報：3年分の公約を1本の記事に

地域紙「あかり日報」のデータチームのチャン記者は、市長選挙を前に、4人の候補の公約が過去3年間でどう変わったかを比較する記事を準備しています。資料は、報道発表資料、討論会の書き起こし、公約集のPDF、市議会の議事録で、合計数百万トークンあります。最初は、候補ごとに資料をすべて入れ、「公約の変化を整理せよ」と指示しましたが、結果はまちまちでした。ある候補では、撤回した公約が現在の公約として整理され、別の候補の発言が混ざることもありました。

チャン記者は、記事で答えるべき問いから逆算しました。記事が答えるべきなのは、「分野ごとに、各候補の現在の公約は何で、いつ、何が変わったのか」です。分野は、交通、住居、ケア、財政の4つです。そこで、作業単位を「候補1人×分野1つ」に分けました。16個の作業それぞれについて、予算表を作りました。

資料の選別には、検索を使いました。候補者名と分野のキーワードで探した後、発言者がその候補本人であるものだけを残しました。書き起こしは発言単位で切り分け、発言者、日付、催事名を付けました。ほかの候補の発言が混ざっていた問題は、このメタデータによってなくなりました。

生成の段階では、まず引用を得ました。モデルは、公約を述べた文を原文どおりに転記し、日付順に並べた後、以前の発言から変わった箇所を示しました。撤回したかどうかのように、解釈が必要な部分は「要確認」として残させました。チャン記者は、引用を原文と機械的に照合するスクリプトを同僚に依頼し、文字が異なる引用をすべて除外しました。

最後に統合する段階では、元の資料の代わりに、16個の整理表だけを入れ、分野別の比較表を作らせました。作業ごとに書いた進捗メモには、確認が済んだ引用と、残った確認事項を記し、数日かけて作業しても、どこまで終えたのかわからなくならないようにしました。

採用しなかった案も記録しました。すべての資料を一度に入れ、すぐに比較表を作らせる方法は、複数の情報を同時に探す作業になるため、見落とす公約が生じる危険が高いものでした。資料を要約し、その要約で比較する方法は、日付や数値が曖昧になる危険があるため、要約ではなく、原文の引用を積み重ねる方法を選びました。記事は、公約を述べた文ごとに出典と日付を付けて公開され、読者の問い合わせに答えるための根拠も、そのまま残りました。

間違えやすいポイント

• ウィンドウが大きければ、全部入れるほうが有利だ。 コンテキスト劣化によって、無関係な情報はかえって品質を下げ、費用と遅延を増やします。
• 広いと長い出力も受け取れる。 出力には別上限があり、長い成果物は分割します。
• 質問を先に書けば、モデルに目的が伝わる。 長い入力では、文書を前に、質問を最後に置く配置が公式の推奨です。中核となる行動制約は前に置きます。
• RAGの誤答にはプロンプトを直す。 資料・検索・選別・生成の失敗箇所を先に判別します。
• 要約すれば、情報の損失はない。 要約は数値と条件を曖昧にします。確定した値は、状態の記録として原文どおりに残します。
• 外部資料ほどシステムプロンプトに入れたほうが、よく反映される。 信頼できない内容を、最も信頼される場所に置くと、インジェクションの危険が高まります。
• キャッシュを有効にすれば、自動で節約される。 変わる値が前方にあると、その後が毎回再計算され、キャッシュはほとんどヒットしません。固定内容を前に、変数を後ろに移します。

ひと目でわかるまとめ

公式ドキュメントで確認する

• Anthropic — Prompting best practices: long context：配置、タグ構造、先に引用を得る方法を読む。
• Anthropic — Effective context engineering for AI agents：劣化、必要時の読み込み、圧縮、構造化メモ、サブエージェント、ツール設計を読む。
• Anthropic — Contextual Retrieval：断片の文脈補強、BM25、再ランキングの効果と小規模知識ベースへの助言を読む。
• Anthropic — Prompt caching：順序、無効化条件、寿命、価格倍率を確認する。
• Anthropic — Mitigate jailbreaks and prompt injections：間接攻撃に備える配置原則を読む。
• OWASP — LLM01:2025 Prompt Injection：直接・間接攻撃と7つの対策を確認する。

セルフチェック

3-1. コンテキスト劣化を1文で定義し、「広いので関連資料を全部入れよう」に反対する根拠を2つ挙げてください。

3-2. 1回のリクエストのコンテキスト予算表に含めるべき構成要素を5つ書いてください。その中で最も忘れられやすいものは何か、また忘れたときに生じる症状も書いてください。

3-3. 各60ページの監査報告書2件と1つの質問を入れるプロンプトの骨格をタグで書いてください。出典・作成日を付け、先に引用を得るようにしてください。

3-4. RAG誤答の失敗段階を分ける4つの問いを確認順に書き、最後に初めて指示を直す理由を1文で説明してください。

3-5. 担当者の交代により、モデルと数週間にわたって交わしたイベント企画の会話を、新しい担当者の新しい会話に引き継ぐ必要があります。引き継ぐ記録に原文どおり残すべき情報を3種類挙げ、その記録の形式を例で示してください。

3-6. あるエージェントは、同じ長い指針を使いながら、リクエストごとにユーザーの権限レベルに応じて、ツール一覧の一部を削除したり追加したりして送っています。プロンプトキャッシュの観点でどのような損失が生じるかを説明し、権限の違いを守りながら損失を減らす方法を1つ提案してください。

3-7. 競合サイトの料金表を整理する調査エージェントを作ります。取得した本文をどこにどの形で入れるか、隠れた指示で突破された際の被害軽減策を、それぞれ2つ書いてください。

実習課題