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はその最小実装である。