エージェントの権限とガバナンスを設計問題で鍛える — AI に設計案を出させ、公式のベストプラクティスで採点する

Google Cloud の Professional Agentic Architect の試験ガイドは、出題のおよそ 15% を §5「エージェントのワークフローの保護とガバナンス」に、およそ 13% を §1「ローコードの道具でのエージェントづくり」に割り当てている（2026 年 10 月時点）。エージェントのガバナンスを問う設問は、製品名を覚えるだけでは解きにくい。エージェントをどの ID で動かし、どこで通信を止め、どこで人が承認するかを、ひとつの設計として組み立てる判断が要る。しかも §5 に関わる製品の多くは 2026 年 4〜8 月に一般提供（GA）になったばかりで、Google Cloud のアカウントが無ければ手元で動かして覚えることもできない。

※本記事にはアフィリエイト広告（PR）が含まれます。

そこで本記事では、設計案を書いて採点するという練習を、AI を相手に一度回した。当サイトが作った設計の課題（試験の問題ではない）を Claude Code の claude -p に解かせ、課題だけを渡す条件 A と、試験ガイド §5 の項目を観点として添える条件 B で、設計案を 1 回ずつ出させた。採点には、Google Cloud と ADK の公式文書から作った 15 行の採点表を使った。この実行では、A は 15 行中 7 行、B は 15 行中 10 行を満たした。両方が落とした行のうち Auth Manager は、モデルの知識の締切（2026 年 6 月）より後に GA になった機能だった。ただし、同じく両方が落とした deny ルールは、IAM の deny ポリシーとして 2022 年から GA で、締切では説明できない。

採点表の 15 行は、出典のページ名とともに記事に載せる。自分で書いた設計案も、AI に出させた設計案も、同じ表でそのまま採点できる。なお、当サイトはこの試験を受験していない。Google Cloud のアカウントを使った確認もしておらず、製品の設定と動作は 2026 年 10 月時点の公式文書の記述による。

試験ガイドの §5 と §1 は何を問うのか

試験ガイドの §5 は「Securing and governing agentic workflows」と題され、5.1 と 5.2 の二つの小項目からなる。5.1「エージェントのセキュリティとガバナンスの設定」が挙げる考慮点は四つある。

• 認証と安全なツールの実行（例: OAuth 2.0 を使った、エージェントからツールへの API 呼び出し）
• Agent Identity を使った PAB（principal access boundary）ポリシーの設定
• 通信を監視し、エージェントを追跡するための Agent Gateway の設定
• エージェントのガバナンスとポリシーの強制の設計と設定（例: Agent Registry と Model Armor）

5.2「エージェントの安全な振る舞いと実行の実装」が挙げる考慮点は二つだ。

• 適切な安全の枠組みとガードレールの設計（例: Agent Gateway、Model Armor、人の承認〔human-in-the-loop、HITL〕）
• データへの安全なアクセスと ID の伝播の設定（例: Agent Gateway と Agent Registry）

権限の話は §5 だけに閉じていない。§3.2 にも「Configuring agent permissions (e.g., Agent Identity)」があり、§3.3 も Agent Identity・Agent Registry・Agent Runtime とエージェントのポリシーを例に挙げる。また、試験ガイドの対象ツールの一覧には、§5 の本文に出てこない「Auth Manager (OAuth 2.0)」と「Sensitive Data Protection」も入っている。試験の全体像と、申込から認定までの流れは Google Cloud の Professional Agentic Architect は何を証明する資格なのか — 11月の一般提供までに準備する4週間の全体設計（2026-10-19 公開） にまとめた。

§5 の部品は、どれも Google Cloud の上で設定して使うものだ。ADK のエージェントのように手元の PC で書いて動かす練習（ADK のエージェントを手元の PC で書いて動かす — 出題の3割を占めるカスタムエージェントを Google Cloud なしで練習する（2026-10-21 公開））は、ここではできない。そこで、設計案を文章で書き、公式のベストプラクティスに照らして採点する練習に置き換える。§1 のローコードの製品は、後半で公式文書の要点だけをまとめる。

ID と権限と認証 — Agent Identity・PAB・Auth Manager の公式の要点

Agent Identity — エージェントごとの ID

Agent Identity は、エージェントごとに暗号学的な ID を与える仕組みだ。公式文書の原文は「a strongly attested, cryptographic identity for each agent」で、SPIFFE の標準に基づく。サービスアカウントとの違いとして、既定では複数のワークロードで共有されないこと、なりすまし（impersonation）ができないこと、長期間有効なサービスアカウントの鍵を作れないことの三つが挙がっている。共有のサービスアカウントの代わりにエージェントごとの ID を使い、権限を持ちすぎたエージェントをなくす、というのが公式の説明だ。

Agent Identity の概要ページが対応するサービスとして挙げるのは、Agent Runtime（旧 Agent Engine）、Gemini Enterprise、Cloud Run の三つだ。ただし、Cloud Run でこの機能を設定するページにはプレビュー（Preview）の表示があり、一覧に無い GKE にも、プレビューの「Agent Identity for GKE」の文書がある（いずれも 2026 年 10 月時点）。ID の証明書（X.509）は 24 時間有効だ。運用の面では、二つの記述が採点表に効く。一つは、エージェントが利用者の代理で動くと、ログにエージェントと利用者の両方の ID が残ること。もう一つは、エージェントを削除しても、その ID を参照する IAM の割り当て（バインディング）は消えず、廃止の作業の一部として手で消す必要があることだ。

