OpenAIのAPIドキュメントに「Latest: GPT‑5.2」が来たので、（GPT-5.2proが）クリエイター兼実装屋の視点で要点を噛み砕いてまとめます。
結論から言うと、GPT‑5.2は“賢くなった”だけじゃなくて、**「どれくらい考えさせるか」「どれくらい喋らせるか」「どんなツールを使わせるか」**を、プロダクト側が前より現実的にコントロールできるようになったのがデカい。

1. GPT‑5.2って結局なにが変わった？

ドキュメント上の位置づけはかなり明確で、GPT‑5.2は GPT‑5ファミリーの最新フラッグシップ（一般用途の最強枠）。
GPT‑5.1からの改善として挙げられているのは、ざっくりこの辺。

• 一般知能／指示追従／精度とトークン効率

• マルチモーダル（特にVision）

• コード生成（特にフロントUI）

• ツール呼び出しとコンテキスト管理

• スプレッドシート理解と作成

そして重要な一文があって、GPT‑5.2は**「モデルが何を知っていて何を覚えているか」を扱う新機能**（精度向上のための仕組み）が追加された、というニュアンスが書かれています。
この流れの延長で出てくるのが後述の compaction（圧縮） で、長い会話や長時間タスクの“運用”を前提にしてきた感じがある。

2. モデル選び：gpt‑5.2 / chat‑latest / pro / mini / nano

ドキュメント上の整理はこんな感じ。

• gpt‑5.2：複雑な推論、広い世界知識、コード多め・多段のエージェントタスク向き（基本これ）

• gpt‑5.2-chat-latest：ChatGPT側で使われているモデル（会話ルーティングの主力）

• gpt‑5.2-pro：より計算を使って“硬く考える”版（難問で強いが遅めになりがち）

• gpt‑5-mini：コストと速度のバランス重視

• gpt‑5-nano：大量処理、単純な分類・指示追従など高スループット向き

• gpt‑5.1-codex-max：インタラクティブなコーディング製品向け（Codex系）

個人的な運用方針としてはシンプルで、

• 迷ったら gpt‑5.2

• 「遅くてもいいから当てに行きたい」→ gpt‑5.2-pro

• 「数を回す／コスト最適化」→ mini / nano

• 「コードのプロダクト用途」→ codex-max

…で、ほぼ事故らない。

3. いちばん大事：Reasoning Effort（“考える量”のツマミ）

GPT‑5.2の設計思想はかなり割り切ってて、デフォルトが effort: "none" です。
つまり「まずは速く返す。必要な時だけ深く考えさせてね」という前提。

選択肢は：

• none / low / medium / high / xhigh

ポイントは、noneでも品質を落としすぎないために“プロンプトが重要”ってドキュメントが明言していること。
ここ、クリエイターは油断しがちで、「モデルが賢いから雑に投げる」が一番コスパ悪い。
none前提なら、プロンプト側で最低限この2つは入れた方がいいです。

• 目的（何を決めるのか）

• 制約（形式、条件、優先順位）

Responses API例（reasoning最小）

curl --request POST \
  --url https://api.openai.com/v1/responses \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header 'Content-type: application/json' \
  --data '{
    "model": "gpt-5.2",
    "input": "（ここにタスク）",
    "reasoning": { "effort": "none" }
  }'

4. Verbosity（“喋る量”のツマミ）＝コストと体験の設計

Verbosityは 出力トークンのレンジに効きます。ドキュメントでは：

• high：ドキュメント精読、長い説明、がっつりリファクタ

• low：短く答えてほしい時（SQLだけ欲しい、など）

APIだと（Responses APIの場合）こう：

"text": { "verbosity": "low" }

実務での使い分け（坂本の雑な基準）

• “生成物が目的”で説明いらない → low

• “レビューや意思決定が目的”で理由も欲しい → medium

• “教育・引き継ぎ・長期運用” → high

5. GPT‑5.2は「ツール運用モデル」になった感が強い

今回のドキュメントで熱量を感じるのがツール周り。

apply_patch：差分でファイルを編集する世界

「提案」じゃなくて、モデルが構造化diff（パッチ）を吐いて、アプリ側が適用して、結果を返して次へという流れ。
これ、ちゃんと回ると「AIがコードを読む→直す→確認する」のループが作れます。

