はじめに
こんにちは。 ATOM事業部で開発とテクニカルサポートを担当している渡部です。
日々のテクニカルサポート業務を効率化するため、問い合わせ対応の調査支援、定型作業の自動化、ナレッジの蓄積などをカバーするClaude Code連携ツール集を開発・運用しています。
特に問い合わせ対応における情報収集は、以下の理由で時間がかかりがちです。
- 「ヘルプドキュメント」「DB情報」「媒体APIの仕様」など情報源を横断して調査
- 担当者は機能の把握はできても、システム内部の動作まではカバーしきれない
- 過去の対応事例はNotionに蓄積されているが類似事例の検索に手間がかかる
本記事では、これらの課題に対して作ったテクニカルサポートスキルの仕組みと、運用して分かったことを紹介します。
テクニカルサポートスキル
テクニカルサポート業務において、問い合わせ対応を効率化するための中核スキルです。 スキルを使用するためのリソースはGitHubリポジトリで管理しており、ヘルプドキュメント・過去の対応事例・システム仕様書をリポジトリ内に蓄積しています。
以下のリソースを優先度順に検索し、回答に必要な情報を収集します。
参照先リソース:
| 優先度 | リソース | 用途 |
|---|---|---|
| 1 | ヘルプドキュメント | 公式仕様・基本的なFAQ |
| 2 | 過去の対応事例 | 過去の調査結果・解決策 |
| 3 | システム仕様書 | DB構造・機能・テーブル対照表（詳細技術調査） |
ワークフロー:
1. 問い合わせ内容の把握 - 何が起きているか（エラーメッセージ、症状） - いつから発生しているか - 影響範囲（特定アカウント / 全体） 2. ヘルプドキュメントの検索 - キーワードでヘルプドキュメントを検索 - エラーメッセージ、機能名などで絞り込み 3. 過去事例の検索 - Githubに蓄積したナレッジから類似事例を検索 - 過去の原因・対応方法を参照 4. 回答の作成 - ヘルプに記載がある → 要約して回答 - 過去事例がある → 原因・対応方法を参考に回答 - 情報がない → 追加調査項目を整理 5. ナレッジとして保存 - 対応完了後、knowledge-saveスキルでナレッジ蓄積
なお、調査中のDB構造確認や対応完了後のナレッジ保存は、それぞれ別のスキルと連携して処理しています。
運用していて役に立ったこと
Claude連携による調査効率化
Before:
1. 問い合わせを受ける 2. ヘルプドキュメントを検索 3. 過去の対応事例をNotionで探す(NotionAI利用) 4. 該当機能の調査 5. 調査結果を元に、仕様/外部API/自社プロダクトの不具合を切り分け 6. ATOMの不具合の場合 - ソースコードを確認(自分で確認 or 開発者に依頼) - 確認結果をまとめる 7. 回答を作成
After:
1. 問い合わせを受ける 2. 問い合わせ内容をコピペ → スキルが自動で情報収集・回答作成 3. ATOMの不具合の場合 - ソースコードを確認(自分で確認 or 開発者に依頼) - 確認結果をまとめる 4. 回答を清書し、正式な回答を作成 5. 回答を元にナレッジに格納
特に「以前同じ問い合わせがあったはず...」という曖昧な記憶を頼りに探す時間が大幅に削減されました。 過去の対応事例を蓄積しているため、Claudeが自動で類似事例を見つけてくれます。
改善すべきポイント
ナレッジ不足
過去にNotionへ蓄積してきたナレッジを、まだGitHubリポジトリに移しきれていません。
セキュリティ上の理由からClaude CodeがNotionを直接参照できないため、手動でコピーする必要があり、移行が追いついていない状況です。
サブエージェントの活用
現状、すべての処理を分割せずにメインのモデル（Opus等）で実行していますが、 ヘルプドキュメントの検索や過去事例の参照といったタスクは高機能なモデルでなくても十分対応できます。
これらを軽量なサブエージェント（Haiku等）に分離すれば、コストを抑えるだけではなく、並列実行による調査速度向上も期待できます。
調査結果の提示方法
現状、スキルの出力はClaude Codeが調査結果をもとに回答を生成する形になっています。
しかしテクニカルサポートにおいては、AIが作成した回答をそのまま顧客に伝えるのではなく、 根拠となるドキュメントや過去事例を添えた調査結果として提示し、 最終的な回答は担当者が判断、作成すべきです。
実際の運用でも「LLMによって自動生成された回答」は使用しておりません。
「回答の生成」ではなく「調査の補助」にとどめる設計への見直しが必要だと考えています。
ナレッジ検索にRAG MCPを使用する
現状、ナレッジ検索はテキストをすべて検索して結果を出しています。
ナレッジがあまり蓄積していない今は問題ないですが、 ナレッジが蓄積するにつれてコンテキストを圧迫し、結果、レスポンスの低下や回答品質の低下につながります。
そのため、蓄積したナレッジを効率よく検索するためのRAGシステムを作成し、そのシステムをLLMが利用しやすいようにMCPを構築することでコンテキストの圧迫を防ごうと考えています。
まとめ
Claude Codeのスキル機能を活用してテクニカルサポートスキルを構築したことで、 問い合わせ対応における情報収集の手間が削減されました。
- 調査の効率化: ヘルプドキュメント・過去事例・システム仕様を自動で横断検索
- ナレッジの循環: 対応事例を蓄積し、次の調査で再利用できる仕組み
一方で、サブエージェントの活用や調査結果の提示方法など、改善すべき点も見えてきました。
Claude Code等のLLMのスキル機能は、調査という知的作業の効率化に大きな可能性があると感じています。 同じような課題を持つチームの参考になれば幸いです。
おまけ：実際のスキル定義
参考までに、実際に使用しているテクニカルサポートスキルの定義を掲載します(生々しいので少し編集してます笑)。
--- name: techsupport description: ユーザーからの問い合わせを調査・トラブルシュートします。ヘルプドキュメントと過去の対応事例を参照して回答を作成します。 --- # テクニカルサポートスキル ユーザーからの問い合わせに対して、ヘルプドキュメントと過去の対応事例を参照して回答を支援します。 ## 発動条件 - 「問い合わせ対応」「調査」「トラブルシュート」 - 「この問い合わせについて調べて」 - 「〇〇についてヘルプを調べて」 - 具体的なエラーメッセージや問題の相談 ## 参照先リソース ### 1. ヘルプドキュメント（公式） knowledge/help-docs/ └── *.md # プロダクトのヘルプページ ユーザーに公開されている公式ヘルプページ。基本的な使い方・仕様・FAQ。 ### 2. 過去の対応事例（テクサポナレッジ） knowledge/case/ └── yyyymmdd_*.md # 過去の対応事例 テクニカルサポートで対応した実際の事例。原因調査・解決策の記録。 ### 3. システム仕様（ビジネスロジック） knowledge/system-specs/ ├── database/ # データベース仕様 └── business-logic/ # ビジネスロジック プロダクトの内部仕様。DB構造調査・詳細な技術調査時に参照。 ## ワークフロー ### Step 1: 問い合わせ内容の把握 ユーザーから以下を確認: - 何が起きているか（エラーメッセージ、症状） - いつから発生しているか - 影響範囲（特定アカウント / 全体） ### Step 2: ヘルプドキュメントの検索 公式ヘルプから関連情報を検索: 検索のコツ: - エラーメッセージの一部で検索 - 機能名・媒体名で検索 - 「エラー」「できない」「表示されない」などの症状で検索 ### Step 3: 過去事例の検索 テクサポナレッジから類似事例を検索。 キーワード検索や特定期間の事例確認が可能。 ### Step 4: 回答の作成 検索結果を元に回答を作成: 1. ヘルプに記載がある場合 - ヘルプの内容を要約して回答 - ヘルプページのURLを案内 2. 過去事例がある場合 - 類似事例の原因・対応方法を参考に回答 - 同じ原因かどうか確認のための質問を追加 3. 情報が見つからない場合 - 追加調査が必要な旨を報告 - 確認すべき項目を整理 ### Step 5: ナレッジとして保存 対応完了後、knowledge-saveスキルでナレッジを保存。 対応事例を蓄積し、次回以降の調査で再利用できるようにする。 ## 検索優先度 | 優先度 | リソース | 用途 | |:------:|----------|------| | 1 | help-docs | 公式仕様・基本的なFAQ | | 2 | case | 過去の調査結果・解決策 | | 3 | system-specs | DB構造・内部仕様（詳細技術調査） |
