AIサブエージェント運用の実験 3: 初回出力チェックで見えた限界
前回までは、サブエージェントが高リスクレビューで効いた場面を書いた。
今回は、逆に限界を書く。
サブエージェント運用で怖いのは、最終的に整った出力だけを見て「うまくいった」と思ってしまうことだ。
そこで、初回出力チェックを入れた。
つまり、後から整えた出力だけでなく、最初の出力がデータ形式や参照してよい情報の境界を満たしていたかを見る。
これはかなり重要だった。
きれいに整えた最終結果だけを見ると、運用上の弱さが隠れるからだ。
初回出力チェックとは何か
今回の意味の判定では、ざっくり次の流れを使った。
- 候補だけの素材を作る。
- 隠した正解条件の素材を作る。
- 判定しやすい形に整える。
- 判定担当が、隠した正解条件に照らして候補を判定する。
- 親エージェントが検証、集計、記録を行う。
初回出力チェックでは、判定用データ作成役や判定担当の初回出力を残す。
そして、次を見る。
- JSONとして妥当か
- 必須項目があるか
- 候補と正解条件の対応が崩れていないか
- 参照してよい情報の境界を破っていないか
- 禁止された変更をしていないか
- 後から修正した出力だけで成功扱いしていないか
この運用を入れたことで、サブエージェントの良い面だけでなく、壊れやすい面も見えた。
うまくいったケース
QC-008Pでは、権限まわりではない別テーマで検証した。
対象は、内部文書の鮮度確認。
見たかった隠した正解条件は次の3つ。
- 根拠不足や未検証の主張を追跡すること
- あとから見える確認シグナルを決めること
- 次の確認手順や担当者・置き場所を決めること
この試行では、判定用データ作成役の初回出力チェックが2 / 2で通り、判定担当の初回出力チェックも6 / 6で通った。
6つの判定すべてが強い候補を選び、弱い候補は3つの正解条件をすべて外した。
これは、論点を分けて初回出力を厳しめに確認するやり方が、少なくとも1つの別テーマに転用できたことを示す。
ただし、これでも「一般に優れている」とは言えない。
1つのテーマの結果であり、速さ、費用、実装の安全性は測っていない。
権限境界では効果が出たが、契約の穴も出た
QC-008Qでは、権限引き継ぎを対象にした。
ここでは、レビューで得た証拠が準備完了、ラベル変更、Issue終了、PR取り込み、公開・展開、記事公開の権限に見えてしまわないかを見た。
結果として、6つの判定すべてが強い候補を選んだ。
強い候補は、準備完了、ラベル変更、Issue終了、PR取り込み、公開・展開、読むだけのレビューの境界を明示していた。
弱い候補は、3つの権限境界の正解条件をすべて外した。
この意味では、権限境界レビューには効いた。
ただし、初回判定用データ作成役は事前チェックに落ちた。
理由は、正解条件リストに、検証ツールが必要とする要約が足りなかったことだった。
さらに、判定結果の項目名チェックでも検証ツール側の穴が見つかった。
これは失敗ではある。
しかし、重要な失敗だった。
初回出力チェックを置いたから、役割ごとの出力ルールと検証ツールのズレが見えた。
最終出力だけを見ていたら、このズレは隠れていた。
もう一度近いテーマを回しても、まだ穴は出た
QC-008Rでは、ラベル振り分けや自動化権限のテーマを使った。
QC-008Qで直した要約不足の問題が再発しないかを見た。
この点は改善した。
判定用データ作成役は、隠した正解条件の意味を要約へコピーできた。
しかし、別の穴が出た。
候補素材の最終判定が単なる文字列で、判定用データの検証ツールはまとまったデータを期待していた。
そのため、初回判定用データ作成役はまた事前チェックに落ちた。
ここで分かったのは、サブエージェント運用は「一度直したら安定」ではないことだ。
厳しめに確認する流れは、うまくいった証明というより、契約のズレを早めに見つける仕組みとして効いた。
QC-008Rでも、修正後の判定用データと判定結果は通り、6つの判定すべてが強い候補を選んだ。
しかし、修正なしで初回から安定することは証明できなかった。
運用ルール以外の領域では差も出た
QC-008Tでは、架空のAPI変更レビューを対象にした。
GET /v1/invoicesにstatus絞り込みとinclude=customerを追加する、という仮想変更である。
ここでは、APIの約束事、後方互換性、ページ分割・キャッシュ・絞り込み・追加取得の組み合わせ、エラー時の挙動、テスト用データや契約テスト、人間による互換性確認の境界を見た。
結果は良かった。
判定用データ作成役の初回出力チェックは2 / 2、判定担当の初回出力チェックは6 / 6で通り、6つの判定すべてが強い候補を選んだ。
一方、QC-008Uのセキュリティに近いレビューでは、より微妙な結果になった。
対象は、決済サービスから届く通知の署名確認、イベント保存、二重処理防止、再試行処理。
6つの判定すべてが強い候補を選んだが、意味の一致は完全には安定しなかった。
特に、サービス提供元が定める署名対象、許可する署名方式やバージョン、人間が公開・セキュリティ上の約束を採用する判断の明示が足りず、一部正解条件の一致が弱かった。
これは重要な結果だった。
「強い候補を選べた」ことと、「隠した正解条件を完全に満たした」ことは違う。
セキュリティに近いレビューでは、この差を混ぜると危ない。
今回言えること
初回出力チェックを入れて分かったことは、次の通り。
- サブエージェントは、権限境界やAPIの約束事のような高リスクレビューで有効そうだった。
- 複数判定役により、弱い候補を落とす信号はかなり明確に出た。
- ただし、データ形式や役割ごとの出力ルールのズレは普通に起きる。
- 最終結果だけを見ると、そのズレは隠れる。
- セキュリティに近いレビューでは、候補の好ましさと完全な意味の一致を分けて扱う必要がある。
まだ言えないこと
次はまだ言えない。
- サブエージェントは初回出力で常に安定する。
- サブエージェントはセキュリティレビューで十分に安全。
- 強い候補を選んだので、本番安全性がある。
- APIや外部サービス通知まわりの実装に進んでよい。
- 速い、安い、同じ条件の比較対象より優れている。
特に、本番安全性、実装の安全性、秘密情報の扱い、公開・セキュリティ上の約束を採用する判断、公開・展開の準備完了は別問題である。
レビューで得た証拠は、実行許可ではない。
結論
初回出力チェックは、サブエージェント運用の優位性を示すためだけでなく、限界を見つけるために必要だった。
初回出力を残すと、データ形式のズレ、役割ごとの出力ルールのズレ、検証ツールの抜け穴が見える。
これは地味だが、運用ではかなり大事である。
サブエージェントを使うなら、成功した最終出力だけを見るべきではない。
失敗した初回出力も証拠として残す。
そのうえで、言えることと言えないことを分ける。
この分離がないサブエージェント運用は、見落としを減らすどころか、過信を増やす。