Claude Code autoモード完全ガイド｜自動実行の設定と安全運用

Claude Codeのautoモードとは、権限ルールと自動承認で決まらない操作を別のモデル（分類器）が実行前に審査し、通常の承認ダイアログなしで作業を進められるパーミッションモードです。承認待ちの時間を減らして開発のスピードを保ちながら、拒否ルール（permissions.deny）と確認ルール（permissions.ask）の設計で、止める操作と人が確認する操作を明示できます。

「ファイル編集のたびに確認を求められて、作業のリズムが崩れる」「AIに任せたいけれど、何でも自動実行させるのは怖い」「チームで使うAIツールの権限ルールを統一したい」——このような悩みを抱えている方は少なくありません。

autoモードとは、Claude Codeのパーミッションモードの1つで、作業ディレクトリ内のファイル編集や読み取りは承認なしで進め、それ以外の操作は分類器が「依頼の範囲を超えていないか」「外部への情報送信や破壊的操作に当たらないか」を審査してから実行する仕組みです。許可ルール・拒否ルール・askルールに当たる操作は審査より先に判定されるため、承認の手間と実行リスクのバランスを、ルールの設計でコントロールできる点が最大の特徴です。なお、autoモードはリスクを完全になくすものではなく、公式も「方向性を信頼できる作業向けで、機微な操作のレビューの代わりにはならない」としています。

本記事は「Claude Code実践ガイド｜AI開発の生産性を高める運用設計」シリーズの一部です。

この記事でわかること

Claude Codeで毎回の承認操作に時間を取られている方に向けて、この記事ではautoモードの仕組みと安全な設計方法をまとめています。

• autoモードの動作原理 — 分類器が操作を審査する仕組みと、許可・拒否ルールとの判定の順序を解説します。
• パーミッションモードの使い分け — default・acceptEdits・plan・auto・dontAsk・bypassPermissionsの違いを整理し、autoモードが向くケース・向かないケースを明確にします。
• permissions.allowの設計パターン — autoモードでの許可ルールの役割（審査を省く操作の事前許可）と、実務向けの構成例を紹介します。
• チームでの安全運用 — permissions.denyやHooksとの組み合わせ、段階的な権限拡張の進め方を解説します。

Claude Codeの承認操作を効率化したいエンジニアや、チームでの自動実行ポリシーを設計したいテックリードの方に向けて書いています。最後まで読むと、自社のプロジェクトに合わせた許可ルールを設計し、安全にautoモードを導入できるようになります。

autoモードとは

Claude Codeには複数のパーミッションモードがあり、autoモードはそのうちの1つです。まずは基本的な起動方法と、バージョンによる仕様の変遷を押さえておきます。仕様がすでにわかっている方も、後述の設計思想の部分だけは読み飛ばさずに確認いただくことをおすすめします。ルールと分類器の関係を理解しないまま起動方法だけを真似ると、意図しない範囲まで自動実行を許可してしまうリスクがあるためです。

起動方法

2026年10月時点の公式ドキュメント（Choose a permission mode）では、起動時のモード指定は--permission-modeフラグで行います。v2.1.283以降は、対話セッションの起動時のモードがautoになっています。

# コマンドライン引数でautoモードを指定して起動
claude --permission-mode auto

# 非対話（-p）実行でautoモードを使う
claude -p "テストを実行して失敗を直して" --permission-mode auto

# 現在の分類器の既定ルールをJSONで確認する
claude auto-mode defaults

許可するコマンドを事前に列挙する方式は、autoモードではなくdontAskモードの使い方です（例: claude -p "..." --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"）。--allowedToolsはCLIフラグとして存在しますが、autoモードの判定は分類器が担う点が異なります。

設定に関する注意点（バージョンによる変遷）

