第9章：AIエージェントの品質保証 ― eval を頑張るな、アーキテクチャで勝て
― eval が複雑になるのは、LLM にやらせすぎているサインである
AI エージェントを本番に載せたとき、最初にぶつかる壁は「品質保証」だ。
LLM は確率的な存在である。同じ質問をしても、毎回同じ答えが返る保証はない。従来のソフトウェアテストのように「期待値と一致するか」で判定できない。
この不確実性にどう向き合うか。設計は大きく2つに分かれる。
- eval（評価）の精度を極めるアプローチ
- アーキテクチャで品質を担保するアプローチ
本章では、前章までに述べた設計原則 ― 文脈の分離、タスク外部化、レポート化 ― が、品質保証にどう帰結するかを検証する。
eval の精度を上げるアプローチ
業界では、LLM の出力品質を保証するために eval の精度向上に大きな投資が行われている。
典型的な手法はこうだ。構造化された判定基準（Rubric）を設計し、LLM 自体に「LLM-as-a-Judge」として判定させる。JSON 検証や文字列比較による決定的判定と、LLM による意味的評価を二層に重ねることで、精度を高める。
技術的に洗練されたアプローチだし、特定のユースケースでは合理的な選択だ。
しかしこのシリーズを通じて考えてきた「構造で品質を担保する」思想から見ると、別の問いが浮かぶ。
eval の精度を上げる以外に、品質を担保する方法はないのか？
3つの原則
私たちの設計を貫く原則は3つある。
- LLM にはテキストを渡す。データは渡さない。
- 曖昧さは構造で吸収する。
- 品質は「正しいソースを使ったか」で保証する。
個々の実装よりも、この3つの原則が全体を貫いていることが重要だ。
原則1：LLM にはテキストを渡す
LLM に生データを渡して「集計して」と言えば、答えは返ってくる。しかしその答えは毎回違う。数値の見落とし、誤った合算、文脈の取り違え。
LLM はテキストの理解と要約には極めて優秀だが、数値の集計や横断比較は安定しない。だから私たちは、LLM にデータの分析をさせない設計にした。
第6章で述べたレポート化アーキテクチャの実践だ。ETL パイプラインが事前にデータを分析し、1つの事実を1つの構造化レポートに変換する。エージェントはそのレポートを「読んで」回答するだけ。
同じレポートを読めば、同じ事実が出る。回答の揺らぎは「どのレポートを取得したか」に帰着する。
品質の制御ポイントが、LLM の出力ではなくレポート選択に移る。
原則2：曖昧さは構造で吸収する
データをレポート化しても、正しいレポートにたどり着けなければ意味がない。そしてユーザーの入力は常に曖昧だ。
この曖昧さを LLM のプロンプトで吸収するか、構造で吸収するか。ここに設計の分岐がある。
第3章で述べた「タスク外部化」の原則がここにも効いている。曖昧な入力を正確な検索条件に変換する責務を、LLM ではなく検索エンジンが担う。LLM にやらせれば毎回ブレる処理が、検索エンジンなら確定的に動く。
原則3：正しいソースを使ったかで保証する
ここまでで、正しいレポートを読めば正しい事実が出る状態と、曖昧な入力から正しいレポートに到達できる状態が揃った。この2つが揃って初めて、3番目の原則が成立する。
LLM に「回答は正しいか？」と聞く必要がない。「正しいソースを使ったか？」を静的に検証するだけで、品質の下限を保証できる。
eval がシンプルで済むのは手を抜いているからではない。上流の設計が品質を担保しているからだ。
確率を敵にするか、味方にするか
一般的な eval 重視のアプローチは、確率を排除しようとする。1回の判定を確定的に正しくしたい、という思想だ。
私たちのアプローチは逆で、確率を受け入れている。1回の判定が完璧でなくても構わない。代わりに、複数回実行して統計で品質を見る。
ここで重要なのは、一貫性が低いとき、それは eval の問題ではなく、上流の問題を示唆している ということだ。
実際に一貫性スコアが極端に落ちたケースがあった。原因を調べると、eval の判定が悪いのではなく、集約という本来 LLM に任せるべきでない処理を LLM がやっていた のが問題だった。集約済みのレポートを用意すれば、LLM は「読んで答える」だけで済む。
eval を改善しても、この問題は解決しなかった。レポートの設計が品質の上限を決める。 これがアーキテクチャで品質を担保するということだ。
シリーズ全体との接続
この章で示した品質保証は、前章までの設計原則の帰結だ。
第3章「タスク外部化」が効いている。数値集計、曖昧入力の解決、レポート選択の検証。これらはすべて LLM の外に出した処理だ。LLM でもできるが、LLM でやる必然性がない。外に出せば確定的に動く。
第6章「レポート化アーキテクチャ」が効いている。原子データを分子レベルに集約し、LLM は読むだけ。だから回答の揺らぎが小さく、eval に求められる識別力も低くて済む。
第7章「安定性設計」の「文脈・実行・時間の三分離」が効いている。品質の制御ポイントが LLM の出力から上流に移るから、問題が起きたときの診断もシンプルになる。
eval が複雑になるのは、LLM にやらせすぎているサインである。
LLM から還元可能な仕事を剥がしていくと、最後に残るのは「事実を読み取り、文脈に応じて、人に伝える」という本質的な仕事だけだ。それこそ LLM が最も得意とする領域であり、そこに全力を集中させたい。
この章のまとめ
- eval の精度を極めるアプローチと、アーキテクチャで品質を担保するアプローチは、対立ではなく補完である
- LLM にはテキストを渡す。データは渡さない
- 曖昧さは構造で吸収する。LLM のプロンプトで吸収しない
- 品質は「正しいソースを使ったか」で保証する
- 確率を排除するのではなく、確率を前提にした検証を設計する
- 一貫性が低いとき、それは eval の問題ではなく上流の問題である
- eval が複雑になるのは、LLM にやらせすぎているサインである
具体的な検証設計（多層品質保証、一貫性スコア、診断マトリクス）の実装については、実装概論シリーズの品質保証章で詳しく解説する。
Last Updated: 2026-04-06