Stripeワークフローを使ったBacklog課題自動登録システムの構築

決済システムを運用していると、決済エラーや課金失敗の通知を適切に管理することが重要な課題となります。これまでWebhookを使ったカスタム開発が一般的でしたが、Stripeから公開プレビューとしてリリースされたワークフロー機能を使えば、ノーコードで通知システムを構築できるようになりました。

今回は、Stripe ワークフローとBacklogの「メールによる課題登録」機能を組み合わせて、決済エラーを自動的にプロジェクト管理ツールに登録する仕組みを作ってみます。

Stripe ワークフローの概要

Stripe ワークフローは、Stripeダッシュボード上でビジュアルビルダーを使ってタスクの自動化やカスタムフローを作成できる機能です。現在は公開プレビュー版として提供されており、コードを書くことなく複数ステップのプロセスを構築できます。

各ワークフローはトリガーとなるAPIイベントから始まり、条件ロジックを使った分岐処理や、複数のアクションを組み合わせた処理フローを作成できます。決済エラーが発生した時、特定の条件を満たした顧客に対してのみ処理を実行する、といった細かい制御も可能です。

特に便利なのが「Email team member」アクションで、ダッシュボードにアクセスできるユーザーに対してメール通知を送信できます。このメール機能を活用して、外部システムとの連携を実現していきます。

Backlogのメール課題登録機能

Backlogには「メールによる課題登録」という機能があります。プロジェクト設定のインテグレーション画面から設定でき、専用のメールアドレスが発行されます。

このアドレスにメールを送信すると、件名がタスクタイトル、本文がタスク内容として自動的に課題が登録される仕組みです。

この機能を使えば、Stripeワークフローからの通知メールを直接Backlogの課題として取り込むことができます。

実装手順

Backlog側の設定

まず、Backlogで課題登録用のメールアドレスを発行します。プロジェクト設定画面から「インテグレーション」→「メールによる課題登録」を選択し、設定を有効化します。

ここで発行されるメールアドレスをメモしておきます。

Stripe側でのメールアドレス登録

次に、Stripeのダッシュボードでチームメンバーとして、先ほどBacklogで発行したメールアドレスを登録します。新しいユーザーとして招待する形になり、確認メールがBacklogに課題として登録されるため、そこから確認リンクをクリックして登録を完了させます。

この際、適切な権限レベルを設定することが重要です。決済情報への過度なアクセス権限は与えない方が安全です。

ワークフローの作成

Stripeダッシュボードのワークフロー画面で新しいフローを作成します。トリガーとして適切なイベントを選択します。請求書の決済エラーであれば「Invoice payment failed」を選択するのが適切でしょう。

トリガー選択後、「Add action」から「Email team member」を選択し、先ほど登録したBacklogのメールアドレスを指定します。

データの収集と通知内容の設定

単純にエラーが発生したことを通知するだけでは実用的ではありません。「Append data」機能を使って、関連する情報を収集します。

顧客情報であれば「Customer ID」、請求書の詳細であれば「Invoice ID」、サブスクリプション関連であれば「Invoice Subscription ID」、決済試行回数なら「Invoice Attempt count」といったデータを追加できます。これらの情報がメール本文に含まれ、Backlogの課題内容として記録されます。

条件分岐の設定

すべてのエラーを通知すると課題が増えすぎる可能性があります。「Add condition」を使って、特定の条件を満たした場合のみ通知するよう設定できます。

例えば、決済リトライが2回目の時のみ通知する、リトライ回数が4回に達した時に緊急度の高い通知を送る、といった細かい制御が可能です。条件は「Attempt count is equal to 2」のような形で設定し、複数の条件をOR条件で組み合わせることもできます。

現在の制限事項と将来の改善

2025/09時点でのワークフロー機能には制限があります。最も大きな制約は、配列データの処理ができないことです。

請求内容の詳細や、サブスクリプションの契約データなど、オブジェクトの配列として格納されているデータをループ処理して通知内容に含めることができません。これは開発ロードマップに含まれているため、将来的には改善される見込みです。

現在この制約により、通知内容はテキストメールとして受信する内容と同程度の情報に留まり、構造化された詳細データの処理には限界があります。より高度な処理が必要な場合は、従来のWebhook + Lambda/Cloud Runといった開発アプローチが必要になるでしょう。

まとめ

Stripeワークフローを使った通知システムは、従来のWebhook開発と比べて圧倒的に簡単に構築できます。ノーコードでありながら条件分岐も可能で、実用的なレベルの自動化が実現できました。

ただし、現時点では配列データの処理に制限があるため、複雑なデータ処理が必要な場合は従来の開発手法との使い分けが重要です。

Stripeの機能拡張は活発に行われており、この制限も近い将来解消される可能性が高いです。まずはシンプルな通知システムから始めて、機能拡張に合わせて段階的に高度化していくアプローチが現実的でしょう。

決済システムの運用において、エラー通知の自動化は重要な要素です。開発コストを抑えながら実用的な仕組みを構築したい場合、Stripeワークフローは有力な選択肢になりそうです。