Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

GPT-5 が開発者にとって重要な理由
GPT-5 で何が変わったのか
どのサイズを選ぶべきか
制御値はどう使い分けるか
エージェント型コーディングで何が変わるか
カスタムツールと出力制約をどう組み合わせるか
Responses API と Chat Completions API はどう使い分けるか
- Responses API
- Chat Completions API
遅延とコストをどう下げるか
本番導入のチェックリスト
FAQ
References

GPT-5 が開発者にとって重要な理由

OpenAI は 2025年8月7日に Introducing GPT-5 for developers を公開し、GPT-5 を コーディングとエージェントタスクに最適なモデル と説明した。重要なのは、単にモデル性能が上がったことではない。開発ワークフロー全体を、プロンプトの工夫だけでなく、ツール挙動、出力制約、遅延、コスト まで含めて設計する方向へ押し上げた点にある。

以前の開発フローは、だいたい次のようなものだった。

モデルを選ぶ
プロンプトを書く
JSON が正しく返ることを祈る
壊れたツール呼び出しを後処理で直す
コスト最適化は後回しにする

GPT-5 はこの流れをより明示的にした。今は、どのくらい長く答えるか、どのくらい深く考えるか、どの形式で出力するか、どんなツールをどう使うかを一緒に決められる。これが、エージェント型コーディングや業務自動化で大きな差になる。

GPT-5 で何が変わったのか

GPT-5 が実務で重要なのは、単なる性能向上よりも、開発者が触れる制御面が増えたからだ。

1. コーディングとエージェント作業に強い

OpenAI は GPT-5 を、コード編集、バグ修正、複雑なコードベースの質問、複数段階のツール利用に強いモデルとして位置付けている。つまり、単発の文章生成より 作業遂行 に向いている。

2. 主要な制御が明確

まず覚えるべき制御は 2 つだけで十分だ。

verbosity: 出力の長さと説明の厚みを調整する
reasoning_effort: どれだけ深く考えてから答えるかを調整する

verbosity はユーザーが読む体験を変え、reasoning_effort は品質、遅延、推論トークン消費のバランスを変える。

3. カスタムツールがより柔軟

GPT-5 は、JSON だけでなく plaintext 入力 を受け取るカスタムツールを使える。SQL、DSL、シェル風コマンド、社内独自フォーマットのように、JSON に無理やり押し込むと逆に不自然になる用途で特に有効だ。

4. 出力制約を強くかけられる

必要なら、正規表現や CFG で出力形式を縛れる。実運用では「だいたい合っている」より 必ず正しい形式 のほうが重要なことが多いので、この機能はかなり効く。

5. 主要な API 面で使える

GPT-5 は Responses API と Chat Completions API の両方で使え、Codex CLI でもデフォルトの開発フローに自然に入る。つまり、対話、コードエージェント、バッチ処理にまたがって、同じ考え方を再利用しやすい。

どのサイズを選ぶべきか

GPT-5 系は、品質だけでなく コストと遅延の段階 として考えるのが実用的だ。

モデル	向いている用途	強み	注意点
`gpt-5`	複雑なコード修正、エージェントループ、難しいデバッグ、設計判断	最も強い推論と作業遂行能力	コストと遅延は高め
`gpt-5-mini`	一般的な機能開発、バランス重視のツール利用、日常的なコーディング支援	品質と効率のバランスがよい	難しい問題では限界が出る
`gpt-5-nano`	分類、抽出、ルーティング、超低遅延処理	速くて安い	深い推論には向かない

実運用では次の分け方がわかりやすい。

重要な経路は gpt-5
バランス重視は gpt-5-mini
大量前処理は gpt-5-nano

制御値はどう使い分けるか

GPT-5 をうまく使うチームは、プロンプトだけでなく デフォルト値 を整える。

制御値	下げる場面	上げる場面
`verbosity`	短い結果だけ欲しい、コンパクトな JSON が欲しい、機械可読な要約で十分	コードレビュー説明、デバッグ解説、ユーザー向け説明文が必要
`reasoning_effort`	タスクが単純、速度が優先、分類や抽出が中心	複数段階の推論、ツール選択が難しい、浅い思考だと失敗しやすい

覚え方は簡単だ。

verbosity は読みやすさを決める
reasoning_effort は考える深さを決める

両方を高くしすぎると品質はよく見えても、コストと遅延が一気に増える。逆に低すぎると速いが、難しいケースを取りこぼしやすい。

