GPT-5.4 vs GPT-5.3：実際に何が変わるのか

こんにちは、Doraです。気づいたら長時間動くエージェントループの監視をしていました。劇的なことは何もなく、ただモデルがもう一つツールコールを求め、また次のを求めるときの、あのゆっくりとした落ち着かない感覚があるだけです。自分の一日の大半がエッジ部分に存在していることを改めて実感しました。停止、リトライ、「本当にドキュメントを読んだの?」という瞬間たち。

そこで午後を使ってGPT-5.3に関するメモを見直し、初期のGPT-5.4に関する話題をざっと確認しました。モデルアーキテクチャとレイテンシのヒントに関するリーク議論の一部は、このGPT-5.4リークの解説にまとめられています。次の大きなトレンドを追うためではなく、もっと小さな疑問に答えるため——これで自分のワークフローの落ち着かない部分が減るだろうか?——です。これは私のGPT 5.4 vs GPT 5.3の継続ログで、実際に計測したこと、信憑性があると思うこと、そしてまだ確信が持てないことをまとめたものです。

GPT-5.3の能力：現在のベースライン

推論とツール使用のパフォーマンス

2026年1月中旬からGPT-5.3を三つの定常業務に使ってきました。プロダクトリサーチの要約、サポートスレッドのトリアージ、小さなスクリプトの骨格作りです。一言でいうと：明確な構造を与えればマルチステップ推論をうまく処理できます。 ロール、状態、終了条件を明示すると、脱線せずに遂行します。

ツール使用については、関数呼び出しは安定しています。OpenAIの関数呼び出しパターンと標準ツールスキーマを活用しており、特に驚くことはありません。ツールが明確に定義されている場合（検索、取得、シンプルなベクトルルックアップ）、5.3のコールは整然としています。20通のメールをトリアージするランでは、スレッドあたり平均1.7回のツールコールで、旧セットアップの2.4回から減りました。これで小さな「次は何?」という停止感が減りました。落とし穴は：ツールの説明が曖昧になると、より多くのコールで補おうとすることです。

最も気になるのは、部分的なコンテキストへの耐性です。関連するチャンクとスリムな状態サマリーだけを渡しても推論は問題ありません。しかし、緩く関連したメモをたくさん投げ込むと、ヘッジが始まります。

コーディングとエージェントワークフローのサポート

コードについては、5.3は小〜中規模のリファクタリングで安定しています。明確な説明付きのdiffを生成するのが得意で、簡単なスタイルガイドを与えれば一貫したスタイルを維持できます。遅くなるのは、密な依存関係の認識が必要なファイル間の変更です。通常は二パスのパターンに切り替えます。最初のパスで編集内容の概要を示し、二番目のパスでファイルごとに適用する、という形です。これにより、触るべきでないものを過信して触ることを防げます。

エージェントワークフローでは、再帰に上限を設けてすべての判断をログに記録すると5.3は最もうまく動きます。プラン→ツール呼び出し→反省、という三ステップのループに落ち着きました。それ以上やると冗長になります。また状態にコンパクトなJSONを出力するよう促すことで、パースエラーが減ります。これは魔法ではなく、ループを過度に要求しないためのガードレールです。

既知の制限

システムルールと長いユーザータスクを混在させると指示を二重処理することがある。プロンプトの末尾近くに主要な制約を再記述するようになりました。
すでに要約したインプットをもう一度要約しようとすることがあり、トークンと時間を無駄にします。
ビジョンタスク（スクリーンショット、UIモック）では、ラベリングや説明は得意ですが、小さなテキストや細かいレイアウトロジックを見落とします。トグルをボタンと間違えたことが一度ならずありました。
プレッシャー下（トークンが少ない）では、正確なエッジより安全な一般論を好みます。エラーログを評価するときに見られます。起こりうる原因は挙げるものの、より多くのコンテキストなしにはコミットを躊躇します。

これが5.3の私の作業イメージです。明示的な場合は信頼できますが、そうでない場合は少し不安定になります。

GPT-5.4のシグナルが示す変化

