MakeとAirtableを連携する方法｜受付データの検索・追加・更新

受付ごとに変わらないIDを決める

完成形は「受付IDが同じなら既存行を更新し、異なるなら追加する」です。氏名は同姓同名、メールアドレスは変更があるため、今回の照合には使いません。フォームの送信単位で変わらないrequest_idを渡し、Airtable側にも同じ値を保存します。これは推奨構成の例で、実行結果の報告ではありません。

- 入力例：request_id=REQ-1001、subject=資料請求、status=new。

- 保存先：受付ID、件名、受付日時、処理状態。担当者メモは自動更新から外す。

接続先のベースとテーブルを限定する

練習用ベースに受付テーブルを作り、MakeのAirtable接続で必要なベースへのアクセスを許可します。接続方式ごとの認可範囲を確認し、使わないベースへ広げないようにします。表の列名だけでなく型も決め、状態は選択肢、受付日時は日付、受付IDは文字列として扱います。

検索結果が出ない場合の流れを作る

AirtableのSearch Recordsで受付IDを完全一致させる条件を指定します。式へ外部の入力をそのまま連結すると引用符などで条件が変わるため、IDの文字種を制限してください。検索で0件のとき、後続へ空の出力を渡す設定が使えるかを確認します。0件で出力自体がなくなる構成では、後ろのRouterへも届かず、新規追加されません。

0件・1件・複数件を別々に扱う

0件ならCreate a Recordで追加し、1件なら検索で返ったRecord IDを使ってUpdate a Recordへ進めます。2件以上なら先頭を選ばず、確認待ちへ回します。検索上限を1件にすると重複を発見できないため、少なくとも複数件を識別できる件数で試してください。モジュールが複数出力する場合は件数を集計してから判断します。

項目の対応と空欄の意味をそろえる

request_idは受付ID、subjectは件名、received_atは受付日時へ割り当てます。更新では自動化が管理する列だけを書き換え、人が追記した担当者メモを保持します。「値がない」と「既存値を消す」は別の指示です。空欄の入力で既存値が消えないかを先に確かめ、削除が必要な項目には明示的な操作を設けます。

再送と同時実行を試す

REQ-1001を初回・同じ内容の再送・件名変更の順で処理し、保存件数が増えず件名だけ更新されることを確認します。同じIDの2件が同時に検索すると両方が0件と判断するおそれがあり、検索と追加だけでは一意性を保証できません。必要に応じて入口を直列化するか、一意制約を持つ別の保存基盤で受付を確定させます。

書き込み結果を照合して運用へ移す

接続拒否、選択肢の不一致、途中で追加だけ成功した場合も試します。成功したRecord IDと受付IDを記録してから再実行の範囲を決めてください。費用は検索だけでなく追加・更新・集計・再試行も含めて見積もります。単純なフォーム保存だけならAirtable単体で足りる場合もあるため、複数サービスをつなぐ必要があるかを先に判断します。

• Airtableで問い合わせ管理表を作る｜受付・担当・対応状況の設計
• Makeの重複登録を防ぐ｜受付ID・Data store・再実行の設計
• Makeのクレジット計算｜定期実行・複数行・再実行を数える