Amazon Quick Flows でスケジュール実行時に Slack インテグレーションが失敗してもフローが Failed にならない

Amazon Quick Flows でスケジュール実行時に Slack インテグレーションが失敗してもフローが Failed にならない

2026.04.04

はじめに

Quick Flows で毎朝 8 時に定期実行するフローを設定して経過観察していました。通知の文面の変化や、安定して実行できるかを確認するためです。2026 年 4 月に入り、フローの実行結果の通知先である Slack への通知が届かなくなりました。実行履歴を確認したところ、ステップが失敗してもフロー全体が Failed にならないというケースがありました。

Quick_-_Flows_🔊-10.png

スケジュール実行設定と、実行履歴の基本的な見方は以下の記事で紹介されています。

https://dev.classmethod.jp/articles/quick-suite-scheduling-quick-flows/

確認結果

  • Quick と Slack のインテグレーション設定でエラーが起きても、ステップがエラー扱いにならない
  • その場合、実行履歴の「Failed runs」フィルタではエラーを検出できない
  • エラーを確認するには個別のイベントを開く必要がある
  • メール通知の「実行を表示」リンクから直接イベント詳細に遷移して確認が必要

フロー設定の概要

今回使ったフローは 4 ステップ構成です。Quick Sight ダッシュボードを確認し、AI で分析して Slack 向けに整形・送信します。

Quick_-_Flows_🔊-6.png

このフローに毎朝 8:00 の定期実行スケジュールを設定しています。

Quick_-_Flows_🔊.png

フローが実行されると、こんな感じで Slack に通知が届きます。

demo-quick-20260325(チャンネル)_-_プライベートSlackテスト_-_Slack.png

Slack へのインテグレーション設定は以下の記事で紹介している設定が入っています。

https://dev.classmethod.jp/articles/amazon-quick-suite-slack-integration-setup/

ステップが失敗してもフローが Failed にならない

実行履歴から定期実行したときのイベント内容を確認できます。

Quick_-_Flows_🔊-8.png

個別のイベントを開くと、ステップのエラーは確認できます。定期実行だとこの内容を他の手段で通知してもらわないと困りますね。

Quick_-_Flows_🔊-10.png

フローの実行履歴に「Failed runs」でフィルタする機能があります。これでエラーが起きた実行をまとめて確認できると思ったのですが、Failed runs でフィルタしても Slack への通知失敗は引っかかりませんでした。

Quick_-_Flows_🔊-11.png

わかったこと

Quick と Slack のインテグレーション設定でエラーが起きてもエラーと判定されないことがあります。その場合、実行履歴の Failed runs フィルタではエラーになったイベントを確認できません。定期実行であれば通知先へ通知がないことをトリガーにイベントを目視確認する必要があります。

メール通知から確認する方法

フローを設定したアカウントのメールアドレスに、「〇〇の実行が完了しました。結果と出力を確認してください。」という通知が届きます。成功・失敗の区別はメールからはわかりません。

QuickSightコスト増加分析・Slack通知…_-_Classmethod_jp_メール_🔊.png

メール内の「実行を表示」をクリックすると、該当日時のイベント詳細に直接遷移できます。不定期実行の場合はステップのエラーに気づく現実的な手段はこのメール通知からの確認です。

わかったこと

フローが実行されればメール通知は行われる。ただし、メールの内容からは成功か、失敗かはわからない。

おわりに

今回、Quick と Slack のインテグレーション設定でエラーが起きてもフロー全体が Failed と判定されない挙動を確認しました。Failed runs フィルタは「フロー全体の失敗」を対象としており、個々のステップ内でのエラーは拾いません。どういう基準で Failed と判定されるかはもう少し調査が必要です。

定期実行であれば通知先への通知が来なくなることで異常に気づけます。3/26〜31 は正常に動作していたものの、4/1〜4 は Slack への通知が失敗していたことが今回の発端でした。一方、なにかしらの異常時に通知する不定期実行では通知がない日の方が多いため、エラーの検知にはメール通知を確認するか、定期的に実行履歴を目視確認する運用が必要になります。

参考

この記事をシェアする

関連記事