GPT-5.4が来た: Codexで1Mコンテキストを有効にする方法と他モデルとの比較

こんにちは！逆瀬川 (@gyakuse) ちゃんです

今日はOpenAIから本日リリースされたGPT-5.4について、Codexリポジトリのソースコードから読み取れるinstructionsの進化、1Mコンテキストウィンドウの有効化方法、そして他モデルとのベンチマーク比較をまとめていきたいと思います。

GPT-5.4の概要

GPT-5.4は2026年3月6日（日本時間）にリリースされたOpenAIの最新フロンティアモデルです。ChatGPT（GPT-5.4 Thinking として）、API、Codexの3つのプラットフォームで利用できます。

ポジショニングとしてはGPT-5.3-Codexのコーディング能力をベースに、知識ワーク・コンピュータ操作・ツール利用を大幅に強化した統合モデルです。公式ブログでは「our most capable and efficient frontier model for professional work」（プロフェッショナルワークのための最も能力が高く効率的なフロンティアモデル）と紹介されています。

主要な新機能をざっくり整理するとこうなります。

コンピュータ操作: 汎用モデルとして初めてネイティブなcomputer-use能力を搭載。OSWorld-Verifiedで75.0%（人間の72.4%を超える）
1Mコンテキスト: APIとCodexで最大100万トークンのコンテキストウィンドウを実験的にサポート
ツール検索: tool searchという仕組みで大量のツール定義をコンテキストに入れずに効率的にツールを使える。MCP Atlasベンチマークでトークン使用量47%削減。ただしこのアプローチ自体はAnthropicが2025年11月にdefer_loadingパラメータとtool search toolとしてClaude APIに導入済みです。Claude CodeでもMCP Tool Searchとして本番実装されており、MCPツール定義がコンテキストの10%を超えると自動的に有効化されます。OpenAIがGPT-5.4で追いついた形です
トークン効率: GPT-5.2と比較してreasoningトークンが大幅に減少。o1以降、推論時の計算量を増やすことで精度を上げるtest-time compute (Snell et al., 2024) が性能向上の主要な手段だったが、GPT-5.4はトークンを減らしつつ性能を上げている
/fastモード: Codexで最大1.5倍のトークン速度。同じモデル、同じ知性で速度だけ上がる

OpenAI公式ベンチマーク結果

公式ブログが発表している主要ベンチマーク結果を表にします。

評価項目	GPT-5.4	GPT-5.4 Pro	GPT-5.3-Codex	GPT-5.2
GDPval（知識ワーク）	83.0%	82.0%	70.9%	70.9%
SWE-Bench Pro	57.7%	-	56.8%	55.6%
OSWorld-Verified（コンピュータ操作）	75.0%	-	74.0%	47.3%
Toolathlon（ツール使用）	54.6%	-	51.9%	46.3%
BrowseComp（ウェブ検索）	82.7%	89.3%	77.3%	65.8%
MMMU Pro（視覚理解）	81.2%	-	-	79.5%
ARC-AGI-2（抽象推論）	73.3%	83.3%	-	52.9%
GPQA Diamond	92.8%	94.4%	92.6%	92.4%
Humanity's Last Exam（ツールあり）	52.1%	58.7%	-	45.5%
FrontierMath Tier 1-3	47.6%	50.0%	-	40.7%

特に目を引くのはOSWorld-Verifiedです。GPT-5.2の47.3%から75.0%に跳ね上がっていて、人間のパフォーマンス（72.4%）を超えています。コンピュータ操作能力が一気に実用レベルに到達した感があります。

GDPvalも70.9%から83.0%へと大幅に向上しています。これは44の職種にわたるプロフェッショナルの知識ワーク（営業資料、会計スプレッドシート、法的分析など）で業界プロフェッショナルと同等以上の品質を出せるかという評価で、かなり実務寄りの指標です。

ハルシネーション低減も注目ポイントで、個々の主張が誤りである確率がGPT-5.2比で33%減少、レスポンス全体にエラーが含まれる確率は18%減少しています。

models.jsonから読み解くinstructionsの進化

さて、ベンチマーク結果だけでは見えない話があります。CodexはOSSなので、モデル定義ファイル codex-rs/core/models.json を読むと、各モデルに渡されるbase_instructions（システムプロンプト）の設計思想がわかります。自分はモデル更新のたびに読んでいますが、めちゃくちゃ面白いです。GPT-5.4とGPT-5.3-Codexは構造が非常に似ていますが、微妙な差分にCodex開発チームの意図が透けて見えます。

