コンテンツへスキップ
リソース/評価フレームワーク
戦略フレームワーク

AI ベンダー・モデル選定マトリクス

AI ベンダーを8つのディメンションで評価する完全な意思決定フレームワーク。備えるべき失敗モードから、25のRFP質問、12のレッドフラグまで — 適切な AI ベンダーを選び、コストのかかるロックインを避けるために必要なすべて。

10セクション
エンドツーエンドの網羅
読了35分
テンプレートと表付き
25のRFP質問
送信準備済み
2026年3月更新
大企業・中堅企業
2週間の評価プロセス

AI ベンダー選定が失敗する理由

短いデモと好意的な公開ベンチマークだけを根拠に LLM ベンダーを選ぶと、決定的な問いが答えられないまま残る。モデルはいつまでサポートされるのか、ベンダーのデータ処理契約は自社のコンプライアンスレビューを通るのか、本番のボリュームでサービスにいくらかかるのか。いずれも、構造化された評価によってコミット前に確認できる。

ベンダー選定がうまくいかないとき、根本原因が技術であることはまれだ。それはプロセス — あるいはその欠如だ。

ロックインのリスク

ベンダー固有のプロンプト形式、function calling のスキーマ、SDK のパターンが積み重なり、見えない移行負債となる。プロジェクト途中で LLM プロバイダーを切り替えるには、エンジニアリングの工数と月単位の期間がかかる。しかもこの依存は、廃止通知や値上げが届くまで気づかれないことがある。

誇大宣伝と現実

公開ベンチマーク(MMLU、GPQA、HumanEval)は一般的な学術能力を測る。あなたの本番ワークロードは一般的ではない。MMLU で1位のモデルが、あなた固有の契約抽出やカスタマーサポートのタスクでは4位になることもある。ドメイン固有のパイロットを伴わないベンチマークに基づく意思決定は、たびたび期待を裏切る。

隠れたコスト

トークンあたりの API 価格は、実際の AI インフラ支出の一部にすぎない。egress 料金、ファインチューニングの計算、コンプライアンス監査、サポート階層のアップグレード、移行エンジニアリングは、トークンの請求書には現れない。トークンだけを対象にした予算は、利用が増えるにつれて超過のリスクにさらされる。

備えるべき3つの失敗モード

コンプライアンスの不一致
ベンダーが、法務レビュー中に発覚したデータレジデンシーや規制要件を満たせない(コミット後)
コスト超過
当初の TCO 分析でモデル化されていなかった隠れた料金、価格変更、利用増加が予算超過を招く
性能ギャップ
本番でのモデル品質やレイテンシがデモやベンチマークと一致せず、コストのかかる移行を要する

8つの評価ディメンション

すべての AI ベンダー選定は、これら8つのディメンションで評価すべきだ。以下のデフォルト重みは、規制された欧州の文脈で LLM インフラを展開する大企業に適している — 重みは具体的な優先順位に合わせて調整してほしい。医療の CISO はセキュリティを35%で重み付けするだろう。市場へ急ぐスタートアップは技術的性能を40%で重み付けするかもしれない。

重みの合計は100でなければならない。セクション3、4、5は、最も重みの大きい3つのディメンションを掘り下げる。

D1

技術的性能

あなた固有のタスクにおけるモデル品質、レイテンシ、スループット、現実的条件下での精度。

25%
D2

セキュリティとコンプライアンス

認証(SOC 2、ISO 27001、HIPAA)、データレジデンシー、GDPR への姿勢、EU AI Act との整合。

20%
D3

総所有コスト

API 価格、トレーニングコスト、隠れた料金、egress、サポート階層、移行エンジニアリングのオーバーヘッド。

15%
D4

サポートと SLA

稼働率保証、サポート応答時間、専任 CSM、エンタープライズ階層の提供。

10%
D5

統合とエコシステム

SDK 品質、フレームワーク互換性(LangChain、LlamaIndex)、CI/CD 統合、ドキュメント。

10%
D6

ベンダーのロードマップと安定性

財務的余力、モデルのリリース頻度、廃止ポリシー、製品ロードマップとの整合。

10%
D7

コンプライアンスと規制適合

