a16z: すべてが「Palantir 化」される背後にある、運命づけられた失敗の模倣ショー

a16z crypto

2026-01-19 18:47

この記事を読むのに必要な時間は 35 分

ほとんどのカテゴリにとって、包括的な「Palantir 化」は危険な幻想です。

原文タイトル：すべてのもののパランティリゼーション

原著者：Marc Andrusko、a16z パートナー

翻訳：深潮 TechFlow

はじめに：シリコンバレーでは現在、「Palantir 化」の波が押し寄せています。AI スタートアップ企業が Palantir を手本に工程師を顧客先に派遣し、高度にカスタマイズされたサービスを提供し、7桁の大口注文を獲得しています。

a16z パートナーの Marc Andrusko はこの動きに冷水を浴びせました。ほとんどの企業は単なる模倣に過ぎず、最終的にはSaaSの外套をまとったコンサルティング企業に成り下がってしまうでしょう。この記事では、Palantir モデルの本当に複製可能な部分と、単なる幻想に過ぎない部分が細かく分析されています。

本文

今日のスタートアップ企業のビジネスプラン（BP）には、「基本的に私たちは X 分野の Palantir です」というフレーズが流行しています。

創業者たちは自社のエンジニアを「前線展開エンジニア」（Forward-Deployed Engineers、FDE）として顧客先に派遣し、深いカスタマイズされたワークフローを構築し、従来のソフトウェア企業ではなく特殊部隊のように運営することを熱心に語ります。今年は、「前線展開エンジニア」を募集する求人が何百パーセントも増加し、みんなが2010年代初期に Palantir が確立したモデルを模倣しています。

このプレイブックが魅力的である理由は理解できます。企業の顧客は今や「どんなソフトウェアを購入すべきか」という問題に頭を抱えており、AIと謳うものがあちこちに溢れています。Palantir のアプローチは非常に魅力的です：数ヶ月でカスタマイズされた作業プラットフォームを提供するために、混沌とした環境に小さなチームを降ろし、さまざまな内製および孤立したシステムを結びつけます。最初の7桁の注文を獲得したいスタートアップ企業にとって、「私たちはエンジニアをあなたの組織に配置し、問題を解決します」という約束は非常に効果的です。

しかし、「Palantir 化」が一般的な方法論として普及できるか疑問です。Palantir は「唯一のカテゴリ」（Category of One）です — その株価の動きを見ればわかります！ Palantir の表面的な取り組みを真似したほとんどの企業は、結局、高価なサービス企業になるだけで、ソフトウェアのバリュエーション倍数を持ちながらも、複利効果の競争上の優位性がありません。これは、2010年代に各社が「プラットフォーム」であると言っていたのと同様に、「Palantir 化」が容易にできないからだと思います。

この記事では、Palantir パターンのうち、本当に移植可能な部分と複製不可能なユニークな部分を明確にし、企業ソフトウェアとハイタッチサービスを組み合わせたい創業者により実用的なロードマップを提供します。

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

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

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

フロントライン展開エンジニア（Palantir 社内では「デルタ」および「エコー」と呼ばれています）が顧客組織に駐在（通常数ヶ月にわたり）、ビジネスシナリオを理解し、各システムを統合し、Foundry プラットフォーム（またはセキュリティの高い Gotham プラットフォーム）でカスタムワークフローを構築します。価格設定は固定料金であり、「SKU」の伝統的な概念はなく、エンジニアはこれらの機能を構築および維持します。

強く主張する統合プラットフォーム

Palantir の製品は基本的にはばらばらのツールセットではなく、データ統合、ガバナンス、および運用分析に使用される主張のあるプラットフォームであり、組織データにより近い「オペレーティングシステム」です。目標は、断片化されたデータをリアルタイムかつ高信頼度の意思決定に変換することです。

高級でハイタッチな販売モデル

「Palantir 化」は、長期かつ高接触の販売サイクルを特徴とする販売スタイルも表しています。ターゲット顧客はキータスク環境（国防、執行、インテリジェンスなど）です。規制の複雑性と業界における「賭け」の規模は、特徴でありバグではありません。

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

収入は、数年間の結果連動契約から発生し、ソフトウェア、サービス、および継続的な最適化が混合されています。個々の顧客契約は、年間数千万ドルに達することがあります。

