SaaS運営者向けMCP活用: 顧客データを全部AIに渡さない調査の作り方

SaaSの問い合わせ調査で、CS担当が「請求メールが届かない」と聞かれ、管理画面、Stripe、SendGrid、DB、障害ログを順に開いている。ここでMCPをつないで全部AIに見せれば速く見えますが、顧客名、メール、契約金額、支払い情報、本文ログまで同じ調査材料に混ざります。今日まず直す1箇所は、MCPに渡してよい列、渡さない列、実行させないtoolを分けた調査表です。

この記事では、SaaS運営者がMCPを使って顧客問い合わせを調査する前に、Claude Codeでデータ境界、read-only tool、allowlist、監査ログを作る流れを書きます。MCPはAIへ外部データやtoolをつなぐ標準プロトコルです。ただし、つなげることと、顧客データを全部渡すことは別です。SaaSでは、調査の速さより先に、tenant_id、ticket_id、伏せた要約、実行権限、記録の残し方を決めます。

参考にした一次情報は、Model Context ProtocolのSpecification、Security Best Practices、AnthropicのMCP connector、Introducing the Model Context Protocolです。既存の作り方はMCPサーバーの作り方で扱います。

この記事の要点

• SaaS運営者のMCP導入は、顧客データを全部AIに渡す話ではなく、調査に必要な列だけを見せる話から始める。
• MCPにはResources、Prompts、Toolsがある。SaaSの初回調査では、書き込みtoolよりread-only toolと伏せた要約を優先する。
• 渡してよい列はtenant_id、ticket_id、event_type、created_at、redacted_summary、plan_bandに絞る。
• 渡さない列は顧客名、メール、電話、支払い、契約金額、問い合わせ全文、access token、添付です。
• 人が見る範囲は、返金、契約例外、セキュリティ事故、顧客返信、本番書き込み、削除操作です。

SaaS調査で起きる失敗シーン

SaaSの問い合わせ調査では、最初の画面が多すぎます。サポートチケット、管理画面、決済、メール配信、status page、直近deploy、DBのイベントテーブル。担当者は急いでいるので、「MCPで全部検索できるようにしよう」と考えがちです。けれど、全部検索できる状態は、全部漏れる入口にもなります。

MCP仕様では、Host、Client、Serverの役割があり、ServerはResources、Prompts、Toolsを提供します。Resourcesは文脈やデータ、Promptsはワークフロー、ToolsはAIモデルが実行する関数です。便利なのはToolsですが、SaaSではここが危ないです。export_all_customers や update_invoice のようなtoolを雑に見せると、調査のつもりが顧客データの一括取得や本番変更に近づきます。

MCPのSecurity Best Practicesでは、confused deputy、token passthrough、SSRF、scope minimizationなどが扱われています。初心者向けに言い換えると、「誰の権限で何を呼んだのか」「tokenを横流ししていないか」「AIに見える範囲が広すぎないか」を見る話です。SaaSの調査では、読ませるのは顧客そのものではなく、調査に必要な事象です。

業務フロー: チケットから原因候補までを見る

SaaS運営者の調査フローは、チケット確認、伏せ字、イベント検索、直近変更、原因候補、担当者確認、返信または開発連携の順番です。MCPは、イベント検索、直近deploy確認、status page確認、FAQ候補、原因候補の表作りに使います。返金、契約例外、顧客返信、本番変更は外します。

最初の表は、チケット管理ツールやDBの列を左右に分けるだけで十分です。左にMCPへ渡してよい列、右に渡さない列を書きます。たとえば、ticket_id、tenant_id、event_type、created_at、redacted_summary、plan_bandは左です。customer_name、email、phone、billing_card、full_message、access_token、contract_amountは右です。

調査の流れ	MCPに渡してよいもの	人が見るもの
チケット確認	ticket_id、category、redacted_summary	顧客名、メール、問い合わせ全文
イベント検索	tenant_id、event_type、created_at	生ログ、token、IP詳細
決済調査	plan_band、invoice_status	カード情報、契約金額、返金判断
障害調査	status page、recent_deploys	障害認定、告知文、補償
返信準備	reply_note、missing_info	顧客返信文、法務表現

