ai·

コンテキストエンジニアリングとは？プロンプトとの違い・4戦略・Claude Code実装ガイド【2026年版】

コンテキストエンジニアリング（Context Engineering）の定義、プロンプトエンジニアリングとの違い、Anthropic／LangChainが提唱する4戦略（Write / Select / Compress / Isolate）、Claude Codeでの実装5ステップ、失敗パターン7選、効果測定4 KPIまで、エンジニアと意思決定層の双方に向けて体系的に解説。

#コンテキストエンジニアリング#Context Engineering#Claude Code#AIエージェント#LLM
コンテキストエンジニアリングとは？プロンプトとの違い・4戦略・Claude Code実装ガイド【2026年版】

「プロンプトを工夫しても、AIエージェントが本番環境で安定して動かない」——2026年のAI開発現場で、もっとも頻繁に聞かれる悩みの一つです。Claude や GPT のコンテキストウィンドウは年々拡大していますが、長く詰め込むほど性能が落ち、トークンコストは膨らみ、AIエージェントは中盤の指示を見落とします。

この限界に対する答えとして、AnthropicやLangChainが提唱しているのが**コンテキストエンジニアリング（Context Engineering）**です。プロンプトエンジニアリングが「どう聞くか」の最適化だとすれば、コンテキストエンジニアリングは「LLMが処理する作業メモリ全体をどう設計するか」を扱う上位概念です。

本記事では、コンテキストエンジニアリングの定義、プロンプトエンジニアリングとの違い、4戦略（Write / Select / Compress / Isolate）の実装、Claude Code での実践5ステップ、失敗パターン7選、効果測定4 KPI、本番化ロードマップまでを一気通貫で解説します。

この記事の要点（TL;DR）

  • コンテキストエンジニアリングとは、LLMの限られたコンテキストウィンドウに「どの情報を、どの順序で、どれだけ入れるか」を設計する技術
  • プロンプトエンジニアリングは個々の指示の最適化、コンテキストエンジニアリングは作業メモリ全体の設計
  • LangChain提唱の4戦略は Write（書き込み）／Select（選択）／Compress（圧縮）／Isolate（分離）
  • コンテキストウィンドウが大きくなっても Lost in the Middle・KVキャッシュ無効化・トークンコストの3つの罠は残る
  • Claude Code では CLAUDE.md / MEMORY.md / Subagent / /compact / Hooks の組合せで段階的に実装できる

この記事を読むとわかること

  • コンテキストエンジニアリングの定義と、プロンプトエンジニアリングとの位置づけの違い
  • LLMが参照する5要素（System Prompt / User Input / State / Long-term Memory / Tools・RAG）の設計観点
  • 4戦略（Write / Select / Compress / Isolate）の実装パターンと使い分け
  • AIエージェント開発で陥りがちな失敗7パターンと早見表
  • 効果測定の4 KPIと、本番化に向けた5段階ロードマップ

結論 ── コンテキストエンジニアリングは"何を入れるか"を設計する技術

コンテキストエンジニアリングとは、LLMが推論する各ステップで「コンテキストウィンドウに何の情報を入れるか」を体系的にキュレーションする工学的アプローチです。 Anthropic は「各推論ステップにおいて、モデルの限られた注意バジェットに何の情報を入れるかをキュレーションすること」と定義し（Anthropic, Effective context engineering for AI agents, 2025）、LangChain は「Write（書き込み）／Select（選択）／Compress（圧縮）／Isolate（分離）」の4戦略にまとめています（LangChain, Context Engineering for Agents, 2025）。

プロンプトエンジニアリングが「個々の指示文の最適化」だったのに対し、コンテキストエンジニアリングはシステムプロンプト・履歴・長期メモリ・ツール出力・RAG結果のすべてを含む作業メモリ全体の設計を扱います。AIエージェントを本番運用する企業が必ず通る道筋です。

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

定義 ── Anthropic公式の定式化

Anthropic公式ブログでは、コンテキストエンジニアリングを次のように説明しています。

Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference.（Anthropic, Effective context engineering for AI agents）

日本語に意訳すれば「LLM推論中に、最適なトークン（情報）の集合をキュレーションし維持するための戦略群」です。「the art and science of curating what will go into the limited context window」という表現も用いられており、限られたコンテキストウィンドウに何を入れるかを設計する技術であることが強調されています。

