AIエージェント Build vs Buy フレームワーク | Harvey/JPMorgan事例で分かる6軸意思決定と4象限判断フロー【2026年版】

エンタープライズAIエージェントの導入を検討するCIO・情シス責任者・DX推進担当が必ず直面するのが「内製（Build）か外製（Buy）か」という意思決定だ。LLMの世代交代サイクルが5〜6週間まで短縮された2026年において、この判断を誤るとTCOの跳ね上がりか差別化の機会損失か、どちらかのコストを確実に払うことになる。本稿では、Harvey・JPMorgan LLM Suiteをはじめとする世界8社の事例を分解し、日本エンタープライズが使えるフレームワークとして整理する。

#なぜBuild vs Buy判断がAIエージェント導入の最重要ゲートか

AIエージェント導入には3つの構造的難しさがある。第一に、LLMは平均5〜6週間ごとに進化するため、フルスクラッチで内製した場合「最新モデルへの追従」という終わりなき保守が発生する。第二に、3年TCOの予測が極めて難しい。GPU・APIコストの急落と人件費・運用コストが逆方向に動くため、1年目の見積もりと3年目の実績が大きく乖離する事例が続出している。第三に、「差別化の源泉になる機能」と「汎用機能」を区別せずに全部Buyまたは全部Buildすると、どちらの方向でも過剰投資と過剰依存のリスクが生まれる。このゲートを正しく通過した企業だけが、次のステップ（AIエージェント導入ステップ）に進める。

#Buy型成功事例4社：Harvey・Cognition Devin・Sierra・Salesforce Agentforce

#Harvey（法務AI）：$11Bバリュエーションが証明するドメイン特化Buy型の完成形

Harvey AIは2026年3月に$200M Series D調達（GIC・Sequoia共同リード）、バリュエーション$11B、ARR $190M（2026年1月時点）を達成した法務特化AIプラットフォームだ。10万人以上の弁護士、1,300組織にサービスを提供し、25,000以上のカスタムエージェントが契約分析・デューデリジェンス・M&Aを自律実行している。HarveyがBuy型で成功した理由は明確で、法律事務所は自社でLLMを内製する必要がない。コアの差別化は「法務ドメイン知識の深さ」と「クライアント機密データのガバナンス」であり、その両方をプラットフォームとして提供するHarveyに乗ることで差別化と速度を両立できた。

#Cognition Devin（開発AI）：Goldman Sachsが採用したハイブリッドワークフォース

Cognition（評価額$10.2B、2025年9月）が提供するDevinは自律型AIソフトウェアエンジニアリングエージェントだ。Goldman Sachsはこれを「ハイブリッドワークフォース」として採用し、開発ライフサイクル全体でAIと人間エンジニアが協働する体制を構築している。Goldman Sachsが純粋なBuildを選ばなかったのは、エンジニアリングの差別化がLLMの実装にあるのではなく「金融ドメイン固有の業務ロジックとリスク管理」にあると判断したためだ。

#Sierra（CX AI）：5週間導入→1.5週間でフル展開を実現した$175M調達の破壊力

Sierraは元Salesforce Co-CEOのBret Taylorらが設立したカスタマーエクスペリエンスAIエージェントプラットフォーム（ARR $100M、2025年11月達成）。$175MのBain Capital主導調達を経て、2026年4月には東京拠点のOpera Techを買収し日本市場参入を加速した。Nordstromの事例では「5週間で導入、1.5週間で通話の1%から100%にスケール」という高速展開を実現。Sierraがエンタープライズに選ばれる理由は、カスタマー対応というドメインでのBuy型導入がPoC→全社展開の最短経路になるからだ。

#Salesforce Agentforce（CRM AI）：CEO「billion agents」宣言と2026 Q2 GA拡大