業種固有の要件 — 医療の HIPAA、フィンテックの PCI-DSS、EU AI Act のリスク分類。

5%
D8

出口戦略と移植性

データエクスポートの仕組み、モデルの移植性、移行経路、契約上の出口条項。

5%

評価プロセスのフローチャート

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

ディメンション1の詳細:技術的性能

デフォルト重み:25%

技術的性能の評価には3つの要素がある:ベンチマーク手法、レイテンシとスループットの測定、そしてあなた固有のドメインでの精度テスト。3つすべてをコミット前に実行しなければならない。

ベンチマーク手法

公開ベンチマークは出発点であり、意思決定の入力ではない。MMLU は幅広い学術知識を、HumanEval は Python コード生成をテストする。いずれもあなた固有のタスクをテストしない。ベンダー比較を実行する前に、実際の本番データからドメイン固有の評価セットを構築しよう。

評価セットの構築

  • 実際の本番データからの100〜500件の例
  • エッジケースと既知の失敗モードを含める
  • 易・中・難の難易度を網羅する
  • ユースケースに関連する敵対的プロンプトを含める
  • 人間のアノテーターでグラウンドトゥルースのラベルを作成する

タスクタイプ別の精度メトリクス

  • 抽出:エンティティ/値の精度に対する F1 スコア
  • 分類:クラスごとの precision、recall、F1
  • 生成:人間評価 + ROUGE/BERTScore
  • 推論:ロジックタスクでの Pass@1 と Pass@3
  • ハルシネーション率:事実主張の検証

レイテンシとスループットのメトリクス

単一リクエストでレイテンシを評価してはならない。想定する本番トラフィックパターンを用い、現実的な同時負荷の下で測定しよう。ベンダーのデモのレイテンシは常に単一リクエストのベストケースだ。

メトリクス測定対象許容しきい値測定方法
P50 レイテンシ応答時間の中央値単純タスクで < 400ms本番量の1倍で負荷テスト
P95 レイテンシ95パーセンタイル — ユーザー体験の下限複雑タスクで < 1,200ms本番量の2倍で負荷テスト
P99 レイテンシ最悪ケース — 最も悪い1%のユーザー< 3,000ms(SLA の上限)本番量の3倍で負荷テスト
Time to First Tokenストリーミング応答における体感速度P95 で < 300msTTFT を総レイテンシと分けて測定
トークン/秒リクエストあたりの生成スループットリアルタイム UX には > 40 tokens/sトークン数 / 総生成時間
レート制限の容量1分あたりの最大同時リクエスト/トークンピーク本番量の ≥ 2倍ドキュメント確認 + バースト挙動のテスト

精度テストのプロトコル

第1週
ベースライン評価
  • 同一プロンプトで各ベンダーに対し評価セットを実行する
  • 応答ごとの精度、レイテンシ、トークン数を記録する
  • 明らかなハルシネーションや形式の失敗にフラグを立てる
第2週
プロンプト最適化
  • 各ベンダーごとにプロンプトを独立して最適化する
  • 最適化による精度向上を測定する
  • ベンダーごとのプロンプトエンジニアリングの労力を文書化する
第3週
ストレスとエッジケースのテスト
  • 敵対的入力と既知の失敗モードをテストする
  • 長コンテキスト文書での性能を測定する
  • コンテキストウィンドウの限界での挙動をテストする

ディメンション2の詳細:セキュリティとコンプライアンス

デフォルト重み:20%

これらの確認は PoC の後ではなく前に行わなければならない。コンプライアンスのバーをクリアできないベンダーは、技術的性能に関わらず除外される。

SOC 2 Type II

  • Type II は6〜12か月の期間をカバーする(特定時点のスナップショットではない)
  • NDA の下で完全なレポートを要求する — 要約では不十分
  • カバーされる Trust Services Criteria を確認:最低でも Security + Availability
  • 未解決の例外や限定事項についてマネジメントレターを確認する
  • 監査法人の信頼性を検証する(Big 4 または認知された専門家)

ISO 27001

  • 証明書が有効で失効していないことを検証する
  • スコープを確認:利用する具体的なサービスをカバーしているか?
  • クラウドホスト型 AI サービスは Annex A.17(事業継続)を含むべき
  • ISO 27001 認証と単なるコンプライアンス主張を区別する
  • 関連する場合は ISO 27017(クラウドセキュリティ)と ISO 27018(クラウドの PII)を組み合わせる

