Make代替ツール7選、無料・日本語対応・OSSで選ぶ移行先 (2026年版)

Make代替とは、Makeで組んでいた業務自動化を、別のクラウドサービスや自己ホスト型オープンソース、国産iPaaS・RPA、自前スクリプトなどに置き換えることです。乗り換え先は大きく7つのタイプに分かれ、選び方は「操作数課金・日本語UI・データ保管先」のどの不満を解きたいかで決まります。

月末に請求画面を開いて、操作数（オペレーション）の消費量にぎょっとした経験、ありませんか。Makeは1シナリオの中でモジュールが動くたびにカウントが増える仕組みなので、ループや繰り返しを含むシナリオが1本あるだけで消費が跳ねます。ここが乗り換え検討の最大の入口。

ただ、乗り換えれば解決するとは限りません。課金の単位が「操作数」から「実行回数」や「タスク数」に変わるだけで、シナリオの作りが雑なままなら別の形で高くつきます。

だからこの記事は、ツールの羅列ではなく「あなたの不満はどのタイプで解けるか」から入ります。

Make代替とは、何を指すのか

Make代替とは、複数のアプリをつないで作業を自動化する仕組みを、Make以外の方法で組み直すことです。同種のクラウドサービスへの乗り換えだけでなく、自社サーバーで動かすオープンソース、国産のRPA、そしてスクリプトを書いて自前で回す選択肢まで含みます。

ここを広く取るのが大事です。「Makeの代わりになるSaaSはどれか」と問いを狭めると、結局また同じ課金モデルの製品に着地しがち。

代替の選択肢は、大きく5つの方向に分かれます。

つまり、乗り換え先を選ぶ前に「自分がどの方向を向いているか」を決めるほうが早いということです。

なぜMakeから乗り換えたくなるのか？

乗り換え理由の大半は、機能不足ではなくコスト構造・言語・データ管理の3つです。機能そのものへの不満は意外と少数派。

理由1: 操作数の消費が読めない

Makeの課金は操作数ベース。1回の実行で何回モジュールが動くかは、扱うデータの件数で変わります。100件のスプレッドシート行を回すシナリオなら、それだけで100回以上。月初に立てた見積もりが月末に崩れる、という現象が起きます。

理由2: 画面が英語のまま

シナリオを組む本人が英語に慣れていても、引き継ぎ相手が困ります。自動化は作った人だけが理解している状態が一番危ない。担当が変わった瞬間に誰も触れないブラックボックスになります。

理由3: データを社外に出したくない

顧客名簿や請求データを海外のクラウド経由で流すことに、社内の情報システム部門が難色を示すケース。金融・医療・自治体系の案件では、この一点で検討が止まります。

理由が3つあるということは、正解も3つに分かれるということ。ひとつのツールで全部を満たす製品を探すのは、時間の無駄になりがちです。

代替7タイプの早見表

タイプ別に、どんな不満を解けるかをまとめました。製品名ではなく「型」で見ると判断が速くなります。

つまり、7つのうち自分に関係するのはたいてい2つか3つ。全部を比較する必要はありません。

タイプ1: 同型クラウド自動化への横移動

画面の考え方がMakeに近く、シナリオの組み直しが最小で済むタイプです。移行の心理的ハードルが一番低い。

分岐、ループ、エラーハンドリングといった構造をそのまま持っていける製品があるので、既存シナリオが10〜30本あるような環境ではここが現実解になります。

ただし注意点がひとつ。課金モデルが「操作数」から「タスク数」に変わっても、結局は実行量に比例します。安くなるかどうかはシナリオの作り次第。移行前に、いまMakeで一番操作数を食っているシナリオを1本特定してください。それが移行後にどうカウントされるかを試算すれば、判断は数分で終わります。

• 移行が速い（画面の思想が近い）
• 課金単位が変わるだけの場合もある
• 事前に「一番重いシナリオ1本」で試算する
• 無料枠は検証用と割り切る

