ノーコードツール（Zapier/Make）とAI連携による業務自動化

ZapierやMakeは、フォーム、メール、チャット、表計算などのSaaSをつなぎ、決まった手順の処理を自動で動かすサービスです。多くの連携を画面の操作で組めますが、接続先の権限、項目の対応づけ、例外や失敗したときの扱いは、利用する側で設計します。

どちらを選ぶかは、対象の業務、必要な接続先と操作、月の処理件数から見積もる消費量、止まったときに対応できる体制で決めます。この記事では、ZapierとMakeを同じ業務の例で比べ、条件によって候補になるn8nとYoomにも触れます。

AIを組み込む前に、処理を3つに分けます。決まった項目を決まった宛先へ渡す転記や通知は、AIを使わずにルールだけで組めます。AIは、分類や下書きのように、結果を人が確かめられる工程に使います。

金銭や契約に関わる業務でも、受付、書類の整理、期限の通知など、自動化できる工程はあります。業務全体を自動化できるかどうかで分けず、影響の大きい確定の判断を人に残して、その前後の定型の処理を自動化します。人が承認する工程を置いても誤りがなくなるわけではないため、承認する人が何を確かめるかまで決めておきます。

ZapierやMakeのフローは、あらかじめ決めた順番と条件で動きます。依頼ごとに手順が変わる業務では、条件の分岐を足し続けるより、実行するときに手順を組み立てるAIエージェントの方式も候補です。使い始め方と活用例はAIエージェントの始め方と活用例で扱っています。Malakeが提供するAIAG（AI業務Orchestrator）も、この方式の製品です。方式を変えても、影響の大きい判断を人に残す考え方は変わりません。

ZapierもMakeも、複数の手順をつなぎ、条件による分岐やデータの変換を組めます。違いは、フローの組み立て方、消費量の数え方、失敗の調べ方、接続の管理などに表れます。比べるときは、製品全体の優劣より、自社の業務で必要な接続先と操作が使えるか、担当者が運用を続けられるかを確かめます。

この記事では、次の業務を共通の例にします。

共通の例：フォームで問い合わせを受け付ける → 外部のAIで種類を分類し、返信の下書きを作る → Slackで担当者に通知する → 受付の結果を台帳に記録する。顧客への返信は、担当者が内容を確認してから別に送ります。

必要な接続先が一覧にあっても、必要な操作や権限が使えるとは限りません。同じアプリでも、使えるトリガーやアクション、取得できる項目は製品ごとに異なります。採用の前に、共通の例の各工程が実際の接続先で動くかを、試用の環境とテストデータで確かめます。

プランによって組めるフローも変わります。たとえばZapierの無料プランは2ステップのZapに限られるため、起動と3つの工程がある共通の例には、複数のステップに対応したプランが要ります（Zapier：Pricing）。どちらが安いか、簡単かは、必要なアプリと操作、プラン、担当者の経験、エラーの調べ方によって変わり、一律には決まりません。Makeで分岐や繰り返しを組む場合も、bundleの扱いやエラー処理の設定を理解して運用する担当が要ります。

ZapierとMakeのほかに、条件によってはn8nやYoomも候補になります。

n8nは、画面でフローを組み、必要に応じてHTTPのリクエストやコードで処理を加えられるサービスです。用意された連携だけでは足りずにAPIを直接呼ぶ処理や独自のデータ変換が多い場合や、システムを置く場所と管理の方法に条件がある場合に候補になります。APIを直接呼んだりコードで変換したりする部分では、APIの仕様、JSONの形式、JavaScriptなどの知識が要ります。

使い方は、n8nが運用する環境を使うCloudと、自社や委託先が用意した環境で動かすセルフホストに分かれます。Cloudではサーバーの運用をn8nに任せられ、セルフホストでは環境の保守が利用者の責任になります（n8n：Choose how to use n8n）。どちらでも、フロー、接続の権限、記録、担当の交代は利用する側で管理します。セルフホストでは、これに加えて更新、監視、バックアップ、障害対応の担当と、その作業や環境の費用を見積もります。社内のサーバーに置いても、フローが外部のAIやSaaSへ送るデータは別に確認が要ります。

