はじめに
こんにちは、ヤプリでiOSエンジニアをしている菅（@Nao_RandD）です。
先日、2025年7月25日(金)に開催されたYapTech Playground #1というイベントで登壇しました。
YapTech Playgroundはヤプリが主催する新しいエンジニア向けイベントです。
記念すべき第1回は「モバイルアプリ開発」をテーマに、iOS/Androidのエンジニアがそれぞれの視点から語り合いました
本記事では、その際に発表した『New Relic ではじめるアプリプラットフォームのオブザーバビリティ』について、内容を解説していきたいと思います。
モバイルアプリの複雑化が進む中で、オブザーバビリティ（可観測性）はますます重要になってきていると感じています。
そこで、ヤプリで New Relic を導入した背景から、導入時のカスタマイズ、そして実際の運用体制まで、具体的な取り組みをご紹介します
本記事が、皆さんのモバイルアプリ開発におけるオブザーバビリティ向上のきっかけになれば幸いです。
なぜオブザーバビリティに取り組むのか
早速ですが、なぜ今ヤプリでオブザーバビリティに取り組むことになったのか、その背景からお話しします。
そこには、多くのアプリを一つのコードベースで提供するプラットフォーマーならではの課題がありました。
プラットフォーマー特有の複雑さ
ヤプリは、高品質なアプリをノーコードで提供できるプラットフォーム「Yappli」を開発・運営しています。
一つのコードベースから様々な機能を組み合わせたアプリを作成できるようになっており、現在は約900アプリ（2025年9月時点）を提供しています。
コードベースが同じプラットフォームでは個々のスクラッチ開発が不要になる反面、一つの実装の不具合が複数のアプリに影響を及ぼしてしまう可能性がある、という難しさもあります。
そのため、未然に防ぐことはもちろん、不具合を可能な限り早く検知して影響あるクライアントに連携していくことが重要です。
しかし、複数のアプリを提供するプラットフォームでは、以下のことから事前検知と原因特定が難しいという課題感がありました。
- 多様なアプリ構成: 機能を組み合わせて様々なアプリが作られている
- 複数バージョンの混在: リリースごとに全ユーザーがアップデートを行うわけではないため、ひとつのアプリに複数のバージョンが存在する（強制アップデートはお客様判断）
- サードパーティーSDKとの連携: アプリは様々なサードパーティSDKとも連携しており、外部要因も考慮した動作になる
そこで、これらの課題をオブザーバビリティというアプローチで解決を図ることにしました。
「監視」と「オブザーバビリティ」の違い
課題解決のために重要になるのが、オブザーバビリティ（Observability, 可観測性）という考え方です。
よく似た言葉に監視（Monitoring）がありますが、両者は少し目的が異なると自身は解釈しています。
| 監視 (Monitoring) | オブザーバビリティ (Observability) | |
|---|---|---|
| 目的 | システムが正常か異常かを判断する | システムに「なぜ」その問題が起きたのかを問い、理解する |
| 対象 | 既知の未知（想定内の問題） | 未知の未知（想定外の問題） |
| 例 | CPU使用率が90%を超えたらアラート | 特定の操作でAPIエラーが多発している原因を深掘りする |
簡単に言うと、監視は「問題が起きていること」を検知するのが得意ですが、オブザーバビリティは「なぜ問題が起きているのか」を調査・理解するための能力、といったイメージかと思います。
オブザーバビリティにより、先ほど挙げたような再現の難しい問題に対しても、多角的なデータからアプローチできるようになります。
ヤプリが目指す状態
ヤプリがオブザーバビリティを構築することで目指しているのは、単にクラッシュやパフォーマンス低下といった不具合を減らすことだけではありません。
ユーザーに影響が出る前にプロアクティブに検知・修正したり、パフォーマンスのボトルネックを特定して、長期的な視野でプラットフォーム全体のユーザー体験を向上させることを目指しています。
最終的には、データに基づいてプロダクトの意思決定を行い、より良い開発サイクルを実現していきたいと考えています。
New Relicの導入
オブザーバビリティを整備する背景と重要性についてお話ししたところで、次に私たちが具体的なツールとして何を選んだかをご紹介します。
ツール選定の結果、ヤプリではNew Relicを採用しました。
なぜNew Relicを選択したのか？
New Relicではひとつの管理画面で、
- プラットフォーム全体の計測結果をひとつのダッシュボードから確認できる
- パンくずリスト（詳細は後述）からユーザーの行動履歴を追える
という点から、プラットフォーム全体で不具合が発生していないかを把握しやすく、原因特定の情報を得やすいと判断して採用しています。
また、サーバー・インフラチームで既に導入実績があり、ベンダーとの関係値が築けていた点も大きな後押しになりました。
ヤプリのサーバー・インフラチームでのNew Relic導入に関してご興味ある方は、以下の記事もぜひ！
モバイルであればFirebaseのCrashlyticsやPerformanceが多くの場合、まず選択肢として浮かびます。
しかし、Firebaseでは基本的にアプリ単位でのプロジェクト管理が必要になります。複数プロジェクトを横断して分析するにはBigQueryへデータをエクスポートするなどの工夫が必要になります。
また、クラッシュやパフォーマンスだけでなく、ユーザーがどのような操作を経てその事象に至ったのか、という導線までを分析するのは少し難しい印象でした。
双方のメリット・デメリットを鑑みて、導入目的との一致が大きいNew Relicを採用しました。
New Relic iOS Agentの組み込み
ここからは、実際にNew Relicを導入した流れについてご紹介していきます。
New Relicではモバイル向けのSDKが提供されています。
公式ドキュメントに従って数行の初期化コードを呼び出すだけで、基本的なセットアップは完了します。
import NewRelic // トークンを渡して計測開始 NewRelic.start(withApplicationToken: "[New Relic Token]")
これだけで、アプリの様々なデータがNew Relicで計測できるようになります。
導入時に追加で行ったこと
デフォルトで取得できる情報に加えて、より詳細な分析を行うため、カスタム属性とパンくずリストによる行動分析も行いました。
1. カスタム属性をセット
カスタム属性をセットすることによって、OSや通信環境などデフォルトで取得する以外の情報を追加することができます。
参考： カスタム属性を作成する | New Relic Documentation
ヤプリではSKUという識別子によってプラットフォームで提供するアプリを管理しているため、計測データに追加することでどのアプリで事象が発生したかを把握できるようにしています。
// アプリを識別する情報をセット NewRelic.setAttribute( "SKU", value: "XXXXXXXXX" // アプリの識別子 )
2. パンくずリストによる行動分析
「パンくずリスト」を記録することで、ユーザーの行動分析を行うことができます。
参考： Record breadcrumbs | New Relic Documentation
クラッシュなどの不具合に至るまでに、ユーザーがどのような操作を行ったかを時系列で記録することができます。
// 処理A NewRelic.recordBreadcrumb( "処理A", // パンくずに記録する名称 attributes: attributes // 必要な属性追加 ) ・・・ // 処理B NewRelic.recordBreadcrumb( "処理B", // パンくずに記録する名称 attributes: attributes // 必要な属性追加 ) ・・・ // ここでクラッシュ💥 （処理A→ 処理B を踏んでクラッシュしたことがわかる）
これによって、どの処理までは正しく動作していたかや、どのような操作を行なったかを把握することが可能になります。
導入後の運用と今後の展望
オブザーバビリティ基盤を構築したことで、私たちはこれまで見えなかった多くの課題をデータとして捉えることができるようになりました。
しかし、ツールを導入して終わりではありません。ここからは、そのデータをいかに活用していくかという「運用」のフェーズについてご紹介します。
Slack連携によるプロアクティブな問題検知
まず取り組んだのが、New RelicのError InboxとSlackの連携です。
New RelicではError Inboxからアプリで現在起きているクラッシュやその他の不具合を確認することができます。
ただ、New Relicの管理画面を常に開いて確認することは現実的ではありません。
そのため、ワークフロー自動化ツールのZapierを用いて、「特定のクラッシュが24時間でXX件を超えたらSlack通知する」といった仕組みを整備しています。
Slackは日常的に業務で使うツールなのでアラート検知の初動を早めることができ、お客様からのお問い合わせをいただく前に問題をプロアクティブに検知するという目的を満たしやすくなります。
見えてきた新たな課題
一方で、運用していく中で新たな課題が見えてきたのも事実です😇
- ノイズとの戦い: アラートの閾値設定が甘いと、重要度の低い通知が頻発し、本当に重要なアラートが埋もれてしまうことがあります。アラートを育て、常にチューニングし続ける必要があります。
- 根本原因の特定: データは「何が起きているか」を教えてくれますが、「なぜ起きているか」の根本原因を特定するのは、やはり開発者の知見が必要です。データを元に仮説を立て、検証するサイクルが重要だと感じています。
- 文化の醸成: 最も重要で難しいのが、この仕組みをチームの文化として根付かせることかもしれません。データを見て、次のアクションに繋げるという意識をチーム全体で高めていく必要があります。
今後の展望
まだまだ道半ばですが、今後はさらにオブザーバビリティを強化させていきたいと考えています。
今後のステップとして、New Relicが提唱する「オブザーバビリティ成熟度モデル」が参考になります。
現在はアラートの整備が中心ですが、今後はパフォーマンスの改善や、より良いユーザー体験の提供へと繋げていくことを目指していきます。
- カスタムデータの活用: ユーザーIDや利用プランといった、ヤプリ固有の情報をカスタムデータとして送信し、より詳細な分析（例：特定のプランのユーザーだけエラーが増えているなど）を可能にする。
- SLI/SLOの導入: SLI/SLO（サービスレベル指標/目標）を定義し、よりデータドリブンな品質改善サイクルを回していく。
- 分散トレーシングの活用: モバイルアプリからバックエンドまで、リクエストの流れを追跡できる分散トレーシングを活用し、問題発生時の原因切り分けをさらに迅速にすることを目指す。
最後に
本記事では、『YappTech Playground #1』での登壇内容を元に、ヤプリにおけるアプリプラットフォームのオブザーバビリティについてご紹介しました。
モバイルアプリが抱える課題に対し、New Relicを導入し、データに基づいた品質改善の第一歩を踏み出せたかと思っています。
オブザーバビリティへの取り組みは、一度作って終わりではなく、アラートをチューニングしたり、新たな指標を追加したりと、継続的に改善していく活動だと強く感じています。
イベント当日は、多くの方々と直接お話しする機会があり、非常に刺激的で楽しい時間でした。ご参加いただいた皆様、本当にありがとうございました！
ヤプリでは、プロダクトの価値を向上させることに情熱を持つエンジニアを募集しています。この記事を読んで弊社に興味を持っていただけた方は、ぜひカジュアル面談へお越しください！