「エキスパートエンジニア」としての自己認識

GPT-5.4のGeneralセクションにはGPT-5.3-Codexにない導入文が追加されています。

As an expert coding agent, your primary focus is writing code, answering questions,
and helping the user complete their task in the current environment. You build context
by examining the codebase first without making assumptions or jumping to conclusions.
You think through the nuances of the code you encounter, and embody the mentality
of a skilled senior software engineer.

（エキスパートコーディングエージェントとして、あなたの主な仕事はコードを書き、質問に答え、現在の環境でユーザーのタスク完了を助けることです。まず仮定や飛躍なしにコードベースを調べてコンテキストを構築します。遭遇するコードの微妙なニュアンスを考え抜き、熟練したシニアソフトウェアエンジニアのメンタリティを体現します。）

5.3-Codexにはこの導入文がなく、いきなり具体的なルールから始まっていました。「skilled senior software engineer」のメンタリティを体現せよ、という一文はロールプロンプティングのように見えます。しかし、段落全体を読むとその実態は異なります。

「コードを書き、質問に答え、タスク完了を助ける」→ タスクスコープの明示
「仮定や飛躍なしにまずコードベースを調べよ」→ 行動制約
「コードのニュアンスを考え抜け」→ 行動制約
「skilled senior software engineerのメンタリティを体現せよ」→ 上3つをまとめるアンカー

つまりこれはペルソナを付与するロールプロンプティングではなく、行動指示のプリアンブルです。5.3-Codexでは箇条書きルールにいきなり入っていた構成を、5.4では「何をする存在で、どう振る舞うか」を散文で前置きする構成に変えています。dbreunig (2026)が6つのコーディングエージェントのsystem promptを分析して指摘しているように、system promptの役割はモデルの訓練データバイアスを補正し、行動の境界を定義することです。この段落もその機能を果たしています。

apply_patchの強制化

GPT-5.3-Codexでは「try to use apply_patch for single file edits, but it is fine to explore other options」（単一ファイルの編集にはapply_patchを使ってみてください。ただし他の方法を探っても構いません）と柔軟な指示でした。GPT-5.4ではこう変わっています。

- Always use apply_patch for manual code edits. Do not use cat or any other commands
  when creating or editing files.

（手動のコード編集には常にapply_patchを使用すること。ファイルの作成や編集にcatやその他のコマンドを使用しないこと。）

「always」で「Do not use cat」と明示的に禁止しています。apply_patchを経由したほうがdiffのトラッキングやユーザーへの変更提示が確実にできるため、エージェントの挙動を予測可能にするための厳格化です。

予期しない変更への対応: パニック→冷静に

GPT-5.3-Codexでは作業中に予期しない変更を見つけた場合の指示がこうでした。

- While you are working, you might notice unexpected changes that you didn't make.
  If this happens, STOP IMMEDIATELY and ask the user how they would like to proceed.

（作業中に、自分が行っていない予期しない変更に気づくかもしれません。その場合は直ちに作業を停止し、どう進めたいかユーザーに確認してください。）

GPT-5.4ではより冷静な対応に変更されています。

- While you are working, you might notice unexpected changes that you didn't make.
  It's likely the user made them, or were autogenerated. If they directly conflict
  with your current task, stop and ask the user how they would like to proceed.
  Otherwise, focus on the task at hand.

（作業中に、自分が行っていない予期しない変更に気づくかもしれません。おそらくユーザーが行ったか、自動生成されたものでしょう。現在のタスクと直接衝突する場合は作業を停止してユーザーに確認してください。そうでなければ、手元のタスクに集中してください。）

「STOP IMMEDIATELY」（直ちに停止）が消え、「ユーザーが作った変更か自動生成かもしれない。直接衝突する場合だけ聞け、それ以外は手元の作業に集中せよ」という指示になっています。長時間のエージェントセッションではlinterやformatterによる自動変更が頻繁に起きるので、いちいち止まっていたら作業が進まないという実運用の知見が反映されています。

intermediary updatesの頻度調整: 20秒→30秒

GPT-5.3-Codexでは中間アップデートの頻度が20秒ごとでしたが、GPT-5.4では30秒ごとに変更されています。

# 5.3-Codex
- You provide user updates frequently, every 20s.

# 5.4
- You provide user updates frequently, every 30s.

（5.3-Codex: ユーザーへの更新を頻繁に、20秒ごとに提供する。）（5.4: ユーザーへの更新を頻繁に、30秒ごとに提供する。）

