Codexの速度を測る方法｜0.155.0先行版の更新前後比較

0.155.0 alpha系列の公開事実と速度を分ける

最初に確定できるのは、0.155.0 alpha系列が公開されたことと、それが先行版として表示されていることです。OpenAI Codexの公式リリースページでは、alpha.2はPre-releaseとして2026年9月10日18:02 UTCに公開され、alpha.3.9は同11日11:51 UTCに公開されています。日本時間ではそれぞれ9月11日03:02、20:51です。出典 URL: https://github.com/openai/codex/releases/tag/rust-v0.155.0-alpha.2、https://github.com/openai/codex/releases/tag/rust-v0.155.0-alpha.3.9

一方、公式ページに速度の実測値、更新前の基準値、同じ入力での比較結果はありません。版番号が連続していることから「返答が速くなった」「作業が短くなった」とは判定できません。先行版を試す場合も、公開された版の記録と、自分の端末で測った値を別の欄に置くことが、後から読み返せる記事と計測表の前提になります。

先行版の版番号を測定表に残す

測定表には、単に「0.155.0」と書くのではなく、alpha.2やalpha.3.9まで含めた版番号、確認した時刻、使った入口を残します。先行版と安定版を同じ行へまとめると、どの公開物を試した結果か分からなくなるからです。版番号は結果の理由を決める材料ではなく、条件を特定する識別子として使います。

公式本文にない差を補わない

公式本文が速度を説明していないときは、短い返事を見ただけで改善を補いません。ネットワークの状態、選んだモデル、入力の長さ、対象ファイルの数、端末の負荷が変われば、同じ版でも時間は動きます。書かれていない性能差は「未確認」と残し、読者が同じ条件で試せる部分だけを記事にします。

更新前後でそろえる比較条件

codex 速度の比較で最も大切なのは、測定を始める前に条件を固定することです。更新前と更新後で製品、入口、版、モデル、入力、対象、端末、開始点のどれかが違えば、得られた時間は単純な更新差ではありません。まず一つの作業を選び、同じ作業を同じ順番で繰り返せる形にします。

版とモデルを同じ欄で確認する

版番号とモデル名は似たように見えても、意味が違います。版番号は利用している製品の公開物を示し、モデル名はその作業で選んだ処理系を示します。更新前後で版だけを変えるならモデル名を固定し、モデルを変えるなら別の比較として記録します。どちらも変えた結果を一つの速度差として発表しないことが重要です。

画面に新しいモデル名が表示された場合も、表示されたこと、選択できたこと、作業が完了したことを分けます。選択欄に出たという事実は、すべての利用条件や作業で同じ結果になることを保証しません。表示確認と処理時間を別の列に置けば、見えた機能と測った値が混ざりません。

入力・対象・開始点を固定する

同じ依頼文でも、読み込ませるファイルが一つから十個へ増えれば、返答までの時間も確認にかかる手間も変わります。短い読み取り、複数ファイルの変更、調査を別の作業として用意し、それぞれの対象と初期状態を保存します。更新前にだけ準備作業を行った場合は、その時間を結果へ隠さず別欄へ残します。

比較する日は、まず更新前の値を一度記録してから版を変えます。作業場所の初期状態、未保存の変更、開いている画面が違うと、同じ入力でも別の測定になります。開始時点をそろえられなかった計測は失敗ではなく「条件不一致」として扱い、無理に平均へ入れないようにします。

最初の応答・完了・結果確認を別に測る

利用者が「速い」と感じる時間には、少なくとも三つの区間があります。入力を送って最初の応答が見えるまで、作業結果が出るまで、出力や変更を人が確認して終えるまでです。最初の応答だけが短くても、完了や確認に長くかかるなら、作業全体が短くなったとは言えません。

短い読み取りから始める

最初の測定は、対象ファイルを一つ読む、決めた文字列を探すなど、結果を確認しやすい作業にします。短い作業なら、応答が見えるまでと完了までの境界を観察しやすく、端末や入力の違いも見つけやすくなります。その後に複数ファイルの変更や調査を追加し、同じ区間をもう一度測ります。

長い作業をいきなり比べると、待っている間の画面操作、追加質問、対象の読み込み、結果の確認が一つに見えます。各区間の時刻を残し、区間ごとの値を並べてから合計を見ます。読者へ示すときも、単一の「速度」という数字だけでなく、何を終点としたかを添えてください。

再試行を成功時間へ隠さない

一回目が途中で止まったり、結果の確認でやり直したりした場合は、最初の応答時間を消さず、再試行の回数と理由を残します。再試行後の最終結果だけを採用すると、実際に使った時間より短く見えます。更新前後で再試行の有無が違うなら、それ自体が利用上の重要な差です。

確認時間も結果の一部です。変更ファイルが多くて差分を読む時間が増えたなら、応答が速くても作業の負担は減っていません。最初の応答、完了、確認、再試行を別の列にすれば、どの段階が変わったのかを説明できます。

速さと正しさを同じ数字にしない

時間の比較だけでは、早く返った結果がそのまま使えるか分かりません。変更ファイル数、読み取り結果、テストや確認の結果、修正の回数を別に記録します。特に更新直後は、返答の早さと内容の正しさが同じ方向へ動くとは限らないため、速さの表に品質の判定を混ぜないことが大切です。

早い返答を成功と判定しない

最初の応答が早くても、依頼した対象を読んでいない、変更範囲が広がっている、確認で誤りが見つかるなら成功とは判定しません。速度欄には測った秒数を残し、判定欄には「採用」「要確認」「条件不一致」など、結果を読んだ後の状態を書きます。これにより、短い待ち時間がそのまま良い結果だという誤解を防げます。

