著者: マーク・アンドルスコ
編集:Deep Tide TechFlow
Deep Tide Insights:「Palantir 化」のトレンドがシリコンバレーを席巻しています。AI スタートアップ企業は、エンジニアをクライアントのサイトに派遣し、高度にカスタマイズされたサービスを提供し、7 桁の契約を締結することで、Palantir を模倣しています。
a16zのパートナーであるマーク・アンドルスコ氏は、このアイデアに冷水を浴びせました。ほとんどの企業は表面的な模倣に過ぎず、最終的にはSaaS企業を装ったコンサルティング会社になるだろう、と。この記事では、パランティアモデルの真に模倣可能な側面を分析し、単なる美しい幻想に過ぎない部分を明らかにします。
メインテキストコンテンツ:
最近のスタートアップのビジネスプランでよく使われるフレーズは、「私たちは基本的に、X 分野の Palantir です」です。
創業者たちは、「前方展開エンジニア」(FDE)をオンサイト・クライアントに派遣し、高度にカスタマイズされたワークフローを構築し、従来のソフトウェア企業ではなく特殊部隊のような運営を行うことに熱心に取り組んでいます。今年、「前方展開エンジニア」の求人数は数百パーセント増加し、2010年代初頭にパランティアが先駆者となったモデルを、各社が模倣しています。
このアプローチが魅力的な理由は理解できます。企業顧客は現在、「どのソフトウェアを購入すべきか」というジレンマに悩まされています。あらゆるものがAIを謳い、シグナルとノイズを区別することがかつてないほど困難になっています。Palantirの販売手法は魅力的です。少人数のチームを混沌とした環境に送り込み、自社構築のサイロ化された様々なシステムを接続し、数ヶ月以内にカスタマイズされた作業プラットフォームを提供するのです。最初の7桁の受注を目指しているスタートアップにとって、「エンジニアを貴社に派遣し、業務を遂行します」という約束は非常に魅力的です。
しかし、「パランティア化」が一般的な手法として広く採用されるかどうかは極めて疑問です。パランティアはまさに「カテゴリー・オブ・ワン」です。株価の推移を見れば一目瞭然です。表面的な部分を模倣するだけの企業の多くは、最終的には高額なサービス企業となり、複合的な競争優位性も築かずにソフトウェアの時価総額を何倍にも膨らませることになります。これは、あらゆるスタートアップが「プラットフォーム」を標榜しながらも、真のプラットフォーム企業は構築が困難だったため極めて稀だった2010年代を彷彿とさせます。