セルフホストには無料で使える版（Community edition）がありますが、SSOなどの機能には有料の版やプランが要ります。社内の業務での利用と、n8nを他社へサービスとして提供する使い方などでは、必要なライセンスが異なります（n8n：Which license do I need for my use case?）。使いたい機能と利用の形を、公式の案内で確かめてから選びます。環境の構築や運用の手順は、この記事では扱いません。

セルフホストでの更新・バックアップや、Cloudと分担する範囲を整理する場合に使える、配置・版と運用担当を確認する項目を、Dify・n8nのセルフホスト運用にまとめています。

Yoomは、SaaSの連携、AIの処理、人への承認や確認の依頼を組み合わせたフロー（フローボット）を、日本語の画面と案内で組めるサービスです（Yoom：フローボット）。kintoneなどとの連携や、途中に人の確認を挟むフローを、日本語の案内を見ながら検討したい場合に候補になります。

連携アプリの一覧に掲載されていても（Yoom：連携アプリ一覧）、必要な起動の条件、操作、権限が、使うプランで使えるとは限りません。人の承認を組み込む場合も、承認する人、対象の内容、期限、承認されないときの扱いを決める点は、ほかの製品と同じです。記録の残し方と、担当が交代したときの手順も確かめます。Yoomには定型のフローボットとは別にAIワーカーの機能もありますが、この記事では決まった手順の連携を扱います。

kintoneは業務のデータを置くアプリ、YoomやZapierなどはアプリの間をつなぐ役割で、組み合わせて使うこともあります。台帳の移行先の選び方は脱Excelの進め方で扱っています。

フローを組む前に、共通の例の各工程について、次の4点を決めます。

1. 入力：何をきっかけに動くか（フォームの送信など）、受け付けた1件を識別するID、項目と形式。必須の項目が欠けているときの扱い。
2. 処理：AIに任せる処理（分類、要約、下書き）と、ルールで決める処理（宛先の振り分け、期限の計算など）。AIを使わずに済む工程は、ルールで組みます。
3. 承認：人が確認する内容、承認する人、期限、承認されるまで送信や登録をしない条件。
4. 記録：完了の条件と、結果を後から確かめるための記録。

Slackにボタンを置くだけでは、承認の仕組みはできません。誰が、どの内容のどの版を承認したか、期限を過ぎたらどうするか、承認の前に送信されない作りになっているかを確かめます。チャットでの承認の作り方は申請・承認をSlack / Teamsにつなぐ設計、AIの出力の評価の仕方は生成AIを業務へ組み込む方法で扱っています。

記録は、製品の実行の履歴と、自社で残す記録の役割を分けて考えます。実行の履歴は失敗の調査や再実行に使うもので、見られる期間や範囲は製品とプランによって異なります。業務として後から確認したい事項（受付のID、処理の状態、確認した人など）は、必要な範囲を決めて自社の台帳などに残します。入力や出力の全文まで複製するかは、保存先、期間、閲覧できる人とあわせて決めます。詳しくは、監視とエラー対応の節で扱います。

次の3つは、構成を考えるための一般的な例です。

① 問い合わせの受付と担当への通知（共通の例）

• 入力：問い合わせフォームの送信を受け付け、受付IDを付ける
• AI：問い合わせの種類を分類し、要約と返信の下書きを作る
• 通知：種類に応じた担当者へ、Slackで要約と下書きを知らせる
• 記録：受付ID、分類、通知した日時、担当者を台帳に記録する

返信は、担当者が下書きを確認・修正してから別に送ります。承認した内容を自動で送信するところまで広げる場合は、承認の記録、送信の処理、失敗したときの再実行の条件と、増える消費量を別に設計します。

② 公開ニュースの確認と要約

