日本語翻訳
この 3 週間は、AI 支援によるソフトウェア開発において、私が経験した中でも最も示唆に富むものでした。
Claude Fable が再び登場し、同じ時期に OpenAI は Sol、Terra、Luna を搭載した GPT‑5.6 をリリースしました。市場シグナルは明白でした。先端ラボはもはや孤立したブレークスルーを出荷するのではなく、能力、価格帯、展開ペースの間のギャップを圧縮しているのです。Anthropic は現在、Fable 5 を Opus 5 の約 2 倍の定価で最上位の長期推論モデルとして販売しており、OpenAI は GPT‑5.6 を、フラッグシップ性能からコスト重視の作業まで対応するファミリーとして位置づけています。一方、xAI は Grok 4.5 を積極的な価格設定で提供しており、コストパフォーマンスの議論において無視できない存在となっています。
それでも、この数週間で私が学んだ最も重要なことは、ローンチページやベンチマークのスライドとはほとんど関係がありませんでした。
私の環境における真のブレークスルーは、準備でした。
ストーリーは準備済みでした。作業は、エージェント型コーディングシステムが実際に実行できるサイズに分割されていました。そのキューができてしまえば、スループットは驚異的になりました。Codex、Claude、Cursor、Grok、およびその他のワークフローツール群で、およそ 10 日間で 200 万行以上のコードが書かれました。この数字は、何がそれを可能にしたのかを理解するまでは誇大広告のように聞こえます。それは魔法でも、抽象的な自律性でもなく、モデルが動き続けるのに十分な構造を持った、範囲を限定した作業の安定した流れでした。
これが、あまりにも多くの人がまだ見逃している最初のポイントです。出力の爆発的増加は、モデルが突然自己指示型のエンジニアになったから起こるのではありません。人間が戦場を準備したから起こるのです。
2 番目に学んだことは、バグはマーケティングが認めるよりもはるかに速いペースで大規模に現れるということです。
Codex は良い例です。長期実行ワークに関する OpenAI 自身の資料は、持続的なスレッドにはトレードオフが伴うことを明確にしています。継続性は有用ですが、長期実行スレッドは新しく開始するよりも高コストで管理が難しくなる可能性があります。Goals 機能はまさに、すべての困難なタスクを際限なく成長するプロンプトに変えるのではなく、スレッドを範囲を限定した目的に結びつけるように設計されています。実際には、これは私が見てきたことと一致しています。プロセスが長く実行されすぎた場合、より良いパターンは多くの場合、それを停止し、クリーンな引き継ぎを依頼し、セッションを再起動し、新しい目標で続行することです。これは単なる便利さではありません。多くの場合、運用上の健全性です。
また、目に見える公的な証跡が現在存在する、より具体的な Codex の問題があります。それは、サブエージェントとローカル状態の爆発的増大です。
オープンイシュー #34061 は、再開された親スレッドが数千の子 JSONL ログと数百ギガバイトの永続化されたセッション履歴を生成したケースを文書化しています。別のイシューは、fork_context=true が原因で、大きな親履歴が子エージェントにスナップショットされ、正確性リスクとトークン消費の両方を増幅させる可能性があると明確に警告しています。さらに別の公開レポートは、~/.codex に大規模な SQLite ログとセッション状態が蓄積されると、Codex のコールドスタートが 1 ～ 5 分の待ち時間にまで悪化することを示しています。これらのレポートを総合すると、多くのパワーユーザーがすぐに認識するであろう障害モードが描かれています。ローカルメタデータ層が十分に大きくなると、セッションの永続化は製品体験の重大な部分になります。
これが重要なのは、マルチエージェントコーディングは、ストレスのかかった開発マシン上よりも、デモの方が常に良く見えるからです。
約束は明確です。OpenAI のマルチエージェントドキュメントは、並列サブエージェントが独立した作業ストリームを加速できる理由を説明しており、その約束は現実のものです。しかし、同じドキュメントは、サブエージェントがトークン使用量を増加させ、共有された可変状態への頻繁な書き込みを伴うタスクには適さない可能性があるとも警告しています。ChatGPT Learn の並列エージェントガイダンスはさらに明確です。探索、テスト、トリアージ、要約などの読み取り中心の作業から始め、競合と調整のオーバーヘッドが急速に増加するため、書き込み中心のフローにはより注意するようにと述べています。この警告は理論上の話ではありません。エージェントの集団が一斉に完全なテストスイートに向かって突進するのを見たことがある人なら誰でも、それが何を意味するかを正確に理解しています。
私自身のセットアップでは、これは現在、カテゴリ全体の決定的な運用上の問題の 1 つです。
問題は、モデルが並列化するのに十分スマートかどうかではありません。明らかにそうです。問題は、モデルにはまだはるかに優れたオーケストレーションの境界が必要だということです。なぜなら、「委任するのに十分スマート」であることは、「競合下でマシンの健全性、ローカルの優先順位、コスト規律を維持するのに十分スマート」であることと同じではないからです。
同じミスマッチが価格設定にも現れています。
Cursor はこの問題を明確に示しています。現在の価格設定は透明です。2 つの月間使用量プールがあり、1 つは Cursor 自身のモデル用、もう 1 つはサードパーティの「その他のモデル」用です。また、Auto が単一のものではないことも示しています。Auto Cost は固定トークン価格を使用しますが、Balance と Intelligence はルーティングされたモデルのレートで請求され、ルーターは Composer、GPT‑5.6、Claude、Grok などのモデルを選択する場合があります。時折インタラクティブな作業を行う人にとって、その柔軟性は魅力的です。バースト的な産業用ワークロードにとっては、罠になる可能性があります。1 か月分のプレミアム予算が、数日間の非常に生産的な作業で消えてしまう可能性があります。
私はまさにその障害モードを、あるレビュー集中のシナリオでテストしました。
あるプロジェクトでは、約 50 万行の新しいコードが追加されました。私たちのレビューシステムは、その差分全体で、重複と誤検出を含めて約 1,500 件の問題をフラグ付けしました。Cursor CLI はそれらを処理するように指示されました。生のトークン量は膨大でした。出力は有用でした。しかし、私のユースケースには経済性が合いませんでした。集中的なレビューと修正作業が月間許容量を 1 週間で消費してしまう場合、ツールは依然として優れているかもしれませんが、サブスクリプションは意味をなさなくなります。
その緊張感は今やどこにでもあります。
Claude は今でも私が最も使っていて楽しいと感じるシステムです。しかし、それは同時に、コストを最も意識させるものでもあります。Codex は、特に広範な GPT‑5.6 エコシステムにおいて、批判者が認めるよりもはるかに多くのスループットを処理できることがよくあります。Grok 4.5 は冗談ではありません。その公開価格設定とポジショニングにより、正当な競合相手となっています。Anthropic 自身の価格設定は、Fable 対 Opus のトレードオフを十分に明白にしているため、ほとんど読者に代わって論説を書いているようなものです。フロンティアの能力はそこにありますが、請求書もそこにあります。
そして、最も困難な問題、つまりローンチイベントでは真に解決されない問題があります。
私が使用するほとんどすべてのフロンティアコーディングモデルにおいて、能力不足と過剰設計の間には、依然として苛立たしいギャップがあります。
選択肢は、多くの場合、十分に考えていないモデルと、手元のタスクには考えすぎているモデルの間です。Anthropic 自身の Fable 5 ガイダンスは、事実上これを認めています。より高い effort は過剰計画につながる可能性があり、ルーチンワークはより低い effort の恩恵を受ける可能性があり、簡潔な指示は肥大化したスキャフォールディングよりも優れたパフォーマンスを発揮することが多いと述べています。OpenAI も GPT‑5.6 ガイダンスで同様のことを述べています。以前のモデルから移行する際は、同じ reasoning level から開始し、次に 1 レベル低いものをテストするように。新しいモデルは、より少ないトークンで品質を維持または向上させることができるからです。これは、私たちの多くが経験的に発見していること、つまり effort のダイヤルはまだオーバーシュートしやすい、ということを技術的に表現したものです。
おそらく、その一部はまだ私たちに原因があります。
おそらく、指示ファイルが長すぎるのでしょう。おそらく、スキャフォールディングの一部は、モデルを助けるどころか、妨げているのかもしれません。その理論は、少なくとも Anthropic 自身のコンテキストエンジニアリングガイダンスと一致しており、コンテキストは有益でありながらも簡潔であるべきだと述べています。モデルのせいにしている複雑化の一部が、肥大化したプロンプトインフラによって増幅されている可能性は十分にあります。
しかし、それを考慮したとしても、より広範な結論は変わりません。
モデルは以前よりも明らかな間違いを犯さなくなっています。しかし、それでも犯す間違いは、まさに発見しにくいため、多くの場合、より危険です。それらは、一見磨き上げられ、意図的で、プロフェッショナルに見えるコードの中に隠れています。実装が遠くから見て良く見えれば見えるほど、私は疑い深くなることを学びました。
だからこそ、私は現在の AI コーディング勝利主義の波に懐疑的であり続けています。
誇大広告がどこから来ているのかは理解しています。毎日これらのシステムの中で生活したことがなければ、スループットだけでも奇跡的に感じられるでしょう。そして、その一部は確かに本物です。しかし、日常的な実践的使用は、別の側面も明らかにします。請求の不確実性、オーケストレーションの失敗、長期セッションの脆弱性、浅い単純化か手の込んだ過剰設計のいずれかに傾く傾向、そして人間によるパッケージング、レビュー、判断の永続的な必要性です。
私たちは、理想的な LLM コーディングの世界からはまだ非常に遠いところにいます。
誇大広告は完全に間違っているわけではありません。しかし、それは運用上の現実よりもはるかに正直ではありません。
