コンテキストエンジニアリングとは？FDEが現場で使う設計手順と実践法

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

コンテキストエンジニアリングとは、LLMが次の一手を正しく判断できるように、渡す情報全体を設計・管理する技術です。

生成AIを業務で使うと、「同じモデルなのに、ある現場ではうまく動き、別の現場では使えない」という差がよく出ます。この差を生むのは、モデルの性能よりも「モデルに何を見せているか」であることが多いです。コンテキストエンジニアリングは、この「見せ方」を属人的なコツで終わらせず、設計の対象として扱うための考え方です。

定義と言葉が広まった経緯

2025年半ばにAndrej Karpathy氏らの発信で広まった、文脈全体を設計の対象にする考え方です。

元OpenAIのAndrej Karpathy氏は2025年6月、X上で「prompt engineering」より「context engineering」という言葉を支持すると投稿しました。その中で、次のステップに必要な情報だけをコンテキストウィンドウにちょうどよく詰める「繊細な技術であり科学」だと説明しています。同じ時期にShopify CEOのTobi Lütke氏も同じ趣旨の発信をしており、言葉が一気に広まりました。

その後、Anthropicは2025年9月に技術ブログ「Effective context engineering for AI agents」を公開しました。この記事では、コンテキストを「有限の資源」として扱い、望む振る舞いを引き出せる最小限で密度の高い情報を選ぶことが重要だと整理しています。

なぜ今FDEにとって重要なのか

AIエージェントの業務導入が進み、精度の差がモデルの性能より「何を渡すか」で決まる場面が増えたためです。

FDE（Forward Deployed Engineer）は顧客の現場に入り込み、プロダクトを顧客の業務に合わせて動く状態にする職種です。Palantirで確立されたこの働き方では、汎用的な製品と個別の業務のあいだを埋めることが中心的な価値になります。生成AIの時代では、このあいだを埋める作業の多くがコンテキストの設計そのものになります。顧客固有の用語、例外ルール、社内システムの仕様といった「暗黙知」をAIが扱える形にすることは、FDEの職務と強く重なります。

プロンプトエンジニアリングとの違いは？

プロンプトエンジニアリングは指示文の工夫、コンテキストエンジニアリングは指示を含む情報環境全体の設計です。

違いは設計の「単位」にあります。プロンプトエンジニアリングは、1回の入力文をどう書くかに注目します。一方、コンテキストエンジニアリングは、複数のステップをまたいで、何をいつ、どの形でモデルに渡すかという仕組み全体を扱います。

対象範囲と時間軸の違い

プロンプトは一回の入力文が対象ですが、コンテキストはエージェントが動くあいだ続く情報の流れ全体が対象です。

プロンプトの工夫が無駄になるわけではない

指示文の書き方は今もコンテキストの重要な一部です。上位の概念に含まれたと捉えるのが実務的です。

「プロンプトエンジニアリングは終わった」という言い方を見かけることがありますが、現場の感覚としては言い過ぎでしょう。システム指示の明確さや具体例の選び方は、今でも出力の質を大きく左右します。変わったのは、指示文だけを磨いても限界があり、周辺の情報設計と組み合わせて初めて安定するという認識が広がったことです。

コンテキストエンジニアリングの構成要素は？

主な構成要素は、システム指示・知識・ツール・記憶・会話履歴・出力形式の6つに整理できます。

分け方は論者によって少しずつ異なります。ここでは、FDEが顧客環境で設計を分担・点検しやすい粒度で6つに分けています。

6つの要素と役割

各要素は役割が異なるため、要素ごとに「何を入れ、何を入れないか」を決めることが設計の出発点になります。

ツール接続については、Anthropicが2024年11月に公開したModel Context Protocol（MCP）のように、外部データやツールをLLMにつなぐための標準仕様も広がっています。接続の方式がそろうことで、FDEは「つなぎ方」より「何をつなぐべきか」の判断に時間を使えるようになります。

「足す」より「絞る」が効く理由

コンテキストは有限の資源です。情報を詰め込みすぎると重要な指示が埋もれ、精度が落ちやすくなります。

2023年に発表された論文「Lost in the Middle」（Liuら）は、長いコンテキストの中ほどに置かれた情報をLLMが活用しにくい傾向を報告しました。Anthropicの前述のブログも、トークンが増えるほど情報を正確に思い出しにくくなる現象に触れ、注意を向けられる量には限りがあるという前提に立っています。

