何が起きていたか

MulmoClaudeには、会話ログから日々の要約を自動生成する journal という裏側の機能がある。この処理が、毎時間動くたびに異常に時間がかかるようになっていた。1回あたり25〜90秒かかっている回もあった。裏で何度もリトライが走っている感触があり、消費されるトークン量も明らかに増えていた。

原因を追う

調べていくと、直前の移行作業(前回の記事参照)で発生した大量のセッション(625個)が、未処理のまま残留していることが分かった。毎時間動く自動処理は、この残留分を毎回すべて処理しようとしてリトライを繰り返していた。処理が終わらない→次の時間にまた同じ分をやり直す、という無限ループに近い状態になっていた。

さらに掘ると、根っこにはもう一段深い原因があった。処理済みかどうかを判定するタイムスタンプの比較で、Python側とNode.js側でミリ秒の扱いが微妙に食い違っていた。片方は切り捨て、もう片方は四捨五入、というようなズレがあり、本来「処理済み」と判定されるべきセッションが毎回「未処理」に見えてしまっていた。何度か修正を試したが、このズレそのものを直さない限り再発する状態だった。

応急処置と本修正

まず journal 機能そのものを一時的にOFFにして、それ以上の消費を止めた。そのうえで、タイムスタンプ精度の扱いを両言語で揃える形に修正。修正後、daysSkipped: 0 で毎時処理の所要時間が2〜3ミリ秒まで落ちたのを確認できた。

設定も見直して、journal は日次1回(dailyIntervalHours: 24)に固定。毎時のスケジューラーチェック自体は軽い処理だけに留めるようにした。

常時稼働は、アプリ本体だけでなく裏側の自動処理まで含めて「壊れない」ようにする話だと分かった。表から見えない場所ほど、地味にコストがかかっていたりする。

つづく。

構成を決めるまで

自分のマシンから直接SSHで繋ぐ案は、会社のネットワークがoutboundのポート22を塞いでいることが多いので早々に除外した。代わりに、ドメイン経由でHTTPSアクセスし、手前にCloudflare Accessで認証ゲートを置く構成にした。ログインはGoogleアカウント、加えてアプリ側の共有シークレットでも二重にロックしている。

クラウドはさくらのクラウドとAWS Lightsailで迷ったが、Singaporeリージョンのレイテンシを優先してLightsailにした。最初は$7/月(1GB RAM、2 vCPU)の一番小さいバンドルから始め、足りなければ後で上げる方針にした。

詰まったところ

1. 送信しても無反応になる(CSRF)

移行作業自体は終わったのに、ブラウザからメッセージを送っても何も起きない。エラーも出ない。原因は、アプリ内蔵のCSRFガードがOriginヘッダーをチェックしていて、新しいドメインを.envのMULMOCLAUDE_TRUSTED_ORIGINSに追加し忘れていたことだった。自分の公開ドメインをここに足してsystemctl restartしたら直った。同じようにセルフホストしていて、公開ドメインからの送信だけ無言で失敗する場合は、まずここを疑うといい。

2. 内部API呼び出しが断続的に失敗する

数日後、presentFormやmanageCollectionなど内部のMCPブリッジ呼び出しが「Network error calling …: fetch failed」で落ちるようになった。最初はメモリ不足を疑い、zram-toolsで圧縮swapを作ったり、Lightsailのプランを$7/月(1GB)から$12/月(2GB)に上げたりしたが、症状は変わらなかった。

結局、アプリのソース(server/index.ts)を読んで根本原因が分かった。アプリは127.0.0.1にしかbindしない設計になっており、Mac(Docker Desktop)ではこれがhypervisor越しにloopbackへ届くのに対し、Linux(Docker Engine)では単にdocker0ブリッジの実IP(このケースでは172.17.0.1)に解決されるため、接続を受け付けていなかった。Macでは表面化しなかった設計上の穴が、Linux移行で初めて出てきた形だ。修正は、socatでブリッジ側からloopbackへTCPを1本中継するだけで済んだ。

