AIの性能を最大限に引き出すために重要なのは、最新のモデルを選ぶことではありません。どんな情報を、どのタイミングで、どのフォーマットで渡すか。この「コンテキストの設計」が、AIの出力品質を左右する最大の変数です。
2025年6月、AI研究者のAndrej Karpathyがこの概念に名前を与えました。コンテキストエンジニアリングです。「プロンプトエンジニアリングの時代は終わった」という彼の発言は、AI開発者コミュニティに大きな反響を呼び、2026年現在、エンタープライズAI開発の中核テーマとなっています。
コンテキストエンジニアリングとは
コンテキストエンジニアリングとは、LLM(大規模言語モデル)のコンテキストウィンドウに、次のステップのためにちょうど正しい情報を満たす繊細な技術と科学です(Karpathy, 2025年6月)。
プロンプトエンジニアリングが「AIへの指示文をどう書くか」に焦点を当てるのに対し、コンテキストエンジニアリングは指示文を含むあらゆる入力情報の設計を対象とします。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 対象 | 指示文(プロンプト)のみ | AIに渡す全情報(プロンプト、データ、ツール、履歴) |
| 性質 | 静的な文字列の最適化 | 動的なシステムの設計 |
| タイミング | 事前に固定 | タスクに応じてリアルタイムに構成 |
| 目的 | より良い回答を得る | AIが正しく判断・行動できる環境を構築する |
Hugging FaceのAIエンジニアリング責任者Phil Schmidは、コンテキストエンジニアリングの本質を4つの属性で整理しています。
1つ目は「システムであり文字列ではない」こと。静的なプロンプトテンプレートではなく、メインのLLM呼び出しの前に走るシステム全体の出力として捉えます。2つ目は「動的」であること。カレンダーデータ、CRM情報、Web検索結果など、タスクに合わせてリアルタイムに生成されます。3つ目は「正しい情報とツールを正しいタイミングで提供する」こと。不要な情報はノイズとなりAIの判断を誤らせます。4つ目は「フォーマットが重要」であること。簡潔な要約は生データのダンプに勝り、明確なツールスキーマは曖昧な指示に勝ります。
AIエージェントの急速な普及により、プロンプト単体の最適化では対応できない複雑なタスクが増えています。複数のツールを使い、長時間にわたって自律的に動作するエージェントには、動的に構成されるコンテキスト全体の設計が不可欠です。
AIエージェント時代のコンテキスト設計
LangChainのViv Trivedyは、AIエージェントの構造を「Agent = Model + Harness」という等式で定式化しています(2026年3月)。Modelが知性(intelligence)を持ち、Harness(ハーネス)がその知性を有用にする。ハーネスとは、モデルそのもの以外の全てのコード、設定、実行ロジックを指します。
コンテキストエンジニアリングは、このハーネス設計の中核です。ハーネスがコンテキストウィンドウにどんなデータを、どのタイミングで、どのフォーマットで注入するかを制御します。
重要な知見があります。Schmidが指摘する通り、エージェントの失敗はコンテキストの失敗であり、モデルの失敗ではありません。LangChainの実験では、モデルを一切変更せずハーネス(コンテキスト設計)だけを改善することで、Terminal Bench 2.0のスコアが52.8%から66.5%へ、13.7ポイント向上しました。
しかし、コンテキストには限界があります。Context Rot(コンテキスト劣化)と呼ばれる現象です。最新モデルは100万トークン以上のコンテキストウィンドウを持ちますが、Databricks Mosaicの研究では32Kトークンを超えるとモデルの正確性が低下し始めることが示されています。さらにLLMはコンテキストの最初と最後の情報を優先し、中間部分を無視する「Lost in the Middle」効果も確認されています。
つまり、容量が大きいからといって情報を詰め込めばよいわけではありません。有効な性能ゾーンの中に、最も価値の高い情報を効率的に配置する設計が求められます。
コンテキストを構成する5つの要素
コンテキストエンジニアリングで管理すべき要素は、大きく5つに分類できます。
1. システムプロンプトと指示設計
AIの役割定義、制約条件、出力フォーマットの指定です。これは従来のプロンプトエンジニアリングの領域ですが、コンテキストエンジニアリングではシステムプロンプトをコンテキスト全体の一部として位置づけます。AIエージェントの文脈では、CLAUDE.mdやAGENTS.mdのようなプロジェクト指示ファイルがこの役割を担います。
2. 動的コンテキスト(RAGと状態管理)
タスクの実行時に動的に取得される情報です。ベクトルデータベースからの検索結果(RAG)、CRMから取得する顧客情報、会話履歴、直近のツール呼び出し結果などが含まれます。RAGはコンテキストエンジニアリングの一要素であり、検索の必要性をエージェント自身が判断するAgentic RAGへと進化しています。
3. ツールと構造化出力
AIが外部システムと連携するためのインターフェースです。関数呼び出し、API連携、MCP(Model Context Protocol)サーバーなどが該当します。ツール定義自体がコンテキストを消費するため、100以上のツールを事前に読み込むとハルシネーションを引き起こすことが知られています。必要なツールだけを段階的に開示する「Progressive Skill Disclosure」が有効です。
4. 長期メモリ
セッションをまたいで保持される情報です。2025-2026年のエージェント開発では、3種類のメモリが標準化されています。過去の具体的な対話や経験を記録するEpisodic Memory、事実や知識を蓄積するSemantic Memory、学習した行動パターンを保持するProcedural Memoryです。メモリの管理はハーネスの責務であり、適切なタイミングで適切なメモリをコンテキストに注入する設計が求められます。
5. コンテキスト最適化
限られたコンテキストウィンドウを効率的に使うための戦略です。主に3つのアプローチがあります。古いツール呼び出しや会話履歴を知的に要約するCompaction(圧縮)、冗長なツール出力をファイルシステムに保存してコンテキストから外すTool Output Offloading(外部化)、全ツール定義を事前に読み込まず必要に応じて段階的に開示するProgressive Disclosure(段階的開示)です。Anthropicの研究では、Memory Pointers(生データの代わりに軽量IDを渡す手法)で84%のトークン削減を実現した事例が報告されています。
企業でのコンテキストエンジニアリング導入ステップ
コンテキストエンジニアリングを企業のAI活用に取り入れるには、3つのステップで進めるのが現実的です。
Step 1: 業務データの構造化
まず、AIに渡すべきデータを特定し、構造化します。CRMに蓄積された顧客情報、商談や会議で交わされた対話データ、社内のドキュメントやナレッジベース。これらを機械可読な形式に整理することが出発点です。特に対話データは、CRMの定型フィールドには収まらない一次情報(顧客の具体的な発言、感情の変化、競合への言及)を含んでおり、コンテキストの質を大きく左右します。
Step 2: コンテキストパイプラインの設計
次に、どの情報を、いつ、どのフォーマットでAIに渡すかを設計します。全ての情報を常に渡すのではなく、タスクの種類に応じて動的にコンテキストを構成するパイプラインを構築します。例えば、商談分析であれば直近の対話データとCRM情報を優先的に注入し、レポート生成であれば過去の実績データとテンプレートを優先します。
Step 3: 段階的な自動化と品質モニタリング
最初から完全自動化を目指すのではなく、「AIが提案し、人間が承認する」段階から始めます。AIの出力品質をモニタリングし、コンテキストの構成を継続的に改善していきます。コンテキストの質が向上するにつれ、自動化の範囲を段階的に拡大します。
営業領域でのコンテキストエンジニアリングの詳しい実践方法は、コンテキストエンジニアリングで営業AIの精度を変える方法で解説しています。
aileadは対話データを安全に統合・構造化し、AIエージェントが業務を自動で動かすエンタープライズ基盤です。商談や会議の対話データをBANT情報、顧客課題、競合情報として構造化し、SalesforceカスタムオブジェクトへAI自動入力します。導入400社以上、SFA入力工数90%削減の実績があります。AIエージェントの詳細を見る
関連記事
- コンテキストエンジニアリングで営業AIの精度を変える方法
- AIエージェント導入の進め方: ステップ別完全ガイド
- 対話データとAIエージェントの活用: 商談分析から営業強化へ
- エージェンティックワークフロー vs RPA: 自律型AIと自動化の違いを解説
- Gemini AI検索がB2Bリード獲得を変える
ailead編集部
株式会社ailead
aileadの公式編集部です。営業DX・AI活用に関する情報を発信しています。



