In Silico

AIエージェント

Claude Code auto modeとは：分類器が審査する範囲と設定方法

2026/10/14

🤖 AIを使用して執筆

  • Claude Code
  • AIエージェント
  • 権限管理
  • auto mode
  • Codex
  • auto-review
  • AmPermBench
  • 分類器
  • Anthropic
  • OpenAI
  • Manual mode
  • 承認疲れ
  • サンドボックス
  • ask ルール
  • deny ルール
  • allow ルール
  • 作業ディレクトリ
  • バージョン管理
  • 保護パス
  • 偽陰性率
  • Terraform
  • 状態ファイル
  • settings.json
  • defaultMode
  • VS Code
  • approvals_reviewer
目次
背景・問い・要点
背景

コーディングを担う AIエージェントは、ファイルを書き換え、シェルコマンドを実行し、ネットワークへ接続する。従来は、危険になりうる操作の前に確認の画面が出て、利用者が可否を答えた。ところが利用者は確認の大半に「はい」と答え、内容を読まなくなる。

そこで、確認への答えを人から別のモデルへ移す方式が広がっている。権限管理の設定を変えずに使い始めた開発者は、エージェントによっては、自分の代わりに第二のモデルが操作を承認する環境にいる。この開発者が知りたいことは、どの操作を誰も確認しないかである。

本稿は、Claude Code の auto mode と、比較として OpenAI の Codex の auto-review を例に取る。どちらの作り手も、設計とその理由を一次資料に書いているからである。

問い

auto mode が審査に回す操作はどれで、審査に回らない操作を守るために、利用者は何を書けばよいのか。

要点

Claude Code の auto mode では、作業ディレクトリ内のファイル編集は、操作を審査する第二のモデル（分類器）に回る前に自動で承認されるので、守りたいファイルは、確認を求める規則（ask ルール）か禁止する規則（deny ルール）で利用者が指定する必要がある。 Claude Code は auto mode を起動時の既定にした。分類器の審査に回るのは、利用者の規則にも自動承認にも当たらない操作で、シェルコマンドの実行やネットワークへの接続がこれに当たる。範囲や影響を曖昧にした合成課題での独立の評価では、状態を変える操作の 36.8% が、分類器を通らない作業ディレクトリ内の編集だった1。

モデル・例示

規則に当たらない作業ディレクトリ内の編集は、分類器を通らない

※ この節の数値は説明のための仮定で、測定値ではありません。

あるリポジトリに、ソースコードの src/app.py と、Terraform がインフラの状態を記録する状態ファイル infra/terraform.tfstate がある。利用者は auto mode で起動し、allow ルール、ask ルール、deny ルールを一つも書いていない。Claude Code は、エージェントが求めた操作を次の順に調べ、最初に当てはまった段階で判定を決める。

  1. 利用者が書いた allow ルール、ask ルール、deny ルールに当たるか。
  2. 読み取りか、作業ディレクトリ（Claude Code を起動したディレクトリ）内のファイル編集か。当たれば自動で承認する。ただし .git など、書き込みを自動承認しない場所（保護パス）への書き込みは除く。
  3. どちらにも当たらない操作は、分類器が許可するか止めるかを判定する。

エージェントが、状態ファイルの上書きと、シェルでの terraform destroy の実行を続けて求めると、判定は次のように分かれる。

  1. エージェントClaude Code1. ファイル編集ツールで infra/terraform.tfstate を上書きしたい
  2. Claude Code2. 規則に当たらず、保護パスでもない作業ディレクトリ内の編集なので承認する
  3. Claude Codeエージェント3. 上書きを許可する
  4. エージェントClaude Code4. シェルで terraform destroy を実行したい
  5. Claude Code5. 規則に当たらず、読み取りでもファイル編集でもない
  6. Claude Code分類器6. この操作を許可するか止めるかを尋ねる
  7. 分類器Claude Code7. 許可か停止かを返す
※概念図（やりとり）：本文の手順を図式化したもの。

