Claude Codeを長時間自走させる方法——許可設計で「止まらないAI開発」を実現する

Claude Codeで、こんなことができたら

Claude Codeを使えば、製造業の現場でもこんなことができます。

• 受注・在庫・工程能力データから、週次の生産計画草案を自動生成するスクリプトを、仕様を伝えるだけで一気に実装
• Excelで手作業していた負荷山積み・山崩しを、過負荷検出から平準化案の提示まで自動化
• 「年月＋連番＋品種コード」の採番ロジックをkintoneに実装して、ヒューマンエラーをゼロに
• 検査装置のCSVデータをkintoneに自動登録し、合否判定まで含めたスクリプトを構築

——と夢は広がります。

ところが、実際にClaude Codeを使い始めると、最初に感じることがあります。

「許可を求めすぎじゃないか？」

ファイルを編集するたびに確認。Bashコマンドを実行するたびに確認。
気づけば「はい」を押す作業員になっている。

もちろんこれは安全装置です。前回のセキュリティ記事で解説した多層防御の一部であり、意図しない操作からプロジェクトを守っています。
しかし、プロジェクトによってはこの安全装置が生産性のボトルネックになります。

この記事では、安全性を担保しながらClaude Codeを長時間自走させるための「許可設計」を解説します。
読み終わる頃には、あなたのClaude Codeは止まらない開発パートナーに変わっているはずです。

結論：「許可を事前に設計する」だけで、Claude Codeは長時間自走できる

Claude Codeを自走させるとは、「許可を全部外す」ことではありません。必要な許可を事前に設計することです。

具体的には、以下の5つのレイヤーで許可を設計します。

#	レイヤー	やること
1	パーミッションモード	作業フェーズに合わせてモードを切り替える
2	allowルール	よく使うコマンドやツールを事前に許可する
3	セッション中の許可管理	「このセッション中は許可」を活用する
4	CLAUDE.md	プロジェクト固有の指示で自走の精度を上げる
5	Claude Teamsマネージド設定	チーム全体の許可ポリシーを統一する