設定に関する注意（2026年8月1日時点）: CLAUDE_CODE_ENABLE_AUTO_MODE=1 という環境変数は現在は不要です。 v2.1.158〜v2.1.206の期間、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryなどではこの変数の設定が必須でしたが、v2.1.207でその要件は削除されました。 互換性のため変数自体は受理されますが、設定しても効果はありません。この変数が「必要」と書かれている情報は古い仕様なので注意が必要です。また、autoモードは全プラン（Proを含む）で利用可能で、Team / Enterpriseでは既定で使え、管理者はマネージド設定のpermissions.disableAutoModeを"disable"にして組織全体で無効化できます。（出典: Choose a permission mode、2026年8月1日確認）

このように仕様は短期間で変わっているため、社内マニュアルに設定手順を残す場合は出典と確認日をあわせて記録しておくと、後から情報が古くなったときに気づきやすくなります。これはHubSpotのようなSaaSプロダクトでも同じで、ワークフローの仕様やAI機能の対応範囲は更新が続くため、設計思想（なぜその権限にしたか）を残しておく方が、細かい手順書だけを残すより長く使える資産になると考えています。

パーミッションモードとautoモードの位置づけ

autoモードの理解には、他のモードとの違いを押さえておくことが欠かせません。それぞれ「何を自動化し、何を人の判断に残すか」の設計思想が異なります。

default/acceptEdits/plan/auto/dontAsk/bypassPermissionsの比較

planモードは、プランを承認するまで編集をブロックするのが基本です。ただし、bypassPermissionsを使える状態で起動した対話式のターミナルセッションでは、planモードのブロックが強制されず、計画中でもファイル編集やシェルコマンドが確認なしで実行され得ます。Claudeには「編集せずに計画する」よう指示は出ますが、それを仕組みで止めているわけではありません。-pによる非対話実行やAgent SDKなどでは、planモードのブロックが維持されます。

defaultモードでは、ファイル編集のたびに「よろしいですか？」と確認が入ります。1回の作業で数十回ファイルを変更するケースでは、この確認操作だけで大きな時間ロスが発生します。autoモードは、この問題を「分類器による審査」で解決する仕組みです。

autoモードが向くケース・向かないケース

autoモードが力を発揮するのは、テスト・ビルド・Gitの基本操作など、内容が予測しやすい反復作業です。一方で、初めて触れるプロジェクトや複雑な権限要件があるコードベースでは、defaultモードで一通り作業の癖を把握してから移行する方が安全です。

ただし、autoモードは万能ではありません。分類器は既定で、curl | bashのような外部コードの実行、機微データの外部送信、本番デプロイ、force pushなどをブロックしますが、同じ操作が許可ルールに明示されていれば審査より先にルールで許可されます。MCP連携で外部サービスへの書き込みが発生するケースも、影響範囲が大きいため慎重な検証が必要です。bypassPermissionsモードは審査を行わないため、公式でも隔離したコンテナやVMでの利用に限るとされています。

導入するかどうかを判断する際の目安を整理すると、以下のようになります。

autoモードの安全性は「何を許可するか」ではなく「何を許可しないか」で決まります。許可ルール（permissions.allow）は最小限から始め、拒否ルール（permissions.deny）で破壊的コマンドを明示的にブロックする設計が、安全性と生産性を両立する鍵です。

permissions.allowの設計パターン

autoモードでも、許可ルールに一致する操作は分類器の審査より先に承認されます。実用性は、許可ルールの設計で大きく変わります。許可する範囲が狭すぎると分類器の審査や承認の手間が残り、広すぎるとセキュリティリスクが生まれるため、最初の設計が重要な工程になります。なお、autoモードに入るとき、Bash()のような任意コード実行を許す広い許可ルール、Bash(python)のようなインタープリタのワイルドカード、パッケージマネージャーの実行コマンドなどは一時的に無効化されます。Bash(npm test)のような限定的なルールは有効なままです。

基本構文と指定方法

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(npm test)",
      "Bash(npm run build)",
      "Bash(git diff *)"
    ]
  }
}

最小権限の原則で設計する

