ドキュメントLearning Manager

Webhooks

Last update: Mon Apr 13 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Webhookを使用すると、特定のイベントが発生したときに、1つのエンティティから別のエンティティにリアルタイムのデータまたは通知を自動的に送信できます。 これにより、アプリケーションは常に情報を要求することなく、他のアプリケーションに情報を提供することができます。 例えば、ユーザーが学習管理システム(LMS)コースを完了すると、webhookはその情報をCRMやレポートツールなどの別のプラットフォームに自動的に送信できます。 Webhookは、プロセスを自動化し、システム間の手動アップデートの必要性を減らすために、統合でよく使用されます。 データの送信先となるコールバックURLを指定して、webhookを設定します。

WebhookとAPIの比較

WebhookとAPIはどちらもシステムが相互に通信するのに役立ちますが、動作の方法は異なります。 APIを使用すると、ユーザーが要求した場合にのみ情報が共有されます。 例えば、学習者がコースの進捗状況に関するデータを必要とする場合、学習者はAPIにリクエストを送信し、APIがその情報を提供します。 一方、Webhookでは、イベントが発生するとすぐにデータが自動的に送信されます。 例えば、学習者がコースを完了すると、手動リクエストなしでデータがリスナーURLにすぐに送信されます。

リアルタイムAPIとは

リアルタイムAPIを使用すると、イベントが発生したときにアプリケーションでデータを即座に交換できます。 ユーザーが情報を要求するのを待つ従来のAPIとは異なり、リアルタイムAPIはデータが発生した時点でデータを共有します。 WebhookはリアルタイムAPIとして機能し、指定されたイベントが発生するとすぐにデータを共有できます。 リアルタイムAPIにより、手動リクエストを行うことなく、このデータ転送が即座に行われるため、システムが即座に更新されます。

Webhookイベント

Webhookイベントは、リスナーURLにデータを自動的に送信するシステムで発生する特定のアクションです。 例えば、学習者がコースに登録すると、webhookイベントがトリガーされ、登録の詳細がリスナーURLに送信されます。

Webhookイベントは、次の2つのカテゴリに分類されます。

  • リアルタイムイベント:イベントはリアルタイムで処理され、ターゲットURLに送信されます
  • 非リアルタイムイベント:イベントはバッチで処理され、リアルタイムではなく指定された時間に送信されます

リスナーURL

リスナーURLは、イベントが発生したときにデータ情報を受信するエンドポイントまたは宛先です。 コースへのユーザー登録など、特定のイベントが発生すると、システムは手動で要求することなく、このURLに詳細を自動的に送信します。 リスナーURLは、これらすべてのアップデートが配信されるアドレスです。
Webhookは、関連する情報をJSON形式で送信します。 Adobe Learning Managerでトリガーされるイベントのペイロードの例を次に示します。

{
  "accountId": 1010,
  "events": [
    {
      "eventId": "d5fb7071-10a9-46b2-9f9e-79dde346c052",
      "eventName": "COURSE_ENROLLMENT_BATCH",
      "timestamp": 1727414643000,
      "eventInfo": "1727414643000-047210-84242-0",
      "data": {
        "userId": 4279332,
        "loId": "course:7374992",
        "loInstanceId": "course:7376092_10250977",
        "loType": "course",
        "enrollmentSource": "ADMIN_ENROLL",
        "dateEnrolled": 1727414643
      }
    }
  ]
}

Webhookの作成と管理 – 統合管理者

Adobe Learning ManagerでWebhook統合を作成するには、次の手順を実行します。

  1. 統合管理者​としてログインします。

  2. ホームページで、Webhook/Webhookを追加​を選択します。


    Webhookを追加

  3. Webhookの​ 名前 ​と​ 説明 ​を入力します。

  4. イベントデータを渡すリスナーURLを​ ターゲットURL ​として入力します。

  5. 次のいずれかの認証方法を選択します。
    Webhooksの認証は、リスナーURLに送信されるデータが信頼できるソースから来ていることを確認するためのセキュリティ方法です。

    • なし：認証は不要です。
    • 基本：これは資格情報ベースの認証です。 ユーザー名とパスワードを入力します。
    • 署名:システムは特別な署名を作成し、Webhookデータに追加します。 受信側のサーバーはこのコードをチェックして、データが実際のものであり、変更されていないことを確認します。 署名を生成し、認証に使用します。 署名をJSONとしてダウンロードします。

  6. トリガーイベント​ドロップダウンからWebhookイベントを選択します。

    note note
    NOTE
    「 Webhookを追加」ページから「 Webhookをテスト」オプションを選択して、webhookをテストすることもできます。

  7. アクティベーションステータス​の切り替えを選択して、Webhookを有効にします。 有効にすると、選択したイベントが発生するたびにデータが渡されます。