横移動で解けるのはスピードの問題。コストの問題は、次のタイプのほうが効きます。

タイプ2: 自己ホストOSS型は本当に安いのか？

オープンソースの自動化ツールを自分のサーバーに置くと、実行回数の課金がゼロになります。かかるのはサーバー代だけ。月に数万回動かすような環境では、ここが圧倒的に効きます。

代表格はn8n。ノードをつないでワークフローを組む形式で、Makeの経験があれば感覚を持ち込めます。自己ホストなら実行回数の上限がなく、データも自分の管理下に置けます。

ただ「安い」の中身は正確に見たほうがいい。

つまり、お金の支払い先が「ベンダー」から「自分の時間」に移っただけ、というケースもあります。社内にサーバーを触れる人がいるかどうか。ここが分かれ目。

判断の目安は明確です。月の実行回数が数千回を超えていて、かつDockerでコンテナを立てられる人が社内に1人でもいるなら、自己ホストで元が取れます。どちらか欠けるならSaaS型のままが無難。

セルフホストの実務では、バックアップの設計を先に決めてください。ワークフローの定義がサーバー上のデータベースに入るので、そこが飛ぶと全部やり直しになります。

タイプ3: 大手SaaS統合型に寄せる判断

接続先アプリの数を最重視するなら、統合の数で勝負している大手に寄せる選択があります。Zapierがこの位置。

強みは、マイナーなSaaSでも公式コネクタが用意されている確率の高さです。Makeで「このアプリだけHTTPリクエストで自作している」という部分が、標準コネクタで置き換わることがあります。自作部分が減ると、壊れたときの調査時間が減る。地味に効きます。

弱みは、複雑な分岐やループを組むときの窮屈さ。Makeのビジュアルな自由度に慣れていると、物足りなさを感じる場面があります。

この選択が向くケース

• 接続したいアプリがニッチで、コネクタの有無が死活問題
• シナリオの構造は単純（トリガー1つ、アクション2〜3個）
• 社内に運用担当が1人しかいない

逆に、1シナリオの中で10個以上のモジュールをつないでいるなら、窮屈さのほうが上回ります。

タイプ4: 国産iPaaSという選択肢

日本語UI、日本語ドキュメント、国内の営業日にレスポンスが返るサポート。この3つが揃うのが国産のiPaaS（複数のクラウドサービスをつなぐ基盤）です。

海外SaaSとの一番の差は、トラブル時の解決速度。英語のヘルプセンターを読み解いてチケットを立て、時差をまたいで返信を待つ。この往復が1回減るだけで、業務が止まる時間が短くなります。

料金は海外SaaSより高めに設定されている傾向があります。ただ、比べるべきは月額そのものではなく「英語のドキュメントを読む時間の時給換算」。担当者の時給が3,000円なら、月に3時間の調査時間が消えるだけで9,000円分の価値。ここを計算に入れないと判断を誤ります。

国産iPaaSが効くのはこういう現場

• 会計・給与・販売管理など国産SaaSとの連携が中心
• 情報システム部門が海外ベンダーとの契約を嫌がる
• 自動化の担当が非エンジニア

国産の弱点は、海外の新しいAIサービスへの対応が遅れがちなこと。生成AIを絡めた自動化を組みたいなら、そこは事前に確認してください。AI動画やAIアバターを業務フローに組み込む構想があるなら、Synthesiaの解説記事で連携のしやすさを掴んでおくと、要件の詰めが早くなります。

タイプ5: 国産RPAで「画面を操作させる」

RPA（人がパソコンを操作する手順をソフトに再現させる仕組み）は、APIがない社内システムに強い型です。

Makeのような連携ツールは、相手側にAPI（他のソフトから機能を呼び出す窓口）がないと手が出ません。基幹システムが20年前のもので、CSVを画面から手作業で落とすしかない。こういう現場ではRPAが唯一の解になります。

