結論:Freeで始めてよい条件、Core・Proを確認する条件
MakeのFreeプランは月額0ドル、月1,000クレジットまで使え、クレジットカードなしで始められます。プラン自体に利用期限はありません。まずFreeを選びやすいのは、月1,000クレジット以内に収まると見積もれること、同時に有効化するシナリオが最大2件で足りること、最短15分のスケジュールで足りること、1回の実行が5分以内で終わること、詳細ログを7日間保存できれば足りること、という条件がそろう場合です。
反対に、3件以上のシナリオを有効化したい、1分間隔で動かしたい、1回の処理に5分を超える可能性がある、ログを30日保存したい、より大きなデータ転送量やMake APIが必要なら、Coreを確認します。優先実行、カスタム変数、実行ログの全文検索が運用上必要なら、Pro固有の機能が関係します。まずはトリガー方式と実行頻度を見積もり、必要な制限だけを基準に判断するのが順序です。
Free / Core / Proの違い
| プラン | 月間クレジット / 有料区分 | 有効シナリオ | 最短スケジュール | 実行時間上限 | ログ | 向く判断 |
|---|---|---|---|---|---|---|
| Free | 月額0ドル / 月あたり最大1,000クレジット | 最大2件 | 15分 | 5分 | 詳細ログは7日 | 1,000クレジット以内と見積もれ、2件・15分・5分・7日で足りる |
| Core | 有料区分 | 無制限 | 1分 | 40分 | 詳細ログは30日 | シナリオ数、1分間隔、実行時間、30日ログ、より大きなデータ転送量、Make APIを必要とする |
| Pro | 有料区分 | 無制限 | 1分 | 40分 | 詳細ログは30日 | Coreの条件に加え、優先実行、カスタム変数、実行ログの全文検索が必要 |
表は「できる・できない」を分けるための入口です。Freeの上限に近づく前でも、スケジュール、実行時間、ログのいずれかが要件に合わなければ、クレジット数とは別にCoreまたはProを検討します。
ポーリングとinstant:クレジットの見積もりで最初に分けること
ポーリングトリガーは、設定したスケジュールごとにデータを確認します。Gmail Watch Emailsはポーリングであり、設定したスケジュールごとにメールを確認します。今回の公式根拠では、メールが0件でも1件以上でも、1回の確認は1オペレーション、1クレジットです。
一方、instantトリガーやwebhookはデータ到着時に開始し、定期的なポーリング確認は行いません。そのため、ポーリング型では確認回数を先に計算し、instant型では受信イベント数と後続処理を中心に見積もります。ただし、すべてのモジュールへ同じ算定規則を一般化することはできません。通常の非AIアプリの多くは1オペレーションが1クレジットですが、AIや高度な機能には異なる規則があり得ます。
月間クレジットを静的に手計算するワークシート
ポーリング型を考えるときは、30日を仮定して、まずトリガー確認だけを固定的に数えます。
推定月間クレジット = トリガー確認回数 + 後続の通常非AIオペレーション + リトライ・エラー用バッファ 15分: 96 x 30 = 2,880 trigger checks/month 1時間: 24 x 30 = 720 trigger checks/month 1日1回: 30 trigger checks/month
これは算術上の推定であり実測ではありません。
たとえばGmail Watch EmailsをFreeの最短15分で30日間連続ポーリングするなら、トリガー確認だけで2,880クレジットとなり、月1,000クレジットを上回ります。これは推定です。15分はFreeプランで使える最短間隔であり、15分ごとに動かす義務ではありません。
次に、実際に処理したメールなどの入力バンドルごとに、後続の通常非AIオペレーションを足します。Gmail Watch Emailsの後にGoogle Sheets Add a Rowを置く構成では、Google Sheets Add a Rowは処理する入力バンドル1件ごとに1オペレーション、1クレジットです。最後に、リトライ・エラー用バッファを別枠で加えます。ここでの計算は構成を比べるための手計算であり、利用結果の実測ではありません。
instant型では、定期確認回数の代わりに、実際の受信イベントによるトリガー実行、処理されたバンドルに対する後続の通常非AIオペレーション、リトライ・エラー用バッファを合計して考えます。AIや高度な機能は異なる算定規則になり得るため、使うモジュール・機能ごとの個別確認が必要です。
Start-Free前のチェックリスト
- トリガーはポーリングかinstantかを確認する。
- 実行頻度を決め、30日を仮定した確認回数またはイベント数を置く。
- 同時に動かす有効シナリオ数が2件以内か確認する。
- 1件の入力を処理する後続モジュール数を書き出す。
- 想定する月間イベントを、ポーリング確認とは分けて数える。
- リトライやエラー時の余地を見積もりに加える。
- 1回あたりの実行時間が5分以内で足りるか確認する。
- ログ保存が7日で足りるか確認する。
- AIやカスタム変数、全文検索などの高度機能が必要か確認する。
- チーム内で必要なシナリオ数、確認頻度、ログの見方をそろえる。
この順に埋めると、月1,000クレジットだけを見て判断するよりも、Freeの制約が実際の構成に合うかを確かめやすくなります。
過去のGmail→Sheets検証で確認できた範囲
この成功例は2026年8月20日の過去の検証に基づき、新たな2026年9月の成功実測ではありません。
過去の検証ではMake Freeを利用し、Gmail Watch EmailsからGoogle Sheets Add a Rowへ接続しました。専用のテストメール1通を受信して使用し、スプレッドシートにはちょうど1行が追加されました。追加行にはreceived_at、from、subjectを記録しています。外部へのメール送信はなく、メールの削除・アーカイブもありません。有料のMakeプランは使用していません。手順と確認範囲はGmailからGoogle Sheetsへの検証記録でも確認できます。
成功した過去の実行で消費した正確なクレジット数やオペレーション数は観測・記録していません。専用メールアドレスを使ったことは確認されていません。ここでいう専用のテストメール1通と、専用メールアドレスの利用確認は別の事実です。
1回の成功だけでは本番運用の信頼性や処理量を示せません。有料プランとの実測比較は行っていません。したがって、この検証はFreeでGmailの新着監視からGoogle Sheetsへの行追加という接続を確認した過去の記録として扱い、クレジット消費や本番規模の根拠にはしません。
まとめ
Freeを選ぶ判断は、表で上限を確認し、ポーリングかinstantかを分け、月間クレジットを推定し、チェックリストで必要条件を照合することです。月1,000クレジット、最大2件、最短15分、実行5分、ログ7日で足りるならFreeを試す候補になります。シナリオ数、頻度、実行時間、ログ、Make APIやデータ転送量が要件になるならCoreを確認し、優先実行・カスタム変数・全文検索が必要ならProを確認します。
この記事にはMakeのアフィリエイトリンクを含みます。リンク経由で契約されると、当サイトが報酬を受け取る場合があります。
小さな作業から確認できます。