LLMのベンダー選定が「デモ印象主導」になっていないか。ベンチマークスコアと営業資料だけで調達を決めた企業が、本番稼働後に「データ学習のオプトアウト条項がない」「SLAにモデル精度の担保がない」「規制対応のためにデプロイモデルを変更できない」という問題に直面するケースは増えている。LLM調達は技術評価が核心であり、防御可能な選定根拠を調達段階で確立する必要がある。
LLM調達が「技術的意思決定」である理由
LLM調達はベンチマーク比較ではなく、データ管理・セキュリティ統制・ベンダー依存リスクを技術仕様レベルで検証する意思決定プロセスです。
従来のソフトウェア調達と異なり、LLMにはモデル固有のリスク構造がある。第一に学習データ汚染リスク——顧客データがモデルの再学習に使用されるとデータリーケージが生じる。第二にモデル非推奨リスク——ベンダーが旧モデルを廃止した際の移行コストは、APIのバージョン固定設計がなければ甚大になる。第三に集中リスク——単一ベンダーへの依存が深まると、価格改定・サービス変更への対抗手段を失う。
2026年以降、規制面でも変化がある。EU AI Actの高リスクシステム義務は2026年8月から本格適用され、米国のOMB M-26-04はLLM調達時にモデルカード・評価アーティファクト・利用可能ポリシーの提出を義務付けた。「動けば良い」という判断基準は、既にコンプライアンスリスクを内包する。
技術評価の4軸フレームワーク
防御可能な選定決定はモデル能力・セキュリティ・基盤・ガバナンスの4軸を数値スコアで横断比較することで得られます。
軸1: モデル能力評価
公開ベンチマーク（MMLU・HumanEval等）はあくまで参考値であり、自社ユースケースとの相関は保証されない。評価前に成功基準を定義し、プロダクションに近い入力でPoCを実施することが必須となる。評価すべき観点は以下の通りです。
- タスク精度: 本番を想定した入力サンプル100〜500件で精度・ハルシネーション率を測定する
- 構造化出力: JSON Schema準拠の出力（
outputSchema対応）と型検証の安定性を確認する - レイテンシー: 本番規模でのp95/p99レイテンシーをload testで計測する（デモ環境の値は参考にならない）
- コスト予測性: トークン単価の変動履歴とボリュームディスカウント条件を契約前に確認する
軸2: セキュリティ・コンプライアンス
調達担当者が最初に確認すべきは「顧客データがモデル学習に使われるか」という一点です。
- SOC 2 Type II取得確認: Type Iは一時点のスナップショットに過ぎず、Type IIの継続的な運用証跡が必須
- 学習オプトアウト: デフォルトで学習無効になっているか、遡及的に削除可能かを契約条項で確認する
- VPC隔離・プライベートデプロイ: 機密データを扱う場合、パブリックAPIではなくVPC内デプロイが要件になる
- データ処理契約: GDPR準拠のDPA（Data Processing Agreement）、国内規制に対応した個人情報取扱い条項、医療・金融分野ではBAA等の個別対応を要求する
- サブプロセッサーの開示: ベンダーが利用するクラウドプロバイダー（例: Anthropic→AWS）とそのデータ処理ポリシーまで連鎖確認する
軸3: 基盤・API信頼性
本番稼働後の安定性は、調達前のAPI設計評価で大半が決まります。
- SLAのスコープ: 稼働率だけでなく「精度保証・レスポンス品質」をSLAに含めることを要求する。稼働しているが品質劣化したモデルは稼働0と同義の場合がある
- APIバージョン固定: モデルバージョンをAPIレベルで固定できるか、廃止通知の猶予期間は何ヶ月かを確認する
- レート制限設計: 本番ピーク時のスループット要件に対するレート上限と課金モデルを事前に確認する
- 監査ログ: プロンプト・レスポンスのログ保持期間、エクスポート形式、改ざん防止措置を確認する（詳細は監査ログの改ざん防止設計を参照）
軸4: ガバナンス成熟度
ベンダー自体の組織的成熟度は、長期的な調達リスクに直結します。
- モデルカードの開示: 学習データの出所・評価手法・既知の限界が文書化されているか
- 脆弱性開示ポリシー（VDP）: セキュリティインシデント発生時の通知義務と対応プロセスが定義されているか
- 本番参照顧客: 類似規模・業種での本番デプロイ実績が確認できるか
- 財務安定性: 資金調達ラウンドと現金滑走距離（runway）、IPO・M&A動向がベンダーロックインリスクに影響する
ベンダーリスクの技術的構造
LLMベンダーリスクはデータリーケージ・モデル非推奨・集中・コンプライアンスの4類型に整理でき、それぞれ技術統制で対処します。
データリーケージリスクには、学習オプトアウト・DPA・VPC隔離・機密データのマスキングを組み合わせる。モデル非推奨リスクには、APIバージョン固定とモデル抽象化レイヤー（LLMゲートウェイ）の導入が有効で、ゲートウェイでルーティング先をベンダー依存なく切り替えられる設計にする。集中リスクは、プライマリ/セカンダリの2ベンダー体制とルーティング設計で緩和する。
コンプライアンスリスクは業種によって内容が異なる。金融機関は金融庁のAIガバナンス指針、医療機関は医療情報システムの安全管理に関するガイドライン、グローバル展開企業はEU AI Act高リスク分類の確認を調達時に実施する必要がある。いずれも「後から対応する」前提の設計では、改修コストが調達コストを上回るリスクがある。
エンタープライズデプロイモデルの技術選択
パブリックAPI・プライベートクラウド・オンプレミスの3モデルはデータ感度・レイテンシー要件・規制適合のトレードオフで選択します。
エンタープライズでのLLMデプロイには3つのモデルがあり、選択は機能要件と規制要件の交差点で決まります。
| デプロイモデル | データ隔離 | 実装速度 | 主なユースケース |
|---|---|---|---|
| パブリックAPI | 限定的 | 最速 | 非機密データの社内ツール・PoC |
| プライベートクラウド（VPC） | 高 | 中 | 機密データを扱う業務アプリ |
| オンプレミス | 最高 | 低 | 規制対象データ・完全ネットワーク分離要件 |
VPCデプロイは「セキュリティと速度のトレードオフで中間点」に位置するが、ベンダーがVPCデプロイオプションを提供しているかどうか自体が評価軸となる。主要LLMプロバイダーのVPC/プライベートエンドポイントの対応状況は、調達要件として明示的にRFPに含めることを推奨します。
Kuuの大企業向けRDEサービスでは、デプロイモデル選択を含むLLM調達の技術評価フレームワーク設計を支援しています。
参考
- Enterprise LLM Vendor Evaluation: A Complete Checklist for Choosing the Right AI Partner
- AI Vendor Security and Safety Assessment Guide
- AI Vendor & Tool Approval Checklist 2026
まとめ
LLM調達をデモ印象主導から防御可能な技術評価へ転換するには、モデル能力・セキュリティ・基盤・ガバナンス成熟度の4軸で一貫したスコアリングを行い、データ学習オプトアウト・SOC 2 Type II・VPCデプロイ対応・APIバージョン固定の4点を契約前に確認することが最低要件です。規制対応が本格化する2026年以降、調達プロセスの技術的厳密さがエージェントガバナンスの品質を決定する重要因子になります。
LLM調達の技術評価設計やベンダーリスクアセスメントの体系化は、Kuu株式会社のRDEサービスにご相談ください。