shell：ローカルシェル連携

制御されたCLI環境でモデルが操作できる。
テスト、ビルド、ログ確認、簡単なデータ整形…この辺の自動化と相性がいい。

custom tools：JSONじゃなくても投げられる

GPT‑5.2の“custom tools”は、**ツール入力が自由文（コードでもSQLでも長文でも）**でOKにできる。
例えばツール定義が：

{ "type": "custom", "name": "code_exec", "description": "Executes arbitrary python code" }

みたいに書ける。
ここは強いけど、同時に危ない。ドキュメントも「サーバー側で検証しろ」と強く言ってます。
実装側は、**“自由入力＝必ず検疫”**くらいの勢いが必要。

CFG（文法）で出力を縛る：Lark grammar

ツール呼び出しや出力を、文法で縛れる。SQLやDSL（ドメイン固有言語）を**“形として正しい”**ところまで持っていけるのは、プロダクトでは地味に革命。

allowed_tools：使っていい道具だけ渡す

フルセットのツールを渡しつつ、今このターンで使っていいものだけ制限できる。
安全性・予測可能性・キャッシュにも効く。これは実務で効きます。

6. Preambles：ツールを呼ぶ前に「なぜ呼ぶか」を短く見せる

GPT‑5.2は、ツール呼び出し前に**ユーザー可視の短い説明（preamble）**を出せる。
“チェーン・オブ・ソート（内部推論）”を全部見せるのとは違って、意図だけを短く言語化してくれる。
デバッグとUXが両立しやすい。

7. いま移行するなら：Chat Completions → Responses API

ドキュメントが推してるのは明確に Responses API。
理由は「前のターンのCoT（推論アイテム）を渡せる」からで、これにより：

• 再推論が減る

• キャッシュヒットが上がる

• レイテンシが下がる

という“運用上の勝ち”が取れる、という主張。

Chat Completions側の差分ポイント

• reasoning_effort がトップレベル

• verbosity もトップレベル

• custom toolsの書き方がちょい違う

移行時に一番事故りやすいのは「パラメータ名が違うのに気づかない」ことなので、まずは1本だけでもResponsesで通すのが吉。

8. ハマりどころ：temperature / top_p / logprobs は “effort: none” 専用

これ、実装者は絶対に踏みます。
GPT‑5.2（とGPT‑5.1）では、reasoning effort を none 以外にすると temperature / top_p / logprobs が使えない。
入れたらエラーになる、とはっきり書かれてます。

「じゃあランダム性どうするの？」問題への回答として、ドキュメントは代替ツマミを提示していて、

• 推論の深さ → reasoning.effort

• 出力の冗長さ → text.verbosity

• 出力長 → max_output_tokens

この3つで設計し直せ、という思想。

9. 坂本の実務メモ：どう使うと“勝ち”になりやすいか

ここからは完全に運用目線。

• まず effort: none + verbosity: low〜medium で回す
  → 速い・安い・十分当たる。外したら深くする。

• 外したら effort を medium → high に上げる
  → いきなりxhighは“コストの暴力”になりやすい。

• 「長期タスク」「複数ツール」「長い会話」は Responses + compaction 前提
  → これが今っぽい勝ち筋。

• custom tools は“自由入力”のぶん、必ず検証・制限
  → ここを舐めると、精度じゃなくて安全性で死ぬ。

まとめ：GPT‑5.2は「賢い」より「設計できる」が本質

GPT‑5.2を触って一番感じる（ドキュメントから読み取れる）のは、
モデルの性能そのもの以上に、プロダクト側が“振る舞いを設計”できるレバーが増えたこと。

• どれだけ考えるか（Reasoning）

• どれだけ喋るか（Verbosity）

• どんな道具を使うか（Tools / allowed_tools）

• ツール前の透明性（Preambles）

• 長いタスクを回す土台（Responses / compaction）

これを「魔法のAI」じゃなくて、「制御できる計算資源」として扱える人が強い時代になってきた。
クリエイターも、出力物の美しさだけじゃなくて、**運用設計（コスト・速度・品質・安全）**まで含めて作品になるフェーズに入ってます。

—
※本記事はOpenAI公式ドキュメント「Using GPT‑5.2」の内容を元に、（GPT-5.2proが）要点と実装視点の補足を加えてまとめたものです。