AWS What's New Digest

Appearance

2026年10月21日 ​

[Connect] Amazon Connect Customer launches two new layouts for agent workspace ​

概要 ​

Amazon Connect Customerのエージェントワークスペースに、画面スペースを最適化する「Modern」と「Classic」の2つの新レイアウトが追加されました。管理者はチームごとに最適なレイアウトを割り当てられ、エージェントの操作性と効率を向上できます。

変更内容・新機能の詳細 ​

新しい2つのレイアウトは以下の通りです。

  • Modernレイアウト: コンタクトコントロール（通話ミュート、保留、終了など）をワークスペースの上部に配置し、その下のアプリケーション領域を最大化します。音声通話時はアプリ表示スペースが広くなり、チャット／メール／タスクを扱う場合は読み取り・応答用の表示領域が高く、幅も広くなります。これによりマルチチャネル対応のエージェントが素早く情報を確認・入力できます。
  • Classicレイアウト: 既存のエージェントワークスペースと馴染みのある見た目を維持しつつ、チャネルに応じて展開・収縮するコンタクトコントロールと、サイズ変更可能なAgent Assistアプリケーションをサポートします。既存運用を継続しながら段階的に移行するチーム向けです。 管理者はチーム単位でどちらのレイアウトを使うかを設定可能で、他のデスクトップから移行するチームにはModernを、既存のワークスペースに慣れているチームにはClassicを割り当てるなどの運用判断がしやすくなっています。対応リージョンは以下の通りです：米国東部（バージニア北部）、米国西部（オレゴン）、アフリカ（ケープタウン）、アジアパシフィック（ソウル、シンガポール、シドニー）、カナダ（中央）、欧州（フランクフルト、ロンドン）。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンターの管理者、エージェント、SRE/運用チーム
  • 利用シーンまたは効果: チームごとに最適な画面レイアウトを割り当てることで、音声通話中心のワークフローやチャット／メール中心のワークフローに応じて閲覧・操作効率が向上します
  • 運用効果: エージェントの作業効率と満足度向上、応対時間短縮や誤操作の低減につながる可能性があります
  • 導入コスト影響: 機能自体に関する追加料金は記事に明示されていないため通常のAmazon Connect運用コスト内で利用可能（ただし設定・テストに係る運用工数は発生します）

技術的な注意点 ​

  • IAM権限: レイアウト設定やチームへの割当は管理者権限が必要です。Amazon Connectの管理コンソール操作権限または相応のIAMポリシーを確認してください
  • リージョン制限: 現時点で利用可能なリージョンは記事記載の9リージョンのみです。他リージョンでは未対応の可能性があります
  • 互換性・移行: 他のデスクトップ（サードパーティ製含む）からの移行時はModernが適している一方、既存ワークスペースに慣れたチームはClassicを継続可能です。レイアウト変更はチーム単位で行われるため段階的ロールアウトが可能です
  • コスト: 新レイアウト自体について追加料金の記載はありませんが、設定検証やトレーニング、画面カスタマイズに伴う人的工数は発生します
  • その他注意点: Agent Assistアプリのリサイズやチャネルごとのコントロール動作などUI挙動が変わるため、実運用投入前に主要ケースでの操作確認とエージェント教育を推奨します

参考情報 ​

[S3] Amazon S3 server access log delivery to Amazon CloudWatch Logs now available in five additional AWS Regions ​

概要 ​

Amazon S3 のサーバーアクセスログを Amazon CloudWatch Logs に配信する機能が、AWS GovCloud (US)、AWS European Sovereign Cloud、AWS China リージョンで利用可能になり、これにより全リージョン対応となりました。CloudWatch Logs 側でリアルタイム検索、アラーム設定、KMS による暗号化が可能になります。

変更内容・新機能の詳細 ​

S3 のサーバーアクセスログ（リクエスター、バケット、タイムスタンプ、操作、HTTP ステータス、転送量、User-Agent、リクエスト ID 等を含む標準ログ形式）を直接 CloudWatch Logs（ロググループ）へ配信できる新しい配信パスが、追加リージョンで有効になりました。これにより既存の S3 一般的なバケットへのログ配信と併用して、より柔軟な監視・分析が可能です。CloudWatch Logs に配信されたログはほぼリアルタイムで CloudWatch Logs Insights によるクエリ、メトリクスフィルタ／アラーム設定、サブスクリプションフィルタ（Lambda／Kinesis へのストリーミング）やロググループ単位の KMS 暗号化を利用できます。なお、CloudWatch Logs 側の“vended logs” に対する課金が適用されます（取り込み・保管・データ転送等の CloudWatch 料金が別途発生）。この機能は全リージョンで利用可能になったため、GovCloud／China／欧州ソブリンを含む各パーティションで同様のオペレーションが行えます。