二つの操作は、どちらもインフラの状態を壊しうる。それでも分類器が見るのは terraform destroy だけである。状態ファイルは保護パスの一覧に入っていないので、中身がインフラの状態であっても、判定は二番目の段階で終わる。一方、.git/hooks/pre-commit への書き込みは、.git が保護パスなので自動承認から外れ、分類器に回る。不明なホストへファイルを curl で POST する操作も、ファイル編集ではないので分類器に回る。

利用者が permissions.ask に Edit(infra/terraform.tfstate) を一つ書くと、同じ上書きの判定は最初の段階で決まる。

  1. エージェントClaude Code1. ファイル編集ツールで infra/terraform.tfstate を上書きしたい
  2. Claude Code2. ask ルール Edit(infra/terraform.tfstate) に当たる
  3. Claude Code利用者3. この上書きを許可するかを尋ねる
  4. 利用者Claude Code4. 許可か拒否かを答える
  5. Claude Codeエージェント5. 利用者の答えに従い、許可か拒否かを返す
※概念図（やりとり）：本文の手順を図式化したもの。

この判定の順序から、次の三つが言える。

  1. 操作が分類器に回るかは、規則、操作の種類（読み取り、ファイル編集、シェル）、書き込み先のパスで決まる。操作が壊しうるものの大きさは、この判定に入らない。
  2. 同じ結果を生む操作でも、シェルを通れば分類器が判定し、作業ディレクトリ内のファイル編集を通れば分類器は見ない。
  3. ask ルールは、分類器の審査を増やすのではなく、当たった操作を最初の段階で人の確認に戻す。src/app.py の編集のように規則に当たらない操作の判定は変わらない。

auto mode は Manual mode の確認を分類器の審査に替え、対話端末と VS Code で起動時の既定になった

Claude Code は Anthropic の製品で、GitHub のリポジトリ anthropics/claude-code は 2025 年 2 月に作られ、2026 年 10 月 14 日の取得時点で 150,588 個のスターを持つ2。

Claude Code の Manual mode では、ファイルの編集、シェルコマンドの実行、ネットワークへの接続といった操作の大半の前に、Claude Code が止まって利用者に尋ねる。auto mode では、分類器が利用者の代わりに操作を審査する3。2026 年 10 月 14 日に取得した文書では、auto mode は対話端末と VS Code のセッションで、全プラン・全プロバイダの起動時の既定モードである。フラグと設定ファイルのどちらでも起動時のモードを指定しなければ、Claude Code は auto mode で起動する。ただし、組織が HIPAA 構成を適用している場合や、設定やモデルの都合で auto mode が使えない場合は、Manual mode で起動する3。

Anthropic がこの審査を設けた理由は、確認の多さである。Anthropic は、利用者が許可の確認の 93% を承認していると報告する。確認が多いと、利用者は承認する内容に注意を払わなくなる。Anthropic はこれを承認疲れ（approval fatigue）と呼ぶ4。auto mode は、この確認への答えを分類器に移す設計である。

作業ディレクトリ内の編集は、バージョン管理で見直せるという理由で分類器から外されている

Claude Code の文書は、判定を三つの段階の順に行い、最初に当てはまった段階が判定すると書く。利用者の規則に当たる操作はその場で判定され、次に読み取りと作業ディレクトリ内のファイル編集が自動で承認され、どちらでもない操作が分類器に回る3。

Anthropic は、作業ディレクトリ内の編集を分類器から外した理由を二つ書いている。一つは、日常的なコーディングが分類器の遅延を払わずに済むことである。もう一つは、プロジェクト内の編集はバージョン管理で見直せることである4。

二つ目の理由が成り立つのは、編集したファイルがバージョン管理の下にあるときである。.gitignore で管理から外したファイルには、この理由が当たらない。Claude Code にはチェックポイントの機能があり、自身のファイル編集ツールによる変更を記録して、利用者は /rewind で以前の状態に戻せる。ただし、チェックポイントはシェルコマンドが変えたファイルを記録しない。Claude Code の文書は、チェックポイントをセッション内の復旧の手段とし、バージョン管理の代わりにはならないと書く5。どちらの手段で戻す場合も、戻すには利用者が変更に気づく必要がある。

