プラグインなしでAirtableのメールアドレスを検証する方法

Airtableは、多くのチームが連絡先を管理している場所です。登録フォームがベースにデータを送り込み、Interfaceがリードを集め、先週のイベントリストがCSVインポートで取り込まれます。しかし、Airtableのメールフィールドが確認するのは、アドレスの形式がそれらしく見えるかどうかだけです。メールボックスが実在するか、使い捨てのアドレスか、最初の送信でハードバウンスしないかは判断できません。このガイドでは、Qualisendを使ってAirtableのメールアドレスを検証する実用的な方法を2つ紹介します。1つは、新規レコードごとに短いスクリプトを実行するオートメーションによるリアルタイムの検証、もう1つは、ビューをCSVにエクスポートして行う一括検証です。どちらもネイティブのプラグインは不要です（現時点では提供していません）。Airtable標準のオートメーションかエクスポートボタンがあれば実現できます。

結論#

回答が必要なタイミングに合わせて、方法を選んでください。

• リアルタイム：Run a scriptアクションを使った、AirtableのAutomationを作成します。新規（または更新）レコードごとにメールアドレスを読み取り、fetchでQualisend APIを呼び出して、判定結果を同じ行のフィールドに書き戻します。レコードにstatusとscoreが付くので、絞り込み、グループ化、振り分けに使えます。
• 一括：テーブルまたはビューをCSVにエクスポートし、Qualisendの一括検証にかけて、クリーニング済みのファイルを再インポートします。ベースにすでにあるすべてのレコードに、ステータス列を一括で付与できます。

Airtableのメールフィールドだけでは不十分な理由#

AirtableのEmailフィールドタイプが行うのは形式チェックだけです。@とドメインがあるか、明らかに不正な文字列がないかを確認します。これは正規表現と同じ種類のチェックで、失敗する理由も同じです。形式が正しくてもメールが届くとは限りません。jane@gmial.comは形式チェックを通過します。throwaway@mailinator.comも通過します。昨年ひっそり閉鎖されたドメインの、もっともらしい見た目のアドレスも通過します。

これらは送信するまで検出されません。その時点では、無効なアドレスはハードバウンスとなり、バウンス率と送信者レピュテーションを少しずつ損ないます。本格的な検証では、スプレッドシートにはできないチェックが加わります。DNS/MXの照会、SMTPによるメールボックスのプローブ、さらに使い捨て、役割アドレス、キャッチオールのフラグです。この仕組みが初めての方は、入門としてメールアドレス検証が実際に確認することをご覧ください。

Airtableでメールアドレスを検証する2つの方法#

最初に重要な制約があります。検証は、行が作成された後に行われます。行を作成したフォームやInterfaceで、入力途中に検証を行って送信をブロックすることはできません。Airtableには、外部APIの呼び出し結果によって入力途中の送信を止める公式の方法がないためです。そのため、レコードが届いた時点で検証し、判定結果に応じて対処します。以下の2つの方法は、この前提に沿っています。

多くのチームは両方を組み合わせています。リアルタイムの受け付けにはスクリプトを使い、追加後に古くなったアドレスを見つけるために、ときどきリストのクリーニングを行います。

方法1：Airtableのオートメーションによるリアルタイム検証#

Airtableのオートメーションでは、Run a scriptアクションでJavaScriptを実行でき、そのコードからfetchで外部APIを呼び出せます。Airtableの外に出ることなくレコードを検証するのに必要なものは、これで揃います。

1. トリガーを選びます。 Automationsでオートメーションを作成し、トリガーを選択します。

• When a record is created：フォームやInterfaceが新しい行を追加する場合に最も簡単です。
• When a record matches conditions（例：Email status is empty）：検証済みの行をスキップしたい場合に向いています。
• When a record enters a view：Email status = emptyで絞り込んだビューを指定すると、再実行されても同じアドレスに二重に課金されません。

