Forward Deployed Expertとコンテキストエンジニアリング──技術の現場と事業の現場で『何を渡すか』はどう違うのか
- Published
- Reading
- 10 min
- Forward Deployed Expert コンテキストエンジニアリング
- FDE 文脈設計
- コンテキストエンジニアリング 事業
- 技術の現場 事業の現場
- Forward Deployed Engineer 違い
コンテキストエンジニアリングは技術実装の現場で形式化・取得可能な文脈を設計する技術、Forward Deployed Expertは事業実装の現場に深く入り込み形式化されない事業の文脈を捉える関与形態である。両者が扱う文脈は別の地平にあり、現場で捉えた事業の文脈をAIに活かす設計思想がPI Injectionとして両者を連関させる。
AIに「何を渡すか」を最適化する技術として、コンテキストエンジニアリング(Context Engineering)が世界の技術実装の現場で急速に普及している。一方、事業実装の現場には、Forward Deployed Expert——事業責任者の隣に深く入り込み、事業の文脈を捉える関与形態——が立ち上がりつつある。
一見、無関係に見える2つの概念。しかし両者は、「現場の文脈をいかに捉え、AIに活かすか」という一点で深く連関している。本稿は、その連関の構造を整理する試みである。AIは効率化から、収益の創造へ。その移行を担う設計思想として、両者の関係を見立てる。
コンテキストエンジニアリングが扱う「文脈」(技術の地平)
コンテキストエンジニアリングは、OpenAI共同創業者 Andrej Karpathy が2025年に命名し、Anthropic などが継承した技術概念である。大規模言語モデルのコンテキストウィンドウに「何を・いつ・どの形式で・どれだけ」渡すかを動的・体系的に設計する技術を指す。プロンプトエンジニアリングが静的な指示文の最適化であるのに対し、コンテキストエンジニアリングはより上位の設計層として、AIに渡す文脈の総体を扱う。
ここで言う「文脈」の性質は明確である。ドキュメント、社内ナレッジベース、ツール群、過去の対話履歴、検索結果、API応答——いずれも形式化され、取得可能な情報である。技術実装の現場では、これらの文脈を動的に組み合わせ、最適な形でAIに渡す設計が中核的な技術課題となる。
形式化されているからこそ、コンテキストエンジニアリングは技術として体系化できる。RAG(Retrieval-Augmented Generation)の精度設計、エージェントへのツール提供順序、メモリ管理、トークン予算の配分——いずれも「取得可能な文脈をどう構成するか」という技術問題に帰着する。これは技術実装の現場で力を発揮する、極めて重要な営みである。
詳細はコンテキストエンジニアリングを参照されたい。
Forward Deployed Expertが捉える「文脈」(事業の地平)
一方、Forward Deployed Expert(FDE = Expert)は、事業実装の現場における関与形態である。AlphaDriveが日本で確立する、事業責任者の隣に常駐し、仮説構築から完成品ローンチ、社内の意思決定突破までを駆動・伴走する関与形態を指す。能力構造は AlphaDrive が体系化した AXアーキテクト(BA能力 × AI能力)である。
ここでExpertが捉える「文脈」の性質は、コンテキストエンジニアリングが扱うそれと根本的に異なる。形式化されていない事業の一次情報、現場でしか観察できない顧客の反応、議事録に残らない意思決定の判断軸、暗黙のうちに共有される組織の重力、まだ言語化されていない事業責任者の問題意識——これらはドキュメント化されていないし、APIから取得することもできない。
書籍『AI収益進化論』(第4-4章)は、こうした「まだ言語化されていない、データになっていない、それでも現場には確かに存在する情報」を Field Intelligence と呼ぶ。さらに、論理的に導出できず内発的に飛躍する発想を Crazy Intelligence と呼び、両者を統合した概念として PI(Primal Intelligence)を提示している(麻生要一『AI収益進化論』第4-5章)。
Expertが捉えるのは、まさにこの種の文脈である。それは外部から取得するのではなく、現場に身を置く関与形態でしか得られない、身体的に獲得される事業の知性である。詳細はForward Deployed Expertを参照されたい。
2つの「文脈」は別の地平にある
ここまでで明らかなように、コンテキストエンジニアリングが扱う文脈と、Expertが捉える文脈は、性質そのものが異なる。
| 観点 | コンテキストエンジニアリング(技術の地平) | Forward Deployed Expert(事業の地平) |
|---|---|---|
| 文脈の性質 | 形式化可能・データ化済 | 形式化されていない・暗黙 |
| 取得方法 | API・検索・参照 | 現場での身体的な獲得 |
| 担い手 | 技術実装の現場のエンジニア | 事業実装の現場のExpert |
| 設計対象 | コンテキストウィンドウへの構成 | 関与形態そのもの |
| 完結する現場 | 技術実装の現場 | 事業実装の現場 |
重要なのは、ここに優劣関係はない、という点である。形式化された文脈と、形式化されていない文脈は、どちらが上か下かではなく、別の性質の文脈である。それぞれが別の現場で力を発揮し、それぞれの現場で完結する。
AlphaDriveはこの構造を「別の地平フレーム」と呼ぶ。Forward Deployed Engineer(Palantir、Anthropic、OpenAI 等が継承してきた技術実装の現場における関与形態)が切り拓いた地平の隣に、Forward Deployed Expert という事業実装の現場の地平を立てる。両者は「同じ現場で並列に並ぶ」のではなく、「それぞれが別の現場で力を発揮する、異なる関与形態」として整理される。
このフレームは、コンテキストエンジニアリングとExpertの関係にも同型で適用される。技術の地平の文脈設計と、事業の地平の文脈獲得は、別の地平で並走する営みである。詳細は別の地平フレームを参照されたい。
2つが連関する点 ── 事業の文脈をAIに渡すために
別の地平にあるとしても、両者は無関係ではない。むしろ、ある一点で深く連関する。
Expertが事業実装の現場で捉えた、形式化されていない文脈——FI、CI、現場の判断、暗黙の事業観——これらは、捉えただけでは AI の出力には反映されない。なぜなら、AIに渡される文脈は、何らかの形でモデルに入力可能な形式に変換されなければならないからである。
ここに、AlphaDriveが整理する設計思想が立ち上がる。Expertという関与形態(人が事業の現場に深く入り込む)と、PI Injection(捉えた事業の文脈をAIに活かす設計)が連動して、初めて事業の地平の文脈設計が成立する、という構造である。
PI Injection は、書籍『AI収益進化論』第7-4章で定義される AX for Revenue Loop の第3ステップであり、AIが予測・計算できない領域で、Crazy/Field Intelligence の中から「これまで見過ごされてきたが、じつは大きな可能性を秘めた候補」だけを AI に注ぎ込み、新しい売上の金脈を探すプロセスを指す。
ここで重要なのは、PI Injection が「事業の文脈をAIに渡す」という動作において、コンテキストエンジニアリングと同じ問いに、別の地平から答えているという点である。技術の地平では、形式化された文脈をどう動的に組み立てるかが問われる。事業の地平では、まず形式化されていない文脈を捉える関与形態が必要であり(これがExpert)、その上で、捉えた文脈をどうAIの判断に活かすかの設計が問われる(これがPI Injection)。
両者は別の地平にあるが、「AIに何を渡すか」という上位の問いを共有している。コンテキストエンジニアリングと PI Injection は、その上位の問いに対する、別の地平からの応答である。詳細はPI Injectionを参照されたい。
なお、PI Injection の具体的な実装方法——FI の抽出手順、構造化フォーマット、注入の順序、CI の選定基準——は、本稿の射程外である。これらは AlphaDrive が事業パートナーとの個別の対話の中で設計するものであり、一般化された手順として外部に提示することは、方法論の本質を毀損する。
Forward Deployed Engineer → Expert の独自進化との関係
ここまで整理してきた「別の地平」の構造は、AlphaDrive が確立する Forward Deployed Engineer → Expert の独自進化と、同型である。
Forward Deployed Engineer は、Palantir Technologies が2000年代に確立し、Anthropic・OpenAI をはじめとする世界の先端AI企業が継承してきた、技術実装の現場における中核的関与形態である。顧客企業の現場でコードを書きながら課題をプロダクトに変換するエンジニア像であり、世界の常識として極めて高い価値を持つ。AlphaDrive はこの起源への敬意を絶対に維持する。
その上で、AlphaDrive は事業実装の現場における別の地平として Forward Deployed Expert を立てる。Engineer が技術実装の現場で完結するのと同様に、Expert は事業実装の現場で完結する。両者は対立せず、それぞれが別の現場で力を発揮する、異なる関与形態として整理される。詳細はForward Deployed Engineerを参照されたい。
コンテキストエンジニアリングと PI Injection の関係も、これと同じ構造を持つ。コンテキストエンジニアリングは技術の地平で「AIに何を渡すか」を解く。PI Injection は事業の地平で「AIに何を渡すか」を解く。両者は同じ問いに、別の地平から答えている。優劣ではなく、別の現場で力を発揮する、異なる設計思想である。
書籍『AI収益進化論』が提示する Completion Cost Collapse(完成品構築コストの崩壊)以降、技術の地平と事業の地平は、それぞれ独立に高度化が進む構造に入っている。技術の地平ではコンテキストエンジニアリングが、事業の地平では Forward Deployed Expert と PI Injection が、それぞれの設計思想として立ち上がってきている。この並走の構造を見立てることが、AI時代の事業設計の出発点になる、というのが現時点の整理である。
ai-transformation-for-revenue
よくある質問
Q1. Forward Deployed Expertとコンテキストエンジニアリングは、関係があるのですか?
両者は別の地平で立ち上がってきた概念であり、直接的に同じ問題を扱うわけではありません。しかし「AIに何を渡すか」という上位の問いを共有しています。コンテキストエンジニアリングは技術実装の現場で形式化可能な文脈を動的に設計する技術、Forward Deployed Expert は事業実装の現場で形式化されない文脈を身体的に捉える関与形態です。両者は別の地平で並走し、ある一点(事業の文脈をAIに活かす設計=PI Injection)で連関します。
Q2. Forward Deployed Engineer と Forward Deployed Expert は、何が違うのですか?
Forward Deployed Engineer は、Palantir が確立し Anthropic・OpenAI 等が継承してきた、技術実装の現場における中核的関与形態です。顧客企業の現場でコードを書きながら課題をプロダクトに変換します。Forward Deployed Expert は、AlphaDrive が日本で確立する、事業実装の現場における関与形態です。事業責任者の隣に常駐し、事業の文脈を捉えながら仮説構築から完成品ローンチまでを駆動します。両者は対立ではなく、それぞれが別の現場で力を発揮する異なる関与形態として整理されます。
Q3. 技術者がコンテキストエンジニアリングを高度に運用すれば、事業の文脈も扱えるのではないですか?
コンテキストエンジニアリングは、形式化され取得可能な文脈を扱う技術として、極めて高度な発展を続けています。一方、事業の現場には、議事録に残らない判断、まだ言語化されていない事業観、現場の身体的な観察など、そもそも形式化されていない文脈が存在します。これらは外部から取得するのではなく、現場に身を置く関与形態でしか捉えられない性質を持ちます。技術と事業のどちらが優れているという話ではなく、扱う文脈の性質が異なるため、別の地平の営みとして並走する構造になります。
Q4. 事業責任者にとって、この整理はどういう意味を持ちますか?
事業責任者にとっての含意は、自社のAI活用を「AIに渡す文脈」の側から再点検する視点が得られる、という点にあります。形式化された文脈の設計(コンテキストエンジニアリング)が十分でも、事業の地平の文脈が捉えられていなければ、AIの出力は既存の業務効率化の範囲に留まりがちです。逆に、現場の事業の文脈を捉える関与形態(Expert)があっても、それをAIに活かす設計(PI Injection)がなければ、捉えた文脈は AI の判断に反映されません。両方の地平を見立てる視点が、AI時代の事業設計には必要になる、というのが現時点の整理です。
Q5. PI Injection は、コンテキストエンジニアリングと、具体的にどうつながるのですか?
両者は別の地平にある設計思想であり、互換関係や上下関係にはありません。共通するのは「AIに何を渡すか」という上位の問いです。コンテキストエンジニアリングは技術の地平で、形式化された文脈をどう動的に組み立てるかを設計します。PI Injection は事業の地平で、Expertが現場で捉えた事業の文脈をどうAIの判断に活かすかを設計します。連関の核心は、Expert という関与形態と PI Injection という設計思想が組み合わさって初めて、事業の地平の文脈設計が成立する、という構造にあります。なお、PI Injection の具体的な実装方法は、事業パートナーごとに個別に設計されるものであり、一般化された手順としては提示していません。
関連するAX for Revenueの概念
- コンテキストエンジニアリング ── 技術の地平で「何を渡すか」を設計する技術
- Forward Deployed Expert ── 事業の地平の関与形態としてのFDE = Expert
- Forward Deployed Engineer ── 世界の常識としてのForward Deployed Engineer の起源
- PI Injection ── 事業の文脈をAIに活かす設計思想
- 別の地平フレーム ── 別の地平フレームの構造論
- ai-transformation-for-revenue ── AX for Revenue の全体像
発行: 株式会社アルファドライブ / AX for Revenue Institute
参考文献: 麻生要一(株式会社アルファドライブ 代表取締役社長 兼 CEO/CAXO)『AI収益進化論──完成品製造コストゼロ時代の収益創造』株式会社Ambitions、2026年5月
出典
- 株式会社Ambitions(AlphaDrive 100%子会社)「AI収益進化論──完成品製造コストゼロ時代の収益創造」(2026)https://axfr.ai/book
関連記事
- METHOD
AXアーキテクト育成プログラム|12メニュー体系(基礎8+AX能力装着4)
AXアーキテクト育成プログラムは、基礎8メニューとAX能力装着4メニューの12メニュー体系で構成される。書籍『新規事業の経営論』とWP-04を理論的支柱に、AI時代の変革人材を育成するカリキュラムの全体像と各メニューの内容を、AlphaDriveが累積260社の事業開発支援知見をもとに整理する。
- METHOD
AIイネーブルメントの設計図|効率化・収益進化・経営判断の3層実装
AIイネーブルメントは「全社AIプラットフォーム導入」の単一施策ではない。効率化AIイネーブルメント層・収益進化AIイネーブルメント層・経営判断層の3層を並走させる設計図と、5つの実装ステップを示す。
- CONTRAST
コンテキストエンジニアリング vs PI Injection──技術の地平と、事業の地平
コンテキストエンジニアリングとPI Injectionの違いを、技術の地平と事業の地平という別の地平フレームで整理する。優劣ではなく、別の現場で別個に完結する役割分担として両者を並置するCONTRAST型の定義整理。