a16z：万物 Palantir 化背后、一場注定失敗的模仿秀

作者：Marc Andrusko

翻訳：深潮 TechFlow

深潮ガイド： シリコンバレーでは「Palantir化」ブームが巻き起こっている——AIスタートアップ企業が次々とPalantirを模倣し、エンジニアを現場に派遣し、高度にカスタマイズされたサービスを提供し、7桁の大口契約を獲得している。

a16zのパートナー、Marc Andruskoは冷水を浴びせる：「大多数の企業は表面的な模倣にとどまり、最終的にはSaaSの外観を持つコンサルティング会社に成り下がるだろう。」この記事では、Palantirモデルの本当に模倣可能な部分と、単なる幻想に過ぎない部分を解き明かし、企業ソフトウェアと高接触型サービスを結びつけたい創業者にとってより実用的なロードマップを提供する。

本文内容：

今、スタートアップのビジネスプランには「我々はX分野のPalantirだ」というフレーズが流行している。

創業者たちは、「フロントライン展開エンジニア」（Forward-Deployed Engineers、略してFDE）を顧客先に派遣し、深くカスタマイズされたワークフローを構築し、特殊部隊のように運営することに熱狂している。今年、FDEの募集ポジション数は数百パーセント増加し、多くの企業が2010年代にPalantirが築いたモデルを模倣している。

このやり方の魅力は理解できる。企業顧客は今、「どのソフトウェアを買うか」に頭を悩ませている——すべての製品がAIを標榜し、ノイズの中から信号を見つけ出すのはこれまでになく難しい。Palantirの売り方は非常に魅力的だ：混乱した環境に小隊を空降させ、さまざまな孤立したシステムをつなぎ合わせ、数ヶ月以内にカスタムワークフローを提供する。最初の7桁の契約を獲得したいスタートアップにとって、「エンジニアを派遣して組織に入り込み、問題を解決する」という約束は非常に強力だ。

しかし、「Palantir化」が汎用的な方法論として普及できるかには疑問を抱いている。Palantirは「カテゴリー・オブ・ワン」（唯一無二の存在）だ——その株価の動きを見れば一目瞭然だ！模倣者の多くは表面的な模倣にとどまり、最終的には高価なサービス企業に成り下がり、ソフトウェアの評価倍率を持ちながらも、持続的な競争優位性を持たないことになる。これを2010年代に「プラットフォーム」と自称したスタートアップ企業の多さを思い出すが、実際にプラットフォームを築くのは非常に難しい。

この記事では、Palantirモデルの中で本当に移植可能な部分と、独自すぎて模倣できない部分を整理し、企業ソフトウェアと高接触型サービスを結びつけたい創業者にとってより現実的な道筋を示す。

「Palantir化」とは一体何を意味するのか

「Palantir化」はいくつかの相互に関連する事柄を指すようになった：

フロントライン埋め込みエンジニアリング

Palantir内部では「Delta」や「Echo」と呼ばれるフロントライン展開エンジニアは、顧客の組織に長期間（通常数ヶ月）入り込み、ビジネスシナリオを理解し、システムをつなぎ、Foundryプラットフォーム（または高セキュリティ環境下のGothamプラットフォーム）上でカスタムワークフローを構築する。価格は固定料金で、「SKU」は基本的に存在せず、エンジニアがこれらの能力の構築と保守を担当する。

高度に主張のある統合プラットフォーム

Palantirの製品は、散在したツールの集合ではなく、データ統合、ガバナンス、運用分析を目的とした明確な主張を持つプラットフォームであり、組織のデータを「オペレーティングシステム」に近い形で扱う。目的は、断片化したデータをリアルタイムかつ高信頼性の意思決定に変換することだ。

高級・高接触の販売モデル

「Palantir化」はまた、長期にわたる高接触型の販売スタイルも指す。ターゲット顧客は国防、法執行、情報機関などの重要任務環境だ。規制の複雑さや業界の「賭け」の規模は、特性でありバグではない。

結果を売る、ライセンスは売らない

収益は長期契約と結果に連動し、ソフトウェア、サービス、継続的な最適化が混在する。単一の顧客との契約は数千万ドルに達することもある。

最近の分析では、Palantirは「唯一品種」（Category of One）と定義されている。なぜなら、次の3つの点で極めて優れているからだ：（a）統合製品プラットフォームの構築、（b）エリートエンジニアを顧客運営に埋め込み、（c）政府や国防の重要任務環境で実証済み。多くの企業はこれらのうち1つか2つはできても、3つ同時に行うのは不可能だ。

しかし、2025年までに、多くの企業がこのモデルの光を浴びようとするだろう。

なぜ今、誰もがPalantirを模倣したいのか

3つの力が交錯している：

1. 企業AIの「実現」難題

