1．はじめに：すべてを通せ

前回（第5回）のラストシーンを思い出してください。キーワード共起密度 0.25 という閾値で q4 と q6 を分離することには成功しました。しかし、その閾値は q4 のためだけにチューニングされたものであり、q4’（少し変形した熱伝導率クエリ）が来れば崩れ、q6’（少しだけ Al-Al に言及した Cu-Cu クエリ）が来れば崩れる。あるクエリを救う調整は、必ず別のクエリを犠牲にする。

はたして、この無限牢獄を突破する鍵はあるのか——。

もちろん見つけることができました。ただし、それは「もっと良い閾値を見つける」方法ではありません。根本的な発想の転換が必要でした。

「これまでの単一基準による境界線は廃止。一旦すべてのパスを通し、AI自身に『このパスは少し怪しい』と注釈を付けさせる。」

これが Phase 6 の核心です。本稿では、この「排除から評価へ」の大転換——私たちが LLMガードレール（LLM Guardrail） と呼ぶ仕組み——の設計と実装、そして全クエリ復活の軌跡を詳述します。

2．発想の転換：「門番」から「案内人」へ

Phase 5.6r までの私たちは、まるで入国審査官のようなことをしていました。パスポート（density値）が 0.25 未満のパスは「類推（hypotheses）」行きのゲートに回し、0.25 以上のパスだけを「事実（facts）」の門に通す。この「門番モデル」の何が問題だったかといえば、パスポートの基準（閾値）が特定の国（クエリ）にしか通用しないことです。

Phase 6 で採用した「案内人モデル」は違います。門をなくす。すべてのパスを facts に通す。その代わり、density の低いパスには LLMが付箋を貼る——「このパスは Cu-Cu のデータから類推しています。Al-Al の直接証拠ではありません」と。

たとえて言うなら、図書館の司書です。「この本はあなたの質問に直接は答えていませんが、関連する知見が載っています」と付箋をつけて渡してくれる。借りるかどうかはあなた次第。これが LLMガードレールの本質です。

3．実装の詳細：三段階のガードレール

Phase 6 の実装は、大きく三段階で進めました。

第一段階：門を取り払う。 Phase 5.6r で導入した _classify_paths_by_keyword_density() の min_matches 制約を撤廃しました。min_matches=3 という、q6 を守るために設けた関所は、同時に q1（V-MgO）や q3（Cu-Cu bonding）を犠牲にしていました。この制約を外し、density の値に関わらずすべてのパスを direct_paths ——つまり facts ——として通過させます。

第二段階：JSONに付箋欄を追加する。 各 facts エントリに2つのフィールドを追加しました。density（そのパスのキーワード共起密度）と requires_llm_review（density < 0.25 の場合に true）。後者は「このパスにはLLMの査読が必要です」というフラグです。

第三段階：LLMに査読させる。 専用のプロンプト evaluation_llm.txt を作成し、低密度パス群をLLMに一括評価させます。プロンプトは以下のような指示で構成されます。

全体のデータフローは次のようになりました。Phase 5.6r の図1（第5回）と見比べると、その簡潔さが際立ちます。

Stage 1: PRIMARY SEARCH @ threshold=0.7
  ├─ キーワード抽出（Phase 4 既存）
  ├─ マルチエントリーポイント検索（Phase 4 既存）
  ├─ パス収集（変更なし）
  ├─ 【Phase 6 変更】全パスを direct_paths として通過
  │   └─ density 値のみ計算し、出力JSONに付与
  │
  └─ 【Phase 6 新設】LLMガードレール
      ├─ density < 0.25 のパス → LLM一括評価
      │   ├─ annotation_type: "fact" / "analogy"
      │   ├─ scientific_plausibility: high / medium / low
      │   └─ annotation: 自然言語注釈
      └─ density >= 0.25 のパス → LLMレビュー対象外（高信頼）

4．全クエリ復活：数字が語るパラダイムシフト

検証の瞬間です。Phase 5.6r で犠牲になった7つのクエリ（q1, q2_1, q2_2, q3, q5, q6_retry, q7）が、本当に復活するのか——。

全クエリ facts=1。情報喪失ゼロ。

この表を見たときの安堵感は、これまでのどのフェーズとも違う種類のものでした。q4 だけを特別扱いする閾値を撤廃し、すべてのクエリに平等に門を開いた。その代わり、density 0.007 の q6（Al-Al）には LLM が「これは analogy です」と正しく判定して付箋を貼っている。

特筆すべきは q3（Cu-Cu bonding）です。density わずか 0.009。これほど低密度でも、LLM は「Cu-Cu の文脈から妥当な事実抽出がなされている」と判断し、annotation_type: analogy と適切にラベリングしました。門番モデルなら確実に棄却されていたパスが、案内人モデルでは「注釈付きで生存」している。これこそが、私たちが求めていた姿です。

5．見えない罠：Phase 6.1 のバグ修正

全クエリ復活の喜びもつかの間、実装の裏側には細かなバグが潜んでいました。このセクションは少しマニアックですが、実際の開発とはこういうものだという証左として、2つの象徴的なバグを紹介します。

