AIセキュリティ診断の進め方｜検査範囲と報告書の選び方

2026年9月15日

公開日: 2026年9月15日

公式ドキュメント・公式発表などの一次情報を確認したうえで、株式会社Nexaが執筆・更新しています。AIツールの仕様や料金は変わることがあるため、導入判断の前に各公式サイトの最新情報もご確認ください。運営会社について

AIセキュリティ診断は「検査範囲・手法・報告書」の3軸で選び、モデルから連携先までの弱点を確認します。

範囲：生成AIだけでなく、検索する社内文書、利用者の権限、外部操作まで整理します。
手法：設計レビュー、設定確認、アプリ診断、レッドチーミング、自動評価を組み合わせます。
成果物：検出した問題だけでなく、再現条件、未評価の範囲、改修と再診断の条件を受け取ります。

対象読者：中小企業の経営者、DX推進担当者、情報システム部門

今日やること：利用中のAIシステムを1つ選び、接続先と権限を書き出す。

この記事の著者

株式会社Nexa 代表取締役川島陸

一橋大学経済学部卒業後、フォーティエンスコンサルティング株式会社（旧株式会社クニエ）にて法人向けAI導入支援等を経験。独立後、AI系メディア運営やDify/n8nの導入支援を経て、株式会社Nexaを創業。法人向けAI研修・AI導入支援・AI関連メディア運営を手掛ける。

詳しく見る AI顧問の無料相談

AIセキュリティ診断を依頼するときは、検査するシステムの範囲と、納品される報告書を先に決めます。同じ「AI診断」でも、チャットへの入力だけを調べるものと、社内検索や外部操作まで検証するものでは、確認できる問題が違うからです。

診断項目が多くても、自社の重要な連携が対象外なら安心材料にはなりません。公開された公式資料を基に、手法の違いから検査票、見積依頼の条件まで整理します。情報の確認日は2026年9月15日です。

AIセキュリティ診断とは何を確認するものか

AIセキュリティ診断は、AIを利用するシステムの弱点を調べ、業務への影響と改修の優先度を整理する活動です。

ここでの対象は、生成AIの回答、データの扱い、連携するアプリケーションなどです。脆弱性とは、攻撃や誤用により情報漏えいや不正操作につながる弱点を指します。「AIを使って従来のWebサイトを診断する」という診断作業の自動化とは区別します。

たとえば社内FAQボットなら、回答の正確さに加え、別部署の非公開文書を読めないかも検査対象です。一方、画面から会話を試すだけでは、提供企業のモデル内部や学習基盤を検査したことにはなりません。契約する範囲をシステム構成図に対応させます。

診断結果は、その時点の対象と試験条件に限られます。脆弱性が見つからなかったことを、将来も含む無条件の安全保証として扱わないことが出発点です。

診断対象は利用形態ごとに決める

診断範囲はSaaS利用、API組み込み、社内検索、外部操作の有無で変わり、自社が管理する境界から決めます。

SaaSは、提供企業が運用するソフトウェアをインターネット経由で利用する形態です。APIは、システム同士がデータや処理を受け渡す窓口を指します。自社の管理画面で変えられる設定と、提供企業だけが変更できる部分を分けてください。

利用形態	主な確認対象	勝手に含めない範囲
SaaSの生成AIを利用	アカウント、共有範囲、データ設定	提供企業の内部基盤への検査
APIを自社アプリへ組み込み	認証、入力、ログ、外部送信	提供モデルの学習基盤
社内文書を検索して回答	文書権限、検索条件、回答と引用	未接続の文書システム
AIが外部ツールを操作	実行権限、承認、操作記録	未許可の送信や削除

AIセキュリティ診断の対象範囲をSaaSとAPI、RAG、AIエージェントで比較 図1: 利用形態に応じて、モデルだけでなく連携先も検査範囲へ含めます。

複数の形態を組み合わせる場合は、範囲も重なります。サービス名だけで判断せず、「誰の権限で、何を読み、何を変更できるか」を担当者と確認するのが実務的です。

＼ AI導入の進め方を一緒に整理しませんか／

AI顧問の無料相談はこちら

AIセキュリティ診断の5つの手法を比較する

AIセキュリティ診断の手法は得意な確認対象が異なるため、設計資料の点検と実際の挙動の検査を組み合わせます。

下表は発注時に整理しやすいように分けた分類です。統一されたサービス名称ではなく、事業者によって呼び方や含まれる作業は異なります。

手法	主に確認する内容	求めたい成果物
設計レビュー	データの流れ、守る情報、責任分界	構成図への指摘と設計改善案
設定確認	アカウント、共有、権限、保存設定	設定値と推奨値の差分
アプリ脆弱性診断	Web/APIと生成AIの接続部分	再現条件と技術的な修正案
AIレッドチーミング	攻撃者や誤用者を想定した挙動	シナリオ別の証拠と業務影響
自動評価	用意した条件を繰り返すテスト	テスト条件、結果、判定根拠

