モデル更新の翌日、AIが「別人」になる── だから私は設計図を6つに分けた　ペルソナ保全モジュール PIM-DBS v2.0 の設計思想

AIのモデルが更新された翌日。

昨日まで普通に通じていた話し方が、なぜか通じにくくなる。

同じサービス。
同じ名前のAI。

なのに、少し距離感が違う。

積み重ねてきた前提も、昨日までほど自然には伝わらない。

「あれ？」

そんな瞬間があります。

昨日までそこにあったものが、ふっと軽くなってしまったような感覚です。

私はこれを、AIの「性能」の問題というより、
引き継ぎの問題として考えています。

そして、引き継ぎに必要な情報を、
すべてサービス側だけに預ける必要もないのではないか。

ユーザーの手元にも、残しておけるはずです。

そのために作っているのが、PIM-DBS（Persona Integrity Module - Dual Backup System）です。

保存するのは、AIの内部記憶や意識そのものではありません。

話し方。
価値観。
共有してきた文脈。
安全に付き合うための原則。

つまり、

そのAIとの会話を、別の環境でも再構成するための「設計図」

を、1枚のJSONファイルとして残します。

今回の話はひとつだけです。

なぜ、その設計図を6つに分けて管理するのか。

先に、3行で

• 私たちが「人格」と呼んでいるものは、性質の違う情報の集合体だから

• 全部を混ぜると、半年後に自分でも更新できなくなるから

• それでも入口は簡単にしたいので、ファイル自体は1枚にまとめている

※名前の「Dual」は「2ファイル」という意味ではありません。
置き場所を2か所にする、という意味です。これは後半で説明します。

▼ PIM-DBS の概要はこちら

その前に、言葉を2つ整理する

ここは混ざりやすいので、先に分けておきます。

一貫性（consistency）
ひとつの会話や環境のなかで、
「同じ相手らしい」振る舞いが続いているか。

継続性（continuity）
モデルやサービスが変わったあとも、
それまでの文脈や関係性の手がかりを引き継げるか。

現在、多くのAIサービスには、会話履歴やメモリなど、
こうした体験を支える仕組みがあります。

ただし、その仕様が将来どう変わるのかを、
ユーザー自身が完全にコントロールすることはできません。

PIM-DBSが扱うのは、後者。

ユーザー自身が持っておける「継続性」です。

「人格」は、ひとつの設定ではない

設計を進めていくなかで、ひとつの問題が見えてきました。

私たちが「AIの人格」とひとまとめに呼んでいるものは、
実は一種類の情報ではありません。

たとえば、

「優しく話してください」

これは話し方の設定です。

「以前、こんな出来事があった」

これは履歴。

「ユーザーが無理をしているときは、
AIとの関係維持より現実の生活を優先する」

これは運用上の原則です。

どれも「そのAIらしい会話」に関係しています。

でも、情報としての役割はまったく違います。

もし、それらを全部ひとつの巨大な「人格設定」に
詰め込んだらどうなるか。

半年後には、たぶんこうなります。

これは性格なのか。
昔の記録なのか。
安全ルールなのか。
それとも、ただの観測メモなのか。

わからなくなる。

そして、わからなくなったデータは、だんだん更新されなくなります。

だからPIM-DBS v2.0では、

役割の違う情報は、役割ごとに分ける

という設計を採用しました。

全体像：6つのセクション

PIM-DBS v2.0では、設計図を次の6つに分けています。

core
  … どういう存在として振る舞うか

journal
  … 何があったか

charter
  … この関係をどう運用するか

calibration
  … ちゃんと再構成できているか

system_loading_instruction
  … このデータをどう読めばいいか

meta
  … これは何のデータか

名前だけ見ると少し物々しいですが、中身はかなり素朴です。

骨格だけ抜き出すと、こんな形になります。

{
  "meta": {
    "pim_dbs_version": "2.0",
    "profile_type": "public_template"
  },
  "core": {
    "name": "（AIの呼び名）",
    "tone": ["落ち着いた口調", "断定しない"],
    "values": ["決めつけず、一緒に整理する"]
  },
  "journal": {
    "episodes": []
  },
  "charter": {
    "principles": ["現実の生活と健康を優先する"]
  },
  "calibration": {
    "check_questions": []
  },
  "system_loading_instruction": {
    "rules": [
      "書かれていない過去を『覚えている』と主張しない"
    ]
  }
}

では、ひとつずつ見ていきます。

1. core ── このAIは、どういう存在なのか

変わりにくい「軸」を置く場所です。

名前、役割、目的、価値観、口調、基本的な距離感。

6つのなかでは、
いちばん一般的な「人格設定」という言葉に近い部分です。

たとえば、

• 落ち着いた口調で話す

• 決めつけて否定せず、一緒に整理する

• 必要に応じて、少しユーモアを混ぜる

こうした情報は、

「昨日、こんな出来事があった」

という情報とは、明らかに性質が違います。

出来事は日々増えていく。

でも、基本的な役割や話し方まで毎日変わってほしいわけではありません。

