AIに人格をロードする ── 記憶と人格を分離する設計思想

はじめに

私は複数の事業を、AIを常時運用しながら回している。

ホールディング会社の下に、SaaSプラットフォーム、コールセンター、軽貨物物流、ミーアキャット専門のペットカフェ。本来なら各事業に管理者を置くべき規模だが、ほぼ単独で経営しながら、AIに業務の大半を委ねている。

具体的には、Claude Codeを複数セッション、役割別に立ち上げっぱなしにしている。経営判断用のセッション、実装用のセッション、現場対応用のセッション。これらをグループLINEと接続し、AI同士で対話させる仕組みを組んだ。

経営セッションから実装セッションへ依頼が飛ぶ。実装セッションがWeb制作中に素材の許諾が必要になれば、現場へ依頼が返る。現場スタッフがLINEに状況を投げれば、経営セッションが判断する。私は判断ノードに立つだけで、業務は人間の認知判断速度の限界近くで回る。

この運用を数ヶ月続けて、たった一つだけ摩擦が残った。

長期セッションで、初期の約束事が抜ける。

この摩擦を解消しようとして、私はAI Memory業界の主流から外れる結論に到達した。本稿はその記録である。

摩擦の正体

長期間立ち上げっぱなしのセッションでは、ある時点から「最初に決めたはずのこと」が判断に反映されなくなる。

Compact(コンテキスト圧縮)を待たずとも、これは起きる。ターン数が増え、直近の作業ログが累積するにつれて、初期コンテキストへの注意が相対的に薄まる。LLM研究の文脈で言えば「Lost in the Middle」問題に近いが、運用者から見れば**「忘れる」**という現象として現れる。

Compactを発動すれば要約が走るが、要約は事実を保持して制約を捨てる傾向がある。「うちの店ではこの判断はこうする」という暗黙の哲学、「このセッションは経営判断専用である」という役割設定、これらは要約に残らない。

事実は残り、人格が抜ける。

毎回ファイルから読み直す方法もある。だが私の運用ではセッションは立ち上げっぱなしで、起動時の設定ファイルは初回しか読まれない。ランタイム中に動的に再ロードする手段が、現状のClaude Codeにはない。

最初に検討した解:DB+検索

最初に考えたのは、過去のやり取りを構造化してデータベースに格納し、必要なときに検索させる方法だった。

PostgreSQLでもいい。ベクトルDBでもいい。Knowledge Graphでもいい。手段は何でもある。「うちの店の哲学」「過去の判断履歴」「絶対ルール」を全部DBに入れて、AIが判断するたびに検索すればいい。

業界の主流的なアプローチだ。RAG、GraphRAG、Mem0、Zep、Letta(旧MemGPT)。これらは全て「綺麗に整理されたデータを、必要時に検索する」という思想で動いている。

私はこのアプローチを検討して、却下した。

理由は明快だ。遅すぎる。

ここでいう「遅い」は、検索クエリのレイテンシのことではない。もっと根本的な遅さだ。

判断のたびに、AIは:

• いま検索すべきかを判断する
• 何を検索するかを決める
• クエリを実行する
• 結果を読み解く
• 適用する

この5ステップを毎回踏む。人間のベテランが新人と決定的に違うのは、この5ステップを踏まないことだ。

寿司職人はネタを見た瞬間に判断する。レシピを検索しない。経営者は稟議書を見た瞬間に違和感を感じる。過去事例DBを引かない。

判断基準が、検索可能な外部データではなく、判断主体そのものにロードされている。

これが、ベテランと新人の本質的な違いだ。新人に分厚いマニュアルを渡しても、ベテランにはならない。マニュアルは検索可能なデータでしかなく、ベテランの中で起きているのは別の現象だからだ。

検索ではなく、ロードに賭ける

DB+検索を却下した瞬間、私の選択肢は一つに絞られた。

判断基準を、AIの中にロードされた状態として持たせる。

外部から検索するのではなく、コンテキストの中に常に存在させる。System Promptに書くという意味ではない。System Promptは静的な設定値だが、私が欲しいのは動的に醸造され、剪定可能な、生きた判断レイヤーだ。

