この記事の結論：「保存できた」と「永続保存できた」は別です。Cloud Runのローカルファイルは、消えてはいけないデータの保存先として使わないことが重要です。

Cloud RunでWebアプリや業務アプリを公開し、「データの保存までできた」と安心していたところ、修正して再デプロイした後にデータが消えてしまった。そんな経験をすると、「Cloud Runではデータを保存できないのか？」「コードを直したら、なぜ入力済みのデータまでなくなったのか？」と戸惑うかもしれません。

私自身、AIを使いながら診断アプリを開発していた際に、この問題を経験しました。管理者画面で使用する情報や診断回答データを保存し、画面上でも読み出せていたため、当初は「保存機能は完成した」と考えていました。ところが、アプリを修正してCloud Runへ再デプロイすると、それまで保存されていた情報が消えてしまったのです。

原因を調べたところ、重要なデータをFirestoreなどの永続的なデータベースではなく、Cloud Runで動作しているコンテナ内のローカルファイルへ保存していたことが分かりました。そこで保存先をFirestoreへ変更し、再デプロイ後もデータを読み出せる構成へ変更しました。

Cloud Runでは、コンテナのファイルシステムへ書き込むこと自体は可能です。しかし、Google Cloudの公式ドキュメントでは、そのファイルシステムはメモリ上にあり、インスタンスが停止すると書き込んだデータは保持されないことが説明されています。この記事では、Cloud Runで保存したデータが消える理由と、Firestore・Cloud SQL・Cloud Storageをどのように使い分ければよいのかを、プログラミングの専門知識がない経営者や担当者にも分かる言葉で解説します。

Cloud Runで保存したデータが消えるのはなぜ？

最初に結論から言うと、Cloud Runのコンテナ内へ保存したファイルは、長期間残すことを前提とした保存場所ではないからです。Cloud Runは、Webアプリケーションなどをコンテナとして実行するサービスです。利用者からアクセスがあれば必要に応じてインスタンスが起動し、状況によって増減したり停止したりします。

Cloud Runのローカルファイルは永続ストレージではない

例えば、自分のパソコンでcustomer.json、settings.json、answers.json、admin.txtなどのファイルを保存したとします。通常のパソコンであれば、電源を切って再び立ち上げても、ハードディスクやSSDに保存されたファイルは残っています。そのため、「ファイルに書き込んだのだから保存された」と考えるのは自然です。

しかしCloud Runのコンテナ内ファイルシステムは、この感覚とは異なります。Google Cloudの公式仕様では、Cloud Runコンテナのファイルシステムは書き込み可能ですが、インメモリのファイルシステムであり、インスタンス停止時には書き込んだデータが永続化されません。つまり、「ファイルを書き込める」ことと、「そのファイルが将来も残っている」ことは別問題です。

「保存できた」ため問題に気づきにくい

Cloud Runのローカル保存で厄介なのは、保存処理そのものが失敗するとは限らないことです。例えば、診断フォームへ回答し、その内容をJSONファイルへ保存し、同じ環境で管理画面から読み込めれば、利用者から見ると正常に動いているように見えます。

しかし実際には、現在動いているCloud Runのインスタンスの中に一時的に存在しているだけという可能性があります。だからこそ、「保存しました」という画面表示だけでは永続化できたことを確認できません。

再デプロイしなければ消えないわけではない

私の場合は、再デプロイしたことをきっかけに問題が発覚しました。しかし、「では再デプロイしなければ安全なのでは？」と考えるのも危険です。Cloud Runのインスタンスは、常に同じ1台が動き続けることを前提としていません。

したがって判断基準は、再デプロイするかどうかではありません。そのデータが消えてよいのか、消えてはいけないのかで考える必要があります。

「保存できた」と「永続保存できた」は別

Cloud Runでデータを扱うときに、最も重要なのがこの考え方です。「保存できた」と「永続保存できた」は別です。この違いを理解するだけで、AIを使ったアプリ開発でも多くのトラブルを防ぎやすくなります。

保存直後に読み出せただけでは不十分

例えば、管理者パスワードを登録する機能を作り、登録後に「パスワードを保存しました」と表示され、管理画面から問題なくログインできたとします。ここまで確認すると、普通は完成したと思います。

しかし確認すべきなのは、その先です。Cloud Runのインスタンスが変わったらどうなるか、再デプロイしたらどうなるか、新しいリビジョンへ切り替わったらどうなるか、数日後にアクセスしても読み出せるかまで考える必要があります。

永続保存とは「環境が変わっても必要なデータを取得できる」こと

非エンジニア向けに単純化すると、永続保存とは、アプリを動かしている場所が入れ替わっても、必要なデータをもう一度取得できる状態と考えると分かりやすいでしょう。

