2025年AI開発の新常識！Context Engineering（コンテキストエンジニアリング）が変える開発現場

はじめに：プロンプトエンジニアリングの先へ

こんにちは、みなさん！新人プログラマーだった頃、私はAIモデルに「何か面白いことを言って」と入力して、その反応に一喜一憂していました。でも今、AIとの対話は単なる「お遊び」から「本格的な開発手法」へと進化しています。

Vibe Codingが流行した後、今度はAndrej Karpathyが新たなバズワードを生み出しました——それが「Context Engineering（コンテキストエンジニアリング）」です。

日本語では「コンテキストエンジニアリング」と呼ばれ、これが今、AI開発者の間で熱い注目を集めています。Karpathyは遠慮なくこう言い切りました：

「コンテキストエンジニアリングとは、コンテキストウィンドウを精巧に設計する芸術と科学である」

Karpathyといえば、AI界の重鎮として知られ、開発者の直感に響く言葉で複雑な技術トレンドを定義するのが得意な人物です。「Software 2.0」「Software 3.0」「Vibe Coding」、そして最近提唱した「Bacterial Programming（細菌プログラミング）」など、彼が提唱する概念はほぼ例外なく業界で火がつきます。

これに対してKarpathy自身は：

「ハハ、新しい言葉を発明しているわけじゃないよ。ただ、みんなが『プロンプト』という概念を単純化しすぎて、その複雑さを過小評価していると思っただけさ」

と返しています。

確かに、「コンテキストエンジニアリング」は全く新しい概念ではありません。2025年のAI Agent（エージェント）ブームに伴い、業界で徐々に形成されてきたコンセンサスなんです。

私の理解では、これはまだ「流行りの言葉」でありながら「定義があいまい」な概念です。でも、これからのAI開発において避けて通れない重要なスキルになることは間違いないでしょう。

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

「プロンプト」という言葉を聞くと、多くの人はChatGPTに「量子力学を説明して」といった単純な指示を出すことをイメージするでしょう。もう少し複雑なプロンプトでも、タスクの説明を加えたり、例を示したり、出力ルールを定義したりと、基本的には「自分の要求をできるだけ明確に伝える」ことが核心です。

でも、本格的なアプリケーションを開発する場合、それは単なるプロンプト一発では済まないんです。大規模言語モデル（LLM）に複雑でカスタマイズされたタスクを完了させるには、コンテキスト（文脈・上下文）を精巧に構築する必要があります。

簡単に言えば：

「プロンプトエンジニアリング」はユーザー向け、「コンテキストエンジニアリング」は開発者向けなんです。

「名前を変えただけじゃないか」と思う人もいるかもしれませんが、いえいえ、名前は非常に重要です。なぜなら、言語が思考を形作るからです。

ShopifyのCEOであるTobi Lutke も「正名」の立場に立ち、「コンテキストエンジニアリング」は「プロンプトエンジニアリング」より優れた概念だと考え、タスクにはすべての背景情報を提供すべきだと主張しています。

なぜコンテキストエンジニアリングは「芸術と科学」なのか？

なぜ「科学」なのか

最近、Googleの長文コンテキスト事前学習の共同責任者であるNikolay Savinovがあるブログのインタビューで、エージェント（Agent）とコンテキスト（Context）の間の深い共生関係について語りました。これは非常に示唆に富む内容でした。

サビノフによると、Agentは「二重の役割」を担っているそうです：

• 一方では、Agentはコンテキストの消費者です。例えば、「5日間の東京旅行を計画する」という複雑なタスクを実行するAgentは、「航空券は予約済み」「ホテルの価格を比較中」「まだ旅程を完成させる必要がある」などの状態情報を継続的に記憶しておく必要があります。長いコンテキストのサポートがなければ、質問するたびに記憶を失い、一貫したタスクフローを形成できません。コンテキストはAgentにとって不可欠な「メモリハードドライブ」なのです。

• 他方では、Agentはコンテキストの創造者でもあります。現実世界では、ユーザーがすべての背景情報（予算、時間の好み、過去の検索履歴、地理的な好みなど）を手動でパッケージ化してAgentに与えることはありません。ここで、Agentの「ツール使用能力」が非常に重要になります。Agentは検索、カレンダー、旅行APIなどのツールを積極的に呼び出し、生の情報を取得し、フィルタリング、精製、構造化処理を通じて、これらの原材料を高品質なコンテキストに動的に組み立て、大規模言語モデルに供給します。

