目次

AIをうまく使う技術の主役が、「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ移りつつある。プロンプト（指示文）を磨くだけでなく、モデルに渡す情報全体（コンテキスト）を設計・管理する——これが2026年のAI活用、とくにAIエージェントづくりの必修スキルになっている。

本記事では、コンテキストエンジニアリングとは何か、なぜ重要なのか（鍵は「context rot」）、そして具体的なテクニックまでを初心者向けに整理する。

CONTEXT ENGINEERING · プロンプトの次

コンテキストは「有限の予算」

— 最小で最も効く情報だけを残す技術

🎯

取捨選択する

全部詰め込まず、本当に効く情報だけを選んで入れる。

🧹

こまめに整理

不要になった履歴やツール結果を要約・削除して軽く保つ。

📥

必要な時に取りに行く

最初に全部読み込まず、必要になった瞬間に取得する。

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

コンテキストエンジニアリングとは、Anthropicの定義を借りれば「推論のあいだにモデルへ渡す最適なトークン（情報）の集合を、選び・保つための戦略全般」のことだ（同社「Effective context engineering for AI agents」2026年3月）。プロンプト（指示文）だけでなく、システムプロンプト・ツール・会話履歴・外部データなど、コンテキストウィンドウに入るすべてを対象にする。

イメージは「机の上の整理術」だ。作業に必要な資料だけを手の届く範囲に置き、使い終わったものは片づける。机（＝コンテキストウィンドウ）にむやみに資料を積み上げると、かえって作業効率が落ちる——AIでも同じことが起きる。だからこそ「何を載せ、何を載せないか」の設計が効いてくる。

💡 ひとことで：プロンプトエンジニアリング＝「指示文を磨く」。コンテキストエンジニアリング＝「モデルが見る情報全体を設計する」。後者は前者を含むより広い技術だ。

2. なぜ重要？「context rot」という壁

「コンテキストウィンドウが100万トークンあるなら、全部入れればいいのでは？」——ここに落とし穴がある。トークンを増やすほど、モデルの精度はむしろ下がる。この現象は「context rot（コンテキストの劣化）」と呼ばれる。

2025年にChromaが18の主要モデル（GPT・Claude・Gemini等）で検証したところ、例外なく、入力が長くなるほど回答の信頼性が落ちた。理由はモデルの「注意（attention）」が有限の予算だからだ。トークンが1つ増えるたびにその予算は薄まり、関連情報を取りこぼしやすくなる。とくに長い文脈の「中盤」に置かれた情報は見落とされやすい（lost in the middle）。

入力が長くなるほど精度は落ちる（イメージ）

短い文脈（必要な情報だけ）高精度
中くらい（履歴・ツール結果が蓄積）低下
長すぎる文脈（全部詰め込み）大きく低下

※傾向を示す概念図。実測ではStanfordの研究（2023）で約4,000トークン規模の参照情報を与えた際に正答率が70〜75%から55〜60%へ低下した例などが報告されている。難しいタスクほど劣化が大きい。

つまり「文脈は長ければ長いほど良い」は誤り。だからこそ、最小で最も効くトークンだけを残すコンテキストエンジニアリングが必要になる。とくに長時間動くAIエージェントやコーディングエージェントでは、context rotが失敗の主因になりやすい。

3. コンテキストには何が入っているか

「コンテキスト＝プロンプト」と思われがちだが、実際にはもっと多くの要素が同じ窓に同居している。これら全部が予算を消費する。

システムプロンプト

役割・ルール・口調などの土台となる指示。

ツールの定義・結果

MCP等のツール説明や、その実行結果。

会話・作業の履歴

これまでのやり取りやモデル自身の思考の蓄積。

外部データ

取得した文書・コード・RAGの検索結果など。

長い作業ほど、履歴やツール結果がどんどん積み上がる。放っておけば窓はすぐ「中盤に埋もれた重要情報」だらけになる。だから次の整理テクニックが要る。

4. 主要テクニック6つ

Anthropicや実務の知見から、効果の高い6つを挙げる。共通する原則は「最小で最も効くトークン集合を選ぶ」こと。

① 適切な粒度の指示

細かすぎる条件分岐は脆く、曖昧すぎると効かない。「具体的だが柔軟」な中間を狙う。

