FDE(フォワードデプロイドエンジニア)は何を使うのか？ オントロジー優先のオープンスタック
FDE の仕事を定義する 5 つの痛み：配管が第 1 週を食い潰す、デモがセキュリティレビューで死ぬ、要件がコードより速く変わる、パターンが複利にならない、引き継ぎが信頼を毒す。それぞれへの具体的な解決策を示します。
要約： フォワードデプロイドエンジニアリング(FDE)はエンタープライズ AI で最も成長している職種です — 採用は前年比約 1,000% 増、OpenAI は専門のデプロイメント会社に 40 億ドルをコミット。機能するプレイブックは Palantir のオントロジー優先メソッドです。しかし現役の FDE に実際の 1 週間を聞くと、繰り返し現れる 5 つの痛みが返ってきます：配管がエンゲージメントを食い潰す、デモがセキュリティレビューで死ぬ、要件がコードより速く変わる、パターンが顧客をまたいで複利にならない、引き継ぎが関係を毒す。本稿ではこの 5 つを具体的に検討し、オープンなオントロジー優先スタックがそれぞれをどう取り除くかを示します。最後に、この職種の次の波を定義すると私たちが考える問い — オントロジーの引き継ぎ。顧客のオントロジーは顧客自身のリポジトリの型付きオープンファイルとして残るのか、それとも他人のプラットフォームの更新交渉カードになるのか？
誰も正直に説明しないこの仕事
求人票が語るのは「0→1 の曖昧さ」と $300K–$550K の報酬帯です(Perspective AI、TechTarget)。実際の仕事は、他人の壁の内側で AI を動かすことです：相手のデータ、相手の権限、相手のコンプライアンス部門、相手の「十分」の定義。Palantir は何年も前にメソッドを制度化しました：AI FDE は LLM アプリを出す前に顧客専用オントロジーを先行構築し、週の 30–40% をディスカバリーに使う(Palantir AI FDE ガイド)。メソッドは正しい。1 週間が実際に消えていくのは、その下の道具立てです。痛みを 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)。つまりコーディングエージェントはシステム全体をコンテキストに保持します：承認チェーンの変更は、フロー・権限・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 トークンであって 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 言語 — すべての層が揃って約 170k トークン。全体がなお 1 つのエージェントコンテキストウィンドウに収まります。
このスタックが直さないもの
相手側の言い分も立てておきます：Foundry 級のデータフェデレーションと分析パイプラインは Palantir のホームグラウンドです — 40 の遺産システムからペタバイトを融合する案件なら、別の道具のクラスです。組織のチェンジマネジメントはどんなスタックにも直せません。すでに閉じたプラットフォームに全面標準化した顧客が留まるのも合理的でしょう。主張はより狭い：フォワードデプロイド業務のアプリケーション層 — ビジネスをモデル化し、統制されたアプリをその上で出荷する — に関しては、上の 5 つの痛みはいまや取り除け、オントロジーは人質ではなく引き継ぎ物にできる、ということです。
FDE チェックリスト
- どんな UI の話よりも先に、顧客の名詞と動詞をオブジェクトとフローにモデル化する。
- 定義全体をコンテキストサイズに保ち、エージェントが丸ごと推論・リファクタリングできるようにする。
- 権限はデフォルトで保守的に。権限の変更はすべて diff で明示する。
- 引き継ぐのはリポジトリ、コンパイル済み成果物、レビューチェックリスト — 自社テナントのログインではない。
- MCP を有効にしたまま渡し、顧客自身の AI がその権限内でアプリを操作できるようにする。
ループを回してみる
コーディングエージェントをオープンスタックに向けてください — スキャフォールドには AGENTS.md とスキルバンドルが同梱され、エージェントは最初からフォーマットのルールを読み込んだ状態で始まります：
npm create objectstack@latest client-app && cd client-app
npx os dev --ui # アプリは動いています — 最初のオブジェクトをエージェントとモデル化プラットフォームの運用まで任せたい顧客には、ObjectOS — 同じオープンな定義の上で動く商用ランタイム、ブラウザで構築と問い合わせ、ガバナンス内蔵 — があります。