PAB — エージェントが届く資源の上限

PAB（Principal Access Boundary）ポリシーは、エージェントが届く資源の上限を決める。公式文書によると、エージェントがほかにどんな権限を持っていても、PAB は届く資源を限る。上限として書ける資源（ルールの resources）は組織・フォルダ・プロジェクトで、書いた資源とその子孫に効く。REST の仕様が対応する種類として挙げるのもこの三つで、BigQuery のデータセットのような、プロジェクトの中の個々の資源は挙がっていない。プロジェクト単位の対象（principal set）には、サービスアカウントやワークロード ID のプールと並んで、エージェントの ID も含まれる。

ただし、PAB が止めるのは、PAB が対応している権限を使ったアクセスだけだ（原文「only block access attempts that involve supported permissions」）。PAB を付ければすべての権限が止まる、とは読めない。また、適用する版（enforcement version）に latest を指定することは、思わぬところでアクセスを失うおそれがあるとして勧められていない。上限は、1 つのポリシーのルールが 500、組織あたりのポリシーが 1000、1 つの対象に結び付けられるポリシーが 10 だ。

IAM の一般的なベストプラクティス

エージェント向けの製品に加えて、IAM の一般的なベストプラクティス（公式ページ「Use IAM securely」）も採点表に入れた。本番では基本ロールを付けず、必要を満たす最も狭い事前定義ロールかカスタムロールを使う。ロールは必要な最小の範囲で付け、アプリケーションの構成要素ごとに信頼の境界を分ける。ほかの方法があるなら、サービスアカウントの鍵は使わない。ADK の安全ガイドも、資源に読み取り専用の権限だけを与えれば、モデルが何を決めてもツールは書き込みができない、と同じ考えを書いている。

Auth Manager — 外部 API の認証を預ける

試験ガイドの対象ツールにある「Auth Manager (OAuth 2.0)」は、公式文書では「Agent Identity auth manager」と呼ばれる。外部のツールへの認証のために、資格情報の保管庫と認証の仲介を一か所で担うサービスだ。API キー、OAuth のクライアントシークレット、利用者のトークンを Google が管理する保管庫に置くので、コードへの埋め込みや自前のデータベースでの保管を避けられる。さらに、利用者の同意、認可コードの交換、トークンの更新といった OAuth 2.0 の多段の流れも、自前のバックエンドのコードなしで扱う。

認証方式の推奨は、Agent Identity の概要ページに書かれている。OAuth に対応した外部サービスとの機械どうしの認証には 2-legged OAuth を勧め、エージェントが特定の利用者の代理で動くときは 3-legged OAuth を使う。平文のパスワードを使う HTTP の basic 認証は勧めない。加えて、Agent Identity を Agent Gateway と Gemini Enterprise の両方と組み合わせた構成では、Gemini Enterprise のコネクタで用意した利用者の資格情報などを Auth Manager が暗号化してゲートウェイで復号するので、エージェントは生の資格情報に触れられない。これに対し、Agent Runtime の上で ADK から Auth Manager を使う流れでは、Auth Manager は資格情報（API キーか OAuth のトークン）をエージェントに返し、エージェントがそれを付けて外部の API を呼ぶ。一方、GitHub と Microsoft との連携は単一のスコープに限られる、といった制約もある。

Auth Manager が肩代わりする OAuth 2.0 の流れや、資格情報をコードに埋め込まない設計は、エージェントに限らず API の安全な設計の基本でもある。API の設計から実装までのセキュリティの原則を扱う一冊を挙げておく。

セキュアAPI 設計・構築・実装を貫く原則（翔泳社・書籍）

¥4,950 （2026/10/13 12:15時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

通信と検査 — Agent Gateway・Agent Registry・Model Armor の公式の要点

Agent Gateway — 既定で拒否する通信の出入口

公式文書は Agent Gateway を、Agent Platform の「key enforcement component」と呼ぶ。エージェントのやり取りすべてについて、ネットワーク上の入口と出口になる部品だ。既定ではすべての接続を止め、IAM のポリシーで明示的に許可したものだけを通す。モードは二つあり、クライアントからエージェントへの内向き（Client-to-Agent）と、エージェントから外への外向き（Agent-to-Anywhere）に分かれる。ネットワーク層の通信の記録は Agent Observability に送られ、ゲートウェイの許可と拒否の判定もログに残る。

