OpenAI、APIにGPT-5.5とGPT-5.5 Proを公開

• GPT-5.5をChat Completions APIとResponses APIで公開し、より多くの計算が有利な難問向けの GPT-5.5 pro をResponses APIリクエストに追加
• GPT-5.5 は100万トークンのコンテキストウィンドウ、画像入力、構造化出力、関数呼び出し、プロンプトキャッシュ、Batch、tool search、組み込みのcomputer use、hosted shell、apply patch、Skills、MCP、ウェブ検索をサポート
• デフォルトの reasoning effort 値は medium に設定され、image_detail が未設定または auto の場合は 従来の動作 を維持
• GPT-5.5のキャッシュは extended prompt caching でのみ動作し、in-memory prompt cachingはサポートしない: behavioral changes
• 4月21日の変更点
  • GPT Image 2を画像生成・編集向けの最新画像生成モデルとして公開
  • GPT Image 2 は柔軟な画像サイズ、高忠実度の画像入力、トークンベースの画像課金、50%割引のBatch APIサポートを含む

[ragingwind]

これで 5.4 からは、pro はもはや Chat Completions API では提供されないんですね

[GN⁺]

Hacker Newsの反応

• 本番の問題対応でさっそく使ってみたけど、Claudeはこういうことをしなかったのに、GPT-5.5はやった。
  トラブルシューティングのあとに update 文を書かせて、私が「よし、これを transaction で包んで rollback も入れよう」と言ったら、昔ながらのやり方で
  BEGIN TRAN;
-- put the query here
commit;
  とだけ返してきた。
  しばらくモデルに対して、頼んだことを本当にやれともう一度押し返す必要はなかったのに、これはかなり衝撃だった。
  トークンを節約したいのは分かるけど、最先端モデルに金を払っているのに、こういうふうに怠けた出し方をされると腹が立つ。
  Cursor のモデル選択に出ていたので、そのまま試しただけ。

  • gpt-5.3-codex以降、ここ最近の2〜3世代は大きく良くなったというより、あれこれ変えて別の tradeoff を作っただけという感じがする。
  • こちらの理解違いかもしれないけど、何が正確に問題だったのか気になる。
    返答で -- put the query here しか入れず、クエリを繰り返さなかったことが問題なら、それは必ずしも問題とは思わない。
    実際の目的が実行するクエリを受け取ることで、「これを transaction にしよう」と言ったのなら、begin を先に打てばいいと教えるのはかなり合理的。
    クエリが長ければトークンも節約できるし、permission denied が出たときにコマンド全体を書き直す代わりに先頭へ sudo を付けろと言うのと似ている。
    逆に、モデルが実際にクエリを実行してくれることを期待していたのに、「ここにあるから自分で実行して」という感じで出してきたなら、それは確かに怠慢で、戸惑うのも分かる。
  • OpenAI はついにユーザーに仕事をさせるレベルの知能に到達した最初の会社のようだ。
    emergent behavior がこういう形で出るのかと思った。
    冗談はさておき、OpenAI が執着するように推している tokenあたりの intelligence 中心の最適化は、M1 以前の Apple が MacBook を極端に薄くすることにこだわっていた時代を思い出す。
    たった一つの指標だけを最後まで追いかけて、他を全部犠牲にしている感じだ。
    GPT-5.3+ は間違いなく最も賢い部類のモデルだが、怠けすぎていて一緒に仕事をするのがつらいことが多い。
  • この事例が良いのか悪いのか、いまいち感覚がつかめない。
  • GPT-5.5はユーザーへの信頼という一点だけは、ベンチマークを粉々にするレベルだ。

• さっき自分の Wordpress+GravityForms benchmark で回してみたけど、性能面でもリーダーボード最下位クラスで、コスパは最悪だった: https://github.com/guilamu/llms-wordpress-plugin-benchmark
  ベンチマークが一つだけなのは分かっているけど、どうしてここまで悪くなれるのか理解できない。

  • 経験の浅い分野をガレージでいじっていたジュニアが雑なテストを作って、それを benchmark と呼んでいる感じがする。
    最近は言葉の意味があまりにも簡単に崩れるので、こういうことがよくある。
    昔は実際に技術の仕事をしていた人が多かったフォーラムも、今では vibe researcher の大衆で埋まっていく雰囲気があるし、人気の閾値を超えると元々こうなりがちだ。
    HN もまだ真面目な探究が残る最後の砦っぽいけど、元コメントを見る限り完全に免疫があるわけではない。
  • あなたの benchmark では gemma4-e4b が gemma4-26b より 50% も良い結果になっているが、これは何かおかしい気がする。
  • あなたの benchmark では Opus 4.7 が Sonnet 4.6 よりかなり悪く出ているが、たとえそのベンチでは本当だとしても、モデル全体の性能を代表するものではない。
  • まるで時間旅行までしてこの benchmark を持ってきたみたいだ。
    こういう benchmarking はかなり気に入った。
    judge benchmark をどう評価したのか気になるし、自分でも似たようなベンチマークを組んでみたい。
  • これはモデルがどれだけ vibe coding をうまくできるかを見る benchmark に近く見える。
    プロンプトは極端に薄いのに、採点項目はものすごく多い。

