- 最初に要点:本記事でできること(2026年9月時点)
- Makeの基本:シナリオとモジュール、クレジットの考え方
- 向いている業務・向かない前提
- ユースケース例:日次ダイジェストで朝会を短縮
- シート設計のベストプラクティス(読み取り負荷と要約品質の両立)
- Slackメッセージ設計の実務ポイント
- 実装手順:Googleシート→AI要約→Slack(ノーコード)
- 料金と主な制限(確認日:2026年9月)
- コスト最適化:クレジット/トークン/レート制限を味方にする
- 運用設計:ロールアウト、監視、変更管理
- アーキテクチャの代替案:スケジュール一本化 vs. 逐次取込+日次集約
- 代替案との比較(Zapier/n8n)
- よくある落とし穴と対処
- 日本語対応の現状
- 選定基準:スケール/頻度/データ量/運用体制/ガバナンス
- テンプレートと追加リソース
- 運用の具体ワークフロー例(部門別)
- Slack投稿の品質を上げる小ワザ
- まとめ:日次AIレポート運用のチェックリスト
- よくある質問(FAQ)
- 参考情報
最初に要点:本記事でできること(2026年9月時点)
GoogleスプレッドシートのKPIや実績を、AIの短い要約を添えて、毎朝Slackに自動投稿する仕組みをMake(Make.com)で構築します。必要なのは「スケジュール実行」「Sheetsからの読み取りと整形」「AI要約(Make AI Toolkit)」「Slack投稿」の4工程だけ。UIは英語ですが、ノーコードで再現できます。

- 判断の目安
- 要件が「日次1通+要約3〜5行」→ Makeの標準機能で早期運用可。
- 高頻度(毎分)や大量イベント→ クレジット見積りを精緻化してMake上位プラン、もしくはn8nも試算。
- 自社ホスト必須→ n8n(セルフホスト)を優先。
- 対応アプリの数を最優先→ Zapier(7,000+対応、apps一覧)も検討。
参考リンク:Google Sheets統合/Slack統合/Make AI Toolkit
Makeの基本:シナリオとモジュール、クレジットの考え方
Makeは可視化キャンバス上でアプリ間の自動化(シナリオ)を組むノーコードの統合基盤です。モジュールは「トリガー」「サーチ」「アクション」「ユニバーサル」に大別され、監視・取得・作成/更新・汎用API呼び出しを担当します(Scenario UI/Types of modules)。Google SheetsとSlackは公式アプリがあり、読み書きや行監視、チャンネル/メッセージ/ファイル操作が可能です(Sheets統合/Slack統合)。
課金はクレジット制(Operations等から移行した新単位)。トリガーはデータ有無に関わらず実行ごとに消費し、先頭モジュールが多数の行(バンドル)を返すと後段の実行回数が乗算的に増えます。スケジューラーは「Every day」等を設定でき、最小間隔はプランに依存(Freeは15分間隔)(Schedule a scenario/How features use credits/Pricing)。
向いている業務・向かない前提
- 向く:SlackとGoogleスプレッドシートを日常的に使い、営業/CS/マーケ/バックオフィスで日次の定型KPI報告を省力化したいチーム。ノーコードで短期構築し、拡張も見据えたい。
- 向かない:日本語UI必須(MakeのUIは英語/チェコ語、公式)。完全オンプレのみ許容(MakeはクラウドSaaS)。秒〜分単位の超大量イベントをポーリングで捌く(クレジット消費が膨らむ)。社内ポリシーで外部SaaS連携が不可。

