powered by TechFeed
表示モード
Deep Dive

AIはコーディングだけじゃない — 要件定義・グルーミング・QA・レビューを5つの専門エージェントで自動化したVeriskの事例

11月6日、AWSが「Reinventing software delivery with AI-SDLC on Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、VeriskとAWSが共同で構築した、要件定義からQAまでの全工程をAIエージェントが担うソフトウェア開発ライフサイクル(AI-SDLC)の実装事例について詳しく紹介されている。AIはコーディングだけじゃない――残り4工程を専門エージェントが担うAIコーディングアシスタントの普及で「開発」工程の自動化は進んだ。しかし要件定義・グルーミング・QA・コードレビューの4工程は依然として手作業のままというチームが大半だ。Veriskが直面していた課題は具体的だ。

11月6日、AWSが「Reinventing software delivery with AI-SDLC on Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、VeriskとAWSが共同で構築した、要件定義からQAまでの全工程をAIエージェントが担うソフトウェア開発ライフサイクル(AI-SDLC)の実装事例について詳しく紹介されている。

AIはコーディングだけじゃない――残り4工程を専門エージェントが担う

AIコーディングアシスタントの普及で「開発」工程の自動化は進んだ。しかし要件定義・グルーミング・QA・コードレビューの4工程は依然として手作業のままというチームが大半だ。

Veriskが直面していた課題は具体的だ。

  • 要件定義:受け入れ条件が不完全なチケットが多く、何度も確認往復が発生
  • グルーミング:機能をタスクに分解するだけでスプリント計画に数時間を費やす
  • QA:テスト計画の作成に1機能あたり3〜4時間、自動化セットアップに1〜2日
  • コードレビュー:レビュアーの知識や空き状況によって品質にばらつき

これらの非効率を解消するため、Veriskは5つの専門エージェントをAmazon Bedrock AgentCore上に構築した。Amazon Bedrock AgentCoreは、エージェントのホスティング・メモリ管理・ツール統合・オブザーバビリティを統合的に提供するAWSのマネージドプラットフォームであり、2025年に一般提供が開始された比較的新しいサービスだ。

5つの専門エージェントが分業する構造

各エージェントは独立して動作し、明確なトリガー・入力・出力形式・人間レビューのチェックポイントを持つ。ライフサイクル全体を管理する中央オーケストレーターは意図的に採用していない。各工程は時間的に分断され、異なる担当者が関わり、AIでは予測できない人間の判断を挟むためだ。

フェーズ1:プランニング

Requirements Agent(要件改善)
Jiraチケットが作成・更新されると起動。受け入れ条件の不足、曖昧な記述、エッジケースを検出して改善案を提示する。AgentCore Memoryを使って会話コンテキストを保持し、プロダクトオーナーと対話しながら反復的に要件を磨ける点が特徴だ。AgentCore Memoryは、通常のBedrockモデル呼び出しでは会話ターンをまたいで状態を持てないのに対し、セッション間のコンテキスト保持をマネージドで実現するコンポーネントである。これにより、複数回のやり取りを経て要件を段階的に精緻化するワークフローが成立する。最終的な承認はプロダクトオーナーが行う。

Grooming Agent(技術的詳細化)
要件承認後、リポジトリ構造とAPI仕様を参照してサブタスク分解・ストーリーポイント見積もり・依存関係マッピング・技術仕様ファイル(spec.md)を生成する。開発者はゼロから設計を考えるのではなく、このアウトプットを起点にできる。

フェーズ2:コンストラクション

Developer Agent(実装)
Claude Code on Amazon Bedrockを使用し、コーディング規約の読み込み、タスク分解、フルスタック横断のコード生成を行う。既存リポジトリのパターンを参照してコードの一貫性を保つ。コードのコミット判断は開発者が行う。

Code Review Agent(レビュー)
プルリクエスト作成をトリガーに、差分をspec.mdおよびプロジェクト標準と照合してフィードバックを生成。指摘事項はCritical・Major・Minorで重要度分類され、コード品質ツールの結果とも統合される。最終承認権限は開発者が保持する。

フェーズ3:品質保証

QA Agent(2段階動作)
まず受け入れ条件に紐付いたテスト計画を生成(ハッピーパス・ネガティブケース・境界値・インテグレーション動作を網羅)。QAエンジニアの承認後、プルリクエストのマージを経て第2段階に進み、Bruno(オープンソースAPIクライアント)のコレクションとApache JMeterのパフォーマンステスト計画を自動生成する。

計画→自動化を2段階に分けたのは意図的な設計だ。検証済みのロジックに基づいてテストを生成することで、生の要件から直接自動化して不整合が生じるリスクを回避している。

MCPで既存ツールに「乗っかる」統合設計

ツール統合にはModel Context Protocol(MCP)を採用。MCP Gatewayを通じて、JiraリーダーライターやAPIスペックリーダーなど各ツールへの標準インターフェースを提供する。

この設計の利点は明確だ。エージェントの推論ロジックとツール実装が分離されているため、新ツールを追加してもエージェントのコードを変更不要。MCP登録を1箇所で行えば全エージェントが即座に使えるようになる。

また、VeriskはAtlassian Forge UIをJiraに統合し、エージェント操作をJira画面内で完結させた。エンジニアは新しいツールを学ぶ必要なく、普段のJira操作の延長でAIエージェントを利用できる。

保険業界ならではの「監査証跡」設計

Veriskが保険会社向けデータ分析企業であることは、このアーキテクチャ設計に直接影響している。すべての工程で必須の人間レビューチェックポイントを置く設計は、工学的品質の維持だけでなく、SOX法コンプライアンスや州保険監督機関が求める監査証跡を自然に生成する仕組みでもある。ポリシー価格算出・クレーム判定・リスクモデルに影響するソフトウェア変更には規制上の証跡が必要であり、このアーキテクチャはそれをワークフローの副産物として実現している。

技術だけでなく「働き方」の再設計も必要

記事が強調するのは、AI-SDLCは技術的な課題より組織的な課題の方が大きいという点だ。

  • 開発が加速したとき、現行のスクラムのスプリントサイクルは最適か
  • バックログリファインメントやデモの頻度を上げるべきか
  • エンジニアには深い専門性と横断的スキルを持つT字型人材への移行が求められる
  • 評価指標も「速度」だけでなく、開発者生産性・AIインフラコスト・工学品質・ROIを含む新たな軸が必要

AIエージェントをエンジニアの代替として導入するのではなく、能力を増幅するツールとして位置付けることが採用成功の条件だと記事は述べている。

詳細はReinventing software delivery with AI-SDLC on Amazon Bedrock AgentCoreを参照していただきたい。