Codex Cloudが登場。それでもAIエージェントをローカル環境で動かすべきケースとは？

9月29日のDevDayにおいて、OpenAIは開発者が「コンピューター上でも、スマートフォンからのリモートでも、あらゆるデバイスからクラウド上でも、必要な場所でどこでもCodexを実行できる」と発表しました。DevDayの振り返り記事の中でチームにとって最も重要となるのは、それに続く一文です。再利用可能な開発環境は「タスクを素早く開始できるようにし、承認済みの設定と権限を備えた共有セットアップをチームに提供」します。Codex cloudは、Plus、Pro、Business、Healthcare、Education、Enterpriseの各プランで利用可能です。

個人の開発者にとっては、これで話は決まりかもしれません。しかし、すでにワークステーションでClaude Codeを動かし、ビルドサーバーでCodexを動かし、誰かのノートPCでGeminiを動かしているチームにとっては、作業場所がもう1つ増えることを意味します。作業はOpenAIのクラウド上、自前のハードウェア上、さらには電車内のスマートフォンからも開始できるようになり、実行履歴のリストはそれぞれの場所に分散します。「どのエージェントが何を担当しており、何が完了し、何がレビュー担当者を待っているのか」を確認する場所がまた1つ増えるのです。したがって、真に有用な問いは「クラウドかローカルか？」ではありません。「どの作業をどこで実行すべきか、そしてその作業の記録はどこに残るのか？」なのです。

TL;DR（要約）

Codex cloudは、迅速に開始したい作業、ノートPCがスリープ状態でも継続したい作業、あるいはスマートフォンから着手したい作業に適しています。また、メンバー各自が個別にホスト環境を用意するのではなく、承認済みの共通セットアップを1つ用意したいチームにとっても最適です。一方、自前のComputerが優れているのは、タスクにClaude CodeなどのCodex以外のRuntimeが必要な場合、契約プランのデフォルトVMを超えるハードウェアが必要な場合、あるいは現時点でOpenAIのクラウド環境ドキュメントで非対応とされている要件（GitLabリポジトリ、ブラウザ操作、SSHやデータベースプロトコル経由でアクセスするプライベートサービスなど）が必要な場合です。どちらを選択しても、誰がその作業を割り当て、誰が承認するのかという点は変わりません。それはチームの手元で、Taskとして管理されます。

Codex cloud環境がもたらすメリット

OpenAIのドキュメントによると、クラウド環境とは「タスクが使用する再利用可能なセットアップであり、リポジトリ、依存関係、ツール、アクセス設定」で構成されます。GitHubリポジトリを選択すると、Codexがそれらを検査し、依存関係やツールをインストールしてワークフローをテストし、推測できない部分があれば質問してきます。セットアップレポートを確認して公開すれば準備は完了です。以降の新しいタスクはすべて、その公開されたファイルシステムから独自の隔離されたワークスペースで起動し、タスクは「コンピューターがスリープ状態でも実行を継続できます」。

アクセス制御モデルは、トークンを貼り付けたセットアップスクリプトよりもはるかに慎重に設計されています。環境変数はプログラムに直接渡されますが、ネットワークシークレットがプロセスに直接届くことは決してありません。プログラム側にはプレースホルダーが渡され、許可されたHTTPS接続先に対してのみプロキシが実際のリクエストに本物の認証情報を代入します。インターネットアクセスは、有効化した上でパッケージマネージャーのプリセットやカスタムドメインリストによって制限できます。プライベートサービスへはVPN経由で接続可能で、現時点ではTailscaleがサポートプロバイダーとなっています。また、Enterpriseワークスペースでは有効期間の短いクラウド認証情報を取得するためのOIDC接続をリクエストできます。