ユースケース例:日次ダイジェストで朝会を短縮
- 売上/受注:当日/前日/週累計、平均単価、主要SKUの伸びを要約。
- CS:新規チケット、一次応答SLA、解決中央値、CSATの要点を3行で。
- マーケ:UTM別セッション/コンバージョン、主要LPのCVR動向を簡潔に。
- プロジェクト:完了数、遅延/ブロッカー、注意喚起を箇条書き。
近い雛形は公式テンプレートが参考になります(日次サマリー→Slack/Sheets監視+AI応答)。
シート設計のベストプラクティス(読み取り負荷と要約品質の両立)
- 列設計の固定化:ヘッダー1行目に「date, metric, value, delta_abs, delta_pct, note」などの列名を固定。Make側のマッピングが壊れにくく、AIに渡す前の整形も安定。
- 日付の一意性:date列はYYYY-MM-DDで統一。スプレッドシートの表示書式と実体値の不一致(文字列/シリアル)を避けるため、関数TEXTで文字列化し、Makeは文字列として扱う。
- 「日次集計」専用タブ:RAWデータからQUERY/PIVOT/ARRAYFORMULAで「当日または前日分だけ」を整形したタブを用意。Makeはこのタブの固定範囲(例:A1:F100)だけを読む。
- 命名規則:タブ名「daily_report_YYYY」ではなく「daily_report」など不変名に。A1ノーテーションも固定(例:A1:F)」。
- 欠損/外れ値処理:IFERROR/IFNAで空文字に置換。Makeでは空行スキップ条件を併用。
- 差分列の先計算:delta_pct(前日比%)はシートで先に算出し、Makeでは書式のみ調整。API呼び出しとAI入力トークンを節約。
- 検証ルール:value列は数値のみ、delta_pctは-1.0〜1.0などのデータ検証で入力ミスを抑止。
Slackメッセージ設計の実務ポイント
- ヘッダー:「[日次KPI] 2026-09-11(金)」のように日付を明示。
- KPIリスト:数値の書式(小数/%/円)を統一、順序は固定。
- AI要約:3〜5行で「増減ポイント→原因仮説→示唆」。
- リンク:対象シート範囲URLとダッシュボードURLを末尾に。
- Blocks利用時:textフィールドのフォールバックを適切に設定(chat.postMessage)。
Block Kitの構成例(概念):
- section(ヘッダー):「[日次KPI] {日付}」
- divider
- section(箇条書きKPI):「・売上:¥X(前日比+Y%)」など3〜6行
- section(AI要約):「増減ポイント」「示唆」を1ブロックにまとめる
- context:データ出所(シートURL)、生成時刻、責任者
通知の強度は@here/@channelの乱用を避け、週次/重要指標のみで使うなどルール化するとノイズを抑制できます。

実装手順:Googleシート→AI要約→Slack(ノーコード)
1) スケジューラーを設定(Every day)
- 新規シナリオでスケジュールを「Every day」、業務開始前時刻(例:08:30 JST)に設定(公式ヘルプ)。
- 注意:スケジュール実行はデータが無くても1回分のクレジットを消費(Credits)。
- 深夜バッチがある場合は+10〜30分の余白を取る。
- タイムゾーンはシナリオレベルでJSTに合わせる。Sheets側で日跨ぎ計算をしている場合はJST/UTCの不一致に注意。
2) Sheetsから取得→整形→集約
- Google Sheetsモジュール(例:Get a range values)でスプレッドシートと範囲(A1:F100など)を指定。必要なら「Major dimension: ROWS」。
- 前処理は可能な限りシート側で実施し、Makeは「集計済み範囲」を読むだけに。これでAPIコールとバンドル数を削減(Sheets API limits)。
- 改行安全なテンプレ化:行テンプレ(例:「{date}|{metric}|{value}|{delta_pct}」)を決め、Text aggregatorで改行結合。インデックスエラーや空行はフィルタで除外。
- 2026年4月にSheetsのパフォーマンス/セル上限が改善(Google公式)。それでも取得範囲は必要最小限に切るのが基本。
- 整形の定番
- 丸め:小数第1位まで等を統一。
- %表記:0.123→12.3% のように文字列化してから集約。
- 欠損/空行はスキップ条件で除外しノイズ削減。
- 分岐の設計:対象行が0件のときは「データなし」メッセージに切り替えるルートを用意(クレジット浪費やAIへの空入力を防止)。
3) AI要約(Make AI Toolkit:Summarize text)
- Summarize textモジュールへ集約テキストを入力。例プロンプト:「昨日と比較して増減の大きい指標を3点。数字と%を示す。日本語で。」
- AIプロバイダはMake提供か外部接続を選択。2026年の更新で入力/出力トークンのレートが分離され、要約など“入力多め”の用途で効率が改善と案内(AI Provider token pricing)。
- 出力の一貫性を高めるコツ
- 形式指定:「箇条書き3点、各行頭は・、最大300文字」。
- 語調/言語:「敬体、日本語、スラング禁止」。
- 略語辞書:「CVR=コンバージョン率、AOV=平均注文額」等を明示。
- Few-shot(任意):理想的な1例を短く添えると安定する。
- 日本語の要約は問題なく可能(AI Toolkit)。
- フォールバック設計:AIが空/失敗時はシンプルな定型文(例:「本日は要約生成に失敗。KPIは下記の通り」)を返す分岐を用意。
4) Slackへ投稿(Blocksとフォールバック)
- Slack投稿モジュールでチャンネル、本文、必要ならBlocks(セクション/区切り/フィールド)を構成。
- Blocks利用時もtextフィールドの扱い(フォールバック等)に注意(chat.postMessage)。
- レート制限:Slackは厳密な数値を公開していません。超過時はHTTP 429とRetry-Afterヘッダーに従いバックオフを実装してください(実務上は“1チャンネルあたり毎秒1通前後”を目安にするケースが多い)(Rate Limits)。
- 承認フロー:MakeのSlackアプリはマーケットプレイス未掲載のため、ワークスペース設定により管理者承認が必要な場合があります(Make Slackアプリ)。
- 配信のバリエーション:同文を複数チャンネルへ配るのではなく、1通を全社向けに投稿し、詳細は部門チャンネルへリンク誘導するなどの集約配信でレートとノイズを抑制。

