AI スタートアップの企業契約獲得実態 — Millennium ブライアン・ルイス氏

AI スタートアップが企業契約を勝ち取る「退屈な 60%」の正体： Millennium の製品評価担当者が語る実態

AI スタートアップが企業顧客から契約を獲得するための現実とは、技術的なデモの成功だけではない。Millennium（ヘッジファンド）で製品評価を担当するブライアン・ルイス氏は、現在のモデル知能レベルでは価値の多くが未活用であり、スタートアップ側と企業側の認識ギャップが契約成立率を下げていると分析している。

特にセキュリティ要件や信頼性、そしてガバナンスといった「退屈な 60%」への対応こそが、企業顧客から選ばれ続けるための鍵となるのだ。

デモの壁：5% の契約に至るまでの現実

スタートアップ側にとって、企業顧客との契約獲得は決して簡単な道ではない。ルイス氏によれば、興味深いと見なされた 10〜15 社のスタートアップの中から選別され、デモコールが 2〜3 回行われる。その結果、パイロット（実証実験）に至るのはゼロか一つ程度であり、最終的に契約に至るのは約四分の一だ。

つまり、デモコールの約 5% が最終契約に結びつくという計算になる。これは業界全体のベンチマークと一致する数字だが、多くのスタートアップが「エンタープライズ対応」を謳いながら、企業側の厳格な基準とは乖離しているケースが多いのが実情だ。

「スタートアップ側が『エンタープライズ対応』と主張しても、企業側の厳格な基準とは乖離しているケースが多い。」

契約に至らない理由の多くは、機能の有無ではなく「セキュリティ」や「信頼性」、そして「法的リスク」にある。ルイス氏は、契約獲得プロセスを以下の 4 つの要素に分解して解説する。

1. 有効性（Efficacy）: 40% を占める。製品が実際に課題を解決し、価格モデルが真の価値を反映しているか。
2. セキュリティ: デモ後に脱落する最大の要因の一つ。
3. 信頼性: 運用面での堅牢性が問われる。
4. 法的・コンプライアンス: 契約条件やリスク管理の明確さ。

「エンタープライズ対応」の誤解と、機能開発以外の課題

多くのスタートアップが陥る罠は、「有効性」への過度な集中だ。製品が課題を解決していることは前提だが、企業側が求めるのは「Day 1 に実装可能な統合」や「明確な成功基準の提示」である。

ルイス氏が指摘する典型的な失敗例には以下のようなものがある。

• 虚構（Vaporware）: プラットフォームチームなら 6 週間で再構築できるような機能を、わざわざ外部に頼もうとする提案。あるいは、すでに自社で解決可能な課題に対して「買おう」という提案が成り立たないケース。
• 逆転した価格モデル: 「自社のゲートウェイを介して LLM トラフィックが流れているのに、そのテレメトリデータを報告させてもらい、高いマージンを上乗せしたい」といった理不尽な要求。これは企業側には受け入れられない。
• デモでの約束と現実の乖離: デモでは素晴らしい機能を見せるが、2 ヶ月経っても具体的な導入時期（ETA）を提示できない。
• 過去の拒否事項の再提案: 顧客が既に断った機能を、別の言い回しで再度提案する姿勢。これは「顧客の声を聞いていない」と見なされる。

また、注目すべきはパイロット期間の短縮だ。ルイス氏が Millennium に着任した当初は 6 ヶ月だったパイロット期間が、現在はわずか 2 週間にまで短縮されているという。市場の変化があまりにも急速であるため、企業側は「すぐに結果を出さなければ」というプレッシャーを強く持っている。

セキュリティ要件：ZDR と BYO Gateway が必須となる世界

スタートアップが契約を逃す最大の原因の一つがセキュリティへの対応不足だ。ルイス氏は、セキュリティ担当者が存在しないスタートアップや、明確なインシデント対応計画を持たない企業を評価基準から外すと語る。

企業が求める具体的なセキュリティ要件は以下の通りである。

1. ZDR（Zero Data Retention）と暗号鍵管理

データ保持ゼロ（ZDR）が最優先される。それが不可能な場合でも、顧客管理暗号鍵（Customer-Managed Encryption Keys）への対応が必須だ。しかし、多くのスタートアップは「対応可能」と言いながら、実際に実装すると製品機能が壊れてしまうケースが多い。これは致命的な欠陥と見なされる。

2. BYO Gateway（Bring Your Own Gateway）

企業側は、自社のゲートウェイを介してトラフィックをルーティングしたいと考えている。また、自社クラウドインフラ内でのデプロイや、自社のシステムへの組み込みを望むケースがほとんどだ。

3. SCIM と RBAC の連携（権限管理の再設計）

「エンタープライズでは『退屈な 60%』であるガバナンスと権限体系の再設計が先行して必要となる。」

多くのスタートアップは、新機能を「全員に有効にする」設計になりがちだが、企業側はそうではない。AD（Active Directory）グループや他の権限管理グループを RBAC（ロールベースアクセス制御）と紐付け、SCIM（System for Cross-domain Identity Management）を通じて権限を管理できることが求められる。

また、すべての機能にデフォルトで「読み書き全権限」を与える設計は採用されない。特定のグループに対してのみ、特定の条件下でアクセスを許可する柔軟性が不可欠だ。

4. セキュリティ担当者の存在とインシデント対応

