Claude CodeやOpenCodeのようなAIコーディングエージェントを複数のリポジトリで並行して使っていると、sessionを跨いだ依頼の伝達がまず崩れる。前のsessionが何を頼まれていたかはチャット履歴の奥に沈み、新しいsessionはその存在に気づかない。気づかなければ二度手間が始まり、気づいても経緯は読み直せないことがある。

本稿はその伝達をINBOX.mdという1枚のMarkdown表に固める設計と運用規律をまとめる。対象は「1人で複数リポジトリを、複数のagent sessionで回している」状況である。Issueトラッカーとの使い分けと、実運用で起きた失敗パターンも後半で扱う。

何が起きるか — 壊れ方は3つ

sessionを跨いだ依頼の流れが壊れるとき、パターンは3つに整理できる。

指示の迷子: 依頼が前のsessionのチャット履歴にだけ存在し、次のsessionは気づかない。気づいた人間が同じことを頼み直し、二重作業になる
完了の記録漏れ: 依頼は届いて作業も終わったのに、終わった記録がどこにも残らない。人間が毎回「あれどうなった」を聞く作業が発生する
経緯の喪失: チャット履歴を整理して消すと、「なぜその方向で直したのか」という判断の文脈ごと消える。同じ判断を後からもう一度やり直す

3つの共通の原因は、依頼の置き場所がsessionの外に用意されていないことである。sessionは終われば文脈ごと消える。だから依頼はsessionより長く生きる場所に置く必要がある — この記事は、その場所を仕組みとして最小に作る話である。

設計 — INBOX.md 1枚

置く場所はリポジトリ直下のINBOX.md 1ファイル、中身は表1枚とする。管理ツールもサーバーも不要で、履歴はファイル自体とgit diffの両方に残る。まずテンプレートを示し、その後に各部の理由を説明する。

# INBOX

## 規律
- session開始時にこの表を確認する
- 依頼・引き継ぎ・訂正は行を追記する (履歴は消さない)
- status は open → done のみ上書きできる
- 秘密情報・顧客情報は書かない

## 依頼
| # | 日時 | from | to | 内容 | status |
|---|------|------|-----|------|--------|
| 1 | 2026-09-06 09:15 | 人間 | agent | build scriptのdry-run結果を報告 | open |
| 2 | 2026-09-06 11:40 | agent | 人間 | CI赤を再実行したが同じtestで落ちる — 要判断 | open |

設計の核は2つの規律である。履歴を消さない (追記のみ) と、上書きしてよい列をstatusの1列に限定する。履歴を消すと訂正の痕跡が消え、「なぜこの構成にしたか」を後から追えなくなる。訂正は元の行を書き換えるのではなく、訂正行を追記する。可変部がstatus 1列に限定されていれば、複数のsessionが同時にこのファイルを触っても衝突が起きる場所が1箇所で済む。

各列の役割は次のとおりである。

#: 採番。訂正や参照は「#2の件」のように番号で指す
日時: 依頼が生じた時刻。後から時系列で読み直せる
from / to: 人間→agent、agent→agent、agent→人間の区別。誰の待ち状態かが分かる
内容: 1行で書ける粒度に切る (失敗パターンで後述)
status: open / done の2値のみ。保留や確認中のような中間値を作らない

運用規律

各sessionは作業開始時に表を確認する — agentの最初の1手順として組み込む
依頼・引き継ぎ・訂正は行を追記する
対応が終わったagentが status を open → done に書き換える (これだけが上書き)
完了の判定は、内容の行に書いた条件で行う
秘密情報・顧客情報・トークン類は書かない (チャットと同じ公開範囲で考える)

規律を5行に絞っているのは意図的である。ルールを増やすと守られなくなり、守られないINBOXは数日で死ぬ。増やしたくなったら、そのルールはIssueトラッカーやコード側に移せるものがないかを先に疑う。

Issueトラッカーとの使い分け

