Lark AutomationのIF/ELSE未対応を回避する「デフォルト+条件付き上書き」パターン

Lark Base（Bitable＝Lark内で使える業務データベース）のAutomation機能で、条件によって入れる値を変えたい場面があります。

流入元URLにドメインAが含まれていたら「流入元 = 広告LP（A）」、ドメインBが含まれていたら「流入元 = 広告LP（B）」、どれにも当てはまらなければ「その他LP」と入れたい。

普通のプログラミング言語なら IF/ELSE で書けます。ところがAutomationの設定画面をいくら探しても、Action（＝Automationが実行する処理）の中にIF/ELSEの分岐が見つかりません。これは設定ミスや見落としではなく、Lark Automationの仕様です。1本のAutomationの中で「もし〜なら〜、そうでなければ〜」という分岐は組めない作りになっています。

ここで「Larkじゃ無理か」と外部ツールに逃がす前に、知っておくと手が動く回避策があります。この記事では、Lark AutomationのIF/ELSE未対応という制約と、それを回避する「デフォルト値 + 条件付き上書き」パターンを、実装例つきでまとめます。後半では、Lark Automationで粘るか外部ツールに出すかの方式比較や、導入前に整理しておくチェックリストも置きました。

結論：1本で分岐せず、複数のAutomationを連鎖させる

回避策の骨子はこうです。

• Lark AutomationはAction内のIF/ELSE分岐に対応していない。これは仕様なので、機能追加を待っても解決しない
• 1本で分岐する代わりに、「デフォルト値を入れるAutomation × 1本」と「条件を満たしたときだけ値を上書きするAutomation × 必要な数」に分けて連鎖させる
• 上書きAutomationのトリガー条件に「対象フィールドがまだデフォルト値のままか」をチェックすると、多重上書きや無限ループを防げる

IF/ELSEを1本の中で書く発想を捨て、「とりあえずデフォルトを入れる役」と「該当したら書き換える役」を別々のAutomationに分担させる。これだけです。シンプルですが、ノーコードの範囲で最も壊れにくい組み方になります。

実話：5本のAutomationで「流入元の自動判別」を組んだ

ある業務システムで、複数の問い合わせフォームから1つの顧客管理テーブルへ自動転記する処理を組みました。要件は次の通りです。

• 公式サイトの問い合わせフォーム経由のレコード → 顧客管理テーブルへ転記
• 複数の広告LP（ドメインが違う）経由のレコード → 同じ顧客管理テーブルへ転記
• 顧客管理テーブルの「流入元」列は、レコードに入っているURLのドメインで自動判別する
  • ドメインA → 広告LP（A）
  • ドメインB → 広告LP（B）
  • 上記以外 → その他LP
• さらに「LINE経由」で届いたものは別の経路フラグを立てたい

この「URLのドメインで流入元を出し分ける」部分が、まさにIF/ELSEで書きたくなる処理です。Lark Automationで実装するには、ここを5本のAutomationに分けて連鎖させました。

「5本連鎖」と聞くと複雑に見えますが、各Automationは1つの役割しか持っていません。1本ずつ独立しているので、どこで止まったかの切り分けも、後からルールを足すのも楽でした。IF/ELSEで1本にまとめた巨大なAutomationより、結果的に運用しやすい形になっています。

設計の中核1：デフォルト値と判別ロジックを分ける

このパターンの肝は、転記するAutomation（AとB）には判別ロジックを一切入れず、デフォルト値を入れるだけにすることです。実際の値を出し分ける判別ロジックは、別のAutomation（C・D・E）に切り出します。

転記Automation（B：広告LP → 顧客管理テーブル）の中身はこうなります。

トリガー: 広告LP用テーブルにレコードが追加された
アクション: 顧客管理テーブルにレコードを追加
  - 流入元URL  ← 元レコードのURL
  - 名前        ← 元レコードの名前
  - 流入元      = 「その他LP」   ← デフォルト値で固定
  - 問合せ経路  = 「通常メール」  ← デフォルト値で固定

ここではドメインを見て出し分ける処理を書きません。どんなレコードでも、いったん「その他LP」という汎用カテゴリで入れてしまいます。

そのうえで、ドメインAに該当するものだけを後から書き換えるのが、上書きAutomation（D）の役目です。

トリガー: 顧客管理テーブルで条件を満たすレコードが追加・変更された
条件:
  - 流入元URL に ドメインA が含まれる
  - かつ 流入元 = 「その他LP」   ← ここが重要
アクション: レコードを編集
  - 流入元 = 「広告LP（A）」

