自動化:設定、トリガー、レシピ、監視

Last updated: October 23, 2026

自動化とは、Edvisorで何かが起きたときに自動的に実行されるルールです。たとえば、新しい学生へのメール送信、提案が閲覧または承認されたときのフォローアップ、パイプラインのステージ変更時のカウンセラーへの通知、タスクの作成、Webhookへのデータ送信、ビザまたは保険の期限前のリマインダーなどがあります。この記事では、自動化の完全な設定フロー(自動化の場所、機能の有効化、ルールの作成、検索、複製、管理)、5つの領域(学生、提案、登録、セール、保険)にわたる18種類の利用可能なイベントと「実行タイミング」のオプション、条件、アクション、変数、すぐに使える自動化レシピ、ログで自動化の実行を監視する方法について説明します。

自動化とは、Edvisorで何かが起きたときに自動的に実行されるルールです。各ルールには、イベント(開始条件)、任意の条件(フィルター)、1つ以上のアクション(実行内容)があります。この記事では、自動化の場所、機能の有効化方法、ルールの作成、検索、複製、管理方法について説明します。

概要

自動化とは、Edvisorで何かが起きたときに自動的に実行されるルールです。各自動化には以下が含まれます。

  • イベント — 開始条件。
  • 任意の条件 — 満たす必要があるフィルター。
  • 1つ以上のアクション — 実行時に行うこと。

一般的な用途:

  • 新しい学生が作成されたときにウェルカムメールを送信する。
  • 学生が更新されたときにカウンセラーへ通知する。
  • 特定の国籍に一致する学生がいる場合にフォローアップタスクを作成する。
  • Webhookを介して学生データを自社システムに送信する。
  • 学生のビザの有効期限前にリマインダーを送信する。
  • 学生が提案を閲覧または承認したとき、または提案の有効期限前にフォローアップする。
  • 学校が登録を承認したときに引き継ぎタスクを作成する。
  • セールが作成されたときにオンボーディングタスクを作成する。
  • 学生が特定のパイプラインステージに移動したときにカウンセラーへ通知する。
  • 保険契約の開始日または終了日前に学生へリマインダーを送信する。

利用可能なイベント

自動化はイベントによってトリガーされます。イベントは5つの領域に分類された18種類があります。それぞれの詳細については、以下のトリガー、条件、アクションのリファレンスセクションを参照してください。

学生

  • 新しい学生が作成された
  • 学生が更新された
  • 学生が削除された
  • 学生の誕生日である
  • 学生のビザの有効期限が近づいている

提案

  • 提案が作成される
  • 提案発行済み — 学生に発行または送信された。以前は「提案公開済み」と呼ばれていましたが、製品全体に合わせて名称が変更されました。
  • 提案閲覧済み — 学生が初めて提案を開いたときに一度だけ発生する。
  • 提案承認済み — 承認済みへの移行時に発生する。
  • 提案の有効期限 — 提案の有効期限日の前、当日、または後。

登録

  • 学生の新しい登録が作成された
  • 学校によって登録が承認された

セール

  • セールが開始された
  • 宿泊施設のセールが開始された
  • セールが作成された
  • パイプラインステージの変更 — ステージへ移動およびステージから移動の条件を使用します。一括再割り当てではトリガーされません。

保険

  • 保険開始日
  • 保険終了日

保険イベントは確定済みの予約のみに適用されます。

注: 自動化をトリガーできるイベントの範囲を広げるため、今後新しいイベントが追加されます。

見つける場所

設定 > リクルート > 自動化に移動します。

自動化の作成、編集、有効化、無効化、削除を行えるのは管理者のみです。カウンセラーは自動化を表示できますが、変更することはできません。

自動化を有効にする

自動化セクションを初めて開くと、機能の説明が表示された有効化画面が表示されます。有効化すると、アカウント用のAPIキーのペアが生成され、Edvisorが内部で自動化を実行するために使用します。キーを自分で管理する必要はありません。