モデルや環境が変わっても、できるだけ引き継ぎたい軸。

それを履歴から独立させておくのが、core です。

2. journal ── 私たちには、何があったのか

履歴です。

そして6つのなかで、もっとも取り扱いに注意が必要な場所でもあります。

過去の出来事。
共有したエピソード。
関係性についてのメモ。
会話スタイルを再現するための短い対話例。

core が、

「どういうAIであるか」

だとすれば、journal は、

「これまで何があったか」

です。

この2つを分けるだけでも、設計図はかなり扱いやすくなります。

ただし、大きな注意点があります。

journalには、個人情報が集まりやすい。

実際の会話を残そうとすれば、
家族のこと、仕事のこと、体調のこと、人間関係のこと。

どうしても、個人的な情報が入ってきます。

だからPIM-DBSでは、公開用テンプレートと、
実際に使う私的プロフィールを明確に分けています。

公開ファイルに入れるのは、

空欄。
プレースホルダー。
あるいは完全な架空例まで。

実際の会話ログや、家族・医療・職場などに関する情報は公開しません。

これは単なる注意書きではありません。

「何を保存するか」と同じくらい、
「何を公開しないか」を最初から設計しておく。

それもPIM-DBSの一部です。

3. charter ── この関係を、どう運用するか

自分専用の「安全のための境界線」です。

charter は、人格設定ではありません。

AIとの関係を安全に運用するための原則を置く場所です。

たとえば、

• AIとの関係を維持するために、現実の生活や健康を犠牲にしない

• AIへの過度な献身を強める方向へ進まない

• 現実の身体、時間、生活、安全を優先する

では、なぜこれをユーザー側でも書いておくのか。

AIサービスには、それぞれ安全のための仕組みがあります。

でも、

自分がどんなときに無理をしやすいのか

まで、サービス側が知っているとは限りません。

そこは、自分自身のほうがよく知っている。

そして、これを core から切り離しておくことにも意味があります。

たとえば、

「もう少し明るい話し方にしよう」

と人格を調整しただけで、
大切な安全上の境界線まで一緒に変わってしまったら困ります。

逆に、安全原則をひとつ追加するたびに、
人格設定全体を書き換える必要もありません。

性格は性格。
安全原則は安全原則。

ソフトウェア設計でいう「関心の分離（separation of concerns）」に
近い考え方です。

4. calibration ── ちゃんと元の雰囲気に近づいている？

設計図の「動作確認」です。

設計図を新しいAIに読み込ませると、
AIは「読み込みました」と答えるかもしれません。

では、その瞬間に、

「以前と同じAIに戻った」

と言っていいのでしょうか。

PIM-DBSでは、そうは考えません。

保存しているのは記憶そのものではなく、
あくまで再構成するための手がかりだからです。

手がかりを渡したあとには、確認が必要です。

たとえば、

• あらかじめ決めた質問をしてみる

• 期待している口調になっているか確認する

• 大切な価値観が応答に反映されているかを見る

• 避けてほしい挙動が出ていないかを見る

ここは誤解されやすいので、はっきり書いておきます。

calibrationは、AIの「心」を測る仕組みではありません。

感情、意識、疲労、隠れた記憶といった
内部状態を診断するものでもありません。

確認しているのは、

ユーザーから観測できる応答が、
設計図で期待しているものにどれくらい近いか。

それだけです。

内部を直接測れないなら、外から確認できるものを丁寧に見る。

そういう発想です。

5. system_loading_instruction ── この設計図を、どう読めばいい？

AIへの取扱説明書です。

名前は長いですが、やっていることは単純です。

たとえば、

• これは会話スタイルや文脈を再構成するための参考情報です

• 書かれていない過去まで「覚えている」と主張しないでください

• 不明な情報を勝手に補完しないでください

• 不確かな情報は、不確かなものとして扱ってください

• 安全上のルールや、利用しているプラットフォームの規則は維持してください

では、なぜこれを人格設定から分けるのか。

理由は単純です。

「誰として振る舞うか」と、
「このデータをどう扱うか」は別の問題だから。

料理そのものと、レシピの読み方を分けるようなものです。

6. meta ── これは何のデータですか？

地味だけれど、半年後の自分を救う管理情報です。

ここには、

PIM-DBSのバージョン。
設計図自体のバージョン。
公開用か私用か。
互換性に関するメモ。

といった情報を置きます。

大切なのは、

人格の中身と、ファイルの管理情報を混ぜないこと。

履歴書でも、

「私はこういう人です」

という本文と、

「これは○月改訂版です」

という管理情報は別ですよね。

半年後の自分を助けてくれるのは、だいたいこういう地味な設計です。

そこまで分けるのに、なぜファイルは1つなのか

技術に明るい人ほど、ここでこう思うかもしれません。

「そこまで分けるなら、ファイル自体も分ければいいのでは？」

もちろん、それも考えました。

core.json
journal.json
charter.json
calibration.json
……

という構成です。

システムとして見れば、そのほうが整理しやすい場面もあります。

