『一人で店を回す、その横にAIが来た。』第6章 挑戦編 - 自分の店専用のシステム開発
この本は note・PDF・Google Play で無料で読めます（Kindle 版のみ99円）。PDF は日本語を含む20の言語があり、再配布自由です。→ https://bontallc.com/books/hitori-de-mise?via=note
全8回の7回目
～「ないなら作る」。専門家不在のシステム開発プロジェクト～
※念のためお伝えしておくと、本書に出てくるすべてをやる必要はありません。
・画像を投げて文章を作らせる
・LINEの長文を図にする
まずはこの2つだけで十分です。それだけでも、あなたの仕事は確実に楽になります。
「こんなことまでAIとできるんだ」と、読み物として眺めるだけでも十分です。
6-1. 既製品のアプリでは、私の「痒いところ」には届かない
ここまで、画像生成やメニュー分析など、既存のプラットフォームの上でAIを活用する方法をお話ししてきました。
しかし、経営を続けていると、どうしても「既製品のアプリ」では解決できない悩みが出てきます。
特に、私たちのような「昼はカレー、夜はバー」という変則的な業態では、入出金の流れも複雑です。
「PayPay銀行の残高と、今後の支払い予定を突き合わせて、月末に着地する金額を知りたい」
「支払日は10日と25日に分かれている。これをシミュレーションしたい」
世の中にある会計ソフトは高機能ですが、「今の私の頭の中にある不安」をピンポイントで解消してくれるものはありませんでした。
そこで私は決意しました。
「ないなら、作ろう。私にはGeminiという最強のエンジニアがいる」
6-2. フェーズ1〜3：メモ書きから「クラウド」へ
開発は、私のGoogleKeepのメモ書きをGeminiに見せることから始まりました。
開発の元になったKeepメモ
フェーズ1：ロジックの構築
「このメモにある計算を自動化したい」
私の要望に対し、Geminiはすぐに計算ロジックを組みました。
項目ごとの金額を変えたら、即座に最終残高を計算する。
資金がショートしそうになったら、赤字で「警告」を出す。
支払いのタイミングを「10日」と「25日・月末」で分割してシミュレーションする。
データはブラウザ（キャッシュ）に保存する方式
これだけでも十分便利ですが、私は欲が出ました。「ブラウザを閉じてもデータが消えないようにしたい。スマホでも確認したい」と。
フェーズ2：未知のツール「Firebase」の採用
スプレッドシートとの連携を考えましたが、Geminiの提案は意外なものでした。
「リアルタイム性と効率を考えるなら、Googleの『Firebase（ファイアベース）』を使いましょう。無料枠で十分運用できます」
「ファイアベース……？」聞いたこともない単語です。しかし、私はかつてのシステム調整役としての勘で「AIがそこまで勧めるなら乗ってみよう」と判断しました。
結果、Firestoreというデータベースを使うことで、データは安全にクラウドに保存されるようになりました。
フェーズ3：Googleログインと承認システム
お金の話なので、誰でも見られる状態はマズいです。
最初は「合言葉」などを考えましたが、Geminiは「セキュリティを高めるならGoogleログインにしましょう」と提案。
さらに、「私が承認したスタッフだけが見られるようにしたい」と伝えると、「管理者が画面上でメンバーを承認・削除できるシステム」まで作ってくれました。
6-3. フェーズ4〜5：黒い画面（ターミナル）への挑戦
ここからが、バイブコーディングの最大の山場でした。アプリをインターネット上に公開（デプロイ）する作業です。
注意：ここからは「黒帯」コースです
ここからの数ページは、本書の中で最も難易度が高い「実践編」です。 映画に出てくるハッカーのような「黒い画面（ターミナル）」を操作します。
正直に言います。ここでは必ずエラーが出ます。私も出ました。 「PowerShellの権限エラー」など、呪文のような壁にぶつかります。 ですが、恐れないでください。ここでもやることは同じ。「エラー画面をスクショしてAIに投げる」だけです。
私がシステム屋時代に学んだ真実は、「プロでもエラーは出す。違いは、エラーが出た時に諦めるか、検索（相談）するかだけ」ということです。 もし難しそうだと感じたら、この節は読み飛ばして、「AIを使えばこんなことまでできるんだ」という可能性だけ感じ取ってください。
Geminiは言いました。
「WindowsのPCで開発環境を作ります。『Node.js』をインストールし、『VS Code』で以下のコマンドを打ってください」
言われるがままに黒い画面（ターミナル）を開きましたが、いきなりエラーです。
「PowerShellのセキュリティ制限で実行できません」
普通の店主ならここで心が折れます。
しかし、私はエラー画面をコピペしてAIに投げました。
AIは即答します。「『Set-ExecutionPolicy』というコマンドで制限を解除してください」
意味もわからずコマンドを打ち込み、npm run build、firebase deploy……。
呪文のような文字を打ち込むたびに、画面には文字が走り、処理が進んでいきます。
そしてついに、Web上に私のアプリが表示されました。
フェーズ5：スマホアプリ化（PWA）
公開されたアプリは、最初はデザインが崩れた「すっぴん」状態でしたが、これも「Tailwind CSS」という設定を追加して解決。
さらに「スマホのホーム画面にアイコンを置いて、アプリみたいに使いたい」と頼むと、「PWA（プログレッシブ・ウェブ・アプリ）」化の設定を教えてくれました。
これで、私のスマホの中に、私が作った（コードは1行も書いていない）専用アプリが誕生したのです。
完成したキャッシュフロー管理アプリの画面
6-4. フェーズ6：30日後の課題と解決
運用を始めて1ヶ月ほど経ったある日、問題が起きました。
「昨日まで使えていたのに、急にアクセスできなくなった！」
焦ってGeminiに相談すると、原因は意外なところにありました。
「データベース（Firestore）の設定が『テストモード（30日限定）』のままになっていました。期限切れです」
AIは、開発当初に設定の手間を省くため、あえて期限付きのルールにしていたのです。
「セキュリティルールを、『ログイン済みユーザーならずっと使える』ように書き換えましょう」
AIの指示通りに設定ファイルを数行書き換えると、無事にアプリは復活しました。
このトラブルも、私にとっては良い経験でした。
「システムは生き物であり、メンテナンスが必要だ」ということ。
そして「トラブルが起きても、AIに聞けば必ず答えがある」という安心感を得られたからです。
6-5. 事例②：X（旧Twitter）のデモ動画から始まった「顔認証プロジェクト」
私が挑んだもう一つの、そして最大のシステム開発。
それが、「来店されたお客様をカメラで認識し、お名前とその方のデータ及び好みをこっそり教えてくれるシステム」です。
開発のきっかけは、何気なく見ていたSNS（X）でした。
あるエンジニアが投稿した、「Google Chromeに組み込まれたAI（Built-in AI）を使って、Webカメラに映ったものをリアルタイムで解説させる」というデモ動画が流れてきたのです。
元システム屋としての勘が働きました。
「これは『マルチモーダル』だ。しかもブラウザに組み込まれているなら、クラウドにお金を払わなくても、自分のPCの中だけで動くんじゃないか？」
もしこれができれば、高額なシステムを導入せずとも、私の店専用の「おもてなしシステム」が作れるかもしれない。
私はそのURLをコピーし、Geminiに投げ込みました。
「これと同じことをやりたい。実装方法を教えて」
Phase 1：動いたけれど、「誰」かが分からない
Geminiの指示通りにChromeの設定（フラグ）を変更し、コードを貼り付けると、あっけなくデモと同じシステムが動きました。
カメラに私が映ると、画面にはこう表示されます。
『眼鏡をかけた男性が、PCの前に座っています』
GeminiNanoというブラウザ内に組み込まれたAIを使っているのですが、これはクラウドに接続すること無く、ブラウザ内で完結するのが利点ですが、一般的な、「眼鏡」、「男性」などは認識できますが、それが誰かを判定するまでには至りません。
すごい技術です。しかし、飲食店経営者としての私はすぐに落胆しました。
「これじゃダメだ」
私が知りたいのは「眼鏡の男性」という一般的な特徴ではなく、「これがAさんなのか、Bさんなのか」という個人の特定です。
Phase 2：Google Photos連携の壁と、AIからの回答
そこで私は、安直なアイデアをGeminiにぶつけました。
「このシステムと、私のGoogle Photosを繋げてよ。そこには友達や常連さんの顔分類データがあるから、それと照合すれば名前がわかるでしょ？」
Geminiの回答は、冷ややかかつ正論でした。
「申し訳ありませんが、それはできません。Google Photosの顔認識データは高度なプライバシー情報であり、外部のプログラムから利用することはセキュリティ上、許可されていません」
ごもっともです。ここで道は途絶えたかに見えました。
しかし、ここからが「バイブコーディング（対話開発）」の真骨頂でした。AIは、ただ断るだけではありませんでした。
Phase 3：代替案とピボット（方向転換）
Geminiは続けてこう提案してきました。
「Google Photosは使えませんが、オープンソースのライブラリ（OpenCVやface_recognitionなど）を使って、ローカル環境で独自の顔認証システムを作ることは可能です。試しますか？」
「はい」と即答しました。
ここから、開発方針がガラリと変わりました。Chromeの機能を使うのではなく、Pythonというプログラミング言語を使って、ゼロから顔認証システムを組むことになったのです。
Phase 4：黒い画面と格闘し、スプレッドシートと繋ぐ
やることは変わりません。Geminiに「必要なライブラリのインストール方法」を聞き、黒い画面（コマンドプロンプト）に貼り付ける。
エラーが出れば、その赤文字をそのままGeminiに投げ返す。
数時間後、ついにシステムが完成しました。
Webカメラが私の顔を捉える。
PC内のフォルダにある「顔写真データ」と照合する。
一致したら、「Googleスプレッドシート」の顧客リストを見に行く。
画面に『Bontaさん：角ボトルの残量 〇〇g』と表示される。
顔認証システムの稼働画面。店主の顔を認識して情報を表示している。Geminiでキャプチャ画像にモザイクをかけている
外注費0円。私のコーディング作業もゼロ。
世界に一つだけの「顔認証CRMシステム」が、東中野の片隅で産声を上げた瞬間でした。
Phase 5：そして気づく「守る責任」
システムは完成しました。しかし、喜びと同時に、背筋が凍るような感覚も覚えました。
「待てよ。今、このパソコンの中に、お客様の顔のデータ（生体情報）が入っているんだよな……」
これまでは「動けばいい」と思っていました。しかし、これが実運用となると話は別です。
もしこのパソコンがウイルスに感染したら？ お客様の顔データと、好みの情報（個人情報）がセットで流出してしまうかもしれない。
インターネットに繋がないスタンドアロンPCなら安全ですが、予約管理やSNS運用をする以上、ネット接続は必須です。
「便利な道具を作れる」ということと、「それを安全に管理できる」ということは別問題です。
私はここで初めて、以前保険屋さんが営業に来た時に話していた「サイバーリスク保険」の重要性を痛感しました。
「ウチみたいな個人店にサイバー攻撃なんて来ないよ」と笑っていましたが、AIで高度なシステムが作れてしまう今、私たち個人店主も、立派な「データ管理者」としての責任を負うことになるのです。
AIを使えば、魔法のようなツールが手に入ります。
しかし、その魔法を使うための「杖（リテラシー）」と「盾（セキュリティ対策）」を持つことも、これからの店主の仕事なのだと学びました。
6-6. 自由とセットになる「責任」と「保険」の話
重要：プライバシーと個人情報について
この「顔認証システム」は、技術的な可能性を検証するために作成した実験的なプロトタイプです。 実際に店舗で運用する場合、お客様の顔データは「個人情報（生体情報）」として、法律（個人情報保護法）で厳格に守られるべき対象となります。
もしあなたがこれを導入したいと考えるなら、以下の2点を絶対に守ってください。
お客様への周知と同意: 店頭に「ＡＩによる顔認証を行っています」と掲示し、会員登録時に同意を得るなどのプロセスが不可欠です。隠し撮りは絶対にＮＧです。
データの保全: インターネットから切り離された環境で管理するなど、漏洩リスクをゼロにする対策が必要です。
「作れる」ことと「やっていい」ことは違います。技術を持つ店主には、技術を使う責任も同時に発生することを忘れないでください。
ここまで「手作りシステム」の素晴らしさを語ってきましたが、最後に経営者としてシビアな現実もお伝えしなければなりません。
それは、「自分で作ったものは、すべて自分の責任である」という事実です。
月額課金のサービス（SaaS）なら、サーバーが止まれば運営会社が謝罪し、復旧してくれます。
しかし、バイブコーディングで作ったシステムに「カスタマーサポート」はありません。
ランチタイムのピーク時に突然アプリが動かなくなっても、誰も助けてくれません。
Googleの仕様変更で、昨日まで動いていたコードが今日はエラーを吐くことなど日常茶飯事です。
だからこそ、私は2つの準備をしています。
一つは「アナログのバックアップ」です。
「顔認証が止まったら、紙の顧客台帳を見る」「レジアプリが落ちたら、電卓と手書き伝票で対応する」。
デジタルはあくまで「便利ツール」であり、それに依存しすぎて「止まったら店も止まる」状態にしてはいけません。
もう一つは、先ほども触れた「保険」です。
情報漏洩のリスクだけでなく、自分のミスでシステムを止めてしまった時の営業補償なども含め、サイバーリスク保険に入ることは、IT武装する個人店主の「大人の嗜み」です。
「止まることもある。間違えることもある」
それを前提に、リスクを許容し、対策を打つ。
この覚悟を持って初めて、私たちは誰にも縛られない「自由なシステム」を使いこなすことができるのです。
6-7. 専門家はいらない。「執念」があればいい
これら2つのシステム開発に、私は1円も外注費を払っていません。
使ったのは、月額数千円のAI利用料と、「絶対にこの不安（資金繰り）を解消したい」「お客様を喜ばせたい」という店主としての執念だけです。
「プログラミングができないから無理」ではありません。
「作りたいもの（Want）」さえあれば、AIが「作り方（How）」を教えてくれます。
わからない言葉（Node.js, PowerShell, Firestore...）が出ても、恐れることはありません。
私たちには、それを翻訳し、導いてくれる「Gemini」という最強のパートナーがいるのですから。
コラム④：Excelとデータベース（Firestore）は何が違う？
～「自分が見るメモ」か、「システムが読む台帳」か～
キャッシュフローアプリ開発で登場した「Firebase（Firestore）」。なぜExcelじゃダメなの？ と思われたかもしれません。
表計算ソフト（Excel）は「人間が見て入力するノート」です。自由度が高い反面、システムにとっては「どこに何があるか曖昧」です。
一方、データベース（Firestore）は「システム専用の整理されたロッカー」です。「1番に日付、2番に金額」と決まっているので、プログラムが瞬時に扱えます。また、複数人で同時にアクセスしても壊れません。
「アプリを作るならExcelではなくデータベース」。これを知っているだけで、AIへの指示出しレベルが一つ上がります。
**2026年10月の追記**
本書を再公開するにあたり、二つ書き添えます。
一つ目は、6-4で書いたデータベースの設定です。「ログインしていれば誰でも使える」という設定は、それだけでは安全ではありません。誰がどのデータを読み書きできるかを、利用者やデータごとに制限する必要があります。試すときの設定を、そのまま本番で使わないでください。
二つ目は、6-5の顔認証です。これは技術を確かめるための試作で、店でそのまま運用することは勧めません。顔の情報の扱いは、国や地域の法律で決まりが違い、同意を得たり、インターネットから切り離したりするだけで危険がなくなるわけではありません。
この本の、ほかの読み方
PDF（無料・再配布自由）：https://bontallc.com/books/hitori-de-mise/pdf?via=note
Google Play（無料）：https://play.google.com/store/books/details?id=4dUiEgAAQBAJ
Kindle（99円）：https://www.amazon.co.jp/dp/B0GFY4WW4Y
周りの店主仲間や、AI に興味のある方に、そのまま送ってください。
屯の予約サイト：https://tamuroreservation.vercel.app/?src=note1
Agendaシリーズ：https://bontallc.com/agenda?via=note1
