先月、流通業を営む取引先の担当者から、Makeの請求書を一枚見せられました。前月比で4割増えた金額の横に、本人が走り書きしたメモが残っていました。「何が増えたのか分からない」。
これは特殊なケースではありません。判断はシンプルです。Makeのコストが読めなくなる原因は、料金が「実行回数」に連動する従量課金であり、そこにAIを足すと消費が一気に跳ね上がる構造にあります。私が経営者として最初に確認するのは、その請求書の中で「本当に成果を生んでいる支出」がどこまでなのか、という一点です。コストの内訳を分解すれば、Makeを使い続けるべき部分と、WindyFloへ移すべき部分の線引きは明確になります。
Makeのコストはなぜ高くなるのですか?
Makeのコストが高くなる最大の理由は、料金が「オペレーション」という実行単位の従量課金になっており、自動化が成果を上げて稼働回数が増えるほど費用も比例して膨らむ点にあります。使えば使うほど高くなる構造が、月末の想定外の請求を生みます。
Makeでは、シナリオ内のモジュールが1回処理を実行するたびに「オペレーション（Operation）」が1つ消費されます（Make公式ドキュメント「Operations の定義」2026年）。データを1件取得すれば1オペレーション、それを加工してどこかへ送れば、さらにオペレーションが積み上がります。つまり費用は「何を自動化したか」ではなく「何回処理が走ったか」で決まります。
この構造が問題になるのは、自動化が業務に定着し始めた段階です。導入初期は月数千オペレーションで収まっていた企業が、複数部署へ展開した途端に数十万オペレーションへ達し、上位プランへの移行を余儀なくされるケースを何度も見てきました。自動化の成功がそのままコスト増に直結するのは、経営判断として扱いにくい性質です。
オペレーション消費が積み上がる仕組み
具体的に、受注処理を1件自動化する場合を考えてみます。注文データの取得で1、在庫システムへの照会で1、条件分岐の評価で複数、結果の通知で1というように、1件の業務フローでも複数のオペレーションを消費します。1日100件の受注があれば、それだけで日々数百オペレーションが流れていく計算です。
| 利用段階 | 月間オペレーション目安 | Makeの状況 |
|---|---|---|
| 導入初期（1部署・少数シナリオ） | 数千〜1万 | 下位プランで収まる |
| 定着期（複数業務へ展開） | 数万〜10万 | 中位プランへ移行が必要 |
| 全社展開（AI処理を併用） | 数十万以上 | 上位プラン+追加費用が発生 |
※ オペレーションの定義と各プランの上限はMake公式サイト（2026年）を参照。実際の消費量は構築するシナリオの設計により大きく異なります。
為替の影響も無視できません
Makeはドル建ての海外サービスであり、日本企業にとっては為替変動が実質コストに上乗せされます。円安が進んだ局面では、同じプランを使い続けているだけで日本円での支払額が増える状況が続いてきました。料金体系そのものが変わらなくても、決算上のコストは膨らむということです。経営者の立場からは、自社のコントロールが効かない変数で予算が揺れること自体が、判断材料として軽視できません。
なぜ「使うほど高くなる」が経営課題になるのか
総務省「令和5年版情報通信白書」によると、クラウドサービスを一部でも利用している企業の割合は8割を超えています。クラウド前提の業務はすでに当たり前になり、自動化ツールもその延長線上にあります。問題は、Makeのような従量課金モデルでは「業務を自動化して効率を上げる」という目的そのものが、コスト増の引き金になる点です。
経営判断の言葉で言えば、これは投資とリターンの向きが逆を向く構造です。通常、業務改善への投資は固定費に近く、使い込むほど1件あたりのコストは下がっていくのが望ましい姿です。ところがオペレーション従量課金では、成果が増えるほど変動費が積み上がり、損益分岐の見通しが立てにくくなります。私が請求書を最初に分解するのは、この「向きの逆転」がどこで起きているかを特定するためです。
AIをMakeで使うと、なぜ費用が跳ね上がるのですか?
AIをMakeで使うと費用が跳ね上がるのは、AI関連の処理が通常のオペレーションより多くのクレジットを消費しやすく、さらにAI API自体の利用料が別途発生する「二重のコスト」になりやすいためです。AIを本格活用するほど、この二重構造が月額費用を予測しにくくします。
MakeにはAI機能が標準で組み込まれているわけではありません。AIを使いたい場合は、OpenAIやAnthropicといった外部APIをシナリオのステップとして組み込む形になります。Makeの公式ヘルプセンターでも、組み込みAIプロバイダーを利用する処理はトークン量やファイルサイズに応じて1オペレーションを超えるクレジットを消費すると案内されています（Make公式ヘルプセンター「How features use credits」2026年）。AI処理を多く含むシナリオほど、通常の連携より消費が重くなる傾向があります。
問題はそれだけにとどまりません。Makeのオペレーション消費とは別に、OpenAI側のAPI利用料（トークン課金）が並行して発生します。つまり「Makeのオペレーション料金」と「AI APIのトークン料金」という2つの従量課金が同時に動くことになります。
月80万円という現実
実際に、流通業を営むある日本企業では、MakeとOpenAI APIを組み合わせた構成で月額80万円以上のコストが発生していました（参考事例：WindyFlo導入支援記録 2026年）。自動化の範囲を広げ、AIによる文書処理や問い合わせ対応を回すほど、この金額は膨らんでいきました。
ここで重要なのは、この80万円が「無駄遣い」ではなかったという点です。自動化は確かに成果を出していました。それでも、AIを足すたびにコストが青天井に近づく構造そのものが、経営判断としては受け入れがたいものでした。投資配分の観点では、「成果は出ているが、コストの天井が見えない」という状態こそが最も避けたいシナリオです。
| コスト要素 | Make + 外部AI APIの構成 | 性質 |
|---|---|---|
| Makeのオペレーション料金 | プラン上限を超えると追加発生 | 従量課金（実行回数連動） |
| AI APIのトークン料金 | 処理テキスト量に比例 | 従量課金（OpenAI等へ別途支払い） |
| 為替上乗せ | 円安局面で実質増加 | 外部変数（コントロール不可） |
| 合計の予測可能性 | 月末まで読みにくい | 予算計画が立てにくい |
WindyFloに移行するとどれだけ削減できますか?
WindyFloへ移行すると、AI機能が追加費用なしで標準搭載されているため「二重課金」が解消され、機能を向上させながら月額コストを下げられるケースが多数報告されています。特にAIを多用していた企業ほど、削減幅は大きくなります。
WindyFloは、ノーコードでAIエージェントとビジネスワークフローを一体化した業務自動化プラットフォームです。「ChatGPTは答えます。WindyFloは働きます。」——このスローガンが示すとおり、WindyFloはAIが実際に業務を実行する仕組みを、プラットフォーム内部に持っています。AIを使うために外部APIを別途呼び出し、そのたびにオペレーションを消費する必要がありません。
これがコスト面で決定的な違いを生みます。Makeでは「実行回数に応じたクレジット消費 + AI処理の追加消費 + AI APIトークン料」で膨らんでいた費用が、WindyFloではAI処理を含めた利用が想定された料金体系に収まります。AIを多用する企業ほど、移行による削減効果が出やすいのはこのためです。
乗り換え前後のコスト比較
| 項目 | 乗り換え前（Make + 外部AI API） | 乗り換え後（WindyFlo） |
|---|---|---|
| 課金の単位 | オペレーション従量 + AIトークン従量 | 利用規模に応じた体系 |
| AI機能 | 別途外部API（クレジット消費が重く + トークン料） | 標準搭載（追加費用なし） |
| コストの予測可能性 | 月末まで読みにくい | 月初に予算計画を立てやすい |
| 為替リスク | ドル建てで影響を受ける | 円建て対応（詳細は公式サイト参照） |
| ERP連携対応数 | カスタム開発が必要なケースが多い | 500以上の標準コネクタ |
| 日本語サポート | 英語中心 | 日本語完全対応 |
※ WindyFloの具体的な料金は公式サイトにてご確認ください。上記は構造の比較であり、削減額は個社の利用状況により異なります。
削減事例（参考）
製造業A社（従業員150名）の参考事例では、Makeと外部AI APIの複合構成で月額約60万円かかっていたコストが、WindyFlo導入後に大幅に削減されました。移行期間は約3週間、副次効果として在庫処理の自動化により処理時間が3時間から1分へ短縮されています（参考推定値）。
ここで強調しておきたいのは、削減額そのものよりも「コストが予測できるようになった」という変化のほうが、経営判断上は大きいという点です。月初に上限が見える予算は、稟議も立てやすく、追加投資の判断も速くなります。費用の絶対額が下がること以上に、コストの不確実性が消えることに価値があります。
Makeを使い続けるべきケースもありますか?
はい、あります。シンプルなデータ転送が中心で、AIをほとんど使わず、稼働回数も安定している業務では、Makeを使い続けるほうが合理的なケースもあります。公平な投資判断のためには、すべてを移行するのではなく、コストが膨らんでいる部分を見極めることが先です。
私が乗り換えの相談を受けたとき、必ず「全部を移す必要はありません」と伝えます。Makeのビジュアルなシナリオ設計は直感的で、軽量な連携であれば下位プランの範囲で安定して動きます。問題が起きているのは、たいていAIを併用している処理や、稼働回数が膨らんだ一部の業務に集中しています。
経営判断としては、請求書の中で「どの処理がコストの大半を占めているか」を特定し、そこだけをWindyFloへ移すという部分移行が現実的です。コストの8割が一部のAI処理から発生しているなら、その部分だけ移すだけで支出構造は大きく変わります。残りのシンプルな連携は、無理に動かす必要はありません。
移行を優先すべき業務・そうでない業務
| 区分 | 特徴 | 判断 |
|---|---|---|
| 優先して移行 | AI APIを多用・稼働回数が多い・月末に請求が跳ねる | WindyFloへ移すとコスト効果が大きい |
| 移行を急がない | シンプルなデータ転送のみ・AI不使用・稼働が安定 | Makeのまま様子を見てよい |
| 慎重に判断 | ERP連携を含む基幹業務 | 並行稼働で検証してから移行 |
このように区分すれば、移行は「全面刷新」ではなく「コストが膨らんでいる部分の付け替え」になります。投資配分の観点では、効果が最も大きい一点から着手するのが、機会費用を抑える最短経路です。
WindyFloへの移行はどう進めればいいですか?
WindyFloへの移行は、いきなり全シナリオを移すのではなく、コストが膨らんでいる業務から段階的に付け替える3ステップで進めるのが安全です。リスクを最小化しながら、削減効果を早期に実感できます。
ステップ1: 請求書ベースの棚卸し（1〜2週間）
最初に行うのは、過去3ヶ月のMake請求書と、稼働中のシナリオ一覧の突き合わせです。どのシナリオがどれだけオペレーションを消費しているかを洗い出し、AI APIを併用している処理に印をつけます。この段階で、コストの大半を生んでいる「少数の重い処理」が見えてきます。
優先度は、コストの高さ・AI利用量・エラーの頻度の3軸で分類します。コストが高くAIを多用している処理が、最優先の移行対象です。
ステップ2: トライアルでの並行検証（2〜3週間）
最優先の処理をWindyFlo上で再構築し、実際の業務データで動作を検証します。WindyFloの無料トライアル期間中に、Makeと並行稼働させて結果を比較するのが確実です。AI処理を含むフローは、出力の精度とコストの両面で、移行前後を数値で照らし合わせます。
並行稼働の期間を確保することで、いきなり本番を切り替える不安を避けられます。
ステップ3: 段階的な切り替えと解約（1〜2ヶ月）
検証が済んだ処理から順にWindyFloへ移し、Makeのプランは更新タイミングに合わせて段階的に縮小・解約します。重い処理をWindyFloへ移すと、Makeのオペレーション消費が減るため、下位プランへの変更だけでも支出が下がる場合があります。二重払いを避けるため、解約はMakeの更新月を確認してから行います。
移行時の注意点は何ですか?
移行で最も注意すべきは、Make特有のシナリオ設定をそのまま移そうとして、構造の違いを見落とすことです。MakeとWindyFloは設計思想が異なるため、機能の単純な置き換えではなく、業務フローとして再設計する視点が必要です。
実務上、次の4点を事前に押さえておくと移行が滑らかになります。第一に、現在のシナリオ設定とデータマッピングを記録・バックアップしておくこと。第二に、重要業務は1〜2週間の並行稼働を経てから完全移行すること。第三に、ERPや独自システムとの連携部分は検証に最も時間がかかるため、早めに着手すること。第四に、操作に慣れるための社内研修を、移行と並行して進めることです。HAMADA LABS Japanでは、これらの工程を日本語でサポートしています。
WindyFloはどのような日本企業に向いていますか?
WindyFloが特に向いているのは、Make+外部AI APIの構成で月額コストが高騰している企業と、ERP連携や日本語サポートを必要とする中小・中堅企業です。AIを業務に本格的に組み込みたい企業ほど、移行の効果が明確に出ます。
経営者として導入相談に立ち会ってきた経験から、効果が出やすい企業には共通点があります。第一に、AIによる文書処理や問い合わせ対応をMakeで回しており、AI関連のオペレーション消費が請求の大半を占めている企業。こうした企業は、WindyFloのAI標準搭載によってコスト構造が根本から変わります。
第二に、SAPやOracleといったERPシステムとの連携が必要な製造業・流通業です。WindyFloは500以上の外部システムコネクタを標準搭載しており、Makeではカスタム開発が必要だった基幹システム連携を、ノーコードで設定できます（WindyFlo公式 2026年）。第三に、IT人材が限られ、日本語での導入支援を必要とする中小企業です。プロンプト入力からアプリを自動生成する機能により、専任エンジニアがいなくても運用を立ち上げられます。
一方で、シンプルなデータ転送だけで完結し、AIを使わない業務であれば、移行の優先度は高くありません。投資判断としては、コストが膨らんでいる領域に絞って移すことが、最も合理的な一手です。
IDC Japanの国内AIシステム市場予測（2025年発表）によると、国内AIシステム市場は2024年から2029年にかけて年平均成長率20%以上の高成長が見込まれています。業務自動化にAIエージェントを組み込む流れは、製造業・流通業を中心に加速しています。この流れの中でコストの予測可能性を確保しておくことは、単なる経費削減ではなく、AI活用を継続的に広げていくための前提条件になります。コストの天井が見えれば、次の業務へAIを展開する判断も速くなるためです。経営の視点では、今コスト構造を整えておくことが、来期以降の投資配分を有利にする布石になります。
よくある質問（FAQ）
Q1. Makeのオペレーションとは何ですか?
オペレーション（Operation）とは、Makeのシナリオ内でモジュールが1回処理を実行するたびに消費される課金単位です（Make公式ドキュメント 2026年）。
データを1件取得する、加工する、送信するといった処理ごとに1オペレーションが消費されます。1件の業務フローでも複数のモジュールを経由するため、オペレーションは積み上がります。Makeの料金プランはこのオペレーション数の上限で区切られており、上限を超えると上位プランへの移行や追加購入が必要になります。
Q2. なぜAIを使うとMakeの費用が急に増えるのですか?
AIを使うとMakeの費用が急増しやすいのは、AI関連の処理が通常より多くのクレジットを消費しやすく、加えてAI API自体のトークン料金が別途発生するためです。
MakeにはネイティブのAI機能がないため、OpenAI等の外部APIをシナリオに組み込む必要があります。Make公式ヘルプセンターによれば、組み込みAIプロバイダーを使う処理はトークン量やファイルサイズに応じて1オペレーションを超えるクレジットを消費します（Make公式ヘルプセンター 2026年）。さらにOpenAI側への支払いも並行して発生するため、「Makeのオペレーション・クレジット料金」と「AIのトークン料金」という2つの従量課金が同時に動くことが、費用が読めなくなる原因です。
Q3. WindyFloに移行すると本当に安くなりますか?
安くなるかどうかは利用状況によりますが、AIを多用している企業ほど削減効果が出やすいです。
WindyFloはAI機能を追加費用なしで標準搭載しているため、Makeで発生していた「AI処理によるクレジット消費 + トークン料」という二重課金が解消されます。一方、AIをほとんど使わずシンプルなデータ転送のみの場合は、削減幅が小さいこともあります。過去3ヶ月の請求書をもとに、WindyFloの無料トライアルで実際のコストを試算することを推奨します（詳細は公式サイトをご確認ください）。
Q4. MakeからWindyFloへの移行にどのくらいの期間がかかりますか?
移行期間はシナリオの複雑さと件数によって異なります。シンプルな構成（5件以下）で1〜2週間、中規模（5〜20件）で2〜4週間、大規模・複雑な構成（20件以上）で1〜3ヶ月が目安です。
最も時間がかかるのは、ERPシステムや独自システムとの連携部分の検証です。すべてを一度に移すのではなく、コストが膨らんでいる処理から段階的に進めると、リスクを抑えながら早期に効果を確認できます。HAMADA LABS Japanの日本語サポートチームが移行を支援します。
Q5. Makeのシナリオをそのままに、一部だけWindyFloへ移すことはできますか?
はい、部分移行は現実的かつ推奨される進め方です。
コストの大半を生んでいるAI処理や稼働回数の多い処理だけをWindyFloへ移し、シンプルな連携はMakeに残すという構成が可能です。重い処理をWindyFloへ移すとMake側のオペレーション消費が減るため、Makeを下位プランへ変更するだけでも支出が下がる場合があります。コストが膨らんでいる一点に絞って移すのが、機会費用を抑える最短経路です。
Q6. WindyFloは円建てで支払えますか?
WindyFloは日本市場向けに円建て対応の料金体系を用意しています（詳細は公式サイトをご確認ください）。
Makeのようなドル建てサービスでは、円安が進むと料金プランが同じでも日本円での支払額が増えます。WindyFloの円建て対応は、為替という自社でコントロールできない変数を予算から切り離せる点で、月初の予算計画を立てやすくします。
Q7. WindyFloのデータセキュリティは安全ですか?
WindyFloはエンタープライズ水準のセキュリティを備えています。RBAC（役割ベースアクセス制御）、監査ログ機能を標準搭載し、オンプレミス対応オプションも提供しています（WindyFlo公式 2026年）。
オンプレミス構成では、社内データをクラウドへ送信せずにAIエージェントを稼働させることが可能です。製造業・流通業など、データ管理に厳しい要件がある日本企業からの評価が高い点の一つです。
私たちが取引先に勧めているのは、Makeを全面的に捨てることではなく、請求書の中で「コストの天井が見えない処理」を一つだけ選んで、WindyFloへ移してみることです。投資の優先順位は明確です。最もコストが膨らんでいる一点から始めれば、削減効果と予測可能性の両方を、最小のリスクで確かめられます。次のステップは、自社のMake請求書を3ヶ月分そろえること——費用の試算はそこから始まります。
※ 本記事はAIを活用して作成し、専門家が監修しています。
