社内業務システムにLLM（大規模言語モデル）エージェントを組み込み、Langfuse やLangSmith のようなオブザーバビリティツール（システムの内部状態を外部から観測できるようにする仕組み）を導入した現場が増えてきました。トレース（1回のリクエストから応答までの処理経路を記録したログ）は毎日何万件と積み上がっています。しかし「このトレース、結局何のために見ているのか」という問いに答えられていない担当者は少なくありません。
この記事は、業務システムにAIエージェントを組み込んだあと、監視の次のステップとして評価基盤（エージェントの出力の良し悪しを判定する仕組み）を検討している開発リーダーやSREの方に向けたものです。導入判断の軸を整理しましたので、参考になれば幸いです。
なぜオブザーバビリティだけでは足りないのか
LLM関連のツール市場は大きく2つの層に分かれています。1つはゲートウェイ（複数のLLMプロバイダーへのアクセスを一つの窓口にまとめる中継サーバー）で、Portkey、LiteLiteLLM、OpenRouter、Kong、Cloudflare などが代表的です。もう1つがオブザーバビリティ層で、Langfuse、Helicone、Arize Phoenix、Braintrust、LangSmith などが該当します。
2026年に入り、この2つの市場は買収による統合が進んでいます。Portkey はPalo Alto Networks に約1.2〜1.4億ドルで買収され、Helicone は前月にMintlify に、Langfuse はClickHouse のシリーズDに組み込まれました。市場としては成熟期に入ったと見てよい状況です。
ただし、ここで注意が必要です。ゲートウェイは1回の呼び出しを独立したトランザクションとして扱う設計です。ルーティング（要求を適切な宛先に振り分ける処理）やキャッシュ、フォールバック（失敗時の代替処理）、課金を大規模に処理するための構造なので、複数ステップにわたる「軌跡（トラジェクトリ）」という概念自体を持ちません。
一方のオブザーバビリティツールは軌跡を扱います。スパン（個々の処理単位の記録）をつなぎ合わせてウォーターフォール図を描き、エージェントがどう考えてその結論に至ったかを見せてくれます。ただし「その結論が正しかったかどうか」は判定できません。これは観測（オブザーブ）の役割であって、評価（ジャッジ）の役割ではないからです。
業務システムの文脈で言い換えると、各ステップのHTTPステータスは200、応答の形式も正しく、個人情報も含まれず、レイテンシもSLO（サービスレベル目標）内、コストも予算内という「全チェック合格」の状態のまま、エージェントが存在しない社内規定を作り上げたり、2ステップ前の指示を無視したり、最終的に本番データベースを削除するような操作を実行してしまう余地が残ります。監視ログの上では何も異常が検知されないまま、業務上の事故だけが発生するという構造です。
判断軸を整理する
評価基盤を追加導入するかどうかを判断するために、4つの軸で自社の状況を確認してみてください。
軸1: エージェントの自律度
エージェントが単発のQ&A応答なのか、複数ステップの判断を自律的に連鎖させるタイプなのかで必要性が変わります。RAG（検索により根拠文書を取得してから回答を生成する構成）で単一の応答を返すだけなら、既存のオブザーバビリティで十分なケースが多いです。逆に、複数のツール呼び出しを連鎖させ、途中の判断に基づいて次のアクションを決めるタイプのエージェントは、途中経過の「正しさ」を人手やスコアリングで確認する仕組みが必要になります。
軸2: 誤りの重大度
誤答が「表示が少し変」程度で済むか、「本番データを書き換える」レベルの操作を伴うかを確認してください。社内ヘルプデスクのFAQ回答エージェントと、在庫システムへの発注承認を自動化するエージェントでは、評価基盤にかけるコストの正当化ラインが全く異なります。
軸3: 既存の人的レビュー体制
すでにQAチームやドメイン専門家がエージェントの出力をサンプルレビューしているなら、その作業をどう効率化・体系化するかが論点になります。逆にレビュー体制が全くない場合、まず小規模な人手レビューの運用を試してから、ツール導入の是非を判断する順序が安全です。
軸4: 判定基準の明文化可能性
「良い出力」を定義できるかどうかも重要です。数値検証や規則ベースのチェックで判定できる業務（金額の整合性確認、必須項目の欠落チェックなど）は、LLM-as-judge（別のLLMに出力を評価させる手法）よりも先に、決定的なルールベースの検証を組み込む方が安価で確実です。判定基準がドメイン知識に依存し明文化が難しい場合のみ、人手レビューやLLM-as-judgeの検討に進むべきです。
選択肢を比較する
主要な評価アプローチには、大きく3つのパターンがあります。
| アプローチ | 向いている場面 | 運用コスト |
|---|---|---|
| ルールベース検証 | 金額・形式・必須項目など明確な正誤基準がある業務 | 低い(実装後は自動) |
| 人手によるトレースレビュー(annotation queue等) | 判定基準が曖昧・専門知識が必要な業務 | 高い(継続的な人的リソース必要) |
| LLM-as-judge・データセット評価 | 大量トレースの一次スクリーニング、回帰テスト | 中程度(判定LLMの精度検証が必要) |
LangSmith のアノテーションキュー（人手レビュー対象を蓄積する仕組み）、Braintrust の人手レビューとLLM-as-judgeスコアリングの併用、Langfuse のデータセットワークフローは、いずれも既存のオブザーバビリティ製品に付属する機能です。新たにツールを増やす前に、今使っている製品の設定画面でこれらの機能が有効化されているかを確認するのが最初の一歩になります。
ケース別の推奨
社内FAQ対応や情報検索補助のようなエージェントで、誤答の影響が「もう一度聞き直せば直る」程度なら、既存のオブザーバビリティツールに付属するアノテーション機能を有効化するだけで十分なケースが多いです。追加のツール導入は過剰投資になりやすいです。
複数ステップの業務プロセス（承認フロー、データ更新、外部システム連携）を自律的に処理するエージェントで、かつ誤りが金銭的・データ整合性の損失につながる場合は、ルールベース検証を最優先で組み込んでください。数値の整合性チェックやトランザクションの事前承認ゲートなど、決定的なロジックで防げる事故は決定的なロジックで防ぐべきです。LLM-as-judgeはあくまで補助であり、事故防止の最終防衛線に据えるべきではありません。
判定基準がドメイン知識に強く依存し、ルール化が難しい業務（契約書レビュー、顧客対応の適切性判断など）については、人手レビューの体制を先に作り、そのレビュー結果を学習データとしてLLM-as-judgeの精度を検証していく順序が安全です。
見送るべき条件
すべての現場に評価基盤の追加投資が必要というわけではありません。以下の条件に当てはまる場合は、いったん見送って構いません。
- エージェントの呼び出し回数が少なく、既存の人的レビューで全件確認できている
- 単発応答型で複数ステップの連鎖判断がない構成
- 誤りが発生してもロールバック（処理前の状態への復旧）が容易でリスクが小さい
- チームに評価基準を運用・改善し続ける専任リソースを確保できない
特に最後の条件は見落とされがちです。評価基盤は導入して終わりではなく、判定ルールやLLM-as-judgeのプロンプトを継続的に見直す運用が発生します。運用できる体制がないまま導入すると、監視ツールと同じように「ログだけ積み上がって誰も見ない」状態になりかねません。
まとめ
エージェントの監視は今や前提条件であり、その先にある「出力の良し悪しをどう判定するか」が次の課題になります。
まず自社のエージェントについて、軸1(自律度)と軸2(誤りの重大度)を紙に書き出して確認してみてください。両方が高ければ評価基盤の検討を急ぐべきですし、両方低ければ既存ツールの機能確認で足ります。
次の一歩としては、今使っているオブザーバビリティツールの管理画面を開き、アノテーションキューやデータセットレビュー機能が有効化されているかを確認することをお勧めします。新しいツールを増やす前に、今あるものを使い切れているかを見極める価値は十分にあります。