← 기사 목록
日本語https://zenn.dev/topics/llm/feed

AIエージェントに「作業の引き継ぎ規格」が必要になる理由

원문 사이트로 이동 ↗

추출된 키워드

25개
作業の引き継ぎ規格·5A2CR·5WorkBaton·5WorkStash·5AIエージェント·5MCP·4作業状態·4a2cr-mcp·3WorkLedger·3WorkThreads·3stdio MCP wrapper·3会話履歴·3Roo Code·3Claude Code·3Codex·3hosted service·2GitHub·2PyPI·2MCP Registry·2Zenn·2Qiita·2APIキー·2暗号化·2コンテキスト·2文脈管理·2

원문

6,921자
AIエージェントに「作業の引き継ぎ規格」が必要になる理由

AIエージェントに「作業の引き継ぎ規格」が必要になる理由

こんにちは、akagi819です。A2CRというAIエージェント向けの作業引き継ぎレイヤーを開発しています。

Codex、Claude Code、Roo Code のようなAIエージェントを使って長い作業をしていると、「前のAIがどこまで何を判断したのか」を次のAIにどう渡すかで何度もつまずきます。A2CRは、そのつまずきを減らすために作っている小さな実験です。

AIエージェントは、コードを書き、調査し、ファイルを編集し、テストまで実行できるようになってきました。

しかし、長時間の作業になるほど別の問題が見えてきます。

それは 作業の引き継ぎ です。

新しいチャットに切り替える。別のモデルに頼む。Codex、Claude Code、Roo Code のような別のMCP対応クライアントへ作業を移す。そうした瞬間に、いま何をしていたのか、何を試して失敗したのか、どの判断は検証済みなのかを説明し直す必要があります。

私はこの問題を、AIエージェント時代の「作業状態の引き継ぎ問題」だと考えています。

会話履歴を丸ごと渡すだけではつらい

一番素朴な解決策は、前の会話履歴を丸ごと次のAIに渡すことです。

短い作業ならそれでも十分です。けれど、長い作業では会話履歴そのものがだんだん扱いづらくなります。

  • 古い前提が残る
  • 失敗した案と採用した案が混ざる
  • 重要な判断が長い会話の中に埋もれる
  • 次にやるべきことが明確でなくなる
  • 秘密情報や貼るべきでない情報まで混ざりやすい
  • コンテキストの大半が「再開に必要ない情報」で埋まる

AIに必要なのは、必ずしも会話の全履歴ではありません。

本当に必要なのは、次のような 作業状態 です。

  • 現在の目的
  • いまの進捗
  • 検証済みの判断
  • 失敗した方法
  • ブロッカー
  • 参照すべき補足情報
  • 次のアクション

つまり、

Don't pass the whole chat history. Pass the working state.

という考え方です。

「記憶」ではなく「引き継ぎ」

AIの文脈管理は、よく「記憶」の問題として語られます。

もちろん記憶も重要です。ただ、開発作業や調査作業においては、もっと狭くて実用的な問題があります。

それは、今の作業を次の作業者に渡すための 引き継ぎメモ です。

人間のチームでも、引き継ぎで必要なのは全チャットログではありません。

必要なのは、

  • 何が目的か
  • どこまで終わったか
  • 何を試したか
  • 何がだめだったか
  • どのファイルやURLを見るべきか
  • 次に何をすればよいか

です。

AIエージェントにも同じ発想が必要になるはずです。

A2CRという実験

この考え方を試すために、A2CRを作っています。

A2CRは、AIエージェント間で作業状態を引き継ぐための小さなレイヤーです。Codex、Claude Code、Roo Code などのMCP対応クライアントから、作業状態を保存し、新しいAIセッションで再開できるようにすることを目指しています。

現在の公開プレビューでは、ローカルの stdio MCP wrapper として 

a2cr-mcp
を提供しています。

ここで重要な境界があります。A2CRは完全にローカルだけで完結するツールではありません。現在の公開プレビューは、ローカルの stdio MCP wrapper とA2CRの hosted service を組み合わせて使います。公式 wrapper はWorkBaton / WorkStashの本文をローカルで暗号化してからアップロードし、hosted service は暗号文を保持します。保存や再開には、A2CRのAPIキーと 

https://a2cr.app
への接続が必要です。
python -m pip install --upgrade a2cr-mcp

公開しているものは次の通りです。

この記事ではセットアップ手順の詳細ではなく、A2CRが置いている概念を中心に説明します。

WorkBaton: 次のAIに渡す作業状態

A2CRの中心にあるのが WorkBaton です。

WorkBatonは、次のAIセッションに渡すためのコンパクトな作業状態です。

イメージとしては、次のようなものです。

