Makeは無料でどこまで使える？Tallyフォームを自動化してクレジット消費を実測

オートメーションサービスのMake(Make.com)は、無料のFreeプランで月1,000 creditsまで使えます。では、Tallyで作ったフォームの回答を自動で処理すると、その1,000 creditsはどのくらいの速さで減るのでしょうか。止まったとき、やり直したときには何が起きるのでしょうか。

この記事は、2026年10月19日に、MakeのFreeプラン、TallyのFreeプラン、Google Sheetsだけで実際に動かして記録した結果です。フォーム→Makeの2つの経路(Custom webhookとTally公式Makeモジュール)と、Makeを使わないTally標準のGoogle Sheets連携を比べています。

※検索では「Make」が、名前の似た別のサービスと混ざることがあります。この記事で扱うのは、シナリオ(自動化の流れ)を組むサービスのMake.comです。

情報の根拠が分かるように、次の3つを書き分けています。

• 【実機確認】2026年10月19日に、自分でMake・Tally・Google Sheetsを操作して確認した内容
• 【公式情報】MakeとTallyの公式ページ・ヘルプで確認した内容(2026年10月19日確認)
• 【未確認】今回は確かめていない内容。推測で補わず、確認していないと書きます

実測の数字から計算した値は、実測と混ざらないよう【試算】と明記します。

先に結論:Google Sheetsに保存するだけなら、Tally標準で足りてMakeのcreditも使わない

Sheetsに貯めるだけならTally標準、回答の内容で処理を分けたいなど、Tally標準で足りない処理があるならMakeが候補です。つなぎ方は、今回の実測ではまず公式モジュールで、公式モジュールを使えないときはCustom webhookです。詳しい判断表は、後半の「結局どれを選ぶ?」にあります。

3つの方法の違い(早見表)

この記事で確認したこと・確認していないこと

検証の条件

• 実施日:2026年10月19日(1日で実施。Makeのリセット日は表示上2026年11月19日)
• 環境:MakeのFreeプラン(新規に作ったアカウント)、TallyのFreeプラン、Google Sheets。有料プランの契約・カード登録は行っていません
• テスト用フォーム:お名前/メールアドレス/会社名/ご用件の種別(ドロップダウン)/緊急度(単一選択)/お問い合わせ内容。ダミーのデータだけを送信しました
• 検証の項目は、実施前に決めて固定しました(下の表)

1アカウント・1フォーム・1日の検証です。長期運用、複数人での運用、大量の回答、有料プランの挙動は確かめていません。末尾の「この記事で確認していないこと」にまとめています。

方法①:Tally標準のGoogle Sheets連携(K0)

Tallyのフォームの「Integrations」画面から、Google Sheetsを接続する方法です。MakeもWebhookも使いません。

【公式情報】TallyのGoogle Sheets連携は無料のTallyユーザーでも使えます。送信ごとに1行が追加され、「Export existing submissions」をオンにすると既存の回答も反映されます。部分的な回答(途中までの回答)は同期されないこと、新しい行は最初の空行に入るため時系列の順になるとは限らないこと、同期ログと「Resend」(未配信の再送)、同期が失敗したときにメールが届くことが、公式ヘルプに書かれています。(Tally公式ヘルプ:Google Sheets連携)

【実機確認】Googleアカウントの認可をして、Google Sheets連携を追加しました。その後に送った8件(K1〜K8の送信)は、すべて、送信順に1行ずつ、各1回だけ記録されました。ドロップダウンと単一選択の値は「見積り依頼」「通常」のように日本語のラベルで記録され、IDにはなりませんでした。Makeのcreditは使っていません。

• 【実機確認】Makeのシナリオが止まっていた間(後述のK5〜K6)も、Tally標準の連携は独立して記録を続けました
• 【実機確認】回答の内容で保存先を分ける項目は、今回の設定画面では見当たりませんでした。営業のご案内も、緊急度「高」の回答も、同じシートに全件が入りました

つまり「回答をスプレッドシートに貯める」だけが目的なら、ここで完結します。以降は、Tally標準では足りない処理が出たときに、Makeがどう動くかの記録です。

Makeの無料プランの条件と、creditの基本

【公式情報】Makeの料金ページ(2026年10月19日確認)では、Freeプランは月1,000 creditsです。ルーター(Router)のモジュールとエラーハンドラー(Rollback・Break・Resume・Commit・Ignore)はcreditを消費しないと書かれています。creditは契約期間の終わりに失効します。また公式ヘルプでは、通常のアプリでは「1 operation(1つのモジュールの実行)=1 credit」で、一部のAI関連のモジュールなどは例外とされています。(Make料金ページ / Make公式ヘルプ:Credits)

【実機確認】アカウントのSubscription画面でも、Freeプランの内容を確認しました。