5) エラーハンドリング/監査
- 429(Slack)→ Retry-Afterに従って待機し再送。Sheetsクォータ→取得頻度と範囲を見直し(Slack/Sheets)。
- 実行ログで入出力と失敗点を追跡。先頭で返る行数が多いと後段の実行(Operations相当)が増幅しクレジット消費が跳ね上がる点に注意(Operationsの概念)。
- フォールバック:AI要約が失敗/空ならKPI本文のみ投稿する分岐を用意。
- 通知:失敗時は運用チャンネルまたは担当者DMに簡易の失敗要約を投げると一次対応が速い。
料金と主な制限(確認日:2026年9月)
以下はMakeの公開情報ベースです。プラン/仕様は変更され得るため、運用前に最新の料金ページ/ヘルプで必ず再確認してください。
| 項目 | ポイント | 出典 |
|---|---|---|
| 課金単位 | クレジット制。2025年以降、用語はOperations→Creditsへ移行(AIはトークン連動のダイナミック課金に移行) | Introducing credits |
| Freeプラン | 月1,000クレジット。最小実行間隔は15分 | Pricing/Schedule |
| 上位プランの間隔 | 毎分実行まで対応(プラン依存) | Pricing |
| Code App | JavaScript/Pythonは1秒あたり2クレジット消費。内蔵ツールで代替可能な整形はコードを避ける | Pricing |
| AIプロバイダのレート | 2026年の更新で入力/出力トークンのレートが分離し、要約など“入力多め”の用途の効率が改善と案内 | AI Provider token pricing |
| AI Toolkitの上限(Free) | FreeでもMakeのAIプロバイダを利用可。トークン上限は案内ベースで設定があり、変更の可能性があるため最新を要確認 | AI Toolkit |
| 追加クレジット | 2025年11月の見直しで、追加分は標準クレジットより約25%高コストに(案内ベース) | Adjustments |
| データ転送/保存枠 | 一定の使用枠が「10,000クレジットごと」に付与(例:データ転送/保存枠やWebhookキュー)。具体値はPricing内の使用枠セクションを参照(代表例・最新確認推奨) | Pricing(Included usage) |
| トリガー消費 | トリガーモジュールはデータ有無に関わらず1回でクレジット消費。高頻度ポーリングはコスト影響大 | How features use credits |
補足:Make AI ToolsのOpen Betaは、ベータ告知時点で寛容なトークン枠が案内されていますが、モデル/上限/価格は今後変更され得ます。導入時は最新の案内を必ず確認してください(Open Beta告知)。
コスト最適化:クレジット/トークン/レート制限を味方にする
- 一括要約:行ごとにAIへ投げず、Text aggregatorで1テキストにまとめる。入力トークンとクレジットの両方を削減。
- 最小頻度:日次で足りるなら無理に短い間隔にしない。チェックラン(新規なし)でも消費する点を意識。
- 前処理:Sheets側で日次集計シート/範囲を用意し、Makeはそこだけ読む。
- Slack投稿の集約:複数チャンネル向けでも1通にまとめて@mentionで誘導する案を検討。
- コード最小化:Code App(1秒=2クレジット)は最後の手段。数値/テキスト整形は内蔵ツールで。
- テスト計測:テストチャンネルで実行し、バンドル数→後段実行回数の増幅点を特定→ボトルネックを抑える。
運用設計:ロールアウト、監視、変更管理
- ロールアウト手順
- 検証環境:Slackに「#sandbox-report」などの検証用チャンネル、シートは複製(サンプルデータ入り)を用意。
- パイロット:1〜2週間は検証チャンネルのみへ配信し、要約の妥当性・KPI定義の齟齬を是正。
- 本番移行:本番チャンネルのルール(メンション方針、反応絵文字で確認など)を告知して開始。

