コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと4つの実装手法

コンテキストエンジニアリング（context engineering）は、LLMが推論する時点でコンテキストウィンドウに入っている情報全体を設計し、管理する技術です。対象はシステムプロンプト、ツール定義、会話履歴、検索結果、メモリまで含みます。プロンプトエンジニアリングが「どう頼むか」を磨くのに対し、こちらは「何を見せ、何を見せないか」を毎ターン決めます。本記事では、定義と用語の由来、プロンプトエンジニアリングとの違い、長いコンテキストで精度が落ちる仕組み、Write・Select・Compress・Isolateの4手法を一次情報で整理し、Pythonでの組み立て例とClaude APIの設定例を示します（2026年9月時点）。

まとめ｜コンテキストエンジニアリングの定義と導入判断の要点

• 定義：Anthropicは「LLMの推論中に最適なトークン（情報）の集合を選び、維持するための戦略群」と定義しています。プロンプト以外にコンテキストへ入る情報もすべて対象です。
• 原則：目標は情報を多く入れることではなく、望む結果を得る確率を最大にする「最小の高シグナルなトークン集合」を見つけることです。
• 違い：プロンプトエンジニアリングは1回の指示文を磨く作業、コンテキストエンジニアリングは毎ターン組み替わる入力全体の設計です。ツール呼び出しを重ねるエージェントほど後者の比重が上がります。
• 必要な理由：入力トークンが増えるほど、モデルが中身を正確に思い出す力は落ちます（context rot）。100万トークンの窓があっても「全部入れる」は解になりません。
• 手法：Write（窓の外へ書き出す）、Select（必要な分だけ取り込む）、Compress（要約や削除で縮める）、Isolate（サブエージェント等で窓を分ける）の4つです。
• 判断：単発の分類や要約ならプロンプトの改善で足ります。対話やツール結果の蓄積によって必要な情報が埋もれる場合は、コンテキストの選別と圧縮を見直してください。

コンテキストエンジニアリングの定義と用語が広まった経緯

Anthropicは2025年9月29日の技術ブログ「Effective context engineering for AI agents」で、コンテキストエンジニアリングを “the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts” と定義しました。プロンプトの外からコンテキストに入り込む情報まで含めている点が、この定義の要です。

同じ記事は、良いコンテキストエンジニアリングを “finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome” と表現しています。窓に空きがあるなら埋めた方がよい、という直感とは逆の原則です。

2025年6月のLütke氏・Karpathy氏による用語への言及

用語を広めた投稿としてよく引用されるのが、2025年6月のX（旧Twitter）上の2つの投稿です。ShopifyのCEOであるTobi Lütke氏は6月19日の投稿で、context engineeringという言葉の方が中核スキルをよく表すとし、それを “the art of providing all the context for the task to be plausibly solvable by the LLM” と書きました。

元OpenAIのAndrej Karpathy氏は6月25日の投稿でこれへ賛同し、実用レベルのLLMアプリでは “the delicate art and science of filling the context window with just the right information for the next step” がコンテキストエンジニアリングだと述べています。Karpathy氏は構成要素として、タスクの説明、few-shotの例、RAG、関連データ、ツール、状態と履歴、圧縮を挙げました。「次の一手に必要な情報だけ」という言い回しが、前述のAnthropicの原則と一致しています。

論文での扱いと2026年の企業向け整理

学術側では、2025年7月にarXivで公開されたサーベイ「A Survey of Context Engineering for Large Language Models」（arXiv:2507.13334）が、1,400本を超える論文を分析し、コンテキストの取得・生成、処理、管理を基礎要素、RAG・メモリ・ツール統合・マルチエージェントを実装形態として体系化しました。

2026年3月には、Vera V. Vishnyakova氏の単著プレプリント「Context Engineering: From Prompts to Corporate Multi-Agent Architecture」（arXiv:2603.09619）が公開されています。この論文は、良いコンテキストの基準として関連性（relevance）・十分性（sufficiency）・分離（isolation）・経済性（economy）・来歴（provenance）の5つを提案し、プロンプト→コンテキスト→意図（intent engineering）→仕様（specification engineering）と積み上がる成熟度モデルを示しました。査読前の論文なので、実務では5基準をレビューの観点表として借りる程度が妥当です。特に「来歴」は、後述の古い版の混入を防ぐ観点として使えます。

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

Anthropicは、コンテキストエンジニアリングをプロンプトエンジニアリングの “natural progression”（自然な発展形）と位置づけています。対立する概念ではなく、設計の対象が指示文から入力全体へ広がったと捉えると整理しやすくなります。

