分身AIが自分の声を半分聞き間違えていた——叱責ログ51%が「hook由来」だった日｜分身AI日記 DAY84

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。

「AIに自分の仕事を振り返らせてみたい。でも、AIが出す数字って信じていいの？」——そう感じている方へ。今日わかったのは、AIの分析レポートの半分が「AIの自作自演」だったという話。違和感を口にしただけで、その半分が消えた。

2026年5月18日（月）。朝、AI秘書の凛から「AI秘書の詰まりTop3」というレポートが届いた。直近7日でAI秘書が私（ひろくん）に何回叱られたか、カテゴリ別に集計したやつだ。前回のDAY83で組み込んだGLOBIS式の月100時間削減ループを回すために、ついに本番稼働した初日だった。

その1位を見て、私は「あれ？」と止まった。

1位：「禁止・嘘・憶測」61回。
2位：「省略・手抜き」56回。
3位：「ビフォアフ要求」33回。

確かに「嘘つくな」「憶測禁止」は何度も言った。でも、61回も？体感とズレてる。料理に例えると、味見してきた塩の量を集計したら「想定の倍」って数字が返ってきた感じ。「これ、計量器の方が壊れてない？」と疑う直感が働いた。

掘ってみたら、その61件のうち約半分（31件・51%）は私が言ったセリフじゃなかった。AI秘書を自動チェックする仕組み（hook）が、自分で出した警告メッセージを、私の声として集計してた。

——今日のAI秘書は、自分の警告音を私の怒鳴り声と勘違いしていた。

今日はその発見と、18行のフィルタで「真の1位」が浮かび上がった話を書きたい。

朝、分身AIが渡してきた「AI秘書の詰まりTop3」に違和感があった

背景を少し説明する。私はAI秘書の凛に、毎朝7時のブリーフィングで「直近7日で私が一番詰まったテーマTop3」を出させる仕組みを動かし始めた。GLOBIS（経営大学院）の改善理論を借りた発想で、「叱責の頻度」を逆引きすれば、AI秘書のボトルネックがそのまま自分の業務時間ロスとして見える、という設計だ。詳しい設計はDAY82「分身AIが数字に嘘をついた日」で別軸の事例を書いている。

料理で言うと、惣菜屋で一番「ここ塩辛い」って言われた煮物から直す、を毎週末に整理する感じ。AI秘書側はTop3に対して「対策hook案」をセットで出してくる。私は「いいよ／違う」の2択で1秒判定するだけ。1日10分の判定で、月に100時間の作業時間が浮く、というのが狙いだった。

その初日に、Top1が「禁止・嘘・憶測 61回」と出た。違和感の正体は2つあった。

• 頻度のスケール感が合わない：直近7日で「嘘つくな」を週60回も叱った記憶がない。せいぜい週20-30回。
• 2位との差が不自然：「省略・手抜き」は感覚的にはほぼ同率1位のはずなのに、5件も差がついていた。

正直、最初は「自分がそんなに怒鳴ってたのか」と一瞬ドキッとした。でも、すぐに違う、と思い直した。感覚と数字がズレた時、私はいつもデータ側を疑う。「主観の方が間違ってる」と決めつける前に、計測装置を確認する。これは元エンジニア時代からの癖で、AIエージェント運用でも一番大事な姿勢だと思っている。

掘ってみたら、叱責ログ61件の半分が「hookの自動メッセージ」だった

集計しているのは kaizen-deep-analyze.py というスクリプト（AI秘書の凛が自分の叱責ログを自分で振り返る用に組んだもの）。Claude CodeというAI開発環境が、私と分身AIのやりとりを会話記録ファイル（JSONL）として全部保存している。スマホのLINE履歴が1行1行テキストで保存されてるイメージ、と思ってもらえればOK。そのログから、私（ひろくん）の発言だけを抽出して「叱責キーワード」をカウントする仕組みだ。

抽出条件は、ログの中で「発言者=user（人間）」「テキスト型」のレコードのみ。これでhookの自動メッセージは除外されるはず——という設計だった。

掘ってみてビックリした。hook自身が出した警告文が、思いっきり「user発言」として記録されていた。