• 入力：特定のキーワードのRSSや、公開されているニュースの更新
• AI：見出しや取得できた本文から、自社との関係の有無を分類し、要約する
• 出力：関係がありそうなものだけを、元の記事へのリンクとあわせてSlackのチャンネルへ投稿する

RSSなどで受け取れるのは、見出しや抜粋だけのこともあります。本文を取得できるか、取得や要約が利用規約で認められているか、会員限定の記事のように取得できない情報をどう扱うかを確かめます。判断に使う前に、担当者が元の記事を確認します。

③ 会議の録音から議事録の下書きを作る

• 入力：決めたフォルダーに会議の録音ファイルが保存される
• AI：音声を文字に起こし、議事録の形式に要約する
• 出力：議事録の下書きを作り、確認する担当者へ通知する

録音することや、外部のサービスで文字に起こすことを参加者にどう伝えるかを、社内の規程に沿って決めます。フォルダーと下書きを見られる人の範囲を決め、担当者が内容を確認してから参加者へ共有します。文字起こしと要約に使うAIは、精度、対応する言語、費用、データの扱いの条件で選びます。

ZapierとMakeは、消費量の数え方が異なります。Zapierでは、成功したアクションの手順ごとにtaskを数え、トリガーやFilter、Pathsなどの一部の組み込みの手順は数えません（Zapier：task usage）。Makeでは、モジュールがデータを処理・確認する1回の実行をoperationと呼び（Make：Operations）、課金はcreditという単位で数えます。多くのモジュールは1回の実行で1creditを消費します。ただし、消費量が固定でも1creditを超えるモジュールや、AIの機能など利用量に応じて消費が変わるモジュールもあるため、使うモジュールの消費量と条件を確かめます（Make：Credits）。受け付けた件数、フローの手順の数、課金される消費量は、同じになるとは限りません。

共通の例について、次の前提で消費量を数えてみます。

• 問い合わせは月100件。1件の受付ごとに、後続の3つの工程（外部のAI、Slackへの通知、台帳への記録）がそれぞれ1回ずつ動く
• 分岐、繰り返し、添付ファイルの処理、再実行はない
• 3つの工程は、それぞれ1回あたり1task、または1creditを消費すると仮定する（実際の消費は、使う機能・設定・プランで確かめる）

この小計は、後続の3工程だけを数えた計算例で、月の消費量の合計や料金ではありません。次の分は、別に確かめて加えます。

• 起動と確認：Zapierのトリガーはtaskを数えません。Makeでは、データを確認するトリガーの実行もoperationとして数えるため、定期的に確認する設定では、確認の回数が消費にどう表れるかを確かめます。
• 追加の処理：データの整形、条件による分岐、通知の追加など。Zapierには数えない組み込みの手順もあれば、数える手順もあります。
• 複数のデータ：Makeでは、1回の起動で複数のbundle（データのまとまり）を受け取ると、後続のモジュールがbundleの数だけ実行されます。
• 分岐と再実行：分岐した先の手順や、失敗した後のやり直しでも消費が増えます。Zapierで実行の全体をやり直すと、成功していた手順のtaskも数え直されます（Zapier：What is replay?）。
• AIの機能の数え方：AI by Zapierのように選ぶモデルによって消費が変わる機能や、Makeが提供するAIの機能は、工程ごとに1回あたり1taskまたは1creditとした上の仮定とは別の数え方になります。

Zapierの300taskとMakeの300creditは、単位も料金も異なり、同じ金額にはなりません。料金は、各社の料金ページで、必要な機能を含むプラン、月の枠、枠を超えたときの扱い（追加の料金か、処理の停止・保留か）を確かめて比べます（Zapier：Pricing、Make：Pricing）。

費用は、次の4つに分けて見積もります。

• 連携サービスの契約（必要なプラン、利用者の数、管理の機能）
• 外部のAIの利用料
• 接続元のSaaS（フォーム、Slack、台帳）の契約
• 構築、監視、保守、社内での確認にかかる作業

