【AIエージェントのオブザーバビリティ】エージェント監視 開発者ガイド
Article by: Sergiy Dybskiy 「エージェントのオブザーバビリティのベストプラクティス」を謳うコンテンツのほとんどは、2019年のコンプライアンスチェックリストの「マイクロサービス」という部分を「AI」と貼り替えただけのようなものです。「包括的なロギングを実装する」「評価メトリクスを確立する」「ガバナンスフレームワークを構築する」など、コードは一行も出てこず、エージェントが3ターン目にこっそり間違ったツールを選んでしまったとき、なぜそうなったかを突き止める方法にも一切触れていません。 エージェント監視に必要なものは2つです。すべてのエージェントで何が起きているかを示すダッシュボードと、特定の実行でなぜ問題が起きたかを正確に示すトレース。ほとんどのツールはどちらか一方しか提供しません。両方を持っている場合どうなるか、見ていきましょう。 エージェントのオブザーバビリティとは何か エージェントのオブザーバビリティとは、AIエージェントの動作をエンドツーエンドで可視化することです。どのモデルを呼び出しているか、どのツールを実行しているか、各ステップでどんな意思決定をしているか、そしてその決定が最終的な出力にどう影響しているかを把握できます。 従来のアプリケーション監視はリクエスト、エラー、レイテンシを追跡します。各リクエストが独立したステートレスなHTTPサービスではそれで十分です。 しかしAIエージェントは異なります。単一のエージェント実行には、複数のLLM呼び出し、ツールの実行、サブエージェントへのハンドオフ、マルチターンの推論ループが含まれることがあり、これらすべてが互いに依存し合っています。出力が誤っていた場合、その連鎖のどこかに失敗が潜んでいる可能性があります。ツールからの不正なレスポンス、コンテキストウィンドウのオーバーフロー、モデルによる間違った関数の選択、ハンドオフでのステート消失など、原因はさまざまです。 従来の監視がAIエージェントで機能しない理由 標準的なAPMツールは「POST /api/chat が4.2秒で200を返した」とは教えてくれます。しかし、そのリクエストの中でエージェントが5回LLMを呼び出し、3回目に間違ったツールを選択し、そのツールが古いデータを返し、モデルがそのゴミを律儀に要約したというようなことは教えてくれません。 「とにかく全部ログに残して後で考える」という監視方針であれば、カウントと平均値で埋まったダッシュボードができ上がるだけで、深く掘り下げる手段はありません。間違った答えを返したエージェントは、12回LLMを呼び出し、4つのツールを実行し、サブエージェントにハンドオフしてからゴミを生成していたかもしれません。集計メトリクスはエラーレートが上がったことは教えてくれても、推論のどこでおかしくなったかは教えてくれないのです。 必要なのは、標準的な規約に基づいて設計された構造化トレースです。ダッシュボード、トレース、アラートがすべて同じ言語で話せるようになります。 エージェントオブザーバビリティのOpenTelemetry標準 OpenTelemetryの gen_ai セマンティック規約は、AIエージェントシステムのインストゥルメンテーション標準を定義しています。カスタムロギングの代わりに、すべてのAI操作が一貫した属性セットを持つ構造化スパンを生成します。規約で定義されたコアオペレーションは以下の通りです。 スパンオペレーション 何をキャプチャするか gen_ai.request 単一のLLM呼び出し：モデル、プロンプト、レスポンス、トークン数 gen_ai.invoke_agent エージェント実行のフルライフサイクル：タスクから最終出力まで gen_ai.execute_tool ツール/関数呼び出し：名前、入力、出力、実行時間 これらはスパンツリーとして構成されます。 これはプロプライエタリな仕様ではなく、オープン標準です。この規約に従うオブザーバビリティプラットフォームであれば、どれでもこれらのスパンを取り込むことができます。スパンのopは gen_ai.{operation_name} というパターンに従います。手動インストルメンテーションの場合、gen_ai.request がすべてのLLM呼び出しをカバーします。SDKによる自動インストルメンテーションでは、呼び出されるAPIに応じて gen_ai.chat や gen_ai.embeddings といったより具体的なopが生成されることもあります。これらは非構造化ログではなく構造化スパンであるため、ダッシュボードとトレースビューの両方を活用できます。 AIエージェント監視の主要メトリクス ツールの話に入る前に、本番環境のAIエージェントで追跡すべき指標を整理しておきましょう。 信頼性メトリクス エージェントエラー率 — 失敗またはエラーを返したエージェント実行の割合 ツール失敗率 […]
【Duolingo】アラート疲れを減らしてデバッグを12倍高速化
Duolingo は世界をリードする語学学習アプリであり、毎月何百万人もの学習者に、魅力的なレッスン体験を提供しています。ミッションはシンプルです。世界最高の教育をつくり、誰もが利用できるようにすること。 舞台裏では 200以上のマイクロサービスと、1日に複数回のデプロイを伴う高速なリリースサイクルがこれらの体験を支えています。これほど複雑なシステムを運用する以上、Duolingo は見逃されたバグや遅い問題解決がプラットフォームや「学習者第一」のミッションを損なわないようにする必要がありました。 暫定対応、分断されたデバッグ、生産性のボトルネック Sentry 導入前、Duolingo は同社のスケールに対応できるよう設計されていない従来型のエラー監視ツールに依存していました。その結果、煩雑なデバッグワークフローとUIがエンジニアの不満を招き、生産性を制限していました。 遅いデバッグ： 情報の検索は1回のクエリでも最大30分かかることがありました。さらに同時にクエリできるのは1人のエンジニアだけで、チーム全体に強いボトルネックが生まれていました。 ノイズ過多： 有効なフィルタリングやグルーピングがなく、無関係なデータが大量に流れ込み、重要な問題に集中することが難しくなっていました。 検索機能の制約： 短期的なスパイクのような細かなエラートレンドは、特定がほぼ不可能でした。エンジニアは手作業に頼ったり、勘に頼って原因を探したりすることがよくありました。 使いにくさと属人化： UIが扱いづらく、利用は経験豊富な少数のエンジニアに限られていました。その結果、「パワーユーザー」への依存が生まれ、他のメンバーは貢献に必要なツールやコンテキストを得られない状態でした。 コンテキストと可視性の不足： 取得できるメタデータが最小限で、エラーと根本原因の相関も弱かったため、開発者は複数の情報源からコンテキストを寄せ集める必要がありました。こうしたコンテキストの切り替えが解決までの時間を延ばし、生産性を下げていました。 さらに悪いことに、この従来ツールでは課題をすべて解決できず、ワークフローに重要な穴が残っていました。チームは暫定対応を素早く出せてはいましたが、それは場当たり的な対症療法になりがちで、根本原因は未解決のまま残り、同じ問題が後から何度も再発することがありました。 「単純なデバッグですらマラソンのように感じました。ツールが分かりにくく、デバッグできるのはパワーユーザーだけで、他の人は簡単に理解できなかったのです。全員にとってデバッグを効率化するためのツールがありませんでした。」と、Duolingo の Staff Site Reliability Engineer である David Amin 氏は言います。「単に時間を無駄にしていたという話ではありません。すべてのエンジニアが、素早く問題を解決できるという自信と能力を持つためのツールがなかったのです。」 システムとチームの複雑さが増すにつれ、Duolingo は、よりスケーラブルで開発者にやさしいエラー監視とデバッグのアプローチを求めるようになりました。 Duolingo が Sentry を選んだ理由：実装の簡単さ＆インサイトまでの時間の短縮 選択肢を評価した結果、Duolingo は最小限のセットアップで最大の課題に対処できることから Sentry を選びました。分かりやすい導入と開発者中心の設計により、チームは採用しやすく、すぐに効果を得られました。 200以上のマイクロサービスを2週間未満で移行： Sentry のAPI、Terraform 対応、分かりやすい設定により、200以上のマイクロサービスをわずか2週間で移行できました。 解決までの時間を12倍高速化： リアルタイムクエリ、直感的なダッシュボード、深いコンテキストにより、エンジニアはノイズを素早く絞り込み、トレンドを可視化し、問題箇所を特定できました。すべてを1つのツール内で完結できます。以前は原因の特定がほぼ不可能で、何時間、場合によっては何日もかかっていました。いまは数分の話です。 ノイズ削減： 組み込みのグルーピング、フィルタリング、Spike Protection、オーナーシップルールにより、ノイズを取り除き、重要な問題だけを検知して適切なチームへルーティングします。これによりアラート疲れが軽減され、重要なエラーに集中できます。さらに明確さを得たことで […]
【Anthropic】600人以上のエンジニア＆1つのツール。Anthropic の Sentry ストーリー
世界でも Anthropic が日々取り組んでいる課題ほど技術的に複雑な挑戦に取り組むチームはそう多くありません。 AIとAI安全性研究の最前線で働くAnthropic の日々の業務には、想像を絶する規模のデータセット、大規模な分散ジョブ、そして高度に専門化されたハードウェアが関わっています。同社のエンジニアは GPU メモリの制約から最下層レベルでの計算最適化まで、あらゆる課題に取り組みながら、ほんの少し前までは考えられなかった種類のコードを継続的にリリースしています。 システムの複雑さが増すにつれて、問題が発生した際の修正も一層複雑になります。 Anthropic の既存のインフラストラクチャーモニタリングツールが追いつかない状況になったとき、彼らはSentryを導入して、より迅速に問題を見つけて修正することにしました。バグやクラッシュを早く取り除くことができれば、本当に重要な研究に注力する時間が増えます。 「Sentry は Sonnet の開発を進める上で重要な役割を果たしました。」と、Anthropic のシステムリードを務める Nova DasSarma が、同社の最も先進的なAIモデルの1つに言及しながら語っています。 課題：圧倒的なログ量 AI研究では、時間は単なるコストではなく「前進」そのものです。業界の最前線で取り組むなら、バグの特定と修正に何日もかけている余裕はありません。 「1つのノード障害が、数百、あるいは数千台のサーバーに影響することがあります… Sentry 導入前は（多くはハードウェア故障が原因で）クラッシュループに陥ることがよくありましたが、不良ハードウェアを排除するためのノードレベルのテレメトリがありませんでした。」ー Nova（システムリード） インフラが拡大するに伴い、問題も増加しました。 既存のモニタリングツールが処理しきれない圧倒的なログ量 ノードレベルのハードウェア問題の可視性がない 分散システム間でエラーを関連付けるのが難しい エラーが発生したときに最初に誰が知るべきか、エラーの所有権を追跡する能力が限られている トレーニングしていたモデルが大規模化するにつれて、これらの問題は深刻化しました。数千の GPU が同時に稼働する中で、デバッグに費やす1分1秒がリソースの浪費と研究の停滞につながります。 「私たちは、デバッグに数日かかる障害にぶつかっていました。何千台ものサーバーが関わる中で、それをSentryで“数時間”に短縮できたことは、大規模トレーニングジョブを効率よく回し続けるうえで決定的でした」ー Nova（システムリード） 小規模なジョブでは問題なかった既存のセットアップは、この規模には適していませんでした。 「以前のツールは厳しいスロットル制限があり、生成されるログの量が多すぎて処理しきれませんでした。」ー Nova（システムリード） 彼らが求めていたのは、このスケールに対応でき、失敗を手作業でつなぎ合わせなくてもよいリアルタイムのデバッグソリューションでした。 解決策：スケールした状態での即時可視化 Anthropic の機械学習インフラは、小さな障害がすぐに大きな混乱へと発展する規模で動いています。Claude 1 のトレーニング時点でも、既存のインフラ監視は追いつけなくなっていました。 「これは、それまでで最大のジョブでした。以前はほとんどのジョブが数ノードで完結していました。でも大規模モデルを学習させると、1つのノード障害が数千台のサーバーに影響します。」ー Nova（システムリード） 以前の会社で Sentry を使ったことのあるメンバーもいました。そのため、GPU クラスターで連鎖的障害が起き、デバッグがほぼ不可能になったとき、Sentry […]
【GRIN】Sentryで3ツールを1つに。デバッグを20倍高速化
Grin は、ブランドがクリエイターと本物の関係を築けるよう支援する、急成長中のインフルエンサーマーケティングプラットフォームです。事業が拡大するにつれて、エンジニアリングチームはある課題に直面しました。オブザーバビリティのスタックが分断され、摩擦が生まれ、開発スピードが落ちていたのです。 ツールが多すぎて、シグナルが足りない Sentry 導入前、Grin はスタック全体をカバーするために、3つのオブザーバビリティツールを組み合わせて使っていました。この構成でパフォーマンスとエラーの監視はできていましたが、明確さよりも混乱が増える状態になっていました。 「当時はインフラ用ツール、APM ツール、それからクラッシュレポート用ツールがありました」と、Grin の シニアエンジニアリングマネージャーの Jorge は話します。「使い方によっては重複するツールが3つあるようなものです。集約したかったですし、ツールの力を最大限に引き出して使いたかったんです。」 既存のエラートラッキングツールはノイズが多く、パフォーマンス問題はさらに厄介でした。 「フラストレーションが溜まりました。たとえば、遅いデータベースクエリがエンドユーザー体験にどう影響しているか。のような基本的なパフォーマンスの疑問に答えるだけでも、ログ、メトリクス、トレースを手作業でつなぎ合わせる必要がありました。」 5分で元が取れた理由 Sentry を置き換え候補として、社内でデモをしていた Grin のメンバーが数名いました。そのデモの最中に偶然が起きます。デモ用に擬似エラーを仕込んでいたわけではなく、実際のバグが現れ、それをその場で追跡して解決できたのです。 Sentry により、特にそのページを頻繁に使うユーザーの読み込みが異常に遅いことが分かりました。パワーユーザーでは読み込みに 50 秒以上かかり、場合によってはまったく表示されないこともありました。 Session Replay と Tracing を組み合わせることで、チームは実際のユーザーセッションを確認し、どの瞬間に、どこで遅くなっているのかを正確に特定できました。しかも5分以内に問題が見つかったのです。 「ページをリロードして、リプレイを見て、リクエストを見て、それからトレースを確認するだけでした。」と Jorge は振り返ります。「たった5分で問題が何かが分かりました。」 修正はシンプルでした。ページの一部を非同期で読み込むようにしたことで、読み込み時間は 50秒から10秒未満 に短縮されました。80% の改善です。 「Sentry に Session Replay と Tracing があることを知りませんでした。」と Jorge は認めます。「会話はすぐに、切り替えるべきか。から、どれだけ速く進められるか。へ変わりました。」 Jorge の見積もりでは本来なら丸1週間のデバッグが必要だったものが、1回のミーティングで解決しました。 「Sentry のデモをしただけで元が取れました。」 オーバーヘッドのないオブザーバビリティ：Grin が Sentry を選んだ理由 […]
【Flo】毎日50回デプロイしても品質が落ちない理由
要約世界をリードする女性向けヘルスケアアプリを手がける Flo Health は、Sentry を活用して「素早くリリースし、さらに素早く修正」しています。モバイルとバックエンドを横断するフルスタックの可視化により、Flo は問題が本番に到達する前に検知し、パフォーマンスをリアルタイムで追跡し、世界中の数百万人のユーザーのエンゲージメントを維持しています。しかも、1日50回以上のデプロイというペースを落とすことなく実現しています。 結果 主要トランザクションの重要リクエストにおける処理速度を 50% 向上 数百万人のユーザー規模で 99.9%+ のクラッシュフリー率を維持 自信を持ったモバイルロールアウトと迅速なロールバック戦略を可能に 品質や可視性を犠牲にせず、バックエンドを 約50回/日 デプロイする運用を支援 「アプリが遅ければ、ユーザーは待ってくれません。すぐに離脱します。Sentry を使ってパフォーマンスをデバッグし、監視することは、ユーザーをアプリ内に留め、利用を継続してもらううえで、私たちの成功を支える重要な要因です。」ー Vaidas Zlotkus（エンジニアリング・ディレクター） バックエンドのデプロイからエッジのレイテンシまで：1億人超のユーザーに対する「応答性」をデバッグする Flo は世界で最も広く利用されている女性向けヘルスケアアプリで、AI によるインサイトと医療専門家によるレビュー済みコンテンツを複数言語で提供しています。インフラはバックエンド主導の UI を支え、数万本に及ぶコンテンツ記事を提供し、バックエンド更新を高頻度で配信しています。 その回数は 1日最大50回 にもなります。この規模でアプリの速度と安定性を確保することは、単なる技術目標ではなく、事業上の必須要件です。 世界中にユーザーがいる Flo は、地域やデバイスを問わず、応答性・データ保護・信頼性に関して高い基準を満たす必要があります。そのためには問題を検知し、強固なプライバシー保護とデータ最小化の保護策を適用し、チームがそれに対して迅速に行動できるようにする、堅牢なオブザーバビリティツールが求められます。 Sentry はそのためのフルスタック可視性を提供します。 Flo が Sentry を使って高速で安定したアプリを提供する方法 1. プロアクティブなリリース監視とクラッシュ管理 Flo のエンジニアはモバイルのロールアウトにおける「最初の防衛線」として Sentry を活用しています。段階的デプロイとバージョンごとに異なるユーザーの採用率がある中で、リグレッションを早期に検知すること、つまり深刻化する前に止めることが重要です。 「モバイルで 5% ロールアウトを行うとき、Sentry を確認するのはリリースチェックリストの一部です。この方法で重大な問題を捕捉し、ユーザーベースに影響する前に悪いリリースを止められました。」— […]
【Seer】Honra がSeer AI Code Review でレビュー時間を75%削減した方法
5人の開発チームが冗長なレビューをやめ、的確で即時のフィードバックに置き換えることで、より速くバグの少ないリリースを実現 Honra はプエルトリコに拠点を置くスリムな B2B ソフトウェアコンサルティング企業で、クライアントのカスタムプロダクトやインフラ構築を支援しています。 TypeScript・Python・Go を扱う 5人のチームで構成されており、エンジニア一人ひとりが平均以上のインパクトを出すことが求められ、1分1秒が重要になります。この少人数チームが顧客により大きな価値を届けられるようにするため、社長の Marc Maceira Zayas 氏は、高い品質基準を維持したままコードをより速く出荷できる方法を必要としていました。 本記事では、Seer がどのようにして、わずか 1週間で 15,000ドル分のエンジニアリング工数をチームに節約したのかをご紹介します。 課題：レビューが遅く、フローが途切れてしまう Seer を使う前の Honra のコードレビューは、遅くて手作業中心のプロセスでした。Marc さんのチームは、手動テストと PR を一行ずつ読み込むレビューを組み合わせて運用しており、しばらくのあいだはうまく機能していたものの、やがて限界が見えてきました。 「たいていの場合、問題は細部に潜んでいます」と Marc さんは話します。「本来であればもっと早い段階で拾うべき小さなバグを見落としてしまうことがありました。そして、メンバー全員がリリースの責任を負っているので、レビューが長引くということは、新しいコードが出荷されないということなんです。」 そこでまず別の AI コードレビューツールを導入し、レビューの自動化に取り組みました。当初は確かに役立っていましたが、次第に足かせになっていきました。AI が生成するフィードバックは PR 1件あたり 20〜50 分もかかり、本来であれば 3行のコメントで済む内容が、2パラグラフにもわたる長い講釈として返ってくることも少なくありませんでした。 本当に重要な問題を浮き彫りにする代わりに、そのツールは実装の細部について主観的な解説を長々と始めてしまう傾向があり、その結果として生じていたのは、コンテキスト過多による疲労感と混乱です。 「本当は自分の解決策が正しいのに、間違っているのではないかと不安にさせられることもありました。冗長になりすぎて、遅すぎて、ツールとしての役割から外れてしまっていたんです。」 解決策：即時で、すぐ行動につなげられるフィードバック Honra が Seer の AI Code Review を試し始めたとき、その違いにすぐに気づきました。 「最初に動かしたときは、思わず笑ってしまいました」と Marc 氏は話します。「PR […]