Zapierでデータをマージする基本と実践方法

Zapierで複数のデータを1つにまとめたい時、Line Items、Looping、Paths、Webhooks、Storageなど似たような選択肢が出てきて、どれを使えばいいのか迷いやすいです。とくに、ループの結果を最後にまとめたい、分岐した処理を同じ後続ステップへ流したい、Mailchimpのmerge fieldsに値を入れたい、という場面はつまずきやすいところかなと思います。

Zapierは便利ですが、Pathsの後ろに共通ステップを置けないなど、思った通りにデータを合流できない制約もあります。だからこそ、最初に何をマージしたいのかを切り分けて、Formatter、Code、Webhooks、Storage、Digestなどを使い分けるのが大事ですよ。ここでは、調べた範囲の情報をもとに、Zapierでデータをマージする考え方を実務寄りに整理します。

Zapierでデータをマージする基本

Zapierでデータをマージしたい場面は、だいたい「複数の値を1つにまとめたい」「分岐した処理を最後に同じ流れへ戻したい」「ループで得た結果をまとめて次のステップへ渡したい」のどれかです。見た目は似ていますが、Zapier上では使う機能がかなり変わります。

ここで最初に大事なのは、マージという言葉を少し分解することです。Line Itemsをまとめるのか、Pathsの分岐を合流させたいのか、Loopingの結果を集約したいのかで、選ぶべき方法が変わります。ここを曖昧にしたまま作ると、同じ処理を何度もコピーしたり、API送信が想定より多く走ったりしやすいですよ。

まず何を結合したいか決める

Zapierでデータをマージする時は、いきなりFormatterやCodeステップを触るより、まず「何と何を、どの単位でまとめたいのか」を決めるのが近道です。たとえば、同じ人の作業データを1つの請求データにまとめたい場合と、分岐後に同じCRM更新処理へ進めたい場合では、設計がまったく違います。

よくあるのは、データの形を見ずに「マージしたい」と考えてしまうケースです。Zapierでは、単一のテキスト、複数フィールド、Line Items、ループ結果、WebhookのJSONなど、入力データの形によって扱いやすさが変わります。結合したい対象がリストなのか、条件分岐なのか、処理フローなのかを先に見るのが大事です。

マージしたい対象の切り分け表

ここでいうキーとは、まとめる基準になる値のことです。たとえば「担当者名」「顧客ID」「メールアドレス」「会社ID」などですね。同じ人のデータをまとめたいなら、名前だけではなく、できればIDやメールアドレスのようにブレにくい値を使う方が安全です。

最初の整理は少し地味ですが、ここを飛ばすと後から修正が大きくなります。あなたが作りたいZapが「データの整形」なのか「処理の合流」なのかを分けるだけでも、選ぶべき機能はかなり絞れますよ。

Line Itemsをまとめる考え方

Line Itemsは、複数の商品、複数のタスク、複数の請求明細のような「行のまとまり」を扱う時に出てくる考え方です。ZapierではアプリによってLine Itemsとして渡せることがありますが、テキストをSplit Textで分割して疑似的に行データのように扱うケースもあります。

たとえば、Person name、Project name、Task name、Hours worked、Hourly rateのような値が並んでいる場合、単純に分割するだけでは「どの名前にどの作業が紐づくのか」が分かりにくくなります。同じJohn Doeの作業を1つの請求にまとめたいなら、人ごとにグループ化する設計が必要です。

Line Itemsで確認したい項目

Line Itemsを扱う時に注意したいのは、見た目で同じ行に見えても、Zapier上では別フィールドとして扱われることがある点です。名前だけ、案件名だけ、時間だけがそれぞれ別のリストになると、途中で1つ欠けた時に対応関係が崩れます。これは請求や顧客管理ではかなり困ります。

対策としては、最初のCodeステップや取得元APIの段階で、できるだけ「1人分」「1案件分」のまとまりを作っておくことです。Zapier内で無理に複雑な結合をするより、取得時点でまとめやすい形に寄せる方が安定しやすいですよ。正確な仕様は連携先アプリによって変わるため、正確な情報は公式サイトをご確認ください。

Formatterで分割する注意点

Formatter by ZapierのSplit Textは、テキストを区切り文字で分割したい時に便利です。たとえば、ログ出力を特定の記号で区切って、segment indexをall as separate fieldsにすると、分割された値を後続ステップで使える形にできます。

ただし、Split Textは「分割」は得意でも、「意味を理解してグループ化する」機能ではありません。つまり、名前、案件名、タスク名、時間、単価のような情報を分割できても、同じ人の複数タスクを自動で1つの請求単位にまとめるところまでは別の設計が必要です。ここ、けっこう勘違いしやすいです。

