Stripe Workflows が発表されたので、セッションで詳細を聞いてきました

Stripe Sessions 2025 にて、コードを書かずに Stripe 上で処理する決済や請求・サブスクリプション・チャージバックなどのワークフローを実現する「 Stripe Workflows 」の公開プレビューが発表されました。当日はこの Workflows について学ぶセッションも用意されていましたので、参加してきました。

セッションとスピーカーについて

このセッションでは、当日朝のキーノートで発表された新機能の「Stripe Workflows」について、開発の背景や機能・ユースケースとロードマップについて紹介がありました。

セッションでは、Tanya氏（Stripe Workflowsのプロダクトマネージャー）とBen Smith氏（Stripeのスタッフデベロッパーアドボケイト）が登壇しました。両氏はAWSで約5年間ともに働いた経歴があり、サーバーレスやStep Functions、Lambdaなどのテクノロジーに携わっていたとのことです。様々な業界の顧客と接する中で、常に「インテグレーションの複雑さと難しさ」という共通課題が浮上していたという話も紹介されていました。

「７行のコード」は、環境の変化で複雑なコードベースへ

Stripeは2010年、「たった7行のコードでオンラインアプリケーションに決済機能を追加できる」というシンプルさを売りに始まりました。その後、顧客の要望に応える形で Billings や Radar, Connect, Terminal などなど、非常に幅広い製品ラインナップとなっています。これにより現在では、決済や請求、税金、ID確認、財務など、あらゆる財務インフラをStripe上で運用することが可能になっています。

しかし、一方で製品ラインナップや機能の追加によって、シンプルさが失われているという声も増えていました。決済は単に「完了」するだけでなく、「オーソリ」や「キャプチャ」そして「返金」「チャージバック」など、取引が完了してからもさまざまな出来事が発生し、決済の状態が変化します。ビジネスやワークフローと、この決済に関する状態変化を適切にマッピングするためには、たとえば決済が最初にキャプチャされた場合にのみ返金が可能になるといったルールやワークフローを設計する必要があります。このようなワークフローは決済以外にもサブスクリプションやプラットフォームなどでも発生し、それぞれに対応する API 実装や Webhook 連携を追加していくことで、コードベースが肥大化していきます。

Stripe Workflows による複雑さの解消

Stripe Workflowsは、こうした複雑さに対処するために開発された新製品です。Workflows を利用してStripe API を利用したアクションを実行することができます。Webhook イベントに対応して実行できるので、Webhook API やバッチ処理を実装せずとも、カスタムのワークフローやルールを実行できるようになります。

また、 Workflows は自動的にスケーリングするフルマネージドサービスとして提供されます。プロビジョニングやパッチ適用は不要で、コードを書く必要もありません。600以上のStripe アクションを呼び出すことができ、特定の順序で一連のアクションを確実に実行したい場合には、メンテナンスが必要なアプリケーションコードを実装することなく Stripe アカウントに適用できます。

コード vs Workflows の実装比較

セッションではシンプルなユースケースを例に、従来のコード実装と Workflows を使用した実装が比較されました。例として「成功した取引ごとに管理者にメールを送信する」というシナリオが紹介されました。

従来のコード実装では、まずAPIキーの安全な管理が必要です。環境変数またはシークレット管理系の SaaS を利用し、安全に API キーをアプリケーションコードが取得できる仕組みを作らなければなりません。また、npm や composer などで配布されている 3rd party のライブラリを使用したり、Next.js / AWS CDK などのフレームワークをメンテナンスする手間もかかります。Webhook を利用する場合は、第三者からの攻撃リクエストからエンドポイントを保護する必要もあります。さらにエラー処理やロギング、オブザーバビリティについても考慮すべき点です。特にセッションでは、 Webhook の保護処理についてと、決済というクリティカルな領域における「リトライ処理のハンドリングや冪等性の扱い」が開発時の重要な要件になり、同時にコードの複雑化を招く要素でもあると紹介されていました。

Workflows を利用すると、これらのコードの複雑性を解消することができます。Webhook API を実装する代わりに、視覚的なビルダーを使ってワークフローを設定します。そのため、アプリケーションコードだけでなく、コードを実行するサーバーも不要となり、ダッシュボード操作ですぐに実行できます。また、エラーが発生した時リトライだけでなく、冪等性の担保による二重処理の予防措置まで組み込みされているとのことでした。

Workflows がもつ3つの機能と設計パターン

Workflows には現在３つの機能が用意されています。

1つ目は ワークフローを実行するためのトリガー設定です。イベントペイロードの内容に基づいて、より細かくワークフローの実行を制御できます。たとえば、200ドル以上の支払いに対してのみワークフローを実行するといった条件設定が可能です。

2つ目の機能は、ワークフロー内で実行するアクションを設定する機能です。Stripe API を利用した取得・作成・変更・削除などのオペレーションをサポートしており、またメールでの社内通知に利用できるアクションも提供されています。アクションでは、ワークフロー内の前のステップからのデータを使用できます。顧客や決済などのオブジェクト情報をワークフロー全体で渡せるので、データの連携がスムーズになります。

最後の機能は、条件分岐です。ワークフローで実行するアクションを分岐する条件を作成できます。チップが含まれる支払いの場合に顧客をVIPとしてマークするなど、ビジネスロジックの実装が柔軟に行えます。

