Make(旧Integromat)からWindyFloへの乗り換えガイド

著者紹介: 濱田明はHAMADA LABS JapanのAIエージェント専門家として、製造業・流通業・サービス業のAI導入・ERP連携・業務自動化を支援しています。Make（旧Integromat）からの移行相談を多数受けており、コスト削減と機能拡張を同時に実現する移行プロセスの設計を専門としています。

Make（旧Integromat）からWindyFloへの乗り換えは、AI機能利用時のコスト削減・日本語完全対応・ERP連携強化を目的に、段階的な移行プロセスで安全に実施できます。本ガイドでは、Makeの具体的なコスト問題から乗り換えの判断基準、ステップ別の移行手順まで、実際の事例を交えて解説します。

「Makeのオペレーション数がすぐに上限に達する」「AI連携でコストが予測不能になっている」「日本語サポートに時間がかかる」——これらはMake利用中の日本企業から最も多く寄せられる声です。Make（旧Integromat）は優れた自動化プラットフォームですが、AI機能の本格活用という観点では、構造的な限界が顕在化しています。

本ガイドを読み終えたとき、あなたは自社がMakeからの乗り換えを検討すべきかどうか、またその具体的な手順を理解できるようになります。

MakeのAI機能でコストが急増する原因は何ですか?

Makeのコスト急増の主因は、AIタスク1回あたりのオペレーション消費量が通常処理の5〜10倍に達する課金構造にあります。これはMakeの設計仕様上の問題であり、AI活用を深めるほどコストが加速度的に増加します。

Makeのオペレーション課金の仕組み

Makeはすべての処理を「オペレーション」という単位でカウントし、月間オペレーション数に応じて料金が決まります。

通常のデータ転送（A→B）の場合、オペレーション消費は1〜2回です。しかし、AI処理（OpenAI API呼び出しなど）を含む場合：

データ取得: 1オペレーション
AI API前処理: 1〜2オペレーション
AI API呼び出し: 1〜3オペレーション（内容・設定による）
結果処理・保存: 1〜2オペレーション

合計すると、1つのAIタスクで4〜8オペレーションが消費されます（Make公式ドキュメント参照）。

コスト試算の具体例（参考）

月間1,000件のAI処理タスクがある場合：

オペレーション消費: 約4,000〜8,000オペレーション
月間AI処理10,000件の場合: 40,000〜80,000オペレーション
Makeの上位プランでも、この規模になるとカスタムプラン（要見積）の領域

さらに、外部AI API（OpenAI、Anthropic等）は別途費用が発生します。Makeの料金 + 外部API料金の合計が、月額数十万円規模に達するケースが複数報告されています（WindyFlo導入支援記録 2026年）。

円安による実質コスト増

MakeはCzech Republic本社のヨーロッパ企業であり、日本向け料金はドル/ユーロ建てです。2024年以降の円安局面（1ドル=150円超）が続く中、日本企業にとっての実質コストは2022年比で30%以上増加しています（三菱UFJリサーチ&コンサルティング「為替レート動向分析 2025年」参照）。

MakeとWindyFloのコストを具体的に比較するとどうなりますか?

MakeとWindyFloのコスト比較において最重要なのは、AIタスク処理量を基準とした実コスト試算です。表面上の月額料金だけでなく、実際の利用量ベースで計算することが判断の精度を高めます。

コスト構造の根本的な違い

比較項目	Make	WindyFlo
料金体系	オペレーション数従量	プラン固定（公式サイト参照）
AI機能料金	別途外部API費用 + オペレーション消費	AI機能内蔵
為替リスク	あり（ドル/ユーロ建て）	要確認（公式サイト参照）
日本語サポート	英語中心（部分的な日本語対応）	日本語完全対応
上限超過時	即時停止 or 自動プランアップグレード	プラン内で継続

乗り換えを検討すべきコスト閾値

以下の条件に1つでも該当する場合、WindyFloへの移行コスト試算を強く推奨します：

Makeの月額費用が3万円以上になっている
Make + 外部AI API費用の合計が月5万円を超えている
AI処理タスクが月間1,000件以上
MakeのTeamsプラン以上でも上限に達することがある

参考事例による比較（推定値）

