前提

• 自分名義のドメイン(取得方法は各ドメインレジストラのサイトを参照。自分はCloudflare Registrarを使った)
• iCloud+の契約(月額サブスクリプション。iPhoneのバックアップ用など、何らかの理由ですでに契約していれば追加コストはかからない)
• ドメインのDNS(「taikiito.comというドメインは実際にはどのサーバーを指すか」をインターネット全体に教えるための住所録のような仕組み)を自分で編集できる状態(Cloudflareなど)

何をしたかったか

Gmailは便利だが、Googleに完全に預けているアカウントでもある。自分名義のドメインを取得したことで、自分のドメインでメールを受け取れる状態が整った。iCloud+はもともとiPhoneのバックアップ用に契約していたので、カスタムドメインのメールボックスを足しても容量を共有するだけで実質タダ。これなら移行のコストに見合うと判断した。

何に移すか: iCloud+ vs Fastmailで迷った話

自前ドメインでメールを使う場合、有名な選択肢としてFastmailがある。料金以外の軸(標準プロトコル対応、Apple以外の端末での使い勝手、エイリアスの上限、送信ドメインとしての評判、データの持ち出しやすさ)で比較検討した。

比較の途中で、自分の思い込みが一つ崩れた。iCloud MailはApple製品専用だとばかり思っていたが、実際には標準のIMAP/SMTP(メールの受信・送信をやり取りするための業界共通の通信規格。この2つに対応していれば、どのメールソフトからでも接続できる)にアプリ専用パスワードでアクセスすれば、Thunderbirdのような普通のメールクライアント(メールを読み書きするためのアプリ)からも使える。「ロックインされて出られなくなる」という一番の懸念はほぼ杞憂だった。すでに契約しているiCloud+の容量を共有できて実質無料な点も踏まえ、Fastmailへの乗り換えは見送り、iCloud+のカスタムドメイン機能を使うことにした。

Step 1: iCloud+でカスタムドメインを設定する

iPhoneの「設定」アプリ → 自分の名前(Apple ID) → iCloud → 「メール」→「カスタムメールドメイン」から設定を開始する(Mac版System Settingsからも同じ設定にたどり着ける)。ドメイン名(例: taikiito.com)を入力すると、iCloud側が必要なDNSレコードを画面に表示してくれるので、それを自分のドメインのDNS管理画面(Cloudflareなど)にそのまま追加する。実際に追加したレコードは以下の3種類だった。

iCloud+の設定ウィザードはこの3つだけを要求し、DMARC(後述、なりすまし対策をさらに強化するレコード)は必須ではなく任意なので、最初は追加しなくても動く。反映には数分〜数十分かかる。全て緑のチェックマークになれば、そのドメインでメールアドレス(自分の場合はme@taikiito.com)を作成できる。

Step 2: 会社のメール環境への到達を確認する

自分の場合、me@taikiito.comからGmailへは問題なく届いたが、会社のメール(Microsoft 365ベース)にはエラーも通知もなく、静かに届かないという問題が起きた。SPF/DKIMを見直しても直らなかったため、DMARC(TXTレコード)を追加した。

_dmarc.taikiito.com  TXT  "v=DMARC1; p=none; rua=mailto:<自分のメールアドレス>"

p=noneはまず様子見のモード(ポリシー違反があっても何もしない、レポートだけ受け取る)。これでも解決しなかったが、SPF/DKIM/DMARCの設定自体には問題が無いことが確認できたので、原因は取得したばかりのドメインが「送信履歴の無い新規ドメイン」として会社側のメールフィルタに警戒されていることだと判断し、時間経過で解決するのを待つ方針にした。実際、数日後には特に追加の変更をしないまま届くようになった。新しく取ったドメインでメールを送る場合、最初の数日〜1週間は主要な送信先に届かないことがあると見込んでおくとよい。

Step 3: なりすまし対策を強化する(SPF/DMARCの締め上げ)

ドメインの送信環境が安定してきたら、なりすまし対策を強める。最終的には以下の設定にした。

_dmarc.taikiito.com  TXT  "v=DMARC1; p=reject; rua=mailto:<自分のメールアドレス>"

p=none(様子見) → p=quarantine(怪しいメールを迷惑メール行き) → p=reject(なりすましメールを完全拒否)の順に段階を踏むのが一般的だが、自分の場合は送信経路がiCloudのみでSPF/DKIMがすでに正常に機能していたため、リスク評価をした上で段階を飛ばしてp=rejectまで一気に進めた。SPFも~all(該当しない送信元は「疑わしい」扱い)から-all(該当しない送信元は「完全に拒否」)へ強化した。

注意: p=rejectにすると、このドメインからのメールを送るときに使う経路(自分の場合はiCloudのみ)以外からは一切メールが届かなくなる。今後、別のメールサービスを追加で使う場合は、SPFレコードに新しい送信元をinclude:で追加し忘れないこと。

Step 4: Gmailからの引っ越しで3つハマったこと

1. Thunderbirdの「3層構造」に気づかず認証が通らなかった

WindowsでThunderbirdを使って移行作業をしようとしたところ、何度設定してもIMAP/SMTPの認証が通らなかった。原因は、iCloudのアカウント構造が3層になっていたこと。

