はじめに
こんにちは、ラクです！
delyではAWSを中心にインフラを構築しており、昨年に続き今年もAWS Summitに参加してきました！！（幕張メッセは遠くない！！）
個人的な話として、昨年はサーバーサイドエンジニアとして参加し、今年はSREとして参加したため、実際の業務ですぐに使えそうな知識もたくさん得ることができました。この記事では、特に印象に残ったセッションについて紹介していきます。
印象に残ったセッション
Day1
📌 AWS で生成 AI アプリケーションを構築する時に役立つサービスと組み立て方を学ぼう
生成AIを使ったシステムを開発する際の懸念や工夫などを、実際の事例とともに紹介するセッションでした。
特に驚いたのが、何も知らずにセッションを聞いていたら弊社delyのクラシルの事例が紹介されたことです！AWS Summitで取り上げられることは事前に知っていたのですが、このセッションで紹介されるとは思わずに見ていたので驚きました。
クラシルでのBedrockを活用した事例については、以下のスライドでも紹介していますのでぜひご覧ください！
📌 明日から実践できる AWS でのオブザーバビリティ革新
AWSオブザーバビリティサービスの全体像
AWSが提供するオブザーバビリティスタックは、データ収集から可視化・分析まで一貫してサポートしてくれます。
セッションでは特に触れられていませんでしたが、この図を見てAWS Managed Grafanaの存在を知りました。また、普段自分が主に担当しているクラシルリワードではNew Relicを活用してオブザーバビリティの導入を行っています。
オブザーバビリティ導入でぶつかる課題
実際に導入しようとすると、次のような課題に直面します。
- 部分的な分析：異なるフォーマットのテレメトリが散在し、一貫した分析が困難
- 高い実装コスト：多言語対応の手動計装や既存コードへの大規模改修が必要
- 分析スキルセット不足：膨大なデータの相関分析には高度な専門知識が求められる
- 膨大なデータ・複雑さ：分散システムから生成される大量テレメトリの処理がボトルネックに
これらの課題、実際の現場で経験したことがある方も多いのではないでしょうか？
OpenTelemetryによる標準化とAWS Application Signalsによる統合ソリューション
これらの課題を解決するため、AWSではOpenTelemetryとAmazon CloudWatch Application Signalsを組み合わせたアプローチを提供しています。
OpenTelemetryによる標準化
- CNCFプロジェクトとしてテレメトリ収集仕様を標準化
- ベンダー非依存の統一データモデルを提供
- → 異なるフォーマットのテレメトリ散在問題を解決
AWS Application Signalsによるゼロコード計装
- エージェントによるゼロコード計装をサポート（Java、Python、Node.js、.NETに対応）
- → 手動計装による高い実装コストを削減
（弊社で主に使用しているRubyは対応していないので、使用する場合は素朴にOpenTelemetryを実装することになりそうです。）
Amazon CloudWatch Application Signals の特長
このサービスの特長として、次のような点があります。
- 自動サービス検出／トポロジー可視化：複雑なアーキテクチャをマップで一目把握
- テレメトリ自動収集：AWS Distro for OpenTelemetryを内包し、ゼロコードで取得
- ビルトインダッシュボード：SLO／エラー率／レイテンシーなどを即時確認
- 多次元相関分析：メトリクス・ログ・トレースを一画面で深掘り可能
→ 分析スキルセット不足や膨大なデータ処理の複雑さといった課題を、直感的なUI・自動化機能で解決
デモ事例：Springアプリ×EKS環境での障害検知
セッション中のデモでは、Java/Spring WebアプリケーションをAmazon EKS上で実行し、AWS Distro for OpenTelemetryのゼロコード計装エージェントを適用していました。
意図的に組み込んだ問題をCloudWatch Application Signalsで検知し、次のような流れで解決していました。
- 障害点の特定
- 関連トレース／ログへのジャンプ
- 根本原因の深掘り分析
これがAWSの中で完結して調査できるのは良さそうでした！
📌 クラウドストレージのコスト最適化戦略 - AWS ストレージの賢い活用法
コスト最適化は永遠のテーマですよね。このセッションでは、特にS3のコスト削減について詳しく説明されていました。
Amazon S3 コスト最適化アプローチ
アクセスパターンが既知・予測できるデータの場合
ストレージクラス選定
- ミリ秒アクセスが必要なデータ → S3 Standard / Standard-IA
- 数分～数時間アクセスでも良いデータ → S3 Glacier Instant Retrieval (GIR) / Flexible Retrieval (GFR) / Deep Archive (GDA)
アクセス頻度に応じたクラスを手動で選ぶことで、長期保管データは最大92％のコスト削減が可能だそうです。すごい！
ライフサイクルルール
- オブジェクトの経過日数に応じて自動移行（例：30日で IA、60日で GIR、90日で GDA）
- オブジェクトサイズフィルターで「大容量かつ長期利用」データのみをアーカイブ対象にする
ポイントは、10 MB以上のオブジェクトは2ヶ月で移行メリットが発生するということ。細かいファイルを頻繁に移行すると、移行コストの方が高くなってしまうんですね。
アクセスパターンが不明・変化するデータの場合
S3 Intelligent-Tiering
- 自動で「高頻度／低頻度／アーカイブ即時アクセス」の3階層を移動
- オプションで「アーカイブアクセス／ディープアーカイブアクセス」層へも自動移行
- 監視・自動化料金はごく僅少ながら、最大82～92％のストレージコスト削減を実現
アクセスパターンが読めない場合は、これを使うのが一番楽で確実そうです。
可視化と分析ツールの活用
Amazon S3 Storage Lens（Advanced）
- バケットやプレフィックス単位で15ヶ月分のメトリクスを保持
- 経過日別アクセス分析による「Standard→IA 推奨日」の自動レコメンド機能
ストレージクラス分析
- Standard クラス上の使用量とアクセス頻度を経過日別に可視化し、移行タイミングを判断
データに基づいた最適化ができるのは良さそうでした！
Day2
📌 AI Agent 時代のソフトウェア開発の型 ～ Everything as Code で叡智を伝える ～
AI駆動開発を進めていく中で、Gitリポジトリを見ていればプロジェクトの全てを把握することができる状態を作ることの重要性について話されていました。
「意図」こそが命運を分ける
最初に強く印象に残ったのは、「AIは確率的に動く（Probabilistic）」という本質的な特性です。
人間同士なら曖昧でも通じる"ニュアンス"や"暗黙知"が、AIにはまったく共有できません。したがって、「何を」「なぜ」「どのように」実現したいのか──意図をコード（テキスト）で明示化することこそ、AI駆動開発の要だと感じました。
AI駆動開発は手段に過ぎず、本質的に重要なのは最終的にどれだけのビジネス価値を創出できるかという点です。登壇者の方によると、よく「開発効率はどの程度向上するのか？」「工数削減効果はどれくらいか？」といったROI（投資利益率）に関する質問を受けるそうです。しかし、本当に注目すべきは効率性の向上ではなく、エンドユーザーに提供できる価値の大きさです。
AWS CDKとドキュメントも「型」に落とし込む
具体的な実践例として紹介されたのが AWS CDK を中核に据えた「型」化です。
- インフラもアプリも 全てCDKでコード管理
- 型チェック・自動テスト をCI/CDパイプラインに組み込み
- ドキュメントもMarkdownで構造化し、 "Documentation as Code" として扱う
組織能力（Capability）としてのAI駆動開発
最後に、「個人のスキル」ではなく「チーム／組織の能力」としてAI開発を定着させるための指標・文化づくりにも言及されました。
- デプロイ頻度、リードタイム、MTTR、内製化率 などをKPI化
- 失敗を恐れずナレッジを蓄積し、コミュニティを醸成
- 「型」を反復・改善し続けることで、組織全体にAI駆動の叡智を根付かせる
これによって、単発のPoCやハンズオンにとどまらない、持続可能なAI開発体制の構築が可能になります。
「Everything as Code」は、単なるスローガンではなく、チームの叡智を継承し、高速に価値を届けるための必須戦略です。
おわりに
今回のAWS Summit 2025では、AIやオブザーバビリティ、セキュリティを中心とした技術の動向を知ることができました。特に、SREとしての業務に直結する内容が多く、非常に有意義な参加でした。
また、今回の記事では触れていませんが、個人的にはミニセッションやコミュニティステージでのセッション内容も熱く、大変楽しめました。
学んだ知識を実際の業務に活用していきたいと思います。よければ、皆さんも気になるセッションがあったらぜひチェックしてみてください！
Discussion