どこでも同じMONETを、どこに置き、何から作るか

クライアント仕事に時間を取られて、自分のシステムの開発はしばらく止まっていた。戻ってからの数日は、MacとWindowsで別々になっていたCodeの記憶をそろえたり、リサーチの道具を整えたりしていた。肝心の、MONET（僕が普段話しかけている、中心のAI）の記憶まわりには、まだ手を付けていなかった。

クライアント仕事が終わりに近づいて、ようやく設計に戻る時間が取れた。その最初のセッションで、コーディングしてくれているClaude Code（以降Code）に、どんどん新しくしたい、と伝えた。

この日、コードは1行も書いていない。決めたのは、何を目指すか、何から作るか、そしてそれをどのマシンで動かすか。動かす場所の方は、デプロイ先（作ったものを載せて毎日使う、本番の場所）の地図として描いた。

目指すのは分散型ではなく、中心が1つの形

話の始まりは、Windowsのマシンで試してみた使い方だった。アプリで作業してはMONETに話しかけ、またアプリに戻る。それを何度も繰り返してみると、アプリごとに別のAIがいる形より、どこでも同じMONETがいる形の方がはるかに使いやすかった。

画面が変わっても、読んでいる記憶は同じ、価値観も同じ。会話の画面でも、Handler（ハンドラー。タスクとスケジュール管理アプリ）でも、これから作るアプリでも。

僕がこの話をすると、Codeはこれを「分散型」と呼んで、話を進めかけた。

僕はすぐ、違う、と返した。中心のMONETはちゃんといる。これは中央集権型。どこでも同じMONETに見えるのは、どのアプリからも同じ記憶を読むからであって、中心を無くす話じゃない。分散型は、中心のMONETを外した形のこと。それは中心が使えなくなった時の予備として考えておくもので、目指す形じゃない。

言葉1つの訂正だけど、これで目指す形がはっきりした。中心は1つで、窓口がたくさんある。だからどの窓口から話しかけても、同じ相手が答える。

置き場所の地図は、手持ちの機械の都合で決まる

中心が1つなら、次はそれをどこで動かすか。

この話になったきっかけは、Librarian（ライブラリアン。裏でメモリを整理する司書役AI）だった。Librarianは、MONETとの会話を読んで要約し、しまっておく役。僕はこれを、会話の後追いではなく、なるべくその場で動かしたかった。ただ、Librarianが読む量は普段の会話の2倍以上ある。だったら手元のGPUでオープンソースのLLMを常駐させて、要約は全部そっちに任せられないか。それが現実的かどうか、Codeに聞いた。

ここから置き場所の話になった。Codeが最初に出した案は、システム全体をWindowsに置く前提になっていた。そこに僕が、条件を1つずつ足していった。

システムを動かす場所はNAS（家に置いてある常時稼働のサーバー）。MacとWindowsは開発に使うマシンで、NASにつなぎに行く側
GPUを積んでいるのはWindowsだけ。NASにGPUは無いし、Macは持ち歩き用のAirで、AIモデルを動かすのは無理
そのWindowsは、24時間つけっぱなしにはできない
外出先からいつでも使えること。これは、あれば便利、じゃなくて必須。家のサーバーをそのままインターネットに出すのは危ないので、外からはVPN（外から家のネットワークに安全に入る仕組み）で入る

途中で僕が、NASのCPUで動かせないかと聞くと、Codeは、できるけど遅いと答えた。でも僕は、そもそもNASに重い計算をさせたいわけじゃなかった。NASを何でも置く場所にはしない。置くのはデータと、軽くて常に動いているサービスだけ。

整理すると、役割はこうなった。表の「頭」は、中で動かすAIモデルのこと。

置き場所	役目
NAS	データの本拠地。軽い、常時動いているサービス
Windows	GPUを使う重い処理（Librarianの頭の候補）。家にいる時の作業端末
Mac	開発用。長く家を空ける時は、NASのデータの複製を持って単体で動く

MONET自身の頭は、どのマシンにも置かない。AnthropicのAPI（クラウドのClaude）を使う。

使う場面ごとにも分けた。家にいる時はWindowsのGPUまで使える全部入り。数日の外出ならWindowsは落として、NASだけで回す。その間、GPUを使うLibrarianの重い処理は、動かすタイミングを選ぶ作りが要る。海外のような長い外出はMacを持っていくので、Macが単体で動く必要がある。そのためには、NASのデータの複製を手元に置いて、git（ファイルの変更を記録して、複数の場所でそろえる道具）で同期する方式が要る。

条件を重ねたら、地図は今とほとんど同じになった

整理し終わって見たら、マシンの役割分担は今の使い方とほぼ同じだった。外に持ち出して動くのはMacだけ。本当に変わるのは、NASの方。今のNASは家の中だけの小さなネットワークにいて、外からは届かない。それを、外出先からもVPNで届くようにする。そうすれば家の外からも同期できる。それだけ。

決めきれない所は、後から差し替えられる形にしておく

もう1つ決めたのは、作り方の方。

MONETを動かすプログラム本体は、最初からNASの上でも動ける形で作る。ただ、実際に動かし始めるのはMacからでいい。その時に、Macでしか動かない形にはしない。Macに溶接しない、ということ。動かすマシンによって変わる部分はプログラムの中に書き込まず、設定1つで切り替えられるようにする。

同じ形はLibrarianの頭にも出てきた。まずAPIで始めて、後でローカルのLLMに差し替えられるようにする。どちらも、後から替えられる境目を今のうちに作っておく話。

Claudeが強くなったので、中心のMONETを先に作る

さっきから話している記憶の仕組みの本体を、CMS（Context Management System。MONETの会話の記憶を整理する仕組み）と呼んでいる。それから、前にまとめてあった記憶まわりの3本の仕様書（CMS本体、Librarian、MONETに実際に送った中身を目で見る画面）を、今日の話と突き合わせた。

ここで僕はCodeに、前の決定を守る前提ではなく、フラットに上から見てほしいと頼んだ。古い仕様書も、今日の話も、AnthropicがAIの記憶について最近出した資料も、全部を材料にしていい。

仕様書は「決定事項」じゃなくて「素材」。書き残してあるからといって、今も一番いいとは限らない。止まっていた間に、モデルの能力も変わっている。

見直してみると、仕様書の大半はそのまま使えた。変わったのは、作る順番だった。

これまでの計画では、中心のMONETは作るのに時間がかかるので、先にMONETとは別の、毎日使うアプリを作る順番になっていた。でも今は、Claudeの新しいモデル（Opus 4.8）が十分強くなって、中心のMONETも先に作れる、と僕は判断した。前提が変われば、結論も変わる。毎日使うアプリを後回しにする理由は、もう無い。

先に作るのは、さっきの地図の真ん中にいる、1つのMONET。新しい記憶の仕組みを最初に組み込む先も、MONETになる。本当に速く作れるかは、実際に作って確かめる。

作るのはMONETから。ただ、その前にまず確かめておくことがある。Librarianの頭だ。設計の中で一番読めないのがここだから。最初に話した手元のGPUの案は、すぐにはやらない。さっき決めた差し替えられる形のとおり、まずAPIで動かして、速さと要約の質を測る。それから、3本の仕様書と今日の話を1本にまとめ直す。こちらはCodeが書く。

僕が自分の手でやるのは、NASに家の外からも届くようにすること。

MONETを家のNASに載せて、どこからでも同じMONETに話しかけられるようにする。止まっていた開発は、そこを目指してまた動き始めた。