ほとんどのエンタープライズAIは、社内で構築されていません。Gartnerによれば、2025年までに、70%を超える組織が第三者プロバイダーから提供される少なくとも1種類のAIを導入すると予測されていました［1］。この割合はその後さらに増加しています。しかし、多くの組織が依拠しているガバナンス・フレームワークは、自らが管理するソフトウェアを前提に設計されたものであり、見たことのないデータで学習され、設定していないスケジュールで更新され、ベンダー自身にとってさえ不透明であり得るロジックで動作する確率論的システムを前提としていません。

規制環境は、この現実に追いついてきました。2025年に段階的施行期間に入ったEU AI Actは、プロバイダー（AIシステムを開発または市場投入する者）とデプロイヤー（自らの権限の下でそれを利用する者）を明確に区別しています。しかし、この区分はデプロイヤーの責任を免除するものではありません。第26条は、高リスクAIシステムのデプロイヤーが、人による監督、入力データ品質、モニタリング、記録保持に関して具体的な義務を負うことを明確にしています［2］。調達・コンプライアンス部門にとって耳の痛い真実は次のとおりです。モデルを構築したのがベンダーであるという理由だけで、規制上の責任がベンダーへ移転することはありません。

本ガイドは、初期デューデリジェンスから継続的モニタリングに至るまで、構造化されたAIベンダー・リスク評価フレームワークを提示します。

なぜ第三者AIリスクには異なるアプローチが必要なのか

従来のベンダーリスク管理では、稼働率、データセキュリティ、契約上のSLAを評価します。これらはAIベンダーに対しても引き続き必要ですが、それだけでは不十分です。AIシステムは、従来のIT調達では想定されていなかったリスク領域をもたらします。

第三者AIを他のソフトウェアと根本的に異ならせる特性は、次の3点です。

意思決定ロジックの不透明性。従来のSaaSアプリケーションは決定論的なコードを実行します。一方、AIシステムの出力は、デプロイ組織が可視化できない学習データ、ファインチューニングの選択、推論時パラメータに左右される場合があります。与信スコアリングモデルが申請を却下したり、HRスクリーニングツールが候補者を順位付けしたりする場合、デプロイヤーはその判断を説明する必要があります。ベンダーが意味のある説明を提供できなければ、デプロイヤーは解釈できない結果に対して責任を負うことになります。

静的ではない挙動。従来のソフトウェアはバージョン管理されたリリースによって変更されます。AIモデルは、再学習、ファインチューニング、基盤データパイプラインの変更により、正式なリリースサイクルなしに挙動が変化することがあります。調達時には許容範囲内であったモデルが、その後数か月でドリフトする可能性があります。デプロイヤーがそれに気づくのは、損害が既に発生した後かもしれません。

継承されるデータリスク。モデルの挙動を形成する学習データには、バイアス、著作権保護コンテンツ、または十分な法的根拠なしに処理された個人データが含まれる可能性があります。デプロイヤーは、それらの上流の選択に関与していなくても、その帰結を引き受けることになります。GDPRの下では、AIシステムがデプロイヤーのデータ処理契約と整合しない方法で個人データを処理した場合、デプロイヤーはプロバイダーと並んで執行リスクを負います［3］。

従来のベンダースコアカードでは、これらの力学を捉えきれません。目的に特化した評価フレームワークが不可欠です。

構造化されたAIベンダー・リスク評価フレームワーク

以下のフレームワークは、AIベンダー評価を7つの領域に整理しています。各領域は特定のガバナンス上の懸念に対応し、調達時、定期レビュー時、またはトリガーに基づく再評価時にスコアリングできます。

Enzaiのようなプラットフォームを利用する組織は、このフレームワークを既存のベンダーライフサイクル・ワークフローに統合し、AI固有の基準を、分断された別プロセスではなく、従来のITリスク指標と並行して扱うことができます。

評価質問票

この表は、継続的に更新される運用手段として扱うべきです。スコア閾値はユースケースによって異なります。例えば、医療トリアージで用いる高リスクAIシステムには、低リスクのコンテンツ推薦ツールよりもはるかに厳格な透明性が求められます。

ベンダーに確認すべき重要な質問

質問票は、質問が実質的リスクを露出できるだけの具体性を持つ場合にのみ機能します。曖昧な質問は曖昧な回答を招きます。以下の質問はカテゴリ別に整理され、実行可能な回答を引き出すよう設計されています。

モデルの透明性と説明可能性

1. このシステムはどのモデルアーキテクチャを使用しており、現在本番環境で展開されているバージョンは何ですか。

2. 想定ユースケース、既知の制限、性能ベンチマークを記載したモデルカードまたは技術データシートを提供できますか。

