本記事は 2026 年 11 月 9 日 に公開された「 How skills and agents work in AWS Quick 」を翻訳したものです。 AI エージェントを利用していて、同じ作業の進め方を何度も説明したことはないでしょうか。週次の状況報告の作り方、リリースノートの書き方、プロジェクトの管理方法、チケットの作成方法などです。こうした繰り返しの作業は、 AWS Quick のエージェントとスキルにまとめておけます。Quick は、作業の自動化、データ分析、Web アプリケーションの構築、調査を AI で行えるサービスです。自然言語で指示すると、Quick は AI エージェントを利用し、接続済みのデータソースやアプリケーションに対してリクエストを処理します。 本記事では、Quick でエージェント、スキル、データがどう組み合わさるのか、そしてチームで利用できるスキルの作り方と共有方法を説明します。あわせて、公式カタログとカスタムエージェントを利用してスキルを活用する方法も紹介します。 基本的な概念 このセクションでは、エージェント、スキル、データとの関係から Quick を理解するための基本的な概念を説明します。 図 1: Quick エージェントが指示に従い、タスクに必要なスキルを読み込み、コネクタを通じて操作を行い、データに基づいて回答する仕組み 図 1 の中心にあるのがエージェントです。エージェントは指示に従い、タスクに必要なスキルを読み込み、コネクタを通じて操作を行います。回答の根拠には、スペース、ナレッジベース、データセット、ダッシュボードといったデータを利用します。 エージェント Quick の エージェント は、独自の指示、ナレッジソース (スペース)、コネクタを持つ、設定可能な AI です。これらを利用して質問に答えたり、作業を代わりに進めたりします。エージェントとはチャットで対話できるほか、 ルーチン で自動的に実行させることもできます。エージェントがアクセスできるのは、ユーザー自身がアクセスできるリソースとサービスのみです。各エージェントに何を許可するかもユーザーが決めます。 デフォルトエージェントの「 Quick 」は、すべてのユーザーが利用できる組み込みのエージェントです。範囲が固定されていないため、会話ごとに、スペース、ナレッジベース、ダッシュボード、コネクタ、スキルなど、ユーザーがアクセスできるリソースを利用して動作します。リクエストにどのデータやツールが必要かを事前に決めなくてよいので、ほとんどの作業は Quick から開始できます。 カスタムエージェント は、自分やチームのメンバーが特定の仕事向けに設定するエージェントです。たとえば、人事 (HR) チームのスペースをもとに新入社員の質問に答える HR オンボーディングアシスタントがあります。カスタムエージェントには専用の指示を与え、ユースケースに必要なスペース、コネクタ、スキルのみを利用するよう制限します。テストして公開すると、同じ Quick アカウント内の他のユーザーやグループと共有できます。作成手順は「 Build AI-powered employee onboarding agents with AWS Quick 」を参照してください。 データ エージェントは、Quick に接続したデータに基づいて回答します。 スペース は、エージェントが情報源として利用するドキュメントと Quick リソースを選んでまとめたものです。自分用、チーム用、組織内の別のグループ用に作成できます。スペースにはファイルやフォルダをアップロードできるほか、ダッシュボード、ナレッジベース、アクションコネクタ、データセットなどのアセットも追加できます。Quick との会話を開始するときにスペースを添付すると、その会話で Quick が利用するデータを絞り込めます。エージェントにスペースを追加すると、スペースはエージェントの設定の一部になり、リクエストに必要なときにエージェントが参照します。 ナレッジベース は、データソースから集めたドキュメントやコンテンツを整理してインデックス化したもので、検索と質問への回答に最適化されています。Quick は、Google Drive、Microsoft OneDrive、Confluence、Microsoft SharePoint、Amazon Simple Storage Service (Amazon S3)、Web クローラー、 Amazon Bedrock Managed Knowledge Bases などのソースからナレッジベースを同期し、同期スケジュールに沿って最新の状態に保ちます。 データセットとダッシュボードは、Quick のビジネスインテリジェンス機能である AWS Quick Sight で作成します。Quick Sight は、AWS マネジメントコンソールからプロビジョニングしたアカウントで利用できます。 データセット は、分析やダッシュボードですぐに利用できるよう準備したデータの集まりです。 ダッシュボード は、分析を公開したもので、他の Quick ユーザーと共有できます。データセットを利用すると、データベースのテーブルなどの構造化データに意味を説明する豊富なメタデータを付けられるため、複雑な分析も自然言語で行えます。 最後に、 コネクタ は Quick を外部のアプリケーションやネイティブツールにつなぎ、エージェントがデータを読み取ったりユーザーの代わりに操作したりできるようにします。 クラウドコネクタ は、Microsoft Outlook、Slack、Jira、Asana、Salesforce などのサービスや、リモートでホストされている Model Context Protocol (MCP) サーバーに Quick を接続します。クラウドコネクタは、Quick を利用するすべてのデバイスで利用できます。 ローカルコネクタ は、自分でホストする MCP サーバーなど、自分のマシン上で動くコネクタです。そのため、ツールを利用できるのはそのマシンが起動していて接続されているときのみです。コネクタの種類の一覧は、Quick ユーザーガイドの「 Connectors 」と「 Integration-specific guides 」を参照してください。 こうした仕組みを組み合わせると、データ、ドキュメント、アプリケーションを自然言語で扱えるようになり、接続したソースに対して質問したり操作したりできます。 スキル スキル は、特定のタスクのやり方をエージェントに教える、再利用可能な指示のセットです。スキルは、Quick のエージェントの振る舞いと作業の進め方の土台でもあります。Quick のエージェントは、他のエージェントと同じく、推論と行動 (ReAct) パターンに従うハーネス (マネージドなエージェントループ) の中で動きます。Quick にプロンプトを入力すると、エージェントは利用できるツールと指示を活用して目的を達成し、回答を返します。 Strands Agents SDK などのエージェントフレームワークも、同じモデル駆動のループをもとに作られています。 Quick がデフォルトでできることの多くは、 システムスキル によるものです。たとえば、Quick に Word 文書、PowerPoint のプレゼンテーション、Excel のスプレッドシート、PDF の作成を頼むと、システムスキルが同梱のスクリプトを利用し、コードでドキュメントを作成・編集します。ほかにも、Web の閲覧、コードの実行、ディープリサーチ、音声や動画の文字起こし、画像の生成を行うシステムスキルがあります。 AWS Quick Flows の作成、ルーチンのスケジュール設定、Kiro などのコーディングエージェントへの作業の引き渡し、メモリとナレッジグラフの管理、To-Do の管理など、Quick 自体を管理するシステムスキルもあります。Quick の中でシステムスキルのオン・オフは切り替えられますが、編集、複製、エクスポート、公開、共有、削除はできません。 Quick の機能とツールを組み合わせることで、スキルでさまざまな作業を実行できます。たとえば、テンプレートから週次の状況報告を作るなど、成果物を作るスキルがあります。その週の Jira の更新を集めて要約を Slack に投稿するなど、複数のコネクタをまたいでワークフローを自動化するスキルもあります。Python スクリプトで計算し、結果を JavaScript でグラフにするスキルも作れます。 スキルとは Quick のスキルは、Anthropic が開発してオープンスタンダードとして公開した Agent Skills 仕様に準拠しています。 2026 年 4 月にプレビュー として登場し、 2026 年 9 月に一般提供 が始まったデスクトップ版 Quick も、この仕様を採用しています。 スキルは、ルートに Markdown ファイル SKILL.md を置いたフォルダです。指示の中で利用するスクリプトや参考ファイルも、必要に応じて入れられます。ファイルのフロントマター (2 本の --- 行で囲まれた属性) には、名前、説明、その他スキルに関係するメタデータを書きます。以下は、 release-notes-generator というスキルを短くした例です。 --- name: release-notes-generator description: "Generates human-readable release notes from merged pull requests, commits, or changelogs ... Use when asked to 'generate release notes', 'write changelog', ..." --- スキルが呼び出されるかどうかは、説明と名前で大きく決まります。Quick はスキルをエージェントのプロンプトに読み込むときに 段階的開示 (progressive disclosure) を利用します。エージェントは、リクエストがそのスキルを必要とするまで、各スキルの名前と説明のみを読みます。必要になった時点で、スキルの指示全体を読み込みます (詳しくは「 How agents load skills 」を参照)。そのため、「バージョン 2.3 のリリースノートを作って」のような特定のフレーズを入力すると、スキルが呼び出されやすくなります。仕様では name を 64 文字、 description を 1,024 文字までに制限しており、スキル内の指示は 5,000 トークン未満を推奨しています。 図 2: release-notes-generator スキルのフォルダ。必須の SKILL.md ファイルと、任意の scripts フォルダ、references フォルダがある Quick でスキルを作成して共有する スキルは、チャット、ファイル (.md または .zip)、ルートに SKILL.md ファイルがあるフォルダのいずれかから作成できます。本記事ではチャットから作る方法を扱います。まず、チャットで Quick にタスクを説明します。たとえば、次のテンプレートから開始できます (<> で囲んだ部分を自分の要件に置き換えてください)。 Every <specify your cadence e.g. every day, on monday, or none at all>, I have to grab data from the following sources: - <List your sources and how you want to query them> ... And do <describe how you want to transform the data and the exact sequence of steps>. Once I am finished, I have to create a report <describe your report format or provide an example> and send to the following stakeholders <describe your recipients> using the following connector <describe your connector>. Create a skill from this requirement, and help me come up with testing scenarios to test the skill. 自分のスキル作りを開始するのに必要なのはこれだけです。以前にタスクを実行するために行った複数ターンの会話をもとに、Quick にスキルを作ってもらうこともできます。最終的な結果に納得したら、スキルを公開して共有します。 Customize を選択し、 Skills を選択します。 下書きのスキルを見つけて、詳細パネルを開きます。 Publish を選択します。 Share を選択し、共有する相手のユーザーまたはグループを選択します。 公開と共有は別の手順です。公開しただけでは、誰もスキルにアクセスできません。共有された人は、 Shared with me の Add to Quick からスキルを追加します。追加したスキルは、作成者が再公開するたびに同期されます。最新の手順は、Quick ユーザーガイドの「 Draft and published versions 」と「 Sharing your skills 」を参照してください。 ベストプラクティスでスキルを改善する 簡単な説明や会話から作ったスキルでも、自分の環境では安定して動くかもしれません。しかし、チームで共有する本番用のスキルを作るときは、考慮すべき点がたくさんあります。スキルはコードと似ており、ソフトウェアエンジニアリングのベストプラクティスの多くは、ナレッジワーカーがスキルを作る場合にも役立ちます。 「自分のマシンでは動く」は、ソフトウェアエンジニアの間でよく聞く言葉です。作った本人の環境では動くのに、他の人がインストールしたり利用したりすると動作しないソフトウェアを指します。スキルを作るときは、環境を考慮する必要があります。スキルの指示では、エージェントを利用してデータソースを照会したり、コネクタやツールを呼び出したりできるからです。ソフトウェアエンジニアは通常、ソフトウェアを利用するための前提条件を文書化して、環境の違いによる問題を回避します。たとえば、スキルのみを単体で共有する場合は、こうした要件を記した README をスキルに添えるとよいでしょう。スキルを利用するエージェントを共有する場合は、エージェントが接続するソースもあわせて共有してください。共有しないと、共有された人は自分がすでにアクセスできるソースからしか回答を得られません。 失敗に備えます。エージェントは、サードパーティやファーストパーティのサービスに依存する接続済みのソースを利用します。エンジニアはコードを書くとき、ソフトウェアの一部が失敗したらどうするかを理解しておく必要があります。こうした状況をスキルの指示に盛り込んでおけば、エージェントは具体的な指示に沿って対応できます。エージェントは目的に向かって動き、ステップが失敗した場合は再試行したり別の方法を試したりできるので、スキルの作成者に、連携先のサービスに関する詳細な知識は求められません。ただし、失敗がタスクや業務プロセスに影響する場合にどうするかは書いておく必要があります。次のスニペットは、失敗すると影響が出かねないスキル内のワークフローの一部です。 [Agent] Send the report to {{recipient}} over email. メールの送信に失敗したら、エージェントはどうすべきでしょうか。その場合の対応を指示に加えるとよいでしょう。 [Agent] Send the report to {{recipient}} over email. Validate: The report appears in your Sent folder. If fails: Stop, and tell the user that the report wasn't sent and why, so they can send it themselves. 人の確認なしにスケジュールでエージェントを実行する場合は、失敗時の対応がさらに重要になります。 変更のたびにテストします。ソフトウェアエンジニアは、単体テストや結合テストなど、さまざまな種類のテストを書いてソフトウェアを検証し、変更のたびに実行します。スキルでも同じように、さまざまな状況のテストケースを自分で作り、変更に合わせて新しいテストを追加していくことが重要です。方法はいくつかありますが、スキルを利用する人が実際に利用する環境でテストするのが最善です。 本番用のスキルを作るときに考慮すべき点は、ほかにもたくさんあります。 変更ごとにリリースノートを付ける。 /Users/me/notes や #my-team のように変わる可能性がある値は手順にハードコードせず、各自が指定する入力として宣言する。 スキルを変更した日付を、人が読める形で記録する。 各参考ファイルの出典を記録し、元の情報が変わったらスキルの指示も更新できるようにする。 チェックサム (スキルのファイルの指紋) を保存し、確認済みのバージョンとコピーの違いが分かるようにする。 リンターがレビュー前にコードの誤りを見つけるように、変更のたびに構造をチェックする。 スキルを一貫した方法で作り、チームが変更を提案しやすく、レビューしやすくする。 ここまでの点をすべて考慮するのは、どのユーザーにとっても大変です。そこで Quick 公式カタログ では、こうしたベストプラクティスを踏まえて作ったスキルなどのリソースを用意しています。 AWS Quick 公式カタログ 公式カタログは、エージェント用リソースを集めたものです。そのままインストールして利用することも、出発点にして自分の仕事に合わせて変えることもできます。カタログによると、掲載されているリソースはすべて、公開前に品質、セキュリティなどの観点でテストとスキャンを受けています。スキルは、日常の生産性向上のほか、営業、マーケティング、人事、法務、プロジェクト管理、カスタマーサクセス、ソフトウェアエンジニアリングなどのチームの仕事に対応しています。金融、ヘルスケア・ライフサイエンス、エネルギー・公益事業、ホスピタリティ、サプライチェーン・物流などの業界向けのスキルもあります。 カタログには、こうしたエンジニアリングのベストプラクティスを代わりに適用してくれる、構築済みの Skill Architect スキルがあります。詳しくは「 Build skills with software engineering practices in AWS Quick 」を参照してください。インストールするには、 Customize 、 Skills 、 Browse all 、 Official の順に選択します。検索ボックスに skill architect と入力し、 Install を選択します。最新の手順は「 Install skills in AWS Quick on desktop 」を参照してください。 スキルをエージェントにつなぐ エージェントを作成するときは、名前、説明、指示を設定し、参照するスペース、利用できるコネクタ、読み込めるスキルを選択します。詳しくは、Quick ユーザーガイドの「 Agent configuration 」を参照してください。エージェントは、新入社員の質問に答える、週次の状況報告を準備するといった特定のユースケースに絞り、そのユースケースに必要なスペース、スキル、コネクタのみに 範囲を限定 したときに最もよく機能します。デフォルトでは、エージェントはユーザーのすべてのスキルを利用できます。特定のスキルを追加すると、エージェントはそのスキルのみを利用するようになります。デフォルトのままだと、エージェントを共有したときに問題になります。エージェントは利用する人の権限で動作するからです。同じリクエストでも人によって利用できるデータやスキルが異なり、自分しかアクセスできないソースが必要な場合は不完全な回答になることがあります。 エージェント、スキル、スペースを組み合わせて利用してみたい場合は、ワークショップの personal agent architect モジュール をお試しください。 まとめ 本記事では、Quick でエージェントがスキルとデータをどう利用するのか、そしてチームで利用できるスキルの作り方と共有方法を紹介しました。あわせて、公式カタログとカスタムエージェントを利用してスキルを活用する方法も取り上げました。 Quick についてさらに学んだり、イベントを探したり、成功事例を共有したりするには、 AWS Quick Community をご覧ください。Quick Community には、学習教材、機能の発表、イベント、他のユーザーの事例があります。Q&A フォーラムで質問することもできます。 本記事のトピックを扱った録画セッションは、「 Encode Your Enterprise with Agents & Skills on AWS Quick 」でご覧いただけます。セッションでは、スキルの構造と読み込み方、エージェント・スペース・コネクタとスキルの連携、共有するスキルを作るときのベストプラクティスを扱います。最後に、公式カタログと Skill Architect スキルのデモがあります。 Quick に日々携わるスペシャリストが作成した、その他のリソースも紹介します。 A Complete Guide to AWS Quick: The Agentic AI Business Workspace AWS Quick: End-to-End Business Use Cases with Rich Integrations AWS Quick Administration Workshop Deep dive into AWS Quick Sight AWS Quick Knowledge Hub – Official Code Samples and Solutions Quick に関する AWS ブログ記事 著者について Jed Lechner Jed は、AWS のシニアスペシャリストソリューションアーキテクトで、エージェント型 AI ソリューションを専門としています。現職の前は、AWS や他の企業でソフトウェアエンジニアとして、エネルギーとサステナビリティの分野に取り組んでいました。 翻訳は Solutions Architect の 守田 凜々佳 が担当しました。

