プロシージャは、現在ベータ版として提供しております。正式リリース(2026年12月中を予定)時、画面や機能の一部が変更される場合があります。
プロシージャは、業務の手順を文章で記述するだけで、ALFが顧客と会話しながら業務を処理できる機能です。同僚に業務を引き継ぐように、「通常はこの手順で進め、顧客からこのような回答があった場合は、こう対応する」といった内容を、問い合わせ対応マニュアルのように記述するだけで設定できます。
顧客がすでに伝えた情報は、再度質問せずに活用します。
不足している情報のみを質問します。
顧客が回答を変更した場合は、関連する情報を再確認します。
注文情報の照会、タグの追加、オペレーターへの接続など、必要なツールを指示文に直接組み込むことができます。
機能 | 作成方法 | 活用場面 |
|---|---|---|
プロシージャ | 特定の状況に応じた業務手順を、文書を作成するように記述します。 | 決まった手順はあるものの、顧客との会話に応じて柔軟な判断が必要な場合 |
タスク | ノードと線をつなげてフローを作成し、設定した経路に沿って実行します。 | 段階的な承認など、実行する経路を固定する必要がある場合 |
タスクは引き続き利用でき、プロシージャとの併用も可能です。実行する経路を固定する必要がある業務には、タスクを活用しましょう。
ノード数が多く、分岐や例外処理が複雑な受付業務のタスク(修理・交換・返品、キャンセル・返金など)を運用している場合
ルールに複雑な問い合わせ対応のフローを記述している場合
顧客が必要な情報を順不同で伝えたり、途中で依頼内容を変更したりする問い合わせが多い場合
プロシージャを利用するには、以下の条件をすべて満たす必要があります。
Startupプラン以上を利用していること
チャネルワークスAIエディションを利用していること
※SaaSエディションでは利用不可
ベータテスターに申請し、承認されているチャネルであること
Startupプランでは、稼働中のプロシージャを最大10件まで利用できます。Businessプラン以上のプランでは、件数の制限はありません。
[サポート] - [ALF] - [設定] - [プロシージャ] で [ベータテストに申し込む] をクリックします。
申請が承認されると、順次チャネルに適用されます。
[顧客] - [サポート] - [ALF] - [設定] - [プロシージャ] で [+新規作成] をクリックします。
編集画面上部の「いつ開始しますか？」で、プロシージャをいつ、誰に、どのサービスで適用するかを設定します。
項目 | 説明 |
|---|---|
いつ開始しますか？ | プロシージャが必要となる状況を文章で記述します。最大5,000文字まで入力できます。(例：顧客が決済済みの注文のキャンセルを希望する場合) |
フィルタリング | [+フィルター追加] から、特定の顧客(例：VIP顧客)や特定の問い合わせ(例：特定の問い合わせタグが付いている場合)にのみ適用するよう設定します。 |
動作サービス | プロシージャを適用するテキスト形式の問い合わせチャネルを選択します。現在、電話(ボイスALF)には対応していません。 |
「いつ開始しますか？」は、特定のキーワードが含まれているだけで必ず実行されるものではありません。公開済みのプロシージャのうち、フィルター条件を満たすものから、ALFが会話の内容に適したプロシージャを選択して実行します。
「何をしますか？」で、業務手順をセクションごとに分けて記述します。
セクションとは、「依頼の受付」「顧客確認と注文照会」「キャンセル受付」など、業務手順をわかりやすく整理するための単位です。
セクションの種類 | 説明 |
|---|---|
セクション | 実行する業務を順番に記述します。顧客が回答を変更した場合は、前のセクションに戻って再確認することもできます。 |
呼び出し専用セクション | 複数の場面で繰り返し使用する共通の手順(例：オペレーターへの接続、キャンセル失敗時の対応)を別途作成し、必要に応じて呼び出すことができます。実行が完了すると、元の指示文の続きに戻ります。 |
左側の一覧で [セクション] または [呼び出し専用セクション] の横にある [+] をクリックするか、[+セクション追加] ボタンをクリックして追加します。
[指示文の作成のコツ] を参考し、ALFが意図通りに業務を処理するように、指示文を作成してみましょう。
指示文の作成中に @ を入力すると、業務に必要なツールを追加できます。追加したツールは、指示文内にチップ形式で表示されます。
ツール | 利用場面 | 注意事項 |
|---|---|---|
メッセージ送信 | 定型文をチャットでそのまま送信する場合 | ファイル・ボタン・Webページの添付や変数を使用できます。ALFのボットプロフィールから送信されます。 |
SMS送信 | 顧客の携帯電話にSMSを送信する場合 | メッセージを直接作成するか、ALFに生成させるかを選択できます。添付できるのは画像のみで、送信ごとに料金が発生します。 |
条件分岐 | 状況に応じて対応を変える場合 | 下記の「条件分岐」を参照します。 |
セクション移動 | 顧客が回答を変更した場合や、途中の手順をスキップする場合 | 移動先のセクションから処理が続き、元の位置には戻りません。 |
セクション呼び出し | 繰り返し使用する手順を再利用する場合 | 呼び出し専用セクションを実行した後、元の位置に戻ります。呼び出し専用セクション内では、他のセクションへの移動や別のセクションの呼び出しはできません。 |
プロフィール読み取り | 顧客・問い合わせ・チャネル情報やメモリの値を参照する場合 | チャネル情報から営業時間を取得できます。営業時間に応じて対応を変える場合は、条件分岐と組み合わせて活用できます。 |
プロフィール更新 | 取得した値をプロフィールやメモリに保存する場合 | 更新できるのはString・Number・Boolean型のみです。チャネル情報は変更できません。 |
メモリ | プロシージャ内でのみ使用する一時的な値を定義する場合 | プロシージャが終了すると値は消去され、プロフィールには保存されません。 |
アプリ | インストール済みのアプリの機能を呼び出す場合(例：Shopifyの注文照会) | 関数を直接選択するか、ALFに選択させることができます。実行結果はプロフィールやメモリに保存できます。 |
カスタム関数 | 外部APIの呼び出しなどを関数として作成し、再利用する場合 | 関数を直接選択するか、ALFに選択させることができます。 |
コード実行 | 値の検証、複雑な条件の判定、外部との通信が必要な場合 | プロシージャ内で作成したコードブロックを実行します。コードブロックはプロシージャごとに最大30個まで作成できます。 |
問い合わせアクション | チーム・担当者・フォロワー・タグを指定する場合 | — |
問い合わせを開く | オペレーターに対応を引き継ぐ場合 | ALFによる対応が終了し、受信トレイに問い合わせが入ります。 |
プロシージャ終了 | 実行中のプロシージャのみを終了する場合 | プロシージャが終了しても、ALFによる対応は継続します。 |
条件分岐
条件分岐は、「どのような状況で、何を実行するか」を設定するツールです。条件を記述し、[Then] の下にその条件を満たした場合に実行する処理を記述します。
条件は、右側の形式選択メニュー(例：[自然言語])から、2つの形式のいずれかを選択して記述できます。
形式 | 作成方法 | 例 |
|---|---|---|
自然言語 | 条件を文章で記述します。ALFが会話の内容をもとに判断します。 | 顧客が返金を希望する場合 |
フィルター | 顧客・問い合わせ情報やメモリの値を使って比較条件を設定します。 | 注文ステータス = 配送中 |
1つの条件グループで使用できる形式は1種類のみです。形式を変更すると、設定済みの条件が削除されるため、ご注意ください。
条件内で使用できるツールは、[プロフィール読み取り] のみです。
区分 | 意味 | 説明 |
|---|---|---|
IF | もし〜なら | 最初に判定する条件です。条件分岐は必ずIFから始まります。条件に該当する場合は、[Then] に設定した処理を実行し、それ以降の条件は確認しません。 |
ELSE IF | そうでなく、〜なら | 上の条件に該当しない場合に判定する条件です。必要な数だけ追加でき、上から順番に判定します。省略することもできます。 |
ELSE | それ以外の場合 | いずれの条件にも該当しない場合に実行します。条件は設定せず、実行する処理のみを記述します。省略することもでき、省略した場合は次の指示に進みます。 |
例）キャンセル可否の確認
順序 | 条件 | Then (実行する処理) |
|---|---|---|
IF | 注文ステータスが「入金前」の場合 | そのままキャンセルを受け付けます。 |
ELSE IF | 注文ステータスが「発送準備中」の場合 | キャンセル依頼を受け付け、確定までに時間がかかることを案内します。 |
ELSE IF | 注文ステータスが「配送中」の場合 | キャンセルが難しいことを伝え、返品方法を案内します。 |
ELSE | (条件なし) | [セクション呼び出し：オペレーターへの接続] を実行します。 |
「入金前」の注文： IFの条件に該当するため、そのままキャンセルを受け付けます。それ以降の条件は確認しません。
「配送中」の注文： 2つ目のELSE IFの条件に該当するため、返品方法を案内します。
「配送完了」の注文： いずれの条件にも該当しないため、ELSEに従ってオペレーターに接続します。
注意事項
条件を上から順番に判定し、最初に該当した条件の処理のみを実行します。 複数の条件に該当する場合も、上にある条件が優先されるため、より具体的な条件を上に配置します。
条件の判定に必要な情報が不足している場合は、条件に該当しないと判断せず、必要な情報を先に確認します。注文照会など、条件の判定に必要な処理は、条件分岐の前に配置します。
条件分岐の中に別の条件分岐を設定する「ネスト構造」には対応していません。複数の条件を組み合わせて判定する場合(例：会員かつ配送中の場合)は、1つの条件にまとめ、ELSE IFとして設定します。
「プロシージャメモリ」は、プロシージャの実行中に一時的に保持される値です。プロシージャが終了すると値は消去され、顧客・問い合わせのプロフィールには保存されません。設定したメモリは、プロシージャ内で読み取りや更新ができます。
画面左下の [メモリ] をクリックします。
[+メモリ追加] をクリックします。
キー・タイプ・説明を入力します。
項目 | 説明 | 入力例 |
|---|---|---|
キー | 指示文内でメモリを呼び出す際に使用する名前 |
|
タイプ | 保存する値の形式。初期設定はString型です。 | 一覧から選択 |
説明 | メモリに保存する値の内容を記述します。 | 顧客の注文一覧 |
対応しているデータ型
タイプ | 保存する値の例 |
|---|---|
String | 文字列(例：交換理由) |
Boolean | 真偽値(例：会員かどうか) |
Number | 数値(例：キャンセル数量) |
Date / Datetime | 日付 / 日時(例：注文日) |
List / List Of Number | 複数の文字列 / 複数の数値(例：りんご、バナナ、ぶどう / 1、2、100) |
Object / List Of Object | 複数の情報をまとめた値 / その値のリスト(例：1件の顧客情報 / 複数の注文商品情報) |
顧客が回答を変更しても、保存済みの値は自動的に削除されません。
[プロフィール更新] ツールで値を保存できるのは、String・Number・Boolean型のみです。List・Objectなどの型は、アプリの実行結果をメモリに保存する際に活用します。
問い合わせ終了後も値を保持する場合は、メモリではなく [プロフィール更新] ツールを使用して、顧客・問い合わせ情報に保存します。
右側のパネルにある [プレビュー] で、実際の会話を想定して動作を確認します。
テストが完了したら、画面右上の [実行] をクリックします。作成した内容は自動保存されますが、実際の問い合わせに適用するには公開が必要です。
プレビュー中は料金が発生しません。保存前でもテストできます。
参照先の誤りや未対応の機能などのエラーがある場合、プレビューを開始できません。まずはエラーが発生している箇所を確認します。
プレビュー開始後に内容を修正しても、実行中のプレビューには反映されません。プレビューを再度開始すると、最新の内容で動作を確認できます。
修正内容は、実行後に新しく開始された問い合わせから適用されます。
すでに進行中の問い合わせには、開始時点の内容が引き続き適用されます。
[ステータス] と [サービス] のフィルターで、表示するプロシージャを絞り込めます。
画面上部の検索欄から、タイトルでプロシージャを検索できます。
[フォルダを作成] から、国・ブランド別など、任意の基準でプロシージャを分類できます。
フォルダは1階層のみ作成できます。
フォルダ内に稼働中のプロシージャがある場合、そのフォルダは削除できません。
自動保存と公開の履歴がそれぞれ記録され、過去の内容を復元できます。
公開中のプロシージャは、画面上部の [修正内容を見る] から編集中の内容を確認できます。
一覧画面では、プロシージャごとの実行数・完了率・解決率と、前の期間からの増減を確認できます。データは直近7日間を対象とし、その前の7日間との比較も表示されます。
より詳しいデータは、公開済みのプロシージャを開き、[分析] タブから確認できます。
画面上部で集計期間(例：直近7日間)と [サービス] を選択します。
項目 | 説明 |
|---|---|
プロシージャの内容要約 | 開始条件、処理内容、セクション構成を要約して表示します。 |
実行数 | プロシージャが開始された回数です。 |
完了率 | プロシージャが設定した手順どおりに完了した割合です(解決＋設計どおりのオペレーター接続)。実行結果は「解決」「設計どおりのオペレーター接続」「設計外のオペレーター接続」の割合に分けて表示されます。 |
解決率 | オペレーターに接続せずに解決した割合です。 |
プロシージャ処理ファネル | 実行されたプロシージャがどのような結果で終了したかを、段階別に表示します。 |
プロシージャ実行 → プロシージャ完了： 設定した指示どおりに処理が進んだ場合
プロシージャ解決： オペレーターに接続せずに終了した場合
設計どおりのオペレーター接続： 指示文に従ってオペレーターに接続した場合
プロシージャ実行 → 設計外のオペレーター接続： 顧客からの要望や処理できない状況などにより、指示文で想定していないオペレーターへの接続が発生した場合
最終段階では、結果を「ポジティブ」「ニュートラル」「ネガティブ」「評価対象外」「評価中」に分類して表示します。評価は、ALFの最後の回答から24時間が経過した後に確定します。
プロシージャは、ALFが指示文をもとに判断して処理を進めるため、すべての問い合わせが同じ文章や手順で進行するとは限りません。重要な処理については、実際の照会結果や実行結果を確認します。
関数・コード・SMS送信を同じ入力内容で再実行すると、処理が重複する可能性があります。重複送信や重複更新が自動的に防止されるとは限りません。
外部処理に失敗した場合、ALFは失敗を認識し、指示文に従って対応します。自動での再試行やオペレーターへの接続は行われないため、失敗時の対応を指示文に記述します。(例：呼び出し専用セクション「キャンセル失敗時の対応」を呼び出す)
対応していない業務： 電話での問い合わせ対応、オペレーターによる承認待ち、本人認証(OTP)、返金処理などの慎重な対応が必要な業務、ブラウザの自動操作
1. 顧客から実際に依頼される状況を記述します。
利用シーンは、キーワードではなく、状況に応じて判断されます。顧客からどのような依頼があった場合にプロシージャを開始するかを、文章で記述します。
(良い例) 状況を文章で記述する
顧客が決済済みの注文のキャンセルを希望する場合
(悪い例) キーワードのみを列挙する
キャンセル、注文キャンセル、決済キャンセル
2. 開始対象外となる状況も記述します。
似たような状況でも、このプロシージャで対応すべきではない問い合わせがある場合は、その違いを明確に記述します。これにより、意図しない状況でプロシージャが開始されることを防ぎやすくなります。
(良い例)
顧客が決済済みの注文のキャンセルを直接依頼した場合に開始します。
キャンセルが可能かどうかを確認するだけの場合は開始せず、顧客が実際にキャンセルする意思を示した場合に開始します。
1. ノードではなく、文章で記述します。
タスクでノードや分岐を使って設定していた繰り返しの確認も、1つの文章で記述できます。ALFが会話の流れに応じて再度質問し、顧客の回答を待ちます。
(良い例)
顧客に写真の送信を依頼し、回答を待ちます。
顧客の回答が曖昧な場合は、写真を送信できるか再度確認します。
(悪い例) タスクのノード構造をそのまま記述する
写真の送信を依頼する。
写真が送信されなければ、手順1に戻る。
再度写真の送信を依頼する。
2. 必要な情報をまとめて記述し、不足している情報のみを確認します。
情報ごとに確認手順を分ける必要はありません。顧客がすでに伝えた情報については、ALFが再度質問することはありません。
(良い例)
顧客の氏名、連絡先、住所を確認します。不足している情報のみを再度質問します。
(悪い例)
氏名を確認する。確認できなければ再度案内する。
連絡先を確認する。確認できなければ再度案内する。
住所を確認する。確認できなければ再度案内する。
3. 案内メッセージを送信するだけの手順は、前後の指示文にまとめます。
メッセージを1つ送信するためだけに、セクションを分ける必要はありません。セクションは「注文照会」「キャンセル受付」など、業務単位で分けて作成します。
4. ポリシーや顧客への案内文は、原文のまま記述します。
キャンセル・返金ポリシーなど、正確に伝える必要がある内容は、要約せずに原文のまま記述します。文言を変更せずにそのまま送信する必要がある場合は、[メッセージ送信] を使用します。
5. 処理に失敗した場合の対応を記述します。
注文照会やキャンセル受付などの外部処理に失敗しても、ALFが自動で再試行したり、オペレーターに接続したりすることはありません。失敗時の対応を呼び出し専用セクションとして作成しておくと、複数のセクションから呼び出し、同じ手順で対応できます。
(良い例)
キャンセル受付に失敗した場合は、[セクション呼び出し：キャンセル失敗時の対応] を実行します。
1. 注文照会などの事前処理は、条件分岐の前に配置します。
条件を判定するために必要な情報は、事前に取得する必要があります。注文情報を照会し、その結果をもとに条件分岐するように記述します。
(良い例) 情報を取得してから条件分岐する
Shopifyで注文情報を照会し、メモリに保存します。
IF 注文ステータスが発送準備前の場合
Then キャンセルを受け付けます。
(悪い例) 情報を取得せずに条件分岐する
IF 注文ステータスが発送準備前の場合
Then Shopifyで注文情報を照会し、キャンセルを受け付けます。
2. 複数の条件を判定する場合は、順番に分けて記述します。
条件分岐のネスト構造には対応していません。条件は上から順番に判定し、最初に該当した条件の処理のみを実行するため、より具体的な条件を上に配置し、[ELSE IF] を使って順番に記述します。
3. 値が変更される可能性がある場合は、再取得して保存するように記述します。
メモリに保存された値は、顧客が回答を変更しても自動的に削除されません。顧客がキャンセル対象の注文を変更した場合などは、注文情報を再度照会し、メモリに保存するように記述します。
(良い例)
顧客がキャンセル対象の注文を変更した場合は、注文一覧を再度照会し、メモリの cafe24Ordersに保存します。