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や外部サービス通知まわりの実装に進んでよい。
速い、安い、同じ条件の比較対象より優れている。

特に、本番安全性、実装の安全性、秘密情報の扱い、公開・セキュリティ上の約束を採用する判断、公開・展開の準備完了は別問題である。

レビューで得た証拠は、実行許可ではない。

結論

初回出力チェックは、サブエージェント運用の優位性を示すためだけでなく、限界を見つけるために必要だった。

初回出力を残すと、データ形式のズレ、役割ごとの出力ルールのズレ、検証ツールの抜け穴が見える。

これは地味だが、運用ではかなり大事である。

サブエージェントを使うなら、成功した最終出力だけを見るべきではない。

失敗した初回出力も証拠として残す。

そのうえで、言えることと言えないことを分ける。

この分離がないサブエージェント運用は、見落としを減らすどころか、過信を増やす。