- 監視
- 失敗通知:Slackに「#automation-alerts」を用意し、失敗時は日時・シナリオ名・エラーメッセージの要約を投稿。
- ヘルスチェック:毎週1回、実行回数とクレジット消費の推移を点検。バンドル増幅の兆候(対象範囲の拡大等)を早期発見。
- 変更管理
- 変更ログ:シナリオのバージョンとプロンプトの改定履歴を記録(要約品質の回帰を防止)。
- KPI定義管理:定義書に「算出式/分母分子/小数点/四捨五入/表示単位」を明記し、AIにも同梱。
アーキテクチャの代替案:スケジュール一本化 vs. 逐次取込+日次集約
- シンプル運用(本記事の基本形):毎朝スケジュールでシートの集計済み範囲を読み→AI→Slack。初期構築が速く、クレジット見積りもしやすい。
- 逐次取込+日次集約(Webhook活用):イベント駆動(受注/問い合わせ等)が多い場合は、逐次でWebhook受信→日次にまとめてSlack配信。スケジュールの「空振り実行(新規なし)」を減らせるため、クレジット効率がよいケースがある(ポーリング消費の注意)。
- 週次/月次ハイブリッド:日次は簡易KPIのみ、週次は詳報(AI要約+考察+主要トピック)に分離。AIトークンを平準化しつつ情報粒度を最適化。

