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

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

つづく。

きっかけ

中島聡さんのニュースレター経由で以前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.

つづく。

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つ切って、静的ページだけを置く

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

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

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

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

色で少し迷った

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

地味なハマりどころ

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

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

つづく。

Cloudflare Accessをバイパスできる抜け穴があった

アクセス周りの設定を見直している最中、ドメインではなく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つ目の入り口と、デジタル名刺用のサブドメインを追加した(どちらも実在のURLはここには書かない。前者はCloudflare Access越しとはいえサブドメイン名自体を晒したくないし、後者は名刺ページに連絡先が載っている)。

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がすべて正しくても解決できない、ドメインの送信履歴(センダーレピュテーション)の問題だった。フィルタが厳しいメールサーバーほど、この影響を強く受けるらしい。

技術的に打てる手は尽きたので、これは時間が解決してくれるのを待つことにした。

つづく。

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

ある日、自分の名前をそのままドメインにできないか調べてみた。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)に固定。毎時のスケジューラーチェック自体は軽い処理だけに留めるようにした。

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

つづく。

構成を決めるまで

自分のマシンから直接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で守られている状態になった。

つづく。