3. 影響を受ける個人に対して、個別予測または判断を説明するために利用可能な手法は何ですか。

4. モデルが第三者の基盤モデル（例：LLMプロバイダー）に基づく場合、どの基盤モデルおよびバージョンを基盤としているか開示できますか。

データガバナンスとプライバシー

5. このモデルの学習・検証にどのデータセットを使用し、データ来歴記録を提供できますか。

6. 学習における個人データ処理の適法根拠は、GDPR（または同等規制）の下で何ですか。

7. モデルは推論時に学習データを保持、記憶、再現しますか。データ漏えいを防ぐ保護措置は何ですか。

8. デプロイ後に顧客データはどのように利用されますか。モデル学習に再投入されますか。顧客はオプトアウトできますか。

バイアス、公平性、安全性

9. このモデルは、適用される差別禁止法で定義される保護特性について、バイアス監査を受けていますか。

10. 監査は誰が実施し、結果はレビュー可能ですか。

11. サブグループ間での新規バイアスや性能劣化を検知するため、どのような継続的モニタリングを実施していますか。

12. 生成AIシステムの場合：有害、誤解を招く、または法的に問題のある出力生成を防ぐガードレールは何ですか。

セキュリティとレジリエンス

13. 敵対的攻撃、プロンプトインジェクション、モデル反転、または学習データ抽出に対して、どのような具体的防御策がありますか。

14. 当該システムは、標準的なアプリケーションセキュリティ試験を超えて、AI固有のペネトレーションテストまたはレッドチーミングを受けていますか。

15. 本サービスのAIコンポーネントに特化した災害復旧および事業継続計画は何ですか。

コンプライアンスと規制対応準備

16. このシステムはEU AI Actのリスク区分で分類されていますか。分類されている場合、その分類結果は何ですか。

17. 第43条で要求される高リスクAIシステムの適合性評価に関する文書を提供できますか。

18. 当社が事業展開する法域において、適用されるAI規制への完全準拠に向けたタイムラインは何ですか。

インシデント対応と説明責任

19. 貴社のAI固有インシデント対応計画は何であり、インシデント分類のトリガーは何ですか。

20. 当社デプロイメントに影響するAI関連インシデントに関する契約上の通知期限は何ですか。

21. 過去のAIインシデントの事例と、その解決方法を提示できますか。

すべての質問がすべてのベンダーに当てはまるわけではありません。しかし、明らかに適用される質問に対して信頼できる回答が欠けていること自体が、重要な所見です。

ベンダー回答におけるレッドフラッグ

ベンダー評価では、回答内容そのものだけでなく、組織がどのように回答を受け取るかも同様に重要です。ベンダー回答における特定のパターンは、より厳格な精査を引き起こすべきです。

機密性を装った曖昧さ

営業秘密を保護する正当な根拠はあります。しかし、モデルの一般的なアーキテクチャファミリー、使用した学習データのカテゴリー、またはバイアステストの有無の開示を拒むベンダーは、知的財産を守っているのではありません。リスクを覆い隠しているのです。透明性に関するあらゆる質問に対して「当社モデルは独自仕様のため詳細は共有できない」と答えるベンダーは、デプロイヤーの規制義務を支援できるベンダーではありません。

文書の欠如

ベンダーがモデルカード、データガバナンスポリシー、またはインシデント対応計画を提示できない場合、最も可能性が高い説明は、それらが存在しないということです。文書がないことは中立的な所見ではありません。それは、責任ある導入を支えるために必要なガバナンス基盤へ投資していないことを示します。

監査権への抵抗

契約上の監査権に反発するベンダーは、それが運用上困難であるとか商業的に不合理であるといった理由づけであっても、慎重に扱うべきです。EU AI Actは、デプロイヤーがプロバイダーの準拠を検証する必要性を明示的に想定しています［4］。監査条項に抵抗するベンダーは、精査に耐えない可能性があります。

インシデント対応プロセスがない

「AIインシデント対応計画は何ですか」という問いに対し、沈黙、一般的なITインシデント管理への誘導、または今後策定するとの約束しかない場合、組織は、ベンダー支援なしでAI障害の全責任を負う準備があるかを検討すべきです。

責任転嫁の文言

AIの結果に関する責任をすべてデプロイヤーに転嫁しようとする契約文言に注意してください。デプロイヤーに義務があることは事実ですが、モデル性能、バイアス、障害について一切責任を受け入れないベンダーは、自社システムへの信頼に関して何らかのシグナルを発しています。

重要なのは個別回答よりもパターンです。実際の制約を透明に示すベンダーは、証拠なしに完全性を主張するベンダーより、はるかに低リスクです。

