調査タスクをAIと乗り切る 〜過去の調査をナレッジ化し 調査手順をスキルにする〜

GO TechTalk #34 データサイエンティストの生成AI活用で発表した資料です。

■ YouTube
https://www.youtube.com/watch?v=7t9fIeBU2MQ
■ connpass
https://jtx.connpass.com/event/370877/

Transcript

1. 調査タスクをAIと乗り切る 〜過去の調査をナレッジ化し 調査手順をスキルにする〜 GO TechTalk #34 データサイエンティストの生成 AI活用 宮本 真実 GO株式会社
2. GO株式会社 AI技術開発部 AI1グループ / 宮本 真実 • • 2023年 GO株式会社 入社 タクシーアプリ『GO』のアルゴリズム開発 ◦ 到着時間予測、乗車場所の推薦などを担当 ◦ 現在は相乗りサービス『GOエコノミー』の予約 ・運行管理も 猫を2匹飼っています。手芸やハンドメイドが趣味です。 © GO Inc. 2
3. アジェンダ 背景 相乗りサービス『GOエコノミー』の運用で日々発生する「調査タスク」とは 課題 • • もっと早く、もっと網羅的に調べたい 調査できる人が限られる／記録の運用が続かない 解決策 1. 2. 3. 4. 過去の調査をナレッジ化する AIが調査できる環境を整える 調査方法をスキルとして整備する 記録が信頼できる状態を保つ 結果 • • やってみてどうだったか わかったこと © GO Inc. 3
4. 01 背景 〜相乗りサービス『GOエコノミー』の運用で 日々発生する「調査タスク」とは〜 © GO Inc. 4
5. 今日話す「調査タスク」とは 止血のための緊急の調査 起点 分かっていること 知りたいこと 例 原因調査 Sentryなどのエラー通知 止血対応の後・問い合わせ エラーが出ていることだけ 起きた事象は分かっている • • • 今も出ているか 影響範囲 どう止めるか • • • なぜその挙動が起きたのか 影響範囲 どのように対応するか • • リリース直後にエラーが出た 高負荷でエラーが出た • • KPIが悪化した 乗務員さん・ユーザから見て挙動 が不自然だった 障害対応 分析寄り どちらもログとコードを付き合わせ 状態を理解する作業 © GO Inc. 5
6. システム構成と調査フロー 相乗りサービス アルゴリズムシステム APIリクエスト/ レスポンス BigQuery (データ保存) API ログ MySQL アプリ ログ Sentry (エラー追跡・アラート) アプリケーションログ (エラーのみ) 相乗りサービス アルゴリズムサーバ MySQLデータベース （状態管理） アプリ ログ 通知 アプリケーションログ 調査に必要な情報を取得 複数データソースに跨って 調査を行う Grafana (モニタリング) © GO Inc. 6
7. 02 課題 © GO Inc. 7
8. 「早く・網羅的に」調べたいが、現実は遠い 相乗りはまだまだ成長途中 • 機能追加やキャンペーンが続く 調査・不具合対応にスピードが要る MySQLやBigQueryのクエリが 1調査あたり最大16本 仮説を立てて手動で実行 相乗りシステムは複雑 • • • 予約を車両に割り当てる処理は定期的に動くバッチ ユーザや予約がそれぞれ10種類以上の状態を持つ 複数の外部システム・アプリと連携している 「どこで止まったか」「何が原因か」を出すには ログとコードの突き合わせが必要 網羅的に調べるのも大変 © GO Inc. 8
9. 調査が人に依存してしまう 得意な領域が人によって異なり、調査できる人が限られる スプレッドシートで管理するルールを作ったが うまく回らなかった 書くのが大変 手動なので運用を忘れる 書く人・書かない人が出る © GO Inc. 9
10. とりあえずAIにやらせてみたが、うまくいかなかった 属人化から抜けるため、AI単独での自動調査を試みた結果 調査タスク整理前 属人化から抜け出したい 比較検証した結果... 各々がAIと密にやりとり AIにひとりでやらせてみる あまりよくなかった... 人により進め方が異なり結局属人化 人が調査した結果を正解として比較 結論を急いだり見当違いだったり 「丸投げ」ではなく 知見・ドキュメント・過去のナレッジを渡してAIに調査させる形が必要 © GO Inc. 10
11. 03 解決策 © GO Inc. 11
12. 解決策 人間がどのように 調査を行っているのかを 振り返りながら整理 ① 調査をナレッジ化する 過去の記録はAIが参照できるようにリポジトリに置く 形骸化しないようAI自身にナレッジを貯めさせる ② AIが調査できる環境を整える Grafana MCPを活用しログをAIから読めるようにする ③ 調査方法とエージェントスキルを整備する 調査の手順と 間違えやすいクエリをあらかじめ用意しておく ④ 古くなった作業記録を定期的に見直す 古くなった記録を自動で見つける仕組みを作る ➡ 毎回「過去の記録が役に立ったか」を振り返って記録する © GO Inc. 12
13. ① 過去の調査をナレッジ化する © GO Inc. 13
14. ①-1 調査記録をコードと同じリポジトリに置く AIが仕様書やコードと一緒に過去のナレッジを読める状態を作る これまで：人間向け これから：AI主導 findings.md --- 📝 スプレッドシート 👤 人間が手書き 📂 Markdown（リポジトリに置く） 🤖 調査中にAIがまとめる type: 状態遷移調査 title: 便乗できなかった原因調査 description: 同一エリア・同一乗車時刻の2ライダーが別 トリップに割り当てられ便乗が成立しなかった事例。 AIには文脈が読めず検索しづらい コードと同じ文脈でAIが読める ... --- # 便乗できなかった原因調査 investigation/ ├── index.md <- 自動生成される「調査記録の一覧」 └── 20260901-piggyback-failure/ ├── findings.md <- 結論と、次の調査者が引くための情報 └── src/ <- 調査で書いたクエリ（実行すれば再現できる） **調査日**: 2026-◼-◼ **調査対象 **: - ライダーA: ◼◼◼ - ライダーB: ◼◼◼ ## 結論 ... --- ## 仕様書修正点 次の調査への引き継ぎとなる ... --- © GO Inc. 14
15. ①-2 AIが横断して調査できる形にする フロントマターに必要な項目を持たせ、調査記録を蓄積する YYYY-MM-DD-****-failuer symptoms: … cause: … verify: … status: … — 項目 役割 例 symptoms 次の調査者が「自分の症状と 同じか」を判断する見出し マッチング中の画面が解消しない cause 原因 xxxに停車地点データがないため verify どこを見れば確認できるか。 コードの場所かクエリ xxx.pyのx行目 未修正 / 修正済み / 仕様通り 修正済み Markdownファイルの先頭に AIが読みやすいメタデータを持たせる AIにとっての「検索タグ」の役割 status xxxの処理 AI自身が参照しやすいようにデータを構造化し、調査記録を蓄積することで 全記録を横断し調査できる状態を作る © GO Inc. 15
16. ② AIが調査できる環境を整える © GO Inc. 16
17. ② AIが調査できる環境を整える 前提 複数のデータソース（MySQL, BigQuery, Grafana, Sentry）に跨った調査が必要 GrafanaをMCP化し AIに調査を任せる （ログやデータの可視化・分析ツール） アプリケーションログは構造化されておらず、手動クエリの ハードルが高い MCP化による効果 • AIが時間や対象を変え自律的に何度もクエリを投げる ため網羅性が向上 • スタックトレースの全文解析により、詳細な深掘りが 可能に 調査のスピードと網羅性の向上につながる 調査の起点となる Sentry・BigQueryはMCP化しなかった 調査のメインはGrafanaに対するクエリで完結するた め、システムの無駄な複雑化を回避 Sentry エラー情報が整理されており、手動でコピペしてAIに 渡す運用が最速 BigQuery 構造化されていてクエリが容易、CLIでも実行可能なた め現状の運用を維持 セキュリティの都合上AIから直接アクセスで きないものに関しては、必要に応じて人がク エリを実行し連携する © GO Inc. 17
18. ③ 調査方法とエージェントスキルを整備する © GO Inc. 18
19. ③-1 どの種類の調査かを見極めさせる 同じ「調査」でもやることが異なるためエージェントスキルを分ける 事象 調査の始め方 調査の終わり方 スキル名 1件を深掘りする 傾向を調べる アルゴリズムを検証する 「このエラーが発生した」 「相乗り率が下がった」 「乗客を乗せる順番がおかしい」 logを時系列で調査 期間を決めて集計 期待値を人間に聞く 原因が判明 差の説明ができる 期待値との差分を説明できる investigate analytics-workflow investigate-algorithm 見極めはAIにさせる © GO Inc. 19
20. ③-2 人のやり方をもとに調査手順を整える 人が行っていた「調査の段取り」をスキルとして定義し、AIに守らせる AIが指示なしでやりがちなこと 飛ばしてはいけない手順 スキル上の制御 1. いきなりクエリ作成・仮説検証 過去の類似調査を確認 過去資産の参照を強制 2. 取得できないデータを取ろうとする 取得できるデータで解決できるかを見極める 調査範囲の境界判定を強制 判定不能ならそこで止める 3. 断片的なログを見て推論 対象の時系列を並べて全体像を掴む 関連ログを自動収集させ俯瞰させる 4. 仕様を勘違いしたまま調査を進める 5. 人に聞かずに何十ステップも消費 6. 仕様書を読む （概要 → ユースケース → 詳細） 調査の段取りを決めて、人に確認をとる 前の結果を見る前に次を書かせない 結果を確認し、人に確認を取る © GO Inc. 20
21. ③-3 間違えたクエリは正解を関数で残す スキルを整えても.. 仕様の勘違いやネストの考慮漏れなどで誤ったクエリを書くことがある 知識の資産化 仕様書を読んでも正しく書くことが難しい複雑なクエリや ドメイン知識を Python関数として定義して提供 df = assignment.new_rider_assignment(date="2026-07-26", ids=[...]) • • 戻り値の形式担保や、ネスト構造の吸収を関数側で保証 引数の検証を共通処理化 AIが自己判断で間違える回数を減らすため 調査用の関数ライブラリを充実させていく © GO Inc. 21
22. ④ 記録が信頼できる状態を保つ © GO Inc. 22
23. ④ 記録が信頼できる状態を保つ 人とAIが協調して調査記録の正確性を維持する 👤 人が調査結果が正しいか 🤖 AIが古くなった記録を見つ 🤖 AIが毎回振り返って記録 を判断する け再確認する する • 人がレビューし、正しけれ ば記録に残す • 人のチェックが済んでいな い記録は「未検証」として おく 「原因箇所」と「確認日」を記録 コードが変わっている場合は再確 認が必要と判断し、記録を更新 • • • • 過去の記録は役に立ったか 無かった記録 無かったクエリ AI が間違えたところ 記録だけでなく修正、クエリの保 存を行う © GO Inc. 23
24. 04 結果 〜やってみてどうだったか・分かったこと〜 © GO Inc. 24
25. 整備してどうだったか 良くなったこと 調査のスピードが上がった • 同じ調査が 半日 ➡ 30分ほど 見えている課題 クエリを間違えやすいため、クエリの関数化だけ でなく、ログやテーブルに対するドキュメント化 が必要 調査ハードルが下がった • Grafanaのログは構造化されたテーブルと 異なりクエリを書くのが大変だった 調査の網羅性が上がった • 似た事象が他にないかの調査まで手が回よ うになった © GO Inc. 25
26. まとめ 構築した仕組み 良かったこと 分かったこと 調査記録の構造化 スピードと網羅性の向上 「丸投げ」は NG AIが読める形でコードと共に管理 半日の調査が 30分に短縮 類似事象まで手が回るように 知見やドキュメントが必要 完全自動化は不要 GrafanaのMCP化 初動の迅速化 非構造化ログの調査を AIへ委任 手作業も手順化すれば属人化は防げる 複雑なクエリ作成のハードルが低下 資産の整備 調査手順を「スキル」、 クエリを「関数」化 運用の仕組み化 古い記録の自動検知と毎回の振り返り まだ運用途中。アップデートしていきます。 © GO Inc. 26
27. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください © GO Inc.