加えてGPT-5.4には「When working for a while, keep updates informative and varied, but stay concise.」（しばらく作業が続く場合は、更新を情報量豊かで変化に富んだものにしつつ、簡潔に保つこと。）という一文が追加されています。更新頻度を下げつつ品質を上げる方向の調整です。20秒だとユーザーへの割り込みが多すぎたのでしょう。

Reactコードのモダンパターン指示

GPT-5.4のFrontend tasksセクションにはGPT-5.3-Codexにない指示が追加されています。

- For React code, prefer modern patterns including useEffectEvent, startTransition,
  and useDeferredValue when appropriate if used by the team. Do not add
  useMemo/useCallback by default unless already used; follow the repo's
  React Compiler guidance.

（Reactコードには、チームが使用している場合、useEffectEvent、startTransition、useDeferredValueなどのモダンパターンを適切に使用すること。既に使われていない限り、デフォルトでuseMemo/useCallbackを追加しないこと。リポジトリのReact Compilerガイダンスに従うこと。）

React Compilerへの対応を明示的に指示しています。useMemo/useCallbackをデフォルトで追加しないという指示は、React Compilerがこれらを自動最適化する前提で書かれています。

bashコマンドチェーンの禁止

GPT-5.4では並列ツール呼び出しの指示に以下が追加されています。

Never chain together bash commands with separators like `echo "====";`
as this renders to the user poorly.

（echo "===="; のようなセパレータでbashコマンドを連鎖させないこと。ユーザーへの表示が崩れるため。）

GPT-5.3-Codexにはこの制約がありませんでした。エージェントがecho "====" ; cat file.txt ; echo "====="のようなコマンドチェーンを組み立てると、Codex UIでの表示が崩れるという実運用上のバグフィックスです。

Codexで1Mコンテキストウィンドウを有効にする

このmodels.jsonを見るとわかる通り、GPT-5.4のcontext_windowはデフォルトで272,000トークンです。ですが実験的に1M（100万トークン）まで拡張できます。

設定方法

2つの方法があります。

方法1: CLIフラグで直接指定する

Codexの-cフラグを使えば、config.tomlを編集せずにその場で設定できます。

codex -m gpt-5.4 -c model_context_window=1000000 -c model_auto_compact_token_limit=900000

-c key=valueはconfig.tomlの任意のキーをCLIからオーバーライドできる汎用フラグです（codex-rs/utils/cli/src/config_override.rs）。値はTOMLとしてパースされ、整数はそのまま整数として扱われます。試しに1Mコンテキストを使ってみたいときにはこちらが手軽です。

方法2: config.tomlに書く

常用するなら ~/.codex/config.toml に以下を追記します。

model = "gpt-5.4"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

この2つのパラメータの役割を説明します。

model_context_window: モデルのコンテキストウィンドウサイズ（トークン数）。デフォルトは272,000。1Mに設定することで100万トークンまで会話履歴を保持できる
model_auto_compact_token_limit: 会話履歴の自動圧縮（auto-compact）が発動するトークン数の閾値。この値を超えると古い会話がサマリに圧縮される

仕組みの解説

Codexのソースコードを見ると、この設定がどう反映されるかがわかります。

codex-rs/core/src/models_manager/model_info.rsのoverride処理がこうなっています。

pub(crate) fn with_config_overrides(mut model: ModelInfo, config: &Config) -> ModelInfo {
    // ...
    if let Some(context_window) = config.model_context_window {
        model.context_window = Some(context_window);
    }
    if let Some(auto_compact_token_limit) = config.model_auto_compact_token_limit {
        model.auto_compact_token_limit = Some(auto_compact_token_limit);
    }
    // ...
}

config.tomlの値が直接ModelInfoに反映される素直な設計です。デフォルトのGPT-5.4の定義（codex-rs/core/models.json）ではcontext_window: 272000で、auto_compact_token_limitは未設定です。auto_compact_token_limitが未設定の場合はコンテキストウィンドウの90%（context_window * 9 / 10）が自動圧縮の閾値として使われます。

つまりデフォルトだとおよそ244,800トークンで自動圧縮が走ります。1Mに拡張するときはmodel_context_windowを1000000にして、model_auto_compact_token_limitで明示的に圧縮閾値を指定するのが推奨です。上の例では900,000にしていますが、これはお好みで調整してください。

コストに関する注意

ここで重要な注意点があります。公式ブログにこう書かれています。

