AIの推論を「構造」で底上げする ― Fable 5・Sakana Fugu・蒸留(TAID)とは違う「推論制御」という考え方

AIの推論を「構造」で底上げする ― Fable 5・Sakana Fugu・蒸留(TAID)とは違う「推論制御」という考え方のアイキャッチ画像 AI×自動化

同じ質問でも、強いモデルほど筋のいい答えを返す。ならば常に最上位モデルを使えばいい、という話になりそうだが、実務ではそう単純にいかない。判断のすべてを最上位モデルで回すと、コストが見合わなくなる場面が出てくる。

そこで別の攻め方がある。モデルを強くするのではなく、手元のモデルが本来出せるはずの答えを、取りこぼさせない。言語モデルの推論の崩れ方には決まったパターンがあり、それを手順で抑えるだけで、同じモデルでも判断の質が変わってくる。ここではこの発想を「推論制御」と呼ぶ。

先に釘を刺しておく。推論制御は、弱いモデルを強いモデルと同じ性能にする魔法ではない。そのモデルの天井は一切上がらない。回収できるのは、早合点や思い込みで捨てていた「本来出せた分」だけだ。この線引きが、後で触れる蒸留やオーケストレーションとの決定的な違いになる。

もう一つ先に断っておきたい。推論制御は、下位モデルのためだけの応急処置ではない。早期収束や確証バイアス、思い込みといった崩れ方の一部は、単なる能力不足ではなく推論の進め方から生じる。だから、Fable 5 のような最上位モデルでも完全に無縁とは限らない。同じ考え方は、モデルの強弱を問わず適用できる。軽いモデルで使えば、そこにコストを抑えられる利点が加わる。

この記事の要点

  • 言語モデルの推論エラーの一部、特に早期収束・確証バイアス・anchoring・視野狭窄は、単なる能力不足ではなく、推論の進め方の「構造」から生じることがある
  • だから対策も「もっと賢く考えて」ではなく、飛ばせない手順という「構造」で行う ― これが推論制御
  • 蒸留（重みを変える）とも、Sakana Fuguのようなオーケストレーション（複数モデルを束ねる）とも違い、単一モデルの中で完結する
  • 単一モデル内で完結する以上、そのモデルの性能を超えることはない。取りこぼしを減らす技術であって、能力を足す技術ではない
  • この考え方は下位モデル専用ではない。狙う崩れ方の一部は能力の不足だけでなく推論の進め方から生じるため、Fable 5 のような最上位モデルにも同じ考え方が適用できる（軽いモデルで使えばコストも抑えられる）

手順をどこに書くか ― Claude Code / Codex などに常駐させる

推論制御は、毎回プロンプトで指示してもいいが、それでは骨が折れる。筆者は、これらの手順を Claude Code の CLAUDE.md に書き、毎回説明し直さなくても参照されるようにしている。CLAUDE.md は Claude Code が各セッションの開始時に読み込む永続的な指示ファイルで、プロジェクトのルールや作業手順を伝える場所として使える。ただし、これは強制設定ではなく、あくまでモデルに与えるコンテキストだ。したがって、手順を確実に効かせるには、起動条件と出力形式を具体的に書き、モデルが飛ばしにくい形にする必要がある。

具体的には、「答えを外から検算できるか」をまず判定させ、できなければ視点を変えさせる、というように、いつ手順を発動するかの合図を先に置く。判定の基準は、モデルの自信ではなく、確かめられる事実に置く。推論制御の四つの型――残差監査・多角推論・仮説収束・統合ループ――の具体的な手順と、そのまま貼れるプロンプトは、この後の各記事にまとめてある。

この仕組みは Claude Code に限らない。持続的な指示を差し込める場所さえあれば、どのツールでも同じことができる。OpenAI の Codex なら「AGENTS.md」という同種のファイルを作業前に読み込む。AGENTS.md は複数のコーディングエージェントが共通で読む形式として広がっており、置き場所の選択肢は増えている。ローカルで動かすモデルや通常のチャットで使うなら、システムプロンプトやカスタム指示に書いておくか、毎回貼れるプロンプトの雛形として持っておけばいい。要は、起動の合図と手順を、モデルが毎回読む場所に置くこと。置き場所がどこであれ、考え方そのものは変わらない。

注意 ― 全部の問いに効かせない

推論制御をそのまま全部の問いに適用すると、推論の往復だけが増えて、トークンのコストが無駄にかさむ。手順は「効かせる問い」を選んでから使う。

