エージェント開発ツールが新たなボトルネックに直面：ワークフローの監査可能性

開発ワークフローでエージェントを利用するある大手金融機関において、内部監査・コンプライアンスチームは具体的な疑問を抱いた。決済サービスの依存関係を更新するためにエージェントが作成したマージリクエストについて、誰が承認したか、エージェントが使用した入力データとプロンプトは何か、どのポリシーチェックが評価されたか、そしてこのタスクを再現または取り消す方法はあるか、を示すことは可能か？チームには答えがなかった。デリバリーシステムは、エージェントの作業を、境界が明確で監査可能なトランザクションとは見なしていなかった。

CI（継続的インテグレーション）によって検証され、承認された差分は、変更が発生したことを証明する。しかし、エージェントが使用した文脈、マージリクエスト作成前に評価されたポリシー決定、または後続の実行で結果を再現する可能性については証明しない。規制環境においては、「どのように」と「なぜ」が重要である。この状況は、プラットフォーム全体およびDevSecOps組織で見られる：エージェントツールの予算は数週間で承認される一方、実行記録、アイデンティティ連携、リプレイツールの予算は全く現れないか、単なるコンプライアンスコストとして扱われる。

繰り返し発生する4つの例外

エージェントが規制されたCI/CD環境でマージリクエストを開くとすぐに、4種類のコンプライアンス例外が発生する。1つ目は欠落したプロビナンス：仕様、取得した文脈、ツール呼び出し、リポジトリの状態など、エージェントが使用したデータが誰にも分からない。2つ目は不確かなアイデンティティ帰属：エージェントは共有サービストークンの下で動作し、指定された人間の責任者がいないため。3つ目は再構築不可能な意思決定連鎖：推論が一時的にしか捕捉されていないため。4つ目は境界のないロールバック：エージェントの変更が結合されているため、取り消し作業はコミットやリポジトリをまたぐ手動作業となる。

事後再構築とは、会話ログ、CIの部分出力、まだ利用可能なエージェントのトレースを調査することである。多くの組織では、この作業に毎週費やされる時間が計上されておらず、そのコストが見えにくい理由となっている。情報源は簡単なテストを提案する：チームは、タスクの仕様、リポジトリの状態、評価されたコントロール、アクションの元となった人間の責任者をまとめた証拠ファイルを1時間以内に作成できるか？

「まず届ける」とその限界

「まず届け、その後統治する」という戦略は、エージェントがテスト生成、小規模なリファクタリング、ドキュメント更新など、厳格な人間レビューを伴う限定的な範囲に限定されている場合には機能しうる。しかし、チームがその制約から解放され、プロンプトライブラリが増殖してロギングが一貫せず、共有トークンによりポートフォリオ規模での帰属が不可能になると、この戦略は崩れる。記事ではまた、エージェントを一般化する前にワークフロー基盤を構築しようとした大企業の事例も引用している：プラットフォームプロジェクトは数四半期にわたり延長し、チームは最終的にそれを回避した。

記事は、「競争圧力は速度を報いる一方、規制当局は再構築能力を報いる」と指摘している。このギャップのコストとして、監査時に発覚した欠落証拠、数週間の是正措置、そして記録が不十分なエージェントアクションごとに広がる影響範囲が説明されている。この点で、記事はクレディ・アグリコルCIBを引用し、同社はテキストによれば、エージェント作業を監査するために必要な条件である、数十か国に分散する数千人の開発者を単一のDevSecOpsプラットフォーム上で統合したデリバリーを推進しているとしている。

作業の命名と測定

情報源は、この取り組みを「エージェントCI/CDのための記録実行」と名付けた独立したプロダクトとして扱い、プラットフォームエンジニアリング、セキュリティ、監査、開発者体験を統合したリソースを充てることを推奨している。その成果物は、入力データ、出力、ツール呼び出し、モデルバージョンを捕捉する記録スキーマ、各アクションを人間の責任者に結びつけるアイデンティティ連携、ポリシー決定ログ、およびリプレイとロールバックのメカニズムをカバーする。追跡は、例外キューの深さ、証拠取得までの中央値時間、リプレイ成功率、例外再開率に基づいて行うことができる。

一歩だけ進めるのであれば、テキストは、依存関係変更、Infrastructure as Codeの変更、セキュリティ設定など、最もリスクの高いケースから始めることを勧めている。提案される最後のテストは、チームに、記録された成果物のみに基づいて、エージェントによって記述されたマージ済み変更をきれいに取り消すよう求めることである。