キャリブレーション付きフォワードモデルと held-out 学習ゲート

エージェントの推測すべてを現実と照合して採点する——数字の裏付けがない教訓は、採用されるまでベンチで待機。

概要

DuDuClaw 1.54 以降、どのエージェントも行動する前に「このステップは成功するか？」に対して確率の数字を出せるようになりました。事後、システムはツールが実際に返した結果を使い、統計学的に公正と認められた方法でその数字を採点します。採点結果は表示のためだけのものではありません。エージェントが自ら帰納した教訓を採用してよいかどうかも、この採点が決めます。教訓は、ツール記録や監査ログで検証できるものなら直接採用され、そうでなければまず候補として扱われ、その後の実例で命中率を記録し、ベースラインに勝って初めて昇格します。この機能一式は v1.54 からデフォルトで有効であり、各エージェントがそのまま使えます。不要な場合は設定で全体または層ごとに無効化でき、無効化した層の挙動はこの機能が存在する前と完全に同じになります。

解決する3つの問題

第一に、サンプルが少ないと自己正当化に陥ります。 エージェントが30件の仕事をこなし、振り返ってパターンを探すと、ノイズをパターンと取り違えて1本のルールに書き起こし、次の意思決定もそのルールに従ってしまいがちです。しかもそのルールは、30件の外側のデータで一度も検証されていません。この閉ループは回るほど自信を深めますが、回るほど正確になるわけではありません。

第二に、後付けの「予測・行動・検証」フローでは、検証ステップが自分の書いたログを自分で読むだけになりがちです。 一見完全なループがあるように見えて、実際には「検証」が外部の事実に一切接続されておらず、一回きりの質問応答をする素のモデルと本質的な違いがありません。

第三に、「当初の推測」と「後に起きたこと」を突き合わせて採点する仕組みが存在しませんでした。 この対照がなければ、モデルは推測を外しても正確にはならず、流暢に話せるがゆえに信頼できそうに見えるだけです。

仕組み

3つの段階、すべて純粋な数学計算で、追加のLLM呼び出しはありません：

行動の前
     |
     v
+----------------------+
|  先に推測を確定       |  <-- TaskPrediction.confidence を行動前に
+--------+-------------+      記録。事後の書き換えは不可
         |
         v
+----------------------+
|  外部証拠で採点       |  <-- ツールが実際に返した結果が審判。
+--------+-------------+      Brier score または RPS を計算
         |
         v
+----------------------+
|  Murphy 分解          |  <-- resolution の上昇だけが
+----------------------+      本当の学習として扱われる

先に推測してから行動する

行動の前に、タスク層の予測（TaskPrediction.confidence）が確率を記録します。このステップは成功するか、どれくらい時間がかかるか、失敗するならどの失敗クラスか。この数字は行動が起こる前にファイルに落ち、事後に書き換えることはできません。先にコミットしてこそ反証されうる、という反証可能性の原則に沿った設計です。

事後に外部証拠で採点する

タスク終了後、システムはツールが実際に返した結果（エージェントの自己申告ではありません）を審判として、Brier score（二値判断）または RPS（三分類の順序判断）を計算します。どちらのスコアも有界で、範囲は 0 から 1 に固定されています。業界でよく使われる log score は、たった一度の極端な予測で合計を無限大まで引きずれるため小サンプルで不安定であり、ここでは意図的に使いません。

Murphy 分解で本当に学習したかを確認する

Brier score は3つの成分に分解できます。信頼度（reliability）、分解能（resolution）、不確実性（uncertainty）です。鍵となる判断はここにあります。resolution が時間とともに上昇して初めて、予測パターンを本当に学んだといえます。reliability が改善しても resolution が動かない場合、エージェントは保守的に平均値を報告することを覚えただけです（常に「五分五分」と答えるのが最も減点されにくい推測ですが、それでは何も学んでいません）。システムはこの2つの数字を別々に追跡し、合計点だけを見ることはありません。

