AI ベンダーを8つのディメンションで評価する完全な意思決定フレームワーク。200万ドルの失敗パターンから、25のRFP質問、12のレッドフラグ、実際のケーススタディまで — 適切な AI ベンダーを選び、コストのかかるロックインを避けるために必要なすべて。
ある欧州のフィンテックは、45分のデモと好意的なベンチマークのブログ記事に基づいて LLM ベンダーを選定した。18か月後、そこから移行するために210万ドルを費やした。モデルは廃止され、コンプライアンスチームはベンダーのデータ処理契約を却下し、トークンあたりのコストは当初の予算から3倍になっていた。これらのいずれも予見不可能ではなかった。すべて、構造化された評価で捉えられていたはずだ。
この話は珍しくない。欧州全域の80人を超えるエンジニアリングリーダーとの対話で、同じ失敗モードが繰り返し現れる。根本原因はほとんど常に技術ではない。それはプロセス — あるいはその欠如だ。
ベンダー固有のプロンプト形式、function calling のスキーマ、SDK のパターンが積み重なり、見えない移行負債となる。プロジェクト途中で LLM プロバイダーを切り替える平均的なエンジニアリングコスト：5万〜20万ドル、3〜6か月。多くのチームは、廃止通知や値上げを受け取るまでこの依存に気づかない。
公開ベンチマーク（MMLU、GPQA、HumanEval）は一般的な学術能力を測る。あなたの本番ワークロードは一般的ではない。MMLU で1位のモデルが、あなた固有の契約抽出やカスタマーサポートのタスクでは4位になることもある。ドメイン固有のパイロットを伴わないベンチマークに基づく意思決定は、たびたび期待を裏切る。
トークンあたりの API 価格は、実際の AI インフラ支出の40〜60%にすぎない。egress 料金、ファインチューニングの計算、コンプライアンス監査、サポート階層のアップグレード、移行エンジニアリングが、見えない大多数だ。トークンだけを予算化するチームは、2年目にたびたび2〜3倍のコスト超過を経験する。
すべての AI ベンダー選定は、これら8つのディメンションで評価すべきだ。以下のデフォルト重みは、規制された欧州の文脈で LLM インフラを展開する大企業に適している — 重みは具体的な優先順位に合わせて調整してほしい。医療の CISO はセキュリティを35%で重み付けするだろう。市場へ急ぐスタートアップは技術的性能を40%で重み付けするかもしれない。
重みの合計は100でなければならない。セクション3、4、5は、最も重みの大きい3つのディメンションを掘り下げる。
あなた固有のタスクにおけるモデル品質、レイテンシ、スループット、現実的条件下での精度。
認証（SOC 2、ISO 27001、HIPAA）、データレジデンシー、GDPR への姿勢、EU AI Act との整合。
API 価格、トレーニングコスト、隠れた料金、egress、サポート階層、移行エンジニアリングのオーバーヘッド。
稼働率保証、サポート応答時間、専任 CSM、エンタープライズ階層の提供。
SDK 品質、フレームワーク互換性（LangChain、LlamaIndex）、CI/CD 統合、ドキュメント。
財務的余力、モデルのリリース頻度、廃止ポリシー、製品ロードマップとの整合。
業種固有の要件 — 医療の HIPAA、フィンテックの PCI-DSS、EU AI Act のリスク分類。
データエクスポートの仕組み、モデルの移植性、移行経路、契約上の出口条項。
flowchart TD
A([Start: Vendor Evaluation]) --> B[Discovery & Requirements]
B --> B1[Define use case & constraints]
B --> B2[Set must-have criteria]
B --> B3[Identify 15-20 candidate vendors]
B1 & B2 & B3 --> C[Initial Shortlist]
C --> C1[Apply MoSCoW filter]
C1 --> C2{Passes must-haves?}
C2 -- No --> X1[Eliminate]
C2 -- Yes --> D[PoC / Pilot Phase]
D --> D1[Technical benchmark on your data]
D --> D2[Security review & DPA check]
D --> D3[Pricing & TCO modelling]
D1 & D2 & D3 --> E[Weighted Scoring Matrix]
E --> E1[Score top 3 vendors]
E1 --> F[Commercial Negotiation]
F --> F1[SLA terms]
F --> F2[Data processing agreement]
F --> F3[Exit clause negotiation]
F1 & F2 & F3 --> G([Vendor Selected])
style A fill:#1a1a2e,stroke:#7c3aed,color:#e2e8f0
style B fill:#1e293b,stroke:#475569,color:#e2e8f0
style B1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style C1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C2 fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style D fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style D1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style E1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style F1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style X1 fill:#1f0d0d,stroke:#ef4444,color:#e2e8f0
style G fill:#0d1f12,stroke:#22c55e,color:#e2e8f0デフォルト重み：25%
技術的性能の評価には3つの要素がある：ベンチマーク手法、レイテンシとスループットの測定、そしてあなた固有のドメインでの精度テスト。3つすべてをコミット前に実行しなければならない。
公開ベンチマークは出発点であり、意思決定の入力ではない。MMLU は幅広い学術知識を、HumanEval は Python コード生成をテストする。いずれもあなた固有のタスクをテストしない。ベンダー比較を実行する前に、実際の本番データからドメイン固有の評価セットを構築しよう。
単一リクエストでレイテンシを評価してはならない。想定する本番トラフィックパターンを用い、現実的な同時負荷の下で測定しよう。ベンダーのデモのレイテンシは常に単一リクエストのベストケースだ。
| メトリクス | 測定対象 | 許容しきい値 | 測定方法 |
|---|---|---|---|
| P50 レイテンシ | 応答時間の中央値 | 単純タスクで < 400ms | 本番量の1倍で負荷テスト |
| P95 レイテンシ | 95パーセンタイル — ユーザー体験の下限 | 複雑タスクで < 1,200ms | 本番量の2倍で負荷テスト |
| P99 レイテンシ | 最悪ケース — 最も悪い1%のユーザー | < 3,000ms（SLA の上限） | 本番量の3倍で負荷テスト |
| Time to First Token | ストリーミング応答における体感速度 | P95 で < 300ms | TTFT を総レイテンシと分けて測定 |
| トークン/秒 | リクエストあたりの生成スループット | リアルタイム UX には > 40 tokens/s | トークン数 / 総生成時間 |
| レート制限の容量 | 1分あたりの最大同時リクエスト／トークン | ピーク本番量の ≥ 2倍 | ドキュメント確認 + バースト挙動のテスト |
デフォルト重み：20%
セキュリティとコンプライアンスは、AI ベンダー選定がコミット後に失敗する最も一般的な理由だ。これらの確認は PoC の後ではなく前に行わなければならない。コンプライアンスのバーをクリアできないベンダーは、技術的性能に関わらず除外される。
| プロバイダー | EU リージョン | データが EU を出ない | セルフホストの選択肢 | DPA の提供 |
|---|---|---|---|---|
| OpenAI（直接） | 利用不可 | いいえ — 米国のサーバー | なし | あり（Enterprise） |
| OpenAI（Azure 経由） | あり（スウェーデン、フランス、オランダ） | はい（PTU） | なし | あり（Azure DPA） |
| Anthropic（直接） | 利用不可 | いいえ — 米国のサーバー | なし | あり（Enterprise） |
| Anthropic（Bedrock 経由） | あり（フランクフルト、アイルランド） | はい | なし | あり（AWS DPA） |
| Mistral（直接） | あり（フランス） | はい — EU 発祥 | オープンウェイト | あり（標準） |
| Google Vertex AI | あり（ベルギー、オランダ） | はい（リージョナルエンドポイント） | なし | あり（GCP DPA） |
デフォルト重み：15%
AI ベンダーの TCO モデリングには5つのコストカテゴリがある。多くのチームはカテゴリ1だけを予算化する。全体像はたいてい当初見積もりの2〜3倍だ。コミット前に3年間のモデルを構築しよう。
これは、多くのチームが予算に含める唯一のコストだ。
ファインチューニングを使うチームでは通常、API コストに20〜40%を追加する。
成熟した本番展開では、API コストの30〜60%にのぼることが多い。
規制業種では、一度限りおよび年次の経常コストが合計で年間1万〜5万ドル。
最も過小評価されるコストカテゴリ。プロジェクト途中で切り替える場合は3〜6か月の移行を見込もう。
欧州の大企業の LLM 展開に向けて4社のベンダーを比較した実例。各ベンダーをディメンションごとに1〜10で採点し、ディメンション重みを掛け、合計して加重総点を求める。
| ディメンション | 重み | ベンダー A米国ハイパースケーラー | ベンダー Bクラウドプラットフォーム | ベンダー CEU 発祥 | ベンダー Dオープンソースのホスト |
|---|---|---|---|---|---|
| 技術的性能 | 25% | 9/10(22.5) | 8/10(20.0) | 7/10(17.5) | 6/10(15.0) |
| セキュリティとコンプライアンス | 20% | 5/10(10.0) | 8/10(16.0) | 10/10(20.0) | 7/10(14.0) |
| 総所有コスト | 15% | 6/10(9.0) | 7/10(10.5) | 8/10(12.0) | 9/10(13.5) |
| サポートと SLA | 10% | 8/10(8.0) | 9/10(9.0) | 6/10(6.0) | 5/10(5.0) |
| 統合とエコシステム | 10% | 9/10(9.0) | 7/10(7.0) | 6/10(6.0) | 5/10(5.0) |
| ベンダーのロードマップと安定性 | 10% | 8/10(8.0) | 7/10(7.0) | 9/10(9.0) | 6/10(6.0) |
| コンプライアンスと規制適合 | 5% | 4/10(2.0) | 7/10(3.5) | 10/10(5.0) | 8/10(4.0) |
| 出口戦略と移植性 | 5% | 4/10(2.0) | 6/10(3.0) | 9/10(4.5) | 8/10(4.0) |
| 加重総点 | 100% | 70.5 | 76.0 | 80.0勝者 | 66.5 |
ベンダー C（EU 発祥）は、技術的性能と統合で低いスコアにもかかわらず勝利する。セキュリティとコンプライアンス（20%）および規制適合（5%）への重い重み付けは、エンタープライズの文脈を反映している。コンプライアンス要件のないスタートアップなら、別の勝者になるだろう。
タイブレークのルール： 2社のベンダーが互いに5点以内であれば、本番規模のトラフィックで2週間の並行パイロットを実施しよう。マトリクスは候補を絞り込む — あなたのワークロードに関する実データが最終判断を下す。
重みの調整： 採点の前に、主要なステークホルダー（CTO、CISO、CFO、DPO）に独立して重みを割り当ててもらい、その後に平均するか交渉しよう。異なる重みは異なる勝者を生む — 重み付けの議論は採点と同じくらい重要だ。
パイロットを実施する前に、検討中のすべてのベンダーにこれらの質問を送ろう。回答を拒むベンダーや、回答が曖昧なベンダーは問題のサインだ。書面での回答を求めること — 営業エンジニアの口頭回答は契約上の拘束力を持たない。
これらは、本番障害、コンプライアンス問題、関係悪化と強く相関する観察可能なサインだ。クリティカルのフラグはハードストップ — 進めてはならない。ハイのフラグは深い調査を要する。ミディアムのフラグは契約で管理すべき注意サインだ。
| 番号 | レッドフラグ | 深刻度 | 何を示すか |
|---|---|---|---|
| 1 | 公開ステータスページや過去の稼働率データがない | クリティカル | ベンダーは信頼性について隠すものがある。本気の本番プロバイダーは必ずインシデント履歴を公開する。 |
| 2 | トレーニングのオプトアウトに、UI のトグルではなく法務レビューが必要 | クリティカル | あなたの独自プロンプトと業務データは、モデルのトレーニングに使われている可能性が高い。エンタープライズでは交渉の余地なし。 |
| 3 | SOC 2 Type II レポートが提供されない（Type I のみ） | クリティカル | Type I は持続的な統制の証拠がない特定時点のスナップショット。Type II は6〜12か月の運用期間をカバーする。 |
| 4 | GDPR/DPA の文書に営業エスカレーションが必要 | クリティカル | DPA はセルフサービスか標準であるべき。エスカレーション要件は、法務の未成熟か意図的な摩擦のいずれかを示す。 |
| 5 | 基本階層の情報を得るのに価格が営業電話を要する | ハイ | 隠れた価格はたいてい、認識された予算に応じて変動することを意味し、コスト予測に予測不能性を生む。 |
| 6 | モデル廃止の通知が6か月未満 | ハイ | 本番システムは6か月未満では安全に移行できない。短い廃止ウィンドウはエンジニアリング計画を破壊する。 |
| 7 | エンタープライズ階層にセルフホストや VPC 展開の選択肢がない | ハイ | 規制業種や高感度データでは、共有テナンシーはしばしば受け入れられない。セルフホストなし = 取引なし。 |
| 8 | SDK が retry/backoff ロジックのない薄い REST ラッパー | ハイ | エンジニアリング成熟度のサイン。本番品質の SDK は、リトライ、ストリーミング、レート制限のバックオフ、エラー分類を扱う。 |
| 9 | レート制限が文書化されていない、または事前通知なく変更される | ミディアム | 文書化されていない、または不安定なレート制限は容量計画を不可能にし、予期しない本番障害を引き起こす。 |
| 10 | データレジデンシーの書面によるコミットがない | ミディアム | 口頭の保証は強制力がない。データレジデンシー要件は営業資料ではなく、DPA または MSA に記載されなければならない。 |
| 11 | 設立から18か月未満で、参照可能なエンタープライズ顧客がない | ミディアム | 初期段階のベンダーは方向転換、資金切れ、買収の可能性がある。本番 AI インフラには長期存続性が重要だ。 |
| 12 | 標準契約に出口条項やデータ削除保証がない | ミディアム | 離脱時、あなたのデータと微調整済みモデルはどうなるのか？ 契約が沈黙しているなら、最悪を想定せよ。 |
ハードストップ。契約上の是正を得られない限り、直ちにベンダーを除外する。
進める前に、詳細な調査と書面による緩和計画を要する。
注意サイン。契約上の保護、または文書化されたリスク受容で管理する。
多くのベンダー評価は、チームが並行で評価しようとする選択肢が多すぎるために停滞する。この2週間のプロセスは段階的な絞り込みを用い、効率的に3社の有資格ファイナリストに到達し、本当に値するベンダーのために PoC の労力を温存する。
広く網を張る：15〜20社のベンダー
厳格な must-have 基準を適用する
残る6〜8社のベンダーを深掘りする
各ベンダーと30分のコール、25の RFP 質問を尋ねる
上位3〜4社のベンダーに加重スコアリングマトリクスを適用する
これらを二者択一の合否ゲートとして適用する。Must Have を満たさないベンダーは直ちに除外される — 例外なし。
3か月のプロセス • 12社のベンダーを評価 • 意思決定の根拠を文書化
7か国で事業を展開する汎欧州のリテール銀行は、社内文書検索と契約分析のための LLM ベンダーを必要としていた。52,000件の文書、PII の多いコンテンツ、複数法域にわたる規制要件があり、賭け金は高かった。その評価をどう進めたかを示す。
選定されたベンダーは、欧州に本社を置き、EU データレジデンシーを発祥から備えるプロバイダーだった。生のモデル性能ベンチマークでは3位だったが、セキュリティとコンプライアンスに割り当てた30%の重みを適用すると1位となった。技術的に優れた2社はいずれも米国に本社があり、評価時点で EU のみのデータレジデンシー保証がなかった。
交渉された契約上の出口条項により、銀行はすべての微調整済みアダプターをエクスポートし、90日の通知でプロバイダーを切り替える権利を得た。この一条項だけで、リスクモデルにおける移行リスクプレミアム（想定される将来の移行エンジニアリングのコスト）を40万ユーロ削減した。
12か月の成果： 銀行は初年度に890,000件の文書クエリを処理し、TCO は当初見積もりを30%下回った。ベンダーは EU のカバレッジを拡大し、関係をさらに強化した。この構造化された評価プロセスは、今後すべての AI ベンダー選定の標準として採用された。
ベンダーの選定は始まりであり、終わりではない。ベンダー関係は能動的な管理がなければ劣化する。最良の成果を得るチームは、ベンダー管理を、定期的なリズム、文書化された SLA トラッキング、明確なエスカレーション経路を伴う継続的な規律として扱う。
| メトリクス | SLA 目標 | 測定 | エスカレーションのトリガー |
|---|---|---|---|
| API 稼働率 | 月次 ≥ 99.9% | EU リージョンから60秒ごとの合成モニタリング | ダウンタイムが15分超なら P1 インシデント |
| P95 レイテンシ | 標準リクエストで < 800ms | 24時間のローリングウィンドウでの応答時間の95パーセンタイル | P95 が5分超にわたり1,200ms を超えたらアラート |
| エラー率 | 1時間あたり 5xx エラー < 0.5% | クライアントエラーを除く、全 API エンドポイントでのエラー率 | 連続2時間で1%超ならベンダーへエスカレーション |
| レート制限の余裕 | 契約上限に対し ≥ 30% の予備容量 | 契約上のレート制限上限に対する日次ピーク使用量 | 余裕が連続5日 < 20% のとき上限引き上げを要求 |
| API 1,000 コールあたりのコスト | モデル化したベースラインの10%以内 | 当初 TCO モデルに対する7日間のローリング平均 | ベースラインを20%超で継続的に上回るならレビューと再交渉 |
| 四半期ビジネスレビュー | 90日ごとに実施 | ベンダーロードマップの更新、インシデントレビュー、価格レビュー、SLA 準拠レポート | クリティカルな SLA を1つでも逃したら正式な性能レビューを発動 |
契約更新の3か月前に開始する。これがあなたの交渉力のウィンドウだ。
ベンダーロックインを減らす最も効果的な唯一の方法は、初日から LLM 呼び出しをルーティング層の背後に抽象化することだ。これは1〜3日のエンジニアリング投資で、数か月分の移行リスクを排除する。