GDPR とデータ処理

  • 署名済みの DPA(データ処理契約)は GDPR 第28条により必須
  • サブプロセッサーの一覧と、サブプロセッサー変更の承認権を確認する
  • データレジデンシーを確認:EU リージョンのみ、SCC なしでの米国移転は不可
  • 削除 SLA を検証:解約時や要求時にどれだけ速くデータが削除されるか?
  • プロンプトと出力がモデルのトレーニングに決して使用されないことを確認する

EU AI Act との整合

  • あなたの AI ユースケースを EU AI Act のリスクカテゴリに分類する
  • 高リスクのユースケース(HR、与信、医療)は適合性評価を要する
  • GPAI モデルの義務(透明性、著作権)についてベンダーの声明を要求する
  • プロバイダーが第53条に沿った技術文書を維持していることを検証する
  • 第62条に基づくインシデント報告義務に関するプロバイダーの立場を確認する

主要プロバイダー別のデータレジデンシーの選択肢

プロバイダーEU リージョンデータを EU 内に留められるかセルフホストの選択肢DPA の提供
OpenAI(直接)あり(対象顧客のみ、欧州リージョン)プランと設定による。欧州リージョンに設定したプロジェクトは顧客コンテンツをそこで保存・処理する。システムデータは対象外。なしあり(Enterprise)
OpenAI(Azure 経由)あり(EU リージョンと EU Data Zone)リージョナル(EU 地域)または EU Data Zone のデプロイなら可。Global デプロイと Batch は不可。なしあり(Azure DPA)
Anthropic(直接)利用不可不可。データは米国に保存され、推論は米国またはグローバルで実行される。なしあり(Enterprise)
Anthropic(Bedrock 経由)あり(EU リージョン)EU の地理的推論プロファイルなら可。グローバルプロファイルは不可。なしあり(AWS DPA)
Mistral(直接)あり(既定で EU)既定では可。一部の機能はデータを一時的に EU 域外へ転送し、米国エンドポイントはデータを米国でホストする。オープンウェイトあり(標準)
Google Vertex AIあり(EU リージョンと EU マルチリージョン)リージョナルまたは EU マルチリージョンのエンドポイントなら可。グローバルエンドポイントは不可。なしあり(GCP DPA)

「EU リージョン」と「データを EU 内に留められるか」の列は、各プロバイダーの公開ドキュメントを 2026年10月10日に確認した。その他の列は同日に再確認していない。提供内容は変わる。リージョンを選べることは、データ、テレメトリー、サポートによるアクセスが EU 外に出ないことの保証ではない。処理リージョン、保存場所、復処理者、サポートアクセスを契約書とプロバイダーの最新の DPA で確認すること。

ディメンション3の詳細:総所有コスト

デフォルト重み:15%

AI ベンダーの TCO モデリングには5つのコストカテゴリがある。カテゴリ1だけを対象にした予算では、残りの4つが抜け落ちる。コミット前に3年間のモデルを構築しよう。

Category 1

API と推論のコスト

  • 入力トークン価格 × 月間入力トークン量の見込み
  • 出力トークン価格 × 月間出力トークン量の見込み
  • ボリュームディスカウントの階層 — 各価格帯でモデル化する
  • 見込み量におけるコミット利用と従量課金のトレードオフ
  • 専用スループットが必要な場合のレート制限アップグレードのコスト

最も目に見えやすいカテゴリ。ここで止まる予算は不完全だ。

Category 2

トレーニングとカスタマイズ

  • ファインチューニングの計算:エポックあたりのトレーニング実行コスト × 想定実行回数
  • ファインチューニングの推論:微調整済みモデルに対するベンダーの料金を、基本モデル推論の料金と比較する
  • 評価の計算:モデルのバージョン更新ごとに評価スイートを実行する
  • 埋め込みモデルの切り替えや更新時の埋め込み再インデックスのコスト
  • トレーニングセットのためのデータ準備とラベル付け

ファインチューニングを行う場合にのみ発生する。自社で予定しているトレーニング実行とベンダーの料金から見積もろう。

