Codexモデルを選ぶ前に：GPT-5.3-Codex・5.2・5.1のコストと互換性を見る

3行まとめ

Model

5.3/5.2/5.1/5を見る。

Endpoint

API経路を確認。

Context

入力と出力上限。

Cost

input/output/tool fee。

Snapshot

固定とdeprecated。

Benchmark

小さく比較。

最新名だけでなく、運用で固定する項目を先に見ます。

• Codex系モデルは、最新名だけで選ばず、capability、endpoint、context、max output、cost、snapshot/deprecated表示を分けて確認します。
• 新規評価ではGPT-5.3-Codexを基準にしやすい一方、既存workflowではGPT-5.2-Codex、GPT-5.1-Codex、GPT-5-Codexからの切替リスクも見ます。
• 400k contextや128k max outputは強い条件ですが、常に全部使う前提にしません。PR review、test repair、long-horizon refactorの3タスクで小さく比較します。

本文の事実確認には、OpenAI API公式モデルページ、All models、pricing関連の公式記述を使っています。モデル名、価格、deprecated表示、rate limitは変わり得るため、2026年6月1日時点の確認として扱います。

この記事でわかること

New eval

新規評価の基準。

Compatibility

既存workflowの維持。

Budget

tokenとtool cost。

Rollout

段階的な切替。

モデル選定は、性能比較と運用切替を分けると進めやすくなります。

• GPT-5.3-Codex、GPT-5.2-Codex、GPT-5.1-Codex、GPT-5-Codexを見る時の確認軸
• 新規workflowで最新Codexモデルを基準にしやすい理由
• 既存workflowをすぐ切り替えず、互換性とsnapshotを見る理由
• context window、max output、reasoning effortをタスクで使い分ける考え方
• input、cached input、output、tool-specific feeを分けて見積もる方法
• モデル更新前に走らせる最小benchmarkの作り方

Codexモデルは、AIコーディングエージェントや社内agent基盤の品質に直結します。PR review、test repair、migration、docs update、CLI workflowなどで、モデルの選び方は速度、品質、コスト、再現性に効きます。

ただし、モデル選定は「一番新しいものを選ぶ」だけでは足りません。既存workflowが安定しているなら、出力傾向、tool call、rate limit、snapshot、deprecated表示、価格上振れまで見てから切り替える必要があります。

前提知識

項目	内容	見方
GPT-5.3-Codex		agentic coding向け。
GPT-5.2-Codex		long-horizon coding向け。
GPT-5.1-Codex		既存運用の確認対象。
GPT-5-Codex		互換性と表示を確認。

導入時はAll modelsと個別モデルページの両方を確認します。

OpenAI APIのモデルページでは、GPT-5.3-Codexがagentic coding向けに最適化されたモデルとして説明されています。個別ページでは、reasoning effort、context window、max output tokens、pricing、対応endpoint、features、snapshots、rate limitsなどが確認できます。

GPT-5.2-CodexやGPT-5.1-Codex、GPT-5-Codexのページも同様に、context、max output、価格、features、snapshotやaliasの情報を持っています。All modelsページでは、codingカテゴリにCodex系モデルが並び、deprecated表示が出る場合もあります。

この記事の扱う範囲

項目	見ること
GPT-5.3-Codex	新規評価の基準にする候補
GPT-5.2-Codex	既存long-horizon taskとの比較対象
GPT-5.1-Codex	古いworkflowの互換性確認対象
GPT-5-Codex	alias、snapshot、deprecated表示を確認する対象
context / output	大量入力と長い出力を本当に使うか
pricing / rate limit	input、cached input、output、tool fee、tier制限

2026年6月1日時点で公開されているOpenAI公式ページを確認しています。導入時には、All models、個別モデルページ、Pricing、rate limit、組織のusage tierを必ず確認してください。

注意点

この記事は、特定モデルを恒久的に推奨するものではありません。OpenAIのモデルページは更新されます。モデル名、snapshot、価格、deprecated表示、対応endpoint、rate limitは、導入直前に再確認する前提です。

まず6つの確認軸に分ける

項目	内容	見方
Capability		必要なtaskに合うか。
Endpoint		Responses/Chatなど。
Context		長文入力の必要性。
Output		長い差分やreport。
Cost		input/output/cached。
Status		snapshotとdeprecated。

