[レポート]Accelerating Development and DevSecOps with Amazon Bedrock and Kiroに参加してきました！ #PEX303 #AWSreInvent

クラウド事業本部運用イノベーション部の いそま です。

re:Inventにて「Accelerating Development and DevSecOps with Amazon Bedrock and Kiro」セッションに参加しました！
このセッションでは、ソフトウェア開発ライフサイクルにおけるAgentic AIの活用方法、技術的アーキテクチャ及び導入事例が紹介されました。

そもそもAgentic AIとは？という方はこちらのブログをご参照ください。
https://zenn.dev/nttdata_tech/articles/925b2510ccf517#agentic-aiとは

目次

• セッション概要
• 従来型ソフトウェア開発ライフサイクル(SDLC)の課題
• 従来型ソフトウェア開発ライフサイクル(SDLC)におけるAgentic AIの影響
• エージェント型AIとロールベースアーキテクチャパターンによるSDLCの構築
• まとめ

セッション概要

タイトル
Accelerating Development and DevSecOps with Amazon Bedrock and Kiro

スピーカー

Dana Varievalen（AWS EMEA Partner Solutions Architecture Lead）
Fabio（AWS Solutions Architect
George Fenine（CTO, ZBR Clouds / AWS Ambassador）

テーマ
AIエージェントを活用したソフトウェア開発ライフサイクル(SDLC)全体の自動化

※ 後ろの席に座ってしまいかなり画質が荒くなっているため、これ以降の項目はYoutubeのスクショを使用します。

従来型ソフトウェア開発ライフサイクル(SDLC)の課題

現代のSDLCについて、セッションの冒頭でまず示されたのは「開発チームの生産性低下」という現実でした。
多くの開発チームが繰り返しの作業や手動対応、ドキュメント不足への対処に時間を費やし、その結果として生産性が失われている、という指摘です。

また、以下のようなデータを用いた分析がされていました。

1. エンジニアの稼働実態
   • ソフトウェアエンジニアの78%が、業務時間の少なくとも30%を反復的な手作業に費やしている
2. 生産性低下による損失（ex. 250人規模のチーム）
   • 手作業による直接的損失
     • 年間約800万ドル(約12億円)。これはエンジニア1人あたりの平均年収を10万7,000ドル(約1,605万円)とした計算に基づく
   • 非効率性と負債による損失
     • 環境の切り替えや技術的負債により毎週20%の時間が失われ、年間約540万ドル(約8.1億円)の損失が発生
   • 合計損失額 ➡️ 年間約1,340万ドル(約20.1億円) +α タイトな納期や障害対応による「燃え尽き症候群」の危機が、持続可能な開発を阻害している

セッション全体を通して強調されていたのは、「現在のやり方は持続可能ではない」という点です。そして、その課題に対する一つの解として提示されたのが、Agentic AIを活用したSDLC全体の再設計です。

従来型ソフトウェア開発ライフサイクル(SDLC)におけるAgentic AIの影響

とある予測によれば、2028年までにエンタープライズ・ソフトウェア・エンジニアリング・チームの90%がAIコードアシスタントを採用するとされています。

2024年初頭の予測では14%だったのにも関わらず、わずか4年で6倍以上に急増するこの潮流において、AIの導入は「選択」ではなく、競争力を維持するための「不可避」な戦略といえます。

この変革の核となるのが、単なる応答生成を超えた「Agentic AI（エージェント型AI）」です。

生成AIとAIエージェントの違い

従来の生成AI（One-shot interaction）とAgentic AIの違いをまとめた表です。
Agentic AIは、SDLCでは特に、要件定義〜運用まで横断的に自律実行をすることができます。

機能・特性	従来の生成AI (One-shot Interaction)	Agentic AI (Autonomous Systems)
動作原理	プロンプトに対する一回限りの回答生成	自律的な推論、計画、タスクの実行
相互作用	人間の指示に対しAIが回答するのみ	ツール（Jira, Confluence等）と自律連携
コンテキスト保持	単発のやり取りが中心	短期・長期メモリによる文脈の永続的保持
SDLCでの役割	部分的なコード生成、特定質問への回答	要件定義から運用までを自律的に横断
複雑なタスク	困難（人間による細分化が必要）	自律的にタスクを分解し、反復的に解決

