komatsuna「分散システムにおけるバグ分析手法」

Transcript

1. 分散システムにおけるバグ分析の実践手法 〜「バグを見つける QA」から「バグの構造を語れる QA」へ〜 Merpay QA komatsuna
2. なぜこの話か システム複雑化に抗う前提： AI（コーディングエージェント）を指揮する新たな QAスタイル  現状の課題：混迷する調査と対話  大前提： AIエージェントの指揮・活用 システム複雑化でバグ調査難易度が指数関数的に上昇 「コードを追えない」常識を AIが覆す マイクロサービス、複数フロント、複数環境、外部連携が混在し、どこで何が 起きているか把握困難。 Claude Code等に広大なコードベースを読ませ、ログ基盤も接続。人力読 解の限界を突破。 「再現不可」「情報不足」の不毛なラリー QAが「指揮官」として AIを動かす 開発者との往復で何日も浪費し、現場が疲弊。 QAは自ら詳細コードを精読せずとも、AIに指示を出すことでシステム全体 の振る舞いを探求可能に。 AIをバディに、 QAが「原因の構造」まで踏み込めると、  不毛なラリーは消失し、バグ調査のあり方は劇的に変わる
3. QA がこの手法を持つ価値 「バグを見つける QA」から「原因の構造を語れる QA」へ  Before (現状)  After (この手法を持つと ) QA「決済できません」 → 開発者「再現できない」 「情報ください」の不毛なラリーが発生   数日のタイムロス バグの再現手順と構造が明確になり即座に修正可能 QA「画面が表示されません」 ⇄ 開発者「設定ミス？」 事実確認を疑う不毛なやり取り  数時間のロス 修正サイクル短縮  誤った Pass 判定の防止 ロジックの理解に基づき、表面的な挙動に騙されない  修正漏れの発見 影響範囲を特定し、類似箇所の修正漏れまで見抜く
4. QA がこの手法を持つ価値 修正への貢献まで踏み込める 簡単なバグ 複雑なバグ — QA が直接 PR を出す — 修正候補を構造化して議論材料を提供 • typo、null チェック漏れ、 log メッセージ修正、明ら かな 1 行 fix • 「どのマイクロサービスで治すか」が論点になるケー ス • 開発者のレビュー工数も最小、その場で完結 • BE で fix する案 / FE で fix する案 / proto から直 す案、トレードオフを整理 • 開発者・PMが判断に集中できる状態を作る → バグ報告：「 TODOの追加」 →「意思決定の開始」
5. 実践手法 5
6. 調査フレームワーク 6 ステップ 漠然とした症状を根本原因に到達させ、修正まで繋ぐ定型手順 STEP 01 STEP 02 STEP 03 症状の構造化 観測軸の特定 観測 / 期待 / レイヤーを分離 どの ID で追うか決める ログ集約 → 絞り込み STEP 04 STEP 05 STEP 06 コード参照との突合 仮説 → 検証 → 報告 修正への貢献 異常の根拠を読む 1 つずつ潰す まず分布、次に個別 PR作成や議論材料提供 3
7. Step01: 症状の構造化 01. 観測 (Observation) 02. 期待 (Expectation) 03. レイヤー (Layer) 事実をありのまま捉える 本来の正しい姿を定義 境界線を見極める 先入観を排除し、エラーメッセージ、 ログ、発生した数値などの「実際に 起きている事象」のみを書き出す。 仕様や要件に基づき、「本来どう動 くべきだったのか」という期待値を明 確にし、観測された事実との差分を 浮き彫りにする。 クライアント、 APIゲートウェイ、マイ クロサービス、 DBなど、システムス タックのどこで不整合が発生してい るかを切り分ける。
8. Step02: 観測軸の選択（最重要ステップ） 何を key にして追うかで、見える景色が全然変わる 間違った材料を渡すと AIすら誤誘導されるため、最初の「軸の固定」は人間が決めるべき絶対の要所 ⚠ RISK / ユーザーID・時刻のみで追うリスク DECISION / 人間が軸を決定する 並行セッションによる「ログの混線」 状況に応じた最適な「観測軸」の選択 • 同一ユーザーが複数セッションを並行して走らせている場合、ユー ザーIDで追うとリクエストが混線して混乱を招く • Aさんのリクエストを追うつもりが、同時刻の Bさんのログを誤認する 事態が容易に発生する SITUATION / 状況 個別リクエストの追跡 trace ID / セッションID AIによる誤解の組み立て AIは渡された情報が混線していても、持ち前の推理力でもっともらしい虚偽のス トーリーを組み立ててしまうため、調査全体が無駄になります。 SITUATION / 状況 ルーティング問題を疑う SITUATION / 状況 全体傾向を掴みたい デプロイメント軸 API メソッド軸
9. Step03: ログ集約から絞り込み ログ調査は「まず全体分布、次に個別追跡」の順番を徹底する PHASE 01. 分布の把握 (AIに集計させる ) PHASE 02. 個別の追跡 (代表値を固定する ) 観測軸で集計し、偏りを見つける 1リクエストを「頭から尻尾まで」追う • 1件ずつ読む前に、まずはマクロな視点から集計させる • 偏りから代表となる 1件の「trace ID」を選択して固定 • 特定環境・特定 API・特定バージョン等の「偏り」を可視化 • 「EntranceからDBまで」1つのリクエストを完璧に追わせる • 分布が「これは異常だ」と言い切るための比較対象（基準）を 提示 • 正常時ログとの差分比較で、真のバグ箇所を突き止める 【分析観点】 • エラーは特定環境（カナリア、特定クラスタ）のみか？ • 特定のAPIメソッド、特定のリリースバージョン以降か？ ⚠ いきなり個別ログに入ると危険 正常・異常の判断基準がないまま個別ログに入ると、何が異常なのか判断できず にAIも人間も時間が溶けます。 ⚠ よくある失敗 : Step 1・2を飛ばしてここから始めてしまう 「とりあえずAIに投げる」と何時間も無駄に。必ず事前に構造化と観測軸の選定を行う
10. Step04: コードとの突合 「どこで」から「なぜ」へ。ログの事実とコードの条件を重ねて原因を特定する PHASE 01. 出力箇所の特定 PHASE 02. 到達条件の解読 ログのエラー文言でコードを検索 その行に達する「分岐と設定」を追う • ログ単体で判明するのは「エラーが発生した場所」という事 実のみ • 特定した出力行に到達するためのロジック（コードパス）を 読み解く • ログに記録されたエラーメッセージや例外スタックトレース をキーに、コードベースを検索 • どのような条件分岐（if文の評価）を通ってそこへ至ったか を調査 • 実際に出力処理が実行されている「具体的な該当行」をピ ンポイントで特定する • 影響を与えているシステム設定値や機能フラグ（Feature Flag）の状況を整理 Goal: 原因の構造化 「ログで観測された事実」と「コード上の到達条件」が重なった瞬間、真の障害原因が明らかになる
11. Step05: 仮説検証と報告 仮説出し・ドラフト作成は「 AI」、白黒つける現物検証は「人間」が主導する PHASE 01. AIによる仮説立案と1要素ずつの検証 PHASE 02. AI下書きによるフォーマット報告 複数仮説を確からしい順に出し、検証 「事象・原因・根拠・修正案」をセットで報告 • 構造把握後、AIに原因の仮説を複数出させる（1つに決め打ち しない） • 「設定変更で再現するか」「フラグをオフにして挙動が変わるか」 等を検証 • ⚠ 必ず 1要素ずつ実施： 同時に変更すると影響因子が特定 できなくなるため避ける • 検証は人間が主導：AIの自信満々な説明ではなく、現物での 検証で白黒つける • 白黒ついた段階で、曖昧さを残さず即座に報告フェーズへ移行 • 報告のドラフト作成（事象・原因・根拠・修正案）も AIに実行させ る • QAが事実確認して提出：AIが作成したドラフトを、QA自身が 検証結果と照らして最終確定 • 確定した原因・対策をセットでドキュメント化し、次の迅速な意思 決定へ Goal: 事象・原因・根拠・修正案のパッケージング 「AIを活用した仮説立案・ドラフト作成」と「現物による事実確認」で、迅速かつ正確な報告を実現する
12. Step06: 修正への貢献 報告して終わりではなく、もう一歩踏み込んでバグを確実に解消する 01. 簡易なバグの直接修正 02. 複雑なバグの解決支援 03. 類似箇所の修正確認 直接PRを出して解決 修正案と議論材料の整理 横展開と網羅性の検証 • Typo（誤字脱字）や単純な nullチェック漏れなどの簡易な バグが対象 • 「どのマイクロサービスで修正 すべきか」が論点となる複雑な 問題に対応 • 「同じ構造のバグが他の箇所 に潜んでいないか」を徹底的に 疑う • QA自身が直接プルリクエスト （PR）を作成・送付する • 具体的な複数の修正案とその トレードオフを論理的に整理 • • 開発チームに負担をかけず、 迅速な修正サイクルを実現 • 関係者が意思決定しやすい議 論のたたき台を提供する 類似ロジックやコンポーネント における修正漏れの有無を確 認 • 根本からバグを根絶し、調査タ スクを完全な形で完了させる
13. まとめ — 3 原則 01 観測軸を先に決める 02 現物で裏を取る 03 修正の網羅性を疑う
14. Thank you! ご清聴ありがとうございました