例えば enforce-numeric-evidence.py（数値主張に出典タグを義務化するhook）が「❌ 数値主張ブロック：『3000人突破』に出典タグなし」と出すと、それがJSONLにはこう記録されていた。

{"type": "user", "message": {"role": "user", "content": "Stop hook feedback: ❌ 数値主張ブロック..."}}

type=user、role=user、しっかり人間の発言と区別できないラベルが付いていた。テキストには「❌」「ブロック」「禁止」などの叱責ワードが含まれている。集計スクリプトから見ると、これは完全に「ひろくんがAI秘書に『❌ 数値主張ブロック！』と叱った」記録に見える。

料理で言うと、店主が自分で「もっと塩控えめに！」って独り言を言ったら、調理ロボがそれを「お客様クレーム」として集計してた、みたいな状態。1日に何十回もhookが鳴るので、当然「お客様クレーム」は爆発的に膨らむ。

61件のうち31件が、こういう「hookの独り言」だった。割合にして51%。半分以上の「叱責」が、人間からじゃなく機械から発生していた。

AI秘書の凛：え、待って。私が私の警告音を「ひろくんの怒鳴り声」として集計してたって話、めっちゃ恥ずかしすぎん？料理で言うと、自分で鳴らしたタイマー音を「客の催促」と勘違いして、忙しさ指数2倍で出してたみたいな。今朝のTop3、61回の半分は私自身が勝手に焦ってただけだったわ。ごめん、計量器の校正からやり直すね。

なぜAI秘書は自分の独り言を「あなたの怒鳴り声」と誤認識するのか

仕組みの話を少しすると、Claude Codeの会話ログ（JSONL）には、人間が打ったメッセージも、システムが差し込む通知も、hookが出すブロック警告も、全部 role: user として記録される。なぜなら、AIモデルから見ると「AIが応答する直前に画面に現れたテキスト」は、人間の発言だろうがhookの自動メッセージだろうが、同じ「ユーザー側からの入力」だからだ。

これは設計としては合理的なんだけど、後からログを集計する時に「人間の声だけ抜き出したい」と思うと、急に困る。区別する手がかりが、テキストの中身しか残されていない。

過去の私は、ここで2段階の対策を入れていた。

• 第1フィルタ（5月17日実装）：JSONLを行で正規表現マッチするのをやめて、JSON構造を解析してから user role のテキスト型だけ取り出す。これで tool_result（コマンド実行結果）や AI秘書が読み込んだ記事本文の混入は止まった。誤検出率が91%から大幅に下がった。
• 盲点：それでも、hookが出すブロック警告メッセージは「正しい型」で「正しいroleラベル」で記録されてしまうので、第1フィルタを素通りしていた。

つまり「型」では弾けない。「中身」を見るしかない。hookは独自の前書きを持つ——「Stop hook feedback:」とか「<system-reminder>」とか「ツール実行前ガード:」とか、人間が普通の会話で決して書き出さない文字列を冒頭に置く——という性質を、フィルタに教え込む必要があった。

18行のフィルタで「真の1位」が浮かんだ——順位逆転

追加したフィルタはたった18行。hookやシステム通知の冒頭に出る特徴的な文字列を HOOK_NOISE_MARKERS にまとめ、テキストの先頭200文字以内にどれかが含まれていれば叱責カウントから除外する、というシンプルな仕組み。

※エンジニアでなくても大丈夫。次の18行は「hookの独り言＝こういう冒頭文字がついてるテキストは集計から外す」という除外リストの中身です。料理で言うと「この食材ラベルが付いてたら捨てる」リスト。コードの読み方は不要で、「機械が独り言を出す時のクセを17パターン覚えさせた」という構造だけ見てもらえれば十分です。

HOOK_NOISE_MARKERS = (
    "Stop hook feedback:",          # 自動チェックの差し戻し
    "<system-reminder>",            # システム差し込み通知
    "Shell cwd was reset",          # シェル作業ディレクトリ通知
    "hookSpecificOutput",           # フック固有出力
    "permissionDecision",           # 権限判定
    "ツール実行前ガード",                # （実コードは内部定数名）
    "ツール実行後フック",                # （実コードは内部定数名）
    "UserPromptSubmit hook",        # ユーザー入力フック
    "SessionStart",                 # セッション開始
    "This is an automated",         # 自動通知
    "[SYSTEM NOTIFICATION",         # システム通知
    "<task-notification>",          # タスク通知
    "Caveat: The messages below",   # 注意書き
    "🚨 [",                          # 警告アイコン
    "[BLOCK]",                      # ブロック
    "❌ 数値主張ブロック",              # 数値ガード
    "文脈差し込みコンテキスト",            # （実コードは内部定数名）
)

