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

Claude Codeのautoモードとは、allowedToolsに登録したツールをAIが確認なしで自律実行できるパーミッションモードです。承認待ちの時間をなくして開発のスピードを保ちながら、allowedToolsの設計次第で安全性も両立できます。

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

autoモードとは、Claude Codeの4つのパーミッションモードの1つで、あらかじめ許可したツール（allowedTools）だけを確認なしで自動実行し、それ以外は従来通り承認を求める仕組みです。承認の手間と実行リスクのバランスを、リストの設計でコントロールできる点が最大の特徴です。

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

この記事でわかること

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

• autoモードの動作原理 — allowedToolsに登録したツールのみを自動実行し、未登録ツールは従来通り確認を求める仕組みを解説します。
• 4モードの使い分け — default・plan・auto・bypassの違いを整理し、autoモードが向くケース・向かないケースを明確にします。
• allowedToolsの設計パターン — 最小権限の原則に基づいた実務向けの構成例を紹介します。
• チームでの安全運用 — blockedToolsやHooksとの組み合わせ、段階的な権限拡張の進め方を解説します。

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

autoモードとは

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

起動方法

# コマンドライン引数で起動
claude --mode auto

# allowedToolsを同時に指定
claude --mode auto --allowedTools "Edit,Write,Bash(npm test),Bash(npm run build)"

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

設定に関する注意（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機能の対応範囲は更新が続くため、設計思想（なぜその権限にしたか）を残しておく方が、細かい手順書だけを残すより長く使える資産になると考えています。

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

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

default/plan/auto/bypassの比較

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

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

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

ただし、autoモードは万能ではありません。ワイルドカード指定が想定外のコマンドに一致してしまうケースや、MCP連携で外部サービスへの書き込みが発生するケースでは、影響範囲が大きいため慎重な検証が必要です。完全自動化が前提のCI/CDパイプラインでは、むしろbypassモードの方が設計がシンプルになる場合もあります。

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

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

allowedToolsの設計パターン

autoモードの実用性は、allowedToolsリストの設計でほぼ決まります。許可する範囲が狭すぎると承認の手間が残り、広すぎるとセキュリティリスクが生まれるため、最初の設計が重要な工程になります。

基本構文と指定方法

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

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

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

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

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

実務での運用パターン

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

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

