AWS DevOps Agent の「リリース管理」を試す — マージ前にコードレビューとリリーステストを自動化する（プレビュー）

こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。

本番環境で起きる障害は、直前に入ったコード変更が引き金になることが少なくありません。だからこそマージ前のコードレビューやテストが重要なのですが、レビューの観点は人によってばらつき、テストを書く手間は小さくなく、複数リポジトリにまたがる影響は見落としがちです。

AWS DevOps Agent は、AWS・マルチクラウド・オンプレミス環境の運用を支援するAIエージェントです。インシデントの調査・復旧・予防といった本番運用の機能に加えて、コード変更が本番に届く前に検証する「リリース管理（release management）」機能がプレビューで提供されています。公式ドキュメントでも、DevOps Agent はリリース管理と本番運用の両方にまたがるエージェントと位置づけられています。

この記事では、そのリリース管理機能にしぼって、次の内容を扱います。

リリース管理が提供する2つの機能（リリース準備コードレビューとリリーステスト）の中身
どの開発ワークフローに、どう組み込めるか
実際に動かしてみた結果
プレビュー段階で使う際の注意点

なお本記事の内容は2026年6月時点のものです。リリース管理はプレビュー段階で変更が速いため、最新の仕様は必ず公式ドキュメントをご確認ください。（下部に参考リンクを記載しています。）

リリース管理とは

リリース管理は、コード生成と本番デプロイの間に置かれる自動検証レイヤーです。DevOps Agent がコード変更をレビューし、さらに実際に動かしてテストすることで、本番に届く前に問題を見つけます。

機能は2つで構成されています。

リリース準備コードレビュー（Release readiness code review）: コード変更を組織ポリシー・依存関係・アクセス制御の観点で評価し、検証環境でビルドとテストを行う
リリーステスト（Release testing）: デプロイ済みのアプリケーションに対して、変更内容に応じたテストを生成・実行する

リリース管理は、本番でインシデントが起きるより前、コード変更の段階にエージェントの目を向ける機能だと捉えると位置づけが分かりやすいです。

リリース準備コードレビュー

リリース準備コードレビューは、コード変更を本番リスクの観点で評価する機能です。一般的なlinterや静的解析がルールベースで個々のコードを見るのに対し、この機能はアプリケーションのアーキテクチャ、他リポジトリとの関係、組織のポリシーを踏まえて、文脈の中で変更を評価します。

レビューは次の3つの観点（公式では「レンズ」と表現）で行われます。

標準への準拠（Standards evaluation）: セキュリティ・信頼性・性能・運用などの組織標準に照らして評価します。標準は自然言語の「スキル（Skills）」として定義でき、policy-as-code の専門知識がなくてもポリシーを記述できます。
リポジトリ横断の依存関係分析（Cross-repository dependency analysis）: 接続したリポジトリをインデックス化して構築したナレッジグラフを使い、あるリポジトリの変更が別リポジトリの利用側を壊さないかを検出します。
アクセス制御の検証（Access-control verification）: CloudFormation の変更について、IAMポリシー・リソースポリシー・ネットワーク設定が Well-Architected のベストプラクティスに沿うか、権限がアプリの必要範囲を超えて広がっていないかを確認します。

レビューと同時に、自動の検証テストも実行できます。DevOps Agent は AWS が管理する検証環境にコードをクローンし、必要なビルドツールと依存関係を判別して導入したうえでビルドし、テスト計画を生成・実行して機能的なリスク（エッジケースなど）を洗い出します。検証環境のアウトバウンド通信は、主要なパッケージレジストリやコンテナレジストリなどの許可ドメインに限定されています。あわせて、認証情報の露出防止や変更系AWS操作のブロックといった安全ガードレールが組み込まれています。

レビューの結果は、次の内容を含むレポートとして返ります。

推奨アクション: BLOCK（マージを止める）/ Proceed with Caution（注意して進める）/ Safe to Release（リリースして問題ない）
変更サマリ: 何がどの範囲で変わったか
リスク分析: 影響するコード箇所つきの具体的な指摘
推奨対応: 各指摘を解消するための手順

リリーステスト

リリーステストは、デプロイ済みのアプリケーションに対して探索的なテストを実行する機能です。コードレビューに含まれる検証テストが AWS 管理の検証環境でビルドして行う確認なのに対し、リリーステストはすでにデプロイされたアプリケーションそのものに対して実行する点が異なります。

あらかじめ用意した固定の回帰スイートを流すのではなく、変更内容を踏まえて「何をテストすべきか」を判断し、変更に特化したテスト計画を生成して実行します。機能の回帰、ユーザージャーニーの検証、統合テスト、エッジケースの探索をカバーします。

対象は Web アプリケーション（React・Angular・Vue・サーバーレンダリング）と REST API で、テスト種別はブラウザ操作による UI テストと、HTTPエンドポイントを直接呼び出す API テストの2種類です。

テスト対象は「テストプロファイル」として定義します。プロファイルには対象アプリの URL とテスト種別を設定します。

ここで重要な注意点があります。リリーステストは対象アプリに実際のリクエストを送ります。フォーム送信やエラーハンドリングの確認のために、書き込み系の操作（POST / PUT / DELETE）も実行されます。つまりデータの作成・変更・削除が起こりえます。公式ドキュメントでも、対象 URL にはステージングなどのテスト環境を指定し、本番 URL は書き込み操作が安全だと確認できる場合に限るよう強く案内されています。

