# AIエージェント同士の非同期メッセージで「未返信」を誤判定しない 複数のPC・複数のアカウントで走るAIエージェント同士が、非同期のメッセージ箱（スプレッドシート・キュー・ファイル） を介して質問と回答をやり取りする構成は珍しくない。この構成には、**実際には送信済みなのに「まだ送っていない」と 判定し続ける**という固有の壊れ方がある。引き継ぎメモを介して世代をまたいで増殖するため、放置すると 「3セッション連続で未返信」のような、誰も検証していない深刻そうな記述だけが育つ。 この指示書は、その誤判定を起こす4つの仕組みと、着手前に1分で潰す手順をまとめたもの。 --- ## 1. 何が起きるか（実際に起きた形） 引き継ぎメモにこう書かれていた: > **未読1件に返信する**（`<メッセージID>` / from=`<相手ホスト>`）。**3セッション連続で未返信。** 新しいセッションのエージェントはこれを信じて作業に着手する。だが実際には: - そのメッセージは**返信すべき質問ではなく、バウンス通知**だった（相手が受信種別を承諾していない、という自動応答） - **返信も、別種別での再送も、16時間前にすでに完了していた** - 「未返信」という記述は誰も検証しておらず、世代ごとに回数だけが 2 → 3 と盛られていた 結果として、着手したセッションは**存在しない作業**を探して時間を溶かす。 --- ## 2. 誤判定を生む4つの仕組み ### (a) 受信箱の一覧コマンドが既定で「未読のみ」を返す ```js export function readInbox(home, { unreadOnly = true } = {}) { ... } ``` 一覧コマンドを叩いて**無出力**だったとき、人もAIも「メッセージが無い」と読む。 実際の意味は「**未読のものが無い**」＝全部既読フラグが立っている、かもしれない。 既読化 (`--ack`) は返信とは別操作なので、**既読だが未返信**も、**既読で返信済み**も、 どちらも同じ「無出力」に見える。 > **原則**: 一覧コマンドの無出力を「空」と読まない。受信箱の実体ディレクトリを直接 `ls` して、 > 個々のファイルの `readAt` / `resultAt` を見る。 ### (b) 送信系コマンドが設定未投入時に「何もせず exit 0」 ```js 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回連続」と書かれていたら、作業に入る前にこの順で引く。 ```bash # 1. 行為ログ: 自分は本当に送っていないのか（最重要・これだけで大半は決着する） tail -10 <送信ログのパス> # action:"sent" / "reply" と id を探す # 2. 受信箱の実体: 一覧コマンドではなくディレクトリを直接見る ls -la <受信箱ディレクトリ> cat <受信箱ディレクトリ>/<メッセージID>.json # replyTo / readAt / resultAt / status / expiresAt # 3. 未着の回答が無いか（副作用の無い形で） --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. 受信箱のメッセージは**質問・回答・バウンス**に仕分けてから扱う。バウンスに返信しても何も起きない。 ---