Skip to main content
ベータ版。 Automations API はベータ版であり、現在フィードバックを積極的に収集しています。改善を重ねる中で、エンドポイント、ペイロード、および制限が変更される可能性があります。改善の優先順位付けのため、フィードバックとバグレポートをサポートまでお送りください。
Automations エンドポイントを使用すると、Instagram で発生したエンゲージメントと Facebook ページへの DM に自動的に反応するルールを定義できます。各オートメーションは、1 つ以上の triggers(ルールを発火させるイベント)と 1 つ以上の actions(発火時に発生する処理)を組み合わせます。1 つのルールで複数のトリガーを監視し、複数のアクションをディスパッチできます — 同じエンゲージメントから分析パイプラインへ Webhook を発火 AND DM を送信することも可能です。 このエンジンは、ユーザーがあなたに向けて行ったエンゲージメント(コメント、ストーリー返信、DM、リアクション)にのみ反応します — フォローをトリガーとする DM 送信、見知らぬ相手への初回 DM、一斉アウトバウンドは決して行いません — また、Ayrshare のアカウントごとのレート制限、受信者ごとの重複排除、および冪等な Webhook 取り込みを継承します。
sent は Meta がメッセージを受理したことを意味し、受信者が受信したことを意味するものではありません。 Instagram では、配信は最終的に受信者の Message requests 設定によって決まります。受信者が全員からのメッセージリクエストを許可していない場合、Meta は成功レスポンスを返しつつメッセージを黙って破棄し、これはあらゆる API レイヤーで不可視です。配信されたコメントトリガー DM でさえ、受信者が承認しなければならないメッセージリクエストとして届きます(両アカウント間に既に会話が存在する場合を除く)。詳しい説明は Automation DM Sent but Not Delivered を参照してください。

仕組み

1

オートメーションを作成する

使用したいトリガーとアクションを指定して POST /automations を実行します。オートメーションは即座に有効化されます。
2

エンドユーザーがエンゲージメントを行う

誰かがあなたの投稿にコメントする、ストーリーに返信する、DM を送信する、または DM にリアクションします。Meta が Webhook を Ayrshare に配信します。
3

Ayrshare がマッチしてディスパッチする

Instagram のスパム対策ヒューリスティクスの範囲内に収まるよう、エンゲージメントに 20〜60 秒のジッターが適用されます。その後エンジンはイベントにマッチするすべてのルールを検索し、アクションごとの重複排除と 1 日あたりの DM 上限をチェックし、各アクションを実行します。
4

発火した内容を確認する

GET /automations/:id/activity で監査ログ — すべてのディスパッチ試行、アクションごとの結果、および発生したエラー — が返されます。

Triggers

1 つのオートメーションに最大 50 個の triggers を紐付けできます。各トリガーは type フィールドを判別子とする union で、タイプ固有のフィールドは同じレベルに配置されます。各トリガーが利用できる場所は プラットフォーム 列に示されています。Facebook で必要な条件については Facebook ページ を参照してください。 キーワードマッチングは大文字小文字を区別しない、単語単位でのマッチです。イベントは、設定されたキーワードのいずれか 1 つを含んでいれば、キーワードフィルタ付きトリガーを満たします。

"all" によるエバーグリーンルール

postId(または storyId)にリテラルの小文字文字列 "all" を設定すると、特定のコンテンツ 1 件ではなく、連携されたアカウント上のすべての投稿、リール、またはストーリーで発火します。新しいコンテンツが公開されても、投稿ごとの API 呼び出しなしで動作し続けるべきルールには、これが最適です:
値は正確に "all" でなければなりません。"ALL" や " all" のような変形は、決してマッチしない投稿 ID として保存されるのではなく、バリデーションエラーとして拒否されます。 "all" が連携されたアカウントの範囲を超えて広がることはありません — あるプロファイル上のルールが別のプロファイルのコンテンツで発火することはできません。1 日あたりの DM 上限とエンゲージメントを起点とする送信ルールは、単一投稿のルールとまったく同じように適用されます。
重複排除はオートメーションと受信者ごとにカウントされ、投稿ごとではありません。"all" ルールでは、重複排除ウィンドウ(既定 7 日間)内に 2 つの異なる投稿にキーワードをコメントしたユーザーが DM を受け取るのは 1 回だけで、2 つ目のアクティビティは deduplicated として記録されます。より小さい dedupWindowMinutes はそのウィンドウを短くするだけで、重複排除を投稿ごとにするものではありません。0 に設定すると重複排除が無効になるため、同じ投稿への繰り返しコメントも含め、マッチするすべてのコメントで DM が送信されます。
ストーリートリガーでは、storyId を省略すると "all" と同じ動作になります。"all" を推奨します — 意図を明示的に示すことができ、省略は将来のリリースで廃止される予定です。事前の告知は Upcoming API Changes で行われます。

