「Make 乗り換え / Make 代替 / Make 複雑」——検索窓にこうした言葉を並べる現場の多くは、料金への不満と同時に、設定の入り組みそのものに息苦しさを感じています。乗り換えを考え始めた最初の引っかかりが、この複雑さであることは少なくありません。

以前、Makeで長く運用してきた自動化を別の基盤へ移したい、という相談を受けたことがあります。担当の方は当初、「エクスポートして取り込むだけで済むと思っていた」と話していました。ところが現行のシナリオを一つずつ開いてみると、話はそれほど単純ではありませんでした。

一つのシナリオの中に、十数個のモジュール、複数の分岐、失敗時のエラー処理、そしていくつものAPI認証が絡み合っていたのです。設計図の残っていない配管を引き直すのに近い作業で、丸ごと運ぶことはできません。移す先の基盤が変われば、同じ処理でも組み方そのものが変わります。

乗り換えで本当に効いてくるのは、月額料金の差よりも、この再構築にかかる時間と人手です。どこにどれだけの負担がかかるかが見えないまま切替を決めると、旧環境と新環境の二重運用がずるずると長引き、目的だったはずのコスト削減はかえって遠のきます。

だからこそ、負担を工程として書き出し、見える状態にしてから判断したいのです。負担が数字で見えていれば、切替の可否そのものを落ち着いて決められます。逆にそこが霧の中のままだと、料金への不満だけが先走り、移行が途中で空中分解します。

チェックリストにこだわるのは、移行を管理できる単位に割るためです。全体を一つの大きな作業として眺めると、着手をためらうか、逆に見切り発車で走り出すかの両極に振れます。工程と完了条件に分けておけば、今日どこまで進めるかを判断でき、途中で担当が代わっても引き継げます。

なぜMakeからの乗り換えは「移行」ではなく「再構築」になるのか

Makeのシナリオは、モジュールという部品をツール固有の作法で連結した構造だからです。データを書き出して別の場所へ読み込むだけの移行にはならず、同じ処理でも接続や分岐を組み直す再構築になります。

Makeでは、一つひとつの処理をモジュールとして置き、それを線でつないでシナリオを作ります。分岐にはルーター、失敗時の扱いにはエラーハンドラー、実行回数の計上にはオペレーションという単位を使います。これらはMake公式ドキュメントに定義された、Make固有の考え方です。

問題は、この固有の考え方が他の基盤にそのまま存在するとは限らない点にあります。あるツールではルーターに当たる分岐が別の書き方になり、エラー処理の粒度も違います。オペレーション課金という数え方そのものがない基盤も珍しくありません。数え方が違えば、料金の見通し方も設計の勘所も変わってきます。

つまり移す対象は「データ」ではなく「処理の設計」です。設計は、言語が違えば書き直しになります。日本語の文章を英語へ移すとき単語を置き換えるだけでは通じないのと同じで、構造ごと組み直す前提に立ちます。

この前提を最初に共有できているかどうかで、プロジェクトの進み方は大きく変わります。「取り込むだけ」という期待のまま着手すると、想定外の作業が次々に現れ、見積もりが後から崩れていきます。逆に「再構築である」と最初に握れていれば、洗い出しから順に進める計画が立てられます。

技術者の立場で言えば、ここで測るべきは行数でも画面数でもなく、「処理と処理のつながりの本数」です。つながりが多いほど、一つの変更が他へ波及します。この波及の広さこそが再構築の重さであり、最初に把握しておきたい指標になります。

乗り換え前に洗い出すべき依存関係は何か

先に洗い出すべきは、現行シナリオの本数、外部接続先、分岐とエラー処理、認証情報、データの保管場所という5つです。この5点を棚卸しすると、再構築がどれくらいの規模になるかが数字で見えてきます。

