Zapier、Make、n8nでOpen Badgesを自動化する（ノーコードレシピ集）

トレーニングプログラムや有料コース、階層分けされたメールリストを運用しているなら、誰かが完了・購入・条件達成した瞬間は、たいてい何らかの形ですでに記録されています——フォームの回答、Stripeの課金、Mailchimpのタグなどです。本来ならバッジはそのイベントに応じて自動的に発行されるべきですが、実際にはそうなっていないことがほとんどです。「クレデンシャルを発行する」というアクションはほとんどのツールにネイティブで用意されておらず、単発の自動化のためにカスタムのWebhook受信サーバーを構築するのはやりすぎだからです。

まさにこれこそZapier、Make、n8nの出番です。この3つはすべてBadges Ninja APIを直接呼び出せます——プラグインもミドルウェアサーバーもコードのデプロイも不要です。以下は今日すぐにコピーして使える3つの実践的なレシピと、バッジが静かに発行失敗しないようにするために押さえておくべきAPIキーの扱い方、エラー時のリトライの挙動です。

何と何をつなぐのか

すべてのレシピは同じ形をしています。トリガー → （任意で）受信者の照合 → /awardsへのHTTP POSTです。/awardsエンドポイントは、実際に受信者にバッジを発行する場所です。既存のbadgeIdを指定すると、専用の検証URL、QRコード、PDF証明書を持つ、一意で検証可能な発行レコードが作成されます。まだバッジを作成していない場合は、APIクイックスタートを参照してください。これらの自動化を実行する前に、そのIDが必要になります。

3つのプラットフォームすべてで認証方法は同じです。ダッシュボードから発行したキーを載せたX-Api-Keyヘッダーです。自動化プラットフォームは任意のREST APIに対するOAuthフローの扱いがあまり得意ではないため、ここではAPIキーがちょうどよい選択です——長期間有効で、アカウントに紐づき、Zapが誤動作した場合もワンクリックで無効化できます。

まずAPIキーを作成する

ダッシュボードから設定 → APIキーを開き、キーを作成をクリックして、用途がわかる名前を付けます——key1ではなくzapier-course-completionsのように。この命名は見た目以上に重要です。半年後にある自動化が誤作動したとき、たまたま同じキーを共有している他の3つの連携を壊すことなく、そのキーだけを無効化したいはずです。

キーは作成直後に一度だけ、全文が表示されます。作成後すぐに、自動化プラットフォームの安全な認証情報ストアにコピーしてください——Zapierの「Connection」、Makeの「Connection」、あるいはn8nのCredentialです。Zap／シナリオ／ワークフロー内のプレーンテキストのフィールドには絶対に貼り付けないでください。

レシピ1: Typeform → Badges Ninja（コース修了フォーム）

ユースケース: あるコホートがコースを修了し、短い「完了しました」フォームに回答する（あるいは、自習型トラックの最終ステップとしてフォームを送信する）場合です。

Zapierでは:

1. トリガー: Typeform — New Entry（修了フォームに限定）
2. アクション: Webhooks by Zapier — POST
3. URL: https://api.badges.ninja/awards
4. ヘッダー: X-Api-Key: bws_<your key>、Content-Type: application/json
5. データ（Typeformのフィールドからマッピング）:

{
  "badgeId": "bdg_9f2a1c",
  "recipient": {
    "name": "{{typeform_name}}",
    "email": "{{typeform_email}}"
  },
  "issuedOn": "2026-08-27"
}

これだけでZapは完成です。フォームが実際の修了時にしか発火しないなら、Filterステップは不要です。ただし一般的な問い合わせフォームを兼ねている場合は、Webhookが発火する前にFilter by Zapierステップを追加し、隠しフィールドや回答値をチェックして、スパムやテスト送信からバッジが発行されないようにしてください。

レシピ2: Stripe → Badges Ninja（購入＝クレデンシャル）

ユースケース: 有料の認定試験、プレミアムコースのプラン、あるいはバッジ自体が購入対象の一部になっている会員プランです。

Zapierでは:

1. トリガー: Stripe — New Charge（サブスクリプションの場合はNew Invoice Payment Succeeded）
2. フィルター: 課金額が、クレデンシャル対象商品の正確な価格と一致することを確認します——1つのWebhookで複数の商品を扱っているStripeアカウントの場合、これは重要です。
3. アクション: Webhooks by Zapier — POSTをhttps://api.badges.ninja/awardsへ、ヘッダーは上記と同じです。
4. データ: charge.billing_details.emailとcharge.billing_details.nameをrecipient.email / recipient.nameにマッピングします。