現場では「念のため全部入れておこう」という判断になりがちですが、実務ではそれが逆効果になる場面をよく見ます。次の3つは、まず試す価値のある手法です。

1. 選別：そのステップの判断に使わない情報は渡さない
2. 圧縮：長い履歴や文書は要約し、要点だけを残す
3. 遅延取得：最初から全部を渡さず、必要になった時点でツール経由で取りに行かせる

FDEは顧客現場でどう実装するのか？

FDEは顧客の業務を観察して判断に必要な情報を洗い出し、小さく作って現場で検証する作業を繰り返して実装します。

机の上で設計を完成させてから持ち込むより、現場の担当者の隣で動かしながら直すほうが、結果的に早く精度が上がることが多いです。FDEという職種が「現場に常駐すること」を重視する理由は、ここにもあります。

現場で使う5ステップの設計手順

業務の判断ポイントを特定し、必要な情報を洗い出し、実装・評価・運用の順に進めるのが基本形です。

特に効くのはステップ1と2です。担当者に「何を見て判断していますか」と聞いても、暗黙知は言葉になりにくいものです。実際の作業画面を一緒に見て、参照している画面や資料を一つずつ確かめると、AIに渡すべき情報の候補が見えてきます。

Palantir AIPに見るオントロジーという発想

Palantirは業務データをオントロジーとして構造化し、AIに渡す文脈の土台にする設計を採っています。

Palantirは2023年にAIP（Artificial Intelligence Platform）を発表しました。その中核にあるのが「Ontology（オントロジー）」です。Ontologyは、顧客企業のデータを「設備」「受注」「出荷」といった業務上のオブジェクトと、それらの関係・実行できるアクションとして表現します。LLMは、ばらばらの生データではなく、業務の意味が付いた構造を通じて情報を参照・操作します。

この発想はPalantir製品を使わない場合にも参考になります。「どの表のどの列か」ではなく「業務上の何についての情報か」でコンテキストを組み立てると、AIの判断が業務の言葉と一致しやすくなります。FDEが現場で最初に作るべきものは、プロンプトより先に、この業務の語彙と構造の整理なのかもしれません。

現場でつまずきやすいポイント

失敗の多くは、モデルの能力不足ではなく、情報の鮮度・権限・用語のずれから生まれます。

コンテキストエンジニアリングを身につけるには？

まず自分の業務で小さなエージェントを作り、評価と改善を回す経験を積むのが最短ルートです。

コンテキストエンジニアリングは、知識として読むだけでは身につきにくい技術です。情報を減らしたら精度が上がった、要約したら重要な条件が消えた、といった体験を自分の手で重ねることで、判断の勘所が育ちます。

段階別の学習ロードマップ

指示文の設計から始め、検索・ツール連携を経て、最後に評価と運用設計まで広げる3段階が目安です。

一次情報としては、Anthropicの技術ブログやドキュメント、各LLMベンダーのエージェント構築ガイドが有用です。用語や推奨手法の更新が速い分野なので、二次情報だけでなく発信元の資料に当たる習慣をつけておくと安心です。

評価（Evals）を習慣にする

改善できたかどうかは感覚ではなく評価セットで判断します。変更のたびに同じ問いで比較する習慣が重要です。

コンテキストを少し変えただけで、別のケースの挙動が変わることは珍しくありません。実務の評価セットは最初から大規模である必要はなく、実際の案件から典型的なケースと失敗しやすいケースを集めた小さなセットでも十分に役立ちます。顧客の担当者に採点基準づくりに加わってもらうと、「何をもって正しいとするか」の認識合わせにもなります。

企業側が身につけた人材を見極める観点

FDEの採用・育成を検討する企業は、情報設計の判断理由を説明できるかどうかを確認すると見極めやすくなります。

「どのプロンプトを書いたか」より、「なぜその情報を渡し、なぜ別の情報を外したか」「どう評価して改善したか」を説明できるかどうかが、現場で通用するかの目安になると考えられます。FDE導入を検討する意思決定者にとっては、面談でこの説明を求めること自体が、コンテキストエンジニアリングの実力を測る現実的な方法の一つでしょう。

姉妹メディアの関連記事