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 データでエンリッチされます。

主な概念

トリガーを呼び出す

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%"
  }'

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

トリガー呼び出しの認証

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

トークンを取得する方法

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

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

応答

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

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

このアプローチの違い

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

前と後

スケジュールされたタスクと 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 リファレンス

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を使用します。

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

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

制限

関連するコンテンツ

• スケジュールされたタスク
• ワークフローの自動化
• HTTP トリガーを作成してテストする