連携コネクタには、「繰り返し」や「条件分岐」をはじめ、データの変換や整形など、連携を便利にする機能があります。
それらを使いこなすことで、より高度な連携を実現できます。

「シナリオ制御」を使うと、シナリオの実行中に条件で処理を分けたり、実行を中断したりできます。
たとえば、条件に合う相手にだけメールを送ったり、確認が必要なデータを見つけたときは処理をやめたりできます。

本記事では、イベントの申し込みを管理するkintoneアプリを例に、次の3つのシナリオを使って、シナリオ制御の使い方とステップ消費数の考え方を紹介します。

• 新規の申込者にだけ、特典案内のメールを送る（条件分岐）
• 毎月のニュースレターを、キャンセルした申込者を除いて送る（スキップ判定）
• 確認を要する申し込みが1件でもあれば、別アプリへの転記をやめる（中断判定）

シナリオ制御では、次の3つのアクションを使ってシナリオの実行を制御できます。

• シナリオ制御 条件分岐 ：条件を満たすときだけ処理します。
• シナリオ制御 スキップ判定 ：繰り返しの一部の回をスキップします。
• シナリオ制御 中断判定 ：シナリオの実行を中断します。

3つのアクションは、いずれも「条件」の値がtrueかfalseかで動作が変わります。
各アクションの違いは、次のとおりです。

アクション	条件がtrueの場合	条件がfalseの場合	使える場所	向いている用途
条件分岐	条件分岐アクションのブロック内の処理を実行し、完了後にシナリオを終了する	ブロック内の処理は実行せず、条件分岐の後続のステップに進む	ブロックの内外を問わず使える	特定の条件に応じて、処理の流れを切り替えたいとき
スキップ判定	スキップ判定に該当する回の後続のステップを実行せず、次の繰り返しに進む	スキップ判定アクションの後続のステップを実行する	繰り返しブロック内でのみ使える	条件に合う回だけをスキップし、全体の処理は最後まで進めたいとき
中断判定	シナリオ全体の実行を中断する 中断判定を繰り返しなどのブロック内に置いた場合も、条件がtrueになった時点でシナリオ全体の実行が中断される	中断判定アクションの後続のステップを続ける	ブロックの内外を問わず使える	前提条件を満たさない場合に、後続のステップを実行したくないとき 無限ループや意図しない大量処理を防ぎたいとき

シナリオ制御の3つのアクションは、「条件」に設定した値で動作が決まります。
「条件」の値が小文字のtrueに一致するときだけ、trueと判定されます。
それ以外の値は、すべてfalseと判定されます。

「条件」には、前のステップでtrueまたはfalseになる値を用意して設定します。
値を用意する方法は、判定したい内容によって異なります。

判定したい内容	値の用意の方法	本記事のシナリオ
kintoneのフィールドの値	kintoneの計算式で、小文字のtrueかfalseを返すフィールドを用意する	条件分岐、スキップ判定
データがあるかどうか	表データの「データの存在チェック」の出力データresultを使う	中断判定
文字列が一致するか、含むか	一般の「フィールド関数を実行する」の「式フィールド3_真偽値」でEXACT、CONTAINS、REGEXTESTを使い、出力データexpression_booleanを使う 比較演算子（>や=など）はないため、数値の大小は比較できない	－
シナリオの途中で取得した件数などの数値	Excel for the webのセルに判定用の数式を入力しておき、判定したい値を書き込んでから判定結果を取得する	－

次の画面は、kintoneの計算式でtrueになったフィールドの値を、「条件」に設定した例です。

次の画面は、「データの存在チェック」の出力データresultを、「条件」に設定した例です。

本記事の3つのシナリオでは、共通してイベント申込アプリを使います。
「申込フォーム」と「管理者用」のグループでフィールドをグループ化しています。
申込者は「申込フォーム」グループのフィールドを入力します。
「管理者用」グループのフィールドには、今回のシナリオ制御で使う値を格納します。

イベント申込アプリの画面は、次のとおりです。

イベント申込アプリのフィールドや設定は、次のとおりです。

