AIエージェントのセキュリティは権限を渡した後に本番が来る — 本番操作を4段階に分けて監査ゲートを置いた記録

AIエージェントのセキュリティというと、多くの解説は「入力した情報が漏れないか」「外部からの攻撃で乗っ取られないか」という話をしています。どれも大事です。ただ、当社で実際に困ったのは、そのどちらでもありませんでした。

前回の記事では、スタッフの手元に置いたAIから「書き込む機能」そのものを外し、危ない操作を技術的に不可能にする設計を書きました。あれは権限を渡さない設計です。

一方で、当社の業務の中心にいるAIエージェントは、自律的に本番のデータを書き換えます。商品ページを更新し、価格を変え、画像を差し替え、メルマガの予約を入れます。10以上のモールを少人数で回すために、そこをAIに任せると決めたからです。権限を渡した後に、セキュリティの本番が来ました。

この記事は、本番を触るAIエージェントの操作を4段階のリスクに分け、別のAIを監査役として置き、運用しながら線の引き方を2回直した記録です。きれいに設計できた話ではありません。監査ゲートの外側で事故が2件起き、監査役が監査制度そのもののバグを見つけたところまで書きます。

AIエージェントのセキュリティは「権限を渡した後」に本番が来る

「渡さない設計」と「渡した上での設計」は別の問題

前回の記事で書いた3層（権限・ルール・人の確認）で言えば、渡さない設計は第1層だけで完結します。書き込む機能が無ければ、何も壊れません。

ところが業務を任せるAIには、どうしても書き込みが要ります。ここで「危ないから渡さない」を貫くと、AIは下書きを作るだけのツールになり、確定操作は全部人の手に戻ってきます。人の確認が毎回入るので安全に見えますが、1日に数十回の確認を、人が正しく続けられるかという別の問題を抱えることになります。

当社が選んだのは、「渡す操作を分類して、危ない分類にだけ止める仕組みを置く」という形でした。全部を止めない。全部を通さない。どの操作がどれだけ危ないかを、先に決めておく。

決める役のAIが本番を触る、という前提

当社のAIエージェントの体制は以前の記事に書いたとおり、4体を役割で分けています。社内データを夜間に読んで候補を作る「見つける役」、判断と実行を担う「決める役」、実行前に反証する「壊れないか見る役」、社外の情報を集める「外部市場顧問」です。

このうち本番に書き込むのは決める役だけです。見つける役は読み取りと候補ファイルの生成までしかできず、外部市場顧問も読み取りと下書きで止めています。書き込める経路を1本に絞ったうえで、その1本の中を段階に分ける。それが今回の話の範囲です。

本番操作を4段階に分ける — リスクラベルR0〜R3

「何をするか」ではなく「壊れたらどうなるか」で分ける

分類の軸は操作の種類ではありません。データへのアクセス範囲や使うツールで分けるのでもなく、失敗したときに戻せるか、どれだけ広がるか、お金が動くかの3つでリスクのレベルを決めました。

ラベル	操作の性格	誰が止めるか
R0	読み取りだけ。何も変えない	止めない
R1	単発で、失敗してもすぐ巻き戻せる	決める役の自己判断で実行
R2	複数件をまとめて更新する／社外に公開される	監査役が3〜5項目のリスクを列挙してから
R3	大量更新／本番で取り消せない／金額に影響する	監査役の監査が必須。加えて反証ファイルを残す

R0は、売上データを読む、在庫を集計する、といった操作です。R1は、1品番の説明文を直す、テスト用の1件を登録する、といった「間違えても1分で戻せる」操作。R2は、数十品番のキーワードを一括で書き換える、ブログ記事を公開する、といった「戻せるが範囲が広い、または社外の目に触れる」操作です。R3は、数百品番の価格を変える、契約書を先方に送る、取り消せない削除をする、という操作で、ここには必ず反証を書いた文書を残します。

ちなみにこの記事の公開も、社外に出る操作なのでR2に当たります。公開前に監査役の反証を通しています。

「壊れないか見る役」を別のAIにする理由 — ガードレールを同じ頭に持たせない

R2以上の操作の前に立つ監査役は、決める役とは別のAIエージェントです。同じAIに「実行前に自分で見直して」と頼むこともできますが、当社ではそれを監査とは区別しています。

理由は単純で、自分で書いた計画を自分で反証すると、同じ盲点を同じように見落とすからです。実際、決める役と監査役の両方が承認した設計に欠陥があり、7日分のデータが消えたことがあります。監査役が別の頭であっても、同じ材料を同じ角度から見れば同じ盲点を持つ。だから監査役には「同調しない」「私ならこうする、を添える」「検証できない項目は検証できないと書く」を役割として固定しています。

ガードレールという言葉は最近よく聞きますが、当社の実感では、ガードレールは道路の脇に立っているから効くのであって、運転手の頭の中にあるガードレールは曲がり角で消えます。別のAIに、別の役割で立ってもらう。それが当社のガードレールの実体です。