最近の分析では、Palantir を「唯一のカテゴリ」と定義しました。なぜなら、Palantir が三つのことを同時に非の打ち所のない形で達成したからです：（a）統合プロダクトプラットフォームの構築、（b）顧客運用にエリートエンジニアを組み込む、（c）重要なタスクレベルの政府および国防環境で自らを立証する。ほとんどの企業はこれらのうちの一つまたは二つを達成できますが、すべてを同時に達成するのは不可能です。

しかし、2025年になると、誰もがこのパターンに追随したいと考えています。

なぜ今、誰もがPalantirをまねたがるのか

三つの力が集結しています：

1. 企業AIには「導入」の壁がある

多くのAIプロジェクトが、本番環境に導入される前に立ち往生しています。その原因は、通常、データの混乱、統合の難しさ、組織内でのリーダーシップの不足です。購買意欲は高いままですが（取締役会やCスイートからの「AIを導入する必要がある」という実際のトップダウンの圧力があります）、実際の展開とROIはしばしば多大な手作業を必要とします。

2. フロントライン展開エンジニアは、失われた橋のように見える

メディアの報道や求人データによると、FDEポジションは今年爆発的に増加しています。異なる情報源によると、増加率は800%から1000%の間です。AIスタートアップは、エンジニアを組み込むことで展開を本当の意味で実現しようとしています。

3. 急成長が常態化しています（7桁の大口注文は5桁の小口注文よりも急速にスケールアップしやすい）

エンジニアに飛行機に乗って現地駐在させることが、フォーチュン500企業や政府機関から100万ドル以上の注文を獲得するための代償である場合、多くの新興企業はマージン率を犠牲にすることを選択します。投資家は、新しいタイプのAIエクスペリエンスが多大な推論コストを必要とするため、徐々に低いマージン率を受け入れるようになっています。賭けは、顧客の経営陣の信頼とポジションを獲得し、「結果」を提供し、そこから価格設定を行うことができるかどうかです。

そのため、ストーリーは次のようになります：「私たちはPalantirがやったことをします。エリートチームを派遣して、魔法のようなものを生み出し、それを時間とともにプラットフォームに変えます。」

この物語は非常に特定の状況で成立する可能性があります。しかし、いくつかの厳しい制約が存在し、創業者はしばしばそれを軽視します。

比喩の欠点

最初の日から「結果」を売りたい

Palantirの主力製品であるFoundryは、数百のマイクロサービスから成る組み合わせであり、1つの結果に貢献しています。これらのマイクロサービスは、各業界の企業が抱える一般的な問題に対する製品化された、主張のあるソリューションを提供しています。過去2年間、何百ものAIアプリケーションの創設者に会ってきましたが、比喩が破綻する点をお教えいたします：スタートアップは、巨大な結果ベースの目標を持って入り、その後にPalantirのように意識的にマイクロサービスを構築していくのです。これらのマイクロサービスは、その中核能力の礎となっています。これが普通のコンサルティング会社とPalantirの違いです（77倍の収益での取引を実現した理由でもあります）。

Palantirにはいくつかの主力製品があります：

· Palantir Gotham：国防和情报平台，帮助军事、情报和执法机构整合分析分散数据，用于任务规划和调查。

· Palantir Apollo：软件部署和管理平台，自主安全地向任何环境（多云、本地、断网环境）推送更新和新功能。

· Palantir Foundry：跨行业数据运营平台，整合数据、模型和分析，驱动企业运营决策。

· Palantir Ontology：组织真实世界实体、关系和逻辑的动态可操作数字模型，为 Foundry 内的应用和决策提供动力。

· Palantir AIP（人工智能平台）：通过 Ontology 将 AI 模型（如大语言模型）与组织的数据和运营连接起来，创建可生产的 AI 驱动工作流和代理。

引用那份 Everest 报告：「Palantir 的合同从小处开始。首次合作可能只是一个短期训练营和有限的许可证。如果价值得到验证，才会叠加更多用例、工作流和数据领域。随着时间推移，收入结构会从服务向软件订阅倾斜。与咨询公司不同，服务是推动产品采用的手段，而非主要收入来源。与大多数软件供应商不同，Palantir 愿意预先投入自己的工程时间来拿下有意义的客户。」

一方面，我现在看到的 AI 应用公司往往能直接跳到七位数合同。但另一方面，这主要是因为他们处于全面定制模式——他们在解决早期客户抛出的任何问题，希望之后能从中发现主题来构建核心能力或「SKU」。

不是每个问题都是「Palantir 级」问题