エージェント型AIとロールベースアーキテクチャパターンによるSDLCの構築

AWSの3つのアプローチ

※ 「ロールベースアーキテクチャパターン」とは、システムやプロセスを役割（ロール）ごとに分割して設計するアーキテクチャの考え方

個別のAIツールを場当たり的に導入することは、断片化された計画立案やツール間のデータ分断を助長し、セキュリティやガバナンスの欠如を招きます。組織全体でスケールさせるには、一貫した「プラットフォーム駆動型アプローチ」が必要です。

本セッションでは、AWSが提供するAgentic AI実装のための3種類のアプローチが紹介されました。

1. Agent搭載アプリ

• Amazon Quick Suite
• Kiro
• Kiro CLI

2. フルマネージド

• Amazon Bedrock Agents

3. フルカスタム

• Strands Agents
• Nova Act SDK
  

また、1.〜3.の土台となるのが、高性能なAIエージェントを構築・展開するためのフルマネージドな基盤 Amazon Bedrock AgentCore です。

Amazon Bedrock AgentCoreについては、こちらのブログに解説がありますのでご参照ください。
https://dev.classmethod.jp/articles/amazon-bedrock-agentcore/#Amazon%2520Bedrock%2520AgentCore%25E3%2581%25A8%25E3%2581%25AF

プラットフォーム型SDLCアーキテクチャ

ここからが、本セッションで最も重要と感じたポイントになります。

SDLCの各役割（ペルソナ）ごとにエージェントを最適化し、MCPやツールを切り替えるプラットフォーム設計をすることが重要です。

単一の万能AIを導入するのではなく、役割ごとに使うツール・接続先・権限を変えることがプラットフォーム設計思想の中核となります。

なぜペルソナ別に分ける必要があるのかについてですが、それは、SDLCには多様な役割が存在するからです。
ex.ビジネスアナリスト,ソリューションアーキテクト,開発者,DevSecOps,運用担当

そして、ペルソナそれぞれが扱う情報、利用するツール、必要な権限はまったく異なります。

もし単一のエージェントが全情報・ツールにフルアクセスしてしまうと…

• セキュリティリスクが高まる
• 不要な情報までコンテキストに入り推論が不安定になる
• トークン消費が増大する
• ガバナンスが困難になる

つまり「何でもできるAI」はエンタープライズでは危険であるため、

• ペルソナ単位でMCP接続先を制御
• 権限を限定し、必要な知識だけを渡す

というような、プラットフォーム設計が必要となります。

プロジェクト共通ナレッジベース

プラットフォーム型SDLCを成立させるうえで、最も重要な構成要素がプロジェクト共通ナレッジベースです。
単に情報を保存する場所ではなく、SDLC全体の「文脈」を一元管理し、各ペルソナのエージェントを正しく動かす中枢神経として機能します。

本セッションではプラットフォーム型SDLCの中核として、Amazon Bedrock Knowledge Bases + Amazon S3 + Vector Databaseが紹介されました。

このナレッジベースには、以下情報が蓄積されます。

• ビジネスアナリストが作成した要件
• アーキテクトが作成した設計情報
• OpenAPI仕様
• 各ペルソナが生成した成果物

そして各エージェントは、MCP経由でこのナレッジベースを参照します。

ここも非常に重要な点であり、セッション内でも以下のように言及されていました。

エージェントは authorized information のみを参照することで、ハルシネーションを防ぐ
分離されたエージェントを動かすには、統合された知識基盤が必要である

つまり、インターネット上の曖昧な情報ではなく、プロジェクト内で確定した情報のみを根拠に推論する設計を作ることができます。

まとめ

本セッションでは、Amazon Bedrock と Kiro を活用したAgentic AIによるソフトウェア開発ライフサイクル(SDLC)全体を加速させる方法が紹介されました。
単なるコード生成ではなく、要件定義から運用までを横断するアプローチが示された点が特徴的でした。
このセッションが伝えていたのは、「AIは単なる開発支援ツールではなく、開発プロセスそのものを再設計するための基盤である」ということではないかと考えています。

今後のエンタープライズ開発において、こうしたアプローチがどのように広がっていくのか、今後も注目していきます。