ExecStart=/usr/bin/socat TCP-LISTEN:3001,bind=172.17.0.1,fork,reuseaddr TCP:127.0.0.1:3001

これをsystemdサービスとして登録したら、curl http://host.docker.internal:3001/が200を返すようになり、機能もすぐに正常化した。メモリ・zramの対応が無駄だったわけではないが(実際に空きは増えた)、このエラーの直接原因ではなかった。

3. プランを下げようとしたら作り直しになった

原因判明後、節約のため$7/月(1GB)に戻そうとしたが、Lightsailはスナップショット経由でのプラン縮小に対応しておらず、1GBインスタンスを作り直す必要があった。作り直したインスタンスは、Dockerのサンドボックスイメージビルドのような負荷時にたびたびハングし、SSHもブラウザコンソールも反応しなくなることが複数回あった。このワークロード(本体+Dockerサンドボックス+Telegram bridge)は1GBでは支えきれないと判断し、$12/月(2GB)を最終プランとして確定した。

いくつかのつまずきを経て、今はこのサーバーが24時間動き続けている。

まずは、そもそもの始まりの話から書く。

きっかけ

中島聡さんのニュースレターで「MulmoClaude」というものを知った。ChatGPTやClaudeのようなAIアシスタントを、SaaSとしてではなく自分のマシン上でセルフホストできるOSSプロジェクトで、会話履歴や記憶させた情報が全部ローカルのファイルとして自分の手元に残る、という点に惹かれた。試しに自分のMacBookに導入してみることにした。環境は Node.js v24.18.0、git 2.50.1、Claude Code CLI v2.1.220。

最初のつまずき: ERR_MODULE_NOT_FOUND

導入方法はいくつかあり、最初は receptron/mulmoclaude を git clone する開発者向けの方法を選んだ。yarn install して yarn dev で起動しようとしたところ、ERR_MODULE_NOT_FOUND のビルドエラーで起動しなかった。原因は、パッケージ群のビルドが済んでいない状態で dev を起動しようとしていたこと。yarn build:packages:dev を先に実行してからだと、あっさり起動した。同じエラーで詰まっている人がいたら、まずこの順番を疑ってみてほしい。

動くようにはなったが、調べると公式が推奨しているのは npx mulmoclaude@latest というもっとシンプルな方法だった。ビルドの手間もgit cloneの管理も不要で、同じ日のうちに乗り換えた。ポートも git clone/yarn dev 版の 5173 から、npx版の 3001 に変わった。今もこのnpx版をベースに使い続けている。最初からこちらを選んでいれば、ERR_MODULE_NOT_FOUND にも遭遇しなかったはずだ。

実際に使える環境に仕上げる

動くようになってからは、日常的に使えるように何点か手を加えた。まず、パソコンの前にいないときにも使いたかったので、Telegramのbot(taiki_mulmoclaude_bot)をBotFather経由で作成し、公式のTelegram Bot APIの手順どおりに連携させた。外出先からでもチャットできるのは地味に便利だった。

あわせて、それまで公式のClaudeアプリで会話してきた蓄積(仕事の話、住んでいる場所、興味関心、日々の記録など)を、この新しい環境の「記憶」(ローカルのMarkdownファイルとして蓄積される仕組み)として移行した。ゼロから育てるのではなく、これまでの会話の続きから始められたのは大きかった。

最後に、ローカル環境が壊れたら全部消える、というのは避けたかったので、早い段階でGitHubにprivateリポジトリを作り、git push による定期的な自動バックアップの仕組みを整えた。この習慣は今も続いていて、後々サーバー移行を決める安心材料にもなった。

ここまでで、パソコンの中にMulmoClaudeを構築し、Telegram経由でも使えて、データもGitHubで守られている状態になった。

つづく。