LangChain も同じ思想を別の角度から定義しています。「the art and science of filling the context window with just the right information at each step of an agent's trajectory」——エージェントの各ステップで、コンテキストウィンドウにちょうど良い情報を満たす技芸です（LangChain）。

なぜ今、注目されているのか

コンテキストエンジニアリングが2025年以降に急浮上した背景には、3つの構造変化があります。

1. プロンプト単発から、エージェント連続実行へ

ChatGPT が登場した2022〜2024年のプロンプトエンジニアリングは「ワンショット指示の最適化」が中心でした。一方、Claude Code・Claude Agent SDK・LangGraph 等のエージェントフレームワークでは、LLMが数十〜数百ステップの推論を連続して行い、ツール呼び出し・RAG検索・サブエージェント呼び出しの結果が逐次コンテキストに積み重なります。各ステップで何を入れ、何を捨てるかを設計しなければ、すぐに上限に到達します。

2. 長コンテキストモデルでも"中盤の劣化"は残る

Anthropic は Claude Sonnet 4.6 や Claude Opus 4.7 で 1M トークンのコンテキストウィンドウを提供しています（Anthropic, Claude Sonnet 4 now supports 1M tokens of context, 2025）。しかし Liu らの研究 "Lost in the Middle" は、関連情報がコンテキストの中盤にあると性能が大幅に劣化することを報告しています（Liu et al., 2023, arXiv:2307.03172、TACL 2024掲載）。GPT-3.5-Turbo・当時の Claude-1.3 などで一貫して観測された現象で、ウィンドウが拡大しても根本解決にはなりません。

3. AIエージェントの本番化要件

PoC からの本番昇格には、再現性・可観測性・コスト管理が求められます。プロンプトを「とにかく長くする」アプローチでは、トークンコストとレイテンシが線形に増加し、ビジネスとして成立しません。何を残し、何を削るかを工学的に管理するスキルが、AI開発のプロフェッショナル要件になりつつあります。

業界での位置づけ

Phil Schmid 氏や Drew Breunig 氏らは2025年中盤から「これからのAIスキルはプロンプトではなくコンテキストエンジニアリング」と発信し、O'Reilly などのメディアも特集を組んでいます（O'Reilly, Working with Contexts）。プロンプトエンジニアリングの完全な置き換えではなく、より広い設計領域として包含する関係にあります。

プロンプトエンジニアリングとの違い

プロンプトエンジニアリングとコンテキストエンジニアリングは対立概念ではありません。プロンプト設計はコンテキスト設計のサブセットです。役割の違いを5観点で整理すると次のようになります。

観点プロンプトエンジニアリングコンテキストエンジニアリング
対象範囲ユーザー指示文（プロンプト）単体System Prompt / 履歴 / 長期メモリ / ツール出力 / RAG結果を含む作業メモリ全体
時間軸ワンショットや少数ターンエージェントの全トラジェクトリ（数十〜数百ステップ）
主な技法Few-shot・Chain of Thought・Role指示Write / Select / Compress / Isolate の4戦略
失敗の典型曖昧な指示・例示不足情報過多・順序不適切・古い記憶の混入
必要なスキル自然言語の表現力システム設計・情報アーキテクチャ・評価運用

両者の使い分けの基本原則はシンプルです。「単発の質問・限定的なタスク」ならプロンプトエンジニアリングで十分です。「エージェントが複数ステップで動く・長期セッションを跨ぐ・ツールを多用する」ならコンテキストエンジニアリングが必須になります。実務ではプロンプトエンジニアリングの基礎と実務応用で身につけた表現技法を、コンテキスト設計の中で使うという順序が自然です。

コンテキストの構成要素 ── 5要素モデル

LLMがある瞬間に参照しているコンテキストは、次の5要素に分解できます。各要素は独立に設計・最適化できる工学的単位です。

1. System Prompt（システムプロンプト）

エージェントの役割・行動規範・出力形式・禁止事項を定義する初期設定です。Anthropic は「specific enough to guide behavior effectively, yet flexible enough to provide the model with strong heuristics（行動を効果的に導くほど具体的でありつつ、強力なヒューリスティクスを与えるほど柔軟）」というバランスを推奨しています。XMLタグ（<background_information>, <instructions>）やMarkdownヘッダー（## Tool guidance, ## Output description）でセクション分割すると、モデルが各情報を確実に参照できます。

2. User Input（ユーザー入力）

人間からの直接的な指示や質問です。プロンプトエンジニアリングで最も洗練されてきた領域ですが、コンテキストエンジニアリングの観点では「他の4要素との整合性」が問われます。例えば過去履歴に「以後すべて日本語で答える」と書かれているのに User Input が英語で来たとき、どちらを優先するかの規則を System Prompt に明記する必要があります。

3. State / History（短期記憶・履歴）

直前数ターンのユーザーとAIのやり取り、ツール呼び出しの結果、思考の中間状態などです。エージェントの実行が長くなるほど肥大化し、もっとも圧縮対象になります。Claude Code の4層メモリモデル（/compact・CLAUDE.md・MEMORY.md・claude-mem）では、この層が /compact 圧縮の主対象です。

4. Long-term Memory（長期記憶）

セッションを跨いで保持される知識です。プロジェクト固有の規約（CLAUDE.md）、過去セッションから自動学習された情報（MEMORY.md）、ベクトルデータベースに保存された会話要約（claude-mem 等）が該当します。読み込みコストとリコール精度のトレードオフを設計する領域です。

5. Tools / Tool Results / RAG結果

外部ツールの定義（関数シグネチャ・利用方法）と、実行結果（API レスポンス・検索結果・ファイル中身）です。Anthropic は「tools should be self-contained, robust to error, and extremely clear with respect to their intended use（ツールは自己完結的で、エラーに堅牢で、意図された用途に対して極めて明確であるべき）」と推奨しています。RAG の検索結果もこの層に入り、RAG高度化テクニック（再ランキング・ハイブリッド検索）で関連度フィルタリングを設計します。

5要素はそれぞれが独立した最適化対象です。System Prompt の改善は1回で終わるが、State の圧縮は毎ステップで走る——というように、最適化サイクルの粒度も異なります。

4つの戦略 ── Write / Select / Compress / Isolate

LangChain は、コンテキストエンジニアリングの実装手法を Write / Select / Compress / Isolate の4戦略に整理しました（LangChain, Context Engineering for Agents）。本番運用のAIエージェントは、この4つを組み合わせて構築されています。

4戦略マッピング表

戦略目的主な実装Claude Code での対応
Write（書き込み）コンテキストウィンドウの外に情報を保存scratchpad、ファイル書き込み、永続メモリCLAUDE.md / MEMORY.md / 作業メモファイル
Select（選択）必要な情報だけをコンテキストに引き出すRAG、関連度フィルタ、メモリ検索Skills / @-mention / Subagent結果のフィルタ
Compress（圧縮）必要なトークンのみ保持する要約、階層圧縮、削除/compact / Hooks による要約自動化
Isolate（分離）コンテキストを分割して干渉を防ぐサブエージェント、マルチエージェントSubagent / 並列worktree

Write ── 「書く」ことで忘れる

エージェントが進行中のタスクで使う情報を、コンテキストウィンドウの外側に書き出す戦略です。LangChain は「Scratchpad（メモ帳）」と呼びます。ファイル書き込みツールまたはランタイム状態オブジェクトのフィールドとして実装されます。

代表的な実装は次の3パターンです。

  1. Project Memory（CLAUDE.md）：プロジェクト規約・ビルドコマンド・コーディングスタイル等を、人間が手動で書く永続ファイル。Claude Code では起動時に自動読込されます（詳細はCLAUDE.mdの書き方完全ガイド）。
  2. Auto Memory（MEMORY.md）：エージェントが「次回も役立つ」と判断した情報を自動追記する学習ファイル。Claude Code の最近のバージョンで利用可能（公式 changelog で対応バージョンを確認できます）。
  3. Working Notes（タスク実行中の中間メモ）：長いリサーチタスクで、各ステップの発見をファイルに書き出し、最終ステップでまとめて参照する。

Write の本質は「忘れることを許容する」ことです。重要な情報を外に書いておけば、コンテキストウィンドウから削除しても再取得できます。

Select ── 必要な情報だけを引き出す