指示文そのものの書き方はプロンプトエンジニアリングの4要素と手法の使い分けとシステムプロンプトの指定方法と書き方で扱っています。

プロンプトの改善で足りる場面と足りない場面

入力が1回で完結し、参照する文書が固定で窓に余裕があるタスク（分類、翻訳、定型の要約）は、多くの場合プロンプトの改善で足ります。評価で必要な精度を満たしているなら、追加のコンテキスト管理は導入せず、構成を簡潔に保ちます。

一方、次の条件が当てはまる場合は、指示文だけでなく、渡している情報の不足や混入を点検してください。回答が社内規程のようにモデルの知らない情報に依存する、対話の蓄積で必要な情報が埋もれる、ツール結果が履歴に溜まっていく、同じ文書の新旧の版が検索にかかる、のいずれかです。典型的な失敗は、プロンプトに「最新の規程に従って回答すること」と書いたのに、コンテキストに旧規程が入っていて古い締め日を答えるケースです。原因は指示文ではなく入力にあるため、直す場所もコンテキストの側になります。

ハーネスエンジニアリングとの守備範囲の差

ハーネスエンジニアリングは、エージェントを動かす実行環境全体（ツールの権限、検証ループ、評価、失敗時の復帰）を設計する考え方です。コンテキストエンジニアリングは「モデルに何を見せるか」を担い、ハーネスはその外側で「モデルに何をさせ、結果をどう検証するか」を担います。Karpathy氏も前述の投稿で、問題を制御フローに分割する、呼び出すモデルを選ぶ、生成と検証の流れを作るといった処理を挙げ、コンテキストエンジニアリングはLLMアプリを構成する厚いソフトウェア層の “just one small piece” にすぎないと書いています。仕様・コンテキスト・ハーネスの三層で組む考え方はハーネスエンジニアリングのSpec・Context・Harnessの三層設計で解説しています。

長いコンテキストで精度が落ちる仕組み

コンテキストエンジニアリングが必要になる根本の理由は、入力を増やすほどモデルの性能が落ちることです。トークン上限の数え方と実効長はコンテキストウィンドウのトークン上限と有効長で詳しく扱っています。

Context Rotによる想起精度の低下

Anthropicは前述の記事で、context rotを「コンテキストウィンドウ内のトークン数が増えるほど、そこから情報を正確に思い出す能力が下がる」現象と説明し、程度の差はあってもすべてのモデルに現れるとしています。理由として、Transformerではn個のトークンにn²の組み合わせの関係が生じ、長くなるほど注意が薄く引き伸ばされる点を挙げ、コンテキストを「限界効用が逓減する有限の資源」として扱うよう求めています。

ベクトルデータベースを開発するChromaは、2025年7月14日の技術レポート「Context Rot」でGPT-4.1、Claude 4、Gemini 2.5、Qwen3を含む18のモデルを評価しました。単純なタスクでも入力長が伸びるだけで性能が落ち、その落ち方は一様ではない、というのが結論です。

Lost in the Middleによる中央の情報の見落とし

Liuらの論文「Lost in the Middle」（TACL 第12巻・2024年）は、必要な情報が入力の先頭か末尾にあるときに性能が高く、中央にあると大きく下がる傾向を報告しました。同じ文書を渡しても、置く位置で結果が変わるということです。RAGの設計での対策はLost in the Middle現象とRAGの設計対策にまとめています。

長いコンテキストで起きる4つの失敗

Drew Breunig氏は2025年6月22日の記事「How Long Contexts Fail」で、長いコンテキストの失敗を4つに分類しました。対策と合わせると次のとおりです。

コンテキストを構成する要素と設計の要点

Anthropicの記事は、要素ごとに設計の指針を示しています。窓に入る主な要素と、その指針を並べます。

システムプロンプトについてAnthropicは、条件分岐を細かくハードコードする書き方と、曖昧な抽象論だけの書き方を両極の失敗とし、その間の「ゴルディロックスゾーン」を狙うよう勧めています。ツールについては、機能が重なる大きなツール群を最も多い失敗の1つに挙げ、”If a human engineer can’t definitively say which tool should be used in a given situation, an AI agent can’t be expected to do better.” と書いています。例示の選び方はFew-shotプロンプトの例示の選び方と並べ方を参照してください。

