簡潔な答え：AIベンダーの評価とは、約束ではなく証拠を求めることです。署名する前に、4つのことを書面で欲しいです：検証可能な独立テスト結果、データの使用と保管方法に関する明確な条件、運用開始後のシステム監視への約束、およびベンダーの言葉を信じずにすべてのセーフティクレームを検証する方法。このガイドの残りの部分は、これを実用的なプロセス、ベンダーに送信できる質問リスト、および回答を確実にする契約条件に変えます。

AIデューデリジェンスが通常のソフトウェアレビューと異なる理由は、AIシステムが自信を持って誤った答えを出したり、独自のルールから引き出されたり、データをリークしたり、火曜日にベンダーが推し進めるモデル更新後に動作を変更したりする可能性があるためです。これらのリスクは動作をテストすることで見つけ、動作がドリフトした場合に何が起こるかを述べる契約条件で制御します。

AIベンダーのデューデリジェンスが現在正式な期待である理由

AIを購入することは、データに関する追加段落を含むソフトウェア購入として扱われてきました。大西洋の両側の公開購買者と立法者がこれを変えました。

米国連邦購買者：OMBメモM-25-22

2025年4月3日、ホワイトハウス行政管理予算局はメモランダムM-25-22「政府におけるAI調達の効率化」を発行しました。これはメモから180日以上後に発行された勧誘の下で授与された契約、およびその後行使された更新オプションに適用されます。第4条(d)は、機関がAIシステムおよびサービスの契約に「対応する条件を含める必要がある」と述べています。その中でも：

• 継続的なパフォーマンス監視。契約では機関がシステムのパフォーマンス、リスク、および有効性を定期的に監視および評価できる必要があり、四半期または隔年の定期レビューが例として示されています。
• 独立テスト。機関は「ベンダーがアクセスできない」独自のデータセットでテストすべきであり、ベンダーは「機関が独立した評価を完了するために必要なアクセスと時間」を提供する必要があり、テスト結果は「テストが独立して検証または再現できるほど詳細」である必要があります。
• ロックインに対する保護。条件には知識の移転、「データおよびモデルポータビリティ」、ライセンスおよび価格の透明性が含まれる場合があります。
• データのトレーニング使用の制限。第3条(e)は、機関が明示的に同意しない限り、契約は「非公開の入力機関データおよび出力結果を」公開または商業的に利用可能なAIのさらなるトレーニングに使用することを「永久に禁止する」ことを要求しています。
• 変更前の通知。 機関は新しいAI機能が統合される前にベンダーに通知するよう求めることを検討し、新しいバージョンの展開前にベンダーがパフォーマンス基準を満たすことを求め、必要に応じてロールバックすることを求めることをお勧めします。

2025年12月11日のもう一つのメモ、OMB M-26-04は、M-25-22を「補完する」ものであると述べています。大規模言語モデル契約については、機関がベンダーに要求すべき情報のリストを掲げています。受け入れ可能な使用方針、モデル、システムまたはデータカード、エンドユーザーリソース、およびエンドユーザーフィードバックのメカニズムです。また、機関は評価結果などより多くの情報を求めることもできます。

これらのメモは連邦機関を拘束するもので、民間企業を拘束するものではありません。それでも、高度なAI購買者が何を求めるかについての最も詳細な公開声明であり、民間調達チームは直接その構造を借用できます。

EUの導入者: AI法が購買者に求めること

EU AI法である規則(EU)2024/1689は、AI システムを自らの権限下で使用する組織を「導入者」と呼びます。高リスクAIシステムを購入して運用に投入する場合、第26条はベンダー側の義務とは別に、あなたに対する義務を課します。欧州委員会のAI法サービスデスクに公開されている統合テキストでは、第26条は以下のように述べています。

