Makeの初回Scenarioを作る

Google Sheetsに行を追加したらSlackへ通知する。最初はこの2モジュールだけに絞るのがおすすめです。Google Sheets側で行が取得されたか、Slack側へ何件渡されたかを別々に確認すると、「動かない」を最短経路で切り分けられます。

まず完成形を把握する

Google Sheets：Watch New Rows → Slack：Send a Message。

Makeでは、処理の開始条件をTrigger、その後の通知などをActionとしてつなぎます。この例のWatch New Rowsは定期的にシートを確認するPolling Triggerです。行を入力した瞬間に必ず通知する仕組みではありません。通知までの速さは実行間隔にも左右されます。

まずは個人情報を含まない架空のテスト行と、関係者だけが確認できるSlackのテストチャンネルを用意します。会社の顧客名簿や実際の問い合わせを使う必要はありません。必要な権限がない場合は、接続用アカウントを勝手に共用せず管理者へ確認してください。

1. テスト用シートとチャンネルを用意する

例として列見出しを「案件名」「担当」「メモ」とし、2〜3行の架空データを入れたGoogle Sheetsを用意します。1行目をヘッダーにする場合、どこが見出し行かを決めておきます。

Slack側にはテスト送信用チャンネルを用意し、使用する接続アカウントが投稿できるか確認します。送信先は本番チャンネルではなくテスト用から始めると、開始位置の選択ミスで過去の行が複数送られても影響を限定できます。

2. Scenarioを作り、Google Sheetsの接続と監視対象を設定する

Makeで新規Scenarioを作り、最初のモジュールとしてGoogle Sheets → Watch New Rowsを選びます。Googleアカウントへの接続はCreate a connection → Sign in with Googleから認可します。許可画面でアクセス対象を確認してください。

その後、公式手順に沿ってDrive、Spreadsheet ID、Sheet Nameを選びます。ヘッダーがある場合はTable contains headers = Yesとし、実際の見出し範囲を指定します。初回はLimitを小さく設定して大量処理を避けます。Makeの公式チュートリアルでは例として20に設定していますが、テストデータが少数なら、目的に合わせて上限を調整してください。

重要：モジュール設定を保存することと、Scenario全体を保存することは別です。Make公式はモジュールのSaveに加えてScenario Builderの保存も案内しています。

公式：Create a connection / Set up the trigger

3. Choose where to startで「既存行」をどう扱うか決める

Watch New RowsではChoose where to startが初回に処理する行へ影響します。Makeの公式チュートリアルはAllを選び、既にある行を（設定したLimitの範囲で）処理してから、新規行を監視する例です。

Allを本番の大きなシートへ無意識に適用しないでください。 既存行の通知も必要なら有効な選択ですが、「これから追加される行だけを通知したい」運用では、開始位置の選択肢と対象範囲を確認する必要があります。選択肢の名称や表示は画面によって変わり得るため、実行前に対象行を読み直します。

テストで既存行を使いたい場合、All → 少数の架空行 → 出力確認の順に試すと、何が処理されたのか追いやすくなります。設定後は右クリックから再度Choose where to startを開けると公式に案内されています。

公式：Set up the trigger

4. 最初はGoogle Sheetsモジュールだけを動かす

Google Sheetsモジュールを右クリックし、Run this moduleを選びます。実行後、モジュールの上に現れる出力バブルを開き、案件名・担当・メモの値が入っているか確認します。

ここで何も出なければ、Slackの設定を直しても解決しません。対象Spreadsheet/Sheet、Google接続、ヘッダー位置、開始位置、Limit、実際のデータ行を先に点検します。

出力が正しければ、初めてSlackを接続します。Make公式はこの単体モジュールテストでもcreditを消費すると説明しています。

公式：Test the module

5. SlackへMappingしてRun onceで一連の流れを確かめる

Google Sheetsの後にSlack → Send a Messageを追加し、接続先・投稿可能なテストチャンネルを選びます。メッセージ本文のText欄で、Google Sheetsの出力列を選んでMappingします。

編集用メッセージ例：

新しい案件：〔案件名〕／担当：〔担当〕／メモ：〔メモ〕

角括弧の項目は固定文字列として打ち込まず、MakeのMappingパネルから該当する出力フィールドを指定します。氏名や電話番号など不要な項目をSlackへ流さないことも重要です。

保存後、Scenario BuilderでRun onceを選択します。Google Sheets側の出力バブルで何行処理されたか、Slack側のInputでどの値が渡ったか、Slack側のOutputでどう送信されたかを確認し、実際のチャンネルの通知と照合してください。

Google Sheetsの出力が正しいのにSlack投稿だけ失敗する場合は、チャンネル、Slack接続・権限、Text欄のMappingとSlack側のエラーに原因を絞れます。

公式：Map data / Test your scenario

6. テストが通ったらScheduleを設定し、Scenarioを有効にする

手動のRun onceが成功しても、定期実行が有効になったとは限りません。公式の例ではScenario BuilderのSchedule設定（例：Every 15 minutes）を選び、Save後にActivate scenarioして運用を開始します。

Watch New RowsはPolling Triggerなので、通知の速さはScheduleの設定に依存します。数分単位の速報が必要なのか、1時間程度の遅延を許容できるのかを先に決めます。

テストだけなら、確認後にScenarioを非アクティブにする、またはスケジュールを見直すことをMake公式が推奨しています。

公式：Schedule your scenario

動かない場合：どのモジュールまで成功したかで分ける

この表は公式機能に基づく確認順序の提案です。現象だけで原因を断定せず、Sheetsの出力→Slackの入力→Slackの出力→送信先の順に見てください。

Creditsを無駄にしない考え方

このシンプルなScenarioでも、「実行回数 × モジュール2個」とは限りません。Make公式チュートリアルでは、Watch New Rowsが3つのbundleを返した例で、Triggerは1 credit、3件のbundleを処理したSlack Actionは3 creditsを消費します。つまり1回の実行で4 creditsとなる例です。

Pollingの実行回数も無視はできません。公式Scheduleページは、1時間ごとのPollingならTrigger部分だけで24 credits/日という例を示しています。ただし、これはTrigger側だけの例示です。実際の総消費は新規行数、後段Action、その他のモジュールによって異なります。

したがって、対策は「とにかく実行頻度を下げる」ではありません。必要な通知速度、毎回のPolling、処理されるbundle数を分けて考え、実行結果のcredit表示を見て調整します。上限・料金・例外的なcreditルールはMakeのCredits解説で確認してください。

公式：Test your scenario / Schedule your scenario

まだ調べますか？

Scenarioが1本動いたら、いったん接続アカウントが無効になったときの担当者、送信先チャンネルの管理、実行失敗時の確認先、不要になったScenarioの停止方法を決めておきましょう。

• 次の自動化を考えたい：Makeでできる自動化例で、業務をTriggerとActionに分解する。
• 運用時の使用量を把握したい：Make CreditsとOperationsの違いで、bundle数や実行間隔の影響を確認する。
• Makeを使い続けるか判断したい：Makeの概要と選び方へ進み、利用環境と維持管理の負担を比較する。

最初の到達点は、作る→1件確認する→定期実行でも確認することです。

公式資料

• Make：接続作成
• Make：Google Sheetsトリガー設定
• Make：単一モジュールのテスト
• Make：Mapping
• Make：Run onceとbundle/credits
• Make：スケジュールとCredits