はてなが開発・運用するオブザーバビリティプラットフォーム「Mackerel（マカレル）」は、2014年9月17日に正式リリースして以来、10年にわたり多くのエンジニアに選ばれ続けてきました。
これまでサーバー監視・管理の領域に力を入れてきたMackerelは、より複雑な問題やシステムの変化に対応していくため、「始めやすくて奥深い、可観測性プラットフォーム」としてオブザーバビリティ領域の開発に力を入れることを宣言し、2025年5月1日（木）にはMackerelのAPM（アプリケーションパフォーマンスモニタリング）機能を正式リリースしました。
技術の進化による環境の変化の中で、Mackerelが変わったところや変わらないところ、この先の展望などについて、Mackerel プロデューサーの 
id:wtatsuru にインタビューしました。聞き手は Mackerel エバンジェリスト 
id:Soudai です。インタビュー記事は前後編でお送りし、本記事は後編となります。
- 前編：なぜ「痒いところに手が届く」のか？ - エンジニアに10年選ばれ続けるMackerelの"らしさ"を探る【前編】
- 後編：モニタリングを超えた“次のあたりまえ”へ - エンジニアに10年選ばれ続けるMackerelの"らしさ"を探る【後編】
プロフィール
渡辺 起（id:wtatsuru） / Mackerel プロデューサー
2011年にインフラエンジニアとしてはてなに入社。インフラ基盤チーム責任者、Mackerelプロダクトマネージャーを経て、2023年1月からMackerelプロデューサーとして事業全体の運営に携わる。
曽根 壮大（id:Soudai） / 合同会社 Have Fun Tech 代表社員、株式会社 Linkage CTO
数々の業務システム、Webサービスなどの開発・運用を担当し、2017年に株式会社はてなにMackerelのCRE（Customer Reliability Engineer）として入社。退職後、株式会社オミカレの副社長/CTOなどを経て、合同会社 Have Fun Techを起業。 その後、LinkageのCTOとしてJOINし、Have Fun Techの経営と二足の草鞋を履きこなしている。Mackerelエヴァンジェリスト。
Mackerelが目指すオブザーバビリティの全体像
Soudai：先ほど、アプリケーションエンジニアはまずログを見るという話がありましたが、ログもOpenTelemetryの重要な要素ですよね。現在Mackerelはトレースとメトリックに注力している印象ですが、今後、それぞれの機能に対し、どのような方向性を考えていますか？
wtatsuru：まずトレースとラベル付きメトリックに関しては、基本的な機能は一通りリリースできました。ただ、これを実際に活用していただくには、まだ改善の余地があると思っています。
特にトレースは、APMとして導入から活用までの体験をスムーズにするのがテーマです。現状、トレースデータを投稿する部分にもまだハードルがあるため、そこは改善していきたいですね。
メトリックは、ラベル付きメトリックの投稿と分析、ダッシュボード作成、メトリック比較といった機能は既に提供していますが、従来のユーザーに、これらの新しい体験をまだ十分に届けられていません。従来からあるMackerelの機能をラベル付きメトリックやAPMといった新しい体験とどう統合していくかは次の課題です。
アプリケーションの状況を深く掘り下げる、問題解決力を強化する機能は強化していきたいと考えています。加えて、こうした機能を誰でもすぐに活用いただけるよう、入り口の容易さも同時に整えていきたいと考えています。
ログやプロファイルといった他のシグナルについてもOpenTelemetryで対応しているものは、ニーズがあるので、必要なものは積極的に対応していきたいです。
ただ常に気をつけたいのが、コストの問題ですね。オブザーバビリティは情報量が増えるとコストも高くなりがちです。トレース機能を開発して痛感しましたが、コストを適切にコントロールしつつ、必要な情報を効率的に活用できる仕組みをセットで提供することが重要です。ログも同様で、クラウド上のストレージとSaaSでログが二重管理になると、その分コストが跳ね上がってしまうので、最適化しながら有効活用できる方法を慎重に検討していきたいです。
Soudai：まさにコストに対する考え方こそMackerelらしさだなと思いますね。仮に「この機能を提供するなら、多少コストがかかっても当然ですよ」と言って売り込むこともできたはずなのに、そうしない。なぜなら、実際にユーザーさんの目線に立ったら、運用・監視にかけるコストは売上の中で許容される範囲が現実的に決まっていることを理解しているから。この、ユーザーに寄り添った現実解に落とし込む姿勢は非常に大事ですよね。
まさに料理キットが、料理に時間が割けられない人のニーズに答えるように、Mackerelもまた、無限にはコストをかけられないユーザーの状況を理解して、「ちょうどいい」バランスと「お手頃」な価格で価値を提供している。これがMackerelの大きな魅力だと思います。
「レール」と「自由度」のちょうどいい関係
Soudai：オブザーバビリティの領域でも、Mackerelらしい導入しやすさを実現してほしいですね。例えばラベル付きメトリックだと、どんなラベルを付けたらいいか、命名規則はどうするのかなど、結構難しいと思うんですよ。Mackerelがテンプレートやチュートリアルを出してくれて、用意したレールに沿って進むと自然とそれっぽい運用ができると嬉しいです。
Mackerelのサーバー監視でのサービスとロールがそうでしたよね。サービス名に自分たちが運用するサービスの名前、例えば「はてなブログ」とつけ、ロール名にWebサーバー、DBサーバー、そしてDBの中でもプライマリーとセカンダリーのように細かく設定していくと、システム構成に合ったグラフの配置やダッシュボードに自然と近づいていく。これがMackerelの良さだと思います。トレースでも同じように提案してもらえると、Mackerelらしさの延長線上に、僕らの住みやすいオブザーバビリティの世界が広がっていくのかな、と話を聞いていてイメージしました。
wtatsuru：そうですね、皆が「OpenTelemetryのラベルを頑張っていじろう」という世界にはおそらくならないでしょう。整えられる人はいいですが、Mackerelとしては、難しいことはちゃんと整えてあげて、「こうやれば満足いくようになるよ」というやり方を提供していきたいですね。
Soudai：そうですね。一方で、完成品をインストールするのではなく、自分たちの運用に合わせてカスタマイズできるのもMackerelの良さだと感じています。完成品だと、自分たちがそれに合わせるしかありません。これも料理の話で言えば、レストランの完成されたおいしさもいいんですが、コストもかかるし、出てきたものがその日の気分や好みの味付けと違うこともありますよね。
料理キットのように、自分たちで一定の料理をすることによって、ある程度カスタマイズすることもできます。これができれば、SREならより本質的な価値を発揮できるし、アプリケーションエンジニアも、SREに頼らずに、自分たちでオブザーバビリティをカスタマイズできるようになれば理想です。サーバー監視でMackerelを使って成長できた実績があるので、オブザーバビリティでも期待したいですね。
wtatsuru：「改善していっていいよ」と何もないところで言われても困りますよね。まずは、手を動かせるような「叩き台」や「スタート地点」が必要だと思います。開発プロセスに終わりはなく、理想というものも常に変化し続けます。そんな中Mackerelのやり方を起点として、改善を進めてもらえるようにすることは、これからの開発が本番だなと思います。
システムは最初はシンプルに作るけど、だんだん複雑になることもあります。ビジネスが成長すれば、そこに合わせてオブザーバリティやモニタリングも進化させていくことが必要です。ツールを使いながらシステムを少しずつ良くしていく。合わせて人もチームも成長していく。そういう改善のための「スタート地点」を提供することをMackerelは大事に思っています。
Soudai：Mackerelが「スタート地点を提供する」ことを重視しているとのことですが、先行するオブザーバビリティツールが多い中で、今Mackerelを選ぶ理由というのは、まさにそうした点にあるのでしょうか？
wtatsuru：そうですね。そういう面で「Mackerelならこう見せます」という、Mackerelらしいスタート地点の違いを作っていきたいです。 例えば、いろんなオブザーバビリティツールを見ていると、ツールによっては導入していきなりすごい数の入力項目が並ぶことがありますよね。もちろん、一つ一つ入力していけば詳細な情報が見られ、自由にダッシュボードも作れるので、それはそれで素晴らしい価値です。 MackerelのAPMだと、OpenTelemetryの規則に従ってデータを入れれば、REDメソッドのグラフをはじめ、HTTPサーバーやデータベースのパフォーマンスといった「今、これが必要でしょう」という情報を、自動的にバッと表示します。こうした整った状態から始められる体験を提供していきたいです。 もちろん詳細な分析機能も段階的に拡充していくつもりです。ただ、そこでは先行する優れたツールも多いので、Mackerelはまず、機能的にはシンプルでも「これが欲しかったんだ」と感じてもらえるような必要な情報がすぐ手に入る体験に重点を置いています。
Soudai：Mackerelの方向性と、独自のカラーがはっきり出ている感じがします。今後が楽しみですね。
AIが運用を変える？ロードマップのその先を語る
Soudai：APM機能もリリースされた今、Mackerelの今後のロードマップ、特に今年2025年の後半から来年にかけて、どのような進化を予定しているのでしょうか？具体的に、ここに注力していく、というポイントがあれば教えていただけますか？
wtatsuru：オブザーバリティの取り組みはまだ始まったばかりなので、アプリケーションとインフラの両方の観点で機能の拡充や対応範囲の拡大をしばらく継続していくつもりです。具体的には、直近はやはりAPM機能の進化に注力していきます。
Soudai：AIが今、まさにゲームチェンジャーとして世の中で注目されていますが、LLMを含めたAIの活用や連携、あるいはMackerel自体がAIエンジンとしてどう進化していくかについて、何か考えていることはありますか？
wtatsuru：はい、いくつか試しています。例えば、MackerelのMCPサーバーを作ってみたり、PromQLの式を書く代わりにAIに自然言語で指示してグラフを生成させたり。これらは現在の技術で十分に実現可能だと見ています。AIは人間のサポートから、開発・運用プロセス全体へ深く関わっていくでしょう。そんな中で、Mackerelをどう位置づけていくか。
今は、AIに適切な指示を出すためにも、オブザーバビリティを高め、システムの情報をしっかり収集・管理することが重要です。
昔は、ハードウェアの配線図を見ながら「ここが壊れたら通信がおかしくなるから、ここを監視しよう」と話すような時代でした。それがクラウドになり、どこが壊れるか分からないから「後で調べられるように情報を集めておく」という姿勢に変わりました。これがオブザーバビリティの本質だと思います。
さらにAIエージェントがコードを書き、そのうちインフラも構築するようになる未来では、人間が把握しきれない要素もどんどん増えるでしょう。そうなった時、「よくわからないけど動いている」というような状態ではなく、例えば「レスポンスタイムがこの範囲ならOK」といったSLO（Service Level Objective）のように、システムの期待する状態を人間が定義する役割が残ると思います。 Mackerelは、その定義された目標に対し、「こういう観点で見ると良い」「この情報を見れば異常が分かる」と、誰でも答えにたどり着けるよう支援していきたい。これは、オブザーバビリティ進化の延長線上にあると考えています。最終的にオペレーションが全て自動化される未来では、Mackerelはシステムの裏側に溶け込み、人間が直接触れない存在になっているかもしれませんね。
Soudai：なるほど。確かに、それは面白い観点。
僕が想像したのは、データベースのクエリを例にすると、OpenTelemetryでクエリ自体は取得できるわけだから、APMが直接LLMにクエリを投げ、実行計画を取得して「このクエリが問題では？」「ロックを取っています」といったことを示唆してくれる。つまり、AIがデータベースの構成情報、メトリック、ログ、トレースなどの情報を見た上で、障害になり得るところを推測してくれるようなことができちゃうな、と。他には、アラートをトリガーにLLMを叩いて初動対応まで行う、といったことも十分にあり得る未来像ですよね。 これは、ハッカーとしての腕の見せ所で面白いところだと思います。MackerelのいいところはAPIが公開されていることです。RESTベースのAPIでWebhookを叩き、LLMやAIを起動させたり、データを連携させたりすることもできそうです。障害の振り返りの際には、Mackerelのアラート一覧からタイムラインを作成させたり、ポストモーテムのテンプレートを事前にAIに作らせたりと、既存の機能だけでも面白い連携はたくさんありそうですね。
wtatsuru：そうなんですよ。Mackerelには人が設定したアラート定義や、異常発生時のアクション履歴も残っています。そういった情報から、次のアクションをAIが支援できると面白いですね。Mackerelがまだ持っていない情報、例えばSlackでの障害対応のやり取りなどをAIで集約し、サマリー作成や、改善まで含めたアクション支援ができれば、さらに面白くなるだろうと想像しています。
Soudai：もうAIがAWSの構成図や、ルーターのコンフィグからネットワーク図まで作ってくれそうな世界がすぐそこまで来ていますよね。Mackerelの情報をAIに連携したら、ネットワーク図や構成図ができる、なんてことも実現できそうな気はしますよね。
wtatsuru：そうですね。システムの設定情報とMackerelの情報を組み合わせ、「ここがおかしい」と教えてくれるような機能は欲しいですね。
Soudai：確かに。「ここがリスクが高い」といった表示でも良いですね。 あとは、Mackerel側が様々なシステムの情報を持っているはずだから、「この構成だとWebサーバーで障害が発生しやすい」「このデータベース構成だと何年以内に障害が発生する確率が高い」といった推測まで出せるようになるのではないでしょうか。
wtatsuru：それはできそうです。ちょっと前にAWSインテグレーションで、このインテグレーションではここをモニタリングしているユーザーが多い、というランキングを記事として公開したら結構反響がありました。、Mackerelが持つデータの活用の幅は、実際にもっと広がるでしょうね。
ユーザーと一緒に描く、オブザーバビリティの次の風景
Soudai：Mackerelは10年続いていますが、最新情報を追うユーザーだけでなく、昔のイメージのままの人も多いと思います。そうした方々にもぜひ最近の変化を知ってほしいのですが、何からキャッチアップするのがおすすめですか？
wtatsuru：Mackerelからの公式発信としては、まず毎週更新しているブログを見ていただくのが一番分かりやすいと思います。Xアカウント（@mackerelio_jp）もフォローいただけると情報がキャッチしやすいはずです。他にも、CREチームによるハンズオンや公式Meetup、オンラインセミナーなど、気軽に新機能に触れる機会も設けています。
Soudai：Mackerelは国産サービスなので、Meetupイベントなどで開発者と直接会える距離感がいいですよね。ぜひ皆さんにも参加してほしいです。「最近触っていなくて、久々に見たらよく分からなかった」という人も、積極的にフィードバックや質問をしてほしいですね。
wtatsuru：私も含め、Mackerelの開発メンバーは様々な技術イベントに参加したり登壇したりしています。もし直接会う機会があれば、ぜひ気軽に声をかけてください。ご要望をいただけたら、それに合わせてMackerelも進化していきたいですし、Mackerelは「開発者に会いに行けるサービス」とよく言っていますが、ユーザーと距離を近く保って、対話しながらプロダクトを作っていきたいと考えています。
Soudai：それはローンチ以来変わらない良さですね。エンジニアや開発者に会えたり、直接フィードバックできる手触り感があるのは、はてならしさでもあると思います。ぜひ皆さんにも堪能してほしいです。
「ダッシュボードのおまかせ生成機能を使ってみたけど、他のパターンも作ってほしい」とか、「テンプレートをこう改善してほしい」といった具体的な声は歓迎です。使う人の数だけ運用パターンがあるでしょうから、「うちの業界では、このメトリックをこういう風に見たい」といったフィードバックは、id:wtatsuru さんが開発の際にユーザー一人ひとりの顔を思い浮かべる助けになるはずです。
wtatsuru：最近リリースしたAPMは今まさに始まったところで、「社内の運用から考える最強の機能」という視点を起点に開発を進めています。「データベースパフォーマンスはよく見るだろう」「HTTPエンドポイントのパフォーマンスは一目でわかるべき」といったところをチームで議論しています。お客様と話しながら作ってはいますが、「こういう課題があって、こんな機能こそ必要だ」という具体的な要望があれば、今から作っていくフェーズなので、ぜひ積極的に教えていただけると非常に反映しやすいタイミングです。
Soudai：さっきのAIの話でも触れましたが、Mackerelは国内にコミュニティがあるのも強みですよね。コミュニティからも「こんな面白いアイデアがあるんだけど、一緒にハッカソンをやってみませんか？」といった提案も含め、様々なアイデアをどんどんフィードバックしてほしいなと思いました。
wtatsuru：はい、皆さんからの直接の声がMackerelをさらに良いプロダクトへと進化させる力になります。ぜひ、これからも皆さんと一緒に、新しいオブザーバビリティ体験をつくっていきたいです。
