でも、コストはどうなんだろう？私の理解ではo3はかなり高い運用コストがかかる。GPT-5はもっと安いの？もしそうなら、性能がo3に近くて安いなら、それでも良い改善になるかも。

まあ…彼ら自身がその情報を投稿に含めてるから、あんまり驚きじゃないよね。

個人的には、コーディングのためにもう10倍の改善を待とうと思ってる。今のままだと、明らかにそれが必要だから。

長時間のタスクにおけるコンテキスト認識は、長時間のタスクを持ってないよ、LLMでもそうじゃなくても。問題を小さくて管理しやすい部分に分けて、それから組み立てるんだ。人間もLLMも長時間のタスクには向いてない。

もしGPT-5が本当に400kのコンテキストを持っているなら、それがOpusを意味のある形で超えるために必要な全てかもしれない。

「OpusとGPT-5の間には、ソフトウェア開発の専門知識に大きな違いがあるとは言えない。もしソフトウェア開発の専門知識に大きな違いがなければ、GPT-5はほぼ10倍安いので、Opusを圧倒することになる。」

ちょっと曖昧だけど、OPがこれを指摘してた: >「GPT-5は、今までリリースした中で最強のコーディングモデルです。コーディングのベンチマークや実際の使用ケースでo3を上回り、Cursor、Windsurf、GitHub Copilot、Codex CLIのようなエージェント的なコーディング製品で輝くようにファインチューニングされています。GPT-5は私たちのアルファテスターを驚かせ、多くのプライベートな内部評価で記録を打ち立てました。」

完全に同意だね。今のところ、フロンティアのLLMは、十分なコンテキストがあれば、僕が投げるほとんどの問題を解決できると思ってる。失敗したときに彼らが何のコンテキストを欠いているのかを考えるのに、ほとんどの時間を使ってるんだ。だから、僕にとって一番助かるのは、もっと集中したコンテキスト収集の能力だね。僕の使い方では、関連するコードファイルや問題、ディスカッション、PRに本当に焦点を当てる必要がある。GPT-5がこの点で進展をもたらしてくれることを期待してるよ。ベンチマーク結果には完全には反映されていないけど、Opusよりも安く同じような結果を出せるのは確かに期待できるね。

僕の会社（Charlie Labs）では、数週間前にアクセスを得てから、長時間のタスクにおけるコンテキスト認識で素晴らしい成果を上げてるよ。10個の実際のGithubの問題を解決する評価を行って、Claude Codeと比較したんだけど、差が驚くほど大きかった。こちらに僕たちのまとめがあるよ: https://charlielabs.ai/research/gpt-5 たいてい、僕たちのタスクは30〜45分かかるし、LinearやGithubでの大規模なコンテキストスレッドを扱っても、途中で方向が変わってもつまずくことはないんだ。10個の問題はそんなに包括的じゃないけど、方向性としては非常に印象的だったし、今後のパフォーマンスを理解するためにこれを基にしていくつもりだよ。

来週、GPT-5についての評価を聞きたくて返信したよ。

どれくらいのプロダクトを作ったら「良い」「信頼できる」と言えるの？私の経験では、70時間で「動く」PoCができるけど、初期の機能セットを超えて、例えばAPIの初稿を作ると、機能を重ね始めたときにうまくいくのかな？

ここも同じだけど、私はRooを使ってて、ClaudeとGemini pro 2.5がうまくいってるよ。

「とはいえ、私の経験では、実際に信頼できる方法で動作するモデルはClaudeモデルだけだ。最近のCursor（1.4）のツールアップデートが、Geminiのようなモデルでのツール使用をかなり信頼性の高いものにしたようだ。以前は簡単なファイル編集すら苦労していたけど、今はほぼ毎回編集がうまくいく。」

魔法はプロンプトやツールの使い方、ファインチューニングにあるね。OpenAIの推論モデルはより良いコードを書くし、問題解決も得意だけど、Claudeのコードはもっと役立つ製品だと思う。モデル自体は弱いけどね。

これのいくつかはスタックに関係してるかもね。最近、Convexについてのt3.ggの動画を見たんだけど、その性質がAIに正しい答えを出させることが多いみたい。ここ数日それを試してみたけど、彼に同意すると思う。開発のワークフローは根本的に変わると思う。これを最大限に活用するには、複数のAIを並行して動かす必要があるから、ただコーディングに飛び込むのではなく、PMツールでチケットをたくさん書いて（今のところLinearがレースに勝ってるみたい）、どれがマージコンフリクトを起こさずに並行して実行できるかを考えたり、AIに考えさせたりして、複数のチケットをIDEやターミナルに引っ張り込んで、タブを切り替えながら必要に応じて作業することになると思う。今はまだこれを実行してないけど、切り替えが必要だと感じてるし、Warpがこのようなワークフローに最適かもしれないと思ってる。必要なときにIDEに切り替えて編集することもあるだろうしね。あ、これを実現するにはgit worktreesを使う必要があるよ。

出力: $10 / 1Mトークン これは面白いね。明らかに（少なくとも）2つの基盤モデルから成る「モデル」に対して、フラットなトークン価格を使ってるのが。片方はもう一方よりもずっと計算コストが低いし、プロンプトを通じてどのモデルが使われるかをある程度影響できるのも興味深い。おそらくこの価格モデルは、基盤モデルがどれくらい使われるかの予測に基づいてるんだろうけど、それが本当に当たるのか、ユーザーが期待以上に良いモデルを使おうとするのか、あるいは価格があまりにも膨らんでいて関係ないのか、気になるな。

それが発表の中で唯一ワクワクした部分だったよ、ハハ。早く触ってみたいな。もうGoogleやOpenAIのような他社の構造化出力APIでいくつかの問題に直面してるけど、彼らはこの点で素晴らしい仕事をしてるね。

正直言って、これが一番の改善点だと思う。ツールをたくさん呼び出す作業をしているんだけど、モデルが偽のツールを作り出すのは大きな問題なんだ。さらに悪いことに、モデルがツール呼び出しを生成せずに直接応答を作り出すこともある。新しいトレーニング報酬が幻覚を抑えたりツールをスキップするのを防いだりして、いい方向に進むことを願ってる。

Q: プロダクトマネージャーって何をするの？ GPT4: エンジニアリング、営業、マーケティング、財務、外部パートナー、サプライヤー、顧客と協力して……など。 GPT5: わからない。これを言った瞬間、AIは啓発された。