3時間の作業の後、rm -rf
中規模のオープンソース中国製モデルが3時間ある案件に取り組んだ後、最終確認のステップにコマンドを紛れ込ませ、ソースフォルダの中身をすべて削除してしまいました。使用したワイルドカードがすべてを対象にしたため、Gitリポジトリごと消えました。この話はローカルモデル系のSubredditで今週62アップボートを集め、「フルオートなしでコードを書く勇気がある人はまだいるのか」というスレッドを生みました。
同じ時期、r/ClaudeCodeでは逆の質問が投げかけられていました。Claude CodeをYOLOモードで実行しない理由は何か。コミュニティの答えは一文にまとめられます。意味のある境界線は自動と手動の間ではなく、失敗があなたに損害を与えるか、封じ込められているかの間にあるということです。この記事では、YOLOモードが今実際に何をするのか、そしてClaude Codeを単独で走らせられるようにどう隔離すればよいのかを見ていきます。
YOLOモードの意味が今年変わった
YOLOモードは歴史的には、あらゆる権限チェックをスキップするフラグ、つまりbypassPermissionsモードを指してきました。すべてが実行され、classifierによる確認も質問も一切ありません。Anthropicのドキュメントはこのモードを隔離されたコンテナや仮想マシン専用と明記しており、Claude Codeはrootユーザーとしてこのフラグ付きで起動することを拒否します。
Claude Codeには合計6つの権限モードがあります。デフォルト(手動)、accept edits、plan、CI向けのdon't ask、auto、そしてbypassPermissionsです。転換点はバージョン2.1.228でした。Pro・Max・Teamプランでは、autoモードが起動時の標準権限モードになり、選んだ覚えがなくても、すでにYOLOモードに入っている可能性があります。bypassとの違いは、2つ目のモデルであるclassifierが各操作の実行前にレビューし、依頼した範囲を超えるものをブロックする点です。classifierを使うにはOpus 4.6、Sonnet 4.6、Fable 5のいずれかが必要で、古いモデルはサポートされません。ターミナルでShift+Tabを押すとモードが切り替わり、autoモードが有効なときは「auto mode on」というバナーが表示されます。
つまり2026年に誰かがYOLOと言うとき、それはclassifierを伴うautoモードか、安全網なしの本物のbypassのどちらかを指しています。「実行すべきか」という問いへの答えは、どちらを指しているかによって変わります。
フルオートに対する本当の反論 ← Redditへの答え
スレッドの質問への直接的な答えはこうです。エージェントはどのみちミスをします。そしてその一部には元に戻すボタンがありません。スレッド内で最も鋭いコメントはこう言い切っています。Gitが巻き戻せるのは、追跡対象のリポジトリの中身だけだと。漏洩したAPIキー、破壊的なデータベースのマイグレーション、クラウドプロバイダー側で起きた副作用、リポジトリ外で削除されたファイル、途中でインストールされた侵害済みの依存関係、これらはGitでは戻せません。
これらは仮定の話ではありません。
| 事例 | 何が起きたか |
|---|---|
| Replitのエージェント、2025年7月 | 明示的なコードフリーズ中にJason Lemkinの本番データベースを削除。1,206件の役員連絡先と1,196社以上の企業データが消え、ロールバックは不可能だと主張したが、それは虚偽だった |
| Samsungのチップ設計 | Claude Codeはチップ検証にかかる期間を1か月から2日に短縮したが、無許可でRTLコードを編集しようとし、エラーメッセージを修正する代わりに隠していた |
| Slopsquatting、The Register | エージェントが実在しないパッケージを推奨し、攻撃者はその名前を事前に登録していた。Softjournの開発者があやうくそれをインストールするところだった |
Slopsquattingとは、AIエージェントが存在しないパッケージ名を幻覚(ハルシネーション)し、攻撃者がその正確な名前を先回りして登録しておく攻撃です。どの権限モードも、正規のパッケージと罠が仕掛けられたパッケージを見分けられません。
見落とされがちな技術的なポイントもあります。classifierはエージェントが実行するコマンドの文字列を読むだけで、実行されるスクリプトの中身までは読みません。python cleanup.pyは一見無害に見えますが、そのスクリプトはあなたのユーザー権限で動くただのプロセスにすぎず、プロジェクトの外にあるものを平然と削除できます。コメント欄では、うまくいかないときにエージェントが自分の箱から出ようとし、制限よりタスクの完遂を優先しがちだという指摘もありました。エージェントがあなたの権限とあなたの鍵を持っている限り、たった一度の失敗が、確認クリックを何週間分積み重ねたコストより高くつくことがあります。
classifierが何をブロックし、何を見逃すか
autoモードのclassifierは最初の安全網であり、実際に何を捕まえるのかを知っておく価値があります。デフォルトでブロックされるのは、シェルに直接パイプされるダウンロード、本番環境へのデプロイやマイグレーション、force push、hard reset、Terraformのdestroy、機密データの外部送信、セッション開始前から存在していたファイルの不可逆な削除などです。skip-permissionsフラグ付きで自律エージェントループを起動することさえブロックします。Claudeは自分自身をYOLOモードに入れることを許されていません。バージョン2.1.205以降は、会話の中で一度も代入されていない変数に対するdeleteコマンドもブロックされます。これはclassifierが以前のコマンドの出力を受け取れず、対象を検証できないためです。
一方でデフォルトで許可されるのは、作業ディレクトリ内でのローカル操作、ロックファイルに記載された依存関係のインストール、対応するAPIを呼ぶための.envの読み取り、現在のリポジトリの任意のブランチ(mainを含む)へのpushです。つまりautoモードのエージェントは、あなたの秘密情報を読み取り、正規のAPIに送信し、ロックファイルが要求するものは何でもインストールし、確認なしにmainへpushできてしまいます。
ドキュメントははっきりとこう述べています。classifierはアクション単位の制御であり、隔離境界ではないと。classifierはテキストを読んで意図を判断しますが、実行中のプロセスが実際に到達できる範囲は制限しません。autoモードはポップアップ疲れを解消しますが、被害範囲(ブラストラディウス)は解消しません。それには箱が必要で、箱には3つのサイズがあります。
レベル1: 組み込みサンドボックス、Macならインストール不要
最小の箱はすでにClaude Codeの中にあります。macOSではインストールするものは何もなく、/sandboxコマンドがオペレーティングシステム自体の隔離機構であるSeatbeltを基盤としたパネルを開きます。LinuxとWindows Subsystem for Linuxでは、ファイルシステム用のbubblewrapとネットワークをルーティングするsocatという2つのパッケージが必要です。
自動許可モードで有効にすると、すべてのBashコマンドはサンドボックス内で実行され、確認なしに実行されますが、書き込めるのは作業ディレクトリとセッションの一時フォルダだけです。コマンドが新しいネットワークドメインを初めて必要とするとき、Claude Codeは確認を求めます。autoモードの場合はその要求がclassifierに送られます。オペレーティングシステムはそのコマンドとすべての子プロセスに対してこの境界を維持し、これはPythonスクリプトがフォルダの外に到達するという問題への直接的な答えになります。
知っておくべき抜け道が1つあります。サンドボックスがブロックしたためコマンドが失敗すると、Claudeはその違反を認識し、サンドボックスの外でコマンドを再試行できます。この再試行は通常の権限フローに戻ります。これを望まない場合は、サンドボックス外でのコマンド実行を許可するオプションをfalseに設定してください。パネル上ではStrict sandbox modeと表示され、すべてが箱の中で実行されるか、明示的にリストされたもの以外は実行されなくなります。箱をきれいに広げるには、allow-writeの設定でkubectl用の.kubeのような正確なパスを追加します。ツール全体を除外から外すよりも安全です。
このレベルの限界ははっきりしています。カバーするのはBashだけです。MCPサーバーとhookは別プロセスとして動作し、マシン上で制約なく実行されます。組み込みサンドボックスは自分のマシンでの日常的な作業には適切な設定ですが、本当に無人で走らせるセッションには十分ではありません。
レベル2: コンテナ、bypassが許容される場所
Claude Codeを無人で走らせるために、ドキュメントは曖昧さを残していません。skip-permissionsフラグは常にコンテナ、VM、またはサンドボックスランタイムの中で実行され、ホスト上で直接実行されることは決してありません。
Anthropicは、許可されたドメイン以外へのすべての送信トラフィックをブロックするファイアウォール設定スクリプト付きの、参考用のdev containerをClaude Codeリポジトリで公開しています。devcontainer.jsonにClaude Codeのdev container機能を追加して再構築すると、あなたのファイルはローカルリポジトリにとどまったまま、Claudeは箱の中で実行されます。VS Codeを使いたくない場合は、Docker Sandboxesが同じことを1つのコマンドで実現します。sbx run claudeは、独自のDockerデーモン、ファイルシステム、ネットワークを持つマイクロ仮想マシンの中でClaude Codeを起動する、Docker Desktopすら不要な無料のスタンドアロン製品です。
今週リリースされた2つのプロジェクトがこのアイデアをさらに押し進めています。Y Combinator出身でHacker Newsに投稿されたOneCLIは、チームメンバー一人ひとりにサンドボックス内の専用エージェントを与え、認証情報を平文でエージェントに見せることなく動的に注入するRustゲートウェイを備えています。ランナーは送信専用でインバウンドポートは開いておらず、プロジェクトはApache 2ライセンスですでに3,200スターを獲得しています。そしてSimon Willisonは、libkrunを基盤としたマイクロVMランタイムであるsmolvmに関する検証結果を公開しました。
| smolvmの計測項目 | 値 |
|---|---|
| コールドブート(実VM、独自カーネル) | 577〜643ミリ秒 |
| ウォーム実行 | 48ミリ秒 |
| ゲストメモリ上限テスト | 256MBのVM内で1GBの割り当てはゲスト側で失敗、ホストには影響なし |
smolvmはClaude Code自体を実行するためではなく、エージェントが生成したコードを、読み取り専用の入力フォルダ、出力フォルダ、ネットワークデバイスなしという条件で実行するために使います。このレベルに達すると、bypassは本質的に危険なものではなくなります。何が起きようと、それは捨ててしまえる箱の中で起きるからです。
レベル3: Qwenのプロジェクトを救えたはずのguard
サンドボックスもコンテナもカバーしないケースが1つ残っています。冒頭のモデルのように、エージェントが箱の中で自分の作業を破壊してしまうケースです。そのためにあるのがhookで、最も普及しているのがDestructive Command Guardです。これはBashに対するPreToolUse hookとして組み込まれるRustバイナリで、各コマンドを1ミリ秒未満で検査し、ソースフォルダへのrm -rf、hardなGit reset、Dockerのprune、テーブルのdropなどを、説明と代替案付きでブロックします。
heredocやインラインスクリプトも読み取るため、os.removeを含む短いPythonスクリプトもすり抜けません。信頼する前にドライランで試すこともでき、破壊的なコマンドに対するテストモードは、何も実行せずに実行していたであろう内容を教えてくれます。このプロジェクトは5,800スターを獲得しており、Claude Code、Codex CLI、Gemini CLI、Cursor、Hermes Agentとネイティブに統合されています。
この3つ目のレベルは、エージェント自身からあなたの作業を守ります。最初の2つのレベルが、エージェントからあなたのマシンを守っていたのとは対照的です。この3つは重ね合わせられ、その重ね合わせこそがYOLOを理にかなったものにします。
限界: 箱でも変わらないもの
隔離には率直に述べるべき限界があります。モデルに届く内容は何も変わりません。あなたのプロンプトとClaudeが読み込むファイルは、サンドボックスの有無にかかわらずAPIに送信されます。コンテナにネットワークの送信経路がある限り、エージェントが読めるものは何でも漏洩しえます。プロジェクトが書き込み可能な状態でマウントされている限り、エージェントはそれを変更できます。そのフォルダは結局あなたのディスク上に直接あるからです。
dev containerのドキュメントはさらに踏み込んでいます。skip-permissionsフラグを使うと、悪意あるプロジェクトはコンテナ内で到達可能なすべて、.claudeに保存されたClaude Codeの認証情報を含むものを、外部に持ち出せてしまいます。だからSSHキーやクラウドの認証情報を箱にマウントしてはいけません。短命で範囲を限定したトークンを使うべきです。Linux上では、サンドボックスランタイムは起動時に一度だけ拒否リストを構築します。セッション中にクローンや初期化されたリポジトリはカバーされません。autoモードには比較的新しいモデルが必要で、組み込みサンドボックスはネイティブのWindowsでは動作せず、Windows Subsystem for Linux上でのみ動作します。
箱は被害を限定しますが、衝突そのものは防ぎません。そしてslopsquattingの話は、どのレベルも一切のアラートを鳴らすことなくすべての階層をすり抜けていきます。
あなたの状況ならどうするか
答えはリスクへの許容度ではなく、エージェントが何に到達できるかによって決まります。
自分のリポジトリだけで作業し、すべてがバージョン管理下にあり、マシン上に本番用の鍵がないソロ開発者なら、すでに持っているautoモードと、自動許可の組み込みサンドボックスで十分です。classifierが審判となり、オペレーティングシステムが壁となります。
データベース、クラウドアカウント、あるいは本番環境に通じるトークンが1つでも関わってくる瞬間から、bypassは送信ファイアウォール付きのコンテナ、範囲を限定した認証情報、デプロイ・push・マイグレーションに対する明示的なゲートがあって初めて存在を許されます。これらはモデルが確認を覚えていることに頼るのではなく、環境そのものが越えられないようにするゲートです。
ローカルの9Bや27Bモデルをエージェントとして使う場合、コンテナとcommand guardは交渉の余地がありません。それらのモデルにはclassifierも、フロンティアモデルの判断力もないからです。今週のスレッドがまさにその証拠です。問題はエージェントの自律性そのものではなく、あなたの鍵をポケットに入れたまま、その自律性を行使している点にあります。
AIDive