2026年3月5日時点では5.4への直接アクセスはありません。以下は初期リークスレッド、プライベートフォーラムでの信頼性の高いデベロッパーコメント数件、そしてモデルファミリーが少し前進するときに注目するようになったパターンからの情報です。各ポイントを「観察可能」「リークベース」「推測的」として分類します。

推論速度、ファストモードの意味

リークベース：複数のアカウントが短形式推論向けの「ファストモード」または低レイテンシティアについて言及しています。事実なら、生のスループットよりエージェントのテンポに意味があります。最初のトークンのレイテンシが20〜30%削減されると、ループの感触が鈍重からレスポンシブに変わります。DeepSeekやGLMなどのモデルとGPT-5を比較したベンチマークは、レイテンシとコストが実際の開発ワークフローにどれだけ影響するかを示しています。私の5.3セットアップでは、平均的なプロンプトで最初のトークンのレイテンシは600〜900msほど漂っています。150〜200ms削減されるだけでもツールチェーンのストップアンドゴーが減るでしょう。このファストモードは深度をトレードオフにすると予想されます——より重いパスの前のルーティング、分類、簡易バリデーションに便利です。

観察可能：5.4に本当にスピードティアが追加されるなら、ワークフローを分割するでしょう。クイック分類→ルート→ディープパス。それはすでに一般的なパターンで、速度がただそれをスムーズにするだけです。

ビジョン入力処理の改善

リークベース：小さなテキストOCRの改善と、より安定したレイアウト推論。低コントラストのUIテキストの認識向上と、より精細なバウンディングボックスロジックへのヒントがあります。正確なら、5.3の二つのフリクションポイントが解決されます。スクリーンショットの小さなコピーとUIコントロールの区別です。

観察可能：インターフェースのワイヤーフレームを検証するときの行き来が省けます。今は5.3が判断を渋るとき、スクリーンショットを別のOCRステップに通しています。5.4がその迂回路を減らすなら、チェーンからツールを一つ外せます。

コンテキストウィンドウ拡張の可能性

推測的：使用可能なコンテキストのわずかな増加、または長いプロンプトにわたる保持の改善。ヘッドラインの数字ではなく、長い会話の後半での実用的な想起を意味します。5.4がタスクの制約をより長く保持してくれれば、状態の構造化方法が変わります。リマインダーが減り、トークン税が減ります。生のウィンドウ増加だけで想起の改善がなければ、恩恵は小さいです。

これは実際に「後半での再解釈」が減るのを見てから信じます。それまでは慎重です。

並列比較表

実際に計測したことと、聞いただけのことを分けて考えたいです。毎回同じレンズで、三つの簡単な表にまとめます。

確認された能力

エリア	GPT-5.3	GPT-5.4
ツール使用 / 関数呼び出し	明確なスキーマで安定：私のランでは1タスクあたり1〜3コールが典型	未確認
トークンプレッシャー下の推論	一般論に劣化：制約の再記述で改善	未確認
ビジョン（UIスクリーンショット）	小さなテキストを見落とす：一部のコントロールを混同	未確認
エージェントループの動作	2〜3ステップのループと明示的な停止条件で最良	未確認
ファイル間のコーディング	安全のために二パス戦略が必要：明確なdiff説明	未確認

参考：OpenAIの関数呼び出しドキュメントとAPIリファレンスのツール定義のパターンに従っています。興味があれば、公式ドキュメントが良い基盤です：OpenAI API: 関数呼び出しとツール使用。

リークベースのシグナル

エリア	GPT-5.3	GPT-5.4（リークベース）
推論速度ティア	標準モードのみ	低レイテンシレスポンス向けの高速・浅いティアを追加
ビジョンOCR	十分だが、小さな/低コントラストのテキストに苦労	小テキストの精度とレイアウト処理が改善
トークンあたりのコスト	現在公開されている料金	ファストティアでわずかに削減（未検証）

ソースの品質：まちまち。一部の詳細は過去のリリースパターンと一致しますが、確認済みはありません。

エリア	GPT-5.3	GPT-5.4（推測的）
コンテキスト保持	制約の頻繁なリマインドが必要	より少ない再記述で制約をより長く保持
ツール使用の効率	スキーマが曖昧なときに過剰コールすることがある	類似プロンプトでより良いコールの倹約
長期計画	3〜4ステップ先にコミットすることをためらう	マルチステップ計画がわずかに安定

