AIのセキュリティ審査とは

著者: Brian Tr · 更新日: 2026年10月6日

AIのセキュリティ審査とは、ベンダーのAIプロダクトが自社のデータに触れることを許可する前に、企業の買い手が行う正式なチェックです。始まりは通常のソフトウェアベンダー審査と同じで、質問票、認証、アーキテクチャに関する質問、契約条件を確認します。そのうえで、プロダクトにモデルが含まれているからこそ存在するリスクについて、第2層の質問が加わります。プロンプトインジェクション、機密情報の漏えい、ユーザーに代わってアクションを実行するソフトウェアなどです。

AIスタートアップにとって、確実に見えた商談が何週間も停滞するのは、この審査の段階であることが少なくありません。一方で、この審査は予測可能でもあります。審査担当者が使うフレームワークは公開されており、質問は買い手が変わっても繰り返し出てきます。作業の大半は、誰かに聞かれる前に証拠を準備しておくことです。本ページでは、審査とは何か、標準的なSaaSの審査とどう違うか、その背景にある主なフレームワーク、審査が進む段階、そして準備すべきものを説明します。

AIのセキュリティ審査とは何か

セキュリティ審査は、買い手側のデューデリジェンスのプロセスです。買い手のセキュリティ、リスク、またはIT部門のチームが、ベンダーのプロダクトを自社のデータとともに使ってよいか、どのような条件でなら使えるかを判断します。結果は通常、承認、必要な修正を条件とする条件付き承認、または却下のいずれかです。

一般的な営業の会話とは2つの点で異なります。相手はプロダクトを欲しがっている人ではなく、リスクの責任者です。そして、証拠は書面で残す必要があります。審査担当者は、後でその判断を別の誰かに説明しなければならないからです。

AIの営業では、この審査が単独で行われることはめったにありません。データに関する条件の法務審査と並行して進み、最近ではAIガバナンスについての別の確認も加わることが増えています。テーブルの向こう側に誰が座っているのか、そしてなぜセキュリティが拒否権を持ちがちなのかについては、AIの購買委員会をご覧ください。

標準的なSaaSの審査との違い

標準的なSaaSのセキュリティ審査は、ベンダーがデータを保護し、規律ある運用をしているかを問います。AIの審査は、それをすべて問ったうえで、モデル層がデータの喪失、操作、損害を引き起こす新たな経路を生んでいないかを問います。ベースラインはそのまま引き継がれ、AI層はそれに上乗せされます。

創業者が過小評価しがちなのは、挙動の行です。従来のソフトウェアは決定論的なので、審査担当者は設計から推論できます。モデルの出力は固定されていないため、審査担当者は代わりにテストの証拠を求めます。これはAIプロダクトでデモがより重要になる理由で扱っている評価の取り組みにつながります。

ベースライン: 質問票と認証

AI特有の質問に入る前に、ほとんどの審査では同じ基本事項を確認します。

セキュリティ質問票。 買い手は、標準化された質問票か独自の質問票を送ってくることがよくあります。広く使われている標準形式としては、Shared AssessmentsのSIG(Standardized Information Gathering)質問票と、Cloud Security AllianceのCAIQの2つがあります。CSAのCloud Controls Matrixのページは、CCMを主要な標準に対応付けられたクラウド特有のセキュリティ管理策のメタフレームワークと説明しており、CSA STAR Registryへの提出用のSTAR Level 1版を含むCAIQも併せて配布しています。同じ質問票に何度も回答するのは無駄なので、記入済みで最新のCAIQかSIGを1つ持っているスタートアップは、その大部分を再利用できます。

SOC 2。 SOC 2レポートは、サービス提供組織の管理策に対する独立した検証です。AICPAのSOCスイートのページは、こうしたサービスが対象とする5つの領域として、セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシーを挙げています。所定の期間を対象とするレポートは、企業の審査担当者が求める単独の資料として最も一般的なものです。

ISO/IEC 27001。 情報セキュリティマネジメントの国際標準で、特に米国以外の買い手からよく求められるもう1つの資料です。

SOC 2やISO 27001は、AIに関する質問には答えてくれません。審査担当者に伝わるのは、あなたの組織が管理されたプロセスを運用しているということであり、それは入場券にすぎません。まだ取得していない場合はそう伝え、スケジュールを示し、根底にある質問に直接答えられるよう準備しておきましょう。アーリーステージのスタートアップは、明確な書面の回答と定められたロードマップで審査を通過することもよくありますが、そのリスクを受け入れる買い手の範囲は狭まります。

審査担当者が確認するAI特有のリスク

