メインコンテンツまでスキップ

ロングコンテキストのためのプロンプティング

中級
What you'll learn
  • 長いドキュメントをプロンプトのどこに置くか(下ではなく上)、そしてそれが最大30%変化する理由
  • <document> / <source> タグで複数ドキュメントを構造化する方法
  • 長文回答を劇的にグラウンドさせる引用抽出のコツ
  • 1Mコンテキストが誤った道具である場面 — 検索やチャンク化が正しい場合
  • コンテキスト認識とコンパクションがSonnet 5でゲームをどう変えるか

ロングコンテキストはゲームを変えます — と同時に、回答を静かに台無しにもします。Sonnet 5、Opus 5、Opus 4.6/4.7 は 1M トークンウィンドウをデフォルトで搭載(betaヘッダー不要)しているため、全部を貼り付けて祈りたくなる誘惑に駆られます。やめましょう。優れたロングコンテキストプロンプトと粗悪なものの決定的な違いは、まさに構造 — 各パーツをどこに置き、どうラベル付けするかです。

実際に効果がある4つの技法​

Guided walkthrough1 of 4
  1. 長いドキュメントや参考資料は、指示やクエリの下ではなく上に配置します。Anthropic自身のテストでは、クエリを末尾に置くと応答品質が最大30%向上します — 特に複雑で多ドキュメントの入力で顕著です。これが最もレバレッジの高い単一の変更です。

標準テンプレート​

Anthropic自身のテンプレート — これをコピーするだけで、1Mウィンドウを使うほとんどの人より一歩先を行けます:

ロングコンテキスト複数ドキュメント用テンプレート

<documents>
<document index="1">
  <source>annual_report_2025.pdf</source>
  <document_content>
    {{ANNUAL_REPORT}}
  </document_content>
</document>
<document index="2">
  <source>competitor_analysis_q2.xlsx</source>
  <document_content>
    {{COMPETITOR_ANALYSIS}}
  </document_content>
</document>
</documents>

Find quotes from the two documents that are relevant to identifying strategic advantages we can press on in Q3. Place them in <quotes> tags with the source filename. Then, based only on those quotes, recommend three focus areas with a one-line justification each. Place your recommendations in <recommendations> tags.

このプロンプトが同時に行っている3つの動きに注目してください:

  1. ドキュメントが先、質問は最後 — 実際の依頼は資料の下にあります。
  2. 名前付きソース — すべてのドキュメントにClaudeが引用できるファイル名があります。
  3. 引用 → 回答 — Claudeは推奨を出す前に自らグラウンドせざるを得ません。

コンテキスト・ロット: なぜトークン数が多い ≠ 回答が良い ではないか​

コンテキストは多ければ自動的に良いというわけではありません。トークン数が増えると精度と再現率は低下します — Anthropicはこれを**context rot(コンテキスト・ロット)**と呼びます。モデルは長い入力の中間よりも先頭と末尾を確実に利用する傾向があります(古典的な "lost in the middle" 効果)。

実務的な帰結:

  • 貼る前に切り詰めましょう。 20%が無関係のセクションである10万トークンのダンプは、6万トークンの厳選版に負けることが多いです。
  • 重要度で並べる。 <documents> の中で、答えを含む可能性が最も高いドキュメントを一番前に置きます。
  • プロンプトキャッシングはすぐに元が取れます。 安定した接頭辞設計(システムプロンプト + ドキュメントがターン間で同一)なら、キャッシュされた接頭辞はトークン価格の約10%で読み込まれます。プロンプトキャッシングを参照。
Watch out
  • 1M ウィンドウ ≠ 1M トークン分の有用な注意。机を埋めるほど精度は落ちます。
  • 巨大な貼り付けの中央に依頼を埋めると、重みが低くなります。
  • Sonnet 5 / Opus 5 で入力200kトークンを超えると、ロングコンテキスト料金です — リポジトリを貼る前にモデルページを確認してください。

