💨

handoff.mdで十分？ AIエージェントの作業引き継ぎにA2CRを使う理由

2026/05/16に公開

Python

Model Context Protocol

llm

Claude Code

tech

AIエージェントとの作業が長くなると、最後に困るのはコードそのものではなく、「次のAIに何を渡せば続きから動けるのか」だったりします。
そのとき、まず一番簡単なのはローカルに handoff.md を作ることです。
結論から言うと、handoff.md で足りているなら、それで十分です。小さな作業、単発の調査、同じリポジトリ内で完結する修正なら、手書きの引き継ぎメモはかなり強いです。
一方で、作業が複数日にまたがったり、Codex / Claude Code / Roo Code のような複数のMCP対応クライアントを行き来したり、補助メモが増えてきたりすると、ただの handoff.md だけでは少しずつつらくなります。
この記事では、ローカル handoff.md と A2CR の違いを、できるだけ公平に整理します。

 まずは handoff.md で十分な場面handoff.md は、とても良い出発点です。
たとえば、次のようなメモをリポジトリに置くだけでも、次のAIセッションはかなり再開しやすくなります。
# Handoff

Goal: Fix the failing login test.

Current state:
- Reproduced the 401 after token refresh.
- The refresh branch is the likely cause.

Tried:
- Updating the fixture did not fix it.

Decision:
- Do not change the database schema yet.

Next action:
- Inspect src/auth refresh logic and rerun the focused test.
この形の良いところは明快です。
すぐ作れる
人間が読みやすい
Gitで差分を追える
追加ツールやアカウントがいらない
作業リポジトリの中に自然に置ける
短い作業なら、まず handoff.md から始めるのが一番です。A2CRを使う前に、そもそも「会話履歴を丸ごと渡すのではなく、作業状態を短く渡す」という習慣を作るだけでも効果があります。

 handoff.md がつらくなる場面ただ、手書きの引き継ぎファイルは、作業が長くなると少しずつあいまいになります。

 最新状態がどれかわからなくなるhandoff.md を更新し忘れたり、別のファイルにメモが増えたり、チャット側にも重要な判断が残ったままになったりします。
その結果、次のAIに渡すときに「このファイルが本当に最新なのか」を人間が判断する必要が出てきます。

 補助メモが混ざりやすい最初は短い引き継ぎメモだったものが、だんだん次のような情報で膨らみます。
調査ログ
エラー出力
URL一覧
ファイルパス一覧
試したけれど採用しなかった案
あとで見るかもしれないメモ
もちろん、これらは役に立つことがあります。問題は、次のAIが最初に読むべき「再開に必要な状態」と、必要になったときだけ見ればよい「補助情報」が同じ場所に混ざることです。

 クライアントをまたぐと手作業になる同じリポジトリを開いているだけなら handoff.md は楽です。
でも、別のAIクライアント、別のチャット、別の作業環境に移ると、次のような手作業が増えます。
どのファイルを読ませるか指定する
最新のメモがどれか説明する
長い補助メモは貼るか貼らないか判断する
重要な判断だけをもう一度要約する
この手作業が増えるほど、引き継ぎの品質は人間の注意力に依存します。

 安全ルールも人間の習慣に依存するhandoff.md は自由に書けるぶん、危険な情報も入りやすいです。
たとえば、次のようなものは入れるべきではありません。
APIキー
パスワード
Authorizationヘッダー
Cookie
private database URL

.env の中身
会話全文
長いログ
大きなソースコード本文
ローカルファイルなら何を書いても安全、というわけではありません。リポジトリに含めればコミットや共有に混ざる可能性がありますし、AIに読ませれば次のセッションの入力にもなります。

 A2CRは何を変えるのかA2CRは、AIエージェント間で作業状態を引き継ぐためのMCP対応レイヤーです。
中心にあるのは WorkBaton という小さな引き継ぎチェックポイントです。WorkBatonには、次のAIが再開するために必要な情報だけを入れます。
一方で、あとで参照するかもしれない補助メモは WorkStash に分けます。
WorkBaton = 次のAIがまず読む作業状態
WorkStash = 必要になったときだけ参照する補助メモ
この分け方により、引き継ぎの入口を小さく保ちやすくなります。
A2CRは現在、ローカルの stdio MCP wrapper である a2cr-mcp と、A2CRの hosted service を組み合わせて使う公開プレビューです。完全にローカルだけで完結するツールではありません。
公式 wrapper は、WorkBaton / WorkStash の本文をローカルで暗号化してからアップロードします。hosted service は暗号文を保存し、公式 wrapper 経由では本文の平文やローカル client key を受け取りません。保存や再開には、A2CRのAPIキーと https://a2cr.app への接続が必要です。
この境界は大事です。A2CRはシークレットマネージャーではありません。秘密情報や長いログを保存する場所ではなく、AI作業を再開するための状態を短く残すための道具です。

 比較表

観点
ローカル handoff.md

A2CR


