0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

複数端末・複数AIツール(Cursor / Claude Code)を行き来してもコンテキストを失わない作業環境を作る

0
Last updated at Posted at 2026-06-03

この文章はClaude Opus 4.8のサポートを受けて執筆しています.

この記事について

CursorやClaude CodeのようなAIエージェント型の開発・執筆支援ツールを使って,論文や技術文書,コードなどの知的作業を進めるとき,多くの人が次の状況に直面する.

  • 自宅のデスクトップ,ノートPCなど,複数の端末を渡り歩いて作業する.
  • ツールとしてCursorとClaude Codeの両方を使い,しかも作業の途中でツール自体を乗り換えることがある.
  • そのたびにAIは文脈をリセットするので,「前回どこまでやったか」「このプロジェクトの方針は何か」を毎回説明し直すことになる.

素朴な対処として「コンテキストを1枚の .md に書かせて,作業開始時に読ませ,終了時に書き足す」という運用がある.これは方向性としては正しいが,1枚にすべてを詰め込むと破綻しやすい.

本記事では,端末間・ツール間でコンテキストの継続性を保つための設計原則を整理し,同期基盤がgitの場合とDropboxの場合のそれぞれについてベストプラクティスをまとめる.
結論を先に書くと,要点は次の3つである.

  1. コンテキストを 「変化速度」で分離する.不変のルールと,毎回変わる引き継ぎ状態を別ファイルにする.
  2. 正本となるコンテキストファイルをツール非依存の AGENTS.md に寄せる.Claude Code用の CLAUDE.md はそこへの参照1行だけにする.
  3. 同期基盤に応じて衝突モデルを設計する.Dropboxなら「1セッション1ファイル」で競合コピーを根絶する.

1. 問題の構造を整理する

AIエージェントは原則として,セッションごとに文脈を失う.大規模言語モデルは推論呼び出しの間に記憶を保持しないためで,これはバグではなく仕様である.だから「記憶」は,利用者側がファイルとして外部に持たせて,毎回読ませる形で実現することになる.

ここで混乱しやすいのは,性質の異なる2種類の情報を1枚のファイルに混ぜてしまうことだ.

  • ほぼ不変の情報:プロジェクトの目的,文書の対象読者,引用スタイル,命名規則,「日本語の口語で説明する」といった恒久的な指示.
  • 毎回変わる情報:前回どの節まで書いたか,どんな判断を下したか,次に何から再開するか.これはセッションのたびに更新される.

この2つを1枚に混ぜると,更新頻度の高い情報のせいでファイル全体が肥大化し,毎回の読み込みコストが上がり,かつ「どこが最新の状態なのか」が分かりにくくなる.したがって最初の原則は,この2つを分離することである.


2. 基本原則1:コンテキストを「変化速度」で分離する

具体的には,次の2層に分ける.

2-1. 不変のルール層

プロジェクトの恒久的な前提を書く.後述する AGENTS.md に置く.更新頻度が低いので,複数端末から同時に編集することはまずない.

2-2. 引き継ぎ状態層(HANDOFF)

「前回どこまでやって,次に何をするか」を書く.これが端末を渡り歩くときの継続性の本体である.毎回テンプレートに沿って書くと精度が安定する.

## 2026-06-04 09:30 (MacBook / Claude Code)
- 進捗: 第3章のロジックを整理し,図4の説明文を修正した.
- 直近の決定: 用語Aは「〜」に統一する方針とした.
- 次の一手: 第4章の実験結果の記述から再開する.
- 未解決: 参考文献[12]の出典を要確認.

セッション終了時にこの形式で1ブロックを書き,開始時には末尾のブロックだけを読めばよい.この「末尾だけ読む」「終了時に追記する」という運用ルール自体は,後述するとおり不変のルール層(AGENTS.md)に明記しておく.

論文作成のように作業が連続的なものでは「次に書く節」が引き継ぎの中心になるし,資料作成やコードのリファクタリングのように作業単位が離散的なものでは「各タスクの状態」が中心になる.扱う仕事の性質に合わせてテンプレートを用意するとよい.


3. 基本原則2:正本を AGENTS.md に寄せる(ツール非依存)

CursorとClaude Codeを行き来するなら,正本のコンテキストファイルは AGENTS.md にするのが現状の最善手である.