自社のプロジェクトによって扱うシステムや開発体制は異なるため、最適な許可ルールの範囲も一律ではありません。汎用的な設定例をそのまま流用するのではなく、自社の開発フローで頻出する操作を洗い出したうえで、そこから許可範囲を組み立てることをおすすめします。

例えば、npm系コマンドをすべて許可するBash(npm *)はスピードが出る一方、意図しないスクリプトが実行される余地も広がります（autoモードでは、パッケージマネージャーの実行コマンドを許す広いルールは一時的に無効化されます）。特定コマンドだけを列挙するBash(npm test)の方が動作は限定的ですが、想定外の実行を防ぎやすくなります。どちらを選ぶかは、プロジェクトのリスク許容度に応じて判断する項目です。

この考え方は、HubSpotの取引パイプラインを設計するときに「どのステージで何を必須入力にするか」を決める発想と近いものがあります。ステージ移行の条件を曖昧にしたまま運用を始めると、後からデータの粒度がバラつくのと同じように、許可ルールの範囲を曖昧にしたまま運用を始めると、後から「なぜこのコマンドまで自動実行されているのか」を追いにくくなります。最初にリストの意図を明文化しておくことが、後々の運用のしやすさに直結します。

実務での運用パターン

許可ルールの構成は、業務の性質によって最適な形が変わります。ここでは開発者向けとコンテンツ制作向けの2パターンを紹介しますが、これはあくまで出発点であり、自社の業務内容に合わせて過不足を調整いただくことが前提になります。

開発者向け（コーディング中心）

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(npm test)",
      "Bash(npm run build)",
      "Bash(npm run lint)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git diff *)",
      "Bash(git status)",
      "Bash(git log *)"
    ]
  }
}

ファイル編集とテスト・ビルド・Gitの基本操作を自動化しつつ、git pushやrm -rfのような影響の大きいコマンドは意図的にリストから外しています。ただし、リストから外すだけでは「人の承認に残す」ことにはなりません。autoモードでは、リストにない操作は分類器が審査し、force pushなどは既定でブロックされますが、通常のgit pushは分類器が問題なしと判断すれば確認なしで実行され得ます。人の確認を残したい操作は、permissions.askに明示します。

{
  "permissions": {
    "ask": [
      "Bash(git push *)"
    ]
  }
}

Bash(git push *)のように、コマンドの内容に一致するaskルールは、autoモードでも承認の確認に回ります。ここでのポイントは、「参照・変更を伴うがローカルで完結する操作」と「外部やリモートに影響が及ぶ操作」を明確に分けている点です。この線引きがぶれると、許可ルールを広げるたびに新しいリスクを持ち込むことになります。

コンテンツ制作向け

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(node scripts/convert.js *)"
    ]
  }
}

マークダウン記事やHTMLの生成・変換スクリプトの実行を自動化するパターンです。CRM連携のコンテンツパイプラインでは、記事生成からHTML変換までの反復作業が多いため、autoモードとの相性が良いと考えています。Bash(node )のようにインタープリタ全体を許可するルールは、autoモードに入るとき一時的に無効化されるため、実行するスクリプトをBash(node scripts/convert.js )のように特定して書きます。あわせて、実行対象のスクリプト自体をレビューしておく運用をおすすめします。

設定ファイルでの永続化とチーム運用

毎回コマンドライン引数を指定するのは非効率です。設定ファイルに書き出すことで、プロジェクト単位・チーム単位でautoモードの運用を仕組みとして残せます。属人的な「あの人しか権限設定を把握していない」という状態を避けるためにも、この永続化のステップは省略せずに行うことをおすすめします。

.claude/settings.jsonでの永続化

プロジェクトの.claude/settings.jsonに、次の内容を書きます。設定ファイルは厳密なJSONで、//のコメントや末尾のカンマを入れると、次回起動時に設定エラー（Settings Error）として報告されます。

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(npm test)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ]
  }
}