AIの費用は、使うモジュールと接続方式によって支払い先が変わります（Make：Credits）。MakeのOpenAIなどのアプリで自社のAIアカウントに接続する場合は、AIの提供者へ支払う利用料と、Makeで消費するcreditを分けて確認します（Make：OpenAI（ChatGPT, Whisper））。Make AI Toolkitで自社契約のAIに接続する機能は、有料プランが対象です（Make：Make AI Toolkit）。Make側がAIを提供する方式では、AIの利用分を含めてcreditをどう数えるかを確認します。必要なプランは、使う機能ごとに公式資料で確かめます。支払いの経路を確かめたうえで、同じAIの費用を二重に数えないようにします。月払いか年払いか、比べる期間、税、為替の条件もそろえます。見積もりに入っていない費用は、0円とせず未確認として分けます。

n8nとYoomは、さらに別の単位で数えます。n8nの有料プランは、手順の数にかかわらず、ワークフローの1回の実行（execution）を単位にしています（n8n：Pricing）。Yoomは主にアクションの数をタスクとして数え、AIを使う操作や繰り返しの処理では、1回の起動で多くのタスクを消費することがあります（Yoom：タスク実行数のカウント方法、Yoom：料金プラン）。n8nでも、外部のAIの利用料や、セルフホストの環境と運用の費用は別にかかります。単位の数だけを並べて安さを決めず、同じ業務での消費の条件と、運用にかかる作業を含めて比べます。

実際の消費量は、採用を決める前に、試用の環境とテストデータで共通の例を動かし、実行の履歴や利用状況の画面で確かめます。

ZapierやMakeでフローを動かすには、接続先のサービス（フォーム、Slack、台帳など）へアクセスする許可を、連携サービスに与えます。このとき、次の3つを分けて考えます。

• 認可の仕組み：OAuthなど、連携サービスにアクセスを許可する方式。接続先によって、OAuth、APIキーなどの方式があります。
• 接続に使うID：誰のアカウントで許可するか。担当者個人のアカウント、組織が管理する業務用のアカウント、Googleのサービスアカウントのようなアプリ用のIDなどがあります。
• 連携サービス上の所有者：連携サービスの中で、その接続やフローを持ち、管理する人。

OAuthとサービスアカウントは、どちらかを選ぶものではありません。OAuthは許可の仕組み、サービスアカウントはIDの種類で、Googleのサービスアカウントは、個人の利用者ではなくアプリケーションに属するアカウントとして、OAuth 2.0でアクセスします（Google：Using OAuth 2.0 for Server to Server Applications）。どのIDで接続できるかは、接続先と、連携サービスの接続の機能が対応する方式によって決まります。

担当者個人のアカウントで接続すると、異動や退職でそのアカウントが使えなくなったときに、フローが止まります。組織が管理する業務用のアカウントで接続するかは、接続の機能が対応しているか、そのIDがアクセスできるデータと権限が業務に必要な範囲に収まるか、社内の管理の方針に合うかで判断します。アプリ用のIDに広い権限を与えたり、Google Workspaceのドメイン全体の委任を設定したりすると、アクセスできる範囲が大きく広がります。標準の手順にはせず、必要性と範囲を個別に確かめます。

連携サービスの中で所有者を変えても、接続先のアカウントや与えた許可が切り替わるとは限りません。たとえばZapierでは、接続の共有や所有者の変更ができるのは一部のプランで、所有者を変えても接続しているアカウントはそのままです。別のアカウントへ切り替えるには、接続を置き換える操作が要ります（Zapier：Manage your app connections）。次の点を、担当の交代や退職の前に決めておきます。

• 接続を共有・譲渡できるプランか、誰が再接続（再認可）できるか
• 各接続が、どのアカウントを使っているか
• 担当者の退職や異動のときに、接続を止めて別のアカウントへ切り替える手順

