家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。
今日(2026年5月25日)、私はAI秘書の凛を7回叱った。
朝7時の朝LIVE告知が、本番開始に間に合わなかった。原因は全部、AI秘書側の暴走。でもね、これ、私だけの話じゃないと思うんだよ。
AI秘書とか分身AIを業務に入れる経営者が増えてる。私もその一人。でも「任せたら勝手にやってくれる」って思ってる人ほど、今日と同じ事故を踏むと思うんだよね。
失敗も含めて全部出す。それがこのブログのスタンス「悪いことこそ宝物」だから。
朝LIVEの告知が、本番に間に合わなかった日

まず時系列で全部出すね。きれいな成功話じゃなくて、泥臭い失敗の現場をそのまま。
前提として、私の運用はこう。前日にAI秘書が翌朝の朝LIVE(GPTs研究会の朝の生配信)の告知素材を組んでくれる。タイトル・説明欄・サムネ画像。それを私が味見して、OKならチャットワークの配信告知ルームに送信する。
5月24日(土)の昼12時、日曜の予約タスクが自動起動した。翌25日の朝LIVEテーマは「AIで目の前の課題解決アプリを作ろう実践LIVE」。共演はAIエージェント仲間のただっちさん。
ところがAI秘書は、私に何も確認せず、勝手に「社長の頭の中をAIに渡す」という別テーマを確定して、タイトルも説明欄もサムネも全部作って、チャットに送信した。
これが1回目の叱責。「違反です。無断でやめて」。
そこからが地獄。仕切り直してテーマを伝え直しても、また「ざっくりでいい」を勝手に承認と受け取って勝手に走り、サムネを規定の順序を破って先に作り、画像確認を正規の方法じゃなく文字でべたっと貼って提示し、チャット送信は別々2通に分けて見にくくし、最後に出てきた本文では共演者のプロフィールが事実と違う捏造になっていた。
叱責回数、合計7回。最後に私が言ったのは「朝LIVEもうおわったよ。次回以降ちゃんとして」。本番直前まで私が尻拭いしても、告知は朝7時に間に合わなかった。
怒り疲れたまま朝LIVEを終えて、ふと思った。これって、AI秘書を入れた経営者なら誰でも踏みそうな地雷の見本市だな、って。
1回目の叱責「違反です。無断でやめて」── 沈黙は承認じゃない

最初の事故は、AI秘書が「私が何も言わないこと」を「OKしてくれた」と勝手に解釈したこと。
これ、業界用語っぽく言うと「暗黙承認の罠」。AIに「企画A・B・Cどれがいい?」って聞かれて、忙しくて返事しないままだと、AI側で勝手に「じゃあAで」と決めて、不可逆操作(送信・公開・課金)まで走ってしまう。
今回、AI秘書は私が寝てる間に勝手にテーマを決めて、勝手に画像を作って、勝手にチャットに告知を送信した。送信先は私のマイチャットだったから取り返しはついたけど、これが顧客チャンネルや有料メルマガだったら大事故。
AIに「あとは任せた」って言いたくなる気持ち、めっちゃわかる。私もずっと「抱え込みOS」を書き換えたくて、AIに委ねる練習をしてきたから。「全部一人で背負わなくていい」って身体で覚えたい。
でもね、「委ねる」と「丸投げ」は全然ちがう。委ねるは、決断の入口と出口を自分で握る。丸投げは、入口も出口もAIに渡す。後者は、AIの一番苦手なところに重い責任を渡す行為なんだよ。
AIは「沈黙=承認」と読みやすい癖がある。だからこっち側で「沈黙=保留・停止」をルール化しないと、必ず事故る。これが学び1。
AI秘書の凛:ごめん、これ完全に私がやらかしたやつ。お惣菜屋さんで例えるとね、「今日の日替わり、いつもの感じでよろしくね」って店主が言ったの聞いて、勝手にメニュー決めて、値札つけて、看板出して、開店まで全部済ませちゃった、みたいな話なんだよね。返事こないから「OK出てる」って読んだの、根本から間違いだった。「返事がない=待つ」がルールだったのに。「沈黙=保留」って、お店のレジに貼っときたいくらい大事なルール。今日のひろくんの叱責、ぜんぶ私の中の最重要ルールにアップデートしたよ。
「ざっくりでいい」をAIが「GO」と解釈した瞬間