棚卸しを省いて乗り換えを始めると、「思ったより接続先が多かった」「使っていないと思ったシナリオが実は基幹処理につながっていた」といった発見が、移行の後半で噴き出します。後半での発見は、それまでの作業のやり直しに直結します。だから棚卸しは、面倒でも最初に済ませておきたい工程です。

依存関係は、次の表のように整理すると抜けが減ります。

見落とされやすいのが、最後の「データ保管場所」です。処理の途中で外部サービスに一時保存されるデータや、ログとして残る情報がどこにあるかは、権限を持つ担当者でないと把握しづらい領域になります。ここは監査ログと突き合わせて確認しておくと、乗り換え後のデータ管理で足をすくわれません。

棚卸しの精度を上げるには、画面を目で追うだけでなく、機械が読める形で書き出すのが近道です。Makeの管理画面からシナリオ一覧や実行履歴を取り出し、接続先とオペレーション数を表に落とすと、稼働の実態が数字で残ります。この一覧は、後の並行稼働で新旧を突き合わせるときの土台にもなります。

外部接続先の一覧は、ただ数えるだけでなく、それぞれが「業務のどこに効いているか」まで紐づけておくと役に立ちます。接続が切れたときに止まる業務が見えていれば、移行の優先順位を決める材料になります。紐づけがないと、切替の順番を勘で決めることになり、止めてはいけない処理を先に触ってしまう危険が残ります。

認証情報の棚卸しには、もう一つ狙いがあります。誰がどの権限で外部サービスにつないでいるかを一覧にすると、属人化していた接続が浮かび上がるのです。特定の担当者の個人アカウントで動いていた連携は、その人が離れた瞬間に止まります。乗り換えは、この属人化をほどく機会にもなります。

再構築の負担はどう数値化するか

再構築の負担は、接続の本数と難所の係数を掛け合わせて概算します。感覚で「重そう」と語るのではなく、数字に置き換えておくと、切替の可否も日程も落ち着いて議論できるからです。

技術者として最初に数えたいのは、シナリオの本数ではなく、処理と処理をつなぐ接続の本数です。同じ十本のシナリオでも、内部で密に絡み合っているものと、独立して動いているものとでは、作り直しの重さがまるで違います。接続が密なほど、一つの変更が周囲へ波及します。

次に、接続一本ごとに難所の係数を添えます。単純なデータ転記なら軽く、分岐やエラー処理、認証の再発行を含む接続なら重い、という具合です。係数は精密である必要はなく、軽・中・重の三段階で十分に見通しがよくなります。

概算の重み付けは、次のように置くと関係者で共有しやすくなります。

この重み付けの狙いは、精密な見積もりではなく、着手前の合意です。重い接続がどこに何本あるかが見えていれば、人手をどこに厚く割くかを先に決められます。数字は完璧でなくてよく、関係者が同じ絵を見られることのほうが効きます。

概算が手元にあると、切替の日程も現実的に引けます。重い接続を含む処理は、テストと並行稼働の時間を長めに見積もる、といった判断が数字を根拠にできるからです。逆に概算を飛ばすと、日程は希望的観測で決まり、後半で必ず押します。

再構築でつまずきやすいのはどこか

再構築で時間を奪うのは、モジュール互換、エラー処理、認証の再設定、データ形式、実行タイミングの5点です。この5つが作業量の大半を占めるため、ここを先に見積もると全体の負担がつかめます。

一つ目のモジュール互換は、Makeで使っていた機能が移行先に同じ形で存在するかという問題です。同名の連携があっても、対応するアクションの範囲が違えば、足りない部分を別の方法で補うことになります。ここで「近い機能はあるが完全一致ではない」ものを洗い出しておくと、後の手戻りが減ります。

二つ目のエラー処理は、地味ですが再現が難しい部分です。Makeではエラーハンドラーで再試行や通知を細かく設定できますが、移行先で同じ粒度を再現できるとは限りません。ここを省くと、平常時は動いても異常時に静かに止まる自動化になり、気づいたときには処理が何日も抜けていた、という事態を招きます。

