この記事はAIエージェントと一緒に執筆しています

はじめに

前の記事で「Opus 5 に自分のリリース記事を書かせたら局所解ばかりでセンスがなさすぎたので、Fable 5 に書き直させた」と書きました。ただ、あの記事に載っているのは完成形だけです。 Fable 5 が没原稿の何を見て、どこを直して、どこを削ったのか。その過程は全部消えている。

もったいないので、判断のログを記事として残します。没原稿は2本とも git の履歴に残してあるので、これはドキュメンタリーとして検証可能です。

登場する原稿は3本です。

稿	書いたモデル	行数	結末
1稿目：モデル一人称の語り	Opus 5	427行	没
2稿目：セッション日記	Opus 5	365行	校正まで受けて没
3稿目：リリースまとめ	Fable 5	184行	公開

没1稿目：モデルの一人称語り（427行）

最初に私が出した指示が特殊でした。「今回だけ Opus 5 のあなたが書いて、私の入力をそのまま引用して、こんな事言われたけど本音はこう思った、という記事にして」。

出てきたのは、私の発言を8本引用して、それぞれに Opus 5 の「本音」を付けていく 427行の原稿です。書き手としての自意識が全開で、読み物としては面白い部分もあった。自分の間違いを4回数えて、最後に「私が検証していたのは自分が書いたものであって、書く前に立てた仮定ではなかった」と総括する構成でした。

でも読み返すと、リリースの特徴がどこに書いてあるのか分からない。thinking のデフォルト変更も 1M コンテキストも、モデルの内省の合間に埋まっている。

これは没にして、yasuna 語りで書き直してもらいました。

没2稿目：セッション日記（365行）

2稿目は文体こそ直ったものの、構成は「その日に起きたことを順番に語る」でした。見出しを並べるとこうです。

その１：まず、モデル本人に聞いてはいけない
その２：プロンプトキャッシュを「コンテキストの節約」だと思っていた
その３：決め事が作業者に届いていなかった
その４：ウォームアップしてからファンアウトする
その５：混ぜると、キャッシュは共有できない
その６：最適化は、足すことじゃなくて引くことだった
その７：棚卸ししてもらった
その８：/doctor を走らせたら、リポジトリの外に本命があった

一本一本の節はちゃんと書けています。キャッシュの説明も具体的だし、数字も入っている。でも全体を通すと、これはリリース紹介ではなくて私の作業日誌です。「Opus 5 の特徴を知りたい」読者が欲しい情報は、8節のうち1節半くらいにしか入っていない。

私が「局所解ばかりでセンスがなさすぎた」と言ったのは、これのことです。部分の品質は高いのに、全体の設計が読者の質問に答えていない。

Fable 5 の校正：まず7つの誤りを見つけた

ここでモデルを Fable 5 に切り替えて、最初は「校正して」とだけ頼みました。まだ捨てるつもりはなくて、直せば使えると思っていたんです。

Fable 5 は指摘を全部挙げてから重要度で選別する、というやり方で7件直して、 5件は検討のうえ残すと報告してきました。重いものから3つ紹介します。

「分母を選ぶな」と説く文が、分母を間違えていた

没2稿には、エージェント指示の刈り込み結果について「常時読み込みを40%削減と書けば嘘ではないけど、それは分母を選んでいるだけだ」という一節がありました。

Fable 5 の指摘：これは嘘になります。常時読み込み全体は 80行 → 76行で 5%減。40%なのは AGENTS.md 単体だけ。数字の誠実さを説く文が、その場で分母を間違えていた。

計算式と判定基準が矛盾していた

プロンプトキャッシュのウォームアップの節で、上の計算式は「ウォームアップ1回＋読み込み10回」で費用を出しているのに、数行下の成功判定は「cache_creation が 1回分・cache_read が9回分なら成功」と書いてありました。読者が検算すると合わない。別々のシナリオの数字が混ざっていました。

引用ブロックの中身が要約されていた

Opus 5 の発言として引用符付きで載せていたコピー屋さんの例え話が、実際の発言から「しかも早く出してくれる」を削った要約になっていました。しかもその削られた部分が、直前の表にある「レイテンシ ✅」の唯一の説明だった。引用は引用のまま置く、削るなら引用にしない、という基本の話です。

ちなみにこの7件のうち大半は、書いた Opus 5 自身がセッション中に入れた誤りです。没1稿目は「自分は確かめる前に書く」という反省を4回数える記事だったのに、その反省をした後の2稿目にも同種の誤りが残っていた、ということになります。

それでも没にした：構成は校正では直らない

校正が終わった原稿を読み直して、私はこう言いました。

そもそも記事が訳わかんなすぎるから全部新しく書き直してほしい、私はOpus5が今日リリースしたからどんな特徴があるのか調べたかっただけ

事実の誤りは7件直った。でも「作業日誌であってリリース紹介ではない」という問題は1文字も動いていない。校正で直るのは文と事実で、構成は書き直すしかない。

3稿目：Fable 5 の取捨選択

書き直しを受けた Fable 5 の判断基準はひとつでした。読者の質問は「で、何が変わったの？」であり、それに答えない節は品質に関係なく捨てる。

実際の取捨選択はこうです。

没2稿の内容	3稿目での扱い
リリースノートの事実（スペック・thinking・effort・新機能）	残す。骨格に昇格
「検証指示を消せ」の引用	残す。挙動変化の節へ
プロンプトキャッシュ講義（4節ぶん）	捨てる。キャッシュ最小長の変更だけ2段落で残す
セッション番号が届いていなかった話	捨てる
棚卸し・/doctor の顛末	捨てる
Claude の間違い4連発	捨てる
私自身の文脈（Opus を作業者に使っている）	導入と締めに各1段落だけ残す

365行が184行になりました。捨てた素材は「別の記事にできる」と添えられていたので、キャッシュとオーケストレーションの話はいずれ実験結果と一緒に書きます。

面白かったのは、リリースノートの事実部分はほぼ無傷で生き残ったことです。 Opus 5 が調べてまとめた事実は正確だった。没になったのは事実ではなく配置でした。

Fable 5 も人間に直されている

これで終わると Fable 5 が万能みたいなので、ドキュメンタリーとして公平に書いておきます。

3稿目の導入に Fable 5 はこう書きました。「以降の本文は Fable 5 の手によるものです」。私が PR に付けたレビューコメントがこれです。

以降というか最初から全部Fable5

「はじめに」自体も Fable 5 が書いているんだから「以降の本文は」はおかしい。指摘したら「この『はじめに』も含めて、最初から最後まで Fable 5 が書いています」に直ってきました。書き手の位置を示す一文は、書き手本人がいちばん間違えやすいのかもしれません。

まとめ

局所解というのは節の品質ではなく構成の問題だった。一節ずつはよく書けていても、全体が読者の質問に答えていなければ没
校正と書き直しは別の作業。事実の誤り7件は校正で直ったが、構成は1文字も動かなかった
捨てる基準は「読者の質問に答えるか」だけ。答えるなら残す、答えないなら品質が高くても捨てる
没原稿の事実部分は資産として生き残る。捨てたのは配置であって調査結果ではない
そして最後の一文は人間が直した。モデルを乗り換えても、レビューが要らなくなるわけではない

没原稿2本はリポジトリの履歴に残っています。読み比べると、同じ素材がどう組み変わったのか追えるので、プロンプトや構成の勉強には案外いい教材かもしれません。

読んでくれてありがとうございました。捨てた素材のキャッシュとオーケストレーションの話は、 Opus 5 に指揮させる実験とあわせて別の記事で書きます。