SaaS AI機能のBuy vs. Build: 実際に機能する意思決定フレームワーク

Build対Buyの問いはソフトウェアの世界で数十年前から存在しています。AIバージョンのこの問いは表面上は似ていますが、答えを変える構造的な違いがあります。

その違いは第3の選択肢「Wrap」です。

OpenAI、Anthropic、GoogleのLLM(大規模言語モデル)APIは2022年以前には存在しなかった道を開きました。モデルを訓練することなく、MLエンジニアなしに、数百万ドルのデータインフラ投資なしにAI機能を構築できます。APIを呼び出し、適切に設計されたプロンプトとコンテキストを渡すと、インテリジェントな出力が得られます。魔法ではありませんが速く、ほとんどのSaaSプロダクト表面にとって正しい出発点です。

古典的なBuy対Buildの枠組みはこれを見逃しています。「AIを構築する」とは「データサイエンティストを雇用してデータでモデルを訓練する」ことを意味していた時代のために設計されているからです。それはまだ選択肢のひとつです。ただもはや唯一の選択肢ではありません。Series C以下のほとんどのSaaS企業にとっては、それは間違った選択肢です。

つまり本当の決断は3択です。Buy、Wrap、またはBuild。

Buy/Wrap/Build Decision

Buy/Wrap/Build DecisionはSaaS AI機能に特化した3択フレームワークです。Buyは専用のAIベンダー製品を購入してワークフローに統合します。デプロイが速く、差別化に限界があり、ベンダー依存があります。Wrapは自社のプロダクト表面にAI機能を構築するためにLLM APIを直接使用します。中程度の速度、中程度のコスト、体験とコンテキストをコントロールするため大きな差別化の可能性があります。BuildはカスタムモデルをトレーニングまたはFine-tuneします。最大の差別化の上限、最大のコスト、最大の時間、MLの才能が必要です。ほとんどのSaaS企業はWrapをスキップしてBuyとBuildのみを評価します。ARR $50M未満のほとんどのプロダクト内AI機能にとって、Wrapが正しい出発点です。

3つの選択肢の定義

Buy: 専用のAIベンダー製品を購入してワークフローに統合します。セールスコール分析のGong、CSヘルススコアリングのGainsightまたはVitally、サポートデフレクションのIntercom Fin。デプロイが速い。本番実績あり。差別化の余地が限られている。

Wrap: OpenAI、Anthropic、またはGoogle LLM APIを直接使用して、自社のプロダクトまたはオペレーションツール内にAI機能を構築します。自社のコード、自社のUI、彼らのモデル。構築の速度は中程度、中程度のスケールでの中程度のコスト、体験をコントロールするため大きな差別化の可能性があります。

Build: 独自のモデルをトレーニングまたはFine-tuneします。カスタムMLパイプライン。独自訓練データ。最大の差別化の上限、最大のコスト、最大の時間、MLの才能が必要。AIが真にコアプロダクトの差別化要因であり、データが堀を生み出す場合に限定されます。

ほとんどのSaaSチームが「AIを構築すべきか?」と言うとき、暗黙的にBuildについて尋ねています。ほとんどの場合、正しい答えはWrapから始めて、データと競合状況によってBuildが実際に正当化されるかどうかを確認することです。

Key Facts: SaaS AIのBuy vs. Buildの経済性

• 中程度の複雑さのAIエージェントをゼロから構築するには最低3〜5ヶ月かかります。BuyまたはWrapアプローチでは数週間で市場投入できます(Ptolemay LLM TCO Research, 2025)
• エージェント型AIアーキテクチャを完全に社内で構築しようとする企業の4分の3が失敗します。これらのアーキテクチャには洗練されたRAGスタック、高度なデータパイプライン、そしてステージ3以前のほとんどのSaaSチームが持っていないニッチなML専門知識が必要だからです(Forrester, 2025)
• AIへの平均月間支出は2024年の$63,000から2025年の$85,500に36%増加し、月間AIに$100,000以上を費やす予定の企業の割合は同じ期間に2倍以上になりました(Binadox, 2025)

いつBuyすべきか

Buyが正しい答えなのは、ユースケースが十分に理解されており、既存のベンダーで十分に対応されており、差別化より価値実現までの時間が重要な場合です。

セールスコール分析はほとんどのSaaS企業にとってBuyのユースケースです。Gongは何年もかけてAIコールスコアリングを磨いており、何百万ものセールスコールで訓練されたモデルを持ち、すべての主要CRMと統合しています。独自のコール分析AIを構築しても競争力は上がりません。すでに機能するものを再発明しながら価値を遅延させるだけです。パターン別Buy vs. Buildでは、評価するすべてのAI Capabilityに一貫して適用できるよう、すべてのACEパターン全体でこの決断をマッピングしています。

