Anthropic 速報｜Codex比較とCopilotコードレビューAPI

codex 比較で最初に分ける三つの軸

今回の更新を一つのランキングにすると、版の公開とレビュー機能の追加、モデルの終了が同じ種類に見えてしまいます。実際には、Codexで見ているのは「どの版が公式リリース欄に載ったか」、Copilotで見ているのは「どの入口からレビューを依頼でき、どの深度を選べるか」、さらにCopilot内では「どのモデルの選択肢が整理されたか」です。製品名が近いからといって、記録する項目まで同じにする必要はありません。

この表の目的は、どの製品が優れているかを決めることではありません。ニュースを読んだあとに同じ確認を繰り返せるよう、公式に書かれた範囲と、自分の環境で確かめる範囲を切り離します。特に先行版の番号は目立つため、番号の増加をそのまま機能差や品質差と解釈しないことが重要です。出典 URL: https://github.com/openai/codex/releases、https://github.blog/changelog/2026-10-02-copilot-code-review-api-support-and-new-default-effort-level/

Codex 0.162.0-alpha.2〜.7は公開事実として読む

OpenAI Codexの公式リリース一覧では、2026年10月2日に 0.162.0-alpha.2 から 0.162.0-alpha.7 まで6件が並び、各項目にPre-releaseの表示があります。本記事が扱うのは10月2日に掲載された6件です。リリース一覧はその後の版が追加されるページなので、閲覧時点で別の項目が見えても、記事の対象日と対象版を混ぜないようにします。

6件を表にするときに大切なのは、版番号の列へ想像した変更内容を足さないことです。公式ページで本文の詳しい変更説明を確認できない項目について、「新機能が増えた」「速度が上がった」「安定した」と書く根拠はありません。alpha.2よりalpha.7の数字が大きいことも、利用者にとっての優先順位や品質を示す指標ではありません。確認できないことを未確認のまま残す方が、次の版と比べるときに記録の信頼性を保てます。出典 URL: https://github.com/openai/codex/releases

公式掲載と手元の結果を別の欄にする

先行版を調べるときは、公式ページを読んだことと、端末でその版を使ったことを同じ記録にしません。公式ページから分かるのは公開日、版番号、Pre-releaseの区分、ページに記載された変更説明です。端末から分かるのは、呼び出された実際の版、作業場所、入力を受け付けたか、返答や差分がどうだったかです。この二つを同じ表に置く場合も、列を分けると推測が入りにくくなります。

手元で確認する項目は、次の順序で残します。

1. 公式リリースページのURL、版番号、公開日、Pre-release表示を記録する。
2. 端末に表示された版と、確認したフォルダーを記録する。
3. 安定版と先行版で同じ小さな読み取りを行い、入力と返答を保存する。
4. 差分、検査結果、採用できるかどうかを、版ごとに分けて記録する。
5. 公式ページに書かれていない機能差、速度、安定性は、確認できるまで未確認とする。

この順序なら、リリース欄に載ったという事実、端末に表示されたという事実、依頼が通ったという事実、結果を採用できるという判断を切り分けられます。たとえば端末にalpha.7と表示されても、それだけでalpha.2より速いとはいえません。対象フォルダー、入力、選んだモデル、確認方法が違えば、観測された差を版の違いだけに帰せないからです。

CopilotコードレビューAPIは入口と深度の更新

GitHub Copilotの2026年10月2日の告知は、コードレビューをREST APIまたはGraphQL APIから依頼できるようになり、依頼ごとにレビューの深度を指定できるという内容です。ここで更新されたのは、版番号の一覧ではなく、レビューを開始する入口と、依頼単位で選ぶ設定です。Codexの先行版6件と同じ表へ置く場合も、「先行版」と「レビュー依頼API」を別の行にし、同じ機能の追加として扱わないようにします。出典 URL: https://github.blog/changelog/2026-10-02-copilot-code-review-api-support-and-new-default-effort-level/

告知では、この変更はCopilot Pro、Pro+、Max、Business、Enterprise向けに一般提供されると説明されています。ただし、製品名が対象に含まれていることと、自分の契約で同じ入口が利用できることは別です。依頼前に利用条件と権限を確認し、返ってきたレビューの深度や内容を記録します。APIを使えることだけを理由に、結果の正確さや検査範囲まで保証されたと考えないことも大切です。

BalancedとLiteの読み方

Defaultのレビュー深度は、2026年9月28日から新規と既存のリポジトリ・組織でBalancedになったと告知されています。以前から設定画面でLiteを明示していた場合は、その選択が尊重されます。この情報は「すべての対象が同じ深度で動く」という意味ではありません。上位の設定、組織の設定、リポジトリの設定、個人の設定のどこで値を管理しているかによって、表示と適用結果が変わり得ます。

設定を確認するときは、次の記録を一組にします。

1. レビューを依頼した入口がRESTかGraphQLかを書き留める。
2. 依頼に深度を明示したか、Defaultへ任せたかを残す。
3. 管理している場所でBalancedまたはLiteが表示されるかを確認する。
4. 同じ変更に対するレビューの指摘、対象範囲、返答時間を保存する。

この記録があれば、レビューの結果が変わったときに、APIの入口、深度、対象変更のどれが影響したかを考えやすくなります。逆に、Balancedという文字だけを見てレビューの深さを評価したり、Liteという文字だけで結果が軽いと決めつけたりするのは早計です。利用者が見るべきなのは設定名ではなく、その設定で対象の変更にどの指摘が返ったかです。出典 URL: https://github.blog/changelog/2026-10-02-copilot-code-review-api-support-and-new-default-effort-level/