Requests that exceed the standard 272K context window count against usage limits at 2x the normal rate.

（標準の272Kコンテキストウィンドウを超えるリクエストは、通常の2倍のレートで使用量制限にカウントされます。）

272Kを超えるリクエストは使用量制限（rate limit）に対して通常の2倍のレートで消費されます。同じ制限枠の中で使える量が実質半分になるので、大量に使う場合は制限に当たりやすくなります。

どういうケースで使うか

1Mコンテキストが活きるのは以下のようなケースです。

大規模リポジトリの横断的なリファクタリングで全体像を把握したい
長時間のデバッグセッションで会話履歴を圧縮させたくない
複数ファイルにまたがるアーキテクチャレビュー

逆に通常のコーディング作業であればデフォルトの272Kで十分なケースが多いはずです。auto-compactは優秀なので、よほど「圧縮で文脈が失われて困る」という体験がない限りはデフォルトのままでいいと思います。

他モデルとの比較

さて、Codex内部の設計を見てきたところで、GPT-5.4が他のフロンティアモデルとどう並ぶかを見ていきましょう。

API価格比較

まずは価格から。コスト構造の違いは選択に直結するので大事です。

モデル	入力 ($/M tokens)	キャッシュ読取 ($/M tokens)	出力 ($/M tokens)	ソース
GPT-5.4 (≤272K)	$2.50	$0.25	$15.00	OpenAI
GPT-5.4 (>272K)	$5.00	$0.50	$22.50	OpenAI
GPT-5.4 Pro (≤272K)	$30.00	-	$180.00	OpenAI
GPT-5.4 Pro (>272K)	$60.00	-	$270.00	OpenAI
GPT-5.2	$1.75	$0.175	$14.00	OpenAI
Claude Sonnet 4.6 (≤200K)	$3.00	$0.30	$15.00	Anthropic
Claude Sonnet 4.6 (>200K)	$6.00	$0.60	$22.50	Anthropic
Claude Opus 4.6 (≤200K)	$5.00	$0.50	$25.00	Anthropic
Claude Opus 4.6 (>200K)	$10.00	$1.00	$37.50	Anthropic
Gemini 3.1 Pro (≤200K)	$2.00	$0.20	$12.00	Google
Gemini 3.1 Pro (>200K)	$4.00	$0.40	$18.00	Google
Gemini 2.5 Pro (≤200K)	$1.25	$0.125	$10.00	Google
Gemini 2.5 Pro (>200K)	$2.50	$0.25	$15.00	Google

キャッシュ読取はOpenAIの「Cached input」、Anthropicの「Cache Hits & Refreshes」、Googleの「Context caching」に対応し、いずれもベース入力単価の0.1倍です。

GPT-5.4はGPT-5.2より入力が43%高くなっています（$1.75→$2.50）。ただしOpenAIはGPT-5.4のトークン効率がGPT-5.2より大幅に改善されていると主張しており、同じタスクに必要な総トークン数が減るため実質コストは下がるケースもあるとのことです。

Claude Sonnet 4.6と比較すると入力はGPT-5.4が安く（$2.50 vs $3.00）、出力は同額（$15.00）です。Gemini 2.5 Proは入出力ともに最安ですが、各モデルの得意分野が異なるのでコストだけでは判断できません。

なお3社とも長コンテキスト利用時は入力2倍・出力1.5倍の課金が設定されています（OpenAI: 272K超、Anthropic・Google: 200K超）。1Mコンテキストを常用すると通常の2倍近いコストがかかります。

ベンチマーク横断比較

GPT-5.4は本日リリースされたばかりなのでサードパーティの統一条件ベンチマークはまだ出揃っていませんが、各社公式発表のスコアを並べるとこうなります。

評価項目	GPT-5.4	Claude Opus 4.6	Gemini 3.1 Pro	ソース
OSWorld-Verified（コンピュータ操作）	75.0%	72.7%	-	OpenAI, Anthropic
SWE-Bench Verified（コーディング）	-	80.8%	80.6%	Google DeepMind
SWE-Bench Pro（コーディング）	57.7%	-	54.2%	OpenAI, Google DeepMind
Terminal-Bench 2.0*	75.1%	65.4%	68.5%	OpenAI, Google DeepMind
GPQA Diamond（科学推論）	92.8%	91.3%	94.3%	OpenAI, Google DeepMind
ARC-AGI-2（抽象推論）	73.3%	68.8%	77.1%	OpenAI, ARC Prize
MMMU Pro（視覚理解）	81.2%	73.9%	80.5%	OpenAI, Google DeepMind
GDPval-AA（知識ワーク）	83.0%	1,606 Elo	1,317 Elo	OpenAI, Google DeepMind
BrowseComp（ウェブ検索）	82.7%	84.0%	85.9%	Google DeepMind
MCP Atlas（ツール連携）	67.2%	59.5%	69.2%	OpenAI, Google DeepMind