代替案との比較(Zapier/n8n)
| 観点 | Make | Zapier | n8n |
|---|---|---|---|
| 料金モデル | クレジット制(実行/AI/データ転送等に連動) | タスク制(Freeは月100タスク、15分ポーリング、2ステップ:2026/8時点) | “実行(ワークフロー1回)”課金。Cloud Starter: 年払い20€で2,500実行、Pro: 年払い50€で10,000実行(公称) |
| 最小間隔(無料) | 15分 | 15分 | プラン/ホスティングに依存(セルフホスト可) |
| 対応アプリ数(公称) | 3,000+ pre‑built apps | 7,000+ apps(公式一覧) | 多数のノード+自作拡張可能 |
| AI機能 | AI Toolkit(要約/抽出/翻訳等)を標準アプリとして提供 | 各種LLM連携あり(詳細はZapier側ドキュメント参照) | 外部LLMや自作ノードで柔軟 |
| ホスティング | クラウドSaaS | クラウドSaaS | Cloud/セルフホスト両対応 |
| UI言語 | 英語/チェコ語 | 英語中心 | 英語中心 |
| ライセンス/権利 | 商用SaaS | 商用SaaS | Sustainable Use License(再販的SaaS化等に制約) |
参考:Zapier Freeの制限/n8n料金/SUL/Makeの連携規模。頻度・データ量・拡張性・ガバナンスで選びましょう。
よくある落とし穴と対処
- Slackレート制限:公式は厳密な数値を公開していません。429/Retry-Afterに従うバックオフを実装し、可能なら1通に集約(Slack Rate Limits)。
- Sheetsクォータ:RAW全件の読み出しを避け、日次サマリ範囲を事前に用意(公式)。
- チェックラン消費:スケジュール・トリガーは「新規なし」でも1回分消費。前段で返す行数(バンドル)を抑え、後段の実行増幅を回避(Credits/Operations)。
- Slackアプリ承認:ワークスペースのアプリ制限により管理者承認が必要になり得る(Make Slack)。
- Slack無料プランの履歴:無料ワークスペースはメッセージ可視期間に制限(公式)。日次レポートのアーカイブが見えなくなる場合は有料化や外部アーカイブを検討。
- タイムゾーン:シナリオのTZとSheets関数の基準TZ(JST/UTC)を合わせる。
- AI出力のばらつき:行テンプレ化・略語辞書・最大文字数指定で安定化。
- メッセージ肥大化:KPIは最大5〜8点に絞る。詳細はダッシュボードへ誘導。
日本語対応の現状
MakeのUIは2026年5月時点で英語/チェコ語のみ(公式)。一方でAI Toolkitの「要約/翻訳/言語判定」は日本語テキストを問題なく扱えます(AI Toolkit)。UI操作は英語、プロンプト/運用ドキュメントは日本語という運用が現実的です。
選定基準:スケール/頻度/データ量/運用体制/ガバナンス
- 頻度:日次〜数時間置きならMakeで十分。秒〜分単位で高頻度ならクレジット影響を精査。
- データ量:RAW全件ではなく「日次集計済み範囲」を読む設計に寄せる。
- 拡張性:将来的なチャンネル増、添付、分岐、承認フローへの拡張。
- 運用体制:英語UIの学習コスト、Slack/Googleの権限フロー整備。
- コスト:クレジット/月、AIトークンの振れ幅、追加クレジットの単価差。
- ガバナンス:SaaS可否、データ所在地、監査要件。セルフホスト要件が強いならn8n。
テンプレートと追加リソース
- 日次概観→Slack:Get a daily Slack overview…
- Sheets監視+AI応答:Watch Sheets rows…
- 競合情報要約→Slack:Competitive intelligence to Slack
- スケジューラ:Schedule a scenario
- クレジットとOperations:How features use credits/Operations

