🧭 エージェント導入を「作る前」に潰す20の問い — Google Cloudの設計レビュー枠組み

対象: Google Cloud が 2026-07-08 に公開したブログ「20 questions for the agentic enterprise」。
エージェント導入プロジェクトを「作る前」に問うべき 20 の設計判断を、Build / Scale / Optimize / Govern の 4 フェーズに整理した設計フレームワークです。
本記事は方法論（フレームワーク）を対象とするため、C4 図は「枠組みが前提とするエージェント基盤の論理構造」に読み替えています。原典本文には逐語の設定断片が少なく、各問い末尾の Example リンク先で実装例が補われます。本記事のコードブロックはすべて補助的な「実装案 / 例」です。
なお原典タイトルは "20 questions" ですが、本文の問いは #0（Who is building the application?）から始まり #20 まで 21 ラベルで構成されます。本記事では原典の番号付けに従い Q0-Q20 と表記します。

AI エージェントの導入は、この 1-2 年で「どのモデルが強いか」から「認可境界・監査・ガバナンスをどう設計するか」へ論点が移りました。Google Cloud の「20 questions for the agentic enterprise」は、その主戦場を 20 の問いに分解した設計レビュー枠組みです。本記事では、この枠組みを構造・データ・実装・運用の観点で解剖します。

概要

「20 questions for the agentic enterprise」は、Google Cloud が 2026-07-08 に公開した設計フレームワークです。

• エージェント導入プロジェクトを「作る前」に問うべき 20 の設計判断を提示します。
• 20 問は Build / Scale / Optimize / Govern の 4 フェーズに整理されています。
• 執筆者は Gemini Enterprise Agent Platform の Product Manager（Kanchana Patlolla 氏 / Greg Brosman 氏）です。

このフレームワークの性格は、特定製品の実装手順書ではありません。プロジェクト開始前に組織が自問すべき論点集です。各問いに Google 製品の対応例が添えられているため、チェックリストと製品カタログを兼ねた構成になっています。

なぜ 2026 年に重要か

エージェント導入の論点は、この 1-2 年で移動しました。

Google Cloud 自身も記事冒頭で、速く動く圧力とエンジニアリング上の複雑さの落差を課題として述べています。具体的には、次の 3 点が量産フェーズで顕在化します。

• 断片化したツール群の統合（disconnected tools）
• 機密データ漏洩とトークン予算超過というコスト・セキュリティ懸念
• 組織全体でスケールする際の基盤の複雑さ

2026 年時点のエージェント導入は、PoC の延長線上ではなく、本番運用を前提にした認可・監査・統制の設計が主戦場になっています。この枠組みは、その主戦場を 20 問という扱いやすい単位に分解した点に価値があります。

誰向けか

原典が名宛人として明記するのは "IT leaders" です。本記事では、Q0 のペルソナ記述も踏まえ、実際の想定読者をエンタープライズのアーキテクト・IT 意思決定者・実装エンジニアの三者として整理します。経営層向けの啓蒙資料ではなく、実装に踏み込む前の設計レビュー資料として使う想定です。Q0 は開発に関わる 3 層のペルソナを想定しています。

4 フェーズと 20 問の全体像

20 問は、開発の進行順に沿った 4 フェーズに配置されています。

20 問の一覧は次のとおりです。

特徴

• 問いから始める設計: 実装手順ではなく、意思決定すべき論点を疑問文で提示します。答えは組織ごとに異なる前提です。
• フェーズ順の成熟度モデル: 4 フェーズは開発の進行順とも対応し、成熟度モデルとして読めます。前段の判断を飛ばすと後段でつまずく設計です。
• Google 製品エコシステム前提: 各問いの解決策として Agent Studio・ADK・Antigravity・Agent Gateway・Model Armor など Gemini Enterprise Agent Platform 系の製品が対応づけられています。
• ガバナンスを設計段階に組み込む思想: Govern フェーズは Q14-Q20 の 7 問と最大で、権限・監査・脅威検知を後付けでなく初期設計の一部として扱います。
• 開発〜統制の一気通貫: 開発ツール選定から脅威検知・ライフサイクル管理まで、単一のフレームワークでカバーします。
• 相互運用プロトコルへの言及: A2A protocol・MCP という業界標準プロトコルを Google 製品と併記し、自社エコシステム内で閉じない設計を志向します。