比較対象のベースラインは凍結されなければなりません。データと一緒に漂流してしまえば、「ベースラインに勝った」ということ自体が検証不能になります。

誠実なラベル

システムが許す結論は3種類だけです：

ラベル	意味
`SUPPORTED`	サンプル外の成績がベースラインを有意に上回る
`CANDIDATE`	サンプルがまだ足りず、当面は判断できない
`INDISTINGUISHABLE_FROM_LUCK`	信頼区間が五分五分をまたぐ、または較正後の勝率の信頼が不足しており、数学的に技量と運を区別できない

「まだ分からない」は正当かつ頻出の結論です。システムは有用に見せるために、あいまいな「暫定的に有効」を無理にひねり出すことはしません。

held-out 学習ゲート：リフレクションが候補を出し、数字が採否を決める

自己リフレクション（reflexion）は引き続き候補教訓を生み出しますが、すべての教訓はまず分類を通過します：

リフレクションが候補教訓を生成
        |
        v
ツール記録や監査ログで検証できるか？
        |
   +----+----+
   |         |
 できる    できない
   |         |
   v         v
 直接採用   shadow 候補（プロンプトに注入しない）
                |
                v
          新しい実例ごとに命中／外れを記録
                |
                v
          Wilson 信頼区間下限 vs ベースライン
          （複数候補が同時に競合する場合は
            Bonferroni 補正）
                |
           +----+----+
           |         |
          勝ち      負け
           |         |
           v         v
         昇格し、   観察を継続。
         注入開始   外れ続ければ退役

ツール記録や監査ログで検証できる教訓（たとえば、あるツールのパラメータ形式の誤りが失敗を招く、など）は従来どおり直接採用されます。判断の根拠が確定した事実だからです。
プログラム的な証拠がなく、純粋に帰納で得られた教訓（たとえば、ある状況では成功率が低めだ、といった統計的直感）は、まず shadow 候補として扱われ、プロンプトには現れません。以後、新しい実例が発生するたびに、その候補の推測が当たったか外れたかを記録します。十分なサンプルが溜まったら、Wilson 信頼区間の下限（複数の候補が同時に競合する場合は Bonferroni 補正でしきい値を引き締め）をベースラインと比較します。ベースラインに勝って初めて昇格し、注入が始まります。昇格後に成績が悪化し、ローリングウィンドウの信頼区間下限が再びベースラインを割り込んだ場合は、直ちに候補へ降格されます。記録は保持され、削除されません。

候補はどう昇格するか：shadow スコアリング

候補教訓の昇格クローズドループは、両方の経路が接続済みです。自律タスクループ側では、タスクの各ラウンド精算時に、状況が合致する候補それぞれに命中または外れを1件記録します。通常の会話側では、プロンプト組み立て時にトリガーシグナルが当該ターンの状況に合致する候補をまず登録し（依然として注入はしません）、返答の結果が精算された後で、登録済みの各候補に記帳します。

両側は同じ判定基準を使います。候補の暗黙の予測は「この種の状況はリスクが高め」であり、実際に問題が起きれば命中、空振りなら外れです。サンプルがしきい値に達したら、Wilson 信頼区間の下限（複数候補の競合時は Bonferroni 補正）を、そのエージェント自身の過去のベースレートと比較し、勝てば昇格して注入が始まり、空振りを続けた候補は退役します。昇格後に成績が悪化すれば候補に戻されますが、履歴は保持され、シグナルが再び合致すればサンプルを積み直して復帰できます。ベースレートは層ごとに別々に計算されます。タスク層はタスク精算記録、会話層は会話誤差記録を参照し、履歴が8件未満の場合は一律で五分五分にフォールバックします。保守的である方を選ぶ設計です。

有効化の方法

3つのスイッチはすべて [task_forward_model] の下にあり、層ごとに重ねて有効化します：

# config.toml（グローバル）。dashboard →「詳細設定 → 予測キャリブレーション」でも切り替え可能。
[task_forward_model]
enabled = true                # マスタースイッチ：タスク層予測そのもの。v1.54 でデフォルト true
calibration_enabled = true    # 採点：Brier/RPS + Murphy 分解。v1.54 でデフォルト true
held_out_gate_enabled = true  # 学習ゲート：reflexion 候補にサンプル外検証を課す。v1.54 でデフォルト true

3層は独立に積み重なります。enabled は予測の記録を行い、calibration_enabled は採点を開始して誠実なラベルを生成し、held_out_gate_enabled は自己学習した教訓を注入してよいかに影響します。3層とも v1.54 でデフォルト有効です。どの層でも false に変えれば、その層の挙動はこの機能が存在する前と完全に同一（byte-identical）になり、層ごとに順に無効化できます。

例：特定の種類のエージェントに限定されない

この仕組みは意図的に具体的な業務と無関係に設計されており、エンジン内部は (信頼度, 実際の結果) という抽象的な数値ペアだけを認識し、特定ドメインの語彙を一切知りません。たとえば、自分でコードを修正するコーディングエージェントは、リスクのあるリファクタリングを実行する前に「この変更でテストが通る」確率を予測し、変更後のテスト結果が外部の審判になります。「特定のエラーコードに遭遇したら、先にフォーマッタを実行してから再試行すれば通る」と帰納した場合、これはツール記録で検証できるため直接採用されます。しかし「金曜日に変更したコードは壊れやすい」といったプログラム的証拠のない統計的直感を帰納した場合は、まず候補としてサンプルを蓄積し、ベースラインに勝って初めて実際に使われます。同じエンジンが、カスタマーサポートでもトレーディングでも、他のどんな場面のエージェントでもまったく同じように動作します。

ダッシュボード表示（2026-08-13 追加）

メモリページに「予測キャリブレーション」タブが追加されました。本機能の最初のダッシュボード面であり、エージェントごとに次を表示します：予測総数／精算済み件数／平均誤差スコア（Brier、低い＝正確）、4段階の結果分布（予想どおり／小さな偏差／明確な偏差／深刻な偏差）、観測忠実度と予測ソースの分布、そして「最近の予測と結果」の対照リスト。データソースは prediction.db の task_prediction_log 監査証跡（読み取り専用 RPC forward.summary／forward.recent）です。統計ウィンドウは有界（直近 5,000 件）で、その旨を UI 上に正直に表示します。この表示面は汎用です。タスク予測を有効にしたエージェントはすべてここに現れ、特定の実験や業種に縛られません。

主要な根拠

MuZero（arXiv:1911.08265）：世界モデルは環境の完全な動態を再構築する必要はなく、意思決定に影響する量（成功可否、コスト、失敗クラス）を予測できれば十分。
Gneiting & Raftery, Strictly Proper Scoring Rules（JASA 2007）：proper scoring の定義と、有界スコアが小サンプルで log score より安定する理由。
Murphy（1973）／Siegert（QJRMS 2017）：Brier score の三分解、reliability − resolution + uncertainty。本稿のキャリブレーション判定基準の直接の根拠。
Richens et al., ICML 2025（arXiv:2506.01622）：多段タスクの成績を本当に向上させる仕組みは、数学的に必ず、抽出して検証できる世界モデルの内容を含む。本稿が「事前学習済み世界モデルは主張しないが、キャリブレーションのクローズドループは主張する」立場を取る理論的根拠。
RSEA（arXiv:2606.28374）：held-out ゲートのないオンライン自己進化は崩壊する。論文中の Dynamic Cheatsheet はシナリオ変更後に精度が 70.7% から 0.14% に落ちた。本稿の held-out 学習ゲート設計の直接の動機。
2310.01798：外部シグナルなしにモデルの自己評価だけに頼る自己修正は、効果がないかむしろ悪化する。本稿が外部ツール結果のみで採点し、LLM の自己評価を採用根拠にしない理由。