作業の開始方法も同様に柔軟です。Codex Cloudの概要にはWeb、デスクトップアプリ、モバイル、Codex CLIが挙げられており、Cloud delegation（クラウド委譲）を利用可能なEnterpriseワークスペースでは、SlackやMicrosoft Teamsの@ChatGPTからタスクを開始することもできます。Enterprise環境はワークスペース内で共有できるため、新しく参加したチームメンバーも環境を一から作り直すことなく、承認済みのセットアップから作業を始められます。Codexの作業において、これは環境の差異（セットアップドリフト）が生じる大きな原因を排除してくれます。

OpenAI自身のプロダクトラインナップを見ても、配置場所は単一の答えに固定されるものではなく、ワークロードごとに選択すべきものとして扱われています。Dotsにはそれぞれ専用のクラウドコンピューターが割り当てられ、Agents APIはエージェントの実行主体に関する記事で解説したように、OpenAIホスト型またはセルフホスト型のいずれの環境も選択できます。そして今や、Codexもその両方の場所で実行できるようになりました。

Sharkly Computerがもたらすメリット

Computerとは、Agentが作業を実行できる、接続されたデバイス、サーバー、またはコンテナのことです。Sharkly Computersのドキュメントの言葉を借りれば、「Agentが必要とするOS、ファイル、認証情報、ネットワークアクセス、ツールを提供する」ものです。軽量なローカルサービスがマシンを登録し、そこにインストールされているRuntimeを検出し、キューに入った実行タスクを受け取って、進捗状況をストリーミングで送り返します。このサービスは外向きに接続を開くため、一般的な構成であればインバウンドポートの開放は不要です。

今回の比較において重要な特性が3つあります。第1に、1台のComputerで複数のRuntimeを公開できる点です。SharklyはClaude Code、Codex、Gemini、OpenCode、OpenClaw、Hermesをサポートしており、ローカルサービスが自動検出しないツールについてはカスタムACP Runtimeで対応可能で、1台のComputerが複数のAgentにサービスを提供できます。第2に、分離がTask単位で行われる点です。Temporary（一時）モードではTaskごとに独立したディレクトリが割り当てられ、リポジトリベースの実行では新しいworktreeを使用できるため、並行エージェントによるマージコンフリクトを回避できます。Specified（指定）モードでは、依存関係、キャッシュ、ローカルサービスがすでに整っている設定済みのローカルディレクトリを再利用し、1回に1つの実行を行います。第3に、認証情報の管理権限が手元にある点です。Agentは平文およびシークレットの環境変数を保持し、各実行には許可された環境と認証情報のみが渡されます。また、Personal（個人）公開範囲に設定されたComputerは、その所有者だけが利用できます。

率直に言えば、ホストの管理責任も自前になるというコストがあります。Computerがオフラインになると、新しい実行タスクは再接続されるまで待機します。デスクトップアプリはスリープを防止でき、macOSではシステムが許可していればリッド（画面）を閉じた状態でも動作を継続できますが、長時間に及ぶ無人実行は、コーディングエージェントのリモート実行で論じたように、自社が管理するサーバー上で実行するのが適切です。料金体系は変わりません。ComputerやRuntimeはSharklyのプランのシート数を消費せず、Sharklyがトークンを販売することもありません。Codex Agentは、そのCodex CLIがサインインしているChatGPTプランまたはAPIキーを利用します。

Codex cloudか自前のComputerか：判断基準テーブル

以下の表におけるCodex cloudの項目はすべて、9月30日時点のOpenAIのクラウド環境ドキュメントに基づいています。Computerの項目はSharklyのドキュメントに基づいています。

これを判断の基準ペアとして捉えてください。タスクがCodexの作業であり、依存関係がパブリックまたは許可リスト登録済みのHTTPS経由でアクセス可能で、タスクを開始する人がデスクにいない可能性がある場合は、Codex cloudを使用します。タスクにおいて意図して選択した特定のRuntime、ハードウェア、またはネットワークが必要な場合は、自前のComputerを使用します。

