はじめに
近年、AWSでは生成AIを活用した機能強化が各サービスに広がっています。個別のAIサービスに限らず、開発や運用を支える既存サービスにもAIが組み込まれ始めている点が特徴です。
これらのサービスを活用することで、定型的な作業や判断をAWSに任せ、利用者はそれぞれの立場やビジネスに応じて、本来注力すべき領域にリソースを割きやすくなります。
こうした流れの中で、AWS re:Invent 2025では、開発・運用を支える各種サービスに対する実践的なアップデートが数多く発表されました。本記事では、AWS re:Invent 2025で発表されたアップデートを、「AIによる機能拡張」と「実行基盤・運用の進化」の2つの観点から整理して紹介します。
AIによる機能拡張
本セクションでは、AWS re:Invent 2025で発表されたアップデートのうち、設計や分析といった人間の判断が求められる場面をAIが支援する機能に加え、開発者が利用できるAI基盤モデルの拡充について紹介します。
新たな基盤モデル「Amazon Nova 2」の発表
このたび、AWSが提供しているAI基盤モデルであるAmazon Nova（以下、Nova）について、最新のモデルであるAmazon Nova 2が発表されました。
AWS re:Invent 2024でNovaを発表して以来、AWSは自社製のAI基盤モデルを持つハイパースケーラーとしての立ち位置を改めて示しましたが、生成AI分野では引き続き多様なモデルが競争を続けています。そうした状況の中で、Nova 2は用途・要件に応じた選択肢を拡充するものといえます。日常的なワークロード向けの高速でコスト効率に優れたモデルから、複雑なタスクやマルチモーダルなユースケースに対応するモデルまでが用意されており、AI活用の幅を広げる基盤として期待できます。
| モデル名 | 主な特徴 |
|---|---|
| Nova 2 Lite | 推論性能とコスト効率のバランスを重視した標準的なマルチモーダルモデル |
| Nova 2 Pro | 複数ステップを要する高度で複雑なタスクに対応するマルチモーダルモデル |
| Nova 2 Sonic | 音声の理解および生成を前提とした対話向けモデル |
| Nova 2 Omni | テキストと画像の両方を出力可能なマルチモーダルモデル |
AWS公式ブログにて、他社モデルとの性能比較についても述べられていますので、詳細な機能や性能評価はこちらをご覧ください。
また、モデルによって提供状況（GA／Preview）が異なります。最新の対応状況については、AWS公式ページをご確認ください。
IAM Policy Autopilotの発表
IAMポリシーの設計は、AWSを利用する上で欠かせない要素の一つです。 特に、セキュリティリスクを最小限に抑えるために必要最小限の権限を見極める作業には、時間と労力がかかることも多いのではないでしょうか。
こうした課題に対するアプローチとして、「IAM Policy Autopilot」が発表されました。
IAM Policy Autopilotは、アプリケーションコードを解析し、実際に利用されている AWS API呼び出しに基づいてIAMポリシー作成を支援するツールです。 開発者がゼロからポリシーを設計するのではなく、IAM Policy Autopilotがたたき台となるポリシーを生成することで、開発者は最小限の労力で権限設計が可能です。
本ツールは、2つの方法で利用できます。
1つは、Model Context Protocol（MCP）サーバーとして利用する方法で、KiroやClaude Code、Cursor、ClineといったAIアシスタントと連携して利用できます。 もう1つは、CLIツールとして利用する方法で、ポリシーを直接作成したり、修正したりすることが可能です。
IAM Policy Autopilot の具体的な利用イメージについては、AWS公式ブログにて、画面キャプチャ付きで紹介されていますので、実際の出力内容や操作感を確認する際は参照するとよいでしょう。
Amazon CloudWatch Incident ReportsのFive Whys分析の発表
システム障害が発生した際、その原因をどこまで深掘りできるかは、再発防止の観点で非常に重要です。一方で、ログやメトリクスを確認しながら原因を整理し、「なぜそれが起きたのか」を段階的に言語化していく作業は、経験や時間を要するプロセスでもあります。
このたび、こうした障害分析の負担を軽減する機能として、Amazon CloudWatch Incident Reportsに「Five Whys」分析を支援する機能が追加されました。
Five Whys分析は、発生した事象に対して「なぜ」を繰り返し問いかけることで、表面的な原因にとどまらず、根本原因を特定するための分析手法です。 この手法を支援するための機能として、Amazon Qを活用したチャットベースの機能が追加されました。
具体的な機能として、インシデントに関連するCloudWatchアラーム、ログなどの情報を参照しながら、AIが分析の観点となる問いを提示します。利用者は、問いに対して回答することで、「なぜ問題が発生したのか」を一段ずつ掘り下げて整理していくことができます。
実際に、EC2のCPU使用率が80％を超過した際にアラームが発生する状況を意図的に作り出し、Five Whys機能の動作を確認しました。
CloudWatchアラームには、アクションとして調査グループを紐付けることが可能です。これにより、アラーム発生時にインシデント調査が自動的に開始されます。
調査が完了し、インシデントレポートを作成すると、そこからFive Whys分析を開始するためのボタンが表示されます。
これを起点に、Amazon Qとのチャットベースの対話を通じて原因分析が進められます。
対話を進めていくと、提示された問いと利用者の回答を基に分析結果が整理され、最終的な内容は以下のような形式でインシデントレポートに自動的に反映されます。
実際に利用してみて感じた点として、Five Whys分析はAIが問いを提示してくれる一方で、分析の質は利用者の回答に大きく依存するという印象を受けました。必ずしも「5回のなぜ」だけで十分に原因へ到達できるとは限らず、状況によっては、より多角的な整理が必要になるケースもあります。
また、Amazon Qが提示する問いは、必ずしも常に利用者が想定していた方向に進むとは限らず、分析の文脈によっては異なる切り口が提示される場面もありました。そのため、問いに対して漫然と回答するのではなく、「本来どの観点を深掘りしたいのか」を意識しながら回答し、必要に応じて分析の方向性を利用者側で補正していくことが重要だと感じました。
一方で、技術的な要因にとどまらず、事前の作業準備や運用体制といった観点まで自然に問いが広がっていく点は、本機能の大きな利点です。従来、人手で行っていた振り返り作業を支援し、再発防止に向けた議論のきっかけを作りやすくなる点は評価できるでしょう。
なお、本機能は原因分析のプロセスを支援するものであり、最終的な原因の確定や対策の決定を自動化するものではありません。AIが提示する問いや整理結果を参考にしつつ、システム構成や運用方針を踏まえた判断は、引き続き利用者が行う必要があります。
