こんにちは、マネージドサービス部の加藤です。
今年も AWS Summit Japan 2026 に参加してきました。本記事では私が参加した2つのセッションをレポートします。 今年も雨が降る天気となっていましたが、会場は大賑わいでした。
注記：本記事の内容はセッションの公式見解ではなく、筆者の理解・解釈・感想を含みます。正確な情報は各セッションの公式資料をご参照ください。
目次
セッション1：生成 AI × MCP で切り拓く次世代 SRE！自律型運用への挑戦と開発者体験の進化 {#session1}
KINTO Technologies の粟田啓介さんによるセッションです。
要約
- SRE チームが直面していた「New Relic を導入しても活用が進まない」「障害調査が属人的で重複する」という課題を、生成 AI と MCP で解決した事例の紹介
- New Relic Analyzer を内製開発：アラート検知をトリガーに New Relic からログ・トレースを自動収集し、要約を Slack のスレッドに返信する仕組み
- 把握にかかる時間が 約20〜30分 → 1分 に短縮。複数人の重複調査も解消
- さらに New Relic MCP を組み込み、Slack で
@New Relic Analyzerにメンションするだけで対話形式の深掘り調査が可能に - 会話履歴を Amazon Bedrock AgentCore のメモリに保存し、文脈を踏まえた継続的な調査を実現
- 結果として「ツールを教える」から「AI と一緒に調べる」へシフト。人はアラートの把握作業から解放され、判断と改善に集中できる環境へ
セッション資料は生成AI×MCPで切り拓く次世代SRE（speakerdeck）で公開されています。
感想
このセッションで特に印象的だったのは、「初動の把握はAIに任せ、人はSlack上で対話しながら深掘りする」というフローです。
アラートが鳴るたびに人が New Relic を開いて調査するのは、スキル差・時間・重複という三重の非効率を生んでいます。New Relic Analyzer はその初動を自動化し、Slack というエンジニアが普段いる場所に要約を届けてくれる。さらに MCP との組み合わせで、そのまま Slack 上で「なぜ ECS タスクが落ちたのか」を3回のやり取りで特定できるまでになっているのは、実用性の高さを感じました。
AWS や New Relic に限らず、「ツールを覚えてもらう」教育コストを下げるアプローチとして、普段使いのコミュニケーションツールに AI を組み込む設計は参考になります。
セッション2：ランサムウェア被害を想定した迅速な復旧のためのバックアップ（株式会社SBI新生銀行） {参加session2}
AWS ソリューションアーキテクトと共同で検討した、実際の銀行システムにおけるランサムウェア対策のバックアップ・リストア設計の事例紹介です。
要約
バックアップ/リストアに関する3つの要件を定義し、それぞれへの対応策を検討・実装した内容でした。
3つの要件
| 要件 | 内容 | 狙い |
|---|---|---|
| 要件① | 3-2-1-1-0 ルールの順守（3コピー・2メディア・1オフサイト・1イミュータブル・エラー0） | バックアップデータの保護とリストアの保証 |
| 要件② | バックアップデータにマルウェアが存在しないことを確認 | 復旧後の暗号化等による再被害防止 |
| 要件③ | バックアップデータに「暗号化されたデータ」が無いかを確認 | クリーンなデータを迅速特定し復旧時間を最短化 |
要件①への対応：AWS Backup ＋ マルチリージョン ＋ アカウント分離でバックアップデータの取得・冗長化・改変/削除保護を実現。
リストア環境の設計では2案を比較検討：
- 案1：異なるアカウントでの復旧 → 他システムとの繋ぎ換えをどうするかが課題
- 案2：同一アカウントの異なるVPCでの復旧 → 再構築リソース量・IaC整備の負荷・セキュリティリスクのバランスが必要
オンプレミス側の対策もあわせて検討。オンプレミス⇔AWS間での感染拡大リスクがあるため、両環境での対策アーキテクチャを設計。
なお、要件②③のリストア時適用については、リードタイム（速度）優先かチェック（安全性）優先かというトレードオフが残ります。特に要件③（暗号化データの検出）は現時点でAWSサービス単体での完結が難しく、仕組みを引き続き検討中とのことでした。
感想
AWSソリューションアーキテクトと一緒に設計を進めても、想定外の考慮事項が次々と出てきて予定より時間がかかったという話が印象的でした。「ランサムウェア対策のバックアップ設計は、やってみると思ったより複雑」というリアルを感じました。
3-2-1-1-0 ルール自体はよく知られたベストプラクティスですが、実際の銀行システムに適用しようとすると、要件②③のように「バックアップデータ自体の健全性をどう担保するか」という難しい問題に直面することがわかりました。
リストア時のトレードオフ（速く戻すか・安全を確認してから戻すか）は、事業継続性と安全性のバランスであり、システムの性質によって答えが変わります。自社システムのバックアップ設計を見直すきっかけになるセッションでした。
さいごに
ここまで読んでいただき、ありがとうございます。
今年の AWS Summit Japan 2026 では、AI を活用した運用効率化と、ランサムウェアを前提としたセキュリティ設計という、現場で今まさに求められているテーマのセッションに参加できました。どちらも「実際にやってみて初めてわかった」という当事者ならではの話が多く、非常に参考になりました。
加藤 貴也 (記事一覧)
まだまだAWS学習中