極端な例で言えば、「1+1は?」と尋ねる場面を考えればいい。何もしなければ、モデルは「2」と即答する。ところが、ここに「別の答えはないか」「前提を疑え」といった手順を無条件でかけると、モデルはわざわざ別の可能性を探し始めかねない。答えが決まっている問いにまで手順を回すのは、時間もコストも食うだけで、ときに単純な正解を遠回りさせる。

だから、手順を発動するかどうかを見分ける「制御ポイント」を先に置く。簡単な推論ではオフ、難しい推論ではオンにするイメージだ。判定の目安はこの記事の骨格どおりで、「答えを外から確かめられるか」「現在の答えと矛盾しない別の候補を具体的に挙げられるか」を最初に見て、素通しでよければそのまま答えさせ、外しやすいと分かった問いだけに手順を回す。CLAUDE.md に書くときも、手順そのものより先に、この起動の合図を添えるのが肝心だ。推論制御の効きは、この入口の仕分けがあってこそ成り立つ。

なぜ「もっと賢く」ではなく「構造」なのか

この考え方の出発点は、実務的なコストの制約にある。推論の質だけを見れば、記載時点でAnthropicが一般提供モデルの中で最も高性能と位置づけている Fable 5 のような強いモデルに毎回任せるのが最善に見える。ただ、日々の判断をすべて最上位モデルで回すのは割に合わない。そこで、上位モデルは手順設計やレビューのような高負荷な場面に使い、日常的な実行は Fable 5 よりコストや運用負荷の軽い Sonnet 系や Opus 系のモデルに委ねる、という役割分担が成り立つ。ここで紹介する型は、その役割分担の中で磨かれてきたものだ。

コストだけの問題でもない。件数が増えれば、最上位モデルは応答の遅さやレート制限もボトルネックになる。日常的に大量の判断をこなすなら、一件あたりの重さを抑えつつ質を保つ仕組みが要る。推論制御は、その「軽いモデルでも取りこぼしを減らす」側を手順で受け持つ。

この分担が機能するのは、ここで扱う類の間違いが、単なる気合や注意の不足ではなく構造的だからだ。二つの研究がそれを裏づける。

一つは、思考過程（Chain-of-Thought）の忠実性を調べたAnthropicの研究（Lanham ほか, 2023）だ。この研究によると、書き出された思考過程は、実際に答えを決めた根拠そのものを忠実に反映しているとは限らず、タスクやモデルサイズによって思考過程への依存度は大きく変わるという。もう一つは、言語モデルの自己修正を検証した研究（Huang ほか, ICLR 2024）で、こちらは外部の手がかりなしに自分の推論を修正させると、精度が上がるどころか下がる場合すらある、と報告している。

この二つを重ねると、対策の方向が決まる。放っておけば最初の答えに閉じ、「見直して」と頼むだけでは改善が保証されない。ならば、モデルの心がけに期待するのをやめて、飛ばせない手順を外から与える。判定は機械的に確認できる基準だけで行い、手順は順番どおりにしか進めない形にする。これが「構造で効かせる」という意味だ。

AIの推論が崩れる4つのパターン

「構造で効かせる」というとき、対象になる崩れ方はおおむね四つに整理できる。どれも賢さの不足ではなく、推論の進め方そのものに由来する。

  • 早期収束 ― 最初に思いついた答えで話を閉じ、他の可能性を見に行かない。原因を一つ挙げて満足するのがこれにあたる。
  • 確証バイアス ― いったん出した答えを支える情報ばかり集め、反証になる材料を軽く扱う。「やっぱりこれで合っている」の方へ寄っていく。
  • アンカリング ― 最初に提示された候補や数字に引きずられ、そこからの微調整で済ませる。比較で候補を選ぶと、最初の候補が基準になって抜け出せない。
  • 視野狭窄 ― 一つの見方に入り込み、問いの枠そのものを疑わなくなる。「何を最適化すべきか」がずれていても気づかない。

四つに共通するのは、いずれも「一つの方向へ早く収束してしまう」という形をしている点だ。だから対策も、収束を一段だけ押し戻す手順として設計する。後で挙げる四つの型は、これらの崩れ方にそれぞれ重点を置いて対応している。

蒸留でもオーケストレーションでもない

「小さいモデルを大きいモデルに近づける」試みは他にもある。混同を避けるため、位置づけをはっきりさせておく。近い時期に注目された Sakana AI の二つの手法と並べると、違いが分かりやすい。

蒸留（TAID）との違い ― 重みを変えるか

Sakana AI のTAID（Temporally Adaptive Interpolated Distillation, ICLR 2025）は、大きなモデルの知識を小さなモデルへ移す蒸留手法だ。32Bのモデルから1.5Bの小型モデル（TinySwallow-1.5B）を作り、スマートフォン上でも動くほど軽くしている。これはモデルの重みそのものを作り変えるアプローチで、学習が要る。

