Claude CodeのAgent Teamsでテクニカルサポート調査を行いやすくする

はじめに

どうもfujimmm331です。最近は週1で仕事終わりに走って脳内のキャッシュを消す取り組みをしています。

今年からCRE（Customer Reliability Engineering）チームに所属しています。CREチームの主要業務のひとつがテクニカルサポートです。お客様からの技術的な問い合わせに対して、コードやログを調査し、原因を特定して回答します。

問い合わせは週に4〜5件。もともと5人のチームで回していましたが、他プロジェクトの立ち上げなども重なりチームが半減しました。自分はもともとフロントエンドがメインの領域で、バックエンドやインフラを含むシステム全体の調査には時間がかかります。このままでは回らないと気づき、調査をなんとかAIに任せらえないかと取り組むことにしました。

最初の試み：Claude Codeにそのまま調査させる

最初に試したのは、Claude Codeに問い合わせ内容を渡して「調査して」「メールの回答をまとめて」と依頼する素朴なアプローチです。

Claude Codeはコードベースを自在に読め、Sentry MCPのMCPなどとも連携できるため、即戦力となってくれそうと感じていました。

つまずき：速いが信頼できない

しかい、実際に使ってみると3つの問題にぶつかりました。

1. 速すぎてついていけない

AIは数分で大量のコードを読み、調査結果をまとめてきます。しかし、自分がその結果を理解するのに結局時間がかかります。成果物を読み解く負荷が、自分で調査するのとそんなに大差なかったです。

2. 決めつけで調査する

最初に思いついた仮説に飛びつき、それを裏付ける証拠だけを集めてきます。「原因はこれです」と断定されても、他の可能性を検討した形跡がない。これで間違いないでしょ、、と思っても実際には間違っていたこともしばしばありました。

3. 論理が通らない回答が出る

「AだからB、よってCが原因」という推論に飛躍があり、お客様にそのまま送れる品質ではありませんでした。

工夫：社内の経験とマルチエージェントの融合

ヒントは社内のCSメンバーとのやりとりにあった

実は論理が通らない問題は、AIに限らず私にも言えたことでした。

自分がテクニカルサポートを始めた頃、調査して「これが原因です」と結論づけても、社内のCSメンバーから「ここはそうとは言い切れないのでは？」とフィードバックをもらうことがよくあり、たしかに、、となっておりました。

しかし、やりとりを通じて仮説を検証していくと、事象への解像度が上がっていく感覚がありました。

「仮説→調査→論理チェック→再調査」のサイクルが、調査を進めていく上で重要なのでは？？とうっすら感じ始めました。

参考にした記事

そんな中、社内でたまたま以下の記事を教えていただきました。

デバッグは死んだ。デバッグ万歳！Agent Teamによるインシデント自動調査

こちらの記事では、Claude CodeのAgent Teamsを使い、複数のAIエージェントに役割を分担させてデバッグを行う手法が紹介されていました。これをCREのテクニカルサポートに応用できると考え、調査チームを組んでみることにしました。

4つの役割で調査チームを構成する

Claude Codeでは .claude/agents/ 配下にMarkdownファイルでエージェントを定義します。各エージェントに役割・使えるツール・出力フォーマットを指示し、/cre というスラッシュコマンドでチーム全体を起動する仕組みです。

① 調査リーダー（investigation-lead）問い合わせ内容から仮説を立て、調査を割り振り、結果をまとめる
② 批判的レビュアー（critical-reviewer） 仮説や調査結果におかしな点がないかチェックする
③ コード調査担当（code-researcher）コードパスを追跡し、行番号で報告させる
④ ログ調査担当（log-analyst）Sentry・Athenaでログを分析させる
↓
最終レポート＋返信メール要点

仮説を立てる→調査する→批判的レビュアーがフィードバックする、という基本構造は参考記事のアーキテクチャをそのまま取り入れています。参考にさせていただいた記事にもありました通り、批判的レビュアー（critical-reviewer）の存在は大きく、レビュアーは以下の4つの観点でチェックします。

仮説の網羅性: 見落としている仮説はないか。仮説がコードに偏っていないか
調査の十分性: 棄却・採用の根拠が揃っているか。関連リポジトリを見落としていないか
論理の妥当性: 推論に飛躍がないか。相関と因果を混同していないか
対応策の評価: 根本原因に対処しているか。お客様側で実行可能か

このレビューで不足が指摘されれば、調査担当に差し戻して再調査します。根拠が揃うまでこのサイクルを回す設計です。

CRE業務に合わせて工夫した点は以下の通りです。

複数リポジトリの横断調査: Re:lationはメインのRailsアプリだけでなく、インフラ側や、社内メールパーサーなど複数のリポジトリで構成されています。コード調査エージェントにはRe:lation関連のリポジトリをすべて調査対象として指定しました。1つのリポジトリだけ見て原因を見誤るリスクを減らすためです。
調査結果は必ずコードベースで根拠を示す: お客様に返信する以上、情報に誤りがないかを念のためチェックします。その際、コードベース提示してもらうことで、自身がコードを追えるようにし、調査結果に誤りがないことを確認するためです。
返信メール要点の出力: Re:lationにはAIAgentによるメール文面生成機能があります。調査レポートの末尾に「お客様への返信に書くべき内容」を箇条書きで出力させ、それをAIAgentに入力することで、調査から回答作成までを一気通貫とすることが狙いです。

導入してみて

調査チームを運用して数週間、調査結果をそのまま回答に使えるケースが明らかに増えました。レビュアーのチェックを通過した結果はコードベースでの根拠が明示されているので、自分が理解する負担も減りました。

とはいえ、最終的にお客様への返信メールを作成するのは自分です。誤った情報を回答するわけにはいかないので、調査結果の内容は自分で理解し、論理に飛躍がないか確認する必要があります。調査の「実行」は任せられても、「判断」まで丸投げはできないのが現時点での実感です。

そして、予想外だったことは効率が上がったことではなく、自力では解けなかったであろう問い合わせを解決に導けたことでした。

事例：ある機能が特定の条件下で動作しなくなる

あるお客様から、特定の操作でとある機能の動作が不安定という問い合わせがありました。複数ユーザーで発生し、再現性はあるがブラウザ再起動で一時的に直るといった状況で、社内での再現に苦戦していました。

チームで話し合ったところ、ひとまず細かくログが出力されるように変更し、sentryにログを蓄積させある程度貯まったら調査してみる方向としました。ログがある程度貯まったあと、 /cre コマンドでチームに投げると、以下のように調査が進みました。ログを元に調査させた結果、これらを組み合わせて導かれた原因は、複数タブ間の状態同期によるレースコンディションが悪さをしているという結論でした。

コードは読めても、Sentryのイベントを時系列で並べて「同一秒に複数発火している」ことから利用状況を推論するといった判断をClaudeCodeは数分で行ってくれましたが、人力で私1人で行っていたらこれはかなり時間を消費していただろうと感じています。