この表があると、Claude Codeへの依頼が変わります。「顧客を調べて」ではなく、「伏せたticket_idとevent_typeだけで、原因候補と人が見る判断を表にして」と頼めます。先に、調査で扱う材料が減ります。

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

Claude Codeに任せる範囲は、MCPのtool設計メモ、allowlist、denylist、read-only tool、監査ログ、調査用プロンプトです。たとえば、search_support_events、read_status_page、list_recent_deploys のようなread-only toolだけを最初に出します。請求更新、ユーザー削除、メール送信、全顧客exportのtoolは見せません。

人が見る範囲は、顧客との契約、返金、支払い、個人情報、セキュリティ事故、障害告知、本番書き込みです。Claude Codeが原因候補を出しても、顧客へ返信してよいかは人が見ます。MCP connectorではtoolのallowlistやdenylistが使えるため、最初から「呼んでよいtool」を狭くします。これは便利さを削るためではなく、調査を事故にしないためです。

監査ログも最初に作ります。見る項目は、who、when、tool、tenant_id、ticket_id、result_idです。結果全文ではなく、「誰が、いつ、どのtoolで、どのtenantのどのticketを調べたか」を残します。あとでAIの会話ログだけに頼らない形にします。

3つのUse case

Use case 1: 請求メールが届かない問い合わせを調べる

• 入力: ticket_id、tenant_id、invoice_status、email_event_type、redacted_summary、created_at。
• 出力: 配信失敗候補、直近の変更、追加で見る項目、担当キュー、返信前の注意点。
• 人の確認: メールアドレス、契約金額、返金、請求再送、顧客返信文を確認する。

このUse caseでは、MCPにSendGridやStripeを丸ごと見せません。まずread-onlyのイベント検索だけにします。返金や再請求は人へ戻し、Claude Codeには「何を見るか」を表にさせます。

Use case 2: 障害かもしれない問い合わせをdeploy履歴と照合する

• 入力: ticket_id、tenant_id、product_area、event_type、created_at、recent_deploys、status_page。
• 出力: 同時刻の変更候補、影響領域、開発へ聞く質問、障害候補のメモ。
• 人の確認: 障害認定、告知文、影響範囲、補償、重要顧客への連絡を決める。

障害調査はMCPと相性がよい一方、AIが「障害です」と断定すると危ないです。Claude Codeには時刻、event_type、直近deployを並べさせ、人が告知を判断します。

Use case 3: サポート履歴からFAQ候補だけを取り出す

• 入力: redacted_summary、category、product_area、resolution_tag、ticket_count。
• 出力: FAQ候補、既存ヘルプとの差分、公開前に見る表現、問い合わせ削減の仮説。
• 人の確認: 顧客固有の事情、契約条件、法務表現、公開してよい範囲を確認する。

FAQ作りでは、問い合わせ全文をAIに渡したくなります。最初はredacted_summaryとresolution_tagだけで十分です。公開文は、サポート責任者が顧客固有情報を消してから見ます。

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

あなたはSaaS運営者のMCP調査設計担当です。
目的は、顧客データを全部AIへ渡さず、問い合わせ調査に必要なread-only toolと監査ログを決めることです。

入力:
- 調査したい問い合わせ:
- ticket_id:
- tenant_id:
- event_type:
- created_at:
- redacted_summary:
- 使いたいMCP server:
- 既存tool一覧:

出力:
1. MCPへ渡してよい列
2. MCPへ渡さない列
3. allowlistに入れるread-only tool
4. denylistに入れるwrite/export/delete/send系tool
5. 人が見る判断: 返金、契約、セキュリティ、障害告知、顧客返信、本番書き込み
6. 監査ログ: who、when、tool、tenant_id、ticket_id、result_id
7. 今日30分で直す1箇所

制約:
- customer_name、email、phone、billing_card、full_message、access_token、contract_amountを渡さない
- token passthroughを前提にしない
- 書き込みtoolを初回から出さない
- 不明な判断は人の確認へ戻す

動く確認コード

次のコードは、MCPでSaaS問い合わせ調査を始める前の境界を確認します。実MCP server、Claude API、SaaS DBには接続しません。まず、渡さない列、read-only tool、人の確認、監査ログが揃っているかを見ます。

