前提

以下がすでに用意できていることを前提にする。まだの場合は先に自分の「サーバー」を持つとはどういうことかを読んでほしい。

• 常時起動しているLinux環境(Docker Engineが使える状態)
• 自分名義のドメイン、およびCloudflare(無料プランで可)でそのドメインを管理していること
• Cloudflare Tunnel(cloudflaredというソフトを使い、自宅のルーターの設定を一切いじらずに自宅サーバーを安全にインターネット公開する仕組み)がすでに動いている状態。導入手順は自分の「サーバー」を持つとはどういうことかを参照

何をしたかったか

写真をImmichに移した(前の記事)のと同じ理由で、Google Driveに置きっぱなしにしていたファイルも自分の手元に戻したいと思った。写真ほど量は多くない(実質100〜150MB程度)が、契約書や身分証のコピーなど「人に預けたくないもの」が混ざっていたのが動機だった。

Step 1: Nextcloudを選び、全部は移さないと決めた

Google Driveの代わりになる自前ホスト型のソフトはいくつかある。今回は次の4つを比べた。

• Nextcloud — ファイル同期に加えて、連絡先・カレンダー・メモアプリなど周辺機能が豊富。後から機能を足しやすい。
• Seafile — ファイル同期に特化していて速いという評判だが、周辺機能はNextcloudほど無い。
• Syncthing — サーバーを介さず端末同士が直接同期する仕組み。管理はシンプルだが、Google Driveのような「どこからでもブラウザで見る」用途には向かない。
• Filestash — 既存のストレージ(自分のNASなど)にWeb UIを被せるツール。今回は土台のストレージ自体を新規に用意する必要があったので、ここでは選択肢から外れた。

最終的に、**拡張性(今後、連絡先やカレンダーも同じ場所に集約したくなる見込みがあった)**を決め手にNextcloudにした。実際にこの後、連絡先・カレンダーも同じNextcloudに移すことになったので、この判断は結果的に正しかった。

写真の時は「全部Immichに取り込む」という単純な方針にしたが、Google Driveは事情が違った。中身を確認すると、自分のファイルの他に、家族と共有しているフォルダが2つ(iPhoneの体組成計・血圧データを自動書き出しする仕組みと、ビザ手続き関連の共有フォルダ)混ざっていた。この2つは「相手(連携先アプリや家族)がGoogle前提で動いている」ため、無理にNextcloudへ移すと連携が壊れる。移行の効果(データ主権が増える度合い)と、移すコスト・壊れるリスクを天秤にかけて、この2つはGoogle側に残すと決めた。 残りの自分専用ファイル(契約書などのarchiveフォルダ)だけをNextcloudに移した。

Step 2: docker-composeでNextcloudを構築する

作業用フォルダを作り、docker-compose.ymlを用意する。

mkdir ~/nextcloud && cd ~/nextcloud

docker-compose.ymlの中身(Nextcloud本体appと、データを整理して保存しておくデータベースソフトdb〈MariaDB〉の2つのコンテナをセットで起動する構成):

services:
  db:
    image: mariadb:11
    restart: always
    volumes:
      - ./db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=<自分で決めた強力なパスワード>
      - MYSQL_PASSWORD=<自分で決めた強力なパスワード>
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud:latest
    restart: always
    ports:
      - 127.0.0.1:8081:80
    links:
      - db
    volumes:
      - ./data:/var/www/html
    environment:
      - MYSQL_PASSWORD=<自分で決めた強力なパスワード>
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db
      - NEXTCLOUD_ADMIN_USER=admin
      - NEXTCLOUD_ADMIN_PASSWORD=<自分で決めた強力なパスワード>
      - NEXTCLOUD_TRUSTED_DOMAINS=drive.example.com

portsを127.0.0.1:8081:80(自分のマシンの中からしかアクセスできない設定)にしているのがポイント。外部への公開はこのあとCloudflare Tunnel経由で行うので、Nextcloud自体を直接インターネットに晒す必要はない。NEXTCLOUD_TRUSTED_DOMAINSには、実際に使う自分のドメイン(例: drive.taikiito.com)を入れる。

起動する。

docker compose up -d
docker compose ps

app・dbの2つが起動していることを確認したら、http://localhost:8081にアクセスして管理者アカウント(NEXTCLOUD_ADMIN_USER/NEXTCLOUD_ADMIN_PASSWORDで指定した内容)でログインできることを確認する。

Nextcloudの管理者ユーザー名は一度決めると後から変更できないので、adminのような分かりやすい名前で最初から決めておくとよい。

Step 3: Cloudflare Tunnelで公開する

/etc/cloudflared/config.yml(Cloudflare Tunnelの設定ファイル)のingress(どのドメイン宛のアクセスを、サーバー内のどのポートに転送するかのルール一覧)に、Nextcloud用の行を追記する。

ingress:
  - hostname: drive.taikiito.com
    service: http://localhost:8081
  # ...他のサービスの行がここに続く...
  - service: http_status:404

注意点: service:行のインデント(行頭の空白)は他の行と正確に揃えること。ここが1マスでもずれるとYAML(設定ファイルの記述形式)の解析エラーになり、Cloudflare Tunnel全体が落ちて他のサービスまで巻き込んで止まる、という事故を実際に経験している。編集後はcloudflared tunnel ingress validateで文法チェックしてからsudo systemctl restart cloudflaredで反映するのが安全。

DNS側は、Cloudflareの管理画面(またはAPI)でdrive(サブドメイン部分)のCNAMEレコードを<トンネルID>.cfargotunnel.comに向ける。反映後、https://drive.taikiito.comでNextcloudのログイン画面が表示されれば成功。

Nextcloud特有の注意点: Nextcloud(内部でApacheというソフトを使っている)は、自分がHTTPS経由でアクセスされていることを正しく認識できないと、ログイン後に無限リダイレクトを起こすことがある。Cloudflare Tunnelは末端(サーバーとの接続)を暗号化しないHTTP接続で待ち受けるため、この設定が必要になる場合がある。症状が出た場合は、Nextcloudのconfig/config.phpに以下を追記して回避する。

'overwriteprotocol' => 'https',

Step 4: Macと同期する

ここからは、サーバーさえ用意できていれば誰でもできる部分。Google DriveにはMacの「Finder」(ファイル一覧の画面)に統合される専用アプリがあったが、Nextcloudにも同じような公式デスクトップアプリがある。これをインストールしてログインすると、Finder上にNextcloudのフォルダが表示され、Google Driveの時とほぼ同じ感覚でファイルを開いたり保存したりできる。同期は「全部」ではなくフォルダ単位で選べる。最初はNextcloudが用意するお試し用のサンプルフォルダ(Documents、Photos、Templatesなど)が並んでいたが、これは削除してよい。本物のデータが入っているのは、移行したarchiveフォルダだけだった。

Step 5: バックアップを設定する

「移した先が壊れたら意味がない」ので、移行作業そのものと同じくらいバックアップ体制を大事にしている。rclone(色々なオンラインストレージをコマンドラインから操作できるツール)を使い、Backblaze B2という安価なオンラインストレージへ、Nextcloudのデータを毎日自動でコピーする設定にした。

# データベースのダンプ
docker compose -f ~/nextcloud/docker-compose.yml exec -T db \
  mysqldump -u nextcloud -p<パスワード> nextcloud | gzip > /tmp/nextcloud-db.sql.gz

# ファイル本体の同期
sudo rclone --config /home/ito-t/.config/rclone/rclone.conf sync \
  ~/nextcloud/data "$B2_REMOTE/nextcloud/data"

これを日次のcron(定期実行の仕組み)に登録しておけば、毎晩自動でバックアップが取られる。

つまづいた所・積み残し

