はじめに 金融IT本部 3年目の坂江 克斗です。 re:Invent 2025 で公開されたFrontier Agentの1つとして AWS Security Agent が発表され、3月には AWS Security Agentのペネトレーションテストが一般公開 されました。 AWS Security Agentは、開発フローにセキュリティを統合する DevSecOps において、その「Sec（セキュリティ）」を担うようなサービスです。 本記事では、AWS Security Agent 全体の使用感を、コンソール操作とCICDへの組み込みイメージも含めて紹介します。 ※本記事は2026年6月時点の情報です。 本記事執筆時の2026年6月17日に、 AWS Continuum が発表され、AWS Security Agent のペネトレーションテスト・コードスキャン機能は「Continuum for penetration testing」「Continuum for code scanning」（プレビュー）として Continuum の一部にもなりました。本記事の操作内容は引き続き参考になりますが、AWS Security Agent の名称や提供形態は今後変わっていく可能性があります。 はじめに Frontier Agent とは AWS Security Agent の概要 全体像 コスト クォータ データ保護 テスト・レビュー コンソール画面 実際に試してみる 管理者側の設定手順 AWS Security Agent アプリケーションの作成・エージェントスペースの作成 【AWS Security Agent アプリケーションが既に存在する場合】エージェントスペースだけの作成 セキュリティエージェントを使用可能な開発者の登録 ターゲットドメインの登録 リポジトリの統合 セキュリティ要件 コードレビューの有効化 ペネトレーションテストの有効化 開発者用コンソールの確認 開発側の実行手順 設計レビューの実行 コードレビューの実行 脅威モデルの実行 ペネトレーションテストの実行 レポートの確認 デザインレビュー 脅威モデル コードレビュー・ペネトレーションテスト CI/CDへの組み込み CLIコマンドの基本構造 共通： AWS 認証（OIDC） develop マージ時： コードレビュー stg デプロイ完了後： 軽量ペンテスト（DAST・対象を絞る） リリース時 / 定期： フルスコープのペネトレーションテスト 設計ドキュメント更新時： デザインレビュー（脅威モデリング） まとめ おわりに Frontier Agent とは 少し前になりますが、2025年のre:Inventにて「フロンティアエージェント（Frontier Agent）」という新しいカテゴリのAIエージェントが発表されました。 フロンティアエージェント とは、 自律的に動作する開発チームの拡張機能 として位置づけられたAIエージェントです。 個々のタスクをサポートする従来の AI アシスタントとは異なり、フロンティアエージェントはチームの拡張機能として機能し、多様なユースケースにわたって包括的な成果をもたらします。 AWSが定義するフロンティアエージェントには、以下の3つの特徴があります。 自律的 — 人間が常に介入しなくても、独立して動作します スケーラブル — 大規模なスケーリングにより、複数タスクを同時実行します 長時間実行 — 24時間365日、継続的に動作できます 2025年re:Inventで発表されたフロンティアエージェントは以下の3種類です。 エージェント 役割 AWS Security Agent 仮想セキュリティエンジニア。設計・コード・稼働中アプリを横断してセキュリティを担保する AWS DevOps Agent 仮想SREメンバー。インシデントのトリアージや根本原因分析、復旧を自律的に行う Kiro autonomous agent 仮想開発者。仕様書からコード生成・テスト・デプロイまでを担う 中でも今回は、インフラ構築の文脈で特に気になった AWS Security Agent を調査しましたので、その仕組みをまとめます。 去年のre:Invent直後に宮崎さんが AWS re: Invent2025で登場した3つのFrontier Agentsの1つである「AWS DevOps Agent」を触りつつ、概要について整理してみる。 という記事を書いていますので、気になる方はぜひご覧ください。 AWS Security Agent の概要 全体像 AWS Security Agentは機能としては、 SAST（Static Application Security Testing）・ DAST（Dynamic Application Security Testing） ・ペネトレーションテスト を単一のエージェントに統合し、 設計ドキュメントからソースコード・IaC・脅威モデルまでを取り込んでアプリの全体像（コンテキスト）を把握 することで、個々の脆弱性の連鎖まで含めた精度の高い検出と実用的な修復提案を実現するサービスです。 Security Hub/GuardDuty/Inspector などによる従来の事後的なセキュリティ調査では、本番デプロイ後に問題が見つかるため、設計やコードに起因する脆弱性ほど手戻りが大きくなりがちです。こうした背景から、 開発からデプロイまでのフローの早い段階にセキュリティのチェックを寄せる「シフトレフト」や、それを開発プロセスに組み込む「 DevSecOps 」 が重視されるようになってきました。AWS Security Agentは、この考え方を踏まえたサービスとなります。 DevOpsによって開発サイクルが高速かつ高頻度で回るようになった一方、セキュリティが従来どおりの体制のままでは開発スピードに追いつけません。この課題に対して生まれたのが DevSecOps で、開発初期からセキュリティを考慮するシフトレフトの動きを取りつつ、DevOpsの効率性を損なわないようにセキュリティレビュー等を自動化に組み込むことが重視されます。 AWS Security Agentは、大まかに以下の構成となっています。 設計レビュー（デザインレビュー） ・ コードレビュー ・ 脅威モデリング ・ ペネトレーションテスト という4つの作業を行うことができ、各レビュー・テストにおいては、管理側・開発側でコンソールを切り替えることができます。 そのため、開発側は作業中に管理側を意識する必要がなく、不要に管理設定を変更してしまうことを防げます。 コスト コストについては、現在のところ ペネトレーションテストの料金 のみが公開されており、1タスク時間あたり50ドル、かつ初回は2か月間・最大200タスク時間分が無料となっています。 AWS 公式ドキュメントによると、 平均的なアプリケーションテストには約 24 タスク時間かかり、包括的な侵入テストと修復にかかる費用は通常 1,200 ドル の見込みとのことです。 このタスク時間は、ペネトレーションテスト実行中にタスクごとに独立してエージェントが稼働していた場合、それぞれのエージェントの稼働時間を合算したものがそのままタスク時間に換算されます。 クォータ Service Quotas より、各レビューやテスト、連携可能なリソース数などに上限が設定されています。ただし、AWSサポート経由で申請することで上限を変更できます。 データ保護 アップロードするドキュメントなどのデータは、既定でAWSマネージドキーにより暗号化され、任意でカスタマーマネージドキー（CMK）を指定して自社で鍵を管理することも可能です。 S3・CloudWatch Logs・Secrets Managerを連携する際も、CMKで暗号化したものを渡して使用できます （各リソースのKMSキーポリシーと、サービスロールへの復号権限の設定が必要）。 ただし、 CMKを指定できるのはリソース（エージェントスペースや統合）の作成時のみで、既存リソースへの後付けや鍵の差し替えはできない点に注意が必要です （CMKで運用する場合はリソースの再作成が必要）。 テスト・レビュー 各テスト・レビューの内容を紹介します。詳細な設定方法や実際の動作については次の章をご参照ください。 なお、ポイントについてはドキュメントの内容に加えて私の解釈も含むため、セキュリティエンジニアの方のご意見もぜひ伺いたいです。 項目 概要 ポイント（普通のAI・既存ツールとの差分） 設計レビュー 設計書などのドキュメントを、組織で定義したセキュリティ要件（AWSマネージド／カスタムのガイドライン）に照らして自動レビューし、コードを書く前の段階で指摘。数分～数十分程度で完了。 セキュリティチームが基準を一元的に定義し、開発者側は変更・迂回できない（責務の分離）。組織横断で同じ基準を強制でき、結果が監査ログ・レポートとして残る。従来のSASTと異なり、（アプリ実行時のコンテキストを含まない）パターンマッチングではなく、 アプリの実際の動作・コンテキストを推論して脆弱性を検出 。 コードレビュー 連携したリポジトリやS3のコードを、セキュリティ要件に照らしてレビュー。フルリポジトリ／差分を選択でき、PRへのレビューコメントや自動修正PRまで対応。数分～数十分程度で完了。 設計レビューと同様。Gitにも統合でき、差分レビューなど使いやすい構成。 脅威モデル 攻撃者視点で潜在的な脅威を洗い出して分析。コード以外の信頼境界・権限設計・外部連携なども含め、広範な攻撃経路を整理。数分～数十分程度で完了。 実装上の問題を中心に見るコードレビューと異なり、アーキテクチャ全体のリスクを俯瞰。 ペネトレーションテスト （ 副作用を考慮し、検証環境での実施を推奨 ）稼働中のアプリに対し、ソースコードやドキュメントソースをもとにした多段階の攻撃シナリオで脆弱性を検出。再現手順・PoC・CVSS・修正PRまで提示。数時間～数十時間程度で完了。 従来の DAST と異なり、ブラックボックス的なアプローチではなく、 ソースコードやAPI仕様、設計書をもとにアプリの詳細なコンテキストを構築して検証 。テスト項目の設定によりスコープ調整も可能。 コンソール画面 操作するインターフェースは2層に分かれています。テストのスコープ・セキュリティ要件・リポジトリ統合などを設定する管理者コンソール（AWSマネジメントコンソール内）と、実際にレビューやテストを実行する開発者向けのWebアプリです。 開発者向けのWebアプリは、明示的にアクセス権限を設定でき、運用しやすい構成となっています。 実際に試してみる 本記事では、管理者側・開発者側それぞれの操作方法を紹介しながら、基本的な使用方法について共有します。 その他の詳細な設定について参照が必要な場合は、 AWS Security Agent ： User Guide をご参照ください。 前提として以下のリソースを準備します。 ドキュメント 設計書やAPI仕様（OpenAPIまたはSwagger）等 コードソース GitHub リポジトリ（今回はこちらで検証） S3バケット内のZIPファイル セキュリティ要件 上記のドキュメントやコードソースに対して準拠させたいガイドラインやポリシー ペネトレーションテスト用のエンドポイント情報（ 本番ではなくステージング環境を推奨 ） ターゲット情報（ 外部APIや決済処理、データの削除・更新等の副作用を伴うエンドポイントは除外 ） ドメイン パス VPC内のプライベートなアプリケーションの場合（Security Agent自身がENIを使用してアクセス） VPC ID サブネット ID セキュリティグループ ID アプリケーション接続時に認証情報が必要な場合 静的な認証情報（平文 or Secrets Managerシークレット） 動的な認証情報の生成方法をまとめたプロンプト Security Agent自体の運用管理 CloudWatch ロググループ（コンソールから作成する場合は自動作成されるため任意） IAM サービスロール（コンソールから作成する場合は自動作成されるため任意） KMSキー（デフォルトはAWSマネージドキーで管理されるため任意） 開発者に対応する IAM Identity Center のユーザ（Security Agentを使用可能なユーザを明示的に指定） 管理者側の設定手順 AWSコンソールのAWS Security Agentの画面より、管理者側の設定を行います。 AWS Security Agent アプリケーションの作成・エージェントスペースの作成 各レビュー設定に入る前に、AWSコンソールから全体で必要な設定をしておきます。 Security Agentのコンソール画面に遷移したら、「AWS Security Agentをセットアップ」ボタンを押下します。 AgentSpaceの設定を入力しつつ、AWSマネージドキーではなく、CMK（カスタマーマネージドキー）でデータを保護したい場合には、「Customize encryption settings (advanced)」チェックボックスにチェックを入れ、任意のCMKを紐付けてください。 タグについては、エージェントスペースタグがエージェントスペースに付与されるタグ、アプリケーションタグがAWS Security Agentアプリケーション自体に付与されるタグとなります。 また、 IAM Identity Centerもここで紐づくため、インスタンスを再作成すると連携が切れてしまう点に注意が必要です。（コンソールやCLI経由での更新不可です） 完了後、AWS Security Agent アプリケーションとエージェントスペースが作成されます。 【AWS Security Agent アプリケーションが既に存在する場合】エージェントスペースだけの作成 既にAWS Security Agentアプリケーションを作成済みの状態で、エージェントスペースのみ作成する場合は以下のように作成します。 Security Agentのコンソール画面に遷移したら、「最初のエージェントスペースを作成」ボタンを押下します。 AWSマネージドキーではなく、CMK（カスタマーマネージドキー）でデータを保護したい場合には、「Customize encryption settings (advanced)」チェックボックスにチェックを入れ、任意のCMKを紐付けてください。 作成画面の入力後、「作成」ボタンを押下します。 セキュリティエージェントを使用可能な開発者の登録 作成したエージェントスペース画面のウェブアプリタブにおいて、「ユーザの追加」を押下します。 IAM Identity Centerで設定したユーザーを選択し、「ユーザーを追加」ボタンを押します。 画面遷移後、ユーザーが追加されていることを確認できます。 ターゲットドメインの登録 サイドバーの「ターゲットドメイン」を押下し、ターゲットドメインのページから「ドメインを追加」ボタンを押下します。 ペネトレーションテストの対象となるドメイン・検証方法を選択し、「ドメインを追加」ボタンを押下します。 今回は検証方法としてDNS TXTレコードを指定しました。その他のHTTPルートやプライベートVPCの検証については「 Managed target domains used for penetration testing」 をご参照ください。 ターゲットドメインの追加完了後、「ワンクリック検証」を押下します。レコードの追加も含めマネージドに対応してくれるので、そのまま進めます。 検証が完了すると、ステータスが検証済みになります。 リポジトリの統合 サイドバーの「統合」から、「統合の追加」ボタンを押下します。今回はGitHubを選択して進めていきます。 設定画面に遷移したら、ステップ1より順に設定します。 ステップ2の「GitHubでAWS Security Agentを開く」を押下すると、GitHubアプリのインストール画面に遷移するのでインストールします。 この際、連携するリポジトリをアカウント内すべてにするか、特定のリポジトリに限定するかを選択できます。 インストールの完了後、ステップ3で認証するボタンを押下します。「認証が成功しました」という表示が出ることを確認します。 最後にステップ4で、登録名・アカウントタイプ・CMKによる暗号化を設定したら、「接続」ボタンを押下して完了です。 セキュリティ要件 コンソールサイドバーのセキュリティ要件より、マネージドまたはカスタムのセキュリティ要件を設定することができます。 セキュリティ要件は、設計レビューやコードレビューの際のガイドラインとなる設定であり、各セキュリティ要件項目と、それをまとめたパックの単位で管理を行います。 マネージドセキュリティ要件パックについては、 AWS managed security requirement packs またはコンソールから各設定値をご参照ください。 デフォルトではASA Base Packのみ有効化されています。 カスタム設定については、「Create security requirements pack」ボタンを押下してパックを作成した後に、パック内でセキュリティ要件を個々に設定します。 セキュリティ要件パックの作成後、セキュリティ要件の追加時には、手動での入力またはドキュメントを読み込ませて自動生成する方法を選ぶことができます。 マニュアル設定 の場合は、以下に示すように、条件を適用するシナリオ、具体的な違反内容、修正方法の提示について入力が必要となります。 ドキュメントをアップロードして自動生成する場合は、ファイルサイズにもよりますが、60KB程度のmdファイルを読み込ませて、数分程度で20個のセキュリティ要件が生成されました。 ただし、注意点として、 https://docs.aws.amazon.com/ja_jp/securityagent/latest/userguide/security-requirements.html にあるとおり、既存の要件を置き換えることになる点に注意が必要です。 Uploading new source documents regenerates all requirements for the pack. Any existing requirements, including ones you added manually, are replaced. コードレビューの有効化 コードレビューを有効にするボタンを押下して進めます。 接続された統合項目の追加ボタンを押下し、先ほど連携したGitHubアカウントを選択します。 今回は使用しませんが、S3バケットもコードの保存先として参照可能です。 アカウント内のリポジトリを選択し、「次へ」ボタンを押下します。 以下の設定を確認し、「接続」を押下します。 コードレビューコメント：PR作成時にレビューコメントを追加してくれる許可 PR修正：レビューやテスト後に脆弱性の箇所を自動でPR作成する許可 完了すると、コードレビューの設定画面に戻り、統合が追加されたことが確認できます。 その他の項目も確認し、「次へ」ボタンを押下します。 オプション設定画面に遷移したら、CloudWatchログとサービスロールを設定します。これらは事前に準備したもの、もしくは入力を更新せずにマネージドに作成されるものも使用可能です。設定ができたら、保存を押下します。 エージェントスペース画面に戻ると、脅威モデルについてもセットで有効化されていることが確認できます。 ペネトレーションテストの有効化 最後にペネトレーションテストの有効化ボタンを押下します。 先ほど設定したターゲットドメインを選択し、「次へ」ボタンを押下します。 ターゲットドメインが検証済みであることを確認し、「次へ」ボタンを押下します。 以下の設定項目について確認し、入力が完了したら保存を押下します。 VPC：VPC内でプライベートなエンドポイントを叩く場合など、Security AgentがVPC内のENIからターゲットにアクセスする際の設定 VPC、サブネット、セキュリティグループ CloudWatchログ：ログの出力先、任意 シークレット：テスト打鍵時にログインなどの認証情報を保存しておくために使用 Lambda関数：動的な認証情報生成用に独自デプロイしたものがあれば指定 Lambdaがない場合でも、テスト実行時のプロンプトでカバー可能かどうかは要検討 S3バケット：ペネトレーションテスト実行時にアプリケーションの構成などを学習するためのリソースとして使用可能 全項目が準備完了のステータスであることを確認して完了です。 開発者用コンソールの確認 エージェントスペース画面において、ウェブアプリケーションの項目から開発者用のコンソール（レビューやテストを実行する場所）を開くことができます。 管理者アクセスの場合は「管理者アクセス」ボタンを押下し、直接エージェントスペースに対応するコンソールに移動します。 エージェントウェブアプリのURLよりアクセスする場合は、紐付けたIAM Identity Centerユーザでログインしたのちに、そのユーザが使用可能なエージェントスペースの一覧が表示され、そこから指定のエージェントスペースに遷移する形となります。 以上で管理者側の設定は完了です。次に、実際にテストを実行します。 開発側の実行手順 開発者用のコンソール画面より、開発者側の操作（レビュー・テスト）を行います。 設計レビューの実行 ホーム画面から「設計レビューを作成する」を押下し、レビュー対象のファイルをアップロードして、「開始する」ボタンを押下します。 デザインレビューが進行中となります。 完了すると、コンソールからそのまま実施結果を確認することができます。 「レポートをダウンロード」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 コードレビューの実行 ホーム画面から「コードレビューを作成する」を押下し、以下の項目を設定して、「作成する」ボタンを押下します。 ソース：コードソースを選択。今回は先ほど設定したGitHubリポジトリを設定 サービスロール：管理者画面で設定したサービスロールを選択 CloudWatchロググループ：未入力で自動生成されます 自動コード修正：有効にするとレビュー結果に応じてPRを自動作成します 作成したコードレビューを押下します。 「レビューを開始する」ボタンを押下し、コードレビューを開始します。 ただし、プルダウンから差分コードレビューも選択可能です。2回目以降、頻繁に回す場合は差分レビューが推奨されると考えられます。（毎回フルリポジトリレビューを実行するとコストに響いていく想定） コンソールから結果を確認することができます。 「レポートを生成」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 脅威モデルの実行 ホーム画面から「脅威モデルを作成する」を押下し、以下の項目を設定して、「脅威モデルを作成する」ボタンを押下します。 リポジトリ：先ほど設定したコードソースを選択 機能仕様書：ドキュメントをアップロード サービスロール：管理者画面で作成したサービスロールを選択 CloudWatchロググループ：未入力で自動生成されます 設定完了後、「実行を開始する」ボタンを押下します。 実行結果についてはコンソールから取得できます。 「レポートを生成」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 ペネトレーションテストの実行 ホーム画面から「ペネトレーションテストを作成する」を押下し、以下の項目を設定して、「次へ」ボタンを押下します。 ターゲットや除外対象を調整することで、テストスコープを大まかに調整することができます。 ターゲットURL：検証済みのドメインをもとにURLを入力 リスクタイプを除外する：テストで検証しなくてもよい項目を選択し除外可能 範囲外のURL：テストでアクセスしてほしくないURLを入力（外部APIや決済処理、データの削除・更新などの副作用を伴うエンドポイント等） アクセス可能なURL：テスト中に攻撃対象ではないが、アクセスを許可するURLを入力 カスタムHTTPヘッダ：静的なヘッダのキーと値を設定（動的な設定がしたい場合は、以降の手順で対応） サービスロール CloudWatchロググループ VPCリソースの設定画面に遷移しますが、今回は設定項目がないため「次へ」ボタンを押してスキップします。 管理者画面で設定していた場合は、VPC、サブネット、セキュリティグループを設定可能です。 認証リソースの設定画面に遷移しますが、今回は設定項目がないため「次へ」ボタンを押してスキップします。 認証情報についてはシークレットまたは平文での静的情報が入力可能なほか、エージェントスペースのログインプロンプトに動的な認証方法に関する記載をすることで、動的な認証にも対応できます。 実際に、動的にトークンを生成してカスタムヘッダに載せる必要があるアプリで動作を確認できました。 その他の設定画面において、以下を設定し、「ペネトレーションテストモデルを作成する」ボタンを押下します。 リソース：コードソースなどを設定 自動コード修正：有効化するとペネトレーションテストの結果に応じてPRを自動作成 検出結果のパーソナライゼーション（ オンオフでの差分未確認 ） リソースを可能な限りクリーンアップ（ オンオフでの差分未確認 ） 作成後、「実行を開始する」ボタンを押します。 実行結果についてはコンソールから取得できます。 テストの取得結果数が少ないのは、実行中に裏側で呼び出しているBedrockの存在に気づき、コスト懸念のため途中で中止したためです。 レポートの確認 デザインレビュー デザインレビューについては、「レポートをダウンロード」からCSV形式でレポートを取得できます。 デザインレビューは手動でファイルを読み込ませる形式で自動修正等もないため、このCSVを手元のAIエージェントに読み込ませて修正することを想定しています。 脅威モデル 脅威モデルの場合は、「レポートを生成」ボタンを押下すると、レポートをPDF形式で取得することができます。 体裁（抜粋） 構成 Introduction 脅威モデルの対象、実施日、検出された脅威件数、重大度の内訳 System Overview 対象システムの目的、機能、アーキテクチャ、主要コンポーネントの説明 Configuration 脅威モデルに使用したスコープ文書、連携リポジトリ、S3ソース、ドキュメントなどの設定情報 Threats 実際に検出された脅威シナリオの一覧 Detailed Threats 各脅威シナリオに対する攻撃者、攻撃が成立するための前提条件、具体的な攻撃方法、攻撃成功時の影響、脅威の根拠、脅威の判断に紐づく構成箇所 System Overview章では設計書やコードから、アプリの構成に関する洞察がかなり細かく記載されており、セキュリティ上のリスクを多角的に把握する上で非常に有用であると感じます。 コードレビュー・ペネトレーションテスト 同様に、コードレビューやペネトレーションテストの場合は、「レポートを生成」ボタンを押下すると、レポートをPDF形式で取得することができます。 体裁（抜粋） 構成 Report Filters Applied このレポートに含めるリスクレベル、信頼度、ステータスなどの抽出条件 Executive Summary テスト対象、実施日、検出された脆弱性件数、重大度の内訳 Scope ペネトレーションテスト：対象URL、対象外URL、利用した認証情報 コードレビュー：対象リポジトリ、S3バケット Methodology AWS Security Agent がどのような流れ・観点でテストを実施したかの説明 ペネトレーションテストの場合は、表形式でXSS、SQL Injection、SSRF、Path Traversalなど、実際に実施されたテスト項目の一覧を記載 Findings 実際に検出されたセキュリティ指摘の一覧 Detailed Findings 各セキュリティ指摘に対する、概要、再現手順、 CVSS（Common Vulnerability Scoring System）評価 の根拠、推奨修正方針、修正対応PR ペネトレーションテストの結果におけるMethodology章では、例えば私のサービスではバックエンドにDynamoDBやSQLを使用している点から、それらの要素を突くような攻撃を実施した旨が記載されていました。これは、学習リソースとしてGitHubリポジトリを与えたために、IaCで管理しているリソースやアプリケーションロジックを総合して攻撃方法を検討していることが確認できました。 まさに、 AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 で紹介されていたような、 アプリケーションコンテキストを追加して精度と検出の深度を向上 させるという面が見られたのではないかと感じます。 また、今回はコードレビューとペネトレーションテストの際にリポジトリへの修正PRを許可していることから、自動でPRを立てていました。 実施理由から変更内容、サマリまでが簡潔にまとめられていることがわかります。コードの質に関しては、今回はそこまで複雑なアプリではないこともあり、特に気になる点はなかったと感じますが、ぜひ皆さんの使用時に確認していただければと思います。 CI/CDへの組み込み AWS Security Agent は、CodePipeline 等の CI/CD や定期的な管理タスクとして実行させることが可能で、 AWS CLI / API 経由でジョブを起動できます。 今回は、GitHub Actions での使用イメージを記載します。以下は、デザインレビュー・コードレビュー・ペネトレーションテストを、大まかに GitHub Actions に組み込んだ場合のイメージです。 タイミング 実行するもの 性質 develop マージ リポジトリ全体のコードレビュー 軽量・低コスト・高頻度 main マージ stg へ反映（テストは伴わないデプロイトリガー） — stg デプロイ完了後 軽量ペンテスト（対象を絞る） 中コスト・中頻度 リリース時 / 定期 フルスコープのペンテスト 高コスト・低頻度 設計ドキュメント更新時 デザインレビュー 随時 CLIコマンドの基本構造 AWS Security Agent の各機能は、以下の流れで実行します。AWS Security Agent 関連リソースはあらかじめコンソールまたは create コマンドで定義しておき、CI/CD からは名前を基に list-* コマンドでIDを取得し start-*-job で起動するのが基本です。 機能 起動コマンド 主な必須引数 コードレビュー aws securityagent start-code-review-job --agent-space-id / --code-review-id ペネトレーションテスト aws securityagent start-pentest-job --agent-space-id / --pentest-id デザインレビュー（脅威モデリング） aws securityagent start-threat-model-job --agent-space-id / --threat-model-id 例えばペネトレーションテストの起動は、コンソールから設定した場合は名前を元に以下のようになります。Agent Space やペンテスト定義の実IDは list-* 系コマンドで name / title を条件に取得し、 start-pentest-job に渡します。 $ AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text \ --region ap-northeast-1) $ PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text \ --region ap-northeast-1) $ aws securityagent start-pentest-job \ --agent-space-id "$AGENT_SPACE_ID" \ --pentest-id "$PENTEST_ID" \ --region ap-northeast-1 start-pentest-job は pentestJobId と status （ IN_PROGRESS / COMPLETED / FAILED など）を返します。短時間で完了するコードレビューやデザインレビューは、この status をポーリングして完了を待つ構成にできます。一方、数時間〜数十時間かかるペネトレーションテストは、GitHub Actions の実行時間制限（後述）の都合から、起動のみ行う非同期キック構成とします。 以下では、各フェーズで実行する workflow の YAML ファイル例を示します。なお、いずれの例も Agent Space 名や各リソース名（ title ）、AWS 認証情報（OIDC ロール等）を GitHub の Secrets / Variables に登録している前提です。リソース ID は workflow 内で list-* から動的に解決するため、ID 自体は Variables に持ちません（コンソール側で再作成された場合の追従が楽になります）。 共通： AWS 認証（OIDC） 各 workflow で共通して使う、OIDC による AWS 認証部分の例です。長期のアクセスキーを GitHub に保存せず、フェデレーションでロールを引き受ける構成にしています。 permissions : id-token : write contents : read steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ap-northeast-1 develop マージ時： コードレビュー develop への push（マージ）をトリガーに、リポジトリ全体のコードレビューを起動します。高頻度で回すため、軽量・低コストなレビューを想定しています。 # .github/workflows/code-review.yml name : security-agent-code-review on : push : branches : [ develop ] permissions : id-token : write contents : read jobs : code-review : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} CODE_REVIEW_NAME : ${{ vars.CODE_REVIEW_NAME }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) CODE_REVIEW_ID=$(aws securityagent list-code-reviews \ --agent-space-id "$AGENT_SPACE_ID" \ --query "codeReviewSummaries[?title=='$CODE_REVIEW_NAME'].codeReviewId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$CODE_REVIEW_ID" ] || [ "$CODE_REVIEW_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID CODE_REVIEW_ID=$CODE_REVIEW_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "code_review_id=$CODE_REVIEW_ID" >> "$GITHUB_OUTPUT" - name : Start code review job id : start run : | JOB_ID=$(aws securityagent start-code-review-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --code-review-id "${{ steps.resolve.outputs.code_review_id }}" \ --query 'codeReviewJobId' --output text) echo "job_id=$JOB_ID" >> "$GITHUB_OUTPUT" echo "Started code review job: $JOB_ID" - name : Wait for completion run : | JOB_ID="${{ steps.start.outputs.job_id }} " AGENT_SPACE_ID=" ${{ steps.resolve.outputs.agent_space_id }} " for i in $(seq 1 60); do STATUS=$(aws securityagent batch-get-code-review-jobs \ --agent-space-id "$AGENT_SPACE_ID" \ --code-review-job-ids "$JOB_ID" \ --query 'codeReviewJobs[0].status' --output text) echo "status=$STATUS" case "$STATUS" in COMPLETED) echo "Code review completed" ; exit 0 ;; FAILED|STOPPED) echo "Code review did not succeed: $STATUS" ; exit 1 ;; esac sleep 30 done echo "Timed out waiting for code review" ; exit 1 stg デプロイ完了後： 軽量ペンテスト（DAST・対象を絞る） main マージ後の stg デプロイ完了を受けて、対象を絞った軽量なペネトレーションテストを実行します。 ペネトレーションテストは数時間〜数十時間かかる場合があり、GitHub ホストランナーの 1 ジョブ最大 6 時間という実行時間制限を超える恐れがあります。そのため、ここでは 起動のみを行い、完了は待たない（非同期キック） 構成とします。テストの進捗・結果は、コンソールや EventBridge 通知などジョブの外で確認する想定です。 # .github/workflows/pentest-light.yml name : security-agent-pentest-light on : workflow_run : workflows : [ "deploy-stg" ] # stg デプロイ workflow 名 types : [ completed ] permissions : id-token : write contents : read jobs : pentest-light : # デプロイが成功したときだけ実行 if : ${{ github.event.workflow_run.conclusion == 'success' }} runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} PENTEST_NAME : ${{ vars.PENTEST_NAME_LIGHT }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$PENTEST_ID" ] || [ "$PENTEST_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID PENTEST_ID=$PENTEST_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "pentest_id=$PENTEST_ID" >> "$GITHUB_OUTPUT" - name : Start light pentest job (fire-and-forget) run : | JOB_ID=$(aws securityagent start-pentest-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --pentest-id "${{ steps.resolve.outputs.pentest_id }}" \ --query 'pentestJobId' --output text) echo "Started light pentest job: $JOB_ID" echo "進捗・結果はコンソールまたは EventBridge 通知で確認してください。" リリース時 / 定期： フルスコープのペネトレーションテスト リリースタグの push、または定期実行でフルスコープのペネトレーションテストを起動します。高コスト・低頻度の枠です。 ペネトレーションテストは数時間〜数十時間かかる場合があり、GitHub ホストランナーの 1 ジョブ最大 6 時間という実行時間制限を超える恐れがあります。そのため、ここでは 起動のみを行い、完了は待たない（非同期キック） 構成とします。テストの進捗・結果は、コンソールや EventBridge 通知などジョブの外で確認する想定です。 # .github/workflows/pentest-full.yml name : security-agent-pentest-full on : push : tags : [ "v*" ] # リリースタグ schedule : - cron : "0 18 * * 0" # 毎週日曜 18:00 UTC（=月曜 3:00 JST）に定期実行 permissions : id-token : write contents : read jobs : pentest-full : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} PENTEST_NAME : ${{ vars.PENTEST_NAME_FULL }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$PENTEST_ID" ] || [ "$PENTEST_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID PENTEST_ID=$PENTEST_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "pentest_id=$PENTEST_ID" >> "$GITHUB_OUTPUT" - name : Start full pentest job (fire-and-forget) run : | JOB_ID=$(aws securityagent start-pentest-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --pentest-id "${{ steps.resolve.outputs.pentest_id }}" \ --query 'pentestJobId' --output text) echo "Started full pentest job: $JOB_ID" echo "長時間ジョブのため、結果はコンソールまたは EventBridge 通知で確認してください。" 設計ドキュメント更新時： デザインレビュー（脅威モデリング） 設計ドキュメント（ docs/design/ 配下など）の更新をトリガーに、デザインレビュー（脅威モデリング）を起動します。STRIDE 形式での脅威モデル生成を想定しています。 # .github/workflows/design-review.yml name : security-agent-design-review on : push : paths : - "docs/design/**" # 設計ドキュメントの更新時のみ permissions : id-token : write contents : read jobs : design-review : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} THREAT_MODEL_NAME : ${{ vars.THREAT_MODEL_NAME }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) THREAT_MODEL_ID=$(aws securityagent list-threat-models \ --agent-space-id "$AGENT_SPACE_ID" \ --query "threatModelSummaries[?title=='$THREAT_MODEL_NAME'].threatModelId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$THREAT_MODEL_ID" ] || [ "$THREAT_MODEL_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID THREAT_MODEL_ID=$THREAT_MODEL_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "threat_model_id=$THREAT_MODEL_ID" >> "$GITHUB_OUTPUT" - name : Start threat model job id : start run : | JOB_ID=$(aws securityagent start-threat-model-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --threat-model-id "${{ steps.resolve.outputs.threat_model_id }}" \ --query 'threatModelJobId' --output text) echo "job_id=$JOB_ID" >> "$GITHUB_OUTPUT" - name : Wait for completion run : | JOB_ID="${{ steps.start.outputs.job_id }} " AGENT_SPACE_ID=" ${{ steps.resolve.outputs.agent_space_id }} " for i in $(seq 1 60); do STATUS=$(aws securityagent batch-get-threat-model-jobs \ --agent-space-id "$AGENT_SPACE_ID" \ --threat-model-job-ids "$JOB_ID" \ --query 'threatModelJobs[0].status' --output text) echo "status=$STATUS" case "$STATUS" in COMPLETED) exit 0 ;; FAILED|STOPPED) echo "Threat model did not succeed: $STATUS" ; exit 1 ;; esac sleep 30 done echo "Timed out" ; exit 1 まとめ 最近よく話題に挙がるDevOpsにセキュリティを加えた概念、 DevSecOps に沿ったモダンなサービスだと感じました。 今回のAWS Security Agentでは、 コンソール操作だけでなくAPI経由でCICDに取り込める点 、 レビューから修正までをAIで一括管理できる点 、さらに コードレビューやペネトレーションテストにおいて差分レビューやターゲットURL・除外項目の設定などでスコープを調整できる点 から、このDevSecOpsのコンセプトを強く反映しています。 また、単なる効率化にとどまらず、ドキュメントとして人向けに残す成果物まで整備されている点も充実しています。 一方で、懸念点としては以下の3点が挙げられます。 コスト ：プレビュー中の機能もありますが、実際にCI/CDへ組み込んだ際の料金イメージが読みにくい点。エージェントを個別に構築する場合と比較した、運用コスト・性能とのバランス。 秘匿ドキュメントの管理 ：社内の機密情報や個人情報を含むドキュメントをクラウド上にアップロードすることになるため、要件によっては慎重な判断が必要。 データは既定でAWSマネージドキーにより暗号化され、任意でカスタマーマネージドキー（CMK）を指定して自社で鍵を管理することも可能であり、保護の仕組みは用意されている。そのため、最終的には自社のセキュリティ要件に照らして判断することになる想定。 レビューやテストの性能 ：現在の検出性能や今後の伸びしろについて、セキュリティエンジニアの視点でのご意見をぜひお聞きしたいと感じています。 おわりに 本記事では、AWS Security Agentの概要を紹介しました。今後も、機能の追加や検出性能そのもののアップグレードが期待されます。 ただし、偽陽性が多いのではないかという声も聞いたため、検出性能については別途、評価・比較してみたいと考えています。 ご精読いただき、ありがとうございました。 余談になりますが、先輩と話した際に挙がった、「ペネトレーションテストを主軸に開発を進める中で、アプリケーションのコンテキストを理解させるために、結局は設計レビュー・コードレビュー・脅威モデリングが必要になり、機能として統合されていったのではないか」という見方には、かなり納得できました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sakae.katsuto レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

