齋藤：サービスのコアは10年間変わっていないのですが、お客さまが増えるほど「サービスを落とせない」という重責が年々増してきました。落とさないためのインフラのメンテナンス頻度は、人が増える前と比べて2.5倍ほどになり、アプリケーションのパフォーマンスも無視できなくなってきました。

実は、創業から3〜4年目あたりに一度、海外のAPMツールを導入してみたことがあります。ただ、当時はまだ社員数名で開発していた時期で、得られる成果とコスト、そして当時の売上がまったく見合っていませんでした。
何が遅いかはわかったものの、どう改善すればいいのかが全然わからず、どういう風にアプリケーションのコードを変更してどういったデータを得られたらパフォーマンスを改善できるのかの試行錯誤もできませんでした。そのツールの一番安価なプランを選んでいたため、カスタマイズやトレースを見るのも機能制限されてあまりできなかったんです。

結局その後は解約し、他のAPMも利用せずにやってきました。お客さまから「このページが遅い」という問い合わせがたまに来ても、調べる手立てが十分にない。何が原因かはわからないけれども、とりあえず見える範囲で対応する。そんな状態が続いていたのです。

― その後、再びAPMが必要だと考え直したきっかけは何だったのでしょう？

齋藤：累計アカウント数が15万、16万と増えていく中で、私たち自身がテスト環境などでzaicoを触った際、「なんだか特定の処理が重くて使いづらいな」と感じる場面が目立つようになってきました。

大口のお客さまですと1回で数千件のデータを動かすこともあるため、時間がかかるものだと想像されているのか、お客さまからのクレームが頻発していたというほどではないのですが。とはいえ、「遅いのが当たり前」になってしまう前に、SREing（Site Reliability Engineering、サービスの安定運用を体系的に実現する手法）の考え方を導入し、サービスの信頼性を客観的に担保できる状態にしなければならない、という危機感でした。

そこで再度、大手海外ツールの導入も検討し、資料請求や問い合わせを行いました。しかし、ベンダーロックインのリスクや、サポートが十分に得られるかなど、不安要素が多かったですね。

谷口：大手海外ツールだと、コストの算出方法がわかりにくかったことも大きな懸念でした。「このオプションは別料金です」「書いていないけれども実はこの組み合わせだとこれだけかかります」といったことが多く、実際に見積もりを依頼しても、利用環境によって最終的な金額がいくらになるのかわからなくて不安になる経験がありました。経営層やCTOに対して「この予算でこれだけの成果が出ます」と自信を持って説明し、社内プロモーションをかけることが非常に難しい状態だったのです。

OpenTelemetryという標準化への挑戦と、Mackerel APMという運命的な選択

― そのような課題を抱えていた中で、MackerelのAPMに目が留まった経緯を教えてください。

谷口：私がZAICOに入社した際、インフラチームのマンパワーも整ってきたため、本格的にテレメトリーデータ（アプリケーションの内部動作状況を示す計測データ）の標準化を進めたいという意向がありました。特定のベンダーに依存するシステム構造にしてしまうと、将来的にツールの変更が必要になった際にベンダーロックインのリスクが生じます。そのため、業界の標準規格である「OpenTelemetry」の採用を決めました。SDK（ソフトウェア開発キット）が整備されているので自分たちでもテレメトリーを送るための実装ができますし、標準規格に準拠しておけば、もしも将来ツールを変更する必要が生じてもベンダーロックインされずに移行しやすいと考えたからです。

まさにそのタイミングで、MackerelがOpenTelemetryをベースとしたAPM機能をリリースするというブログ記事を目にしました。「気にはなっているけれど、自分たちだけで一からOpenTelemetryを組むのは難しそうだ」という不安を抱えていた時期でしたし、国産のAPMが出るなら国産を使いたいという思いもあったので、これは非常に運命的なタイミングでした。