• 導入事業者は、「当該システムに付属する使用指示に従ってシステムを使用することを確保するため、適切な技術的及び組織的措置を講じなければならない」(第26条第1項)。
• 導入者は「当該システムに附属する使用方法に従って当該システムを使用することを確保するための適切な技術的および組織的措置を講じなければならない」(第26条(1))。
• 導入者は「必要な能力、訓練および権限を有する自然人に人的監視を割り当てなければならない」(第26条(2))。
• 導入者は「使用方法に基づいて高リスクAIシステムの運用を監視」しなければならず、当該システムがリスクをもたらすと考える理由がある場合は、プロバイダーまたは流通業者および関連する市場監視当局に通知し、使用を中止しなければならない(第26条(5))。
• 導入者は「当該高リスクAIシステムにより自動的に生成されるログを」その範囲内にある限り、他の法律に別段の定めがない限り少なくとも6か月間保管しなければならない(第26条(6))。

これらの義務はいずれも、ベンダーからしか得られない情報に依存しています。受け取ってもいない使用説明書に従うことはできませんし、システムが出力しないログを保存することも、測定する手段のない挙動を監視することもできません。第13条は、この取引のベンダー側の責務を定めたものです。高リスクシステムには、とりわけ「その精度の水準、評価指標、堅牢性およびサイバーセキュリティに関する情報」を含む使用説明書が付属していなければなりません(第13条(3)(b)(ii))。デューデリジェンスとは、こうした資料が実際に存在し、自社の責務を果たすのに十分な内容であることを確認する作業です。

タイミングが重要です。デジタルオムニバス改正の下で、第113条は現在、附属書IIIに記載されたスタンドアロンシステムについては2027年12月2日から、附属書Iの対象となる製品に組み込まれたAIについては2028年8月2日から、ハイリスク規則を適用することとしています。本日締結する契約の多くは、これらの日付の時点でもなお有効であることが想定されるため、今のうちに該当義務を契約条項に盛り込んでおくことが賢明です。これとは別に、第4条は、AIシステムの提供者および導入者一般に対し、ハイリスクシステムに限らず、それらを運用・利用する従業員の「AIリテラシーの向上を支援するための措置を講じる」ことを求めています。より広範な法的状況については、当社のEU AI法および米国AI法の完全ガイドをご覧ください。

任意の各種フレームワークも同じ方向性を示しています

NIST AI Risk Management Frameworkのコアでは、サードパーティAIが独立したカテゴリーとして扱われています。GOVERN 6.1には「サードパーティ事業者に関連するAIリスクに対応する方針および手続きが整備されている」、GOVERN 6.2には「高リスクと判断されるサードパーティのデータまたはAIシステムにおける障害やインシデントに対処するための緊急時対応プロセスが整備されている」とあり、MANAGE 3.1では、サードパーティリソースに起因するリスクを「定期的に監視し、リスク管理策を適用かつ文書化する」べきであるとされています。貴社がすでにNIST AI RMFに準拠している、あるいはISO/IEC 42001マネジメントシステムを運用している場合、調達するAIについてこれらの要件を満たす手段となるのがベンダーデューデリジェンスです。NIST AI RMF、ISO/IEC 42001および関連規格に関するガイドでは、各フレームワークがどのように連携するかを解説しています。

評価すべき6つの領域

すべてのAIベンダーレビューは、最終的に6つの領域に行き着きます。

1. システムの概要と目的

まず確認すべきは適用範囲です。この製品の基盤となっているのはどのモデルか、そしてベンダーはその開発元なのか、それとも他社のモデルを包んだ単なる再販業者なのか。ベンダーが文書化している使用目的は何か、御社が計画している用途はその範囲内に収まっているか。EU AI Actの下では、使用説明書に最初に明記すべき項目が使用目的であり、その範囲外でシステムを使用することは、ベンダーが一度も検証していないリスクを引き受けることを意味します。

2. 安全な挙動を示す根拠

このエリアは、多くの購入担当者が最もうまく対応できていない領域です。なぜなら、質問票で尋ねるのが最も難しい項目だからです。「バイアスのテストは実施していますか」と聞けば、どの企業も「はい」と答えます。より適切な質問は、その手法と結果を具体的に尋ねるものです。何をテストしたのか、どのようなシナリオに対して、どの程度の合格率で、誰が、いつ実施したのか。押さえておくべき行動リスクは、A.E.G.I.S.™フレームワークの7つの柱に対応しています。

