Coding AgentとはじめるMySQLパフォーマンスチューニング
LayerX Tech Blog の記事は、データ量や分布の変化により実行計画が劣化した MySQL パフォーマンス問題に対し、Coding Agent を活用して EXPLAIN と EXPLAIN ANALYZE を分析・改善した実践的な事例を報告している。
キーポイント
SLO 違反の発端：データ分布の変化による実行計画の劣化
業務システムにおける主要エンドポイントの応答時間が SLO を下回った原因は、顧客数の増加に伴うデータ量と分布の変化により、MySQL が意図しない実行計画を選択してしまったことだった。
Coding Agent による EXPLAIN と ANALYZE の分析活用
AI エージェント（Coding Agent）をフル活用して SQL 文の推定実行計画（EXPLAIN）と実測データ（EXPLAIN ANALYZE）を比較し、インデックス未使用やテンポラリソートの発生といった具体的なボトルネックを特定した。
推定と実測のズレによる精緻なチューニング
MySQL の EXPLAIN が示す推定値と実際の動作にズレがあることを確認し、その差異を解消するためにインデックスの追加やクエリ構造の見直しを行い、パフォーマンスを改善した。
データ分布変化による実行計画の逆転と対応
以前の改善策（NOT IN＋サブクエリ）が現在のデータ分布では非効率となり、カラム直接指定への書き換えで劇的な高速化（最大50倍）を達成した。
Coding Agentとツールの活用による高効率チューニング
EXPLAIN分析から実装までAgentに任せることで従来より迅速に改善し、gormgoldenを用いてGORM生成クエリのBefore/Afterを容易に確認した。
AI活用における人間の判断と検証の重要性
Agentは過度な複雑化や限定的な改善を提案するため、メンテナンス性や効果の見込みを人間が判断し、仕様書やクライアント実装との整合性を確認する必要がある。
AI Agentによる業務効率化と人間のリソース最適化
AI Agentに多くの業務を任せることで、人間は本当に必要な判断に集中でき、事業成長のための改善活動を推進できる。
影響分析・編集コメントを表示
影響分析
この記事は、AI ツール（Coding Agent）を実際の DB パフォーマンス問題解決にどう組み込むかという具体的なワークフローを示しており、開発現場における AI 活用事例として非常に参考になります。特に、推定値と実測値の乖離を AI で分析する手法は、多くの MySQL ユーザーにとって即座に適用可能な知見です。
編集コメント
AI ツールを単なるコード生成だけでなく、既存のインフラ課題解決（DB チューニング）にどう活用するかという視点で書かれた、実務家向けの貴重な事例記事です。
こんにちは！バクラク申請・経費精算のエンジニアリングマネージャーをやっています、@ar_tamaです。
今回は、私たちのプロダクトで最近行ったバックエンドのパフォーマンスチューニング（スロークエリの改善）について書いてみたいと思います。比較的地味なトピックではありますが、Coding Agent をフル活用したエピソードとして、主に MySQL をバックエンドに持つアプリケーションの性能問題に直面している方の助けになれば幸いです。
発端：データ量や分布の変化で実行計画が変わった
私たちは、プロダクトごとに内部 SLO（サービスレベル目標）を定めてモニタリングし、基準値を割ったらアクションすることを習慣づけています。
SLO というと大きな障害や可用性の話を想像されるかもしれませんが、特にバクラクのような業務システムでは、毎日繰り返し使う操作の遅さがそのまま利用者（お客様）の生産性低下に直結してしまうため、観測対象に主要エンドポイントの応答時間も追加しています。
今回その基準に違反したのは、複数のテーブルを JOIN して SELECT する処理のあるエンドポイントでした。これまでも必要に応じて、クエリをチューニングしたり、インデックスやインデックスヒントを追加したり、ミドルウェアを立てたり……と対策をさまざま取ってきた箇所です。今度は一体何が……？と調べたところ、たくさんのお客様にお使いいただきデータ量や分布（偏り）に変化が生じたことで、実行計画が意図どおり選ばれなくなったことが分かりました。
やったこと：AI と実行計画を眺める
対象のクエリが見えてきたので、実際に発行されている SQL とパラメータを取得し、Coding Agent と一緒に EXPLAIN と EXPLAIN ANALYZE を確認しました。世は大 AI 時代ですが、主なやることは昔と変わりませんね。
EXPLAIN は、MySQL がその SQL をどう実行しようとしているかを見るためのものです。JOIN の順序、使われるインデックス、推定行数などを確認できます。MySQL の公式ドキュメントでも、インデックスを追加すべき箇所や JOIN の処理順を確認するための手段として説明されています。
一方で、EXPLAIN はあくまで推定です。実際にどのくらい時間がかかったのか、どのステップでどれくらい行を読んだのかを見るには、EXPLAIN ANALYZE が役に立ちます。実際にステートメントを実行するので実行環境には注意が必要ですが、推定と実測のズレによってより精緻に改善することができます。
実際の SELECT 文で双方を確認してみたところ、先述のデータ量・分布の変化によって、効かせたいはずのインデックスが選択されていなかったり、頻出のソート条件に合う複合インデックスがなくテンポラリソート（一時ソート）が起きていたりと、大小様々な問題が発見されました。その中でも今回特に取り上げたいのは以下です。
- JOIN の起点が期待と違い、サブテーブルに持たせている種別の絞り込みから始まっていた
その後、メインテーブル側で数万件規模の候補行を読み、除外条件を 1 行ずつ評価していた
- クエリの責務を分け、サブテーブルの絞り込み→結果を使ってメインテーブルの絞り込み、と 2 回クエリを発行
- 以前のパフォーマンス改善対応（NOT IN＋サブクエリでフィルタ）が、むしろ大きな集合を作るような実行計画に変化していた
→ サブクエリではなく、カラム NOT IN (...) とクエリ自体を書き換えることで対応
1 については EXPLAIN の目視でもすぐに分かるところでしたが、2 については EXPLAIN 結果を分析した Coding Agent からの指摘で初めて気づきました。
以前の対応時は、たしかに除外対象をサブクエリとして扱うほうが効率的だったはずなのですが、現時点でのデータ分布ではそのサブクエリを作るために大きなスキャンが発生しており、インデックスを辿りながら直接条件を評価する方が速くできそう、という見立てが出されたのです。
同僚からその部分の実装意図を聞いていたこともあり、はじめは「いやいやそんな〜まさか〜」と半信半疑でしたが、修正版を試してみたところ劇的に計画が改善されました。余計なコンテキストを持たないほうが強いこともある……🥲
なお、今回は GORM を使ってクエリを発行している部分が修正の対象だったため、実際のクエリの書き換えにあたり、同僚である pon さんのgormgoldenが大変頼りになりました。アプリケーションコード上では良さそうに見えても、出力されたクエリが大事故…ということもときには生じ得るため、このように Before/After の確認を行いやすい状態にしておくことも大事ですね。
結果として、対象クエリ群のほぼ全てで改善が叶い、ベストケースでは50 倍以上もの高速化が叶いました。やったぜ！
imageデプロイ後にアラート対象のクエリが激減した様子
今回のようなクエリチューニング作業においては、Coding Agent の網羅性と手の速さがとても頼りになります。クエリ改善で振る舞いが変わってしまうことのリスクとテストの重要性は前述の通りですが、分析・複数の改善案出し・検証・実装にいたるまで、積極的に Agent に任せながら改善を進めたおかげで、従来の改善活動よりもずっと早く修正が叶いました。
振る舞いの担保についても、以下のようなソースを参照して破綻しないことを確認してもらいました。
- ヘルプサイトや仕様書
- 対応するクライアント（フロントエンド）の実装
これにより人の目だけでは拾いにくい検証観点も補え、動作確認も楽に行えました。
ただし、Agent は放っておくと限界までチューニングしようとしてしまいます。改善提案の中には、修正後のクエリが複雑になりすぎてメンテナンス性を損ねたり、修正量の割に改善効果が限定的だったりするものもありました。そのため計画時、または修正を走らせた後でも、「どの程度改善される見込みか」を確認しながら改善を採用する・しないの判断を行いました。
ほかにも、過去経緯などのコードや仕様に立ち現れないコンテキストを補完したり、ハルシネーションにツッコミを入れたり、計測と修正のサイクルを回すためにステップを分けたりなど、人間の仕事も思いの外残りました。とはいえ、今回の改善を回す過程で補完した文脈はドキュメントに残しましたし、モデルの進化も著しいため、次回以降はどんどん手がかからなくなっていくことが予想されます。
おわりに
今後の展望としては、今回の一連の流れを元に、SLO 違反を検知→スロークエリを EXPLAIN して原因を特定→修正・検証までを実行する Skill などを作れると、改善のサイクルがより速く・多く回せそうです。
人間が本当に必要な判断に集中できるよう、また AI Agent たちにより多くの業務を任せられるよう、引き続き事業成長を支えるための改善活動を（も）進めていきます。
LayerX では、AI と共に爆速で価値を生む・守る仲間を大大大募集しています！ご興味を持っていただけたらぜひこちらからご応募ください。
本職はマネージャーなので、AI 時代のマネジメントどうなる〜？みたいな話も大好物です。カジュアル面談のお誘いもお気軽にどうぞ！
原文を表示
こんにちは！バクラク申請・経費精算のエンジニアリングマネージャーをやっています、@ar_tamaです。
今回は、私たちのプロダクトで最近行ったバックエンドのパフォーマンスチューニング（スロークエリの改善）について書いてみたいと思います。比較的地味なトピックではありますが、Coding Agentをフル活用したエピソードとして、主にMySQLをバックエンドに持つアプリケーションの性能問題に直面している方の助けになれば幸いです。
発端：データ量や分布の変化で実行計画が変わった
私たちは、プロダクトごとに内部SLO（サービスレベル目標）を定めてモニタリングし、基準値を割ったらアクションすることを習慣づけています。
SLOというと大きな障害や可用性の話を想像されるかもしれませんが、特にバクラクのような業務システムでは、毎日繰り返し使う操作の遅さがそのまま利用者（お客様）の生産性低下に直結してしまうため、観測対象に主要エンドポイントの応答時間も追加しています。
今回その基準に違反したのは、複数のテーブルをJOINしてSELECTする処理のあるエンドポイントでした。これまでも必要に応じて、クエリをチューニングしたり、インデックスやインデックスヒントを追加したり、ミドルウェアを立てたり……と対策をさまざま取ってきた箇所です。今度は一体何が……？と調べたところ、たくさんのお客様にお使いいただきデータ量や分布（偏り）に変化が生じたことで、実行計画が意図どおり選ばれなくなったことが分かりました。
やったこと：AIと実行計画を眺める
対象のクエリが見えてきたので、実際に発行されているSQLとパラメータを取得し、Coding Agentと一緒にEXPLAINとEXPLAIN ANALYZEを確認しました。世は大AI時代ですが、主なやることは昔と変わりませんね。
EXPLAINは、MySQLがそのSQLをどう実行しようとしているかを見るためのものです。JOINの順序、使われるインデックス、推定行数などを確認できます。MySQLの公式ドキュメントでも、インデックスを追加すべき箇所やJOINの処理順を確認するための手段として説明されています。
一方で、EXPLAINはあくまで推定です。実際にどのくらい時間がかかったのか、どのステップでどれくらい行を読んだのかを見るには、EXPLAIN ANALYZEが役に立ちます。実際にステートメントを実行するので実行環境には注意が必要ですが、推定と実測のズレによってより精緻に改善することができます。
実際のSELECT文で双方を確認してみたところ、先述のデータ量・分布の変化によって、効かせたいはずのインデックスが選択されていなかったり、頻出のソート条件に合う複合インデックスがなくテンポラリソートが起きていたりと、大小様々な問題が発見されました。その中でも今回特に取り上げたいのは以下です。
- JOINの起点が期待と違い、サブテーブルに持たせている種別の絞り込みから始まっていた
その後、メインテーブル側で数万件規模の候補行を読み、除外条件を1行ずつ評価していた
- → クエリの責務を分け、サブテーブルの絞り込み→結果を使ってメインテーブルの絞り込み、と2回クエリを発行
- 以前のパフォーマンス改善対応（NOT IN＋サブクエリでフィルタ）が、むしろ大きな集合を作るような実行計画に変化していた
→ サブクエリではなく、 カラム NOT IN (...) とクエリ自体を書き換えることで対応
1についてはEXPLAINの目視でもすぐに分かるところでしたが、2についてはEXPLAIN結果を分析したCoding Agentからの指摘で初めて気づきました。
以前の対応時は、たしかに除外対象をサブクエリとして扱うほうが効率的だったはずなのですが、現時点でのデータ分布ではそのサブクエリを作るために大きなスキャンが発生しており、インデックスを辿りながら直接条件を評価する方が速くできそう、という見立てが出されたのです。
同僚からその部分の実装意図を聞いていたこともあり、はじめは「いやいやそんな〜まさか〜」と半信半疑でしたが、修正版を試してみたところ劇的に計画が改善されました。余計なコンテキストを持たないほうが強いこともある……🥲
なお、今回はGORMを使ってクエリを発行している部分が修正の対象だったため、実際のクエリの書き換えにあたり、同僚であるponさんのgormgoldenが大変頼りになりました。アプリケーションコード上では良さそうに見えても、出力されたクエリが大事故…ということもときには生じ得るため、このようにBefore/Afterの確認を行いやすい状態にしておくことも大事ですね。
結果として、対象クエリ群のほぼ全てで改善が叶い、ベストケースでは50倍以上もの高速化が叶いました。やったぜ！
今回のようなクエリチューニング作業においては、Coding Agentの網羅性と手の速さがとても頼りになります。クエリ改善で振る舞いが変わってしまうことのリスクとテストの重要性は前述の通りですが、分析・複数の改善案出し・検証・実装にいたるまで、積極的にAgentに任せながら改善を進めたおかげで、従来の改善活動よりもずっと早く修正が叶いました。
振る舞いの担保についても、以下のようなソースを参照して破綻しないことを確認してもらいました。
- ヘルプサイトや仕様書
- 対応するクライアント（フロントエンド）の実装
これにより人の目だけでは拾いにくい検証観点も補え、動作確認も楽に行えました。
ただし、Agentは放っておくと限界までチューニングしようとしてしまいます。改善提案の中には、修正後のクエリが複雑になりすぎてメンテナンス性を損ねたり、修正量の割に改善効果が限定的だったりするものもありました。そのため計画時、または修正を走らせた後でも、「どの程度改善される見込みか」を確認しながら改善を採用する・しないの判断を行いました。
ほかにも、過去経緯などのコードや仕様に立ち現れないコンテキストを補完したり、ハルシネーションにツッコミを入れたり、計測と修正のサイクルを回すためにステップを分けたりなど、人間の仕事も思いの外残りました。とはいえ、今回の改善を回す過程で補完した文脈はドキュメントに残しましたし、モデルの進化も著しいため、次回以降はどんどん手がかからなくなっていくことが予想されます。
おわりに
今後の展望としては、今回の一連の流れを元に、SLO違反を検知→スロークエリをEXPLAINして原因を特定→修正・検証までを実行するSkillなどを作れると、改善のサイクルがより速く・多く回せそうです。
人間が本当に必要な判断に集中できるよう、またAI Agentたちにより多くの業務を任せられるよう、引き続き事業成長を支えるための改善活動を（も）進めていきます。
LayerXでは、AIと共に爆速で価値を生む・守る仲間を大大大募集しています！ご興味を持っていただけたらぜひこちらからご応募ください。
本職はマネージャーなので、AI時代のマネジメントどうなる〜？みたいな話も大好物です。カジュアル面談のお誘いもお気軽にどうぞ！
関連記事
Z.ai が GLM-5.2 を発表：100 万トークンのコンテキストとコーディング機能強化
Z.ai は、100 万トークン対応のコンテキストウィンドウや新推論制御機能を備えた「GLM-5.2」を発表した。同社は本モデルをコードベース全体を対象とした長期的なコーディングタスクに特化したアジェンシー型ソフトウェアエンジニアリング向けと位置付け、Coding プランユーザーに即時提供を開始し、来週には API やオープンウェイトの公開を予定している。
Z.ai が使用可能な 100 万トークンコンテキストと 2 つの思考レベルを備えた GLM-5.2 を発表、ベンチマークなしでリリース
Z.ai は最新大規模言語モデル「GLM-5.2」を発表し、100 万トークンの使用可能コンテキストウィンドウと 2 つの思考努力レベルを搭載した。同社は本モデルにベンチマーク結果を伴わずにリリースを行った。
Kimi K2.7 Code（Hugging Face リポジトリ）
Moonshot AI が、複雑なソフトウェア開発ワークフローでのタスク完了能力とトークン効率を向上させたコーディング特化型エージェントモデル「Kimi K2.7 Code」を発表した。この Mixture-of-Experts 構造を持つモデルは総パラメータ数が1兆に達し、OpenAI や Anthropic と互換性のある API を通じて利用可能である。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み