Azure SRE エージェントの HTTP トリガー

Azure SRE エージェントの HTTP トリガーは、外部システムがオンデマンドでエージェントを呼び出すために使用する Webhook エンドポイントです。継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインが失敗した場合、アラートツールで異常が検出された場合、または HTTP クライアントが POST 要求を送信すると、エージェントはイベントコンテキストを受け取り、すぐに動作を開始します。

問題: アラートとパイプラインエラーには手動トリアージが必要です

チームには、既にアラート、監視、およびワークフローのためのツール（Datadog、Dynatrace、Jira、Splunk、Grafana など）があり、さらに CI/CD パイプラインも備えていますが、それらは失敗する場合があります。問題が発生した場合、応答は毎回同じです。

エンジニアがページングされます。 エンジニアは監視ツールを開き、アラートを読み取り、ログ、メトリック、デプロイ履歴を複数のダッシュボードで手動で開き、何が起こったかを把握します。
パイプラインが失敗する: 誰かが自分の作業を停止し、ビルド出力を確認し、最近の変更と関連付け、ロールバックするか、前に進めるかを決定する必要があります。
コンテキストは分散しています。 Datadog アラートには、"prod-api での CPU スパイク" と表示されます。根本原因として、3 つのサービスからのログを関連付け、最近のデプロイを確認し、Dynatrace トレースを確認する必要があります。

HTTP トリガーのしくみ

HTTP トリガーを使用すると、Webhook をサポートするすべてのツールを SRE エージェントのインスタンスに直接接続できます。手動トリアージを行うエンジニアの代わりに、問題が Datadog アラート、Dynatrace 異常、Jira ワークフロー遷移、パイプライン障害のいずれであっても、問題を検出したシステムはエージェントに調査を指示します。コンテキストは自動的に渡されます。

各トリガーは、一意の URL を持つエージェント上の名前付き webhook エンドポイントです。外部システムが HTTP POSTを介してその URL を呼び出すと、エージェントはトリガーの構成されたプロンプトを実行します。このプロンプトは、要求本文の JSON データでエンリッチされます。

主な概念

概念	どのように機能するのか
Trigger	プロンプト、割り当てられたエージェント (既定またはサブエージェント)、および自律レベル (自律またはレビュー) を含む名前付きエンドポイント。
トリガーURL	トリガーの作成時に生成される一意の Webhook URL。この Webhook URL は、外部ツールが呼び出すものです。
JSON コンテキスト	`POST` 要求と共に送信されるオプションの JSON 本文。完全なコンテキストが含まれるように、エージェントのプロンプトの一部になります。
実行履歴	すべての呼び出しは、タイムスタンプ、スレッドリンク、成功または失敗の状態でログに記録されます。
有効化/無効化	削除せずにトリガーのオンとオフを切り替えます。無効なトリガーは 404 を返します。

トリガーを呼び出す

HTTP POST 要求を使用してトリガー URL を呼び出します。

curl -X POST \
  https://your-agent.sre.azure.com/api/v1/httptriggers/trigger/<TRIGGER_ID> \
  -H "Authorization: Bearer <ARM_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "datadog",
    "alert_title": "High error rate on checkout-api",
    "severity": "critical",
    "service": "checkout-api",
    "region": "eastus2",
    "metric": "error_rate",
    "value": "8.2%",
    "threshold": "5%"
  }'

要素	それは何か
URL	トリガーの一意の Webhook エンドポイント。トリガーの詳細ビューの [ トリガー URL] で見つけます。
Authorization	Azure Resource Manager ベアラートークン。トリガーの呼び出しについては、「認証」を参照してください。
Content-Type（コンテンツの種類）	JSON 本文を送信する場合、`application/json`である必要があります。
JSON 本文 (省略可能)	エージェントに表示する JSON データ。このデータは、エージェントのプロンプトの一部になります。アラート名、重大度、影響を受けるサービスなど、エージェントの調査に役立つコンテキストを含めます。

JSON 本文は省略可能です。本文なしでトリガーを呼び出すと、エージェントはトリガーの構成されたプロンプトのみで実行されます。本文を含めることで、エージェントはプロンプトと送信したデータの両方を確認できます。

トリガー呼び出しの認証

トリガーエンドポイントには、 Authorization: Bearer <TOKEN> ヘッダーに Azure Resource Manager ベアラートークンが必要です。呼び出し元には、エージェントリソース Microsoft.App/agents/threads/write アクセス許可が必要です。

トークンを取得する方法

メソッド	最適な用途	詳細情報
サービスプリンシパル	CI/CD パイプライン、自動化システム	アプリの登録を作成し、エージェントリソースにロールを割り当て、クライアント資格情報フローを使用してトークンを取得します。
マネージド ID	Azure でホストされるサービス (Azure Functions、Azure Virtual Machines、Azure Container Apps)	管理するシークレットはありません。 Azure リソースは自動的に認証されます。
Azure CLI	テストと開発	`az account get-access-token --resource https://management.azure.com --query accessToken -o tsv` を実行します。

Azure 認証をサポートしていない外部ツールを接続する

Datadog、Dynatrace、Jira、Splunk などのツールは、Azure Resource Manager トークンではなく、独自の認証形式で Webhook を送信します。ギャップを埋めるために、次のいずれかの中継局を使用します。

