Gemini Canvasで作ったアプリ、その共有リンクをそのまま職場に配って大丈夫?と思ったことはありませんか?
Gemini Canvasでアプリを作って、できあがった共有リンクをそのまま同僚に送ったり、「入力したデータが消えないようにして」とGeminiにお願いしたことはないでしょうか。
問題は「Canvasでアプリを作ること」ではありません。
「そのデータがどこに保存されているのか」「誰が見られる状態なのか」
ここを確認しないまま業務利用を始めてしまうことが、情報管理上の事故につながりやすいポイントです。
この記事では、Gemini Canvasで作ったアプリを職場で使う場合に知っておきたい「データをどこに置くのか」「誰に見せるのか」の基本について、解説していきます。
「Firestore」「Firebase Hosting」「Security Rules」といった言葉が出てくるので、一見難しく感じるかもしれませんが、意外とシンプルなので大丈夫です。
現場で実際によく聞かれること

Googleを活用したAI活用では、Canvasまわりで似た質問が出てきます。
よくある質問
「アプリはできたんですけど、どこに置けば職員に使ってもらえますか」
「昨日入力した内容がなくなっていました。保存されないんですか」
「共有リンクを配ったんですが、ここに利用者さんの情報を入れても大丈夫ですか」
特に最後の質問は、特に慎重に考える必要があります。
まず考えなければいけないのが、
「作る」
「配る」
「データをためる」
この3つは、それぞれ別だということここを整理すると、Firebaseの話もかなり理解しやすくなるので、次からはこの3つについてわかりやすく解説していきます。
GASを使った業務効率化の記事の人気です。ぜひご覧ください
-
-
参考【GAS超入門】GeminiとGoogle Apps Scriptで知識ゼロからウェブアプリを作る
「プログラミングって、なんだか難しそう…」 「完璧な設計図とか、サーバーの知識とか、覚えることが多すぎる…」もしあなたがそう感じているなら、その考えは不要です。設計図なんていりません。 ...
続きを見る
GeminiとFirebaseの関係を「3つの層」で考える