フィールド名	フィールドコード	フィールドタイプ	備考
申込フォーム	申込フォーム	グループ	次の6つのフィールドが入っています。
氏名	氏名	文字列（1行）
メールアドレス	メールアドレス	文字列（1行）
イベント名	イベント名	文字列（1行）
開催日	開催日	日付
参加区分	参加区分	ラジオボタン	選択肢は「新規」「リピーター」です。初期値は「新規」です。
申込状況	申込状況	ラジオボタン	選択肢は「参加予定」「キャンセル」です。初期値は「参加予定」です。
管理者用	管理者用	グループ	次の3つのフィールドが入っています。「新規案内（条件分岐）」と「今月配信除外（スキップ判定）」は、自動計算を設定した文字列（1行）です。
新規案内（条件分岐）	新規案内_条件分岐	文字列（1行）	計算式はIF(参加区分="新規","true","false")です。
今月配信除外（スキップ判定）	今月配信除外_スキップ判定	文字列（1行）	計算式はIF(申込状況="キャンセル","true","false")です。
データ状態	データ状態	ラジオボタン	選択肢は「正常」「要確認」です。初期値は「正常」です。

条件分岐のシナリオでは、新規の申込者から申し込みがあったときに、Outlookで特典案内のメールを自動送信します。
新規の申込者ではない場合は、何も処理しません。

シナリオ全体の流れは次のとおりです。

新規の申込者の場合は、条件がtrueになります。
「条件分岐」のブロック内の処理を実行し、Outlookで特典案内のメールを送信します。

新規の申込者ではない場合は、条件がfalseになります。
「条件分岐」の後続のステップに進みますが、このシナリオでは後続のステップがないため、メールを送信せずにシナリオが終了します。

このシナリオでは、「レコード追加/編集の検知」イベントで申し込みを検知します。
「検知するイベントの種類」は「追加」だけを選択してください。
「編集」も選択すると、レコードを編集したときにも特典案内のメールが再送されます。

条件分岐アクションは、次の手順で作成します。

1. [アプリ選択]で「シナリオ制御」をクリックします。

2. [アクション選択]で「条件分岐」をクリックします。

3. [基本設定]の「条件」に、レコード追加/編集の検知 > record > 新規案内_条件分岐 > valueを選びます。
   「新規案内（条件分岐）」は、「参加区分」が「新規」のときにtrueになるフィールドです。

   

4. [出力確認]で[完了して次へ]をクリックします。

条件分岐の対象となるアクションは、ブロック内に作成します。
[基本設定]で[ブロックを開く]をクリックすると、ブロックの中を編集できます。

ブロックの最初のステップには、「分岐ブロックの開始」が自動で作成されています。
「分岐ブロックの開始」の項目は決まっているため、変更せず[出力確認]で[完了して次へ]をクリックします。

条件分岐のシナリオでは、ブロックの中は次の2ステップになります。

1. （ステップ2.1）「分岐ブロックの開始」
2. （ステップ2.2）「メールの送信」

• 条件分岐にはtrue用のブロックだけがあり、false用のブロックはありません。
  条件がfalseのときだけ実行したいステップは、条件分岐のあとに配置します。
• 条件がtrueでブロック内の処理が完了すると、条件分岐のブロックの外にある後続のステップは実行されず、シナリオが終了します。
  条件分岐のあとで実行したいステップがある場合は、それらのステップも条件分岐のブロック内に配置します。

条件分岐のシナリオでは、条件の判定結果によって、実行されるステップが変わるため、ステップ消費数も変わります。
このシナリオのステップは、条件分岐の外と中に分かれます。
条件分岐の外の処理は「レコード追加/編集の検知」「条件分岐」です。
条件分岐の中の処理は「分岐ブロックの開始」「メールの送信」です。

次の図は、条件分岐のシナリオがtrueの場合のステップ消費数の例です。

条件がtrueの場合は、Outlookでメールを送信します。
そのため、ステップ消費数は「条件分岐の外のステップ数 + 条件分岐の中のステップ数」で計算できます。
条件分岐の外のステップ数には「条件分岐」も含まれます。
合計のステップ消費数は2 + 2 = 4です。

次の図は、条件分岐のシナリオがfalseの場合のステップ消費数の例です。

条件がfalseの場合は、ブロック内の処理を実行しません。
このシナリオでは後続のステップもないため、条件分岐の外のステップだけが加算されます。
合計のステップ消費数は2です。

スキップ判定のシナリオでは、毎月1日にOutlookからニュースレターを送ります。
送信の宛先は、その月に開催されるイベントの申込者のうち、申込状況が「参加予定」の申込者です。
申込状況が「キャンセル」の場合は、送信をスキップします。