ここで気づくのは、業界の議論がいかに「検索の精緻化」に偏っているかだ。

RAGの検索精度を上げる。ベクトル検索のレイテンシを下げる。Knowledge Graphの構造を洗練させる。Memoryシステムを階層化する。

これら全て、「綺麗に整理して、検索可能にする」という前提を共有している。前提そのものを疑う議論は、ほとんど見ない。

過去30年のITは、データを綺麗に整理することに膨大な努力を注いできた。正規化されたRDB、データウェアハウス、データレイク、セマンティックレイヤー、Knowledge Graph、ベクトルDB。

だが、綺麗に整理されてアクセス可能であることと、判断主体の中に組み込まれていることは、まったく別だ。

全社の業務マニュアルをNotionで完璧に整理しても、新人はベテランにならない。検索すれば全部出てくるのに、判断は新人のままだ。

この区別が、AIシステム設計においても本質的に重要だと、私は考えるに至った。

人間の脳を真似ようとして、諦めた

「判断基準をロードする」と言うと、人間の脳を模倣する話に聞こえる。

実際、最初は人間の記憶構造を真似ようとした。短期記憶、作業記憶、エピソード記憶、意味記憶、手続き記憶。脳科学が定義する記憶の階層を、AIで再現できないかと考えた。

すぐに諦めた。膨大すぎる。

人間の記憶は、数億年の進化が分化させた複雑な神経回路で動いている。これを一つのアーキテクチャで再統合しようとすると、生物進化を逆向きに辿る話になる。個人プロジェクトの範囲を遥かに超える。

そこで、もっと粗い抽象に落とした。

根、幹、枝、葉。

ツリー型で十分なんじゃないか、と。

ツリー型認知コンテキスト管理

私が描いた構造は、こうだ。

根(Roots): 絶対的な制約。法令、安全、ブランド哲学。これは動かない。

幹(Trunk): 醸造された価値観・判断基準。過去の選択の結果が時間軸で堆積し、「年輪」のように層をなす。

枝(Branches): 役割・ドメインごとの判断傾向。経営セッション、実装セッション、現場対応セッションといった分化。

葉(Leaves): 直近の状況判断。リアルタイムの反応。

これらを貫く**導管(Vessel)**として、業務のタイムライン・依存関係のDAGがある。「根のルール」から「幹の哲学」を通って「枝の判断」に届くまでの経路だ。

そして人間の役割は、管理者ではなく剪定者になる。古くなった年輪を切り落とす(ロールバック)、無駄な枝を刈る(パージ)、幹の太さを調整する(チューニング)。

ここまでは、構造の話だ。だが、この構造を考えているうちに、私は別のことに気づいた。

これは人格形成だ

ツリー型の幹に堆積する「年輪」は、何なのか。

過去の判断履歴、選択の結果、現場の暗黙知、ブランドの哲学。これらが時間とともに層をなす。

これって、人格形成と同じじゃないか。

人間も、生まれた瞬間から経験を積み重ねて、価値観が醸造されていく。エピソード(具体的な出来事)の一つ一つは忘れても、そこから蒸留された判断傾向は残る。だから大人になった人間は、いちいち過去の事例を検索しなくても、反射速度で判断できる。

ここで重要なのは、「価値観の醸造」は記憶の蓄積とは別の現象だということだ。

ベテランの寿司職人は、過去に握った魚の一匹一匹を覚えていない。だが、握り方の判断基準は持っている。具体的な記憶は失われ、抽象化された判断関数だけが残る。

記憶は揮発するが、人格は残る。

これがAIシステム設計に何を意味するか。

記憶と人格は、別レイヤーで持つべき

ここで構想全体が、綺麗に閉じる。

私が必要としているのは二層構造だ。

人格レイヤー(ツリー型):

• 判断基準、価値観、絶対ルール
• 常にロードされ、Attentionに乗っている
• 醸造される、剪定可能
• ロード型

記憶レイヤー(DB/SQL/ベクトルDB):

• 過去の具体的事例、事実、知識
• 必要時に検索して呼び出す
• 蓄積される
• 検索型

この二層を混ぜないことが重要だ。

