---
title: "EventBridge ログの調べ方：ルールが発火しない原因をメトリクス・バスログ・DLQで特定する"
url: "https://www.issoh.co.jp/tech/details/18449/"
published: 2026-10-17
updated: 2026-10-17
categories: ["AWS"]
publisher: "株式会社一創"
---

# EventBridge ログの調べ方：ルールが発火しない原因をメトリクス・バスログ・DLQで特定する

EventBridgeのルールを作ったのにターゲットが動かないとき、最初に困るのは「どこを見ればよいか」です。EventBridgeは処理の途中経過を既定ではどこにも残さないため、調べる側でログの出口を用意する必要があります。本記事では、CloudWatchメトリクスで止まった段を特定し、イベントバスのログ記録・CloudWatch Logsターゲット・DLQで原因を読む手順を、CLIとLogs Insightsのクエリ例つきで整理しました。EventBridge全体の仕組みは[Amazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順](https://www.issoh.co.jp/tech/details/15513/)に譲ります。仕様と上限値は2026年10月時点の公式ドキュメントの記載です。

## まとめ：EventBridgeのログ調査はメトリクスで段を絞りバスログとDLQで原因を読む

調査で最初に行うのは、問題が起きた段階の切り分けです。まずルール単位のメトリクス`TriggeredRules`・`Invocations`・`FailedInvocations`を見て、「ルールに一致していない」のか「一致したがターゲットに届いていない」のかを分けます。前者ならイベントパターンと実際のイベントの差を、後者なら権限・リソースの有無・ターゲット側のエラーを疑います。

原因を読む手段は、照合から配信までの各段を残すバスのログ記録、届いたイベント本文を残すCloudWatch Logsターゲット、失敗理由を残すDLQの3つです。AWSサービスのイベントは不一致だとバスのログにも残らないため、パターン不一致の調査ではCloudWatch Logsターゲットで実物を捕まえます。常時はERRORレベルとアラーム、DLQまでにとどめ、TRACEや詳細データは調査の間だけ有効にします。

## ログを出す3つの手段｜バスのログ記録・CloudWatch Logs・DLQの守備範囲

3つの手段は記録する対象が違い、どれか1つでは足りない場面があります。最初に守備範囲を押さえておくと、調査で遠回りしません。

### イベントバスのログ記録が残す処理の段と、記録しないAWSイベントの条件

[イベントバスのログ設定](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus-logs.html)を有効にすると、EventBridgeはイベントの受け取り・ルール照合・ターゲット呼び出しの各段をログとして送ります。送信先はCloudWatch Logs、Amazon Data Firehose、Amazon S3の3つで、どの送信先にも同じ内容が届きます。既定のレベルは`OFF`で、何も記録されません。

記録の対象には条件があります。`PutEvents`で送ったイベント、パートナーのイベント、アーカイブから再生したイベントは、ルールに一致してもしなくても記録されます。一方、AWSサービスのイベントは、バス上のルールに一致したものだけが対象です。[処理ステップの説明](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-logs-execution-steps.html)には、どのルールにも一致しないAWSイベントは破棄されログも生成されないと書かれています。マネージドルールだけに一致したイベントも記録されません。

EC2の状態変化を拾うルールが動かない場合、バスのログが空でも、イベントが来ていないのかパターンに合わなかったのかは区別できません。

### CloudWatch Logsターゲットで届いたイベント本文をそのまま残す用途

ルールのターゲットにCloudWatch Logsのロググループを指定すると、ルールに一致したイベントのJSONがログエントリとして保存されます。バスのログが「どの段で何が起きたか」を残すのに対し、こちらは「どんな中身のイベントが来たか」を残す手段です。

| 手段                   | 記録されるもの          | 分かること                   | 既定           |
| -------------------- | ---------------- | ----------------------- | ------------ |
| イベントバスのログ記録          | 照合・呼び出しの各段とエラー   | 一致したか、どのターゲットで何のエラーか    | OFF          |
| CloudWatch Logsターゲット | 一致したイベントの本文      | 実際に届くイベントのフィールドと値       | なし（ルールを作る）   |
| DLQ（SQS）             | 配信に失敗したイベントと失敗理由 | ERROR\_CODE・再試行回数・対象ルール | なし（ターゲットに設定） |

パターン不一致の調査では、条件を`source`だけに緩めた調査用ルールを別に作り、ターゲットをCloudWatch Logsにします。そこに残った実イベントと本番ルールのパターンを突き合わせれば、どのフィールドで外れているかが分かります。

本記事のメトリクス名と`message_type`は、デフォルトバスと従来型のカスタムバス（Custom Event Bus – Classic）のものです。2026年9月に追加された購読者型のCustom Event Busは、[専用の可観測性ページ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-custom-bus-observability.html)にあるとおりメトリクスが`AWS/EventsV2`に出て、ログも購読者ごとの`LogConfiguration`で有効にする別系統です。

## ルールが発火しないときの最初の確認｜CloudWatchメトリクスで止まった段を特定

ログを有効にする前に、設定なしで毎分送られているメトリクス（`AWS/Events`名前空間）で段を絞ります。

### TriggeredRulesとFailedInvocationsで止まった段を見分ける

[メトリクスの一覧](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-monitoring.html)から、ルールが発火しない調査で使う4つを並べます。統計はSumを使います。

| メトリクス                | 数えるもの                 | 0またはデータなしのときの読み方        |
| -------------------- | --------------------- | ----------------------- |
| TriggeredRules       | イベントに一致して動いたルールの数     | パターン不一致か、イベント自体が来ていない   |
| Invocations          | ターゲットを呼んだ回数（成功・失敗の両方） | 一致していても呼び出しまで進んでいない     |
| FailedInvocations    | 再試行を経ても失敗した呼び出し       | 値があれば権限・リソース・ターゲット側のエラー |
| InvocationsSentToDlq | DLQへ送られた呼び出し          | 値があればDLQのERROR\_CODEを読む |

`TriggeredRules`に値があり`FailedInvocations`も増えているなら、問題はターゲットへの配信側です。`TriggeredRules`が出ていないなら、配信側をいくら調べても答えは出ません。

### get-metric-statisticsでルール単位のSumを取りデータなしを読む

CLIでは次のように取得します。`--dimensions`にルール名を入れ、5分刻みのSumを見ます。

```
aws cloudwatch get-metric-statistics \
  --namespace AWS/Events \
  --metric-name TriggeredRules \
  --dimensions Name=EventBusName,Value=orders-bus Name=RuleName,Value=order-created-to-sqs \
  --start-time 2026-10-17T00:00:00Z --end-time 2026-10-17T06:00:00Z \
  --period 300 --statistics Sum
```

ここに2つの落とし穴があります。1つ目は次元の指定です。公式によると、`RuleName`だけを指定したメトリクスはデフォルトバスのルールを指し、カスタムバスのルールは`EventBusName`と`RuleName`の両方で記録されます。カスタムバスのルールを`RuleName`だけで探すと、動いていても何も返りません。

2つ目は「0」が記録されないことです。`Invocations`や`FailedInvocations`、`InvocationsSentToDlq`は値が0でないときだけ送られ、`TriggeredRules`はルールが一度動くまでメトリクス自体が現れません。データポイントが空なのは「0回」の意味で、取得の誤りとは限らない。なお、メトリクスはベストエフォートで、1分単位の完全な記録ではないと明記されています。

## イベントバスのログを有効にする手順｜ログレベル・詳細データ・送信先の設定

段が絞れたら、バスのログ記録で中身を読みます。設定はレベル、詳細データの有無、送信先の3点です。

### update-event-busでレベルを指定しロググループへ配信する設定例

レベルと詳細データは[update-event-bus](https://docs.aws.amazon.com/cli/latest/reference/events/update-event-bus.html)の`--log-config`で指定します。値は`Level`が`OFF`・`ERROR`・`INFO`・`TRACE`、`IncludeDetail`が`NONE`・`FULL`です。送信先はCloudWatch Logsのログ配信の仕組み（配信元・配信先・配信の3つ）で紐づけます。コンソールのバス編集画面で送信先を選べば、この紐づけは画面側で作られます。

```
# 1. バスのログレベルと詳細データを設定する
aws events update-event-bus --name orders-bus \
  --log-config IncludeDetail=FULL,Level=INFO

# 2. 配信先のロググループを作る（/aws/vendedlogs/ で始める）
aws logs create-log-group --log-group-name /aws/vendedlogs/events/orders-bus

# 3. バスを配信元、ロググループを配信先として登録し、両者を紐づける
aws logs put-delivery-source --name orders-bus-info \
  --resource-arn arn:aws:events:ap-northeast-1:123456789012:event-bus/orders-bus \
  --log-type INFO_LOGS

aws logs put-delivery-destination --name orders-bus-cwl \
  --delivery-destination-configuration destinationResourceArn=arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/events/orders-bus

aws logs create-delivery --delivery-source-name orders-bus-info \
  --delivery-destination-arn DESTINATION_ARN
```

`DESTINATION_ARN`には`put-delivery-destination`の応答に入るARNを入れます。`--log-type`は設定したレベルに合わせた種別を指定します。ロググループ名を`/aws/vendedlogs/`で始めておくと、配信用のリソースポリシーをCloudWatch Logs側が管理してくれる、というのが購読者型バスの手順にある説明です。設定する側のIAMには、対象バスに対する`events:AllowVendedLogDeliveryForResource`の許可が要ります。

### ERROR・INFO・TRACEで記録されるmessage\_typeと選び方

レベルは上位が下位を含む関係です。[ログのスキーマ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-logs-schema.html)にある`message_type`で見ると、調査に効くものは次のとおりです。

- `ERROR`：`INVOCATION_FAILURE`・`INVOCATION_ATTEMPT_PERMANENT_FAILURE`・`INVOCATION_ATTEMPT_RETRYABLE_FAILURE`・`INVOCATION_DLQ`・`EVENT_INGEST_FAILURE`などの失敗と、スロットリング
- `INFO`：上記に加え、`RULE_MATCH`（一致したルールとターゲット）、`NO_STANDARD_RULES_MATCHED`（一致なし）、`INVOCATION_START`・`INVOCATION_SUCCESS`
- `TRACE`：上記に加え、`EVENT_RECEIPT`・`RULE_MATCH_START`・試行ごとの`INVOCATION_ATTEMPT_START`・`INVOCATION_ATTEMPT_SUCCESS`

「ルールに一致したか」を知りたいなら`INFO`で足ります。`NO_STANDARD_RULES_MATCHED`が出ていれば、`PutEvents`で送ったイベントはどのルールにも合わなかったと分かる。`TRACE`は再試行の1回ごとまで出るため、スロットリングや遅延を追うときに限ります。`IncludeDetail=FULL`にすると`target_input`などが付き、ターゲットに何を渡したかまで読める。1レコードは1MBが上限で、超えた分の項目は`dropped_fields`に記録されて削られます。

### Logs Insightsでevent\_idを軸に呼び出しの失敗まで追うクエリ

CloudWatch Logsに届いたレコードはJSONなので、Logs Insightsでフィールドを指定して読めます。最初に段ごとの件数を数え、次に1件のイベントを`event_id`で追います。

```
# 直近の段ごとの件数
fields message_type
| stats count(*) as n by message_type
| sort n desc

# 1件のイベントを受け取りから呼び出しの結果まで時系列で追う
fields @timestamp, message_type, details.rule_arn, details.target_arn, error.aws_service, error.http_status_code, error.error_message
| filter event_id = "6a7e8feb-b491-4cf7-a9f1-bf3703467718"
| sort @timestamp asc
```

失敗したレコードの`error`には、呼び出し先のサービス名、HTTPステータス、エラーメッセージが入ります。ターゲット側のログを探す前にここを見ます。Logs Insightsはスキャン量で課金されるため、期間を絞って実行してください。クエリ言語と課金の詳細は[CloudWatch Logs Insightsの料金と使い方](https://www.issoh.co.jp/column/details/2900/)にまとめています。

## 原因別の確認手順｜パターン不一致・CloudTrail・権限不足・DLQの失敗理由

メトリクスとログで見えた症状ごとに、確認する場所と直し方を並べます。

### RULE\_MATCHが出ないときは実イベントをtest-event-patternで照合

ルールを作成・変更した直後は、反映まで少し時間がかかると[公式のトラブルシューティング](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-troubleshooting.html)に書かれています。時間を置いても一致しないなら、実際に届くイベントを捕まえてパターンと照合します。

```
# 調査用：sourceだけで拾うルールを作り、CloudWatch Logsへ流す
aws events put-rule --name debug-ec2-all \
  --event-pattern '{"source":["aws.ec2"]}'

aws events put-targets --rule debug-ec2-all \
  --targets 'Id=cwl,Arn=arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/events/debug-ec2'

# ロググループに残ったイベントをevent.jsonに保存し、本番ルールのパターンと照合する
aws events test-event-pattern \
  --event-pattern file://pattern.json \
  --event file://event.json
```

[test-event-pattern](https://docs.aws.amazon.com/cli/latest/reference/events/test-event-pattern.html)は一致すれば`"Result": true`を返します。外れやすいのは、ARNの区切り文字です。多くのAWSサービスはARNのコロンとスラッシュを同じ扱いにしますが、EventBridgeのパターンは厳密一致なので、イベントに入っている通りの文字で書きます。CloudTrailのAPIイベントは`resources`が空のことがあり、`resources`で絞ると一致しません。演算子の書き方は[EventBridge イベントパターンの書き方](https://www.issoh.co.jp/tech/details/18424/)で扱っています。調査が終わったら`debug-ec2-all`は削除します。

### CloudTrail経由のイベントは証跡・読み取り系の状態・us-east-1を確認

`detail-type`が`AWS API Call via CloudTrail`のイベントは、条件を満たさないとそもそもバスに届きません。[CloudTrail経由のイベントのページ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event-cloudtrail.html)で確認すべき点は3つです。

1. ログ記録が有効なCloudTrailの証跡があるか。CloudTrail系の`detail-type`は証跡が無いと記録されない
2. `Get`・`List`・`Describe`などの読み取り系の管理イベントを拾いたい場合、ルールの状態が`ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS`になっているか。既定の`ENABLED`では一致しない
3. IAMやRoute 53などグローバルサービスのAPIイベントを、米国東部（バージニア北部）のus-east-1で受けているか

CloudTrailのイベントはデフォルトバスにだけ届くため、カスタムバスで拾うには転送用のルールが要ります。読み取り系を転送するなら、転送元と転送先の両方のルールに上記の状態が必要です。バスをまたぐ送信のポリシーは[EventBridge イベントバスの使い分け](https://www.issoh.co.jp/tech/details/18441/)で解説しています。

### CloudWatch Logsに書き込まれない原因はロググループのリソースポリシー

ルールは動いているのにロググループが空なら、まず権限を疑います。[リソースベースのポリシーのページ](https://docs.aws.amazon.com/ja%5Fjp/eventbridge/latest/userguide/eb-use-resource-based.html)によると、ロググループ側にEventBridgeが書き込めるリソースポリシーが要り、コンソールなら自動で作られますが、CLIやIaCでは自分で登録します。

```
aws logs put-resource-policy --policy-name EventBridgeToCWLogsPolicy \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":["events.amazonaws.com","delivery.logs.amazonaws.com"]},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":"arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/events/*:*"}]}'
```

CloudWatch Logsのターゲットには`RoleArn`を指定しないよう公式に注意書きがあります。ロールを付ければ動く、という発想で直そうとすると遠回りです。また[put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-resource-policy.html)で登録するポリシーは、[CloudWatch Logsのクォータ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch%5Flimits%5Fcwl.html)でリージョンごとに10個までと決まっており、引き上げできません。ロググループごとにポリシーを足すのではなく、`/aws/events/`のような接頭辞で1つにまとめます。Terraformで書く場合の例は[Terraform EventBridgeの実装手順](https://www.issoh.co.jp/tech/details/18447/)にあります。

### DLQのERROR\_CODE属性で権限不足とリソース不在を見分けて直す

ターゲットにDLQを付けておくと、配信に失敗したイベントがSQSに残り、メッセージ属性に失敗の理由が入ります。[DLQのページ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rule-dlq.html)にある属性は`RULE_ARN`・`TARGET_ARN`・`ERROR_CODE`・`ERROR_MESSAGE`・`EXHAUSTED_RETRY_CONDITION`・`RETRY_ATTEMPTS`の6つです。

```
aws sqs receive-message \
  --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/orders-bus-dlq \
  --message-attribute-names All \
  --max-number-of-messages 10 \
  --visibility-timeout 0
```

`ERROR_CODE`が`NO_PERMISSIONS`ならターゲット側のリソースポリシーかロール、`NO_RESOURCE`ならターゲットのリソースが消えている、`THROTTLING`ならターゲットの処理能力不足です。公式によると、権限不足・リソース不在・アドレス不正は再試行されずに直接DLQへ送られます。`RETRY_ATTEMPTS`が0で届いたものは再試行の対象外だった失敗なので、まず権限やリソースの設定を疑う。回数が多いものなら、調査の起点はターゲット側の一時的な障害です。APIでDLQを指定した場合はキュー側のポリシーも手で付ける必要があり、抜けると`InvocationsFailedToBeSentToDlq`が増えます。DLQからの再投入は[EventBridgeとSQS・Lambdaの非同期構成](https://www.issoh.co.jp/tech/details/6034/)で扱っています。

## ログ調査の運用判断｜常時有効にする範囲と調査時だけ上げる設定の線引き

ログは多く出すほど調査は楽になりますが、費用と情報の複製が増えます。常時の設定と調査時の設定を分けておきます。

### 常時はERRORレベルと失敗のアラーム、全ターゲットのDLQで足りる

本番で常に有効にしておくのは次の3つで足ります。

- バスのログ記録を`ERROR`・`IncludeDetail=NONE`で有効にする（失敗した段とエラー内容だけが残る）
- `FailedInvocations`のSumが1以上でSNSに通知するCloudWatchアラーム（公式のトラブルシューティングに作成手順がある）
- すべてのターゲットにDLQを付け、`InvocationsSentToDlq`にもアラームを張る

EventBridgeは配信を最大24時間再試行し、尽きると`FailedInvocations`を記録してイベントを捨てます。DLQが無い構成では、失敗に気づいた時点で中身は残っていません。ログより先にDLQを付ける、が優先順位です。

### TRACEとFULLを調査の間だけに限る理由はペイロードの複製

`IncludeDetail=FULL`にすると、イベント本文とターゲットへの入力がログに複製されます。購読者型バスのドキュメントは、ペイロード付きのログはロググループを読める人なら誰でも本文を読めると警告し、調査が済んだら戻すよう案内しています。個人情報や注文情報を流すバスで`FULL`を出しっぱなしにする構成は採りません。

費用の面でも、バスのログはCloudWatchの[Vended Logsの料金](https://aws.amazon.com/cloudwatch/pricing/)（料金ページのLogsタブ）で課金され、`TRACE`はイベント1件ごとに複数のレコードを生みます。流量の多いバスで常時`TRACE`にする理由はありません。調査は`INFO`から始め、再試行やスロットリングを追う必要が出たときだけ`TRACE`に上げ、終わったら`ERROR`に戻す運用にします。イベント駆動の構成で監視や障害調査の仕組みまで含めて設計を見直したい場合は、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)でご相談いただけます。

## よくある質問

EventBridgeのログと発火しないルールの調査でよく出る疑問に、公式ドキュメントの記載をもとに答えます。

### EventBridgeのログはどこで見られますか？

既定ではどこにも出ていません。バスのログ記録かCloudWatch Logsターゲットを設定するまで記録は無く、障害が起きてから有効にしても過去分は読めません。過去の状況は、設定なしで出ているCloudWatchメトリクスの`AWS/Events`名前空間で確認します。

### スケジュールで動かすルールが指定した時刻に動きません。何を確認しますか？

まず時刻の基準を確認します。ルールの`ScheduleExpression`はUTCで解釈されるため、日本時間の9時に動かしたいなら`cron(0 0 * * ? *)`と書きます。ルールは指定した分の中で動き、秒単位の精度はありません。タイムゾーンを指定したい、1回限りの実行をしたいといった要件なら、EventBridge Schedulerのほうが向いています。Schedulerの書き方は[EventBridge SchedulerのAPI](https://www.issoh.co.jp/tech/details/4019/)で解説しています。

### ルールは動いているのにLambda関数が起動しないのはなぜですか？

多くはLambda側のリソースベースポリシーの不足です。`aws lambda get-policy`で、プリンシパル`events.amazonaws.com`と対象ルールのARNを条件にした`lambda:InvokeFunction`の許可があるかを確認します。公式のトラブルシューティングによると、ポリシーに`SourceAccount`が入っているとEventBridgeから呼べないため削除が必要です。エイリアスやバージョンを呼んでいる場合は`--qualifier`を付けて確認します。

### イベントバスのログ記録に料金はかかりますか？

かかります。バスのログはCloudWatchのVended Logsとして配信され、S3やFirehoseへ送る場合も配信の料金が発生し、保存先の料金は別です。EventBridge本体の課金の仕組みは[Amazon EventBridgeの料金](https://www.issoh.co.jp/tech/details/3341/)で整理しています。

### ログが出ていないのは、イベントが処理されていないということですか？

そうとは限りません。公式は、バスのログもメトリクスもベストエフォートで、完全性と適時性は保証されないと明記しています。ログが無いことだけで結論を出さず、メトリクス、CloudWatch Logsターゲットに残った実イベント、DLQの3つを突き合わせて判断します。

## 関連記事

- [Amazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順、新Custom Event Busとの違いを解説【2026年版】](https://www.issoh.co.jp/tech/details/15513/)：バス・ルール・ターゲットの全体像と最小構成。
- [EventBridge イベントパターンの書き方：演算子一覧とtest-event-patternでの検証](https://www.issoh.co.jp/tech/details/18424/)：一致しないパターンを直すときの演算子と照合規則。
- [EventBridgeとSQS・Lambdaの非同期構成｜キューポリシー・部分バッチ応答・DLQの置き場所](https://www.issoh.co.jp/tech/details/6034/)：DLQの置き場所と、溜まったイベントの再投入。
- [CloudWatch Logs Insightsの料金と使い方｜スキャン課金・limit上限・3つのクエリ言語【2026年版】](https://www.issoh.co.jp/column/details/2900/)：バスのログを読むクエリの書き方と課金。
- [EventBridge 入力トランスフォーマーの使い方：InputTemplateでSNS・Slack通知を整形する](https://www.issoh.co.jp/tech/details/18439/)：ターゲットへ渡す入力を整形したときの確認方法。

---

出典: [EventBridge ログの調べ方：ルールが発火しない原因をメトリクス・バスログ・DLQで特定する](<https://www.issoh.co.jp/tech/details/18449/>)（株式会社一創）