NOTE
最大5つのWebhookを作成および管理できます。

Webhookを編集 – 統合管理者

Adobe Learning ManagerからWebhookを編集するには、次の手順に従います。

  1. 統合管理者​としてログインします。

  2. ホームページで​ Webhook ​を選択します。

  3. 編集するwebhookを選択します。


    Webhookを編集

  4. 「編集」を選択してwebhookの詳細を変更し、「保存」を選択します。

Webhookを削除 – 統合管理者

Adobe Learning ManagerからWebhookを編集するには、次の手順に従います。

  1. 統合管理者​としてログインします。
  2. ホームページで​ Webhook ​を選択します。
  3. 削除するwebhookを選択します。
  4. Webhookを削除するには、削除​を選択します。


Webhookを削除

Webhookの廃止 – 統合管理者

Webhookを廃止するには、次の手順に従います。

  1. 統合管理者​としてログインします。
  2. ホームページで​ Webhook ​を選択します。
  3. 編集するwebhookを選択します。
  4. 編集​を選択し、アクティベーションステータス​を無効にして、Webhookを廃止します。


Webhookを廃止

代替用のWebhook webhooks-for-alternates

ALMは、代替完了用の専用のwebhookイベントを提供して、自動化、統合、外部システムとの同期をサポートします。

これらのイベントにより、外部のコンシューマーは、別の関係を介して付与された直接完了と完了を確実に区別できます。

概要

学習者が代替または関係を介してコースを完了すると、ALMは、標準のコース完了webhookとは別にwebhookイベントをトリガーします。 これにより、必要に応じて別の完了に対して統合が異なる応答を返すことができます。

また、Webhookイベントは、遡及的な完了または遡及的な未完了が発生した場合にもトリガーされ、履歴更新と関係の変更が対象となります。

Webhookイベントの動作

  • 個別のwebhookイベントは、学習者がターゲットコースの代替ステータスを介して「完了」を受信した場合にトリガーされます。
  • このイベントは、学習者が代替関係を通じてターゲットを満たす設定されたソースコースを完了したときに生成されます。
  • このWebhookは、直接コースの完了にはトリガーされません。
  • 「遡及完了」または「遡及未完了」が有効になっている場合は、影響を受ける学習者およびターゲット・コースごとにWebhookイベントが発行されます。

Webhookペイロードの詳細

代替完了Webhookペイロードには、次のキー属性が含まれます。

  • 学習者ID
    代替完了を受け取った学習者を識別します。
  • ソースコース
    学習者が直接完了したコースまたは学習パス。
  • 対象コース
    代替関係を介して完了とマークされたコース。
  • 完了方法
    補完方式が代替であることを示します。
  • 完了日
    ソースコースの完了日から取得されます。
  • リレーションシップの種類
    リレーションシップが代替かどうかを指定します。

遡及的完了取消シナリオの場合、webhookイベントは、既存の代替完了が取り消されたことを示します。

統合に関する考慮事項

外部システムは、次のWebhookイベントを使用できます。

  • 学習者レコードの更新
  • 完了ステータスの同期
  • 通知またはダウンストリームワークフローのトリガー
  • コンプライアンスの目的で監査証跡を維持

Webhookコンシューマーは、直接完了と代替完了を明示的に区別する必要があります。

代替完了では、スキル、バッジ、およびゲーミフィケーション報酬は付与されません。 下流のシステムでは、フィードバックを適切に処理する必要があります。

アダプティブ学習パスのWebhook

概要

Adobe Learning Managerは、学習パス（学習プログラム）​の完了ステータスが更新されるたびに外部システムに通知する​ webhookイベント ​を提供します。 これにより、学習者の完了レコードがロールバックまたは再計算されるたびに、下流システム（人事、レポート作成、分析プラットフォームなど）を同期できます。