発行を支払いイベントに紐づけることの利点は、それが自然と冪等に近い挙動になることです。Stripeの課金IDは一意なので、Webhookの再送によってZapが再発火することを心配するなら、/awardsを呼び出す前にそのcharge IDをすでに処理済みかどうかをチェックするStorage by Zapierステップを追加してください。

レシピ3: Mailchimpのタグ → Badges Ninja

ユースケース: 購読者があるマイルストーンに達したとき——ウェビナーへの参加、ドリップメール配信の完了、3人の紹介など——手動で（あるいは別の自動化経由で）タグを付け、自分でAPIを触ることなく、そのタグからバッジを発行したい場合です。

Zapierでは:

1. トリガー: Mailchimp — New Tag Added to Subscriber、特定のタグ（例: webinar-attended）で絞り込みます。
2. アクション: Webhooks by Zapier — POSTをhttps://api.badges.ninja/awardsへ。
3. データ: subscriber.email_addressとsubscriber.merge_fields.FNAME + LNAMEを受信者フィールドにマッピングします。

このパターンは、セールスのSPIFF、コミュニティのマイルストーン、イベント参加など、表彰プログラムでよく使われます。すでにチームの誰かが連絡先にタグを付ける習慣を持っている場合、その習慣からそのままバッジが自動的に生まれる形になります。

エラーとリトライの処理

自動化プラットフォームはバッジデータに対してトランザクション的な保証を提供しないため、本物のインテグレーションに求めるのと同じ規律を組み込んでおく必要があります。

• レスポンスコードを確認する。 200は発行成功を意味し、4xxは通常badgeIdが不正か、メールアドレスの形式が誤っていることを示します——これはZapの設定ミスであり、無条件にリトライすべきものではありません。5xxは安全にリトライできます。
• Zapier: 失敗したZapの実行は、リクエストとレスポンスの全文とともにZap Historyに記録されます。一時的な失敗にはAuto-Replayを有効にしつつ、繰り返し失敗する場合に備えてメールやSlackへのアラートも設定し、静かに壊れたZapのせいで3か月分のバッジが未発行のまま放置されることを防ぎましょう。
• Make: シナリオにはネイティブのError Handlerルートが用意されています。HTTPモジュールにResumeまたはRollbackのディレクティブを付け、継続的な失敗は単に破棄するのではなく通知モジュールへ流すようにします。
• n8n: セルフホストでもクラウドでもより細かい制御が可能なので、HTTP RequestノードをError Triggerワークフローでラップし、失敗したペイロードを軽量なフォールバックストア（AirtableやGoogle Sheetsなど）に書き込んでおいて後から手動でリプレイできるようにすることを検討してください。

3つのプラットフォームいずれにおいても、「緑色で実行が終わったから成功した」と思い込む罠には注意してください。URLの誤りやヘッダーの欠落など、誤って設定されたWebhookステップからの200らしいレスポンスでも、Badges Ninja側では失敗していることがあります。新しい自動化を導入して最初の1か月は、週に一度はダッシュボードの発行一覧を目視でチェックすることをおすすめします。

Make.comでの対応

Makeのビジュアルなシナリオビルダーは、上記のZapierのステップとほぼそのまま対応します。

1. トリガーモジュール — Typeform / Stripe / Mailchimpの監視モジュールで、Zapierのトリガーと同じです。
2. HTTP → Make a Requestモジュール — メソッドはPOST、URLはhttps://api.badges.ninja/awards、Headersテーブルでヘッダーを設定（X-Api-Key、Content-Type: application/json）、ボディはトリガーからマッピングした変数を含む生のJSONとします。
3. Stripeの金額チェックやTypeformの「実際の完了」ガードのために、モジュール間に任意でFilterを挟みます。

Makeの強みはここでは可視性です。シナリオエディタは有効化する前に各ステップの実際のJSONペイロードを表示してくれるため、フィールドマッピングのミスをデバッグする速度が、より線形的なステップごとのテストビューを持つZapierより速くなります。

n8nでの対応

セルフホストで運用したい場合や、すでに自分のスタックの他の部分をn8nで自動化している場合は、n8nが最適です。

1. トリガーノード — Typeform Trigger / Stripe Trigger / Mailchimp Trigger（いずれも組み込みノードです）。
2. HTTP Requestノード — メソッドはPOST、URLはhttps://api.badges.ninja/awards、認証はHeader Authに設定し、X-Api-Keyはノードにハードコードせずn8nのCredentialとして保存します。JSONボディはトリガーノードの出力を参照する式で組み立てます。
3. IFノード（任意）— 上記と同じ完了／金額のガード条件を、HTTP Requestノードの前に配置します。

