Make(旧Integromat)とは|『複雑分岐対応ワークフロー自動化』の本質と運用5要件

『Make(旧Integromat)』って、ぶっちゃけ何のツールか、説明できますか?

株式会社Cameen 西村温裕ことおんゆーです。

で、ノーコード自動化という言葉が一般化して、ZapierやMake、n8n、Power Automate、こういうツールの名前を聞く機会が一気に増えたんですよね。SNSを開けば「業務を自動化して時短」「ノーコードで月数十時間の削減」、こういう発信が流れてきます。

でも、いざ「Makeって何ができるツールですか?」「Zapierと何が違うんですか?」と聞かれると、答えに詰まる方が多いんですよね。なんとなく「自動化のツールでしょ?」というイメージで止まっている。これ、自分だけだと思ってませんか?

うちの事業ではMakeを2年以上運用していて、メルマガ配信・LINE連携・LARK文字起こし→議事録化・SNS投稿・通話録音アーカイブ、こういう業務をMakeで日々自動で動かしています。クライアント案件でも「Zapierで限界が来た業務」をMakeに移植する相談を何度も受けてきました。その中で見えてきたのは、Makeは単なる「Zapierの代替」ではなく、「複雑な業務プロセスを視覚的に組み立てて運用するためのエンタープライズ向け基盤」だということ。シンプルなトリガー1個→アクション1個の世界ではなく、ルーター・フィルター・データストア・エラー処理が組み合わさる世界です。

もう1つ繰り返し観察したのは、「Makeを導入したけど運用設計を間違えて、結局Zapierに戻る」というケースなんです。Makeは表現力が高い分、設計を雑に始めると、半年後に誰も触れない巨大シナリオが残ります。Makeで成果を出すかどうかは、ツール選定ではなく運用設計の質で決まります。

今回はその「今さら聞けないMake(旧Integromat)」を、ツール紹介ではなく、運用設計の核心と、うちで2年回してわかった本音まで深掘りしていきます。読み終わる頃には、自分の業務をMakeで自動化すべきか、どこから着手すべきかが、紙に書き出せるレベルになっているはずです。

結論:Makeの核心は「Zapierの代替」ではなく「複雑分岐対応の自動化基盤」

Makeの本当の正体は、「複雑な分岐・ループ・データ加工が必要な業務を視覚的に組めるエンタープライズ向け自動化基盤」のことなんです。単なるトリガー&アクションの繋ぎこみではなく、業務プロセス全体を1枚のキャンバスに描いて運用する基盤、という性格を持ちます。

業界の体感として、Zapierが「A→Bの直線的なつなぎ込み」を得意とするのに対して、Makeは「A→分岐→B/C/D→集約→E」のような複雑構造を視覚的に組めるのが強みなんですよね。シナリオ1本で数十モジュールを繋いだ業務フローも珍しくないんです。

Makeの料金体系も特殊で、Zapierが「タスク数(=実行アクション数)」課金なのに対して、Makeは「オペレーション数(=モジュール実行回数)」課金なんです。これ、複雑なシナリオを組むほどコストが膨らむ構造になっていて、設計力がそのままコストに直結するんですよね。

うちでMake運用してわかったんですが、Makeの真の価値は「自動化できるアクション数」ではなく、「自動化した業務を継続的に運用・改善できる視覚化レイヤー」なんです。半年後に過去の自分のシナリオを開いたとき、何をしているかが図解1枚で理解できる、これがMakeの本質的な強みです。

なぜ「Make(旧Integromat)」という名前なのか

もう少し深く掘ります。なぜこのツールは「Make」と呼ばれているのか。命名の歴史的背景を整理します。

Makeはもともと、2012年にチェコのプラハで「Integromat」という名前で誕生したサービスなんです。「Integration(統合) + Automat(自動化)」の合成語で、当初から「複数SaaSを統合して自動化する」というコンセプトでスタートしました。Zapierが2011年創業なので、ほぼ同時期に立ち上がったサービスなんですよね。

転機が訪れたのは2022年。ドイツのプロセスマイニング企業Celonisがintegromatを買収して、ブランドを「Make」にリブランドしたんです。Celonisは業務プロセス可視化のグローバルリーダーで、Makeは「Celonisの自動化実行レイヤー」として位置づけが進化しました。単なる自動化ツールから、業務プロセス基盤の一部に格上げされた、という見方ができます。

「Make」という名前は、Integromatより短く、グローバル展開に適した命名なんですよね。「Make = 作る」のシンプルさが、「業務フローを自分の手で作る」というツールの思想と一致しています。いやちょっと待ってください。シンプルな名前の裏に、Celonisが描く「業務自動化の民主化」という大きな戦略が隠れているんです。

業界の体感として、Make/Integromatは欧州を中心にエンタープライズ顧客に強く、Zapierが米国の中小企業に強い、という棲み分けが見えるんです。日本でもMake導入が加速していて、特に「複雑な業務フローを抱える中堅企業」「複数SaaS連携が必要なSaaSベンダー」「マーケティング部門での運用」、こういう領域でMakeが選ばれています。

近年は、AI機能の統合も急速に進んでいるんですよね。OpenAI・Anthropic・Cohereなど主要LLMモジュールが標準で組み込まれていて、「業務自動化 + LLM処理」のシナリオが組みやすくなっています。これ、エンタープライズ自動化の次世代スタンダードを取りに来ている動きじゃないですか。

ツールの進化として、Makeは月額数千円のスタータープランから、エンタープライズ向けの年額数百万円プランまで、価格レンジが広いんです。中小ベンチャーから大企業まで対応できる柔軟性が、長期で運用基盤として選ばれる理由になっています。