多くのAIプロジェクトは、導入前に行き詰まる。原因はデータの混乱、統合の難しさ、内部のリーダーシップ不足だ。調達意欲は依然高い（取締役会やC-suite層には「AIを買わざるを得ない」という上からの圧力がある）が、実際の展開やROIには多くのハンズオン作業が必要だ。

2. フロントライン展開エンジニアは「欠落した橋梁」のように見える

メディア報道や求人データによると、FDEのポジションは今年爆発的に増加しており（増加率は800%から1000%の範囲）、AIスタートアップはエンジニアを埋め込み、展開を実現しようとしている。

3. 急速な成長は常態化（7桁契約は5桁の小口契約よりも早く大きくなりやすい）

エンジニアを飛行機で派遣して駐在させることが、フォーチュン500や政府機関の100万ドル超の契約を獲得するためのコストだとすれば、多くの早期企業は粗利率と引き換えに動力を得ようとしている。投資家も、推論コストが高い新しいAI体験にはより低い粗利率を許容しつつ、顧客管理層の信頼と結果の提供を重視している。

こうして、「我々はPalantirがやったことをやる。エリートチームを派遣し、奇跡的なものを作り、それを時間とともにプラットフォームに変えていく」というストーリーが形成される。

このストーリーは非常に特定の状況下で成立し得るが、いくつかの硬い制約も存在し、創業者はそれをあまり語らない。

類似性が失効する場所

「結果」を最初から売ろうとする

Palantirのフラッグシップ製品Foundryは、数百のマイクロサービスの集合体であり、共通の結果に向けて連携している。これらのマイクロサービスは、各分野の企業が抱える一般的な問題に対して、製品化された明確な解決策を提供している。過去2年間で数百のAIアプリ創業者と会ったが、類似性が崩れるポイントは次の通りだ：スタートアップは最初から結果に基づく壮大な目標を掲げてピッチするが、Palantirは意識的にマイクロサービスを構築し、それがコア能力の土台となっている。これが、Palantirと普通のコンサルティング会社の違い（また、来年の収益の77倍の評価取引の理由）だ。

Palantirには一連のコア製品がある：

Palantir Gotham：国防・情報分析プラットフォーム。軍事、情報、法執行機関が散在するデータを統合し、任務計画や調査に役立てる。

Palantir Apollo：ソフトウェア展開・管理プラットフォーム。多クラウド、オンプレ、オフライン環境に安全にアップデートや新機能をプッシュできる。

Palantir Foundry：業種横断のデータ運用プラットフォーム。データ、モデル、分析を統合し、企業の運営意思決定を推進。

Palantir Ontology：実世界のエンティティ、関係、ロジックを動的に操作可能なデジタルモデル化。Foundry内のアプリや意思決定に力を与える。

Palantir AIP（人工知能プラットフォーム）：Ontologyを通じて、AIモデル（例：大規模言語モデル）と組織のデータ・運用を連結し、生産性の高いAI駆動のワークフローやエージェントを作り出す。

Everestレポート引用：「Palantirの契約は小さなところから始まる。最初の協力は短期のトレーニングキャンプや限定的なライセンスだけかもしれない。価値が証明されれば、より多くのユースケースやワークフロー、データ領域に拡大していく。時間とともに、収益構造はサービスからソフトウェアサブスクリプションへと傾いていく。コンサルティング企業とは異なり、サービスは製品採用を促進する手段であり、主要な収益源ではない。多くのソフトウェアベンダーと違い、Palantirは自社のエンジニアリング時間を事前に投入して、意味のある顧客を獲得することを厭わない。」

一方、今見ているAIアプリ企業は、すぐに7桁契約に跳躍できるケースが多いが、これは彼らが完全にカスタマイズモードにあるためだ——早期顧客の問題を解決し、その中からテーマを見出してコア能力や「SKU」を構築しようとしている。

すべての問題が「Palantirレベル」ではない

Palantirの早期展開分野は、「何も役に立たない」選択肢の代替となる：反テロ、詐欺検出、戦場後方支援、高リスク医療運用などだ。これらの問題の解決価値は、数十億ドルの損失や人命救助、地政学的な結果で測られるものであり、増分効率ではない。

もしあなたが中規模のSaaS企業に販売し、販売プロセスを8％最適化したとしても、同等のカスタマイズ展開のコストは負担できない。ROIの範囲は、数ヶ月の駐在エンジニアを正当化できるほどには大きくない。

ほとんどの顧客は、あなたの研究開発の実験室のように永遠に使いたいわけではない

Palantirの顧客は、共に進化する製品を受け入れることを前提としている。彼らは多くを許容している。なぜなら、賭けが高く、代替品が少ないからだ。

特に国防や規制の少ない分野の企業は、自分たちが長期的なコンサルティングプロジェクトの一部であると感じたくない。彼らが求めるのは、予測可能な導入、既存ソフトとの相互運用性、そして迅速な効果だ。

