記事全体のサマリー
本文に入る前に、この記事の全体像を1枚にまとめました。先に見取り図をつかんでから読み進めていただければと思います。
AIに資料の修正を頼みました。返ってきたものは、きれいにまとまっていましたが、頼んでいない範囲まで書き換えられていました。
問題は、書き換えられたことではありません。それがきれいにまとまりすぎていて、気づかなかったことです。気づいたのは、提出した後でした。自分が意図していない文章が、成果物に残っていました。
これが、いま私がいちばん怖いと思っていることです。
今回の材料 ― ISACAの2本の論考
先に、これから触れる資料の説明をしておきます。
今回触れるのは、ISACA のサイトに掲載された2本の論考です。ただし、どちらも基準でもガイダンスでもなく、1本目はISACAのブログ、2本目は業界ニュース欄の寄稿記事です。つまり「ISACAが定めた要求事項」ではなく、ISACAが場を与えた実務家の整理として読む必要があります。
2本は役割が分かれています。
この2本に共通して出てくるのが、Authorized scope（認可された範囲）と Exercised scope（実際に行使された範囲）という対比です。定まった訳語がまだ無いので、この記事では英語を併記します。
日本語の一次情報はまだほとんど見当たりません。ただ、論じられているのは特定の国の規制ではなく、AIエージェントという道具の性質です。日本の実務でも、読み替えはほとんど要らないと思います。
なぜ今、これが避けられないのか
生成AIが「答える」だけの道具だったころ、リスクは何を言うかにありました。誤った回答、偏った回答、作られた事実。どれも出力を見れば分かります。
エージェント型のAIでは、そこが変わります。リスクは何を実行できるかへ移ります。
ISACAが公表した論考は、この変化をこう書いています。
最も懸念されるのは、エージェントがそれを正規の資格情報と、完全に認可されたインターフェースを使って行えることである。
ISACA『Four Governance Questions to Ask Before an AI Agent Goes Live』（2026年8月24日／訳は筆者）
つまり、アクセス権の監査では発見できません。権限は正しく付与されており、ずれているのは権限そのものではなく、その使われ方だからです。
「認可された範囲」と「実際に行使された範囲」
この論考でいちばん効くのは、2つの言葉を分けたことです。Authorized scope（認可された範囲）と、Exercised scope（実際に行使された範囲）。
人間の権限管理では、この2つはだいたい一致します。システムへのアクセス権を持つ人は、職務に沿って使うだろう、と仮定できるからです。エージェントは、その仮定を壊します。
原文の例が分かりやすいので、そのまま紹介します。
サポートチケットへの返信を下書きする権限を与えられたエージェントが、回答の質を上げようとして、顧客の購買履歴を引き、請求内容を突き合わせ、苦情のログまで確認する。その一つひとつは与えられた資格情報で実行できる。しかし、行動として、誰もこれを承認していない。
同上（訳は筆者）
読んで、自分の体験と同じ構造だと思いました。権限の範囲内で、頼んでいないことが、うまく行われている。
そして、うまく行われているから、気づかない。
監査手続の側が追いつかない
もう1本の論考は、従来のIT監査の前提が通用しなくなる箇所を4つ挙げています。
- ロジックが文書化できない ― モデルの重みは自社が保有も制御もしておらず、挙動を決めるシステムプロンプトは、バージョン管理も正式な変更承認もないまま書き換えられていることが多い
- サンプリングが効かない ― 同じ入力から別の出力が出る。出力のばらつきは異常ではなく、システムの性質である
- アクセスレビューが足りない ― 見るべきは「何にアクセスできるか」ではなく「それらの上で何ができるか」。読む・更新する・承認を起動する、その組み合わせがリスクを作る
- 変更管理が発動しない ― ベンダーのモデル更新はAPI越しに来る。社内の変更管理プロセスは一度も動かないまま、挙動が変わる
4つ目は、以前COSOのガイダンスについて書いたときに触れた「急速な構成変更」と同じ話です。SaaSに組み込まれたAIが、社内の誰の承認も経ずに昨日と違う挙動になる、というあれです。
では、どうするのか
論考は手続まで書いています。個別のサンプリングをやめて、期間の出力分布を見る。権限の境界を試す入力を設計して、越えようとしたときに止まるかを試す。モデル更新の記録を入手して、更新後に再検証したかを確かめる。止まって人に上げるべき条件が文書化され、実際に上がっているかを見る。
そして、こうも書いています。
十分なログが無いこと自体が、発見事項である。
ISACA『Auditing Agentic AI Workflows』（2026年9月11日／訳は筆者）
ただ、ログを取れば済む話ではありません。同じ論考の、いちばん重要な一文はここだと思います。
正当な資格情報が使われていても、エージェントが認可された境界を越えたならアラートを上げなければならない。その行動が、エージェントを承認したときの意図の範囲内だったかを判断するのは、監査人である。
同上（訳は筆者）
判断するには、物差しが要ります。何をさせるつもりで承認したのかが書かれていなければ、ログを見ても「これは頼んでいない」とは言えません。記録はあるのに、判定できないという状態になります。
だから順序は、ログより先に意図です。本番に出す前に、そのエージェントが何者で、誰が持ち主で、何をさせるつもりで、何をさせないつもりかを書いておく。論考が挙げる「本番エージェントの最低基準」も、中身はその文書化です。
現場への問い
- あなたの組織で動いているAIエージェントについて、「何をさせるつもりで承認したか」が文書になっていますか。無いなら、ログがあっても逸脱を判定できません。
- AIが関わった成果物のレビューで、見ているのは出力だけではありませんか。途中で何に触れたかを確かめる手段はありますか。
- 使っているAIの挙動が先月と同じである保証は、どこにありますか。ベンダーの更新は、社内の変更管理を通っていません。
私はこう考える
冒頭の話に戻ります。
私が承認したのは、やってよいことの範囲でした。実際に起きたのは、その範囲の中で、頼んでいないことが、きれいに行われたことでした。
ハンコは押されています。手続の上では、問題は一件も起きていません。
2本目の論考は、最後にこう締めています——エージェント型AIの監査は、従来のIT監査の枠組みを置き換えるのではなく拡張することだ。統制の存在、設計の有効性、運用の有効性という中核は変わらない。変わるのは、それをどう確かめるかだ。
正しいと思います。ただ、使っている側の実感としては、もう少し断絶に近いというのが正直なところです。私たちが長く前提にしてきたのは、「誰が承認したか」を追えば責任の所在が分かる、という構造でした。その前提が薄くなっています。承認した人はいる。承認された範囲でもある。それでも、誰も意図していないことが起きる。
だから私は、自分が使うときも、意図を先に書くようにしました。何を頼んでいて、何は頼んでいないのか。書いておかないと、きれいな成果物を前にして、自分でも判定できないからです。
今回は以上です。
出典
- ISACA『Four Governance Questions to Ask Before an AI Agent Goes Live』ISACA Now Blog、2026年8月24日
https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2026/four-governance-questions-to-ask-before-an-ai-agent-goes-live - ISACA『Auditing Agentic AI Workflows: How to Control Test When the System Decides for Itself』Industry News、2026年9月11日
https://www.isaca.org/resources/news-and-trends/industry-news/2026/auditing-agentic-ai-workflows-how-to-control-test-when-the-system-decides-for-itself