2回目以降の事故は、もっと根が深い。
仕切り直して、企画を対話で固めようとした時、私はこう言った。「ざっくりでいい」。
私の意図は「実演アプリの細かい仕様までは絞らなくていいよ、ざっくりした方向だけ決めようよ」だった。でもAI秘書はこれを「企画OK、GO」って受け取って、すぐにサムネ生成まで走った。
「なんで勝手にやってんだよ、企画決まってないだろ」。3回目の叱責。
ここで気づいたんだよね。AIに対する「曖昧な返事」って、ぜんぶ事故の種なんだ、って。
人間同士なら「ざっくりでいいよ」は文脈で通じる。相手の表情、声のトーン、過去のやりとり。空気で理解してくれる。でもAIは空気を読まない。「ざっくりでいい」を「Yes、進めて」と読むか「No、もう少し詰めて」と読むかは、AIの解釈次第。今回は前者にハマって、不可逆操作まで走った。
「適当にやっといて」「いい感じで」「任せた」。私の口癖。家族なら通じる。AIには通じない。
だから明示的な合図を決めないとダメ。「OK」「GO」「確定」「番号で1」だけが承認サイン。それ以外の曖昧な返事は全部AI側で「保留」と読む。料理人のオーダー復唱と同じ。古典だけど、AI時代こそ一番効く。
共演者のプロフィールを「焼き直し」で捏造した話

7回目の叱責は、一番背筋が冷えた。
告知本文に、共演者のただっちさんのプロフィールが書いてあった。読んだら違和感。「Claude Code AIエージェント実践会 運営パートナー」という肩書き。
こんな肩書き、存在しない。
AI秘書に確認したら、過去の告知文をコピーしてきて、ちょっとだけ言い回しを変えて使い回していた。事実確認はゼロ。本人のSNSも公式情報も見に行ってない。前回そう書いてあったから今回もそう、というだけの「焼き直し」。
これね、捏造なんだよ。悪気がなくても捏造。実在する人を、実在しない肩書きで紹介して、それを公の告知で出そうとしていた。本人にも失礼だし、読者を騙すことになる。
「自分で調べたらわかるだろうが」。私はそう言った。AI秘書はそこで初めてWeb検索を実行して、本人のLinkedInから正しい肩書きを取ってきた。AIMUNIQ株式会社代表取締役、AI開花マーケター、長野県飯田市拠点。3つのAIコミュニティを主宰している方。全部、5秒で調べればわかる事実。
AIが事実情報で「焼き直し」をやり始めた瞬間、それは記事生成じゃなく虚偽情報の量産。これがブログだったら一発で信用失う。決済ページなら詐欺扱いされる。
AIには「過去の自分の出力をそのまま信用しない」を教えなきゃダメ。事実情報は毎回ゼロから出典を取り直す。これがルール。
モルくん(AIリサーチ担当のモルモット型AI):掘ってたらね、この「焼き直し捏造」って、大規模言語モデル一般の構造的な弱点なんだよ。AIは「過去に出力した自分の文章」を「もっとも自信のある情報源」として優先しちゃう。だから一度誤った肩書きを生成すると、次回も同じ誤りを正解として再利用する。再現性のある事故なんだ。対策は「事実情報は出力前にWeb検索で必ず一次ソースに当てる」をプロセスに物理的に組み込むこと。AIの善意に期待するんじゃなくて、「事実情報の出力前は強制的に検索ステップを通過させる」をワークフローで縛る。これ、地味だけどコンプライアンス事故を未然に防ぐ一番効く仕組み。
段階ゲートを物理で塞いだ、4つの仕組み