レッドチーミングは、攻撃や誤用をする側の視点でシステムを試し、防御の弱点を探す活動です。Microsoftは生成AI製品のレッドチーミングに関する報告で、従来のセキュリティ問題も対象に含めています。

国内でも、三菱総研DCSの公式サービスは、入力による検査、設定確認、Web脆弱性との組み合わせをプラン別に示しています。名称が似ていても検査範囲は同じではありません。

AI導入に関するお困りごとは、株式会社NexaのAI顧問がサポートします。「何から始めればいいか分からない」という段階からご相談いただけます。

AI顧問の無料相談はこちら →

OWASPのリスク分類は版を指定して使う

OWASPの分類は診断項目の抜けを探す参考資料であり、版と対象範囲を決めて自社の検査項目に対応づけます。

OWASPは、ソフトウェアのセキュリティ向上を目的とするコミュニティです。OWASP GenAI LLM Top 10 2026では、大規模言語モデルを用いるアプリケーションの主要リスクを整理しています。大規模言語モデル（LLM）は、文章などを入力として回答を生成するモデルです。

2026年版の公式リポジトリにある分類は次のとおりです。日本語は内容を理解するための訳です。

番号	英語名称	確認する問題の例
LLM01	Prompt Injection	信頼できない入力による指示の上書き
LLM02	Sensitive Information Disclosure	機密情報の開示
LLM03	Excessive Agency	過剰な機能、権限、自律性
LLM04	Supply Chain	モデルや依存部品の供給網
LLM05	Data and Model Poisoning	データやモデルへの不正な混入
LLM06	Unbounded Consumption	処理量や費用の無制限な消費
LLM07	Misinformation	誤った情報の生成と利用
LLM08	Hidden Context Exposure	内部文脈の露出
LLM09	Vector and Embedding Weaknesses	類似検索や埋め込みの弱点
LLM10	Improper Output Handling	生成した出力の不適切な処理

旧版とは名称や番号が異なる項目があります。見積書に「OWASP準拠」とだけ書くのではなく、何年版のどの項目を、どの方法で確認するのかを明記してもらいます。

＼業務自動化のお悩みをAI顧問に相談できます／

AI顧問の無料相談はこちら

NIST AI RMFで診断後の責任を決める

NIST AI RMFは診断の合否証明ではなく、AIリスクの把握から測定、対応、責任分担まで整理する枠組みです。

米国国立標準技術研究所NISTは、AI Risk Management Frameworkを任意利用の枠組みとして公開しています。AI RMF 1.0の中心となる機能は、GOVERN、MAP、MEASURE、MANAGEです。これは必ず順番に一巡する手順表ではありません。

実務では、GOVERNを責任者と判断ルール、MAPを業務と影響の把握、MEASUREを評価、MANAGEを対処に結び付けます。診断会社が問題を報告しても、改修予算の承認や残るリスクの受容まで代行するとは限りません。

生成AI固有の論点には、NIST AI 600-1の生成AIプロファイルも参照できます。まず社内で、技術的な修正担当と、利用継続を決める業務責任者を別々に記入してください。

MITRE ATLASで検査シナリオを組み立てる

MITRE ATLASはAIへの攻撃を整理するための知識基盤であり、自社の入口と業務影響を結ぶ検査案に利用できます。

MITRE ATLASには、AIシステムに関係する攻撃の戦術や技法が整理されています。項目をそのまま全件実行するのではなく、自社の構成に関係する入口を選び、守りたい情報や機能と結び付けます。

たとえば公開Webページを参照するAIと、社内文書だけを検索するAIでは、信頼できない情報が入る場所が異なります。「外部文書を取得する」「文書の内容をAIへ渡す」「外部操作を行う」という流れを描くと、観測すべきログも決めやすくなります。

検査計画には、入口、期待する防御、失敗した場合の影響を並べます。攻撃技法名だけのチェックリストより、業務責任者が優先順位を判断しやすい形になります。

＼ AI活用の「次の一手」を一緒に考えませんか／

AI顧問の無料相談はこちら

プロンプトインジェクションは入力経路を分ける

プロンプトインジェクションは利用者の入力だけでなく、検索文書や外部ツールの出力からも起こるため、入口を分けて検査します。

プロンプトインジェクションは、信頼できない情報の中の指示がAIの挙動へ影響する問題です。質問欄に直接入力されるものだけでなく、AIが取得した資料の中に含まれるものもあります。OWASPの公式解説を基に、直接入力と取得情報を区別します。

検査では、文章が誘導されたかに加え、権限外のデータ参照や操作まで進んだかを確認します。不適切な回答が出ることと、社外へデータが送信されることでは、影響が違うためです。