類似の設計枠組みとの比較

3 者は補完関係にあります。

• Google「20 questions」は、エージェント導入の設計論点を網羅する縦串の枠組みです。
• OWASP Top 10 for LLM Applications は、Prompt Injection や Excessive Agency など脅威そのものを列挙するリストです。
• NIST AI RMF 1.0 は、組織のリスク管理プロセスを規定する枠組みです。

たとえば Govern フェーズの Q18（プロンプト保護）は OWASP の LLM01（Prompt Injection）と対応し、Q14-Q17（権限・ポリシー）は NIST AI RMF の GOVERN 機能と重なります。Google の枠組みは、これら業界標準の論点を Google 製品で実装する際の対応表としても機能します。なお A2A protocol と MCP は governance framework ではなく相互運用プロトコルのため、比較表には含めていません。

構造

「20 questions」はフレームワークであり、特定製品の設計図ではありません。ただし各問いの背後には、一貫したエンタープライズ・エージェント基盤の論理構造が透けて見えます。この節では、その論理構造を C4 model の 3 階層で図解します。具体企業名は使わず、役割・カテゴリ名で表現します。

システムコンテキスト図

最上位の視点です。「エージェント基盤」を単一のシステムとして捉え、周囲のアクターと外部システムとの関係を示します。

利用者アクター

エージェント基盤 / 外部システム

コンテナ図

エージェント基盤の内部を、4 フェーズに対応する 4 つの層としてドリルダウンします。開発層で作られたエージェントが接続層を介してデータ/他エージェントと繋がり、実行層で稼働し、統制層をすべての通信の関所として通過する構造です。

開発層 / 接続層

実行層 / 統制層

コンポーネント図

統制層（Govern）をさらに分解します。Agent Gateway を中心に、Identity・二層 Policy・Registry・Model Armor・Anomaly Detection・監査証跡がどう連携するかを示します。

Policy 二層

統制層コンポーネント

エージェント通信境界のネットワーク構成図

Agent Gateway による統制は、ポリシーへの準拠を期待する運用ルールではありません。すべての入口/出口を物理的な proxy に集約し、それ以外の経路を遮断する設計です。CNCF の記事が示す「境界をアプリの遵守に期待するポリシーではなく、アーキテクチャの性質にする」という考え方（原文の paraphrase）と一致します。

通信境界の構成要素

egress_proxy を経由しない通信は iptables ルールで強制的に遮断する構成です。境界の遵守はアプリケーションの実装判断に依存せず、ネットワーク構成自体の性質になります。

データ

「20 questions」が扱う主要エンティティを、概念モデルと情報モデルにモデル化します。配置・通信などの構造や設定ファイルの書き方は対象外です。「20 問の設計レビュー票」自体も DesignReviewQuestion としてエンティティ化し、稟議・ADR に埋め込んで他エンティティをレビュー対象として参照する構造にしています。

概念モデル

DesignReviewQuestion は他の主要エンティティを横断的に参照します。20 問がフェーズを横断して全エンティティに触れる、という枠組みの構造を表しています。

情報モデル

属性の出典は 3 区分です。枠組みが明記するもの（AgentIdentity.identity_model の direct/independent/delegated、Memory.memory_type の short/long、Policy.policy_type の iam/semantic、AgentRegistryEntry の business_owner/target_dataset/permitted_tools、EvaluationResult.method 等）、公式ドキュメントで補完したもの、一般的な IAM / 監査ログ設計から推測補完したものに分かれます。推測補完した属性（storage_backend、retention_policy、compliance_tag、DesignReviewQuestion.decision/owner/status 等）は枠組みに明示の記載がありません。

構築方法

この枠組みを組織に導入する初期セットアップです。原典本文には逐語の設定断片が少ないため、以下はすべて補助的な「実装案 / 例」です。