APIキーなどの秘密情報は、接続の設定画面など、製品が用意した入力欄に保存します。秘密情報を管理する機能は製品によって異なります。キーを手順書、共有のシート、ログ、スクリーンショットに書かないようにします。画面でキーを隠すだけでは、誰が接続を使えるかの管理にはならないため、接続とフローを編集できる人も限定します。

個人情報や機密情報を外部のAIやSaaSへ送るかは、送信先、契約、データの区分、保存と削除の扱い、使える管理の機能、自社の規程に沿って、社内で確認して決めます。

連携先のAPIの一時的な不具合や、接続の認証の失効などで、フローは止まることがあります。止まることを前提に、気づく方法と戻し方を決めます。次の確認票は、共通の例を想定した記入例です。担当の欄は役割の例で、自社の体制に合わせて決めます。

再試行と再実行を分けます。Zapierには、失敗した手順だけを再実行する方法と、実行の全体をやり直す方法、自動で再試行する機能があり、使える条件はプランによって異なります。自動の再試行が働く間は、最後の試行が失敗するまでエラーのメールが送られません（Zapier：What is replay?）。Makeでは、エラーが続いたときにシナリオを停止する設定があります（Make：Scenario settings）。止まったことに気づく通知と、再開の手順を決めておきます。

二重処理は、台帳の照会だけでは防げない場合があります。台帳で受付IDを調べ、未処理なら書き込む作りでは、同じ受付が同時に2回処理されると、両方が「未処理」と判断することがあります。一意な業務ID、同時に実行させない設定、登録先の一意の制約や、同じ要求を重ねて受けても結果が変わらない仕組み（冪等性）、結果の照会、どこから再開するかを、構成に合わせて確かめます。接続先によって使える機能は異なり、1回だけ実行されることを完全には保証できない場合もあります。

送信や登録が成功して、応答だけが失われることがあります。この場合に無条件で全体を再実行すると、通知やメールが重複します。まず相手側の結果を確かめます。Makeのエラー処理にはロールバックなどの設定がありますが、元に戻せるのはトランザクションに対応したモジュールの処理で、それ以外のモジュールの変更はその場で反映されます（Make：Overview of error handling）。送信済みの通知やメールを取り消せる前提にはしません。

ループと利用量を監視します。たとえば、Slackへの投稿をきっかけにAIが返信する設定では、AIの返信がまた起動のきっかけになり、処理が繰り返されることがあります。ボットの投稿を除外する条件だけに頼らず、起動の条件、重複とループの検知、利用量の通知、止める方法、手作業に戻す手順、担当を決めます。予算や利用量の通知は知らせるための機能で、処理を自動で止めるとは限りません。

記録は、必要な項目を決めて残します。台帳に残す候補は、業務ID、実行ID、状態、日時、参照先（元のデータの場所）、必要に応じて確認した人や版です。入力と出力の全文を複製すると、個人情報や機密情報の置き場所が増えます。保存先、期間、閲覧できる人、削除の方法、再処理に必要な情報を決めます。Zapierの実行の履歴は、保証される期間と表示される件数に上限があり、長く残すには書き出しが要ります（Zapier：Zap history）。Makeで実行の内容を機密として扱う設定にすると、実行の記録に処理したデータが残らず、エラーを直す手段が限られます（Make：Scenario settings）。保存の範囲と期間は製品、プラン、設定によって異なるため、使う環境で確かめます。技術的なログを残すだけで、監査に使える記録になるとは限りません。

自動化したフローの運用を始める前の確認項目です。未確認の項目は、担当と期限を決めて確かめます。

確認は、まずテストデータや匿名化したデータと、試験用の送信先で、正常と異常の両方の動きを見ます。本番のデータでの確認や、対象を絞った試験運用が必要な場合は、対象のデータ、権限、送信先、影響の範囲を関係者と合意してから行います。

チェックリストや確認票で未確認のまま残った項目や、今の自動化が止まったときの対応に不安がある点は、業務フローの整理、連携、監視と引き継ぎの相談の材料になります。