AirtableはAIネイティブのアプリ基盤で、やりたいことを自然な言葉で伝えるだけで、チーム自身の業務データ上で動くテーブルや画面、自動化、AIエージェントを構築でき、管理者による統制と企業向けの法令順守にも対応します。
このツールを使いましたか？評価してください
Airtableは、業務担当者が自分で扱える関係型データベースを土台にしながら、その上に人工知能を製品の主軸として据えた協働プラットフォームです。公式サイトの冒頭では「人工知能が個人の働き方を変えたなら、Airtableはチームの協働のしかたを変える」という主張が掲げられ、自らを「未来をつくる企業のための記録システム」と位置づけています。この表現は宣伝文句というより、製品構造そのものの説明です。データが散らばったままでは、どれほど優れたモデルを接続しても結果が信頼されません。だからこそ、まずチームの事実を一か所に集める記録層を確保し、その上でワークフローとエージェントを動かすという順序になっています。
2025年6月24日に最高経営責任者が公開した書簡は、今回の刷新の性格をはっきり定義しました。書簡はこの人工知能中心の作り直しを、同社にとっての「もう一度創業する瞬間」と表現し、既存の基盤に機能をいくつか足したものではないと明言しています。つまり人工知能は付加的な層ではなく本線です。この違いは実際の使用感にも現れます。多くのツールが取る手法は、完成した表の脇に補助ボタンを一つ添える形ですが、Airtableはアプリケーションをつくる起点そのものを対話に置き換えました。
それでも土台にある概念はなじみ深いままです。データはベースという単位に収まり、各テーブルの列はテキスト、数値、日付、選択肢、添付ファイル、担当者といったフィールドタイプで区別されます。テーブル同士はリンクされたレコードでつながり、この結びつきによって一件の顧客情報が契約、請求、サポート履歴と一つの事実としてまとまります。表計算に慣れた人がデータベース理論を学び直さなくても構造化データを扱えることが、長年この製品の中核的な資産でした。現在の人工知能機能も、結局はこの構造化された土台の上で動いています。
整理すると、Airtableは三層で理解するのが正確です。最下層には担当者自身が設計し修正する関係型データ層があります。その上にはワークフローと画面が置かれ、データを流し、人に見せます。最上層には対話型のビルダーとエージェントが位置し、つくる仕事と処理する仕事の両方を引き受けます。導入を検討する際は、この三層のどこに重心を置くかによって体感される価値が大きく変わります。
Omniは、必要なものを自然言語で説明すると、データテーブル、画面、ワークフローまで含んだ完成形のアプリケーションを生成する対話型ビルダーです。空白の画面からフィールドを一つずつ作る代わりに、「どの業務をどう処理したいか」を文章で書くところから始まります。重要なのは、生成物が閉じていない点です。できあがった構造は従来のビジュアル編集ツールで手作業で編集し続けられるため、最初の形に納得できなくても一から作り直す必要がありません。生成はたたき台を素早く得る手段であり、最終形は人が決めます。
エージェントはデータを分析し、コンテンツを生成し、調査を代行します。Field Agentsは各レコードの中で動作し、行単位で結果を埋めていきます。このほかにも複数の形態が用意されています。文書分析のエージェントは契約書や請求書を走査してリスク箇所を洗い出します。ウェブ検索のエージェントは見込み客の情報を補完し、競合を分析し、ニュースを要約します。翻訳や画像生成にも対応します。これらのエージェントは、データが新規追加または更新された時点で自動的に実行されるよう設定できるため、人が毎回操作しなくても処理の流れが途切れません。
自動化はトリガーとアクションを組み合わせるノーコード方式で構成します。条件分岐や繰り返しといった基本の流れは画面上のクリックで組め、標準のブロックでは表しにくいロジックはJavaScriptで拡張できます。チャット型の協業ツールや業務用オフィス製品群といった代表的な外部サービスとは標準の接続が用意されているため、状態が変わったときに担当チャンネルへ通知したり、文書を作成しておいたりする処理を、別途開発することなく実現できます。
インターフェースデザイナーは、データをそのまま露出させる代わりに、役割に合わせた画面をつくるための機能です。コードを書かずに一覧、詳細、ダッシュボードといった形の画面を組み立てられ、誰が何を見られるかもここで決めます。ただし公式の案内には、権限に関わる一部の機能が特定の有料プランでのみ提供されるという但し書きが付いています。社外の協力会社や大規模な組織に画面を配布する計画があるなら、プランの条件を先に確認してください。
管理者はワークスペース単位で人工知能の利用可否を切り替えられ、どのデータにアクセスできるかも制御します。すべての活動はガバナンスの対象であり、監査が可能です。最上位の企業向けプランでは、管理パネル、監査ログ、企業向けの鍵管理、データ漏洩防止の機能が追加で提供されます。規制の厳しい業界で導入を検討する場合、この層が実質的な判断材料になります。
HyperDBは、1億件を超える大規模データセットを扱うための経路です。通常のベースにおけるレコード上限とは異なる層の機能で、大量の元データを参照する必要がある場面を想定しています。ただしこれは企業水準の能力であり、下位プランのレコード上限を回避する手段として理解すべきではありません。
ウェブAPIは標準的なREST的意味論に従い、データはJSONで表現され、処理結果は一般的なHTTPステータスコードで返されます。つまり特殊な通信規約を学ぶ必要はなく、慣れた方法で連携できます。ただしプランごとに呼び出し上限が異なるため、設計段階で呼び出し量を必ず織り込む必要があります。
機能要望、不具合、リリース予定、担当者を一つのベースにまとめ、各項目をリンクされたレコードでつないでおくと、どの要望がどのリリースに含まれたかを追跡できます。インターフェースデザイナーで経営層向けの要約画面と現場向けの作業画面を分けて作れば、同じデータを見ながらもそれぞれに必要な情報だけが表示されます。
企画、初稿、校閲、公開へと進む段階をステータスのフィールドで管理し、状態が変わるたびに担当チャンネルへ通知が飛ぶようワークフローを組みます。ここに生成系のエージェントを組み合わせれば、初稿の要約、見出し候補の作成、多言語への翻訳といった反復作業をレコードの中で処理できます。ただし生成結果は公開前に必ず人が確認してください。
商談の段階、担当者、想定金額をテーブルで管理しながら、ウェブ検索のエージェントで新規見込み客の公開情報を補い、競合状況を整理します。新しいレコードが入った時点で自動的に調査が走るようにしておけば、営業担当が最初の電話をかける前に背景情報がすでに埋まっている状態をつくれます。
文書分析のエージェントで契約書や請求書を走査してリスク箇所を抽出し、その結果をレコードのフィールドとして残します。元のファイルは添付として保管し、確認結果は構造化されたフィールドに収まるため、後から条件別に検索したり集計したりするのが容易になります。判断そのものは担当者が下し、エージェントは読む時間を減らす役割を担います。
応募者、募集ポジション、面接日程、評価記録を互いにつないでおけば、一人の全履歴を一望できます。選考段階が変わったときに通知を送り、評価の要約を自動生成するよう組めば管理の負担が減ります。ただし人事データは機微な情報なので、画面の段階で閲覧範囲を必ず絞り込んでください。
資産管理、取引先一覧、予算執行など、これまで個別の表に散らばっていた資料を一つのベースにまとめると、部署間の二重入力がなくなり、数字の出どころが明確になります。規模が大きくなり通常のベースの上限を超える見通しがあるなら、上位プランや大規模データセットの経路も併せて検討する必要があります。
まず自動化したい業務を一文で書き出します。「何を記録し、誰が更新し、どんな判断を下すのか」がその一文に含まれている必要があります。この定義が曖昧なままだと、後の工程でフィールドが際限なく増え、構造が崩れます。
定義した文章をそのままOmniに説明し、テーブル、画面、ワークフローを含むたたき台を生成します。この段階の目的は完成ではなく、議論の対象を手に入れることです。なおアプリケーションを構築する行為そのものはクレジットを消費しないため、気兼ねなく何度でも試せます。
生成されたテーブルを開き、フィールドタイプが実際のデータの性質と合っているかを確認します。日付をテキストとして受けていないか、選択肢で管理すべき値が自由入力のままになっていないかを点検してください。繰り返し現れる値は別テーブルに切り出し、リンクされたレコードでつないでおかないと、後から集計できません。
テーブル間のつながりを整理したうえで、参照や集計のフィールドで必要な数値を引いてきます。ここが表計算と最も大きく分かれる地点であり、初めて使う人が最もつまずく区間でもあります。一度きちんと組んでおけば、その後の画面づくりも自動化も格段に単純になります。
役割ごとに画面を分け、それぞれの画面がどのデータを見せるかを決めます。人によって必要な情報は異なるため、元のテーブルをそのまま共有するより、画面を経由してアクセスさせるほうが安全です。権限に関わる細部の機能はプランによって異なるので、事前に確認してください。
ステータスの変更や新規レコードの作成といった、明確な時点を選んでワークフローを設定します。データの追加や更新の時点でエージェントが自動実行されるようにする際は、最初から全体に適用せず、一部のレコードで先に試してください。
ワークスペース単位で人工知能の利用可否とアクセス可能なデータを決めます。組織の方針上、特定のデータを処理の対象から外す必要があるなら、この段階で明示的に除外しておきます。
一定期間運用し、クレジットの消費と座席数の変化を見守ります。想定より消費が速いようなら、どのワークフローが原因かを突き止め、実行条件を絞ってから適用範囲を広げる順序が安全です。
第一に、構造を先に固め、自動化は後から乗せます。フィールドタイプやテーブル間の関連がずれた状態で自動化を重ねると、誤ったデータがより速く広がるだけです。最初の数日を構造の整理だけに使うほうが、結果としては早く仕上がります。
第二に、編集権限を習慣的に配らないことです。座席課金の仕組みでは、編集権限を必要とする協働者ごとに費用が発生します。実際、気軽に編集権限を配ったところ請求額が想定を超えたという声が、利用者コミュニティで繰り返し上がっています。多くのメンバーは画面からの閲覧と入力だけで足りる場合が少なくありません。
第三に、レコード上限を最初から計算に入れます。上限はワークスペースではなくベース単位で適用され、無料プランは1000件、Teamプランは50000件です。ログのようなデータをそのまま積むと想定より早く限界に達するので、保管期間を定めるか、要約用のテーブルを別に置く設計が必要です。
第四に、エージェントの実行条件は狭く始めます。クレジットの消費量は入力データ、選んだモデル、出力データによって変動するため、固定値では予測できません。特定の条件を満たすレコードにだけ先に適用し、実際の消費の推移を確認してから広げる進め方が安全です。
第五に、クレジットが共有資源であることをチーム全体で認識してください。クレジットはワークスペースまたは組織のレベルでまとめて使う枠であり、個人に固定されません。無駄が出にくい仕組みですが、裏を返せば、一つのチームが大量の自動化を回すと他のチームの取り分が減ります。大量処理を計画するなら、事前に共有する手順を設けておくとよいでしょう。
第六に、生成結果を確認する段階を構造の中に組み込みます。対話型ビルダーがつくったアプリケーションも、エージェントが埋めたフィールドも、人の確認が必要です。「確認済み」といったステータスのフィールドを置き、その値が真のときだけ次の工程に進むよう自動化を設計すれば、確認が形式ではなく実際の関門になります。
第七に、外部連携は呼び出し上限を基準に設計します。無料プランはワークスペースあたり月1000回、Teamプランは月100000回で、Businessプラン以降は回数の制限がありません。短い周期で繰り返し問い合わせるより、変更が発生したときだけ呼び出す方式のほうが上限を節約できます。
第八に、変更履歴の長さを把握したうえで使います。無料プランの修正履歴とスナップショットの保管期間は2週間、TeamとBusinessのプランは1年です。四半期単位で過去の状態をさかのぼる必要がある業務なら、無料プランでの運用は現実的ではありません。
第一に、表計算での運用に限界を感じている中小規模のチームです。値の重複やバージョンの衝突が繰り返されているなら、関係型の構造へ移る時期です。
第二に、情報システム担当者を配置せずに独自の業務ツールが必要な部署です。開発人員を割り当ててもらいにくい状況で、担当者自身がつくって直せることが実質的な価値になります。
第三に、繰り返しの調査や要約の作業が多い営業と販促の組織です。見込み客の情報補完や競合情報の整理といった作業をレコード単位で自動化できます。
第四に、大量の文書を読む必要がある法務、調達、財務の担当者です。契約書や請求書からリスク箇所を抽出する作業の一次処理を任せられます。
第五に、複数部署のデータを一か所に集めたい運用担当者です。部署ごとに散らばった表を統合し、画面単位で配布するのに向いています。
第六に、監査や統制の要件がある規制産業のチームです。管理者による統制、監査ログ、データ漏洩防止といった要件を上位プランで扱えます。
第七に、試作を素早くつくって見せる必要がある企画担当者やコンサルタントです。対話型ビルダーで議論用のたたき台を短時間で用意できます。
第八に、膨大な元データを参照する必要がある組織です。1億件を超える規模を扱うなら、大規模データセットの経路が検討対象になります。
主な利用環境はウェブブラウザです。インストールせずに接続するだけで使え、機能の更新はサービス側で行われるためバージョン管理の負担もありません。チーム全員が同じ画面を見ながら協働するという点でも、ブラウザ中心の運用が既定の形になります。
公式にはデスクトップ向けアプリとモバイル向けアプリも提供されています。ただし各配信先での評価点、インストール容量、必要とされるオペレーティングシステムのバージョンといった細かな数値は、独自に確認できていません（要確認）。社内配布の方針上、最低限のシステム要件を明記する必要がある組織は、公式の配布ページで直接ご確認ください。
プログラムから接続する場合はウェブAPIを使います。このインターフェースは標準的なREST的意味論に従い、データをJSONでやり取りし、処理結果を標準のHTTPステータスコードで知らせます。プランごとの呼び出し上限は前述のとおりで、連携の規模が大きい場合はこの上限が実質的な設計上の制約になります。
無料プランは、ベースあたり1000件のレコード、1GBの添付ファイル容量、2週間の修正履歴とスナップショットの保管、ワークスペースあたり月1000回のAPI呼び出しを提供します。個人利用や概念実証には十分ですが、チーム運用にはすぐ手狭になります。
Teamプランは年間契約の場合、ユーザーあたり月20米ドルです。ベースあたり50000件のレコード、20GBの添付ファイル容量、1年間の修正履歴、月100000回のAPI呼び出しが含まれます。多くの実務チームが最初に検討する水準です。
Businessプランは年間契約の場合、ユーザーあたり月45米ドルです。ベースあたり125000件のレコード、100GBの添付ファイル容量、1年間の修正履歴を提供し、API呼び出しの回数に制限はありません。連携が多い組織や統制の要件が強い組織が該当します。
Enterprise Scaleプランは個別見積もりでの提供です。管理パネル、監査ログ、企業向けの鍵管理、データ漏洩防止といった統制機能はこのプランに含まれます。
人工知能のクレジットは、プランごとに有料ユーザー数に応じた月次の枠が割り当てられます。この枠は無料とTeamのプランではワークスペースのレベルで、BusinessとEnterpriseのプランでは組織のレベルでまとめて使われ、個人には固定されません。消費量は動作ごとに変動し、入力データの量、選んだモデル、出力データの量が変数として効いてきます。追加購入はセルフサービスの価格で、月10000クレジットが20米ドル、月100000クレジットが200米ドル、月400000クレジットが800米ドルです。一つ重要な点として、対話型ビルダーでアプリケーションをつくる行為そのものはクレジットを消費しません。つまり費用が発生するのはつくる過程ではなく、運用中に実行される処理のほうです。
個人情報の保護と規制順守の面も、予算の検討と併せて見ておくべき部分です。公式の説明によれば、モデルの提供側は顧客データを保持せず、顧客データがモデルの学習に使われることもありません。企業の顧客はどのモデルを使うかを自ら決められ、選択できる提供元には主要なモデル提供元が含まれます。取得している認証はSOC 2 Type 2、ISO/IEC 27001:2022、ISO/IEC 27701:2019、HIPAA、TX-RAMP Level 2です。欧州連合域内でのデータ保管という選択肢が用意されており、企業の顧客は自社の鍵で保管中のデータを暗号化できます。欧州経済領域と英国、スイスの居住者には、アクセス、可搬性、訂正、削除、処理の制限、同意の撤回、異議申立ての七つの権利があり、米国の対象となる州の居住者にはアクセス、削除、訂正、不服申立ての権利があります。プライバシーポリシーの最終更新は2026年7月15日です。
Notionは文書とナレッジベースの領域で優れています。自由な文書作成と情報整理が中心で、データベースはそれを補助する形なので、チームの主な成果物が文書であればこちらのほうが合います。
Smartsheetは従来型のプロジェクトポートフォリオ管理に近い製品です。日程や資源の配分を定型的な方法で管理する必要がある組織なら、慣れた概念をそのまま使えます。
Monday.comは業務管理が先で、データベースとしての性格は次に来ます。チームの進捗を視覚的に管理することに焦点があるため、複雑なデータモデルより協働の流れが重要な場合の選択肢になります。
表計算にスクリプトを組み合わせる方式は費用が最も低く抑えられます。ただし関係型の構造と権限配布の仕組みが不足しているため、データが増え関係者が多くなるほど、維持の手間という別の形で費用が返ってきます。
BaserowとNocoDBはオープンソースで、自社のサーバーに設置して運用できます。データを特定の地域や自社の設備の中に置く必要がある場合や、費用を最優先にする場合に検討する価値があります。
Retoolは、すでに保有しているデータベースの上に社内向けツールをつくることに焦点を当てています。コードを書くことが前提なので開発人員のいる組織に向いており、記録システムそのものを新しくつくるという目的とは方向が異なります。
第一に、座席課金の仕組みです。編集権限を必要とする協働者一人ごとに費用が発生し、利用者コミュニティでは、気軽に編集権限を与えた結果として請求額が想定を超えたという声が繰り返し上がっています。費用が利用量ではなく人数に応じて増える点は、組織が大きくなるほど負担として効いてきます。
第二に、レコード上限はベース単位で適用されます。無料プランの1000件、Teamプランの50000件は、実際の運用では思ったより早く埋まります。大規模データセットのための経路は企業水準の能力であり、下位プランの上限を補う代替品ではありません。
第三に、クレジットの消費が変動的で、過小に見積もりやすい点です。消費量は入力データ、選んだモデル、出力データによって変わります。さらにクレジットが共有資源であるため、一つのチームの自動化が共通の枠を使い切ってしまう可能性があります。
第四に、学習コストは実在します。リンク、参照、集計へと連なる関係型の考え方が、表計算に慣れた利用者にとって主な参入障壁です。導入初期にこの概念を一緒に学ぶ時間を計画に入れておかないと、表を模倣しただけの平坦な構造が残ります。
第五に、一部の機能がプランごとに制限されています。とくに権限に関わる項目がそうなので、社外の関係者へ画面を配布する想定なら、必要なプランを事前に確認してください。
第六に、所有権の変更が進行中です。2026年8月4日、Bending SpoonsがAirtableの買収に関する最終合意に達したと発表し、企業価値は12億8500万米ドルとされています。ただし取引はまだ完了していません。規制当局の承認をはじめとする通常の条件を満たす必要があり、年内の完了が見込まれ、完了までは両社が独立して運営されます。現時点で製品、ブランド、ドメインに変更はありませんが、複数年にわたる調達の判断を下す際は、完了後の価格方針や製品の方向性が新しい所有者によって決められる可能性を考慮すべきです。
第七に、対話型ビルダーが生成したアプリケーションには、依然として人による確認が必要です。構造がもっともらしく見えても、フィールドタイプや関連の設定が実際の業務とずれていることがあるため、生成結果をそのまま本番運用に投入するのは勧められません。
最も大きな違いはテーブル同士の関連です。表計算は各シートが独立しているため同じ情報を複数の場所に繰り返し書くことになりますが、Airtableはリンクされたレコードでテーブルをつなぎ、一つの事実を一度だけ記録します。また各列がテキスト、日付、担当者、添付ファイルといった明確な型を持つので、入力の誤りが減ります。そこに役割ごとの画面と自動化を重ねられる点が加わります。
いいえ。2025年6月24日の最高経営責任者の書簡は、今回の刷新を同社にとっての「もう一度創業する瞬間」と表現し、既存の基盤に人工知能の機能を追加した形ではないと明確に述べています。実際、アプリケーションをつくる起点そのものが対話型ビルダーに置き換わり、エージェントがレコード単位で動作します。ただし土台にある関係型のデータ構造はそのまま維持されています。
個人には固定されません。プランごとに有料ユーザー数に応じた月次の枠が決まりますが、その枠は無料とTeamのプランではワークスペースのレベルで、BusinessとEnterpriseのプランでは組織のレベルでまとめて使われます。この仕組みのおかげで、特定の人に枠が縛られて余る事態は減ります。反面、一つのチームによる大量の自動化が共通の枠を急速に消費することもあり得ます。
対話型ビルダーでアプリケーションを構築する行為そのものはクレジットを消費しません。したがって構造を何度もつくり直しながら最適な形を探ることに、費用の心配はいりません。クレジットが消費されるのは運用中に実行される処理、つまりデータの分析やコンテンツの生成といった動作のほうです。消費量は入力データ、選んだモデル、出力データによって変動します。
制限がはっきりしています。ベースあたり1000件のレコード、1GBの添付容量、2週間の修正履歴とスナップショットの保管、ワークスペースあたり月1000回のAPI呼び出しが上限です。概念を検証したり小規模な個人業務を整理したりするには使えますが、複数人がデータを積み上げる実運用ではすぐに限界に達します。とくに2週間という履歴の保管期間は、操作ミスからの復旧という観点では短めです。
公式の説明によれば、モデルの提供側は顧客データを保持せず、顧客データがモデルの学習に使われることもありません。また企業の顧客はどのモデルを使うかを自ら決められます。管理者はワークスペースのレベルで人工知能の利用可否とアクセスできるデータの範囲を制御できるため、特定のデータを処理の対象から外す運用も可能です。
取得している認証はSOC 2 Type 2、ISO/IEC 27001:2022、ISO/IEC 27701:2019、HIPAA、TX-RAMP Level 2です。欧州連合域内でのデータ保管という選択肢が用意されており、企業の顧客は自社の鍵で保管中のデータを暗号化できます。管理パネル、監査ログ、データ漏洩防止といった統制の機能は最上位の企業向けプランに含まれるため、要件が厳しい組織はプラン選定の段階でこれらを併せて検討する必要があります。
上限はベース単位なので、まずデータを性質ごとに分けて複数のベースに切り出す方法が検討できます。保管期間を定めて古い記録を整理する、詳細なログの代わりに要約用のテーブルを維持するといった設計も有効です。プランを上げればTeamで50000件、Businessで125000件まで増えます。1億件を超える大規模データセットを扱う必要があるなら別途の経路が検討対象になりますが、これは企業水準の能力です。
2026年8月4日にBending Spoonsが買収に関する最終合意の締結を発表し、企業価値は12億8500万米ドルとされています。ただし取引はまだ完了しておらず、規制当局の承認をはじめとする通常の条件が残っていて、年内の完了が見込まれています。完了までは両社が独立して運営され、製品、ブランド、ドメインに現時点での変更はありません。短期の導入への影響は小さいものの、複数年にわたる契約を検討するなら、完了後の価格方針と製品の方向性を変数として見ておくのが現実的です。
ウェブAPIは標準的なREST的意味論に従い、JSONでデータをやり取りし、標準のHTTPステータスコードで結果を知らせるため、技術的な参入障壁は高くありません。実際に確認すべきは呼び出しの上限です。無料プランはワークスペースあたり月1000回、Teamプランは月100000回で、Businessプラン以降は制限がありません。短い周期で繰り返し問い合わせるのではなく、変更が発生した時点でのみ呼び出すよう設計すれば、上限をかなり余裕をもって使えます。