Palantir 早期部署的领域，替代方案是「啥都不管用」：反恐、欺诈检测、战场后勤、高风险医疗运营。解决问题的价值以数十亿美元、挽救的人命数量或地缘政治后果来衡量，而非增量效率。

如果你卖给一家中型 SaaS 公司，帮它优化销售流程 8%，你负担不起同等水平的定制部署。ROI 的空间根本支撑不了数月的驻场工程。

大多数客户不想永远当你的研发实验室

Palantirの顧客は、製品の共同進化をデフォルトで受け入れます。彼らは多くを許容していますが、賭けが大きく、代替品が限られているためです。

多くの企業、特に国防および規制のない分野のほとんどは、自分たちが長期にわたるコンサルティングプロジェクトの一部であると感じたくありません。彼らが求めるのは、予測可能な実装と既存のソフトウェアツールとの連携、そして迅速な効果です。

人材密度と文化は一般化できません

Palantirは10年以上かけて、生産レベルのコードを書くことができ、官僚制度でスムーズに動作し、大佐、CIO、監督機関と同じ部屋で話をすることができる非常に優れたオールラウンドエンジニアをリクルートおよびトレーニングしました。この職位から離れた人々が、一連の「Palantirギャング」の設立者および幹部グループを形成しました。これらの人々の多くはユニコーンレベルであり、技術的に高度でありながら、顧客の前では非常に効果的です。

ほとんどのスタートアップ企業は、数百人ものこのような人材を雇うことができるとは想定できません。実際には、「私たちはPalantirスタイルのFDEチームを構築するつもりです」ということが、しばしば以下に退化します：

· プリセールスソリューションエンジニアが「FDE」と名乗る

· ジュニアオールラウンドが製品、実装、および顧客管理を一緒に行うように求められる

· リーダーシップ層は、Palantirの展開を間近で見たことがないが、その雰囲気が好き

明確に言わなければならないのは、非常に才能のある人々がたくさんいるということと、Cursorなどのツールが非技術者でもコードを書けるようになっているということです。しかし、Palantirのモデルを大規模に展開するには、極めて希少なビジネスと技術の人材統合が必要です。そして、実際にPalantirでの経験があると役立ちます。それは非常にユニークな企業だからです。ただし、この人々の数は限られています！

サービストラップは本物です

Palantirが機能している理由は、カスタムワークの下に本当のプラットフォームがあるからです。エンジニアをインプリントする部分だけを複製すると、最終的には何千ものカスタム展開が生まれ、メンテナンスやアップグレードができなくなります。AIツールによって、企業がこのようなモデルでソフトウェアレベルのマージン率に到達する世界を考えるとしても、フロントライン展開に過度に依存し、強力な製品バックボーンを欠いている企業は、規模の経済的利益や持続可能な競争上の優位性を生み出すことができないかもしれません。

無差別な投資家は、0から1000万ドルの契約価値までのホッケースティック成長を目の当たりにして、急いで参加したいと思うかもしれません。しかし、私が常に疑問に思っていることは、何十もの（場合によっては何百もの）このような1000万ドルのスタートアップ企業が、お互いに衝突するような同じピッチを行い始めたとき、何が起こるのかということです。

その時、あなたは「X 領域の Palantir」ではありません。あなたは「X 領域の Accenture」であり、ただ前面がより美しいだけです。

Palantir が本当にうまくやったこと

神話を剥ぎ取れば、注意深く研究すべき要素がいくつかあります：

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

Palantir のフロントライン展開チームは、一連の再利用可能な原語（データモデル、アクセス制御、ワークフローエンジン、ビジュアライゼーションコンポーネント）に基づいて構築されており、各顧客ごとに完全にカスタマイズされたシステムを作成していません。

2. 仕事がどのようにすべきかに明確な主張がある

この企業は、単なる既存プロセスの自動化ではなく、顧客をしばしば新しい作業方法に導き、ソフトウェア自体がこれらの主張を体現しています。これはサプライヤーにとって稀な勇気であり、それにより再利用が可能になります。

3. 長期的視点と資本

Palantir 様式の企業になるには、プラットフォームと販売モデルが成熟する過程で、長期にわたるネガティブな感情、政治的論争、そして現金化が不透明な状況を経験する必要があります。

4. 非常に特定の市場ポートフォリオ

情報収集および国防分野での初期配置は、特性であり欠陥ではありません：高い支払意向、高い切り替えコスト、高い賭け、そしてほとんど競争がない数少ない超大規模顧客。何十年もの間競争せずに取引を行うことができる古い競合他社の一群を言うまでもありません。

