レッスン2：共通の設計言語①——トリガー・アクション・条件分岐

このレッスンで学ぶこと

自動化の3要素であるトリガー・アクション・条件分岐を説明できる
業務の流れを Mermaid の図で書き出す手順を身につける
順次・分岐・繰り返しという、処理の3つの基本パターンを理解する
エラーが起きたときの分岐を、あらかじめ設計に組み込める
あえて手作業を残すべき場面を判断できる

前のレッスンでは、ノーコード・ローコードの全体像と、本コースが繰り返す6つの中核メッセージを確認しました。その2つ目に「ツールは変わりますが、変わらないのはトリガー・アクション・条件分岐という組み立て方です」というメッセージがありました。このレッスンでは、その組み立て方そのものを、じっくり扱います。

自動化の3要素——トリガー・アクション・条件分岐

どのノーコードツールも、画面の見た目や用語は異なりますが、内側で動いている考え方は共通しています。その共通言語が、トリガー・アクション・条件分岐の3つです。

トリガーとは、仕組みが動き出すきっかけのことです。「フォームが送信された」「決まった時刻になった」「表に新しい行が追加された」といった出来事が、トリガーにあたります。トリガーがなければ、どんな仕組みも動き出しません。

アクションとは、トリガーをきっかけに実行される処理のことです。「メールを送る」「表に行を追加する」「通知を出す」「別の仕組みを呼び出す」といった、実際に何かを行う部分がアクションです。1つのトリガーに対して、複数のアクションが連なることもよくあります。

条件分岐とは、状況に応じて異なるアクションへ進ませる仕組みのことです。「金額が10万円を超えていたら上長に回す、それ以外は自動承認する」というように、条件によって行き先を変えます。条件分岐がなければ、仕組みは常に同じ動きしかできません。

💡 ポイント トリガー・アクション・条件分岐は、日本語で言い換えると「何がきっかけで」「何をして」「どう分岐するか」です。この3つの組み合わせで、業務の自動化はほぼすべて説明できます。ツールの画面が変わっても、この3つを探せば読み解けます。

具体的な例で考えてみましょう。「経費申請フォームが送信されたら、金額が3万円以下なら自動で承認済みにし、3万円を超えていたら上長に確認の通知を送る」という仕組みは、次のように分解できます。

トリガー：経費申請フォームが送信された
条件分岐：金額が3万円以下かどうか
アクション（3万円以下の場合）：承認済みの状態にして、申請者に通知する
アクション（3万円を超える場合）：上長に確認の通知を送る

この分解ができれば、実際にどのツールの画面を開いても、迷わず設定を進められます。

もう1つ、別の業務でも確認しておきましょう。「在庫の数が5個を下回ったら、担当者にメールで知らせる」という仕組みは、次のように分解できます。

トリガー：在庫を記録している表の数値が変わった
条件分岐：在庫の数が5個を下回っているかどうか
アクション（下回っている場合）：担当者にメールを送る
アクション（下回っていない場合）：何もしない

2つの例を見比べると、業務の内容はまったく異なっていても、分解の型は同じであることに気づきます。「何がきっかけで」「どう分岐し」「何が実行されるか」という3つの問いに答えられれば、業務の種類を問わず設計に落とし込めます。

📝 補足 アクションは1つとは限りません。「表に記録する」「担当者に通知する」「関連する別の表も更新する」というように、1つのトリガーから複数のアクションが連なって実行されることもよくあります。順番に並べるだけなので、難しく考える必要はありません。

業務の流れを Mermaid で書き出す手順

ノーコードで仕組みを作るとき、いきなりツールの画面を開いて手を動かすのは遠回りです。先に、業務の流れを紙やホワイトボード、あるいは本コースで扱う Mermaid のような図で書き出しておくと、迷いが大きく減ります。

書き出す手順は、次の4段階です。