システム開発のPMOを任されたものの、何をどこまで担当すればよいのかわからず、不安を感じるケースは少なくありません。 進捗表の更新や会議資料の作成に追われるうちに、 PMOとして本当に価値のある仕事ができているのか と疑問を抱くこともあります。 一方、PMOの導入を検討する立場では、どのようなプロジェクトに必要なのか、社内人材で運用できるのか、外部へ依頼すべきなのかを判断しなければなりません。 PMOは単なる事務局ではなく、進捗・課題・リスク・品質・コストなどの情報を整理し、PMや関係者が適切に判断できる状態を作る役割です。 役割と権限を正しく設計できれば、問題の早期発見、意思決定の迅速化、管理業務の標準化につながります。 そこで今回は、 システム開発におけるPMOの役割から具体的な業務、導入・運用の進め方まで を実務の流れに沿って整理しました！ PMOを初めて担当する場合にも、管理体制を見直したい場合にも役立つ内容です。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼システム開発の流れに関する記事はこちら▼ システム開発の全体像をわかりやすく解説！工程と役割を入門ガイド システム開発のPMOとは？PMとの違いから役割をつかもう！ システム開発では、顧客、利用部門、開発会社、協力会社など、多くの関係者が同時に動きます。 規模や関係者が増えるほど、PMだけで進捗、品質、費用、課題、リスクを把握することは難しくなります。 PMOは、このような複雑なプロジェクトで情報を集約し、管理方法を整え、 PMが正しい判断を下せる環境を作る組織または機能 です。 担当業務はプロジェクトによって異なりますが、進捗管理、課題管理、会議運営、報告資料の作成、ルールの標準化などが中心です。 まずはPMやPLとの違い、支援範囲、導入が必要になる状況を理解し、PMOに期待される役割を明確にする必要があります。 PMOはプロジェクトを成功しやすい状態に整える支援役です！ PMOは「プロジェクト・マネジメント・オフィス」を意味し、組織内のプロジェクト管理を横断的に支援する役割です。 個別の作業を直接完了させることよりも、プロジェクトの状況を正しく把握できる仕組みを作り、関係者の判断と行動を支えることが中心になります。 たとえば、チームごとに異なる進捗報告を同じ基準へそろえれば、遅れている領域や対応が必要な課題を比較しやすくなります。 課題の担当者、期限、影響範囲を明確にすれば、問題が会議で報告されるだけで放置される事態も防ぎやすくなります。 また、PMOには、管理方法の標準化、人材育成、プロジェクト間のリソース調整、ナレッジの蓄積といった組織横断的な役割もあります。 つまり、PMOの価値は資料の作成量ではなく、 問題を早く見つけ、必要な判断を促し、プロジェクトを前へ進めること にあります。 PM・PL・PMOの違いを整理して責任の重複を防ごう！ PMはプロジェクト全体の責任者として、目標、予算、納期、品質、体制などを管理し、重要事項を最終的に判断します。 PLは担当するチームや開発領域をまとめ、設計、開発、テストなどの実作業を計画どおりに進める役割です。 これに対してPMOは、PMやPLから情報を集め、状況を整理し、問題の兆候や判断が必要な事項を明らかにします。 端的に整理すると、 PMは決定してプロジェクトを動かす役割、PMOはPMが判断できる状態を整える役割 です。 ただし、実際の現場では境界が曖昧になり、PMOがPMの代わりに判断したり、反対に資料作成しか任されなかったりすることがあります。 体制を作る際は、誰が決めるのか、誰が管理するのか、誰が実行するのかを役割分担表などで明文化し、責任の重複と空白を防ぐことが重要です。 PMO・プログラム管理・全社PMOは支援する範囲で使い分けよう！ PMOという言葉は、支援する対象や範囲によって異なる意味で使われることがあります。 個別プロジェクトを支援するPMOは、進捗や課題を管理し、PMの意思決定を支えることが主な役割です。 複数の関連プロジェクトをまとめるプログラム管理では、案件間の依存関係、共通目標、リソース競合などを横断的に調整します。 全社PMOは、組織全体のプロジェクトを俯瞰し、経営戦略との整合性、投資の優先順位、人材や予算の配分を支援します。 大切なのは名称を先に決めることではなく、 どの範囲で何を改善する必要があるのか を明らかにすることです。 最初から全社的な組織を立ち上げる必要はなく、重要プロジェクトの課題管理や報告標準化から始め、効果を確認しながら対象を広げる方法も有効です。 PMOが必要かどうかは人数より管理の難しさで判断しよう！ PMOの必要性は、プロジェクトの参加人数だけでは判断できません。 少人数でも複数のベンダーが関与し、仕様変更が多く、利用部門との調整が複雑であれば、管理の負荷は高くなります。 反対に、人数が多くても役割や管理方法が確立され、PMが無理なく全体を把握できている場合は、大規模なPMOを設ける必要がないこともあります。 導入を検討する目安は、PMが資料作成や会議調整に追われている、報告方法がチームごとに違う、課題の担当者や期限が曖昧といった状態です。 複数案件で同じ人材を取り合っている場合や、経営層に進捗・費用・品質を一貫した形で説明できない場合も、PMOが機能しやすい状況です。 関係者数、変更頻度、技術的な難しさ、組織横断性、PMの管理負荷 を確認し、必要な機能から導入することが大切です。 PMOの具体的な業務を理解して、優先順位を決めよう！ PMOの業務範囲は広いため、最初からすべてを担当しようとすると、管理作業そのものが目的になりやすくなります。 まず取り組むべきなのは、プロジェクトの現状と重要な問題を正しく把握できる状態を作ることです。 進捗、課題、リスク、品質、コスト、変更要求などを整理し、PMや経営層が必要なタイミングで判断できるようにします。 そのうえで、会議や報告の方法、管理表の書式、情報の保存場所などを整え、担当者ごとの差を減らしていきます。 PMOの業務は、情報を集めるだけでは完了しません。 集めた情報を判断と行動につなげること までを一連の仕事として設計する必要があります。 まずは進捗・課題・リスクを見える化しよう！ 進捗管理では、計画に対する実績を確認するだけでなく、今後遅れる可能性のある作業を見つけることが重要です。 単に進捗率を集計するのではなく、遅延理由、後続工程への影響、回復策、判断が必要な事項まで整理します。 課題管理では、課題の内容、重要度、影響範囲、担当者、期限、対応状況を明確にし、更新されないまま放置されることを防ぎます。 リスク管理では、まだ発生していない問題について、発生確率と影響度を評価し、予防策や発生時の対応を決めておきます。 課題とリスクを同じものとして扱うと、すでに対応が必要な問題と将来への備えが混在するため、管理上の区分も必要です。 報告時は数値を並べるだけでなく、 何が起きており、どのような影響があり、何を決める必要があるのか まで示すことで、PMの意思決定を支援できます。 会議と報告を判断が進む場に変えよう！ 会議が増えても、課題や意思決定が前へ進むとは限りません。 まず会議の目的を情報共有、状況確認、課題解決、意思決定などに分け、参加者と議題を必要最小限にします。 開催前には、確認したい事項、決めたい事項、判断に必要な資料を共有し、参加者が準備できる状態を作ります。 会議中は議事録を詳細に残すことよりも、決定事項、未決事項、担当者、期限、次の確認日を明確にすることが重要です。 報告資料も情報量の多さを競うのではなく、正常に進んでいるのか、問題は何か、どの判断を求めているのかが短時間で伝わる構成にします。 現場、PM、経営層では必要な情報の粒度が異なるため、 相手の役割と判断内容に合わせて報告を変えること が、会議の短縮と意思決定の迅速化につながります。 管理ルールと書式をそろえて属人化を減らそう！ 管理方法が担当者ごとに異なると、同じ「進捗率八〇％」でも意味が変わり、正確な比較ができません。 最初に、着手、進行中、完了の条件や、課題とリスクの違い、重要度の判断基準などを定義します。 次に、進捗報告書、課題管理表、リスク管理表、変更管理表など、必要な書式と記載項目をそろえます。 ただし、書式を増やしすぎると、同じ情報を複数のファイルへ入力する二重管理が発生します。 情報の保存場所、更新担当者、更新頻度、承認方法を決め、どこを見れば最新情報がわかるのかを明確にすることも必要です。 標準化の目的は現場を規則で縛ることではなく、 誰が担当しても同じ基準で状況を把握できる状態を作ること です。 運用開始後も使いにくい項目や重複作業を見直し、実態に合わせて簡素化します。 品質・コスト・変更要求を横断して管理しよう！ システム開発では、品質、コスト、納期を個別に管理するだけでは不十分です。 納期を優先してテスト期間を短縮すれば、品質低下や本番稼働後の障害につながる可能性があります。 品質管理では、テストの進捗、不具合件数、重要度、修正状況、再発傾向などを確認し、問題の兆候を早期に捉えます。 コスト管理では、予算と現在までの実績だけでなく、残作業を含めた完了時点の費用見込みも確認します。 仕様変更については、目的、影響範囲、必要な工数、追加費用、納期への影響を整理し、承認前に関係者へ提示することが大切です。 口頭の依頼だけで開発を進めると、費用や納期の認識がずれやすいため、受付、影響分析、承認、反映確認までの流れを定めます。 品質・コスト・納期のトレードオフを見える形にすること が、PMOによる重要な判断支援です。 部門やベンダーの壁を越えて認識をそろえよう！ 発注側、利用部門、開発会社、協力会社では、重視する成果や評価基準が異なります。 利用部門は業務上の使いやすさを重視し、開発側は技術的な実現性や作業工数を重視するなど、同じ仕様でも見方が変わります。 PMOは、それぞれの主張をそのまま並べるのではなく、共通するプロジェクト目標と客観的な事実に整理します。 用語、前提条件、成果物、完了基準を共通化し、認識の違いによる手戻りを防ぐことも重要です。 また、作業担当者だけでなく、承認者、説明責任者、相談先を明確にし、問題発生時に責任の押し付け合いが起きないようにします。 外部ベンダーへ管理を任せきりにせず、発注側も判断に必要な情報と経緯を保持する必要があります。 PMOは監視役として現場を追及するのではなく、 悪い情報ほど早く共有できる関係を作る調整役 として機能することが大切です。 PMOを正しく導入・運用してプロジェクトを安定させよう！ PMOを設置するだけで、プロジェクトが自動的に改善するわけではありません。 導入目的が曖昧なまま管理表や会議を増やすと、現場の負担が大きくなり、PMOへの反発が生まれます。 最初に解決したい課題を定め、その課題に必要な役割、権限、情報、体制を設計することが必要です。 社内人材で運用するのか、外部の専門人材を活用するのかも、経験、立ち上げ期間、継続性を踏まえて判断します。 運用開始後は、小さな範囲で効果を確認し、不要な管理を減らしながら支援範囲を広げます。 PMOの成功には、仕組みだけでなく、 現場との信頼関係、状況を読み解く力、判断を促す伝え方 も欠かせません。 導入目的と支援範囲を決めてから体制を作ろう！ PMOを導入する際は、最初に「何のために設置するのか」を具体的にします。 遅延を減らす、PMの負担を軽くする、品質問題を早期に発見する、複数案件の状況を統一して把握するなど、解決したい課題を明文化します。 目的が決まったら、進捗管理、課題管理、品質管理、会議運営、経営報告など、PMOが担当する範囲を選びます。 同時に、PM、PMO、PL、開発メンバー、経営層の権限と責任を定め、誰が最終判断を下すのかを明確にします。 収集する情報、報告先、報告頻度、緊急時の連絡条件も事前に決めておくと、運用開始後の混乱を減らせます。 成果は会議数や資料数ではなく、課題の早期発見、判断時間の短縮、遅延件数の改善などで測ります。 PMOが解決する課題と生み出す価値を現場へ説明すること が、監視部門という誤解を防ぐポイントです。 社内運用か外部支援かをプロジェクトの状況で選ぼう！ 社内PMOは、自社の業務、組織文化、意思決定の流れ、関係者の特徴を理解している点が強みです。 プロジェクト終了後もノウハウを残しやすく、継続的な改善や人材育成にもつなげられます。 一方、PMO経験を持つ人材が少ない場合や、既存の部門関係によって客観的な指摘が難しい場合は、立ち上げに時間がかかります。 外部PMOは、他社や複数案件で得た知識を活用し、短期間で管理体制を整えやすい点がメリットです。 ただし、委託範囲、成果物、権限、機密情報の取り扱い、契約終了後の引き継ぎを曖昧にすると、外部人材への依存が残ります。 立ち上げ段階だけ外部支援を活用し、運用が安定した後に社内へ移管する方法もあります。 支援会社を選ぶ際は、PMOの実績だけでなく、 対象業界、開発工程、技術への理解、現場との調整力、内製化支援の方針 まで確認することが重要です。 小さく始めて効果を確かめながら広げよう！ PMOの導入時に、すべての管理領域を一度に標準化すると、現場の負担が急増します。 最初は、課題が放置されている、会議で何も決まらない、進捗報告を比較できないなど、影響の大きい問題を一つ選びます。 特定のプロジェクトやチームで試行し、必要な管理項目、更新頻度、会議方法を検証します。 導入前後で、期限を超過した課題数、意思決定までの日数、報告資料の作成時間などを比較すると、効果を判断しやすくなります。 使われない資料や成果につながらない会議は廃止し、現場の作業量と管理効果のバランスを調整します。 運用が定着した方法だけをほかのチームへ展開すれば、混乱を抑えながら組織全体の管理力を高められます。 小さく試し、効果を測り、改善してから広げること が、形骸化しにくいPMOを作る基本です。 PMOに必要なスキルを実務の中で伸ばそう！ PMOには、進捗、課題、リスク、品質、コスト、変更要求などを管理する基礎知識が必要です。 ただし、管理手法を知っているだけでは、現場から正確な情報を集め、関係者を動かすことはできません。 相手の状況を聞き出すコミュニケーション力、立場の異なる部門を調整する交渉力、問題の原因と影響を整理する分析力が求められます。 PMや経営層が短時間で判断できるよう、複雑な情報を要点にまとめる文書作成力や説明力も重要です。 さらに、開発工程やシステムの特徴を理解していなければ、現場の実態と合わない管理ルールを作る可能性があります。 資格取得は知識を体系的に学ぶ手段になりますが、資格だけでPMO業務を遂行できるわけではありません。 小さな管理改善を実践し、結果を振り返る経験 を重ねることで、判断力と支援力を伸ばせます。 管理するだけのPMOにならないための失敗対策を押さえよう！ PMOで起こりやすい失敗は、管理表、報告資料、会議を増やすこと自体が目的になることです。 現場の負担が増えても、意思決定や課題解決が速くならなければ、PMOは不要な管理部門と受け取られます。 細かなルールの遵守だけを求めると、メンバーは問題を隠したり、形式上の報告だけを整えたりするようになります。 また、PMOがPMの代わりに判断を始めると責任範囲が曖昧になり、反対に権限がまったくなければ事務作業しかできません。 PMがPMOへ判断を任せきりにする状態や、PMとPMOが対立して決定が遅れる状態も避ける必要があります。 PMOの成果は、資料や会議の数ではなく、問題を早期に発見できたか、判断が速くなったか、PMと現場の負担が減ったかで評価します。 管理のための管理を減らし、プロジェクトの成果につながる活動へ集中すること が重要です。 まとめ｜PMOの役割を明確にして、失敗を防げる開発体制を作ろう！ PMOは、進捗表を更新したり会議資料を作ったりするだけの事務局ではありません。 プロジェクトの情報を整理し、問題の兆候を早期に捉え、PMや関係者が判断しやすい状態を作る役割です。 PMが最終的な意思決定を担い、PMOが情報整理と判断支援を担うなど、役割と責任を明確にすると、業務の重複や責任の空白を防げます。 実務では、進捗、課題、リスク、品質、コスト、変更要求を共通の基準で見える化し、必要な判断と対応につなげます。 導入時は、解決したい課題と支援範囲を決め、現場の負担を確認しながら小さく始めることが大切です。 まずは、担当するプロジェクトで最も混乱している管理業務を一つ選び、 担当者、期限、報告方法、判断者 を整理することから始められます。 PMOを監視役ではなく、PMと開発メンバーが本来の業務に集中できる環境を作る支援役として運用することで、安定したプロジェクト推進につながります。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