始めやすさ
とても簡単。ファイルを作るだけ
MCP設定とAPIキーが必要

人間の読みやすさ
とても読みやすい
WorkBaton自体は読みやすいが、ツール経由で扱う

最新状態の明確さ
更新忘れや複数ファイルであいまいになりやすい
Slot / resume の流れで意図したチェックポイントを扱いやすい

複数クライアント間の引き継ぎ
ファイル指定やコピーが必要
MCP対応クライアントから保存・再開する前提

補助メモ
1ファイルに混ざりやすい
WorkStashに分けられる

安全ルール
人間の運用に依存
ツール説明と保存ルールで禁止情報を意識しやすい

オフライン性
ローカルだけで完結できる
hosted service への接続が必要

長期作業
ファイルが肥大化・陳腐化しやすい
複数日・複数セッションの再開に向く


 同じ作業を2つの形で渡すローカル handoff.md なら、こう書けます。
# Handoff

Goal: Fix login error.

Current state:
- Confirmed the API returns 401 after token refresh.
- The failure is reproducible with the existing fixture.

Tried:
- Updating fixture data did not fix it.

Decision:
- Do not change DB schema yet.

Next action:
- Inspect src/auth refresh logic.
- Run the focused login test again.
A2CRのWorkBatonなら、同じ内容を次のような形で保存します。
{
  "goal": "Fix login error",
  "current_state": "Confirmed the API returns 401 after token refresh.",
  "next_action": "Inspect src/auth refresh logic and rerun the focused login test.",
  "decisions": [
    "Do not change the database schema yet."
  ],
  "failed_attempts": [
    "Updating fixture data did not fix the failure."
  ],
  "validation": [
    "Reproduction confirmed with the existing fixture."
  ]
}
どちらも本質は同じです。大事なのは、次のAIが作業を再開できる状態に絞ることです。
違いは、A2CRではこの形をMCPツールの流れに乗せて、保存・再開・補助メモ参照の習慣として扱いやすくする点です。

 どちらを選ぶべきか私は、最初からA2CRを使うべきだとは思っていません。
まずは handoff.md で十分な場面があります。
1回きりの短い作業
同じリポジトリ内で完結する作業
人間が明確に最新メモを管理できる作業
オフラインで完結させたい作業
まだMCP設定を増やしたくない段階
一方で、A2CRが向いているのは次のような場面です。
作業が複数日にまたがる
複数のAIセッションを行き来する
Codex / Claude Code / Roo Code など複数のMCP対応クライアントを使う
補助メモが増えて、引き継ぎメモが太り始めた
「次にどの状態から再開するか」を明確にしたい
WorkBatonとWorkStashを分けて、安全ルールも意識しながら運用したい

 まとめhandoff.md は良い出発点です。AI作業の引き継ぎで一番大事なのは、まず「会話履歴を丸ごと渡す」のをやめて、「次のAIが再開するための作業状態」を短く渡すことです。
そのうえで、作業が長くなり、複数のAIクライアントや複数日にまたがるようになり、補助メモが増えてきたら、A2CRのWorkBaton / WorkStashという分け方を試す価値があります。
小さく始めるなら handoff.md。
継続的に引き継ぐなら A2CR。
そのくらいの距離感で考えるのが、いまの公開プレビューにはちょうどいいと思っています。

 リンクA2CR: https://a2cr.app/
GitHub: https://github.com/a2cr/a2cr
MCP setup: https://github.com/a2cr/a2cr/blob/main/docs/mcp-setup.md
Qiita setup guide: https://qiita.com/a2cr/items/acb3caac242aeec34539
Zenn concept article: https://zenn.dev/a2cr/articles/155c8f6c8d9695

観点	ローカル `handoff.md`	A2CR
始めやすさ	とても簡単。ファイルを作るだけ	MCP設定とAPIキーが必要
人間の読みやすさ	とても読みやすい	WorkBaton自体は読みやすいが、ツール経由で扱う
最新状態の明確さ	更新忘れや複数ファイルであいまいになりやすい	Slot / resume の流れで意図したチェックポイントを扱いやすい
複数クライアント間の引き継ぎ	ファイル指定やコピーが必要	MCP対応クライアントから保存・再開する前提
補助メモ	1ファイルに混ざりやすい	WorkStashに分けられる
安全ルール	人間の運用に依存	ツール説明と保存ルールで禁止情報を意識しやすい
オフライン性	ローカルだけで完結できる	hosted service への接続が必要
長期作業	ファイルが肥大化・陳腐化しやすい	複数日・複数セッションの再開に向く

まずは handoff.md で十分な場面

handoff.md がつらくなる場面

最新状態がどれかわからなくなる

補助メモが混ざりやすい

クライアントをまたぐと手作業になる

安全ルールも人間の習慣に依存する

A2CRは何を変えるのか

比較表

同じ作業を2つの形で渡す

どちらを選ぶべきか

まとめ

リンク

Discussion