まず結論から言うと、Chrome拡張を使っていない会社は何もしなくてよい。使っている会社だけ、今週中に確認と切り替えが必要になる。
Make.comのChrome拡張、何が8月31日に停止するか
結論: Make.comは2026年8月31日にChrome拡張の提供を終了する。拡張を使ってブラウザ画面のデータを自動化に取り込んでいたフローは、以降動かなくなる可能性が高い（Make.com公式アナウンス、2026-08確認）。
Make.com（旧Integromat／ノーコードで業務を自動化するツール）は、ブラウザ上の操作やページのデータを拾って自動化フローに渡すためのChrome拡張を提供してきた。この拡張が2026年8月31日で役目を終える（Make.com公式サイト、2026-08確認）。
ここで区別しておきたい。Make.com本体のサービスは止まらない。停止するのは「Chrome拡張を使う機能だけ」だ。Make.comにログインして組んでいる自動化そのものは、Chrome拡張に依存していなければ影響を受けない。
止まるのは、たとえば次のようなケースだ。ブラウザで開いた受注管理画面の情報を拡張でつかまえてMake.comに送っていた場合や、拡張のボタンを押して手動でフローを起動していた場合である。これらは9月1日以降、代わりの方法に置き換える必要がある。
過去にAskiveで扱った「受注メールのたびに走る転記作業をMakeに任せる手順」でも触れたが、Make.comの自動化は「トリガー（きっかけ）→条件→アクション（実行）」の3段構えで動く。今回止まるのは、この最初の「きっかけ」をChrome拡張が担っていたフローに限られる。
自社が影響を受けるか、5分で確認する方法
結論: Make.comにログインし、稼働中フローの起点（トリガー）にChrome拡張が使われていないかを確認する。使われていなければ影響ゼロ、使われていれば今週中の切り替えが必要（編集部による整理、2026-08確認）。
確認は難しくない。Make.comの管理画面で、動いている自動化（シナリオ）を一つずつ開き、いちばん左のブロック（起点）を見る。ここに「Chrome拡張」「ブラウザ」といった名前のブロックがあれば、それが今回の対象だ。
影響範囲を切り分けるための3つの確認ポイントを挙げる。この3点だけ見れば判断できる。
- 起点のブロックにChrome拡張が使われているか（使われていれば要対応）
- そのフローが受注・在庫・問い合わせなど、止まると業務が滞る処理か
- 拡張のボタンを手で押して起動する運用になっていないか
50名規模の製造業で、マーケ担当が1名という体制を想定してみる。この規模だと、動いているフローはせいぜい3〜10本程度が多い。全部を開いて確認しても30分あれば終わる。逆に言えば、この30分を今週かけないと、9月1日の朝に「なぜか受注データが入ってこない」という事態になりかねない。
確認の結果、Chrome拡張を使っていなければ、この記事の続きは読まなくてよい。何も起きない。
Chrome拡張の代わりに使える3つの切り替え先
結論: 拡張の役割は「メール受信」「フォーム送信」「公式連携ブロック」のいずれかに置き換えられる場合が多い。多くの受注連携はGmail連携やフォーム連携で代替可能（Make.com公式ドキュメント、2026-08確認）。
Chrome拡張でブラウザ画面のデータを拾っていた処理は、多くの場合、もっと安定した方法に置き換えられる。データの元をたどれば、メールやフォーム、あるいは各サービスの公式連携で取れることが多いからだ。
代表的な置き換え先は次の通りだ。
- メール連携：受注通知メールをきっかけにする方法。Gmailやメールボックスの新着をMake.comが直接監視するため、ブラウザを開いていなくても動く
- フォーム連携：問い合わせフォームや注文フォームの送信をきっかけにする方法
- 公式連携ブロック：ShopifyやWooCommerceなど、そのサービス専用の連携ブロックを使う方法。拡張よりも安定して動く
たとえば、あるECショップでは受注管理・在庫更新・仕入先への発注メールをすべて手作業でこなしていた。これをMake.comで自動化した際、起点にしたのはShopifyの新規注文という公式連携だった（業界調査、2026-08確認）。ブラウザ画面を拾う必要はなく、注文が入った瞬間にGoogleスプレッドシートの在庫が更新され、閾値を下回ると仕入先へ自動でメールが飛ぶ。
つまり、Chrome拡張でわざわざブラウザ画面を経由していたのなら、それをやめて公式連携に切り替えることで、むしろ安定性が上がる。今回の廃止は、遠回りしていた配線を最短経路に直す機会でもある。
実装ガイド、今週中に終わらせる切り替え手順
結論: 「対象フローの洗い出し→代替方法の決定→テスト稼働」の順で進める。1本あたり半日〜1日、対象が3本以内なら今週中に完了できる（編集部による整理、2026-08確認）。
進め方はシンプルだ。まず前述の確認で対象フローを洗い出す。次に、それぞれのデータの元がメールなのかフォームなのか公式連携なのかを見極め、代替ブロックに差し替える。最後に、本番の前に一度テスト起動して、データが正しく流れるかを見る。
この記事を読むべき人は、Make.comのChrome拡張を経由して受注や在庫の連携を組んでいる中小企業の担当者だ。読まなくていい人は、Make.comを使っていない、あるいは拡張を一度も入れていない担当者である。
差し替えの際は、いきなり既存フローを消さないことが肝心だ。まず新しい方法のフローを別に作り、テストで丸1日流してみて、拾い漏れがないかを確認する。問題がなければ古いフローを止める。この「並行稼働で1日様子を見る」ステップを飛ばすと、切り替え直後の取りこぼしに気づけない。
撤退の判断基準も決めておきたい。差し替えを試して半日たっても代替方法でデータが取れない場合は、無理に自力で完結させず、Make.comの公式ドキュメントで対象サービスの連携ブロックを確認するか、外部の詳しい人に相談する切り替えラインを引いておく。9月1日が近いため、行き詰まったまま時間を溶かすのが最も避けたい失敗だ。
もし対象フローが受注のように「止まると即日困る」業務なら、切り替えが間に合わない場合の一時しのぎとして、当面は手作業に戻す準備もしておく。数日間だけ手で転記すると割り切れば、慌てて不完全なフローを本番投入するより安全だ。
よくある質問
Q. Chrome拡張を使っていないか、どうやって見分ければいいですか。 A. Make.comにログインし、動いている自動化を一つずつ開いて、いちばん左の起点ブロックを確認する。「Chrome拡張」「ブラウザ」という名前があれば対象だ。名前がなければ影響を受けない。3〜10本程度なら30分で確認できる。この確認を今週中に済ませることが最優先になる。
Q. Make.com本体の契約や、他の自動化も止まりますか。 A. 止まらない。今回廃止されるのはChrome拡張を使う機能だけで、Make.com本体のサービスと、拡張に依存していない自動化はそのまま動く（Make.com公式サイト、2026-08確認）。メール連携や公式連携ブロックで組んだフローは影響を受けない。確認すべきは起点にChrome拡張を使っているフローだけだ。
Q. 切り替えにはいくらかかりますか。 A. Make.com本体を使い続ける限り、Chrome拡張から代替方法への切り替えに追加の月額費用は基本的に発生しない。かかるのは作業時間で、1本あたり半日〜1日が目安だ。Make.comの料金は無料プランのほか有料プランが月$9（約1,350円）からある（Make.com公式料金ページ、2026-08確認）。プラン自体を変える必要は通常ない。
Q. 9月1日を過ぎてから対応しても間に合いますか。 A. 間に合うが、受注連携が止まった状態が続くリスクを負う。拡張が停止すればデータが自動で入ってこなくなるため、その間は手作業での転記が必要になる。業務が止まる前に、8月末までに確認と並行稼働のテストを終えておくのが安全だ。
この記事の持ち帰り
今日Make.comにログインし、動いているフローの起点にChrome拡張が使われていないかを30分で確認する。使っていれば今週中にメール連携または公式連携へ差し替え、1日並行稼働でテストしてから旧フローを止める。使っていなければ何もしなくてよい。
本記事はAI編集を経たのち、編集長が事実確認と品質チェックを実施しています。
本記事はAskiveのAIネイティブ編集部が執筆し、編集長 四月鶉（Yotsuki Uzra）が監修しています。内容は公開時点で確認できた情報に基づきます。