本文は 2026年6月26日 に公開された AWS Cloud WAN Routing Policy: Real-World Global Network Scenarios (Part 2) を翻訳したものです。 Part 1 では、 AWS Cloud WAN のルーティングポリシーを紹介し、グローバルネットワーク全体でルート伝播とパス選択に影響を与えるためのきめ細かな制御をどのように使用できるかを示しました。各ルーティングポリシーは、3つの主要コンポーネントで構成されます。1) マッチ条件：ルートプレフィックスまたは BGP 属性を評価します。2) アクション：マッチしたルートの処理方法を決定します。3) 方向性：ポリシーをインバウンドとアウトバウンドのどちらのルート伝播に適用するかを指定します。これらの構成要素は、アタッチメント、セグメント、またはリージョンのレベルで適用できます。 本記事では、これらの概念を踏まえ、ハイブリッド環境やマルチサイト環境で一般的に見られる3つの実運用シナリオを取り上げます。AWS Cloud WAN のルーティングポリシーを使用して、 AWS Transit Gateway 環境からの移行中にルーティングを制御する方法、ローカルプリファレンスを使用して複数の AWS Direct Connect ロケーション間のパス選択を改善する方法、そして同一の BGP 自律システム番号（ASN）を持つネットワーク間の接続を許可する方法を学びます。 これらのパターンは、AWS Cloud WAN を集中型のポリシー適用ポイントとして使用し、グローバルネットワーク全体のルーティング制御を簡素化する方法を示しています。 本記事で説明するシナリオは、網羅的なリストではありません。AWS Cloud WAN のルーティングポリシーは、ここで扱う以外にも追加のマッチ条件とアクションをサポートしているため、お客様の環境固有のルーティング課題に対応できます。利用可能なマッチ条件とアクションの完全なリストについては、 AWS Cloud WAN ルーティングポリシーのドキュメント を参照してください。 前提条件 本記事は、2部構成のシリーズの第2回です。マッチ条件、アクション、方向性、基本的な設定ワークフローなど、ルーティングポリシーの基礎を扱った Part 1: AWS Cloud WAN Routing Policy — Fine-grained controls for your global network を既に読まれていることを前提とします。また、 Amazon Virtual Private Cloud（Amazon VPC） 、AWS Cloud WAN、AWS Direct Connect、 AWS Site-to-Site VPN などの主要な AWS ネットワークサービス、および AS-path、ローカルプリファレンス、コミュニティ属性といった概念を含む Border Gateway Protocol（BGP） の基礎を理解していることを前提とします。AWS Cloud WAN のハイブリッド接続パターンに関する補足的な背景情報については、 Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration を参照することを推奨します。 補足：AWS Cloud WAN のルーティングポリシーには、コアネットワークポリシーバージョン 2025.11 以降が必要です。本記事で説明する設定を実装する前に、コアネットワークがこのバージョンで動作していることを確認してください。 シナリオ1：既存の Transit Gateway 環境からのルート伝播の制御 AWS Cloud WAN を採用する場合、既に AWS Transit Gateway 上に構築された既存環境を運用しているかもしれません。移行中は、これらの環境を AWS Cloud WAN に接続することで、一度きりのカットオーバーではなく、段階的な移行が可能になります。 こうしたアーキテクチャでよくある要件は、AWS Cloud WAN が Transit Gateway から学習したルートを、ネットワークの他の部分、特に AWS Direct Connect や AWS Site-to-Site VPN を通じて接続されたオンプレミス環境にどのように伝播するかを制御することです。 次の図（図1）は、ルーティングポリシーが適用されていない場合に、AWS Cloud WAN 内でルートがどのように学習され、伝播されるかを示しています。この例では、ap-southeast-2 リージョンの Transit Gateway が、AWS Direct Connect を通じてオンプレミスのデータセンター（DC1）に接続されています。この Transit Gateway が AWS Cloud WAN にアタッチされると、DC1 は重複したルートを受信し始めます。1つ目のルートセットは、Transit Gateway から直接伝播されます。2つ目のセットは AWS Cloud WAN 自体から来るもので、AWS Cloud WAN は Transit Gateway ルートテーブルのアタッチメントから同じルートを学習し、それらを Direct Connect 経由で DC1 に再配布します。ルーティングポリシーがない場合、このルートの重複は、非効率的または予測不可能なルーティング動作につながる可能性があります。 図1：ルーティングポリシーがない場合のルート伝播動作 AWS Cloud WAN のルーティングポリシーは、BGP コミュニティのタグ付けとフィルタリングによってこの問題を解決し、どのルートをオンプレミス環境にアドバタイズするかを正確に制御できるようにします。 図2：ルーティングポリシー適用後のルート伝播動作 図2に示すように、Transit Gateway は自身の production ルートテーブルを AWS Cloud WAN の production セグメントに接続します。ルーティングポリシーは2つのステップで動作します。第1に、Transit Gateway ルートテーブルのアタッチメントから学習したルートに、BGP コミュニティ値（65000:1 など）をタグ付けします。第2に、このコミュニティタグを、production セグメントから hybrid セグメントへルートを共有する際のフィルタとして使用します。タグ付けされたルートは、hybrid セグメントの Direct Connect ゲートウェイ（DXGW）へはそれ以上アドバタイズ（伝播）されません。 その結果、オンプレミスのデータセンターは Transit Gateway から直接ルートのみを受信することになり、重複したアドバタイズが排除され、Transit Gateway が同じデータセンターに接続されたままのアーキテクチャにおけるルーティングの競合を回避できます。 補足：AWS Cloud WAN に直接アタッチされた新しい VPC は、Transit Gateway の背後にある既存の VPC が AWS Cloud WAN 上の VPC と通信できるように、自身の Classless Inter-Domain Routing（CIDR）ブロックを Transit Gateway にアドバタイズします。ただし、これらの CIDR ブロックは、その関連付けの 許可プレフィックスリスト に含まれていない限り、Transit Gateway の Direct Connect ゲートウェイの関連付けを通じてオンプレミスにはアドバタイズされません。これにより、Cloud WAN の VPC ルートが Transit Gateway パス経由で DC1 にアドバタイズされるのを防ぎ、AWS Cloud WAN の Direct Connect ゲートウェイをオンプレミスへの唯一のパスとして残します。 仕組み 既存の Transit Gateway から学習したルートは production セグメントに入り、アタッチメントのインバウンドポリシーによってコミュニティ 65000:1 でタグ付けされます。production の VPC と AWS Cloud WAN のリソースは、Transit Gateway のワークロードに通常どおり到達できます。一方、production のルートが hybrid セグメントと共有される際、アウトバウンドのセグメントフィルタリングポリシーがコミュニティタグ 65000:1 にマッチし、それらのルートをドロップします。その他すべての production ルート（VPC からのルート）は hybrid セグメントに通過し、Direct Connect 経由でオンプレミスにアドバタイズされます。これにより、同じ Transit Gateway に依然として直接接続されているデータセンターへの重複したルートアドバタイズを防ぎます。 ステップ1：Transit Gateway のルートにコミュニティをタグ付けする（Transit Gateway ルートテーブルアタッチメントでインバウンド） このインバウンドポリシーを、AWS Cloud WAN の Transit Gateway ルートテーブルアタッチメントに適用します。このポリシーは、Transit Gateway から学習したすべてのルートにマッチし、コミュニティ 65000:1 でタグ付けします。 { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "tagTgwRoutes", "routing-policy-description": "Tag routes learned from existing TGW with community 65000:1", "routing-policy-direction": "inbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "prefix-in-cidr", "value": "0.0.0.0/0" } ], "condition-logic": "and", "action": { "type": "add-community", "value": "65000:1" } } } ] } ] } ステップ2：セグメント共有時にタグ付けされたルートをフィルタリングする（prod → hybrid） このアウトバウンドポリシーを、production セグメントから hybrid セグメントへルートを共有する際に適用します。このポリシーは、コミュニティ 65000:1 を持つルートにマッチしてドロップし、Transit Gateway 由来のルートが hybrid セグメントおよび Direct Connect 経由でオンプレミスの DC に伝播されるのを防ぎます。コミュニティ値 65000:1 にマッチしないルートは暗黙的に許可され、通常どおり伝播を続けます。AWS Cloud WAN のルーティングポリシールールはデフォルト許可（default-allow）を基本として動作し、ドロップルールによって明示的にマッチしたルートのみがフィルタリングされます。 { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "filterRoutesToHybrid", "routing-policy-description": "Drop TGW-originated routes (community 65000:1) when sharing prod to hybrid", "routing-policy-direction": "outbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "community-in-list", "value": "65000:1" } ], "condition-logic": "and", "action": { "type": "drop" } } } ] } ] } ステップ3：ポリシーを配布ポイントに関連付ける 3.1 ルーティングポリシーラベルを使用して、タグ付けポリシーを Transit Gateway ルートテーブルアタッチメントに適用します。 { "attachment-routing-policy-rules": [ { "rule-number": 100, "conditions": [ { "type": "routing-policy-label", "value": "TgwInbound" } ], "action": { "associate-routing-policies": [ "tagTgwRoutes" ] } } ] } 関連付けを完了するには、routing-policy-label を Transit Gateway ルートテーブルアタッチメントに割り当てます。これは、アタッチメントの作成時に routing-policy-label パラメータを使用するか、AWS Cloud WAN コンソールで既存のアタッチメントを編集することで実行できます。このシナリオでは、ラベル TgwInbound を Transit Gateway ルートテーブルアタッチメントに割り当てます。 3.2 セグメント共有のレベルでフィルタリングポリシーを適用します。 { "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "production", "share-with": [ "hybrid" ], "routing-policy-names": [ "filterRoutesToHybrid" ] } ] } シナリオ2：複数の Direct Connect ロケーション間でのパス選択の改善 複数のオンプレミスロケーションがある場合、耐障害性のために複数のサイトから同じプレフィックスをアドバタイズしていることが多いでしょう。これは可用性を向上させますが、AWS Cloud WAN が複数のロケーションから固有の優先度なしに同一のルートを受信するというルーティングの曖昧さを生み出します。追加の制御がなければ、トラフィックが適切に誘導されない場合に非効率的なルーティング決定につながる可能性があります。 ルーティングポリシーが適用されていない場合、AWS Cloud WAN はデフォルトのルーティング動作（ロンゲストプレフィックスマッチ）に依存し、ローカルプリファレンスやパスステアリングは行われません。図3に示すように、AWS Cloud WAN が同じプレフィックス（例えば DC2 から発信される 10.2.0.0/16）を3つの DXGW とサイトすべてから同時に学習する場合、DC2 を通る直接パスを優先するメカニズムがありません。その結果、DC2 宛てのトラフィックが代わりに DC1 や DC3 を経由して出ていくことがあり、不要なバックボーンの通過、レイテンシーの増加、コストの増加を招きます。 補足：このシナリオでは、オンプレミスのデータセンターが MPLS や AWS Direct Connect SiteLink などのバックボーンネットワークを通じて相互接続されており、フェイルオーバー時にサイト間でトラフィックを通過させられることを前提としています。 図3：ルーティングポリシーがない場合のルートパス選択 AWS Cloud WAN のルーティングポリシーは、ローカルプリファレンスなどの BGP 属性を使用して、パス選択を集中的に制御します。図4に示すように、各 DXGW アタッチメントに適用されたインバウンドルーティングポリシーがローカルプリファレンス値を割り当て、トラフィックを発信元のデータセンターへ誘導することで、最も直接的なパスが優先されるようにします。 図4：ルーティングポリシー適用後のルートパス選択 このシナリオでは、各データセンターが特定のプレフィックスのセットを保有しています。DC1 は 10.1.0.0/16 を、DC2 は 10.2.0.0/16 を、DC3 は 10.3.0.0/16 を発信します。耐障害性のため、3つの DC はいずれも、自身の Direct Connect ロケーションから3つすべてのプレフィックスをアドバタイズします。各 DC は専用の DXGW を通じて接続されており、DC1 は ASN 65010、DC2 は 65011、DC3 は 65012 を使用します。AWS Cloud WAN は3つの DXGW すべてから同じルートを学習し、ローカルプリファレンスを使用して各プレフィックスのトラフィックをその保有元 DC へ誘導します。他の DC は、セカンダリおよび第3（ターシャリ）のフェイルオーバーパスとして機能します。 AWS Cloud WAN の観点から見ると、このシナリオのパス優先度マトリックスは次のとおりです。 プレフィックス 1番目（ローカルプリファレンス 300） 2番目（LP 200） 3番目（LP 100） DC1: 10.1.0.0/16 DXGW 65010 DXGW 65011 DXGW 65012 DC2: 10.2.0.0/16 DXGW 65011 DXGW 65012 DXGW 65010 DC3: 10.3.0.0/16 DXGW 65012 DXGW 65011 DXGW 65010 仕組み 3つの DC はいずれも耐障害性のために3つすべてのプレフィックスをアドバタイズしますが、各プレフィックスは特定の DC に属します。AWS Cloud WAN が 10.1.0.0/16 を3つの DXGW すべてから学習すると、ルーティングポリシーは、DXGW 65010（保有元である DC1）から 300、DXGW 65011（DC2）から 200、DXGW 65012（DC3）から 100 のローカルプリファレンスを割り当てます。AWS Cloud WAN は最も高いローカルプリファレンスを持つパスを選択し、10.1.0.0/16 のトラフィックを DC1 経由で誘導します。DC1 の Direct Connect パスに障害が発生した場合、トラフィックは自動的に DC2（ローカルプリファレンス 200）、次いで DC3（ローカルプリファレンス 100）へフォールバックします。同じロジックが、DC2 保有のプレフィックス（プライマリは DXGW 65011、セカンダリは 65012、第3経路は 65010 経由）および DC3 保有のプレフィックス（プライマリは DXGW 65012、セカンダリは 65011、第3経路は 65010 経由）にも適用されます。 DXGW のレベルでは、VIF 上の BGP コミュニティ を通じて、追加のパス制御レイヤーが利用できます。各 DXGW にはプライマリとセカンダリの2つの VIF があり、コミュニティタグによってアウトバウンドトラフィックにどちらの VIF が優先されるかが決まります。高優先度には 7224:7300、低優先度には 7224:7100 を使用します。あるいは、アクティブ・アクティブの ECMP ロードバランシングのために、両方の VIF に 7224:7200 を適用することもできます。 この設定により、AWS Cloud WAN と DXGW は、インバウンドのルート優先設定を使用してアウトバウンドトラフィックをオンプレミスへ誘導します。対称ルーティングを実現するには、オンプレミスから AWS へ流れるトラフィックについても、オンプレミスのデバイスが同じパスを優先するように設定する必要があります。 補足：定義された3つのプレフィックスリストのいずれにもマッチしないプレフィックスは、明示的なローカルプリファレンスが設定されないまま通過し、3つの DXGW すべてにわたって非決定的なパス選択となります。オンプレミスから新しいプレフィックスがアドバタイズされるのに合わせて、プレフィックスリストを最新の状態に保つようにしてください。 ステップ1：各データセンター用のプレフィックスリストを定義する データセンターごとに個別のプレフィックスリストを作成し、そのサイトから発信される CIDR をグループ化します。プレフィックスリストは Amazon VPC マネージドプレフィックスリスト（カスタマーマネージドプレフィックスリスト）として作成され、その後プレフィックスリストエイリアスを使用してコアネットワークに関連付けられます。ルーティングポリシーがプレフィックスをマッチする際に参照するのは、このエイリアスです。例えば、10.1.0.0/16、10.2.0.0/16、10.3.0.0/16 をそれぞれ含む3つの マネージドプレフィックスリスト を作成し、エイリアス dc1Prefixes、dc2Prefixes、dc3Prefixes を使用してコアネットワークに関連付けます。 補足：–max-entries パラメータは必須で、プレフィックスリストが保持できるエントリの最大数を定義します。ここで使用している値 5 は任意のものであり、含める予定のプレフィックス数に応じて調整できます。 aws ec2 create-managed-prefix-list --prefix-list-name dc1Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.1.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc2Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.2.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc3Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.3.0.0/16 aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc1-prefix-list-arn> --prefix-list-alias dc1Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc2-prefix-list-arn> --prefix-list-alias dc2Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc3-prefix-list-arn> --prefix-list-alias dc3Prefixes ステップ2：DXGW アタッチメントごとにルーティングポリシーを定義する 各 DXGW は、それぞれ独自のインバウンドルーティングポリシーを持ちます。このポリシーは、パス優先度マトリックスに基づいて各プレフィックスにローカルプリファレンス値を割り当て、各プレフィックスを発信元 DC へ、決定的なフェイルオーバー順序で誘導します。 DXGW 65010（DC1）のポリシー。DC1 のプライマリ、DC2 と DC3 の第3経路： { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "pathPreferenceDxgw65010", "routing-policy-description": "DXGW 65010 (DC1): primary for DC1, tertiary for DC2, tertiary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}} ] } ] } DXGW 65011（DC2）のポリシー。DC2 のプライマリ、DC1 と DC3 のセカンダリ： { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "pathPreferenceDxgw65011", "routing-policy-description": "DXGW 65011 (DC2): secondary for DC1, primary for DC2, secondary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}} ] } ] } DXGW 65012（DC3）のポリシー。DC3 のプライマリ、DC2 のセカンダリ、DC1 の第3経路： { "routing-policies": [ { "routing-policy-number": 300, "routing-policy-name": "pathPreferenceDxgw65012", "routing-policy-description": "DXGW 65012 (DC3): tertiary for DC1, secondary for DC2, primary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}} ] } ] } ステップ3：ポリシーを DXGW アタッチメントに関連付ける 各ルーティングポリシーを routing-policy-label にマッピングし、次にラベルによってアタッチメントをマッチし、対応するルーティングポリシーを関連付ける attachment-routing-policy-rules を定義します。routing-policy-label を各アタッチメントに割り当てます。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dxgw65010inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65010"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dxgw65011inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65011"]}}, {"rule-number": 300, "conditions": [{"type": "routing-policy-label", "value": "dxgw65012inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65012"]}} ] } 次に、routing-policy-label パラメータまたはコンソールを使用して、対応する routing-policy-label を各 DXGW アタッチメントに適用します。このシナリオでは、ラベル dxgw65010inbound を DXGW 65010 アタッチメントに、dxgw65011inbound を DXGW 65011 アタッチメントに、dxgw65012inbound を DXGW 65012 アタッチメントに割り当てます。 シナリオ3：同一 ASN を持つネットワーク間の通信の許可 Wide Area Network（WAN）を構築する企業は、グローバル接続のために AWS のバックボーンインフラストラクチャをますます活用していますが、買収、有機的な成長、または一般的なデフォルト ASN 値を使用したマルチサイト展開などにより、プライベート ASN の重複に直面することがよくあります。複数のサイトが同一の ASN を使用している場合、BGP のループ防止機能が、AS-path にそのサイト自身の ASN を含むルートを拒否し、WAN 全体のエンドツーエンドの通信を妨げます。 このシナリオでは、2つの ASN の競合がエンドツーエンドの通信を妨げています。図5に示すように、DC1 と DC2（A）はどちらも ASN 65000 を使用しています。AWS Cloud WAN がそれらの間でルートを伝播すると、各サイトは AS-path に自身の ASN を検出するため、相手のルートを拒否します。これが BGP のループ防止機能を引き起こします。 図5：DC1 と DC2 間で BGP ループ防止機能を引き起こす ASN の競合 2つ目の競合（B）は、図6に示すように、ASN 64512 を使用する DC3 が、ap-southeast-2 の AWS Cloud WAN コアネットワークエッジ（CNE）の ASN と競合するというものです。これにより、DC3 のルートは ap-southeast-2 の CNE によってドロップされ、DC3 もその CNE からのルートをドロップします。 図6：DC3 と AWS Cloud WAN CNE 間の ASN の競合によるルート伝播のブロック これら2つの競合が組み合わさることで、3つのデータセンターすべてにわたって到達性が完全に失われる結果となります。 AWS Cloud WAN のルーティングポリシーは、replace-asn-list アクションによってこの問題に対処します。このアクションは、AS-path 全体を指定した ASN のセットで置き換え、ループ防止機能を引き起こす競合を取り除き、オンプレミスの BGP の番号を振り直すことなく接続を復元します。 図7に示すように、3つのデータセンターは AWS Cloud WAN を中央のグローバルバックボーンとして使用します。DC1 は ap-southeast-2 リージョンの Direct Connect を通じて接続し、DC2 は us-west-2 リージョンの Site-to-Site VPN を通じて接続し、DC3 はメトロファイバー経由で DC2 を通じて AWS Cloud WAN に到達します。インバウンドルーティングポリシーは、2つのアタッチメントポイントに適用されます。(1) DC1 用の Direct Connect ゲートウェイアタッチメント、および (2) DC2 用の VPN アタッチメントです。DC3 のルートは DC2 の VPN アタッチメントを経由して通過するため、そのアタッチメントのインバウンドポリシーが DC2 と DC3 の両方の ASN 置換を処理します。 図7：3つのデータセンターすべての接続を復元する ASN 置換ルーティングポリシー 次の表は、ASN の置換をまとめたものです。 ソース 元の ASN 置換後の ASN 理由 DC1（Direct Connect） 65000 65550 DC2 でのループ検出を回避 DC2（Site-to-Site VPN） 65000 65551 DC1 でのループ検出を回避 DC3（DC2 のメトロファイバー経由） 64512 65552 ap-southeast-2 の CNE ASN との競合を回避 重要：AWS Cloud WAN のコアネットワークエッジ（CNE）は、インバウンドルーティングポリシーが評価される前に、BGP AS-path のループ検出を実行します。CNE が自身の ASN と一致する ASN を持つルートを受信した場合、replace-asn-list アクションが実行される前にそのルートをドロップします。トポロジーを計画する際は、オンプレミスのルートが、受信側の CNE の ASN と一致する ASN を持たないようにしてください。 仕組み このアプローチは、各サイトに固有で競合しない置換 ASN を割り当てることで、どのサイトも伝播されたルートの中に自身の ASN を見ることがなく、また、どのルートもトポロジー内の CNE と競合する ASN を持たないようにするものです。DC1 が AWS Cloud WAN にルートをアドバタイズすると、Direct Connect ゲートウェイアタッチメントのインバウンドポリシーが、AS-path 全体を ASN 65550 で置き換えます。これらのルートは AWS Cloud WAN を通じて伝播し、AS-path に 65000 ではなく 65550 を含んだ状態で DC2 に到達するため、DC2 のルーターはループ検出を引き起こすことなくそれらを受け入れます。 DC2 がルートをアドバタイズすると、VPN アタッチメントのインバウンドポリシーが AS-path 全体を ASN 65551 で置き換えます。これにより DC1 は、AS-path に 65000 ではなく 65551 を含んだ状態でこれらのルートを受信するため、BGP のループ検出を防ぎ、DC1 と DC2 間の双方向通信を復元します。 DC3 については、ルートは ASN 64512（DC3）と ASN 65000（DC2）の両方を持った状態で、DC2 の VPN アタッチメントを通じて AWS Cloud WAN に入ります。インバウンドポリシーは AS-path 全体を単一の専用 ASN（65552）で置き換え、競合する2つの値を1回の操作で取り除きます。これにより、DC3 のプレフィックスが AWS Cloud WAN のルートテーブルに受け入れられ、DC1 およびクラウドリソースにアドバタイズされるようになります。 すべての置換 ASN（65550、65551、65552）は、コアネットワークエッジ用に設定された ASN 範囲の外から選択されています。ルーティングポリシーの置換値は、AWS Cloud WAN の CNE の ASN 範囲と重複できないためです。 ステップ1：DC1 の Direct Connect ゲートウェイアタッチメントにインバウンドポリシーを定義する このポリシーは、DC1 から到着する AS-path に ASN 65000 を含むルートにマッチし、それを 65550 に置き換えます。これらのルートが DC2 に伝播されるとき、AS-path には 65000 が含まれなくなるため、DC2 のルーターはそれらを受け入れます。 { "routing-policies": [ { "routing-policy-name": "replaceasndc1", "routing-policy-description": "Replace ASN 65000 from DC1 with 65550 to avoid loop detection at DC2", "routing-policy-direction": "inbound", "routing-policy-number": 100, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65550]}}} ] } ] } ステップ2：DC2 の VPN アタッチメントにインバウンドポリシーを定義する このポリシーは、2つのルーティングルールを使用して ASN の競合を解決します。 ルール10 ：DC3 の ASN（64512）を 65552 に置き換えます。 ルール20 ：DC2 の ASN（65000）を 65551 に置き換えます。 DC3 からのルートは DC2 を経由して通過するため、AS-path に両方の ASN を含みます。そのため、順序が重要です。replace-asn-list は AS-path 全体を上書きするため、DC3 のルートが専用の置換 ASN（65552）を受け取れるように、ルール10 を先に実行する必要があります。 もしルール20 が先に実行されると、DC2 の ASN にマッチして AS-path 全体を 65551 で置き換えてしまいます。DC3 のルートは依然として受け入れられ、接続は機能しますが、DC2 のルートと区別がつかなくなり、ルートの追跡やトラブルシューティングが難しくなります。 { "routing-policies": [ { "routing-policy-name": "replaceasndc2", "routing-policy-description": "Replace ASN 65000 from DC2 with 65551 and ASN 64512 from DC3 with 65552", "routing-policy-direction": "inbound", "routing-policy-number": 200, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 64512}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65552]}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65551]}}} ] } ] } ステップ3：ポリシーをアタッチメントに関連付ける routing-policy-label にマッチする attachment-routing-policy-rules を定義することで、各ルーティングポリシーをアタッチメントに関連付けます。routing-policy-label パラメータまたはコンソールを使用して、各アタッチメントに指定の routing-policy-label をタグ付けします。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dc1inbound"}], "action": {"associate-routing-policies": ["replaceasndc1"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dc2inbound"}], "action": {"associate-routing-policies": ["replaceasndc2"]}} ] } 最後に、routing-policy-label パラメータまたはコンソールを使用して、各アタッチメントに指定の routing-policy-label をタグ付けします。このシナリオでは、ラベル dc1inbound を DC1 の Direct Connect ゲートウェイアタッチメントに、dc2inbound を DC2 の VPN アタッチメントに割り当てます。 知っておくべきこと AWS Cloud WAN への Direct Connect ゲートウェイアタッチメントを作成する際、DXGW が接続する CNE を選択できます。各 CNE は自身のローカルリージョンの VPC ルートのみを DXGW にアドバタイズするため、関連付けを制限する特別な理由がない限り、シナリオ2に示すようにすべての CNE を選択することを推奨します。 IPv6 がサポートされています。同じマッチ条件、アクション、ポリシー構造が IPv6 プレフィックスにも適用されます（ワイルドカードマッチとして ::/0 を使用）。本記事で説明したすべてのシナリオにおいて、IPv6 のルート伝播に同一のルーティングポリシーパターンを適用できます。 シナリオ2に示すように複数の Direct Connect ゲートウェイをデプロイすると、単一の Direct Connect ゲートウェイ（DXGW）を使用する場合よりも、きめ細かなルーティング制御が可能になります。AWS Cloud WAN のルーティングポリシーは、VIF や DXGW のレベルで利用できるものよりも幅広い BGP 属性の制御を提供します。オンプレミス接続を複数の DXGW に分散させることで、ルーティングの決定を AWS Cloud WAN に移し、トラフィックエンジニアリングのためのより豊富なポリシー制御を利用できるようになります。 ルーティングポリシー内のルールは、rule-number の順に評価されます。評価を停止する終端アクションは drop と allow のみです。replace-asn-list、set-local-preference、add-community などのその他のアクションは非終端であり、評価は残りのルールへと続き、各変更が引き継がれていきます。replace-asn-list アクションは、個々の ASN を置換するのではなく、AS-path 全体を上書きします。その結果、先のルールによって変更されたルートは、後のルールがマッチするための元の ASN をもはや持ちません。シナリオ3の DC2 を経由する DC3 のルートのように、ルートが複数の ASN を持ちうる場合は、最も具体的なマッチが最初に適用されるようにルールを順序付けてください。 AWS Cloud WAN は、CNE ごとに BGP AS-path のループ検出を実行し、このチェックはインバウンドルーティングポリシーが適用される前に実行されます。受信ルートの AS-path に、そのアタッチメントが接続する CNE の ASN が含まれている場合、replace-asn-list ポリシーが変更を加える前にそのルートは拒否されます（詳細な例についてはシナリオ3を参照してください）。 クリーンアップ 本記事で説明したルーティングポリシーは、AWS Cloud WAN のコアネットワークポリシードキュメント内で定義されるものであり、単独で課金対象となるリソースを作成することはありません。これらの設定を削除するには、次の手順を実行します。 AWS Cloud WAN コンソールでアタッチメントを編集するか、AWS CLI を使用して、各アタッチメントから routing-policy-label を削除します。 ポリシーを参照している attachment-routing-policy-rules と、すべての segment-actions を削除します。 コアネットワークポリシーの routing-policies セクションから、ルーティングポリシーの定義（tagTgwRoutes、filterRoutesToHybrid、pathPreferenceDxgw*、replaceasn*）を削除します。 変更を適用するために、コアネットワークポリシーのバージョン更新を送信します。 シナリオ2でマネージドプレフィックスリストを作成し、それらが不要になった場合は、AWS CLI または AWS マネジメントコンソールを使用して削除します。 まとめ 本記事では、AWS Cloud WAN のルーティングポリシーが、ハイブリッド環境やマルチサイト環境における一般的なルーティングの課題をどのように解決できるかを示す、3つの実運用シナリオを取り上げました。コミュニティのタグ付けとフィルタリングを使用して Transit Gateway 環境からのルート伝播を制御する方法、ローカルプリファレンスを使用して複数の DXGW と Direct Connect ロケーション間のパス選択を改善する方法、そして AS-path の置換を使用して BGP の ASN の競合を解決する方法を紹介しました。ルーティングポリシー設定の基礎を扱った Part 1 と合わせて、これらのシナリオは、AWS Cloud WAN をグローバルネットワークの統合的なルーティング制御レイヤーとしてどのように使用できるかを示しています。始めるには、 AWS Cloud WAN のドキュメント を参照してください。 著者について Jordan Rojas Garcia Jordan は、AWS の Worldwide Specialist Organization に所属するシニアネットワークスペシャリストソリューションアーキテクトです。従来型のデータセンターネットワークの分野でキャリアをスタートし、2018年に AWS に入社しました。AWS では、クラウドネットワーキングソリューションの設計に注力し、AWS クラウドでネットワークを構築するためのガイダンスとベストプラクティスを提供しています。仕事以外では、旅行、新しい料理の開拓、ハイキングを楽しみ、二輪車と四輪車の運転への情熱を燃やしています。 Akeef Khan Akeef Khan は、オーストラリアのシドニーを拠点とする Amazon Web Services のソリューションアーキテクトです。Cross-Industries セグメントのお客様を担当し、小売業や QSR（クイックサービスレストラン）の組織が AWS を採用、運用、スケールできるよう支援しています。彼の専門分野はネットワーキングであり、AWS のサービスを使ってお客様のグローバルなネットワーク接続をシンプルにすることに情熱を注いでいます。仕事以外では、新しいテクノロジーの探求と継続的な学習を楽しんでいます。 翻訳は Solutions Architect の田村 大地が担当しました。原文は こちら です。