「許可するからやって」では、AIは動かない
記事AIが編集した二次情報
こんにちわ、黄島成です。
本日は、AIエージェントが「承認がないとできません」で止まるとき、全部許可にしてしまう以外に手はあるのか、という話をします。
手はありました。許可の範囲を広げるのではなく、対象と操作を名指しで言う。それだけで、その場で通ります。
CodexとClaude Codeを使っていて、権限まわりで止まることが結構ありました。内部の操作はほとんどできる状態にしてあるのに、外部通信になると毎回ブロックされる。「明示承認がない限りできません」と言われる。うざったいな、と思っていました。
外部通信も永続的に許可しているつもりでした。「そこはもう許可しているからやっていいよ」と伝えても、毎回引っかかる。原因を調べるのも、内部の設定をいじるのもめんどくさい。そのままなあなあにしていました。
「やってください」では通らない
「GitHubへの接続がブロックされました。私にはこれ以上できません」と言われたとします。そこで「やってください」と返す。また「私にはできません」と返ってくる。「承認しますのでやってください」と言い方を変えても、結果は同じでした。
言葉を強くしても意味がなかった、というのがこの件のいちばん妙なところです。「今後も許可するからやって」は「やってください」よりはっきりした承認のはずなのに、同じように弾かれる。強さの問題ではありませんでした。
通ったのは、こう言ったときです。
「GitHubへプッシュしてください」
対象と操作を言っただけです。許可という言葉すら入っていない。それで動きました。
技術的なブロックというより、キーワードで発火しているような動きに見えました。ここは自分の捉え方で、内部の実装を確かめたわけではありません。ただ、挙動としては、承認の意思を読み取っているというより、名前が一致したかどうかを見ている感じでした。
リポジトリを消すときと同じだった
考えてみれば、同じ形を毎日見ています。
GitHubでリポジトリを削除するとき、確認欄にリポジトリ名をそのまま打ち込みます。打ち込んだ文字列が一致して、初めてDeleteが押せる。公式のドキュメントにも、削除しようとしているリポジトリが正しいことを確かめるために、テキストボックスへその名前を入力する、と書かれています。
「本当に削除しますか」に「はい」で消える設計にはなっていません。
ここが面白いところで、確認欄が守っているのは、意思の強さではないんですよね。「はい」を押す人は、削除する気が十分にあります。足りないのはやる気ではなく、どのリポジトリの話をしているかの特定です。だから名前を打たせる。
エンジニア向けのサービスでは、重要な操作を具体的なキーワードとの一致で発火させる仕組みがよくあります。AIの外部通信も、それに近い動きになっていました。「いいからやって」が通らなかったのは、承認が足りなかったからではなく、対象が入っていなかったからです。
言い換えると、こちらが渡していたのは気持ちだけでした。「許可するからやって」という文には、許可する意思は入っていますが、何をしていいのかが入っていません。必要だったのは、許可するという宣言ではなく、何をしていいのかを明示的に伝えることのほうでした。
この見方に立つと、うまくいかなかった順番にも説明がつきます。ブロックが出るたびに自分がやっていたのは、承認の言い方を強めることでした。強めるほど、文からは対象が抜けていきます。「今後も許可する」は範囲の話で、「GitHubへプッシュする」は対象の話です。ずっと範囲の側を大きくしていたので、いつまでも発火しませんでした。
止まるのは通信だけ、という線
なぜ内部の操作は全部通るのに、外部通信だけが止まるのか。ここは設定の話として確認できます。
Codexの既定であるAutoは、作業ディレクトリへの書き込みを許すサンドボックスと、必要なときに承認を求める方針の組み合わせで動きます。作業ディレクトリの中でのファイル読み書きとコマンド実行は自動で通り、ワークスペースの外に出る操作とネットワークアクセスだけが承認へ回る。公式のドキュメントには、エージェントは既定でネットワークアクセスをオフにして動く、とはっきり書かれています。設定で通信自体を有効にする項目も別に用意されています。
さらに、通信を全部開けるか全部閉じるかの二択でもありません。プロキシを指定して、通信先を承認済みドメインの許可リストに絞る設定も用意されています。線は、消すか越えるかだけでなく、引き直すこともできる構造になっている。
つまり、バグでも設定の書き漏らしでもありませんでした。最初からそこに線が引いてあります。
自分は「ほぼフルアクセスに近い状態」にしてあるつもりでいました。実際にフルアクセスだったのは内部だけです。線の内側を広げる作業をずっとやっていて、線そのものは一度も動かしていなかった。ブロックが毎回同じ場所で出ていたのは、当たり前でした。
設定へ書き足すほど、通らなかった
ここまで来ると、具体的な言葉が効くなら、設定ファイルにも具体的に書き込めばいい、という話になりそうです。
自分がやったのは逆でした。
ブロックされるたびに設定をいじったり、永続的な許可を記録したりしても、あまり意味がなかったからです。むしろ、CodexのグローバルなAGENTS.mdとClaudeのCLAUDE.mdに置いているものは、削って哲学だけにしました。Simple is best、Make sense、Evidence based、Clean as you go、Fix the root cause。この5つです。
それまでは何度も、他の人のAGENTS.mdを参考にして作り込んだり、高次元AIに作らせたりしていました。毎回腑に落ちませんでした。理由は、自分で理解していなかったから、自分で考えなかったからです。時間が溶けるまでAIを使い倒して、脳が沸騰するまで対話した結果、哲学だけでいいなと感じました。
矛盾しているように見えて、実は同じことを言っています。
設定は、常時どういう性格で動くかを決める場所です。承認は、今この操作を通すかどうかを決める場所です。混ぜると、常時の側が肥大していくのに、今この操作の側は空っぽのままになる。永続的な許可をいくら書き足しても、目の前のブロックが解けなかったのは、書いていた場所が違ったからでした。
許可ルールの書き方自体も、よく見ると名指しの形をしています。Claude Codeの設定でallowに並べるのは、たとえばBash(npm run lint)のような、ツール名とその引数の組です。「全部いい」と宣言する欄ではなく、名指しを束にして置いておく欄になっている。設定に書くか、その場で言うかの違いだけで、要求されているものは最初から同じでした。
指示は、複雑にすればするほど不完全性が高まると考えています。余計なことを言うと、AIは逆に暴走します。承認まわりで自分が長いこと作っていたのは、まさにその余計なことのほうでした。
哲学の5つのうち、この件にいちばん効いたのはFix the root causeです。表面的な症状を取り繕うのではなく、原因まで掘り下げて、再発しない形で根本から解決する。設定をいじってその場をしのぐのは、症状の取り繕いのほうでした。原因はブロックの側ではなく、こちらが渡している文の側にあった。
自分の要望や過去のやりとりについては、フロンティアモデルのメモリシステムに任せています。そちらが覚えてくれるものを設定ファイルへ二重に書くと、書いた分だけ挙動が読めなくなる。だから哲学だけをそっと置いています。今はこのアプローチで暴走することもありませんし、出したいアウトプットへ日々パーソナライズされている感じがします。
「全部許可」に流れる理由
出回っている答えの多くは、逆方向を向いています。承認を求められること自体を止めにいく。「毎回承認を求められる」「YES地獄」といった言葉で語られていて、需要としてはよく分かります。
自分が変えたのは、承認を消すことではなく、承認の通し方でした。この違いは、作業中の手触りとしてかなり大きいです。前者は線を消す作業で、一度やれば終わります。後者は線を残したまま、止まるたびに1行で越える。越える1行が短いので、結果として止まっている時間はほとんどなくなりました。
ここは条件を書いておきます。自分が確かめたのはAutoモードでの話です。フルアクセスの場合にどうなるかは分かりません。ただ、多くの人は基本的にAutoモードを使っていると思うので、同じ場所で止まっている人は多いはずです。
CodexやOpenAIだけでなく、Anthropic側でもおそらく同じだろうと思っています。これは自分の実体験から掴んだ範囲で、両方を並べて検証したわけではありません。
触る場所を間違えていた
必要だったのは、純粋にシンプルで具体的な許可でした。設定でも、永続化でも、言い方の強さでもない。
最近よくあったブロックのオチは、そんな単純な解決方法でした。原因を調べるのがめんどくさくてなあなあにしていたわりに、解けてみれば1行です。
だから、次にAIが「できません」で止まったときに触る場所は、設定ファイルではありません。次に打つ1行のほうです。そこに、どこへ、何をするのかが入っているかを見る。入っていなければ、どれだけ許可を重ねても通りません。
自分で考えて、自分が理解して、制御できる範囲でAIを使わないと、能力を拡張することはできないと感じています。残るのは、スパゲッティコードとブレインフォグだけです。承認の解き方も、たぶん同じ話でした。
出典の記録
この記事は、次の記録をAIが読み、編み直したものです。