AIエージェントの暴走を止める：AWSの「Dogwood」が切り拓く時系列制御の未来

我々エンジニアがAIエージェントを実務に導入する際、最も頭を悩ませるのは「一度の推論で完結しないタスク」の制御だ。単発のAPIコールであれば、従来の認可ポリシーで十分だった。しかし、エージェントが自律的にツールを連鎖させ、複雑なワークフローを構築し始めると、話は一変する。例えば、「特定の機密データにアクセスした後は、外部への通信を遮断する」といった制約は、単一のイベントだけを見ていては決して守れない。AWSがオープンソース化した「Dogwood」は、まさにこの「時系列の文脈」を制御するために生まれた言語だ。

Dogwoodは、AWSが開発した認可言語「Cedar」を拡張したもので、Apache 2.0ライセンスで公開されている。Cedarが「そのリクエスト単体で許可されるか」という静的な判定に特化していたのに対し、Dogwoodは「過去に何が起きたか」というイベント履歴を参照できる。これは、分散システムにおけるステートフルな制御を、AIエージェントのツール呼び出しレイヤーに持ち込んだことを意味する。我々がこれまで深夜の障害対応で頭を抱えてきた「順序依存のバグ」や「競合状態によるポリシーのすり抜け」を、ポリシー言語のレベルで解決しようという野心的な試みだ。

技術的な核心は、Dogwoodが導入した「temporal condition（時系列条件）」にある。これは、エージェントのイベント履歴を読み取り、formerly（過去に発生したか）、count_within（指定期間内の回数）、count_distinct_within（異なる値の数）、sum_within（合計値）といった演算子を用いて、動的な制約を記述できる。これにより、例えば「1時間以内に送金ツールを3回以上呼び出したらブロックする」といった、これまでアプリケーションコード側で泥臭く実装していたガードレールを、宣言的なポリシーとして切り出せるようになる。これは、ビジネスロジックとセキュリティポリシーを分離したいと願うアーキテクトにとって、福音以外の何物でもない。

Dogwoodの発表で最も興味深いのは、AWSが自ら指摘している「正確性の罠」だ。彼らは、レートリミットを「リクエストイベント」ではなく「レスポンスイベント」に基づいて記述した場合、並行処理によってポリシーが容易に突破されるリスクを明示している。例えば、2,000ドルの送金リクエストが3つ同時に飛んできた際、レスポンスが返る前にポリシーエンジンが判定を行うと、合計6,000ドルの送金が許可されてしまう。これは、分散システムにおける「チェック・ゼン・アクト（Check-then-Act）」の典型的な競合問題であり、エージェントという新しい抽象化レイヤーにおいても、我々が長年戦ってきた分散システムの原則がそのまま適用されることを示唆している。

さらに、Dogwoodの導入には明確なトレードオフが存在する。Cedarの強力な武器であった「自動推論（Automated Reasoning）」によるポリシーの形式検証が、Dogwoodではサポートされない。時系列データという「状態」を扱う以上、検証の複雑性が爆発的に増大するためだ。これは、セキュリティの堅牢性を取るか、動的な制御の柔軟性を取るかという、エンジニアにとっての永遠のジレンマを突きつけている。AWSがCedarを拡張するのではなく、あえて別の言語としてDogwoodを切り出した判断は、この「検証可能性」を犠牲にしてでも「時系列制御」という実用的な課題を解決したかったという強い意志の表れだろう。

また、Dogwoodはあくまで「言語」であり、その背後には信頼できるイベントログの蓄積と、正確なタイムスタンプの管理が不可欠だ。AWSが「本番環境での利用には、信頼できるイベントログの構築が必要」と明言している通り、Dogwoodを導入するということは、単にポリシーを書くことではなく、エージェントの全行動を追跡可能な「監査可能なパイプライン」を構築することを意味する。これは、MCP（Model Context Protocol）のような標準化の動きと相まって、エージェントの挙動を可視化・制御するためのインフラがようやく整いつつあることを示している。

Dogwoodの登場は、AIエージェントのガバナンスが「モデルの出力制御」から「システム全体の振る舞い制御」へとシフトしたことを決定づけている。我々エンジニアは、プロンプトエンジニアリングでモデルの出力を調整することに腐心してきたが、今後は「エージェントが何をしたか」という履歴をいかに正しく管理し、それをポリシーエンジンにどうフィードバックするかという、より堅牢なシステム設計が求められるようになる。これは、AI開発が「実験的なプロトタイピング」から「信頼性の高いエンジニアリング」へと成熟する過程そのものだ。

最後に、読者であるあなたに問いかけたい。あなたのチームが構築しているエージェントは、その「行動履歴」をどれだけ正確に追跡できているだろうか？ もしエージェントが予期せぬツール呼び出しを連鎖させたとき、それを即座に検知し、停止させるための「宣言的なガードレール」は存在するか？ Dogwoodは、そのための強力なツールになり得るが、魔法の杖ではない。結局のところ、エージェントの安全性を担保するのは、言語の機能ではなく、我々が設計するイベントログの信頼性と、その背後にある「何が許容され、何が許容されないか」という厳格なビジネスロジックの定義に他ならない。

明日から取るべきアクションは明確だ。まずは、現在開発中のエージェントが発行しているツール呼び出しの履歴を、時系列で構造化して保存する仕組みを検討すること。そして、その履歴に対してどのような制約を課すべきか、Dogwoodの仕様を参考にポリシーのプロトタイプを書いてみることだ。AIの進化速度に翻弄されるのではなく、我々が培ってきた分散システムの知見をAIエージェントの制御に適用し、自らの手で「制御可能なAI」を構築する。それが、シニアエンジニアとして今、最も取り組むべき挑戦ではないだろうか。