エージェントを使った作業のための二つの状態機械

複数エージェントの作業にはプロンプトだけでは足りない。エージェントの運用状態とタスクの意味上の状態を分ける実践的な見取り図を、herdr と tmux-a2a-postman から考える。

1. なぜ一つの状態では足りないのか

エージェントを複数動かすとき、最初に崩れやすいのは「状態」を一つにまとめてしまうことだ。ターミナルのペイン、メールボックスの一通、チェックリストの一項目は、遠目にはどれも進捗に見える。

エージェント側の状態がある。どのプロセスが存在するか、どのペインが動いているか、どのエージェントが詰まっているか、どのメッセージが未読か、どの返信がまだ必須か、どのセッションに再接続できるか、という状態である。

一方で、タスク側の状態もある。何を依頼したか、何が変更されたか、何を検証したか、誰が承認したか、どの不確実性が残っているか、その結果を完了と数えてよいか、という状態である。

この二つは触れ合うが、同じ層ではない。メッセージが届いていても、タスクはまだ間違っているかもしれない。ペインのプロセスが生きていても、エージェントは詰まっているかもしれない。返信が配送上の依頼を満たしても、完了主張にはまだ根拠が足りないかもしれない。

これからのエージェント用の道具は、まずエージェントの運用状態を扱う状態機械を持ち、その上にタスクの意味を扱う状態機械を重ねる方向へ向かうと思う。一つ目は作業を失わせない。二つ目は、その作業を完了と数えてよいかを決める。

この記事は、「なぜ複数エージェントなのか」 と 「tmux は生き残るが、見える形は消える」 の次に置く。次の記事では 「個人用コンピューターの中の会社」 を扱う。

2. 第一の状態機械: エージェント運用

第一の状態機械は、運用上の問いに答える。ここではまだ品質を問わない。エージェントシステムが作業を手元に保っているかを問う。

• エージェントのプロセスは生きているか
• 状態名は working、blocked、done、idle、unknown のどれか
• セッションに再接続できるか
• どのペインがターミナルプロセスを所有しているか
• どの役割に未読メールがあるか
• どの必須返信がまだ開いたままか
• メッセージは dead-letter の経路に入ったか

herdr と tmux-a2a-postman は、この層の別々の部分を扱っている。見せる根拠は違うが、層は同じである。

herdr の 概念ドキュメント は、実際のターミナルプロセスを中心に作業空間、タブ、ペインのモデルを定義している。ペインの中のエージェントを認識し、blocked、working、done、idle、unknown などの状態名を追跡する。セッション状態ドキュメント はさらに、生きたままの永続化、スナップショット復元、ペイン履歴の再生、エージェントセッションの復元、生きたままの引き継ぎを分けている。何が残り、何を復元でき、操作者がどの根拠を信頼できるかを扱う運用状態のモデルである。

tmux-a2a-postman は、よりメッセージ中心の経路を取る。設計上は、initial、ready、waiting、pending、stale などのノード状態を扱う。配送上の識別階層は意図的に狭い。メッセージ、スレッド、入力依頼である。返信必須のメッセージは正確な input_request_id を開く。その依頼を解決する返信が、同じ依頼を満たす。projection という状態投影は、ターミナル履歴から人間に推測させずに、ノードに受信作業がある、あるいは誰かを待っている、と言える。

どちらも運用状態の状態機械である。タスクが正しいことは証明しない。しかし、正しさを確認する前に作業そのものを失うことを難しくする。実務上、これは大きい。見えなくなった責務はレビューできない。

3. postman はメッセージ経路の状態機械である

postman のよい設計は、メールボックスが作業全体であるかのように装わないことだ。配送を記録するが、配送を受理に膨らませない。

README は postman を薄い調整層と説明している。役割と辺を postman.md に置き、tmux ペイン間でローカルメールを配送し、アーカイブを保存し、返信必須の枠を追跡し、状態を報告し、dead-letter という配送不能レーンを見える状態に保つ。中心にあるのはメッセージの経路である。send-heredoc、pop、配送、返信の流れ、dead-letter 処理がその中核になる。

この境界が主張を誠実に保っている。

別の言い方をすれば、postman は責務台帳である。メッセージの価値は、文面が動いたことだけではない。役割の間に責務を開き、満たし、あるいは満たせなかったことを残すからである。だから配送上の終了とタスクの受理は、別々の出来事であり続けなければならない。

postman はこう言える。

• このメッセージは送信された
• この受信者は返信しなければならなかった
• この正確な入力依頼は満たされた
• このノードにはまだ受信側の必須作業がある
• このノードは誰かを待っている
• この配送は失敗し、dead-letter に入った

postman だけで言うべきではないこともある。

• 実装は正しい
• 記事はよい
• レビュー担当は根拠を理解した
• タスクは意味上も完了した

後者は次の層に属する。

この区別があるから、“DONE” だけでは足りない。返信は配送の往復を閉じられる。しかし、それだけでタスクを閉じるべきではない。完了には成果物、チェックリストの状態、根拠、検証、残っている阻害要因が必要である。それがなければ、“DONE” は届いたメッセージでしかない。

4. 第二の状態機械: タスクの意味

第二の状態機械は、意味上の問いに答える。ここでシステムは、作業が動いたかではなく、その動きが依頼を満たしたかを問う。

• 元の依頼は何か
• どのチェック項目が通らなければならないか
• 正本となる成果物はどれか
• 完了を支える根拠は何か
• 根拠はレビューされたか
• 結果は accepted、rejected、blocked、still under revision のどれか

ここでループ設計が実体を持ち始める。

