AIシステムのリスクアセスメント――企業は今、何から始めるべきか

生成AIの業務活用が広がるなか、多くの企業ではすでに何らかの利用ポリシーが整備されているのではないでしょうか。大手プロフェッショナルファームのデロイトトーマツが2025年7月、国内プライム上場企業の部長クラス以上700名を対象に調査したところ、「ガバナンス体制の整備」が生成AIの本格導入における主要課題に挙げられました^＊1。ポリシーがあっても統制が追いついていない背景には「AIのリスクをどう把握するのか」という課題があるのです。

生成AIのリスク管理をむずかしくしているのは「振る舞いの不確実性」です。コンピュータは同じ入力には同じ出力を返しますが、生成AIはそうではありません。同じ質問でも毎回異なる表現で回答し、想定と異なる出力を返すことがあります。また、外部サービスとして利用する場合、モデルの内部構造やデータ処理の実態を外側から完全に把握することは不可能です。

さらに、学習データに由来するバイアスが出力に現れることがあります。これは不確実性（毎回結果が変わる予測不能性）とは別の問題で、特定の判断や表現が系統的に偏る可能性です。不確実性とバイアスという二つの特性が重なることで、「なぜそう出力されたのか」という原因追跡がさらに困難になります。

そのため、 AIシステムのリスクアセスメントは「モデルの“内部”を理解する」ことを目標にしても限界があります。実践的なアプローチは「どんな文脈で、何に用い、どんなデータがわたり、出力が誤った場合の影響がどこにおよぶのか」という観察可能な側面に評価の焦点を当てることです。この視点の転換が、後述する国際的なフレームワークの設計思想にも反映されています。

総務省・経済産業省の「AI事業者ガイドライン」^＊2は、 AIに関わる組織を「AI開発者」「AI提供者」「AI利用者」の3者に大別し、リスクベースアプローチにもとづく対応を求めています。これにもとづいて自社の立場を確認することが、リスクのスコープを絞る出発点となります。以下では、この分類を枠組みとして、各立場に特有のリスクポイントを整理します。

「利用者」として生成AIサービスを使う企業は、まず「業務とAIの接点の棚卸し」から始める必要があります。「どの業務にAIが介在し」「どのようなデータがAIにわたっているのか」という2点が把握できていなければ、リスクアセスメントは始まりません。

ここで注意が必要なのは、 AIにわたるデータの範囲です。国内において個人情報は個人情報保護法によって取り扱いが規制されていますが、企業が保有するデータはそれだけではありません。未公開の事業情報・研究開発データ・顧客との契約内容・競争上の機密（営業秘密）など、多種多様なデータを外部のAIサービスに入力した場合、実際にどう処理・保持されるのかは、利用規約に明記されていないことも多く、記載があっても技術的な実態を保証するものではありません。既存のポリシーが「AI経由でデータが外部にわたるケースを想定しているか」を確認するところから始めるべきです。

「提供者」は、 AIシステムを他者（社内外を問わず）に提供・運用する立場です。ここでは社内向けAI基盤の整備を例に取りますが、その原則は外部向けサービスでも同様です。社内ナレッジをAIに活用させるためにRAG（検索拡張生成）が広く使われていますが、「誰のクエリに何のデータが返るのか」という制御が不十分な場合、本来閲覧権限のない情報が引き出される可能性があります。アクセス制御（誰が何にアクセスできるのかを管理すること）をシステムの設計段階から明確にし、構築後に検証する必要があります。

また、外部からの悪意ある入力によってAIの応答や動作が意図的に操作されるリスクは、提供者として運用する段階でも無視できません。プロンプトインジェクションはその代表的な攻撃手法であり、入力の検証と出力の監視を組み合わせた対策が必要です。さらに、 AIに外部システムやデータへのアクセス権限を与えて処理を自動実行させる構成では、付与する権限が広すぎると、誤作動や悪意ある入力をきっかけに想定外の操作が引き起こされる余地が広がります。 AIにわたす権限は必要最小限にとどめ、実行可能な操作の範囲を設計段階で限定することが求められます。

オープンソースLLMを社内で運用したり、ファインチューニングで独自モデルを構築する場合、「開発者」としての観点も加味する必要が生じ、訓練データへの汚染（ポイズニング）や、モデルの堅牢性の検証まで、責任範囲はさらに広がります。

リスクの識別・評価・対処のプロセスとして、ISO/IEC 23894（AIリスク管理ガイダンス）^＊3と、NIST AI RMF^＊4が参考になります。前者はAI固有のリスクを評価・管理するためのガイダンスであり、後者のMAP（文脈の特定）およびMEASURE（評価・追跡）と組み合わせることで、ブラックボックス化しているモデルの内部を問うことなく、「使い方・データの流れ・影響範囲」を軸にリスクを体系的に評価できます。

ISO/IEC 42001（AIマネジメントシステム規格）^＊5はこれらの評価活動を組織的な管理体制として定着させる枠組みです。基本構成やアプローチはISO/IEC 27001（情報セキュリティマネジメントシステム、 ISMS）など、他のマネジメントシステムと共通化されており、すでにISMSを運用している企業は既存の管理体制を基盤にAIマネジメントシステムを拡張できます。各フレームワーク間の対応関係は、NISTが公式のクロスウォーク（対応表）として公開しており^＊6、複数を参照する際の整合性確認に活用できます。

なお、 EU域内で事業を展開する組織は、EU AI Act（欧州AI規則）への対応も必要です。本稿では詳細を扱いませんが、自社のAIシステムのリスク分類と義務要件の確認を並行して進めることをお勧めします。

2026年にAnthropic社が発表した「Project Glasswing」^＊7は、 AIがセキュリティ分野にもたらす変化を象徴しています。未公開フロンティアモデル「Claude Mythos Preview」が、主要OS・ブラウザで数千件のゼロデイ脆弱性を発見しました。こうした能力を防御に活用するため、 AWS、アップル、マイクロソフト、グーグルなどと連携した大規模修正プロジェクトが立ち上がりました。重要なのは、こうした能力がClaude Mythosだけの話ではない点です。コーディング支援から脆弱性解析まで、多くの生成AIが問題の検出と検証を低コストで実施でき、守備側と攻撃側の双方がそれらを活用可能です。

これにより、 CVSSスコア（共通脆弱性評価システム）順に優先度を決め、担当者が順次対応するという従来のサイクルでは追いつかなくなる場面が増えることが予想されます。膨大な問題のなかから何を先に対処するのかを判断する「トリアージ能力」と、それを支える体制・プロセスの設計が、今後のセキュリティ運用においてより重要な役割を担うでしょう。もっとも、脆弱性を発見する能力そのものは、すでに複数の生成AIに広く備わっています。各国の規制がどうであれ、また個別の制限措置が講じられても、この能力が攻守の双方で使われ続ける状況は変わりません。

AIのリスクアセスメントは、完成形を目指して一気に構築するのではなく、現状把握を積み重ねながら精度を上げていくものです。出発点は自社で「どの業務にAIが介在しているのか」「どんなデータがわたっているのか」という2点の“棚卸し”です。これが把握できていなければ、どれほど精緻なフレームワークを参照しても、評価の対象が宙に浮きます。

まずは既存のセキュリティポリシーや情報管理規程に「AIが介在する場合」の記述があるか否かを確認することから始めてはいかがでしょうか。その答えが、体制整備の道標になるはずです。