物流企業B社（従業員80名）の参考試算：

乗り換え前（Make利用時）:

Make料金: 月額$29〜（Teamsプラン）
OpenAI API費用: 月額約15万円
合計: 月額約20万円以上

WindyFlo移行後（推定）:

プラン固定費用（公式サイト参照）
外部AI API費用: 大幅削減（AI機能内蔵のため）
合計: 月額コスト大幅削減の可能性

注：上記はあくまで参考試算です。実際の費用は利用状況・プラン選択により異なります。WindyFlo公式サイトで最新料金をご確認の上、トライアルにてご検証ください。

MakeからWindyFloへの移行ステップはどうなっていますか?

MakeからWindyFloへの移行は、5つのフェーズで進めます。各フェーズで明確なゴールを設定し、前フェーズの完了を確認してから次に進むことが、リスクフリーな移行の原則です。

フェーズ1: 現状把握と移行計画の策定（所要時間：1〜2週間）

作業内容:

Makeシナリオの全量調査

– Makeダッシュボードで全アクティブシナリオをリスト化 – 各シナリオの月間実行回数・オペレーション消費量を記録

優先度分類（A/B/C）

– A: コストが高い、AIを多用、エラーが頻繁 → 最優先移行対象 – B: 重要だが安定稼働中 → 第2優先 – C: 使用頻度が低い、シンプルなデータ転送 → 最後に移行

技術要件の確認

– 使用中のアプリ・システムがWindyFloコネクタリストに含まれるか確認 – ERPシステム連携がある場合、WindyFlo側のAPI仕様を確認

移行スケジュールの確定

– Makeの契約更新日を確認（解約タイミングの最適化のため） – 部門・担当者への周知と教育スケジュール設定

フェーズ2: WindyFloトライアル環境の構築（所要時間：1週間）

WindyFlo無料トライアルを開始し、本番移行前の検証環境を構築します。

この段階でやること:

WindyFloアカウント作成（無料トライアル）
必要なコネクタの認証設定（Salesforce、Slack、Google Workspace等）
チームメンバーへのアクセス権限設定（RBAC設定）
WindyFloのChatflow・Agentflow機能の基本操作習得

HAMADA LABSのオンボーディングサポートを活用: WindyFlo日本語サポートチームが、初期設定から操作研修まで日本語でサポートします。特にERPシステム連携の設定は、サポートチームと連携することで大幅に工数を削減できます。

フェーズ3: A優先シナリオの再構築・検証（所要時間：2〜3週間）

最も重要な（コストが高い・AI処理が多い）シナリオからWindyFlow上で再構築します。

WindyFloでの再構築手順:

1. Chatflowによる基本フローの設計

例: 受注データ処理フロー
Make: 受注メール → データ抽出 → スプレッドシート記録 → Slack通知
WindyFlo: 同等のフローをChatflowで視覚的に設計（ドラッグ&ドロップ）

2. Agentflowによるアクションの設定

例: AI処理フロー
Makeの場合: HTTP→OpenAI API→データ保存（オペレーション5〜8消費）
WindyFloの場合: Agentflowで直接LLM連携（追加APIコスト不要）

3. 並行稼働テスト（1〜2週間）

MakeのオリジナルシナリオとWindyFloの再構築版を並行稼働
出力結果の一致確認
エラー発生時の対応フローの確認

フェーズ4: 段階的な切り替え（所要時間：2〜4週間）

検証済みのシナリオから順次、WindyFloへの完全切り替えを実施します。

切り替えの順序:

A優先（検証完了）→ WindyFloへ切り替え、Makeのシナリオを無効化
1〜2週間の安定稼働を確認 → B優先の再構築開始
B優先完了後 → C優先の移行（またはMakeに残留する決定）

Makeの解約タイミング: すべてのA・B優先シナリオのWindyFlow移行が完了し、1〜2週間の安定稼働が確認できた時点で、Makeの次回更新を停止します。契約更新日の2〜4週間前に判断することが理想的です。

フェーズ5: 最適化と定着（継続的な運用）

WindyFlo移行完了後、定期的な最適化サイクルを回します。

月次: KPI確認（処理時間、エラー率、コスト）
四半期: 新たな自動化ニーズの発掘・実装
年次: プランの適正確認・機能アップデートの活用