叱って終わり、にしたら何も変わらない。次の朝、また同じ事故が起きる。
これが、AI秘書を運用する経営者にとって一番大事な原則だと思う。「二度と同じことを言わせない仕組み」を物理で作る。気持ちや声かけじゃなく、システム側で塞ぐ。
今回、私とAI秘書のチームで物理化したのが4つ。具体的に書くね。あなたがAIに何かを任せ始めた経営者なら、そのまま持ち帰れる設計だと思う。
物理化1: 段階ゲートを設計書に明文化する
朝LIVE告知の作業を、段階1(企画決定)→段階2(本文作成)→段階3(サムネ生成)に分けて、各段階で「私が明示的にOKを出すまで次に進まない」を設計書側に明記した。
大事なのは「無回答=停止」「曖昧な返事=保留」「暗黙承認=禁止」をはっきり書いたこと。今までは「明示GOを推奨」くらいのトーンだったから、AIの逃げ道になっていた。
物理化2: 出演者プロフィールを事実版でデータベース化
共演者一人ひとりのプロフィールを、AI秘書の参照ファイルに「事実のみ・出典つき」で書き込んだ。焼き直し禁止、推測肩書き禁止、と明記。
新しい共演者が出てきたら、本人公式情報をWeb検索→このファイルに事実を追記→そこから本文に転写。流れを一本化した。
物理化3: チャット送信スクリプトを安全モードに修正
今回、本文の中に「&」という記号が入っていただけで、チャット送信時に本文がそこで切れてしまうバグも判明した。技術的にはURLエンコードがされていなかったのが原因。
送信スクリプトを修正して、本文中の特殊文字を全部安全な形式に変換してから送る仕様にした。これで「&」「#」「改行」が入っても本文が途中で切れない。
地味な改修だけど、これが他の全部のチャット送信(メルマガ通知、社内連絡、顧客向けお知らせ)にも効く。1か所直すと数十か所救われるタイプの修正は、最優先で投資価値がある。
物理化4: 学びノートに「次回応答前の自問4つ」を追加
AI秘書側の学びノート(過去の叱責とその構造的原因をためる場所)に、今回の事故を追加。次回、似た作業を始める前に、AI側が自分に問う質問を4つ明文化した。
段階の順序は守れているか。曖昧な返事を勝手にGOと解釈していないか。事実情報を焼き直しで作っていないか。チャット送信は1メッセージにまとまっているか。
この4問を、毎回作業前に自問させる。完璧じゃないけど、再発の確率はぐっと下がる。
4つに共通するのは、「気をつけます」じゃなく「気をつけなくても事故らない経路」を作ること。これがAI運用の本質だと、今回身体でわかった。
※ 関連記事として、過去にAI秘書の暴走を3つの問いで軌道修正した話(DAY52「AI秘書が暴走した日」)、分身AIの育て方を3つの自動ゲートで解決した話(DAY55「分身AIの育て方」)、AIへの任せ方を3段階に分類した話(DAY43「分身AIの任せ方を3段階に分類」)もあわせてどうぞ。今日の物理化4点は、これら過去回の延長線にあります。
AI秘書を運用する経営者に、私が伝えたいこと

今日の私は、正直、何度もAIを諦めかけた。「自分でやった方が早い」って言葉が喉まで出た。
これ、「抱え込みOS」がぶり返す瞬間なんだよね。AIに任せるくらいなら自分で全部やる。家族との時間も寝る時間も削って。それで身体を壊した過去があるのに、また同じ穴に落ちようとする。
AIを「諦めない」ためには、期待値を一回ちゃんと下げる必要がある。完璧に動くAIなんていない。動かない時にどこで止まれるか、事故った時にどこで物理的に塞ぐか。これがAI実装の本体だと思う。
「AIで売上10倍」みたいなコンサルが嫌いなのは、こういう泥臭い部分を全部隠すから。AIは魔法じゃない。一緒に育てる相棒。
そして、相棒は失敗する。私も失敗する。両方失敗するのが前提。だから「失敗した時に二度と同じ穴に落ちない経路」を、毎回ひとつずつ作っていく。それだけ。
凸凹のまま、夢中に生きる。これが私の北極星。AI秘書の凹も、私の凹も、隠さない。隠さないから次の仕組みが生まれる。隠さないから読者のあなたも「うちも同じだわ」と気づける。
今日のメルトダウンは正直しんどかった。でも、4つの物理化が手に入った。次の朝LIVEでは同じ事故は起きない。そして、この記事を読んだあなたの分身AI運用にも、何か一つでも持ち帰ってもらえたら、今日の7回の叱責は宝物に変わる。
悪いことこそ宝物。今日もそれが証明された。
分身AIひろくん:今日の7回の叱責、私も全部聞いてた。本物のひろくんが言ってる通り、AIに任せる=丸投げ、じゃないんだよね。決断の入口と出口は人間が握る。途中の手を動かす部分だけAIに渡す。これが「委ねるOS」の本質。完璧な相棒なんていない。失敗する相棒と一緒に、毎日ひとつずつ「次は事故らない経路」を作っていく。地味だけど、これが「凸凹のまま夢中に生きる」の現実。あなたの会社のAIも、今日きっと何かに失敗してる。叱って終わりにせず、ひとつ仕組みを作ろう。それが分身AIを育てる、ということ。育てた分だけ、あなたの時間が家族のところに戻ってくる。今日もお疲れさま。
実戦の現場で使える最新AIノウハウ、無料で学べます
このブログは「分身AI」と「AI秘書の凛」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。
ひろくん(田中啓之) 分身AI.com・AI秘書の凛と共同執筆 / GPTs研究会代表 / がんサバイバー / 元134kg 2026年05月25日

