Codex 5.6 SolがFableを超えたと感じた理由

最近、AIに「コードを書いて」と頼むことが減りました。

代わりに「この状態まで持っていって」と頼んでいます。

この違いは、料理のレシピを書いてもらうことと、実際に食卓へ料理を出してもらうことくらい大きい。レシピが正しくても、材料が足りず、火がつかず、皿に載らなければ夕食にはなりません。

今週、FableとCodex 5.6 Solを二つの本番案件で比べました。

一晩かけても公開できなかった

一つ目は、1toAllというコンテンツ配信Agentを11agentsへ統合し、サーバーへ公開する仕事です。

二つのリポジトリ、プロジェクトごとのワークスペース、ログイン、永続データ、Cloudflare、デプロイが絡みます。

Claudeと一晩作業しました。個々の修正はもっともらしく、説明も明快でした。でも全体は動きません。設定を直すとログインが壊れ、新版を送ってもサーバーは旧releaseのまま。毎回「あと少し」に見えました。

Solは共有メモリと引き継ぎ、履歴を読み、現場を再構成しました。どのコードをどちらのリポジトリが持つか、なぜ本番データをreleaseで上書きできないか、Cloudflareが認証へどう影響するか、実際に何が稼働しているかを確認しました。

そして修正、テスト、デプロイを続け、本番のrelease SHAが新しいcommitと一致するところまで見届けました。

「残りは人間がやってください」がありませんでした。

きれいなサイトは、完成したサイトではない

二つ目は、モデルルーティング基盤Flatkeyの公式サイトです。

見た目は完成していました。でも検索は動かず、モデルと言語は切り替わらず、一部のボタンは飾りでした。登録導線、API情報、key prefix、価格、SLAにも古い情報が残っていました。

200が返ることと、製品が使えることは別です。

Solに渡したのは細かな修正表ではなく、「安全に公開できる状態にする」というgoalでした。

実製品、ドキュメント、本番構成と照合し、偽の操作や古い情報を修正。いきなり本番へ出さず、canary環境で検索、モデル選択、言語、料金、コード例、リンクを含む20の操作テストを実行しました。さらに12の本番経路、redirect、analytics、主要モデルを確認してからtrafficを切り替え、rollbackも残しました。

Flatkeyをここで挙げるのは広告のためではありません。モデルルーティングが実際の基盤になると、サイト、ドキュメント、価格、runtimeの挙動が一致している必要があるからです。

では、何が変わったのか

コード生成は最低条件になったのだと思います。

本番の仕事は、目標を理解し、現実の文脈を復元し、複数のシステムを変更し、新しい問題を発見し、修正し、テストし、公開し、最後の状態を確認するループです。

途中で止まれば、それまでの価値がゼロになることもあります。

Fableは今も強いgeneratorです。速くページを作り、正しいコードも書けます。ただ、私の案件では、人間が背景を補い、タスクを分け、漏れを指摘し、最後の検収を持つ必要がありました。

Solは結果に責任を持つAgentに近づいています。

共有メモリでゼロからやり直さない。

goalを手放さない。

画面、権限、データ、deploy、本番を自分で確かめる。

失敗時のrollbackまで「完了」に含める。

これは20%の効率差ではありません。

仕事を手伝ってもらえるか、仕事そのものを任せられるかの差です。

ここからは予想。外したらスマヌ

Agentはツールから組織単位へ変わっていくと思います。

人間は「なぜやるか」「どこまでを完成と呼ぶか」「越えてはいけない線は何か」に判断を集中する。共有メモリ、自動検証、デプロイ、Flatkeyのようなモデル基盤、rollbackが、その間をつなぐ組織のOSになる。

次の競争は、誰が一番きれいなレシピを書くかではありません。

曖昧でも本物のgoalを受け取り、面倒な細部を通り抜け、食卓まで料理を運べるか。

私はそこを見たいと思っています。