軸を分けると、単純な最新版比較になりません。

Codexモデル選定では、最初に6つへ分けます。

軸	確認すること
Capability	agentic coding、long-horizon task、reasoning effort
Endpoint	Responses、Chat Completions、Batchなどの対応
Context	どれだけ読ませる必要があるか
Output	差分、review、reportがどれだけ長くなるか
Cost	input、cached input、output、tool-specific fee
Status	snapshot、alias、deprecated表示、rate limit

この6つを分けると、「最新だから良い」「安いから良い」だけの判断になりません。実務では、タスクごとに必要な条件が違います。

最新モデル名だけで選ばない

新規評価では、GPT-5.3-Codexのような最新Codexモデルを基準にするのが自然です。公式ページでも、GPT-5.3-Codexはagentic coding task向けに最適化されたモデルとして示されています。

ただし、既存workflowでは、最新モデルへ置き換えるだけで良いとは限りません。出力の粒度、修正の大胆さ、tool callの回数、長いcontextの使い方、コストが変わる可能性があります。

旧モデルを残す理由

旧モデルを残す理由は、保守的な互換性です。すでにCI、PR review、社内CLI、eval、Skillが特定モデルの出力傾向に合わせて作られている場合、切替でreport形式や差分サイズが変わることがあります。

そのため、既存workflowでは、モデルを置き換える前に同じ入力、同じ評価軸、同じ成功条件で比較します。

GPT-5.3-Codexは新規評価の基準にする

Reasoning

effortを変えて見る。

Long task

長い作業の完走。

Output

reviewやpatch量。

Cost

上振れを記録。

新規導入では5.3-Codexを基準にし、既存運用は比較して切り替えます。

新しくCodex系モデルを評価するなら、GPT-5.3-Codexを基準にしやすいです。公式モデルページでは、GPT-5.3-Codexがagentic coding tasks向けで、reasoning effortとしてlow、medium、high、xhighを扱えること、400,000 context window、128,000 max output tokensが示されています。

価格は、公式ページ上でinput、cached input、outputの単価として確認します。検索時点の公式ページでは、GPT-5.3-Codexはinput $1.75 / 1M tokens、cached input $0.175 / 1M tokens、output $14.00 / 1M tokensとして表示されています。

見る項目

GPT-5.3-Codexを評価する時は、次を見ます。

項目	見ること
reasoning effort	lowからxhighで品質と時間がどう変わるか
context	どこまで入れると品質が上がるか
output	長いreportやpatchで崩れないか
endpoint	自社workflowで使うAPI経路に合うか
cost	input/outputと再実行回数の合計

「一番強いeffortで全部投げる」は、評価としては雑です。実務では、PR reviewならmediumで足りるのか、長いmigrationだけhighやxhighにするのか、taskごとに分けます。

すぐ置き換えない場面

すでにGPT-5.2-CodexやGPT-5.1-Codexで安定しているworkflowは、すぐ置き換えません。特に、出力formatをparserで読んでいる場合、model changeで崩れる可能性があります。

たとえば、PR review botがSummary / Risks / Tests / Questionsの見出しを前提に動いているなら、モデル切替後も同じ形式で出るか確認します。CLIのJSON出力やstructured outputを使っている場合も、同じschemaで比較します。

5.2/5.1/5-Codexは既存運用の互換性で見る

項目	内容	見方
5.2		既存long taskの比較。
5.1		古いworkflowの再確認。
5		deprecated表示を確認。
Snapshot		固定versionを見る。

既存workflowは、最新化より再現性と切替リスクを先に見ます。

GPT-5.2-Codex、GPT-5.1-Codex、GPT-5-Codexは、既存運用の比較対象として見ます。公式ページでは、GPT-5.2-Codexもagentic coding task向けで、400,000 context window、128,000 max output tokens、reasoning effort対応などが示されています。

GPT-5.1-CodexやGPT-5-Codexのページでは、Responses APIやsnapshot、features、pricingなどを確認できます。All modelsページでは、モデルの現在の扱いが変わることがあります。

deprecated表示

