空欄・全角・想定外の値で自動化が壊れる:入力データの落とし穴と対策

先に知っておくフィルタの性質

各ツールの公式ヘルプで確認できた範囲は次のとおりです(確認日は2026年10月28日)。

• Make:フィルタは2つのモジュールの間に置け、条件を満たさないバンドルは処理が終了します。「Exists」は項目が入力されているかを見る演算子で、反対の演算子もあります(Makeのフィルタ)。
• Zapier:フィルタは指定した条件を満たすデータだけにアクションを実行させます。ルールには「テキスト用」「数値用」などの型の区別があり、型に合わないルールは使えません。ヘルプによると、フィルタはProfessional、Team、Enterpriseプランで使える扱いです(Zapierのフィルタ)。また、テキストのルールは大文字小文字を区別しない、と書かれています(フィルタルールの種類)。
• n8n:Filterノードは条件に合うアイテムだけを通し、条件はANDかORのどちらかで束ねます(混在はできません)。文字列・数値・日時などの型ごとに「存在する」「空である」などの比較があります。「Ignore Case」と、型の違いでエラーが出るときに値の型変換を試みる「Less Strict Type Validation」も選べます(n8n Filterノード)。Ifノードはワークフローを条件で分岐させ、「is empty」「is not empty」なども使えます(n8n Ifノード)。

一方、公式ページを読んだ範囲では、「Exists」や「is empty」が空白だけの文字列や「0」をどう扱うかは確認できませんでした。ここは推測せず、後述のテストで自分の環境の挙動を見てください。

ここから設計の原則が出ます。「落とす」だけでは足りず、「落とすものを人に回す」分岐が必要です。n8nなら、Filterの代わりにIfノードで分岐し、合わない側をスプレッドシートへの記録や通知につなげられます。ZapierやMakeでも、各ツールの分岐機能で同じ構成にできます。

よくある入力の揺れ一覧

次の表は、説明用の例です。「申込フォームの参加人数」と「連絡先メール」を扱う自動化を想定しています。

• 空欄、入力例：(未入力)、起きやすい問題：後続の項目が空のまま、メールが宛先なしで失敗、対処：必須項目は入口で存在確認
• 空白だけ、入力例：「 」(スペース1つ)、起きやすい問題：空欄ではないと判定され通過する可能性、対処：空白除去してから判定
• 前後の空白、入力例：「 taro@example.com 」、起きやすい問題：完全一致の比較が外れる、対処：空白除去
• 全角数字、入力例：「３」、起きやすい問題：数値として扱われない、比較でエラー、対処：半角へ変換。無理なら人へ
• 単位・記号つき、入力例：「3名」「1,200円」、起きやすい問題：数値変換に失敗、対処：数字だけ抜く、または人へ
• 数値欄の文字、入力例：「未定」「-」「N/A」「なし」、起きやすい問題：計算・大小比較が失敗、対処：数値判定に通らなければ人へ
• 想定外の大きさ、入力例：「300」「-1」「0」、起きやすい問題：在庫・金額の誤処理、対処：範囲条件(1〜20など)で弾く
• 全角の記号、入力例：「taro@example.com」(全角@)、起きやすい問題：宛先不正で送信エラー、対処：半角化、それでも不正なら人へ
• 表記ゆれ、入力例：「東京」「東京都」「とうきょう」、起きやすい問題：条件分岐のどれにも当たらない、対処：許可リストにない値は人へ
• 大文字小文字、入力例：「Yes」「YES」「yes」、起きやすい問題：比較が一致しない(ツール・設定による)、対処：大文字小文字を無視する設定を確認
• 日付の書き方、入力例：「2026/10/5」「10月5日」、起きやすい問題：日付型に変換できない、対処：形式を統一、変換不可は人へ
• 改行・複数値、入力例：「A\nB」、起きやすい問題：1件のつもりが複数件扱い、対処：改行を含むものは人へ

大文字小文字は、Zapierのテキストルールは区別しない旨が公式に書かれています。n8nはIgnore Caseのオプションがあります。Makeは今回読んだページに記載がなかったため、テストで確認する項目に入れてください。

入口で弾く条件・人に回す条件の書き方

判定は次の順で行うと、条件が単純になります。順番が大事で、整える作業を先にしないと、全角や空白のせいで正しい値まで落ちます。