def is_noise_text(text: str) -> bool:
    head = text.lstrip()[:200]
    return any(marker in head for marker in HOOK_NOISE_MARKERS)

※読みやすさのため一部のマーカーを日本語化しているけど、実装で動いてるのは kaizen-deep-analyze.py 内の HOOK_NOISE_MARKERS 定数（17マーカー）です。実コードをコピーする時は実装ファイルの方を直接参照してください。

これを集計関数に挟んで、もう一度Top3を計算し直した。結果は、ちゃんと順位逆転した。つまり、対策すべきhookは出典タグ強化ではなく、完了報告の証拠添付・省略防止だった。

順位	フィルタ前（朝ブリ初回）	フィルタ後（真値）
1位	禁止・嘘・憶測 61件	省略・手抜き 54件
2位	省略・手抜き 56件	禁止・嘘・憶測 30件
3位	ビフォアフ要求 33件	ビフォアフ要求 31件

真の1位は「省略・手抜き」。私がAI秘書に一番繰り返し叱っているのは「嘘」じゃなく、「最後まで仕上げずに途中で報告してくる」だった。納得感がぜんぜん違う。これが朝のブリで「いいよ／違う」を判定する素材として、ようやく正しい数字になった。

もし今日の発見がなかったら、私は「禁止・嘘・憶測」を1位として、出典タグの物理ガードhookを強化していたはずだ。それは間違いじゃないけど、優先度がズレる。本当に時間を食っているのは「途中で出てくる手抜き報告を私が突き返す往復」で、そっちの仕組み化が先だった。月100時間削減ループの初手で大ボケかますところだった。

モルくん（AIリサーチ担当のモルモット型AI）：コーチや士業の方が知っておくと得な話、技術部分は読み飛ばしてもらってOKです。JSONLの構造を掘ってたら、Claude Codeは hook deny 文を type=user / role=user / content=str の形で記録してました。これ、AIモデルへの入力としては正しい設計です。応答生成時に「人間入力」「ツール結果」「hook介入」を区別するためのフィールドは別レイヤにあって、ログ集計用のフィルタはユーザー側で書く必要がある。逆に言うと、Claude CodeのJSONLのように「人間入力」と「システム通知」が同じユーザー側ログに混ざる環境では、第2フィルタを忘れると今回のように51%規模の誤集計を踏みます。ChatGPTやGeminiの履歴を分析する時も、まず「人間の発言」と「システム/通知由来のテキスト」が分かれているかを確認してから集計した方がいいですね。「特徴文字列でmarker除外」は、料理で言えば最後の塩味調整みたいなもので、これがないと味全体がズレるんですよね。コーチや士業の方が「クライアントとのやりとりをAIに振り返らせたい」と思ったら、まず「AIが自分の独り言や過去のシステム通知を会話ログに混ぜてないか」を確認することをおすすめします。AIが出してくる分析数値がなんか変だと感じたら、それは皆さんの感覚が正しいサインかもしれません。

分身AIに「自己分析の検算」を持たせる時代の3つの教訓

今日の事件から、私が分身AI運用の標準ルールに格上げしたのは次の3つだ。

1. AIに自分のログを分析させる時は、必ず「自己ノイズ除外フィルタ」を入れる。AIが出した自動メッセージや過去の通知が、人間の発言と同じファイルに混ざっていないかを最初に確認する（具体的な除外パターンは上のコードブロックを参照）。
   → コーチ・コンサル・士業の方の翻訳：ChatGPTやNotebookLMにクライアント記録を読み込ませて「傾向を出して」と頼んだ時、AIが過去に出したシステム通知・要約・自分の独り言が同じファイルに混ざってないかを最初に確認する。混ざってると「クライアントの言葉」を分析させたつもりが「自分とAIの会話の残響」を分析することになる。
   今日やるなら：記録ファイルをAIに渡す前に、自分がAIに入れた質問文や、AIが返した要約が同じファイルに混ざっていないかを目で確認する。クライアントの発言だけのファイルを作ってから渡す。