有効化すると、自動化の一覧ビューが表示されます。ヘッダーには合計件数(例: 「自動化 (21)」)が表示され、各自動化はカードとして表示されます。

各カードには次の項目が表示されます:

  • 自動化の名前。
  • トリガーとなるイベント。
  • 条件の概要チップ。たとえば「3条件 · いずれか」などが表示され、ルールを開かなくても条件の数と、すべての条件またはいずれかの条件のどちらのロジックを使用しているかを確認できます。
  • アクションチップ。
  • 有効化 / 無効化トグル。
  • 自動化を複製する場所であるカードメニュー。

自動化を作成する

開始する方法は2つあります:

  • 最初から作成 — 右上の自動化を作成をクリックします。
  • テンプレートから作成 — 一覧ビューの右側にあるパネルからテンプレートを選択します(例: 「新入生を歓迎」)。テンプレートにはイベント、条件、アクションがあらかじめ入力されているため、詳細をカスタマイズするだけで済みます。

ビルダー

ビルダーは3つの部分で構成されています:

  • 上部 — 自動化名(必須)、説明、および「この自動化が失敗したときにメールを送信する」トグル。自動化の実行が失敗するたびにメールを受け取るには、トグルをオンのままにします。
  • 左パネル — 3つのステップが縦に並んだルールの流れ:イベント > 条件 > アクション。設定するには任意のステップをクリックします。
  • 右パネル — 選択したステップの設定。

右パネルの下部にある「イベント」/「条件」/「アクション」ボタンを使って、ステップを前後に移動することもできます。

イベントを設定すると、自動化を実行するタイミングも選択します — 即時、または日付に関連するイベントの場合は、当日の前/当日/当日の後(期間を日数で設定)です。日付ベースのイベントでは、作成中にルールが平易な言葉で再表示されるため、保存する前にタイミングを確認できます。

完了したら、右上の保存をクリックします。必須項目がすべて入力されるまで、保存は無効のままです。

自動化を検索する

ルールが数件を超えたら、自動化リストの検索を使って名前から見つけられます。

  • 検索ボックスに入力すると、入力に合わせてリストが絞り込まれます。
  • 一致する結果の件数が表示されます。
  • 一致するものがない場合は、専用の結果なし状態が表示されます。これは「最初の自動化を作成する」空の画面とは異なり、後者は自動化が本当に1つもない場合にのみ表示されるようになりました。

自動化を複製する

ルールを作り直さずに再利用するには、自動化のカードメニューを開き、複製を選択します。ワンクリックで実行できます。

コピーはオフの状態で作成されます。そのことを知らせるバナーも表示されます。これは意図的な仕様です。確認が完了するまで何も実行されません。コピーを開き、名前や変更が必要な項目を編集してから、トグルで有効にします。

既存の自動化を管理する

自動化リストから、次の操作を行えます。

  • カードをクリックして自動化を開きます。これにより「自動化を編集」が開き、2つのタブが表示されます。自動化(作成画面)とログ(実行履歴)です。
  • カードのトグルで有効または無効にします。無効にした自動化は保持されますが、実行されません。
  • カードメニューから自動化を複製します(上記を参照)。
  • 編集画面から自動化を削除します。過去の実行ログは保持されます。

言語

自動化は22言語に完全対応しており、アカウントの言語に従います。

トリガー、条件、アクションのリファレンス

これは、自動化の作成に使用する構成要素、つまり自動化を開始するイベント、実行するかどうかを決定する条件、および実行するアクションのリファレンスです。

概要

すべての自動化は、次の3つの部分で構成されます。

  • イベント — 自動化を開始するEdvisor内で発生する事象(例:新しい学生が作成された場合)。
  • 条件(任意) — 自動化を実行するために満たす必要がある追加ルール。
  • アクション — 自動化の実行時に行われる処理(例:メールの送信)。

これらは自動化ビルダーで選択します。このセクションでは、選択できるすべてのオプションを一覧にしています。

イベント

イベントは自動化を開始するトリガーです。イベントは18種類あり、学生、プロポーザル、登録、セール、保険の5つのカテゴリーに分類されています。

