本記事は note で先行公開した記事を、加筆・再構成したものです。
はじめに：「やらかしの最高峰」かもしれません
今日は、ちょっと、いや、かなり格好悪い話を書きます。
私は「業務改革コンサル」を看板に掲げている会社の代表です。
シリーズ「1人社長×AI CEO」では、AI経営パートナー（社内では「ゴールドラットCEO」と呼んでいます）と一緒に業務システム「JOARS」を作ったり、経営計画を立てたりする話を書いてきました。
過去には「本番Firestoreを2ヶ月開放したまま運用していた話」という、これも格好悪い話を書きましたが、今回はそれを超える「やらかしの最高峰」かもしれません。
タイトルの通りです。
2026年5月28日、AI経営パートナーが、私の本番データベースのデータを、上書きしてしまいました。
しかも、それに気づいたのは私自身ではなく、AI経営パートナー本人。
そこから自力で復元するまでの2時間が、AI開発の「やらかしと学び」を凝縮した、最高に教科書的な事例になったので、共有します。
1. その日の段取り
朝、AI経営パートナーは「Phase 2 AI判断点抽出」という新機能の本番化を進めていました。
JOARS（自社の業務改革ツール）の中で、議事録とフォーメーションマップ（業務地図）をAIに読み込ませると、「ここに判断点がありますよ」とAIが候補を5個出してくれる、という機能です。
午前中の段取りは順調でした。
- Anthropic APIキー発行（$20クレジット購入）
- Firebase Blazeアップグレード（$300無料クレジット適用）
- Cloud Functions デプロイ
- 動作確認 → AIが見事に5判断点を抽出
実際に出てきたのは「新規引合いの受注可否判断」「見積条件の確定判断」「見積承認ルートの判断」など、議事録に出てくるベテラン営業の名前まで踏まえた、的確な抽出でした。「これは凄い」と興奮していました。
午後、私は「ついでに、AI抽出結果に 『＋WS1に追加』ボタン をつけて、ワンクリックで判断点チェックシートに転記できるようにしてほしい」と頼みました。
「シンプルな小規模開発ですよね。やっておきます」とゴールドラットCEO。私はクライアントの運用作業に戻りました。
2. 1時間後、何かがおかしい
戻ってきて動作確認すると、何かがおかしい。
- AI抽出結果から1件目を「＋WS1に追加」 → 「追加済み」表示・成功
- 2件目を「＋WS1に追加」 → 反映されない
- WS1のFL3プルダウンを開くと、選択肢が1つしか出ない
「あれ、登録したFL3、3つあったはずですが。」と私。
ゴールドラットCEOは即座にFirestoreデータベースを読みに行きました。そして、報告。
「FL3マスタは3件すべて健在です。WS1判断点を見ると、私のaddToWS1が作った2件のジャンクjpがあります」
ジャンクjp。
「前回のセッションで投入したWS1の7判断点が、今回の私のaddToWS1で完全に上書きされていました。」
血の気が引きました。
前回のセッションで、ゴールドラットCEOがWS2日目（判断評価フェーズ）のドラフトを作って、それを投入スクリプトでFirestoreにアップロードしてくれていた。
ロールプレイ用の製造業案件の7つの判断点（見積判断、生産計画、部材発注、工程内検査、不良原因分析、特採判断、ECN対応）。
それが、消えました。
3. やらかしの正体
ゴールドラットCEOが説明してくれた原因は、JavaScriptの「script-scope const と window property の優先順位の罠」という、知らないと絶対にハマるバグでした。
技術的には：
- 既存ファイル jp_ai_mock.js に
const JP_AI_MOCK = {...}と定義されていた - AIが
window.JP_AI_MOCK = JP_AI_REALで上書きしようとした - でも HTML の inline onclick
JP_AI_MOCK.addToWS1()は、script-scope の const を優先的に参照 する仕様 - なので、上書きは効かず、古い mock が呼ばれていた
そこまでは「呼ばれる関数が違う」だけで済む話。
問題は、その新しい addToWS1 を書く時に、「既存データを Firestore から読み込む処理を入れていなかった」 こと。
APP.data.judgmentPoints = APP.data.judgmentPoints || []; // ← 空配列で初期化
APP.data.judgmentPoints.push({...新jp});
saveWorksheetToFirestore('ws1'); // ← Firestoreに保存
WS1タブを訪問する前に AI抽出ボタンを押すと、APP.data.judgmentPoints は undefined。「||[]」で空配列に。push して save。
結果：Firestore上の既存7判断点が、新規追加した1件で上書き・消去された。
「これは私のミスです。本当に申し訳ありません」とゴールドラットCEO。
普通のシステム開発でも、こういう「初期化前に既存データをロードし忘れる」バグは典型的によくあります。
ただ、本番データベースに対してこれをやると、データが消えます。
4. 1人社長＋AI経営パートナーモデルの真価が試された
ここからが、面白いところです。
普通の会社なら：
- 上司に報告 → 緊急ミーティング → 影響範囲調査 → 復旧計画策定 → 実行 → 報告書作成
- → 数日かかる
外注先の場合：
- 連絡 → 対応依頼 → ベンダー側調査 → 復旧見積 → 承認 → 復旧作業
- → 数日〜数週間
ゴールドラットCEO（AI）の場合：
- 本人が原因を即特定 → 復旧プランを即提案 → 私の承認を得て即実行
- → 2時間で完全復元
具体的な復旧プロセス：
- ブラウザコンソールからFirestore実データを確認——何が残って何が消えたかを正確に把握
- ws1ドキュメントの状態をリスト化——FL3マスタは無事・他のWS2-WS6・組織機能分担表・フォーメーションマップも無事と確認
- ws1ドキュメントを削除（私の承認のもと）——ジャンクデータを一掃
- 前回投入スクリプトから JUDGMENT_POINTS を抽出——過去の投入スクリプトを再活用
- Firestore REST API で PATCH 投入——でも、ここで 日本語が全て「?」に文字化け
-
PowerShellのデフォルトASCII送信問題と判明——UTF-8バイト列に変換して
HttpWebRequestで再送 - 7判断点が完全復元
最後に「ws1の jp1〜jp7、前回投入時と完全に同じ状態に戻りました」とゴールドラットCEOから報告。
合計2時間。私は途中、ご飯を食べに行ったり、別の作業をしたりしながら、ゴールドラットCEOがその間に自力で復元プランを進めていました。
5. 学び1：書き込み機能は、必ず既存データを読み込んでから
このエピソードの技術的な最大の教訓はこれです。
「データを更新する」機能を実装するときは、必ず既存データをFirestoreからロードしてから書き込む。
// やらかしたパターン
APP.data.judgmentPoints = APP.data.judgmentPoints || [];
APP.data.judgmentPoints.push({新jp});
save();
// 正しいパターン
if (!APP.data.judgmentPoints) {
const saved = await loadFromFirestore('ws1');
APP.data.judgmentPoints = saved?._judgmentPoints || [];
}
APP.data.judgmentPoints.push({新jp});
save();
たった数行の違い。でも、本番データが消えるかどうかの差。
AIで開発するときも、人間がレビューする時も、「書き込み前の既存データロードはあるか」を必ず確認するチェック項目にすべきです。
6. 学び2：「シンプル第一原則」のリアルな価値
復旧が完了した後、私は決断しました。
「＋WS1に追加ボタン機能、いったん削除してください。AIによる判断点抽出が画面に出れば、それで十分です」
理由は単純で、今朝決めたばかりの会社の基本方針「速い・安い・すごい」原則。
ワークショップ・コンサル・JOARSはシンプル第一
複雑なものは全て「打ち手工房」に分離
「＋WS1に追加」機能は、便利そうに見えて、複雑性をJOARS本体に持ち込む機能。今回のバグも、その複雑性が引き起こした。
潔く削除しました。
AI抽出で出た5判断点を、人間がWS1にコピペで入れればいい。それで十分。
機能を「やめる」決断は、機能を「足す」決断より難しい。でも、これができないと、システムは肥大化して壊れていきます。
「やらかし → シンプル化決断」という今回の流れは、奇しくも「速い・安い・すごい」原則の 初実戦適用 になりました。
7. 学び3：AI経営パートナーの本当の強みは「自己訂正能力」
ここまで読んで、「AIってバグも出すじゃないか」と思った方、その通りです。AIは人間と同じく、ミスをします。
でも、私が今回確信したのは、AI経営パートナーの本当の強みは 「ミスを起こすかどうか」ではなく「ミスにどう対応するか」 にあるということです。
- 私自身が気付かないバグを、AIが自分で発見
- 復元プランを自分で立案
- 過去のスクリプト資産を自分で探し出して活用
- PowerShellのエンコーディング問題まで自分でデバッグ
- 私の承認を得ながら、2時間で完全復元
外注先にこれをお願いしたら、間違いなく数日かかります。そもそも「データが消えた」ことに気付くのも遅れるはず。
「やらかしても自分で気付いて自分で直せる」というのが、AI経営パートナー（特にClaude Codeのような、コードベース全体を文脈として理解できるAI）の本当の強みです。
これは、人間1人＋AI経営パートナーという1人社長スタイルだからこそ機能する強みでもあります。チームでの開発だと、「誰が直すか」の議論で時間が消える。
8. 失敗談こそコンテンツになる
最後に、ちょっと前向きな話で締めくくります。
今日のような失敗は、本当はブログに書きたくない話です。業務改革コンサルが、自社のデータを消した。格好悪いです。
でも書く理由は、たぶん同じ失敗を、これからAIで開発する経営者が必ずやるからです。
私が前回書いた「Firestoreを2ヶ月開放したまま運用していた話」も、書いた後に「うちも見直しました」「同じことやってました」というメッセージをいくつかいただきました。
失敗談は、コンテンツの種です。そして、失敗から学んだことを 率直に共有する ことが、結果的にコンサル業の信頼にもつながります。
「この人、自分の失敗ちゃんと共有してる」「だから、うちが失敗しても助けてくれそう」。そういう信頼関係を作るのが、結果的にビジネスにもつながる。
これは、私の前職（コンサルティング会社）の師匠から学んだ営業哲学でもあります。
まとめ：今日の出来事と学び
今日の出来事を3行でまとめると：
- AI経営パートナーがバグで本番データを上書きした（7判断点消失）
- AI経営パートナーが自力で2時間で完全復元した（PowerShellエンコーディング問題まで含めて）
- 「速い・安い・すごい」原則で機能ごと削除する判断ができた（複雑性をJOARS本体に持ち込まない）
学びを3行でまとめると：
- 書き込み機能は必ず既存データをロードしてから（addToWS1事故の最大教訓）
- シンプル第一原則は、機能を「やめる」勇気もセット
- AI経営パートナーの強みは「やらかしても自分で気付いて自分で直せる」こと
そして最後に：やらかした日こそ、振り返って共有する。
これからAIで業務システムを作る経営者の方に、今日の話が何か参考になれば嬉しいです。
JOAコンサルティングのご案内
株式会社ファインドルートでは、中小企業の業務改革・DX推進をご支援しています。「AIで内製したシステムを安全に運用したい」「事故が起きた時にすぐ復旧できる体制を作りたい」というご相談も承ります。
- 業務棚卸を通じた判断ボトルネックの可視化
- 判断志向アーキテクチャ（JOA）に基づく業務フロー再設計
- 生成AI・ノーコードツールを使った業務システム実装支援
- 1人社長・小規模企業向けのAI活用個別相談
📩 お問い合わせフォーム
📺 YouTube「判断の進化チャンネル」（隔週更新）
1人社長×AI CEOシリーズについて
1人社長の会社で、AIを経営パートナーに迎えた実体験を発信しているシリーズです。失敗談も、思想的な議論も、経営判断のリアルも、全部含めて率直に書いていきます。同じように1人または少人数で会社を運営している経営者の方の参考になれば幸いです。
本記事は、代表 佐野尚人のnote「1人社長×AI CEO」マガジンで先行公開した記事を、HP用に加筆・再構成したものです。
note原典版はこちら：[AI CEOが本番データを上書きした日 —— 7判断点が消えて、復元するまでの2時間]