サポート問い合わせ調査を AI エージェントに任せる仕組みを作ってみた

はじめに

システムを担当していると、想定外の使われ方をして、サポート担当が困って問い合わせてくることがあります。

その都度、設定内容を調査し、仮説を立てて検証して回答する。うーん、大変。

最近は AI の進歩のおかげで仮説の検証はずいぶん楽になりましたが、こうした調査は経験と勘がものを言う、属人化しやすい領域です。そこで、自分が楽になるために、AI を使って現状を改善する足がかりを作ってみました。まずは以下の課題を解決したいと考えています。

• 同じような問い合わせが、何度も繰り返し発生する
• 調査の過程や結果は文書に残すようにしているものの、必要なときに探し出すのが地味に手間
• サポート担当は開発側に気を使うので、ちょっと気になったことを気軽に投げられる場所がほしい

使ったのは Claude Code です。色々相談しながら作ってもらいました。

「あるもの」で、まず始めた

この手の仕組みを作ろうとすると、つい「まずは AI に読ませるための綺麗なドキュメントを整備しよう」と考えがちです。でも、それをやり始めると準備だけで挫折します。

今回はその逆で、すでに社内にある資産をそのまま読ませるところから始めました。

• ソースコード（プロダクトのリポジトリ）
• 社内マニュアル
• 課題管理ツールに溜まった過去の問い合わせ

新しく何かを書き起こすのではなく、「今あるもの」を AI の調査対象として与えるだけ。精度や使い勝手の細かい調整は、走らせながら後から詰めればいい——という「まずはやってみる」スタンスで始めました。

実際、最初は粗削りでしたが、使いながら指示書を直していくうちに、十分実用的なところまで持っていけました。

全体の構成

仕組みはシンプルで、以下の3要素だけです。

support-kb/（GitHub リポジトリ）
├── .claude/
│   ├── commands/
│   │   ├── support.md          ← 問い合わせ調査の指示書（オーケストレータ）
│   │   └── support-maintain.md ← 月次メンテの指示書
│   └── agents/
│       ├── system-a-investigator.md  ← システム別の調査担当
│       ├── system-b-investigator.md
│       └── system-c-investigator.md
├── system-a/   ← システムごとのナレッジ
│   ├── INDEX.md
│   └── {担当者}/{トピック}.md
└── ...

• オーケストレータ：問い合わせを受け取り、全工程を統括する司令塔
• 調査サブエージェント：業務システムごとに専任の調査担当を用意
• ナレッジベース：調査結果を Markdown で蓄積する GitHub リポジトリ

問い合わせ内容を貼り付けるだけで、対象システムの判定 → 調査 → 回答案作成 → ナレッジ保存まで自動で走ります。

調査の流れ

オーケストレータは、問い合わせを受けると次の順で動きます。

1. 問い合わせ文から どの業務システムの話か を自動判定
2. ナレッジベースを最新化（git pull）
3. 該当システムの調査サブエージェントを起動し、4つの情報源を並列で調査
   • 過去に蓄積したナレッジ
   • 課題管理ツールの過去問い合わせ
   • ソースコード（読み取り専用でクローンしたものを検索）
   • 社内マニュアル
4. 結果を統合し、固定フォーマットで回答
5. 調査結果をナレッジベースに保存し、自動でコミット

ポイントは 「サポート担当向けの平易な説明」と「開発者にそのまま渡せる技術詳細」を分けて出力することです。サポート担当はそのまま現場に返信でき、エスカレが必要なときは技術詳細セクションを開発者に丸ごと渡せます。

ナレッジを「育てる」仕組み

調査して終わりではなく、結果が資産として積み上がるようにしています。

蓄積するファイルには冒頭にメタ情報を持たせ、目次（INDEX）は自動再生成。サブエージェントは調査時にまず目次を読むので、2回目以降の同じ問い合わせはほぼ即答できます。

---
title: 〇〇機能が動かないときの判定仕様
tags: [タグ1, タグ2]
last_verified: 2026-05-19
related_backlog: [チケット番号]
---

# 仕様
（平易な説明）

# 事例
## YYYY-MM-DD: 問い合わせ要約
症状: ...
原因: ...
回答内容: ...

