FirebaseのHosting,Authentication,Firestore Databaseで本格的なアプリをローンチする【タイムスタディアプリ開発：介護DX】

少し前の記事で「訪問介護事業所向けタイムスタディアプリ(デモ) 」を書きました。その記事で紹介したアプリはあくまでもデモで、実際の運用には職員ごとに識別した上で、ボタンを押すごとにデータベースへ記録が保存されるようにする必要があります。そして管理者はそれらのデータにアクセスして情報を収集できるようにしなければなりません。

Webアプリを実際に使えるようにするにはデプロイ環境にデプロイしなければなりませんが、『Hosting』以外にも様々な機能があるFirebase。データベースの『Firestore Database』、ユーザー認証の『Authentication』など様々な機能があり、とりあえず試してみることにしました。

プロンプト

以下は、あなたに作っていただいた訪問介護事業所向けのタイムスタディアプリのフロントエンドのコードです。実運用に向けたバックエンドの開発をしたいと思いますので、1. データベース (DB)、2. サーバーサイド（バックエンド）アプリケーション、3. API (Application Programming Interface)、4. 認証・セキュリティの各ファイルのコードを書いてください。デプロイ環境は、GoogleのFirebaseとし、無料版でできる内容としてください。各ファイルのFirebaseへのデプロイの仕方も教えてください。DBはNoSQLになるかと思います。よろしくお願いします。
##タイムスタディアプリのフロントエンドのコード##

デコード

承知いたしました。ご提示いただいたフロントエンドのコードを元に、Firebase を使用したバックエンドの構築手順と各コードを解説します。

Firebase の無料プランの範囲内で、データベース（Firestore）、サーバーサイドアプリケーション（Cloud Functionsは不要）、API（Firebase SDK）、認証・セキュリティの各要素を実装していきます。

Firebase の大きな特徴は、クライアントサイド（ブラウザの JavaScript）から直接データベースを操作できる点です。これにより、小〜中規模のアプリケーションであれば、別途サーバーサイドアプリケーション（例: Node.js/Express など）を立てる必要がなく、開発を大幅に簡略化できます。API は Firebase SDK が提供するメソッド群そのもの、セキュリティは Firestore セキュリティルール で担保します。

構築の全体像
1. データベース (DB) とセキュリティルールの設計
1. データベース設計 (NoSQL: Firestore)
2. セキュリティルール (firestore.rules)
2. サーバーサイドアプリケーションと API
3. 認証・セキュリティとフロントエンドコードの修正
1. 修正版 index.html
4. Firebaseへのデプロイ方法
1. 事前準備
2. デプロイ手順

構築の全体像

Firebase プロジェクトの準備: Google Cloud 上にアプリの土台を作成します。
認証 (Authentication) の設定: ユーザー（スタッフ）がログインできる仕組みを作ります。
データベース (Firestore) の設定: タイムスタディのデータを保存する場所を用意します。
フロントエンドコードの修正:
- Firebase SDK を読み込み、設定を追加します。
- ログイン機能を追加し、ハードコードされたスタッフ選択を置き換えます。
- 記録時に Firestore へデータを保存する処理（APIコール）を追加します。
- （任意）ログイン時に過去のデータを読み込む処理を追加します。
セキュリティルールの記述: 他のスタッフがデータを盗み見たり、改ざんしたりできないようにルールを設定します。
デプロイ (Hosting): 完成したアプリをインターネット上に公開します。

1. データベース (DB) とセキュリティルールの設計

まず、データの保存形式と、誰がそのデータにアクセスできるかを定義します。

データベース設計 (NoSQL: Firestore)

コレクション:activities
- これは、すべての業務記録を保存する大きな箱のようなものです。
ドキュメント: 1回の業務記録（例：「身体介護を15分間」）が1つのドキュメントになります。
- フィールド:
  - staffId: 記録したスタッフのユニークID (Authenticationから取得)
  - staffEmail: 記録したスタッフのメールアドレス (識別用)
  - task: 業務内容 (例: “身体介護”)
  - startTime: 開始時刻 (Timestamp型)
  - endTime: 終了時刻 (Timestamp型)
  - duration: 業務時間（ミリ秒）

セキュリティルール (firestore.rules)

このファイルは、上記データベースへのアクセス権限を定義する非常に重要なファイルです。

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 'activities'コレクションに対するルール
    match /activities/{activityId} {
      // 読み取り(read): ログインしており、かつドキュメントのstaffIdが自分のIDと一致する場合のみ許可
      allow read: if request.auth != null && request.auth.uid == resource.data.staffId;
      
      // 書き込み(create): ログインしており、かつ書き込むデータのstaffIdが自分のIDと一致する場合のみ許可
      allow create: if request.auth != null && request.auth.uid == request.resource.data.staffId;
      
      // 更新(update)と削除(delete)は許可しない
      allow update, delete: if false;
    }
  }
}