外部ストレージからコンテキストへ「必要な情報だけ」を選んで注入する戦略です。代表例はRAG（Retrieval-Augmented Generation）で、ベクトル検索や全文検索で関連度の高い文書だけをコンテキストに入れます。LangChain の記事が紹介する事例では、RAG を適用することでツール選択精度が約3倍に改善したとされています（LangChain, Context Engineering for Agents）。

実装パターンは次の通り。

  • 意味検索（ベクトル検索）：埋め込み類似度で関連文書を抽出。誤マッチの可能性があるため再ランキングと併用。
  • 全文検索（BM25 等）：完全一致系のクエリに強い。ハイブリッド検索で意味検索と併用するのが主流。
  • メモリ検索：MEMORY.md / claude-mem のような長期メモリから関連エントリを取り出す。
  • @-mention（ファイル参照）：Claude Code で @path/to/file.ts と書くと、そのファイルだけがコンテキストに注入される。
  • Skills：Claude Code のSkills 機能では、タスク内容に応じて関連Skillだけが動的に読み込まれる。

Select は「何を読まないか」の設計でもあります。すべてを読ませると Lost in the Middle で性能が落ちるため、上位 N 件だけを選び抜く判断が重要です。

Compress ── 失わずに小さくする

コンテキストに残す情報を要約・抽象化してトークン量を削減する戦略です。Anthropic は「Compaction」として、長コンテキスト・タスクで「内容を要約し、その要約とともに新しいコンテキストウィンドウを再開始する」アプローチを推奨しています。

実装パターンは次の通り。

  • 要約圧縮：直前 N ターンの会話を1パラグラフに要約。Claude Code の /compact コマンドが代表例で、LangChain 記事の紹介によればコンテキスト使用率が95%を超えると自動実行されます（LangChain, Context Engineering for Agents、最新仕様はClaude Code 公式 changelogを参照）。手動で 60% 程度の段階で実行するのがコミュニティのベストプラクティスです。
  • 階層圧縮：詳細→中要約→粗要約と多層化し、必要な解像度だけを呼び出す。
  • 削除：冗長な ack（「了解しました」等）や、結論が出たツール呼び出しの中間ログを削除。
  • 構造化抽出：自由記述から JSON や表形式に変換し、トークンあたりの情報密度を上げる。

Claude Code ではHooks 機能で /compact 後の自動処理を組めるため、圧縮→必要文脈の再注入を自動化できます。

Isolate ── 文脈を分けて干渉を防ぐ

ひとつのエージェントに全てを詰め込まず、複数のエージェントやコンテキストに分割する戦略です。

実装パターンは次の通り。

  • サブエージェント（Subagent）：Claude Codeのサブエージェント機能を使うと、特定タスク用に独立したコンテキストでLLMを動かせる。親エージェントは結果（要約）だけを受け取る。
  • マルチエージェント：役割の異なるエージェント（プランナー・実行者・批評者）を並列に動かす。LangChain の記事はマルチエージェント利用時に「チャット比較で最大15倍のトークン消費」が観測されると紹介しており（LangChain）、コスト管理と精度のトレードオフが重要。
  • Worktree並列：Git worktree でディレクトリを分け、複数の Claude Code セッションを並行実行する。各セッションが独立コンテキストになる。
  • Quarantine（隔離）：信頼できないツール出力（外部APIレスポンス等）を別コンテキストで処理し、メインに混入させない。プロンプトインジェクション対策にもなる。

Isolate は「干渉によるエラー」を防ぐ戦略です。本番のAIエージェントでは、ツール出力同士・指示同士の衝突が頻発するため、文脈の分離設計が品質を左右します。

コンテキストウィンドウの3つの罠

「コンテキストウィンドウが大きいモデルを使えばコンテキストエンジニアリングは不要では？」という質問は頻出しますが、答えは否です。長コンテキストには次の3つの罠が残ります。

罠1: Lost in the Middle（中盤劣化）

Liu らの研究 "Lost in the Middle: How Language Models Use Long Contexts" は、関連情報がコンテキストの先頭または末尾にあるときに性能が最も高く、中盤に置くと大幅に劣化することを示しました（Liu et al., 2023, arXiv:2307.03172、TACL 2024掲載）。検証はGPT-3.5-Turbo・当時の Claude-1.3・MPT-30B-Instruct・LongChat-13B(16K) など複数のモデルで一貫して観測されました。

