木村 健人
セールスエンジニア
「Looking Back at Datadog Live」は、これまでに開催した Datadog Live のセッションをあらためて振り返り、当日会場でどんな話が交わされていたのかを記事として残していくシリーズです。イベントそのものは一日で終わってしまいますが、そこで語られた実践知はあとから読んでも役に立ちます。ご参加いただいた方には記憶の手がかりとして、参加が叶わなかった方には当日の空気に触れる入口として読んでいただければ幸いです。
今回振り返るのは、2026年5月20日に開催した Datadog Live Tokyo 2026 のメインセッション、Fireside Chat「AI エージェントを見守る技術 ― 現場から考える Agent Observability」です。モデレーターは Datadog Japan のセールスエンジニアである木村が務めました。
本セッションはアーカイブを公開しております。当日の模様も是非動画でご覧ください。
ご登壇いただいたのは、石垣 雅基 様（株式会社LegalOn Technologies）と若原 義隆 様（株式会社日本経済新聞社）のお二人です。
LegalOn Technologies では、法務向けプロダクト「LegalOn」が「Professional AI for Legal」というコンセプトのもとチャットインターフェースを備えており、その裏側に案件管理や契約書レビュー、電子署名といった業務を担う「LegalOn Ambient Agent」を配置する構成の開発が進んでいます。
日本経済新聞社の「NIKKEI KAI」は、情報収集から分析、アウトプットまでの業務プロセスを効率化するプロダクトです。新聞記事や経済情報、日経テレコンに蓄積された情報をもとに回答を作るため、一般的な AI と比べてハルシネーションのリスクを低く抑えられることが特徴です。
お二人の立ち位置が対照的だったことも、このセッションを面白くしてくれました。石垣様は SRE として Datadog の導入を進め、開発者と協力しながら LLM を使った技術をどう監視するかを考える立場。若原様は SRE と議論しながらプロダクト開発を主導する立場です。同じテーマを開発側と運用側の両方から聞けたことになります。
本ブログでは、Fireside Chat でお話した内容の一部を振り返りながら、概要をお届けします！
Agent Observability とは何か
セッションの導入として、モデレーターの木村から Agent Observability の位置づけを整理しました。
オブザーバビリティのアプローチは、さまざまなレイヤーの情報を収集し、いまシステムで何が起こっているのかを可視化することにあります。マネージドクラウドの監視情報、その上のサーバーやアプリケーションの情報と積み上げてきたところに、さらに乗ってきたのが AI エージェントや LLM を使った処理です。この AI エージェント層には別のアプローチが必要になるという背景から生まれたのが Agent Observability です。
具体的には、どういった LLM の呼び出しが行われているのか、MCP のツールを使ってどこから情報を取ってきているのか、RAG が情報ソースから正しくデータを引いて回答を組み立てているのか。外からは見えない AI エージェントの動きの中身を追えるようにするのが役割のひとつです。あわせてコストやセキュリティの情報を扱えるほか、実際にプロンプトを送って何が返るかを試したり、出てきたアウトプットを AI に評価させたりもできます。
Agent Observability 入門のきっかけ
最初のテーマは、すでに Datadog をお使いいただいているお二人が、なぜ Agent Observability を別途必要だと考えたのかです。
日経の若原様の答えは明快でした。アプリケーションのレイヤーは APM で十分に監視できていた。足りなかったのはその1つ上、開発者目線で言えば LangChain や LangGraph といったフレームワークの中身です。自社で用意しているプロンプトがどう動作しているのか、そしてグラフ構造がどう展開されているのか。Agent Observability を入れるとグラフがきれいに展開され、一目で分かる状態になったとのことでした。
導入の障壁について伺うと、技術面ではなく手続き面だったという回答が返ってきました。プロンプトが見えてしまうことを懸念されるお客様が多く、契約面の確認に苦労された一方、技術的には「アプリケーション設定に1行足すだけ」で送信が始まる。むしろ全部送れてしまうことがやりすぎに感じられる部分もあったといいます。APM と同じ SDK のまま機能を有効化するだけで始められる点が、導入のハードルを下げていました。
LegalOn Technologies の石垣様は、そこに至る前史をお持ちでした。同社は早い段階から LLM に注目しており、2年ほど前には LLM の挙動を監視する仕組みを自前で構築し、プロンプトやスパンを自社の GKE クラスターに送っていたそうです。ところが運用負荷とインフラ費用の両方が重く、純粋なコストと運用コストの双方で嵩んでいた。そこに Datadog の Agent Observability が登場し、PoC を経てすぐに採用を決められました。導入が簡単で、自分たちで運用しなくてよく、必要なプロンプトも見られる。自前構築の痛みを知っている立場からの評価だけに、説得力のある話でした。
OpenTelemetry で APM のトレースを取得している同社が、Agent Observability では dd-trace を選んだ理由も伺いました。当時は LLM のトレースの取り方がまだ標準化されておらず、通常の APM 側で OpenTelemetry に対応できているのだから、この部分は Datadog の実装に寄せてよいという判断だったそうです。
もうひとつ、マルチプロダクト構成の企業ならではの使い方も紹介いただきました。LegalOn Technologies では事業部ごとに開発体制が分かれており、テレメトリーの閲覧範囲を分けたいという要件があります。Data Access Control が Agent Observability にも対応していたため、事業部ごとの閲覧制限をそのまま適用できたとのことでした。
現場の試行錯誤
2つ目のテーマは、導入してからの工夫や試行錯誤です。
石垣様に伺ったのは、契約書という極めてセンシティブなデータを扱う難しさでした。お客様によっては、そうしたデータを外に流してほしくないという要望があります。そこで AI チームが dd-trace のラッパーライブラリを作り、リクエストに含まれるテナント ID を見て、Agent Observability にデータを送るか送らないかを判断する機構を実装されたそうです。すべてのプロンプトを送って分析すればよいわけではない、という現実に対する具体的な答えでした。
若原様からは、コスト情報の取得について共有いただきました。文字を連続して返す SSE 形式では、当時コストの計測が素直に取れなかったため、その部分は自前でラップして作る必要があったといいます。苦労というよりも、機能として寄せてもらえるとありがたい部分だという整理でした。
ハルシネーションへの向き合い方も、NIKKEI KAI のようなプロダクトでは信頼に直結します。人が目で見て確認するには無理があるため、LLM が出した回答をさらに LLM に評価させる基盤を自社で構築されているそうです。「あなたは経済のアナリストなので、これを評価して」といった形でスコアを付け、これくらいの水準であれば性能が劣化していないと判断する。この考え方は Datadog の Agent Observability にも LLM-as-a-Judge として実装されており、ハルシネーションの検出だけでなく、意図したデータソースへアクセスできているか、日本語で聞いたのに英語で返っていないか、ユーザーが内部情報を引き出そうとしていないかといった評価も可能です。
LegalOn Technologies では、Prompt Playground が予想外の場面で活躍していました。BtoB プロダクトゆえにお客様からの問い合わせ調査が発生しますが、AI 関連の機能に関する問い合わせであれば、実際に打ち込まれたプロンプトをそのまま試して反応をクイックに確かめられる。AI エージェントの非決定論的な振る舞いを追う場面で重宝しているとのことでした。同じ入力でも違う答えが返り、モデルを変えれば挙動も変わる領域だからこその使い方です。
AI エージェントの信頼性
最後のテーマは、AI エージェントの信頼性をどう捉えるかです。100%正しい答えを出すことは難しいなかで、何を指標に置くのか。
若原様が挙げられたのは、ハルシネーションに加えてツールの選択率でした。NIKKEI KAI では、ユーザーが記事を求めていると判断すれば記事系のツール、経済情報を求めていれば経済系のツールと、LLM が自律的に選ぶ構成になっています。想定とずれたツールを選んでいないかを重点的に見るという指標の置き方です。
そうした取り組みができる体制が AI 開発の初期から整っていたことが強みだったともお話しいただきました。意味論的検索のために記事をベクトル化して持つ Elasticsearch の巨大な基盤がすでにあり、それが LLM と非常に相性が良かった。構造化された AI レディーなデータを整備してきたこと自体が会社の強みという言葉が印象に残りました。
石垣様には、法務という難しいドメインでの信頼性について伺いました。同社の前身プロダクトである LegalForce で AI レビューを提供していた当時、弁護士以外が法律相談に応じることを禁じる弁護士法第72条の非弁行為に抵触しないか、という議論があったといいます。エージェントの機能を拡張していくにあたり、そうした領域に抵触する回答を返していないかを LLM-as-a-Judge でチェックする仕組みが必要になるというお話でした。守らなければならない線が明確にあるからこそ、出力の評価に重きを置くという整理です。
レイテンシと精度のトレードオフについては、お二人に同じ質問を投げました。若原様は、情報の密度や量を高めて正確な回答を出そうとすればするほど時間がかかるという構造を踏まえ、AI が自律的に判断するためのターン数に上限を設け、最初は決め打ちで入れたうえでユーザーの要望に応じて調整していると答えられました。石垣様の答えはより踏み込んだものでした。レスポンスの遅さは通常の API に比べればある程度許容されるものの、待たされた挙げ句に失敗しましたと返ってくればストレスは通常より大きい。だからこそエージェントの SLO をどう設定すべきかが喫緊の課題だと語られました。
コストについても両社の実践を伺いました。石垣様からは、LLM への投資を ROI として捉える必要があり、トークン数を Agent Observability で追ってコストをコントロールしていきたいという方針を。加えて、複数の LLM を使っているため、障害時に別のモデルへ切り替える動きも監視して対処できるようにしたいという展望も挙げていただきました。若原様は、1質問あたりにかかる金額を出して平均値と中央値を追い、大きく悪化していないかを継続的に計測されています。新しいモデルを試すと明らかに跳ねる部分があるため、高すぎれば本番利用をためらうという判断基準でした。
なお、この判断を助ける機能として Agent Observability には Experiments 機能があります。モデルを変えたときに回答の品質が変わらないか、コストがどれだけ下がるかを試しながら比較できるため、本番投入の前段で使っていただける機能です。
最後に
クロージングでは、お二人から今後の展望をいただきました。
石垣様からは、LLM を使ったエージェンティックな機能をどうユーザー体験と紐付けて監視していくかに注力して考えていきたい、そのために Agent Observability で取れるテレメトリーを駆使して何ができるかを探りたいとのお話がありました。まだ正解がない領域への取り組みです。
若原様が描かれていたのは、フィードバックの循環でした。LLM-as-a-Judge を取り入れつつ、ユーザーが増えればフィードバックも増えていく。それをコーディングエージェントで直接チケット化し、開発して修正するループを回せる体制ができれば、フィードバックが重荷ではなくプロダクトのプラスとして働く。その土台として Datadog を使っていきたいという展望で締めていただきました。
AI エージェントの信頼性をどう定義し、どこで測るのか。この問いにはまだ確立した答えがありません。だからこそ、実際にプロダクトを届けている現場が何を指標に置き、どこで悩んでいるのかを聞けたことに価値があったと思います。センシティブなデータの扱い、レイテンシと精度の均衡、トークンコストの管理。いずれも避けて通れない論点でした。
改めまして、ご登壇を快諾いただき、開発中の取り組みまで率直に共有してくださった石垣様、若原様、本当にありがとうございました。
過去の Datadog Live の振り返りは、『Looking Back at Datadog Live Tokyo 2025「現場で活きる！Datadog によるオブザーバビリティ実践のリアル」パネルディスカッション開催レポート』でもご紹介しています。是非あわせてご覧ください。
DATADOG LIVE は今後も各地で開催予定です。9月16日には DATADOG LIVE OSAKA、10月15日には AI にフォーカスした DATADOG LIVE TOKYO – AI Powers the Future – を開催します。 お客様の先進的な取り組みや、Datadog の最新ビジョン・製品アップデートとともに、オブザーバビリティや AI がもたらす変革の可能性をご紹介します。ぜひご参加いただき、最新の知見や、皆さまの次のアクションにつながる具体的なヒントをお持ち帰りください。
