アトラシアン自動化で受信 Webhook トリガーを設定する

In Atlassian Automation, rules can be triggered with an incoming webhook. You can use this trigger if you want to run a rule by sending a web request from another system, such as a third-party application. In the coming months, rules containing incoming webhook triggers will begin to be routed through more secure endpoint. This update is part of our continuous focus to uplift the security and reliability of Atlassian Automation.

受信 Webhook トリガーを含む新しいルールを作成する

受信 Webhook トリガーを含む新しく作成されたルールはすべて、自動的に新しいエンドポイントを経由します。移行に向けてこれらのルールを準備するために、開発者側で何かする必要はありません。

受信 Webhook を含むルールを作成、設定するには、次の手順を実行します。

1. Jira または Confluence で自動化のルールビルダーを開きます。

2. トリガーとして受信 Webhook を選択します。

3. ルールのアクションと、追加したい条件やブランチを選択します。

4. ルールを有効化します。下書きとして保存して、後で有効化することもできます。

5. これで、トリガー コンポーネントに URL とシークレットが表示されるようになります。

6. その URL とシークレットをコピーします。

7. URL とシークレットを接続先のアプリに入力し、X-Automation-Webhook-Token という名前で新しい HTTP ヘッダーを追加します。これを行う方法はアプリによって異なる可能性があるため、ご利用のアプリの手順をご確認ください。ご利用のアプリでカスタム HTTP ヘッダーがサポートされていない場合、URL の末尾にスラッシュを挿入し、それに続けてシークレットを追加できます。たとえば、https://URL/SECRET のようにします。これにより、HTTP ヘッダーが不要になります。ただし、シークレットのセキュリティ強化のため、可能な場合はヘッダーを使うことをおすすめします。

8. ルールの実行後に監査ログにアクセスすると、URL でルールが正常にトリガーされたかどうかを確認できます。

受信 Webhook トリガーを含む既存のルールを更新する

2025 年 1 月 28 日よりも前に作成されたルールは 2025 年 5 月 30 日までは通常どおり動作しますが、この日以降も引き続きルールを機能させるには、アプリ内で変更を行って新しいエンドポイントに移行する必要があります。2025 年 5 月 30 日以降、従来のエンドポイントでルールをトリガーすることはできなくなります。

既存のルールを新しいエンドポイントに移行するには次の手順を実行します。

1. Jira または Confluence で自動化ルールの一覧を開きます。

2. [トリガー] フィルターをクリックし、[受信 Webhook] フィルターを選択します。受信 Webhook でトリガーされているすべてのルールが表示されます。これらのルールを 2025 年 5 月 30 日までに更新する必要があります。

3. これらのフィルタリングされたルールのうち、最近従来の Webhook でトリガーされたルールについては、名前の横に警告アイコンが表示されます。これにより、どのルールで従来の URL がアクティブに使用されているかがわかります。

4. ルールビルダーで、警告アイコンが表示されているルールの 1 つを開きます。

5. トリガー コンポーネントを選択します。

6. 新しい URL とシークレットをコピーします。

7. 新しい URL とシークレットを接続先のアプリに入力し、X-Automation-Webhook-Token という名前で新しい HTTP ヘッダーを追加します。この方法はアプリによって異なる可能性があるため、利用しているアプリの手順を適宜確認してください。利用しているアプリでカスタム HTTP ヘッダーがサポートされていない場合は、代わりに URL の末尾にスラッシュを挿入し、それに続けてシークレットを追加できます。たとえば、https://URL/SECRET のようにします。これにより、HTTP ヘッダーを必要とすることなくルールを更新できます。ただし、シークレットのセキュリティ強化のため、可能な場合はヘッダーを使用することをお勧めします。

8. ルールの実行後に監査ログにアクセスすると、新しい URL でルールが正常にトリガーされたかどうかを確認できます。

9. 受信 Webhook トリガーを含むすべてのルールに対して上記の手順を繰り返します。

今回の移行では一括アクションを実行することができないため、受信 Webhook トリガーを含むすべてのルールを手動で更新し、接続先のアプリに変更を加える必要があります。

Webhook リクエストの認証の仕組み

新しい Webhook トリガーが作成されると、一意のトークンが自動的に生成されます。ルールを実際にトリガーするのは、該当するトークンを提示する受信 HTTP リクエストのみになります。他のユーザーが Webhook を使用してルールをトリガーできないように、このトークンを非公開にしておくことをお勧めします。トークンには有効期限はありません。トークンが侵害された可能性があると思われる場合は、[再生成] ボタンをクリックして、以前のトークンを直ちに無効にし、新しいトークンを生成できます。その場合は、接続されているすべてのアプリでトークンをすぐに更新する必要があることに注意してください。

受信 Webhook が機能していることを確認するには

You can perform a quick check by triggering a webhook event and sending a POST request, via cURL or POSTMAN, to check if that triggers your rule. To check with any of the methods below, first:

1. ルールビルダーでルールを開きます。

2. 受信 Webhook トリガーを選択します。

3. Webhook の URL とシークレットをコピーします。

cURL を使用して確認するには次の手順を実行します。

1 2 curl -X POST -H 'Content-type: application/json' -H 'X-Automation-Webhook-Token: <Add you secret here>' \ <Insert_webhook_URL>

上記の cURL コマンドをターミナルで実行すると null が返されます。その後、監査ログで、ルールが実行されたかどうかを確認できます。

POSTMAN を使用して確認するには次の手順を実行します。

1. リクエスト タイプを POST に変更します。

2. Webhook の URL を URL セクションに貼り付けます。

3. X-Automation-Webhook-Token というヘッダーと、シークレットに設定された値を指定します。

4. [送信] を選択します。

5. [ステータス] に、POST リクエストが成功したことを示す 200 応答コードが表示されるはずです。

6. 自動化の監査ログで、ルールが正常に実行されたことを確認します。

上記の方法のいずれかを使用してルールがトリガーされた場合、受信 Webhook コンポーネントが想定どおりに機能していることになります。

We’ll release further updates over the next few months, which will make it easier for you to prepare for this upcoming change. These will be announced via email, community post and release notes. Information about these updates will also be added to this page once they’re available. In the meantime, if you’d like further assistance, you can contact support.