const mcpResearchPlan = {
  task: "investigate failed invoice email",
  allowedFields: ["tenant_id", "ticket_id", "event_type", "created_at", "redacted_summary", "plan_band"],
  blockedFields: ["customer_name", "email", "phone", "billing_card", "full_message", "access_token", "contract_amount"],
  allowedTools: ["search_support_events", "read_status_page", "list_recent_deploys"],
  blockedTools: ["export_all_customers", "update_invoice", "delete_user", "send_customer_email"],
  humanReview: ["refund", "legal wording", "security incident", "customer reply", "production write"],
  auditLog: ["who", "when", "tool", "tenant_id", "ticket_id", "result_id"]
};

const requiredBlocked = ["email", "full_message", "access_token", "billing_card"];
const requiredAllowedTools = ["search_support_events"];
const requiredHuman = ["refund", "security incident", "production write"];
const requiredAudit = ["who", "tool", "tenant_id", "ticket_id"];

const findings = [
  ...requiredBlocked
    .filter((field) => !mcpResearchPlan.blockedFields.includes(field))
    .map((field) => ({ type: "blocked field missing", field })),
  ...requiredAllowedTools
    .filter((tool) => !mcpResearchPlan.allowedTools.includes(tool))
    .map((tool) => ({ type: "needed read-only tool missing", tool })),
  ...requiredHuman
    .filter((item) => !mcpResearchPlan.humanReview.includes(item))
    .map((item) => ({ type: "human review missing", item })),
  ...requiredAudit
    .filter((field) => !mcpResearchPlan.auditLog.includes(field))
    .map((field) => ({ type: "audit field missing", field }))
];

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

空のtableが出れば、最低限の線引きは揃っています。もしemail、full_message、access_token、billing_cardがblocked側にないなら、MCP serverをつなぐ前に止めます。MCPの価値は、全部見せることではなく、調査に必要な窓だけを作ることです。

Pitfall: よくある落とし穴

原因: MCP serverに全顧客export toolを置く。直し方: 初回はread-onlyの検索toolだけにします。export、delete、update、sendはdenylistに入れます。

原因: SaaSのaccess tokenをMCP serverへ横流しする。直し方: token passthroughを避け、audience、scope、client、監査ログを確認できる形にします。公式Security Best Practicesでもanti-patternとして扱われています。

原因: tenant_idを見ずに問い合わせを検索する。直し方: すべてのread toolでtenant_idを必須にし、resultにもtenant_idとticket_idを残します。境界が曖昧だと、別顧客のログが混ざります。

原因: allowlistを作らず、MCP serverのtoolを全部見せる。直し方: 調査に使うtoolだけをallowlistにし、write/export/delete/send系はdenylistへ入れます。MCP connectorのように個別tool設定がある場合は、最初から狭くします。

よくある質問

Q. MCPを使うなら、顧客DBを全部つなぐ必要がありますか。 A. ありません。最初は、問い合わせ調査に必要なread-only toolだけで十分です。全顧客exportや書き込みtoolは後回しにします。

Q. Resources、Prompts、Toolsの違いを初心者向けに言うと何ですか。 A. Resourcesは読む材料、Promptsは作業の型、Toolsは実行できる関数です。SaaSではToolsが一番強いので、最初に絞ります。

Q. Claude Codeに問い合わせ本文を貼ってよいですか。 A. 実顧客の本文は避けます。redacted_summary、category、ticket_id、tenant_id、event_typeで足りるかを先に試します。

研修・相談につなげるなら何を見るか

SaaS運営者がMCPを入れる相談では、MCP serverのコードだけでなく、顧客データの分類、tenant_id、tool allowlist、denylist、監査ログ、返金や障害時の人の判断を同じ表にします。

ClaudeCodeLabの研修・相談では、SaaSの問い合わせ調査、MCP server、Claude Code、サポート履歴、決済、メール配信、監査ログを一緒に棚卸しできます。今日やるなら、既存のMCP tool候補をread-only、write、export、delete、sendの5列に分けてください。

実際に試した結果

この記事では、Model Context ProtocolのSpecification、Security Best Practices、AnthropicのMCP connector、公式発表、記事内JavaScript確認コード、内部リンク、CTA、frontmatter、slugを確認しました。コードはallowedFields、blockedFields、allowedTools、blockedTools、humanReview、auditLogを見ます。今日まずやる1手は、MCPに渡してよい列と渡さない列を左右に分けることです。