2つの新しいWebhookイベントタイプを使用できます。

LEARNING_PATH_COMPLETION_ROLLBACK - 学習者​が自分の学習パスの完了ステータスを更新するとトリガーされます。

LEARNING_PATH_COMPLETION_ROLLBACK_BATCH - 管理者​が​ 1人以上の学習者 ​の学習パスの完了ステータスを更新したときにトリガーされます（一括操作など）。

これらのイベントは、共通のペイロード構造​を使用し、webhookエンドポイントが使用して、サイドで完了データを更新または再処理できます。

共通のペイロード構造

各Webhookリクエストには、次のトップレベル構造が含まれています。

{
  "accountId": 69735,
  "events": [
    {
      "eventId": "757b9d58-048c-4ae2-9fff-35f9def7ef29",
      "eventName": "LEARNING_PATH_COMPLETION_ROLLBACK",
      "timestamp": "2026-01-20T05:48:10.000Z",
      "eventInfo": "1768888090000-197513-137581-0",
      "data": {
        "userId": 13446697,
        "loId": "learningProgram:157165",
        "loInstanceId": "learningProgram:157165_148769",
        "loType": "learningProgram",
        "enrollmentSource": "SELF_ENROLL",
        "dateEnrolled": "2026-01-20T05:44:05.000Z"
      }
    }
  ]
}

同じ構造​は、両方のイベントの種類で使用されます。eventNameとデータ内の値（userId、loId、enrollmentSourceなど）のみが異なります。

例：学習者が開始する更新

学習者が自分の学習パスの完了ステータスを更新すると、WebhookはLEARNING_PATH_COMPLETION_ROLLBACKイベントを送信します。

{
  "accountId": 69735,
  "events": [
    {
      "eventId": "757b9d58-048c-4ae2-9fff-35f9def7ef29",
      "eventName": "LEARNING_PATH_COMPLETION_ROLLBACK",
      "timestamp": "2026-01-20T05:48:10.000Z",
      "eventInfo": "1768888090000-197513-137581-0",
      "data": {
        "userId": 13446697,
        "loId": "learningProgram:157165",
        "loInstanceId": "learningProgram:157165_148769",
        "loType": "learningProgram",
        "enrollmentSource": "SELF_ENROLL",
        "dateEnrolled": "2026-01-20T05:44:05.000Z"
      }
    }
  ]
}

学習者が明示的に更新を要求した場合に、外部システムで​ 学習者の完了データを再計算またはリセット ​するには、このイベントを使用します。

例：管理者が開始するバッチリフレッシュ

管理者が1人以上の学習者の完了の更新（グループの過去の完了数の修正など）を実行すると、WebhookからLEARNING_PATH_COMPLETION_ROLLBACK_BATCHイベントが発生します。

{
  "accountId": 69735,
  "events": [
    {
      "eventId": "757b9d58-048c-4ae2-9fff-35f9def7ef29",
      "eventName": "LEARNING_PATH_COMPLETION_ROLLBACK_BATCH",
      "timestamp": "2026-01-20T05:48:10.000Z",
      "eventInfo": "1768888090000-197513-137581-0",
      "data": {
        "userId": 13446698,
        "loId": "learningProgram:157166",
        "loInstanceId": "learningProgram:157166_148770",
        "loType": "learningProgram",
        "enrollmentSource": "ADMIN_ENROLL",
        "dateEnrolled": "2026-01-21T05:44:05.000Z"
      }
    }
  ]
}

バッチ操作では、webhookエンドポイントは、完了が更新された学習者ごとに1つ、1つのリクエストで​ 複数のイベントオブジェクト ​を受信する場合があります。 統合では、イベント配列を反復処理し、各イベントを個別に処理する必要があります。

これらのイベントを統合で使用する方法

これらのwebhookイベントは、次の場合に使用できます。

完了レコードを外部のLMS/LRS、HR、またはレポートシステムと同期します​完了がロールバックまたは再計算されたとき。

ダウンストリームワークフローのトリガー （証明書やバッジの再割り当て、通知、再計算など）。

eventId、タイムスタンプ、eventInfoを、学習者および学習パスIDと共にログに記録することで、監査証跡を維持​します。

少なくとも、webhookハンドラーは次のことを行う必要があります。

