Quality by Design
検証可能なエージェントアーキテクチャの設計原則
検証できないものは設計できない
確率的なシステムの品質保証には、根本的な問いがある。
「正しいか？」という問いに答えられる構造になっているか。
この問いを LLM に委ねることはできない。LLM に「この回答は正しいか？」と聞いても、答えは確率的だ。eval を重ねれば精度は上がるかもしれないが、eval 自体が確率的な存在に依存している。評価基準が増えるほど、評価する仕組み自体が複雑化し、何を信頼すべきかがわからなくなる。
設計の起点はここにある。「検証可能な問いに変換してから設計する」。
変換という発想
品質保証の設計には2つの方向がある。
ひとつは、確率的な出力を事後的に評価する方向。LLM の回答を LLM が評価する。eval の精度を上げる。これは合理的に見えるが、スケールしない。評価基準が増えるほど、評価する仕組み自体が複雑化し、何を信頼すべきかがわからなくなる。
もうひとつは、問いを変換する方向。「これは正しいか」という検証不能な問いを、「これは仕様に合致しているか」という検証可能な問いに変換する。変換に成功すれば、判定は静的になる。LLM を使わなくていい。
Quality by Design とは、この変換を設計の段階で行うことだ。
3つの原則がある。それぞれが異なる層で「検証不能な問い」を「静的に確認できる問い」に変換する。
原則 1：Reportization
変換: 「内容は正しいか」→「正しいソースを使ったか」
LLM に生データを渡して「要約して」と言えば、毎回違う答えが返る。数値の見落とし、誤った合算、文脈の取り違え。内容が正しいかは、読んでみなければわからない。
レポート化アーキテクチャはこの問いを変換する。ETL パイプラインが事前にデータを分析し、一つの事実を一つの構造化レポートに変換する。LLM はそのレポートを「読む」だけだ。
変換前: 「この回答の内容は正しいか？」（LLM judge が必要） 変換後: 「正しいレポートを参照したか？」（静的パターンマッチで判定可能）
正しいレポートを参照した回答は、正しい事実を伝えている。「内容の正しさ」を「ソースの正しさ」に変換する。これが Reportization の本質だ。
原則 2：Tag as Document
変換: 「解釈は正しいか」→「正しいタグに収束したか」
レポートが正確に構築されていても、正しいレポートにたどり着けなければ意味がない。ユーザーの入力は常に曖昧だ。「〜に関するもの」という問いは、精確な検索条件として定式化されていない。
この曖昧さを LLM のプロンプト解釈で吸収すれば、同じ入力でも毎回異なる検索条件が生まれる。LLM の解釈が揺れるから、検索結果が揺れる。揺れの根拠を遡ることができない。「なぜこの結果が返ってきたか」がブラックボックスに入る。
tag as document は、この問いを変換する。対象に紐づくあらゆる属性を「タグ」として抽出し、それぞれを独立した検索可能なドキュメントとして格納する。タグは DB のラベルではなく、検索可能な意味の節点だ。タグが独立して存在することで、曖昧な入力に対して検索エンジンが「どのタグに近いか」を判定できる。変換の責任が LLM から検索エンジンに移る。
変換前: 「LLM はこの入力を正しく解釈したか？」（追跡不能） 変換後: 「この入力は正しいタグに収束したか？」（ログで静的に確認可能）
「どのタグに収束したか」はログに残る事実だ。収束先を確認すれば、解釈の正否を人間が直接判断できる。LLM の内部で何が起きたかを問わず、出力を検証できる。
本章では、この原則を品質保証の文脈における位置づけとして示す。
原則 3：Structured Output
変換: 「提案は適切か」→「指定フォーマットで出たか」
LLM の出力が自由形式のテキストである限り、品質の判定は意味的評価を必要とする。「この提案は適切か」という問いは、文脈と基準を持つ人間か、高精度な LLM judge が必要だ。
構造化出力はこの問いを変換する。エージェントの出力フォーマットを設計段階で固定し、LLM の出力を JSON スキーマや型定義に射影する。フォーマットに合致しているかは、パターンマッチで判定できる。
変換前: 「この提案の質は適切か？」（LLM judge が必要） 変換後: 「指定された構造で出力されたか？」（スキーマバリデーションで判定可能）
フォーマット設計は検証設計だ。
何を出力すべきかを先に決めることは、何を検証できるかを先に決めることと等価だ。出力を「何でもいい」にするたびに、検証を後回しにしている。
構造化出力は出力の自由度を下げる。これはトレードオフではなく、設計の方針だ。自由度の高い出力が必要なケースは、ほとんどの場合「フォーマットをまだ決めていない」だけだ。出力フォーマットを決めることは、エージェントに何をさせるかを明確にすることでもある。
Deterministic Verifiability Ratio — 設計品質のメトリクス
3つの変換原則を導入することで、設計の品質を一つの指標で表現できる。
DVR（Deterministic Verifiability Ratio）は、検証の何割が静的に行えるかを示す設計メトリクスだ。
設計前の典型的なシステムでは、ほとんどの品質問は LLM judge に委ねられている。「回答の内容は正しいか」「解釈は意図通りか」「提案のトーンは適切か」。すべてに LLM judge が必要なら、DVR ≈ 0.2 だ。
3原則を適用すると変わる。
| 検証項目 | 変換前 | 変換後 |
|---|---|---|
| 回答内容の正確さ | LLM judge 必要 | 参照レポートの確認で静的判定可 |
| 入力解釈の正否 | 追跡不能 | タグ収束先をログで静的確認 |
| 出力フォーマット | LLM judge 必要 | スキーマバリデーションで静的判定 |
| 動作の完了 | 静的判定（元から） | 静的判定（変化なし） |
設計後の DVR は ≈ 0.8 に達する。残る 0.2 は「事実を正しく伝えられているか」の意味的評価など、構造では変換しきれない部分だ。そこには eval を使う。ただし、大部分が静的に保証された後の eval は、ずっとシンプルで済む。
DVR の使い方
設計の評価: 設計完了時点で DVR を計算する。「このシステムは設計段階で品質の何割を静的に保証できるか？」を問うメトリクスとして機能する。0.8 を超えなければ、設計をやり直す判断基準になる。
改善の指針: DVR が低いとき、どの原則が未適用かを特定できる。「正しいソースを使ったか」が判定できていないなら Reportization が不足している。「解釈の揺れ」が検証できていないなら tag as document が機能していない。「出力検証に LLM judge を使っている」なら Structured Output を検討する。
DVR は完成したシステムを測定するツールではなく、設計プロセスの中で使うメトリクスだ。設計しながら DVR を上げることが、Quality by Design の実践になる。
agent-probe はツールではなく設計の帰結だ
品質保証のツールとして agent-probe を紹介することができる。しかしその順序は逆だ。
agent-probe が有効に機能するのは、3原則が揃っているときだ。正しいレポートが存在し、タグによる検索が機能し、出力フォーマットが固定されている。この状態であれば、agent-probe は「正しいソースを使ったか」「正しいタグに収束したか」「フォーマットに合致したか」を自動で検証できる。
原則がなければ、agent-probe は動いても何も判定できない。「回答は正しいか」という検証不能な問いに向き合い続けるだけだ。
ツールは設計の上に成立する。設計のない場所でツールは機能しない。
これはツールの限界ではなく、設計の責任の話だ。品質保証ツールを導入して問題が解決しないとき、たいていの場合、設計が変換をしていない。eval を強化しても、DVR が低い設計の上では意味がない。
統合フレームとして
第6章で Reportization を扱った。本章で Tag as Document、Structured Output、DVR を加えた。
3原則に共通する変換の構造は一つだ。
「LLM に判断させる問い」を「静的に確認できる問い」に変換する。
変換の成功が DVR を上げ、DVR が高い設計がスケールする。eval が必要になるのは、変換できなかった残余の部分だけだ。
確率的なシステムの品質保証は、確率と戦うことではない。確率を前提として、確率に委ねる問いの範囲を設計で絞ること。その絞り方が DVR として測定できる。
確率的システムの品質保証が「何をするか」を示しているとすれば、本章は「なぜそれで機能するか」と「どこまで設計できているかを測る方法」を示している。
まとめ
- Reportization: 「内容は正しいか」→「正しいソースを使ったか」への変換。ソースが正確なら、出力は静的に保証できる
- Tag as Document: 「解釈は正しいか」→「正しいタグに収束したか」への変換。タグが意味の節点として機能するとき、曖昧さは検索エンジンが吸収する
- Structured Output: 「提案は適切か」→「指定フォーマットで出たか」への変換。フォーマット設計は検証設計と等価だ
- DVR: 3原則の適用度を一つの数値で表す設計メトリクス。設計プロセスで使う。目安は 0.8 以上
- agent-probe: 3原則が揃ったとき初めて有効に機能する。ツールの有効性は設計に依存する
Last Updated: 2026-05-27