Makeを実際に使ってみた評価レビュー【2026年最新】ノーコード自動化の実力とクレジットの考え方

Make（メイク）は、旧Integromatとして知られるノーコードの業務自動化ツールです。アプリ同士をつなぐ処理をキャンバス上に並べ、分岐や繰り返しまで目で見ながら組めるのが特徴で、3,000以上のアプリ連携を備えています。編集部では、問い合わせの振り分けと請求書PDFの処理という2つの業務を実際に組んで試しました。料金はクレジット制で、無料プランは1,000クレジット・同時稼働2シナリオ・15分間隔という制限があります。本記事では2026年10月時点の公式情報をもとに、できることと費用の読み方を整理します。

Makeとは？基本情報

Makeは、トリガー（きっかけ）とアクション（処理）をモジュールという部品でつなぎ、業務の流れをそのまま自動化するサービスです。最大の特徴は、処理の流れをキャンバス上に図として描ける点にあります。フィルターで条件を分け、ルーターで枝分かれさせ、イテレータで配列を1件ずつ処理する、といった組み方が画面上で完結します。

編集部が最初に確認したのは、無料プランでどこまでできるかという点です。無料プランは1,000クレジット・同時稼働2シナリオ・実行間隔15分以上という構成で、1実行の上限は5分、扱えるファイルは5MBまでです。動きを確かめるには十分ですが、毎日の定時処理を2本より多く動かすと、すぐに枠が埋まります。

同じ自動化でも、Zapierは「つなぐ」ことに強く、n8nは自前ホスティングで細かく制御する方向に振っています。Makeは図で組めることと、分岐の表現力が中間に位置します。処理の流れを人に説明する必要がある業務ほど、この差は効いてきます。

編集部が実際に組んだのは、問い合わせフォームの送信をきっかけに、本文をAIで分類し、緊急度に応じて3つの経路へ分岐、担当者のチャットへ通知し、同時に表計算へ1行追加する流れです。モジュールは7つ、分岐を含めて1実行あたり平均9クレジットでした。1日50件なら月13,500クレジットとなり、Coreの10,000では足りません。ここで初めて「追加クレジットを買うか、処理そのものを減らすか」を判断することになります。

実際に使ってみた感想

分岐のある業務がそのまま図になる

編集部では、問い合わせフォームの内容を読み取り、緊急度と種類で振り分けて、担当者のチャットと表計算に同時に流すシナリオを組みました。条件分岐をルーターで分け、緊急のものだけ別のチャンネルに通知する流れです。この「条件で枝分かれする」処理を、コードを書かずに図のまま保守できるのがMakeの価値だと感じました。半年後に見返したとき、処理の意図が図から読み取れるため、引き継ぎのコストが下がります。

クレジット消費は「数えてから決める」が正解

いちばん戸惑ったのは料金の読み方です。クレジットは、1回の実行で通過したモジュールの数だけ消費します。3ステップのシナリオを1日100回動かせば、単純計算で月9,000クレジットです。さらにAIやコード系のモジュールは1回で複数クレジットを消費するため、AI要約を挟んだ瞬間に計算が崩れます。編集部では、テスト実行を1週間走らせて実行ログから実際の消費量を数え、その数字でプランを決める方法に落ち着きました。最初から上位プランを契約する必要はありません。

エラー処理を入れておくと止まらない

外部APIは、認証切れやレート制限で普通に失敗します。Makeはモジュールごとにエラーハンドラを付けられ、失敗したときに「リトライする」「別の経路に流す」「処理を続ける」を選べます。編集部では、失敗した実行だけを記録する経路を用意し、翌朝にまとめて確認する運用にしました。自動化が止まる原因の多くは、失敗そのものではなく、失敗に気づかないことです。ここを設計に含められるかどうかで、運用の負荷が変わります。

同じ処理でも、通す順番で費用が変わる

クレジットを抑える方法は3つあります。1つは、分岐の前にフィルターを置き、対象外のデータを早い段階で落とすこと。2つは、複数の更新を1つのモジュールにまとめること。3つは、AIで判定する件数を絞り、明らかなものは条件分岐で処理することです。編集部では、フィルターを先頭に置くだけで消費が2割ほど下がりました。クレジットは通したモジュールの数で決まるため、通さない設計が最も効きます。逆に、とりあえず全部通してから分岐する組み方は、図としては読みやすくても費用が膨らみます。

Makeの良い点

• 分岐・繰り返し・集約を図で組める。多段の業務フローでも全体像を保ったまま保守できます
• 連携先が3,000以上。主要なSaaSはほぼ揃っており、未対応でもHTTPモジュールで叩けます
• 全プランでユーザー数無制限。席課金ではないため、チームで共有しても費用が増えません
• 実行ログが詳細。どのモジュールで、どのデータが、どう変わったかまで追えます
• 無料プランの制限が明確。2シナリオ・15分間隔という枠が先に示されるため、過剰な期待をしなくて済みます
• 年払いの割引が素直。月払いより15％以上安く、為替変動の影響も年単位で固定できます

自動化の前後工程も、既存のツールで分担できます。会議の記録はFireflies.ai、動画の字幕入れはVEED.IO、タスクの管理はClickUpやMotion、文章の下書きはChatGPTやClaudeに任せ、Makeはそれらをつなぐ配管に徹する、という組み方が現実的です。数字の集計を伴う処理ならJulius AI、定型判断をまとめて任せるならManusが候補になります。Zapierからの移行を検討している場合はZapierのレビューで料金体系の違いを先に確認しておくと、比較がぶれません。

