生成AIと自律型AIエージェントの進化は、ソフトウェア開発のあり方を大きく変えつつあります。特にエージェント型の開発ツールは、コード生成、テスト作成、リファクタリング、ドキュメント更新といった作業を支援し、開発チームの生産性向上に貢献し始めています。

一方で、エージェントが開発ワークフローの中で実際に変更を作成し、マージリクエスト（MR）を起票するようになると、新たな課題が浮かび上がります。それは、単に「変更が正しく行われたか」ではなく、「⁠その変更がどのような文脈で、誰の責任のもと、どのポリシーチェックを経て行われたのか」を説明できるかという問題です。

たとえば、ある大手金融機関では、AIコーディングエージェントを開発ワークフローに導入し、エージェントによるMRの作成やパイプライン実行を進めていました。その結果、開発速度を示すメトリクスは改善傾向を示していました。

しかし、内部監査およびコンプライアンスチームから、次のような質問が出されました。

「決済サービスの依存関係を更新したエージェント起票のMRについて、誰がその変更を承認したのか、エージェントはどんな入力やプロンプトを使ったのか、MR作成時にどのポリシーチェックが評価されたのか、そしてその作業単位をどうすれば再現したり取り消したりできるのかを明らかにすることはできますか？」

この問いに対して、チームは十分な回答ができませんでした。

エージェントは成果物を生成していました。しかし、デリバリーシステムの側には、エージェントの作業を「境界づけられた、監査可能な作業単位」として扱う仕組みがありませんでした。CIを通過し、承認された差分が存在することは、すなわち変更が行われたことを示します。しかし、それだけでは、エージェントがどのコンテキストを参照したのか、MR作成前にどのポリシーチェックが行われたのか、後続のパイプライン実行で同じ結果を再現できるのかまでは証明できません。

規制対象の環境では、「⁠何が変わったか」だけでは不十分です。むしろ重要なのは、「⁠どのように」「⁠なぜ」その変更が行われたのかを説明できることです。

エージェント起点の変更で生じる4つの例外

エージェントが規制対象のCI/CD環境でMRを作成し始めると、一定のパターンを持つコンプライアンス上には次の4つの例外が発生します。組織や業界が異なっても、その種類は大きく変わりません。

1. 来歴が不明確である

まず問題になるのは、エージェントが何を入力として利用したのかを示せないことです。タスク仕様、取得されたコンテキストの参照元、ツール呼び出し、実行時点のリポジトリ状態などが記録されていなければ、その変更の来歴を説明することはできません。

2. アイデンティティの帰属があいまいである

次に、エージェントによる変更と人間による変更を明確に区別できないケースがあります。エージェントが共有サービス用トークンのもとで動作しており、そのアクションに責任を持つ人間のスポンサーが紐付いていない場合、誰の責任で変更が行われたのかが不明確になります。

3. 意思決定の連鎖を再構成できない

MRが作成される前にどのポリシーチェックが評価されたのか、エージェントがなぜ別の選択肢ではなくその変更を選んだのかを示せないこともあります。推論過程が一時的なトレースとしてしか残っていない場合、監査時に意思決定の連鎖を再構成することは困難です。

4. ロールバックの範囲が定義されていない

エージェントによる編集が複数のコミットやリポジトリにまたがってつながり合っている場合、変更の取り消しは手作業による調査になります。明確な作業単位の境界がなければ、どこまでを1つの変更として戻すべきか判断できません。

上記のような例外が発生した場合、多くの組織では、チャットログ、断片的なCI出力、残っているエージェントのトレースを掘り起こしながら、後付けで証跡を再構成することになります。しかし、この作業に週あたり何時間が費やされているのかを追跡できている組織は多くありません。そのため、このコストは可視化されないまま残り続けます。

実践的な確認方法として、直近でエージェントが起票し、依存関係またはInfrastructure as Code（IaC）に触れたMRを選んでみることが有効です。そのMRについて、チームは1時間以内に、正確なタスク仕様、リポジトリ状態の参照、MR作成時に評価されたポリシーチェック、そしてそのアクションに責任を持つ人間のスポンサーを含む証跡一式を提示できるでしょうか。

提示できないのであれば、そこに改善すべき課題があります。

エージェントによる変更は従来の監査モデルを超える

人間が作成したMRであれば、監査に必要な証跡は比較的限定されています。差分、承認履歴、パイプライン結果があれば、多くの場合は説明が可能です。

しかし、エージェントが作成したMRでは、それだけでは足りません。タスク仕様、取得されたコンテキストの参照、ツール呼び出し、モデルのバージョン、ポリシー評価、そして入力を固定した状態でタスクを再実行するために必要な情報が求められます。

CIログは、この要件を十分に満たしません。CIログが示すのは、パイプラインの各ステップとその出力です。エージェントが参照したコンテキスト、呼び出したツール、MR作成前に評価されたポリシーチェックまでは、通常記録していません。

エージェントの導入が広がるほど、1つのMRに含まれる小さな意思決定の数は増えていきます。一方で、それらを人間が手作業で文書化する能力は、同じようには増えません。ここで、従来の運用モデルは限界に達します。

非人間のシステムが変更を作成するようになった時点で、デリバリーシステムには、そのシステムが何を見て、何を判断し、何を行ったのかを、ワークフローの一部として永続的に記録する仕組みが必要になります。これは、後から付け足す補助的な仕組みではなく、開発ワークフローそのものに組み込まれるべきものです。

エージェントの場合、この課題はさらに複雑です。取得されたコンテキスト、利用されたモデルのバージョン、推論の過程は、同じように再実行しても必ずしも同じ結果を生みません。つまり、エージェントの入力と判断は、本質的に再現しにくいのです。

不足しているのは、エージェントのコンテキストとアクションを、チャットログや一時的なトレースのようなワークフロー外の記録に頼るのではなく、MRに紐付いた永続的な成果物として扱う仕組みです。

今回は、エージェント型開発ツールが開発ワークフローに入り込むことで、従来の監査モデルでは捉えきれない課題が生じることを解説しました。AIエージェント起点の変更を扱う上では、差分やCI結果だけでなく、入力、判断、責任の所在を含めた証跡を残すことが重要です。次回は、スピードと再構成可能性を両立するために、どのように実行記録の仕組みを設計し、運用すべきかについて解説します。