FDEが作る成果物は、ChatAPIであるべきだ

Posted at 2026-10-03

最近、FDEという職種が急速に注目されている。

FDEは、AIの導入方針を提案するコンサルタントではない。既製のSaaSを顧客ごとに設定するための常駐エンジニアでもない。

顧客の業務へ入り込み、解くべき問題を特定し、必要なデータとシステムを接続し、現場で動くソフトウェアを実装する。そして、個別の現場で得た知見を、再利用可能なプロダクトの能力へ戻す。

これがFDEである。

FDEは、基盤モデル企業と顧客企業のあいだで現実とプロダクトを相互に変換する

顧客の要望どおりにアプリケーションを作るだけなら、受託開発である。FDEは、顧客固有の現実と、自社が持つ汎用的な技術基盤の間に立ち、現場でしか観測できない問題をソフトウェアへ変換する。

FDEとは、現実からプロダクトを学習させるための機構である。

そして、FDEはLLMとともに生まれた仕事ではない。

FDEはLLM以前から存在していた

FDEという働き方を長く実践してきた代表的な企業がPalantirである。

Palantirは2003年に創業し、米国の諜報機関におけるテロ対策のためのソフトウェア開発から始まった。2008年には、諜報・防衛機関向けの最初のプラットフォームであるGothamを提供している。現在のような大規模言語モデルが登場するより、はるかに前のことである。[1]

FDEはLLM以前から存在し、データ統合と業務実装の時代から連続している

PalantirのFDEは、顧客から要件を聞いて持ち帰るだけではなかった。

アフガニスタンの軍事基地や米国中西部の工場まで赴き、実際にソフトウェアが使われる現場へ入った。そこで、ユーザーが何を見て、どのように判断し、どこで既存の仕組みに阻まれているのかを観察しながら、GothamやFoundryを実装した。

現場で得られた知見は、その顧客だけのカスタマイズに閉じられない。複数の現場で利用できる形へ抽象化され、Palantirの共通プロダクトへ戻される。Palantirは現在、この開発方法を「人間による誤差逆伝播」と表現している。[2]

通常のプロダクトエンジニアが「一つの能力を、多数の顧客へ届ける」のに対して、PalantirのFDE、社内でいうDeltaは「一人の顧客に、多数の能力を届ける」。ただし、その多数の能力から共通項を発見し、再びプロダクト側へ返していく。[3]

この歴史を踏まえれば、FDEを「企業向けAIアプリを高速に作る人」と理解することが不十分なのは明らかである。

PalantirがLLM以前からFDEを必要としていたという事実は、FDEの本質がプロンプト設計やエージェント開発にはないことを示している。

FDEの本質は、ある組織の現実を、ソフトウェアが認識し、推論し、操作できる構造へ変換することにある。

なぜPalantirにはデータ統合が必要だったのか

Palantirが最初に向き合った諜報・防衛の現場では、一つの対象に関する情報が、最初から一つのデータベースへ整理されているわけではなかった。

通信から得られた情報、現場の報告、位置情報、人物情報、金融取引などが、それぞれ異なる組織やシステムに保存されている。Palantir自身が「一つではなく、何千もの干し草の山から針を探していた」と表現するように、必要な情報が存在していても、互いに結びついていなければ全体像を把握できなかった。[2]

これは企業でも同じである。

顧客情報はCRMにあり、注文は販売管理システムにあり、契約書は文書管理システムにあり、請求は会計システムにある。

製造業であれば、設備、部品、在庫、生産計画、品質記録、供給業者の情報が、部署や工場ごとに分断されている。

ある顧客への納品が遅れる可能性を知りたいだけでも、注文、生産状況、部品在庫、供給業者、輸送状況を横断して確認しなければならない。

データ同士の関係が定義されていなければ、人間が複数の画面や表計算を行き来し、頭の中でつなぎ合わせるしかない。

Palantirが解こうとしたのは、単にデータを一か所へコピーすることではなかった。

異なるシステムから得られた情報を、同じ現実を指しているものとして結び直し、組織が判断と行動に使える状態へ変えることだった。

FDEが作るのはデータ基盤だけではない

データを巨大なデータベースやデータウェアハウスへ集めただけでは、企業の業務は表現できない。

データベースに保存されているのは、テーブル、行、列である。

一方、現場の人間が認識しているのは、顧客、契約、工場、設備、部品、注文、担当者といった対象である。

