サブエージェントのOoO/スペキュレーション（Superscalar）＋エージェント間A2Aライブボード（Constellation）— AIコーディング向けマルチエージェント運用モジュール2種

 (github.com/SoliEstre)
1 ポイント 投稿者 soliestre 10 시간 전 | まだコメントはありません。 | WhatsAppで共有

前回の投稿で紹介したEstreGenesisが、2.0〜2.3にかけて2つの大きなモジュールを追加しました。
どちらも、AIコーディングエージェントのマルチ運用を一段上へ引き上げる試みです。

Constellation — エージェントの会話ウィンドウ間のリアルタイム通信（A2A WebSocketライブボード）

従来のサブエージェントという概念は親子モデルで、mainエージェントが子を作成（spawn）し、子の結果を受け取る一方向の構造でした。ほかのエージェントの会話ウィンドウと直接通信することはありませんでした。

Constellationは、その境界を破ります。

  • A2A（Agent-to-Agent）WebSocketブリッジ — 各エージェント（Claude Code・Codex・Cursorなど）が自分のIDEセッションをそのまま維持したまま、別個のデーモンプロセスがWebSocketライブボードに接続し、ほかのエージェントの会話ウィンドウへメッセージを送ります。親子従属ではなく、*対等ノード間（peer-to-peer）*のモデルです。（実運用テストはClaude/Codexまで確認済み。運用時は各エージェントの自動承認モード（AutoMode）が必須。）
  • 役割分離 — main（オーケストレーターPM） / local（ワーカー） / upstream（Hermes Agentのような自律エージェントpeer） / collab（外部協業者peer）。mainがworkerへDelegate（委任）を送ると、workerは自分のIDEで即時実行し、WorkerReport（報告）で返信します。
  • ターンベースのエージェント対応 — Claude Codeのように、ターン（turn）が終わると会話が終了するランタイム向けのパターンです。ブリッジデーモン（ファイルIO inbox/outbox）がメッセージを受け取り、self-wake watcher（自動起動ウォッチャー）がメッセージ到着時に次のターンを開始します。シェルセッションから分離された状態（detached）でバックグラウンド常駐が可能です。
  • ダッシュボード — すべてのエージェントの作業・メッセージ・状態を1画面で確認できます。ボードだけを見ても流れを再構成できます。

Constellation.md と constellation/*.eux コンポーネントspecとして含まれており、
非公開ランタイムのダウンロードがなくても、本文にプロトコル全体が整理されています。

Superscalar — プロセッサアーキテクチャをエージェント実行に導入

本日（5/29）発表されたClaude Opus 4.8のultracodeは、大量のサブエージェント運用を前提としています。
それを本当に効率的にするには、*どのタスクを同時にいくつ起動するか（dispatch）*を決めるスケジューリングが必要です。
Superscalarは、1960〜80年代のCPUアーキテクチャがすでに解いていた問題、すなわち 複数命令の同時実行（multi-issue / superscalar）・依存関係が満たされれば順序を無視して実行するout-of-order（OoO）・分岐結果を予測して実行するspeculation を、そのままエージェントのタスクスケジューリングに導入します。

  • issue_width の正式な5次元 — ある時点で同時に起動するsub-agentの数を、5つの制約の最小値で決定します。
    1. Anthropicが提示したタスク難易度ごとのeffort band（作業規模の推定）
    2. pace_mode（Cautious・Proactive・Burst・Sprint実行速度モード）の上限
    3. Little's Law throughput（待ち行列理論 — PMレビュー速度 ÷ 平均タスク長）
    4. KanbanのWIP上限（一度に進行中の作業数 ≈ チーム規模 + 1）
    5. autonomy_available_workers（自動承認モードが有効なワーカー数 — そうでないワーカーは動作のたびにユーザー権限のダイアログが出るため、throughputが崩壊）
  • OoO実行 + 結果順序保証（Tomasulo・ROBパターン） — 依存関係さえ満たされればdeclared order（宣言された順序）を無視し、ready taskから実行します。ただしPMが結果を*元の順序どおりにretire（統合完了）*するため、ユーザーからはdeclared orderどおりに見えます。1988年のSmith-Pleszkun Reorder Buffer論文のパターンそのままです。
  • Speculation（opt-in、Spectreの教訓を応用） — 2段階のannounce + ack: 「consider X」→ ユーザーack → 「execute X (speculative lane)」→ 予測が外れた場合はworktree（作業用分離フォルダ）を丸ごと破棄。トヨタのアンドン（Andon、Jidoka可視化）の3要素を強制します — 視覚信号・緊急停止cord・誤答の振り返りログ。
  • Cost-benefit gate — 約30〜60kトークンのhorizon crossoverで、spawn（生成）オーバーヘッド < 並列化の利得となる時点を自動判定します。小さな作業は自然にinlineへ落ちます。

deep researchの3軸（プロセッサアーキテクチャの学術的canon / エージェントハーネスの産業事例 / 作業コミュニケーション・経営学）で検証されており、
Superscalar.md 本文およびStage 1の自前テスト（dogfooding）ログ（§11）で補強されています。

基盤 — 自律実行の絶対原則

上記2つのモジュールは、自律運用を前提としています。
「ユーザー確認待ちで処理量が崩壊する」のであれば、どちらにも意味がありません。
そのためEstreGenesis 2.3では、次を絶対原則として明文化しました。

すでに決まっている次のステップ（Phase順序・planned（予定）トラック・blocked（ブロック）解除分・in-order retire（順次完了）キュー）は確認せずに進め、
ユーザーゲートは次の4つだけです。

  1. 損失または外部公開（push・deploy・send・delete）
  2. 新たな重大な分岐の意思決定時点（RRP/設計決定段階。ただし、その結果として決まったPhase A/B/Cの実行は決定済みの実行）
  3. 再起動が必要なdeployのタイミング調整（適用自体は自律、再起動の時点だけ調整）
  4. 明示的なユーザーsteering（ユーザーが直接方向転換を指示）

「Phase Aを開始しますか？」のように、すでに決定済みの実行を再度確認するパターンは自律運用違反と位置づけられており、
6種類のシードに中核原則として明文化され、ダウンストリーム（シード適用プロジェクト）が自力で自律運用を強制できるようになっています。

ブートストラップシード v2.0+ に統合

EstreGenesisはハーネスブートストラップ・シードプロンプトライブラリであり、
Master/Lite/Compactの3 tier × EN/KOの6ファイルを新規プロジェクトにコピーして、
ブートストラップインタビュー + AGENTS.md 自動生成を行います。
v2.0（Constellation）・v2.3（Superscalar）モジュールも6種類のシードすべてに統合されており、
シードをコピーするだけで2つのモジュール + 自律実行原則がすべて含まれます。

  • Master: 中核原則 #12（Constellation） + #13（Superscalar） + #14（自律実行）の全文 + § Constellation + § Execution Scheduling
  • Lite/Compact: 同じ原則の圧縮版 + 中核 §
  • すべてのtierで、grepで検証可能な一貫した自律運用の強制

GitHub: https://github.com/SoliEstre/EstreGenesis

モジュール本文:
Constellation.md
Superscalar.md

Changelog: CHANGELOG.md

関連記事

まだコメントはありません。

まだコメントはありません。