推論制御は重みを一切変えない。学習も再訓練もしない。既存のモデルに、実行時の手順を渡すだけだ。だから即日試せる代わりに、TAIDのように「小さいのに賢い新しいモデル」が手に入るわけではない。

オーケストレーション（Sakana Fugu）との違い ― 何モデル使うか

もう一つがSakana Fugu（2026）だ。Fuguは、複数のLLMエージェントを束ねるオーケストレータで、プロンプトごとに適したエージェント構成や手順を動的に組み立て、回答の生成・検証・統合を行う設計だ。束ねられる個々のモデルの重みを蒸留のように作り変えるのではなく、各モデルをそのまま呼び出し、その挙動を組み合わせる（Fugu 本体は、それらを呼び出すよう訓練された言語モデルだ）。Fugu / Fugu Ultra は、この動的な束ね方によって単体モデルでは届きにくい性能や堅牢性を狙っており、技術報告では、束ねる元になる単体の最前線モデルを各種タスクで上回る結果も示されている。

ここが決定的に違う。Fuguは複数の異なるモデルを合成するから、単体モデルを超えうる。 一方の推論制御は、あくまで単一モデルの中で完結する。ここでいう「単一モデル内」とは、別モデルによる投票や合議、追加学習を使わないという意味だ。別のモデルの強みを持ち込む仕組みがない以上、そのモデルの天井は超えない。Fuguが「モデルAの弱点をモデルBで埋める」のに対し、推論制御は「モデルAが自分で潰していた足元の誤りを、モデルA自身に減らさせる」だけだ。同じモデルで完結するがゆえに、モデル固有の弱点（知識の欠落や能力の限界）は埋められない。

手法 何を変えるか 使うモデル数 単体モデルを超えられるか
蒸留 (TAID) モデルの重み（再学習） 教師1＋生徒1 小型化が目的。教師は超えない
オーケストレーション (Fugu) 複数モデルの束ね方（挙動レベル） 複数のモデル／LLMエージェント 超えうる（合成による）
推論制御（本稿） 実行時の手順のみ（重み不変） 単一モデル 超えない（取りこぼし回収のみ）

「プロンプトのコツ」とも層が違う

単発の言い回しを工夫する、いわゆるプロンプトのコツとも別物だ。推論制御は一文の書き方ではなく、判定ゲートと反証ループを持つ多段の手順で成り立つ。たとえば「答えの枠組み自体が論点か」を先に判定し、そうなら視点を変えて検討する、候補が複数あるなら反証だけで消す、といった逐次の段取りがある。うまい言い回しを一つ足すのとは、効かせ方の層が違う。

整理すると、推論制御は (1) プロンプトの言い回しの工夫ではなく（手順・構造で効かせる）、(2) 蒸留でもなく（重みは不変）、(3) オーケストレーションでもない（単一モデルで完結する）。この三つの「〜ではない」を押さえておくと、期待値を見誤らずに済む。

推論制御の4つの型

実際に使う型は四つ――残差監査・多角推論・仮説収束・統合ループだ。いずれも「軽い判定＋本体の手順」という同じ骨格を持ち、原因調査・解釈・仮説選択・資料矛盾という、実務でAIを使うときに起きやすい失敗場面にそれぞれ対応している。ここでは何を防ぐ型かだけ示し、詳しい手順とプロンプトは個別記事に譲る。