シナリオ全体の流れは次のとおりです。

キャンセルした申込者の場合は、条件がtrueになります。
その回の後続のステップを実行せず、ニュースレターを送信しないまま次の申込者に進みます。
参加予定の申込者の場合は、条件がfalseになります。
スキップ判定の後続のステップに進み、ニュースレターを送信します。

イベント申込アプリに、今月開催の申込レコードへ絞り込む「今月のイベント」一覧を作ります。

• 「今月のイベント」一覧には、「メールアドレス」と「今月配信除外（スキップ判定）」を表示するフィールドとして追加します。
• 一覧の「絞り込み」の条件で、「開催日」が「今月」になる条件を設定します。

スキップ判定のシナリオは、一般コネクタの「スケジュール実行」で毎月1日に実行します。
イベント申込アプリのレコードは、kintoneの「レコードの一覧取得」アクションで取得します。
[基本設定]の「取得方法」は「一覧から取得する」、「一覧」は「今月のイベント」を選択します。

「繰り返し」アクションは、次の手順で作成します。

1. [アプリ選択]で「一般」をクリックします。
2. [アクション選択]で「繰り返し」をクリックします。
3. [基本設定]で、次の2点を設定します。
   • 「繰り返し対象」は、「今月のイベント」一覧を取得した「レコードの一覧取得」を選択します。
   • 「エラー時に繰り返しをスキップ」は「しない」をクリックします。
4. 繰り返しの[ブロックを開く]をクリックします。
5. 「繰り返しの開始」のあとに、アクションを追加します。

スキップ判定アクションは、次の手順で作成します。

1. [アプリ選択]で「シナリオ制御」をクリックします。

2. [アクション選択]で「スキップ判定」をクリックします。

3. [基本設定]の「条件」に、繰り返しの開始 > item > 今月配信除外_スキップ判定 > valueを選びます。
   「今月配信除外（スキップ判定）」は、「申込状況」が「キャンセル」のときにtrueになるフィールドです。

   

4. [出力確認]で[完了して次へ]をクリックします。

5. 「メールの送信」のステップを作成します。

• 条件がtrueのときは、同じ繰り返しブロックの中でスキップ判定より後ろにあるステップが、その回だけ実行されません。
  どの回でも実行したいステップは、スキップ判定より前に配置します。
• 繰り返しアクションにも、スキップする設定として「エラー時に繰り返しをスキップ」があります。
  エラーが起きた回の後続のステップをスキップして、次の回へ進む設定です。
  スキップする点はスキップ判定と同じですが、発動条件が異なります。
  スキップ判定は条件を満たしたとき、「エラー時に繰り返しをスキップ」はエラーが起きたときにスキップします。

  

スキップ判定を使ったシナリオのステップ消費数は、「繰り返しの外のステップ数 + 各回の繰り返しの中のステップ数の合計」で計算できます。

繰り返しの外の処理は「スケジュール実行」「レコードの一覧取得」「繰り返し」です。
繰り返しの中の処理は「繰り返しの開始」「スキップ判定」「メールの送信」です。

次の図は、今回のスキップ判定シナリオのステップ消費数の例です。

繰り返しの外の処理は、スキップ判定の結果にかかわらずカウントされます。
スキップ判定の条件がtrueの場合は、その回の後続のステップを実行しません。
そのため、「メールの送信」は加算されません。
スキップ判定の条件がfalseの場合は、その回の後続のステップも実行します。
そのため、「メールの送信」も加算されます。

今回のシナリオでは、繰り返しの外のステップ数は3です。
図の例では、スキップ判定の条件がtrueの回とfalseの回が1回ずつあります。
trueの回の繰り返しの中のステップ数は2です。
falseの回の繰り返しの中のステップ数は3です。
ステップ消費数は3 + 2 + 3 = 8です。

中断判定のシナリオでは、毎日決まった時刻に、イベント申込アプリの情報を個人情報管理アプリへ転記します。
ただし、「データ状態」が「要確認」のレコードが1件でもある場合は、転記をすべて中断します。
要確認のレコードがあるかどうかは、「要確認」一覧と「データの存在チェック」で判定します。

シナリオ全体の流れは次のとおりです。

「要確認」のレコードがある場合は、条件がtrueになります。
中断判定のステップでシナリオ全体の実行を中断し、個人情報管理アプリへの転記はしません。

