構想と、それを阻む制約

やりたいこと

1. メインエージェント（大きなモデル）が、目的を受け取って作業手順に分解する
2. サブエージェント（小さなモデル）が、分解された個々のタスクを実装する
3. サブエージェントは複数動かし、量をこなす

狙いは役割分担にある。計画のような「判断が要る仕事」は賢いモデルに、 実装のような「量が要る仕事」は速いモデルに振り分ける。

本PCの実測値（計画書 第10章より）

最初にぶつかる壁

2つのモデルを同時に立てようとすると、それだけで VRAM を超える。

同時に何が動くか — VRAM の割り当て

2つの実現方法

--parallel で何が起きるか

コンテキストの割り当て試算

構成案の比較

案1 — クラウドで計画、ローカルで実装（逐次）

メインは Claude 等のクラウドモデル。計画を構造化データで出力させ、 オーケストレータがタスクを1つずつローカルの llama-server に投げる。

• 利点計画の品質が担保される。分解の妥当性がこの構成の生死を分けるので、ここが強いのは大きい
• 利点ローカル側は1モデル1スロットでよく、コンテキスト 8192 をフルに使える
• 欠点サブエージェントは実質1つ。「複数」という当初の狙いは満たさない
• 欠点計画フェーズでネットワークとクラウド利用料が要る

案2 — 完全ローカル 2段構え（モデル切り替え）

計画は gemma-4-E4B（reasoning・正確）、実装は Qwen3-4B（速い）。 同時常駐できないため、llama-swap のようなプロキシか、オーケストレータ自身がプロセスを立て直す。

• 利点完全オフライン。費用がかからない
• 利点計画書 第10章で E4B の正確さは確認済み（Qwen3-4B が誤答した設問に正答）
• 欠点切り替えごとに 7.5 秒。計画↔実装を往復する設計だと効いてくる
• 欠点4B クラスに計画を任せる品質リスク。E4B でも 7.5B 相当であり、分解の質は未知数

案3 — 1モデル＋並列スロット

Qwen3-4B を --parallel 4 で立て、独立したタスクを同時投入する。

• 利点「複数のサブエージェント」が唯一実現する形
• 欠点1スロット 2048 トークン。タスクを相当細かく割る必要がある
• 欠点全サブエージェントが同一モデル。役割ごとにモデルを変えられない
• 未知並列時の合計スループット。帯域律速なので4倍にはならないが、何倍かは実測しないと分からない

案4 — ハイブリッド

計画と最終検証はクラウド、実装の量はローカル並列、検証で落ちたタスクだけクラウドに差し戻す。

• 利点各モデルを得意な場所に置ける。失敗の受け皿がある
• 利点ローカルで捌けた分だけクラウド利用が減る
• 欠点構成が最も複雑。オーケストレータの実装量が増える

比較表

採用案とアーキテクチャ

採用: 案4（ハイブリッド）を、案3の実測を経て組む

最終形は案4とする。ただし案4の中核は案3（並列スロット）であり、 そこが何倍のスループットを出すかが分からないまま全体を組むのは順序が逆。 第6章の段階計画では、案3の実測を最初に置く。

全体の流れ

各層の責務

通信の形

サブエージェントとの通信は、計画書 第10章で動作確認済みの OpenAI 互換エンドポイントを使う。

POST http://127.0.0.1:8080/v1/chat/completions
{
  "messages": [
    { "role": "system", "content": "あなたは与えられた1つのタスクだけを実装します。" },
    { "role": "user",   "content": "<タスク定義>" }
  ],
  "max_tokens": 1024,
  "temperature": 0.2
}

サブエージェント側は状態を持たない。会話履歴を積まず、1タスク1リクエストで完結させる。 文脈が 2048 トークンしかない以上、履歴を持たせる余裕がないという事情もある。

タスク分解と検証の設計

4B が扱えるタスクの条件

計画書 第10章の品質評価で、Qwen3-4B は次の結果を出している。

タスクの適性

タスク定義に必要な項目

メインが出力するタスク定義には、検証方法まで含める。これが無いとオーケストレータが合否を判定できない。

{
  "id": "task-003",
  "goal": "html2md.ps1 の Convert-Table に colspan 展開のテストを追加する",
  "context_files": ["src/scripts/70_html2md/html2md.ps1"],
  "constraints": [
    "既存の関数シグネチャを変えない",
    "PowerShell 5.1 で動作すること"
  ],
  "verify": {
    "command": "pwsh -File tests/run-tests.ps1 -Filter Convert-Table",
    "expect_exit_code": 0
  },
  "max_retry": 2
}

検証の階層

段階的な実装計画

Phase 1 — --parallel の実測

ここが最初に来る。並列時の合計スループットが分からないまま全体を組むと、 「並列にした意味がなかった」という結論を最後に知ることになる。

判断

• 2倍以上並列に意味がある。Phase 2 へ進む
• 1.3〜2倍効果は限定的。案1（逐次）でも大差ないので、実装の単純さを取る
• 1.3倍未満並列は諦める。帯域律速が支配的という結論を記録して終える

Phase 2 — 単一タスクの往復

オーケストレータの最小形を作り、1タスクを投げて検証まで回す。

• タスク定義 JSON を1件、手で書く
• API に投げ、応答からコードを取り出す
• verify.command を実行して合否を出す
• 失敗したら再試行する（最大2回）

ここまでで「4B が実際にタスクを完了できるか」が分かる。できないなら以降は無意味になる。

Phase 3 — 複数タスクの投入

• タスク定義を N 件に増やし、Phase 1 で決めた並列数で投入する
• 成功率を測る。ここが低いと構成全体が成り立たない
• 失敗の傾向を分類する（要件の取りこぼし／構文エラー／文脈不足）

Phase 4 — 計画フェーズの接続

• メインにタスク定義 JSON を生成させる
• 差し戻しの経路を繋ぐ
• 分解の粒度が適切かを、Phase 3 の成功率と突き合わせて調整する

成果物の置き場

src/scripts/80_agent/
  orchestrator.ps1     … タスク配分・API 呼び出し・検証・集約
  orchestrator.cmd     … ランチャー
  tasks/               … タスク定義 JSON
  results/             … 実行結果とログ
docs/plan/agent-architecture.html  … 本書

この案が失敗する条件

失敗のパターン

最大のリスクは4番目

技術的には Phase 1〜3 で解決できる問題が並ぶが、4番目だけは技術で解決できない。

4B が扱えるタスクは「入出力が明確で、機械的に検証でき、判断を含まない」ものに限られる。 そこまで細かく分解し、検証コマンドまで用意する作業を誰かがやらねばならない。 それをメインエージェントにやらせるなら、メインが直接実装するのと手間が変わらない場面が相当ある。

それでも成立する条件

この計画で決まっていないこと

• 未定適用する作業内容。計画書 第9章の時点で常用用途が未定のままであり、 「同種のタスクが大量にある」に当てはまる仕事が具体化していない
• 未測定--parallel のスループット。Phase 1 で測る
• 未確認使用中のビルド（b10612）での --parallel の正確なオプション名と挙動
• 未検討メインをクラウドにする場合の接続方法。計画書 第8章 Step 5 と重なる