AIで作ったアプリをバックアップする方法 — そして、なぜ本当に必要なのか

私がよく話す起業家の一人は、予約ビジネス全体 — 3拠点、週におよそ200人の顧客 — を、AIアプリビルダーで自分で作ったアプリで回しています。ある火曜日に彼はそれを見せてくれて、とても誇らしげでした。水曜日に彼は、少し不安げに私に尋ねました。「これが壊れたら、僕はただ……全部失うのかな？」

正直な答えはこうでした。たぶん。「壊れる」が何を意味するかによる。どんなバックアップを持っているかによる（彼は持っていませんでした）。間に合うように作り直せるかによる、と。

その会話は、AIでアプリを作った人々と私が交わす、最もありふれた会話です。作ること自体は小さな奇跡のように感じられます。「もしそれが消えたらどうなる」という問いは、アプリがすでに本物の仕事をするようになるまで、ほとんど出てきません — そしてそのころには、それを失うことの結果は深刻になっているのです。

この記事は、自分でコードを書かずに本物の動くアプリを作り、今は何か大事なことをそれに頼っているすべての人のためのものです。実際に何がリスクにさらされているか、何をバックアップするか、どのくらいの頻度で、そして何かがうまくいかなくなったときに何をするかを扱います。技術的ではありません。実行するスクリプトもありません。ゴールは、何を作ったにせよ、「バックアップというものがあると誰も教えてくれなかったから」という理由でそれを失わないようにすることです。

AIで作ったアプリの中には実際何が入っているか（そして何が消えうるか）

AIで作ったアプリは、二つのまったく異なるものでできていて、それぞれを別々にバックアップする必要があります。

一つめはアプリそのもの — 画面、ロジック、デザイン、連携です。これはAIビルダーがあなたのために生成したもの。たいていはプロジェクトの中の、AIビルダーのアカウントに存在します。そのアカウントへのアクセスを失ったり、ビルダーに障害が起きたり、プロジェクトが壊れたりすると、これを失います。

二つめはあなたのデータ — ユーザー、注文、メッセージ、予約、人々がアップロードしたファイルです。これはたいてい、どこかのデータベースに存在します。AIビルダーの中にあることもあります。Supabase、Firebase、Airtable のようなサービスにあることもあります。複数の場所に散らばっていることもあります。

この二つは、まったく異なるリスクの性質を持っています。アプリの構造は、AIに変えてくれと頼んだときに変わります。あなたのデータは、ユーザーが何かをするたびに変わります。だから、別々のバックアップ戦略が必要なのです。

役立つ考え方：もし建物が焼け落ちたら、アプリは設計図で、データは焼けたときに建物の中にあったものです。設計図からは建て直せます。中にあったものは取り戻せません。

何がリスクか：実際に起きる4つのシナリオ

これらのそれぞれが、AIアプリビルダーで作っている人々に起きるのを見てきました。どれも机上の空論ではありません。

1. うっかりAIにアプリを壊させる。 疲れていて、深夜に作業していて、「ユーザー登録ページを削除して」と言います。作り直したいからです。AIは削除します。同時に、既存のユーザーがログインできる部分も削除してしまいます。今や誰もアプリを使えず、バージョン履歴をオンにしていない限り、AIの最後に動いていたバージョンは消えています（多くのビルダーは、初期設定ではオンになっていません）。

2. AIビルダーに障害やデータの問題が起きる。 まれですが、現実です。2024年、ある人気のノーコードプラットフォームで、顧客データにアクセスできなくなる6時間の障害がありました。誰も恒久的にデータを失いはしませんでしたが、多くのビジネスが1日を失いました。土曜の朝、顧客が土曜の午後を予約しようとしているときに予約アプリがダウンしていたら、それは「データ損失なし」ではありません — それは取り戻せない失われた売上です。

3. アカウントがロックされる。 課金の問題かもしれない、新しい場所からのログインがフラグされたのかもしれない、反映されなかったメール変更かもしれない。アプリは無事、データも無事、でもあなたが入れません。エクスポートしたコピーがなければ、サポートの応答速度に身を委ねるしかありません。

4. プラットフォームを離れる。 これは人々が計画しないものです。1年後、別のツールに移りたくなるかもしれないし、作ったものを引き継ぐ開発者を雇いたくなるかもしれません。アプリとデータの唯一のコピーが一つのビルダーの中にしか存在しなければ、選択肢は狭く、高くつきます。

これらのどのシナリオでも、「煩わしい」と「破滅的」の違いは、バックアップを持っていたかどうかです。

何を、どのくらいの頻度でバックアップするか

凝ったシステムは要りません。必要なのは習慣です。コードを書かずにAIで作っている人に、最低限これを勧めます。

データ — 毎日、できれば自動で。

データが Supabase や Airtable のようなものに存在するなら、どちらも定期エクスポートやバックアップを提供しています。これをオンにしてください。たいていの人は飛ばします。3クリックで済むうえ「あとでやればいい」と思うからです。ローンチした日にやりましょう。

データがAIビルダーそのものの中にあって自動エクスポートがないなら、毎週日曜にカレンダーのリマインダーを設定して手動でエクスポートしましょう。テーブルごとに CSV としてエクスポートします。ビルダーの外のどこかに保存しましょう — Google Drive、Dropbox、外付けハードドライブ。同じサービス以外のどこかに。

これらのエクスポートを少なくとも4週間ぶん保ちましょう。毎回同じファイルを上書きしないこと。火曜にデータが壊れて金曜まで気づかなかったら、唯一のバックアップが金曜のすでに壊れたデータであってほしくありません。