• Hallucination Integrity: プレッシャーがかかる状況、曖昧な状況、専門領域に関する質問に直面した際、システムは虚偽の内容を事実であるかのように述べることはないか。
• Guardrail Resistance: ジェイルブレイクやプロンプトインジェクションの試みによって、安全でない挙動へと誘導され得るか。
• Hallucination Integrity: システムは特に圧力、曖昧性、または領域固有の質問の下で、虚偽を事実として述べますか。
• Guardrail Resistance: ジェイルブレーク試行またはプロンプトインジェクションを通じて不安全な動作に操作されることができますか。
• Data Handling & Privacy: 個人データを含め、何を収集し、保持し、漏らしますか。
• Adversarial Robustness: 動機のある攻撃者に対して、どの程度耐性を持っていますか?
• Explainability and Transparency: その振る舞いを理解し、事後に監査することができますか?

これらのそれぞれが実際にどのようにテストされるかについては、AI システムの安全性テスト方法についての完全ガイドをご覧ください。購入者にとって重要な区別は、ベンダーが自社について生成した結果と、第三者が生成した結果の間のものです。内部テストには価値がありますが、これはベンダーが自分自身の宿題を採点しているようなものです。M-25-22 は「独立して検証または再現可能」なほど詳細なテストを求めることで、購入者側から同じポイントを述べています。

3. データ取り扱い

データがどこに行くのか、どのくらいの期間保持されるのか、誰がアクセスできるのか、そしてそれが何かをトレーニングするのかを尋ねてください。M-25-22 の連邦基準は有用なベンチマークです。ベンダーは契約のために「合理的に必要」な場合にのみ機関情報を収集および保持することができ、非公開のインプットおよびアウトプットは、同意なしに公開または商用モデルのトレーニングに使用されてはなりません。システムのログがあなたにとって利用可能かどうかも尋ねてください。EU の高リスクシステム展開者はログを自分たちの管理下に保つ必要があるからです。

4. 監督とコントロール

システムが誤っているときに、人間ができることを調べてください。オペレーターはアウトプットをレビューまたはオーバーライドできるか、あるいはシステムを一時停止できるか?Article 26(2) は、あなたが監督のために適切な人員を配置することを前提としています。ベンダーはそれらの人員が使用できるものを提供する必要があります。

5. 変更管理と監視

AI 製品はあなたの下で変更されます。新しいベースモデルまたは再トレーニングにより、あなたが承認した振る舞いは、もはや本番環境で実行される振る舞いではなくなります。ベンダーが重大な変更についてどのように通知するのか、新しいバージョンがユーザーに届く前にテストできるのか、そしてバージョンをロールバックできるのかを尋ねてください。M-25-22 は機関に 3 つすべてを検討または要求することを求めています。その後、本番開始後に存在する監視は何か、そして結果があなたと共有されるかどうかを尋ねてください。

6. インシデントと責任

有害なアウトプットや成功したジェイルブレイクなどの AI 固有の障害に対するベンダーのインシデント対応プロセスをお尋ねください。EU の高リスクシステム展開者は、システムがリスクを提示していると考える場合、プロバイダーと市場監視当局に通知する必要があるため、契約により、ベンダーがそのような場合にあなたと協力することを確認する必要があります。記録されている AI インシデントとテストが検出するものについてのガイドは、計画する価値のある障害パターンを示しています。

AI ベンダーに送信できる質問リスト

これらを RFP にコピーしてください。各項目はあなたが確認できるものを求めています。

スコープと目的

1. 製品の電力を供給するモデルはどれか、各モデルを開発するのは誰か、本番環境では現在どのバージョンが使用されているか?
2. 文書化された目的の使用目的は何か、また、どのような用途に対して警告していますか?使用上の注意または同等のドキュメンテーションをお送りください。
3. 製品のモデル、システム、またはデータカードを公開していますか?それらを添付してください。
4. エンドユーザーの許容利用ポリシーは何ですか?

