はじめに
今年もAWS Summitに参加してきました！（幕張メッセは遠くない！！！）
AWS Summitは、AWSの最新技術やサービス、運用事例・ベストプラクティスを学ぶ絶好のイベントです。
delyではAWSを中心にクラウドインフラを構築・運用しており、SREチームとしても日々の業務に活かせる知見を得るために参加しています。
今年は2日間にわたって参加させてもらいました！
この間に社内の業務をカバーしてくれたチームメンバーに感謝です🙏
個人的な印象ですが、今年はAIやSecurity関連のセッションが多いなと感じました。
特にAmazon Bedrockを活用した事例が目立ち、AIサービスの活用シーンが広がっている印象を受けました！
印象に残ったセッション
Day1
📌 「実践的な生成 AI 活用の推進: PoC から価値創出へ」
生成AIを使ってビジネスの価値創出を行うためのポイントや事例、生成AIを活用するためにAWSが提供するBedrockやSageMakerなどのサービスが紹介されました。
生成AIを活用して価値創出を行うためには、4つのポイントが重要であると説明されました。
- Time to Value（価値創出までの時間）
- AI対応データ
- 費用対効果
- 信頼性
SREチームは直接的な機能開発にはかかわらないものの、社内での生成AI活用においても上記4つのポイントを考慮しておくことが重要であると感じました。
特にAmazon Bedrockでは「信頼性」の観点でサービス自体にセキュリティやガバナンスを考慮するための機能（Amazon Bedrock Guardrailsなど）が充実しており、本質的な価値創出に集中できるのは大きなメリットだと感じました。
現時点ではクラシルリワードでAmazon Bedrockを活用できていませんが、今後の活用に向けて検討していきたいと思えるセッションでした。
📌 「生成 AI のためのデータ活用実践ガイド」
自社のデータを生成AIにどう活用していくかやRAG（Retrieval-Augmented Generation）を活用して回答精度を向上させるテクニックが紹介されました。
自動車保険への加入を検討しているユーザーを例としてRAGを活用することでどのように回答精度を向上させていくかをステップごとに解説してくれており、非常にわかりやすかったです。
RAGには状況コンテキスト・セマンティックコンテキスト活用してプロンプトを最適化することで回答精度の向上が期待できるとのことでした
まずはシンプルなNaïve RAGからはじめ、より検索品質を向上させる必要がある場合はAdvanced RAG/Modular RAGへと段階的に進めていくことが推奨されていました。
AWSではAmazon Bedrock Agentsを活用することで複雑なアクションをオーケストレーションすることができるため、RAGの改善が拡張性高く行えるのは大きなメリットだと感じました。
セッションの後半では適切な状況コンテキスト・セマンティックコンテキストを提供するためのソースとして生成AIに必要なデータ基盤の作り方が紹介されました。
「実践的な生成 AI 活用の推進: PoC から価値創出へ」のセッションでも触れられていましたが、生成AIを活用するためには根本的にデータをどう整備して生成AIに与えられるかが重要になります。
構造化データのみならず、JSONなどの半構造データや画像などの非構造データを活用していくことも重要であり、これまでのビッグデータ基盤構築のノウハウを活かしながらAI Readyなデータ基盤を構築していくことが求められます。
加えて、RAGを活用したアプリケーションの開発においては、適切なデータアーキテクチャ（データの収集・管理・利用方法）を考慮した設計が重要であると感じました。
ex. RAGの更新頻度や方法・提供までのレイテンシーなど
今後RAGを活用したアプリケーション開発を行う際には、データ基盤の設計やデータの収集・管理方法をしっかりと考慮していきたいと思います！
📌 「AI によってシステム障害が増える!? ～AI エージェント時代だからこそ必要な、インシデントとの向き合い方～」
AIエージェントの活用が進む中で、デプロイの頻度の増加やシステムの複雑性の増加により、システム障害の発生頻度が高まる可能性があることが指摘されました。
こうした状況におけるインシデントとの向き合い方や、PagerDutyを活用したインシデントレスポンスの事例が紹介されました。
個人的に登壇者と同じ意見を持っており、AIエージェントの活用と同レベルでインシデントの対応や向き合うための仕組みや体制の整備は急務であると感じています。
AIエージェントに対する期待値は高まる一方で弊社でもCursorやClaude CodeなどのAIエージェント活用して日々の開発を行っています。
弊社では現在Opsgenieを活用していますが、サービス終了に伴い、PagerDutyへの移行を検討しています。
現在はNotionでポストモーテムを実施していますが、過去のインシデントの検索や振り返りがしづらい点に課題を感じています。
インシデント管理ツールとして紹介された「jeli」はインシデントからの学びを支援するツールとしてSlackから情報収集やレポートを自動生成するなど機能があり、非常に気になりました！
上記のスライドの意見にも同意で今後少数精鋭かつ開発の民主化が進む中でDevとOpsを分離するのではなくDevOpsの文化を推進していくことは大事だと改めて感じました。
呼び名は違えど、delyでもフルサイクルエンジニアリングの文化を推進しており、開発者が開発から運用のプロセスに責任を持つことを実施しています。
自分たちが実装したコードがどのように動作し最終的なユーザーへ価値提供できているのかを理解することは開発者にとって重要な要素であり、
AIエージェントによるコーディングやAWSなどのクラウドサービスの登場で開発者が担当できる範囲は広がりつつあり、より全体を俯瞰してシステムや開発を推進できるスキルが求められるようになってきていると感じます。
SREとしては、今後もAIエージェントの進化や発展が進む中で開発と運用のバランスを取りながら、安全かつ失敗から学べる文化や仕組みを推進して行きたいなと感じるセッションでした！
📌 「セキュアなソフトウェア開発ライフサイクルのための生成 AI」
セキュアなソフトウェア開発ライフサイクル（SDLC）の概要とSDLCにおけるAWS関連サービスの紹介がありました。
Amazon Q Developerでコーディングやレビューを行えることは知っていましたが、セキュリティの観点からも活用できることを知りませんでした。
コード上のセキュリティの脆弱性やシークレットの意図しない漏洩を検出するための機能があり、セキュリティの観点からも活用できることがわかりました。
Amazon CodeGuru Securityも初めて知りましたが、Amazon InspectorやAWS Security Hubと連携させることで開発時から本番運用の一連のセキュリティを強化できることや 一元的に管理できるため有用だと感じました。
普段のサービス開発において細部までセキュリティを考慮して実装することは実装者のスキルレベルに依存したりすることもあると思います。
こうした開発から本番運用までのサイクルでセキュリティをチェックできるポイントを設けておくことで誰でも透過的にセキュリティを考慮した開発ができるようになるのは大きなメリットだと感じました。
Day2
📌 「AI Agent 時代のソフトウェア開発の型 ～ Everything as Code で叡智を伝える ～」
AIエージェントの時代におけるソフトウェア開発の型や、AIエージェントを活用した開発のプラクティスが紹介されました。
AI駆動開発（AI によるタスクの解決をプロセスに組み込んだソフトウェア開発⼿法）で発生する以下の課題へのアプローチが紹介されました。
- どうすればAIにエンジニアの意図を伝えられるか︖
- どうすれば組織としてAI駆動開発の能⼒を⾝につけられるか︖
Everything as Code（すべてをコードとして扱う）の手法を取り入れることで変更の追跡を可能にして人間だけが知っていることをなくす = AIがすべてを理解できる状態にすることが重要であると説明されました。
実際にデータ分析エージェントをAI駆動開発で構築するデモがあり、どのようにAI駆動開発を行うか説明がありました。
Documentation as Code（マークダウンなどのプレーンテキスト）を対象者や用途に応じて用意しておき、AIエージェントに必要な情報（設計方針や検証方法など）を与えることで実装からテストまでを自律的に完遂できるようにすることが目指されていました。
弊社でもリポジトリにMarkdownを配置して設計方針やディレクトリ構成の説明などを行っていますがDocumentation as Codeをブラッシュアップして整備していくことはもちろんCI/CDといった検証方法の整備も重要であると感じました。
📌 「オンラインゲーム開発におけるプラットフォームエンジニアリングと Amazon EKS による実装例」
オンラインゲーム開発における課題をAmazon EKSを活用して解決するためのプラットフォームエンジニアリングの実装例が紹介されました。
私自身オンラインゲームの開発経験はないのですが、EKS（k8s）を活用したプラットフォームエンジニアリングに興味があり参加しました。
ゲーム開発と運用においては、以下のような課題があることが紹介されました。
- インフラチームがまとめてインフラ運⽤
- サーバー開発と運⽤の効率化のために共通基盤を構築
- ゲームごとに⾃律的にサーバー開発から運⽤まで⾏う
共通化と自律性のバランスを取るために、プラットフォームエンジニアリングの考え方・プラクティスが有効であると説明されました。
また、利用されるプラットフォームにするためには開発者体験や生産性の向上を見込むことができるニーズを把握してMVPを提供することが重要であると感じました。これは既存のプロダクト開発においても馴染みある考え方だったので共感できました。
後半では、Amazon EKSを活用したプラットフォームエンジニアリングの実装例が紹介されました。
EKSを迅速に導入するためのAmazon EKS Blueprintsの紹介やSpotifyが開発しているサービスカタログの「Backstage」、Argo CDを活用したGitOpsでのアプリケーションのデプロイ方法などが紹介されました。
delyでは順調なサービス成長に伴い、サービスや基盤システムの数や依存関係が増えてきており、システム全体の複雑性が増してきています。
また、今後も複数のプロダクトを展開していく中で、共通基盤の構築や運用の効率化は重要なテーマとなると考えています。
EKSを活用したプラットフォームエンジニアリングの考え方や実装例は非常に参考になりました。今後は導入によるPros/Consを検討しながらEKS導入のPoCを行っていきたいと思います！
📌 「アーキテクチャ道場 2025 - 実践編！」
アーキテクチャ道場は、AWSのアーキテクチャ設計のベストプラクティスを学ぶためのセッションです。
個人的に毎年欠かさず参加しているセッションで、今年も非常に有意義な内容でした！
今回は「実践編」として、現実世界の問題解決から学ぶがテーマでした。
特に株式会社ZOZOの事例として在庫更新処理の性能問題を解決するためのアーキテクチャ改善のプロセスが紹介されました。
オンプレミスのDBを使ったまま高負荷の更新を捌きかつ、迫る施策影響までに迅速に課題を解決するというまさにアーキテクトの腕の見せ所といった内容でとても面白かったです。
アプローチとしては、更新処理の非同期化と在庫数を管理するテーブルをKVSに切り出すことによって更新によるロック競合を回避し、更新処理の負荷を軽減することが紹介されました。
クラシルリワードもtoC向けのサービスでトラッフィクが年々増加しており、施策や外部との連携によるデータ更新の負荷が高まっています。
すでにShoryuken(SQSをキューとして利用するRubyのバックグラウンドジョブフレームワーク)を活用して非同期化を行うことで瞬間的な負荷を分散させるようにしていたりします。
今後もアーキテクチャの改善やパフォーマンスの最適化を行う際には、今回の事例を参考にしながら、非同期化やKVSの活用を検討していきたいと思います！
普段のSRE活動と照らして感じたこと
AWS Summitに参加したことで今後のSREには以下のような取り組みが大事かなと感じました。
- AIの積極的な活用環境とガードレールの整備
- AIエージェントの活用においては、開発者が意図を伝えやすくするためのドキュメントやコードの整備が重要であり、これを支援するツールやプラクティスの導入や社内での共有や布教活動が求められる
- 避けられないAIの進化に対して適切なセキュリティや信頼性を担保するための言わばガードレールの整備を行うことで一人ひとりの開発者が安心してAIを活用できる環境を整え、よりユーザーへの価値提供に集中できるようにする
- プラットフォーム化・共通基盤の整備の加速
- サービスの成長や多様化に伴い、SREとしての対応範囲が広がってきています。これに対処するためには、CI/CD、監視、権限管理などの共通基盤をモジュール化・サービス化し、個別最適を減らす取り組みが鍵となると感じました。
おわりに
AWS Summit Japan 2025は、技術的にも文化的にも多くの学びが得られるイベントでした!
今回はAWS主催のセッションを中心に参加しましたがAWS Village StageやCommunity Stageでも魅力的なミニセッションが行われており、そちらにも参加したかったです…！
今後もこのようなイベント参加を通じて知見を自社に還元しながら、外部への発信も積極的に行っていきたいと思います！
delyでは、AWSを中心にクラウドインフラの構築・運用を行っており、SREだけでなくバックエンドエンジニアもAWSを活用した実装やシステム運用を行っています！
バックエンドエンジニアやSREとしてAWSを活用した開発・運用に興味がある方は、ぜひ一度お話ししましょう！
Discussion