state-management

状態管理

マルチエージェントシステムにおいて、状態とは、これまでに起きたこと、現在進行中のこと、決定されたことについての共有された事実です。状態管理がなければ、エージェントは古くなった情報や矛盾する情報に基づいて動作し、繰り返し質問されること、矛盾した回答、進捗の喪失という代償をユーザーが払うことになります。

状態管理は、マルチエージェント設計における配管のようなスキルです。ここを間違えると、このプラグインのほかのすべてのスキルが難しくなります。

状態の種類

• タスク状態：タスク全体がライフサイクルのどの段階にあるか。どのサブタスクが完了、進行中、保留中か。
• コンテキスト状態：各エージェントが何を知っているか。何が共有、要約、破棄されたか。
• ユーザー状態：好み、履歴、現在の感情状態。
• 意思決定状態：下された決定、検討された選択肢、却下された選択肢（およびその理由）。
• エラー状態：何が失敗し、再試行され、エスカレーションされたか。

状態アーキテクチャのパターン

• 集中型状態：すべてのエージェントが読み書きする、単一の共有ストア。シンプルで、デバッグしやすい一方、大規模化するとボトルネックになるリスクがあります。
• 分散型状態：各エージェントが独自の状態を保持し、ほかのエージェントと同期します。柔軟ですが、一貫性に関するリスクがあります。
• イベントソーシング型状態：イベントのログから状態を構築します。すべての変更が記録され、監査可能ですが、複雑です。
• ブラックボードパターン：エージェントが結果を投稿し、ほかのエージェントの貢献を読み取る共有ワークスペースです。協調的な問題解決に適しています。

ユーザー向けの状態設計

ユーザーは、システムが何を記憶するかについて期待を持っています。

• セッション内状態：この会話で話されたことはすべて、一貫して保持される必要があります
• セッションをまたぐ状態：過去のセッションでの好み、決定、コンテキストが引き継がれる必要があります
• エージェントをまたぐ状態：あるエージェントが何かを学んだら、ほかのエージェントもそれを知る必要があります
• ユーザーが制御する状態：システムが記憶している内容を、ユーザーが確認、編集、消去できる必要があります

意思決定のルール

• まずは集中型状態を選びます。 分散型を選ぶのは、測定の結果、エージェント間のレイテンシーが本当にボトルネックだと分かった場合に限ります。多くのチームは時期尚早に分散型を選び、いつまでも一貫性のバグに悩まされます。
• ある状態が単一のエージェントの作業メモリにしか存在しないなら、失われたものとして扱います。 モデルの呼び出しをまたぐメモリは信頼できません。保持が必要なものはすべて共有ストアに移してください。
• セッションをまたぐ状態は、カテゴリごとに明示的な同意が必要です。 「好みを記憶する」≠「話し合った内容を記憶する」です。粒度は、あると望ましい程度のものではなく、設計上の制約です。
• 状態の競合では、暗黙のマージより検出を優先します。 表面化した競合は、ユーザーが解決すれば復旧できます。暗黙にマージされた不整合は、見えないまま損害を生みます。
• ユーザーに見えない状態は、信頼されません。 動作のパーソナライズに使われる状態はすべて、ユーザーがUIを操作して約30秒以内に見つけられる場所で確認できるようにする必要があります。

アンチパターン

• 古いコンテキストのバグ：エージェントが、別のエージェントによって更新された状態に基づいて動作します。エージェント単体では正しく見えるため、検出が困難です。読み取りごとにバージョンを付けることで軽減できます。
• 単一の信頼できる情報源をめぐる争い：2つのエージェントが、同じ状態の一部分について、どちらも自分が管理者だと主張します。解決ルールは曖昧で、断続的に後から書き込まれた値が優先されます。
• 暗黙の状態：状態が共有ストアではなく、エージェントのプロンプトコンテキストに存在します。再起動で失われ、引き継ぎもデバッグもできません。
• 状態の肥大化：機能が増えるにつれて、スキーマが際限なく拡大します。半年もすると、何が使われているのか、何が不要なのか、何が重要な基盤なのか、誰にも分からなくなります。
• 同期の先送り：効率化のために書き込みをバッチ処理した結果、失敗時に書き込みが失われます。ユーザーには「保存済み」と表示されても、状態は実際には保存されていません。
• 見えないパーソナライズ：ユーザーが確認も上書きもできない状態が動作に影響し、操作や誘導へと傾いていきます。

これを使用しない場合

• 単一エージェントのプロダクト — モデルのコンテキストウィンドウがそのまま状態です。代わりにcontext-window-designを参照してください。
• ステートレスなトランザクション機能（単発の補完、画像生成の呼び出し）— 明示的な状態アーキテクチャは、メリットがないままオーバーヘッドを増やします。
• プロトタイプ段階 — 状態アーキテクチャを早期に設計すると、まだ柔軟にしておくべき選択肢が固定されてしまいます。可能な限りシンプルなストアを使用し、決定事項はdecision-stateのみに記録してください。

関連項目

• handoff-protocols — エージェント間のコンテキスト転送では状態アーキテクチャを使用するため、併せて設計してください。
• observability-design — 状態変更は最も有用なトレースです。何を保存するかと同時に、何をログに記録するかを設計してください。
• consent-and-agency — セッションやエージェントをまたぐ状態には、原則として同意が関わります。
• task-decomposition — タスク状態のスキーマは分解の形によって決まるため、共同で設計してください。

設計成果物

• 状態アーキテクチャ図（集中型／分散型／イベントソーシング／ブラックボード）
• 状態スキーマの定義（何を、どこに、誰が、どのTTLで保存するか）
• 状態ライフサイクルの仕様（作成、更新、アーカイブ、削除）
• 状態の各スライスに対する競合解決ルール
• ユーザー向けの状態の可視性と制御の設計

実例 — マルチエージェントのカスタマーサポートフローにおけるタスク状態：

{
  "task_id": "tk_8b2",
  "owner_agent": "router",                  // who currently holds the task
  "status": "in_progress | escalated | done",
  "subtasks": [
    {"id": "verify_account", "status": "done", "result_ref": "ctx_a91"},
    {"id": "check_refund_eligibility", "status": "in_progress", "owner": "billing_agent"}
  ],
  "user_state_ref": "us_482",               // pointer, not embedded copy
  "decisions": [
    {"at": "...", "by": "router", "choice": "billing_agent", "rejected": ["faq_agent"], "why": "intent: refund"}
  ],
  "errors": [],
  "version": 7                              // increments on every write; readers check before acting
}

バージョンフィールドは、古いコンテキストに起因するバグを防ぐ最もシンプルな手段です。rejectedを含むdecisionsログにより、インシデントレビューの際、人間がルーティングの内容を把握しやすくなります。

マルチエージェントシステムにおける共有メンタルモデルの研究と、分散システムの一貫性に関する文献（論理時計に関するLamportの研究、分離された状態に関するアクターモデル）を参考にしています。