Mackerelは、この機能をどのように使うとどれだけのコストが発生するのかという価格体系が極めてシンプルで明確です。料金がわかりやすいということは、運用イメージが湧きやすいということでもあります。利用量の推移線も便利で、「これくらいの計測量なら月額これくらいに収まる」という計算が事前にきっちりと成り立つため、CTOへ話を持ちかけやすく、導入の承認を得るまでのプロセスが非常にスムーズでした。

― ありがとうございます！ 実際にMackerel APMの導入を進める中で、どのような点が正式採用の最後の後押しとなりましたか。

齋藤：一言で言えば、Mackerelチームの「サポートの質の高さ」です。私たちはAPMファーストユーザーキャンペーン（トライアル期間の延長と、エンジニアが担当として付いて導入支援を受けられるキャンペーン）に応募したのですが、Slackを活用し、非常に密なコミュニケーションを取らせていただきました。

驚いたのは、単にMackerelという製品の枠に留まらず、OpenTelemetryの仕様そのものに関する相談や、「こういうケースではどう実装すべきか」という技術的な深い検証に対して、ものすごいスピード感で一緒に手探りしながら並走してくれたことです。

谷口：海外ツールだと、窓口には営業担当の方しかおらず、私たちが伝えている技術的な本質や困りごとがうまく伝わらないというもどかしさを感じることが多々あります。結局、何も解決しないまま半年が過ぎてしまうといった話もよく耳にします。

しかし、Mackerelとの会合には、知識も経験も豊富な導入支援担当エンジニアであるMackerel CRE（Customer Reliability Engineer）が直接参加してくださっています。私たちが投げかけた難しそうな質問に対して、その場で適切な答えが返ってくるだけでなく、検証した結果をわかりやすくドキュメントあるいはブログなどの技術記事として還元してくれました。

ぼそっと漏らした「こういう機能があったらいいのに」という要望が、実際に形になって返ってきたこともありました。この「相互にツールとシステムをアップグレードしていける感覚」と、圧倒的な安心感があったからこそ、私たちは迷うことなくMackerelの採用を決断できたと思います。

導入後の現在も、CREの方々がSlackを通じて新機能のお知らせや活用に関する質問対応など、継続的にコミュニケーションを取ってくれて助かっています。

齋藤：トラブルが発生した際、解決にこぎ着けるまでのスピードが今までとは圧倒的に違いますね。先日もシステムに高負荷がかかる場面があったのですが、Mackerel APMを確認したところ、特定のパスにおける特定の処理がピンポイントで浮き彫りになりました。

これまでは、データベースのインデックス（索引）が効いていないせいで全件検索になってしまっている重い処理を探すために、ログからリクエストIDを頑張って探し出し、どんな処理が実行されたのかという泥臭いフローをインフラエンジニアが1週間かけて調査していました。それが今では、Mackerelの画面を開くだけで、どの処理が犯人なのかが最初からわかります。

結果として、調査に1週間、修正に2日かかっていたようなトラブルが、その日のうちに原因を特定してエスカレーションを行い、翌週には完全に修正が完了しているというスピード感に変わりました。何も生まない手探りの調査時間がなくなり、すぐに次の具体的な改善タスクへつなげられる体制が構築できたことは、実務において非常に大きな変革です。

谷口：今まではそもそも何も見えなかったアプリケーションの深部が、完全に可視化されるようになりました。これまでもAWS全体の大きなメトリックを追うことはできましたが、Mackerel APMを入れたことで、各エンドポイント（APIの接続先）でどれだけのレイテンシー（遅延時間）が発生しているのか、データベースの処理に何秒かかっているのか、クエリが具体的に何回発行されているのかまで、ピンポイントで細かく追えるようになりました。

実際に見てみると、想定外の発見も多くありました。思いもよらない箇所で大量のクエリが発行されていたり、データベース側の問題だと思い込んでいたものが実はアプリケーション実装側に原因があったりと、可視化されて初めて気づけたことがいくつもあります。