【実機確認】今回のFreeアカウントでは、FilterとRouterも実際に使用できました。

実行履歴は7日間しか残らないため、あとから確認し直したい場合は、履歴の画面を早めに保存しておく必要があります。

方法②:Tally公式Makeモジュール(実機で確認できた範囲)

【公式情報】TallyのヘルプによるとMakeとの連携は無料で、Makeのシナリオに「Tally」を追加し、トリガー「Watch New Responses」(フォームが送信されたとき)を選んで、MakeにTallyアカウントへのアクセスを許可し、Form IDのドロップダウンから対象のフォームを選ぶ流れです。(Tally公式ヘルプ:Make連携)

設定で起きたこと【実機確認】

• Makeのアプリ「Tally」のモジュールは、「Watch New Responses」(Instantの表示)と「List Fields Definitions」の2つでした
• Webhookを作るとき、Tallyへの接続が必須で、種別は「Tally OAuth」と「Tally Personal API Key」でした。私はOAuthを選び、Tallyの同意画面で許可しました(APIキーは使っていません)
• 今回の環境では、OAuthの許可後に、Form IDの候補としてアカウント内の2つのフォームが表示されました
• Webhookを保存すると、Tally側のIntegrationsに「Make」という連携が自動で追加されました。Webhook URLをTally側に貼る作業は不要でした

回答を1件受けた結果【実機確認】

フォームを一時的に再公開して、ダミーの回答を1件だけ送りました(送信後すぐに受付を停止)。Makeの「Run once」で処理すると、結果は次のとおりでした。

方法③:Custom webhook(Tally → Make → Google Sheets)

Make側で「Custom webhook」のURLを作り、TallyのIntegrationsにある「Webhook」にそのURLを貼る方法です。K1〜K8の検証は、主にこの経路で行いました。構成は、Webhookを受け取り、Routerで「緊急度が高」と「それ以外」に分けて、2つのGoogle Sheetsの「Add a Row」につなぐ形です。

最初のつまずき:選択項目がUUIDで届き、シートの列が空になった(K1)

【実機確認】Tallyの Webhookが送る回答は、fieldsという配列に項目の順で入っていました。ドロップダウンや単一選択の値は日本語ではなく、選択肢のID(UUID)の配列で、日本語の文字はoptionsという別の配列に入っていました。MakeがWebhookの構造を自動で検出した結果は、optionsを含まず、値を単なるテキストとして扱う形でした。そのため、最初のテストでは「ご用件の種別」と「緊急度」の列が空になりました。

試行錯誤の結果、今回のフォームでは、次の式で日本語のラベルを取り出せました。

first(map(1.data.fields[4].options; "text"; "id"; first(1.data.fields[4].value)))

「ご用件の種別」が4番目の項目なのでfields[4]です(Makeの配列は1から数えます)。この式はMakeの変数欄に入れて使いました。get(map(...))で取り出そうとしたり、indexOf(0から数える)を使ったりした方法は、この画面では期待どおりに動きませんでした。

K1の通常処理が正しく動くまでに、実行が5回・合計10 creditsかかりました(送信した通常の実行3回=各2、原因を調べるための再実行2回=各2)。今回の検証では、テスト送信や再実行でも各モジュールが実行され、その分creditを消費しました。

creditの減り方:実測と試算を分けて見る

【実機確認】実測した値

これらの合計は、Makeの「Credit usage」画面で、K0〜K8で21 credits、追加検証(失敗の再現2+公式モジュール1)を含めて24 creditsでした。Scenarios欄の合計が24 creditsで、無料枠1,000 creditsの約2.4%です。

K4:ポーリング型シナリオの消費(Tally→Makeの経路とは別の検証)

【実機確認】Google Sheetsの「Watch New Rows」(Free既定の15分間隔、pollシートは空)のシナリオで、新しい行がなくても、実行のたびに1 creditでした。2回目の実行(その間にpollシートへ2行追加)も、1回の実行で1 creditでした。実行間隔は、15:28:41から15:43:42で、15分と1秒でした。

【公式情報】Makeの公式ヘルプには、ポーリング型のトリガーは前回の実行以降の新しいデータを調べ、新しいデータがない実行を「check run」と呼ぶこと、check runは履歴で見られることが書かれています。ただし、このページにはcheck runのcredit消費は書かれていません。上の「新しいデータがなくても1 credit」は、今回の画面で確認した実測です。(Make公式ヘルプ:Types of modules)

【実機確認】参考までに、Custom webhookのシナリオの履歴には、回答が届いたときの実行だけが並んでいました(空振りの実行は見当たりませんでした)。

【試算】実測値からの計算(実際に月末まで動かしたものではありません)

条件で振り分ける:FilterとRouter(K2・K3)