ペイロードを検証し、イベントを解析します[]。
eventNameを使用して、変更が​ learnerinitiated ​か​ admin/batchinitiated ​かを特定します。

userId、loId、およびloInstanceIdを使用して、システム内の対応するレコードを検索し、更新します。
同じイベントが複数回配信される場合に、重複した処理を防ぐには、eventIdを使用します。

ユーザーグループのメンバーシップを追加および削除するためのWebhook

2つの新しいWebhookイベントタイプに最終ステータスが反映されます。

  • 応答:ASYNCAPI_USERGROUP_USER_ADDED
  • 応答:ASYNCAPI_USERGROUP_USER_REMOVED

サンプルペイロード

{
  "accountId": 69735,
  "events": [
    {
      "eventId": "cd2972c8-cb15-47a0-a23f-e4a16cb720f5",
      "eventName": "RESPONSE:ASYNCAPI_USERGROUP_USER_REMOVED",
      "timestamp": "2026-03-18T13:38:12.000Z",
      "eventInfo": "cd2972c8-cb15-47a0-a23f-e4a16cb720f5",
      "data": {
        "status": "SUCCESS",
        "request": {
          "metadata": { "event_id": "cd2972c8-cb15-47a0-a23f-e4a16cb720f5" },
          "data": [ { "type": "user", "id": "13446641" } ]
        }
      }
    }
  ]
}

主な要素

  • accountIdはALMアカウントを識別します。
  • eventsはイベントオブジェクトの配列です。
  • eventIdは元の非同期要求識別子と一致します。
  • eventNameは追加操作または削除操作を示します。
  • timestampは完了時間を表示します。
  • data.statusは現在、成功したバッチの「SUCCESS」を報告しています。
  • data.requestには、送信した正確な要求が含まれています。

統合では、主にeventId （またはmetadata.event_id）とstatusをキーオフする必要があります。

例

ユーザーの非同期追加

手順1. 非同期呼び出しを行う

POST/primeapi/v2/async/userGroups/12345/users

{
  "metadata": {
    "event_id": "sync-2026-03-30T10:15:00Z-ug-12345",
    "sourceSystem": "HRIS",
    "batchId": "hr_2026_03_30_0001"
  },
  "data": [
    { "type": "user", "id": "11101219" },
    { "type": "user", "id": "11101220" }
  ]
}

手順2. 即時応答を読み取ります

{ "event_id": "sync-2026-03-30T10:15:00Z-ug-12345" }

このジョブをシステムで送信済みとしてマークできるようになりました。

手順3. Webhook​を処理します

Webhookコールバックの例：

{
  "accountId": 69735,
  "events": [
    {
      "eventId": "sync-2026-03-30T10:15:00Z-ug-12345",
      "eventName": "RESPONSE:ASYNCAPI_USERGROUP_USER_ADDED",
      "timestamp": "2026-03-30T10:15:43.000Z",
      "data": {
        "status": "SUCCESS",
        "request": {
          "metadata": {
            "event_id": "sync-2026-03-30T10:15:00Z-ug-12345",
            "sourceSystem": "HRIS",
            "batchId": "hr_2026_03_30_0001"
          },
          "data": [
            { "type": "user", "id": "11101219" },
            { "type": "user", "id": "11101220" }
          ]
        }
      }
    }
  ]
}

一般的なコンシューマーは次のことを行います。

  • 内部ジョブを見つけます。
  • オプションで、GET /userGroups/{id}/usersを使用してメンバーシップを確認します。
  • ジョブを完了としてマークします。

ユーザーの非同期的な削除

同じ身体構造のDELETEを用いて、切除は対称性である。

{
  "metadata": {
    "event_id": "sync-2026-03-30T11:00:00Z-ug-12345",
    "sourceSystem": "HRIS",
    "batchId": "hr_2026_03_30_0002"
  },
  "data": [ { "type": "user", "id": "11101219" } ]
}

速やかな対応：

{ "event_id": "sync-2026-03-30T11:00:00Z-ug-12345" }

その後、同じeventIdでRESPONSE:ASYNCAPI_USERGROUP_USER_REMOVED Webhookが受信されます。

詳細については、ユーザーグループメンバーシップの非同期パブリックAPIを参照してください。

recommendation-more-help
d5e5961a-141b-4c77-820e-8453ddef913d