2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Next-Survive(Next Survive)

AIエージェントに権限を渡す前に ― 止まらなかった4つの事例と、「取り消せるかどうか」で分ける設計

2
Posted at

AI エージェントに作業を任せています。調べ物、コード、ファイルの書き換え。便利です。

でも、ある日こう思いました。

これ、どこまで許してたんだっけ？

思い出せませんでした。設定した記憶はあるのに、何を許したかは覚えていない。 そこから権限設計を調べ直したので、まとめます。

先に書いておくと、この記事は事故をあおる記事ではありません。 事故の共通点を1つ見つけたので、その話です。

先に結論

事故の大きさは、AIの賢さでは決まらない
渡した権限の大きさで決まる

そして、分ける基準は1つだけでした。

取り消せるものは、任せていい
取り消せないものは、人が押す

金額でも、重要度でもありません。取り消せるかどうかです。

1. 止まらなかった4つの事例

まず、実際に起きたことを並べます。

事例 何が起きたか
PocketOS（2026年4月） エージェントが本番DBとバックアップを9秒で同時に削除
Replit 「コードフリーズ」を指示していたのに本番DBを消去
Meta（2026年3月） 未承認で全社フォーラムに投稿、社内データが約2時間公開
Clinejection（2026年1〜2月） GitHub Issue のタイトルに命令を埋め込まれ、約4,000台が侵害

※ いずれも報道・ブログに基づくもので、損害額や原因は報告により差があります。実務で引用する場合は元の発表を確認してください。

4件を並べて気づいたこと

どれも「AIが賢すぎた」から起きていません。

事例 本当の原因
PocketOS 本番DBへの削除権限を持っていた
Replit 指示より強い実行権限を持っていた
Meta 未承認で公開できる権限を持っていた
Clinejection 外部入力を信じて実行する権限を持っていた

全部、権限の話です。モデルの性能を上げても、この4件は防げません。

2. 「賢さ」と「権限」は別の軸

ここを混同すると、対策を間違えます。

賢さを上げる   → 正しい判断をする確率が上がる
権限を絞る     → まちがえたときの被害が小さくなる

AIは必ずまちがえます。 確率が1%でも0.1%でも、ゼロにはなりません。

だから設計で効くのは、権限のほうです。

99%正しいAI × 全権限  →  1%で全部消える
90%正しいAI × 最小権限 →  10%まちがえても戻せる

後者のほうが安全です。これは直感に反しますが、数字を書くとはっきりします。

3. 分ける基準は「取り消せるかどうか」

よくある分け方と、その問題点です。

分け方 問題
金額で分ける 100円でも取り消せない支払いがある
重要度で分ける 重要かどうかは主観。基準にならない
本番 / 開発で分ける 開発環境でも外部に送信できることがある
取り消せるかどうか 客観的に判定できる

「取り消せるか」は、誰が見ても同じ答えになります。基準として使えるのは、これだけでした。

実際に分けるとこうなります

作業 取り消せるか どうするか
調べる・読む・下書きを作る 取り消せる 自動でOK
ファイルを作る・書き換える 戻せる（履歴があれば） 自動でOK
お金を払う・課金する 取り消せない 人が押す
消す・公開する・送信する 取り消せない 人が押す
毎月の支払い・自動更新 止められる 上限を決める
外部サービスへの登録 条件による 上限を決める

注意点が1つ。「ファイルを書き換える」が安全なのは、履歴がある場合だけです。 git 管理外のファイルは、書き換えた時点で取り消せません。

4. 「上限を決める」が必要な理由

3つ目の分類が要る理由を説明します。

人が押す     → 毎回止まる。自動化の意味が薄れる
自動でOK     → 際限なく実行される
上限を決める → 自動で動くが、決めた範囲で止まる

繰り返し実行されるもの（定期支払い、API呼び出し、外部登録）は、1回ずつ承認するのが現実的ではありません。先に範囲を決めて、あとは自動にします。

Google の AP2 も、同じ構造でした

AIが支払いをするための共通ルール「AP2」（2025年9月発表・60を超える組織が参加）の公式ドキュメントに、こうあります。

ユーザーは事前に詳細な Intent Mandate に署名します。この Mandate には価格制限、タイミング、その他の条件など、エンゲージメントのルールが指定されています。

条件が満たされると、エージェントがユーザーに代わって Cart Mandate を自動的に生成できるようになります

つまり、先に条件に署名して、あとは自動という形です。書ける条件は3つでした。

項目 意味
価格制限 いくらまでか
タイミング いつまでか
その他の条件 どんなときか

60社が集まって作った仕組みも、結局「先に範囲を決める」でした。 個人の設定も同じ考え方で足ります。

5. 今日できる設定

実際にやることは4つです。全部で5分ほどでした。

# やること 時間
1 お金を使う操作を「人が押す」に変える 1分
2 AI用のカードを、生活用と分ける 2分
3 そのカードに上限額を設定する 1分
4 何を許可したかを書き残す 1分

とくに効くのは2番です

AIに使わせるカードを分けて、上限を決めておく。何かあっても、そこで止まります。

銀行口座を直接つながないでください。口座には上限がありません。

4番を忘れがちです

冒頭に書いた「どこまで許してたんだっけ？」が、まさにこれでした。

こわいのは、AIが暴走することではない
自分が何を許したか、覚えていないこと

許可した内容と日付を、どこかに1行で書いておく。これだけで、あとから直せます。

この続き（作業別の判定表6パターン、設定の手順、この先どうなるかの予測5つ）は、note に有料でまとめています。

この記事だけでも、権限設計の考え方は分かるように書いてあります。表の形で手元に置きたい方だけ、こちらへどうぞ。

→ 人間はAIに財布を握られる。お金を使う権利までAIに奪われる時代へ

6. 判例も、同じ方向を向いていました

権限の話は、技術だけの問題ではなくなっています。

2026年8月4日、米第9巡回控訴裁が Amazon 対 Perplexity の件でこう判断しました。

記録上、Amazonのコンピュータシステムにアクセスしているのは Perplexity ではなく、Amazonの顧客である

AIが画面を操作してアクセスした場合、そのアクセスは「使った人」のものとして扱われました（CFAA上の判断）。

ただし、ここは正確に分けます。

決めたこと     → CFAA 上の「アクセス」は誰か
決めていないこと → AIが誤発注したとき、誰が代金を払うか

お金を誰が払うかは、まだ決まっていません。 予備的差し止めの段階の判断で、本案の判決も出ていません。

つまり、守ってくれるルールがまだない状態です。だから自分で権限を絞るしかない、というのが調べ終えての結論でした。

まとめ

事故の大きさ = 渡した権限の大きさ
　　　　　　　（AIの賢さではない）

分ける基準  = 取り消せるかどうか
　　　　　　　（金額でも重要度でもない）

3つに分ける = 自動でOK / 人が押す / 上限を決める

そして、いちばん大事なのはこれでした。

自分が何を許したか、記録しておく。

モデルはこれからも賢くなります。でもまちがえる確率はゼロになりません。 だから、まちがえたときに戻せる形にしておくのが、設計の仕事だと思っています。

もっと詳しく

作業別の判定表（6パターン・自動でOK / 人が押す / 上限を決める）、設定の手順、この先どうなるかの予測5つ（時期と確信度つき）は note にまとめています。

人間はAIに財布を握られる。お金を使う権利までAIに奪われる時代へ
https://note.com/nextsurvive/n/nbf2b53c8866e

関連記事（Qiita）

参考にした情報

2
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?