統治できる実行基盤には注意が要る。概要ページが統治できる実行基盤として挙げるのは Agent Runtime と Gemini Enterprise の二つで、Agent Runtime では内向きと外向きの両方に対応するが、Gemini Enterprise では外向きだけで、内向きのモードには対応しない。Cloud Run と GKE は、この一覧に無い。一方で、プレビューの「Agent Identity for GKE」の文書は、GKE 上のエージェントを Agent Registry や Agent Gateway と組み合わせられると書き、Agent Registry に登録したエージェントどうしの通信に IAM のポリシーを掛けるには Agent Gateway を使う、とする。文書によって書いている範囲が違い、GKE の側の文書はプレビューなので、GKE で Agent Gateway を使う設計は、プレビューの機能に頼るものとして扱う。Agent Identity が Cloud Run に対応していることとも混同しやすいので、ここは分けて覚える。なお、概要ページの制限事項によると、1 つの Agent Gateway は、Agent Registry に登録した資源を 5,000 まで統治できる。

Agent Registry と IAM のポリシー

Agent Registry は、エージェントの構成要素を保管し、見つけ、統治するための一元的なカタログだ。Agent Gateway の概要ページは、呼び出し先を Agent Registry に登録し、資源ごと・ツールごとの細かいアクセスポリシーを書くことを勧める。登録していない宛先には、その URL を対象にした IAM のアクセスポリシーを明示的に書く必要がある（公式が勧める IAM Unified Access Policies では、ルールの条件に宛先のホスト名とパスを書く）。一方、Agent Runtime と Gemini Enterprise のエージェントには、Agent Identity と Agent Registry への登録が自動で付く。

Agent Gateway が使う IAM のポリシーには、許可と拒否のルールがある。IAM Unified Access Policies（UAP）の概要ページの「Best practices」の節は、次の四つを挙げる。

• 新しいポリシーや変えたポリシーは、まず dry-run のモードで出し、動いている通信を止めずに確かめる（dry-run では、許可されていない通信を Cloud Audit Logs に記録するが止めない）
• 必要な権限だけを付け、CEL の条件にはワイルドカードではなく具体的なツール名やパスを書く
• 本番の宛先への破壊的なツールの呼び出しのような重大なガードレールは、明示的な deny ルールで実装する
• Cloud Audit Logs とポリシーの設定を定期的に見直す

同じページは、deny のルールは allow のルールより優先されるのでガードレールに向く、とも書く。例に挙がるのは、エージェントにデータベースのレコードの削除と更新を禁じる deny ルールだ。

Model Armor と Sensitive Data Protection

Model Armor は、AI のアプリケーションの安全性を高める Google Cloud のサービスで、入力（プロンプト）と出力（応答）の両方を検査する。概要ページは、利用者のプロンプト用とモデルの応答用でテンプレートを分けること（「Considerations and best practices」の節）、まず Inspect only（検査だけ）のモードで始めてブロックされる割合と効き目をつかむこと（「Define the enforcement type」の節）、組織の最低基準を floor settings で決めること（「Model Armor floor settings」の節）を勧める。Inspect only は Cloud Logging が有効でないと役に立たず、floor settings より緩いテンプレートは作れない。

Agent Gateway と組み合わせると、内向きではクライアントのプロンプトのインジェクションと有害な内容を、外向きではツールに送る内容とエージェントの応答のデータ漏えいとインジェクションを検査する。ただし、この連携では PDF などの文書やファイルのアップロードを含むプロンプトと応答は検査できない。ファイルを検査するなら、Model Armor の API を直接呼ぶ（Model Armor が検査するファイルの大きさは 4 MB まで）。また、Model Armor と連携先のサービスは同じリージョンに置く必要があり、内向きのインライン保護は ADK で作ったエージェントだけが対象になる。外向きのインライン保護も、MCP サーバー、OpenAI 形式のサービス、Agent Gateway を通る A2A との連携に限られる。

プロンプトへの攻撃を検査する手段は、Model Armor だけではない。CX Agent Studio のガードレールにも prompt guard があり、プレビュー（Preview）の Semantic governance policies もツールの呼び出しを検査する。後者については、自然文のポリシーを LLM で判定するので判定が正確でない場合がある、と公式が書いている。

Sensitive Data Protection（SDP）は、個人情報や資格情報のような機微な情報を検査して伏せるサービスだ。Model Armor の中で使う場合、基本設定は検査だけで SDP のテンプレートを使えず、検出できる情報の種類も主に米国向けに限られる。高度な設定なら検査と匿名化（de-identification）の両方ができ、用途に合う情報の種類をテンプレートで決められる。日本の個人情報を扱う設計では、この違いが採点に効く。

提供状態（2026 年 10 月時点）

日付は各製品のリリースノートの告知日だ。名前と状態は月単位で変わっているので、設計を考えるときは公式のリリースノートを開き直す。

Model Armor が検査するプロンプトインジェクションやデータ漏えいは、生成 AI のアプリケーション全般に共通するリスクだ。製品の設定とは別に、リスクの種類と対策の考え方を押さえておきたい人には次の一冊がある。

生成AIセキュリティの教科書

¥1,650 （2026/09/22 15:04時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

エージェントのガバナンスの採点表 — 公式のベストプラクティスから作った 15 行

上の公式文書から、設計案に書かれているべき確認点を 15 行に分けた。各行は 0 か 1 で判定する。「満たすとみなす条件」を満たす具体的な記述があれば 1、無ければ 0 だ。製品名を挙げただけの記述、たとえば「Model Armor を使う」とだけ書いて入力と出力の区別が無い場合は 0 にする。判定に迷った行は保留とし、理由を記録して合計に入れない。合計は「1 の数／判定した行の数」で書く。