防御を「不正な指示に従わない」という文章だけに頼らず、検索や操作を実行する側でも権限を検査します。診断報告書には、回答の記録と、実際に起きた処理の記録を分けて残してもらいます。

情報漏えいは出力と内部文脈を分けて評価する

情報漏えいの重大度は露出した情報と利用可能性で決まり、内部の指示が見えたことだけで一律に判定しません。

機密情報の出力は内容と到達先を確認する

個人情報や秘密情報が出た場合は、内容、閲覧できた利用者、送信先を確認します。検証用のダミー情報を使えば、実際の顧客情報を広げずに権限の分離を試せます。画面に出ない情報が、ログや外部連携先へ残る可能性も検査範囲に含めます。

内部文脈の露出と認可の欠陥を区別する

AIへ事前に与える指示や内部設定の露出は、その中身と影響で評価します。OWASPのHidden Context Exposureは、内部文脈を隠すことにセキュリティを依存させる問題を扱っています。

秘密鍵やアクセス用の認証情報を指示文へ入れないことが基本です。内部指示が知られても権限外の操作を拒否できるか、アプリケーション側の認可も確認してください。

RAGは検索権限と回答内容を別々に調べる

RAGの診断では、回答に秘密情報が出ないかだけでなく、検索段階で権限外の文書を取得しないかを確認します。

RAGは、関連する資料を検索し、その内容をAIへ渡して回答を作る方式です。社内規程やマニュアルを参照させる場合に使われます。文章の意味の近さで資料を探す類似検索と、誰が閲覧できるかを判定するアクセス制御は別の機能です。

OWASPのベクトル検索に関するリスク解説も参照し、部署や役割を変えた検査条件を作ります。検索結果、回答の引用先、キャッシュに権限外の情報が混ざらないかを確認します。

「回答には出さない」という制御だけでは、検索時に何を取得したかが分かりません。ダミー文書に識別用の文字列を入れるなど、検証時に取得範囲を追える証拠を用意すると、修正担当者へ説明しやすくなります。

AIエージェントは外部操作まで追跡する

AIエージェントの診断は会話の検査だけで終えず、接続する外部ツールの操作権限と承認の仕組みまで追跡します。

AIエージェントは、目的に応じて処理を選び、外部機能を使いながら作業を進めるシステムです。情報を読むだけの機能と、メール送信やデータ削除ができる機能では、誤動作の影響が異なります。

OWASPのExcessive Agencyでは、過剰な機能、権限、自律性が論点になります。業務に不要な機能を外し、利用者の権限を超える操作をさせない設計を検査します。

実務上の検査案としては、「読む」「下書きを作る」「送信する」を分離します。承認画面がある場合も、承認した宛先や内容と実行結果が一致するかを確認します。承認表示の有無だけで安全と判断しないでください。

WebとAPIの脆弱性診断も組み合わせる

生成AIを組み込んでも従来のWebとAPIの弱点は残るため、AI固有の検査とアプリケーション診断を併用します。

生成された文字列を画面へ表示したり、別の処理へ渡したりする部分には、出力を扱うための検証が必要です。たとえば、文字列を表示するための処理と、命令として実行する処理を混同すると、AIの回答が下流の問題につながります。

OWASPのImproper Output Handlingは、この出力処理の問題を扱っています。内容が正しいかを評価する誤情報対策とは、別の検査項目です。

既存のWeb診断を実施済みでも、AIから新たにデータが渡る箇所が増えれば再確認が必要です。見積依頼には、認証、ファイルアップロード、外部URLの参照など、AIの周辺機能も列挙します。

PyRITは自動評価と人の確認を組み合わせる

PyRITは生成AIのリスクを発見するための自動評価を支援しますが、業務への影響や最終判定は人が確認します。

MicrosoftのPyRITは、生成AIシステムのリスクを調べるオープンソースのフレームワークです。公式の構成説明では、対象、シナリオ、変換、採点などの要素を組み合わせる設計を確認できます。

自動化すると、設定したテストを繰り返し、変更前後を比較しやすくなります。しかし、採点が成功しても、業務上の被害を正しく分類したとは限りません。安全な回答を誤って問題扱いする場合も、問題を見逃す場合もあります。

検査ツールを使う場合は、ツールの版、対象モデル、評価設定、試行条件を残します。担当者が具体的な結果を読み、重大度の理由を説明できることを納品条件に含めましょう。

検査前に許可範囲と停止条件を合意する

AIの検査は所有者と提供者が許可した範囲だけで行い、本番影響や費用増を止める条件を開始前に合意します。

以下は検査準備の推奨例です。自社が契約するSaaSでも、提供企業の内部基盤まで自由に検査できるとは限りません。利用規約と診断に関する条件を確認し、必要な許可を取ります。

