【Codex】⑭　ChatGPT Work ::会話からコードを作り、GitHubへ反映する――Codex Cloudとは何が違うのか

■ChatGPT Work：会話によるコード生成、一時的な作業環境とGitHub連携

■Codex Cloud：専用コンテナ作成、ブランチまたはコミットをcheckoutしコード編集＆テスト

ChatGPT　Work	Codex Cloud
この会話用の一時環境でコード作成	リポジトリ専用のクラウド環境で作業
必要ファイルをGitHubから個別に取得	Gitリポジトリ全体をcheckout
GitHub連携でコミットを直接作成	通常は変更差分をレビューしてPR作成
環境設定は会話側に依存	setup scriptや環境変数をリポジトリ別に設定
会話終了後の作業環境は恒久的ではない	長時間・バックグラウンド・並列作業向け

はじめに
今回、実際に何を行ったのか
「GitHubへpushした」と言ってよいのか
Codex Cloudとは何が違うのか
最大の違いは「リポジトリ全体を作業環境として持つか」
今回の方式の利点
注意点と改善すべき運用
Prj.JARVISでの推奨する使い分け
まとめ

はじめに

Prj.JARVISとMiTiR-Baseの連携開発を進めるなかで、少し意外なことが起きた。

ChatGPT上の会話で、MiTiR側のOpenAPI仕様を読み取り、JARVIS側のAPIクライアントとcontract testを作成し、テストを実行した。その後、作成したコードをGitHubのJARVISリポジトリへ反映したのである。

ここで疑問が生じる。

これはCodex Cloudで開発したことになるのか。それとも別の仕組みなのか。

結論から言えば、今回の作業はCodex Cloudの正式なクラウドタスクではない。ChatGPT Workの会話内に用意された一時的な実行環境でコードを作り、GitHub連携を通してリポジトリへコミットを反映したものである。

両者は似ているが、開発環境の作り方、リポジトリの扱い、レビュー方法、得意な作業が異なる。本稿では、実際のJARVIS開発を例に、その違いと使い分けを整理する。

今回、実際に何を行ったのか

対象は、WindowsノートPCで稼働する個人AI秘書「Prj.JARVIS」と、Mac mini上の専門業務基盤「MiTiR-Base」の連携部分である。

まず、MiTiR-Baseリポジトリを読み取り専用で参照し、次の二つを確認した。

docs/from-MiTiR.md：MiTiR側からJARVIS側への連絡事項
docs/api/jarvis-mitir-openapi.yaml：MiTiR Integration API v0.1.0の正式契約

OpenAPIには、次の操作が定義されていた。

GET /health：稼働確認
GET /capabilities：利用可能な機能一覧
POST /tasks：非同期タスクの受付
GET /tasks/{id}：進捗と結果の取得
POST /tasks/{id}/cancel：タスク取消

さらに、Bearer認証、Idempotency-Keyによる重複実行防止、新規受付時のHTTP 202、同一リクエスト再送時のHTTP 200、内容が異なる再送時のHTTP 409などが定義されていた。

この契約を基に、会話内の一時作業環境で以下を作成した。

JARVIS用MiTiR APIクライアント
Pydanticによるリクエスト・レスポンスモデル
Bearer認証処理
タイムアウトと限定的な再試行
タスク作成、状態確認、取消処理
APIエラーと通信エラーの分離
OpenAPI契約のスナップショット
7件のconsumer contract test

テストは一時環境内で実行し、7件すべてが成功した。その後、複数の変更ファイルを一つのGitコミットとして構成し、JARVISリポジトリのmainブランチへ反映した。

実際のコミットは以下で確認できる。

JARVIS：MiTiR APIクライアントとcontract testの追加

「GitHubへpushした」と言ってよいのか

結果としては、pushしたのと同じ状態になっている。ただし、通常の開発PCで次のコマンドを実行したわけではない。

git add .
git commit -m "feat: add MiTiR API client and contract tests"
git push origin main

今回は、GitHub連携を通じて次のGitオブジェクトをGitHub上に作成した。

各ファイルのblob
変更後のtree
親コミットを指定した新しいcommit
mainブランチの参照先更新

したがって、ローカルでgit pushコマンドを実行してはいないが、GitHub側では通常のpush後と同様に、新しいコミットがmainブランチの先端になっている。

重要なのは、WindowsノートPC上の作業フォルダが自動更新されるわけではない点である。GitHubに反映された変更をローカルへ取り込むには、Windows側で次を実行する必要がある。

git pull origin main

つまり、GitHubが中央の正本となり、会話内の作業環境とWindowsのローカル環境は、それぞれGitHubを介して同期される。

Codex Cloudとは何が違うのか