2024年Dreamforceで発表されたAgentforceは、2026年Q2にAtlas Reasoning Engineの性能向上と機能拡大を伴うGA拡大フェーズに入った。CEO Marc Benioffが「billion agents」宣言で示したように、CRMデータをネイティブに活用した営業・サービス自動化の文脈ではAgentforceは最も摩擦の少ないBuy型選択肢だ。一方でCRMデータ以外の対話データ（商談音声・会議録・面談記録）の構造化活用には別の基盤が必要になる点は第7節で詳述する。Salesforce Agentforceとaileadの組合せについても参照のこと。

#Build型成功事例4社：JPMorgan・ソフトバンク・みずほ・製薬

#JPMorgan LLM Suite：23万人が日次利用する$1.5B ROIの内製AI基盤

JPMorgan Chase LLM Suiteは、AWS基盤の上に構築された社内AIプラットフォームで、230,000人の従業員が日次利用し、$1.5B超のROIを計上している（2024〜2026 Phase 2）。2027年からはPhase 3「Agentic AI」に移行し、450以上のエージェンティックユースケースを段階的に展開する計画だ。JPMorganがBuildを選んだ判断の核心は「金融データは最高機密であり、第三者LLMへの委託リスクが許容できない」という一点だ。金融機関として規制当局への説明責任を果たすためには、モデルの動作・データの流れ・意思決定の根拠を完全にコントロールできる内製基盤が必要だった。

#ソフトバンク Sarashina：Oracle Alloy基盤でデータ主権を確保

ソフトバンクは2026年6月からの順次提供を予定しているOracle Alloy採用のCloud PF Type Aで、国産LLM「Sarashina」を軸に自社AI基盤を構築している。データが物理的に自社管理インフラ内に留まる構成により、通信キャリアとして保有する顧客データの取り扱いに関する規制・コンプライアンス要件を満たしながらAI活用を進める戦略だ。

#みずほ銀行：面談記録作成時間70%以上削減の実績

みずほ銀行は自行の業務プロセスに即したAIエージェントを内製展開し、面談記録作成時間の70%以上削減という定量成果を公開事例として開示している。金融機関における顧客情報保護の観点から、商談・面談データを外部SaaSに委託することは困難であり、Build型が自然な選択となった。

#製薬業界のフェデレーテッドラーニング：機密データのBuild型活用

製薬企業においては、競合他社と原材料や臨床データを外部に出せないという制約から、フェデレーテッドラーニング（分散学習）を活用したBuild型AIエージェントが実装されている。データが組織の外に出ることなくモデルを共同学習できるこのアーキテクチャは、規制・秘密保持制約の強い業界でのBuild型の典型例だ。

#6軸意思決定フレームワーク

Buy・Build・Hybridの3択を6軸で評価するフレームワークを示す。各軸でBuyに寄せる条件とBuildに寄せる条件を明確にすることで、意思決定を構造化できる。

#日本エンタープライズ向け4象限判断フロー

上記6軸を踏まえ、以下のYes/Noディシジョンツリーで判断象限を特定できる。

• Q1. 核となる差別化要素か？ → Noなら Pure Buy象限へ。Yesなら次へ。
• Q2. 機密データの第三者委託が許容されるか？ → Noなら Pure Build象限へ。Yesなら次へ。
• Q3. 3年TCOで Build < Buy × 1.5 に収まるか？ → Noなら Pure Buy象限へ。Yesなら次へ。
• Q4. 保守・反復・所有能力が社内にあるか（またはロードマップにあるか）？ → Noなら Open Source + Fine-Tune象限へ。Yesなら Platform Buy + Workflow Build象限へ。

4象限の定義は以下のとおりだ。