スタートアップ規模が小さい場合でも、少なくとも一人のセキュリティ専門家を雇っていることが求められる。また、「 breach（情報漏洩）が起きたらどうするか」という質問に対し、「まだ起きていないのでわかりません」と答えるのは NG だ。

「 breach が起きたらどうするのか？という問いに『まだ起きていません』と答えるのは、実は『起こった場合の対応策を持っていません』という意味になる。」

信頼性と運用管理：API と監査ログが問う「堅牢性」

AI エージェント時代において、既存の基盤を継承する以上、人間の権限管理の問題は 100 倍に増幅される。そのため、企業側は信頼性（Reliability）と運用管理に対して極めて厳しい目を向ける。

企業が求める運用要件は以下の通りだ。

• 管理画面の API 化: すべての設定変更が API で行えること。
• 監査ログの完全性: 誰が、いつ、何を変更したかを追跡できるログ。深夜に誤操作や、飲み会の後のミスがあった場合でも、その履歴を遡れる必要がある。
• リリース管理とバージョン管理: 頻繁な更新（1 日に数回）により、どのバージョンで不具合が発生したか特定できない状態は許されない。また、サポートドキュメントのバージョン管理も重要だ。契約書にはないリスクが、ウェブサイトのサポートページに「昨日更新」として記載されている場合、企業側はそれを追跡できず、重大なリスクとみなす。
• SLA とサポート体制: 実際の SLA（サービスレベルアグリーメント）の保証と、連絡可能なサポートエンジニアの存在。

ルイス氏は、あるスタートアップが「SSL 証明書が新しいリリースで壊れた」という事象に対し、全社 3,000 人のユーザーが異なるバージョンに分散しているため、原因特定や一斉デプロイができなかった事例を挙げた。これは企業にとって致命的な運用リスクだ。

エージェント時代の権限モデル：「退屈な 60%」への投資こそが競争優位性

AI エージェントの普及により、既存の基盤を継承する以上、人間の権限管理の問題は 100 倍に増幅される。そのため、企業側は信頼性（Reliability）と運用管理に対して極めて厳しい目を向ける。

企業が求める運用要件は以下の通りだ。

• 管理画面の API 化: すべての設定変更が API で行えること。
• 監査ログの完全性: 誰が、いつ、何を変更したかを追跡できるログ。深夜に誤操作や、飲み会の後のミスがあった場合でも、その履歴を遡れる必要がある。
• リリース管理とバージョン管理: 頻繁な更新（1 日に数回）により、どのバージョンで不具合が発生したか特定できない状態は許されない。また、サポートドキュメントのバージョン管理も重要だ。契約書にはないリスクが、ウェブサイトのサポートページに「昨日更新」として記載されている場合、企業側はそれを追跡できず、重大なリスクとみなす。
• SLA とサポート体制: 実際の SLA（サービスレベルアグリーメント）の保証と、連絡可能なサポートエンジニアの存在。

ルイス氏は、あるスタートアップが「SSL 証明書が新しいリリースで壊れた」という事象に対し、全社 3,000 人のユーザーが異なるバージョンに分散しているため、原因特定や一斉デプロイができなかった事例を挙げた。これは企業にとって致命的な運用リスクだ。

エージェント時代の権限モデル：「退屈な 60%」への投資こそが競争優位性

AI エージェントの普及により、既存の基盤を継承する以上、人間の権限管理の問題は 100 倍に増幅される。そのため、企業側は信頼性（Reliability）と運用管理に対して極めて厳しい目を向ける。

企業が求める運用要件は以下の通りだ。

• 管理画面の API 化: すべての設定変更が API で行えること。
• 監査ログの完全性: 誰が、いつ、何を変更したかを追跡できるログ。深夜に誤操作や、飲み会の後のミスがあった場合でも、その履歴を遡れる必要がある。
• リリース管理とバージョン管理: 頻繁な更新（1 日に数回）により、どのバージョンで不具合が発生したか特定できない状態は許されない。また、サポートドキュメントのバージョン管理も重要だ。契約書にはないリスクが、ウェブサイトのサポートページに「昨日更新」として記載されている場合、企業側はそれを追跡できず、重大なリスクとみなす。
• SLA とサポート体制: 実際の SLA（サービスレベルアグリーメント）の保証と、連絡可能なサポートエンジニアの存在。

ルイス氏は、あるスタートアップが「SSL 証明書が新しいリリースで壊れた」という事象に対し、全社 3,000 人のユーザーが異なるバージョンに分散しているため、原因特定や一斉デプロイができなかった事例を挙げた。これは企業にとって致命的な運用リスクだ。

まとめ：技術力だけでなく「堅牢さ」こそが真の競争優位性

生成 AI の普及において、技術的なデモの成功だけでは不十分であることが明確になった。企業顧客から契約を獲得するためには、セキュリティ要件（ZDR、BYO Gateway）、信頼性（API 管理、監査ログ）、そしてガバナンス（権限管理の再設計）といった「退屈な 60%」への対応が不可欠だ。

スタートアップにとっては、機能開発よりもこれらの運用基盤への投資こそが競争優位性の鍵となる。一方、企業側も AI 導入前に既存の権限管理やガバナンス体制を見直す必要性を強く認識させる内容である。技術的な魅力だけでなく、その裏にある「堅牢さ」こそが、AI スタートアップが企業市場で生き残るための唯一の道なのだ。