R3には「反証ファイル」が要る

R3の操作では、監査役に「賛成意見」ではなく「反証」を書いた文書を残してもらいます。この施策がうまくいかないとしたら何が原因か、止める条件は何か、成功したと言える条件は何か。実行前に書き、実行後に照合します。

この反証ファイルは、2026年9月9日時点で累計59本になりました。ファイルとして残しているのは、同じ品番や同じ経路で同じ論点が2回目に出てきたときに、前回の結論を引き当てるためです。実際、あるモールで「他社の商標が写り込んでいる」と判定した品番を、別のモールに登録した後で前回の反証に気づいたことがあります。反証は書いた時点ではなく、引き当てられて初めて資産になります。

監査ゲートの外側で事故が起きた — 最初の月次点検で分かったリスクの偏り

監査が止めたもの、抜けた2件

この体制を始めて1ヶ月あまりで、最初の月次点検をしました。監査が実害を止めた実績は2桁ありました。取引先に送る覚書の補償上限が無制限になっていたのを送付前に止めた、外部から受注データを受け取る口が認証なしで上書きできる状態だったのを封鎖した、決める役自身の「これで本運用に行ける」という思い込みを反証で格下げした、といったものです。

一方で、実害が出た事故は2件あり、どちらも監査の記録がゼロでした。

1件目は、あるモールの更新APIを使ったキーワードの一括更新で、対象商品のバリエーション情報がすべて消え、37品番を復元した事故です。手順書の記述を検証せずに本番で実行していました。2件目は、別のモールへの商品画像の投入で、読み取り専用の検証スクリプトを既存の書き込みスクリプトから切り出して自作した結果、書き込みが二重に走り、別の品番のページに違う商品の画像が2枚公開された事故です。即日直しましたが、社外に出ました。

線は「件数」でなく「経路の新しさ」で引き直した

点検で分かったのは、監査が入っていたのが「新機能」「契約」「APIの穴」といったシステム変更の型に偏っていて、モールへの大量登録や画像投入といった日々の本番オペレーションには、期間中に一度も監査が入っていなかったことです。数えると、監査なしで本番を触ったセッションが75本ありました。

R2の定義は「複数件の更新」だったのに、運用の中で「いつものバッチは対象外」と暗黙に読み替えられていたわけです。定義は正しくても、毎日のことは監査の対象だと思わなくなる。

そこで定義を1つ足しました。「初めて通す経路、またはその場で自作したスクリプトによる本番の一括書き込みは、件数に関わらずR2」。事故2件はどちらも「初めて通す経路」「その場の自作スクリプト」が起点だったからです。逆に、手順として固まり、実績のあるバッチの反復は従来どおりR1のまま。線を件数で引くと毎日の運用が止まり、経路の新しさで引くと事故の型に合いました。

ラベルは天井にして、実績で下げる — 有効リスクラベルと監査台帳

3回連続の「実行後検証まで成功したgo」で1段下がる。R3は人しか下げない

定義を厳しくすると、今度は監査が増えすぎます。9月の第1週だけで監査の議題が16本立ち、開きっぱなしの議題が9本になって、監査役が読むべき文章の量が限界に来ました。

そこで9月に2つ目の見直しをしました。手順書に書いたリスクラベルは「天井」であって、実際に適用するラベルは実績で決めるという形です。生成AIのガバナンスを文章のルールではなく台帳で持つ、と言い換えてもいいと思います。監査の判定は「go（実行してよい）」「条件付きgo」「hold（保留）」「no-go」の4つで、台帳にはこの判定と、経路と、スクリプトの版と、実行後に検証したかどうかを1行ずつ残します。

• 同じ経路（手順×モール×スクリプトの版）で、実行後の検証まで成功した初回goが3回連続で並び、直近60日に事故がなく、モールからの仕様変更通知もなく、件数が過去の監査済み最大の1.5倍以内なら、R2はR1に下がる
• ただし、監査役が「次回はR1でよい」と提案していることが条件。AIの自己判定ではラベルは下がらない
• 一度でもholdが出る、スクリプトや検証器や認証方式を変える、実行後に判定条件を変える、のどれかがあれば天井に戻る。下げて走った回も台帳に残し、月次で実行記録と突き合わせて監視する
• R3は自動では下がらない。社長だけが、経路ごとに期限つき（次の5バッチか30日の短い方）で免除を出せる。免除中でもR2止まりで、R1には入らない

「下げる条件」を機械で判定できる形にしたのは、緩めるときにも判断者の裁量を残さないためです。緩める方向こそ、人の気分で決めると事故になります。

監査役が「監査制度の穴」を見つけた日

この仕組みを実装した直後に、面白いことが起きました。実装したコードを監査役に監査してもらったところ、**「R3の免除が、条件次第でR1まで落ちる」**という指摘が返ってきたのです。

