第19回 実践レポート
外の人が使うアプリには、データベースをつなぐ

前回までの3回で、社内の情報を集約して経営者自身が意思決定を行う「操縦席（ダッシュボード）」を仕上げました。今回からの3回は、そこから一歩進め、外部の顧客や会員がログインして予約や業務報告を行う「Webアプリケーション」を各自で作れるようになるための実践シリーズです。

この日は、食品事業に取り組む参加者がゲスト講師を務めました。エンジニア経験がなく、少し前までコードもプロンプトも書いたことがなかった状態から、直近で「レンタルキッチンの予約システム」と「約300人が暮らす寮の運営アプリ」の2つをAIとの対話だけで構築しています。実際に動いている画面と裏側のデータベースを見せながら、非エンジニアがどのようにシステムを組んでいるのかを解剖していきました。

---

コードを書かない人間が担う、3つの仕事

ゲスト講師を務めた参加者は、AIを使ったアプリ開発では「人間の仕事」と「AIの仕事」を最初に切り分けることが重要だと話します。コードを書いて修正を反映するのはすべてAIの仕事であり、人間がやることは次の3つだけです。

1. 現場を視察し、誰のどんな困りごとを解くために何を作るか決めること
2. 背景・目的・制約を、AIに伝わる具体的な言葉で渡すこと
3. 出てきたものを自分で使い、使いづらい部分をひたすら微調整すること

基本の形ができるまでのデータベース接続や初期構築は全体の1〜2割に過ぎず、残りの8〜9割は「自分で触ってUIを微調整する作業」になります。知らない業界のシステムを外から想像で作っても使い物になりません。自分自身がそのコミュニティや現場の中に入り、使う人の隣で改良を重ねる「FDE（現場常駐型のエンジニア）」と同じ動き方をすることが、実用的なアプリを作る第1条件として共有されました。

300人が暮らす寮の運営アプリで、企画書と月次報告を自動化する

続いて、参加者が現在構築している、約300人が暮らす学生寮の運営アプリの実画面が共有されました。

開発のきっかけは、寮監へのヒアリングでした。当初は管理用のアプリを想定していましたが、話を聞くと「この寮の良さは入居者から次々にアイデアが出て企画になるところだが、予算申請や企画書作成の壁で立ち消えになることが多い」という課題が見えてきました。そこで、単なる管理ツールではなく、みんなのアイデアが形になるアプリとして設計しています。

画面は大きく4つの機能に分かれています。

• アイデアと進行中プロジェクト：入居者が「中庭でイベントをやりたい」といったアイデアを投稿し、みんなの「いいね」が集まったら企画をスタートします。会議の音声や文字起こしを入れると、管理会社へ提出する企画書と進行ステップが自動生成され、参加スタッフが一目で分かります。
• 働く（役職者の月次業務報告）：寮の役職者は毎月1回、管理会社へ業務報告書を出す必要があります。従来は月末に過去のチャットを遡ってExcelの書式に手入力していましたが、アプリ上で日々の対応をその場でメモしておけば、月末にボタン1つで指定フォーマットの報告書（PDF）が自動作成されます。
• 保管庫（名簿・備品在庫・過去資料）：300人のユニット別名簿に加え、イベント用の備品在庫を登録しています。これまで各自が別々のExcelで管理していたために起きていた二重購入を防ぎ、去年のイベント報告書を引き継いで毎年改善できる仕組みです。
• プロフィールと活動履歴：大規模イベントのプロジェクトリーダーになるには、事前にグループリーダーを経験している必要がある、といった寮独自のルールがあります。企画への参加ボタンを押すと活動履歴が自動で記録され、誰がどの役割を担えるかが可視化されます。

参考サイトの画面をAIに見せ、増えすぎたボタンは人間が削る

AIに指示を出すときの具体的なコツも実演されました。「予約システムを作って」と一言だけ投げても、AIは何の予約か分からず、曖昧な画面しか出せません。どの地域のどんな施設で、誰がスマホから予約し、管理者は何人でどう確認するのかまで、ヒアリングした言葉や契約書の条件をそのまま貼り付けて渡します。

さらに効果的だった手法として紹介されたのが、既存の優れたWebサイトのスクリーンショットを順番に撮ってAIに見せるやり方です。分かりやすい予約サイトのトップ、カレンダー、設備紹介、口コミ欄を上から順に撮影してチャットに貼り、「このUIをベースに、中身を自社の施設情報に変えてデータベース設計案を作って」と指示すると、最初から整った画面と設計案が出てきます。

一方で、AI特有のクセとして全員がうなずいたのが、「AIは言われた機能を強調しようとして、同じ『予約する』ボタンを右上にも真ん中にも下にも配置したり、頼んでいない誇張表現を勝手につけたりする」という点でした。

AIは放っておくとどんどん機能を足してアクセルを踏むため、人間側がブレーキを踏み、「重複するボタンを1つに絞る」「不要な文字を削る」「ポップアップは外側の余白をタップしただけで閉じられるようにする」「いきなり予約する人ばかりではないので、予約と問い合わせを分ける」といった引き算の指示を繰り返す必要があります。