① Gemini Canvas=つくる場所
GeminiのCanvasでは、日本語で指示しながらアプリやコードを作成できます。アプリの変更は自動的に保存され、コードビューを開けば、生成されたコードを直接確認・編集することもできます。
たとえば「備品貸出を管理するアプリを作って」と入力するだけでも、画面や入力フォーム、一覧表示などをかなり短時間で形にできます。
Canvasはアイデアを動く形にする場所として非常に便利で、初心者がバイブコーディングする上でもとても使いやすいものとなっています。
② Firestore=データをためる場所
Gemini Canvasで複数のセッションや端末をまたいでデータを保存する必要のあるアプリを作ると、Gemini Apps側でFirestoreのデータベースが用意されます。
一言でいうと、「難しい設定を一切せずに、スマホとPCでデータを共有できる本格的なアプリが作れる」ということです。
通常、データを保存するアプリ(ToDoリストやゲームのセーブ機能など)を作るには、自分で専用のサーバーやデータベース(データを保存するオンライン上の引き出し)を契約して接続するプログラミングをする必要がありました。
ただこれをCanvasでは、すべて自動で行ってくれます。面倒なサーバー準備や接続設定を完全にスキップして、アイデアをそのまま「ちゃんと動いてデータが残るアプリ」にできるのが一番の凄さです。
ちなみにFirestoreとは、GoogleのFirebaseというサービスに含まれている、インターネット上にデータを保存する仕組みです。
③ Firebase Hosting=アプリを配る場所
Firebase Hostingは、HTMLやCSS、JavaScriptなどで作ったWebアプリをインターネット上に公開するためのサービスです。
わかりやすく言えば「自分で作ったWebサイトやアプリを、インターネット上に一瞬で安全に公開できるGoogleの『置き場(ホスティング)』サービス」になります。
チェックリスト
-
標準で高セキュリティ:無料で自動的にSSL化(
https://)され、暗号化通信が行われます -
圧倒的な配信スピード:Googleの配信ネットワーク(CDN)に乗るため、どこからでもサクサク動きます
-
確実な管理権限:データの保存先やアクセスできる人の範囲を、自分たちで自由にコントロールできます
Canvasで作ったアプリを共有リンクで使い続けるのは、いわば「作業机の上の試作品を、そのままお客さんに触らせている状態」です。
業務で長く安全に運用するなら、プロトタイプから一歩進めて、自分たちの管理下に置ける「Firebase Hosting」へ移行することをおすすめします。
Canvasから正式運用へ移す5つのステップ

Gemini Canvasで作ったアプリを、安全かつスムーズに社内本番へ持っていくための5ステップを優しく整理しました。
Step① Canvasでアプリの「試作品」を作る
最初から完成形を目指す必要はありません。まずは「本当に業務で使えるか」「どんな項目が必要か」を試す試作品(プロトタイプ)を作りましょう。
ポイントは、AIに「いい感じに作って」とお任せしないことです。AIが勝手に決めたルールが、そのまま業務ルールになってしまうのを防ぐため、決まっていない部分は「要確認」として残すよう指示します。
プロンプト例
役割:フロントエンドエンジニア
タスク:社内の備品貸出を記録するWebアプリを作成
(条件)
機能は「備品登録」「貸出者入力」「日付記録」「一覧表示」「返却変更」のみ
後からFirestore(データベース)へ変更しやすい構造にする
入力漏れや日付の逆転時にはエラーを表示する
個人情報は使わず「担当A」などのサンプル値を使う
仕様が不明な箇所は勝手に作らず【要確認】とコメントする
Step② 保存されるデータを確認する(テストデータを使う)
Canvas上で作ったアプリのデータは、ブラウザの中(LocalStorageなど)に一時保存されているか、プログラム内に直接組み込まれていることがほとんどです。
この段階では、まだ安全な管理データベースには繋がっていません。
ここで一番大切なのは、試作段階で本物の個人情報や社内データを入れないことです。
コード共有時のリスクに注意
「共有とエクスポート」から「Google ドライブで共有」を選んで誰かにアプリを見せる際、コード内に本物のデータが残っているとそのまま見えてしまいます。
ダミーデータを徹底する
画面上の入力テストは、プログラム内にも「担当A」「サンプル商店」といった架空のデータだけを使うようにしましょう。
「コードを共有したら中身が丸見えになるかもしれない」という前提で、安全なダミーデータだけで動作確認を進めるのがポイントです。
アプリの使い勝手が確認できたら、次はいよいよ本物のデータを安全に保存できる場所を用意します。
Step③ 自分たちのFirebaseプロジェクトを用意する
Canvasでの試作が終わり、「このアプリを実際の業務で使おう!」と決まったら、ここからが本番環境の準備です。
Step②でお伝えした通り、Canvasのままでは安全なデータベースがありません。そこで、自社でしっかり管理できる「Firebase」のプロジェクトを新しく作り、アプリのデータ保存先をそちらへ引越しさせます。
Webアプリの登録
Firebaseとアプリを繋ぐための設定情報(APIキーなど)を発行します。
Firestore(データベース)の作成
最初からアクセス制限がかかる「Production mode」で作成しましょう(Test modeは誰でも読み書きできてしまい危険です)。
認証(Authentication)の設定
社内利用なら「匿名認証」ではなく「Googleアカウントログイン」を使います。匿名認証は「誰かわからない人」もログインできてしまうため、社内限定のガードにはなりません。
Step④ Firebase Hostingでインターネットに公開する
準備ができたら、Firebase Hostingを使ってアプリをWeb上に公開します。
基本の公開手順
① まずは関係者だけでテスト確認(プレビュー公開)
いきなり本番公開せず、一時的なテスト用URLを発行して動作チェックをするのがおすすめです。 firebase hosting:channel:deploy preview
② 問題がなければ本番公開
テストで問題がなければ、正式なURLへ一括公開します。 firebase deploy
テスト用のURL(Preview Channel)もURLを知っていれば誰でもアクセスできます。安全なルール(Step⑤)を整えるまでは、テスト段階であっても本物のデータを入力しないよう注意しましょう。
ステップ⑤ 「誰が・何をできるか」のルールを決める

最後にアプリとデータを守るためのセキュリティ設定(Firestore Security Rules)を行います。
Step③で用意したProduction modeは「初期状態ではすべて拒否」されているため、必要な社内ユーザーだけに、必要な操作を少しずつ許可していくのが安全な進め方です。
混乱しやすいセキュリティの仕組みは、以下の3つの役割で整理すると分かりやすくなります。
| 仕組み | 役割 | たとえ |
| Authentication | ログインしているか | 「あなたは誰ですか?」を確認 |
| Security Rules | 読み書きの権限チェック | 「あなたにこの操作を許可します」 |
| App Check | 正式なアプリからのアクセスか | 「偽物のアプリや怪しいツールではありませんか?」 |
「ログインしている=安全」ではない
ルールを書く際、よく使われる request.auth != null(ログイン済みのユーザーなら許可)という条件だけで安心してしまうケースがあります。
これだと「アカウントさえ持っていれば誰でもデータを変更できる」状態になりかねません。
「社内ドメイン(@your-company.com)のGoogleアカウントだけを許可する」といった、一歩踏み込んだ設定を入れることで、社内アプリとして安全に運用を開始できます。
料金体系について
Firestoreは、小規模なアプリであれば無料で十分に運用できます。ただし、タダで収まるかどうかは「利用人数」ではなく「アプリの作り方(設計)」で決まります。
-
保存データ:1GB
-
ドキュメント読み取り:1日50,000回
-
書き込み:1日20,000回
-
削除:1日20,000回
-
外部データ転送:月10GiB
「少人数だから無料」とは言えない?
備品管理や簡単な記録アプリなら無料枠に収まりやすいですが、以下のような作りになっていると、たとえ社員数人の利用であっても上限を超えて有料になります。
-
画面を開いている間、リアルタイムで何度もデータを読み直し続ける
-
不要なデータまでまとめて全件取得してしまう
-
不正アクセスや無駄な連続リクエストを防ぐ仕組みがない
「何人で使うか」ではなく、「1回画面を開く・操作するときに何回データを読み書きするか」を意識してアプリを設計することが重要です。
注意しておくべき点

Firebaseで画像保存やバックエンド処理を組み込む際、絶対に知っておくべき「課金プランの重要ルール」があります。
一部の機能にはBlazeプラン(従量課金)が必須
画像やPDFなどのファイルを扱う「Cloud Storage for Firebase」を利用するには、従量課金制のBlazeプランへの変更が必要です。
またサーバーなしで「データの自動処理」などを裏で動かす「Cloud Functions」を本番環境へデプロイする際にもBlazeプランへのアップグレードが必須となっています。
Blazeプラン=即課金ではない
「従量課金」と聞くと身構えてしまいますが、プランを切り替えたからといってすぐに請求が発生するわけではありません。
それぞれのサービスには無料利用枠が用意されているため、小規模な利用であれば無料で収まることも十分にあります。
ただし、サービスごとに無料枠の条件や課金の計算方法が異なる点には注意しておきましょう。
予算アラートの落とし穴
予想外の請求を防ぐために、Google Cloudで予算アラートを設定しておくのがおすすめです。
しかし、ここで最も気をつけたいのが「アラートは自動で処理や料金を止めるストッパーではない」という点です。
予算アラートは、あくまで設定金額に近づいたことを「通知してくれるだけ」の仕組みです。通知が届いたら放置せず、すぐにアクセス状況やプログラムの挙動を確認する運用を心がけましょう。
事業所として先に決めておきたい3つの線引き

1.試作段階では個人情報を入力しない
利用者名、顧客名、住所、電話番号などをCanvasの試作品へ入力する必要はありません。テストなら、「利用者A」「担当B」「サンプル商店」で十分です。
Google自身もCanvasアプリへ機密情報や個人情報を提供しないよう案内しています。
そしてもう一点。自社Firebaseへ移しただけで、個人情報を自由に扱ってよくなるわけでもありません。
アクセス権、保存期間、削除方法、担当者、組織のルールなどを決めたうえで利用する必要があります。
2.AIが書いたコードを必ず人が確認する
AIが作ったアプリは、「画面が動く」ことと「業務システムとして正しい」ことが別です。
たとえば「返却日より貸出日のほうが後になっている」「誰でも削除できる」「入力必須の項目が抜けている」「権限のない職員が編集できる」ような問題が残ったままでも、アプリ自体は普通に動きます。
公開前に、実際の業務と同じ流れで人が触って確認してください。
3.判断と責任は人が持つ
「誰に使わせるか」
「どのデータを保存するか」
「どこまでAIに処理させるか」
「問題が起きたとき誰が対応するか」
これはAIに決めてもらうものではありません。
AIはコードを書くことはできます。でも、そのアプリを業務として運用してよいかどうかを決める責任までは持ってくれません。
Canvasに向かないこと

Canvasは便利ですが、何でもCanvas共有リンクで運用すればよいわけではありません。
特に、下記を扱うアプリでは、Canvasの共有リンクをそのまま本番環境として使い続けることはおすすめしません。
- 多人数で長期間利用する
- 個人情報を扱う
- 職員ごとに権限を変える
- 操作履歴を残す
- 業務上止まると困る
Canvasで試作して、必要性が確認できたものだけを、自分たちが管理できる環境へ移す。このくらいの感覚で利用を考えていたらいいと思います。
まとめ
Gemini Canvasで業務アプリを作るときは、
- Canvas=つくる場所
- Firestore=データをためる場所
- Firebase Hosting=アプリを配る場所
このように分けて考えると理解しやすくなります。
そして一番確認してほしいのは、「どこにデータが保存されているのか」「誰がそのデータを見られるのか」この2点です。
Canvasでユーザー間のデータ共有を有効にしたアプリでは、公開リンクを知っている人がデータを閲覧・編集できます。
社内で継続利用するなら、自分たちが管理するFirebaseプロジェクトへ移し、AuthenticationとSecurity Rulesを設定する。そして個人情報を扱う場合は、システムだけでなく組織としての運用ルールまで決める。
ここまでできて、ようやく「作れたアプリ」が「職場で使える仕組み」に変わっていきます。
よくある質問
Q. プログラミングの知識がなくてもCanvasでアプリを作れますか?
A. 試作品を作るところまでは十分可能です。
日本語で指示しながらアプリを作り、コードを直接確認・修正することもできます。
ただし、業務システムとして公開する場合には、Authentication、Security Rules、データ設計などの知識が必要になります。
「AIがコードを書いてくれる=システム管理の知識が不要」ということではありません。
Q. Canvasで作ったアプリに顧客名や利用者名を入れても大丈夫ですか?
A. 試作段階では入れないことをおすすめします。
GoogleもCanvasアプリへ機密情報や個人情報を提供しないよう案内しています。
まずは架空データでテストしてください。
また、自社Firebaseへ移しただけで個人情報の利用が自動的に安全になるわけではありません。
Security Rulesだけでなく、組織としての情報管理ルールまで確認してください。
Q. 無料で運用できますか?
A. 小規模アプリなら無料枠に収まる可能性はあります。
Firestoreでは1日50,000回の読み取りなどの無料枠があります。
一方で、アプリの設計や利用量によって変わるため、「○人までなら必ず無料」とは言えません。
Cloud StorageやCloud Functionsなど、Blazeプランが必要な機能もあります。
Q. 匿名認証を使えば社内限定になりますか?
A. なりません。
匿名認証は、ログインしていない人へ一時的な匿名アカウントを発行するための仕組みです。
職員だけに利用させたい場合は、Googleアカウントなどで本人を認証し、Security Rulesで利用可能なユーザーを制限する方法を検討してください。
Q. Canvasで作ったものをそのまま業務システムにしていいですか?
A.Canvasの共有リンクだけで運用し続けることはおすすめしません。
小さな試作や検証には非常に便利ですが、継続して業務利用するもの、特に「個人情報を扱う」「複数職員が同じデータを扱う」「権限管理が必要」これに該当するなら管理できる環境へ移し、保守担当者まで決めておくことをおすすめします。
※本記事は2026年9月1日時点で公開されているGoogleおよびFirebase公式情報をもとにまとめています。各サービスの仕様・料金・提供状況は変更される可能性があるため、実際に導入する際は最新の公式情報をご確認ください。