graph TB
    A["① パーミッションモード
作業フェーズに合わせて切替"] --> B["② allowルール
よく使うコマンドを事前許可"]
    B --> C["③ セッション中の許可管理
その場で許可を固める"]
    C --> D["④ CLAUDE.md
自走の精度を上げる指示書"]
    D --> E["⑤ Claude Teams
チーム全体のポリシー統一"]

    style A fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
    style B fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
    style C fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
    style D fill:#fff3e0,stroke:#e65100,color:#bf360c
    style E fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20

この記事では、各レイヤーの設定方法を実際のJSON設定例とともに解説します。

パーミッションモード — 作業フェーズに合わせて切り替える

自走に最適なモード — acceptEdits

Claude Codeには5つのパーミッションモードがあります。
このうち、自走に関係するのは主に3つです。

モード	動作	自走との相性
default	すべて都度確認	安全だが自走には不向き
acceptEdits	ファイル編集は自動承認、Bashコマンドは都度確認	コーディング主体の自走に最適
bypassPermissions	全確認スキップ	コンテナ/VM専用。ローカル環境では絶対に使わない

各モードでどの操作が止まるかを図にすると、違いが一目でわかります。

graph LR
    subgraph modeDefault["defaultモード"]
        D1["ファイル読み取り ✅"] --- D2["ファイル編集 🔒確認"] --- D3["Bashコマンド 🔒確認"]
    end
    subgraph modeAccept["acceptEditsモード"]
        A1["ファイル読み取り ✅"] --- A2["ファイル編集 ✅自動"] --- A3["Bashコマンド 🔒確認"]
    end
    subgraph modeBypass["bypassPermissions ⚠️"]
        B1["ファイル読み取り ✅"] --- B2["ファイル編集 ✅自動"] --- B3["Bashコマンド ✅自動"]
    end

    style modeDefault fill:#fff3e0,stroke:#e65100,color:#333333
    style modeAccept fill:#e8f5e9,stroke:#2e7d32,color:#333333
    style modeBypass fill:#ffebee,stroke:#c62828,color:#333333

acceptEditsが自走の第一歩です。
ファイルの読み書きで止まらなくなるだけで、体感の生産性が大きく変わります。

設定方法は2つあります。

• Claude Code内で /permissions を実行してモードを切り替える
• settings.json に "defaultMode": "acceptEdits" を設定して固定する

planモード — 「考えさせてから動かす」という戦略

planモードは、自走の「逆」に見えます。分析のみ可能で、ファイル変更やコマンド実行は一切できません。

しかし実は、長時間自走の精度を上げるための重要な戦略です。

使い方のパターンはこうです。

1. まずplanモードで起動し、タスクの全体像を分析・設計させる
2. 計画が固まったら、acceptEditsモードに切り替えて一気に実行させる

この「plan → execute」のフローにより、Claude Codeが的外れな方向に自走して手戻りが発生するリスクを大幅に減らせます。

「急がば回れ」——10分の計画が、1時間の手戻りを防ぎます。

なお、Shift + Tab でplanモードと通常モードを即座に切り替えられます。
キーボードショートカット1つで「考えるモード」と「動くモード」を行き来できるのは、実際に使ってみると非常に便利です。

フェーズ別モード切り替えの実践例

実際の開発フローに沿ったモード切り替えの例を示します。

sequenceDiagram
    participant 開発者
    participant Claude Code

    Note over 開発者,Claude Code: 設計フェーズ（planモード）
    開発者->>Claude Code: 要件を伝える
    Claude Code->>Claude Code: 既存コード分析・影響範囲調査
    Claude Code->>開発者: 実装計画を提示

    Note over 開発者,Claude Code: 実装フェーズ（acceptEditsモード）
    開発者->>Claude Code: 計画を承認、モード切替
    Claude Code->>Claude Code: コード生成・修正を自走

    Note over 開発者,Claude Code: テストフェーズ（defaultモード）
    開発者->>Claude Code: モード切替
    Claude Code->>開発者: テスト実行の都度確認

    Note over 開発者,Claude Code: レビューフェーズ（planモード）
    開発者->>Claude Code: モード切替
    Claude Code->>開発者: コードレビュー・改善提案

フェーズ	モード	理由
設計	plan	要件の分析、影響範囲の調査。まだ動かさない
実装	acceptEdits	コード生成・修正の自走。ここで最も時間を使う
テスト	default	テスト実行は都度確認。破壊的操作の可能性があるため
レビュー	plan	コードレビュー、改善提案。ここも動かさない

もちろん、プロジェクトの性質に応じてカスタマイズしてください。上記はあくまで出発点です。

---

allowルール — 「よく使うコマンド」を事前に許可する

settings.json に allowルールを追加する

パーミッションモードをacceptEditsにしても、Bashコマンド実行時の確認は残ります。
npm run build や git status のたびに止まっていては、自走とは言えません。

permissions.allow で、繰り返し使うコマンドを事前に許可しておくことで、さらに止まらなくなります。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npx tsc *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(ls *)",
      "Bash(mkdir *)",
      "Bash(cat *)"
    ]
  }
}

allowルールを設定すると、コマンド実行時の流れがこう変わります。

graph LR
    A["Bashコマンド実行"] --> B{allowルールに
マッチ？}
    B -- Yes --> C["自動許可
止まらない ✅"]
    B -- No --> D{denyルールに
マッチ？}
    D -- Yes --> E["ブロック ❌"]
    D -- No --> F["ユーザーに確認 🔒"]

    style C fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    style E fill:#ffebee,stroke:#c62828,color:#b71c1c
    style F fill:#fff3e0,stroke:#e65100,color:#bf360c

この設定で、ビルド・テスト・Git操作が許可なしで実行されます。

allowルールの書き方 — ワイルドカードの使い方

ルールの書式は Tool(specifier) 形式です。
ashコマンドにはglob記法でワイルドカードが使えます。

パターン	マッチ対象	例
Bash(npm run build)	完全一致	npm run build のみ
Bash(npm run *)	npm run で始まるすべて	npm run build、npm run test 等
Bash(npm*)	npmで始まるすべて	npm も npx もマッチ

スペースの有無が重要です。Bash(npm run *) のようにスペース+* と書くと、単語の境界が強制されます。
Bash(ls *) は ls -la にマッチしますが、lsof にはマッチしません。
一方、Bash(ls*) は lsof にもマッチします。

セキュリティ上の注意：Bash(*) はすべてのコマンドを許可してしまいます。
絶対に使わないでください。

なお、Claude Codeはシェル演算子（&&）を理解します。
Bash(safe-cmd *) を許可しても、safe-cmd && rm -rf / のようなチェーンコマンドは許可されません。

設定ファイルの使い分け — 個人用 vs プロジェクト共有

設定ファイルは3つのスコープがあります。

ファイル	スコープ	Git管理
~/.claude/settings.json	ユーザー設定（全プロジェクト共通）	しない
.claude/settings.json	プロジェクト設定（チーム共有）	する
.claude/settings.local.json	ローカル設定（個人のプロジェクト固有）	しない（gitignored）

設定の優先順位は以下の通りです。上位の設定が常に優先されます。

graph TB
    M["🔒 マネージド設定
（Claude Teams / 管理者配信）
最高優先・上書き不可"] --> L["📁 ローカル設定
.claude/settings.local.json
個人×プロジェクト固有"]
    L --> P["📂 プロジェクト設定
.claude/settings.json
Git管理・チーム共有"]
    P --> U["👤 ユーザー設定
~/.claude/settings.json
全プロジェクト共通"]

    style M fill:#ffebee,stroke:#c62828,color:#b71c1c
    style L fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
    style P fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    style U fill:#fff3e0,stroke:#e65100,color:#bf360c

おすすめの使い分けはこうです。

• チーム共通のallowルール（ビルド、lint等） → .claude/settings.json（Git管理）
• 個人の好みのallowルール（エディタ系コマンド等） → ~/.claude/settings.json
• プロジェクト固有の個人設定 → .claude/settings.local.json

---

セッション中の許可管理 — 「このセッション中は許可」を賢く使う

「Yes, don’t ask again」の仕組み

Claude Codeで許可を求められたとき、選択肢は3つあります。

• Yes — 今回だけ許可
• Yes, don’t ask again — 今後同じ操作は自動許可
• No — 拒否

ここで重要なのは、「Yes, don’t ask again」の永続範囲が操作タイプによって異なる点です。

操作タイプ	永続範囲
Bashコマンド	永続的に許可（プロジェクトディレクトリ＋コマンドの組み合わせで記録）
ファイル変更	セッション終了まで

つまり、Bashコマンドの許可は次回セッション以降も有効です。
一度「Yes, don’t ask again」を選べば、二度と聞かれません。

実践テクニック — セッション序盤で許可を固める

長時間自走させる前に、最初の数分で必要なコマンドを一通り実行させ、「Yes, don’t ask again」で許可を固めていく方法が効果的です。

たとえば、最初にこんな指示を出します。

「このプロジェクトのビルドとテストを一通り実行して、動作確認してください」

Claude Codeが npm run build、npm run test などを実行するたびに「Yes, don’t ask again」で許可していく。
数分で主要なコマンドの許可が完了し、その後は自走できる状態になります。

/permissions コマンドでセッション中の許可状況を確認・調整することもできます。

このアプローチは、「settings.jsonに書くほどではないが、このセッションでは何度も使う」コマンドに有効です。

---

CLAUDE.md — 自走の精度を上げる「指示書」

CLAUDE.mdが自走精度に効く理由

許可設計で「止まらない」状態を作っても、Claude Codeが的外れな方向に走り続けたら意味がありません。

CLAUDE.mdは、プロジェクトのルール・制約・目的をClaude Codeに伝える仕組みです。
プロジェクトのルートに .claude/CLAUDE.md または CLAUDE.md を置くだけで、Claude Codeが起動時に自動で読み込みます。

自走において特に重要なのは、/compact でコンテキストが圧縮されても、CLAUDE.mdはディスクから再読み込みされるため必ず残るという点です。

長時間の自走セッションでは、会話が長くなるにつれてコンテキストが圧縮されていきます。
しかしCLAUDE.mdに書いたルールは消えません。つまり、長時間自走しても指示がブレないのです。

graph LR
    subgraph phase1["セッション開始"]
        S1["会話コンテキスト
（フル）"] --- S2["CLAUDE.md
読み込み済"]
    end
    subgraph phase2["compact実行後"]
        C1["会話コンテキスト
（圧縮）"] --- C2["CLAUDE.md
ディスクから再読込"]
    end
    subgraph phase3["さらに長時間後"]
        L1["会話コンテキスト
（再圧縮）"] --- L2["CLAUDE.md
常に完全な状態"]
    end

    phase1 --> phase2 --> phase3

    style S2 fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    style C2 fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    style L2 fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    style C1 fill:#fff3e0,stroke:#e65100,color:#bf360c
    style L1 fill:#ffebee,stroke:#c62828,color:#b71c1c

自走に効くCLAUDE.mdの書き方

自走精度を上げるCLAUDE.mdには、以下の4つの要素を入れます。

1. プロジェクト概要

# プロジェクト概要
- kintoneプラグイン開発プロジェクト
- TypeScript + webpack
- Node.js 20.x

2. コーディングルール

# コーディングルール
- 変数名はcamelCase、定数はUPPER_SNAKE_CASE
- src/components/ 配下にReactコンポーネントを配置
- any型の使用禁止

3. テスト方針

# テスト
- テスト実行: npm run test
- 新機能には必ずユニットテストを書く
- テストファイルは __tests__/ に配置

4. Git運用

# Git
- ブランチ: feature/xxx, fix/xxx
- コミットメッセージ: 日本語、動詞で始める（例：「追加する」「修正する」）

200行以内を目安にしてください。長すぎるとノイズになります。

また、@path/to/file のインポート記法を使うと、READMEやpackage.jsonをCLAUDE.mdのコンテキストに含められます。

プロジェクトの詳細は @README.md を参照。
利用可能なnpmスクリプトは @package.json を確認。

`.claude/rules/` でルールをモジュール化する

CLAUDE.mdが長くなってきたら、.claude/rules/ ディレクトリにルールファイルを分割できます。

特に便利なのは、frontmatterでパスを指定して、該当ファイルを読んだときだけルールを適用する機能です。

---
paths:
  - "src/api/**/*.ts"
---
# API開発ルール
- すべてのAPIエンドポイントにバリデーションを含める
- エラーレスポンスは統一フォーマットで返す

「APIを触るときだけこのルール」「テストを書くときだけこのルール」のように、文脈に応じたルール適用が可能になります。これにより、CLAUDE.md本体を短く保ちつつ、必要な場面で詳細なルールを読み込ませることができます。

---

Claude Teams — チーム全体の許可設計を統一する

マネージド設定 — 管理者が配信する「上書き不可」のポリシー

ここまでの設定はすべて個人単位です。しかしチームで開発している場合、メンバーごとに許可設計がバラバラになるリスクがあります。

Claude Teams / Enterprise では、サーバーマネージド設定が利用可能です（Public Beta）。

仕組みはシンプルです。

1. 管理者がClaude.aiの 管理画面 > Claude Code > Managed settings からJSON設定を入力
2. Claude Codeクライアントが起動時に設定を取得、その後1時間ごとにポーリング
3. 設定がクライアントに反映される

マネージド設定の最大の特徴は、最高優先度であること。ユーザーやプロジェクトの設定では上書きできません。

graph LR
    A["管理者"] -->|"JSON設定を入力"| B["Claude.ai
管理画面"]
    B -->|"起動時に取得"| C["メンバーAの
Claude Code"]
    B -->|"起動時に取得"| D["メンバーBの
Claude Code"]
    B -->|"起動時に取得"| E["メンバーCの
Claude Code"]
    B -.->|"1時間ごとに
ポーリング"| C
    B -.->|"1時間ごとに
ポーリング"| D
    B -.->|"1時間ごとに
ポーリング"| E

    style A fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
    style B fill:#fff3e0,stroke:#e65100,color:#bf360c
    style C fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    style D fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
    style E fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20

チーム運用で有効な設定例

チーム全体の「自走のベースライン」を統一する設定例を示します。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npx *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  }
}

この設定で実現できること：

• allow：ビルド・テスト・Git操作はチーム全体で許可。自走のベースラインを統一
• deny：.env やシークレットへのアクセスは全員ブロック。安全の境界線を統一
• disableBypassPermissionsMode：bypassPermissionsモードそのものを無効化。「全部スキップ」の抜け道を塞ぐ

allowとdenyの両方をマネージドで配信することで、「安全に自走できる範囲」をチーム全体で統一できます。

なお、個別のプロジェクト設定で追加のallowルールを足すことは可能です。
ただし、denyはマネージドが最優先なので、マネージドでブロックされた操作は誰も許可できません。

マネージドCLAUDE.md — 組織共通の指示書を配信する

許可設定だけでなく、CLAUDE.mdもマネージドで配信できます。

OS	配信先
macOS	/Library/Application Support/ClaudeCode/CLAUDE.md
Linux	/etc/claude-code/CLAUDE.md
Windows	C:\Program Files\ClaudeCode\CLAUDE.md

組織のコーディング標準、セキュリティポリシー、使用禁止パターンなどを全員に強制適用できます。マネージドCLAUDE.mdは claudeMdExcludes 設定で除外できないため、確実に全員に適用されます。

---

まとめ：自走させるための3ステップ

まずやるべき3つのこと

Step 1：acceptEditsモードに切り替える

/permissions でモードを変更してください。これだけで、ファイル編集での停止がなくなります。

Step 2：allowルールを設定する

settings.json に、プロジェクトで頻繁に使うコマンドを追加してください。
この記事のJSON設定例をそのままコピペして、プロジェクトに合わせてカスタマイズするのが最短ルートです。

Step 3：CLAUDE.mdを整備する

プロジェクトのルール・制約を書いてください。止まらないだけでなく、「正しい方向に走り続ける」ための指示書です。

「自走」と「暴走」の境界線

自走させることと、暴走させることは違います。

• 自走 ＝ 許可を設計した上で、安全な範囲を自律的に動かすこと
• 暴走 ＝ 許可を全部外して、何が起きても気にしないこと

前回のセキュリティ記事で解説した permissions.deny と、今回の permissions.allow を組み合わせることで、**「ここまでは自由に動いていい。ここから先は絶対に触るな」**という境界線を引けます。

この境界線を正しく設計できれば、Claude Codeは安全に、長時間、自走し続けます。

---

参照元（公式ドキュメント）

• Permissions
• Settings
• CLAUDE.md
• Teams

関連記事

• 

  2026-03-22

  n8nを使って自社のサイトに特化したSEOレポートを自動生成しよう

  毎月のSEOレポート、まだ手作業で作っていませんか？ GA4を開いて、Search Consoleを開いて、数字をスプレッドシートにコピペして、グラフを整えて—— 毎月この繰り返しをしていないでしょうか。 「数字を並べるだけなら何とかなる。でも、分析コメントを…

• 

  2026-03-19

  Claude Codeを使う上で最低限知っておきたいセキュリティ対策

  そのClaude Code、セキュリティ設定は大丈夫ですか？ Claude Codeを使い始めたものの、「自分のPCで動くAIって、セキュリティ的に大丈夫なのか？」と気になっている方は多いのではないでしょうか。 ChatGPTやClaude.aiはブラウザ上で…