CodexのYOLOモードとは?他Modeとの違いや活用例も解説
CodexのYOLOモードって何ができるの?
普通のモードと何が違うのか気になるな…
Codexを使い始めてから「YOLOモード」という言葉を見聞きする機会が増え、どんな機能か気になっている人は多いですよね。
他モードとの違いやできることなど、詳細を把握してから使うべきかを決めたい人もいるはず。
そこでこの記事では他モードとの違いも交え、CodexにおけるYOLOモードの特徴を解説します。安全に使うコツも紹介するので、ぜひ参考にしてください。
Codexの特徴を詳しく知りたい人は、次の記事を参考にしてください。

- YOLOモードは承認確認とサンドボックスを無効にして、Codexがコマンドを自動実行する
- YOLOモードと同等の設定はconfig.tomlでも指定できる
- コンテナやVMなどで実行環境を隔離して使うことが重要
『ClaudeCodeに興味はあるけど、どうやって使えばいいんだろう…』
そんな方へ、
- ClaudeCodeに作業や仕事を任せる方法
- ClaudeCodeを使いこなすたった1つのコツ
- 業務効率化や収入獲得に活かすClaudeCodeの実演
を、無料のオンラインセミナーで凝縮してお伝えします!
パソコンはもちろん、スマホから気軽に参加OK。この時間が、あなたを変える大きなきっかけになりますよ。
CodexのYOLOモードとは?

CodexのYOLOモードとは、承認確認とサンドボックスによる制限を無効にし、Codexが確認なしでコマンドを実行できるモードです。
通常のCodex CLIでは、サンドボックスや承認ポリシーによって、ファイル編集やコマンド実行などに一定の制限が設けられています。
一方、YOLOモードではこれらの安全機構を解除します。正式には–dangerously-bypass-approvals-and-sandboxというオプションで、–yoloはその短縮形です。つまり、単に「コマンドを自動実行する」だけでなく、実行環境に対する制限そのものを大きく緩和する設定と理解しておきましょう。
「YOLO」は「You Only Live Once(人生は一度きり)」の略です。名前のとおり、細かな確認よりもスピードや自動化を優先する使い方を想定しています。
ここからはYOLOモードと他モードの違いを、3つにまとめて解説します。
Read-onlyモードとの違い
Read-onlyモードは、ファイルを読み取って内容を確認したり、質問に回答したりするための安全性を重視した設定です。ファイルの編集やコマンド実行など、書き込みを伴う操作には制限があります。
YOLOモードとの最大の違いは、操作範囲です。
Read-onlyモードでは、たとえば「このコードのバグを見つけて」と指示すると、コードを調査して問題点を説明するところまでが中心です。一方、YOLOモードでは、原因を特定したうえでファイルを編集し、必要なコマンドを実行するといった一連の作業まで自動化できます。
安全にコードを調査したいときはRead-only、変更を含む作業を自動化したい場合はYOLOというように、目的に応じて使い分けるとよいでしょう。
Autoモードとの違い
Autoモードは、、ワークスペース内でのファイル編集やコマンド実行を自動化しつつ、サンドボックスの範囲を超える操作やネットワークアクセスなどでは確認を求める設定です。
現在のCodex CLIでは、–full-autoがこの使い方のプリセットとして案内されています。
YOLOモードとの大きな違いは、サンドボックスが残るかどうかです。
シェルコマンド実行時の確認有無にあります。Autoモードでは`npm install`や`git push`の実行前に承認を求めます。YOLOモードではシェルコマンドも含め、すべて確認なしで実行します。
たとえば「依存パッケージを追加して」と指示した場合、Autoモードではワークスペース内での編集やコマンド実行を自動で進められます。ただし、サンドボックスの範囲を超える操作などが必要になれば、確認が求められます。一方、YOLOモードではサンドボックス自体を無効にするため、より広い範囲で操作できます。
そのため、普段の開発ではAuto、隔離された環境などで完全自動化したい場合にYOLOと使い分けるのがおすすめです。
Planモードとの違い
Planモードは、実際の変更を行う前に、作業内容や手順を整理するためのモードです。
YOLOモードとの違いは、計画と実行の位置づけにあります。
Planモードでは、たとえば「テストコードを追加して」と指示した場合、象となるファイルや実装方針などを整理してから作業に進みます。これに対してYOLOモードは、必要な操作を判断しながら実際のファイル編集やコマンド実行まで進める使い方です。
変更内容を事前に確認したい場面ではPlan、作業をまとめて自動化したい場合はYOLOが向いています。
なお、Planは承認ポリシーやサンドボックスとは別の観点から作業手順を整理する機能として考えると、モードの違いを理解しやすくなります。
次の表に、4つのモードの特徴をまとめます。
| モード | ファイル読み取り | ファイル編集 | コマンド実行 | 安全機構 |
|---|---|---|---|---|
| Read-only | ○ | × | × | 制限あり |
| Plan | ○ | 原則実行前の計画 | × | 実行前に確認しやすい |
| Auto | ○ | ○(自動) | ○(確認あり) | サンドボックスあり |
| YOLO | ○ | ○(自動) | ○(自動) | サンドボックス・承認を無効化 |
とくに注意したいのが、AutoとYOLOは「自動で作業する」という点では似ていますが、安全機構の有無が大きく異なることです。Autoではworkspace-writeなどのサンドボックスによって操作範囲を制限できますが、YOLOではその制限を解除します。
CodexのPlanモードについて詳しく知りたい人は、次の記事を参考にしてください。

Codex・YOLOモードの活用例

YOLOモードは、確認のやり取りを省いて、複数の作業を一気に進めたい場面で力を発揮します。とくに作業内容がある程度明確で、実行環境を隔離できる場合に適しています。
代表的な活用例を5つ紹介します。
| 活用例 | できること | メリット |
|---|---|---|
| プロトタイプの高速開発 | プロジェクトの雛形作成や依存パッケージの導入をまとめて実行 | 環境構築を素早く進められる |
| テストコードの自動生成・実行 | テストコードの作成から実行、エラー修正まで自動化 | テストと修正のサイクルを高速化できる |
| リファクタリングの一括適用 | 命名規則の統一や不要コードの整理を複数ファイルに適用 | 定型的な修正の手間を減らせる |
| ドキュメントの自動生成 | READMEやAPIドキュメントの作成・書き込みを自動化 | ドキュメント作成を効率化できる |
| 学習用の実験環境 | 新しい言語やフレームワークの導入・動作確認を自動化 | 確認作業を減らして自由に試せる |
このようにYOLOモードは、人間による確認を減らして開発作業を高速化したいケースに向いています。
ただし、YOLOモードでは承認確認だけでなくサンドボックスによる制限も無効になるため、実行する環境には十分注意が必要です。とくに、重要なファイルや認証情報を含む環境での使用は避け、コンテナやVMなど、問題が発生しても影響を限定できる環境で利用することをおすすめします。
本番環境や重要なリポジトリでは、YOLOモードではなく、サンドボックスや承認機能を利用できる設定を選びましょう。
YOLOモードは使うべき?

結論として、YOLOモードは利用する環境を限定し、安全対策を講じたうえで活用すべきです。
YOLOモードの最大のメリットは、確認操作を省いて作業を高速化できることです。通常の設定では、コマンドの実行時に承認が必要になる場合があります。一方、YOLOモードでは承認確認とサンドボックスによる制限を無効にするため、Codexが複数の操作を連続して実行できます。
たとえば、依存パッケージの導入、テストの実行、エラー修正などを繰り返す作業では、確認のたびに作業を止める必要がなくなります。
ただし、YOLOモードは安全機構そのものを無効にするため、リスクも大きくなります。 Codexが生成したコマンドが、そのまま実行される可能性があるためです。意図しないファイル変更や削除、外部サービスへのアクセスなどが発生しても、通常の承認フローによって止めることができません。
そのため、次のように使い分けるとよいでしょう。
| YOLOモードが向いている場面 | YOLOモードを避けるべき場面 |
|---|---|
| 使い捨てのプロトタイプ開発 | 重要なリポジトリでの作業 |
| コンテナやVM内での実験? | |
| 学習目的のコード検証 | 機密情報を含むプロジェクト |
| 何度もコマンドを実行する反復作業 | 重要なデータを扱う環境 |
| 失敗しても容易に環境を再構築できる作業 | 削除や外部アクセスの影響が大きい作業 |
とくに初心者の場合、まずは通常のサンドボックス・承認設定でCodexの動作を理解し、必要性を感じた段階で隔離環境内のYOLOモードを試すのがおすすめです。
YOLOモードは「常に使うべきモード」ではありません。安全性よりも自動化とスピードを優先できる環境で使うモードと考えると、適切に使い分けやすくなります。
Codex・YOLOモードの使い方

YOLOモードを使い始めるまでの流れはシンプルです。ここからはYOLOモードの使い方を、3ステップにまとめて解説します。
1.Codex CLIをインストールする
YOLOモードを使うには、まずCodex CLIのインストールが必要です。
Codex CLIはnpmからインストールできます。Node.jsを利用できる環境を用意したうえで、ターミナルから次のコマンドを実行します。
```
npm install -g @openai/codex
```
インストール後、次のコマンドで正常に導入できたか確認します。
```
codex --version
```
バージョン番号が表示されれば、インストール完了です。
なお、現在のCodex CLIでは、APIキーを環境変数に設定する方法だけでなく、ChatGPTアカウントでログインして利用する方法もあります。利用する認証方式に合わせて設定してください。
Codex CLIについて詳しく知りたい人は、次の記事を参考にしてください。

2.–yoloで起動する
Codex CLIをYOLOモードで起動するには、`–yolo`オプションを付けて実行します。
```
codex --yolo "指示内容"
```
–yoloは–dangerously-bypass-approvals-and-sandboxのエイリアスです。指定すると、承認確認だけでなくサンドボックスによる制限も無効になります。公式リポジトリでも、YOLOモードは安全性に関する注意が必要な設定として扱われています。
たとえば、PythonのWebサーバーを作成する場合は次のように実行できます。
```
codex --yolo "Flaskで Hello World を返すWebサーバーを作成して"
```
Codexは指示に応じて、ファイル作成・編集やコマンドの実行などを自動的に進めます。
なお、–full-autoと–yoloは同じものではありません。–full-autoはworkspace-writeのサンドボックスとon-requestの承認ポリシーを組み合わせたプリセットで、サンドボックス外の操作などでは確認が求められます。一方、–yoloはサンドボックスと承認確認の両方を無効にします。
代表的な設定の違いは次のとおりです。
| モード | コマンド | 特徴 |
|---|---|---|
| Read-only | `codex –read-only “指示内容”` | 読み取り中心で利用 |
| Plan | `codex –plan “指示内容”` | 実行前に作業計画を整理 |
| Auto | `codex –auto “指示内容”` | サンドボックス内の作業を自動化 |
| YOLO(Full Auto) | `codex –yolo “指示内容”` | 承認とサンドボックスを無効化 |
3.config.tomlで初期設定を行う
毎回コマンドラインオプションを指定するのが面倒な場合は、config.tomlでCodex CLIの動作を設定できます。
現在のCodex CLIでは、主に~/.codex/config.tomlに設定を記述します。承認ポリシーとサンドボックスは、それぞれapproval_policyとsandbox_modeで指定します。
たとえば、通常の自動化設定は次のように記述できます。
```toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
```
一方、YOLOモードと同等の設定にする場合は、次のように安全機構を無効にする設定を明示します。
ただし、YOLOモードではそもそもサンドボックスを無効にするため、こうした設定を追加してもYOLOモードの制限を復元することにはなりません。
YOLOモードを常用する設定にするのではなく、必要な作業だけ–yoloを付けて実行するほうが、安全性の面ではおすすめです。
Codexの使い方を詳しく知りたい人は、次の記事を参考にしてください。

