この記事は、ファインディエンジニア #1 Advent Calendar 2025の21日目の記事です。 adventar.org
はじめに
こんにちは、ファインディのPlatform開発チームでSREを担当している原（こうじゅん）です。
2025年12月、ラスベガスで開催されたAWS re:Inventに参加してきました。re:InventはAWSが毎年開催する世界最大級のクラウドカンファレンスです。
今年は特にAI Agentを中心とした大きな変化を感じるイベントとなりました。
本記事では、私の体験したセッションを通じて見えてきたインフラ・運用の変化について、AIOps領域に焦点を当てて振り返りを書いていこうと思います。
会場の様子やセッション以外のイベントについてはまた別記事で書いていきます。
re:Invent 2025
re:Inventは、ラスベガスの街全体が会場となる巨大なイベントです。
6つの会場で数多くのセッションが同時並行で開催され、世界中のエンジニアが集まります。
会場間の移動だけでも場所によれば徒歩だと約1時間かかることもあり、シャトルバスやモノレールで移動しながら1週間を過ごすことになります。
セッション以外にもEXPO、re:Playと呼ばれるパーティイベント、5k Raceなど様々なアクティビティが用意されており、まさにAWSの祭典という雰囲気でした。
今年の主要テーマの1つであるFrontier Agents
2025年のre:Inventで印象的だったのは、Frontier Agentsと呼ばれるAIエージェントにまつわる発表です。
Keynoteでは、Kiro Autonomous Agent、AWS DevOps Agent、AWS Security Agent、など、フロンティアエージェントと呼ばれるインフラ・運用領域に直接関わるAIエージェントが次々と発表されました。
これらは単なる「補助ツール」ではなく、「チームメイトとして成果を出すことを期待される存在」として位置づけられています。
その中の1つである私が体験してきたAWS DevOps Agentについて軽く触れていきたいと思います。
AWS DevOps Agentとは
AWS DevOps Agentは、運用チームの「チームメイト」として次のような役割を担います。
- Team Player: アラートやチケットに対応し、Slackなどのコラボレーションチャネルで知見を共有
- Telemetry Expert: メトリクス・ログ・トレースを横断的に分析。DatadogやNew Relicとも連携可能
- Pipeline Pro: GitHubやGitLabと連携して障害につながる変更を特定し、パイプライン改善を提案
- Application Context: アプリ構成やRunbookを理解した上で判断
ワークショップでの体験
実際にDevOps Agentを使ったワークショップである [NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agent に参加し、次のような操作を体験しました。
- 障害発生中のAWSリソースを解析して根本原因を特定
- Dynatraceと連携させてオブザーバビリティデータを統合
- インシデント対応レポートと改善計画の自動生成
エージェントが「インシデントの根本原因を教えてくれる」だけでなく、「改善計画」まで説明してくれる点は、まさにチームメイトのような動きでした。
まだプレビュー版ではありますが、弊社でオブザーバビリティツールとして使用しているDatadogとの連携もできるのでぜひ取り入れていきたいと思いました。
その他の運用・インフラ領域で参考になるセッション
DevOps Agent以外にも、AIOpsに関連する運用・インフラ領域で参考になるセッションがいくつかありました。
Observability × AI
Scaling observability with generative AI (ARC311) では、Kiro CLI Agentを用いた自然言語操作によるオブザーバビリティの自動化が紹介されました。
障害が発生している環境に対して、Kiroがカスタムエージェントで解析した内容をもとにLambdaのコードを書き換えたり、リソース設定を変更したりするデモが印象的でした。
Unveiling Amazon ECS workloads with AWS observability and agentic AI (CNS413) では、ECSワークロードに対して生成AIを活用し、オブザーバビリティデータを自動分析するアプローチが紹介されました。
毎週30億タスクが実行され、新規コンテナ顧客の65%がECSを利用しているという事実を紹介してから、AWSのオブザーバビリティツール全体を整理した上で、ECS上でAIOpsエージェントを構築する際のベストプラクティスが紹介されました。
運用の文化とプラクティス
Behind the scenes: How AWS drives operational excellence & reliability (COP415) では、AWSがグローバル規模で運用をどのように行っているのかが解説されました。
特に印象的だったのは、次のサイクルを継続的に回している点です。
- Readiness: 障害が起きる前の状態づくり（アラーム、ダッシュボード、Runbook、オンコール体制の整備）
- Observability: ログ・メトリクス・トレースでの計測、SLOドリブンなモニタリング
- Incident Response: SOP（標準作業手順書）に従った対応、AIOpsによる障害分析
- Reviews: 定期的なダッシュボードレビューと改善活動
これらはSREのプラクティスと大きくは変わらないなと思いつつ、改めて運用フローを整理・定義していく重要性を認識しました。
インフラ基盤の進化
Infrastructure Innovations (KEY004) では、Graviton5やLambda Managed Instances、Amazon ConnectのAI対応など、AWSのインフラ技術の進化が語られました。
セキュリティ、可用性、弾力性、コスト、俊敏性といった軸で、どのような思想で設計・進化してきたのかが示されており、基盤レイヤの理解を深めることができました。
IAMポリシーの深掘り
A deep dive on IAM policy evaluation (SEC402-R1) では、IAMポリシーの評価ロジックが詳細に解説されました。
権限評価は単一のポリシーだけで決まるのではなく、Organization → Account → Role → Boundary → Session という複数レイヤをすべて通過して決まります。
また、すべてのPrincipalを対象にしたDenyに条件を付けることで、特定のロールだけを例外として許可するIAMポリシーの書き方なども紹介されており、セキュリティ設計の参考になりました。
AIがインフラ領域に組み込まれている中、ガードレールとしてのポリシーの整備も必要だと感じました。
エンジニアに求められる姿勢
また、クロージングKeynoteで、AWS CTOのWerner Vogels氏が語った言葉が印象に残っています。
「AIは自分の仕事を奪うのか？」という問いに対して、CTOは「多分ね……」と答えつつも、本質的な問いはそこではなく、「AIがあなたを時代遅れにするのか？」であると強調していました。
そして、その答えは、「あなたが進化し続ける限り、断じてノーだ」と。
私たちは今、AIによって時代が大きく動いている震源地に立っています。その中で重要なのは、次の姿勢です。
- Be Curious: 好奇心を持ち続けること
- Think in Systems: 複雑なシステム全体を捉える力
- Communicate: 良いアイデアを明確に伝える力
- Owner: 成果物に対して自ら責任を持つこと
- Polymath: 多才であり、学び続けること
AIはあくまでツールであり、仕事の主体は常に「あなた自身」である。
The work is yours, not the tool's
YOUR CURIOSITY + YOUR SKILLS = WORLD-CHANGING
このメッセージは、re:Inventの締めとしてとても印象に残りました。
おわりに
4日間のイベントを通して、技術的な知見が広がり、刺激的で濃い時間を過ごすことができました。
2026年は、AIOpsが本格的に実務に組み込まれていく年になると感じ、ファインディのPlatform開発チームでもよりAIOpsを組み込んでいく体制づくりを行っていければと思います。
ファインディでは一緒に働くメンバーを募集中です！
よかったら覗いてみてください。
herp.careers