AI調達における契約上の保護

評価は必要ですが、それだけでは十分ではありません。所見は、強制可能な契約条件に組み込む必要があります。標準的なソフトウェア調達契約には、AI固有リスクに十分対応する条項が含まれていないことが一般的です。以下の条項は、あらゆるAIベンダー契約への組み入れを検討すべきです。

監査権

契約では、デプロイヤーに対し、合理的な間隔で、かつ特定のトリガー事象（報告済みインシデントや規制当局からの照会など）の発生時に、ベンダーのAIシステムを直接または独立した第三者を通じて監査する権利を付与すべきです。この権利は、モデル性能データ、バイアステスト結果、データガバナンス実務にも及ぶべきです。

インシデント通知

契約では、AI関連インシデントに関する最大通知期限を、一般的なサービスインシデントとは区別して明記すべきです。高リスクシステムでは、発見から24時間以内の通知が合理的な出発点です。通知には、インシデントの性質、影響を受けるシステム、推定影響、是正手順を含めるべきです。

データ取扱いと保持

契約では、AIシステムに関連して顧客データがどのように使用されるかを正確に規定すべきです。すなわち、モデル改善に使用されるか、どのように保存されるか、いつ削除されるか、顧客が学習データセットからの削除を要求できるか、です。これは、AI学習とデータ保護権の交点に対する継続的な規制上の注目を踏まえると、とりわけ重要です［5］。

モデル変更通知

契約では、ベンダーに対し、新規データでの再学習、アーキテクチャ変更、重要なパラメータ調整を含むモデルの重大変更について事前通知を義務付けるべきです。通知期間は、更新モデルが当該組織の環境で本番導入される前に、デプロイヤーがテストを実施できる長さであるべきです。緊急でない変更について30日の通知期間は、合理的な基準値です。

性能ベンチマークとSLA

従来の稼働率SLAに加え、契約ではAIシステムに対する測定可能な性能ベンチマーク（精度閾値、公平性指標、レイテンシ要件など）を設定すべきです。これらのベンチマーク違反は、定義済みの是正義務、および必要に応じて契約解除権を発動させるべきです。

責任配分

契約では、各当事者の管理可能性の程度を反映した形で、AI関連損害に関する責任を配分すべきです。モデル、学習データ、更新サイクルを管理するベンダーは、それらのコンポーネントの欠陥について比例的な責任を負うべきです。ベンダーに一方的に有利な包括的補償は、AI導入には適切ではありません。

強固な契約はガバナンスを代替しませんが、ガバナンスを実効化する執行メカニズムを提供します。

継続的モニタリング：一度きりの評価を超えて

調達時に一度実施して保管するだけのAIベンダー評価は、リスク管理実務ではなく、コンプライアンス上の成果物にすぎません。AIシステムは変化し、提示されるリスクも同様に変化します。

継続的モニタリング指標

組織は、複数の側面で継続的モニタリングを確立すべきです。

• 性能ドリフト。調達時に設定したベンチマークに対してAIシステムの出力品質を追跡します。劣化は、モデルドリフト、データパイプライン問題、または非開示のモデル変更を示唆する可能性があります。

• インシデントの頻度と重大度。ヒヤリハットを含むすべてのAI関連インシデントを記録し、時系列で傾向分析します。異常出力の頻度増加は調査を要します。

• 規制動向。システムのリスク分類を変更したり、デプロイヤーに新たな義務を課したりする可能性のある、適用AI規制の変更を監視します。

• ベンダーの財務・運営安定性。財務的困難に直面するベンダーは、モデル保守、セキュリティ、コンプライアンスへの投資を縮小する可能性があり、これらはいずれもデプロイヤーへ直接影響します。

再評価トリガー

以下の事象は、定期レビューサイクル外であっても、ベンダーの全面的再評価を引き起こすべきです。

• ベンダーが大規模なモデル更新またはアーキテクチャ変更を発表した場合

• 当該組織のデプロイメントに関するもの、または公表されたものを問わず、重大なAIインシデントが発生した場合

• 規制ガイダンスによりAIシステムのリスク分類が変更された場合

• 組織がAIシステムの利用方法を変更し、リスクプロファイルに実質的な変化が生じた場合

• ベンダーが買収、合併、または重要な経営陣変更を行った場合

ガバナンス・ワークフローへのモニタリング組み込み

実効的な継続的モニタリングには、善意だけでは不十分です。ベンダー監督を既存のガバナンス運用周期に統合するツールが必要です。Enzaiは、継続的な第三者AIモニタリングのための基盤を提供し、評価結果、契約義務、リアルタイム性能指標を単一のガバナンス・ワークフローへ接続します。この統合がなければ、モニタリング義務は時間とともに形骸化し、最も警戒が必要な時点で組織を無防備にします。