つまり、両者は競合ではなく守備範囲が違うということ。Makeで手が届かなかった部分だけRPAに任せる、という併用が現実的です。

RPAの落とし穴は保守です。画面のボタンが1つ移動しただけでシナリオが止まります。作った直後は快適でも、半年後に誰も直せない状態になっている例が本当に多い。導入するなら、シナリオ数を最初から絞ってください。

タイプ6: すでに契約済みの基盤に自動化が付いていないか

一番見落とされるのがこれ。オフィススイートや業務基盤の契約に、自動化機能が最初から含まれているケースがあります。追加費用ゼロで使える機能を、わざわざ別サービスで買い直している状態。

確認すべきポイントは3つです。

• いま契約しているグループウェアに、ワークフロー自動化のメニューがあるか
• CRMやMAツールの中に、条件分岐つきの自動処理があるか
• 使っているデータベース系サービスに、トリガー機能があるか

意外と、Makeでやっている処理の半分くらいが基盤側の機能で置き換わります。全部は無理でも、半分減れば操作数の消費も半分。

この見直しは移行より先にやるべきです。移行してから「これ元々使えたやつだ」と気づくのが一番もったいない。

タイプ7: 自前スクリプトに戻す判断

エンジニアがいるなら、スクリプトを書いて定期実行させるのが最も安く、最も自由です。サーバー1台と数十行のコードで済むことも多い。

向いているのは、要件が固まっていて変更頻度が低い処理。毎朝データを取得して整形して通知する、といった単純なパイプラインは、ノーコードで組むより保守が楽なことすらあります。

逆に向かないのは、非エンジニアが仕様を頻繁に変える業務。「条件をちょっと変えたい」がそのたびに開発依頼になる構造は、結局スピードを殺します。

判断はシンプル。変更を誰がやるかで決めてください。作る人と変える人が同じならスクリプト、違うならノーコード。

コードを書くハードルは、AIコーディング支援でだいぶ下がりました。要件を日本語で伝えれば動く形まで持っていける時代です。この延長線上で何が自動化できるかは、Google Labsの実験的ツールをまとめた記事を眺めると輪郭が掴めます。

無料で使い続けられるのはどれ？

無料の意味が2種類あるので、分けて考えてください。「無料枠つきのSaaS」と「無料のソフトを自分で動かす」は別物です。

つまり、本当の意味で無料を続けられるのは自己ホスト型か、既存契約に含まれる機能のどちらか。SaaSの無料プランは「試すため」のものと割り切るのが健全です。

ひとつ現実的な話を。無料枠で本番を回すと、上限に達した瞬間に自動化が止まります。止まったことに気づくのが翌日、というのが最悪のパターン。無料で運用するなら、失敗通知だけは別経路（メールやチャット）で必ず飛ばしてください。

日本語対応はどこまで必要か？

UIの日本語化と、ドキュメントの日本語化と、サポートの日本語対応。この3つは別々に評価してください。全部揃っている製品は多くありません。

現場で一番効くのは、実はドキュメントです。UIは英語でもアイコンと配置で慣れますが、エラーメッセージの意味を調べる段階で英語しかないと、そこで詰まります。

つまり、日本語UIの有無だけで製品を切るのは早すぎるということ。日本語の解説記事がどれだけ流通しているかも、実質的な「日本語対応度」です。

海外製ツールを日本語環境で使いこなす感覚は、動画編集ツールでも同じ構図があります。日本語UIと日本語情報の量が実務でどう効くかは、CapCutの使い方まとめを見ると具体的に想像しやすいはずです。

オープンソースを選ぶときの落とし穴

OSSは無料ですが、ライセンスと運用責任がついてきます。ここを確認せずに社内展開すると、後で面倒なことになります。

確認すべき4点

• ライセンスの種類（商用利用や再配布の条件が製品ごとに違う）
• アップデートの頻度と、破壊的変更の告知方法
• 自己ホスト版と有料クラウド版で機能差があるか
• 認証・権限管理が有料版限定になっていないか