解説:

request.auth.uid: 現在ログインしているユーザーのユニークIDです。
resource.data.staffId: データベースに既に保存されているドキュメント内の staffId フィールドの値です。
request.resource.data.staffId: これからデータベースに書き込もうとしているデータ内の staffId フィールドの値です。
このルールにより、「ユーザーは自分自身の記録しか閲覧・作成できない」というセキュリティが実現されます。

2. サーバーサイドアプリケーションと API

前述の通り、今回はクライアントから直接 Firebase を操作するため、独立したサーバーサイドアプリケーションのファイルはありません。

API の役割は、修正後のフロントエンド index.html 内の JavaScript コードが担います。具体的には、Firebase SDK が提供する firebase.firestore().collection('activities').add() といった命令文が API コールに相当します。

3. 認証・セキュリティとフロントエンドコードの修正

元の index.html を修正し、Firebase の認証機能とデータベースへの接続機能を追加します。

修正版 index.html

元の HTML ファイルを以下のように大幅に修正します。主な変更点は以下の通りです。

Firebase SDK のスクリプトタグを追加
Firebase の設定情報を追加
ログイン/ログアウト用のUIを追加し、スタッフ選択プルダウンを削除
認証状態を監視し、UIの表示を切り替える処理を追加
logActivity 関数内に Firestoreへデータを保存する処理 を追加

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>訪問介護タイムスタディアプリ</title>
    <script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
    
    <script src="https://www.gstatic.com/firebasejs/8.10.1/firebase-app.js"></script>
    <script src="https://www.gstatic.com/firebasejs/8.10.1/firebase-auth.js"></script>
    <script src="https://www.gstatic.com/firebasejs/8.10.1/firebase-firestore.js"></script>....以下省略

4. Firebaseへのデプロイ方法

ここまでのファイル (index.html, firestore.rules) をFirebaseにデプロイする手順です。

事前準備

Node.jsのインストール: もしPCにインストールされていなければ、公式サイトからLTS版をインストールしてください。
Firebase CLIのインストール: ターミナル（WindowsならコマンドプロンプトやPowerShell）で以下のコマンドを実行します。Bashnpm install -g firebase-tools

デプロイ手順

プロジェクト用フォルダの作成: PCの好きな場所に、このアプリ専用のフォルダを作成します（例: time-study-app）。
ファイルの配置: 作成したフォルダの中に、以下の2階層でファイルを作成・配置します。time-study-app/ ├── public/ │ └── index.html <-- 修正したHTMLファイル ├── firestore.rules <-- セキュリティルールを記述したファイル └── firebase.json <-- (この後 `init` コマンドで自動生成されます) ※注意: index.html は public という名前のフォルダの中に入れてください。
Firebaseへのログイン: ターミナルで time-study-app フォルダに移動し（cd path/to/time-study-app）、以下のコマンドを実行します。ブラウザが開き、Googleアカウントでのログインを求められます。Bashfirebase login
Firebaseプロジェクトの初期化: 同じくターミナルで以下のコマンドを実行します。Bashfirebase init いくつか質問されるので、以下のように答えてください。（[ ]はスペースキーで選択、()はエンターキーで決定）
- Which Firebase features do you want to set up? -> Firestore と Hosting を選択します。
- Please select an option: -> Use an existing project を選択し、Webコンソールで作成した自分のプロジェクトIDを選びます。
- What file should be used for Firestore Rules? -> firestore.rules (デフォルトのままエンター)
- What do you want to use as your public directory? -> public (デフォルトのままエンター)
- Configure as a single-page app (rewrite all urls to /index.html)? -> No (エンター)
- Set up automatic builds and deploys with GitHub? -> No (エンター)
これで firebase.json と .firebaserc が自動生成されます。
Firebaseプロジェクトのセットアップ（Webコンソール）
- Firebaseコンソールにアクセスし、プロジェクトを開きます。
- Authentication:
  - 左メニューの「Authentication」へ移動。
  - 「Sign-in method」タブを開き、「メール/パスワード」を有効にします。
  - 「Users」タブに戻り、「ユーザーを追加」ボタンから、ログインに使用するスタッフのメールアドレスとパスワードを登録します。
- Firestore Database:
  - 左メニューの「Firestore Database」へ移動。
  - 「データベースの作成」をクリックし、テストモードで開始します。（後でルールを適用します）
  - 場所は asia-northeast1 (東京) などを選びます。
- Webアプリの設定情報取得:
  - プロジェクト概要の横にある歯車アイコン ⚙ > 「プロジェクトの設定」へ移動。
  - 「マイアプリ」セクションで、作成したウェブアプリを選択します。（なければ「アプリを追加」からウェブを選択）
  - firebaseConfig というオブジェクトが表示されるので、その中身をコピーし、index.html の // ※ここは自分の... の部分に貼り付けます。
