Slack連携の限界突破へ！iPaaS活用ガイド（第2回：iPaaSとは？主要サービス ZapierとMakeを徹底比較）
はじめに
対象読者
本記事は、Slackと他サービスとの連携に関して課題を感じている方、Slackをハブにした業務フローを検討している方を主な対象としています。
本記事の前提知識として、SlackアプリやWebhookに関する基本的な知識、何かしらのワークフローツールの基礎知識があることを想定しています。
記事のゴール
本記事は複数回に分かれていますが、全体を通じて、読者は以下の点を達成することを目指したいと思います。
- Slackと他サービスとの連携方法について、改めておさらいする
- iPaaS(Integration Platform as a Service)の Zapier と Make のサービス概要を把握する（今回の範囲）
- Zapierによる実際のフロー構築のイメージをつかむ、Makeとの違いを把握する
iPaaS（Integration Platform as a Service）とは
iPaaSの概要
iPaaS(Integration Platform as a Service)とは、「サービスとしての統合プラットフォーム」であり、複数の異なるサービス間で、データやプロセスを連携するためのプラットフォームです。
近年、企業ではSaaS(Software as a Service)などのクラウドサービスや、既存のオンプレミスシステムを複数利用することが増えており、それぞれのシステムにデータが分散し、サイロ化で分断された状態が生じやすい傾向があります。iPaaSは、このサイロ化を解消し、サービス間の連携をスムーズに行うためのものです。
主な機能として、複数のサービス間にまたがるプロセスを、一連のワークフローとして自動実行することができます。
またその際には、データ連携も可能で、連携先のシステムに合わせて変換・加工する機能もあります。
iPaaSでは、数多くのコネクタが提供されており、これにより多くのサービス間の連携を可能にします。
ワークフローはGUI上で直感的な操作で構築することが可能です。またノーコード（もしくはローコード）が基本なので、非エンジニアの方でも扱いやすくなっています。
主なiPaaS
iPaaSには、大企業と中小企業をターゲットにしたものがありますが、今回は中小企業向けの主要なサービスについて、それぞれの特徴を以下に簡単にまとめてみました。
| サービス名 | リリース年 | 主な特徴・強み | コスト体系と傾向 | 連携可能なサービス数 | 学習コスト |
| IFTTT | 2010 | ・個人利用やIoT連携に強い ・「アプレット」と呼ばれるシンプルな「If This Then That」(もし〜ならば、これをせよ)のロジックが基本 | アプレット数ベース 比較的安価だが、機能は他のiPaaSより限定的 | 900以上 | 低 |
| Zapier | 2011 | ・連携アプリ数が圧倒的に豊富 ・シンプルで直感的なUIで、初心者でも簡単に「Zap(ワークフロー)」を作成できる ・単線的でシンプルな自動化が得意 | タスク数(フロー内で実行されたアクション回数)ベース 小規模な利用であれば比較的安価 | 8,000以上 | 低 |
| Make (旧Integromat) | 2012 | ・視覚的なフロー設計に優れる ・複雑なロジックや多岐にわたるデータ操作(分岐、繰り返し、集約など)を柔軟に構築可能 | オペレーション数(ワークフロー内で実行されたモジュール数)ベース 複雑で大規模な処理を効率的に設計できる | 3,000以上 | 中〜高 |
| Power Automate | 2016年 | ・Microsoft製品との連携が非常に強力 ・特にExcel、Outlook、SharePointなどのMicrosoft 365環境における自動化に最適 ※RPA機能(Desktop Flow)も利用できるが、今回は評価範囲外 | 基本機能のみの利用はMicrosoft 365ライセンスに含まれる 単体ライセンスはユーザー単位/フロー単位などベースが様々 | 1,000以上 | 中 |
| Yoom | 2022年 | ・純国産のiPaaS ・データベース機能を内蔵しており、SaaS連携だけでなく、集約したデータを基にした柔軟なワークフロー自動化に強み | 利用ボット数、データベース容量などに基づく | 160種類以上 | 低 |
検証対象にするiPaaSの選定
今回検証対象にするiPaaSとしては、まず連携可能なサービス数を第一に考え、IFTTTとYoomについては対象外にしたいと思います。
さらに、当社ではPowerAutomateが得意とするMicrosoft製品との連携は特に重視していないため、これも対象外にし、Zapier と Make(旧Integromat) を候補として検証をしていきたいと思います。
Zapier と Make を要素ごとに比較
連携可能なサービス数
Zapierの状況
2025年10月時点で、8800ほどあるようです。
https://zapier.com/apps
Makeの状況
こちらも2025年10月時点で、3000以上とのことでした。
https://www.make.com/en
結果: 連携可能なサービス数に関しては、Zapierが2倍以上とかなりリードしているようです。
日本語対応
Zapierの画面
コンソール画面のメニュー表示や説明は日本語未対応でした。Zap(※)などは日本語で設定することは可能でした。
※ ワークフローのこと。以降は「ワークフロー」で呼称を統一します。
Makeの画面
こちらもコンソール画面のメニュー表示や説明は日本語未対応でしたが、シナリオ(※)などは日本語で設定することは可能でした。
※ ワークフローのこと。以降は「ワークフロー」で呼称を統一します。
結果: 両ツールともに基本的には日本語未対応なので、英語が苦手な方はブラウザ内蔵の翻訳機能などを活用すれば良いかと思います。
ワークフローのデザイン画面のUI
Zapierの画面
ワークフローのデザイン画面はこんな感じです。シンプルで見やすいと思います。
各アクション(ワークフロー内の各ブロック)の設定画面はこんな感じになっています。特に不便さは感じませんでした。
Makeの画面
ワークフローのデザイン画面はこんな感じです。横並びですがこちらもシンプルで見やすいと思います。
各モジュール(ワークフロー内の各ブロック)の設定画面はこんな感じになっています。こちらも特に不便さは感じませんでした。
結果: 両ツールともにUI的には見やすく、不便さは感じませんでした。
AI(LLM)対応
両サービスとも、OpenAI(ChatGPT)やGeminiと連携したアクション/モジュールが利用可能でしたので、この辺もワークフロー内に織り込めば、非常に柔軟で強力なワークフローが構築可能になりそうです。
また、共にまだベータ機能となりますが、AIエージェントの作成も可能なようなので、より高度な自動化を実現することもできそうです。
結果: 両ツールともにAI(LLM)対応しているので、この点でも差はあまり無いように思います。
料金
料金に関しては、両サービスでずいぶんと違いがありました。
まずZapierの料金プランは、Free、Professional、Team、Enterpriseの4プランがあり、複数ユーザーで利用可能なものはTeamプラン以上になります。ワークフローや他アプリとの接続を複数ユーザーで共有したい場面もあると思うので、今回はTeamプランをターゲットにしたいと思います。
次にMakeの料金プランは、Free、Core、Pro、Teams、Enterpriseの5プランがあり、全てのプランで複数ユーザーで利用可能です。ざっと見た感じ、ある程度の機能が使えてオススメになっているのがProプランなので、Makeに関してはProプランをターゲットにして比較して行きたいと思います。
| プラン | 利用できるタスク/クレジット数 | 月額 (年払い) |
| Zapier Teamプラン | 2,000タスク (1アクションの実行で1タスク消費) | $69 |
| Make Proプラン | 10,000クレジット (1モジュールの実行で1クレジット消費) | $16 |
こう見ると、Makeの方が割安さが際立ってきますね！ 単純にタスク/クレジット数あたりのコストを比較すると、
・Zapier: $69 ÷ 2,000タスク = $0.0345
・Make: $16 ÷ 10,000クレジット = $0.0016
となり、20倍ちょっとの開きがある事になります。
ところが、両ツールにおけるタスク/クレジットのカウント方法には違いがある点に注意が必要です。
両ツールともワークフローの開始ブロックは「トリガー」と呼ばれます。例えばSlackの特定チャンネルで特定のリアクション(Reacji)があったことをトリガーにしたとします。
まずZapierでは、公式サイトにも記載されている通り、トリガー自体はタスクとしてカウントされず、それ以降のアクションが実行された場合のみ、その分のタスクがカウントされます。
一方Makeではこの場合、まずイベントを受け取るモジュールが反応してイベント内容を受け取るのですが、この際に1クレジットがカウントされます。そして直後にチャンネル名やリアクション内容(Reacji)をフィルターして、該当条件に合った場合は以降のモジュールが実行され、さらにその分のクレジットがカウントされます。
この違いは一見ちょっとした差にしか思えませんが、今回の当社のように、ハブとなっているSlackを起点・経由点にしたいという取り組みだと少し事情が変わってきます。
例えば現在当社のSlackワークスペースには100人を超えるメンバーが参加しています。またリアクション(Reacji)によるコミュニケーションもそこそこあり、(きちんと数えてはいませんが)1人当たり1日平均20個は押していると思います。
こういったケースの場合、上記のようにMakeでSlackのリアクションをトリガーとしたシナリオを作ってしまうと、月間で見た場合に 100人×20個×20営業日=40,000という大量のクレジットがカウントされてしまうことになります。MakeのProプランでも、40,000クレジットになると料金が $53 となり、ZapierのTeamプランと大して変わらない額になってきます。
そういったシナリオがさらに2つ、3つと増えていくと、リニアにクレジットのカウントが増加します。
※念のため実際に試してみましたが、1回のリアクションでもシナリオ数分のクレジットがカウントされるのが確認できました。
そのため、MakeでSlackリアクションをトリガーしたい場合はトリガー専用のシナリオを1つだけ作って、ルーターとフィルターで分岐させた後に、後続のモジュールがあるサブシナリオを呼び出すようにすることで、クレジット数を減らすような工夫はできます。
しかし管理責任の分離なども考えると、使い勝手はちょっと微妙な気がしますので、連携させるツールとの相性を考えて適切なサービスを選ぶ必要がありそうです。
結果: ぱっと見はZapierに比べMakeの方が割安に見えるが、ユースケースによっては逆転も起きかねないので注意が必要です。
学習コスト
Zapierはとにかく設定が簡単です。非エンジニアでも使いやすいという点に重点を置いて作られているのを感じます。
例えばSlackとの連携を作成する際、Zapierは公式Slackアプリが提供されているので、それをSlackワークスペースに追加するだけで連携が完了します。対してMakeは公式ドキュメントを見ながら自分でSlackアプリを作成してからあちこち設定して初めて連携ができるようになります。権限周りも細かく設定しなくてはいけなくて、少し間違ってるだけで思った通り動かないので、慣れてない人にはハードルが高いと感じました。
反面、Zapierは手軽に使ってほしいというコンセプトもあるのか、あまり凝ったことをやろうとするとできない時もあるようです。例えば分岐処理からの合流なども1つのワークフロー内で普通に作ろうとしてもできないので、少し工夫する必要があります。対してMakeはノーコードではありますが、プログラムに近い複雑なきめ細やかな処理ができると思います。
とは言え、例えば、以下のような処理があったとします。(承認や確認プロセスが挟まるようなタイプの業務ですね)
何かのトリガー(申請がされた、サービスAでユーザーが追加された、など)
→ Slackのチャンネルにその旨を自動投稿
→ リアクション(reacji)などでユーザーの応答を待つ
→ その後の処理(申請に基づいた処理、サービスBにもユーザー追加、など)
これはどちらのサービスでもできるのですが、Makeは「リアクション(reacji)などでユーザーの応答を待つ」のところもトリガーなので2つのワークフローに2つに分ける必要があり、さらにそのシナリオ間のデータ引継ぎなども設定する必要があります。
ところが、Zapierはこれがワークフロー内でもユーザーの応答を待つタスクが使えるので、これらの処理が1つのワークフローで済んでしまうという利点があります。
このように、総じてZapierの方が学習コストが低くて済むように感じました。
結論: 気軽に使えるZapierの方が学習コストが低く、非エンジニアの方でも扱いやすそう。
他サービスとの連携
ぱっと思いついた他サービスとの連携について、簡単にまとめてみました。
| サービス | Zapier | Make | コメント |
|---|---|---|---|
| Slack | ◎ | 〇 | 共に十分な機能があるが、Zapierの方が高機能 |
| Google Workspace Admin | 〇 | 〇 | ユーザー、グループ操作に関する機能がメイン |
| Googleフォーム | 〇 | 〇 | フォーム送信をトリガーにすることが可能 ※MakeはGoogleスプレッドシート経由 |
| GitHub | 〇 | 〇 | 共に多種の機能、Makeの方が僅かに多い 共にユーザー操作に関する機能はほぼ無い |
| GitLab | △ | 〇 | Makeの方が標準提供される機能が多い 共にユーザー操作に関する機能はほぼ無い |
| HubSpot | 〇 | 〇 | 共に多種の機能 |
| Zendesk | △ | 〇 | チケット、ユーザー操作に関する機能がメイン Makeの方が標準提供される機能が多い |
| Freee | △ | × | Zapierに多少の機能 |
| Team Spirit | × | × | 自分に権限が無く詳細不明だったが、恐らく未対応 |
上記に挙げたサービスだけ見ると両サービスともあまり大差が無いようでした。
強いて言うと、Zapierの方は凝った事をやろうとすると標準提供の機能では出来ないこともあり、広く浅くという感じがしました。
恐らくですが、Zapierはよく使われる機能をより簡単に利用できるように、Makeは少し取っつきづらいが凝った機能ができる、といったようなコンセプトの違いがあるのかも知れません。
両サービスとも、Webhook受信やHTTPリクエスト機能はあるので、少しだけ敷居が高くなりますが、未対応の機能はその辺を利用した連携が必要になりそうです。
まとめ
学んだことの整理
今回の記事を通じて、iPaaS、主にZapierとMakeについて以下のようなことを学びました。
- iPaaSはSaaSのサイロ化を解消し、データ連携・業務自動化を実現するプラットフォームである。
- 多数のコネクタとGUIによる直感的なワークフロー構築(ノーコード/ローコード)が可能で、非エンジニアでも扱いやすい。
- ZapierとMakeは、それぞれ強みと弱みがあり、ユースケースによって適切なサービスを選択することが重要である。
- Zapierは連携可能なサービス数が圧倒的で、シンプルなUIで学習コストが低い。
- Makeは複雑なロジックやきめ細やかな処理を柔軟に構築可能だが、学習コストは少し高くなる。
- 料金的にはMakeが一見割安だが、タスク/クレジットのカウント方式の違い(特にSlackリアクションなどの高頻度トリガー)との連携時は、コスト優位性が薄れる可能性がある。
次回は、Slackをハブとするような業務をサンプルとして、実際にZapierでワークフローを構築していきたいと思います。