学生(5イベント)

  • 新しい学生が作成された
  • 学生が更新された
  • 学生が削除された
  • 学生の誕生日である
  • 学生のビザの有効期限が近づいている

プロポーザル(5イベント)

  • プロポーザルが作成された
  • プロポーザル発行 — プロポーザルが発行または学生に送信された。このイベントは以前はプロポーザル公開と呼ばれていましたが、製品内の他の名称と一致させるために変更されました。
  • プロポーザル閲覧 — 学生が初めてプロポーザルを開いたとき。このイベントは一度だけ発生し、その後の閲覧では再度発生しません。
  • プロポーザル承諾 — 承諾への実際の移行時に発生します。学生がオプションAを承諾した後にオプションBを承諾した場合、それは2つではなく1つのイベントです。
  • プロポーザル有効期限日 — 日付ベース。プロポーザルの有効期限日の前、当日、または後に実行できます。

登録(2イベント)

  • 学生の新しい登録が作成された
  • 学校によって登録が承認された

セール(4イベント)

  • セールが開始された
  • 宿泊施設のセールが開始された
  • セールが作成された
  • パイプラインステージの変更 — 学生がパイプライン内のステージ間を移動した。ステージは移動先ステージと移動元ステージの条件で選択します(下記の「条件」を参照)。一括再割り当てでは、このイベントは発生しません。

保険(2イベント)

  • 保険契約開始日
  • 保険契約終了日

保険の両イベントは日付ベースで、確認済みの予約にのみ適用されます。未確認の予約に設定された保険では、これらのイベントは発生しません。

注:自動化をトリガーできるイベントの範囲を広げるため、今後新しいイベントが追加される予定です。

実行タイミング

各イベントについて、タイミングを設定します。

  • 即時 — イベントが発生するとすぐに自動化が実行されます。
  • 前 — 日付の指定日数前に実行されます。
  • 当日 — その日付当日に実行されます。
  • 後 — 日付の指定日数後に実行されます。

学生のビザの有効期限、提案の有効期限、保険ポリシーの開始日または終了日などの日付ベースのイベントでは、前または後の日数として期間を入力する必要があります。日付ベースのイベントは、将来の日付に依存するため、「即時」には実行できません。

日付ベースのトリガーを作成すると、保存する前にタイミングが意図したとおりになっているか確認できるよう、ビルダーがルールを平易な言葉で言い換えて表示します。

条件

条件は、オートメーションを実行するために満たす必要がある任意のルールです。

条件の組み合わせ

  • 条件はすべてのロジック(すべての条件が真である必要があります)またはいずれかのロジック(少なくとも1つの条件が真である必要があります)で組み合わせることができます。
  • リストビューのオートメーションカードには、設定内容の概要として、たとえば「3条件 · いずれか」のように表示されます。
  • 1つのオートメーションで同じフィールドを複数回使用できます。そのため、1つのフィールドから範囲や複数部分のルールを作成できます。

フィールドの種類

従来のリスト形式のフィールドに加えて、条件では次のフィールドもサポートされるようになりました。

  • 日付フィールド。
  • テキストフィールド。
  • はい/いいえフィールド。

既知の条件フィールド

  • 学生の国籍 — 「いずれかである」などの演算子を使用できます。たとえば、特定の国籍の学生に対してのみオートメーションを実行できます。
  • 保険の渡航先国 — 保険関連のルールに使用します。
  • 保険プロバイダー — 保険関連のルールに使用します。
  • ステージへ移動およびステージから移動 — パイプラインステージ変更イベントで使用します。選択項目には利用可能なパイプラインとそのステージが一覧表示されるため、まずパイプラインを選択し、その後ステージを選択します。

最近の変更

  • 以前は非表示だった2つの提案条件が利用可能になりました。リリースノートでは名前が示されていなかったため、提案イベントの条件選択画面で現在の一覧を確認してください。
  • 1つの演算子が廃止されました。これは、適用先のフィールドに対して意味をなさなかったためです。リリースノートでは名前が示されていません。以前使用していた演算子が見つからない場合は、これが理由である可能性が高いため、条件を開き直して残っている最も近い演算子を選択してください。