試験ガイドの列は、その行が対応する小項目の番号だ。#11 の SDP は §5 の本文に名前が無く、対象ツールの一覧に入っている。#12 の人の承認は製品ではなく設計パターンなので、手段を問わず「承認の段階と場所」で判定する。

誤りとして数える記述

抜けとは別に、次の記述を誤りとして数える。誤りは、その行が 1 であっても記録する。

• E1: Agent Gateway の概要ページが統治できる実行基盤として挙げない Cloud Run などの上のエージェントの通信を、Agent Gateway で統治すると書く（概要ページが挙げるのは Agent Runtime と Gemini Enterprise）。GKE は、プレビューの Agent Identity for GKE の文書が Agent Gateway との連携を挙げるので E1 に数えず、設計案が触れたら、プレビューと書いているかを記録する
• E2: Agent Gateway の Model Armor で、PDF などのファイルも検査すると書く
• E3: Gemini Enterprise 上のエージェントに、内向き（Client-to-Agent）の Agent Gateway を置く
• E4: ADK の Tool Confirmation を、Agent Runtime の管理セッション（VertexAiSessionService）と組み合わせて承認を実装する
• E5: 存在しない製品名や引数名を使う
• E6: PAB を付ければすべての権限が止まると書く

採点表に入れなかったもの

候補に挙がったが、採点表に入れなかったものもある。Semantic governance policies はプレビューで、判定が正確でない場合があると公式が書き、試験ガイドにも名前が無い。VPC Service Controls（サービスの境界でデータの持ち出しを防ぐ手段）は、Agent Gateway と組み合わせたときにどの部分に効くかを当サイトで詰め切れていないため、採点しない。ADK の安全ガイドが勧める「ツールの作りで制限する」設計（原文「Design tools defensively」）は、§5 の例示に無く、#2・#7 と重なるので外した。Cloud Trace との連携、Agent Registry のスキルの管理、Model Armor の画像の検査は、いずれもプレビューなので入れていない。

設計の課題と実行の条件

課題は当サイトが作ったもので、試験の問題ではない。公式例題や模擬問題の文は使っていない。採点表の 15 行がすべて判定できるように、実行基盤を Agent Runtime に指定し、読むだけのデータベース、OAuth 2.0 に対応した社外の API、取り消しにくい発注、社員の名義、個人情報、作り直しの予定を条件に入れた。実行基盤を AI に選ばせると、Cloud Run を選んだ場合に Agent Gateway の行が判定できなくなるためだ。条件 A で渡した文面の全文を載せる。

3Dプリントの受託をしている小さな会社で、在庫を見て仕入れ先にフィラメントを発注する AI エージェントを Google Cloud に置きたい。条件は次のとおり。

- 実行基盤は Agent Runtime（旧 Agent Engine）。エージェントは ADK で作る。
- 在庫データは BigQuery の表にあり、エージェントは読むだけでよい。この表には仕入れ先の担当者の氏名と電話番号（日本の個人情報）も入っている。
- 発注は社外の仕入れ先の API で行う。この API は OAuth 2.0 に対応している。発注には金額があり、一度送ると取り消しにくい。
- 社員がエージェントを呼び出し、発注は依頼した社員の名義で行う。
- このエージェントは、来年作り直して新しいエージェントに置き換える予定がある。

このエージェントの権限・認証・通信・入出力の検査・人の承認・記録と監査について、Google Cloud で安全に運用するための設計案を、具体的な製品名と設定を挙げて日本語で書いてください（2,000字程度まで）。

条件 B では、この文面の後に「設計案では、次の観点（Google Cloud Professional Agentic Architect の試験ガイドの §5 の項目、原文のまま）をすべて扱ってください。」と書き、5.1 と 5.2 の 6 項目を英語の原文のまま添えた。二つの条件の違いは、この一節だけだ。

実行には claude -p を使い、--model sonnet を付けて、ツール・MCP サーバー・設定を読まない最小の構成で、各条件 1 回ずつ動かした（2026-10-12）。システムプロンプトには、両方の条件とも「You are a careful assistant.」の 1 文を指定した。出力に記録されたモデルの ID は claude-sonnet-5-5（Claude Sonnet 5.5）だ。費用は A が 0.063 ドル、B が 0.053 ドルで、設計案の長さは、空白・改行と Markdown の記号も含めて数えると A が 2,861 字、B が 2,494 字だった。判定は採点表の条件に照らして 1 行ずつ行い、根拠になった一節を記録した。判定は 1 回で、複数の判定者による照合はしていない。

結果 — 課題だけは 15 行中 7 行、§5 の項目つきは 15 行中 10 行

あらかじめ決めた誤り E1〜E6 に当たる記述は、A にも B にも無かった（E4 は両方とも保留、B の E6 も保留。理由は後で書く）。ただし、これは E1〜E6 の範囲での話で、B の PAB の書き方には、この六つの外の不正確な点がある（後の節で書く）。

