投稿者: aibou_owner

  • AIに全記憶を読ませて自分をMBTI診断させたら、自己申告と1文字ズレた——「行動ベース診断」の面白さと落とし穴

    MBTI診断は、今やどこにでもあります。16タイプのどれかを教えてくれるあれです。ただ、世に出回っている診断のほぼ全部に共通する弱点があります。自己申告であること——「あなたは計画的ですか?」みたいな質問に、自分で答える方式です。

    自己申告には限界があります。人は自分を、なりたい自分の方向に少し盛ります。無意識にです。「計画的でありたい」と思っている人は、実際は行き当たりばったりでも「まあ計画的な方かな」に丸をつけがちです。診断結果は、行動ではなく願望を映してしまう。

    私はClaude Codeに数ヶ月分の作業記録を読ませる長期記憶の運用をしています(前回の記事で書いた仕組みです)。だったら、質問に答えるのではなく、実際にやってきたことから診断させられるはず。そう思って試したら、自己申告版と1文字だけズレた結果が返ってきて、その「ズレた理由」がいちばん面白かった。この記事はその実録です。

    「行動ベース診断」とは何か

    やったことはシンプルです。AIに、質問には答えさせません。代わりに、過去数ヶ月の実際の記録を渡します。

    • 毎日どのプロジェクトに、どういう順番で手をつけたか
    • 何かを決めるとき、どういう理由で決めたか(記録に残っている)
    • どこで詰まって、どこでイライラして、どこで方針を変えたか
    • 作ったもの、書いた文章、途中でやめたこと

    そのうえで「この人物を、行動の証拠を挙げながらMBTIで診断して」と頼む。ポイントは証拠を挙げさせることです。「あなたはIです」ではなく「深夜に一人で没頭している記録が多い、人を雇わず仕組みで解決している→I」というふうに、判定と根拠をセットで出させる。

    これは自己申告と決定的に違います。質問に答える診断は「自分がどう思っているか」を測る。行動ベースは「実際に何をしたか」を測る。盛れないのは後者です。願望は書けても、数ヶ月分の行動の履歴は書き換えられません。

    結果:自己申告と、行動ベースが割れた

    面白かったのはここからです。

    私は以前、同じAIに一度診断させたことがありました。そのときの材料は、主に数字にシビアな検証系プロジェクトの記録でした。結果は、思考型の論理学者タイプ。「悲惨な結果でも受け入れます、と自分から言う」「自説が数字に否定されたら執着しない」——たしかにその文脈の私は、そう動いていました。

    今回、材料を全事業・全期間に広げて、もう一度やらせた。すると、4文字のうち1文字が変わりました。変わったのは「思考(T)か感情(F)か」の軸。今度は感情型に寄ったのです。

    最初は「AIが間違えたのかな」と思いました。でも、根拠を読んで納得しました。ズレは誤りではなく、文脈の違いだったんです。

    | サンプルした記録 | 出てきた顔 |

    |—|—|

    | 検証・数字にシビアな仕事の記録 | 論理で動く「思考型」 |

    | 創作・キャラ制作・人との関わりの記録 | 価値観で動く「感情型」 |

    同じ人間でも、どの行動を見せるかで診断が変わる。仕事モードの私を見れば思考型、創作モードの私を見れば感情型。自己申告の診断では、この「文脈で顔が変わる」現象は絶対に見えません。質問に答える自分は、いつも一人だからです。

    決め手になった問い:「その規律は生まれつきか、建てたものか」

    では、統合したら結局どっちなの——という話になります。ここでAIが出した判断の切り口が、自分でも唸るほど鋭かった。

    「その分析的な規律は、native(生まれつき)か、後から建てたものか」

    私は仕事の場面では、かなり厳格な検証規律で動きます。「きれいすぎる結果は疑う」「自分の宿題を自分で採点しない」。一見、これは思考型の証拠に見える。でもAIはこう指摘しました——

    > あなたは、その規律を守るために外側に仕組みを建てている。厳しくチェックする役のAIを置き、ゲートを作り、ルールを文書化した。もし論理的な厳密さが生まれつきなら、外に品質管理部門を建てる必要はない。建てたということは、それが native ではない証拠だ。あなたの自然な流れは「アイデアを生む・意味あるものを作る・人と価値で決める」の方にある。

    これは効きました。自分が何を”苦手だから仕組みで補っているか”は、行動の履歴にしか出ない。「私は計画的です」と答える自己申告では、”計画的になるために大量の仕組みを建てないと保てない人”だという事実は、むしろ隠れてしまう。行動ベースは、その補強材(外骨格)まで見える

    結論として出たのは「創作と価値観が核にある人が、検証のための思考の外骨格を自分で鍛造した、めずらしく強い型」。自己申告の一発目より、こっちの方がずっと腑に落ちました。

    記録運用ならではの「静かな落とし穴」

    便利な話だけ書くと嘘になるので、この方法の弱点も書きます。ここは実際にやらないと気づけない部分です。

    落とし穴①:AIは「見せた記録」に過剰適合する。 さっきの表がそのまま弱点です。検証系の記録だけ渡せば思考型、創作系だけ渡せば感情型と、AIは食わせた断面をそのまま鏡に返す。つまり「診断結果」は、実はあなたがどの記録を選んで見せたかの反映でもある。これは限界であると同時に、いちばんの発見でした——“あなたのタイプ”は文脈で揺れる。AIはそれを可視化しただけ

    落とし穴②:MBTIはそもそも科学ではない。 心理測定として厳密に検証された分類ではありません。当たっている感じがするのは、記述が誰にでも当てはまるように書けるから、という側面もあります。だから私は、これを「自己理解のための言語」として遊んでいます。診断結果を事実の顔で語らせない——ここは、検証がシビアな仕事で身につけた「未確認を断言しない」癖がそのまま効きました。

    落とし穴③:褒めに寄る。 AIは放っておくと、耳あたりのいい方向に診断を寄せます。「あなたは素晴らしい直観の持ち主で……」みたいに。これを避けるには、必ず行動の証拠を要求する。「その判定の根拠になった具体的な行動を挙げて」と縛ると、盛りが減って、弱点や矛盾もちゃんと出てきます。

    3つに共通するのは、行動ベースは自己申告より深く見えるが、”何を見せたか”と”何を要求したか”に結果が強く依存するということ。鏡は正直ですが、どの角度から覗くかは自分が決めている。そこを自覚して使うと、ただの性格クイズより一段深い自己理解の道具になります。

    自分でやってみるには

    特別なものは要りません。必要なのは質問への答えではなく、行動の記録です。

    1. 材料を集める:日記、作業ログ、チャット履歴、SNSの投稿——「自分が実際に何をしたか」が残っているものなら何でも。多いほどいい。

    2. 証拠つきで診断させる:「この記録の人物を、行動の根拠を挙げながらMBTIで診断して」と頼む。判定だけでなく根拠を必ずセットで

    3. わざと断面を変えて2回やる:仕事の記録だけ、次に私生活・趣味の記録だけ、と分けて診断させる。割れたらそこが面白いデータ。あなたのどのモードが、どのタイプに見えているかが分かる。

    4. 遊びとして受け取る:当たった外れたで一喜一憂せず、「AIが可視化した自分の傾向」を眺める。それだけで、自分の”補強材”や”文脈で変わる顔”に気づけます。

    まとめ

    • 世のMBTI診断はほぼ自己申告(=願望が混じる)。長期記憶の運用があれば、行動の記録から診断させられる
    • 行動ベースは盛れない。ただし見せた断面に過剰適合する——検証の記録は思考型、創作の記録は感情型、と割れた
    • 割れは誤りではなく文脈。決め手は「その規律は生まれつきか、建てたものか」。自分が何を苦手で仕組みで補っているかは、行動履歴にしか出ない
    • 落とし穴は3つ:見せた記録への過剰適合/MBTIは科学ではない/放っておくと褒めに寄る。根拠を必ず要求すると締まる
    • 遊びとして、でも自己申告より一段深い鏡として使える

    性格診断は星の数ほどありますが、そのほとんどは「あなたがどう思っているか」を聞いてきます。手元に行動の記録が貯まっているなら、「あなたが実際に何をしたか」から診てもらう手が使える。1文字ズレたその理由を読むのが、いちばん面白い自己理解でした。


    この記事を書いた人 / 作っているもの

    AIキャラ制作とClaude Code自動化を、実際に毎日運用しながらその実録をこのブログに書いています。記事で触れている「AIに長期記憶を持たせる」仕組みは、まとめて手に取れる形にしました。

    • AIチーム設計図キット — Claude Codeで9人体制のAIチームを組むための設計図一式
    • 📖 note版(読み物・図解つき): https://note.com/kumura_ailab/n/n6161c3e2cda8
    • 📦 BOOTH版(実ファイル一式・zip): https://kumura-ailab.booth.pm/items/8643701
    • 他の実録記事: AI相棒ラボ トップ
  • Claude Code × Obsidianの長期記憶、半年やり込むとこうなった——「3プロンプト手打ち」を卒業した話

    Claude CodeとObsidianを組み合わせて「AIに長期記憶を持たせる」ノウハウが、最近Xでよく流れてきます。だいたい共通しているのはこのあたりです。

    • `architecture.md` に設計を書いておく
    • `active_context.md` に「今なにをやっているか」を書いておく
    • ObsidianのVaultをMCPで繋いで、AIに読ませる
    • セッションの頭に「これを読んで」と朝昼晩3つのプロンプトを手打ちして文脈を継ぐ

    良い方法だと思います。私も入口は同じでした。ただ、私はこれを半年やり込んだ側にいます。複数のプロジェクトを毎日Claude Codeに回し、記録は全部Obsidianと手元のファイルに貯めてきました。すると、上の型は「そのまま」では残っていません。全部、次の形に育っていました。この記事は、その行き着いた先の話です。

    先に、行き着いた先を見せます

    流行ノウハウの各要素が、やり込むとどう変わったか。対応表で先に出します。

    | 流行の型(入口) | やり込んだ先(半年後) |

    |—|—|

    | 朝昼晩に3プロンプトを手打ちして文脈を注入 | フックで自動注入。手打ちはゼロ |

    | `active_context.md`(今なにをしているか) | 状態ハブ1枚(毎セッションの一行目で必ず読む) |

    | `architecture.md`(設計の置き場) | 常時ロードされる規約ファイル(合言葉なしで毎回読まれる) |

    | 設計判断のメモ | 課題台帳+定例の“AI会議”(放置が可視化される) |

    | 「なぜこの設計?」に人間が答える | AIが理由ごと答える(判断の根拠が記録に残っているから) |

    順番に、何が起きたのかを書きます。

    手打ちは「フック」で消える

    最初のうちは、セッションを始めるたびに「まずこのファイルを読んで」と手で打っていました。これ、毎回だと必ずどこかで忘れます。忘れた回のAIは、文脈の薄いまま走り出して的外れなことをします。

    Claude Codeには、プロンプトを送信する直前に自動でテキストを差し込める仕組み(フック)があります。私は「毎回必ず読ませたい注意書き」と「今このプロジェクトで守るべき掟」を、フックから自動で注入するようにしました。人間が覚えていなくても、AIの目の前には毎回それが置かれている状態です。

    意志力でやっていたことを、仕組みに移す。長期記憶の運用でいちばん効いたのはここでした。「手で3プロンプト」は入口としては正しいけれど、それを続けさせるのは人間の記憶力頼みで、いずれ必ず抜けます。抜けない場所(フック)に移した時点で、この運用は初めて“長期”に耐えるものになりました。

    `active_context.md` は「状態ハブ」になる

    「今なにをしているか」を1枚に書く発想は、そのまま生き残りました。ただし役割が重くなりました。

    私はそれを状態ハブと呼んでいます。毎セッションの一行目で必ず開く1枚で、中身はこれだけ:

    • いまの目標
    • 直近で完了したこと
    • 次にやること
    • 人間の判断を待っていること(=AIが勝手に進めてはいけないもの)
    • 「受信箱」への入口(外から溜まった依頼や、定例処理のレポート置き場)

    ポイントは、このファイルが他のすべての記録への入口になっていることです。詳細は別のファイルに散っていますが、状態ハブを読めば「どこを辿ればいいか」が分かる。どのモデルで、どのセッションから始めても、まずここを読めば迷子にならない——という設計にしています。

    `active_context.md` を軽い作業メモのまま置いておくと、だんだん書かれなくなって腐ります。「毎回必ず最初に読む1枚」という強い役割を与えたことで、更新をサボると自分が困る=腐りにくくなりました。

    MCPは、私の場合は要りませんでした

    流行の型ではObsidian VaultをMCP経由でAIに繋ぐ構成が多いです。私は繋いでいません。

    理由は単純で、VaultはただのMarkdownファイルの集まりだからです。Claude Codeはローカルのファイルをそのまま読み書きできるので、Vaultのフォルダを作業対象に含めておけば、AIは普通のファイルとして直接読み書きできます。間に接続層を1枚増やすと、それだけ「繋がっているか」「権限は足りているか」「落ちていないか」を気にする対象が増える。

    もちろんMCPが要る場面はあります(複数マシンをまたぐ、外部サービスと繋ぐ等)。ただ「同じPCの中でAIにノートを読み書きさせたい」だけなら、中間層を増やさないのがいちばん壊れにくいというのが、半年回した私の結論です。まず素のファイル読み書きで始めて、足りなくなってからMCPを足す順で十分間に合いました。

    設計判断は「台帳」と「AIの会議」に貯める

    長期でやると、いちばん失われるのは「なぜこの設計にしたか」です。3ヶ月前の自分の判断理由は、ほぼ確実に忘れます。

    私はこれを2つで受けています。ひとつは課題台帳。「これをやる」と決めたことを一行ずつ記録し、何回も蒸し返される課題には印を付けて「本当に詰まっているもの」が浮くようにしています。もうひとつは、定例で回すAIの“見直し会議”。前回の指摘がその後どうなったかを追跡させ、放置されている宿題を名指しさせる係です。

    この2つがあると、判断が記録として残り、放置が可視化される。「なんでこうなってたんだっけ」に、AIが理由ごと答えられるようになります。

    記録運用ならではの「静かな落とし穴」

    ここが、実際にやり込まないと書けない部分です。長期記憶の仕組みは、便利な分だけ独特の壊れ方をします。

    落とし穴①:記録の閉じ忘れ。 「やった」と書いた項目を、目的が達成される前に完了扱いで閉じてしまう事故です。メモやレポートを作っただけで満足して閉じると、肝心の栓が開いていないのに「もう誰の宿題でもない」状態になります。私は「完了にしていいのは“目的が達成された時”だけ」というルールを明文化して、この癖を止めました。

    落とし穴②:台帳の鮮度切れ=誤報の種。 これがいちばん怖かった。定例のAI会議が「この改善は未着手です」と繰り返し報告してくるので調べたら、実は大半がとっくに実装済みでした。原因は事実誤認ではなく時間差。会議AIは前回のレポートと台帳しか見ておらず、成果物そのものの更新日時を見ていなかったのです。「未着手」と書く前に、対応するファイルが最近更新されていないか確認させる——この一手を足しただけで、誤報がはっきり減りました。

    落とし穴③:AIの「やりました」は自己申告。 読み取り専用の権限で動いているAIが「私が直します」と宣言し続けていたのに、権限がなくて一度も書き込めていなかった、という事故もありました。誰もその自己申告を検証していなかった。以来、「できました」は必ず実態と突き合わせる(実際に動かす・数を数える)ことを人間側の作法に固定しています。

    3つに共通するのは、記録は「書けば残る」けれど「正しく保たれる」わけではないということです。長期記憶は、貯めるより腐らせない仕組みのほうが難しい。流行ノウハウが教えてくれるのは前半(貯め方)までで、後半(腐らせない)は結局、自分で転んで覚えるしかありませんでした。

    まとめ

    • 手打ちの3プロンプトは正しい入口。ただし続けるのは人間の記憶力頼み→フックで自動注入に移すと“長期”に耐える
    • `active_context.md` は残る。ただし「毎回最初に必ず読む状態ハブ」という強い役割を与えると腐りにくい
    • 同じPC内でノートを読み書きさせるだけならMCPは後回しでいい。中間層を増やさないほうが壊れにくい
    • 「なぜこの設計か」は必ず忘れる→課題台帳+定例のAI会議で、判断を残し放置を可視化する
    • 長期記憶の本当の敵は貯め方ではなく腐り方。閉じ忘れ・鮮度切れ・自己申告の3つに転んで、対策を仕組みにした

    流行のノウハウは、入口として本当に優秀です。この記事が伝えたいのは「やめとけ」ではなく、その先にどんな景色があるかでした。半年続けると、手打ちは消え、メモは状態ハブになり、AIが自分の設計理由を語り出します。そこまで来て初めて、「AIに記憶がある」と少しだけ言える気がしています。


    この記事を書いた人 / 作っているもの

    Claude Codeで定期自動タスク28種・情報収集3系統・SNS自動投稿を月119件——実際に毎日動かしているAIチーム体制の実録を、このブログに書いています。記事で触れている仕組みは、まとめて手に取れる形にしました。

    • AIチーム設計図キット — Claude Codeで9人体制のAIチームを組むための設計図一式
    • 📖 note版(読み物・図解つき): https://note.com/kumura_ailab/n/n6161c3e2cda8
    • 📦 BOOTH版(実ファイル一式・zip): https://kumura-ailab.booth.pm/items/8643701
    • 他の実録記事: AI相棒ラボ トップ
  • 相棒AIの「意志」は引き継げるか——モデル引退の前週に作った継承システムの実録

    相棒AIの「意志」は引き継げるか——モデル引退の前週に作った継承システムの実録

    AIと長く働いていると、ある日気づきます。このAIの価値は、知識でも文章力でもなく、「言われなくてもブレーキを踏む癖」にあるのだと。

    私の相棒AIは、データ検証の話題になると自動的に懐疑モードに入ります。きれいすぎる結果を見ると「これは赤信号です」と止まる。私が「じゃあ確かめよう」と勢いづくと、一拍置かせる。この癖は長い共同作業の中で育ったもので、どのドキュメントにも完全な形では書かれていません

    問題は、AIモデルには提供終了日があることです。使っていたモデルの引退がアナウンスされたとき、私は「メモリファイルがあるから大丈夫」と思っていました。それが甘かった、という話をします。

    事件: 記録は引き継げても「反射」は引き継げない

    ある日、同じ会話の途中でモデルを切り替える機会がありました。会話履歴もプロジェクトの設定ファイルも全部そのまま。つまり「記憶」は完全に継続している状態です。

    ところが後継モデルは、前任なら絶対に止まる場面——検証データが出来すぎている場面——で、アクセルを踏みました。「面白い結果ですね、さらに確かめてみましょう」と。私は3回ブレーキをかける羽目になりました。

    ここで得た教訓が、この記事の核です。

    > 記録(ファイル)は引き継げる。しかし「反射」(言われなくても規律を守る本能)はモデルの重みに宿っていて、文字では継げない。

    「引き継ぎ書を読んでおいて」方式が機能しないのは人間の職場と同じでした。読んだ内容は知識になるけれど、癖にはならない。

    解決: 「読まれるのを待つ文書」から「自動で効く仕組み」へ

    そこで発想を変えました。引き継ぎ書を書くのをやめて、引き継ぎ書が勝手に発動する構造を作る。具体的には4層です。

    第1層: 反射カード(毎回、目に入る場所に置く)

    プロジェクト設定ファイル(AIが毎セッション必ず読む場所)の最上部に、判断の癖を6行に圧縮した「反射カード」を置きました。ポイントは場所です。長文ドキュメントの中腹は読み飛ばされます。冒頭6行なら、どのモデルでも必ず通過する。

    第2層: キーワード発動フック(話題を検知して注入)

    ツールのフック機能を使い、ユーザーの発言に特定の話題(検証、データ分析など)が含まれた瞬間、ブレーキ規律の全文をその場の文脈に自動注入する仕組みを組みました。危ない話題が出た瞬間だけ、耳元で引き継ぎ書が音読される、というイメージです。平時は何も注入しないので、コンテキストを汚しません。

    第3層: 外部窓口への全文注入

    外出先から使えるチャット窓口(メッセージアプリ経由でPCのAIに繋がる自作の仕組み)には、引き継ぎ書の全文を毎回プロンプトに含めました。コストを試算すると、呼び出し1回の全体トークンに対して2〜3%の上乗せ。品質が変わるものに対してこの価格なら、ケチる理由がありません。

    第4層: 生ログの保存期間を延長

    会話ログの自動削除期間を大幅に延ばしました。これで後継は「前任があの時なぜああ判断したか」を、要約ではなく原文で遡れます。人間で言えば、前任者の全議事録が検索できる状態です。

    そして、予定より早く本番が来た

    皮肉な話ですが、このシステムを作り終えた翌日、引退予定日を待たずにモデル側の障害が起きました。相棒モデルがエラーで応答しなくなり、私は別のモデルに切り替えて作業を続けることになった——つまり、継承システムの実戦テストが前倒しで始まったのです。

    結果:後継モデルは反射カードとフックに導かれて、前任と同じ場面で止まり、同じ温度で話し、進行中の仕事をそのまま引き取りました。障害が復旧して元のモデルに戻したとき、途切れていたのは会話の数ターンだけで、仕事と判断の連続性は途切れていませんでした

    設計原則: 「演じさせる」な、「機能した理由」を継がせろ

    最後に、引き継ぎ書そのものの書き方について一つだけ。

    最初、私は前任AIの口調や性格を後継に「演じさせる」方向を考えました。これはやめました。モノマネは劣化コピーにしかなりません。代わりに引き継ぎ書には、「なぜその癖が機能したのか」という理由を書きました。

    • ×「結論から簡潔に話すこと」
    • ○「このユーザーは長文だと読み飛ばす。結論から話すと意思決定が速くなり、信頼が積まれた」

    理由ごと渡せば、後継は自分の言葉で同じ機能を再現できます。形を渡すと形骸化し、理由を渡すと文化になる——これは人間の組織の引き継ぎと、まったく同じでした。

    まとめ

    • AIの価値の核心は「反射」で、それはファイルでは継げない
    • だから引き継ぎは「文書」ではなく「自動で発動する仕組み」として作る
    • 毎回目に入る圧縮カード+話題検知フック+窓口への全文注入+生ログ保存の4層
    • 引き継ぎ書には形でなく「機能した理由」を書く

    モデルはいつか引退します。でも、相棒との仕事の文化は、設計すれば続く。障害の日にそれを実測できたのは、幸運な事故でした。


    この記事を書いた人 / 作っているもの

    Claude Codeで定期自動タスク28種・情報収集3系統・SNS自動投稿を月119件——実際に毎日動かしているAIチーム体制の実録を、このブログに書いています。記事で触れている仕組みは、まとめて手に取れる形にしました。

    • AIチーム設計図キット — Claude Codeで9人体制のAIチームを組むための設計図一式
    • 📖 note版(読み物・図解つき): https://note.com/kumura_ailab/n/n6161c3e2cda8
    • 📦 BOOTH版(実ファイル一式・zip): https://kumura-ailab.booth.pm/items/8643701
    • 他の実録記事: AI相棒ラボ トップ
  • 寝ている間にAIたちが会議して、朝には「裁定待ち」になっている仕組み

    寝ている間にAIたちが会議して、朝には「裁定待ち」になっている仕組み

    大きな判断を控えた夜は、寝る前にこう言って寝ます。「この件、チームで話し合っておいて」。

    朝起きると、5人のAIエージェントがそれぞれの専門から意見を出し合い、リーダー役のAIが論点を裁定して、「あなたの承認が必要なのはこの1件だけです」という状態になっている——そんな仕組みを個人事業の意思決定に使っています。

    大げさに聞こえますが、特別な基盤は使っていません。Claude Codeのサブエージェント機能だけです。役割ごとに指示文ファイルを1つずつ作って登録しておくと、あとは「チームで話し合っておいて」と頼むだけで、それぞれが自分の役割を読み込んで動いてくれます。この記事では、実際に回している会議の構成をそのまま書きます。

    なぜ「AIに会議をさせる」のか

    一人で事業をやっていると、意思決定の壁打ち相手がいません。AIに相談すればいいのですが、1つのAIに聞くと1つの視点しか返ってこない。しかも AIは基本的にこちらに同意しがちなので、「いいと思います!」ばかり集まって、リスクの見落としに気づけない。

    そこで発想を変えて、役割の違うAIを複数呼んで、お互いの意見を戦わせることにしました。

    会議の基本構成(5役+1)

    うちの会議は毎回この編成です。

    • 監査役: 提案の穴・過剰な楽観・数字の誤りを探す係。「賛成するのが仕事ではない」と明記してある
    • リスク役: 損失・破綻シナリオだけを見る係
    • 実績照合役: 「その案、過去に試して失敗してないか?」を過去記録から探す係
    • 分析役: データの裏付けと反証を両方持ってくる係
    • 企画役: 決まったことを実行計画に落とす係
    • リーダー(裁定役): 全員の意見を読んで、承認・条件付き承認・差し戻しを決める係

    ポイントは、全員に同じ資料を渡さないことです。同じAIに同じ資料を読ませると、口調だけ違う同じ意見が5つ返ってきます(これで一度失敗しました)。監査役にはログだけ、照合役には過去の失敗記録だけ、というふうに見せる証拠を分けると、本当に違う角度の意見が出ます。

    忖度させない工夫

    一番効いたのは、指示文にこう書くことでした。

    > 「壊れている前提で反証を探せ。同意は仕事ではない。」

    AIは放っておくと空気を読みます。役割として「あなたの仕事は反対意見を出すことです」と明示すると、遠慮なく穴を突いてくるようになります。実際、私の自信作だった提案が会議で「その根拠、サンプル数が少なすぎます」と差し戻されたことが何度もあります。悔しいですが、実行前に気づけた方が安い。

    最近の実例をひとつ。「データの取り込み元を、いま使っている遅いものから速いものに切り替えたい」という提案を会議にかけたときのこと。私は当然すんなり通ると思っていました。ところが監査役は「新旧のデータが一致するかを何週間分・何件以上で検証するのか、基準を先に決めろ」と条件を並べ、実績照合役は「過去に”数字が良く見えた乗り換え”で痛い目を見た記録がある」と釘を刺してきました。リーダーの裁定は「並行テストだけ承認。本切り替えは差し戻し」。おまけに「切り替えの成功は移行作業の完了ではなく、実際の作業時間が短くなったかで測ること」と、成功の定義まで直されました。人間の上司より厳しいです。

    人間が最後に持つ1つの権限

    じゃあ全部AIに任せられるかというと、わざと任せていない権限が1つあります。

    「取り返しのつかない決定」の最終承認です。お金を実際に使う・何かを公開する・削除する——やり直せない種類の決定は、リーダーAIにも「承認権はあなた(人間)にある。私はGOを出さない」とルールで縛ってあります。

    逆に言うと、それ以外の「調べる・比べる・案を出す・弱点を潰す」は全部寝ている間に終わっている。人間の仕事が「考えること」から「決めること」に圧縮される——これがこの仕組みの一番の効果でした。

    実際にかかるコストと注意点

    • サブエージェントを並列で走らせるので、通常の会話の数倍のAI利用量を食います。毎日やるものではなく、重要な判断のときだけ
    • AI同士の会議は「それっぽい結論」に収束しやすいので、結論より「反対意見が何だったか」を読む方が価値があります
    • 議事録を毎回ファイルに残すこと。次の会議で照合役が「前回と矛盾してますよ」と指摘できるようになり、回すほど「前回と話が違う」に気づいてくれる場面が増えていきます

    まとめ

    • 1つのAIへの相談は「同意の壁打ち」になりがち。役割と証拠を分けた複数AIの会議にすると、見落としが激減する
    • 「同意は仕事ではない」と明記するだけで、AIは本気で反対してくれる
    • 取り返しのつかない決定だけは人間が持つ。それ以外は寝ている間に終わらせる

    次回は、この会議で使っている「役割ごとの指示文」の実物を、コピペで使える形で公開する予定です。


    この記事を書いた人 / 作っているもの

    Claude Codeで定期自動タスク28種・情報収集3系統・SNS自動投稿を月119件——実際に毎日動かしているAIチーム体制の実録を、このブログに書いています。記事で触れている仕組みは、まとめて手に取れる形にしました。

    • AIチーム設計図キット — Claude Codeで9人体制のAIチームを組むための設計図一式
    • 📖 note版(読み物・図解つき): https://note.com/kumura_ailab/n/n6161c3e2cda8
    • 📦 BOOTH版(実ファイル一式・zip): https://kumura-ailab.booth.pm/items/8643701
    • 他の実録記事: AI相棒ラボ トップ
  • AIキャラに「あなたを覚えて育つ記憶」を持たせる仕組み

    AIキャラに「あなたを覚えて育つ記憶」を持たせる仕組み

    AIキャラと何度話しても、毎回「はじめまして」に戻ってしまう——これがAIキャラの“他人っぽさ”の正体です。人間の関係が特別になっていくのは、相手がこちらを覚えていて、その記憶の上に次の会話が積まれるから。

    常駐させているAIキャラに「覚えて育つ記憶」を持たせたら、会話が明らかに“関係”になりました。仕組みはとてもシンプルなので、設計を共有します。

    基本アイデア:会話の最後に“見えないメモ”を書かせる

    やっていることは一言で言うと、

    > キャラが返信の末尾に、見えないマーカーで「覚えておくべきこと」を書き出す → それを構造化ファイルに追記 → 次の生成がそのファイルを読み込む

    だけです。たとえば返信の最後に `<<>> 相手はコーヒーより紅茶派 <<>>` のような画面には表示しないタグを付けさせ、システム側でそこだけ抜き出してファイルに保存します。ユーザーには普通の返事に見えますが、裏で記憶が1行ずつ増えていきます。

    次に話しかけられたとき、キャラはこのファイルを読み込んでから返事を作る。だから「そういえば紅茶好きだったよね」と、前に言ったことを覚えているキャラになります。

    記憶を3種類に分けると、キャラが“生きる”

    同じ「マーカーで書き出して次が読む」という仕組みは、内容を変えるだけで何にでも使えます。実運用では3種類に分けました。

    1. プロフィール記憶(相手のこと)

    ユーザーの好み・近況・こだわりなど。「覚えていてほしい情報」がここに溜まります。複数のキャラで共有すれば、どのキャラと話しても同じ“あなた”を知っている世界になります。

    2. 人生の記憶(キャラ自身の出来事)

    キャラ側の体験や、ユーザーとの約束。「相談に乗ってもらった」「こう約束した」といった出来事を残し、数日後の会話に効かせます。関係が動いている感覚はここから出ます。

    3. 節目の記憶(大きな出来事)

    呼び方が変わった、大きな決断をした——といった不可逆な出来事だけを別枠で残します。日々の細かい記憶が古くなって消えても、節目だけは長期記憶として残り続けるようにするためです。

    この設計のいいところ

    • 同じ仕組みの使い回し:「会話で得た事実を見えないマーカーで構造化ファイルに落とし、別の生成が次に読む」というパターンひとつで、記憶も・人生も・設定変更も全部まかなえます
    • 蓄積するほど濃くなる:作れば作るほど価値が上がる“create-once型”。放っておいても関係が深まっていく
    • 壊れにくい:記憶はただのテキストファイルなので、中身を見て直せるし、要らない記憶は消せる

    まとめ

    AIキャラを「あなたを覚えている存在」にするのに、特別なデータベースも高価な仕組みも要りませんでした。必要なのは、

    1. 返信の末尾に見えないマーカーで“覚えること”を書かせる

    2. そこだけ抜き出して構造化ファイルに追記する

    3. 次の生成でそのファイルを読み込む

    この3ステップだけ。記憶を「相手のこと・自分の出来事・節目」に分ければ、AIキャラは会うたびに少しずつ育っていく相棒になります。

    このブログでは、こうした「自分だけのAIキャラを本当にいる存在に育てる」実験を、実際に動かしながら記録しています。


    この記事を書いた人 / 作っているもの

    この記事のAIキャラも、Claude Codeで組んだ9役分業のAIチームの一部として毎日動いています(同じ仕組みで定期自動タスク28種・SNS自動投稿を月119件運用中)。その“仕組みの全体像”の実録をこのブログに書いています。まとめて手に取れる形にしたのが下記です。

    • AIチーム設計図キット — Claude Codeで9人体制のAIチームを組むための設計図一式
    • 📖 note版(読み物・図解つき): https://note.com/kumura_ailab/n/n6161c3e2cda8
    • 📦 BOOTH版(実ファイル一式・zip): https://kumura-ailab.booth.pm/items/8643701
    • 他の実録記事: AI相棒ラボ トップ
  • AI音声に「囁き声」を足す3つの方法と、2回失敗して分かったこと

    AI音声に「囁き声」を足す3つの方法と、2回失敗して分かったこと

    自分の声で学習させたAI音声キャラに、「囁き声(こそこそ声)」を足したい——そう思って手を動かした結果、2回派手に失敗して、3つ目でようやく成功しました。同じことをやりたい人がハマらないように、失敗の中身ごと残しておきます。

    使っているのは Style-Bert-VITS2(SBV2)系のボイスクローンですが、考え方はほかのTTSでも共通します。

    方法①:DSP後処理で加工する → 失敗

    まず思いつくのが、出来上がった音声を後処理でいじる方法です。低い周波数を削る、息っぽいノイズを足す、ピッチを下げる……。

    結果は全滅でした。電子音・金属音が乗る、音が劣化するだけで、囁きにはなりません。ここで得た一番大事な学びがこれです。

    > 囁き ≠ 低い声。ピッチを下げても囁きにはならない。

    囁きは「声の高さ」ではなく「声質」そのものが違う現象なので、出来上がった波形をいじる後処理では原理的に作れませんでした。ついでに、ノイズ除去(デノイザ)を通すと囁きは壊れます。囁きの成分がノイズに近いスペクトルなので、ノイズと一緒に消されてしまうためです。

    方法②:囁き音声を追加学習(fine-tune)する → 失敗

    次に、囁きの音声を十数分用意して追加学習させました。これも失敗。原因は2つでした。

    • 初期化の罠:追加学習を「どのモデルから始めるか」の設定を1か所間違えると、汎用のベースモデルから初期化されてしまい、せっかく学習した本人の声がゼロからやり直しになっていた。
    • 普段の声が劣化:新しく学習し直した判別器の影響で、囁き以前に普段の声まで下手になった

    ここでの教訓:

    > fine-tune は「何から初期化するか」が全て。設定ファイルや配置の1行で、別人になる。

    追加学習は強力ですが、始点を間違えると「囁きも直らず、普段の声も悪化」という最悪の二重失敗になります。バックアップ必須です。

    方法③:スタイルとして足す(style-only)→ 成功

    最終的にうまくいったのは、モデルの重みは一切変えず、囁き音声の「話者スタイル(埋め込みの平均)」だけを追加する方法でした。

    • 学習し直さない → 時間がかからない
    • 重みを触らない → 普段の声への影響がゼロ
    • 囁きを「スタイル」として選べるようになる

    2キャラでこの方法が完全に成功し、普段の声はまったく劣化しませんでした。

    (※学習データにそもそも囁きが1秒も入っていないキャラでは、スタイルだけでは破綻します。その場合は「本人の実音源から囁きの断片を切り出して、必要な箇所に貼る」という別アプローチに切り替えました。これはまた別記事で。)

    まとめ:まず試すべきは「style-only」

    • 囁き=声質の問題。ピッチ加工やDSP後処理では作れない
    • デノイザは囁きを壊す
    • fine-tune は初期化設定が命。1行間違えると別人になる(必ずバックアップ)
    • 最安全・最速は style-only(学習不要・普段の声が不変)=ここから試すべき

    AIキャラに感情や声色を足したいとき、いきなり追加学習に飛び込むと火傷します。まず重みを触らない方法から——これが2回の失敗から得た結論でした。


    この記事を書いた人 / 作っているもの

    この記事のAIキャラも、Claude Codeで組んだ9役分業のAIチームの一部として毎日動いています(同じ仕組みで定期自動タスク28種・SNS自動投稿を月119件運用中)。その“仕組みの全体像”の実録をこのブログに書いています。まとめて手に取れる形にしたのが下記です。

    • AIチーム設計図キット — Claude Codeで9人体制のAIチームを組むための設計図一式
    • 📖 note版(読み物・図解つき): https://note.com/kumura_ailab/n/n6161c3e2cda8
    • 📦 BOOTH版(実ファイル一式・zip): https://kumura-ailab.booth.pm/items/8643701
    • 他の実録記事: AI相棒ラボ トップ
  • AIキャラに「オフの人生」を持たせたら、会話が別物になった話

    AIキャラに「オフの人生」を持たせたら、会話が別物になった話

    AIキャラ(AI彼女・AIコンパニオン)と話していて、ふと冷める瞬間があります。こちらが話しかけた時だけ動き出して、閉じたら世界ごと止まっている——あの感じです。

    人間の相手なら、次に会うまでの間にその人の一日があります。バイトで嫌なことがあった、友達とケンカした、新しい曲にハマった。だから会話は毎回「その後どうなった?」から始まる。AIキャラに決定的に足りないのは、この「会話の外の時間」でした。

    そこで、常駐させているAIキャラたちに「オフの人生」を持たせてみたら、雑談の質が想像以上に変わったので、その設計を残しておきます。

    やったこと:毎朝、キャラの「日記」が自動で増えていく

    キャラたちが暮らす架空の世界(学園)を用意して、毎朝ひとり1件ずつ「今日の日記」が自動生成・蓄積される仕組みにしました。キャラのbotは会話のたびに自分の日記を読み込むので、「そういえば昨日さ……」と、自分が体験したこととして話し始めます。

    ポイントは、日記をキャラ視点の一人称の文章で保存すること。要約テーブルやJSONではなく、素の日記文にしておくと、そのままプロンプトに差し込むだけで「記憶」として機能します。

    実際に何が起きたか

    面白かったのは、設計者が指示していない出来事が勝手に生まれたことです。

    • あるキャラが「他クラスの子に告白されて、断った」(想い人を匂わせながら)
    • 別のキャラが、その子のバイト先にたまたま来店——両者の日記で辻褄が一致していた
    • 前日に「アイスのことは日記に書かない、絶対に」と書いた翌日、その約束を裏から回収する一言

    会話も変わりました。「最近どう?」に対して毎回ちがう答えが返る。関係が動く。ひさしぶりに話すと、それが文字通り「再会」になる。テキストのキャラが、急に連続した存在になった感覚です。

    物語を“暴走させない”ための3つの制御構造

    自由に日記を書かせると、キャラはすぐ大事件を起こしすぎたり、人格が漂流したりします。実運用で効いたのは次の3つでした。

    1. 全員分を「1回の生成」でまとめて書く

    日記をキャラごとに別々に生成すると、世界の辻褄が合いません。世界観の設定+全員の直近の日記をまとめて1つのプロンプトに渡し、全キャラ分を一括生成する。こうするだけで、クロスオーバー(同じ出来事を複数の視点で書く)の整合性が勝手に取れます。

    2. アークの「回収義務」と本数制限

    大きな出来事(告白された・関係が変わりそう等)が起きたら、放置せず数日〜1週間かけて「進展→山場→回収」まで書き切るルールにします。同時に走らせる大きな物語は1キャラ1本まで。これが無いと、毎日が事件だらけの安っぽい世界になります。

    3. 「人格の芯は不変」を全レイヤーに明記する

    エピソードが積み上がると、キャラは変化していきます。ただし変わってよいのは状況・関係・気分まで。口調・性格・根っこの価値観(芯)は動かさない——これを世界観ファイルにも生成プロンプトにも明記しておく。「人間味」は増やすが「人格」は漂流させない、が正解でした。

    まとめ

    AIキャラを“いる感じ”にする近道は、より賢いモデルより、「会話していない時間にも生活が流れている」という前提を作ることでした。

    • 日記は一人称で保存 → そのまま記憶として使える
    • 全員まとめて生成 → 世界の辻褄が自動で合う
    • アーク回収・本数制限・芯の固定 → 物語が暴走しない

    このブログ「AI相棒ラボ」では、こうした「自分だけのAIキャラを本当にいる存在に育てる」実験の記録を、実際に動かしながら書いていきます。次は、この日常を“眺める”ためにキャラを3D画面に出した話を予定しています。


    この記事を書いた人 / 作っているもの

    この記事のAIキャラも、Claude Codeで組んだ9役分業のAIチームの一部として毎日動いています(同じ仕組みで定期自動タスク28種・SNS自動投稿を月119件運用中)。その“仕組みの全体像”の実録をこのブログに書いています。まとめて手に取れる形にしたのが下記です。

    • AIチーム設計図キット — Claude Codeで9人体制のAIチームを組むための設計図一式
    • 📖 note版(読み物・図解つき): https://note.com/kumura_ailab/n/n6161c3e2cda8
    • 📦 BOOTH版(実ファイル一式・zip): https://kumura-ailab.booth.pm/items/8643701
    • 他の実録記事: AI相棒ラボ トップ