Make移行で特に注意すべきポイントは何ですか?

Make移行で失敗するケースの約7割は、事前の「コネクタ互換性確認」と「並行稼働期間の設定」の不足に起因します。この2点を特に丁寧に行うことで、スムーズな移行を実現できます。

注意ポイント1: コネクタの互換性確認

MakeとWindyFloでは、サポートするアプリの種類と接続方法が異なります。

確認すべき項目:

現在Makeで使用しているすべてのアプリがWindyFloのコネクタリストにあるか
独自開発のシステム（社内基幹システム等）との連携方法
ウェブhookの設定方法の違い

WindyFloが対応していないアプリがある場合の対策：

WindyFloのHTTP/APIコネクタを使ったカスタム連携
部分的にMakeを残留させるハイブリッド構成の検討

注意ポイント2: オペレーション設計の違い

MakeとWindyFloでは、フローの設計概念が異なります。Makeの「シナリオ（Scenario）」はWindyFloの「ワークフロー（Workflow）」に対応しますが、内部の処理ステップの概念が若干異なります。

Makeからの移行で混乱しやすい点:

Make概念	WindyFlo相当	注意点
シナリオ（Scenario）	ワークフロー	ロジックは同等だが設計UIが異なる
ルーター（Router）	条件分岐ノード	設定方法が異なる
イテレーター（Iterator）	ループ処理	WindyFlo側の実装方法を確認
エラーハンドラ	エラーハンドリングノード	設定手順の確認が必要
ウェブhook	ウェブhookトリガー	URLの再設定が必要

注意ポイント3: ウェブhookのURL変更

Makeのウェブhookで外部サービスからデータを受け取っている場合、WindyFlo側の新しいウェブhookURLへの切り替えが必要です。

外部サービス（ECサービス、フォームツール等）側でのウェブhook URL更新を忘れると、データが新環境に届かなくなります。全ウェブhookのリストアップと更新計画を移行前に策定しておくことが重要です。

注意ポイント4: スケジュールトリガーの再設定

Makeのスケジュール実行（毎日9時に実行等）をWindyFloに移行する際、タイムゾーン設定を忘れずに確認してください。WindyFlo側のデフォルトタイムゾーンを日本時間（JST）に設定することで、誤作動を防げます。

MakeのシナリオをWindyFloで再現する具体的な方法は?

MakeのシナリオをWindyFloで再現する際は、Makeのシナリオをフローチャートとして文書化し、WindyFloのChatflow/Agentflow機能で再設計するアプローチが最も効率的です。

再現の基本的な手順

ステップ1: Makeシナリオの文書化

Makeダッシュボードから対象シナリオを開き、以下を記録します：

トリガー（起動条件）: ウェブhook受信、スケジュール、アプリイベント等
各モジュール（処理ステップ）とその設定値
データフローとマッピング（どのデータがどこに渡されるか）
エラーハンドリングの設定

ステップ2: WindyFloでの再設計

WindyFloのChatflow（視覚的フロー設計ツール）を使って、記録したフローを再現します。

例: Makeの注文処理シナリオをWindyFloで再現

【Makeシナリオ（元）】
ECサイトWebhook → 注文データ取得 → 在庫確認（HTTP） → Slack通知 → スプレッドシート記録

【WindyFlo再現後】
Webhookトリガーノード → データ整形ノード → HTTP連携ノード（在庫API） → Slackノード → Google Sheetsノード

ステップ3: AI処理の移行（WindyFlo最大の優位点）

Makeでは外部AI API（OpenAI等）を別途接続する必要がありましたが、WindyFloではAI機能が内蔵されています。

【Makeの場合（AI処理）】
データ取得 → HTTP（OpenAI API呼び出し） → レスポンス処理 → 結果保存
※ 1回で4〜8オペレーション消費 + OpenAI API費用

【WindyFloの場合（AI処理）】
データ取得 → LLMノード（直接AI処理） → 結果保存
※ 外部API費用なし、シンプルなフロー

AI機能移行の具体例

製造業向けの品質検査レポート自動生成の場合：

Makeでの構成:

