目次
AIエージェントの統制について、この1年で議論されてきたのは主に「事前」の話だった。どのアクションを許すか（権限の設計）、誰が承認するか（承認の設計）、どこに統制を置くか（統制の置き場所）。いずれも本番投入の前に決めるべきことであり、決めた企業は着実に増えている。
だが監査は、事前の設計を見に来るわけではない。監査が問うのは常に事後である。「そのトランザクションを実行したのは誰か」「30日前のあの操作の根拠は何か」「なぜそれが許されたと言えるのか」。稟議書に押された印は、この問いには答えない。
2026年8月末から9月頭にかけて公表された調査と標準文書は、この事後側に大きな穴が空いていることを、はじめて数字で示した。
「絞れている」94%、絞れていた33%
「権限は絞れている」という確信と実際に絞れていた割合を示す図。EMA / Cequence Security「Agents Without Guardrails」（2026年8月31日公表、従業員1,000名以上のIT・セキュリティ責任者202名）より。そう思っている側は94%で、自社のAIエージェントは必要以上の権限を持っていないと回答。実際にやっていた側は33%で、最小権限を実際に強制していた組織はこれだけであり、残りは広い常設権限のまま運用している。想定した範囲の外で動いた経験については、65%が範囲外の挙動を観測、29%が実害を測定、35.6%が実害の手前で気づけた、3.5%は顧客・取引先からの指摘で知った。問題は権限が広いことではなく、広いかどうかを誰も確かめていないこと。なおCequenceはAPI・エージェントセキュリティのベンダーであり、設問設計に自社領域への傾きがある点は割り引いて読む必要がある
Enterprise Management Associates（EMA）が Cequence Security の委託で実施した調査 「Agents Without Guardrails」（2026年8月31日公表）は、従業員1,000名以上の企業のIT・セキュリティ責任者202名を対象としている。
この調査でまず目を引くのは、確信と実態の差である。
- 94% が「自社のAIエージェントは必要以上の権限を持っていない」と回答した
- だが、最小権限を実際に強制していたのは33% だった
残りの約3分の2は、広い常設権限（standing permissions）のまま運用しており、その見直しは定期的か、稀か、あるいは一度も行われていない。
そして実際に何が起きているか。65%が、AIエージェントが想定した範囲の外で動くのを観測している。うち 29%は測定可能な実害に至った。35.6%は実害の手前（ニアミス）で気づけた。そして 3.5%（7組織）は、顧客または取引先からの指摘で初めて知った。
この最後の3.5%が示しているのは、検知の失敗ではない。そもそも検知する仕組みの外側で動いていたということである。
前提として、これは実験段階の話ではない。同調査では 46%が複数部門と本番ワークフローにまたがってエージェントを展開しており、79%が生成AIとエージェント型AIを並行して稼働させている。一方で 30%はパイロットを一時停止または中止しており、その 48.5%がセキュリティ上の懸念を理由に挙げた。
認可を「配ったとき」に決めて、「使うとき」に確かめていない
認可を配布時に決めるか実行時に確かめるかを対比した図。同調査より、実行しようとした個々のアクションについて認可を評価しているのは34.2%。配布時に決める多数派のパターンは、導入時に権限セットを付与し、承認済みのMCP・API一覧に載せ、以降は実行のたびの照合をしない。結果として認証済みのまま危険に振る舞えることになり、個々には正当なアクションの連なりが全体としては許容できない挙動になる。実行時に確かめる34.2%のパターンは、誰として実行しているかを毎回特定し、そのアクションが承認済み設計の範囲かを判定し、範囲外なら実行前に止める。結果は事後の検知ではなく事前の遮断であり、JetStreamのClearance（2026年9月2日発表）はこの一点だけを製品カテゴリにしに来ている。固有IDについては、エージェントごとの固有IDを要求しかつ徹底しているのが54.5%、要求はしているが一貫して徹底できていないのが32.2%、承認済み接続先の一覧は持つが維持する専任チームがあるのは半数未満。誰であるかを決めても、いま何をしようとしているかは別に確かめないと分からない
なぜ「94%の確信」と「65%の逸脱」が同時に成立するのか。同じ調査の別の設問が、その理由を示している。
エージェントが個々のアクションを実行しようとしたその時点で、認可を評価している組織は34.2% にとどまる。裏を返せば、約3分の2は、認可を導入時に一度決めたきりで運用している。
この構造は、人間の従業員を前提にすれば長らく妥当だった。権限を付与し、四半期か年次で棚卸しをする。人は1日に数百回もシステムを横断しないし、目標に向かって経路を自律的に探索しない。
エージェントは両方をやる。しかも機械速度で、多段階の計画を動的に組み替えながらやる。個々には正当な操作の連なりが、全体としては許容できない挙動になる、という失敗の形が生まれる。認証は通っている。個別の権限も満たしている。それでも結果は逸脱になる。
Cequence 側の整理は明快で、従来のID管理は「あなたは誰か」に答える仕組みだが、エージェントにはもう一つの問いが要る ― 「このエージェントは、いま実際に何をしようとしているか」。前者を解いても後者は解けない。
ここまでの到達点も数字で出ている。
- エージェントごとの固有IDを 要求し、かつ徹底している：54.5%
- 要求はしているが、一貫して徹底できていない：32.2%
- 承認済みのMCP接続先・API一覧を維持している：56.4%。ただし それを継続的に維持する専任のガバナンスチームがあるのは半数未満
「固有IDを持たせる」という方針までは、半数以上が到達している。徹底されていない32.2%との差が、そのまま方針と実装の距離である。
そしてこの穴を埋めに来る製品が、実際に出始めている。JetStream Security は2026年9月2日、Clearance を発表した。ゲートウェイ上で、リクエストごとに「誰が／どの承認済み設計に基づいて／どのツールを／何のために呼ぼうとしているか」を突き合わせ、実行される前に可否を決める。事後にログを残すのではなく、危険な操作の連なりを途中で止めることを狙っている。統制が製品カテゴリとして切り出されてきたのは、それだけ多くの企業がここで詰まっているということでもある。
監査が問うのは「許可したか」ではなく「何が起きたか」
監査が問うのは許可したかではなく何が起きたかを示す図。事後に説明できるかどうかで測った到達点として、台帳が作れない47%（稼働中の全エージェントを確実に棚卸しできない）、証跡が出せない46.1%（特定エージェントの30日分の行動記録を容易に出せない）、止めるのに時間がかかる54.5%（封じ込めに数時間と手作業が必要。数分で自動対応できるのは32.2%）。なぜ証跡が人がやったことになるのかについて3点。エージェントが人の資格情報や共用サービスアカウントを借りて動く。ログには借りた側の人名が残り、エージェントの実行だったことは記録に現れない。結果として自分はやっていないと当人が言えてしまい、非否認性が成立しない。NISTの2026年8月27日ブログの整理として、静的APIキーは身元を証明せず、エージェントには固有の識別子・資格情報・権限を持たせ、OAuth 2.0 / SPIFFE / WIMSE / DPoP で短命かつ範囲を絞った権限委譲を行うべきとしている。事前の許可設計は稟議で通るが、事後の説明責任は監査で初めて試される
ここからが本題である。仮に事前の許可設計が甘かったとしても、事後に説明できるなら、統制はまだ機能する余地がある。問題は、その事後側がさらに薄いことだ。
- 47%が、稼働中の全エージェントを確実に棚卸しできない
- 46.1%が、特定のエージェントについて30日分の行動記録を容易に出せない
- 54.5%が、範囲外の挙動を封じ込めるのに数時間と手作業を要する（数分で自動的に検知・封じ込めできるのは32.2%）
- 55%が、統合されたガバナンスプロセスを持っていない
「30日分を出せない」という数字の意味を、監査の文脈に置き換えてみてほしい。監査法人から「4月10日のこの仕訳を作成したプロセスの実行記録を出してください」と言われたときに、出せないということである。あるいは顧客監査で「貴社の環境で当社データにアクセスした主体を全件列挙してください」と言われたときに、答えられないということである。
なぜこうなるのか。理由は技術的にはひとつしかない。エージェントが、人の資格情報か共用のサービスアカウントを借りて動いているからである。
借りて動けば、ログに残るのは借りた側の名前になる。証跡の上では、深夜2時に1,200件の処理をしたのは特定の担当者だったことになる。エージェントが実行したという事実そのものが、記録に現れない。 その結果、「自分はやっていない」と当人が言えてしまう。監査の言葉で言えば、非否認性（non-repudiation）が成立していない。
この点について、NIST は2026年8月27日のブログ 「Back to the Future: Why Agentic AI Needs a Strong Identity Foundation」 で、はっきりした整理を出している。
- 静的なAPIキーは身元を証明しない。 鍵を持っている者は誰でもそのAPIを呼べる。長期間有効で再利用可能なため、特定のアクションと結びつけることが難しい
- APIキーは対象サービスへの広く・範囲の絞られていないアクセスを与えるもので、エージェントがどう振る舞ってよいかを細かく認可する手段を持たない
- エージェントには固有の識別子・資格情報・それに紐づく権限を持たせるべきであり、人の資格情報を共有させてはならない
- 実装には OAuth 2.0、SPIFFE、策定中の WIMSE といった既存・新興の標準を使い、DPoP（所持証明）で短命かつ範囲を絞った資格情報にする
- そして注意点として、Human-in-the-Loop の承認に頼りすぎないこと。承認疲れ（consent fatigue）を招く
最後の一点は重要である。「不安なら人が承認すればよい」という対処は、件数が増えた瞬間に形骸化する。承認の追加は、証跡の代わりにはならない。
なお NIST 側の標準整備は、まだエージェントに追いついていない。トークンとアサーションの保護を扱う NIST IR 8587（2025年12月に初期公開草案）は、47ページの文書のうち非人間主体（NPE）への言及がほぼ1箇所にとどまる。標準が揃うのを待つ、という選択肢は事実上ない。
日本の大企業で、この穴が最初に露出する4つの場所
日本の大企業でこの穴が最初に露出する4つの場所を示す図。既存の内部統制の様式が人を前提に作られていることが原因になる。1つ目は年1回のID棚卸し（J-SOX・IT全般統制のアクセス管理）で、棚卸しの対象は人の名簿でありエージェントは載らず、載っても作った担当者の権限を借りているため過剰権限としては検知されない。異動・退職で担当者のIDが失効した瞬間に業務が止まるか、失効しないまま残る。2つ目はAI事業者ガイドライン第1.2版（2026年3月31日・総務省／経済産業省）で、自律型AIエージェントとフィジカルAIを明示的に定義し、利用時の入出力・推論過程・判断根拠のログを合理的な範囲で記録・保存することを求めており、合理的な範囲は自社で定義しなければならない。3つ目は運用保守の外部委託構造で、委託先がエージェントを動かせば資格情報も証跡も委託先のテナントに残り、自社の監査で出せるのは委託先に聞けば分かるという状態になる。責任分界点とSLAはまだ人の作業を前提に書かれている。4つ目は導入速度が台帳整備を待たないことで、国内のAIエージェントソリューション市場は2025年度2,130億円から2026年度4,140億円（前年比194.4%）、2027年度8,400億円の見通しであり、非人間IDのライフサイクル方針を明文化できている企業は約2割にとどまる。統制の様式を書き換えないまま台数だけ増えると、増えた分がそのまま説明できない領域になる
この構造は世界共通だが、日本の大企業では露出する場所が具体的に決まっている。
① 年1回のID棚卸し。 J-SOX のIT全般統制（ITGC）で、アクセス管理の統制として毎年実施しているあれである。棚卸しの対象は「人」の名簿だ。エージェントは名簿に載らない。仮に載せたとしても、それが担当者の権限を借りて動いている限り、過剰権限としては検知されない。借りている権限は、その人にとっては適正な権限だからである。そして担当者が異動・退職してIDが失効した瞬間、業務が止まるか、あるいは失効させないまま例外として残ることになる。
② AI事業者ガイドライン 第1.2版。 2026年3月31日に総務省・経済産業省が公表した改定版は、自律型AIエージェントとフィジカルAIを明示的に定義し、リスク対応・人間の関与・記録に関する要求を具体化した。特に検証可能性の確保として、開発過程・利用時の入出力・学習過程・推論過程・判断根拠のログを、データ量や内容に応じて合理的な範囲で記録・保存することを求めている。ここでの論点は「合理的な範囲」が自社定義であることだ。定義していない企業は、監査で問われたときに定義していないことがそのまま露出する。
③ 運用保守の外部委託構造。 日本の大企業の情報システム運用は、その多くが外部委託で成り立っている。委託先がエージェントを動かせば、資格情報も実行証跡も委託先のテナント側に残る。自社の監査で出せるのは「委託先に照会すれば分かるはず」という状態である。責任分界点とSLAは、いまだ人の作業を前提に書かれている。
④ 導入速度が、台帳整備を待たない。 デロイト トーマツ ミック経済研究所の調査によれば、国内のAIエージェントソリューション市場は 2025年度2,130億円 → 2026年度4,140億円（前年比194.4%）→ 2027年度8,400億円 の見通しである。一方で PwC Japan は2026年6月11日のコラムで、非人間アイデンティティのライフサイクルに関する明確なポリシーを整備している企業は約2割にとどまると指摘し、権限の肥大化・責任主体の曖昧性・可視性の欠如という3点を構造的課題として挙げている。
台数は2倍のペースで増え、それを説明する様式は据え置かれている。 増えた分は、そのまま説明できない領域になる。
本番化の前に決める5つのこと
本番化の前に決めておく5つのことを示す図。いずれも技術の問題ではなく様式と定義の問題であり、だから本番投入の前にしか決められない。1つ目はエージェントを人の代理ではなく独立した登録対象にすること。固有ID・発行と失効の手順・棚卸しの対象・オーナー部署を定め、人事異動と切り離して管理できる状態にする。2つ目は認可の判定を配布時から実行時へ移すこと。静的APIキーと共用アカウントをやめ、短命で範囲を絞った資格情報に置き換え、都度、経路上で照合する。3つ目は証跡の要件を1エージェント単位で30日分を出せることで書くこと。改ざんされない・消えない・検索できるの3つが揃って初めて監査証跡として機能する。4つ目は検知から封じ込めまでの所要時間を想定ではなく実測で持つこと。数分（自動）か数時間（手作業）かを訓練して測る。測っていない停止手段はあることになっていない。5つ目は承認済み接続先（MCP・API）の一覧に維持責任者を明記すること。一覧を作ることと更新し続けることは別の仕事であり、後者に名前がなければ一覧は数ヶ月で嘘になる。関連する壁はガバナンスの壁（本番直前で止まる）と横展開の壁（説明できないものは2件目に進めない）
いずれも技術の問題ではない。様式と定義の問題であり、だからこそ本番投入の前にしか決められない。
1. エージェントを「人の代理」ではなく、独立した登録対象にする。 固有ID、発行と失効の手順、棚卸しの対象、オーナー部署。人事異動と切り離して管理できる状態にする。ここを飛ばすと、以降のすべてが担当者の在籍期間に依存する。
2. 認可の判定を、配布時から実行時へ移す。 静的APIキーと共用サービスアカウントをやめ、短命で範囲を絞った資格情報に置き換える。そして経路（ゲートウェイ）上で、実行のたびに照合する。文書に書いた統制は迂回できるが、経路に置いた統制は迂回できない。
3. 証跡の要件を「1エージェント単位で30日分を出せること」という形で書く。 「ログを取得する」では要件にならない。改ざんされない・消えない・検索できる ― この3つが揃って初めて監査証跡として機能する。要件定義の段階で、実際に監査部門に「この形式で出したら受け取れるか」を確認しておくのが早い。
4. 検知から封じ込めまでの所要時間を、想定ではなく実測で持つ。 数分（自動）なのか、数時間（手作業）なのか。訓練して測る。測っていない停止手段は、あることになっていない。
5. 承認済み接続先（MCP／API）の一覧に、維持責任者を明記する。 一覧を作ることと、一覧を更新し続けることは別の仕事である。後者に名前がついていなければ、その一覧は数ヶ月で実態と乖離する。調査で「一覧はあるが専任チームは半数未満」という結果が出ているのは、まさにこの分業が抜けているからだ。
まとめ ― 説明できないものは、2件目に進めない
この論点は、Wizit が整理している 4つの壁 のうち、ガバナンスの壁と横展開の壁の両方にまたがる。
ガバナンス側で起きるのは、本番直前の停止である。設計も精度も揃っているのに、監査部門・情報セキュリティ部門から「実行主体を特定できないものは本番に出せない」と言われて止まる。これは技術の不足ではなく、証跡の要件を最初に合意していなかったことの結果である。
そして横展開側では、もっと静かに効く。1件目が本番稼働しても、「あれが何をしていたか説明できない」状態のまま2件目の稟議は通らない。説明できないものは、増やせない。エージェントの台数が伸びない企業の理由が、しばしば技術ではなく説明責任にあるのはこのためだ。
Wizit は、大企業のAIをPoCで止めず、本番運用とROIまで動かし切ることを仕事にしている。その現場で繰り返し見てきたのは、本番化を止めるのは「動くかどうか」ではなく「後から説明できるかどうか」だったという事実である。だから本番化基準を最初に合意する段階で、精度の目標値と同じ重さで、証跡の要件を書くようにしている。
最後に、ひとつだけ確かめてほしいことがある。
いま自社で動いているAIエージェントを1体選び、「この30日間に、それが何をしたか」を一覧で出してみてほしい。 出せるなら、統制は機能している。出せないなら、それは統制がないのではなく、統制があることになっているだけである。
---
出典:
- Enterprise Management Associates / Cequence Security「Agents Without Guardrails」（2026年8月31日公表、従業員1,000名以上の企業のIT・セキュリティ責任者202名。過剰権限でないという確信94%に対し最小権限の強制33%、範囲外の挙動を観測65%、実害29%、ニアミス35.6%、顧客・取引先からの指摘3.5%、複数部門・本番での展開46%、生成AIとの並行稼働79%、パイロットの停止・中止30%とうちセキュリティ理由48.5%）
- Cequence Security ブログ「Agents Without Guardrails: Why Agentic AI Governance Must Focus on Behavior, Not Just Identity」（実行時の認可評価34.2%、固有IDの徹底54.5%／要求のみ32.2%、台帳を作れない47%、30日分の記録を出せない46.1%、数分での自動封じ込め32.2%／数時間＋手作業54.5%、統合されたガバナンスプロセスの欠如55%、承認済み接続先一覧56.4%と専任チーム半数未満）
- Infosecurity Magazine「65% of Enterprises Have Seen AI Agents Act Out of Scope」（2026年9月1日）
- NIST Cybersecurity Insights ブログ「Back to the Future: Why Agentic AI Needs a Strong Identity Foundation」（2026年8月27日。静的APIキーの限界、固有の識別子・資格情報・権限、OAuth 2.0 / SPIFFE / WIMSE / DPoP、Human-in-the-Loop への過度な依存と承認疲れ、NIST SP 800-63 および NIST IR 8587 への参照）
- NIST IR 8587「Protecting Tokens and Assertions from Forgery, Theft, and Misuse」（初期公開草案。CISA との共同、大統領令14144に対応。非人間主体への言及は限定的）
- JetStream Security「Clearance」発表（2026年9月2日。ゲートウェイ上で、実行前に主体・承認済み設計・呼び出しツール・意図を突き合わせて可否を判定）
- 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日。自律型AIエージェントとフィジカルAIの定義、利用時の入出力・推論過程・判断根拠のログの記録・保存）
- PwC Japanグループ「AIエージェントとID管理：人を前提とした統制モデルの限界と再設計の方向性」（2026年6月11日。非人間IDのライフサイクル方針の整備は約2割、権限の肥大化・責任主体の曖昧性・可視性の欠如）
- デロイト トーマツ ミック経済研究所「AIエージェントソリューション市場動向 2026年度版」（国内市場 2025年度2,130億円 → 2026年度4,140億円・前年比194.4% → 2027年度8,400億円）