コンテキストエンジニアリングとは？AIコーディングのためのガイド（2026年版）

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

コンテキストエンジニアリングとは、言語モデルが各推論呼び出しで目にするトークンのセット全体を設計・厳選・管理し、タスクを完了するために必要な情報を、十分に——しかしちょうど十分なだけ——持たせる専門分野です。そのトークンのセットにはいくつかの層があります。システムプロンプト、ツールの説明、渡すコードファイル、会話履歴、ツールの実行結果、そして長期メモリ（例えばCLAUDE.mdファイル）です。

簡単に言えば、プロンプトエンジニアリングは「この指示をどう上手く言い表すか？」を問うのに対し、コンテキストエンジニアリングは「コンテキストウィンドウに何を、どのタイミングで読み込み、何を除外するか？」を問います。Anthropicはこれを、エージェントが多くのループを実行しデータをますます蓄積していく中で自然に生じる進化だと説明しています（Effective context engineering for AI agents、2025-09-29公開を参照）。

AIコーディングでは、ここが核心です。同じモデル、同じリクエストでも、間違ったファイルを読み込んだり、履歴を膨れ上がらせたり、プロジェクトの規約を忘れたりすれば、生成されるコードは仕様からずれていきます。コーディングエージェントの出力品質は、モデルよりもコンテキストに左右されます。だからこそ、コンテキストを厳選する術を知る開発者は、チームメイトがすでに使っているのとまったく同じツールから、より多くを引き出せる傾向があるのです。

コンテキストエンジニアリングとプロンプトエンジニアリングの違い

多くの人がこの2つの用語を同じ意味で使っています。プロンプトエンジニアリングは時代遅れになったわけではありません——ただ、今ではコンテキストエンジニアリングの内側にある1つの層になっています。プロンプトは特定の指示をどう言い表すかであり、コンテキストはその指示を取り巻く情報環境の全体です。

この一文は壁に貼っておく価値があります。悪いプロンプトのコストは1つの悪い回答だけ。しかしCLAUDE.mdの悪い1行は、何ヶ月にもわたってすべてのリクエストにかかる税になります。これこそが、コンテキストエンジニアリングのレバレッジがはるかに大きい理由です——1か所を直せば、その後の何千ものセッションが恩恵を受けます。プロジェクトの規約ファイルをきちんと書きたい方は、Claude Code向けにしっかりしたCLAUDE.mdを書くためのガイドをご覧ください。

AIコーディングでコンテキストが重要な理由（コンテキストウィンドウとトークン予算）

どのモデルにもコンテキストウィンドウ——一度に「見る」ことのできるトークン数の上限——があります。現在Claude Codeで使われているClaudeモデルは、おおよそのウィンドウを持ち、これは数百ページ分のテキストに相当します。多いように聞こえますが、実際の作業では思っているより早く使い切ってしまいます。

「大きなウィンドウ」が「良い記憶」を意味しない理由は、2つの現象で説明できます。

• アテンション予算は減っていく：トークンを追加するたびに、モデルのアテンションは薄まります。詰め込めば詰め込むほど、モデルが本当に重要な細部に注意を向け続けるのは難しくなります。コンテキストは無限の倉庫ではなく、希少な資源です。
• コンテキストの劣化／「中間で迷子になる」：長い会話の中間に置かれた情報は、冒頭や末尾の情報よりもモデルが見落としやすくなります。これが、コーディングエージェントが数十ターン前に言ったことをしばしば「忘れ」たり、長いセッションの後に誤った回答をしたりする理由です。

自分で測れる数字があります。「常時オン」の構成（システムプロンプト、ツール定義、メモリ）だけですでにウィンドウの約10〜20%を占めているなら、残りがコード・履歴・ツール出力に使える分です。合計の使用量がウィンドウの大半を超えると、品質は落ち始めます——そこが圧縮やリセットが必要になるタイミングです。コンテキストを厳選するとは、まさに本当に重要なものを予算内に収め続ける作業のことです。

