【参加レポート】AWS Summit 2025 に参加してきました！

はじめに

鈴木です。
2025年6月25日、26日に開催された AWS Summit 2025 に参加してきました！
本記事では、私が聴講したセッションの概要や、特に印象に残った点などをまとめていきたいと思います。

今年の参加目的は以下の通りです。

• 普段触れない分野の知見を広げるため
• セキュリティに関する他社の事例を学ぶため

1日目

パナソニック エオリア アプリにおける、ユーザージャーニーを起点としたサービスレベルマネジメントの導入と実践

概要

エオリアアプリとは

Amazon ECS,AWS Fargate,Amazon EC2,AWS Lambda等で構成
様々な機能を追加し構成が複雑化

1. システム運用における監視の目的

システムの安定稼働と高品質なサービス提供を維持するため、以下の状況を把握し、迅速な対応を行うことを目的としてアラートが設定されます。

• 障害の発生: システム停止やパフォーマンスの低下など、ユーザーへのサービス提供に直接的な影響が出ている状態。
• 障害の予兆: 上記のような問題が近い将来発生する可能性を示す兆候。

2. 監視手法の変遷

アンチパターン：従来の監視

• OSメトリクス中心のアラート: CPU使用率やメモリ使用量といった、インフラ中心の監視。これだけでは、ユーザーが実際にサービスを利用できているかは判断できない。

デザインパターン：推奨される監視

• ユーザー視点の監視: アプリケーションがユーザーにとって正常に機能しているかを直接的に監視する。

3. 技術進化と監視の課題

テクノロジーの進化に伴いシステム構成は複雑化している。その結果、以下の課題がある

• 原因調査の困難化: システムが複雑になることで、問題発生時の原因特定に時間がかかるようになった。
• ユーザー視点の欠如: 個々のコンポーネントの監視に終始し、サービス全体がユーザーにどう影響しているかの把握が難しくなっている。

4. 「監視」から「オブザーバビリティ（可観測性）」へ

このような課題を解決するため、従来の「監視」から「オブザーバビリティ」への移行が求められる。

• 監視（Monitoring）: システムの特定の要素や出力を継続的にチェックする活動。
• オブザーバビリティ（Observability）: システム全体のデータをリアルタイムに収集・関連付けし、常にシステムの状態を多角的に把握することで、問題の予防や改善に繋げる状態を指す。これにより、ユーザージャーニー全体を通したサービス品質の向上が可能になる。

5. NEW Relic導入理由

• エンジニアが抱える課題
  無駄なアラートが多い、監視内容・運用体制が顧客満足の向上に繋がっているかわからない
  ユーザー影響がわかりにくい、サービス状態が見える化できていない(管理すべきSLI/SLOが決められていない)

6. 導入決定後の取り組み

• 取り組み
  UJの整理→CUJの特定→SLI/SLOの仮決め→ログ/メトリクス設計→実装→Runbook(構成、インシデント)改善→SLI/SLO計測・見直し

・UJ(ユーザーが製品やサービスを利用して目的を達成するまでの一連の行動を可視化)
・CUJ(UJのなかでも優先度が高いもの)
・SLO(Service Level Objective・サービスレベル目標):サービス提供者がユーザーに提供するサービスの品質目標を数値で表したもの
SLI(Service Level Indicator・サービスレベル指標):SLOの達成を判断するために使用される主要なメトリクス

• UJの洗い出し
  エオリアアプリとしてのユーザー体験をワークショップで洗い出し
  付箋を使ってGoal Taskの意見を書き出す

• CUJの検討
  洗い出したUJを「頻度」「重要度」から優先順位を決定

• SLI/SLOの仮決め
  優先度の高いCUJからSLI/SLOを策定

• 設計・構築
  策定したCUJを達成するためのSLI/SLO監視のための設計を行い、監視ツールの構築(NewRelic)

• SLI/SLOの見直し
  設定している内容を満たしてもユーザー満足につながっていない場合
  アラートが発生してもユーザーへの影響が認められない等・・・

7. まとめ

• SLI/SLOの策定により変化したこと
  エラーがどの程度サービスに影響があるかわかりやすく
  SLI/SLOが共通言語となり、DevとOpsのコミュニケーションも取りやすくなった

---

所感、重要な点
ユーザーが実際にする体験を起点にシステムの健全性を判断する
SLI/SLOを策定して障害を未然に防ぐ、サービスのパフォーマンスを継続的に改善していける
監視については目に見えるところが正常か異常かくらいの形式的な考えしか持っていなかったし、学ぶところはあると思う

Amazon SageMaker HyperPod を利用した日本語 LLM (Swallow) の構築

概要

Swallowプロジェクト は、東京科学大学と産業技術総合研究所（産総研）による共同研究プロジェクト。Meta社のLlamaやGoogle社のGemmaといったオープンモデルを基盤に、日本語に強い大規模言語モデル（LLM）を開発することを目的とする。

---

開発手法とAWSの活用

継続事前学習

オープンモデルは、そのままでは日本語能力が弱い。そこで、日本語、英語、コードで独自に収集したデータセット を使い、追加で学習させる 「継続事前学習」 という手法をとる。

• 利点 : ゼロから開発するより低コストで済む。
• 欠点 : 元となるモデルの構造やライセンスに縛られる。
  

成果

• 近年のモデルは数学・コードの能力が高くなっているというトレンドがある。それに追随するため、Swallowプロジェクトでも強化を図っている。
  

• リリースモデル
  

• 日本語理解の強化
  生成タスクではGPT-4o　相当
  
  日本語QA能力の強化により達成
  

• コード能力・数学能力の強化
  青はMeta社が当時リリースしたLlama3.1、大きく強化されている
  独自のコーパス「SwallowCode」「SwallowMath」を使用することで達成
  
  

• 独自のデータを使い、学習効果を上げている(「SwallowCode」「SwallowMath」公開中)
  

AWSによる効率化

近年のLLMのトレンドである数学・コード能力の向上を達成するため、AWSのサービスを活用して高速かつ効率的な開発環境を構築した。

近年のモデルは数学コードレベルがあがっている。Swallow Projectも他のモデルに追従するため、AWSを活用して成果を上げた。

1. SageMaker HyperPod

   • 国立研究機関は大学に付随しているスーパーコンピューターを利用して研究開発を行っている。
     EC2等では1つのインスタンスタイプで立ち上がるため環境移行のコストが大きい。 SageMaker HyperPod を使うことで、設定次第で スーパーコンピュータに匹敵する環境 を構築できる。内蔵のジョブスケジューラーが多数のGPUノードを最適に管理・スケジューリングし、大規模な学習を効率的に実行する。
     

2. Amazon Managed Service for Prometheus(AMP) と　AWS Grafana
   Amazon Managed Service for Prometheus(AMP) ：データ収集
   AWS Grafana　：データ可視化

   • 基盤学習時に発生する障害を収集→エラー発生時の問題救命を迅速化
     

3. 学習データの高速供給：FSx for Lustre & S3
   高価なGPUをデータ読み込みで待たせ、遊ばせる時間をなくすことが重要だ。そこで、以下のワークフローを構築した。

   • 普段、データは安価なオブジェクトストレージである S3に保管 しておく。
   • 学習を開始する直前に、S3から超高速なファイルシステムであるFSx for Lustreへデータを転送する。
   • 学習中はFSx for Lustreからデータを高速供給することで、GPUの待機時間を最小化する。
     

---

まとめ

Swallowプロジェクト は、オープンモデルに追加学習を行うコスト効率の良い手法で、日本語に特化したLLMを開発している。
SageMaker HyperPod による柔軟な大規模計算環境と、S3とFSx for Lustreを組み合わせたコスト効率の良い高速データ供給基盤、AWSをうまく活用し成果を上げている。

所感
スパコン級の環境をクラウドで柔軟に構築できるSageMaker HyperPod、AWSの強みを感じた。
SageMaker HyperPod →　FSx for Lustre　→S3　の設計は性能は発揮しつつコストを抑える工夫を感じた。

セキュアなソフトウェア開発ライフサイクルのための生成 AI

概要

セキュアなソフトウェア開発ライフサイクルのための生成 AI

Amazonの生成AIツール群（Amazon Q Developer, Amazon Inspector, Amazon CodeGuru Securityなど）を活用し、ソフトウェア開発の全工程（ライフサイクル）にセキュリティを組み込む

シフトレフト

ソフトウェア開発の工程(企画→要件定義→設計→実装→テスト→リリース)において
上流の早い段階（要件定義など）からセキュリティ対策を行うという考え方
開発の後半で脆弱性が見つかると、修正コストや時間が膨大になるため、この考え方が重要。

開発ライフサイクル全体でのセキュリティ対策

ソフトウェア開発の各段階で、以下のようにAWSリソースを活用してセキュリティを確保する

Plan

AmazonQ Developper in Consoleを活用
AmazonQ DevelopperがAWSアカウント内のリソースを理解した上で、
セキュリティのベストプラクティスに基づいたアーキテクチャを会話形式で検討する。最適化を図る。

Create