この記事の目的は、Palantir モデルの真に移植可能な部分と、独自性があり複製不可能な部分を明確にし、エンタープライズ ソフトウェアとハイタッチ サービスを組み合わせたいと思っている創業者に、より実用的なロードマップを提供することです。
「パランティリゼーション」とは具体的に何を意味するのでしょうか?
「パランティリゼーション」は、相互に関連するいくつかの事柄を指すようになりました。
最前線の組み込みエンジニアリング
最前線の導入エンジニア(Palantir社内では「Delta」および「Echo」と呼ばれています)が顧客組織に常駐し(通常数ヶ月間)、ビジネスシナリオの理解、各種システムの接続、Foundryプラットフォーム(または高セキュリティ環境の場合はGothamプラットフォーム)上でのカスタムワークフローの構築を行います。料金は固定料金であるため、従来の意味での「SKU」は存在せず、エンジニアがこれらの機能の構築と維持に責任を負います。
高度にアサーティブな統合プラットフォーム
高度にアサーティブな統合プラットフォーム
Palantirの製品は、本質的には単なるツールキットではなく、データ統合、ガバナンス、そして運用分析という明確な目的を持つプラットフォームです。組織データの「オペレーティングシステム」とも言えます。その目標は、断片化されたデータをリアルタイムかつ信頼性の高い意思決定へと変換することです。
ハイエンド、ハイコンタクトの販売モデル
「パランティライゼーション」とは、営業スタイルの一種でもあり、ミッションクリティカルな環境(防衛、法執行、諜報など)を対象とした、長期にわたるハイタッチな営業サイクルを指します。規制の複雑さと業界の「賭け」の規模の大きさは、バグではなく、むしろ特徴です。
ライセンスではなく結果を販売します。
収益は、複数年にわたる成果ベースの契約、ソフトウェア、サービス、そして継続的な最適化の組み合わせから得られます。1人のクライアントとの契約で、年間数千万ドルに達することもあります。
最近の分析では、パランティアは3つの点で同時に優れているため、「ユニークなカテゴリー」に分類されています。(a) 統合型製品プラットフォームの構築、(b) 顧客オペレーションへの優秀なエンジニアの配置、(c) ミッションクリティカルな政府・防衛環境における実績です。ほとんどの企業はこれらのうち1つか2つを実現できますが、3つすべてを同時に実現できるわけではありません。
しかし、2025年までに、誰もがこのモデルの恩恵を受けようとした。
なぜ今、誰もが Palantir を真似したがるのでしょうか?
3つの力が収束しています。
1. エンタープライズ AI は「実装」という課題に直面しています。
AIプロジェクトの多くは、データの乱雑さ、統合の難しさ、社内リーダーシップの欠如などが原因で、本番環境に到達する前に行き詰まってしまいます。AI導入への意欲は依然として高いものの(取締役会や経営幹部から「AI導入」を求めるトップダウンの圧力が実際にかかっています)、実際の導入とROIの実現には、多くの実践的な作業が必要となることがよくあります。
2. 最前線の展開エンジニアが、欠けている橋渡し役となっているようです。
メディアの報道や採用データによると、AI スタートアップ企業がエンジニアを採用して導入を真に実現可能にしているため、FDE (ソフトウェア エンジニア) のポジションが今年爆発的に増加しており、さまざまな情報源によると 800% ~ 1000% の増加を示しています。
3. 急速な成長が標準となっている (7 桁の契約を締結すると、5 桁の契約を締結するよりも迅速に規模を拡大することが容易になります)。
フォーチュン500企業や政府機関から100万ドル以上の受注を獲得するために、エンジニアを飛行機で現地に派遣しなければならないとしたら、多くのアーリーステージ企業は、勢いを得るために粗利益率を犠牲にする覚悟です。また、新しいAI体験にはしばしば多大な推論コストがかかるため、投資家は粗利益率の低下をますます受け入れるようになっています。重要なのは、クライアントの経営陣と信頼を勝ち取り、「結果」を提供し、それに応じた価格設定ができるかどうかです。
そこで、ストーリーはこうなりました。「パランティアと同じことをしよう。エリートチームを派遣して素晴らしいものを作り、時間をかけてそれをプラットフォームに変えるのだ。」