実務上の対策は3つ。

  1. 重要な情報は先頭または末尾に配置：System Prompt の最重要規則は冒頭、ユーザー指示の最終確認は末尾。
  2. 無関係な情報を中盤から削る：Compress 戦略で「中盤に置かれている冗長コンテキスト」を優先的に削る。
  3. Re-ranking で関連順序を再構成：RAG の検索結果は関連度順だけでなく、配置位置も考慮する。

罠2: KVキャッシュ無効化

Transformer ベースの LLM は、過去トークンの計算結果をKVキャッシュとして保持し、再計算を避けて高速化しています。コンテキストの先頭が変わるとキャッシュが無効化され、レイテンシとコストが急増します。

実装上の対応は次の通り。

  • 不変部分を先頭に固定：System Prompt や恒常的なツール定義をコンテキスト冒頭に置き、キャッシュヒット率を上げる。
  • 動的部分を末尾に：ユーザー入力・直近のツール結果など、毎回変わる部分は末尾に集める。
  • プレフィックスキャッシング機能の活用：Anthropic API の prompt caching、OpenAI の prompt caching を有効化し、固定プレフィックスの再計算を回避する。

罠3: トークンコスト爆発

入力トークンは「線形」にコストが増えるように見えますが、現実には会話のターン数 × 各ターンのコンテキスト長の積で増えます。50ターンの会話で各ターン3万トークンを再送ると、合計150万トークン分の入力課金が発生します。前述の通り、LangChain の記事ではマルチエージェント構成でチャット比較で最大15倍のトークン消費が紹介されています。

対応は Compress 戦略の自動化 と Cache 機能の最大活用の二本柱です。本番化したい AI エージェントでは、トークンコストの監視ダッシュボードと、コスト超過時の自動 Compaction フックがほぼ必須になります。

Claude Code で実践する5ステップ

Claude Code を使ったコンテキストエンジニアリングの導入は、次の5ステップで段階的に進められます。社内向けに「明日から始められる」レベルまで具体化したロードマップです。

Step 1: CLAUDE.md でベースラインを敷く（Write 戦略）

まずプロジェクト固有の前提を CLAUDE.md に書き出します。Claude Code は起動時にこのファイルを自動読込するため、毎回 System Prompt 相当の指示を入力する必要がなくなります。

# プロジェクト規約

## ビルドとテスト
- 型チェック: `pnpm typecheck`
- ユニットテスト: `pnpm test`
- E2E: `pnpm test:e2e`

## コーディング規約
- TypeScript の `any` は禁止。`unknown` + 型ガード
- 関数50行・ファイル400行を超えたら分割
- console.log を本番に残さない

## コミット
- 形式: `<type>: <description>`
- 必ずブランチを切って PR を作る（main 直 push 禁止）

CLAUDE.md はCLAUDE.mdの書き方ガイドにあるとおり、200行以内に収め、長くなったら役割別に分割するのが定石です。これがコンテキストエンジニアリングの「最も再利用される Write 層」になります。

Step 2: MEMORY.md で学習を蓄積する（Write 戦略）

Claude Code の最近のバージョンで利用可能な auto memory（MEMORY.md）を有効化します（最新仕様はClaude Code 公式 changelogを参照）。エージェントが「次回も役立つ」と判断した情報を自動追記してくれます。

蓄積される代表例:

  • 「このリポジトリの DB 接続には .envrc の AWS_PROFILE が必要」
  • 「pnpm test は型チェックも兼ねている」
  • 「ユーザーは PR タイトルを 70 文字以内で要求する」

肥大化したら手動編集で剪定し、秘密情報が誤って書かれていないかを定期的にレビューします。詳細はClaude Code のメモリ運用で解説しています。

Step 3: Subagent で文脈を分離する（Isolate 戦略）

長いリサーチや独立した調査タスクは、サブエージェント機能で別コンテキストに切り出します。親エージェントには「結論サマリー」だけが返るため、メインのコンテキストウィンドウを圧迫しません。

切り出しの判断基準:

  • 3往復以上のツール呼び出しが必要なリサーチ
  • 大量のファイルを読み込む必要がある探索
  • 独立した出力（レポート・コードレビュー）を生成するタスク