検索結果の入れ方では、事前にすべてを取り込むのではなく、ファイルパスやクエリなどの軽い参照だけを持ち、ツールで必要時に読み込む「just in time」方式が紹介されています。Claude Codeは、CLAUDE.mdを最初から窓に入れ、ほかのファイルはglobやgrepで必要時に探す混合方式の例として挙げられています。要素ごとの実装の詳細はコンテキストの構成要素と最適化の実装、記憶の設計はエージェントメモリの短期記憶と長期記憶の設計で扱っています。

4つの実装手法：Write・Select・Compress・Isolate

LangChainは2025年7月2日のブログ記事「Context Engineering」で、主要なエージェントと論文の手法を調べ、コンテキスト管理をwrite・select・compress・isolateの4つに分類しました。

手法を足す順序とサブエージェントの費用

手を入れる順序は、Select→Compress→Write→Isolateを推奨します。検索結果の混入が原因なら、まずSelectで対象を絞ります。ただし、必要な根拠まで落とさないかを評価セットで確認します。Compressでは、Anthropicが “One of the safest lightest touch forms of compaction” と呼ぶツール結果の削除から始め、会話全体の要約は後に回します。

Isolateは最後に検討します。Anthropicの2025年9月の記事によれば、サブエージェントが数万トークンを使って調べても、主エージェントに返すのは多くの場合1,000〜2,000トークンの要約です。同社のマルチエージェント研究システムの報告（2025年6月）では、Claude Opus 4を主エージェント、Claude Sonnet 4をサブエージェントとする構成が、社内の調査タスク評価で単一のClaude Opus 4を90.2%上回りました。一方で、エージェントはチャットの約4倍、マルチエージェントは約15倍のトークンを使うとされています。採用は、並列化による品質や所要時間の改善が、追加のトークン費用と調整コストを上回るタスクに限定します。

Pythonでトークン予算付きのコンテキストを組み立てる例

Select・Compressと配置の工夫を、外部ライブラリなしのPythonで組んだ例です。社内ヘルプデスクを想定し、履歴の圧縮と検索結果の選別を示します。戻り値は選別結果の確認用で、LLMへ渡す検索本文やメッセージの組み立ては省略しています。トークン数は文字数からの概算で、本番ではモデル提供元のトークン計測APIで測ってください。

from dataclasses import dataclass

@dataclass
class Chunk:
    source: str
    text: str
    score: float             # 検索スコア（0〜1）
    superseded: bool = False # 改定で失効した文書か

def estimate_tokens(text: str) -> int:
    # 概算。本番は各社のトークン数計測API（Claudeなら messages.count_tokens）で測る
    return max(1, round(len(text) * 0.9))

def build_context(system, history, chunks, budget, keep_turns=4, min_score=0.5):
    used = estimate_tokens(system)
    report = {"system": used}

    # Compress: 古い会話は1行要約に置き換え、直近 keep_turns 件だけ原文で残す
    old, recent = history[:-keep_turns], history[-keep_turns:]
    summary = "過去の要点: " + " ／ ".join(t.split("。")[0] for t in old) if old else ""
    hist_tokens = estimate_tokens(summary) + sum(estimate_tokens(t) for t in recent)
    used += hist_tokens
    report["history"] = hist_tokens
    if used > budget:
        raise ValueError("システム指示と履歴だけで予算を超えています。履歴を削減してください。")

    # Select: スコアの低い断片は捨て、高い順に残り予算へ詰める
    picked, dropped = [], []
    for c in sorted(chunks, key=lambda c: c.score, reverse=True):
        cost = estimate_tokens(c.text)
        if c.superseded or c.score < min_score or used + cost > budget:
            dropped.append(c.source)
            continue
        picked.append(c)
        used += cost
    report["retrieved"] = used - report["system"] - hist_tokens

    # 並べ方: 最も関連の高い断片を先頭と末尾に置き、中央に埋もれさせない
    ordered = picked[0::2] + picked[1::2][::-1]
    return {"summary": summary, "recent": recent, "chunks": [c.source for c in ordered],
            "dropped": dropped, "tokens": report, "total": used, "budget": budget}