以前の英語記事 From Prompt Engineering to Loop Engineering で、私はプロンプト、文脈、実行基盤、ループ設計が階段を作ると書いた。プロンプトはメッセージをうまく述べる。文脈は読み手に正しい事実を渡す。実行基盤はメッセージを正しい処理へ届ける。ループ設計は、作業が実際に起きたことを証明する。

二つの状態機械という見方は、同じ考えの次の形である。ループはメッセージをエージェントに届けるだけでは足りない。引き継ぎを越えて作業の意味を保たなければならない。

第一の状態機械は、ほぼ実行基盤と運用状態である。エージェント、ペイン、メール、セッション、生存状態、復旧可能性を扱う。

第二の状態機械はタスク状態である。依頼された作業、根拠、レビュー、受理、却下、未解決の残りを扱う。

この二つを混同すると、システムは脆くなる。分けておくと、検査できるシステムになる。一方の層が作業は生きていると言い、もう一方の層が結果を却下できる。

5. herdr と postman は異なる境界を指している

herdr の公式ドキュメントは、強いターミナル実行基盤の境界を示している。サーバーがペインとプロセス状態を所有し、クライアントがそこへ接続する。socket API により、道具は作業空間、タブ、ペイン、エージェントを点検し制御できる。連携機能は、対応するエージェント CLI のセッション識別子やライフサイクル状態を報告できる。プラグインは Herdr CLI や socket API へコールバックすることで作業の流れを拡張する。

これは豊かな運用基盤である。エージェントに永続して走る場所を与え、操作者に検査できる具体的な状態を与える。

postman は、より薄い配送境界を示している。モデルセッションを所有しない。完全な作業エンジンになろうとしない。メール、返信責務、アーカイブ、状態の投影を、どれか一つのエージェントの文脈枠の外側に保つ。

この違いが層を見える状態に保つ。未来は、すべての道具が同じ製品になることを必要としない。必要なのは明確な層分けである。

• ターミナルとセッションの基盤
• エージェントの運用状態
• メッセージと引き継ぎの状態
• タスクの意味上の状態
• 承認と信頼境界の状態
• 人間が読む要約

いくつかの製品は層をまとめるだろう。いくつかのローカルシステムは小さな道具を組み合わせるだろう。ブランドの境界より、どの状態が長く残るかを見るほうがよい。薄い層でも、消えやすい責務を所有するなら決定的な役割を持てる。

このため、予測の中では Claude Code と Codex がますます差し替え可能に見えてくる。実行エンジンとしての違いはあってよい。しかし運用状態とタスク状態は、そのどちらか一つの中に閉じ込められるべきではない。

その永続する場所は、人間の現在地から遠くにあるかもしれない。tmux はサーバー上で動かせる。herdr の公式モデルも、ターミナル作業空間を、クライアントが切り離し、再接続できるサーバー支えの実行基盤として扱う。非公開ネットワークはこの型を強くする。状態機械は作業のそばに残り、人間はブラウザ、スマートフォン、SSH 経由の接続、レビュー面からそこへ届く。

6. 遠隔アクセスはどこに入るか

スマートフォンからのアクセスは、単なる便利機能ではない。状態モデルへの負荷試験である。小さい画面は、人間がすべてのペインを覚えていられるという幻想を消す。

人間がターミナルの前にいるとき、システムは弱い状態管理でもごまかせる。人間が手で全部点検できるからだ。人間がスマートフォン上にいると、その前提は崩れる。システムは何を見せるべきかを知っていなければならない。

具体的な Telegram と Tailscale の根拠は 「tmux は生き残るが、見える形は消える」 で扱った。状態機械上の論点はもっと狭い。SSH、スマートフォン、ブラウザ、非公開ネットワーク上のレビュー面を経由して承認と点検が行われるようになると、システムはペインに関する人間の記憶に頼れない。責務の状態をシステム自身が運ばなければならない。

スマートフォンからのアクセスは状態機械の必要性を消さない。それを露出させる。

7. タスク層は何を保存すべきか

第二の状態機械は、最初から重くある必要はない。チェックリスト付きの永続的なタスク成果物として始めればよい。地味に見えるが、その地味さが効く。記録は、洗練される前に、まずモデル応答を越えて残らなければならない。

最低限有用な記録は、意図的に素朴でよい。

• 元の依頼
• 受け入れチェックリスト
• 有効な成果物のパス
• 判断と調査結果
• 根拠ログ
• 検証コマンド
• 阻害要因
• 完了判断

これで文脈圧縮、エージェント間の引き継ぎ、レビューを越えられる。また、「返信済み」と「作業受理済み」の違いを具体的にできる。

時間が経つにつれ、この多くは構造化される。レビュー判断は記録になる。承認は記録になる。エージェントの正しい完了履歴は問い合わせ可能な事実になる。監査は状態遷移になる。根拠のない完了は、弱い段落ではなく、根拠のない完了主張として扱われる。

それが第二段階の状態機械である。受理を文章ではなく、検査できる状態に変える。

8. 予測

第一段階はすでにここにある。herdr、tmux、postman、ターミナルペイン、状態の投影、セッション復元、メールボックスのアーカイブは、どれも同じ主題の変奏だ。エージェントの運用状態は、どれか一つのモデル応答より長く生きなければならない。

第二段階はまだ固まっていないが、方向は見えている。タスク状態も、どれか一つのモデル応答より長く生きなければならない。何が依頼され、何が確認され、誰が受け入れ、何が未解決のままかを知らなければならない。

エージェントを使った未来の作業環境は、単によりよいターミナルではない。二つの状態機械を積み重ねたものだ。

• 一つはエージェントの運用状態のため
• もう一つはタスクの意味上の状態のため

人間がターミナル履歴からそのどちらかを再構成する必要はなくなるべきだ。