コンテキストエンジニアリングを対人コミュニケーションにあてはめてみる

はじめに

こんにちは、アジャイル開発チームの伊藤です。今日もたくさんのアドベントカレンダー記事が公開されている中、この記事を開いていただきありがとうございます。

この記事は、Insight Edge Advent Calendar 2025 16日目の記事です。

今回はコンテキストエンジニアリングについて、三つのことを語りたいと思います。

1つ目は「コンテキストエンジニアリングは対人コミュニケーションの場面に当てはめることができる」ということです。

あわせて「対人コミュニケーションをコンテキストエンジニアリングで考えると、相手に伝えるべき情報についての理解が深まる」という点について例とともに説明します。

そして最後に「コンテキストエンジニアリングはエンジニアに限らず全ての人に有用な汎用的スキルになるのではないか」という野望(?)に触れさせてください。

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

まずはコンテキストエンジニアリングについて、簡単に前提を合わせます。

コンテキストエンジニアリングとは、生成AIから望ましい回答を得られるように「コンテキストを設計する」ことで、2025年の6月頃に有名になった概念です。

どのようなものがコンテキストに当たるのかは様々な考え方がありますが、今回はGoogle DeepMindのPhilipp Schmid氏がブログで提示した内容をもとに話をしたいと思います。

Schmid氏によればコンテキストエンジニアリングには以下のような要素が含まれます。

要素	概要
システムプロンプト	生成AIの振る舞いを方向づけるためにあらかじめ提示してある指示やルール
ユーザプロンプト	直接のタスク指示や質問
短期メモリ	現在のセッションの中で行われた指示・回答の内容
長期メモリ	過去の会話で提示された知識や生成AI自身の回答、ユーザの好みなどの情報
取得した知識(RAG)	タスク実行や回答のために外部から取得して提示された情報
利用可能ツール	生成AIがアクセスできるツールの説明
出力形式	生成AIのアウトプットのフォーマットの指定

出典: Context Engineering - Philipp Schmid

生成AIに期待通りの動作・回答をしてもらうために、これらの要素からなる文脈（コンテキスト）を適切に設計する必要がある、というのがコンテキストエンジニアリングの主旨でした。

コンテキストの構成要素をどう分類するかはさまざまな意見があると思いますが、今回は例としてSchmid氏の提示した項目に沿って考えてみます。

コンテキストエンジニアリングを人間相手に拡張する

さて、ここからが本題です！

コンテキストエンジニアリングは「生成AIから望ましい回答を得るために、どのようにコンテキストを構築するか」を考えるものですが、この概念を拡張することで、生成AIに限らず人間を相手にする場合にも適用できないでしょうか。「相手から望ましいリアクションを得るために、どのように情報を提示するか」を考えるものとしてコンテキストエンジニアリングを一般化してみるのです。

人間を相手にする場合、コンテキストエンジニアリングの各要素は次のように読み替えることになるでしょう。

観点	対生成AI で考えること	対人間で考えること
システムプロンプト	生成AIに期待する役割や振る舞いをどう指示するか	相手に期待する役割や振る舞いをどう伝えるか
ユーザプロンプト	タスク指示や質問そのものをどう示すか	タスク依頼や質問そのものをどう伝えるか
短期メモリ	現在のセッションの中で出てきた質問・回答や指示の内容をどのように含めるか	現在の会話の中に出てきた質問・回答や依頼の内容をどのように考慮してもらうか
長期メモリ	過去のセッションで登場した知識や質問/回答、指示などの内容をどのように含めるか	過去のやりとりに出てきた知識や質問/回答、依頼事項などの内容をどのように考慮してもらうか
RAG	今回のタスク実施・回答のためのインプットとなる情報をどう取得して含めるか	今回の作業実施・回答のためのインプットとなる情報をどう集めてどう提示するか
利用可能ツール	生成AIがタスク実施・回答にあたって使用できる情報源やツールをどのように準備してどう提示するか	相手が作業実施・回答にあたって使用できる情報源やツールをどのように準備してどう提供するか
構造化出力	生成AIの作業結果・回答を受け取る際の形式をどう指示するか	相手の作業結果・回答を受け取る際の形式をどう伝えるか

相手が人間になったとしても意外とそのまま適用できそうですね。

いくつかの具体的なケースで、上記の観点を用いたコンテキストエンジニアリングをしてみましょう。