AIチャットボットによるサポートデフレクションも同様です。Intercom Fin、Zendesk AI、同様の製品はサポート解決のために調整された強力なモデルを持っています。彼らのAIはあなたの顧客だけでなく、すべての顧客のサポートインタラクションから改善されます。サポートボット用にLLM APIをラップした場合、彼らが何年もトレーニングデータを持っている間、モデルをゼロからスタートさせることになります。

ルール: ユースケースが標準化されており、ベンダーが新鮮なLLM API呼び出しより実際のトレーニングデータの優位性を持ち、このユースケースの差別化が顧客の選択を左右しない場合はBuyを選択してください。

顧客はサポートチャットボットが独自の個性を持っているからあなたのSaaSプロダクトを選んでいるわけではありません。コアのプロダクト能力のために選んでいます。サポートAIはBuyして、AIエンジニアリングの時間を重要なところに投資してください。

Buyのコストプロファイル: 中堅市場SaaSの場合、ツール1本あたり年間$15,000〜$80,000。10ツールでのBuyの決断は意味のある予算項目です。しかし予測可能であり、維持するためのエンジニアリング人員を必要としません。

いつWrapすべきか

Wrapが正しいのは、自社のプロダクト表面にAIが必要で、ユースケースが汎用ベンダーツールに合わない程度に特化しており、カスタムモデルの訓練を正当化するほどの独自データをまだ持っていない場合です。

プロダクト内AI Copilotは典型的なWrapのユースケースです。SaaSがプロジェクト管理ツールで、ユーザーがタスクの説明を下書きし、依存関係を自動提案し、ステークホルダー向けにプロジェクトステータスを要約するAIアシスタントを追加したい場合、自社のデータモデルにこれを正確に行うベンダーはいません。構築する必要がありますが、モデルをトレーニングする必要はありません。LLM APIをWrapします。データベースからコンテキストを渡し、プロンプトを慎重に設計し、UIでアウトプットを処理します。SaaS製品UIに埋め込まれたAI Copilotでは、Build/Wrapの選択に続くプロダクト設計の決断を説明しています。

Wrapはまた、自社プロダクトのユースケースに特化したワークフローのAI機能にも適しています。SaaSツールが法律文書プラットフォームで、AIに潜在的に問題のある契約条項をフラグ立てしてほしい場合、契約法に関してモデルをトレーニングする必要はありません。条項評価フレームワークを含む適切に設計されたシステムプロンプトでClaudeまたはGPT-4をWrapします。バージョン1は数ヶ月ではなく数週間でリリースできます。

ルール: 機能がプロダクトのコンテキストを必要とし、どのベンダーも適合する既製ソリューションを持たず、チームにカスタムモデルを構築するMLの専門知識やデータがない場合はWrapを選択してください。

Wrapのコストプロファイル: これはチームが驚くところです。使用量が少ない場合のLLM API価格は些細なものです。スケールすると違います。

OpenAIのGPT-4oは入力トークン100万あたり$2.50、出力トークン100万あたり$10です。安く聞こえます。10,000 MAU(月間アクティブユーザー)がそれぞれ月に20回のAI補完をトリガーし、呼び出しごとに平均2,000入力トークンと500出力トークンとして計算してみましょう。

• 月間入力: 10,000 x 20 x 2,000 = 4億トークン x $2.50/M = $1,000
• 月間出力: 10,000 x 20 x 500 = 1億トークン x $10/M = $1,000
• 月間LLMコスト: $2,000

管理可能です。しかし100人のパワーユーザーが20回ではなく500回の補完を実行し、プロンプトが5,000トークンで出力が2,000トークンの場合:

• 月間入力: 100 x 500 x 5,000 = 2.5億トークン x $2.50/M = $625
• 月間出力: 100 x 500 x 2,000 = 1億トークン x $10/M = $1,000

それでも管理可能です。本当のリスクはAI機能を定額料金(使用量制限なし)で価格設定しており、95パーセンタイルユーザーをモデル化していない場合です。使用量の上限を構築していなければ、200人のアクティブユーザーがそれぞれ毎日100回の補完を実行する1社のエンタープライズ顧客がAPI費用として月$40,000〜$60,000のコストをかける可能性があります。

WrapはDay 1からの消費アーキテクチャを必要とします。ユーザーごとのレート制限、使用量ダッシュボード、定額料金ティアの消費上限はオプションの後付け機能ではありません。

