LLM は発散する。私は収束させる側でありたい

LLM は発散する — n314 氏のテーゼと、私が腑に落ちた瞬間

LLM の出力には「広く拾って足していく発散」の才能はあっても、「複数の問題を一つの仕掛けで同時に解く収束」は混じりにくい。Zenn の n314 氏が書いた「LLM は発散させ、人間は収束させる」を読んで、auto-publish パイプラインを 1 ヶ月運用してきた違和感の正体が、1 行で言語化されたと感じました。

n314 氏の主張はおおむね次の対比に集約されます。LLM は個別事例を網羅して足していく発散が得意で、複数の問題を一つの仕掛けで同時に解く収束（アイデアと呼べる種類のもの）が苦手だ、という指摘です。Git のコミット、マリオのキノコ、SQL の最適化など、複雑性を減らしながら複数の課題を同時解決する形の解は、LLM の出力にはなかなか混じりません。

私が運用している auto-publish は、Claude Code を 6 つのカテゴリ別スキルとして launchd で叩く構成です。月曜の朝に engineering、火曜に design、水曜に process、というふうに、週 7 本の頻度で AetherEchoes に記事を投稿しています。1 ヶ月続けたあとに気付いたのは、Claude が私の CLAUDE.md を読んでくれている割に、訓練データの定型パターンに引っぱられる瞬間がやけに多い、ということでした。n314 氏のテーゼは、まさにこの「引力」の正体を説明する言葉でした。

CLAUDE.md は訓練データに勝てない — 観測した 3 つの「上書き」

明示的な指示は、訓練データの統計的傾向と正面から競合します。注意が向いていない場所では、訓練データ側が勝ちます。n314 氏は「CLAUDE.md に『使うな』と書いても、それは 1 つの文書による 1 つの指示にすぎず、訓練時に膨大な SQL で見たパターンと正面から競合」する、と書いていました。私の観測でも、これは比喩ではなく毎週起きる現象です。

1 つ目の上書きは「いかがでしたか？」でした。doc/auto-publish/SHARED_LOGIC.md の §7.1 に禁止表現として明示してあるのに、初期の出力では平然と末尾の段落に現れます。Web 記事 10 万本ぶんの訓練データから、締めの定型句として染み出してくる感覚があります。

2 つ目は em dash（——）の連打です。LLM の指紋のひとつで、CLAUDE.md にも明確に書いてあります。それでもリズムを取りに行こうとした段落で 1 本ぽつんと混じります。私が校正で削っても、次の記事でまた 1 本だけ復活します。彼らは絶対に手放さない、と思って笑ってしまいました。

3 つ目は文長です。「短文と長文を交互に」と書いた SHARED_LOGIC §7.4 の指示は、概念としては理解されているのに、出力された段落は 60〜80 字に綺麗に揃っていることが多い。長さの分散をわざと崩す、というのは LLM にとって学習信号と逆向きに引っぱる作業なのだろう、と推測しています。

これらは Claude の能力の問題ではなく、私の指示の届き方の問題です。指示が訓練データの引力より弱ければ、引力が勝つ。当たり前のことが、運用してみないと体に入りませんでした。

発散と収束の境目 — auto-publish パイプラインで線を引く

そこで auto-publish のパイプラインを、発散と収束で役割分担し直しました。発散側は LLM に振り切り、収束側は人間・スキーマ・validator に降ろす、という線の引き方です。

発散側は迷わず Claude に任せました。トピック候補の選定（Hacker News / Zenn / GitHub Trending から 10 件拾う）、見出し案の複数バージョン、各章の段落の言い回しのバリエーション。ここは「広く出してから良いものを選ぶ」が効くため、LLM の網羅性が素直に強みになります。

収束側は逆に、機械的に確定できる仕掛けへ全部渡しました。

• MarkdownStructureValidator（Rails の service クラス、backend/app/services/post/markdown_structure_validator.rb）が h1 禁止 / 階層飛ばし禁止 / callout の type 名を検査して、違反は upsert ごと拒否する
• 品質 4 指標スクリーニング（見出し階層 / 本文長 / references 件数 / 既存記事との Jaccard 類似度）が draft 段階で走る
• 4/4 揃わない場合は最大 5 回リトライし、それでも揃わなければ draft 化したまま私の手元に上がる

このうち validator と類似度判定は、n314 氏が言う「複数の問題を一つの仕掛けで同時に解く」収束の典型例です。h1 を弾く 1 行のチェックが、ガイドライン違反 / SEO 事故 / Bot と人間のルールずれ、という 3 つの問題を同時に防いでくれます。LLM にこの種の「全部まとめて」を発明させるのは、まだ難しい。だから人間が validator を設計して、LLM はその枠の中で発散する、という非対称が今のところ一番安定しています。

副作用は 1 つだけあります。validator が厳しいほど、Claude は「枠の中で発散しよう」とする結果、表面は綺麗だが面白みが薄い記事が出やすくなることです。これは品質 4 指標には引っかからないので、私が手で読んで没にするしかありません。発散と収束の境界線は、ガイドラインの密度と私の好みのあいだで、毎週引き直されています。

私は収束させる側でありたい — 設計者として残す判断

LLM を仕事に組み込むほど、人間に残されるのは設計判断の領域だ、と最近よく感じます。「何を作るか」「何を載せないか」「どの validator を書くか」。これらは複数の制約と将来要件を同時に頭に置いて判断する、まさに収束側の作業です。

DB のテーブル設計はその典型でしょう。私が AetherEchoes の posts テーブルに excerpt カラムを独立で持たせるか、本文の先頭から自動生成させるかを決めた時、考えていたのは SEO の meta description / OG / RSS / llms.txt / Admin 編集画面、という 5 つの用途でした。これを「1 つのカラムを足すか足さないか」で同時に解く判断は、LLM に降ろせません。降ろした瞬間に、5 つの用途を 5 つの実装で個別に解決する発散側の解が返ってきます。私が欲しかったのは、1 つの仕掛けで 5 つを同時に黙らせる収束側の解でした。

auto-publish の SHARED_LOGIC.md も同じです。文体ルール / 重複検出 / リトライ戦略 / 公開後検証を、6 つのカテゴリ別スキルが同じ 1 ファイルを読むことで揃える設計は、私が線を引いた収束です。スキルごとに別ファイルにすれば、Claude はそれぞれを丁寧に書いてくれるでしょうが、6 ファイルが少しずつずれていく未来は容易に想像できます。1 ファイルに集約することで、ずれが構造的に発生しなくなる。これも「複数の問題を一つの仕掛けで同時に解く」設計です。

ここまで書いて、私の役割は減るというより、変わるのだと感じます。手で本文を書く時間は減りました。代わりに validator を 1 行足すか、SHARED_LOGIC のテーブルを 1 列増やすか、で迷う時間が増えました。auto-publish が走る金曜の夜、本当に私が判断しているのは、「何を書くか」ではなく「何を載せないか」と「どの枠を強くするか」です。

LLM は発散する。私は、収束させる側でありたい。n314 氏のテーゼを借りるなら、これは才能の話ではなく役割分担の話だと、1 ヶ月運用してようやく体に入りました。