Stripe MCP を業務に載せる｜課金イベント参照と返金操作の権限分離（要公式・実装確認）

決済プラットフォームとして圧倒的なシェアを誇るStripeにおいて、運用業務の効率化は常にバックオフィスの課題です。特にカスタマーサポートにおける「支払い状況の照会」や「返金処理」は、慎重な操作が求められる一方で、日々のルーチンワークとして工数を圧迫します。

2024年末、Anthropic社が発表した「Model Context Protocol（MCP）」は、AIエージェントが外部ツール（Stripe等）のコンテキストを直接理解し、操作することを可能にしました。本記事では、このStripe MCPを実務に投入するための、「参照」と「操作」の権限分離にフォーカスした完全な実装ガイドを提示します。

Stripe MCP導入の意義と業務効率化の全体像

Model Context Protocol（MCP）が決済運用を変える理由

MCPは、AIモデル（Claude 3.5 Sonnetなど）がローカルまたはリモートのデータソースやツールに安全にアクセスするためのオープン標準です。Stripeが提供するMCPサーバー実装（stripe/mcp-server）を利用することで、自然言語で「先週の売上推移を教えて」「未払いのインボイスがある顧客をリストアップして」といった指示が可能になります。

これまでのようにSQLを叩いたり、ダッシュボードの複雑なフィルタリング機能を駆使したりする必要はありません。AIがStripeのAPIドキュメントと実データを解釈し、即座に回答を出力します。

従来のダッシュボード運用 vs MCPによるAIエージェント運用

従来、CS担当者はStripeダッシュボードにログインし、顧客を検索し、複数のタブを行き来して返金可否を判断していました。MCPを導入することで、CRMやチャットツールから離れることなく、コンテキストを維持したまま決済操作を完結できます。

権限分離の設計思想：参照と操作を切り分ける

実務でStripe MCPを運用する際の最大の懸念は、**「AIが誤って大規模な返金を実行してしまうこと」や「全権限を持つAPIキーが漏洩すること」**です。これを防ぐためには、単一のAPIキーで運用するのではなく、用途に応じた権限分離が不可欠です。

最小権限の原則（PoLP）に基づくRestricted API Keyの作成

Stripeでは「Secret Key」の他に、アクセス可能なリソースを制限できる「Restricted API Key」を作成できます。実務においては、このRestricted Keyの使用が必須です。

• 参照専用キー: charges, customers, invoices, subscriptions などの Read 権限のみを付与。
• 操作用（返金）キー: refunds の Write 権限を付与。

このように、業務システムやデータ基盤の設計においても、責務を分けることが定石です。例えば、【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』で示しているように、各ツールが持つべきデータと権限を明確にすることが、セキュリティ事故を防ぐ第一歩となります。

参照専用ロール（Read-Only）の権限スコープ

CS担当者の日常業務（問い合わせ対応）には、参照権限のみを持つMCPサーバーを提供します。これにより、誤操作による返金リスクを物理的にゼロにできます。

推奨設定（Stripeダッシュボード）:

All Payment resources: Read

All Subscription resources: Read

All Customer resources: Read

実行専用ロール（Write-Only / Refunds）の権限スコープ

返金実行が必要な場合は、特定の「返金承認プロセス」を通った後にのみ、書き込み権限を持つMCPサーバー、あるいは専用のAPIエンドポイントが起動するように設計します。refunds に対する Write 権限は、極めて慎重に扱うべき「特権」です。

Stripe MCP サーバーの実装とデプロイ手順

公式リポジトリの確認と環境構築

Stripe MCPの公式サーバーは、Node.js / TypeScriptで実装されています。まずはリポジトリからソースを取得し、環境を構築します。

git clone https://github.com/stripe/mcp-server-stripe.git
cd mcp-server-stripe
npm install
npm run build

MCP設定ファイル（stipe-config）の書き分け

AIクライアント（Claude Desktop等）から利用する場合、config.json にAPIキーを記述します。ここで、参照用と実行用の2つのプロファイルを作成することをお勧めします。

{
"mcpServers": {
"stripe-reader": {
"command": "node",
"args": ["/path/to/mcp-server-stripe/build/index.js"],
"env": {
"STRIPE_API_KEY": "rk_live_ReadOnlyKey..."
}
},
"stripe-operator": {
"command": "node",
"args": ["/path/to/mcp-server-stripe/build/index.js"],
"env": {
"STRIPE_API_KEY": "rk_live_RefundWriteKey..."
}
}
}
}