つまり、Palantir は単なる「ソフトウェア企業+コンサルティング」ではありません。それは「ソフトウェア企業+コンサルティング+政治的プロジェクト+非常に忍耐強い資本」です。

これは、垂直の SaaS 製品に単に接続して一般化できるものではありません。

より現実的なフレームワーク：いつ「Palantir 化」するのが妥当か

「Palantir のようになる方法」ではなく、一連の閾値の問題を尋ねるほうが賢明です：

1. 問題の重要性

この問題は「クリティカル・ミッション・レベル」（人命、国家安全保障、数十億ドル）なのか、「ほんのおまけ」（10〜20% の効率向上）なのか？賭けが高いほど、フロントライン展開モデルがより適切になります。

2. 顧客の集中度

あなたは数十の巨大な顧客に販売していますか、それとも何千もの小さな顧客ですか？組み込みエンジニアリングは、集中し、高い ACV（年間契約価値）の顧客グループでよりよく展開します。

3. 領域のフラグメンテーション

お客様間の作業フローは類似していますか？使用されているソフトウェアツールは同じですか？それとも、展開ごとにまったく異なりますか？各顧客がユニークな場合、一貫したプラットフォームを構築することが困難です。ある程度の均質性が役立ちます。

4. 監督とデータの引力

過度に規制された領域や、データ統合の課題が顕著な領域（国防、医療、金融犯罪、重要インフラ）でビジネスを展開していますか？それでこそ、Palantir スタイルの統合作業が本当の価値を生み出すことができる場所です。

これらの次元の左下に多くを占める場合（重要度が低い、フラグメンテーションされた顧客、比較的単純な統合）、包括的な「Palantir 化」はほぼ間違いないパターンです。そのような状況は、ボトムアップ型のPLG（Product-Led Growth）アプローチにより適しています。

学ぶべきこと

すべての初期段階の企業がPalantirのようなモデルを成功裏に展開できるとは疑問ですが、このアプローチには考慮に値する要素がいくつかあります：

1. 最前線の展開を足場として、家屋としてではなく

次のアプローチが完全に正しい場合があります：

・エンジニアを初期のデザインパートナーとして組み込む

・最初の3〜5つの顧客を生産環境に参入させるためにあらゆる手段を講じる

・これらのパートナーシップを活用して、あなたのプリミティブと抽象を圧力テストする

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

・タイムボックス付きデプロイメント（たとえば、「プロダクションへの90日間のスプリント」）

・明確なスケール（たとえば、「個々の顧客あたりの100万ドルのARRごとに最大何人のエンジニアを割り当てるか」）

・カスタムコードを毎四半期、再利用可能な構成やテンプレートに変換することを目指す

さもなければ、「後で製品化します」という言葉は「私たちは結局やる時間がありません」になってしまいます。

2. 強力なプリミティブに基づいて構築すること、カスタムワークフローに頼らないこと

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

・統一されたデータモデルと権限レイヤー

・汎用のワークフローエンジンとUIプリミティブ

・コードではなく、可能な限り構成を使用する

フロントライン展開チームは、各顧客に新しいものを構築するのではなく、「選択」と「検証」に時間を費やすべきです。新規構築はエンジニアに任せます。

3. FDE を製品の一部にし、単なるデリバリーに留めない

Palantir の世界では、フロントライン展開エンジニアは製品の発見とイテレーションに深く関与し、単なる実装だけでなくなっています。強力な製品組織とプラットフォームチームは、FDE が第一線で学んだ内容を栄養素として受け取ります。

FDE が独立した「プロフェッショナルサービス」部門にいる場合、このフィードバックループを失い、純粋なサービス企業に滑り落ちてしまいます。

4. 粗利構造に対して正直であれ

もしもあなたのピッチがソフトウェアの粗利率が80％以上で、純収益率が150％を想定しているとしても、実際には長期間のオンサイトプロジェクトが必要な販売モデルである場合、メリットとデメリットのトレードオフについては透明性を保つことが重要です。少なくとも企業内で透明性を持つべきです。

一部のカテゴリにおいて、粗利が低く、ACV が高いモデルは完全に合理的です。問題は、SaaSであるふりをして実際にはプラットフォーム付きのサービス企業であることです。一般的に、投資家は絶対価値で最大の粗利に向かうパスを見ますが、これを実現する方法の1つが、より大きな契約規模に加えてより大きな COGS（販売費用）です。