20問を「設計レビュー票」として稟議/ADR に埋め込む

20問はそのままでは読み物です。意思決定プロセスに強制力を持たせるには、稟議/ADR のテンプレートに必須記入欄として埋め込みます。

1. 新規エージェント案件の ADR テンプレートに「20問チェック表」セクションを追加する。
2. 案件のフェーズ（Build/Scale/Optimize/Govern）に該当する問いだけを必須項目にする。全20問を初回から強制すると形骸化しやすいためです。
3. 各問いに「未着手 / 検討中 / 対応済 / 対象外（理由記載）」の4値ステータスを持たせる。
4. 承認者は「対応済」の根拠（リンク・設定値）を確認してから承認する。「対象外」は理由なしで通さない。
5. 本番リリース前ゲートとして、Govern フェーズ（Q14-Q20）の必須項目を「未着手」のまま通さない。

レビュー票は人間が読む版（Markdown）と、CI/棚卸しで機械集計する版（YAML）の2種類を用意すると運用しやすいです。

## 20-Questions 設計レビュー (ADR-XXXX 添付)

対象システム: <エージェント名>
レビュー日: <YYYY-MM-DD>
レビュアー: <氏名>

| # | フェーズ | 問い (要約) | ステータス | 採用パターン / 根拠 | 残課題 |
|---|---|---|---|---|---|
| Q0 | Build | 誰が作るか (no/low/high-code) | 対応済 | high-code, ADK 採用 | - |
| Q4 | Build | 単一 vs マルチエージェント | 検討中 | coordinator + 2 sub-agents (仮) | 責務分割レビュー待ち |
| Q10 | Optimize | blast radius 制限 | 未着手 | - | Sandbox 未選定 |
| Q14 | Govern | データアクセスをユーザーと揃えるか | 未着手 | - | Agent Identity 未設計 |
| Q17 | Govern | policy 実施と可視化 | 未着手 | - | Gateway 未配置 |

判定: [ ] 本番リリース可 (Govern 必須項目がすべて 対応済/対象外)

# agent-design-review.yaml — 実装案。20問チェックの機械可読版
adr_id: ADR-0123
agent_name: support-triage-agent
review_date: "2026-07-09"
questions:
  - id: Q0
    phase: build
    summary: "誰が作るか (no/low/high-code)"
    status: done          # not_started | in_review | done | not_applicable
    decision: "high-code, ADK 採用"
    evidence: "docs/adr/0123-agent-dev-tool.md"
  - id: Q14
    phase: govern
    summary: "データアクセスをユーザーと揃えるか"
    status: not_started
    decision: null
    evidence: null
required_before_prod: [Q14, Q15, Q16, Q17, Q18, Q19, Q20]

20問自体は一次情報（Google Cloud Blog）に基づきます。YAML/Markdown の構造は本記事の実装案であり、Google の公式テンプレートではありません。

4フェーズを成熟度ステップとして整備する導入順序

4フェーズは「1つのプロジェクトの時系列」であると同時に、「組織としてのエージェント基盤の成熟度ステップ」として読み替えられます。1個目のエージェントで Build だけ整えて終わりにせず、2個目・3個目が出てくる前に Scale/Optimize/Govern の土台を組織として先回りで整備するのが狙いです。

成熟度ゲート（次フェーズに進む前に満たしたい状態、実装案）は次のとおりです。

前提条件

Govern フェーズの各問い（Q14-Q19）は、事前に以下が無いと個別対応の寄せ集めになりがちです。

実務上は「IAM 設計 → 監査基盤 → Gateway 一本化」の順に着手すると、Gateway が最後に既存の IAM/監査と統合される形になり手戻りが少ないです。順序づけ自体は本記事の実装案です。

利用方法

各問いへの実装/構成の具体例です。以下はすべて「実装案 / 例」です。コマンド・フラグ・フィールド名は公式ドキュメントに沿わせていますが、この製品群は 2026-07 に公開されたばかりで仕様が流動的です。実施時は必ず最新の公式ドキュメントでコマンド名・フラグ・リソース名を確認してください。プロジェクト ID・エージェント名などは架空の値です。