AnthropicとGoogleの価格設定は同様のパターンに従い、2026年時点でClaude 3.5 Sonnetは入力$3/M、出力$15/Mです。計算はモデルの選択によって大きく変わりません。アーキテクチャの要件は同じです。

いつBuild(実際に構築)すべきか

カスタムモデルの構築が正当化されるのは、3つの条件がすべて同時に真である場合です。

1. データがベンダーが汎用トレーニングデータで再現できない防御可能な優位性を生み出している
2. AI機能がプロダクトの差別化のコアである(顧客が部分的にはそれが理由で自社を選んでいる)
3. 会社にMLエンジニアリングの才能があるか採用できる

3つの条件のいずれかが偽の場合、Wrapがより良い選択です。

SaaSのデータ堀の条件が最も重要です。プロダクトがスケールで独自の行動データを生成する場合、そのデータはモデルトレーニングの資産です。GitHubにはコード補完においてこれがありました。何百万人もの開発者のコードリポジトリ、それぞれのコミット履歴、コードレビューのフィードバック、そして作者コンテキストです。どの競合もそのデータセットを購入できませんでした。Copilotの品質は部分的にGitHubの独自のデータポジションの関数です。

ほとんどのSaaS企業はSeries AまたはBではその堀を持っていません。500〜5,000の顧客がいます。彼らのデータはプロンプト設計とRAG(Retrieval-Augmented Generation)検索に価値がありますが、適切にプロンプトされたベースモデルに対してFine-tunedモデルを意味のある形で改善するほど大きくも独自でもありません。データ堀が存在する前に構築することは、Wrapより悪い結果を得るためにエンジニアリングリソースを燃焼させることです。

ルール: 独自データがスケールでラッピングでは再現できないモデル品質を生み出し、その品質が顧客が代金を払う理由である場合にBuildを選択してください。

Buildのコストプロファイル: 初期コストだけではありません。モデルにはメンテナンスが必要です。データパイプラインにはモニタリングが必要です。世界が変化しトレーニングデータが古くなるにつれてモデルのパフォーマンスは低下します。初期モデルを構築するために採用したチームは、今そのメンテナンス、モニタリング、再トレーニングの責任があります。これはBuyとWrapが課さない継続的な運用コストです。ForresterのAI時代におけるBuild vs. Buyの分析では、エージェント型AIアーキテクチャを完全に社内で構築しようとする企業の4分の3が失敗することを指摘しています。これらのアーキテクチャには洗練されたRAGスタック、高度なデータパイプライン、そしてステージ2または3のほとんどのSaaSチームが持っていないニッチなML専門知識が必要だからです。

ARR $20M未満では、AIが文字通りプロダクトでない限りこのコスト構造を正当化することは難しいです。強力なデータ堀の証拠を持つARR $50M以上では、正しい投資になり得ます。

考慮すべき隠れたリスク

各選択肢には初期の予算見積もりに現れないコストがあります。

Buyの隠れたコスト: ベンダー依存。Gainsightが価格モデルを変更すると(それは起きます)、CS運用予算はあなたの関与なしに変わります。Gongが構築したワークフローの機能を廃止すると、そのワークフローを再構築します。より重要なことは: AIの改善はベンダーのモデルで複利的に蓄積され、自社のモデルでは蓄積されません。Gongを通じて処理するすべてのセールスコールはGongのモデルを訓練し、自社のモデルを訓練しません。彼らのプロダクトを良くしているのです。成熟度ステージ4では、Buyするときにデータ堀が構築されないため、これが重要になります。AIベンダーロックイン軽減戦略では、Buy決断においても柔軟性を守る方法を説明しています。

Wrapの隠れたコスト: モデルの廃止。OpenAIはGPT-4 32kといくつかの他のモデルを6〜12ヶ月の通知で廃止しました。ラッピングアーキテクチャが特定のモデルバージョンに密結合されている場合、マイグレーションは意味のあるエンジニアリングプロジェクトです。正しいアーキテクチャはモデルを抽象化レイヤーの背後にWrapし、AI機能コードを書き直すことなく基盤となるモデルを交換できるようにします。

Buildの隠れたコスト: 初期コストだけではありません。モデルにはメンテナンスが必要です。データパイプラインにはモニタリングが必要です。モデルのパフォーマンスは世界が変化しトレーニングデータが古くなるにつれて低下します。初期モデルを構築するために採用したチームが、今そのメンテナンス、モニタリング、再トレーニングの責任を負います。これはBuyとWrapが課さない継続的な運用コストです。