Codex Cloudは、GitHubリポジトリと結び付いた専用のクラウド開発環境である。公式ドキュメントによれば、タスク開始時に分離されたコンテナを作成し、選択したブランチまたはコミットをcheckoutする。その後、セットアップスクリプトを実行し、コードの編集、コマンド実行、検証を行い、最後に変更差分を提示する。Codex Cloud環境の公式説明

今回の会話内開発との違いは次のとおりである。

比較項目	ChatGPT Work	Codex Cloud
作業の起点	ChatGPTでの設計・相談	Codexのクラウドタスク
実行環境	会話用の一時作業環境	リポジトリ別に構成した専用コンテナ
リポジトリ取得	必要なファイルをGitHub連携で参照	ブランチまたはコミットをcheckout
環境構築	会話環境の利用可能ツールに依存	setup script、環境変数、依存関係を設定可能
変更確認	会話内の報告とGitHubコミット	summaryとdiffを確認してPRへ進める
長時間処理	比較的小規模な作業向き	バックグラウンド・並列作業向き
ローカルPC	直接変更しない	同じく直接変更しない

公式には、Codexの実行場所としてLocal、Worktree、Cloudが区別されている。LocalとWorktreeは自分のコンピューター上で動き、Cloudは構成済みのリモート環境で動く。Codex environmentsの公式説明

最大の違いは「リポジトリ全体を作業環境として持つか」

両者の本質的な違いは、単にクラウド上で動くかどうかではない。

今回の会話内開発でも、コードはクラウド上の一時環境で作成された。しかしCodex Cloudでは、対象リポジトリをcheckoutし、プロジェクト固有の依存関係、環境変数、セットアップ手順を備えた再現可能な開発環境を構成する。

Codex Cloudは、リポジトリにAGENTS.mdがあれば、そこに記載されたプロジェクト固有のLintやテスト手順も参照して作業する。環境設定により、依存パッケージ、ツール、インターネットアクセスなども管理できる。Codex Cloud環境の公式説明

一方、会話内開発は、設計相談からそのまま小さな実装へ移れる機動性が高い。複数リポジトリの仕様を比較したり、OpenAPIを読みながらクライアントのひな型を作ったりする作業に向いている。

今回の方式の利点

今回のJARVIS開発では、次の利点があった。

1. 設計相談から実装まで連続して進められる

JARVISとMiTiRの責務分担、相互リポジトリの書き込み制限、OpenAPI契約の方針を会話で整理し、そのままコードへ落とし込めた。

2. 複数リポジトリを安全に参照できる

JARVISは書き込み対象、MiTiRは読み取り専用という境界を維持しながら、MiTiRの契約をJARVISクライアントへ反映できた。

3. ローカルPCを起動していなくてもGitHubへ反映できる

WindowsノートPC上でVS Codeを開いていなくても、GitHub上のJARVISリポジトリへ変更を記録できる。

4. 小規模な契約追従が速い

OpenAPIの変更を確認し、型モデル、クライアント、contract testを一体で更新するような作業には効率がよい。

注意点と改善すべき運用

一方で、今回の方法には注意点もある。

mainへ直接反映しない

今回はmainブランチへ直接コミットした。しかし、本格開発では作業ブランチを作り、差分確認、テスト、レビュー後にPRをマージする方が安全である。

推奨フローは次のとおりである。

仕様確認
  ↓
作業ブランチ作成
  ↓
コードとテストの作成
  ↓
差分・テスト結果の確認
  ↓
Draft PR作成
  ↓
レビュー後にmainへマージ

実機テストは別途必要

一時環境でcontract testが通っても、WindowsノートPCからTailscale経由でMac miniへ到達できることまでは保証されない。

次の確認は実機で行う必要がある。

WindowsからMac miniのTailscaleホストへ到達できるか
MiTiRのポートがTailscale側で公開されているか
MITIR_INTEGRATION_TOKENが両側で一致しているか
Windowsのファイアウォールやプロキシが通信を妨げないか
実際のMiTiR応答がOpenAPI v0.1.0と一致するか

ローカルの未コミット変更との衝突に注意する

GitHub上で先に変更した場合、Windows側に未コミット変更があると、git pull時に競合する可能性がある。pull前に必ず次を確認する。

git status

未コミット変更がなければ、次を実行する。

git pull origin main

Prj.JARVISでの推奨する使い分け

今後は、四つの作業場所を役割で分けるとよい。

作業場所	主な役割
ChatGPT Workの会話	全体設計、MiTiRとの仕様調整、技術調査、小規模修正
Codex Cloud	リポジトリ全体を使う実装、長時間テスト、複数案の並列検討、PR作成
WindowsノートPC＋VS Code Codex	JARVIS本体開発、UI、音声、Windows操作、実機確認
Mac mini＋Codex	MiTiR、Ollama、専門エージェント、バックグラウンド処理の実機確認

特にJARVISとMiTiRの連携では、次の流れが安定する。