if __name__ == "__main__":
    system = "あなたは社内ヘルプデスクです。規程に書かれていないことは推測せず、担当部署を案内してください。"
    history = ["締め日を質問。月末と回答", "出張の事前申請を質問。必要と回答", "領収書の宛名を質問。会社名と回答",
               "交通系ICの扱いを質問。利用履歴で可と回答", "海外出張の日当を質問。規程第9条と回答",
               "立替金の振込日を質問。翌月25日と回答", "宿泊費の上限を質問。役職別と回答", "領収書を紛失した場合を質問"]
    chunks = [
        Chunk("経費規程 第5条", "経費精算は毎月末日締め、翌月10日までに申請する。" * 3, 0.91),
        Chunk("経費規程 第7条", "出張旅費は事前申請が必要で、上限額は役職ごとに定める。" * 3, 0.84),
        Chunk("FAQ 12", "領収書を紛失した場合は、支払証明書で代替できる。" * 3, 0.77),
        Chunk("旧規程 2019年版", "経費精算は毎月20日締め。" * 3, 0.62, superseded=True),
        Chunk("社内報 2024年3月", "新しい経費システムを導入しました。" * 3, 0.41),
    ]
    for budget in (250, 400):
        r = build_context(system, history, chunks, budget)
        print(f"budget={budget} total={r['total']} tokens={r['tokens']}")
        print(f"  chunks={r['chunks']}")
        print(f"  dropped={r['dropped']}")
    print("summary=" + r["summary"])

Python 3.9.6で実行した出力です。

budget=250 total=217 tokens={'system': 42, 'history': 107, 'retrieved': 68}
  chunks=['経費規程 第5条']
  dropped=['経費規程 第7条', 'FAQ 12', '旧規程 2019年版', '社内報 2024年3月']
budget=400 total=355 tokens={'system': 42, 'history': 107, 'retrieved': 206}
  chunks=['経費規程 第5条', 'FAQ 12', '経費規程 第7条']
  dropped=['旧規程 2019年版', '社内報 2024年3月']
summary=過去の要点: 締め日を質問 ／ 出張の事前申請を質問 ／ 領収書の宛名を質問 ／ 交通系ICの扱いを質問

出力から読み取れる設計上の判断は3つあります。

• 履歴が予算の最大の消費者になる：予算250では履歴が107トークンと全体の半分近くを占め、検索結果は1件しか入りませんでした。最後の質問「領収書を紛失した場合」に答えるFAQ 12が落ちています。この問いに答えられないなら、削るべきは検索結果ではなく古い履歴です。
• 類似度だけで選ぶと旧版が入る：旧規程（スコア0.62）はしきい値0.5を超えており、失効フラグがなければ予算400で取り込まれ、現行の第5条と締め日が矛盾します（Clash）。検索結果の選別には、類似度のほかに版や施行日などの来歴のメタデータが必要です。
• 素朴な要約は答えを落とす：1文目だけを残す要約では「締め日を質問」だけが残り、「月末と回答」が消えました。圧縮では、質問よりも決定事項と回答、未解決の論点を優先して残します。

Claude APIで使えるコンテキスト管理の機能

API側にも、Compressを肩代わりする機能があります。2026年9月時点のClaude APIでは次の3つが使えます（いずれもベータ）。

ツール結果の削除は、既定で入力が100,000トークンを超えると古いツール結果から順に消し、直近3回分を残します。消した結果はプレースホルダーに置き換わります。要約（compaction）は既定で150,000トークン（最小50,000）で発動し、サーバー側で古いターンを要約に置き換えます。公式ドキュメントは、利用できる環境ではアプリ側から要約の時期を指示する「Compaction on demand」（ベータヘッダー compact-2026-09-04）を優先するよう案内しています。

ツール結果の削除をPython SDKで指定する例です。anthropic 1.9.0はPython 3.10以上を必要とし、環境変数ANTHROPIC_API_KEYの設定が必要です。この例は設定の送信までで、ツール実行と結果を履歴へ追加するループは省略しています。初回リクエストには削除対象のツール結果がないため、削除動作は発生しません。

import anthropic

client = anthropic.Anthropic()

tools = [{
    "name": "read_file",
    "description": "リポジトリ内のファイルを読み、内容を返す",
    "input_schema": {
        "type": "object",
        "properties": {"path": {"type": "string"}},
        "required": ["path"],
    },
}]
messages = [{"role": "user", "content": "src配下の設定読み込み処理を調べて、未使用の設定キーを挙げて"}]

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    betas=["context-management-2025-06-27"],
    tools=tools,
    messages=messages,
    context_management={
        "edits": [{
            "type": "clear_tool_uses_20250919",
            "trigger": {"type": "input_tokens", "value": 30000},        # 入力が3万トークンを超えたら発動
            "keep": {"type": "tool_uses", "value": 3},                  # 直近3回分のツール結果は残す
            "clear_at_least": {"type": "input_tokens", "value": 5000},  # 5千トークン未満しか消せないなら見送る
        }]
    },
)
print(response.stop_reason)
print(response.context_management)