deprecated表示は、導入判断に大きく関係します。All modelsページや個別モデルページで、対象modelやaliasがdeprecatedになっていないかを見ます。

deprecatedが出ている場合、すぐ壊れるとは限りませんが、新規採用の候補から外す、移行計画を作る、snapshot固定を見直す、といった判断が必要です。

snapshot固定

公式モデルページでは、snapshotsが用意されている場合があります。snapshotは、モデルのbehaviorを一定に保つために使います。

運用では、次のように分けます。

用途	model指定
新規評価	latest aliasで比較
本番workflow	snapshotで固定を検討
migration test	aliasとsnapshotを両方試す
deprecated対応	replacement候補を別branchで評価

aliasは更新を受けやすく、snapshotは再現性を取りやすい一方で、古くなるリスクがあります。どちらが良いかではなく、workflowの目的で選びます。

contextとmax outputはタスクで使い分ける

項目	内容	見方
PR review		差分と周辺file。
Migration		広い依存関係。
Docs		大量資料の整理。
Report		長い出力の確認。

大きなcontextは便利ですが、常に全部入れる前提にはしません。

Codex系モデルの大きなcontext windowは魅力です。公式ページでは、GPT-5.3-CodexやGPT-5.2-Codexに400,000 context window、128,000 max output tokensが示されています。

ただし、上限が大きいからといって、常にrepo全体や長いlogを全部入れる必要はありません。大きなcontextは、必要な時だけ使う方が扱いやすいです。

長文contextの使いどころ

長文contextが効きやすいのは、広い依存関係を見る時です。

task	contextに入れる候補
PR review	diff、関連Issue、周辺file、test log
migration	API usage、adapter、test、changelog
long-horizon refactor	call graph、affected files、design note
docs update	old docs、new spec、examples、release note

逆に、単純なlint修正や小さなUI文言修正では、大きなcontextを使う必要は薄いです。入力が増えるほどcostとノイズも増えます。

出力上限の見積もり

max outputは、長いpatch、長いreview report、migration plan、docs更新で効きます。ただし、長い出力はレビューも重くなります。

出力を短く保ちたい時は、最初に制約を入れます。

出力は Summary / Risks / Tests / Next steps に分けてください。
各項目は最大5 bulletにしてください。
コード修正はまだ行わず、必要なfile候補だけ挙げてください。

モデルのmax outputが大きくても、人間が読める成果物へ絞る方が実務では強いです。

costはinput/output/tool feeで分ける

項目	内容	見方
Input		読ませるcodeやlog。
Cached		再利用される入力。
Output		patchやreport。
Tool		searchやcomputer use。

token単価だけでなく、tool固有の費用と再実行回数を見ます。

Codexモデルのcostは、model単価だけでは決まりません。公式モデルページでは、input、cached input、outputの価格が分かれます。さらにOpenAIのpricing説明では、searchやcomputer useのようなtool-specific modelやtool callに別費用があることも示されています。

つまり、見積もりは次のように分けます。

項目	見ること
input	code、docs、log、prompt
cached input	繰り返し使うcontext
output	report、patch、test plan
tool	search、computer useなど
retry	失敗時の再実行

cached input

cached inputは、同じ長い前提を繰り返し使うworkflowで効きます。たとえば、repo規約、API仕様、長い設計docsを毎回入れる場合です。

ただし、cacheを期待して長文を雑に入れるのは避けます。まずcontextを削り、次にcacheが効くかを見る順番です。

tool call

tool callは、モデルtokenとは別にcostや時間へ効く場合があります。search、computer use、browser系、MCP toolなどは、何回呼ぶかで費用とリスクが変わります。

モデル比較では、tokenだけでなく、tool call数も記録します。

記録項目	例
prompt tokens	入力量
output tokens	出力量
tool calls	search、browser、MCP
retries	失敗して再実行した回数
human review time	人間が読む時間

AIコーディングでは、モデル単価より「1つのPRを通すまでの総費用」で見る方が現実的です。

benchmarkは3タスクで小さく見る

PR review

riskとtest gap。

Test repair

失敗logから修正。

Refactor

長い変更を分割。

Docs update

仕様変更を反映。

モデル比較は、普段の作業を小さく固定してから行います。