つまり、Agentはコンテキストに依存して「生きる」と同時に、ツールを通じて積極的にコンテキストを構築し、それによってモデルをより「賢く」します。これこそが「コンテキストエンジニアリング」が科学となる根本的な理由です。

単純なプロンプト作成やデータの連結ではなく、タスク要件の動的な感知、情報構造の組織化、トークン配置の制御、入出力のバランスに関する完全な方法論なのです。

より分かりやすく言えば、コンテキストエンジニアリングの定義はこうなります：

それは動的システムを設計・構築する学問であり、その唯一の目標は：適切なタイミングで、適切な形式で、タスク完了に必要なすべての情報とツールを大規模言語モデルに正確に「供給」することです。

Karpathyによれば、コンテキスト設計には以下の要素が含まれるべきです：

• タスク指示（task instructions）
• 例示（few-shot examples）
• 検索補足コンテンツ（RAG）
• マルチモーダル情報
• 外部ツール/関数
• 現在の状態と履歴コンテキスト
• コンテキスト圧縮と最適化（compacting）

考慮が少なすぎると、モデルはタスクを理解できません。多すぎたり無関係だったりすると、コストが上がり、パフォーマンスが低下します。これは科学的な技術作業なのです。

Google DeepMindの上級AIリレーションシップエンジニアであるPhilipp Schmid（フィリップ・シュミット）も、最新のブログでコンテキストエンジニアリングを複数の構成モジュールに分解しています：

• システムプロンプト/システム指示：行動、ルール、例の定義
• ユーザープロンプト：現在の問題またはタスク
• 短期記憶/会話履歴：現在のセッションの内容
• 長期記憶：セッションをまたぐユーザーの好み、プロジェクト情報
• 検索情報（RAG）：ドキュメント、データベース、APIからの動的コンテンツ取得
• 利用可能なツール：search、send_emailなどの関数定義
• 構造化出力：JSON、表などの指定形式

さらに、コンテキストエンジニアリングの4つの主要特性を挙げています：

1. 動的システムであり、静的な文字列ではない。コンテキストは「テンプレート」として固定されるのではなく、LLMを呼び出す前にAgentがリアルタイムのニーズに基づいて動的に組み立てた結果です。それは生命力を持っています。

2. 必要に応じて生成され、不変ではない。あるリクエストでは、コンテキストはあなたのスケジュールかもしれません。次のリクエストでは、最新のウェブ検索結果や重要なメールが必要かもしれません。それは「千人千様、千時千様」なのです。

3. 情報とツールを正確に供給し、情報の洪水ではない。核心は「ちょうど良い」こと。「ゴミ入力、ゴミ出力」を避けます。タスクが本当に必要とする情報と能力だけを提供し、それ以上は干渉になります。

4. 形式を非常に重視し、「生の」データではない。モデルに一連の未加工のログを投げ込むよりも、精製された要約を提供する方が良いです。明確な構造を持つツール呼び出し指示は、あいまいな自然言語の説明よりもはるかに優れています。

実際のAI開発における課題

実際のLLMアプリケーション/Agent開発プロセスでは、「コンテキストを精巧に構築する」だけでなく、多くのエンジニアリング問題も処理する必要があります：

• タスクロジックの分解（problem decomposition）
• 呼び出しフローの制御（control flow）
• 異なるモデル能力のマッチング（モデルスケジューリング）
• ユーザーインタラクションの処理（UI/UX）
• 検証ステップの構築、セキュリティの追加、効果の評価
• 並列化、プリフェッチング（prefetching）などのパフォーマンス最適化の実装...

この全体のシステムは、すでに複雑で重厚なソフトウェアシステムとなっています。コンテキストエンジニアリングはその一部ですが、Agentの成功を左右する核心の一つでもあります。

実際の開発現場では、APIドキュメントの管理もコンテキストエンジニアリングの重要な一例です。例えば、Apidogのようなツールは、APIの仕様、エンドポイント、パラメータ、レスポンス例などの情報を構造化して管理し、開発者が必要な情報を適切なタイミングで参照できるようにします。これは「情報の選別」「構造化」「適切なタイミングでの提供」というコンテキストエンジニアリングの原則そのものです。

