🦈
JAWS-UG SRE支部 #13 イベントレポート
「レベル400の話を聞いてポカンとしましょう」——2025年7月23日に開催された「JAWS-UG SRE支部 #13」は、そんな挑戦的なテーマで幕を開けました。「レベル400」とは、AWSが定めるセッション難易度の最高峰。それは、単なるサービスの紹介ではなく、アーキテクチャの深層や、テクノロジーが機能する根本原理を解説するエキスパート向けの領域を意味します。
この夜、壇上に立った3名の「つよつよSRE」たちが語ったのは、まさにその名にふさわしい、信頼性を支えるための「秘伝のタレ」でした。AIが人間の同僚としてAWSを操作する未来、AIが障害対応の初動を担う現在、そして、SREが決して抗うことのできない観測性の「物理法則」。
本レポートでは、これら3つのセッションを紐解き、現代のSREが到達した技術の深淵と、私たちが明日から向き合うべき課題を明らかにします。
『転職したらAWS MCPサーバーだった件』
株式会社スリーシェイク / nwiizo氏
最初のセッションは、「もし自分がAWSのMCPサーバーとして働くことになったら…？」という、奇想天外な一人称視点の物語から始まりました。体調不良のため急遽オンライン登壇となったnwiizo氏ですが、その語り口は、私たちをMCPという新たな世界の住人へと引き込みます。
彼が紹介したのは、AWS公式リポジトリで開発が進む**aws-mcp-servers**。これは、50以上のAWSサービスや関連ツールを自然言語で操作するための、MCPサーバー群の巨大な集合体です。
「オフィスに行くと、同僚はみんな自分のことを『サーバー』と呼んでいた。『はじめまして、私は全体の司令塔、Core MCPサーバーの山田です』と…」 —— nwiizo氏
このユーモラスな寸劇を通して、nwiizo氏はaws-mcp-serversの洗練されたアーキテクチャを解説しました。
Core MCP: ユーザーからの曖昧なリクエスト（例：「EC2を自動スケールさせたい」）を解釈し、後述の専門サーバーへタスクを適切に振り分ける**「司令塔」**。
Documentation MCP: 公式ドキュメントをリアルタイムに検索し、最新の仕様やベストプラクティスを回答する**「図書館司書」**。ドキュメントの鮮度を判定するアルゴリズムまで内蔵しているという徹底ぶりです。
API MCP: 実際にAWSのAPIを実行する**「オペレーター」**。プロンプトインジェクションなどを防ぐため、3段階の安全装置が組み込まれています。
このセッションで示されたのは、単一の巨大なAIに全てを任せるのではなく、責務が明確に分離された複数の専門エージェントが協調して動作するという、未来のAIシステムの設計思想でした。aws-mcp-serversは、AWSを操作するためのツールであると同時に、私たちがAIエージェントを構築する際の、最高の参照実装（リファレンスアーキテクチャ）でもあるのです。
『生成AIを活用した障害対応初動の改善』
アマゾンウェブサービスジャパン合同会社 / 津郷光明氏
AIがシステムの構成管理を担う未来像に続いて、AWSの津郷氏は、AIが「障害対応」という極めてリアルで切迫した課題を解決する、現在の実践例を披露しました。
障害対応の現場は、時間との戦い、正確性の要求、そして意思決定のストレスに満ちています。特に難しいのが、「今すぐ対応すべきか」「どこから手をつけるべきか」という優先順位の判断です。
「この判断を、感覚ではなくデータに基づいて行うために、私たちはMulti-layered Observabilityと生成AIを組み合わせるアプローチを提案します」 —— 津郷 光明氏
津郷氏が提唱するMulti-layered Observabilityとは、従来のインフラ層、アプリケーション層の監視に加え、ユーザー影響や収益といったビジネス層のメトリクスまでを統合的に観測する考え方です。
この考え方を具現化したのが、AWSがサンプルとして公開している**「Failure Analysis Assistant (FA²)**」です。
障害発生時、運用担当者はSlackのフォームにエラーの概要と発生時刻を入力。
Lambda上で稼働するAIエージェントが起動し、CloudWatchのログやメトリクス、X-Rayのトレース情報などを自動で収集。
さらにRAG（Retrieval Augmented Generation）を用い、S3に保管された設計書などの関連ドキュメントも参照。
収集した全ての情報を総合的に分析し、数分で障害の根本原因、ビジネス影響、推奨される対策をまとめたレポートをSlackに返却。
FA²は、人間であれば数十分、あるいは数時間かかっていたであろう初動調査を、わずか数分で完了させます。これにより、私たち人間は、時間のかかるデータ収集から解放され、レポートに基づく最終的な意思決定という、最も重要なタスクに集中できるのです。AIは、信頼性の最後の砦である人間の判断を、高速かつ正確な分析で支援する「最高の副官」となりうることを、このセッションは力強く示しました。
『メトリクスインターバルについて』
アマゾンウェブサービスジャパン合同会社 / 山口能迪氏
イベントの最後を飾ったのは、AWSの山口氏による、観測性の根源に迫る、まさに「レベル400」のセッションでした。テーマは**「メトリクスインターバル」**。一見地味なこの技術的パラメータが、実はSREの活動全体を支配しているという、衝撃的な事実が明かされました。
「皆さんのオブザーバビリティシステムには、抗うことのできない物理法則があります。それがメトリクスインターバルです。CloudWatchの基本モニタリングは5分間隔。これを念頭に置いて話を聞いてください」 —— 山口 能迪氏
SREの基本は、SLO（サービスレベル目標）と、それを下回ることが許される「エラーバジェット」の管理です。しかし、山口氏が示したのは、このエラーバジェットと、障害を検知するまでの平均時間（MTTD）との間にある、冷徹な数学的関係でした。
例えば、多くのサービスが目標とする「99.99%（Four Nines）」の可用性。これを月間のエラーバジェットに換算すると、わずか4分20秒です。 もし、あなたのシステムの監視間隔がCloudWatchのデフォルトである5分だった場合、障害が発生してから次のメトリクスが収集されるまでの間に、エラーバジェットは完全に枯渇します。アラートが鳴った瞬間には、もう手遅れなのです。
では、どうすればこの「物理法則」に抗えるのか。山口氏は、アーキテクチャレベルでの3つの解決策を提示しました。
冗長化: システムを冗長化すれば、片方がダウンしても影響は半分（ソフトダウン）になり、実質的なエラーバジェットが2倍（8分40秒）に伸びる。
カナリアリリース: 新機能を10%のユーザーにだけリリースすれば、そこで問題が起きても影響は1/10に抑えられ、エラーバジェットは10倍（43分）になる。
自動ロールバック: 異常を検知したら、人間を介さず自動でロールバックする仕組みを構築し、修復までの平均時間（MTTR）を極限まで短縮する。
このセッションが突きつけたのは、SREが単なる精神論やツールいじりではなく、数学と物理学に基づいたエンジニアリングであるという厳然たる事実でした。私たちは、自らが使う監視システムの限界を正確に理解し、その制約の中で信頼性を達成するためのアーキテクチャを設計しなければならないのです。
信頼性の深淵、そこに秘伝のタレを見た
「つよつよSREの秘伝のタレ」と銘打たれたこのイベント。3つのセッションを経て私たちが目にしたのは、単一の魔法のレシピではありませんでした。
それは、まず、自分たちのシステムを支配する揺るぎない原理原則を理解すること（山口氏）。 その原則の上で、障害という避けられない現実に対し、冷静かつ迅速に対応するための仕組みを構築すること（津郷氏）。 そして、その仕組みをさらに進化させるために、AIという新たな力を、設計思想から理解し、活用していくこと（nwiizo氏）。
この、基礎から応用、そして未来へと連なる、幾重にも重なった知見の層こそが、「秘伝のタレ」の正体だったのではないでしょうか。システムの信頼性という深淵を覗き込み、その本質と向き合い続ける。そんなSREの探求の旅は、これからも私たちを魅了してやみません。
Yardでは、AI・テック領域に特化したスポットコンサル サービスを提供しています。
興味がある方は、初回の無料スポットコンサルをお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...