審査担当者は、AIのリスク分類をゼロから作るわけではありません。多くは、OWASP GenAI Security Projectが公開しているOWASP Top 10 for LLM Applicationsに頼っています。2025年版では、次の10のリスクが挙げられています。

1. プロンプトインジェクション(Prompt Injection)
2. 機密情報の開示(Sensitive Information Disclosure)
3. サプライチェーン(Supply Chain)
4. データとモデルのポイズニング(Data and Model Poisoning)
5. 不適切な出力の取り扱い(Improper Output Handling)
6. 過剰なエージェンシー(Excessive Agency)
7. システムプロンプトの漏えい(System Prompt Leakage)
8. ベクトルと埋め込みの脆弱性(Vector and Embedding Weaknesses)
9. 誤情報(Misinformation)
10. 無制限の消費(Unbounded Consumption)

このうち5つは、ほぼすべての審査で取り上げられます。

プロンプトインジェクション。 モデルを操作して指示を無視させるテキストです。ユーザーから直接届くこともあれば、文書、Webページ、メールなど、モデルが読み込むコンテンツを通じて間接的に届くこともあります。審査担当者が問うのは、攻撃者があなたのプロダクトに何をさせ、何を明かさせることができるか、そしてモデルがだまされた場合にどのような制限が働くかです。

機密情報の開示。 プロダクトが、ある顧客のデータを別の顧客にさらしたり、出力やログで機密データを明かしたりする可能性はあるでしょうか。テナント分離、検索時のアクセス制御、ログ記録の運用が精査されるのはここです。

サプライチェーン。 あなたのプロダクトは、サードパーティのモデル、オープンソースのコンポーネント、データセット、場合によってはプラグインに依存しているはずです。審査担当者は、それが具体的にどれか、誰が更新しているか、提供元が条件を変更したりインシデントを起こしたりした場合に何が起きるかを知りたがります。

不適切な出力の取り扱い。 モデルの出力は、システムのほかの部分にとって信頼できない入力です。検証なしにデータベース、ブラウザ、シェルに渡されれば、それはインジェクションの経路になります。モデルが書いたコマンドを誰かがそのまま実行するのが典型的な例です。

過剰なエージェンシー。 OWASPはこれを、予期しない、あいまいな、または操作されたモデルの出力に応じて、損害を与えるアクションが実行されてしまう脆弱性と定義しています。原因として、過剰な機能、過剰な権限、過剰な自律性の3つを挙げています。エージェント型のプロダクトでは、プロダクトが答えるだけでなく行動するため、これが中心的な問いになることがよくあります。エージェント特有の観点については、AIエージェントのセキュリティをご覧ください。

審査担当者が引用するフレームワーク

質問票やポリシー文書には、4つの名前が登場します。それぞれが何であり、何でないかを知っておけば、過大な主張を避けられます。

NIST AI RMF。 NISTによると、2023年1月26日に公開されたAI RMF 1.0は、組織がAIの設計、開発、利用、評価に信頼性を組み込む方法を改善するための任意利用を想定したものです。NISTは2024年7月26日に生成AIプロファイル(NIST-AI-600-1)を公開しました。プロファイル自体の説明によると、プロファイルとは特定の状況に向けてフレームワークの機能を実装したものであり、このプロファイルは生成AIに特有の、または生成AIによって悪化するリスクを定義したうえで、それらを統治、把握、測定、管理するための行動を提案しています。「NIST認証」というものは存在しません。「準拠している」と言えるのは、自社の取り組みを実際に対応付けた場合だけです。

ISO/IEC 42001。 この標準は、AIマネジメントシステムの確立、実施、維持、継続的改善のための要求事項を規定しており、AIを用いたプロダクトやサービスを開発、提供、または利用するあらゆる組織に適用されます。2023年12月18日に発行されました。マネジメントシステムの標準なので、認証とは監査人があなたのプロセスを評価したことを意味します。特定のモデル出力が安全であることを保証するものではなく、現在のほとんどの審査では必須でもありません。スタートアップにとっては、それを求める買い手に販売するようになった段階で差別化要因になります。

MITRE ATLAS。 MITREのATT&CKマトリックスをモデルにしたATLASは、攻撃者がAIを組み込んだシステムをどう攻撃するかを整理したものです。セキュリティチームは、脅威モデルやレッドチームのシナリオを作るためにこれを使います。スタートアップが「ATLAS準拠」を求められることはまれですが、脅威モデルでこれを引用すれば、検討がきちんと行われたことを示せます。

審査の段階

買い手ごとにプロセスは異なりますが、ほとんどは同じ流れをたどります。