はじめにこんにちは。LINEヤフーAdsのデータ分析プラットフォームの開発を担当しているイ・ジョンウ、イ・ウンヨルです。広告売上は、商品、広告主、キャンペーン配信の変化によって日々変動します。広告KP...

G-gen の武井です。当記事では、Google Cloud の WAF サービスである Cloud Armor のベストプラクティスを整理します。 はじめに 前提知識 WAF の基本用語 事前構成 WAF ルール SQL インジェクション クロスサイトスクリプティング Cloud Armor の基本 Cloud Armor の仕組み セキュリティポリシーの種類 ルールの種類 Cloud NGFW との役割分担 ベストプラクティスの全体像 セキュリティポリシーとルールの作成 ルールの評価順を設計する プレビューモードで検証する Adaptive Protection を有効にする レート制限を設定する 優先度の間隔とルールの説明 JSON の解析と Bot 管理 ルールのチューニング 感度レベルを選ぶ 詳細ログを使う stable と canary を使い分ける ロギングとモニタリング ログを有効にする Security Command Center と Cloud Monitoring 全般的な管理 IAM でアクセスを制御する ポリシーの利活用 GKE での構成 導入の進め方 確認ポイント ロードマップ ティアと料金 はじめに Cloud Armor は、Google Cloud が提供する Web Application Firewall（以下、WAF）と DDoS 対策のサービスです。ロードバランサが受けたリクエストを検査し、Web アプリケーションへの攻撃や DDoS 攻撃を防ぎます。 2026年10月現在、公式ドキュメントでは20項目のベストプラクティスが公開されています。当記事では、これらを Cloud Armor の導入から運用までの流れに沿って整理し、項目ごとに設定の考え方を解説します。あわせて、前提となる WAF の用語、Cloud Next Generation Firewall（以下、Cloud NGFW）との役割分担、導入の進め方、料金の目安も説明します。 Cloud Armor については、以下の記事も参照してください。 blog.g-gen.co.jp 前提知識 WAF の基本用語 WAF は、Web アプリケーションへのリクエストの中身を検査し、攻撃と判断したリクエストを遮断する仕組みです。一般的なファイアウォールが IP アドレスやポート番号で通信を制御するのに対し、WAF はリクエストのパス、ヘッダー、ボディに含まれる文字列まで見て判断します。 Cloud Armor の WAF 機能を理解するには、以下の用語を知っておく必要があります。 用語 意味 Cloud Armor との関係 OWASP Web アプリケーションのセキュリティ向上に取り組む非営利団体（Open Worldwide Application Security Project） 以下の OWASP Top 10 や CRS を公開している OWASP Top 10 Web アプリケーションの重大なセキュリティリスクを 10 項目にまとめたもの。数年ごとに改訂され、2026年10月現在の最新版は 2025 年版 事前構成 WAF ルールは、OWASP Top 10 のリスクへの対策として提供されている OWASP CRS OWASP ModSecurity Core Rule Set の略。オープンソースの WAF 用の攻撃検知ルール集 事前構成 WAF ルールの元になっている。2026年10月現在、Cloud Armor ではバージョン 4.22 の使用が推奨されている パラノイアレベル CRS の検知の厳しさを表す段階。レベルが高いほど検知の範囲が広がり、誤検知も増える Cloud Armor の「感度」に対応する 参考 : OWASP Top 10:2025 参考 : OWASP CRS 事前構成 WAF ルール 事前構成 WAF ルールは、CRS のシグネチャ（攻撃を見分けるためのパターン）を攻撃の種類ごとにまとめたものです。CRS 4.22 では、以下の 12 種類のルールが用意されています。 ルール名 検知する攻撃 sqli-v422 SQL インジェクション （入力値に SQL 文を混ぜて、データベースを不正に操作する攻撃） xss-v422 クロスサイトスクリプティング （Web ページに悪意のあるスクリプトを埋め込み、閲覧者のブラウザで実行させる攻撃） lfi-v422 ローカルファイルインクルード （サーバー上のファイルを不正に読み込ませる攻撃） rfi-v422 リモートファイルインクルード （外部のファイルを読み込ませて実行させる攻撃） rce-v422 リモートコード実行 （サーバー上で任意のコマンドを実行させる攻撃） methodenforcement-v422 許可されていない HTTP メソッドの使用 scannerdetection-v422 脆弱性スキャナなどの自動化ツールからのアクセス protocolattack-v422 HTTP の仕様を悪用する攻撃 php-v422 PHP のアプリケーションを狙うインジェクション攻撃 sessionfixation-v422 セッション固定 （攻撃者が用意したセッション ID を使わせる攻撃） java-v422 Java のアプリケーションを狙う攻撃 generic-v422 上記に分類されない汎用的な攻撃 実際にセキュリティポリシーで指定するときは、ルール名の末尾に -stable または -canary を付けます（例 : sqli-v422-stable ）。詳しくは後述しますが、stable は動作が安定したシグネチャで構成された版で、canary は新しいシグネチャが先に反映される版です。 このほか、特定の脆弱性を狙う攻撃を検知するルールとして、以下の 2 つがあります。どちらもすべての Cloud Armor ユーザーが使用できます。 ルール名 対象の脆弱性 cve-canary Log4j と React のリモートコード実行の脆弱性 json-sqli-canary JSON 形式のリクエストで SQL インジェクションの検知をすり抜ける脆弱性 以下では、代表的な攻撃である SQL インジェクションとクロスサイトスクリプティングについて、仕組みと Cloud Armor での対策を説明します。 参考 : Preconfigured WAF rules overview SQL インジェクション SQL インジェクション （以下、SQLi）は、フォームや URL のパラメータに SQL 文の一部を混ぜて送り、アプリケーションが組み立てる SQL 文を不正に書き換える攻撃です。入力値をそのまま SQL 文に連結しているアプリケーションが狙われます。 たとえば、ログイン画面で入力された ID とパスワードを、アプリケーションが以下のように SQL 文へそのまま連結しているとします。 SELECT * FROM users WHERE id = ' （入力された ID） ' AND password = ' （入力されたパスワード） ' ; ID に yamada を入力した場合に、パスワード欄への入力で SQL 文の条件がどう変わるかを比較します。 パスワード 組み立てられる SQL 文の条件 結果 通常 pass1234 id = 'yamada' AND password = 'pass1234' パスワードが正しい場合だけログインできる 攻撃 ' OR '1'='1 id = 'yamada' AND password = '' OR '1'='1' '1'='1' は常に成り立つため、条件全体が真になる 攻撃の例では、入力値の先頭の引用符（'）でパスワードの値が閉じられ、その後ろの OR '1'='1' が条件として扱われます。 '1'='1' （1 と 1 は等しい）は常に真で、 OR はどちらかが真なら全体が真になるため、パスワードが一致したかどうかは関係なくなります。その結果、攻撃者は正しいパスワードを知らなくてもログインできてしまいます。 攻撃が成功すると、データベースの情報の窃取、データの改ざんや削除、認証の回避が起こり得ます。データベースの種類によっては、サーバーの OS コマンドを実行される場合もあります。 Cloud Armor では、事前構成 WAF ルールの sqli-v422-stable で SQLi を検知します。このルールには 60 個のシグネチャがあり、感度ごとの内訳は以下のとおりです。 感度 1 2 3 4 合計 シグネチャ数 20 31 7 2 60 感度 3 と 4 には、リクエストの引数に含まれる特殊文字の数が一定数を超えると検知するシグネチャがあります。感度 4 では特殊文字が 2 個を超えるだけで一致するため、通常の入力値でも誤検知が起きやすくなります。 参考 : SQL Injection - OWASP 参考 : SQL injection (SQLi) クロスサイトスクリプティング クロスサイトスクリプティング （以下、XSS）は、信頼されている Web サイトに悪意のあるスクリプトを埋め込み、他の利用者のブラウザで実行させる攻撃です。入力値を検証やエンコードをせずにページへ出力しているアプリケーションが狙われます。 XSS には、リクエストに含まれるスクリプトがそのままレスポンスに返される反射型、掲示板の投稿などとしてサーバーに保存される格納型、ブラウザ上の JavaScript の処理で発生する DOM ベースの 3 種類があります。 格納型を例にすると、攻撃の流れは以下のとおりです。 攻撃が成功すると、図のようなセッション Cookie の窃取によるアカウントの乗っ取りのほか、偽サイトへの誘導やページの改ざんが起こり得ます。 Cloud Armor では、事前構成 WAF ルールの xss-v422-stable で XSS を検知します。図の例では、1 の投稿がロードバランサで検査され、XSS のシグネチャに一致すれば掲示板に届く前に遮断されます。このルールには 33 個のシグネチャがあり、感度ごとの内訳は以下のとおりです。SQLi と異なり、感度 3 と 4 のシグネチャはありません。そのため、感度を 2〜4 のどれに設定しても、評価されるシグネチャは同じ 33 個です。 感度 1 2 3 4 合計 シグネチャ数 25 8 0 0 33 SQLi と XSS のどちらについても、WAF は防御の層を 1 つ増やすものであり、アプリケーション側の対策の代わりにはなりません。WAF のシグネチャをすり抜ける攻撃もあるため、アプリケーション側の対策と組み合わせて使用します。 参考 : Cross Site Scripting (XSS) - OWASP 参考 : Cross-site scripting (XSS) Cloud Armor の基本 Cloud Armor の仕組み Cloud Armor では、防御ルールの集合を セキュリティポリシー と呼びます。セキュリティポリシーは、ロードバランサのバックエンドサービスにアタッチして適用します。 セキュリティポリシー内のルールは、優先度の数値が小さいものから順に評価されます。リクエストが最初に一致したルールのアクションが実行され、以降のルールは評価されません。この仕組みは、後述する評価順の設計の前提になります。 DDoS 攻撃のうち、L3 / L4 のボリューム型攻撃やプロトコルを悪用する攻撃は、セキュリティポリシーの設定がなくても常時緩和されます。HTTP フラッドなどの L7 の DDoS 攻撃には、セキュリティポリシーのルールで対策します。 なお、Cloud Armor には、Standard と Enterprise の 2 つのティアがあります。Standard は、セキュリティポリシー、ルール、リクエストの数に応じた従量課金です。Enterprise は Standard の機能に加えて、脅威インテリジェンス、名前付き IP アドレスリスト、階層型セキュリティポリシー、高度なネットワーク DDoS 保護などを使用できます。 参考 : Security policy overview 参考 : Cloud Armor Enterprise overview セキュリティポリシーの種類 セキュリティポリシーには、適用先によって以下の3種類があります。 種類 適用先 主な機能 バックエンドセキュリティポリシー アプリケーションロードバランサ、プロキシネットワークロードバランサ 事前構成 WAF ルール、レート制限、Bot 管理など エッジセキュリティポリシー Cloud CDN を有効にしたバックエンド、Cloud Storage バケット IP アドレスや地域などによる許可・拒否 ネットワークエッジセキュリティポリシー パススルーネットワークロードバランサ、外部 IP アドレスを持つ VM など L3 / L4 の通信の許可・拒否 エッジセキュリティポリシーは、Cloud CDN のキャッシュから応答する前に評価され、バックエンドセキュリティポリシーと併用できます。 ネットワークエッジセキュリティポリシーは WAF ではなく、L3 / L4 の通信を制御するものです。使用するには、Cloud Armor Enterprise への登録と、高度なネットワーク DDoS 保護の有効化が必要です。 このほか、組織やフォルダの単位でまとめて適用できる階層型セキュリティポリシーもあり、こちらも Cloud Armor Enterprise の機能となります。 参考 : Types of security policies ルールの種類 セキュリティポリシーに設定できるルールには以下の 7 種類があります。以下の表のティア列で Standard もしくはアドオンとしたものは、どちらのティアでも使用できます。 種類 内容 使用例 ティア IP アドレスの許可リスト・拒否リスト 送信元の IP アドレスや CIDR で許可・拒否する ・攻撃元の IP アドレスを拒否する ・脆弱性診断の送信元を許可する Standard 送信元の地域 送信元の国・地域のコードで許可・拒否する サービス対象外の国からの通信を拒否する Standard 事前構成 WAF ルール CRS のシグネチャで SQLi や XSS などを検知する 感度 1 から有効にし、チューニングする Standard マネージドルール（Preview） Google が脅威情報をもとに更新するシグネチャで検知する 事前構成 WAF ルールに追加して使用する アドオン Bot 管理 reCAPTCHA の評価結果で Bot を判定する ログイン画面への自動化されたアクセスを判定する Standard 名前付き IP アドレスリスト CDN 事業者などが公開する IP アドレスのリストで許可・拒否する CDN 経由のアクセスだけを許可する Enterprise レート制限 一定時間内のリクエスト数で制限する ログイン API への総当たり攻撃を抑止する Standard マネージドルール は事前構成 WAF ルールとは別の機能で、2026年10月現在 Preview です。事前構成 WAF ルールが CRS をもとにしているのに対し、マネージドルールは Google の脅威情報をもとに更新され、新しい脆弱性を狙う攻撃への対策を提供します。 ルールの条件は、Common Expression Language（CEL）をもとにしたカスタムルール言語で記述します。IP アドレス、地域、ヘッダー、パスなどの条件を組み合わせて、独自のルールも作成できます。一致したリクエストに対するアクションには、許可、拒否（403、404、502 から応答コードを選択）、リダイレクト、スロットル、レートベースの禁止があります。 参考 : Managed rules overview Cloud NGFW との役割分担 WAF と似た目的を持つ仕組みに、 侵入検知（防止）システム （IDS / IPS）があります。Google Cloud では、Cloud NGFW の Enterprise ティアで IDS / IPS 機能が提供されます。 Cloud Armor と Cloud NGFW Enterprise は検査範囲が異なります。Cloud Armor はロードバランサが受けたリクエストを検査しますが、Cloud NGFW Enterprise はゾーン単位のファイアウォールエンドポイントで、VM や Google Kubernetes Engine（以下、GKE）が送受信するパケットを検査します。 観点 Cloud Armor（WAF） Cloud NGFW Enterprise ティア（IDS / IPS） 検査対象 ロードバランサが受けた HTTP(S) リクエスト VM や GKE が送受信する通信（VPC 内のサーバー間の通信も含む） 主な防御 SQLi や XSS などの L7 の攻撃、L3 / L4 と L7 の DDoS 攻撃 脆弱性を狙う攻撃、マルウェア、スパイウェア、C2（コマンドアンドコントロール）通信の検知・遮断 仕組み セキュリティポリシー Palo Alto Networks の脅威防御テクノロジー 対象外 VPC 内のサーバー間の通信、送信方向の通信 サーバーレスからの送信方向の通信 一般公開の Web サービスであれば、入口の防御は Cloud Armor で行い、VPC 内の通信はファイアウォールルールで制御する構成が一般的です。そのうえで、VPC 内の通信まで攻撃を検査する必要がある場合や、マルウェアの通信を遮断したい場合に、Cloud NGFW Enterprise を追加します。 なお、Cloud NGFW には、Enterprise ティアの他に、IP アドレスやポートでの許可・拒否を行う Essentials ティアと、FQDN や地域を条件にできる Standard ティアもあります。 参考 : Intrusion detection and prevention service overview 参考 : Cloud NGFW tiers ベストプラクティスの全体像 Cloud Armor のベストプラクティスは以下の4カテゴリ・20項目に分けて紹介されています。以降の章でこの順に各項目を説明します。 セキュリティポリシーとルールの作成 項目 内容 ルールをグループ化して並べ替える 拒否・許可・セキュリティのルールを推奨の順序で並べ、評価順を設計する スキャナのクライアント IP アドレスを特定する 脆弱性診断を行う場合に、診断元の IP アドレスの扱いを決める プレビューモードを使用する 新しいルールを適用せずにログだけ（ドライラン）で試し、影響を確認してから適用する ルールのロジックをテストする リクエストが想定どおりのルールに一致するかを確認する Adaptive Protection を有効にする 機械学習で L7 の DDoS 攻撃などの異常を検知し、アラートを受け取る レート制限のしきい値を設定する クライアントごとのリクエスト数に上限を設け、超えた分を制限する 優先度の間隔を空ける 後からルールを追加できるよう、優先度の値を 10 以上空ける ルールの説明を記載する ルールを作成した理由を説明欄に残す JSON の解析を有効にする JSON を受け付けるアプリケーションで、ボディを正しく解析させて誤検知を減らす reCAPTCHA で Bot を管理する Bot による被害がある場合に、reCAPTCHA の評価で Bot を判定する ルールのチューニング 項目 内容 事前構成 WAF ルールの感度レベルを選ぶ 感度を明示して、誤検知を抑える 詳細ログを有効にする チューニングの期間に、ルールに一致した箇所をログに記録する stable と canary のルールを使い分ける 新しいシグネチャを canary で先に検証する ロギングとモニタリング 項目 内容 ログを有効にし、サンプリングレートを選ぶ ロードバランサのログを有効にし、記録する割合を決める Security Command Center の検出結果を確認する Cloud Armor に関する検出結果を確認する Cloud Monitoring のダッシュボードを使用する ダッシュボードで保護の状況を可視化する 全般的な管理 項目 内容 IAM でアクセスを制御する セキュリティポリシーを変更・適用できるユーザーを限定する セキュリティポリシーの数を最小限にする 共通のポリシーを複数のバックエンドサービスで利活用する Terraform で管理する 上記と関連し、セキュリティポリシーを効果的に活用するため、コードで管理する GKE では Ingress や Gateway から構成する GKE を使用する場合に、Ingress や Gateway のリソースから設定する 参考 : Best practices for Cloud Armor セキュリティポリシーとルールの作成 ルールの評価順を設計する Cloud Armor のルールは、 優先度の数値が小さい順に評価され、最初に一致したルールで処理が終わります 。そのため、どのルールをどの順番で並べるかによって、防御の効果が大きく変わります。 公式ドキュメントでは、ルールを以下の 5 つのグループに分け、上から順に並べることを推奨しています。 順番 グループ 主なルールの種類 1 明示的な拒否 攻撃元として既知の IP アドレスや自律システム番号（ASN）、サービス対象外の地域からの通信を拒否する 2 信頼できる送信元の明示的な許可 脆弱性スキャナなど、信頼できるシステムからの通信を許可する 3 セキュリティルール 事前構成 WAF ルール、カスタムルール、レート制限、Bot 管理などで攻撃を検知する 4 明示的な許可 特定の IP アドレスや ASN、特定のヘッダーを持つ通信など、正規の利用者を許可する 5 デフォルトの拒否 どのルールにも一致しない通信を拒否する No.2 の「信頼できる送信元の明示的な許可」は、セキュリティルールより先に評価されます。ここで許可した通信は WAF の検査を受けないため、注意が必要です。脆弱性診断を行う場合は、診断ツールの送信元 IP アドレスを特定し、診断の期間だけこのグループで許可します。こうすると、WAF に遮断されずにアプリケーションそのものを診断できます。 No.5 のデフォルトルールは、すべてのセキュリティポリシーに自動で作成されるルールで、優先度は最も低い 2147483647 です。社内システムや取引先向けのサービスのように利用者が決まっている場合は、No.4 で許可する送信元を指定し、それ以外の通信をデフォルトルールで拒否します。一方、一般公開の Web サービスでは、許可する送信元を事前に指定できません。そのため、デフォルトルールを許可にして、No.3 のセキュリティルールで攻撃だけを遮断する構成がよく使用されます。この場合、No.4 の明示的な許可ルールは不要です。 No.1、No.2、No.4 のルールでは、IP アドレスのリストを条件に使用します。リストの管理を効率化する機能として、複数のセキュリティポリシーで IP アドレスのリストを共通管理するアドレスグループや、CDN 事業者などが公開する IP アドレスのリストを使用できる名前付き IP アドレスリストがあります。どちらも Cloud Armor Enterprise の機能です。 参考 : Group and sort rules in your security policy 参考 : Address groups overview プレビューモードで検証する プレビューモード は、ルールのアクションを実行せず、一致した結果だけをログに記録する機能です。事前構成 WAF ルールを含め、新しいルールが正常な通信にどう影響するかは、実際の通信で試すまで分かりません。そのため、新しいルールはプレビューモードで追加し、ログで正常な通信が一致していないことを確認してから、強制適用に切り替えます。 gcloud コマンドの場合、ルールの作成時に --preview フラグを付けると有効になります。 gcloud compute security-policies rules create 1000 \ --security-policy=POLICY_NAME \ --expression="evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})" \ --action=deny-403 \ --preview ルールのロジックのテストにも、プレビューモードを使用します。たとえば、優先度の高い許可ルールに一致した通信は、その後の拒否ルールでは評価されません。複数のルールを組み合わせるときは、疑似的なリクエストを送り、意図したルールに一致するかをログで確認します。 参考 : Use preview mode 参考 : Test your logic 参考 : gcloud compute security-policies rules create Adaptive Protection を有効にする Adaptive Protection は、バックエンドサービスごとに通常のトラフィックを機械学習で学習し、L7 の DDoS 攻撃などの異常なトラフィックを検知してアラートを出す機能です。有効にしてからアラートが出るようになるまで、最低 1 時間の学習期間があります。 使用できる機能は、ティアによって異なります。 ティア 機能 Standard 基本的なアラート（検知の信頼度と攻撃の規模） Enterprise 基本的なアラートに加え、攻撃のシグネチャと、攻撃を遮断するための推奨ルール アラートは、通知先を設定しないと担当者に届きません。Cloud Monitoring のアラートポリシーを作成し、検知したときの連絡経路を決めておきます。 なお、Adaptive Protection は大量のリクエストによる攻撃の検知に向いており、少量のリクエストで行われる攻撃は検知できない場合があります。そうした攻撃には、リクエストの中身を検査する事前構成 WAF ルールなどで対策します。 参考 : Adaptive Protection overview 参考 : Enable Google Cloud Armor Adaptive Protection レート制限を設定する レート制限は、一定時間内のリクエスト数に上限を設け、上限を超えたリクエストを制限する機能です。ログイン画面への総当たり攻撃や、API の過剰な呼び出しを抑えるときに使用します。 レート制限のアクションには、以下の 2 種類があります。 アクション 動作 スロットル 上限を超えたリクエストだけを拒否（またはリダイレクト）し、上限以内のリクエストは許可し続ける レートベースの禁止 上限を超えたクライアントからのリクエストを、指定した時間（60〜3,600 秒）すべて拒否する 上限は、送信元 IP アドレス、HTTP ヘッダー、Cookie の値、パスなど、キーを指定して数えます。上限を超えたときの応答コードには、429（Too Many Requests）が推奨されています。 適切なしきい値はアプリケーションの通信量によって異なります。まずプレビューモードでルールを追加し、ログから通常時のリクエスト数を把握してから、しきい値を決めます。 以下は /login へのリクエストを IP アドレスごとに 1 分あたり 100 件までに制限する例です。 gcloud compute security-policies rules create 1000 \ --security-policy=POLICY_NAME \ --expression="request.path.matches('/login')" \ --action=throttle \ --rate-limit-threshold-count=100 \ --rate-limit-threshold-interval-sec=60 \ --conform-action=allow \ --exceed-action=deny-429 \ --enforce-on-key=ip \ --preview 参考 : Rate limiting overview 優先度の間隔とルールの説明 ルールの優先度は、後からルールを追加できるよう、間隔を空けて設定します。公式ドキュメントでは、10 以上の間隔を空けることが推奨されています。また、似たルールは近い優先度にまとめ、グループの間はさらに大きく空けます。たとえば、評価順の No.1 を 1000 番台、No.2 を 2000 番台、No.3 を 3000 番台、No.4 を 4000 番台のように割り当てると、評価順の設計と対応させて管理できます。 ルールには、作成した理由を説明欄に記載します。説明欄は 64 文字までのため、詳しい経緯は構成管理データベース（CMDB）などに記録し、説明欄からその場所が分かるようにしておきます。 参考 : Provide rule descriptions 参考 : Consider priority spacing JSON の解析と Bot 管理 JSON 形式のリクエストボディを受け付けるアプリケーションでは、JSON の解析を有効にします。JSON の解析はデフォルトで無効です。無効のままだと、事前構成 WAF ルールは JSON の構造を解析せずにボディを検査するため、誤検知が増えます。JSON の解析は、セキュリティポリシー単位で設定します。 gcloud compute security-policies update POLICY_NAME \ --json-parsing=STANDARD GraphQL を使用する場合は、 STANDARD_WITH_GRAPHQL を指定します。なお、事前構成 WAF ルールは、リクエストボディの先頭からデフォルトで 64 KB までを検査します。この上限は 8〜64 KB の範囲で変更できます。 Bot による不正なログインや大量アクセスの被害がある場合は、reCAPTCHA と連携した Bot 管理を検討します。Cloud Armor が reCAPTCHA のトークンを評価し、Bot と判定したリクエストを、バックエンドに届く前に拒否やリダイレクトできます。Bot 管理は Standard と Enterprise のどちらでも使用できますが、reCAPTCHA の料金が別途かかります。 参考 : Enable JSON parsing 参考 : Request body content parsing 参考 : gcloud compute security-policies update 参考 : Bot management overview 参考 : Use reCAPTCHA for bot management ルールのチューニング 感度レベルを選ぶ 事前構成 WAF ルールの感度は、0〜4 の値で指定します。指定した感度以下のシグネチャが有効になり、感度 0 ではどのシグネチャも有効になりません。感度を指定しない場合は感度 4 となり、すべてのシグネチャが評価されます。 感度 特徴 1 精度の高いシグネチャだけを評価する。誤検知が少ない 2〜3 検知の範囲が広がる。誤検知も増える 4 すべてのシグネチャを評価する。誤検知が最も多い 公式ドキュメントでは、 多くのアプリケーションで感度 1 から始めることが推奨されています 。前提知識で説明したとおり、SQLi のルールには通常の入力値でも一致しやすいシグネチャが感度 3 と 4 に含まれます。感度を指定せずにルールを追加すると、こうしたシグネチャによる誤検知で正常な通信が遮断されるおそれがあります。 感度は、ルールの条件式で指定します。 evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1}) 感度 1 で運用を始め、ログで誤検知がないことを確認しながら、必要に応じて感度を上げます。誤検知の原因となる特定のシグネチャは、 opt_out_rule_ids で除外できます。特定のパラメータやヘッダーだけを検査の対象から外すこともできます。 なお、CRS 3.0 の書式（ evaluatePreconfiguredExpr('sqli-stable') など）を使用している環境もあります。2026年10月現在、Cloud Armor では CRS 4.22 の使用が推奨されています。ワークロードが許す範囲で、CRS 4.22 のルールへの移行を検討します。 参考 : Tune preconfigured WAF rules 参考 : Choose your preconfigured WAF rule sensitivity level 参考 : Cloud Armor release notes (July 08, 2026) 詳細ログを使う 詳細ログ（verbose logging）を有効にすると、リクエストのどの部分が事前構成 WAF ルールに一致したかがログに記録されます。誤検知の原因を調べるときに役立ちます。 gcloud compute security-policies update POLICY_NAME \ --log-level=VERBOSE 詳細ログには、ルールに一致した部分のリクエストの内容が記録されます。利用者の個人情報が含まれるおそれがあるため、公式ドキュメントでは、本番環境で長期間有効にすることは推奨されていません。チューニングの期間だけ有効にし、終わったら --log-level=NORMAL に戻します。 参考 : Enable verbose logging 参考 : Verbose logging stable と canary を使い分ける 事前構成 WAF ルールには、 stable と canary の 2 つの版があります。新しいシグネチャは、先に canary に反映され、後から stable に反映されます。 シグネチャの追加による影響を事前に確認したい場合は、同じ種類のルールを canary と stable で 1 つずつ作成します。SQLi のルールの例は以下のとおりです。 優先度 ルール 設定 1000 sqli-v422-canary プレビュー（新しいシグネチャの影響をログで確認する） 1010 sqli-v422-stable 強制適用（攻撃を遮断する） プレビューモードのルールはアクションを実行しないため、canary のルールに一致したリクエストも、続けて stable のルールで評価されます。そのため、実際の防御は stable のルールで行いながら、canary に追加された新しいシグネチャが正常な通信に一致しないかを、stable に反映される前にログで確認できます。 参考 : Use stable or canary rules ロギングとモニタリング ログを有効にする Cloud Armor のログは、ロードバランサのログとして Cloud Logging に記録されます。ロードバランサのログはデフォルトで無効のため、バックエンドサービスでログを有効にします。 ログを記録する割合は、ロードバランサのサンプリングレートで決まります。チューニングや導入の期間は サンプリングレートを 1 （すべてのリクエストを記録）にすることが推奨されています。チューニングが終わった後も、すべてのリクエストを記録し続けることが推奨されていますが、ログの量に応じてサンプリングレートを下げることもできます。 gcloud compute backend-services update BACKEND_SERVICE_NAME \ --enable-logging \ --logging-sample-rate=1 \ --global 参考 : Choose a Cloud Logging sampling rate 参考 : Use request logging 参考 : gcloud compute backend-services update Security Command Center と Cloud Monitoring 組織レベルで Security Command Center（以下、SCC）を有効にしている場合、Cloud Armor の検出結果が SCC に表示されます。 検出結果 内容 Allowed Traffic Spike 許可されたリクエストが急増した Increasing Deny Ratio 拒否されたリクエストの割合が増えた これらの検出結果は、L7 の DDoS 攻撃の可能性や、望ましくない通信の増加を示すため、セキュリティ管理者が定期的に確認します。 Cloud Monitoring では、「Cloud Armor policies overview」ダッシュボードで、セキュリティポリシーごとの許可・拒否・プレビューの件数を確認できます。 参考 : Use the Security Command Center 参考 : Security Command Center findings 参考 : Monitoring Cloud Armor security policies 全般的な管理 IAM でアクセスを制御する セキュリティポリシーを変更できるユーザーは IAM で制御します。Cloud Armor の操作に必要な IAM ロールは以下のとおりです。 操作 必要な IAM ロール・権限 セキュリティポリシーの作成・変更・削除 Compute セキュリティ管理者ロール（ roles/compute.securityAdmin ） バックエンドサービスへのセキュリティポリシーの適用 Compute ネットワーク管理者ロール（ roles/compute.networkAdmin ） 例として、ルールを変更する担当者とロードバランサを管理する担当者を分けることで、意図しないルールの変更やセキュリティポリシーの付け外しを防げます。 参考 : Set up Identity and Access Management access control 参考 : Set up IAM permissions for Cloud Armor security policies ポリシーの利活用 セキュリティポリシーは複数のバックエンドサービスに適用できます。同じ要件のアプリケーションには共通のセキュリティポリシーを再利用し、ポリシー数を最小限に抑えます。ポリシーの数が増えると、ルールの変更漏れや設定の差異が起きやすくなるためです。 セキュリティポリシーは Terraform で管理できます。変更履歴が残り、問題があったときに以前の構成へ戻したり、別のプロジェクトで同じ構成を再現したりできます。Cloud Armor の GA 済みの機能は Terraform で設定できます。 参考 : Use Terraform 参考 : google_compute_security_policy GKE での構成 GKE で Ingress や Gateway を使用すると、アプリケーションを公開するためのロードバランサとバックエンドサービスは、GKE が自動で作成・管理します。Cloud Armor で保護する場合は、作成されたバックエンドサービスに直接セキュリティポリシーを設定せず、Kubernetes のリソースから指定します。直接設定した内容は、Kubernetes のリソースでセキュリティポリシーを指定したときに上書きされるためです。 公開方法 特徴 セキュリティポリシーを指定するリソース Ingress 従来からある公開方法。ロードバランサの設定とルーティングの設定を、1 つのリソースにまとめて定義する BackendConfig Gateway Ingress を発展させた新しい公開方法。ロードバランサの設定（Gateway）とルーティングの設定（HTTPRoute）を分けて定義でき、インフラ担当者とアプリケーション開発者で管理を分担できる GCPBackendPolicy Gateway を使用する場合は、先に Cloud Armor のセキュリティポリシーを作成しておき、GCPBackendPolicy から参照します。リージョンの Gateway では、リージョンのセキュリティポリシーを作成する必要があります。 参考 : Configure Cloud Armor with Google Kubernetes Engine 導入の進め方 確認ポイント これから Cloud Armor を導入する場合や、導入済みの設定を見直す場合は、以下の項目を確認します。 確認項目 確認方法の例 ルールを推奨の評価順で並べているか セキュリティポリシーのルールと優先度の一覧 新しいルールをプレビューモードで確認してから適用しているか ルールのプレビューの設定、変更の手順 Adaptive Protection を有効にし、アラートの通知先を設定しているか セキュリティポリシーの設定、Cloud Monitoring のアラートポリシー レート制限のルールを設定しているか スロットル・レートベースの禁止のルールの有無 事前構成 WAF ルールの感度を指定し、CRS 4.22 を使用しているか ルールの条件式（ sensitivity の指定、 v422 の使用） ロードバランサのログを有効にしているか バックエンドサービスのログの設定とサンプリングレート セキュリティポリシーを変更・適用できるユーザーを限定しているか IAM ロールの付与状況 JSON を受け付ける場合に、JSON の解析を有効にしているか セキュリティポリシーの詳細設定 ロードマップ Cloud Armor の導入は、以下の 5 つのステップで進めます。ステップ 2〜4 は、ルールを追加するたびに繰り返します。 ステップ 内容 1. 要件の整理 保護する対象と要件を整理する。導入済みの場合は、前述の確認ポイントで、まだ対応できていない項目を洗い出す 2. プレビューでの導入 必要なルールをプレビューモードで追加し、ログを取得する 3. チューニング 誤検知の原因となるシグネチャを除外し、感度を調整する 4. 強制適用 正常な通信への影響がないことを確認したルールから、順に強制適用に切り替える 5. 追加の対策の検討 Cloud Armor Enterprise や Cloud NGFW Enterprise の要否を判断する ティアと料金 Cloud Armor には Standard と Enterprise の 2 つのティアがあり、Enterprise には Paygo と Annual の 2 つの契約形態があります。2026年10月現在の主な違いは以下のとおりです。 機能 Standard Enterprise Paygo Enterprise Annual 料金 従量課金 月額 $200 / プロジェクト 月額 $3,000 / 請求先アカウント ・事前構成 WAF ルール ・レート制限 ・カスタムルール ◯ ◯ ◯ マネージドルール（Preview） アドオン アドオン アドオン Adaptive Protection アラートのみ ◯ ◯ ・脅威インテリジェンス ・名前付き IP アドレスリスト × ◯ ◯ ・アドレスグループ ・階層型セキュリティポリシー × ◯ ◯ 高度なネットワーク DDoS 保護 × ◯ ◯ ・DDoS 対応サポート ・DDoS 請求保護 × × ◯ Standard は、セキュリティポリシー 1 つあたり月額約 $5、ルール 1 つあたり月額約 $1、リクエスト 100 万件あたり $0.75（グローバル）の従量課金です。 Enterprise では、セキュリティポリシー、ルール、リクエストの料金が月額料金に含まれます。ただし、Standard にはないデータ処理料金がかかります。Paygo は月額料金に 2 つの保護対象リソースが含まれ、3 つ目以降は 1 リソースあたり月額 $200 が追加されます。Annual は 12 か月の契約で、100 リソースまで含まれ、101 個目以降は 1 リソースあたり月額 $30 が追加されます。 DDoS 対応サポートを受けるには、Annual の契約に加えて、カスタマーケアの Premium サポートの契約などの条件があります。また、Annual の契約がない場合、階層型セキュリティポリシーを継承したプロジェクトは、自動的に Paygo に登録されます。 参考 : Cloud Armor Enterprise overview 参考 : Cloud Armor pricing 武井 祐介 (記事一覧) クラウドソリューション部 > 事業開発部。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei