Helper CTO シリーズ 10｜御社の AI 製品にバックアップはありますか：データベースとファイルの最低基準

「バックアップですか。ホスティング会社がやってくれてるはずですよね」。「はず」という言葉を聞くたびに、私たちはたいてい答えが「していない」だとわかります。その代償は何でしょうか。よくある光景として、ある日データベースのレコードが誤って削除され、あちこち探した結果、最新のバックアップが半年前のものしかなく、しかもそれが開くかどうか誰も試したことがなかった、というケースがあります。データを軽視しているわけではありません。バックアップはこれまで一度も「機能」として扱われてこなかったため、製品を作るときに AI にそれも一緒にやらせようと思いつく人がいなかっただけです。以下の 3 つの誤解は、私たちが引き継ぐときに最初に崩すものです。

バックアップに関する 3 つの誤解

• 誤解 1：ホスティング会社がバックアップしてくれている。多くのホスティング会社が提供しているのは「スナップショット」です。デフォルトでオフになっている場合があり、サーバーと同じ場所に保存されており（そのホスティング会社の拠点が障害を起こせば一緒に失われます）、しかもマシン全体単位なので、その中から特定の注文だけを取り出すのは大変な手間です。ホスティング会社が責任を持つのはマシンが動き続けることであり、御社のデータが無事であることではありません。
• 誤解 2：Git があればバックアップになっている。Git が保存するのはプログラムであり、データではありません。顧客リスト、注文、ユーザーがアップロードした写真はそこには含まれません。コードは失っても書き直せますが、データは失うと元に戻せません。
• 誤解 3：バックアップがあれば必ず復元できる。バックアップファイルが存在することは、それが完全であることも、壊れていないことも、それを使える状態のシステムに戻す方法を誰かが知っていることも意味しません。

データベースとアップロードファイルは別物

システムのデータは通常 2 種類に分かれ、バックアップも別々に扱う必要があります。

• データベース：顧客、注文、設定、ログといった構造化されたデータです。常に変化し続ける一体のものであり、定期的にデータベース全体を 1 つのファイルにエクスポートする方法が取られます。
• アップロードファイル：ユーザーがアップロードした画像、文書、動画です。これらはサーバー上のフォルダやクラウドストレージに散らばっており、データベースには「ファイルがどこにあるか」だけが記録され、ファイル自体は保存されません。

データベースだけをバックアップしていると、復元後は注文データはすべて残っているのに商品画像はすべて壊れます。ファイルだけをバックアップしていると、復元後は画像はすべて残っているのに、どれが誰のものかわからなくなります。Vibe Coding と本当のシステムアーキテクチャの差という記事はまさにこの話です。AI で作られた製品では、データがどこに保存されているかは「その時々で都合のよい場所」であることが多いため、バックアップする前にまずデータが何か所に散らばっているかを把握する必要があります。

最低限の基準：4 項目

エンタープライズ級の対応ではなく、実際の顧客がいる製品であれば当然備えるべき最低ラインです。

• 頻度はデータ量に応じて決めます。1 日 1 回なら最悪でも 1 日分の損失で済みますが、データ量が多ければ頻度を上げる必要があります。
• 別の場所に保存したバックアップも、誰がアクセスできるか管理する必要があります。そのファイルには御社の全顧客のデータが入っています。
• バックアップファイル自体が情報漏洩の原因になり得ます。AI が書いたコードが最も踏みやすいセキュリティの地雷という記事で触れた鍵と同じで、保存場所を誤ればそのまま渡してしまうことになります。

復元を試して初めてバックアップと言える

バックアップは静かに失敗します。スケジュールが止まっていても誰も気づかない、容量不足でバックアップファイルが途中で切れている、データベースのパスワードを変更したのにバックアップスクリプトが更新されていない、バックアップの保存先が後で閉鎖されたアカウントだった、といった具合です。どの場合も「バックアップファイルはある」ように見え、実際に必要になった日に初めて開かないことに気づきます。復元テストは難しいものではなく、大事なのは本当にやることです。

• 本番環境とは無関係な場所を用意し、直近のバックアップをそこに復元してみる。
• ログインして最近のデータを数件抜き取り、内容が正しいか確認する。
• 画像やアップロードファイルをいくつか開いて、表示できるか確認する。
• 今回の復元にかかった時間を記録しておく。それが何かあったときに顧客が待たされる時間です。

復元テストはもうひとつのことも確認しています。誰かがやり方を知っているかどうかです。わかる人がひとりしかおらず、手順も書かれていないなら、それはバックアップと単一障害点をセットで抱えているのと同じです。この 4 項目はどれも単体では難しくありませんが、難しいのは「毎日」「四半期ごと」といった継続することです。製品を作る側は次の機能のことを考えており、バックアップは 100 回うまくいっても気づかれず、できなかった 1 回だけが記憶に残ります。

Nerdtechnic（恩梯科技）はバックアップを保守の基本項目として扱います

• バックアップは追加料金のサービスではありません。監視やセキュリティ更新とともに基本保守に含まれ、NT$6,000／月から、月ごとに請求で止めたいときにいつでも止められます。
• 引き継ぎの最初の週に補います。これはデモができることと公開できることは違うという記事で紹介した補う順番の中で最初に来る項目です。やらなかった場合の結果が取り返しのつかないものだからです。
• 動いていることを証明できます。サーバーやサービスに問題が起きたら 1 営業日以内に対応し、バックアップと復元の状況は記録に残し、契約終了時にはそれも一緒にお渡しします。

システムを任された人が、バックアップの責任も負うべきです。そして復元できることを証明できなければなりません。

バックアップは、私たちが Helper CTO としてシステムを引き継ぐとき、最初の週に必ず補う項目です。会社の技術責任者のような存在でありながら御社の社員ではなく、引き継ぎ・保守・改善は同じチームが担当します。最初の一歩は 60 分のシステム健診です。コードを見せていただくだけでよく、本番環境のアカウント情報は不要です。3～5 営業日以内に 1 ページのレポートをお渡しし、その中の 1 項目としてバックアップの現状も記載します。「前回のバックアップがいつか」すら答えられない状態であれば、まずはこちらからどうぞ：Helper CTO：システム保守プラン。