Make運用の現場で何が起きているか

Make運用の現場で、具体的に何が起きているか。5段階で整理します。

ステージ1:シナリオ設計(全体フローの設計)

担当者がまず行うのが、自動化したい業務の全体フロー設計なんです。誰が・どこから・どんなデータが入り・どう加工して・どこへ出力するか、これを1枚の絵に描きます。いきなりMakeのキャンバス画面を開くと迷うので、紙やNotion・Miroで先に下書きするのが定石です。

うちの事業でも、新規シナリオを組むときは必ず「業務フロー図」を先に書いてから、Makeに落とし込むんですよね。これ、後から見返したときに保守できる状態を作る上で決定的に重要なんです。設計図なしで作ったシナリオは、半年後に開いても誰も触れません。

ステージ2:モジュール接続(トリガーとアクションの配置)

設計図ができたら、Makeのキャンバスにモジュールを配置します。トリガー(きっかけ)モジュールが1つ、その後にアクションモジュールを順番につなげる、これが基本構造です。Make公式の対応サービスは1,500を超えていて、主要SaaSはほぼカバーされているんですよね。

各モジュールは前のモジュールが返したデータを参照できるので、「LARKで通話が終わったら、文字起こしを取得し、ChatGPTで議事録化し、Google Docsに保存し、Slackに通知する」、こういう連続処理が直感的に組めるんです。

ステージ3:ルーターとフィルターの設定

シンプルな直列処理を超えて、分岐や条件処理が必要になったら、ルーター(分岐)とフィルター(条件)モジュールを使います。「処理対象がAなら経路1へ、Bなら経路2へ、それ以外なら経路3へ」、こういう分岐がMakeの強みなんです。Zapierではこの分岐表現が弱いんですよね。

うちの事業では、メルマガ配信フローで「ポイント3,000以上のセグメントは配信A、2,999以下は配信B」というルーター分岐を組んでいるんです。これ、フィルター条件1個追加するだけで挙動が変わるので、保守性が高いんですよね。

ステージ4:テスト実行(部分実行と全実行)

シナリオが組み上がったら、テスト実行です。Makeは「Run once(1回だけ実行)」機能があって、各モジュールの入力・出力データを目視確認できるんです。これ、本番運用前のデバッグで決定的に重要な機能なんですよね。

テスト時に確認するのは、(1)各モジュールが期待通りのデータを返しているか、(2)ルーター分岐が正しく動いているか、(3)エラー時の挙動、この3点です。うちではテスト工数を全体の3割程度確保するようにしているんです。これ、後の運用トラブルを激減させるための投資なんですよね。

ステージ5:本番運用と監視

テストが通ったら、シナリオを「ON」にして本番運用開始です。Makeは「実行履歴(History)」機能で、過去のシナリオ実行ログを保存してくれるんです。エラー発生時にメール通知する設定もできて、運用フェーズでの監視がやりやすい構造になっています。

本番運用で起きやすいのは、「外部API変更でモジュールが動かなくなる」「データ量増加でオペレーション数オーバー」「想定外のデータ形式でエラー発生」、この3つなんです。うちでは月1回、全シナリオの実行履歴を見直す運用ルーティンを組んでいるんですよね。これ、業務自動化の継続運用で決定的に重要な習慣です。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

工場のベルトコンベアに置き換えてみます。あなたが食品工場のラインを設計しているところを想像してください。原材料が入ってきて、洗浄され、カットされ、味付けされ、検品され、パック詰めされて出荷される、こういう一連の工程ですよね。

これ、まんまMakeなんです。Makeのモジュール1つ1つが、工場ラインの各工程に対応します。原材料投入=トリガー、洗浄機=モジュール1、カット機=モジュール2、味付け機=モジュール3、検品=エラー処理、パック詰め=最終アクション、こういう対応関係です。

工場ラインで分岐が必要な場面、ありますよね。例えば「サイズLは経路A、サイズMは経路B、サイズSは経路C」みたいな選別工程。これがMakeのルーター機能に対応します。検品で不良品を弾く工程、これがフィルター機能。途中で原材料を一時保管する倉庫、これがデータストア機能。すべて工場ラインの構成要素に対応するんです。

これ、〜じゃないですか。工場ラインを設計するとき、いきなり機械を並べ始める人はいないですよね。先に全体フロー図を書いて、各工程の入力・出力を整理してから機械配置を決めます。Makeも同じで、シナリオ設計図を書いてから、モジュールをキャンバスに置く順番が定石なんです。

工場ラインで決定的に重要なのが「検品工程」と「不良品対応」ですよね。検品なしで全部を出荷すると、不良品が客先に届いてクレームになる。Makeも同じで、エラー処理を設計しないシナリオは、業務にダメージを与え続けます。これ、自動化を始めたばかりの人が一番見落とすポイントなんです。

もう1つ、工場ラインで重要なのが「ライン稼働率の監視」ですよね。1日何個処理したか、エラーは何件出たか、ボトルネック工程はどこか、これを毎日見てラインを改善します。Makeでも同じで、月1回の実行履歴レビューが、業務自動化を継続改善する装置として機能するんです。

業界の体感として、Make導入企業で成功しているところは、ほぼ例外なく「業務フロー設計の文化」を持っているんです。逆に、いきなりMakeを買って組み始める企業は、半年後に運用が止まる確率が高い。これ、ツールの問題じゃなくて、業務プロセス可視化の習慣の問題なんですよね。

Make運用5要件と、それぞれの中身