3-1. AGENTS.md とは

AGENTS.md は,AIコーディングエージェント向けの指示を書くための,ベンダー中立のオープン標準である.2025年8月にOpenAIが提案し,2025年12月にLinux Foundationへ寄贈された.2026年時点で,Codex,Cursor,GitHub Copilot,Gemini CLI,Aider,Windsurf,Zedなど主要なエージェントがネイティブで読み込むようになっており,多数の公開リポジトリで採用が進んでいる.

要するに,1つのファイルを書けば複数のツールが同じ内容を読んでくれるので,ツールを乗り換えてもコンテキストの二重管理が発生しない.

3-2. Claude Code 側での扱い

Claude Codeの本来の規約ファイルは CLAUDE.md だが,@ 記法で外部ファイルを取り込める.CLAUDE.md の先頭に1行だけ書けばよい.

@AGENTS.md

これで AGENTS.md の内容がそのまま読み込まれる.実体は AGENTS.md に集約し,CLAUDE.md は参照専用にしておくと二重管理を避けられる.

なお,Claude Codeのメモリには階層がある.プロジェクト直下の CLAUDE.md または .claude/CLAUDE.md がプロジェクトメモリ,~/.claude/CLAUDE.md がユーザメモリとして,いずれもセッション開始時に読み込まれる./memory コマンドで,どのファイルが読み込まれているかを確認・編集できる.また,肥大化を避けるため CLAUDE.md は200行程度以内に保ち,細分化したいルールは .claude/rules/ に分けるのが推奨されている.

3-3. Cursor 側での扱い

Cursorはプロジェクトルートおよびサブディレクトリの AGENTS.md をネイティブに読み込む.したがって追加の橋渡しは不要で,AGENTS.md をプロジェクト直下に置くだけで効く.

