はじめに
Genesys Cloudを触り始めて、「Architectでフロー作るの簡単そうだな」と思ったのが最初でした。
実際、画面も分かりやすく、ドラッグ＆ドロップでそれっぽいIVRが作れます。
ただ——
「設定は合っているはずなのに、なぜか思った通りに動かない」
- 設定は合っているはずなのに、なぜか違う動きをする
- どこが悪いのか分からない
こういった状況に何度もハマりました。
この記事では、実際に自分がつまずいたポイントをベースに、
初心者がハマりがちなポイントとその対処法をまとめます。
Architectとは簡単におさらい
Architectは、Genesys CloudでIVRやコールフローを設計する機能です。
- 着信時の案内
- 分岐（「1を押したら〜」）
- オペレーターへのルーティング
などをGUIで作成できます。
一見ノーコードで簡単そうですが、
中身はしっかりロジックが必要なので、ここが落とし穴になります。
Architectでは、このようにフローを組み立ててIVRを作っていきます。
ハマりポイント①：フローが思った通りに分岐しない
「1を押したらA、2ならB」と設定したのに、
なぜか意図しないルートに流れる…。
原因の多くは以下でした。
- 条件式の書き方ミス
- 変数がNullになっている
- 入力値の型が違う
例えば、入力値が取得できていない場合、
条件分岐はすべて外れてデフォルトルートに流れます。
👉 確認の流れ
- 変数に値が入っているか確認する
- Nullになっていないか確認する
- 条件式を見直す
ハマりポイント②：変数の型・スコープで混乱する
Architectでは変数の扱いがかなり重要です。
特に混乱したのがこのあたりです。
- StringとIntegerの違い
- Boolean（True/False）の扱い
- フロー変数とタスク変数の違い
例えば、数値で比較しているつもりでも、
実際はStringとして扱われていて条件が一致しない、というケースがありました。
👉 対策
- 型を明示的に意識する
- 必要なら変換関数を使う
- スコープ（どこで使えるか）を整理する
ハマりポイント③：デバッグが難しい
「なんで動かないのか分からない」
これが一番つらいポイントでした。
Architectは一般的なプログラミングのようなデバッガがないため、
動作確認が手探りになります。
👉 対策としてやったこと
- 途中で音声出力させて値を確認する
- テストコールを繰り返す
- フローを小さく分けて検証する
加えて、個人的によく使っていたのが
Participant Dataを使った値の確認です。
フロー内で設定した値をParticipant Dataに入れておくことで、
インタラクションの詳細画面から後追いで確認できます。
ハマりポイント④：ルーティング設定ミス
フローは正しいのに、エージェントに繋がらない。
これもかなりハマりました。
原因はArchitectではなく、
QueueやSkillの設定ミスだったりします。
- エージェントがQueueに所属していない
- スキル条件が厳しすぎる
- ステータスがAvailableでない
👉 対策
- Queue設定を確認
- エージェントの状態を確認
- スキル条件を一旦外して試す
ハマりポイント⑤：共通モジュール変更が反映されない
これ、個人的にかなりハマりました。
共通モジュール（再利用可能なフロー）を修正して、
「これでOK」と思ってテストしたのに——
なぜか変更が反映されない。
原因はシンプルで、
👉 呼び出し元のフローで新バージョンを選択してPublishし直していなかった
👉 確認の流れ
- 共通モジュールをPublishする
- 呼び出し元フローを開く
- 新バージョンの共通モジュールを選択
- フローを再Publishする
ハマりポイント⑥：Publishし忘れる
修正したのに動かない…と思ったら、
ただPublishしていなかっただけ
まとめ
Architectは見た目はシンプルですが、
実際はしっかりロジックを考える必要があります。
- 条件分岐
- 変数管理
- ルーティング設計
- モジュール依存関係
特に「見えない値」をどう確認するかを意識すると、
トラブルシュートのスピードはかなり変わります。