影響範囲・利用シーン ​

  • 対象ユーザー: S3 を利用するセキュリティ／監査担当者、SRE、運用チーム、ログ分析者
  • 利用シーンまたは効果: リアルタイムでのアクセス監視（エラー率や異常トラフィックのアラート）、インシデント調査（アクセス元やリクエスト詳細の即時検索）、S3 アクセスとアプリケーション／インフラの他ログとの相関分析
  • 運用効果: ログ保管バケットの参照や追加処理を待たずに即時クエリやアラートが可能になり、検知から対応までの時間短縮が期待できる
  • 費用影響: CloudWatch Logs の取り込み・保管・クエリ等に対する追加コストが発生するため、想定ログ量に応じたコスト試算が必要
  • リージョン影響: 追加で GovCloud (US)、European Sovereign Cloud、China リージョンに対応し、結果として全リージョンで利用可能

技術的な注意点 ​

  • IAM権限: CloudWatch Logs のロググループへ書き込むためのリソースベースポリシーや必要な権限を設定する必要があります（S3 サービスがログを配信できるように適切な許可を付与）。
  • KMS/暗号化: CloudWatch Logs に対する KMS 暗号化を利用する場合、KMS キーのキー政策で配信元サービス／アカウントを許可する設定が必要です。
  • リージョン制限: 本発表で GovCloud、European Sovereign、China を含め全リージョン対応となりましたが、GovCloud/China はパーティションやアカウント運用ルールが異なるため、アカウント構成・コンプライアンス要件を事前に確認してください。
  • クロスアカウント配信: 別アカウントの CloudWatch Logs へ配信する場合は、ロググループのリソースポリシーやクロスアカウントの信頼関係設定が必要になることがあります。
  • コスト: CloudWatch Logs（vended logs）取り込み・ストレージ・Insights クエリ・エクスポート等の料金が発生します。大量ログを長期間保持する場合はコスト影響が大きくなるため、保持期間（retention）やフィルタ／サンプリングの検討を推奨します。
  • 互換性: 既存の S3 サーバーアクセスログを S3 バケットへ配信する従来の方法は引き続き利用可能で、両者を併用することでアーカイブとリアルタイム分析を両立できます。
  • 監査/コンプライアンス: ソブリン／中国リージョンではデータ主権やログ保管要件が異なる場合があるため、規制要件に合わせた設計を行ってください。

参考情報 ​

[SageMaker] Amazon SageMaker AI now supports custom sequence lengths for serverless model customization jobs ​

概要 ​

Amazon SageMaker AIのサーバーレスモデルカスタマイズで、カスタムのシーケンス長をハイパーパラメータとして指定できるようになりました。これにより短いQ&Aから長文ドキュメントまで学習データに合わせた長さでファインチューニングできます。

変更内容・新機能の詳細 ​

SageMaker AIのサーバーレスモデルカスタマイズが、モデル／手法ごとの公開上限内でシーケンス長を設定可能になりました。対応するオープンウェイト系モデルファミリにはgpt-oss、Gemma、Llama、Nemotron、Qwenなどが含まれます。設定できるハイパーパラメータは手法ごとに異なり、SFT（Supervised Fine-Tuning）およびDPOでは dataset_max_len を指定、RFT（Reinforcement-from-Feedback／別名RFTの文脈で利用されている場合）では max_prompt_length と max_response_length を指定します。多くのモデルと手法で最大16Kトークンまでサポートされるものがあり、公開されているモデル別・手法別の最大値に従って設定可能です。サーバーレス実行はインフラ管理不要で、SageMaker StudioのModelsページ、SageMaker Python SDK、またはAgentスキル（選択したコーディングアシスタント経由）からカスタマイズジョブを起動できます。長いシーケンスを用いる場合はメモリ使用量・実行時間・コストが増加する点に注意が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、SageMakerでモデルカスタマイズを行う開発者
  • 利用シーン: 短いQAペアから複数ページにわたる文書まで、入力/出力の長さ特性に合わせたファインチューニング（SFT/DPO/RFT）の最適化
  • 運用効果: データの実際のトークン長に合わせることで学習品質が向上し、長文コンテキストの扱いが必要なアプリケーションで性能改善が期待できる
  • 注意される影響: シーケンス長を伸ばすとメモリ使用量・レイテンシ・コストが増加するため、コスト管理やバッチサイズ・勾配蓄積戦略の見直しが必要
  • リージョン適用範囲: サーバーレスモデルカスタマイズは US East (N. Virginia)、US West (Oregon)、Asia Pacific (Tokyo)、Europe (Ireland) で利用可能

