はじめに
メディア基盤開発部 配信インフラグループ SREチームの片岡です。 普段は動画に関連するアプリケーションのKubernetesプラットフォームを構築・運用するSREを主な業務としています。
本記事は、2025年11月30日から12月5日（米国標準時）にかけて、ラスベガスで開催されたAWS re:Invent 2025に参加した内容のレポートです。
AWS re:Inventは、ラスベガスの主要ホテル6箇所を会場として使用する超大規模なカンファレンスです。AWSの最新技術や新機能がここで発表されるため、世界中のエンジニアが注目するイベントです。
本記事では、現地で発表された注目の新サービス・新機能の紹介に加え、実際に参加して興味深かったセッションの内容を紹介します。
概要
今回発表された新サービスやアップデートを見た率直な感想は、想定よりもAWSのAIへの注力度が高いという点でした。 純粋なAIサービスはもちろん、既存サービスの新機能発表においても、ほとんどがAIを絡めた紹介であることがそれを物語っていました。
AIが絡まない紹介を探す方が難しく、AWSのAI領域への熱量の高さと、世界的な注目度の高さを感じました。
気になった新サービス・新機能
数ある発表の中で、特に気になったサービスをピックアップします。
Amazon Nova Forge
今回の目玉の一つです。「Amazon Nova」モデルをベースに、ユーザー独自のモデルを作成（フォージ）できるサービスです。
これまでのAIカスタマイズといえば、既存モデルのファインチューニングやRAG（検索拡張生成）が主流でしたが、Nova Forgeではモデルレベルからのカスタマイズが可能になります。
0からモデルを作るのではなく、ある程度学習されたNovaのベースモデルに、さらに企業独自のドキュメントやシステムのソースコードなどを学習させることが可能になります。 自作モデルよりも容易に、また汎用モデルよりもドメイン固有の知識に詳しいモデルを作ることができるようになります。
【所感】
従来のチューニング手法以上に、利用者の求める回答を得やすいモデルの構築ができそうで興味深い内容でした。
弊社のような大規模なシステムやサービスを持つ会社は、同時に膨大なドメイン知識を抱えています。 膨大な情報はファインチューニングやRAGだけでは確実にコンテキストを入れられない部分も出てくるので効果が大きそうです。
Slackの履歴や社内ドキュメント、ソースコードなど、会社固有の情報をすべて学習させたモデルが、実務でどこまで正確な推論をしてくれるのか気になります。
ただし現状はすぐ試せるような費用感ではないため、今後の動向に注目しています。
3種類の「Frontier Agent」
開発・運用を支援するAIエージェントとして、以下の3種類が発表されました。これまでエンジニアが手動で行っていた負担の大きい作業を自律的にこなしてくれます。
- Kiro Autonomous Agent: AIネイティブエディタ「Kiro」に追加された機能。複数リポジトリにまたがる変更や、複雑な依存関係の解決を自律的に行う
- AWS DevOps Agent: 障害発生時に根本原因を特定し、解決までの時間を短縮
- AWS Security Agent: セキュリティ要件に従って開発者をガイドし、要件に合致しない場合は修正のアシストまで行う
【所感】
どれも開発者視点で有用なAIエージェントです。
SREの視点では、特に DevOps Agent とSecurity Agentなど運用面のAgentは魅力的に感じました。
前者は障害発生時の貴重な時間を削減できるという意味で便利が明確です。障害対応は、慣れていても短時間で大量の情報を確認して原因や影響を特定するのは難しく、AIエージェントの手助けがあればより短時間で復旧作業を行えます。
同じくAWS re:Invent内で行われていたEXPOで、Datadogも同じように障害の原因調査をAIで行うSRE Agentという機能を紹介しており、障害対応に対するAIの需要の高さを感じました。
後者はPlatform Engineeringの視点から魅力に感じました。 どうしても開発者ごとにセキュアな開発への注力度合いは異なるため、ある一定ラインまでを自動で担保できるAIエージェントが存在すると、Platform全体のセキュリティレベルの底上げに繋がりそうです。
IAM Policy Autopilot
IAM権限管理のためのMCP（Model Context Protocol）サーバ機能です。アプリケーションが必要とする権限を分析し、適切なIAMポリシーを自動生成します。 こちらはGitHubでOSSとして公開されています。
https://github.com/awslabs/iam-policy-autopilot
【所感】
IAMの権限設定はクラウドエンジニアにとって頭痛の種です。 細かい権限を渡すと開発時に細かく権限調整をしなければならず、かといって一度強い権限を渡してしまうと、後から権限を削るのは難しくなる…といった難しさがありました。
多くの場合、クラウドエンジニアは開発効率とセキュリティを天秤にかけながら、ある程度トレードオフを受け入れて、どちらを取るか判断する必要がありました。 本MCPサーバの機能により、開発効率を落とさずに最小権限の原則を守りやすくなり、よりセキュアな権限管理の判断がしやすくなりそうです。
余談ですが、このMCPサーバはRustで記述されています。 公式のMCP SDKは複数の言語で提供されており、その中にはRustもあるためRustでも比較的容易にMCPサーバを書くことが可能です。
https://modelcontextprotocol.io/docs/sdk
AWS Lambda Durable Functions
Lambda関数にチェックポイントを作ることで、最大1年間単一のワークフローを処理できる機能です。
既存のLambdaとの一番の違いはチェックポイント単位での自動復旧機能を備えている点です。 能動的に待機状態にしたり、障害発生時でLambda関数が止まってしまった場合も、再度直前のチェックポイントから処理を再開することが可能になります。
【所感】
従来のLambdaは最大15分が限界だったことを考えると、チェックポイント周りの処理が必要とはいえ最大1年間という期間は驚異的です。
機械学習など長時間かかるワークロードの文脈で紹介されていましたが、従来の制限時間では難しかった長時間のバッチ処理基盤としても有力な選択肢になりそうです。
セッションレポート
Keynoteなどの大規模セッション以外にも複数の個別セッションに参加してきました。
その中でも現地ならではの雰囲気を感じられる、WorkshopやChalk Talkといった対話型セッションを2つ紹介します。
Workshop: Accelerate VMware Migration with AWS Transform
受講理由： 自身の所属するメディア基盤開発部ではオンプレミスとクラウドのハイブリッド環境を運用しており、今後のクラウド移行（マイグレーション）の参考にするため。
このワークショップでは、AI Agentと対話しながらオンプレミスのVMware環境（模倣）をEC2へ移行するプロセスを体験しました。
通常、オンプレミスからクラウドへの移行作業といえば、SSHでサーバーに入り、アプリのバージョンや依存関係を調査し、終わったらDBをダンプしてSFTPでファイルを持ってきて…と泥臭い作業が無数に発生します。 自身も渡航前後でオンプレミス関連の業務でオンプレミス特有の問題に苦慮していたこともあり、どの程度楽に移行ができるのか気になっていました。
結論から言うと、このWorkshopではそういった作業がないどころか コンソール画面すら見ずに移行が完了 しました。 具体的には以下のような流れでマイグレーションがどんどん進んでいきました。
- ユーザー: 最低限必要な接続情報等をAIエージェントに渡す
- AIエージェント: 調査しどう移行するかのプランを提示
- ユーザー: そのプランで進めてよいか判断する
- AIエージェント: プランに沿ってマイグレーションを進める
- ユーザー: 逐次進行度合いを確認する
- AIエージェント: 移行中に出てきた判断が必要な部分をユーザに質問 (2つのアプリを別のEC2に分離するか？等)
- ユーザー: 自然言語で判断した内容を送信する
このやり取りをしながら、AIエージェントがどんどんマイグレーションを進めていきます。
Workshop用に用意された理想的な環境下とはいえ、コマンドを1つも打たずにマイグレーションが進み、あらゆる作業を代理で行うAIエージェントの様子には衝撃を受けました。
Chalk Talk: AWS Tools - Automate Simulation job Recovery & maximize Cost Savings
受講理由： チームでGoogle CloudのSpot VMを利用した経験があり、AWSのSpot Instanceにおける効率的な活用法や安全な運用方法が参考になりそうと思ったため。
このセッションは、AWSのスペシャリストがホワイトボードを使いながら、安価だが中断リスクのある「Spot Instance」でHPC（ハイパフォーマンスコンピューティング）ワークロードをどうコスト最適化するか、というテーマで進められました。
HPCのように大量の並列処理を行う場合、ハードウェア起因の予期せぬエラーやフリーズは確率的に避けられません。
そこで重要になるのが「チェックポイント」という考え方です。処理の途中で状態を保存し、異常終了やインスタンスの中断が発生しても、最初からやり直すのではなくチェックポイントから再開できるようにします。
これにより、中断に強いアーキテクチャとなり、安価なSpot Instanceでも安心してHPCワークロードを実行可能になるという解説でした。
AWSのエキスパートが、受講者からこういった中断ケースはどうなのか？ではこういった状況は？といった質問を受けながら、フローをホワイトボードに書き込み、更に説明と議論が進んでいく…という様子は現地ならではの見応えがありました。
まとめ
今年のre:Inventを一言で表すなら、AI、特にAIエージェントのre:Inventでした。
その象徴とも言えるのがCEOのKeynoteです。 時間の大部分がAIプロダクトの紹介に割かれ、それ以外の25個の新機能発表はタイムアタックのように、わずか10分で駆け足に紹介されるという徹底ぶりでした。
一方で、SREやPlatform Engineeringといった観点の新発表は目立つものが少なく、少し物足りなさも感じました。
WebAssembly System Interfaceなどの新技術も徐々に広まり始めている中、AI以外の新機能や改善についても、今後の発表に期待したいところです。