9.68GBの謎: 作業の途中、Googleのストレージ画面で「Driveが9.68GB使用中」と表示されているのに気づいた。しかし実際に移行した中身は100〜150MB程度しかない。90倍以上の差があり、計算が全く合わなかった。調べてみると、以前どこかのタイミングで大きなファイルを削除した際、ゴミ箱を空にしていなかった可能性が濃厚だという所まで辿り着いた。Googleドライブのゴミ箱は自動では空にならず、手動で「ゴミ箱を空にする」を押さない限り容量を圧迫し続ける。ここは正直に書いておくと、この謎は最終的に自分の手では確認しきれず、保留のままになっている。

家族との共有: Google Driveで便利だったことの一つに、家族とのフォルダ共有がある。Nextcloudでも同じことは可能で、家族専用アカウントを作って権限を細かく設定する方法と、アカウント不要のリンク共有で手軽に済ませる方法の2通りがある。これは記事執筆時点でまだどちらにするか決めきれていない、現在進行系の課題として正直に残しておく。

結果

自分専用のファイルはNextcloud経由でMacからGoogle Driveと変わらない感覚で使えるようになった。家族共有フォルダ2つは「無理に移さない」という判断のままGoogleに残っており、これはこれで納得している状態。

次は、同じNextcloudに連絡先とカレンダーも集約した話。→ 連絡先とカレンダーをiCloud・GoogleからNextcloudに移す

更新履歴 — 2026-09-12: 初版 / 2026-09-13: docker-compose設定・Cloudflare Tunnel公開手順・バックアップコマンドを追記し、再現可能なレベルに書き直し

前提

すでにNextcloudが動いていることを前提にする。まだの場合は先にファイルをGoogle DriveからNextcloudに移すを読んでほしい。

何をしたかったか

連絡先はiCloudとGoogleの両方に分散していた。カレンダーは個人の予定をGoogleカレンダーで管理していた。どちらも「今後もGoogle/Appleに預け続けるほどの理由がない」データなので、ファイルや写真と同じ流れでNextcloudに集約することにした。同期方式は特定の会社に縛られない業界標準の規格(CardDAV・CalDAV)なので、Mac標準の「連絡先」「カレンダー」アプリやiPhoneからもそのまま繋げられる。

Step 1: Nextcloudのアプリパスワードを発行する

まず、CardDAV/CalDAV経由でアクセスするための専用パスワードを発行する。Nextcloud本体のログインパスワードをそのまま外部アプリに渡すのは避け、用途ごとに無効化できる「アプリパスワード」を使うのが基本。

Nextcloudの画面右上のアイコン → 個人設定(Personal settings) → セキュリティ(Security) → 「新しいアプリパスワードを作成」から、名前(例: contacts-migration)を付けて発行する。表示されたパスワードは、この画面を閉じると二度と表示されないので、一時的にメモしておく。

Step 2: 連絡先をエクスポートする(633件)

Google連絡先553件・iCloud連絡先81件を、それぞれvCard形式(連絡先データの標準的なファイル形式、拡張子.vcf)で書き出す。

• Google連絡先: contacts.google.com → 左メニュー「エクスポート」→ vCard形式を選択
• iCloud連絡先: icloud.com → 連絡先 → 全て選択 → 右下の歯車アイコン → 「vCardを書き出す」

重複1件を除いた633件を、まとめた1つの.vcfファイルにしておく(vCard形式は複数の連絡先を1ファイルに連結できる)。

Step 3: CardDAVへ直接PUTする

Nextcloud Web UI(ブラウザ上の管理画面)の「連絡先をインポート」機能も試したが、件数が多いと不安定だったため、CardDAVのエンドポイント(データの送り先URL)へ、1件ずつPUT(データをサーバーへ送り込む処理)する方式に切り替えた。

まず、まとめた.vcfファイルを連絡先1件ずつのファイルに分割する(Pythonのvobjectライブラリや、csplitのようなテキスト分割コマンドで、BEGIN:VCARD〜END:VCARDの区切りごとに切り出す)。分割できたら、1件ずつ以下のようにアップロードする。

curl -u "admin:<Step1のアプリパスワード>" \
  -X PUT \
  --data-binary @contact-001.vcf \
  -H "Content-Type: text/vcard; charset=utf-8" \
  "https://drive.taikiito.com/remote.php/dav/addressbooks/users/admin/contacts/contact-001.vcf"