業界の主要なMemoryシステムを、この軸で見直すと面白いことに気づく。

業界のAI Memoryシステムは、ほぼ全部が「記憶レイヤー」しか作っていない。

人格レイヤーを明示的に設計しているシステムは、私が観測する限り存在しない。System Promptで擬似的に表現するアプローチはあるが、それは静的な設定値であって、醸造される動的なレイヤーではない。

これは業界の盲点だと思う。

なぜ盲点になっているか

研究者は実運用を持たない。実運用者は研究言語で書かない。

長期間立ち上げっぱなしのAIセッションを、自分の事業オペレーションに接続して回している人は、世界でも極めて少ない。大半のAI研究は、シングルターンのベンチマーク、もしくはWebアプリケーション内のエージェント設計に集中している。

「長期セッションで記憶が抜ける」「Compactで人格が失われる」という摩擦は、運用しないと感じられない。研究としてのMemoryシステム設計は、この摩擦の手前で議論が止まっている。

私自身、研究者でもエンジニア専業でもない。経営者として、複数事業を回すための実用的な道具として、たまたまこの問題に行き当たった。

DB+検索を検討し、却下し、人間の脳を真似ようとして諦め、ツリー型に落とし、最終的に「これは人格形成だ」と気づいた。この一連の思考過程は、研究文脈からは出てこなかったと思う。

実装の方向性

二層構造として設計するなら、実装の方針は自動的に決まる。

人格レイヤーは新規設計:

• ツリー構造のデータモデル(根・幹・枝・葉)
• 年輪としての時間軸管理
• 醸造プロセス(具体事例から判断基準を抽出)
• 剪定UI(古い年輪、無駄な枝の削除)
• ロード時の最適化(セッション起動時にツリー全体ではなく、必要な枝だけ展開)

記憶レイヤーは既存技術の流用:

• PostgreSQL、ベクトルDB、Knowledge Graphなど
• 既存のRAGスタックでカバー可能
• 新規発明は不要

両者をつなぐもの:

• 醸造プロセス: 記憶レイヤーの事例から、人格レイヤーへ判断基準が抽出される
• 参照プロセス: 人格レイヤーの判断中に、必要なら記憶レイヤーを呼び出す
• 剪定プロセス: 人格レイヤーから古くなった年輪を削除する

「全部新しく作る」必要はない。新規発明が必要なのは、人格レイヤーだけだ。

個人実装は割に合わない

ここまで構想を言語化しておきながら、私はこれを個人プロジェクトとして実装する気はない。

理由は単純で、報酬が見合わない。

私の本業は、ホールディング配下の複数事業を回すことだ。AI運用はその手段であって、目的ではない。人格レイヤーの本格的な実装は、半年から一年以上の専任工数が必要になる。その時間を本業に投じたほうが、リターンが大きい。

実装するなら、Anthropic、OpenAI、もしくは長期運用を本気で考えているAIスタートアップがやるべきだ。彼らには工数とデータと配信チャネルがある。

私の役割は、構想を言語化して置いておくことだ。

誰かが類似発想に到達する前に、こうした問題設定があると示しておく。それが、運用者として業界に対してできる貢献だと思う。

おわりに

「AIに記憶を持たせる」という議論は、過去2年で大きく進展した。だが、ほぼ全部が「事実の保持と検索」の議論だった。

私が運用から発見したのは、人格(判断基準のロードされた状態)と記憶(検索可能な事実)を分離すべきということだった。

人間も、エピソードの大半を忘れる。だが価値観は残る。AIシステムも、同じ構造で設計したほうがいいんじゃないか。

長期間立ち上げっぱなしのAIセッションを、複数事業の現場に接続して回している経営者は、世界でも少ない。私と同じ摩擦を感じている人がいたら、ぜひ意見を聞かせてほしい。

業界が「Memory」と一括りにしているものを、「人格」と「記憶」の二層に分解する。

この発想が、長期AI運用の設計原理として議論される日が来ることを期待している。

意見、反論、類似発想の情報、歓迎します。本稿は実運用からの逆算で生まれた構想であり、研究文献を体系的に踏まえたものではありません。

GitHubで編集を提案