2. 「Run a script」アクションを追加し、アクションの左側のパネルで2つの入力変数を設定します。emailにはトリガーとなったレコードのメールフィールドを、recordIdにはそのレコードのAirtableレコードIDを割り当てます。スクリプトはinput.config()でこれらを読み取ります。

3. スクリプトを作成します。 Qualisendを呼び出し、判定結果を同じ行に書き戻します。正確なエンドポイントとリクエストの形式は開発者向けドキュメントで確認してください。以下のプレースホルダーは、ご自身の値に置き換えてください。

// Airtable automation → "Run a script" action.
// Input variables (set in the action's left panel):
//   email     → the triggering record's email field
//   recordId  → the triggering record's record ID
let { email, recordId } = input.config();

let table = base.getTable("Contacts");

try {
  let response = await fetch("https://app.qualisend.com/api/v1/verify", {
    method: "POST",
    headers: {
      // Use a scoped, verify-only key — see the note below on key safety.
      "Authorization": "Bearer YOUR_API_KEY",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ email }),
  });
  // 402 (out of credits), 429 (rate limited) or 5xx: fail open in the catch below.
  if (!response.ok) throw new Error(`Qualisend returned ${response.status}`);

  // Response shape: { job_id, result: { status, score, reason, sub_flags, smtp } }
  let { job_id, result } = await response.json();

  if (result.smtp === "pending") {
    // The mailbox probe is still running, so result.status is only a
    // preliminary "unknown". Park the job ID; the follow-up script writes
    // the final verdict.
    await table.updateRecordAsync(recordId, {
      "Email status": "pending",
      "Qualisend job ID": job_id,
    });
  } else {
    await table.updateRecordAsync(recordId, {
      "Email status": result.status, // text: deliverable / risky / undeliverable / unknown
      "Email score": result.score,   // number: 0–100
    });
  }
} catch (err) {
  // Fail open: never lose a contact if the API is briefly unreachable.
  await table.updateRecordAsync(recordId, { "Email status": "unknown" });
}

4. 保留中の判定結果を取得します。 レスポンスはすぐに返りますが、その時点ではSMTPによるメールボックスのチェックがまだ実行中のことがあります。その場合、result.smtpは"pending"で、result.statusは暫定的なunknownにすぎません。そのため、スクリプトはjob_idをQualisend job IDテキストフィールドに保存しておきます。At a scheduled timeトリガーとRun a scriptアクションを使った2つ目のオートメーションを追加し、保留中の各行の最終的な判定結果をGET /jobs/{job_id}から読み取ります。/verifyを再度呼び出すことはないため、同じアドレスに二重に課金されません。

// Second automation: "At a scheduled time" trigger → "Run a script" action.
// Writes the final verdict onto every row the first script left "pending".
let table = base.getTable("Contacts");
let query = await table.selectRecordsAsync({
  fields: ["Email status", "Qualisend job ID"],
});

for (let record of query.records) {
  if (record.getCellValueAsString("Email status") !== "pending") continue;

  let jobId = record.getCellValueAsString("Qualisend job ID");
  let response = await fetch(
    `https://app.qualisend.com/api/v1/jobs/${jobId}?include=results`,
    { headers: { "Authorization": "Bearer YOUR_API_KEY" } },
  );
  if (!response.ok) continue; // leave it pending; the next run retries

  let job = await response.json();
  if (job.status === "pending" || job.status === "processing") continue; // still probing

  let final = (job.results || [])[0] || { status: "unknown", score: null };
  await table.updateRecordAsync(record.id, {
    "Email status": final.status,
    "Email score": final.score,
  });
}

安定して安全に運用するためのポイントは次のとおりです。

