AIに自分をロールプレイさせたら人生一発逆転できるんじゃないかと思い始めて導入したObsidianとの同期に苦戦した話

AIに人生相談をしたことがあるだろうか。健康のこと、仕事のこと、お金のこと。ChatGPTやClaudeに聞けば、なんとまあ素晴らしい。人類のあらゆる知見を束ねた完全無欠のダイアモンドみたいな答えがちゃんと返ってくる。新時代である。

だが、どこか物足りない。回答を冷静に見てみると、当たり障りのない正論が並んでいるだけである。「食事はバランスが大事」「適度な運動を」「ちゃんと寝てる？」。

「いや、そうじゃなくて」と言いたくなる。そんな一般論は誰でも知っている。僕が知りたいのはその先にある。

だが、このような回答になる理由は単純で、AIは僕のことを何も知らないからだ。

AIに人生相談すると、なぜか物足りない

ChatGPTやClaudeなど、いまのAIチャットはLINEで友達に話しかける感覚で使える。質問すれば勝手に検索して考えて、それっぽい答えが返ってくる。便利になったものだ。

ただ、決定的な弱点が一つある。AIは「あなた自身」を知らない。あなたの過去も、性格も、これまでの生活も、キャリアも、恋愛も、大事にしている考えも知らない。だから人生相談をしても、教科書みたいな一般論しか返せない。初対面の人に的確な助言などできないのと同じだ。

逆に考えると、もしAIが僕の過去や価値観をぜんぶ知っていて、その上で「最近こういう研究が出ている」「いまこういうニュースがある」と最新の情報を調べて掛け合わせてくれたら——「あなたはこう動いたほうがいい、なぜなら」と、僕に固有の助言が返ってくるはずだ。これは、その場限りのチャットだけでは絶対に届かない場所だ。

自分を「第二の脳」に書き溜める

そこで使っているのがObsidianだ。Obsidianは早い話、メモ帳アプリだ。ここに僕は、自分に関することを片っぱしから書き溜めている。プロフィール、キャリア、健康、考えごと。文字どおり「第二の脳」をメモの中に作っているわけだ。

ただ問題は、書き溜めるという行為が続かないことだ。日記が三日坊主になるのと同じで、毎日キーボードに向かって今日を記録するのは、たいていの人にとって無理がある。

だから僕は最近「ボイスログ」という仕組みを作った。毎日、その日あったことを声で喋るだけ。書かない。喋るだけなら続く。しかも、今日を振り返る行為そのものが脳にいいらしい。喋った内容は文字に起こされ、メモの中にどんどん溜まっていく。Claude CodeのSkillを使って、以下のようなイメージで自動で作成されていく仕組みだ。

毎日しゃべる（ボイスログ）
      │
      ▼
今日の振り返りが記録される ──→ プロフィール / キャリア / 健康 …が日々更新
      │
      ▼
「自分とは何か」が最新化されていく
      │
      ▼
それを読んだAIが、僕に固有の助言を返せる

こうして「自分とは何か」が毎日アップデートされていく。それをAIに読ませれば、僕を知った上でのアドバイスが返ってくる。チャットだけでは到達できなかった場所に、これで近づける。

メモは、MacでもiPhoneでも見たい

第二の脳ができてくると欲が出る。家のMacで書いたものを、外出先のiPhoneでも見たい。当たり前の要求だ。

ところがObsidianの公式同期は有料のサブスクだ。僕はサブスクがあまり好きじゃない。毎月の支払いを小さく見せかけて、出費の痛みを麻痺させる悪魔の商品だからだ。資本主義も来るところまで来たものである。

かといって、GoogleドライブやOneDriveのような大手にぜんぶ預けるのも気が進まない。これは大手が悪いという話ではなく、預けた情報の主導権を相手に渡してしまうのが嫌なのだ。かつて「監視などしていない」と言っていたアメリカ政府が、実際にはしていた。スノーデンの一件だ。その事実が一度でも起きたなら、言葉だけでは安心しきれない、と多くの人が学んだ。加えて、ある日突然アカウントが凍結されて中身ごと使えなくなる、というリスクもある。

