LLMエージェントを"見える化"する ― OpenTelemetryからPydantic AI × Logfire へ
LLMエージェントは確率的なブラックボックスです。
動いて見えても、リトライが裏で何回起きているか、どのツール呼び出しでコストが膨らむか、失敗がなぜ再現しないかなど、実際に使用してみたり、運用してみたりすると途端に見えなくなりがちです。
本トークが示すのは「型で守り、トレースで見る」という考え方です。LLM出力を境界で信用しない型安全（事前の防御）と、実行時に何が起きたかを明らかにする可観測性（事後の観測）は、ブラックボックスを信頼できるものにする両輪だと考え、その仕組みを示します。
具体的には、自作のマルチエージェント・オーケストレーターを運用してこの壁にぶつかった経験をもとに、OpenTelemetryを背骨に据えた計測の作り方を紹介します。
内部ではPydantic AIを使い、出力を型として定義し、その制約違反を自動でリトライします。この「型制約→失敗→再生成」のループをトレースし、LLM利用で増加しがちなコストを意識すれば、安価なモデルにも構造化出力を任せられるようになります。
LLMエージェントでは、スキーマ準拠は安定しても意味的な制約は外しやすく、その分リトライが増え、リトライはそのままトークン課金に跳ね返ります。「安いモデル＋検証リトライ」が本当に得かはリトライ率次第で、それはトレースを見て初めて判断できます。
型・トレース・コストを一つの意思決定として捉え、自前ログか、OpenTelemetryか、外部プラットフォームか、といった整理を、Pydanticチームが提供するLogfireと合わせて運用者目線でお話しします。
本トークでは、「計測しておけば、モデルもツールも、勘ではなく実測したリトライ率やコストで選べるようになる」という考え方を持ち帰ってもらうことをゴールとしています。
Tell us about your own experience with this topic
日々の業務で10年以上、Pythonによるアプリケーションの設計・運用に携わっています。最近は、プロジェクトで利用する設計文書を生成するLLMエージェント（マルチエージェント・オーケストレーター）の開発に取り組み、〔個人/業務〕で実際に運用してきました。本トークの中心となるのは、この運用経験です。複数フェーズ・複数エージェントのパイプラインを動かす中で、エージェント内部が見えない問題に直面し、状態やエージェント境界を型で固めつつ、OpenTelemetryによる可観測性を導入してきました。
また、技術評論社「Python Monthly Topics」にPydantic AIの記事を寄稿し（https://gihyo.jp/article/2026/02/monthly-python-2602）、型安全なLLM活用を検証してきました。昨年のPyCon JPではワークフローフレームワークをテーマに登壇しています。
What discussions can you have with attendees through this talk?
このトークには、人によって判断が分かれる論点がいくつかあります。
そうした選択について、参加者の実体験を聞いてみたいです。
ひとつは、可観測性の基盤選びです。LLMエージェントの観測に、自前のログで足りているのか、OpenTelemetryで標準化しているのか、それともLogfireやLangfuse、自前のJaeger/Grafanaといったプラットフォームを使っているのか。選定の決め手や、運用してみての後悔を聞いてみたいです。
もうひとつは、モデルとコストのバランスです。「安いモデル＋型でのバリデーションとリトライ」と「最初から賢いモデル」を、どんな基準で使い分けているか。リトライ率やコストを実際に計測している方がいれば、その数字感を交換できると嬉しいです。
加えて、「型でLLM出力を守る」というアプローチに、どこまで実務的な手応えを感じているか――モデルが賢くなった今も型は要るのか、という点も議論してみたいです。
バクフー株式会社というところでCTOをやっています。Pythonを使用したバックエンドサービスやWeb関係の業務に携わっています。山形県を生活の拠点として開発業務を行いながら、Python Boot CampやPyCon JP への参加（登壇3回 2015, 2017, 2025）するなどの活動を行っています。