技術的な注意点 ​

  • IAM権限: カスタマイズジョブの作成・実行にはSageMakerの適切なIAM権限（ジョブ作成、ログ出力、モデルアクセス等）が必要です
  • リージョン制限: サーバーレスモデルカスタマイズの利用は記事記載の4リージョンに限定されています（Tokyo含む）
  • コスト: シーケンス長を長くするとメモリ消費と実行時間が増え、サーバーレス実行の料金が上昇します。見積もりとモニタリングを推奨します
  • モデル/手法の制限: 公開されているモデルごと、手法（SFT/DPO/RFT）ごとに最大トークン長が異なります。設定はその公開上限まで可能で、上限を超えるとエラーになります
  • ハイパーパラメータ名: SFT/DPO -> dataset_max_len、RFT -> max_prompt_length と max_response_length を使用します（正確な名前はドキュメント/SDKで確認）
  • トークナイザ注意: シーケンス長はトークン単位です。使用モデルのトークナイザ（BPE等）でのトークン化後の長さを基準に設定してください。文字数ではなくトークン数を計測する必要があります
  • 実行時影響: 長いシーケンスはVRAM/メモリ使用量を大きく増やすため、バッチサイズや勾配蓄積、混合精度（FP16）などの調整が必要になることがあります
  • 互換性/起動方法: SageMaker StudioのModelsページ、SageMaker Python SDK、Agentスキルのいずれからジョブ起動可能。SDKのバージョンやエージェントのスキル要件を事前に確認してください
  • データ前処理: データセットはトークン化、必須のパディング/トランケーション、ラベル整形を適切に行ってからdataset_max_len等を適用してください
  • モニタリング: 長シーケンスでは学習失敗やOOMのリスクが高まるため、CloudWatchやSageMakerのログでメモリ／エラーを監視してください

参考情報 ​

[Route 53] AWS Network Firewall now supports Route 53 Resolved IP Validation ​

概要 ​

AWS Network FirewallがRoute 53 VPC Resolverによる“解決済みIP（Resolved IP）検証”をサポートしました。これによりHTTP/HTTPS以外（例：SFTP、SSHなど）のプロトコルでもドメインベースのフィルタリングが可能になります。

変更内容・新機能の詳細 ​

Resolved IP検証は、通信の宛先IPアドレスがVPCのAmazon Route 53 VPC Resolverで実際に解決されたIPであることを確認する機能です。仕組みとしては、Network Firewallが観測した接続先IPに対して、そのIPがVPC Resolver経由で名前解決された結果として得られたIPと照合を行います。これにより、クライアントが直接IPで接続したり、SNIの偽装（SNI spoofing）でドメインベースのルールを回避するケースをクローズできます。主な効果は以下のとおりです：

  • HTTP/HTTPS以外のプロトコル（SSH、SFTP、FTP等）についてもドメインベースのポリシーを適用可能。
  • SNIが使われるTLS接続では、Route 53で解決されたIPとSNI情報を突き合わせることでSNI偽装対策を補強。
  • IPベースのルールだけでは捉えづらいドメイン単位の一貫したセキュリティポリシーを、あらゆる送信トラフィックに対して適用可能。 また、Route 53 Resolver DNS Firewall（DNS Firewall）と組み合わせることで、DNS段階でのブロッキング＋Network Firewallによる接続時の検証という二段構えの防御が実現できます。サービスはAWS商用リージョンで提供され、追加料金は発生しません（詳細はリージョン対応リストを参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク/セキュリティエンジニア、SRE、クラウドアーキテクト
  • 利用シーン: SSH/SFTP等の非HTTPトラフィックに対してドメインベースのアクセス制御を行いたい場合（例：社外SFTPサーバへの接続をドメインで許可）
  • 運用効果: IPホワイトリストの枚挙や頻繁なIP更新から解放され、ドメイン単位で一貫したアウトバウンド制御が可能になり、SNI偽装などによるポリシー回避リスクを低減
  • 既存環境への影響: DNS解決経路がVPC Resolver経由でないトラフィックは検証対象にならないため、DNS設定やルーティングの見直しが必要な場合がある

