小規模から中規模へ
構造化ログからはじめる信頼性の担保
Kaigi on Rails 2025
PLEX / 種井覚道
自己紹介
そのログ活用できていますか?
今日話すこと
- 信頼性向上の第一歩としての構造化ロギングの有用性
- Railsアプリケーションに構造化ロギングを導入する際の課題とアプローチ
- Railsと構造化ロギングのこれから
ログについて整理
ログについて整理
ログとは? その①
“基本的には連続した文字列のことで、(可能なら)いつイベントが発生したのかを示すタイムスタンプが関連づけられたものです。”
引用: 入門監視

ログについて整理
ログとは? その②
- 可能な限りイベントの発生時刻(タイムスタンプ)が打刻された文字列データ
- 測定値であるメトリクスよりも多くの情報をもたせることができる
- 機械的に対象の情報を抽出したい場合には、何かしらパースする必要がある
ログについて整理
構造化ログと非構造化ログ
構造化ログ
- 各フィールドについて、key,value で明確にマッピングされているもの
- 機械が解釈しやすい形式
非構造化ログ
- 各フィールドについて、key,value で明確にマッピングされていないもの
- 人間が解釈しやすい形式

ログについて整理
ログの用途についての分類
- 監視: システム障害やパフォーマンスの低下が発生したときに気付ける
- 調査: エラーやパフォーマンス低下の原因特定、不具合時の影響範囲がわかる
- 分析: 未知の情報を探索したい
- 監査: 法務観点などから保存することが定められているログ
参考: Webアプリケーションのログに関するいくつかの考察
背景
背景
Plex JobというHRプラットフォームを作っています
- 求人サイト/ATSはじめ、社内の人材マッチングの効率化ツールなど複数のプロダクトやシステムを開発・運用
- モノリシックなWebアプリケーションであり、いずれもRails(APIモード)が使われている
背景
アプリケーションの構成

背景
立ち上げから4年ほど経過し成長フェーズに
- サービスの利用者数の増加
- システムの複雑化
- 社内外の複数システムとの連携
- 取り扱う職種領域の拡大
背景
信頼性がより求められるフェーズに
- 不具合発生時の損失が大きい
- 復旧に向けた調査や事後対応をはじめとした運用コストの増加
👉 ある時点でのアプリケーションの状態について迅速に、また詳細を知る必要がある

背景
監視・調査&復旧業務の効率化
監視ツールにより、アプリケーション監視や調査を効率的に行うことができる
背景
監視ツールと構造化ログ
👉 Datadogをはじめとした監視ツールは「構造化ログ」を取り込むことで、上記のようなログベースの機能に応用することが可能
背景
当時のアプリケーション監視
- アプリケーションからはAPMやログは収集されており、APMベースの一部の機能は使えていた
- ログについては非構造化ログとして収集されていた
- ログがツールから認識されておらず、全文検索する程度の活用に限定されていた
👉 収集しているログを活かしきれていない状態
背景
ここまでの話しを整理
- 成長期のサービスにおいては信頼性への関心が高まるが、監視や監視ツールに明るいメンバーが必ずしも在籍しているとは限らない
- ゆえにログの収集や活用が適切に行われていなかったり、知見のない中でそれらを模索していく必要がある
- ログはメトリクスと並んでシステムの状態を知るための重要な情報源であり、ツールからの活用において構造化(機械が解釈しやすいこと)はとても重要なポイント
背景
👉 構造化ロギングを行うだけでも
信頼性の担保を見据えたログの活用ができる
背景
「監視」と「調査」のためのログ収集
- アプリケーションを構成する各サーバープロセスで構造化ログが出力されている状態にする
- 監視ツールのログベースの機能に合わせてログをフォーマットする
背景
「監視」と「調査」用途のログ収集と活用

Railsアプリケーションのログを
構造化する
Railsアプリケーションのログを構造化する
構造化手法の選定と導入
大きく分けて2つ
- gemの活用
- Formatterをカスタマイズして、ActiveSupport::Loggerに設定する
Railsアプリケーションのログを構造化する
Semantic Logger Rails を採用
- メンテナンスが継続的にされている
- インストールするだけで構造化されるため導入が簡単
- Rails.loggerおよび、フレームワークから出力される各種ログイベントを構造化してくれる
Railsアプリケーションのログを構造化する
構造化手法のデファクトスタンダードがない問題
- Kaigi on Rails 2022
- Logrageの次のスライド
Railsアプリケーションのログを構造化する
Railsアプリケーションのログを構造化ロギングに対応させることができた!!
Railsアプリケーションのログを構造化することができた
→ ただし、運用をはじめてみると一部の要素が漏れていたことがわかった
Railsアプリケーションのログを構造化する
Rakeタスクで発生した例外が構造化されていない


