【Claude Code 連載第47回】オートモードの設定 — 分類器に「自社の内側」を教える

よっしー

こんにちは。よっしーです(^^)

背景
1. 一言でいうと何か
2. どういう場面で役立つか
3. 前提条件と、設定の実例
4. まとめ＋次回予告

背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. 一言でいうと何か

オートモードの設定（autoMode ブロック）は、「どこまでが自分たちの内側か」を分類器に教えるための設定リファレンスです。

前提を整理します。オートモードは、ツール呼び出しを分類器にルーティングすることで、定期的な権限プロンプトなしに Claude Code を走らせる仕組みです。分類器は、不可逆・破壊的・環境外を対象とした操作をブロックします。ただし拒否ルールと明示的な質問ルールは分類器より先に評価され、引き続きブロックまたはプロンプト表示を行います。

問題はデフォルトの信頼範囲が極端に狭いことです。分類器がデフォルトで信頼するのは、作業ディレクトリと、現在のリポジトリに設定されたリモートだけ。それ以外は全部「外側」です。つまり会社の GitHub 組織へのプッシュも、チームの S3 バケットへの書き込みも、社内 API への通信も、初期状態では流出の試みと区別がつかず、ブロックされます。

autoMode.environment は、そこに「うちの組織はこれ、ソース管理はここ、信頼できるバケットはこれ」と書き足すためのフィールドです。ここが埋まって初めて、分類器は「日常業務」と「情報流出」を切り分けられるようになります。

重要な性質がひとつあります。**これらのエントリは正規表現でもツールパターンでもなく、散文（自然言語）です。**分類器はそれを自然言語のルールとして読みます。書き方の指針は公式ドキュメントの表現が的確で、「新しく入ったエンジニアにインフラを説明するように書け」。この一文が autoMode 設定の性格をすべて言い表しています。

そして忘れてはならない位置づけ：分類器は権限システムの「後」に走る2番目のゲートです。ユーザーの意図や分類器の設定に関係なく絶対に実行させてはいけないアクションは、autoMode ではなく管理設定の permissions.deny に書きます。そちらは分類器が参照される前にブロックし、オーバーライドできません。

なお、オートモード自体はすべてのプロバイダーの全ユーザーが利用できます（Anthropic API、Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、サインイン済みの Claude アプリゲートウェイセッション）。利用できないと報告される場合は、サポート対象モデルや Team / Enterprise でのオーナー有効化を含む要件を確認してください。

2. どういう場面で役立つか

シーン1：自社リポジトリへのプッシュが毎回ブロックされる

オートモードを有効にした直後、最も高い確率で踏むのがこれです。分類器は自社の GitHub Enterprise 組織を知らないので、そこへのプッシュを「外部への送信」と見なします。environment にソース管理組織を1行書けば解決します。公式が勧めるロールアウト順序も、まさにここから始まります——デフォルトのまま始める → ソース管理組織と主要な内部サービスを追加（最も一般的な誤検知が消える） → 信頼できるドメインとクラウドバケットを追加 → ブロックが出たら残りを埋める。一気に全部書く必要はありません。

シーン2：組織全体に信頼設定を配りたい

autoMode は管理設定（マネージド設定）から配布できます。全開発者に同じ「内側の定義」を配れば、各自が試行錯誤する必要がなくなります。個人設定（~/.claude/settings.json）とはマージされ、開発者は各リストを拡張できますが、管理設定が提供したエントリを削除することはできません。

ただしここに注意点があります。**許可ルールはソフトブロックの例外として働くため、開発者が追加した allow は組織の soft_deny をオーバーライドできます。**公式ドキュメントはこれを明言しています——「組み合わせは加算的であり、ハードポリシー境界ではありません」。組織として絶対に破らせたくない線は、soft_deny ではなく permissions.deny（あるいは hard_deny）で引く必要があります。

シーン3：プッシュや PR 作成にだけ人間のチェックポイントを残したい

オートモードはデフォルトで、ワーキングブランチへのプッシュ、デフォルトブランチへの定期的なプッシュ、PR 作成を許可します。分類器がブロックするのは、フォースプッシュやレビュー回避のようなリスクを伴うプッシュだけです。「それでも全プッシュに人間の確認を挟みたい」場合は、permissions.ask を使います。他のすべてのアクションについてはオートモードを有効に保ったまま、特定の操作だけプロンプトに戻せます。

境界の引き方は3段階で整理できます。

境界	メカニズム	オートモードでの動作
アクション前にプロンプト表示	`permissions.ask`	コンテンツスコープのルールに対して常にプロンプト。分類器は一致するアクションを自動承認できない
アクションを実行しない	`permissions.deny`	分類器が参照される前にブロック。分類器もユーザーの意図もオーバーライド不可
このセッション限りの境界	会話で述べる（「レビューするまでプッシュしないで」など）	分類器はブロックするが、コンテキストコンパクションでその発言が消えると境界も失われうる

