第11章：品質保証OS ― 多層検証で「壊れない」を証明する
— eval 単体に全賭けしない。検証を分解し、各層が1つの問いだけに答える。
設計概論（第9章）で述べた通り、品質保証の原則は3つだ。
- LLM にはテキストを渡す。データは渡さない。
- 曖昧さは構造で吸収する。
- 品質は「正しいソースを使ったか」で保証する。
本章では、この原則を どう検証の仕組みに落とし込むか を実装レベルで解説する。
11.1 なぜ eval 単体では不十分か
eval の精度をどれだけ上げても、以下の問題は解決しない。
- レポートの粒度が粗くて、LLM が集約を強いられている
- 正しいレポートに到達できず、別の事実を読んでいる
- そもそも回答が返ってこない（タイムアウト）
これらはすべて eval の上流にある問題 だ。eval は「出力の品質を判定する仕組み」であって、「品質を生み出す仕組み」ではない。
問題を検知する仕組みと、問題の所在を特定する仕組みは別物だ。
11.2 多層品質保証の設計
検証を4つの層に分解し、各層が1つの問いだけに答える。
第1層：「動いたか」（静的判定）
回答が返ったか。タイムアウトしなかったか。LLM は使わない。二値判定。
実装は単純だ。HTTPステータス、レスポンスの有無、所要時間の閾値チェック。ここで落ちるなら、eval以前の基盤の問題。
第2層：「伝わったか」（内容評価）
回答がレポートの事実をきちんと伝えているか。ここだけ LLM を使う。
ただし評価基準はシンプルなフリーテキストで十分だ。「具体的な企画名を挙げているか。流入元に言及しているか。」
上流がレポート化されているから、回答の揺らぎが小さい。eval に求められる識別力も低くて済む。上流の設計がevalの負荷を決める。
第3層：「安定しているか」（一貫性スコア）
同じ質問を複数のプロトコルで、複数回投げる。そして得られた複数の回答を比較し、「事実・数値・結論が一致しているか」を一貫性スコアとして算出する。
- スコア 1.0: 全回答が同じ内容 → 信頼できる
- スコア 0.5: 主要な事実は一致するが一部に差異 → 要調査
- スコア 0.2 以下: 回答がバラバラ → 設計上の問題がある
1回の判定精度を極めるより、複数回回して統計で見る方が信頼できる。
一貫性が低いとき、それは eval の問題ではなく、上流の問題を示唆している。
実際に一貫性スコアが 0.2 まで落ちたケースがあった。ある番組の「3ヶ月間で流入が多かった企画」を聞く質問だ。毎回異なる回答が返ってきた。
原因を調べると、集約という本来 LLM に任せるべきでない処理を LLM がやっていた。14本の個別レポートを読んで自力で集約するから、毎回ブレる。集約済みのレポートを1本用意すれば、LLM は「読んで答える」だけで済む。
eval を改善しても、この問題は解決しなかった。レポートの設計が品質の上限を決める。
第4層：「正しいソースを使ったか」（レポート検証）
LLM は使わない。「この質問なら、この種類のレポートを使うべき」という制約を正規表現でマッチングするだけだ。
この第4層が、エコシステム全体の安定性を決定的に高めている。正しいレポートを使っていれば、回答に含まれる事実はレポートに書いてある通りだ。eval は「正しい事実を伝えられているか」という表現面だけ担えばいい。
11.3 診断マトリクス ― 「何を直すべきか」を特定する
4層の検証結果を突き合わせれば、「何を直すべきか」がわかる。
eval 単体の精度を上げても、この診断能力は得られない。
11.4 エコシステムとしての循環
3つの原則と4層の検証。これらが個別に存在するのではなく、循環している点にこの設計の真価がある。
LLM に読ませるレポートが正確だから、eval の判定もシンプルで済む。曖昧な入力を構造で吸収しているから、正しいレポートにたどり着ける。正しいソースを使ったかを静的に検証しているから、LLM に品質を聞かなくていい。
どれか1つが欠けても、エコシステムは成立しない。
これを実装レベルで見ると：
- レポート化（第6章メモリOS） が品質の上限を決める
- タスク外部化（第5章タスクOS） が曖昧入力の解決を確定的にする
- 文脈分離（第4章エージェントOS） がLLMの判断を安定させる
- 品質保証OS（本章） が上記すべてが機能しているかを検証する
4つのOSが揃って初めて、エージェントは「壊れない」と言い切れる。
11.5 実装手順
① 第4層（レポート検証）から作る
最もシンプルで、最も効果が高い。「この質問にはこのレポート種別を使うべき」のルールを定義し、正規表現でマッチングする。LLMを使わないので、即日実装できる。
② 第1層（静的判定）を加える
レスポンスの有無、タイムアウト、ステータスチェック。CI に入れる。
③ 第3層（一貫性スコア）を組む
同一質問を N 回投げ、回答を比較する。スコアが閾値を下回ったら、レポート粒度を見直す。
④ 第2層（内容評価）は最後に入れる
ここだけ LLM を使う。上流が整った状態で入れるから、eval基準はシンプルで済む。Rubricを精緻に作り込む必要がない。
この順序が重要だ。 第2層から作ると、evalの精度を上げることが目的化する。第4層から作ると、品質の構造的な担保が先に入る。
11.6 この章のまとめ
- ✔ eval単体では品質は保証できない。検証を4層に分解する
- ✔ 第1層：動いたか（静的判定）
- ✔ 第2層：伝わったか（内容評価、ここだけLLM）
- ✔ 第3層：安定しているか（一貫性スコア）
- ✔ 第4層：正しいソースを使ったか（レポート検証）
- ✔ 診断マトリクスで「何を直すべきか」を特定する
- ✔ 4つのOS（文脈・タスク・メモリ・品質保証）が揃って初めてエージェントは壊れない
- ✔ 実装は第4層→第1層→第3層→第2層の順で入れる
Last Updated: 2026-04-06