はじめに

Azure Logic Appsでワークフローを構築する際、多くの開発者が直面するのが「タイムアウト」エラー、特にHTTPアクションの「2分の壁」です。

この記事では、タイムアウトが発生する根本的な原因から、その「2分の壁」を乗り越えるための2つの実践的な設計パターン、そしてワークフローを安定させるためのリトライ戦略まで、具体的な実装例を交えて徹底解説します。

この記事を読めば、タイムアウトを正しく理解し、安定的で堅牢なワークフローを自信を持って設計できるようになります。

1. Logic Appsの基本的なタイムアウト

まず、最も基本となるコネクタのアクションにおけるタイムアウトです。これは、Logic Appsが特定のアクション（例：「メールを送信する」「ファイルを作成する」）を実行し、その応答を待つ最大時間です。

デフォルトのタイムアウト値

ほとんどのコネクタのアクションでは、デフォルトのタイムアウトは2分に設定されています。通常はこれで十分ですが、処理に時間がかかるシステムと連携する場合、このデフォルト値が原因でエラーになることがあります。

タイムアウトの確認と設定変更

タイムアウト値は、各アクションの設定から簡単に確認・変更できます。

変更したいアクションをクリックします。
表示されたメニューから「設定」（「Setting」）を選択します。
「タイムアウト」（「Action timeout」）の項目で現在の設定値を確認できます。

設定値はISO 8601期間形式で指定します。少し難しく感じるかもしれませんが、パターンは簡単です。

PT120S : 120秒 (デフォルト)
PT5M : 5分
PT1H : 1時間
P1D : 1日

💡 実例：Teamsへの通知がタイムアウトするケース

例えば、Teamsの「チャットまたはチャネルでメッセージを投稿する」アクションを実行する際に、Teams側のサービスが一時的に高負荷になっていると、応答が2分以内に返ってこない可能性があります。その結果、Logic Appsはタイムアウトエラーとなります。もしこのような状況が稀に発生し、5分待てば成功するのであれば、タイムアウトを PT5M に延長することで、ワークフローの安定性を高めることができます。

2. 長時間処理のタイムアウトを回避する2つの設計パターン

Logic Appsで外部API連携や複雑な処理を行う際、2分のタイムアウトは大きな壁となります。ここでは、その壁を乗り越えるための代表的な2つの設計パターンを解説します。

非同期パターンの限界：なぜ2分でタイムアウトするのか？

まず前提として、HTTPアクションなどは既定で非同期パターン =Asynchronous Patternで動作します。これはリクエストを投げた後、相手からの応答を待ち続ける動きのため、従量課金プランでは最大120秒でタイムアウトしてしまいます。

実例：処理時間が2分を超えるHTTPアクションの呼び出し

呼び出し元
呼び出し先

3分かかる子Logic Appを呼び出すと、（Action timeoutを延ばしたとしても）必ずタイムアウトします。この問題を解決するのが、これから紹介する2つの方法です。

方法1：【推奨】入れ子のLogic Appsワークフローで処理を分割する

この方法は**「複数の処理から成るプロセス全体」が長い**場合に特に有効で、最も柔軟性が高いアプローチです。

なぜこの方法が推奨か？

呼び出し先のAPIやシステムが特別な仕組み（Webhookなど）に対応している必要がなく、Logic Appsの機能だけで完結できるためです。また、複雑な処理を機能単位で別のワークフローに分割することで、管理や再利用がしやすくなるという大きなメリットもあります。

長時間かかる処理を別の子ワークフローとして作成し、メインの親ワークフローから呼び出します。

処理の流れ：

親Logic App: Azure Logic Appsコネクタの「ワークフローの選択 (Choose a Logic Apps workflow)」アクションを使って、子ワークフローを非同期的に呼び出します。
子Logic App: 時間のかかる一連の処理を実行します。子ワークフローはステートフルで作成すれば、最大90日間実行可能です。
子Logic App: 処理が完了したら、「応答 (Response)」アクションで親ワークフローに結果を返します。

実装

呼び出し元
呼び出し先

方法2：Webhookパターン（HTTP Webhookアクション）

こちらは、「単一のAPI呼び出し」が長時間かかる場合に有効な方法です。呼び出し先側から処理完了をLogic Appsに通知してもらう、効率的な仕組みです。

処理の流れ：

呼び出し元 → 呼び出し先: 処理のリクエストと共に、「処理が終わったらこのURLに通知して」というコールバックURLを渡します。Logic Appsはここで一時停止します。
呼び出し先: 長時間処理を実行し、完了したらコールバックURLに結果を送信します。
呼び出し元: コールバックを受け取り、ワークフローを再開します。