MakeがTally標準より強いのは、この部分です。K2では、ご用件の種別が「営業のご案内」の回答をFilterで除外しました。K3では、Routerで、緊急度が「高」の回答を別のシート(urgent)に、それ以外をnormalのシートに振り分けました。

• 【実機確認】Filterで除外した回答でも、受信の1 creditは消費しました。Sheetsには行は追加されませんでした
• 【実機確認】Routerで振り分けた回答は2 credits(受信1+Sheets追加1)で、Router自体のcreditの表示はありませんでした。【公式情報】Routerはcreditを消費しないと、Makeの料金ページに書かれています

【未確認】FilterとRouterは、公式モジュールではなく、Custom webhook経路で実行した結果です。公式モジュール経由でFilter・Routerを実行して、creditや動作を確かめてはいません。

エラーで止まったとき:自動で無効になり、回答はキューに残る(K5・K6)

K5:わざとエラーを起こした【実機確認】

送信先のシート名(urgent)を一時的に別の名前に変えてから、緊急度「高」の回答を送りました。

• Makeの実行はErrorになり、エラー文は「400: INVALID_ARGUMENT – Unable to parse range: ‘urgent’!A1」(RuntimeError)でした
• 消費は2 credits(受信1+失敗したSheetsの操作1)。失敗した操作も消費されました
• 約1秒後に、Makeがシナリオを自動で無効にしました(履歴に「Scenario was deactivated by Make because of reason: …」)。無効になったシナリオは自動では再開せず、手動で有効にし直す必要がありました
• 「Incomplete executions」には何も残りませんでした(0件)
• Tally側のWebhookのイベントログは「Delivered」のままでした。回答はMakeのWebhookのキュー(待ち行列)に入りました

【公式情報】Makeの公式ヘルプには、Instantトリガーで始まるシナリオは最初のエラーの直後に無効になること(「Errors before deactivation」の設定はInstantトリガーでは使われない)、Webhookごとにキューがあり、処理されたデータは削除されること、キューの上限はプランによって決まることが書かれています。(Make公式ヘルプ:Scenario settings / Make公式ヘルプ:Webhooks)

キューとダイアログの画面(再現して撮影)

K5のときは、キューの画面とダイアログを撮れていませんでした。そこで、同じ手順(シート名を変更→有効化→TallyのWebhookのイベントログから、既存の回答を「Resend」)をもう一度行って撮影しました。このときも、Errorと自動の無効化が起き、WebhooksのキューはK5と同じ「1/50」でした。再現での消費は2 creditsです。

シート名を元に戻してシナリオを再有効化すると、次のダイアログが出ました。

• ダイアログの説明:新しく有効にしたシナリオは新しいデータだけを処理する。キューの古いデータは、先に処理するか、処理せずに削除するかを選べる
• K6(最初の復旧):シート名を戻して再有効化し、ダイアログで「Process old data」を選びました。実行はSuccess(2 credits)で、urgentシートにK5の回答が1行だけ追記されました(重複なし)。手順は3操作(シート名を戻す・有効化・ダイアログで処理)でした
• 再現のとき(上の画像):撮影後は「Process old data」ではなく「Delete old data」を選びました。確認のダイアログ(「Delete data in webhook queue」)が出て、削除すると、その回答は処理されません。この再現では、Process old dataは実行していません

復旧の手順をまとめると、①エラーの原因を直す、②シナリオを再有効化する、③キューの回答を「処理する(Process old data)」か「捨てる(Delete old data)」かを選ぶ、の3つです。処理しないまま再有効化すると、キューに残っていた回答は処理されません。

再実行(Replay)は、同じ回答の重複行を作る(K7)

実行履歴の「Replay」を押すと、確認の画面が出ます。Replayすると新しい実行が作られ、creditを消費し、連携先に重複データを作る可能性がある、という内容が表示されました。

【実機確認】1つの回答(同じresponse_id)を、元の実行とReplay 2回で処理したところ、normalシートに同じ回答が3行書き込まれました。Replayは新しい実行として、1回あたり2 creditsを消費しました。

重複を防ぐ仕組み(たとえば、書き込みの前にSearch Rowsで同じIDを探し、Filterで除外する)は試していません。その分のcreditが増える見込みですが、計測していないため【未確認】です。

日本語データは壊れなかったか(K8)

異体字(髙・﨑・𠮷)を含む氏名、㈱とカッコの会社名、全角英字、丸数字、全角・半角の記号、日付と金額、絵文字、改行、長文(全533文字)を含むダミーの回答を1件送り、Tally標準のGoogle Sheets連携の行と、Make(Custom webhook)経由の行を比べました。

【実機確認】データで1文字ずつ比べた結果、氏名・会社名・種別・緊急度・本文のすべてが一致しました(本文は533文字どうし、改行は2か所どうし)。ただし、これは今回のテスト文字列と533文字の範囲での結果です。あらゆる文字や長さで壊れないことを示すものではありません。