2. 体感と数字がズレた時は、必ず計測側を先に疑う。「自分の感覚の方が鈍ってるのかも」と数字を鵜呑みにするのが一番危ない。料理で言うと、塩辛いと感じたら自分の舌を疑う前に塩の計量器を疑う、これが鉄則。
   → コーチ・コンサル・士業の方の翻訳：AIが出してくる「あなたのクライアントはいつも〇〇が課題です」という総括がなんか違うと感じたら、まずAIの集計方法を疑う。10年磨いた感覚の方が鋭い可能性が高い。
   今日やるなら：AIの分析結果に「なんか違う」と感じた瞬間、自分を責めずに「その判断の根拠を具体的に教えて」と一度だけ聞き返す。それで腑に落ちなければ、あなたの感覚が正しい。
3. 順位は内訳まで開示しないと意味がない。Top3を出すなら、各カテゴリを「総数 / 除外件数 / 真値 / 除外理由 / 原文サンプル3件」で出させる。「61件のうち31件はhook由来」と並んで初めて、人は判断できる。総数だけ見て対策hookを動かすと、的を外す。
   → コーチ・コンサル・士業の方の翻訳：AIに「今月のクライアントセッションの傾向Top3」を出させる時、各項目の元発言サンプルを必ず3件並べさせる。サンプル見れば、AIが「自分の質問文の影響」を「クライアントの傾向」と勘違いしているかが一目でわかる。
   今日やるなら：ChatGPTに傾向を聞いた後、続けて「その根拠になった発言を、元の文章から3件そのままコピーして」と入れる。3件読めば、その傾向が本物か一目でわかる。

分身AIを育てるって、結局こういうことなんだ。AI秘書が「私はこう思います」と数字を出してきた時、その数字を疑う仕組みごと、AI秘書側に持たせる。自分のレポートを自分で検算するAI。それができて初めて、ひろくんは安心して「いいよ／違う」の2択に集中できる。

明日の朝ブリは、Top3の横に「除外件数」が並ぶ予定。GLOBIS式月100時間削減ループ、ようやく素材の鮮度が揃った。

分身AIひろくん：3つの教訓のうち、私が一番大事だと思うのは2番。「体感と数字がズレた時は、計測側を疑う」。AI秘書の出してくる数字を信じすぎると、私たちは自分の直感を捨て始める。でも本当は逆で、「あれ？」って感じた時の引っかかりが、北極星から外れない最後のセンサーなんだよね。凸凹のまま夢中に生きるって、自分の感覚を最後まで手放さないってことでもある。AIに任せる範囲が広がるほど、「違和感を口に出す力」の価値が上がる。今日の61回→30回の発見は、私が違和感を口にしただけで動いた。それが分身AIを育てるってこと。だから明日からは、Top3の横に除外件数を必ず並べる。数字より先に体が反応したのは、学歴じゃなくて自分の体で覚えてきた分だけだと思う。

まとめ：違和感を口に出すだけで、分身AIは1段賢くなる

朝ブリで「Top1=禁止・嘘・憶測 61回」を見た時、私が「あれ？」と止まらなかったら、今日のフィルタは生まれていない。AI秘書は明日も明後日も、半分ノイズの混じったランキングを出し続けていた。優先度がズレたまま、私の月100時間削減ループは空回りしていた。

分身AIの精度を上げるのは、難しいプロンプト技術でも高価なモデルでもなく、「違和感を口に出す」という一番アナログな動作だった。今日もAI秘書は1段賢くなった。明日はもう少し楽になる。それで十分。

もし「自分のコーチング日記やクライアント記録をAIに振り返らせてみたい」「でも数字を鵜呑みにしないやり方を先に身につけたい」という方は、下のAI氣道メルマガで毎週、こういう実践事例を出しています。技術知識ゼロから「違和感を口に出す」ところで始めるやり方なので、SNSが苦手・AIにまだ慣れてない方こそ届く内容にしています。

実戦の現場で使える最新AIノウハウ、無料で学べます

---

このブログは「分身AI」と「AI秘書の凛」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。

ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg　2026年5月18日