Copilotの終了モデルは製品内の情報として分ける

同じ10月2日、GitHubはCopilotの各体験で一部モデルを終了扱いにしたと告知しました。これはCopilot Chat、インライン編集、質問・作業モード、コード補完など、Copilot内の選択肢を読むための情報です。Codexの版番号やOpenAI製品のモデル提供状況へ、そのまま読み替えることはできません。出典 URL: https://github.blog/changelog/2026-10-02-selected-models-in-github-copilot-deprecated/

代替候補が表に示されていても、すべての利用者の画面に同じ候補が現れるとは限りません。告知は、Copilot Enterpriseの管理者がモデルのポリシーで代替モデルへのアクセスを有効にする場合があること、個人の設定で利用可能性を確認できることを説明しています。したがって、モデル名の一覧は「選べることの確定」ではなく、「対象製品で確認すべき候補」として扱います。

ここでCodexとの境界を明確にします。CopilotのGemini、Kimi、Claudeの終了と代替はCopilotのモデル選択に関する更新です。Codexに同じ終了や代替が発生したとは書かず、Codex側はCodex公式のリリース欄や公式案内で別に確認します。異なる製品のモデル名を一つの一覧へ混ぜると、読者が自分の利用場所を取り違えやすくなります。

CursorとAiderは公式の確認先を残す

CursorとAiderは、CodexやCopilotと同じ開発作業の中で話題に上がる製品ですが、今回のCodex比較で確認した公開事実を補う資料ではありません。対象期間の更新を確認するときは、Cursorは公式変更履歴、Aiderは公式リリース一覧をそれぞれ開き、製品名、版番号、公開日、変更本文を個別に読みます。出典 URL: https://cursor.com/changelog、https://github.com/Aider-AI/aider/releases

今回の対象日については、Codexの6件とCopilotの二つの告知を中心に扱い、CursorとAiderから別の新機能を比較表へ追加していません。これは両製品の価値や今後の更新を断定するものではなく、同じ日に別製品の情報を見つけても、Codexの版番号へ合流させないという境界です。次に確認するときは、前回の記録をそのまま現在の状態とみなさず、公式ページに掲載された日付と変更本文を取り直します。

この表を別々に埋めると、CursorやAiderの更新が見つかったときにも、それをCodexの先行版の説明へ書き足さずに済みます。製品を横断して読む場合ほど、同じ言葉が同じ意味とは限らない点に注意が必要です。たとえば「リリース」はCodexでは版番号の公開を指し、Copilotではレビュー入口や設定の案内を指すことがあります。

公式情報を手元の確認へ移す手順

今回のニュースを普段の判断に使うなら、優劣を一度に決めるのではなく、製品、更新の種類、公式の根拠、手元の観測を一行ずつ残します。次の順序なら、Codexの先行版とCopilotのレビューAPIを同じ作業で比べるのではなく、それぞれに合う確認方法を選べます。

1. 製品名を固定する。 Codex、GitHub Copilot、Cursor、Aiderのどれを調べているかを最初の欄に書く。
2. 対象日を固定する。 2026年10月2日に掲載された情報と、後から追加された情報を分ける。
3. 更新の種類を書く。 Codexは版番号と公開区分、CopilotはAPIの入口・レビュー深度・モデル整理として記録する。
4. 公式URLを残す。 一覧ページだけでなく、該当する告知やリリースページへ直接戻れるようにする。
5. 手元の確認を行う。 版表示、設定、APIの利用可否、レビュー結果、モデル選択画面など、製品に合う項目だけを確かめる。
6. 未確認を明示する。 公式に説明がない機能差、速度、安定性、別製品への影響は空欄や未確認として残す。

Codexなら、0.162.0-alpha.2〜.7のどれが表示されているかと、同じ読み取りで何が起きたかを分けます。Copilotなら、RESTとGraphQLのどちらから依頼したか、深度を指定したか、BalancedまたはLiteがどこで適用されたかを分けます。CursorとAiderなら、公式ページの見出しと公開日を製品ごとに記録します。入口の違う情報を同じ一行に詰めないことが、比較を実用的にする最小単位です。

まとめ：codex 比較は確認単位をそろえる

2026年10月2日のCodexでは、0.162.0-alpha.2〜.7の6件が先行版として公式リリース欄に掲載されました。ここから確定できるのは版番号、公開区分、掲載事実です。変更説明が確認できない項目について、機能差、速度、安定性を版番号から補ってはいけません。端末で表示された版、同じ入力の結果、差分、検査結果を別に記録することで、公開と利用結果の境界を保てます。出典 URL: https://github.com/openai/codex/releases

Copilotでは、RESTまたはGraphQLからコードレビューを依頼し、依頼ごとに深度を指定できます。DefaultはBalancedで、Liteを明示していた場合はその設定が尊重されます。終了モデルと代替候補もCopilotの選択肢に関する情報であり、Codexの状態へ読み替えません。出典 URL: https://github.blog/changelog/2026-10-02-copilot-code-review-api-support-and-new-default-effort-level/、https://github.blog/changelog/2026-10-02-selected-models-in-github-copilot-deprecated/

CursorとAiderはそれぞれの変更履歴・リリース一覧を確認先として残し、対象期間に採用する情報があるかを個別に見ます。codex 比較で重要なのは、同じ日に更新が並んだことを一つの機能差にしないことです。製品名、更新の種類、公式に書かれた範囲、手元の結果、未確認事項を分ければ、次の版や告知が出ても記録を続けられます。出典 URL: https://cursor.com/changelog、https://github.com/Aider-AI/aider/releases