OpenAI CodexとGitHubの接続・レビュー手順と料金の選び方

OpenAI CodexとGitHubは何が同じで何が違うか

OpenAI Codexは、リポジトリを読み、ファイルを変更し、必要な確認を進めるAIコーディングエージェントだ。GitHubはコードを置く場所であり、変更をプルリクエストとして提案し、コメントや承認を交わす場所である。両者を組み合わせると、Codexが変更の内容を読み、GitHubの差分と会話の中へレビュー結果を返せる。しかし、GitHubにリポジトリがあるだけで、すべてのCodex機能が使えるわけではない。

OpenAIは、Codexが端末、IDE、Web、GitHubなど開発者が使う場所へ広がってきたと説明している（出典: OpenAIのCodexアップデート）。ここで大切なのは「CodexがGitHubに対応した」という一文を、手元のCLIがGitHubのすべてを操作できるという意味に読み替えないことだ。どの入口で、どのリポジトリを、どの権限で、どの種類の作業に使うのかを分けて考える。

Codexの入口を三つに分ける

最初の入口はCodex CLIやIDE拡張など、手元の開発環境である。自分のブランチや未コミットの差分を見ながら、対象ファイルを限定して調べたり直したりする。二つ目はCodexクラウドで、リポジトリを読み込ませて、まとまった課題を依頼し、結果を差分として確認する。三つ目はGitHub側のOpenAI Codex coding agentで、Issueやプルリクエストに近い場所から作業を頼む入口だ。

この三つは、同じOpenAI Codexという名前でも、対象の保存場所、結果を読む画面、利用条件が異なる。手元のCLIを更新したからGitHub上の入口も同じ版になった、あるいはGitHub Copilotに表示されたモデルがCodex CLIでも選べる、と考えるのは危険だ。記事やメモには、入口の名前を毎回書き、モデル名とクライアント版を別の欄へ残すと混乱しにくい。

版番号・モデル名・サービス入口を分ける

2026年8月7日のOpenAI公式Changelogには、Codex CLI 0.147.0の更新が掲載されている。インストールする版を確認するには、公式Changelogと公式リリース一覧を開き、安定版か試験版かを見たうえで、手元の表示も照合する（出典: OpenAIのCodex Changelog、openai/codexの公式リリース一覧）。

一方、GPT-5.3-CodexやGPT-5.4のような名前はモデルを示す。GitHub DocsのOpenAI Codex案内には、Auto、GPT-5.3-Codex、GPT-5.4、GPT-5.4 nanoが選択肢として記載されているが、これはGitHub側の入口で見えるモデルの説明だ。CLIの版番号と、GitHubの画面に出るモデル名を一つの更新情報として扱わないことが、最初の切り分けになる。

2026年8月7日にGitHub連携を見直す理由

今このテーマを確認する理由は、Codexのクライアントと周辺サービスが短い間隔で更新されているからだ。8月7日には0.147.0がChangelogに載り、直前にはGitHubのリリース一覧でも0.147.0系の試験版や修正版が続いている。更新の中にはWindowsのプロセス処理、日本語文字の表示、プロジェクト確認など、GitHubに限定されない改善も含まれる。だからこそ、版番号だけを見て連携状態まで判断せず、実際の入口と対象リポジトリを確認する価値がある。

OpenAIのGitHub連携資料は、Codexがプルリクエストの差分を読み、深刻な問題に焦点を当てた標準的なレビューを投稿すると説明している。GitHubのPRレビューも、コメント、提案、承認、変更依頼を通じて、マージ前の差分を確認する仕組みだ（出典: OpenAIのGitHubレビュー資料、GitHub DocsのPRレビュー）。現在の確認では、Codexの結果を特別な判定として扱うより、通常のレビュー欄で人が読める材料として扱うのが分かりやすい。

0.147.0を確認するときの見方

まず手元のCodex CLIの版を確認し、公式Changelogにある0.147.0の説明と一致するかを見比べる。記録には、確認した日、表示された版、安定版か試験版か、更新後に変わった操作を分けて書く。Windowsで使う場合は、パスの扱いや端末の入力が以前と同じか、日本語やリンクが崩れていないかを小さなリポジトリで確かめるとよい。

更新手順は利用中の配布方法に合わせる。npmで管理している場合は、公式Changelogに示される版を指定して更新し、続けて版番号を表示する。

npm install -g @openai/codex@0.147.0
codex --version

この確認はCLI側の状態を知るためのものなので、GitHub側のレビュー設定やCopilotのモデル表示を置き換えない。更新後にPRレビューも確認したい場合は、別に小さなPRを用意し、どの入口から結果を受け取ったのかを記録する。

GitHub側の公開プレビューを確認する