デプロイの実行: 準備が整いました。ターミナルで以下のコマンドを実行すると、ファイルがアップロードされ、アプリが公開されます。Bashfirebase deploy 成功すると、ターミナルに Hosting URL: が表示されます。このURLにアクセスすれば、作成したアプリが動作します。

以上で、フロントエンドのコードに認証とデータベース機能を統合し、安全な形でデプロイするまでの全工程が完了です。

Webアプリにアクセスすると、ログイン画面になります。コンソールで設定した職員のメールアドレスとパスワードにより、職員ごとのタイムスタディの結果が識別されて保存されます。

タイムスタディの履歴は、タイムスタディアプリのボタンを押すごとにデータベースに保存されます。これにより、誰が、何日の何時に、何の作業に取り掛かったのかのログが記録されます。

冒頭の図のような画面で、業務時間の見える化ができます。この後、実行、デバッグ（プログラムのバグ（誤り）を発見し、修正する作業のこと。デバッグは、ソフトウェアを実行しながら正しく動作するかをチェックし、バグが見つかった場合にはその原因を調査し、修正する重要なプロセス）を繰り返して使い勝手、見え具合の修正などを同じくAIに投げかけてイメージしているものに近づけてゆきます。

ユーザーのログイン画面と、管理者用の画面が使い分けられるように修正してみました。管理者のメールアドレスとパスワードでログインすると管理者用のダッシュボードになり、各職員のログ、業務時間が切り替えで見ることができます。

自然言語のプロンプトで実際に使えるアプリができることが分かりました。いやはや、AIを使ったバイブコーディングは凄いことですね！　エンジニアでもない私が、実際に業務で使えるアプリを開発できるんです‼

Hostingは習得できましたが、ユーザー認証の『Authentication』やデータベースの『Firestore Database』のイメージが、なかなかつきませんでした。しかしながら一度、実装してみると仕組みが良く分かります。ITは、習うより慣れろの世界です。ガシガシ挑戦してみましょう。

業務時間の見える化は、処遇改善加算や生産性向上推進体制加算におけるタイムスタディ調査で求められている要件です。厚生労働省はエクセルでの様式を示していますが、エクセルでおこなうのは現実的ではありません。タイムスタディ調査のアプリは、京都のベンチャー企業最中屋の『ハカルト』や、ベンチャー企業の合同会社AUTOCAREが提供する『ケア記録AIアプリFonLog』などがあります。アプリの内製化は、それぞれの事業所やサービス形態に応じたきめの細かい設定ができる点にあります。ひな形を作って、みんなで、この項目を入れよう、この項目は不要だね、等などと話し合いながら作れることにあります。開発段階からみんなで議論してゆけば、実施に伴うハードルも低くなるはずでず。アプリ代などのお金もかからず、良いこと尽くしですね。

そんなことができてしまうのが、現在という時代なのです。

また、AIによるバイブコーディングに加え、Firebaseの機能を使えば、ほぼフロントエンドのコードだけで、職員ごとの認証や、記録のデータベースへの送信までもができてしまうんですね。バックエンドのコードを書かなくても、ここまでできてしまうなんて、なんてスゴイことですね!!!

これは使わない手はないです。本当にすごい時代になったものです!!!!!

デプロイ、リリース、ローンチはソフトウェア開発や運用においてよく使われる用語ですが、それぞれ異なる意味を持ちます。

デプロイ
デプロイとは、アプリケーションやシステムを特定の環境に配置し、利用可能な状態にすることを指します。これには、開発環境、ステージング環境、本番環境などへのコードやアプリケーションの反映が含まれます。例えば、ステージング環境や本番環境に配置するプロセスがデプロイに該当します。デプロイは必ずしもユーザーに公開されるわけではなく、内部的なテストや確認のために行われることもあります。

リリース
リリースは、デプロイされたアプリケーションや機能をユーザーに公開することを指します。これにより、ユーザーが新しい機能や変更を利用できるようになります。リリースはデプロイの後に行われることが一般的で、必要に応じてビジネス側の確認や段階的な公開（例: 一部のユーザーにのみ公開する）を伴うことがあります。リリースは、すべてのユーザーに公開する場合もあれば、一部のユーザーに限定する場合もあります。

ローンチ
ローンチは、新しい製品やサービスを正式に市場に投入することを指します。これは、リリースの一部として行われることもありますが、より広範なマーケティング活動やプロモーションを伴うことが特徴です。例えば、新しいアプリケーションをリリースする際に、プレスリリースや広告キャンペーンを展開する場合、それがローンチに該当します。

違いのまとめ
デプロイ: アプリケーションを環境に配置し、利用可能な状態にする。
リリース: デプロイされたアプリケーションをユーザーに公開する。
ローンチ: 新しい製品やサービスを市場に投入し、広く宣伝する。

これらのプロセスは相互に関連していますが、目的や対象が異なるため、状況に応じて適切に使い分ける必要があります。