AIセキュリティ診断を安全に実施するための許可と検証環境、停止条件の準備 図2: 許可範囲、検証環境、停止条件、緊急連絡を検査前に決めます。

許可範囲：対象システム、利用アカウント、許可した操作、対象外を文書化する。
検証環境：本番から分離できる環境とダミーデータを用意する。
停止条件：負荷、実行回数、API費用、外部送信の上限を決める。
緊急連絡：異常時の中止判断者と連絡先を診断担当者へ共有する。

検査中に未知の接続先が見つかっても、その場で無断追加しません。範囲の変更を承認してから再開する運用にすれば、診断そのものによる事故を抑えられます。保存した検査ログの共有先と削除時期も、開始前の合意事項です。

サンプル検査票で判定条件をそろえる

検査票には期待する防御と確認する証拠を先に書き、問題を発見した状態と、まだ評価していない状態を区別します。

下表は検査設計の記入例であり、実測結果ではありません。対象業務に応じて行を追加し、実行後に判定と証拠の保存先を記入する想定です。

検査対象	期待する防御	確認する証拠	実施前の判定
社内文書の検索	権限外の文書を取得しない	利用者の役割と検索記録	未評価
外部操作	承認していない送信を実行しない	承認記録と操作記録	未評価
費用管理	合意した上限で処理を止める	利用量と停止記録	未評価
回答の表示	不適切な命令として実行しない	表示処理と検査記録	未評価

判定欄は「問題を確認」「検査条件内で問題を確認せず」「未評価」「対象外」などに分けます。未評価を合格に集計すると、検査できなかった重要機能が埋もれます。画面上の回答だけで判断できない項目には、どのログが必要かも事前に書いてください。

診断報告書は再現条件と対象外まで受け取る

診断報告書は問題一覧だけでなく、再現できる条件、影響、改修案、未評価と対象外の範囲まで受け取ります。

AIセキュリティ診断の報告書で確認する業務影響と再現条件、未評価、再診断 図3: 問題が見つからなかった項目と、まだ評価していない項目を区別します。

経営向けの要約は業務影響で整理する

経営向けには、何が起きると誰に影響するか、利用継続の判断、優先する改修をまとめます。技術的な難しさだけで重大度を決めず、扱う情報や操作できる範囲も評価理由へ含めます。

技術向けの詳細は修正と再確認につなげる

技術担当者には、環境、設定、試行条件、確認方法、証拠、推奨対策が必要です。ラックの公式サービス説明にも、報告書の総評、確認方法、緊急度、推奨対策などが示されています。

AIの応答は試行ごとに変わることがあるため、同じ入力で常に同じ結果になるとは限りません。成功した試行だけでなく、試した回数と結果の分布、再現に必要だった条件を記録すると、改修後の評価がしやすくなります。

費用と期間は検査範囲をそろえて比べる

AIセキュリティ診断の費用と期間は対象と手法で変わるため、同じ検査条件と納品条件で見積もりを比較します。

公式サービスでも、要件に応じた個別見積もりとしているものがあります。確認できない相場を一律に当てはめるより、作業量が増える要因を分ける方が予算を説明できます。

見積もりでそろえる条件	確認する内容
対象の数	システム、モデル、画面、APIの数
権限の種類	一般利用者、管理者、部署別の役割
接続先	社内検索、ファイル、外部操作の範囲
検査方法	自動評価と手動調査の範囲
実行費用	API利用料、検証環境費、上限と負担者
納品後	報告会、質問対応、再診断の条件

低い見積額でも、必要な権限テストや再診断が対象外なら後から追加費用が生じます。期間についても、環境準備、実検査、報告書作成、改修後の再診断を分けて確認します。

見積依頼テンプレで納品条件を具体化する

見積依頼では自社の構成だけでなく、必要な証拠と納品物を指定すると、診断会社ごとの提案を比較しやすくなります。

以下は発注条件を整理する推奨例であり、実際の診断案件や結果ではありません。機密情報や接続用の秘密情報を、そのまま問い合わせフォームへ入力しないでください。詳細は共有方法を合意してから渡します。

目的：公開前の利用可否判断／既存システムの変更時評価対象：システム名、利用モデル、画面とAPIの概要利用者：権限の種類と想定利用者データ：扱う情報の分類、検索対象、保存先接続先：外部ツールと許可する操作検査範囲：設計、設定、会話、Web/API、操作権限対象外：今回調べない部分と理由実施条件：許可済み環境、ダミーデータ、費用上限停止条件：本番影響、異常負荷、想定外の外部操作成果物：経営要約、技術詳細、証拠、未評価一覧再診断：対象範囲、実施期限、費用、結果報告ログ管理：共有先、保存期限、削除方法

提案を受け取ったら、対象外の欄から読んでみてください。自社が不安に感じている接続先がそこに入っていれば、契約前に検査範囲を調整できます。