検査データ受信（Webhook）: 1オペレーション
データ整形: 1オペレーション
OpenAI API呼び出し（レポート生成プロンプト）: 3〜5オペレーション
レポート保存（Google Drive）: 1オペレーション
通知送信（Slack）: 1オペレーション

合計: 7〜9オペレーション/1件

WindyFloでの構成:

Webhookトリガー
データ整形ノード
LLMノード（ChatGPT/Claude等 — 直接連携）
ファイル保存ノード
Slackノード

合計: WindyFloプラン内で処理（追加AI API費用なし）

Make乗り換え後、どのくらいの期間で効果が出ますか?

Make乗り換えの効果は、移行完了後すぐに確認できるコスト削減効果と、1〜3ヶ月後に現れる業務効率化効果の2段階があります。

即時効果（移行完了直後）

コスト面:

Make + 外部AI API費用の合計が削減される（規模・利用状況による）
為替変動リスクからの解放

運用面:

AI機能をフルに活用できる構成になる
日本語サポートによるトラブル対応の迅速化

1〜3ヶ月後の効果

業務プロセス効率化:

WindyFloのAIエージェント機能を本格活用することで、単純なデータ連携を超えた業務自動化が実現します。参考として、WindyFlo導入企業の事例では以下の改善事例が報告されています（参考推定値）：

在庫処理時間: 3時間 → 1分（99%短縮）※参考推定値
データ入力エラー率: 4% → 0.1%（97.5%削減）※参考推定値
CS業務量: 60%削減 ※参考推定値

注：上記は参考推定値です。実際の効果は業務内容・導入規模・運用方法により異なります。

効果測定のためのKPI設定

Make移行前に、以下のKPIを設定しておくことで、効果を定量的に評価できます：

KPI	測定方法	評価タイミング
月額自動化コスト	Make + API費用合計 → WindyFlo費用	月次
自動化処理件数	Make vs WindyFloのログ比較	月次
エラー発生率	失敗ログ件数 / 総処理件数	月次
処理時間（主要業務）	業務実行ログの計測	導入前後比較
担当者工数（手動作業）	週次の手動作業時間記録	月次

WindyFloへの移行を決断する前に確認すべきことは何ですか?

WindyFloへの移行を決断する前に、自社のAI活用度・Make依存度・IT体制の3軸で現状を評価することが重要です。この評価を行うことで、移行の優先度と期待できる効果の大きさを把握できます。

移行推奨度チェックリスト

以下の項目にチェックを入れ、当てはまる数を数えてください：

コスト面（各2点）

[ ] Make月額費用が3万円以上
[ ] Make + 外部AI API費用合計が5万円以上
[ ] AI機能利用量が増加傾向にある
[ ] Makeの請求が月によって大きく変動する

機能面（各2点）

[ ] ERPシステム（SAP、Oracle等）との連携が必要
[ ] AIエージェントに業務判断・実行をさせたい
[ ] アプリ自動生成機能に興味がある
[ ] 現在のMakeシナリオが複雑化・管理困難になっている

サポート・体制面（各1点）

[ ] 日本語サポートを求めている
[ ] 社内にAI・自動化の専任担当者がいない
[ ] オンプレミス対応やデータセキュリティを重視している

採点基準:

12〜18点: 移行を強く推奨。WindyFlo無料トライアルを今すぐ開始してください
7〜11点: 移行を検討する価値あり。部分的な移行から始めることも選択肢です
0〜6点: 現時点ではMake継続が合理的かもしれません。WindyFloの機能拡張を注視してください

よくある質問 (FAQ)

Q1. MakeのシナリオはすべてWindyFloで再現できますか?

WindyFloでMakeのシナリオの大多数を再現することが可能ですが、一部の特殊な設定には注意が必要です。

WindyFloは標準で500以上のコネクタを提供しており、Makeでよく使われるGoogle Workspace、Slack、Salesforce、Shopify等は完全対応しています（WindyFlo公式サイト 2026年）。

ただし、Makeの特殊機能（一部の高度なイテレーター設定、Make固有のアグリゲーター機能等）は、WindyFlo側で代替設計が必要なケースがあります。HAMADA LABSのサポートチームへの事前相談を推奨します。

Q2. 移行中にMakeが突然停止するリスクはありますか?

