サードパーティ製AIベンダーのリスク：自社で開発していないAIを評価する方法

エンタープライズ向けAIの大半は、社内で構築されていません。Gartnerによれば、2025年までに、企業の70%以上が第三者プロバイダーから提供される何らかの形態のAIを少なくとも1つ導入すると予測されていました[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プロバイダー）をベースにしている場合、どの基盤モデルとどのバージョンの上に構築しているかを開示できますか。

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

1. このモデルの学習および検証に使用されたデータセットは何ですか。また、データの出所記録を提供できますか。

2. 学習時の個人データ処理に関するGDPR（または同等の規制）上の適法な根拠は何ですか。

3. モデルは推論時に学習データを保持、記憶、または再現しますか。データ漏えいを防ぐためにどのような保護策がありますか。

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

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

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

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

3. サブグループ全体で新たに生じるバイアスや性能低下を検知するために、どのような継続的監視が行われていますか。

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

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

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

2. 標準的なアプリケーションセキュリティテストを超えて、AI特有の侵入テストまたはレッドチーミングを実施しましたか。

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

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

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

2. 第43条に基づき求められる、高リスクAIシステムの適合性評価に関する文書を提供できますか。

3. 当社の事業地域で適用されるAI規制に完全準拠するまでのタイムラインはどうなっていますか。

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

1. AI特有のインシデント対応計画は何ですか。また、どのような事象がインシデント分類のトリガーになりますか。

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

3. 過去の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ポートフォリオ全体にわたる継続的な監督を実現するプラットフォーム基盤を提供します。デモをご依頼いただき、実際の運用イメージをご確認ください。

Enzaiは、先進的なエンタープライズAIガバナンスプラットフォームです。抽象的な方針を実運用の監督へと移行するために設計されています。私たちのAIリスク管理プラットフォームは、エージェンティックAIガバナンスの管理、包括的なAIインベントリの維持、EU AI Act対応の確保に必要な専用インフラを提供します。複雑なワークフローを自動化することで、Enzaiは、企業がグローバル基準、たとえば ISO 42001 やNISTに整合しながら、自信を持って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), 第26条 - 高リスクAIシステムのデプロイヤーの義務, 2024年。

[3] European Data Protection Board, 「AI ActとGDPRの相互作用に関する意見」, 2024年。

[4] European Parliament and Council, Regulation (EU) 2024/1689 (EU AI Act), 第13条（透明性およびデプロイヤーへの情報提供）および第26条（デプロイヤーの義務）, 2024年。

[5] European Data Protection Board, 「AIモデル学習における個人データ利用に関するガイドライン」, 2025年。

[6] European Parliament and Council, Regulation (EU) 2024/1689 (EU AI Act), 第25条 - AIバリューチェーンに沿った責任, 2024年。

[7] European Commission, 「AIシステムの実質的修正に関するガイドライン」(予定), EU AI Actの前文88で言及。