1. 受付。 買い手の調達部門またはセキュリティチームがベンダーの申請を受け付け、関係するデータを分類し、どこまで深く審査するかを決めます。顧客の個人データを扱ったり基幹システムに接続したりするプロダクトは、公開コンテンツを扱うプロダクトよりも深く審査されます。
2. 書類のやり取り。 セキュリティの概要、SOC 2またはISOのレポート、記入済みの質問票、データ処理に関する条件、再委託先のリスト、アーキテクチャ図など、手元にあるものを送ります。
3. 質問票と確認。 審査担当者が回答を確認し、追加の質問を送ってきます。AI特有の質問は通常ここで届きます。顧客データでの学習、モデル提供元、ガードレール、ログ記録などです。
4. 技術的な詳細確認。 リスクの高い導入では、買い手のセキュリティエンジニアとのミーティングが行われます。アーキテクチャ、テナント分離、プロンプトとツールの扱い方、テスト結果を見せるよう求められることがあります。
5. 必要に応じたテスト。 ペネトレーションテストを自ら実施したり依頼したりする買い手や、モデル層の敵対的テストの証拠を求める買い手もいます。
6. リスクの判断と是正。 審査担当者は、承認、条件付き承認、または却下を決めます。条件は契約上のコミットメントや、期日付きの是正計画になることがよくあります。
7. 契約締結と再審査。 審査の指摘事項は契約に反映されます。多くの買い手は、定期的に、または新しいモデル提供元や新しい自律機能など重要な変更があったときに再審査を行います。

時間的なコストは現実のものであり、だからこそ証拠のパッケージが重要になります。審査の結果が契約条件にどうつながるかは、AIのパイロット導入から契約へで扱っています。

AIスタートアップが準備しておくべき証拠

回答がすでに書面になっていれば、審査担当者の作業は速く進みます。実務的なやり方は、常に最新の状態に保ち、求めに応じて送れる常設のトラストパッケージを用意しておくことです。

精査に耐える回答を書きましょう。「当社はプロンプトインジェクションから守られています」といった主張は、満足に答えられない追加質問を招きます。どのベンダーもそれを約束できないからです。「信頼できないコンテンツはデータとして扱い、ツールの呼び出しはこの範囲に限定し、影響の大きいアクションには承認を必要としています」といった主張なら、審査担当者に確認すべき具体的なものを渡せます。あらゆる主張を証拠で裏付けるという同じ規律は、懐疑的な買い手へのAIの売り方全体にも通じています。

よくある間違い

• コンプライアンスについて過大に主張する。 どちらも事実でないのに「NIST準拠」や「ISO 42001認証取得」と言うのは、信頼を失い法的リスクを生む最短の道です。
• 自社のサプライチェーンを把握していない。 どのモデル提供元が顧客データを見ているかを説明できなければ、審査は止まります。
• エージェントの権限を軽視する。 便利だからという理由でエージェントに広範な認証情報を与えることは、まさに過剰なエージェンシーが指しているものです。
• 限界を隠す。 審査担当者は、沈黙よりも「これは既知の制約であり、これがその管理策です」という説明をはるかに高く評価します。エージェントのコンプライアンスの観点については、AIエージェントのコンプライアンスをご覧ください。

重要なポイント

• ベースラインとAI層: AIのセキュリティ審査では、標準的なベンダーチェック(質問票、SOC 2またはISO 27001、データに関する条件)を行ったうえで、モデル特有のリスクが加わります。
• OWASPのリスト: OWASP Top 10 for LLM Applicationsの2025年版は、プロンプトインジェクションから無制限の消費まで、10のリスクを挙げています。
• 過剰なエージェンシーには3つの原因がある: OWASPは、過剰な機能、過剰な権限、過剰な自律性を挙げています。
• NIST AI RMFは任意のもの: NISTは2023年1月26日にAI RMF 1.0を、2024年7月26日に生成AIプロファイルを公開しました。どちらも認証ではありません。
• ISO/IEC 42001は認証の対象になる: 2023年12月18日に発行され、AIマネジメントシステムの要求事項を規定しています。
• SOC 2は5つの領域を対象とする: AICPAによると、セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシーです。
• 再利用できる質問票がある: CSAは、STAR Level 1版を含むCAIQをCloud Controls Matrixとともに配布しています。

関連記事

• AIの買い手が尋ねるデータプライバシーの質問
• 営業資産としての信頼と評価
• 責任あるAIポリシーとは
• 懐疑的な買い手へのAIの売り方
• AIの購買委員会
• AIのパイロット導入から契約へ
• AIプロダクトでデモがより重要になる理由
• AIエージェントのセキュリティ
• AIエージェントのコンプライアンス