これを633件分、シェルスクリプトのforループなどで繰り返す。1件ずつリソースとしてサーバーに送り込む地道なやり方だが、Web UIのインポートより確実に反映される。

Step 4: Macで連絡先を同期する

Macの「連絡先」アプリ → 環境設定 → アカウント → 「アカウントを追加」→「他のアカウント」→「CardDAVアカウントを追加」。

ここでハマったポイントがある。macOSは通常、サーバーアドレスを短く入力するだけで.well-known/carddavという決まったパスへ自動でアクセスし、正しいCardDAVのURLへリダイレクトしてくれる仕組みになっている。ところが、Cloudflare経由のリダイレクト処理の影響で、この自動検出がうまく機能しなかった。

解決策: サーバーアドレスの欄に、自動検出用の短いURL(drive.taikiito.com)ではなく、以下のフルパスを直接入力する。

https://drive.taikiito.com/remote.php/dav/principals/users/admin/

ユーザー名はadmin(Nextcloudのユーザー名)、パスワードはStep 1で発行したアプリパスワードを使う。iPhoneの「連絡先」アプリでも同じ設定項目がある。

Step 5: カレンダーの移行(232件)

個人用のGoogleカレンダーに入っていた予定(2019〜2029年、232件)をNextcloud Calendarの「Personal」カレンダーへ移す。

まずcalendar.google.comの設定画面から、対象のカレンダーを.icsファイル(カレンダーの予定データをやり取りするための標準的なファイル形式)としてエクスポートする。

最初はNextcloud Web UIの「カレンダーをインポート」機能で.icsファイルをそのまま読み込ませようとしたが、「could not be parsed」(うまく読み取れなかった、というエラーメッセージ)というエラーで通らなかった。.icsファイルの行折り返し(RFC5545というカレンダーデータの技術仕様で決められたルール)を手直ししても解決しなかったため、連絡先と同じくCalDAVへ直接PUTする方式に切り替えた。

.icsファイルを1イベントずつに分割し(BEGIN:VEVENT〜END:VEVENTの区切りで切り出す)、以下のようにアップロードする。

curl -u "admin:<アプリパスワード>" \
  -X PUT \
  --data-binary @event-001.ics \
  -H "Content-Type: text/calendar; charset=utf-8" \
  "https://drive.taikiito.com/remote.php/dav/calendars/users/admin/personal/event-001.ics"

232件全てこの方式でアップロードしたところ、全て成功した。反映を確認したうえで、Google Calendar側の元データは削除した。ただし、妻と共有しているカレンダーはGoogleに残す判断にした(相手がGoogle前提で使っているため)。ファイル移行の時の「移す理由が移さない理由に勝つものだけ移す」という基準を、ここでも踏襲した形だ。

つまづいた所

1. Web UIの一括インポートは大量データに弱い: 連絡先・カレンダーともに、NextcloudのWeb UIインポート機能は件数が多いと信頼できなかった。少数なら問題ないと思うが、数百件規模ならCalDAV/CardDAVへ直接PUTする方式を最初から選んだ方が早い、というのが今回の教訓。

2. .well-known/carddavのリダイレクトが失敗する: 上記Step 4の通り、自動検出をあきらめてフルパスを直接指定することで解決した。同じ症状はCalDAV側(.well-known/caldav)でも起こりうるので、うまくいかない場合は同じ対処(フルパス直接指定)を試すとよい。

積み残しもある。祖父の命日のような毎年繰り返す予定は、Google側で表示されていた2025〜2029年分のインスタンスだけを削除しており、繰り返しルールそのもの(マスター)は消していない。2030年以降にまた自動で出現する可能性があるため、気になったら改めてGoogle Calendar側で対応する必要がある。また、Gmailにはフライトやレストランの予約確認メールを自動でGoogleカレンダーに追加してくれる機能があるが、これは自前のメール+Nextcloudカレンダーの組み合わせには存在しない、Google独自の仕組みで、メール・カレンダーのどちらか片方だけ移しても再現できない。同等の仕組みを自作するなら別プロジェクトになるので、今回は見送っている。