実用的なメンタルモデルとして、コンテキストウィンドウはファイルキャビネットではなく机だと考えてください。どれだけ広い机でも、いずれは散らかります。すべてを積み上げてしまえば、必要な1枚の書類を見つけるのに時間がかかります。モデルも同じで、「すべてのトークンを丁寧に均等に読む」わけではなく、アテンションを配分します。だからこそ、本当に必要な数個のファイルだけに絞った集中的なセッションは、「リポジトリ全体を放り込んで尋ねる」セッションよりも高品質なコードを生み出すのが普通です。AIコーディングでは、机を片付けておく規律が、正しいモデルを選ぶことと同じくらい重要なのです。

コンテキストエンジニアリングの4つの戦略（Write, Select, Compress, Isolate）

コミュニティ（LangChain、LlamaIndex、その他多数）は、4つの戦略というコンパクトな思考フレームワークに収束してきました。日々のコーディングワークフローにコンテキストエンジニアリングを適用するとき、これが最も覚えやすいセットです。

Write - 外部に退避する

すべてをコンテキストに詰め込む代わりに、情報を外に押し出します。計画・メモ・決定事項をファイルに書き出すのです（例えばNOTES.md、スクラッチパッド、あるいはCLAUDE.mdのような持続的なメモリ）。コンテキストは情報へのポインタだけを保持し、必要になったときに再読み込みします。

Select - 必要なものだけを取り込む

コンテキストを希少なものとして扱いましょう。リポジトリ全体を放り込むのではなく、今のタスクに必要なファイルやスニペットだけを読み込みます。これは検索拡張（RAG）、@file構文、そしてジャストインタイム検索の精神です——事前に読み込むのではなく、必要になった瞬間にデータを取得するのです。

Compress - 要約する

長い会話履歴やツール出力は、保持する前に要約します。Anthropicはこの手法をcompactionと呼んでいます。コンテキストが埋まりそうになったら、会話の末尾全体を引きずるのではなく、これまでやったことを短い要約に凝縮して続行するのです。

Isolate - 切り離す

補助的なタスク（調査、レビュー、参照）を、独自のクリーンなコンテキストを持つ別のsubagentに移します。subagentは作業を終えると、まとまった要約だけをオーケストレーション役のエージェントに返します——雑然とした詳細がメインのコンテキストを汚すことはありません。例えば、馴染みのないライブラリを学ぶ必要があるとき、ドキュメントページ全体をメインのコンテキストに引き込むのではなく、subagentにドキュメントを読ませて「使うべき3つの関数と、その呼び出し方」を返してもらうのです。

この4つの戦略は互いに排他的ではありません——実際のセッションでは、たいてい4つすべてを使います。計画をNOTES.mdに書き（Write）、編集中のファイルだけを読み込み（Select）、履歴が長くなったら圧縮し（Compress）、調査はサブエージェントに退避します（Isolate）。このフレームワークを身につけると、Claude Codeのあらゆる機能を「これはどのコンテキスト戦略に役立つのか？」というレンズを通して見るようになります。

Claude Codeで実践するコンテキストエンジニアリングの手法

ここが最も重要な部分です。上記の4つの戦略を、Claude Codeで日々使うツールに対応づけていきます。Claude Codeの強みは、各機能がコンテキスト戦略に対応づけられることです——だからコマンドを丸暗記する代わりに、「このコマンドはどんなコンテキストの問題を解決するのか？」と問う習慣を身につけましょう。

• CLAUDE.md = 持続的なメモリ（Write）。このファイルにはプロジェクトの規約、リポジトリ構造、やるべきこと・やってはいけないことが記されます。あらゆるセッションに読み込まれるため、ここに最大のレバレッジが宿ります——一度きちんと書けば、すべてのリクエストで恩恵を受けられます。
• /compactと/clear（Compress＋リセット）。コンテキストがほぼ埋まったとき、/compactは履歴を要約に圧縮します。/clearはコンテキストを一掃し、まったく新しいタスクに移るときにゼロから始められるようにします。
• /context（計測）。このコマンドは使用中のトークンの内訳を表示します——トークンを食っているものは、見えるようになって初めて最適化できます。
• サブエージェント（Isolate）。調査やレビューの作業をサブエージェントに任せ、彼ら自身のコンテキストを「消費」させて結果だけを返させます。Claude Codeでサブエージェントを使うためのガイドをご覧ください。
• MCPと@file（Select）。事前に読み込むのではなく、外部ソースからジャストインタイムでデータを読み込みます。MCPに馴染みがなければ、MCPとは何かを読んでみてください。
• プランモード／NOTES.mdのスクラッチパッド（Write）。長い計画はコンテキストの外に保持し、エージェントは必要なときだけそれを参照します。