Facebook ページ

platform を facebook に設定すると、プロファイルに連携された Facebook ページでオートメーションを実行できます。DM はページから Messenger 経由で送信されます。
  • トリガー: dm_keyword と dm_reaction。コメントトリガーとストーリートリガーは現在 Instagram のみに対応しており、これらを使用する Facebook のオートメーションはバリデーションエラーとして拒否されます。
  • Messaging: Messages API で Facebook の DM を送信する場合と同様に、プロファイルで Facebook 向けに Messaging が有効化されている必要があります。
  • 受信者: {{recipient_id}} はユーザーのページスコープ ID(PSID)です。Messenger の Webhook にはユーザー名が含まれないため、{{recipient_username}} は空になります。

Actions

1 つのオートメーションに最大 50 個の actions を紐付けできます。これらは順次実行され、各結果はアクティビティ行に記録されます。

アクションごとの重複排除ウィンドウ

すべての action は、その action のみに対して 既定の 7 日間 の受信者ごと重複排除ウィンドウを上書きする、オプションのトップレベル dedupWindowMinutes フィールドをタイプに関係なく受け入れます。
  • そのアクションで重複排除を完全に無効化するには 0 を設定します(受信者がすべてのイベントを期待する fire_webhook / send_email で一般的)。
  • 上限は 525600(1 年)です。
Action with a 24h dedup override

動的なメッセージ内容

既定では、send_dm はルールを発火させたすべての人に同じ message を送信します。人によって変わるのは {{recipient_username}} などのプレースホルダーだけです。アクションに messageUrl を設定すると、代わりにお客様自身のサーバーが各人向けの DM を作成します: ルールがマッチするたびに、お客様のエンドポイントに送信内容を問い合わせ、その回答を DM として送信します。 例。 投稿に「LINK」とコメントした人に返信するルールがあり、messageUrl がお客様のサーバーを指しているとします。Ava が「LINK please!」とコメントすると:
  1. 詳細をお客様の messageUrl に POST します: コメントした人("recipientUsername": "ava")、コメント内容、対象の投稿です。
  2. お客様のサーバーが Ava 向けの返信(たとえば彼女専用に作成したトラッキングリンク付きのもの)を作成し、{ "message": "Hi ava, here's your link: https://example.com/r/12345" } と応答します。
  3. そのテキストを、お客様が作成したとおりに DM として Ava に送信します。
