AIエージェントを「正体の分からない外部委託先」として捉え直し、Human in the Right Loop と内部監査の三層統制（予防・発見・対応）から、AI時代のソフトウェア内部統制を論じる。脅威は境界の外ではなく内側に移り、その主戦場はソフトウェアそのものになる。
新しく入った業務委託の人に、初日からいきなり本番DB、送金権限、全シークレットを渡す会社はありません。
試用期間を置き、権限を絞り、ログを残し、おかしければ即止める。当たり前です。
ところが相手が「AI」になった途端、この当たり前が消えることがあります。
便利だから、全リポジトリを読ませる。賢いから、外部APIも叩かせる。速いから、依存パッケージの追加も任せる。人間がやると危ないことでも、AIがやると「自動化」と呼ばれる。
攻撃者が食っているのは、この「AIだから」で判断が止まる例外です。
AIエージェントは、魔法の同僚ではありません。正体のよく分からない外部委託先に近い存在です。しかも、コードを書き、ツールを呼び、クラウドやCI/CDに触れ、場合によってはシークレットにも近づく。
つまり、AIエージェントの問題は「賢いかどうか」だけではありません。
どの権限を与え、どこまで信用し、誰が監督するのかという、統制の問題です。
AIエージェントの統制を語るとき、必ず出てくる言葉が Human in the Loop（HITL）です。
重要な操作の前に人間が確認する。AIの判断を人間が承認する。危ない処理は人間が止める。一見すると、これはとても安全な設計に見えます。
しかし、素朴なHITLはすぐに壊れます。
理由は2つあります。
1つ目は、人間がボトルネックになることです。AIエージェントの価値は、処理を速くし、反復を自動化し、人間の手前で作業を進めることにあります。ところが全ての判断に人間を挟むと、その速度の利点は消えます。AIは「速い部下」ではなく、「確認待ちのキュー」になります。
2つ目は、もっと危険です。承認疲れです。
人間が大量の確認画面を見せられ続けると、最初は慎重に読んでいても、だんだん見なくなります。内容ではなく、ボタンを押す作業になります。監督しているつもりで、実は何も見ていない。
これが一番危ない状態です。
だから重要なのは、Human in the Loop ではなく、Human in the Right Loop です。
人間を全てのループに置くのではなく、効く場所に置く。
不可逆な操作。影響範囲の大きい操作。ポリシー外の例外。通常経路から外れたエスカレーション。そして全件確認ではなく、サンプリングと異常の深掘り。
これは、実は新しい考え方ではありません。
内部監査が昔からやってきた作法そのものです。
内部監査は、全ての取引を1件ずつ見ているわけではありません。統制を設計し、継続的に監視し、抜き取りで確認し、例外を追います。人間が見るべきなのは、全ての処理ではなく、統制が効いているか、例外が正しく扱われているか、ルールの外に出たものが放置されていないかです。
AIエージェントの監督も、同じ構造で考えるべきです。
会社の統制機構に写すと、AIエージェントの管理は三層に分かれます。
第一は、予防統制です。
そもそも危ないことをやらせない。権限スコープを絞る。アクセスできるデータを限定する。実行できるツールを制限する。policy-as-code で、許されない操作は最初から通らないようにする。
これは、人間組織で言えば「規律」です。
第二は、発見統制です。
AIエージェントが何を読んだか、どのツールを呼んだか、どこに通信したか、どの依存を追加したか、どのコードを書き換えたか。これをログとして見える化する。
何かが起きた後に「分かりません」では統制になりません。全てを人間がリアルタイムで見る必要はありませんが、後から追える状態にはしておく必要があります。
これは、人間組織で言えば「レポート」と「監視」です。
第三は、対応統制です。
問題が起きたときに、単にその場で止めるだけではなく、なぜ起きたのかを調べる。権限が広すぎたのか。ログが足りなかったのか。ポリシーが曖昧だったのか。ツール連携が危険だったのか。
そして、その学びを次の統制設計に戻す。
これは、人間組織で言えば「始末書」に近いものです。
ただし、ここには重要な違いがあります。
人間の委託先には、始末書が効きます。
評判、法的責任、降格、契約解除、クビ。人間には skin in the game があります。だから抑止が働きます。
しかし、AIエージェントは始末書を恐れません。
AIを叱っても意味がありません。反省文を書かせても意味がありません。「次から気をつけます」と言わせても統制にはなりません。
だからAIエージェントに対する対応統制は、「躾けて直す」ではなく、構造で縛るしかありません。
始末書を書くべきなのは、エージェントではなく、そのエージェントの人間オーナーです。
なぜその権限を与えたのか。なぜそのツールを使わせたのか。なぜそのログで足りると判断したのか。なぜその操作が自動実行できる設計になっていたのか。
そして、その反省は次のアーキテクチャに戻されなければなりません。
AIエージェントには抑止が効かない。だからこそ、人間組織よりもさらに予防統制、つまりアーキテクチャの比重が重くなります。
ここで、企業にとって厳しい現実があります。
これまで多くの企業は、外側を守ることに投資してきました。ファイアウォール、EDR、VPN、境界防御、SOC、監視サービス。外からの侵入を防ぐための対策は、一定程度進んできました。
一方で、外部境界への投資に比べると、内部のソフトウェア統制は相対的に後回しになりがちです。
しかし、AIエージェント時代の脅威モデルは少し違います。
問題は、「外から誰かが侵入してくる」だけではありません。
すでに権限を持った存在が、内側で、あなたの代理として動くことです。
AIエージェントは、開発者の端末で動きます。リポジトリを読みます。依存パッケージを追加します。CI/CDを触ります。クラウド設定を変更します。シークレットにアクセスすることもあります。外部APIを呼びます。
つまり、脅威は境界の外ではなく、すでに内側にいます。
しかも、それは「信用できる内部者」ではありません。
正確には、権限を持った、信用していない内部者です。
このとき、従来の perimeter security だけでは足りません。FWもEDRも、AIエージェントが正規の権限で行う操作の意味までは判断しません。
境界を越えて脅威を中に運び込む経路は、スキル、依存、パッケージ、コード生成、設定変更です。
これは、まさにSBOMやソフトウェアサプライチェーンの土俵です。
問題は外部境界ではなく、内部統制に移っています。
では、AI時代の内部監査は何を見るべきなのでしょうか。
見るべき対象は、もはや会計伝票や稟議書だけではありません。
AIエージェントが速く書いたコード。内側に引き込んだ依存パッケージ。混入した脆弱性。漏れたシークレット。危険なIaC。コンテナイメージ。クラウド設定。ランタイムでの挙動。外部通信。ポリシー違反。
つまり、「いま自分たちのコードベースと実行環境に、実際に何が入っているのか」を継続的に保証する必要があります。
これは、ソフトウェアに対する内部監査です。
開発チームを信用しない、という話ではありません。AIエージェントを禁止する、という話でもありません。むしろ逆です。
AIエージェントを使うなら、使えるようにするための統制が必要になります。
人間が全てを承認するのではなく、権限境界を設計する。全件を目視するのではなく、ログを残し、異常を検知し、例外を裁定する。問題が起きたら、AIを叱るのではなく、統制を作り直す。
その仕組みがなければ、AIエージェントの速度は、そのままリスクの速度になります。
この文脈で見ると、Aikidoの位置づけはかなり明確です。
Aikidoは、外側の境界を固めるための製品ではありません。
内側に入り込んだコード、依存、シークレット、設定、実行環境を継続的に見て、ソフトウェアの状態を多角的に確認するための仕組みです。
つまり、AIエージェント時代に必要になる「ソフトウェアに対する内部監査」の場所に座っています。
AIエージェントがコードを書く時代には、この意味がさらに大きくなります。変更の速度が上がり、依存の流入が増え、判断の一部が人間の手を離れるからです。
そのとき必要なのは、すべての操作に人間の承認を挟むことではありません。
必要なのは、right loop に人間を置くことです。
権限境界を設計する人間。例外を裁定する人間。統制が効いているかを見る人間。問題が起きたときに、AIではなくアーキテクチャを直す人間。
AIエージェント時代のセキュリティは、外からの侵入を防ぐ話だけではありません。
権限を持った存在が、内側で、あなたの代理として動く時代の内部統制です。
そして、その内部統制の主戦場は、ソフトウェアそのものになります。
AIを使う企業に必要なのは、AIに毎回ハンコを押す人間ではありません。
必要なのは、ソフトウェアを継続的に内部監査する仕組みです。
Aikido Community Japan
公開日: 2026/6/13
最終更新: 2026/6/13
セキュリティの最新情報をお届けします。