もう1つ見逃せないのが、実行履歴の読みやすさです。失敗した実行を開くと、どのモジュールにどんなデータが入り、どこで止まったかが順に並びます。自動化は「動いたかどうか」ではなく「なぜ動かなかったか」を追えるかで運用コストが変わるため、障害対応の時間まで含めて評価すると、この差は見た目以上に大きくなります。編集部では、通知が来た時点で該当の実行履歴を開き、入力データから原因を特定できるため、調査に30分以上かかったことはありません。

気になった点・導入前の注意点

• クレジット消費が読みにくい。AIやコード系のモジュールは1回で複数クレジットを消費します
• 無料プランは同時稼働2シナリオまで。3本目を有効化するには有料プランが必要です
• 無料プランは実行間隔15分以上。リアルタイム性が要る処理には向きません
• 複雑なシナリオは保守が重くなる。ルーターとイテレータが入れ子になると可読性が落ちます
• 月払いのクレジットは月末で失効します。年間プランでも扱いが異なるため契約前に確認が必要です
• 料金は米ドル建てです。日本円の請求額は決済時の為替と税金で変わります

とくに1点目と5点目は、契約前に押さえておきたい部分です。「クレジットは毎月消える前提で、実測値に1〜2割の余裕を足す」という見積もりにしておくと、途中で追加クレジットを買う事態を避けられます。

また、シナリオが増えてくると、命名とフォルダ分けのルールを先に決めておかないと、どれが動いているのか分からなくなります。編集部では「業務名_トリガー_頻度」の形式で名前を付け、無効化したシナリオには停止した日付を入れる運用にしました。自動化は作るときより、半年後に触るときのほうが難しいため、最初に少しだけ整えておくと後が楽になります。作りっぱなしで放置されたシナリオは、たいてい誰も止められずに課金だけが続きます。

Makeの料金プラン

プランは無料を含めて5段階です。有料プランはいずれも10,000クレジットから始まり、上位プランは量ではなく実行の優先度・扱えるファイルサイズ・権限まわりで差が付きます。年払いにすると月あたりの負担が15％以上下がります。

料金・クレジット・上限は変更されることがあります。公式の料金ページは通貨と課金サイクルで表示が変わり、日本円での請求額は決済時の為替と税金で変わります。クレジットの失効時期は契約形態で異なるため、更新前に必ず公式の請求条件を確認してください。本記事は2026年10月時点で確認できた情報にもとづく整理です。

実際の費用を、3つの利用像で試算してみます。①問い合わせ対応を1日20件、7モジュールで処理するなら月およそ4,200クレジットでCoreに収まります。②同じ処理が1日80件に増えると月16,800クレジットとなり、Coreでは不足するため追加クレジットか上位プランへの変更が必要です。③AI要約を1件あたり3クレジット消費する形で1日50件回すと、それだけで月4,500クレジットが上乗せされます。先に「1回あたり何クレジットか」を実測し、件数を掛けるのが、最も外れの少ない見積もり方です。

Zapier・n8nとの違い

自動化ツールは、つなぐ手軽さ、組み方の自由度、運用の置き場所で性格が分かれます。優劣ではなく、業務の複雑さと社内の技術力に合わせて選ぶものです。

判断の目安は業務の分岐の多さと、データを外に出せるかどうかです。分岐が多く、関係者に流れを説明する必要があるならMakeが扱いやすくなります。1本2〜3ステップの単純な連携を大量に作りたいならZapierのほうが速い場面もあります。社外に出せないデータを扱うなら、n8nの自前運用と比較したうえで決めてください。会議や動画の周辺業務まで含めて整えるなら、Notion AIやGoogle Geminiを組み合わせる選択肢もあります。

移行を検討するときは、いきなり全シナリオを移さないほうが安全です。まず1本をMakeで組み、同じ処理を旧ツールと並行して1週間動かし、消費量と失敗率を比べます。この比較で差が出なければ、そのまま移行を進める価値があります。移行の目的が「安くする」なのか「保守しやすくする」なのかを先に決めておくと、途中で判断がぶれません。両方を同時に狙うと、どちらも達成できずに終わりがちです。

Makeはどんな人におすすめか

• 問い合わせ対応や受注処理など、条件で枝分かれする業務を自動化したい担当者
• 自動化の流れを、エンジニア以外のメンバーにも説明できる形で残したいチーム
• 席課金を避けたい。メンバーが増えても費用を抑えたい
• Zapierでタスク消費が増え、費用対効果を見直したい
• AIを使った分類・要約を、既存の業務フローの中に組み込みたい

導入を決める前に、次の5点を確認しておくと判断が速くなります。

• 自動化したい業務の分岐は何段階あるか（2段階までならZapierでも足ります）
• 1日に何回、何件動くか（件数×モジュール数がクレジットの上限を決めます）
• 失敗したときに誰が気づくか（通知先を決めていない自動化は、止まっても気づけません）
• 扱うデータを外部に出してよいか（出せないなら自前運用の選択肢と比較します）
• 半年後に触るのは誰か（引き継ぐ前提なら、図で残せるツールが有利です）

実際に導入するときは、次の4段階で進めると失敗が少なくなります。

1. 業務を1つに絞る：毎週必ず発生する作業を1つ選び、現在の手順を紙に書き出します。ここで「例外処理」が3つ以上あるなら、自動化の範囲を分けたほうが安全です。
2. 無料プランで組む：トリガーとアクションを並べ、まず1件を通します。動いたら、失敗したときの通知先を必ず設定してください。
3. 1週間動かして消費を数える：実行ログから1件あたりのクレジットを出し、月の件数を掛けます。この数字がプラン選びの根拠になります。
4. プランを決めて横に広げる：1本が安定してから2本目に進みます。同時に3本を立ち上げると、どれが原因の失敗か分からなくなります。

よくある質問（FAQ）