特に複数のマイクロサービスが連携する現代のシステムでは、APIコンテキストの適切な管理がプロジェクトの成功を左右することも少なくありません。例えば、あるプロジェクトでは、Apidogを使ってAPIのモックデータを作成し、フロントエンドとバックエンドの開発を並行して進めることで、開発期間を30%短縮できたという事例もあります。これはまさに「コンテキストの動的生成」と「情報の適切な供給」というコンテキストエンジニアリングの原則が実践された好例と言えるでしょう。

なぜ「芸術」でもあるのか

それは、「情報を選択する」「構造を作る」「長さを制御する」といった原則を知っていても、実際の開発では、言葉にできない、公式化できない多くの判断と微調整が必要だからです。

例えば、LLMがあなたのプロンプトをどのように「見ている」のかは分かりません。固定された構文やインターフェイスドキュメントはありません。あなたが意味的にほぼ同じだと思う2つのバージョンの入力文でも、最終的なモデルのパフォーマンスは大きく異なる可能性があります。

だから、経験と「モデルとの対話の直感」に頼って、繰り返し試し、言い回しを調整し、順序を配置する必要があります。まるで気難しいパートナーを調教するようなものです。

これが「プロンプトセンス」です。なぜある人はAIで10倍の効率を得られ、ある人は役に立たないと感じるのか、その違いはここにあります。

だから、今後特に優れた製品に出会ったとき、「またChatGPTのラッパーアプリか」と言うのは、少し失礼かもしれませんね。

コンテキストエンジニアリングの実践方法

AI開発フレームワークLangChainが発表したブログでは、4つの核心的な実装戦略がまとめられています：

第一の戦略：書き込み（Write）—— AIに「下書き帳」と「長期記憶」を与える

AIも「下書き」や「日記」が必要です。

複雑なタスクを処理する際、AIに中間ステップの思考を一時的な「下書き帳」（Scratchpads）に記録させたり、重要な結論をセッションをまたぐ「長期記憶」（Memory）モジュールに保存させたりします。これにより、メイン対話ウィンドウをすっきりと保ちながら、AIに継続的な学習と振り返りの能力を持たせることができます。

第二の戦略：選別（Select）

量より質です。

AIがタスクに直面したとき、インテリジェントな「ディスパッチェー」を起動し、膨大な知識ベース（ドキュメント、ツール、記憶）から、RAGなどの技術を通じて、現在最も関連性の高い情報を正確に選別してモデルに「供給」します。これにより情報過多を避け、モデルが核心的な問題に集中できるようにします。

第三の戦略：圧縮（Compress）

コンテキストメモリには限りがあり、一寸の土地も金です。

会話履歴や検索ドキュメントが長すぎる場合、「断捨離」を学ぶ必要があります。要約や剪定などの戦略を通じて、コンテキストを賢く「スリム化」し、重要な情報を失わずに、最も精髄な内容を貴重なコンテキストウィンドウ内に残します。

第四の戦略：隔離（Isolate）

分割して統治し、複雑さを単純化する。これはマルチエージェント（Multi-agent）システムの真髄です。一人の「万能」Agentにすべての複雑さに対応させるよりも、大きなタスクを分解し、独立した最適化されたコンテキストを持つ複数の「専門」Agentに配布し、それぞれが自分の役割を果たし、最後に成果を集約して1+1>2の効果を実現します。

コンテキストエンジニアリングの「病理学」

LangChainの開発者Drew Breunigは、非常に重要な観点を提示しました：

ほとんどのインテリジェントエージェントの失敗は、もはやモデル自体の失敗ではなく、私たちが与える「コンテキスト」に問題があるのです。

彼はこれらの問題を4つの典型的な「病理学」に分類しています：

病症1：コンテキスト中毒

• 症状：AIがツールを呼び出すとき、誤った情報や純粋な「幻覚」（存在しないURLや誤ったデータなど）を持ち帰り、これらの「毒素」が全体のコンテキストを汚染し、後続の推論がすべて誤りになります。
• 解決策：
  • （1）隔離：不安定なツールを「サンドボックス」環境で実行し、検証済みの無毒な結果だけをメインシステムに戻します。
  • （2）選別：情報検索後、「品質検査」プロセスを追加し、低品質で疑わしい情報源をフィルタリングまたは並べ替えます。
  • （3）書き込み：「下書き帳」にツール呼び出しの出所と信頼性を記録し、いつでも「毒源」を追跡・調査できるようにします。

