Codex CLIとCodex Cloudの使い分け：環境構築から料金・スマホ操作まで

Codex CLIでのローカル作業と使い分けられるのが、Codex Cloudです。デスクを離れる前に、失敗しているテストをCodexに渡しておけば、ノートPCの電源を切っても作業を続けられます。再利用できるプロジェクト環境を用意し、Webやスマホから進捗を追い、指示を補い、結果を確認できます。

9月30日の刷新で何が変わった？

今回の刷新で、クラウド上の作業を繰り返し始めやすくなりました。リポジトリ、依存関係、スクリプト、各種設定を、次のタスクを開始する前に準備しておけます。スマホや別のPCから進捗を確認し、Codexに追加の指示も出せます。デスクトップで使い慣れた操作体験が、Webとモバイルにも広がります。これらが、OpenAIの2026年9月30日の発表で示された変更点です。

環境は、準備済みの作業場と考えると分かりやすいでしょう。道具と材料は使える状態にしておき、タスクごとに専用の作業台を用意します。依存関係とは、プロジェクトが必要とするソフトウェアパッケージのことです。リポジトリは、コードをバージョン管理しながらまとめて保管する場所です。

実務上の利点は、コーディングの作業と、自分のPCを起動しておく必要を切り離せることです。Codex CloudはOpenAIが管理するコンピューター上で動きます。デスクトップまたはWebで環境を作成して公開すれば、対応するデバイスから利用できます。作業ファイルはタスクごとに分かれます。この仕組みは、OpenAIのCloudヘルプで説明されています。

私なら、結果を検証できる小さな仕事から始めます。バックグラウンドで動くエージェントは、「何をもって正しい結果とするか」が先に決まっているときに役立ちます。

Codex Cloudを利用できるプランは？

Cloudを利用するには、対象となるPlus、Pro、Business、Enterprise、Healthcare、Educationのいずれかのアカウントが必要です。提供状況やワークスペースの設定によって利用可否は変わります。FreeとGoでもCodexを利用できますが、Codex Cloudは含まれません。ゲスト、K-12、Enterpriseの閲覧専用シートでは、クラウド環境を作成できません。この区分は、OpenAIのプラン別提供条件に基づいています。

上記のサブスクリプション料金は、2026年10月7日に確認したCodexの料金ページに基づいています。Cloudの対象プランでも、すべてのメンバーがすべての設定や操作を使えるとは限りません。

クラウド作業では利用枠をどう消費する？

提供開始時点では、標準環境に仮想マシンの別途料金はかかりません。仮想マシンとは、タスクを実行するリモートのコンピューターです。ただし、モデルの使用量は通常のCodexの利用上限に算入され、該当するクレジットや課金の対象になります。共有プールを持つプランでは、提供されている範囲でCodex、ChatGPT Work、ChatGPT for Excel、Workspace Agentsの使用量を共有できます。トークンベースのEnterprise契約は、クレジットではなくUSDで請求されます。使用量の計算方法は、OpenAIの利用ルールで説明されています。

ローカルのメッセージとクラウドのチャットは、プランの利用枠を共有します。週単位の上限が適用される場合もあります。クラウドのタスクは、ローカルのメッセージより多くの利用枠を消費することがあります。料金ページにあるメッセージ数の目安はローカルでの利用を示すもので、クラウドで実行できるジョブ数を保証するものではありません。対象となるPlusとProのユーザーは、プランを変更せずに追加クレジットを購入できます。現在の上限とリセット時刻は、使用量ダッシュボードで確認してください。条件による違いは、Codexの料金と使用量に記載されています。

対象プランをすでに契約しているなら、利用枠を追加購入する前に、範囲を絞ったタスクを試しましょう。仕事としての費用対効果は、削減できた手作業の時間から、セットアップの維持、追加指示、レビューにかかった時間を差し引くことで考えます。追加クレジットの費用は別に計上します。作業をノートPCから移す価値があるのは、この収支が改善する場合です。

サブスクリプションとAPIの料金を広く比較したい場合は、2026年のCodex料金ガイドを参照してください。CloudにはChatGPTでのサインインが必要です。APIキーを使うローカルCLIのセッションには、別のAPI課金が適用されます。その違いは、認証方法の説明で確認できます。

