複数のAIエージェント（Claude CodeとCodexなど）に同じプロジェクトを任せていると、「今どこまで進んでいて、誰が何を待っているか」が会話の中にしか存在しなくなる瞬間がある。実際に別セッションの成果物を、タイムスタンプの違和感から偶然発見したことがある。その事故から組み直した、引き継ぎ専用ファイル1枚の設計を書く。
進行中の作業を取りこぼさないdone / in-flight / waiting-user / next の4行エントリ設計と、状態・履歴・引き継ぎ・保管を混ぜない4層の役割分担の考え方。
1つのプロジェクトを、Claude CodeとCodexという2つの異なるAIエージェントに任せて回している。片方が調査や設計を担当し、もう片方が実装や検品を担当する、といった分担だ。この体制で一番怖いのは、バグでも衝突でもなく、「今どこまで進んでいるか」が誰にも見えなくなる瞬間だった。
ある日、片方のエージェントが作業したファイル群を、更新日時の違和感から偶然見つけたことがある。作業自体は正しかったが、こちらは何も知らないまま別の変更を進めようとしていた。会話ログは各セッションに閉じていて、次のセッションには引き継がれない。「進行中・承認待ちの作業」は、会話の中にしか存在せず、状態を記録するファイルにも履歴を記録するファイルにも載らない——これが同期の最大の敵だと気づいた。
解決策は複雑な仕組みではなく、逆に情報を絞ることだった。「進行管理の窓口」という役割を持つMarkdownファイルを1つだけ作り、セッションの終わりに必ず1エントリ追記するルールにする。書く項目は4つだけに固定した。
完了した作業を短く書く。ここは詳細を書きすぎない。詳細は別ファイル（作業ログや履歴ファイル）に任せ、このエントリでは「何が終わったか」の見出しだけを残す。
まだ終わっていない作業と、ユーザーの承認や操作を待っている項目を分けて書く。ここが空欄なら「何も進行中ではない」ことの明示になる。書き忘れると、次のセッションが同じ作業に重複して手を付けてしまう。
次のセッション（自分か、相方のエージェントか、ユーザー本人か）が最初に読むべき行動を1〜3個、日付つきで書く。相対的な表現（「来週」など）は使わず、絶対日付に変換して記録するのがポイントだ。
ここが核心。「終わったこと」より「終わっていないこと」を書く方が難しく、価値が高い。in-flight / waiting-user の欄が正直に埋まっているかが、この仕組みが機能しているかどうかの唯一のテストになる。
この引き継ぎファイルがうまく機能する理由は、書式そのものより、他の記録ファイルと役割を厳密に分けていることにある。1つのファイルに全部書こうとすると、すぐに肥大化して誰も読まなくなる。
状態ファイルに「進行中の作業」を書かず、引き継ぎファイルに「これまでの全履歴」を書かない——この線引きだけで、どのファイルも肥大化せずに読めるサイズを保てる。
複数人・複数AIでなくても、「今日の自分」と「明日の自分」の引き継ぎとして同じ設計がそのまま使える。