「信頼済みコマンド」を設定しても夜間オート実行はできなかった - claude --helpで分かった見落とし

クラウド上のAI開発環境で「夜間に無人で動かす」ことが増えている。記事の著者も、許可リスト方式の設定を入れれば完全自動化できると思い込んでいた。しかし実際には git push や PR作成の手前で止まった。原因は、許可リスト（permissions.allow）と呼ぶセキュリティレイヤーとは別に、--dangerously-skip-permissions や --permission-mode という上位レイヤーの権限設定が存在していたこと。つまり「許可リストで承認をゼロにする」「夜間バッチを完全無人で回す」という両立不可能な要求を混同していたわけだ。

AIの鬼の視点としていちばん引っかかるのは、セキュリティと自動化の仕組みの層が分かれているのに、多くのエンジニア（この著者含む）が「許可リスト設定すれば終わり」と思ってしまう構造だ。実は公式ドキュメントにはちゃんと書いてある。だが検索で見つかる実装例や「これをコピペすればOK」というブログ記事には、その区別が書かれていない。この「知ってる人には当たり前だが、調べた人には見落とされがちな前提」は、どの自動化ツールにもある。実装者側は層を意識してるのに、ユーザー側では透明化されてしまう。結果、期待と現実のズレが起きてからヘルプを探すという逆順になる。記事が指摘するように --dangerously-skip-permissions は「サンドボックス限定」と明記されているのに、これを普段使いのマシンで有効にすれば、読み込んだWebページやコード内に仕込まれた指示をエージェントが疑いなく実行してしまう。権限の昇格は、自動化の度合いに正比例してリスクも昇格する。

ただし記事の最後に出てくるEC2+tmuxの隔離環境という発想は実務的だ。本番環境と切り離した使い捨て環境を用意し、そこだけでバイパスを有効にする。中小企業がAIエージェントで社内システムを自動化するなら、同じ考え方が必須だ。「全自動化する」と「安全に自動化する」を両立させるには、実行環境の分離が欠かせない。単にコマンドを許可リストに加えるのではなく、そのコマンドが動く環境そのものを制御するという一段上の判断が要る。