仲介	どのように機能するのか
Azure Functions	Webhook を受信し、マネージド ID を使用して Azure Resource Manager トークンを取得し、呼び出しをトリガー URL に転送します。
Azure Logic Apps	任意のソースから Webhook を受信し、組み込みの Azure Resource Manager 認証で Azure API を呼び出すコードなしのワークフロー。
Azure API Management	トリガー URL の前に配置され、ポリシーを使用してトークンの検証と変換を処理します。

応答

{
  "message": "HTTP trigger execution initiated",
  "executionTime": "2026-03-13T10:30:00Z",
  "threadId": "thread-abc123",
  "success": true
}

トリガーはすぐに HTTP 202 (Accepted) を返します。エージェントは要求を非同期的に処理します。

このアプローチの違い

HTTP トリガーは、既存のアラートツールと CI/CD ツールを、ループ内のエンジニアなしでエージェントに直接接続します。問題を検出したシステムは、エージェントに調査を指示し、完全なコンテキストを自動的に渡します。ページング、ダッシュボードの切り替え、手動によるコンテキスト収集はありません。

前と後

Before (手動トリアージ)	After トリガー (HTTP トリガー)
Datadog アラートが発生する。エンジニアがページングされ、3 つのダッシュボードが開き、調査が開始されます。	Datadog の Webhook 呼び出しがトリガーされる。エージェントは、結果を自動的に調査して投稿します。
パイプラインの中断。エンジニアはビルドログを確認し、PR を確認し、次の手順を決定します。	パイプライン障害ハンドラーがトリガーを呼び出す。エージェントはエラーを分析し、根本原因を投稿します。
Dynatrace は異常を検出します。エンジニアは、サービス間で手動で関連付けます。	Dynatrace の Webhook 呼び出しが異常コンテキストと共にトリガーされる。エージェントは、ログ、メトリック、デプロイを関連付ける。

スケジュールされたタスクと HTTP トリガー

スケジュールされたタスク	HTTP トリガー
時間ベース (時系列スケジュール)。	イベント駆動（オンデマンド）
何かが発生したかどうかに関係なく実行されます。	呼び出されたときにのみ実行されます。
実行ごとに外部入力はありません。	各呼び出しに挿入されるペイロードデータ。
定期的なチェックに最適です。	イベントドリブンの反応に最適です。

両方を一緒に使用します。事後対応型の監視にはスケジュールされたタスクを使用し、事後対応イベント処理には HTTP トリガーを使用します。

利用事例

CI/CD パイプラインの統合

デプロイパイプラインが失敗した場合は、エージェントを呼び出してエラーを分析します。

# In your pipeline's failure handler
curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"pipeline\": \"$PIPELINE_NAME\", \"run_id\": \"$RUN_ID\", \"error\": \"$ERROR_MESSAGE\"}"

アラート駆動型の調査

アラートシステムを接続して、重大なアラートが発生したときに自動調査をトリガーします。

{
  "alert_name": "Error rate > 5%",
  "severity": "P1",
  "service": "checkout-api",
  "region": "eastus2",
  "start_time": "2026-03-13T10:15:00Z"
}

導入のコンプライアンスチェック

デプロイが完了したら、コンプライアンスレビューをトリガーします。

curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -d '{"deployment_id": "deploy-456", "environment": "production", "changes": ["config update", "image bump"]}'

API リファレンス

エンドポイント	メソッド	説明
`/api/v1/httptriggers`	`GET`	すべてのトリガーを一覧表示します。
`/api/v1/httptriggers/create`	`POST`	新しいトリガーを作成します。
`/api/v1/httptriggers/{id}`	`GET`	トリガーの詳細を取得します。
`/api/v1/httptriggers/{id}`	`PUT`	トリガーのプロパティを更新します。
`/api/v1/httptriggers/{id}`	`DELETE`	トリガーを削除します。
`/api/v1/httptriggers/{id}/enable`	`POST`	トリガーを有効にします。
`/api/v1/httptriggers/{id}/disable`	`POST`	トリガーを無効にします。
`/api/v1/httptriggers/{id}/execute`	`POST`	トリガーを手動で実行します。
`/api/v1/httptriggers/{id}/executions`	`GET`	実行履歴を取得します。
`/api/v1/httptriggers/trigger/{id}`	`POST`	外部 Webhook エンドポイント。

Troubleshooting

トリガーから 404 が返される

トリガーが有効に設定されていることを確認します。無効なトリガーは 404 を返します。
URL のトリガー ID が正しいことを確認します。

401 権限がありません

トークンの対象ユーザーは、 https://management.azure.comではなく、SRE エージェントアプリ ID と一致する必要があります。
テスト用のトークンを取得するには、 az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsvを使用します。

トリガーは実行されますが、エージェントは動作しません

エージェントプロンプトを確認します。空のプロンプトでは、役に立つ出力が生成されない場合があります。
選択したサブエージェントにタスクに必要なツールがあることを確認します。
実行履歴でエラーの詳細を確認します。

制限

資源	制限
エージェントあたりのトリガー数	ハード制限なし。
実行あたりの最大ターン数	250 ターン。
Authentication	ベアラートークンは、トリガー URL ごとに必要です。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-22