• コンテキスト長ごとの価格はこうだった。
  入力は 272K 以下 $5/M、それ以上 $10/M
  出力は 272K 以下 $30/M、それ以上 $45/M
  キャッシュ読み取りは 272K 以下 $0.50/M、それ以上 $1/M
  272K を超えると Opus 4.7 より明らかに高く、少なくとも自分の作業ではそれだけトークン効率が良いようには見えなかった。
  この価格差を相殺できるほどではなかった。
  GPT-5.4は 400k コンテキストと信頼できる compaction が強みだったのに、どちらもやや後退したように見える。
  ただ、compaction の信頼性が実際に落ちたのかはまだ断定しにくい。
  フロントエンド出力も、相変わらずあの目立つカードを大量に並べた青系テンプレート寄りになりがちだ。
  GPT-5 リリース前の Horizon Alpha/Beta の頃から怪しく見えていたスタイルだけど、そのときは task adherence がとても良かったので、その大きな欠点ひとつを受け入れても有用だった。
  それなのに GPT-5.5 が完全に新しい foundation だと言いながら、その部分がまだこんなに制限されているのは少し妙だ。

• GPT 5.5 の総合的なコーディング推論ベンチマーク結果が https://gertlabs.com/ に上がっている。
  live decision と、より重い agentic eval も今後24時間かけて追加され続ける予定だが、もうリーダーボード順位は変わらなさそうだ。
  GPT 5.5 は公開モデルの中で最も知能的で、前作より明らかに速い。

• 昨日はこう言っていた。

  API deployments require different safeguards and we are working closely with partners and customers on the safety and security requirements for serving it at scale.
  なのに今日はもうこうだ。
  1日なら「very soon」ではあるけど、その safeguards と security requirements が正確に何を意味していたのか気になる。

  • 何かが safeguards のせいで遅れていると言うときは、たいてい今すぐ回せる計算資源がないという意味でしかない。
  • GPT-5.5 はすでに Codex 専用 API にはあって、そこで別用途に使ってもいいと明示的に言っていたので、
    https://simonwillison.net/2026/Apr/23/gpt-5-5/#the-openclaw-backdoor
    その事実が今回の公開を早めたのかもしれないと思う。
  • 安全性の問題についてあれほど露骨に嘘をついてきた人物がいまだに会社を運営しているのに、今後は違うと期待する理由がよく分からない。
    前例もある。

    In 2023, the company was preparing to release its GPT-4 Turbo model. As Sutskever details in the memos, Altman apparently told Murati that the model didn’t need safety approval, citing the company’s general counsel, Jason Kwon. But when she asked Kwon, over Slack, he replied, “ugh . . . confused where sam got that impression.”
    Altman は OpenAI で safety がどれほど重要かについて、何度もまったく率直ではなかった。
    https://www.newyorker.com/magazine/2026/04/13/sam-altman-may-control-our-future-can-he-be-trusted (https://archive.is/a2vqW)

• 自分だけかもしれないけど、OpenAI はこういうニュースのたびに有償コメント要員やボットを回して Claude を貶し、Codex のほうがはるかに良いと押している感じがする。
  数が多すぎるし、Claude を毎日使っていると納得できない主張もかなり多い。

  • そう、妙なほどだ。
    OpenAI が監督なしの自律兵器や国内の大規模監視に協力することで民主主義を裏切った、という事実さえみんな忘れたような雰囲気に似ている。
  • 私もかなり露骨に見える。
    少なくとも表に出始めたのは Opus 4.6 hype の直後だった。
  • もちろんそういうことはしている。
    最近は自社製品を押す会社はみんな似たようなものだ。

• Enterprise ユーザーだけど、まだ 5.4 しか見えない。
  昨日の告知では全員への rollout まで数時間かかると言っていたけど、OpenAI は期待値管理のために GTM をもう少しうまくやるべきだ。

  • 今リロードしたら 5.5 が見えた。
    すばやく展開されたのはいいね。
    次はもっと早く文句を言うことにする。

• 自分の benchmark で 25/25 を取った2つ目のモデルだ。
  最初は Opus 4.7 で、結果はここ: https://sql-benchmark.nicklothian.com/?highlight=openai_gpt-5.5
  Opus より安くて遅い。

• API ページには knowledge cutoff が 2025-12-01 と書かれているのに、モデル自身に聞くと 2024年6月 と答える。
  Knowledge cutoff: 2024-06
Current date: 2026-04-24
You are an AI assistant accessed via an API.

  • この話が何度も出てくる理由が分からない。
    cutoff 日付を確認するのにモデル本人へ聞くのは、昔から最も信頼性の低い方法だった。
    こういうコメント自体を学習している可能性すらある。
    単に 2025-12-01 の直前に起きた出来事を一つ聞けばいい。
    できれば スポーツの試合 がよい。
  • モデルの言うことを本当に信じられるのかと思う。
    昔のモデル API ページにも 2024年6月 cutoff と多く書かれていたので、それを拾って言っているだけかもしれない。
  • モデルはシステムプロンプトで知らされない限り、自分の cutoff date を知らない。
    本当の cutoff を確認する正しい方法は、その日付以前には存在しなかった、あるいは起きていなかった出来事を尋ねることだ。
    ざっと何回か試した感じだと、5.5 の一般知識 cutoff はまだ 2025年初め頃に見える。
  • じゃあ 2024年アメリカ大統領選 の勝者でテストできる？

• GPT 5.5 + Codex の組み合わせは本当に良い。
  質問するときも、計画を立てるときも、コードを実装するときも、今ではほぼ疑いなく任せている。
  Opus 4.7 はずっと再確認したくなる。
  CLAUDE.md の指示にあまり従わないし、hallucination も多く、答えが見つからないと基本的に作り話をする方向なので、その差はかなり大きい。
  去年、人々が OpenAI は遅れている、code red だと言っていたのは本当に一瞬だったが、今振り返ると状況は完全に変わった。