運用の具体ワークフロー例(部門別)
- 営業チーム
- シート:当日受注、受注金額、AOV、商談ステージ推移、前日比。
- 要約:AOV上振れの理由(高単価SKU比率増)、受注数の下振れ(週末効果)。
- 意思決定:高単価SKUの在庫確認、明日の架電ターゲット見直し。
- CSチーム
- シート:新規/対応済み/エスカレーション件数、初回応答SLA、解決中央値、CSAT。
- 要約:SLA逸脱の時間帯特定、エスカ増の原因(特定プロダクト)。
- 意思決定:繁忙帯シフト調整、既知不具合の告知強化。
- マーケチーム
- シート:訪問数、CV、CVR、主要チャネル別のパフォーマンス、前週同曜日比。
- 要約:LP-AのCVR改善、広告停止の影響、自然検索の構成変化。
- 意思決定:A/Bテスト継続、広告の予算配分見直し。
Slack投稿の品質を上げる小ワザ
- 日付を日本語表記に整える(例:「2026年9月11日(金)」)。
- 数値は桁区切り(例:「12,345」)と通貨記号(例:「¥」)を明示。
- 「良い/悪い」の評価語は避け、事実と示唆に分けて記述。
- 末尾に「詳細を見る」リンクと、問い合わせ先(例:@ops-bot)を常設。
まとめ:日次AIレポート運用のチェックリスト
- Sheets側で集計済み範囲を用意し、Makeは必要最小限だけ読む。
- Text aggregatorで「行テンプレ→改行結合」に揃え、AIへ安定入力。
- プロンプトは形式・語調・件数・単位を明示して短く。
- Slackは1通に集約、Blocks+textフォールバックを忘れない。
- 実行ログでバンドル増幅点を特定し、クレジット/トークンを最適化。
- 失敗時の代替経路(要約なし投稿)と失敗通知を用意。
よくある質問(FAQ)
Freeプランで日次レポートは回せますか?
はい。月1,000クレジット、最小15分間隔の制約内で日次1通は現実的です(Pricing)。ただし先頭で多量の行を処理すると後段の実行が増幅し消費が増えるため、前処理/集約でバンドル数を抑えてください。
AI要約のコストはどう見積もる?
入力トークン(集約テキスト)+出力トークン(要約文)で概算します。2026年にMakeのAIプロバイダは入力/出力でレートが分離され、要約のような“入力多め”用途で効率が改善と案内されています(公式)。設計上は、不要な列を除外し、差分(前日比/前週比)に絞ると入力を削減できます。
Slackのレート制限に当たったら?
Slackは厳密な上限値を公開していません。HTTP 429とRetry-Afterヘッダーに従い、指数バックオフ等で再送してください。複数チャンネル配信は1通に集約する、または数秒の間隔を空けて順送りするのが安全です(公式)。
Google Sheets APIのクォータ超過を避けるには?
毎回RAWをフル取得せず、日次集計シート/固定範囲を作ってそこだけ読む設計に。取得回数/範囲を減らす、フィルタを前段に寄せる、深夜にまとめて集計→朝は読み取りのみ、が安定します(公式)。
日本語の要約品質を安定させるコツは?
行テンプレ化(列順・書式を固定)、略語辞書の同梱、最大文字数と箇条書き指定が効きます。語調(敬体/常体)と禁止事項(スラング等)も明記しましょう。Make AI Toolkitは日本語テキスト処理をサポートしています(公式)。
Slack接続で「承認が必要」と出た場合は?
MakeのSlackアプリはマーケットプレイス未掲載のため、ワークスペースのアプリ制限により管理者承認が必要な場合があります。IT/管理者に事前相談し、Botユーザーと配信先チャンネルの権限を確認してください(公式)。
クレジット見積りで膨らみやすいのはどこ?
先頭のSheets取得が大量の行(バンドル)を返すと、後段の実行回数が乗算的に増える点です(Operations)。Text aggregatorでまとめる、Sheets側で集計済みにする、チェックランの頻度を見直す、が有効です。
Zapierやn8nを選ぶのはどんな時?
Zapierは対応アプリが豊富(7,000+ apps)で、既存資産があれば移行が容易。n8nはセルフホストや“1実行”課金でコスト見積りが立てやすく、データ所在地やガバナンス要件が厳しい環境に適します(公式)。
SlackのBlocksとtextの両方を入れる意味は?
Blocksはリッチ表示に最適ですが、互換性や検索性の観点でtextフィールドのフォールバックも推奨されています。モバイルや外部連携での表示崩れ対策にもなります(chat.postMessage)。
プロンプトは毎回変えるべき?固定すべき?
日次ダイジェストは「固定プロンプト+日付や閾値の一部変数化」が安定します。大規模変更は週次/四半期のタイミングで検証→切替が安全です。
参考情報
- Pricing & Subscription Packages | Make
- Schedule a scenario – Help Center
- Make AI Toolkit – Apps Documentation
- Make AI Tools now available in Open Beta
- Slack – Apps Documentation (Make)
- chat.postMessage | Slack API
- Rate Limits | Slack
- Usage limits | Google Sheets API
- Scenario UI · Make Academy
- Types of modules – Help Center
- How features use credits – Help Center
- Introducing credits
- Adjustments to plans and pricing
- Operations – Help Center
- Make and Google Sheets Integration
- Template: Get a daily Slack overview…
- Template: Watch Google Sheets rows…
- Automation Tool | Integration Platform | Make
- Zapier Free plan/Zapier apps
- n8n Plans and Pricing
- n8n Sustainable Use License
- Google Sheetsのパフォーマンス改善
注:本記事は公開ドキュメントを基にしています。AIのトークン条件やクレジット/追加クレジット、Slack/Sheetsのレート/クォータは改定の可能性があるため、必ず最新の公式情報をご確認ください。