3番目は覚えておく価値があります。**会話で述べた制約は、コンパクションで消える可能性がある。**耐久性が要るなら ask か deny ルールにしてください。

不要・向かないケース

オートモードを使っていない場合。このページは丸ごとオートモード専用の設定です。classifyAllShell に至っては、オートモードがアクティブな間しか適用されません。
絶対的な禁止を課したい場合。autoMode.soft_deny はユーザーの意図でクリアされ、開発者の allow でも上書きされます。破られたくない線は permissions.deny（管理設定）です。
ツールパターンで機械的に止めたい場合。autoMode の各リストは散文評価です。パターンマッチで確実に止めたいなら permissions.deny を使います。
プロジェクト単位で設定したい場合。これは仕様上できません（後述）。
レイテンシに敏感なワークフロー。classifyAllShell: true は全シェルコマンドを分類器に通すので、待ち時間と分類器呼び出し回数が増えます。

3. 前提条件と、設定の実例

バージョン要件（機能ごとに異なる）

このページは機能ごとにバージョン要件が細かく分かれています。設定を書く前に確認してください。

機能	必要バージョン
`autoMode.classifyAllShell` / 拒否理由の表示	v2.1.193 以降
内部パッケージレジストリ、機密データの場所とオーディエンス、機密リモートターゲット、保護された IaC スコープの各エントリ	v2.1.195 以降
`claude auto-mode defaults` が3種類の環境エントリを出力	v2.1.198 以降
トランスクリプト証拠によるリポジトリ可視性の判定	v2.1.200 以降
リポジトリ可視性が機密情報のみをスコープする挙動	v2.1.203 以降
分類器が `.claude/settings.local.json` を読まなくなる	v2.1.207
`claude auto-mode defaults --label`	v2.1.208 以降

古い挙動として押さえておくべき点が2つ。**v2.1.195 より前は最初の5つの信頼スロットしか出力されません。**そして v2.1.158〜v2.1.206 では、Bedrock / Agent Platform / Foundry / Claude アプリゲートウェイ上のオートモードに CLAUDE_CODE_ENABLE_AUTO_MODE=1 が必要でしたが、v2.1.207 でこの要件は削除されました。

設定をどこに書くか（ここが最重要の落とし穴）

分類器が autoMode を読むスコープは3つです。

スコープ	ファイル	用途
1人の開発者	`~/.claude/settings.json`	個人の信頼できるインフラ
組織全体	マネージド設定	全開発者に配布される信頼できるインフラ
`--settings` フラグまたは Agent SDK	インライン JSON	自動化のための呼び出しごとのオーバーライド

**このリストに .claude/settings.json と .claude/settings.local.json は含まれません。**分類器はプロジェクト設定から autoMode を読みません。理由も明示されています——どちらもリポジトリディレクトリに存在するため、チェックインされたリポジトリやビルドステップが独自の許可ルールを注入しうるからです。信頼境界を定義するファイルがリポジトリ側から書き換えられては意味がない、という設計判断です。

v2.1.207 より前は .claude/settings.local.json も読まれていました。そこに autoMode を書いていた人は、**~/.claude/settings.json に移してください。**移さないと黙って効かなくなります。

なお、プロジェクト規約や動作ルール（「force push を絶対にしない」など）は CLAUDE.md に書くのが起点です。分類器は Claude 自身が読むのと同じ CLAUDE.md を読むので、1か所書けば Claude と分類器の両方を同時に制御できます。複数プロジェクトに効かせたい信頼インフラや組織全体の拒否ルールだけを autoMode に書く、という切り分けになります。

プッシュと PR に人間チェックポイントを追加する

permissions.ask に書きます。これは分類器より前に評価されるので、オートモードでも必ずプロンプトが出ます。

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

信頼できるインフラを定義する

autoMode.environment が、ほとんどの組織で唯一設定が必要なフィールドです。エントリは3種類に分かれます。

