BtoB SaaSのVertex AI連携メモをClaude Codeで作る: 営業FAQとサポート履歴の使い分け

BtoB SaaSの営業ページを直していると、営業FAQ、ヘルプセンター、サポート履歴、商談メモ、Slackの質問が全部「AIに読ませる候補」に見えてきます。ところが、顧客名、契約条件、障害時のやり取り、未公開ロードマップまで混ざると、便利なFAQどころか情報漏れの入口になります。

この記事では、BtoB SaaSがVertex AIやAgent Searchを検討する時に、Claude Codeで連携メモを作り、営業FAQとサポート履歴を分ける手順を書きます。狙いは「AIチャットを置く」ことではありません。問い合わせ削減、商談前の不安解消、サポート品質を狙いながら、顧客データを雑にAIへ渡さない境界を作ることです。

この記事の要点

• BtoB SaaSでは、営業FAQ、ヘルプ記事、サポート履歴、商談メモ、ロードマップを同じデータ源にしない方が安全です。

• Vertex AI周辺では、RAG、Grounding、Agent Search、Safety filtersを見ながら、使うデータと使わないデータを先に分けます。

• Claude Codeには、データ分類表、回答可否ルール、プロンプト、検証質問、運用メモを作らせます。

• 人が見る範囲は、顧客名、契約条件、障害履歴、個人情報、未公開機能、法務表現、料金回答です。

• ROIは、商談前FAQの自己解決率、サポート一次回答時間、誤回答件数、エスカレーション率、有料相談への導線で見ます。

現場で起きる失敗シーン

BtoB SaaSでよくある失敗は、営業FAQを作るつもりでサポート履歴を丸ごと使うことです。サポート履歴には、顧客名、利用プラン、契約条件、障害時のやり取り、返金相談、解約理由、担当者名が入ります。営業ページのFAQには便利そうでも、そのまま検索対象にすると危ない情報が多すぎます。

もうひとつの失敗は、営業FAQとサポートFAQの目的を混ぜることです。営業FAQは、導入前の不安を減らし、資料請求や商談予約へ進めるためのものです。サポートFAQは、契約後の操作、障害、設定、請求、権限の質問に答えるものです。答える相手も、責任も、見せてよい情報も違います。

参考にする公式情報は、Google CloudのRAG Engine、Grounding、Agent Searchのデータストア、Safety filters、Responsible AIです。RAGやGroundingは、モデルの回答をデータに近づける考え方です。ただし、どのデータを渡すかを間違えると、正確に危ない情報を返すだけになります。

• Google Cloud: RAG Engine overview

• Google Cloud: Grounding overview

• Google Cloud: Grounding with Google Search

• Google Cloud: Create a search data store

• Google Cloud: Safety and content filters

• Google Cloud: Responsible AI

業務フロー: AIに渡す前にデータを4つに分ける

最初に作るのはVertex AIの設定ではありません。SaaSのFAQ候補を、公開してよい情報、顧客別に隠す情報、社内だけの情報、AIに渡さない情報の4つに分けます。ここを飛ばすと、後からどの回答がどのデータに基づいたのか追えません。

営業FAQに向いているのは、機能概要、導入手順、セキュリティ方針の公開版、料金プランの公開範囲、よくある比較、導入事例の公開済み情報です。サポート履歴に向いているのは、管理画面の操作手順、エラーの切り分け、権限設定、請求画面、連携設定です。商談メモや個別契約の条件は別扱いにします。

| データ源 | AIに使う範囲 | 人が確認する点 |

| --- | --- | --- |

| 営業FAQ | 公開済み機能、料金の公開範囲、導入前の質問 | 法務表現、料金例、競合比較 |

| ヘルプ記事 | 操作手順、設定、権限、エラー | 古いUI、廃止機能、スクショ |

| サポート履歴 | 匿名化した質問パターン、頻出エラー | 顧客名、契約条件、障害履歴 |

| 商談メモ | 原則AIに渡さない。使うなら論点だけ抽出 | 顧客名、予算、未公開ロードマップ |

| ロードマップ | 公開済み予定だけ | 未公開機能、日付の断定 |