例1: 作業を依頼する場面

誰かに資料作成を依頼するケースで考えてみます。

生成AIを使う際に与える情報を設計するのと同じように、相手に伝えるべき情報を洗い出しましょう。

システムプロンプトの観点：

生成AIに対して役割や振る舞い方を指定するのと同じように、相手に担ってもらいたい役割や期待していることを前提として伝えると、認識の齟齬を避けられそうです。

例:「スライド作りが得意と聞いているので、分かりやすい資料を作成するために手伝ってもらえないでしょうか」

ユーザプロンプトの観点：

依頼したいことを明示するのがこの部分です。生成AI向けのプロンプトでは「以下の情報を使って」や「次の手順で」などの指示を記載していると思いますが、人間相手ではそれらを明確にするのを忘れがちです。生成AI向けだったらどう記述するだろう、とイメージしてみると自分が無意識に省略している点に気づけるかもしれません。

例:「売上の情報をお渡しするので、情報をまとめてスライドにして欲しいのです」

短期メモリの観点：

直近の会話をどう文脈に反映するかを考える観点です。今現在の会話はすべて相手に共有されている”文脈”であるわけですが、そこには依頼内容にとって重要なものとそうでないものが混ざっています。相手の認知負荷と認識齟齬を減らすために関連性の高い/重要なポイントをリマインドしてあげることにしましょう。生成AIの場合もセッション中の情報が多い場合には要点だけを取り出すコンパクションを行いますね。

例:「今お話したように、内訳の詳細な説明よりもこれまでの全体の推移がわかることが重要です」

長期メモリの観点：

その人との過去のやり取りの中で今回の文脈に含めるべき情報はあるでしょうか。過去のやり方と同じことをしてもらいたい、などが考えられますね。同じことを再検討してしまわないように入れておきましょう。

例:「前回、同様のお願いしたときと同じように、トピックごとにページ分けされているとありがたいです」

RAGの観点：

依頼と同時に渡すべき情報を準備して伝えましょう。次に出てくる「利用可能ツールの観点」と違い、こちらは情報を参照するか相手に選ばせるのでなく、必ず参照するものに注目した観点です。

例:「資料に反映する売上のデータはこちらになります」

利用可能ツールの観点：

相手が参照できる情報源・ツールは準備できているでしょうか。どんな時に使えるかも明示してあげましょう。また、適切なアクセス権が付与されている必要がありますね。

例:「他の指標のデータが必要であればこのフォルダの中を確認ください。」

出力方式の観点：

アウトプットの方法を伝えましょう。生成AIの場合は出力先などは限定されている場合が多いですが、人間の場合は形式とともに格納先や期限などもセットで考えると良さそうです。

例:「16:9のPowerPointファイルで、明日中に共有フォルダに格納いただけると助かります」

どうでしょうか。人間相手に依頼する場面でもコンテキストエンジニアリングの構成要素に分解して考えることで、伝えるべき情報を検討する足がかりになりそうです。

例2: 会議用プレゼンテーションの場面

仕事の中ではクライアントや上司にプレゼンテーションをする機会も多いと思います。次はそのようなシーンでのコンテキストエンジニアリングを考えてみましょう。

システムプロンプトの観点：

本題に入る前に、期待する役割を明確にしておきましょう。

例:「本日はセキュリティ責任者として判断をいただきたいと考えております」

ユーザプロンプトの観点：

依頼事項を明示しましょう。この部分がスライドのメッセージラインに対応する場合も多いかと思います。

例:「〜についての対応方針をご判断いただきたい」

短期メモリの観点：

このケースでの短期メモリとはどの範囲でしょうか。今回のミーティングの中のやりとりで、関連する部分を取り出してリマインドすると議論の迷走を抑える効果がありそうですね。

例:「前スライドで整理されたとおり、優先すべき事項は〜となっております」

長期メモリの観点：

過去の議事/会話の中で関連するものがあれば取り上げることを考えましょう。

例:「昨年はこのような観点から〜という方針で対応するということになりました。」

RAGの観点：

判断にあたって必要な情報を揃えておきます。生成AIの場合と同じく、どこまでを直接提示するのか/どこからを別途参照してもらうのか、の検討が必要でしょう。

例:「対応方針についての各担当者のコメントを集めてありますのでご説明します」

利用可能ツールの観点：

