F-18: ビルド vs バイ¶

この相反は何か¶

AI エージェントシステムの各コンポーネント（LLM ランタイム、オーケストレーションフレームワーク、ベクトルデータベース、ガードレール、モニタリングなど）を構築する際、「自社で開発・運用するか（ビルド）、それとも既製のサービス・プラットフォームを購入・利用するか（バイ）」という二択が F-18 の相反です。

この選択が排他的になる理由は、各コンポーネントの実装主体が自社か外部かで、制御可能性・データ主権・運用責任の所在が根本的に異なるためです。自社開発したコンポーネントはソースコードレベルで制御可能ですが、外部サービスはブラックボックスであり、提供者の仕様変更や障害に依存します。中間はありません---あるコンポーネントのコードを自社が所有しているか、外部サービスとして利用しているかは、明確に二値です。

AI エージェントの文脈でこの相反が特に重要な理由は、AI/LLM エコシステムの変化速度が極めて速く、今日のベストプラクティスが半年後に陳腐化する可能性があるためです。自社開発に過度に投資するとエコシステムの進化についていけなくなるリスクがあり、外部サービスに過度に依存すると制御を失うリスクがあります。この速度の不確実性が、ビルド vs バイの判断を従来のソフトウェアよりも複雑にしています。

選択肢A：ビルド（自社開発）¶

ビルドとは、自社のエンジニアリングチームがコンポーネントを設計・実装・運用する方式です。LLM ランタイムの自社ホスティング、カスタムオーケストレーションフレームワークの開発、独自のベクトルデータベースの構築・運用などが該当します。

ビルドの最大の強みは制御とデータ主権です。コードレベルでの完全な制御が可能なため、自社のユースケースに最適化した実装ができます。データが自社のインフラから出ないため、データ主権・プライバシー・規制への準拠が確保しやすくなります。外部サービスの仕様変更、価格改定、サービス停止のリスクから解放されます。

また、差別化要因となりうるコンポーネントについては、ビルドすることで競合優位性を確立できます。エージェントの中核的な推論ロジック、業界固有のガードレール、独自のメモリアーキテクチャなど、事業の差別化に直結する部分は外部に依存しない方が長期的な競争力につながります。

弱点は開発速度とエンジニアリングコストです。AI/LLM エコシステムは急速に進化しており、自社開発で追従するには相当なエンジニアリングリソースが必要です。ベクトルデータベースの性能最適化、LLM 推論の高速化、ガードレールの最新攻撃手法への対応など、専門性の高い課題を自社で解決し続ける必要があります。

さらに、車輪の再発明のリスクがあります。既に成熟した外部サービスが存在するコンポーネントを自社で開発すると、品質が及ばないだけでなく、本来の事業価値を生む開発にリソースを割けなくなります。

選択肢B：バイ（外部サービス利用）¶

バイとは、既製のサービス・プラットフォーム・フレームワークを購入・利用してコンポーネントを構成する方式です。LLM API（OpenAI、Anthropic、Google）の利用、マネージドベクトルデータベース（Pinecone、Weaviate Cloud）の採用、SaaS 型エージェントプラットフォームの利用などが該当します。

バイの最大の強みは速度と専門性の活用です。既に成熟したサービスを利用するため、開発開始から本番稼働までの時間が大幅に短縮されます。サービス提供者は該当分野の専門チームを擁しており、性能最適化、セキュリティ対応、スケーリングなどの専門的な課題を継続的に解決しています。自社で同等の品質を達成するには、それ以上のエンジニアリング投資が必要になります。

また、運用負荷が低減されます。インフラのスケーリング、パッチ適用、障害対応などの運用タスクがサービス提供者に委ねられるため、自社のチームは事業価値を生む開発に集中できます。

弱点は依存とロックインです。外部サービスの仕様変更（API の破壊的変更、価格改定、機能の廃止）に対して受動的な立場に置かれます。サービス障害時には自社で対応できる範囲が限られます。また、データが外部サービスに送信されるため、データ主権やプライバシーの観点で制約が生じる場合があります。

さらに、差別化の困難さがあります。同じ外部サービスを競合も利用するため、サービスの利用自体では差別化になりません。差別化はサービスの上に構築するアプリケーション層で実現する必要があります。

選定基準¶

この相反の選定は [cost_sensitivity] と [accountability] の二つの駆動変数で決まります。

ビルドを選ぶべき条件：

[accountability] が高く、データ主権が必須な場合。金融、医療、政府系など、データを外部に送信できない規制要件がある環境です。
そのコンポーネントが事業の差別化に直結する場合。競争優位性の源泉となるロジックは外部に依存しない方が長期的に有利です。
外部サービスの制約（レート制限、カスタマイズ不可、SLA 不足）が事業要件を満たさない場合。
十分なエンジニアリングリソース（人員・専門性・予算）が確保できる場合。

バイを選ぶべき条件：

[cost_sensitivity] が高く、エンジニアリングリソースが限られている場合。特にスタートアップやMVP段階では、開発速度が生存に直結します。
そのコンポーネントがコモディティであり、差別化に寄与しない場合。ベクトルデータベースの運用やログ管理などは、多くの場合バイの方が合理的です。
エコシステムの変化が速く、自社実装が陳腐化するリスクが高い場合。LLM の進化速度を考えると、ランタイム層のビルドは数ヶ月で無駄になる可能性があります。
[provider_trust] が十分に高い場合。サービス提供者の可用性、継続性、セキュリティに対する信頼が確保できる場合です。

デフォルトとハイブリッド¶

デフォルト：抽象化層を介してバイで開始するのがデフォルトです。初期段階では開発速度を優先し、外部サービスを利用して素早くプロトタイプを構築・検証します。ただし、外部サービスとの接続点に抽象化層（インターフェース/アダプターパターン）を設け、将来の差し替えを可能にしておきます。

ハイブリッド：ランタイム抽象化により差替可能な構成が最も実用的な折衷案です。具体的には以下の方針を取ります。

バイ：LLM API、ベクトルデータベース、ログ/モニタリング基盤など、コモディティ化が進んだインフラ層
ビルド：業務ロジック、オーケストレーション、ガードレールポリシー、ドメイン固有の検証ロジックなど、差別化に直結するアプリケーション層
抽象化層：両者の接続点に薄いインターフェースを設け、ビルドへの移行やプロバイダ変更を低コストで実現

A6 Adaptive Timeout & Budget-Bounded Retry パターンのリトライ戦略やフォールバック構成は、マルチプロバイダ対応の抽象化層と組み合わせて機能します。

判断を誤ったときの症状¶

ビルドを選んだがバイが適切だった場合の症状：

エンジニアリングチームがインフラコンポーネントの開発・保守に時間を取られ、事業価値を生む機能の開発が遅延しています。
自社実装のコンポーネントの品質（性能、信頼性、セキュリティ）が、同等の外部サービスに及んでいません。
エコシステムの進化（新しいモデル、新しい技術）への対応が遅れ、競合に後れを取っています。
インフラの運用障害（スケーリング問題、パフォーマンス劣化）への対応に追われています。

バイを選んだがビルドが必要だった場合の症状：

外部サービスの制約（レート制限、カスタマイズ不可）が事業の成長を阻害しています。
外部サービスの仕様変更や価格改定に振り回され、頻繁なマイグレーション作業が発生しています。
データを外部に送信できないユースケースが増え、サービスの適用範囲が制限されています。
競合と同じサービスを使っているため、差別化ができず価格競争に陥っています。
外部サービスの障害時に自社では何もできず、SLA 違反が顧客に転嫁されています。