本日の主なトピック #
- Amazon SageMaker HyperPod が API による Slurm 設定とドリフト管理をサポート: 機械学習クラスターの構築・運用がより標準化され、ライフサイクルスクリプトの負担が軽減されます。
- エージェンティック AI IDE「Kiro」から SageMaker Unified Studio へのリモート接続が可能に: ローカルの AI 支援開発環境とクラウドのスケーラブルなリソースがシームレスに統合されました。
- IAM Identity Center の IPv6 対応が全リージョンで完了: 台北および GovCloud リージョンでのサポート開始により、グローバルで IPv6 によるセキュアなアクセスが可能になりました。
- MediaLive が SRT リスナーモードに対応: 接続を待ち受けることが可能になり、オンプレミス環境からの映像プッシュ送信が容易になりました。
- Amazon Bedrock AgentCore Policy が GA: Cedar 言語を用いた決定論的な認可制御により、AI エージェントの安全性とガバナンスが強化されます。
¥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
Amazon SageMaker HyperPod が API による Slurm 設定をサポート #
投稿日: 2026年02月26日
何ができるようになったのか #
Amazon SageMaker HyperPod において、API（CreateCluster/UpdateCluster）や AWS コンソールから直接、Slurm のトポロジーや共有ファイルシステムの設定を行えるようになりました。
具体的には、インスタンスグループごとのノードタイプ（Controller, Login, Compute）の指定や、パーティションのマッピング、FSx for Lustre / OpenZFS のマウント設定を、ライフサイクルスクリプトを介さずに API 定義として記述できます。また、Slurm のネイティブ設定ファイルと HyperPod 側の構成の乖離（ドリフト）を管理するための SlurmConfigStrategy（Managed, Overwrite, Merge）も導入されました。
何が嬉しいのか #
これまで Slurm クラスターの構築に不可欠だった複雑なライフサイクルスクリプトの作成・管理負担が大幅に軽減されます。API 駆動になることで、クラスターのプロビジョニングがより標準化され、エラーの混入を防ぎやすくなります。また、自動スケール時の設定不整合を検知・解決する仕組みにより、大規模な機械学習（ML）環境の運用安定性が向上します。
これまでとどう変わるのか #
- これまで: Slurm のインストール、役割定義（管理・ログイン・計算ノードの振り分け）、ファイルシステムのマウントなどは、すべてユーザーが用意するライフサイクルスクリプト（シェルスクリプト）内で手動で実装する必要がありました。また、Slurm 内部の設定と HyperPod のリソース状態に不整合が生じないよう、ユーザー自身が注意深く管理しなければなりませんでした。
- これから: API のパラメータとしてこれらの構成情報を渡すだけで、SageMaker HyperPod が自動的に Slurm クラスターをセットアップします。設定のドリフト管理も組み込みの戦略（Managed, Overwrite, Merge）を選択するだけで対応可能になります。
具体的なユースケース #
- 大規模言語モデル（LLM）の分散学習: 複雑な Slurm パーティション構成を API で迅速に定義し、多数の GPU インスタンスを用いた学習環境を即座に構築する。
- ハイブリッドなクラスター運用: 基本的な構成は API で管理しつつ、特定の最適化が必要な箇所のみ手動設定を残す（Merge 戦略の活用）。
Slurm は「Simple Linux Utility for Resource Management」の略です。 HPC（ハイパフォーマンコンピューティング）や大規模な機械学習クラスターで広く利用されている、オープンソースのワークロードマネージャーおよびジョブスケジューラです。 主な特徴は以下の通りです。
- クラスター内の計算リソース（CPU/GPU/メモリ）を効率的に管理し、ユーザーのジョブに割り当てる。
- 優先度に基づいたジョブのキューイングとスケジューリングを行う。
- 複数の計算ノードを束ねて一つの巨大な計算リソースとして扱うための標準的なインターフェースを提供する。
Amazon SageMaker Unified Studio が Kiro IDE からのリモート接続をサポート #
投稿日: 2026年03月03日
何ができるようになったのか #
次世代の Amazon SageMaker である「SageMaker Unified Studio」において、AWS が提供するエージェンティック AI IDE「Kiro」からのリモート接続が可能になりました。 これにより、開発者は自身のローカル環境で使い慣れた Kiro の高度な AI 支援機能（スペック駆動開発、自律的なコード生成など）を利用しながら、実際の計算処理やデータアクセスには SageMaker のスケーラブルなクラウドインフラをシームレスに利用できます。
何が嬉しいのか #
ローカル IDE とクラウドインフラの間の「コンテキストスイッチ（切り替え）」が不要になります。Kiro の強力な AI エージェント機能を活かした開発ワークフローを維持したまま、Amazon EMR や AWS Glue、Amazon Athena といった AWS の各種分析サービスや機械学習ワークロードを直接実行できるようになります。また、IAM によるセキュアな認証とカスタマー管理型の暗号化キーにより、エンタープライズレベルのセキュリティを保ちながら開発効率を最大化できます。
これまでとどう変わるのか #
- これまで: SageMaker Unified Studio では、JupyterLab や Code-OSS ベースの Code Editor といった、主にクラウド上で完結するマネージドな IDE が中心でした。ローカルの AI 特化型 IDE からクラウドのリソースを直接操作するには、個別の設定や手動でのデータ同期が必要な場合がありました。
- これから: AWS Toolkit 拡張機能を通じて、ローカルの Kiro IDE から SageMaker Unified Studio のドメインやプロジェクトに直接アクセスできます。Kiro の特徴である「ステアリングファイル」や「エージェント・フック」といった独自の設定を、そのままクラウド上の計算リソースに対して適用可能です。
具体的なユースケース #
- AI エージェントによるデータパイプライン構築: Kiro IDE 上で自然言語によりデータ処理の「スペック」を定義し、その実装とテストを SageMaker のコンピュートリソース上で AI エージェントに自動実行させる。
- スケーラブルな ML モデル開発: ローカルで Kiro を使ってモデルのプロトタイプを迅速に作成し、そのままの環境から SageMaker の強力な GPU インスタンスを呼び出して大規模なトレーニングを実行する。
Kiro は、AWS が提供する「エージェンティック（自律的エージェント型）AI IDE」です。 主な特徴は以下の通りです。
- スペック駆動開発: プロンプトから詳細な仕様書（スペック）とタスク分解を自動生成。
- エージェント・フック: ファイル保存などのイベントをトリガーに、テスト生成やドキュメント更新を自動化。
- Code-OSS ベース: VS Code 互換のインターフェースを持ち、既存の拡張機能も利用可能。
AWS IAM Identity Center が台北および GovCloud リージョンで IPv6 をサポート #
投稿日: 2026年02月27日
何ができるようになったのか #
AWS IAM Identity Center において、AWS アジアパシフィック（台北）および AWS GovCloud (US) リージョンで IPv6 デュアルスタックエンドポイントが利用可能になりました。これにより、IAM Identity Center が提供されているすべての AWS リージョンで IPv6 対応が完了したことになります。 ブラウザやアプリケーションなどのクライアントがデュアルスタックエンドポイントにリクエストを送信すると、ネットワーク環境に応じて IPv4 または IPv6 アドレスとして解決されます。
何が嬉しいのか #
IPv6 のみ、または IPv6 を優先するネットワーク環境からでも、追加のプロキシや変換（NAT64など）を介さずに直接 IAM Identity Center にアクセスできるようになります。また、公共機関などで求められる IPv6 コンプライアンス要件への対応が容易になります。
これまでとどう変わるのか #
- これまで: 2026年1月に多くのリージョンで IPv6 対応が開始されましたが、台北リージョンと GovCloud リージョンについては IPv4 エンドポイントのみのサポートに留まっていました。
- これから: すべての商用リージョンおよび GovCloud リージョンにおいて、IPv6 を用いたセキュアなアクセスが可能になります。
具体的なユースケース #
- IPv6 ネットワーク環境からの AWS アクセス: 社内ネットワークが IPv6 化されている企業において、追加のインフラなしに AWS マネジメントコンソールや CLI へのシングルサインオン（SSO）環境を構築する。
- コンプライアンス遵守: 米国政府機関向けの GovCloud を利用しており、厳格な IPv6 採用基準を満たす必要があるプロジェクトでの利用。
IPv6 デュアルスタックエンドポイントとは、一つのドメイン名に対して IPv4 と IPv6 の両方のアドレスが割り当てられているエンドポイントのことです。 主な特徴は以下の通りです。
- クライアントのネットワーク環境に応じて、自動的に最適なプロトコル（IPv4 または IPv6）が選択されます。
- 既存の IPv4 環境を維持したまま、スムーズに IPv6 への移行を進めることができます。
AWS Elemental MediaLive が SRT リスナーモードをサポート #
投稿日: 2026年02月28日
何ができるようになったのか #
AWS Elemental MediaLive において、映像の入力と出力の両方で SRT（Secure Reliable Transport）の リスナー（Listener）モード が利用可能になりました。 これまでは MediaLive 側から外部へ接続しに行く「コーラー（Caller）モード」のみでしたが、今回のアップデートにより、MediaLive が接続を「待ち受ける」ことができるようになります。
何が嬉しいのか #
ネットワーク構成が大幅に簡素化されます。特に、オンプレミス環境のエンコーダーからクラウドの MediaLive へ映像を送信する場合、これまではオンプレミス側のファイアウォールでインバウンド接続を許可する設定が必要でしたが、リスナーモードを使えばオンプレミス側から MediaLive へ「プッシュ」するだけで済むため、セキュリティポリシーの変更なしに導入しやすくなります。
これまでとどう変わるのか #
- これまで: SRT コーラーモードのみをサポートしていました。MediaLive が映像ソースや配信先の IP アドレスを把握して接続を開始する必要があり、相手側でインバウンド通信を許可する（ポートを開ける）設定が必須でした。
- これから: リスナーモードを選択することで、MediaLive 側で接続を待ち受けることができます。送信元は MediaLive のエンドポイントに対して接続を開始するだけでよく、送信元ネットワークのファイアウォール設定を簡略化できます。
具体的なユースケース #
- リモート制作拠点からの映像送信: ファイアウォール内に設置されたカメラやエンコーダーから、クラウド上の MediaLive へ直接ライブ映像をプッシュ送信する。
- 柔軟な映像配信: 配信パートナーが、必要なタイミングで MediaLive の出力エンドポイントへ接続して映像を「プル（取得）」する。
SRT は「Secure Reliable Transport」の略です。 不安定なネットワーク（公衆インターネットなど）経由でも、低遅延かつセキュアに高品質なビデオを伝送するために設計されたオープンソースのビデオ伝送プロトコルです。 主な特徴は以下の通りです。
- 独自のパケット損失回復メカニズムにより、ジッターやパケットロスが発生しやすい環境でも安定した伝送が可能.
- AES 暗号化によるコンテンツ保護をサポート。
- 遅延（レイテンシ）と信頼性のバランスを細かく調整可能。
Amazon Bedrock AgentCore Policy が一般提供開始（GA） #
投稿日: 2026年03月03日
何ができるようになったのか #
Amazon Bedrock AgentCore において、エージェントとツールの相互作用を細かく制御するための「Policy（ポリシー）」機能が一般提供開始（GA）となりました。 この機能により、セキュリティやコンプライアンスの担当チームは、エージェントのコードを一切変更することなく、どのエージェントがどのツールにアクセスできるか、どのような入力パラメータを許可するかといった認可ルールを中央集中型で定義・管理できるようになります。
何が嬉しいのか #
AI エージェントの動作を「決定論的（確実）」に制御できるようになります。プロンプトによる指示だけでは防ぎきれない予期せぬツールの実行や、権限を超えた操作を、ポリシーエンジンによって確実に遮断できます。また、自然言語で記述したルールを AWS のオープンソースポリシー言語「Cedar」に自動変換する機能も備わっており、専門的な知識がなくても安全なガバナンス体制を構築できます。
これまでとどう変わるのか #
- これまで: エージェントが利用できるツールの制限や入力値のチェックは、主にエージェントの指示（システムプロンプト）や、ツール側の Lambda 関数内での個別の実装に頼る必要がありました。これでは管理が煩雑になり、セキュリティの担保も困難でした。
- これから: AgentCore Gateway がエージェントとツールの間の通信をインターセプトし、設定されたポリシーに基づいてリクエストを評価します。エージェント本体とは独立して認可レイヤーが存在するため、一貫したセキュリティポリシーを複数のエージェントに横断的に適用可能です。
具体的なユースケース #
- 役職に基づいた操作制限: 「一般社員用エージェントは社内データの読み取りツールのみ許可し、マネージャー用エージェントのみが顧客へのメール送信ツールを利用できる」といったルールを適用する。
- パラメータによるガードレール: 「返金処理ツールにおいて、100ドルを超える金額の入力があった場合は自動的に拒否する」という制限を設ける。
Cedar は、AWS が開発したオープンソースのポリシー言語です。 主な特徴は以下の通りです。
- 決定論的: 「許可」か「拒否」かを数学的に厳密に判定します。
- デフォルト拒否: 明示的に許可されていない操作はすべて禁止される、セキュアな設計（ゼロトラスト）を採用しています。
- NL2Cedar: 自然言語の指示から Cedar ポリシーを自動生成する機能が AgentCore に統合されています。