同じ作業を複数回試したときは、平均値だけでなく各回の値と結果を並べます。一回だけ極端に短い値が出ても、再現しなければ更新後の代表値にしません。利用者が知りたいのは記録上の最小値ではなく、同じ条件で何度試してどの程度安定して終わったかです。

同じ作業量で結果を比べる

更新前は一つのファイル、更新後は複数ファイルという比較では、版の違いと作業量の違いを分離できません。まず同じ対象で比べ、次に作業量を増やした別の表を作ります。表を分けることで、短い読み取りの反応と、大きな変更での確認負担をそれぞれ説明できます。

結果の正しさを確認できない計測は、速度の参考値としても注意書きを付けます。未確認の項目を成功に数えず、確認できなかった理由と次に見る条件を残してください。これは版の優劣を決めるためではなく、自分の作業にどの更新が合うかを判断するための記録です。

Python SDK 0.154.0は観測欄として分ける

Python SDK 0.154.0の公式リリースには、maxとultraの推論の強さ、ExternalMessage、履歴の取得範囲、ターン単位のサービス指定、sourceメタデータ、通知モデルの更新が記載されています。これらは呼び出しや履歴の見え方を整理する変更で、Codexの処理時間が何秒短くなったという発表ではありません。速度の測定表へそのまま足さず、観測方法の欄に分けます。出典 URL: https://github.com/openai/codex/releases/tag/python-v0.154.0

たとえばExternalMessageは同期・非同期のrun()とturn()へ外部の内容を渡すための型で、通常のターンを開始したり、進行中のターンへ加わったりできます。公式本文は独立したイベントの流れを受け取ることも説明していますが、これだけで応答時間が短くなるとは書いていません。入力の受け取り方が変わった場合は、同じ依頼を送った時刻と、どのイベントを終点にしたかを記録します。

履歴と応答の範囲を記録する

include_turnsは再開や分岐で返される履歴の範囲に関係します。公式本文は、履歴の選択が返される応答を変える一方、モデルの文脈自体を変えないと説明しています。したがって、返答の文字数や取得時間が変わったときも、履歴範囲の差と処理速度の差を別に記録します。保存した履歴を後から読む時間も、作業確認の一部として残します。

通知が以前より細かく見えるようになった場合、終了時刻の決め方も見直します。ターン開始、途中の通知、完了通知のどれを「最初の応答」や「作業完了」とするかを先に決め、更新前後で同じ終点を使います。終点が変わったのに秒数だけを比べると、測定方法の変更を速度差と誤認します。

変更を速度の証拠にしない

SDKの更新欄に新しい型や通知が増えたことは、読者が観測できる情報の範囲が広がったことを示します。これは有用な変更ですが、版の公開ページに処理時間の数値がなければ、速度改善の証拠にはなりません。速度の欄には実際の開始・終了時刻を置き、SDKの欄には入力、履歴、通知の違いを置くという分担を守ります。

Copilot CLI・Cursor・Aiderは製品ごとに見る

周辺製品の更新を同じ記事で扱う場合も、Codexの計測結果へ置き換えません。GitHub Copilot CLI 1.0.84-4はコマンド名の整理、一覧表示の変更、Windows ReFS上の検索に関する更新を含む先行版です。Cursorの公式更新欄はProjectsの文脈共有や複数の作業担当を案内し、Aiderは公式リリース欄で版ごとの変更を確認できます。どれもCodex 0.155.0の速度値ではありません。出典 URL: https://github.com/github/copilot-cli/releases/tag/v1.0.84-4、https://cursor.com/changelog、https://github.com/Aider-AI/aider/releases

Copilot CLIの変更はCopilotの測定欄へ

Copilot CLIの更新で操作名が変わった場合は、一覧を開くまで、目的の項目を表示するまで、実際の作業を確認するまでをCopilotの表へ記録します。Windows ReFS上の検索が更新されても、その検索時間をCodexの最初の応答と同じ指標にはしません。入口、製品、作業の終点が違う値を一つの順位へ並べないことが境界を守る方法です。出典 URL: https://github.com/github/copilot-cli/releases/tag/v1.0.84-4

CursorとAiderの公開欄を別に確認する

CursorのProjectsは、長期間の文脈、複数の担当、クラウドとローカルの作業を扱う更新として説明されています。これは同じような作業を整理する際の比較材料になりますが、Codexの版やモデルの性能を示すものではありません。Aiderも公式リリース欄の版番号と変更本文を確認し、使った製品の結果として別表へ残します。出典 URL: https://cursor.com/changelog、https://github.com/Aider-AI/aider/releases

まとめ: codex 速度を判断する記録の最小単位

0.155.0 alpha系列について、公式ページから言えるのは先行版が公開されたことまでです。速度を判断するには、更新前後で同じ入口、版、モデル、入力、対象、端末、開始点をそろえ、最初の応答、作業完了、結果確認、再試行を別々に測ります。早い値が出ても、結果を確認できなければ採用できる速度とは判定しません。

Python SDK 0.154.0の型・履歴・通知の更新、Copilot CLIの操作変更、CursorやAiderの公式更新は、観測する場所を整えるための周辺情報です。Codexの速度表と製品別の更新欄を分ければ、公開された変更、手元で測った時間、作業結果の正しさを一つの印象へまとめずに済みます。自分の端末で同じ条件を繰り返せる記録を残すことが、codex 速度を更新前後で判断する最小単位です。