結果

連絡先633件・カレンダー232件、どちらも移行完了。MacとiPhoneから、Google/iCloudの時とほぼ変わらない感覚で使えている。大量データの移行はWeb UIのインポートを過信せず、CalDAV/CardDAVへの直接PUTを検討するとよい、というのが一番の学びだった。

次は、メモをJoplinに移そうとして、結局全部は移さなかった話。→ メモをiCloud NotesからJoplinに移す

更新履歴 — 2026-09-12: 初版 / 2026-09-13: アプリパスワードの発行手順・実際のcurl PUTコマンドを追記し、再現可能なレベルに書き直し

先に正直に書くと、Nextcloudで困っていたことは何も無かった。故障の修理ではなく、作りを良くするための工事だ。だから得たものと同じ分量で、失ったものを書く。

前提

• 常時起動しているLinux環境とDocker(ソフトを1つずつ箱に入れて動かす仕組み)が使えること。土台は自分の「サーバー」を持つとはどういうことか
• すでにNextcloudの連絡先・カレンダーを使っている状態(前の記事)
• CalDAV(予定表をやりとりするための標準的な通信規約)・CardDAV(住所録用の同じもの)の名前だけ知っていれば十分

動かした理由は「規模が不釣り合い」の一点

移す前に、Nextcloud側の中身を?exportで実測した。住所録575件、予定表236件、そして空の予定表が2つ(片方はiPhoneのリマインダーが勝手に作ったもの)。

🔴 前の記事に書いた「連絡先633件・予定232件」は誤りだった。移した件数は、移した日に書き留めただけでは当てにならない。

実データの合計は約230KB。テキストファイル1枚に収まる量だ。これに対してNextcloudはPHPで書かれた大きな母屋にデータベースまで抱えている。やっている仕事に対して仕掛けが大きすぎる、というのが唯一の動機だった。

Radicaleは何で、何ではないか

RadicaleはCalDAV/CardDAVだけを話す小さなサーバー。データベースを持たず、予定1件が.icsファイル1枚、連絡先1件が.vcfファイル1枚として、普通のフォルダにただ並んでいるだけ。

やっているのは「フォルダのテキストファイルを、CalDAVという会話の形に翻訳して端末に見せる」中継だけだ。Appleのカレンダーアプリには「このフォルダを見ろ」という設定が存在せず、CalDAVでしか話せないので、この翻訳役が必要になる。あとは各予定にetag(版番号)を付けて差分と衝突を管理するだけ。

何ではないかのほうが重要だと思う。

• 使えるWeb画面が無い。ブラウザで開いても予定を見る画面は出てこない。どうしても画面が欲しければ、CalDAVを外から繋げられるメールサービス(自分はFastmail)を窓口にする手はある。
• 共有リンクも共有のUIも無い。「この予定表をあの人に見せる」をボタンで作れない。
• ファイル置き場ではない。PDFもWordも置けない。契約書の保管はNextcloudに残した。
• 何でも1箇所にある便利さを捨てる。サーバーが1つ増え、端末のアカウントも1つ増える。

代わりに得たのは、速さ、攻撃される面の小ささ(PHPの大きな母屋とデータベースが無くなる)、そしてバックアップがフォルダのコピーで済み、ソフトが壊れても中身はテキストで読めること。この3つのために上の4つを捨てた。判断は人によって逆でいい。

立てて流し込む

構成はdocker composeで1つ、tomsquest/docker-radicale(Radicale 3.8.1)。127.0.0.1にだけ口を開け、外から直接は触れないようにした。認証はhtpasswd(ユーザー名とパスワードの対応表ファイル)だけ。設定の書き方は版で変わるので公式ドキュメントのConfigurationの項を見てほしい。

移行前にNextcloudから控えを取る。

