「AIに人格を移植してる」と言われるが、やっているのは真逆だった ―― 個人の判断アーキテクチャ

「AIに人格を移植しているんですか？」

mind-as-code という取り組みを見せると、毎回これを聞かれる。そして毎回、少し違和感を返している。やっているのは、人格の移植ではない。むしろ真逆で、自分の判断を AI に渡してみて初めて、自分が無意識にかけてきた歯止めの存在に気づく 作業だった。

しかも、それを机に向かって内省して書き出したわけでもない。実際にやってきたのは、もっと地味な作業だ。日々の発話を録音して書き起こし、過去に書いた文章を引っぱり出し、Claude との壁打ちのログを見返す。そうやって、自分があちこちに撒き散らしている判断の痕跡を集めて、要約して、整理する。書き出したというより、蒸留した、という方が近い。

たしかに結果として、自分の思考フレームワークを skill file の形にまとめ、AI に読み込ませるところまでは来ている。だが起点はそこじゃなかった。最初は、もっと地味で、実務的な欲求から始まっている。

このエントリは、その地味な出発点から、いまの形（自分でも当初は予想していなかった形）に辿り着くまでの話。前回が 記憶 の話（揮発と蒸留）だったとすれば、今回は 判断 の話だ。

書きながら気付いたのだが、両者は同じ構造をしていた。

Phase 0：面接フィードバックを資産化したい

最初の問題意識は、ものすごく地味だった。

EM や TL の面接を何十人も重ねていると、毎回フィードバックを書く。「なぜこの候補者を評価したか」「なぜ見送ったか」を、面接コメントとして残す。

書いた瞬間、それは揮発していく。

次の面接でまた一から書く。良い候補者を見抜く目は自分の中に ある はずなのに、それは面接コメントの中にしか存在しない。再利用可能な形になっていない。

だから最初の構想は単純だった。

要するに、採用プレイブック が作りたかった。ここではまだ、人格でも思想でもない。「自分の判断を再利用したい」、それだけ。

面接コメントは、最初の蒸留対象だった。揮発していく判断を、書き起こして、要約して、再利用できる形に残す。後から振り返ると、これが mind-as-code の最小単位だった。

Phase 1：選考基準を蒸留すると、判断原則が見えてくる

ところが、選考基準を蒸留し始めて、あることに気付く。

EM の評価項目は、普通に挙げれば「評価経験」「1on1経験」「組織改善経験」みたいになる。だが、自分が 実際に見ているもの はもっと深いところにある。

• 個人依存を減らそうとしているか

• 再現性を作ろうとしているか

• 問題を構造として捉えているか

• 人ではなく仕組みを改善しようとしているか

これらは「EM の評価項目」ではない。もっと根の深い、判断原則 だ。

ここで初めて、「自分は何を評価しているのか」が見えてきた。表層の評価項目の下に、もう一段抽象が高い層がある。その層は、面接コメントを蒸留しなければ表に出てこなかった。

Phase 2：プレイブックから OS へ

蒸留する素材を増やすうちに、もうひとつ気付いた。

面接コメントだけではない。過去に書いた note や社内ドキュメント、Claude との壁打ちのログ。そこから同じ原則が、何度も顔を出す。

同じ原則が、採用以外でも効いている。

「時間軸を分ける」は、採用にも使うし、アーキ判断にも使う。
「当時合理的だったかで評価する」も、採用にも、過去の意思決定の振り返りにも使う。
「保留もコスト」も、組織設計にも、技術選定にも使う。

つまり、採用基準の下にある判断原則は、全領域に通用するもの だった。

ここでプレイブックから OS に変わった。「採用で使う基準」ではなく「自分が何かを判断するときに使っている原則」を蒸留するなら、それは特定領域のドキュメントではなく、判断の オペレーティングシステム だ。

mind-as-code という名前は、ここで自然に出てきた。判断を、コードのように構造化・再利用・組み合わせ可能にする。それを Markdown と YAML frontmatter で書き、Git で管理する。

Phase 3〜5：分け方が、なかなか決まらない