Step 4: /compact と Hooks で圧縮を自動化する（Compress 戦略）

長セッションでは Claude Code の /compact コマンドで会話履歴を要約圧縮します。LangChain によると、Claude Code はコンテキスト使用率が95%を超えると自動圧縮を実行しますが、品質を保つには 60%前後で proactive に手動実行するのがコミュニティのベストプラクティスです。

Hooks を使えば /compact 後の自動処理を仕掛けられます。

{
  "hooks": {
    "PostCompaction": [
      { "hook": "cat .steering/specs/current-feature.md" }
    ]
  }
}

これで圧縮直後に「現在の仕様書を再注入」する処理が走り、圧縮で失われがちな前提を取り戻せます。

Step 5: 効果測定とドリフト監視を組み込む（運用）

ここまでの4ステップは「型を整える」段階です。本番運用には何が良くなったか・悪くなったかを測る指標が必要です。次節で詳述する4 KPI（Context Precision / Recall / Faithfulness / Answer Relevance）を、ベンチセットに対して定期的に計測します。

LLMOps実践ガイドの評価運用と組み合わせると、CLAUDE.md の更新やプロンプトの調整が性能に与える影響を定量で追えるようになります。

よくある失敗パターン7選

Drew Breunig 氏の "How Long Contexts Fail" と "How to Fix Your Context" の2記事を起点に、現場でよく遭遇する失敗を本記事で7つに体系化しました（How Long Contexts Fail, 2025 / How to Fix Your Context, 2025）。症状で判別できる早見表として活用してください。

1. Context Pollution（コンテキスト汚染）

症状: AIが一度間違えた情報を、その後も繰り返し参照する。 原因: 幻覚（hallucination）や誤ったツール出力がコンテキストに残り、後続の推論が「事実」として扱う。 対策: 誤情報を発見したら即座に履歴から削除する／ツール結果を信頼度別に層別化する／重要な事実は別ストレージから毎回 Select し直す。

2. Context Distraction（注意散漫）

症状: AIが新しいタスクに進まず、過去の行動を反復する。 原因: 履歴が長すぎて、過去の文脈が新しい指示より目立ってしまう。 対策: Compress で履歴を要約／重要な指示を末尾に再配置／Subagent で短いコンテキストを与える。

3. Context Confusion（混乱）

症状: 関係ないツールやドキュメントを呼び出す。 原因: ツール定義や RAG 結果が多すぎて、似たような選択肢の中から誤選択する。 対策: Tool Loadout（タスク種別に応じてツール集合を絞る）／RAG の上位 N を厳しく設定／ツール説明を「自己完結的・明確」に書き直す。

4. Context Clash（衝突）

症状: 異なる情報源の指示が矛盾し、AIが揺れる。 原因: 古い指示と新しい指示の混在、複数 MCP サーバの instructions の競合。 対策: System Prompt で優先順位を明示／古いツール定義を撤去／Quarantine で外部入力を隔離。

5. Stale Memory（陳腐化したメモリ）

症状: 半年前のプロジェクト規約に従った提案をしてくる。 原因: MEMORY.md や CLAUDE.md が更新されず、現実と乖離。 対策: 月次で memory ファイルをレビュー／前提が変わったら明示的に削除／日付付きでメモを残す。

6. Tool Overflow（ツール定義過多）

症状: ツール選択が遅い・誤選択が増える。 原因: 50個・100個と接続したツール定義がすべてコンテキスト先頭に常駐し、トークンを食い、選択判断を難しくする。 対策: タスク種別ごとのプロファイルでツールを絞る／使用頻度の低いツールは Subagent 経由に切り出す。

7. Premature Compaction（早すぎる圧縮）

症状: 圧縮直後に「あれ何だっけ」となる。 原因: まだ参照中の情報まで要約してしまい、詳細が失われる。 対策: 圧縮対象は「結論が出たステップ」に限定／PostCompaction Hook で重要な前提を再注入／圧縮閾値を保守的に設定。

失敗パターン早見表

パターンキーワード症状主な対策戦略
Pollution過去の誤情報を繰り返す削除・層別化
Distraction新しい指示に進まないCompress・Isolate
Confusion関係ないツール呼び出しTool Loadout・RAG精査
Clash矛盾した出力優先順位明示・Quarantine
Stale Memory古い前提に従う定期レビュー・剪定
Tool Overflowツール選択ミスプロファイル分離
Premature Compaction圧縮直後に詳細喪失閾値調整・再注入