• 表向きのApple IDサインイン用メールアドレス
• 実際のIMAP/SMTP認証に使う、真のiCloudアカウントアドレス(@icloud.com形式)
• 送受信に使う見た目のアドレス(カスタムドメインのエイリアス)

Thunderbirdの手動設定画面で、サーバー情報は以下のようにする。

ポイントはユーザー名欄で、一番上のApple IDのアドレスでも、送受信に使うカスタムドメインのアドレスでもなく、中間層の真のiCloudアカウントアドレスをフルで入力する必要がある。これはApple公式の設定手順のどこにも明記されておらず、自力で突き止めるまで何度も認証エラーに悩まされた。

2. 「完了」と判断したが、実は直近1〜2ヶ月分が抜けていた

Gmailの全メール(46,544件)をThunderbird経由でiCloud側へ移す自作スクリプトを作り、実行した。進捗ログを見ながら待ち、件数がおおよそ一致したことを確認して「移行完了」と判断した。

ところが後日、送信済みメールを見返していて、直近のメールが見当たらないことに気づいた。調べると、スクリプトは古いメールから新しいメールへ順番に処理する作りで、確認した時点では全体の約8割(37,362件/46,544件)までしか進んでおらず、直近1〜2ヶ月分がまだ移行されていない状態で「完了」と誤判断していたことが分かった。「件数がざっくり合っている」だけでは、移行完了の確認として不十分だったという教訓。

3. 復旧作業中に4,293件を誤って喪失、Google Takeoutの原本から復元

上記の見落としを受けて調査していたところ、さらに深刻な問題が見つかった。iCloud側で重複メールを整理する作業をしていた際、4,293件のメールを誤って消してしまっていた。加えて、作業の混乱の中でThunderbirdのローカルインポートフォルダ自体も誤って削除してしまい、復元の頼みの綱を一つ失った。

幸い、Gmailの公式エクスポート機能(Google Takeout、写真移行の記事で使ったのと同じ機能)で取得していた元データ(zipファイル、Gmailの全メールをmbox形式(メールをまとめて1つのファイルに保存する一般的な形式)で含む)がゴミ箱に残っていた。これは「Thunderbirdの中間コピー」ではなく「Gmail公式のエクスポート原本」なので、むしろ最も確実な復旧元だった。

Message-ID(メール1通ごとの一意な識別子、ヘッダーに必ず含まれる)単位で「Takeoutの原本」と「今iCloud側にあるメール」を突き合わせる復旧スクリプトを書き、欠落していたメールを復元した。最終的に、iCloudの1通あたりのサイズ上限を超えている(添付ファイルが大きい)ため原理的に復元不可能な2〜3件を除いて、ほぼ完全に復旧できた。

このとき得た一番の教訓: 大量データの移行を「件数がだいたい合っている」だけで完了と判断しない。Message-IDで突き合わせる方式が、確実に検証する唯一の方法だった。そしてGoogle Takeoutのような「移行元の公式エクスポート」は、移行作業が終わるまで絶対に消さないこと。

Step 5: 移行後の後片付け

Gmail側にme@taikiito.comへの自動転送(Forwarding、Gmailの設定 → 「メール転送とPOP/IMAP」から設定できる)を設定し、移行後にGmail宛へ届く新着メールも自動的に新しいアドレスへ流れるようにした。Google Takeoutのバックアップzipは、Backblaze B2とNextcloudの両方に保存。この3点(バックアップ済み・移行件数の整合性確認済み・新着メールの転送設定済み)を確認したうえで、Gmail側の整理に着手した。

整理は、GmailのAPI(他のプログラムからGmailを操作するための窓口)や管理画面からではなく、IMAP(前述の受信用の通信規格)を直接操作する自作スクリプトで、指定日より前の全メール(49,755件)をGmailの「ゴミ箱」フォルダへ移動する処理を実行した。Gmailのゴミ箱は30日後に自動で完全削除される仕組みなので、今のところ即座に完全削除したわけではなく、猶予期間を残した状態にしてある。この記事を書いている時点では、Gmail側のメールはゴミ箱送りまで完了しているが、Googleアカウント自体はまだ削除していない。しばらくme@taikiito.com側の運用が安定するのを見届けてから、次の判断(アカウント自体を消すかどうか)をするつもりでいる。

結果

me@taikiito.comが主メールとして定着し、日常的に使っている。途中でメールを実際に失いかけた一件は、この移行作業の中で一番肝を冷やした部分だったが、Google Takeoutで原本のバックアップを取っておいたことが最終的に救いになった。大量データを移す時は、移行先だけでなく移行元の生データも別途バックアップしておく、というのが今回一番強く実感した教訓だった。

更新履歴 — 2026-09-12: 初版 / 2026-09-13: DNSレコードの実際の設定値・Thunderbirdのサーバー設定項目を追記し、再現可能なレベルに書き直し

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

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つずつ辿るだけでは、記事が増えてきたときに不便になる。投稿のある年月を新しい順にリストアップし、クリックするとページ遷移なしでカレンダーがその月に切り替わる仕組みを、既存のカレンダーの状態管理に乗せる形で追加した。

つづく。

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以外の端末がメインになるとか、エイリアスを大量に使うようになったら、その時また考える。

つづく。

何が起きていたか

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時間動き続けている。