Claude Code on the Web でリモートトリガーが ~/.claude/memory を読めない — Calendar reminder に切り替えた実体験

「RemoteTrigger で memory を毎週自動 sync したい」と思ったことはありませんか。

Claude Code on the Web を使い始めたとき、筆者も同じことを考えました。Obsidian Vault の更新を週 1 で自動反映させる routine を組もうとして——制約の壁に当たりました。2026-05-19 の実体験です。

結論：RemoteTrigger から ~/.claude/memory には触れない

単刀直入に言います。

RemoteTrigger routine は sources で指定した git repository しか参照できません。 ~/.claude/projects/ 配下の memory ファイルは環境外であり、routine から読み書きすることは現時点では不可能です。

この制約を知らずに memory-weekly-sync routine を設計すると、詰まります。筆者は詰まりました。

何をしようとしたか

筆者の Claude Code 環境では ~/.claude/projects/ に 30 本以上の memory ファイルがあります。weekly の sync routine を組んで、「月曜 09:00 JST に memory を最新化 → 週の作業をフレッシュな状態で開始」という流れを自動化したかったのです。

構想としては自然です。実際に Claude Code on the Web の RemoteTrigger を使えば、指定日時に自動でセッションを起動し、repository を checkout して何かを実行できます。

問題は「repository を checkout する」という部分にあります。

制約の正体

RemoteTrigger の動作モデルを整理すると以下のとおりです。

参照できるもの	参照できないもの
sources に指定した git repository	~/.claude/projects/ の memory
repository 内の任意のファイル	ローカルマシンのホームディレクトリ
Supabase MCP 等の外部サービス	ローカル環境変数 / キーチェーン

RemoteTrigger が起動するのはクラウド上の隔離コンテナです。ローカルの ~/.claude/ はそのコンテナから見えません。

試みた回避策と却下理由

symlink を張る

「git repository 内に ~/.claude/projects/ への symlink を張れば読めるのでは」と思いました。

却下理由は 2 つ：

1. git tracked 境界が壊れる — symlink 先がリポジトリ外なので git add が予期せぬパスを追跡する可能性がある
2. Vercel deploy 巻き込みリスク — masatoman.net は Vercel でデプロイしており、git の変更がそのままデプロイトリガーになる。memory ファイルが誤って本番に乗る可能性を排除できない

採用した判断：Calendar reminder + 手動実行

結論として採用したのは Calendar reminder + 手動 /sync-strategy 実行 です。

• 毎週日曜 21:00 JST に Calendar リマインダーを設定
• リマインダーが来たら手動で Claude Code セッションを開いて /sync-strategy を実行
• 所要時間は週 1 × 30 分以下

「自動化できないなら意味がない」と思うかもしれません。ただし、この判断には根拠があります。

週 1 × 30 分以下の作業は、自動化の準備コスト（不安定リスクの排除・テスト工数）より手動のほうが総コストが低い。

自動化が有効なのは「人間が毎日やらないといけない反復作業」か「時間精度が秒〜分単位で必要な処理」です。週 1 の memory sync は後者ではありません。

Obsidian 自動育成でも同じ制約に当たった

同日、Obsidian Vault の自動育成も検討していました。こちらも RemoteTrigger ベースで設計しようとしましたが、同様の制約が発生しました。

結果として実装したのは以下の段階構成です。

• Phase 1 (即実装): tooling-update-watch routine — 週 1 月曜 09:00 JST、git repo 内の情報をもとに Claude Code / Obsidian の最新情報を収集
• Phase 2 (即実装): Memory health check — Calendar reminder、週 1 日曜 21:00 JST で手動トリガー
• Phase 3-A (即実装): memory-change-detector Stop hook — ローカルセッション終了時に memory の変化を検出

Phase 3-B（PostToolUse hook）と Phase 3-C（UserPromptSubmit inject）は 2〜4 週の運用後に判断します。理由は同じで、制約が見えていない段階で全部入れると詰まるからです。

判断軸：RemoteTrigger を選ぶ基準

RemoteTrigger が有効なユースケースと、向かないユースケースを整理します。

RemoteTrigger が有効

• Supabase DB の定期集計・INSERT（MCP 経由で外部サービスにアクセス可能）
• git repository 内のファイルを読み書きして push する処理（記事生成、lint、レポート）
• 特定時刻のスケジュール実行（毎日 02:00 JST に記事を生成するなど）

RemoteTrigger が向かない

• ~/.claude/ 配下の memory や settings への読み書き
• ローカル環境でしか動かないスクリプト（launchd、ローカル DB、Voice Memos など）
• ローカル認証情報（keychain、.env ファイルなど）を必要とする処理

この区分を最初から持っていれば、筆者の詰まり 30 分は節約できました。

で、どう稼ぐ？

この制約の理解は直接の収益につながるというより、自動化設計の精度を上げることに効きます。

Supabase + Next.js + Claude Code で個人開発を進めている場合、RemoteTrigger は「外部サービスへのアクセス」と「git repository 操作」に限定して使うのが最もリスクが低い。

ローカル memory の自動化は Calendar reminder + Stop hook の組み合わせで補完する。これが現時点の最適解です。

RemoteTrigger × Supabase MCP の組み合わせで何ができるかは、Claude Code Labs EP05（リモートサーバー運用術）でより詳しく扱っています。

---