また、商談での失敗談も率直に共有されました。レンタルキッチンの予約システムを先に作り上げて施設側へ提案したところ、システム自体の出来は高く評価されたものの、「数年前から頼んでいる既存の制作業者がいるから」と導入を断られたという経験です。講師からは、相手の名前や情報を使って画面を作る以上、作り始める前に一言相談して合意を取っておくことが大切だと助言がありました。

自分が使う画面と、外の人がログインするアプリは何が違うか

講義の後半では、「前回まで作ったダッシュボード（ローカルや単一サーバーで動く画面）と、今回のように外部データベース（Supabaseなど）をつなぐWebアプリは何が違うのか」を講師が整理しました。

自分1人、あるいは家族や社内メンバー数人だけが見る画面なら、自分のパソコン内や簡易なサーバーだけで十分回ります。しかし、システムの「外側」にいる顧客や会員がアクセスする場合には、外部データベースが必要になります。理由は4つあります。

1. 会員ごとのログインとマイページ：1人ひとりにアカウントを発行し、自分の予約や履歴だけを見られるようにする。
2. 誰が操作したかの追跡：共有画面で「送信」ボタンが押されたとき、外部データベースでログイン管理をしていれば、誰がどのアクションを実行したかが正確に記録に残る。
3. 閲覧権限（パーミッション）の振り分け：リーダー、一般メンバー、外部ゲストなど、立場によって見せてよいデータと隠すデータを安全に区分できる。30人規模の社員管理などを頼まれた場合、これがないと情報漏洩の事故が起きる。
4. 24時間の受付と同時書き込みの保護：自分のパソコンを閉じていてもオンライン上で常時データを受け付けられ、複数人が同時に書き込んでも上書きでデータが消えない。

GitHub・サーバー・データベースの役割を切り分ける

不動産事業に取り組む参加者からは、「自分のパソコンからGitHubにコードを上げ、Cloudflareで公開するところまでは分かったが、データベースはその間のどこに入るのか」という質問が出ました。講師は手書きの図を描きながら、3つの役割を建物のたとえで説明しました。

• GitHub（設計図の保管庫）：画面のデザインやプログラムのコードを保存し、バージョン管理する場所。顧客の個人情報はここには絶対に保存しない。
• Cloudflareなどのサーバー（空き家）：インターネット上に借りる「部屋」。ここにプログラムを置いておけば、自分のパソコンの電源が切れていても、顧客はスマートフォンから部屋を訪れて操作できる。
• Supabase / Firebase（専用の倉庫）：サーバー（空き家）の奥に接続された、データ保管専用の倉庫。顧客が画面に入力した情報は、サーバー上のプログラムが受け取ってこの倉庫にしまい、必要なときに取り出して表示する。

倉庫（データベース）の使い分けとして、運営側が用意した静的なデータを大量に置いてユーザーに見せるだけならFirebase、ユーザーがログインして次々にデータを書き込む動的なアプリならSupabaseが適している、という基準も整理されました。将来、会員が10万人規模に育って従量課金が大きくなる段階が来たら、そのまま払うのではなくデータベース会社の担当者と直接ミーティングをして構成を最適化してもらうのがよい、という実務の知恵も共有されました。

スプレッドシート管理からの移行と、安全な予約フォーム

最後の30分は、不動産事業に取り組む参加者が開発中の「教室の予約管理システム」を画面共有し、その場でデータベースへつなぎ直すワークを行いました。Googleフォームとスプレッドシートを経由していた仕組みに対し、ゲスト講師のナビゲートでSupabaseのプロジェクトを東京リージョンで立ち上げ、AIチャットに指示を出して直接データベースで管理する構成へと移行を進めました。

あわせて、複数のAI開発ツール（Claude CodeやCodexなど）を使い分ける際、ツール固有のフォルダにデータを閉じ込めず、パソコンの共通ドライブを作業フォルダに指定しておけば、どのAIからでも同じオントロジーとコードを引き継げることも確認しました。

また、参加者が制作した空き家事業のWebサイトも披露されました。自分の写真を元に作ったちびキャラクターが画面上を歩くと、空き家に明かりが灯って「活用中」に変わる遊び心のあるデザインです。そこへ組み込まれたオンライン相談の予約画面について、講師は「自前のWebフォームに直接文字を入力させる方式はウイルス混入などのリスクが高いが、Googleカレンダーの予約受付画面をそのまま埋め込む方式は、Googleの堅牢なセキュリティの中でやり取りが完結するため、利用者にとっても運営者にとっても非常に安全で信頼感がある」と高く評価しました。

この日の到達点

自分が眺めるためのダッシュボードから一歩踏み出し、外部のユーザーがログインして動くWebアプリケーションの裏側の構造（GitHub・公開サーバー・外部データベースの連携）を全員で理解しました。AIに画面を作らせるときは参考サイトのスクリーンショットと具体的な背景を渡し、出てきた画面から不要なボタンを人間が削っていく。次回の第20回に向けて、各自が自分の事業のアプリケーションを1つ組み立てて持ち寄ることになりました。