Vertex AIやAgent Searchを使う前に、この表を社内で合意します。Claude Codeには、既存FAQ、ヘルプ記事、サポート履歴の列名、問い合わせ分類を読ませ、どの情報がどの箱に入るかを下書きさせます。

Claude Codeに任せる範囲と人が見る範囲

Claude Codeに任せる範囲は、データ分類と検証質問の下書きです。FAQ、ヘルプ記事、CSVの列名、サポートタグ、既存問い合わせ分類、NG回答例を読ませ、営業FAQに使う情報とサポートFAQに使う情報を分けます。

人が見る範囲は、顧客ごとの事情です。顧客名、契約条件、個別割引、障害報告、法務表現、セキュリティ回答、未公開機能、料金の例外は、人が確認します。AIが「回答できそう」と言っても、商談やサポートの責任は会社に残ります。

RAGやGroundingは、回答の根拠をデータに寄せます。だからこそ、データの境界が先です。営業FAQにサポート履歴を混ぜる時は、顧客名を消すだけでは足りません。契約条件、障害名、個別運用、担当者名、日時、問い合わせIDも手がかりになります。

3つのUse case

Use case 1: 営業FAQとサポート履歴を分ける

• 入力: 公開FAQ、ヘルプ記事、サポート履歴CSVの列名、問い合わせタグ、商談前によく聞かれる質問。

• 出力: 営業FAQ向け、サポートFAQ向け、社内確認向け、AIへ渡さない情報の4分類表。

• 人の確認: 顧客名、契約条件、障害履歴、未公開機能、個別価格が混ざっていないかを見る。

このUse caseでは、Claude Codeに本文を丸ごと貼るより、まず列名とサンプルをマスクして渡します。営業FAQに使うのは、公開してよい表現だけにします。

Use case 2: Vertex AI連携前の検証質問を作る

• 入力: 想定ユーザー、料金ページ、ヘルプ記事、NG回答例、エスカレーション条件。

• 出力: 回答してよい質問、回答せず人へ渡す質問、根拠リンクが必要な質問のテストセット。

• 人の確認: 料金、契約、セキュリティ、障害、解約、個別要望の回答境界を決める。

RAGやAgent Searchを入れた後に試すのでは遅いです。先に検証質問を作り、営業ページの不安解消に効く質問と、サポート担当へ渡すべき質問を分けます。

Use case 3: 誤回答時の運用メモを作る

• 入力: 誤回答例、問い合わせログ、サポート担当の修正コメント、公開FAQの更新履歴。

• 出力: 誤回答の分類、修正するデータ源、再テスト質問、公開前承認者を持つ運用メモ。

• 人の確認: 法務表現、返金条件、障害説明、顧客影響、公開タイミングを確認する。

SaaSのAI FAQは、一度置いたら終わりではありません。回答がずれた時に、プロンプトを直すのか、FAQを直すのか、サポート記事を直すのかを決める運用が必要です。

コピペで使えるプロンプト

あなたはBtoB SaaSのVertex AI連携メモ作成担当です。目的は、営業FAQとサポート履歴を分け、顧客データを雑にAIへ渡さないことです。



対象:

- 公開FAQ

- ヘルプ記事

- サポート履歴CSVの列名

- 問い合わせタグ

- 料金ページ

- NG回答例



作ってほしいもの:

1. 営業FAQ向け、サポートFAQ向け、社内確認向け、AIへ渡さない情報の4分類表

2. Vertex AI / Agent Searchに渡す前の検証質問20個

3. 回答してよい質問、人へ渡す質問、根拠リンクが必要な質問の3列表

4. 誤回答時に、FAQ、ヘルプ記事、プロンプト、データ分類のどこを直すかの運用メモ

5. 主CTAは /training/ にする



制約:

- 顧客名、契約条件、個別価格、障害履歴、未公開ロードマップを本文に再掲しない

- 法務やセキュリティ回答をAIだけで断定しない

- 実装前に、人が承認する境界を明記する

動く確認コード

