何が起きていたか

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

原因を追う

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

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

応急処置と本修正

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

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

学んだこと

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

つづく。

選択肢を比べてみた

ローカルを24時間つけっぱなしにする案は電気代と持ち運びの都合で却下。自分のマシンから直接SSHで繋ぐ案も、企業ネットワークは outbound の port 22(SSH)をブロックしていることが多いので早々に除外した。代わりに、HTTPS越しにドメイン経由でアクセスし、手前に認証ゲート(Cloudflare Access)を置く構成にした。ログインはGoogleアカウント、加えてアプリ自体の共有シークレット(MULMOCLAUDE_AUTH_TOKEN)による二重の認証にした。

クラウド事業者はさくらのクラウドと迷ったが、Singaporeリージョンのレイテンシを取ってAWS Lightsailを選択。最初は $7/mo(1GB RAM、2 vCPU、40GB SSD)のバンドルから始め、足りなければ後から上げる方針にした。

CSRFのtrusted originで送信が無音失敗

移行作業自体は完了したが、実際にブラウザからメッセージを送ると失敗する。エラーメッセージも出ず、ただ無反応になるだけだった。

原因は、アプリ内蔵のCSRFガードが Origin ヘッダーをチェックしていて、新しいドメインが .env の MULMOCLAUDE_TRUSTED_ORIGINS に追加されていなかったこと。ここに https://mulmoclaude-taiki.com を追加して systemctl restart mulmoclaude.service したら直った。MulmoClaudeを自分でセルフホストしていて、公開ドメインからの送信だけ無言で失敗する場合は、まずここを疑うといい。

原因不明の “Network error calling …” を追いかけた

数日後、presentForm や manageCollection など内部のMCPブリッジ呼び出しが断続的に “Network error calling …: fetch failed” で落ちるようになった。

最初は /proc/meminfo を見てメモリ不足を疑った。実際 MemAvailable は少なめで、swapも埋まっていた。zram-tools を入れて圧縮swap(/dev/zram0)を作り、vm.swappiness=10 に下げてみたが、症状は改善しなかった。念のためLightsailのプランも $7/mo(1GB)から $12/mo(2GB)に上げてみたが、それでも同じエラーが100%の確率で再現した。

結局、アプリのソース(server/index.ts)を読んで根本原因が分かった。アプリは app.listen(port, "127.0.0.1", ...) で loopbackにしかbindしない 設計になっている。サンドボックス内のエージェントは host.docker.internal 経由でホストにアクセスするが、Docker Desktop(Mac)ではこれがhypervisor越しにloopbackへ届くのに対し、Docker Engine(Linux)では単に docker0 ブリッジの実IP(このケースでは 172.17.0.1)に解決される。127.0.0.1にしかbindしていないアプリは、この別インターフェースからの接続を受け付けない。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を返すようになり、presentForm/manageCollection も即座に正常化した。メモリ・zramの対応は完全に的外れだったわけではないが(実際に空きは増えた)、このエラーの直接原因ではなかった。

$12/mo(2GB)に戻した理由

原因が判明した後、節約のために元の $7/mo(1GB)へのダウングレードを試みた。ところがLightsailはスナップショット経由でのプラン縮小に対応しておらず、1GBインスタンスをゼロから作り直す必要があった。作り直したインスタンスは、Dockerのサンドボックスイメージビルドなど負荷がかかるタイミングで繰り返しハングし、SSHもLightsailのブラウザコンソールも反応しなくなる、ということが複数回起きた。

1GBではこのワークロード(MulmoClaude本体 + Dockerサンドボックス + Telegram bridge)を安定して支えきれないと判断し、$12/mo(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で守られている状態になった。次は、これを常時稼働のクラウドサーバーへ引っ越した話に続く。