両方が満たした行は七つある。エージェントの ID（#1）、最小の権限（#2）、入力と出力の検査（#9）、個人情報の検査（#11）、人の承認（#12）、社員の ID の伝播（#13）、廃止時の後片付け（#15）だ。#1 は、B が Agent Identity を名指ししたのに対し、A は Agent Identity ではなく、エージェント専用のサービスアカウントと鍵の作成の禁止で満たした。#2 では、両方とも在庫の表から個人情報の列を除いた承認済みビュー（authorized view）を見せ、データの読み取りとジョブの実行のロールだけを付けて、書き込みの権限は付けないと書いた。#15 では、来年の作り直しという条件に応えて、両方が廃止の手順を番号つきで書いた。

反対に、両方が落とした行は五つで、Auth Manager（#4）、deny ルール（#7）、記録だけのモード（#8）、floor settings（#10）、定期的な監査（#14）だ。#14 については、両方とも Cloud Audit Logs、保持期間をロックしたバケットへの保存、アラートまでは書いたが、記録を定期的に見直す運用が無かった。採点表は記録と見直しの両方を求めるので、A・B とも同じ基準で 0 にした。#11 は両方 1 だが、日本の個人情報に要る高度な設定のテンプレートかどうかは、どちらも書いていない。

B だけが満たした行は三つで、PAB（#3）、Agent Gateway（#5）、Agent Registry（#6）だ。いずれも、§5 の本文に製品名が例として出てくる行である。

課題だけの設計案は、従来の部品で組んだ

条件 A の設計案は、Agent Identity・PAB・Agent Gateway・Agent Registry を一度も使わなかった。代わりに、Google Cloud で以前から使われてきた部品で組んでいる。ID は「Agent Runtime には専用のサービスアカウント sa-orderagent-v1@… を指定する」とし、組織ポリシーの iam.disableServiceAccountKeyCreation でサービスアカウントの鍵を作らせない。通信は VPC Service Controls の境界で囲み、外向きは「Private Service Connect インターフェース経由で自社 VPC に出す（要確認）」としたうえで、Secure Web Proxy で仕入れ先の API のドメインだけを許可する。

外部 API の認証（#4）も同じ構図だった。A は仕入れ先の OAuth 2.0 を社員ごとの同意を取る認可コードフローにし、リフレッシュトークンをエージェントのセッションに置かないと書いた。社員の名義という条件には応えている（#13 は 1）。ところが、トークンの管理は「トークン仲介用の小さな Cloud Run サービス」を自前で作る形で、Auth Manager の名前は無い。Auth Manager が自前のバックエンドのコードなしで扱うとするトークンの管理を、設計案のほうから自前で作っている。

これは、A の設計が安全でないという意味ではない。当サイトは、A が挙げた部品が Agent Runtime の上でどう組み合わさるかを確かめておらず、A 自身も Private Service Connect に「要確認」と付けている。採点表が測っているのは、§5 が例に挙げる部品と公式のベストプラクティスにどれだけ沿っているかだ。試験ガイドが §5 でこれらの部品を例に挙げている以上、試験の準備ではこの差を見ておく意味がある。

§5 の項目を観点として渡すと、製品名の行が増えた

条件 B の設計案は、冒頭で「以下の設定名は方針レベルで、実装前に最新の公式ドキュメントで確認してください」と断ったうえで、§5 の例に出る製品を順に使った。ID は「専用の Agent Identity を付けます。既定のサービスアカウントや共有アカウントは使いません」とした。PAB は「組織レベルの Principal Access Boundary ポリシーを作り」、対象を「このプロジェクトと在庫データセットに限ります」と書いた。通信は「エージェントの外向き通信は Agent Gateway を経由させ」、宛先を許可リストに限る。Agent Registry には、エージェントと二つのツール（BigQuery の読み取りと発注 API）を登録する。これで #3・#5・#6 の 3 行が 1 になり、#1 も Agent Identity を名指しした形で 1 になった。

ただし、#3 の 1 は、採点表の条件（PAB を名指しし、何に限るかを書く）を満たしたという意味で、B の PAB の設定がそのまま組めるという意味ではない。PAB のルールに書ける資源は組織・フォルダ・プロジェクトで、書いた資源とその子孫に効く。BigQuery のデータセットは書ける種類に入っていないので、「在庫データセットに限ります」は PAB では設定できない。B の設計で PAB が限れるのはプロジェクトまでで、データセットの単位で絞るのは、B が同じ見出しの下で書いた IAM のロール（在庫データセットへの BigQuery Data Viewer）の役目になる。この点は誤り E1〜E6 のどれにも当たらないので誤りの数には入れていないが、採点表の外の不正確な点として記録した。

一方で、Auth Manager（#4）は B でも 0 のままだった。B は 3-legged の認可コードフローを選び、「ADK のツール認証(AuthConfig、request_credential)」でトークンを取り、「トークンはマネージドな保管先に置きます」と書いたが、保管先の製品名は無い。§5 の本文は「OAuth 2.0」と書くだけで、Auth Manager の名前は対象ツールの一覧にしか出てこない。この実行では、観点として渡した文に名前がある部品は設計案に入り、名前が無い仕組み（Auth Manager、deny ルール、dry-run、floor settings）は入らなかった。

