ChatGPT、Codex CLI、Codex Appをどうつなぐか GitHubを作業の中継点にする

ChatGPT、Codex CLI、Codex Appを直接つながっている前提で扱わず、GitHub Issue、PR、ブランチ、HANDOFF.mdを中継点にする運用を整理します。

この記事の要点

ブラウザ版のChatGPT、Codex CLI、Codex App。並べると同じAI体験の入口に見える。だが、実際にコードや会話が処理される場所はそれぞれ違う。ブラウザの会話、ローカルの端末、デスクトップアプリ、GitHub、各種コネクタ、MCP、APIの設定。境界はばらばらに引かれている。

ChatGPTで方針を固めても、手元の作業ディレクトリが勝手に書き換わるわけではない。Codex CLIでファイルを直しても、その意図がブラウザの会話へ自然に戻ってくるわけでもない。

これらを「裏でつながっている」前提で動かすと、いまどこに最新の状態があるのかが、すぐに分からなくなる。

ChatGPTが向くのは、企画、論点の整理、Issue本文の下書き、レビューで見る観点の洗い出し、読者像の整理だ。リポジトリを読む接続があったとしても、作業の成果をどこに保存するかは、別に考えておく。

OpenAIのヘルプの説明では、ChatGPT側のGitHub接続は、リポジトリを読んで分析・検索するためのものと案内されている。コードの生成や編集、pushはCodex側の役割として分けられている。

だとすれば、ChatGPTの会話で決めたことは、Issue、PRコメント、HANDOFF.mdのように、後から共有できる場所へ書き出しておくほうが活きる。

Codex CLIは、ローカル端末で指定したディレクトリのコードを読み、編集し、コマンドを実行する側だ。テストを流し、差分を見て、コミットまで進める作業に向く。

手元で動くということは、その端末のファイル構成、認証、サンドボックス、承認モード、ネットワークの制限を、そのまま受けるということでもある。ブラウザの会話の身軽さとは、別の制約がついてくる。

だからCLIで進めた結果は、ブランチ、コミット、PR、テスト結果として残す。「完了した」を会話の中だけに置いておかない。

Codex Appは、デスクトップ上でGit作業、差分の確認、スレッドの管理、アプリ連携を扱う側になる。ただし、App側のコネクタや接続サービスが、Codex CLI側でも同じように見えるかどうかは、プラン、ワークスペースの設定、時期、実装によって変わりうる。

OpenAIのヘルプでは、一部の接続サービスがChatGPTとCodexの間で使えるようになる例も挙げられている。その一方で、会話自体は分かれていて、使える機能や権限は管理側の設定に左右される。

確かめられていない接続を、同じものとして扱わないことだ。Gmail、Drive、Slack、GitHubのような接続を前提に組むなら、それがApp側なのかCLI側なのか、MCP経由か、APIに直接設定したものか、OAuthとトークンをどこで管理しているのかを、一つずつ見ておく。

ツール同士を直接つなごうとするほど、どこからどこまでが誰の責任なのか、境界がぼやける。代わりに、GitHubを真ん中の中継点として使う。ChatGPTでIssueを書く。Codex CLIでブランチを切って実装する。Codex AppやWebで差分を確かめる。PRでレビューする。

GitHubのIssueは依頼の内容を残す。PRは差分と検証を残す。ブランチは作業の単位を残す。HANDOFF.mdは途中の状態を残す。どのAIが読んでも、人間が読んでも、同じ場所を指せる。

AIツール同士を魔法のように直結させるより、GitHubへ作業の状態を寄せておくほうが、事故は少ない。

便利な接続は、確かに作業を速くする。ただ企業で使う以上、どのツールがどのデータを読めたのか、どの権限で操作したのか、ログはどこに残ったのか。これを後から説明する場面が、いずれ来る。

ChatGPT、Codex CLI、Codex Appをつなぐというのは、記憶や権限をひとつに溶かし合わせることではない。企画、実装、レビュー、引き継ぎを、GitHubとファイルという「後から追える形」で結び直すことだ。

閉域AI、社内データ活用、拠点間ネットワーク、音声・録音データ、クラウド接続など、AIを業務環境に組み込むためのインフラ構成についてご相談ください。

既存ネットワーク、PBX、データセンター、業務システムとの接続を前提に、実装しやすい構成を整理します。

要件を相談する