こんにちは、クラウドサインで CRE（Customer Reliability Engineer）をしている藤谷です。CRE は、顧客が安心してプロダクトを使い続けられるよう、問い合わせ対応からプロダクト改善までをエンジニアリングで支える役割です。
先日の記事「問い合わせ対応の全工程の自動化を AI で実現」では、Agent Skills 活用の事例を紹介しました。
今回は、その全工程の「中身」の話です。Agent Skills（Markdown ファイルで AI エージェントにドメイン固有のスキルを渡す仕組み）に込めた設計思想を共有します。
私たち CRE には問い合わせにおいて 2 つの基本的な考え方があります。問い合わせの一字一句から顧客の真の課題を読み解くこと。そして「問い合わせが届いた時点で、すでに遅い」という予防の視点です（詳しくは「CRE が「回答のその先」に見ている景色」で書きました）。これをスキルとしてどう実装したかを紹介します。
誤解のないように最初に伝えておきたいのですが、私たちは AI に回答を丸投げしているわけではありません。顧客により深く寄り添い、理解するために、AI というツールを使って顧客理解を強力に深めようとしています。スキルに込めた設計思想は、この考え方が土台にあります。
問い合わせ調査 — CRE の「考え方」を AI に渡す
まずスキルの全体像を見せます。実際のスキルは以下のような構造の Markdown ファイルです。
# CRE ヘルプデスク ## 入力の自動検知 Jira の URL が貼られたら、チケットを取得してワークフローを自動選択 ## ワークフロー選択 | ワークフロー | 使用場面 | |---|---| | 問い合わせ調査 | 新規問い合わせの調査・回答案作成 | | 回答レビュー | 回答案のレビュー・修正案作成 | | CRE Done（対応完了） | 対応完了後の振り返り・ナレッジ生成 | ## 品質ゲート（サブエージェント） 各チェックポイントでサブエージェントを起動し独立検証 ## 共通: 課題整理の観点 / 品質チェック / 調査データソース ...
業務の手順・判断基準・品質チェックの観点が、見出しとテーブルで構造化されています。AI エージェントはこの Markdown を読み込み、指示通りに動きます。
以降で紹介するコードブロックは実際のスキルからの抜粋です。実物はこれより多くのルールや分岐を含んでいますが、この記事では設計思想が伝わる部分に絞って紹介します。
質問の裏にある背景を読み解かせる
以前の記事で「顧客の問い合わせには、一字一句に意味がある」と書きました。質問を「点」で捉えず、業務フローという「線」の中で捉え直します。この考え方を、AI スキルにそのまま書き込んでいます。
スキルには、質問パターンごとの読み解きの観点を明示しています。
### 1. 質問を理解する — 「なぜ聞いてきたのか」を読み解く - 既に別の解決策を提示されているのに再質問 → より良い方法を探している - 「〜できますか？」という質問 → 業務フローに組み込めるか判断したい - 特定条件下での挙動を聞いている → その条件で困った経験がある - 同じ質問を言い換えて繰り返している → 前回の回答では解決していない 顧客が本当に知りたいことは大きく2つ: 1. このプロダクトを業務フローに組み込んで大丈夫か 2. この運用は社内で説明できるか
AI にこの観点を渡すことで、単なるキーワード検索ではなく、AI が「なぜ聞いてきたのか」を推測しながら調査を進めるようになります。CRE はそれをもとに、顧客が本質的に何に困っているかをより深く正確に理解できるようになります。
エラー画面のスクリーンショットも AI に認識させる
以前の記事でも触れましたが、エラー画面や UI 上の表示状態のスクリーンショットには、テキストでは伝わらない「困り度合い」や「文脈」が詰まっています。
スキルでは、こうしたエラー情報の画像読み取りを AI に組み込みました。問い合わせ文面に書かれていない「操作のしづらさ」や「誤解しやすい UI」にも注目させ、顧客の申告内容と実際の画面状態を突き合わせます。認識のズレがあれば、それ自体が調査の手がかりになると考えています。
情報源を AI で見て伝言ゲームを防ぐ
課題を整理したら、次は調査です。スキルでは調査の順序も設計しています。
## 手順 1. 課題整理 → 🔍 CP-課題整理（サブエージェントで検証） 2. 既知事例チェック（ログ調査の前に必ず実施） 3. 情報収集: HubSpot会話履歴 → Slackスレッド 4. 調査: ヘルプセンター → esa → ログ → コードベース 5. 回答案作成 → 🔍 CP-回答案（サブエージェントで検証）
まず顧客対応の会話履歴を確認します。これがなぜ重要かというと、CRE への問い合わせはカスタマーサクセス（CS）からエスカレーションされることが多く、伝達の過程で文脈が落ちてしまうことがあるためです。だから AI に経緯を直接把握させ、顧客が本当に言いたかったことを正確に認識させています。
次に「既知事例のチェック」から始めます。ログ調査は時間がかかるため、社内ナレッジ（esa）や過去の Jira（課題管理ツール）チケットで類似事例がないかを先に確認するのが基本です。既知事例に該当すれば調査工数を大幅に削減できますし、ログ調査の観点も絞れます。
その上で、AI がヘルプセンター・社内ナレッジ・アプリケーションログなど必要な情報源を順に調査します。CRE が手作業で調査していたときと同じ手順を、同じ優先順位で、AI が再現できるようにスキルとして設計しました。これが調査手順を書き込んだ効果です。
バラバラだったツールが繋がり、顧客理解の質が変わる
ここまで紹介した調査の流れを支えているのが、ツールの統合です。
CRE が手作業で調査していた頃は、Slack・Jira・esa・ヘルプセンター・アプリケーションログを 1 つずつ開いて個別に検索し、頭の中で情報を繋いでいました。ツールを切り替えるたびにコンテキストが途切れ、情報の関連付けは CRE 個人の記憶と経験に頼るしかありません。
スキルにより、これらのツールがすべて AI エージェントの中で繋がりました。AI は Slack の会話で得た手がかりからログを絞り込み、ログで特定した事象を社内ナレッジの過去事例と照合し、ヘルプセンターの記載との差分まで一気通貫で追跡します。人間が時間の制約で拾いきれなかった情報の繋がりを、AI が網羅的に見つけ出します。
バラバラだったツールが AI エージェントに統合されたことで、CRE は顧客が本質的に何に困っているかを一段深く理解できるようになりました。単なる効率化ではなく、顧客理解の質そのものの変化です。
回答の品質 — 根拠に基づく回答のためのルール設計
「読んだ人が次に何をすればいいか」が分かる回答
調査結果を回答案にまとめる段階でも、スキルには明確なルールを設けました。
顧客が読んだ後に「次に何をすればいいか」が明確になること。これが目指す姿です。
メインエージェント（問い合わせ対応の主担当 AI）は回答案の作成時に、スキルに定義した観点でセルフチェックを行います。
### レビュー観点 - 課題理解: 「なぜ知りたいのか」を汲み取り、次のアクションが明確か - 調査の十分性: 根拠は明確か、推測で回答していないか - 回答の適切性: 社外秘を含まないか、自走を促せているか - 表現: 結論が冒頭か、専門用語を避けているか、誤字脱字がないか
これは一部で、実際には利用規約チェックやユビキタス言語チェック、エスカレーション判定なども含め十数の観点でチェックしています。中でも「自走を促せているか」がポイントです。回答して終わりではなく、次に似たことが起きたときに顧客自身で確認できる情報を添えることを、スキルレベルでチェックしています。さらに、顧客が明示的に聞いている質問項目をすべて列挙し、回答案で各項目に 1 対 1 で回答しているかも照合します。1 つでも未回答の項目があれば、必須修正です。
根拠の検証 — メインとサブの二重チェック
中でもスキルとしてもっとも重視したのが「根拠の検証」です。AI は一般的にもっともらしい回答を生成しますが、それがプロダクトの実際の仕様に基づいた事実なのか、一般論から推測した内容なのかは区別がつきません。この検証を、メインエージェントとサブエージェントの二重構造で行っています。
まず、メインエージェントの出力形式に「根拠」セクションを設けました。回答案の各主張に対して、どの情報源（ヘルプセンター記事・社内ナレッジ・ログなど）のどの記載を根拠としたかを明示させます。根拠が見つからない主張は「推測である」と明記するルールです。
さらに、前回の記事で紹介したサブエージェント（メインとは別プロセスで動く検証用エージェント）が、この根拠を独立に裏取りします。メインが「ヘルプセンターに〜と記載されている」と述べていれば、サブエージェントが同じ記事を自分で取得して実際の記載と照合します。「ログを確認したところ〜」という記述があれば、同じクエリでログを再取得して突合します。どの情報源にも根拠が見つからない主張は、重大問題として報告されます。
先ほどスキルの全体像で触れた「品質ゲート」の中身が、まさにこの二重チェックです。スキルには、工程ごとのチェックポイントと、サブエージェントの動作原則、判定ルールを定義しています。
### チェックポイント一覧 | チェックポイント | タイミング | 検証内容 | |---|---|---| | CP-課題整理 | 課題整理の完了後 | 問題理解の妥当性、見落としの検出 | | CP-調査 | 調査完了後 | 根拠の十分性、ログの正確性 | | CP-回答案 | 回答案の作成後 | 根拠の独立検証、利用規約、ユビキタス言語 | ### サブエージェントの動作原則 1. 独立検証: メインの結論を前提にしない。自分でデータを取得して確認する 2. 早期検出: 上流の誤りを見つけたら即座に報告。下流に伝播させない ### レビュー結果の反映 - ✅ PASS: そのまま次のステップへ進む - ⚠️ 要修正: 指摘事項を反映してから次へ進む - 🔴 重大問題: CRE に報告し、対応方針を確認してから進む
特に CP-課題整理をもっとも厳しく検証する設計にしています。課題整理の段階で認識がズレると、その後の調査や回答がすべて的外れになるためです。サブエージェントはメインの結論を鵜呑みにせず、元の問い合わせ文面を自ら読み直し、メインの課題理解と照合します。
ユビキタス言語の統一
回答の品質には、表現の正確さも含まれます。スキルではユビキタス言語チェックを組み込んでいます。
ユビキタス言語とは、プロダクト内で統一された用語体系のことです。たとえばクラウドサインの機能名や操作名を、社内の通称ではなくヘルプセンターやプロダクト UI と同じ表現で統一させています。顧客がヘルプセンターを見たときに、CRE の回答と同じ言葉が使われていること。この一貫性が、顧客の混乱を防ぎます。
対応完了後の振り返り — 同じ問い合わせを減らしていく
CRE の振り返りを AI で深化させる
CRE チームでは、問い合わせ対応が完了するたびに「振り返り」を行っています。
なぜこの問い合わせが来たのか、社内ナレッジやヘルプセンターの記事は足りているか、プロダクトの UI や仕様に改善の余地はないか。この振り返りのプロセスを、スキルとして定義しました。
以前の記事で「問い合わせが届いた時点で、すでに遅い」と書きました。この考え方と、そこで紹介した分析視点をスキルに落とし込み、AI が自動で構造的に分析するようにしています。
分析の視点: - 同じ問い合わせが他の顧客でも発生しうるか（個別事象 or 構造的問題） - 問い合わせが来ていないのは「現場が自力で握りつぶしている」だけの可能性はないか - 「今回の回答」ではなく「次に問い合わせが来ない世界」にするには何が必要か
ポイントは、根本原因を「バグがあった」「仕様です」で止めないこと。ここで止めてしまうと、同じ問い合わせがまた来る原因となります。なぜそのバグが生まれたのか、なぜその仕様は顧客を混乱させるのか。直接原因と根本原因を切り分け、構造的・システム的な問題まで到達することを AI に求めています。
AI の網羅性が振り返りの質を変える
振り返りで AI がもっとも力を発揮するのは、分析の網羅性です。
人間が振り返りを行う場合、類似の過去事例を数件確認し、ヘルプセンターの該当記事をチェックして改善点を挙げます。確認できる範囲は、時間と認知負荷に制約されます。AI エージェントにはこの制約がありません。
社内ナレッジの関連記事、ヘルプセンターの全記事、過去の Jira チケットを横断スキャンし、「同じ根本原因を持つ過去事例」「ドキュメントの不足箇所」「類似の問い合わせが集中している時期と要因」まで洗い出してくれます。
1 件の問い合わせから、人間では追いきれなかった改善の種を網羅的に抽出できるようになりました。
この網羅性が、以降で紹介する 5 つの成果物の精度を支えています。
5 つの成果物でプロダクトを改善する
この振り返りでは、分析結果をもとに 5 つの成果物を自動生成します。
- 課題の根本原因・短期的対策・長期的対策の構造的な振り返り
- 社内ナレッジへの Q&A エントリの追加（重複チェック付き）
- 顧客向けヘルプセンター記事の修正案
- Web API ドキュメントの修正案
- 費用対効果の高い改善施策の Jira チケット起票案
特筆すべきは、5 つ目の Jira チケット起票案です。振り返りの根本原因から改善候補を 4 カテゴリ（プロダクト改善・プロセス改善・ドキュメント改善・自動化）で洗い出し、費用対効果で評価します。
| 評価軸 | 判断基準 | |---|---| | 影響度 | 影響ユーザー数 × 発生頻度 | | 対応コスト | ドキュメント修正 < 設定変更 < 機能開発 | | 費用対効果 | 影響度 ÷ 対応コスト。これが最大の候補を選択 | 選択の原則: プロダクト改善に限定せず、ドキュメントやプロセスの改善で解決できるならそちらを選ぶ
小さな工数で多くの顧客に効く施策を優先して起票案として提示する設計です。プロダクト改善ありきではなく、ドキュメント 1 行の追記で解決できるならそれが最善という判断を、AI にも持たせています。
ヘルプセンター・社内ナレッジの横断分析
振り返りの中で、AI はヘルプセンターの記載内容と問い合わせで明らかになった情報の差分を特定します。社内ナレッジでは、既存 Q&A と重複がないかを先に確認し、必要な場合のみ新規追加します。
この横断分析の考え方は、普段のナレッジ見直し作業にも共通しています。顧客が見るヘルプ記事と社内ナレッジの間に矛盾があれば、それが次の問い合わせの種になります。だから両方を横断して整合性を保つようにしています。
顧客の声をプロダクトへ届ける
振り返りの完了後、問い合わせ内容に顧客の機能要望・改善要望が含まれている場合は、顧客フィードバック管理ツールへの投稿用テキストを生成します。
ここでのポイントは、実装方法ではなく業務上のゴールとして要望を記述することです。スキルでは「要望内容」と「背景」を分けて出力させ、実装方法の指定を禁止事項として明示しています。
### フィードバック — 要望内容 - 顧客が実現したいことを書く（実装方法ではなく業務上のゴール） - 「〜したい」「〜できるようにしてほしい」の形式 ### フィードバック — 背景 - 問い合わせの経緯や業務フローを簡潔に記載 - 同様の問い合わせが複数あれば件数・頻度も記載 ### 禁止事項 - 実装方法の指定（「APIを追加して」等）— 要望と背景のみ
「API を追加してほしい」ではなく「月末の締め処理で一括送信したい」。顧客が実現したいことと、その背景にある業務上の課題を分けて記述させることで、開発チームが「何を解決すべきか」を判断しやすくなります。
顧客にとって何が変わるのか
ここまでの設計思想を、顧客の立場から見てみます。
AI が並行調査することで初動が速くなり、対応経緯を直接取得したうえで CRE が回答するため、CS を経由した伝言ゲームによる認識のズレも減ります。
振り返りで生成される改善アクションにより、問い合わせるたびにプロダクトが少しずつ良くなっていく。そして「次に似たことが起きたら、ここを見れば自分で確認できますよ」という案内が、問い合わせなくても解決できる状態へ繋がります。顧客にとって負担の少ない形を目指しています。
大事なのは、最終的に顧客に届く回答の判断と責任は、私たち CRE が持っていることです。AI は CRE がその判断をより正確に行うための「目」として機能しています。
まとめ
CRE が AI エージェントのスキルに込めた設計思想を振り返ります。
- バラバラだったツールを AI エージェントに統合し、顧客が本質的に何に困っているかをより正確に捉えられる状態にしたこと
- 顧客の発言から「なぜ聞いてきたのか」を読み解き、添付画像からもテキストにない文脈を把握する仕組み
- メインエージェントとサブエージェントの二重構造で、根拠のない推測が顧客に届くことを防ぐ回答設計
- 対応完了後の振り返りで AI の網羅性を活かし、1 件の問い合わせから「次に問い合わせが来ない世界」へ繋げる設計
AI や Agent Skills を使うこと自体は目的ではありません。常にその先にいる顧客にとって何ができるかを考えること。これは CRE としてだけでなく、プロダクトを提供する側として忘れてはいけない視点だと思っています。ツールや技術は変わっても、顧客に向き合う姿勢は変わりません。
スキルとは結局、CRE が顧客に向き合うときの「考え方」を、再現可能な形で書き出したものです。AI は「答え」を出す機械ではなく、顧客の声をどう聴き、どう深く理解し、どう次に繋げるか——その眼差しを再現する CRE の「目」として機能しています。この記事が、AI エージェントで顧客対応を設計しようとしているかたの参考になれば幸いです。
