はじめに #
AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
まとめと気づき #
「AWS Step Functions が分散マップのデータソースオプションを拡張し、可観測性を向上」が気になりました。Step Functionsはよく使われると思いますが、機能制限によりカスタム関数を追加することもよくありますよね。個々の独自の処理が要らなくなるのは大変便利だと思います。それに加えてIPv6も対応するということで、これからもますます中心的なサービスとして活躍しそうです。
Amazon Kinesis Data Streams が AWS GovCloud (US) リージョンでインターネットプロトコルバージョン 6 のサポートを拡大 #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon Kinesis Data Streams が AWS GovCloud (US) リージョンで、インターネットプロトコルバージョン 6 (IPv6) を介した API リクエストをサポートするようになりました。これにより、顧客はデュアルスタックのパブリックエンドポイントまたは VPC エンドポイントを介して、IPv6 または IPv4 のいずれかを使用してリクエストを送信するオプションが利用できます。また、新しいエンドポイントは Federal Information Processing Standard (FIPS) 140-3 プログラムの下で検証されています。
何が嬉しいのか #
IPv6 のサポートにより、利用可能なアドレス数が大幅に増加し、顧客は重複するアドレス空間の管理が不要になります。多くのデバイスやネットワークが既に IPv6 を使用しているため、データストリームへの書き込みや読み取りが容易になります。FIPS 準拠のエンドポイントは、米国連邦政府と契約している企業が、サポートされているリージョンで機密データを暗号化するという FIPS セキュリティ要件を満たすのに役立ちます。
これまでとどう変わるのか #
- これまで
- AWS GovCloud (US) リージョンでは、Kinesis Data Streams の API リクエストは主に IPv4 を介して行われており、IPv6 ネイティブな環境との統合やアドレス空間の管理に課題がありました。また、FIPS 140-3 準拠の IPv6 エンドポイントは利用できませんでした。
- これから
- AWS GovCloud (US) リージョンでも IPv6 を介した API リクエストが可能になり、より広範なアドレス空間を利用できるようになります。これにより、IPv6 を使用するデバイスやネットワークからのデータストリームへのアクセスが容易になり、FIPS 140-3 準拠のセキュリティ要件を満たす政府機関の顧客も安心して利用できます。
具体的なユースケース #
- IPv6 ネイティブなデバイスやネットワークからリアルタイムで大量のデータを Kinesis Data Streams に取り込み、処理する企業。
- 米国連邦政府との契約があり、FIPS 140-3 のセキュリティ要件を満たす必要がある政府機関や請負業者。
- 重複する IPv4 アドレス空間の管理を避けたい顧客。
Amazon BedrockでStability AI Image Servicesが利用可能に #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon BedrockでStability AI Image Servicesが利用可能になりました。これは、プロのクリエイティブワークフローを加速するために設計された、9つの専門的な画像編集ツールを含む包括的なスイートです。このサービスにより、画像編集をきめ細かく制御し、単一のコンセプトから完成品までを正確かつ柔軟に実現できるようになります。
提供される画像編集機能は以下の2つのカテゴリに分けられます。
- 編集ツール: 背景の削除、オブジェクトの消去、検索と置換、検索と再着色、インペイントといった機能で、画像内の特定の部分をターゲットに修正できます。
- 制御ツール: 構造、スケッチ、スタイルガイド、スタイル転送といった機能で、既存の画像やスケッチに基づいてバリエーションを生成する強力な方法を提供します。
Stability AI Image Servicesは、APIを通じてAmazon Bedrockで利用でき、米国西部 (オレゴン)、米国東部 (バージニア北部)、米国東部 (オハイオ) リージョンでサポートされています。
何が嬉しいのか #
- クリエイティブワークフローの加速: 9つの専門ツールにより、画像編集プロセスが大幅に効率化され、迅速なコンテンツ制作が可能になります。
- きめ細やかな画像制御: 背景の削除からスタイル転送まで、幅広い編集機能により、ユーザーは画像に対して高度な制御を行えます。
- アイデアから完成品までの一貫性: アイデア出しから最終的な画像生成・編集までをAmazon Bedrock内で一貫して行えるため、クリエイティブなビジョンを忠実に実現できます。
- 多様なニーズへの対応: マーケティング、デザイン、コンテンツ制作など、様々な業界や用途における画像編集のニーズに応えることができます。
これまでとどう変わるのか #
- これまで
- Amazon BedrockではStability AIの画像編集サービスが直接提供されていなかったため、高度な画像編集を行うには、外部のツールやサービスを別途利用し、それらをBedrockのワークフローと統合する必要がありました。
- 画像生成AIと編集ツール間の連携が複雑で、クリエイティブワークフローに手間がかかる場合がありました。
- これから
- Amazon Bedrock上でStability AI Image Servicesを直接利用できるようになり、画像生成から編集までを一貫してBedrock内で完結できるようになりました。
- 9つの専門ツールが統合されたことで、クリエイティブワークフローが簡素化され、より効率的かつ柔軟な画像編集が可能になります。
具体的なユースケース #
- マーケティング素材の迅速な作成: 製品写真から背景を削除したり、特定の要素を置き換えたりして、広告キャンペーンやソーシャルメディア投稿用の画像を素早く生成・編集します。
- デザインの反復と探索: スケッチや既存のデザインに基づいて、様々なスタイルや構造のバリエーションを生成し、デザインの選択肢を広げ、迅速なプロトタイピングを行います。
- パーソナライズされたコンテンツの生成: ユーザーの好みや入力に基づいて画像を生成し、その後、インペイントで特定のオブジェクトを修正したり、再着色したりして、よりパーソナライズされた体験を提供します。
- ブランドイメージの一貫性維持: スタイルガイドツールを使用して、生成されるすべての画像がブランドの視覚的アイデンティティに沿っていることを確認し、一貫性のあるコンテンツを制作します。
AWS BedrockでOpenAIオープンウェイトモデルが新しいリージョンに拡大 #
投稿日: 2025年09月18日
何ができるようになったのか #
AWS Bedrock上でOpenAIのオープンウェイトモデルが、新たに8つのAWSリージョンで利用可能になりました。これにより、より多くの地域でこれらの強力なAIモデルにアクセスできるようになります。
何が嬉しいのか #
AIを活用したアプリケーションにおいて、レイテンシーの低減とパフォーマンスの向上が期待できます。また、データを希望する地理的ロケーション内に保持できるため、データレジデンシー要件への対応が容易になり、ネットワークレイテンシーも削減されます。
これまでとどう変わるのか #
- これまで
- OpenAIのオープンウェイトモデルは、AWS Bedrock上でUS West (Oregon) リージョンでのみ利用可能でした。
- これから
- US East (N. Virginia)、Asia Pacific (Tokyo)、Europe (Stockholm)、Asia Pacific (Mumbai)、Europe (Ireland)、South America (São Paulo)、Europe (London)、Europe (Milan) の8つのリージョンが追加され、合計9つのリージョンで利用できるようになりました。
具体的なユースケース #
- レイテンシーを最小限に抑え、パフォーマンスを最大化する必要があるAI駆動型アプリケーションの開発。
- 特定の地域にデータを保持する必要がある、データレジデンシー要件が厳しいワークロード。
- グローバルに展開する企業が、各地域のユーザーに地理的に近い場所でAIモデルを提供し、ユーザーエクスペリエンスを向上させる。
Amazon BedrockでQwen3モデルがフルマネージドで利用可能に #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon Bedrockで、Qwen3のオープンウェイト基盤モデル4種類（Qwen3-Coder-480B-A35B-Instruct、Qwen3-Coder-30B-A3B-Instruct、Qwen3-235B-A22B-Instruct-2507、Qwen3-32B）がフルマネージドかつサーバーレスなサービスとして利用可能になりました。これらのモデルは、密なアーキテクチャとMixture-of-Experts (MoE) アーキテクチャの両方を特徴とし、特にQwen3-Coderモデルはエージェントコーディングや複雑なソフトウェアエンジニアリングタスクにおいて、関数呼び出しやツール利用で最先端のパフォーマンスを発揮します。
Qwen3は、Alibaba Cloudによって開発された、オープンソースの大規模言語モデル（LLM）のファミリーです。
テキスト生成、質問応答、翻訳、コーディングなど、多様なタスクで高い性能を発揮するように設計されています。特に、Mixture-of-Experts (MoE) アーキテクチャを採用したモデルは、計算効率を維持しながら性能をスケールさせることを可能にしています。
主な特徴は以下の通りです。
- 多様なモデルサイズ: 小規模なものから数百億パラメータを持つ巨大なモデルまで、様々なサイズが提供されており、ユースケースに応じた選択が可能です。
- 高いコーディング能力: Qwen3-Coderモデルは、特にソフトウェア開発タスクに特化しており、コード生成や関数呼び出しで最先端の性能を示します。
- 多言語対応: 幅広い言語に対応しており、グローバルなアプリケーションでの利用に適しています。
- オープンソース: モデルの重みが公開されており、研究者や開発者が自由に利用・改変できます。
AWSのAmazon Bedrockのようなプラットフォームで利用することで、開発者はインフラ管理の手間なく、Qwen3の強力な機能を活用したAIアプリケーションを迅速に構築できます。
何が嬉しいのか #
インフラストラクチャの管理なしに、高度なエージェント機能を備えた強力なAIアプリケーションを構築できるようになります。多様な開発ニーズに対応できる柔軟なモデル選択肢が提供され、特にコーディングや複雑なタスクにおいて高い性能を持つモデルを容易に利用できるため、開発効率とアプリケーションの能力が向上します。
これまでとどう変わるのか #
- これまで
- Qwen3のオープンウェイトモデルをAmazon Bedrockでフルマネージドサービスとして利用することはできませんでした。
- エージェントコーディングや複雑なソフトウェアエンジニアリングタスクに特化した高性能なオープンウェイトモデルの選択肢が限られていました。
- これらのモデルを利用するには、ユーザー自身がインフラストラクチャを管理する必要がありました。
- これから
- Qwen3のオープンウェイトモデルがフルマネージドで提供されるため、インフラ管理の負担なく利用できます。
- Qwen3-Coderモデルにより、エージェントコーディングや複雑なソフトウェアエンジニアリングタスク、関数呼び出し、ツール利用を伴うAIアプリケーション開発が容易かつ高性能に行えるようになります。
- 一般的な推論や幅広い計算タスクにも対応できる多様なモデルが選択肢に加わります。
具体的なユースケース #
- エージェントコーディングや複雑なソフトウェアエンジニアリングタスクを自動化するAIアプリケーションの開発
- 関数呼び出しや外部ツールとの連携を高度に行うAIエージェントの構築
- 一般的な推論能力と指示追従能力を必要とする多様なタスク（例：コンテンツ生成、要約、質問応答）
- 幅広い計算タスクやデータ処理を効率的に行うAIモデルの利用
DeepSeek-V3.1 モデルがAmazon Bedrockでフルマネージドとして利用可能に #
投稿日: 2025年09月18日
何ができるようになったのか #
DeepSeek-V3.1がAmazon Bedrockでフルマネージドな基盤モデルとして利用可能になりました。このモデルは、詳細な段階的分析のための思考モードと、より迅速な応答のための非思考モードを切り替えることができます。包括的な多言語サポートを備え、以前のDeepSeekモデルと比較して精度が向上し、ハルシネーションが減少しています。また、意思決定プロセスの可視性も維持されます。
何が嬉しいのか #
最先端のソフトウェア開発から複雑な数学的推論、データ分析まで、様々なビジネス機能でDeepSeek-V3.1のエンタープライズグレードの機能を利用できます。高度な問題解決タスクに優れ、コーディングベンチマークや技術的課題で高いパフォーマンスを発揮します。強化されたツール呼び出し機能とシームレスなワークフロー統合により、AIエージェントの構築やエンタープライズプロセスの自動化に最適です。その透明性の高い推論アプローチは、チームがその出力を理解し、信頼するのに役立ちます。
これまでとどう変わるのか #
- これまで
- DeepSeekモデルはAmazon Bedrockでフルマネージドとして直接利用できませんでした。思考モードと非思考モードの切り替え機能や、現在のDeepSeek-V3.1が提供するような強化された精度、ハルシネーションの削減、意思決定プロセスの可視性は利用できませんでした。
- これから
- DeepSeek-V3.1がAmazon Bedrockでフルマネージドサービスとして提供されるため、ユーザーはインフラ管理の負担なく、この高度なモデルを簡単に利用できます。思考モードと非思考モードを切り替えることで、タスクに応じて最適な応答速度と詳細度を選択できるようになり、多言語サポート、高精度、低ハルシネーション、透明性の高い推論といった恩恵を受けられます。
具体的なユースケース #
- 最先端のソフトウェア開発におけるコード生成、デバッグ、レビュー
- 複雑な数学的推論や科学計算の支援
- 大規模なデータセットの分析と洞察の抽出
- 顧客サービス、社内業務、データ処理などのためのAIエージェントの構築
- エンタープライズワークフローの自動化と効率化
Amazon EVSがパブリックインターネット経由のHCX移行をサポート #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon Elastic VMware Service (Amazon EVS) が、オンプレミスデータセンターからAmazon EVS環境へのレイヤー2ネットワークのセキュアな移行と拡張を、パブリックインターネット経由でサポートするようになりました。これにより、VMware HCXを使用したワークロード移行において、Elastic IPアドレス (EIP) を利用して安定したエンドポイントと迅速なセットアップが可能になります。
HCXは「VMware Hybrid Cloud Extension」の略で、オンプレミスのvSphere環境とクラウド環境（AWS上のVMware Cloudなど）の間で、仮想マシンの移行やネットワークの拡張を容易にするためのVMware社のソリューションです。
主な特徴は以下の通りです。
- ハイブリッド接続: オンプレミスとクラウドのデータセンターを安全に接続し、単一の連続したネットワークとして管理できます。
- ライブマイグレーション: 仮想マシンを稼働させたまま、ダウンタイムなしでオンプレミスとクラウド間で移行できます。
- ネットワーク拡張: オンプレミスのネットワークセグメントをクラウドに拡張し、IPアドレスを変更することなく仮想マシンを移行できます。
- WAN最適化: 移行トラフィックを圧縮・重複排除することで、ネットワーク帯域幅の消費を抑え、移行時間を短縮します。
Amazon EVSのようなサービスと組み合わせることで、企業は既存のVMwareベースのワークロードを、最小限の変更で迅速かつ安全にAWSへ移行し、ハイブリッドクラウド環境を構築できます。
何が嬉しいのか #
これまで専用のプライベート接続（AWS Direct ConnectやVPNなど）が必要だったHCX移行において、パブリックインターネットを利用する選択肢が加わったことで、より柔軟な移行が可能になります。プライベート接続が利用できない場合や、移行中に高いネットワークパフォーマンスを必要としないアプリケーションやプロジェクトにおいて、費用対効果の高い代替手段として利用できます。
これまでとどう変わるのか #
- これまで
- Amazon EVSへのワークロード移行は、主にAWS Direct ConnectやVPNなどの専用プライベート接続に依存していました。
- これから
- 専用プライベート接続がない場合や、よりコスト効率の良い方法を求める場合に、パブリックインターネット経由でHCX移行を実行できるようになりました。
具体的なユースケース #
- AWS Direct ConnectやVPNなどのプライベート接続オプションが利用できない環境からのワークロード移行。
- 移行中のネットワークパフォーマンス要件が厳しくなく、コストを抑えたいアプリケーションやプロジェクトの移行。
第二世代のAWS OutpostsラックがAWSカナダ（中央）および米国西部（北カリフォルニア）リージョンでサポート開始 #
投稿日: 2025年09月18日
何ができるようになったのか #
第二世代のAWS Outpostsラックが、AWSカナダ（中央）および米国西部（北カリフォルニア）リージョンでサポートされるようになりました。これにより、カナダおよび米国内外の組織は、これらの新しいサポート対象リージョンに接続されたOutpostsラックを注文できるようになります。
何が嬉しいのか #
AWS Outpostsラックは、AWSのインフラストラクチャ、サービス、API、ツールを事実上あらゆるオンプレミスデータセンターまたはコロケーションスペースに拡張し、真に一貫性のあるハイブリッドエクスペリエンスを提供します。今回のリージョン拡張により、顧客はレイテンシーとデータレジデンシーの要件に合わせて最適化できるようになり、Outpostsを接続できるAWSリージョンの選択肢がさらに柔軟になります。
これまでとどう変わるのか #
- これまで
- AWSカナダ（中央）および米国西部（北カリフォルニア）リージョンにOutpostsラックを接続することができませんでした。そのため、これらのリージョンに特化したレイテンシーやデータレジデンシーの要件を持つ顧客は、ハイブリッドクラウドの導入に制約がありました。
- これから
- AWSカナダ（中央）および米国西部（北カリフォルニア）リージョンにOutpostsラックを接続できるようになり、これらのリージョンに特化した要件を持つ顧客も、一貫したハイブリッドエクスペリエンスを享受し、レイテンシーとデータレジデンシーのニーズを最適化できるようになります。
具体的なユースケース #
- オンプレミスシステムへの低レイテンシーアクセスが必要なワークロードをローカルで実行しつつ、アプリケーション管理のためにホームリージョンに接続する。
- データレジデンシー要件を満たすためにオンプレミスに留める必要があるデータを管理および処理する。
Amazon Q Developer CLI がリモート MCP サーバーのサポートを発表 #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon Q Developer CLI がリモート MCP (Managed Control Plane) サーバーのサポートを開始しました。これにより、開発タスクで使用するツールのスケーラビリティとセキュリティが向上します。HTTP および OAuth ベースの認証をサポートする Atlassian や GitHub などの MCP サーバーと統合できるようになりました。
何が嬉しいのか #
集中型サーバーに移行することで、コンピューティングリソースの使用量を削減し、アクセスとセキュリティをより適切に管理できるようになります。これにより、開発環境の効率性と安全性が向上します。
これまでとどう変わるのか #
- これまで
- リモート MCP サーバーのサポートがなかったため、開発ツールのスケーラビリティやセキュリティ管理に課題があった可能性があります。各開発環境で個別にリソースを消費し、アクセス管理も分散的でした。
- これから
- リモート MCP サーバーを構成することで、開発ツールを集中管理し、コンピューティングリソースを削減できます。また、OAuth ベースの認証により、アクセスとセキュリティをより強固に管理できるようになります。
具体的なユースケース #
- Atlassian や GitHub などの既存の MCP サーバーと Amazon Q Developer CLI を統合し、開発ワークフローを効率化する。
- 開発ツールへのアクセスを一元的に管理し、セキュリティポリシーを適用することで、コンプライアンス要件を満たす。
- 開発環境のコンピューティングリソースを集中型サーバーにオフロードし、開発者のローカルマシンへの負荷を軽減する。
Amazon VPC Reachability AnalyzerとAmazon VPC Network Access Analyzerが7つのAWSリージョンで利用可能に #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon VPC Reachability AnalyzerとAmazon VPC Network Access Analyzerが、以下の7つのAWSリージョンで利用可能になりました。
- アジアパシフィック (ニュージーランド)
- アジアパシフィック (ハイデラバード)
- アジアパシフィック (メルボルン)
- アジアパシフィック (台北)
- カナダ西部 (カルガリー)
- イスラエル (テルアビブ)
- メキシコ (セントラル)
何が嬉しいのか #
より多くのリージョンでこれらのツールを利用できるようになることで、VPC内のネットワーク到達性の診断や、意図しないネットワークアクセスの特定が容易になります。これにより、ネットワークのトラブルシューティングが迅速化され、セキュリティとコンプライアンスの維持が強化されます。
これまでとどう変わるのか #
- これまで
- 上記7つのリージョンでは、VPC Reachability AnalyzerとVPC Network Access Analyzerが利用できなかったため、ネットワークの到達性診断や意図しないネットワークアクセスの特定には、手動での確認や他のツールを組み合わせる必要があり、時間と労力がかかっていました。
- これから
- これらのリージョンでも、自動化された専用ツールを使用して、VPC内のリソース間のネットワーク到達性を効率的に診断し、セキュリティポリシーに違反する可能性のあるネットワークアクセスパスを特定できるようになります。これにより、運用効率とセキュリティ体制が大幅に向上します。
具体的なユースケース #
- VPC Reachability Analyzer:
- あるAWSアカウントのEC2インスタンスが、別のAWSアカウントのEC2インスタンスに接続できない場合に、VPCルーティングテーブルの欠落エントリなど、ネットワーク到達性を妨げている設定ミスを特定する。
- 新しいネットワーク設定をデプロイする前に、期待されるネットワークパスが正しく機能するかを検証する。
- ネットワークの変更後に、既存の重要な接続が意図せず切断されていないことを確認する。
- VPC Network Access Analyzer:
- ウェブアプリケーションからインターネットへのすべてのトラフィックが、指定されたファイアウォールを確実に通過していることを検証し、ファイアウォールをバイパスするパスを検出する。
- コンプライアンス要件（例：PCI DSS、HIPAA）を満たすために、機密データへの不正なネットワークアクセスパスが存在しないことを定期的に監査する。
- セキュリティグループやネットワークACLの設定ミスにより、意図しないポートが開いていないか、またはリソースが公開されていないかを検出する。
Amazon Lex が強化された確認および通貨組み込みスロットを10の追加言語で提供開始 #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon Lexが、ポルトガル語、カタロニア語、フランス語、イタリア語、ドイツ語、スペイン語、北京語、広東語、日本語、韓国語の10の追加言語で、確認（Confirmation）および通貨（Currency）スロットタイプをサポートするようになりました。
「スロットタイプ」とは、会話型AI（チャットボットなど）がユーザーの発言から特定の情報（スロット）を収集する際の、その情報の「種類」や「カテゴリ」を定義するものです。
例えるなら、アンケート用紙の質問項目のようなものです。
- スロット: 「お客様の誕生日はいつですか？」という質問項目そのもの。
- スロットタイプ: その質問項目に期待される回答の形式。「日付」という種類。
Amazon Lexのようなサービスでは、以下のようなスロットタイプが使われます。
-
組み込みスロットタイプ:
- AWSが事前に定義している一般的な情報の種類です。
AMAZON.DATE（日付）、AMAZON.NUMBER（数値）、AMAZON.CITY（都市名）など、多くの種類があります。- 「確認スロットタイプ」や「通貨スロットタイプ」もこの一種です。
- これらを使うことで、「明日」を具体的な日付に変換したり、「二百」を「200」という数値に変換したりする処理をAIが自動的に行ってくれます。
-
カスタムスロットタイプ:
- 開発者が独自に定義する情報の種類です。
- 例えば、「製品カテゴリ」というスロットタイプを定義し、その値として「Tシャツ」「ジャケット」「パンツ」などをリストアップすることができます。
- これにより、AIはユーザーが「ジャケットが欲しい」と言った際に、「製品カテゴリ」として「ジャケット」を正しく認識できるようになります。
スロットとスロットタイプを適切に設計することで、AIはユーザーとの対話から必要な情報を正確に抽出し、目的のタスク（予約、注文、情報提供など）を実行できるようになります。
「確認（Confirmation）スロットタイプ」と「通貨（Currency）スロットタイプ」は、Amazon Lexのような会話型AIサービスで、ユーザーからの特定の種類の情報を効率的に収集・解釈するために事前定義された機能です。
-
確認スロットタイプ (Confirmation Slot Type):
- ユーザーの「はい/いいえ」の意図を捉えるために使われます。
- 例えば、「予約を確定しますか？」という質問に対して、ユーザーが「はい」「ええ」「お願いします」と答えても、あるいは「いいえ」「やめておきます」「結構です」と答えても、それらを肯定（Yes）または否定（No）の標準的な値に自動的に解決してくれます。
- これにより、開発者は多様な肯定・否定の表現を個別に処理するロジックを書く必要がなくなります。
-
通貨スロットタイプ (Currency Slot Type):
- ユーザーが言及した金額に関する情報を抽出するために使われます。
- 例えば、ユーザーが「10ドル」「200円」「5ユーロ」などと発言すると、その数値を標準化された形式（例:
USD 10.00,JPY 200,EUR 5.00）で自動的に抽出します。 - これにより、通貨記号や単位の揺れを吸収し、システムが後続の処理（例: 支払い、計算）を正確に行えるようになります。
これらの組み込みスロットタイプを利用することで、開発者はより少ない労力で、自然で精度の高い会話フローを構築できます。
何が嬉しいのか #
組み込みスロットにより、ユーザーの発言の同義語を理解し、それらの入力を標準形式に解決することで、より自然で効率的な会話を構築できるようになります。これにより、多言語での会話型AIエクスペリエンスの構築が容易になり、ユーザー体験が向上します。
これまでとどう変わるのか #
- これまで
- これらの10の追加言語では、強化された確認および通貨スロットタイプが利用できませんでした。そのため、開発者はこれらの言語でユーザーの確認や通貨に関する発言を正確に理解し、標準化するために、より多くのカスタムロジックを実装する必要がありました。
- これから
- Amazon Lexがこれらの10言語で確認および通貨スロットタイプをネイティブにサポートするため、開発者はより少ない労力で、より自然で効率的な多言語会話型インターフェースを構築できます。例えば、「nope」や「absolutely not」といった表現を「No」に、または「1 dollar」を「USD 1.00」に自動的に解決できるようになります。
具体的なユースケース #
- 多言語対応のコンタクトセンターで、顧客が様々な言語で「はい」「いいえ」を表現する際に、それを正確に「Yes」または「No」として認識し、会話の流れをスムーズにする。
- 国際的なEコマースプラットフォームで、顧客が異なる言語で通貨の金額を言及する際に、それを自動的に標準化された通貨形式（例：「1ドル」を「USD 1.00」）に変換し、注文処理を簡素化する。
- グローバルなサービスを提供するチャットボットが、ユーザーの確認応答（例：「結構です」「問題ない」など）を多言語で正確に解釈し、適切なアクションを実行する。
Amazon OpenSearch Serverless がディスク最適化ベクトルをサポート #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon OpenSearch Serverless で、ディスク最適化ベクトルがサポートされるようになりました。これにより、精度と再現率を損なうことなく、ベクトル検索操作のための費用対効果の高いソリューションが提供されます。
何が嬉しいのか #
運用コストを大幅に削減しながら、高品質なベクトル検索機能を実装できるようになります。メモリ最適化ベクトルと同等の高い精度と再現率を、より低いコストで実現できます。サブミリ秒の応答時間が重要ではないユースケースに最適です。
これまでとどう変わるのか #
- これまで
- ベクトルストレージの選択肢がメモリ最適化のみであり、コストが課題となる場合がありました。
- これから
- メモリ最適化とディスク最適化の2つのベクトルストレージオプションから選択できるようになり、コストとパフォーマンスのバランスを最適化できます。
具体的なユースケース #
- セマンティック検索アプリケーション
- レコメンデーションシステム
- その他のAIを活用した検索シナリオ（特にサブミリ秒のレイテンシーが必須ではない場合）
AWS Step FunctionsがデュアルスタックエンドポイントでIPv6をサポート #
投稿日: 2025年09月18日
何ができるようになったのか #
AWS Step FunctionsがIPv6をサポートし、新しいデュアルスタックエンドポイント（IPv4とIPv6の両方に対応）を介してIPv6トラフィックを送受信できるようになりました。また、PrivateLinkインターフェースVPCエンドポイントを介したIPv6接続もサポートされ、パブリックインターネットを経由せずにプライベートにサービスにアクセスできます。
何が嬉しいのか #
- インターネットの拡大に伴うIPアドレスの需要増加に対応し、より大きなアドレス空間を提供します。
- IPv4アドレス空間の制約に縛られることなく、サーバーレスワークフローを構築できるようになります。
- 既存のIPv4エンドポイントとの後方互換性を維持しつつ、IPv4とIPv6の両方のプロトコルをサポートします。
- IPv6環境で運用している組織が、複雑なIPv6からIPv4への変換メカニズムを必要とせずに、Step Functionsとネイティブに統合できるようになります。
これまでとどう変わるのか #
- これまで
- AWS Step Functionsは主にIPv4で動作しており、IPv6環境からの接続には、IPv6からIPv4への変換メカニズムが必要となる場合がありました。
- これから
- AWS Step FunctionsがIPv6をネイティブにサポートし、デュアルスタックエンドポイントおよびPrivateLink経由でのIPv6接続が可能になります。これにより、IPv6環境からの直接的かつセキュアなアクセスが実現します。
具体的なユースケース #
- IPv6環境で動作するアプリケーションをモダナイズし、Step Functionsを組み込む場合。
- IPv4アドレスの枯渇を気にせず、大規模な分散アプリケーションやIT/ビジネスプロセス自動化ワークフローを構築する場合。
- IPv6のみのネットワーク環境から、複雑なアドレス変換なしにStep Functionsに直接アクセスする必要がある場合。
- PrivateLinkを使用して、パブリックインターネットを経由せずにIPv6でStep Functionsにプライベートかつセキュアに接続する場合。
Amazon SageMaker HyperPod が Karpenter を使用したオートスケーリングをサポート #
投稿日: 2025年09月18日
何ができるようになったのか #
Amazon SageMaker HyperPod が Karpenter を使用したマネージドノードのオートスケーリングをサポートするようになり、顧客は動的な推論およびトレーニングの需要に合わせてクラスターを自動的にスケーリングできるようになりました。
Karpenterは、Kubernetes向けのオープンソースのクラスタオートスケーラーです。アプリケーションのワークロード需要に応じて、適切なサイズのコンピュートリソース（EC2インスタンスなど）を迅速かつ効率的にプロビジョニングします。
従来のKubernetesオートスケーラー（Cluster Autoscaler）との主な違いは、ノードグループを管理する必要がない点です。
主な特徴は以下の通りです。
- ジャストインタイムなノードプロビジョニング: Podのスケジューリングが保留されると、KarpenterはPodの要件（CPU、メモリ、GPUなど）に最適なインスタンスを直接起動し、クラスタに追加します。
- ワークロードに合わせた最適化: アプリケーションの実際の要求に基づいてインスタンスを選択するため、リソースの過剰なプロビジョニングを避け、コストを最適化します。
- 迅速なスケーリング: 数分ではなく数秒で新しいノードを起動できるため、急なトラフィックの増加にも迅速に対応できます。
- ノードグループの不要: 事前に定義されたノードグループを管理する必要がなく、運用オーバーヘッドを大幅に削減します。
Amazon SageMaker HyperPodのようなサービスに統合されることで、機械学習のトレーニングや推論といった動的なワークロードに対して、インフラの管理を意識することなく、常に適切な量のリソースを確保し、コスト効率の高い運用を実現します。
何が嬉しいのか #
- リアルタイム推論ワークロードにおいて、予測不可能なトラフィックパターンに対応し、サービスレベルアグリーメントを維持しながらコストを最適化できます。
- 複雑なオートスケーリングソリューションのインストール、設定、保守にかかる運用上のオーバーヘッドが解消されます。
- 統合された回復力と耐障害性機能が提供されます。
- 推論トラフィックスパイクに対してGPUコンピューティングを迅速に適応させるジャストインタイムプロビジョニングを実現します。
- 低需要期間中に専用のコントローラーインフラストラクチャを維持することなく、ノードをゼロにスケールできます。
- インスタンスタイプとコストを最適化するワークロード認識型ノード選択の恩恵を受けられます。
- 推論ワークロードでは、本番トラフィックの急増に対応するための自動キャパシティスケーリング、アイドル期間中のインテリジェントなノード統合によるコスト削減、KEDAのようなイベント駆動型Podオートスケーラーとのシームレスな統合が可能です。
- トレーニングワークロードでも、モデル開発サイクル中の自動リソース最適化の恩恵を受けられます。
これまでとどう変わるのか #
- これまで
- 組織は、複雑なオートスケーリングソリューションのインストール、設定、保守にかかる運用上のオーバーヘッドに苦慮していました。
- ノードをゼロにスケールする場合でも、専用のコントローラーインフラストラクチャを維持する必要がありました。
- コスト最適化が非効率的になる可能性がありました。
- これから
- HyperPodマネージドノードのオートスケーリングにより、Karpenterのセットアップと保守における差別化されていない重労働が不要になります。
- 統合された回復力と耐障害性が提供されます。
- ジャストインタイムプロビジョニングにより、推論トラフィックスパイクに迅速に対応できます。
- 専用のコントローラーインフラストラクチャなしでノードをゼロにスケールできます。
- ワークロード認識型ノード選択により、インスタンスタイプとコストが最適化されます。
- 推論ワークロードでは、自動キャパシティスケーリング、インテリジェントなノード統合によるコスト削減、KEDAとのシームレスな統合が実現します。
- トレーニングワークロードでは、モデル開発サイクル中の自動リソース最適化が可能になります。
具体的なユースケース #
- 予測不可能なトラフィックパターンを持つリアルタイム推論ワークロードの運用。
- 推論およびトレーニングワークロードのコスト最適化。
- 推論における本番トラフィックの急増への対応。
- アイドル期間中のインテリジェントなノード統合によるリソース効率の向上。
- モデル開発サイクルにおけるトレーニングワークロードの自動リソース最適化。
- 推論トラフィックスパイクに合わせてGPUコンピューティングを動的にスケーリング。
AWS Step Functions が分散マップのデータソースオプションを拡張し、可観測性を向上 #
投稿日: 2025年09月18日
何ができるようになったのか #
AWS Step Functions の分散マップ (Distributed Map) 機能において、以下の点が改善されました。
- データソースの拡張:
- AWS Athena のデータマニフェストファイルと Parquet ファイルを直接処理できるようになりました。
- S3ListObjectsV2 を使用して、指定されたプレフィックス下の S3 オブジェクトを反復処理できるようになりました。
- JSON オブジェクトから直接読み込み、Amazon S3 またはステート入力から JSON オブジェクト内の配列データをネイティブに抽出できるようになり、カスタムの前処理が不要になりました。
- 可観測性の向上:
- 分散マップの使用状況に関する新しいメトリクス（Approximate Open Map Runs Count、Open Map Run Limit、Approximate Map Runs Backlog Size）が提供され、可視性が向上しました。
何が嬉しいのか #
- 開発の簡素化と効率化: カスタムの前処理ロジックを記述する必要がなくなり、大規模な分析や ETL ワークフローの構築がより簡単かつ迅速に行えるようになります。
- 柔軟性の向上: より多様なデータ形式やソースを直接 Step Functions のワークフローに統合できるようになり、幅広いユースケースに対応できます。
- 運用管理の改善: 分散マップの実行状況を詳細なメトリクスで監視できるようになり、パフォーマンスのボトルネックの特定や、スケーリング戦略の最適化が容易になります。
これまでとどう変わるのか #
- これまで
- 分散マップで処理できるデータソースが限られており、Athena の結果や Parquet ファイル、S3 オブジェクトのリストなどを処理するには、通常、前処理ステップや追加の AWS サービス（例: Lambda 関数）を組み合わせてデータを整形する必要がありました。
- JSON オブジェクトから配列データを抽出する際にも、カスタムの変換ロジックが必要となることがありました。
- 分散マップの実行状況に関する詳細な運用メトリクスが不足しており、大規模なワークロードの監視やトラブルシューティングが困難な場合がありました。
- これから
- Athena データマニフェスト、Parquet ファイル、S3 オブジェクトリスト、JSON 配列など、より多くのデータソースをカスタムの前処理なしで直接 Step Functions のワークフローに統合できるようになります。
- Approximate Open Map Runs Count などの新しいメトリクスにより、分散マップの同時実行数、制限、バックログサイズなどを詳細に監視し、運用上の可視性が大幅に向上します。
具体的なユースケース #
- 大規模なデータ変換と分析: S3 バケットに保存された大量の Parquet 形式のログファイルやデータレイクのデータを、分散マップを使用して並行して処理し、変換や集計を行う。
- S3 オブジェクトの一括処理: 特定の S3 プレフィックス下のすべての画像ファイルに対して、サムネイル生成やメタデータ抽出などの処理を並行して実行する。
- Athena クエリ結果の後処理: Athena のクエリ結果マニフェストを直接入力として、各結果レコードに対して個別のビジネスロジック（例: データベースへの書き込み、通知の送信）を実行する。
- API レスポンスの並行処理: 外部 API から取得した JSON レスポンスに含まれる配列データ（例: 複数の顧客情報）を抽出し、各要素に対して独立したワークフローを実行する。
- ワークフローの監視と最適化: 新しいメトリクスを活用して、分散マップの実行状況をリアルタイムで監視し、リソースのプロビジョニングやスロットリング設定を調整して、ワークフローのパフォーマンスとコスト効率を最適化する。
図解 Amazon Web Servicesの仕組みとサービスがたった1日でよくわかる 単行本（ソフトカバー） – 2022/2/2
¥2,200
Amazonで見る