効果測定 ── 4つのKPI

コンテキストエンジニアリングの効果は、感覚ではなく数値で測ります。RAG 評価で広く使われる「RAGトライアド」を拡張した4 KPIが、エージェント全体の評価にも応用できます。

KPI 1: Context Precision（コンテキスト適合度）

コンテキストに含めた情報のうち、回答に実際に関連していた割合です。

  • 計算: 関連した情報の数 / コンテキスト全体の情報数
  • 推奨閾値: 0.8 以上（「無関係な情報がコンテキストの20%未満」）
  • 改善手段: Select 戦略の精度向上、RAG 上位件数の絞り込み、再ランキング

KPI 2: Context Recall（コンテキスト再現率）

回答に必要だった情報のうち、コンテキストに含められていた割合です。

  • 計算: コンテキストに入った関連情報数 / 必要だった関連情報の総数
  • 推奨閾値: 0.85 以上（「必要情報の85%以上を引き出せている」）
  • 改善手段: 検索範囲の拡大、ハイブリッド検索、Long-term Memory の充実

KPI 3: Faithfulness（出典忠実性）

AIの回答が、与えられたコンテキストの内容と矛盾していないかです。幻覚（hallucination）を測る指標として使われます。

  • 計算: コンテキストの記述と整合する回答主張の数 / 回答中の主張の総数
  • 推奨閾値: 0.95 以上（「回答主張の95%以上がコンテキストで裏付けられている」）
  • 改善手段: System Prompt に「コンテキスト外の知識で答えない」を明示、Pollution 検出フィルタ

KPI 4: Answer Relevance（回答関連性）

AIの回答が、ユーザーの質問にどれだけ的確に答えているかです。

  • 計算: 質問と回答の埋め込み類似度、または LLM-as-judge による 0-1 スコア
  • 推奨閾値: 0.85 以上
  • 改善手段: User Input の意図抽出を改善、Few-shot で回答スタイルを学習させる

これら4 KPIはベンチセット（質問と理想回答のペア集）に対して定期的に計算します。CLAUDE.md の更新前後でスコアを比較できれば、コンテキスト設計の改善効果が定量で見えるようになります。

本番化までのロードマップ（5段階）

PoC で動いたエージェントを本番運用に乗せるには、評価・監視の運用が不可欠です。次の5段階で段階的に整備していきます。

Stage 1: PoC評価（1〜2週間）

  • 目的: 「そもそも価値があるか」を判断
  • 成果物: 5〜10件のテストケースで AIエージェントが期待動作するかの定性評価
  • 主担当: AIエンジニア／プロダクトマネージャ

Stage 2: ベンチセット作成（2〜4週間）

  • 目的: 定量評価の土台を作る
  • 成果物: 50〜200件の「質問・期待回答・利用すべきツール」のペア
  • 主担当: ドメインエキスパート＋AIエンジニア
  • ポイント: エッジケース・失敗ケース・敵対的入力を必ず含める

Stage 3: A/B 比較（2週間）

  • 目的: コンテキスト設計の変更が効くかを定量で確認
  • 成果物: 4 KPI のベンチマーク表（CLAUDE.md 改訂前後／戦略別）
  • 主担当: AIエンジニア
  • ポイント: 1変数ずつ変える（同時に CLAUDE.md とプロンプトとツールを変えない）

Stage 4: SLO 監視（継続）

  • 目的: 本番でのリアルタイム品質を可視化
  • 成果物: ダッシュボード（Faithfulness / レイテンシ / コスト / トークン消費）
  • 主担当: SRE／プラットフォームチーム
  • ポイント: SLO違反時のアラートと、自動 Compaction フックの整備

Stage 5: ドリフト検知（継続）

  • 目的: 性能の経時劣化を検出
  • 成果物: 週次のベンチセット再実行レポート、KPIトレンドの異常検知
  • 主担当: AIエンジニア／LLMOps エンジニア
  • ポイント: モデル更新・データ変化・依存ライブラリ更新の3軸でドリフト要因を分離