GitHub Docsは、OpenAI Codex coding agentとVS CodeのOpenAI Codex拡張を公開プレビューとして案内している。コーディングエージェントは有料Copilotプランが対象で、拡張の「Sign in with Copilot」はPro+とMaxが対象と書かれている。これらはCodexのChatGPTプランやCLIの利用条件とは別なので、GitHubの画面に入口が出ないときは、モデル名を探す前にプランと機能の有効状態を確認する（出典: GitHub DocsのOpenAI Codex）。

公開プレビューは、説明があっても全ユーザーの画面へ同じタイミングで表示されるとは限らない。組織やチームの方針、対象となる契約、利用地域、段階的な提供状況によって表示が変わることがある。確認日と画面の入口を残し、「公式に対応と書かれている」と「自分の環境で選べる」を別の事実として記録する。

GitHubでCodexのレビューを始める準備

GitHubのプルリクエストでCodexを試すときは、大きな変更をいきなり渡さず、差分の意味を人が説明できる一件から始める。OpenAIの資料では、まず対象リポジトリにCodexクラウドを用意し、設定画面でCode reviewを有効にし、PRのコメントからレビューを依頼する流れが示されている。利用前に、リポジトリの所有者、レビューを読める人、変更を戻せる人を確認しておく。

接続の確認は、次の順序で進めると原因が分かりやすい。

1. 対象リポジトリと対象ブランチを一つ選び、PRの変更範囲を小さくする。
2. Codexクラウドで、そのリポジトリを作業対象として選べるか確認する。
3. Codex設定画面でCode reviewが対象リポジトリに対して有効になっているか確認する。
4. PRの本文に、何を変えたか、何を確認済みか、特に見てほしい範囲を短く書く。
5. コメントで@codex reviewと依頼し、返ってきたレビューを差分と照合する。

この順序なら、PRの内容が原因なのか、リポジトリの接続が原因なのか、レビューの依頼方法が原因なのかを切り分けられる。最初の一件では、機能を多く試すことより、入力、返答、確認結果が同じ人に追えることを優先する。

対象リポジトリと権限を先に確認する

Codexが見てよいリポジトリと、変更を返してよいブランチを先に決める。公開リポジトリでも、組織の方針やブランチ保護の設定によって、レビューの依頼者や変更を反映できる人は変わる。最初は読み取りとレビューだけに絞り、修正を反映する段階は別に確認するほうが安全だ。

また、PRに含まれるファイルが本当にレビュー対象かを見る。生成物や大きなロックファイルが差分の大半を占めていると、重要な変更が埋もれる。対象ファイルを分け、変更理由と確認方法をPRに書けば、Codexの指摘も人のレビューも読みやすくなる。

依頼型のレビューを一件で試す

OpenAIの公式資料では、PRのコメントに@codex reviewと書くとCodexが反応し、レビューを投稿する流れが説明されている。最初の試行では、依頼文に「何を直したか」「何を壊したくないか」「どのテストを行ったか」を書く。レビューの対象を広げるために、無関係な相談や複数の目的を同じコメントへ詰め込まない。

レビューが返ったら、まずPRの差分上で指摘された行と周辺のコードを読む。次に、指摘が示した再現条件を手元で確かめ、テストやログなど別の根拠を探す。指摘がなかったことは、問題が存在しない証明ではない。レビューの範囲と、今回確認できなかった範囲をコメントに残すと、次の担当者が判断しやすい。

P0とP1の指摘を承認と混同しない

OpenAIのGitHubレビュー資料では、CodexはP0とP1の高優先度の問題に焦点を当てると説明されている。P0やP1がないことは良い材料だが、すべての品質を保証する結果ではない。仕様の抜け、利用者に伝わる文言、性能の変化、テストの妥当性などは、PRの目的を知る人が別に読む必要がある。

GitHubのレビューには、Comment、Approve、Request changesという判断がある。Codexのコメントを受け取っただけでApproveへ進めず、指摘を採用したか、見送ったか、追加の確認が必要かを人が決める。承認を出す人と変更を作る人が同じ場合でも、判断の根拠を短く残しておくと、後から差分を見直しやすい。

OpenAI CodexとGitHub Copilotの入口を選び分ける

「OpenAI CodexをGitHubで使う」という検索語には、少なくとも二つの意味がある。一つはCodexクラウドをGitHubリポジトリへ接続し、PRの差分をレビューしてもらう使い方。もう一つはGitHub Copilotの画面からOpenAI Codex coding agentやVS Code拡張を使う使い方だ。前者はCodex側のプランと設定、後者はGitHub側のプランと機能条件を確認する。

両者を比べるときは、同じ作業を同じ入口で試し、どの画面で何ができたかを記録する。Codexの利用上限、Copilotの利用量、表示モデル、PRへ返る結果は別々に管理される。ひとつのサービスで使えたことから、もう一方も使えると判断しないことが、接続トラブルと請求の読み違いを減らす。