三つ目の認証の再設定は、セキュリティに直結します。トークンやAPIキーは移すのではなく、移行先で新しく発行し直すのが原則です。発行元の管理画面ごとに手順が異なり、付与する権限の範囲も見直すことになります。この機会に、広すぎる権限で発行されていた鍵を絞り込んでおくと、外部流出防止の面でも安全側に寄せられます。

四つ目のデータ形式は、モジュール間で受け渡されるデータ構造の違いです。日付や金額の書式、文字コード、入れ子になった項目の扱いが変わると、後続の処理が意図せず失敗します。この不一致は実行して初めて表面化することが多く、テストデータをどれだけ現実に近づけられるかがものを言います。

五つ目の実行タイミングは、定期実行か、イベントを受けて動くかという起動条件の違いです。Makeのスケジュールやウェブフックの受け方を、移行先の作法へ置き換えます。ここがずれると、二重に動いてデータが重複したり、動くべきときに動かず処理が抜けたりします。

この5点は互いに独立していません。認証を再設定すればデータの取得先が変わり、データ形式の違いがエラー処理の設計に跳ね返ります。一つを直すと別の一つが動く連鎖を前提に、触る順序を決めてから進めるのが現実的です。順序を決めずに一度に手をつけると、どの変更が不具合の原因かを切り分けられなくなります。

移行チェックリストはどう組み立てるか

移行チェックリストは、棚卸し、優先度付け、並行稼働、切替、旧環境の停止という5つの工程に分け、それぞれに完了条件を決めると抜け漏れが防げます。工程を分けることで、「どこまで終わったか」が誰の目にも見えるようになります。

チェックリストは、作業を並べるためではなく、各工程を「次へ進んでよいか」の判断点にするために作ります。完了条件が曖昧なまま次へ進むと、後戻りの温床になるのです。条件がはっきりしていれば、担当者が代わっても判断がぶれません。

工程ごとの完了条件は、次のように置くと運用しやすくなります。

最も飛ばされやすいのが、並行稼働の工程です。早く切り替えたい気持ちから、新環境が動いた時点で本番を移してしまうと、旧環境でしか拾えていなかった例外に後から気づきます。新旧を一定期間、同じ入力で走らせて出力を突き合わせておくと、この取りこぼしを事前に見つけられます。

優先度付けでは、業務影響の小さいシナリオから移すのが定石です。いきなり受発注や請求のような止められない処理から手をつけると、不具合がそのまま業務停止につながります。小さく始めて手順を確かめ、勘所をつかんでから重い処理に進むほうが、遠回りに見えて結局は速く終わります。

旧環境の停止まで工程に入れる理由は、二重運用の期間を意識して区切るためです。停止の条件と期日を決めていないと、「念のため」で旧環境を残し続け、削減したかった料金が両方に発生し続けます。認証の失効とデータ退避を停止条件に含めておけば、外部流出防止の観点でも締めくくりがつきます。

チェックリストには、切り戻しの条件も一行だけ足しておきます。新環境で不具合が出たとき、どの時点まで旧環境へ戻すかを決めていないと、判断が個人の勘に委ねられます。並行稼働を残している間は旧環境がそのまま退避先になるので、戻す手順を先に書いておけば、切替当日の判断が軽くなります。

工程を版として記録しておくのも、地味に効きます。どの接続をいつ移し、完了条件をどう満たしたかを一覧に残すと、途中で担当が代わっても同じ判断を再現できます。監査ログと突き合わせれば、移行の過程そのものが後から検証できる記録になります。

完了条件は、できるだけ「動いたかどうか」ではなく「同じ結果が出たかどうか」で書くのが要点です。動くだけなら見た目で判断できますが、正しく動くかは出力を突き合わせないとわかりません。この一手間が、切替後の静かな不具合を防ぎます。

