Airtable Automationsの実行上限と回避設計──失敗した実行もカウントされる
Automationsには月間の実行回数上限があり、しかも「失敗した実行」もカウントされます。日本語で解説された記事がほぼ存在しないこの仕様を公式ドキュメントで裏取りし、上限にぶつからない設計・運用量から逆算したプラン選び・そして実案件で分かった「Automationsで完結しないこと」までまとめます。
Automationsの上限に気づくのは、大抵止まった後です。しかもあまり知られていない重要な仕様があります——エラーで失敗した実行も、上限としてカウントされます。
この記事では、公式ドキュメントに基づいた正確な数値のみを整理し、上限に到達させないための設計や、運用量から逆算するプラン選定の方法まで解説します。
この記事でわかること
- Automationsにおける3種類の上限（公式の数値）
- 失敗した実行もカウントされる仕様と、実務への影響
- 実行回数を抑える3つの設計
- 運用量からプランを逆算する方法
- 上限に達する前に決めておくべきこと
- 実案件で分かったAutomationsで完結しないこと（トリガー制限・列名変更で壊れる・GAS併用時の修正範囲）
まず公式の数値を押さえる
Automationsの制限は3種類あります。すべて公式ドキュメント（Getting started with Airtable automations）に記載されている数値です。
プラン別の月間実行回数（run）上限
| プラン | 月間実行回数 |
|---|---|
| Free | 100回 |
| Team | 25,000回 |
| Business | 100,000回 |
| Enterprise Scale | 500,000回 |
プランに関係なく効く2つの上限
| 対象 | 上限 |
|---|---|
| 1つのベースあたりのAutomations数 | 50本（無効化したものも含む） |
| 1つのAutomationあたりのアクション数 | 25個 |
1つ目の「無効化したものも含む」は見落としやすいポイントです。使わなくなったAutomationをオフにしただけでは枠は空きません。不要になったものは削除してください。
見落としやすい仕様：失敗した実行もカウントされる
公式に明記されている一文
Airtableは、トリガーが呼ばれるたびに1回の実行としてカウントします。アクションが正常に完了したかどうかに関係なくです（原文："Airtable counts an automation 'run' each time a trigger is invoked, regardless of whether the automation's action(s) run properly."）。つまり、設定ミスやAPIエラーで失敗し続けているAutomationであっても、何も処理されないまま上限を消費してしまいます。
最も危険なのは、外部サービスとの連携が停止したときです。①連携先APIが一時的なエラー状態になる →②トリガーは変わらず発火し続ける →③アクションは失敗し続ける →④実行回数だけが減っていく。エラー通知を設定していなければ、誰も気づかないまま上限に到達します。
そして上限に達すると、その月は正常に動いていたAutomationも含めて全部止まります。この構造はAIで作った業務ツールは、半年後に誰が直すのかで書いた「静かに止まる」問題とまったく同じです。失敗に気づける仕組みを、先に作ってください。
最低限やること
- 1失敗時にSlackなどへ通知を飛ばす（Automationの中に通知アクションを1つ足すだけ）
- 2月に1度、実行回数の消費ペースを見る（月末に慌てないため）
- 3テスト実行も消費することを踏まえて、検証は本番と別のベースでやる
実行回数を減らす3つの設計
同じ業務を回していても、設計次第で消費量は何倍も変わります。上限が近いなら、プランを上げる前にここを見直す価値があります。
「トリガーの条件を絞る」
最も効くのがこれです。「レコードが更新されたら」で発火させると、どの項目が変わっても発火します。担当者がメモ欄を直しただけで1回消費される、という状態になります。
- 「レコードが更新されたら」→ 「特定のフィールドが更新されたら」
- 「レコードが作成されたら（全件）」→ 「条件付きビューに入ったら」
- 「毎時実行」→ 「毎日1回」（本当に毎時必要か確認する）
条件付きビューをトリガーにするのが定石です。「ステータスが『承認待ち』になったレコードだけ」のようにビュー側で絞れば、無関係な更新では発火しません。
「Automationを分けずに1本へ集約する」
同じトリガーで複数のAutomationを作ると、その数だけ実行回数を消費します。
トリガーが同じなら、1本のAutomationの中でアクションを並べる方が消費は1回で済みます。アクションは25個まで入るので、たいていの処理は1本に収まります。
「件数が多い処理はスクリプト側に逃がす」
100件のレコードを処理する場合、レコード単位でトリガーすると100回消費します。
定時実行を1本だけ置き、その中のスクリプトアクションでまとめて処理すると、消費は1回です。件数が多い定型処理では、この差が決定的になります。
運用量からプランを逆算する
プラン選定で見るべきは、料金表よりも自社の月間トリガー回数の見積もりです。次の手順で概算できます。
見積もりの手順
- 1作る予定のAutomationを洗い出す
- 2それぞれのトリガー頻度を見積もる（日次なら月30回、レコード作成なら月間の新規件数）
- 3合計する
- 4安全率として1.5〜2倍する（テスト実行・失敗の再試行・想定外の更新を吸収するため）
感覚としては、Freeの100回は検証用と考えてください。日次の定時実行を1本置くだけで月30回、テストを繰り返せばすぐ到達します。本番運用ならTeam（25,000回）が実質的な下限です。逆に言えばTeamの25,000回はかなり余裕があり、レコード作成をトリガーにする運用でも、月800件の新規レコードなら十分に収まる計算です。
上限に達したらどうなるか
その月のAutomationsは停止します。翌月のリセットを待つか、プランをアップグレードする必要があります。業務が止まってから気づくのが最悪のパターンなので、消費ペースの定点観測を運用に組み込んでください。
上限にぶつかる前にやっておくこと
運用開始時に決めておく3つ
- 失敗通知を必ず入れる — 失敗が上限を食い潰す構造なので、気づける状態が前提になります
- 月次で消費量を確認する担当を決める — 「誰も見ていない」が一番多い失敗です
- 不要になったAutomationを削除する運用を決める — 無効化では50本の枠が空きません
3つ目は特に、部署ごとに自由にベースを作れる環境で効いてきます。誰も使っていないAutomationが実行回数を消費し続けている状態は珍しくありません。
実行履歴について
Automationの実行履歴は管理画面から日付を指定して遡れますが、保持期間は公式に公表されていません。「先月の処理がなぜ失敗したか」を後から追う必要がある業務なら、重要な実行結果は自前でログとして残す設計にしてください。失敗時の通知をSlackに飛ばしておけば、それ自体が簡易的なログになります。
上限の前に知っておきたい「Automationsで完結しない」こと
実案件でAirtableを組んでいると、上限とは別の理由でAutomationsから外す判断が出てきます。ここも先に知っておくと設計が早くなります。
「トリガーの種類に制限がある」
Automationsのトリガーは、レコード作成・レコード更新・ビューへの流入・定時実行・フォーム送信・Webhook受信などが用意されています。逆に言えば、この範囲を超える起点は作れません。
実案件では、「Slackの特定チャンネルに議事録が流入したこと」をトリガーにしたいという要件がありました。これはAutomationsのトリガー種別では扱えず、GAS（Google Apps Script）とAirtable APIを組み合わせる構成に切り替えています。トリガーが用意されていない起点を使いたい場合は、外部から叩く形（Webhook受信）にするか、GAS側で制御するのが現実的です。
「列名を変えると、Automationが壊れる」
こちらは運用でかなり効きます。テーブルの列名を変更したり、列を増減したりすると、Automationの変数指定やリレーションの参照が壊れます。実案件では、クライアントにこうお伝えしています——「列名の変更や、列の増加・削減、テーブルの追加によって、Automationの変数部分やリレーション関係も変わってきます。一旦、列名やテーブルなどの静的な部分を修正していただいてから、動的な部分もまとめて教えてください」。
順序が逆になると、直した先から壊れていきます。「静的な構造を先に確定させ、そのあとで自動化を直す」——この順番を守るだけで、手戻りが大きく減ります。
「Automationだけ直しても終わらないことがある」
AutomationとGASを併用している構成では、片方だけ直しても動きません。実案件でも「Automationは直したが、GASも直さないといけない。これが結構大きい修正になりそう」という状況が発生しています。
自動化の実体が2箇所に分かれていると、修正範囲の見積もりが倍になります。どの処理をAutomationに置き、どこからGASに任せるかを最初に線引きしておくと、後の保守が軽くなります。
まとめ
Automationsの上限は3つです。プラン別の月間実行回数（Free 100／Team 25,000／Business 100,000／Enterprise Scale 500,000）、1ベースあたり50本（無効化したものも含む）、1本あたり25アクション。
そして実務で最も効いてくるのが、失敗した実行もカウントされるという仕様です。連携先が落ちて失敗し続けているAutomationは、何も生まないまま枠を消費し、最後には正常なAutomationごと止めてしまいます。
対策は難しくありません。トリガー条件を絞り、1本に集約し、件数の多い処理はスクリプトに逃がす。そして何より、失敗に気づける通知を1つ入れておくこと。これだけで、上限に振り回される状況はほぼ避けられます。
バックアップ設計とあわせて考えるならAirtableのバックアップ方法3段構え、プランとコストの関係はAirtableの権限設計は、コスト設計であるにまとめています。
この記事の情報について
数値は2026年9月時点のAirtable公式ドキュメントにもとづきます。プラン構成や上限は変更される可能性があるため、実際の設計時には公式ヘルプで最新情報をご確認ください。
他の記事