ACM、3つのエージェントフレームワークをバージョン管理された構成グラフへ投影し、変更影響と実行プロベナンスを統一的に追跡

エージェントシステムの振る舞いは通常、プロンプト、モデル名、ツール権限、スキルファイル、ハンドオフ関係、フレームワーク固有のワークフローに分散している。コードがバージョン管理されていても、あるモデルやプロンプトの変更がどのエージェントに影響するのか、実際の実行でどの構成一式が使用されたのか、異なるフレームワークが同じガバナンスルールに従っているのかを、チームが把握することは依然として難しい。

新たな技術レポートでは、Agentic Configuration Management（ACM）が提案されている。ACMは前述のコンポーネントを、型付きで個別にバージョン管理可能なAgentic Configuration Itemとして表現する。各項目は不変のrevisionを保持し、デプロイ時にbaselineとして構成される。各ネイティブフレームワークの構成は、semantic projectionを通じてcanonical Configuration Graphへマッピングされる。このグラフには、依存関係、構成関係、ツール利用、エージェント間のハンドオフ関係が明示的に記録される。また、構成バージョンとruntime provenanceも分離されるため、実行記録がフレームワーク内部のオブジェクトや、再構築できないテキストスナップショットだけにとどまることを防げる。

変更影響分析では、有限束上の単調伝播を採用する。変更されたノードを起点として、関係と変更カテゴリに基づき、影響を受ける集合が増加しなくなるまで固定点を反復計算する。著者はPython scaffoldに加え、LangGraph、CrewAI、OpenAI Agents SDK向けの3つのadapterを提供している。論文では、27のガバナンスシナリオと9組のクロスフレームワークケースを用いてテストした。13の構成項目と18の関係を含む例では、1階層の依存関係チェックで検出できたのは6項目だけだったのに対し、固定点伝播では完全な手動追跡と同じ9項目を検出した。9組のケースはそれぞれ5回再実行され、結果の決定性が維持された。

マルチエージェントのデプロイを監査する必要があるチームにとって、ACMの価値は、新たなagent runtimeを再構築することではなく、オーケストレーションフレームワークの上位に構成サプライチェーンを確立する点にある。これにより、「モデルを変更すると何に影響するか」をグラフクエリとして扱えるようになり、ロールバック、承認、実行プロベナンスの追跡に共通のデータモデルを提供できる。

ただし、現時点のエビデンスは依然としてリファレンス実装の段階にある。9組のケースに用いられたoracleは著者が事前に作成したもので、独立した第三者による判定ではない。また、3つのフレームワークにおける等価な依存構造も意図的に構成されたものだ。CrewAIの一部の動的トポロジーは静的にイントロスペクションできず、引き続きadapter metadataによる補完が必要となる。公開リポジトリも始動したばかりで、大規模な本番環境、悪意ある構成、動的に生成されるツール、高頻度のバージョン変更における信頼性は実証されていない。そのため、エンジニアは当面、ACMを成熟した標準ではなく、実験可能なschemaおよびガバナンスモデルとして捉えるべきだ。