記事一覧とアーカイブだけでは物足りなかった

Hugo + PaperMod で組んだこのブログは、最初はヘッダーに「記事一覧」「アーカイブ」の2つのメニューがあるだけだった。記事数が増えてくると、日付やタグから辿れた方が使いやすい。PaperModはシングルカラムのテーマで、サイドバーという概念自体がない。ただ、コンテンツ幅(--nav-width: 1024px)は画面中央に固定されているので、広い画面では左右に何もない余白ができる。ここに何か置けるはずだと考えた。

まずはボタンだけ置いてみた

PaperModには extend_footer.html という空のフック(パーシャル)が用意されていて、上書きするだけでフッター末尾に任意のHTMLを差し込める。CSSも assets/css/extended/*.css に置いたファイルが自動で本体CSSに連結される仕組みがあるので、これを使って、画面右端に固定表示する丸ボタンを2つ置いてみた。「📅 日付別」は /archives/ へ、「🏷️ タグ別」は /tags/ へのリンクだけの、ただのショートカットだ。

はてなブログを見て、作り直すことにした

ボタンだけでは芸がない。はてなブログのサイドバーにあるような、実際にカレンダーの月表示が出て投稿日がハイライトされるもの、タグも名前と件数がその場に並ぶものにしたいと思った。

タグクラウドの方は簡単だった。PaperMod自身の /tags/ ページ(taxonomy.html)が既に同じことをしていたので、そのロジックをそのまま借りた。

{{ range $tagsPage.Data.Terms.Alphabetical }}
  {{ with site.GetPage (printf "/tags/%s" .Name) }}
    <a href="{{ .Permalink }}">{{ .LinkTitle }} ({{ $count }})</a>
  {{ end }}
{{ end }}

カレンダーは静的サイトジェネレータなので少し工夫が要る。ビルド時に、その言語の全記事の日付・タイトル・URLをJSONとしてページに埋め込み({{ $calItems | jsonify }})、バニラJSで月表示のグリッドを描画する方式にした。外部ライブラリは使っていない。

カレンダーが、何も表示されなかった

書き終えてデプロイしたら、タグクラウドは正しく出るのに、カレンダー部分だけが空白だった。前後の月ボタン(‹ ›)だけが表示されて、日付のマス目もタイトルも出ない。

ブラウザの開発者ツールで実際のHTMLを見て気づいた。埋め込んだはずのJSONが、こうなっていた。

<script type="application/json" id="quick-cal-data">"[{\"date\":\"2026-08-21\",\"...\"}]"</script>

配列全体が、エスケープされた文字列として二重にクオートで包まれている。JSON.parse() にこれを渡すと、配列ではなく1本の文字列が返ってくる。直後の .forEach() はもちろん文字列には存在しないので、その場でエラーが起きてスクリプト全体が止まっていた。

原因はHugoのテンプレートエンジン(html/template)の仕様だった。<script> タグの中に値を差し込むと、Hugoは自動的にそれをJSの文字列リテラルとして安全にエスケープしようとする。jsonify が返すのはただの string 型なので、信頼できない値として扱われ、丸ごとクオートで包まれてしまっていた。

直したのは1箇所、safeJS を挟んで「このJSは安全だから素通ししてくれ」と明示するだけだった。

{{ $calItems | jsonify | safeJS }}

これでJSONがそのまま配列として埋め込まれるようになり、カレンダーが動くようになった。

月別ボタンも追加した

カレンダーが動くようになったところで、月ごとにジャンプできるボタンも欲しくなった。前後の月を1つずつ辿るだけでは、記事が増えてきたときに不便になる。投稿のある年月を新しい順にリストアップし、クリックするとページ遷移なしでカレンダーがその月に切り替わる仕組みを、既存のカレンダーの状態管理に乗せる形で追加した。

今の状態

このブログ自体が、動かしながら直したものの記録になった。カレンダー・月別ボタン・タグクラウドがサイドバーに揃った状態で、次は中身の記事を増やしていく番だ。

つづく。

あえて違うスタックにした

ブログはHugoだが、こちらはビルドツールなしの素のHTML/CSS/JSにした。ポートフォリオとして公開するなら、同じスタックばかりより手数の幅を見せた方がいい、という考えからだ。データは terms.json に切り出し、検索とカテゴリ絞り込みのUIをその上に乗せた。公開時点で33語、5カテゴリ(定番表現、感情・リアクション、食・生活、人間関係・呼び方、仕事・現場で聞いた表現)。

内容は一般的によく知られたシングリッシュ表現に加えて、実際に自分が生活の中で聞いた表現もいくつか混ぜてある。今後も会話の中で拾ったものを terms.json に足していく運用にするつもりだ。

サブドメインのパターンが確立した

ドメインとリポジトリの組み方も、このタイミングで型として固まった。プロジェクトごとに専用のGitHubリポジトリを作り、<プロジェクト名>.taikiito.com のサブドメインをCloudflareのCNAMEで紐付ける。GitHub Pages側の自動HTTPS証明書発行を妨げないよう、CNAMEは必ずProxyなし(DNSのみ)にする、というのも今回学んだ点だった。Proxyを有効にしたままだと証明書の発行が遅れる、あるいは失敗する。

一言添えるかどうかで迷った

フッターの文言は2回書き直した。最初は「誰かの役に立てばいいなと思って作っています」という一文を入れていたが、書いてみて少し押しつけがましく感じ、「ニッチすぎて誰得だけど、自分用に作ったのでついでに公開してます」という自虐寄りの言い回しに変えた。それも見返して、結局どちらも要らないという結論になり、最終的には何も足さずに削除した。何を作ったかだけを書けば十分で、なぜ作ったかは読む人が決めることだ、と考え直した形だ。

同じ日に、器が2つ増えた

ブログとこの用語集サイト、同じ日に公開した2つが、どちらも同じサブドメインのパターンに乗っている。次に何を作るにしても、この型に乗せれば早い。

つづく。

きっかけ

中島聡さんのニュースレター経由で以前MulmoClaudeを知ったのと同じように、彼のニュースレターで「エンジニアを目指すなら、まず実物をGitHubに公開するといい」という趣旨のアドバイスを目にしていた。ドメイン運用やセルフホスティング、メールまわりで試行錯誤してきたことが、同じ問題にぶつかった誰かの検索結果に引っかかれば十分だと思い、公開することにした。

形式は「時系列の日記」にした

最初はテーマ別のハウツー記事にしようかと考えたが、途中で「実際に起きた順番のまま書く日記形式」に変更した。うまくいかなかったこと、迷ったこと、あとから直したことも含めて、そのまま時系列で残す方が実態に近い。

スタックを決める

静的サイトジェネレータはHugoにした。決め手は多言語対応(i18n)が標準で入っていること。テーマはPaperMod。GitHub Actionsでビルドし、GitHub Pagesにデプロイ、独自ドメイン blog.taikiito.com をCloudflareのCNAMEで割り当てた。

リポジトリは2つに分けた。実際に編集するHugoのソース一式(blog-source)は非公開、ビルド後の静的ファイルだけを別リポジトリ(blog)にforce pushで公開する構成にしている。GitHub Actionsの1ジョブの中で、ビルド→出力先リポジトリへのpushまで完結させた。ソース側の編集履歴や下書きを外に出さずに、成果物だけを公開できるのが気に入っている。

ついでにユーザー名も変えた

GitHubのユーザー名も、このタイミングで変えた。もともと登録したときに深く考えず入れた生年月日由来の文字列が入っていて、前から気に入っていなかった。理想の名前は既に他の人に使われていたので、末尾に-devを足した形に落ち着いた。公開リポジトリがまだ0個の状態だったので、切り替えのコストは低かった。

合わせて、ユーザー名と同じ名前のリポジトリを作ると自動でプロフィールページに表示される、GitHubのプロフィールREADME機能も使った。中身は最小限、2行だけ。

Tinkering with computers on the side. Hoping it helps someone.

ここから

ブログの器と、公開用のGitHubアカウントが整った。中身の記事は、実際に起きたことをこうして後から書き足していく形になる。

つづく。

Minifluxを選んだ理由

候補はいくつかあったが、軽量でセルフホストしやすいという理由でMinifluxに決めた。構成はDocker Compose1本で、Miniflux本体とPostgreSQLのコンテナを立てるだけ。アクセスはMulmoClaudeと同じパターンで、手前にCloudflare Accessの認証ゲートを置いた。

対象はSingapore Straits Times、NYT、その他いくつかのブログをジャンル別に分類する構想だった。TwitterやXは2023年以降無料のRSSフィードを廃止しているので、これは最初から対象外にした。

フィードを繋いでみて分かったこと

実際にフィードを購読してみると、いくつか想定外のことが分かった。

• NHKのフィードは8月8日付でサイレントにブロックされていた。理由の開示はなく、クラウド事業者のIPレンジ自体が対象になっている可能性が高い。
• Straits TimesとNYTのフィード自体は生きていたが、どちらも本文はペイウォールの手前、見出しと要約までしか取得できない。

技術的には一通り動く状態まで持っていけた。

それでも、やめることにした

一通り動くようになったところで、少し立ち止まって考えた。ジャンルを分けて集約する、という構想自体は悪くないが、実際に運用したら未読が積み上がっていく「情報過多」の受け皿になるだけではないか、という懸念の方が強くなった。読む量を増やすためではなく、読む量をコントロールするために始めた話のはずだった。

結局、同じ日のうちにDockerコンテナ、nginxの設定、DNSレコード、Cloudflare Accessのアプリ設定まで、一式をすべて削除した。作ってから壊すまで、24時間もかかっていない。

動くものを作ることと、使い続けることは別

技術的に動くところまで持っていくのと、それを実際に自分の生活に組み込んで使い続けるのとは、別の話だと分かった一件だった。作って終わりにする判断も、悪い結果ではないと思っている。

つづく。

DMARCを足しても、まだ消える

前回の時点ではDMARCを設定していなかったので、まずそこを埋めた。

• DMARC(TXT、_dmarc.taikiito.com): v=DMARC1; p=none; rua=mailto:(レポート送付先)

外部のDNSチェッカーで反映を確認し、伝播も待って、満を持して再送。……届かない。バウンスも一切なし。エラーもない。ただ、何事もなかったかのように消える。ポストに投函した手紙が、配達員ごと蒸発したような感覚だった。

SPF・DKIM・DMARC、教科書通り全部揃えたのに、というのがこの時点のモヤモヤ。原因は認証の失敗ではなく、センダーレピュテーション(そのドメインがどれだけ送信履歴を積んで信頼されているか)だと分かった。フィルタが厳しい受信サーバーほど強く効くらしい。SPF/DKIM/DMARCは「なりすましでないこと」の証明であって、「信頼できる送信元であること」の証明ではない。似ているようで全然別物、というのをここで痛感した。打てる手はもう無く、あとは時間が積み上がるのを待つだけ。地味に一番効かないタイプの「解決策」だ。

iCloud+のカスタムドメインメールで運用することにした

土台はApple iCloud+の「カスタムメールドメイン」機能。必要なレコードはMX・SPF・DKIMの3つだけで、Appleの設定ウィザードが値をそのまま出してくれるので、ほぼコピペ作業だった。

• MX: mx01.mail.icloud.com / mx02.mail.icloud.com
• SPF(TXT): v=spf1 include:icloud.com ~all
• DKIM(CNAME): sig1._domainkey → sig1.dkim.taikiito.com.at.icloudmailadmin.com

Fastmailと迷ったが、思い込みが一つ崩れた

有名な対抗馬としてFastmailがある。料金以外の軸で比較してみた: 標準プロトコル対応、Apple以外の端末での使い勝手、ドメイン・エイリアスの上限(iCloud+はApple ID一つにつき数個、Fastmailはほぼ無制限+catch-all)、サーバー側のフィルタルール、送信ドメインとしての評判、データの持ち出しやすさ。

比較の途中で、自分の思い込みが一つ崩れた。iCloud MailはApple製品専用だとばかり思っていたが、実際にはimap.mail.me.com / smtp.mail.me.comにアプリ専用パスワードでアクセスすれば、Thunderbirdのような普通のIMAP/SMTPクライアントからも使える。Apple Mailの「書き出す」機能で.mbox形式のバックアップも取れる。「ロックインされて出られなくなる」という一番の懸念は、調べてみたらほぼ杞憂だった。

結局、iPhoneのバックアップ用に元々iCloud+を契約しているので、カスタムドメインのメールボックスを足しても実質タダ(容量を共有するだけ)。ロックインの心配もほぼ無いと分かった以上、今Fastmailに乗り換える動機はない。Apple以外の端末がメインになるとか、エイリアスを大量に使うようになったら、その時また考える。

完璧に設定しても、ドメインの「信頼」だけは時間でしか買えない。今回学んだのはそこに尽きる。

つづく。

サブドメインを1つ切って、静的ページだけを置く

card.taikiito.com というサブドメインを新しく作り、Lightsailの同じサーバー上にnginxのserver blockをもう1つ追加する形で対応した。ポイントは、MulmoClaude本体のNode.jsアプリとは完全に切り離したこと。proxy_pass は使わず、ただの静的HTMLファイル1枚を配信するだけの設定にしたので、名刺ページのアクセスがMulmoClaude本体の負荷に影響することはない。

中身は実際に普段使っている名刺の情報をそのまま移した。ボタンは2つだけに絞った。

• 「連絡先に保存」— クリックするとJSのBlobで .vcf ファイルをその場で生成し、スマホの連絡先追加シートを開く
• 「WhatsApp」— wa.me のクリック・トゥ・チャットのディープリンクを踏むだけ

最初はメール送信ボタンも用意していたが、後で削って情報行(mailto:リンク)だけに縮小した。ボタンは絞れるだけ絞った方が結局使いやすい。

色で少し迷った

配色は最初からネイビーで作っていたが、比較のために白黒版も一度作ってみた。並べて見て、結局ネイビーの方が良いという結論に落ち着き、白黒版は削除した。

地味なハマりどころ

公開直後、このアプリ自体に埋め込んだプレビュー用のiframe内でカードを確認したところ、メールアドレスの表示が記号だけの謎の文字列になっていた。最初は自分のミスかと疑ったが、正体はCloudflareの「メールアドレス難読化」機能(Scrape Shield)だった。ページ内のメールアドレスをスパム避けのため自動でエンコードして表示する仕組みで、通常のブラウザではJSが実際のアドレスに戻して表示するが、このアプリのプレビュー用iframe内ではそのデコード用スクリプトが動かなかった、というだけの話だった。ゾーン全体の設定なので個別にOFFにはせず、実際のブラウザでは問題なく表示されることを確認して終わりにした。

名前のドメインは、こう転がっていく

自分の名前をドメインにした瞬間から、こういう小さいサブドメインを次々に切れるようになった。この後もいくつか同じパターンで増やしていくことになる。

つづく。

自分で開けてしまっていた裏口

アクセス周りの設定を見直している最中、ドメインではなくLightsailのオリジンIPに直接アクセスしてみたところ、普通に開けてしまうことに気づいた。

これは、ドメイン経由のアクセスにはCloudflare Accessによる認証ゲートを設けていたのに、オリジンIPに直接アクセスすればそのゲートを完全にバイパスできてしまう、ということを意味していた。自分で用意した鍵が、裏口からは意味をなしていなかった、という状態だ。

同日中に ufw を導入し、inbound の80/443番ポートを Cloudflareの公開IPレンジ(https://www.cloudflare.com/ips-v4)からのみ許可、それ以外はデフォルトで拒否する設定にした。SSH(22番)は明示的に ufw allow OpenSSH で許可を先に入れてから有効化した(この順番を間違えると、ufw有効化と同時にSSH接続自体が失われるリスクがある)。適用後、ドメイン経由のアクセスは変わらず機能し、オリジンIP直接アクセスは接続不可になった。

2つ目のオリジンを追加したときの522エラー

このドメインの下に、MulmoClaude用の2つ目の入り口(mulmoclaude.taikiito.com)と、デジタル名刺用のサブドメイン(card.taikiito.com)を追加した。

2つ目の入り口のDNS(Aレコード)とCloudflare Accessのポリシーを設定した直後、アクセスするとCloudflareの 522エラー(オリジンへの接続タイムアウト) が出た。原因は、SSL/TLSの暗号化モードがゾーン(ドメイン)ごとに個別管理されていること。新しい taikiito.com ゾーンはデフォルトの Full モードになっていて、Cloudflareがオリジンの443番ポートへHTTPS接続を試みるが、nginx側は80番しか listen していなかった。既存のドメインと同じ Flexible モードに変更したら、即座に解消した。

続けて、SPF/DKIM/DMARCを設定してメールも作った

ドメインを持ったので、iCloud+の Custom Email Domain 機能を使って me@taikiito.com を作った。追加契約は不要で、案内された通りにDNSレコードを3つ登録するだけだった。

• MX: mx01.mail.icloud.com / mx02.mail.icloud.com
• SPF(TXT): v=spf1 include:icloud.com ~all
• DKIM(CNAME): sig1._domainkey → sig1.dkim.taikiito.com.at.icloudmailadmin.com

これらは「このメールは、なりすましではなく本当に自分のドメインから送られている」ことを証明する仕組みで、値をコピーして貼り付けるだけの単純作業だった。

それでも一部の宛先にだけ届かない

設定は正しく完了したはずだったが、試しに別のメールアドレス宛に送ってみたところ、そちらには届かなかった。バウンス(エラー返信)も一切なく、静かに消えているような状態だった。

念のため DMARC(TXT、v=DMARC1; p=none; rua=mailto:(レポート送付先))も追加し、外部のDNSチェッカーで正しく反映されていることも確認した。それでも届かない。原因は、SPF/DKIM/DMARCがすべて正しくても解決できない、ドメインの送信履歴(センダーレピュテーション)の問題だった。フィルタが厳しいメールサーバーほど、この影響を強く受けるらしい。

技術的に打てる手は尽きたので、これも時間が解決してくれるのを待つことにした。ドメインの「信頼」は、SPF/DKIM/DMARCを完璧に設定しても、技術設定だけではどうにもならない部分がある、というのは、ウェブアクセスとメールの両方で学んだことだった。

つづく。

自分の名前が、まだ空いていた

ある日、自分の名前をそのままドメインにできないか調べてみた。taikiito.com — 空いていた。特にひねりのない、名前をつなげただけのドメインが、まだ誰にも取られていなかった。

自分の名前をドメインにしている人たちのパターンをいくつか見比べてみた。苗字だけを使う人、下の名前と苗字をそのまま一続きにする人、ニックネームをブランド化して実体は別サイトにリダイレクトさせている人。ハッカー文化だと、本名と切り離した完全に別のハンドルを使うことも多い。

自分の名前を看板にするなら、変にひねらず、名前をそのまま素直に繋げる形が一番しっくりきた。苗字を先にする(itotaiki.com)か、ハイフンを入れる(taiki-ito.com)かも迷ったが、結局一番シンプルな taikiito.com に決めた。

今のうちに取っておくことにした理由

ドメインは取りたてのうちは、ネットワーク製品の自動フィルタなどから「作られたばかりで分類のない(uncategorized)ドメイン」として警戒されやすい、と聞いたことがあった。これを回避する方法は基本的になく、ドメインの年齢とアクセス・送信履歴が積み上がって「信頼できるカテゴリ」に分類されるのを待つしかないらしい。

だったら、本格的に使う予定が固まっていない今のうちに取っておいて、気長に信頼が育つのを待てばいい。そう考えて、Cloudflare Registrarで taikiito.com を取得した(実費のみ、WHOISプライバシー込み)。.jp や .net も保険で押さえておくか迷ったが、.com 一本で十分だと判断した。

自分の名前がそのままアドレスになる、というのは、想像していたよりも気分が良かった。

つづく。

何が起きていたか

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で守られている状態になった。次は、これを常時稼働のクラウドサーバーへ引っ越した話に続く。