問い合わせ対応をAIエージェントで効率化 ── DB・ログに直接アクセスさせるClaude Code設計と運用

はじめに

こんにちは、下江と申します。広告代理店向けの業務支援サービス「ATOM」のテクニカルサポートを担当しています。

ATOMでは、問い合わせの一次対応をサポートデスクが、システム内部の調査をテクニカルサポートエンジニアが担っています。いずれも製品仕様や過去事例の知識が求められ、長年経験を積んだメンバーが対応してきました。この属人性が問い合わせ対応のボトルネックになっており、今後の人員の入れ替わりも考慮すると、ノウハウを仕組みで補う必要がありました。

本記事では、社内チーム賞も受賞した、AIを活用した問い合わせ対応の効率化と属人性の排除に向けた取り組みを紹介します。

フェーズ1: Notion AIで初動調査の効率化
フェーズ2: Claude Codeで技術調査を半自動化

フェーズ1: Notion AIで初動調査の効率化

課題

サポートデスクチームでは、効率化のためにすでにNotion AIで過去事例を検索するフローを取り入れていましたが、以下の問題がありました。

人によってAIへの指示品質がばらつき、関係のない資料まで参照してしまう
検索結果の取捨選択に内容の精読が必要で、調査が長引くことがある
過去事例が不具合修正で陳腐化していても鮮度・真偽の判定が難しく、時間をかけて調査しても結局エンジニアへの問い合わせにつながってしまう

対策

Notionカスタムエージェントを活用し、問い合わせ調査用のプロンプトを標準化しました。ただし、カスタムエージェントは2026年4月時点では無料のため利用していますが有料化が予定されています。費用対効果を見てNotion AIのAIスキル機能への切り替えも検討しています。

運用イメージ

Notionカスタムエージェントに問い合わせ調査用の手順を登録し、

Slack通知をトリガーに対象スレッドへ自動で一次回答を投稿する
Slackの回答を確認して、参考にしながら一次切り分けを行う

という流れで対応できるようにしました。手順・指示文では以下のルールを組み込むよう工夫しました。

回答ルールのチェックリスト化（わからない場合はわからないと返す、推測は明示する等）
情報鮮度チェック（リリース状況まで確認し、解消済みと返す）
参照先を必要最低限の情報に限定（カスタムエージェントのみ）

効果と限界

難しい問い合わせの初動調査コストが1件あたり5分程度削減され、回答品質の標準化や新メンバーのオンボーディング支援にも効果がありました。

一方で、実際のDBやログを見ないと原因がわからないケースや、AWSのジョブ状態・ユーザーの操作履歴を追う必要があるケースには対応できません。こうした技術調査はこれまでエンジニアが手動で行っており、調査依頼から回答までにリードタイムが発生していました。

フェーズ2: Claude Codeで技術調査を半自動化

Claude Codeのカスタムスキルとは

Claude CodeにはカスタムスキルというMarkdownファイルで「調査手順」を定義できる仕組みがあります。スキルは /investigate のようにスラッシュコマンドで呼び出すことができ、定義した手順に沿ってClaude Codeが自律的に調査を進めます。さらに、Claude CodeはMCP（Model Context Protocol）サーバーに接続でき、DB参照やログ取得といった外部システムへのアクセスをツールとして提供できます。

この仕組みを活用し、問い合わせの技術調査を半自動化する investigate スキルを構築しました。最初は単一エージェント+DB参照だけの構成でしたが、ログ調査用MCPツールの追加等、テクニカルサポート対応をしながら一つずつ拡張していき、コンテキスト肥大化による回答精度の低下を経て、現在のマルチエージェント構成に発展しました。

全体アーキテクチャ

問い合わせ内容をカテゴリ分類し、専門のサブエージェントがDB・ログを並列に調査して原因を特定する構成です。

設計のポイント

1. Anthropicの推奨設計パターンの採用

AnthropicのBuilding Effective Agentsで推奨されている3つのパターンを採用しました。

1.1 Orchestrator-Workers

親エージェントはタスクの分解と結果の統合に徹し、技術的な作業はすべてサブエージェントに委譲するようにしました。大量の検索結果やログによるコンテキスト圧迫を防ぎ、精度の維持が狙えます。 RDBエージェントやドメインエキスパートは調査全体を通じて常駐させ、その他のエージェントは必要時にのみ起動する構成としています。

1.2 Routing

当初はエージェントに自律的な判断を委ねていましたが、「データを確認する前にコード分析だけで『仕様です』と結論を出す」「深掘りが必要な場面で推測で調査を打ち切る」等、意図しない動きが頻発しました。そこで、普段の問い合わせ対応で実際に踏んでいる調査ステップをカテゴリ別に明文化し、エージェントの判断余地を意図的に狭める設計に切り替えました。

問い合わせ内容をヒアリングした後、影響範囲と症状からカテゴリに分類します。以下はその一例です。

	症状	調査の流れ
A	外部サービスとの数値不一致	DB上の値と元データの突合
B	データが表示されない	バッチジョブの実行状態・リトライ状況
C	ユーザー操作起因	エラーメッセージからコードを追跡
..	etc	etc

カテゴリごとに調査手順書（子スキル）が用意されており、起動するサブエージェントの組み合わせが決まります。調査手順と使用ツールが固定されるため、エージェントの探索範囲が制限されます。また、各ステップに「実データで検証してから次に進む」という指示を組み込み、コード分析だけで結論を出すことを防いでいます。

なお、カテゴリ判定後にはユーザーに方針を確認するチェックポイントを設けています。調査中に「認証エラーと思ったが実際はデータの問題だった」等、カテゴリの再判定が必要になった場合も、ユーザーに切り替えを提案してから再スタートする設計としました。

1.3 Parallelization（Sectioning）

カテゴリ判定後、過去事例検索・DB参照・ドメイン知識の照会など独立したサブタスクを並列に実行し、調査時間を短縮しました。

2. MCPサーバーによる安全なデータアクセス

MCPサーバーは、.mcp.jsonに起動コマンドを定義しておけば、Claude Code起動時に自動で立ち上がり接続されるため、別途サーバーを構築・運用する必要はありません。このMCPサーバーを自前で実装することで、以下を実現しました。

読み取り専用アクセス: DBへの書き込みは不可能な設計
事前定義クエリ: SQLをテンプレート化しており、エージェントが任意のカラムをSELECTで指定できないため、センシティブ情報にはそもそもアクセスできない
権限制御: .claude/settings.jsonのpermissions.askにMCPツールを指定し、ユーザーが毎回許可しない限り実行されない設定にすることで、意図しないデータアクセスを防止
QPS制限: エージェントの総当たり的なAPI呼び出しによる本番環境への負荷を抑制

なお、調査結果の最終判断と回答の作成は人が行います。 AIが自律的に行うのは調査の実行と調査レポートの作成までです。

3. ドキュメント設計の工夫

エージェントにはSKILL.mdに加えて、各ドキュメントに関連ドキュメントのパスを明記し、必要に応じてたどれる構造にしました。

また、変化しやすい仕様はドキュメントに記載せず、Git Submodule化した設定ファイルへの参照を渡すようにしました。たとえばバッチのスケジュール定義は頻繁に変更されるため、ドキュメントに転記せずTerraformの定義ファイルを直接参照させています。これにより陳腐化を防ぎ、常に最新の仕様をエージェントが参照できます。

調査結果の蓄積

調査結果はナレッジベースに蓄積し、将来の調査精度を向上させる仕組みを設けました。

調査完了後、調査経緯・原因・対応をケースファイルとして保存する
調査中に判明した「ドキュメント不足」「MCPツールの機能不足」等をナレッジギャップとして記録する
定期的にギャップを棚卸しし、スキルの手順追加やMCPツールの拡張に反映する
蓄積されたケースファイルを過去事例エージェントが次の調査で参照する