• Pure Buy：差別化要素でなく、委託可能で、TCO的にもBuyが合理的な汎用機能（例：汎用チャットボット、FAQ自動応答）
• Pure Build：機密データを外に出せず、かつその機能が差別化の核心で、内製能力もある場合（例：JPMorgan LLM Suite、ソフトバンク Sarashina）
• Open Source + Fine-Tune：差別化はしたいが内製能力が限定的な場合、OSS LLMをファインチューニングして最低限のコントロールを確保する中間策
• Platform Buy + Workflow Build：LLM・オーケストレーション基盤はBuy、ドメイン固有スキーマ・ガードレール・UIはBuildで組み合わせる2026年の主流パターン

AIエージェントのガバナンス設計と組み合わせると、この4象限の判断をより具体的な設計に落とし込める。

#ハイブリッド戦略「Platform Buy + Workflow Build」の実装パターン

2026年のエンタープライズAIエージェントで最も現実的な実装パターンは「Platform Buy + Workflow Build」だ。典型的な構成は以下のとおりだ。

• Platform層（Buy）：OpenAI API / Anthropic Claude API / Azure OpenAI → LLM基盤を外部調達
• オーケストレーション層（Buy or OSS）：LangGraph / MCP / Semantic Kernel → エージェント間の調整、ツール呼び出し制御
• Workflow・スキーマ層（Build）：ドメイン固有の業務ロジック、評価基準、入出力スキーマを自社で定義
• ガードレール・UI層（Build）：ロールベースアクセス制御、監査ログ、社内データとの接合、エンドユーザーUI

このパターンの核心は「LLMは外部調達しても、ドメイン知識のスキーマ定義と業務ルールは内製する」という原則だ。LLMが5〜6週間で更新されても、Workflow層のスキーマとガードレールは自社資産として蓄積・進化させることができる。エンタープライズAIエージェント評価基準でプラットフォーム選定の詳細を確認しておくことも有益だ。

#aileadが提供する「Buy + 対話データ構造化」ハイブリッドの位置づけ

対話データの活用に課題を感じていないか。aileadは「Platform Buy + Workflow Build」の実例として、LLM基盤を活用しながら「対話データのStructureスキーマ」を自社で定義・管理する設計で動作する。商談・面談・会議の音声データを 営業・人事採用・経営の各ドメインに応じた構造化スキーマで整理し、AIエージェントが評価・レコメンド・SFA連携・タスク起票を自律実行する。SFA入力工数90%削減、新人営業の立ち上がり期間50%短縮を実現した企業が400社以上。ISO/IEC 27001:2022取得済みで国内データセンター完結の運用も可能だ。お問い合わせ（エンタープライズRFP）

#PoC→部門展開→全社展開のロードマップと失敗パターン3選

意思決定の軸が定まったら、実装フェーズに移行する。典型的なロードマップは次の3段階だ。

• Phase 1（PoC、1〜3ヶ月）：1部門・1ユースケースに絞って検証。Buy型なら既存SaaSのトライアルで2〜4週間で結果を出す。Hybrid型ならWorkflow層のスキーマ設計とLLM APIの接合をプロトタイプで検証する
• Phase 2（部門展開、3〜6ヶ月）：PoCで検証したパターンを3〜5部門に拡大。セキュリティ審査・SSO連携・ログ管理の本格実装が必要になる
• Phase 3（全社ロールアウト、6〜18ヶ月）：ガバナンス体制（AIオーナー、利用ポリシー、監査フロー）を整備し、部門横断でエージェントを展開する

このロードマップで頻発する失敗パターンが3つある。

#失敗パターン①：Pure Build罠

全スタックを内製しようとしてLLM更新サイクルに追いつけず、エンジニアが保守に忙殺されて新機能開発が止まる。特にフルスタック内製を志向した場合、「最新モデルに移行するたびにプロンプト・スキーマを全部作り直す」コストが予測の3〜5倍になる事例が多い。AIエージェント構築ガイドではこのトレードオフを詳細に解説している。

#失敗パターン②：Buyの差別化埋没

汎用SaaSを導入したが競合も同じツールを使っており、差別化の源泉にならない。特に「競合他社が使っていないか」という観点でのベンダー選定を怠ると、買収・模倣・コモディティ化のリスクが高まる。