② ツールを厳選する

役割が重複する・どれを使うべきか曖昧なツールは外す。少数の明確なツールに絞る。

③ ジャストインタイム取得

最初に全部読み込まず、ファイルパスやリンクだけ持ち、必要な瞬間に取得する。Claude Skillsの段階的開示と同じ発想。

④ コンパクション（要約圧縮）

窓が埋まってきたら履歴を要約し、新しい窓に引き継ぐ。決定事項や未解決点は残し、冗長なツール結果は捨てる。

⑤ メモ（外部メモリ）

進捗や要点を窓の外のファイルに書き出し、必要な時だけ読み戻す。長期タスクの一貫性を保つ。

⑥ サブエージェントで分離

調査などの重い作業はサブエージェントに任せ、要約だけ本体へ返す。詳細な文脈を本筋から隔離する。

⚠️ やりすぎ注意：凝った仕組みより「動く一番単純なやり方」が先。まずは不要な情報を入れない・こまめに新しいセッションを始める、だけでも効果は大きい。

5. プロンプト・RAG・Skillsとの関係

近い概念と混ざりやすいので、位置づけを整理する。コンテキストエンジニアリングはこれらを束ねる「上位の考え方」だ。

  • プロンプトエンジニアリング：指示文を磨く技術。コンテキストエンジニアリングの一部に含まれる。
  • RAG：外部知識を検索して文脈に足す手法。「何を取得して入れるか」を担う一手段。
  • Skills：手順を必要な時だけ展開する仕組み。ジャストインタイム取得の具体例。

つまり「指示を磨く（プロンプト）」「知識を足す（RAG）」「手順を出し入れする（Skills）」——これらを「窓に何を載せ、何を片づけるか」という一つの設計問題として統合的に扱うのがコンテキストエンジニアリングだ。

6. 今日からできる実践

難しい実装の前に、誰でもすぐ効く習慣がある。

  • 話題が変わったら新しいチャットを始める：前の文脈を引きずらないだけで精度が戻る。最も簡単で効果的。
  • 長い資料は丸ごと貼らない：必要な箇所だけ抜き出して渡す。全文添付は逆効果になりやすい。
  • 長い作業は途中で要約させる：「ここまでの決定事項と残タスクを箇条書きにして」と頼み、それを起点に続ける（手動コンパクション）。
  • ツール・拡張を盛りすぎない：使わないMCPやスキルは外す。選択肢が多いほどモデルは迷う。

💡 コスト面でも有利：余計なトークンを載せないことは、そのままトークン代の節約にもなる。精度とコストが同時に改善する。

まとめ

コンテキストエンジニアリングを3点に整理する。

  • 正体：プロンプトを含む「モデルが見る情報全体」を設計・管理する技術。プロンプトエンジニアリングの次の段階。
  • 理由：トークンを増やすほど精度が落ちる「context rot」があるため。文脈は有限の予算。
  • コツ：最小で最も効くトークンだけを残す。厳選・整理（要約）・必要時取得・サブエージェント分離が武器。

まずは「話題が変わったら新セッション」「長文は要点だけ」から始めてみよう。仕組みをさらに知りたい人はClaude Skillsやハーネスエンジニアリングもあわせてどうぞ。

FAQ

Q. プロンプトエンジニアリングはもう不要？

A. いいえ。プロンプトエンジニアリングはコンテキストエンジニアリングの一部として今も重要です。指示文を磨く力の上に、情報全体を設計する視点が加わる、という関係です。

Q. コンテキストウィンドウが大きいモデルを使えば解決する？

A. 窓が大きくても context rot は起きます。容量があるからと全部詰め込むとむしろ精度が落ちることが研究で示されています。大きい窓は「余裕」であって「全部入れてよい」ではありません。

Q. 普通のチャット利用でも関係ある？

A. あります。「話題ごとに新しいチャットを始める」「長文は要点だけ貼る」だけで回答品質が上がります。エンジニアでなくても今日から使えるコツです。

Q. RAGとコンテキストエンジニアリングの違いは？

A. RAGは「外部知識を検索して文脈に足す」具体的手法の一つ。コンテキストエンジニアリングは「窓に何を載せ何を片づけるか」全体を扱う上位概念で、RAGはその構成要素です。