Railsアプリケーションのログを構造化する
Rakeタスクで発生した例外が構造化されていない

Railsアプリケーションのログを構造化する
検討: 3つの方法
- begin … rescue … end でtask内の処理を囲う
- Rake にパッチをあてる
- at_exit を使用する
Railsアプリケーションのログを構造化する
どの方法で実装するか?
今回は保守性を考慮して、Rake にパッチをあてる方法が落とし所としてはよさそうだという判断となりました。
Rake にパッチをあてる

Railsアプリケーションのログを構造化する
begin … rescue … end で処理を囲う

Railsアプリケーションのログを構造化する
at_exit を使用する

Railsアプリケーションのログを構造化する
Rakeにパッチをあてる
https://github.com/ruby/rake/blob/79bf96f9aa3219ce87a4979e78fb206a29d18dac/lib/rake/application.rb#L235を参考にdisplay_error_messageメソッドにモンキーパッチを当てることで実装を行いました。
Railsアプリケーションのログを構造化する
パッチの例

Railsアプリケーションのログを構造化する
結果
{"host":"004c21fd7993","application":"Semantic Logger","timestamp":"2025-07-24T06:23:03.354088Z","level":"fatal","level_index":5,"pid":6481,"thread":"1816","file":"/workspaces/sample/rakefile","line":17,"name":"Rails","message":"bin/rails aborted! Tasks: TOP =\u003e hoge:fuga","exception":{"name":"RuntimeError","message":"","stack_trace":["/workspaces/sample/lib/tasks/hoge.rake:3:in 'block (2 levels) in ..."]}}
ログのフォーマット
ログのフォーマット
ツールの仕様に合わせてログをフォーマットする
- Datadogのエラートラッキング機能は、予め指定されたスキーマの構造化データから自動でエラーを検知して、issueとしてエラートラッカーに起票してくれる機能がある
- 機能を有効化するには?
- kind,message,stack の3つの属性がerror属性配下に存在している
- ログのlevel属性が指定されたレベル(ERROR, CRITICAL, ALERT, or EMERGENCY)である必要がある
→ 監視ツールで定められた要件を満たす形に構造化ログをフォーマットする必要がある
{
...
"level": "ERROR",
"error": {
"kind": "...",
"message": "...",
"stack": "...",
}
...
}
どこでフォーマットするか?
- Semantic LoggerのFormatterをカスタマイズする?
- Datadogでは収集後のログをフォーマットすることもできる
→ ログのフォーマットに関する設定がアプリケーションと監視ツールにまたがってしまうことや、SWEを中心としたチームであることから、前者を選択
→ 社内に専門性のあるメンバーやチームがある場合は、監視ツールでフォーマットするのもあり
ログ活用の現在
監視
調査
- ログの検索性向上
- APMとのログの紐づき
- 障害時のデータパッチなど、スクリプトからの利用も容易に
おまけ | Rails8.1と構造化ログ
- どのようなインターフェースと機能になりそうか?
- 既存のログ機構を置き換えられそうか?
Railsでの構造化ログ標準化やエコシステム進化の期待
課題に対して取り組んできた内容と、Railsへの期待が対応している形にしたい
- 構造化ログ
- Railsでの構造化ログ標準化への期待
- (https://github.com/rails/rails/issues/50452)[https://github.com/rails/rails/issues/50452]
- RakeとRails統合
まとめ
- 信頼性向上の一歩目として監視、調査用途のログを出力することのススメ
- Railsアプリケーションの各サーバープロセスにおいて、監視ツールで求められるフォーマットとしての構造化ログの重要性
- アプリケーションエンジニアを中心としたチームでも取り組むことが可能。専門性のあるチームに良い形でバトンを渡すことができる
- Railsアプリケーションのログ出力を構造化する際にはいくつか課題があり、チームの状況に合わせて採用する技術を検討する必要があること
- 上記に課題については、構造化ログをはじめとして一部Railsがフレームワークとしてサポートする動きがあること(Rails標準機能に乗り換えられるように意識しておく必要がある)