Codex・YOLOモードを安全に使う方法

YOLOモードは便利な反面、確認なしでコマンドが実行されるリスクがあります。安全策を組み合わせることで、リスクを最小限に抑えられます。
ここからは安全に使うための方法を、3つにまとめて解説します。
コンテナやVMで隔離する
YOLOモードを使う際は、DockerコンテナやVM(仮想マシン)など、ホスト環境から分離された環境で実行する方法がもっとも効果的です。
YOLOモードは承認確認だけでなくサンドボックスも無効にするため、通常のサンドボックス設定だけで安全性を確保することはできません。そこで、Codexを実行する環境そのものを分離し、万が一問題が起きてもホスト環境への影響を抑えます。
たとえば、コンテナ内に必要なソースコードを配置してYOLOモードを実行すれば、実験終了後にコンテナを破棄する運用が可能です。
ただし、コンテナを使えば必ず安全になるわけではありません。 ホストとのボリューム共有やDockerソケットの公開など、設定によってはホスト環境へ影響を及ぼす可能性があります。不要な共有や権限付与は避けましょう。
不要な権限やネットワークアクセスを与えない
YOLOモードでは、Codexに必要以上の権限やネットワークアクセスを与えないことも重要です。
たとえば、外部サービスとの通信が必要ない作業であれば、ネットワークアクセスを制限します。また、ホスト側の重要なディレクトリや認証情報を実行環境から参照できないようにすることも大切です。
なお、config.tomlで設定できるnetwork_accessなどは、サンドボックス環境におけるネットワークアクセスを制御するための設定です。YOLOモードではサンドボックス自体を無効にするため、YOLOモードと組み合わせれば安全なホワイトリストとして機能するわけではありません。
そのため、YOLOモードを使う場合は、Codex側の設定だけに頼らず、コンテナやVM、OS側の権限制御などを組み合わせて実行環境を制限することが重要です。
本番リポジトリでは使わない
YOLOモードは、本番環境や重要なリポジトリでは使用しないのが鉄則です。
本番リポジトリでYOLOモードを使うと、意図しないファイル変更や削除、設定変更などが確認なしで実行される可能性があります。さらに、外部サービスへのアクセスなどが発生すれば、コード以外にも影響が及ぶおそれがあります。
安全な運用パターンは次のとおりです。
- 実験用ブランチやコピーしたリポジトリでYOLOモードを使う
- コンテナやVM内に作業環境を構築する
- 作業後にgit diffなどで変更内容を確認する
- 問題がないことを確認してから、手動で本番ブランチへ反映する
とくに重要なのは、YOLOモードで作業した結果をそのまま本番環境へ反映しないことです。
本番環境や重要なデータを扱う場合は、サンドボックスや承認機能を利用できる通常の設定を選び、変更内容を確認してから反映しましょう。
YOLOモードは安全機構を解除する強力な設定だからこそ「YOLOモードそのものを安全にする」のではなく、「影響を受けても問題ない環境で実行する」という考え方が重要です。
Codexの安全性・セキュリティについて詳しく知りたい人は、次の記事を参考にしてください。

まとめ
本記事では、Codex CLIのYOLOモードの特徴と使い方を解説しました。
YOLOモードは、承認確認とサンドボックスによる制限を無効にし、Codexによるファイル編集やコマンド実行を自動化できるモードです。Autoモードなどと比べて作業を高速化できる一方、意図しない操作がそのまま実行されるリスクがあります。
まずは使い捨ての実験環境でYOLOモードを試し、基本的な動作を確認するところから始めましょう。慣れてきたら、コンテナ隔離やホワイトリスト設定と組み合わせることで、より安全な運用が実現できます。