注意点として、公式ドキュメントによるとpermissions.defaultModeの値"auto"は.claude/settings.jsonや.claude/settings.local.jsonに書いても反映されません。起動時のモードをautoにしたい場合は~/.claude/settings.jsonに書くか、--permission-mode autoで起動します。プロジェクトの設定ファイルには、チームで共有する許可・拒否ルールを置く運用が基本です。

この設定ファイルをGitリポジトリに含めれば、担当者が変わってもレビューを経て、共通のルールを土台に作業を引き継げます。ただし、実際に適用される権限は、個人のローカル設定やユーザー設定、組織のマネージド設定との組み合わせで決まります（次項）。個人の裁量に権限判断を委ねるのではなく、設定ファイルという仕組みで残しておく方が、属人化を避けられます。新しいメンバーが参加したときも、このファイルを読めば「このプロジェクトでは何が自動実行され、何が承認制なのか」を把握でき、口頭での引き継ぎに頼らずに済みます。

設定の優先順位

公式ドキュメント（Settings files and precedence）では、同じキーが複数の場所にあるとき、次の順に高い方の値が使われます。

1. マネージド設定（組織が配布するmanaged-settings.json・MDM・サーバー管理設定）。自分の設定ファイルや--settingsでは上書きできません
2. コマンドライン（--settingsで渡すJSON）
3. プロジェクトのローカル設定（.claude/settings.local.json）
4. 共有のプロジェクト設定（.claude/settings.json）
5. ユーザー設定（~/.claude/settings.json）

permissions.allowのような配列は、上書きではなく複数のファイルの内容が合算されます。そのため、共有の.claude/settings.jsonに書いたルールに、各自のローカル設定やユーザー設定、組織のルールが加わった状態で動きます。ファイルを共有するだけでは、全員がまったく同じ権限になるとは限りません。

なお、起動時のモードだけは別の決まりで、--permission-modeフラグが最優先、次に設定ファイルのpermissions.defaultMode、最後に組み込みの既定値の順です。例えば、普段はユーザー設定のautoモードで作業しつつ、特定の調査作業だけ--permission-mode defaultでdefaultモードに戻す、という使い方ができます。

安全に運用するためのガイドライン

autoモードは便利な反面、設計を誤ると意図しない実行が起きるリスクもあります。ここでは段階的な導入手順と、多層防御の考え方を整理します。いきなり広い権限を持つ設定を組織全体に配ることはおすすめしません。まずは小さく試し、問題が起きないことを確認してから展開範囲を広げる進め方が現実的です。

段階的に権限を広げる

autoモードでは、許可ルール（permissions.allow）は自動実行の範囲を絞る仕組みではありません。allowは「分類器の審査を待たずに許可する操作」の事前登録で、allowに載っていない操作も分類器が問題なしと判断すれば実行されます。そのため段階的な導入では、まずdefaultモードで作業の傾向をつかみ、autoモードに移る時点で「決して実行させない操作」を拒否ルール（permissions.deny）に、「人の確認を残す操作」を確認ルール（permissions.ask）に明示するところから始めます。

Week 1: defaultモードで作業（読み取り以外を確認）
  ↓ 止めたい操作・確認を残したい操作を洗い出す
Week 2: autoモード + permissions.deny / permissions.ask を明示
  ↓ 分類器のブロックや確認の履歴を見る
Week 3+: deny・askを見直し、審査を省きたい定型操作だけallowに追加

allowに加えるのは、テストやビルドのように毎回同じで、分類器の審査を待つ必要がない定型の操作に限るのが現実的です。allowを広げても安全にはならず、審査を省く範囲が広がるだけなので、安全側の設計はdenyとaskで行うと考えています。企業様によって開発フローやリスク許容度は異なるため、この期間を1週間単位にするか2週間単位にするかは、自社のリリース頻度に合わせて調整いただくのがよいと考えています。

permissions.denyとHooksによる多層防御

許可ルールだけでなく、permissions.denyで危険なコマンドを明示的に禁止できます。拒否ルールはどのモードでも有効です。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)"
    ]
  }
}