n8nのCredentialは暗号化されており複数のワークフローで再利用できるため、Badges Ninjaの自動化を複数計画している場合はこちらの方がすっきりします。認証情報を一度設定すれば、バッジ発行が必要なすべてのワークフローで再利用できます。

ネイティブアプリではなく汎用Webhookステップを使う理由

Zapier、Make、n8nにはいずれもアプリマーケットプレイスがあり、つい汎用のHTTP／Webhookモジュールより先に「Badges Ninja」アプリを検索したくなります。しかし、その検索は不要です。これほど小さなREST API（発行者を作る、バッジを作る、発行レコードを作る、それだけ）に対しては、汎用のWebhookステップを使えば10分でライブに乗せられ、サードパーティのアプリメンテナーがAPIの変更に追随してくれるかどうかに依存する必要もありません。専用アプリは不要な抽象化のレイヤーを1つ加えるだけです。結局、同じbadgeId、recipient.email、recipient.nameのフィールドを、JSONボディの代わりにフォームで入力することになるだけです。APIリファレンスは5分もあれば読める短さで、それを読んでしまえば、生のHTTPアプローチのほうがむしろ壊れにくいことがわかります。Badges NinjaのAPI変更とあなたの自動化が動き続けることの間に、アプリストアの審査サイクルという障害物が存在しないからです。

本番に切り替える前にテストする

上記のどのプラットフォームでも、実際のトリガーイベントを待たずに1回だけテスト実行する方法が用意されています。

• Zapier — トリガーステップで「Test」を使ってサンプルレコードを取得し、Webhookアクションで「Test」を使って実際のリクエストをちょうど1回発火させます。Zapを有効化する前に、ダッシュボードで発行レコードが表示されることを確認してください。
• Make — サンプルバンドルを使ってシナリオを手動で一度実行し（「Run once」ボタン）、HTTPモジュールの出力バブルで実際のレスポンス本文を確認します。
• n8n — HTTP Requestノードでテスト用の入力データを使って「Execute Node」を実行すると、エディタ内でリクエストとレスポンスをその場で確認できます。

最初のテスト実行で確認する価値があるのは2点です。ハードコードしたbadgeIdが本当に想定しているバッジのものかどうか（重複させたZapに古いIDが残っているのはよくあるミスです）、そして受信者のメールアドレスフィールドが実際のアドレスを取得できているか、マッピングのタイプミスによって{{email}}のようなプレースホルダーが未解決のまま残っていないかです。どちらのミスも、自動化プラットフォームの「成功」表示には現れません——HTTP呼び出しはどちらにせよ200を返すからです——ため、確実な確認方法はダッシュボードで発行レコードを開き、受信者が想定通りの人物であることを確認することだけです。

バッジの重複発行を防ぐ

上記のいずれのトリガー元も、実運用下ではその同じイベントに対して複数回発火する可能性があります——Stripeはタイムアウト時にWebhookをリトライしますし、Typeformは接続が遅いと二重送信することがあり、Mailchimpの自動化はタグが削除されて再度付与されると再トリガーされることがあります。バッジ発行が冪等でない場合、それは受信者が同じクレデンシャルを2回受け取るという結果につながり、見た目が雑になり、サポートへの問い合わせも発生します。

もっとも確実なガードは、作成前に照合ステップを入れることです。/awardsへのPOSTの前にSearchアクション（ZapierならGETリクエストによる「Find Award」、Make/n8nなら同等のHTTP GET）を追加し、自分自身の発行記録を照合します。APIに問い合わせたくない場合は、同じZapが発行成功直後に書き込む軽量なGoogleスプレッドシートやAirtableのログでも十分機能します。その受信者とバッジの組み合わせのレコードがすでに存在する場合は、再発行せずに何もしない分岐へ進みます。これはわずか5分で追加できる仕組みですが、放置しても信頼できる自動化と、常に付きっきりで見守る必要がある自動化との違いを生み出します。

ノーコードでは足りないとき

これらのレシピは単一イベントのトリガーには十分対応できます。しかし、1つのCSVエクスポートから数百件のバッジを発行するようになったら——コホート全体の卒業、カンファレンスの参加者リスト、大量のCE単位更新など——自動化プラットフォームは避けてバッジの一括アップロードを直接使ってください。バッチの途中で一時停止・再開でき、ブラウザのタブを閉じても処理が続くため、ノーコードのWebhookループでは大量処理時にうまく扱えない部分をカバーできます。

---

最初の検証可能なクレデンシャルを発行する準備はできましたか? badges.ninjaで無料で始める——ビジュアルデザイナー、公開検証ページ、PDF証明書、Open Badge v2.0出力。クレジットカードは不要です。