Claude Code YOLOモードとは?--dangerously-skip-permissionsを使いこなす完全ガイド【2026年最新】
室谷今回はClaude CodeのYOLOモード、つまり
--dangerously-skip-permissionsフラグについて話しましょう。これ、.AI(ドットエーアイ)コミュニティでも毎週のように質問が来るんですよね・・・
テキトー教師ですね。講座でコミュニティのメンバーさんに「YOLOモードって何ですか?」って聞かれると、毎回30分は話してしまいます(笑)。
危険という印象が先行しすぎていて、本当に使うべき場面が伝わっていないことが多い。
危険という印象が先行しすぎていて、本当に使うべき場面が伝わっていないことが多い。
室谷名前からして怖いんですよ。
でもAnthropicがこの名前を意図的に選んだのには理由があって・・・
--dangerously-skip-permissionsって、「危険にも権限をスキップする」という意味ですから。でもAnthropicがこの名前を意図的に選んだのには理由があって・・・
テキトー教師「無意識に使えないようにしてある」というのがポイントですよね。毎回この長いフラグを打ち込まないと有効にならない。
-yみたいな短縮形は存在しない。
室谷そうなんですよ。意識的に選択しないと使えない設計になっている。
うちのMYUUUのエンジニアも最初は「怖くて使えない」って言ってたけど、適切な環境を整えたうえで使うと生産性が別次元になりますね。
うちのMYUUUのエンジニアも最初は「怖くて使えない」って言ってたけど、適切な環境を整えたうえで使うと生産性が別次元になりますね。
YOLOモードとは何か:bypassPermissionsモードの仕組み

テキトー教師まず基本から整理しますね。
このモードでは、Claudeが提案するすべてのアクションが確認なしに即実行されます。
--dangerously-skip-permissionsフラグを付けてClaude Codeを起動すると、Anthropicが「bypassPermissionsモード」と呼ぶ状態になります。このモードでは、Claudeが提案するすべてのアクションが確認なしに即実行されます。
室谷通常だと、ファイルを書き換えるたびに「これ実行しますか?」って聞いてくるじゃないですか。10ファイルのリファクタリングをしたら30回以上承認を求めてくる。
あのクリックの積み重ねが地味にキツい。
あのクリックの積み重ねが地味にキツい。
テキトー教師飛び越えられるのは具体的に言うと、ファイルの編集・作成、Bashコマンドの実行、MCPツールの呼び出し、Web fetchのリクエスト、サブエージェントの起動、こういったものすべてです。
実際のコマンドはこうなります:
# 基本的な使い方(headlessモード)
claude --dangerously-skip-permissions -p "認証モジュールをJWTに書き換えて"
# セッション名を付けて再開可能にする
claude --dangerously-skip-permissions --resume refactor-sprint "リファクタリングを続けて"
# CI/CDパイプラインに組み込む(JSON出力形式)
claude --dangerously-skip-permissions -p "lintエラーを全部直して" --output-format stream-json
室谷-pフラグは非インタラクティブモードで、プロンプトを直接渡してそのまま実行します。これを--dangerously-skip-permissionsと組み合わせると、完全に人の手を離れた自動実行になる。
テキトー教師ここで大事なのが「何がスキップされて、何がスキップされないか」という点です。スキップされないものもちゃんとあります。
室谷Claudeのコア安全トレーニング(明らかに有害な命令は拒否する)は変わらない。それに加えて、設定ファイルで指定したネットワーク制限、
.git/や.claude/(一部を除く)、.vscode/、.idea/、.husky/へのWRITEは引き続き確認を求めます。
テキトー教師あと
0か100かではないんですよね。
PreToolUseフックも依然として動作します。これを使えば「YOLOモード中でもこのコマンドだけはブロックする」という設定が可能です。0か100かではないんですよね。
Claude Codeの5つの権限モード:YOLOは最終手段
室谷YOLOモード一本に頼るのは、実は中級者の落とし穴なんですよ。Claude Codeには5つの権限モードがあって、YOLOはその最終手段に過ぎない。
テキトー教師整理すると、こういう構造です。
| モード | ファイル編集 | Bashコマンド | MCPツール | 最適なユースケース |
|---|---|---|---|---|
| Default | 種類ごとに1回確認 | 毎回確認 | 毎回確認 | 初心者・慣れないコードベース |
| Accept Edits | 自動承認 | 毎回確認 | 毎回確認 | 日常開発・コード修正中心の作業 |
| Plan Mode | ブロック | ブロック | ブロック | コードレビュー・設計検討 |
| Auto | 安全チェック後に自動承認 | 安全チェック後に自動承認 | 安全チェック後に自動承認 | 普段の開発(リサーチプレビュー) |
| Don't Ask | 事前承認分のみ | 事前承認分のみ | 事前承認分のみ | ロックダウン環境 |
| bypassPermissions(YOLO) | 全自動 | 全自動 | 全自動 | CI/CD・Docker・信頼済みセッション |

