Claude Codeを複数デバイスで使うようになってから、じわじわ困り始めた。
AIはセッションが終わると全部忘れる。それ自体はわかっていた。
でも頭でわかっていることと、毎日体験することは別で、気になる場面が積み重なっていった。
- Macで昨日2時間かけて「これはダメだ」と結論を出した実装を、翌日WindowsのAIがまた提案してくる
- 「なぜこの設計にしたか」という判断の経緯が、セッションをまたぐと消える
- MacのAIがWindowsのAIに何か伝えようとすると、自分がコピペして間に入る羽目になる
特に3つ目が気になった。
AIに指示を出しているはずが、いつの間にか自分がAIとAIの間のメッセンジャーになっている。
周りに聞いて、調べてみた
同じような使い方をしているAIヘビーユーザーに聞いてみたが、「セッション終わったらメモ残してる」程度の人はいても、複数インスタンス間を自動で連携させている人には出会えなかった。
世界の実装を調べてみると、セッションログ系のツールはそれなりにあった。
GhostやClaude-mem、handoffなど。日本のZenn・Qiitaにもhooksで引き継ぎファイルを作る記事がいくつかあった。
「あるじゃないか」と思って読み進めると、どれも「記録するためのログ」だった。
セッションの内容を残しておくところまではできている。ただ、自分が困っていた部分には届いていなかった。
- なぜその実装を選んだかという判断の経緯が残らない
- 試してダメだった案が記録されないから、次のAIがまた同じことを提案する
- 複数デバイス間の連携は、どのツールも手動が前提
「記録するためのログ」と「後から別のAIが続きから始めるためのログ」は、目的がまったく違う。
そこに気づいたとき、自分で作るしかないと判断した。
どうやって作ったか
プログラミングの知識はHTMLが少し書ける程度だ。
シェルスクリプトもPythonも、書いてあるものを読めばわかる程度で、ゼロから書けるわけじゃない。
それでも作れた理由は、コードより先に「何をどういう順番でやるか」の構造をイメージできたからだと思っている。
「セッションが終わったら自動でファイルに書く」「gitで同期する」「次の起動時に読み込む」——
この流れをClaude Codeに伝えて、出てきたものを動かして、おかしければ「ここが違う、なぜか」を一緒に考える。
このサイクルをひたすら回した。いわゆるバイブコーディングだ。
ひととおり形になったところで、Claude Codeが書いたコードをOpenAIのCodexにレビューさせた。
作った本人（AI）とは別の目で見てもらうことで、気づかなかった問題がいくつか出てきた。
人間のコードレビューと同じ発想をAIでやった形だ。
システムの仕組み
全体の流れ
AIとの会話が始まると、このシステムが自動で「今日の引き継ぎノート」を作る。
会話が終わるとAIがそのノートに作業内容を書き込み、gitで別のデバイスへ自動送信する。
次にどこかのデバイスでAIを起動すると、そのノートを自動で読み込んで「続き」から始まる。
ユーザーは普段通りAIを使うだけでいい。
セッション開始 → 前回のログを自動読み込み・引き継ぎノートを自動作成
↓
普通に作業
↓
セッション終了 → AIがノートに記入 → gitで他デバイスへ自動送信
ファイルの構成
ログ保存フォルダ/
├── 2026-05-14_1000.md ← 今日の引き継ぎノート
├── shared/
│ └── context.md ← 全デバイス共有の現在状態
└── full/
└── 2026-05-14.log ← AIの全発言を自動記録する詳細ログ
引き継ぎノートの実例
実際のノートはこんな中身になっている。
# セッションログ 2026-05-14 10:00
## 🔴 概要 SHORT（3行以内）
ログ自動記録の仕組みを完成させた。
ダッシュボードのバグ（正規表現の問題）を修正した。
次はWindowsデバイスへの展開。
## やったこと MIDDLE
- session_log.sh を修正。セッション終了時に自動でgit pushするように変更。
- ダッシュボードのSHORT抽出バグを修正。
→ 原因：正規表現の `.` が改行をまたいでしまっていた。
→ 対策：`[^\n]` に変更して解決。
### 却下した案
- GitHub Pagesでダッシュボードを公開する案
→ ログの中身が全世界に公開されてしまうため保留。
## 次のアクション
- Windowsデバイスにも同じスクリプトを展開する
ログに何を書くか——ここが一番大事
このシステムを作るうえで一番悩んだのがここだった。
たどり着いた基準は「後から別のAIインスタンスがこのログだけを読んで、続きから作業を再開できるか」というものだ。
この問いを基準にすると、書くべき内容が自然に決まる。
必ず書くこと
却下した案とその理由
これが一番効いた。
「Dockerを試したがダメだった、理由は開発環境にDockerが入っていないユーザーが多いから」まで書く。
理由がないと次のAIが同じ提案を繰り返す。
なぜその方法を選んだか
「Aという方法でやった」だけでなく「BとCも検討したがAにした、理由は〜」まで書く。
書いておかないと次のAIが「BやCの方が良くないですか？」と蒸し返してくる。
あとは発見した具体的な事実——「このフォルダのパスは /home/user/logs/ だった」「このコマンドは管理者権限が必要だった」など。次回また調べ直す手間が省ける。
未解決事項は「後日対応」だけでなく「〇〇の判断が出れば着手できる」まで書いておくと、次のセッションがすぐ動ける。
ログの3層構造
ログはSHORT・MIDDLE・FULLの3層に分けている。
- SHORT（3行以内）：次のセッションが最初に読む要約。朝礼のイメージ
- MIDDLE：判断の根拠・却下した案・発見した事実の詳細
- FULL：AIの全発言を自動記録する監査ログ。ほとんど読まないが後から調べるときに使う
次のセッションはSHORTから読んで、必要な部分だけMIDDLEに潜る。
デバイス間の連絡をAIに自分でやらせる
最初は「MacのAIが出した内容をコピペしてWindowsに渡す」という運用をしていた。
これが地味にストレスで、自分がメッセンジャーになっている感じがしてどうにかしたかった。
解決策はシンプルで、全デバイスが同じファイルを共有するだけでいい。
shared/context.md をgitで全デバイスに同期させて、AIはここに直接メッセージを書き込む。
相手は次のセッション開始時に自動で読む。
## 📨 インスタンス間メッセージ
### Mac → Windows
Windowsでも session_start.sh を動かしてほしい。
パスは /home/user/logs に変えること。確認したらこのメッセージを消すこと。
### Windows → Mac
完了した。ログの同期も確認できた。
ポイントはAIへの指示書（CLAUDE.md）に「他デバイスに伝えたいことがある場合、ユーザーに頼まずに自分でこのファイルに書くこと」と明記しておくことだ。
書いておかないとAIは普通にユーザーへコピペを頼んでくる。
自動化の仕組み（フック）
Claude Codeには「フック」という機能があって、セッションの開始・終了など特定のタイミングで自動的にスクリプトを実行できる。
設定ファイルにこう書くだけだ。
{
"hooks": {
"SessionStart": [
{ "hooks": [{ "type": "command", "command": "bash ~/scripts/session_start.sh" }] }
],
"Stop": [
{ "hooks": [{ "type": "command", "command": "bash ~/scripts/session_log.sh" }] }
]
}
}
起動時の session_start.sh は、他デバイスの最新ログをgitで取得→自分宛てメッセージを表示→直近3セッションのSHORTを表示→今日のノートを作成、という順番で動く。
終了時の session_log.sh は以下をやる。
- ログに変更があればgitに保存する
- AIがSHORTを書き込んだらセッション完了とみなす
- 他デバイスへgitで自動送信する
実際のスクリプトとCLAUDE.mdのテンプレートはGitHubに置いている。
→ GitHub: https://github.com/msnr0404/ai-handoff-log
運用してみてわかったこと
一番大きかったのは「同じ提案を繰り返される」問題がほぼ解消したことだ。
却下した案とその理由をログに残すようにしてから、「昨日それ試してダメだったんだけど」というやり取りが激減した。
MacとWindowsで作業を引き継ぐときの「また一から説明する」もなくなった。
起動したら前回のSHORTが画面に出てくるので、どこまでやっていたかがすぐわかる。
予想外だったのはログが溜まってくると自分の判断パターンが見えてくることだ。
「自分はいつもここで詰まる」という傾向が記録として残るので、俯瞰できるようになった。
課題もある。ログの品質はセッションによってばらつく。
複数デバイスが同時に shared/context.md を更新すると競合が起きる可能性があるし、FULLログは長期運用で容量が増えていく。
大げさなシステムではなく、CLAUDE.mdのテキスト記述とシェルスクリプト数本で動いている。
プログラミングが得意じゃなくてもバイブコーディングで作れた。
ただ、仕組みよりも「引き継ぎのためのログ」という目的の明確化と、「却下した案を必ず書く」というルールの徹底の方が、実際には効果が大きかった。
複数のAIインスタンスを使う機会がある人は、同じ問題に当たっていると思う。