CodexクラウドでPRを確認する場合

PRの差分やリポジトリ方針を中心にレビューしたいなら、Codexクラウド側のGitHub連携を使う。OpenAIの資料では、Codexは差分とリポジトリの案内を読み、高優先度の問題を標準的なGitHubレビューとして投稿する位置づけだ。人のレビュー欄でコメントを読み、必要に応じて修正を依頼し、変更後の差分をもう一度確認するという使い方に向く。

この入口では、リポジトリに置いたAGENTS.mdでレビュー観点を伝えることもできる。規約を長く並べるより、「互換性を壊す変更を指摘する」「外部入力の境界を確認する」「必要なテストがない場合は理由を示す」のように、結果を判定できる短いルールを置くほうが扱いやすい。ルールはCodexの判断を補助するもので、テストや人の承認を置き換えるものではない。

GitHub Copilot経由で作業を頼む場合

GitHub Docsの案内では、OpenAI Codex coding agentを使う際に、Auto、GPT-5.3-Codex、GPT-5.4、GPT-5.4 nanoからモデルを選べる。Autoを選ぶと、利用可能性や制限状況を踏まえてCopilot側がモデルを選ぶため、固定モデルを選んだ結果とは分けて記録する。表示モデルが少ない場合は、まず入口、契約、機能の有効状態を確かめる。

VS Code拡張から「Sign in with Copilot」を使う場合は、GitHub Docsにある対象プランの説明を確認する。コーディングエージェントと拡張では対象条件が同じではないため、Copilotが契約済みでも、拡張の入口や特定のモデルが表示されない場合がある。画面のどこから作業を始めたかを記録すれば、OpenAI Codexの不具合とGitHub側の条件を混ぜずに済む。

Cursorや手元のCLIと比べる場合

GitHub連携の良し悪しを知りたいときは、モデル名だけを比べるのではなく、同じリポジトリの小さな修正を一件ずつ渡す。Codexクラウド、GitHub Copilot経由、手元のCLIで、対象ファイル、依頼文、確認するテスト、変更を戻す基準を揃える。結果の違いが入口の差なのか、モデルの差なのか、読み込んだ文脈の差なのかを後から追えるようにする。

比較では、速さだけを勝敗にしない。変更範囲が狭いか、既存の書き方に合っているか、テスト結果を説明できるか、指摘を人が再現できるかも見る。GitHubのPRへ結果を残せることは利点だが、レビュー欄の情報量が増えるほど、重要な指摘を拾う基準も必要になる。

接続後に起きやすい問題を切り分ける

CodexがGitHub上で反応しないときは、利用不可とすぐに決めず、確認した場所を順に戻る。OpenAIの公式資料が示す基本条件は、対象リポジトリがCodexクラウドで用意されていること、Code reviewが設定で有効になっていること、依頼コメントの書式が正しいことだ。GitHub側のプランや公開プレビュー条件も別にあるため、ひとつのエラー表示から原因を広げて推測しない。

問題の切り分けでは、確認結果を「確認済み」「未確認」「対象外」に分ける。たとえば、リポジトリの接続は確認済みでも、組織の方針は未確認という状態がある。未確認を利用不可と書かないだけで、次に見るべき画面が明確になり、同じ調査を繰り返さずに済む。

レビューが返らないとき

最初にPRが対象リポジトリにあるか、Codexクラウドの環境がそのリポジトリを指しているかを確認する。次に設定画面でCode reviewの状態を見て、依頼コメントが@codex reviewの正確な表記になっているかを確かめる。反応がない場合は、PRの差分を大幅に減らしたテスト用の一件を作り、同じ順序を再確認すると原因を狭めやすい。

依頼者にレビューを出す権限があるか、対象ブランチの制限で結果を投稿できない状態になっていないかも見る。GitHubのレビューはリポジトリの設定や権限に影響される。Codexだけを再起動するより、GitHubのPR画面、Codex設定、対象リポジトリの三か所を同じ確認日時で記録するほうが有効だ。

指摘を修正へつなぐとき

指摘に対応する場合は、最初にその指摘が再現するかを確認し、次に変更するファイルと変更しないファイルを決める。Codexへ修正を頼む場合でも、PRのコメントに対象の指摘、期待する結果、実行する確認方法を書き、範囲を限定する。修正後は新しい差分を読み、元の指摘が消えたかだけでなく、別の振る舞いが変わっていないかを見る。

修正結果をそのまま承認に回さず、必要なテストを実行し、PRの会話に確認結果を残す。GitHub Docsも、レビューコメントの意図を理解してから変更し、更新後に再度レビューを依頼する考え方を示している（出典: GitHub Docsのレビュー解決方法）。レビューと修正を短い往復に区切れば、どの変更がどの指摘に対応したかが追いやすい。

