総合配信プラットフォームと銀行を、並行で作る — AIエージェントの「編成」に実機能を実装させ、実測で分業をチューニングした記録

はじめに

個人で、二つのシステムを並行で作っている。一つは映像や音楽を束ねる総合配信プラットフォーム、もう一つは、その決済に使う自作の銀行システムだ。二つを同時に前へ進めるのに、私は開発を1体のAIに全部は頼まなかった。役割で分けた**サブエージェントの編成（fleet）**を組み、実装役・検証役・編成役に分けて、実機能の開発を回した。

「相棒」としてのAIと、「エージェント」としてのAIが別物だという話は GitHub Copilot を1か月、Claude Code を2日使ってみたに書いた。この記事はその先——エージェントを1体の万能選手として使うのをやめ、“編成”として配備し、実際の開発でチューニングする、その設計と実測の記録だ。

一体に全部やらせると、何が崩れるか

1体のエージェントにコードを書かせ、そのまま同じエージェントに「レビューして」と頼む。素直だが、自分のコードを自分で甘く見て（書いた直後の文脈に引きずられる）、文脈が雑多な情報で汚れ、能力とコストも釣り合わない。答えは「もっと賢い1体」ではなく、役割で分けた複数体だった。

【一体で全部】
  1体のエージェント ─▶ 実装も検証も調査も全部
        └─ 自分のコードを自分で甘く見る／文脈が汚れる／コストが釣り合わない

【編成で分ける】
  実装役 ─▶ 検証役（別の視点・別の権限）─▶ 編成役が全体を差配
        └─ 独立した目でチェック／文脈は隔離／仕事ごとに能力を配分

役割で分ける：coder → reviewer、そして orchestrator

土台は、実装役（coder）が書いたら、別のエージェントである検証役（reviewer）が独立した目で確認し、指摘を実装役に差し戻すこと。その上に、手を動かさず差配だけをする**編成役（orchestrator）**を置く。

                      ┌─▶ coder（実装）──┐
  orchestrator（編成）─┤                  ├─▶ reviewer（検証）─▶ 指摘は coder へ差し戻し
                      └─▶ 分解・並行判断 ─┘         │
                              ▲                     └─ 良くなるまで往復
                              └──────────────────────┘

この図の役割分担を、Claude Code では1体ずつの定義ファイルで表す。各定義に、役割・使える道具・割り当てるモデルを書く。上の図がそのまま、下の設定になる。

# ~/.claude/agents/*.md（各サブエージェントの定義から抜粋）
orchestrator : { model: opus,   tools: [Agent, Read, Grep, ...] }   # 編成役（差配のみ）
rag-reviewer : { model: opus,   tools: [Read, Grep, Bash, ...]  }   # 検証役
rag-coder    : { model: sonnet, tools: [Read, Write, Edit, ...] }   # 実装役

図と設定を並べると、検証役の道具に Write / Edit が無いことが効いているのが分かる。reviewer は実装役の成果物を直接は編集できない。検証と実装が同じ手に握られると、また「自分で自分を甘く見る」に戻るからだ。役の境界を、権限のレベルで混ぜない。

この編成を、銀行システムの実APIで初めて通しで走らせたとき、入れ子の直列編成（実装→検証→コミット専任）が権限エラーなく動いた。実測はこうだ。

# orchestrator が実機能（本人確認API）を編成した実測
rag-coder（実装）     … 約11.6分 / 約136k トークン  ← 最も重い工程
rag-reviewer（検証）  … 約6.7分  /  約73k トークン
コミット専任（分離）  … 約34秒   /  約40k トークン  ← 実装の約1/3。軽い定型を別体に隔離

トークン量は、そのまま工程の重さを映す。実装が最も重く、コミットのような定型はその1/3で済む。だから重い実装は主戦力モデルに、軽い定型は別体に切り出す——数字が、次の配分の根拠になる。

モデルを適材適所で配る