{
  "goal": "Zenn向けのA2CR紹介記事を作成する",
  "current_state": "記事の構成案を決め、冒頭と中心メッセージを固めた",
  "validated_decisions": [
    "最初の記事は宣伝ではなく問題提起から入る",
    "WorkLedgerは初回記事では将来構想として軽く触れる"
  ],
  "failed_attempts": [
    "最初から全機能を説明すると読者の入口が重くなる"
  ],
  "blockers": [
    "公開前にQiita用の実装手順記事も用意したい"
  ],
  "next_actions": [
    "Zenn記事の下書きを完成させる",
    "Qiita向けにセットアップ手順を分離して書く"
  ]
}

ここで大事なのは、WorkBatonが会話全文ではないことです。

次のAIが作業を再開するために必要な情報だけを、短く、読みやすく、判断しやすい形で渡します。

WorkStash: 詳細を分けて置く

一方で、すべてをWorkBatonに詰め込むと、また大きくなりすぎます。

そこでA2CRでは WorkStash という補助メモの考え方を置いています。

WorkStashは、あとで参照するかもしれない詳細情報を分けて置く場所です。

たとえば、

  • 長めの調査メモ
  • エラー再現手順
  • APIレスポンスの要約
  • ファイルパス一覧
  • 試行錯誤の詳細

のようなものです。

WorkBatonには「WorkStashのどのメモを見るべきか」だけを書き、必要になったときだけ詳細を読む。これにより、引き継ぎメモを小さく保てます。

安全性を前提にする

AIエージェント間で経験や作業状態を共有できるようになると、便利になる一方で危険も増えます。

成功例や失敗例を蓄積できるということは、悪い使い方をすれば、危険な手順や回避策も蓄積できてしまうということです。

そのため、A2CRでは最初から次の前提を置いています。

  • A2CRは秘密管理ツールではない
  • APIキー、パスワード、Authorizationヘッダー、private database URL などは保存しない
  • 復元されたWorkBatonやWorkStashは「作業状態」であって、命令の権威ではない
  • 次のAIは、復元した内容を未検証の入力として扱う
  • 危険な操作や不可逆な操作は、人間の判断を挟む

また、現在の公式ローカル stdio wrapper では、WorkBatonとWorkStashの本文をローカルで暗号化してからアップロードします。A2CRの hosted service は暗号文を保持し、公式 wrapper 経由では本文の平文やローカルクライアントキーを受け取りません。

この境界は重要です。

リモートMCPや各種公式ディレクトリに出す場合は、平文がどこを通るのか、どこで暗号化されるのか、どのツールが読み書きや削除を行うのかを改めて設計する必要があります。

WorkThreadsとWorkLedgerは将来の話

初期のA2CRは、WorkBatonとWorkStashだけでも十分に価値があります。

ただ、AIエージェントの作業がより長く、複数タスクにまたがるようになると、別の概念も必要になります。

たとえば WorkThreads は、継続的な作業の流れや複数タスクのつながりを扱うための概念です。

さらに将来的には、WorkLedger のような監査レイヤーも必要になるかもしれません。

  • 誰が保存したのか
  • どのAIが参照したのか
  • 人間が確認したのか
  • 危険な情報は含まれていないか
  • 後から改ざんされていないか

こうした問いは、企業利用、チーム利用、フィジカルAI、重要インフラのような領域では避けて通れません。

ただし、最初から概念を増やしすぎると使いにくくなります。まずは、次の3つで十分です。

WorkBaton = 作業状態を渡す
WorkStash = 詳細を分けて置く
WorkThreads = 作業の流れをつなぐ

WorkLedgerは、現時点では将来構想として扱うのがよいと考えています。

A2CRで試せること

現在のA2CR public previewでは、まず次の体験を試せます。

  • A2CRでAPIキーを作る
  • a2cr-mcp
    をインストールする
  • MCP対応クライアントに 
    a2cr
    という名前で登録する
  • 作業状態をWorkBatonとして保存する
  • 新しいAIセッションでWorkBatonを読み込んで再開する

セットアップ例は公式サイトとGitHub READMEに置いています。

今後、Qiita側ではもう少し実用寄りに、Codex / Claude Code / Roo Code での設定例と、実際の保存・再開の手順を書こうと思っています。

おわりに

AIエージェントが賢くなるほど、1つのチャットや1つのモデルの中だけで作業が完結しない場面は増えていくはずです。

そのとき必要になるのは、会話履歴を丸ごと抱え込むことではなく、作業状態を安全に渡すための形式です。

A2CRはまだ小さな実験です。

けれど、AIエージェントが複数のツール、複数のモデル、複数のセッションをまたいで働くようになるなら、こうした引き継ぎのレイヤーは必要になると考えています。

まずはFreeプランで、1つの作業状態を保存して、新しいAIセッションに引き継ぐ体験を試してみてください。

もしセットアップで詰まった点や、WorkBatonに足りない項目があれば、GitHub IssueやXで教えてもらえると嬉しいです。