はじめに
Amazon Connect の「モジュール」は、フロー内で何度も使う処理を部品化して再利用するための仕組みです。公式ドキュメントでも、モジュールは「再利用可能なフローの一部分」として説明されています。
案件対応しているときに、以前はできなかった、コンタクトフロー以外でモジュールが呼び出せるようになっており、気になって調べてみました。
ただ、2026年4月時点で公式ドキュメントを確認すると、まだ次のように書かれています。
- 呼び出しモジュール ブロックは Inbound flow で利用可能
- Customer queue / Customer hold / Customer whisper / Outbound whisper / Agent hold / Agent whisper / Transfer to agent / Transfer to queue はモジュール非対応
- モジュールから別モジュールは呼び出せない
つまり、公式情報だけを読むと「モジュールは コンタクトフロー 専用」になります。
一方で、実際に自分の環境で試してみると、挙動が違って見えたので、この記事ではその検証結果をまとめます。
環境差分やロールアウト状況によって挙動が異なる可能性があるため、利用時は必ずご自身の環境でも確認してください。
この記事は公式仕様の断定記事ではなく、2026年4月時点の検証です。
この記事で伝えたいこと
今回確認したかったのは、次の2点です。
- これまで コンタクトフロー からしか呼べないと思っていたモジュールが、ほかのフロータイプからも呼べるのか
- モジュールから別モジュールを呼べるのか
結論
次のフローから「呼び出しモジュール（呼び出しモジュール）」を配置して利用できました。
- 顧客キューフロー
- 顧客保留フロー
- 顧客ウィスパーフロー
- 発信ウィスパーフロー
- エージェント保留フロー
- エージェントウィスパーフロー
- エージェントへの転送フロー
- キューへの転送フロー
さらに、モジュールから別モジュールを呼ぶ構成も動作確認できました。
ただし、無制限にネストできるわけではありません。
検証時には CloudWatch Logs に Max Nesting Limit For Modules [5] Exceeded というログが出力され、無限ループにはなりませんでした。
前提
- 構築環境
- AWS（Amazon Connect）リージョン：東京（
ap-northeast-1）
- AWS（Amazon Connect）リージョン：東京（
公式情報ではどう書かれているか
公式ドキュメント上では、呼び出しモジュール ブロックのフロータイプは コンタクトフロー とされています。
また、モジュールの説明ページでは、Customer queue / Customer hold / Customer whisper / Outbound whisper / Agent hold / Agent whisper / Transfer to agent / Transfer to queue は非対応、さらに Modules do not allow invoking another module と記載されています。
つまり、公式情報と実機確認の結果が食い違っているように見えます。
少なくとも私が確認した時点では、ドキュメント側はまだ従来の説明が残っているようでした。
今回の検証スタンス
今回は「正式にアナウンスされているか」ではなく、コンソール上で実際に置けるか、保存できるか、呼び出せるか を確認しました。
- 公式仕様として保証された話ではない
- 今後ドキュメント更新や正式アナウンスが出たら、そちらを優先すべき
実際に試したこと
1. コンタクトフロー 以外で 呼び出しモジュール を置けるか
まずは、従来「非対応」とされていたフロータイプで、呼び出しモジュール ブロックを配置できるかを確認しました。
結果として、以下のフローで ブロック配置・設定が可能でした。
- 顧客キューフロー
- 顧客保留フロー
- 顧客ウィスパーフロー
- 発信ウィスパーフロー
- エージェント保留フロー
- エージェントウィスパーフロー
- エージェントへの転送フロー
- キューへの転送フロー
少なくとも「コンソール上で選べない」「保存時に弾かれる」といった挙動ではありませんでした。
2. モジュールから別モジュールを呼べるか
次に、コンタクトフロー以外のフロータイプでも呼び出しができるのか。とモジュール A から モジュール B を呼ぶ。構成を作って確認しました。
実機上では 全てのフロータイプやモジュール → モジュール の呼び出しが成立しているように見えました。
無限ループはどうなったか
ここが一番気になったポイントでした。
今回は、あえて次のような構成を作りました。
- コンタクトフロー → モジュールA
- モジュールA → モジュールB
- モジュールB → モジュールA
つまり、A と B が互いを呼び合うループ構成です。
実際の実行イメージはこんな感じです。
- コンタクトフロー
- モジュールA
- モジュールB
- モジュールA
- モジュールB
- モジュールA
- その先で打ち止め
- モジュールA
- モジュールB
- モジュールA
- モジュールB
- モジュールA
この検証では、最終的にコンタクトフロー側の切断ブロックで通話終了になりました。
CloudWatch Logs には Max Nesting Limit For Modules [5] Exceeded が出ていました。
ここから読み取れるのは、
- モジュール同士の呼び出しはできる
- ただしネスト上限がある
- 無限再帰のような使い方は防がれている
ということです。
この結果から
ここは断定せずに、検証結果ベースで整理します。
まだ断定しないほうがよいこと
次の点はまだ慎重に扱ったほうがよいです。
- これが全リージョン・全テナントで同じとは限らない
そのため、業務で本番利用するなら、
「置けたからOK」ではなく、実行・エラー分岐・ログ確認まで含めてテストするのが安全です。
初学者向け：そもそもモジュールをどう使うと嬉しいのか
Amazon Connect を触り始めたばかりだと、「モジュールって何のために使うの？」となりやすいと思います。
モジュールは一言でいうと、よく使う処理を部品化するための仕組みです。
たとえば次のような処理を共通化したいときに向いています。
- 共通のアナウンス再生
- 入力値チェック
- 共通の属性設定
- 分岐前の前処理
- エラー時の共通ハンドリング
1つのフローの中に全部書くと、すぐに長くて読みにくくなります。
そこで、共通部分だけ切り出してモジュール化しておくと、見通しがよくなり、再利用しやすくなるのがメリットです。
今回の検証結果を踏まえた設計上の注意点
今回の挙動が使えるとしても、設計では少し気を付けたほうがよさそうです。
1. 相互呼び出しは避ける
A → B → A のような構成は、今回のように上限に引っかかる可能性があります。
たとえ動いても、後から見た人が理解しにくく、障害調査もしづらくなります。
おすすめは、親フロー → 共通モジュール群 のように、呼び出し方向を一方向にそろえることです。
2. 共通化しすぎない
モジュール化は便利ですが、細かく分けすぎると逆に読みづらくなります。
「複数のフローで本当に再利用する処理か？」を基準に切り出すのがよいと思います。
3. Error ブランチを必ずつなぐ
今回のように、ネスト上限や予想外の挙動にぶつかったとき、Error ブランチ未接続だと追いにくくなります。
最低でも、切断・案内・ログ確認の導線は用意しておくのがおすすめです。
4. CloudWatch Logs を前提に確認する
今回の Max Nesting Limit For Modules [5] Exceeded も、CloudWatch Logs を見ないと気づきにくい情報でした。
Amazon Connect のフロー検証では、コンソール上の見た目だけでなくログも見るのが大事です。
まとめ
今回の検証では、以下の気づきがありました。
- 従来は非対応と認識していた複数のフロータイプで 呼び出しモジュール を使えた
- モジュール → モジュール の呼び出しもできた
- ただし
Max Nesting Limit For Modules [5] Exceededがあり、無限ループはできなかった
一方で、2026年4月時点の公式ドキュメントでは、まだ
- コンタクトフロー のみ
- 対象外フローあり
- モジュールから別モジュールは呼べない
という説明が残っています。
そのため、現時点では
公式ドキュメントとのズレがあるため、本番利用前には必ず実機確認をおすすめする。
同じように試した方がいたら、ぜひ挙動を共有いただけるとうれしいです。