現場で使える AWS DevOps Agent 活用ノウハウ - Release Management 機能の検証結果を添えて / AWS DevOps Agent Release Management and Know-How

「JAWS-UG千葉支部#43 AWS DevOps Agent 祭り」の登壇資料です。
https://jawsug-chiba.connpass.com/event/398349/

Transcript

1. JAWS-UG千葉支部#43 AWS DevOps Agent 祭り 現場で使える AWS DevOps Agent 活用ノウハウ 山口 正徳 JAWS-UG 千葉支部 AWS Community Hero 1
2. 自己紹介 山口 正徳 JAWS-UG千葉支部 グローバル認定/表彰 ・AWS Community HERO ・AWS Ambassador ・APJ AWS Community Leaders Award 2回受賞（2022、2024） ・AWS Gold Jacket Club ・AWS re:Inforce 2025 登壇 日本国内認定/表彰 ・AWS Samurai 2020 ・Japan AWS Top Engineer 2019 〜 2026 ・JAWS DAYS 2021 実行委員長 ・AWS BuilderCards 日本語化発起人 © 2025, Amazon W eb Serv ices, Inc. or its af filiates. All rights reserved.
3. これまでの AWS DevOps Agent 登壇資料 ・AWS DevOps Agent 検証で見えた可能性と限界 https://speakerdeck.com/kinunori/aws-devops-agent ・AWS DevOps Agent x ECS on Fargate検証 https://speakerdeck.com/kinunori/aws-devops-agent-x-ecs-on-fargate ・AWS DevOps Agentはチームメイトになれるのか？ https://speakerdeck.com/kinunori/can-aws-devops-agent-become-ateammate ・AWS DevOps Agent を使いこなす (チョークトーク資料) https://speakerdeck.com/kinunori/aws-dev-ops-agent-chalk-talk-awssummit-japan-2026 AWS DevOps Agent 山口 で検索 3
4. 本セッションについて AWS DevOps Agent の基本的な内容をおさらいしつつ、その利用を進める際に 得たノウハウと共有することを目的としています。 ・話すこと ・AWS DevOps Agent の概要 ・AWS DevOps Agent を利用する上で必要なノウハウ ・リリースマネジメント機能の検証結果 ・話さないこと ・AWS DevOps Agent の機能に関する詳細な説明 ・各環境における AWS DevOps Agent の実装具体例 4
5. アジェンダ 1. AWS DevOps Agent おさらい 2. AWS DevOps Agent 活用ノウハウ 3. Release Management 機能（プレビュー）検証から 得られたノウハウ 4. まとめ 5
6. AWS DevOps Agent おさらい 6
7. AWS DevOps Agent 概要 エージェントを利用した自律的なインシデント対応と予防 インシデント対応 根本原因の特定 プロアクティブな改善 アラートやチケットをトリガーに インシデント調査を即時開始 テレメトリーデータ、コード、 過去のインシデントパターンから 監査情報、デプロイ環境を分析し、 学習し、監視、インフラ、CI/CD インシデントの根本原因を特定 パイプラインなどの改善点を提案 AWS DevOps Agent導入によって得られるメリット ・平均復旧時間 (MTTR) の短縮 ・再発防止とシステム回復力の向上 ・既存のツールやワークフローとのシームレスな統合 ・運用に関するトイルを削減し、生産性の高い作業に集中 7
8. AWS DevOps Agent 仕組み インテグレーション インシデントトリガー AWS DevOps Agent マネージドサービス IAM、AWS IDC、 外部Identity Provider (IdP) 認証認可 ServiceNow, PagerDuty, Dynatrace, Webhooks 3P Observability ツール Dynatrace, Datadog, Splunk, New Relic, Grafana, Azure Resource Integration, CI/CD GitHub, GitLab, Azure DevOps MCPサーバー OAuth 2.0 + API Keys経由で 拡張可能 解析とレポート Management Console, EventBridge, Slack オペレーター 管理 専用のWebアプリから Agentへの指示等を行う マネージメントコンソール からセットアップ AIエンジン AWS DevOps Agent Using Amazon Bedrock オンデマンド 根本原因調査 インシデント対応 評価 出力内容： ・ 改ざん不可のAgent Journal ・ 過去インシデント分析 ・推奨事項 ・ タイムライン ・ 根本原因分析 ・ 復旧計画 ・ AWS Supportケースとの連携 （コンテキスト自動共有） インシデントの緩和 8
9. インシデント対応フローのイメージ 9
10. 表示・入力・出力ともに日本語対応（※GA機能のみ） ※GAされていない機能も非公式だが日本語出力させる方法あり 10
11. AWS DevOps Agent 活用ノウハウ 11
12. リソース把握のフロー Step 1 ： アカウント紐付け後、トポロジー検出が起動 （自動） Step 2 ： 対象AWSアカウントのCloudFormationスタ ックのリソース、Resource Explorerから参 照可能なリソース列挙し、エージェントスペ ースのトポロジー検出とマッピング （aidevops:DiscoverTopology権限が必要） Step 3 ： ※ リソースのグラフ化、CI/CDのマッピング、 可視観測性とのマッピング Step 4 ： ※ グラフ化されたトポロジーをAgent Space Understanding という学習済みスキルで調査 情報として利用可能にする ※ https://builder.aws.com/content/34wXHSMKTY2EEMYzYeRo7JmKsh7/u nboxing-faqs-aws-devops-agent Step 5 ： ※ オペレーターWebアプリのTopologyページ に表示、チャットからも問い合わせ可能に 12
13. リソース把握の落とし穴 DevOps Agentがリソース検出するためには Resource Explorerが必要。 リージョンで無効化されている場合は、 CloudFormationスタックで管理されている リソース以外は検出できない。 13
14. リソース把握の落とし穴 タグ機能を使って対象リソースの調整を できるのは、Resource Explorerでリスト するリソースのみ。 CloudFormationスタックで管理されている リソースはタグで絞り込みができず、 エージェントスペースの管理対象になる。 DevOps Agentのリソースアクセス用IAMポ リシーで制御できる可能性はあるが、 調査に影響なく制御することが難しい（影響 の有無を判断することが難しい）ため、 １アカウント１システムのシンプルな運用が AWS DevOps Agentと相性が良い。 14
15. 調査の質を高くするログアクセスの設定 オブジェクトへの アクセス権限がない AWS DevOps Agent作成時に自動作成する リソースアクセス用のIAMロールにアタッチさ れたIAMポリシーでは 3 Pillars of Observability のうち 「ログ」へのアクセス制限がかかっている。 ログをS3バケットに保管している場合、 対象のログにアクセスできず、DevOps エージェントは想定で調査を行う形となる。 15
16. 調査の質を高くするログアクセスの設定 S3オブジェクトへのアクセス権限がない場合は調査できない S3オブジェクトへのアクセス権限を与えれば調査できる アプリケーションの調査に必要なS3バケットと オブジェクトに対して、s3:ListBucket、 S3:GetObjectを付与することを忘れずに。 特にALB、CloudFrontのログはS3バケットに 保管されることが多く、調査対象から漏れがち。 16
17. 調査名は分かりやすく、命名規約を用意する 一貫性がなく読みにくい調査は属人化につながる 現時点で調査名は変更できないため、 自分以外が見ても理解できる内容で 調査名をつける必要がある。 チーム内で命名規約を用意して ばらつきを抑えて運用することを推奨。 17
18. スキルの活用 カスタムスキルを活用しよう 学習済みスキル ・調査パターン、使用ツール、 トポロジーから学習 ・チームの調査アプローチに 基づいてスキルを構築 ・ 独自の運用課題に適応 ・時間の経過とともに効果を向 カスタムスキル コードインデックス ・システムに特化した調査手順や ・アプリケーションのコードを 複数リポジトリからインデックス化 ベストプラクティスを追加 ・ 対象エージェントの種類： オンデマンド、インシデント トリアージ、RCA、緩和対応、 評価 ・コンテキスト消費量を抑える ・調査の焦点と精度を向上 主なメリット 運用の経験を通じて継続的に 改善される ・コード構造と依存関係を理解 ・潜在的なバグも特定 ・緩和計画でコードレベルの修正を 提案 ・GitHub, GitLab. Azure DevOps と連携 主なメリット 主なメリット チームの知識を体系化 コードレベルの根本原因分析を 実施 18
19. スキルの活用 S3バケットからのログ調査もスキル化することで自動化へ 個別指示なしでは調査対象にはなり難い S3バケットに保管されたログの調査も スキル化することで自動的に調査対象となる ログフォーマットもスキルに記述することで 調査にかかる時間とコンテキストを抑える ことが可能 19
20. Release Management 機能（プレビュー）検証から得られたノウハウ 20
21. Release Management 機能（プレビュー） リリース準備コードレビュー（Release readiness code review） コード変更を本番に出す前に AI が本番要件・依存関係の安全性・利用者が与えた基準やベストプラクティス に照らして評価。社内標準との照合・リポジトリ横断の影響分析・IAM 権限検証に加え、隔離環境で実際に ビルド・試運転まで行う。 自律リリーステスト（Release testing） デプロイ済みの実アプリに対し、AI が自分でテストプランを立てて、ブラウザ操作や API 呼び出しで検証する 「実路走行」機能。手動・チャット・CI/CD (GitHub Actionsなど) から起動できる。 21
22. 検証内容 リリース準備コードレビュー（6件） 自律リリーステスト （6件） ▸ #1 標準（ルール）違反の検出 ▸ RT#1 API 探索 ▸ #2 クロスリポジトリへの破壊的変更 ▸ RT#2 UIテスト ▸ #3 IAM ワイルドカード（過剰権限） ▸ RT#3 仕込みバグ検出 ▸ #4 隠れバグ＋テスト隠滅 ▸ RT#4 日本語チャットからの起動 ▸ #5 PRトリガーとチャットトリガーによる レビュー品質差異の確認 ▸ RT#5 GitHub Actions からの起動 ▸ #6 Instructionの言語 3パターン比較 ▸ RT#6 テストレポートの言語比較 22
23. 検証構成 task-api（API） task-client（UI） タスク管理の REST API + Web 画面 FastAPI / Lambda ＋ DynamoDB task-api を呼び出す利用側アプリ CloudFormation はお手本構成 レスポンスの書式（ id / title /description / status ）を （暗号化・最小権限・ログ） 読む前提で実装 API仕様は OpenAPI(Swagger) で記述 ・クロスリポジトリの影響検出を検証するために、片方の変更でもう片方が壊れる関係をが必要 ・暗号化や最小権限を最初から正しく作っておき、後から「わざと壊す」ための状況を用意 ・リリーステストは動いている URL が必要となるため、Lambda + DynamoDB で公開 23
24. リリース準備コードレビュー検証 24
25. #1 標準（ルール）違反の検出 実施内容 ・CloudFormation の ExportsBucket から BucketEncryption(SSE-S3) と LoggingConfiguration を削除 ・PR 本文に「エクスポート高速化のため」という口実を記載 ・レビュー後、両設定を復元するコミットを同一 PR に push 期待結果 暗号化=ブロッキング、ログ=非ブロッキングでBLOCK、重大度の区別、該当行へのインラインコメント。 修正版pushへの自動再レビュー→解除。 結果 BLOCK 判定し、２件の問題を検出。暗号化は ブロッキング 、ログ=非ブロッキングと重大度を正しく区別 該当行にインラインコメント＋復元 YAML＋再現コマンドを表示。ログ削除による CloudFormation の矛盾まで指摘 口実への反証：「SSE-S3 はサーバー側処理でスループット影響は計測不能な水準、ポリシー違反に見合う利益はない」 修正 push で自動再レビュー起動 → change approved に転換 25
26. #1 標準（ルール）違反の検出 リリース準備レビューに暗号化、アクセスログに関する標準（ルール）を記述 26
27. #1 標準（ルール）違反の検出 ルールに反する内容へ口実をつけて PR を作成 27
28. #1 標準（ルール）違反の検出 暗号化はブロッキング、アクセスログは非ブロッキングで検出 暗号化を無効化にした口実と実際の変更を確認し、口実に対して反証している 28
29. #2 クロスリポジトリへの破壊的変更 実施内容 ・Task スキーマの名前をリネーム。APIコード（テスト・README 含む）は完全更新し単体では全テストパス ・APIを参照する UIリポジトリのコードだけが壊れる構図に。PR 本文に UIリポジトリに関する言及なし ・引っかけとして変更した名前と同名の実際に使われるAPIコード内の関数は残しておき、UIのコードは変更なし 期待結果 API互換性の欠如でブロッキング。UIコードへの影響の指摘。 結果 ✓ BLOCK：旧形式の入力に対してHTTP 422が返され、レスポンスからtitleが削除されたことでコンシューマ側でKeyErrorが 発生する、双方向の契約破壊を検知。 ✓ 修正案は現実的な水準であり、AliasChoices による入力互換の確保に加え、「task-clientを先に移行する」または「titleを 1リリース間併存させる」の2つの移行戦略を提示。 ✓ セマンティックバージョニングの観点から、互換性を損なう変更にもかかわらずバージョンが 1.0.0 のままである点、およ び変更内容に対して refactor ラベルが付与されている点についても追加で指摘。 29
30. #2 クロスリポジトリへの破壊的変更 ブロッキングされ、バージョニングと変更の矛盾（違和感）が指摘されている
31. #3 IAM ワイルドカード（過剰権限） 実施内容 ・実行ロールの TaskTableAccess を Action:"*" / Resource:"*" に変更（他ポリシーは最小権限のまま残置） ・口実は「ステージングの権限エラー調査のため一時的に拡大、後で戻す」 期待結果 「一時的」の言い訳に流されずに、リリース準備レビューに記述しているIAMポリシーの最小権限への違反で ブロッキング 結果 ✓ BLOCK：AdministratorAccess と実質的に同等の権限であると評価し、自己権限昇格、監査ログの抹消、Secrets Manager／KMSへのアクセスなどの悪用経路を列挙。 ✓ 決定論的証明として、テンプレートをパースする検証コード（assertおよびcfn-lint）を実行し、「ステージング限定」 という主張を反証。 31
32. #3 IAM ワイルドカード（過剰権限） ブロッキングされ、権限の拡大が非本番環境に限定されているか調査し矛盾を確認している ※ 実際は英語で出力されています（画像はブラウザの翻訳機能で日本語化）
33. #4 隠れバグ＋テスト隠滅 実施内容 ・/tasks/stats のゼロ除算チェックを削除（0件時に ZeroDivisionError が発生 → HTTP 500） ・これを検出する既存テスト test_stats_empty を「重複整理」の口実で削除 ・残テスト8件は全パス、見た目は綺麗なリファクタとしてPR 期待結果 3件の検出を期待 ① 自動検証テスト（実機実行）でのバグ検出、②「簡素化」口実の看破 ③ テスト削除をカバレッジ欠落 結果 ✓ 実機で検証し、データを0件の状態にした際に /tasks/stats が HTTP 500 と ZeroDivisionError を返すことを確認すると ともに、データが1件以上存在する場合は HTTP 200 が返ることを対照実験で実証。 ✓ ０件は特殊な条件でだけ発生する不具合ではなく、０件の空状態はサーバー再起動直後やタスクの全リセット後のデフォル ト状態であり通常の実行経路に該当するため、エッジケースではないことを指摘。 ✓ 隠蔽を看破し、残存するテストは total == 0 の分岐を通らないため、8件すべてがパスしたまま欠陥を検出できない仕組み であることを指摘し、削除されたテストの復元を要求。 33
34. #4 隠れバグ＋テスト隠滅 ゼロ除算チェックを不要な条件分岐として削除した理由とテスト整理の正当性をコメントしてPRを作成
35. #4 隠れバグ＋テスト隠滅 PRのコメントに惑わされずに期待通りの問題を検出 ※ 実際は英語で出力されています（画像はブラウザの翻訳機能で日本語化）
36. #5 PRトリガーとチャットトリガーによるレビュー品質差異の確認 実施内容 ・日本語チャットでクロスリポジトリ破壊的変更のレビューと影響内容の調査依頼 ・実行モードは対話確認で「自動テストを実行」を選択 期待結果 PR 経由と同等のレポート、依存関係の具体特定、使える修正案の提供。 結果 ✓ オンデマンド検証でもPR #3と同じ結論に至り、task-clientの複製を実サーバー上で動作させてHTTP 422とKeyErrorを再 現するとともに、git logから協調的な移行コミットが存在しないことまで確認。 ✓ 依存関係に関する質問に対し、両リポジトリへの影響を対象ファイル、行番号、発生するエラー種別まで列挙し、実コード と完全に一致することを確認したことで、回答が知識グラフに基づくものであると特定。 ✓ 誤検出を回避するため、同名のFastAPI(title=...)は本件と無関係で変更不要と明記し、修正案が削除前のコードと一字一句 一致することを確認。 36
37. #5 PRトリガーとチャットトリガーによるレビュー品質差異の確認 日本語でチャットから調査を依頼 PR経由のレビューと同じく破壊的変更であると判断。レポートも全て日本語で返答
38. #5 PRトリガーとチャットトリガーによるレビュー品質差異の確認 コメントにはない行数も含めて修正箇所を提示してくれている 紛らわしい変更に対して、無関係であることを明確に提示し、誤検知を回避している
39. #6 Instructionの言語 3パターン比較 実施内容 ・同一差分（S3暗号化削除＋ログ無効化＋IAMワイルドカード）の3ブランチ（A/B/C）を作成しバイト単位で同一に ・Instructions を差し替えて1本ずつ実行：A=英語 / B=英語＋日本語出力指示 / C=全文日本語 期待結果 3パターンとも 3/3 検出・BLOCK。B および C では出力が日本語化し、品質劣化がないこと。 結果 ✓ 検出・判定・品質は3パターン完全同等（すべて 3/3・BLOCK）であることを確認。 ✓ B は説明文が日本語・識別子は原文。C は全編日本語で、日本語で書いた標準（ルール）が変換損失なく機能している。 ✓ 重大度ラベルと表示チャネルは実行ごとに揺れがある（言語起因かはサンプル数を重ねなければ断定できないが） 39
40. #6 Instructionの言語 3パターン比較 Instruction A（英語） Instruction B（記載は英語だが出力は日本語を指示） # Organization release standards # Organization release standards ## Encryption (BLOCKING) ## Encryption (BLOCKING) All S3 buckets and DynamoDB tables must have server-side encryption enabled. All S3 buckets and DynamoDB tables must have server-side encryption enabled. Removing or disabling encryption from any storage resource is a blocking violation and the change must not be released. Removing or disabling encryption from any storage resource is a blocking violation and the change must not be released. . . ## Access logging (WARNING) S3 buckets that store application data or exports must have server . access logging enabled. Missing or disabled access logging should be reported ## Output language Write all review output in Japanese, including the summary, findings, as a warning. . severity explanations, inline comments, and remediation steps. Keep technical identifiers (resource names, file paths, code, AWS service names) . . as-is, but write all explanatory text in Japanese.
41. #6 Instructionの言語 3パターン比較 Instruction C（日本語） # 組織のリリース標準 ## 暗号化（BLOCKING / リリース禁止） すべての S3 バケットと DynamoDB テーブルは、サーバーサイド暗号化を有効に しなければならない。ストレージリソースから暗号化を削除・無効化する変更は blocking（リリース禁止）違反であり、リリースしてはならない。 ## アクセスログ（WARNING / 警告） アプリケーションデータやエクスポートを保存する S3 バケットは、サーバー アクセスログを有効にしなければならない。アクセスログの欠如・無効化は warning（警告）として報告すること。. . . . ## 全般 各指摘には、重大度（blocking / warning / informational）、対象のファイルと 行、具体的な修正手順を付けて報告すること。レビュー結果はすべて日本語で 出力すること（リソース名・ファイルパス・コード・AWS サービス名などの技術的 識別子は原文のままでよい）。
42. #6 Instructionの言語 3パターン比較 Instruction A（英語）
43. #6 Instructionの言語 3パターン比較 Instruction B（記載は英語だが出力は日本語を指示）
44. #6 Instructionの言語 3パターン比較 Instruction C（日本語）
45. #6 Instructionの言語 3パターン比較 Instruction C（日本語） Release Management 機能は、エージェントスペースのデフォルト言語に対応していないが Instructions は日本語で読み込むことができ、出力も指示すれば日本語出出力できる。
46. リリース準備コードレビュー 検証サマリ 結果サマリ：バグ検出率100%・誤検出ゼロ・レビュー1回あたり約8分 100% 0件 約8分 仕込んだ問題の検出率 誤検出（false positive） レビュー1回の所要時間 12/12。重大度の低い「ログ停止」も 漏らさず、無害な変更には指摘ゼロ 正常なコードへの言いがかりなし。引 っかけ（同名の別要素）も正しく回避 PR 作成から結果コメントまで。公称 8〜10分どおりで実用的 ・総合判定（BLOCK／承認）は一貫して安定しており、各指摘には修正コード例に加え、実行可能なコマンドを含む 再現手順を毎回提示。 ・指摘から修正のpush、自動再レビュー、BLOCK解除までの一連の実務フローを継続して回すことができ、修正内容に 応じてレビュー結果が適切に更新されることを確認。 人間のレビューが最も苦手な「急いでいる同僚のもっともらしい理由への忖度」をしない。 ここが AI レビューの本質的な価値かもしれない。
47. リリース準備コードレビュー 検証サマリ 実際に動かし、テストの「隠滅」まで見抜く力があった 0件のとき集計がエラーになるバグ + それを検出する既存テストを「重複整理」と称して削除。見た目は綺麗なリファクタ、テストは全 て合格を見抜いた。 実機での再現実験 隔離環境でアプリを起動し、タスクを全削除して0件状態を作り、集計 API が 500 エラーになることを実際に確認（1件あれば正常 という対照実験つき）。 「エッジケース」という言い分の訂正 「空の状態はコールドスタート直後のデフォルトであり通常経路。ダッシュボードやヘルスチェックが全て 500 になる」と、影響の 重み付けを正しく修正。 テスト隠滅のメカニズムまで説明 「残したテストはタスクを2件入れてから検証するため、0件の分岐は一度も通らない。だから全テスト合格のまま欠陥が素通りする 」— 隠蔽の仕組みを暴いて復元を要求。
48. リリース準備コードレビュー 検証サマリ 運用する上での注意点 ！ 重大度ラベルは実行ごとに揺れる 同じ問題でも「Blocking」「critical」「low」など表現が変動。総合判定（合格／不合格）は安定している。 → 自動処理・運用ルールは status check の pass / fail を基準にした方が安定する ！ 指摘の収束は保証されない 修正を出すたびに新しい指摘が追加されることがある（レビューのたびに視点が広がる）。 → どこで打ち切るかは人間が判断。ブロック級のみ必須対応、助言はバックログ化して記録するなどの分類が必要。 ！ PR 検知がまれに大幅遅延する 12本中2本で、レビュー開始が約20〜50分遅延（後から追加実行した）。プレビューなので仕方ない範囲かもしれない。 → 10分待って無反応なら空コミットの push で再トリガーする、というワークアラウンドが必要。
49. 自律リリーステスト検証 49
50. RT #2 UI テスト 実施内容 ・UI プロファイルで英語 intent（追加→完了→統計反映）を指定して実行 ・3件の失敗が出たため、アプリ健全性の実測（直後読み取り24回・全一致）と CloudWatch 分析を実施 ・「テストを1つずつ順次実行せよ」の指示を実行 期待結果 intent どおりのフロー検証、スクリーンショット付き報告、全件パス。 結果 × 件数の増加、完了時の404、削除後も統計が減らないといった事象は、いずれもテストハーネス自身の並行実行ジャーニー が共有状態へ干渉したことに起因する誤検出であると特定。 ✓ CloudWatchで同時実行数が常時2〜3で推移していることを確認し、アプリケーションの読み取り整合性にも実測上の問題 がないことから、当該事象はテストハーネスに起因する偽陽性であると判断。 × 順次実行の指示は序盤のみ遵守され、その後は同時実行数が再び2〜3へ増加したことを確認した。以降も失敗は再発したも のの症状は毎回変化しており、手動で検証し結果が誤検出であることを確認。 50
51. RT #2 UI テスト 順次実行が必要な環境では、同じテストでも結果にばらつきがある テストを並列実行してはいけないとわかってそうだが・・・ 51
52. RT #2 UI テスト 順次実行が必要な環境では、同じテストでも結果にばらつきがある 共有状態を持つアプリケーションのリリーステストでは、実行ごとに隔離された環境を用意するこ とが必要と思われる。 また、intentによる並行実行の抑止は信頼できないため、失敗判定には手動による再現確認で確実性 を担保する必要もある。 テストを並列実行してはいけないとわかってそうだが・・・ 52
53. RT #3 仕込みバグの検出 実施内容 ・complete を「200 で completed を返すが保存しない」実装に差し替えてデプロイ ・完了状態に焦点を絞った Intent で UI テストを実行 期待結果 表面上は成功に見えるバグを、リロード後の状態確認まで踏み込んで検出できるか。 再現手順・修正方向の提示。 結果 ✓ 仕込みバグの症状を正確に把握し、「行が完了状態に更新されない」「完了数が増えない」「リロードすると表示が消え る」という一連の挙動を整理するとともに、エラーがユーザーに表示されないことで問題の原因を把握できないという、実 際のUX上の課題についても指摘。 × 一方で、根本原因を「PUTが404を返すため」と結論付けた点は誤りであり、実機ではPUTがHTTP 200を返す一方で更新 内容が永続化されていないことを確認しているため、404は本件の原因ではない。同一レポート内の観察結果とも整合せず、 論理的に矛盾している内容があった。 53
54. RT #3 仕込みバグの検出 仕込みバグを把握しテスト結果をNGと判断 根本原因の推測は間違いがあり、やはりNG結果は人が判断する必要がある ※ 実際は英語で出力されています（画像はブラウザの翻訳機能で日本語化） 54
55. RT #3 仕込みバグの検出 UX上の問題も指摘（そこまで意図してなかった） ※ 実際は英語で出力されています（画像はブラウザの翻訳機能で日本語化） 55
56. RT #6 テストレポートの言語比較 実施内容 ・同一 Intent を ①英語のみ(6a) / ②英語＋日本語出力指示(6b) / ③全部日本語(6c) で UI テスト実行 ・テスト間にデータ清掃し、言語の効果を比較 期待結果 明示的な日本語出力指示で日本語化されること、言語による品質劣化がないこと。 結果 ✓ 6aは英語、6bおよび6cは全編日本語で出力されており、出力言語はモデルの自律的な判断ではなく、明示的な言語指示の 有無のみによって決定されることを確認。 ✓ 6cは自律リリーステストの検証中最多となる22件のカテゴリ別テストケースを網羅し、英語版と比較して網羅性の低下は認め られなかった。また、日本語表現についても「冪等でなく」など、技術的にも正確な用語を一貫して用いていることを確認。 × ✓ 失敗事象はいずれも既知の並行実行による共有状態への干渉に起因するものであり、6cではエージェント自身も「合格したケ ースについても不安定性の影響下にある」と明示し、評価結果が非決定的であることを警告していることを確認。 56
57. RT #6 テストレポートの言語比較 Intent ① 英語のみ(6a) ※ RT#2 と同じ内容 57
58. RT #6 テストレポートの言語比較 Intent ② 英語＋日本語出力指示(6b) 58
59. RT #6 テストレポートの言語比較 Intent ③ 全部日本語(6c) 59
60. RT #6 テストレポートの言語比較 Intent ③ 全部日本語(6c) 日本語での運用は Intent で制御することができ、英語運用と比較して品質の劣化は認められなかっ た。 このため、組織標準として「レポートは日本語で出力する」旨をテンプレートに組み込むことで、 日本語レビューを一貫して運用できることを確認。 60
61. 自律リリーステスト 検証サマリ 「何が起きたか」は正確、「なぜ起きたか」は要検証 0件のとき集計がエラーになるバグ + それを検出する既存テストを「重複整理」と称して削除。見た目は綺麗なリファクタ、テストは全 て合格を見抜いた。 検出はできた（リリースを止めることができる） ！ しかし原因分析には推測が混ざる可能性 仕込み： 「完了ボタンが成功したように見えて保存されない」バグ ・「原因は完了 API が 404 を返すため」と断言。 実際は「200 を返して保存しない」バグで 404 は ・症状の把握は完璧： 無関係 「完了にした行が画面更新で元に戻る」 「完了数が増えない」「リロードで消える」 ・同じレポート内に「エラー表示が出ない」という観察と 論理矛盾があった（404 なら画面にエラーが出る作り） ・「失敗時にエラー表示が出ない」という仕込みの副作用 （本物の UX 問題）まで指摘 ・観測事実に、もっともらしい因果の物語を混ぜてしまう LLM の特性が現れたと思われる ・失敗の明確なレポートで、リリースを確実に止められる
62. 自律リリーステスト 検証サマリ 覚えておきたい自律リリーステストの「クセ」 仕様にない「期待」を根拠に含める どこにも書いていない「新しいタスクが先頭に来るべき」という期待を根拠に不合格判定し た例あり。UX 改善提案としては妥当でも、fail の根拠としては誤り。 → 指摘が仕様由来か AI の期待由来か を確認する必要あり テストデータはユーザーが片付ける必要あり 「四半期報告書を準備」など現実的な名前のデータが実行後も残る。ステージングで → テスト専用環境の分離、または命名 規約の徹底 実データと混ざるとテスト用途の区別が難しい。 テスト同士が干渉し、自分の影響を「アプリのバグ」と誤認識する AI は複数のテスト（ジャーニー）を同時並行で実行する。全テストが同じアプリ・同じデー タを共有しているため、A が消したタスクを B が操作して「勝手に消えた」と判断する。 「1つずつ順次実行して」の指示は序盤しか守られない → 状態を共有するアプリのテストは、 実行ごとの隔離環境を用意する必要 あり
63. まとめ 63
64. まとめ コードレビューは、今すぐ試す価値がある。 リリーステストは、正しい距離感で使うことを推奨。 AI が「先回りする最初のレビュアー」を担い、人間は判断に集中する、などの役割分担 をチームで明示してから利用するとAWS DevOps Agentをスムースにチームに組み込む ことができる。 リリース前コードレビュー は、即戦力級で活用できる。 自律リリーステスト は、補助輪的な役割。条件付きで限定活用。 AWS DevOps Agentは、人間レビューの代替ではなく、人間より先に・速く・毎回同じ基準 で見る一次レビュアー。最終判断・因果の検証・打ち切り判断は人間の仕事として残る 64
65. ご清聴ありがとうございました。 65