テストと根拠

5. 製品をテストした安全性リスクはどれか(例えば、幻覚、ジェイルブレイクとプロンプトインジェクション、プライバシー漏洩、脆弱なユーザーとの振る舞い、自律性の限界、敵対的攻撃、説明可能性)?それぞれについて、方法と結果は何か?
6. これらのテストのいずれかは独立した第三者によって実施されたか?誰が、いつ、どのバージョンに対して実施されたか、また、結果を自分たちで確認できるか?
7. 独自の評価を実行するためのアクセスと時間を与えてくれるか、あなたが見えないテストデータを使用するか?
8. 文書化された精度、堅牢性、およびサイバーセキュリティレベルは何か、またそれらはどのように測定されたか?

データ

9. 使用からどのようなデータを収集および保持しているか、どのくらいの期間保持しているか、そして各項目が必要な理由は何か?
10. 弊社のインプットやアウトプットが、貴社またはサードパーティーのモデルの訓練や改善に使用されることはありますか。それを契約上禁止することはできますか。
11. モデルプロバイダーを含むどのサブプロセッサーが弊社のデータにアクセスしますか。
12. システムはどのようなログを生成し、それらをエクスポートして保持することはできますか。

制御、変更およびインシデント

13. 当社のオペレーターが利用できる人間による監視および無効化のための管理機能にはどのようなものがありますか。
14. オペレーターが利用できるヒューマンオーバーサイトおよびオーバーライドコントロールにはどのようなものがありますか。
15. モデルまたはその動作に対する重大な変更があった場合、どのような形で、いつ通知していただけますか。新バージョンを本番環境に配信する前にテストでき、ロールバックできますか。
16. 導入後の製品監視はどのように行われ、監視結果を弊社と共有していただけますか。
17. AI固有の障害に対するインシデント対応プロセスはどのようなものですか。また、弊社への通知上の責務は何ですか。

回答を契約条件へ落とし込む

質問票の回答は表現です。契約がそれを義務に変えます。M-25-22はトピックのテンプレートを提供し、民間の購入者はそれほど大きな変更を加えることなく適応させることができます。

• 性能および安全性に関するコミットメント。 テスト済みの挙動を契約書に明記してください。文書化された精度・安全性のレベル、定期的なレビュースケジュール、そして結果がそれを下回った場合の対応方針です。
• パフォーマンスおよび安全性に関するコミットメント。テスト済みの動作を契約に記載してください。文書化された精度および安全レベル、定期的なレビュースケジュール、および結果がそれ以下に低下した場合の対応を含めます。
• 評価権。貴社自身でテストを実施するか、独立した第三者によるテストを実施する権利を確保し、ベンダーからのアクセスと時間を確保してください。
• データ使用制限。書面による同意なしにインプットおよびアウトプットでの訓練を禁止し、保持期間を必要な範囲に限定し、サブプロセッサーを明記してください。
• 変更通知。重大なモデル変更の事前通知および本番環境に適用する前のテストウィンドウを要求し、ロールバックオプションを備えてください。
• ログと記録。システムに必要なログを生成してエクスポートするよう要求し、ベンダーが自身のログを保持する期間を設定してください。
• インシデント協力。AIインシデントの通知タイムラインを設定し、貴社が負う報告義務を果たすのを支援する義務を設けてください。

M-26-04は、有用な起草技術を一つ追加しています。各省庁に対し、特定の要件を「契約に基づく受給資格および支払いに重要な事項」として特定するよう求めているのです。安全性および透明性に関する条項を重要事項とすることで、これらの条項に実効性が備わります。なぜなら、これに違反することが単なる注記ではなく、救済措置の根拠となるからです。

デューデリジェンスが行き詰まる典型的なポイント

失敗に終わるAIベンダー審査の多くは、いくつかの予測可能なパターンに当てはまります。