判断にあたって別途参照してもらえるものはなんでしょうか。その場で直接提示しない情報へのアクセス手段という意味では、ドキュメントやシステムのほかに有識者の紹介なども考えられます。（claude codeでも「ユーザに質問する」がツール化されていますね）

例:「不明点等ありましたら、私宛にチャットでご連絡ください」

出力方式の観点：

この観点は、回答の形式や期限について検討する部分となります。

例:「結果につきましては今週中にメールでいただければと思います」

「どの情報をどんな形で提示するのか」の選択はプレゼンテーションの成否に直結するポイントであり、これを長い（苦しい？）経験によって身につけてきた方も多くいらっしゃると思います。コンテキストエンジニアリングの枠組みは、それらのノウハウを整理・明文化する際の一つの切り口として使えるように思います。

もちろん、コンテキストエンジニアリングの構成要素や観点についてはまだ発展途上で、いわゆる抜け漏れのない（=MECEな）定義になっていないため、まだ整理のフレームワークとしては不完全です。

しかし「情報を要素ごと分けて、準備・提示の仕方を検討する」という考え方自体はプレゼンテーション技術の体系化に寄与する可能性を感じます。

例3: 子供に宿題を教える場面

次は方向を変えて子供の宿題を手伝っているシーンを考えてみます。

大人から見ると簡単な問題でも、なぜか子供は苦戦していることがあります。（ええ、うちの息子です）

学校の勉強の範疇では、問題を解くのに必要な情報はすでに示されているはずです。回答をするのに必要なコンテキストを整えてあげましょう。

システムプロンプトの観点：

宿題をするにあたり、回答者には何が期待されているのでしょうか。それを把握するだけでヒントになるかもしれません。

例:「息子よ、この宿題は今日授業で習ったことを思い出して使えるようにするためのものなのだ」

ユーザプロンプトの観点：

作業者には直近の指示が正確に伝わっているでしょうか。人間相手の場合はここが適切にコンテキストに反映されていないことがあります。（ええ、うちの息子です）

例：「息子よ、問題文をよく読むのだ。なんと書いてあるか」

短期メモリの観点：

直近の問いや解説で、関連するところ・重要なところを把握できているでしょうか。

例：「息子よ、例題ではどんな解き方を使っていたか」

長期メモリ：

過去の経験で関連することがあれば思い出させてあげましょう。

例：「息子よ、昨日の問題で間違えたところを覚えているか」

RAGの観点：

今使える情報として提示されているものを把握できているでしょうか。

例：「息子よ、使える公式は問題文の下に書いてあるぞ」

利用可能ツールの観点：

参照できる情報源・ツールは把握できているでしょうか

例：「息子よ、ヒントは教科書の10ページとのことだ。また、三角定規の使用も許可されているぞ」

出力方式の観点：

最後に見落としがちな点です。どのような形式で回答すべきなのか分かっているでしょうか。

例：「息子よ、途中式を書くことと、回答に単位をつけることを忘れてはならぬ」

相手のアウトプットやリアクションが自分の思っているものと異なる時、それは相手から見えている情報が足りていない・適切でないからかもしれません。（これは生成AIの場合も同じですね）

そんなときは、コンテキストエンジニアリングの考え方で認識のギャップを埋めることができそうです。

例4: 自分自身の作業準備をする場面

最後に、他人へのコミュニケーションだけでなく、自分自身に対するコンテキストエンジニアリングについて考えてみましょう。

自分が行うタスクで良いアウトプットを出すために、どのような情報を整えておくことができるでしょうか。

システムプロンプトの観点：

自分の役割や優先すべきことを意識できているでしょうか。生成AIと同じく、ここを明確にしておくことで、ブレない思考過程・安定したアウトプットにつながるはずです。

例：「今求められている役割はなんだっけ？・・・PoCをするために、実装速度重視のコーディングを求められている」

ユーザプロンプトの観点：

直近のやるべき作業は明確でしょうか。曖昧なタスク定義は余分な時間を費やすことにつながります。

やらないことを明確にすることも効果的でしょう。これも生成AI向けプロンプトでは明示するのに人間相手だと省略してしまいがちですね。

例：「今自分がやるべきことは？・・・・この機能を実装する。途中でリファクタリングはしない！」

短期メモリの観点：

直近で行った作業・思考で次のタスクに使うものを一度整理しましょう。