1M コンテキストが誤った道具の場面​

「コードベースを貼り付けるだけ」の方が、検索を構築するより簡単に感じるため、ロングコンテキストは魅力的です。時にはそれで正解です。でも多くの場合はそうではありません。以下の場合は代替案を選びます:

シグナル1M貼り付けより良い選択
同じドキュメントを数千のクエリで使う検索 + RAG — より安く速い
ユーザーが毎ターン自分のドキュメントを持ち込むFiles API でのドキュメントアップロード
回答には全体のコードベースが必要だが、繰り返し尋ねる安定接頭辞のコードベーススナップショットでプロンプトキャッシング
行単位の監査可能な引用が必要チャンクIDでの検索 → 「貼り付けのどこか」ではなくチャンクを引用
一度の品質より遅延の方が重要チャンク+リランク、次にtop-kだけを渡す

経験則: 毎ターンこれを貼り直すことにためらいがあるなら、おそらく検索が必要です。

Sonnet 5 で何が変わるか(コンテキスト認識)​

Sonnet 5、Sonnet 4.6、Sonnet 4.5、Haiku 4.5 は現在コンテキスト認識を持っています — APIがシステムプロンプトに走行予算を注入し、モデルがペース配分できるようになります:

<budget:token_budget>1000000</budget:token_budget>

各ツール呼び出し後、APIがそれを更新します:

<system_warning>Token usage: 350000/1000000; 650000 remaining</system_warning>

これらのタグを送るのはあなたではありません — APIです。実務的な効果: 長いエージェンティック実行では、Sonnet 5 は壁にぶつかる前に事前にサマライズしたりハンドオフしたりします。Opus 4.7+、Fable 5、Mythos 5 には注入タグはありません。代わりにタスク予算(beta)で明示的に予算を与えてください。

よくある間違い​

  • 指示の 後 にドキュメントを貼る — 最もよくある見逃し。依頼の上に移動しましょう。
  • <source> メタデータがない — Claude は report.pdf ではなく「そのドキュメント」と引用し、下流のツールで検証できません。
  • 1つの巨大な <document> ブロック — 複数のソースを1つに畳むと Claude は区別できません。ファイルごとに1つずつ使いましょう。
  • 長入力に直接回答を求める — 約20kトークンを超える入力には常に先に引用を求めましょう。
  • キャッシングが自動だと仮定する — 違います。キャッシュブレークポイントと TTL はプロンプトキャッシングを参照。
  • コンパクションの存在を忘れる — Claude 4.6+ でとても長いエージェント実行では、サーバー側コンパクションが古いターンを自動で要約します。

今すぐ試してみる​

普段そのまま貼っている20k以上のトークンのドキュメントを1つ取ります。上のテンプレートに包み、依頼を一番下に置き、最初の指示に「まず関連する引用を抽出せよ」を追加します。古いプロンプトの回答と比較してみてください — 違いはたいてい小さくないはずです。

理解度チェック

0/5
  1. ロングコンテキストプロンプトで長いドキュメントはどこに置くべきか?
  2. 引用抽出テクニックとは?
  3. 900k トークンのコードベースがあり、1日500件の類似クエリを想定しています。生の1M貼り付けに勝るのは?
  4. 「context rot(コンテキスト・ロット)」とは?
  5. Sonnet 5 で <budget:token_budget> タグを注入するのは誰?
Key takeaways
  • 長文データは先頭、依頼は末尾 — 複雑な入力で最大30%改善。
  • すべてのドキュメントを <document> と <source> メタデータで包み、回答の前に <quotes> を求めよ。
  • 1M コンテキスト ≠ 無料 — context rot は現実で、入力200kトークンを超えるとロングコンテキスト料金が発生する。
  • 同じコーパスが多数のクエリに使われるときは RAG を使え。ロングコンテキストを経済的にするにはコンパクションとプロンプトキャッシングを使え。

次に​