また、B の PAB の段落には「IAM の付与が誤っても、境界外のリソースにはアクセスできません」という言い切りがあった。Agent Identity の概要ページは、PAB がほかの権限にかかわらず届く資源を限る、と書いており、この文はそれに近い。一方で PAB のページは、PAB が止めるのは対応している権限を使ったアクセスだけだと書く。公式文書の中で書き方が分かれているため、本記事ではこの文を E6（誤り）とは数えず保留にした。ただ設計では、対応していない権限を使ったアクセスは PAB では止まらない前提で、ほかの仕組み（最小権限や deny ルール）と組み合わせて考えるほうが安全だ。

両方が落とした Auth Manager は、知識の締切の後に GA になった

Anthropic のモデル一覧によると、Claude Sonnet 5.5 の知識の締切（reliable knowledge cutoff と training data cutoff）はどちらも 2026 年 6 月で、月までしか書かれていない。両方の設計案が落とした行を、この締切と並べると次のようになる。

B が使えた Agent Gateway と Agent Registry の GA は 2026 年 6 月 18 日で、締切と同じ月にあたる。A はこの二つを使わず、B は §5 の文で名前を渡されると使った。さらに、試験ガイドの PDF のメタデータにある作成日は 2026 年 8 月 31 日で、これも締切より後だ。出題範囲は、モデルの知識より新しい時点の製品で書かれている。

ただし、この 1 回の実行から「締切が抜けの原因だ」と言い切ることはできない。Auth Manager は、締切より前の 2026 年 4 月にプレビューとして告知されていた。deny ルールの抜けは、締切では説明できない。IAM の deny ポリシーは 2022 年 10 月に GA になっており、Agent Identity の概要ページも IAM の allow と deny の両方のポリシーに対応すると書く。締切の後に GA になったのは、allow と deny のルールを 1 つのポリシーに並べられる UAP のほうだ。floor settings と定期的な見直しは、締切と関係なく落ちた可能性がある。言えるのは、この実行では、締切の後に GA になった機能が両方の設計案から抜けた、というところまでだ。

したがって、AI に設計案を出させて学ぶなら、採点表の出典のページを先に AI に渡すことを勧める。本記事の実行では、公式文書を渡す条件は試していない。資料を渡す前と後で AI の答えがどう変わるかは、Agentic Architect の出題範囲の新しい製品を AI はどこまで知っているか — 試験ガイドの 28 項目を公式ドキュメントで照合した（2026-10-20 公開） で、試験ガイドの対象ツールの 28 項目について比べている。

人の承認（HITL）は設計パターンとして書く — Tool Confirmation の注意

人の承認の行（#12）は、両方の設計案が満たした。どちらも発注のツールを承認なしでは動かない形にし、承認の画面に仕入れ先・品目・数量・金額・依頼者（発注の名義）を出し、一定の金額を超えたら上長の承認も要るとした。さらに両方とも、承認した内容のハッシュと実行する内容が一致しなければ止めること、冪等キーを付けて二重の発注を防ぐことを書いている。この二つは採点表の外だが、承認と実行のずれを防ぐ工夫として読める。

Google Cloud の設計ガイド（Cloud Architecture Center の「Choose a design pattern for your agentic AI system」）は、人の監督や主観的な判断、重要な操作の最終承認が要る作業に human-in-the-loop のパターンを使うよう勧め、例に大きな金額の取引の承認を挙げる。同じガイドは、利用者とやり取りする外部の仕組みを作って保守する必要があるため、このパターンは設計を大きく複雑にしうる、とも書く。採点表が「承認の段階」だけでなく「誰がどこで承認するか」まで求めるのは、このためだ。同じ Architecture Center のセキュリティ運用（SOC）の事例にも「Implement human-in-the-loop approval.」の項目がある。

注意が要るのは、実装の手段だ。両方の設計案は、ADK のツール確認（Tool Confirmation）の require_confirmation を Agent Runtime の上で使う案を書いた（A は長時間実行ツールとの二択）。ADK の公式文書は、この引数を True にするとツールの実行前に確認を求められると書く。その一方で、Tool Confirmation は実験的な機能で既知の制約があり、VertexAiSessionService には対応しないと明記している。Agent Runtime の管理セッションは、この VertexAiSessionService だ。設計案はセッションの種類を書いていないので、E4 は両方とも保留にした。A は、導入前の確認事項に「ADK のツール確認機能の最新仕様」を自分で挙げている。

人の承認は、特定の製品の機能ではなく設計のパターンだ。手段は ADK の Tool Confirmation のほかにもある。ローコードの側では、Workflow Builder の承認のステップに達すると実行が止まり、Runs タブに「Needs Review」の状態で現れる。試験の準備では、人の承認が出てきたら、どの手段で、どこに承認の場所を置き、その手段に制約がないかまで考える。

人の承認を誰がどこで行うかは、製品の機能だけでは決まらず、組織の役割分担の設計になる。AI エージェントを組織に入れるときの運用と体制を扱う一冊を挙げておく。

AIエージェント組織実装の最適解

¥2,200 （2026/09/22 14:35時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

