Coding AgentとはじめるMySQLパフォーマンスチューニング
こんにちは！バクラク申請・経費精算のエンジニアリングマネージャーをやっています、@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の確認を行いやすい状態にしておくことも大事ですね。 github.com 結果として、対象クエリ群のほぼ全てで改善が叶い、ベストケースでは50倍以上もの高速化が叶いました。やったぜ！ デプロイ後にアラート対象のクエリが激減した様子 Coding Agentと人間との役割分担 今回のようなクエリチューニング作業においては、Coding Agentの網羅性と手の速さがとても頼りになります。クエリ改善で振る舞いが変わってしまうことのリスクとテストの重要性は前述の通りですが、分析・複数の改善案出し・検証・実装にいたるまで、積極的にAgentに任せながら改善を進めたおかげで、従来の改善活動よりもずっと早く修正が叶いました。 振る舞いの担保についても、以下のようなソースを参照して破綻しないことを確認してもらいました。 ヘルプサイトや仕様書 対応するクライアント（フロントエンド）の実装 これにより人の目だけでは拾いにくい検証観点も補え、動作確認も楽に行えました。 ただし、Agentは放っておくと限界までチューニングしようとしてしまいます。改善提案の中には、修正後のクエリが複雑になりすぎてメンテナンス性を損ねたり、修正量の割に改善効果が限定的だったりするものもありました。そのため計画時、または修正を走らせた後でも、「どの程度改善される見込みか」を確認しながら改善を採用する・しないの判断を行いました。 ほかにも、過去経緯などのコードや仕様に立ち現れないコンテキストを補完したり、ハルシネーションにツッコミを入れたり、計測と修正のサイクルを回すためにステップを分けたりなど、人間の仕事も思いの外残りました。とはいえ、今回の改善を回す過程で補完した文脈はドキュメントに残しましたし、モデルの進化も著しいため、次回以降はどんどん手がかからなくなっていくことが予想されます。 おわりに 今後の展望としては、今回の一連の流れを元に、SLO違反を検知→スロークエリをEXPLAINして原因を特定→修正・検証までを実行するSkillなどを作れると、改善のサイクルがより速く・多く回せそうです。 人間が本当に必要な判断に集中できるよう、またAI Agentたちにより多くの業務を任せられるよう、引き続き事業成長を支えるための改善活動を（も）進めていきます。 LayerXでは、AIと共に爆速で価値を生む・守る仲間を大大大募集しています！ご興味を持っていただけたらぜひこちらからご応募ください。 open.talentio.com 本職はマネージャーなので、AI時代のマネジメントどうなる〜？みたいな話も大好物です。カジュアル面談のお誘いもお気軽にどうぞ！ jobs.layerx.co.jp
- MySQL
- 生成AI
- パフォーマンス
- Go
TSKaigi 2026に参加しました #TSKaigi
こんにちは。Ai Workforce事業部 開発部の id:ninjinkun です。 先日開催されたTSKaigi 2026において、LayerXはゴールドスポンサーおよび学生支援スポンサーとして協賛しました。 このエントリでは弊社社員の登壇資料の共有、1日目の最後に行われた基調講演の様子、そしてLayerXブースの様子をレポートします。今回はゴールドスポンサーとしての出展に加え、LayerXから総勢4名のエンジニアが登壇しました。まずはそれぞれの登壇資料からご紹介します。 登壇資料 API設計や型の推論にまつわる話まで、幅広いテーマでの登壇となりました。各発表の資料は以下の通りです。もしご興味のある方はぜひご覧ください。 基調講演 TS7: How We Got There 自身の中でもっとも印象に残ったセッションが、1日目最後の基調講演です。MicrosoftでTypeScriptコンパイラのGo移行をリードしているJake Bailey氏による基調講演が行われました。内容としては、セルフホストで書かれていたTSコンパイラが長年抱えていたパフォーマンスの問題の紹介から始まり、どのように移行プロジェクトが始まったのか、なぜGo言語を選んだのかという説明がわかりやすく展開されました。そして最後に劇的に改善されたパフォーマンスのデモで締め括られるというストレートかつ熱い構成で、会場も熱気に包まれていました。 印象的だったのは、VSCodeのコードが頻繁にベンチマークとして使われていたことです。VSCodeのコードに対して型検証を行う際の速度比較や、実際にリポジトリでtscを実行するデモ（氏曰く「呪われたコマンド」）が行われていました。VSCodeを引き合いに出しているのはおそらく社内に対する説明と社外に対するアピールの両方の目的があるのでしょうが、理にかなった戦略だと感じました。この例から伝わる通り、Microsoft自身がTypeScriptを大規模に利用しており、パフォーマンスを改善し続ける強い動機を持っている点は、いちTSユーザーとしても言語の将来に期待が持てる内容でした。 また私個人としては、2日目の昼食の時間に氏が近くに座っていたので、多少勇気を出して話しかけてお礼を言えたのがよかったです。非公開リポジトリでの数ヶ月の試行錯誤を経てリポジトリを公開した話や、なんでC#にしないんだと頻繁に言われる話などを冗談めかして語ってくれました。 すでにGo移行プロジェクトはtypescript-goリポジトリで公開されており、誰でも試すことが可能です。氏のおすすめはまずVSCode拡張のTypeScript (Native Preview)を利用することで、入れるだけでVSCodeでTSファイルを開いてから型解析が完了するまでの速度が大幅に向上するとのことでした。Go移行プロジェクトのリリース版であるTS7はComing Soonとのことなので、楽しみに待ちたいと思います。 LayerXブース ブース撤収完了しました！遊びに来てくださったみなさんありがとうございました、また来年お会いしましょう🙌#TSKaigi pic.twitter.com/J0TXcO25lG— LayerX Tech (@LayerX_tech) 2026年5月23日 今回LayerXとして2日間スポンサーブースを出展しました。ブースでは@syumai、@やた、@Yokan の3名が社内からヒアリングしてきたTypeScriptやフロントエンドに関連した事例をディスプレイで展示し、来場者の方の興味に合わせてその中からトピックを選び説明を行いました。内容は変数をGUIで選択しながら計算式を記述できる複雑なフォームを実装した話、ElectronでPC利用を記録するアプリを開発した話など多岐にわたり、ブースに訪れてくださった方にも好評でした。残念ながらコンテンツはその場限りの公開だったのですが、今後また紹介できればと思います。 私自身は今年4月に入社したばかりのため、前述のコンテンツや会社の事業であるバクラクやAi Workforceについて最初はたどたどしく説明していたのですが、2日間ブースに立ち続けてある程度スムーズに説明できるようになりました。ブースに立ちながら、LayerXの社名はご存知でも実際どんな事業をやっているのかご存知でない方もまだ多いことを実感したので、今後もこういった出展や社外へのアウトプットを継続していく必要性を強く感じました。 アフターイベントのご案内 6/3(水)にUbie様、ビットキー様との共催でアフターイベント「歴史あるプロダクトで、"AIに任せられる領域"をどう広げるか？TSKaigi アフターイベント」を開催します。 TSKaigi本編では話しきれなかったTypeScriptに関するトークに加え、懇親会でより学びを深められる機会です。ぜひ下記connpassリンクよりお申し込みください。 終わりに 私は今回初めてTSKaigiに参加しましたが、普段触っていないバックエンドTSの世界の話も聞くことができ、改めてTypeScriptの表現力を見直す機会になりました。 運営の皆様、スピーカーの皆様、そしてブースに立ち寄ってくださった皆様、ありがとうございました！
- TypeScript
- Go
TSKaigi 2026にゴールド、学生支援スポンサーとして協賛し、4名が登壇します #TSKaigi
バクラク事業部ソフトウェアエンジニアの矢田(@0e2b3c)です。 LayerXはゴールドスポンサー並びに学生支援スポンサーとしてTSKaigi 2026に協賛させていただきます。 加えて、弊社ソフトウェアエンジニアである泉(@izumin5210)、福岡(@syumai)、山本(@minako-ph)、田中(@ypresto)が登壇者として参加を予定しています。 スポンサーブースのご紹介 昨年度までは社内ADRを公開するというブース内容でしたが、今年度は新しい取り組みとして社内の面白かった・苦労した実装を紹介するブースを出展予定です。 弊社の事業の１つであるバクラク事業部の各チームにフロントエンドやTypeScriptに関するインタビューを行い、それをスライドとしてまとめたものをブースにて展示予定です。 LayerXの実際の開発を体感できるこれまでにない取り組みですので、是非当日は足をお運びください。 登壇のご紹介 開発体験を左右するライブラリの API 設計 ― GraphQL スキーマ構築ライブラリから考える@izumin5210 TypeScript で GraphQL を実装するためのライブラリには、さまざまな API 設計が存在します。Schema-first と Code-first といったスキーマ記述アプローチの違い、スキーマと TypeScript 型をどのように接続するか、resolver をどのような形で記述させるかといった設計上の選択は、単なる記法の違いではなく、開発者がどのようにスキーマと向き合い、どのように設計を組み立てるかという開発体験そのものを規定します。 本発表では、既存の GraphQL 実装ライブラリを比較しながら、スキーマ構築と resolver 実装の API 設計を整理します。特に、スキーマと型の結びつけ方や、開発者に与えるメンタルモデルの違いに注目し、それぞれのトレードオフを明らかにします。そのうえで、AI Coding が前提となりつつある現在、ライブラリに求められる API 形状や型情報の役割がどのように変化しうるのかを検討します。整理を踏まえ、新たに開発した GraphQL 実装ライブラリ「gqlkit」の設計を一例として紹介し、今後の GraphQL 実装基盤の方向性を提案します。 日時：Day1 / 11:00 ~ 11:40 場所：RightTouchトラック 2026.tskaigi.org Oxlintはいかにしてtsgolintのlint ruleを呼び出しているのか@syumai Oxlintは、VoidZeroによって開発されている、Rust製の高速なJavaScript / TypeScript Linterです。 既に安定版のv1がリリース済みですが、実は、そこにはTypeScriptの型情報に依存するルールの実装が含まれていません。 その役割を担うtype-aware lintingの実装は、typescript-goベースの別リポジトリである、oxc-project/tsgolintで行われています。 tsgolintを通じてlintを行うことで、Oxlintは no-floating-promises などのlint ruleをサポートすることができます。 つまり、Rust実装であるOxlintから、Go実装のtsgolintを呼び出していることになるのですが、一体これはどのように実装されているかご存知でしょうか？ 本発表では、発表者がOxlintおよびtsgolintの実装を読んで知った、プロセス間通信に基づくOxlintとtsgolintの通信方法についての概要と、tsgolint側にルールを追加する度に必要となるOxlint側での実装について解説を行います。 また、発表者が、tsgolintにカスタムルールを実装しようとした過程で得た知見についてもお話しします。 日時：Day1 / 17:20 ~ 17:50 場所：Leveragesトラック 2026.tskaigi.org 柔軟なPDFレイアウトエディタを支える型システム設計 — Discriminated UnionとConditional Typeの実践@minako-ph バクラク請求書発行では、請求書・見積書・納品書などのPDFレイアウトをGUIで自由にデザインできるビジュアルエディタを提供しています。テキスト・画像・動的テーブルなど6種類のノードを自由に配置し、実際の書類データをバインドしてPDFを生成する仕組みです。 しかし自由度が高いほど、コードの複雑さも増します。テキストノードにはフォント設定があり、テーブルノードには列定義があり、画像ノードにはフィット方法がある——同じ「ノード」でも中身はまったく別物です。さらにノードの値は固定テキストかもしれないし、書類データから動的に取得するかもしれない。こうした組み合わせの中で「テキストノードなのにテーブルの列定義を参照してしまう」ような取り違えをどう防ぐか。人のレビューに頼るのではなく、型に任せられないか—— 本トークはその問いから始まります。 Protocol Buffersのoneof定義からZod経由でDiscriminated Unionを自動生成する仕組み、Conditional Typeでノード型名から値型を安全に取り出すパターン、DeepPartialでReducerの部分更新を型安全にする設計、そして同一の型定義でエディタのプレビューとPDF本番生成の両方を駆動するアーキテクチャを、具体的なコードとともに紹介します。 日時：Day2 / 15:50 ~ 16:20 場所：RightTouchトラック 2026.tskaigi.org TypeScriptはどのようにどこまで推論できるのか ─ とにかく as は禁止で@ypresto(スポンサーセッション) TypeScript の型チェックは、型推論、Control Flow 解析、そして各種ガードレールという強力な3つの仕組みに支えられています。そしてInferred Type Predicates (filter()の型推論) のように、以前は手でケアしていた場面でも自動で正しい型が付くようになるなど、これらの機構は年々強化されてきました。 一方これらの機構でカバーできるにも関わらず as (as constを除く) を使用してしまうことは、AI 時代に必要な安全性を自ら緩めることになり、それは "敗北" です。 本セッションは、Contextual Type をはじめとして、TypeScript の推論機構やガードレールの仕組みと制限を紹介し、その安全性を活かすことにより、「as全部禁止」に対して「主張が強い」と返されないように試みるものです。 日時：Day2 / 12:30 ~ 13:30(スポンサーセッション内) 場所：Leveragesトラック 2026.tskaigi.org TSKaigi 2026について 2024年に産声をあげ、2025年も大盛況のうちに幕を閉じた TSKaigi を今年も開催します！ 私たちは、誰かの発表を聞くだけでなく、他の誰かに向けて発表することもまた学びの一つだと考えています。 参加者、登壇者、スタッフ、スポンサーをはじめ、TSKaigi に関わるすべての人たちが互いに学び合い、新たな繋がりを生み出し、型にとらわれないエンジニアとして生き生きと活躍できる世界を目指します。 TypeScript に関するあらゆるテーマを扱う国内最大級のカンファレンスとして、まさに「型破り」なイベントを目指し成長を続ける TSKaigi にご期待ください。 詳細やタイムテーブルなどは TSKaigi 2026公式サイト をご覧ください。 協賛の背景 わたしたちは技術コミュニティから日々たくさんの技術的な知見を頂いたり、実際にOSSとして活用させて頂いています。 LayerXの掲げる行動指針である「徳」の観点からも技術コミュニティから一方的に恩恵を受けるだけでなく、技術コミュニティへの貢献を継続して行っています。 アフターイベントのご案内 TSKaigi 2026終了後、6/3(水)にUbie様、ビットキー様との共催でアフターイベント「歴史あるプロダクトで、"AIに任せられる領域"をどう広げるか？TSKaigi アフターイベント」を開催します。 TSKaigi本編では話せなかったTypeScriptトークや懇親会でより学びを深められる機会となりますので、是非下記connpassリンクよりお申し込みください。 bitkey.connpass.com 最後に 過去最多の登壇人数、新たなスポンサーブースで、これまでで最大規模となるTSKaigiへ参加します。 TypeScriptやフロントエンド開発に関してディスカッション、交流できればと思いますので、是非お気軽にスポンサーブースやセッションへ足をお運びください！
- TypeScript
- GraphQL
- Go
- Rust
- カンファレンス
Self-Maintainable CI ── Go testの失敗をClaudeで自動修復する仕組み
はじめに LayerX バクラク事業部 Platform Engineering 部 Enabling グループの shibutani です。 CIのテストが落ちたとき、開発者がやることは意外と多いです。ログを読み、原因を特定し、担当者を探し修正依頼 or 自分で修正する。これがrace conditionやflaky testのように再現しにくいものだと、対応はさらに後回しにされがちです。 今回、Go testの失敗を検知したらClaudeが自動でログを分析し、担当チームに通知し、修正PRまで作成する仕組みを構築しました。本記事ではその設計と実装を紹介します。 -race フラグの分離と、その先の課題 出発点はPull Request作成時のCIの速度改善でした。これまではPull Request作成時のCIで -race フラグ付きの go test を実行していましたが、-race フラグはGoのrace detectorを有効にするオプションで、公式ドキュメントによるとメモリ使用量5〜10倍、実行時間2〜20倍のオーバーヘッドが発生します。Pull Requestのたびにこのコストがかかり、開発者のフィードバックループを遅くしていました。 Agentic codingの普及によりPull Requestの量が増えつつある今、CIのthroughputを上げることの重要性は高まっています（参考: ハーネスエンジニアリング：エージェントファーストの世界における Codex の活用）。そこで -race フラグをmainブランチへのpush後のCIに移し、Pull Request作成時のCIは -race なしで高速に実行する構成に変更しました。 しかし、単純に分離するだけでは新たな問題が生まれます。Pull Request作成時のCIで即座にフィードバックされていたrace conditionやflaky testが、mainブランチにマージされて初めて検出されるようになります。なお、バクラクではmainブランチへのマージが即本番デプロイされるわけではなく、QAなどの工程を経てリリースされるため、mainで検出しても本番への影響を防ぐ余地はあります。とはいえ、race conditionは「稀にしか起きない」「再現しにくい」、flaky testは「もう一回走らせたら通る」という性質から、mainブランチで失敗しても対応が後回しにされがちです。放置すればrace conditionは本番で影響の大きいバグとして発現し、flaky testはCIの信頼性を徐々に損ないます。 分離によるCI高速化のメリットを享受しつつ、検知した失敗が放置されない仕組みが必要でした。そこで、失敗の分析・担当チームへの通知・修正PRの作成までを自動化するパイプラインを構築しました。 全体のフロー mainブランチへのpushをトリガーに、以下のフローで動作します。 flowchart TD A[mainへのpush] --> B["go test -race<br/>testwrapper経由"] B --> C{失敗あり？} C -- No --> D[通知なし] C -- Yes --> E[Claudeによる失敗ログ分析] E --> F{"既知のflaky<br/>のみ？"} F -- Yes --> G[通知なし] F -- No --> H[CODEOWNERSからオーナーチームを特定] H --> I[Slackにグループメンション付きで通知] I --> K{"DATA RACE<br/>あり？"} K -- Yes --> L[修正 Draft PR を作成] K -- No --> M["Flaky Mark PR<br/>+ 修正 Draft PR を作成"] ポイントは、すべての失敗を検知しつつ、既知のflaky testによるノイズは通知しないことです。通知の信頼性を保つことで、「またflakyか」と無視される状態を防ぎ、本当に対処が必要な失敗に開発者の注意を集中させます。 testwrapperによるテスト実行 通知の信頼性を保つためには、既知のflaky testと新規の失敗を区別する仕組みが必要です。 go test を直接実行する代わりに、社内で整備している testwrapper というCLIラッパーを経由して実行しています。この仕組みは Tailscaleのtestwrapper/flakytest を参考にしたもので、弊社の @upamuneが Go Conference 2025での発表 で詳しく解説しています。テスト関数内で flakytest.Mark() を呼ぶことで「このテストはflakyである」と宣言し、testwrapperがその情報を検知して自動的に最大3回までリトライします。 func TestSomething(t *testing.T) { flakytest.Mark(t, "https://github.com/org/repo/issues/123") // ... } flakytest.Mark() の第2引数にはTracking IssueのURLを渡します。なぜflaky化されているのか、いつ解消する予定かをIssueで管理する運用です。 既知のflaky testのみで失敗した場合は、testwrapperが自動リトライを試みます。リトライで通ればそのまま成功として扱い、リトライしても失敗が残った場合でもSlack通知やPR作成は行いません。既知のflaky testとして管理されている以上、対応済みと判断するためです。それ以外の失敗が含まれる場合に、次のClaudeによる分析フローに進みます。 Claudeによる分析と修復 テスト失敗を検知したら、Claudeがログ分析から修正PRの作成までを一気通貫で行います。この自動化はGitHub Actionsのカスタムアクションとして実装しており、Anthropic SDKを通じてClaude APIを呼び出しています。 ログの絞り込み CIのログをそのままClaudeに渡すのではなく、関連度の高い部分に絞り込んでからプロンプトに含めています。DATA RACEブロックが検出された場合はそのブロックを優先的に抽出し、そうでない場合は --- FAIL: の前後20行を抽出します。 ログ全体を渡すとコンテキストウィンドウを消費するだけでなく、関係のない情報にClaudeが引きずられるリスクもあります。ノイズの除去が分析精度の向上に直結するため、この前処理は重要です。 オーナーチームへの通知 失敗したテストのパッケージパスからCODEOWNERSを逆引きしてオーナーチームを特定し、GitHubチームとSlackグループのマッピングを通じてグループメンションを送ります。「テストが失敗した → 担当チームに通知が届く」という流れを自動化することで、誰にも気づかれないまま放置されるリスクを減らしています。 SlackへのCI失敗通知の例 失敗種別に応じたPR自動作成 Claudeは失敗の種別に応じて、異なるPRを自動作成します。 DATA RACEが検出された場合、Claudeがソースコードを分析し、race conditionを修正するDraft PRを作成します。 DATA RACEなしだが未マークのテスト失敗の場合は、2種類のPRを作成します。 FlakyをMarkするPR: 該当テストに flakytest.Mark() を追加し、tracking Issueも同時に作成します。このPRをマージすると、次回以降はtestwrapperが自動リトライするようになり、Slackへの通知も止まります。 Flakyを修正するDraft PR: テストの非決定性を除去する修正案をClaudeが生成します。 いずれもDraft PRはエンジニアがレビューするまでマージされません。Claudeが自動でコードを書きますが、最終的な判断は人間が行う設計です。 FlakyをMarkするPRをマージするだけで、そのテストに起因する通知が次回から止まります。これにより、対処すればするほどノイズが減り、通知の信頼性が上がっていく好循環が生まれます。 おわりに 今回構築した仕組みのポイントをまとめます。 -race フラグをmainブランチのCIに分離し、Pull Request作成時のCIの高速化とrace condition検知を両立した testwrapperと flakytest.Mark() で既知のflaky testを自動リトライし、通知のノイズを除去した Claudeによるログ分析・PR自動作成で、検知から修正提案までを自動化した CODEOWNERSの逆引きでオーナーチームにグループメンションし、通知の見落としを防いだ race conditionもflaky testも、放置されがちな問題です。原因の特定が難しく、影響がすぐには見えにくいため、目の前のタスクに押されて後回しになりがちです。この仕組みでは、検知・通知・修正提案を自動化することで対処のハードルを下げ、開発者が本来の開発に集中できる環境を目指しました。
- Go
- CI/CD
- GitHub Actions
- 生成AI