注意点が2つあります。時刻は、Tally標準のシートもMake経由のシートも、日本時間ではなくUTC(協定世界時)の表記で入りました(日本時間より約9時間遅れて見えます)。また、公式モジュール経由でSheetsに書き込んだ場合の日本語は【未確認】です。公式モジュールの出力画面では、異体字・㈱・全角英字・丸数字・絵文字・改行がそのまま表示されたことまでを確認しています。

結局どれを選ぶ?(今回の実測にもとづく判断)

Makeを使うかどうかは、「Tally標準でできないことがあるか」で決めるのが安全です。目安として、Custom webhook経路で1回答=2 creditsなら、試算上は月に約500件の回答まで1,000 creditsに収まります(失敗・再実行・テストを除く)。これは実測値からの計算で、長期の運用で確かめたものではありません。

この記事で確認していないこと

• 公式モジュール経由での、Google Sheetsへの書き込みとそのcredit(合計が2 creditsになるかは未確認)、Filter・Routerの実行、エラー時の動作
• 「Fields by ID」の挙動(質問のラベルを後で変更したとき)
• Tally標準のGoogle Sheets連携の失敗時の挙動(公式ヘルプの記載のみ)
• 有料プランの挙動、大量の回答の処理、複数人・長期の運用、月末までのcreditの減り方
• 重複を防ぐ処理と、そのためのcredit

MakeやTallyの仕様・画面・料金は変更されることがあります。この記事は2026年10月19日の時点の内容です。

よくある質問

Q. Makeの無料プランは、何回まで自動化できますか?

回数ではなく、creditで決まります。Freeプランは月1,000 creditsで、【公式情報】通常は1 operation=1 creditです。今回の実測では、Custom webhook経路で1回答=2 creditsでした。別に試したGoogle Sheetsのポーリング型シナリオ(K4)では、新しいデータがなくても、実行のたびに1 creditでした。

Q. TallyからGoogle Sheetsに送るだけなら、Makeは必要ですか?

必要ありません。Tally標準のGoogle Sheets連携で、今回の8件はすべて1回ずつ記録され、Makeのcreditも使いませんでした。

Q. 公式モジュールとCustom webhookは、どちらがいいですか?

今回の実測では、公式モジュールは選択項目が日本語ラベルで出力され、変換式が不要でした。Custom webhookは選択項目がUUIDで、変換式が必要でした。ただし公式モジュールは、Sheets書き込みとFilter・Routerを試していないため、その範囲の優劣は言えません。

Q. エラーでシナリオが止まったら、どうすればいいですか?

今回は、原因(シート名)を直して再有効化し、ダイアログで「Process old data」を選ぶと、キューに残っていたK5の回答が1行だけ追記されました。「Delete old data」を選ぶと、その回答は処理されません。Replayは同じ回答を重複して書き込むことがあります。

まとめ

• Google Sheetsに回答を保存するだけなら、Tally標準の連携で足りて、Makeのcreditも不要でした
• Makeが候補になるのは、回答の内容による除外・振り分けなど、Tally標準では足りない処理が出たとき
• Makeでつなぐなら、今回の実測では公式モジュールの方が選択項目を扱いやすかった(ただしSheets書き込みとFilter・Routerは未確認)。Custom webhookは変換式が必要
• Custom webhook経路の実測:通常の1回答=2 credits、Filterで弾いても受信の1 credit、別に試したポーリング型(K4)は何もなくても1回1 credit
• エラーが1回出るとMakeはシナリオを自動で無効にした。復旧は「Process old data」で1行だけ。Replayは重複した
• 日本語は、今回のテスト文字列と533文字の範囲で、Tally標準と一致した

関連記事

• Tallyとは?料金・日本語対応・無料版でできる範囲を実機レビュー
• Tallyの使い方|日本語の問い合わせフォームを作って公開するまで
• TallyとJotformを実際に使って比較

確認した情報の出典(いずれも2026年10月19日確認)

• Make 料金ページ(Freeの1,000 credits、Router・エラーハンドラーのcredit)
• Make公式ヘルプ:Credits(1 operation=1 credit)
• Make公式ヘルプ:Types of modules(ポーリング型とInstantトリガー、check run)
• Make公式ヘルプ:Webhooks(Webhookのキュー)
• Make公式ヘルプ:Scenario settings(Instantトリガーのシナリオの自動無効化)
• Tally公式ヘルプ:Make連携
• Tally公式ヘルプ:Google Sheets連携
• Tally公式ヘルプ:Webhooks(送信に失敗したときの再試行とイベントログ)

本記事の内容は、2026年10月19日にMake・Tally・Google Sheetsの無料の範囲で実際に操作した結果と、同日に確認した上記の公式ページにもとづいています。サービスの仕様や画面は変更されることがあります。