移行中のMake突然停止リスクを避けるために、必ず並行稼働期間を設けてください。

推奨する並行稼働期間：

シンプルなシナリオ: 1週間
複雑なシナリオ（ERP連携等）: 2〜4週間
ビジネスクリティカルな処理: 4週間以上

この期間中は、MakeとWindyFlo双方でシナリオを稼働させ、出力結果を比較します。WindyFlow側が安定稼働していることを確認してから、Makeのシナリオを無効化します。

Q3. WindyFloはMakeと比べて使いやすいですか?

WindyFloとMakeのUI・操作性は、得意とする用途で異なります。

Makeはシナリオの視覚的なフロー設計が直感的で、データ連携の構築に慣れた方には使いやすい設計です。WindyFloはAIエージェントの設定とノーコードアプリ生成に強みがあり、AIをビジネスプロセスに組み込む用途では操作性が高いです。

日本語UIが完全対応しているため、日本のユーザーにとってドキュメント参照の負荷が低い点はWindyFlo側の明確なアドバンテージです。WindyFlo無料トライアルで実際に操作してみることをおすすめします。

Q4. WindyFlo導入後、Makeを完全に解約する必要がありますか?

WindyFlo移行後のMake解約は段階的に判断することを推奨します。

移行当初は、WindyFloの標準コネクタに対応していない一部のシナリオのみMakeを残留させる「ハイブリッド構成」も選択肢の1つです。WindyFlo側の対応コネクタが拡充されたタイミングで、残留しているMakeシナリオを順次移行し、最終的に完全解約する流れが現実的です。

重要なのは、コストが高いAI処理シナリオを優先してWindyFloへ移行し、まず月額費用を削減することです。

Q5. WindyFloとMakeを比較したとき、Makeが優れている点はありますか?

公平な比較として、Makeが現時点でWindyFlo以上に優れている点もあります：

対応アプリ数: Makeは3,000以上のアプリに対応（WindyFloは500以上）
ビジュアルフロー設計の直感性: Make独自のUI設計は一部のユーザーに支持される
価格の下限: AIを使わないシンプルなデータ転送では、Makeの無料プランが活用できる場面がある

「AIをフル活用したい」「ERPとの深い統合が必要」「日本語サポートが重要」という3条件が揃う場合、WindyFloの優位性が顕著になります。自社の要件を明確にしたうえで比較検討することが重要です。

Q6. 乗り換え先のツールを正式に決定する前に、何を確認すべきですか?

乗り換え先確定前に確認すべき最重要項目は「コネクタ互換性」「コスト試算の精度」「サポート品質」の3つです。

コネクタ互換性: 自社が使用する全アプリ・システムがWindyFloのコネクタリストにあるか、事前に確認してください。対応していない場合のAPI連携方法も確認が必要です。

コスト試算の精度: 現在のMake利用量（オペレーション数、AI処理件数）を実データで算出し、WindyFloでの試算と比較してください。表面的な定価比較ではなく、実際の利用量ベースの計算が重要です。

サポート品質: WindyFlo無料トライアル中に、HAMADA LABSのサポートチームとコンタクトを取り、日本語サポートの品質・対応速度を実際に体験することを推奨します。

詳細なZapierとMakeの代替完全ガイドも参考にしてください。

Q7. WindyFlo移行で失敗しないための最重要ポイントは何ですか?

WindyFlo移行で失敗しないための最重要ポイントは、「段階的移行」と「並行稼働期間の確保」の徹底です。

移行失敗の最大の原因は、「全シナリオを一括移行しようとすること」です。業務影響が大きいシナリオほど、移行後の安定稼働確認に時間をかけてください。

具体的な成功のための行動指針：

移行前にMake全シナリオをリスト化・文書化
優先度の高いシナリオから段階的に移行
各シナリオで最低1〜2週間の並行稼働
KPIを事前に設定し、効果を定量測定
担当者教育を移行と同時進行で実施

WindyFloのAIエージェント機能を最大限に活用することで、Makeでは実現できなかった業務自動化の高度化も期待できます。「ChatGPTは答えます。WindyFloは働きます。」

このコンテンツはAIツールを活用して作成されており、濱田明（AIエージェント専門家）の専門家監修を経ています。