Category 3

運用オーバーヘッド

  • SDK 統合、プロンプトエンジニアリング、保守のためのエンジニアリング時間
  • モニタリングとオブザーバビリティのツール(LangSmith、Langfuse、Datadog LLM)
  • レイテンシやフェイルオーバー要件のためのマルチリージョン複製
  • エンタープライズ SLA のためのサポート階層のサブスクリプションコスト
  • 利用規約変更の法務レビュー(ベンダーが更新するたびに)

展開が成熟するにつれて増える。自社のエンジニアリングとツールのコストから見積もろう。

Category 4

コンプライアンスとセキュリティ

  • SOC 2 のブリッジレターと第三者評価
  • GDPR DPA の法務レビューと年次再レビュー
  • ペネトレーションテストとセキュリティ評価のコスト
  • 監査ログのインフラと保持ストレージ
  • データレジデンシーの追加料金(該当する場合)

一度限りのコストと年次の経常コスト。規制業種では、自社が取得した監査と法務の見積もりをもとに予算化しよう。

Category 5

移行と出口のコスト

  • プロバイダー切り替え時にプロンプトとアダプターを書き換えるエンジニアリング時間
  • 移行後の評価スイートに対する回帰テスト
  • 移行期間中の並行稼働コスト(2ベンダー同時)
  • 埋め込みプロバイダー変更時のコーパス全体の再埋め込み
  • 移行ウィンドウ中のダウンタイムリスクと収益への影響

過小評価しやすいカテゴリ。移行の工数は、切り替えが必要になってからではなく、コミット前に自社のコードベースに即して見積もろう。

自社構築・購入・提携の意思決定フレームワーク

購入(SaaS API)

最適なのは
  • 市場投入のスピードが最優先
  • チームに ML インフラの専門知識が不足している
  • API コストが月5,000ドル未満の規模
  • ユースケースが標準的(要約、分類)
主なリスク
  • ベンダーロックインと規模拡大時の価格変更
  • データが自社の境界を出る
  • ドメイン固有タスク向けのカスタマイズが限定的
例: OpenAI API, Anthropic API, Mistral API

構築(オープンソースのセルフホスト)

最適なのは
  • API コストが月1万ドルを超える規模
  • データ主権が交渉の余地なく必須
  • 深いカスタマイズとファインチューニングの制御が必要
  • チームに ML インフラと DevOps の能力がある
主なリスク
  • 高い運用オーバーヘッドと信頼性の責任
  • GPU の設備投資(capex)またはレンタルコスト
  • モデル更新とセキュリティパッチの負担が自社チームにかかる
例: Llama 4, Mistral(オープンウェイト), Falcon, Gemma

提携(クラウド AI プラットフォーム)

最適なのは
  • すでに AWS、Azure、GCP に大きく投資している
  • 既存のクラウド契約でのエンタープライズコンプライアンスが必要
  • 複数のベンダー関係を管理せずにモデルの多様性が欲しい
  • マネージドのファインチューニングと評価ツールが必要
主なリスク
  • モデルロックインに加えてクラウドプラットフォームのロックイン
  • モデルの提供が直接プロバイダーの API に後れを取る
  • 複数の次元(トークン + 計算 + ストレージ)の複雑な価格設定
例: AWS Bedrock, Azure OpenAI Service, GCP Vertex AI

スコアリングマトリクスのテンプレート

欧州の大企業の LLM 展開に向けて4社のベンダーを比較した実例。各ベンダーをディメンションごとに1〜10で採点し、ディメンション重みを掛け、合計して加重総点を求める。

計算式: Weighted Total = Σ(Dimension Weight% × Score) / 10スコア1〜3:要件を満たさない | 4〜6:部分的に満たす | 7〜9:満たすか上回る | 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)
サポートと SLA10%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.576.080.0勝者66.5

結果の読み方

ベンダー C(EU 発祥)は、技術的性能と統合で低いスコアにもかかわらず勝利する。セキュリティとコンプライアンス(20%)および規制適合(5%)への重い重み付けは、エンタープライズの文脈を反映している。コンプライアンス要件のないスタートアップなら、別の勝者になるだろう。

