「プロンプトエンジニアリング」に続く言葉として、「コンテキストエンジニアリング(Context Engineering)」の注目が高まっています。
生成AIやAIエージェントの成果を左右するのは、もはや指示文の巧みさだけではありません。AIに「何を、どの順で、どれだけ渡すか」という情報環境の設計こそが、出力の質を決める——。そうした考え方です。
本記事では、コンテキストエンジニアリングの意味、プロンプトエンジニアリングとの違い、構成要素、そして企業が実践するための具体的なステップまでを、経営者の視点で整理します。
目次
コンテキストエンジニアリングとは
コンテキストエンジニアリングとは、AIが応答を生成する際に参照する情報環境そのものを設計・管理する技術領域です。具体的には、システム指示や参照するデータ、ドキュメント、会話の履歴、利用できるツール、出力の形式といった要素をタスクに対して過不足なく整える行為を指します。
プロンプトが「AIへの1回の問いかけ」だとすれば、コンテキストは「AIの作業机の上に、適切な資料を並べておく」の全体像です。同じモデルを使っていても、渡すコンテキストの質と量が違えば、精度は大きく変わります。モデルの性能差が縮まりつつある今、成果を分ける主戦場が「指示の磨き方」から「情報環境の設計」へと移りつつあるのです。
なぜ、いまコンテキストエンジニアリングなのか
背景には、生成AI導入の「期待外れ」が広がっている現実があります。米調査会社のガートナーは2025年6月、2027年末までにエージェント型AIプロジェクトの40%以上がキャンセルされると予測しました。
理由として挙げられたのは、コストの高騰やビジネス価値の不明確さ、リスク管理の不備です(出典:Gartner「Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027」2025年6月25日)。
多くの企業は当初、成果が出ない原因を「プロンプトの書き方」に求めました。しかし海外のAI実装の最前線では、問題は指示の出し方ではなく「AIに渡している情報そのもの」にあるという見方が定着しつつあります。
この転換をいち早く言語化したのが、ShopifyのCEOトビ・リュトケ氏です。同氏は2025年6月、自身のX投稿で「コンテキストエンジニアリングという言葉のほうが、プロンプトエンジニアリングよりも本質を捉えている。LLMが解ける形でタスクを成立させるために必要な文脈をすべて提供する技術こそが、核となるスキルだ」と述べました(出典:Tobi Lütke 氏 X投稿、2025年6月)。
プロンプトエンジニアリングとの違い
両者は対立するものではなく、役割が異なります。プロンプトエンジニアリングが「どう問いかけるか」を磨く技能であるのに対し、コンテキストエンジニアリングは「何を渡すか」を設計する仕組みづくりです。主な違いを次の表に整理しました。

| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
| 対象 | AIへの問いかけ(指示文) | AIが参照する情報環境の全体 |
| 主眼 | どう聞くか | 何を、どの順で、どれだけ渡すか |
| 単位 | 1回の指示 | 継続的な設計・運用 |
| たとえ | 質問の仕方を磨く | 机に必要な資料を過不足なく並べる |
| 担い手 | 主に個人の技能 | 組織の仕組み・データ基盤 |
コンテキストエンジニアリングの主な構成要素
AIに渡すコンテキストは、大きく次の要素で構成されます。これらを過不足なく設計することが、コンテキストエンジニアリングの実務です。
- システム指示:AIの役割、守るべき制約、トーンなどの前提を定義する。
- 参照データ・ナレッジ:社内文書やデータベースを、AIが検索・参照できる形で用意する(RAG=検索拡張生成の仕組みなど)。
- 会話履歴・状態:これまでのやり取りや業務の進行状況を保持し、文脈を途切れさせない。
- 利用可能なツール:検索、社内システムのAPI、実行アクションなど、AIが「使える手段」を渡す。
- 出力フォーマット:回答の構造や形式を指定し、後工程で使える形に整える。
- 取捨選択と順序:限られたコンテキスト枠に、何を優先して入れるかを設計する(情報が多ければよいわけではない)。
企業がコンテキストエンジニアリングを始める5つのステップ
コンテキストエンジニアリングは、一部の技術者だけの作業ではありません。次の順序で、組織として取り組むことが成果への近道です。ここでは営業部門でAIエージェントを活用する場面を例に、各ステップで実際に何が問われるのかを見ていきます。
1.AIに任せる業務と、必要なコンテキストを洗い出す
最初の一歩は、対象業務を1つに絞ることです。
たとえば「商談後のフォローメールの下書き作成」をAIに任せるなら、顧客の商談履歴、過去のやり取り、提案中の製品情報、料金や値引きのルールが必要になります。
「人間の担当者が同じ判断をするために、何を見ているか」を分解するのが要点です。ここで多いつまずきが、最初から全社データを対象にして、範囲が広がりすぎて頓挫するパターン。まず1つの業務で成功例を作ることが、遠回りに見えて近道です。
2.社内データを整理・構造化する
次に、その業務に必要なデータがAIに渡せる状態かを点検します。よくあるのは、商談メモに「値引きした」という結果は残っていても、「なぜそう判断したのか」が書かれていないケースです。これではAIは表面的な行動しか学べません。議事録、メール、PDFといった非構造化データを、AIが読み取れる形に整える作業がここで発生します。
3.サイロを越えてデータを統合する
営業やカスタマーサポート、マーケティングが別々のシステムでデータを持っていると、AIは同じ顧客を「別人」として認識してしまいます。1人の顧客が、AIから見ると3人にも5人にも分裂して見える状態です。
顧客を一意に特定できる形でデータを名寄せし、AIが横断的に参照できるようにすることで、はじめて「顧客を1人の人間として理解した」応答が可能になります。
4.システム指示とツールを設計する
AIの「作業環境」を組み立てる段階です。役割(あなたは既存顧客を担当する営業アシスタントです)、守るべき制約(提示できる値引きの範囲など)、そして使えるツール(在庫確認のAPI、見積書の作成機能など)を定義します。
ここが曖昧だと、AIは権限を越えた回答をしたり、必要な確認を飛ばしたりします。「何をしてよく、何をしてはいけないか」を明文化することが、安全な自動化の前提になります。
5.評価し、改善のループを回す
最後に、「出力の質」を継続的に評価します。AIの回答をサンプリングして人がレビューし、誤りがあれば「原因は指示にあるのか、渡した情報にあるのか」を切り分けます。
実務では、その多くが後者、コンテキストの不足や誤りに起因します。この検証と改善のサイクルを回し続けることが、精度を育てる唯一の方法です。
ここで全体の壁になりやすいのが、データの整備状況です。
「Salesforce State of Data and Analytics」レポートによると、企業データの80ー90%は非構造化データであり、データ分析責任者の70%が「最も価値ある洞察は非構造化データの中に眠っている」と回答しています。つまり、多くの企業にとって最も貴重な知識資産は、まだAIに渡せる形に整っていないのです。

【事例】Agentforceによる現場での実装
AIエージェントプラットフォーム「Agentforce」は、社内のデータやナレッジをAIが参照できる形で統合し、現場の業務を支援する仕組みを提供します。これは、コンテキストエンジニアリングの考え方を製品として実装したものと言えます。
たとえばアフラック生命保険は、Agentforceを社員・代理店募集人全員の「相棒」として提供する取り組みを進めています。
顧客ポータルやコンタクトセンターなど各領域のデータを「Data 360(旧Data Cloud)」で統合し、AIがリアルタイムに参照することで、経験の浅い担当者でも、ベテランに近い水準で顧客へ最適な提案ができる状態を目指しています。
部門ごとに分かれていた顧客データを、AIが扱えるコンテキストとして束ね直した取り組みです(出典:Salesforce 顧客事例 アフラック生命保険株式会社)
コンテキストエンジニアリングは「経営の課題」
コンテキストエンジニアリングは、一見すると技術者向けのテーマに見えます。しかしその本質は、「自社の知識・判断・経験を、AIが使える形でどれだけ整えているか」という問いにあります。
ここまで見てきた5つのステップのうち、データの統合や判断基準の言語化は、技術部門だけでは完結しません。組織のあり方そのものに関わる、経営課題なのです。
この視点をさらに掘り下げ、「コンテキスト負債」という新しい経営指標として論じた記事があります。AI時代に企業が向き合うべき本質的な準備度について、あわせてご覧ください。
【おさらい】よくある質問(FAQ)
Q. コンテキストエンジニアリングとプロンプトエンジニアリングの違いは?
A. プロンプトエンジニアリングは「AIへの問いかけ方」を磨く技能、コンテキストエンジニアリングは「AIに渡す情報環境の全体」を設計する仕組みづくりです。前者が個人の技能寄りなのに対し、後者は組織のデータ基盤に関わります。
Q. RAG(検索拡張生成)とは何が違う?
A. RAGは、AIが外部の文書やデータを検索して参照する技術で、コンテキストエンジニアリングを構成する重要な要素の一つです。コンテキストエンジニアリングは、RAGを含めて「何をどう渡すか」全体を設計する、より広い概念です。
Q. 企業は何から始めればよい?
A. まずはAIに任せたい業務を1つ選び、その判断に必要な社内情報が「AIに渡せる形」に整っているかを点検することから始めるのが現実的です。