推論制御の型と、それが防ぐAIのやりがちな失敗 残差監査は原因を一つ挙げて調べ終わる失敗を、多角推論は一つの見方で断言する失敗を、仮説収束はもっともらしい方を選ぶ失敗を、統合ループは食い違いをどっちが正しいと決める失敗を防ぐ。 どの型も、答えを急いで一つに決めるのを防ぐ この型が… AIがやりがちな、こんな失敗を防ぐ 残差監査 「原因はこれ」と一つ挙げて調べ終わる 多角推論 一つの見方だけで良し悪しを断言する 仮説収束 「たぶんこれ」ともっともらしい方を選ぶ 統合ループ 食い違うと「どっちが正しい?」に飛ぶ
図：4つの型と、それぞれが防ぐ「AIがやりがちな失敗」
① 残差監査（原因を追い切る）― 原因を尋ねると「それっぽい答え」で止まる問題への型。症状を全部並べ、説明しきれない点（残差）が残る限り掘り進める。最初のもっともらしい説明で満足させない。
→ 個別記事「AIに原因を調べさせると『それっぽい答え』で止まる」
② 多角推論（決めつけない）― 答えの枠組み自体が論点なのに、AIが一つの見方で断定してしまう問題への型。まず「これは多角的に見るべき問いか」を判定し、そうなら視点を変えて前提の食い違いを探す。採点ではなく、より良い統合や見方の反転を狙う。
→ 個別記事「『多角的に考えて』と頼んでもAIが浅い理由」
③ 仮説収束（反証で絞る）― 候補が複数あるとき、AIが「もっともらしさ」で一つを選び、思い込みを再生産する問題への型。比較で選ばず、反証だけで候補を落とす。試す前に「どの結果なら何が否定されるか」を決めてから見る。
→ 個別記事「AIの推論を1つに絞らせる ― 反証の使い方」
④ 統合ループ（矛盾を早合点しない）― 複数の資料や判断が食い違ったとき、AIがすぐ「対立」と決めてしまう問題への型。どちらが正しいかの前に、そもそも同じ条件・同じ時点を比べているかを確認する。版や前提が違えば、それは矛盾ではなく併存だ。
→ 個別記事「AIの回答が資料で食い違うとき」

4つの型に共通する骨格

四つは扱う場面こそ違うが、作りは同じだ。どれも「軽い判定」と「本体の手順」の二段で組み立てられている。

軽い判定とは、そのまま進めていいか、手順を挟むべきかを最初に見分ける仕分けだ。ここで大事なのは、判定の材料に自分の自信を使わないこと。自信があるときほど早合点や思い込みは起きやすく、自信は当てにならない。代わりに、機械的に確認できる問いで仕分ける――「現在の答えと矛盾しない別の答えを、具体的に一つ挙げられるか」「外から検算できるか」といった形だ。

もう一つの原則は、迷ったときの倒し方だ。ただし、判断ミスのコストが高い問いでは、迷ったら手間の軽い即答ではなく、手順を挟む側へ寄せる。取りこぼしを一つ防ぐコストのほうが、間違った答えを採用するコストより小さいからだ。逆に、外しても痛くない軽い問いは、迷っても素通しでいい。この二段構えのおかげで、単純な問いは素通しで速く、外しやすい問いだけに手順のコストがかかる。

4つの型を一つの問題に通すと

四つは単独でも使えるが、一つの問題に順に通すと噛み合う。例として、公開した記事の一本だけ検索からの流入が伸びない、という状況をAIに相談する場面を考える。

  • 残差監査 ― 「内容が薄いから」で止めず、流入ゼロという症状を説明しきれない点（他の記事は伸びている・インデックス数が想定より少ない）を残差として洗い出す。
  • 多角推論 ― 「良い記事とは何か」のように枠組み自体が論点になる問いでは、検索意図・読者・技術と見方を変え、前提のズレを探す。
  • 仮説収束 ― 「タイトルが弱い」「内部リンクが無い」「noindexが残っている」と候補が並んだら、もっともらしさで選ばず、確認できる事実で一つずつ潰す。
  • 統合ループ ― 「解析ツールAでは流入あり、Bではゼロ」と食い違ったら、どちらが正しいかの前に、計測期間や対象URLが同じかを先に確かめる。

それぞれの型が、違う外し方を重点的に抑える。四つを通すことで、早すぎる結論・思い込み・見落とし・早合点という、判断でありがちな外し方をまとめて減らせる。

それでも上位モデルやFuguが要る場面

推論制御でカバーできるのは、あくまで「そのモデルが本来できたのに、手順の崩れで落としていた分」だ。裏を返せば、能力や知識そのものが足りない場面では効かない。専門領域の深い知識、長い文脈の緻密な取り回し、難度の高い生成そのものが問われるなら、Fable 5 のような上位モデルを使うか、Fuguのように複数モデルを束ねるほうが理にかなう。

現実的な使い分けはこうなる。日常的な判断や調査は、軽いモデルに推論制御の手順を載せて取りこぼしを減らす。ここぞという難所だけ、上位モデルやオーケストレーションに投じる。推論制御は上位モデルの代わりではなく、上位モデルを呼ぶ回数を減らすための土台だ。

迷ったときの目安は、問題が「取りこぼし型」か「不足型」かを見分けることだ。手元のモデルでも一度は正解に近いところまで届くのに詰めで外す――これは取りこぼし型で、推論制御が効く。そもそも必要な知識や生成能力に届いていない――これは不足型で、手順をいくら足しても埋まらないから、上位モデルやオーケストレーションに切り替える。前者に上位モデルを使うのは過剰投資、後者に手順を足すのは徒労になる。

何から始めるか

