こんにちは～ 浮田です。
合田ですー！
佐野（マナティ）です！！
今回は、AWS Summit Japan 2026に参加してきましたので、参加レポートをお届けします！
どのセッションも学びが多く、AWSの最新技術や実際の活用事例、そして今後の業務にも活かせそうな考え方をたくさん得ることができました。
AWS Summitって何？と気になる方は、以下の記事もご覧いただければと思います！
https://cx.genech.co.jp/column/20260626
今回は、それぞれのメンバーが参加して学んだセッションの内容を要約してお届けします。
それでは行ってみましょう！！
■ 「Amazon S3 セキュリティベストプラクティス」
浮田は、AWS Summit Japan 2026のブレイクアウトセッション「Amazon S3 セキュリティベストプラクティス」を聴講してきました。予約は満席で当日参加枠での聴講でしたが、会場は8〜9割ほどの入り。S3を触る人なら誰でも持ち帰れる、実践的な内容でした。
● 印象に残ったこと
一番印象に残ったのは、S3のセキュリティが「バケットを公開しないよう設定に気をつける」ことだけではない、という点です。S3がデフォルトで守ってくれる範囲に、利用者が8つのベストプラクティスで積み増していく、という構造で全体像が示され、とてもわかりやすかったです。デフォルト保護は年々広がっていて、2026年4月からはSSE-Cがデフォルトで無効になりました。
また2025年11月発表の新機能では、組織レベルでBlock Public Accessを一括強制できる宣言的ポリシーや、タグでアクセスを制御するABAC対応が実用的で、組織がスケールしてもIAMポリシーを更新し続ける負担が大きく減ると感じました。
● 気を付けるべきこと
SSE-Cのデフォルト無効化は、2025年に観測されたCodefingerランサムウェアへの対策です。盗まれた認証情報で顧客提供キーを使ってオブジェクトを暗号化される手口だったので、特別な要件がなければSSE-Cは使わず、SSE-S3 / SSE-KMSに寄せるのが安全です。着手は役割別に考えるのが現実的で、開発者は手元のバケット(ログやチェックサム)から、組織リーダーは組織全体のガードレールと監査基盤から。完璧を目指さず、できるところから1つずつ積み上げていきましょう。
8つのベストプラクティスの中身や、403エラーの課金ルール、耐久性・リカバリの打ち手といった詳細は、別の記事にまとめています。あわせてご覧ください。
AWS Summit のブレイクアウトセッション「サーバーレス API のセキュリティ ─ API 認可の基本を押さえ、AI エージェント時代に備える ─［CNS315］」に参加してきました。
正直なところ、これまで認証・認可は「とりあえず Cognito 入れておけばOK」くらいの感覚でした。でも今回、その手前にも奥にも、知らない世界が広がっていることを思い知らされました。
● 印象に残ったこと
は、API セキュリティが「認証・認可」だけの話ではなかったことです。その土台に IAM があり、Inspector や GuardDuty、WAF などを重ねる「多層防御」という考え方がある。そして OAuth 2.0・OIDC・Verified Permissions という基礎が、そのまま AI エージェントの認可（AgentCore Identity）まで一本でつながっていく構成が、とても腑に落ちました。
● 気を付けるべきこと
として刺さったのは、認可はバックエンドで効かせるべき、という点です。UI でボタンを隠すだけでは防御にならず、API を直接叩かれたら素通りしてしまう。本丸の判定は必ずサーバー側で、というのは自分への戒めになりました。
学んだ内容は別記事に詳しくまとめています。よければあわせてご覧ください。
佐野が聴講してきたDEV250「『勝手に広まる』人気 AI エージェントを爆速で作ろう！」では、AIエージェントを自前で構築する意義や、実際に使われるプロダクトにするための工夫が紹介されていました。
最近は、オフィススイートに付属するチャットボットや、コーディング支援AIなど、既製品のAIエージェントも増えています。
一方で、自社固有の業務データを参照したい、既存システムにAI機能を組み込みたい、UIまで含めて自社サービスとして作り込みたい場合は、自前で構築する価値があるという整理が印象的でした。
技術面では、Strands Agents や Amazon Bedrock AgentCore、AWS Amplify、Amazon Bedrock ナレッジベースなどを組み合わせることで、AIエージェントをかなり素早く構築できることが紹介されていました。
特に印象に残ったのは、AIエージェントは「作れるかどうか」よりも、どのユースケースに当てるかが重要だという点です。
実際の事例として紹介されていた「パワポ作るマン」は、スライド作成という多くの人が困りやすい業務にフォーカスしていました。
Web検索やURL読み込み、Marpを使ったスライド生成、PPTX/PDF出力など、ユーザーが欲しい成果物まで一気に作れる形になっており、リリース後も継続的に使われている点が印象的でした。
また、使われるアプリになるほどLLMの利用料も増えるため、モデル選定やプロンプトキャッシュ、会話履歴のトリミングなど、コスト最適化も重要になります。
AIエージェントはPoCで終わりがちな印象もありますが、実運用を見据えると、UX・運用・コストまで含めて設計する必要があると感じました。
AWS CDK 社内ライブラリと横断展開
もう1つ印象に残ったのが、DEV352「IaC コードを資産へ：AWS CDK 社内ライブラリと横断展開」です。
このセッションでは、各プロジェクトで個別に管理されていたIaCコードを、AWS CDKの社内ライブラリとして集約し、プロジェクト横断で再利用できるようにした取り組みが紹介されていました。
プロジェクトごとに似たようなIaCコードをコピペして管理していると、同じ修正を何度も行う必要があります。
また、監視・ログ・セキュリティ・可用性といった運用上のベストプラクティスも、プロジェクトごとにばらつきが出てしまいます。
そこで、よく使うAWS構成を CDK Construct として社内ライブラリ化し、各プロジェクトで再利用できるようにしていました。
CDK Construct とは、簡単に言うと、AWSリソースの構成をまとめた「再利用可能な部品」のようなものです。
例えば、Lambda、API Gateway、CloudWatch Logs、アラーム設定などを毎回個別に書くのではなく、あらかじめ社内標準の設定を含んだ部品として用意しておくことで、各プロジェクトではそれを呼び出すだけで同じ品質の構成を作れるようになります。
これにより、一箇所の改善を複数のプロジェクトへ展開できるようになり、ログ設定や監視、セキュリティといった運用上のベストプラクティスも統一しやすくなります。
この取り組みで得られるメリットとして、次の3点が特に印象に残りました。
また、CDK Construct の設計ポイントとしては、抽象化しすぎないこと、再利用しやすい単位でまとめること、そして修正や改善を共通ライブラリ側でまとめて管理できるようにすることが紹介されていました。
特に「抽象化しすぎない」という話は、自分の業務にも活かせそうだと感じました。
便利だからといって何でも詰め込むと、かえって中身が見えづらくなり、利用者にとって扱いづらいものになってしまいます。
使いやすさと責務の分離のバランスを取ることが、社内ライブラリを継続的に使ってもらう上で重要だと感じました。
合田が聴講し印象に残ったセッションの一つが、AIM342「本番運用を見据えた AI エージェント - Amazon Bedrock AgentCore を活用したベストプラクティス」です。
AIエージェントは、PoCや簡単なデモであれば比較的作りやすくなってきています。一方で、実際に業務で使い続ける本番運用を考えると、精度・コスト・セキュリティ・運用監視など、検討すべきことが一気に増えます。このセッションでは、AIエージェントを本番環境で継続的に運用するための9つのベストプラクティスが紹介されていました。
特に印象に残ったのは、「課題から逆算して小さく始める」という考え方です。最初から何でもできるAIエージェントを目指すのではなく、解決したい課題や期待する成果物を明確にし、PoCで検証することが重要だと紹介されていました。
また、「コードで実現できることはコードで実装する」という考え方も参考になりました。AIは推論や判断が必要な部分に活用し、計算、条件分岐、ルールベースの処理は従来どおりプログラムで実装することで、処理速度やコスト、品質の面でメリットがあります。AIにすべてを任せるのではなく、AIが得意な部分とコードが得意な部分を切り分けることが、本番運用では重要だと感じました。
さらに、AIエージェントは作って終わりではなく、回答品質やコスト、レスポンス時間、ハルシネーションの有無などを継続的に監視・評価する必要があります。セッション内では、ObservabilityやEvaluationsを活用し、トレースや評価結果を確認しながら改善していく考え方も紹介されていました。
現在、私自身もAIを活用した業務改善に取り組んでいるため、本番運用を見据えた設計や運用の考え方は非常に参考になりました。PoCで動くものを作るだけでなく、実際に利用され続けるサービスにするためには、評価・監視・改善の仕組みまで含めて設計する必要があると感じたセッションでした。
もう一つ印象に残ったのが、AIM360「AIエージェントの推論から大規模学習まで コスト効率と性能が両立するAIインフラ － AWS Trainiumの全貌」です。
生成AIの活用が進むにつれて、GPUの確保や学習・推論コストが大きな課題になっています。モデルを学習するにも、推論を大量に実行するにも高性能な計算リソースが必要であり、コストやキャパシティの問題は避けて通れません。このセッションでは、それらを解決する選択肢として、AWSが独自に開発しているAIアクセラレータ「Trainium」が紹介されていました。
AWSは、CPUのGravitonや仮想化基盤のNitroだけでなく、AI向けにも独自チップを開発しています。Trainiumはその一つで、機械学習の学習・推論に向けて、性能だけでなくコストや電力効率も考慮して設計されている点が印象的でした。クラウドサービスというとソフトウェアやサービスの印象が強いですが、チップレベルから最適化しているという点に、AWSのAIインフラへの力の入れ方を感じました。
セッションでは、Trainium2やTrainium3の紹介もありました。Trainium2では大規模モデルの学習や推論を低コストで実現でき、Trainium3ではさらに性能やメモリ帯域が強化されています。また、AnthropicやOpenAIでもTrainiumを活用する取り組みが進められていることが紹介されており、AIインフラの新たな選択肢として存在感が高まっていることを知ることができました。
使い方としては、既存のPyTorchコードをなるべくそのままTrainium上で動かす方法や、vLLMを使って推論コストを固定化する方法、さらに性能を最大限引き出すためにNeuron Kernel InterfaceやNeuron Explorerを使って最適化する方法などが紹介されていました。最初から難しい最適化を行う必要はなく、用途に応じて段階的に活用できる点が分かりやすかったです。
AIモデルの性能や精度に注目しがちですが、それを支えるインフラも同じくらい重要です。今後AIを業務に活用していく上では、「どのモデルを使うか」だけでなく、「どの基盤で動かすか」「継続利用したときにコストはどうなるか」という視点も持つことが大切だと感じました。GPU以外の選択肢としてTrainiumを知ることができた、学びの多いセッションでした。
AWS Summit Japan 2026では、幅広いテーマのセッションを通して多くの学びを得ることができました。
特に印象的だったのは、どのセッションでも単に「新しい技術を使う」だけではなく、「実際の業務でどう活用するか」「継続的に使われる仕組みにするにはどうするか」という視点が大切にされていた点です。
AIエージェントであれば、PoCで動くものを作るだけでなく、本番運用を見据えた設計・評価・監視・コスト最適化が重要になります。
S3やCDKのセッションでは、日々の開発や運用において、セキュリティや標準化をどのように組織全体へ広げていくかを考える良いきっかけになりました。
また、普段の業務では触れる機会が少ないTrainiumのようなAIインフラについても知ることができ、生成AIを支える基盤技術の重要性も改めて感じました。
さらに、セッション終了後には「Ask the Speaker」という時間が設けられており、講演者の方へ直接質問できる場もありました。
講演の中では聞けなかった内容について質問されている参加者も多く、セッションを聞いて終わりではなく、登壇者と直接コミュニケーションを取れる点は、AWS Summitならではの魅力だと感じました。
AWS Summitは、AWSの最新情報を知るだけでなく、実際の活用事例や他社の取り組み、そして現地でのコミュニケーションを通して、自分たちの業務に活かせるヒントを得られる貴重な場でした。
今回学んだ内容を、個人の知識として終わらせるのではなく、社内でのナレッジ共有や今後の開発・提案活動にも活かしていきたいと思います。
来年以降も機会があればぜひ参加し、引き続きAWSの技術や活用方法について学びを深めていきたいと思います！