Airtableの保守・運用代行に何を頼めるか──契約で決める5項目と、壊れ方の実例

Airtableで業務システムを構築した（あるいはこれから構築する）企業が、次に直面するのが「作った後、誰が面倒を見るのか」という問題です。「ノーコードだから保守は不要」と思われがちですが、実際には列名を1つ変更しただけでAutomationが止まります。この記事では、Airtableの保守・運用代行に何を依頼できるのか、契約で何を決めておくべきか、費用の構造をどう捉えるべきかを、Airtable×GAS×生成AIの業務システムを実際に本番稼働・保守している現場の立場から解説します。

「ノーコードだから保守は要らない」は誤解──実際に壊れた3つの実例

まず前提を整理します。Airtableはコードを書かずにシステムを構築できますが、運用開始後に障害が発生する箇所は、コードの外側にあります。私たちが本番運用で実際に直面した3つのトラブル事例を紹介します。

「保守」「運用」「改善」は別物──頼む前に言葉を分ける

「保守をお願いしたい」というご相談をいただく際、詳細をヒアリングすると実際には3種類の業務が混同されています。これらを明確に区別せずに発注すると、見積もりも契約内容も曖昧になります。

区別が必要な理由は明快です。保守と運用は対応範囲を定義できますが、改善業務は青天井だからです。月額の保守契約に「改善」の定義が曖昧なまま含まれていると、受託側はリスクを避けるために高めの見積もりを出さざるを得ず、発注側は「月額費用の範囲内で対応してくれるはず」と期待し、確実に行き違いが生じます。

保守・運用代行に頼めること──メニューの実際

3つの業務を切り分けた上で、外部委託が可能な業務を一覧にまとめました。私たちが実際に保守・運用を受託している業務範囲をベースにしています。

重要なのは最後の項目です。改善対応を月額に含めるなら「月◯時間まで」と上限を設ける。含めないなら都度見積もりとする。どちらの設計でも問題ありませんが、未定のまま進めることが最大のリスクです。

どこからが「保守」でないか──実契約の対象外リスト

業務範囲の線引きの実例を紹介します。私たちがAI業務システムの案件で締結している契約では、保守フェーズの対象を「受入基準書に基づき完了確認済みの機能が、仕様どおりに動作しない状態（＝エラー）」と定義し、以下の項目を保守対象外として明記しています。

ポイントは、「エラーの定義」が受入基準書に紐づいている点です。何が「正常動作」かを書面で合意しているからこそ、「障害」の有無を客観的に判定できます。受入基準がないまま保守契約を結ぶと、「想定と挙動が違う」といった主観的な要望がすべて障害扱いとなり、対応範囲が際限なく広がります。

契約で決める5項目──実契約の書き方

対象外リストを含め、保守・運用契約において事前に合意すべき項目は5点あります。実際の契約書で使用している文面例とともに示します。

⑤は生成AIを組み込んだシステムならではの必須項目です。AIの出力には確率的な揺らぎが伴うため、「精度を保証する」という契約は誰にも履行できません。この前提を曖昧にしたまま「AIが間違えた」を障害として扱うと、受注側は対応不能に陥り、信頼関係が破綻します。誠実な業者ほど、この項目を事前に説明するはずです。

②の報告フォーマットも運用上極めて重要です。「動きません」という一報だけでは、原因の切り分けに余計な工数がかかります。再現手順・発生環境・影響範囲の3点が揃った報告に統一するだけで、復旧までの時間は目に見えて短縮されます。

費用の構造──「月額いくら」の前に見るべきもの

保守・運用代行の費用は、業者や範囲によって大きく変わります。提示された金額の相場を見る前に、まずは費用の構造を把握してください。

私たちの支援料金は固定プランではなく、過去の事例に基づいた個別見積もりでご提示しています。具体的な実績はAIパートナー事業のページに掲載しています。

発注側が要求すべきもの──「気づける仕組み」を先に作らせる

保守契約の質は、障害が起きたときの対応速度よりも、障害に気づくまでの時間で決まります。冒頭の「静かな故障」のように、エラーを出さない障害は珍しくありません。発注段階で、次の通知設計を最初の構築スコープに必ず含めるよう要求してください。

この3点が入っていれば、「数週間止まっていたのに誰も気づかなかった」という最悪のパターンはほぼ防げます。逆に、要件定義の段階で通知設計の話が出てこない業者には、この記事を見せて要求してください。

ずっと任せるか、社内に引き取るか──2つの出口を先に決める

保守・運用代行には、実は出口が2つあります。ずっと任せ続けるか、いずれ社内に引き取るかです。商談の場で、複数の会社から異口同音に聞く声があります。「保守を外注に握られ続けたくない」という懸念です。これは外部ベンダーへの不信ではなく、「外注に握られ続けると費用が永遠に発生する。数ヶ月かけて社内に引き取れるなら、そちらが安い」という合理的な計算です。

どちらの出口を選ぶかで、構築と保守の設計そのものが変わります。任せ続けるなら、外部が保守しやすい形（監視・ドキュメント・環境分離）に。引き取るなら、社内の担当者が触れる範囲を広く設計し、保守できる人を育てるところまでを契約に含める必要があります。私たちは後者の場合、引き渡し時に次を必ずセットで渡しています。

保守を「自分ごと」として設計する側の視点は、AIで作った業務ツールは、半年後に誰が直すのかに詳しく書いています。本記事が「任せる側」の記事だとすれば、あちらは「引き取る側」の記事です。

発注前に、業者へ聞く5つの質問

ここまでの要点を、発注前のベンダー選定で使える質問に整理しました。この5つに具体的な答えが返ってくるかどうかで、保守を任せられる相手かが分かります。

最後の質問に「精度は保証できません。その代わり──」と、2段階チェックや人の確認を挟む設計の話が返ってきたら、その業者は実運用を知っています。「AIなので大丈夫です」と返ってきたら、注意してください。

頼まない方がいいケース

最後に、保守・運用代行が要らないケースも書いておきます。

逆に、Automation・外部連携・生成AIのどれかが入っていて、構造を触る人が3人以上いるなら、誰かが面倒を見る体制は必須です。それが社内の担当者なのか、外部なのかを、この記事の線引きで決めてください。

まとめ──「何を頼むか」より先に「どこで線を引くか」

構築の発注前ならAirtable開発会社の選び方と外注する前に用意するものも併せてどうぞ。