空文字列拒否バグ。 LLM が「該当なし」と出力したフィールドは空文字列 "" で返ってきます。ところが Python 側のバリデーションでは not parsed[field] と書かれていました。Python において not "" は True です。つまり、LLM が「該当なし」と正直に答えるほど、Python は「これはダメだ」と拒否していたのです。皮肉ですよね。修正は parsed[field] is None への一行変更でした。空文字列は「空である」という正当な応答として許可されるべきなのです。

循環検証の罠。 LLM の出力を検証するロジックに、こんなコードがありました。「LLM が出力した annotation_type が、プロンプトで指示した expected_class と一致しているか」。これ、よく考えると自分で教えた答えを自分で言えるかテストしているだけです。LLM が「fact と答えなさい」と教えられて「fact」と答えたら合格——それ、検証になってませんよね。この循環参照を削除し、代わりに「出力値が fact か analogy のいずれかであること」という形式的な検証に置き換えました。

これらの修正を経て、LLM のフォールバックテンプレート使用率は 0/9（0%） を達成しました。LLM が一度も失敗せず、すべて自力で評価を返したことになります。

6．残された課題：plausibility の差別化

Phase 6 は全体として大成功でしたが、ひとつだけ「宿題」が残りました。LLM の出力する scientific_plausibility（科学的妥当性）が、ほとんど “medium” に偏ってしまうのです。

全9クエリ中、high を獲得したのは q2_1（CMP+Hybrid）と q7（Summarize）の2つだけ。残り7つはすべて medium。評価基準を明示した Rubric（採点表）をプロンプトに追加しても、この偏りは解消しきれませんでした。

これは想像するに、LLM が「はっきり high と言い切ることへの慎重さ」を持っているためです。材料科学のクエリに対して「これは間違いなく正しい」と断定することを、おそらく LLM 自身が避けている。これはこれで健全な態度とも言えますが、ユーザーにとっては「ほとんどが medium なら、わざわざ表示する意味あるの？」という疑問につながります。

この plausibility 差別化問題は、Phase 7 に持ち越す継続課題としました。LLM の性格を変えるより、人間の査読者が「high/medium/low の三段階で読む」ことに慣れる方が先かもしれません。

7．パラダイムシフトの本質：プログラムは「判断」を手放した

Phase 4 から Phase 6 までの道のりを、少し大きな視点で振り返ってみます。

Phase 4 でマルチエントリーポイント化を実装したとき、私たちは 「網羅性」 を手に入れました。Phase 5 で二段階ルーティングを実装したとき、「構造（facts/hypotheses）」 を手に入れました。Phase 5.6 でキーワード共起密度を実装したとき、「定量性」 を手に入れました。

そして Phase 6 で、私たちは思い切って 「判断」を手放したのです。

閾値で切り捨てる権限をコードから剥奪し、代わりに「このパスは少し怪しいかもしれません」と言う権限を LLM に与えた。これは単なる設計変更ではありません。AIシステムの設計思想におけるパラダイムシフトです。

「排除から評価へ」——これはコードを書く研究者にとって、驚くほど勇気のいる決断です。自分たちが書いたロジックで品質を保証することを諦め、LLM という確率的なブラックボックスに「査読」を委ねる。査読項目を制限することで、熟練研究者レベルの品質を担保する。

この決断がもたらした3つの副産物を書き留めておきます。

第一に、コードの単純化。 分類ロジックが消え、閾値パラメータが消え、LLM呼び出しを伴うバリデータが消えました。Phase 5.6 初版の複雑な機構（第4回参照）と比べると、Phase 6 のコードは嘘のようにスリムです。

第二に、品質の底上げ。 全9クエリ facts=1。情報喪失ゼロ。5,094パスの q6 も、16パスの q4 も、すべてがユーザーに届きます。LLM の付箋付きで。

第三に、説明可能性の向上。 「なぜこのパスは facts なのか」「なぜ類推なのか」を、LLM が自然言語で説明してくれます。density=0.007 という数字よりも、「Cu-Cu の結合メカニズムから Al-Al への転移推論です」という文章の方が、研究者には遙かに有用です。

8．次回予告：誰もが使える推論プラットフォームへ

Phase 6 で ARIA-Forge の推論エンジンは、一つの完成形に到達しました。しかし、ここまでの ARIA-Forge は純粋なバックエンド API ——つまり、コマンドラインから Python スクリプトを叩いて使う開発者専用ツールです。

これを、研究者が対話的に使える Web アプリケーションにする。それが最終章 Phase 7 の挑戦です。

次回、第7回「誰もが使える推論プラットフォームへ —— GUI化と次なるフロンティア」では、Streamlit を用いた GUI 化のプロセス、エンジンキャッシュによる高速テストサイクルの実現、そして全固体電池など未知ドメインへのストレステスト構想についてお話しします。シリーズ最終回——ARIA-Forge が「実験室の道具」から「共有可能なプラットフォーム」へと羽ばたく瞬間を、ぜひ見届けてください。