これにより、以前とは全然違う戦い方ができているという実感があります。たとえば、大きなミドルウェアのアップデートや、大規模な新機能のリリースを行う際、以前なら「たぶん大丈夫だろう」という感覚を頼りにハラハラしながら見守るしかありませんでした。しかし今では、リリース前後でパフォーマンスに影響が出ていないかどうかを、見やすいグラフと明確な数値によって定量的に確認できます。この確証が得られるようになったことが、チームにとって計り知れない安心感につながっています。

― AIも活用されていると伺いました。MackerelとAIをどのように掛け合わせているのか教えてください。

齋藤：普段の開発でもAIはかなり使っていて、最近書いたコードの多くはAIを活用して開発しています。障害調査においても、MackerelのAPMとMCPを使い、AIでコードと照らし合わせながら原因を追う、というフローができてきました。データが多すぎると人間では「何を見たいんだっけ」となりがちですが、人が気づけない相関にAIは気づける。人間の認知負荷を下げながら分析できるのが大きいです。

谷口：APMで取れるようになったデータは、AIでの調査にも直結しています。障害の原因を突き止めるための手がかりは、多ければ多いほどいいですから。AIが当たり前になった時代だからこそ、APMを入れて助かっている部分があります。ただ、すべてのトレースを取得すると相応のコストがかかるため、いまは条件を絞り、データ量の多いお客さまのトレースだけを100%出す、といった使い方をしています。

― 負荷削減だけでなく、コスト削減という観点でもサンプリングやフィルタリングができるのはOpenTelemetryのメリットですね。

谷口：はい、CREに相談しながら、自由度が高くスマートなサンプリングの設計を行い、現在は全体のアクセスに対するサンプリングレートをかなり絞って運用しています。これによって、月額のベースコストを自分たちが十分に許容できる範囲へと確実にコントロールしています。

一方で、「これだけ絞ってしまうと、特定の重要なトラブルを見逃すのではないか」という懸念もあるので、ターゲットを絞ったピンポイントなサンプリング設定をしています。具体的には現在、大口のお客さまや、データ量が非常に多くパフォーマンス低下のリスクが高い特定のお客さまの企業単位に条件を絞り、その通信に関しては100%トレースを送るという構成を組んでいます。全体としてのコストを賢く抑えつつ、本当に見たい重要なパフォーマンスの指標や検索条件の挙動は確実に定量データとして算出する。このようにしてコストを最適化しながら、十分な情報と安心感を得られています。

齋藤：私たちの代表も常々口にしているのですが、在庫管理というビジネスにおいて何よりも価値があるのは、「泥臭い現場のリアルなデータをいかに蓄積していくか」という点にあります。物品の管理というのは、現実世界とデジタル世界の間で非常に複雑なリレーションが存在します。SaaSの中でそれを網羅しようとすると、データベースのリレーションが張り巡らされ、どうしてもシステム全体が重くなる傾向にあります。

これからの10年を見据え、私たちは大量の現場データをこれまで以上の超高速で処理し、お客さまへ価値を還元するための「次世代データ基盤」の構築という大きなチャレンジに踏み出しています。データベースエンジンそのものの根本的な見直しや、新しいアーキテクチャへの移行を進める上で、Mackerel APMはなくてはならないものとなっています。

谷口：新しいデータベースの検証やシステムのスクラップ＆ビルドを繰り返す際、実際に本番同様のアクセスを発生させたときのパフォーマンスの変動が、Mackerelの画面を通じて直感的に、かつリアルタイムに確認できます。

トレースデータがパッとグラフに表示され、計測の条件を少し変えるだけで「なるほど、この構成なら2、3分後にはこの数値に落ち着くのか」ということが手に取るようにわかります。Mackerel APMという確かな土台があるからこそ、私たちはサービスの安定性を保ったまま、新しい技術への挑戦を加速させることができています。今後のログ監視機能にも期待していますし、オブザーバビリティの基盤をさらに充実させながら、zaicoをもっとよくしていきたいですね。

 ― 齋藤さま、谷口さま、ありがとうございました！