下のNode.jsコードは、FAQ候補の分類漏れを確認します。Vertex AIへ接続するコードではありません。まずAIへ渡す前のCSVやJSONで、顧客データらしき列が営業FAQへ混ざっていないかを見ます。

const faqCandidates = [

  { source: "public_faq", title: "料金プランの違い", bucket: "sales_faq", fields: ["plan", "price", "feature"] },

  { source: "support_history", title: "A社の障害時対応", bucket: "sales_faq", fields: ["customerName", "incidentId", "contractNote"] },

  { source: "help_center", title: "権限ロールの変更", bucket: "support_faq", fields: ["role", "setting", "screen"] }

];



const sensitiveHints = [/customer/i, /contract/i, /incident/i, /discount/i, /account/i, /顧客/, /契約/, /障害/, /割引/];

const findings = faqCandidates.flatMap((item) => {

  const sensitiveFields = item.fields.filter((field) => sensitiveHints.some((pattern) => pattern.test(field)));

  if (item.bucket === "sales_faq" && sensitiveFields.length > 0) {

    return [{ title: item.title, source: item.source, issue: `営業FAQに敏感な列が混ざっています: ${sensitiveFields.join(", ")}` }];

  }

  return [];

});



if (findings.length > 0) {

  console.table(findings);

  process.exitCode = 1;

} else {

  console.log("SaaS FAQ data boundary looks ready for review.");

}

実行例は、vertex-faq-boundary-check.mjs として保存し、node vertex-faq-boundary-check.mjs です。A社の障害時対応が営業FAQに入っていると出たら、営業ページ用の公開FAQから外します。

Pitfall: RAGに入れたから正しいと信じる落とし穴

原因: RAGやGroundingは、回答をデータへ近づけます。ただし、入れたデータが営業FAQに向かない情報なら、正確に危ない回答を返します。サポート履歴を丸ごと入れると、顧客名や契約条件に近い断片が回答に混ざるおそれがあります。

直し方: データの入口で分けます。営業FAQは公開済み情報と商談前の不安に絞る。サポート履歴は匿名化して質問パターンだけ見る。契約条件、障害履歴、未公開ロードマップはAIに渡さない箱へ置きます。

もうひとつの落とし穴は、誤回答の直し先を全部プロンプトに寄せることです。回答が古いならFAQやヘルプ記事を直します。境界が甘いなら分類表を直します。言い回しだけの問題ならプロンプトを直します。

よくある質問

Q. BtoB SaaSでVertex AIを使うなら、まず何から始めますか。

A. まずデータ分類表です。FAQ、ヘルプ、サポート履歴、商談メモ、ロードマップを分け、AIに渡すものと渡さないものを決めます。

Q. サポート履歴は全部消すべきですか。

A. 全部消す必要はありません。質問パターン、タグ、頻出エラー、操作手順は役に立ちます。ただし顧客名、契約条件、障害履歴、個別価格は分けます。

Q. Grounding with Google Searchは営業FAQに使えますか。

A. 公開情報の補助には使えます。ただし自社SaaSの契約条件やサポート履歴の代わりにはなりません。公開情報と社内データの境界を分けます。

Q. 相談導線は何に寄せますか。

A. Vertex AI、Agent Search、RAG、データ分類、セキュリティ境界が絡むため、主CTAは研修・相談です。

相談へ進むなら

ClaudeCodeLabの研修・相談では、BtoB SaaSのFAQ、ヘルプ記事、サポート履歴、Vertex AI / Agent Search連携前のデータ分類、検証質問、運用メモを一緒に作れます。今日やるなら、まずFAQ候補を20件だけ選び、営業FAQ、サポートFAQ、社内確認、AIへ渡さない情報の4つに分けてください。

実際に試した結果

この記事では、frontmatter、本文文字数、公式リンク、Use case 3本、入力・出力・人の確認、コードフェンス、/training/へのCTAを確認しました。確認コードはNode.jsで構文を通し、営業FAQへ顧客名、契約条件、障害IDに近い列が混ざるケースを検出するところまで見ました。Vertex AIやAgent Searchへの接続は実行せず、実装前の分類メモとして残しました。