人材の密度と文化は一般化できない

Palantirは、異常に優れた汎用エンジニアを採用・育成するのに10年以上を費やしてきた。彼らは生産レベルのコードを書き、官僚的な体系の中でも巧みに動き、上司やCIO、規制当局と会話できる。これらの人々の多くはユニコーン級の創業者や幹部となっている。彼らは高度な技術力を持ちつつ、クライアントの前でも非常に効果的だ。

多くのスタートアップは、同じレベルの人材を数百人雇用できると仮定できない。実践的には、「Palantir式のFDEチームを作る」と言っても、次のような形に退化しがちだ：

プレセールスのソリューションエンジニアの名称を「FDE」に変更

ジュニアの汎用エンジニアに、製品、実装、顧客管理を同時に求める

リーダー層はPalantirの展開を間近で見たことがなく、その雰囲気だけを好む

明確にしておきたいのは、外部には非常に才能のある人材が多く、Cursorのようなツールは非技術者でもコードを書けるようにしているが、Palantirのモデルを大規模に展開するには、極めて希少なビジネスと技術の融合人材が必要であり、実際にPalantirで働いた経験があると非常に役立つ。だが、その人材の数は限られている。

サービスの落とし穴は本物

Palantirが成功したのは、カスタマイズ作業の背後に本当にプラットフォームが存在しているからだ。もし嵌め込みエンジニアだけを模倣しようとすれば、最終的には何千、何万ものカスタム展開が生まれ、維持やアップグレードが困難になる。AIツールによって企業がこのモデルでソフトウェアレベルの粗利率を達成している世界でも、前線展開に偏りすぎて強力な製品の背骨を持たない企業は、規模の増加や持続的な競争優位を生み出せない可能性が高い。

無差別に投資する投資家は、0から1000万ドルの契約価値の曲線棒のような成長を見て、急いで参入しがちだが、私が常に問い続けているのは、数十社（あるいは数百社）のこうした1000万ドルのスタートアップが、まったく同じピッチで競合し始めたときに何が起きるかだ。

そのとき、あなたは「X分野のPalantir」ではなく、「X分野のアセンブリ・エクセンチック」になっているだけだ。

Palantirが本当にやったこと

神話を剥ぎ取ると、いくつかの要素が見えてくる：

1. プラットフォーム優先、プロジェクト優先ではない

Palantirのフロントライン展開チームは、再利用可能な原語（データモデル、アクセス制御、ワークフローエンジン、可視化コンポーネント）を基に構築されており、顧客ごとに完全にカスタマイズされたシステムを作るわけではない。

2. 仕事の「あるべき姿」に対する明確な主張

この会社は単なる既存プロセスの自動化だけでなく、しばしば顧客を新しい働き方に推し進め、そのためのソフトウェア自体がこれらの主張を体現している。これは、供給者としては稀有な勇気であり、再利用を可能にしている。

3. 長期的視野と資本

Palantirのような企業になるには、プラットフォームと販売モデルの成熟過程で、長期的なネガティブな感情や政治的論争、短期的な収益化の不透明さを乗り越える必要がある。

4. 非常に特定の市場構成

情報・国防分野での早期展開は、特性でありバグではない：高い支払い意欲、高い移行コスト、高い賭けの規模、そして超大口顧客の少数だ。さらに、何十年も競争なしで契約を獲得できる古い競合も存在する。

要するに、Palantirは「ソフトウェア企業＋コンサルティング」だけではなく、「ソフトウェア企業＋コンサル＋政治的プロジェクト＋非常に忍耐強い資本」だ。

これは、垂直型SaaS製品に簡単に嫁がせて普及させられるものではない。

より現実的な枠組み：いつ「Palantir化」が妥当か

「どうやってPalantirのようになれるか」ではなく、次のような一連のハードルを問う方が良い：

1. 問題の重要性

この問題は「重要任務レベル」（人命、国家安全保障、数十億ドル）か、それとも「ちょっとした効率化」（10-20％の効率向上）か？リスクが高いほど、フロントライン展開モデルが合理的になる。

2. 顧客の集中度

あなたは数十の超大口顧客に売るのか、それとも何千もの小口顧客に売るのか？集中型・高ACV（年間契約価値）の顧客群では、埋め込みエンジニアの展開がより効果的。

3. 分野の断片化度

顧客間のワークフローは似ているか、使うソフトウェアツールは共通か、それとも毎回全く異なるのか？顧客ごとに雪の結晶のように異なる場合、一貫したプラットフォームの構築は難しい。一定の同質性は役立つ。

4. 規制とデータの引力

高度に規制された分野や、データ統合の痛点が顕著な分野（国防、医療、金融犯罪、重要インフラ）で運営しているか？そこがまさに、Palantir式の統合作業が真の価値を生む場所だ。