再利用できる環境を作るには？

大きな変更を任せる前に、テストが安定して動くプロジェクトを用意します。旧来のワークフローではなく、現行のクラウド環境のセットアップ手順に従ってください。

1. リポジトリを接続します。 Webまたはデスクトップで、Work in > Cloud > Select environment > Create environmentを選びます。GitHubのリポジトリを選択し、接続を求められたらGitHubを接続します。
2. プロジェクトを準備します。 Get startedを選びます。Codexに調査、インストール、テストを進めてもらい、不足している情報や必要なバージョンを伝えます。
3. セットアップ用スクリプトを確認します。 Install scriptには依存関係の準備が、Start skillにはサービスの起動と準備完了までの処理が記録されます。対話しながらセットアップを調整します。
4. 値を設定します。 環境変数またはネットワークシークレットの横にあるManageを選びます。ネットワークシークレットには、キー、値、許可するドメインを入力します。
5. インターネットへのアクセスを設定します。 必要に応じてAllow Codex to access internetを有効にします。Package managersまたはCustom domains onlyを選び、必要なホストを追加します。**All (unrestricted)**では、より広いアクセスを許可します。
6. 公開して作業を始めます。 ファイル、設定、チェック結果を確認して保存し、Publishを選びます。Environment publishedと表示されたら、新しいタスクを開始します。後からセットアップを変更する場合は、EditとRepublishを使います。

準備のための対話では、プロジェクトで実際に使うインストールとテストのコマンド、必要なランタイムのバージョン、サービスをCodexに伝えます。何が成功し、何を検証できなかったのかも報告するよう求めてください。これは指示の組み立て方の提案であり、どのプロジェクトにもそのまま使えるセットアップスクリプトではありません。

最初の試行では、人工的に作成したテストデータを使い、作業を再現するのに必要な最小限のサービスアクセスを与えるのがよいと考えます。パッケージのダウンロードに失敗したら、すぐにインターネットへのアクセスを広げず、ホスト名と認証をそれぞれ調べます。

最初に任せたい3つのタスク

出発点が明確で、範囲が小さく、終わった後に証拠を確認できるタスクを選びます。以下の依頼文は、リポジトリに合わせて調整して使える例です。

失敗するテストを修正する

再現できる不具合によってリリースが止まっている創業者なら、原因の調査と、その問題に絞った修正を任せられます。失敗するコマンドと出力を渡しましょう。本来の動作を維持し、原因を説明し、実行したチェックを報告するようCodexに求めます。

依頼文の例です。

プロジェクトに記載されたコマンドで、この失敗するテストを再現してください。原因を特定し、正しく直せる最小限の修正を行ってください。テストを通すためにアサーションを弱めないでください。対象のテストと、関連する周辺のテストを実行してください。変更したファイル、結果、まだ確認できていない点をまとめてください。

私が最初のタスクとして最も勧めるのは、修正前と修正後の状態を目で確認できるからです。テストが成功しても、差分のレビューは必要です。パッチが失敗を隠すだけになっていないか、本来の動作を直しているかを確認します。

マイグレーションを作成する

データベースのスキーマを変更するバックエンド開発者なら、マイグレーションファイル、互換性の検討事項、使い捨てデータを使ったテストを求めます。マイグレーションとは、データベースの構造や保存データに対する変更を、バージョン管理するものです。

依頼文の例です。

リポジトリで使われている既存の規約に従って、このスキーマ変更のマイグレーションを作成してください。現在のアプリケーションとの互換性、ロールバックの選択肢、データ損失のリスクを説明してください。可能な範囲で、使い捨てのフィクスチャを使ってテストしてください。本番環境での実行やデプロイは行わないでください。

得られるのは、レビューできる実装と、より明確な適用計画です。マイグレーションを書くだけでは、本番でのロック、バックフィルにかかる時間、アプリケーションの新旧バージョンが共存できるかどうかは決まりません。それらの判断は、デプロイの責任者が行います。

プルリクエストをレビューする

チームメンバーの変更を待つメンテナーなら、PRのブランチまたはコミットと、比較元のベースブランチを指定します。作業ファイルは変更せず、根拠を添えた指摘を求めましょう。

依頼文の例です。

