Makeが動かないとき、最初に整理する4つの確認先

PR｜料金の案内先には紹介リンクを含む場合があります。

通知が届かないときは、むやみに同じ処理をやり直す前に、止まった場所と送信済みの範囲を確かめましょう。このページは、Makeをすでに使っている担当者向けの確認順です。原因や復旧を確定する診断ではありません。接続先や顧客情報を第三者へ送ることなく、履歴と通知先を照合するために使います。

このページは、停止原因を自動で診断したり、再実行だけで直ると約束したりするものではありません。Slackへの送信が済み、表への記録だけが止まっていることも考えられます。最初から実行し直す前に、実行履歴と通知内容、元の行を照合してください。操作する権限がなければ、管理担当者に状況を伝えるところまでで構いません。不明点は残して構いません。

比較表

この4つは確認を整理する枠で、障害原因の頻度順ではありません。今回、実際の障害を再現していません。サービス障害や制限など、別の原因もあり得ます。

1. 実行の履歴で、進んだ場所を見る

Makeの処理回数の公式説明では、シナリオのHistoryから実行の詳細をたどれます。最後に確認できる実行を探し、新しい行を取得したのか、Slackへ送ったのか、表を書き換えたのかを分けます。各処理の入力と出力には業務情報が含まれる場合があるので、共有先を限定してください。

通知先だけでなく、実行の時刻と受付IDも照合します。見た範囲と見られていない範囲をメモし、原因の推測と事実を混ぜないようにします。問い合わせへの対応が急ぐ場合は、担当者が手作業で対応し、その記録を残す方法も選べます。

2. 途中で止まった処理の保存設定を見る

未完了の処理を残す機能は、初期状態では無効です。設定でStore incomplete executionsを有効にすると、途中で止まった実行を保存する仕組みです。保存の有無、対象の実行、再試行の範囲を確かめます。画面に項目がないことだけで、失敗した処理がなかったと決めないでください。

自動で再試行するものと、人が解決するものがあります。個々のエラーでどう扱われるかは公式資料と自分の設定に戻ります。今回、すべてのエラーの復旧条件を確認しているわけではありません。

3. 接続と権限を担当者と照合する

Googleの表にアクセスする接続と、Slackへ投稿する接続は分けて確かめます。アカウントや権限を変えた記録があるか、対象の表とチャンネルが今も利用できるかを管理者と照合します。認証情報やパスワードをチャットで集める必要はありません。

権限の具体的な範囲と、使っている組織での承認手順は【要確認】です。接続し直した後も、通知が止まっていた間の問い合わせが処理されたかは別に照合します。過去の行を送る範囲を決めずに実行しないようにします。

4. 表の空行、列名、更新する行を見る

新しい行を監視する処理には、空の行があると、それより後の行を処理しない制約があります。途中の空行や、監視する表の取り違えを確かめます。行の更新では行番号の指定が必要なので、通知した問い合わせと記録した行が同じかを照合します。

列名や列の位置の扱いは設定によって変わります。列を変更した場合は、どの項目を通知・記録する設定かをテスト用の表で確かめます。顧客の実データを使って何度も試す必要はありません。

条件を当てはめた例

Slackに受付ID「SAMPLE-001」の通知があり、表の通知済み欄が空という説明用の例を考えます。このとき空欄だから未送信だとは決められません。送信と更新は別の処理なので、更新だけが止まった可能性を履歴で調べます。これは原因の断定ではなく、二重通知を避けるための照合です。

条件と注意・次の一手

止める担当者、手作業へ戻す担当者、再実行する範囲を決めます。接続の許可や確認担当が決まらなければ、今回の構成の運転再開を急がないようにします。無料枠や追加費用を調べる場合も、まず対象の処理と件数を整理します。既存利用者に新規登録は勧めません。

出典・確認日

• Makeの処理回数（2026-09-25確認）
• Makeの未完了実行（2026-09-25確認）
• MakeのGoogle Sheets処理（2026-09-25確認）
• Makeの料金・利用条件（2026-09-25確認）

公式機能を基にした説明用の設計例です。実接続、消費量、削減時間、導入成果は未検証です。読者像と需要も未検証です。

運営者情報・広告方針・お問い合わせ

Makeが必要かどうかから整理する / Makeの無料枠と料金条件