Dekita

エージェントは回している、権限と監査の制度は追いついているか

生成AI 日本語 AIエージェント セキュリティ ガバナンス

はじめに

この稿は、日本の現場で「エージェントは本番に入れたが、ID と権限と監査の制度は作ったか」という、まだ答えが定まらない問いに答えます。

生成 AI を使うこと自体は、すでに多くの会社で当たり前になりました。問いは能力から制度に移っています。問いは、エージェントが誰の名前で動き、どこまで触れ、あとから確認できるのかを、会社として決められるかです。

2026 年 10 月 13 日、SailPoint は第5回 Horizons of Identity Security レポートを公表しました。本番で AI エージェントを回す組織は 79% でした。一方、エージェント用の ID セキュリティの道具を使い始めているのは 2% です。この 79 対 2 の差を、日本の現場でどう読むか、を述べます。

本番と制度の差

レポートの数字を 4 つ並べます。

4 番目の 15% が、この稿の中心です。人を雇うときは、ID を作って権限を決めて退社のときに返す。この流れが 15% に止まるのは、エージェントの流れが人の流れに乗っていないからだと考えられます。

人を管理するほうは、同じ期間に上がっています。Horizon 1 は 2022 年の 45% から 23% まで下がりました。同じ会社の同じ ID チームが、人の ID とエージェントの ID を別速度で育てている、という構図です。

エージェントは、非人間のアカウント全体の 22% を占めています。サービスアカウントやボットと同列に扱われると、ログが人の名前で残る、という問題が起こります。

人の制度をそのまま使う視点

この開きを、新しい枠組みから埋めなくてよいと見る向きがあります。日本では 2026 年 10 月、小山よしき氏が整理した視点があり、エージェントを「新規ユーザー一名と新規ベンダー一名」として扱う方法です。

この視点では、会社はずっと人に対してやってきたチェックを、そのままエージェントに当てます。そのチェックは、ID、権限、記録、承認、停止、ベンダー管理の 6 つです。特別な新しい制度を作る必要はありません。

面白いのは、同氏が 2026 年 10 月の政府の注意喚起を元にした 47 項目のチェックリストで、「承認」が一度も出てこなかった、という点です。人が読む注意喚起は、承認の場面を想定していなかった、と読むことができます。氏はこの空白を埋めるため F-1 から F-6 まで 6 項目を加えました。

開発者が先に決められる 4 項目

制度の全面改定を待たなくても、開発者が先に決められることは 4 つあります。これらは、いずれも既存の ID 管理の流れの中で書けます。

  1. エージェントに専用のアカウントと鍵を与える。人の鍵を共用すると、ログがその人の操作に見える。
  2. 読み取りと、送信・削除・支払いを分ける。外部の文書を読むエージェントには、その 3 つを与えない。
  3. 承認の置き場所を決める。どの操作が自動でよく、どこで人が押すか、を事前にかく。
  4. 止まり方を書く。権限を返す手順と、異常を検知したときの停止条件を残す。

1 と 2 は、人の管理でいう「ID を分ける」と「権限を分ける」の繰り返しです。3 と 4 は、承認と停止の置き場所を決めることで、47 項目にない空白を、会社の側に書き足す作業になります。

まとめ

エージェントを回すことと、エージェントを管理する制度を置くことは、別々の作業です。79 対 2 は、その差の大きさを示す数字です。

開発者が待てるのは、制度の全面改定までです。その前に、4 項目のうちから 1 つを、既存の ID 管理の流れの中で書けます。人の制度をそのまま使う視点があれば、新しい枠組みを探す必要はありません。

参考情報

← 記事一覧