Azure Logic Apps Standard を運用していると、Application Insights のトランザクション検索やトレースで「Logic Apps JobHost」「runtime environment」「Service Bus リスナー」「workflow」に対する Stopped／Started が、ほぼ毎日（とくに夜間）に記録されることがあります。本記事では、それが正常挙動なのか、Stopped の間に何が止まるのか、Always On の設定場所、そして運用で“早期に気づく”監視・通知の作り方まで、現場目線で整理します。
まず結論：Stopped／Started は多くの場合「正常」だが、影響が出るケースもある
Stopped／Started のトレースは、結論から言うと プラットフォーム側の通常のライフサイクル（再起動・入れ替え） を示していることが多く、必ずしも障害や恒久停止を意味しません。App Service／Logic Apps のランタイムが、メンテナンスやスケーリング、ヘルスチェック等の都合でプロセスを入れ替えると、ホストやリスナーが一度停止し、再起動・再接続するために Stopped→Started が残ります。
ただし、ログが「正常」であっても、タイミング次第では 短時間の処理遅延 や、再接続までの 取りこぼしに見える現象（実際は遅延） が起きることがあります。業務影響が疑われる日は、ログだけでなく、周辺メトリクスや実行履歴との突き合わせが重要です。
| よくある疑問 | 結論（運用での見方） | 次にやること |
|---|---|---|
| Stopped／Started は異常？ | 多くは正常（プラットフォームの入れ替え） | 頻度・時間帯・継続時間を観測し、相関がある日だけ深掘り |
| Stopped の間、Logic Apps はオフライン？ | 実行ホスト／リスナーの再起動中は処理が止まる可能性あり | Stopped→Started の間隔、実行失敗/遅延、バックログ増加を確認 |
| Always On はどこで設定？ | Logic Apps Standard の基盤（App Service）設定で有効化 | 「構成/General settings」等で Always On を ON（プラン条件も確認） |
| 事前/早期に把握する通知は？ | Azure Monitor / App Insights のログアラート＋Service Health が有効 | アラート条件と通知先（Action Group）を整備し、運用基準を決める |
Stopped／Started の正体：どのコンポーネントが「止まって」「再開した」のか
Application Insights 上で見える Stopped／Started は、同じ言葉でも対象によって意味合いが変わります。まずは用語の対応関係を整理すると、切り分けが一気に楽になります。
| ログに出がちな対象 | ざっくり役割 | Stopped／Started が出る典型要因 | 影響の出方（一般的） |
|---|---|---|---|
| Logic Apps JobHost | ワークフロー実行を動かすホスト（実行ランタイムの中核） | ホストプロセスのリサイクル、更新、ヘルスチェックによる入れ替え | 停止中はトリガー処理や実行が遅延/一時停止しやすい |
| runtime environment | Logic Apps Standard の実行環境（基盤側の実体） | App Service 側の再起動・スケール・メンテナンス | 環境再起動中は全体に影響（短時間） |
| Service Bus リスナー | Service Bus トリガー等の受信待機・接続管理 | ホスト再起動、接続の貼り直し、負荷変動に伴う再確立 | 停止中は受信が一時停止し、バックログが増えることがある |
| workflow | 個々のワークフロー（ロジック）実行単位 | ホスト再起動に伴う再ロード、設定反映、トリガー再初期化 | そのワークフローだけ遅延/一時停止のように見えることがある |
ポイント：Stopped／Started は「止められた」よりも「入れ替え（再起動）した」と捉える方が、運用判断を誤りにくくなります。
なぜ業務時間外に多いのか：夜間に起きやすい“入れ替え”の理由
「ほぼ毎日、主に業務時間外」というパターンは、運用現場でよく見かけます。理由はひとつではありませんが、代表的には次のような条件が重なります。
- 基盤のメンテナンス：夜間帯に行われることがあるため、入れ替えが集中しやすい
- スケールアウト/スケールイン：負荷が下がるとインスタンス数が減り、ホストやリスナーが貼り直される
- ヘルスチェックによるプロセス入れ替え：軽微な不調でも“健全化”のために再起動が走ることがある
- アイドル状態（アクセス/処理が少ない）：Always On が無効だと、スリープやコールドスタートに近い挙動が起きやすい
つまり、Stopped／Started の頻度だけで即「障害」とは断定せず、発生時刻・継続時間・同時に出る別ログ を合わせて判断するのが安全です。
「Stopped の間はオフライン？」に対する実務的な答え
質問として最も重要なのが、「Stopped と出ている間、Logic Apps は実際に止まっているのか？」です。実務的には次のように捉えると混乱が減ります。
- Stopped の対象が JobHost / runtime environment / リスナーの場合：処理が一時停止（または遅延）する可能性はあります。特にトリガーは“待ち受け”が切れるため、メッセージ取り込みが止まって見えます。
- ただし多くは短時間で Started が続く：自動で再起動し、再接続される前提の動きです。Stopped の文字だけで長時間停止と決めつけないのが重要です。
- Stopped の間に発生したイベントが“消える”とは限らない：Service Bus のようなキュー型は、受信側が止まってもメッセージは残るため、再開後に処理が追いつくことが多いです（その代わり遅延やバックログ増加が起きる）。
特に Service Bus トリガーの運用では、Stopped／Started の瞬間に次のような“現象”が起きやすいため、観測ポイントを決めておくと切り分けが速くなります。
| 現象 | 起きやすいタイミング | 見え方 | 実務的な判断 |
|---|---|---|---|
| 処理遅延 | Stopped〜Started の間、再接続直後 | 「受信が止まった」ように見える | バックログ増加→Started 後に回復するなら正常寄り |
| 一部実行の失敗 | 再起動瞬間に実行中の処理がある | タイムアウト、接続エラーなどが混ざる | 再試行で復旧するか、失敗が連鎖していないかを確認 |
| 重複処理に見える | 再試行・ロック切れなどが絡む | 同一メッセージ相当が複数回走る | ワークフローを冪等に設計（同一入力でも安全）する |
業務影響が疑われる場合の確認ポイント：見る順番がすべて
「Stopped／Started は通常動作」として扱いつつも、業務影響と時間帯が一致した日があるなら、次の順番で確認すると原因特定が早くなります。ここは運用手順として、そのままチェックリスト化するのがおすすめです。
Stopped→Started の“間隔”と“頻度”をまず見る
- Stopped と Started の差分（何分止まっていたか）
- 短時間に何回繰り返しているか（再起動ループの兆候）
- 同じ時刻帯に複数コンポーネントが同時に止まっていないか（環境全体の入れ替えの可能性）
App Service / 基盤側の“再起動・リサイクル”痕跡を突き合わせる
Logic Apps Standard は基盤として App Service を使うため、まずは基盤側のイベント（再起動・スケール）を確認します。見る場所の例は次のとおりです。
- Azure ポータルのアクティビティログ：該当リソース（Logic Apps Standard / App Service）で、再起動やスケール関連の操作・イベントが出ていないか
- 診断ログ：再起動やプラットフォームイベントに近いログが採れているか
- メトリクス：CPU/メモリのスパイク、インスタンス数の増減、エラー率の跳ね上がりがないか
Logic Apps の実行結果（成功率・遅延・再試行）を確認する
“ログが止まった”ことより、実際に処理結果がどうなったか が最重要です。以下を同じ時間軸で並べるのがコツです。
- 失敗した実行数（ワークフロー run の失敗）
- 実行時間の急増（通常より極端に長い run）
- 再試行回数の増加（外部接続、Service Bus、API 呼び出しなど）
Service Bus 側の“受信できなかった”証拠を確認する
Service Bus トリガーを使っている場合、Stopped／Started は「受信待機が一度切れた」ことを示すことが多いです。このとき Service Bus 側では次のような変化が出ます。
- Active Messages（アクティブメッセージ） の増加（バックログ）
- Dead-letter（デッドレター） の増加（処理できない/設定不整合）
- 失敗要求やサーバーエラーに相当するメトリクスの増加
| 確認対象 | 見るべき指標（例） | 判断のヒント |
|---|---|---|
| App Service / 基盤 | CPU、メモリ、インスタンス数、エラー率 | リソース逼迫→スケールや再起動のトリガーになりやすい |
| Logic Apps 実行 | 失敗数、実行時間、再試行回数 | 再試行で回復しているなら一過性、失敗が連鎖なら対策優先 |
| Service Bus | Active/Dead-letter、受信/送信の傾向 | バックログだけ増え、Started 後に減るなら遅延の可能性が高い |
Always On の役割：止まる理由を“ゼロ”にはできないが、夜間の停止を減らせる
Stopped／Started の要因が「アイドル・スリープ系」に寄っている場合、最も手堅い対策が Always On（常時オン） です。
Always On で何が改善するのか
- アクセスや処理が少ない時間帯でも、アプリのプロセスを起こし続ける
- 次のイベント到来時に“起動待ち”が起きにくくなり、コールドスタート由来の遅延 を減らせる
- Service Bus などのリスナーが「待受の再初期化」になりにくくなり、運用上の不安定さを抑えられる
Always On でも残るもの（期待値を合わせる）
Always On は万能ではありません。以下のような プラットフォーム都合の入れ替え は、Always On を有効にしていても起きる可能性があります。
- メンテナンス
- スケーリングによるインスタンスの増減
- ヘルスチェックによる入れ替え
- アプリ更新・構成変更の反映
Always On の設定場所（Logic Apps Standard）
Logic Apps Standard は App Service 基盤で動作するため、設定は App Service 側（Logic App リソースの設定画面） にあります。ポータル上では概ね次の導線で到達できます。
- Azure ポータル → 対象の Logic App (Standard)
- 設定（Settings）→ 構成（Configuration）
- 全般設定（General settings）付近の Always On を有効化
注意点として、Always On は App Service プランの種類によって利用可否が変わります。一般には Free / Shared では使えず、Basic 以上のプランで有効化できることが多いです（プラン制約は環境により異なるため、まずは現在のプランを確認してください）。
| 判断材料 | Always On を有効にする目安 | 期待できる効果 | 注意点 |
|---|---|---|---|
| 夜間に Stopped／Started が多い | アクセス/処理が薄い時間帯に偏っている | スリープ由来の停止・遅延の低減 | メンテナンス由来は防げない |
| 朝一の処理が遅い | 初回メッセージ受信で遅延が顕著 | コールドスタートの抑制 | プランのコスト/仕様を要確認 |
| Service Bus トリガーが重要 | 遅延が許容しづらいワークロード | 待受の安定化（体感） | それでも短時間の入れ替えは起こり得る |
“事前 or 早期に気づく”ための監視・通知：おすすめの組み合わせ
受信が止まったように見える問題は、発生してから追うと原因がぼやけやすいのが難点です。そこで、運用としては「プラットフォーム入れ替えの兆候」と「業務影響の兆候」を分けて監視し、通知のノイズを減らすのがコツです。
おすすめの監視設計（全体像）
| 監視レイヤー | 狙い | 具体例 | 通知の考え方 |
|---|---|---|---|
| プラットフォーム（Azure 側） | 計画メンテや広域障害を早く知る | Service Health / Resource Health のアラート | 運用チーム全体に通知（情報共有） |
| 基盤（App Service） | 再起動/スケール/エラー率の異常を検知 | メトリクスアラート、HTTP 5xx、リソース逼迫 | しきい値は“業務影響に直結するもの”に絞る |
| アプリ（Logic Apps 実行） | 失敗・遅延・再試行の増加を検知 | 失敗した run 数、実行時間の増加 | 最優先で通知（SLA に直結） |
| トリガー/メッセージ（Service Bus） | 受信停止・バックログ増加を検知 | Active/Dead-letter の急増 | “増え続ける”条件で通知（瞬間的増加はノイズ） |
Application Insights で Stopped／Started を“ログアラート化”する例
Stopped／Started 自体は正常でも、以下のような条件なら運用品質を上げるアラートになり得ます。
- 短時間に何度も繰り返す（再起動ループ）
- Stopped の継続時間が長い（再開しない、または回復が遅い）
- Stopped の直後に失敗 run が増える（業務影響の兆候）
ログ検索（Kusto クエリ）の雛形は、例えば次のような形で作れます（環境によりフィールド名が異なるため、まずは実際のログで列名を確認してください）。
traces
| where message has_any ("Stopped", "Started")
| where message has_any ("JobHost", "runtime", "Service Bus", "workflow")
| summarize Count=count() by bin(timestamp, 30m), message
| order by timestamp descそして、アラート条件は「Count が一定以上」「特定文字列を含む」「Stopped だけが続く」などにします。通知先は Action Group（メール、Teams 連携、Webhook など）で統一しておくと、運用の属人化を防げます。
“業務影響を早期検知”するアラートの作り方（実践寄り）
Stopped／Started の通知は便利ですが、通知が多すぎると無視されがちです。実務では「影響の兆候」側に寄せたアラートが効きます。
| アラート対象 | 推奨条件（例） | 狙い | 補足 |
|---|---|---|---|
| Logic Apps の失敗実行 | 失敗数が一定回数以上 / 連続失敗 | 業務影響の直接検知 | 通知レベルは高め（当番/即対応） |
| 実行時間の急増 | 通常の P95 を超過し続ける | 遅延の早期検知 | 「瞬間」ではなく「継続」で判定するとノイズが減る |
| Service Bus のバックログ | Active Messages が増え続ける | 受信停止・処理詰まりの検知 | 閾値はキューのSLAと処理速度から逆算する |
| Dead-letter の増加 | 短時間で急増 | 設定不整合/処理不能の検知 | 原因はアプリ側だけでなくルール/権限の可能性もある |
Stopped／Started に強いワークフロー設計：運用コストを下げる“予防策”
プラットフォームの入れ替えは完全には避けられないため、実務では「入れ替えが起きても事故になりにくい」設計に寄せるのが結果的に強いです。ここは一般論に寄りすぎない範囲で、効果が出やすいポイントをまとめます。
冪等性（同じ入力が来ても安全）を前提にする
Service Bus のようなメッセージ基盤では、再試行やロック切れ等により “同じメッセージが再度処理される” 可能性をゼロにはできません。Stopped／Started が絡むと、その確率が上がる局面があります。以下のいずれか（または複数）を検討すると安定します。
- 処理対象に 一意キー を持たせ、重複ならスキップする
- 外部システム更新は Upsert（存在すれば更新） に寄せる
- “二重実行で壊れる処理” を避け、壊れるなら 排他/ロック を設計する
“止まったら困る”トリガーは、遅延許容度を明文化しておく
Stopped／Started が毎日出ていても、業務側が「夜間の遅延は許容」「朝 10 分の遅延は許容不可」など、許容度が異なることがほとんどです。運用では次を決めておくと、アラート設計と切り分けが楽になります。
- 許容遅延（例：5分、15分、60分）
- 許容できないキュー滞留数（例：Active Messages が N を超えたら障害扱い）
- 当番対応の条件（例：失敗が連続 X 回、または Dead-letter が増加）
Always On＋監視＋設計の“セット”で効く
Stopped／Started の不安は、単発の設定だけでは完全に消えません。Always On で発生頻度を下げ、監視で早く気づき、設計で事故になりにくくする——このセットが最も再現性があります。
ドキュメントはどこを読めばよいか：調べる順番のおすすめ
「動作を説明したドキュメントがあるか？」という点については、1ページで“Stopped／Started の全て”がまとまっていることは少ない一方で、周辺ドキュメントを押さえると全体像が理解しやすくなります。探すときは、次の順番が実務的です。
- Azure Logic Apps Standard のアーキテクチャ/ランタイム：標準プランが App Service 基盤で動くこと、ホストの考え方
- 監視（Application Insights / Azure Monitor）：ログ・メトリクス・アラートの考え方、ログアラート（クエリアラート）の作り方
- App Service の Always On：スリープ抑制、プラン要件、運用上の注意点
- Service Bus トリガー/受信の挙動：再試行、ロック、デッドレターの基本（“止まったように見える”ときに何が起きるか）
- Service Health / Resource Health：プラットフォーム起因のイベント通知と、運用の初動判断
まとめ：Stopped／Started を“怖いログ”から“運用の計測点”へ
Logic Apps Standard の JobHost・runtime environment・Service Bus リスナー・workflow に出る Stopped／Started は、基本的に プラットフォーム側の通常ライフサイクル（リサイクル、メンテナンス、スケール、ヘルスチェック） の一部として発生し得るログです。多くは短時間で Started が続き、自動回復する前提の動きで、必ずしも長時間停止を意味しません。
一方で、業務影響と時間帯が重なる場合は「ログが出たか」ではなく、Stopped→Started の間隔、実行失敗・遅延、Service Bus バックログ を同じ時間軸で突き合わせるのが重要です。対策としては、Always On の有効化 による夜間のスリープ系挙動の低減、そして Azure Monitor / Application Insights / Service Bus / Service Health を組み合わせた アラート設計 によって、“起きてもすぐ気づき、影響を最小化する”運用へ寄せることができます。
コメント