1. 整える:前後の空白を除去し、全角英数を半角にする。専用のテキスト加工ステップや式で行う
2. 必須チェック:必須項目が存在し、空でない
3. 型チェック:数値欄が数値として読める
4. 範囲チェック:数値が想定範囲に収まる
5. 許可リストチェック:選択肢系は、あらかじめ決めた値のどれかに一致する

入口で弾く(止めて記録する)条件の例

「弾く」は、自動処理を進めると確実に失敗するか、害が出るものに使います。説明用の書き方です。

弾く = 次のいずれか(OR)
  ・メール が 空 または 存在しない
  ・参加人数 が 空
  ・参加人数 が 数値として読めない(整えた後でも)

人に回す条件の例

「人に回す」は、機械では正否を決められないものです。人数が「300」のような極端な値は、誤入力かもしれないし本当かもしれません。

人に回す = 次のいずれか(OR)
  ・参加人数 が 21以上 または 0以下
  ・都道府県 が 許可リスト(47都道府県名)のどれにも一致しない
  ・備考 に 改行が含まれる

通す = 上のどちらにも当てはまらない(=弾く/人に回すの否定)

ここで「通す」条件を肯定形で書くより、「弾く」「人に回す」を先に判定し、残りを通すほうが、想定外の値の取りこぼしを見つけやすくなります。ただし、許可リストのように「正しい値の集合」が決まる項目だけは、肯定形で書くほうが安全です。

人に回すときは、次の情報を残すと対応が早くなります。

• 元の入力値(整える前のもの)
• 回した理由(例:「参加人数が範囲外」)
• 入力日時と、元データへのリンク

AIにテストデータと条件のたたき台を作らせる

条件の漏れは、揺れたデータを意図的に流すと見つかります。AIには、実データではなく説明用のダミーデータを作らせてください。氏名・メール・電話番号など個人情報や社内の機密は渡さないでください。

次の依頼文は、そのまま使える形です。

申込フォームの自動化をテストします。項目は次の3つです。
- メール(必須、半角の形式)
- 参加人数(必須、1〜20の整数)
- 都道府県(47都道府県名のどれか)

人が入力して起きそうな「揺れ」を含むテスト用の行を30件、
表(CSV形式)で作ってください。
・正常なものを5件、残りは空欄、空白のみ、全角数字、単位つき、
 「未定」などの文字、範囲外の数、全角@、表記ゆれ、改行入りなど
・メールは example.com のダミーのみ使い、実在の人物に見える名前は使わない
・各行の末尾に「期待する判定(通す/整えて通す/弾く/人に回す)」を付ける

AIが作る「期待する判定」は案にすぎません。自分の運用ルールと合っているか、人が読んで直してください。たとえば「全角数字は整えて通す」か「人に回す」かは、業務によって答えが違います。

手順:テストして、落ちたものを見える化する

1. テスト行をスプレッドシートに貼り、自動化のトリガーにつなぐ(本番の宛先や課金を伴う処理は、テスト用に切り離す)
2. 全行を流し、各行の結果(通った・弾かれた・人に回った)を比べる
3. 期待判定とずれた行を探す。特に、空白だけの行、「0」、全角数字が「空」「存在する」とどう判定されたかを確認する(公式ページで挙動が確認できなかった部分です)
4. n8nでは、型の違いでエラーになる場合に「Less Strict Type Validation」を試す。ただし、意図しない変換で誤って通すこともあるので、結果を必ず見る
5. 弾いたもの・人に回したものの記録先(シートや通知)を用意し、週に一度は件数を見る。件数が急に増えたら、フォーム側の入力欄の見直しの合図です

入口の前にフォーム側でも減らす

自動化側の条件を増やす前に、入力元で揺れを減らすほうが安く済む場合があります。たとえば、都道府県は選択式にする、人数は数値欄にする、必須項目を必須設定にする、といった対応です。ただし、使っているフォームやシートによってできる設定は違います。それでも人が自由に打てる欄が残るなら、上の検問が最後の守りになります。

最後に確認する項目

• 必須項目の空欄・空白だけを、弾けているか
• 弾いた・人に回したデータが、消えずに記録されているか
• 許可リストにない値が、黙って通っていないか
• 元の入力値が、整える前の形で残っているか
• Zapierのフィルタを使うなら、契約プランで使えるか(上記ヘルプでは有料プランの扱い)