これらの機能を組み合わせて、さまざまなパターンのワークフローを構築することができます。

ワークフローの可観測性機能

Workflowsにはデバッグのためのオブザーバビリティ機能が組み込まれています。ワークフローの詳細ページでは、すべてのワークフロー実行の日付や時間、ステータスが一覧で確認できます。失敗理由についても表示しますので、失敗した場合の概要を一目で把握することが可能です。「subscription id 123は存在しない」といった具体的なエラー内容が一目で確認できるように作られているとのことでした。

ステップごとに input / output のデータを調査することもできます。そのため、「どんな API リクエストを実行したか」や「どんな結果が返ってきたか」などをワークフローに沿った形で調べることができます。また、手動でのリトライ機能も、冪等性を担保した状態で提供されているとのことですので、修正後に同じイベントデータを使って再試行できます。

また、 API リクエスト内容やリソース内容を詳細に調査できる「 Stripe Workbench 」とも連携しているとのことでした。そのため、Subscription リソースに紐づく Invoice や Payment Methods などのデータを深掘りすることも、ダッシュボード上で実現できるそうです。

この他、Workflowsには無限ループを防止する機能も備わってるとのことでした。直接再帰（ワークフローが自身をトリガーする無限ループ）を防止するだけでなく、間接再帰（ワークフローが他のワークフローをトリガーする連鎖）も制限されます。これにより、APIリミットの意図しない消費を防ぐことができます。最大5回までのワークフロー連鎖は許可されますが、自己トリガーは最大1回までという制限があるそうです。

実装例：チップ含む支払いの自動VIP設定

セッション中のデモでは、条件分岐を使った具体的な実装例が紹介されました。

まず、イベントのフィルタリングとして、支払い金額が$200以上の「payment_intent.succeeded」イベントのみをトリガーに設定します。次に条件分岐を行い、チップ（tip amount）が含まれているかどうかを判定します。チップがあれば（tip amountが空でない）、その顧客を「tipper」と判断するわけです。顧客データの更新では、チップを支払った顧客を「VIP」としてマークします。支払いに関連する顧客IDを動的に参照し、そのカスタマーオブジェクトにメタデータとして「tier: VIP」を追加する仕組みになっています。

結果として、$200以上の支払いにチップを含む顧客が自動的にVIPとしてマークされます。チーム内の誰もがその顧客情報を見たときに、VIPステータスを確認できるようになり、顧客体験の向上につながるでしょう。この例は、動的フィールド、条件分岐、メタデータ自動化というWorkflowsの主要パターンを組み合わせたものであるともいえそうです。

Workflows のユースケースについて

このほかにも不正対策や大口契約などのワークフローで Workflows を利用するユースケースが紹介されていました。

1. 不正使用の早期警告 への対応

Stripe では、クレジットカード会社がチャージバックの申立てリスクが高いと思われる決済について早期アラートを出す仕組みが用意されています。これを「不正使用の早期警告 ( Early Fraud Warning | EFW)」と呼びます。この機能をトリガーとしたワークフローを実装することで、異議申し立て手数料やチャージバックが発生する前に予防措置をとることが可能です。セッションでは、チャージバックが発生した時の手数料よりも決済金額が少額であれば、チャージバックが発生する前に返金してしまうフローが提案されていました。これによって不正利用による被害額をすこしでも削減できるとのことです。また、条件分岐とメール通知アクションを組み合わせることで、高額決済など迅速な異議申し立てや顧客への連絡が必要な場合には、チームに通知することもできるということです。

2. カスタム料金でのサブスクリプション申込フロー

大口契約など、顧客や案件ごとに料金を提示するケースでは、メールで請求書を送信する設定のサブスクリプションを自動生成するワークフローが作れます。このケースでは料金（ Price ）リソースの作成をトリガーにし、顧客やサブスクリプションの作成までを一気通貫するフローが紹介されていました。

ロードマップ

セッションでは最後に大まかな製品ロードマップも紹介されていました。スライドをみると、年内にはリストデータを処理するためのループステップや、 3rd partyアクションを実行する機能が登場しそうです。

2026年以降になる見込みですが、バージョニングやスケジュール実行・ Human in the loop（人間による承認ステップ）などまでリリースされると、Stripe 内部で完結するワークフローはほぼ Workflows に集約する流れになってくるかもしれません。

また、3rd partyアクションによって、どんなアプリとの連携が可能になるのかも楽しみですね。

まとめ

Stripe Workflowsはパブリックプレビューとして発表され、現在Stripeアカウント内で600以上のAPIアクションを自動化・調整することができます。イベントに応じて自動的にスケーリングする特性を持ち、Stripe内でほぼ無限のカスタマイズが可能になりました。

開発者にとっての最大のメリットは、基盤となる複雑な実装について心配する必要がなくなることでしょう。ビジネスロジックの構築とStripeのビジネスニーズへのカスタマイズに集中できるため、生産性向上が期待できます。

まだ公開プレビュー状態のため、リストデータを扱うことが難しいなど物足りなさを感じる部分はありそうです。しかしキーノートでの発表に加えて専用セッションまで用意されていることから、今後のアップデートや可能性には大きく期待できそうです。

ぜひみなさんも Workflows を試してみて、社内業務に使える場面がないかなどを話し合ってみてください。