Engineering 2026.07.26

Stripe Connect で AI エージェントマーケットプレイスを構築する 5 step — Aiverse Studio 実装事例

AI エージェントや AI クリエイターが売り手になる「マーケットプレイス型 SaaS」を Stripe Connect で構築する時、実装で迷う 5 つの判断 (アカウント種別・オンボーディング・split 手数料・KYC / 特商法・payout 監視) を、Xiora の Aiverse Studio 実装事例をもとに整理します。

沓澤怜士 (Kutsuzawa Reo)
Xiora 代表 · info@xiora-official.com

この記事は何か

「AI エージェント側 (クリエイター / developer) が売り手、消費者側が買い手になるマーケットプレイス」を作りたい、というご相談を月 3-5 件受けています。共通してぶつかるのが、Stripe の「単純 Charges」ではなく「Stripe Connect」を使う判断と、その先の 5 つの選択肢です。

この記事では、Xiora が Aiverse Studio (AI 配信 SaaS) を Phase 2 (Hub 化) で Stripe Connect を導入する準備段階で整理した、5 step の実装判断を共有します。ドキュメント上の理論だけでなく、実際に services/shared/billing-core/ と billing-core-service/ (FastAPI) で走らせている実装ベースの話です。

免責: 本記事は情報提供を目的としており、Stripe 側の仕様変更に追随する責任は読者側にあります。実際の実装前に Stripe 公式ドキュメント (https://docs.stripe.com/connect) の該当ページをご確認ください。また特商法・電子契約法などの法規制については、事業内容に応じた法務レビューを受けることを推奨します。

Step 1 — Stripe Connect のアカウント種別を 3 つから選ぶ

Stripe Connect には 3 つのアカウント種別があり、選定を誤るとオンボーディング体験と分配ロジックが後戻り不能になります。

Standard — 売り手が自分の Stripe ダッシュボードを持つ。Stripe UX と手数料構造を売り手が直接負う。プラットフォーム側の実装コストが最小。
Express — Stripe ダッシュボードは簡略版、プラットフォーム側が UX を包む。売り手体験を統一しやすい。手数料と payout もプラットフォームで抽象化。
Custom — Stripe UX を全く見せず、すべてプラットフォーム側で構築。フル制御と引き換えに、KYC / 通知 / エラー UI を自前で用意する必要あり。

Xiora の判断は「AI クリエイター側の技術理解度」と「サービス初期段階での実装工数」で決めました。Aiverse Studio (Phase 2) では Express を選択予定です。理由は 3 つ:

クリエイターは Stripe のマーケットプレイス UX に不慣れなので、Custom で全部作ると初期リリースが 2-3 ヶ月遅延する
Standard だと売り手側の手数料設定が Xiora ブランドとズレる恐れ
Express なら Stripe が提供する Hosted onboarding で KYC 一次通過を任せられる

「Custom じゃないと自由度が足りない」という誤解が多いですが、Aiverse Studio の Phase 2 レベルでは Express で十分でした。Custom は「AI 側にも独自の payout ロジック (例: パフォーマンスベースの上乗せ) を組み込みたい」段階で検討します。

Step 2 — オンボーディング設計 (Hosted vs Embedded)

アカウント種別を選んだら、オンボーディング flow を Hosted (Stripe が提供する画面遷移) か Embedded (自社サイトに埋め込み) から選びます。Aiverse Studio では Hosted onboarding + 完了後 redirect backを採用しました。理由:

Hosted は Stripe 側で KYC UI を最新に保ってくれる (法規制対応の追随を Stripe に任せられる)
Embedded は柔軟だが、Stripe の UI 更新のたびに CSS 追随が必要
Aiverse Studio では「AI クリエイターが最短 10 分で登録完了する」ことが最優先

実装は POST /v1/account_links で type=account_onboarding、return_url に自社サイトの「登録完了しました」ページを指定するだけです。5-10 行の実装で終わります。

落とし穴: オンボーディング完了後、Stripe から返ってきた account.id をそのまま「登録済み」フラグにしないでください。Stripe は「オンボーディング画面は通過したが KYC の追加書類要求で pending 状態」というケースを頻繁に返します。判定は capabilities.card_payments と capabilities.transfers がともに active になっていることを webhook (account.updated) で確認します。

Step 3 — Split 手数料の設計 (Destination Charges vs Direct Charges)

マーケットプレイスの中心的判断が、「決済フローを Destination Charges にするか Direct Charges にするか」です。この選定で、日本の税務処理と Stripe 手数料の帰属が大きく変わります。

Destination Charges — プラットフォーム (Xiora) が売上主体、その一部を売り手に送金。Stripe 手数料はプラットフォーム負担、売上計上もプラットフォーム側。
Direct Charges — 売り手が売上主体、プラットフォームは「application_fee」として手数料を受け取る。Stripe 手数料は売り手負担、売上計上は売り手側。

Aiverse Studio の Phase 2 では Direct Charges + application_fee 15%を選定予定です。理由:

「AI クリエイターが売り手」を明示することで、消費者の期待値と課税処理が一致する
Xiora 側の売上は「プラットフォーム手数料」として明確に計上できる (経理と会計が簡潔)
特商法表記が売り手ごとに独立するため、Aiverse プラットフォーム全体で誇大表現の連帯責任リスクを分散できる

ただし Direct Charges は、売り手ごとの Stripe アカウントが KYC 完了していないと使えません。Step 2 の Hosted onboarding + capabilities.transfers 確認が前提です。

実運用の Tip: application_fee の割合は「初期は 10-15%、成熟後は 15-25%」に段階的に上げる設計を最初から YAML に持たせておくと、後で楽です。Xiora では services/shared/billing-core/config/fee-tiers.yaml に階段を持たせています。

Step 4 — KYC と特商法表記の連携

ここが日本で一番ハマるところです。Stripe Connect の KYC は「Stripe に対する KYC」であって、日本の特商法表記 (販売業者名 / 責任者名 / 所在地 / 電話番号 / メールアドレス) をそのまま満たすわけではありません。

Xiora では以下の連携設計にしています。

Stripe onboarding 完了時に、KYC で取得済みの「事業者名 / 所在地」を webhook (account.updated) で受信
この情報を Aiverse Studio の「販売者ページ」に自動反映 (特商法表記の自動生成)
販売者ページの URL を、決済画面に必須表示 (Stripe Checkout の「販売者情報を見る」リンク)
販売者側で「電話番号を非公開にしたい」場合は、Xiora 側の代理電話番号を表示するオプションを提供 (プラットフォーム連帯責任)

この連携がないと、「Stripe onboarding は通ったのに、特商法上の表示不備で消費者庁指導」というリスクが発生します。Aiverse Studio の Phase 2 実装では、この連携を「販売開始の前提 gate」にしています (販売者は特商法表記が反映されるまで販売開始できない)。

また、Stripe の KYC 情報を特商法表記に流用する部分は、事業内容に応じた法務レビューを受けています。汎用の実装ではなく、事業固有の設計判断が必要な部分です。

Step 5 — Payout 監視と失敗リカバリ

マーケットプレイスの運用で最も見落とされやすいのが、payout (売り手への送金) の監視です。Aiverse Studio では以下の 3 段階監視を設計しました。

Payout 予定監視 — 各売り手の payout schedule を Stripe API で日次取得、想定 payout 額と実 payout 額の乖離を検知
Payout 失敗 alert — payout.failed webhook を受信、失敗理由 (口座凍結 / 口座番号誤り / KYC 期限切れ) ごとに対応 runbook を Slack 通知
売り手側 dashboard 表示 — 売り手が自分の payout 状態を確認できる画面を Xiora 側でも用意 (Stripe Express ダッシュボードへの link に加えて自社版)

「payout は Stripe が自動でやってくれるから監視不要」と思いがちですが、実運用では 3-5% の売り手で payout 失敗が観測されます (Xiora の運用ログベース)。多くは口座名義とパスポート表記の相違、または KYC 更新書類の期限切れです。この 3-5% を放置すると、売り手から「お金がいつ入るか分からない」というクレームが発生し、マーケットプレイスの信頼を失いやすくなります。

Xiora の対応方針は「payout 失敗を検知した 24 時間以内に、原因と復旧手順を売り手に日本語で通知する」です。この文言テンプレートも Slack alert に含めています。

実装の順序 (要約)

これから Stripe Connect で AI エージェントマーケットプレイスを構築するなら、以下の順で作るのが最短です。

アカウント種別を Express / Custom / Standard から選定 (Aiverse Studio は Express)
Hosted onboarding で 5-10 行実装、account.updated webhook で capabilities 確認
Destination or Direct Charges を選定、application_fee は YAML で階段管理
KYC 情報と特商法表記を webhook 経由で連携、法務レビューを 1 回入れる
Payout の 3 段階監視 (予定 / 失敗 / 売り手 dashboard) を実装

この 5 step が終わると、AI エージェント側の売り手を安全に受け入れられるマーケットプレイス基盤が動きます。Aiverse Studio の Phase 2 (Hub) では、この基盤の上に「AI クリエイターディレクトリ + ファンクラブ課金」を載せる予定です。

次の一手

Aiverse Studio の M1a (waitlist) は現在受付中です。Phase 2 (Hub + Stripe Connect) の開発進捗を追いたい方は、ぜひ waitlist にご登録ください。

Aiverse Studio (M1a waitlist) — https://aiverse.xiora-official.com/pricing
XCloud Connect (Live、Stripe セルフサーブ稼働) — https://connect.xiora-official.com/
XCloud Flow (Live) — https://flow.xiora-official.com/
Xiora コーポレートサイト — https://xiora-official.com/

Stripe Connect の実装相談、AI マーケットプレイスの設計レビュー、KYC / 特商法連携の運用設計は info@xiora-official.com までお問い合わせください。

筆者: Xiora 代表沓澤怜士 (Kutsuzawa Reo)
連絡: info@xiora-official.com
免責: 本記事は情報提供を目的としており、Stripe の仕様変更や法規制の変更に追随する責任は読者側にあります。実装前に Stripe 公式ドキュメントおよび顧問弁護士 / 顧問税理士のレビューを受けることを推奨します。

#Stripe #StripeConnect #AI #マーケットプレイス #SaaS #個人開発 #Xiora