# 住所録
curl -u "<ユーザー名>:<アプリパスワード>" \
  "https://drive.example.com/remote.php/dav/addressbooks/users/<ユーザー名>/contacts?export"
# 予定表
curl -u "<ユーザー名>:<アプリパスワード>" \
  "https://drive.example.com/remote.php/dav/calendars/<ユーザー名>/<予定表名>?export"

入れ物の一覧は同じURLに-X PROPFIND -H "Depth: 1"を付けて取る。流し込みはスクリプトを書いた。設計で効いた点が2つ。

• ファイル名をデータの中のUID(1件ごとの識別子)にする。何度流し直しても同じファイルを上書きするだけで、件数が増えない。
• 繰り返す予定の「例外日」(毎週の予定のうち1回だけ時間をずらした分)は同じUIDを持つので、1ファイルにまとめる。別ファイルにすると予定が二重になる。

結果は575件・236件でNextcloud側と完全一致、失敗0件。

🔴 立てるときに踏んだ穴

• コンテナの中のRadicaleは自分と違うユーザーで動く。自分の場合は数字のユーザーID 2999だった。パスワード表をrootの持ち物にしたままだとPermission deniedで起動しない。そのIDに所有者を変え、読み取りだけ許すのが正解。
• 🔴 「正常な応答コード」を3回続けて読み違えた。トップページのGETは302(転送)が正常で401ではない。予定表フォルダのGETは認証が通っていても403が仕様どおりで、壊れていない。正しい確認はPROPFINDを投げて207が返ることで、件数もこれで数える。

端末の繋ぎ直しに「移行」は無い

ここが一番地味で、一番時間がかかる。サーバー間でデータを移しても、端末のアカウント設定は1台も自動で付いてこない。全部手で繋ぎ直す。 Apple(Mac・iPhone)で詰まる点は1つだけで、はっきりしている。

