Skip to content

サブエージェント委譲に model × effort × role の明示的ルーティングを導入する #868

Open
Open
サブエージェント委譲に model × effort × role の明示的ルーティングを導入する#868
Labels
area:workflowenhancementNew feature or requestpriority:P1P1: 次 milestone 候補

Description

@s977043
s977043
opened on Jul 18, 2026

背景

以下の投稿で紹介されている、上位モデルをメインの実行者ではなくオーケストレータとして使い、サブタスクごとに 実行モデル・reasoning effort・役割 を明示して委譲する考え方を、PlanGate のサブエージェント運用へ適用できるか検討する。

投稿の本質は、単にサブエージェントを並列起動することではない。

  • 上位モデルは計画、分解、ルーティング、昇格判断へ集中させる
  • 定型処理・大量処理は軽量モデルへ委譲する
  • 高リスク判断・難しい実装・最終検証のみ上位モデルへ昇格する
  • 委譲時にモデルと effort を暗黙継承させず、選定理由とともに明示する
  • 実行者と検証者を必要に応じて分離する

既存実装との重複確認

PlanGate には、すでに以下が存在する。

  • docs/ai/subagent-delegation/
    • 会話履歴を持たないサブエージェントへの自己完結した派遣プロンプト
    • 必須8要素
    • OUTCOME 契約
    • P0/P1/P2 の要判断事項
    • 行動規範
  • plugin/plangate/skills/subagent-dispatch
    • high-risk / critical での依存グラフ生成、並列 dispatch、ファイル受け渡し
  • subagent-driven-development
    • Implementer → Spec Reviewer → Quality Reviewer の分離
  • docs/ai/model-profiles.md / model-profiles.yaml
    • mode × model profile × reasoning effort
    • context budget / tool policy / validation bias / retry strategy
    • supports_parallel_subagents
  • workflow-conductor / orchestrator mode
    • オーケストレータ責務と Gate 境界

また、完了済み Issue #710 で「なぜこのモデルに格上げされたか」は派遣プロンプト必須要素として導入済み。

したがって、本 Issue では新しい委譲機構を別に作らず、既存の委譲契約・Model Profile・Trust Ledger / 実行ログを接続し、ルーティング判断を構造化する差分に限定する。

現状のギャップ仮説

既存仕様にはモデル振り分けと委譲理由が存在するが、以下が一つの構造化された契約として接続されていない可能性がある。

  1. サブタスク単位の role
  2. 選択した model_profile
  3. 選択した reasoning_effort
  4. 選択理由・リスク根拠
  5. 実行可能な tools / write scope
  6. 実行者と verifier の分離要否
  7. 下位モデルから上位モデルへの昇格条件
  8. 実績値（再試行、失敗、コスト、昇格結果）

暗黙継承のままだと、以下の問題が起こり得る。

  • オーケストレータと全サブエージェントが同じ高コストモデルになる
  • 定型処理に過剰な reasoning effort を使う
  • high-risk / critical を軽量モデルへ誤配分する
  • 調査エージェントへ不要な write 権限を渡す
  • 実装者と検証者が同一モデル・同一文脈になり、独立検証が弱くなる
  • モデル昇格の効果を後から評価できない

目的

PlanGate のサブエージェント委譲において、タスクごとのルーティング判断を次の形で再現可能・監査可能にする。

routing = role × model_profile × reasoning_effort × tools × validation × budget

検討方針

1. ルーティング契約を定義する

派遣時に最低限、以下を構造化して持つ。