開発者はIDE（統合開発環境）内で Amazon Q と対話しながらコーディングを進めらる。

Test & secure

コードレビューもAIが支援し、セキュリティ上の問題だけでなく、分かりにくいコードの修正案まで提案する。
同時に Amazon CodeGuru Security がコードの静的解析を行い、開発ライフサイクル全体で脆弱性を継続的に可視化する。

Operate

AmazonQ Developper　運用調査機能を活用し、CloudWatchから得られた運用ログから問題点の仮説を提供する。
迅速に問題の解決を図ることが可能

まとめ

• シフトレフト: 開発のできるだけ早い段階からセキュリティを組み込み、手戻りによるコスト増大を防ぐことが極めて重要
• 継続的な監視: リリースして終わりではなく、本番環境にデプロイされた後も、新たな脅威に対応するために脆弱性スキャンを継続することが不可欠

2日目

2日目は、より技術的にディープなセッションを中心に聴講しました。

tenki.jp に学ぶセキュリティインシデント発生時の即応に必要な事業判断とエッジサービス活用

概要

「tenki.jp」は、平常時でも 1時間に50万～150万セッション を処理し、大地震や台風などの突発的なトラフィックスパイクにも対応可能な大規模サービスである。

しかし、ある時 最大60Gbps超 という、これまでの災害トラフィックとは比較にならない大規模なDDoS攻撃を受けた。その結果、災害時でも安定稼働していたサービスが 約2週間にわたり断続的に停止 する事態に陥った。

---

インシデント対応のフェーズと教訓

このインシデントへの対応は、短期・中期・長期の3つのフェーズで進められた。

1. 短期対応とその限界
   • ゴール : 通常稼働の即時回復。
   • 方針 : 効果は度外視し「すぐできること」を優先。システムの大きな変更やコストをかけずに、クラウドインフラの機能で即応しようと試みた。
   • 結果 : 不十分だった。 サービスは断続的に停止し続け、このアプローチだけでは現代のDDoS攻撃に対応できないことが明らかになった。
2. 中期対応とソリューションの選定
   • ゴール : 未知の攻撃も視野に入れた、恒久的な防御策の導入。
   • 選定ポイント : 緊急時に多くの選択肢を比較検討する時間はないため、以下の2点を軸にソリューションを選定した。
     1. 導入・検証の容易さ : 稼働中のシステムに大きな影響を与えず、スムーズに導入・検証できること。
     2. ”生態系（エコシステム）”の存在 : 導入して終わりではなく、継続的な改善を支える周辺ツール、事例、サポート体制が充実していること。
   • 結果 : これらの要件に基づき、**AWSソリューション（Amazon CloudFront, AWS WAF）**の導入を決定した。
3. 長期対応
   • ゴール : 継続的な改善とオペレーションの定着。
   • 方針 : 防御ツールを導入して終わりではなく、PDCAサイクルを回し、定期的に運用を見直し、改善し続ける。
     
     

---

AWS導入の成果と「生態系」の強み

Amazon CloudFrontとAWS WAFの導入後、DDoS攻撃への耐性は飛躍的に向上し、実際に再度DDoS攻撃を受けた際も、サービスを停止させることなく継続提供が可能となった。

この成功は、AWSの技術的優位性だけでなく、 PDCAサイクルを適切に回した運用面の成果 でもある。その運用を支えたのが、AWSの持つ 「生態系（エコシステム）」 。

• AWSの生態系とは:
  • 豊富な導入事例とノウハウの蓄積
  • 連携可能な周辺ツールや管理機能の充実
  • 専門的なナレッジサポート
  • 多様な強みを持つAWSパートナー企業の存在
    

---

まとめ

• サイバー攻撃は大規模化・複雑化している。
• インシデント対応では、エンジニアとビジネスサイドがそれぞれポリシーを持ち、密にコミュニケーションを取ることが重要。
• AWSの強みは、個々のサービスの技術的優位性だけでなく、事例・サポート・パートナーといった「生態系」全体にある。
• 

所感
技術的な対策だけでなく、緊急時の判断基準を決めることも重要だと感じた。

まとめ

今回のAWS Summit 2025では、特に 普段触れない分野(生成AI) と セキュリティ(オブザーバビリティ) という2つのテーマを中心にセッションを聴講しました。
参考になる事例を交えてのセッションも多く参考になりました。
また、2日間を通して、AWSの進化の速さと、それを活用するビルダーたちの熱量を肌で感じることができ、非常に良い刺激になりました。

おわりに

最後までお読みいただきありがとうございました。
この記事が、AWS Summitに参加された方の振り返りや、参加できなかった方への情報共有の一助となれば幸いです。