例：「直前までやっていたことで作業に関係するのは？・・・・直前に作った機能とパラメータを合わせる必要があるな」

長期メモリの観点：

過去の作業・経験で必要なものは整理できているでしょうか。必要に応じて過去の資料は作業記録などを見て作業コンテキストに取り込みましょう。

例：「過去にやってきた作業で今回も関係するのは？・・・・この特殊ケースへの対応を忘れない」

RAGの観点：

必要になる情報は手元に準備できているでしょうか。確実に必要となる情報はすぐに使えるところにないと集中を妨げることになります。

例：「作業開始するにあたって必ず使う情報は？・・・・対応すべきパラメータの一覧はこれ」

利用可能ツールの観点：

使える参照先とツールを確認・準備しておきましょう。ここに不足があると、本来の作業の途中に「ツールを整える作業」が割り込むことになります。（まさに「コンテクストスイッチング」による効率の低下です）

例：「情報元とツールは？・・・・このサイトとこのサイトをブックマーク、このツールをインストールしておく」

出力方式の観点：

アウトプットの形式や作業完了の条件は明確にできているでしょうか。ここをおろそかにすると、自分自身に対して作業のやり直しを指示するという残念なことが起こったりします。

例：「アウトプットはどのようにするんだっけ？・・・・メンバにデモできるところがゴール」

自分自身に対しても、作業の準備ができているかをコンテクストエンジニアリングの観点からチェックすることができました。

自分自身へのコンテキスト整備なので、新たな情報を与えるのではなく「分かっていることから今使う情報を絞る・ポイントを思い出す」というアプローチでコンテキストを組み立てることになりますね。

ここまでで示せたもの

ここまで4つの例で、コンテキストエンジニアリングという概念は、想定する範囲を拡張することで、生成AIだけでなく人間相手のコミュニケーションにも当てはめることができることを示しました。

また、対人コミュニケーションにコンテキストエンジニアリングの観点を持ち込むことによって、提示する情報というものを要素分解して理解・検討できることが分かりました。（個人的にも、これまで曖昧なイメージしか持っていなかった会話の「文脈」に対して具体的な観点を持てたことが大きな収穫でした。）

今後の展望

コンテキストエンジニアリングは発展途上のものなので、登場する各要素・観点もまだ綺麗に整理されているわけではありません。例えば長期メモリには過去に提示済みのRAGの内容やツール情報が含まれるはずです（これは記事の最初に引用したSchmid氏のベン図でも円の重なりや余白として現れています）。またSchmid氏以外にもコンテキストエンジニアリングについて述べたものは多数存在し、それぞれ構成要素の考え方が少しずつ異なります。

生成AIの可能性については日々新たな知見が公開されています。それに合わせてコンテキストエンジニアリングの領域でも、より良い理論が生まれ洗練されていくでしょう。コンテキストエンジニアリングが人間相手にも有効な考え方であるならば、その発展は同時に「人に対して提示する情報はどのように整理できるのか」というフレームワークのアップデートにも繋がるはずです。もちろん「生成AI向けにはこう、人間相手にはこう整理したほうがよい」といった分岐が発生する可能性はありますが、生成AI相手の知見と人間相手の知見はお互いに影響を与えながら成熟していくでしょう。

対人間の場面に適用できるものとして十分に成熟したコンテキストエンジニアリングは、使う人により良いコミュニケーションを可能にするツールとなるはずです。その時にコンテキストエンジニアリングはもはやエンジニアのためのハードスキルではなくなり、すべての人に身につけることが推奨される一般教養/ソフトスキルとして社会に定着するのではないかと考えています。

まとめ

本記事では、実際のシーンの例を入れつつ、以下を説明しました。

コンテキストエンジニアリングを「相手から望むリアクションを引き出すために、情報の準備・提示の仕方を考えること」として一般化することで、対人コミュニケーションにも当てはめることができました
コンテキストエンジニアリングによって考慮すべき要素・観点が示されることで、人間相手のコミュニケーションや内省に際に必要な情報について理解する際のフレームワークとなる可能性を持っています
コンテキストエンジニアリングは発展途上ですが、将来的に要素・観点が洗練されることで、エンジニアに限らずすべての人が身につけるべきスキルとなると考えています

生成AI関連スキルという枠を超えた、コンテキストエンジニアリングの可能性に注目していただければと思います。