技術的な注意点 ​

  • IAM権限: Network FirewallおよびRoute 53 Resolverを設定・更新するIAM権限（例: network-firewall:PutFirewallPolicy等）を確認してください。詳細な権限は公式ドキュメントを参照してください
  • リージョン制限: 商用リージョンで提供されていますが、利用可能リージョンはAWS Capabilities by Regionページで必ず確認してください
  • コスト: 本機能自体に追加料金は発生しないと発表されていますが、Route 53 ResolverやNetwork Firewallの利用自体の通常料金は発生します
  • 前提条件: VPC内のDNS解決がRoute 53 VPC Resolver経由で行われている必要があります。クライアントが別のDNSを直接使用している場合や、接続がDNS解決を伴わない（IP直指定）場合は検証できません
  • 制限事項: プロトコル固有のメタデータ（例: SNI）が存在しないトラフィックでは、DNSクエリと接続の紐付けが必要になるため完全な保証には限界があります。また、検証処理に伴うごくわずかな遅延や運用上の設定変更が発生する可能性があります

参考情報 ​

[ECS] Announcing Amazon ECS Gateway, a managed ingress solution for your ECS services ​

概要 ​

Amazon ECS Gatewayは、ECSサービス向けのマネージドなingressソリューションで、ALB（Application Load Balancer）や関連リソースをユーザのアカウント内に動的プロビジョニングしてIngressの管理とガバナンスを簡素化します。プラットフォームチームが組織のネットワーク標準を1つのゲートウェイで定義し、アプリチームはそのゲートウェイにオプトインするだけで標準を継承できます。

変更内容・新機能の詳細 ​

ECS Gatewayは、ECSクラスタにアタッチするリソース（ゲートウェイ）を作成し、クラスタ内のサービスが接続すると必要に応じてApplication Load Balancer（ALB）、リスナー、ターゲットグループ、セキュリティグループ等を自動的にプロビジョニングしてフルライフサイクルを管理します。主な技術要点は以下の通りです。

  • ホストベースルーティングを採用し、各サービスにユニークなDNSホスト名を割り当てる（サービスごとにホストヘッダでルーティング）。
  • 最大25サービスを1つのALBで共有できるため、インフラコストを最適化可能。ALBのキャパシティ上限に到達するとECSが自動で追加のALBをプロビジョニングし、不要になれば削除します。
  • ゲートウェイと各サービスへのルート構成、プロビジョニングされたリソースは可視化され、どのようにリクエストがサービスに到達するかを確認できます。
  • モニタリングは標準のALBメトリクス（Amazon CloudWatch）およびElastic Load Balancingのターゲットヘルス情報を利用可能。
  • 利用開始手順は、ECS Gatewayの作成→クラスタへの関連付け→サービス側でgateway connectorパラメータを追加してオプトイン（AWS Management Console / AWS CLI / API / SDK / CloudFormationに対応）。
  • 対応条件として、awsvpcネットワークモードのECSサービスで利用可能で、すべての起動タイプ（Fargate / EC2 / External等）をサポートします。
  • 料金はECS Gateway自体の追加料金はなく、ゲートウェイにサービスが接続した際にアカウント内でプロビジョニングされる基盤リソース（ALB、データ転送、ENIなど）に対して通常の料金が発生します。

影響範囲・利用シーン ​

  • 対象ユーザー: プラットフォームチーム（ネットワーク/セキュリティ標準を一元管理したいチーム）、アプリケーション開発チーム、SRE/運用チーム
  • 利用シーン: 組織的なIngressポリシーの一元化（共通TLS、WAF、セキュリティグループ設定等）、複数サービスのALB共有によるコスト最適化、オンボーディング時のネットワーク設定簡素化
  • 運用効果: ALBやリスナー設定を個別管理する手間が削減され、アプリチームはネットワーク専門知識が無くてもガバナンスに準拠した公開が可能。ALBの自動スケール/削除により運用負荷と過剰プロビジョニングを低減
  • 制限影響: awsvpcネットワークモードが必須なため、bridgeなど別のネットワークモードを使う既存ワークロードは変更や検討が必要
  • 観測/デバッグ: ALBの標準メトリクスとターゲットヘルス、ゲートウェイルールの可視化でトラフィック経路とヘルス確認が容易になる