特に4つ目。無料の自己ホスト版ではユーザー管理が単純で、有料版でSSO（一度のログインで複数サービスを使える仕組み）が解禁される構成はよくあります。3人で使うぶんには問題なくても、30人になると詰まります。

ここまでの整理 コストが理由なら自己ホストOSS、日本語運用が理由なら国産iPaaSかRPA、接続先の広さが理由なら大手SaaS。そして移行前に、いま契約済みの基盤に自動化機能がないかを必ず確認する。この4点だけ押さえれば、選択肢は2つ以下に絞れます。

落とし穴の話をもうひとつ。OSSは「自分で直せる」が強みですが、実際にコードを読んで直す人が社内にいるかは別の話です。読める人がいない前提なら、OSSでもSaaSでもリスクは変わりません。

移行の手間はどれくらいかかる？

シナリオ数と接続アプリ数で決まります。目安を出します。

つまり、シナリオが20本を超えたら「移行」ではなく「棚卸し」の仕事だということ。

ここが一番言いたいところです。50本のシナリオを持つ環境で、実際に価値を出しているのはたいてい10本前後。残りは作ったきり動いていないか、動いていても誰も結果を見ていません。

移行のタイミングは、この棚卸しをやる唯一のチャンス。全部移そうとせず、直近3ヶ月で1回も実行されていないシナリオは捨ててください。それだけで移行の工数が半分になります。

段階移行のコツは、並行稼働の期間を2週間取ること。旧環境を止めるのは、新環境で2週間問題なく回ってから。

業種によって答えが変わる場面

汎用の答えは出しましたが、業種特有の制約がある領域では判断軸が変わります。

医療・介護のように、扱うデータそのものに法的な制約がかかる分野では、クラウドの保管先が最初の関門になります。この領域の自動化がどこまで進んでいるかは、医療現場向けAIの解説を読むと、規制と実装のバランス感が掴めます。

制作・マーケティング系なら話は逆で、スピード優先。使っている制作ツール側の自動化機能で完結するケースが増えています。Webサイト構築ツールが自前でフォーム連携やCMS更新の仕組みを持っているなら、外部の自動化サービスを噛ませる必要はありません。この考え方はFramerの解説で扱っている「ツール内で完結させる」発想と同じです。

つまり、自動化ツールを足す前に「使っているツール側で完結しないか」を疑うのが先。ここを飛ばすと、連携のための連携が増えていきます。

選び方の判断フロー

3つの質問に答えるだけで、候補は2つ以下になります。

質問1: 月の実行回数は数千回を超えていますか

超えている、かつ社内にサーバーを触れる人がいる → 自己ホストOSS型。 超えているが触れる人がいない → 大手SaaSの上位プランで年契約割引を狙う。 超えていない → 質問2へ。

質問2: 運用担当は非エンジニアですか

はい → 国産iPaaS、または既存基盤の内蔵機能。 いいえ → 質問3へ。

質問3: 接続先にAPIがないシステムがありますか

ある → RPAとの併用。 ない → 同型クラウドへの横移動、または自前スクリプト。

この3問で決まらないケースは、たいてい要件が2つに割れています。その場合は無理に1本化せず、2つのツールを役割で分けるほうが早い。1つのツールで全部やろうとして複雑になったシナリオは、必ず後で誰も触れなくなります。

AI PICKS編集部の判定

Makeからの乗り換えで一番多い失敗は、ツールを変えただけで満足してしまうことです。操作数の課金が重いという理由で移った先が、実行回数課金だっただけ。数ヶ月後に同じ請求画面を見て同じため息をつく、という展開を何度も見てきました。

編集部の判定は明確です。実行回数が月数千回を超えていて、Dockerを触れる人が社内にいるなら、自己ホストのOSS型が一択。従量課金から完全に降りられる価値は破格です。逆にその条件を1つでも欠くなら、移行の費用対効果は薄い。Makeに残ってシナリオを整理するほうが、確実に安く上がります。