だから僕が欲しいのは、自分で鍵を握れて、暗号化して預けられる場所だ。GitHubのプライベートリポジトリに入れる手もあったが、個人情報の塊をあそこに置くのはさすがに怖い。結局Cloudflare R2というストレージに、暗号化して置くことにした。穴は似たようなものかもしれないが、少なくとも自分で鍵を持てるぶんマシだ、と自分を納得させている。

  Mac ──書き込み/読み取り──┐
                          ▼
                  Cloudflare R2（暗号化して保管）
                          ▲
iPhone ──読み取り（今回ここを制限したい）──┘

橋渡しをするのが「Remotely Save」というObsidianのプラグインだ。各端末がこのR2と読み書きして、差分を合わせてくれる。

同期は「どっちが本物か」問題である

ここで、同期というものの厄介さに触れておきたい。「2台で同じファイルを持つ」だけの話に聞こえるが、これはコンピュータサイエンスではけっこうな難題なのだ。

何が難しいのか。たとえば同じメモを、Macで少し直し、iPhoneでも別の箇所を直したとする。さて、どっちが「本物」か。両方が「自分こそ最新だ」と主張したとき、機械はどちらかを選んで、もう一方を上書きする。選択を間違えれば、片方の編集はこの世から消える。

Mac 版:    「A を編集した」  ┐
                            ├─→ どっちを残す？ 片方は上書きで消える
iPhone 版: 「B を編集した」  ┘

「最新のほうを残せばいい」と思うだろう。ところが、その「最新」を決めるのが難しい。最新かどうかは時刻で決まるが、MacとiPhoneの時計は微妙に食い違っている。ほんの一瞬のズレで、新しいほうを古いと誤判定してしまう。

世の中はこれをどう解いているのか。たとえばGoogleは、自社の巨大データベース「Spanner」のために、世界中のデータセンターにGPS受信機と原子時計を設置した。超高精度の時刻を全拠点で共有し、「どちらの書き込みが先か」を誤差ミリ秒の世界で確定させたのだ。要するに、時間そのものを金で買って殴り倒したわけだ。力こそパワーである。

僕にもGPS受信機や原子時計を設置する能力があったらよかったのだが、どうやら僕はGoogleではないらしい。

つまり、この「どっちを本物にするか」に気を配るしかない。今回の問題はそこだ。

iPhoneのメモが古い。だから読み取り専用にしたい

いま僕のiPhoneにあるメモは、だいぶ古い状態で止まっている。Macではせっせと更新してきたが、iPhone側は長らく放置していた。

この状態で何も考えずに双方向同期をかけると、どうなるか。iPhoneの古い内容がR2へ押し上げられ、Macで育てた最新の第二の脳を、数週間前の状態へ巻き戻してしまう。考えただけで血の気が引く。

危険な双方向同期:
   iPhone（古い）──押し上げ──▶ R2 ──▶ Mac（最新）が巻き戻る ✗

やりたい片方向（pull only）:
   R2（最新）──取り込みのみ──▶ iPhone     ※iPhoneは書き込まない ✓

だから今回やりたいことは一つだけ。iPhone側を「読み取り専用」にする。クラウドから受け取るだけ、絶対に書き込ませない。これさえできれば、古いiPhoneが本物を殺す事故は起きない。

「読み取り専用の鍵」を作ろうとした

ここで前提を一つ。クラウド上の保管庫に出入りするには、合言葉のような「鍵」が要る。そしてこの鍵には権限を設定できる。「読むことしかできない鍵」も、「読み書き両方できる鍵」も作れる。

僕が思いついたのは、いちばん硬い方法だった。iPhoneに渡す鍵を「読むだけの鍵」にすればいい。書き込み権限のない鍵なら、iPhoneがどうあがいても物理的に書き込めない。アプリのお願いごとに頼らず、根本から塞ぐ発想だ。

ところが、最初の鍵から作る場所を間違えた。Cloudflareには鍵を作る入口がいくつもあって、僕は汎用の入口に入ってしまった。そこから出てきたのは、Remotely Saveが求めているものとは別物だった。