技術的な注意点 ​

  • IAM権限: ECSがALB等を作成・管理するための権限（Elastic Load Balancing: Create/Modify/Delete、EC2: ENIやセキュリティグループ操作、IAMのサービスリンクロールの作成等）が必要。事前にサービスリンクロールと必要権限の確認を推奨します。
  • リージョン制限: 公表情報では全商用リージョンで利用可能とされていますが、個別リージョンの機能差分やローンチ直後は一部リージョンでドキュメント差異がある可能性があるため利用前に該当リージョンのドキュメントを確認してください。
  • コスト: ECS Gateway自体に追加料金はありませんが、プロビジョニングされるALB（ALB時間課金、LCU/リクエスト単位課金）、データ転送、ENIやNAT等の関連リソースに対し通常料金が発生します。ALBを共有することでコスト削減が期待できますが、トラフィック量が増えると追加ALBがプロビジョニングされる点に留意してください。
  • ネットワークモード: awsvpcのみサポート。既存サービスが別モードの場合はタスク定義の見直しが必要です。
  • サービス制限: 1つのALBに最大25サービスを共有という設計制約があるため、大規模なサービス数を持つ場合は設計時にALBスケールの挙動を考慮してください。
  • 可視化/監査: ECSがアカウント内に作成するリソースはユーザ側で確認可能（コンソール/CLI/CloudFormationでのテンプレート化やタグ付けの検討を推奨）。
  • 互換性: 全起動タイプ（Fargate/EC2/External）に対応とされていますが、各起動タイプ固有のネットワークやIAM要件を満たす必要があります。
  • CloudFormation/API: Console/CLI/API/SDK/CloudFormationからの設定が可能。自動化・インフラストラクチャー-as-codeでの導入を推奨します。

参考情報 ​

[DynamoDB] Amazon DynamoDB global tables now support disassociating replicas ​

概要 ​

Amazon DynamoDBのグローバルテーブルで、レプリカ（複製テーブル）をテーブルやデータを削除せずにレプリケーションから切り離せる機能が追加されました。これにより、特定リージョンやアカウントをレプリケーション対象から外し、そのテーブルを単一リージョンの通常テーブルとして継続利用できます。

変更内容・新機能の詳細 ​

今回の更新で、DynamoDB Global Tables（マルチリージョン・マルチアクティブレプリケーション）において、レプリカを削除せずに“disassociate”（切り離す）操作が可能になりました。切り離し操作を行うと、そのレプリカとの間の双方向レプリケーションが停止される一方で、レプリカ側のテーブルとデータはそのまま残り、ローカルワークロードや検証、監査用途で利用可能です。対応範囲は同一アカウント／マルチアカウントのグローバルテーブルで、multi-Region eventual consistency（MREC）を使用している構成です。操作はAWS Management Console、AWS CLI、DynamoDB API（DisassociateReplica等）、およびAWS CloudFormationから実行できます。切り離し後は、そのリージョン／アカウントのテーブルは単一リージョンテーブルとして振る舞い、以降のローカル書き込みは他リージョンへレプリケートされません。

影響範囲・利用シーン ​

  • 対象ユーザー: DB管理者、クラウド/インフラエンジニア、アプリケーション開発者、セキュリティ/コンプライアンス担当者
  • 利用シーン: マルチリージョン構成から一部リージョンまたはアカウントを切り離してローカル検証、監査、またはリージョン単独での運用へ移行する際に利用
  • 運用効果: レプリケーション停止によるクロスリージョン通信・レプリケーション先の書き込み負荷削減、グローバルテーブルからの容易な離脱により運用作業が簡素化
  • コスト: レプリケーションを停止することで将来的なレプリケーション関連のデータ転送や追加の書き込みキャパシティ課金を抑制可能（ただし既存のデータ保管や過去の転送分は対象外）
  • リスク/注意点: 切り離した後のテーブルは以降の変更が他リージョンに反映されずデータの乖離が発生するため、再度グローバルテーブル化する際はデータ同期手順が必要になる可能性が高い

