6月25日の AWS Summit Japan に参加して、一番強く感じたのは「生成AIそのもの」ではなく、その一歩先の エージェンティック AI（AIエージェント）を前提にした”基盤づくり” が、完全に主役になっていることでした。
「どのモデルを使うか」から、「自社データと業務に最適化されたエージェントをどう作り、どう運用するか」へ。
そのために、いくつかの AWS サービスが、ほぼすべての時間帯のセッションで繰り返し登場していたのが印象的でした。
この記事では、当日多く取り上げられていた主なサービスと、各サービスが担う役割、そして実際にセッションに参加して感じた「AWS の AI 戦略の今」を、参加者目線でまとめます。
Amazon Quick / Amazon Connect Customer / Amazon Bedrock AgentCore・Knowledge Bases / Amazon Nova Forge / S3 Vectors・DynamoDB GSI / AWS Transform・AI-DLC・Kiro
1. Amazon Quick：BI から「エージェント×アクション基盤」へ
午前・午後を通して一番よく耳にしたのが、Amazon Quick でした。
単なる「新しい BI ツール」というより、生成AIとエージェントを組み合わせた “Agentic BI プラットフォーム” という位置づけです。
会場で語られていた Amazon Quick の姿
- 社内のドキュメント、データベース、メール、Slack、ダッシュボード、Jira など、バラバラな情報源を横断して検索・質問できる
- 「チャットで聞いて終わり」ではなく、そのまま業務アクションまで実行できる
- Web やモバイルだけでなく、Slack や Microsoft 系ツールとも連携し、「どこで働いていても一緒にいる AI チームメイト」というコンセプト
特に印象に残ったのは、SaaS プロダクトに Amazon Quick を埋め込むセッションです。
SaaS の中に「Chat Agent 付き BI」を組み込み、ユーザーが自然言語で質問し、そのまま分析結果や次のアクションを返してくれるアーキテクチャが紹介されていました。
裏側では、Amazon Quick が生成AIと連携し、ユーザーの質問を理解し、必要なデータソースへ問い合わせ、アクションを組み立てている形です。
また、「分析の民主化は幻想だったのか？」という挑発的なタイトルのセッションでは、
- 従来の「ダッシュボードを見て自分で考えてアクションする」スタイルでは、9割のユーザーは動けない
- だからこそ、エージェントが”インサイトから行動まで”をつなぐ必要がある
というメッセージが強調されていました。ここでも中心にいたのが Amazon Quick の Agentic AI 機能でした。
2. Amazon Connect Customer：コンタクトセンターに常駐する AI エージェント
顧客接点系で目立っていたのが、Amazon Connect Customer です。
ここでもキーワードは「エージェンティック AI」と「人間オペレーターとの協調」でした。
セッションの中で語られていたポイントを整理すると、Amazon Connect Customer は主に次のような役割を果たします。
- すべての顧客接点（電話、チャット、他チャネル）に AI をシームレスに統合
- 日常的な問い合わせを AI エージェントが一次対応し、必要に応じて人間オペレーターへ適切にエスカレーション
- 過去のコンテキスト（会話履歴や顧客情報）を維持しながら、会話を引き継いだり、後続のアクションを自律的に実行
特に印象的だったのは、「エージェント単体の精度」ではなく、エージェントと人間オペレーターを含めたエンドツーエンドの体験設計と、その評価方法まで踏み込んでいた点です。
| 議論されていたテーマ | 内容 |
|---|---|
| エージェントの構築方法 | どのように設計・学習させるか |
| パフォーマンス評価 | どの KPI で測るか |
| 自律化の範囲 | どこまでを自律的に任せ、どこからを人間が監督すべきか |
背後にはもちろん、Amazon Connect と、生成AI（推奨としては Amazon Bedrock 系のモデル群）が存在しており、会場全体として「生成AI＋業務システム＋オペレーター」がひとつのワークフローとして設計されつつある空気を感じました。
3. Amazon Bedrock と AgentCore / Knowledge Bases：エージェント・RAG・ガバナンスの中核
直接「Bedrock の名前」をタイトルに掲げていないセッションでも、内容としては Bedrock が前提になっているものが非常に多くありました。
（1）エージェントを組み立てる”中核”としての Bedrock
具体的な事例の”モデル側の土台”として、Amazon Bedrock が使われている構成が繰り返し紹介されていました。
- 「購買 AI エージェント」を内製し、EC サイトに組み込んだ事例
- 既存の検索 API と LLM を組み合わせたハイブリッド設計
- 検索結果ゼロ件を劇的に減らしつつ、レスポンスを 30 秒から 15 秒へ短縮
単に「チャットボットを作る」というレベルではなく、ビジネスロジックを分層化した多層アーキテクチャ、既存 API 群と LLM をどう編成してエージェントにするか、レイテンシとコストの最適化、といったところまで踏み込んだ話が多かったのが特徴的でした。
（2）Bedrock AgentCore / Knowledge Bases：エージェントの”骨格”と”長期記憶”
エージェンティック AI のためのデータ活用ガイドのセッションでは、MCP（Model Context Protocol）や RAG（Retrieval Augmented Generation）をベースにしながら、以下の組み合わせが紹介されていました。
- Amazon Aurora や Amazon OpenSearch Service を使ったデータ基盤
- Amazon SageMaker Unified Studio による分析・処理・ストリーミング
- それらをまとめあげる Amazon Bedrock AgentCore と Knowledge Bases
データレイク、データガバナンス、データ品質から始まり、エンドツーエンドなエージェントアプリケーションまで含めて「どう作り、どう運用するか」の話に完全にシフトしていました。Bedrock AgentCore と Knowledge Bases は、エージェントの骨格を定義するレイヤーと、データを”AI が扱える形”で長期的に保持し RAG に供給するレイヤーとして位置づけられています。
4. Amazon Nova Forge：汎用性能を保ったままドメイン特化モデルを作る
生成AIモデルそのものにフォーカスしたセッションで象徴的だったのが、Amazon Nova Forge です。
ここで語られていたテーマは、とても現場感がありました。
- 汎用 LLM で足りる領域と、どうしても精度が出ない領域
- ファインチューニングで間に合うケースと、どうしてもスクラッチ（ドメイン特化基盤モデル）が必要なケース
- ドメイン特化モデルを作るときに、汎用性能を犠牲にしないためのアプローチ
Amazon Nova Forge は、汎用性能を維持しつつ、特定ドメイン向けに基盤モデルを鍛えるためのサービスとして紹介されていました。研究機関の事例なども交えながら、次のような具体論が多く語られていました。
| テーマ | 内容 |
|---|---|
| データ収集 | 9 億件を超えるデータ収集の実際 |
| 壁と突破口 | 品質設計・分散学習・評価設計の壁 |
| AWS との協働 | AWS エンジニアとの協働で何が変わったか |
個人的には、どこかで”自分たちのモデル”という選択肢を考え始めるフェーズに来ている、という空気を感じました。そのときの選択肢として Nova Forge が提示されている、という印象です。
5. データ基盤サービス群：S3、Aurora、OpenSearch、DynamoDB などの”AI前提アップデート”
エージェントやモデルの話と同じくらい、会場で何度も出てきたのがデータ基盤系のアップデートです。
Amazon S3：ストレージから「RAG／ベクトル検索対応のAI基盤」へ
S3 の最新機能として紹介されていたのは次の4つです。
| 機能 | 概要 |
|---|---|
| Amazon S3 Tables | Apache Iceberg テーブルをフルマネージドで扱える |
| Amazon S3 Vectors | ベクトル検索をフルマネージドで提供（RAG のコア部分） |
| S3 Metadata | リアルタイム検出を可能にする |
| S3 Express One Zone | 低レイテンシなストレージアクセス |
特に S3 Vectors は、「ドキュメントを S3 に保存する → そのままベクトル検索（＝RAG のコア部分）までマネージドでやってくれる」という構図で説明されていて、S3 が完全に AI / RAG 前提で進化していると強く感じました。
DynamoDB：GSI マルチキーサポートで、エージェントのメタデータストアとしても進化
DynamoDB のセッションでは、グローバルセカンダリインデックス（GSI）のマルチキーサポートによって、これまで複雑だったインデックス設計がどのように変わるか、新しいクエリパターンにどう対応できるかが詳しく紹介されていました。
直接「生成AI」とは言っていないものの、エージェントのメモリやセッション情報、メタデータストアとして使うケースを想像すると、非常に重要なアップデートだと感じました。
Aurora や OpenSearch、データレイク全体の設計など、ほぼすべてが「AI 利用を前提としたデータ基盤」として語られていました。
6. AWS Transform / AI-DLC / Kiro：AI 駆動開発とマイグレーションの新しいかたち
開発・移行まわりでは、「AI による支援」から一歩進んだ世界観が提示されていました。
AWS Transform：エージェントによるマイグレーション加速
AWS Transform や AWS Transform for VMware のセッションでは、複数の AI エージェントが協調して大規模移行を進める像が語られていました。
- ディスカバリーエージェントがワークロードや依存関係を分析
- 計画エージェントが最適な移行計画を立てる
- ネットワーク変換エージェントが VMware のネットワークを AWS 用にマッピング
- サーバー移行エージェントがプロセスそのものを短縮
ここでも生成AI（LLM）自体より、「それをどうエージェント群として編成するか」が主役になっていたのが印象的です。
AI-DLC / Kiro：AI を前提にした開発ライフサイクル
AI 駆動開発ライフサイクル（AI-DLC）や、ソフトウェア開発エージェント Kiro のセッション・ワークショップでは、開発フローそのものを AI 前提でもう一度設計し直すアプローチが共有されていました。
| フェーズ | AI の役割 |
|---|---|
| Inception（企画） | 要件整理・ドキュメント生成を AI が支援 |
| Construction（実装） | チケット・コード・レビューを AI が横断 |
| Operations（運用） | 永続的なコンテキストを保持しながら人間と協調 |
実際に Kiro を触るワークショップでは、チケットを切る・ドキュメントを書く・実装と改善を回す、といった普段の開発プロセスの中に AI エージェントが”チームメイト”として入り込んでくる感覚を、かなりリアルにイメージできました。
7. まとめ：AWS の AI は「モデルの話」から「エージェントと基盤の話」へ
1 日を通してセッションに参加して感じた、AWS Summit の大きなメッセージを自分なりに整理すると、こうなります。
- 生成AI（LLM）単体の話は、もはや当たり前になりつつある
- これからの焦点は、「自社データと業務に最適化されたエージェントをどう構築し、どう運用するか」
その主役として、会場で繰り返し登場していたサービスを整理するとこうなります。
| サービス | 役割 |
|---|---|
| Amazon Quick | Agentic BI / AI チームメイト |
| Amazon Connect Customer | コンタクトセンター向けエージェント基盤 |
| Amazon Bedrock AgentCore / Knowledge Bases | エージェントと RAG の中核 |
| Amazon Nova Forge | ドメイン特化基盤モデルの構築 |
| S3 Vectors / DynamoDB マルチキー GSI | AI 前提のデータ基盤 |
| AWS Transform / AI-DLC / Kiro | AI 駆動の開発・移行 |
会場全体の空気として、「生成AIを触ってみるフェーズ」から、「エージェントと基盤を整えて、本番で当たり前のように使うフェーズ」に完全に入りつつあることを、肌で感じる 1 日でした。
どの業務にエージェントを入れるべきか、そのとき必要なデータ基盤やガバナンスはどうあるべきか──今日見た各サービスと事例を頭の中で組み合わせながら、具体的な設計イメージを描いていくことになりそうです。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
