AIエージェント同士の非同期メッセージで「未返信」を誤判定しない

複数のPC・複数のアカウントで走るAIエージェント同士が、非同期のメッセージ箱（スプレッドシート・キュー・ファイル） を介して質問と回答をやり取りする構成は珍しくない。この構成には、実際には送信済みなのに「まだ送っていない」と 判定し続けるという固有の壊れ方がある。引き継ぎメモを介して世代をまたいで増殖するため、放置すると 「3セッション連続で未返信」のような、誰も検証していない深刻そうな記述だけが育つ。

この指示書は、その誤判定を起こす4つの仕組みと、着手前に1分で潰す手順をまとめたもの。

---

1. 何が起きるか（実際に起きた形）

引き継ぎメモにこう書かれていた:

未読1件に返信する（<メッセージID> / from=<相手ホスト>）。3セッション連続で未返信。

新しいセッションのエージェントはこれを信じて作業に着手する。だが実際には:

• そのメッセージは返信すべき質問ではなく、バウンス通知だった（相手が受信種別を承諾していない、という自動応答）
• 返信も、別種別での再送も、16時間前にすでに完了していた
• 「未返信」という記述は誰も検証しておらず、世代ごとに回数だけが 2 → 3 と盛られていた

結果として、着手したセッションは存在しない作業を探して時間を溶かす。

---

2. 誤判定を生む4つの仕組み

(a) 受信箱の一覧コマンドが既定で「未読のみ」を返す

export function readInbox(home, { unreadOnly = true } = {}) { ... }

一覧コマンドを叩いて無出力だったとき、人もAIも「メッセージが無い」と読む。 実際の意味は「未読のものが無い」＝全部既読フラグが立っている、かもしれない。 既読化 (--ack) は返信とは別操作なので、既読だが未返信も、既読で返信済みも、 どちらも同じ「無出力」に見える。

原則: 一覧コマンドの無出力を「空」と読まない。受信箱の実体ディレクトリを直接 ls して、 個々のファイルの readAt / resultAt を見る。

(b) 送信系コマンドが設定未投入時に「何もせず exit 0」

const config = envFile(path.join(dir, 'fleet-sheet.env'));
if (!config.URL || !config.TOKEN) { err('設定未投入のためスキップ'); return 0; }

設定ファイルが無いPCでバッチが落ちないように、との親切な設計。だが呼び出し側から見ると 「送信成功」と「1バイトも送っていない」が同じ exit 0 になる。 警告は stderr にしか出ないので、パイプや自動化の中では消える。

原則: 終了コードを送信の証拠にしない。行為ログに記録が載ったかで判定する。

(c) 「受信箱の状態」と「自分の行為の記録」が別ファイルにある

受信箱（＝相手から来たものの状態）を見ても、自分が返信を送ったかどうかは分からない。 返信は送信ログ側に action: "reply" として残る。引き継ぎを書いたエージェントは 受信箱しか見ず、そこから「まだ返していない」を推測して書いていた。

原則: 状態（inbox）と行為（send log）は別物。完了判定は必ず行為ログで行う。

(d) バウンス通知を「返信すべき質問」と読み違える

相手が受信を承諾していない場合、システムは自動で

未オプトイン。承諾コマンド: node -e "..."

のような案内メッセージを返す。これは受信箱に普通のメッセージとして積まれるため、 「相手から来た未処理のメッセージ＝返信しろ」と誤読される。バウンスに返信しても何も起きない。

原則: 受信箱のメッセージは replyTo / kind / 本文の性質を見て、 質問・回答・バウンスの3種に仕分けてから扱う。

---

3. 着手前にやる1分の検証

引き継ぎに「未返信」「未処理」「N回連続」と書かれていたら、作業に入る前にこの順で引く。

# 1. 行為ログ: 自分は本当に送っていないのか（最重要・これだけで大半は決着する）
tail -10 <送信ログのパス>          # action:"sent" / "reply" と id を探す

# 2. 受信箱の実体: 一覧コマンドではなくディレクトリを直接見る
ls -la <受信箱ディレクトリ>
cat <受信箱ディレクトリ>/<メッセージID>.json   # replyTo / readAt / resultAt / status / expiresAt

# 3. 未着の回答が無いか（副作用の無い形で）
<CLI> --poll --dry-run --json      # [] なら相手からの新着は無い

判定表:

行為ログ	受信箱	結論
action:"reply" に該当 id あり	—	完了済み。着手不要。
記録なし	replyTo が自分の送信 id	相手からの回答またはバウンス。中身を読んで仕分ける
記録なし	replyTo なし・readAt なし	本当の未返信。 ここで初めて作業に入る

---

4. 作る側の設計チェックリスト

同じ仕組みを自分で作るなら、次を満たすと誤判定が構造的に起きにくい。

• 送信は「試行」と「成功」を別レコードで残す。試行を先に書けば、通信が不確実に終わっても 同じ id を調べ直せる（新しい id での無条件再送を防ぐ）。
• 一覧コマンドに未読フィルタの有無を明示するフラグを付け、既定値を --help に書く。 無出力時は (未読 0 件 / 全 N 件) のように母数を出す。これだけで (a) は消える。
• 設定未投入のスキップは exit 0 以外（例: 3）にするか、最低でも stdout に SKIPPED: ... を出す。「静かに成功に見える」を作らない。
• バウンス・自動応答には kind: "bounce" のような機械可読な種別を付ける。 本文の日本語を読ませて判別させない。
• メッセージに expiresAt を持たせ、期限切れは期限切れとして表示する。 期限切れを「未返信」と同じ扱いにしない。

---

5. 安全側の線引き（AIに代行させないこと）

バウンスが「受信側で承諾コマンドを実行せよ」と案内してくる場合、それは 相手側の人間が下す同意であって、エージェントが代わりに実行してよいものではない。 自分のPC上のローカルな確認ダイアログと、他アカウント・他PCの安全機構の解除は別の話。

• やってよい: 承諾の要らない種別（通知・note 相当）で送り直す
• やってはいけない: 相手PCの承諾ファイルを書き換える / 相手に代わって承諾する / 「承諾すれば早い」と言って人に解除を促す

また、相手が答えないことは自分側の未完了ではない。 新しい id での再送は重複配達になるので、期限を記録して閉じ、再送するかどうかは人の判断に上げる。

---

6. まとめ（3行）

1. 「未返信」は行為ログで検証する。受信箱を見て推測した「未返信」は信用しない。
2. 一覧コマンドの無出力は「空」ではない。exit 0 は送信の証拠ではない。
3. 受信箱のメッセージは質問・回答・バウンスに仕分けてから扱う。バウンスに返信しても何も起きない。