Anthropic のエンジニアは、1 年前と比べて 8 倍ものコードを日々マージしています。モデルは変わっていません。ハードウェアも変わっていません。チームの規模も変わっていません。変わったのは、Claude が作業を開始する前に「何を見ているか」です。
ほとんどの開発者は、より良いプロンプトを書くことに時間を費やしています。Anthropic のエンジニアは、より良いコンテキストを構築することに時間を費やしています。この一つの転換こそが、8 倍という差を生み出している理由です。
Anthropic 自身の研究でも、AI エージェントの品質はモデルそのものよりも、与えるコンテキストによって決まるということが直接的に示されています。Claude はコンテキストウィンドウの中にあるものしか見ることができません。そのウィンドウの外にあるものは、存在しないのと同じです。つまり、本格的な AI エンジニアの仕事とは、気の利いたプロンプトを書くことではなく、Claude が最初のアクションを起こす前に、正確かつ適切な情報を確実に持たせることなのです。
その規律には、今や名前がついています。「コンテキストエンジニアリング」です。そしてそれは、2 年前にプロンプトエンジニアリングが手動のスクリプト作成に取って代わったのと同じように、プロンプトエンジニアリングに取って代わりつつあります。
ブックマークしてフォローしてください
私は Noisy、4 年の経験を持つ開発者です。AI システムや自動化パイプラインを構築し、テクノロジーを実際の収入に変える方法を追求しています。
なぜあなたの AI エージェントは的外れな回答をするのか
AI エージェントが失敗したとき、ほとんどの人はモデルのせいにします。間違ったファイルを編集した、誤った前提で動いた、どんな開発者でも気づくような明白なミスをした、といった具合です。
しかし、問題はほとんどの場合モデルではありません。問題は「コンテキストの欠如」です。
1ほとんどの人が Claude に与えるもの | プロンプト2Claude が実際に必要としているもの | 知識、メモリ、ファイル、3 | ルール、例、ツール、4 | 状態、過去のアクション
プロンプトは一つの文章に過ぎません。コンテキストとは、Claude が動作する情報環境そのものです。機能するエージェントと機能しないエージェントの差は、ほとんどの場合、どのモデルが動いているかではなく、その環境の中に何があるかによって決まります。
Anthropic は次のように説明しています。「LLM はコンテキストウィンドウ内にあるものしか見ない。コンテキストは AI のオペレーティングシステムである。構築を間違えれば、モデルがどれほど有能であっても何も機能しない」と。
コンテキストの正体
多くの人は、コンテキストとは質問の前に貼り付けるテキストのことだと考えています。それは一つの層に過ぎません。適切に設計されたコンテキストには、7 つの要素が連携して機能しています。
1メモリ | 過去のセッションからエージェントが知っていること2指示 | ルール、制約、コーディングスタイル3例 | 優れた出力とはどのようなものか4ファイル | 関連するコード、ドキュメント、アーキテクチャ5過去のアクション | エージェントがすでに試したこと6ツール実行結果 | 検索や関数が返したもの7状態 | タスクが現在どの段階にあるか
Claude がアクションを起こすたびに、コンテキストは成長します。ツールの結果が戻り、新しいファイルが読み込まれ、状態が更新されます。Claude は新しいコンテキストを見て、次のアクションを決定します。このサイクルこそがエージェントの実際のメカニズムであり、プロンプトでもモデルでもなく、ステップごとに進化するコンテキストこそが重要なのです。
1ユーザーのリクエスト2↓37 つの要素すべてから構築されたコンテキスト4↓5Claude がアクションを決定6↓7ツールが実行8↓9結果がコンテキストに追加10↓11Claude が新しいコンテキストを確認12↓13次のアクション14↓15完了まで繰り返す
ダメなエージェントは、このサイクルをステップ 2 で壊してしまいます。コンテキストが不完全なため、Claude は推測で動くことになります。前提が間違っているため、出力も間違ったものになります。ほとんどの開発者はプロンプトを書き直すことでこれを解決しようとしますが、実際の解決策はコンテキストを正しく構築することです。
3 層のコンテキストスタック
Anthropic は、コンテキストを 3 つの層で考えることを推奨しています。各層は異なる目的を持ち、エージェントの作業の異なる時点で読み込まれます。
1グローバルコンテキスト | 常に存在し、すべてのセッションで有効2プロジェクトコンテキスト | プロジェクト開始時に読み込まれる3タスクコンテキスト | 特定のタスクのために読み込まれる
グローバルコンテキストは永続的な層です。アイデンティティ、コアルール、コーディングスタイル、エージェントが絶対にしてはいけないことなどが含まれます。これはセッション間で変わることはなく、再説明する必要もありません。
1グローバルコンテキストの内容:2- エージェントのアイデンティティと役割3- コーディング基準とスタイルルール4- セキュリティ制約5- 決して触れてはいけない、または変更してはいけないもの6- 不確実性への対処方法
プロジェクトコンテキストは知識の層です。Claude がこの特定のコードベースを理解するために必要なすべて（アーキテクチャ、使用されているパターン、決定事項とその理由、以前に何がうまくいかなかったかなど）が含まれます。
1プロジェクトコンテキストの内容:2- README とアーキテクチャの概要3- プロジェクト固有のルールを記した AGENTS.md4- フォルダ構造と命名規則5- テスト要件とパターン6- 主要な依存関係とその選定理由
タスクコンテキストは実行の層です。現在取り組んでいるファイル、現在のチケット、直近の目標、この特定のタスクに適用される制約などが含まれます。
1タスクコンテキストの内容:2- 現在のファイルおよび関連ファイル3- このセッションの具体的な目標4- 最近の変更とその結果5- 現在のテスト結果6- このタスク固有の制約
ほとんどの開発者は Claude にタスクコンテキストしか与えません。エージェントはグローバルコンテキストやプロジェクトコンテキストなしでセッションを開始するため、知らないことをすべて推測しなければなりません。その推測こそがミスの原因です。
AGENTS.md - すべてを変えるファイル
本格的な Claude Code のセットアップにおいて、最も重要なファイルです。研究者たちは AGENTS.md を AI コーディングエージェントのコンテキストにおける新しい標準として特定しました。これが機能するため、現在数千もの本番環境のリポジトリで採用されています。
AGENTS.md は、プロジェクトコンテキストが永続的に存在する場所です。Claude はすべてのセッション開始時にこれを自動的に読み込みます。その後は、同じことを二度と説明する必要はありません。
1# AGENTS.md23## アーキテクチャ4Next.js フロントエンドと Express バックエンドのモノレポ構成。5すべての API ルートは /api に配置。/legacy は直接変更しないこと。67## コーディングルール8axios は絶対に使用せず、fetch を使用すること。9すべてのコンポーネントは TypeScript、Tailwind、Server Actions で記述。10ページ以外でのデフォルトエクスポートは禁止。1112## テスト13ユニットテストには Vitest、E2E には Playwright を使用。14すべてのコミット前に npm test を実行すること。15失敗したテストを無効にせず、修正するかエスカレーションすること。1617## Git18main ブランチへの直接コミットは禁止。19必ず明確な説明を添えて PR を作成すること。20すべての PR を Linear チケットに紐付けること。2122## 触れてはいけないもの23src/payments/ - 変更には人間の承認が必要24src/auth/tokens/ - セキュリティレビューが必要25.env ファイル - 読み取りや変更は禁止
このファイルにあるすべてのルールは、Claude が二度と繰り返さないミスになります。プロジェクトが長く続くほど、AGENTS.md はより具体的で価値のあるものになります。これは、エージェントが犯したすべてのエラーと、チームが確立したすべての慣習から得られた知識の蓄積なのです。
本格的なエージェントを支えるコンテキストスタック
優れた AI エンジニアは、プロンプトを書くことからタスクを始めません。彼らはコンテキストスタックを構築します。これは、Claude が最初のアクションを起こす前に読み込まれる、構造化された情報シーケンスです。
1ステップ 1 | グローバルコンテキストの読み込み - アイデンティティ、ルール、スタイル2ステップ 2 | プロジェクトコンテキストの読み込み - AGENTS.md、アーキテクチャ、ドキュメント3ステップ 3 | 関連する過去の経験をメモリから検索4ステップ 4 | この特定のタスクに関連するファイルを読み込み5ステップ 5 | 現在の状態を読み込み - テスト結果、最近の変更6ステップ 6 | 明確な成功基準とともにタスクの目標を定義7ステップ 7 | Claude が完全な情報に基づいてアクションを実行
コンテキストエンジニアリングが適切に行われたエージェントと、デフォルトの状態を比較してみましょう。
1ダメなエージェント:2質問 → Claude → 回答3Claude は知らないことをすべて推測する45優れたエージェント:6質問7↓ ドキュメントを検索8↓ メモリを検索9↓ AGENTS.md を読み込む10↓ 関連ファイルを読み込む11↓ 現在の状態を確認12↓ Claude13↓ 完全な情報に基づいた回答
後者のエージェントが賢いわけではありません。より良い情報を持っているだけです。モデルは同一ですが、コンテキストが異なります。
メモリ - セッション間を生き抜くコンテキスト
Anthropic は、コンテキストに供給されるメモリの種類を明確に区別しています。ほとんどのエージェントは「現在の会話」という一つのメモリしか持っていません。だからこそ、毎回ゼロからセッションを開始することになるのです。
1長期メモリ | 過去の全セッションを通じて学習したすべて2短期メモリ | この会話の初期に何が起こったか3ワーキングメモリ | 今まさにコンテキストウィンドウにあるもの
長期メモリこそが、エージェントの価値を時間とともに高める要素です。すべてのセッションがそこに積み重なります。すべてのミスが記録され、すべての成功パターンが保存されます。6 ヶ月間コードベースで稼働し続けているエージェントは、どんなプロンプトでも再現できないそのプロジェクト独自の知識を持っています。
その実践的な実装が「メモリファイル」です。これは会話の外にあるマークダウン形式のドキュメントで、エージェントはセッション開始時に読み込み、終了時に更新します。
1# プロジェクトメモリ23## アーキテクチャの決定事項4- Firebase ではなく Supabase を選択: リアルタイム性はそれほど重要ではなく、SQL クエリが必要だったため5- REST から tRPC へ移行: スタック全体での型安全性を確保 (2026 年 6 月)67## うまくいったこと8- リファクタリング前のテストカバレッジ向上によりリグレッションを防止9- 大きな PR を機能フラグごとのリリースに分割することでレビュー時間を短縮1011## うまくいかなかったこと12- マイグレーションの自動生成: スキーマの乖離により本番環境でインシデントが発生13- 同一ファイルへのエージェントによる並列書き込み: 常に worktrees を使用すること1415## 繰り返されるパターン16- 認証の問題は、ほぼすべてミドルウェアの順序に起因する17- パフォーマンスの問題は、通常データベースのクエリ層から始まる
セッションごとにこのファイルが読み込まれ、更新されます。エージェントは決して忘れません。
MCP - あらゆる場所からのコンテキスト
コンテキストはリポジトリ内のファイルからだけ得られるものではありません。本番環境のエージェントは、チームが使用するあらゆるシステム（課題管理ツール、エラー監視ツール、ドキュメント、データベース、コミュニケーションツール）からのコンテキストを必要とします。
Model Context Protocol (MCP) は、個別のカスタム統合を必要とせずに、Claude が外部システムからコンテキストを抽出するための仕組みです。
1ファイルシステム | ローカルファイル、設定、コードベース2GitHub | 課題、PR、コミット履歴、CI 結果3Linear / Jira | チケット、優先順位、プロジェクトの状態4Slack | 決定事項、議論からのコンテキスト5Postgres | ライブデータ、スキーマ、クエリ結果6Google Drive | ドキュメント、仕様書、会議メモ7Sentry | ライブエラー、発生頻度、影響を受けるユーザー
MCP が設定されたエージェントは、コードを見るだけではありません。この機能が必要な理由を説明したチケット、アーキテクチャが決定された Slack の会話、ユーザーがバグに遭遇している様子を示す Sentry のエラー、そして修正が考慮すべきデータベーススキーマまでを見通します。
これこそが完全なコンテキストです。Claude が推測に頼らず、正しい決定を下すために必要なすべてが揃っています。
コンテキストエンジニアリングのワークフロー
適切にコンテキストエンジニアリングされたタスクは、最初から最後までこのように見えます。
「〜して」ではなく：
1エクスポート機能を構築して。
Claude にはこう与えます：
1目標2エクスポート機能が無料版からプロ版への転換を阻害している。3シグナルを参照: /signals/export-too-hidden.md45関連ファイル6src/features/export/ - 現在の実装7src/components/ui/Button.md - 従うべきボタンパターン8tests/features/export.test.ts - 既存のテストカバレッジ910アーキテクチャの制約11AGENTS.md の「Export Rules」セクションを参照12課金統合部分は直接変更しないこと1314成功基準15既存のテストがすべてパスすること16新しいテストが 3 つのエクスポート形式をカバーすること17Linear チケット EXP-47 を紐付けた PR を作成すること18src/payments/ には変更を加えないこと
タスクは同じでも、コンテキストが全く異なります。出力が少し良くなるというレベルではなく、Claude が推測ではなく完全な情報に基づいて決定を下しているため、根本的に異なる結果が得られます。
今週末に試すべき実践的なセットアップ
1 日目 - 3 層のコンテキストスタックを構築する。アイデンティティとコアルールを記したグローバルコンテキストファイルを作成する。プロジェクトのアーキテクチャ、コーディング規約、禁止事項をまとめた AGENTS.md を作成する。セッション開始時に読み込み、終了時に更新されるメモリファイルを設定する。
2 日目 - MCP を介して外部コンテキストを接続する。GitHub コネクタをインストールして、課題管理や PR 履歴を Claude に見せる。ファイルシステムコネクタをインストールして、コードベースを効率的にナビゲートさせる。チームが意思決定に使用しているなら、Slack や Linear も追加する。
3 日目 - 違いをテストする。従来の「プロンプトのみ」のアプローチと、完全なコンテキストスタックを用いたアプローチで同じタスクを実行してみる。その出力の差こそが、8 倍の生産性を生み出す源泉です。
すでに起きている転換
プロンプトエンジニアリングは「適切な言葉を見つけること」でした。コンテキストエンジニアリングは「適切な情報環境を構築すること」です。
Anthropic の優れた AI エンジニアは、気の利いたプロンプトを作ることに時間を費やしません。彼らは、Claude が最初のアクションを起こす前に、正確な知識、メモリ、ファイル、ルール、状態を確実に持たせることに時間を費やします。プロンプトは作業の最後の 1% に過ぎません。コンテキストが残りの 99% です。
完璧なプロンプトを持ちながらコンテキストが貧弱なエージェントは、知的なミスを犯します。平均的なプロンプトでも完全なコンテキストを持つエージェントは、正しい決定を下します。モデルは同じでも、情報環境が異なるのです。
コンテキストは AI のオペレーティングシステムです。正しく構築すれば、Anthropic で起きている 8 倍の生産性の差は、あなたのコードベースでも起きるようになります。
ほとんどの開発者はプロンプトを書き換え続け、なぜ結果が改善しないのかと不思議に思うでしょう。しかし、一部のエンジニアは週末を使って適切なコンテキストスタックを構築し、二度と元には戻らないはずです。
人生を築くのはあなた自身です。正しい道を選んでください。
/ 役に立ったならフォローしてください /
