FDE(フォワードデプロイドエンジニア)は何を使うのか？ オントロジー優先のオープンスタック
FDE が 60–180 日のデプロイメントで実際に何を作るのか、この仕事を定義する 5 つの痛み、そして 2026 年の模倣の波がなぜ職種だけを写し取り、その下の基盤を写さなかったのか。
要約： フォワードデプロイドエンジニアリング(FDE)はエンタープライズ AI で最も成長している職種です — 求人票は前年比 1,165% 増(Live Data Technologies の集計を、採用マーケットプレイスの Paraform が伝えたもの)。そして 2026 年、OpenAI、Anthropic、AWS、Microsoft がそれぞれ自前のフォワードデプロイド組織を立ち上げました。全員が写しているプレイブックは Palantir のオントロジー優先メソッドです。本稿が扱うのは、採用系のコンテンツが決して書かない 2 つのこと：FDE が 60–180 日のデプロイメントで実際に何を作るのか、そして模倣の波がなぜ職種だけを写し取り、その下の基盤を写さなかったのか。その間に、手作りスタックでこの仕事をするときに繰り返し現れる 5 つの痛み — 配管がエンゲージメントを食い潰す、デモがセキュリティレビューで死ぬ、要件がコードより速く変わる、パターンが顧客をまたいで複利にならない、引き継ぎが関係を毒す — と、オープンなオントロジー優先スタックがそれぞれをどう取り除くかを置きます。最後に、この職種の次の波を定義すると私たちが考える問い — オントロジーの引き継ぎ。顧客のオントロジーは顧客自身のリポジトリの型付きオープンファイルとして残るのか、それとも他人のプラットフォームの更新交渉カードになるのか？
誰も正直に説明しないこの仕事
求人票が語るのは「0→1 の曖昧さ」と $300K–$550K の報酬帯です(Perspective AI、TechTarget)。実際の仕事は、他人の壁の内側で AI を動かすことです：相手のデータ、相手の権限、相手のコンプライアンス部門、相手の「十分」の定義。Palantir は何年も前にメソッドを制度化しました：AI FDE は LLM アプリを出す前に顧客専用オントロジーを先行構築し、週の 30–40% をディスカバリーに使う(Palantir AI FDE ガイド)。メソッドは正しい。1 週間が実際に消えていくのは、その下の道具立てです。
FDE が実際に作っているもの
デプロイメントはおよそ 60–180 日走り、引き継ぎまでに 4 つの成果物を、決まった順序で生みます — それぞれが次の入力になるからです。ここが、求人票が決して描かない部分です：
| デプロイ日 | 実際に書かれるもの | 完了の判定 |
|---|---|---|
| 0–15 · 取り込みアダプタ | ソースシステムごとに 1 つのアダプタ — 相手の ERP、相手のチケットツール、そして実は真の source of truth であるスプレッドシート。まず読み取り経路：移行せず、つなぐ。 | 画面上のビジネスオブジェクトが、今朝相手のシステムから出てきた実データの行を表示する。 |
| 15–45 · エンティティ解決 | 誰もデモしない、地味なほうの半分。「顧客」は 4 つのシステムで 4 つの別々のキーです：マッチルール、サバイバーシップルール、そしてオントロジーが正規と見なす識別子を書きます。 | 同一企業の 2 レコードが統合され、顧客の運用責任者も「統合されるべきだ」と同意する。 |
| 30–60 · 権限マッピング | 相手の組織図を、ロール・権限セット・行レベル共有・項目レベルのルールへ翻訳する。3 人しか見てはいけない項目も含めて。 | セキュリティレビューが会議ではなくファイルの読み合わせになる：レビュアーが「誰が何を見られるか」を指させる。 |
| 45–90 · 最初のワークフロー | エンドツーエンドの業務を 2〜3 本 — 承認チェーン、トリアージキュー、更新手続き — と、その周りのアクション・ビュー・通知。 | あなたの会社の人間ではない誰かが、そのアプリで実際の 1 日分の仕事を終える。 |
| 90–180 · 引き継ぎ | シードデータ、受け入れ用フィクスチャ、翻訳ラベル、パッケージ済みアプリ、そして相手のチームが本当に回せるレビューチェックリスト。 | 相手のエンジニアが、あなたに電話せずに変更をリリースする。 |
最初の 4 行に共通するものに注目してください：どれも通常の意味でのアプリケーションコードではありません。それらは定義です — 何が存在するのか、何を同一とみなすのか、誰が何をしてよいのか、仕事がどう流れるのか。手作りのスタックでは、それでも各行はコードとして表現されます。下の 5 つの痛みが噛みつくのは、まさにそのためです。
2 回目のデプロイメントこそ、このモデルが儲かるか失敗するかの分かれ目です。 あの表のどれも、やっている最中に感じるほどには顧客固有ではありません。「顧客」のエンティティ解決は、次の顧客ではキーが違うだけの構造的に同じ問題です。承認チェーンは、しきい値と承認者ロールが違うだけの同じ形です。だから 2 回目のエンゲージメントで測る価値のある数値は 1 つだけ — リネーム率と呼びましょう：2 回目のデプロイメントのうち、すでに持っている型付き定義の名前を変えただけの割合であり、書き直しではない割合です。手書きのコードベースではリネーム率はほぼゼロで、しかも誰も気づきません。2 回目も出荷はされるからです — ただ 1 回目と同じコストがかかるだけで。型付きメタデータなら数えられます。面が有限だからです：HotCRM 規模のエンゲージメントは 15 オブジェクト、17 フロー、10 アクション、6 権限プロファイル、5 共有ルール。次の顧客が何を引き継ぐのか、文字どおり列挙できます。
これがこの仕事です。本稿の残りは、あの表の各行を本来より難しくしている 5 つの痛みと、それを取り除くものの話です。
痛み 1 — 第 1 週はいつも配管
どのエンゲージメントも同じ始まり方をします：画面にビジネスオブジェクトを 1 つ出す前に、認証、SSO、ロール、CRUD API、管理 UI、ファイルストレージ、監査テーブルが要る。どれも顧客があなたを雇った理由ではありません。あなたの差別化 — 相手のビジネスを理解することに使うはずの 30–40% — は、前の顧客でも作った無差別な土台の再構築に使う 60% に押し潰されます。
このスタックが変えること： 土台は最初からあります。コマンド 1 つで、Console、サインインと SSO、ロール/行/フィールドレベル権限、監査ログ、REST API、MCP サーバーが昼までに動いています：
npm create objectstack@latest client-app && cd client-app
npx os dev --ui # Console は :3000 — 認証・権限・監査はすでに強制済み導出できるものはすべてランタイムが導出します。残るのは、あなたにしか書けないもの — 顧客のオブジェクト、フロー、権限ルール — だけ。第 1 週はディスカバリーとモデリング、つまりあなたが本当に差別化されている仕事になります。
痛み 2 — セキュリティレビューで死ぬデモ
この曲線はご存知でしょう。第 1 週の金曜：継ぎ接ぎのデモ — コピーした CSV の上に急ごしらえの UI — で会議室は拍手。2 か月目:情報セキュリティ部門が 3 つの質問を持って現れます。AI は正確に何が見えるのか？ AI が動くとき誰の権限が適用されるのか？ 監査記録はどこか？ デモスタックにとって正直な答えは作り直しであり、作り直しこそエンゲージメントが死ぬ場所です。
このスタックが変えること： ガバナンスは後付けではなく土台です。検証ゲートは、共有モデルを宣言していないオブジェクトをそもそも受け付けません：
export const Ticket = ObjectSchema.create({
name: 'support_ticket',
label: 'Ticket',
sharingModel: 'private', // 必須 — なければゲートが拒否する
fields: {
subject: Field.text({ label: 'Subject', required: true }),
status: Field.select({ label: 'Status', options: [/* 顧客の実際の状態 */] }),
approver: Field.lookup('sys_user'),
},
});ランタイムでは、あらゆる呼び出し — 人の UI、REST、MCP 経由の AI エージェント — が同じ RBAC、行・フィールドレベルセキュリティを通り、同じ監査ログに落ちます。情報セキュリティが*「AI は何が見えるのか？」*と聞いたら、答えは彼らがそのまま読めるファイルです：ランタイムが強制する権限メタデータであり、スライドの約束ではありません。金曜のデモと本番デプロイは同一の成果物。作り直しは存在しません — 「ガバナンスなし版」が最初から存在しないからです。
痛み 3 — 要件はコードより速く変わる
会議の途中で運用リーダーが言います：「そういえば、20% を超える値引きは先に地域マネージャーの承認です」。手書きのコードベースなら、スキーマ移行、API 3 か所、UI 1 か所、そして 1 週間 — そして顧客の目には、要求が具体的になった瞬間にあなたが遅くなったと映ります。フォワードデプロイドの仕事は、会議室の中での反復速度で生き死にが決まります。
このスタックが変えること： アプリ全体がコンパクトな型付きメタデータです。同梱の CRM リファレンスは 1,792 行、約 16k トークン(自分で数えてください：find examples/app-crm/src -name '*.ts' | xargs cat | wc -l)。完全な HotCRM でもアプリ全体は 150k トークン未満 — ビジネスロジックは 100k 未満、UI は約 50k です。どちらの規模でも、コーディングエージェントはシステム全体をコンテキストに保持します：承認チェーンの変更は、フロー・権限・UI をまたぐ一つの一貫した diff として、会議が終わる前に書き上がり、os validate が門番をし、Console がライブでプレビューします。「これを変えると何が壊れる？」はエージェントが本当に答えられる問いです — 全体が見えているのだから。要件変更は工程への脅威であることをやめ、それ自体がデモになります。
痛み 4 — パターンが複利にならない
顧客 A の承認チェーンのコードは顧客 B のコードベースに持ち込めません — フレームワークも認証も何もかも違う。だから毎回ゼロから始まり、3 人のブティックは Palantir モデルの経済学を成立させるレバレッジを永遠に築けない。フォワードデプロイド系コンサルが大きくなれない静かな理由です。
このスタックが変えること： パターンは型付きメタデータであり、型付きメタデータは移植可能です。顧客 A のために作った承認チェーンは、顧客 B のリポジトリに落として名前を変えれば動くフロー定義です。案件を重ねるほど自分の「型番ライブラリ」— オブジェクト、フロー、権限セット、シードデータ — が貯まり、エージェントが数分で次の顧客に適用します。しかもゼロから始める必要はありません：HotCRM は完全でフォーク可能なリファレンス — 15 オブジェクト、17 フロー、4 ダッシュボード、2 つの AI コパイロット、4 言語 — であり、この規約の手本として作られています。フォークして名前空間を変えれば、あなたの案件は空のリポジトリではなく動くシステムから始まります。
痛み 5 — 引き継ぎが関係を毒す
すべてのエンゲージメントは終わり、今日その終わり方は 2 通りで、どちらも後味が悪い。プラットフォームを渡せば、顧客は自分のオントロジーを永遠に借り続けます — あなたは誰かの販売チャネルになり、顧客は「成功したパイロット」を恐れることを学びます。オントロジーが良いほどロックインは深いからです。特注コードベースを渡せば、相手のチームは維持できず、腐っていき、18 か月後にその腐敗はあなたの名前と結びつきます。
このスタックが変えること： これがオントロジーの引き継ぎ — FDE プレイブックが解かなかった結末です。渡すのは顧客のリポジトリ：Apache-2.0 の型付きオブジェクト、フロー、権限、それにコンパイル済み成果物とレビューチェックリスト。セキュリティチームは定義全体を確認できます — 同梱リファレンスは 16k トークン、完全な HotCRM でさえ 150k 未満であり、30 万行のコードではありません。顧客自身のコーディングエージェントが、あなたが使ったのと同じループで維持を続けます — このフォーマットはエージェントが書くために作られているからです。プラットフォームの運用ごと任せたければ ObjectOS があり、同じオープンな定義の上で動きます — 離れてもオントロジーは失われません。次の契約はロックインで搾り取るものではなく、新しい仕事で勝ち取るもの。その違いが、複利で効いてくるあなたの評判です。
FDE のための完全なメタデータツールキット
オントロジーはデータモデルだけではありません。フォワードデプロイドのエンゲージメントは、ディスカバリーから引き継ぎまで、各フェーズにメタデータタイプを使います — そしてそのすべてが、同じ型付き・検証可能・移植可能な定義です:
| フェーズ | 答えるべき顧客の問い | 使うメタデータタイプ |
|---|---|---|
| 1 · 名詞のモデリング | 「うちのビジネスには何がある？」 | オブジェクトと項目(関係、検証ルール、数式)· データソース(既存 DB に接続、移行不要)· シードデータ(デモと検収用) |
| 2 · 動詞のモデリング | 「仕事は実際どう流れる？」 | フロー(承認チェーン、状態機械、レコードトリガー、スケジュール)· 承認(多段階、キュー、レコードロック)· アクション(権限チェック付きのボタンとサーバー操作) |
| 3 · 人のための画面 | 「うちの人はどこで働く？」 | アプリとナビゲーション · ビュー(リスト/かんばん/カレンダー/ガント)· ページとフォーム · ダッシュボードとレポート(経営陣が求める KPI) |
| 4 · セキュリティレビュー通過 | 「誰が何を見て何ができる？」 | 権限セットとロール(RBAC)· 行・フィールドレベルセキュリティ · 共有ルール · 監査(ランタイム内蔵 — 宣言すれば得られる) |
| 5 · 顧客が本当に欲しい AI | 「AI は何をしてくれる？」 | AI エージェント(営業/サポートのコパイロット)· AI ツールとスキル · MCP 公開(ai: { exposed: true }) |
| 6 · 引き継ぎと複利 | 「あなたが去った後は？」 | 翻訳(多言語ラベル、グローバル顧客向け)· アプリマニフェストとパッケージング(1 つの objectstack.json にコンパイルし、任意の環境へ) |
要点は、この 6 層が同じ素材でできていることです。承認チェーンもデータモデルと同じ型付きメタデータであり、AI エージェントもそうです — 同じ検証ゲートが検査し、同じ diff でレビューされ、同じリポジトリで引き継がれます:
// The client's verbs: a discount approval — typed metadata, same as an object
export const DiscountApproval: Flow = {
name: 'discount_approval',
label: 'Discount Approval',
type: 'record_change',
status: 'active',
nodes: [
{ id: 'start', type: 'start', label: 'Start',
config: { objectName: 'crm_quote', triggerType: 'record-after-update',
condition: 'record.discount > 0.20' } },
{ id: 'review', type: 'approval', label: 'Regional Manager Review',
config: { approvers: [{ type: 'position', value: 'regional_manager' }], lockRecord: true } },
{ id: 'end', type: 'end', label: 'End' },
],
edges: [/* start -> review -> end */],
};
// The AI the client actually wants: a service copilot — still metadata
export const ServiceCopilot = defineAgent({
name: 'service_copilot',
label: 'Service Copilot',
instructions: 'Help support reps triage and resolve cases. Retrieve only within the user\'s permissions. Always cite case IDs.',
skills: ['case_triage', 'customer_360'],
knowledge: { topics: ['support_kb', 'sla_policies'] },
});HotCRM はこの語彙の完全な使用例です:15 オブジェクト、17 フロー、10 アクション、4 ダッシュボード、2 つの AI コパイロット、6 スキル、6 つの権限プロファイル、5 つの共有ルール、4 言語 — すべての層が揃い、アプリ全体で 150k トークン未満です。ビジネスロジックは 100k 未満、UI は約 50k。全体が 1 つのエージェントコンテキストウィンドウに収まります。
2026 年の模倣の波は、職種を写して基盤を写さなかった
わずか 1 年で、業界は「エンタープライズ AI はこう届けるものだ」と決めました。以下はいずれも、それを表明した企業自身による日付入りのコミットメントです — だからこそ引用に値します：
| 2026 年 | コミットメント | 発表元 |
|---|---|---|
| 5 月 | OpenAI が過半数保有のデプロイメント会社を設立し、40 億ドル超をコミット。コンサルティング会社 Tomoro と約 150 名のフォワードデプロイドエンジニアを同時に取得 | OpenAI |
| 6 月 11 日 | Anthropic と DXC が複数年アライアンスを発表。DXC がすでに銀行・航空会社・保険会社向けに運用しているシステムの内側で働く、Claude 認定のフォワードデプロイドエンジニアを数万人育成する | Anthropic |
| 6 月 30 日 | AWS がフォワードデプロイドエンジニアリング部門に 10 億ドルをコミット。5〜6 名のポッドを顧客内部に常駐させる | CNBC |
| 7 月 2 日 | Microsoft が Frontier を立ち上げ — 25 億ドル、6,000 名 — 同じ仕事のために | CNBC |
この波と一緒に出回る数字がもう 2 つあり、それらは復唱ではなく出所の明示に値します。FDE 求人票の前年比 +1,165% は Live Data Technologies の集計を Paraform が伝えたもの — FDE 採用を商売にしている採用マーケットプレイスです — そして数えているのは求人票であって、充足されたポジションではありません。Salesforce の「1,000 名の FDE チーム」は Salesforce 自身のブログ発。意思表明であって、開示された人員数ではありません。どちらも方向としては本物で、どちらも監査は受けていません。
さて、実務にとって重要なのはここからです。あの表のコミットメントはすべて、エンジニアとドルで表示されています。2 回目のデプロイメントが 1 回目より安くなるかどうかを決めるもの — エンジニアのアウトプットが何に書き込まれるのか — で表示されたものは 1 つもありません。Palantir のメソッドが効くのは、FDE が顧客専用オントロジーに書き込み、アプリケーションがそこから導出されるからです — 基盤こそが製品であり、エンジニアはそれが顧客に届く経路です。まったく同じ人材を、基盤のない組織に採用しても、外から見た仕事は 1 年ほどはまったく同じに見えます。
だから、どのフォワードデプロイド組織に対しても — 入ろうとしている組織、発注しようとしている相手、自分が作っている組織 — 有用な問いは「エンジニアが何人いるか」ではありません。基盤についての 3 つの問いです：
- エンジニアが去るとき、その仕事はどのファイルに着地したのか？ チケットも、ノートブックも、作り込んだサービスも答えにはなりません。顧客のリポジトリにある型付き定義なら答えになります。
- 顧客はあなた抜きでそれを読めるか？ 定義がベンダーのコンソールの中でしか読めないなら、顧客は自分のオントロジーを借り直しているのであり、あなたの仕事が良いほどその度合いは深まります。
- 2 回目のデプロイメントは 1 回目から何を引き継いだか？ そのリストを出してもらってください。誰も出せないなら、リネーム率はゼロです。
本稿の答えは 3 つとも同じで、それが上のすべてを貫くオントロジー優先の理由です：成果物はオープンなビジネスオントロジー — Apache-2.0 の下、顧客自身のリポジトリに置かれた型付きのオブジェクト・フロー・権限 — であり、顧客はそれを読み、保持し、自分のコーディングエージェントに渡せます。職種を写すのは採用計画であり、四半期あればできます。基盤を写すというのは、顧客が手元に残したいと思うくらいオープンにするということで、それは 2026 年の波の中でほとんど誰も下していない製品判断です。
このスタックが直さないもの
相手側の言い分も立てておきます：Foundry 級のデータフェデレーションと分析パイプラインは Palantir のホームグラウンドです — 40 の遺産システムからペタバイトを融合する案件なら、別の道具のクラスです。組織のチェンジマネジメントはどんなスタックにも直せません。すでに閉じたプラットフォームに全面標準化した顧客が留まるのも合理的でしょう。主張はより狭い：フォワードデプロイド業務のアプリケーション層 — ビジネスをモデル化し、統制されたアプリをその上で出荷する — に関しては、上の 5 つの痛みはいまや取り除け、オントロジーは人質ではなく引き継ぎ物にできる、ということです。
FDE チェックリスト
- どんな UI の話よりも先に、顧客の名詞と動詞をオブジェクトとフローにモデル化する。
- 定義全体をコンテキストサイズに保ち、エージェントが丸ごと推論・リファクタリングできるようにする。
- 権限はデフォルトで保守的に。権限の変更はすべて diff で明示する。
- 引き継ぐのはリポジトリ、コンパイル済み成果物、レビューチェックリスト — 自社テナントのログインではない。
- MCP を有効にしたまま渡し、顧客自身の AI がその権限内でアプリを操作できるようにする。
- 2 回目のデプロイメントでリネーム率を数える。何も引き継げていないなら、問題はそのエンゲージメントではなく基盤にある。
ループを回してみる
コーディングエージェントをオープンスタックに向けてください — スキャフォールドには AGENTS.md とスキルバンドルが同梱され、エージェントは最初からフォーマットのルールを読み込んだ状態で始まります：
npm create objectstack@latest client-app && cd client-app
npx os dev --ui # アプリは動いています — 最初のオブジェクトをエージェントとモデル化プラットフォームの運用まで任せたい顧客には、ObjectOS — ObjectStack 上の商用プロダクション／運用プラットフォーム、ブラウザで構築と問い合わせ、マネージドまたはプライベート展開、ガバナンス内蔵 — があります。