始まりと終わりを決める：この業務は何をきっかけに始まり、何をもって完了とするかを最初に言葉にします
登場する人と持ち物を洗い出す：誰が関わり、どんな情報（申請書、金額、日付など）が動くかを箇条書きにします
判断が変わる場所を探す：「もし〜なら」という分岐がどこにあるかを見つけます
図に起こす：トリガー・アクション・条件分岐の記号を使い、始まりから終わりまでを一本の流れとしてつなぎます

先ほどの経費申請の例を、実際に図にすると、次のようになります。

flowchart TD
  A[経費申請フォームが送信された] --> B{金額は3万円以下か}
  B -->|はい| C[自動で承認済みにする]
  C --> D[申請者に通知する]
  B -->|いいえ| E[上長に確認の通知を送る]
  E --> F[上長が承認する]
  F --> D

この図は、四角形をアクション、ひし形を条件分岐として表しています。矢印をたどるだけで、業務の全体像が一目でつかめます。文章だけで説明するより、関係者との認識合わせもずっと速く進みます。

📝 補足 図を書く目的は「きれいな図を作ること」ではありません。書き出す途中で「あれ、この場合はどうするのだったか」という抜け漏れに気づくことこそが、最大の価値です。ツールに向かう前に、この気づきを済ませておきます。

順次・分岐・繰り返し——処理の3つの基本パターン

トリガー・アクション・条件分岐を組み合わせるとき、処理の流れ方には3つの基本パターンがあります。

順次は、決められた順番どおりに、1つずつ処理を進める最も基本的なパターンです。「フォームが送信されたら、まず表に記録し、次にメールを送る」というように、上から下へ流れます。

分岐は、条件によって進む道が分岐するパターンです。先ほどの経費申請の例が、これにあたります。分岐は1回とは限らず、金額に応じて3段階、4段階に分岐することもあります。

繰り返しは、同じ処理を、対象を変えながら何度も行うパターンです。「表にある未処理の行を、1件ずつ順番にチェックして、条件に合うものだけ通知する」というように、件数分だけ同じ処理が繰り返されます。

この3つの組み合わせだけで、業務の自動化のほとんどは表現できます。逆に言えば、複雑に見える仕組みも、順次・分岐・繰り返しに分解していけば、必ず整理できるということです。

「繰り返し」を図にすると、次のようになります。表の行を1件ずつ確認し、条件に合う行だけ通知する、という流れです。

flowchart TD
  A[表の未処理の行を1件取り出す] --> B{条件に合うか}
  B -->|はい| C[通知する]
  B -->|いいえ| D[何もしない]
  C --> E{ほかに未処理の行があるか}
  D --> E
  E -->|はい| A
  E -->|いいえ| F[繰り返しを終了する]

矢印が A に戻ってきている部分が「繰り返し」を表しています。すべての行を確認し終えたら、繰り返しを抜けて終了します。

🔰 初学者の方へ 「繰り返し」は、慣れないうちは最もイメージしづらいパターンです。「表の行を上から1行ずつ、同じ確認作業をしている」という具体的な光景を思い浮かべると理解しやすくなります。

エラーが起きたときの分岐

業務の流れを設計するとき、うまくいく場合だけを考えがちですが、うまくいかない場合の分岐も、あらかじめ用意しておく必要があります。これを怠ると、仕組みが止まったことに誰も気づかないまま、業務が滞ってしまいます。

エラーが起きる典型的な場面には、次のようなものがあります。

必須の項目が空欄のまま送信された
つなぎ先のサービスが一時的に応答しない
想定していない形式のデータが入ってきた
承認する人が長期不在で、確認が進まない

これらに対しては、「エラーが起きたら、担当者に通知して人の目で確認する」という分岐を、最初から流れの中に組み込んでおきます。

flowchart TD
  A[処理を実行する] --> B{正常に完了したか}
  B -->|はい| C[通常の流れを続ける]
  B -->|いいえ| D[担当者にエラーを通知する]
  D --> E[人が確認して手動で対応する]