このプルリクエストをベースブランチと比較して調べてください。正しさ、認可、互換性、足りないテストに重点を置いてください。各指摘にファイル内の位置、具体的に不具合が起きる状況、裏付けとなる証拠を添えてください。ファイルの変更やPRのマージは行わないでください。

GitHubと連携したレビューを使いたい場合、OpenAIはリポジトリの接続と、PRへの@codex reviewコメントを案内しています。その手順は、GitHubレビューの設定で説明されています。移行期間中、Code Review、Security Review、既存のGitHubおよびLinear連携は、引き続き**Codex Cloud (Legacy)**を使います。この区分は、Cloudのヘルプページでも確認できます。

新しいクラウドタスク内でレビューを依頼する方法と、GitHub上で自動レビューを実行する方法は、別のワークフローです。

次に任せたい3つの仕事

失敗するテストの修正を試した後は、範囲を絞りやすく、検証しやすいものから順に検討するとよいでしょう。以下はワークフローの提案であり、実施結果の報告ではありません。

依頼文には、完了と認める条件を必ず含めます。「このコードベースを改善して」だけでは、未決定のことが多すぎて、最初の依頼としては機能しません。

スマホから進捗を確認し、指示を追加するには？

作業を続けたいときは、同じタスクに戻ります。新しいタスクを開くと別のワークスペースが作られ、元のタスクでコミットしていない変更は引き継がれません。重要な変更はコミットしてください。保存されたVMを復元できる期間の既定値は、最後のターンの開始またはタスクの再開から最大7日間です。これは、会話履歴の保持期間を定めるルールではありません。何が保存されるかは、OpenAIのタスク状態に関する説明で確認できます。

モバイルでCodexを開き、公開済みの環境を選びます。タスクを開き直せば、進捗を追いながら修正の指示を送れます。デバイスをまたいだ作業の流れは、Cloudの概要で説明されています。

よい追加指示は、迷っている判断を決めるものです。

• 「修正はパーサーの中に収め、公開レスポンスの形式は維持してください。」
• 「マイグレーションのテストには、使い捨てのデータベースフィクスチャを使ってください。」
• 「パッチとテスト報告ができたら止めてください。デプロイはレビュー後に判断します。」

私なら、スマホでは作業範囲の判断と進捗確認を行い、大きな差分は広い画面でレビューします。自分のノートPC上で動いているタスクへのリモートアクセスは、そのPCに依存します。Cloudのように、ノートPCの電源を切っても実行を続けられるわけではありません。この違いは、OpenAIのヘルプページで区別されています。

Codex CLIとCloudはどう使い分ける？

範囲が明確な仕事を独立して進めたいときは、クラウドを選びます。自分のPCにあるファイルや開発ツールが必要なときは、ローカルCLIを選びます。

CLIは、ローカルのリポジトリを調べ、ファイルを編集し、インストール済みのツールを実行できます。プロジェクトのディレクトリを開いてcodexを実行し、ChatGPTでサインインします。codex cloudを通じてクラウドへタスクを任せることもできるため、どのインターフェースから始めたかだけで実行場所が決まるわけではありません。両方の使い方は、CLIガイドで説明されています。

以下は、私が勧める使い分けです。

現在のCloud環境は、コンピューター／ブラウザー操作、GitLab、セルフホストのGitHub Enterprise Serverに対応していません。個人のローカルスキルも同期されません。クラウドを好むかどうかより、こうした現在の制約を踏まえて選ぶことが大切です。

アクセス範囲を絞り、差分をレビューする

環境が何にアクセスできるかを把握します。 許可ドメインはVMのネットワーク接続先を制御するもので、サービスの操作権限を付与するものではありません。環境に属するネットワークシークレットのドメインも、接続先として許可されます。環境設定に加えて、EnterpriseのAgent Security要件も適用されます。各制御は、ネットワーク設定とAgent Securityで説明されています。

認証情報の渡し方を適切に選びます。 環境変数を直接設定すると、その値はプログラムに渡ります。ネットワークシークレットは、セットアップ時とタスク実行時に、許可されたHTTPS接続先のポート443に対してプロキシのプレースホルダーを使います。これにより、生の認証情報をローカルのプロセスやファイルに渡さずに済みます。その仕組みは、シークレットの取り扱いで説明されています。