⚙️ Formatterで起きやすいズレ

区切り文字を使う場合は、データの中に同じ記号が入らないかも見ておきたいところです。たとえばタスク名の中にカンマやプラス記号が入っていると、意図しない場所で分割されることがあります。シンプルな処理に見えて、実は入力データのきれいさにかなり左右されます。

Formatterは、軽い整形にはとても使いやすいです。一方で、複数条件でグループ化したり、配列を組み替えたり、同じ担当者ごとに明細をまとめたりするなら、Codeステップや取得元APIの出力調整を検討した方がよい場面もあります。Formatterで無理に全部やろうとしないのが、安定したZapを作るコツです。

Looping後に集約する方法

Looping by Zapierを使うと、複数のデータを1件ずつ処理できます。たとえば5件のデータを順番に処理する、ユーザーごとにAPIへ問い合わせる、明細ごとに値を整える、といった使い方です。ただし、ループ内に次のAPI送信ステップを置くと、そのステップもループ回数分だけ実行されます。

「5回のループ結果をまとめて、最後に1回だけHTTPで送信したい」という場合は、ループ中に送信するのではなく、ループの結果をどこかに集める設計が必要です。Zapierのコミュニティでも、Looping後の集約にはStorage、Digest、Lookup Table、Webhooksなどが選択肢として挙げられています。

Looping後の集約方法の比較

Loopingで大事なのは、ループ内でやる処理と、ループ後にやる処理を分けることです。各ユーザーの情報取得はループ内、全員分をまとめた送信はループ後、というように役割を分けると考えやすくなります。逆に、全部をループ内に入れると、通知やAPI送信が必要以上に増えることがあります。

もう1つの考え方として、先にユーザー一覧だけを取得し、Loopingで1人ずつ処理し、その中で必要なデータだけを出力する方法もあります。元のPythonコードやAPI取得処理を少し分けるだけで、Zapier側の複雑さが下がることもありますよ。処理回数やタスク消費はプランや設定に左右されるため、最新の条件はZapier公式の案内で確認してください。

Pathsは後続処理を共有できない

Paths by Zapierは、「条件Aならこの処理」「条件Bなら別の処理」という分岐を作る機能です。たとえばCRMで連絡先が見つかったら更新し、見つからなければ新規作成する、といった流れに使いやすいです。Filterが条件に合わない時点でZapを止めるのに対して、Pathsは複数の結果に応じた処理を作るイメージです。

ただし、Pathsで分岐したあとに「また1本の共通ステップへ戻す」ことは、Zapier上ではそのまま実現しにくいです。公式ヘルプでも、Pathsの後ろに全ブランチ共通のアクションを置くのではなく、各ブランチに複製するか、Sub-Zapなどに処理を分ける考え方が示されています。ここは仕様として押さえておきたいポイントです。

️ Pathsで迷いやすい設計パターン

共通処理を1か所にまとめたい場合は、各Pathの最後からWebhooks by Zapierで別のZapへデータを送る方法があります。受け取り側のZapをWebhookトリガーで始めて、そこにCRMのContact IDや必要な値を渡す形です。こうすると、共通処理の修正が1つのZapで済みやすくなります。

一方で、Zapが複数に分かれると、あとから見た時に全体像を追いにくくなることもあります。少ない分岐なら各Pathに同じ処理を置く、共通処理が長いならWebhookやSub-Zapに分ける、という判断が現実的です。メンテナンスしやすい方を選ぶという視点で決めると、あとで困りにくいですよ。

Zapierでデータをマージする実践

Zapierでデータをマージする時は、1つの機能だけで全部を解決しようとすると詰まりやすいです。Webhooksで別Zapへ渡す、Storageで一時保存する、Digestでまとめる、Lookup Tableで置換する、Codeで形を整えるなど、目的ごとに使い分けるのが現実的です。

ここでは、実際にどの場面でどの方法を選ぶとよいかを整理します。あなたが作りたいZapが「分岐後の共通処理」なのか、「ループ結果の集約」なのか、「フィールド名の反映」なのかを見ながら読むと判断しやすいですよ。

Webhooksで共通処理へ渡す

Pathsで分岐したあとに同じ処理をしたい場合、Zapierの中でそのまま1本に合流させるのは難しいです。そこで候補になるのが、Webhooks by Zapierで別のZapへデータを渡す方法です。分岐した各Pathの最後から同じWebhook URLへ送れば、後続処理を別Zap側にまとめられます。

たとえば、Path Aでは既存顧客を更新し、Path Bでは新規顧客を作成するとします。そのあとに「CRMへ活動履歴を追加する」「Slackへ通知する」「別ツールへ送信する」など同じ処理をしたいなら、各Pathの最後で必要な値をWebhookに送ります。別ZapはWebhook受信をトリガーにして、共通処理だけを担当する形です。