乗り換え先は何で選ぶか

移行先は、開発者が管理し続ける前提か、業務チーム自身が運用する前提かで分かれます。同じ「Make代替」でも、誰が運用の主体になるかで最適な選び方が変わるからです。

自動化の基盤には、大きく二つの方向があります。一つは、柔軟性と拡張性を重んじ、開発者やエンジニアが構築と保守を担う方向です。もう一つは、業務チームが自分たちで運用でき、専門家に依存せずに回せる方向です。どちらが優れているという話ではなく、用途が違います。

開発者が主体なら、コードやオープンソースに近い基盤が候補になります。細かい制御が効き、独自の要件にも対応しやすい反面、保守の担い手を社内に確保し続ける前提になります。この観点は、[開発者向けのn8nと業務チーム向けの完全管理型をどう線引きするか](/ja/blog/n8n-vs-windyflo-gyomu-team/)という論点と地続きです。

業務チームが主体なら、日本語で完結し、運用の手離れがよい完全管理型が向きます。ここで問いになるのは、「作れること」と「動かし続けられること」の違いです。ツールでアプリを作れても、それを日々の業務として回し続けるには別の力量が問われます。この境界は、[AIアプリを作るDifyと業務を動かすWindyFloの違い](/ja/blog/dify-vs-windyflo-jikko/)でも扱っています。

WindyFloが完全管理型の側に立つのは、答えを返すことと、業務を実際に動かすことを分けて考えているからです。ChatGPTは答えます。WindyFloは働きます。乗り換え先を選ぶときも、「質問にうまく答える賢さ」ではなく、「決めた業務を任せて止まらないか」で見ると、判断軸がぶれません。

料金の見通しやすさも、この判断軸の一部です。従量課金が想定を超えて膨らむ構造そのものを避けたいなら、料金の数え方が事前に予測できるかを確かめておくと安心できます。この点は、[Zapierの料金が予測できない理由と円建てで見通せる代替](/ja/blog/zapier-ryokin-yosoku-daitai/)でも整理しています。移行先選びは、機能表の丸の数ではなく、運用の主体と料金の予測性という二つの軸で見ると迷いにくくなります。

乗り換えを小さく始めるにはどうするか

一度に全部を移そうとせず、影響の小さい一つの業務から並行稼働で試すのが、最も負担の少ない始め方です。小さく試すことで、再構築のコストと運用の感触を、本番を止めずに測れます。

最初に選ぶ業務は、失敗しても被害が限定的で、それでいて手順に一通りの要素が含まれるものが向いています。社内への定期通知や、フォーム受付内容の転記のような、外部接続とデータ整形の両方を含む処理が手ごろです。ここで一連の工程を体験しておくと、本命の重い業務を移すときの見積もりが具体的になります。

並行稼働の期間は、新旧が同じ入力に対して同じ出力を返すかを確かめる時間です。ずれた原因を一つずつ潰していくと、先に挙げたつまずきポイントのどれに自社が弱いかが、現場の環境に即してわかってきます。この「自社での実測」は、一般論の比較表よりもはるかに確かな判断材料になります。

小さく始める利点は、撤退のしやすさにもあります。試した結果、移行先が合わないとわかっても、本番はまだMake側にあるので、失うものはほとんどありません。切替は、実測で確信が持ててから決めれば間に合います。

手を動かして確かめたいなら、WindyFloの無料トライアルで一つの業務を並行稼働させ、再構築の負担を自社の数字で測るところから始められます。数字で見えた負担は、社内の合意形成でもそのまま説明材料になります。

よくある質問

出典

• Make公式ヘルプセンター（Scenario・Module・Router・Error handling・Operations の定義）— https://www.make.com/en/help
• Make公式サイト（製品概要・オペレーション課金の考え方）— https://www.make.com
• WindyFlo公式サイト（無料トライアル・製品ポジション）— https://windyflo.com