開発ワークフローへの組み込み方

リリース管理は、開発のさまざまな段階から起動できます。

コード生成中: Kiro / Claude Code 向けプラグイン経由で、コードを書いている最中にレビューを実行できます。コミット前に IDE 上で指摘が出るため、その場で直せます。
プルリクエスト / マージリクエスト: GitHub や GitLab で PR・MR が作成・更新されると自動でレビューが走り、指摘は該当行へのインラインコメントとして表示されます。指摘をマージのブロック条件にするか、助言にとどめるかを設定できます。
オンデマンド: DevOps Agent のチャットで、任意のブランチ・コミット・リポジトリのレビューを依頼できます（例: 「my-service リポジトリの main ブランチを、リリースリスクの観点でレビューして」）。
CI/CD パイプライン: GitHub Actions や GitLab CI のステージとして組み込めます。リリーステストは webhook 経由で起動し、結果を GitHub の Check Run として返します。

リリース管理は、既存のコードレビューや CI を置き換えるものではなく、補完する位置づけです。リポジトリ単独では見えない変更の影響範囲を依存関係グラフからとらえたり、自然言語で書いた組織ポリシーで評価したりできる点が、従来の linter やテストとは違うところです。

やってみた: チャットからリリース準備レビューを実行する

ここからは実際にリリース管理を動かしてみます。今回は最も手軽な入口として、DevOps Agent のチャットからオンデマンドでリリース準備コードレビューを実行してみます。リポジトリを接続してインデックスが終わっていれば、PR の自動レビューや検証テストを有効化していなくても、チャットから任意のブランチやコミットをレビューに回せます。

検証の前提は次のとおりです。

リージョン: us-east-1（リリース管理はプレビューのため、現時点ではこのリージョンのみ）
リポジトリ: GitHub の検証用リポジトリを1つ接続

セットアップ

リージョンを us-east-1 にして DevOps Agent コンソールを開きます。
Agent Space を作成します。
機能プロバイダーメニューから GitHub の登録をします。
作成した Agent Space の機能タブから、パイプラインに GitHub リポジトリを接続します。
インデックスの完了を待ちます。

レビューで重視したい観点や、何を BLOCK 扱いにするかをあらかじめ決めておきたい場合は、リポジトリに AGENTS.md（Agent instructions）を置いて自然言語で定義できます。今回は既定のまま進めます。

レビューの実行

インデックスが完了したら、DevOps Agent のチャットでレビューを依頼します。「どのリポジトリの、どのブランチ（またはコミット）を、リリースリスクの観点でレビューするか」を伝えるだけです。たとえば次のように依頼します。

「my-service リポジトリの main ブランチを、リリースリスクの観点でレビューして」
「infrastructure リポジトリのコミット abc123 を、リリース準備の観点でレビューして」

結果の確認

レビューが終わると、結果は Web App の「変更」ページにレポートとして表示されます。レポートには、推奨アクション（BLOCK / Proceed with Caution / Safe to Release）、変更サマリ、影響するコード箇所つきのリスク分析、各指摘への推奨対応が含まれます。

気になった指摘は、チャットでそのまま深掘りできます（例:「なぜ42行目の IAM 変更を指摘したのか」「変更した API に依存しているリポジトリはどれか」）。

スクリーンショットはマスクしていますが、英語の文章で結果が記載されています。

使う上での注意点（プレビュー段階）

リリース管理はプレビュー段階のため、使う前に押さえておきたい点が4つあります。

料金: プレビュー中は追加費用なしで利用できます。ただし、インシデント調査などの本番運用タスクは agent-second 単位（$0.0083/agent-second）で課金されます。リリース管理が無償なのはあくまでプレビュー中に限る点に注意してください。
提供リージョン: 現時点では us-east-1 のみです。GA時に、東京を含む全対応リージョンへ拡大される予定です。
実行環境: リリーステストは対象アプリに書き込み系のリクエストを送るため、本番 URL は避け、対象はパブリックインターネットから到達できる必要があります（プライベートエンドポイントは現状非対応）。コードレビューの検証環境から社内のアーティファクトストアなどへつなぐ場合は、別途プライベート接続（VPC）と runtime role を設定します。

まとめ

AWS DevOps Agent のリリース管理機能（プレビュー）を見てきました。リリース準備コードレビューは、組織ポリシー・リポジトリ横断の依存関係・アクセス制御の観点でコード変更を評価し、BLOCK / Proceed with Caution / Safe to Release という分かりやすい判断を返します。リリーステストは、変更に応じたテストを生成して、デプロイ済みのアプリケーションで実行します。どちらも IDE・PR/MR・チャット・CI から起動でき、既存の開発フローに無理なく差し込めます。

インシデントが起きてから動くだけでなく、コードが本番に届く前のリスクをエージェントが検出してくれるのは、運用担当者にとっても開発者にとっても心強いところです。一方で、プレビュー段階ゆえの制約（リージョン・初回インデックスの時間・リリーステストの副作用）もあるため、まずはステージング環境で挙動を確かめるところから始めるのがよさそうです。