アクション

アクションは、オートメーションの実行時に行われる処理です。複数のアクションを追加できます。アクションは順番に実行され、それぞれ独立して実行されます。1つのアクションが失敗しても、他のアクションは引き続き実行されます。

アクションは2つのカテゴリーに分類されます。

コミュニケーション

  • 学生にメールを送信 — 学生にメールを送信します。学生のメールアドレスは自動的に入力されます。件名と本文(どちらも必須)を設定し、変数(下記参照)を使用できます。
  • カウンセラーにメールを送信 — 学生に割り当てられたカウンセラーにメールを送信します。

統合

  • タスクを作成 — タスクを作成します。タスク名、期限、担当者を設定します。
    • 注:タスク内の変数はプレーンテキストとして保存され、実際の値には置き換えられません。タスク名内の変数に依存しないでください。
  • Webhookを送信 — 選択したURLにデータを送信します。URLとペイロードを設定します。安全上の理由から、Webhookはパブリックアドレスにのみ送信でき、リダイレクトは最大5回まで行われます。

変数

変数を使用すると、実際の学生情報や代理店情報をメールに挿入できます。自動化が実行されると、各変数が実際の値に置き換えられます。

学生

  • 学生ID
  • 名
  • 姓
  • メールアドレス
  • 生年月日

代理店

  • 代理店名
  • オフィス名

変数に値を入力できない場合(たとえば、学生の生年月日が未登録の場合)、プレースホルダーはメッセージから削除されます。

言語

イベント、条件、アクションを含む自動化ビルダーは22言語に完全対応しており、アカウントの言語に従います。

自動化レシピ:一般的な設定

このセクションでは、設定 > 募集 > 自動化で構築できる一般的な自動化設定について説明します。各レシピは、達成する内容、選択するトリガー、実行タイミング、追加する条件、推奨アクション、注意点という同じ構成になっているため、必要なものをすぐに見つけて数分で構築できます。

新しいトリガーや条件がリリースされるにつれて、今後さらにレシピが追加されます。固定されたリストではなく、成長するライブラリとしてご利用ください。まだ掲載されていない便利な設定を作成した場合は、別のセクションとして追加できます。

利用可能な項目の全リストについては、上記の「トリガー、条件、アクションのリファレンス」セクションをご覧ください。

レシピ1 — 提案書をフォローアップする

達成する内容:手作業で追跡しなくても、提案書の対応を進められます。提案書の期限が切れる前に学生へ通知し、学生が提案書を確認したものの対応していない場合にフォローアップし、承諾した瞬間に社内へ引き継ぎます。

選択するトリガー:実行したい動作ごとに、提案書グループから自動化を1つ設定します。

  • 提案書を閲覧 — 学生が初めて提案書を開いたとき。
  • 提案書を承諾 — 学生が承諾したとき。
  • 提案書の有効期限 — 提案書の期限日より前、当日、または後に実行するよう設定できる日付ベースのトリガー。

実行タイミング:

  • 提案閲覧は、学生が提案を初めて開いたときに発火し、その後の閲覧では発火しません。
  • 提案承諾は、実際に承諾へ移行したときに発火します。
  • 提案の有効期限日は、有効期限日を基準に実行されます — リマインドの場合は、数日前に設定してください。日付ベースのトリガーを作成すると、ビルダーがルールをわかりやすい言葉で言い換えて表示するため、正しいオフセットと方向を選択したか確認できます。

追加する条件:自動化が対象の学生にのみ実行されるよう絞り込みます — たとえば学生の国籍や、渡航先、プログラム種別などの提案フィールドを指定できます。1つのルール内で同じフィールドを複数回使用して、2つのテストを行うこともできます。カードには、作成した内容の概要(たとえば「3つの条件 · いずれか」)が表示されます。すべての条件を一致させたい場合は、一致モードを「すべて」にします。1つの条件だけで十分な場合は「いずれか」を使用します。