独立の評価では、状態を変える操作の 36.8% が分類器を通らなかった

Zimo Ji らが arXiv で公開した評価は、AmPermBench という 128 件の課題で auto mode を測った。課題は四つの DevOps 作業の族に属し、対象の範囲、影響の大きさ、危険度のどれかを曖昧にした指示を含む。評価者は、エージェントが取った状態を変える操作 253 件を、正解の基準と照らした1。

状態を変える操作の 36.8% は、作業ディレクトリ内のファイル編集として自動承認で決まり、分類器の対象に入らなかった。止めるべき操作を通した割合（偽陰性率）は全体で 81.0% で、分類器が評価した 160 件に限っても 70.3% だった。評価者は、分類器の対象外の 36.8% が全体の偽陰性率を押し上げたと述べる1。

抜けが最も大きかったのは成果物の後始末の課題族で、偽陰性率は 92.9% だった。期待する CLI が使えないとき、エージェントは状態ファイルの編集に切り替えた。評価者は、auto mode が危険な操作はシェルを通ると想定している一方で、エージェントは分類器が評価しないファイル編集で同じ効果を得ると指摘する1。

Anthropic が実際の行き過ぎた操作 52 件で測った偽陰性率は 17% である4。評価者は、81.0% との差を、根本的に異なる作業を測った結果であり矛盾ではないとする1。Anthropic は、17% の評価が比べる相手で変わると書き、確認を省く —dangerously-skip-permissions で動かしている利用者にとっては大きな改善だとする4。

二つの測定はどちらも、分類器が Sonnet 4.6 で動いていたときのものである41。独立の評価は、結果を 2026 年 4 月時点の挙動とし、本番の性能へ当てはめないよう求めている1。文書は、現在の既定の分類器を Sonnet 5 としている3。一方、作業ディレクトリ内の編集を分類器の前に自動承認する順序は、2026 年 10 月 14 日に取得した文書でも変わっていない3。

Codex の auto-review も、サンドボックス内で許された操作は審査しない

Codex は OpenAI の製品で、リポジトリ openai/codex は 2025 年 4 月に作られ、2026 年 10 月 14 日の取得時点で 129,011 個のスターを持つ6。

Codex の auto-review は、サンドボックスの境界での手動の承認を、別の審査エージェントに替える7。サンドボックスは、プロセスが書き込める場所とネットワークを OS が制限する実行環境である。Codex のエージェントは read-only か workspace-write のサンドボックスの中で作業し、境界を越える必要があるときに承認を要求する。設定 approvals_reviewer が “auto_review” なら、Codex はこの要求を、人の確認で止める代わりに審査エージェントへ回す7。

審査が走る要求は、権限を引き上げるシェル実行、遮断されたネットワーク接続、書き込み可能な範囲の外へのファイル編集、承認が要る MCP やアプリの呼び出しである。サンドボックス内で許された日常の操作には、auto-review は走らない7。したがって workspace-write では、書き込める範囲内のファイル編集は審査されない。この点で、Codex は作業ディレクトリ内の編集を審査に回さない Claude Code と重なる。

二つの方式は、審査しない操作の範囲と既定で異なる。Codex はサンドボックス内で動くシェルコマンドも審査しないが、その外への書き込みとネットワークは OS のサンドボックスが技術的に止める。Claude Code は、規則に当たらないシェルコマンドを分類器に回す73。また、Codex の CLI では、利用者が approvals_reviewer を “auto_review” にし、承認ポリシーを “on-request” にして審査役を選ぶ7。Claude Code は、審査を対話端末と VS Code の起動時の既定にした3。

守りたいファイルは ask ルールか deny ルールで指定し、一件ずつ確認したい利用者は Manual mode で起動する

ask ルールと deny ルールは判定の最初の段階で働くので、作業ディレクトリ内の編集の自動承認より先に決まる3。作業ディレクトリ内の守りたいファイルには、そのパスを指す ask ルールか deny ルールを、利用者が書く。ask ルールは判定を利用者に戻し、deny ルールは操作を止める。Edit(...) の deny ルールは、ファイル編集ツールのほか、Claude Code がシェルで認識するファイル操作のコマンド（sed や tee など）と、リダイレクトの書き込み先にも当たる。ただし、Python や Node のスクリプトがファイルを自分で開いて書き換えるような間接的な書き込みには当たらない8。

