Codex CLIの使い方：導入からチーム共通設定まで

動作するプロジェクトと、Codexを利用できるアカウントがすでにある前提で、最初の15分をセットアップの目安にします。インストールやログイン、時間のかかるテストスイートによっては、それ以上かかることもあります。最初の成果として目指すのは、検証済みの小さな変更、または作業を妨げている原因の具体的な説明です。コマンドは2026年10月11日に確認しています。

Codex CLIをインストールして、小さなタスクを完了する

Codexはプロジェクト内で動き、ファイルの調査や編集、手元のマシンにインストールされたツールの実行ができます。別の作業台を使う開発メンバーと考えるとわかりやすいでしょう。タスクと作業範囲を伝えるのは人間であり、その成果をプロダクトに取り込むかどうかも人間が判断します。OpenAIのCLIガイド

0〜3分：インストール方法を一つ選ぶ

macOSまたはLinuxでは、スタンドアロンインストーラーを次のコマンドで実行できます。

curl -fsSL https://chatgpt.com/codex/install.sh | sh

既存の環境に合う方法があれば、そちらを使っても構いません。後で更新方法に迷わないよう、インストール経路は一つに絞りましょう。

Windows向けには、新しいPowerShellウィンドウで実行するコマンドとして、公式ドキュメントに powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex" が記載されています。

以上が、現行のCLIドキュメントと公式リポジトリで案内されているインストール方法です。Codexを起動する前に、ターミナルでプロジェクトのディレクトリを開いておきます。

3〜5分：ChatGPTログインかAPIキー認証を選ぶ

最初の対話セッションでは、プランとワークスペースで利用が認められていれば、ChatGPTログインを使うとよいでしょう。codex login を実行し、ブラウザで手続きを完了します。未ログインの状態で codex を起動した場合も、Sign in with ChatGPTという選択肢が表示されます。

プログラムからの利用など、OpenAI Platformのアカウントで使いたい場合は、APIキー認証を選びます。シェル環境に OPENAI_API_KEY が設定済みであれば、macOS/Linux向けの公式コマンドは printenv OPENAI_API_KEY | codex login --with-api-key です。キーはリポジトリ内のファイルに書き込まないでください。

codex login status を実行し、どちらの認証方式が有効か確認します。チームで使う場合、この違いは重要です。ChatGPT認証にはChatGPTワークスペースの管理設定が適用され、API認証にはAPI組織の管理設定が適用されます。認証ガイド

料金： ChatGPTログインでは、対象プランに含まれる利用枠を使います。APIキーでの利用は、OpenAI Platformを通じてAPI料金で別途課金されます。プランの比較はCodexの料金ガイドを参照してください。チームで試す際は、手作業にかかる時間と、プロンプト作成・レビュー・修正にかかる時間を比べ、実際に削減できた時間の価値から追加の利用料金を差し引きます。初稿が早くできても、受け入れまでの総作業量が減らなければ効果は出ません。OpenAIによる認証方式と課金の違いの説明

5〜8分：編集の前にコードを調べる

まずGitで作業前の状態を記録します。プロジェクトのシェルプロンプトから、公式ドキュメントに記載された codex --sandbox read-only --ask-for-approval on-request で調査用セッションを開始します。

調査範囲は明確に絞ります。たとえば、次のプロンプト例を自分のプロジェクトに合わせて調整してください。

これは作業の進め方を示すプロンプト例で、Codex専用のコマンドではありません。回答を読み、アプリケーションの適切な箇所を見つけているか確認します。読み取り専用のサンドボックスでも、境界内での調査やコマンド実行は可能です。境界の外に及ぶ操作には、承認が必要になることがあります。承認とサンドボックスのガイド

8〜12分：小さな変更を一つ任せる

編集を任せる準備ができたら、/permissions でワークスペースの編集を許可する設定に切り替えます。新しいセッションを開始する場合は、公式ドキュメントにある codex --sandbox workspace-write --ask-for-approval on-request を使います。

続いて、完了と判断する条件を伝えます。

最初は、結果を短時間で判断できる作業を選びます。既知の挙動を確認するテストの追加は、アーキテクチャの改善を漠然と頼むより、初回のタスクに向いています。

12〜15分：差分と検証結果を確認する

/diff でパッチを確認し、/review でレビューを依頼します。実際のテスト出力と変更されたファイルを見て、提示した完了条件を満たしているか判断してください。コミットは自分でもレビューしてから行います。これらのスラッシュコマンドは、シェルプロンプトではなくCodexセッション内で使います。CLIコマンドリファレンス

モデル選びは、比較の基準を作ってから

まずはセッションで利用できるモデルで始め、その後で /model を使って別のモデルを選んだり、推論の強度を調整したりします。OpenAIが現在示している起動例は codex --model gpt-6.1-sol です。

現時点では、アカウントとクライアントで利用できる場合、複雑なコーディングにはGPT-6.1 Sol、範囲が明確で繰り返し行うタスクにはGPT-6 Lunaが推奨されています。推論の強度を上げると難しい分析に役立つことがありますが、時間もトークンも多く使います。結果を比較する際は、初回タスクの内容と推論の設定を揃えてください。Codexのモデル選択ガイド

チームへの導入時には、タスクとテスト結果に加えて、使用したモデルも記録しておきます。モデル名を指定しても、アカウントにそのモデルの利用権限が付与されるわけではありません。

サンドボックスのアクセス範囲と承認ポリシーを分けて設定する

サンドボックスは、コマンドがアクセスできる範囲を定めます。承認ポリシーは、Codexが実行前に確認を求めるタイミングを定めます。サンドボックスが作業部屋の壁なら、承認ポリシーは扉を開けるための許可に相当します。

対話形式の作業には on-request を使います。サンドボックス内で許可された操作はそのまま進み、より広いアクセスが必要な操作では確認を求められることがあります。never はCodexが承認を求められない設定であり、サンドボックスを解除するものではありません。実行を阻まれた操作は、そのまま実行できないことがあります。

書き込み範囲を定めても、編集のたびに確認が入るとは限りません。workspace-writeとon-requestを組み合わせた場合、Codexはワークスペース内のファイル変更や許可されたコマンドの実行を自動で進められます。現在の設定は /permissions で確認してください。OpenAIによるサンドボックスと承認の挙動の説明

チームの古いテンプレートで approval_policy = "untrusted" を指定している場合は、更新してください。OpenAIはこの明示的な設定を廃止しており、指定すると起動できなくなる可能性があると説明しています。以前の codex exec --full-auto を使う方法も非推奨です。公式ドキュメントにあるサンドボックスと承認の設定を使ってください。現在の移行ガイド

チームの作業ルールをAGENTS.mdにまとめる

AGENTS.md を使えば、リポジトリの作業方法を毎回説明せずに済みます。Codexは実行開始時にこの指示を読み込みます。/init でひな形を生成できますが、チームで使い始める前に、メンテナーが内容を整えてください。

実用的なリポジトリ向けの指示ファイルには、次の四つの問いへの答えを書きます。

• 依存関係のインストールとプロジェクトの実行は、どの手順で行うか。
• 変更内容に応じて、どのテストやチェックを実施するか。
• 生成ファイルが入っているディレクトリや、特に注意が必要なディレクトリはどこか。
• 挙動の変更、実行したテスト、未解決の失敗など、完了報告に何を含めるか。

一般的な要望を並べるのではなく、実際に使うコマンドとチームの規約を書きます。個人の好みは ~/.codex/AGENTS.md に置き、リポジトリで共有する指示はプロジェクトルートに置いてコミットします。

Codexは全体に適用する指示を読み込んだ後、プロジェクトルートから現在のディレクトリに向かって指示を読み込みます。より作業場所に近い指示が、それ以前の指示より優先されます。同じディレクトリでは、AGENTS.override.md が AGENTS.md より優先されます。指示を変更したらセッションを再起動し、読み込んだ指示を要約するようCodexに依頼してください。AGENTS.mdの検出ルール

このファイルは、開発参加者向けのハンドブックとして扱います。技術的な制限には、設定や管理側で強制する要件を使ってください。

config.tomlは小さく保ち、レビューしやすくする

個人の既定値は ~/.codex/config.toml に保存します。プロジェクト共通の既定値は .codex/config.toml に置きます。Codexがこのファイルを読み込むのは、信頼済みのプロジェクトだけです。設定には、名前付きの設定項目を記述するテキスト形式であるTOMLを使います。

以下は、OpenAIの設定ガイドにある値を組み合わせた出発点です。モデルを指定する行は、そのモデルをアカウントで利用できる場合にだけ使ってください。

model = "gpt-6.1-sol"
model_reasoning_effort = "medium"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

CLIのフラグと --config による上書きは、プロジェクト設定より優先されます。信頼済みプロジェクトの設定は、選択したプロファイルやユーザーの既定値より優先されます。組織の要件によっては、それらの既定値にかかわらず、許可される設定が制限されます。設定の基本

web_search = "cached" は、キャッシュされたWeb検索結果を使う設定です。シェルコマンドのネットワークアクセスとは別のものです。CodexにWeb検索ツールがあっても、依存関係のダウンロードには承認が必要になることがあります。コマンドが失敗するたびに権限を緩めるのではなく、この違いを導入時の説明に含めておきましょう。

MCPサーバーは、必要な用途が決まってから追加する

MCP（Model Context Protocol）は、Codexをツールや外部のコンテキストに接続する仕組みです。ローカルサーバーはプロセスとして動作し、リモートサーバーにはHTTPアドレス経由で接続します。リポジトリだけでは得られない情報や実行できない操作がタスクに必要になったときに追加してください。

OpenAIのドキュメントにある例は codex mcp add context7 -- npx -y @upstash/context7-mcp です。この例では npx 経由でドキュメントサーバーを起動するため、そのランチャーが利用できる必要があります。設定済みのサーバーは codex mcp list で一覧を表示し、セッション内の /mcp で有効な接続を確認します。OAuthに対応するサーバーでは、codex mcp login <server-name> のプレースホルダーを設定済みのサーバー名に置き換えて実行します。

サーバー設定は、同じTOML設定の仕組みの中で、[mcp_servers.<server-name>] の下に記述します。チームは enabled_tools と disabled_tools で公開されるツールを制限できます。拒否リストは許可リストの後に適用されます。まずは、作業に必要な最小限のツールから始めましょう。MCPのセットアップと設定

ツールの応答が大きすぎる問題については、Codex CLIのMCP出力制限の解説を参照してください。サーバーの接続と、返される出力量の制御は、それぞれ別に検討する設定です。

タスクごとに作業用チェックアウトを分けたいときはworktreeを使う

Gitのworktreeを使うと、タスク用にリポジトリの別のチェックアウトを用意できます。実験的な変更を、いま作業しているファイルから切り離したいときに便利です。

OpenAIの0.154.0リリースでは、CLIタスク、対話セッション、会話のフォーク向けに、管理対象のworktreeが追加されました。実装上は実験的な worktrees 機能で有効化する必要があり、利用できるのはローカルセッションに限られます。CLIの公式な機能有効化コマンドに従って codex features enable worktrees を実行し、codex --worktree で起動します。リリースノート、対話型worktreeの実装、機能を管理するコマンド

対応するセッションでは、/worktree から管理対象のチェックアウトで新しい会話を始めるか、現在の会話をフォークできます。フォークは会話履歴を引き継ぎ、新しい会話は履歴なしで始まります。利用するには、機能が有効であることと、ローカルのGitリポジトリが必要です。worktreeのセッションコマンド

変更のレビュー、統合、作業後の片付けは、自分で行う前提で計画してください。CLIの実装では、管理対象として作成したチェックアウトの自動クリーンアップは無効になっています。また、別のチェックアウトを用意しても、サンドボックス設定やマージ前のレビューは引き続き必要です。管理対象チェックアウトのライフサイクル

並行してタスクを進める段階になったら、Codex CLIのworktreeガイドを参照してください。最初にテストを一つ追加する作業なら、チェックアウトは一つで十分です。

小規模チームで試したい六つのタスクと優先順位

以下は作業の提案であり、生産性を測定した結果ではありません。完了条件を最も確認しやすいものから始めてください。

Codexが、未決定のプロダクト方針を埋めてくれるわけではありません。また、テストがすべて通ったとしても、あらゆるリスクを網羅した証明にはなりません。完了条件の設定とレビューは、引き続き人間の仕事です。より広い観点での評価はCodexレビュー、購入を検討するための比較はCodexとClaude Codeの比較を参照してください。

技術系の創業者が作れる、用途を絞った二つのツール

より有望なのは、特定の技術スタックに絞った回帰テストサービスです。 既知のバグがあり、テストカバレッジが手薄な小規模チームに、レビュー済みのテストパッチを販売します。最小限の実用的な形は、再現可能なケースを受け取り、別のチェックアウトで範囲を限定したCodexタスクを実行し、パッチとテストの検証結果を返すものです。2026年10月11日に取得したDataForSEOの米国向けキーワード推計では、「automated software testing services」の月間検索数は880件です。この数字が示すのは、その仕事への関心であり、この製品への支払い意欲ではありません。難しいのは、信頼できるフィクスチャと意味のあるアサーションを用意することです。実装をなぞるだけのテストでは、価値はほとんど増えません。

もう一つの選択肢は、リポジトリ専用のレビューアシスタントです。 チームが文書化した規約を適用し、短く検証可能な指摘一覧を返すレビューであれば、エンジニアリング責任者が費用を払う可能性があります。まずは一つのリポジトリと、その AGENTS.md、繰り返し実行できるレビュー手順から始めます。同じ需要調査では、「ai code review」の米国での月間検索数は1,300件と推計されています。課題は差別化です。Codexにはすでにコードレビュー機能があるため、製品としては指摘の的確さを高め、誤検知を減らす必要があります。購入者が成果物を確認して実行できる点で、テスト生成のほうが初期の提供価値を明確にしやすいでしょう。

Codex CLIのセットアップでよくある質問

月曜日には、メンテナー一人とチームメンバー二人で同じ小さなタスクを実行し、レビューと修正にかかった手間を記録してみてください。引き継ぎがうまくいかなかった箇所は、共通の指示を直します。チームがこの流れを確実に繰り返せるようになってから、対象を広げましょう。

これらの管理設定を軸にしたリポジトリの作業フローが必要であれば、AI本番システムの構築をお手伝いします。