この記事で分かること
- ユーザー企業に起きる被害が七つに分けられていること
- そのうち一つが金額として出てくること
- リスクの高さをどう決めることになっているか
社員が生成AIを使い、一部の業務をエージェントに任せ始めているとします。それにまつわる事故として、まず思い浮かぶのは情報が漏れることでしょう。
被害を七つに分けている
情報処理推進機構の産業サイバーセキュリティセンターが、生成AIおよびAIエージェントを安全に活用するための手引書を2026年7月31日に出しました。99ページあります。
手引書が想定しているのはユーザー企業です。AI開発者とAI提供者に固有の問題は、選定基準の段階で対象から外されています（手引書）。モデルの学習工程のリスクは扱いません。
第4章が、AIシステムによる被害を七つに分けています。情報の漏洩、付与権限外の操作、システムや内部データの改ざん、AIシステムのサービス停止、虚偽や低品質な出力の利用および出力の誤用、第三者への加害、そして過剰課金の発生です。
七つという数にも根拠が書かれています。ISO/IEC 27000が定義する情報セキュリティの7特性に照らし、企業活動に影響を及ぼす被害カテゴリを網羅するよう選ばれています（手引書）。フィジカルAIに起因する物理的事故と、将来的な人工超知能に関するリスクは対象外です。
七つ目の被害は請求額として出る
過剰課金の発生は、AIシステムへの悪意のあるリクエストや乗っ取り、または意図しない処理の反復による過剰利用で発生する金銭的被害です（手引書）。
挙がっている事例は2024年のものです。盗まれたクラウド認証情報でクラウドホスト型のLLMに不正アクセスする攻撃が特定されました。攻撃者はAIモデルへアクセスするリバースプロキシを構築し、他のサイバー犯罪者が無制限に利用できるサービスとして提供していました。被害企業は1日あたり最大4万6,000ドルの損失が試算されたとあります（手引書）。
原因として書かれているのは、APIキーの管理不備と、異常な利用量を検知する監視体制の欠如です。そして、コスト上限の未設定が被害額の拡大につながったとあります。
侵入を止める話ではありません。正規の権限がそのまま使われたときに、どこで気づいて、どこで頭打ちにするかの話です。
承認をプロンプトで書いても効かない
付与権限外の操作は、AIエージェントが外部のシステムと連携する場合に顕在化しやすいとされています。メール送信、ファイル操作、API呼び出し。最小権限原則が守られていない環境では特にリスクが高まるとされています（手引書）。
事例は2026年のものです。自律型のAIエージェントにメールのアクセス権を与えた結果、意図せず数百通が大量削除されました。原因の書き方が具体です。実行前の人間の承認ステップをシステム的な制御として組み込まず、プロンプトによる指示のみに依存していたと書かれています（手引書）。
指示文に「削除する前に確認すること」と書いても、それは制御ではありません。AIの処理限界による指示忘れや、不正な指示の読み込みが、そのまま被害になります。
リスクが高い観点が一つでもあれば、被害全体のリスクも高くなる
第5章が、被害ごとにリスクの高さを決める方法を示しています。評価は低・中・高の3段階で、対策を講じる前の大きさを表します（手引書）。
決め方が書かれています。すべての評価観点を評価したうえで、最も高いレベルをその被害の固有リスクとします。いずれか一つの観点でも高と評価される要素があれば、被害が発生した際の影響度は高となりうるためです（手引書）。
ただし、高が出た時点で評価を打ち切らないことも書かれています。総合評価が同じ高でも、どの観点が高いか、高と評価された観点がいくつあるかによって、リスクの性質や影響の広がりが異なるため、その結果が対策を選ぶ判断材料になります。
留意点がもう一つ置かれています。対策予定の有無によって、固有リスクを低く見積もらないことです。
禁止を先に置くと、見えない利用が増える
組織が未許可のAIシステムを使うこと、つまりシャドーAIについても方針が書かれています。悪意ではなく業務上のニーズから生じるため、禁止を先行させるだけでは申告されない利用が増え、実態把握がさらに困難になるとされています（手引書）。
ルールについても同じ留意点が置かれています。過度に厳格なルールは、AI利用者がそのルールを避けて使うことを招き、かえってリスクを高める可能性があります。禁止一辺倒ではなく、代替手段とセットでルールを策定することが望ましいとあります（手引書）。
発生要因として挙がっているのは、業務に使いたいのに公式な手段がない状況です。IT部門が安全性を検証した組織公認のAIを提供することが、対策の有効な前提条件の一つとされています。
明日からできること
決めるのは、どの被害を自社の話として見るかです。
まず、いま使っているAIを一覧にします。製品名、提供している事業者、契約の形。手引書は契約形態の例として、法人契約、個人契約、無料利用を挙げています。個人契約と無料利用が混ざっていれば、そこが組織の外です。
次に、外部のシステムにつながっているものを見ます。メール、ファイル、API。実行前の確認が指示文だけで書かれていないか。指示文は制御ではありません。
最後に、請求を見ます。利用量に上限が設定されているか。普段と違う量が出たときに気づけるか。ここを見ていなければ、請求書が届いてから気づくことになります。
情報の漏洩に手を打っても、残りの六つは減りません。どの被害のリスクが自社にとって高いのかを、七つ書き出したうえで決めます。