この表から意図的に外している項目が1つあります。それは「社内ネットワーク外に出してはならないデータ」です。自前のComputer上で実行すれば、リポジトリ、キャッシュ、シークレットは手元で制御できるハードウェア内に保持されます。しかし、プロンプトがモデルプロバイダーに送信されるのを防げるわけではありません。Runtimeがモデルに送信するデータは依然として外部へ送られるからです。OpenAIも自社製品において同様の境界線を引いています。Agents APIのドキュメントには「セルフホスト型サンドボックスを選択しても、Agents APIがZDR（Zero Data Retention）の対象になるわけではない」と明記されています。配置場所が決めるのは、コードと認証情報がどこに置かれるかです。データ保持については、モデルプロバイダーとの個別契約の問題となります。

ハイブリッド配置だからこそ管理ボードが真価を発揮する

大半のチームは両方を併用することになるでしょう。スマートフォンからクラウド環境へ手早くCodexの修正作業を投入する一方で、ステージングデータベースを必要とするマイグレーション作業は社内ネットワーク上のComputer内のAgentで実行する、といった運用です。これは極めて合理的な使い分けですが、作業リストが2つに分かれてしまうという結果を生みます。

Codex cloudは、設計上タスクを互いに隔離しています。ドキュメントにある通り、共有セットアップへのアクセス権があっても「他のユーザーのタスクへのアクセス権が付与されるわけではない」のです。プライバシーの観点からはこれが適切なデフォルト設定です。しかしそれは、セットアップは共有されていても作業内容は共有されないことを意味するため、「チームのエージェント作業は今何をしているのか？」という状況を、クラウドタスクとComputerの両方にまたがって把握するには、別の場所で確認しなければなりません。まずはルーティングルールを次のように整理してみましょう。

Where does this Task run?
1. Needs a non-Codex Runtime                          -> Agent on a Computer
2. Needs SSH, a database protocol, or private DNS     -> Computer inside that network
3. Needs GitLab, GitHub Enterprise Server, or browser use -> Computer
4. Codex work, allowlisted HTTPS, started away from a desk -> Codex cloud
5. Someone must accept the result                     -> a Task with an Assignee and a reviewer, wherever it ran

5つ目のルールこそが、この分散した運用を破綻させずに維持するための要です。Sharklyでは、Taskがその記録となります。進捗、実行ログ、ブロッカー、そして結果がすべてTaskに集約され、人間のレビュー待ちとなった実行は担当者の受信トレイ（Inbox）に届きます。同じComputer上のCodex AgentとClaude Code Agentは、それぞれのRuntimeに設定されたモデルに従いながら、同じボードに報告を上げます。Codex cloudで実行された作業については、プルリクエストが連携の架け橋となります。ブランチ名またはPRタイトルにTask IDを含めることで、SharklyのGitHub連携機能がPRを該当Taskに紐付けようとするため、承認作業を一箇所で行うことができます。業務時間を超えて長時間稼働するエージェントに関する記事では、こうした長時間の無人実行におけるレビュー体制について取り上げています。

エージェントが調査、実行、テスト、報告を行い、人間が方針を定め、権限を付与し、成果物を承認する――この役割分担の原則は、実行された場所がどこであろうと変わりません。

これからの環境設計に向けて

Codex cloudは、「Codexをどこで実行すべきか？」に対する優れた答えです。しかし、「あらゆるRuntime上で稼働するエージェントたちのうち、どれが何を担当しており、誰が承認したのか？」に答えるために作られたわけではありません。独自のRuntime、ハードウェア、またはネットワークを必要とする作業にはComputerを手元に残し、スマートフォンから着手する作業やノートPCを閉じたまま進める作業にはCodex cloudを活用し、その両方の記録を1つの場所で一元管理しましょう。

特定の単一エコシステムに囲い込まれることなく、複数のコーディングエージェントを自由に使い続けたい――それこそが、Sharklyが解決するために設計された課題です。