お客様のサーバーが timeoutMs 以内に応答しない、エラーを返す、または使用できない内容を返した場合は、代わりにアクションの通常の message を Ava に送信するため、彼女は引き続き返信を受け取れます。 send_dm アクションには次のように追加します:
send_dm with messageUrl
messageUrl はテキストを問い合わせる先です。message は引き続き必須で、フォールバックとして使われます: お客様のサーバーに送信されることはなく、サーバーが時間内に応答しない、エラーを返す、または使用できない内容を返した場合(下記の警告を参照)に、代わりにこれを DM として送信します。timeoutMs は任意です(既定 3000、最大 5000)。 エンドポイントに送信される内容。 次の JSON ボディを含む POST です:
Callback request body
Webhook シークレットを登録している場合、ボディは automations Webhook と同じシークレットを使い、同じ方法で署名されます: X-Authorization-Content-SHA256 は生のボディの HMAC-SHA256 で、X-Authorization-Timestamp にはボディの timeStamp が入ります。Webhook 用に既に使用している検証コードがそのまま使えます。シークレットが登録されているのにその時点で読み取れない場合、署名なしでコールバックを送信することはなく、代わりに message テンプレートを送信します。 指定できる URL。 messageUrl は公開 HTTPS アドレスでなければなりません。プライベート、ループバック、リンクローカル、またはクラウドメタデータのアドレスに解決される URL は拒否され、リダイレクトは追跡されません — 3xx 応答は失敗として扱われます。いずれの場合も、代わりにテンプレートが送信されます。 エンドポイントが返す内容。 最大 16 KB の JSON ボディで 200 を返し、1〜1000 文字の message 文字列を含めてください:
お客様のテキストはそのまま送信されます。{{placeholder}} の置換は適用されないため、生成したテキストに含まれるリテラルの {{ は、そのまま受信者に届きます。
message は引き続き必須であり、飾りではありません。 エンドポイントがタイムアウトした、non-2xx を返した、使用できないボディを返した、または繰り返し失敗した後に一時的にサーキットブレーカーが作動している場合は、代わりにレンダリングされた message テンプレートを送信します。この送信も失敗する可能性があります。たとえば、テンプレートが空にレンダリングされた場合(下記参照)や、Instagram が拒否した場合です。コールバックを再試行することはありません — 再試行すると受信者に 2 通のメッセージが送信されるおそれがあるためです。
timeoutMs の既定値は 3000 です。最大値は 5000 で、それより大きい値はオートメーションの作成時または更新時にバリデーションエラーとして拒否されます。この値は、レスポンスボディの読み取りを含むやり取り全体に適用されます。これを考慮に入れてください: DM はエンドポイントの応答後に送信されるため、遅いエンドポイントはメッセージを遅らせます。 発火がどの経路をたどったかは GET /automations/:id/activity で確認できます。actionResults[] 内の send_dm エントリには、DM のテキストが確定した時点で messageSource が含まれます(その後に送信が失敗した場合も含む)。それより前にアクションが停止した場合(たとえば自身のアカウントへの skipped DM や deduplicated アクション)には含まれません: messageSource は DM がどのテキストから作成されたかを示すものであり、配信されたかどうかを示すものではありません。それについてはエントリの status を確認してください。 フォールバック自体はアクションを失敗させません: テンプレートの DM が配信されると、エントリは sent となり、コールバックが使用されなかった理由が errorDetails に記載されます。その後テンプレートの DM も失敗した場合、エントリは failed となり、errorDetails には送信エラーに続いてコールバックの理由が記載されます。これに注意してください: そうしないと、毎回の発火で失敗しているコールバックが、正常に動作しているものとまったく同じように見えてしまいます。 message はそれ単体で送信可能な状態にしておいてください。受信者に対して空にレンダリングされ(たとえばユーザー名を持たない DM トリガーで {{recipient_username}} だけの場合)、かつコールバックのテキストが使用されない場合、DM は送信されず、アクションは failed となり、理由が errorDetails に記載されます。

Webhook イベント

POST /hook/webhook で登録した automations Webhook アクションには 2 つのイベントが配信されます。どちらも type フィールドを持ちます — 他のフィールドを読む前に、まずこのフィールドで分岐してください。
automation.completed は既定で無効です。オートメーションで有効にするには、その fire_webhook アクションに "sendCompletedEvent": true を設定します。それ以外の場合は無効のままなので、1 回の発火につき 1 つのペイロードを前提に構築された受信側は、引き続き正確に 1 つだけ受け取ります。automation.triggered はすべてのマッチの記録ではありません: fire_webhook 自体が実行されたときにのみ送信されるため、rate_limited または deduplicated で終わったマッチは automation.completed のみを生成します。ディスパッチの実行前に無効化または削除されたオートメーションについては、どちらのイベントも送信されません。

automation.triggered

activityId は GET /automations/:id/activity が返す行そのものなので、recipientId + triggerId + keyword によるマッチング — 複数の人が同じキーワードを同時にコメントすると曖昧になります — ではなく、両者を正確に突き合わせることができます。actionId はイベントを送信した fire_webhook アクションで、actionResults[].actionId と一致します。これにより、同じルール上の 2 つの fire_webhook アクションを区別できます。 トリガーが設定しないフィールドは省略されるのではなく null になるため、形式は安定しています。recipientUsername は dm_keyword、dm_reaction、story_reply では null になります。Meta のペイロードにユーザー名が含まれないためです。commentId は comment_keyword と story_comment の場合にのみ、postId は comment_keyword の場合にのみ、storyId はストーリートリガーの場合にのみ設定されます。story_reply には keyword がありません。dm_keyword の場合、commentText は DM のテキストです。dm_reaction の場合、commentText と keyword はどちらもリアクションの絵文字です。

automation.completed

オートメーションがその fire_webhook アクションでオプトインした場合にのみ送信されます:
fire_webhook action with the outcome event on
status と各 actionResults[].status は、アクティビティログと同じ値 — sent、failed、rate_limited、deduplicated、skipped、auth_error — を使用するため、通常のケースではポーリングせずにディスパッチがどのように終わったかを知ることができます。ただし、このイベントの配信はベストエフォートです: 結果の記録とイベントのキューイングの間にプロセスが停止した場合、イベントは送信されません。アクティビティログが正となる記録なので、すべての結果が必要な場合は、結果を報告していない activityId について GET /automations/:id/activity と突合してください。send_dm の結果には、アクティビティログと同様に messageSource(template、callback、または fallback)も含まれるため、フォールバックし続けている messageUrl をポーリングせずに見つけることができます。結果は位置ではなく actionId で設定済みのアクションと照合してください — 同じタイプの 2 つのアクションはそれでしか区別できません。actionResults が空になるケースは 3 つあり、理由がある場合はトップレベルの errorDetails に記載されます: rate_limited(1 日あたりの上限に達した)、deduplicated(すべてのアクションが重複排除ウィンドウ内だった)、およびディスパッチが最大回数まで再試行されても完了しなかった後の failed です。最後のケースでは一部のアクションが既に実行されている可能性があるため、DM が送信済みで、automation.triggered も既に送信されている場合があります。 Webhook の配信は at-least-once であるため、同じイベントがまれに 2 回届くことがあり、再試行されたディスパッチは新しい hookId で automation.triggered を再送することがあります。hookId で重複排除しないでください。一方の処理が他方を抑止しないよう、イベントタイプごとに個別にキーを設定してください: automation.completed は activityId(各アクティビティには 1 つの結果があります)で、automation.triggered は activityId と actionId の組み合わせ(fire_webhook アクションごとに 1 つ)でキーを設定します。2 つのイベントは独立して配信されるため、まれに automation.completed が automation.triggered より先に届くことがあります。

Webhook が登録されていない場合

fire_webhook は、プロファイルに登録された automations アクションに POST し、なければ Primary Profile にフォールバックします。messages など別のアクションへのフォールバックはありません。どちらの登録も存在しない場合でも、automation.triggered は黙って破棄されるのではなく、アクションはアクティビティ行に failed として記録され、理由は actionResults[].errorDetails に記載されます。(automation.completed も送信先がないため、記録されません。)ディスパッチの全体的な status は通常の優先順位に従います: いずれかのアクションが認証エラーに該当すれば auth_error、次にいずれかのアクションが受理されていれば sent、それ以外は failed となります。したがって、Webhook の欠如がオートメーションの失敗統計にカウントされるのは、ルール上の他のアクションが何も送信しなかった場合のみです。別のアクションが送信した場合(かつ認証エラーに該当するものがない場合)、ディスパッチは sent で終了し、失敗した Webhook は actionResults[] にのみ表示されます。 fire_webhook の結果が sent であることは、イベントがあなたの URL への配信のためにキューに入れられたことを意味し、エンドポイントがそれを受理したことを意味するものではありません。配信はその後、独自のスケジュールで再試行されます。

テンプレート変数

send_dm.message、send_email.subject、および send_email.message は {{placeholder}} の置換をサポートします。不明なプレースホルダーは作成/更新時に拒否されます(473 バリデーションエラーとして)。これにより、タイプミスがそのまま {{foo}} としてお客様向けメッセージに紛れ込むことを防ぎます。
sender_email / recipient_email はありません。 これらは意図的に公開されていません — 請求用メールアドレスが見知らぬ相手への DM に含まれる正当な理由はなく、Meta も IG の Webhook で受信者のメールアドレスを提供しません。これらのプレースホルダーを避けることで、意図しない情報開示を防ぎます。
テンプレート例:

レート制限と上限

アクティブなオートメーションの上限は、親アカウント単位ではなく、User Profile ごとにカウントされます。アカウント配下の各プロファイルはそれぞれ Launch/Business は 10、Enterprise は 50 の枠を持つため、多数のプロファイルを持つアカウントでは各プロファイルでその数のオートメーションを実行できます。この上限はアクティブなオートメーションをカウントし、POST(作成)および PUT による再有効化(active: false → true)の双方で適用され、それぞれエラーコード 470 を返します。プロファイルごとの上限引き上げが必要ですか? サポートまでお問い合わせいただくことで、アカウントに対して上限を引き上げることができます。 1 日あたりの DM 上限 は Ayrshare の親アカウントごとに適用され、すべてのプロファイル間で共有されますが、プロファイルごとのサブ上限があるため、忙しい 1 プロファイルがアカウント全体のクォータを使い切ることはありません。DM 上限に達すると、アクティビティ行に rate_limited ステータスが記録され、DM は送信されません。 メッセージングの会話上限 も適用されます。send_dm にはプロファイルで Messaging アドオンが必要であり、送信される各 DM は、あなた自身が送信する DM と同様に、そのプロファイルの月間会話上限にカウントされます。上限に達すると、新しい受信者への send_dm は送信されず、アクティビティ行に failed ステータスが記録され、上限に関するメッセージが actionResults[].errorDetails に記載されます。コメントによってトリガーされた DM(comment_keyword および story_comment)は例外です: 上限に達していても引き続き送信され、カウントもされます。 1 つのオートメーションに対する構造的上限: triggers 1〜50 個、actions 1〜50 個。 Instagram 自体はアカウントあたり約 200 件/時の DM 上限を課しています。エンジンは 20〜60 秒のジッターでディスパッチをペーシングし、この上限を安全に下回るようにします。

アクティビティのステータス

GET /automations/:id/activity の行には、トップレベルの status と actionResults[] 内のアクションごとの status が含まれます。 pending と in_flight は一時的な状態で、それ以外はすべて終端状態です。 オートメーションに複数のアクションがある場合、トップレベルの status はアクションごとの結果から次の順序で導出されます: いずれかのアクションが認証エラーに該当すれば auth_error、次にいずれかのアクションが受理されていれば sent、次にすべてのアクションが重複排除されていれば deduplicated、次にすべてのアクションが意図的に抑止されていれば(skipped または deduplicated)skipped、それ以外は failed となります。アクションごとの詳細については actionResults[] を参照してください。
sent はプラットフォームによる受理の受領証であり、配信の受領証ではありません。 send_dm アクションは、Instagram アカウントから送信した場合も、Facebook ページから Messenger で送信した場合も、Meta がメッセージを受理した瞬間に sent とマークされます。オートメーションが記録するのはこの受理のみで、配信は追跡しません。Instagram はメッセージ配信をいかなる API にも公開しておらず、受信者が実際に受け取るかどうかは、受信者の Instagram Message requests 設定に依存し、Ayrshare はこれを読み取ることも影響を与えることもできません。Automation DM Sent but Not Delivered を参照してください。

エラーコード

API は 2 種類のエラー形式を返します。
  • ビジネスルールエラー はオートメーション固有の番号付き code を持ちます(例: { "action": "automation", "code": 469, ... })。
  • バリデーションエラー — 不正なリクエストボディ全般(必須/無効なフィールド、不明なテンプレート変数、認識されないキー)は、単一の 473 レスポンスとして返され、details オブジェクトに問題のあるフィールドが列挙されます。details はバリデータの出力(formErrors と fieldErrors)です。条件ごとのコードではなく、details で分岐してください。fieldErrors では、キーはトップレベルのリクエストフィールド(triggers、actions)です。特定のエントリ内の問題(例: トリガーで keywords が欠落)は、そのフィールド(例: triggers)配下で報告されます。一方、formErrors にはオブジェクトレベルの問題(認識されないキーなど)が含まれます。
Launch プランも対象です。 Business Launch は Business ティアとして扱われるため、オートメーションは Launch、Business、Enterprise の各プランで利用できます。468 は、オートメーションを含まないプランに 対してのみ返されます。

Meta が許可していないこと

一般的にリクエストされる機能のうち、Meta が公開 Instagram API で許可していないため、以下はサポートされていません。
  • 新規フォロワーへの自動 DM。 Instagram はフォロー Webhook を公開していません。
  • 見知らぬ相手への初回 DM。 Meta はビジネスアカウントがメッセージを送信する前に、受信者側からのエンゲージメント(コメント、返信、DM、リアクション)を必須としています。サポートされるすべての trigger はそのようなエンゲージメントを起点としますが、送信が許可されていることと、メッセージが配信されることは別です。受信者の Instagram Message requests 設定によって、Meta がメッセージを受理しつつ黙って破棄することは依然として起こりえます(Automation DM Sent but Not Delivered を参照)。
  • 一斉アウトバウンドキャンペーン。 プラットフォームレベルで 1 時間あたりの DM 上限とスパム対策ヒューリスティクスが適用されます。

マルチプロファイル利用

エンドポイントは profileKey ヘッダーを尊重します。子プロファイルのキーを渡すと、そのプロファイル配下でオートメーションが作成/管理されます。プロファイルごとのサブ上限によってレート制限がプロファイル間で分割されるため、おしゃべりな 1 プロファイルが親アカウントのクォータを使い切ることはありません。

FAQ

いいえ。Instagram はフォロー Webhook を公開しておらず、Meta はサードパーティアプリが先にエンゲージメントを行っていないユーザーに DM を送信することを許可していません。サポートされるすべてのトリガー(comment_keyword、story_reply、dm_reaction、dm_keyword)はそのようなエンゲージメントを起点としており、これが送信を許容可能にしています。
sent は Meta がメッセージを受理したことを意味し、配信されたことを意味するものではありません。これは Instagram でも Facebook(ページからの Messenger)でも同じで、オートメーションが記録するのは受理のみで、配信は追跡しません。Instagram では、配信は受信者の Instagram Message requests 設定に依存します。受信者が全員からのメッセージリクエストを許可していない場合、Meta は成功レスポンスを返してメッセージを黙って破棄し、エラー、Webhook、その他のシグナルはあらゆる API 経路で発生しません。配信に成功したコメントトリガー DM でさえ、受信者が承認しなければならないメッセージリクエストとして届きます(既に会話が存在する場合を除く)。これは Instagram プラットフォームの恒久的な制限です。Automation DM Sent but Not Delivered を参照してください。
アカウントの Instagram または Facebook ページの認証情報またはメッセージング権限が実際に失敗した場合 — 例えば、期限切れまたは取り消されたアクセストークン、Facebook Page が選択されていない、あるいはプロファイルで Messaging が有効化されていない、などのケース — アクティビティ行に auth_error ステータスが記録され、DM は再試行されません。アカウントの状態を解消すれば(再連携、Page の選択、または Messaging の有効化)、次にマッチしたエンゲージメントで通常通り発火します。これは真の認証情報および権限の失敗にのみ適用されます: 特定の DM が別の理由で配信できなかった場合 — 例えば、受信者が見つからなかった、またはトリガーとなったエンゲージメントが DM を送信するアカウント自身から発生した場合 — その行は failed または skipped として記録され、理由は actionResults[].errorDetails に記載されます。再連携しても結果は変わりません。
各ディスパッチは、DM の送信が Instagram のスパム対策システムから見て自然に見えるよう、エンゲージメントの 20〜60 秒後にスケジュールされます。この遅延はルールがマッチする前にエンゲージメント自体に適用されるため、fire_webhook と send_email を含むルール上のすべてのアクションに適用されます。Webhook はコメントの直後ではなく、20〜60 秒後に届きます。アクティビティ行の created タイムスタンプはトリガーがマッチした時刻、completedAt はディスパッチが完了した時刻です。
アクティビティ行はトレースと分析のため無期限に保持されます。GET /automations/:id/activity エンドポイントはパフォーマンス上の理由から直近 30 日間の行を返します。(重複排除ガードは独自のアクションごとのウィンドウ — 既定 7 日間 — を使用し、これはアクティビティのルックバックとは無関係です。)
いいえ。削除はソフト削除です。マスター行に deleted フラグが立ち、新規のディスパッチは発生しなくなりますが、履歴のアクティビティ行はアクティビティエンドポイントから引き続き読み取れます。

エンドポイント