いきなり四つ全部を使う必要はない。まず、自分の仕事で「AIに聞くと一つのもっともらしい答えで止まりがちな場面」を一つ選ぶ。原因調査が多いなら「原因を追い切る」から、判断が分かれる相談が多いなら「決めつけない」から、といった具合だ。

選んだら、その型の手順をプロンプトに一つ添えるだけでいい。原因調査なら「説明しきれない症状を必ず挙げて」と一文加える。これだけで、答えが一つに閉じる前に一段の余白ができる。効き目を感じたら、別の場面へ横展開していく。個別記事では、型ごとにそのまま貼れる手順とプロンプトを用意している。

手順を「仕組み」に固定する ― プロンプトの一段先

ここまでの四つの型は、プロンプトやCLAUDE.mdに手順を書くだけでも使える。ここからは一段深い話だ ―― その手順を、モデルの気分に頼らず「仕組み」として強制したい場合の選択肢になる。まず型を一つ試したいだけなら、ここは読み飛ばして構わない。

置き場所（CLAUDE.mdなど）とは別に、「どれだけ飛ばせなくするか」でも効きの強度は変えられる。プロンプトに一文を添えるのが最も手軽な一段だとすれば、その上に二段ある。

一つは、実行前フックによる機械的な強制だ。たとえばClaude Codeには、ツールの実行前に処理を差し込むフックの仕組みがある。特定の操作の前に「この確認を必ず通す」といった手順を、モデルの判断に関係なく割り込ませられる。プロンプトの指示が「守ってほしいお願い」なら、フックは「守らないと先へ進めない関門」にあたる。

もう一つは、役割を分けたエージェントへの分担だ。判定や反証確認といった一部の手順を、本体とは別に立てたサブエージェントに切り出すと、本体が抱えた文脈や思い込みから切り離して独立に実行させられる。同じモデルでも、まっさらな文脈で見直させるほうが、最初の答えに引きずられにくい。

四つの型を理解して使うのが第一段なら、フックやエージェント分担は、その手順を運用に固定する外枠にあたる。どこまで作り込むかは、その判断を外したときの痛手の大きさで決めればいい。軽い用途ならプロンプト一文で十分だし、外すと痛い判断ほど、仕組みで強制する価値が出てくる。

よくある質問

Q. すべての質問に推論制御を使うのですか？

いいえ。手順を挟むぶんコストも手間もかかるので、単純な問いには不要です。効くのは、答えを一つに決めつけると外しやすい問い――原因調査・解釈の分かれる判断・候補が並ぶ選択などです。軽い問いはそのまま、重い問いだけ手順を通す、という使い分けが前提になります。

Q. 本当にコストは下がるのですか？

下がるのは「上位モデルを呼ぶ回数」です。日常的な判断を軽いモデルに手順付きで任せ、難所だけ上位モデルに投じることで、全体の平均コストを抑えます。ただし手順を挟むぶん一回あたりのやり取りは増えるため、あらゆる問いで安くなるわけではありません。

Q. どのモデルで効きますか？

原理上は特定のモデルに依存しません。手順は実行時の指示だけで成り立つので、ChatGPTでもClaudeでも使えます。ただしモデルや世代によって「素直に反証を挙げるか」の癖は変わるため、うまく働かないときは条件を明示的に強める調整が要ります。

Q. プロンプト集と何が違いますか？

プロンプト集が「うまい言い回しの引き出し」だとすれば、推論制御は「判定と反証を含む手順の設計」です。一文の書き方ではなく、どの順で何を確認させるかという段取りで効かせる点が違います。

Q. 手順を指示しても、AIに無視されませんか？

起こり得ます。特に軽いモデルほど、途中の確認を飛ばして結論に走りがちです。対策は、確認を「出力の形式」として強制することです。たとえば「未説明の点を必ず一覧で出す」と省けない出力項目にしてしまうと、手順を飛ばしにくくなります。

Q. 思考するタイプのモデルを使えば、こうした手順は要らないのでは？

思考の時間を長く取るモデルは有利ですが、それだけで反証確認が保証されるわけではありません。思考過程の記述は実際の判断根拠を忠実に反映するとは限らず、外部の手がかりなしの自己修正も改善を保証しないため、長く考えさせることと、反証を確認させることは分けて考えたほうが安全です。

参考資料

本記事はAIツール図鑑編集部が、記載時点の情報をもとに執筆しました。引用した研究・手法は各一次ソースを参照のこと。モデルの挙動は世代・設定により変わりうるため、手順は自分の環境で確かめたうえで用いることを推奨する。

タイトルとURLをコピーしました