Cursorにはより構造化された仕組みとして .cursor/rules/*.mdc(YAMLフロントマターでスコープや発火条件を制御するルール)もあるが,端末・ツールを横断する正本としては,プレーンなMarkdownである AGENTS.md のほうが移植性が高い.まずは AGENTS.md に寄せ,Cursor固有の細かい制御が必要になった部分だけ .cursor/rules/ に切り出す,という順序がよい.


4. 基本原則3:作業原則そのものをどこに書くか

「HANDOFFを読む・書く」「正本はAGENTS.mdである」といった作業原則(メタルール)自体を,どこに書いておけば自動で効くのか,という問題がある.これは原則の適用範囲によって置き場所を分けるのがよい.

4-1. プロジェクト固有の内容 → リポジトリ / プロジェクトフォルダ内

プロジェクトの目的や,そのプロジェクト特有の運用ルールは AGENTS.md に書く.ファイル同期(gitやDropbox)に乗るので,どの端末・どちらのツールでも同じ内容が揃う.端末間の継続性の本体はこの層である.

4-2. 全プロジェクト共通の汎用ルール → ユーザーグローバル設定

「すべてのプロジェクトでHANDOFFを末尾だけ読む」のような,プロジェクトをまたいで効かせたい原則は,ツールのユーザーグローバル設定に置く.

  • Claude Code: ~/.claude/CLAUDE.md(ユーザメモリ)./memory で編集でき,全セッション開始時に読み込まれる.
  • Cursor: 設定 → Rules の User Rules(旧称 "Rules for AI").エディタ全体に常時含まれるユーザーレベルの指示である.

4-3. 優先順位(衝突したときの挙動)

Claude Codeのメモリは,おおむね「プロジェクトメモリ > プロジェクトルール(.claude/rules/)> ユーザメモリ > ユーザールール(~/.claude/rules/)> ローカルプロジェクトメモリ > 自動メモリ」の順で優先される.つまりプロジェクト側がユーザーグローバル側を上書きできるので,汎用ルールをグローバルに置きつつ,特定プロジェクトだけ例外運用にしたい場合は AGENTS.md 側で上書きすればよい.設計として素直である.

4-4. ユーザーグローバル設定の同期に注意

ここに落とし穴がある.ユーザーグローバル設定は,プロジェクトの同期(gitやDropbox)には自動で乗らない.各端末で個別に用意する必要がある.

  • ~/.claude/CLAUDE.md は単なるファイルなので,dotfiles管理下に置いてシンボリックリンクするか,後述のDropbox配下に実体を置いてリンクすれば,全端末へ同期できる.
  • CursorのUser Rulesはアプリ設定内に保存されるため,ファイルとして同期しにくい.正本のテキストをどこかに保管しておき,新しいマシンのセットアップ時に一度だけ貼り付ける運用が現実的である.頻度が低いので許容できる.

最小構成で始めるなら,まずは(4-1)の AGENTS.md に作業原則ごとすべて書くのが最も堅実だ.これだけで「同期された全端末・両ツール」をカバーできる.汎用化して新規プロジェクトにも自動で効かせたくなった段階で(4-2)を足す,という順序を勧める.


5. 同期基盤がgitの場合

プロジェクトをgit管理しているなら,端末間の継続性は git pull / git push に集約できる.AGENTS.mdCLAUDE.md,HANDOFFのファイル群もまとめてコミットすれば,ある端末で終えて別の端末で開く流れが自然に成立する.コミット履歴がそのまま変更の履歴になるという利点もある.

ただし,後述するように,すべてのファイルをDropboxで同期している運用では,gitリポジトリを持つこと自体が例外的になる.その場合は次節の方針をとる.


6. 同期基盤がDropboxの場合(本記事の主眼)

ユーザファイルをほぼすべてDropboxで同期している運用では,git前提のベストプラクティスをそのまま当てはめる必要はない.重要なのは,ファイルの置き場所はほとんど変わらず,変わるのは「衝突モデル」だけだということである.

6-1. 前提:Cursor も Claude Code も git を必要としない

両ツールとも,開いた「フォルダ」の直下にある AGENTS.md / CLAUDE.md を読むだけで,対象がリポジトリである必要はない.したがって,Dropbox上のプロジェクトフォルダ直下に AGENTS.md(および @AGENTS.md だけの CLAUDE.md)を置けば,これまでの構成はそのまま成立する.ここで諦めるものは何もない.

6-2. 本当の敵は「競合コピー(conflicted copy)」問題

gitとの最大の違いは,マージの仕組みがないことだ.Dropboxの失敗モードは,2台が同期完了前に同じファイルを編集すると,「○○ (端末名 の競合コピー)」というファイルが生成され,自動マージされない点にある.

ここで問題になるのが,原則1で勧めた「単一のHANDOFFファイルに追記していく」方式である.これは実はDropboxと最も相性が悪い.共有された1ファイルを複数端末が触りに行くため,競合コピーが発生しやすい.対策は次の2系統で,併用が理想だ.

6-3. 対策①:規律で防ぐ(最低限)

作業時は常に1台だけをアクティブにし,端末を移る前にDropboxの同期完了(チェックマーク)を必ず待つ.当たり前に見えるが,「移動中に少しだけ見て,戻って続きをやる」といった細切れの作業で破綻しやすい.明示的に習慣化しておく価値がある.

6-4. 対策②:構造で防ぐ(推奨)

HANDOFFを1ファイルに追記するのをやめ,1セッション=1ファイルとして handoff/ サブフォルダへ書き出す.

handoff/
  2026-06-04T0930_macbook.md
  2026-06-04T2140_desktop.md

新規ファイルは複数端末による同時編集(co-edit)が起きないため,競合コピーが原理的に発生しない.「再開するときは handoff/ 内の最新ファイルを読む」と AGENTS.md に明記しておけば,運用も単純なままだ.作業単位が離散的な仕事ほど,この方式がよく噛み合う.

一方,AGENTS.md(不変ルール)は更新頻度が低く,2台で同時に編集することがまずないので,単一ファイルのままで問題ない.つまり「低頻度・単一ファイル」と「高頻度・ファイル分割」を使い分けるのがコツである.

6-5. Dropboxならではの注意点

バージョン管理はDropbox履歴で代替できる. gitのコミット履歴の代わりに,Dropboxのバージョン履歴と「削除・競合ファイルの復元」機能が安全網になる.誤って上書きしても遡れるので,バージョニングの利点を完全に失うわけではない.

作業中のフォルダは必ず「オフラインで利用可能」にしておく. スマートシンク等でオンライン専用(プレースホルダ)状態になっていると,ツールがファイルの実体を読めずに失敗する.アクティブなプロジェクトフォルダはローカルに実体化(ピン留め)しておく.

Dropbox内に本物のgitリポジトリを置かない. .git ディレクトリを複数端末が同時に同期すると,リポジトリ破損の典型的な原因になる.どうしてもgitが必要な案件だけ,例外的にDropbox外に置く.これはまさに「gitは例外的」という運用とも整合する.


7. 自動メモリの扱い

Claude Codeには自動メモリ機能があり,~/.claude/projects/<project>/memory/ 配下に,CLAUDE.md に明示していない発見(観測した命名規則や依存関係など)を自分で記録していく.Cursorにも,実行をまたいで学習するMemories系の機能がある.

これらは便利だが,いずれもツール固有・端末ローカルであり,CursorとClaude Codeの間や端末間では共有されない.したがって正本(信頼できる唯一の情報源)にはせず,あくまで補助として扱う.「真実はDropbox上の AGENTS.mdhandoff/ のファイルにある」という原則を崩さなければ,全体の一貫性は保たれる.


8. 推奨セットアップ(まとめ)

最小構成から拡張までを段階的に示す.

8-1. 最小構成(まずこれだけで動く)

Dropbox上のプロジェクトフォルダを次のようにする.

my-project/            # Dropbox配下,オフライン実体化しておく
├── AGENTS.md          # 不変ルール + 作業原則(正本)
├── CLAUDE.md          # 中身は「@AGENTS.md」の1行だけ
├── handoff/           # 1セッション1ファイル
│   ├── 2026-06-04T0930_macbook.md
│   └── ...
└── (本体の原稿やコードなど)

AGENTS.md には,プロジェクトの前提に加えて,次のような運用ルールを書いておく.

## このプロジェクトでの作業ルール
- セッション開始時: handoff/ 内の最新ファイルを読み,前回の続きから始めること.
- セッション終了時: handoff/ に「YYYY-MM-DDTHHMM_端末名.md」という新規ファイルを作り,
  進捗・直近の決定・次の一手・未解決事項を記録すること.既存ファイルへ追記しないこと.
- このファイル(AGENTS.md)がプロジェクトの正本である.自動メモリは補助に留めること.

8-2. 拡張(全プロジェクト共通化したくなったら)

「HANDOFFを読む・書く」という汎用ワークフローを,各ツールのユーザーグローバル設定(Claude Codeは ~/.claude/CLAUDE.md,CursorはUser Rules)に移し,個々の AGENTS.md からは重複記述を減らす.グローバル設定の端末間同期は,dotfilesやDropbox配下への実体配置+シンボリックリンクで対応する.

8-3. 配置と同期の対応表

置き場所 主な内容 同期 読むツール
AGENTS.md(プロジェクト直下) プロジェクト固有 + 作業原則 Dropbox(自動) Cursorは直接,Claude Codeは @ 経由
handoff/*.md(プロジェクト直下) セッション間の引き継ぎ状態 Dropbox(自動,競合回避済み) 両ツール
~/.claude/CLAUDE.md 全プロジェクト共通の汎用ルール dotfiles / リンク(手動セットアップ) Claude Code
Cursor User Rules 全プロジェクト共通の汎用ルール 各マシンで1回貼り付け Cursor

9. まとめ

複数端末・複数ツールを行き来しながらコンテキストを維持するための要点は,次の3つに集約される.

  • 変化速度で分離する. 不変ルール(AGENTS.md)と引き継ぎ状態(handoff/)を分ける.
  • 正本をツール非依存に寄せる. AGENTS.md を正本とし,Claude Codeは @AGENTS.md で参照するだけにする.これでCursorとClaude Codeを乗り換えても二重管理が起きない.
  • 同期基盤に応じて衝突モデルを設計する. Dropbox中心なら,HANDOFFを「1セッション1ファイル」にして競合コピーを根絶し,同期完了を待つ規律を持ち,アクティブフォルダはオフライン実体化しておく.

特にDropboxを主な同期基盤とする運用では,ファイル配置は据え置きでよく,変えるべきは「単一ファイルへの追記」をやめて「ファイル分割」にする一点に尽きる.これだけで,git前提のベストプラクティスの大半を,Dropboxの作法に翻訳して享受できる.


参考リンク

注: 各ツールの仕様(メモリの階層やファイルパス,Cursorのルール形式など)は更新が速い領域である.導入時には公式ドキュメントで最新の仕様を確認してほしい.

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?