【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 を確認するのはリリースチェックリストの一部です。この方法で重大な問題を捕捉し、ユーザーベースに影響する前に悪いリリースを止められました。」— […]
【React Native】パフォーマンス改善戦略：最新の手法とツール
Article by: Simon Grimm 本記事は、Galaxies.dev の創業者である Simon Grimm によるゲスト投稿です。Galaxies.dev は、ハンズオン形式のコース、専門家のガイダンス、そして個別サポートを通じて、開発者が React Native を習得できるよう支援するプラットフォームです。 React Native のパフォーマンスは、これまで以上に重要になっています。 新しいアーキテクチャが安定版となり、アプリが電光石火のネイティブ体験と競い合う中で、ユーザーは1秒未満の読み込み時間と滑らかな60fpsの操作感を期待しています。遅いアプリはユーザーを苛立たせるだけではなく、最終的な利益にも直結します。実際、100msの遅延でもコンバージョン率が7%低下し得ることを示す調査があります。 そこで、朗報です！ 新しいアーキテクチャを備えた React Native 0.80 以降に、Expo Router や Reanimated 4 といった最新ツール、そして Sentry による包括的なモニタリングを組み合わせることで、開発者は高パフォーマンスなアプリを作るための強力な手段を手にできます。ただし、大きな力には、それに見合う技術が必要です。 本ガイドでは、起動時の最初の印象という重要な局面から、高負荷時でも滑らかなアニメーションを維持する方法まで、React Native アプリのパフォーマンスをあらゆる面で最適化するための実証済みの戦略を解説します。 本記事で扱う内容は次のとおりです。 操作可能になるまでの時間（TTI）の短縮する React の最適化 60フレーム/秒（FPS）を達成する リスト表示のパフォーマンスを改善する 丁寧な状態管理 各トピックには、今日から実装できる実際のコード例と実践的なツール選定のおすすめを含めています。 さらに、Sentry が提供するシグナル（指標）を見ながら、アプリ内で何が起きているのか、そしてどう直せばよいのかを理解する方法も掘り下げます。 React Native アプリを、パフォーマンスの強力なアプリへと変えていきましょう。 1. 操作可能になるまでの時間（TTI）を短縮する TTI はアプリ起動後に「使える状態」になるまでの速さを測る指標です。アプリアイコンをタップしてから、ラグや処理中スピナーで待たされることなく、ユーザーが実際に […]
【Skimmer】タブ追加ゼロでリリースを65%高速化
Skimmer はプールサービス業界をリードする業務・物流管理プラットフォームです。スケジューリングやルーティングから請求までを通して現場チームの動きを支え、ソフトウェアが仕事の妨げにならないようにします。 舞台裏では、分散された .NET アーキテクチャが毎週木曜日のリリースを支えています。Web は React、モバイルは .NET MAUI、さらにデプロイ可能な 24 以上のマイクロサービスで構成されています。約24名のスリムで実践的なエンジニアチームで、前年比 40〜50% の成長を続ける Skimmer にとって、見逃されたバグや修正の遅れは致命的です。特に非同期でキュー中心のフローではなおさらでした。 彼らが必要としていたのは「何が起きた？」をクリックひとつで「なぜ起きたのか」「どこで起きたのか」へと変えられるツールでした。 Skimmer が向き合っているのは、ユーザーが「動かなかった」などと書き込む現実の現場です。しかも処理の多くは、キューやバックグラウンドワーカーを介した非同期ジョブとして実行されます。そのため障害の原因は、エラーが表面化した場所やタイミングとは別のサービス、別の時点に存在することがあります。 「サーバーのシグナルは一箇所、ログは別の場所、クライアント／モバイルのクラッシュはさらに別のところ。エラーを投げない問題は何時間もパターン探しに化けることがありました。」— Gary Osteen（品質・オペレーション担当ディレクター） 調子の良い日なら、彼らはエラーの位置を三角測量のように絞り込めました。けれど普段はサポートチケットの会社IDを手がかりに、ログ、バックエンドのメトリクス、クライアントのクラッシュレポートをつなぎ合わせる作業に追われていました。しかも報告者が本当にそのエラーに遭遇した本人であるという前提に賭けるしかありませんでした。 一方で事業は加速度的に成長していました（前年比 40〜50%）。しかしチーム規模はそれに合わせて倍増していません。リーダー陣は現場主義を保ちつつ、「何を変えるべきか」は明確に把握していました。必要だったのはダッシュボードを増やすことではなく、調査の起点を一本化できる開発者が実際に使う場所にある、情報の参照先を一本化できる「唯一の参照元」でした。 課題起点のコンテキスト vs 複雑なセットアップと限られた MAUI 対応 Skimmer はいわゆる定番の APM ツール群を Sentry と比較しました。各ツールを .NET Framework と .NET（Core）のバックエンド両方に加え、Web の React、モバイルの .NET MAUI にも組み込みました。 従来型APMツールで起きたこと 基本を超えるとインストゥルメンテーションが破綻した「シンプルな例を超えた途端、セットアップが面倒になりました。.NET Framework 4.8 と .NET（Core）でドキュメントの整合性が取れていない上、MAUI 対応は限定的、あるいはロードマップにも載っていませんでした。」 […]
【MCPサーバー構築後】Sentryでクライアント・ツール・リクエストを追跡
Article by: Sasha Blumenfeld, Miguel Betegón 本日（2025/8/14）より、MCP SDK 実装に計測コードを1行入れるだけで、サーバーサイド JavaScript SDK ベースの MCP サーバーの多くを計測できるようになりました。 これを導入すれば、MCP 実装全体にわたって、プロトコルの利用状況、クライアントの利用状況、トラフィック、ツールの利用状況、パフォーマンスといった詳細を確認できるようになります。 2025年の初めに私たち自身の MCP（Model Context Protocol）サーバーを公開した際の目的はシンプルでした。AI エージェントが Sentry のコンテキストを使って、ユーザーのアプリケーション上の問題をリアルタイムにデバッグできるようにすることです。 共同創業者の David Cramer も、有名な辛口コメントをシェアしているように、標準が頻繁に変わる新技術を前提に開発するのは簡単ではありません。 ここ数か月の間に、MCP が Streamable HTTP に標準化され、OAuth サポートが改善され、新しい仕様（spec）が導入されるなど、（控えめに言っても）多くの「調整」が行われていくのを見てきました。 ユーザーが簡単に導入できること、そしてユーザーベースが直面する複雑なユースケースをサポートすることを念頭に、MCP サーバーを「最先端」で構築してきました。リモートホストされるステートフルな MCP サーバー、OAuth のサポート、Seer や自然言語検索といった機能の追加など、最先端の要素に踏み込むことには、モニタリングとオブザーバビリティの面で固有の課題が伴いました。 それに加えて、Sentry の規模もあり、MCP サーバーの利用は非常に速いペースで増加しました。数千のユーザーが利用し、月間 5,000 万リクエスト（そして増加中）に達しています。 Sentry MCP サーバーを構築する中で、MCP サーバー監視におけるギャップがどこにあるのかを把握し始めました。エラーの詳細や MCP 内で現れる厄介なエッジケースの詳細を捉えるのは容易ではありません。ツール呼び出しにおけるパフォーマンス問題は診断が難しく、さらにツール呼び出しの特定の入力・出力に関する課題も、MCP の監視という観点では現時点で未成熟な領域です。 […]
【LogTape & Sentry】トレースに紐づく構造化ログ
Article by: Kyle Tryon アプリケーションがちょっとした個人開発から、多くのユーザーに使われる複雑な分散システムへと成長していくにつれて、従来の console.log に頼ったデバッグ手法では通用しなくなります。本当に観測可能なシステムを構築するには単なるテキストログから、構造化されクエリ可能で、トレースに紐づくイベントへと移行していく必要があります。 要点：ログ戦略の転換 多くの人はログをパンくずのように扱い、各行が実行されたことを確認したり、デバッグのために出力結果を記録したりします。ところが本番環境では、そのパンくずはすぐにノイズの山になります。必要なのは処理の過程を逐一ログに残すやり方から、マイルストーンをログに残すやり方へ切り替えることです。 ノイズを取り除く：ノイズを生み、クエリや相関が難しい「薄い」ログから離れましょう。 高カーディナリティを受け入れる： タスクの進行に伴って積み上がる「厚い」コンテキストをログに詰め込みましょう。ユーザーID、注文ID、カート情報などを含め、任意のイベントについて必要なデータをクエリできるようにします。 点をつなぐ： Sentry を使ってログをトレースに紐づけたままにし、各ログをそれを引き起こした特定のリクエストへ紐づけます。 ログの洪水：なぜ本番環境では console.log が通用しないのか ログが集中管理されなくなり、時系列で追えなくなった瞬間に console.log は破綻します。複数のユーザーとサービスが同時に動く本番環境では、ログはすぐにさまざまなイベントが入り混じったストリームになってしまい、特定の1リクエストについて何が起きたのかを復元する明確な手がかりがなくなります。 関連するログ同士をつなぐ共通のトレースと、フィルタ可能で有用なデータがなければ、こうしたログは本番環境では実質的に役に立たなくなります。 LogTape と Sentry で本番品質のロギングを実装 Sentry はトレースに紐づくロギングを提供します。トレースを使えば、1つのリクエストに関する全体のコンテキスト（そのリクエストに紐づくログも含む）を確認できます。これにより特定の issue やリクエストに関連するトレースとログを簡単にクエリできるようになります。 さらに Sentry Logs には、属性や構造化データをもとにログを検索できる強力なクエリエンジンがあります。そこから検索結果に基づいてアラートやダッシュボードを作成することも可能です。 LogTape はあらゆる JavaScript ランタイム向けの軽量なロギングライブラリです。LogTape のようなロギングライブラリを使うと、コードに計測を組み込み、自動でリッチな構造化ログを出力できるようになります。また「log sink」を使って、それらのログを Sentry に送信できます。 構造化ログとは、単なる文字列ではなく、定義されたプロパティを持つ構造化オブジェクトとしてログを扱う形式です。 これにより本番環境でのデバッグにおいて、ログから必要なデータを見つけて可視化するための強力なクエリやフィルターを作成できます。 LogTape の構造化ログマニュアルからの例 クイックスタート：Next.js […]
よくある Unity エラーと対処法
Article by: Abuld D. Unity では、開発中に思いがけない挙動に出会うことがあります。ホットリロード直後のプレイモードのフリーズ、突然広がるピンク一色のマテリアル、あるいは「transform はずっと null でしたよ」と丁寧に思い出させてくるスタックトレースなど。そんな瞬間にスプリントの残りが崩されないように、本記事では実行時によくある厄介者を4つに絞り、それぞれをどう再現し、どう見分け、どう直すかを具体的に紹介します。 扱う内容は次のとおりです。 NullReferenceException: Object reference not set to an instance（オブジェクト参照がインスタンスに設定されていません） IndexOutOfRangeException: Array index problems（配列／リストのインデックスが範囲外です） MissingComponentException: Component not found（必要なコンポーネントが見つかりません） MissingReferenceException: Destroyed object access（破棄済みオブジェクトへの参照にアクセスしています） 具体性を担保するために、まっさらな HDRP サンプルプロジェクト上で各エラーをすべて作り直し、余計なものを省いた SentryCube スクリプトを組み込んで、問題（と修正）がリアルタイムでどう起きるかを確認できるようにしました。コードをそのままコピーしても良いですし、コンソールに出ている内容に一致するスニペットだけ流し読みしても良いですし、解決策セクションに飛んでも構いません。とにかく、より早く開発に戻れるやり方で進めてください。 1. Unity で NullReferenceException（Object reference not set to an instance）を修正する方法 このエラーはスクリプトが null の参照を使おうとしたときに発生します。ゲームのコンソールやログファイルでは、通常次のような表示になります。 UnassignedReferenceException: The […]
【View Renderer V2】iOS Session Replay パフォーマンスを向上
Article by: Phil Niedertscheider モバイル向け Session Replay を一般提供（GA）にした後、採用は急速に進み、より多くのフィードバックが私たちのもとに届くようになりました。 あまり良くない話ですが、Apple SDK のユーザーから、古い iOS デバイスでの Session Replay のパフォーマンスオーバーヘッドにより、アプリが使い物にならなくなったという報告がありました。 そこで私たちは原因を突き止めるための旅に出て、ベンチマークで 4〜5 倍良いパフォーマンスを得られる解決策を見つけました。モバイルの Session Replay の内部で何が起きているのかを理解するために、技術的な詳細に入る前に、まずモバイルの画面録画がどのように動作するのかを見ていきましょう。 フレームレートをひと言で言うと 画面録画とは、フレームと呼ばれる高速で表示される多数の画像から成る動画です。人間の目は 1 秒あたり約 60 フレーム（フレームレート）を処理でき、これはヘルツ（1 Hz = 1 秒あたり 1 単位）で測定され、動いている映像の錯覚を生み出します。フレームレートは用途によって異なり、映画では 24 Hz、ゲーミング向けの PC ディスプレイでは 144 Hz まであります。 より高いフレームレートはより滑らかな動画を生みますが、重大なトレードオフを伴います。 同じ動画の長さでも、ストレージとネットワーク帯域の消費が増える 1 秒あたりに処理すべきフレームが増え、性能を維持するにはより強力なハードウェアが必要になる フレームレートを最小まで下げると、録画はストップモーション動画のように見えます。このスタイルのとても良い例は、この YouTube 動画で見ることができます。フレームは単に連続した写真にすぎませんが、それでも動いている写真のように感じられる、つまり動画です。 これは本質的に、私たちがモバイルの Session […]
【Sentry MCP ＆ Cursor】デバッグをもっとスマートに
Article by: Cody De Arkland 本番の障害を Cursor でデバッグしていますか？ おそらくワークフローはこうです。Alt-Tab で Sentry に切り替え、エラーの詳細をコピーし、IDE に戻って Cursor に貼り付ける。コンテクストスイッチを 3 回もした頃にはフローは途切れ、実際の本番環境やコードベースを理解しているとは言えない… 一般的な提案を眺めることになります。 Cursor と LLM は良いコードを書けますが、本番のエラー、ユーザーの操作フロー、影響指標、デプロイ履歴、さらにはアーキテクチャのことも知りません。そのコンテクストがあるかどうかで、「パターンマッチングと一般的なエラーハンドリングを提案します」と「この API エンドポイントは、隣接するサービスの 1 つにデプロイされた昨日のコミット以降、ユーザーの 47% で失敗しています」という差が生まれます。 Sentry MCP Server を使えば、Cursor は Sentry が持つ、本番（および開発）アプリケーションのパフォーマンス周辺のコンテクストに直接アクセスできます。エラーメッセージやログをコピー＆ペーストしたり、分散トレーシングの構成やスタックトレースをチャットで説明しようとしたりする必要はありません。MCP は実際の問題を調査し、その影響を理解し、実際の本番コンテクストにもとづいて修正案を提案できます。 ただし、アプリケーションのアーキテクチャの複数領域にまたがるような複雑でシステム全体に及ぶ問題に直面したとき、「AI Debugger」として本領を発揮するのは Sentry の Seer です。Cursor 単体でもピンポイントな修正は得意ですが、MCP Server と併用する場合でも、問い合わせたアプリ性能の各要素を手作業で引き出して自分でつなぎ合わせる必要があります。しかも、MCP の結果が一貫しないこともあります。MCP はまだ完璧には程遠いのです。Seer はプロジェクト全体を横断して、自動的にパターンを見つけ、Sentry のコンテクストに対して深い調査を行い、根本原因の特定と実際に使える解決策の構築に取り組みます。 幸い、私たちは Sentry MCP […]