編成チューニングの中心は、どの役に、どのモデルを割り当てるかだ。目的はトークン節約ではなく、能力とコストの配分。この方針を、まず図の”はしご”で持ち、指示（CLAUDE.md）に文章で焼き込む。

能力↑  fable ─── 最難関の一手だけ、判断で限定昇格
       opus ──── 検証・設計・セキュリティ（死守）
       sonnet ── 生成・日常コーディング（主戦力）
       haiku ─── 機械的・単純
コスト↓（下ほど安い）

# CLAUDE.md（運用規律・抜粋）— 上のはしごを言葉で固定する
モデル選択は「性能最大化の適材適所」が第一＝トークン節約が目的ではない。
検証・設計/セキュリティ判断 = opus 死守（惜しまない）
⛔ 安く落とすことを目的化して検証を落とすのは軸の取り違えで禁止

一度、コスト削減のつもりで検証役まで軽いモデルに落として、軸を取り違えたことがある。**「どこまで安くできるか」ではなく「その仕事が相応の能力を要するか」**で選ぶ。安さは目的ではなく、能力の配分が目的だ。

委譲には「構造費」がある

もう一つの効きどころが、大量の grep や長いログの精読を、主役（main）とは別のまっさらな作業場（隔離コンテキスト）を持つサブエージェントに委譲することだ。読むのはサブに任せ、主役が受け取るのは要約だけ。主役の文脈を、雑多な情報で埋めないためだ。

ただし委譲は、いつでも得ではない。並行起動には構造費——並べたぶんだけ増える総トークンと、前提を各体へ配り直す固定費——がかかる。ある大規模な整合性監査で、それを読み違えた。

# 大量ファイルの監査を3体に並行配備した結果
狙い：並行で短縮  ─▶  実際：多重起動の構造費がモデルティアを上回り、
                        コンテキストを 8 割超まで消費
判定：この監査は「判断が重く全体を見渡す一体のタスク」＝分割向きではなかった
      → メインが直接まとめて処理する方が安い

つまり、委譲するかどうかは仕事の性質で決まる。

  verbose な読解（大量ログ・全文精読）  → 委譲（隔離で主役の文脈を守る）
  独立して並行できる作業（多数の変換）  → 委譲（並行が効く／同時起動は2〜4に絞る）
  判断が重く全体を見渡す一体のタスク    → メイン直（分割の固定費が高い）

配備は万能ではない：崩れたら、測って戻す

編成は強いが、壊れないわけではない。別の日、独立性の高い一括変換の仕事を4体に並行配備したとき、APIが不安定で半分以上が途中でストール（応答が流れの途中で止まる現象）した。ここで効いたのは「委譲＝速い」を過信せず、測定して戻す規律だ。

① 存在マトリクスで欠損を測る   … 揃い 21/32・欠損 11（書き込みは全文一括＝中途半端な切れは無い）
② 失敗分だけ、負荷を下げて再配備 … 1体あたりの担当を減らす
③ それでも落ちた分は main で直接 … 安定した手元で確実に仕上げる
④ 機械チェックで整合を確認      … 内部リンク 0 エラー

欠損を一覧化できたのは、書き込みが全文一括で、ストールしても中途半端なファイルが残らないからだ。速さは、壊れ方とセットで設計する。

「万能の1体」より「凡ミスしない編成」

二つのシステムを並行で作りながら分かったのは、エージェントの強さは1体の賢さでは決まらない、ということだ。役割で分け（実装と検証を別の目・別の権限に）、能力を配り（重い仕事に強いモデルを惜しまず）、委譲の構造費を測り（判断の重い一体タスクはメイン直）、壊れ方を設計する（落ちても被害を測って戻せる形に）。強いのは、より賢い1体ではなく、賢くない瞬間を編成と規律で潰した編成のほうだった。

実装が”技術的には正しいのに完成品に見えない”といった、編成でも漏れる失敗を指示のゲートに畳んだ話は「技術的に正しい」を「完成品」に引き上げるに、横断する編成が共有記憶から別プロジェクトの決定を引いて汚染した話は別プロジェクトの決定の混入を検出して分離したに書いた。