Claude Codeの--permission-prompts noneを使う

結論：prompt待ちを拒否し、拒否結果をjobの失敗として検知する

一次情報はClaude Code公式changelogのv2.1.259、および公式headless実行ガイドです。公式情報では、無人headless hostでpromptになる操作を自動拒否し、active permission modeの判断は維持すると説明されています。認証やtoolを自動で用意する機能ではないため、実行前にjobの入力・出力・停止条件を定義します。

無人実行の設定を比較する

設定	主な役割	運用上の確認
--permission-prompts none	promptが必要な操作を自動拒否	拒否を見落とさずjob結果へ反映
--bare	hooks、skills、MCPなどの自動検出を省く	必要な設定をflagで明示し、再現性を確認
--allowedTools	指定toolをpromptなしで許可	tool名と対象scopeを最小化する
interactive実行	人間がpromptへ応答する	無人jobへ混ぜず、承認jobと分ける

例えばReadだけを許可した調査jobなら、想定外のEditやBashがpromptを発生させても自動拒否できます。これは拒否して安全側へ倒す動作ですが、拒否を無視して「完了」と扱うと、未実施の処理を成功と誤認します。出力形式と終了状態を機械的に評価し、期待する成果物がない場合はjobを止めます。

--bareとの関係も分けて考えます。bare modeは自動検出を減らして同じ環境を作る起動モードで、permission promptの扱いそのものとは別です。両方を使う場合は、設定、MCP、plugin、skill、toolをflagや明示ファイルで渡し、読み込まれた内容をsystem/initなどの実行結果から確認します。

導入手順：read-only jobから8ステップで試す

1. jobの目的を「何を読むか」「何を出力するか」「変更を許さないか」の三点で固定します。
2. Claude Codeのversionを確認し、v2.1.259以降であることと確認時刻を記録します。
3. まず--bareで自動検出を抑え、必要な入力、settings、MCP、toolを明示します。
4. Readなど必要最小限のtoolだけを許可し、Edit、削除、外部送信をjobの初期範囲から除外します。
5. 無人実行へ--permission-prompts noneを付け、promptが必要な操作を拒否できることをテストします。
6. 終了code、標準出力、エラー、構造化結果、拒否された操作を保存します。
7. 期待するファイルやJSONのschema、テスト、変更差分があるかをCIの判定へ組み込みます。
8. 一度に広い権限へ移さず、承認者、再実行条件、timeout、rollbackを決めて段階展開します。

テストでは、意図的にpromptが必要になる安全なケースを一つ用意します。例えばread-only jobへ変更操作を要求し、処理が拒否されてjob側で検知できるかを確認します。拒否文面だけを判定キーにするとversion変更で壊れる可能性があるため、終了code、構造化出力の状態、成果物の有無を複数の条件で評価します。

入力は標準入力、ファイル、固定されたpromptのどれかに限定し、jobごとに上限を置きます。公式headlessガイドが示すように、非対話実行は終了codeで成功・失敗を分岐できますが、実行中の失敗が結果として標準出力に現れる場合もあります。stdoutだけを成功判定にせず、stderr、JSON、生成物を合わせて確認してください。

無人jobが途中で止まったら、人間が同じjobを手動で再開する運用を作らないことも大切です。拒否理由、必要だったtool、入力の版、Claude Codeのversion、実行環境を記録して、承認jobへ引き渡します。再実行は同じ入力を繰り返すのではなく、権限を追加する理由とownerを台帳へ残してから行います。

企業運用の判断：自動拒否を停止線として設計する

無人化で減るのはprompt待ちであり、判断責任ではありません。定型のread-only集計やlintのように、変更と外部送信が不要な処理は自動拒否と最小toolで運用しやすい一方、production変更、顧客データ送信、依存関係更新のような処理は、promptをなくすのではなく承認jobへ切り出します。

既存のbare mode無人実行ガイドは起動時の自動検出、認証、入力、出力、timeoutを扱い、権限設定はallow・ask・denyの設計を扱います。監査ログと判断記録へ拒否と再開理由をつなぐと、無人化の範囲を後から説明できます。

jobの成功条件には、処理が終わったことだけでなく、期待された成果物があること、対象外ファイルが変わっていないこと、テストが通ったことを含めます。promptを拒否した後にClaudeが「完了」と文章で返す可能性を考え、文章の印象ではなく機械的な検証を優先します。検証に失敗したら、成果物を公開せず、人間へエスカレーションします。

チェックリスト：無人jobを公開・反映する前に

versionを固定したか／jobの入力と出力が一文で説明できるか／bare modeの要否を決めたか／toolを最小化したか／prompt拒否をテストしたか／終了codeとstdout・stderrを保存するか／成果物とschemaを検証するか／対象外変更を検知するか／timeoutと再試行回数を決めたか／拒否後の承認者とrollbackを決めたか、を確認します。

権限を広げてpromptを消すことを解決策にしないでください。promptが発生した理由が、想定外のtool、入力の汚染、project settings、MCP、pluginの読み込みなら、まず原因を分離します。問題が解消しないjobは自動公開せず、そのjobだけをHOLDして調査結果を残します。

よくある質問

--permission-prompts noneは全操作を拒否しますか？

promptが必要になる操作を自動的に拒否します。activeなpermission modeの判断や、あらかじめ許可された範囲をすべて無効にする設定ではないため、toolとmodeを合わせて確認します。

--bareを付ければpromptは出ませんか？

別の設定です。bare modeは自動検出を省きますが、promptの扱いを決めるものではありません。無人hostの待ちを防ぐ目的ならpermission設定とjobの検証を別に行います。

拒否されたのにexit codeが0なら成功ですか？

成功とは限りません。期待成果物、構造化出力、差分、テストを確認し、拒否が含まれる場合は業務上の完了条件を満たさないとして停止または人間確認へ送ります。

公式情報と無料診断

--permission-prompts noneの追加はClaude Code公式changelog、無人実行と終了状態は公式headlessガイドで公開直前に確認します。Miraigentの無料診断では、無人化する業務、権限境界、拒否時の停止、検証、承認、再開条件を整理できます。