タグ: AI自動化

  • 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相棒ラボ トップ