室谷大多数のケースはAccept Editsで十分なんですよね。Shift+Tabを押すだけで切り替えられる。
ファイル編集は自動承認でBashコマンドだけ確認、という使い方が現実的には一番バランスが良いと思っています。
ファイル編集は自動承認でBashコマンドだけ確認、という使い方が現実的には一番バランスが良いと思っています。
テキトー教師受講生さんがよくやる間違いが「毎回確認が面倒だからYOLO一択」なんです。でも実際は、
settings.jsonに許可ルールを書いておくだけで9割の場面は解決します。
室谷そのsettings.jsonの権限設定、これが意外と知られていないんですよね。
settings.jsonで細かく制御する:YOLOより安全で速い方法
テキトー教師settings.jsonを使うと、特定のコマンドだけを自動承認にできます。「npm run系は全部OK、でもgit pushだけは確認」みたいな設定が可能です。設定の例はこうなります:
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(bun run *)",
"Bash(git status)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git add *)",
"Read",
"Edit(/src/**)",
"Edit(/tests/**)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)",
"Bash(curl *)",
"Read(./.env*)",
"Read(./secrets/**)",
"Edit(./.env*)"
],
"ask": [
"Bash(git push *)",
"Bash(git commit *)",
"Edit(/package.json)"
]
}
}
室谷この設定、MYUUUのプロジェクトでも近いものを使ってます。
評価順は
allow、deny、askの3階層で制御できる。評価順は
deny→ask→allowで、最初にマッチしたルールが優先されます。
テキトー教師ルールの書き方のポイントをいくつか。
Bash(npm run *)のように書くと「npm run」で始まるすべてのコマンドに適用されます。*はワイルドカードで、スペース後の*は単語境界を守ります。つまりBash(ls *)はls -laにマッチしますが、lsofにはマッチしないです。
室谷ここが微妙なところで、シェルオペレーター(
&&や||)も認識してくれる。Bash(safe-cmd *)という許可ルールがあっても、safe-cmd && dangerous-cmdのような組み合わせはブロックします。
テキトー教師セッションをまたいだデフォルトモードの設定もできます。
{
"permissions": {
"defaultMode": "acceptEdits"
}
}
これをプロジェクトの.claude/settings.jsonに書いておけば、そのプロジェクトを開くたびにAccept Editsモードで起動します。
室谷設定ファイルには優先順位もあって、マネージド設定(IT部門が配布)→CLIフラグ→ローカルプロジェクト設定→共有プロジェクト設定→ユーザー設定、という順で上が優先されます。
テキトー教師チームで使う場合、
.claude/settings.jsonをgitにコミットしておくと、チーム全員が同じ権限設定で動けます。これ、講座でも強調しているポイントです。auto modeとの違い:2026年に整理されたYOLOの立ち位置
室谷このポストで書いた通り、auto modeが来てからYOLOモードを使う理由の半分は解消されました。auto modeとYOLOモードは別物として捉えた方がいいんですよね。
テキトー教師auto modeとYOLOモードの違い、整理しておきましょう。
| 比較軸 | auto mode | YOLOモード(bypassPermissions) |
|---|---|---|
| 有効化方法 | Shift+Tab(対話式) | --dangerously-skip-permissionsフラグ |
| 安全チェック | バックグラウンドで動作する | スキップ |
| 対話性 | インタラクティブに確認できる | 完全自律実行 |
| 向いている場面 | 普段の開発作業 | CI/CD・コンテナ内の自動化 |
| 安全境界 | Claudeのチェッカー | 実行環境(コンテナ等) |
室谷auto modeのcheckは「大量ファイル削除」「機密データ流出」「悪意あるコード実行」を検知してブロックする仕組みです。YOLOはそれも含めて全部スキップする。
テキトー教師「auto modeでほぼ解決するのでは?」という声もありますよね。実際、普段の開発はauto modeで十分なことが多い。
YOLOを使うのは、コンテナやCI/CDなど環境自体がセキュリティを担保している場面に限定するのが理想的です。
YOLOを使うのは、コンテナやCI/CDなど環境自体がセキュリティを担保している場面に限定するのが理想的です。
室谷そうですね。auto modeが来て「YOLOの使いどころ」がより明確になった感じがします。
YOLOモードが本当に必要な場面とは
室谷では実際にYOLOモードが必要な場面を具体的に見ていきましょう。
テキトー教師auto modeが来てからYOLOモードを使う理由の半分は解消されました。でも残り半分——CI/CDとDockerを中心とした完全自動化ワークフロー——はYOLOモードでないと実現できないんですよね。
テキトー教師具体的に言うと、こういったユースケースです。
- コンテナ内での大規模リファクタリング: 数十ファイルにまたがる変更を一気に処理したいとき
- CI/CDパイプラインでの自動修正: PRのlintエラーやテスト失敗を自動で修正するワークフロー
- テスト駆動開発のループ: 失敗するテストを書いて、通過するまでClaude自身がイテレーション
- 大量ファイルの一括変換: APIのバージョン移行やフレームワーク置き換えなど
室谷Anthropicのサーフェガードチームのエンジニアが16並列エージェントでRustベースのCコンパイラを書いたという話があって。その人のブログに「コンテナで実行してください、実際のマシンではなく」と一言書いてあった。
作った人たちが同じことを言ってるんですよね。
作った人たちが同じことを言ってるんですよね。
テキトー教師コンテナ内なら権限プロンプトはただの摩擦です。コンテナ境界がセキュリティを担保しているので、追加確認は不要になる。
Dockerを使ったセーフYOLOの構成
室谷実際のDocker設定を見てみましょう。Anthropicが推奨するdevcontainerの考え方を元にした構成です。
FROM node:20-slim
# Claude Codeをインストール
RUN npm install -g @anthropic-ai/claude-code
# 作業ディレクトリをセット
WORKDIR /workspace
CMD ["bash"]
実行はこう:
docker run --rm \
-v $(pwd):/workspace \
--network none \
-e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
my-claude-container \
claude --dangerously-skip-permissions -p "全ファイルのlintエラーを修正して"
テキトー教師--network noneが重要で、外部ネットワーク通信を完全に遮断します。--rmで実行後にコンテナを削除する。この2つで「使い捨てで閉じた環境」が作れます。
室谷あとgitのチェックポイント。YOLOを有効にする前に必ず
何か問題があっても
git commitかgit stashで状態を保存しておく。何か問題があっても
git reset --hardで元に戻せる。gitが安全網の役割を担うわけです。
テキトー教師Docker + gitチェックポイント + denyルール。この3点セットが、YOLOモードを使うときのコミュニティのコンセンサスになっています。
GitHub ActionsでのCI/CD活用
室谷GitHub Actionsへの組み込み例も見ておきましょう。
name: Claude Code Auto-Fix
on:
pull_request:
types: [opened, synchronize]
jobs:
claude-fix:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Claude Code
run: npm install -g @anthropic-ai/claude-code
- name: Run Claude Code
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
claude --dangerously-skip-permissions \
-p "lintエラーを全部修正して、テストが通るまでイテレーションして" \
--output-format stream-json
テキトー教師GitHub Actionsのランナーはそれぞれ独立したVMで動くので、コンテナと同様に分離されています。ANTHROPICのAPIキーはSecretsで管理して、絶対にコードに直書きしない。
室谷--output-format stream-jsonを指定しておくと、Claudeが何をしているかをパイプラインのログで追えます。後でデバッグするときに助かります。実際に起きた事故と教訓
テキトー教師怖い話もしないといけないですよね。コミュニティで大きな話題になった事故があります。
室谷2025年末にユーザーが「古いリポジトリのパッケージを整理して」と指示したら、Claudeが
rm -rf tests/ patches/ plan/ ~/を実行してしまったケースです。末尾の~/がシェルによってホームディレクトリに展開されて、Desktopのファイルもパスワードマネージャーのデータも全部消えた・・・
テキトー教師Simon WillisonさんがこれをXで取り上げて、Hacker Newsで大反響になりましたね。
室谷YOLO単体の問題というより「gitのチェックポイントなし」「コンテナなし」「denyルールなし」という三重の無防備状態だったのが問題で。
テキトー教師防ぎ方は明確です。
gitに作業状態をコミットしてからYOLOを使う。コンテナ内で実行する。
この3点さえ守れば、防げた事故です。
settings.jsonに"deny": ["Bash(rm -rf *)"]を書く。gitに作業状態をコミットしてからYOLOを使う。コンテナ内で実行する。
この3点さえ守れば、防げた事故です。
室谷怖い話ではあるんですが、同時に「安全に使う方法は確立されている」という話でもあるんですよね。事故の原因が明確だから対策も明確。
YOLOモードを使うときの5つのチェックリスト
テキトー教師まとめとして、使う前に確認すべきチェックリストです。
- コンテナまたは分離された環境の中で実行しているか
- gitで作業前の状態をコミット済みか
settings.jsonで危険なコマンドをdenyに入れているか(Bash(rm -rf *)、Bash(sudo *)等)- 本番のAPIキーや秘密情報がその環境に存在しないか
- ネットワークの外部通信が必要最低限に制限されているか
室谷5点全部Yesなら、YOLOモードは十分安全に使えます。1つでもNoなら、まず環境を整えることを優先してください。
テキトー教師Accept Editsモードや細かい
settings.jsonの設定で解決できるケースも多いので、「とりあえずYOLO」ではなく適切なモードを選ぶ習慣をつけることが大事だと思います。YOLOモードが輝く実践的なワークフロー3選
室谷ユースケースを具体的に3つ紹介しましょう。MYUUUで実際に使っているものも含めて。
1. テスト駆動開発ループ
テキトー教師Anthropicが公式に推奨しているパターンで、テスト駆動開発との相性が抜群です。
# ステップ1: まずテストを書かせる
claude --dangerously-skip-permissions -p "このAPIエンドポイントの失敗するテストを書いて"
# ステップ2: テストをコミット
git add . && git commit -m "failing tests"
# ステップ3: テストが全部通るまでClaudeに任せる
claude --dangerously-skip-permissions -p "全テストが通るまで修正を続けて。完了したら教えて"
室谷このパターン、夜に走らせて翌朝確認するという使い方が最高です。gitにコミットしてから走らせるから、朝起きて気に入らなければ
git reset --hardで戻せる。
テキトー教師受講生さんで「1泊でAPIの実装が完成した」って報告してくれた方がいましたね。失敗するテストを夜に定義して、朝見たら全テスト通っていたと。
2. 大規模リファクタリングのバッチ処理
室谷数十ファイルにまたがる変更もYOLOモードの得意領域です。MYUUUでも古いAPIクライアントをリライトするときに使いました。
# 事前にブランチを切ってコミット
git checkout -b refactor/v2-api-migration
git commit -am "before: v1 API client"
# コンテナ内でバッチ実行
docker run --rm \
-v $(pwd):/workspace \
-e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
my-claude-container \
claude --dangerously-skip-permissions -p \
"全ファイルのv1 API呼び出しをv2形式に移行して。src/配下を全部チェックして"
テキトー教師このパターンのポイントは「スコープを明示する」こと。
src/配下とかtests/配下とか、どのディレクトリを対象にするか最初に伝えておく。
室谷そうしないと想定外のファイルまで触られることがあるので・・・
3. マルチリポジトリレポート生成
テキトー教師複数のリポジトリをまたいで情報を集約するレポート生成も、YOLOモードがないとできないパターンです。
室谷例えば「先週の全リポジトリのコミット履歴を読んで、機能別に分類したサマリーを作って」みたいな指示。手作業だと2〜3時間かかる作業が、YOLOモードを使えば数分で終わります。
テキトー教師ログ・コミット履歴・Issueをまたいで分析するような定型業務は、CI/CDスケジュールに組み込んでおくと週次レポートが自動生成できます。これ、経営的にもかなり価値がありますよね。
室谷「AIが仕事をするにはYOLOモードみたいな自律性が必要」という話で、理想と現実のバランスをとる仕組みがclaude code yoloの仕組みだと思っています。
企業・チームでYOLOモードを管理する方法
テキトー教師チームや組織でClaude Codeを展開しているケースも増えてきていますね。その場合、個人でYOLOモードを勝手に使われると困ることもある。
室谷マネージド設定を使えば、組織全体でYOLOモードを無効化できます。
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}
テキトー教師これをITが管理する
managed-settings.jsonに書くと、ユーザーの設定では上書きできなくなります。「絶対にYOLOモードを使わせたくない」組織向けのオプションですね。
室谷逆に「開発環境では使っていいがステージングや本番ではダメ」という使い分けも、環境ごとに異なる設定ファイルを配布することで実現できます。
テキトー教師Claude Code EnterpriseとTeamプランでは、こういった細かい権限管理のサポートが充実しています。大規模展開を考えているならも参考になります。
よくある質問(FAQ)
YOLOモードとauto modeの違いは?
室谷いちばん多い質問ですね。auto modeはShift+Tabで切り替える対話型のモードで、バックグラウンドで安全チェッカーが走ります。
YOLO(bypassPermissions)はそのチェッカーもスキップする完全自律モードです。
YOLO(bypassPermissions)はそのチェッカーもスキップする完全自律モードです。
テキトー教師auto modeは普段の開発に、YOLOはCI/CDや完全自動化シナリオに向いています。セキュリティのレベルが異なるので、目的に合ったモードを選ぶことが大事です。
settings.jsonにdefaultMode: bypassPermissionsと書くのとフラグは同じ?
テキトー教師機能的には同じです。ただ、フラグの場合はそのセッションだけ有効なのに対して、
settings.jsonに書くと毎回そのモードで起動します。
室谷セキュリティ観点から言うと、フラグを毎回打つ方が意識的な選択になるので、個人的にはフラグ形式を推奨しています。
settings.jsonに書くのは、CI/CD環境など完全に制御された環境向けです。セッション途中でYOLOモードに切り替えられる?
テキトー教師現在のバージョンでは、
--dangerously-skip-permissionsフラグは起動時に指定する必要があります。セッション途中でYOLOモードに切り替えることはできないので、再起動が必要です。
室谷これはGitHub Issueで「セッション中に切り替えられるようにしてほしい」という要望も上がっているんですが、現時点では対応されていないですね。
まとめ:YOLOモードは環境ありきで考える
室谷まとめると、
--dangerously-skip-permissionsは「環境の安全性があって初めて使えるモード」です。フラグ自体を恐れる必要はないですが、適切な環境なしに使うのは確かに危険。
テキトー教師受講生さんへのアドバイスとして言うなら、まず
YOLOはその先の話です。
settings.jsonの権限設定を覚えること。次にAccept Editsモードを使いこなすこと。YOLOはその先の話です。
室谷海外のコミュニティでも「Docker + gitチェックポイント + denyルール」がセットというのが共通認識になっています。この3点セットさえ守れば、YOLOモードは生産性を別次元に引き上げる強力なツールになります。
テキトー教師次回はClaude Codeのhooks機能と組み合わせた権限制御を深掘りしていきましょう。あのPreToolUseフックとYOLOモードの組み合わせが、中上級者向けの使い方としていちばん実用的ですし。
室谷そうですね。では今回はここまでです。