モデルが表示されないとき

モデルが見えない場合は、まずCodexクラウド、GitHub Copilotのコーディングエージェント、VS Code拡張のどれを使っているかを決める。次にその入口に対応する公式資料で、対象プラン、公開プレビューの状態、利用できるモデルを確認する。GPT-5.3-CodexがOpenAIのモデル情報にあることと、自分のGitHub画面で選べることは別なので、表示結果を根拠として残す。

同じ作業を別入口で行う場合は、モデル名を手入力しただけか、選択欄から実際に選んだかも区別する。Autoを使った場合は、どのモデルが選ばれたかをサービス側で確認できないこともあるため、固定モデルの結果と同じ表へ混ぜない。版番号、モデル名、入口、確認日を一つずつ記録すれば、更新後の比較が可能になる。

OpenAI CodexとGitHubの料金・利用量を考える

料金を比べるとき、ChatGPTのCodex利用とGitHub Copilotの利用を同じ月額表だけで判断しない。OpenAIの案内では、Codexの利用量は作業の大きさ、複雑さ、モデル、実行場所によって変わると説明されている。小さな修正と大きなリポジトリの調査では、同じ入口でも消費する量が異なるため、作業単位で記録する必要がある（出典: OpenAIのCodex利用プラン案内）。

GitHub Copilot経由では、Copilot側のプラン、利用できるモデル、レート制限、拡張かコーディングエージェントかという入口が判断材料になる。OpenAI Codexの直接利用と、GitHubの契約に含まれるCodex利用は、同じモデル名が見えても請求や上限を同じ方法で計算できるとは限らない。現在の料金と利用条件は変わるため、記事の数字を固定せず、利用時点の公式ページを確認する。

比較する項目を先に揃える

一件の作業を比べるなら、次の項目を同じ形式でメモする。

1. 利用した入口（Codex CLI、Codexクラウド、GitHub Copilot、VS Code拡張）。
2. 選択したモデル名、またはAutoを選んだこと。
3. 対象ファイル数、変更行数、作業の開始と終了の時刻。
4. 実行したテスト、レビューの指摘数、修正の回数。
5. 利用量の表示、上限に近づいたか、追加費用が発生したか。

この記録があれば、「安いから常に得」「新しいモデルだから常に速い」といった判断を避けられる。レビューだけを頼みたい日と、複数ファイルを変更したい日では、適した入口も利用量も違う。結果を同じ表へ置き、作業の種類ごとに判断する。

少額の確認から始める

初めてGitHub連携を使う場合は、変更対象が少なく、確認方法が明確なPRを選ぶ。既存のテストがあり、差分の目的を一文で説明できる修正なら、レビュー結果と実際の不具合の有無を比べやすい。大きな移行や複数サービスをまたぐ変更を最初に選ぶと、利用量、待ち時間、レビューの妥当性を別々に測れなくなる。

料金の判断は、一回の結果ではなく数件の記録から行う。Codexが指摘を返した回数、追加の確認にかかった時間、修正を戻した回数を見て、月額と利用量を合わせて考える。利用上限が近いときは、モデルを替える前に対象範囲を小さくできるか、確認を先に済ませられるかを検討する。

まとめ：GitHubでは差分・根拠・入口を残す

OpenAI CodexとGitHubの組み合わせを理解する鍵は、Codexの版番号、モデル名、GitHub上の入口を一つにまとめないことだ。2026年8月7日にCodex CLI 0.147.0が公開された今も、CLIの更新とGitHubのPRレビュー設定は別に確認する。GitHub Docsが案内するOpenAI Codex coding agentも公開プレビューであり、契約、入口、表示モデルの条件を画面で照合する必要がある。

最初の一件では、対象リポジトリと差分を小さくし、@codex reviewで結果を受け取り、P0/P1の指摘を人が再現する。修正を頼む場合も、変更後の差分とテストを読み直してから判断する。料金は月額だけでなく、作業量、モデル、利用入口、利用量を同じ記録へ置いて考える。この三つを守れば、GitHubの連携を試すときも、Codexの更新を追うときも、判断の根拠を後から確認できる。

最初の一件で残すチェック

最後に、記録へ残す内容を短くまとめる。対象リポジトリ、PR番号、Codexの入口、CLIや拡張の版、モデル名、依頼文、レビュー結果、実行したテスト、最終判断の順に書けば、同じ条件で再確認できる。公式資料のURLと確認日も添え、画面に表示された事実と自分の評価を分けておく。

次に同じ連携を使う人が、どの条件ならレビューを依頼でき、どの指摘を追加確認するべきか分かる状態が理想だ。Codexの更新が続くほど、過去の成功例をそのまま現在の保証にせず、ChangelogとGitHub Docsを開いて入口と利用条件を見直す習慣が役に立つ。