無人で動かすAIコーディングエージェントの権限設計｜Claude Code・Codex・OpenCode・Hermes
対話中なら「このコマンドを許可しますか」に答えられます。午前 3 時の定期実行では答える人がいません。無人運用の権限は、対話時の設定をそのまま流用できません。
Claude Code、Codex、OpenCode、Hermes Agent には、それぞれ承認や制限の仕組みがあります。違いを追うと、無人運用で先に決めるべき境界が見えてきます。
プロンプトより外側で止める
「危険な操作をしないで」と書くことには意味があります。ですが、それだけでは権限制御になりません。
Claude Code の公式資料は、permission rule をモデルではなく Claude Code 本体が強制すると明記しています。判定順は deny、ask、allow です。広い deny に一致した操作を、狭い allow で通すことはできません。
Codex は sandbox mode と approval policy を分けます。前者は書き込める場所やネットワーク到達範囲を技術的に制限します。後者は、どの場面で人へ確認するかを決めます。CLI と IDE 拡張のデフォルトでは、ネットワークを切り、書き込みを作業領域へ絞ります。
指示文は進行方向を決めます。権限設定はガードレールを置きます。この 2 つを混ぜない方がよいです。
製品ごとに「無人」の扱いが違う
| 製品 | 書き込みとコマンド | 無人実行で見る点 |
|---|---|---|
| Claude Code | allow、ask、denyをルール化 | dontAsk は未承認ツールを自動拒否する |
| Codex | OS sandboxとapproval policyを併用 | workspace外とネットワークを別々に制御する |
| OpenCode | エージェント単位でask、allow、denyを指定 | 読み取り専用のsubagentを作りやすい |
| Hermes Agent | 危険コマンド承認と実行環境を分離 | cronの危険操作はデフォルトでdenyになる |
Claude Code の dontAsk は、事前許可していない操作を止めます。確認待ちで固まるのではなく、拒否したうえで別の手段を探させたい無人処理に合います。
OpenCode では permission をエージェントごとに変えられます。公式の Explore と Scout は読み取り専用です。レビュー担当には edit: deny、実装担当には作業領域内の編集だけを許す、といった分担を設定ファイルへ落とせます。
Hermes Agent は approvals.cron_mode のデフォルト値が deny です。承認が必要な危険コマンドを拒否し、エージェントは別の手段を探します。単発の -q や webhook など、人が答えられない経路も同じ fail-closed の考え方です。cron 側の境界を厚くしたい場合は、cron権限を3層で止める手順へ進みます。
ホストへ届く実行環境には、設定で解除できない blocklist もあります。隔離コンテナでは、コンテナ自体を境界として危険コマンド検査を省きます。
ネットワークをファイル権限と分ける
ソースを読むだけのエージェントでも、ネットワークへ自由に出られると情報を送信できます。逆に、依存パッケージを調べる仕事では外部通信が必要です。
Codex の workspace-write は、コマンドのネットワークアクセスをデフォルトで無効にします。必要な場合は通信を有効にし、network proxy で接続先ドメインを絞れます。
Web 検索、MCP、ブラウザ操作は別の通信経路を使います。コマンド用 proxy だけでは、すべての経路を制御できません。
私なら役割を分けます。調査エージェントは Web を読めますが編集できません。実装エージェントはリポジトリへ書けますが、外部通信先を依存元へ限定します。公開担当は対象ファイルと送信先をさらに絞ります。
Git pushは独立した権限にする
ファイル編集と git push は影響範囲が違います。ローカル差分なら戻しやすいですが、共有ブランチへの push は CI や公開処理を始める場合があります。
OpenCode は bash 権限をコマンドパターンで指定できます。公式例にも git push を ask にする設定があります。Claude Code でも Bash(git push *) を deny にできます。無人ジョブへ push を許すなら、対象リポジトリ、ブランチ、事前テストを固定したいです。通常 push は残しつつ force push だけを止めたい場合は、denyルールでforce pushを止める手順が参考になります。
公開を伴う処理では、生成と公開を分ける方が管理しやすいです。生成側は下書きを push します。公開側はレビュー済みのファイルだけを変更します。時刻が来たことを承認の代わりにしません。draft と公開の置き場所を分ける実装は、draft・approved・publishedの公開ゲートにまとめています。
最初の設定は狭くてよい
無人化を始めるとき、私は次の順で権限を足します。コピー用です。1 段階ずつ通し、止まったら下表の次の一手へ進みます。
最初の5段階チェックリスト
- 読み取りと状態報告だけを許す
- 専用の作業ディレクトリへ書かせる
- 決めた検証コマンドを許す
- 専用ブランチへの push を許す
- 公開や削除は別の承認経路に残す
失敗したときの次の一手
| 止まった段階 | よくある失敗 | 次の一手 |
|---|---|---|
| 1. 読み取り | 想定外のパスを触って拒否される | 読ませるパスだけを明示し、範囲外は deny のまま残す |
| 2. 書き込み | ホームや設定ディレクトリへ書こうとして止まる | 専用 workdir だけを allow し、作業外は閉じたままにする |
| 3. 検証 | 未許可のテストコマンドで止まる | 通すコマンドを 1 件ずつ足し、広い * 許可は後回しにする |
| 4. push | 確認待ちで固まる／main や force へ向かう | 専用ブランチだけを許し、main と force push は deny 側に残す |
| 5. 公開 | 生成ジョブが公開フラグや削除まで触れる | 生成と公開を別経路にし、公開は人の承認後だけにする |
毎回すべてを許可する設定は楽ですが、失敗の範囲も広げます。エージェントが止まった理由を記録し、必要な操作だけ次回から通す方が、時間はかかっても事故を小さくできます。
関連する記事
製品横断の境界を置いたあと、個別の壁は次へ進みます。
- AIエージェントの公開事故を防ぐ｜draft・approved・publishedを分ける実装 — 生成と公開の承認ゲート
- Hermes Agentのcron権限を3層で止める｜承認・運用契約・外部保護を分ける — cron の承認境界
- Hermes Agentのdenyルールでforce pushを止める｜YOLOより強い拒否線を作る — force push の拒否線
参照した一次情報
製品の権限仕様は更新されます。次の公式ページを 2026-09-29 に再確認し、上表の記述と食い違いがないことを確認しました。数値や成功率などの効果指標は載せていません。
| 資料 | この記事で使った点 |
|---|---|
| Claude Code Configure permissions | deny → ask → allow、dontAsk、Bash(git push *) |
| OpenAI Codex Agent approvals and security | sandbox と approval の分離、workspace-write のネットワークデフォルト |
| OpenCode Agents | エージェント単位の ask / allow / deny、Explore / Scout、git push の ask 例 |
| Hermes Agent Security | approvals.cron_mode の deny デフォルト、hardline blocklist、隔離コンテナでの扱い |