Webhooksに渡すデータの例

Webhooksを使うメリットは、共通処理を1か所で管理しやすいことです。同じSlack通知や同じCRM履歴追加を複数Pathにコピペすると、あとで文面や項目を変える時に漏れが出やすいです。共通処理を別Zapにしておけば、修正箇所を減らせます。

ただし、Zapが複数に分かれるので、全体像は少し追いにくくなります。業務で使うなら、Zap名やWebhookに渡す項目名を分かりやすくしておくと安心です。外部APIやWebhookの仕様は変わることがあるため、正確な情報は公式サイトをご確認ください。

Storageで一時保存する使い方

Storage by Zapierは、Zapの途中で値を一時的に保存したい時に使える機能です。Loopingの中で処理した値を保存し、あとで取り出して使うような設計に向いています。ざっくり言うと、Zapier内に小さなメモ置き場を作るイメージです。

Storageを使う時に大事なのは、キーをどう作るかです。キーとは、保存した値をあとで取り出すための名前です。たとえば顧客ID、注文ID、実行日、Zap Run IDのような値を組み合わせると、他の処理結果と混ざりにくくなります。

️ Storageを使う時の設計ポイント

Storageは便利ですが、何でも入れる場所として使うと管理が難しくなります。特に請求、顧客、契約に関わるデータを扱う場合は、保存する内容を必要最小限にした方がよいです。業務上の重要データを扱うなら、社内ルールや連携先サービスの扱いも確認しておきたいところです。

また、Storageは「データベースを本格的に作る機能」というより、Zapの処理を助ける一時保存に向いています。長期保存や検索、監査が必要なデータなら、Google Sheets、Airtable、専用DB、CRMなどを使う方が自然な場面もありますよ。

Digestで結果を集める方法

Digest by Zapierは、複数回発生したデータをためて、あとでまとめて出す時に使います。たとえば、1日分の通知をまとめる、複数のループ結果をまとめて送る、一定時間内のイベントを1つのメールにする、といった使い方です。

Loopingで処理した結果をすぐ送るのではなく、Digestに追加しておき、最後にまとめて取り出すという考え方ができます。個別送信が多すぎる時や、まとめて確認したい時には相性がいいです。通知疲れを減らしたい時にも使いやすいですね。

Digestが向いている場面

• 複数件の結果を1通のメールにまとめたい
• Slack通知を細かく出さず、一定単位で集約したい
• 日次や週次で処理結果を一覧にしたい
• ループごとの出力を後からまとめて見たい
• すぐにAPI送信せず、確認用の一覧を作りたい

注意点は、Digestは「いつ出すか」の設計が必要なことです。すぐに次のステップへ渡したい処理には合わない場合があります。たとえば、外部APIへ即時送信しなければならない業務なら、DigestでためるよりWebhooksやCodeで直接整形する方が合うこともあります。

Digestを使うなら、集める単位を先に決めましょう。顧客ごと、日付ごと、Zap実行ごと、担当者ごとなど、単位が曖昧だと関係ないデータが混ざります。まとめたい単位と出力タイミングをセットで決めるのがコツです。

Lookup Tableで変換する方法

Lookup Tableは、ある値を別の値に変換したい時に使います。たとえば、フォームの選択肢を社内コードへ変える、部門名を担当者メールに変える、ステータス名をAPI用の値に変える、という場面です。マージというより、マージ前後のデータをそろえる補助役として便利です。

たとえば、外部フォームでは「営業部」と入っているけれど、CRMでは「sales」という値で登録したい場合があります。この時、Lookup Tableで「営業部 → sales」の対応を作っておけば、後続ステップで扱いやすくなります。

Lookup Tableの使いどころ

Lookup Tableは、少数の決まった変換には向いています。ただし、数百件以上の大きな対応表や、頻繁に変わるマスターデータを管理するには不向きなことがあります。その場合は、Google Sheetsやデータベースを参照する形の方が運用しやすいです。

データをマージする前に値の表記をそろえると、後続の条件分岐や集計が安定します。「Sales」「営業」「営業部」が混ざっていると、同じ意味でも別データとして扱われやすいです。Lookup Tableは、こうした小さな表記ゆれを減らす場面で使うと効果的ですよ。

Codeステップで整形する場面

Code by Zapierは、FormatterやLookup Tableでは難しい整形をしたい時に使います。たとえば、配列をグループ化する、同じ顧客ごとに明細をまとめる、JSONを組み替える、不要な値を除外する、といった処理です。

