こんにちは！kubellで「Chatwork」iOSアプリの開発をしているRikkuma(@Rikkuma_W)です。
今回は、iOSDC Japan 2025のルーキーズLTで登壇した
気づいて！アプリからのSOS 〜App Store ConnectAPIで始めるパフォーマンス健康診断〜
について、その後しばらく運用して感じたことを振り返ってみようと思います。
5分LTという性質上、仕組みの概要が中心になっていたため、
この記事では実際に使ってみてどうだったかや、今後やってみたいことを中心に書いていきます。
本記事は kubellアドベントカレンダー2025 12月19日の記事となります。
iOSDCで話した内容のおさらい
まずは、発表内容を簡単に振り返ります。
LTでは、以下のような内容で登壇させていただきました。
- Xcode Organizer では、起動時間やHang率などのパフォーマンス指標を確認できる
- ただし、普段の開発では毎回意識して見に行く必要がある
- App Store Connect API と GitHub Actions を使って、異常が出た際にチャットにて通知を行う
- 異常が出たら検知できる「パフォーマンスの健康診断」的な仕組みを作る
簡単にまとめると、GitHub Actions で定期的に App Store Connect API を叩き、Regression（前バージョンより悪化した状態）を検知した際に「Chatwork」に通知する、という構成です。
ポイントとしては、
パフォーマンスが悪化した瞬間を見逃さないための仕組みを作る、という考え方です。
そもそもこの仕組みを構築した背景
実は、この仕組みを作る前に、私自身がパフォーマンス起因のインシデントを発生させてしまったことがありました。
インシデント対応が落ち着いた後に振り返ってみると、Xcode Organizer上では、異常な値が検知されていることに気づきました。
そこで、もし事前にこの異常な値を確認できていれば、より早い段階で気づけた可能性が高かったと考えました。
もちろん開発段階で気づけるようにするのが一番ではありますが、ユーザーごとの想定していなかった使い方やデータ量など、
実際にユーザーの手に届いて初めて気づくパフォーマンスの問題も少なくありません。
そのため早期に問題に気付ける体制を作ろうということでこの仕組みを構築しました。
実際に運用してみて良かった点
異常が出たときだけ見に行けばいい
Xcode Organizer を毎回確認する運用は、正直かなり手間です。 今回の仕組みでは、
- 普段は特に意識しない
- 異常が出たときだけ Organizer を見に行く
という形にできたため、運用コストがかなり低いと感じています。
データを見ながら会話ができる
チーム内で、
- 「このリリースから急に悪化していないか？」
- 「この機能追加が影響していそう」
といった話を、感覚ではなく数字を見ながらできるようになりました。
「どのタイミングで悪化したか」が見えることで、対策も打ちやすくなったと感じています。
Organizerを見る文化が生まれた
そもそも、これまでチーム内には「Organizerをちゃんと見る」という文化があまりありませんでした。 しかし、定期的に数値を話題にするようになったことで、
- Organizerにはどのような指標があるのか
- どこを見ると異常に気づけるのか
といった認識が、チーム内に自然と広がっていきました。
これは、当初は想定していなかった良い変化でした。
また、この文化が生まれたことで、悪化している変化だけでなく、改善している変化にも気づけるようになりました。
「どうすれば改善するのか」「どのような変更が悪化につながるのか」といった点について、
チーム内で知見を蓄積していけるようになったと感じています。
その結果、
「どういう実装を行うとHungが発生しやすいのか」
といった観点を、運用上のチェックポイントとして活用できるようにもなりました。
実運用で見えてきた課題
データ量が少ないケースがある
Organizerのデータは、匿名でのデータ提供を許可してくれているユーザー分のみです。
iPhoneは問題ないのですが、iPadなどはそもそもの母数が少なく、
- 数値がブレやすい
- あるバージョンでは Regressionとなるが、次では戻る
といったケースもあり、判断が難しい場面がありました。
Regressionが出ても、原因特定は人力
異常検知自体はできても、
- なぜ悪化したのか
- どの変更が原因なのか
については、結局Organizerを見に行って、そのリリースバージョンを確認してと、自分で調べる必要があります。 ここはまだ、人間が頑張っている部分です。
今後やってみたいこと
AIを使った原因推定
今後やっていきたいこととしては、Regressionが出た際に
- そのリリースに含まれる変更内容と突き合わせる
- 「この変更が原因の可能性が高い」と候補を出す
といった 原因調査の初動をAIに任せる仕組みです。完全自動でなくても、 調査のとっかかりを作れるだけでもかなり楽になると思っています。
異常と対策の知見を溜める
もう一つは、
- どんな異常が出たか
- どう調査して
- どう対策したか
を記録として蓄積していくことです。
同じような数値変化が出たときに、過去の対応をすぐ参照できる状態を目指したいと考えています。
今後対応までAIに任せたいとなった際にこのデータは役に立つかなと感じています。
まとめ
実際に運用してみて感じたのは、
- 完璧な監視より、早く気づける仕組み
- 常に見るより、話題に上がる状態
- 数字があることで、会話の質が変わる
という点でした。
個人的にはなるべく人間が手を動かす必要がある仕組みではなく、人間が受動的でも問題ない仕組みを構築したいという考えがあり、
「健康診断を習慣化する」アプローチとして、この仕組みは今後も育てていきたいなと思っています。
ここまで読んでいただき、ありがとうございました！
良いクリスマスを🎄🎅
