Codex Cloud：GitHub・Slack・Linear からタスクを委任
Codex Cloud は Codex の3つの実行環境のひとつです（CLI と IDE 拡張機能と並ぶ存在）。自分のマシン上で動くのではなく、分離されたクラウドコンテナ内でタスクを実行し、ウェブ、GitHub、Slack、Linear から起動できます。リポジトリをクローンし、バックグラウンドで作業し、確認用のサマリーと差分または PR を返します。最初に知っておいてください。Codex Cloud には ChatGPT Plus 以上が必要で、Free と Go では利用できません。
- 以下で扱うプランの条件、インターネットアクセスの初期設定、Slack/Linear のトリガー構文は、執筆時点の公式ドキュメントと照合済みです。この実行環境は変化が速いため、頼りにする前に最新のドキュメントで確認してください。
Codex Cloud とは？
Codex Cloud は、同じ基盤エージェントを共有する3つの実行環境のひとつです。ターミナルで動かす CLI や IDE 拡張機能と並ぶ存在です。核心的な違いはこうです。すべての Cloud タスクは、リポジトリへのアクセス、シェル、テストランナーを備えた独自の分離されたコンテナ内で動作し、そのどれもあなたのマシンには触れません。公式ドキュメントははっきりこう述べています。「隔離されたクラウド環境で Codex に作業を委任する」（learn.chatgpt.com/docs/cloud）。
読み進める前に3つの実行環境の全体像を知りたい方は、OpenAI Codex とは何かをご覧ください。混同を避けるために一言。Codex Cloud は Codex の機能であり、OpenAI 自身の「AgentKit」（Agent Builder）とはまったくの別物です。3者の詳しい区別はそのハブ記事にまとめてあり、ここでは繰り返しません。
はっきり述べておく価値のある実務上の意味合いがひとつあります。各タスクが独自のコンテナを持つため、Cloud タスクは実質的に使い捨てのインフラです。インストールしたもの、キャッシュしたもの、壊したものは、タスクが終わると何も残りません。そして、その動作が別のタスクのコンテナへ横に漏れ出すこともありません。これは、作業ディレクトリと既存の状態に対して直接すべてを実行する CLI と引き換えに得られるものです。
CLI・Cloud・IDE ― どれを使うべきか
3つの実行環境は同じエージェントを共有しますが、それぞれ適した状況が異なります。散らばったドキュメントからつなぎ合わせなくて済むよう、判断表を用意しました。
| 実行環境 | 動く場所 | 向いている用途 | 必要なもの |
|---|---|---|---|
| CLI | 自分のターミナル、対話形式。 | 手を動かすセッション、スクリプト作成、その場でのデバッグ。 | Codex CLI をインストール。Free プランでも（制限付きで）利用可能。 |
| Cloud | OpenAI のサーバー上の分離されたコンテナ。web/GitHub/Slack/Linear から起動。 | バックグラウンド作業、複数タスクの並列実行、ターミナルに張り付かずに委任すること。 | Plus プラン以上（下の表を参照）、接続済みの GitHub、少なくとも1つの環境。 |
| IDE | VS Code/JetBrains 内の拡張機能。 | エディタを離れずに差分を確認し、エージェントを操縦すること。 | 拡張機能をインストール。CLI/Cloud のアカウントを共有。 |
ざっくりした目安はこうです。キーボードの前にいて結果をすぐ見たいなら、CLI か IDE を使ってください。小さなジョブのまとまり ― 依存関係のバージョン上げ、小さなバグ修正、あるモジュールのテスト ― を委任したくて、待ちの間にマシンを占有したくないなら、Cloud に投げて別のことをしましょう。
実際には、3つすべてを使う人の多くは1つを選んで固定するのではなく、タスクごとに切り替えます。何度もやり取りが必要な厄介なリファクタリングは CLI に残します。小さくて独立した雑務の山は Cloud に振り分けて、1つずつ順番にではなく5つを同時に走らせます。そして IDE 拡張機能は、作業を開始するためというより、その直後の場面で使われます。ブラウザやターミナルに切り替えることなく、Codex がすでに生成した差分にさっと目を通すのです。
Codex Cloud のサンドボックスは実際どう動くのか
すべての Cloud タスクは独自のコンテナを取得します。Codex は接続された GitHub リポジトリをチェックアウトし、セットアップスクリプトを実行し（この段階では依存関係をインストールするためのネットワークアクセスがまだあります）、その後にはじめて実際のエージェントフェーズが始まります。そのエージェントフェーズの間、インターネットアクセスは初期状態でオフです。許可リストのプリセットを選びます。none（完全にオフ）、common-dependencies（一般的なパッケージレジストリを許可）、all（完全に開放）のいずれかです。出典：learn.chatgpt.com/docs/cloud/internet-access。正確なプリセットの挙動に頼る前に再確認する価値があります。変わることがあるためです。
各タスクをこうして分離する理由はかなりシンプルです。OpenAI が、異なるリポジトリ、異なるユーザー、異なる企業から、任意の数のタスクを同時に実行できるようにするためであり、あるタスクの依存関係インストールや暴走したプロセスが別のタスクに影響を与えないようにするためです。あなたにとっての実務上の利点は、1つの不安定な `npm install` が次のタスクの依存先となる環境を壊す心配をせずに、午後のうちに十数個の小さな委任タスクを投げられることです。どれも毎回クリーンな状態から始まります。
2つの「サンドボックス」の意味を混同しないでください。 ここで説明した Cloud のサンドボックス（分離されたコンテナ）は、Codex CLI のローカルのサンドボックス権限モード（
read-only/workspace-write/danger-full-access― ローカルの CLI セッションがディスク上で触れてよい範囲）とはまったく別の概念です。どちらも「サンドボックス」という言葉を使いますが、両者は無関係な2つの仕組みです。ローカルの権限レベルについては、ローカルのサンドボックス権限モードをご覧ください。
Codex Cloud を接続する ― GitHub・Slack・Linear
GitHub
GitHub アカウントを接続し、Codex がアクセスできるリポジトリを選び、リポジトリ（またはリポジトリのグループ）ごとに環境を作成します。依存関係、インストールするツール、環境変数、シークレットを宣言します。この環境こそ、Codex Cloud がそのリポジトリに対してタスクを実行するたびに再利用するものです。一度セットアップすれば、何度でも再利用できます。出典：learn.chatgpt.com/docs/cloud。
リポジトリごとに環境が1つに限られるわけではありません。たとえばフロントエンドとバックエンドのサービスを持つモノレポは、依存関係のセットが異なる2つの別々の環境を用意する妥当なケースです。そうすれば、フロントエンドに範囲を絞ったタスクが、決して使わないバックエンドのツール類のインストールにセットアップ時間を費やさずに済みます。これを最初に正しく整えるのは数分の追加コストの価値があります。数秒で作業を始めるタスクと、実行時間の大半をパッケージのインストールだけに費やすタスクとの違いになるからです。
Slack
Plus プラン以上、接続済みの GitHub アカウント、そしてすでにセットアップ済みの環境が少なくとも1つ必要です。ワークスペースの管理者が Slack 用の Codex アプリをインストールし、それ以降は誰でも、チャンネルやスレッドで @Codex にメンションすることで作業を委任できます ― たとえば「@Codex fix the null pointer in org/repo」のように（これは説明のための例であり、ドキュメントの逐語的な引用ではありません。引用として公開する前に正確な構文を確認してください）。Codex は 👀 の絵文字でリアクションし、タスクを追跡するためのリンクを投稿し、それから同じスレッドで結果を返信します。出典：learn.chatgpt.com/docs/third-party/slack。
ここで気づく価値があるのは、アプリがインストールされれば、セットアップした本人だけでなく、チャンネルにいる誰もが作業を委任できるという点です。だからこそ「管理者が一度インストールし、誰でも起動できる」というモデルがチームにとって重要になります。新しいメンバーに「Codex に頼む」ことを覚えてもらうのは Slack のメンション1つで済み、CLI のインストールと認証フローは要りません。
Linear
「Codex for Linear」アプリをインストールし、イシューのコメントで @Codex にメンションしてアカウントを連携します。タスクを起動する方法は2つあります。イシューを直接 Codex に割り当てるか、コメントで @Codex にメンションするかです。トリアージ自動化をオンにすれば、毎回手作業でやる代わりに、新しくトリアージされたイシューを Codex に自動割り当てすることもできます。出典：learn.chatgpt.com/docs/third-party/linear。クラウドに作業を委任するのではなく、Linear のデータをローカルで読むだけで十分な場合は、Codex MCP のセットアップをご覧ください。
実際の委任タスクを最初から最後まで
私が最もよく実行しているものを紹介します。Slack で報告された小さなバグを、ターミナルを開かずに直すというものです。
- 起動。 開発チャンネルで、
@Codex fix the crash when a user submits an empty email field on org/checkout-serviceと入力します（説明用であり、逐語的なコマンドではありません）。ターミナルは開いておらず、ローカルにリポジトリもクローンしていません。この時点では、スマホで Slack を読んでいるだけです。 - 環境の選択。 Codex は
checkout-serviceリポジトリ用にすでに構成された環境を選びます。毎回依存関係を宣言し直す必要はなく、そのサービスが固定している Node/Python のバージョンを覚えておく必要もありません。 - コンテナの起動。 Codex はリポジトリをチェックアウトし、セットアップスクリプトを実行して依存関係をインストールし、それからその環境用に選んだプリセットにインターネットアクセスを設定した状態でエージェントフェーズが始まります。
- バックグラウンドで実行。 その間、私は別のことをします。ターミナルに張り付くことも、「まだ考えているのか」と更新を繰り返すこともありません。
- 結果を確認。 Codex は変更内容のサマリーを差分とともに、まさに Slack のスレッド内に投稿します。私はそれを、ざっと流し読むトランスクリプトとしてではなく、同僚の PR の説明を読むのと同じように読みます。
- PR を開く。 差分を読み、問題なさそうなら Codex に PR を開かせます。盲目的なマージではなく、同僚の PR のようにレビューします。何かおかしければスレッドで返信すると、承認する前に修正してくれます。
効果は生の速さではありません（自分で2分で打てる変更なら、CLI のほうが速いこともあります）。効果は、私がSlack を一度も離れないことであり、こうした小さな修正をいくつも並行して委任でき、そのたびに自分のマシンを占有したりターミナルへ切り替えたりせずに済むことです。
どの ChatGPT プランが必要か
これはこのガイドで最も役立つ事実です。Free と Go では Codex Cloud を利用できません。 公式ドキュメントによると、Slack 連携のページが要件をはっきり述べています ― 「Plus、Pro、Business、Enterprise、Edu のいずれかのプラン」（learn.chatgpt.com/docs/third-party/slack）。これは learn.chatgpt.com/docs/pricing とも一致します。
| ChatGPT プラン | Codex Cloud を利用できる？ |
|---|---|
| Free | ✗ |
| Go | ✗ |
| Plus | ✓ |
| Pro | ✓ |
| Business | ✓ |
| Enterprise / Edu | ✓ |
Free か Go を使っていて、クラウド委任のボタンを押しても何も起きないなら、それが理由です ― バグではありません。もう1つ知っておくべきこと。料金ページによると、Cloud とローカル CLI の利用は、別々の予算ではなく、同じローリング式のクレジット枠（おおよそ5時間）を共有します ― この数字を前提に重い利用を計画する前に再確認してください。上限は変わるためです。このプランの条件も恒久的なものと考えないでください ― ChatGPT のプラン機能は過去にも動いてきたので、読んでいる時点で改めて確認してください。
実際的には、これは Cloud を多用する習慣 ― たとえば1日に10個の小さなタスクを振り分ける ― が、対話的な CLI セッションと同じ利用枠を消費することも意味します。すでにプランの上限近くまで長い CLI セッションを回しているなら、その上に忙しい Cloud ワークフローを追加するのは、すでに持っているプランに無料で上乗せされる余剰容量だと決めつけず、注視する価値があります。
Codex Cloud 対 Claude Code ― クラウド委任は本物の差別化要因
誇張なしに率直に言います。Claude Code の主な実行環境はローカル/CLI で、自分のマシン上で動き、subagent や hook を通じて拡張されます。Codex は逆方向に進み、GitHub/Slack/Linear を通じたファーストパーティのクラウド委任を標準で出荷しており、追加で作り込むものは何もありません。これはマーケティングではなく本物の違いです ― チームが自前のパイプラインを組み立てずに Slack や Linear から作業を委任したいなら、それは Codex Cloud に有利な確かな点です。
逆に、主な作業が段階ごとにきめ細かい制御を必要とする長い対話セッションなら、Claude Code のほうが依然として subagent/skill/hook のエコシステムが深いです。全体の比較については、Claude Code 対 Codex の完全比較をご覧ください ― その記事はまだ Cloud を具体的には扱っていないので、このガイドをその補完編として扱ってください。
これが実際に最も効いてくるのは、個人利用ではなくチームでの導入です。チーム全体に CLI をインストールさせ、認証させ、そのフラグを覚えさせるのは、実際の摩擦です。すでに日常的に使っている Slack のスレッドで @Codex と打ってもらうのは、ほぼゼロ摩擦です ― そしてその差こそ、どのエージェントが技術的により高性能かとは関係なく、クラウド委任が CLI ツールよりも速くチームに広まりやすい理由です。
よくある質問（FAQ）
Codex Cloud とは？
Codex Cloud は Codex の3つの実行環境のひとつで、分離されたクラウドコンテナ内でタスクを実行し、ウェブ、GitHub、Slack、Linear から起動でき、確認用の差分または PR を返します。
Codex Cloud には有料プランが必要ですか？
はい。Plus、Pro、Business、Enterprise、Edu のいずれかが必要です ― 執筆時点の公式ドキュメントによると、Free と Go では利用できません。
GitHub の PR から Codex Cloud を起動できますか？
はい。GitHub アカウントを接続し、そのリポジトリ用の環境を作成すれば、GitHub は（Slack や Linear と並ぶ）3つの公式トリガーチャネルのひとつです。
Codex Cloud にインターネットアクセスはありますか？
セットアップスクリプトの段階では、あります（依存関係をインストールするため）。実際のエージェントフェーズの間は、インターネットアクセスは初期状態でオフで、none/common-dependencies/all の許可リストプリセットで開放できます。
タスクが終わった後、私のコードはどうなりますか？
Codex はサマリーを差分とともに返すか、確認用の PR を開きます。タスクを実行したコンテナは、その実行だけのための分離された環境であり、あなたのマシンではありません。
Slack/Linear のタスクは並列で実行できますか？
はい。各タスクは独自のコンテナで実行されるので、Slack、Linear、GitHub から複数のタスクを一度に委任でき、順番に実行されるのを待つ必要はありません。
まとめ
手短に言うと、手を動かす対話的な作業には CLI、GitHub・Slack・Linear を通じたバックグラウンド/並列/チーム起動の作業には Cloud を ― そして Cloud には Plus 以上が必要です。3つの実行環境の違いがまだはっきりしないなら、何かを設定する前に、全体像を知るためにOpenAI Codex とは何かに戻って読んでください。