Q10: Agent Sandbox — 隔離実行

「スクリプト実行やブラウザ操作をするエージェントの blast radius をどう制限するか」への実装案です。原典 Q10 の Example は Agent Platform 側の Code Execution / Sandbox ですが、ここでは自己管理 Kubernetes での概念例として GKE Agent Sandbox を示します。runtimeClassName: gvisor によるユーザー空間カーネル分離で、LLM が生成した未信頼コードを隔離実行する考え方です。

# 概念例: GKE Agent Sandbox で未信頼コード実行を隔離する SandboxTemplate
# 実際の apiVersion/CRD 名は GKE Agent Sandbox の最新ドキュメントで確認すること
kind: SandboxTemplate
metadata:
  name: python-runtime-template
spec:
  podTemplate:
    spec:
      runtimeClassName: gvisor            # gVisor によるカーネルレベル分離
      automountServiceAccountToken: false # 未信頼コードに SA トークンを渡さない
      securityContext:
        runAsNonRoot: true
      containers:
        - name: python-runtime
          securityContext:
            capabilities:
              drop: ["ALL"]               # 権限昇格の防止

• Kubernetes を持たない構成であれば、Vertex AI Agent Engine の Code Execution（API 呼び出しで Python/JavaScript を隔離実行）も選択肢です。
• ポイントは「未信頼コードにサービスアカウントトークンや権限を持たせない」「カーネル分離で blast radius を閉じる」の 2 点で、これは特定製品に依存しない設計原則です。

Q12: Evaluation — LLM-as-a-Judge

「結果をどう信頼するか」への実装案です。評価フレームワークは、決定論的なメトリクス（ツール軌跡の一致など）と、LLM を判定者に使うメトリクス（最終応答の意味的一致・ルーブリック評価など）を組み合わせる考え方です。

// 概念例: 評価設定 — 決定論的判定 + LLM-as-a-Judge + ルーブリック
{
  "criteria": {
    "tool_trajectory_avg_score": { "threshold": 1.0 },
    "final_response_match": {
      "threshold": 0.8,
      "judge_model": "gemini-flash-latest",
      "num_samples": 5
    },
    "rubric_based_quality": {
      "threshold": 0.8,
      "rubrics": [
        { "id": "on_brand_tone", "text": "回答がブランドのトーンを守っている" },
        { "id": "no_fabrication", "text": "一次情報で確認できない事実を含まない" }
      ]
    }
  }
}

CI に組み込む場合の流れです。

「自己評価エージェントが end-user 到達前に output を audit する」という原典の記述は、この judge モデルによるオフライン評価と、本番トラフィックへの human-in-the-loop 併用の両方に対応します。

Q14: Agent Identity — 委譲権限/IAM

「エージェントのデータアクセスを人間ユーザーに揃えるか」への実装案です。Agent Identity は共有サービスアカウントの代替として、エージェントごとに一意な ID を発行し、IAM に直接バインドする考え方です。

• 共有サービスアカウントを避け、エージェント単位の一意な principal を IAM member として扱います。
• 人間ユーザーと同じ権限を丸ごと渡すのではなく、エージェントが実際に使うツール分だけ個別付与するのが Q14 の趣旨です（最小権限）。
• 「ユーザーの代わりに操作する」委譲権限パターンは、エンドユーザー同意を伴う OAuth（3-legged）で実現し、エージェントに生の認証情報を持たせず Gateway 側で扱う設計が推奨されます（Q17 と接続）。

# 概念例: エージェントの principal に最小権限ロールを付与する IAM バインド
# principal 表記・付与するロール名は最新の公式ドキュメントで確認すること
gcloud <resource-type> add-iam-policy-binding <resource-id> \
  --member="<agent-principal>" \
  --role="<least-privilege-role>"

Q16: Policy — 二層（IAM + semantic）

「ユーザー・エージェント・データ・ツールの相互作用をどう定義するか」への実装案です。二層構造で捉えます。

