【Seer】自動根本原因分析で N+1 クエリ問題を解消
Article by: Sergiy Dybskiy Shopify で働いていたとき、ブラックフライデーとサイバーマンデーはまさに私たちにとってのスーパーボウルでした。マーチャントの皆さんが1年の中で重要な時期に予期せぬトラブルに遭遇しないよう、数週間も前からコードフリーズに入っていました。それでも、ときには直前になってアップデートをリリースしなければならないこともあります。 たとえば、こんな場面です。 ブラックフライデー前夜の午後 11 時 47 分。50 点以上の商品を割引価格で掲載した新しい /sale ページをデプロイしたばかりです。マーケティングチームはこれから 50 万人の購読者にメールを送ろうとしています。サンプルデータでのテストはすべて問題ありませんでした。 そして午前 0 時 13 分、最初の Sentry アラートが届きます。 問題 /sale エンドポイントの平均レスポンスタイムが 1 リクエストあたり 4 秒以上かかっています。ユーザーはタイムアウトを経験しており、今すぐこの問題を修正する必要があります。 Sentry が問題を検知する Sentry を開いてみると、すでに原因が特定されています。N+1 クエリです。Sentry はトランザクションスパンを自動的に解析し、/api/sale エンドポイントがリクエストごとに 150 回以上の連続したデータベースクエリを発行していることを突き止めました。 Issue の詳細を見ると、典型的なパターンが現れています。 まず最初に全商品を取得するクエリが 1 回実行され、その後に各商品のセール価格、メタデータ、カテゴリ情報を取得するクエリが何度も繰り返し実行されています。典型的な N+1 です。 […]
Seer が Cursor Agents を起動してバグを自動修正できるようになりました！
Article by: Jenn Mueng 先日、Cursor Cloud Agent との連携機能をリリースしました。これにより、Seer がバグを見つけたときに、その問題に関して Sentry が持っているコンテキスト一式を添えて Cursor に渡し、修正コードを書いて PR を作成させることができるようになりました。 完全自動＆検証済みのコード修正 これからは、実際に稼働しているコードベース環境の中で、コーディングエージェントを自律的に動かすことができます。しかも、すべてバックグラウンドで実行されます。 Seer が問題を検知し、根本原因を分析すると、その結果と問題のコンテキストを Cursor Cloud Agent に送信できます。 エージェント側では次の情報を受け取ります。 Issue のコンテキスト一式：スタックトレース、ブレッドクラム、ユーザーインパクトなど Seer の Root Cause Analysis：実際に何が壊れているのかに関する詳細な分析結果 あなたの稼働中コードベース：Cursor Cloud Agent は実際のコードベース全体にアクセスでき、コードの実行も可能 あとは、あなたがコーヒーを取りに行っている間に、エージェントが自律的に作業を進めてくれます。戻ってくる頃には、あなたのリポジトリにはエージェントが作成した PR がすでに用意されています。 使い方は 2 通り 手動トリガー 任意の Issue の「Seer Root Cause Analysis」カードから、Find […]
【AI Code Review】バグを3万件削減、50%高速化
Article by: Lindsay Piper 先月、私たちは AI Code Review をリリースしました。これは、バグを自動で検出し、パフォーマンス問題を見つけ、PR をより速く出荷できるようにする開発者向けツールです。 リリースから30日、アップデートは次のとおりです。 自社コードでの AI Code Review の検証 これまでに、AI Code Review は3万件以上のバグを検出しました。そのうちいくつかは、Sentry のスタッフエンジニアである Ryan Brooks のサイドプロジェクト（持久系アスリート向けにトレーニング計画を作成・維持するアプリ）にも含まれていました。Strava のパフォーマンスに基づいてワークアウトを調整する、いわば「適応型のバーチャルコーチ」です。 AI Code Review はスケジューリングのロジックバグを検出しました。 「私のアプリの一部では、レース日から逆算してトレーニングの“フェーズ”を生成します。このアルゴリズムにいくつか手を入れたところ、Sentry が、2つのフェーズが潜在的に重なり得るという、起こり得ないはずのバグを正しく検出してくれました。PR のコメントをそのまま Claude Code に貼り付けたら、バグは修正されました。」 ユーザーに確実に影響していたはずのミスもありました。 「オンボーディングのフローに、3週間未満先のレースを追加できないようにするロジックを加えました。率直に言って、来週末にマラソンは走らないでしょうからね。ですが、レースの編集にも同じ React コンポーネントを使っており、Sentry がすでに予定されているレースの編集をブロックしてしまうバグを見つけてくれました。これは大きな指摘でした。」 コピペできるプロンプトで、コメントをより高速に パフォーマンスを50%改善 レビューにかかる時間が誰にとっても長すぎたため、レビューパイプラインを作り直し、平均レイテンシをおよそ50%削減しました。 実施内容は次のとおりです。 推論量が少なくてよいタスクについては、出力の一貫性を保つようプロンプトを調整しつつ、より高性能な（高速な）モデルへ切り替えました。 すべてのステップに「思考の上限（thinking budget）」を設け、仮説検証ステップには最大反復回数を設定して、考えすぎ（overthinking）を防ぎました。 評価（eval）とスポットチェックを実施し、パフォーマンス改善がレビュー品質に悪影響を与えていないことを確認しました。 要するに、レビューはこれまでより速くスリムになり、私たちはそのバランスの調整を継続しています。 […]
【バイブコーディング】トレーサビリティでフィードバックループを閉じる
Article by: Kyle Tryon ここ数か月で私は本気で「ヴァイブ・コーディング」を受け入れはじめ、メインのコードエディタとしては Cursor を、エージェントの LLM としては Claude Sonnet 4 を使っています。開発者にとっていまは刺激的な時代です。私たちは、生産性を100倍にしてくれるかもしれない何かを試しつつ、これらのツールを実装するための新しいワークフローや戦略を切り拓いているのです。 しかし、十分に大きなコードベースで LLM を使った本格的な開発をしたことがある人なら誰でも知っているとおり、それは「怯えた猫の群れをまとめようとするようなもの」です。 コードベースが複雑化・分散化するほど、管理すべきコンテキストは増え、ファイル固有のルールも増え、エージェントから高品質な出力を得ることが全般的に難しくなります。皮肉なことに、私たちがコードをきちんと整理すればするほど、LLM はそれを見つけるためのコンテキスト管理タスクをより多くこなさなければならなくなります。 PR のレビューやテスト生成といった AI ツール一式があっても、AI 生成コードを出荷するのは不安が残ります。ヴァイブ・コーディングで作った機能が本番を落とさないと、どうして言い切れるでしょうか。そもそも本当に動くのか、どうやって確かめればよいのでしょう。ビルドを通すためだけに、エージェントが巨大なコード片をコメントアウトしてしまうのを目にしたことさえあります。 エージェント主導のコードサイクルには盲点があります。しかし、それは修正可能です。 LLMの盲点：実行時の可視性 プロンプトを微調整したり、docstring を追加したり、エージェントのルールを洗練させたりしても、核心的な問題は解決しません。LLM は、自分が生成したコードが実際に走ったときに何が起きるのかを「見る」ことができないのです。暗闇の中で手探りでダーツを投げ、修正を重ねても照準を合わせ直せない。しかも、生成コードに現れたエラーは、LLM がその問題を見ないまま反復するほど増殖していきます。 現状のコンテキスト管理は、プロンプトにどのファイルを含めるかの管理に大きく依存しています。MCP（Model Context Protocol）は一歩先に進み、複数のデータソース間でコンテキスト情報をやり取りできるようにしてくれます。 いま Cursor や Claude Code のようなツールを、MCP 連携が限定的な形で使っているなら、あなたのコンテキストはおそらくアプリのソースコードと、多少のドキュメント、それにコピペした何かくらいに留まっているはずです。 コードを実行し、そのログを問題解決のために手動で LLM に食べさせたことがあるかもしれません。目指すべきはここにフィードバックループを組み込むことです。すなわち、コードを生成し、その実行からテレメトリ（計測情報）を収集し、その結果を LLM に知らせることで、ガイダンス付きで解法の反復を進められるようにするのです。 このフィードバックループをどう閉じるかを理解するために、まずトレースとは何か、そしてそれが欠けている「実行時の可視性」をどう提供できるのかを見ていきます。MCP サーバーを使えば、この重要なコンテキストを LLM エージェントに追加し、可視性のギャップを埋めることができます。 […]
【Sentry AIコードレビュー】現在ベータ版：本番環境での問題発生を減少
Article by: Lindsay Piper これは防げたはずです。 これも防ぐべきでした。 これも同じです。 私たちは皆、PR（プルリクエスト）でタグ付けされるのが嫌いです。時間を取られ、必ず何かを見落とした時には責められ、そして「自分ならこうは書かなかった」という感覚が常につきまといます。LLM（大規模言語モデル）は、これをもっと簡単にしてくれると約束しました。私たちの代わりにやってくれると。しかし、ご覧のとおり、まだその段階には至っていません。 しかし、これこそが Sentry の本業です。私たちはバグを捕まえます、本番環境で。では、その専門性をコードレビューの段階に持ち込んだらどうでしょうか？天才的だと思いませんか？ そこで私たちは、AI コードレビューに新しい機能を追加しました。プルリクエストを開く際に、Sentry の Issue を取り込み、実際にバグを予測するのです。もちろん、すべてのエラーを防げるわけではありません。あなたが書いた（あるいはプロンプトで生成した）コード以外にも考慮すべき要因があまりに多すぎるからです。しかし、この機能を使えば、本番環境を停止させるような回避可能なミスを出荷してしまうことを防ぐことはできます。 Sentry のコンテキストをプルリクエストに持ち込む AI ツールにおいては、コンテキストこそがすべてです。これは、Seer がベータ期間中に開発者たちの累計2年以上の時間を節約できた理由でもあります。私たちの AI コードレビューも同じアプローチを取りますが、それを出荷（デプロイ）前に行います。具体的には、あなたが触れたコードに対して Sentry のコンテキストや、そのコードに関する過去のシグナルを活用します。対象となるのは、関数の残りの部分、リポジトリ内で呼び出される関数、そして依存するクラスやオブジェクトです。 この「ライブのコードコンテキスト」と「現実世界での Issue 履歴」を組み合わせることで、フィードバックは曖昧な警告や一般的なリンティングの助言ではなく、具体的で実行可能なものになります。 最も重要なエラーを予測し、防ぐ 自動化された PR レビューは、たとえリポジトリ全体のコンテキストを持っていても、しばしば実際の問題をスタイル上の細かい指摘やベストプラクティスに埋もれさせてしまいます。その結果、開発者は「consider inlining」や「prefer async/await」といった注意の洪水の中から UnboundExecutionError を探し出さざるを得なくなるのです。 しかし、Sentry のコードレビューはそうではありません。PR がレビュー可能（ready for review）とマークされたときに実行され、実際に本番環境を壊すものだけにフォーカスします。 したがって、もしあなたが次のような変更を含む PR を開いた場合、以下のようになります。 インポート文の後に空行を追加したほうがよい、といったコメントは表示されません。 Sentry が返すのは、次のように 具体的で実際に役立つデバッグコメント です。 これがどのように動作するかは、次のとおりです。 […]
分散システムのトラブルシューティングにトレース参照機能を備えた Sentry AI デバッガー
Article by: Rohan Agarwal デバッグは、すべての開発者にとって常に付きまとう課題であり、たとえAIがコードを書くようになったとしても、その負担が増す可能性さえあります。Sentry のようなツールは、長年にわたりエンジニアが問題を追跡し、デバッグを行う際に支援してきましたが、新たなAIツールを活用することで、こうしたプロセスをさらに迅速かつ容易にできる点が魅力です。 もちろん、Sentry から例外のスタックトレースをコピーして ChatGPT に貼り付けることも可能です。しかし、もし本当に賢いものが欲しいとしたら、どうでしょうか。AI が最善の仕事をするために、より多くのコンテキストを持ち、分散システムを深く理解し、本番環境でそれらをデバッグする能力を備えたものがあればどうでしょうか。 本記事では、私たちがどのようにして、トレーシングの力を活用して、Sentry の本番レベルの AI デバッグアシスタント「Seer」を構築したのかを説明します。 AI によるデバッグの欠点はどこにあるのか？ Seer とその Autofix 機能は、Sentry のIssues 詳細とコードベースとの緊密な統合を活用することで、問題の根本原因を突き止め、修正するための優れたツールとなっています。Autofix は開発者と協働しながら、問題の根本をより深く理解し、効果的な解決策を計画し、さらにはそれを修正するプルリクエストの下書きまで作成します。さらに、リグレッションを防ぐための単体テストも含まれます。これまでのところ、その裏側では主に Sentry のスタックトレースやパンくずリスト、そしてコードベース検索に依存して知見を得ていました。実際、Autofix はすでに数多くの開発者を助けており、さまざまなアプリケーションのバグを修正してきました。 Autofix 自身のバグさえもです。 しかし時には、Autofix が的を外してしまうこともありました。たとえば、フロントエンドから報告された「500 Internal Server Error」に対して Autofix を実行しても、バックエンドでの問題を特定することはできません。あるいは、2つのマイクロサービス間で認証の問題が発生した場合、Seer には実際に何が起きているのか把握できませんでした。さらに、複雑なアプリケーション全般においては、エラーの発生源となっているモジュールがどのように、なぜ利用されているのかについて、ほとんど理解できていませんでした。 ここで登場するのがトレースです。トレースを使うことで、Seer はマルチサービスシステム全体のフロー（フロントエンドとバックエンドといった複数階層を持つソリューションや、さまざまなマイクロサービスを利用するものを含む）、関連するエラー、エラー発生前後に実行された正確な処理（さらにプロファイリングを有効にすれば正確な関数呼び出しまで）を明確に把握できます。これにより Seer は、プロジェクトやリポジトリをまたいだ問題を非常に速く分析し、現実世界でエンジニアが直面する最も複雑な問題の一部を自律的にデバッグできるようになります。それに比べて、チャットボットにコピー＆ペーストするだけでは表面をなぞるに過ぎません。 トレースとは何か？どう活用できるのか？ すでに内容をご理解いただいている場合は、このセクションをスキップしていただいて構いません。そうでない場合は、ここで簡単にご説明します。 トレースとは、アプリケーションおよびその関連サービスを通じてリクエストがどのように流れるかを記録し、データの移動経路や潜在的な問題の発生箇所を可視化する仕組みです。トランザクションやリクエストに関与するイベントのシーケンスを追跡することで、分散システムにおけるパフォーマンスのボトルネック、エラー、依存関係などを特定するのに役立ちます。 トレース内の各ステップは「スパン」と呼ばれ、データベースクエリ、API呼び出し、関数の実行などの作業単位を表します。これらのスパンを組み合わせることで、初期リクエストから最終レスポンスまでの全トランザクションの経路を、包括的に視覚化することができます。トレースは複雑なマイクロサービスアーキテクチャのデバッグおよび最適化において、特に高い価値を発揮します。 Sentry を使えば、トレースを簡単に始められます。アプリに Sentry SDK を追加すると、多くの部分が自動的にインスツルメントされ、後からカスタムのスパンや属性を任意でインスツルメントすることもできます。たとえば Python […]
LLM パフォーマンスのコア KPI（と追跡方法）
Article by: Sergiy Dybskiy 本ブログの内容 「良い」LLM KPIとは？ 抑えるべき LLM パフォーマンスの中核指標10選 Sentry の AI オブザーバビリティを始める 他にも追跡しておくべき LLM メトリクス 次のステップ LLM を制御下に置くために 数か月前、トロントのオープンデータポータル向けに MCP サーバーを構築し、エージェントがユーザーの質問に関連するデータセットを取得できるようにしました。最初のバージョンを急いで作り、コードをざっと確認したところ、問題なさそうに見えたので、Claude に「トロント市における交通関連のデータソースにはどんなものがありますか？」と尋ねました。 ツール呼び出しは動作し、関連する結果も得られました。ところが、すぐにエラーが出ました。 「会話が長すぎます。新しい会話を開始してください。」質問を一度しただけだったのに。 原因は、最初の呼び出しで API から返された巨大な JSON ペイロードでした。それがコンテキストウィンドウを埋め尽くしてしまったのです。見ればすぐに解決できる簡単な問題でした。 しかし、モニタリングがない AI アプリには他にも様々な落とし穴があります。ツールのタイムアウトが黙って発生する、トークン使用量が急増する無限ループ、遅い検索、JSON フォーマットを壊すモデルのダウングレード、あるいは単純な500エラーなどです。 こうした場面があるからこそ、私は重要な問題をすぐに表面化させるために監視しているいくつかの主要な指標をまとめています。 「良い」LLM KPIとは？ Rahul が言うように、「プロンプトを入力してレスポンスが返ってくる。それはオブザーバビリティではありません。ただの“雰囲気”です。」 良いKPIとは生のカウンター値ではなく、プロダクトの成果に結びついた方向性のシグナルです。特にAIエージェントのパフォーマンス指標において重要です。 3つの視点で考えてみましょう。 信頼性：正しく動作しているか コスト効率：妥当な範囲でコストを抑えられているか ユーザー体験：速くてレスポンシブに感じられるか 以下のメトリクスはこれらの視点に直接対応しており、あなたも経験したことがあるであろう実際の障害とも結びついています。例えば、ループによるトークンスパイク、不安定なベクターデータベースがレスポンスを遅くする問題、あるいは静かに行われたモデル変更で出力品質が大幅に低下するケースなどです。 また、これらは「LLM 評価指標（LLM evaluation metrics）」「LLM […]
AIアシスタントに対する考え方を変えたSentryのAI
Article by: Dan Mindru ブロックチェーン、IoT、ビッグデータ… テクノロジー業界で長く働いていると、こうしたバズワードが時折現れては話題をさらい、やがて輝きを失っていく光景を何度も見ます。多くの流行が生まれては消えるのを経験してきた私は、つい懐疑的になってしまいます。 今回も、「今度は何を売り込もうとしているのか」と考えてしまいました。これを「愚痴っぽい」と言う人もいれば、「エンタープライズ・アーキテクト的だ」と言う人もいます。だから、AIアシスタントを最初は単なるバズワードだと思っていたことを、どうかお許しください。所詮は、きれいな箱に入った5つの API 呼び出しにすぎないと思っていたのです。 ところが、私は大きく間違っていました。 AIアシスタントとは 平たく言えば、AIアシスタントは販売管理から会議のスケジュール調整、コピーライティングまでを、少ない手間で短時間にこなす有能なチームメイトのような存在です。複数のプロンプト、API 呼び出し、認証、ユーザー入力を組み合わせて構築され、必要に応じてワークフローを自動的に計画できます。 万能でも低価格でもありませんが、すでに私たちの働き方を変えつつあります。さらに、AI の総コストが下がりつつある現状を踏まえると、AI 機能を実装する際の主流の選択肢になる可能性があります。 詳しく知りたい方は、AI エージェントに関する記事もご覧ください。ご自身のアプリでの活用方法を解説しています。 すべてが始まったバグ 私は「技術的に進んでいない」と感じていたため、しばらくの間、AIアシスタントを軽視していました。それは「ただの AI」に、ほんの少し装飾を加えた程度のものだと思っていたのです。しかし、インディーハッキングでの経験から学んだのは、製品を作るうえで重要なのは先進的な技術そのものではなく、解決できる問題だということです。 AIアシスタントは間違いなく強力なツールです。ただし、大きな力には大きな責任が伴います。すべての問題を解決できるわけではなく、最速の手段とも限りません。それでも、確かに有用な使用例があります。 私が信じていなかった理由のひとつは、そうした使用例を実際に見たことがなかったからなのですが、ある日、お気に入りのモニタリングプラットフォームで見つけた機能が、私の視野を大きく広げることになったのです。 その機能とは、Sentry の AI Autofix（現在はベータ版ですが、まもなく一般公開されるでしょう）です。すべては、ほとんどの良い話がそうであるように、一通のメールから始まりました。私のように「バグなんて書かない」という方でも、これはきっと驚かれると思います。 誤検出に違いないと考え、「Sentry で表示」をクリックして事態を確かめました。 そして… このあと何が起こったのか、きっと信じられないでしょう…。 私が初めて感動した AIアシスタントAI Autofix 問題を開いた瞬間、自分の能力を過大評価していた可能性がすぐに明らかになりました。 「これは、例外が規則を証明するケースに違いない」と、自分に言い聞かせます。 しかし、問題ビューの右上隅にあるソリューションハブが目に入りました。原因はどう見ても間違っていて、私は思いました。 「なるほど、Sentry も AI ブームに乗ってきたか。今日は大きく失望させられるかもしれないな」と。 ……冗談はさておき、最初は単なる一発のプロンプトに見えました。ですが、私の興味を強く引いたのは「Open Autofix」ボタンです。Sentry はこの問題に対して豊富なコンテキストを保持しています。コードベース、ソースマップ、例外の詳細、さらには多数の匿名ユーザープロパティまで。人間にとって Sentry が有用であるのと同じ理由で、AI にとっても有用になり得ます。 そして、そのボタンを押した瞬間、この機能は単なるギミックではないと確信しました。 初期分析と自己修正 […]
【AIエージェント】ハイプか現実か？
Article by: Dan Mindru 数年前はブロックチェーンが話題の中心でした。その前はIoT、その前はビッグデータ、さらにその前はクラウドでした。それぞれの時代が一種のパラダイムシフトをもたらし、大規模な投資と約束が生まれました。成功したものもあれば、そうでないものもありましたが、いずれもテクノロジーの進化を促進したといえます。 現在、私たちは2022年頃にOpenAIから始まったAIの誇大広告サイクルを全面的に受け入れています。しかし、今回はこれまでとは異なる感覚があります。マーケティングが優れているからではありません（「OpenAI」の「Open」と「AI」について議論の余地はあります）が、前例のない速度で実際のアプリケーションが次々と登場しているからです。これは未来の約束ではなく、「今」起きている現象です。そして、その進展は非常に速いのです。では、どのくらい速いのか。その速さは、2025年の現在、誰もが次のビッグトレンドである「AIエージェント」に飛びついていることからもよくわかります。 OpenAIは「Operator」を発表しました。これは自分のブラウザを使ってユーザーのためにタスクを実行できるAIエージェントです。中には2024年の時点で一足先にAIエージェントをリリースした企業（Chatbaseなど）もあります。 しかし、そもそもAIエージェントとは何でしょうか？ 初めて聞く方にもわかるように説明しましょう。14歳の子どもにも説明できると言いたいところですが、正直なところ、最近では私たちより彼らの方がAIエージェントについて詳しいかもしれません。 では、始めましょう！ AIエージェントとは？ 想像してみてください。 あなたの会社で極秘のエンタープライズアップグレードが導入されたとします。ITチケットも不要、ダウンタイムもなし、マニュアルもいりません。目に見えない裏方チームが、カスタマーサポートの対応、コードの記述、ドキュメントの翻訳、マーケティングコピーの作成など、あらゆる作業を同時にこなします。しかも月額200ドル、24時間365日稼働し、「至急」案件も数分で「完了」へ。ミーティングもオンボーディングも不要。まるでワークフローに誰も予想しなかったターボボタンを追加したようなものです。それがAIエージェントであり、どのように見ても魅力的です。 では、仕組みはどうなっているのでしょうか？ AIエージェントは、大規模言語モデル（LLM）を強化するためのシステムであり、タスクの計画、サードパーティサービスとの統合、プロンプトの連鎖による回答の洗練を行います。 LLMとは？LLM（大規模言語モデル）は、大量のテキストデータで学習されたディープラーニングモデルで、人間のような言語を理解し生成します。文章の次に来る単語を予測し、質問への回答、コンテンツの執筆、言語の翻訳、アイデア出しなどを、学習データ内のパターン認識を通じて実行します。 簡単に言えば、比較的シンプルなプロンプトを受け取り、それを複数のプロンプトとAPIコールの組み合わせに変換できます。もちろん、単一のプロンプト実行よりはコストが高くなります（この点については後述します）。話を複雑にしすぎずに言えば、AIエージェントのワークフローは「彼ら」が従うフローに基づいて大きく2つのカテゴリーに分かれます。 処方型ワークフロー 探索型ワークフロー これらについて詳しく見ていきましょう。 処方型ワークフロー 単一のレスポンスで完結 シンプルに言えば、AIエージェントは「通常の」プロンプトを連結したものです。魔法のようなものではありませんが、実用的な実装が可能になります。 例えば、AIエージェントのシンプルな実装は、好みのAIモデルに対して複数回のLLMコールを行うforループであり、その前後にサードパーティAPIコール（あるいはインテグレーション）を組み合わせる形です。 一部のAPIコールは他のサードパーティAPIへのアクセスでもあり、ユーザーの「ゲート」（入力待ち状態）によって制御される場合もあります。 これは、リアルタイムデータや他のシステムに隔離されたデータへアクセスするなど、LLMの本質的な制限を克服するのに特に有効です。 例えば、AIエージェントが従業員の休暇申請を処理するケースでは、内部APIを介して分離された人事データベースにアクセスし、残りの有給休暇を確認し、条件を満たせば自動承認する、という流れです。 他の例としては以下のようなものがあります。 カスタマーサポートFAQエージェントクエリの意図を特定するために4つのプロンプトを連鎖させ、内部ナレッジベースから関連情報を取得し、ユーザーにわかりやすい形で返します。 コンテンツ作成ワークフローブログ記事作成のために3つのプロンプトを連鎖し、アウトラインの生成、各セクションへの展開、最終稿のスタイル調整までを行います。 ミーティングスケジューラーAPIコール、プロンプト、再度APIコールを連鎖し、個人のカレンダーを確認し、最適な時間にミーティングを提案・予約し、Slackチャンネルへ通知します。 処方型ワークフローでは、タスクを小さなマイクロタスクに分割し、並列処理したうえで最終的に1つのレスポンスにまとめることもできます。このアプローチは非常に高性能かつ柔軟性があります。 さらに、各マイクロタスクがそれぞれ独自にAPIコールを行い、リアルタイムデータや隔離されたデータを取得することも可能です。 つまり、これらのワークフローは、私たちがよく知っていて好むLLMの特性（文脈理解、タスク非依存の多用途性、柔軟な推論、人間らしい対話など）を活かしつつ、それ単体では難しい、あるいは不可能な機能を補完しています。 処方型ワークフローの利点はコストが予測しやすい点です。単一のLLMコールよりは高くなりますが、APIの使用量やタスクの複雑さが一定ならコストは安定します。 しかし、統合数を増やすと難易度や非効率が増すこともあります。APIコールがすべて必要とは限らず、場合によっては動的なユーザー入力が求められることもあります。 では、もしエージェント自身がこれを判断できたらどうなるでしょう？ 探索型ワークフロー：適応的かつ動的 ここまで読んでこう思ったかもしれません。 「AIエージェントって、トレンチコートを着たLLMコール3回分の塊じゃない？」 しかし、実は時には冬用ジャケット、金融用ベスト、さらにはダサいクリスマスセーターにもなり得ると言ったらどうでしょう？実際、すべてのAIエージェントが同じように作られているわけではありません。多くのエージェントはプロンプトの連鎖に基づいていますが、それだけでなく計画、推論、反復、自己指向的なワークフローの遂行も可能です。 探索型ワークフローは動的で適応性があります。処方型ワークフローで可能なすべての経路をたどることができますが、あらかじめ定義されているわけではなく、APIやインテグレーション、人間からのフィードバックに基づいて自ら計画・実行・適応します。根本的には、プロンプト技法、ループ処理、APIコールの集合体です。そこにユーザー入力を少し加えることで、数年前には構築不可能だったようなシステムが実現できます。 このようなワークフローは、より汎用的になり、ツールやAPIコールの数に関わらずスケールし、何千もの個別かつ動的なワークフローを構築できる可能性があります。これも拡張手法の一つですが、より多くの工夫が加わっています。 動的な計画立案：エージェントが中央レジストリから使用するツールを自分で決定します。 ツール統合：OpenAPI仕様のようなコンテキストを利用して、CRMシステムや各種APIと統合します。 セキュアアクセス：OAuthのようなプロトコルを使い、エージェントが安全にプライベートデータへアクセスします。 反復的推論：結果を評価し、成功または失敗の基準に達するまで計画を調整します。 フィードバックループ：強化学習や人間のフィードバックを通じてパフォーマンスを改善します。 例えば、クラウドストレージやメールを横断検索するよう指示されたAIエージェントを考えてみましょう。このエージェントは、必要に応じてDropboxやGmailのAPIを呼び出し、実行ステップを動的に計画し、タスクが完了するまで結果に基づいて繰り返し処理を行います。実際のアプリは単純な入力インターフェースであり、ユーザーは「Dropboxを検索」といった特定のサービスを指定したり、「メールとカレンダー全体を検索」といった一般的な指示を出したりします。 […]
Transformer ベースのテキスト埋め込みモデルで Sentry アラートを 40% 削減 ー ノイズを突破
Article by: Tillman Elser, Josh Ferge Sentry は Issue Grouping（イシューグルーピング） を使用して、同一のエラーを集約し、重複するイシューの作成やアラートの送信を防止しています。 しかしこれまでにユーザーから最も多く寄せられていた不満の一つは、既存のアルゴリズムでは一部のケースで類似エラーが十分にまとめられず、Sentry が別々のイシューやアラートを生成してしまうことでした。これにより、開発者にとって不要な混乱、あるいは少なくとも煩わしさが生じていたのです。 この課題に対応するため、私たちは過去最大規模のイシューグルーピングアルゴリズムの改良を行いました。新しいAI搭載のアプローチでは、Transformer ベースのテキスト埋め込みモデルを使用し、新規イシューの生成数を40%削減しつつ、エンドツーエンドの処理レイテンシーを100ミリ秒未満に維持しています。 本記事では、このAIを活用したイシューグルーピングの開発・テスト・デプロイのプロセスについてご紹介します。 なぜ重複イシューが発生するのか Sentryの主要な価値は、ログを延々と読むことなく、必要な情報に素早くアクセスできる点にあります。新たな問題が発生すると、イシューフィード、メール、メッセージングプラットフォームなどを通じて開発者に通知されます。この一連のプロセスの鍵を握るのが、グルーピングアルゴリズムです。 経験豊富な開発者であれば、2つのスタックトレースを比較し、それらが同一の問題かどうかを判断するのはそれほど難しくありません。しかし、この判断プロセスを堅牢なヒューリスティック（経験則）として実装するのは容易ではありません。 たとえば、Reactアプリケーションでは、同じ「Invalid prop」エラーが異なるスタックフレームの順序で出現することがあります。あるときは validateProp(Select.js:42) に続いて Anonymous Component(App.js:123) が現れたり、逆の順番になったりすることもあります。同様に、Python では一見同じ KeyError が、コードのリファクタリングによりわずかに異なる行番号（たとえば line 145 と line 147）で発生することもあります。 さらに、非同期処理（async） はより一層複雑になります。たとえば Python の async 関数内で ValueError が発生した場合、それが asyncio/tasks.py を経由するか asyncio/runners.py を経由するかで、同じエラーが異なる実行パスを通って表面化することがあります。 私たちのグルーピングアルゴリズムは、これらのバリエーションを同一の根本原因として扱いつつ、明確に異なるエラーは正しく区別できなければなりません。しかも、Sentry は高速かつ効率的である必要があります。イベントの取り込み速度の低下や処理コストの増大は許容されません。 従来のグルーピング手法の問題点 従来のグルーピングアルゴリズムは、段階的に広いマッチング戦略を適用しながら、各エラーに対してユニークなフィンガープリント（指紋）を生成することで動作します。最も精度の高い手法であるスタックトレースの分析から始まり、アルゴリズムは各フレームを検査します。その際、アプリケーションコードとサードパーティライブラリを慎重に区別し、さらにプラットフォーム固有のルールに従って正規化を行います。 たとえば、Python のトレースバックと、難読化された JavaScript […]