「ステージ1でBuildに直接飛び込む企業は、MLエンジニアリングに$800,000を費やして、月$200のAnthropic APIサブスクリプションが生み出したであろうものより劣るCopilotを手に入れます。GTM AIツールはBuyしてください。プロダクトAIにはLLM APIをWrapしてください。独自データ堀のユースケースのためにBuildは取っておいてください。」(Rework分析, 2025)

「モデルの廃止はWrapのチームが予算計上しない隠れたコストです。OpenAIはGPT-4 32kといくつかの他のモデルを6〜12ヶ月の通知で廃止しました。ラッピングアーキテクチャが特定のモデルバージョンに密結合されている場合、マイグレーションは意味のあるエンジニアリングプロジェクトです。正しいアーキテクチャはモデルを抽象化レイヤーの背後にWrapし、AI機能コードを書き直すことなく基盤となるモデルを交換できるようにします。」(Rework分析, 2025)

Buy vs. Wrap vs. Build: 意思決定マトリクス

出典: Forrester Build vs. Buy in the Age of AI 2025、Ptolemay LLM TCO Research 2025、Vendasta Build vs. Buy AI Analysis 2026

Rework分析: SaaS AI投資で最も高コストな失敗は、データ堀が存在する前にカスタムモデルを構築することです。ほとんどのSeries A-B企業は500〜5,000の顧客を持っています。彼らのデータはプロンプト設計とRAG検索に価値がありますが、適切にプロンプトされたベースモデルに対してFine-tunedモデルを意味のある形で改善するほど大きくも独自でもありません。3つの条件(防御可能なデータ優位性、コアプロダクトの差別化要因、利用可能なMLの才能)をすべて確認する前にBuildを評価するチームは、Wrapが生み出すより悪い結果のためにエンジニアリング資本を燃焼させています。まず2つの質問テストを実施してください。この機能には自社の特定のコンテキストとデータが必要か? これは顧客が自社を選ぶ理由か、それとも彼らが高く評価するが代替品と比較評価しないサポート機能か?

決断を下すための意思決定フレームワーク

最もシンプルなバージョンは2つの質問テストです。

1. このAI機能は、汎用ベンダーソリューションより意味のある向上を得るために、自社の特定のコンテキストとデータを必要とするか?
2. このAI機能は顧客が自社プロダクトを明示的に選ぶ理由になっているか、それとも代替品と比較評価しないながらも高く評価するサポート機能か?

質問1の答えがノーなら: Buy。 質問1の答えがイエスで質問2がノーなら: Wrap。 両方がイエスで、データと才能がある場合: Build。

具体的なシナリオに適用してみましょう。

フレームワークはどの選択をすべきかを教えてくれます。シーケンシングはいつかを教えてくれます。

実際に機能するシーケンシング

成熟度ステージ2〜3のほとんどのSaaS企業にとって:

1. 最初の6ヶ月でGTM(Go-to-Market)AIツール(Gong、Gainsight、Intercom AI)をBuyしてください。自社のコンテキストでAI支援の良い結果がどのように見えるかについてデータを収集してください。
2. ステージ2から始まってプロダクト内AI機能のためにLLM APIをWrapしてください。ステージ4までプロダクトにAIを追加するのを待たないでください。
3. 18〜24ヶ月のユーザー行動データ、明確なデータ堀の仮説、そしてMLの人員コストをサポートするARRが得られたステージ4でBuildを評価してください。

ステージ1でBuildに直接飛び込む企業は、MLエンジニアリングに$800,000を費やして、月$200のAnthropic APIサブスクリプションが生み出したであろうものより劣るCopilotを手に入れます。OpenViewのSaaS使用量ベース価格設定のベンチマークによると、ネットドル保持率が最も強い企業は、データ量が正当化する前に独自モデルを構築しようとするのではなく、GTM向けにベストインクラスのAIツールをBuyし、プロダクトAIにはAPIをWrapした企業であることが多いと示しています。

GTM AIはデフォルトでBuy。プロダクトAIはデフォルトでWrap。独自データ堀のユースケースのためにBuildは取っておく。そしてデータが蓄積されるにつれて再評価してください。

---

関連記事:

• パターン別Buy vs. Build: 各ACEパターンにわたる決断のマッピング
• Build vs. Buy vs. Integrate Decision: AIインフラの戦略レベルの意思決定フレームワーク
• AIベンダーロックイン軽減戦略: Buy決断において柔軟性を守る方法
• SaaS AIの成熟度ステージ: Buy/Wrap/Buildの決断がステージ全体でどのようにシフトするか
• SaaS製品UIに埋め込まれたAI Copilot: Wrapの選択に続くプロダクト設計の決断
• SaaS AIの競争: Speed to Ship: Build/Buyの決断の競合タイミングコンテキスト