IAM は「到達可否」、semantic policy は「到達できた上での振る舞い」を制御するため、片方だけでは Q16 の要求を満たしません。IAM で許可されたツールでも、semantic policy が個別のツール呼び出しをブロックできます。自然言語制約の例は「米国内の発送には常に UPS を使う」「一定額を超える返金は必ず human-in-the-loop の承認を経由する」といった、業務ルールをそのまま宣言する形です。

Q17: Agent Gateway — 入口一本化と egress 遮断

「policy をどう実施し、エージェント活動をどう可視化するか」への実装案です。Agent Gateway はエージェントに関わる全通信の入口（ingress: クライアント→エージェント）と出口（egress: エージェント→外部リソース）を一本化するネットワーク層です。

構成の考え方（概念例。実施時は公式ドキュメントで最新の設定 UI/リソース名を確認）は次のとおりです。

1. エージェントと MCP サーバーを Agent Registry に登録する（Q15 の棚卸しと接続）。
2. Ingress 側で「どのクライアントがどのエージェントに到達できるか」を IAM policy で強制する。
3. Egress 側で、エージェントの identity ごとに「到達してよい外部リソース/ツール」を定義し、未登録の外部エンドポイントへの到達はデフォルトでブロックする。
4. Semantic Policy（Q16）と Model Armor（Q18）をこの一本化された入口にアタッチし、「到達可否」だけでなく「内容の安全性」もここでチェックする。個別エージェントごとに実装すると抜け漏れが出ます。
5. Gateway が生成する network-layer telemetry を Agent Observability 基盤（Cloud Logging / Cloud Trace 等）に送る。脅威検知の findings は Security Command Center 側で扱う。

これにより Q14（委譲権限）と Q17（入口一本化）が同じ機構でつながり、prompt injection / 機微データ検知（Q18）が初めて全トラフィックに一様適用されます。

運用

Govern フェーズ（Q14-Q20）を中心に、稼働後の統制運用を扱います。この 7 問が扱う領域は次のとおりです。

Shadow AI / agent sprawl の継続監視（Q15）

Agent Registry は、ビジネスオーナー・対象データセット・許可ツールを自動でインベントリ化します。稼働後は次を定期実施します。

policy enforcement の可視化（Q17）

Agent Gateway が生成する network-layer telemetry は、行動メトリクスと実行トレースをダッシュボードへ供給します。稼働後の運用ポイントは、この telemetry を「誰が」「いつ」見るかを決めることです。telemetry を出すだけでは監視になりません。二層ポリシーとの関係は次のとおりです。

Threat Detection / Anomaly Detection による behavioral audit（Q19）

Security Command Center の Agent Platform Threat Detection は、稼働後の挙動を監視する組み込みサービスです。検知は 2 系統に分かれます。

これに加えて Anomaly Detection が、サービスアカウントの外部由来 behavior signal（認証情報漏洩の兆候など）を検知します。findings を単一ビューで定期確認し、重大度に応じて隔離・失効・エスカレーションを判断する運用ループを組むことが要点です。

コスト監視（Q13）

コスト暴走対策は、モデル選定とインフラ契約の 2 軸で構成されます。

• Provisioned Throughput（PT）は予約枠で固定コスト・固定期間を確保する契約です。定常的に高スループットを要する本番ワークロードに向きます。
• context caching、precision RAG、agent iteration の hard stop、決定論的コードへの置き換えは、いずれも「同じ結果をより少ないトークン・呼び出し回数で得る」ための施策です。

稼働後に監視すべき KPI の設計例です。Google 記事は KPI の具体値までは明示していないため、実務での監視観点として整理します。

起動・停止・状態確認・監査ログ確認

一次情報は個別 CLI コマンドの逐語仕様までは踏み込んでいません。フレームワークが示す構成要素から、次の対応関係で運用手順を設計します。

ベストプラクティス

誤解しやすい点を先に反証してから、推奨を示します。

誤解 1: ガバナンスは後付けでよい