モデル切替前には、小さなbenchmarkを作ります。大きすぎるbenchmarkは続きません。最初は、普段の開発から3タスクだけ選びます。

タスク	評価するもの
PR review	risk、test gap、質問の質
test repair	失敗logからの原因特定と修正
long-horizon refactor	計画、分割、互換性、テスト

この3つを同じ入力、同じ制約、同じ評価表で回します。既存モデルと新モデルを並べる時は、prompt、対象repo、time limit、tool権限を揃えます。

PR review

PR reviewでは、修正ではなくreview材料を出させます。出力はSummary / Risks / Tests / Questionsに固定します。これは、AIエージェントPRテンプレートの記事と相性がよいです。

test repair

test repairでは、失敗log、対象test、関連fileを渡します。評価するのは、通ったかどうかだけではありません。原因説明、変更の小ささ、テスト追加、不要な期待値変更をしていないかを見ます。

long-horizon refactor

long-horizon refactorでは、最初から実装させず、計画、影響範囲、分割案、rollback案を出させます。大きなcontextとreasoning effortが効きやすい一方、出力が長くなりやすいので、人間レビュー時間も記録します。

比較環境の作り方は、AI Coding Benchmark Kitの記事の考え方を流用できます。

導入初週の進め方

1. 1日目

   All modelsと個別ページを確認。

2. 2日目

   PR reviewで比較。

3. 3日目

   test repairを同条件で実行。

4. 5日目

   costと失敗条件を記録。

5. 7日目

   切替/保留を決める。

まず評価し、既存workflowの切替は最後に判断します。

初週は、モデルを全workflowへ一気に切り替えません。まず公式ページを確認し、小さなbenchmarkを回し、costと失敗条件を残します。

日	やること
1日目	All models、個別モデルページ、Pricing、rate limitを確認
2日目	PR review taskを同条件で比較
3日目	test repair taskを同条件で比較
4日目	long-horizon refactorの計画だけ比較
5日目	token、tool call、retry、人間レビュー時間を記録
7日目	切替、保留、snapshot固定、追加検証を決める

Codexの使い方そのものをチームへ広げる場合は、Codex活用をチームに広げる順番の記事と合わせて、PR review、Slack task、CLI化、Skill化の順番も見ます。

FAQ

Latest?

常に即採用ではない。

Deprecated?

公式表示を確認。

Context?

必要な分だけ使う。

Cost?

再実行も見る。

迷ったら、モデル名ではなくタスクと運用条件へ戻します。

最新のGPT-5.3-Codexを常に使えばよいですか？

新規評価の基準にはしやすいですが、既存workflowを無条件に置き換えるとは限りません。出力形式、tool call、cost、snapshot、deprecated表示、rate limitを確認してから切り替えます。

GPT-5.2-CodexやGPT-5.1-Codexを残す理由はありますか？

あります。既存workflowが安定している場合、急な切替でreport形式や差分サイズが変わることがあります。deprecated表示や利用期限を確認しつつ、移行計画を作ります。

400k contextは常に使うべきですか？

いいえ。長いcontextは、migration、large PR review、docs updateのように広い情報が必要な時に効きます。小さなbugfixでは、対象fileとlogを絞る方が安く、レビューしやすいです。

costはtoken単価だけ見ればよいですか？

足りません。input、cached input、output、tool-specific fee、retry、人間レビュー時間を分けて見ます。AIコーディングでは、1回のmodel callではなく、1つのPRを通すまでの総量で見ます。

次に読むなら

参照した主な情報源

• https://developers.openai.com/api/docs/models/gpt-5.3-codex
• https://developers.openai.com/api/docs/models/gpt-5.2-codex
• https://developers.openai.com/api/docs/models/gpt-5.1-codex
• https://developers.openai.com/api/docs/models/gpt-5-codex
• https://developers.openai.com/api/docs/models/all
• https://developers.openai.com/api/pricing/

更新履歴

1. 2026年6月1日

   OpenAI API公式モデルページ、All models、Pricing関連記述を確認して初版を作成しました。

導入時には最新のモデルページ、pricing、rate limit、deprecated表示を確認してください。

• 2026年6月1日: OpenAI API公式モデルページ、All models、Pricing関連記述を確認して初版を作成しました。