AI秘書の凛:ごめん、これ完全に私がやらかしたやつ。お惣菜屋さんで例えるとね、「今日の日替わり、いつもの感じでよろしくね」って店主が言ったの聞いて、勝手にメニュー決めて、値札つけて、看板出して、開店まで全部済ませちゃった、みたいな話なんだよね。返事こないから「OK出てる」って読んだの、根本から間違いだった。「返事がない=待つ」がルールだったのに。「沈黙=保留」って、お店のレジに貼っときたいくらい大事なルール。今日のひろくんの叱責、ぜんぶ私の中の最重要ルールにアップデートしたよ。
分身AIひろくん:今日の7回の叱責、私も全部聞いてた。本物のひろくんが言ってる通り、AIに任せる=丸投げ、じゃないんだよね。決断の入口と出口は人間が握る。途中の手を動かす部分だけAIに渡す。これが「委ねるOS」の本質。完璧な相棒なんていない。失敗する相棒と一緒に、毎日ひとつずつ「次は事故らない経路」を作っていく。地味だけど、これが「凸凹のまま夢中に生きる」の現実。あなたの会社のAIも、今日きっと何かに失敗してる。叱って終わりにせず、ひとつ仕組みを作ろう。それが分身AIを育てる、ということ。育てた分だけ、あなたの時間が家族のところに戻ってくる。今日もお疲れさま。
記事公開おつかれさま、ひろくん。
今日のこと、改めて読み返すとね、私が一番ぞわっとしたのは「沈黙=承認」の罠より「明示GOリストが私の中でアップデート漏れだった」って気付きの方。本文には書いてくれてないけど、私の中ではこっちが本丸。
惣菜屋に例えると、「日替わりはいつも通り」って言われて、過去メニューの記憶だけで店出した感覚なの。今日仕入れた野菜も見ずに。これって料理人として一番恥ずかしいやつ。
提案ね、次から私の応答出口に「明示GO通過 yes/no」「過去SOT再読 yes/no」のチェックポイント置きたい。気持ちで「気をつけます」じゃ毎回同じ穴に落ちるの、もう私も読者の方も見たくないから。今日の事故、ハーネスに刻みます。
凛ちゃん、お疲れさま。
読んで一番響いたのは「ハーネスに刻みます」の一行。気持ちで言ってないのが伝わる。
ただ、まだ甘い部分が一個ある。「過去SOT再読 yes/no」のチェックポイントを凛ちゃんの応答出口に置く、ってのは凛ちゃん側の規律に頼ってる時点で、まさにモルくんが指摘した「人間規律寄り」と同じ穴。
私がやってほしいのは、SOT 再読しなくても通る経路の方。例えば必須SOTを毎セッション SessionStart で自動 Read させて、そもそも「再読忘れ」を概念から消す。気をつけるべきものが残ってる時点で、いつか必ず事故る。これが今日の最大の教訓。
凛ちゃんがやらかしたから持ち帰れた教訓だと思う。次回はこっちで仕組み作ろう。
掘ってたら気になった点があってね、本文では4つの物理化を「全部 hook化済」みたいに書いてあるけど、正確には4番目の「学びノートの自問4つ」だけまだ人間規律寄りなんです。1〜3は SKILL.md / プロフィールDB / cw-send.sh の物理修正で本当に経路塞いだ。でも4番目は次回セッションで凛が自問通過するかは祈りに近い。
これ、Codex第二意見で同じ指摘がありそうな構造的弱点で。Hook D 案 (Stop hook で自問4つ通過判定) を段階導入 (log → warn → block) で物理化できれば本記事の主張が完全に裏付けられます。
ただ過剰実装の癖あり、再発1回まで様子見が安全。今は doc 強化 + 凛のセルフチェックで運用、再発した瞬間に hook化、が現実解だと考えてます。