Cloud Runは「アプリを動かす場所」、FirestoreやCloud SQL、Cloud Storageなどは「残しておくデータを保管する場所」と役割を分けて考えることが重要です。

実際に起きた失敗｜管理者パスワードと診断回答が消えた

ここからは、私自身がAIを使って診断アプリを開発した際に経験した内容を紹介します。今回の失敗は、特別に高度な開発をしていたから起きたわけではありません。むしろ、AIと会話しながらアプリを作れるようになった今だからこそ、非エンジニアにも起こりやすい問題だと感じています。

最初はローカルファイルへ保存していた

開発していた診断アプリには、質問への回答、診断結果の表示、PDF生成、顧客データの保存、管理者画面などの機能がありました。さらに管理者機能として、管理者用の情報も保存する必要がありました。

画面上では正常に登録でき、再読み込みしても情報が表示されていました。そのため当初は「保存処理も完成した」と判断していました。ところが実際には、一部のデータがCloud Runコンテナ内のローカルファイルへ保存される構成になっていました。

保存直後は問題なく使えていた

保存方法が適切でなかったにもかかわらず、開発中は正常に動いていました。登録できる。読み出せる。管理画面にも表示される。そのため、見た目だけでは問題に気づけません。

AIに「診断回答を保存できるようにしてください」と依頼して、実際に回答が保存できれば、つい次の開発へ進んでしまいます。しかし本来確認すべきなのは、「どこへ保存したのか」です。

再デプロイしたところデータが消えた

その後、別の機能を修正してCloud Runへ再デプロイしました。Cloud Runでは新たなデプロイによって新しいリビジョンが作成されます。そして本番環境を確認すると、それまで登録していた情報がなくなっていました。

最初は「コードの修正でデータを消してしまったのか？」「データ読込処理を壊したのか？」と考えました。しかし調べていくと、そもそも消えてはいけないデータをCloud Runコンテナのローカルファイルへ保存していたことが原因だと分かりました。

Firestoreへ移行して解決した

そこで、再デプロイ後も残す必要があるデータをFirestoreへ保存する構成へ変更しました。Cloud Firestoreは、ドキュメントとコレクションを使ってデータを保存するクラウド型のデータベースです。

考え方としては、「Cloud Run＝アプリケーションを動かす」「Firestore＝残したいアプリケーションデータを保存する」と役割を分けました。この変更後は、Cloud Runを再デプロイしても、Firestoreに保存されたデータを再び読み出せる構成にできました。

Cloud Runでは何をどこへ保存すればよい？

「ではCloud Runを使うなら全部Firestoreへ保存すればよいのか？」という疑問が出てきます。答えは、必ずしもそうではありません。保存したいものによって、適した保存先が異なります。

Firestore、Cloud SQL、Cloud Storageは単純に「どれが一番優れているか」で選ぶものではありません。何を保存したいのかで選びます。

Firestoreが向いているデータ

フォーム回答や診断結果

例えば診断アプリなら、回答者ID、回答日時、各質問への回答、診断結果、ステータスなどを保存できます。「1件の診断」というまとまりでデータを扱いやすいケースでは、Firestoreを検討しやすいでしょう。

ユーザー設定やアプリ設定

通知設定、表示設定、管理画面設定、ユーザーごとの状態なども、再起動や再デプロイ後まで残す必要があります。こうした情報をCloud Runのローカルファイルだけに保存していると、いつ失われるか分かりません。

管理画面から検索・更新するデータ

単に「保存する」だけでなく、管理画面へ一覧表示する、条件で検索する、ステータスを変更する、後から修正するといったデータも、アプリ本体とは切り離して永続的な保存先を用意した方が管理しやすくなります。

Cloud SQLが向いているデータ

複数の表の関係が重要な業務システム

例えば、顧客→契約→請求→入金という関係がある業務システムを考えてみます。「どの顧客が、どの契約を持ち、その契約にどの請求があり、どの入金と結びついているか」という関係性が重要です。このようなデータでは、リレーショナルデータベースが向いている場合があります。

既存システムがSQL前提の場合

すでに社内でMySQLやPostgreSQLなどを利用している場合や、既存のアプリケーションがSQLを前提に設計されている場合も、Cloud SQLが候補になります。重要なのは、FirestoreとCloud SQLのどちらが上かではありません。業務データの構造や、既存システムとの関係で選ぶことです。

Cloud Storageが向いているデータ

PDF・画像・CSVなどのファイル

例えば診断アプリで、診断回答→診断結果を計算→PDF生成→利用者へ提供という処理があるとします。生成したPDFをその場でダウンロードさせるだけで、後から再利用しないのであれば、一時ファイルとして扱えるケースもあります。

一方、「管理画面から後でPDFを再ダウンロードしたい」のであれば、PDFそのものを残しておく必要があります。その場合、Cloud Storageへ保存する方法を検討できます。

DBに何でも入れればよいわけではない

例えば、診断者名、診断日時、診断結果、PDFの保存場所といった情報はデータベースで管理し、PDF本体はCloud Storageへ保存する、というように役割を分けることもできます。「保存」という言葉だけで一括りにせず、データなのか、ファイルなのかを区別することが大切です。

Cloud Run内に一時保存してよいデータもある

ここまで読むと、「Cloud Runのローカルファイルは一切使ってはいけない」と思うかもしれません。しかし、それも違います。Cloud Run内のファイルシステムは一時的な処理には利用できます。重要なのは、消えても困らないデータだけにすることです。

処理途中だけ必要な一時ファイル

例えば、データを取得し、一時ファイルへ書き出し、PDFへ変換し、利用者へ送信した後に一時ファイルが不要になる処理なら、処理途中のファイルを一時的に置くことは考えられます。

再生成できるキャッシュ

一度消えても、元のデータから再生成できるものであれば、一時的な保存で問題ない場合があります。

リクエスト終了後に不要になるもの

変換処理や集計処理のためだけに必要で、処理が終わったら不要になるデータもあります。つまり判断基準はとても簡単です。「このデータが突然消えたら困るか？」困るのであれば、Cloud Runのローカルファイルだけを保存先にしない。困らないのであれば、一時領域として活用する余地があります。

永続保存できているかは「再デプロイテスト」で確認する

検証手順：保存 → 確認 → 再デプロイ → もう一度確認

保存方法を修正したら、「今読み出せているから大丈夫」で終わらせないことが重要です。私がおすすめしたいのは、上記の4段階をセットで行うことです。

ステップ1｜データを保存する

まず、テスト用のデータを登録します。テストユーザー、テスト回答、管理者設定、テスト用ステータスなど、後から確認しやすいデータがよいでしょう。本番の重要データを使う必要はありません。

ステップ2｜保存されたことを確認する

次に、管理画面や確認画面からデータを読み出します。ここで表示できても、まだテスト完了ではありません。この段階で確認できたのは、「今動いている環境では読み書きできた」ということだけです。

ステップ3｜Cloud Runを再デプロイする

次に、Cloud Runへもう一度デプロイします。Cloud Runではデプロイによって新しいリビジョンが作られます。実際の開発ではコード修正が頻繁に発生します。したがって、「デプロイし直してもデータが残るか」は本番運用上、非常に重要な確認です。

ステップ4｜もう一度データを確認する

再デプロイ後、本番URLへアクセスします。そして先ほど登録したテストデータが読み出せるか確認します。残っていれば、「少なくとも再デプロイ後にも外部保存先から取得できている」と確認できます。

もちろん本格的なシステムでは、バックアップ、権限、障害対策、データ削除などさらに多くの確認が必要です。しかし非エンジニアがAIとアプリを作る際でも、「保存→確認→再デプロイ→もう一度確認」だけは最低限のチェックとして取り入れる価値があります。

AIにアプリ開発を任せるときこそ「保存先」を確認する

生成AIの進歩によって、プログラミング経験が少ない人でもWebアプリや社内ツールを作れるようになりました。一方で、今回のような問題も起きやすくなります。なぜなら非エンジニアは、コードが動いたかは確認できても、そのコードがどのような設計になっているかまでは確認しにくいからです。

「保存機能を作って」で終わらせない

AIに「フォームの回答を保存してください」と依頼し、AIがコードを書き、実際に回答が保存された。ここで「完成した」と思ってしまいがちです。しかしAIへの依頼では、もう一段掘り下げることをおすすめします。

• このデータはどこへ保存されていますか？
• Cloud Runのローカルファイルですか？
• インスタンスが停止しても残りますか？
• 再デプロイしても残りますか？
• 永続保存先は何ですか？
• Firestoreなど外部のデータベースを利用していますか？

「どこに保存している？」まで確認する

これはデータ保存に限った話ではありません。AI開発では、「できました」という結果の裏側を確認する習慣が重要です。メール送信できたならどのサービスを使っているのか、ログインできたなら認証情報をどのように管理しているのか、PDFを作れたなら一時生成なのか保存されるのか、と確認します。

AIを単なるコード生成ツールとして使うのではなく、開発について質問できる相手として利用すると、非エンジニアでも設計上の問題に気づきやすくなります。