汎用APIトークンの入口   → cfat_... という別形式のトークン（今回は使わない）
R2専用トークンの入口     → Access Key ID + Secret Access Key（これが正解）

名前は似ているのに、別物。気づくまで、出てくるはずのない鍵を探して画面をしばらくスクロールしていた。探し物が初めから存在しないと知るのは、なかなか間抜けな時間だ。

鍵は正しいのに、403だけが返ってくる

正しい入口で「読むだけの鍵」を作り直し、iPhoneのRemotely Saveに入れた。接続テストを押す。返ってきたのは 403 Forbidden。あんたにアクセスする権利はない、という意味のそっけない数字だ。

鍵が違うのか。作りたてで反映に時間がかかるのか。アプリの不具合か。画面の中で当て推量を続けても埒があかない。こういうときは、変数を一つずつ潰すに限る。

そこでMacのターミナルから、同じ鍵・同じ保管庫に直接アクセスしてみた。iPhoneアプリという要素を、いったん方程式から消すためだ。

AWS_ACCESS_KEY_ID=... \
AWS_SECRET_ACCESS_KEY=... \
aws s3 ls s3://my-bucket \
  --endpoint-url https://<account>.r2.cloudflarestorage.com \
  --region auto

ファイル一覧が、あっさり返ってきた。つまり鍵は死んでいない。少なくとも単体では、ちゃんと中身を読めている。

なのに、Remotely Saveに入れると403で弾かれる。鍵は生きているのに、このプラグインだけが受け取ってくれない。話がますます分からなくなった。

読み取り専用では、なぜか通らなかった

だめもとで、鍵を作り直した。今度は「読み書き両方できる鍵」にしてみる。読み取り専用へのこだわりを、いったん手放した。

すると、あっさり通った。接続テストも同期も、何ごともなかったように成功する。

結局、こういうことだった。Remotely Saveは、なぜか読み取り専用の鍵では動かない。読み書きできる鍵を渡して、初めて使える。理由は正直、最後まで分からなかった。おそらくプラグインが同期のたびに、削除を追跡するための小さな管理ファイルをクラウドへ書き込んでいて、読むだけの鍵ではその一手で詰まるのだろう——とは思う。だが確証はない。分からないものは、分からないと書いておく。

はっきりしたのは一つだけ。「書き込めない鍵」と、このアプリは相性が悪い。読み取り専用という入口は、ここでは閉じていた。

結局、鍵を縛る必要はなかった

ここで視点が変わった。そもそも僕は、何を守りたかったのか。「iPhoneがクラウドへ書き込んで、本物を上書きする」事故を防ぎたかっただけだ。鍵を読み取り専用にするのは、その一手段にすぎない。

そしてRemotely Saveには、同期の方向を選ぶ設定がある。「Incremental pull only（取り込みのみ）」。これを選べば、iPhoneはクラウドから受け取るだけで、自分からは一切書き込まない。

僕が固めようとしていた層:
  ┌─────────────────────────────┐
  │ アプリの設定（pull only）   │ ← 実はここ一つで足りた
  ├─────────────────────────────┤
  │ クラウドの鍵の権限          │ ← ここを必死に縛ろうとしていた
  └─────────────────────────────┘

アプリに「書かない」と宣言させれば、鍵の権限で縛る必要はそもそもなかった。いや、読み取り専用の鍵はそもそも動かなかったのだから、残された道は最初からこれしかなかったとも言える。どちらにせよ、僕は守る層を一つ間違えていた。一番下の鍵の層で固めようとして、その上のアプリの設定一つで済む話を、わざわざ難しくしていたのだ。

最終的な構成はあっけない。Macで使っている読み書き可能な鍵をそのままiPhoneにも入れ、Remotely Saveの同期方向を「pull only」にする。それだけで、iPhoneは受け取り専用になり、古い状態が本物を殺す事故は起きなくなった。

注意は一つ。この守りはアプリの設定、つまりソフトの約束で成り立っている。うっかり同期方向を双方向に戻せば、その瞬間からiPhoneはまた書き込めてしまう。だから「pull onlyから動かさない」ことだけは覚えておく。鍵で物理的に縛る硬さはないが、運用で十分守れる。

おわり😊