routing_decision:
  role: implementer
  model_profile: gpt-5_5
  reasoning_effort: medium
  task_mode: standard

  tool_policy: narrow
  write_scope:
    - src/**
    - tests/**

  verifier:
    required: true
    role: quality_reviewer
    model_profile: gpt-5_5_pro
    reasoning_effort: high

  reasons:
    - multi_file_change
    - architecture_impact

  escalation:
    from_profile: null
    trigger: null

既存の model-profiles.yaml と重複する値は再定義せず、参照または profile 解決後の実効値として扱う。

2. オーケストレータの判断責務を明示する

オーケストレータは実作業を行わず、以下を担当する。

  • タスクの難度・リスク・不確実性の分類
  • サブタスクへの分解
  • role の決定
  • model profile / effort の決定
  • tools / write scope の制限
  • verifier の必要性判断
  • 実行結果に応じた昇格判断

3. デフォルト継承と明示指定の境界を決める

すべてを毎回手書きすると運用コストが高いため、以下を検討する。

  • ultra-light / light は mode 由来の既定値を許容
  • standard 以上、write あり、review=true、high-risk / critical は明示指定を必須化
  • 親モデルの暗黙継承を許可する条件を限定する
  • critical で未対応・unknown profile の場合は fail closed または human escalation

4. 実行者と検証者の分離ルールを定義する

以下では verifier 分離を原則とする。

  • high-risk / critical
  • セキュリティ
  • 破壊的変更
  • アーキテクチャ変更
  • 後方互換性に影響する変更
  • 要件の曖昧さが高い変更
  • 実装者が複数回失敗した変更

同じ model profile を使う場合でも、別セッション・別コンテキストで独立レビューする。

5. 昇格条件を定義する

下位または標準 profile から上位 profile / effort へ昇格する代表条件を定義する。

  • missing_context が解消できない
  • 設計候補が複数あり trade-off 判断が必要
  • テスト失敗が retry 上限を超えた
  • security / destructive / compatibility risk を検出
  • verifier が needs_review / failure
  • task mode が途中で high-risk / critical 相当に変化

単純な retry とモデル昇格を混同しない。

6. Trust Ledger / 実行ログへ記録する

最低限、以下を記録候補とする。

  • requested / resolved model profile
  • reasoning effort
  • role
  • task mode
  • routing reason
  • verifier profile
  • retry count
  • escalation count / reason
  • outcome
  • human intervention
  • 公開安全なコスト・利用量メタデータ

秘密情報、API key、account ID、内部モデル名は記録しない。既存 telemetry_tags と privacy 方針に従う。

実装候補

以下を確認し、最小変更案を選ぶ。

  • docs/ai/subagent-delegation/dispatch-template.md
    • routing decision 参照欄を追加
  • docs/ai/subagent-delegation/plangate-flow-integration.md
    • mode / role / verifier / escalation の判断フローを追加
  • docs/ai/model-profiles.md / .yaml
    • 既存フィールドで不足する場合のみ additive に拡張
  • subagent-dispatch
    • dispatch brief へ解決済み routing metadata を出力
  • workflow conductor
    • profile 選択・昇格・verifier 割り当ての責務を明示
  • Trust Ledger / run artifact
    • routing decision と実績を記録

Non-goals

  • 特定ベンダーのモデル序列を固定すること
  • Fable / Opus / GPT 等の固有名を Core Contract に埋め込むこと
  • 既存の C-3 / C-4 / Parent Gate を変更すること
  • AI に Human-owned の承認権限を移すこと
  • すべてのタスクで上位モデルや verifier を必須にすること
  • 既存 subagent-dispatch を置き換えること

TODO

  • 既存 model-profiles と委譲テンプレートの責務境界を整理する
  • 現在の dispatch brief / run artifact に含まれる routing 情報を棚卸しする
  • 暗黙継承が発生する箇所を特定する
  • role × profile × effort × tools × verifier の最小スキーマを設計する
  • mode 別の既定値と明示必須条件を決める
  • verifier 分離条件を決める
  • retry と escalation の状態遷移を決める
  • Trust Ledger / telemetry への記録項目を決める
  • 後方互換性を確認する
  • ultra-light / standard / high-risk の3シナリオで dry-run 評価する
  • 必要な docs / skill / schema / fixture / test の変更案を作る

受け入れ条件

  • サブタスクごとに role・model profile・reasoning effort・選定理由を説明できる
  • high-risk / critical で軽量 profile が誤選択された場合に block または escalation できる
  • write scope と tool policy が routing decision から確認できる
  • verifier の要否と割り当て理由が記録される
  • retry と model escalation が区別される
  • 実行ログまたは Trust Ledger から routing decision と outcome を追跡できる
  • 既存の サブエージェント委譲プロトコルをPlanGate運用に組み込む #710 委譲プロトコル、Model Profile、Gate 条件を置き換えず接続している
  • 既存利用者に破壊的変更を与えない
  • 3種類以上の代表シナリオで、コスト過剰・品質不足・権限過剰を検出できる

評価シナリオ例

A. 定型調査

  • role: researcher
  • mode: light
  • effort: low
  • read-only
  • verifier: optional

B. 通常実装

  • role: implementer
  • mode: standard
  • effort: medium
  • write scope: 対象ファイル限定
  • verifier: spec reviewer + quality reviewer

C. 高リスク設計変更

  • role: architect / implementer
  • mode: high-risk または critical
  • effort: high 以上
  • verifier: 必須・別セッション
  • Trust Ledger: routing reason / escalation reason / human intervention を記録

期待効果

  • 上位モデルを判断が必要な箇所へ集中できる
  • 定型処理のコストを抑えられる
  • モデル・effort の暗黙継承による過剰利用を防げる
  • 実装者と検証者を分離し、レビュー独立性を高められる
  • モデル昇格の有効性を実績データから改善できる
  • PlanGate のモデル非依存 Core を維持したまま、各 provider の能力差を薄い設定層へ閉じ込められる

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:workflowenhancementNew feature or requestpriority:P1P1: 次 milestone 候補

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions