Codex Cloudとは？クラウドでの使い方・環境の作り方・料金と制限を解説

「Codexのクラウドは、手元で使うのと何が違うのか」「パソコンを閉じても作業が進むと聞いたが、どう始めるのか」「旧クラウドと書かれた画面があるが、どちらを見ればいいのか」と迷っている方は多いのではないでしょうか。

Codex Cloudは、Codexの作業をOpenAIが用意するクラウド上の環境で動かす使い方です。タスクごとに独立した作業場所が用意され、手元のパソコンがスリープしていても作業が進みます。結果はWeb・スマホ・デスクトップアプリから確認でき、よければコミットやプルリクエスト（変更を取り込んでもらうための依頼）に進めます。

この記事では、Codex Cloudの全体像と新旧の違いから、手元の作業との使い分け、プランと使用量、環境の作り方と設定、CLI・GitHub・Slackなどの入口、安全に使うための注意と現在の制限までを順に解説します。内容は2026年10月時点の公式ドキュメントをもとにしています。クラウドは2026年9月末に仕組みが刷新されたばかりで、画面や名称が変わりやすい部分です。実際に使う前には、公式ページもあわせて確認してください。

Codex Cloudとは

Codex Cloudは、公式ドキュメントで「コーディング作業をクラウドで動かす」機能と説明されています。バグの調査から機能の追加まで、プログラムに関する作業を任せられます。作業が進む場所はあなたのパソコンではなく、OpenAIが用意した仮想マシン（VM）です。

公式の説明を、流れに沿って整理すると次の3つになります。

1. プロジェクトを選ぶ作業の対象にするリポジトリ（ソースコードの保管場所）を選びます。Codexがプロジェクトの中身を調べ、準備を進め、足りない情報やアクセス権があれば尋ねてきます。
2. 作業を進めてもらう公開した環境からタスクを開始します。タスクごとに専用の作業場所があり、パソコンがスリープしていても動き続けます。
3. 結果を確認する変更されたファイルとテストの結果を見て、追加の修正を頼み、問題がなければコミットやプルリクエストの作成に進みます。

手元で動かすCodexとの大きな違いは、作業の前に「環境」を一度用意しておく点です。環境とは、リポジトリ・必要なツール・設定などをひとまとめにした、再利用できる作業の土台です。新しいタスクを始めるたびに、この環境から独立した作業場所が作られます。

新しいクラウドと旧クラウド（Legacy）

公式ドキュメントを読むと、「Codex Cloud」と「Codex Cloud (Legacy)」という2つの名前が出てきます。ここで混乱しやすいので、先に整理しておきます。

OpenAIの更新履歴では、2026年9月28日からの週に「再利用できるCodex Cloudの環境を用意する」機能が追加されたと案内されています。環境を一度用意して公開し、そのファイルシステムを新しいタスクごとの独立した作業場所で再利用する仕組みです。

ここで大切なのは、新旧が混在している期間があることです。たとえばGitHubのプルリクエストに@codexとコメントしてクラウドで作業させる流れは、公式のGitHubのページでは旧クラウドのチャットとして案内されています。画面の名称が記事と違って見えるときは、どちらの仕組みの画面かを確認してください。

旧クラウドの仕組み

GitHubの@codexやコードレビューを使っていると、旧クラウドの仕組みで動いていることがあります。公式の旧クラウドのページによると、1回のチャットは次のように進みます。

旧クラウドでは、環境変数はチャットの間ずっと使えますが、シークレットは、エージェントの作業が始まる前に取り除かれ、セットアップの間だけ使えます。コンテナのキャッシュは最大12時間保たれ、セットアップスクリプトや環境変数を変えると、自動的に無効になります。BusinessとEnterpriseでは、キャッシュはアクセスできる全員で共有されるため、1人がリセットすると全員に影響します。

クラウドでできること

公式のCodex Cloudのページでは、クラウドを使う場面として次のような例が挙げられています。

手元の作業との違い

Codexには、作業を動かす場所の違いとして「モード」があります。ChatGPTのデスクトップアプリで「Codex」を選ぶと、Local・Worktree・Cloudの3つから選べます。

LocalとWorktreeは、どちらも自分のパソコンで動きます。違いは、いまのフォルダを直接書き換えるか、分けた置き場で作業するかです。Cloudは、そもそも別の場所で動きます。

クラウドには渡らないもの

公式の説明で押さえておきたいのは、手元のものが自動ではクラウドに移らない点です。クラウドのタスクは、環境に含まれるファイルとサービスだけを使って動きます。

また、クラウドの1つのタスクで加えた変更は、環境そのものには反映されません。次のタスクの出発点を変えたいときは、環境を更新して公開し直します。

向いている仕事・向かない仕事

公式のモードのページには「どの仕事にクラウドを使うべきか」という明確な指針は書かれていません。ただ、上の違いから考えると、次のように分けられます。

迷ったら、「その作業にパソコンの中のファイルや、手元でログインしたものが必要か」で決めると分かりやすくなります。必要なければ、クラウドに任せて結果だけを確認する運用ができます。

使えるプランと使用量

Codex Cloudは、ChatGPTのアカウントでサインインして使う機能です。単独の商品ではなく、ChatGPTのプランに含まれています。公式の料金ページの内容を表にまとめます（2026年10月時点）。

FreeとGoは、公式の料金ページの機能一覧にクラウドの列がなく、使えるかどうかは公式には案内がありません。確実に使うなら、Plus以上を前提にしてください。また、APIキーでサインインして使う場合は、GitHubのコードレビューやSlackなどと同じく、クラウドの機能は使えません。

使用量の考え方

クラウドの作業も、ChatGPTのプランに含まれる使用量の枠の中で動きます。公式の料金ページでは、次のように案内されています。

• 手元のメッセージとクラウドのチャットは、プランの使用量の枠を共有する。週ごとの上限が別にかかることもある
• クラウドのタスクは、ローカルのメッセージより多く使う場合がある。使用量はモデルとタスクの内容によって変わる
• Proは、現在5時間ごとの上限はない
• 使用量の枠を使い切ったあとは、クレジットを追加して作業を続けられる

公式の料金ページには、PlusとBusinessの「手元のメッセージ」が5時間あたり何回ほど送れるかの目安が、モデル別に載っています。たとえばGPT-6.1 Solで15〜160回、GPT-6 Lunaで350〜3,000回と、モデルによって大きく開きます。ただしこれは手元のメッセージの目安で、クラウドのタスクだけの上限や単価は公式に案内がありません。実際の使用量は、ChatGPTの使用量の画面で確認します。確認方法は、別の記事で解説しています。

クラウドの作業場所（VM）の大きさ

クラウドの各タスクは、プランに応じた大きさのVMで動きます。公式の環境のページに載っている標準の大きさは次のとおりです。

Enterpriseでは、より大きなVMや、細かく指定した構成も用意されていると案内されています。テストの実行やビルドが重いプロジェクトでは、Plusの標準の大きさでは足りない場合があります。

プランの選び方の目安

公式の表から読み取れる範囲で、選び方の目安をまとめます。クラウドだけの使用量の上限は公開されていないため、実際に使って様子を見るのが確実です。

始め方

ここでは、公式のクイックスタートに沿って、環境を作って最初のタスクを動かすまでの流れを説明します。環境の新規作成は、WebかデスクトップアプリのChatGPTから行います。

1. ChatGPTを開いてサインインするChatGPTのWeb版、スマホアプリ、デスクトップアプリのどれかを開き、ChatGPTのアカウントでサインインします。
2. 環境を作る、または選ぶWebかデスクトップアプリでCodexの新しいタスクを開き、「Work in」から「Cloud」を選びます。「Select environment」を開いて、「Create environment」を選びます。「Settings」→「Codex Cloud」→「Environments」からも作れます。
3. プロジェクトを準備させるチェックアウトするGitHubのリポジトリを選び、「Get started」を押します。求められたらGitHubを接続します。Codexがリポジトリを調べ、依存関係やツールを入れ、動かして確かめます。足りない情報やアクセスを尋ねられたら答えます。
4. 内容を確認して公開するセットアップの報告、設定、ファイルを見て、「Save draft」か「Publish」を選びます。「Environment published」と表示されれば完了です。
5. 最初のタスクを始める新しい環境なら「Start a new task」を選びます。すでにある環境なら、すぐに始められます。やりたいことを書いて送り、変更とテスト結果を確認します。

手順3では、リポジトリを1つだけでなく、複数選ぶこともできます。環境の設定画面では、リポジトリ・インストールスクリプト・Startスキル・ネットワーク・環境変数・「Who can use」（使える人）・VPNやOIDCといった項目を、あとから見直せます。

スマホからは、公開済みの環境を選んでタスクを始めることはできますが、環境を新しく作ることはできません。先にWebかデスクトップアプリで作って公開しておきます。

最初のタスクは小さく、確かめやすいものから

最初から大きな機能追加を頼むより、結果がすぐ確かめられる依頼から始めるのがおすすめです。環境がきちんと動くかどうかの確認にもなります。

結果を受け取る

タスクが終わると、Codexの回答と、変更されたファイルの差分が表示されます。内容を確認して、追加の修正を同じタスクの中で頼めます。納得できたら、コミットを作るか、プルリクエストを開きます。

CLIを使っている場合は、クラウドのタスクの最新の差分を手元のリポジトリに反映するコマンドも用意されています。

公式のコマンド一覧では、codex applyは「安定版」の扱いで、別名はcodex aです。

環境の準備がうまくいかないとき

環境のセットアップに失敗したときは、画面の「Try again」で再実行するか、失敗したコマンドを直して再実行するようCodexに頼みます。環境の画面に「Unpublished」と表示されているときは、まだ公開されておらず、タスクでは使えません。

環境の設定

環境は、一度作れば終わりではありません。接続するサービスや、使える範囲を、あとから調整していくものです。公式の環境のページで説明されている項目を順に紹介します。

インストールスクリプトとStartスキル

環境の準備で、Codexは次の2つの項目に、確かめたセットアップを記録します。

公式のページには、新しいクラウドの標準のコンテナイメージの内容は載っていません。旧クラウドでは「universal」という既定のイメージが使われると説明されていますが、新しいクラウドでも同じかどうかは公式には案内がありません。

環境変数とネットワークシークレット

環境の設定には、プログラムに渡す値を登録する場所が2種類あります。「Environment variables」または「Network secrets」の横の「Manage」から設定します。

ネットワークシークレットは、本物の認証情報がローカルのプロセスやファイルに書き出されない作りになっています。APIキーのように「外に出したくない値」は、環境変数ではなくこちらで扱うのが基本です。

自分専用の変数やシークレットは、「Settings」→「Codex Cloud」→「Personal vault」に保存できます。すべての環境に適用するか、特定の環境だけに適用するかを選べます。環境ごとの値は、共通の既定値より優先されます。共有された環境では、環境の持ち主が「各自の値」を要求でき、使う人がそれぞれのアカウントから入れる形にもできます。

インターネットアクセス

クラウドのタスクが外のサイトに接続できるかは、環境ごとに決めます。設定は「Allow Codex to access internet」を有効にするところから始まります。

「Additional allowed domains」には、追加で許可するホストを入れられます。注意したいのは、ドメインを許可しても、そのサービスの認証情報までは渡らない点です。認証が必要なサービスには、前の項目のネットワークシークレットを使います。接続元のIPアドレスで制限しているサービスには、公式が公開しているエージェントの送信元IPのリストを使えます。

Enterpriseのワークスペースでは、「Agent Security」で組織全体の制限が設定されている場合もあります。その場合は、環境の設定とあわせて両方が適用されます。

保存される状態と、更新のしかた

環境とタスクの状態は、次のように扱われます。

公式のページには、「保存された状態は、ソースコード管理の代わりにはならない」と明記されています。大事な変更は、必ずコミットしてください。

環境の内容を変えたいときは、環境の「…」メニューから「Edit」を選び、変更したいことを伝えます。Codexが試したあと、「Republish」で公開し直します。新しいタスクには更新が反映され、すでに動いているタスクは、それまでの状態のままです。

共有・VPN・OIDC

共有された環境を使う人は、環境を「使える」だけで、編集はできません。部署で同じ環境を使いたいときは、環境を作る人と使う人の役割をあらかじめ分けておくと運用しやすくなります。

いろいろな入口から使う

クラウドのタスクは、ChatGPTのWeb・デスクトップアプリ以外からも始められます。公式ドキュメントで確認できた入口を表にまとめます。

どの入口でも、動いているのは同じクラウドの環境とタスクです。普段の作業の場所に近い入口を選ぶのが、いちばん続けやすい選び方です。開発の中心がGitHubならプルリクエスト、課題の管理がLinearならIssue、チームの相談がSlackならスレッド、という具合です。

CLIからクラウドを使う

CLIのcodex cloudは、ターミナルからクラウドのチャットを探したり、タスクを送ったりするコマンドです。公式のコマンド一覧では「実験的（Experimental）」とされ、別名はcodex cloud-tasksです。

認証は、通常のCLIと同じ認証情報を使います。タスクの送信に失敗すると、終了コードが0以外になります。--jsonを付けると、tasksの配列に、id・url・title・status・updated_at・environment_id・summaryなどが入った形で返ってくるので、スクリプトから扱えます。

スマホから使う

ChatGPTのスマホアプリ（iOS）の「Codex」から、クラウドの環境を選んでタスクを始められます。進み具合を見る、追加の指示を送る、変更されたファイルと差分・テスト結果を確認する、といった使い方ができます。Androidについては、公式のページには案内がありません。

GitHubから使う

プルリクエストのコメントで@codexに続けて「review」以外の内容を書くと、そのプルリクエストを文脈にしたクラウドのチャットが始まります。公式の例は@codex fix the CI failuresです。権限があれば、Codexは修正をそのプルリクエストのブランチに送れます。

公式のGitHubのページでは、この流れは「旧クラウドのチャット」として案内され、環境の設定は旧クラウドのページを参照する形になっています。GitHub連携の設定やレビューの使い方は、別の記事で詳しく解説しています。

Slackから使う

公式のSlackのページでは、Slackのチャンネルで@ChatGPTにメンションして依頼を始めると案内されています。クラウドへの委任が有効なワークスペースでは、リポジトリの作業を別のクラウドのタスクとして実行し、結果をスレッドに返します。

• 使うには、ワークスペースに共有された公開済みの環境が必要。管理者がCodex Cloudを有効にする
• ChatGPTは、アクセスできる共有環境から選ぶ。個人用の環境は選択肢に入らない。リポジトリ名や環境名を依頼に書くと選びやすい
• 依頼者には、アクセスの許可・拒否を選ぶ承認カードが非公開で表示される
• タスクが始まると、投稿でお知らせされる。「Follow along」と「Cancel」は、デプロイで有効にされていれば依頼者が使える
• 同じスレッドで追加の依頼をすると、作業が続く

注意点として、他の組織と共有している「Slack Connect」のチャンネルには対応していません。また、承認カードは非公開でも、チャンネルの返信は、そのチャンネルを見られる人なら誰でも読めます。秘密情報は、依頼文に書かないでください。以前に@Codexを使っていた場合は、ChatGPTのアプリが有効になったあとは@ChatGPTで依頼します。

Linearから使う

Linearでは、Issueの担当者にCodexを指定するか、コメントで@Codexとメンションすると、クラウドのチャットが始まります。進み具合と結果は、Issueに投稿されます。

1. GitHubとクラウドの環境を用意するCodexに、対象のリポジトリのGitHubを接続し、クラウドの環境を作ります。
2. Codex for Linearを入れるCodexのコネクタの設定から、「Codex for Linear」を導入します。
3. LinearのアカウントをつなぐIssueのコメントで@Codexとメンションすると、アカウントを連携するリンクが表示されます。

Codexは、Linearが示すリポジトリか、直前に使った環境を選びます。チャットは、環境のリポジトリの対応表にある先頭のリポジトリの、デフォルトブランチで動きます。特定のリポジトリを指定したいときは、コメントに「openai/codexでこれを直して」のように書きます。有料プランが必要で、Enterpriseでは管理者がクラウドのチャットとコネクタを有効にします。

GitLabから使う（ベータ）

GitLabのマージリクエストに対するコードレビューは、ベータ版として案内されています。公式のGitLabのページでは、すべてのChatGPTプランで利用でき、Codex cloudで動くとされています。マージリクエストに@codex reviewとコメントすると、Codexが目のリアクションを付けてレビューを投稿します。@codex fix the CI failuresのような依頼には、プロジェクトの環境が必要です。

安全に使うために

クラウドは「パソコンの外」で動く分、手元のファイルが勝手に書き換わる心配は小さくなります。一方で、外のサービスにつなぐ設定や、認証情報の扱いを間違えると、別の種類のリスクが出てきます。

インターネットアクセスは必要最小限に

公式の旧クラウドのページでは、エージェントがインターネットにアクセスできるようにすると、次のようなリスクが増えると説明されています。

• 信頼できないWebの内容による、不正な指示（プロンプトインジェクション）
• コードや秘密情報の外部への流出
• マルウェアや脆弱性のある依存関係の取り込み
• ライセンス上の制限があるコンテンツの取り込み

公式の例では、GitHubのIssueに隠された指示で、直前のコミットの内容が外部のサーバーに送られる場面が紹介されています。許可するドメインは必要なものだけにし、信頼できる情報源だけを参照させてください。旧クラウドの設定では、使えるHTTPメソッドをGET・HEAD・OPTIONSに限る設定もあり、これにするとPOSTなどは止められます。

認証情報の扱い

• 外部サービスのAPIキーは、環境変数ではなくネットワークシークレットで登録し、許可する接続先を絞る
• 旧クラウドでは、シークレットはセットアップの間だけ使え、エージェントの作業が始まる前に取り除かれる
• 環境を共有する前に、準備されたファイルと認証情報の中身を確認する
• Slackのチャンネルに書いた依頼は、見られる人全員に読まれる。秘密情報は書かない

環境の共有は、使うことだけを許す仕組みで、リポジトリへのアクセスは付きません。Slackのページにも「環境を共有しても、リポジトリへのアクセス権は与えられない」と書かれています。

現在の制限

公式の環境のページには、現在の制限として次の点が挙げられています。

できあがった変更を確認する観点

クラウドのタスクは、手元から離れた場所で動くため、結果を受け取るときに確認の漏れが起きやすくなります。公式のLinearのページにも「Codexは間違えることがあるので、回答と差分は確認する」と書かれています。取り込む前に、次の点を見てください。

• 変更されたファイルが、頼んだ範囲に収まっているか（関係のないファイルが変わっていないか）
• テストの結果が、環境の中で実際に実行されたものか
• 設定ファイルや認証情報に関わる部分に、意図しない変更が入っていないか
• 新しく追加された依存関係（外部のパッケージ）に、必要性と安全性の確認が取れているか

プルリクエストにしておけば、人のレビューや自動のテストを通してから取り込めます。クラウドに任せる範囲が広がるほど、この「取り込む前の確認」を決まった手順にしておくことが大切です。

会社で使うときに決めておくこと

チームで使う場合は、使い始める前に次の点を決めておくと、運用が安定します。

1. 環境を作る人を決める環境の公開・更新は、少人数の担当者に絞ります。使う人には「使える」権限だけを渡します。
2. つなぐリポジトリを絞るGitHubでCodexに見せるリポジトリは、必要なものだけにします。
3. インターネットの許可と秘密情報のルールを決める許可するドメインの基準と、認証情報の登録場所（ネットワークシークレット）をそろえます。
4. 結果は人が確認してから取り込む差分とテスト結果を見て、コミットやプルリクエストを作る担当者を決めます。
5. 使用量を定期的に見るクラウドのタスクは、手元より多く使う場合があります。月に一度は使用量の画面を確認します。

よくある質問

まとめ

Codex Cloudは、リポジトリが整っているほど、任せられる仕事が増える機能です。まずは小さなタスクで、環境がきちんと動くかを確かめるところから始めてみてください。

会社で使うには、環境を作る担当者、つなぐリポジトリの範囲、認証情報の置き場所、使用量の見方といった決めごとが一気に増えます。INTERCREATE JAPANでは、Claude CodeやCodexの導入から、社内で使い続けられる運用ルールづくりまでをお手伝いしています。