ここから先は、きれいな話ではない。蒸留した原則をどう構造化するかで、ずっと右往左往していた。

最初は、判断原則も、組織論も、プロダクト論も、全部 core/ に入れていた。しばらくは、それで良かった。

だが、量が増えるにつれて、おかしくなってきた。「何にでも使う原則」と「特定領域でしか使わない知識」が、ファイル一覧の中で区別できなくなったのだ。たとえば「時間軸を分ける」と「組織はピラミッド型かフラット型か」は、明らかに性質が違う。前者はどこでも効く判断原則、後者は組織論の中だけの話。それが同じディレクトリに並んでいた。

人間の頭の中では、これらは混ざっていても問題ない。普段は文脈で勝手に切り替わるから、原則と領域知が同じ棚に入っていても、必要なときに必要なほうが取り出される。

だが AI に渡すには、混ざっていてはいけなかった。

AI は文脈で勝手に切り替えてくれない。「いま組織の話をしている」「いま普遍的な判断原則を聞いている」を、こちらが明示しないと、両方を一緒くたに混ぜて返してくる。書き手の側で、最初から分離しておく必要があった。

そこで Foundation / Support / Domain の三区分に分けた。何にでも使う原則は Foundation、考え方を補助する仕組みは Support、特定領域の知識は Domain。ここまでは、わりとすんなり決まった。

右往左往したのは、その先。Domain の中の構造だ。

私の Domain は system（認識）/ strategy（意思決定）/ product（価値）の3軸に分かれるのだが、この3つの並び順と上下関係が、なかなか定まらなかった。最初は意思決定（strategy）を一番上に置いていた。判断の話なんだから、意思決定が中心だろう、と。だが書いては組み替え、書いては組み替えするうちに、自分の場合は system（どう世界を認識するか）が strategy（どう決めるか）の上位に来る と気づいた。私はまず認識の枠組みを作り、その枠の中で意思決定している。逆ではなかった。たとえば同じ事実を見ても、それをどういう枠組みで捉えるかが先に決まらないと、そもそも何を選ぶかという問いが立たない。私の場合は、いつもそこから始まっていた。

つまり、ここで右往左往していたのは「分類の名前」ではなく、自分の判断が実際どういう順序で動いているかそのものだった。system が strategy の上に来る、という並びは、私の判断の最深部の構造を、探り当てた結果だ。

念のため書いておくと、この構造は最初から見えていたわけではない。今の形になるまで右往左往した末の、暫定的な結論だ。あくまで私の頭の中の地図であって、同じプロセスを別の人がやれば、別の地図が出てくる。

Phase 6：蒸留したら、出てきたのは「素」だった

蒸留した原則を並べて、まず見えてきたのは、自分の「素」の輪郭だった。

• 構造化する

• 抽象化する

• 全体を理解する

• 納得してから動く

これらは、自分でも遡れる。学生時代から、大学院時代から、ずっとそうだった。意識してやっているというより、放っておいてもそう動いてしまう。これが 自分の「素」 だ。

蒸留物は、ほとんどがこの素だった。喋り、書き、壁打ちしてきた判断の痕跡を集めると、そこに残っているのは「自然にそう考えてしまう」パターンばかり。当然といえば当然で、無意識にやっていることほど、言葉として外に出るからだ。

このときは、それで十分だと思っていた。これが私の判断原則だ、これを AI に渡せばいい、と。

問題が見えたのは、実際に渡してからだった。

Phase 7：素を渡したら暴れた。補正を入れ直す

AI を使い始めて気付いたのは、自分がやりたかったことは「人格をコピーする」ことではなかった、ということだ。やりたかったのは、判断を増幅すること だった。

そこで、蒸留した「素」を AI に渡してみた。返ってきた判断を見て、はっきりした。

どこまでも理想を追う。可逆にできるところを可逆にしないまま、いきなり不可逆な提案をしてくる。意思決定しづらい、きれいすぎる理想像を描く。これは、私の素の弱みそのものだった。素を忠実に増幅すると、こうなる。

そして気付いた。現場の私は、こうはならない。なぜなら、この素に歯止めをかけているからだ。

