AWS Summit Japan 2026に参加レポート
AIエージェントを「作る」時代

はじめに

こんにちは。クラウド活用推進担当 榊原です。

AWS Summit Japan 2026に参加してきました!
昨年参加したときは1日目の午後だけでしたが、今回は2日間しっかり回ることができました。

今年はAgentic AIが全体を貫くテーマになっており、セッションや展示でもAIが無関係なものはない印象でした。

今回は、会場の雰囲気と、特に印象に残った2つのセッションについてまとめてみます。

目次

• はじめに
• 全体の雰囲気
• 「勝手に広まる」人気AIエージェントを爆速で作ろう！
• KiroとAmazonの文化から学ぶAI駆動開発の型
• 参加して感じたこと

全体の雰囲気

当日は雨。
あまり素敵とは言えない天気ですが、これもある意味「らしさ」かなと思いながら、受付完了までたっぷり30分。

基調講演の大会場を駆けるレーザービームが、AWS Summitに来たんだなぁという気持ちにさせてくれます。

戦利品

AWS Summit恒例のクッションや認定のステッカーをもらいました。
今年初配布のAI Developer Professionalのステッカーもゲット。黒魔導士っぽいです。

Kiroグッズもゲットしました。これが一番うれしかったかもしれません。
2日目に受け取ったんですが、私と同じく初日に悔しい思いをした人が長蛇の列を作っていました。

体験型コンテンツ

会場内ではセッションだけでなく、AWS Builders' Fairの体験型コンテンツもいくつか見て回りました。

印象に残っているのは、AIパワポカラオケ と 大喜利Dojo です。

AIパワポカラオケは、テーマとチャレンジ項目を渡すと、
AIがプレゼン資料と原稿を作ってくれるというものです。
その原稿をもとに人間がプレゼンし、発表内容を採点してくれるところまで含めて
一つの体験になっていました。
資料を作るだけでなく、発表して評価するところまで含めているのがおもしろかったです。

大喜利Dojoでは、Bedrock AgentCore上で動くAI Agentが採点者となり、参加者が大喜利に挑戦します。
挑戦者にはAIを含めることもでき、人間とAIの回答を同じ場で比較できる構成になっていました。
マルチエージェントの活用はいろいろなセッションや企業展示で目にしましたが、その中でもひときわユニークだったと思います。

自分が参加した会ですが、なんやかんやで優勝しました。うれしい。

「勝手に広まる」人気AIエージェントを爆速で作ろう！

このセッションでは、AIエージェントをどう作るかというより、どうすれば使われるAIエージェントになるのか、というおはなしが中心でした。

Strands AgentsやAmazon Bedrock AgentCoreの登場でAIエージェントを作るためのハードルはかなり下がっています。
AgentCore ハーネスでは、マネジメントコンソール上の設定だけでも基本的なエージェントを作れるようになっているとのことでした。
一方で、「一番難しいのはユースケース」と紹介されていました。

感じたこと

具体的なユースケースとして紹介されていた re:Inventエージェント や パワポ作るマン は実際に使ってみたいと思わせる強い魅力を感じました。
それはきっと、製作者自身の「これがあったらうれしい」という想いが根底にあるからだと思います。

私の身近にも、AIの便利で賢い使い方を知っている人がたくさんいます。
そういう人たちのアイデアを、すぐにWebアプリ化できる雛形があったら、ユースケースの発掘がかなり進みそうだなと思いました。

エンドユーザーではなく、まずは開発者やAI活用に慣れた人のアイデアをすぐに反映できる受け皿を用意できると、AI内製化もどんどん進んでいくのかもしれません。

KiroとAmazonの文化から学ぶAI駆動開発の型

こちらはAI駆動開発のセッションですが、AIコーディングエージェントの機能紹介というより、AIに開発を任せるために人間側が何を考えるべきか、という内容でした。

Design for Evaluation

このセッションで中心になっていたのが、Design for Evaluation です。

AIでコードが書けるようになった今、課題は「作れるか」よりも「作ったものを評価し、責任を持てるか」に移っている、というおはなしです。
AIが十分な品質でコードを書けても、ソフトウェアの振る舞いがビジネスの要求とズレていたり、構造や特性がエンジニアの期待とズレていると価値にはなりません。

そこで、AIにタスクを渡す前に「評価可能か」を考える。
これが Design for Evaluation です。

評価可能にするための要素として、以下の3つが紹介されていました。

・評価基準
・評価手段
・観測対象

何を満たせばよいのか、どうやって確認するのか、何を見て判断するのか。
ここが曖昧なままAIにタスクを渡すと、出てきたものに対して「思ってたのと違う」が発生します。

この問題はAIの能力だけの話ではなく、人間側が意図や評価基準をうまく渡せていないことで起こります。

Design for Evaluationを身に着けるプロセス：守破離

セッションでは、Design for Evaluationを身に着けるためのプロセスとして、守破離が紹介されていました。

守：合意形成による評価基準の定義

AIが十分な品質でコードを書けても、ビジネスの要求やエンジニアの期待とずれていれば価値にならない
目的は仕様書を作ることではなく、振る舞いや内部構造について「どうなれば正しいか」を揃えること

破：評価基準と手法により、人間待ちを解消してAIを自律させる

「UIのデザインをかっこよくして」「コードに問題がないかレビューして」は、言語化されていても評価基準と手法がない
構造の制約やセキュリティ評価など評価基準・手段を用意し、AIへのフィードバックループを閉じる

離：AIにコードを書かせること自体を目的にしない

AIがすぐ実装できるからこそ、無駄な機能を作ると負債になる
熟練エンジニアの価値は、顧客課題や成功指標から逆算し、「作るべきもの」と「作らないもの」を判断することにある

感じたこと

自分自身のAI利用を振り返ると、本当に曖昧な指示が多いと感じます。
特にデザインについては、「なんかダサいんだよね」と自分でも正解が分かっていないまま修正を求めたことが何度もあります。
本当に耳が痛い話でした。
エージェント自身が結果を評価できるように、合意形成のプロセスを大事にしようと思いました。

参加して感じたこと

昨年のAWS Summit初参加時点では新卒3か月目。自分の足元さえあやふやで、雰囲気に圧倒されるばかりだったのをよく覚えています。

しかし今年はセッションやブースでたくさん学び、それをどう活用するか、自身の業務にどう取り入れるかという視点で参加することができたと思います。

そして来年はJr. Championsとして参加したいと思っています。
今度はどんな景色が見えるのか、今から楽しみです。