ChatGPTデスクトップアプリ
Codex統合後の設定・運用ガイド
最終確認日：2026年7月13日
主な対象環境：Windows／WSL2
概要
従来のCodexアプリはChatGPTデスクトップアプリへ統合され、現在は一つのアプリ内で次の用途を切り替えて利用できる。
- Chat：通常の対話
- Work：調査や成果物作成
- Codex：ローカルリポジトリでの開発作業
Windows版では、Windowsネイティブ環境とWSL2環境の両方に対応し、Worktree、Git操作、統合ターミナル、Computer Use、リモート接続などの機能も設定できる。
設定画面は次のいずれかから開く。
アカウント
→ 設定
または、Windowsでは次のショートカットを使用する。
Ctrl + ,
先に推奨設定
一般的な開発用途では、次の設定を基準にする。
| 項目 | 推奨設定 |
|---|---|
| 権限 | 自動レビュー |
| フルアクセス | オフ |
| エージェント環境 | プロジェクトの実体に合わせる |
| 統合ターミナル | エージェント環境と合わせる |
| コンテキスト使用量 | 必要に応じて表示 |
| Max／Ultra | 通常はモデルピッカーから非表示 |
| Fast Mode | 通常はオフ |
| Computer Use | 必要なタスクだけ許可 |
| リモート接続 | 利用時のみ有効 |
| Force Push | 通常はオフ |
| 下書きPR | オン |
| Worktree自動削除 | オン |
| Worktree保持数 | 10～15程度 |
| ペット | オフ |
1. 権限
ChatGPTがローカル環境でどこまで操作できるかを決める重要な設定。
現在は、概ね次の3段階に分かれている。
デフォルトの権限
ChatGPTは、現在開いているワークスペース内のファイルを読み取り、編集できる。
ワークスペース外のファイル、ネットワークアクセス、追加権限が必要な処理については、その都度ユーザーへ承認を求める。
向いている用途
- 機密性の高いリポジトリ
- 本番環境に関係する作業
- 認証情報を扱うプロジェクト
- エージェントの操作を毎回確認したい場合
安全性は高いが、長時間タスクでは承認待ちによって処理が止まりやすい。
自動レビュー
ChatGPTはワークスペース内を読み書きでき、追加アクセスが必要になった場合は、別のレビュー処理によって権限要求を自動判定する。
これは、単純にすべての権限を与える設定ではない。ファイルシステムやネットワークの制限は維持されたまま、人間が行っていた承認判断をレビューエージェントへ置き換える仕組みである。
ただし、自動レビューは誤る可能性があり、セキュリティを完全に保証するものではない。Computer Useによる新しいアプリやドメインへのアクセスなど、一部の確認は引き続きユーザーへ直接表示される。
推奨
通常の開発作業では、自動レビューを標準設定にすると、作業の停止を減らしながら一定の制限を維持できる。
ただし、次の作業ではデフォルト権限へ戻すことも検討する。
- 本番データを扱う
- 決済や認証を変更する
- 秘密鍵やAPIキーが存在する
- 削除や移行を大量に行う
- 信頼できないコードを実行する
フルアクセス
フルアクセスでは、ChatGPTが承認なしでコンピューター上の広範囲なファイルへアクセスし、ネットワークを使うコマンドも実行できる。
公式設定上は、ファイルシステムとネットワークのサンドボックス制限を外し、承認を求めずに処理する構成に相当する。
推奨
基本的にはオフでよい。
フルアクセスが必要になる場面は限定的であり、ワークスペース権限や個別の追加承認で対応できる場合は、そちらを優先する。
想定されるリスク：
- 意図しないファイルの変更や削除
- 認証情報の読み取り
- 外部ネットワークへの送信
- 別プロジェクトへの影響
- 悪意ある依存パッケージやプロンプトの実行
フルアクセスを使う場合は、専用の開発PC、仮想環境、コンテナなど、影響範囲を隔離した環境が望ましい。
2. エージェントの環境
Windowsでは、エージェントを実行する環境として主に次を選べる。
- Windowsネイティブ
- Windows Subsystem for Linux（WSL2）
Windowsネイティブ
PowerShellやWindows向けツールを中心に使用する。
向いている例：
- プロジェクトが
C:\以下にある - PowerShellスクリプトを利用する
- Windows専用SDKやアプリを扱う
- Visual Studio系のビルドが中心
- Windowsのファイル権限やパスをそのまま検証したい
WSL2
エージェントをLinux環境内で実行する。
向いている例：
- プロジェクトが
/home/...以下にある - Linux向けのDocker、Python、Node.jsを使う
- Bashスクリプトが中心
- 本番サーバーがLinux
- Linux固有の権限、パス、シンボリックリンクを扱う
Linux向けのツールチェーンを使う場合や、リポジトリがWSL内に存在する場合はWSL2が適している。
WSLで使用するリポジトリは、/mnt/c/...ではなく/home/...以下へ置く方が、ファイルI/O、権限、シンボリックリンクなどの問題を避けやすい。WSL1は現在のCodexではサポート対象外。
プロジェクトごとの推奨
/home/wonder/PythonProjects/tech_blog
このようなパスにあるプロジェクトは、WSL環境を選ぶのが自然。
C:\Users\wonder\Projects\example
このようなパスにあるプロジェクトは、Windowsネイティブ環境が適している。
WindowsとWSLの相互呼び出し
PowerShellからwslコマンドを呼び出したり、WSLからpowershell.exeを実行したりすること自体は可能。
ただし、エージェント環境の設定が異なっていても、Codexが常に自動的に吸収してくれるとは限らない。
環境が異なると、次の違いが発生する。
- ファイルパス
- シェル構文
- 環境変数
- 実行権限
- 改行コード
- インストール済みツール
- PythonやNode.jsの実体
- Dockerの接続先
- サンドボックスの境界
したがって、プロジェクトの実体が存在する環境へ合わせることを基本とする。
3. 統合ターミナルのシェル
統合ターミナルで使用するシェルを選択する設定。
推奨は、エージェント環境と同じシェルを選ぶこと。
| エージェント環境 | 推奨シェル |
|---|---|
| Windowsネイティブ | PowerShell |
| WSL2 | WSL／Bash |
統合ターミナルは現在のプロジェクトやWorktreeを基準に開かれ、ChatGPTはターミナルの出力を作業コンテキストとして利用できる。
環境とシェルを一致させることで、次の問題を減らせる。
- パス変換の失敗
- PowerShellとBashの構文差
- 依存パッケージの二重インストール
- 異なるPythonやNode.jsの実行
- 権限や実行ビットの差
4. コンテキストウィンドウの使用量を表示
この数値は、ChatGPTプランのUsageやCodexクレジットとは別の指標。
そのタスク内でモデルへ渡されている、概ね次の情報量を示す。
- 会話履歴
- 指示
- 読み込んだファイル
- コマンド出力
- ツール実行結果
- モデルの作業履歴
コンテキストが長くなると、古い情報は圧縮される場合がある。これは一般にcompactionと呼ばれる仕組みで、長い作業をコンテキスト上限内で続けるために使われる。
表示する意味
自動圧縮が行われるため、常に数値を監視する必要はない。
ただし、次の兆候を判断する補助にはなる。
- 最初の指示を忘れ始めた
- 同じ調査を繰り返す
- 過去の判断と矛盾する
- 読み込んだファイルが多すぎる
- タスクを分割した方がよい
推奨
- 普段は非表示でも問題ない
- 長時間の大規模タスクでは表示してもよい
- 数値が大きいだけで、プランのUsageを大量消費しているとは限らない
- 品質が落ちた場合は、新しいタスクへ要点を引き継ぐことも検討する
5. 利用可能な推論レベル
モデルピッカーへ表示する推論レベルを選択する設定。
モデルごとに利用可能なレベルは異なる。
Max／Ultraの表示
現在の設定画面では、MaxやUltraをモデルピッカーの最上位候補として表示するか選択できる。
これはモデルそのものを完全に無効化するというより、通常のモデル選択画面を整理し、誤って高負荷設定を選ぶことを防ぐ目的で使える。
推奨
MaxとUltraは通常オフでよい。
日常的な実装では、Terra MediumまたはSol Medium／Highで十分な場合が多い。
MaxとUltraは次の場合だけ有効化する。
- Extra Highでも解決しない
- 失敗コストが非常に高い
- 大規模な調査を並列化できる
- Usage増加を許容できる
- 使用理由を明確に説明できる
6. Fast Mode
Fast Modeは、対応モデルの処理速度を上げる代わりに、通常より高いレートでCodexクレジットを消費する設定。
CLIでは次のコマンドで操作できる。
/fast on
/fast off
/fast status
推奨
通常はオフでよい。
有効にする価値がある場面：
- 緊急の障害対応
- 短時間でレビュー結果が必要
- Usageより待ち時間を優先する
- 小さなタスクを連続処理する
デスクトップアプリのモデルピッカーからFast Mode自体を完全に非表示にする設定は、現時点では見つからない。
誤操作を避けたい場合は、通常モードを標準にし、必要なタスクだけ明示的にFastへ切り替える。
7. Computer Use
ChatGPTが、ブラウザやデスクトップアプリの画面を認識し、マウスやキーボードに相当する操作を行う機能。
想定用途
- Webサイトの表示確認
- UIバグの再現
- ブラウザ上の管理画面操作
- デスクトップアプリの設定変更
- CLIやAPIが存在しないアプリの操作
- 実際の画面を見ながらのテスト
専用連携を優先する
次のような専用ツールが使える場合は、Computer Useより専用連携を優先する。
- GitHub連携
- Gmail連携
- Google Calendar連携
- MCPサーバー
- CLI
- API
構造化された連携の方が、画面上の座標や見た目に依存せず、結果を検証しやすい。
Computer Useは、専用のAPIやプラグインでは操作できない視覚的な作業に適している。アプリごとのアクセス許可は、ファイルやシェルのサンドボックス権限とは別に管理される。
推奨
- 初期状態では必要なアプリだけ許可
- 「常に許可」は慎重に設定
- 削除、送信、購入、公開などは人間が最終確認
- 管理者画面や機密情報のあるアプリでは使用範囲を限定
- Windowsでは操作対象をアクティブなデスクトップへ表示しておく
8. 接続とリモートアクセス
スマートフォンや別のデバイスから、ChatGPTデスクトップアプリが動作しているPC上のCodexタスクを操作する機能。
スマートフォンは操作端末となり、実際のファイル、コマンド、認証情報、プラグイン、Computer Useは接続先PC側で使用される。
設定画面では、次のような項目を管理できる。
- このPCを操作できるデバイス
- 接続を許可
- 接続済みスマートフォン
- 最終接続日時
- 電源接続中にPCをスリープさせない
リモート利用時の条件
- PCのChatGPTアプリが起動している
- PCがオンライン
- PCがスリープしていない
- 同じChatGPTアカウントまたは対象ワークスペースを使用
- Computer UseではWindowsセッションがロックされていない
- 操作対象アプリが表示されている
推奨
- リモート操作を使わない期間は接続をオフ
- 使用しなくなった端末は削除
- 外出先から利用する場合はPCを電源へ接続
- 「スリープさせない」はリモート利用時のみ有効化
- PC自体のログイン、ディスク暗号化、画面ロックも適切に設定する
スマートフォンからの接続設定は、この項目で管理する。
9. Git設定
ブランチのプレフィックス
ChatGPTがブランチを作成するときの接頭辞。
チーム運用として、次の設定は分かりやすい。
feature/
生成例：
feature/add-duration-display
feature/fix-login-error
feature/update-documentation
チームでfix/、chore/、docs/などを使い分けるルールがある場合は、固定のfeature/より、タスク種別ごとに指示する方法もある。
常にプッシュを強制
有効にすると、ChatGPTからのプッシュで--force-with-leaseが使われる。
--force-with-leaseは通常の強制プッシュより安全性を考慮した動作だが、リモートブランチの履歴を書き換える操作である。
推奨
通常はオフ。
有効化を検討できるのは、次の条件を満たす場合。
- ChatGPT専用のFeatureブランチ
- 他の開発者が同じブランチを使わない
- Rebaseやコミット修正がチームルール
- 履歴を書き換えることを理解している
developやmainへForce Pushしないことは、GitHub側のブランチ保護でも強制する。
下書きのプルリクエストを作成
推奨
オン。
ChatGPTがPRを作成しても、すぐにマージ可能な状態にせず、人間による確認を挟める。
ただし、Draft PRだけで誤マージを完全に防げるわけではない。
GitHub側でも次を設定する。
- ブランチ保護
- 必須レビュー
- 必須CI
- 直接プッシュ禁止
- 会話やレビュー指摘の解決を必須化
レビュー配信
レビューの実行方法には、主に次の選択肢がある。
現在のタスクでレビュー
現在の会話内で/reviewを開始する。
向いている用途：
- 実装直後の簡易確認
- 素早い修正サイクル
- 現在の文脈を維持したい場合
別のレビュータスク
実装タスクとは別にレビューを起動する。
向いている用途：
- 実装者とは独立した視点がほしい
- 大きな変更
- 正式なPRレビュー
- 実装時の思い込みを引き継ぎたくない
/reviewは差分を読み取り、通常はワーキングツリーを直接変更せずに問題点を報告する。デスクトップアプリのレビュー画面では、未ステージ、ステージ済み、コミット、ブランチなどの差分を確認できる。
推奨
- 軽い自己レビュー：現在のタスク
- PR提出前の正式レビュー：別タスク
10. コミット指示
チームのコミットルールが決まっている場合、ここへの記載は重要。
設定例：
コミットメッセージは日本語で記述してください。
変更内容に応じて、先頭に次のような簡潔なプレフィックスを付けてください。
add:
update:
delete:
fix:
chore:
docs:
refactor:
test:
1コミットには、原則として1つの論理的な変更だけを含めてください。
生成例：
add: 動画カードに再生時間表示を追加
fix: ログイン失敗時のリダイレクトを修正
update: GPT-Liveの仕様メモを更新
chore: 開発用依存パッケージを更新
11. プルリクエストの指示
設定例：
PRタイトルは次の形式で記述してください。
feature/branch-name -> develop :: PRタイトル
Descriptionには、少なくとも次を含めてください。
- 変更の概要
- 変更理由
- 主な実装内容
- 確認方法
- 実行したテスト
- 影響範囲
- 対象ファイルへのGitHubリンク
- 未対応事項または注意事項
そのほかの内容は、タスクの状況と追加指示に従ってください。
生成例：
feature/add-duration-display -> develop :: 動画カードに再生時間を表示
推奨するブランチ運用
Feature
↓ Pull Request／Squash Merge
Develop
↓ リリース確認
Main
FeatureからDevelopへのマージをSquashにすると、試行錯誤中の細かなコミットを一つにまとめられ、Developの履歴を読みやすくできる。
ただし、このフローがすべてのチームに最適とは限らない。継続的デリバリーを重視する小規模チームでは、Developを置かずFeatureからMainへPRを出すGitHub Flowなども選択肢になる。
このチームでFeature→Develop→Mainを採用する場合は、次を基本とする。
- MainとDevelopへ直接コミットしない
- Featureブランチで作業する
- PRはDraftで作成する
- Feature→DevelopはSquash Merge
- 人間のレビューとCIを通す
- DevelopからMainへの昇格はリリース単位で行う
12. ローカル環境
Codexデスクトップアプリでは、プロジェクトごとにローカル環境設定を保存できる。
環境設定には、次を登録できる。
- 名前
- プロジェクトパス
- セットアップスクリプト
- クリーンアップスクリプト
- ツールバーアクション
ローカル環境設定はプロジェクトの.codexディレクトリで管理でき、必要に応じてリポジトリへコミットし、チームで共有できる。
設定例
名前:
tech_blog
プロジェクト:
/home/wonder/PythonProjects/tech_blog
このパスの場合は、エージェント環境をWSLにする。
セットアップスクリプト
新しいWorktreeが作成されたとき、プロジェクトルートで実行される。
例：
cd "$CODEX_WORKTREE_PATH"
pip install -r requirements.txt
npm install
./run/setup.sh
推奨事項
セットアップスクリプトは次を満たすようにする。
- 複数回実行しても壊れない
- 必要な依存関係だけを導入する
- APIキーやパスワードを直接書かない
- 失敗した場合は明確に停止する
- プロジェクトのロックファイルを利用する
- グローバル環境を不用意に変更しない
- 実行時間が極端に長くならない
Node.jsでpackage-lock.jsonが管理されている場合は、再現性の観点からnpm installではなくnpm ciを使う選択肢もある。
Pythonでは、システム全体へ直接インストールせず、プロジェクト用の仮想環境を使用する方が安全。
クリーンアップスクリプト
Worktreeを削除する前に実行される。
例：
docker compose down --remove-orphans
rm -rf .cache/tmp
想定用途：
- Dockerコンテナの停止
- 使用中ポートの解放
- 一時ファイルの削除
- Worktree固有キャッシュの削除
- バックグラウンドプロセスの終了
別のWorktreeや通常開発環境のコンテナまで停止しないよう、Docker Composeのプロジェクト名や対象ディレクトリを明確にする。
アクション
任意のコマンドを登録し、ローカルツールバーから実行できる。
登録候補：
- 開発サーバー起動
- テスト実行
- Lint
- Formatter
- 型チェック
- ビルド
- Docker起動
- DBマイグレーション
/review
アクションは任意のコマンドを実行できるため、通常のソースコードと同様に内容をレビューする。
TOML保存時の注意
現在の設定画面には、保存時に対象のTOMLファイル全体が書き換えられ、次が保持されない可能性があるという警告が表示される。
- コメント
- 独自の書式
- 設定画面が認識しないフィールド
推奨
設定画面から保存する前に、対象TOMLをGitへコミットするかバックアップする。
手動で追加した未知の設定がある場合は、保存後に差分を必ず確認する。
13. Worktree
Git Worktreeは、同じリポジトリに対して複数の独立した作業ディレクトリを作る仕組み。
Codexでは、複数のタスクを並行して実行するときに利用される。
例：
元のリポジトリ
├─ feature/login
├─ feature/api
└─ feature/documentation
それぞれが別のディレクトリを使用するため、複数タスクが同じファイルを同時に書き換える問題を減らせる。
Worktreeルート
ChatGPTが管理対象Worktreeを作成する場所。
特別な理由がなければ、空欄のままデフォルトを使ってよい。
独自設定が必要な例：
- 容量の大きい別ドライブへ置く
- ウイルススキャン対象を分ける
- 高速なSSDへ置く
- WSL内の特定ディレクトリへ統一する
WSLプロジェクトの場合は、WorktreeもWSLのLinuxファイルシステム内へ置く方がよい。
古いWorktreeを自動的に削除する
推奨
オン。
Codexは削除前にスナップショットを作成し、復元できるようにする。作業中、固定済み、永続化されたWorktreeなどは自動削除の対象から除外される。
ただし、重要な変更はスナップショットだけに依存せず、コミットまたはPRとして保存する。
自動削除の制限値
デフォルト：
15
一般的には10～15程度で問題ない。
次のようなプロジェクトでは5～10へ下げることも検討する。
-
node_modulesが大きい - Python仮想環境をWorktreeごとに作る
- Dockerイメージやキャッシュが増える
- リポジトリ自体が大きい
- ストレージ容量が少ない
Worktree活用例
タスクA：新機能実装
タスクB：既存PRレビュー
タスクC：バグ調査
これらを別Worktreeで同時に進める。
セットアップスクリプトを整備しておくと、新しいWorktreeごとに依存関係や初期設定を自動構築できる。
14. ペット
ChatGPTデスクトップアプリでは、エージェントの状態を示すアニメーションキャラクターを表示できる。
ペットはタスクの実行結果には影響せず、ウィンドウ上に表示される視覚的な補助機能。
実利用上の注意
利用環境によっては、ペットを表示すると次のような負荷を感じる場合がある。
- マウスカーソルがカクつく
- デスクトップ描画が重くなる
- GPU使用率が上がる
- ウィンドウ操作の反応が落ちる
これは環境依存の利用時メモ。
推奨
実用性を優先する場合はオフ。
ペットはCodexの能力やタスク完了には影響しないため、描画負荷や操作遅延を感じる場合に表示する利点は少ない。
15. チーム向け推奨設定
通常の開発者
権限：
自動レビュー
フルアクセス：
オフ
エージェント環境：
プロジェクトが /home/... → WSL
プロジェクトが C:\... → Windowsネイティブ
統合ターミナル：
WSL環境 → WSL
Windows環境 → PowerShell
コンテキスト使用量：
任意
Max／Ultra：
非表示
Fast Mode：
オフ
Computer Use：
必要なタスクだけ許可
リモート接続：
利用時のみオン
ブランチプレフィックス：
feature/
Force Push：
オフ
Draft PR：
オン
レビュー：
正式レビューは別タスク
Worktree自動削除：
オン
Worktree保持数：
10～15
ペット：
オフ
機密性の高いプロジェクト
権限：
デフォルト権限／都度承認
フルアクセス：
オフ
自動レビュー：
必要性を検討
Computer Use：
原則オフ
リモート接続：
オフ
外部ネットワーク：
必要なものだけ承認
Git操作：
Draft PRと必須レビュー
重要な変更：
別タスクでレビュー
16. 最終チェックリスト
Codexを使い始める前に確認する。
- プロジェクトの場所とエージェント環境が一致している
- 統合ターミナルのシェルが環境と一致している
- フルアクセスが不用意に有効になっていない
- Force Pushが不用意に有効になっていない
- Draft PRが有効になっている
- コミットとPRのチームルールが登録されている
- Main／Developのブランチ保護が設定されている
- セットアップスクリプトを複数回実行しても壊れない
- クリーンアップが別環境へ影響しない
- TOML保存前に差分を退避している
- Worktreeの自動削除が有効
- リモート接続端末に不要なデバイスが残っていない
- Computer Useの権限を必要以上に許可していない
- Max／Ultra／Fastを誤って常用しない
- ペット表示による描画負荷がある場合はオフにしている
公式参考URL
- Codexアプリ：https://learn.chatgpt.com/codex/app
- Codex設定：https://learn.chatgpt.com/codex/reference/settings
- サンドボックス：https://learn.chatgpt.com/codex/sandboxing
- 自動レビュー：https://learn.chatgpt.com/codex/sandboxing/auto-review
- Windows／WSL：https://learn.chatgpt.com/codex/windows/wsl
- 統合ターミナル：https://learn.chatgpt.com/codex/integrated-terminal
- Fast Mode：https://learn.chatgpt.com/codex/agent-configuration/speed
- Computer Use：https://learn.chatgpt.com/codex/computer-use
- リモート接続：https://learn.chatgpt.com/codex/remote-connections
- コードレビュー：https://learn.chatgpt.com/codex/code-review
- ローカル環境：https://learn.chatgpt.com/codex/environments/local-environment
- Git Worktree：https://learn.chatgpt.com/codex/environments/git-worktrees
- ペット：https://learn.chatgpt.com/codex/pets