#失敗パターン③：ハイブリッドの管理コスト爆発

Platform BuyとWorkflow Buildの境界が不明確なため、両方のベンダー管理・セキュリティ審査・コスト最適化が複雑化して運用負荷が当初想定の3倍になる。この罠を避けるには「どこまでがBuyの責任領域でどこからがBuildの責任領域か」を設計初期に文書化することが必要だ。AIエージェント実行フェーズ2026で実装段階の詳細を確認してほしい。

#次のステップ：選定後のRFP10項目チェックリスト

Build vs Buyの方針が決まり、Buy型またはHybrid型でベンダーを選定する段階に進んだら、以下の10項目をRFPに必ず含めることを推奨する。

1. SSO連携：SAML 2.0 / OIDC対応、既存IdP（Azure AD等）との統合可否
2. セキュリティ認証：ISO/IEC 27001、SOC2 Type2（参考）等の認証取得状況と審査報告書の開示可否
3. データ処理委託契約（DPA）：APPI・GDPR準拠のDPA締結可否
4. ログ保持期間：監査ログの保持期間と形式（SIEM連携可否）
5. ロールベース権限管理：部署・役職・閲覧制限の粒度
6. 監査API：操作ログの外部出力APIの有無
7. SLA：稼働率保証（99.9%以上）とインシデント対応時間
8. 撤退時のデータ持ち出し：契約終了時のデータエクスポート形式と期限
9. データ保存リージョン：国内データセンター完結の可否
10. アップデートへの追従：LLMモデル更新時のユーザーへの影響範囲と通知プロセス

営業AIエージェント完全ガイド（RFP連携）ではBuy型AIエージェントのRFP詳細テンプレートも提供している。また、対話データガバナンス2026では対話データの取り扱いに関する詳細なガバナンス設計フレームワークを解説している。

#まとめ：2026年の実装解は「Platform Buy + Workflow Build」

Build vs Buyの議論はLLM時代に入って構造が変わった。以前のようにゼロから全部作る「Pure Build」は、LLMの進化速度に追いつくコストが膨大になり、特殊な事情（データ主権・規制・巨大TCO規模）がない限り現実的でなくなった。一方で「Pure Buy」だけでは、自社のコアビジネスに固有のドメイン知識とデータを差別化に活かせない。Harvey・Sierra・Agentforceに代表されるBuy型成功企業は、ドメイン特化したプラットフォームを選ぶことで差別化と速度を両立した。JPMorgan・ソフトバンク・みずほに代表されるBuild型成功企業は、機密データのガバナンスと規制対応という制約条件の中で内製の合理性を確保した。2026年の大多数のエンタープライズに当てはまる現実解は、LLMとオーケストレーション基盤を外部調達（Platform Buy）しながら、ドメイン固有スキーマ・ガードレール・UIを内製する「Platform Buy + Workflow Build」ハイブリッドだ。6軸フレームワークと4象限判断フローを使って自社の意思決定を構造化し、RFP10項目でベンダー選定の精度を上げてほしい。

aileadは対話データをAIで構造化し、営業・人事採用・経営の業務を自動化するエンタープライズ基盤だ。「Platform Buy + Workflow Build」の実装例として、自社の対話データ活用の可能性をデモで確認してほしい。エンタープライズRFP相談・無料デモを申し込む

#よくある質問

（上記frontmatterのfaqsセクションに記載）

#関連記事

• 営業AIエージェント完全ガイド（RFP連携）
• AIエージェントのガバナンス設計
• エンタープライズAIエージェント評価基準
• AIエージェント導入ステップ
• 対話データガバナンス2026
• AIエージェント社内稟議・承認プロセスガイド
• AIエージェント実行フェーズ2026
• AIエージェント構築ガイド
• Salesforce Agentforceとaileadの組合せ
• 対話データとAIエージェント