MackerelのAPM機能とMackerel MCPサーバーを活用し、AIが自律的にWebアプリケーションのパフォーマンス改善を行えるかをISUCONを題材に検証します。Mackerelの計測があることで、AIが根拠を持って問題を分析できるようになります。
こんにちは、Webアプリケーションエンジニアの
id:momochi29です。
Mackerelはインフラだけではなくアプリケーションも監視できるように、APM機能の開発を続けています。その一環として、AIによってMackerelをより高度に活用できるよう、Mackerel MCPサーバーの提供も開始していました。
このMackerel MCPサーバーを利用することで、AIがどこまで、どのように自律的にアプリケーションを改善できるのか知るべく、ISUCONを題材に検証をしてみました（今回はISUCON9の予選を題材として利用しています1）。
本記事では、ISUCONをAIで解くためのMackerelでの計測方法の説明に重きを置きつつ、実際にAIでISUCONを解いてみた具体的な事例についても簡単に紹介します。
ISUCONとは
ISUCONは「Iikanjini Speed Up Contest」の略で、お題となるWebサービスに対して、規定のルールのもと、振る舞いを変えずにいかに高速化できるかというスコアを競うコンテストです。
ISUCONには次のような性質があります。これらはAIが力を発揮しやすい条件が整っており、試す場としてはもってこいです。
- コードベースが小さい。ISUCON9の予選は2ファイル、合計2,500行程度
- ⇒ コンテキストを圧迫しにくい
- ベンチマーカーによる整合性テストがある
- ⇒ 変なことをしていたらテストで気付ける
- スコアとして定量的に改善度合いを測ることができる
- ⇒ 効果のある改善かどうかを客観的に評価できる
「推測するな、計測せよ」
「推測するな、計測せよ」という格言があります。目に付いたN+1クエリを直したのに、パフォーマンスが改善しない……という経験はないでしょうか（筆者はあります）。これは、パフォーマンスのボトルネックになっていないところを直しても効果が薄いことを示しています。
効果的に改善を進めるには、まずどこがボトルネックになっているのかを計測し、そのデータに基づいてボトルネックとなる原因を解消することが重要です。
Mackerelで計測できること
MackerelがAPMに対応したことで、アプリケーションのどこにボトルネックがあるのかを特定しやすくなりました。具体的には以下の項目を計測できます。
- HTTPサーバー統計情報（アプリケーション）
- ⇒ どのエンドポイントが遅いかがわかる
- データベース統計情報（アプリケーション）
- ⇒ どのクエリが遅いかがわかる
- CPU使用率、メモリ使用率、ディスクI/O（インフラ）
- ⇒ どのシステムリソースがボトルネックになっているかがわかる
計測するための準備
それでは、Mackerelで計測するための準備をしましょう。
1. CPU・メモリ使用率等のリソース使用量を知るためのホストメトリックを投稿する
今回はDockerを利用してローカル環境でISUCONを動かすので、DockerのホストメトリックをMackerelに投稿します。
次のようにmackerel-agentをコンテナとして動かすことで、Mackerelに簡単にホストメトリックを投稿できます。
mackerel-agent: image: mackerel/mackerel-agent container_name: mackerel-agent environment: - "apikey=${MACKEREL_APIKEY}" - "enable_docker_plugin=1" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro
詳しくは以下のヘルプページを参照してください。
2. アプリケーションのパフォーマンスを知るためのOpenTelemetryトレースを投稿する
MackerelのAPMはOpenTelemetryを基盤としています。OpenTelemetryトレースをMackerelに送信すると、適切な属性が付与されていれば自動でHTTPサーバー統計情報やデータベース統計情報が生成されます。
アプリケーションコードを変更して計装する方法
アプリケーションからOpenTelemetryトレースを送信（計装）するために、次のような実装を追加します。
実装のポイントは以下のとおりです。
otel.go：トレースを送信するための初期化処理を行っています。main.go：otelchi、otelsqlxという計装ライブラリを使用しています。これにより、「適切な属性」（例：http.route）を手動で付与する代わりにライブラリが自動で付与してくれます。api.go：手動でスパンを作成します。時間がかかっていそうな外部APIへのリクエストをトレースに含めるために、スパンを作成しています。- OpenTelemetry Collectorを利用するための設定：Mackerelへのトレース送信のオフロード、サンプリングによって投稿量を抑えることを目的にOpenTelemetry Collectorを利用します。
- サンプリングにはテイルサンプリングという戦略を採用しました。「エラーになっているトレースは必ず含める」「500ms以上かかっているトレースは必ず含める」というように細かに設定して、投稿量を抑えながらも分析を可能にしています。
OBIでアプリケーションコードを変更せずに計装する方法
ここまでで、「計装するの面倒そうだな……」「普段開発しているアプリケーションコードはいじれないしな……」と思われた方もいらっしゃるかもしれません。そのようなときには、アプリケーションコードを変更せずに計装するOBI（OpenTelemetry eBPF Instrumentation）を使う方法がお勧めです。
eBPFと聞くと難しそうに感じるかもしれませんが、使うだけなら非常に簡単です。必要なのは設定ファイルを記述してOBIを動かすことだけです。以下のコードを実装するだけでMackerelでトレースおよびメトリックを取得できます。
OBIを動かす（docker composeの例）
obi: image: docker.io/otel/ebpf-instrument:main pid: host privileged: true depends_on: - otel-collector environment: OTEL_EBPF_OPEN_PORT: 8000 OTEL_EXPORTER_OTLP_ENDPOINT: http://otel-collector:4318 OTEL_EBPF_CONFIG_PATH: /configs/obi-config.yml volumes: - ./etc/obi-config.yml:/configs/obi-config.yml networks: - my_network
設定ファイル（obi-config.yml）
trace_printer: text open_port: 8000 ebpf: context_propagation: all track_request_headers: true attributes: select: traces: include: ["db.query.text"]
OBIの詳細については
id:kmutoによる紹介記事もあわせてご覧ください。
3. Mackerel MCPサーバーを呼び出せるようにする
Mackerel MCPサーバーはDockerまたはnpxを使ってローカルで動かすことができます。どちらを利用しても差異はないので、お好みのほうをお選びください。
実行にはMackerelのAPIキーが必要です。ISUCONを解くにあたっては読み取りだけできればよいので、「Read」権限のみのAPIキーを用意してください。
Claude CodeにMackerel MCPサーバーを追加する
claude mcp add-json mackerel '
{
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e",
"MACKEREL_APIKEY",
"ghcr.io/mackerelio-labs/mcp-server:latest"
],
"env": {
"MACKEREL_APIKEY": "${MACKEREL_APIKEY}"
}
}
'
AIでISUCONを解いてみる
では、いよいよAIでISUCONを解いてみましょう。
どこにボトルネックがあるかをAI自身が判断して自律的に改善するように、プロンプトを与えました。
その結果、人間が介入せずともどんどんとスコアが上昇し続け、初期状態の1,810点から最終的に50,280点まで改善されました（筆者が昔解いたときは1万点ちょっとぐらいだったと思うので、完全敗北しています……）。
与えたプロンプトの構造
AIが自律的に判断・改善できるように、プロンプトでは以下の3点を定義しました。
- 目標：ISUCONのスコアを最大化すること
- ツール：Mackerel MCPサーバーとその他を必要に応じて使うこと
- 記録：どのように発見し、何を根拠に、どう改善したか、スコアはどう変化したかを記録すること
完全なプロンプトは以下で公開しています。
具体的な改善の一例
AIが行った改善の中からここでは例を1つご紹介します。
Mackerel MCPサーバーを利用してHTTPサーバー統計情報を取得し、P95（95パーセンタイル）レイテンシーが遅いこと、エラー率が高いことを発見しています。事前情報として外部APIのリクエストに時間がかかることはわかっていたので、P95を改善することは困難です。
しかし、コードを分析し、時間がかかるAPIコールを行っている間にロックを保持していることを突き止めました。この外部APIリクエストをトランザクション外に移動することで、エラー率が低下し、スコアが向上しました。
このような調子でボトルネックをどんどん解決して、スコアを伸ばしていきました。AIによる改善の記録を眺めると、まるで熟練のエンジニアのように問題を分析して1つずつ解決していく様子が見えて面白いです。
最後に
Mackerelで計測することで、AIが根拠を持って自律的にISUCONを解けることがわかりました。
Mackerelは500万スパン/月を無料枠として提供していますが、今回の検証に利用したのは405万スパンでしたので、この無料枠に収まりました。
ぜひ皆さんもMackerelとAIを活用してISUCONに挑戦してみてください！
なお、本記事では紹介しきれなかったプロンプトの工夫やAIの改善の様子は、2026年1月22日（木）に開催されるオンラインセミナー「Hatena Engineer Seminar #36 プロダクトを支えるAI編」でお話しする予定です。
追記：
「Hatena Engineer Seminar #36 プロダクトを支えるAI編」の開催レポート記事にて、配信アーカイブおよび発表資料を掲載していますので、こちらもぜひご覧ください！
もう「なんか遅い」で悩まない！開発者のためのAPM入門
アプリケーションを開発・運用していると、特定の処理が遅い、リクエストごとに応答時間がばらつくなど、「なんか遅い」と感じる場面があります。本資料では、こうした「なんか遅い」と感じる状況に対して、どこから調べればよいのか、何を手がかりにすればよいのかという観点から、APM（アプリケーションパフォーマンスモニタリング）が調査の進め方をどう変えるのかを解説します。
- ISUCONは過去問をGitHub（https://github.com/isucon）で公開しています。継続的にメンテナンスされているものもあり、とてもありがたいです。↩
