はじめに
こんにちは、ZOZOTOWN開発本部Webバックエンドブロックのひでです。普段はZOZOTOWNのバックエンド領域を担当しています。
Webバックエンドブロックでは2026年1月より、カスタマーサポートチーム（以下CSチーム）から技術調査として開発側にエスカレーションされる問い合わせの効率化に取り組んでいます。エスカレーション後の調査では、データ・ログ・過去の会話・コードベースなど複数のツールを横断して情報を集める必要があります。そのため、1件あたりの対応に多くの時間がかかるという課題がありました。本記事ではこの課題に対し、AIを活用して開発側での一次回答までを自動化し、調査のリードタイムを平均70％（※アンケートベース）削減できた取り組みをご紹介します。
（※本記事における「CS問い合わせ」は、CSチームで解決に至らず、技術調査のためにエンジニアへエスカレーションされたものを指します。CS側でクローズする問い合わせは本記事の対象外です）
目次
背景・課題
CS問い合わせ対応の背景
CS問い合わせは次のようなフローで対応しています。
- ユーザーが問い合わせを送信
- CSチームが受け付けて一次対応
- CS側で解決できず技術調査が必要と判断されたもののみ、過去の類似問い合わせをもとに関連するシステム担当チームへエスカレーション
- Webバックエンド内のCS問い合わせ回答メンバーが調査・回答
本記事で取り上げる自動化のスコープは、ステップ4のWebバックエンド内での調査です。このステップ4の調査において、徐々に次のような課題が見えてきました。
抱えていた課題
1. 確認すべき情報源が多い
会員データや注文データといった業務データ、アプリケーションログ、過去の問い合わせ会話、関連コードなど、複数の情報源を横断して確認する必要があります。問い合わせの内容によって1件あたり1〜2時間、内容によっては2時間以上かかることも珍しくありませんでした。
2. 情報源ごとにツールが異なり、メンバー間の習熟度に差がある
それぞれの情報源は別々のツールで扱う必要があり、ツールの使い方や検索の勘所にもメンバーごとに差が出ます。新しくジョインしたメンバーや初めて触れる領域を担当する場合は独力での調査が難しく、専任のサポート担当が伴走する体制を取っていました。結果としてサポート担当に負荷が集中しがちで、調査・回答までのリードタイムが長くなる要因にもなっていました。
3. リプレイス過渡期で全体像を把握しづらい
Webバックエンドの調査範囲は、下図の紫色で示したとおりリプレイス前環境とリプレイス後環境の両方にまたがります。同じ事象でもまず新旧どちらの環境で発生しているのかを切り分け、そのうえで該当する側の構成・ログ・コードを掘り下げる、という二段構えの調査が必要でした。
さらに画面によっては、新旧環境の構成が混在しているケースもあり、片方だけを見ても原因を特定できないことがあります。この場合は新旧両方の構成・ログを並行して確認する必要があり、調査の複雑さがさらに増します。
加えてリプレイスは日々進行しており、リプレイス全体像の把握自体が難しく切り分けに余計なコストがかかっていました。
解決の取り組み
システム全体像
これらの課題に対し、CS問い合わせの一次回答までをAIで自動化する仕組みを構築しました。SlackとGitHubを起点とした以下の構成です。
各コンポーネントの役割と採用理由は次のとおりです。
| コンポーネント | 役割 | 採用理由 |
|---|---|---|
| Devin | Slackに投稿されたCS問い合わせを拾い、内容をGitHub Issueとして起票する | Slack上での会話体験が良く、CSチームの普段のやりとりをそのまま自動化の入り口にできる |
| Claude Code Actions | GitHub Issueをトリガに起動し、調査用Agent Skillsを実行する調査エンジン | Agent Skills機能で複数ステップの調査ロジックを定式化できる（検討時点ではDevinにAgent Skills機能がなく、現在は追加されている） |
| Splunk MCP / Slack MCP | ログ・過去会話を横断的に検索するインタフェース | 既存運用しているSaaSにそのままアクセスできる |
役割としては、Slack ⇄ GitHubのインタフェース層をDevinに、調査ロジックの実行エンジンをClaude Code Actionsに分担しています。
マルチリポジトリ対応のWorkflow設定
Claudeが複数リポジトリを横断して調査できるよう、Workflow YAMLを工夫しています。関連リポジトリを順にactions/checkoutでチェックアウトしてからClaudeを起動する構成です。
# claude code actionsの設定のymlファイル jobs: inquiry-investigation: runs-on: ubuntu-latest steps: - name: Checkout skill repo uses: actions/checkout@v4 - name: Checkout オンプレミスのリポジトリ uses: actions/checkout@v4 with: repository: org/onpre-repo path: repos/onpre-repo - name: Checkout FEのリポジトリ uses: actions/checkout@v4 with: repository: org/fe-repo path: repos/fe-repo - name: Checkout Akamaiのリポジトリ uses: actions/checkout@v4 with: repository: org/akamai-repo path: repos/akamai-repo - name: Checkout BFFのリポジトリ uses: actions/checkout@v4 with: repository: org/bff-repo path: repos/bff-repo - name: Run Claude Code Action uses: anthropics/claude-code-action@v1 with: mcp-config: .mcp/config.json
これによりClaudeが「複数リポジトリにまたがるコードベース」を1つの調査文脈として扱えるようになりました。リプレイス前のオンプレミスからAkamaiのルーティング設定・FE・BFFまでを一気通貫で参照できる構成です。
調査スキルの設計
調査手順はClaude CodeのSkill機能として実装しました。
これまで属人化しがちだった「CS問い合わせ調査の進め方」をSkillとしてリポジトリ管理することで、人間が読めるドキュメントでありながらそのまま動くマニュアルとして再利用できる形になっています。
調査スキルは、入り口となる親スキルinquiryと、判断ロジックを切り出したサブスキル群から構成されます。
| スキル名 | 役割 |
|---|---|
inquiry |
親スキル。問い合わせ内容の取得から最終レポート出力までを統括 |
inquiry/webbe-judge |
Webバックエンド担当か他チーム担当かを判定するサブスキル |
inquiry/scope-finder |
影響画面・調査対象リポジトリを特定するサブスキル |
code-investigator（Agent） |
指定されたリポジトリのコードベースを掘り下げるエージェント |
Skillをサブスキルに分割しているのは、調査ステップごとに責務を切り分けることで、メンテナンス時に該当箇所だけを更新できるようにするためです。
ここからは、親スキルinquiryが実行するStep 1〜7の中身を詳しく見ていきます。全体像は次のとおりです。
| Step | 内容 | 関連サブスキル/エージェント |
|---|---|---|
| Step 1 | 問い合わせ内容の取得・抽出 | - |
| Step 2 | Webバックエンド担当かどうかの判定 | webbe-judgeサブスキル |
| Step 3 | 影響画面・調査対象リポジトリの特定 | scope-finderサブスキル |
| Step 4 | Slackで過去類似問い合わせを検索 | Slack MCP |
| Step 5 | Splunkでログを段階的に検索 | Splunk MCP |
| Step 6 | コードベースを掘り下げる | code-investigatorエージェント |
| Step 7 | 統合レポートの作成・スキル改善メモの出力 | - |
Step 1: 問い合わせ内容の取得
渡されたSlackリンクからチャンネルIDとタイムスタンプを抽出し、Slack MCP経由でメッセージ本文・スレッドの内容を取得します。そこから以下の情報を抽出します。
- 問い合わせの概要（ユーザーが何に困っているか）
- 会員ID（記載されている場合）
- 発生日時（記載されている場合）
- エラーメッセージ・デバイス・画面情報（記載されている場合）
Step 2: Webバックエンド担当判定（webbe-judge サブスキル）
本格的な調査を始める前段として、Webバックエンド担当か他チーム担当かを切り分けるステップです。誤って自チームで長時間調査してしまうとリードタイムが大きく伸びるため、最初にここで判定します。
判定は以下のサブステップで進めます。
- Step 2-1：蓄積事例を参照 —
judgment-knowledge.mdから過去の判定知見・誤判定の教訓を参照 - Step 2-2：Slackで過去事例を検索 — 問い合わせキーワードでSlackを横断検索し、Webバックエンドでの過去の対応事例を確認
- Step 2-3：担当判定 — 上記の参照結果から「Webバックエンド担当 / 他チーム担当 / 要確認」を判定
- Step 2-4：判定に応じた処理 — Webバックエンド担当ならStep 3へ、他チーム担当なら
team-routing.mdを参照してルーティング先を提示し終了
なお、図中のjudgment-knowledge.md / team-routing.mdは、使うほど内容が増えていく蓄積知識ファイルです。更新の流れはStep 7で説明します。
Step 3: 影響画面・リポジトリの特定（scope-finder サブスキル）
どの画面で問題が起きているかとどのリポジトリを調査すべきかの2つを独立して特定するステップです。
- Step 3-1：影響画面（URL）の特定 —
screen-url-map.mdを参照、Splunkのユーザーログから画面を推定 - Step 3-2：調査リポジトリの特定 — URLをAkamaiルーティング設定と照合し、新環境/旧環境を判定して対象リポジトリを決定（両方にまたがる場合は複数指定）
ここで特定したリポジトリ情報が、後続のStep 6の調査対象です。screen-url-map.mdも、未登録の画面を見つけるたびに更新されていく蓄積ファイルです。
Step 4: Slack過去類似問い合わせの調査
Step 1〜3で抽出した情報をもとに、Slackから過去の類似問い合わせを検索します。
検索は最低3パターンのキーワード（機能名 + 症状 / エラーメッセージ / 機能名のみ）で実行します。ヒットしたスレッドのうち類似度が高いものは、スレッド内の全メッセージを取得します。
Step 5: Splunkログ調査
会員ID・発生日時を起点に、Splunkで段階的にログを引きます。最初から広い範囲を一気に引くと結果が膨大になりすぎるため、時間範囲を段階的に広げる構成にしています。
- Step 5-1：UID/IPの特定 — 会員IDから内部UID・IPを特定（±3h→±6h→±9h→±12hと範囲を拡大）
- Step 5-2：アプリケーションログの3段階検索 — Stage 1（±30分）/ Stage 2（±6時間）/ Stage 3（±1日）で直接エラー→前兆→全体傾向を確認
- Step 5-3：Akamaiログ調査 — Step 5-2で特定できなかった場合のみ、5xx・WAFブロックを確認
- Step 5-4：新環境のログ調査 — 新環境のAPI層が対象に含まれる場合のみ実施
Step 6: コードベース調査
Step 3で特定したリポジトリのコードをcode-investigatorエージェントが掘り下げます。
Workflow YAMLで関連リポジトリは事前にチェックアウト済みのため、エージェントは複数リポジトリを横断して該当機能のコードを読み解けます。問い合わせ内容と症状から「どの実装が関係していそうか」当たりをつけ、関連コードを抽出します。
Step 7: 統合レポートの作成とスキル改善メモ
Step 1〜6の調査結果を統合し、Markdown形式の統合レポートとしてGitHub Issueにコメント投稿します。レポートに含まれる内容は以下のとおりです。
- 問い合わせ概要 / 担当判定 / 影響画面・リポジトリ
- Slack過去調査の結果 / Splunkログ調査の結果 / コードベース調査の結果
- 総合分析と仮回答案（CSチームへ伝えるための文面）
- 推奨アクション・他チームへのハンドリング先（該当する場合）
- スキル改善メモ ← Skill自体を継続的に育てるための仕組み
最後の「スキル改善メモ」が、本仕組みを継続的に育てていくための仕掛けです。調査の中で次のようなトリガー条件に該当した場合、Skillは「どのファイルに何を追記すべきか」をレポートに出力します。
| トリガー条件 | 更新対象ファイル |
|---|---|
screen-url-map.md 未登録の画面・URLに遭遇した |
screen-url-map.md |
team-routing.md 未登録のチーム・サービスが判明した |
team-routing.md |
| Webバックエンド担当判定で「要確認」になった | judgment-knowledge.md |
| Akamaiルーティング判定で「要確認」になった | akamai-routing-rules.md |
これらのファイルは、Step 2・Step 3の図中、黄色で示していた蓄積知識ファイルそのものです。使われれば使われるほど内容が増え、次回以降の判定精度が上がっていく設計になっています。
現状、蓄積知識ファイルへの反映はメンバーが手作業で行う運用です。スキル改善メモをもとに、本当に反映が必要なものを担当者がコミットします。
効果
仕組みを導入した結果、CS問い合わせ対応に次のような効果が出ています。
調査リードタイムの大幅短縮
これまで人手では1件あたり1〜2時間（複雑なものは2時間以上）かかっていた調査が、Claude Code Actionsの起動から一次回答の出力までおおよそ10分程度で完了するようになりました。担当メンバーは「ゼロから調査を始める」のではなく「AIが出した一次回答をレビューする」立場に変わり、回答までのリードタイムを平均70％（※アンケートベース）削減できました。
サポート担当への負荷集中の解消
初回対応者でも独力で調査できる範囲が広がり、専任サポート担当への質問集中も解消されました。新しくジョインしたメンバーでも、Skillが定義している調査手順をClaudeが代わりに実行するため、まずは一次回答が出てくる状態からレビューを始められます。
調査品質の均質化
メンバーごとの知識差やツール習熟度の差で出ていた調査品質のばらつきが、Skillに沿った定型フローによって均質化されました。確認漏れが起こりやすかった「過去の類似問い合わせ」や「Akamai層のログ」といったステップも、Skill側で必ず実行されるため抜けが起きにくくなっています。
見えてきた課題
一方で、運用していく中でいくつか限界も見えてきました。
蓄積知識ファイルの更新が手動依存
スキル改善メモはSkillが自動で出力するものの、その内容を確認して蓄積知識ファイルへ反映する作業は担当者の手作業に依存しています。改善メモは次々と出てくる一方で反映作業が追いつかず、知識ファイルの育成スピードが運用者のリソースに依存してしまっています。
実DBデータを参照する調査ができない
現状の調査対象はログ・コード・Slackまでで、データそのものを直接クエリする手段は持っていません。そのため、在庫不整合やデータ起因の表示崩れなど「データの中身を見ないと特定できないケース」はSkillの守備範囲外となり、人手調査に戻る必要があります。
一次回答の精度ばらつきとハルシネーション
AIが出す一次回答は、典型的なケースでは十分実用的ですが、複雑なケースでは結論を誤ったり、もっともらしい根拠を伴って間違った回答（ハルシネーション）を出したりすることもあります。最終回答前のメンバーレビューを必須にしているため致命的な事故には至っていませんが、自信ありげな誤回答に引きずられるリスクは残っています。
得られた知見
今回の取り組みを通して、生成AIをチームの調査オペレーションに組み込むうえで、いくつか再利用できそうな知見が得られました。
LLMは「オペレーションエンジン」として使える
生成AIをチャット用途で使うイメージは広く浸透しています。今回得た最大の知見は、LLMは「ログ確認」「履歴検索」「コード調査」といった複数の調査ステップを横断的に実行する「オペレーションの実行エンジン」として使えるという点です。
人間が個別ツールを行き来して調査する代わりに、Skillとして定義した手順を上から下まで自律的に実行する役割をLLMが担うことで、これまでの「対話するAI」とは別軸の使い方が見えてきました。
MCPでナレッジを集約せずに横断利用できる
調査に必要な情報源（Splunk・Slack・コード）はそれぞれ専用のツール・SaaSに分散しており、これまで「ナレッジを別の場所に集約しないと使いづらい」のが定番でした。
MCP経由で既存のツールを直接叩けるようにしたことで、ナレッジを別のドキュメント基盤やデータレイクへ集約せずとも、AIから横断的に扱えるようになりました。データの最新性が保たれる点も大きなメリットです。
さらに、各ツールから得た調査結果はそのままClaudeのコンテキストに取り込まれるため、複数ツールの結果を突き合わせたうえで思考・推論できる点も重要なメリットでした。例えば「Splunkで検出したエラーパターン」と「Slackで見つかった過去対応の経緯」を関連付けて原因の仮説を立てる、といったツール横断の推論が、人手の調査と比べて格段にやりやすくなりました。
Skillが「動くマニュアル」になる
これまでチームの調査手順は、メンバーの頭の中にあるか、社内ドキュメントに散らばったメモとして存在しがちで、整備のモチベーションが上がりにくいものでした。
Skillとして実装することで、人間が読むためのマニュアルであり、かつそのままClaudeが実行する手順書でもある形にできました。一度書けば人間とAIの両方にとって有効な資産になるため、整備に向き合う動機が生まれます。
マルチリポジトリ横断でリプレイス過渡期でも機能する
Workflow YAMLで複数リポジトリを順にチェックアウトする構成により、ClaudeはあたかもシングルリポジトリのようにフロントエンドからBFF・APIまでを参照できます。
リプレイス過渡期のような「新旧コードが別リポジトリに分散している」状況でも、AIが両方のコードを同じ文脈で扱えるため、環境判断の難しさという課題に直接効きました。新しいリポジトリが増えたときも、Workflowにチェックアウトステップを追加するだけで対応できる点も運用上の利点です。
今後の展望
「見えてきた課題」で挙げた限界に対し、次のような取り組みを進めていきたいと考えています。
蓄積知識ファイルへの反映フローの仕組み化
スキル改善メモから蓄積知識ファイルへの反映を、人手を介さず自動で行う仕組みを整備していきます。これにより知識ファイルの育成スピードを担当者の手番から切り離し、定常的に育てられる状態を目指します。
BigQuery MCPなどによる実DBデータへの調査範囲の拡張
BigQuery MCPなどを接続し、ログ・コード・Slackに加えて実DBデータも調査対象として含める拡張を検討しています。この拡張により、データ起因の問い合わせも自動調査の範囲でカバーできるようになります。
ハルシネーションを抑える評価ループの整備
ハルシネーションの課題に対しては、Skillの一次回答を継続的に評価し、Skillへフィードバックするループの整備を進めていきます。過去の問い合わせをテストケースとして、Skill変更前後の回答品質をA/B比較する仕組みは既に整備しているため、これをSkill更新時の品質ゲートとして組み込みます。評価で検出された誤答パターンをSkillの手順や蓄積知識ファイルへ反映していくことで、「使うほど誤答が減る」状態を目指します。
他チームへの展開と各チーム固有Skillの整備
現状この仕組みはWebバックエンドの調査文脈に最適化されていますが、調査手順をSkillと蓄積知識ファイルに切り出す構造はチーム非依存です。今後は他チームへの展開と、各チーム固有のSkill整備を進めていきます。
まとめ
本記事では、Devin・Claude Code Actions・各種MCPを組み合わせたCS問い合わせ調査の自動化を紹介しました。Skillに調査手順を集約し、SlackからGitHub Issue経由でAIに自律的に調査させる仕組みです。これによって1件あたり1〜2時間かかっていた一次調査を10分程度まで短縮し、属人化していた調査ノウハウを「動くマニュアル」として再利用可能な形にできました。同じようにCS問い合わせや運用業務の属人化に課題を抱えるチームを持つ方にとって、何かしらの参考になれば嬉しいです。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