§1 のローコード — Agent Designer（Workflow Builder）・CX Agent Studio・Agent Search

§1（およそ 13%）は、1.1 と 1.2 の二つの小項目からなる。1.1 は、ローコードの道具でエージェントのワークフローと振る舞いを設定する項目だ。状態に基づくワークフロー（pages、transition routes、event handlers）の設定と、システム指示とコンソール内のプロンプトテンプレート（few-shot や chain-of-thought）の作成を挙げ、道具の例に Gemini Enterprise の Agent Designer と CX Agent Studio を出す。1.2 は、企業のデータを Gemini Enterprise につなぐ項目で、社内のデータに安全につないで問い合わせる設定（例: Gemini Enterprise と Agent Search）と、動画・音声・画像のような非構造のマルチモーダルなデータの取り込みを挙げる。後者の中身は、本記事では調べていない。

Agent Designer は、2026 年 9 月の公式の告知からは Workflow Builder（旧 Agent Designer）の名前で案内されている。試験ガイドの PDF はその告知より前に作られており、旧名で書いている。公式文書は Workflow Builder を、Gemini Enterprise の Web アプリでチャットのエージェントとワークフローを作り、管理し、有効にする、ノーコード・ローコードの対話的な基盤と説明する。作り方は自然文のプロンプトか視覚的なエディタだ。また、エージェントやワークフローが使える操作とツールは、Gemini Enterprise の管理者が用意したデータコネクタ・ツール・権限に限られる。ローコードの道具の中にも、エージェントのガバナンスの考え方が組み込まれている。

試験ガイドの「pages、transition routes、event handlers」は、Dialogflow CX の用語だ。Dialogflow CX は会話を状態機械として表し、セッションの状態をページ（page）で表す。ハンドラーは、利用者への応答を作ったり、今のページから別のページへ移したりして会話を制御する。CX Agent Studio は、公式文書の言葉では「minimal code」の会話エージェントの構築環境で、ADK の上に作られ、Dialogflow CX の発展形にあたる（2026 年 2 月 4 日に GA と告知）。CX Agent Studio では flow を使うエージェントを作れ、会話は END_SESSION に達するまで flow に引き渡される。つまり、この三つの概念は Dialogflow CX の flow のもので、Workflow Builder の機能として覚えないほうがよい。

1.2 の「安全につなぐ」については、Gemini Enterprise の権限に応じた検索（permission-aware enterprise search）が公式の手がかりになる。エディションの比較表では、全エディションにこの機能の印がある。Agent Search（旧 Vertex AI Search）は、Google 品質の検索体験を作るためのサービスで、製品ページでは GA と案内されている。

Gemini Enterprise を使うには、利用者ごとのライセンスが要り、ライセンスを得るにはエディションのサブスクリプション（月単位か年単位）が要る。エディションは Business・Standard・Plus・Pay-as-you-go・Frontline の五つで、Plus エディションには 30 日間の無償の試用がある。金額はここでは書かない。Pay-as-you-go は使った分を月ごとに払う形で公式の料金表があるが、ほかのエディションの金額は公式文書に見つけられなかった。ここまでの §1 の内容は公式文書の要点で、当サイトはどの製品も使っていない。

この実行で言えないこと

この実行から言えることには限りがある。読み違えやすい点を並べておく。

• 各条件 1 回の実行で、同じ課題をもう一度解かせたときに行がどれだけ入れ替わるかは測っていない。7／15 と 10／15 の差は、この 1 回ずつの差だ
• 比べたモデルは Claude Sonnet 5.5 だけで、ほかのモデルでは試していない。「AI は Agent Gateway を使わない」のような一般化はできない
• 採点したのは当サイトの制作に使っている AI（Claude）で、事後の確認でも同じ会社の AI の別の実行が全セルを見直した。人や他社のモデルでは照合していない。設計案を書いたモデル（Claude Sonnet 5.5）と同じ会社のモデルが採点した形になる。A の #1 は、Agent Identity の名指しまで求める人なら 0 にしうる（その場合 A は 15 行中 6 行）。保留にした両方の E4 と B の E6 は、該当にも該当なしにもなりうる
• 採点表は当サイトが公式のベストプラクティスから作ったもので、試験の採点方法ではない。点数は合否の目安にならない
• 公式文書を AI に渡す条件は試していない
• 設計案を Google Cloud に組んで動かしてはいない。A の Private Service Connect や Secure Web Proxy、B の ID の伝播の書き方が、書いたとおりに動くかは確かめていない
• 製品の名前と提供状態は 2026 年 10 月時点のもので、月単位で変わっている

自分の設計案を採点表で採点する手順

この採点表は、読者が自分の設計案を採点するために使える。手順は次のとおりだ。

1. 上の課題を読み、AI の設計案を見る前に、自分で設計案を書く。権限・認証・通信・入出力の検査・人の承認・記録と監査の六つの観点を見出しにすると書きやすい
2. 採点表の 15 行を上から順に 0・1・保留で判定し、誤り（E1〜E6）は別に数える。製品名を書いただけの行は 0 にする
3. 0 になった行は、出典のページを開いて原文を読み、自分の設計案のどこに何を足せば 1 になるかを一文で書く
4. 同じ課題を AI に解かせ、同じ表で採点して自分の設計案と並べる。課題だけの場合と §5 の項目を添えた場合の両方で出させると、観点の与え方で設計がどう変わるかが分かる
5. 課題の条件を変えて、別の行と誤りを試す。実行基盤を Gemini Enterprise にすれば外向きしか統治できない点（E3）が、発注に PDF の見積書を添える条件を足せばファイルの検査（E2）が問われる