⚠️ 注意 「エラーは起きないはず」という前提で仕組みを作ると、実際にエラーが起きたときに誰も気づけません。うまくいかなかったときに「静かに失敗する」のではなく、「誰かに気づかせて止まる」ように設計しておくことが、止まらない仕組みの第一歩です。この考え方は、レッスン7でさらに詳しく扱います。

手作業を残す判断

トリガー・アクション・条件分岐を学ぶと、「すべてを自動化したい」という気持ちが生まれやすくなります。ですが、あえて手作業を残したほうがよい場面もあります。

発生する頻度が極めて低く、自動化の設定にかける時間のほうが長くなる作業
例外の判断に、人の経験や状況判断が欠かせない作業
自動化した結果を誰も検証しないまま進めてしまうと、被害が大きい作業（金額の大きい支払いなど）

このような場面では、無理に自動化せず、「一覧に表示して、人が最終確認をしてから実行する」という半自動の形にとどめる判断も、有効な設計です。すべてを自動の流れに乗せることが、必ずしも良い設計とは限りません。

判断の目安を、表に整理しておきます。

発生頻度	間違えたときの被害	向いている設計
高い	小さい	完全に自動化する
高い	大きい	自動で候補を出し、人が最終確認する
低い	小さい	手作業のままにする
低い	大きい	手作業のままにするか、確認の分岐を厚くする

「発生頻度が高く、間違えたときの被害が小さい」作業から自動化を始めると、失敗しても影響が小さく、経験を積みながら設計を育てられます。逆に、発生頻度が低く被害が大きい作業を最初から自動化しようとすると、検証が不十分なまま本番で使うことになりやすく、危険です。

💡 ポイント 自動化するかどうかの判断は、「手間が減るか」だけでなく、「間違えたときの被害の大きさ」も基準に入れます。頻度が低くても被害が大きい作業は、あえて人の確認を残す設計が安全です。

アクションの組み合わせ方——直列と並列

複数のアクションを連ねるとき、並べ方には大きく2つの型があります。

直列は、前のアクションの結果を、次のアクションが使う並べ方です。「表に記録してから、記録した内容をもとにメールの文面を作って送る」というように、順番が意味を持ちます。順番を入れ替えると、正しく動かなくなることがあります。

並列は、複数のアクションが互いに影響を与えず、同時に実行されてもかまわない並べ方です。「申請者に受付完了のメールを送る」ことと「管理用の表に記録する」ことは、たいてい互いに独立しており、どちらを先に行っても問題ありません。

すべてを直列でつなぐと、1つのアクションが遅れたとき、後続のすべてが待たされてしまいます。独立して実行できるアクションを見分け、直列と並列を使い分けることが、無駄のない設計につながります。

📖 もっと詳しく ツールによっては、並列に実行できるアクションの数や、1回の流れで使える合計の時間に上限が設けられていることがあります。細かい制限はツールごとに異なり、時期によっても変わるため、実際に使うツールの案内で確認する習慣を持ちましょう。

まとめ

このレッスンでは、以下のことを学びました。

自動化の3要素は、トリガー（きっかけ）・アクション（実行される処理）・条件分岐（分岐）である
業務の流れは、始まりと終わりを決める、登場人物と持ち物を洗い出す、判断の分岐点を探す、図に起こすという4段階で書き出す
処理の基本パターンは、順次・分岐・繰り返しの3つに整理できる
エラーが起きたときの分岐をあらかじめ組み込み、「静かに失敗する」のではなく「気づかせて止まる」設計にする
発生頻度が低い作業や、人の判断が欠かせない作業は、あえて手作業を残す判断も有効である

次のレッスンでは、もう1つの共通言語である「データの持ち方」を学びます。トリガー・アクション・条件分岐がどれだけうまく組み立てられていても、データの持ち方が崩れていると、あとで必ず作り直しになります。

確認クイズ

このレッスンの理解度をチェックしましょう。