*Terminal-Bench 2.0はTerminus-2ハーネスでの結果。GPT-5.4の75.1%はOpenAI公式値。agent+modelの組み合わせでスコアは大きく変動し（例: Opus 4.6はTerminus-KIRAで74.7%、Gemini 3.1 Pro+Forge Codeで78.4%）、GPT-5.3-Codexの77.3%（Codex CLI）はGPT-5.4より高い。MMMU ProとGPQA Diamondはtools無しの条件。GDPval-AAはOpenAIのみパーセンテージ、Anthropic/GoogleはEloで報告。

注意: 各社公式のスコアは評価条件（scaffolding、reasoning effort設定、ツール構成等）が異なるため、厳密なapples-to-apples比較ではありません。あくまで各モデルの得意領域の傾向を把握するためのものです。

この表から見えてくるパターンは明確です。

コンピュータ操作ではGPT-5.4がOSWorld 75.0%でトップです。Terminal-Bench 75.1%も高いですが、実はGPT-5.3-Codexの77.3%より低く、さらにGemini 3.1 Pro+Forge Codeエージェントは78.4%を記録しています。ただしCodexのようなエージェント型ワークフローではOSWorldの差が効いてきます。

科学推論と抽象推論ではGemini 3.1 Proが強いです。GPQA Diamond 94.3%、ARC-AGI-2 77.1%でリードしています。

視覚理解（MMMU Pro、tools無し）ではGemini 3.1 Pro 80.5%、GPT-5.4 81.2%がOpus 4.6の73.9%を上回っています。ただしOpus 4.6はtools有りで77.3%まで伸びるため、ツール連携込みの実務ではこの差は縮まります。

知識ワーク（GDPval）ではGPT-5.4が83.0%で最高スコアです。プロフェッショナルの実務タスク（スプレッドシート、プレゼン、法的分析）での実力を示しています。

ウェブ検索（BrowseComp）はGemini 3.1 Proが85.9%でトップですが、GPT-5.4 Pro（89.3%）はさらに上です。

つまり「全方面で最強」なモデルは存在せず、タスクの性質で最適解が変わります。

コーディング用途での選び方

実務でのモデル選択の観点で整理します。

GPT-5.4: Codexとの統合が最も深い。computer-use、1Mコンテキスト、commentaryチャネルによるmid-response steeringなど独自機能が多い。特にTerminal-Bench 75.1%が示すように長時間のエージェントセッションやターミナル操作で真価を発揮する
Claude Opus 4.6: SWE-Bench Verified 80.8%が示す通りコーディング品質が高い。MMMU Pro 73.9%（tools有り77.3%）で視覚理解も堅実。ドキュメント駆動のコードレビューに強い
Claude Sonnet 4.6: Opus 4.6の約60%のコストで近い性能。コスパ重視なら有力な選択肢
Gemini 3.1 Pro: 抽象推論（ARC-AGI-2 77.1%）と科学推論（GPQA 94.3%）がトップ。APIコストも$2/$12と競争力がある

Codexを使っているならGPT-5.4がファーストチョイスですが、API経由で複数モデルを使い分ける場合はタスク特性と予算で選ぶのがよいでしょう。

まとめ

GPT-5.4はコンピュータ操作（OSWorld 75.0%で人間超え）と知識ワーク（GDPval 83.0%）で大幅な進化を遂げた統合フロンティアモデル
Codexのmodels.jsonでGPT-5.3-Codex→5.4のinstructions差分を読むと、apply_patchの強制化、予期しない変更への冷静な対応、React Compiler対応など実運用フィードバックに基づく改善が見える
Codexで1Mコンテキストを使うにはcodex -m gpt-5.4 -c model_context_window=1000000 -c model_auto_compact_token_limit=900000か、config.tomlに同等の設定を書く
他モデルとの比較ではタスクによって得手不得手があり、全方面最強ではない。コンピュータ操作・ターミナル操作ならGPT-5.4、コーディング品質ならClaude Opus 4.6、推論ならGemini 3.1 Pro