本番のRailsアプリケーションで障害調査に時間がかかっている、あるいはコーディングエージェント（AIがコードを読んで修正提案まで行う仕組み）にログ調査を任せたいと考えているエンジニアに向けた記事です。
1件のリクエストが30秒かかった障害調査で、原因特定に必要だった情報がPostgresの処理時間446ミリ秒と外部HTTP通信29.4秒という2つの数字だけだった、という事例があります。この記事では、その調査を可能にしたRails用gem「Wide Events」を導入すべきかどうかを、既存の監視基盤や運用体制と照らし合わせて判断する軸を整理します。
Wide Eventsとは何を解決するツールか
Wide Eventsは、1つのHTTPリクエストやActive Job（Railsの非同期ジョブ実行機構）ごとに、処理中に集めた情報を1つの「ルートスパン」にまとめて記録するRails用gemです。
スパンとは、分散トレーシング（複数のサービスをまたぐ処理の流れを追跡する仕組み）における処理単位の記録のことです。通常、1リクエストの中でDBアクセスや外部API呼び出しごとに小さなスパンが作られ、合計すると数十個に及びます。
紹介されている事例では、1リクエストのトレースに82個のスパンと20,261バイトの属性データが含まれていました。一方でルートスパンには40個の属性、1,420バイトしかありません。
この差が意味するのは、82個の子スパンを1つずつ追わなくても、ルートスパンだけを見れば「どこが遅いか」の当たりがつくという点です。実際の事例では、ルートイベントの合計処理時間30.0秒のうち外部HTTP通信が29.4秒を占めており、そこから該当するPOST処理（28.9秒）まで一気に絞り込めています。
コーディングエージェントは自社のコードベースを検索するのは得意でも、稼働中のシステムが「今どうなっているか」は分かりません。どのアカウントで発生したか、どの機能フラグが有効だったか、DBクエリが何回発行されたか。これらはトレース画面やログ、DB管理画面など複数の場所に分散しています。Wide Eventsは、この分散した情報を1リクエスト=1行のイベントに集約する発想です。
導入を判断する4つの軸
軸1: 既存のオブザーバビリティ基盤との親和性
Wide Eventsは既存のOpenTelemetry（分散トレーシングの標準規格）のルートスパンに属性を追加する形で動きます。すでにDatadog、New Relic、あるいは記事中で使われているClickStack（ClickHouseとHyperDXを組み合わせた自前構築の監視基盤）などOTLP（OpenTelemetryが使う送信プロトコル）に対応した基盤があれば、追加の受け皿を作らずに導入できます。逆にトレーシングを一切運用していない場合は、sink = :log設定でJSON1行のログ出力に切り替えられるため、最小構成でも試せます。
軸2: 障害調査でボトルネックの種類を絞り込む必要性
DBが遅いのか、外部API呼び出しが遅いのか、LLM呼び出しのコストが想定外なのか。こうした「どこが原因か」の一次切り分けに時間を取られているチームほど効果が出やすい設計です。逆に単一のモノリスでDB以外の外部依存がほとんどない場合、切り分けの恩恵は限定的です。
軸3: マルチテナント運用の複雑さ
同じ症状が1つのテナントだけで起きているのか、全テナントで起きているのかを見分ける必要がある場合、リクエスト単位でアカウントIDや機能フラグのバリアントを属性として残せる設計が役立ちます。単一テナントの社内システムであれば、この軸の重要度は下がります。
軸4: 対応バージョンと既存コードベースの改修コスト
Wide EventsはRuby 3.2以上、Rails 7.1以上が前提です。古いRailsバージョン（6系以前）で稼働している基幹システムの場合、まずアプリケーション本体のアップグレードが先行課題になります。gem導入だけを見るとbundle installとbin/rails generate wide_events:installの2手順で完了しますが、属性をどこに仕込むかの設計は開発チーム側の作業として残ります。
選択肢の比較
| 選択肢 | 初期コスト | 向いている場面 |
|---|---|---|
| Wide Events導入 | 低〜中（既存OTel基盤があれば低い） | 複数の外部依存があり切り分けに時間がかかる本番運用 |
| 既存APMのダッシュボードのみで運用 | ゼロ（追加実装なし） | 依存先が少なく既存ダッシュボードで十分な粒度が出ている場合 |
| 独自のログ集約基盤を自作 | 高（設計・保守が自社負担） | OTel非対応の特殊な基盤要件がある大規模システム |
ケース別の推奨
複数の外部API・LLM呼び出し・DBが混在するRailsアプリで、障害時に「どこが遅いか」の一次切り分けに毎回時間を取られているなら、Wide Events導入を検討する価値があります。既存のOpenTelemetry基盤があれば導入コストも小さく済みます。
コーディングエージェントにログ調査や障害の一次対応を任せたいチームでも、同じ理由で有力な選択肢になります。エージェントが読むべき情報を1リクエスト1行に圧縮できれば、コンテキストウィンドウ（AIが一度に読み込める情報量の上限）を節約できます。
一方、単一テナントの社内システムで外部依存がDBのみ、既存のAPMダッシュボードで十分に原因が特定できているなら、新規導入の優先度は低く見て構いません。
あえて見送るべき条件
Railsが6系以前で稼働している基幹システムは、まずアップグレード自体のリスクとコストを検討すべきです。gem導入のためにフレームワークのアップグレードを前倒しするのは、順序として本末転倒になりかねません。
個人情報や機微情報をログに残すことに慎重な規制対象の業務（医療・金融など）では、属性に何を記録するかの設計とレビュー体制がgem導入より先に必要です。記事中でも、ユーザー名やメールアドレス、フリーテキストはデフォルトで記録対象に含めない方針が示されています。この判断は組織のポリシーとして先に固めておく必要があります。
また、リクエスト数が少なく障害調査自体がほとんど発生しないシステムでは、導入・運用の手間に対して得られる効果が薄くなります。
判断に迷ったときの確認手順
実際に試すかどうかを決める前に、以下を確認してみてください。
- 現在使っている監視基盤がOpenTelemetry(OTLP)に対応しているか、公式ドキュメントで確認する
- Rubyのバージョンが3.2以上、Railsが7.1以上か
ruby -vとbin/rails -vで確認する - 直近の障害調査で「原因の種類を絞り込む」までにどれくらい時間がかかったか、過去のインシデント記録を振り返る
- ステージング環境で
sink = :log設定を使い、実際のリクエストで出力されるJSON1行の内容を見てみる
まとめ
Wide Eventsは、複数の外部依存が絡む障害調査で威力を発揮する設計です。既存のOpenTelemetry基盤があるか、Rails 7.1以上で稼働しているかをまず確認してください。
単一テナントで依存が少ないシステムや、Railsのバージョンアップが先行課題のシステムでは、優先度を下げて判断して問題ありません。まずはステージング環境でsink = :logを試し、出力されるJSON1行の情報量が自分たちの調査に十分かを見極めるところから始められます。