• 🔴 アカウント種別の「自動(Automatic)」では繋がらない。Appleは.well-known/caldavという決まった入口で「本当の場所はどこ?」と尋ねるが、Radicaleはここでトップページへ転送するだけで場所を教えない。
• 必ず「手動(Manual)」を選ぶ。サーバーアドレスはホスト名(cal.example.com)、駄目なら自分のフォルダまでのフルパス(https://cal.example.com/<ユーザー名>/)を直接入れる。前の記事と同じ系統で、自動検出は当てにしない。

AndroidとThunderbirdは今回つないでいないので手順を書かない。確かなのは、Androidの標準カレンダーにはCalDAVアカウントを足す項目が無く、別途CalDAVクライアントのアプリを入れて端末のカレンダーに同期させる形になること、ThunderbirdはCalDAVに標準対応していることだけだ。

並行期間(両方に同じデータがある状態)の事故防止で効いたこと。

• 古い側の表示名を「OLD(使わない)」に変える。同じ名前が2つ並ぶと、どちらを編集しているか分からなくなる。
• 端末側で新規作成先の既定のカレンダーを新しい方に変える(Macは Calendar > Settings > General、iPhoneは 設定 > アプリ > カレンダー)。ここを変えないと、自分で作った予定だけ古い方に入り続ける。
• 古い側を消すのは、①手元に控えがある②新しい側の件数が一致している、の両方を実測してから。
• 🔴 Nextcloudの予定表は204が返っても消えていない。ごみ箱行き(論理削除)になり、一覧に出続けて中身も読める。完全に消すには削除要求にX-NC-CalDAV-No-Trashbin: 1を付ける。住所録はごみ箱が無く一発で消えるので、挙動が揃っていない。

🔴 Radicaleは重いREPORT問い合わせを同時に受けられない

Radicaleを選ぶ前に知っておくべき制約で、しかもほとんどどこにも書かれていない。自分は後から実測で踏んだ。

REPORTは、カレンダーアプリが「この日からこの日までに何が入っているか教えて」と尋ねるCalDAVの問い合わせだ。Radicaleはこれを受けるとフォルダの中の全ファイルを毎回走査する。繰り返す予定は1ファイルにルールが1行入っているだけなので、「表示を1年先までに絞る」といった対策は効かない。遅さを決めているのは問い合わせの範囲ではなく、フォルダ内のファイル総数だ。

予定表が現在2,626件まで増えた結果、1回の範囲問い合わせに約4.7秒かかる。これ自体は待てる。問題は同時に投げたときだった。

• 事前読み込みを直列3本から並列5本に変えたら、30秒で5本とも通信切れになり、取れた予定は0件になった。
• 直列に戻したら、5期間228件が23.3秒で全部成功した(1本あたり約4.7秒)。

つまりRadicaleは重いREPORTを並べて投げられると、速くなるどころか全部落ちる。「カレンダーアプリを2つ同時に開く」「月を素早く切り替える」「複数の範囲を先読みする自作ツール」のどれでも起こり得る。付き合い方は、どれも「並列化しない」方向になる。

1. 1本ずつ流す列を作る。手前のサーバーに順番待ちの列を1本入れ、範囲問い合わせは必ず直列で流す。
2. 同じ範囲の同時要求は1本に相乗りさせる。2箇所から同じ月を聞かれたら投げるのは1回で、答えを2箇所に配る。画面の操作から来た要求だけ列の先頭に割り込ませると、裏の先読みが詰まっていても人は待たされない。
3. 一度取ったら捨てない。1件保存・削除するたびに全期間のキャッシュを丸ごと捨てて再取得していたのが最悪の形だった。変わった1件だけを手元で差し替えるようにしたら、保存のたびの5秒が消えた。
4. 範囲は広めに取って一度だけ聞く。細かく刻んで何度も聞くほうが遅い。

⭐ 一般則。相手が1本ずつしか捌けない所へ、並べて投げてはいけない。速くする手は並列化ではなく、①同じものを二度聞かない ②要るものだけ聞く、の2つしかない。

時間帯は最初に片付ける

2人で共有するカレンダーを、互いに別の国にいる状態で使っている。時間帯(タイムゾーン)の扱いは後から足す機能ではなく、土台だった。救われたのは、保存の形が最初から正しかったことだ。.icsの中では開始時刻がDTSTART;TZID=Asia/Singapore:...のように**「どの地域の時計で何時か」の形で書かれている**ので、絶対の時刻として一意に決まる。Apple純正のカレンダーはこれを読む側の端末の時間帯で出し直してくれる。標準形式に素直に保存されていれば、時間帯は自動で解決する。 壊れたのは自作の画面のほうで、そこから学んだのは次の3つ。

• 変換は入口と出口の2箇所だけでやる。画面に出す直前と、入力を受け取った直後。途中の計算に混ぜると、どこが変換済みか分からなくなって必ず二重変換が起きる。
• 「いまどの時間帯で見ているか」を常に画面に出す。Google・Apple・Thunderbirdのどれもこうしている。あとから読まれる文章に時刻を書くときも、必ず時間帯を添える(保存された文は読む人の時間帯に書き直せない)。
• 時刻の変換は、画面で確かめる前に机上で全パターン流す。夏時間の切り替わりの前後、30分ずれる地域、日付をまたぐ西側の地域は、実機を1件ずつ見ても踏めない。

バックアップは単純になった

データが素のファイルになったので、バックアップはフォルダを同期するだけになった。既存の日次スクリプトに2行足して終わりで、初回送信は1,035ファイル・379KiBで32秒。ただし消されても戻せる形にしておくことは、データが素のファイルになっても別途必要で、そこは変わらない(バックアップを「消されても戻せる」形にする)。

結果

575件・236件の移行は失敗0で完了し、MacとiPhoneから繋がっている。サーバー上にあるのは1,000枚ほどのテキストファイルで、catで開けば中身が読める。

ファイル置き場のNextcloudは据え置いた。素のファイルを普通のフォルダ構造で保存しているという一点では、調べた移行先候補よりNextcloudのほうが上だったからだ。目的が「データを読める形に保つ」なのに、手段がそこを後退させるなら却下する。

更新履歴 — 2026-10-05: 初版