AIベンダーのリスク評価：質問票、採点モデル、エビデンスチェックリスト（2026）
AIベンダーのリスク評価とは、外部のAI製品やAPIに自社データを扱わせる前に行う審査です。用途のリスクを分類し、AI特有の事項（自社データの学習利用、保持期間、サブプロセッサーとモデルプロバイダー、セキュリティテスト、出力のリスク、規制）について質問し、各回答を裏付けるエビデンスを集め、ベンダーを採点したうえで、契約条件と監視方法を定めます。 通常のベンダー審査との違いは、AIベンダーではモデルの挙動、データの再利用、さらにその先につながるモデルプロバイダーの連鎖も考慮する必要があることです。このガイドでは、すぐに使える質問票、採点モデル、エビデンスチェックリストを紹介します。内容は2026年10月26日時点のものです。
AI API、AIゲートウェイ、AI機能を備えたSaaSツールの利用を承認するセキュリティ、調達、プラットフォームの各チームを対象としています。法的助言を提供するものではありません。
AIベンダーのリスクが通常と異なる理由
従来の第三者審査では、アクセス制御、暗号化、稼働率、認証を確認します。AIベンダーには、これらすべてに加えて、次の確認が必要です。
| 新たなリスク | 重要な理由 | 質問例 |
|---|---|---|
| 学習のためのデータ再利用 | 自社のプロンプトが、他社も利用するモデルの改善に使われる可能性がある | 顧客データはデフォルトで学習や評価に使われますか？ |
| フォースパーティー | ベンダーがモデルプロバイダーにデータを転送する可能性がある | 当社のデータを処理するモデルプロバイダーと、その処理リージョンを教えてください。 |
| モデルの挙動 | 出力が誤っていたり、安全性を欠いたり、データを漏えいしたりする可能性がある | プロンプトインジェクションやデータ漏えいについて、どのようにシステムをテストしていますか？ |
| 変更の速さ | モデルやバージョンが予告なく変わることがある | モデルの変更はどのように通知し、バージョンを管理していますか？ |
| 規制 | EU AI法や業界ごとの規則により義務が加わる | EU AI法上、このシステムをどのように分類していますか？ |
| コストの増大 | 従量課金では費用が急増する可能性がある | 利用枠、支出上限、アラートはありますか？ |
NIST AIリスクマネジメントフレームワークは、GovernとMapの機能で第三者のAIリスクを明示的に扱っています。また、NIST生成AIプロファイル（AI 600-1）では、バリューチェーンとコンポーネント統合のリスクを、生成AIのリスクの1つとして挙げています。
ステップ1：用途に応じてベンダーのリスク区分を決める
すべてのAIツールを同じ深さで審査する必要はありません。まずリスク区分を決め、それに応じて質問票の範囲を調整します。
| 区分 | 基準 | 審査の深さ |
|---|---|---|
| Tier 1（高） | 顧客データ、個人データ、規制対象データを扱う、またはAIが操作を実行する（送信、支払い、レコードの変更） | 質問票の全項目、エビデンス、セキュリティテスト、法務審査 |
| Tier 2（中） | 社内データを扱い、すべての出力を人が確認する | 主要な質問項目 + 重要なエビデンス |
| Tier 3（低） | 公開データのみを扱い、システム連携がない | 簡易質問票 + 利用規約の確認 |
区分とその理由をベンダーの審査資料に記録します。用途が変わったら区分を見直します。
ステップ2：AIベンダーのリスク質問票を送る
通常のセキュリティ質問票（Shared Assessments SIGやCSA AI Controls Matrixなど）に、以下の質問を追加してください。
データの取り扱いとプライバシー
- 当社のデータ（プロンプト、ファイル、出力）は、いずれかのモデルの学習や評価に使われますか？デフォルトの設定はどうなっていますか？オプトアウトや契約による確約は可能ですか？
- プロンプト、出力、ログの保持期間はどのくらいですか？保持しない設定や、短期間の保持を設定できますか？
- データはどこ（どのリージョン）で処理・保存されますか？リージョンを固定できますか？
- 当社のデータを受け取るサブプロセッサーとモデルプロバイダーを教えてください。変更はどのように通知されますか？
- DPA（データ処理契約）は提供されていますか？AIによる処理と国際的なデータ移転を対象に含んでいますか？
モデルとシステムのガバナンス
- 製品にはどのモデルを使用していますか？自社モデルですか、それとも第三者のモデルですか？
- モデルやバージョンの変更はどのように通知し、テストしていますか？
- 正確性、バイアス、安全性について、どのような評価を行っていますか？結果を共有できますか？
- 想定用途と既知の制約を記した文書（モデルカードやシステムカード）はありますか？
セキュリティ
- AIサービスを対象とする認証や保証報告（SOC 2 Type II、ISO 27001、ISO 42001）は何ですか？当該AI製品はその対象範囲に含まれていますか？
- プロンプトインジェクション、データ漏えい、過剰な自律性について、どのようにテストしていますか（OWASP Top 10 for LLM Applicationsに基づくテストなど）？
- APIキーの発行、権限範囲の設定、ローテーション、失効はどのように行いますか？
- ログには何が記録され、誰がアクセスできますか？当社でエクスポートできますか？
- AI関連のインシデントについて、対応手順と通知までの期限を教えてください。
運用とコスト
- SLAの内容を教えてください。AI機能と上流のモデルプロバイダーも対象に含まれていますか？
- 上流のモデルプロバイダーが停止した場合、フォールバック、機能を縮小した稼働、処理失敗のいずれになりますか？
- キーごとの利用枠、支出上限、利用量アラートはありますか？
- 解約時の条件（データのエクスポート、削除確認、事前通知期間）を教えてください。
規制
- EU AI法上、このシステムをどのように分類していますか？提供者として、または導入者への支援として、どの義務に対応していますか？現時点の適用スケジュールでは、附属書IIIの高リスク要件は2027年12月2日から適用されるとされています。
- 必要な場合、出力にAI生成コンテンツであることを示す開示やマーキングを付けていますか？
ステップ3：回答だけでなくエビデンスを集める
Tier 1の審査で「はい」と回答された項目には、すべて保管可能な裏付け資料が必要です。
| 回答 | 要求するエビデンス | 確認事項 |
|---|---|---|
| 「貴社のデータを学習に使用しません」 | 契約条項、DPA、製品設定のドキュメント | デフォルトで適用されるか、オプトアウトが必要か。サブプロセッサーにも適用されるか |
| 「データの保持期間は30日です」 | 保持ポリシー、管理者設定画面のスクリーンショット | ログとバックアップにも適用されるか |
| 「SOC 2 Type II」 | NDA下で開示される報告書、ブリッジレター | AIサービスが対象範囲に含まれるか。対象期間の終了日、例外事項 |
| 「プロンプトインジェクションのテストを行っています」 | テスト概要またはペネトレーションテスト報告書 | 実施日、対象範囲、検出事項、再テスト |
| 「キーごとの利用枠があります」 | ドキュメントまたはコンソールのスクリーンショット、自社でのテスト | 上限到達時にリクエストが実際にブロックされるか |
| 「モデルプロバイダーを公開しています」 | リージョンを含むサブプロセッサー一覧 | 自社のデータ所在地要件を満たすか |
認証は一次審査のエビデンスであり、自社の用途が安全であることの証明ではありません。ゲートウェイ固有のエビデンスについては、AI APIゲートウェイのSOC 2エビデンス、AIゲートウェイのDPAチェックリスト、AI APIのデータ保持チェックリストをご覧ください。
ステップ4：ベンダーを採点する
各領域を1-5で採点し（5 = 対策が充実し、エビデンスで裏付けられている）、自社の用途での重要度に応じて重み付けします。
| 領域 | 重み（Tier 1の例） | スコア1 | スコア5 |
|---|---|---|---|
| データの利用と保持 | 25% | デフォルトで学習に利用され、保持期間が不明確 | 学習に利用せず、保持期間を設定でき、契約で保証されている |
| セキュリティとテスト | 25% | AI固有のテストを実施していない | 再テストを含む直近のテストエビデンスがある |
| フォースパーティーとデータ所在地 | 15% | モデルプロバイダーが不明 | 完全な一覧、リージョン、変更通知がある |
| ガバナンスと変更管理 | 15% | 通知せずにモデルを変更する | バージョンを管理し、変更を通知・評価する |
| 運用とコスト管理 | 10% | SLAも利用枠もない | SLA、フォールバック、利用枠、支出上限がある |
| 規制への対応状況 | 10% | 見解がない | 分類と義務を文書化している |
ベンダーの審査資料と一緒に保管できる、シンプルな採点スクリプトです。
WEIGHTS = {"data": .25, "security": .25, "fourth_parties": .15,
"governance": .15, "operations": .10, "regulatory": .10}
def vendor_score(scores: dict, evidence: dict) -> dict:
"""scores: 1-5 per domain; evidence: True if the score is backed by filed evidence"""
capped = {d: (s if evidence.get(d) else min(s, 2)) for d, s in scores.items()} # no evidence -> max 2
total = sum(WEIGHTS[d] * capped[d] for d in WEIGHTS)
decision = "approve" if total >= 4 else "approve with conditions" if total >= 3 else "reject or escalate"
return {"score": round(total, 2), "decision": decision, "capped": capped}
print(vendor_score(
{"data": 5, "security": 4, "fourth_parties": 4, "governance": 3, "operations": 4, "regulatory": 3},
{"data": True, "security": True, "fourth_parties": True, "governance": False, "operations": True, "regulatory": False},
))
スコアの上限ルールは重要です。裏付けのない主張を、テストで確認した主張と同じように高く評価してはいけません。
ステップ5：リスクに関わる主張を自分たちで検証する
Tier 1のベンダーについては、契約前にサンドボックスでいくつかの項目をテストします。
- キーの失効： テスト用キーを失効させ、リクエストが即座に失敗することを確認します。
- 利用枠： 小さな利用枠を設定し、上限に達するとリクエストがブロックされることを確認します。
- モデルの許可リスト： 許可されていないはずのモデルを呼び出し、拒否されることを確認します。
- ログの内容： リクエストログに何が保存されるかを確認します（メタデータのみか、プロンプト全文か）。
# After revoking the test key in the vendor console, this should return 401
curl -s -o /dev/null -w "%{http_code}\n" https://api.vendor.example/v1/chat/completions \
-H "Authorization: Bearer $REVOKED_TEST_KEY" -H "Content-Type: application/json" \
-d '{"model":"any-model","messages":[{"role":"user","content":"ping"}]}'
質問票でわかるのはベンダーの主張です。これらのテストでは、その一部を直接確認します。自社のAIアプリケーション全体に対するセキュリティテストは別途必要です。詳しくは、AIセキュリティ監査ガイドで解説しています。
ステップ6：管理策を契約に盛り込む
| 条項 | 理由 |
|---|---|
| 顧客データの学習利用を禁止する（サブプロセッサーによる利用も含む） | データの再利用を防ぐ |
| 保持期間の上限と解約時の削除 | データがリスクにさらされる範囲を抑える |
| サブプロセッサーとモデルプロバイダーの変更通知 | 新たなフォースパーティーに異議を申し立てられる |
| データ侵害とAIインシデントの通知期限 | 迅速な対応につながる |
| 監査権とエビデンスの提供を求める権利 | 主張を再確認できる |
| AI機能を対象に含むSLA | 稼働率に関する約束を契約上の義務にする |
| データ所在地 | データ移転の規則を満たす |
ステップ7：承認後も監視する
- Tier 1のベンダーは毎年再審査し、モデル、サブプロセッサー、利用条件が変わった際にも見直します。
- ベンダーごと、キーごとの利用量とコストを追跡します。
- インシデントとセキュリティ情報を継続的に確認します。
- 承認済みモデルの一覧を管理し、新しいモデルは審査を経て追加します（AIモデルの承認ワークフロー）。
AI APIゲートウェイをベンダーとして評価する
ゲートウェイは自社アプリと複数のモデルプロバイダーの間に位置するため、ゲートウェイ自体（キー、ログ、利用枠、課金、サポート）と、ルーティング先となる各上流プロバイダーの両方を評価します。ルート一覧に加え、どのプロバイダーがどのデータを受け取るのかを確認してください。たとえばFlatkeyでは、利用状況ダッシュボードでリクエストごとのモデル、トークン、コスト、キーを確認し、エビデンスとしてログをCSV/JSONでエクスポートできます。また、APIキー管理では環境ごとにキーを作成・失効できます。エクスポートしたデータは、質問票と一緒に調達資料として保管してください。AIゲートウェイ調達用エビデンス一式では必要な資料全体を、モデルプロバイダーのエビデンス審査では上流プロバイダーの審査を扱っています。
よくある質問
AIベンダーのリスク評価とは何ですか？
外部のAI製品やAPIを承認する前に、データの利用、セキュリティ、フォースパーティーのモデルプロバイダー、ガバナンス、運用、規制への対応状況を確認する体系的な審査です。エビデンスとリスクスコアを根拠に評価します。
AIベンダーの質問票には何を含めるべきですか？
最低限、自社データのモデル学習への利用有無、保持期間、処理リージョン、サブプロセッサーとモデルプロバイダー、AIサービスを対象とする認証、AI固有のセキュリティテスト、キーとログの管理、SLAとフォールバック、コスト管理、解約条件、EU AI法上の分類を含めます。
AIベンダーのリスク管理は、通常のTPRMとどう違いますか？
AIでは、学習のためのデータ再利用、フォースパーティーのモデルプロバイダー、予測できないモデル出力、頻繁なモデル変更、AI固有の規制が加わります。標準的なTPRMの管理策も引き続き適用されます。
ベンダーのリスク管理にAIを活用できますか？
はい。AIツールは質問票の要約やエビデンスの不足箇所の指摘に役立ちます。ただし、特にTier 1のベンダーについては、承認の判断とエビデンスの検証を人が行う必要があります。
SOC 2報告書だけでAIベンダーを承認できますか？
いいえ。AIサービスが報告書の対象範囲と対象期間に含まれることを確認したうえで、学習利用、保持期間、モデルプロバイダー、テストに関するAI固有の質問も必要です。AICPAのSOC 2概要では、SOC 2報告書が対象とする内容を説明しています。
AIベンダーのリスク評価に役立つフレームワークは何ですか？
NIST AI RMFとその生成AIプロファイル、技術的リスクを扱うOWASP LLM Top 10、CSA AI Controls Matrix、AIマネジメントシステムのISO/IEC 42001、Shared Assessments SIG質問票です。
出典
2026年10月26日確認：NIST AI RMF、NIST AI 600-1、OWASP Top 10 for LLM Applications、CSA AI Controls Matrix、Shared Assessments SIG、EU AI法の適用スケジュール、GDPR対応AI APIゲートウェイチェックリスト。