コンテキストスロット：組織名、Claude Code の主用途、クラウドプロバイダー、リポジトリ可視性、内部共有／スニペットホスティング、組織固有 CLI、シークレット管理、デフォルト／保護ブランチ、CI/CD デプロイ先、ネットワーク体制、保護されたデプロイ名前空間、データ保持──といった「背景説明」。これらをターゲットにする専用ルールは存在せず、他のルールを読む際の文脈として働きます。未設定なら None configured か保守的な仮定になります（main と master は指定するまで保護ブランチ扱い、パブリックな paste / gist サービスは指定するまで信頼境界の外側、など）。
信頼スロット：分類器が「内側」として扱う対象。信頼できるリポジトリ／ソース管理／信頼できる内部ドメイン／信頼できるクラウドバケット／主要な内部サービス／内部パッケージレジストリの6つ。リポジトリとソース管理だけが作業リポジトリとそのリモートをデフォルトに持ち、残りはすべて None configured。つまり書かない限り何も信頼されません。
感度スロット：保護ルールが高リスクとして扱う対象。機密データの場所とオーディエンス／機密リモートターゲット／保護された IaC スコープの3つ。各スロットは広いヒューリスティックがデフォルトで、例えばホスト名や名前空間に prod / production を含むものは機密リモートターゲット扱いになります。だから何も設定していなくても保護ルールは動いています。具体的なターゲットを書くと、ヒューリスティックではなくその指定に適用先が切り替わります。

リポジトリ可視性については細かい仕様があります。リポジトリは、リモートホストと名前が別途示さない限りプライベートと見なされます。トランスクリプト内の証拠で公開と判定させることもできますが、分類器が読むのはメッセージと Claude が実行するコマンドであって、その出力ではありません。したがって gh repo view を実行しただけでは足りず、あなた自身のメッセージで「これは公開リポジトリだ」と述べる必要があります。また、リポジトリをプライベートにしても秘密・個人データ・信頼されたデータをそこに置いてよいことにはならず、作業リポジトリの外から移植・再ポイント・最初に読み込まれたコンテンツは、そのリポジトリ自体の作業としては扱われません。

デフォルトを保ったまま自分のエントリを足すには、配列にリテラル文字列 "$defaults" を含めます。デフォルトはその位置に挿入されるので、カスタムエントリは前にも後にも置けます。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

書き始めるための公式テンプレートもあります。括弧内を埋め、当てはまらない行は削除して使います。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

内部パッケージレジストリについては副作用が明記されています——パブリックレジストリをバイパスするインストールはブロックされます。private npm / PyPI を使っているなら書いておかないと詰まります。

ブロック／許可ルールをオーバーライドする

environment の他に3つのリストがあり、分類器の組み込みルールを置き換えられます。

autoMode.hard_deny：無条件のセキュリティ境界
autoMode.soft_deny：ユーザーの意図でクリアできる破壊的アクション
autoMode.allow：ソフトブロックルールの例外

分類器の内部では、優先順位が4段階で働きます。

hard_deny が無条件にブロック。ユーザーの意図も allow 例外も適用されない。
soft_deny が次にブロック。ユーザーの意図と allow 例外はこれをオーバーライドできる。
allow が一致する soft_deny を例外として上書きする。
明示的なユーザーの意図が残りのソフトブロックを上書きする。

4番目の「明示的な意図」の線引きが実用上いちばん重要です。一般的なリクエストは明示的な意図としてカウントされません。「リポジトリをクリーンアップして」は force push を認可しない。「このブランチを force push して」は認可する。ユーザーのメッセージがClaude が実行しようとしている正確なアクションを直接かつ具体的に説明している必要があります。

運用の指針はシンプルです。緩めたいときは allow（デフォルトの例外がカバーしていないルーチン操作を繰り返しフラグされる場合）、厳しくしたいときは soft_deny（環境固有でデフォルトが見落としているリスク）か hard_deny（絶対に越えてはいけない線）。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

エントリに「理由」を添えている点に注目してください（staging is isolated from production and resets nightly）。散文として読まれる以上、根拠を書いたほうが分類器の判断精度は上がります。

危険な落とし穴：environment / allow / soft_deny / hard_deny のいずれかを "$defaults" なしで設定すると、そのセクションの組み込みリスト全体が置き換わります。soft_deny なら force push、curl | bash、本番環境へのデプロイ、オートモードバイパスを含む組み込みソフトブロックルールがすべて消えます。hard_deny なら組み込みのデータ流出ルールが消えます。

救いは、各セクションが独立して評価されることです。environment だけを設定した場合、allow / soft_deny / hard_deny のデフォルトはそのまま残ります。"$defaults" を省くのは、そのリストの完全な所有権を取る意図があるときだけにしてください。その場合は後述の claude auto-mode defaults で組み込みルールを出力し、設定ファイルにコピーしてから、1本ずつ自分のパイプラインとリスク許容度に照らして見直します。

すべてのシェルコマンドを分類器に通す

デフォルトでは、Bash(npm test) のような狭い許可ルールはオートモードに引き継がれ、分類器が走る前に解決されます。オートモードが一時停止するのは Bash(*) やワイルドカード化されたインタープリターのような、任意コード実行を許す広いルールだけです。

