この記事で扱うこと
AIエージェントを本番導入する際、チームは「自社開発か、SaaS購入か、外部パートナーか、OSS流用か」という選択に直面します。この記事では、この判断をアーキテクチャとガバナンスの観点から整理します。具体的には、以下の観点を扱います。
- 各調達手段（Build / Buy / Partner / Borrow）が向くユースケースと技術的トレードオフ
- レイヤー単位で調達元を分ける「ハイブリッド調達」の設計パターン
- 調達元が混在した環境で必要なエージェントレジストリ、相互運用性標準、リスクベース分類、共通ガバナンス
経営論ではなく、システム設計・API連携・権限・監査・運用に落とし込める内容を目指します。
なぜ調達戦略がアーキテクチャ問題なのか
AIエージェントは単なるAPI呼び出しではありません。プロセスロジック、コンテキストデータ、ツール連携、監査証跡を内包する実行単位です。この実行単位をどこから調達するかは、以下のアーキテクチャ特性を直接決定します。
- 制御境界：エージェントの動作をどこまでカスタマイズ・監査できるか
- データ境界：コンテキストや決定ログがどの環境で処理・保存されるか
- 依存方向：ベンダーのロードマップ変更やOSSのメンテナンス停止にどの程度影響を受けるか
- 運用負荷：自前で評価ハーネスやライフサイクル管理を構築する必要があるか
この選択を誤ると、以下の3つの落とし穴にハマります。
- 早期ベンダーロックイン：プロセスロジックや監査をベンダーに委ね、出口コストが高騰
- エージェントサイロ化：部門ごとに異なる調達元・評価基準・ガバナンスでカオス化
- 無限プロトタイピング：自前フレームワークの構築に終始し、本番ユースケースが一向に出てこない
Build：制御が競争優位になる領域
Buildが適切な条件：エージェントが扱うロジックが自社の競争優位の中核であり、プロプラエタリなデータや判断ルールに深く依存する場合。または、高い監査要件やランタイム制御が必要な場合。
具体的な判断基準
- 差別化ロジック：保険の引受判断、独自の価格エンジン、サプライチェーンの運用知能など、買って済ませると競争力が毀損する領域
- 高機密データ・重要制御：リスク判断、顧客の保護データ、財務制御ロジックなど、データ境界を自社環境内に閉じたい領域
- 深い監査性とポリシー制御：エージェントが使用したコンテキスト、呼び出したツール、判断理由、エスカレーション経路を完全に追跡・説明する必要がある領域
技術的に必要な基盤
Buildを選ぶなら、以下の基盤が整っていることが前提です。
- エージェントプラットフォームパターン：オーケストレーション、ツール呼び出し、メモリ管理の共通基盤
- API統合の健全性：内部システムとのAPI連携が標準化・管理されていること
- データガバナンスの成熟度：データの権限、保存期間、監査ログの管理が確立していること
- モデルリスクレビュー：LLMの出力品質・バイアス・安全性を評価するプロセス
- 運用モデル：エージェントの所有・改善・廃止を担当するチームとライフサイクル管理
これらの基盤がないままBuildに突入すると、プロトタイプが本番に到達せず、無限プロトタイピングの罠に陥ります。
Buy：速度と引き換えにする制御の限界
Buyが適切な条件：機能が比較的コモディティ化しており、SaaSやエンタープライズプラットフォームとして成熟している領域。差別化にならない業務。
- サービスデスクアシスタント
- CRM内蔵の営業エージェント
- 従業員セルフサービスエージェント
- ナレッジアシスタント
購入前に確認すべき技術的チェックポイント
| 観点 | 確認事項 |
|---|---|
| データ境界 | どのデータがベンダー環境に送信されるか。コンテキストはどこで処理されるか。ログの保存場所と保持期間。 |
| 監査性 | エージェントの決定を説明できるか。アクセス制御はどのように適用されるか。監査ログのエクスポート形式。 |
| カスタマイズ限界 | 推論ロジック、メモリ管理、ランタイムポリシー制御をどこまで変更できるか。複雑な例外処理に対応できるか。 |
| 出口戦略 | 対話データのエクスポート可否。プロンプトや設定の移行可能性。ツール連携が独自形式に依存していないか。価格改定やロードマップ変更への影響。 |
Buyの最大のリスクは、気づいたら構造的依存になっていることです。契約前に出口戦略を明確にしておかないと、後戻りできなくなります。
PartnerとBorrow：現実的な中間領域
Partner：知見と実行力を借りる
Partnerが適切な条件：価値領域は明確だが、実装パターンや運用準備が整っていない場合。特に、以下のような状況で有効です。
- グローバルキャパシティセンター（GCC）が財務業務のエージェント化を推進したいが、運用モデルやガバナンスの設計経験がない
- 特定ドメイン（例：購買発注の自動化）で初めてのエージェント導入であり、リファレンスアーキテクチャが欲しい
Partnerを選ぶ際の契約上の必須条項：
- IP帰属：共同開発したエージェントの知的財産権
- データ利用制限：パートナーによる自社データの二次利用禁止
- 運用モデルとSLA：誰が何を運用するか、サービスレベル目標
- 監査権：パートナーのセキュリティ・データ取扱いを監査する権利
- ナレッジトランスファー計画：段階的に内製化するための移行計画
Partnerは「責任を委譲する」のではなく「実行力を加速する」手段です。契約が曖昧だと、ソフトウェアベンダーからサービスベンダーへの依存先変更にしかなりません。
Borrow：学習速度を優先する
Borrowが適切な条件：本格的なプラットフォーム決定の前に、オーケストレーションパターンやツール呼び出しの要件を検証したい場合。
具体的な活用例：
- 購買チームが「発注依頼を読み取り、ポリシーをチェックし、契約データを参照し、承認パスを準備する」エージェントを試したい
- LangChainやLlamaIndexなどのOSSフレームワークを使って、コンテキストレイヤーの設計を短期間でプロトタイピング
Borrowの限界：
- コンポーネントの品質とセキュリティは玉石混交
- 長期的な所有権が不明確
- OSS依存関係の管理負荷が増大
- プロトタイプが本番に昇格せず、プロトタイピングの沼にハマるリスク
Borrowはあくまで探索パスです。標準化を遅らせる理由にしてはいけません。
ハイブリッド調達を管理する4つの仕組み
現実の大企業では、Build / Buy / Partner / Borrow が混在します。問題は混在そのものではなく、共有アーキテクチャとガバナンスなしに混在が拡大することです。以下の4つを整備してください。
1. エージェントレジストリ（カタログ）
全エージェントを管理するカタログ。最低限、以下を記録します。
- エージェント名とID
- ビジネスオーナーとテクニカルオーナー
- 調達元（Build / Buy / Partner / Borrow）
- 使用データとツール
- リスクレベル（後述）
- ライフサイクルステータス（実験中 / 本番 / 廃止予定）
レジストリなしでは、エージェントのポートフォリオを管理できません。
2. 相互運用性標準
異なる調達元のエージェントが同じエコシステムで動作するための標準。
- ID管理：エージェントの認証・認可（OAuth2 / OIDC ベース）
- ツール呼び出し：OpenAPI スキーマに準拠したツール定義
- イベント：エージェント間・エージェント→人間のハンドオフイベントの標準形式
- ロギング・観測可能性：共通のログスキーマ、トレースID、メトリクス
- 評価：エージェントの出力品質を評価する共通ハーネス
これらの標準がないと、エージェントはすべて島になります。
3. リスクベース分類
すべてのエージェントに同じ制御をかけるのは非効率です。リスクとビジネス影響度で分類し、比例した制御を適用します。
| リスクレベル | 例 | 必要な制御 |
|---|---|---|
| 低 | 社内FAQアシスタント | 基本的なセキュリティレビュー、利用ログ |
| 中 | 購買発注提案エージェント | データ権限設定、承認ワークフロー、監査ログ |
| 高 | 財務決済エージェント | モデルリスクレビュー、ポリシーエンジン、完全監査証跡、人的承認必須 |
4. 共有ガバナンス
調達元が何であれ、本番投入するエージェントは共通のガバナンスプロセスを通過する必要があります。
- セキュリティレビュー
- データパーミッション設定
- 評価（オフライン評価＋本番モニタリング）
- 承認閾値の設定
- 観測可能性（ログ、メトリクス、アラート）
- インシデント管理
- 廃止プロセス
調達元は異なっても、エンタープライズ標準は共通です。
レイヤー単位で調達元を分ける設計パターン
1つのユースケースに対して、1つの調達元を選ぶ必要はありません。以下のようにレイヤー単位で最適な調達元を選べます。
| レイヤー | 例 | 推奨調達元 |
|---|---|---|
| UI・チャットインターフェース | CRMに組み込まれたチャット | Buy（CRMベンダー） |
| オーケストレーション・ポリシー | エージェントのルーティング、承認ワークフロー | Build |
| ドメインロジック | 購買ポリシーの評価、例外処理 | Build または Partner（初期） |
| コンテキストレイヤー | RAGのベクトル検索、プロンプトテンプレート | Borrow（実験）→ Build（本番） |
| 基盤LLM | GPT-4, Claude, Gemini | Buy（API経由） |
「どのレイヤーが差別化領域か」「どのレイヤーがコモディティか」「どのレイヤーを加速すべきか」 という問いが、調達戦略の本質です。
まとめ：ポートフォリオとしてのエージェント調達
AIエージェントの調達戦略は、「BuildかBuyか」の二者択一ではありません。制御・速度・差別化を適切なレイヤーに配置するポートフォリオ判断です。
成熟した企業は、すべてを自前で構築しません。しかし、盲目的に未来を購入もしません。エージェントをエンタープライズ能力のポートフォリオとして管理し、アーキテクチャの規律、ガバナンスの厳格さ、説明責任を適用します。
最初の一歩として、自社のエージェントレジストリを作り、現状の調達元を可視化することから始めてください。