どのデータが一人の顧客を表すのか。

その顧客はどの契約と結びついているのか。

一つの部品が、どの製品や注文に影響するのか。

その対象に対して、誰がどの操作を実行できるのか。

こうした、企業に存在する対象、その属性、対象同士の関係、実行可能な操作を定義するものがOntologyである。

分断された業務データを、現実の対象と関係として再構成するのがOntologyである

Palantirは2020年の上場資料ですでに、Ontologyを、オブジェクト、属性、関係から組織固有の世界を記述する仕組みとして説明していた。構築されたOntologyからは、組織固有のアプリケーションやワークフローを開発するためのSDKも生成できた。[2]

現在のPalantirはさらに明確に、Ontologyを、企業のデータ、ロジック、アクション、セキュリティを一つに統合するオペレーション層と定義している。[4]

Ontologyは、データを整理するための分類表ではない。

それは、企業に何が存在し、それらがどのようにつながり、どのような判断を行い、何を実行できるのかを表現した、企業の操作可能なモデルである。

つまり、PalantirのFDEが作っていたのは個別の画面だけではない。

個別のアプリケーションを何度でも生み出せる、企業固有の系だった。

LLMプロバイダーは世界一般を作り、FDEは会社の系を作る

基盤モデル企業は、「世界モデルを作る」と明示的に宣言しているわけではない。

しかし、基盤モデル間の競争は、世界一般に存在する言語、知識、手続き、因果関係、推論パターンを、より広く、より高い精度でパラメータの中へ圧縮する競争になっている。

それでも、どれほど高性能なモデルであっても、ある会社における「売上」が何を意味するのかは知らない。

受注時点の金額なのか。納品済みの金額なのか。請求済みの金額なのか。

どのテーブルを正とするのか。受注、契約、納品、請求はどのようにつながっているのか。どの社員が値引きを承認できるのか。現在、どの工場で何が起きているのか。

こうした情報は企業ごとに異なり、日々変化する。

企業の現在の状態や権限体系をモデルのパラメータへ焼き込むべきではない。必要なのは、汎用モデルを会社ごとに作り直すことではなく、汎用モデルの外側に、会社固有の世界を構築することである。

LLMプロバイダーが、世界一般についてのパラメトリックな知能を作る。

FDEは、その知能がある会社の内部で成立するための、非パラメトリックな系を作る。

LLMプロバイダーは世界一般を作り、FDEは会社固有の系を作る

その系には、単なる社内文書だけでなく、現在の業務データ、企業固有の概念と関係、正とするデータの定義、業務上の計算や判断ロジック、実行可能なアクション、権限と承認、監査履歴、そして回答や行動を検証する評価系が含まれる。

FDEの仕事は、会社の知識をLLMに覚えさせることではない。

世界一般を扱える知能を、ある会社の現実へ接地させることである。

なぜ成果物がアプリケーションでは足りないのか

これまでFDEは、構築したデータ基盤やOntologyの上に、ダッシュボード、検索画面、シミュレーション、承認フロー、アラートなどのアプリケーションを作ってきた。

アプリケーションは必要である。

毎日繰り返す作業、入力形式が決まっている作業、一覧性が重要な作業、誤操作の危険が大きい作業は、チャットよりも専用画面のほうが速く、安全である。

問題は、アプリケーションをFDEの最終成果物だと考えることにある。

アプリケーションは、作られた時点で想定されていた問いと操作を、画面として固定したものである。

「納期が遅れそうな注文を一覧表示する」

「在庫が一定量を下回ったら通知する」

「申請を確認して承認する」

こうした要求には強い。

しかし、現場には、事前に画面へ固定できない問いが常に発生する。

「今週の遅延案件のうち、利益率の高い顧客へ影響するものだけを出してほしい」

「この部品を別工場へ移した場合、来月の生産計画にどのような影響が出るか」

「同じ原因で過去に発生した障害と、そのとき採用した対応策を調べてほしい」

新しい問いが生まれるたびに、FDEが戻ってきて、新しい画面とAPIを作らなければならないなら、企業の系はまだソフトウェア化されていない。

固定されたアプリケーションが増えただけである。

FDEが作るべき最小成果物はChat APIである

FDEが作るべきなのは、一つの巨大な万能チャットボットではない。

企業のOntologyへ接続され、特定の業務領域について、自然言語から読み取りと操作を行える、最小単位のChat APIモジュールである。