現状は、調査担当者がケースとギャップを記録し、スキルを一貫して管理する担当者が調査手順やMCPツールの改善に反映する運用です。将来的にはこのギャップ整備自体もスキル化し、属人性を減らしていきたいと考えています。

運用から見えた課題

investigateスキルはカテゴリ別の調査手順で安定性を大きく改善しましたが、完全に手放しで調査させるにはまだ道のりがあります。運用の中で見えてきた代表的な課題を紹介します。

必要な情報が不足している時の「総当たり」問題

MCPサーバーが利用者IDを引数にデータを取得する箇所で、利用者を伝えずエージェントに調査を依頼した際、全利用者に対してMCPツールを総当たりで呼び出そうとするケースがありました。同様に、特定広告媒体の調査であるにもかかわらず、全広告媒体をループしてログを取得しに行く動きもありました。

このように、前提条件や対象の制約が不足している場合、エージェントは探索範囲を広げる方向に振る舞い、結果として過剰なツール呼び出しが発生します。

対策として、利用者IDなどの調査対象が確定するまで後続の調査処理に進まないルールの明文化、MCPツールの入力バリデーション強化等により不完全な条件での実行を抑制するようにしました。実際に抑止されたケースもあり、完全ではないものの一定の効果が得られました。

コード分析だけで結論を出してしまう問題

とある数値が出ないという調査で、本来は実データを確認しながら一つ一つ可能性を潰していく必要があるにもかかわらず、エージェントがコードの調査と事象の説明だけで結論を決め打ちしてしまうケースがありました。エージェントが実データの検証を「不要」と判断し、検証用のサブエージェントをそもそも起動しなかったことが原因です。

この「最初のもっともらしい説明に飛びつく」傾向はAIエージェントで一般に知られており、設計時に指示として組み込んでいたものの完全には防げませんでした。対策として、実データ確認を必須とするルールをスキルに明記し、検証用のチェックリストを整備しました。あわせて、実データ確認に必要だったツールが不足していたため、MCPツールの拡張も行いました。これにより同様のケースは解消しています。

ただし、スキルの記述が複雑になるほどエージェントが指示を見落とすリスクも高まるため、制約のかけ方は継続して調整が必要です。

まとめ

AIエージェントの導入を2段階で進めたことで、問い合わせ対応の各フェーズを効率化できました。

フェーズ1（Notion AI）: 過去事例ベースの初動調査を自動化・標準化
フェーズ2（investigate スキル）: エンジニアが手動で行っていた技術調査をサブエージェント群で半自動化

特にinvestigateスキルでは、「親エージェントをオーケストレーターに徹させる」「カテゴリ分類で調査方針を一意に決める」「MCPサーバーで安全にデータアクセスする」という設計により、複雑な技術調査でも安定した品質で実行できるようになりました。

今後は以下の方向で改善を検討しています。

安定運用: 現在はまだ改善しながら運用しているフェーズのため、スキルやMCPツールの品質を安定させていく
DWHへのMCP接続: 現在は分析用SQLを手動で実行しているが、ClickHouse MCPサーバーへ接続しエージェントが直接データ検証できるようにしたい
エージェントの自己評価: ツール呼び出しの成功率やスコープ逸脱の頻度をメトリクスとして計測し、スキルの改善サイクルに組み込む
自動起動の仕組み: 現在は手動で /investigate を実行しているが、問い合わせの受信やアラートの発生をトリガーに自動で調査を開始する仕組みを検討したい。Claude Codeではスケジュール実行や外部イベントトリガーが提供されており、活用できる見込みがある

以上、お読みいただきありがとうございました。以前の記事「広告代理店向けSaaS『ATOM』のサポート力を3つの事例で紹介」では、テクニカルサポートの業務全体について紹介しています。あわせてご覧いただけると幸いです。