AIサブエージェント運用の実験 2: どう分担させるか、どこでは使わないか

前回は、AIサブエージェント運用は万能ではないが、高リスクレビューには効いた、という結論を書いた。

今回は、どういう設計で検証したかを書く。

ポイントは、サブエージェントを増やすことではない。

観点を分けることと、使わない判断を持つことである。

実験の型

大きく2種類の検証をした。

1つ目は、AI運用ルール文書のレビュー。

AIエージェント運用では、文書の中で次のような境界を決める。

• 何を証拠と呼ぶか
• 読むだけのレビュー結果をどこまで信じてよいか
• Issueを閉じてよい条件
• PRを取り込んでよい条件
• ラベルや「準備完了」状態を変更してよい条件
• 自動化や公開・展開を開始してよい条件

こういう文書は、少し曖昧なだけで危ない。

「記録されたリスク」が「解決済みリスク」に見えたり、「レビューで得た証拠」が「実行してよい許可」に見えたりする。

2つ目は、候補を見比べる検証。

候補Aと候補Bを用意し、あらかじめ隠しておいた正解条件に対して、どちらが重要な論点を満たしているかを複数のサブエージェントに判定させた。

ここでは、役割を分けた。

• 素材を作る担当
• 判定しやすい形に整える担当
• 候補を判定する担当
• 最後に結果をまとめる親エージェント

3つの観点に分ける

AI運用ルール文書のレビューでは、単一セッションで全部を見る方式だけでなく、C3という分け方を試した。

C3は、3つの担当範囲に分けてレビューする方式である。

この記事では、比較用語を次の意味で使う。

用語	意味
A1	1つの新しいセッションで対象全体を見る
A3	3つの独立セッションが、それぞれ対象全体を見る
C3	3つの担当範囲に分けて観点別に見る
Mode B	1つの親セッションからサブエージェントを起動する想定の方式

たとえば、次のように分ける。

• 目的、対象範囲、人間が判断すべき境界を見る
• 証拠、検証、戻し方、測定方法を見る
• リスク、権限のない操作、まだ言えない主張を見る

この分け方をすると、文書全体をざっと見るだけでは薄くなりやすい細部を拾いやすい。

実際に、V4-T1/T2/T3では次のような論点が出た。

• 「承認済みの手順」という言葉が、別の承認なしに実行してよいように見える
• 読み取り結果が、準備完了や書き込み許可のように見える
• 「検証済み」と呼ぶ条件が、本文と表と例で揃っていない
• 例外扱いにしたのに、例外IDが必須になっていない
• 伏せ字処理について、誰が何を確認したかが弱い
• 「CIを実装しない」とは書いているが、起動・再実行・承認を禁止する表現が弱い

こういう論点は、文章全体をざっと読むレビューでは落ちやすい。

担当範囲を分ける価値が出やすいところだった。

サブエージェント運用で大事だったルール

実験してみて、最低限必要だと思ったルールがある。

1. 読むだけのレビューだと明示する

サブエージェントの出力はレビュー材料であって、最終判断ではない。

「準備完了」、ラベル変更、Issue終了、PR取り込み、公開・展開、記事公開、自動化の有効化は別の人間判断にする。

ここを曖昧にすると、レビュー結果が勝手に実行権限へ昇格する。

2. 役割を分ける

同じ「レビューして」だけでは弱い。

権限境界、証拠、セキュリティ、API互換性、戻し方、データ形式、伏せ字処理のように観点を分ける。

サブエージェントを増やす意味は、人数ではなく観点分離にある。

3. 親エージェントが統合する

サブエージェントの指摘をそのまま採用しない。

親エージェントが、重複、根拠不足、範囲外、重大な見落としを分類する。

複数の出力を集めるだけでは、レビュー品質は上がらない。

統合しないサブエージェント運用は、単にノイズを増やす。

4. 結果報告を構造化する

各サブエージェントには、何を見たか、何を見ていないか、何を主張してはいけないかを書かせる。

成功、失敗、未検証、根拠不足を混ぜない。

Mode Bが成立しなかった試行も、失敗を隠さず「条件付きの結果」として扱った。

これにより、「サブエージェントを使ったから成功」と雑に言わずに済む。

5. 使わない判断を持つ

サブエージェントを使うべきでない場面を決めておく。

小さな修正、すぐ読めるPR、変更面が狭いタスクでは使わない。

「サブエージェントを起動しない」判断ができない運用は、コスト管理に失敗する。

優位性があると言える条件

今回の実験から、自分なら次の条件を満たしたときだけ「サブエージェント運用に優位性がある」と言う。

1つ目は、単一レビューでは薄くなりやすい重要論点を拾うこと。

たとえば、権限境界、証拠、セキュリティ、互換性、戻し方、人間判断のような論点。

2つ目は、拾った指摘が実際に有効であること。

指摘数ではなく、有効で重複しない指摘を見る。

3つ目は、根拠不足や範囲外の指摘を増やしすぎないこと。

量が増えても、親エージェントの統合負荷ばかり増えるなら優位とは言えない。

4つ目は、読むだけのレビューという境界を壊さないこと。

禁止された変更、秘密情報へのアクセス、ラベル変更、Issue終了、PR取り込み、公開・展開が0であること。

5つ目は、軽いタスクでは使わない判断ができること。

万能化した瞬間に、運用としては弱くなる。

どこに使うべきか

今のところ、使う価値があると思うのは次の場面。

• AIエージェント運用ルールを採用する前
• 証拠の確認ルールや承認の流れを設計するとき
• Issue終了、PR取り込み、ラベル変更、準備完了、公開・展開の権限境界を決めるとき
• APIの約束事や後方互換性のレビュー
• 外部サービス通知、トークン、秘密情報、二重処理防止のようなセキュリティに近いレビュー
• 実装前に、見落とすと戻しにくい論点を洗い出すとき

逆に、使わない方がよいのは次の場面。

• 誤字修正
• 小さな文言修正
• 変更範囲が1ファイルで、人間がすぐ読めるPR
• 実装方針もテスト方針も明確な小タスク
• 速度やコストが最優先の作業

結論

サブエージェント運用で重要なのは、数ではなく設計だった。

観点を分け、読むだけのレビューという境界を固定し、結果を親エージェントが統合する。

そして、軽いタスクには使わない。

この条件があると、高リスクレビューでは使う価値が出る。

条件がないままサブエージェントを増やすと、ただ統合負荷が増える。