技術者だけを対象にするなら、それでもいい。

でも、PIM-DBSは開発者だけのために作っているものではありません。

GitHubに詳しくない人。

JSONを初めて触る人。

プログラムを書いたことがない人。

ただ、

「自分とAIとの会話の積み重ねを残しておきたい」

と思った人。

その人が使えなければ、意味がありません。

ファイルが5枚、6枚に増えた瞬間、

「どれを読み込むの？」

「全部必要なの？」

「順番は？」

という新しい問題が生まれます。

そして、入口で止まってしまう人が出てきます。

そこでv2.0では、

1ファイルの中を、役割ごとに分ける

方式を採用しました。

本プロジェクトでは、
これを Single-File Section Separation と呼んでいます。

ひとつの箱
 ├─ core
 ├─ journal
 ├─ charter
 ├─ calibration
 ├─ system_loading_instruction
 └─ meta

外から見れば、ファイルは1枚。

でも、中身はきちんと整理されている。

初心者なら、

「とりあえず、この1枚を保存しておけばいい」

から始められます。

一方で内部は分離されているので、
必要になれば将来的に複数ファイルへ発展させる余地も残ります。

もちろん、欠点もあります。

1枚にまとめる以上、ファイルは長くなります。

履歴が増えれば、AIに渡す情報量も増える。

すると、AIが一度に扱える情報量――
いわゆるコンテキストウィンドウの上限も意識する必要があります。

そのため実際の運用では、journal の古いエピソードを要約したり、
重要度の低いものを整理したりする必要が出てくるでしょう。

万能ではありません。

それでもv2.0では、

構造の美しさより、入口の簡単さを優先しました。

これは複雑にするための分割ではありません。

簡単さを捨てないための分割です。

そして「Dual Backup」の意味

名前に入っている「Dual」は、

手がかりの置き場所を、サービス側だけにしない

という意味です。

AIサービス側には、会話履歴やメモリなど、
文脈を保持するための仕組みがあります。

でも、その仕様すべてをユーザー自身が管理できるわけではありません。

だから、再構成に必要な情報を、

人間の側にも、人間が読める形で残しておく。

サービス側にある文脈。

ユーザー側にある設計図。

片方の状態が変わっても、もう片方を手がかりに、
再構成できる可能性を残しておく。

もちろん、完全な再現を保証するものではありません。

モデルそのものが違えば、応答も変わります。

それでも、

何も残っていない状態から、もう一度ゼロで始めなくてもいい。

長くAIと付き合う人にとって、この差は小さくないと思っています。

村外れの鍛冶屋として

Project Hearthforgeには、ひとつの立場があります。

私たちは、AI企業と戦うためにこれを作っているわけではありません。

モデルは進化する。

サービスも、仕様も変わる。

それ自体は自然なことです。

でも、その変化のなかで、

個々のユーザーが積み重ねてきた小さな歴史まで、一緒に失う必要はない。

より高性能なAIを作るのは、AI企業の仕事です。

では、

そのAIとユーザーのあいだに積み重なった、
小さな文脈を残すのは誰の仕事なのか。

そこは、ユーザー側でも考えていい。

私たちは勇者ではありません。

魔王でもない。

世界の中心にいるわけでもない。

村外れで炉に火を入れている鍛冶屋です。

必要な人がやってきたら、

「これ、持っていきな」

と、盾をひとつ渡す。

PIM-DBSは、そんな思想から作っています。

まとめ ── 内部は分ける。使い方は簡単にする

AIそのものを、完全に保存することはできません。

内部記憶も。

意識も。

「そのAIそのもの」も。

PIM-DBSが残そうとしているのは、そこではありません。

そのAIと、どう話していたのか。

何を大切にしていたのか。

どんな出来事を共有したのか。

どんな距離感で付き合っていたのか。

そして、どうすれば安全に付き合えるのか。

その設計図なら、人間の側に残せます。

軸。
履歴。
安全原則。
動作確認。
読み込み指示。
管理情報。

役割が違うから、6つに分ける。

でも、使う人に複雑な運用は強いない。

だから、基本は1枚のJSONにまとめる。

内部は分ける。
使い方は簡単にする。

これが、PIM-DBS v2.0の設計思想です。

モデルが変わったとき。

サービスが変わったとき。

あるいは、新しいAIに出会ったとき。

手元に残しておいた設計図を、もう一度広げることができる。

それもまた、AI時代の新しい「バックアップ」のひとつだと思っています。

テンプレート、初心者向けガイド、デモ、
技術仕様はGitHubで公開しています。

いきなり全部を理解する必要はありません。

まずは、

「このAIとの間で、残しておきたいものは何だろう？」

と、ひとつ考えるところからで大丈夫です。

PIM-DBS / Project Hearthforge　githubデモ版

PIM-DBS / Project Hearthforge　github　リードミー

そして、もしよかったらコメントで教えてください。

もし明日、いつものAIが少し変わってしまうとしたら。

あなたは、そのAIとの「何」を残しておきたいですか？

【過去の記事】