{
  "allowedTools": [
    "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のような破壊的コマンドは意図的にリストから外し、承認を要求する状態を保っています。ここでのポイントは、「参照・変更を伴うがローカルで完結する操作」と「外部やリモートに影響が及ぶ操作」を明確に分けている点です。この線引きがぶれると、allowedToolsを広げるたびに新しいリスクを持ち込むことになります。

コンテンツ制作向け

{
  "allowedTools": [
    "Edit",
    "Write",
    "Bash(node *)",
    "Bash(npx *)"
  ]
}

マークダウン記事やHTMLの生成・変換スクリプトの実行を自動化するパターンです。CRM連携のコンテンツパイプラインでは、記事生成からHTML変換までの反復作業が多いため、autoモードとの相性が良いと考えています。開発者向けの構成と比べると許可するコマンドの種類は少なく見えますが、Node/npx経由で任意のスクリプトが実行できてしまう点には注意が必要で、実行対象のスクリプト自体をレビューしておく運用と組み合わせることをおすすめします。

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

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

.claude/settings.jsonでの永続化

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "auto",
    "allowedTools": [
      "Edit",
      "Write",
      "Bash(npm *)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ]
  }
}

この設定ファイルをGitリポジトリに含めれば、担当者が変わってもレビューを経て同じ権限ポリシーで作業を引き継げます。個人の裁量に権限判断を委ねるのではなく、設定ファイルという仕組みで残しておく方が、属人化を避けられます。新しいメンバーが参加したときも、このファイルを読めば「このプロジェクトでは何が自動実行され、何が承認制なのか」を把握でき、口頭での引き継ぎに頼らずに済みます。

設定の優先順位

1. コマンドライン引数（--mode auto）が最優先
2. プロジェクト設定（.claude/settings.json）
3. ユーザー設定（~/.claude/settings.json）

優先順位を理解しておくと、チーム共通のポリシーを.claude/settings.jsonに残しつつ、個人の環境だけ一時的に上書きするといった柔軟な運用もできます。例えば、普段はプロジェクト設定のautoモードで作業しつつ、特定の調査作業だけ一時的にコマンドライン引数でdefaultモードに戻す、という使い方も可能です。

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

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

段階的に権限を広げる

最初からすべてのツールを許可するのではなく、まずはdefaultモードで作業しながら頻繁に承認するツールを特定し、そこから少しずつallowedToolsに追加していくアプローチが安全です。

Week 1: defaultモードで全操作を確認
  ↓ 頻繁に承認するツールを特定
Week 2: autoモード + 最小限のallowedTools
  ↓ 安定を確認
Week 3+: 必要に応じてallowedToolsを拡張

いきなり広い権限を与えるのではなく、まずは基本的なEdit・Write・テスト系コマンドだけをallowedToolsに加え、運用が安定してから段階的に範囲を広げていく進め方が、事故を避けながら生産性を上げる現実的な方法だと考えています。企業様によって開発フローやリスク許容度は異なるため、この期間を1週間単位にするか2週間単位にするかは、自社のリリース頻度に合わせて調整いただくのがよいと考えています。

blockedToolsとHooksによる多層防御

allowedToolsだけでなく、blockedToolsで危険なコマンドを明示的に禁止できます。

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

Hooksを併用すれば、「autoモードで自動実行しつつ、実行ログを記録する」「特定ファイルの変更前にバックアップを取る」といった多層防御が実現します。allowedToolsで許可範囲を絞り、blockedToolsで例外を塞ぎ、Hooksで実行の痕跡を残す——この3層で設計しておくと、何か問題が起きたときにも原因を追跡しやすくなります。個人のスキルや注意力に頼るのではなく、この3層構造そのものを「仕組み」として運用に組み込んでおくことが、チームの人数が増えても崩れない設計につながります。

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

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

上の画面は、HubSpotのBreezeカスタマーエージェントのトーン・応答スタイルを設定するガイドライン画面です。

AIエージェントに事前に「どこまで任せるか」の枠組みを与えておくという発想は、Claude CodeのallowedTools・blockedToolsで自動実行の範囲をあらかじめ定義しておく設計思想と共通しています。どちらの場合も、AIの自律性を高めるほど、その手前でどこまでの範囲を許可するかという設計の丁寧さが問われることになります。

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

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

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

少数精鋭組織での役割分担

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

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

よくある質問

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

autoモードはallowedToolsリストに登録したツールだけを自動実行し、未登録のツールは従来通りユーザーに確認を求めます。一方、bypassモードはすべてのツールを無条件で自動実行します。安全性を保ちながら効率化するにはautoモードが適しており、CI/CDなど完全自動化が必要な場面ではbypassモードが有効です。

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

まずはdefaultモードで作業し、頻繁に承認が必要になるツールを特定してから登録するのが安全です。一般的にはEdit、Write、テスト実行（npm test）、ビルド（npm run build）、Gitの読み取り系コマンドが候補になります。git pushやrm -rfのような破壊的コマンドは登録せず、blockedToolsで明示的にブロックしておくことをおすすめします。

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

.claude/settings.jsonにdefaultModeとallowedToolsを記述し、このファイルをGitリポジトリに含めることで、チーム全員が同じ権限ポリシーで作業できます。設定の優先順位はコマンドライン引数 > プロジェクト設定 > ユーザー設定の順なので、個人の環境で一時的に上書きすることも可能です。

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

はい、allowedToolsにmcp__サーバー名__ツール名の形式で指定すれば、MCPサーバー経由のツールもautoモードで自動実行されます。例えばmcp__slack__send_messageを登録すると、Slack連携のメッセージ送信が承認なしで実行されます。ただし、外部サービスへの書き込み操作は影響範囲が大きいため、十分にテストしてから登録することが目安です。

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

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

まとめ

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

• autoモードはallowedToolsリストに登録したツールのみを承認なしで自動実行し、未登録ツールは従来通り確認を求める「許可リスト方式」で動作します
• 4つのモード（default・plan・auto・bypass）はそれぞれ承認の挙動が異なり、プロジェクトのリスク許容度に応じて使い分けることが重要です
• allowedToolsの設計では最小権限の原則を守り、Edit・Write・テスト・ビルド系から段階的に許可範囲を広げるアプローチが安全です
• blockedToolsで破壊的コマンドを明示的に禁止し、Hooksと組み合わせることで多層防御を実現できます
• .claude/settings.jsonに設定を記述してGit管理することで、チーム全体で統一された権限ポリシーを仕組みとして運用できます

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

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

あわせて読みたい

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