先端技術開発グループ（WAND）の小島です。先月（6月）に幕張メッセで開催されたAWS Summitに、WANDの全員で参加してきましたので、そのレポートをお届けします。
Expoエリアが面白い
AWS Summitでは基調講演やセッション、スポンサーブースなど多彩なコンテンツが提供されていました。私の記事では、Expoエリア内の「AWS Builder's Fair」に絞って、詳細にレポートします。
「Expoエリア」とは、メインセッション会場の隣で開催されているエリアで、最新技術の共有、実機デモ、ハンズオン、LT（ライトニングトーク）などが行われています。メインセッションは後日アーカイブ配信されることが多い一方、Expoエリアのコンテンツは現地でしか見られないものが大半です（Developers on LiveのLTなど、一部はYouTubeで配信されています）。
現地ならではの体験も多く、AWSのサービスについてAWSの方に直接質問したり、ふらっと立ち寄ったLTで、アーカイブがないからこそ聞ける尖った内容に思わず聞き入ってしまったりという体験ができます。個人的には、ここが一番面白かったように感じました。
この記事では、AWS Builder's Fairという、AWSのエンジニアが制作したデモアプリが展示されるエリアを中心に、特に印象に残ったアプリと関連技術を詳しく紹介していきます。この記事ではAIエージェントなどに関する専門用語が登場しますが、都度解説を加えます。
AWS Builder's Fairエリア（1日目）
AIメイクさん（B-041A）
（※AIメイクさんのデモ画面。顔にはぼかしを入れています）
画像生成と3D Gaussian SplattingをAIエージェントで組み合わせた、バーチャルメイクのデモです。3D Gaussian Splattingは、複数枚の写真からリアルな3D空間を再現する新しい技術です。ポリゴン（多角形）の代わりに、「ガウシアン（正規分布）」と呼ばれる色のついた半透明な粒を無数に配置することで、非常に高精細で滑らかな3Dモデルを高速に作り出します。入力された顔画像に対し、画像生成（Nova Canvas）で好みのスタイルに変化させ、さらに3D Gaussian Splattingで3次元モデルとして再構成します。
画像生成とGaussian Splattingを組み合わせるアイデアもさることながら、個人的に最も興味を惹かれたのは、これらをAIエージェントが呼び出すツール群として設計したアーキテクチャです。現在のAIエージェントは、あらかじめ定められた処理を順に実行する「ワークフロー型」と、ツール群だけ用意しておきLLMが動的に呼び出し先を決定する「エージェント型」に大別されます。一般的に、ワークフロー型のほうが安定して成果を出せますが、最近では「コーディングエージェント＋MCP（Model Context Protocol）」のような、自律的にタスクをこなすエージェント型が台頭してきていると私は理解しています。
「なぜエージェント構成にしたのか」と質問したところ、「エージェントにすることで、『流行りのスタイルのメイクにして』といった曖昧な指示にも対応できる」とのことでした。例えば、Web検索ツール（tavily）と連携すれば、エージェント自ら「流行りのスタイル」を調べて理解しようとします。固定のパイプラインのワークフロー型とは異なり、エージェント型は多様な問い合わせに対して動的にツールを呼び出す柔軟性を持っています。
アーキテクチャ図の中央には、司令塔として機能するLambdaが配置され、その中でAWSが開発するOSSのAIエージェントSDK「Strands Agents」が動作しています。AWSが自らOSSのSDKを開発する背景には、LangChainのような既存のフレームワークだけではカバーしきれない、AWSサービスと親和性の高いエージェント開発を加速させたいという狙いがあるのでしょう。同様のSDKは、Googleも「Agent Development Kit（ADK）」として公開しています。
図の右下にあるStep Functionsは、SageMakerの推論タスク（S3にデータをアップロード→推論エンドポイントを呼び出し→結果取得など）を実行するためのもので、Step Functions自体がエージェントとして呼び出される一つの「ツール」として機能します。
このような「Strands Agentsを搭載したLambdaを司令塔とし、その配下に各種ツールがぶら下がる」アーキテクチャは、今回のBuilder's Fairで頻繁に見られた構成でした。Gaussian SplattingのようなGPU環境でのモデルのデプロイは比較的馴染みが深い技術ですが、その延長線上でエージェント化できるという点が非常に興味深く感じました。
このデモは来場者による人気投票でも非常に高い評価を得ていました。見た目が変わるデモは人気が出やすい傾向がありますが、「Gaussian Splattingと画像生成という、画像処理分野ではお馴染みの技術をエージェントで組み合わせるだけで、これほど面白いものが生まれるのか」と感心しました。
Inferentia / Trainium で徳得を積め！？（B-081A）
AWSが開発するAI専用チップ「Inferentia / Trainium」を紹介するブースです。通常、AIモデルの訓練や推論はGPUで行いますが、専用のチップを使うことで、GPUよりも高いコストパフォーマンスでAIモデル（特にLLM）を運用できます。
LLMの運用コスト、特に推論コストの高騰は多くの企業にとって深刻な課題です。BedrockのようなAPIサービスは手軽ですが、大規模なリクエストを処理する場合は、自前でホストする方が経済的です。その際の切り札となるのが、Inferentiaのような専用チップなのです。その代わり、GPUのようにゲームを動かすといった汎用性はなく、AIモデル（特にTransformer）の処理に特化することで、高い効率を実現しています。
同様のチップは、GoogleもTPU（Tensor Processing Unit）として開発しており、Geminiの訓練・運用に大きく貢献したことや、OpenAIがコスト削減のためにTPUを活用するというニュースは記憶に新しいところです。
ここでInferentiaとTrainiumの違いに触れておきます。もともと、「Inferentia」は推論（Inference）、「Trainium」は訓練（Train）を想定して作られたチップです。Inferentiaは2019年12月から、Trainiumは2022年10月から（出典）一般提供が開始されており、いずれもLLMの台頭以前であり、その推論/訓練の線引きは当時のモデル規模に基づいています。LLMの台頭によるモデルの巨大化は、これらのチップの設計当初には想定されていなかったトレンドです。そのため現在では、推論用途であってもInferentiaのメモリに収まらず、より大容量のメモリを持つTrainiumを使うケースも増えており、両者の境界はやや曖昧になっています。
こちらのブースでは、LLMに対して大量の推論リクエストを送る状況を想定し、BedrockによるオンデマンドAPIと、Inferentiaによるセルフホスティングのコストをリアルタイムで比較するデモが行われていました。1台のInferentia 2のインスタンス（inf2.24xlarge）上にLLMをデプロイし、ECS on EC2として384同時リクエストを処理していました。（うろ覚えですが）モデルは8Bパラメータで、それでも「まだメモリは余裕がある」とのことでした。リクエストあたりのトークン数は、「入力約1000、出力約500」とのことで、1ターンで完結するLLM推論としては一般的な値と言えるでしょう。
使用されていたinf2.24xlargeは、アクセラレーターメモリが192GBもあるにもかかわらず、オンデマンド料金はバージニア（us-east-1）で6.491USD/hr、東京（ap-northeast-1）では9.736USD/hrと、GPUインスタンスと比べて非常に安価です。
| インスタンスタイプ | アクセラレーター | アクセラレーターメモリ | バージニア（us-east-1） | 東京（ap-northeast-1） | 東京の1ドルあたりメモリ（GB・h/USD） |
|---|---|---|---|---|---|
| inf2.24xlarge | Inferentia2チップ×6 | 192 GB | USD 6.491 | USD 9.736 | 19.721 |
| inf2.48xlarge | Inferentia2チップ×12 | 384 GB | USD 12.981 | USD 19.472 | 19.721 |
| g6.48xlarge | L4 24GB GPU×8 | 192 GB | USD 13.350 | USD 19.362 | 9.916 |
| g6e.24xlarge | L40S 48GB GPU×4 | 192 GB | USD 15.066 | USD 21.850 | 8.787 |
| g6e.48xlarge | L40S 48GB GPU×8 | 384 GB | USD 30.131 | USD 43.699 | 8.787 |
| p4d.24xlarge | A100 40GB GPU×8 | 320 GB | USD 21.958 | USD 30.098 | 10.632 |
| p4de.24xlarge | A100 80GB GPU×8 | 640 GB | USD 27.447 | USD 37.622 | 17.011 |
※上記はEC2のオンデマンドインスタンスの1時間あたりの料金（2025年7月現在、AWSの公式より）。一番右の列は、1ドルあたりに利用できるアクセラレーターメモリ量（GB・h/USD）で、数値が高いほどコスト効率が良いことを示します。
この表から、特にメモリあたりのコスト効率で比較すると、Inferentia 2が突出していることがわかります。p4de.24xlargeも健闘していますが、これは2025年6月の値下げによるもので、以前はより高額でした。また、GPUインスタンスは需要の高さから枯渇することもあり、「使いたいときに確保できない」という供給リスクも考慮する必要があります。
話をブースの展示に戻しましょう。このデモでは、オープンソースの推論サーバー「vLLM」を使って、LLMをホスティングしています。vLLMは、Inferentia向けのモデルコンパイルからホスティングまでを抽象化してくれる役割を担います。Inferentiaのモデルコンパイルは、AWS Neuron SDKを使ったやや低レイヤーな作業が本来必要ですが、vLLMがNeuron SDKを統合しているため、開発者はその複雑さを意識することなく、手軽にモデルをデプロイできると理解しました。
（※AWSの公式ページでは、OSSのリンクのみ資料として公開されていたため、撮影許可をいただいたのち、当日撮影した写真を編集して掲載しました。また、発表者の方のXでブースの様子が公開されていますので、ぜひそちらもご覧ください。）
さらにこのデモでは、Hugging Face上で公開されている任意のモデルをInferentia上でホストできるよう、AWS CDKによるIaC（Infrastructure as Code）テンプレートも用意されていました。ただし、Neuronはモデルのアーキテクチャによってはコンパイルに失敗することもあるため、GPUのように「何でも動く」わけではありません。それでも、主要なモデルには対応しているため、非常に価値が高いと感じます。vLLMとInferentiaによるHugging Faceのモデルのデプロイ方法は、以下のAWSの公式ブログで紹介されています。また、IaCテンプレートは以下のGitHubで公開されています。
- Serving LLMs using vLLM and Amazon EC2 instances with AWS AI chips
- Neuronx patterns Construct Library
アーキテクチャ図には、LLMをホストするECSの他に、384並列でリクエストを送るためのFargateが描かれています。これは「Summit会場の不安定な通信環境を想定した」とのことで、本来はフロントエンドで処理するため、この構成はデモ特有のものです。
興味深かったのは、LLMのストリーミング応答にAppSync Eventsを利用している点です。これは2024年10月に登場したサーバーレスサービスで、LLMが生成したトークンをリアルタイムでフロントエンドに送信できます。内部的にはWebSocketが使われていますが、その管理をすべてAppSync側が担うため、API GatewayやDynamoDBを別途構築する必要がありません。同様のことは従来のAppSyncでも可能でしたが、GraphQLでの実装が必要で学習コストが高いという課題がありました。AppSync EventsはJSONで通信できるため、より手軽に導入できるメリットがあります。
なお、Summit会場にはInferentiaとTrainiumのチップ現物も展示されていました。Inferentia 2（左）はGPUに近い見た目ですが、Trainium（右）はチップ上に巨大なヒートシンクが鎮座しています。ここまで大型化しないと訓練用のチップの熱は処理できないそうで、純粋に驚いてしまいました。
非常に長い解説になりましたが、個人的にはピンポイントでほしい情報で、大変参考になる内容でした。（今後学生などにInferentiaを教える予定があり、自分自身が理解しておく必要があったためです。）
7/15にNeuron Community Vol.2というイベントがあり、ハンズオンが開催予定なので、参加してさらに知見を深めていきたいと思います。
AWS Builder's Fairエリア（2日目）
Industrial AI Buddy（B-042A）
これは純粋に「未来感」があって面白いデモでした。Agentic RAGの発展形といえるでしょう。ユースケースは、工場の新人研修をバーチャル空間で行うというものです。ユーザーはクラウド上にホストされた3Dゲームをプレイし、ゲームコントローラーでキャラクター（左PCの中央）を操作します。操作中に音声で「この機械は何ですか？」「ここでの避難経路はどこですか？」などと質問すると、AIが音声で回答を返してくれます。
まず、アーキテクチャ図の右側に注目します。Bedrock Agentが様々なツールを呼び出し、その一つに技術ドキュメントを格納したナレッジベースがあります。これにより、避難経路や機械の仕様に関する質問に回答できます。この部分だけ見ると、テキストベースの典型的なRAG（Retrieval Augmented Generation）エージェントです。これを音声入力・音声出力に対応させるために、AWSの音声認識サービス「Amazon Transcribe」と音声合成サービス「Amazon Polly」が組み込まれています。TranscribeとPollyは、どちらもAWSが提供するマネージドの音声認識と音声合成サービスで、前者は「音声→テキスト」、後者は「テキスト→音声」を担います。
最も興味深いのは、ゲームのホスティングに「Amazon GameLift Streams」を利用している点です。3Dゲームのレンダリングをクラウド上のGPUで行い、クライアントには映像をストリーミング配信するため、ユーザー側のPCスペックに依存しません（ゲーミングPCがなくてもOK）。ストリーミングでありながら、非常に低遅延な操作が可能です。この構成では、Unreal EngineのアプリケーションがGameLift Streams上で実行され、CloudFront＋S3でホストされた静的なウェブページからアクセスします。ストリーミング化は、クライアントの開発を大幅に簡略化できるという大きなメリットがあります。もしクライアント側でレンダリングを行う場合、プラットフォームごとのライブラリ対応やネイティブアプリ開発が必要になり、開発工数が膨らんでしまいます。（ただし、ストリーミングの場合は安定した通信環境が必須となる点は注意が必要です。）
また、このアプリでは「この機械は何ですか？」という、画面上の対象物を指し示すコンテキストを理解してRAGを実行する必要があります。当初、私はスクリーンショットをマルチモーダルLLMで解析しているのかと想像しましたが、担当者に伺うと「ゲーム内のキャラクターの位置情報をメタデータとして利用し、ドキュメントと紐づけている」とのことでした。シンプルな工夫ですが、非常に効果的ですぐ応用できそうなテクニックです。
内部的にはRAGの応用ですが、音声インターフェースとゲームコントローラーによる操作を組み合わせることでユーザー体験が大きく向上し、未来的な印象を受けるデモでした。Unreal Engine部分の開発は少し大変そうですが、様々な応用が期待できそうです。
AI と IoT で実現するスマート廃棄物管理（B-112A）
こちらはIoTデバイスを活用した展示です（2日目はIoTを組み合わせた展示が多かった印象です）。これは「食品廃棄物の可視化」をコンセプトにしたもので、ゴミ箱に廃棄物が追加されると、クラウド上で画像分析が行われ、何がどれだけ捨てられたかをダッシュボード上で可視化・追跡できます。これにより、廃棄物削減の目標設定や改善効果を定量的に計測し、継続的な改善サイクルを回すことを目指します。
技術的に面白かったのは、重量センサーの活用法です。この種のカメラ分析では、常時クラウドで画像分析を行うとコストがかさみ、かといってエッジデバイスで常時分析するとデバイスが高温になるという課題があります。このデモでは、重量センサーで一定以上（例：10g）の変化があったときだけカメラを起動し、クラウドで分析を行うという工夫でこの問題を解決しています。この起動トリガーは「IoT Core」からイベントで配信され、Raspberry Pi上で動作する「IoT Greengrass」と連携します。「IoT Greengrass＋IoT Core」はIoT開発でよく見られるアーキテクチャです。
※B-112A AI と IoT で実現するスマート廃棄物管理 関連資料 より
アーキテクチャでは画像分析にAmazon Rekognitionが使われていますが、ここは「全てBedrockのマルチモーダル分析でも構わない（むしろそちらのほうが精度が出るかも？）」とのことでした。時系列データベースである「Timestream」を使っているのも面白いポイントで、（別のブースで聞いた話ですが）Timestreamを使うと、時間軸での集計処理（丸め処理など）をデータベース側で効率的に実行できるというメリットがあるそうです。Timestreamと「Managed Grafana」の組み合わせは他のアプリでも見られ、無料のCloudWatchの標準ダッシュボードでは物足りないが、手軽に見栄えの良いダッシュボードを作成したい場合に適した選択肢のようです。
実際の案件では、物理デバイスの設置や故障対応といった課題もありますが、自宅に設置して暮らしを改善するライフハックとして活用すれば、おそらく楽しいのだろうと感じました。
※ちなみに、現地に設置されていたゴミ箱のアイコンはS3ではなく、S3のアイコンを左右反転させたものでした。「S3はゴミ捨て場ではない」という開発者のこだわりだそうです。
AI を使ってアーキテクチャを作ってみよう！（B-122A）
「ふわっとした要件からAIエージェントがサクッとアーキテクチャを設計する」というデモで、その着眼点と実装方法が非常に参考になりました。ふわっとした要件の相談、多いですよね。その都度、エンジニアが長時間のヒアリングを行うのは大きな負担ですが、これを怠るとあとから悲惨なことになるので、やらざるを得ないというのが、世間一般のあるあるではないでしょうか。
B-122A AI を使ってアーキテクチャを作ってみよう！ 関連資料 より
個人的に感心したのは、要件定義書を生成するフェーズです。エージェントは「AWS Document MCP」と「事例検索Tool」という2つのツール（MCP）を呼び出します。事例のソースは、AWSが公開している顧客事例ブログです。ユーザーが「ふわっとした（曖昧な）要件」を入力すると、エージェントがユーザーとの対話を繰り返し、要件定義書を作成するのに十分な情報が得られるまで、質疑応答を繰り返します。情報が揃うと、事前定義されたフォーマットに沿って要件定義書が作成されます。アーキテクチャとしては、ベクトルDBを2つのツールとして利用するシンプルな構成ながら、解決できる課題の大きさに感心しました。
図の下側のフローも興味深いものです。生成された要件定義書を要約し、再度類似事例を検索してユーザーに提示します。先程のエージェント内部の事例検索ツールは、LLMが要件定義書を作成するために使うものでしたが、こちらの事例検索は、ユーザーが提案内容をより深く理解するために使われます。「類似の事例を提示する」というひと工夫で、LLMの提案の説得力を高めるUX設計は見事ですね。ユーザーに説明する際の、こうした工夫は非常に参考になります。
図の上側のフローは、アーキテクチャ図を生成するためのもので、AWSが公開しているAWS Diagram MCP Serverが使われています。
B-122A AI を使ってアーキテクチャを作ってみよう！ 関連資料 より
インフラは、ALBの配下のECSコンテナにStrands AgentsとMCPが同居するシンプルなアーキテクチャです。事例検索はOpenSearchによるベクトル検索、LLMはBedrockというよくある形です。
少し攻めた質問ですが、「これはソリューションアーキテクト（SA）の仕事を代替するものではないか。SAから見てLLMの生成した提案の品質はどうか」と尋ねてみました。プロの方から見ると「現状の設計では、お客様固有の事情（カウンターパートの方の得意分野、会社の技術戦略や社内標準）を考慮できておらず、提案の質としてはまだ改善の余地がある」とのことでした。こうした属人的な要素をAIが代替するのはまだ難しいという印象を受けました。
とはいえ、初期段階の「ふわっとした要件」に対応するツールとしては大いに期待が持てます。これが実現すれば、エンジニアへの問い合わせを大幅に削減できる可能性があり、非常に期待の持てるデモでした。
まとめ：AIは「モデル」から「エージェント」へ
今回のBuilder's Fairを通して見えてきたのは、LLMを司令塔として様々なツールを連携させる「AIエージェント」アーキテクチャの台頭です。「AIメイクさん」や「アーキテクチャ設計AI」のように、単一のAIモデルでは実現できない複雑なタスクを、エージェントが動的にツールを呼び出すことで解決していました。これは、AI活用のフェーズが、個別の「モデル」利用から、自律的にタスクを遂行する「エージェント」へと移行しつつあることを示す、大きなトレンドであると言えるでしょう。
また、AWSというと「オンプレからの移行支援」のようにお堅いイメージを持たれがちですが、今回のBuilder's Fairでは、展示のほとんどにAI/MLが活用されており、AWSの深い知識がなくても、AIの最新動向がわかれば非常に楽しめる内容でした。楽しいアプリを作ってくださったAWSの皆様、本当にありがとうございました！
番外編：AWSパートナーエンジニア選出プログラムで表彰されました
AWS Summitの1日目には、「AWSパートナーエンジニア選出プログラム」の表彰式が行われました。これはAWSのパートナー企業に所属するエンジニアを評価・選出し、コミュニティを形成するためのプログラムで、以下の4つから構成されます。
- Japan All AWS Certifications Engineers
- Japan AWS Jr. Champion Partner Program
- Japan AWS Top Engineers Program
- AWS Ambassador Program
弊社もAWSパートナーネットワーク（APN）に加入しているため、このプログラムの対象です。今回、弊社からは以下のメンバーが選出されました（※敬称略、AWSの公式発表順）。
- Japan All AWS Certifications Engineers：5名（全体で1,633名）
- 伊賀 裕展、黒木 孝志、小島 啓明、坂根 裕、Chan Kwan Yui Mathew
- Japan AWS Jr. Champion Partner Program：1名（全体で113名）
- 佐藤 碧
- 出典
All CertificationsはAWSの認定資格をすべて取得することで選出されますが、Jr. Championは実績も評価対象となります。
選出された皆様、おめでとうございました！🎉
（※登壇なさっているYukkiさんについては、「どんどん写真撮ってください」と何度もおっしゃっていたため、掲載OKと判断し、そのまま掲載いたしました。また、選出された弊社のメンバーについては、既にAWSのホームページ上で公開されている方々です。）
なお、弊社には「資格取得支援手当」があり、AWSなどの認定資格の受験料が、合否を問わず全額支給されます。詳細は、弊社の福利厚生ハンドブックで公開していますので、興味のある方はぜひご覧ください。
Discussion