このパターンは、「HTTP Webhook」アクションを使用することで実装できます。ただし、呼び出し先のシステムがWebhook（コールバック）に対応している必要があるという前提条件があります。

実装

呼び出し元
呼び出し先

3. タイムアウト発生時の挙動と対策

タイムアウトは、発生させない工夫も重要ですが、発生してしまった場合にどう対処するかも同じくらい重要です。

再実行（リトライ）ポリシー

一時的なネットワークエラーやビジー状態のAPIに応答するため、Logic Appsにはアクションが失敗した際に自動で再試行する「リトライポリシー」機能があります。

既定 (Default)
- 何も設定しない場合のデフォルトの動作です。
- 指数間隔 (Exponential Interval) アルゴリズムを使用し、最大4回のリトライを行います。
指数間隔 (Exponential Interval)
- リトライ間隔が指数関数的に増加する点は「既定」と同じですが、回数や間隔を細かくカスタマイズできます。
固定間隔 (Fixed Interval)
- 指定したリトライ回数と間隔で、常に同じ時間待ってから再試行します。
なし (None)
- リトライを行いません。アクションが一度失敗すると、即座に失敗として扱われます。

使い分けのヒント 💡

指数間隔 (既定を含む): 最も汎用性が高く、ほとんどのケースで推奨されます。外部APIが一時的に高負荷になったり、スロットリング（利用制限）を受けたりした場合に、徐々に間隔を空けて再試行することで、相手のシステムに負荷をかけずに復旧を待つことができます。
固定間隔: 失敗の原因が一定時間で確実に解消されると分かっている場合（例：特定のリソースロックが必ず10秒で解除されるなど）に有効です。それ以外のケースでは、無駄なリトライで相手のシステムに負荷をかけ続ける可能性があるため、あまり推奨されません。
なし: 処理の再実行が許されない場合（例：重複が許されないデータを作成する処理）や、失敗した場合は即座に別のエラー処理に移行させたい場合に選択します。

タイムアウトを捕捉するエラーハンドリング

リトライしても最終的にタイムアウトしてしまった場合、ワークフローを異常終了させるのではなく、エラー処理の経路に処理を継続させることが可能です。

Configure run after (実行条件の構成): アクションの...メニューから設定でき、「(前のアクションが)失敗しました」「タイムアウトしました」の場合に次のアクションを実行するよう指定できます。

実例：HTTPアクション異常時

先行操作が [失敗、[スキップ]、または [タイムアウト] の状態で完了した場合にのみ現在の操作を実行するように指定するには、これらの状態を選択し、既定の状態をクリアします。

4. 見落としがちなタイムアウトの知識

アクション単体だけでなく、ワークフロー全体に関わるタイムアウトの知識も押さえておきましょう。

トリガーのタイムアウトとポーリング

ポーリングトリガー: 「HTTPトリガー」のようなトリガーは、定期的に変更がないかチェックしに行きます。このチェック間隔が意図通りか確認しましょう。
タイムアウト: トリガー自体の処理が長時間かかると、実行がスキップされる可能性はあります。（HTTPトリガーの場合120秒）

ワークフロー全体の実行時間上限

ステートフル（既定）: 実行履歴が保存される通常のワークフロー。実行期間の上限は90日など非常に長いです。
ステートレス: 実行履歴を保存せず、パフォーマンスを重視したワークフロー。実行時間の上限は5分と非常に短いため、長時間処理には向きません。

5. 監視とアラート

問題が発生したときに迅速に対応するため、監視は欠かせません。

Azure Monitorを活用したタイムアウトエラーの監視

Azure Monitorを使えば、Logic Appsの実行状況を監視し、特定のエラー（ActionTimeoutなど）が発生した際にアラートを発行できます。

診断設定: Logic AppsのログをLog Analyticsワークスペースに送信します。
アラートルール: Log Analyticsで特定のクエリを条件にアラートルールを作成し、通知を受け取れます。

おわりに

今回はAzure Logic Appsのタイムアウトについて、基本的な設定から回避パターン、エラーハンドリング、監視まで幅広く解説しました。

タイムアウトを単なるエラーとして捉えるのではなく、ワークフローの設計を見直す良い機会と捉え、今回紹介した非同期パターンやワークフロー分割などのテクニックを駆使して、より堅牢なシステムを構築していきましょう。