このChat APIは、単に質問文をLLMへ送るエンドポイントではない。

ユーザーの言葉を企業固有の概念へ変換し、必要なデータを取得し、関係する業務ロジックを呼び出し、権限を確認し、必要であればアクションを実行する。

そして、何を根拠に回答し、どのデータを読み、どの操作を行ったのかを追跡できなければならない。

したがって、Chat APIは少なくとも、LLM、Ontology、現在のデータ、業務ロジック、Actions、権限、監査、Evalsという要素から構成される。

この一連の接続が完成して初めて、汎用モデルはその会社における知能として成立する。

Chat APIは、チャット画面そのものではない。

Slackから呼び出してもよい。音声インターフェースにつないでもよい。既存の業務アプリへ埋め込んでもよい。バックグラウンドで動くエージェントから利用してもよい。

重要なのはUIではなく、会社の系に対して、言葉を共通形式として読み書きできることである。

だから、成果物はchat botではなくChat APIなのである。

Chat APIはチャット画面ではなく、会社の系への共通インターフェースである

アプリケーションは対話をコンパイルしたものである

Chat APIとアプリケーションは対立しない。

むしろ、Chat APIを使う中で頻繁に繰り返される対話や操作が見つかれば、それを専用UIとして固定すればよい。

毎朝、「昨日から納期リスクが上昇した注文を、顧客重要度順に表示して」と入力しているなら、その対話はダッシュボードにできる。

毎回、「この在庫移動案について、影響範囲を確認し、問題がなければ承認者へ送って」と依頼しているなら、その対話はボタンと承認フローにできる。

つまり、アプリケーションとは、頻出する対話を高速で、安全に、再現可能に実行するためにコンパイルしたものである。

Chat APIは、未知の問い、例外、探索を扱う。

アプリケーションは、既知の問いを高速に処理する。

自動処理は、対話する必要さえなくなった処理を実行する。

三者は別々のシステムではない。同じ企業の系に対する、異なるインターフェースである。

アプリケーションは、頻出する対話をコンパイルしたものである

Palantir自身もChat APIへ向かっている

この主張は、Palantirの思想にChat APIを無理やり付け加えたものではない。

PalantirのOntology SDKは、Ontologyに対する読み書きをTypeScript、Python、Java、OpenAPIなどから利用できるようにし、企業固有のアプリケーションをOntologyの上に構築できる。[5]

さらに現在のAIP Chatbot Studioでは、企業固有のOntologyデータとツールを与えた対話型システムを作り、Ontologyの編集、業務アクションの自動化、ワークフローの実行まで行える。構築したChatbotはPalantir内部だけでなく、APIを通じて外部アプリケーションにも埋め込める。[6]

LLM以前のPalantirは、企業を機械可読かつ機械操作可能にした。

現在のPalantirは、その企業へ自然言語からアクセスするインターフェースを載せ始めている。

FDEの本質は変わっていない。

Ontologyの上に新しい入口が加わったのである。

OpenAIがFDEを必要とする理由

OpenAIは2026年5月、企業への導入を担うOpenAI Deployment Companyを立ち上げ、約150人のFDEとDeployment Specialistを擁するTomoroの買収に合意した。さらに同年7月には、Palantirの最上位パートナーネットワークの最初の企業だったNorthslopeの買収にも合意している。いずれも発表時点では、必要な承認などを条件とする契約段階である。[7]

これは、基盤モデルの性能が上がれば、企業導入が自動的に進むわけではないことを示している。

モデルが世界一般について賢くなっても、企業のデータが分断されたままなら使えない。

企業固有の概念が定義されていなければ、質問を正しく解釈できない。

実行可能なアクションや権限が接続されていなければ、回答するだけで終わる。

評価系がなければ、その回答を本番業務で信頼できない。

OpenAIのFDE採用情報でも、FDEの成功は、デモの完成ではなく、本番での利用、業務への実質的な影響、そして評価を通じて得られたフィードバックがモデルやプロダクトのロードマップを変えることで測られている。[8]

これはPalantirのFDEと同じ構造である。

現場へ入り、動くものを作り、現実から得た誤差信号をプロダクトへ戻す。

違うのは、Palantirがデータとオペレーションのプラットフォームから始まったのに対して、OpenAIは汎用モデルから始まったという点だけである。

両者は反対側から、同じ場所へ向かっている。