これらの次元のほとんどが左下（重要性低、顧客分散、単純な統合）に位置している場合、「Palantir化」はほぼ間違いのない選択肢だ。それは、下からのPLG（プロダクト・グロース）戦略に適している。

何を学ぶべきか

すべての早期企業がPalantirモデルを成功させられるわけではないが、その中で考慮すべきポイントは次の通り：

1. フロントライン展開を足場とし、家を建てることではない

以下のアプローチは正しい可能性が高い：

エンジニアを早期の設計パートナーとともに埋め込み型で働かせる

最初の3-5顧客を何としても本番環境に入れる

これらの協力を通じて原語や抽象化を圧力テストする

ただし、明確な制約が必要：

制限付き展開（例：「90日間のスプリントで本番へ」）

明確な比率（例：「100万ドルのARRあたり最大何人のエンジニアを配置できるか」）

四半期ごとにカスタムコードを再利用可能な設定やテンプレートに変換する目標

さもなければ、「後で製品化するつもり」が「ずっとできていない」に変わる。

2. 強力な原語に基づき構築し、定制ワークフローに頼らない

Palantirの真の教訓は、製品アーキテクチャにある：

統一されたデータモデルと権限層

汎用のワークフローエンジンとUI原語

できるだけコードではなく設定で済ませる

フロントライン展開チームは、「何を選び」「どう組み立てるか」に時間を費やすべきであり、各顧客ごとに新たに構築することは避ける。新規構築はエンジニアの仕事だ。

3. FDEを製品の一部とし、単なる納品にとどまらない

Palantirの世界では、フロントライン展開エンジニアは、製品の発見や反復に深く関わり、単なる実装者ではない。強力な製品組織とプラットフォームチームは、FDEが現場で学んだことを糧にしている。

もしあなたのFDEが「専門サービス」部門に座っているだけなら、そのフィードバックループを失い、純粋なサービス企業へと滑り落ちる。

4. 利益構造に正直であること

あなたのピッチが80％以上のソフトウェア粗利率と150％の純収益維持率を仮定している場合でも、実際の販売モデルが長期駐在を必要とするなら、そのメリットとデメリットを透明に伝える——少なくとも内部では。

特定のカテゴリーでは、低粗利・高ACVのモデルが理にかなっている場合もある。問題は、自分たちをSaaSと偽りながら、実際にはプラットフォームを持つサービス企業であるふりをすることだ。投資家は、最大の粗利益絶対値に向かう道筋を重視し、その一つの方法は、大規模な契約とより顕著なCOGS（売上原価）を伴うことだ。

「Palantir化」スタートアップをどうテストするか

創業者が「我々はX分野のPalantirだ」と言ったとき、私のノートには次のような質問が浮かぶ：

明確な主張を持つプラットフォームの境界線はどこか？ 共有される製品の終わりと、顧客固有のコードの始まりはどこか？ その境界はどれくらい動くのか？

展開のタイムラインを案内してほしい。契約から最初の本番運用までに必要なエンジニア-月はどれくらいか？ どの部分がカスタム必須か？

3年目の成熟した顧客の粗利率はどれくらいか？ フロントライン展開の投入は時間とともに「著しく」低下しているか？ そうでなければ、なぜか？

来年50社の契約を獲得した場合、どこで崩れるか？ 採用？新人研修？製品？サポート？ どこに亀裂が入りそうか？

どうやって「カスタムしない」決断を下すか？ カスタム作業を「ノー」と言う意欲は、プロダクト企業と「きれいなデモのサービス企業」を区別する重要なポイントだ。

これらの答えが明確で、実際の展開に基づき、アーキテクチャも一貫しているなら、一定のPalantir式フロントライン展開は真の強みになり得る。

答えが曖昧だったり、毎回の協力が完全にユニークだと明らかであれば、再現性や規模拡大の潜在性を保証しにくい。

結び

Palantirの成功は、エリートエンジニアチームが複雑な環境に空降し、混乱したデータをつなぎ、組織の意思決定を変えるシステムを提供するという、リスク投資界の精神を支配する強力なオーラを生み出した。多くのAIやデータスタートアップも同じようにすべきだと信じやすいが、多くのカテゴリーにとっては、全面的な「Palantir化」は危険な幻想だ。

問題が十分に重要でない

顧客が細分化しすぎている

人材モデルが拡張できない

経済的に見てサービス企業に落ち着く

創業者にとって、より有益な問いは「どうすればPalantirになれるか」ではなく、

「我々のカテゴリーのAI採用のギャップを埋めるために、どれだけのPalantir式フロントライン展開が必要か——そして、それをどれだけ早く本当のプラットフォーム事業に変えられるか？」だ。

これを正しくやれば、重要な部分だけを借用し、圧倒されるリスクのある部分を避けることができる。