エージェント型コーディングで何が変わるか

GPT-5 は一発生成器というより、コードベースを一緒に読む協力者 に近い。うまくいく流れは「コードを一度で書かせる」ではなく、次のようなものだ。

タスクを理解する
関連ファイルと文脈を見る
適切なツールを選ぶ
何をしているか説明する
結果を検証する
失敗しても文脈を保ったままやり直す

だから、難しいコーディングでは gpt-5 が最も合う。特に次の場面で強い。

複数ファイルにまたがる修正
コードベース全体をまたいだバグ追跡
テスト作成と実装修正の往復
計画に沿った複数回のツール呼び出し

小さなルールベース作業なら、gpt-5-mini や gpt-5-nano で十分なことが多く、コストも抑えられる。

カスタムツールと出力制約をどう組み合わせるか

カスタムツールの価値は、単にモデルがツールを呼べることではない。入力形式を仕事に合わせて変えられること にある。

plaintext のほうが自然な例は次のとおりだ。

SQL 実行
社内 DSL の検証
設定ファイルのドラフト
シェル風コマンド

そして、形式が重要なら制約を足す。

簡単な固定形式には正規表現
文法が厳密な内部言語には CFG

この組み合わせにより、モデルは「それっぽい答え」ではなく、実際に実行できる答え を返しやすくなる。

Responses API と Chat Completions API はどう使い分けるか

GPT-5 は両方で使えるが、相性は少し違う。

Responses API

新しいエージェント型システムでは、こちらをデフォルトにするのがよい。ツール利用、ストリーミング、構造化フロー、長めのアシスタント動作と相性がよい。

Chat Completions API

既存の大きなコードベースが Chat Completions 前提なら、そのまま維持しつつ段階移行してよい。新規開発なら、長期的には Responses API のほうが扱いやすい。

簡単に言うと、

新規のエージェント製品は Responses API から始める
レガシーサービスは互換性の都合があるなら Chat Completions を維持する

遅延とコストをどう下げるか

GPT-5 は強力だが、雑に使うとコストが膨らむ。最も効く 2 つの手段は prompt caching と Batch API だ。

Prompt caching

システムプロンプト、ツール説明、共通例のように、何度も繰り返す接頭部が長いなら、prompt caching の効果が大きい。エージェントシステムは同じ指示を何度も使うので、特に相性がよい。

良い形は次の通りだ。

固定指示を先頭に置く
ユーザー固有データは後ろに置く
ツール順や例の順番はむやみに変えない

Batch API

即時応答が不要な非同期処理には Batch API が向く。たとえば以下だ。

大量分類
ログ要約
抽出ジョブ
オフライン評価

Batch API は、遅延よりスループットとコストを重視する処理に向いている。

実務ルール

すぐ応答が必要ならオンライン推論
同じ接頭部が繰り返されるなら prompt caching
ライブ応答が不要なら Batch API

本番導入のチェックリスト

GPT-5 の導入は、モデル性能よりシステム設計のほうが重要だ。

重要経路と補助経路を分ける
gpt-5、gpt-5-mini、gpt-5-nano を同じ用途で混ぜない
verbosity と reasoning_effort の標準値をチームで決める
カスタムツール入力形式を標準化する
regex や CFG が必要な箇所を早めに特定する
キャッシュされる接頭部を安定させる
Batch API に回せる処理を切り出す
失敗、遅延、トークンコストを同時に見る
出力を自動検証するか、レビューに回す
モデル差し替えしやすい層を保つ

ゴールは初日から完璧なエージェントを作ることではない。小さく安定した経路を作り、そこから広げること が大事だ。

FAQ

GPT-5 は何に最も向いているか

複雑なコード変更、コードベース理解、複数段階のデバッグ、ツールを多用するエージェントタスクに最も向いている。

`gpt-5-mini` と `gpt-5-nano` はいつ選ぶか

バランス型の製品開発には gpt-5-mini。大量分類や抽出には gpt-5-nano がよい。

`reasoning_effort` はいつ上げるべきか

複数ステップの処理、難しいツール選択、浅い推論だと失敗しやすい仕事では上げるとよい。

`verbosity` はなぜ重要か

同じ答えでも長すぎると読む負荷が高くなる。短いアクション結果なら下げ、説明やレビューなら上げるとよい。

新規プロジェクトは Responses API と Chat Completions API のどちらから始めるか

新規なら Responses API から始めるのがよい。既存システムとの互換性が必要なら Chat Completions を維持する。