Python 3.12.13とanthropic 1.9.0でこのコードをローカルのモックサーバーへ送り、anthropic-beta: context-management-2025-06-27 ヘッダーと context_management がそのままリクエストに載ることを確認しました。削除が起きると、レスポンスの context_management.applied_edits に消したツール呼び出しの数（cleared_tool_uses）と削減したトークン数（cleared_input_tokens）が返ります。

注意点はプロンプトキャッシュです。公式ドキュメントのとおり、ツール結果を消すとその位置以降のキャッシュ済みプレフィックスが無効になります。clear_at_least を指定して、キャッシュを捨てるのに見合う量を一度に消す設定にしてください。削除から残したいツール（ユーザー情報の取得など）は exclude_tools に名前を並べます。Claude Codeの自動要約の発動点と設定はClaude Codeのauto-compactの発動点と無効化の設定で解説しています。

導入で陥りやすい失敗と効果の測り方

• 窓の上限まで詰める：100万トークン対応のモデルでも、関連の薄い文書を足すほどcontext rotで精度が落ちます。まず取り込む量を減らしてください。
• 類似度だけで検索結果を選ぶ：改定前の規程や古い版のドキュメントが混入し、矛盾した回答になります。来歴のメタデータで除外します。
• 要約で決定事項を失う：エージェントが同じ調査をやり直し、結果としてトークンが増えます。要約の指示で、残す項目を明示してください。
• ツールを増やしすぎる：使い分けを人が説明できないツール群は、モデルの選択ミスを招きます。
• 毎ターン先頭を書き換える：日時やリクエストIDをシステムプロンプトの先頭に入れると、プロンプトキャッシュが毎回外れます。変わる情報は後ろに置きます。

効果は、変更前後を同じ評価セットで比べて測ります。初期評価の目安として、実際の問い合わせから20〜50件を固定し、正答率・1件あたりの入力トークン・応答時間を記録してください。問い合わせの種類と失敗例を含め、結果のばらつきに応じて件数を増やします。加えて、トレースで各ターンのコンテキストの内訳（履歴・検索結果・ツール結果の割合）を残すと、予算を食っている要素が特定できます。トレースと評価の仕組みはLangSmithのトレース送信と評価の実行で扱っています。

よくある質問

コンテキストエンジニアリングとは、ひとことで言うと何ですか？

LLMが回答する時点で見ている情報全体（指示、ツール、履歴、検索結果、メモリ）を、必要十分な量に選んで組み立てる技術です。Anthropicは「最小の高シグナルなトークン集合」を見つけることを原則としています。

プロンプトエンジニアリングとコンテキストエンジニアリングの違いは何ですか？

プロンプトエンジニアリングは1回の指示文の書き方を磨き、コンテキストエンジニアリングは毎ターン変わる入力全体を設計します。Anthropicは後者を前者の自然な発展形と位置づけており、置き換えではなく対象範囲の拡大です。

コンテキストエンジニアリングのやり方は？何から始めればよいですか？

まず現在のコンテキストの内訳をトレースで測り、どの要素がトークンを使っているかを把握します。次に検索結果や履歴の取り込み量を絞り（Select）、ツール結果の削除や要約（Compress）を足します。サブエージェントによる分割は、費用が数倍になるため最後に検討します。

コンテキストエンジニアリングとハーネスエンジニアリングの違いは何ですか？

コンテキストエンジニアリングは「モデルに何を見せるか」を、ハーネスエンジニアリングは「モデルに何をさせ、結果をどう検証するか」という実行環境全体を扱います。コンテキストはハーネスを構成する一層です。

コンテキストウィンドウが大きいモデルなら、コンテキストエンジニアリングは不要ですか？

不要にはなりません。Anthropicはcontext rotを程度の差はあってもすべてのモデルに現れる性質と説明しており、Chromaが2025年7月に評価した18モデルでも、入力長の増加に伴う性能低下が観測されました。窓が大きいほど「入れすぎ」が起きやすくなる点にも注意が必要です。

関連記事

• コンテキストの構成要素と最適化の実装｜メモリ・RAG・compactionでコンテキストロットを防ぐ
• ハーネスエンジニアリングとは？Spec・Context・Harnessの三層で組む設計と実装
• コンテキストウィンドウとは？トークン上限の数え方と有効長・溢れ対策を実装者向けに解説
• Lost in the Middle現象とは｜RAG精度が落ちる仕組みと設計での対策
• プロンプトエンジニアリングとは？4要素と手法の使い分け・資格までを解説