ガバナンスは単発のイベントではありません。継続的な実践です。

第25条の罠：デプロイヤーがプロバイダーになるとき

EU AI Actでもっとも重大でありながら理解が十分でない規定の一つは、デプロイヤーがプロバイダーへ再分類される状況に関するものです。第25条は、デプロイヤーが、すでに市場にある高リスクAIシステムに自己の名称または商標を付して市場投入する場合、高リスクシステムに実質的改変を加える場合、AIシステムの意図された目的を高リスクとなるよう変更する場合、または元のプロバイダーとの合意の下で第三者が既に市場投入した後に当該高リスクシステムを市場投入する場合、プロバイダーとみなされると規定しています［6］。

これは、第三者AIをカスタマイズする組織に直接的な影響を及ぼします。ベンダーのモデルを独自データでファインチューニングすること、追加の処理レイヤーで出力を変更すること、またはベンダーが示す意図された目的と実質的に異なるユースケースに導入することは、いずれも再分類を引き起こすのに十分となり得ます。

再分類の帰結は重大です。プロバイダーは、高リスクシステムに関するEU AI Act上の義務（適合性評価、技術文書、市販後モニタリング、EUデータベースへの登録を含む）を全面的に負担します。これらの義務は、デプロイヤーに課されるものより大幅に重いものです。

この罠を回避するための実務的ステップ

• 意図された目的を文書化する。AIシステムについてベンダーが示す意図された目的と、組織の実際のユースケースを明確に記録してください。乖離がある場合は、法務・コンプライアンスチームでレビューすべきです。

• カスタマイズ範囲を評価する。第三者AIシステムのファインチューニング、再学習、または実質的改変の前に、その変更が本法上の「実質的改変」に該当するかを評価してください。この点に関する欧州委員会のガイダンスにより今後明確化が見込まれますが、リスクは現時点でも存在します［7］。

• 契約上の明確化。ベンダー契約で、どちらの当事者がプロバイダーでどちらがデプロイヤーかを明確に区分し、その分類が変更され得る条件を明記してください。

• 早期に法的助言を得る。プロバイダーとデプロイヤーの境界は、ラベルではなく実質の問題です。契約で自らをデプロイヤーと呼んでも、実態としてプロバイダーとして行為しているという事実認定を覆すことはできません。

第25条の罠は仮説ではありません。組織がベンダーAIシステムのカスタマイズやファインチューニングを進めるほど、デプロイと提供の境界は、AI規制において最も活発に争われる領域の一つになる可能性が高いと考えられます。

防御可能な第三者AIプログラムの構築

第三者AIベンダーのリスク評価は、調達時のチェックボックスではありません。法務、技術、運用の各領域にまたがる、継続的なガバナンス規律です。このリスクを効果的に管理できる組織は、財務統制やデータ保護と同等の厳格さでAIベンダー監督を扱う組織です。

本稿で示したフレームワークは出発点を提供します。すなわち、構造化評価、具体的質問、契約上の保護、継続的モニタリング、そしてデプロイヤーを一夜にしてプロバイダーへ変え得る規制上の罠への認識です。規制環境下で高リスクAIシステムを導入する組織にとって、これらはいずれも任意ではありません。

第三者AIガバナンスを大規模に運用化したい組織に対して、Enzaiは、ベンダー評価の管理、義務の追跡、AIポートフォリオ全体にわたる継続的監督を実現するプラットフォーム基盤を提供します。実運用での仕組みをご確認いただくために、デモをご依頼ください。

参考文献

［1］ Gartner, "Gartner Predicts 70% of Organisations Will Shift Focus to AI Governance," 2024.

［2］ European Parliament and Council, Regulation (EU) 2024/1689 (EU AI Act), Article 26 - Obligations of Deployers of High-Risk AI Systems, 2024.

［3］ European Data Protection Board, "Opinion on the Interplay Between the AI Act and the GDPR," 2024.

［4］ European Parliament and Council, Regulation (EU) 2024/1689 (EU AI Act), Article 13 (Transparency and provision of information to deployers) and Article 26 (Deployer obligations), 2024.

［5］ European Data Protection Board, "Guidelines on the Use of Personal Data in AI Model Training," 2025.

［6］ European Parliament and Council, Regulation (EU) 2024/1689 (EU AI Act), Article 25 - Responsibilities along the AI value chain, 2024.

［7］ European Commission, "Guidelines on Substantial Modification of AI Systems" (forthcoming), referenced in Recital 88 of the EU AI Act.