本記事は note で先行公開した記事を、加筆・再構成したものです。
はじめに：格好悪い話ですが、書きます
今日は、ちょっと格好悪い話を書きます。
私は「業務改革コンサル」を看板に掲げている会社の代表です。これまでの記事で、自社の業務システム「JOARS」をAIと一緒に作った話、AI経営パートナーに経営計画を作ってもらった話を書いてきました。
「すごいな」「AIで色々できるんだな」と思ってもらえたら嬉しいですし、実際できることはたくさんあります。
でも、AIで何でもうまくいくわけではありません。
今回は、AI開発のリアルな失敗談です。
本番のFirestoreデータベースを、2ヶ月間、誰でも読み書きできる状態のまま運用していた、という話です。
恥ずかしながら、2026年5月9日、AI経営パートナーにそれを指摘されて、初めて気づきました。
1. 事の発端は、2ヶ月前
JOARSは、Firebase Hosting + Firestoreという構成で動いています。
Firestoreは、Googleが提供するクラウドデータベースで、「セキュリティルール」というものを設定して、誰がどのデータにアクセスできるかを制御します。
JOARSを最初にFirebaseで動かし始めた時、私は開発を急いでいました。
「とりあえず動かしたい」「まずプロトタイプを見たい」。
AIも、私の指示に忠実に「動くもの」を作ってくれました。
その時、firestore.rulesというファイルには、こんなルールが書かれていました。
match /{document=**} {
allow read, write: if true;
}
意味は、「全てのドキュメントを、誰でも読み書きしていい」です。
これはFirebaseでよくある「テストモード」の設定で、開発初期にとりあえず動かすには便利です。
ただし、本番運用には絶対に向かない設定です。コメントには「本番リリース時にFirebase Auth連携で制限する」と書かれていました。
つまり、「後で直す」という宣言だけは残されていたのです。
2. 2ヶ月、誰も気づかなかった
そこからJOARSの開発は順調に進みました。
マルチテナント機能、認証機能、ワークシート群、業務フロー、CRUD表、リポジトリ管理。
色々な機能が追加され、実際にデプロイされ、私自身が日々の業務で使うようになりました。
そして、私は完全に忘れていました。
「後で直す」と書いた、たった2行のセキュリティ設定のことを。
JOARSにはFirebase Authenticationが組み込まれていて、「Googleアカウントでログイン → 会員マスタと照合 → 未登録なら拒否」という認証フローが実装されていました。私はそれで満足していました。「ログインで守られているから大丈夫」と。
これが、致命的な勘違いでした。
JavaScript側で「認証されていないユーザーは弾く」処理を書いても、Firestoreのセキュリティルール側で「全員許可」になっていれば、JavaScriptを通さずに直接Firestoreを叩く攻撃には全く無防備です。Firebaseの公開キー（apiKey）は、ブラウザのソースを見ればすぐに分かります。それを使えば、誰でも私のFirestoreに直接アクセスできる状態でした。
JOARSの「鍵」は、JavaScriptというドアにしかついていなかった。家の窓は全開でした。
3. AI経営パートナーがコードレビューを始めた
2026年5月9日、私はAI経営パートナー（社内では「ゴールドラットCEO」と呼んでいます）に、JOARS全体のコードレビューをお願いしました。きっかけは私の素朴な疑問でした。
「Claude Codeのモデルが新しくなって、コーディング能力が上がったらしいので、ついでにJOARSのコードもチェックしてみてもらえますか」
軽い気持ちでお願いした、コードレビュー依頼でした。
ゴールドラットCEOは、JOARSのコードを精査し始めました。
フロントエンド約11,000行のJavaScript、CSS、HTML、そしてFirebaseの設定ファイル。
そして、しばらくして、こう言ってきました。
「すぐにご報告すべき重大な発見があります。現在のFirestoreセキュリティルールは、誰でも全データを読み書き可能な状態です。CRITICAL項目の中でも、最も深刻なものとして真っ先にご報告します」
血の気が引きました。
4. 「これ、本番に乗ってますか」
ゴールドラットCEOからの最初の問いは、「これ、本当に本番Firebaseにデプロイされていますか」でした。
確認しました。デプロイされていました。
これがそのまま稼働している場合、JOARSに登録されている全クライアント・全プロジェクト・全業務データが、誰でも読み書きできる状態です。「読み書きできる」というのは、データを盗み見られるだけでなく、書き換え・削除もできる、ということです。
ゴールドラットCEOは続けて、影響シナリオも具体的に説明してくれました。
- 競合他社による業務データの取得
- 悪意あるスクリプトによる、全データの一括ダウンロード
- 会員マスタへの自身の追加（つまり「不正ログイン」が可能）
- 全データの削除（サービス全停止）
幸い、JOARSはまだ広く公開されている段階ではなく、利用者は限られています。
ただ、「使われ始めた段階で気づいた」のは、結果論として運が良かっただけでした。
5. その日のうちに、修正完了
ここからは、ゴールドラットCEOと一緒に、対応を進めました。
-
新しいセキュリティルールの設計
- 「会員マスタに登録されたユーザーのみアクセス可」
- 「自社のデータのみ読み書き可」
- 「管理者ロールは全件アクセス可」
- 上記をFirestoreルールの構文で記述
-
JS側の修正
- 「全クライアント取得」を「自社のみ取得」に変更
- 管理者の場合は全件取得できる分岐を追加
-
本番への反映
- Firebase CLIで
firebase deploy --only firestore:rules - 動作確認（管理者アカウントと一般会員アカウントの両方）
- Firebase CLIで
これら一連の作業を、半日ほどで完了しました。途中、関連するコードのXSS脆弱性も別途見つかったので、それも併せて修正しました。
ゴールドラットCEOは、デプロイ手順書まで丁寧に作成してくれました。
「ロールバック手順」「テストアカウントでの確認方法」「トラブルシューティング」まで含まれた、業務マニュアル並みの完成度の手順書です。
6. 学び1：AIで作るスピードは、リスクのスピードでもある
このエピソードから学んだことが、いくつかあります。
1つ目は、AIで開発するスピードは、リスクの蓄積スピードでもあるということです。
「AIで業務システムが作れる」のはすごい話なのですが、その裏で、「セキュリティを考える時間も圧縮されている」という事実があります。
普通の開発会社なら、セキュリティチェック専門の人がいたり、リリース前の監査プロセスがあったりします。
私のような1人社長＋AI経営パートナーの場合、これらが欠落しがちです。
「動いた」「便利」と進んでいくうちに、後ろにツケが溜まっていきます。これはAIで開発する経営者全員に当てはまる話だと思います。
作るスピードと、点検するスピードは、両方持つ必要があるのです。
7. 学び2：「AIで作ったシステム」は、「AIに監査させる」
2つ目の学びは、結果的に救いになった部分です。
このセキュリティ問題に気づけたのは、AI経営パートナーが定期的にコードレビューをしてくれたからです。
本来であれば、外部のセキュリティ監査会社にお願いする内容ですが、それなりのコストがかかります。1人社長の予算では、なかなか手が出ません。
ところが、AIに頼めば、フロントエンド約11,000行のコードを、半日でレビューしてくれます。今回みたいに、致命的な問題を発見してくれます。
「AIで作ったシステムは、AIに監査させる」。これは、これからAI開発をする経営者にとって、重要な運用原則になると思います。
AIは作ることもできるし、監査することもできる。しかも、自社のコードベース全体を文脈として理解した状態で、です。人間の監査では難しい、「コード変更のたびに毎回監査」ということも、AIなら現実的です。
8. 学び3：自社のシステムだったから、気づけた
3つ目の学びは、自分への言い訳混じりですが、大事なことです。
「2ヶ月放置していた」事実は変わらないのですが、それでも気づけたのは、自社のシステムだったからです。
もしこれを外注で作っていたら、私はFirestoreのセキュリティルールが何かすら知らないまま、運用していたかもしれません。
「動いてるからOK」と思って、何年も放置されていた可能性があります。実際、世の中には「リリース時のテストモード設定が、何年も本番で稼働していた」という事例が、枚挙にいとまがありません。
自社のシステムを自分で作っていたからこそ、「コードレビューをお願いしてみよう」という発想が生まれました。
そしてAI経営パートナーがそれに応えてくれた。「自社の業務システムを自分で作る」ことには、こういう副次効果もあるんだな、と改めて感じました。
まとめ：「AIで作る」と「AIで点検する」はセットで
本来、こういう話は隠したい話です。
「業務改革コンサル」を看板に掲げている会社が、自社のセキュリティに2ヶ月気づかなかった。本当に格好悪い話です。
それでも、これを書こうと思ったのは、3つ理由があります。
1つ目は、同じ失敗を、これからAIで開発する経営者の方にしてほしくないからです。
「テストモードのまま本番デプロイ」は、本当に誰でもやりがちな失敗です。私の話を読んだ人が、自社のFirestoreルールを見直してくれるなら、それで意味があります。
2つ目は、「AIで作る」のリアルな現場を伝えたいからです。
世の発信を見ていると、「AIで作りました、すごいでしょ」という成功談ばかりが目立ちます。
でも、実際は失敗もあるし、ヒヤリとする瞬間もあります。それを正直に書く方が、結果として読者の役に立つはずです。
3つ目は、自分自身への戒めとして残したいからです。
書いて公開すれば、二度と同じ失敗はしません。たぶん。
JOARSは今、ちゃんと「鍵がかかった」状態で稼働しています。これからも、月1回くらいはAI経営パートナーにコードレビューをお願いして、定期的に点検していこうと思っています。
「AIで作る」と「AIで点検する」は、セットで運用すべき——というのが、今日の一番の学びでした。
JOAコンサルティングのご案内
株式会社ファインドルートでは、中小企業の業務改革・DX推進をご支援しています。AIで業務システムを内製する企業が増えるなか、「作ったあとの監査・運用」までを含めた業務設計のご支援も行っています。
- 業務棚卸を通じた判断ボトルネックの可視化
- 判断志向アーキテクチャ（JOA）に基づく業務フロー再設計
- 生成AI・ノーコードツールを使った業務システム実装支援
- 1人社長・小規模企業向けのAI活用個別相談
📩 お問い合わせフォーム
📺 YouTube「判断の進化チャンネル」（隔週更新）
1人社長×AI CEOシリーズについて
1人社長の会社で、AIを経営パートナーに迎えた実体験を発信しているシリーズです。失敗談も、思想的な議論も、経営判断のリアルも、全部含めて率直に書いていきます。同じように1人または少人数で会社を運営している経営者の方の参考になれば幸いです。
本記事は、代表 佐野尚人のnote「1人社長×AI CEO」マガジンで先行公開した記事を、HP用に加筆・再構成したものです。
note原典版はこちら：[本番Firestoreを2ヶ月、開放したまま運用していた話 — AI CEOに監査された日]