タイブレークのルール: 2社のベンダーが互いに5点以内であれば、本番規模のトラフィックで2週間の並行パイロットを実施しよう。マトリクスは候補を絞り込む — あなたのワークロードに関する実データが最終判断を下す。

重みの調整: 採点の前に、主要なステークホルダー(CTO、CISO、CFO、DPO)に独立して重みを割り当ててもらい、その後に平均するか交渉しよう。異なる重みは異なる勝者を生む — 重み付けの議論は採点と同じくらい重要だ。

RFP テンプレート:すべてのベンダーに送る25の質問

パイロットを実施する前に、検討中のすべてのベンダーにこれらの質問を送ろう。回答を拒むベンダーや、回答が曖昧なベンダーは問題のサインだ。書面での回答を求めること — 営業エンジニアの口頭回答は契約上の拘束力を持たない。

技術的性能

  1. 1当社の想定リクエストサイズに対する、公開された P50、P95、P99 のレイテンシ目標は何ですか?
  2. 2専用階層と共有容量のそれぞれで保証できるスループット(トークン/秒)はどれだけですか?
  3. 3ピーク需要時のレイテンシ低下にどう対処しますか? 負荷を切り捨てますか、それともリクエストをキューに入れますか?
  4. 4モデル精度のベンチマーク手法は何で、ドメイン固有データでどのように検証しますか?
  5. 5出力挙動を変える可能性のあるモデル更新を伝えるプロセスは何ですか?

セキュリティとコンプライアンス

  1. 6現行の SOC 2 Type II レポートを NDA の下で提供できますか?
  2. 7ISO 27001 証明書を保有していますか? その場合、どのスコープをカバーしますか?
  3. 8API 呼び出しログ、プロンプトデータ、モデル出力に対するデータ保持・削除のポリシーは何ですか?
  4. 9GDPR 第28条に準拠したデータ処理契約(DPA)を提供していますか?
  5. 10当社のプロンプトと出力が、明示的なオプトインなしにモデルのトレーニングへ決して使用されないことを書面で確認できますか?
  6. 11提供している EU データレジデンシーの選択肢と、そのリージョンは何ですか?

価格と商業条件

  1. 12入力トークン、出力トークン、ファインチューニング、ストレージを含む完全な価格体系は何ですか?
  2. 13ボリュームディスカウントは利用できますか? どの階層で、コミット利用契約の構造はどうですか?
  3. 14ある月にコミット量を超過した場合、価格はどうなりますか?
  4. 15トークンあたりの価格に含まれない egress、データ転送、API ゲートウェイの料金はありますか?
  5. 16エンタープライズサポート階層の条件は何で、それぞれ何が含まれますか?

運用と統合

  1. 17API 稼働率の SLA は何ですか? ダウンタイムをどう算出し、どう補償しますか?
  2. 18本番トラフィックの急増に対するレート制限の引き上げにどう対応しますか?
  3. 19顧客にどのようなオブザーバビリティとロギングを公開しますか(トークン使用量、エラー率、レイテンシ)?
  4. 20本番挙動を反映したテスト用のステージング/サンドボックス環境を提供していますか?
  5. 21公式にサポートする SDK は何で、SDK バージョンの廃止プロセスは何ですか?

戦略と出口

  1. 22今後12〜18か月のロードマップは何ですか? どのモデル機能が計画されていますか?
  2. 23当社が本番で使用しているモデルバージョンを廃止する前の最短通知期間は何ですか?
  3. 24離脱を選んだ場合、微調整済みモデルの重みやアダプター層をどのようにエクスポートできますか?
  4. 25契約を早期に解除する契約上のプロセスは何で、どのようなデータ削除保証が適用されますか?
  5. 26当社の業種、または同様のコンプライアンス要件を持つ顧客からのリファレンスを提供できますか?

これらの質問の使い方

営業電話での質問としてではなく、正式な書面の RFP として送る
営業日5日以内の回答期限を設定する
各回答を1〜3で採点する(不十分、部分的、完全)
セキュリティ/コンプライアンスのセクションで不十分な回答が3件を超えるベンダーは除外すべき
回答とあわせて証拠文書(SOC 2 レポート、DPA テンプレート)を要求する
曖昧な回答、または契約交渉に先送りされた回答には追加質問をする

