ADWAYS DEEE で Web アプリケーションエンジニアをしています、新卒 2 年目のあーるです。普段はモダナイズチームでレガシーシステムの改善・モダナイズに取り組んでいて、ようやく仕事にも慣れてきたかなという頃合いです。

監視ツールの移行作業と New Relic Advance NEXT をみてきて、Observability の世界に足を踏み入れました。この記事はその一歩目です。

New Relic 移行のはじまり

降ってきた移行作業

ある日エンジニア向けの Slack チャンネルに CTO からこんな投稿がありました:

エンジニアのみんなへ、NewRelicの移行判断を考えています。検証をリッチにやって決断したというよりかは、契約プランでの魅力や既存の課題（テスト環境で気軽に使えない、APM・RUM*1とか一歩踏み込んだ利用がしづらい）という点を評価しました。

この時点では、「ふ〜ん」程度でした。日々の開発の傍でアラートの設定など監視まわりの作業自体はやっていましたが、監視そのものについて深く考えたことはまだなかったのです。

その数日後……

すみません。NewRelicへの監視サービスは見送る方向で行きます。

どっちやねん。そうか、New Relic にはならないのか。でも組織運営上、色々考えているんだな〜なんて呑気に思っていたら

やっぱりNewRelicで行きます。

……こうした紆余曲折あり、弊社では既存監視ツールから New Relic への移行作業が始まりました。

移行作業の進め方

移行作業は、基本普段の担当領域をそのまま各チームが受け持つ形で進めました。（一部例外として AWS Integration などの横断的なものはクラウド担当のチームが取り扱ったりしました）

移行の順序としては

既存監視ツールだけじゃなく New Relic にもログを送信する
既存監視ツールに存在したモニター、アラートを New Relic にも設定する
既存監視ツールへのログ送信を終了する

というフェーズで 2 ヶ月かからないくらいで社内の全アプリケーションの移行が完了しました。
移行作業が長引くほど New Relic と既存監視ツールに2重でお金を払う無意味な期間が増えるため、急ぎました。

New Relic Advance NEXT

そんな移行作業に追われる最中、New Relic の方から紹介されたイベント New Relic Advance NEXT (2026/05/26) に行ってきました。

テーマは SUPERHUMAN時代。Observability と AI の力によって、エンジニアは代替されるのではなく、今まで以上に高い生産性を持って本質に取り組む、というシナリオらしいです。

また何やら New Relic の新しい製品とか機能について聞くイベントかなあと思っていました。過去行った社外イベントは AWS Summit 2025 くらいで解像度が低かったのもありますが New Relic を使えていない自分に有益な情報があるかは不安でした。

ですが、蓋を開けてみれば、Observability という言葉が強く印象に残っています。今回のイベントは7割これだったんじゃないかなと思うくらいでした。

そこで印象に残ったものを2つあげておきます。

ここまでの話に AI は出てこない

New Relic は監視ツールということで、当然ながら障害時の対応、ログやメトリクスの話などがされました。

例えば以下のような問いに、みなさんの担当しているサービスは自信もって答えられるでしょうか？

ユーザーがサービスを快適に使えているか分かりますか？
発生したエラーはサービスの維持にどれほどの影響を与えているか分かりますか？
特定のユーザーしか発生しないようなエラーの再現を即座にできますか？
エラーやパフォーマンス劣化の原因をコードレベルで特定できますか？
本番デプロイ後の振る舞いに問題がないと自信もって答えられますか？

監視を設ければ、一定信頼のできるサービスになるかもしれません。
ですが Observability によって、監視だけでは把握できないシステムの状態をリアルタイムで理解できます。

そんな Observability によって解決できる説明を聞いた直後、登壇者の方からこんなセリフが飛び出しました。

「ここまでの説明で、AI という言葉を使っていないことにお気付きでしょうか」

自分が関わるサービスで「流石にそこまではできていないなあ」と思った課題は AI 導入以前の話でした。

別のセッションでは「AI は増幅器である」という話もありました。適切なデータがなければ、AI には増幅するものがありませんし逆に不十分な、あるいは汚いデータからは変な結果しか出てこないと。

AI を使って自動で障害を適切な形で解決してくれる理想の世界！なんていう以前にこれからの課題は全て Observability によって解決できる範囲のことだったのです。

Observability を育てていく

もう1つはパナソニックコネクトさんの事例紹介です。

「Observability は入れて終わりではない。プロダクト改善に合わせて使い方を育てる」

というテーマで、New Relic 導入後にどのような流れで Observability を実践したかを解説してくれました。

可視化で現状を把握する
- アラートやトレース、ダッシュボードを作成
データに基づくUI／UX改善
- 実装した機能が使われていないことが発覚
- データを元に改善判断
迅速な障害対応
- 開発が進みアプリが複雑化、障害発生
- Observability をしっかりしていたので迅速な対応
不具合運用のフロー見直し
- 緊急度の低いアラートの放置が目立ってくる
- 自動割り当てなどのフロー改善
さらなる可視化の拡大
- ビジネス部門とともに、利用実態がみえる指標を考えるフェーズへ

と簡単に挙げましたが、節々に苦労が見えます。
特にObservability の充実の結果、開発した機能が使われていないことが判明したのは実に悲しい話です。
ですがそれを感覚ではなくデータに基づいて判断できるという利点も垣間見えますね。

この話は、正直聞いた当時の私にとっては先のさらに先の話でした。なにせ移行作業中でしたから。

ただ、裏を返せばその場所へは地続きなのだと気付かされました。
ある地点で Observability が自チームのサービスに導入できたと言えても、この事例から分かるようにそれで終わりではありません。
地道に進めていく改善の1つに Observability の考え方があるんだなと気付かされた発表でした。