はいチーズ！システム/はいチーズ！ノートにおける New Relic の活用

千株式会社では、保育園向けの写真サービスを運営しています。

今回New Relicを導入したのは、ICT領域のサービスです。

ピーク時には毎分18,000リクエストを処理するサービスなのですが、2025年の夏頃まで、監視体制はかなり心もとない状態でした。

Zabbixで定点監視をして、CloudWatchでAWSリソースの数値を見る。やっていたのはそれだけです。アプリケーションの中で何が起きているのか、ほとんど見えていませんでした。

一番つらかったのは障害対応です。「なんか遅い」「画面が表示されない」という問い合わせが来てから、ログをgrepして、CloudWatchのメトリクスを見て、「たぶんこのあたりが原因では」と当たりをつけて調べていく。原因特定まで30分から1時間かかるのが当たり前でした。

リリースにも影響が出ていました。アプリケーションの内部状態が見えないので、リリース後に何が起きるか予測できない。結果として、リリースは週1回、19時限定、PdMが立ち会える時間帯のみという運用に縛られていました。「もっと頻繁にリリースしたい」という声はチーム内にずっとあったのですが、監視体制が追いつかない以上、リスクを取れなかったというのが正直なところです。

こうした状況を変えるために、オブザーバビリティツールの導入を本格的に検討し始めたのが2025年8月のことでした。

• Datadog
• OpenTelemetry+Grafana(セルフホスト）

決め手は大きく4つです。

まず、料金体系です。New Relicはユーザー数とデータ量ベースの課金で、ホスト数に依存しません。サービスが成長してサーバーを増やしても、コストが線形に跳ね上がることがない。予算の見通しが立てやすく、社内の承認も取りやすい構造でした。

次に、サポート体制。New Relicでは専任のコンサルタントがついて、導入から活用まで伴走してくれます。オブザーバビリティツールを本格的に入れるのはチームとして初めてだったので、「入れたけど使いこなせない」という状態になることが一番怖かった。手厚いサポートがあるというのは、未経験のチームにとって非常に大きな安心材料でした。

3つ目は、SaaS型で導入のハードルが低いこと。OSS構成のように自前で監視基盤を構築・運用する必要がなく、エージェントを入れればすぐに使い始められます。APMの経験がないメンバーでもキャッチアップしやすい環境だと感じました。

最後に、統合性です。これまでICTではZabbix（定点監視）とCloudWatch Logs（ログ）を組み合わせて運用していましたが、APMもブラウザモニタリングもなく、必要な情報が複数ツールに分散していました。New Relicは、APM、インフラ監視、ログ、ブラウザモニタリング、外形監視、SLO管理まで1つのプラットフォームで完結します。複数ツールを行き来していた状態から、1つの画面でアプリケーションの状態を横断的に把握できるようになることは、小さなチームにとって運用効率の面で大きなメリットだと考えました。

導入後の変化は、想像以上に大きかったです。

一番インパクトがあったのは、APMによるパフォーマンス改善です。New Relicを入れてまず見えたのが、データベースクエリの遅さでした。APMのトランザクション画面でスロークエリが一目瞭然になり、さらにヒント機能がインデックス追加の提案をしてくれました。その提案に従ってインデックスを追加したところ、DBクエリが20倍改善しました。

特に象徴的だったのは、新卒エンジニアが入社2週間で達成した改善です。APMのトレース画面で特定のトランザクションのボトルネックを見つけ、ヒント機能の提案をもとにインデックスを最適化した結果、44.94msだった処理が1.16msに。39倍の高速化です。オブザーバビリティツールの経験がなくても、New Relicが「ここが遅い」「こうすれば速くなる」と教えてくれるので、新卒メンバーでも成果を出せた。これはチームにとって大きな自信になりました。

こうしたクエリ改善の積み重ねで、DBのコストも月間約25%削減できました。パフォーマンスを改善したら結果的にコストも下がるというのは、当たり前といえば当たり前なのですが、New Relicがなければそもそもどこに無駄があるのかすら分からなかったと思います。

障害対応の時間も大きく変わりました。以前は原因特定に30分から1時間かかっていたのが、今は10分以内で特定できます。トレースIDで複数サービス間の処理を追跡できるので、「このリクエストがどこで詰まっているか」がすぐに分かる。当て推量でログを漁る時間がなくなりました。

リリース頻度も週1回から週3〜5回に増えました。APMとSyntheticsでリリース後の影響をリアルタイムに確認できるようになったことで、「何かあればすぐ気づける」という安心感が生まれ、リリースのハードルが下がりました。

最近ではNew RelicのMCP連携も活用していて、AIエージェントとタスク管理ツールを組み合わせることで、問い合わせ対応にかかる時間が半日から10分に短縮されました。個人の作業としては10秒で終わることもあります。

導入がすべてスムーズだったかというと、そんなことはありません。

一番大きなトラブルは、APMエージェントの導入時に起きたパフォーマンス劣化です。最初、同期通信でNew Relicへデータを送信する設定にしていたところ、アプリケーションのレスポンスが目に見えて悪化しました。ピーク時に毎分18,000リクエストを処理するサービスなので、エージェントの通信がボトルネックになってしまった。New Relicへデータ送信を非同期化することで解決しましたが、導入直後に本番のパフォーマンスが落ちたときは正直焦りました。

NRQLの学習コストもそれなりにありました。NRQLはNew Relic独自のクエリ言語で、SQLに似ているとはいえ、独自の関数や構文があります。ダッシュボードをカスタマイズしたり、アラート条件を細かく設定したりするにはNRQLが必要なので、チームメンバーが書けるようになるまで少し時間がかかりました。

もう1つ、ストレージ使用量の増加という問題もありました。最初は「とりあえず全部のデータを取ろう」という方針でエージェントを設定していたのですが、想定以上にデータ量が膨らんでしまった。どのデータをどのくらいの粒度で取得するかは導入初期にちゃんと設計しておくべきだったと反省しています。