コンテンツにスキップ

第9章 ツール利用を制御する「ポリシー」 — 学習メモ

書籍「Amazon Bedrock AgentCore実践入門」第9章のサンプルコード（このフォルダ）を読み解いた個人学習メモ。 AgentCore 全体像は ../../lectures/agentcore_basics/STUDY_NOTES.md 参照。 実行検証は伴わない。コードに現れた API 名だけ断定し、読めない挙動は「〜と推測」で明示する。

一言で

ポリシー ＝ 「誰が・どのツールを・どんな条件で呼べるか」を、エージェントやツールのコードを一切変えずに、Cedar（宣言的な許可/拒否言語）でゲートウェイに外付けする仕組み。第8章のインターセプター（Lambda で自由にロジックを書く）に対し、こちらは「宣言的な条件式」で権限を絞る。

全体像

実行コードは無く、.cedar ポリシーファイル4種のみ（マネジメントコンソールのポリシー作成画面に貼り付けて使う）。

ファイル 種別 条件 内容
01_permit_amount.cedar permit context.input.amount < 50000 リファンド金額が5万円未満のときのみ許可（9.2.1）
02_permit_department.cedar permit principal.hasTag("department") == "accounting" 経理部門タグを持つプリンシパルのみ許可（9.2.4）
03_forbid_role.cedar forbid principal.hasTag("role") == "intern" インターン役割を明示的に拒否。forbid は permit より常に優先評価される（9.2.5）
04_permit_pattern_match.cedar permit principal.getTag("department") like "sales/*" department タグが sales/ で始まるものをワイルドカードで許可（9.2.6）

適用は3段階（README）:

  1. マネジメントコンソールで AgentCore の「ポリシーエンジン」を開き、ポリシーエンジンを作成する
  2. 作成したポリシーエンジンにポリシーを追加し、.cedar ファイルの内容を貼り付ける
  3. AgentCore ゲートウェイの設定画面からポリシーエンジンを関連付ける（強制モードを選択）

エージェント・ツール本体のコードは一切変更しない。マネジメントコンソール上の設定だけで権限が絞られる。

使用ライブラリ・原理

Cedar は AWS が公開しているオープンソースの認可ポリシー言語（AWS Verified Permissions 等でも使われる。書籍原稿からの直接引用ではない一般知識として付記）。AgentCore ではゲートウェイに来たアクション呼び出しに対し、登録された permit/forbid ポリシーを全て評価し、1つでも forbid にマッチすれば拒否、forbid に当たらず permit のいずれかにマッチすれば許可、という評価モデルを取る（Cedar 言語一般の仕様。本サンプルの .cedar 自体はこの評価モデルの利用例）。

ファイル別の役割

上記の表（## 全体像）を参照。pyproject.toml は無い（実行コードを持たない章のため）。

中心コードの読み解き

基本文型（01_permit_amount.cedar）

permit(
    principal,
    action == AgentCore::Action::"RefundTarget___process_refund",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/my-gateway"
)
when {
    context.input.amount < 50000
};
行 やってること なぜ
01_permit_amount.cedar:1-5 principal（誰が）・action（何を）・resource（どのゲートウェイの）の3点を指定して permit Cedar の基本文型。この3点にマッチしたリクエストだけが when 節の評価対象になる
01_permit_amount.cedar:3 action == AgentCore::Action::"RefundTarget___process_refund" <ターゲット名>___<ツール名>（トリプルアンダースコア）という命名でアクションを一意に識別する
01_permit_amount.cedar:6-8 when { context.input.amount < 50000 } ツール呼び出し時の実引数（amount）がそのまま Cedar の context.input に渡り、条件式として使える

タグベースの条件（02_permit_department.cedar / 03_forbid_role.cedar）

when {
    principal.hasTag("department") &&
    principal.getTag("department") == "accounting"
};

forbid(
    principal,
    action == AgentCore::Action::"RefundTarget___process_refund",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/my-gateway"
)
when {
    principal.hasTag("role") &&
    principal.getTag("role") == "intern"
};
行 やってること なぜ
02_permit_department.cedar:6-9 principal.hasTag("department") && principal.getTag("department") == "accounting" プリンシパル（呼び出し元）に付与されたタグを条件にする。hasTag で存在確認してから getTag で値比較するため、タグ未設定でもエラーにならない
03_forbid_role.cedar:1-9 forbid で明示的に拒否 Cedar は forbid が permit より常に優先評価される。「原則 permit で許可を積み上げ、例外だけ forbid で塞ぐ」という安全な設計がしやすい

パターンマッチ（04_permit_pattern_match.cedar）

when {
    principal.hasTag("department") &&
    principal.getTag("department") like "sales/*"
};
行 やってること なぜ
04_permit_pattern_match.cedar:6-9 like "sales/*" ワイルドカードパターンマッチ。部署名のプレフィックス（例: sales/tokyo）で許可範囲を柔軟に指定できる

学んだこと（要点）

  • 適用は3段階（①ポリシーエンジン作成 → ②.cedar 貼り付け → ③ゲートウェイに強制モードで関連付け）。エージェント/ツールのコード変更は不要
  • forbid は permit より優先評価される。「基本 permit で許可を積み上げ、例外だけ forbid で塞ぐ」設計が安全に書ける
  • アクション名は <ターゲット名>___<ツール名> のトリプルアンダースコア命名。ゲートウェイに登録されたツール単位で権限を切れる
  • context.input.<パラメータ名> でツールの実引数そのものを条件に使える（金額チェック等、ツール内部のロジックを一切変えずに外側で強制できる）

落とし穴・現代版に移植するなら

  • サンプルの ARN（arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/my-gateway）は自分の環境のゲートウェイ ARN に置き換え必須（README）
  • pyproject.toml は存在しない（実行コードを持たない章のため）
  • ../../lectures/guardrails_basics/ex03_tool_permission_gate.py の @wrap_tool_call（allow/ask/deny の権限ゲート）と同じ思想の「宣言的・ゲートウェイ側版」と言える。ex03 はエージェント側コードの middleware で判定するのに対し、Cedar はコードの外（マネコン上のポリシー）で判定する。どちらも「構造の防御」側だが、Cedar はエージェント側のコード変更ゼロで権限を絞れる点が異なる

記事参照

作成: 2026-07-17 ／ 最終更新: 2026-07-17