技術的な注意点 ​

  • IAM権限: disassociate操作を行うには該当API（例: dynamodb:DisassociateReplica やテーブル更新権限）を付与する必要があります。CloudFormationやCLIを使う場合はそれらのアクションに対応する権限も必要です
  • リージョン制限: 記事では「すべてのAWSリージョンでサポート」と明記されていますが、実運用前に対象リージョンのコンソールやドキュメントでサポート状況を確認してください
  • データ整合性/再結合: 切り離し後に発生した更新は他リージョンへ伝播しないため、再度レプリカを追加（再結合）する際には手動でのデータ同期（バックアップ/リストアやデータ移行）や整合性確認が必要になる場合があります
  • 運用機能への影響: 切り離してもそのテーブルのバックアップ、Point-in-Time Recovery（PITR）、DynamoDB Streamsなどローカルの機能は継続して利用可能。ただしストリームの用途や下流プロセスがグローバル前提の場合は影響を確認してください
  • コスト: 切り離しは将来のレプリケーション関連コストを削減しますが、テーブルのストレージ・ローカルの読み書き課金は継続します。再作成や再同期時にはデータ転送コストが発生する可能性があります
  • 自動化/インフラ管理: CloudFormationやCLI/APIから実行可能なので、Infrastructure as Codeでの移行・切り離し操作に組み込めますが、事前にロールバック手順や同期ポリシーを定義してください

参考情報 ​

[General] Polly Generative engine upgraded with more natural speech, 14 new voices, and 2 new languages ​

概要 ​

Amazon Polly Generativeの音声合成モデルが新しいモデルにアップグレードされ、より自然で高精度な音声出力と低レイテンシを実現しました。14の新しい音声（9つのロケール）と、初めてGenerativeエンジンで利用可能になったヒンディー語とフィンランド語を追加しています。

変更内容・新機能の詳細 ​

今回のアップグレードはPolly Generativeエンジンのコアモデルを差し替えるドロップイン型の改良で、音声の自然さ・正確性が向上し、数値・メールアドレス・住所など複雑なコンテンツの読み上げ精度が改善されています。Generativeは従来通りSSMLタグで発話制御が可能で、低レイテンシのストリーミングAPIによりコンタクトセンター、チャットボット、LLMベースの対話型音声エージェントなどリアルタイム会話アプリケーションに適しています。追加された新音声はKenneth、Nate（米英）、Russell、Curtis（豪英）、Kiara、Arjun（ヒンディー語とインド英語）、Tina（独語）、Carlos（米スペイン語）、Leo、Carolina（ブラジルポルトガル語）、Hyunduk（韓国語）、Suvi（フィンランド語）などです。提供リージョンは、US East (N. Virginia)、US West (Oregon)、Europe (Frankfurt)、Europe (Zurich)、Europe (London)、Asia Pacific (Sydney)、Asia Pacific (Seoul)、Asia Pacific (Singapore)、Asia Pacific (Tokyo)、Canada (Central)、および AWS GovCloud (US-West)です。用途としてはニュース・メディアの音声化、eラーニング、アクセシビリティ、IVR/音声応答、音声付きエージェント等が想定されます。詳細は公式ドキュメントと料金ページで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 音声アプリケーション開発者、コンタクトセンター運用者、チャットボット/LLM音声エージェント開発者、メディア／eラーニング制作チーム、アクセシビリティ担当者、パブリックセクターと規制業界のエンジニア
  • 利用シーン: リアルタイムな対話型音声（IVR、音声ボット、LLM音声エージェント）、ナレーション／コンテンツ音声化（ニュース、ポッドキャスト、eラーニング）、支援技術による読み上げ、規制対応が必要なワークロード向けのGovCloud配備
  • 運用効果: 音声の自然さと読み上げ精度が向上することでプロンプトやSSMLの微調整が減り、導入コストと開発工数が低減。低レイテンシのストリーミングでリアルタイムUXが改善し、GovCloud対応により公共機関や規制業務でも利用可能になる

