YOLOモード：ガードレールなしのエージェント自律性

生成型AIが2000年代後半に主流になって以来、 AIエージェントは機能と日常的な使用の両面で大きく進歩しました2022 。Stack Overflowの2025開発者調査によると、開発者の84 %がワークフローでAIツールを使用している、または使用する予定であると回答しており、これは1年前の76 %から増加しています。これらのツールがコードの提案から、ファイルの書き込みやコマンドの実行を自律的に行うようになるにつれて、一つの実用的な疑問が生じる。エージェントは、許可を求めることなくどこまで行動できるべきでしょうか？その上限まで回すと、開発者が「YOLOモード」と呼ぶ状態になります。

YOLOモードを有効にする前に、その仕組みを理解しておくことは重要です。なぜなら、その主なリスクは誤解されやすいからです。リスクは、エージェントがどこで活動するかによって決まる。自分のマシン上で、たった1つのコマンドミスが、ファイルの削除、認証情報の漏洩、意図しないネットワーク要求の実行につながる可能性があります。しかし、適切な境界内であれば、開発者はセキュリティを損なうことなく、YOLOモードでエージェントを使用することで、新たなレベルの生産性を実現できる。

YOLOモードとは何ですか？

YOLOモードとは、AIエージェントのすべての行動を自動承認するモードで運用する際の、コミュニティにおける通称である。エージェントが有効になると、ユーザーの承認を待つことなく、ファイルの読み取り、コードの書き込み、シェルコマンドの実行、ツールの呼び出しを行うことができます。Claude Codeでは「--dangerously-skip-permissions」というフラグが使われていますが、他の一般的なエージェントにはそれぞれ独自の同じスイッチがあります。

• Codex CLIには`–full-auto`オプションに加え、サンドボックスを削除する場合に使用できる`–dangerously-bypass-approvals-and-sandbox`オプションがあります。
• Gemini CLI は、`–yolo` オプションを使用するか、セッション中に Ctrl+Y で切り替えます。
• GitHub Copilot CLIには `–allow-all` というオプションがあり、これは `–yolo` という別名でも知られています。
• Cursorは、それをフラグではなく設定の自動実行として公開します。

名前は異なるが、動作は同じだ。プロンプトを削除してエージェントを解放する。 

YOLOモードは最初にCursorに登場し、次にClaude Codeに登場し、2026の時点ではほとんどのコーディングエージェントで標準的な切り替え機能となっています。しかし、人々がYOLOモードとは何かと尋ねるとき、通常はそれを使うべきかどうかを尋ねているのであり、その答えは、エージェントがどこで実行されているかによって全く異なる、ということになります。

開発者がそれを有効にする理由

通常の業務において、慎重なエージェントは常に許可を求める。「このファイルを編集したり、このテストを実行したり、このパッケージをインストールしたり、このツールを呼び出したりできますか？」 

一つの機能に対して、数十ものプロンプトが表示される。こうした度重なる許可要求は、エージェントが暴走するのを防ぐのに役立つものの、承認のたびにコンテキストの切り替えを余儀なくされ、エージェントを使う価値があったはずの作業の流れが途切れてしまう。開発者がYOLOモードを活用する理由には、以下のようなものがあります。

• コンテキストの切り替え：承認作業のたびに開発者は作業の流れから引き離され、精神的な集中力と全体的な生産性が低下します。 
• プロンプト疲労：過剰なクエリ、洗練、承認によって、創造的なコーディングは、面倒なプロンプトの扱いとデバッグのせいで後回しにされてしまう。  
• リスクの低い定型業務：エージェントは、開発者が創造的なコーディングやイノベーションに専念する時間を奪ってしまうような、反復的なタスクを処理することがよくあります。 
• 勢い：エージェントは自由に動き続けられるときに最も役に立つが、絶え間なく指示が送られるとその自由度が損なわれる。

承認プロセスをオフにすれば、こうした摩擦要因はほぼ解消され、エージェントは約束通りのスピードでサービスを提供できるようになります。しかし、エージェントにYOLOモードの自律性を与えることの代償は何だろうか？

YOLOモードはなぜ危険なのか？

プロンプトを削除すると、アクションが実行される前の最後の人的チェックがなくなるため、エージェントが既に抱えているセキュリティリスクが増大します。エージェントがホスト上で直接動作している場合、そのアクションはファイル、環境変数、認証情報、ネットワークなど、マシンの完全な実行権限を持ちます。混乱したり、何らかの不正行為を行ったりしたエージェントは、エージェントの判断とシステムの間に何も遮るものがない場合、甚大な損害を与える可能性があります。

保護されていないホストでは、YOLOモードは次のようなリスクをもたらします。

• 破壊的なコマンド:曖昧な指示や誤った指示によって、rm -rf のようなコマンドが間違ったディレクトリに対して実行され、それを検知するための処理が停止されない。
• 機密情報と認証情報の漏洩:エージェントは環境変数、.ssh を読み取ることができますキー、トークン、および.envファイルを作成し、それを使用または漏洩する。
• プロンプトインジェクション：エージェントは読み取ったものに基づいて動作するため、Webページ、問題、コードコメント、またはドキュメントに隠された命令によってエージェントをリダイレクトすることができ、攻撃者はあなたのマシンにアクセスする必要はありません。
• データ漏洩：誤って、または乗っ取られたエージェントが、機密データをネットワーク経由で外部に送信する。
• 意図しない広範囲な変更：編集や設定変更が、目の前のタスクを超えて他のプロジェクトに影響を及ぼすことがあります。
• ネットワークと横方向のアクセス範囲：エージェントは内部エンドポイントや外部サービスにアクセスしたり、ユーザーの認証情報を使用してコードをプッシュしたり、APIを呼び出したりすることができます。