「要確認」のレコードがない場合は、条件がfalseになります。
中断判定の後続のステップに進み、個人情報管理アプリへレコードを転記します。

イベント申込アプリに、「転記用」一覧と「要確認」一覧を作ります。

• 「転記用」一覧には、「氏名」「イベント名」「申込状況」「メールアドレス」を表示するフィールドとして追加します。
• 「要確認」一覧には「絞り込み」の条件で、「データ状態」の「次のいずれかを含む」から「要確認」を選びます。

転記先の個人情報管理アプリには、「転記用」一覧と同じ「氏名」「イベント名」「申込状況」「メールアドレス」のフィールドを作成します。

中断判定のシナリオは、一般コネクタの「スケジュール実行」で毎日決まった時刻に実行します。
「要確認」一覧のレコードは、kintoneの「レコードの一覧取得」アクションで取得します。
[基本設定]の「取得方法」は「一覧から取得する」、「一覧」は「要確認」を選択します。

中断判定のシナリオでは、「要確認」一覧にデータがあるときは処理をやめます。
データがあるかどうかをtrueもしくはfalseで受け取るため、表データの「データの存在チェック」アクションを使います。
「データの存在チェック」アクションは、次の手順で作成します。

1. [アプリ選択]で「表データ」をクリックします。
2. [アクション選択]で「データの存在チェック」をクリックします。
3. [基本設定]の「表データ」は、「要確認」一覧を取得した「レコードの一覧取得」の「表内容」を選択します。
4. 「条件」は、「データがある場合にtrueを返す」をクリックします。
   

   

中断判定アクションは、次の手順で作成します。

1. [アプリ選択]で「シナリオ制御」をクリックします。
2. [アクション選択]で「中断判定」をクリックします。
3. [基本設定]の「条件」に、データの存在チェック > resultを選びます。
   resultは、「要確認」一覧にデータがあるときにtrueになります。

   

4. [出力確認]で[完了して次へ]をクリックします。

中断判定のあとには、次のステップを作成します。

1. kintoneの「レコードの一覧取得」を作成します。
   [基本設定]の「取得方法」は「一覧から取得する」、「一覧」は「転記用」を選択します。
2. 「繰り返し」の[基本設定]で、「繰り返し対象」は「転記用」一覧を取得した「レコードの一覧取得」を選択します。
3. 繰り返しの中に「繰り返しの開始」と「レコードの追加」を作成し、個人情報管理アプリへレコードを登録します。

中断判定でシナリオの実行が中断されても、それまでに実行した処理は取り消されません。
取り消せない処理（レコードの登録やメールの送信など）は、中断判定よりあとに配置してください。

中断判定のシナリオでは、条件の判定結果によって、中断判定の後続のステップが実行されるかどうかが変わります。
このシナリオのステップは、中断判定までと、中断判定の後続に分かれます。
中断判定までのステップは、「スケジュール実行」「レコードの一覧取得」「データの存在チェック」「中断判定」です。
中断判定の後続のステップは、「レコードの一覧取得」「繰り返し」「繰り返しの開始」「レコードの追加」です。

次の図は、中断判定のシナリオがtrueの場合のステップ消費数の例です。

条件がtrueの場合は、中断判定の後続のステップは加算されません。
中断判定による中断は実行の失敗ではないため、中断判定までのステップは加算されます。
中断判定までのステップ数には「中断判定」も含まれます。
合計のステップ消費数は4です。

次の図は、中断判定のシナリオがfalseの場合のステップ消費数の例です。

条件がfalseの場合は、中断判定の後続のステップを実行します。
中断判定のシナリオでは、falseの場合は個人情報管理アプリへレコードを転記します。
そのため、ステップ消費数は「中断判定までのステップ数 + 中断判定の後続のステップ数」で計算できます。
図の例では、中断判定のあとに6ステップを消費しています。
合計のステップ消費数は4 + 6 = 10です。

本記事では、連携コネクタの「シナリオ制御」機能を紹介しました。
シナリオ制御では、条件分岐、スキップ判定、中断判定の3つのアクションを使えます。
条件の判定結果によって実行されるステップが変わるため、ステップ消費数も変わります。

課金対象となるステップの詳細は、 課金対象となるステップについて を参照してください。

条件に合わせて処理を変えたいときは、実際の業務に取り入れてみてください。