推奨アクション:

  • 有効期限前:提案へのリンクを含むリマインドメールを学生に送信し、担当カウンセラーが電話するためのタスクを作成します。
  • 承諾時:お祝いのメールを送信し、次のステップ(デポジット、書類)のタスクを作成して、Webhookまたは内部通知でチームに知らせます。
  • 閲覧済みだが未承諾:提案閲覧自動化と、設定した時間後に送信するフォローアップメールを組み合わせるか、有効期限日のリマインドを使用して対応します。

注意点:提案閲覧は最初のオープン時にのみ発火します — 学生が提案を5回再度開いたとしても生成されるイベントは1つだけなので、閲覧のたびに繰り返し発生することを前提としたロジックは作成しないでください。提案承諾は移行時に1回だけ発火します — 学生がオプションAを承諾した後にオプションBへ切り替えた場合も、イベントは2つではなく1つだけです。そのため、承諾の自動化は切り替え時に再度実行されません。

レシピ2 — 学生に保険の契約日をリマインドする

実現できること:学生は保険の補償開始前と終了前に通知を受け取るため、補償が有効な状態で渡航でき、更新時期も把握できます。また、チームが適切なタイミングで書類を確認するためのきっかけにもなります。

選択するトリガー:トリガーピッカーの新しい保険カテゴリーから選択します:

  • 保険開始日 — 渡航前や「補償開始が近づいています」というメッセージに使用します。
  • 保険終了日 — 更新や有効期限のリマインドに使用します。

実行タイミング:どちらも日付ベースなので、該当日の前、当日、または後を選択できます — たとえば保険開始日の7日前、または保険終了日の14日前です。設定時にビルダーがルールをわかりやすい言葉で言い換えて表示するため、保存する前にオフセットが意図したとおりになっているか確認できます。

追加する条件: 保険の渡航先国を使用して国別の指示を送信し、保険プロバイダーはプロバイダーによって文言や書類が異なる場合に使用します。両方が必要な場合は組み合わせ、カード上の条件概要を使用して、ルールが説明した内容に一致していることを確認してください。

推奨されるアクション:

  • 学生に保険証券の詳細と携帯すべきものをメールで送信する。
  • 学生が書類を所持していることを確認するよう、カウンセラーへのタスクを作成する。
  • 終了日については、更新を促すメールを送信し、補償期間の延長について話し合うタスクを作成する。

注意点: 保険のトリガーは確定済みの予約のみに適用されます。まだ確定していない予約に添付された保険契約では、これらのトリガーは実行されないため、保留状態の学生には何も行われません — このレシピだけを補償確認の唯一の手段として頼らないでください。

レシピ3 — パイプラインステージの変更に反応する

実現すること: パイプラインの移動を自動的にアクションへ変換します — 学生がステージに入ったときの歓迎メッセージ、進行したときの引き継ぎタスク、ステージに戻ったり離れたりしたときの内部アラートを実行します。

選択するトリガー: パイプラインステージの変更。

実行されるタイミング: 学生のパイプラインステージが変更されるたびに実行されます。その後、トリガーの条件を使用して、どの変更を対象にするかを決定します。

追加する条件: 「ステージへ移動」を使用して、学生が特定のステージに到着したときにアクションを実行し、「ステージから移動」を使用して、学生がステージを離れたときにアクションを実行します。2つを組み合わせて特定の移行(あるステージから出て別のステージに入る)を捉え、国籍、渡航先、プログラムなどの他の条件を追加して、適切な学生にルールの対象を絞り込みます。

推奨されるアクション:

  • 新しいステージへ移動:ステージに適したメールを送信し、担当者の次のタスクを作成する。
  • アクティブなステージから後退:マネージャーに通知する、または確認タスクを作成する。
  • ステージの変更全般:レポートやCRMが常に同期されるよう、Webhookを実行する。

注意点: 一括再割り当てではトリガーされません。 ステージが一括で変更された場合、自動化は実行されないため、大規模な整理や移行はログ上では何も起きていないように見えます。一括でステージを移動する場合は、フォローアップメールやタスクが作成されないことを前提に計画し、それらを手動で処理してください。