この話は、非常に特殊な状況下ではうまくいくかもしれません。しかし、創業者がしばしば見落としがちな、厳しい制約がいくつかあります。
この類推はどこで失敗するのでしょうか?
初日から、「結果」を売ることが目標でした。
Palantirの主力製品であるFoundryは、数百のマイクロサービスが連携して単一の成果を達成するものです。これらのマイクロサービスは、様々な業種に共通する企業課題に対する、製品化された、確固としたソリューションを形成します。過去2年間で数百人のAIアプリケーションの創業者と面会してきた経験から、このアナロジーがどこに当てはまるのかをはっきりと理解しています。スタートアップ企業は壮大な成果重視の目標を掲げて参入してきますが、Palantirは自社の中核となるコンピテンシーの礎となるマイクロサービスを意識的に構築しています。これがPalantirと一般的なコンサルティングファームの違いであり、株価が来年度の売上高の77倍で取引されている理由でもあります。
Palantir には次のようなコア製品があります。
- Palantir Gotham: 軍隊、諜報機関、法執行機関が任務計画と調査のために断片化されたデータを統合および分析するのを支援する防衛および諜報プラットフォーム。
- Palantir Apollo: あらゆる環境 (マルチクラウド、ローカル、オフライン) に更新と新機能を自律的かつ安全にプッシュするソフトウェア展開および管理プラットフォーム。
- Palantir Foundry: データ、モデル、分析を統合してビジネス運用上の意思決定を促進する、業界横断的なデータ運用プラットフォーム。
- Palantir Ontology: 現実世界のエンティティ、関係、ロジックを整理し、Foundry 内のアプリケーションと意思決定を強化する、動的で実用的なデジタル モデルです。
- Palantir AIP (人工知能プラットフォーム): Ontology を通じて AI モデル (大規模言語モデルなど) を組織のデータおよび運用に接続し、生産性の高い AI 駆動型ワークフローとエージェントを作成します。
エベレストのレポートは次のように述べています。「Palantirとの契約は小規模から始まります。当初の協業は、短期間のブートキャンプと限定的なライセンス契約にとどまるかもしれません。価値が実証された場合にのみ、より多くのユースケース、ワークフロー、データドメインが追加されます。時間の経過とともに、収益構造はサービスからソフトウェアサブスクリプションへと移行します。コンサルティング会社とは異なり、サービスは製品の普及を促進する手段であり、主要な収益源ではありません。多くのソフトウェアベンダーとは異なり、Palantirは有望な顧客を獲得するために、エンジニアリングに先行投資する意思を持っています。」
一方で、私が今目にするAIアプリケーション企業は、7桁の契約にすぐに飛びつくことが多い。しかし一方で、これは主に彼らが完全カスタマイズモードにあるためだ。彼らは初期のクライアントから提起されたあらゆる問題を解決し、そこからコア機能、つまり「SKU」を構築するためのテーマを見つけ出そうとしているのだ。
すべての問題が「Palantir」レベルの問題というわけではありません。
パランティアの初期の導入は、テロ対策、不正行為検知、戦場の物流、高リスクの医療活動など、代替手段が「機能しない」分野を対象としていました。問題解決の価値は、効率性の漸進的な向上ではなく、数十億ドル、救われた命の数、あるいは地政学的な影響といった単位で測られました。
中規模のSaaS企業に販売し、営業プロセスを8%最適化する支援をした場合、同レベルのカスタマイズ導入を行う余裕はありません。ROIは、数ヶ月に及ぶオンサイト作業に耐えられるものではありません。
ほとんどのクライアントは、永遠にあなたの R&D ラボであり続けたいとは思っていません。
Palantir の顧客は、同社とともに進化する製品をデフォルトで受け入れている。リスクが高く、代替手段がほとんどないため、多くのことを許容しているのだ。
ほとんどの企業、特に防衛・規制分野以外の企業は、長期的なコンサルティングプロジェクトに携わっているという感覚を好みません。予測可能な実装、既存のソフトウェアツールとの相互運用性、そして迅速な結果を求めています。
人材密度と文化は一般化できない
パランティアは10年以上にわたり、本番環境で使用可能なコードを書き、官僚的なシステムを難なく操作し、大佐、CIO、規制当局と同じ部屋で話せる、非常に優秀なジェネラリストエンジニアを採用・育成してきました。この役割を離れた人々は、創業者と幹部からなる「パランティアマフィア」を形成しました。これらの人材の多くは、高度な技術力と顧客対応力を兼ね備えているため、まさにユニコーンと言えるでしょう。
ほとんどのスタートアップ企業は、そのような人材を数百人雇用できるとは考えていません。実際には、「PalantirのようなFDEチームを構築する」という考えは、しばしば次のような結果に陥ります。
- プリセールス ソリューション エンジニアは現在、「FDE」と呼ばれています。
- ジュニア ジェネラリストは、製品、実装、顧客管理を同時に処理する必要があります。
- 経営陣はパランティアの展開を間近で見たことはなかったが、雰囲気は気に入った。
世の中には非常に優秀な人材が数多く存在し、Cursorのようなツールによって非技術系の従業員でもコードを書けるようになっていることを明確にしておく必要があります。しかし、Palantirモデルを大規模に機能させるには、ビジネスと技術の両面を兼ね備えた非常に稀有な人材が必要です。Palantirは非常にユニークな企業であるため、実際にそこで働いた経験があれば非常に有利です。しかし、このグループに所属できる人材の数は限られています。
サービストラップは現実です。
サービストラップは現実です。
Palantirが成功しているのは、カスタム作業の裏に真のプラットフォームがあるからです。エンジニアの真似だけをすると、メンテナンスやアップグレードが不可能なカスタムデプロイメントが何千も生み出されてしまいます。AIツールによってこのモデルでソフトウェアレベルの粗利益を達成できるようになったとしても、フロントエンドのデプロイメントに過度に重点を置き、強力な製品基盤を欠く企業は、規模の経済性と持続可能な競争力を生み出せない可能性があります。
無差別投資家は、契約額が 0 ドルから 1,000 万ドルまでホッケースティックのように急激に増加するのを見て、殺到するかもしれません。しかし、私が常に抱いている疑問は、数十社 (あるいは数百社) の 1,000 万ドル規模の新興企業が、まったく同じ売り込みで互いにぶつかり始めたらどうなるかということです。
その時までに、あなたは「X 分野の Palantir」ではなく、「X 分野の Accenture」になるでしょう。ただ、フロントエンドがもっと美しいだけです。
Palantir は実際に何を正しく行ったのでしょうか?
神話を取り除けば、詳細に検討する価値のある要素がいくつかあります。
1. プロジェクト優先ではなくプラットフォーム優先
Palantir の最前線の導入チームは、顧客ごとに完全にカスタマイズされたシステムを作成するのではなく、再利用可能なプリミティブ (データ モデル、アクセス制御、ワークフロー エンジン、視覚化コンポーネント) の小さなセットに基づいて構築します。
2. 仕事が「どのように」行われるべきかについて明確な意見を持っている。
この会社は既存のプロセスを自動化するだけでなく、顧客に新しい働き方を積極的に提案しており、ソフトウェア自体もその姿勢を体現しています。これはベンダーとしては稀有な勇気であり、再利用を可能にします。
3. 長期ビジョンと資本
Palantir のような企業になるには、プラットフォームと販売モデルが成熟するにつれて、長期にわたる否定的な感情、政治的論争、そして短期的な収益化の不確実性を乗り越える必要があります。
4. 非常に特殊な市場構成
諜報・防衛分野への早期導入は、欠点ではなく、特徴的な点でした。高い購入意欲、高い切り替えコスト、大きなリスク、そしてごく少数の超大手クライアント。そして、数十年にわたりほぼ競争なしで契約を獲得してきた旧来の競合企業群の存在も言うまでもありません。
言い換えれば、Palantirは単なる「ソフトウェア会社+コンサルティング」ではありません。「ソフトウェア会社+コンサルティング+政治プロジェクト+極めて忍耐強い資本」なのです。
これは、単に任意の垂直 SaaS 製品に移植するだけでは一般化できないものです。
より現実的な枠組み: 「パランティライゼーション」はいつが合理的か?
「どうすれば Palantir のようになるのか」と尋ねる代わりに、一連のハードルを設定する質問をします。
1. 問題の重大性
これは「ミッションクリティカル」な問題(人命、国家安全保障、数十億ドル規模の問題)でしょうか、それとも「あれば便利」な問題(10~20%の効率向上)でしょうか? リスクが高ければ高いほど、最前線での展開モデルはより合理的になります。
2. 顧客集中
数十の大規模クライアントに販売していますか?それとも数千の小規模クライアントに販売していますか?組み込みエンジニアリングは、ACV(年間契約額)の高い集中したクライアントベースでより効果的に拡張できます。
3. ドメインの断片化の程度
異なるクライアントのワークフローは似ていますか?同じソフトウェアツールを使用していますか?それとも、それぞれの導入は全く異なりますか?すべてのクライアントがばらばらだと、一貫性のあるプラットフォームを構築するのは困難です。ある程度の均一性は重要です。
4. 規制とデータ誘致
防衛、医療、金融犯罪、重要インフラなど、データ統合に重大な課題を抱える、規制の厳しい分野で事業を展開していますか?Palantirのような統合の取り組みは、まさにその分野で真の価値を生み出すことができます。
これらの側面の左下隅(重要度が低い、顧客が分散している、統合が比較的容易)にほぼ当てはまる場合、完全な「パランティライゼーション」アプローチはほぼ間違いなく間違ったモデルです。このような状況には、ボトムアップ型のPLG(プロダクト主導の成長)戦略がより適しています。
学ぶ価値のあることは何でしょうか?
これらの側面の左下隅(重要度が低い、顧客が分散している、統合が比較的容易)にほぼ当てはまる場合、完全な「パランティライゼーション」アプローチはほぼ間違いなく間違ったモデルです。このような状況には、ボトムアップ型のPLG(プロダクト主導の成長)戦略がより適しています。
学ぶ価値のあることは何でしょうか?
すべての初期段階の企業が Palantir モデルをうまく導入できるとは思えませんが、このアプローチには検討する価値のある側面がいくつかあります。
1. 最前線での展開を建物ではなく足場として扱う。
次のアプローチは完全に正しい可能性があります。
- エンジニアが組み込みシステムの初期設計パートナーと連携できるようにする
- 当社は、最初の 3 ~ 5 社の顧客を本番環境へ導入するために、費用を惜しみません。
- これらのコラボレーションを使用して、プリミティブと抽象化のストレス テストを実行します。
ただし、明確な制約が必要です。
- 期間限定の展開(例:「90 日間の実稼働スプリント」)
- 明確な割合(例:「ARR 100 万ドルあたり、クライアント 1 人あたりのエンジニアリング スタッフ数」)。
- 目標は、四半期ごとにカスタム コードを再利用可能な構成またはテンプレートに変換することです。
そうしないと、「将来製品化します」が「まだ時間が取れていません」になってしまいます。
2. カスタム ワークフローではなく、強力なプリミティブに基づいて構築されています。
Palantir の本当の教訓は製品アーキテクチャにあります。
- 統合データモデルと権限レイヤー
- 一般的なワークフローエンジンとUIプリミティブ
- 可能な限り、コードではなく構成を使用します。
最前線の導入チームは、顧客ごとに全く新しいものを構築するのではなく、どのプリミティブを組み立てるかを選択し、検証することに時間を費やすべきです。新しいビルドはエンジニアに任せましょう。
3. FDE を単なる配信メカニズムではなく、製品の不可欠な部分にします。
Palantirの世界では、最前線の導入エンジニアは、実装だけでなく、製品の発見とイテレーションにも深く関わっています。強力な製品組織とプラットフォームチームは、FDEが最前線で学んだことを基にインスピレーションを得ています。
FDE が別の「プロフェッショナル サービス」部門にある場合、このフィードバック ループが失われ、純粋なサービス企業になってしまいます。
4. 粗利益構造について正直になりましょう。
提案書ではソフトウェアの粗利益が 80% 以上、純収益保持率が 150% であると想定しているが、実際の販売モデルでは長期のオンサイト プロジェクトが必要な場合は、少なくとも社内ではトレードオフについて透明性を確保してください。
特定の製品カテゴリーにおいては、構造的に低マージンで高ACVのビジネスモデルは完全に合理的です。問題は、SaaS企業を装いながら、実際にはプラットフォームを持つサービス企業である点にあります。投資家は通常、絶対的な粗利益の最大化を目指しますが、これを達成する一つの方法は、より大規模な契約と、それに伴う大幅に高い売上原価(COGS)を組み合わせることです。
「Palantir 化された」スタートアップにストレステストを行うにはどうすればよいでしょうか?
創設者が私に「私たちは X ドメインの Palantir です」と言ったとき、私のノートには次のような質問が書かれていました。
- 明確なプラットフォームの境界を示してください。共有製品はどこで終わり、顧客固有のコードはどこから始まるのでしょうか?この境界はどのくらいの速さで変化するのでしょうか?
- 導入のタイムラインを教えてください。契約締結から最初の本番稼働まで、何人のエンジニア(何ヶ月)が必要ですか?また、どのような部分をカスタムメイドで対応する必要がありますか?
- 成熟顧客の3年目の粗利益率はどのくらいですか?最前線への導入への投資は時間の経過とともに「大幅に」減少しますか?そうでない場合、その理由は何ですか?
- 来年50社の顧客と契約したら、どこで問題が起きるでしょうか?採用?新入社員研修?製品?サポート?ビジネスモデルのどこで破綻するかを見たいのです。
- カスタマイズを「ノー」と決めるにはどうすればいいでしょうか?カスタマイズを「ノー」と決めるかどうかは、製品を提供する企業と「美しいデモを提供するサービス企業」との違いを決める重要な要素となることがよくあります。
これらの答えが明確で、実際の展開に基づいており、アーキテクチャ的に一貫している場合、ある程度の Palantir スタイルの最前線展開は実際に有利になる可能性があります。
答えが曖昧であったり、各コラボレーションが明らかに独自のものである場合、再現性や真のスケーラビリティの可能性を保証することは困難です。
結論
答えが曖昧であったり、各コラボレーションが明らかに独自のものである場合、再現性や真のスケーラビリティの可能性を保証することは困難です。
結論
Palantir の成功は、ベンチャー キャピタルのスタートアップ シーンを支配する強力なオーラを生み出しました。エンジニアのエリート チームが複雑な環境に飛び込み、混沌としたデータをつなぎ合わせて、組織の意思決定方法を変えるシステムを提供します。
AIやデータを扱うスタートアップは皆こうあるべきだと考えるのは簡単です。しかし、ほとんどの分野において、完全な「パランティライゼーション」は危険な幻想です。
- 問題はそれほど重大ではない
- 顧客が細分化されすぎている
- 人材モデルは拡張できない
- 経済会計は静かに崩壊し、会社はサービス企業に変わった。
創業者にとって、より有用な質問は「どうすれば Palantir になれるのか?」ではなく、むしろ次のような質問です。
「私たちの分野で AI 導入のギャップを埋めるには、Palantir のような最前線の展開がいくつ必要でしょうか。また、それを真のプラットフォーム ビジネスに変えるにはどのくらいの速さが必要でしょうか。」
これを正しく理解すれば、圧倒される部分を継承するのではなく、このアプローチの本当に重要な部分を活用することができます。
全てのコメント