残念ながら、手動承認を有効にしたままでも、すべてのリスクがなくなるわけではありません。許可申請疲れに陥ると、誤って間違った申請を承認してしまうことが非常に簡単に起こり得る。つまり、安全対策はエージェントが実行される環境内に設けるべきであり、そうすることで誤ったコマンドや疲れた状態でのクリックによる影響範囲を大幅に縮小できる。

解決策は権限を減らすことではなく、境界線を設けることだ

プロンプトが解決策でないなら、何が解決策なのでしょうか？エージェントが越えることのできない境界線。ガードレールは、エージェント外部の何らかの要因によって強制される場合にのみ機能します。エージェントには境界ボックスが必要であり、実行前に制約が設定され、触れることができる範囲が明確に制限されている必要がある。その箱の中では、それは好きなだけ速く自由に動けるはずだ。目標は、ミスによってシステムが損傷したり、機密情報が漏洩したりしないように環境を整えることです。

実際には、これはエージェントをホスト上ではなく、隔離された一時的な環境で実行することを意味します。うまくやれば、エージェントはちゃんとした仕事場を手に入れることができる。パッケージのインストール、サービスの実行、ファイルの編集は可能ですが、認証情報にアクセスしたり、他のプロジェクトにアクセスしたり、ホストにアクセスしたりすることはできません。

ホストカーネルを共有するコンテナとは異なり、microVMはエージェントの周囲にハードウェアレベルの境界を設けるため、エージェントが境界を突破しようとしても分離状態が維持され、しかもユーザーが予想するような速度低下もありません。実行がうまくいかなかった場合は、環境を破壊して最初からやり直します。これがサンドボックスセキュリティの根幹となる考え方であり、エージェントがそもそも隔離を必要とする理由です。

YOLOモードを大規模に展開すると、どのようなものになるのでしょうか？

サンドボックス環境のノートパソコンを使用しているある開発者にとって、YOLOモードは個人的な選択である。チーム全体で、それは政策問題となる。100人もの開発者がそれぞれ独自に権限のスキップを決定する状況は、セキュリティ責任者を夜も眠れなくさせる、統制されていない自律性の問題である。大規模に運用できる理想的な構図とは、安全な経路がデフォルトとなる構図である。各エージェントは、組織レベルで一度設定された、隔離された使い捨て環境内で実行されるため、その設定はすべてのエージェントに適用されます。

これこそが、 AIガバナンスが解決するために構築された問題です。重要なサーフェス、つまりネットワークアクセス、ファイルシステム、エージェントがアクセスできるツール全体にわたってルールを一度定義すれば、開発者のマシンごとに自動的に適用されます。ガバナンスによって、開発者ごとの判断に委ねられていたものが、一貫性があり再現可能な機能へと変化する。明確な境界線を設けることで、組織はリスクを抑制しつつ、エージェントに自律性を与えることができる。境界線が標準化されれば、YOLOモードは誰にとっても高速かつ安全になります。

開発者にとってのメリット

境界線が設定されれば、開発者はすべての工程を監視する必要がなくなり、その恩恵がもたらされる。

• 集中して取り組む：指示を与え、一旦離れてから戻ってくると、クローンされたリポジトリがあり、テストに合格し、プルリクエストがオープンになっている。自分の仕事から邪魔が入ることはありません。
• 長時間の自律実行：エージェントは編集、テストの実行、失敗の読み取り、タスクが完了するまで再試行を繰り返す。これは、プロンプトが大量に表示されると停止してしまうような実行方法である。
• エージェントの並列実行：複数のエージェントをそれぞれ異なるタスクに割り当て、それぞれを専用の使い捨て環境で同時に実行させる。
• 結果を確認すると、あなたの仕事はプルリクエスト、テスト、差分へと進み、そこであなたの判断が最も重要になります。

それが本当の魅力であり、Sandboxがあるからこそ安心して頼れるのだ。

エージェントの自律性を安全に解き放つ

YOLOモードは実は、形を変えた質問だ。エージェントにどの程度の裁量権を与えれば、リスクがスピードを上回ってしまうのか？そう捉えると、答えは行為者自身に関するものではなく、その行為者の環境に関するものになる。エージェントにノートパソコンを自由に操作させてしまうと、たとえ小さなミスでも高くつくことになる。しかし、越えられない境界線を設ければ、ほとんど危険にさらされることなくスピードを得ることができる。

まさにそれがDocker Sandboxesの目的です。各エージェントは、ネットワーク、ファイルシステムへのアクセス、リソース制限を制御できる専用の使い捨てmicroVM上で実行されるため、初日から安全にYOLOモードでエージェントを実行できます。エージェントごとにではなく、一貫してこれらの境界を適用したいチームのために、Docker AI Governanceは開発者が作業するあらゆる場所でルールを設定し、強制します。ボックスを定義する。それから、エージェントが好きなだけ速く動けるようにしてあげましょう。

Dockerサンドボックスを使い始めよう → 

Docker AIガバナンスを探る →

よくある質問