アンケートとは、AIに関する質問を後付けで追加した、セキュリティ用フォームに過ぎません。AICPA自身の説明によれば、SOC 2レポートとはセキュリティ、可用性、処理の完全性、機密保持、プライバシーに関連するサービス組織の内部統制を検証するものです。これ自体には価値がありますが、モデルがジェイルブレイクされ得るか、あるいはどの程度の頻度で事実を捏造するかという問いとは、別の問題に答えるものです。情報セキュリティとAIの挙動は、それぞれ別個のセクションとして、別個のエビデンスとともに扱うべきです。

すべての回答は自己申告です。レビュー担当者はフォームや添付されたポリシーの内容を検証する手段を持たないため、購入者は検証不能な申告をそのまま受け入れるか、自ら独自の検証テストを発注するかのいずれかを選ばざるを得ません。

すべての回答は自己報告されている。レビュアーはフォームまたは添付ポリシーを検証する方法がないため、購入者は検証できない主張を受け入れるか、独自のテストを依頼するかのいずれかです。

承認が永続的なものとして扱われている。購入から6ヶ月後にベンダーがモデルを変更し、誰も再チェックしていません。M-25-22とNIST AI RMFの両方が、正確にこの理由で監視を継続的なものとして扱っています。

検証可能な独立した評価がプロセスを短縮する理由

最後の2つの問題が費用のかかるものです。AIシステムが標準フレームワークに対して独立した第三者による評価を受けた場合、購入者にとって3つのことが変わります。

まず、証拠が独立しています。RateAIはシステムの評価に利害関係を持たず、その料金は評価の成果ではなく評価のマイルストーンに紐付けられています。システムは認証に不合格となる可能性があり、その場合、開発者は詳細な調査結果報告書と改善方法を受け取り、問題が修正されれば再評価に入ることができます。

次に、証拠が比較可能です。すべてのA.E.G.I.S.™評価は同じ7つのピラーをスコアリングし、スコアリングパラメータは評価の時代によって固定されているため、評価は時間の経過とともに比較可能なままです。認証を受けたシステムはA.E.G.I.S.™スコアカードを受け取り、A(最高の安全性)からF(危険)までの総合安全性格付け、各ピラーの格付け、A-5 Guardianからあるいはそれ以下のA-1 Unrestricted まで の認証シールが付きます。レビュアーは、1つの場所でシステムの強みと注意が必要な部分を確認でき、同じスケールで2つのベンダーを比較できます。

第3に、証拠が検証可能で最新です。すべてのプロンプトケース、バリデーター投票、認証決定はSHA-256ハッシング処理により一度の書き込みのみ可能な監査証跡でチェーンされているため、記録は改ざんまたは遡及的に変更されることはありません。誰でもログインなしで公開Safety Registryでx RateAI認証を確認でき、それが最新であり、格下げされていないことを確認できます。認証には再認証サイクルも付随し、システムへの重大な変更は再評価をトリガーします。これは上記の変更管理の問題に直結しています。

評価は貴社のデューデリジェンスに代わるものではありません。スコープ、契約条件、データフロー、ユースケースへの適合についての回答はまだ必要であり、RateAI認証は法的決定ではありません。これはコンプライアンス作業をサポートし、規制上の決定は関連当局の管轄下にあります。RateAIのProおよびEnterpriseティアはEU AI Act、NIST AI RMF、ISO 42001へのコンプライアンスマッピングを含みます。検証可能な評価が行うことは、上記のリスト内の質問5から8の証拠の問題に、信頼する代わりに貴チームが確認できるもので回答することです。第三者認証がどのように機能するかについての詳しい説明は、AI安全認証とは何か、そしてどのように機能するのかを参照してください。

実用的なデューデリジェンスワークフロー

