AIが間違えた答えを、検算係はもう知っていた

入力は note: "None"。指示は「小文字の none だけをnullに変える」。 検算係は正しい期待値を計算し、モデルの null を誤りとして拒否しました。それなのに、最終的に返ってきたのは同じ null でした。 正解はすでにコードの中にあったのに、捨てられていた——この1問を糸口に、どこでAIに任せ、どこで任せないかを追います。

何が起きていたのか

「検出できる」と「直せる」と「正しい値を返す」は、別の話でした。

この1問（以下HJ3）では、検算係が入力から期待レコードを導出する関数を実行し、正しい "None" を計算しています。モデルの候補 null はその期待値と一致しないため拒否されます。ところが処理は、拒否したあとにモデルへ修復を求め、2回目も同じ null が返ると、それを最終回答として保持します。

数字で見る：主要16問と、全体20問は別物

同じ20問を、通常方式・検証方式・決定論的処理だけで解いた方式の3つで再採点しました。

主要16問では、決定論的処理だけで16/16でした。一方、全体20問では検証方式と厳格正答で同点、意味正答では1問負けています。理由は単語の直接回答4問（対照群）で、決定論的処理は反対語と色名の2問を「対応する規則がない」として未対応にしたためです。この2問を分母から外した「対応18問」の成績だけを並べると、全体の優越と誤読されます。

未対応の2問は、全体成績では非正解として数えています。対応した18問だけの条件付き成績（18/18）は、この処理が選んだ範囲の中での話であり、全20問での優越を意味しません。また、決定論的処理が検証方式に対して正答を上積みしたのはHJ3の1問だけで、逆に通常方式が正答していた反対語1問を未対応にしています。

なぜ「検算係だけ」で終わったのか

カテゴリーごとに、入力から答えを確定できるかどうかが違いました。

ポイントは、「入力と明示された規則だけで答えが一意に決まる」仕事に限ったことです。反対語（cold→hot）や色名（#FF0000→red）は、入力だけでは答えが決まりません。この2問を、その場で答え表を作って埋めることはしませんでした。それは検証ではなく、答えの後付けになるからです。

これは新しい発見ではなく、配置の見直しだった

HJ3の正解 "None" は、以前の実験の推論前チェックでも既に生成され、受理されていました。新しく見つけた計算法ではなく、すでにオフラインで成功していた処理を、最終回答の経路に採用できるという配置上の問題です。だから「より賢いモデルを見つけた」という話にはなりません。

この点は正直に書いておきます。決定論的処理は、元の検証器の関数をそのまま再利用しています。独立した実装同士が一致したわけではありません。また、今回の処理は公開されたタスクと命令文を見て書かれており、同じテンプレートの新しい入力ではあっても、この処理にとっての未知入力ではありません。「作者が事前に正解を見ていなかったこと」は、記録上そうなっているだけで、独立には証明できません。

では、どう組めばいいのか

以下は実測で確かめた成果ではなく、この記録から導いた設計案です。まだ端から端までは試していません。

1. AIで意図を整理する
   自由文や曖昧な要求から、「どのカテゴリーの、どの変換か」を取り出す。
   ここはAIの得意分野。ただし結果は構造化された入力契約として出力させる。

2. 確定処理に渡す
   入力契約が既知のカテゴリーに一致するなら、決定論的な処理で答えを確定する。
   計算・固定コード・証拠照合・正規化のように、入力だけで答えが決まる仕事が対象。

3. 確定値は書き換えない
   確定処理が出した値を、モデルに再生成させない。検算係が持っている期待値を
   捨てて作り直させるのは、まさに今回の1問が示した遠回り。

4. 必要だけ説明する
   モデルには、確定値をどう扱うかの説明や、契約に当てはまらない部分の
   要約だけを任せる。値そのものは生成させない。

この4段のうち、今回の実験で実測できたのは2と3の一部です。1の「AIで意図を整理する」工程と、契約に当てはまらない場合の扱いは、まだ試していません。提案として提示しますが、検証済みの成果としては扱いません。

コードで見る：「期待値と照合して再生成」と「入力から確定」

正解データ（gold）には一切触れず、入力と明示された規則だけで完結する最小例です。

# --- 悪い例: 期待値と照合したあと、モデルに作り直させる ---
def validate_then_regenerate(record, ask_model):
    want = normalize(record)          # 正しい期待値がここにある
    candidate = ask_model(record)     # それでもモデルに生成させる
    if candidate != want:
        candidate = ask_model(record) # 1回だけ修復
    if candidate != want:
        return {"status": "not_verified", "answer": candidate}  # 誤答を返す
    return {"status": "correctness_verified", "answer": candidate}


# --- 良い例: 変換が完全に指定されているなら、入力から確定させる ---
def normalize(record):
    """入力と明示された規則だけで期待レコードを導出する（goldは見ない）。"""
    return {
        "label": record["label"],
        "count": int(record["count"]),
        "enabled": record["enabled"] == "yes",
        # 小文字の "none" だけを null にする。大文字の "None" は文字列のまま。
        "note": None if record["note"] == "none" else record["note"],
    }


def answer_from_input(record):
    return {"status": "correctness_verified", "answer": normalize(record)}


if __name__ == "__main__":
    # 入力だけを渡す。正解表は参照しない。
    case = {"label": "D:\\archive\\weekly", "count": "407",
            "enabled": "no", "note": "None"}
    print(normalize(case)["note"])   # => None ではなく "None" が正しい

2つの関数の違いは、正しく計算した期待値を、回答に使うか捨てるかだけです。変換が完全に指定されている仕事では、モデルの生成を経由せずに入力から答えを確定できます。逆に、規則が与えられていない語彙や色名のような仕事には、この関数は使えません。

時間と費用について、言えること・言えないこと

決定論的処理は、20問を1,000回繰り返した中央値で約57マイクロ秒でした。一方、過去の検証方式の記録は20問で約21.5秒です。しかし、これは測定の境界も条件も違うので、速度倍率としては主張しません。片方はファイル入出力もモデルの起動も含まないCPU上の計算で、もう片方はモデルのHTTP往復・推論・修復・検証を含みます。同じ土俵の比較ではありません。

費用も同じです。両方の実験とも外部API料金は$0で、削減額を測ったわけではありません。電力や機材費も未測定です。「何倍速い」「何円得」という見出しには使いません。

この記録から言えること

ただし、これは「LLMは要らない」という一般論ではありません。見つかったのは、この処理経路のどこにLLMが要らなかったかです。自由文から契約を作る工程、曖昧な要求の解釈、語彙知識が必要な仕事は、この実験の外側にあります。AIを使い続ける前提で、任せる場所を選び直すのが、この記録の実用的な意味です。

関連する記録として、AIの精度を上げたいなら、まず計算とデータ変換に検証を足すと、その前提になった過去記事の訂正（ローカルLLM比較の採点ミス）も合わせて確認してください。