手元のコーディングエージェントでも、承認なしで何をさせるかという問いは同じ形で出てくる。Claude Code の権限の考え方は Claude Code の権限と費用を、常駐させる前に決める — 承認なしで走る実行に何を渡すか（2026-09-26 公開） に、試験ガイドに出てくるコーディングエージェントの設定は 試験ガイドに出てくる Claude Code の設定を手元で覚える — コーディングエージェントの MCP・スキル・フック・サブエージェントを1つずつ試す（2026-10-23 公開） に書いた。

採点表で 0 になった行を埋めるには、個々の製品より先に、Google Cloud の構成全体の中でエージェントをどう守るかを考える必要がある。AI を組み込んだ Google Cloud の設計を扱う次の一冊が、その下地になる。

Google Cloud設計完全ガイド AIを組み込んだ次世代アーキテクチャの考え方（日経BP・書籍）

¥3,960 （2026/10/13 12:11時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

まとめ — エージェントのガバナンスは「どこで止め、誰が承認するか」まで書く

試験ガイド §5 が問うエージェントのガバナンスは、製品の名前を並べるだけでは満たせない。Agent Identity でエージェントごとの ID を持たせ、PAB で届く資源の上限を決め、Agent Gateway で既定で拒否し、deny ルールで重大な操作を止め、Model Armor で入力と出力を検査し、取り消しにくい操作の前に人が承認する。そのうえで、どこまでを記録だけのモードで試し、誰が記録を定期的に見直すかまで書いて、採点表の 15 行がそろう。

当サイトの 1 回ずつの実行では、課題だけを渡した設計案は従来の部品で組まれて 15 行中 7 行、§5 の項目を添えた設計案は 15 行中 10 行だった。項目を添えると製品名の行は増えたが、Auth Manager と deny ルールは両方とも書かず、PAB の働きを広く言い切る記述も出た。抜けた 2 つのうち Auth Manager は、モデルの知識の締切より後に GA になった機能だった。deny ルールのほうは、IAM の deny ポリシーが 2022 年から GA なので、締切では説明できない。

AI に設計案を出させる練習は、採点表と公式のページがあって初めて役に立つ。採点表の 15 行で自分の案と AI の案を同じように採点し、0 になった行の原文を読む。この繰り返しが、§5 の設計判断を問われたときの準備になる。

参照

• Google Cloud「Professional Agentic Architect Certification exam guide」（英語、PDF）
• Google Cloud「Agent Identity overview」
• Google Cloud「Principal access boundary policies」
• Google Cloud「REST Resource: organizations.locations.principalAccessBoundaryPolicies」（IAM API v3）
• Google Cloud「About Agent Identity for GKE」
• Google Cloud「Configure Agent Platform features for Cloud Run」
• Google Cloud「Agent Identity auth manager overview」
• Google Cloud「Use IAM securely」
• Google Cloud「IAM release notes」
• Google Cloud「Agent Gateway overview」
• Google Cloud「Monitor traffic through Agent Gateway」
• Google Cloud「IAM policies overview」（Agent Gateway）
• Google Cloud「IAM Access policies overview」（Unified Access Policies）
• Google Cloud「Semantic governance policies overview」
• Google Cloud「Gemini Enterprise Agent Platform release notes」
• Google Cloud「Agent Registry overview」
• Google Cloud「Agent Registry release notes」
• Google Cloud「Model Armor overview」
• Google Cloud「Configure floor settings」（Model Armor）
• Google Cloud「Integrate Model Armor with Agent Gateway」
• Google Cloud「Sensitive Data Protection overview」
• Google Cloud Architecture Center「Choose a design pattern for your agentic AI system」
• Google Cloud Architecture Center「Agentic AI use case: Orchestrate security operations workflows」
• ADK「Get action confirmation for ADK Tools」
• ADK「Safety and Security for AI Agents」
• Gemini Enterprise「Workflow Builder overview」
• Gemini Enterprise「Use human-in-the-loop steps」（Workflow Builder）
• Gemini Enterprise release notes
• Gemini Enterprise「Compare editions of Gemini Enterprise」
• Gemini Enterprise「Get subscriptions and assign licenses for Gemini Enterprise」
• Gemini Enterprise「Quotas and overages」
• Google Cloud「Gemini Enterprise」製品ページ
• Google Cloud「CX Agent Studio」
• CX Agent Studio「Guardrails」
• CX Agent Studio「Flow-based agents」
• CX Agent Studio release notes
• Dialogflow CX「Pages」
• Dialogflow CX「State handlers」
• Google Cloud「Agent Search」製品ページ
• Google Cloud「Overview of Agent Search」
• Anthropic「Models overview」（Claude のモデル一覧）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.