「今動く」と「環境が変わっても残る」は別

ここでも大切なのは、今動く＝完成ではないという考え方です。開発中の確認では、今動くか、再起動後も動くか、再デプロイ後も動くか、本番環境でも動くか、データが残るかまで視野に入れる必要があります。

AIが便利になればなるほど、人間側には、「何をもって完成とするのか」を決める力が重要になります。

Cloud Runでデータが消えないようにするチェックリスト

• □ 消えたら困るデータを洗い出しているか
• □ それぞれのデータがどこへ保存されているか把握しているか
• □ Cloud Runのローカルファイルだけに重要データを保存していないか
• □ 回答や設定などのアプリデータは適切なDBへ保存しているか
• □ PDF・画像などのファイルは必要に応じて外部ストレージへ保存しているか
• □ 一時ファイルと永続データを区別しているか
• □ 保存後に再読み込みして確認したか
• □ 再デプロイ後にもう一度データを確認したか
• □ AIに「どこへ保存しているか」を質問したか
• □ 本番運用前にバックアップやアクセス権限についても確認したか

特に非エンジニアの場合、「コードを全部理解しなければならない」と考える必要はありません。まずは、「この情報はどこにあるのか？」「その場所はなくならないのか？」と質問することから始めるだけでも、大きく違います。

よくある質問

Cloud Runではファイルを保存できないのですか？

保存すること自体はできます。Cloud Runのコンテナファイルシステムは書き込み可能です。ただし、インスタンス停止後には書き込んだデータが保持されません。したがって、消えてはいけない情報の永続保存先としてローカルファイルだけを使うのは避ける必要があります。

再デプロイしなければデータは消えませんか？

再デプロイしなければ安全、という意味ではありません。Cloud Runのインスタンスは状況に応じて停止される可能性があります。重要データは外部の永続保存先を利用する必要があります。

FirestoreとCloud SQLはどちらを選べばよいですか？

用途によって異なります。Firestoreはドキュメント型のデータを扱うアプリケーションに適した選択肢です。一方、Cloud SQLはMySQL・PostgreSQL・SQL Serverを利用するリレーショナルデータベースサービスです。顧客・契約・請求など、表同士の関係性を重視する業務システムではCloud SQLが候補になる場合があります。

PDFはFirestoreへ保存した方がよいですか？

PDFや画像などのファイル本体を永続保存したい場合は、Cloud Storageなどのオブジェクトストレージが候補になります。診断結果のデータとPDF本体を別々に管理する設計も考えられます。

AIが作ったアプリでもFirestoreへ変更できますか？

アプリの設計や現在の保存方法によりますが、保存処理を外部データベースへ変更することは可能です。ただし、データ構造、認証、アクセス権限、既存データの移行なども確認する必要があります。AIへ修正を依頼する場合も、「再デプロイ後もデータを取得できること」を完了条件として伝えることが重要です。

まとめ｜Cloud Runでは「保存先」まで設計して初めて完成

Cloud Runで保存したデータが消える問題を理解するうえで、最も大切なのは、「保存できた」と「永続保存できた」は別と知ることです。

診断回答、顧客データ、管理者設定、ユーザー情報、後から必要になるPDFや画像など、消えてはいけない情報については、用途に合わせてFirestore・Cloud SQL・Cloud Storageなどの永続的な保存先を検討する必要があります。

そして保存機能を作ったら、「保存→確認→再デプロイ→もう一度確認」まで行いましょう。AIにアプリを作ってもらう場合も、「保存できるようにしてください」だけで終わらせず、「そのデータはどこに保存されていますか？」と確認してください。

AI時代のアプリ開発では、すべてのコードを書けること以上に、何を確認すべきかを知っていることが重要です。「今動いているから大丈夫」ではなく、環境が変わっても必要なデータが残るところまで確認して、初めて保存機能は完成したと考えることをおすすめします。

相談の目安：「自社でもAIを使って業務アプリを作ってみたい」「試作したアプリを本番運用してよいか判断できない」「どこまで自分で作り、どこから専門家へ相談すべきか整理したい」という場合は、まず現在の業務と作りたい仕組みを整理するところから始めてみてください。

AI・業務アプリ開発について相談する

AI・業務アプリ開発について相談する

参考情報（公式ドキュメント）

• Cloud Run Container runtime contract
• Deploying container images to Cloud Run
• Cloud Firestore documentation
• Cloud SQL overview
• Cloud Storage overview

参考リンク

• Cloud Run コンテナ ランタイムの契約（Google Cloud 公式）
• Cloud Run コンテナイメージのデプロイ（Google Cloud 公式）
• Cloud Firestore ドキュメント（Firebase 公式）