Line Itemsを人ごとにまとめたい場合、Codeステップで「同じ名前またはIDのデータを集める」「明細だけを配列にする」「合計時間や合計金額を計算する」といった処理ができます。Zapierの画面操作だけで複雑になりすぎる時は、Codeに寄せた方が読みやすくなることもあります。

‍ Codeを検討したい場面

• 同じ顧客IDごとに明細をまとめたい
• 複数のLine Itemsを並び替えたい
• APIに送るJSON形式を作りたい
• 空欄や異常値をまとめてチェックしたい
• Formatterのステップ数が増えすぎている

ただし、Codeを使うと保守の難易度は少し上がります。Zapierに慣れていない人が後から修正する場合、画面上の設定よりも理解に時間がかかるかもしれません。チームで運用するなら、入力値と出力値の名前を分かりやすくし、処理内容を短く整理しておくのがおすすめです。

また、外部APIから取得したデータを加工する場合は、元データ側で出力を調整できないかも確認したいです。Zapier内で無理に頑張るより、API取得時点で必要な形に近づける方が安定することがあります。ここは、作業工数と今後の運用しやすさで判断するとよいかなと思います。

Mailchimpのmerge fields確認

Mailchimpのmerge fieldsは、メール配信で使う名前や独自項目を差し込むためのフィールドです。ZapierからMailchimpへ購読者情報を送る時、first nameやlast nameだけでなく、カスタム項目も使いたい場面があります。

カスタムmerge fieldsがZapier側に出てこない場合は、まずMailchimpで正しいAudienceを選んでいるか確認したいです。MailchimpはAudienceごとにフィールドが異なるため、違うAudienceを選んでいると、目的のカスタム項目が見えないことがあります。

Mailchimpで確認するポイント

Zapierのステップには、フィールド情報を再取得するRefresh Fieldsのような操作が用意されている場合があります。Mailchimp側で新しい項目を追加した直後は、Zapier側にまだ反映されていないことがあるため、再読み込みを試すと表示されることがあります。

ここで気をつけたいのは、Mailchimpのmerge fieldsと、この記事で扱っているデータのマージは少し意味が違うことです。Mailchimpのmerge fieldsは「メール本文や顧客情報へ差し込む項目」で、Zapier上のデータ結合とは別物です。とはいえ、Zapierから正しく値を渡すには、Audience、項目名、データ形式をそろえることが大事です。仕様や利用できる項目は変わる可能性があるため、正確な情報は公式サイトをご確認ください。

Zapierでデータをマージするまとめ

Zapierでデータをマージする時は、最初に「データをまとめたい」のか「処理を合流したい」のかを分けると考えやすいです。Line Items、Looping、Paths、Webhooks、Storage、Digest、Lookup Table、Codeは、それぞれ得意な役割が違います。

とくに、Pathsの後に共通ステップを置きたい場合と、Loopingの結果をまとめて1回だけ送信したい場合は混同しやすいです。前者はWebhooksやSub-Zapで共通処理化、後者はStorageやDigestなどで集約、というように分けて見るとスムーズですよ。

Zapierでデータをマージする要点

1. まず、結合したい対象がデータなのか処理フローなのかを決める
2. Line Itemsは、同じ顧客や同じ請求単位でまとめるキーを用意する
3. Formatterは分割や軽い整形に使い、複雑なグループ化は無理に任せない
4. Looping後にまとめたい時は、StorageやDigestで集約を検討する
5. Paths後の共通処理は、WebhooksやSub-Zapで別Zapへ渡す方法が現実的
6. Lookup Tableは、表記ゆれやコード変換を整える補助として使う
7. Codeステップは、配列やJSONなど複雑な整形が必要な時に使う
8. Mailchimpのmerge fieldsは、Audience選択とRefresh Fieldsを確認する

仕事で使うZapほど、あとから見直せる設計が大事です。最初から完璧な自動化を狙うより、小さく作ってテストし、データの形が崩れないかを確認しながら広げる方が安全です。あなたのZapが請求、顧客管理、外部API送信に関わるなら、テストデータで十分に確認してから本番運用へ進めてください。

記事作成にあたり参考にさせて頂いたサイト

• Merging data from line items | Zapier Community
• How to send personalized messages using Gmail mail merge
• Is there a way to merge paths back together? | Zapier Community
• Reddit – Please wait for verification
• Cannot update subscriber data with custom merge fields for Mailchimp. | Zapier Community
• How to merge Google accounts (Gmail, Calendar, and Contacts)
• How to merge the results of (5) loops and send them out via HTTP? | Zapier Community
• Reddit – Please wait for verification
• Create personalized documents from caught webhook data with WebMerge
• Add branching logic to Zap workflows with Paths

当サイトについて

当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。