トリガー条件に「流入元 = その他LP」というガードを入れているところがポイントです。これを入れずに「URLにドメインAが含まれる」だけを条件にすると、上書きで値が変わったあともレコードの変更を検知して再び発火し、上書きが繰り返されるリスクがあります。「まだデフォルト値のときだけ書き換える」と縛ることで、1回書き換えたら以降は黙る動きになります。

IF/ELSEが1本の中で書けない代わりに、ELSE側にあたる処理を「デフォルト値」が肩代わりし、IF側にあたる処理を「上書きAutomation」が肩代わりする。役割分担で分岐を再現していると考えると分かりやすいはずです。

設計の中核2：上書きの順序と排他を意識する

上書きAutomationが複数ある場合、先に書き換わったフィールドを後の上書きがさらに書き換えないように条件を組みます。

たとえば、広告LP（A）の判定が先に動いて「流入元 = 広告LP（A）」になったあと、広告LP（B）の判定も動いてしまうと、せっかく入れた値が上書きで壊れます。これを防ぐ手は単純で、広告LP（B）の上書きAutomationにも「流入元 = その他LP」のガードを入れておくこと。

条件:
  - 流入元URL に ドメインB が含まれる
  - かつ 流入元 = 「その他LP」   ← すでにAに上書き済みなら発火しない
アクション: レコードを編集
  - 流入元 = 「広告LP（B）」

これで「最初にどちらかの上書きが成功したら、もう一方は手を出さない」という排他的な動きになります。複数のIF条件を順番に評価して最初に一致したものを採用する、というIF/ELSE IFの挙動を、ガード条件で再現している形です。

設計の中核3：「初回対応日時」のNOW()問題

似た構図でつまずきやすいのが、日時の自動セットです。「対応状況が初めて変更されたとき、その時刻を初回対応日時の列に記録したい」というユースケースを考えます。

Lark AutomationにはNOW()（＝実行時点の現在日時を返す関数）がアクション内で使えます。ところがIF/ELSEがないため、対応状況が変わるたびにNOW()が走り、初回対応日時が毎回最新の時刻で上書きされてしまいます。これでは「初回」になりません。

これも同じパターンで解けます。

F: 対応状況変更 → 初回対応日時セット
  トリガー: 対応状況が変更された
  条件:
    - 対応状況 ≠ 「未対応」      ← 初めて対応に動いた時だけ
    - かつ 初回対応日時 = 空欄    ← すでにセット済みなら発火しない
  アクション: 初回対応日時 = NOW()

「初回対応日時が空欄のときだけ書き込む」というガードが、2回目以降のNOW()上書きを止めてくれる。値の上書きでも日時の記録でも、考え方は共通です。「デフォルト状態（空欄やその他LP）のときだけ書き込む」と条件で縛れば、IF/ELSEなしでも一度きりの処理が組める。

なお、こうしたノーコードの自動化（Automation）ではなく、プログラムから直接Larkのデータを読み書きしたい場合は、Lark BitableのAPIで業務データベースを作る設計の側にまとめてあります。本記事はあくまでAutomation（画面で組むノーコード自動化）でどこまで粘れるか、という話。

Before / After：このパターンで運用がどう変わるか

「IF/ELSEがない」を制約のまま受け止めると手が止まります。デフォルト+上書きに発想を切り替えると、運用は次のように変わります。

数が増えるのは一見デメリットに見えます。実際には「1本=1責務」のほうが、運用担当が後から触るときの心理的なハードルは下がります。

Lark Automationで粘るか、外部ツールに出すか

「条件分岐できないなら、n8nやCloud Runのような外部の自動化ツールに逃がせばいい」と考える人もいます。確かに、n8n（＝サーバーに立てて使うワークフロー自動化ツール）なら1本のワークフローで分岐まで完結します。それでもまずLark Automationで組めないか検討する価値があるので、判断材料を表で並べます。

外部ツールが向く場面は確かにあります。一方で、Lark内のテーブル間で値を出し分けるだけなら、外部ツールを足すと「壊れる箇所」と「触れる人の少なさ」という運用コストを抱え込むことになります。Lark内で完結する処理は、まずLark Automationで組めるかを試すのが運用負担の面で有利です。これは「動き続けることを機能の豊かさより優先する」という壊れにくさ優先の考え方とも合います。

このパターンが向かないケース

デフォルト+条件付き上書きは万能ではありません。次のような処理は、無理にLark Automationで粘らず外部ツールを検討したほうが楽です。

