ワークフロー

ワークフローは会話を視覚的に表したマップです。適切な質問を適切な順序で行うことをFinnに任せる代わりに、フローチャートのように流れを自分で描き、Finnがそれに従います。

率直に言うと: ほとんどの場合、ワークフローは必要ありません。ユースケースの80%では、自由形式モード（適切なアイデンティティ・スタイル・ナレッジベースだけ）のほうがうまく機能し、メンテナンスもはるかに簡単です。特定の順序や分岐を強制する明確な理由がある場合にのみ、ワークフローを作成してください。

必要かどうかの見分け方: Finnに「Yよりも先にXを実行すること」と何度も指示しているのに、うまくいかない場合です。あるいは、一字一句そのまま読み上げる必要のあるコンプライアンス用スクリプトがある場合や、会話に明確な分岐点がある場合（「Aと言われたらこうする、Bと言われたらああする」）です。

具体例で理解する

救急クリニック向けの受付Finnを作るとします。会話では次のことを、この順序で行う必要があります。

1. 発信者に挨拶し、本当に医療上の相談かどうかを確認する（当社からのテストコールではないこと）。
2. 氏名と生年月日を尋ねる。
3. どのような症状があるかを尋ねる。
4. 症状の重症度を1〜10のスケールで尋ねる。
5. 重症度が8以上の場合は、直ちにオンコール医師に転送する。
6. 重症度が4〜7の場合は、当日の予約を取る。
7. 重症度が4未満の場合は、通常の予約を取る。
8. HIPAAに関する開示事項を読み上げる。
9. 通話を終了する。

これがワークフローです。各ステップがノードになります。「重症度がXの場合」という部分は分岐する判断ノードです。フローは強制されるため、Finnが開示事項を読み飛ばしたり、重症度を確認する前に予約を取ったりすることはありません。

エディタを開く

ダッシュボードのサイドバーから、View All Finn → 対象のFinnをクリック → Edit Workflow をクリックします。

エディタが全画面で開き、次の要素が表示されます。

• 中央の空のキャンバス（既存のワークフローがある場合はそれが表示されます）
• ドラッグして追加できるノードタイプが並ぶ左側のツールバー
• 大きなフローを移動するための右下のミニマップ
• 右上の保存／テストボタン

初めてワークフローを作成する場合、キャンバスには Start ノードだけがある状態から始まります。そこから作り込んでいきます。

構成要素

ノードタイプは6種類あります。キャンバスにドラッグしたうえで、エッジで接続します（ノードの端から次のノードへドラッグします）。

Start

すべてのワークフローに必ず1つだけ存在します。通話はここから入ります。

開始メッセージはStartノードで設定できます。空欄のままにして、Finnの通常のウェルカムメッセージに任せることもできます。

Say

Finnが何かを話します。発話のみで、質問も待機もしません。

例: 「ありがとうございます。必要な情報はすべて揃いました。明日の午後3時にお待ちしております。」

Sayノードは、確認・開示事項・セクション間のつなぎに使います。

{{contact.name}}（オーディエンス行のデータ）や {{state.appointment_time}}（同じ通話内でFinnが先に収集したデータ）を使って、動的なコンテンツを差し込めます。

Ask

Finnが質問し、回答を待ちます。

設定する項目:

• 質問内容 — 「生年月日を教えていただけますか？」
• 期待する回答の種類 — 自由記述、はい/いいえ、数値、日付、列挙型（複数の選択肢から1つ）。
• 回答の保存先 — dob や severity のような変数名を付けます。この名前は後で使用します。
• 回答が意味を成さない場合の処理 — 再質問する、中止して人間に転送する、など。

判定

分岐です。Finn が把握している情報（保存された変数、または発信者が直前に話した内容）に基づき、どの経路を進むか選択します。

3種類あります:

• 単純比較 — 「severity が 8 以上なら ER ノードへ」。数値、はい/いいえ、明確な列挙型がある場合に使用します。
• 列挙型マッチ — 「intent が 'cancel' なら cancel ノードへ」。特定のカテゴリを収集した場合に使用します。
• AI 判定 — 「発信者は苛立っていたか?」。チェックできる明確な値がない場合に、AI に判断を委ねます。

アクション

副作用です。Finn が発話するだけでなく、実際に何かを実行します。

主なもの:

• カレンダー予約 — 連携済みカレンダーにイベントを追加します。
• 通話転送 — 実際の担当者に引き継ぎます。
• CRM 更新 — HubSpot/Salesforce/Pipedrive のフィールドに書き込みます。
• SMS 送信 — フォローアップのテキストメッセージを送信します。
• Webhook — 自社の URL を呼び出します（リアルタイムのデータ参照に便利。連携 を参照）。

終了

通話を終了します。

End ノードは複数持てます — 通話の終わり方ごとに1つずつ。「予約で終了」「転送で終了」「拒否で終了」。複数の終了を用意すると、それぞれが分析上の個別カテゴリになるため便利です。

エディタの基本

キャンバスは一般的な作図ツールと同じように動作します。