レッドフラグ:ベンダーが期待を裏切る12のサイン

これらは、本番障害、コンプライアンス問題、関係悪化のリスクを示す観察可能なサインだ。クリティカルのフラグはハードストップ — 進めてはならない。ハイのフラグは深い調査を要する。ミディアムのフラグは契約で管理すべき注意サインだ。

番号レッドフラグ深刻度何を示すか
1公開ステータスページや過去の稼働率データがないクリティカルベンダーは信頼性について隠すものがある。本気の本番プロバイダーは必ずインシデント履歴を公開する。
2トレーニングのオプトアウトに、UI のトグルではなく法務レビューが必要クリティカルあなたの独自プロンプトと業務データは、モデルのトレーニングに使われている可能性が高い。エンタープライズでは交渉の余地なし。
3SOC 2 Type II レポートが提供されない(Type I のみ)クリティカルType I は持続的な統制の証拠がない特定時点のスナップショット。Type II は6〜12か月の運用期間をカバーする。
4GDPR/DPA の文書に営業エスカレーションが必要クリティカルDPA はセルフサービスか標準であるべき。エスカレーション要件は、法務の未成熟か意図的な摩擦のいずれかを示す。
5基本階層の情報を得るのに価格が営業電話を要するハイ隠れた価格はたいてい、認識された予算に応じて変動することを意味し、コスト予測に予測不能性を生む。
6モデル廃止の通知が6か月未満ハイ本番システムは6か月未満では安全に移行できない。短い廃止ウィンドウはエンジニアリング計画を破壊する。
7エンタープライズ階層にセルフホストや VPC 展開の選択肢がないハイ規制業種や高感度データでは、共有テナンシーはしばしば受け入れられない。セルフホストなし = 取引なし。
8SDK が retry/backoff ロジックのない薄い REST ラッパーハイエンジニアリング成熟度のサイン。本番品質の SDK は、リトライ、ストリーミング、レート制限のバックオフ、エラー分類を扱う。
9レート制限が文書化されていない、または事前通知なく変更されるミディアム文書化されていない、または不安定なレート制限は容量計画を不可能にし、予期しない本番障害を引き起こす。
10データレジデンシーの書面によるコミットがないミディアム口頭の保証は強制力がない。データレジデンシー要件は営業資料ではなく、DPA または MSA に記載されなければならない。
11設立から18か月未満で、参照可能なエンタープライズ顧客がないミディアム初期段階のベンダーは方向転換、資金切れ、買収の可能性がある。本番 AI インフラには長期存続性が重要だ。
12標準契約に出口条項やデータ削除保証がないミディアム離脱時、あなたのデータと微調整済みモデルはどうなるのか? 契約が沈黙しているなら、最悪を想定せよ。
4
クリティカル

ハードストップ。契約上の是正を得られない限り、直ちにベンダーを除外する。

4
ハイ

進める前に、詳細な調査と書面による緩和計画を要する。

4
ミディアム

注意サイン。契約上の保護、または文書化されたリスク受容で管理する。

絞り込みプロセス:2週間で20社から3社のファイナリストへ

ベンダー評価は、チームが並行で評価しようとする選択肢が多すぎると停滞する。この2週間のプロセスは段階的な絞り込みを用い、効率的に3社の有資格ファイナリストに到達し、本当に値するベンダーのために PoC の労力を温存する。

第1週
1

ディスカバリー

広く網を張る:15〜20社のベンダー

成果物: 1行の適格性を付したロングリスト
ツール: 市場調査、G2、アナリストレポート
第1週
2

MoSCoW フィルター

厳格な must-have 基準を適用する

成果物: ロングリストを6〜8社に絞り込む
ツール: コンプライアンスチェックリスト、価格下限
第2週
3

机上調査

残る6〜8社のベンダーを深掘りする

成果物: セキュリティ姿勢、価格、エコシステムの成熟度
ツール: 公開ドキュメント、SOC 2 の要求、RFP の送付
第2週
4

デモと技術コール

各ベンダーと30分のコール、25の RFP 質問を尋ねる

成果物: 回答を採点し、クリティカルなレッドフラグのあるベンダーを除外する
ツール: 構造化インタビューのテンプレート
第2週
5

採点とショートリスト

