TL; DR
「AIリスク管理」とは、同じ名称を持つものの、正反対の2つの分野を指す。 AIによって生じるリスクを管理することと、AIを使ってリスクを管理することは全く異なる作業です。多くの組織は、前者を実施しながら後者を売り込まれ、どちらについても適切に報告していません。
- GenAIのリスク管理は、ガバナンスの問題である以前に、まず発見の問題である。 数えたことのない財産を管理することはできませんし、財産目録はしばしば
.mcp/servers.json誰も開いていないファイル commitテッド。 - リスク管理におけるAIは、3つの職種でその地位を確立している。 相関関係、説明、そして量。AIは判断を下すのが得意ではないため、AIが提案を行い、誰かがそれを見る前に何らかの決定論的なチェックが行われる。
- この二つの分野は、ある一点で交わる。 リスク管理のために導入するAI自体が、モデル、ツールへのアクセス権限、認証情報などを備えたAI資産です。それは、自社の資産管理ツールとして管理されるべきものです。
- まずは数を数えることから始め、政策を策定することから始めない。 発見前に作成されたポリシーは、架空の財産について記述している。1枚のスライドに示された3つの数字は、誰も検証できない枠組みよりも優れている。
なぜ「AIリスク管理」という言葉は、現在では2つの異なる意味を持つようになったのでしょうか？
検索ボックスにそのフレーズを入力すると、全く異なる2つの図書館が表示されます。
1つは AIが生み出すリスク予測不能な挙動を示すモデル、想定以上の権限を持つエージェント、大規模な欠陥のある生成コードの出荷、規制当局による実行状況の照会。これらをGenAIリスク管理と呼ぶべきでしょう。
もう一つは リスク管理機能のツールとしてのAIアラートの優先順位付け、リスク状況の要約、是正措置の策定、スタックトレースを読めない人への調査結果の説明などを行うモデル。リスク管理のためのAIとでも呼べるでしょう。
両者は名前、予算項目、そして多くの場合スライドを共有しているが、同じ分野ではない。一方は防御的で、何が問題になる可能性があるかを問う。もう一方は運用的で、手作業をやめるべきことは何かを問う。 CISこれらを混同すると、業務量を削減しないガバナンス方針と、誰もリスク評価を行っていない自動化プログラムに行き着くことになる。
資金配分の区分を明確にすることは、単なる形式主義ではありません。それは、組織が実際にどちらの資金提供を行っているのかを把握する最も迅速な方法です。
GenAIのリスク管理には、どのような内容が含まれるべきでしょうか？
3つの層があり、そのうちモデルは1つだけです。
- AIが書いたもの。 生成されたコードは、人間が書いたコードと同じ脆弱性を抱えており、レビューが処理できる速度をはるかに超えて生成される。この層は最も馴染み深いものであるため、ほとんどすべての注目を集める。
- AIに組み込まれているもの。 スキル ファイル、ルール ファイル、MCP サーバー構成、ツール スコープ、エージェントが実行される資格情報。プレーン テキスト、 commitドキュメントと同様に作成され、ドキュメントと同様にレビューされ、アシスタントが到達できる範囲を定義します。これは、攻撃が成功した場合、攻撃がどこまで及ぶかを決定するレイヤーであり、エンドポイントを介してモデルをテストするあらゆるものから見えません。
- AIが取り込むもの。 依存関係、モデル、データセット、外部ツール。攻撃者は、エージェントが考案したパッケージ名を登録できるため、もはやメンテナーを侵害する必要はありません。2025年のUSENIX Securityで発表された研究では、16のモデルにわたって2.23万のコードサンプルが生成され、推奨パッケージの19.7%が存在しないことが判明し、20万5000を超える固有の架空の名前が生成されました。
第1層のみを対象とするGenAIリスク管理プログラムは、クリーンなレポートと変化のないリスクプロファイルを生成します。 LLM アプリケーション向け OWASP トップ 10 この現実に基づいて構成されています: 過剰な主体性は上位にランクされますcisそれはモデルの問題ではなく、配線の問題だからです。
そして、これら3つの層はすべて、それらよりもさらに地味なものに依存している。つまり、自分がどのようなAIを持っているのかを知る必要があるのだ。発見は、GenAIリスク管理への予備段階ではなく、残りの部分を支える基盤であり、ほとんどのプログラムが静かに停滞する場所でもある。
リスク管理におけるAIの実際の強みとは？
マーケティング的な側面を抜きにすれば、率直な答えは限定的ではあるが、非常に価値のあるものだ。リスク管理におけるAIは、3つの職種においてその地位を確立している。
- 相関。 6つのツールが、6つの異なる深刻度で同じ結果の6つのバージョンを生成する。これらが同じ問題であり、同じ構成要素にあり、根本原因は1つであると判断することは、人間がゆっくりと一貫性なく行う、面倒なパターン分析作業である。
- 説明。 発見から修正までのギャップは、通常、理解不足にある。脆弱性の経路、影響を受けるコンポーネント、影響範囲を明確に説明することで、「修正しない」としてクローズされたチケットが、実際に解決されるチケットへと変わる。
- ボリューム。 コーディング担当者が1週間に1000個のファイルを生成するようになると、レビューは管理機能を失い、単なる待ち行列になってしまう。人間がそのような規模に対応できるわけではなく、どれだけ人員を増やしても状況は変わらない。
リスク管理におけるAIの弱点は、意思決定です。検証されていない修正案を提案するモデルは、機能のふりをした負債です。有効なパターンは、AIの推論と決定論的分析を組み合わせることです。AIが提案を行い、非確率的な何らかの手法が、その提案がポリシーに準拠しているか、悪用可能性、破壊的変更の影響があるかを、誰にも見られる前にチェックします。
もう一つ、あまり目立たないメリットがあります。自社のスキャナーの検出結果をトリアージするのと同じインテリジェンスが、他社の検出結果もトリアージできるのです。AIレイヤーを既存のツールに置き換えるのではなく、その上に配置すれば、リスク管理におけるAIは移行プロジェクトではなく、既存のツール群への追加要素となります。これは通常、今四半期に開始できるプログラムと来年開始するプログラムの違いを生むものです。
リスク管理におけるAIの問題点とは？
3つの故障モードがあり、いずれもよくあるものです。
- 根拠のない自信。 AIが生成したリスク概要は読みやすく、出典も明記されていない。監査担当者がその数値の算出方法を尋ねた際、「モデルがそう言った」という回答は通用しない。リスク管理プログラムにおけるすべての出力は、発見事項、ファイル、そして該当行へと遡って追跡可能な経路を持たなければならない。
- ゲートのない自動化。 有能なエージェントがいると、つい問題を解決させてしまいたくなる誘惑に駆られます。しかし、本番コードに反映されるものについては、必ず担当者が承認する必要があります。 pull requestこれは臆病さではなく、 EUAI法 いずれにせよ、既に一度変更された段階的なタイムラインで、あなたをその方向へ押し進めます。承認ポイントを今構築するには、設計コストがかかります。cisイオン。監査の下でそれを改修するには、四半期の費用がかかります。
- 露出度ではなく、普及度を測定する。 「私たちのチームはリスク管理にAIを日常的に活用しています」というのは利用状況を示す統計データに過ぎません。リスクが減少したかどうかについては何も示していません。
この2つの分野はどのように融合するのか？
これは、まだ誰もスライドに載せていない部分です。
リスク管理のために導入するAI自体が、AI資産である。 それは1つまたは複数のモデルを持ち、ツールへのアクセス権を持ち、ソースコード、調査結果、そして多くの場合、機密情報まで読み取ります。認証情報に基づいて実行され、MCPサーバーに接続する可能性があります。GenAIのリスク管理インベントリにそれが含まれていない場合、インベントリは間違っており、その欠陥は、最も特権的なシステムに存在することになります。
これにより、2 つの分野が 1 つのプログラムになります。セキュリティ AI は、開発者がインストールした AI と同じインベントリに格納されます。承認状態を持ち、名前付きの所有者がいます。スコープが設定され、ログが記録され、ゲートが設定されます。 pull request リポジトリへの書き込みアクセス権を持つ他のものと同様です。
リスク管理におけるAIの導入を、単なるツール購入と捉える組織は、最初の監査でそのことに気づき、気まずい話し合いを強いられることになるでしょう。一方、AIをリスク管理とツール導入の両方として捉える組織は、取締役会からの質問に対して、単一のインベントリ、単一のリスクモデル、そして単一の回答を用意することができます。
効果的なAIリスク管理運用モデルとはどのようなものだろうか？
6つの機能があり、それぞれに所有者の名前と、動作していることを示す何らかの証拠が付けられています。
| 機能 | それがカバーするもの | 誰が所有しているのか | それを証明するものは何か |
|---|---|---|---|
| AIによる発見 | モデル、エージェント、データセット、MCPサーバー、コーディングツール、セキュリティAIを含む | アプリケーションセキュリティリーダー | A ライブ在庫 資産ごとに承認状態 |
| AIリスク検出 | 迅速なインジェクションパス、安全でないエージェント境界、悪意のあるスキルとルールファイル | アプリケーションセキュリティリーダー | 調査結果は 認められたフレームワークファイルと行付き |
| サプライチェーンスクリーニング | 署名が存在する前にAIが取り込む依存関係 | アプリケーションセキュリティリーダー | スクリーニング判定 パッケージあたり、週あたり |
| AI支援によるトリアージ | すべてのツールにおける相関関係、説明、優先順位付け | セキュリティ運用 | 開発者に届く調査結果の減少 |
| 人間ゲート | 本番コードに到達するもの全てに対する承認 | プラットフォームまたはDevOpsリーダー | エージェントが執筆した作品の割合 pull requests 人間の承認者と共に |
| レポート作成 | 上向きの姿勢 | CISオフィス | エクスポート可能なAI-BOMと、取締役会が活用できる3つの数値 |
人々が忘れがちなのは、最初の行、2番目の節です。 セキュリティAI 自分のインベントリに保管してください。
どのように始めますか？
保険契約ではそうはいきません。発見前に作成された保険契約は、架空の財産について記述したものです。
セキュリティチームが導入したAIも含め、ソフトウェア内で実行されているAIの数を数えましょう。この段階で担当者名を公表すると、利用が隠蔽され、せっかく得た可視性が損なわれるため、担当者名を伏せた上で、社内でのみその数を公表してください。次に、チームが実際に必要とするものを反映した承認済みリストを作成し、問題が発生した場合に復旧不可能な少数の要素（悪意のある依存関係、有効な認証情報、規制対象データに触れる未承認モデルなど）は、アクセスを制限しましょう。
2027年にAIリスク管理で苦戦するのは、迅速に行動した組織ではなく、2026年をAIポリシーの策定に費やし、何も数値化しなかった組織だろう。
これはポジションです ザイゲニ このシステムは、開発者がインストールしたAIとセキュリティチームが導入したAIを網羅する単一のインベントリ、開発者の調査結果と他のツールが生成する調査結果に適用される単一のリスクモデル、そして本番コードに到達するすべてのものを承認する担当者を中心に構築されました。
2つの分野、1つの在庫。これらが別々のプログラムで、それぞれ別の担当者がいる状態から脱却すればするほど、どちらも早く機能し始めるだろう。
FAQ
AIリスク管理とAIガバナンスは同じものですか？
ガバナンスは、誰が何を、どのような条件下で、どのような承認を得て使用できるかといったルールを定めます。AIリスク管理は、実際に何が稼働しているかを把握し、それが生み出すリスクを測定し、それを軽減するための運用作業です。リスク管理を伴わないガバナンスは、誰も検証できないポリシーを生み出します。ガバナンスを伴わないリスク管理は、誰も行動を起こす権限を持たない調査結果を生み出します。ほとんどの組織は、後者よりも前者のほうがはるかに多いのが現状です。
遺伝子・人工知能（GenAI）のリスク管理を解決する前に、リスク管理にAIを活用することは可能でしょうか？
はい、ほとんどのチームがそうするでしょう。なぜなら、運用上のプレッシャーは即座に発生し、ガバナンス上のプレッシャーは四半期ごとだからです。ただし、セキュリティAI自体を後から追加するのではなく、初日からインベントリに登録しておくことが条件です。資産を1つインベントリに追加するだけなら簡単ですが、監査担当者のために18か月分の記録されていないアクセス履歴を再構築するのは容易ではありません。
AIリスク管理プログラムは、どのフレームワークに準拠すべきでしょうか？
その NIST AI リスク管理フレームワーク は最も広く受け入れられている語彙であり、統治、マッピング、測定、管理という4つの機能により、取締役会が認識できる構造を提供します。NISTは目指すべき成果を示し、OWASPは実際の攻撃の様子を示すため、技術層についてはOWASP GenAIの作業と組み合わせてください。どちらも何をカウントすべきかは示さないため、それはあなたの責任となります。cisイオン。
リスク管理におけるAIは人員削減につながるのか？
それをうまく活用しているチームではそうではありません。それはチームの1日の作業内容を変えます。相関関係、トリアージ、および最初の説明はモデルに移行し、人間の時間はデータ処理に移ります。cis結果を伴うイオン：何が規制されるのか、どのようなリスクが誰によって受け入れられるのか、そして実際に生産を脅かす発見はどれなのか。もし事業計画が人員削減に基づいている場合、そのプログラムは2四半期以内に誤った指標で評価される傾向がある。