日本語運用が理由の場合は別です。引き継ぎができない自動化は資産ではなく負債なので、月額が上がっても国産iPaaSに寄せる判断は正しい。ここでケチると、担当交代のたびに作り直すことになります。

そして全ケースに共通する結論。移行前の棚卸しが、どのツールを選ぶかより効きます。動いていないシナリオを捨てるだけで、多くの環境は無料枠や下位プランに収まる。正直、ツール選びに悩む時間の半分を棚卸しに回したほうがリターンは大きいです。

よくある質問（FAQ）

Q. Makeのシナリオを別ツールに自動で変換できますか？

汎用的な変換ツールはありません。ノードの構造も、データの受け渡し方も製品ごとに違うためです。現実的には手作業での作り直しになります。ただし移行を機に不要なシナリオを削れるので、20本以下なら手作業のほうが結果的に速いことが多いです。

Q. 無料で本番運用できる代替はありますか？

自己ホスト型のオープンソースなら可能です。サーバー代だけで実行回数の制限なく動かせます。SaaSの無料プランは月あたりの実行回数に上限があるため、本番運用には向きません。上限に達すると自動化が黙って止まるのが一番の問題です。

Q. 日本語UIがない海外ツールでも運用できますか？

運用している現場はたくさんあります。ただし引き継ぎのリスクは残ります。対策は、シナリオ名と各ステップの説明欄を日本語で書き切ること。UIが英語でも、シナリオの中身が日本語なら次の担当者が読めます。ここを省略すると、担当交代の時点でブラックボックス化します。

Q. n8nとMakeの一番大きな違いは何ですか？

自己ホストできるかどうかです。n8nは自分のサーバーに置いて動かせるため、実行回数の従量課金から降りられます。データも自社の管理下に置けます。代わりに、サーバーの構築とアップデート、障害対応は自分の仕事になります。

Q. RPAと自動化ツールはどちらを選ぶべきですか？

対象システムにAPIがあるかで決まります。APIがあるWebサービス同士の連携なら自動化ツール、画面操作しかできない社内システムが相手ならRPA。競合するものではないので、守備範囲で分けて併用するのが現実的です。

Q. 移行中にMakeと新ツールを並行稼働させても大丈夫ですか？

問題ありません。むしろ推奨です。ただし両方が同じ処理を実行すると、データが二重登録される事故が起きます。並行稼働させるなら、片方は通知だけ飛ばして実際の書き込みはしない設定にしてください。期間は2週間が目安です。

Q. 社内にエンジニアがいない場合、どのタイプが安全ですか？

国産iPaaS、または既に契約している業務基盤の内蔵機能です。オープンソースの自己ホストは、構築できても障害時に復旧できない状態になりがち。自動化が止まった日に誰も直せない、という状況を避けるのが最優先です。

Q. 乗り換えでコストは実際どれくらい下がりますか？

シナリオの作り次第で、下がらないこともあります。課金単位が操作数から実行回数に変わるだけの製品も多いためです。判断するなら、いま最も操作数を消費しているシナリオを1本選び、移行先の課金ルールで再計算してください。それが最も正確な見積もりになります。

あわせて見たいツール・カテゴリ

• n8n — 自己ホストできるワークフロー自動化。従量課金から降りたい人はここから
• Zapier — 接続できるアプリ数を最優先するならこの選択
• 業務効率化カテゴリ — 自動化以外の時短ツールもまとめて眺められます
• AIエージェントカテゴリ — 自動化にAIの判断を挟みたくなったときの入口
• 業務効率化ツールの人気順 — 実際にどのツールが選ばれているかの参考に
• AIコーディング支援カテゴリ — 自前スクリプト路線を検討するならこちら

次に読むならこれ。自前スクリプト路線を少しでも考えているなら、Google Labsの実験的ツール解説から入ってください。ノーコードとコードの境界がどこまで曖昧になっているかが分かり、タイプ7の判断が一気に楽になります。