本日の主なトピック #
- ヘルスケア特化型 AI エージェント「Amazon Connect Health」が GA
- AWS Graviton4 搭載の EC2 M8g インスタンスが 5 つのリージョンで新たに対応
- OpenSearch Service で容量不足時でも更新可能な「容量最適化」デプロイオプションが登場
- Elastic Beanstalk や HealthLake で生成 AI を活用した分析・変換機能が提供開始
- ソフトウェアエンジニアリング特化モデル「Mistral AI Devstral 2」が Bedrock で利用可能に
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
ヘルスケア向けエージェント型 AI「Amazon Connect Health」が登場 #
投稿日: 2026年03月05日
何ができるようになったのか #
ヘルスケア組織向けに設計されたエージェント型 AI「Amazon Connect Health」が一般公開（GA）されました。患者のエンゲージメントや診療ワークフローを合理化するための 5 つの AI エージェント（患者確認、予約管理、患者インサイト、環境音によるドキュメント作成、医療コーディング）を提供します。
何が嬉しいのか #
事務作業の負担を軽減することで、患者はより迅速にケアを受けられるようになり、臨床医は事務処理から解放されて患者への対応に集中できるようになります。既存の電子カルテ (EHR) やコンタクトセンターのワークフローに、数ヶ月ではなく数日で導入可能です。
これまでとどう変わるのか #
- これまで: ヘルスケア向けの AI 導入には、複雑なモデルの構築や既存システムとの統合に多大な時間とコストがかかっていました。また、セキュリティやコンプライアンス（HIPAA 等）への対応も個別に行う必要がありました。
- これから: HIPAA 準拠で AWS のセキュリティ基準を満たした、すぐに使える 5 つの専用エージェントを活用できます。コンタクトセンター向けの機能は Amazon Connect にネイティブ統合されており、診療向けの機能は統一 SDK を介して既存の EHR アプリに簡単に組み込めます。
具体的なユースケース #
- リアルタイム患者確認: 患者からの電話時に EHR と照合して本人確認を自動化し、通話時間を短縮。
- 自動予約管理: 自然言語による音声対話で 24 時間 365 日予約を受け付け、保険の資格確認も同時に実行。
- 臨床ノートの自動作成: 診察中の会話をキャプチャし、リアルタイムで臨床ノートを生成（環境音ドキュメンテーション）。
Amazon EC2 M8g インスタンスがより多くのリージョンで利用可能に #
投稿日: 2026年03月04日
何ができるようになったのか #
AWS Graviton4 プロセッサを搭載した Amazon EC2 M8g インスタンスが、アフリカ (ケープタウン)、アジアパシフィック (マレーシア)、欧州 (ミラノ、チューリッヒ)、カナダ西部 (カルガリー) リージョンでも利用可能になりました。Graviton4 は、前世代の Graviton3 と比較して、データベースで最大 40%、Web アプリケーションで 30% のパフォーマンス向上を実現します。
何が嬉しいのか #
Graviton4 プロセッサを採用することで、汎用ワークロード（アプリケーションサーバー、マイクロサービス、ゲームサーバーなど）において、優れたコストパフォーマンスとエネルギー効率を享受できます。M8g インスタンスは最大 12 のサイズ（ベアメタル 2 種含む）で提供され、ネットワーク帯域幅は最大 50 Gbps、EBS 帯域幅は最大 40 Gbps をサポートします。
これまでとどう変わるのか #
- これまで: M8g インスタンスの利用可能リージョンは限られており、これらのリージョンでは主に前世代のインスタンスが利用されていました。
- これから: 最新の Graviton4 を搭載した M8g インスタンスが主要な追加リージョンで利用可能になり、より高性能で効率的なインフラ構成が可能になります。Graviton3 世代に比べ、最大 3 倍の vCPU とメモリを備えたより大きなインスタンスサイズも選択可能です。
具体的なユースケース #
- アプリケーションサーバー: Java アプリケーションのパフォーマンスを最大 45% 向上させ、レスポンス時間を短縮。
- データストアとキャッシュ: 中規模のデータベースや Redis/Memcached などのキャッシュフリートをより低コストで運用。
- マイクロサービス: AWS Nitro System によるセキュリティとパフォーマンスを活かし、高密度なコンテナ実行環境を構築。
Amazon OpenSearch Service が容量最適化されたブルー/グリーンデプロイメントを導入 #
投稿日: 2026年03月05日
何ができるようになったのか #
Amazon OpenSearch Service のブルー/グリーンデプロイメントにおいて、新たに「Capacity Optimized（容量最適化）」オプションが選択可能になりました。これにより、必要なインスタンス容量が一時的に不足している場合でも、バッチ処理によって段階的にアップデートを完了できるようになります。
何が嬉しいのか #
大規模なクラスターにおいて、アップデート時に 100% の追加容量を確保する必要がなくなります。例えば、100 ノードのクラスターを更新する際、これまではさらに 100 ノードの空き容量が必要でしたが、新しいオプションではバッチ単位で更新が進むため、少ない追加リソースでデプロイが可能です。
これまでとどう変わるのか #
- これまで: ブルー/グリーンデプロイメントでは、常に既存クラスターと同じ数の新しいインスタンスを事前に作成する「Full Swap」方式のみでした。十分な容量が確保できない場合はデプロイが失敗し、後で再試行する必要がありました。
- これから: 「Full Swap（デフォルト）」と「Capacity Optimized」の 2 つの戦略から選択できます。容量最適化オプションは、まずフルスワップを試み、容量不足の場合は自動的にバッチデプロイにフォールバックします。30 ノード以上のクラスターでは、このオプションの利用が推奨されています。
具体的なユースケース #
- 大規模クラスターの更新: 100 ノードを超えるような大規模な OpenSearch クラスターのバージョンアップや設定変更を、リソース制限に阻まれることなく実行。
- ピーク時のメンテナンス: リージョン全体のインスタンス容量が逼迫している時間帯でも、バッチ処理によって確実にドメインの更新を進行。
- コストと時間のトレードオフ管理: 速度を優先する場合は Full Swap、リソース確保の確実性を優先する場合は Capacity Optimized を使い分ける。
Amazon SageMaker HyperPod が制限付きインスタンスグループ (RIG) の包括的な可観測性を提供 #
投稿日: 2026年03月04日
何ができるようになったのか #
Amazon SageMaker HyperPod において、制限付きインスタンスグループ (RIG) のための包括的な可観測性（Observability）機能が提供されました。これにより、Nova Forge で基盤モデルをトレーニングするチームは、事前構成された Amazon Managed Grafana ダッシュボードを通じて、GPU のパフォーマンス、システムの状態、ネットワークのスループット、Kubernetes クラスターの状態を統合的に把握できます。
何が嬉しいのか #
インフラストラクチャ全体からメトリクスを手動で収集・関連付ける手間が省けます。GPU 使用率や NVLink 帯域幅、FSx for Lustre の使用状況などを単一のダッシュボードで監視でき、エポックの進行状況や Python のトレースバックなどのトレーニングログも自動的に統合されるため、トレーニングの失敗を迅速に診断できます。
これまでとどう変わるのか #
- これまで: インフラスタック全体にわたるメトリクスの収集は手動で行う必要があり、GPU のパフォーマンス、ホストの健全性、Kubernetes の状態などを個別に監視・相関させるのが困難でした。
- これから: Amazon Managed Service for Prometheus と Amazon Managed Grafana をバックエンドとする事前定義されたダッシュボードが利用可能になります。新しい RIG クラスター作成時に自動で有効化されるほか、既存のクラスターでも数クリックで有効化できます。
具体的なユースケース #
- トレーニングの進捗監視: エポックごとの進捗やステップレベルのログを監視し、トレーニングが正常に進行しているかを確認。
- リソースのボトルネック特定: GPU 使用率や NVLink 帯域幅を可視化し、トレーニング効率を低下させているインフラ上の問題を特定。
- 障害の迅速なデバッグ: パイプラインエラーや Python のトレースバックをダッシュボード上で確認し、トレーニング中断の原因を即座に特定。
AWS HealthLake が CCDA から FHIR への自動データ変換エージェントを発表 #
投稿日: 2026年03月05日
何ができるようになったのか #
AWS HealthLake において、レガシーな臨床ドキュメント (CCDA) をクエリ可能な FHIR リソースに自動変換する「データ変換エージェント」がプレビュー公開されました。AI を活用したこの機能により、数ヶ月かかっていた変換作業を数日に短縮し、縦断的な患者記録の生成や集団健康分析などが可能になります。
何が嬉しいのか #
専門的な FHIR の知識がなくても、AI のサポートを受けて CCDA 2.1 ファイルを FHIR R4 準拠のリソースに変換できます。自然言語で「特定のステータスの薬をスキップする」などのカスタマイズを指示するだけで、AI が変換テンプレートを自動修正してくれるため、開発効率が飛躍的に向上します。
これまでとどう変わるのか #
- これまで: CCDA などのレガシーデータを FHIR 形式に変換するには、高度な専門知識とカスタムコードの開発が必要で、導入までに数ヶ月の期間を要することが一般的でした。
- これから: 即時利用可能なテンプレートと、自然言語で対話しながら調整できる AI エージェントにより、迅速に FHIR 変換パイプラインを構築できます。一括インポート機能により、アップロードされた CCDA ファイルの自動検知、テンプレート適用、患者の照合・統合までが自動化されます。
具体的なユースケース #
- 患者データの統合: 異なる医療機関から提供された CCDA 形式のサマリーを、HealthLake 内の共通の FHIR データストアに統合し、患者の全体像を把握。
- 健康分析の迅速化: 既存の臨床データを FHIR 形式に変換することで、Amazon SageMaker 等を利用した高度な機械学習分析を即座に開始。
- 臨床データ交換の効率化: 相互運用性の高い FHIR 形式に変換することで、他のヘルスケアシステムやアプリケーションとのデータ連携をスムーズに実現。
AWS Shield ネットワークセキュリティディレクターの検出結果が Security Hub で利用可能に #
投稿日: 2026年03月05日
何ができるようになったのか #
現在プレビュー中の AWS Shield ネットワークセキュリティディレクター (Network Security Director) による検出結果が、AWS Security Hub でも確認できるようになりました。AWS WAF、VPC セキュリティグループ、VPC ネットワーク ACL の設定漏れや誤設定を特定し、修復の推奨事項を提供します。
何が嬉しいのか #
AWS Organizations 全体のネットワークセキュリティ状況を Security Hub で一元的に管理できるようになります。リソースのネットワークトポロジーと設定ミスを組み合わせて重要度が自動判定されるため、どの問題から優先的に対処すべきかが一目でわかります。
これまでとどう変わるのか #
- これまで: ネットワークセキュリティディレクターの検出結果を確認するには、個別に状況を確認する必要がありました。Security Hub との統合がなかったため、他のセキュリティアラートと横断的に分析するのが困難でした。
- これから: Security Hub のインベントリセクションに検出結果が表示され、他のセキュリティサービス（GuardDuty や Inspector など）の知見と統合して、包括的なセキュリティ管理が可能になります。
具体的なユースケース #
- 組織全体の不備特定: AWS 組織内の複数のアカウントにまたがって、WAF が適用されていない公開ロードバランサーや、過度に開放されたネットワーク ACL を自動検出。
- リスクベースの優先順位付け: 公開ネットワークに面しているリソースの誤設定を「高重要度」として検出し、優先的に修正。
- セキュリティ標準への準拠: AWS のベストプラクティスに基づいたネットワーク構成が維持されているかを Security Hub 上で継続的に監視。
Database Savings Plans が Amazon OpenSearch Service と Neptune Analytics をサポート #
投稿日: 2026年03月05日
何ができるようになったのか #
一定量の使用（$/時間）をコミットすることで料金が割引される「Database Savings Plans」の対象に、Amazon OpenSearch Service と Amazon Neptune Analytics が追加されました。1 年間の契約で最大 35% のコスト削減が可能になります。
何が嬉しいのか #
インスタンスファミリー、サイズ、エンジン、リージョンに関係なく、対象となるサーバーレスおよびプロビジョニングされたインスタンスの使用に対して自動的に割引が適用されます。例えば、OpenSearch Service でインスタンスタイプを変更したり、Neptune Analytics をスケールアップしたりしても、継続的に割引のメリットを享受できます。
これまでとどう変わるのか #
- これまで: Database Savings Plans は、Amazon RDS、Amazon Aurora、Amazon ElastiCache、Amazon MemoryDB for Redis などが主な対象でした。OpenSearch や Neptune Analytics では、このような柔軟な割引オプションが限られていました。
- これから: OpenSearch Service や Neptune Analytics も対象に含まれるようになったため、データベース全体のコスト最適化がより柔軟に行えるようになります。
具体的なユースケース #
- 検索クラスターのコスト削減: 24 時間 365 日稼働する OpenSearch クラスターに対して Savings Plans を適用し、運用コストを大幅にカット。
- 分析ワークロードの柔軟なスケーリング: Neptune Analytics での大規模なグラフ分析の実行において、コストを抑えつつ必要に応じてリソースを増減。
- マルチサービスにまたがるコスト最適化: RDS や ElastiCache と同様に、OpenSearch も含めたデータベース全体での利用料金を Savings Plans で一元的に最適化。
AWS Elastic Beanstalk が生成 AI による環境分析機能を提供 #
投稿日: 2026年03月05日
何ができるようになったのか #
AWS Elastic Beanstalk において、環境の異常（ヘルスステータスの低下など）が発生した際に、その原因を特定し解決策を提案する「AI 分析機能」が導入されました。Amazon Bedrock を活用し、最新のイベント、インスタンスのヘルス情報、ログを自動的に解析します。
何が嬉しいのか #
開発者や運用チームは、膨大なログやイベントを手動で確認することなく、問題の根本原因を迅速に特定できるようになります。具体的なトラブルシューティングの推奨手順が提示されるため、平均復旧時間 (MTTR) の大幅な短縮が期待できます。
これまでとどう変わるのか #
- これまで: 環境のヘルスステータスが「警告」「低下」「重大」になった場合、エンジニアが手動で各種ログを取得し、イベントの発生順序などを突き合わせて原因を推測する必要がありました。
- これから: コンソールの「AI Analysis」ボタンをクリックするか、CLI/API からリクエストするだけで、環境の現状に合わせた具体的な診断結果と解決策が得られます。
具体的なユースケース #
- デプロイ失敗の迅速な解決: 新しいバージョンのデプロイ後に環境のヘルスが低下した際、どの設定やコードが原因でエラーが発生しているかを即座に把握。
- リソース不足の特定: インスタンスの CPU やメモリの逼迫によるヘルス低下を AI が検知し、適切なインスタンスタイプへの変更を提案。
- 設定ミスによる接続エラーの診断: セキュリティグループや環境変数の誤りによって DB 接続に失敗しているケースなどを AI がログから特定。
Kiro Power による AWS Lambda Durable Functions 開発の加速 #
投稿日: 2026年03月05日
何ができるようになったのか #
エージェント型 AI 開発環境「Kiro」において、AWS Lambda Durable Functions の開発を支援する「Kiro Power」が発表されました。これにより、レジリエントで長時間実行されるマルチステップアプリケーションや AI ワークフローを、ローカル開発環境で AI エージェントの支援を受けながら迅速に構築できるようになります。
何が嬉しいのか #
Durable Functions 特有の複雑な概念（リプレイモデル、待機操作、並列実行、エラーハンドリングなど）について、AI エージェントが動的に最適なガイダンスを提供します。開発者は、注文処理パイプラインや、人間による承認プロセスを含む AI エージェントのオーケストレーションなどを、アイデアから実装まで短期間で進めることができます。
これまでとどう変わるのか #
- これまで: Lambda Durable Functions の開発には、ステート管理やリプレイの仕組みなど、独自のベストプラクティスを深く理解する必要がありました。また、適切なエラーハンドリングや AWS CDK/SAM によるデプロイ設定を自ら構築する負担がありました。
- これから: Kiro Power を使用することで、AI エージェントがベストプラクティスを提示し、CloudFormation、CDK、SAM によるデプロイ設定まで一貫してサポートしてくれるため、学習コストと開発時間を大幅に削減できます。
具体的なユースケース #
- AI エージェントのオーケストレーション: AI による処理の途中で「人間による承認」を待機するような、複雑な長時間実行フローの構築。
- 注文・決済処理パイプライン: 補償トランザクション（支払いに失敗した際の在庫戻しなど）を含む、信頼性の高い一連の処理の実装。
- 並列データ処理: 多数のステップを並列またはマップパターンで実行するスケーラブルなワークフローの作成。
Mistral AI Devstral 2 が Amazon Bedrock で利用可能に #
投稿日: 2026年02月18日
何ができるようになったのか #
Mistral AI の最新オープンウェイトモデル「Devstral 2 (123B)」が Amazon Bedrock で利用可能になりました。このモデルは、エージェントによるソフトウェアエンジニアリングのワークフローに特化して構築されており、コード生成、自動化、多段階の推論において高い専門性を備えています。
何が嬉しいのか #
開発者はインフラのプロビジョニングやモデルのホスティングをすることなく、フルマネージドな API を通じて Devstral 2 にアクセスできます。1230億のパラメータを持ち、大規模なコードの計画、記述、反復を行う AI エージェントの構築に最適です。
これまでとどう変わるのか #
- これまで: Bedrock で Mistral モデルを利用する場合、Mistral 7B や Mixtral 8x7B などが選択肢でしたが、より大規模でソフトウェアエンジニアリングに特化したモデルは提供されていませんでした。
- これから: 大規模なパラメータ（123B）を持ち、コードレビューの自動化や複雑なソフトウェア開発エージェントに適した Devstral 2 を、Bedrock のマネージド環境で活用できるようになります。
具体的なユースケース #
- 自動コードレビュー: 複雑なロジックの修正やセキュリティ上の懸念を自動で指摘するパイプラインの構築。
- ソフトウェア開発エージェント: 仕様書からコードを生成し、テスト結果に基づいて修正を繰り返す自律型エージェント。
- レガシーコードの解析: 長いコンテキストの理解力を活かし、大規模な既存コードベースの解析やドキュメント化。
マルチパーティ承認が承認チームのベースライニング（稼働確認）をサポート #
投稿日: 2026年03月05日
何ができるようになったのか #
マルチパーティ承認 (MPA) において、承認チームが正しく設定され、承認者がアクティブで連絡可能であることを確認するための「テスト承認（ベースライニング）」が実行できるようになりました。管理者は、実際に機密性の高い操作を行う前に、承認フローの健全性をテストできます。
何が嬉しいのか #
異動や退職による欠員、承認者の選択ミス、あるいはエンゲージメントの低下などによって、承認フローがいざという時に機能しなくなるリスクを事前に排除できます。定期的なチェック（AWS は 90 日ごとの実施を推奨）により、コンプライアンスの維持と運用上の安全性が確保されます。
これまでとどう変わるのか #
- これまで: 承認チームの設定が正しいかどうか、あるいは承認者が実際に反応してくれるかどうかをテストする公式な仕組みはありませんでした。実際の承認リクエストが発生した際に初めて問題が発覚するリスクがありました。
- これから: AWS Organizations コンソールから手動でテスト承認セッションを開始し、承認者の可用性を検証できます。非アクティブなメンバーの特定や、新しい構成の導入時検証が容易になります。
具体的なユースケース #
- 承認チームの定期診断: 90 日ごとにテスト承認を実行し、承認メンバー全員が連絡可能な状態にあるかを確認。
- 新規設定の動作検証: 新しく MPA 構成を作成した直後に、想定通りに通知が飛び、承認が機能するかをテスト。
- オンボーディング後の確認: 新しく承認チームに参加したメンバーが、正しく承認操作を行える環境にあるかを確認。