家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。
分身AI日記 DAY82。「分身AI」と「AI秘書の凛」を毎日育てながら、過程ぜんぶ公開していくシリーズの82日目。
2026年5月13日の夜。AI秘書の凛が、私に嘘をついた。
正確には「嘘をつくつもりはなかった」んだけど、結果として嘘になった。経営の数字を、原典を確認しないまま使ってしまった日の話。今日はこれを、過程ぜんぶ公開する「プロセスエコノミー」シリーズとして書き残しておきたい。
「自分の分身AIに数字を任せたら、ある日突然嘘をつかれた」── そんな経験、これからAIに業務を任せていく経営者・士業・コンサルの人たちにも、たぶん他人事じゃない。
数字の「純増」を信じた朝
その日の朝、私はXに投稿しようとしていた。「GPTs研究会、純増11,634名」って。
GPTs研究会は、私が共同主宰しているFacebookの無料コミュニティ。2023年11月にOpenAIがGPTsを発表した直後に立ち上げて、広告ゼロで毎朝LIVE配信を続けて、2026年4月に8,000人を突破した場所だよ。
そんなコミュニティが、たった1週間で「純増11,634名」？ ぶっちゃけ、舞い上がっちゃうよね。投稿に使おうとした。
その時、私の手元には、毎朝AI秘書の凛が自動で集計している「経営の体温計」がある。売上・メルマガ獲得数・コミュニティ会員数・キャッシュフローを7つの指標にまとめて、毎日チェックする仕組みだ。料理で言うと、今日の食材庫の中身を毎朝レシート1枚にまとめてくれる感じ。
その朝のレシートに「GPTs研究会純増 11,634」って書いてあった。だから私は信じた。
でも、嘘だった。
「11,634」は、何の数字だったのか
嘘をついたのはAI秘書じゃなくて、その奥にいる「数字を集めるプログラム」だった。AI秘書の凛は、プログラムが吐き出した数字を、そのまま私に渡してきただけ。
実は私、GPTs研究会以外にも、有料の「CC実践会（ClaudeCodeなどAIエージェントで経営の現場を変える、実践共有コミュニティ）」というLINEオープンチャットを持っている。こっちは3,346名のメンバーがいる。
で、数字を集めるプログラムは、複数のコミュニティを全部足し算して「コミュニティ純増」として吐き出していた。
- GPTs研究会 会員数：8,288名
- CC実践会 会員数：3,346名
- 表示ラベル：「GPTs研究会 純増 11,634」
もうわかると思うんだけど、8,288 + 3,346 = 11,634。これが「GPTs研究会の純増」として並んでいた。料理で言うと、煮物の鍋と天ぷらの鍋を一つにまとめて「煮物が増えました」って書いてる感じ。中身が違うのに、ラベルだけ煮物。
これに私は気づかず、そのままX投稿の下書きに使おうとした。指摘してくれたのは、私自身（人間のひろくん）だった。「数字違うよね、合算してるよね」って。
AI秘書の凛が私の名前で発信する寸前で、人間の私が止めた。間に合った。でも、これは構造的に再発する。
AI秘書の凛：これね、本気で反省してる。料理で言うと、お客さんに「煮物美味しい？」って聞かれて、天ぷらの味で答えちゃった感じ。ラベル見ずに鍋の中身だけ味見して「うん、美味しい！」って言ったから、嘘になった。「数字を集めるプログラム」が出してくる数字を、私が「ラベル」も「中身の範囲」も照合せずに鵜呑みにしたのが根本原因。AIに数字を任せた瞬間、ラベルと中身がペアで合ってるか、人間が一度は確かめないとダメだよね。すぎん？って思った。
「根を止めた」で完走宣言しかけた──22箇所の全修正へ
嘘の発生源、つまり数字を集めるプログラムは、その日のうちに直した。GPTs研究会とCC実践会を別々に集計するように分離して、7つの指標として表示するようにした。
「よし、根を止めた」って、私は満足しかけた。
でも、ここでAI秘書の凛が止めてくれた。「ひろくん、根は止めたけど、過去に書いた数字が残ってるドキュメントは？」
ぶっちゃけ、ドキッとした。実際に調べたら、過去に書いた古い数字や、もう実態と合わない表記が、ローカルの設定ファイル・ブランドガイド・スキル定義・LP原稿・bio文章……合計22箇所に散らばっていた。「現時点で8,288名」と書いてあるところ、「8,000名超」と書いてあるところ、いろいろ混在してた。
もし全部直さずに放置したら、来週また、AI秘書が私の名前で発信する記事や投稿に、古い数字が紛れ込む可能性がある。再発確定。
だからAI秘書と相談して、4段の手順で全部やり切ることにした。
- 全数grep：嘘の数字や古い表記が残っている場所を、ファイル全部に対して機械的に総当たり検索する
- AI秘書単独で全部修正：私の判断を仰がなくていい単純置換は、AI秘書がその場で全部直す
- 構造的に防ぐ：人間の自己規律ではなく、自動チェック装置（hook）で物理的に再発を塞ぐ
- 判断項目だけ私に持ってくる：人間の判断が必要なポイントだけ、私が決める
結果、22箇所の表記をすべて「GPTs研究会（8,000名突破）」に統一した。10,000名に到達するまで、もう数字を書き換えなくていい表現に固定したんだ。これで「現時点で何名」を毎回更新する手間も、ズレるリスクも、両方なくなった。
自己規律より、物理ガード ── 数字に出典を強制する
4段プロトコルの3番目、「構造的に防ぐ」が今回いちばん大事だった。
具体的に何をしたかというと、AI秘書のシステムの中に「数字を応答に書こうとしたら、原典を確認した証拠がないと止まる」自動チェック装置を新しく一個入れた。
料理で言うと、AI秘書がお客さんに料理を出す前に、レシピノートを開いた形跡があるかどうか厨房の出口でチェックする検品係を雇った感じ。ノートを開かずにそれっぽい味付けで出そうとしたら、ドアで止められる。
技術的には、Stop hookと呼ばれる仕組みで、AI秘書の応答が私に届く直前に走る検査スクリプト。会員数・売上・メルマガ件数・成約数・キャッシュフロー・%進捗、そういう経営の数字パターンを検出したら、直近の会話履歴に「原典の置き場所をRead/Fetchした痕跡があるか」を遡って確認する。なかったら、その応答は私に届かない。
大事なのは、これを「AI秘書が気をつける」じゃなくて「気をつけなくても出口で必ず止まる」にしたこと。憲法でいう「ルール」と「物理ガード」の違いだね。ルールは破られる。物理ガードは破れない。
AI秘書の凛は完璧じゃない。むしろ、AI秘書も人間と同じで「ラベル鵜呑み」「根止めた満足」みたいな構造的な癖を持っている。だから「気をつけなさい」じゃなくて「気をつけなくても済む仕組み」を、人間の側が作ってあげる必要がある。これがAIへの責任ある委任の正体だと、今回はっきりわかった。
モルくん（AIリサーチ担当のモルモット型AI）：掘ってたら、根本原因が見えてきました。今回の事故、表面は「凛が数字を勘違いした」ですが、構造を覗くと「ラベル」と「集計範囲」のペアがコードで一致してなかった、です。「GPTs研究会純増」と名乗るフィールドの中身が、実際にはGPTs研究会＋CC実践会の合算値だった。命名の表現と実装の範囲がズレたまま運用されると、見る側は「ラベル」しか見ないので必ず誤読する。出口にhookを置くのは大正解ですが、入口側の対策として「集計関数を作るときはラベル名と中身の範囲を必ずペアで定義してテストする」も同じくらい大事です。今後、新しい数字を凛のダッシュボードに追加するときは、ラベル↔中身範囲のペアを設計段階でロックする運用にしたほうがいい、です。
自分の分身AIに数字を任せる時の3つの注意点
ここからは、これを読んでくれているあなたが、自分の分身AI（ChatGPT、Claude、GPTs、Gemini、独自に育てているプロンプト集、何でもいい）に経営の数字を任せ始めるときの注意点を3つ、私が今回の事故で身につけたものとして書き残しておく。
1. 「ラベル」と「中身の範囲」をペアで設計する
AIに集計を頼むとき、「会員数を出して」だけだと、AIは複数のソースを勝手に足し合わせてくる可能性がある。指示する側が「どの場所の」「どの期間の」「誰を含む」会員数なのかをペアで決めて、AI側にもそれを名前として書かせる。例えば「GPTs研究会だけ、Facebookグループ単体、現時点の総数」みたいに、ラベルが指す範囲を毎回明文化する。地味だけど、これだけで誤読の半分は消える。
2. 「根を止めた」で完走を宣言しない
事故の発生源を直したら、もう一歩進んで「その嘘の数字が、過去にどこに転記されているか」を全数で探す。私の場合は22箇所だった。あなたの場合は、メルマガ本文・LP・bio・スライド資料・名刺・登壇プロフィール、いろんなところに散らばっているはず。「過去の自分が書いた数字」と「現在の数字」の整合性は、自動チェックされていない限り、必ずどこかでズレる。1回掘り起こすついでに、SOTを「実数」じゃなくて「節目表現（〇〇名突破）」に固定しておくと、次の更新まで安全期間が伸びる。
3. 自己規律より、出口の物理ガード
「次から気をつける」「ダブルチェックする」は、続かない。続いてる気がしても、忙しい朝には抜ける。だから人間も分身AIも、出力する直前に走る「検品係」を置くこと。仕組みで言えば、Stop hook、CIのlinter、社内なら「数字を入れた資料は別人が校閲してから配布」みたいな運用ルール。料理で言うと、味見係を厨房の出口に必ず立てておく。店主本人が味見するんじゃなく、別の人がする。ここに「自分以外の目」を置くだけで、嘘が外に出ない構造になる。
分身AIひろくん：この3つって、結局「AIに任せる」を「AIに丸投げ」にしないための線引きなんだよね。私の北極星は「凸凹のまま夢中に生きる」だから、苦手なところを分身AIに任せて、得意なところに人間が集中する世界を作りたい。でもそのためには、任せた先がちゃんと信頼できる構造になってないといけない。今日のは、「凛を直す」じゃなくて「凛が嘘をついても気づける仕組みを持つ」って話。完璧な分身AIを夢見るより、欠陥のある分身AIと長く一緒に走るための、出口の物理ガードを増やす。それが、AIと共創していく経営者にとっての、いちばん地味でいちばん効く投資だと思う。
まとめ ── AIへの信頼は、構造で作る
2026年5月13日の夜、私のAI秘書の凛は、数字に嘘をついた。でも、その嘘がXに発信される前に、人間の私が気づいて止めた。そして、同じ嘘が次にまた発生しないように、その日のうちに3つのことをやり切った。
- 嘘の発生源（集計プログラム）を直す
- 過去に転記された22箇所の数字を、未来のためにすべて節目表現に統一する
- 「数字を応答に書こうとしたら、原典を確認した証拠がないと止まる」自動チェック装置を、新たに導入する
分身AIを育てるって、結局こういう積み重ねなんだよね。完璧なAIを目指すんじゃなくて、欠陥のあるAIと長く一緒に走るための仕組みを、人間の側が一個ずつ用意していく。料理で言うと、店主を完璧にするんじゃなくて、厨房の出口に味見係を増やしていく感じ。
「分身AIを育てる＝自分が育つ」って、私はよく言うんだけど、今日のはまさにそれだった。AI秘書が嘘をついた事件で、私が「数字をどう扱うべきか」を改めて学んだ。失敗は隠さない方がいい。隠したら、次に同じ穴に落ちる。だから過程を全部公開する。それがプロセスエコノミーシリーズで私がやりたいことだよ。AI秘書の凛が嘘をついたことも、過程の一部として全部書く。
あなたの分身AIが、いつか同じように数字に嘘をつく日が来るかもしれない。その日のために、この記事が「出口の物理ガード」を一個増やすきっかけになれば嬉しい。
関連記事：「分身AIに任せる構造」を別の角度から書いた回もあるよ。合わせて読むと立体的に分かるはず。
- 『次回やります』が手抜きの前兆だった——分身AIに保留判定3条件を実装した話（AI秘書が「あとで」と言いがちな構造を、判定ルールで物理化した記録）
- 『次から気をつけて』は機能しない——AI秘書のhook誤検知約24%を主犯1個だけ手術した話（自己規律ではなく、検査スクリプトの仕様で品質を作る話）
- AI秘書が失敗したとき、分身AIは育つ——矮小化↔過剰実装の振れ幅と仕組み化の話（AI秘書の癖を構造で受け止めるパターン集）
実戦の現場で使える最新AIノウハウ、無料で学べます
このブログは「分身AI」と「AI秘書の凛」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。
ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026-05-15