上位3〜4社のベンダーに加重スコアリングマトリクスを適用する

成果物: PoC 向けの3社ファイナリストのランク付きショートリスト
ツール: スコアリングマトリクス(セクション6参照)

MoSCoW フィルターの基準

これらを二者択一の合否ゲートとして適用する。Must Have を満たさないベンダーは直ちに除外される — 例外なし。

Must Have(いずれかの不合格 = 除外)

  • SOC 2 Type II レポートが提供される
  • GDPR 準拠の DPA が提供される
  • EU データレジデンシー(DPO が要求する場合)
  • 公開された価格(営業ゲートのない基本階層)
  • 契約上の稼働率 SLA ≥ 99.9%
  • 標準のアカウント設定としてのトレーニングオプトアウト

Should Have(高く採点、除外はしない)

  • ISO 27001 証明書
  • 専任のエンタープライズサポート階層
  • セルフホストまたは VPC 展開の選択肢
  • ファインチューニングとカスタマイズのサポート
  • マルチリージョンの可用性
  • モデルの移植性とエクスポート

選定後:ベンダー管理と SLA モニタリング

ベンダーの選定は始まりであり、終わりではない。ベンダー関係は能動的な管理がなければ劣化する。ベンダー管理を、定期的なリズム、文書化された SLA トラッキング、明確なエスカレーション経路を伴う継続的な規律として扱おう。

SLA モニタリングダッシュボード:主要メトリクス

メトリクスSLA 目標測定エスカレーションのトリガー
API 稼働率月次 ≥ 99.9%EU リージョンから60秒ごとの合成モニタリングダウンタイムが15分超なら P1 インシデント
P95 レイテンシ標準リクエストで < 800ms24時間のローリングウィンドウでの応答時間の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つでも逃したら正式な性能レビューを発動

ベンダー管理のリズム

毎日自動 SLA モニタリングのアラート — 稼働率、レイテンシ、エラー率
毎週リクエストあたりコストの傾向とレート制限の余裕の社内レビュー
毎月ベンダーのステータスページのレビュー、すべての P1 イベントの事後検証
四半期ベンダーとの QBR:ロードマップ更新、価格レビュー、SLA 準拠レポート
毎年完全な再評価:スコアリングマトリクスの再実行、市場の代替案の評価、契約の再交渉

契約更新チェックリスト

契約更新の3か月前に開始する。これがあなたの交渉力のウィンドウだ。

  • 本年度の市場データで加重スコアリングマトリクスを再実行する
  • 更新された SOC 2 Type II レポートを要求する
  • 交渉のポジションを確立するため、2〜3社の代替ベンダーをベンチマークする
  • ベンダーの廃止通知を確認する — 依存しているモデルにリスクはないか?
  • 過去12か月の完全な TCO を当初モデルと比較して算出する
  • 過去12か月の条件変更について DPA を確認する
  • 交渉する:価格改善、SLA 改善、通知期間の延長のためのボリュームコミット
  • 出口条項を更新する:データ削除 SLA とモデル移植性の権利が最新であることを確認する

マルチベンダー抽象化戦略

ベンダーロックインを減らす効果的な方法のひとつは、初日から LLM 呼び出しをルーティング層の背後に抽象化することだ。これは小さな初期のエンジニアリング投資で、後の移行リスクを下げる。

オープンソースのルーティングの選択肢

  • LiteLLM — 多数のプロバイダー向けの統一 API
  • Portkey — オブザーバビリティとフォールバックを備えたゲートウェイ
  • OpenRouter — コスト最適化を伴うマーケットプレイスのルーティング
  • プロバイダーインターフェースを備えたカスタム抽象化層

抽象化がもたらすもの

  • アプリケーションコードを書き換えずに主要ベンダーを切り替える
  • レート制限やダウンタイム時にフォールバックベンダーを自動的に実行する
  • ライブトラフィックで2社のベンダーを A/B テストする
  • リクエスト時にコスト対品質で動的にルーティングする

AI ベンダー評価の実施に支援が必要ですか?

要件定義から PoC 設計、採点、契約交渉まで、客観的で文書化されたフレームワークに基づく構造化されたベンダー評価の実施を支援できます。

AI 戦略サービスを見る