私なら、最初のコーディングタスクに本番の認証情報は渡さず、範囲を絞った開発用アクセスを使います。マージ前には差分を読み、テストの出力と依存関係の変更を確認し、パッチが依頼内容に合っているかを確かめます。テスト一式の成功は判断材料であり、レビューを省いてよいという許可ではありません。

Healthcareアカウントで利用できるからといって、CloudがOpenAIのBAAの対象になるわけではありません。BAAは、対象となる医療データの取り扱いに関する契約です。OpenAIは、Codex Cloudで保護対象の医療情報を処理しないよう求めています。この境界は、Cloudのデータ制限に示されています。

チーム向けの制御については、DevDay後のCodexセキュリティ設定ガイドを参照してください。

この仕組みを使って、どんな商品を作れる？

最も有望なのは、特定のソフトウェアスタック向けに、リリースを妨げる不具合を修正するキットです。失敗するテストへの対応で時間を失っているチームに、繰り返し使えるワークフローと検証方法を提供します。DataForSEOの10月7日の調査では、「automated software testing tools」の米国におけるGoogle月間検索数は1,600と推定されています。 これは仕事そのものへの関心を測る数字であり、Codex Cloudに特化した需要を示すものではありません。

実用になる最小構成は、リポジトリ用の指示、再現可能なフィクスチャ、対象を絞った修正依頼文、環境の準備ガイドでしょう。提案されたパッチが本来の動作を維持し、レビューの手間を減らすかを測ります。課題は、テスト基盤の多様さです。広い範囲のスタックに対応しようとすると、小さなキットでも維持費が高くなります。

マイグレーション検証パックなら、特定のフレームワークとデータベースを使うチームに提供できます。DataForSEOは、「database migration tools」の米国における月間検索数を1,300と推定しています。 MVPには、マイグレーションのテンプレート、使い捨てのテストデータ、互換性チェック、準備済みの環境で開発者が使うレビュー用プロンプトを含められます。課題は、本番での挙動です。再利用できるパッケージでも、実際のデータベースへの適用が安全に、あるいは短時間で終わるとは保証できません。

PRレビューの根拠をまとめるパックなら、メンテナーが指摘を依頼し、評価する方法を統一するのに役立ちます。DataForSEOは、「ai code review」の米国における月間検索数を1,300と推定しています。 実際の検索で挙がる質問には、「Can ChatGPT do a code review?」（ChatGPTでコードレビューはできますか？）もあります。リポジトリ用のガイド、レビューの依頼文、指摘の根拠をまとめる書式から始められます。課題は、標準のレビュー機能がすでに存在することです。このパックには、対象分野に即した判断と、有用なチェックを加える必要があります。

いずれも、文書化されているタスク委任の仕組みを基にした商品案です。検索数は仕事の分野に対する関心の推定値であり、顧客数や売上予測ではありません。まずは修正キットから始めるのがよいでしょう。レビュー全般の品質より、完了条件を測りやすいためです。

ChatGPTでコードレビューはできますか？

はい。Codexには、GitHubのPRをレビューする手順が文書化されています。調査タスクとしてレビューを依頼することもできます。ベースブランチと、確認したいリスクを指定してください。マージの判断は人が行います。

AIが書いたコードは安全ですか？

実際のパッチを評価してください。動作の変更、認可、依存関係、テスト、未検証の前提を確認します。説明が整っていても、テストが成功していても、重要なケースをすべてカバーできている証明にはなりません。

コードレビューに時間をかける価値はありますか？

追加の確認によって、損失の大きいミスを見つけられそうな場面でエージェントのレビューを使います。役に立った指摘と誤検知を記録しましょう。削減できる手間よりレビューの負担が増えるなら、対象範囲を狭めます。

月曜日にまず試すこと

信頼できるテストコマンドがあるリポジトリを選びます。その環境を準備して公開し、再現できる小さなテストの失敗を任せ、デスクを離れた後にスマホからタスクを確認してください。マージ前にパッチをレビューします。セットアップの手間、レビューの手間、プランの使用量を記録しましょう。この試行で仕事の進め方が改善するなら、環境を再利用します。

このワークフローをチームの開発・リリース工程に組み込みたい場合は、AIを使う本番システムの構築をご覧ください。