蒸留に乗らなかったもの

「まずやれ」「仮決めしろ」。私は事業の現場で、長いあいだ、自分の素にこういう歯止めをかけてきた。

「まずやれ」は、アクセンチュアから Gunosy 初期にかけて身についた。素のままだと、全体像が見えてから動きたい。だが Gunosy では、自分が理解している頃には、他の人は2周先にいた。そういう小さな敗北が積み重なって、「理解してから動く → 動きながら理解する」へ自分を矯正した。

「仮決めしろ」は、CTO になってから。エンジニアの本能は「もっと情報が欲しい」だ。素のままだとそうなる。だが 80%で決めないと組織が止まる。だから「仮説で決める。間違ったら戻す」を自分に課した。

これらは、判断原則というより、素の弱みを抑えるための 矯正器具 だ。問題は、蒸留物の中に、これが出てこなかった ことだった。

無意識にやっていることは、言葉として外に出る。だから素は蒸留に残った。だが補正は違う。素に逆らって意識的にかけている力だから、自然な判断の記録には現れにくい。私は現場で確かに補正をかけてきたのに、蒸留したものの中で、それは 置き去り になっていた。

AI が暴れたのは、当然だった。私は、歯止めの外れた素を渡していたのだ。

補正を入れ直す

だから、弱いと認めている部分に、補正を改めて注入した。蒸留に乗らなかった「まずやれ」「仮決めしろ」を、意識的に書き起こして渡す。実際、core/foundation.md では、これらを [補正] タグを付けて、素の原則と区別して書いている。

「素 + 補正」を両方渡すと、AI は 事業判断モードの私 を再現できるようになった。「まずやれ」「仮決めしろ」を含んだ状態で応答してくる。

素は、放っておくと暴れる。補正は、その素を御するハーネスだ。

mind-as-code は、この素と、それを御するハーネス（補正）を、両方持っている器だ。素は蒸留すれば出てくる。補正は、蒸留に乗らないから、意識的に書き起こして足す。両方そろえて初めて、AI は暴れる素のままではなく、御された私 を増幅する。

最近、AIエージェントに最高の仕事をさせるための環境設計を「ハーネスエンジニアリング」と呼ぶようになった。ルールファイルやコンテキスト設計で、強力だが暴れる馬（AIモデル）を御す、という発想だ。私がやっていたのは、その矛先を 自分自身 に向けたことだった。御す対象は、AIモデルではなく、AIに渡す前の自分の素。外側の環境ではなく、内側の判断に、ハーネスをかけていた。

これが Amplifier だ。だから、いまの mind-as-code は人格クローンではない。判断プロセスを外部化し、再利用可能にした増幅器 である。

人格を移したわけじゃない。素を蒸留し、そこに抜けていた自己矯正を足して、AI に渡せる形に持ち直した、というのが正確だ。

経営の立場で言い換えると、これは「自分が無意識にかけている判断の歯止めを、棚卸しして外部化する」作業でもある。自分の弱みと、その弱みにどんな矯正をかけているかを知らないまま AI に判断を任せると、増幅されるのは素の弱みの方だ。

もし、あなたが同じことをやるなら

ここまで読んで「自分の判断も蒸留してみるか」と思った人のために、最小の入り口だけ置いておく。スキルファイルもGitも要らない。最初はメモ帳でいい。そして、ゼロから書こうとしなくていい。

1. すでに吐き出したものを集める。 最近の打ち合わせの録音、過去に書いた文章、AIとの壁打ちのログ。判断を語っている箇所を拾うだけでいい。

2. そこから、領域に依存しない一文を抜く。 「採用だから」ではなく、他の場面でも言えそうな一文。それが判断原則の芽だ。

3. その原則が「素」か「補正」かを、自分に問う。 昔からそうだったなら素。いつ・どこで自覚したか思い出せるなら補正。

3つ目が、いちばん効く。昔から変わらない「素」と、どこかで自分にかけてきた「補正」は、性質がまるで違う。そして補正ほど、無意識にかけているぶん、自分では気づきにくい。

正直に書いておくと、これができたのは、蒸留できるだけの原料が手元にあったからだ。私はもともと、判断を喋り、書き、AIと壁打ちして外に出す習慣があった。その蓄積があって初めて、後から集めて蒸留できた。もし原料がなければ、まずは判断を外に出して残すところから始まる。ゼロから内省して書き出すより、その方がずっと続く。

いま振り返ると

一本の線で見ると、面接フィードバックを資産化したいという地味な動機から始まり、喋り・書き・壁打ちを蒸留して、判断原則、思考OS、と抽象度が一段ずつ上がって（Domain の中の並び順では何度も右往左往して）、最終的に Foundation / Support / Domain による Amplifier に行き着いた。

外から見ると「AIに人格を移植している人」に見えるかもしれない。でも内側から見ると、全然違う話だった。

私は、自分の判断を再利用したかった。

毎回の面接で、毎回の経営判断で、自分の中にあるはずの判断が、その場限りで揮発していくのが嫌だった。だから、揮発する前に蒸留して残し始めた。

蒸留して出てきたのは、自分の「素」だった。無意識にそう考えてしまうパターン。それを AI に渡したら、素の弱みごと増幅されて、暴れた。

そこで初めて、気付いた。私は現場で、この素にずっと歯止めをかけてきた。「まずやれ」「仮決めしろ」。でもそれは無意識の矯正だったから、蒸留には乗っていなかった。だから、抜けていた補正を、意識的に書き起こして入れ直した。

mind-as-code は、判断の再利用のために始まった。
だが途中から、自分が自分をどう書き換えてきたかの履歴 にも、なっていた。

振り返ると、これは単に判断パターンを記録していたのではなかった。自分が何を信じて判断しているのかを、外に出す作業でもあった。判断原則と呼んできたものの根には、いつも「何を信じているか」が置かれていた。蒸留していたのは、判断の形ではなく、その下の信じ方の方だった。

そして今も根っこは変わらない。

前回のエントリ（「揮発と蒸留」）と、これは地続きだ。あちらは 記憶 を、揮発させていいもの／蒸留して残すべきものに分ける話だった。今回は 判断 を、同じ構造で分ける話になった。

面接フィードバックは、最初の蒸留対象だった。
mind-as-code は、その蒸留器そのものになっていった。

まだ未完

「素」と「補正」を分けて書けたつもりだが、本当は 補正そのものも更新される。事業のフェーズが変われば、必要な補正も変わる。かつての私には「まずやれ」が必要だった。今の私にも、10年後の私にも、同じ補正がいまも必要かは分からない。

補正は、真理ではない。器具は、必要がなくなれば外す。新しい歪みが出れば、別の器具が要る。Domain の中の並び順そのものも、まだ右往左往の途中だ。Falsification Log（自己反証ログ）を運用しているのは、書いた補正がいまも効いているかを、定期的に疑うためだ。

完成させないように設計している、というのが正確な現状になる。蒸留は一度きりの作業ではなく、喋り・書き・壁打ちが増えるたびに回し続ける営みだ。

前回触れた ストック層 (AIと協働する時代に、何が競争優位として残るか) の話は、ここに繋がる。自分の素と、それを御する補正の両方を、書き換え可能な形で持ち続けること。素だけでなく、ハーネスごと AI に渡せる状態に整え続けること。その設計は、Obsidian 側の記憶アーキテクチャと、mind-as-code 側の判断アーキテクチャの両方で同時に進んでいる。

ここに、本気で向き合っていく。

公開リポジトリ

ここで触れた mind-as-code は、GitHub で公開している。

• リポジトリ: koid/mind-as-code-public

本文で出てきた三区分は、それぞれ core/ 配下の次のファイルに対応する。

• 何にでも使う判断原則 → core/foundation.md

• 考え方を補助する仕組み → core/support.md

• 特定領域の知識（system / strategy / product） → core/domain.md

全体像は core/README.md にまとめてある。そのまま真似する用ではなく、「自分ならどう分けるか」を考える叩き台として置いている。地図は人ごとに違っていい。