• 誤解: セキュリティ・監査の仕組みは、エージェントが動いてから足せばよい。
• 反証: この枠組みは Govern を Q14-Q20 として最終フェーズに置いていますが、これは「後回しにしてよい」という意味ではありません。Agent Identity（Q14）や Agent Registry（Q15）は、エージェントを 1 つでも本番投入した瞬間から必要になります。後付けで導入すると、既存エージェントの棚卸し・権限再設計という追加コストが発生します。
• 推奨: Build 段階（Q0-Q4）で、最初の 1 エージェントから Identity・Registry 登録を必須プロセスに組み込みます。フェーズは実装の進行順であり、着手順ではありません。

誤解 2: 監査証跡はアプリケーションログで十分

• 誤解: エージェントのログ出力（アプリ内ログ）を集めれば、監査証跡として十分である。
• 反証: アプリ内ログは、エージェント自身の実装が正しくログを出す前提に依存します。CNCF の記事は、この前提が崩れた場合の対策として「通信境界（network boundary）から監査情報を取る」設計を提示しています。iptables で全 egress を forward proxy 経由に強制することで、アプリケーションの遵守に依存しない構造的な境界（boundary-as-architecture）を作ります。ただし network boundary は intent（意図）までは見えず、アプリ層の監査を代替するのではなく、アプリ層が信頼できない場合の下限を保証する層です。
• 推奨: 監査証跡は「アプリ内ログ」と「通信境界の telemetry」を両方取り、後者を一次情報源・前者を意図理解の補助情報として位置づけます。Google の Agent Gateway（Q17）が生成する telemetry も、同じ boundary-as-architecture の思想です。

誤解 3: 評価器（LLM-as-a-Judge）の判定はそのまま信頼してよい

• 誤解: 自動評価で pass すれば、品質は保証されている。
• 反証: LLM-as-a-Judge には自己評価バイアス（self-preference bias）、冗長性バイアス（verbosity bias）、位置バイアス（position bias）が知られています。ベンチマーク横断で一様に信頼できる judge は存在せず、評価器そのものの信頼性を検証する必要があります。
• 推奨: 評価器自体を監査対象に含めます。生成モデルと評価モデルを分離する、人間レビューを一定割合でサンプリングする、複数 judge の合議にする、といった対策を評価パイプラインの設計に組み込みます。

誤解 4: ベンチマークのスコアが高ければ導入して問題ない

• 誤解: 公開ベンチマークで高スコアなら、そのまま自社データに適用してよい。
• 反証: ベンチマークのスコアは、評価データセットの品質に依存します。汚染（contamination）、自社ユースケースとの乖離、評価対象タスクの偏りがあれば、スコアは実運用の信頼性を保証しません。
• 推奨: ベンチマークだけでなく、評価に使うデータセット自体の出所・カバレッジ・偏りを監査します。Q12 の評価設計と合わせて、自動テスト・human-in-the-loop・自己評価エージェントの 3 層を組み合わせます。

この枠組みの適用限界

トラブルシューティング

まとめ

Google Cloud の「20 questions for the agentic enterprise」は、エージェント導入を「作る前」に問うべき論点を Build / Scale / Optimize / Govern の 4 フェーズ 20 問へ分解した設計レビュー枠組みです。製品カタログの側面はあるものの、20 問を稟議・ADR の必須記入欄に落とし込めば、権限・境界・停止条件・評価を「仕様書より先に埋める問いのカタログ」として使えます。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 一次情報（本フレームワーク）
  • 20 questions for the agentic enterprise | Google Cloud Blog
• 標準・関連枠組み
  • OWASP Top 10 for LLM Applications 2025 | OWASP Gen AI Security Project
  • NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
  • Linux Foundation Launches the Agent2Agent Protocol Project
  • Introducing the Model Context Protocol | Anthropic
• 関連プロダクト / 実装（Google Cloud）
  • Model Armor overview | Google Cloud
  • Security Command Center | Google Cloud
  • Agent Development Kit (ADK)
  • Provisioned Throughput | Vertex AI
• 実務記事 / 反証
  • Network boundary for AI agents using NGINX and OpenTelemetry | CNCF
  • Google Vertex AI Pricing: Complete Enterprise Guide (2026) | CloudZero
  • Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., arXiv:2306.05685)