この記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」の29日目の記事となります。
過去の投稿(リンク集)は以下リンクからご覧ください。
はじめに
開発が進むにつれて提出される Pull Request(PR)。
気づけば未レビューの PR が溜まり続け、レビュー作業がボトルネックになって開発スピードが落ちてしまう……そんな経験ありませんか?
メンバーのレビューやテストの手間を少しでも減らし、開発に集中できる環境を整えるため、今回は AWS DevOps Agent の導入を検討・検証してみました。
同じような課題を抱えている方や解決策を探している方へ、ひとつの選択肢として共有できれば幸いです。
リリース準備状況コードレビューとは
※AWS公式ドキュメントより引用
リリース準備状況コードレビューでは、リポジトリ間の依存リスク、内部標準コンプライアンス、アクセスコントロールの正確性についてコードの変更を評価します。また、 AWS DevOps エージェントによって管理される検証環境で、コードの変更を構築、実行、テストする自動検証テストも実行します。
AWS DevOps Agent の機能でコードレビューと自動検証テストまでやってくれるものになります。
コードレビュー、自動検証テストの各機能を個別に有効、無効の設定が可能です。
毎回、自動検証テストを実施するとレビュー時間が長くなったりするので有効無効設定ができるのはありがたいです。
※料金や対応リージョンなどはAWS公式の最新情報をご確認ください。
- プレビュー期間中:追加費用なし(2026/8/29時点)
- 対応リージョン:バージニア北部(us-east-1)
AWS DevOps Agent 導入手順(大まかな流れ)
-
AWS DevOps Agent のセットアップ
- DevOps Agent エージェントスペースの構築
-
パイプラインの構築
- 2-1. リポジトリの選択
- 2-2. トリガー条件設定: AWS 側で対象ブランチ(develop など)と発火イベントを設定
-
レビュー指示の配置
- AWS DevOps Agent の
AGENTS.mdに日本語指定やセキュリティ観点を記述
- AWS DevOps Agent の
- 動作確認(PR でのテスト)
今回はGithubと連携して、コードレビューと自動検証テストの実行を試してみます。
導入手順詳細
1. AWS DevOps Agent のセットアップ
- 今回はCDKでエージェントスペースを構築
- バージニア北部(us-east-1)に構築
2. パイプラインの構築
Githubアカウントが登録されていない場合は GitHub アカウント / 組織を登録 画面が表示されます。
今回は個人利用のリポジトリのため、初期状態のままで送信をクリックしました。
送信を押すとリダイレクトするため、承認する をクリックします。
プロジェクトを選択画面に遷移し、対象のリポジトリを選択します。
コードレビューと自動テストの設定で、今回は両方選択し次へ進みます。
レビュー画面が出るため、問題がなければ 送信 をクリックします。
Githubへアカウントのアクセス要求が表示されるため 承認する をクリックします。
AWS DevOps Agent 未インストールの場合、Github Apps に自動でインストールされます。
3. レビュー指示の配置
エージェントスペースの ウェブアプリを起動 から IAM経由で起動する でAWS DevOps Agentのコンソールにアクセスします。
ナレッジ > Release readiness review からAGENTS.mdを編集します。
今回設定した内容はこちらです。
# コードレビューガイドライン
## 基本ルール
- レビューのコメントおよびフィードバックは、必ず【日本語】で記述してください。
- 簡潔かつ具体的な改善案をコード付きで提示してください。
## セキュリティレビュー観点
1. **シークレット・認証情報のベタ書き禁止**
- APIキー、パスワード、トークン、秘密鍵などの機密情報をコード内に直接ハードコード(ベタ書き)しないでください。
- 必要な場合は、環境変数(`process.env`)や Secrets Manager / Parameter Store を使用するよう指摘してください。
2. **最小権限・安全なコーディング**
- 不必要な権限設定や、インジェクション(SQL/Command)の危険性がないかチェックしてください。
実際に試してみた
PRを作成したところ無事動きました。
今回は簡易なLambdaのコードを作成して、コード内でシークレットをべた書きにしてPRを作成しています。
GitHub上
自動検証テストまで行うようにしたので、完了まで時間がかかりましたが結果が反映されてます。ちゃんと問題部分について指摘をしてくれました。
レポート上
レポート上でも結果を確認できました。
導入で躓いたこと
1. Agent Space を CDK で作成する際に、バージニア北部でのブートストラップが必要だった
初歩的な話ですが、DevOps Agent の Agent Space を CDK で構築しようとしたところ、デプロイ時にブートストラップ未実施のエラーで失敗しました。
原因
DevOps Agent はバージニア北部(us-east-1)で利用する必要がありますが、これまで CDK は東京リージョンでしか使っておらず、us-east-1 に CDK 用のブートストラップスタック(CDKToolkit)が存在していませんでした。
CDK のブートストラップは アカウント×リージョン単位 で必要になるため、普段使っているリージョンで実施済みでも、us-east-1 では改めて実行する必要があります。
今後は確認するようにしたいと思います…
対応
対象アカウントの us-east-1 に対してブートストラップを実行してから、再度デプロイしました。
cdk bootstrap aws://<ACCOUNT_ID>/us-east-1
既にブートストラップ済みかどうかは、CloudFormation で CDKToolkit スタックの有無を確認すると早いです。
aws cloudformation describe-stacks --stack-name CDKToolkit --region us-east-1
学び
新機能の検証は「普段使っていないリージョン」で始まることが多く、そこが最初の詰まりどころになりがちです。
リージョン指定が固定されているサービスを触るときは、着手前にブートストラップ状況を確認しておくと無駄な失敗デプロイを避けられることできますね。
2. リポジトリ内にレビュー観点のファイルを置いても読み込んでくれない
「この観点でレビューしてほしい」という内容をまとめたファイルをリポジトリに配置しましたが、レビュー結果にはまったく反映されませんでした。
ファイル名や配置ディレクトリを変えても状況は同じで、汎用的な観点でのレビューコメントしか返ってきません。
原因
DevOps Agent はリポジトリ内の任意のドキュメントを自動的にレビュー観点として解釈してくれるわけではありませんでした。
DevOps Agent に与える指示は、規約として定められた AGENTS.md に記述する必要があります。独自に用意したファイルは、単なるリポジトリ内のファイルとして扱われるだけでした。
対応
レビュー観点を AGENTS.md に集約したところ、指定した観点に沿ったコメントが返ってくるようになりました。
学び
「観点を書いたファイルを置く」ではなく「Agent が読む場所に書く」が正解でした。
レビュー品質は AGENTS.md の書き方にほぼ依存するので、ここをチームで育てていくことがそのまま活用度に直結しそうです。
3. 日本語を明示しないと英語で出力される
レビューコメントは、特に指定しない限り英語で返ってきました。内容自体は妥当なのですが、日本語話者中心のチームだとレビューコメントを読む負荷が上がり、結局読み飛ばされてしまいます。
対応
AGENTS.md に出力言語の指示を明記しました。
## 基本ルール
- レビューのコメントおよびフィードバックは、必ず【日本語】で記述してください。
- 簡潔かつ具体的な改善案をコード付きで提示してください。
学び
「日本語で」と一度書くだけで済む話ですが、書かないと確実に英語になります。
出力形式やコメントの粒度(重大度のラベル付けなど)も含めて、期待する出力の形は明示的に書く のが前提だと考えたほうがよさそうです。
ただ、25KBと容量制限があるため、細かいレビュー観点などは Skills を利用して、汎用的な内容を AGENTS.md に記載するのがよさそうです。
まとめ
今回の検証でつまずいたのは、以下の 3 点でした。
| # | つまずき | 対応 |
|---|---|---|
| 1 |
us-east-1 で CDK ブートストラップ未実施 |
対象アカウントの us-east-1 でブートストラップを実行 |
| 2 | 独自のレビュー観点ファイルが読まれない | 観点を AGENTS.md に集約 |
| 3 | 出力が英語になる |
AGENTS.md に日本語出力を明記 |
いずれも一度分かってしまえば些細な話ですが、初見だと原因の切り分けに時間を取られました。
コードレビュー機能自体は、レビュー観点のばらつきを抑えたり、人間のレビュー前に機械的な指摘を潰しておいたりする用途で十分に開発効率の向上が見込めそうです。
特に、レビュー担当者が「本質的な設計の議論」に集中できるようになる点は大きいと感じました。
一方で、レビューの質は AGENTS.md の内容に大きく左右されるため、まずはここを正しく定義していくことが今後の課題です。
チームの規約や過去のレビューで繰り返し指摘された内容を棚卸しして AGENTS.md に落とし込み、実際のレビュー結果を見ながら継続的に磨き込んでいきたいと考えています。
今回触れたのはDevOps Agentのごく一部の機能なので、引き続き他の機能も試し、開発から運用までを通してどこまで任せられるのかを見極めていきたいです。
最後までお読みいただきありがとうございました!
明日以降のJr.Championsによる記事投稿をお楽しみに!
参考










