こんにちは！ 久しぶりのブログ投稿になります。桑山です。 AWSサミッ
こんにちは！
久しぶりのブログ投稿になります。桑山です。
AWSサミットに行ってきました！業務都合で2日目のみの参加です。
表紙の画像はRedHatのブースで配られていた。企業名通りの「RedHat」です笑
実は私はインフラエンジニアではあるのですが、AWSの実務経験はないため少しでも知見が広がればいいなと思い参加してきました！
そもそもAWS サミットとは
まずは私の参加してきたAWSサミットについてのざっくりとした概要です。
AWSサミットは、Amazon Web Services（AWS）が毎年開催している国内最大級のクラウドカンファレンスです。
クラウドや生成AI、サーバーレスコンピューティングなど、最新技術に関するセッションや展示、ワークショップが行われ、AWSだけでなく多くの協賛企業やエンジニアが集まります。また、AWSのエキスパートや実際にAWSを活用している企業の担当者と直接交流できる場でもあり、新しい知識や事例に触れられる機会になっています。
あるテーマについて体系的にまとまった資料と説明を聞きたい場合はセッション、各企業の担当者の方に直接質問をしたり、意見交換をしたい場合はブースを回るなど目的に応じて行動方針を変えることができるので様々な楽しみ方ができます。
AWSサミット当日の行動内容
当日はセッションは少なめにし、ブースを主に回ってきました。
というのもAWSサミット内の全セッションはアカウント登録をすれば、後日配信されます。そのため当日しか体験できないブース巡りを可能な限り優先することをお勧めします。
基本的にはブースを回りつつ歩き疲れたら、座って聞くことができるセッションを見るのが今回参加して感じた賢い回り方なのかなと思います。(当日はずっと歩き回ってかかとが限界でした。)
そんな中、参加したセッションは
- スペシャルセッション：AI エージェントが変える企業の未来 ─ 構築から運用まで、ビルダーと創る自律型 AI の実践
- IaC コードを資産へ：AWS CDK 社内ライブラリと横断展開
- アーキテクチャ道場 2026 – AI 時代編！
スペシャルセッションをはじめとして個人的に興味のあったIaC(Infrastructure as Code)やアーキテクチャについてのセッションを聞いてきました。
ブース巡りについては、先輩ウナルス社員の二人と回ってきました。様々な企業のブースを回りステッカーなどのアメニティを集めたり、担当者の方と直接会話や質問をしたり、各ブースで行われるミニセッションを聞いたりしました。
AWSサミットに参加した目的
私は書き出しにもある通りAWSの実務経験がない状態でAWSサミットに参加してきました。
そのため「このサービスを知りたい」のような具体的な内容より「これからのAI時代の未来」や「他の企業は今どのようなことに取り組んでいるのか」など抽象的というか大局を見るような形で、今後のインフラやAI開発についてより解像度を上げることを目的にセッションを聞いたり、ブースを回ったりしました。
今回は話を聞いてきたセッションについての話がメインになります。(ブース巡りの話も入れたかったのですが、そちらについては今回は割愛させていただきます)
スペシャルセッション：AI エージェントが変える企業の未来 ─ 構築から運用まで、ビルダーと創る自律型 AI の実践
このセッションでは、AIエージェントそのものだけではなく、それを支えるAWSのインフラ、セキュリティ、生成AI基盤、そして今後の開発者に求められる考え方まで、幅広いテーマが取り上げられました。
今回はその中でも特に印象に残った3つのテーマについて取り上げます。
Amazon Bedrockとは「万能なモデルは存在しない」という考え方から構成された
Amazon Bedrockについても本セッションで言及されました。
特に印象に残ったのは、「あらゆる用途において万能なAIモデルは存在しない」という考え方です。
ClaudeやGPTなど各企業が提供するモデルやモデルのバージョンごとに得意な処理、速度、コスト、セキュリティ要件などが異なります。Bedrockでは単一のAPIを通じて、複数の企業が提供するさまざまな基盤モデルを利用できるようになっています。
利用者は、すべての処理を一つのモデルに任せるのではなく、目的に応じて適切なモデルを選択することができます。
一方で、利用できるモデルや機能が増えるほど、処理性能やコストの最適化は複雑になります。生成AIでは、入力された文章がトークンに変換され、モデル内部で処理された後、再び文章として返されます。この一連の処理には大きな計算資源が必要です。
リリース当初のBedrockでは、アクセスを複数のサーバーに振り分ける負荷分散構成でした。しかし、すべての要求に同じ応答速度が求められるとは限りません。すぐに結果が必要な処理もあれば、多少時間がかかってもコストを抑えたい処理もあります。
要求ごとに緊急度や優先度を分けることで、利用者はコストを最適化でき、AWS側も計算資源をより適切に配分できます。生成AIの時代には、単に処理能力を増やすだけではなく、「どの処理を、どの速度で、どのリソースに割り当てるか」という設計で利点があります。
このように、利用するユーザー側とAWS側のどちらにも利点のある構成になっており、要件に応じて使い分けることができます。
AIエージェント「Kiro」
続いてKiroについてです。
KiroとはAIエージェント搭載の開発ツール群です。Claude Codeなどと同様に「AIと対話しながら設計から開発まで行える」のが特徴です。今回は主に活用方法について取り上げられていました。
その中で特にAIエージェントを従来の開発方法に無理やり当てはめるのではなく、AIの特徴に合わせて仕事の進め方そのものを変える必要がある、という話が印象に残りました。
従来の開発では、人間がタスクを細かく分割し、一つずつ担当者に割り当てる方法が一般的です。
しかし、自律性の高いAIエージェントに対しては、あまりに細かな指示を与えるのではなく、ある程度広い目的やゴールを伝え、その達成方法をAI自身に考えさせることでより柔軟な開発ができるということです。
AIが検証を繰り返しながら開発を行い、仕様やアーキテクチャを改善していくためです。
型にはめすぎない要件の定義がAIエージェントと開発を行っていく上で大事であると感じました。
これに加え以下の点も重要です。
- 複数のエージェントを活用し並列度を上げる
- 人間の介入が最低限となるようにエージェントを設計し、長時間にわたって自律的に処理を続けられるようにする。
たとえば、より自律的に設計することができれば夜間に複数のAIエージェントが作業を完了させ、翌朝に人間が成果物を確認するという働き方も現実的になりつつあります。
その結果、AIエージェントを活用できる人と、従来の方法だけで仕事をする人との間で、成果の差がより広がっていくことを実感しました。
これから求められる「ルネサンスデベロッパー」
セッションの最後には、「ルネサンスデベロッパー」という考え方が紹介されました。
AIがコードを書けるようになると、エンジニアが不要になる、という考え方ではなくエンジニアとしての在り方を再認識する必要があると感じました。
ルネサンスデベロッパーに求められる要素として、以下の5点があげられました。
好奇心
新しい技術や未知の領域に関心を持ち、自ら学び、実際に試し、その結果からさらに学ぶ姿勢です。AIの進化が速い時代では、一度身につけた知識だけで対応し続けることは難しくなります。継続的に学び、試す力そのものが重要になります。
システム思考
一つの機能だけを見るのではなく、その変更がシステム全体や周囲の業務にどのような影響を与えるのかを考える力です。AIによって実装速度が上がるほど、変更の影響範囲を理解しないまま機能を追加してしまう危険性も高まります。
コミュニケーション
AIが実装を担うようになっても、何を作るのかを決めるのは人間です。利用者の課題を理解し、関係者と認識を合わせ、AIに伝えるべき要件を整理するためには、これまで以上にコミュニケーション能力が必要になります。
オーナーシップ
AIが生成したものであっても、最終的にその成果物に責任を持つのは人間です。AIが作ったから分からない、という姿勢ではなく、生成された内容を理解し、判断し、必要に応じて修正する責任が求められます。
ポリマス(博識であること)
特定の技術だけに詳しいのではなく、技術、ビジネス、デザイン、セキュリティなど、複数の観点を組み合わせて問題を考える力です。AIによって「どう作るか」の負担が減るほど、人間には「何を学び、何を作るのか」を考える力が求められます。
好奇心をもって常に学び試す意識を持ちながら、業務ではシステム全体の影響を考えAIや他メンバーとうまくコミュニケーションをとりながら、自分の成果物に対して責任をもち、幅広い知識と大局的な視点を持って物事を見られる、そんなエンジニアを目指していきます！
本セッションのまとめ
本セッションを通じて技術の進化以上に、開発者自身の役割や考え方が変わろうとしていることが、強く印象に残りました。
IaC コードを資産へ：AWS CDK 社内ライブラリと横断展開
このセッションでは、IaCコードを資産として理想的に運用するにはどうすればよいかが、事例を交えて紹介されました。
IaCは「Infrastructure as Code」の略で、サーバーやネットワークなどのインフラ構成をコードとして管理する考え方です。
コードとして管理することで再現性や変更履歴を確保できますが、プロジェクトごとに独自のコードが増えていくと、別の問題が発生します。
プロジェクトごとに似たコードが作られる問題
組織内では、似た構成のシステムであってもプロジェクトごとにそれぞれIaCコードが作成されることがあります。
しかし、似たコードが複数のプロジェクトに散在していると、機能の追加や仕様変更が発生するたびに、すべてのプロジェクトで個別に対応しなければなりません。
また、プロジェクトごとに書き方や実装方針が異なるため、後から参加した人は、どのコードを参考にすればよいのか判断できなくなります。
コードが存在していても、組織として再利用できる状態になっていなければ、それは十分な資産とはいえません。
私の参画しているプロジェクトでも、「以前のプロジェクトで作ったシェルを参考・使用する」という方法が取られることがあります。
似たようなシェルが乱立したり、記載方法が統一されていなかったりと、現在のプロジェクトでどこまで再利用できるか判断するコストが大きくなることが経験としてあります。
ノウハウが組織全体に広がらない
問題は、コードの重複だけではありません。
プロジェクトごとにIaCコードを管理していると、そのプロジェクトで得られたノウハウも内部に閉じてしまうことがあるという点です。
たとえば、監視や運用に関するルールがプロジェクトごとに異なったり、新しいAWSサービスを活用した構成が他のチームに広がらなかったりします。
その結果、組織内で同じような課題を何度も解決することになり、知識や経験が蓄積されにくくなります。
その解決方法として社内ライブラリによる共通化
こうした問題を解決する方法として紹介されたのが、AWS CDKのコードを社内ライブラリとして整備する取り組みです。
各プロジェクトで得られた知見をライブラリに反映し、別のプロジェクトでも利用できるようにします。
これにより、ライブラリを使うだけで、組織として求められる一定の品質や運用ルールを適用できます。
社内ライブラリは各プロジェクトで得られた知見やノウハウを集約し、組織全体に広げるための場所になります。
プロジェクトの成果物を、そのプロジェクトだけで使い終えるのではなく、次のプロジェクトが利用できる形で残すことで「コードを資産できる」ことを理解しました。
抽象化しすぎない
ここからはライブラリをどう設計していくかについてです。
ライブラリを設計する際の重要なポイントとして、「抽象化しすぎないこと」が挙げられていました。
さまざまなケースに対応しようとすると、設定項目の多い万能なライブラリを作りたくなります。
しかし、何でもできるように設計されたライブラリは、利用者から見ると、何ができるのか分かりにくくなることがあります。
また、多くのプロジェクトに対応させようとした結果、実際にはどのプロジェクトにも適用しにくい、複雑なライブラリになる可能性もあります。
そのため、最初からあらゆる用途を想定するのではなく、特定の利用ケースに焦点を当て、目的が明確なライブラリを作ることが重要です。
特定のプロジェクトに依存させない
抽象化しすぎない一方で、特定のプロジェクトだけでしか使えない設計にも注意が必要です。
プロジェクト固有の名称や設定値をライブラリ内部に直接持たせると、他のプロジェクトでは再利用できません。
共通化する部分と、利用側で設定する部分を明確に分ける必要があります。
万能な仕組みを作るのではなく、「利用目的は限定するが、特定のプロジェクトには依存しない」というバランスが、社内ライブラリの設計では重要だと感じました。
本セッションのまとめ
コードを共通化すること自体が目的ではなく、組織内の知識を継続的に蓄積し、利用できる状態にすることで、社内やプロジェクト全体で活用しやすい資産になるのだと感じました。
アーキテクチャ道場 2026 – AI 時代編！
「アーキテクチャ道場 2026 – AI 時代編！」は、与えられた課題をもとに、システムアーキテクチャのベストプラクティスを考えるセッションです。
セッションでは2テーマが扱われていましたが、今回はそのうちの一つが面白かったので共有します。
テーマは、AIによって開発方法が変わる中で、何を変えるべきなのか、反対に何を変えてはいけないのかについてです。
AIがコードを生成できるようになっても、システムに求められる正しさや安全性が変わるわけではありません。
むしろ、コードの生成量が増えるからこそ、仕様や検証方法をより明確にする必要があります。
AI駆動開発で発生する課題
AIを活用した開発では、解決しなければならない課題が3つあります。
・自然言語には曖昧さがあること。
同じ指示であっても、AIが異なる意味として解釈する可能性があり、本来求める仕様とならない場合があります。
・不具合が混入し、本番環境にデプロイされてから判明すること。
・生成されるコードが膨大になり、プルリクエストの手動レビューが負担かつ開発全体のボトルネックになること。
以降では、これらの課題に対するアーキテクチャの視点からの解決策を紹介します。
曖昧な指示を形式化する
仕様解釈の揺らぎを減らす方法として、自然言語だけで指示するのではなく、一定の形式に落とし込む方法が紹介されました。
今回挙げられたのが、CedarというAWSが開発した安全で読みやすいアクセス制御専用の言語を利用する方法です。
自然言語で書かれた要件をもとに、AIにCedarのポリシーを生成させます。ここで重要なのがAIが作成したポリシーをそのまま正しいものとして扱うのではなく、最終的な内容は人間が確認するという点です。
重要なのは、曖昧だった要件が形式化されることです。
形式化された内容は、システムが判定に利用できるだけでなく、ドキュメントとして残すこともできます。
自然言語だけでは解釈が変わる可能性がありますが、形式化されたルールを併記することで、仕様をより明確な資産として残せます。
ただし、形式だけでは背景や目的が伝わりにくいこともあります。そのため形式化された書式だけで表現できない仕様については、自然言語として仕様を作成します。
期待する振る舞いを参照モデルとして定義する
もう一つの方法として、システムに期待する振る舞いを、シンプルな参照モデルとして表現する考え方が紹介されました。
これは、実装前に期待する結果を定義するという意味で、テスト駆動開発、いわゆるTDD(Test-Driven Development)に近い考え方だと感じました。
AIが生成した成果物と参照モデルの結果が一致した場合は、自動的にマージします。
一方で、期待した結果との差分が発生した場合は、人間にフィードバックし、確認を求めます。
すべての生成物を人間が確認するのではなく、事前に決めた仕様を満たしているものは自動的に処理し、判断が必要なものだけを人間に渡す仕組みです。
これにより、AIが生成する量が増えても、人間は重要な判断に集中できます。
本セッションのまとめ
このセッションで特に重要だと感じたのが、「曖昧さを排除し、仕組みで解決する」ことと「人間と自動化のバランス」です。
Cedarのような言語で曖昧な仕様をより明確にすることで要件と実装のずれをなくすことに加え、参照モデルなどを活用し定型的なものについては人間のレビューを自動化することができ、「品質」と「開発スピード」を仕組みで両立できることが分かり、大きな学びになりました。
全体のまとめ
参加したセッションを通じて「これからはAIをどう使うか？」で生産性が大きく変わることを改めて実感しました。
AIが大量の成果物を生成できるようになるからこそ、「品質」と「開発スピード」を両立する必要があり、それらを解決するためには「AIエージェントの適切な構築」や「要件の形式化」などに加え、「既存資産の有効活用」など様々な視点の取り組みをしていく必要があると感じました。
AWSサミットに参加することで、今回の目的であった未来の解像度を上げることができたためとても有意義な経験になりました。
来年もぜひ参加したいな～と思います。
ここまで見ていただきありがとうございました。