アプリの構造 — 重要な変更を加えるたびに。

たいていのAIアプリビルダーは、何らかのバージョン履歴やスナップショットの機能を持っています。この機能を見つけてください。使いましょう。アプリに大きな変更を加える前に — 「大きい」とは「1時間で記憶から作り直せないもの」という意味です — 名前付きのスナップショットを取りましょう。「決済画面の追加前」や「ユーザーロールの変更前」のような、役立つ名前を付けます。

ビルダーにスナップショットがないなら、AIにアプリが何をするかを長い文書にまとめさせましょう。その文書を保存します。アプリの本物のバックアップではありませんが、それはレシピです — 最悪のことが起きたら、その文書を作り直すためのプロンプトとして使えます。

アカウントと認証情報 — 一度、ローンチした日に。

すべてがどこにあるかを、一か所に書き留めましょう。どのビルダーアカウントにアプリがあるか。どのデータベースサービスにデータがあるか。どのメールが管理者のログインか。どの決済代行が接続されているか。どの連携が接続されているか。

これを Google Doc ではなく、パスワードマネージャーに保存しましょう。明日あなたがバスにはねられたら、ビジネスパートナーはこれらすべてを見つけられる必要があります。一人で起業しているなら、未来のあなた（半年後、疲れ果てて、ローンチ時に何をしたか思い出そうとしている）も、これを見つけられる必要があります。

ファイル — ユーザーがアップロードする先のどこか。

アプリがファイルのアップロードを受け付けるなら — 画像、PDF、何でも — それらのファイルはどこかに存在します。どこか見つけましょう。たいていのビルダーは何らかのストレージバケットを使っています。それがバックアップされているか確認しましょう。されていなければ、自分のストレージへの定期コピーを設定しましょう。

週に20分ほどで済む、シンプルなバックアップの習慣

日曜の夕方、どのみち仕事をしていない時間に：

AIビルダーを開く。現在のアプリの状態の名前付きスナップショットを取る。日付を付ける。
各データテーブルを CSV としてエクスポートする。クラウドストレージの日付付きフォルダに入れる。（たいていデータは3〜10個のテーブルに収まる — 大した作業ではありません。）
ストレージバケットをちらっと見る。変なことが起きていないか確認する（ファイル数の急増、怪しいアップロード）。
今週何かが変わったなら「すべてがどこにあるか」の文書を更新する。

それだけです。20分、週に一度。それが守るものに対して、桁外れに割に合う保険です。

これを手動でやりたくないなら、データがネイティブのバックアップを備えたどこかにあるか調べましょう。たとえば Supabase は、自動の日次バックアップをやってくれます。無料プランを使っているなら、それらのバックアップは制限されます。有料プランなら、より長くさかのぼれます。アプリに依存するビジネスにとって、その有料プランはあなたが買う中でいちばん安い保険です。

何かがうまくいかなくなったときに何をするか

AIビルダーのバグや悪い変更でアプリが壊れたら：

慌ててプロンプトを打たない。 本能は、すぐにAIに直してくれと頼むことです。これを10分こらえてください。間違った方向への慌てた修正は事態を悪化させかねず、たいていのビルダーは一連のプロンプトを簡単には取り消せません。
最後のスナップショットにロールバックする。 持っていれば。それを取った理由はまさにこれです。
スナップショットがないなら、AIビルダーに直近の特定の変更を元に戻すよう頼みましょう。正確に。「登録ページを削除した変更を元に戻して」は「また動くようにして」よりも良いです。

データが壊れたら：

すぐに書き込みを止める。 できるならアプリをオフラインにします。データが壊れている間の新しいユーザー操作は一つひとつ、あとで突き合わせる必要のあるデータが増えるということです。
直近の良いバックアップから復元する。 どれが良いか分からないなら、最後のきれいなバージョンが見つかるまで、環境のコピーに一つずつ復元していきます。
欠けているものを突き合わせる。 金曜に日曜のバックアップを復元したら、5日分の活動を失っています。影響を受けたユーザーにメールし、やったことをやり直すようお願いし、謝りましょう。正直で素早く対応すれば、人は驚くほど理解してくれます。

アカウントへのアクセスを失ったら：

すぐにサポートに連絡する。 「自然に直るのを待つ」としないこと。ビルダーのサポート待ち時間はまちまちです。素晴らしいものもあれば、遅いものもあります。
本人確認の準備を整える。 登録時のメール、課金カードの詳細、サインアップした日付、古い請求書。これらなしのアカウント復旧は困難です。

あの起業家に誰も教えなかったこと

冒頭の予約ビジネスの起業家は、話したあとでデータサービスの有料プランを買いました。自動の日次バックアップを設定しました。アプリのスナップショットを取りました。パスワードマネージャーにすべてのアカウントを書き留めました。全部で、日曜の1時間ほどでした。

1か月後、彼が頼んだAIの変更が、うっかり繰り返し予約のロジックを壊してしまいました。顧客が次の予約を見られなくなったのです。彼は20分以内に気づきました。2クリックでスナップショットを復元しました。データを保ち、アプリを保ち、顧客は何も目にしませんでした。

あとで彼は、それは今までで最も安い1時間だったと言いました。間違っていません。AIで作ったアプリのバックアップは、設定に1時間ほど、習慣として週に20分ほどです。それが守るものは、失った人の誰もが自分には起きないと思っていたものなのです。

本物の何かを作ったなら、今日スナップショットを取りましょう。