AIにおける「構築か購入か」という問いは、誤った答えを出しやすいものです。
一方は「ツールを買えばよい。ベンダーがすでに解決している」と言います。もう一方は「独自のAIが必要だ。自社のワークフローは特殊だから」と言います。どちらも正しい場合があります。どちらも、安易に当てはめると高くつく場合があります。
実際の判断は、構築か購入かだけではありません。通常は次のいずれかです。
- ツールを購入する。
- ツールを設定する。
- ワークフロー自動化でツールを拡張する。
- モデルAPIを中心に独自システムを構築する。
- 根拠が十分な場合に限り、自社運用またはファインチューニングを行う。
この記事では、実践的なフレームワークを示します。
システム全体を評価してください。データアクセス、ワークフローへの適合性、検証、権限、連携、モニタリング、人による確認、運用、契約条件、撤退コストまでが対象です。モデルのデモだけで決めてはいけません。
機能の種類から始める
| 機能 | 初期仮説 | 試すべき理由 |
|---|---|---|
| 一般的な文章作成、会議、調査、コーディング支援 | まず購入／設定を試す | 範囲を定めた要件を、複数の候補が満たす場合があるため |
| よくある業務ワークフロー | まず購入／設定を試す | 既存の業務システムが、ガバナンスされた適切な機能をすでに提供している場合があるため |
| ワークフロー固有の自動化 | 拡張と構築を比較する | 統制、信頼性、連携のテスト次第では、ワークフロープラットフォームが適合する場合があるため |
| 社内ナレッジアシスタント | 設定または構築 | 権限と情報源に依存するため |
| 顧客向けエージェント | 慎重に構築／拡張する | ブランド、安全性、連携、ログが重要になるため |
| 規制対象の意思決定支援 | 適格なレビューを先に行い、承認済みの業界向け経路、購入、構築、AIを使わない経路を比較する | 法律、根拠、説明責任、監督の要件が、どのアーキテクチャも除外し得るため |
| 中核製品の差別化 | 所有形態の選択肢を比較する | 所有が優位性を生むかは、顧客と運用の根拠によってのみ判断できるため |
複数のベンダーが要件を満たすなら、購入によって所有・運用の負担を減らせる場合があります。ワークフローが戦略的に重要である、またはベンダー側の不足が実質的である場合は、拡張や構築を正当化できる場合があります。どちらの主張にも根拠を示してください。
4つの意思決定の軸
1. ワークフローへの適合性
ベンダーツールは、実際のプロセスに合わせられますか？
次を確認してください。
- 正式な記録元となる基幹システムにアクセスできますか？
- 自社の承認ルールを適用できますか？
- 例外を扱えますか？
- 監査ログを保持できますか？
- 自社の言語と顧客の期待に対応できますか？
- 利用者は、すでに使っている場所で作業できますか？
チームが毎日ツールを迂回して仕事しなければならないなら、購入価格は実態を表しません。
2. データの管理
どのデータがシステムに入り、どこへ行くのか。
データが公開情報、社内情報、またはそのベンダーでの利用がすでに承認されている場合、購入は容易になります。データが機密情報、規制対象、顧客固有、または厳格なデータ所在地／保持要件の対象である場合は、構築やプライベート環境への導入が選択肢になりやすくなります。
見せかけのプライバシー対策として構築してはいけません。実際のデータルールが求める場合に、構築するか、プライベート環境へ導入してください。
3. 連携の深さ
一部のAIシステムは、正式な記録元となる基幹システムや、処理の実行先へのガバナンスされた接続を通じて価値を生みます。CRM、メール、カレンダー、チケット管理、ERP、文書ストア、データベース、決済、ID、ログなどです。ほかのユースケースは、分離したまま、または読み取り専用にすべきです。
初期仮説としては、標準連携は購入に向き、状態を持つ独自ワークフローは拡張または構築に向く場合があります。代表的な試行では、権限、障害からの復旧、オブザーバビリティ、撤退コストをテストする必要があります。
例：
- 「サポートチケットを要約する」→ 購入／設定。
- 「サポートチケットを振り分け、契約上のSLAを確認し、製品テレメトリを調べ、回答を下書きし、顧客区分に応じて経路を分け、すべての判断を記録する」→ 拡張／構築。
4. 戦略的差別化
競合が同じ機能を入手し、同程度の結果になるよう設定できるなら、その機能だけでは持続的な優位性にならない場合があります。複製されるまでの期間を想定するのではなく、顧客価値と運用上の差別化を測ってください。
汎用ベンダーでは実現できない形で、自社のプロセス、データ、流通、領域の専門知識、顧客体験をシステムに組み込む場合に構築してください。
総所有コスト
ライセンス料と開発時間だけでなく、費用全体を比較します。
| コスト項目 | 購入 | 構築 |
|---|---|---|
| ライセンス／API | 契約に基づくが、席数、使用量、プラン、超過利用で変動し得る | API、推論、インフラ、外部サービス |
| 実装 | 設定、移行、連携、導入時の変更管理 | 製品、連携、プラットフォーム、移行の作業 |
| 保守 | ベンダーがプラットフォーム層の一部を担うが、顧客は設定と連携を引き続き担う | 自社チームが、対象として定めたシステム層と依存関係を担う |
| セキュリティレビュー | ベンダーのデューデリジェンス | アーキテクチャとコードのレビュー |
| 連携 | ベンダーによる制約がある | 柔軟だが高コスト |
| 変更管理 | ベンダーロードマップのリスク | 内部ロードマップの負担 |
| サポート | ベンダーサポート | 内部サポート |
| 撤退コスト | データ／エクスポートの制約 | 技術的負債と所有責任 |
どちらの経路にも、無視できない長期のコストが生じる場合があります。同じ期間を対象に、現在の見積もり、間接費を含む総人件費、移行、サポート、インシデント、撤退シナリオを比較してください。
スコアカード
各軸を1から5で採点し、各点数の意味を定め、ベンダーを評価する前に軸の重みを決めてください。合計点が高くても、セキュリティ、法務、プライバシー、安全性、アクセシビリティ、データ所在地に関する除外条件を覆してはいけません。
| 評価軸 | 点が低いときは購入が有利 | 点が高いときは構築が有利 |
|---|---|---|
| ワークフローの固有性 | 一般的なワークフロー | 固有のワークフロー |
| データの機微性 | 公開／社内 | 機密／要配慮情報 |
| 連携の深さ | 標準連携 | 複数システムにまたがる独自ワークフロー |
| 差別化 | コモディティ | 戦略的優位性 |
| 変更の速さ | ベンダーロードマップで許容できる | 迅速な内部イテレーションが必要 |
| 運用能力 | エンジニアリング要員が少ない、またはいない | チームが本番システムを所有し運用できる |
この記事からリンクしている付属のスコアカードは、再利用できるテンプレートです。試行結果、契約条項、アーキテクチャレビュー、見積もり、ベンチマーク、顧客調査など、すべての点数に根拠を添えてください。
最終候補には、同じ代表的な処理範囲を実装し、タスクの成否、障害からの復旧、人手、レイテンシー、コスト、連携上の制約、権限の挙動、オブザーバビリティ、エクスポート／撤退の経路を記録します。試行後に点数を計算し直してください。
実践的な意思決定ツリー
- ベンダーツールは必須要件を安全に満たしますか？ 購入／設定の候補を試します。
- 残る不足は運用上重要ですか？ 独自構築の前に、自動化で拡張します。
- ワークフローに非公開データ、独自の権限、深い連携が必要ですか？ 法人向けの設定、拡張、薄い独自レイヤー、AIを使わない／手作業の統制を、必須要件に照らして比較します。
- モデルの振る舞い自体を変える必要がありますか？ プロンプティング、決定論的ロジック、検索、制約付き出力など、より単純で適用可能な方法を検討したうえで、候補ごとに評価を行い、その後にファインチューニングを検討します。
- 導入にプライベートな管理が必要ですか？ 品質、コスト、運用を測ったうえで、VPCまたは自社運用を検討します。
上から順に進めてください。デモが戦略的に感じられるという理由だけで、独自インフラへ飛びついてはいけません。
購入が適切な場合
次のときは購入します。
- ワークフローが一般的である。
- ベンダーが既存の構成と連携している。
- データの機微性を扱える。
- 費用が利用量に見合う。
- 価値を得るまでの時間が重要である。
- その機能が差別化要因ではない。
- 独自システムを運用する余力がない。
例：会議の要約、文章作成アシスタント、基本的なサポートマクロ、コーディング補完、営業メールの下書き、承認済み文書を対象とした社内検索。
構築が適切な場合
次のときは構築します。
- ワークフローが事業の中核である。
- ベンダーツールでは必要な統制を強制できない。
- 社内システムとの深い連携が必要である。
- データを汎用SaaSへ送れない。
- 詳細なオブザーバビリティと評価が必要である。
- ユーザー体験が製品の一部である。
- 保守できる。
例：顧客向けAI製品、規制対象の文書ワークフロー、権限を認識する社内RAG、業界固有のエージェント、非公開データの抽出パイプライン。
まだこれを行わないでください
1つのワークフローを実証する前に、プラットフォームを構築しないでください。
データ処理のレビューなしに、ツールを購入しないでください。
実際のエッジケースを試さずに、ベンダーのAI機能を受け入れないでください。
プロンプティング、RAG、評価を試す前に、ファインチューニングを行わないでください。
プライベートに聞こえるという理由だけで自社運用しないでください。プライバシー要件と運用能力を根拠で示してください。
代表的な試行で決める
AIの構築か購入かの判断は、根拠に応じて個別に決まります。英国政府が現在公開しているAI適合性評価も同様に、データ、利用者、危害、代替手段、ライフサイクルコストを含め、そもそもAIが適切かという問いから始まっています。
購入、設定、拡張、構築、AIを使わない／手作業の経路を、仮説として使います。ワークフロー、データ、安全性、連携、コスト、アクセシビリティ、撤退に関する必須要件を満たす候補のうち、所有・運用の負担が最も小さいものを選んでください。モデルと周辺システムは、どちらも制約になり得ます。代表的な試行で、どちらが制約かを示してください。
