AIエージェントの自動承認と責任の設計 — 人間の確認はどこに残るか

Claude Codeの新規セッションは、Pro・Max・Teamプランでauto modeから始まるようになりました。Coworkの承認モードにも「Automatically approve」があり、実行前の安全チェックを挟みながら止まらず進みます。さらにv2.1.232では、会話全体を引き継ぐフォーク型サブエージェントが既定でオンになり、対話セッションでのエージェント起動はバックグラウンド実行が既定になりました。

一つひとつは別々の機能変更です。しかし並べると、同じ1つの判断が読み取れます。「実行前に人間が確認する」を既定から外し、承認という仕事を別の場所へ移すという判断です。AIエージェントの自動承認とは、承認を無くすことではなく、承認の実施者と実施タイミングを設計し直すことを指します。この記事では、承認の仕事がどこへ移ったのかを構造で確認し、人間の確認をどこに残すかをまとめます。

「毎回確認する」が担保していたもの

Claude Codeの当初の既定は意図的に保守的でした。ファイル書き込みとBashコマンドは毎回承認を求める。この設計が担保していたのは安全性だけではありません。すべての行為が人間の目を一度通るという事実そのものが、「誰が承認したのか」という問いへの答えでした。事故が起きても、直前に承認した人間がいます。

代償は速度です。大きなタスクを任せて席を離れることができず、承認待ちで作業が止まります。実際にはプロンプトの大半が承認されており、承認リクエストの93%がそのまま許可されている実態が公式の分析で示されています。ほぼ全部にYesと答える確認フローは、注意力を消費するだけで判断として機能していません。一部の開発者が --dangerously-skip-permissions で確認を丸ごと外していたのは、この帰結です。auto modeは公式自身が「その中間の道」として投入した機能です。

既定の反転はどこまで進んだか

転換は1年かけて段階的に進みました。時系列で並べると、方向が一貫していることが分かります。

Coworkも同じ構図です。承認モードはManual・Auto・Skipの3つで、Autoは実行前に毎回安全チェックを走らせながら止まらず進みます(3モードの具体的な違いは別記事で扱っています)。

同時に、反転しなかった場所も見ておく価値があります。EnterpriseプランとClaude ConsoleのAPIキー、Bedrock・Vertex AI・Foundry経由、claude -p の非対話実行とAgent SDKは、いまもManualが既定です。インストール直後の初回セッションも対象外です。既定を変えたのは「個人が自分の裁量で使う環境」だけで、組織が明示的に統制する環境と無人実行では既定を動かしていません。この線引き自体が、責任の所在を意識した設計だと読めます。

承認の仕事は4つの場所に分かれた

Manualモードの承認プロンプトは、実は複数の仕事を1つのボタンに束ねていました。暴走の防止、意図の確認、責任の記録。自動承認への転換は、この束を解いて別々の仕組みに配り直す作業です。

1つ目の分類器は、auto modeの中核です。監視専任の分類器モデルが各アクションを実行前に審査し、依頼を超える行為・見覚えのないインフラへの接触・読み込んだ敵対的コンテンツに起因する行為をブロックします。ブロックされたClaudeは別のやり方を探し、3回連続または累計20回ブロックされると人間へのプロンプトに戻ります。ここで重要なのは、判断する主体と作業する主体が分離されたことです。分類器はツール実行結果を読まないため、ファイルやWebページに仕込まれた指示で直接操られない設計になっています。何を止めるかの実際の基準はauto mode分類器の分析で確認できます。

2つ目は判断を伴わない境界です。denyルールはどのモードでも、分類器に諮る前にブロックします。サンドボックスは許可の判断自体を不要にする方向で、触れるファイルと到達できるドメインをOSが強制します。

3つ目は事後の可視性です。分類器の拒否は /permissions の「Recently denied」に記録され、通知が出ます。プログラムから拾うなら PermissionDenied フックがあります。Coworkでもスケジュールタスクの実行履歴を定期的に確認するよう公式が案内しており、確認のタイミングが「実行前」から「実行後」へ移っています。

4つ目が、明示的に残された人間の承認です。ここが設計の要になります。

人間の承認が残る場所は3層ある

自動承認の環境でも、人間のクリックが必須のまま残る場所は消えていません。強制力の順に3層あります。

最も固いのは「製品側が譲らない層」です。Coworkはファイルの完全削除だけ、Auto・Skipを含むすべてのモードで明示的な「Allow」を要求します。Claude Codeでも、AskUserQuestion や requiresUserInteraction の付いたMCPツール、クリティカルパスへの rm は、どのモードでも自動承認されません。

次が「自分で書く層」です。permissions.ask ルールは分類器より先に評価され、auto modeでも必ずプロンプトを出します。公式ドキュメントはpush前とPR作成前のチェックポイントとして次の書き方を示しています。

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

最も柔らかいのが「会話で述べる層」です。「レビューするまでpushしないで」と書けば、分類器はそれをブロック信号として扱います。ただしこの境界は会話履歴から都度読み直されるため、コンテキストの圧縮で発言が消えると失われます。恒久的な境界なら設定ファイル、その場限りなら会話、という使い分けです。

1年後、「承認した」の意味はどう変わるか

公式はauto modeについて「リスクを減らすが、なくすわけではない」と明言し、隔離環境での利用を推奨し続けています。ユーザーの意図が曖昧なときや環境の文脈が足りないときに危険な操作が通る可能性、逆に無害な操作を止める可能性の両方を認めたうえでの既定化です。プロンプトインジェクションについても、読んだ悪性コンテンツに気づく前にエージェントが行動しうるという注意が、CoworkのAutoモードのドキュメントに明記されています。

それでも承認ボタンを押す回数は、今後も減り続けます。ただし承認という仕事は消えません。行為ごとの承認から、境界を書く承認へ形を変えるだけです。askルールを書く、信頼するインフラを autoMode.environment に列挙する、CLAUDE.mdに「force pushは禁止」と書く(この1行は作業するClaudeと分類器の両方が読みます)。これらはすべて、かつて毎回のクリックで表明していた意図の事前一括表明にあたります。

すると「誰が承認したのか」の答えも変わります。事故の直前にボタンを押した人ではなく、境界を書いた人、あるいは書かなかった人です。境界を適切に書くには自分の環境を言語化できる必要があり、ここに新しいスキル差が生まれます。承認疲れからの解放は、環境設計の責任と引き換えです。毎回の確認に戻したい場面の手順は手動モードに戻す方法にまとまっています。

よくある質問

自動承認と--dangerously-skip-permissionsは何が違いますか

チェックの有無です。--dangerously-skip-permissions は確認を丸ごと外し、何もアクションを審査しません。auto modeとCoworkのAutoは実行前に毎回審査が走り、危険と判定された行為はブロックされます。また bypassPermissions 系の実行は、隔離されたコンテナやVMの中に限る使い方が公式の前提です。

分類器のチェックは課金されますか

環境によります。Enterpriseプランと、Claude API・Bedrock・Vertex AI・Foundryなどの従量課金環境では、分類器の呼び出しがトークン使用量に計上されます。読み取りと作業ディレクトリ内の編集は分類器を通らないため、オーバーヘッドは主にシェルコマンドとネットワーク操作で発生します。

会話で「pushしないで」と言えば設定の代わりになりますか

その場では代わりになりますが、恒久的ではありません。分類器は会話中の境界宣言をブロック信号として扱う一方、コンテキスト圧縮で該当の発言が消えると境界も失われます。確実に守らせたい境界はaskルールかdenyルールに書く方が安全です。

組織として自動承認を禁止できますか

できます。管理設定で permissions.disableAutoMode を "disable" にすると、auto modeがモード切り替えの選択肢から消え、--permission-mode auto で起動してもManualで始まります。

サブエージェントの行動は誰が確認していますか

分類器が3つの時点で確認します。起動前に委任タスクの内容を審査し、実行中は各アクションを親セッションと同じ基準で審査し、終了時には行動履歴の全体をレビューして、懸念があれば結果に警告を前置します。

まとめ

auto modeの既定化、Coworkの自動承認、バックグラウンド実行の既定化は、「人間の確認を減らす」という一方向の話ではありません。承認が束ねていた仕事を、分類器・構造的境界・事後の記録・範囲を絞った人間の確認という4つの場所に配り直す再設計です。既定に乗るかどうかより、自分の環境で「ここだけは人間を通す」をどの層に書くかが、これからの承認の設計になります。