幕張メッセで開催されたAWS Summit 2026に参加したので、そこでのメモや所感などをまとめます。
1日目
参加セッション
- 生成 AI モデルを選ぶ技術 - モデル選択のフレームワーク -
- Amazon Bedrock AgentCore を活用したエンタープライズ Agentic RAG の実装解説
- Amazon S3 の非構造化データを Amazon SageMaker Catalog で AI-ready な資産に変換する
- AWS Infrastructure as Code : 2025 年主要アップデートの振り返り
生成 AI モデルを選ぶ技術 - モデル選択のフレームワーク -
2025年度より私のチームではRAGのシステム構築に取り組んでおり、一度システムを構築したものの、選択したモデルと相性が良くなかったようで望んだ性能が出ないという悩みがあり、なにかヒントになるものがあるかもと思い聴講しました。
聴講メモ
生成AIのモデルって沢山あるしすぐに新しいものが出るから、人の手じゃなくて選ぶ方法がほしいですよね。
ちなみにBedrockは自社でファインチューニングしたモデルも使えます。
以下の3点で選定していく
- Identity: 候補の特定
- Evaluate: 評価
- Optimize: 最適化
## Identity: 候補の特定
1. モダリティ（モデルが受ける入力と出力。画像はあるのか？とか）で絞り込む
2. ベンチマークを確認
Artificial Analytics（AWS外部のツール）が便利。知能、速度、価格とかで比較できる。自分たちの目的に応じて調べられる。
3. モデル固有の強みを考慮する
自律的に動けるか？カスタム性は？等の観点を見る。
## Evaluate: 評価
とにかく速く、がテーマ。
やることとしてはゴールデンデータセット（正解と問いのセット）を作って評価する。
しかし人手で作ると網羅性の問題や似たパターンになりがちな問題、事実確認の負荷の問題から良いデータセットを作るのは難しい。
そこで以下を使うと便利。人間はこれらにフィードバックを入れる。
- ユーザーシミュレーターエージェント（問いを投げる）
- タスクエージェント（回答を作る）
- 批評エージェントを使う（回答を採点する）
ゴールデンデータセットで測るものとは？
- 運用メトリクス：本番で動かした基本性能。コスト、レイテンシ、スケーラビリティ等。
- 包括的な評価メトリクス：どれだけ良い回答をするか。品質、スタイル、責任を持った回答、カスタムメトリクス等。
各メトリクスの評価はどうするのか？
プログラマティックにやったり、人手でやったり、LLM as a Judge（品質評価）等の方法がある。
Bedrockのモデル評価ですべてカバーできる！
エージェント自体の振る舞いは正しいのか、という観点も必要。
出力だけ見たら◯だが、手順的には☓というケースもある。
そういう場合は期待する手順をゴールデンデータセットに追加してやると良い。
Amazon Bedrock AgentCore evaluationsを使えばエージェントの品質やパフォーマンスを評価して改善に取り組むこともできる。
## Optimize: 最適化
- モデルカスタマイズ
- 自社データでモデルをファインチューニングする
- プロンプトキャッシング
- 長くて複数回読み出すコンテキストをキャッシュさせて、再計算をスキップする
- サービス階層
- パラメータの切り替えで応答速度とコストバランスを最適化する
モデルの選定というよりは、今構築しているシステムの評価という点で参考になりそうでした。
今後の取り組みとして、利用者へのアンケート以外での評価指標も欲しくなってくるかもしれないと考えていたので、Evaluateの段で話されていた内容を参考に評価をしてみても良いかもしれません。
Amazon Bedrock AgentCore を活用したエンタープライズ Agentic RAG の実装解説
まさにRAGを構築しているところなので、何かより良くするためのヒントとして得るものがないかという期待で聴講しました。
聴講メモ
AIエージェント、RAGシステムの構築をする現場としてよくある下記のような課題について解消したい。
- 的はずれな回答
- コストやレイテンシーが上がっている
- PoCから先に進むのが難しい
## コンテキストエンジニアリング
コンテキストロットの増大：コンテキストウィンドウに含まれるトークン数の増大に伴って、正確な情報の想起力が低下する。
最小限のトークンを集めたセットを用意することで解決できる。
とにかく詰め込むのではなく、最小で高品質なデータを用意することが大事。
## メモリの組み込み
短期/長期メモリを組み込んで、会話の永続化をする。
AgentCore memoryを使うと良い。
チャット内容やセッション状態を保存できるので、使うほどに育っていくイメージ。
短期メモリと長期メモリをうまく使い分けることが重要だが、AgentCore memoryはそのあたりは自動。
また、ユーザー間で情報が混ざることはない。
実際にデモしながらのセッションでした。
実装例は全てPythonだったので、TypeScriptで構築している私のチームには直接は持ち込めないが、実装量としてはかなり軽そうでした。あれだけの実装で実現できるのであれば自チームに取り込むのも難しくないかもしれないです。
Amazon S3 の非構造化データを Amazon SageMaker Catalog で AI-ready な資産に変換する
RAGを構築する中で少しでもデータソースを増やしたいと思い、何かしらそのヒントとならないかと思い聴講しました。
聴講メモ
AIエージェントにガバナンスを維持しつつ、データをなるべく色々アクセスさせたいというモチベーション。
## 非構造化データの処理
`メタデータ抽出→変換・正規化→検索可能化→分析・推論`の流れ。
この過程で処理をかけていくことで、扱いやすい形になったりする。
エージェントを使うと複数モーダルを横断検索することができる。
けどこれを実現するにはデータ整備が要る。
下記のあたりを整えないと、エージェントがうまく動かない。
- データコンテキスト
- データへのアクセス
- データの成熟品質
## Sagemakerでコンテキストまわりが改善できるかも
S3とかのデータをカタログ化できるもの。OracleDBなんかも扱える。
なお、カタログ化については人間がメタデータを書く。タグ等も事前に人手で用意して選ぶ。
データセットのアクセス権限管理もできる。
Sagemaker Unified StudioからBedrock等向けにナレッジベースを作成できる。
裏はOpenserch Serverless。
## ほか
Bedrock Guardrailで根拠チェックというのができて、ハルシネーションのフィルタリングができる。
なお日本語はまだ対応されていない…。
画像や図表の扱い等について、良い方法が得られたりするかなと期待しましたが、ちょっと想定していたのとは異なる内容でした。
またGuardrailは既に利用しているので、ハルシネーションのフィルタリングができるのは嬉しい！と思ったが日本語は未対応ということで残念でした。ぜひ今後対応されるのを待ちたいところです。
AWS Infrastructure as Code : 2025 年主要アップデートの振り返り
普段インフラの構築/管理業務をする中でまさによく触れるものなので、何か知らない情報があるかもしれないということで聴講しました。
聴講メモ
## IaCコーディング
使うリソースを決めて、webでドキュメントを読んでいくというなかなか手間のかかる工程が一般的。
AWS Toolkit Pluginを入れればIDE内で完結できる。
ドキュメントも見れるし、構文エラーチェックもできる。
## IaCデプロイ
CDKデプロイ→エラー→ロールバック→修正→CDKデプロイ→… という長いループがよくある。
デプロイしないとわからないことも多かった。
そこで変更セットの作成時にわかるといった、早期エラー検知のアップデートが入った。
これについてはこれからも取り組んでいく。
## IaCドリフト管理
IaCで作成→マネジメントコンソールから修正 といった手順を踏んだ時。
「ドリフト対応変更セット」で現状と前の状態のコードを比べて同期することができる。
1. IaCに保持したい差分だけを記載する(ここは人手で頑張る)
2. ドリフト対応変更セットを作る
3. あとはAWS側がよしなにしてくれる！（保持したくないものはコード通りに巻き戻される）
## IaCリファクタリング
CDKのL1からL2にしたいとか、整理したいといった場合に、物によってはリソースを作り直しされてしまうケースが有る。
そういうときは `cdk refactor` で論理ID/物理IDの置き換えだけが走って上手いことしてくれる。
尚まだプレビュー段階。
## コンストラクトの開発
CDKで書こうにもまだL1しか実装されていないよ、という場面。
CDKミックスインライブラリでL1とL2のカスタムコンストラクトを混ぜて使うことができる。
## コンプライアンスフィードバックの遅延
設定に問題があっても、デプロイされたあと時間が経ってからチェックでようやく気付ける…みたいなラグがある。
- Cfn Hook：デプロイまでの段階で呼び出して、フィードバックをかけることができる
- コントロールカタログ：フックを仕掛けられるので、早期発見ができる
## アカウントのベースライン化
IaC化するのが良いが、デプロイ順序の問題が発生することが多い。
スタックの依存関係を書くことができるようになった上、それをアカウントごとに強制するように設定できるようになった。
## IaCとAI
AWS IaC MCPサーバーがある。
ナレッジ、トラブルシュート、検証を提供してくれる。
ドリフト管理については以前から知っては居ましたが、やはり「現状をコードに起こしてくれる」とまでは行かないようなので、私の現場ではあまり活躍の機会はないかもしれないと思いながら聞いていました。
そして cdk refactor についてはもう少し早く知っていれば、既存の実装を大量にCfnからCDK化する場面があったので役立ったかもしれないと思いました。次の機会があれば使ってみたいところです。
その他
企業ブースでやっていたLTなども聞いたりしました。
クラスメソッドさん：暗黙知を資産にする
- ハイパフォーマンスを出している人
- 色々質問したい人
という人居ますよね。そういう人の知識を活用しよう！という話。
まずはインタビューする。
当たり前にやっていることって無自覚でやっていることが多いので、切り口なしに文書化は難しい。
インタビューして聞いたことをデータ化し、それを元にその人AI化。これをツールにしました。
「ghoost」というツール。
音声から文字起こし→分析→AI化 といったことができる。
データとしては、本人ぽさが残るように「あー」とか「えっと」とかも残すなどの工夫をして、よりその人っぽいAIを実現できるようにしました。
社内の「いつもよく質問される人」の知見をいかに共有財産にするかというところで悩みがあったので、聞かせていただきました。
やはりインタビューしてデータ化する等こちらからアプローチしていくしかないのだな、というのが学びでした。実際の他社の事例を聞けたのがよかったです。
2日目
参加セッション
- スペシャルセッション : AI エージェントが変える企業の未来 ─ 構築から運用まで、ビルダーと創る自律型 AI の実践
- Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－
- 大規模障害から考える、AWS 上で備えるべきレジリエンスの実践
- Agentic RAG が切り開く製造現場語理解の新たな可能性
スペシャルセッション : AI エージェントが変える企業の未来 ─ 構築から運用まで、ビルダーと創る自律型 AI の実践
聴講メモ
## Nitroシステム
AWS独自のコンピュート基盤→これがコンピューティングインスタンスの簡単な用意に役立つ。
## チップ開発
チップ開発も注力している。
Graviton5：エージェンティックAIにも良いように作っているチップ
Tranium：AIチップ。Bedrockとかは全てこれで動いている。
> ■Anthropic
> ClaudeにはAWSの環境が寄与している。
> AIチップ開発を一緒にしたりもしている。
## セキュリティ
自動で未知の脅威をピックしたりするようなことにも取り組んでいる。
Continium
脆弱性をマシンスピードで素早く検知してくれる
Bedrock
これで色々AIツールを作ることができる。
推論をゼロから見直して改善した。
（優先度を利用者が書けるらしい）
利用者間で足を引っ張られないように、利用者単位で処理の重さが影響しないようにそれぞれに専用環境を用意している。
モデルがデータを読むときもセキュリティが重要。
### 生成AIを本番導入することについて
ガバナンス、権限、内容の質、大量アクセス等の課題がある。
これらはAgentCoreで解決できる。
高性能でセキュアなエージェントを組むことができる。
> ■オムロンサイニックス
> 実験サイクルが結構重い。
> エージェントAIとフィジカルAIで高速化していく。
> AgentCoreならモデルを変えての比較なんかも楽にできる。
## フィジカルAI
ビジョン＋指示で、AIで処理しつつ動くロボティクス。
従来のロボットとは違い、自ら考えて動くロボット。
仮想環境も含めてデータ収集をしている。
> ■ファナック
> ロボットの監視/運用ネットワークやアプリケーションをAWSでつくっている。
## AIエージェント
Connect：コンタクトセンターのためのサービス。オペレーターへの取次の選択をしたりなんかしてくれる。
## コーディングエージェント
コーディングだけを速めても、他のフェーズで詰まってしまう。
AI-DLC(AI駆動開発)を導入することでサイクル自体を変える事ができる。
> ■サイバーエージェント
> どのレベル感でAIを使っているかまで評価してる。
> AI-DLCをカスタムして導入している。
## kiro
iOSアプリも出た。
クラウドセッション機能でセッション内容の同期もできる。
タスク割り当てを並列にできるように考えたり、ワークフローを工夫してkiro等を使う工夫が大事。
## フロンティアエージェント
コードセキュリティが危うくなったため、Security Agentを作った。
そして次は運用が大変になるのでDevOpsAgentを作った。
これでリリースも管理したり、変更に特化したテストができるようになった。
> ■日本証券取引所
> 色んなシステムをAWSに載せています。
> 有事対応の素早さのため、DevOpsAgentを使っている。
## AI駆動レガシーモダナイゼーション
レガシーシステムのモダン化にもAIを使う。
負債vsセキュリティの問題があるが、AIでコストやリスクを軽減できるのではないか。
Transform Custom
既存のものを解析してアップデートを考えてくれる。
人間がフィードバックを入れることもできる。
様々な事例とともに、最近のサービスの話を聞けたのは有用性を感じられてよかったです。
内容としては「AIを使いこなすには開発者の学び直しも大事」という最後のほうの一言が一番心に残っています。AIにまかせてできることは多いですが、自分自身も力のあるエンジニアで有りたいと思います。
Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－
カオスエンジニアリングというキーワードが私の現場でも出ていたので、どんなことをしているのか等持ち帰れる物があるかなと思い聴講しました。
聴講メモ
AI-DLC
人と人ではなく、人とAiが協業する方法論。
人が意図・レビューを担って、AIがアウトプットを担う。
ワークフローが出ているので、それに沿ってやると良い。
## AI-DLCのOperationフェーズ
AIがテレメトリデータを分析、計画し、人間がフィードバック、推奨アクションを実行する。
プランレビュー実行の流れ。これを運用でも取り込めばよいのではないかというアイデア。
## 「運用」って長くてやることが多様
V1のAI-DLCのワークフローをそのまま適用するのは難しく、個別のケースに対応しきれない。
そこでV2へのアップデートで柔軟に対応できるようになった。
運用が成熟して整った状況でなければAIを適用できないという現実もある。
## AI-DLCのOperationフェーズの適用
いきなり全部変えるのではなく、ときに人間が介在しながら順に少しずつ適用していけば良い。
1. まずはそのまま今の運用に乗せる
2. 今できてないことをAIで改善する
3. AIを活用した運用にしていく
## リスクストーミング×カオスエンジニアリング
リスクストーミング：アーキテクチャ図上でリスクを可視化して共有する。
カオスエンジニアリング：自信を構築するための実験。（安全にやること！）これもプランレビュー実行の流れ。
準備が大変という問題がある。
AIを活用すればやりやすいし、AI-DLCの体制のおかげで人も取り組みやすい。
リスクストーミングで未知のリスクなどを洗い出して、カオスエンジニアリングで検証する。
カオスエンジニアリングを「自信を構築するための実験」と位置づけていて、「予行演習」くらいに考えていた私としては新たな視点でした。予行演習をすることで何を得るのかということまで考えれていなかったなと気づきました。
また、まとめの所で「エンジニアは要らなくならない。専門性や経験を活かしていく必要があると考えている。」という話をされていたのが心に残っています。活かせる力のあるエンジニアでありたいところです。
大規模障害から考える、AWS 上で備えるべきレジリエンスの実践
普段、インフラに何か起きた際に大体声がかかるチームで働いているため、持ち帰れるものがありそうだと思い聴講しました。
聴講メモ
## AWSの障害時に何をしているのか
### 1. 検出、軽減策の実施
メトリクスやいわゆる監視、問い合わせなどで検知。
問題箇所をまずは切り離してロールバック、台数を増やして再起動、修正し直し…といった手順を踏む。
### 2. 振り返りと計画
- インパクトサマリー
- 根本原因（5whys）
- 教訓
- アクションアイテム
5whysについては、回数に個室せず質を求めて実施する。
「質を求めて実施」とは、自分たちで行動できるアクションにつながる深堀りをすべく、データとともに実施するイメージ。
問いを分岐させていって、複合的な原因に対応できるように取り組むと良い。
### 3. 学習とスケーリング
スケーリング：客にやってもららわないといけないことがあるケース、それすらいらないケースなど色々ある。
## Availabillity Axioms（可用性の原則）
- リージョンを分離する
- AZ障害の自動対応
- グレー障害への対応：Fleet Health ServieやZonal Event Detectorで検知
- ゾーナルシフト→ゾーナルオートシフト：AZ障害に自動的に対処する
- 厳密なテスト
- AWSテストリージョン：テスト用に構築されたAWSリージョン。（客利用なし）
- AZの電源断とか、依存関係利用不可とか、サービス再起動とかをテストしたりする
- 過負荷からの保護
- 準安定障害の解析
## ツール
AWS Fault Injection Service
レジリエンステスト。AWSのエラーケースを試すことができる。
Amazon Application Recovery Controller Region switch
あらかじめ設定しておけば、障害発生時にリージョン移行をしてくれるというもの。
プランの評価もしてくれる。
障害発生時、どういう手順で物事を考えていけばよいか、次に繋げる振り返り等色々と持ち帰る物がありました。細かい部分でいうと、最後に紹介されていたツールについて、取り入れてみても良さそうだなと思いました。
Agentic RAG が切り開く製造現場語理解の新たな可能性
私のチームでは現在まさにRAGを構築しているところのため、使ってもらえるものにするにはどうしたら良いか等、何か参考になるかもしれないと思い聴講しました。
聴講メモ
生産現場に入って一緒に課題を解くという姿勢で、その一つとして取り組んだ。
探せない、伝わらない、活かせないといった課題を解決したいのがモチベーション。
しかし生成AI、RAGを入れればそれで活用されるかというと、それだけではうまく行かない。
現場と知識をつなぐAIがほしい。
例えば、現場で使われるいつも通りの呼び名で通じるとか、一度要ったことを覚えてくれるとか、ざっくりとした検索でも応じてくれるとか、現場にフィットしていってほしいといった要望。
## 現場用語の認識を向上させる
まずRAGを導入し、そこから精度を向上。
Bedrock Evaluationsを使って評価を行い、改善していった。
やったこと
- 検索方式をハイブリッド検索に変更し、社内専門用語を意味を持って読めるようにする
- 取得件数の見直し
確認してフィードバックを待って検索・蓄積の改善ができるようにエージェント化した。
## Human in the Loopで用語を蓄積
未知のものが登場した場合は人間に質問するようにする。
エージェントが辞書をつくり、それを参照/更新させて社内用語をどんどん扱えるように改善。
## 対話型探索エージェントに
検索前に、人間に対していくつか質問させるようにした。
広すぎる検索をいきなりするのではなく、質問で絞り込ませる。
「自己修正・自律探索ループ」という名前をつけた機能を独自で作り、組み込んでいる。
十分に検索できそうかというのを評価するようになっている。
## 活用ログによる改善サイクルの構築
チャットログを取得しておき、どう使われているのか、何が足りないのか（データとか、想定ケースとか）等を考えて改善していく。
ここはコストをあまりかけたくないので、Nova2liteを使って、低コストで常時監視させている。
## 社内の変化
使えるシステムを用意すると、社内のデータを残す意識があがるという変化があった。
辞書機能の組み込みやクエリの評価機能の実装など、細かいところまでてを届かせるための工夫をかなり取り組まれているという印象でした。チャットログから不足しているものを能動的に見つける仕組みというのも面白く、こういう部分は利用者から声があがることは少ない（諦めてしまう）ため、自チームの仕組みにも組み込めると良さそうだと思いました。
さいごに
やはり全体的に生成AIの話題が多く、スポンサーブースでもそのような製品・LTが多く見受けられました。
いくつかチーム内に持ち帰れるものがあったので、取り入れることも検討したいと思います。特にRAG関連のものについては今すぐとはいかなくとも、追々取り組んで行ければと思っています。
フィジカルAIに関してもセッションの中で触れられていたり、展示も多かった印象です。分野的に業務等に活かせる事があるわけではないですが、今盛んに取り組まれていることに触れられたのは良かったです。
またこの記事内では触れていませんが、企業ブースを回って今抱えている悩みについて案をもらえたりしたことや、セッションも集中して聞きやすい環境なのは現地参加してよかった点でした。