推測的な改善

これらの変化が開発者にとって重要な理由

エージェントループ設計への影響

「ファストモード」が存在するなら、ループを再設計して安価な確実性を前倒しにします。クイック分類からブランチへ：シンプルなタスクはファストモードで完結し、複雑なものはフルデプスモデルにエスカレートします。 それだけで人間の監視が減ります。現在の5.3スタックでは、ループが螺旋状に増殖するのを防ぐためにエネルギーを使っています。スピードティアがあれば、そのエネルギーをより明確なルーティングに向けられます。

より良いビジョン処理はUIアナリシスパイプラインを簡素化します。今は、モック向けに三ステップのチェーンを使っています。基本キャプション→OCRパス→レイアウトチェック。5.4が最初の二つをマージすれば、OCRホップを廃止してレイアウトバリデーターだけ残せます。メンテナンスするツールが一つ減り、エラーが発生する場所も減ります。

コンテキスト保持が改善すれば、プロンプト内のリマインダーの太鼓をたたく回数を減らせます。小さな不変のルールブロックを保持して、モデルがより長くランに持ち込めることを信頼します。スキャフォールディングが減り、トークンが減り、同じ結果が得られます。

コストとパフォーマンスのトレードオフ

スピードティアには通常、品質上のコストが伴います。私はそれをバグではなく機能として捉えます。用途は以下の通りです：

ルーティングと軽量バリデーション（日付をパースできたか、yes/no?）
早期終了（これは既知のFAQか?）
取得したコンテキストのヘルスチェック（このチャンクはエンティティに言及しているか?）

それ以外——アウトプットを形成する推論——には深さのためにコストを払います。5.4のファストティアがトークンあたりのコストが安いなら、高ボリュームタスクでは小さな節約が期待できますが、本当の利得はレイテンシです。タスクあたりのコストは少し下がるかもしれません。体感速度は大幅に改善するかもしれません。

価格に変化がなくても、仕事を分割します。5.3でも、ルーティングに小さい/安いモデルを使うことはしばしば効果があります。ネイティブのファストティアがあれば、グルーコードが減るだけです。

移行の考慮事項

シャドウテストから始める。同じプロンプトを5.3と5.4（利用可能になったら）に通して、結果を比較する。数十のエッジケースを確認してからライブパスを切り替えること。
ツールスキーマを厳密に保つ。曖昧な説明は5.3でコール数を膨らませます。ファストかどうかにかかわらず、5.4でも同じになるでしょう。
トークンプレッシャーをログに記録する。多くの「リグレッション」はプロンプトが締まっているだけです。ウィンドウ使用量を追跡してボイラープレートを削減する。
プロンプトをバージョン管理する。システムメッセージに小さな変更履歴を保持しています。5.4がより少ないリマインダーで動作するなら、何を削除したかの証跡が必要になります。
ビジョンを静かに監視する。スクリーンショットを使用するなら、低コントラストのテキスト、狭いUI、変わったフォントでテストする。優れたテストセット一つが、十のエピソードに勝ります。

小チームであれば、最も安全な方法は段階的です。狭いワークフロー（ルーティング、トリアージ）でパイロットし、その後拡大する。

個人ビルダーには、一つの習慣の変化を試してみてほしいです。プロンプトチェーンの先頭に「ファストかフルか?」のゲートを追加する。5.4がファストモードを提供しなくても、その規律は役に立ちます。

重要な注意事項（リークシグナルに基づく比較）

GPT-5.4に関するこの記事のすべては、公式リリースやドキュメントが出るまでは伝聞情報です。5.4の部分は、リークベースのシグナルと過去のアップデートからの慎重な推測の混合です。5.4が実際にリリースされたら、同じタスクを再実行してこれを更新します。今は、インクではなく鉛筆で描いた地図と考えてください。

最後に一言：ちょっとした速度の改善でさえ、ワークフローの緊張をほぐすことができます。 それが5.4のすべてであっても、私は受け入れます。