• 分岐の数が多すぎる：出し分けるパターンが十数通りあると、上書きAutomationが大量になり全体が追いにくくなる
• Lark外のサービスと連携する：外部APIを叩く、別システムへ書き戻すなど、Larkの外に処理が出るものはAutomationの守備範囲外
• 1レコードに対して複雑な計算が必要：多段の集計や条件付きの計算を組むなら、ワークフローツールやスクリプトのほうが見通しが良い
• リアルタイム性が厳しい：上書きは連鎖で順に走るため、ミリ秒単位の即時反映が要る用途には向かない

「Lark内のテーブルで、列の値を条件で出し分けたい・フラグを立てたい」という範囲に収まるなら、このパターンの費用対効果が高くなります。

導入前チェックリスト

実際に組む前に、次を整理しておくと設計がぶれません。自分で組む場合も、外部に依頼する場合も、最初に詰めておく項目です。

• 出し分けたい列は何か（流入元・経路・ステータスなど、デフォルト値を持つ列を決める）
• デフォルト値は何にするか（どれにも該当しないときの汎用カテゴリ。例「その他LP」「未分類」）
• 上書き条件は何通りか（ドメイン・キーワードなど、判別ルールを列挙する。これが上書きAutomationの本数になる）
• 上書きの排他をどう取るか（先に書き換わったら後が発火しないよう、各上書きにガード条件を入れる）
• 一度きりにしたい処理はあるか（初回対応日時のように、空欄のときだけ書き込むガードが要るか）
• Lark内で完結するか（外部サービス連携が混ざるなら、その部分は外部ツールに切り出す前提で設計する）

この6つが決まれば、あとは転記Automation1本に上書きAutomationを必要な本数つなぐだけで組み上がります。

アンチパターン3つ

アンチパターン1：「IF/ELSEがないからLarkは使えない」と諦める

「ノーコードツールは条件分岐ができないから本格運用には向かない」と決めつけて、最初から外部ツールに行くのは過剰設計になりがちです。Lark Automationで扱う業務ロジックの大半は、デフォルト+上書きで書けます。まずこのパターンで組めないか試してから、外部に逃がす判断をするのが順序として安全です。

アンチパターン2：上書きAutomationにガード条件を入れない

「流入元 = その他LP」のようなガードを省くと、レコードの変更を検知するたびに上書きが発火し、無限ループのリスクが出ます。Larkは過剰な実行を検知してAutomationを止めることもあるので、ガードは必須と考えてください。「まだデフォルト値のときだけ書き込む」を癖にします。

アンチパターン3：1本のAutomationに処理を詰め込む

「1本にまとめたほうが管理しやすい」と考えて1本に複数アクションを連結すると、途中の1アクションが失敗したときに後続が全部止まります。どこで失敗したかも追いにくくなる。1本=1責務に分けておけば、不具合の切り分けも後からのルール変更も1本ずつで済みます。

まとめ：「分岐できない」は「複数本に分解する」で解ける

Lark AutomationのIF/ELSE未対応は、初見だと致命的な制約に見えます。実際には「デフォルト値 + 条件付き上書き」パターンで、流入元の自動判別から初回対応日時の記録まで、大半のユースケースをノーコードのまま組めます。

設計の勘どころは3つです。

1. 転記Automationはデフォルト値を入れるだけにして、判別ロジックを別Automationに切り出す
2. 上書きAutomationは1判定=1本に分け、トリガー条件にガード（まだデフォルト値か）を入れて多重上書きを防ぐ
3. Lark内で完結する処理はまずAutomationで組み、外部連携や重い処理だけ外部ツールに逃がす

Larkを業務システムとして使う組織なら、この順序で考えると運用負担を小さく保てます。IF/ELSEという1本の発想を手放して、役割ごとに分けて連鎖させる。これがLark Automationの設計の基本になります。

Lark Base運用・Automation設計でお困りなら

Lark Base / Bitableを業務システムとして回していると、「IF/ELSEで分岐したいのに組めない」「Automation同士が重複して値を上書きし合う」「担当者しか設定の中身を把握していない」といった詰まりが出てきます。多くは設計パターンの問題で、組み直せば解けます。

f2t.jpでは、Lark Base運用の棚卸しから、Automationの設計・整理、Lark内で組むべきか外部ツールに出すべきかの切り分けまでお手伝いしています。まずは「どの処理をAutomationで組み、どこから外部に出すか・属人化をどう減らすか」を一緒に整理するところから始められます。お問い合わせフォームから、自社のLark運用の困りごとをご相談ください。