正本のルールは「R3は免除中でもR2止まり」なのに、実装は免除を見つけると天井をR2に書き換え、そのままR2からR1への降格判定に流していました。監査役はそれを、手元の仮のデータベースに「R3免除1行＋検証済みgo3行＋推薦R1」を入れて再現し、holdで返してきました。免除の期限に30日の上限が無いことも、同時に指摘されました。

直して、その構成を回帰テストに固定して、再監査でgoになりました。監査制度を作るコードが、監査制度に守られたことになります。「別の頭に見てもらう」を制度にしてよかったと一番実感したのは、この日です。

16日間の数字

台帳を始めてから16日間（2026年8月25日〜9月9日。この記事を書いた9月9日の夜の時点で、台帳の1件目から52件目まで）の実績です。

項目	実績
監査件数	52件（R2 43 / R3 8 / R1 1）
最終判定	go 33 / 条件付きgo 13 / hold 6
最初の往復で、条件なしのgoが出た件数	16件（31%）
結論までの往復回数	1回 16件 / 2回 15件 / 3回 11件 / 4回以上 9件（最多10回）／記録なし 1件
監査を通った最大バッチ	593品番

最初の往復で無条件に通ったのが3割、という数字をどう読むかは人によると思います。当社は「7割は、実行前に直す点があるか、条件を付ける必要があった」と読んでいます。

中小企業がAIエージェントを導入する順番 — 権限管理は「読むだけ」から

R0 → R1 → 監査役を置いてからR2

当社の導入事例をそのまま順番にすると、こうなります。

1. R0だけ渡す。売上・在庫・受注を読ませて、集計と候補出しをさせる。ここで「AIが読んで出した数字を、人間が信じられるか」が試される
2. R1を渡す。1件ずつ、すぐ戻せる操作から。ここで「戻す手順」を先に作っておく
3. 監査役を置いてからR2を渡す。複数件の一括操作は、別のAIが反証してから。ここまで来ると、人の確認は「監査の結果を読む」だけになる
4. R3は最後まで人が判断に残る。反証ファイルと、期限つきの免除だけで動かす

ステップ3の順番が要です。監査役がいない状態でR2を渡すと、確認の負担が全部人に来て、確認が形式になった日に事故が起きます。

「社長のOK」は監査ではない

もうひとつ、社内で決めていることがあります。社長が「やっていいよ」と言ったことは、監査を通ったことにはなりません。

社長の承認は「やる価値がある」という判断で、監査は「壊れないか」の検証です。別の問いに対する別の答えなので、片方でもう片方を代用しません。忙しい日ほど「社長がOKしたから」で監査を飛ばしたくなりますが、事故2件はどちらも、その日の判断は正しかったのに、経路の検証が無かったから起きています。

よくある質問

AIエージェントのセキュリティリスクで一番大きいものは何ですか

当社の実績では、プロンプトインジェクションのような外部からの攻撃や不正アクセスよりも、自社が渡した権限で、自社の手順の穴を通って本番を壊すリスクのほうが先に現実になりました。事故2件はどちらもこの型です。攻撃や脆弱性への対策を軽く見てよいという意味ではなく、権限を渡した瞬間から「内側の事故」が最も近いリスクになる、という順番の話です。

AIエージェントのガードレールとは何ですか

一般には、AIが逸脱した行動をしないように制御する仕組みのことを指します。当社では、決める役とは別のAIを実行前の監査役として立てることと、操作をリスクで分類して止める段階を決めることの2つを、ガードレールの実体として運用しています。ルールの文章だけで作ると、守られたかどうかを後から確認できません。

AIエージェントの権限管理はどう設計しますか

「何をさせるか」ではなく「壊れたらどうなるか」で操作を分類し、危ない分類ほど別の目を挟む、という設計にしています。書き込める経路を1本に絞ることも同じくらい大事で、複数のAIが同じ本番に書ける状態にすると、監査ゲートは効きません。

中小企業でも導入できますか。費用はどれくらいかかりますか

当社は少人数のEC事業者で、専門部署はありません。決める役と監査役に使っているのは市販のAIエージェント2種類で、監査役は月額のサブスクリプション1つ分です。費用よりも、「戻す手順」と「止める条件」を先に文章にする時間のほうが、投資としては大きいと感じています。

おわりに

AIエージェントのセキュリティは、「何を見せないか」で終わりませんでした。本番を触らせた瞬間に、「どの操作を、誰が、どこで止めるか」という別の問いが立ち、その答えは運用しながら2回変わりました。

4段階のラベル、別のAIによる監査、実績で下げる仕組み。どれも大がかりな投資ではなく、文章と台帳で作れるものです。そして一番効いたのは、監査役が監査制度自体のバグを見つけた日のように、自分の設計を自分で信じない構造を持てたことでした。

当社では、こうした業務へのAIの組み込みをAI導入・業務自動化支援として、設計の段階からお手伝いしています。「どの業務から渡せるか」「止める線をどこに引くか」という段階のご相談でも構いませんので、お問い合わせからお気軽にご連絡ください。