このロードマップはLLMOps実践ガイドの評価・監視運用と直結します。コンテキストエンジニアリングは設計だけで完結せず、本番化の運用ループで初めて成果を出します。

FAQ

Q1. コンテキストエンジニアリングとプロンプトエンジニアリングは何が違いますか？

A. プロンプトエンジニアリングは「個々の指示文をどう書くか」の最適化、コンテキストエンジニアリングは「LLMの作業メモリ全体（System Prompt・履歴・長期メモリ・ツール出力・RAG結果）をどう設計するか」の上位概念です。プロンプト設計はコンテキスト設計の一要素として包含される関係で、対立しません。

Q2. コンテキストの構成要素は何ですか？

A. System Prompt（役割・規範）／User Input（ユーザー入力）／State・History（短期記憶）／Long-term Memory（長期記憶）／Tools・RAG結果の5要素です。それぞれ独立に最適化できる工学的単位として扱います。

Q3. 4つの戦略（Write / Select / Compress / Isolate）はどう使い分けますか？

A. Write はコンテキスト外への保存（CLAUDE.md・MEMORY.md）、Select は必要な情報の引き出し（RAG・@-mention）、Compress はトークン削減（要約・/compact）、Isolate は文脈の分離（Subagent・並列worktree）です。エージェントの段階・タスク特性に応じて組み合わせ、本番運用ではほぼ4つすべてを使います。

Q4. なぜコンテキストエンジニアリングが必要なのですか？

A. コンテキストウィンドウの上限・Lost in the Middle による中盤劣化・トークンコスト・再現性確保のためです。プロンプトを長くするだけでは、長期セッションで性能とコストの両方が劣化します。

Q5. Anthropic公式の定義は何ですか？

A. Anthropic の公式エンジニアリングブログでは「LLM推論中に最適なトークン（情報）の集合をキュレーションし維持するための戦略群」と定義しています。「the art and science of curating what will go into the limited context window」という表現も用いられています。

Q6. Claude Code でコンテキストエンジニアリングを実践するには？

A. CLAUDE.md（プロジェクト規約）／MEMORY.md（自動学習）／Subagent（文脈分離）／/compact（圧縮）／Hooks（自動化）の5機能を組み合わせます。本記事「Claude Code で実践する5ステップ」の通り、段階的に導入するのが現実的です。

Q7. コンテキストウィンドウが大きいモデル（1Mトークン等）なら不要ですか？

A. 不要にはなりません。長コンテキストでも Lost in the Middle（中盤劣化）／KVキャッシュ無効化によるレイテンシ増／トークンコスト爆発の3つの罠が残ります。むしろ大きいウィンドウだからこそ、何を入れるかの設計責任が重くなります。

まとめ ── 「プロンプト」から「コンテキスト」へ

コンテキストエンジニアリングは、AIエージェント時代の中心的な設計スキルです。本記事の要点は次の4点に集約されます。

  1. コンテキストエンジニアリングとは、LLMの作業メモリに何を入れるかを設計する技術。プロンプトエンジニアリングを包含する上位概念。
  2. 5要素モデル（System Prompt / User Input / State / Long-term Memory / Tools・RAG）を独立した最適化対象として扱う。
  3. 4戦略（Write / Select / Compress / Isolate）を組み合わせ、Claude Code であれば CLAUDE.md / MEMORY.md / Subagent / /compact / Hooks にマッピングできる。
  4. 失敗パターン7選と4 KPI で定量管理し、5段階の本番化ロードマップに沿って評価・監視を整える。

AIエージェントのビジネス活用ガイド・Claude Code完全ガイドと合わせて読むと、AI戦略から実装、運用までの全体像が見渡せるはずです。

関連記事

Claude Opus 4.7の新機能｜エージェントコーディングの進化とMythos Preview
ai

Claude Opus 4.7の新機能｜エージェントコーディングの進化とMythos Preview

AIエージェントとは？仕組み・チャットボットとの違い・ビジネス活用事例【2026年版】
ai

AIエージェントとは？仕組み・チャットボットとの違い・ビジネス活用事例【2026年版】

Gemini 3.1 Proの特徴と活用法｜Googleの最新AIモデルを徹底解説
ai

Gemini 3.1 Proの特徴と活用法｜Googleの最新AIモデルを徹底解説