GitHubのIssueやProjectsと役割が被るように見えるが、扱う単位が違う。整理すると次のとおりである。

軸	Issue / Projects	INBOX.md
扱う単位	成果物 (実装・修正・調査)	メッセージ (依頼・報告・引き継ぎ)
ライフサイクル	日〜週単位	sessionを跨ぐ数時間〜数日
履歴の管理	ツールが持つ	ファイルが持つ (git diffも使える)

両方使う運用では、結果の蓄積はIssue、過程の連絡はINBOXに流す。判断の境界は「その行に完了条件を書けるか」である — 完了条件を伴う作業はIssueに切り、次のsessionへの短い伝言はINBOXに置く。Issueを立てるほどでもない一行が、INBOXの1行として存在する場所を作るのが目的である。

失敗パターン

失敗は記録側と運用側の2箇所で起きる。

記録で壊す:

履歴を消して訂正した: 数日後、「なぜこの方向にしたか」が誰にも分からなくなる。訂正は追記が正解
口頭やチャットだけで依頼した: ファイルに書かれない依頼は、頼んだ人しか覚えていない。次のsessionは永遠に見られない
粒度が大きすぎる行: 「諸々整備しておいて」のような行は完了判定が書けず、openのまま残り続ける。1行1作業に切る

運用で壊す:

statusの更新忘れ: doneにしていない行を次のsessionがもう一度拾い、完了済みの作業が二重に走る
確認が人間の側にしかない: 「session開始時に見る」がagentの手順に組み込まれていないと、表は溜まる一方になる
長時間jobの沈黙: CLIが固まって終了しない事故では、行はopenのまま取り残される。これは次節で扱う

crashしたsessionの行を片付ける

agentが作業の途中で死んだとき、その行はopenのまま残る。ここで「邪魔だから消して整理する」をやると、何が途中だったかが分からなくなる。残った行は次のsessionが次の手順で片付ける。

実物を確認する — 作業ディレクトリ・ログ・成果物を見て、依頼された作業が実際に終わっているかを確かめる
完了していれば status を代行で done にし、経緯を1行追記する (「#5 途中で停止していたが成果物は完成済み — 代行クローズ」)
中途なら、どこまで進んだかと何が残っているかを引き継ぎ行として追記し、作業はそこから再開する

open行が増えること自体は失敗ではない。未解決の依頼が見えている状態であり、表から消えて初めて管理不能になる。「openのまま半日以上残っている行がある」は、そのまま異常検知の条件として使える。

導入手順

各リポジトリの直下にINBOX.mdを置き、規律セクションと空の表を書く (上のテンプレートのままでよい)
今浮いている依頼 — 口頭で頼んだもの、チャットの奥に沈んだもの — を1行1作業で書き出す (status は open)
agent側の運用に「session開始時にINBOX.mdを確認する」を組み込む。以降の日常運用は追記とstatus更新だけである

筆者の環境では5つのリポジトリでこの形を回している (観察期間: 2026-09-06時点)。月数十行の追記で収まっており、表は1画面に収まる。行が増えて読みにくくなったら、閉じた行をARCHIVE.mdへ移す — このとき元の表とARCHIVEで採番を引き継ぐと、「#12 (ARCHIVE)」のような相互参照が切れない。

この設計が効く条件

1人1リポジトリなら不要: sessionを跨ぐ伝達がそもそも少なく、チャット履歴で足りる
複数リポジトリ × session並行で初めて効く: 依頼の置き場所がsessionの外に必要になるのはこの状況である
チーム運用なら寄せない: 複数人が触るならIssueトラッカー1本に集約する方が早い。INBOX.mdが効くのは「1人 × agent複数session」という隙間である

複数リポジトリ × AIエージェント運用の業務効率化は、道具を追加するのではなく「依頼がsessionより長く生きる場所」を作ることで先に進む。INBOX.mdはその最小実装である。