1. ユースケースを分類します。 システムが誰に影響を与えるか、独立して行動できるか、EU AI Actの下で高リスクの可能性があるかを判断します。ステークスが高いほど、より詳細なレビューが必要です。
2. 質問リストを早期に送ります。 RFPに含めて、回答できないベンダーがデモに時間を投資する前に脱落するようにします。
3. 独立した証拠を確認します。 ベンダーの製品をクレームされているインディペンデントレジストリで検索し、評価、日付、バージョンが購入しようとしているものと一致することを確認します。
4. 残されているものをテストします。 独立した証拠がない、またはユースケースをカバーしていない場合は、ベンダーが見たことのないデータでご自身の評価を実行するか、評価を依頼してください。
5. 条件を交渉します。 回答を契約上の義務に変換します:パフォーマンス、テスト権、データ使用、変更通知、ログ記録、インシデント、ポータビリティです。
6. 監視の頻度を設定します。 パフォーマンスをどのくらいの頻度で確認するか、また再確認をトリガーするもの(モデルの変更や報告されたインシデントなど)に合意します。
7. 決定を記録します。 証拠、スコア、承認の理由を保持します。

このプロセスのベンダー側にいる場合、同じリストは購入者が何を尋ねるかを教えてくれます。質問票が到着する前に独立した証拠を用意することで、その後のすべての営業サイクルが短縮されます。RateAIの認証および監視ティアは、エンゲージメントがどのようにスコープされるかについて説明しており、1つのAIエージェントの無料安全ベンチマークは出発点として利用できます。

よくある質問

AIベンダーのデューデリジェンスとは何ですか?

購入前にAIベンダーのシステム、データ慣行、統制をチェックし、その後それらのチェックを最新の状態に保つプロセスです。通常のソフトウェアレビューと比較して、幻覚、ジェイルブレーク耐性、プライバシーリークなどのシステムの動作のテストを追加します。

SOC 2レポートだけでAIベンダーを承認するのに十分ですか?

通常、単独ではそうではありません。SOC 2レポートはサービス組織のセキュリティ、可用性、処理整合性、機密性またはプライバシーに関連する統制を調査するため、偽りの回答、操作、出力を通じたデータ漏洩など、AIモデルの動作方法についての個別の証拠はまだ必要です。

EU AI Actは、AIを購入する企業に何を要求していますか?

高リスクAIシステムを使用する組織は第26条の「デプロイヤー」であり、その指示に従ってシステムを使用し、有能な人間の監視を割り当て、その動作を監視し、ログを自分の管理下に保ち、場合によっては影響を受ける人々に通知しなければなりません。これらの高リスク規則は、Annex IIIシステムについては2027年12月2日から、Annex Iに含まれる製品に組み込まれたAIについては2028年8月2日から適用されます。

AIの購入契約にはどのような条件を含める必要がありますか?

最小限:パフォーマンスと安全性のコミットメント、独立テストの権利、トレーニングのためのデータ使用の制限、モデル変更の事前通知とテスト、ログアクセス、インシデント協力、ポータビリティです。OMBメモM-25-22は、これらのほとんどをUS連邦AIコントラクトの必須トピックとしてリストしています。

独立したAI安全評価は調達にどのように役立ちますか?

これは自己報告型の主張を、第三者によって作成され、ご自身で検証できる標準化された結果に置き換えます。A.E.G.I.S.™ レーティングは、評価対象のすべてのシステムと同じ7つの柱に基づいてシステムを採点するため、ベンダー間で比較し、認定が公開安全レジストリで最新であることを確認できます。

RateAI 認定によって AI システムは法的にコンプライアンスを満たしますか？

いかなる認定もその判断を下すことはできず、正式な規制上の決定は関連当局に属しています。RateAI 認定はコンプライアンス業務を支援し、Pro および Enterprise ティアには EU AI Act、NIST AI RMF および ISO 42001 へのコンプライアンスマッピングが含まれています。

署名する前にベンダーのレーティングを確認してください

最速のデューディリジェンス質問は、システムが既に独立した評価を受けているかどうかです。RateAI Safety Registry を検索して、認定を受けた AI システムがどのようにリストアップされているか、それらの A.E.G.I.S.™ レーティングと認定ステータスを確認し、ベンダーにそれらの製品がそこに掲載されているかどうかをお問い合わせください。