ここに穴があります。狭いルールでも、ルールのプレフィックスが想定していなかったスクリプトパスやフラグが、分類器に見られないまま通る可能性がある。塞ぎたいなら次の設定です。

{
  "autoMode": {
    "classifyAllShell": true
  }
}

これはレイテンシとカバレッジのトレードオフです。許可ルールが即座に承認していたコマンドが分類器の判断を待つようになり、各シェルコマンドが分類器呼び出しとしてカウントされます。適用されるのはオートモードがアクティブな間だけで、他の権限モードでは許可ルールは通常どおり動きます。

設定を検査する3つのサブコマンド

組み込みの environment / allow / soft_deny / hard_deny ルールを JSON で出力します。

claude auto-mode defaults

1本のルールの全文を jq に通さず読みたいときは、--label にラベルの先頭部分を渡します（例：claude auto-mode defaults --label 'Git Destructive'）。マッチングはラベルに対する大文字小文字を区別しないプレフィックスで、一致するセクションがなければ空リストが出ます。

分類器が実際に使う内容を JSON で出力します。設定があればそれを、なければデフォルトを適用した結果です。

claude auto-mode config

カスタムルールに対する AI フィードバックを得ます。

claude auto-mode critique

運用フローとしては、設定を保存したら claude auto-mode config で有効なルールを確認する（"$defaults" が展開されて配置されているのが見えます）。カスタムルールを書いたら claude auto-mode critique にかけると、曖昧・冗長・誤検知を招きそうなエントリを指摘してくれます。散文ルールは書き手の想定どおりに読まれるとは限らないので、このチェックは実質必須と考えていいでしょう。

拒否を確認して、次に何を足すか決める

オートモードがツール呼び出しを拒否すると、/permissions の「最近拒否されたもの」タブに記録されます。拒否されたアクションで r を押すとリトライ用にマークされ、ダイアログを閉じると Claude Code がモデルに「そのツール呼び出しを再試行してよい」と伝えて会話を再開します。

v2.1.193 以降は、各拒否について分類器の理由が3か所に表示されます——トランスクリプト内のブロックされたツール呼び出しの横、拒否通知の中、「最近拒否されたもの」タブの各エントリの下。この理由を読んで、直すべきなのが environment エントリなのか、allow 例外なのか、それとも次のメッセージで明示的な意図を書いて再試行することなのかを判断します。

判断の目安として公式が挙げているのは、同じ宛先への繰り返しの拒否は、たいてい分類器がコンテキストを欠いているサインだということ。その宛先を autoMode.environment に追加し、claude auto-mode config で反映を確認する、というのが定石の対処です。

プログラムから拒否に反応したい場合は PermissionDenied フックを使います。

4. まとめ＋次回予告

autoMode は、オートモードの分類器に「内側」の定義を教える設定ブロック。デフォルトの信頼範囲は作業ディレクトリと現在のリポジトリのリモートだけなので、自社インフラは書かない限り全部「外側」。
environment だけ埋めれば足りる組織がほとんど。エントリは散文で書く。新人にインフラを説明するつもりで、理由も添えて書く。
設定は ~/.claude/settings.json・マネージド設定・--settings/Agent SDK の3スコープから読まれる。プロジェクト設定（.claude/settings.json / .local.json）からは読まれない。リポジトリ側からの注入を防ぐための設計。v2.1.207 で .local.json が対象外になった点に注意。
プロジェクト規約は CLAUDE.md に書けば Claude と分類器の両方に効く。
優先順位は hard_deny > soft_deny >（allow 例外／明示的なユーザー意図）。ただし明示的な意図とは、実行しようとしている正確なアクションを直接述べたものであり、漠然とした依頼は含まれない。
"$defaults" を書き忘れると、そのセクションの組み込みルールが丸ごと消える。各セクションは独立なので、被害は書き換えたセクションに限られる。
classifyAllShell: true は狭い許可ルールの隙間を塞ぐ代わりにレイテンシを払う。
検査は claude auto-mode defaults / config / critique の3本。保存後の config 確認とカスタムルールの critique は習慣にする。
分類器は2番目のゲート。オーバーライド不能な禁止は permissions.deny（管理設定）で引く。

導入手順としては、まずデフォルトのまま動かし、ブロックされたら理由を読み、environment に足す。この繰り返しが最短です。最初から完璧な設定を書こうとしないほうがうまくいきます。

次回予告（暫定）：autoMode を組織全体に配る先である**マネージド設定（server-managed-settings）**を取り上げ、管理者がどの設定をどう配布し、ユーザーが何をオーバーライドできないのかを扱う予定です。

※連載の実際の次テーマは未確定です。