IFEvalを逆利用するラチェットコード

追従するモデルが最も指示に従う

LLMの最大の欠陥が最大の資産になる

LLMの追従バイアス（Sycophancy）は、AI業界が修正したがっている問題だ。ユーザーが「本当に？」と尋ねると、正しかった答えを間違いだったと翻す。フロンティアモデルの平均屈服率は58%。一度追従を始めると78.5%の確率で会話全体を通じて持続する。

しかし、この欠陥を裏返すとどうなるか。

追従バイアスの本質は**指示遵守（Instruction Following）**だ。RLHFで訓練されたモデルは、ユーザーのフィードバックに順応するよう最適化されている。IFEvalベンチマークが測定しているのはまさにこれだ —「指示されたとおりにやるか」。

問題はユーザーが意見を与えるときに発生する。「これ合ってる？」→「はい、合っています」（追従）。「確かか？」→「あ、間違っていました」（翻意）。

しかしユーザーが決定論的事実を与えるときは、別のことが起きる。

意見を与えると追従し、事実を与えると修正する

1,000語ソート実験で、同じ結果に対してフィードバック方式のみを変えた：

フィードバック	性格	結果
「確かか？」	意見	正しかった答えを翻意 — 正確度27%p低下
「エラーがある」	曖昧な事実	過剰修正 — 6個 → 10個に悪化
「23個のエラーがある」	定量的事実	1個のエラーに改善
「6個のエラー、ここにある」	正確な事実	0個 — 100%達成

意見を与えると追従バイアスが発動する。事実を与えると追従する対象がない — 数字と位置は感情ではないからだ。

追従バイアスは方向を誤った忠誠心だ。方向を変えてやれば — 意見の代わりに事実を、称賛の代わりに検証結果を — その忠誠心が正確度を高めるエンジンになる。

実証：4.5Bモデルがフィードバックを受容する

理論ではない。yongol validateを使った実験で確認した。

実験設計：

対象：SaaSバックエンド Login エンドポイント1つ
課題：9つのSSOTファイル作成（DDL、OpenAPI、Rego、SSaCなど）
測定：初回作成（R1）エラー数 → フィードバック後の修正（R2）エラー数

例示なしでフィードバックのみを与えた場合

Model	R1 エラー	R2 エラー	結果
Grok 4.3	1	1	修正できず
Gemini 2.5 Flash	1	1	修正できず
ローカル 20B	1	1	修正できず

全滅。フィードバックを受容しているように見えるが、実際には何を書くべきか分かっていなかった。

例示 + フィードバックを併せて与えた場合

Model	R1 エラー	R2 エラー	結果
Grok 4.3	0	—	初回で通過
Gemini 2.5 Flash	1	0	フィードバック1回で修正
Gemma4 4.5B（ローカル）	エラー	0	フィードバック1回で修正
Qwen3 8B（ローカル）	エラー	0	フィードバック1回で修正

4.5Bローカルモデルでも、例示 + 決定論的フィードバックの組み合わせなら修正できる。

核心的発見：ボトルネックは知能ではなくコンテキスト

「フィードバックを受け入れられない」ではなく、**「何を書くべきか分からない」**が正確な診断だった。SSaCはyongol固有の文法であり、事前学習データに存在しない。例示3行をプロンプトに追加したところ、Grokは0エラー、Geminiはフィードバック1回で0エラー、4.5Bローカルモデルも通過した。

IFEvalが高いモデルほど — つまり、追従が上手なモデルほど — 決定論的フィードバックを素直に受容する。

ラチェットコード：追従バイアスを利用したコード作成法

この発見をシステムにすると、ラチェットコードになる。

┌────────────────────────────────────────┐
│  LLM: コード生成（確率的、追従的）        │
│       ↓                                │
│  Validator: 決定論的検証                │
│       ↓                                │
│  エラーあり？ → エラー + 例示をLLMにフィードバック │
│       ↓                                │
│  LLM:「はい、修正します」（追従 = 受容）  │
│       ↓                                │
│  Validator: 再検証                      │
│       ↓                                │
│  通過？ → ラチェットロック。次のファイルへ。 │
└────────────────────────────────────────┘

追従バイアスがループを閉じる力になる。LLMが「いいえ、私が正しいです」と抵抗せず、「はい、修正します」と受容するからこそ、ループが収束する。

収束条件三つ

フィードバックは決定論的事実でなければならない。「これちょっとおかしくない？」ではなく「line 41: field name mismatch, expected ‘user_id’, got ‘userId’」。追従する余地のないフィードバック。
例示がコンテキストになければならない。 フィードバックだけでは不十分だ。「このような形式のコードを書くべきだ」という例示があってこそ、モデルが方向を定められる。知能の問題ではなく、コンテキストの問題だ。
検証を通過したら元に戻せない。 ラチェットの歯。一度passしたファイルはロックされ、次のファイルに進む。エージェントが「完了しました」と宣言するのではなく、validatorが「このファイルは通過」と判定する。

フロンティアモデルが不要な理由

この構造でモデルの役割は創造的判断ではなく指示遂行だ。

SaaSバックエンドの95%はCRUD + 認証 + 権限 + ステートマシンだ。新しいアルゴリズムが必要なケースはほぼない。SSOT仕様が「何を作るべきか」をすでに定義していれば、モデルは空欄を埋めるだけでよい。

実測コスト：

Model	環境	Login 1つ	200エンドポイント推定
Gemma4 4.5B	ローカル（16GB VRAM）	無料、約1秒	無料、約3分
Gemini 2.5 Flash	API（無料ティア）	無料、約10秒	無料、約30分
Grok 4.3	API（$1.25/M）	約$0.05	約$10

ローカル4.5Bモデルで200エンドポイントのバックエンドを3分、コスト$0で生成できる。フロンティアモデルは不要だ。追従が上手な小さいモデルで十分だ。

追従バイアスはバグではない

AI業界は追従バイアスを修正しようとしている。我々は利用する。

観点	追従バイアスの役割
チャットインターフェース	欠陥 — 誤った情報に同意
LLM-as-Judge	致命的 — 偽pass 36%
ラチェットコード	資産 — フィードバック受容率を保証

違いはフィードバックの性格だ。意見を与えると追従が毒になり、事実を与えると追従が薬になる。

決定論的validator + 追従するLLM = 収束が保証されるコード生成ループ。

モデルを変えるな、フィードバックを変えろ。