短く実用的なCLAUDE.mdの例——トークンを使いすぎることなく、エージェントを仕様に沿わせるのに十分なものです。

# CLAUDE.md

## Project
Booking API, Node.js + Fastify + PostgreSQL (Prisma).

## Structure
- src/routes - endpoint definitions
- src/services - business logic
- src/db - Prisma schema & migrations

## Conventions (DO)
- Validate input with zod at the route layer
- Every query goes through a service; never call Prisma directly in a route
- Commit with Conventional Commits

## Avoid (DON'T)
- Do not add a new dependency without asking first
- Do not edit a migration file that has already been merged
- Do not log user data to the console

トークン予算の管理：計測と最適化

コンテキストエンジニアリングは勘に頼る作業ではありません——「計測してから最適化する」というループです。

1. /contextを読むことで、トークンがどこに割り当てられているかを確認します。システム、ツール、メッセージ、ファイル、出力です。
2. トークンを食っている犯人を特定する：たいていは長いツール出力（ログ、テスト結果）、丸ごと読み込まれた大きなファイル、あるいは肥大化した会話履歴です。
3. 原因に対処する：履歴が長いときは圧縮し（/compact）、ファイルが大きいときは選択的に読み込み（ディレクトリ全体ではなく@file）、補助的なタスクがうるさすぎるときはサブエージェントに切り離します。
4. 新しいセッションを始めるタイミングを知る：本当にタスクを切り替えるときは、古いコンテキストを引きずり回すより、/clearや新しいセッションのほうが優れています。

現場で試された習慣を1つ。長いセッションの開始時と中盤に、特に大きな出力を返すコマンド（ビルド、テスト、ログ）の直後には、/contextにざっと目を通す習慣をつけましょう。トークンを食っている犯人は、編集中のコードではなく、前回の実行から貼り付けられたログの山であることがとても多いのです。早めに気づけば、たった1回の/compactや新しいセッションで、予算の大半を取り戻せます。

なぜそこまでする価値があるのか？トークンはお金であり、レイテンシです。コンテキストが無駄なく引き締まっているほど、1ターンあたりのコストは下がり、応答は速くなります——そして同じくらい重要なことに、モデルが気を散らされないため回答の品質が上がります。コスト面が気になる方は、Claude Codeのコストとトークン最適化の記事を読んで、トークン数を実際の請求額と結びつけてみてください。

コンテキストエンジニアリングでよくある失敗

正直なところ、コーディングエージェントの「間抜けな」エラーの多くは、モデルが弱いからではなく、コンテキストが壊れていることから生じます。失敗の種類を見分けられれば、ツールのせいにする代わりに素早く修正できます。よくある4つのパターンです。

• コンテキストの汚染（context poisoning）：誤った情報（誤った前提、その後変更された古い決定事項）がコンテキストに居座り、エージェントを間違った方向へ導き続けます。予防：気づいたらすぐに修正するか/clearし、エージェントを「間違った土台の上で自信満々」のままにしないこと。
• コンテキストの散漫化（context distraction）：無関係な情報が多すぎて、モデルのアテンションが薄まります。予防：選択的に読み込み、コンテキストは最小限かつ十分に保つこと。
• コンテキストの衝突（context clash）：矛盾する2つの指示が共存します（例えばCLAUDE.mdはライブラリAを使えと言い、会話ではBを求めている）。予防：規約の出所を一貫させ、方針を変えたらメモリを更新すること。
• コンテキストの劣化（context rot）：会話が長くなりすぎると品質が低下します。予防：適切なタイミングで/compactし、結果をファイルに固定してから、セッションをリフレッシュすること。