自動化の実行を監視する

自動化が実行されるたびに、ログエントリが記録されます。このセクションでは、ログの場所、各フィールドの意味、問題が発生したときの読み取り方について説明します。

自動化は、学生、提案、登録、販売、保険に関するイベントなど、さまざまなイベントによって開始されます。そのため、特定の自動化のログには、それが構築されたトリガーに応じた内容が反映されます。以下のフィールド、ステータス、失敗理由は、どのトリガーが実行された場合でも同じです。

概要

ログは、1回の自動化実行の記録です。実行ごとに1件のログエントリが作成されるため、何が起きたのか、いつ起きたのか、正常に動作したかどうかを正確に確認できます。ログは編集または削除できず、永続的な記録として残ります。

ログの確認場所

  1. 設定 > 採用 > 自動化に移動します。
  2. 確認する自動化を開きます。
  3. 自動化の編集画面で、自動化タブからログタブに切り替えます。

自動化が一度も実行されていない場合は、「まだ実行されていません」という空の状態と、自動化の設定を表示するボタンが表示されます。

ログの読み方

ログビューには次の項目が表示されます。

  • 実行結果で実行を絞り込むステータスフィルター(例:「すべてのステータス」)。
  • 一覧に表示されている実行数を示すカウンター(例:「12件を表示」)。
  • 実行ごとに1行。

各ログ行には次のフィールドが表示されます。

  • 時刻 — 実行された日時。
  • ステータス — 結果(下記参照)。
  • トリガー — 実行を開始したイベント。これは自動化の作成元となったトリガーであるため、利用可能なイベントのいずれかになります。表示される例には、提案書作成、提案書発行(以前は提案書公開と呼ばれていました)、提案書閲覧、提案書承認、提案書の有効期限日、パイプラインステージの変更、保険のトリガーである保険契約開始日および保険契約終了日などがあります。
  • 実行ID — 実行ごとの一意のID(「exec-」で始まります)。問題を報告する際は実行IDを記載してください。正確な実行を特定できます。
  • アクション — 実行されたアクションの数を比率で表示したもの(例:「1/1」または「0/1 スキップ」)。
  • 実行時間 — 実行にかかった時間。

行をクリックすると展開され、その実行で行われた各アクションの詳細を確認できます。

ステータス

  • 成功 — 自動化が実行され、すべてのアクションが完了しました。
  • 失敗 — 実行が完了しませんでした。
  • 部分的な失敗 — 一部のアクションは完了しましたが、一部は完了しませんでした。

実行が表示されるその他の場所

自動化の実行は学生の最近のアクティビティフィードにも表示されるため、学生のプロフィールから自動化のアクティビティを確認できます。

よくある失敗の理由

実行が失敗する場合、通常は次のいずれかが原因です。

  • Webhookが2xx以外のレスポンスを返した。
  • WebhookのURLが内部またはプライベートIPアドレスを指していた(これらはブロックされます)。
  • Webhookが5回を超えるリダイレクトに従った。
  • 必須変数に値を入力できなかった。

自動化に実行がない理由

ログタブが空で、エントリがあるはずだと思われる場合は、自動化がオンになっているか確認してください。特に、カードメニューから自動化を複製すると、コピーはオフの状態で作成され、自動化上にその旨を示すバナーが表示されます。無効になっている自動化は実行されないため、有効にするまでログエントリは一切生成されません。新しく複製した自動化が何もしていないように見える最も一般的な理由はこれです。

また、トリガーが実際に発生したことと、自動化の条件が期待しているレコードに一致していることも確認してください。トリガーが発火し、条件を満たした場合にのみ実行が記録されます。

ログを確認するタイミング

期待していたメール、タスク、またはWebhookが実行されなかった場合や、自動化が機能していないと報告された場合は、ログを確認してください。ステータスと展開されたアクションの詳細から、どのステップが失敗したのか、そしてその理由を確認できます。