【AWS Dogwood入門】Dogwoodって何？

Transcript

1. 2026年8月 Dogwoodって何？ AWS Dogwood 入門 ①／⑦ ── エージェントの「列」を検査する言語 赤神 青空
2. ▪「Cedar以外の言語が出た」と読むと、方向を間違える まず訂正から Dogwood は Cedar の代わりではなく、上に生えたものです。 よくある誤読 新しい言語が出た。乗り換えが要る 実際のところ 妥当なCedarは、そのまま妥当なDogwood 移行作業はありません。必要な1本にだけ足していく形になります。 今ココ 導入 2/13
3. ▪2026年8月6日、Apache 30秒でわかるDogwood 2.0 でオープンソース公開 エージェントのツール呼び出しの列を統治するための言語です。 AgentCore Policy にも同日から載っています 01 02 03 04 既存ポリシーは書き換え不 要 when temporal で履歴を条 件に書ける メトリック一階時相論理と いう形式体系 動かしながら仕様違反を捕 まえる Cedarを内包 今ココ 導入 過去が見える 土台はMFOTL 実行時検証 3/13
4. ▪Dogwood5つの部品でできている の話に出てくるのは Gateway だけ エージェント本体 Strands / LangGraph / CrewAI / LlamaIndex ── フレームワークもモデルも問わない Runtime エージェントを動かす場所 セッションごとに 隔離されたmicroVM Gateway ツールの⼊り⼝ 既存のAPIやLambdaを MCPサーバーに変える AgentCore Policy Gateway に付ける認可の層 Memory 短期‧⻑期の記憶 ユーザー単位で 持ち回す Identity エージェントの⾝元 Cognito / Okta / Entra ID とつなぐ Observability 推論‧ツール呼び出しの トレース CloudWatch へ 組み込みツール Code Interpreter（コード実⾏）∕ Browser（ブラウザ操作） 必要なものだけ選んで使える。全部⼊りで採⽤する必要はない Policy は Gateway に付ける層。ほかの部品とは独立している 今ココ どこにある 4/13
5. ▪モデルの外側、ゲートウェイの内側で判定する そもそもどこにいるのか Dogwood が効くのは、Gateway と Policy Engine の境界 既定は deny∕forbid が permit に勝つ。判定は ALLOW か DENY のどちらかにしかならない AIエージェント 呼び出しを「提案」するだけ ポリシーは⾒えない ① ③ 許可なら通す Gateway MCP ツール transfer / delete ... ツール呼び出しの⼊り⼝ エージェントのコードの外側 ② 可否を尋ねる ④ 禁⽌なら DENY request イベントに付く判定 照会 Policy Engine イベント履歴 Cedar / Dogwood を評価 request / response / error Gateway に「アタッチする」別リソース セッション単位‧既定の上限は24時間 追記 モデルは呼び出しを「提案」するだけで、可否には触れない 今ココ どこにある 5/13
6. ▪どれも1回ずつ見れば完全に正当なリクエスト 単発では止まらない例 01 バックアップの前に消した 削除の権限はある。対象も合っている。まだ取っていないだけ。 02 同じ人に、同じ通知を何十通も 1通ずつは、正しい宛先に、正しい文面で送られている。 03 少額の返金を、積み上げた 1件ずつは承認基準を満たしている。合計だけが予算を超える。 今ココ なぜ要る 6/13
7. ▪同じリクエストでも、判定に使える材料が変わる 見えている範囲が違う Cedar｜⾒えるのは「今」だけ ApproveSale response GetPrice response Transfer request Transfer request SellShares いま来た request 判定 過去のイベントは評価に⼀切⼊らない。だから同じ⼊⼒なら常に同じ答えになる（＝解析しやすい） Dogwood｜窓の中の「列」が⾒える ApproveSale response within h の窓（いまから遡って測り直される） GetPrice Transfer response request Transfer request SellShares いま来た request 判定 承認があったか‧何回やったか‧いくら使ったかが、そのまま条件式に書ける Dogwood は窓の中の履歴ごと条件に書ける 今ココ なぜ要る 7/13
8. ▪when の隣に 節がひとつ増えただけ when temporal が並ぶ 「1時間以内に、同じ銘柄・同じ株数の承認が下りていること」を条件にします。 dogwood permit (principal, action == AgentCore::Action::"SellShares", resource) when temporal { formerly within 1h AgentCore::Action::"ApproveSale"::response{ input.stock: input.shares: context.input.stock, context.input.shares, output.approved: true } }; 今ココ 何が書ける 8/13
9. ▪上3つが言語のプリミティブ、下4つが標準マクロ 演算子の早見表 有無 直前 継続 回数 種類 合計 変数 formerly previous since count_within count_distinct sum_within bind 今ココ 何が書ける 窓の中で一度でも起きたか ひとつ前の時点を見る ある事象からの継続を見る 窓の中のイベント数 束ねた値の異なり数（_within） 束ねた値の合計 集計に名前を付けて比較する 9/13
10. ▪足したものと、その代償が対になっている 包含関係で見る Dogwood 構⽂的に妥当なCedarポリシーは、そのままDogwoodポリシーとしても妥当 Cedar principal / action / resource when { ... } 現在のリクエストだけを⾒る deny by default‧forbid が permit に勝つ ⾃動推論による静的解析が効く 実⾏前に「何を許し、何を許さないか」を証明できる Dogwood が⾜したもの when temporal { ... } 過去のイベント列を⾒る formerly ＋ count / sum / bind などのマクロ ⼟台は MFOTL（メトリック⼀階時相論理） 静的解析は、いまのところ効かない 実⾏時に履歴を持って初めて判定できる 移⾏作業は不要。書き換えずに、必要な箇所だけ temporal を⾜していける 認可のセマンティクス（deny by default、forbid優先）は変わらない 今ココ 代償 10/13
11. ▪Rust 1.96.1 参照実装のCLI / dogwood 1.0.0 で確認 検証 再生 変換 生成 validate replay lower schema mcp 今ココ 入口 構文・型・スキーマを検査する 履歴を流して判定の変化を見る Cedar に落とした姿を見る tools/list からスキーマを作る 11/13
12. ▪掘る話は6本に分けます このあと話すこと この回は概要だけです。細かいところは順に見ていきます。 イベントの種類と、演算子をひと通り 手元のCLIで動かして、lower で正体を見る 1語違うだけで上限が上限にならない話 認可の置き場所としての AgentCore Gateway AWSが示している実務向けの7つの型 Cedar との使い分けと、採用するときの注意 今ココ おわりに 12/13
13. ▪この回の持ち帰り まとめ 01 乗り換えではなく、足し算 妥当なCedarは妥当なDogwood。移行作業は要りません。 02 過去のイベント列を条件に書ける 承認・順序・回数・累計・鮮度が、宣言で書けるようになります。 03 ただし、タダではない 時相条件には自動推論による静的解析が効きません。 今ココ おわりに 13/13