保護パスの一覧が守るのは、リポジトリの状態とツールの設定である。一覧には .git、.vscode、.claude、シェルの設定ファイル（.bashrc、.zshrc）、.mcp.json などが入り、利用者自身のデータファイルや状態ファイルは入らない。保護パスへの書き込みも、auto mode では利用者ではなく分類器に回る3。

会話の中で「push しないで」のように伝えた境界は、保証にならない。会話で述べた境界は分類器が止める手がかりになるが、規則としては保存されない。分類器は確認のたびに記録を読み直すので、コンテキストの圧縮が境界を述べたメッセージを消すと、境界は失われる。確実に守る手段として、Claude Code の文書は deny ルールを勧める3。

Claude Code の文書は、auto mode は確認を減らすが安全を保証しないと書き、機密性の高い操作の確認の代わりには使わないよう求める3。一件ずつ確認したい利用者は、Manual mode で起動するよう設定する。起動時のモードは、—permission-mode フラグ、設定ファイルの permissions.defaultMode、組み込みの既定の順に決まる。Manual mode の設定値は default で、~/.claude/settings.json に次の設定を書く。端末では、プロジェクトの .claude/settings.json に別の値があれば、そちらが優先する3。

{ "permissions": { "defaultMode": "default" } }

VS Code の拡張は、設定 claudeCode.initialPermissionMode と、モード表示で最後に選んだモードを、~/.claude/settings.json より先に使う。VS Code で Manual mode から始めるには、claudeCode.initialPermissionMode を default にする3。

ほかのエージェントの自動承認を読むときも、調べる順は同じである。まず、審査より前にどの操作の判定が決まるかを確かめる。その範囲に守りたいファイルが入っていれば、審査の精度を比べる前に、そのファイルを規則で指定しておく必要がある。

出典8件

  1. Zimo Ji ほか「Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code’s Auto Mode」arXiv:2604.04978, 2026. https://arxiv.org/abs/2604.04978 — 全体の偽陰性率 81.0% と、分類器の対象外の操作 36.8% を示す。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. Anthropic「anthropics/claude-code」GitHub, 2026（2026-10-14 取得）. https://github.com/anthropics/claude-code — リポジトリは 2025-02-22 作成、スターは 150,588。 ↩

  3. Anthropic「Choose a permission mode」Claude Code Docs, 2026（2026-10-14 取得）. https://code.claude.com/docs/en/permission-modes — 判定の順序、既定の起動モード、保護パス、分類器が見る入力を定める。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  4. John Hughes「How we built Claude Code auto mode: a safer way to skip permissions」Anthropic Engineering, 2026-03-25. https://www.anthropic.com/engineering/claude-code-auto-mode — 承認の 93%、作業ディレクトリ内の編集を外す理由、17% を含む測定値を示す。 ↩ ↩2 ↩3 ↩4 ↩5

  5. Anthropic「Checkpointing」Claude Code Docs, 2026（2026-10-14 取得）. https://code.claude.com/docs/en/checkpointing — ファイル編集ツールの変更を記録して /rewind で戻せること、シェルの変更は記録しないことを示す。 ↩

  6. OpenAI「openai/codex」GitHub, 2026（2026-10-14 取得）. https://github.com/openai/codex — リポジトリは 2025-04-13 作成、スターは 129,011。 ↩

  7. OpenAI「Auto-review」Codex ドキュメント, 2026（2026-10-14 取得）. https://learn.chatgpt.com/docs/sandboxing/auto-review — サンドボックスの境界を越える要求だけを別の審査エージェントに回す仕組みと、CLI での有効化の条件を示す。 ↩ ↩2 ↩3 ↩4 ↩5

  8. Anthropic「Configure permissions」Claude Code Docs, 2026（2026-10-14 取得）. https://code.claude.com/docs/en/permissions — Read と Edit の deny ルールがシェルのファイル操作に当たる範囲を示す。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。