AIを“使いこなす組織”が実践する『コンテキストエンジニアリング』とは？

こんにちは、ワークスアイディの奥西です。

最近、エンジニアの世界で『バイブコーディング（Vibe Coding）』という言葉が非常に話題になっていますね。自然言語で意図を伝えるだけで、AIがコードを書いてくれる時代。AIの進化に伴い、プログラミングに求められるスキルは変化し、実装の細部を知らなくてもシステムが動くようになりました。

これからのITエンジニアは、『コードを書く能力』から『AIと協働する能力』が求められます。
とはいえ、組織でAIを実装していくには大きな落とし穴があります。どれだけAIの能力が高く学習が速くても、“会社のことを何も知らない”という点です。

本日は、その問いから『コンテキストエンジニアリング』について、一緒に考えていきましょう。

コンテキストエンジニアリングとは？

コンテキストエンジニアリングとは、LLM（大規模言語モデル）がタスクを合理的に解決できるよう、必要な文脈情報(コンテキスト)を設計・提供する技術のことです。

AIの活用が単なる「チャット」から「自律的な問題解決」へと進化する中、その精度を左右する鍵として、いま最も注目を集めているのがこの領域です。

2025年は『AIエージェント元年』とも呼ばれ、AIが主体的にタスクをこなす時代となりました。
バイブコーディング（Vibe Coding）の台頭が象徴するように、AIとの協働において求められるスキルは、プロンプトの“書き方”という表面的なテクニックから、AIに“どのような情報環境を与えるか”という設計的アプローチへと大きくシフトしています。

では、これまで馴染みの深かった『プロンプトエンジニアリング』と何が違うのか、その境界線を整理してみましょう。

端的に言うなら、プロンプトエンジニアリングが“何を聞くか”の設計なら、コンテキストエンジニアリングは“何を見せて考えさせるか”の設計です。

ではなぜ、コンテキストエンジニアリングが必要なのか？
その理由は、人と同じくAIも“文脈”がなければ動けないからです。

外部の優秀なコンサルタントに仕事を依頼するとき、その人の能力だけで結果が決まるわけではありませんよね。会社の事情、顧客の背景、過去の経緯、暗黙のルールなどを丁寧に共有するほど、アウトプットの質は上がります。
AIも同じということです。

コンテキストを構成する5つの要素

AIエージェントのコンテキストは、主に次の5つで構成されます。

（1）プロンプト：人格設定・振る舞い

AI自身が何者として振る舞い、何を優先し何を避けるか？出力はどのフォーマットで返すか？などを定義します。

重要ですが、全体の一要素に過ぎません。

（2）RAG（検索拡張生成）と外部知識

会社固有の知識を持たせる仕組み。

製品仕様書、社内規程、過去の提案書、顧客対応履歴などを構造化し、AIが質問と関連する箇所だけを動的に取得できる状態にします。

“必要なときに必要な情報だけが差し込まれる”設計がポイントですね。

（3）会話履歴の管理

会話が長くなると、コンテキストウィンドウ（AIの記憶容量）は埋まってしまいます。

何を残し、要約し、捨てるかの設計が不可欠。怠ると直前の発言すら参照できなくなります。

（4）ツール定義（MCP・API連携）

AIエージェントが“行動できる範囲”を決める。

MCPは外部ツールやデータソースへリアルタイムにアクセスするための標準プロトコルです。社内データベースへの問い合わせやカレンダーを確認して会議設定するなど、行動の可否は設計次第です。

『MCP』については、別のコラムで解説していますのでぜひご覧ください。

「MCP」がAIの共通言語を変える？分かりやすい解説と活用イメージ
MCPはAIとシステムをつなぐ共通規格。営業・バックオフィス・経営管理の自動化事例とMicrosoft展開を交えて実装の勘所を解説。
 

（5）ワーキングメモリ

複雑なマルチステップ処理に必須の概念。

「今何ステップ目か」「前工程の結果は何か」「未解決の課題は何か」などの進捗情報を保持し、エージェントが長い処理の途中で迷子にならないようにします。

なぜ企業でコンテキスト設計が難しいのか？

5要素を理解すると、企業でのコンテキスト設計の難しさが見えてきます。

最大の障壁 … 暗黙知の言語化

ベテランの頭の中にある判断基準、例外処理、顧客ごとの対応の機微は、チャットや社内Wikiのどこにも書かれていません。RAGに与える文書を作ろうとしても「そもそも書いていない」という壁にぶつかります。

あるメーカー様で、審査業務のAI化を検討した際「審査基準を言語化しましょう」とお願いしたところ、「担当者に聞かないとわからない」という答えが返ってきました。20年選手の暗黙知をAIエージェントに渡すには、まず言語化が必要になります。

これは技術ではなく、組織の問題ですね。

第二の障壁 … 情報の鮮度と形式の多様性

Word、PowerPoint、Excel、メール、チャット、紙など、日本企業のナレッジは形式も散在先も多様。RAGに活用できる形（構造化されたテキスト）への変換コストが現場の足枷になりがちです。

また、製品仕様が更新されてもAIに渡している文書は半年前のまま…といった状況を放置すると、AIが古い情報を自信満々に回答するというケースが発生してしまいます。

コンテキスト設計は“作って終わり”ではなく、継続的な更新サイクルが不可欠です。

まとめ

AIが「使える」と「使えない」の差は、AIそのものの能力差ではありません。AIに“何を見せて、何を考えさせるか”――つまりコンテキスト設計の差です。

どれほど高性能なモデルでも、渡す情報や経緯が曖昧であれば、アウトプットも曖昧になります。そして、コンテキスト設計の本質的な難しさは、技術ではなく組織の知を言語化することです。

「AIに何を聞くか」ではなく、これからは「AIに何を渡すか」。
コンテキストエンジニアリングは、AIを単なるツールから“組織の知的資産を活用する仕組み”へと進化させる取り組みですね。

ぜひ、皆さまの会社でも『コンテキストエンジニアリング』について議論してみてください。

それでは、本日もGOOD JOB！！

▼こちらもおすすめ

RPAとAIエージェントの違いとは？ – 非定型業務までも自動化する次のステージへ –
RPAとAIエージェントの違いを実務目線で整理。AI導入を成功させるステップと、人とAIの協働で生まれる新しい働き方を解説します。
 

今注目の「AIエージェント」とは？生成AIの次に来る“共創”の時代
AIエージェントに任せる仕事が増える時代だからこそ、「何を任せ、何を考えるか」が問われています。