Hooksを併用すれば、「autoモードで自動実行しつつ、実行ログを記録する」「特定ファイルの変更前にバックアップを取る」といった多層防御が実現します。permissions.allowは審査を省いてよい定型操作の事前許可に使い、決して実行させない操作はpermissions.denyで禁止し、人の確認を残したい操作（通常のgit pushなど）はpermissions.askで明示し、Hooksで実行の痕跡を残す——この組み合わせで設計しておくと、何か問題が起きたときにも原因を追跡しやすくなります。個人のスキルや注意力に頼るのではなく、この多層構造そのものを「仕組み」として運用に組み込んでおくことが、チームの人数が増えても崩れない設計につながります。

ビジネス活用における位置づけ

autoモードの本質的な価値は、AIエージェントの「自律性」を業務効率に変換できる点にあります。ここでは、AIに任せる領域と人が判断すべき領域の線引きを整理します。

線引きの土台になるのが、autoモードが操作を判定する順番です。次の図のとおり、まず許可ルール（permissions.allow）・拒否ルール（permissions.deny）・確認ルール（permissions.ask）に一致するかで決まり、どれにも当たらない操作のうち、読み取りと作業ディレクトリ内の編集は自動で承認されます。それ以外の操作が分類器の審査に回ります。

つまり、AIに任せる範囲は分類器だけで決まるのではなく、その手前に置く3種類のルールで、審査なしで許可する操作・禁止する操作・人が確認する操作をあらかじめ定義しておく設計で決まります。AIの自律性を高めるほど、その手前でどこまでの範囲を許可するかという設計の丁寧さが問われることになります。

AIに任せること・人が判断すること

反復的で結果の予測がしやすいテスト・ビルド・Gitの基本操作はAIの自動実行に向いています。一方で、外部サービスへの本番書き込みや、影響範囲の大きい削除・強制上書きのようなコマンドは、たとえ許可ルールに載せられる技術的な条件を満たしていても、人が最終判断を残す領域だと考えています。許可ルールに載せないだけでは確認は残らないため、確認を必須にする操作はpermissions.askで明示します。

この線引きは、HubSpotのライフサイクルステージ設計とも近い考え方です。例えばフォーム送信からMQL（ホットリード）への昇格のように条件が明確な処理はワークフローで自動化しても、失注案件をどのタイミングでどう掘り起こすかという最終的なアプローチ判断は、営業担当者が行うべき領域として残す——AIに任せる作業と人が判断する作業を分けるという考え方は、開発の現場でもマーケティング・営業の現場でも共通していると考えています。

開発現場での役割分担

一人あたりの生産性は事業成長を左右する指標の一つです。HubSpotゴールドパートナーのStartLinkが支援するCRM×AIの文脈では、HubSpotのデータ連携スクリプトの開発・テスト・デプロイの繰り返しサイクルにおいて、autoモードが承認待ちの時間を減らす場面があります。autoモードで反復作業をAIに任せ、人間は設計判断やクライアントコミュニケーションに集中する——この役割分担が、AI時代の実務設計の軸になると考えています。

経営データの可視化やコンテンツマーケティングにおけるAI活用については、経営データBI支援やコンテンツマーケティング支援のページもご参照ください。

よくある質問

Q1. Claude Codeのautoモードとbypassモードの違いは何ですか？

autoモードは、権限ルールと自動承認で決まらない操作を分類器が審査してから実行し、依頼の範囲を超える操作や外部への情報送信などをブロックします。一方、bypassPermissionsモードは審査を行わず、原則としてすべての操作を確認なしで実行します。ただし、denyルールに当たる操作や、askルールで明示的に確認を求める設定にした操作、rm・rmdirによる重要パスの削除などは、このモードでも止まります。安全性を保ちながら効率化するにはautoモードが適しており、bypassPermissionsは隔離したコンテナやVMでの利用に限るのが公式の位置づけです。

