コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いから実践方法まで徹底解説
コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いから実践方法まで徹底解説
目次
目次を読み込み中...
「src/lib/auth/ は変更しないで」とClaude Codeに指示したのに、リファクタリングを進めるうちにそのディレクトリのファイルが書き換えられていた。Cursorでコードを書かせていたら、会話の後半から急にスタイルが崩れ始め、プロジェクトのコーディング規約を無視した実装が返ってくるようになった——そういった経験がある開発者は数多くいらっしゃるのではないでしょうか。
原因はプロンプトの文言ではありません。AIコーディングエージェントに渡している「コンテキスト全体の設計」が問題です。この課題を体系的に解決するアプローチが、コンテキストエンジニアリングです。
この記事では、コンテキストエンジニアリングの基本定義から、CLAUDE.md や MCP を使った実践的なコンテキスト設計、そしてAIコーディングエージェントが陥りやすい失敗パターンとその対策まで、ソフトウェア開発者の視点で解説します。
コンテキストエンジニアリングとは？基本定義と登場背景
コンテキストエンジニアリングとは、「LLMのコンテキストウィンドウに何を・どの順番で・どれだけ渡すかを設計・最適化するエンジニアリング手法」です。単一のプロンプト文言を磨くプロンプトエンジニアリングとは異なり、システムプロンプト・会話履歴・コードベースの検索結果・ツール出力といった複数の情報源を統合的にマネジメントすることを指します。
なぜ今「コンテキストエンジニアリング」が注目されるのか
注目が高まった直接のきっかけは、2025年6月にAI研究者のAndrej Karpathy氏がX（旧Twitter）上で「context engineering is the delicate art and science of filling the context window with just the right information for the next step」と投稿したことです（※1）。同月、Shopify CEOのTobi Lütke氏もXへの公開投稿でコンテキストエンジニアリングの重要性を支持し（※2）、業界全体での認知が急速に広まりました。
背景にあるのは、コンテキストウィンドウ長の急速な拡大です。OpenAIのGPT-5.4とAnthropicのClaude Sonnet 4.6は、いずれも1Mトークンのコンテキストウィンドウを持ちます（※3）。「何を詰め込むか」よりも「何を選び、どう構造化して渡すか」が出力品質を左右する時代に移行しました。Claude CodeやCursorのようなAIコーディングエージェントが日常的なツールになった今、この設計課題は開発者全員に関係します。
コンテキストウィンドウとは何か：AIの「作業デスク」
コンテキストウィンドウは、LLMが1回の推論で参照できる全テキストの領域です。「AIの作業デスク」に相当し、デスクの上に置けるものは有限です。
開発者の視点でいうと、AIコーディングエージェントのコンテキストウィンドウには次のものが積み込まれています。
- プロジェクトの指示ファイル（CLAUDE.md など）
- ユーザーの依頼メッセージ
- 過去の会話履歴
- ファイル読み込みや検索のツール呼び出し結果
- MCPサーバーから取得したDBスキーマやAPIドキュメント
モデルはこのデスクの上にある情報だけを根拠にコードを書きます。デスクに何が載っているかをエンジニアがコントロールすること、それがコンテキストエンジニアリングです。
プロンプトエンジニアリングとの違い
プロンプトエンジニアリングとは、LLMに与える指示文の設計・最適化を指します。Few-shotによる例示、Chain-of-Thoughtによる推論誘導、システムプロンプトの役割設定などが中心です。単一リクエストの品質を高めるアプローチであり、多くの現場で最初に取り組まれます。
ただし、プロンプトエンジニアリングには構造的な限界があります。設計の対象が「その場の指示文」に限定されるため、AIコーディングエージェントが複数ファイルを横断して長時間作業するシナリオや、外部データを動的に参照するRAGシステムには対応しきれません。
| 比較軸 | プロンプトエンジニアリング | コンテキストエンジニアリング |
| スコープ | 単一の指示文 | コンテキストウィンドウ全体 |
| 対象 | 指示・例示・推論誘導 | 指示・記憶・コードベース・ツール出力・状態管理 |
| タイミング | 静的（事前設計） | 動的（実行時に構築・更新） |
| 主な手法 | Few-shot、CoT、役割指定 | CLAUDE.md、RAG、MCP、コンテキスト圧縮 |
重要なのは、コンテキストエンジニアリングはプロンプトエンジニアリングを否定するものではないという点です。Few-shotやChain-of-Thoughtはコンテキスト設計の一構成要素として引き続き有効です。より広い責任範囲でLLMシステム全体を設計する概念がコンテキストエンジニアリングであり、AIコーディングエージェントやRAGシステムを本番品質で動かすためには、この上位の視点が不可欠です。
AIコーディングエージェントのコンテキストを解剖する
ここから実践的な話に入ります。Claude CodeやCursorのようなAIコーディングエージェントが、実際にどんな情報をコンテキストウィンドウに積み込んでいるかを整理します。
1. 永続コンテキスト：CLAUDE.md / AGENTS.md
最も設計コストが低く、最も効果が高いのが永続コンテキストファイルです。Claude Codeであれば CLAUDE.md、OpenAI Codex系エージェントであれば AGENTS.md が相当します。これらのファイルはエージェントが起動するたびにコンテキストウィンドウの先頭に自動注入されます。
「セッションを越えてもAIに覚えていてほしい情報」はここに書く、というのが基本原則です。
悪い例（抽象的すぎる）：
# Instructions
- 常にTypeScriptを使ってください
- ベストプラクティスに従ってください
- クリーンなコードを書いてください「ベストプラクティス」はモデルが解釈する余地が大きすぎます。「クリーンなコード」は指示として機能しません。
良い例（具体的な制約・技術スタック・禁止事項を明記）：
# CLAUDE.md
## 技術スタック
- 言語: TypeScript 5.x（JavaScriptは使わない）
- フレームワーク: Next.js 14 App Router
- 状態管理: Zustand（Redux・Contextは使わない）
- テスト: Vitest + Testing Library / Playwright (E2E)
## コーディング規約
- コンポーネントは関数コンポーネントのみ
- APIクライアントは `src/lib/api/` に集約する
- `any` 型は原則禁止。使う場合は `// TODO:` コメントを添える
## 絶対に変更しないファイル・ディレクトリ
- `src/lib/auth/`（セキュリティレビュー待ち）
- `prisma/schema.prisma`（DBA承認が必要）
## テストの書き方
- ユニットテストは同階層の `__tests__/` に置く
- モックは `vi.mock()` を使う。jest.mockは使わない「絶対に変更しないファイル」を明記しておくことで、冒頭で挙げた「指示したのに書き換えられた」問題の多くは防げます。CLAUDE.mdはプロジェクトリポジトリにコミットしてチームで共有することで、AI利用ルールのバージョン管理も兼ねられます。
2. 動的コンテキスト：ツール呼び出し結果
AIコーディングエージェントは作業中にファイルを読み込んだり、検索したり、コマンドを実行したりします。これらのツール呼び出し結果がすべてコンテキストウィンドウに積み込まれていきます。
たとえばClaude Codeが「UserService クラスを修正して」というタスクを受けたとき、内部では以下のような動作をしています。
1. Glob("src/**/*.ts") → ファイル一覧をコンテキストに追加
2. Grep("UserService") → 該当ファイルのパスをコンテキストに追加
3. Read("src/services/user.ts") → ファイル内容（数百〜数千トークン）をコンテキストに追加
4. Read("src/types/user.d.ts") → 型定義ファイルをコンテキストに追加
5. コード生成 → ここでようやく出力1タスクで数千〜数万トークンが消費されます。タスクが複数ステップにまたがる場合、読み込んだファイルの内容・実行結果・エラーログがすべて蓄積されます。何も考えずに「全部読んでから修正して」とやると、あっという間にコンテキストウィンドウが圧迫されます。
開発者として意識すべきことは、エージェントに「何を読ませるか」を絞ることです。「src/services/ 配下だけ参照して」「関連する型定義は src/types/user.d.ts だけ見て」のように、参照スコープを指示に含めるだけで消費トークン量と出力品質の両方が改善します。
3. 外部コンテキスト：MCP（Model Context Protocol）
MCP（Model Context Protocol）は、外部ツールやデータソースをLLMのコンテキストとして標準化された形で供給するためのプロトコルです。コーディングエージェントに「生きたコンテキスト」を注入する仕組みと考えてください。
たとえば以下のようなMCPサーバーを実装・接続することで、エージェントはリアルタイムの情報を参照しながらコードを書けるようになります。
| MCPサーバーの種類 | 注入するコンテキスト |
| DBスキーマサーバー | 最新のPrismaスキーマをコンテキストに注入 |
| API仕様サーバー | OpenAPI (Swagger) ドキュメントを注入 |
| エラーログサーバー | Sentryの直近エラーをコンテキストに注入 |
| 社内Wikiサーバー | Confluenceのページをコンテキストに注入 |
「エンドポイントの仕様をコピペしてから指示する」という作業が不要になり、エージェントが必要なときに必要な情報を自律的に取得できるようになります。まずは1つのデータソース（例：DBスキーマ）をMCP化して動作を確認し、段階的に拡張していく進め方が現実的です。
コンテキスト設計のポイント：配置順序とトークン予算
コンテキストに何を入れるかが決まったら、次は「どの順番で・どれだけ」の設計です。
配置順序：先頭と末尾を重視する
スタンフォード大学・UCバークレーらの共同研究「Lost in the Middle」（Liu et al., 2023）が示すように、LLMはコンテキストの先頭と末尾に配置された情報を優先的に参照し、中間部の情報を見落としやすい傾向があります（※4）。
AIコーディングエージェントの文脈で整理すると、次のような配置が有効です。
| 配置位置 | コンテキストの種類 | 設計のポイント |
| 先頭（最も参照されやすい） | CLAUDE.md（永続ルール） | 最も重要な制約・禁止事項はここに配置する。セッション全体を通じて参照される |
| 中間 | ツール呼び出し結果（ファイル内容・検索結果・MCPデータ） | 重要度の高い情報を先頭寄りに配置する |
| 末尾（参照されやすい） | 現在のユーザー指示 | 末尾は参照されやすい。タスクの詳細・制約の再確認を置く |
「変更しないでほしいファイル」は毎回の指示に含めるより、CLAUDE.md に書いておく方が確実です。先頭に常駐するため、コンテキストが膨らんでも埋没しにくくなります。
トークン予算：枠を決めて破綻を防ぐ
コンテキストウィンドウの上限トークン数を各要素に事前に割り当てておく「トークン予算」の設計も重要です（※6）。
| コンテキストの種類 | 割り当てトークン数 |
| CLAUDE.md（永続ルール） | 〜2,000 トークン |
| MCP / RAG 取得データ | 〜40,000 トークン |
| ファイル読み込み結果 | 〜30,000 トークン |
| 会話履歴（直近10件） | 〜10,000 トークン |
| 現在のユーザー指示 | 〜2,000 トークン |
| 合計（200K中の約42%） | 〜84,000 トークン |
予算を決めておかないと、大きなファイルを1本読み込んだだけで他の情報が押し出されます。特にRAGやMCPで取得するデータは上限を設けておくことが重要です。
失敗パターンと対策：コンテキストの腐敗（Context Rot）を防ぐ
AIコーディングエージェントを長時間使っていると、最初は正常だった動作が徐々に崩れていく経験をします。この現象を「Context Rot（コンテキストの腐敗）」と呼びます（※6）。
コーディングエージェントでのContext Rot：具体例
[ タスク開始時：正常な動作 ]
CLAUDE.md: 「src/lib/auth/ は変更しない」
User: 「UserServiceのリファクタをお願い」
Claude: 「承知しました。src/services/user.ts を修正します」
# → auth/ には触れずに作業完了[ 50ターン後：劣化した動作 ]
# ※ コンテキスト圧縮が走り、会話履歴が要約された状態
User: 「認証周りも合わせて整理しておいて」
Claude: 「src/lib/auth/session.ts を修正しました」
# → 圧縮要約の中で「変更しない」という否定的制約の精度が落ちているここで誤解しやすいのは、CLAUDE.md はセッション開始時にコンテキストの先頭に注入されるため、物理的に「中間に埋もれる」わけではないという点です。
実際の劣化メカニズムは別のところにあります。Claude CodeなどのAIコーディングエージェントはコンテキストウィンドウが上限に近づくと、会話履歴を自動的に圧縮・要約する「コンテキスト圧縮（Context Compaction）」を実行します。（※8）この圧縮処理の中で、「〜は変更しない」「〜は使わない」といった否定的な制約や細かな条件ほど要約から抜け落ちやすい傾向があります。CLAUDE.md 自体は先頭に残っていても、圧縮された会話履歴の中でその制約の文脈が失われることで、エージェントが制約を実質的に無視した判断を下すようになります。
主要な失敗パターン4つ
- コンテキストの肥大化：ファイル読み込み結果・ツール実行ログ・中間出力が蓄積し、圧縮のトリガーが早まる。大きなリファクタリングを1セッションでやりきろうとするケースで頻発します。
- 矛盾情報の混入：古いファイル内容と最新の変更後内容が同時に存在する。ファイルを読んで→修正して→再読み込みせずに続けて修正、という流れで起きます。
- 圧縮による制約の精度劣化：コンテキスト圧縮の要約処理で、否定的制約（「〜は変更しない」「〜は使わない」）が抜け落ちる。セッション後半で禁止していたはずの操作が突然実行されたらこのサインです。
- トークン超過による切り捨て：コンテキストウィンドウの上限に達し、先頭付近の重要な前提情報が切り捨てられる。
腐敗を防ぐ設計原則
- タスクを小さく区切る：1セッションで完結するタスクの粒度を小さくする。「このファイルだけ修正」「このモジュールだけリファクタ」と範囲を明示する
- 参照スコープを指示に含める：「src/services/ 配下だけ参照して」と伝えることで不要なファイル読み込みを抑制する
- 重要な制約は CLAUDE.md に書く：毎回の指示に書くのではなく、永続コンテキストに書いておくことで先頭からの参照を担保する
- 長いセッションはリセットする：50〜100ターン経過したら新しいセッションを始め、タスクのサマリーだけを引き継ぐ
全対策を一度に打つ必要はありません。まず「タスクを小さく区切る」と「制約をCLAUDE.mdに移す」の2つから始めるだけで、Context Rotの大半は防げます。
プロンプトエンジニアリング・RAG・ファインチューニング・MCPの使い分け
「どの手法をいつ使うべきか」という判断を整理します。
| 手法 | 主な用途 | 向いているケース | コスト感 |
| プロンプトエンジニアリング | 指示・制約の最適化 | タスク定義が明確で知識は静的 | 低 |
| CLAUDE.md / 永続コンテキスト | プロジェクトルールの常駐化 | チームで共通の制約・スタックを維持したい | 低 |
| RAG | 外部知識の動的注入 | 大量ドキュメント・最新情報を参照したい | 中 |
| MCP | ツール・API連携の標準化 | DBスキーマ・API仕様をリアルタイムで参照したい | 中〜高 |
| ファインチューニング | モデル挙動の根本変更 | 特定ドメインの語彙・文体を体得させたい | 高 |
判断フローはシンプルです。
- まず CLAUDE.md を整備する：プロジェクト固有のルール・禁止事項・技術スタックをここに集約するだけで、多くの「指示が守られない」問題は解決します。
- 知識が古い・足りないなら RAG か MCP を追加する：コードベースに存在しない知識（最新の外部仕様・DBスキーマ）が必要ならRAGまたはMCPを追加します。
- 文体・語彙を根本から変えたいならファインチューニング：チームの独自記法や社内ドメイン用語をモデルに内在化させる必要があると判断できた段階で検討します。コストと再学習サイクルが重いため、最後の手段です。
コンテキストエンジニアリングはモデルの重みに手を加えずに挙動を制御できるため、スピードと柔軟性に優れます。まずCLAUDE.mdの整備とトークン予算設計から着手するのが、最もコストが低く即効性のある第一歩です。
まとめ：今日からできる3つのこと
本記事のポイント
- コンテキストエンジニアリングとは、LLMのコンテキストウィンドウに「何を・どの順番で・どれだけ」渡すかを設計する技術です
- AIコーディングエージェントでは CLAUDE.md（永続コンテキスト）・ツール呼び出し結果・MCPの3レイヤーがコンテキストを構成します
- Context Rot（コンテキストの腐敗）はセッションが長くなるほど発生しやすく、タスクの細分化とCLAUDE.mdへの制約集約で大半は防げます
- ファインチューニングより先に、コンテキスト設計で解決できないかを検証するのが合理的です
今日からできる3つのこと
- `CLAUDE.md` を「技術スタック・コーディング規約・変更禁止ファイル」の3セクションで整備する：リポジトリのルートに置いてチームで共有しましょう。AIへの「お作法」をコードと同様にバージョン管理できます。
- 長いセッションで挙動が崩れたら、タスクを分割して新セッションで再開する：「直近100ターン経過したらリセット」をチームのルールにするだけで、Context Rotの被害は大幅に減ります。
- エージェントへの指示に参照スコープを明示する：「src/services/ 配下だけ参照して」「関連型定義は src/types/user.d.ts だけ見て」のように絞ることで、不要なファイル読み込みを抑制してトークン消費を最適化できます。
ひとつ補足しておきたいのは、コンテキストエンジニアリングはあくまで「AIの生成品質を高める」技術であり、開発フロー全体のボトルネックを自動的に解消するものではないという点です。コード生成の品質が上がっても、レビュープロセスが手動のままであれば、そこが新たなボトルネックになります。「AIが書いたコードをレビューする時間が足りない」「CIのテストカバレッジが追いついていない」という状況では、生成速度を上げてもチームのアウトプット量は変わりません。コンテキスト設計の改善と並行して、レビューの自動化・CI/CDのガードレール・テストパイプラインの整備もセットで進めることが、組織としての生産性向上につながります。
AI活用推進の成果をデータで追いたいチームには、Findy Team+ が役立ちます。サイクルタイムやデプロイ頻度などの開発メトリクスを通じて、AI導入前後の生産性変化を可視化できます。まずは2週間の無料トライアルでお試しください。
【4/21（火）開催！コンテキストエンジニアリングについてのイベントお申込みはこちら！】
【Findy Team+について詳しく知りたい方はこちら！】
参考・出典
- Andrej Karpathy「context engineering is the delicate art and science of filling the context window with just the right information for the next step」X（旧Twitter）、2025年6月25日
- tobi lutke（Shopify CEO）、コンテキストエンジニアリングへの支持を表明した公開投稿、X（旧Twitter）、2025年6月19日
- OpenAI公式ドキュメント（GPT-5.4: 1M token context window）/ Anthropic公式ドキュメント（Claude Sonnet 4.6: 1M-token context window）
- Nelson F. Liu, Kevin Lin, John Hewitt, et al.「Lost in the Middle: How Language Models Use Long Contexts」Transactions of the Association for Computational Linguistics, 2024 — arxiv.org/abs/2307.03172
- Jeff Huber, Anton Troynikov, et al.「Context Rot: Why Long Contexts Make LLMs Worse」Chroma Research, 2025 — research.trychroma.com/context-rot
- Anthropic「Build with Claude: Context windows」公式ドキュメント（トークン予算・コンテキスト割り当て設計の参照資料）— docs.anthropic.com/en/docs/build-with-claude/context-windows
- Anthropic「Manage costs effectively」Claude Code 公式ドキュメント — docs.anthropic.com/en/docs/claude-code/costs
「src/lib/auth/ は変更しないで」とClaude Codeに指示したのに、リファクタリングを進めるうちにそのディレクトリのファイルが書き換えられていた。Cursorでコードを書かせていたら、会話の後半から急にスタイルが崩れ始め、プロジェクトのコーディング規約を無視した実装が返ってくるようになった——そういった経験がある開発者は数多くいらっしゃるのではないでしょうか。
原因はプロンプトの文言ではありません。AIコーディングエージェントに渡している「コンテキスト全体の設計」が問題です。この課題を体系的に解決するアプローチが、コンテキストエンジニアリングです。
この記事では、コンテキストエンジニアリングの基本定義から、CLAUDE.md や MCP を使った実践的なコンテキスト設計、そしてAIコーディングエージェントが陥りやすい失敗パターンとその対策まで、ソフトウェア開発者の視点で解説します。
コンテキストエンジニアリングとは？基本定義と登場背景
コンテキストエンジニアリングとは、「LLMのコンテキストウィンドウに何を・どの順番で・どれだけ渡すかを設計・最適化するエンジニアリング手法」です。単一のプロンプト文言を磨くプロンプトエンジニアリングとは異なり、システムプロンプト・会話履歴・コードベースの検索結果・ツール出力といった複数の情報源を統合的にマネジメントすることを指します。
なぜ今「コンテキストエンジニアリング」が注目されるのか
注目が高まった直接のきっかけは、2025年6月にAI研究者のAndrej Karpathy氏がX（旧Twitter）上で「context engineering is the delicate art and science of filling the context window with just the right information for the next step」と投稿したことです（※1）。同月、Shopify CEOのTobi Lütke氏もXへの公開投稿でコンテキストエンジニアリングの重要性を支持し（※2）、業界全体での認知が急速に広まりました。
背景にあるのは、コンテキストウィンドウ長の急速な拡大です。OpenAIのGPT-5.4とAnthropicのClaude Sonnet 4.6は、いずれも1Mトークンのコンテキストウィンドウを持ちます（※3）。「何を詰め込むか」よりも「何を選び、どう構造化して渡すか」が出力品質を左右する時代に移行しました。Claude CodeやCursorのようなAIコーディングエージェントが日常的なツールになった今、この設計課題は開発者全員に関係します。
コンテキストウィンドウとは何か：AIの「作業デスク」
コンテキストウィンドウは、LLMが1回の推論で参照できる全テキストの領域です。「AIの作業デスク」に相当し、デスクの上に置けるものは有限です。
開発者の視点でいうと、AIコーディングエージェントのコンテキストウィンドウには次のものが積み込まれています。
- プロジェクトの指示ファイル（CLAUDE.md など）
- ユーザーの依頼メッセージ
- 過去の会話履歴
- ファイル読み込みや検索のツール呼び出し結果
- MCPサーバーから取得したDBスキーマやAPIドキュメント
モデルはこのデスクの上にある情報だけを根拠にコードを書きます。デスクに何が載っているかをエンジニアがコントロールすること、それがコンテキストエンジニアリングです。
プロンプトエンジニアリングとの違い
プロンプトエンジニアリングとは、LLMに与える指示文の設計・最適化を指します。Few-shotによる例示、Chain-of-Thoughtによる推論誘導、システムプロンプトの役割設定などが中心です。単一リクエストの品質を高めるアプローチであり、多くの現場で最初に取り組まれます。
ただし、プロンプトエンジニアリングには構造的な限界があります。設計の対象が「その場の指示文」に限定されるため、AIコーディングエージェントが複数ファイルを横断して長時間作業するシナリオや、外部データを動的に参照するRAGシステムには対応しきれません。
| 比較軸 | プロンプトエンジニアリング | コンテキストエンジニアリング |
| スコープ | 単一の指示文 | コンテキストウィンドウ全体 |
| 対象 | 指示・例示・推論誘導 | 指示・記憶・コードベース・ツール出力・状態管理 |
| タイミング | 静的（事前設計） | 動的（実行時に構築・更新） |
| 主な手法 | Few-shot、CoT、役割指定 | CLAUDE.md、RAG、MCP、コンテキスト圧縮 |
重要なのは、コンテキストエンジニアリングはプロンプトエンジニアリングを否定するものではないという点です。Few-shotやChain-of-Thoughtはコンテキスト設計の一構成要素として引き続き有効です。より広い責任範囲でLLMシステム全体を設計する概念がコンテキストエンジニアリングであり、AIコーディングエージェントやRAGシステムを本番品質で動かすためには、この上位の視点が不可欠です。
AIコーディングエージェントのコンテキストを解剖する
ここから実践的な話に入ります。Claude CodeやCursorのようなAIコーディングエージェントが、実際にどんな情報をコンテキストウィンドウに積み込んでいるかを整理します。
1. 永続コンテキスト：CLAUDE.md / AGENTS.md
最も設計コストが低く、最も効果が高いのが永続コンテキストファイルです。Claude Codeであれば CLAUDE.md、OpenAI Codex系エージェントであれば AGENTS.md が相当します。これらのファイルはエージェントが起動するたびにコンテキストウィンドウの先頭に自動注入されます。
「セッションを越えてもAIに覚えていてほしい情報」はここに書く、というのが基本原則です。
悪い例（抽象的すぎる）：
# Instructions
- 常にTypeScriptを使ってください
- ベストプラクティスに従ってください
- クリーンなコードを書いてください「ベストプラクティス」はモデルが解釈する余地が大きすぎます。「クリーンなコード」は指示として機能しません。
良い例（具体的な制約・技術スタック・禁止事項を明記）：
# CLAUDE.md
## 技術スタック
- 言語: TypeScript 5.x（JavaScriptは使わない）
- フレームワーク: Next.js 14 App Router
- 状態管理: Zustand（Redux・Contextは使わない）
- テスト: Vitest + Testing Library / Playwright (E2E)
## コーディング規約
- コンポーネントは関数コンポーネントのみ
- APIクライアントは `src/lib/api/` に集約する
- `any` 型は原則禁止。使う場合は `// TODO:` コメントを添える
## 絶対に変更しないファイル・ディレクトリ
- `src/lib/auth/`（セキュリティレビュー待ち）
- `prisma/schema.prisma`（DBA承認が必要）
## テストの書き方
- ユニットテストは同階層の `__tests__/` に置く
- モックは `vi.mock()` を使う。jest.mockは使わない「絶対に変更しないファイル」を明記しておくことで、冒頭で挙げた「指示したのに書き換えられた」問題の多くは防げます。CLAUDE.mdはプロジェクトリポジトリにコミットしてチームで共有することで、AI利用ルールのバージョン管理も兼ねられます。
2. 動的コンテキスト：ツール呼び出し結果
AIコーディングエージェントは作業中にファイルを読み込んだり、検索したり、コマンドを実行したりします。これらのツール呼び出し結果がすべてコンテキストウィンドウに積み込まれていきます。
たとえばClaude Codeが「UserService クラスを修正して」というタスクを受けたとき、内部では以下のような動作をしています。
1. Glob("src/**/*.ts") → ファイル一覧をコンテキストに追加
2. Grep("UserService") → 該当ファイルのパスをコンテキストに追加
3. Read("src/services/user.ts") → ファイル内容（数百〜数千トークン）をコンテキストに追加
4. Read("src/types/user.d.ts") → 型定義ファイルをコンテキストに追加
5. コード生成 → ここでようやく出力1タスクで数千〜数万トークンが消費されます。タスクが複数ステップにまたがる場合、読み込んだファイルの内容・実行結果・エラーログがすべて蓄積されます。何も考えずに「全部読んでから修正して」とやると、あっという間にコンテキストウィンドウが圧迫されます。
開発者として意識すべきことは、エージェントに「何を読ませるか」を絞ることです。「src/services/ 配下だけ参照して」「関連する型定義は src/types/user.d.ts だけ見て」のように、参照スコープを指示に含めるだけで消費トークン量と出力品質の両方が改善します。
3. 外部コンテキスト：MCP（Model Context Protocol）
MCP（Model Context Protocol）は、外部ツールやデータソースをLLMのコンテキストとして標準化された形で供給するためのプロトコルです。コーディングエージェントに「生きたコンテキスト」を注入する仕組みと考えてください。
たとえば以下のようなMCPサーバーを実装・接続することで、エージェントはリアルタイムの情報を参照しながらコードを書けるようになります。
| MCPサーバーの種類 | 注入するコンテキスト |
| DBスキーマサーバー | 最新のPrismaスキーマをコンテキストに注入 |
| API仕様サーバー | OpenAPI (Swagger) ドキュメントを注入 |
| エラーログサーバー | Sentryの直近エラーをコンテキストに注入 |
| 社内Wikiサーバー | Confluenceのページをコンテキストに注入 |
「エンドポイントの仕様をコピペしてから指示する」という作業が不要になり、エージェントが必要なときに必要な情報を自律的に取得できるようになります。まずは1つのデータソース（例：DBスキーマ）をMCP化して動作を確認し、段階的に拡張していく進め方が現実的です。
コンテキスト設計のポイント：配置順序とトークン予算
コンテキストに何を入れるかが決まったら、次は「どの順番で・どれだけ」の設計です。
配置順序：先頭と末尾を重視する
スタンフォード大学・UCバークレーらの共同研究「Lost in the Middle」（Liu et al., 2023）が示すように、LLMはコンテキストの先頭と末尾に配置された情報を優先的に参照し、中間部の情報を見落としやすい傾向があります（※4）。
AIコーディングエージェントの文脈で整理すると、次のような配置が有効です。
| 配置位置 | コンテキストの種類 | 設計のポイント |
| 先頭（最も参照されやすい） | CLAUDE.md（永続ルール） | 最も重要な制約・禁止事項はここに配置する。セッション全体を通じて参照される |
| 中間 | ツール呼び出し結果（ファイル内容・検索結果・MCPデータ） | 重要度の高い情報を先頭寄りに配置する |
| 末尾（参照されやすい） | 現在のユーザー指示 | 末尾は参照されやすい。タスクの詳細・制約の再確認を置く |
「変更しないでほしいファイル」は毎回の指示に含めるより、CLAUDE.md に書いておく方が確実です。先頭に常駐するため、コンテキストが膨らんでも埋没しにくくなります。
トークン予算：枠を決めて破綻を防ぐ
コンテキストウィンドウの上限トークン数を各要素に事前に割り当てておく「トークン予算」の設計も重要です（※6）。
| コンテキストの種類 | 割り当てトークン数 |
| CLAUDE.md（永続ルール） | 〜2,000 トークン |
| MCP / RAG 取得データ | 〜40,000 トークン |
| ファイル読み込み結果 | 〜30,000 トークン |
| 会話履歴（直近10件） | 〜10,000 トークン |
| 現在のユーザー指示 | 〜2,000 トークン |
| 合計（200K中の約42%） | 〜84,000 トークン |
予算を決めておかないと、大きなファイルを1本読み込んだだけで他の情報が押し出されます。特にRAGやMCPで取得するデータは上限を設けておくことが重要です。
失敗パターンと対策：コンテキストの腐敗（Context Rot）を防ぐ
AIコーディングエージェントを長時間使っていると、最初は正常だった動作が徐々に崩れていく経験をします。この現象を「Context Rot（コンテキストの腐敗）」と呼びます（※6）。
コーディングエージェントでのContext Rot：具体例
[ タスク開始時：正常な動作 ]
CLAUDE.md: 「src/lib/auth/ は変更しない」
User: 「UserServiceのリファクタをお願い」
Claude: 「承知しました。src/services/user.ts を修正します」
# → auth/ には触れずに作業完了[ 50ターン後：劣化した動作 ]
# ※ コンテキスト圧縮が走り、会話履歴が要約された状態
User: 「認証周りも合わせて整理しておいて」
Claude: 「src/lib/auth/session.ts を修正しました」
# → 圧縮要約の中で「変更しない」という否定的制約の精度が落ちているここで誤解しやすいのは、CLAUDE.md はセッション開始時にコンテキストの先頭に注入されるため、物理的に「中間に埋もれる」わけではないという点です。
実際の劣化メカニズムは別のところにあります。Claude CodeなどのAIコーディングエージェントはコンテキストウィンドウが上限に近づくと、会話履歴を自動的に圧縮・要約する「コンテキスト圧縮（Context Compaction）」を実行します。（※8）この圧縮処理の中で、「〜は変更しない」「〜は使わない」といった否定的な制約や細かな条件ほど要約から抜け落ちやすい傾向があります。CLAUDE.md 自体は先頭に残っていても、圧縮された会話履歴の中でその制約の文脈が失われることで、エージェントが制約を実質的に無視した判断を下すようになります。
主要な失敗パターン4つ
- コンテキストの肥大化：ファイル読み込み結果・ツール実行ログ・中間出力が蓄積し、圧縮のトリガーが早まる。大きなリファクタリングを1セッションでやりきろうとするケースで頻発します。
- 矛盾情報の混入：古いファイル内容と最新の変更後内容が同時に存在する。ファイルを読んで→修正して→再読み込みせずに続けて修正、という流れで起きます。
- 圧縮による制約の精度劣化：コンテキスト圧縮の要約処理で、否定的制約（「〜は変更しない」「〜は使わない」）が抜け落ちる。セッション後半で禁止していたはずの操作が突然実行されたらこのサインです。
- トークン超過による切り捨て：コンテキストウィンドウの上限に達し、先頭付近の重要な前提情報が切り捨てられる。
腐敗を防ぐ設計原則
- タスクを小さく区切る：1セッションで完結するタスクの粒度を小さくする。「このファイルだけ修正」「このモジュールだけリファクタ」と範囲を明示する
- 参照スコープを指示に含める：「src/services/ 配下だけ参照して」と伝えることで不要なファイル読み込みを抑制する
- 重要な制約は CLAUDE.md に書く：毎回の指示に書くのではなく、永続コンテキストに書いておくことで先頭からの参照を担保する
- 長いセッションはリセットする：50〜100ターン経過したら新しいセッションを始め、タスクのサマリーだけを引き継ぐ
全対策を一度に打つ必要はありません。まず「タスクを小さく区切る」と「制約をCLAUDE.mdに移す」の2つから始めるだけで、Context Rotの大半は防げます。
プロンプトエンジニアリング・RAG・ファインチューニング・MCPの使い分け
「どの手法をいつ使うべきか」という判断を整理します。
| 手法 | 主な用途 | 向いているケース | コスト感 |
| プロンプトエンジニアリング | 指示・制約の最適化 | タスク定義が明確で知識は静的 | 低 |
| CLAUDE.md / 永続コンテキスト | プロジェクトルールの常駐化 | チームで共通の制約・スタックを維持したい | 低 |
| RAG | 外部知識の動的注入 | 大量ドキュメント・最新情報を参照したい | 中 |
| MCP | ツール・API連携の標準化 | DBスキーマ・API仕様をリアルタイムで参照したい | 中〜高 |
| ファインチューニング | モデル挙動の根本変更 | 特定ドメインの語彙・文体を体得させたい | 高 |
判断フローはシンプルです。
- まず CLAUDE.md を整備する：プロジェクト固有のルール・禁止事項・技術スタックをここに集約するだけで、多くの「指示が守られない」問題は解決します。
- 知識が古い・足りないなら RAG か MCP を追加する：コードベースに存在しない知識（最新の外部仕様・DBスキーマ）が必要ならRAGまたはMCPを追加します。
- 文体・語彙を根本から変えたいならファインチューニング：チームの独自記法や社内ドメイン用語をモデルに内在化させる必要があると判断できた段階で検討します。コストと再学習サイクルが重いため、最後の手段です。
コンテキストエンジニアリングはモデルの重みに手を加えずに挙動を制御できるため、スピードと柔軟性に優れます。まずCLAUDE.mdの整備とトークン予算設計から着手するのが、最もコストが低く即効性のある第一歩です。
まとめ：今日からできる3つのこと
本記事のポイント
- コンテキストエンジニアリングとは、LLMのコンテキストウィンドウに「何を・どの順番で・どれだけ」渡すかを設計する技術です
- AIコーディングエージェントでは CLAUDE.md（永続コンテキスト）・ツール呼び出し結果・MCPの3レイヤーがコンテキストを構成します
- Context Rot（コンテキストの腐敗）はセッションが長くなるほど発生しやすく、タスクの細分化とCLAUDE.mdへの制約集約で大半は防げます
- ファインチューニングより先に、コンテキスト設計で解決できないかを検証するのが合理的です
今日からできる3つのこと
- `CLAUDE.md` を「技術スタック・コーディング規約・変更禁止ファイル」の3セクションで整備する：リポジトリのルートに置いてチームで共有しましょう。AIへの「お作法」をコードと同様にバージョン管理できます。
- 長いセッションで挙動が崩れたら、タスクを分割して新セッションで再開する：「直近100ターン経過したらリセット」をチームのルールにするだけで、Context Rotの被害は大幅に減ります。
- エージェントへの指示に参照スコープを明示する：「src/services/ 配下だけ参照して」「関連型定義は src/types/user.d.ts だけ見て」のように絞ることで、不要なファイル読み込みを抑制してトークン消費を最適化できます。
ひとつ補足しておきたいのは、コンテキストエンジニアリングはあくまで「AIの生成品質を高める」技術であり、開発フロー全体のボトルネックを自動的に解消するものではないという点です。コード生成の品質が上がっても、レビュープロセスが手動のままであれば、そこが新たなボトルネックになります。「AIが書いたコードをレビューする時間が足りない」「CIのテストカバレッジが追いついていない」という状況では、生成速度を上げてもチームのアウトプット量は変わりません。コンテキスト設計の改善と並行して、レビューの自動化・CI/CDのガードレール・テストパイプラインの整備もセットで進めることが、組織としての生産性向上につながります。
AI活用推進の成果をデータで追いたいチームには、Findy Team+ が役立ちます。サイクルタイムやデプロイ頻度などの開発メトリクスを通じて、AI導入前後の生産性変化を可視化できます。まずは2週間の無料トライアルでお試しください。
【4/21（火）開催！コンテキストエンジニアリングについてのイベントお申込みはこちら！】
【Findy Team+について詳しく知りたい方はこちら！】
参考・出典
- Andrej Karpathy「context engineering is the delicate art and science of filling the context window with just the right information for the next step」X（旧Twitter）、2025年6月25日
- tobi lutke（Shopify CEO）、コンテキストエンジニアリングへの支持を表明した公開投稿、X（旧Twitter）、2025年6月19日
- OpenAI公式ドキュメント（GPT-5.4: 1M token context window）/ Anthropic公式ドキュメント（Claude Sonnet 4.6: 1M-token context window）
- Nelson F. Liu, Kevin Lin, John Hewitt, et al.「Lost in the Middle: How Language Models Use Long Contexts」Transactions of the Association for Computational Linguistics, 2024 — arxiv.org/abs/2307.03172
- Jeff Huber, Anton Troynikov, et al.「Context Rot: Why Long Contexts Make LLMs Worse」Chroma Research, 2025 — research.trychroma.com/context-rot
- Anthropic「Build with Claude: Context windows」公式ドキュメント（トークン予算・コンテキスト割り当て設計の参照資料）— docs.anthropic.com/en/docs/build-with-claude/context-windows
- Anthropic「Manage costs effectively」Claude Code 公式ドキュメント — docs.anthropic.com/en/docs/claude-code/costs
コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いから実践方法まで徹底解説
「src/lib/auth/ は変更しないで」とClaude Codeに指示したのに、リファクタリングを進めるうちにそのディレクトリのファイルが書き換えられていた。Cursorでコードを書かせていたら、会話の後半から急にスタイルが崩れ始め、プロジェクトのコーディング規約を無視した実装が返ってくるようになった——そういった経験がある開発者は数多くいらっしゃるのではないでしょうか。
原因はプロンプトの文言ではありません。AIコーディングエージェントに渡している「コンテキスト全体の設計」が問題です。この課題を体系的に解決するアプローチが、コンテキストエンジニアリングです。
この記事では、コンテキストエンジニアリングの基本定義から、CLAUDE.md や MCP を使った実践的なコンテキスト設計、そしてAIコーディングエージェントが陥りやすい失敗パターンとその対策まで、ソフトウェア開発者の視点で解説します。
コンテキストエンジニアリングとは？基本定義と登場背景
コンテキストエンジニアリングとは、「LLMのコンテキストウィンドウに何を・どの順番で・どれだけ渡すかを設計・最適化するエンジニアリング手法」です。単一のプロンプト文言を磨くプロンプトエンジニアリングとは異なり、システムプロンプト・会話履歴・コードベースの検索結果・ツール出力といった複数の情報源を統合的にマネジメントすることを指します。
なぜ今「コンテキストエンジニアリング」が注目されるのか
注目が高まった直接のきっかけは、2025年6月にAI研究者のAndrej Karpathy氏がX（旧Twitter）上で「context engineering is the delicate art and science of filling the context window with just the right information for the next step」と投稿したことです（※1）。同月、Shopify CEOのTobi Lütke氏もXへの公開投稿でコンテキストエンジニアリングの重要性を支持し（※2）、業界全体での認知が急速に広まりました。
背景にあるのは、コンテキストウィンドウ長の急速な拡大です。OpenAIのGPT-5.4とAnthropicのClaude Sonnet 4.6は、いずれも1Mトークンのコンテキストウィンドウを持ちます（※3）。「何を詰め込むか」よりも「何を選び、どう構造化して渡すか」が出力品質を左右する時代に移行しました。Claude CodeやCursorのようなAIコーディングエージェントが日常的なツールになった今、この設計課題は開発者全員に関係します。
コンテキストウィンドウとは何か：AIの「作業デスク」
コンテキストウィンドウは、LLMが1回の推論で参照できる全テキストの領域です。「AIの作業デスク」に相当し、デスクの上に置けるものは有限です。
開発者の視点でいうと、AIコーディングエージェントのコンテキストウィンドウには次のものが積み込まれています。
- プロジェクトの指示ファイル（CLAUDE.md など）
- ユーザーの依頼メッセージ
- 過去の会話履歴
- ファイル読み込みや検索のツール呼び出し結果
- MCPサーバーから取得したDBスキーマやAPIドキュメント
モデルはこのデスクの上にある情報だけを根拠にコードを書きます。デスクに何が載っているかをエンジニアがコントロールすること、それがコンテキストエンジニアリングです。
プロンプトエンジニアリングとの違い
プロンプトエンジニアリングとは、LLMに与える指示文の設計・最適化を指します。Few-shotによる例示、Chain-of-Thoughtによる推論誘導、システムプロンプトの役割設定などが中心です。単一リクエストの品質を高めるアプローチであり、多くの現場で最初に取り組まれます。
ただし、プロンプトエンジニアリングには構造的な限界があります。設計の対象が「その場の指示文」に限定されるため、AIコーディングエージェントが複数ファイルを横断して長時間作業するシナリオや、外部データを動的に参照するRAGシステムには対応しきれません。
| 比較軸 | プロンプトエンジニアリング | コンテキストエンジニアリング |
| スコープ | 単一の指示文 | コンテキストウィンドウ全体 |
| 対象 | 指示・例示・推論誘導 | 指示・記憶・コードベース・ツール出力・状態管理 |
| タイミング | 静的（事前設計） | 動的（実行時に構築・更新） |
| 主な手法 | Few-shot、CoT、役割指定 | CLAUDE.md、RAG、MCP、コンテキスト圧縮 |
重要なのは、コンテキストエンジニアリングはプロンプトエンジニアリングを否定するものではないという点です。Few-shotやChain-of-Thoughtはコンテキスト設計の一構成要素として引き続き有効です。より広い責任範囲でLLMシステム全体を設計する概念がコンテキストエンジニアリングであり、AIコーディングエージェントやRAGシステムを本番品質で動かすためには、この上位の視点が不可欠です。
AIコーディングエージェントのコンテキストを解剖する
ここから実践的な話に入ります。Claude CodeやCursorのようなAIコーディングエージェントが、実際にどんな情報をコンテキストウィンドウに積み込んでいるかを整理します。
1. 永続コンテキスト：CLAUDE.md / AGENTS.md
最も設計コストが低く、最も効果が高いのが永続コンテキストファイルです。Claude Codeであれば CLAUDE.md、OpenAI Codex系エージェントであれば AGENTS.md が相当します。これらのファイルはエージェントが起動するたびにコンテキストウィンドウの先頭に自動注入されます。
「セッションを越えてもAIに覚えていてほしい情報」はここに書く、というのが基本原則です。
悪い例（抽象的すぎる）：
# Instructions
- 常にTypeScriptを使ってください
- ベストプラクティスに従ってください
- クリーンなコードを書いてください「ベストプラクティス」はモデルが解釈する余地が大きすぎます。「クリーンなコード」は指示として機能しません。
良い例（具体的な制約・技術スタック・禁止事項を明記）：
# CLAUDE.md
## 技術スタック
- 言語: TypeScript 5.x（JavaScriptは使わない）
- フレームワーク: Next.js 14 App Router
- 状態管理: Zustand（Redux・Contextは使わない）
- テスト: Vitest + Testing Library / Playwright (E2E)
## コーディング規約
- コンポーネントは関数コンポーネントのみ
- APIクライアントは `src/lib/api/` に集約する
- `any` 型は原則禁止。使う場合は `// TODO:` コメントを添える
## 絶対に変更しないファイル・ディレクトリ
- `src/lib/auth/`（セキュリティレビュー待ち）
- `prisma/schema.prisma`（DBA承認が必要）
## テストの書き方
- ユニットテストは同階層の `__tests__/` に置く
- モックは `vi.mock()` を使う。jest.mockは使わない「絶対に変更しないファイル」を明記しておくことで、冒頭で挙げた「指示したのに書き換えられた」問題の多くは防げます。CLAUDE.mdはプロジェクトリポジトリにコミットしてチームで共有することで、AI利用ルールのバージョン管理も兼ねられます。
2. 動的コンテキスト：ツール呼び出し結果
AIコーディングエージェントは作業中にファイルを読み込んだり、検索したり、コマンドを実行したりします。これらのツール呼び出し結果がすべてコンテキストウィンドウに積み込まれていきます。
たとえばClaude Codeが「UserService クラスを修正して」というタスクを受けたとき、内部では以下のような動作をしています。
1. Glob("src/**/*.ts") → ファイル一覧をコンテキストに追加
2. Grep("UserService") → 該当ファイルのパスをコンテキストに追加
3. Read("src/services/user.ts") → ファイル内容（数百〜数千トークン）をコンテキストに追加
4. Read("src/types/user.d.ts") → 型定義ファイルをコンテキストに追加
5. コード生成 → ここでようやく出力1タスクで数千〜数万トークンが消費されます。タスクが複数ステップにまたがる場合、読み込んだファイルの内容・実行結果・エラーログがすべて蓄積されます。何も考えずに「全部読んでから修正して」とやると、あっという間にコンテキストウィンドウが圧迫されます。
開発者として意識すべきことは、エージェントに「何を読ませるか」を絞ることです。「src/services/ 配下だけ参照して」「関連する型定義は src/types/user.d.ts だけ見て」のように、参照スコープを指示に含めるだけで消費トークン量と出力品質の両方が改善します。
3. 外部コンテキスト：MCP（Model Context Protocol）
MCP（Model Context Protocol）は、外部ツールやデータソースをLLMのコンテキストとして標準化された形で供給するためのプロトコルです。コーディングエージェントに「生きたコンテキスト」を注入する仕組みと考えてください。
たとえば以下のようなMCPサーバーを実装・接続することで、エージェントはリアルタイムの情報を参照しながらコードを書けるようになります。
| MCPサーバーの種類 | 注入するコンテキスト |
| DBスキーマサーバー | 最新のPrismaスキーマをコンテキストに注入 |
| API仕様サーバー | OpenAPI (Swagger) ドキュメントを注入 |
| エラーログサーバー | Sentryの直近エラーをコンテキストに注入 |
| 社内Wikiサーバー | Confluenceのページをコンテキストに注入 |
「エンドポイントの仕様をコピペしてから指示する」という作業が不要になり、エージェントが必要なときに必要な情報を自律的に取得できるようになります。まずは1つのデータソース（例：DBスキーマ）をMCP化して動作を確認し、段階的に拡張していく進め方が現実的です。
コンテキスト設計のポイント：配置順序とトークン予算
コンテキストに何を入れるかが決まったら、次は「どの順番で・どれだけ」の設計です。
配置順序：先頭と末尾を重視する
スタンフォード大学・UCバークレーらの共同研究「Lost in the Middle」（Liu et al., 2023）が示すように、LLMはコンテキストの先頭と末尾に配置された情報を優先的に参照し、中間部の情報を見落としやすい傾向があります（※4）。
AIコーディングエージェントの文脈で整理すると、次のような配置が有効です。
| 配置位置 | コンテキストの種類 | 設計のポイント |
| 先頭（最も参照されやすい） | CLAUDE.md（永続ルール） | 最も重要な制約・禁止事項はここに配置する。セッション全体を通じて参照される |
| 中間 | ツール呼び出し結果（ファイル内容・検索結果・MCPデータ） | 重要度の高い情報を先頭寄りに配置する |
| 末尾（参照されやすい） | 現在のユーザー指示 | 末尾は参照されやすい。タスクの詳細・制約の再確認を置く |
「変更しないでほしいファイル」は毎回の指示に含めるより、CLAUDE.md に書いておく方が確実です。先頭に常駐するため、コンテキストが膨らんでも埋没しにくくなります。
トークン予算：枠を決めて破綻を防ぐ
コンテキストウィンドウの上限トークン数を各要素に事前に割り当てておく「トークン予算」の設計も重要です（※6）。
| コンテキストの種類 | 割り当てトークン数 |
| CLAUDE.md（永続ルール） | 〜2,000 トークン |
| MCP / RAG 取得データ | 〜40,000 トークン |
| ファイル読み込み結果 | 〜30,000 トークン |
| 会話履歴（直近10件） | 〜10,000 トークン |
| 現在のユーザー指示 | 〜2,000 トークン |
| 合計（200K中の約42%） | 〜84,000 トークン |
予算を決めておかないと、大きなファイルを1本読み込んだだけで他の情報が押し出されます。特にRAGやMCPで取得するデータは上限を設けておくことが重要です。
失敗パターンと対策：コンテキストの腐敗（Context Rot）を防ぐ
AIコーディングエージェントを長時間使っていると、最初は正常だった動作が徐々に崩れていく経験をします。この現象を「Context Rot（コンテキストの腐敗）」と呼びます（※6）。
コーディングエージェントでのContext Rot：具体例
[ タスク開始時：正常な動作 ]
CLAUDE.md: 「src/lib/auth/ は変更しない」
User: 「UserServiceのリファクタをお願い」
Claude: 「承知しました。src/services/user.ts を修正します」
# → auth/ には触れずに作業完了[ 50ターン後：劣化した動作 ]
# ※ コンテキスト圧縮が走り、会話履歴が要約された状態
User: 「認証周りも合わせて整理しておいて」
Claude: 「src/lib/auth/session.ts を修正しました」
# → 圧縮要約の中で「変更しない」という否定的制約の精度が落ちているここで誤解しやすいのは、CLAUDE.md はセッション開始時にコンテキストの先頭に注入されるため、物理的に「中間に埋もれる」わけではないという点です。
実際の劣化メカニズムは別のところにあります。Claude CodeなどのAIコーディングエージェントはコンテキストウィンドウが上限に近づくと、会話履歴を自動的に圧縮・要約する「コンテキスト圧縮（Context Compaction）」を実行します。（※8）この圧縮処理の中で、「〜は変更しない」「〜は使わない」といった否定的な制約や細かな条件ほど要約から抜け落ちやすい傾向があります。CLAUDE.md 自体は先頭に残っていても、圧縮された会話履歴の中でその制約の文脈が失われることで、エージェントが制約を実質的に無視した判断を下すようになります。
主要な失敗パターン4つ
- コンテキストの肥大化：ファイル読み込み結果・ツール実行ログ・中間出力が蓄積し、圧縮のトリガーが早まる。大きなリファクタリングを1セッションでやりきろうとするケースで頻発します。
- 矛盾情報の混入：古いファイル内容と最新の変更後内容が同時に存在する。ファイルを読んで→修正して→再読み込みせずに続けて修正、という流れで起きます。
- 圧縮による制約の精度劣化：コンテキスト圧縮の要約処理で、否定的制約（「〜は変更しない」「〜は使わない」）が抜け落ちる。セッション後半で禁止していたはずの操作が突然実行されたらこのサインです。
- トークン超過による切り捨て：コンテキストウィンドウの上限に達し、先頭付近の重要な前提情報が切り捨てられる。
腐敗を防ぐ設計原則
- タスクを小さく区切る：1セッションで完結するタスクの粒度を小さくする。「このファイルだけ修正」「このモジュールだけリファクタ」と範囲を明示する
- 参照スコープを指示に含める：「src/services/ 配下だけ参照して」と伝えることで不要なファイル読み込みを抑制する
- 重要な制約は CLAUDE.md に書く：毎回の指示に書くのではなく、永続コンテキストに書いておくことで先頭からの参照を担保する
- 長いセッションはリセットする：50〜100ターン経過したら新しいセッションを始め、タスクのサマリーだけを引き継ぐ
全対策を一度に打つ必要はありません。まず「タスクを小さく区切る」と「制約をCLAUDE.mdに移す」の2つから始めるだけで、Context Rotの大半は防げます。
プロンプトエンジニアリング・RAG・ファインチューニング・MCPの使い分け
「どの手法をいつ使うべきか」という判断を整理します。
| 手法 | 主な用途 | 向いているケース | コスト感 |
| プロンプトエンジニアリング | 指示・制約の最適化 | タスク定義が明確で知識は静的 | 低 |
| CLAUDE.md / 永続コンテキスト | プロジェクトルールの常駐化 | チームで共通の制約・スタックを維持したい | 低 |
| RAG | 外部知識の動的注入 | 大量ドキュメント・最新情報を参照したい | 中 |
| MCP | ツール・API連携の標準化 | DBスキーマ・API仕様をリアルタイムで参照したい | 中〜高 |
| ファインチューニング | モデル挙動の根本変更 | 特定ドメインの語彙・文体を体得させたい | 高 |
判断フローはシンプルです。
- まず CLAUDE.md を整備する：プロジェクト固有のルール・禁止事項・技術スタックをここに集約するだけで、多くの「指示が守られない」問題は解決します。
- 知識が古い・足りないなら RAG か MCP を追加する：コードベースに存在しない知識（最新の外部仕様・DBスキーマ）が必要ならRAGまたはMCPを追加します。
- 文体・語彙を根本から変えたいならファインチューニング：チームの独自記法や社内ドメイン用語をモデルに内在化させる必要があると判断できた段階で検討します。コストと再学習サイクルが重いため、最後の手段です。
コンテキストエンジニアリングはモデルの重みに手を加えずに挙動を制御できるため、スピードと柔軟性に優れます。まずCLAUDE.mdの整備とトークン予算設計から着手するのが、最もコストが低く即効性のある第一歩です。
まとめ：今日からできる3つのこと
本記事のポイント
- コンテキストエンジニアリングとは、LLMのコンテキストウィンドウに「何を・どの順番で・どれだけ」渡すかを設計する技術です
- AIコーディングエージェントでは CLAUDE.md（永続コンテキスト）・ツール呼び出し結果・MCPの3レイヤーがコンテキストを構成します
- Context Rot（コンテキストの腐敗）はセッションが長くなるほど発生しやすく、タスクの細分化とCLAUDE.mdへの制約集約で大半は防げます
- ファインチューニングより先に、コンテキスト設計で解決できないかを検証するのが合理的です
今日からできる3つのこと
- `CLAUDE.md` を「技術スタック・コーディング規約・変更禁止ファイル」の3セクションで整備する：リポジトリのルートに置いてチームで共有しましょう。AIへの「お作法」をコードと同様にバージョン管理できます。
- 長いセッションで挙動が崩れたら、タスクを分割して新セッションで再開する：「直近100ターン経過したらリセット」をチームのルールにするだけで、Context Rotの被害は大幅に減ります。
- エージェントへの指示に参照スコープを明示する：「src/services/ 配下だけ参照して」「関連型定義は src/types/user.d.ts だけ見て」のように絞ることで、不要なファイル読み込みを抑制してトークン消費を最適化できます。
ひとつ補足しておきたいのは、コンテキストエンジニアリングはあくまで「AIの生成品質を高める」技術であり、開発フロー全体のボトルネックを自動的に解消するものではないという点です。コード生成の品質が上がっても、レビュープロセスが手動のままであれば、そこが新たなボトルネックになります。「AIが書いたコードをレビューする時間が足りない」「CIのテストカバレッジが追いついていない」という状況では、生成速度を上げてもチームのアウトプット量は変わりません。コンテキスト設計の改善と並行して、レビューの自動化・CI/CDのガードレール・テストパイプラインの整備もセットで進めることが、組織としての生産性向上につながります。
AI活用推進の成果をデータで追いたいチームには、Findy Team+ が役立ちます。サイクルタイムやデプロイ頻度などの開発メトリクスを通じて、AI導入前後の生産性変化を可視化できます。まずは2週間の無料トライアルでお試しください。
【4/21（火）開催！コンテキストエンジニアリングについてのイベントお申込みはこちら！】
【Findy Team+について詳しく知りたい方はこちら！】
参考・出典
- Andrej Karpathy「context engineering is the delicate art and science of filling the context window with just the right information for the next step」X（旧Twitter）、2025年6月25日
- tobi lutke（Shopify CEO）、コンテキストエンジニアリングへの支持を表明した公開投稿、X（旧Twitter）、2025年6月19日
- OpenAI公式ドキュメント（GPT-5.4: 1M token context window）/ Anthropic公式ドキュメント（Claude Sonnet 4.6: 1M-token context window）
- Nelson F. Liu, Kevin Lin, John Hewitt, et al.「Lost in the Middle: How Language Models Use Long Contexts」Transactions of the Association for Computational Linguistics, 2024 — arxiv.org/abs/2307.03172
- Jeff Huber, Anton Troynikov, et al.「Context Rot: Why Long Contexts Make LLMs Worse」Chroma Research, 2025 — research.trychroma.com/context-rot
- Anthropic「Build with Claude: Context windows」公式ドキュメント（トークン予算・コンテキスト割り当て設計の参照資料）— docs.anthropic.com/en/docs/build-with-claude/context-windows
- Anthropic「Manage costs effectively」Claude Code 公式ドキュメント — docs.anthropic.com/en/docs/claude-code/costs
