0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【ソロ参加】AWS Summit Japan 2026 参加レポート(6/26)

0
Last updated at Posted at 2026-06-27

はじめに

AWS Summit Japan 2026 に初めて参加してきました!
存在は知っていたものの平日のため、有給をとるのがもったいなく参加を見送っていましたが、ちょうど1日だけ余っていたので初めて参加してみました。

参加日:2026年6月26日(金)
会場:幕張メッセ(千葉市)

イベント全体の感想

9時半ごろに会場に到着し、入場しました。(画像は会場前のブース)

IMG_1872.jpg

早速、目玉セッションの会場へ移動!!

スペシャルセッション:AIエージェントが変える企業の未来

10:00からの1時間半。2日目の目玉セッションです。
既に座る場所はなかったため、立ち見で辛かった。
セッション予約しても早いもの順の整理券を貰わないといけないのは罠すぎるよ....

IMG_1874.jpg

テーマは AIエージェント

「生成AIをどう使うか」という話から一段進んで、「エージェントが自律的にタスクを遂行し、ビジネス成果を生み出す」というフェーズに議論が移ってきているのをひしひしと感じました。

Anthropic、オムロン、ファナック、サイバーエージェント、日本取引所グループなど、業界をまたいだ登壇陣が各社の実践事例を語る構成で、「AIエージェント、もう実験フェーズじゃないんだな」という空気感がありました。


アーキテクチャ道場 2026 – AI時代編! [ARC446]

個人的に今日イチのセッション。

概要

概要(原文ママ) AI の進化によって新しいアプリケーションが次々と生まれています。しかし、プロトタイプから本番環境へ進む道のりは簡単ではありません。LLM は嘘をつくかもしれない、コストが爆発するかもしれない、プロセスの途中で文脈を忘れるかもしれない、AI の出力が本当に正しいか保証できないかもしれない。こうした課題に対して、優れたArchitectureはどのような解を持つのでしょうか?今年のArchitecture道場では、AI 時代ならではのお題に対してソリューションアーキテクトが設計したArchitectureをレビューしながら、AI アプリケーションの非機能要件を実現するパターンや、推論モデルをシステムの一部として設計し、運用の中で改善し続けるための勘所を深堀りします。AI 時代のArchitecture設計において、変わることと変わらないことを一緒に考えてみましょう。

お題は全部で2問。

お題①:ショッピングアシスタント機能のアーキテクチャ

LLMを軽量化するとコストは下がるが応答品質も下がる、品質を上げようとするとコストが上がる——このジレンマは、AI機能を開発したことがある人なら誰でも直面するやつです。

それに対する具体的なアプローチとして紹介されていたのが以下:

  • キャッシュの活用:同じようなプロンプトへの回答をキャッシュして、LLMを呼ばずに済む部分を減らしコストとレイテンシを削減
  • モデルの分岐:求められる精度に応じて呼ぶモデルを変える。軽いタスクは軽量モデル、精度が必要なタスクは高性能モデルという使い分け

「どのモデルを使うか」を固定するのではなく、要件に応じて動的に切り替える設計にするという発想が参考になりました。

お題②:AI開発のボトルネックを解消するDX向上のアーキテクチャ

こっちの方が印象的でした。

課題として挙げられたのが以下の3つ:

  • 仕様の記述が曖昧でAIの解釈に揺らぎが出る
  • コードレビューが大変
  • AIが実装した意図しないバグに気づかずリリースしてしまう

これを「運用でカバー」するのではなく、アーキテクチャで解くというのが今回の肝でした。

まとめスライドを見て全体像が一気に腹落ちしたのですが、パイプラインが左右に2つ並んでいて、それぞれの役割がこう整理されていました:

左:仕様生成パイプライン

Biz/Devが自然言語で書いた仕様をAWS CodePipelineに投入すると、AgentCore runtimeが形式仕様を生成・バリデーション・論理チェックまで行い、Pull Requestの形で出力される。さらに別のパイプラインで参照モデルも生成される。

「決定的な仕様をAIが生成、人間が判断する」

右:実装パイプライン

Devがコードを書いてPull Requestを出すと、AWS CodeBuildがKiro CLI(Headless Mode)でレビュー。差分なしならAuto Mergeで本番デプロイ、差分ありなら仕様・実装を修正するフローに戻る。DevSecOpsのパッケージ管理やOSS互換性スコア(OpenSSF Scorecard)チェックも組み込まれている。

「AI生成物を決定的な仕組みで判定、不確実性がある場合は人間が判断する」

「仕様を曖昧なまま渡さない」「レビューを仕組みで自動化する」「バグを出口で止める」という3つの課題が、それぞれパイプラインの中のステップとして組み込まれているのが美しいなと思いました。

スクリーンショット 2026-06-28 012545.png


全体を通じた学び・気づき

「設計できる人」が求められる時代へ

今回のセッションを通じて一番強く感じたのは、設計力がこれまで以上に重要になってきているということ。

コードを書く部分はAIがどんどん担ってくれる時代になってきた分、「何をどう作るか」を決める設計の部分こそが、人間に残される仕事になっていく気がしました。コードが書けるだけでは足りない、という危機感と、逆に設計をちゃんと学べば戦えるという希望を、同時に感じた1日でした。

AIエージェントを自分でも作ってみたい

アーキテクチャ道場で見た「AI駆動開発プラットフォーム」のような設計を目の当たりにして、自分でもAIエージェントを作ってみたいというモチベーションが素直に上がりました。「すごいな」で終わらせず、手を動かすところまで持っていきたいです。

激動の時代、生き残るために頑張りましょう 👏👏👏


まとめ

26日だけの参加でしたが、スペシャルセッションとアーキテクチャ道場だけでも来た甲斐がありました。。動画で後から見るのとは頭への入り方が全然違う、というのを改めて実感したので、来年も参加したいなと思いました。

バイバイ!!!

IMG_1882.jpg


本記事は参加者個人の感想・まとめです。セッション内容の正確な情報は公式サイトをご確認ください。
https://aws.amazon.com/jp/events/summits/japan/

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?