コンテキストエンジニアリングを支えるツールとキット

上記の手法のほとんどは、完全に手作業でできます。CLAUDE.mdを書き、/compactと入力し、サブエージェントを立ち上げる。始めるのに何かを買う必要はありません。それに加えて、これらのパターン——メモリ、compaction、isolate——をパッケージ化した、あらかじめ用意されたスキル／サブエージェントのバンドルもあります。ゼロから作らずに済むわけです。例えばClaude Code向けのAgentKit（リンク経由で20%オフ）バンドル（ak CLI。これはOpenAIのAgentKitとは別の製品である点に注意）です。こうしたキットがコンテキストのパターンをどうパッケージ化しているのか気になる方は、AgentKitレビューを読んでください。そして、特にメモリとコンテキストについてさらに深く知りたい方は、Claude Codeでのコンテキストとメモリの管理をご覧ください。

よくある質問（FAQ）

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

プロンプトエンジニアリングは、単一のターンにおける特定の指示を調整します。コンテキストエンジニアリングは、多くのターンにわたるトークンのセット全体——システムプロンプト、ツール、コード、履歴、メモリ——を管理します。プロンプトエンジニアリングは今や、コンテキストエンジニアリングの内側にある1つの層です。

コンテキストエンジニアリングを学ぶには、コーディングができる必要がありますか？

概念を理解するだけなら必要ありませんが、AIコーディングに応用したいのであれば大いに必要です。最も効果的な手法（CLAUDE.mdを書く、読み込むファイルを選ぶ、履歴を圧縮する、サブエージェントを切り出す）は、いずれも実際のプログラミングワークフローと結びついています。

Claude Codeのコンテキストウィンドウは何トークンですか？

Claude CodeのClaudeモデルは、おおよそ数十万トークンのウィンドウを持ちます（上限やモデルは急速に変わるため、頼りにする前に公式のClaude Codeドキュメントで正確な数値を確認してください）。数字そのものよりも大切なのは、/contextで計測し、重要なものを予算内に収める方法を知っていることです。

/compactはいつ使えばいいですか？

会話履歴が長くなってコンテキストがほぼ埋まっているものの、同じタスクを続けたいときです。/compactは会話を要約に圧縮し、作業の流れを保ちます。まったく別のタスクに切り替えるなら、圧縮するのではなく/clearを使うか、新しいセッションを開いてください。

CLAUDE.mdはコンテキストエンジニアリングですか？

はい、それはWrite戦略の教科書的な例です。毎回指示を繰り返す代わりに、プロジェクトの規約を持続的なファイルに記録し、あらゆるセッションに読み込ませます。良いCLAUDE.mdを書くことは、存在するコンテキスト施策の中でも最もレバレッジの高いものの1つです。

コンテキストエンジニアリングはRAGに取って代わりますか？

いいえ——RAG（検索拡張）は、それ自体がコンテキストエンジニアリング内のSelect戦略の一部です。コンテキストエンジニアリングはより広いフレームワークであり、RAGは適切な情報をコンテキストに読み込むための1つの具体的な手法です。

まとめと次のステップ

コンテキストエンジニアリングは、効果的なAIコーディングのための基礎スキルです。大切なのは「どのモデルが最強か」ではなく「どれだけ上手くコンテキストを厳選するか」です。4つの戦略——Write, Select, Compress, Isolate——を身につけ、/contextで計測し、4つのコンテキスト失敗タイプを早めに捉える。そうすれば、コーディングエージェントを「忘れっぽい」存在から信頼できる存在へと変えられます。メモリの手法をさらに深く知るにはClaude Codeでのコンテキストとメモリの管理を、コンテキストとコストを結びつけるにはClaude Codeのコストとトークン最適化を読み進めてください。AIと一緒に作業し始めたばかりなら、バイブコーディングとは何かやAIスロップを避ける方法もぜひご覧ください。