AIシステムを本番で監視するために本当に必要なこと
Article by: Rahul Chhabria 最新の AI エージェントをプロダクトに組み込み、リリースして、あとは寝るだけ。ところが起きてみると、空文字を返していたり、昨日より 5 秒も遅くなっていたり、あるいは「完璧な JSON」の体裁で堂々と嘘を出していたりしています。 当然、ログを確認します。 プロンプトはある。レスポンスもある。……でも、肝心の手がかりが何もない。 驚きますよね。プロンプト入力とレスポンス出力だけでは、オブザーバビリティとは言えません。あれは雰囲気です。 「LLM のオブザーバビリティ」は今かなり話題です。ただ、実態は「要らないチャート」と「そのうち見なくなるダッシュボード」が増えるだけ、というケースも少なくありません。もしあなたが実際に、チャットボットや社内エージェント、検索・取得アプリなど、LLM を組み込んだプロダクトを作って運用しているなら必要なのは観測です。しかも、肝心なところに差し掛かった瞬間に途切れるような観測ではなく、原因まで辿れる観測です。 何を追うべきか。いつ追うべきか。なぜそれが重要なのか。中身のない補完にうっかり 5,000 ドル払う前に、順番に整理していきましょう。 ステージ 1：本番前 （別名：「プロンプト墓場」） 今、プロトタイプを作っている段階だとします。ノートブック、ベクターストア、OpenAI API キー、そして夢もある。必要なのはダッシュボードではなく、壊れたプロンプトを必死に救い出すためのログです。 何をログに残すべきか この段階でデバッグしているのは、ユーザーというより自分自身です。なので、以下をログに残しましょう。 プロンプト全文とレスポンス全文 モデル名、temperature、function schema のバージョン トークン使用量とレイテンシ プロンプトのバージョンを特定できる情報（何でもいいので） プロンプトのバージョン管理に気の利いた仕組みは要りません。コミットハッシュで十分です。付箋でもいい。とにかく、何が変わったのか忘れる前に書き留めておきましょう。 当面はこれで済むツール類 JSON ファイル Postgres のテーブル 構造化ログを使った Sentry Traceloop（そういうのが好きなら） ここでの唯一の目的は「変な挙動」を再現できるようにすることです。何かが爆発しても、5 分以内に説明できるなら勝ちです。 ステージ 2：本番（Production） （いまや「誰か別の人」の問題） […]
堅牢な時系列モニタリング Matrix Profile と Prophet を用いた異常検知
Article by: Ram Senthamarai, Aayush Seth 異常検知は鏡だらけの家で探偵をしているようなものです。何かがおかしいのは分かるけれど、見えているのが本当の問題なのか、それとも奇妙な反射にすぎないのか、いつも確信が持てません。 本番環境のシステムを監視するのは、絶えず形を変える干し草の山の中から動き回る針を探すように感じることがよくあります。Sentry では、お客様が従来のしきい値ベースや割合ベースのアラートを超えられるようにすることを目標にし、システム内の微妙で複雑な異常をほぼリアルタイムで検知できるよう支援することを目指しました。 本記事では、当社の AI/ML チームが Matrix Profile と Meta の Prophet を用いて、時系列の異常検知システムを開発した方法を詳しく説明します。直面した課題を取り上げ、このハイブリッドなアプローチによって、より信頼性が高く、よりインテリジェントなアラートを構築できた理由を解説します。 問題：ノイズの多いメトリクス、微妙な障害 システムメトリクスは本質的にノイズが多いものです。しかし、適切なタイミングで適切な異常を特定できるかどうかで、結果は大きく変わります。たとえば、素早い修正で済むのか、重大インシデントに発展するのか。とはいえ、自動の時系列異常検知（Time Series Anomaly Detection。以下 TSAD）は簡単な問題ではありません。 コンテクストがすべて：データのスパイクは異常かもしれませんし、週末セール、プロダクトローンチ、システムメンテナンスの影響にすぎない場合もあります。コンテクストがなければ、その違いは判別しにくくなります。 「正常」は常に変動する：パターンは時間とともに変化します。季節性、トレンド、そして突然のレジームシフト（状態の急変）によって、今日の「正常」が明日の「異常」になり得ます。 ノイズとシグナルのせめぎ合い：システムメトリクスのデータはノイズが多くなることがあります。特に大規模環境では、誤検知を連発せずに真の異常だけを検知するのは簡単ではありません。 万能解はない：各メトリクスの振る舞いは異なります。CPU 使用率、ユーザー登録数、取引量など、それぞれ特性が異なるため、状況に応じたアプローチが必要です。 ラベル付きデータがない：教師あり学習は、正解（グラウンドトゥルース）がない場合、難しくなります。多くの場合、何が異常だったのかは、実際に何かが壊れてから初めて分かります。 Sentry のスケール：何十万ものメトリクスを監視する Sentry のようなオブザーバビリティプラットフォームの規模で、この問題を解くことを想像してみてください。 要するに、自動 TSAD には、コンテクストを理解し、適応的で、精度が高く、しかもスケールすることが同時に求められます。 解決策：ハイブリッドアプローチ ARIMA、SARIMA、TimeGPT、Moirai、AutoFormer、ChatTS などさまざまなモデルで広範に実験した結果、私たちは Matrix Profile と Prophet を組み合わせたハイブリッド手法に落ち着きました。これらのモデルを組み合わせることで、時系列データにおける異常をより広い視野と、よりニュアンスのある形で理解できるようになります。 Matrix Profile：形状ベースの異常検知 […]
【Cocoa SDK 9.0.0】リリース！
Article by: Philipp Hofmann Cocoa SDK 9.0.0 をリリースしました。新機能と変更点をご紹介いたします。 前回のメジャーバージョンアップから、ずいぶんと時間が経ちました。前回のメジャーリリースであるバージョン 8.0.0 が公開されたのは、2023年1月16日のことです。その後、57回のマイナーアップデートと47回のバグ修正リリースを経て、ついに新しいメジャーバージョン 9.0.0 をお届けする時が来ました。 なぜ今なのか 私たちの最小サポート OS バージョンはかなり古くなっており、その結果、一部のユーザーが望まないほど多くの Xcode の警告を目にするようになっていました。「互換性は絶対（Compatibility is King）」を少し重視しすぎていたようです。だからこそ、メジャーアップデートを実施し、サポートする最小 OS バージョンを引き上げるのに最適なタイミングだと判断しました。 今回はどのようなリリースなのか バージョン 9 は「メンテナンス系メジャー」リリースです。 具体的には以下の通りです。 最小 OS バージョンの引き上げ いくつかの機能をデフォルトで有効化 多くの細かい API の問題を整理 アップグレードは簡単に行えるはずです。…そう言ってハマるのがお約束ですが。 知っておくべき変更点 バージョン 9 における変更点のほとんどは、「プラットフォーム要件」「デフォルトで有効になった機能」「以前から予定していたクリーンアップ」の 3 つに分類されます。 主要なポイントは以下の通りです。 サポート対象の最小 OS バージョンを更新 […]
【Sentry Seer】法務審査をクリアする方法 Seer をレビューする法務チーム向けガイド
Article by: Virginia Badenhope （本記事は法律の専門家が法律の専門家のために書いたものですが、法務担当者がいないまま Seer の利用を検討している方にとっても、安心材料になるはずです） 自社の法務部門が私たちと同じような状況にあるのであれば、事業側から「もっと多くの AI ツールを使いたい」というリクエストが次々と押し寄せてきているのではないでしょうか。開発チームは Cursor のようなコーディングエージェントを使いたがり、セキュリティチームは AI を活用した調査を導入し、セールスやマーケティングは通話内容のインサイトや競合調査に AI を活用しようとしています。私たちは各チームが試し、購入しようとしているツールに大きな変化が起きていることを目の当たりにしてきました。 サービスの主な機能自体は AI を前提としていない場合でも、いまやほとんどすべてのサービスが何らかの AI 機能を備えています。 ビジネス側も AI の利用には一定のリスクが伴うことは理解していますが、それでも「使わなければ取り残されてしまう」という強いプレッシャーを感じています。あなた自身も同じプレッシャーを感じつつ、自社のデータや知的財産はもちろん、顧客から預かっているデータや知的財産を守るという使命も負っています。 Sentry が Issue Scan や Issue Fix を含む自社の AI／ML 機能を支えるために開発してきた AI エージェントである Seer について法務レビューを依頼されているのであれば、本記事の目的は、Sentry の法務チームである私たちがサードパーティ製の AI ツールを評価する際に用いている基準を、Seer も同じように満たしていることを示すことにあります。 もし Seer の評価を依頼されたとしたら、私たちは承認します。理由は次のとおりです。 では、法務は実際のところ何を気にしているのか？ 私たちおよび顧客データと知的財産を保護しつつ、ビジネスの変化するニーズを引き続き支えていくために、Sentry では AI ツールの利用について次の要件に合意しています。 […]
【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 […]
10x チームの夜明け
Article by: Milin Desai 以前の記事では、人間であれ AI 搭載ツールであれ、デバッグはコンテキストに依存しているという話を書きました。コンテキストがなければ、どれだけ高性能なシステムでも「どのコードが壊れているか」までは教えてくれても、「なぜ壊れたのか」までは教えてくれません。 いまや AI は、開発者が頼りにしているのと同じレベルのコンテキスト（スタックトレース、トレース、ログ、コミット、コード）にアクセスできるようになりました。その結果、ソフトウェアの構築と運用のあり方が変わりつつあります。私たちは、単なるモニタリングの時代から「推論」の時代へと移行しつつあるのです。 「10x デベロッパー（10倍の成果を出す開発者）」という概念は、今でも議論の的です。本当にそんな人はいるのか？ 採用に力を注ぐだけの人数が存在するのか、それともユニコーン探しに過ぎないのか？ そして AI は、私たちの多くをその理想像に近づけることができるのでしょうか。 しかし、これらは本質的なポイントではありません。私たちの前にあるチャンスは、単発の「超人的な個人貢献者」を解き放つことではなく、AI の力で「10x チーム」を実現することにあります。 情報の「ふるい分け」から、共有される推論へ 何十年もの間、デバッグは「起きてから対応する」もの（リアクティブ）でした。何かが壊れると、1人のエンジニアが（後ろで足をトントンしながら待っている人に急かされつつ）ログやトレース、ダッシュボードに飛び込み、干し草の山から一本の針を探すように原因を追いかけていました。モニタリングツールは「何が起きたか」を教えてくれますし、それは当時も今も有用ですが、「なぜ起きたのか」を判断するのは常に人間の役割でした。 時間とともに、モニタリングツールも進化してきました（正直に言うと（少し自慢すると）、その進化には私たちも大きく関わっています）。いま開発者が求めているのは、生のエラーデータだけではなく、「どこで・いつ問題が発生し、誰に影響し、その原因となったコードの行はどこか」といったコンテキストに富んだインサイトです。「何かがおかしい」から、「ここがまさにおかしい」とスポットライトを当てて指し示せるようになったことが、デバッグにおける最初の大きな転換でした。データに意味を与え、壊れたコードを素早く修正するためのツールを開発者に提供したのです。 AI はこの転換をさらに大きく前進させています。Sentry の Seer のようなエージェントは、「何が起きたのか」を構成するあらゆる情報を取り込み、それをコードベースや最近の変更と突き合わせて、根拠のある形で根本原因分析を行います。つまり、「何が起きたのか」を踏まえて推論し、その原因（＝なぜそうなったのか）を自然言語で説明できるのです。しかも、それをインタラクティブに行うこともできます。 こうして、デバッグのプロセスそのものが変わります。これまでは、1人か2人の担当者がベストな仮説を立て、それをチケットなどを通じて組織全体へ共有する、という流れでした。いまはそれが「チームスポーツ」になりつつあります。チーム全員が、同じコンテキスト、同じ推論過程、同じ解決への道筋を共有できるようになっているのです。 人手による「情報のふるい分け」から AI による推論支援へと移行することは、単に個々の開発者を速くするだけではありません。「なぜそうなったのか」という答えをチーム全員で共有できるようにすることで、チーム全体を速くします。「10x エンジニア」のことばかり心配する必要はありません。これは「10x チーム」をつくるための、最初の、そして一見するとごくささやかな一歩なのです。 コンテキストは力を増幅する どのエンジニアリングチームも、コンテキストの断片化やデータ不足がもたらす影響を経験しているはずです。ひとつの大規模チームの中ですら、メンバー間の認識のずれは非常に大きくなり得ます。使っているツールも違えば、追いかけているダッシュボードも違い、DM でのサイド会話の内容も異なる。その結果、本番環境で何が起きているのかについて、メンバーごとにまったく異なるメンタルモデルが形成されてしまいます。 ひとつのコンテキストを共有できれば、フィードバックループは短くなり、重複した作業は減り、時間の経過とともに学習効果が蓄積されていきます。本番環境の問題のデバッグは、孤立した作業からチームで取り組むリズムへと変わり、各イテレーションのたびに、人と機械から成るシステム全体が少しずつ賢くなっていきます。 いまやコンピュータも同じように機能しています。Seer は Sentry […]
AIにもっとデバッグをうまくさせるには？重要なのは「コンテキスト」
Article by: Milin Desai AI を活用したコード生成ツールによって、これまでになく大量のコードが次々とリリースされています。いまは開発者にとっての黄金時代と言っていいでしょう。 しかし、ひとつ重要な事実があります。ソフトウェアは依然として本番環境で壊れてしまいます。Microsoft が最近行った調査によると、AI モデルはソフトウェアのデバッグを苦手としていることがわかりました。その理由は、多くのコード生成ツールで、優れた開発者なら誰もが頼りにしているたった1つのもの、「コンテキスト」が欠けているからです。 何かをデバッグしようとするなら、コンテキストが必要です。AI ツールがあっても、この前提は変わりません。AI は学習データを超えて、実際のエラーやトレースデータ、ブレッドクラム、スタックトレース、コードベース全体、コミット履歴などにアクセスできる必要があります。 AI があるかどうかにかかわらず、デバッグにはコンテキストが欠かせないのです。 AI 時代のデバッグに不可欠なのはコンテキスト Sentry はこの10年あまりの間に、13万以上の組織がソフトウェアの不具合をすばやくデバッグできるよう支援してきました。Sentry 独自のコンテキストを提供することで、エンジニアリングチームが本番環境でのデバッグを従来の 10 倍の速さで行うことができるようにしています。 何かが壊れたとき、開発者は次のようなことを知る必要があります。 問題はいつ発生し始めたのか。 壊れる直前に「何が変わった」のか。 影響を受けているのは 1 人のユーザーか、それとも多数なのか。 どのプラットフォーム／デバイス／リリースに影響しているのか。 問題の起点はどこか。自分のコードなのか、それとも依存している外部要因なのか。 Sentry はこれらの問いに答えるだけでなく、次の情報もあわせて提示します。 どの関数やコード片が失敗しているのかを正確に把握するためのスタックトレース エラーの前後で、アプリケーションがエンドツーエンドでどう振る舞っているかを確認するためのトレースとログ フロントエンドでデバッグしている問題に、バックエンドエラーが関係しているかどうかを確認できるようなトレースでつながった関連 Issue 例外の前後でどのようなアクションが行われたかを把握するための Sentry のブレッドクラム 各関数がどのようなパフォーマンス特性を示しているかをよりよく理解するためのプロファイリングデータ こうしたコンテキストのすべてが、長年にわたって Sentry を開発者にとって非常に有用な存在にしてきました。そしてこれは、障害が発生したときに本当に問題を修正するために、他の AI ツールにも必要でありながら、まだ備わっていないまさにそのコンテキストでもあるのです。 Seer：Sentry の […]
【AI 機能アップデート】全 Sentry ユーザー対象
Article by: Lindsay Piper 今回のアップデートでは、また新たなチャットボットを提供するのではなく、チームの時間が浪費されがちな Sentry の箇所に AI を直接組み込み、すでにお持ちのデータを即座に活用できるコンテキストへと変換できるようにしました。 そして本日、すべての Sentry ユーザーが利用できるようになりました。 Trace Explorer で自然言語クエリを使って質問するだけ Trace Explorer は自然な言葉で書かれた質問をそのまま受け取り、実際のクエリに変換できるようになりました。演算子やフィールド名を覚えておく必要はなく、知りたい内容をそのまま言葉で説明するだけで構いません。 たとえば「うちの DB の p90 レイテンシはどのくらい？」のような質問を入力すると、その裏側で必要なクエリが自動生成され、関連する span を特定し、レイテンシの分布を表示してくれます。 構文を書く必要は一切ありません。クエリを組み立てる手間は大幅に減る一方で、これまでと同じ深さのトレースデータにアクセスできます。 Issue の原因にまず「あたり」をつける 新しい Issue に遭遇したとき、最初の疑問はたいてい「どこから手を付ければいいのか？」ではないでしょうか。 各 Issue に表示される Initial guess は、Issue のコンテキストを自動的に解析し、何が問題になっていそうかを初期的に推定します。これにより、ソースコードや追加の Sentry テレメトリを参照して根本原因をより正確に特定する Seer による詳細な分析に進む前の、出発点を提供してくれます。 Session Replay Summaries でインサイトに素早くたどり着く エラーが発生した瞬間にジャンプできること自体は便利ですが、ユーザーがそこに至るまでの経路を理解するには、依然として時間がかかります。長いセッションでは、多数のインタラクションやネットワークコール、UI […]
【Sentry Godot SDK】Logs・User Feedback など新機能追加
Article by: Serhii Snitsaruk 最初の安定版リリースを経て、Sentry Godot SDK が Windows / Linux / macOS / iOS / Android をサポートし、一般利用いただける状態になったことをお知らせし致します。1年前、いくつかのプロトタイプから本格開発をスタートし、ついにここまでたどり着きました。実績のある Sentry プラットフォーム SDK 群の上に構築されており、Godot プロジェクトに簡単に追加できる GDExtension アドオンとして提供されています。 はじめて Sentry を知る方のために説明すると、Sentry はゲームの開発中・QA 中・リリース後を通じて「健全性」を管理するためのアプリケーションモニタリングツールです。クラッシュや実行時エラー、ログ、さらにはプレイヤーからのフィードバックまで自動的に追跡できるため、バグ追いに費やす時間を減らし、そのぶん「おもしろい体験」を作ることに集中できます。 このあと、Godot SDK に含まれる主な機能をご紹介していきます。 クラッシュとエラー Sentry はエラーやクラッシュのレポートを収集し、それらを「Issue」としてダッシュボード上に自動でグルーピングします。これにより、どの問題から優先的に修正すべきかを判断しやすくなります。 Godot Engine のランタイムエラーやスクリプトエラーを自動で捕捉し、詳細なスタックトレースを表示します。必要に応じてローカル変数やメンバー変数の情報、さらに可能な場合はその前後のスクリプトソースコード行まで確認することができます。 C++ レイヤーで発生したクラッシュについては、Sentry が minidump を収集・送信できます。これにより、ゲームがいつ、Godot のソースコードのどこでクラッシュしたのかを把握できます。この情報をもとにクラッシュの原因を理解したり、スタックトレース（または minidump ファイル）を Godot の開発者と共有したり、自分たちで問題を修正したりすることが可能になります。 […]
【webvitals.com 登場】サイトを遅くしている原因を見つけよう！
Article by: Anton Bjorkman, Sergiy Dybskiy 開発者が求めているのは、「ツールを実行して、数字を見つめて、落ち込むだけ」のウェブサイトではありません。なので、私たちは、まったく違うものを作りました。 WebVitals は、サイトの分析・最適化・高速化を、ひとつの場所でまとめて行えるサービスです。スタックトレースや遅いクエリに日々向き合っているメンバーが作ったこのツールは、パフォーマンス指標と、実際にユーザー体験を遅くしている原因とのつながりを浮かび上がらせます。 この 1 つの場所で、次のことができます。 実際のユーザーがあなたのサイトをどう体験しているかを把握する 最大の遅延要因をすぐに見つけ出す 専門用語や勘に頼ることなく、「次に何をすべきか」がはっきり分かる webvitals.com の仕組み ドメインを入力して「Go」を押せば、あとは WebVitals にお任せです。 裏側では、WebVitals が Vercel AI SDK を使って、いくつかのツールコールを実行します。 1つは Google の PageSpeed API：過去28日間の実ユーザーのパフォーマンスデータ、いわゆる CrUX データを取得します。 もう1つは Cloudflare の URL Scanner：サイトで使われている技術スタックを検出します。 これらの結果を組み合わせて分析し、本当に重要なポイントだけが浮かび上がるようにしています。 何がうまくいっていて、どこに改善余地があるのかが一目でわかります。各レポートでは、CrUX データを踏まえながら、指標を改善するための具体的でコンテキストのある次のステップを提示します。 なお、CrUX データは「実ユーザーの実際の利用データに基づく各指標の 75 パーセンタイル値」です。 Core Web Vitals レポート […]