• スコープ付きのキーを使います。 Airtableのオートメーションのスクリプトでは、キーがスクリプトのテキスト内に保存され、ベースの共同編集者なら誰でも読めます。このようなスニペットには、サーバー側のシークレットストアもありません。そのため、このオートメーション用には、フルアクセスのキーではなくverify専用のスコープ付きキーを発行してください。万一漏えいしても、アドレスの検証と検証結果の読み取りはできますが、アカウント、APIキー、請求情報は変更できません。キーのスコープの設定方法は開発者向けドキュメントで確認できます。これは、サーバーレスでの登録時の検証パターンにある「キーをサーバー側に置く」というルールに相当する、Airtableでの対策です。
• フェイルオープンにします。 リクエストがエラーやタイムアウトになった場合や、402（クレジット不足）、429（レート制限）、5xxが返った場合も、レコードを捨てないでください。catchブロックがunknownを書き込むので、担当者や後の再実行で拾えます。検証APIは品質のフィルターであり、認証のゲートではありません。一時的な障害のために、本物のリードを削除してはいけません。
• 再トリガーのループを避けます。 トリガーがWhen a record is updatedの場合は、「任意のフィールド」ではなく特定のフィールド（メールフィールド）を監視してください。そうしないと、上記の書き戻しによってオートメーションが自分自身を再び起動してしまいます。レコードの作成や、絞り込んだビューをトリガーにすれば、この問題は完全に避けられます。
• フィールドタイプを合わせます。 1行テキストフィールドへの書き込みでは、ステータスの文字列がそのまま入ります。単一選択を使いたい場合は{ name: result.status }を渡し、書き込みが失敗しないよう、5つの選択肢（deliverable、risky、undeliverable、unknown、pending）を事前に作成しておきます。

検証の呼び出し自体は言語に依存しないため、スタックの一部がAirtableの外にある場合も、TypeformのウェブフックやZapierのCustom Requestから同じリクエストを送れます。Airtable固有なのは、上記のinput.config()とupdateRecordAsyncの部分だけです。

方法2：CSVエクスポートの一括検証#

すでにベースに連絡先が大量にある場合や、行ごとにスクリプトを実行するよりスケジュールに沿ってクリーニングしたい場合は、バッチで進めます。レコードごとのオートメーションがプランの実行回数の上限を使い切ってしまう場合にも、この方法が適しています。

1. ビューをCSVにエクスポートします。 グリッドでビューのメニュー → Download CSVを開きます（必要な行だけをエクスポートするには、先にビューを絞り込んでおきます）。1レコードにつき1行で、メールアドレスは専用の列に入ります。
2. ファイルを一括検証にかけます。 Qualisendが、MX、SMTP、使い捨て／役割アドレス／キャッチオールのフラグを含む全工程を、すべての行に適用します。
3. 注釈付きのファイルをダウンロードします。 各アドレスには、status、reasonコード、0～100のscoreが付いて返されます。
4. Airtableに再インポートします。 クリーニング済みのCSVをメール列で照合しながら取り込み、ベース全体にステータスフィールドを付与します。その後、次回の送信前にundeliverableを抑制し、riskyの行は慎重に扱います。一連の流れはメールリストのクリーニング方法で解説しています。

一括検証は過去の分を片付けるのに適していますが、予防ではなく後始末です。ここで見つかるアドレスは、たいていすでにベースに残っていたものです。定期的な一括処理と方法1のオートメーションを組み合わせ、新しい不正なアドレスが届いた時点でフラグが付くようにしましょう。

判定結果への対応#

どちらの方法で結果を受け取っても、構成は同じです。status、reason、score、sub_flagsの4つです。それぞれを次の対応にマッピングします。

判定結果がフィールドに保存されるので、以降の処理はAirtableの通常のフィルターで済みます。Email status = deliverableの「クリーンなリスト」ビューや、undeliverableの抑制ビューなどです。各ステータスにどのように行き着くかについては、メールアドレス検証の仕組みをご覧ください。

導入の準備はできましたか？スコープ付きのverify専用キーと正確なリクエスト形式は開発者向けドキュメントで確認できます。1件のアドレスは無料メールチェッカーで試せます。また、どのプランでも利用できる100の無料クレジットで、導入を決める前に両方の方法を最初から最後まで試せます。