実務においては、これらのキー管理は環境変数やSecret Manager（AWS/GCP）で行うのが一般的です。決済情報を扱う以上、ソースコードへの直書きは絶対に避けてください。

【実務編】課金イベント参照と返金操作のワークフロー

具体的な業務フローを想定し、どのようにAIと対話して業務を進めるかを解説します。

ステップ1：顧客情報と支払い履歴のコンテキスト取得

まずは stripe-reader サーバーを通じて、顧客の状況を把握します。

AIへのプロンプト例:

「customer_id: cus_XXXX の最近3ヶ月の支払い履歴を表示して。また、現在アクティブなサブスクリプションがあるか確認して。」

この段階で、AIは list_payment_intents や list_subscriptions APIを叩き、情報を要約して提示します。もし決済情報の不整合が見つかった場合、それが「システム的なエラー」なのか「ユーザーの支払い拒否」なのかをAIに推論させることも可能です。

こうしたデータの流れを整理する考え方は、会計ソフトの移行実務にも通じます。例えば、【完全版】勘定奉行からfreee会計への移行ガイド：機能・費用比較とデータ移行手順の実務で解説しているような、不整合を許さないデータクレンジングの思想をAI運用にも取り入れるべきです。

ステップ2：AIによる返金可否の一次判定

次に、社内の返金ポリシー（例：決済から7日以内、かつ未使用の場合のみ返金可）をAIに教え込み、判定を仰ぎます。

AIへのプロンプト例:

「この顧客は『間違えて重複購入した』と言っています。ポリシーに照らして、この pi_XXXX は返金対象になりますか？」

ステップ3：人間による最終承認を組み込むアーキテクチャ

返金（Create Refund）を実行するツールをAIが呼び出そうとした際、必ず「人間による確認ボタン」を介在させます。Claude Desktopなどのインターフェースでは、ツールの実行前にユーザーに承認を求めるプロンプトが表示されます。これこそが、AIの暴走を防ぐ最後の砦です。

よくあるエラー（402 Required, 403 Forbidden）の対処法

• 403 Forbidden: APIキーの権限不足です。Stripeダッシュボードで Restricted Key の Refunds 権限が Write になっているか再確認してください。
• 402 Request Failed: 返金対象の元となる支払いに十分な残高がない、または既に返金済みの場合に発生します。AIに「エラー内容を詳しく解析して」と指示することで、StripeのAPIレスポンスに含まれる詳細な理由（reason）を解説してくれます。

決済運用におけるセキュリティ・ガバナンスの要諦

AIに決済操作を委ねる以上、ログの監査と異常検知は必須です。

監査ログの集約：WebhookとBigQueryの活用

Stripe MCP経由で行われた操作も、Stripe側では通常のAPIリクエストとして処理されます。誰が（どのAPIキーが）操作したかを特定するために、Stripe Webhookを利用して全てのイベント（charge.refunded 等）をデータ基盤にストリーミングすることを推奨します。

このあたりのデータパイプライン構築については、高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例が非常に参考になります。決済ログをBigQueryに集約し、dbtで整形することで、不審な返金操作の早期発見が可能になります。

AIエージェントの暴走を防ぐガードレール設計

プロンプトインジェクション（悪意ある入力によってAIの挙動を操作される攻撃）への対策として、以下のガードレールを導入してください。

1. 金額制限: 一度の操作で返金できる上限額を、MCPサーバー側のコードでハードコーディング、あるいは設定ファイルで制限する。
2. 回数制限: 短時間に連続して実行される refund リクエストをレートリミットで遮断する。
3. コンテキストの分離: 顧客の個人情報（PII）が必要ない場合は、MCPに渡すデータを匿名化する中間層を設ける。

まとめ：安全にStripe MCPを業務に載せるためのチェックリスト

Stripe MCPは、正しく設計・運用すれば、決済運用の工数を劇的に削減する「魔法の杖」になります。しかし、その魔法を制御するには、厳格な権限管理と監査体制が欠かせません。

• [ ] Secret Keyではなく、Restricted API Keyを使用しているか？
• [ ] 参照用（Read）と操作用（Write）のサーバー・キーを物理的に分けているか？
• [ ] 返金操作の前に、必ず人間が内容を確認するステップ（Human-in-the-loop）があるか？
• [ ] 全ての操作ログを、Stripe外の安全なログ基盤（BigQuery等）に保存しているか？
• [ ] AIに与えるプロンプト（システム指示文）に、社内の返金ポリシーが明記されているか？

これらの準備が整ったとき、あなたの組織のバックオフィスは、AIと共に進化する「次世代の決済運用チーム」へと変貌を遂げるでしょう。