Q2. permissions.allowにはどのようなコマンドを登録すべきですか？

まずはdefaultモードで作業し、頻繁に承認が必要になるツールを特定してから登録するのが安全です。一般的にはEdit、Write、テスト実行（npm test）、ビルド（npm run build）、Gitの読み取り系コマンドが候補になります。git pushやrm -rfのような影響の大きいコマンドは登録しません。決して実行させないものはpermissions.denyでブロックし、人の確認を残したいもの（通常のgit pushなど）はpermissions.askに登録しておくことをおすすめします。リストに載せないだけでは、autoモードの分類器の判断で確認なしに実行され得るためです。

Q3. autoモードの設定をチーム全体で統一するにはどうすればよいですか？

.claude/settings.jsonにpermissions.allow・permissions.deny・permissions.askを記述し、このファイルをGitリポジトリに含めることで、チーム共通の権限ルールを土台にできます。なおpermissions.defaultModeのautoは.claude/settings.jsonでは反映されないため、起動時のモードは~/.claude/settings.jsonか--permission-mode autoで指定します。ただし、allow・deny・askは複数のファイルの内容が合算され、単一の値は優先順位の高い方が使われます。そのため、共通ルールに加えて、個人のローカル設定・ユーザー設定・組織のマネージド設定も効く点には注意が必要です。起動時のモードは--permission-modeフラグで一時的に変えられます。

Q4. autoモードでMCPサーバーのツールも自動実行できますか？

はい、permissions.allowにmcp__サーバー名__ツール名の形式で指定すれば、そのMCPツールは審査より先に許可されます。例えばmcp__slack__send_messageを登録すると、Slack連携のメッセージ送信が承認なしで実行されます。ただし、外部サービスへの書き込み操作は影響範囲が大きいため、十分にテストしてから登録することが目安です。

Q5. autoモードの実行ログを後から確認する方法はありますか？

Claude Codeはセッションごとの操作ログを自動的に記録しています。さらにHooksを併用すれば、autoモードで自動実行されたツールの入出力を任意のファイルやSlackに記録する仕組みを構築できます。「いつ・何が・どのように実行されたか」をトレースできる環境を整えておくと、autoモードの運用リスクを低減しやすくなります。

まとめ

本記事ではClaude Codeのautoモードについて、仕組みから実務での安全運用パターンまでを解説しました。

• autoモードは分類器が操作を審査して実行する仕組みで、許可・拒否・確認ルールに当たる操作と、読み取り・作業ディレクトリ内の編集は審査より先に判定されます
• パーミッションモード（default・acceptEdits・plan・auto・dontAsk・bypassPermissions）はそれぞれ承認の挙動が異なり、プロジェクトのリスク許容度に応じて使い分けることが重要です
• autoモードのpermissions.allowは自動実行の範囲を絞るものではなく、審査を省く操作の事前許可です。禁止する操作はpermissions.deny、確認を残す操作はpermissions.askで明示します
• permissions.denyで破壊的コマンドを明示的に禁止し、Hooksと組み合わせることで多層防御を実現できます
• .claude/settings.jsonにルールを記述してGit管理することで、チーム共通の権限ルールを土台として仕組みで運用できます（個人・組織の設定が加わる点には注意が必要です）

最初の一歩としては、まず自社のよく使うプロジェクトでdefaultモードのまま1週間ほど作業し、頻繁に承認しているツールを洗い出すところから始めてみてください。次に、止めたい操作をpermissions.deny、確認を残したい操作をpermissions.askに書いてからautoモードに切り替え、動作が安定したら.claude/settings.jsonに書き出してチームで共有する、という3ステップで進めると無理なく移行できます。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Code × API連携で業務システムを自動化する方法｜freee・HubSpot・Slackの実践例
• Claude Codeのステータスライン設定｜レートリミット・コンテキスト使用率をリアルタイム表示する方法
• Claude Codeキーボードショートカット一覧｜操作速度を2倍にする18のキー操作