自動保存はデフォルトで無効です。 保存を忘れないでください。編集途中の状態で良好な状態を上書きするリスクを避け、コミットのタイミングをご自身で選べるようにしています。

変数 — フロー内でのデータの受け渡し

最初につまずきやすい部分です。少し時間をかけて理解してください。

Ask ノードが回答を収集すると、その回答は変数になります。Action ノードがデータを返す場合（例: Book Calendar アクションが予約時刻を返す）も同様に変数になります。変数は通話全体を通じて保持されます。

二重波かっこで参照します:

• {{contact.name}} — この通話の対象となるオーディエンス行から取得されます
• {{state.severity}} — severity に保存した Ask ノードで収集されます
• {{state.appointment_id}} — Book Calendar アクションが返します

Say ノード、Ask ノードの質問文、Action ノードのパラメータ、Decision ノードの条件など、どこにでも挿入できます。

Say ノードの例:

「承知しました、{{contact.name}}さん。{{state.appointment_time}} でご予約しました。確認は {{contact.phone_number}} にお送りします。」

作りながらテストする

ワークフロー全体を完成させなくてもテストできます。方法は 2 つあります:

Test on Chat — ブラウザ上でテキストベースのシミュレーターが開きます。メッセージを入力して Finn の応答を確認できます。各ノードの入力と出力がリアルタイムで表示されるため、どの分岐で問題が起きたか正確に把握できます。

Test on Call — 自分の電話に発信します。エンドツーエンドで実際に近い形で確認できます。実ユーザー向けに公開する前に使用してください。

小さな単位で作る → テスト → 作る → テスト、を繰り返します。最初から全体を設計しようとしないでください。

フローで問題が起きたとき

よくあるパターンと対処法:

「発信先が想定外の発言をしてワークフローが止まった」

最も多い問題です。実際の通話相手は、Ask ノードが想定する形式では回答しません。

対処: すべての Ask ノードにフォールバックエッジを追加します。フォールバックは回答を解析できないときに発火し、再質問、丁寧な終了、フローの別の箇所へのジャンプが可能です。

補足: Ask ノードを「完全一致」から「AI 判定」に切り替えることも検討してください。言い換えられた回答をモデルが解釈できるようになります。

「Finn の話し方が機械的」

ワークフローが Say ノードの連続ばかりだと、会話に余白がありません。

対処: 自由会話の合間を挟みます。End ノードには自由会話へ引き継ぐオプションがあり、これが実行されると Finn はワークフローを抜け、通常の Identity とナレッジベースを使って残りの通話を会話形式で続けます。

ワークフローは必須の部分を確実に進めるのに適しています。それ以外は自由会話が適しています。両者を組み合わせてください。

「変数がトランスクリプトに {{state.x}} のまま表示される」

変数名の入力ミスです。Say ノードは {{state.severity}} を参照しているのに、Ask ノードは severity_score に保存しています。完全に一致させてください。

「大きなワークフローでエディタが重い」

30 ノードを超えるあたりから動作が重く感じられます。

対処: サブフローを Group ノードにまとめます（Pro プラン）。または Transfer ノードでつないだ複数の Finn に分割します。

バージョン管理 — ワークフロー単位で元に戻す

保存するたびに新しいバージョンが作成されます。新規デプロイメントには現在のバージョンが使われます。稼働中のデプロイメントは、開始時のバージョンで動作し続けます。

ロールバックするには: Edit Workflow → History → バージョンを選択 → Restore をクリックします。復元したバージョンが現在のバージョンになります。

ワークフローを見て「前は動いていたのに」と思ったら、諦める前に履歴を確認してください。

ワークフローの共有と再利用

ワークフローはJSON形式でエクスポートできます。用途:

• あるFinnから別のFinnへワークフローをコピーする(開発用アカウントから本番アカウントへのコピーも可)
• プラットフォーム外でワークフローをバージョン管理する(JSONをgitにコミット)
• テンプレートとなるワークフローをチームで共有する

エクスポート方法: ワークフローを編集 → ⋯ メニュー → JSONとしてエクスポート。

インポート方法: ワークフローを編集 → ⋯ メニュー → JSONからインポート。

ワークフローを使うべきでない場面

次の用途にはワークフローを使わないでください:

• 単純な質疑応答。 自由形式とナレッジベースの組み合わせのほうが適しています。
• 「Xについて自然に会話する」。 自由形式が適切です。
• ディスカバリーコール。 会話の展開を事前に予測できないため、モデルに任せます。

ワークフローが適している場面:

• コンプライアンス上の制約がある台本(開示事項、必須の言い回し)。
• 複数ステップの受付フォーム(特定の項目を特定の順序で収集)。
• 振り分け(最初の回答内容に応じて通話をルーティング)。
• 「必ず」「この順序で」という言葉で説明したくなるもの全般。

次のステップ

• Finnの作成 → — ワークフローの土台となる基本事項。
• 連携機能 → — アクションノード内でできること。
• ボイス&パーソナリティギャラリー → — ワークフローを使わずに構築された事例。