技術的な注意点 ​

  • IAM権限: Pollyの合成API（SynthesizeSpeechやストリーミング系API）へのアクセス権が必要です。利用するAPIに応じたIAMポリシーを付与してください。
  • リージョン制限: 新しいGenerative音声は記事に列挙されたリージョン（N. Virginia、Oregon、Frankfurt、Zurich、London、Sydney、Seoul、Singapore、Tokyo、Canada (Central)、AWS GovCloud (US-West)）で利用可能です。その他リージョンでは未提供の可能性があります。
  • コスト: 料金は既存のPollyと異なる場合があります。利用前にAmazon Pollyの料金ページでGenerative（新音声/ストリーミング）の課金体系を確認してください。追加料金が発生する可能性があります。
  • SSML互換性: 既存のSSMLタグは引き続き使用可能です。発音や間の調整はSSMLで制御できますが、モデル側の改善により調整回数は減少します。
  • 互換性/移行: ドロップイン型のモデルアップグレードのため、既存の呼び出し方法は原則そのまま動作しますが、本番運用前に音声サンプル確認と回帰テストを推奨します。
  • 性能注意: 低レイテンシが改善されていますが、ネットワーク条件やAPI呼び出し設計により実際の応答時間は変動します。リアルタイム用途ではエンドツーエンドの遅延評価を行ってください。
  • 発音差・ローカリゼーション: 新しいロケール・音声ごとに発音やイントネーションに差があります。言語固有の発音（固有名詞、数字フォーマット等）は事前にテストし、必要に応じて辞書やSSMLで補正してください。

参考情報 ​

[Ec2] AWS announces TorchNeuron: Native PyTorch Support for AWS Trainium (Public Beta) ​

概要 ​

AWSは、PyTorchをネイティブにTrainium上で動作させるオープンソースのバックエンド「TorchNeuron」のパブリックベータを発表しました。開発者はほぼそのままのPyTorchコード（例: .to('neuron')）でTrainium2/Trainium3インスタンスを利用できます。

変更内容・新機能の詳細 ​

TorchNeuronは、AWS Trainium（Trainium2/Trainium3）向けのネイティブPyTorchバックエンドで、オープンソースとして公開されたパブリックベータです。主な特徴は以下の通りです。

  • 簡単な移植: 既存のPyTorchコードを.to('neuron')に切り替えるだけでTrainium上での実行を試せる設計。
  • PyTorch互換性: eager実行や torch.compile、標準のPyTorch APIと互換性を保ちながら動作することを目指しています。
  • Neuron Kernel Interface (NKI) 統合: ハードウェア固有の最適化やカスタムオペレーターの実装が可能で、高性能化のための低レイヤー最適化を行えます。
  • デプロイ先: Amazon EC2 の Trainium2 および Trainium3 インスタンスでの利用を想定し、TorchNeuronはGitHubで公開されています。
  • オープンソース: ソースを確認・拡張できるため、研究用途や独自最適化の導入が行いやすくなっています。 なお、TorchNeuronはパブリックベータ段階のため、互換性やパフォーマンスの挙動は今後のリリースで変わる可能性があり、Neuronランタイム/SDKや対応PyTorchバージョンを併せて確認する必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: AI研究者、MLエンジニア、PyTorchでモデル開発を行う開発チーム
  • 利用シーン: 大規模なディープラーニングのトレーニング／推論をTrainium上で実行してコスト効率・スループットを改善する場面
  • 運用効果: ほぼそのままのPyTorchコードでTrainiumを試験導入でき、ハードウェア最適化（NKI）を活用することでトレーニング時間とコストの削減が期待できる

技術的な注意点 ​

  • IAM権限: EC2インスタンス起動、関連AMI/EBSアクセス、VPC/セキュリティグループの設定など適切な権限が必要です
  • リージョン制限: TrainiumおよびNeuron関連サービスはリージョン依存で提供状況が異なります。利用前に対象リージョンでの対応有無を確認してください
  • コスト: Trainiumインスタンスは専用アクセラレータを持つためインスタンス料金が発生します。GPUとの比較やジョブサイズに応じたコスト評価が必要です
  • ベータ注意: パブリックベータのためAPI/挙動が変更される可能性があり、本番移行時は互換性確認とリグレッション検証を推奨します
  • 対応インスタンス: 明示的にAmazon EC2 Trainium2、Trainium3 を対象としています。既存のインスタンスタイプでは動作しません
  • ソフトウェア依存: TorchNeuron利用にはNeuronランタイム／SDKや特定のPyTorchバージョンが必要になる可能性があります。リポジトリのREADMEで対応バージョンとインストール手順を確認してください
  • カスタムオペレーター: NKI経由で独自オペレーターを導入可能ですが、実装／最適化には低レイヤー知識とビルド作業が必要です
  • ライセンス/OSS: TorchNeuronはオープンソースで公開されています。商用利用や再配布時のライセンス条件はリポジトリで確認してください

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026