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

IFEvalを逆利用するラチェットコード 画像：AI生成

LLMが指示にはよく従うのに結果がめちゃくちゃなら、おべっかバイアスを排除するのではなく利用したいなら、4.5Bのローカルモデルで正確なコードを生成したいなら――IFEvalとラチェットの組み合わせがその答えだ。

おべっかを使うモデルが一番言うことを聞く

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

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

しかし、この欠陥を裏返したらどうなるか。

おべっかバイアスの本質は**指示遵守（Instruction Following）**だ。RLHFで訓練されたモデルはユーザーのフィードバックに従うよう最適化されている（Ouyang et al., 2022）。IFEvalベンチマークが測定しているのはまさにこれだ――「言われた通りにするか」（Zhou et al., 2023）

問題はユーザーが意見を与える時に発生する。「これ合ってる？」→「はい、合っています」（おべっか）。「本当に？」→「あ、間違っていました」（屈服）。

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

意見を与えればおべっかし、事実を与えれば修正する

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

フィードバック	性質	結果
「本当に？」	意見	正解を覆す――精度27pp低下
「エラーがある」	曖昧な事実	過剰修正――6個→10個に悪化
「23個のエラーがある」	定量的事実	1個に改善
「6個のエラー、ここにある」	正確な事実	0個――100%達成

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

おべっかバイアスは方向を間違えた忠誠心だ。方向を変えてやれば――意見の代わりに事実を、称賛の代わりに検証結果を――その忠誠心が精度を上げるエンジンになる。

実証：4.5Bモデルがフィードバックを受け入れる

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

実験設計：

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

例示なしでフィードバックだけ与えた場合

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

全滅。フィードバックを受け入れるように見えるが、実際には何を書けばいいか分からなかっただけだ。

例示+フィードバックを一緒に与えた場合

モデル	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が「いいえ、私が正しいです」と抵抗せず「はい、直します」と受け入れるからループが収束する。コンパイラとテストのフィードバックでLLMコードを反復修正するアプローチはSelf-Debug（Chen et al., 2024）でも3ターン以内にデバッグが完了することが示された――ラチェットコードはここからLLMの自己判断を完全に除去し、決定論的事実だけを残した構造だ。

収束の三条件

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

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

このアーキテクチャにおけるモデルの役割は創造的判断ではなく指示実行だ。

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

実測コスト：

モデル	環境	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	致命的――36%の偽pass
ラチェットコード	資産――フィードバック受容率を保証

違いはフィードバックの性質だ。意見を与えればおべっかは毒になり、事実を与えればおべっかは薬になる。

決定論的validator + おべっかなLLM = 収束が保証されたコード生成ループ。

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

Reins：手綱のあるハーネス

この3つの条件――決定論的フィードバック、例示コンテキスト、ラチェットロック――を一つの制御システムにまとめたものを我々はReinsと呼ぶ。

今「ハーネス」と呼ばれているものは柵だ。エージェントが外に出られないようにするだけで、目的地に到達することを保証しない。Reinsは手綱だ。方向を定め、事実で矯正し、通過したらロックする。手綱のないハーネスは柵に過ぎない。

出典

Zhou, J., Lu, T., Mishra, S., Brahma, S., Basu, S., Luan, Y., Zhou, D., & Hou, L. (2023). “Instruction-Following Evaluation for Large Language Models.” arXiv:2311.07911
Ouyang, L., Wu, J., Jiang, X., et al. (2022). “Training Language Models to Follow Instructions with Human Feedback.” NeurIPS 2022. arXiv:2203.02155
Chen, X., Lin, M., Scharli, N., & Zhou, D. (2024). “Teaching Large Language Models to Self-Debug.” ICLR 2024. arXiv:2304.05128
Sharma, M., Tong, M., Korbak, T., et al. (2024). “Towards Understanding Sycophancy in Language Models.” ICLR 2024. arXiv:2310.13548
Fanous, A., Goldberg, J., Agarwal, A., et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. arXiv:2502.08177
Shapira, I., Benade, G., & Procaccia, A. D. (2026). “How RLHF Amplifies Sycophancy.” arXiv:2602.01002
Ibrahim, L., Hafner, F. S., & Rocher, L. (2026). “Training Language Models to Be Warm Can Reduce Accuracy and Increase Sycophancy.” Nature, 652, 1159-1165

変更履歴

2026-05-20: 初版