機密情報（顧客名・個人情報など）は本文に残さず、課題管理ツールのリンクだけを残すルールにしています。

サポートも開発も「使う側」

この仕組みは、もともとサポート担当の問い合わせ調査を楽にするために作りました。ただ、私のような開発担当も、自分で調査をするときにこの仕組みを使うようにしています。

開発側も使うことには2つの意味があります。

• 仕様を熟知した立場で回すことで、回答の精度や指示書の改善点に気づきやすい
• 開発側が調査した深い知見も、そのままナレッジとして蓄積される

「サポートが使うツールを開発が整備する」という一方向ではなく、サポートも開発も同じ仕組みを使い、両者で精度を高め合うという関係を狙っています。

工夫したところ

マニュアル参照を安全に組み込む

社内マニュアルも参照させていますが、認証情報入りの URL はリポジトリには絶対に含めません。.gitignore で除外したローカル専用ファイルに分け、調査時だけ読み込む構成にしています。

月次メンテで「劣化」を防ぐ

ナレッジは放置すると古くなり、追記を重ねると矛盾も生まれます。そこで月次メンテ用のコマンドを別途用意し、

• 90日以上経過したナレッジの再調査判定（参照元コードが変わっていないか）
• 古すぎる事例のアーカイブ
• ファイル内の記述矛盾チェック（追記の積み重ねで生じた食い違いを検出）

を半自動で回せるようにしました。

AI に「鵜呑みにさせない」

これが個人的に一番効いた工夫です。問い合わせには「〇〇のはずなんですけど」という利用者の思い込みがよく含まれます。これをそのまま事実として扱うと、AI が思い込みに整合する答えを探してしまい、誤った回答にたどり着きます。

そこで指示書に、利用者の前提を「仮説」として扱うルールを明記しました。実際に使っているプロンプトの一部がこちらです。

## 重要：ユーザーの「〇〇のはず」表現は仮説として扱う

問い合わせ文に含まれる以下の表現は「事実」ではなく「ユーザーの仮説」として扱い、
コードで検証してから回答する：

- 「〇〇のはず」「〇〇の仕様だと思う」
- 「〇〇なので〇〇ができない」（因果関係の主張）
- 「〇〇に丸がついているから〇〇ができる」（前提と結論の主張）
- 「以前は〇〇だった」（過去経験ベースの主張）

**「ユーザーが言っていることに整合する答えを探す」のではなく、
「ユーザーの仮説をコードで検証する」スタンスで調査すること。**

これにより、以下の問題を防げる：
- 確証バイアスでユーザーの誤った前提に沿って答えてしまう
- 反証コードがあっても見落として、表面的に整合させてしまう
- 正解にたどり着くのが遅れ、複数往復で訂正することになる

このルールを入れる前は何度か「利用者の前提に引っ張られて誤回答 → 指摘されて訂正」を繰り返していたのですが、入れてからは最初から正解に近い回答を出せるようになりました。

運用してみて

定量的な効果測定はこれからで、効果を見ながら少しずつ調整していく段階です。それでも体感では、すでに手応えがあります。

• サポート担当が運用目線のナレッジをためてくれるようになり、開発担当者も現場での使われ方をイメージしやすくなった
• 過去事例まで自動で探してまとめてくれるので、調査の負担が軽くなった
• サポートチーム全体で知識を共有しやすくなった

そして何より、指摘・訂正をすると、その場の回答だけでなくナレッジと指示書の両方に反映されるので、同じ間違いを繰り返さなくなりました。人間が指摘 → AI が学習・反映 → 次回から改善、というループが回り始めています。

おわりに

「AI に調査を任せる」というと丸投げのように聞こえますが、実際に目指しているのは、開発者とサポート担当で「AI を育てていく」こと。そうやって、チームの一担当者として働いてもらうことを狙っています。

最初から完璧なドキュメントを用意する必要はありません。今あるソースコード・マニュアル・問い合わせ履歴を読ませて、まず動かしてみる。その後は根気強く育てていけばいいんです。

同じように「問い合わせ対応が属人化している」「過去の調査が残らない」と感じている方は、軽く試してみてもいいかもしれません。