AI実務自動化

Makeの無料プランで何ができる?1,000クレジットで試せる範囲と始め方

結論: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のアフィリエイトリンクを含みます。リンク経由で契約されると、当サイトが報酬を受け取る場合があります。

小さな作業から確認できます。

まず無料で自分の作業を1つ試す

-AI実務自動化