病症2：コンテキスト注意散漫

• 症状：AIに一度に多すぎる情報を詰め込む（たとえそれらの情報がすべて関連していても）。膨大なコンテキストが最も核心的な指示を埋もれさせ、学生の前に参考書が多すぎて最も重要な教科書が見つからないような状態になり、AIが「重点を掴めない」状態になります。
• 解決策：
  • （1）隔離：「マルチエージェント」戦略を採用し、各Agentが自分の専門分野だけに集中し、最も関連性の高い狭い情報だけを見るようにします。
  • （2）圧縮：定期的にコンテキストを「スリム化」し、要約と剪定によってコンテキストの長さを大幅に減らし、核心的な指示が常に「水面に浮いている」ようにします。
  • （3）選別：現在のサブタスクに最も重要な知識とツールだけを選択し、一度に情報の洪水を避けます。

病症3：コンテキスト混乱

• 症状：AIに与える情報の形式が混乱し、整理されていない。例えば、乱雑なログの山をそのまま投げ込むと、AIが予期せぬ誤った方法で解釈し、最終的に「的外れ」な結果を出力します。
• 解決策：
  • （1）圧縮：LLMの要約能力を利用して、非構造化の「生の」データを、明確で簡潔な「調理済み」データに精製してからモデルに供給します。
  • （2）書き込み：「下書き帳」や記憶モジュールを設計する際に、異なるタイプの情報（履歴記録、ツール出力など）を異なるフィールドに保存し、根本から構造の明確さを保証します。
  • （3）選別：検索された情報の形式が統一されていることを確認し、その意味を説明する「説明書」（メタデータ）を添付します。

病症4：コンテキスト衝突

• 症状：コンテキストの異なる部分に矛盾する情報が含まれている。例えば、あるドキュメントでは「Aが正しい」と言い、別のドキュメントでは「Bが正しい」と言う場合、AIは明確な指導がない状況で「陣営を選ぶ」ことを強いられ、決定ミスを引き起こしやすくなります。
• 解決策：
  • （1）選別：情報がLLMに送られる前に、「衝突仲裁層」を設置し、矛盾する情報を事前に処理します。
  • （2）隔離：異なる（そして潜在的に衝突する）情報源を処理するタスクを、異なる「討論者」Agentに割り当て、最後に「裁判官」Agentが判決を下します。
  • （3）書き込み：「長期記憶」に決定結果だけでなく、その決定を下した理由も保存し、将来同様の衝突に遭遇したときに参照できるようにします。

企業におけるコンテキストエンジニアリングの重要性

興味深いことに、Shopifyでは、自発的にAIを使用し、「AIにコンテキストを読み込ませる」能力が従業員の基本的な期待になりつつあり、さらにパフォーマンス評価にも組み込まれています。

現在、どのチームも人員増加を申請する前に、まず会社に証明しなければなりません：なぜこのタスクは、「適切にエンジニアリングされたコンテキスト」を持つAIインテリジェントエージェントによって完了できないのか？

まとめ：コンテキストエンジニアリングの未来

強力で信頼性の高いAIエージェントを構築することは、魔法のようなプロンプトやモデルの更新を見つけることではなくなりつつあります。それは、適切なタイミングで、適切な形式で、適切な情報とツールを提供するコンテキストのエンジニアリングなのです。

これは、ビジネスユースケースを理解し、出力を定義し、LLMが「タスクを達成する」ためのすべての必要な情報を構造化する、分野横断的な課題です。APIドキュメント管理ツールのApidogが情報の構造化と適切な提供を実現しているように、AIエージェント開発においても、情報の構造化と適切なタイミングでの提供が成功の鍵となります。

私自身、最近のプロジェクトでコンテキストエンジニアリングの原則を適用してみましたが、AIの応答品質と一貫性が劇的に向上しました。特に、情報の選別と構造化に時間をかけることで、以前は不可能だと思っていた複雑なタスクもAIに任せられるようになりました。

みなさんは「コンテキストエンジニアリング」が次の大きなトレンドになると思いますか？それとも過大評価された概念だと思いますか？コメント欄でみなさんの洞察をぜひ共有してください！

参考：