本記事は 2026 年 2 月 26 日 に公開された「 Optimize data management on S3 Tables with Intelligent-Tiering 」を翻訳したものです。 多くの組織が、ペタバイト規模の成長とパフォーマンスに対応でき、コストのかかるリライトなしにスキーマやパーティションを柔軟に変更できる Apache Iceberg をデータレイクに採用しています。タイムトラベルやインクリメンタル処理といった機能により、最新のデータレイク管理が可能になります。しかし、データが増大するにつれ、Iceberg データセットの効率的な管理は難しくなります。規制要件や長期的な分析ニーズから数か月〜数年にわたりデータを保持する組織も多く、パフォーマンスやアクセス性とコストのバランスに苦慮しています。テーブルのメンテナンス、ファイルレイアウトの最適化、コスト効率の高いリテンションポリシー（維持期間）の実装は、継続的にリソースを消費し、コスト増加につながります。 Amazon S3 Tables は、Iceberg テーブル向けに設計されたテーブルストレージと新しいバケットタイプを導入し、 Amazon S3 に構造化データを簡単に保存できるようにしました。S3 Tables はコンパクション、スナップショット管理、参照されていないファイルの削除といったメンテナンスタスクを自動的に処理します。さらに、 Intelligent-Tiering ストレージクラス のサポートが追加されました。アクセスパターンに基づいてデータをストレージ階層間で自動的に移動し、ストレージコストを最適化します。データレイクの規模が拡大しデータが古くなっても、パフォーマンスに影響を与えることなくコスト効率を継続的に最適化できます。 本記事では、Intelligent-Tiering をコンパクションやスナップショット管理などの メンテナンス機能 と組み合わせて、長期的な総所有コスト (TCO) を削減する方法を詳しく解説します。 S3 Tables でのデータ管理の最適化 S3 Tables にデータが到着した時点では、最適な状態ではない場合があります。たとえば、分析効率よりも取り込みスループットや柔軟性を優先してデータが取り込まれることがあります。ストリーミング更新で頻繁にテーブルへの変更がコミットされ小さなファイルが生成されるケースや、merge-on-read パターンでテーブル更新時にインクリメンタルな差分ファイル/deleteファイルが追加されるケースが典型的です。このような場合、クエリパフォーマンスの向上と長期的なストレージの最適化にメンテナンス操作が必要になります。S3 Tables は長期的なデータ最適化のために以下の手法をサポートしています。 スナップショット管理 – 必要な履歴データのみを保持し、冗長な情報を体系的に廃止・削除して、参照されていないファイルを完全に除去します コンパクション (Binpack、Sort、Z-order) – 小さなファイルを統合してより大きく効率的なファイルを作成します。Sort や Z-order を使ってデータを並べ替え、より高速でコスト効率の高いクエリを実現したり、delete ファイルをデータファイルにマージしたりできます ストレージ階層の最適化 – Intelligent-Tiering ストレージクラスを活用し、規制やビジネスニーズによる長期データ保持のストレージコストを削減します S3 Tables のスナップショット管理 Iceberg のスナップショットは、テーブルの完全な状態を記録した不変のポイントインタイムレコードです。既存のコンテンツを変更せずに、すべてのデータファイルとメタデータをキャプチャします。タイムトラベルクエリ、同時操作中の一貫した読み取り、運用復旧やリストアのための以前のテーブルバージョンへのロールバックといった機能を実現します。 S3 Tables は、リテンションポリシーの設定やライフサイクル管理の自動化のための コンソールコントロールと API 操作 でスナップショット管理を効率化します。 S3 Tables は、履歴データのニーズとストレージ最適化のバランスをとるための調整可能な有効期限ルールを提供し、ガバナンス要件に対応するスナップショットメトリクスと監査証跡も備えています。保持するスナップショットの最小数、スナップショットの最大保持期間、参照されていないファイルの削除などのプロパティが含まれます。スナップショット管理の詳細は こちらの動画 で解説しています。 nonCurrentDays 、 unreferencedDays 、 maximumSnapshotAge 、 minimumSnapshots などのチューニングパラメータについては、 考慮事項と制限 を慎重に評価することをお勧めします。リテンション要件に合わせて適切に値を調整してください。 S3 Tables のコンパクション Apache Iceberg のコンパクションは、複数の戦略でテーブルパフォーマンスを最適化します。小さなファイルを大きなファイルに統合してメタデータの負荷と I/O リクエスト料金を削減し、delete ファイルをマージし、ソート順でデータをリライトしてパーティション述語を高速化し、多次元クラスタリングで関連データを近接配置して複数カラムでのスキャン効率を向上させます。Amazon S3 Tables は適切なポリシーでコンパクションを自動化し、テーブルのファイルレイアウトを継続的に最適化し、クエリパフォーマンスの向上とコスト削減を実現します。コンパクションのスケジューリング、リソース割り当て、実行を自動的に処理するため、運用負荷がなくなります。S3 Tables は以下のコンパクション手法をサポートしています。 Binpack コンパクション – 多数の小さなデータファイルを少数の最適なサイズのファイルに統合し、メタデータの負荷を削減して、分散処理フレームワークでクエリパフォーマンスを低下させる「スモールファイル問題」を最小化します Sort コンパクション – 1 つ以上の指定カラムに従ってレコードを物理的に並べ替えるようにデータファイルをリライトし、メタデータベースのフィルタリングによる効率的なデータスキッピングを可能にして、ソートカラムに一致する述語でのクエリパフォーマンスを大幅に向上させます Z-order コンパクション – 空間充填曲線(space-filling curve)アルゴリズムで多次元データを 1 次元空間にマッピングし、複数カラムにわたって類似するレコードを近接配置して、Z-order 対象次元の任意のサブセットに対する述語を持つクエリを最適化します Auto (デフォルト) – Amazon S3 Tables がテーブルのソート順に基づいて最適なコンパクション戦略を選択します。すべてのテーブルのデフォルトのコンパクション戦略です。メタデータにソート順が定義されているテーブルには Sort コンパクションが自動的に適用されます。ソート順が定義されていないテーブルには Binpack コンパクションがデフォルトで使用されます 詳細は S3 Tables メンテナンスドキュメント と、AWS での Apache Iceberg 利用に関する規範的ガイダンスの コンパクションセクション をご覧ください。 適切なコンパクションの実施は、持続可能なデータレイク管理に不可欠です。最適化されていないテーブルは、時間の経過とともにパフォーマンスが低下しコストが増加します。定期的なコンパクションにより、小さなファイルの蓄積を防ぎ、最適なデータ構成を維持し、テーブルがペタバイト規模に成長してもクエリ効率を確保できます。パフォーマンス面の直接的なメリットに加え、適切に実行されたコンパクションは圧縮率とファイルレイアウトの改善によりストレージ効率を向上させます。より安定したクエリパフォーマンス、予測可能なコスト、そしてリアクティブなテーブルメンテナンスではなく価値を生み出す活動にエンジニアリングリソースを集中できるようになります。 S3 Tables の Intelligent-Tiering 前述のスナップショットとコンパクション機能に加え、S3 Tables は re:Invent 2025 で S3 Intelligent-Tiering によるストレージ最適化を提供開始しました。このストレージクラスは、アクセスパターンの変化に基づいてコスト効率の高いアクセス階層間でデータを自動的に移動します。データ取得にかかる費用、パフォーマンスへの影響、可用性の変化はありません。 S3 Intelligent-Tiering は個々のデータファイルレベルで動作するため、1 つのテーブル内のファイルが異なる階層に同時に存在できます。データは以下の 3 つのアクセス階層で自動的に管理されます。 高頻度アクセス (FA) – すべてのファイルのデフォルト階層。他の階層のファイルもアクセスされるとここに戻ります 低頻度アクセス (IA) – 30 日間連続してアクセスがないファイルがここに移動します アーカイブインスタントアクセス (AIA) – 90 日間連続してアクセスがないファイルがここに移動します すべての階層でミリ秒レイテンシー、高スループットパフォーマンス、99.9% の可用性、99.999999999% の耐久性が維持されます。オブジェクトは Get API 呼び出しでアクセスされると高頻度アクセス (FA) 階層に遷移します。テーブル内のデータファイルが読み取られるたびに、読み取りをトリガーした操作に関係なく発生します。データファイルの読み取り (FA 階層への遷移) をトリガーする操作は以下のとおりです。 テーブルへの直接アクセス – データファイルを読み取るクエリやスキャン テーブル管理操作 – 既存のデータファイルの読み取りを必要とする LoadTable や UpdateTable などの REST API 呼び出し レプリケーション – テーブルがレプリケートされる際、コンテンツを転送先に転送するためにソースデータファイルを読み取る必要があり、IA/AIA 階層のファイルに対して Get 呼び出しがトリガーされます 重要なポイントとして、階層の遷移はデータファイルが読み取られたときにファイルレベルで発生し、テーブルが参照されたときではありません。基盤となる S3 オブジェクトの読み取りを伴う操作はすべて、オブジェクトを IA/AIA から FA 階層に移動させます。なお、128 KB 未満のファイルは高頻度アクセス階層に留まりますが、コンパクションでより大きなファイルに統合されると階層移動の対象になります。 S3 Tables の Intelligent-Tiering とメンテナンスタスクの連携 スナップショット管理やファイルクリーンアップなどのテーブルメンテナンス操作は、すべての階層で引き続き実行されます。コンパクションについては、S3 Tables は独自のアプローチをとります。コンパクションタスクの開始時に、コンパクションの種類 (Binpack、Sort、Z-order) に関係なく、S3 Tables はコンパクション候補のデータファイルの階層を確認します。この確認自体は階層の変更に影響しません。S3 Tables は FA 階層にあるファイルのみにコンパクションを実行し、30 日以上アクセスしていないデータやファイルが昇格されないようにします。FA 階層のファイルのみを対象とすることで、頻繁にアクセスされるデータのパフォーマンスを最適化しつつ、コールドデータのメンテナンスコストを削減できます。低い階層のデータファイルがアクセスされると FA 階層に戻り、コンパクションの対象になります。 コンパクションは高頻度アクセス階層のファイルのみを処理するため、低コスト階層のデータに対する削除操作では、自動的にコンパクションされない delete ファイルが生成されます。関連するデータファイルがアクセスされて高頻度アクセス階層に戻ると、delete ファイルもコンパクションの対象になります。この動作の詳細は ドキュメント をご覧ください。 以下に、この動作を示す 2 つの例を紹介します。 Binpack コンパクションの例 シンプルな Binpack コンパクションのプロセスを見てみましょう。あるお客様が、当初有効にしていなかったコンパクションを有効にすることにしました。パーティション内の一部のデータファイルは頻繁にアクセスされていましたが、一部はアクセスされておらず、30 日後に自動的に IA 階層に遷移しています。 S3 Tables のコンパクションエンジンが起動すると、コンパクション候補のデータファイルの階層を検証します。FA 階層にあるデータファイルのみにコンパクションを実行し、アクセスされていないファイルはそのまま残します。IA や AIA 階層のファイルを確認しても、階層ステータスには影響しません。結果として、頻繁にアクセスされたデータはより効率的なファイルになり、アクセスされていないファイルのコスト削減は維持されます。2 週間後、残りの 2 つのファイルのデータにクエリがアクセスし、FA 階層に戻りました。 すべてのファイルが FA 階層にある状態で、次のコンパクションエンジンのイテレーションでは、S3 Tables のコンパクションエンジンが追加のコンパクションを実行し、2 つの小さなファイルを大きなファイルにマージします。 Delete ファイルの例 Apache Iceberg の equality delete、positional delete、 deletion vector (v3) などの delete ファイルタイプは、個別の delete 参照ファイルを生成します。これらのファイルは merge-on-read で使用されるか、メンテナンス操作中にデータファイルにマージされます。ここでは equality delete を使って、コンパクションエンジンと S3 Tables Intelligent-Tiering の連携を説明し、delete ファイル管理とデータファイルのストレージ階層のライフサイクルを示します。 Apache Iceberg の equality delete は、位置ベースのメタデータを必要とせずに特定のフィルター条件に一致するレコードを削除できるデータ変更操作で、大規模データセットでの効率的かつ正確なデータ削除を可能にします。テーブル更新の merge-on-read 方式です。 上の図の例では、クエリ時に Iceberg が delete ファイルの述語をデータファイルに動的に適用します。id=2、name=Brad の行はストレージに残りますが、クエリからは見えなくなります。Iceberg は元のデータファイルを変更せずに、読み取り操作中に削除情報を「マージ」します。この 2 つのファイルに対してコンパクションが実行されると、以下の処理が行われます。 データファイルと delete ファイルの両方を読み取る id=2、name=Brad に一致する行をデータから物理的に削除する 削除された行を含まない新しい統合データファイルを作成する 条件が適用済みのため、個別の delete ファイルを除去する テーブルデータへのアクセスを最適化し、読み取り操作中の処理負荷を削減するために一般的に有効な操作ですが、データファイルが IA や AIA 階層にある場合、S3 Tables はコンパクションを実行しません。ただし、ファイルが再度読み取られて高頻度アクセス階層に戻ると、コンパクションが新しいサイクルを開始する際にデータファイルの階層を評価し、FA 階層にあることを確認してメンテナンスタスクを実行します。不要な行を削除し、読み取りに最適化されたファイルを作成します。 S3 Tables でコンパクションを手動実行して delete ファイルの統合やレコードの完全削除を行うことも可能ですが、外部コンパクションジョブは Intelligent-Tiering ストレージクラスの認識とは独立して動作します。S3 Tables は外部コンパクションジョブの実行タイミングを予測できないため、Intelligent-Tiering の最適化はテーブルの自然なアクセスパターンのみに基づきます。手動コンパクションを実行すると、IA や AIA 階層に遷移したファイルを含むデータファイルが統合のために読み取られ、FA 階層に戻ります。その結果、ストレージコストが増加する可能性があります。 まとめ データ駆動型の環境において、効果的なテーブルメンテナンスは大規模データレイクを管理する組織にとって不可欠です。 S3 Tables は、スナップショット管理、コンパクション戦略、Intelligent-Tiering を統合したデータライフサイクル管理ソリューションを提供します。スナップショットで重要な履歴データを保持し、アクセスパターンを考慮したコンパクションでファイルレイアウトを最適化し、コールドデータをコスト効率の高いストレージ階層に自動的に移動します。 スナップショット管理、コンパクション、Intelligent-Tiering の連携により、日常的にアクセスされるデータも長期保存されるデータも、ライフサイクル全体を通じてパフォーマンスとコスト効率の両方が維持されます。組織は複雑なメンテナンスワークフローからデータからの価値ある洞察の抽出へと注力を移すことができ、安定したパフォーマンス、最適化されたストレージコスト、ビジネスニーズの変化に対応するスケーラブルなデータレイクの恩恵を受けられます。本ブログをお読みいただきありがとうございます。ご質問やコメントがありましたら、コメントセクションにお気軽にお寄せください。 著者について Ran Pergamin ストレージ担当のシニアスペシャリストソリューションアーキテクトです。大規模なストレージの課題解決に取り組んでいます。最近はコンテナ、オープンテーブルフォーマット、データレイク、ベクトルに注力しています。プライベートでは CrossFit を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。

このブログ記事は、AWS ソリューションアーキテクトの都築 了太郎と AWS テクニカルカスタマーソリューションマネージャ井元 祐希が執筆し、住信 SBI ネット銀行様が監修しています。 住信 SBI ネット銀行株式会社 （以下、住信 SBI ネット銀行）は、 Amazon Bedrock AgentCore を中核とした AI エージェントの機能を活用し、AI 銀行サービス「NEOBANK ai」のベータ版を公表いたしました。 「NEOBANK ai」は、アマゾン ウェブ サービス (以下、AWS) の生成 AIサービスを活用した革新的な銀行サービスで、「 d NEOBANK 住信 SBI ネット銀行アプリ 」内において、自然言語による対話を通じた銀行手続きを可能にします。本ブログでは、住信 SBI ネット銀行の「NEOBANK ai」による新たな顧客体験向上への挑戦とAWS の先進技術について、活用方法の解説を交えてご紹介します。 新たな顧客体験の創出に向けた挑戦と、求められるシステム要件 住信 SBI ネット銀行が「NEOBANK ai」の開発に着手した背景には、生成 AI の技術革新によってデジタル金融における新しい UI/UX の可能性が広がり始めていることがあります。“画面遷移を辿りながら操作する”従来の体験から、ユーザーが“やりたいこと（意図）を伝えるだけで必要な手続きが立ち上がる”体験へと移行していくことを、住信 SBI ネット銀行は将来のパラダイムシフトとして予見していました。 その未来像を先取りする形で、金融サービスにおける次世代インターフェースの実現を目指した意欲的な取組が「NEOBANK ai」です。日常的に利用される振込、明細確認、各種手続きといった領域においては、メニュー階層をたどる従来型 UI だけでは、ユーザーの意図に沿ったスムーズな体験を提供しにくい場面があります。住信 SBI ネット銀行では、こうした課題に対して、ユーザーの意図に応じて必要な確認項目や安全な手順を動的に提示できるアプローチが、より直感的な体験につながると考えました。 その実現を支える UI 概念のひとつとして、住信 SBI ネット銀行は主体的に「ジェネレーティブ UI」を採用しています。 「NEOBANK ai」では、アプリ内でのテキスト入力に加え、音声・画像を含むマルチモーダルなインプットを受け取り、AI エージェントが意図を解釈したうえで、照会・分析・手続き案内に必要な“その場で立ち上がる UI”を生成します。これにより、ユーザーは直感的かつ効率的に銀行サービスを利用できる体験の実現を目指しました。 本 AI エージェント技術活用に向けた主要なシステム要件として、以下4点ありました。 1. スケーラブルな AI エージェント実行基盤 数百万ユーザーを抱える大規模アプリケーションにおいて、スケーラブルかつ安定した AI エージェント実行基盤の構築が求められていました。ピーク時には多数のユーザーが同時に AI エージェントとやり取りすることが想定されるため、自動スケーリング機能を備え、負荷変動に柔軟に対応可能な基盤が不可欠でした。 2. 実行モデルを切り替えられる柔軟性 日々新たな AI モデルが登場する中で、タスクごとに品質・コスト・パフォーマンスを最適化していく必要があると考えました。そのため、特定のモデルに依存するのではなく、要件に応じて実行対象のモデルを柔軟に切り替え可能なアーキテクチャが求められていました。 3. AI エージェントの可視性 開発環境での検証および本番環境での運用において、AI エージェントの実行プロセスがブラックボックス化することを防ぎ、説明可能性を確保することを重要視していました。AI エージェントが顧客からの自然言語入力をどのように解釈し、どのようなプロセスを経て応答を生成したのかを把握できるよう、実行プロセスの可視性を高める必要がありました。 4. AI セキュリティ対策 社外向けの大規模サービスとして安心・安全な AI 活用を実現するため、AI サービス特有の攻撃的なプロンプトや、銀行取引と関連性のないトピックを検知・制御する仕組みが必要とされていました。これにより、不適切な利用を防止し、セキュリティと信頼性を確保する必要がありました。 AI エージェントシステムのアーキテクチャ 住信 SBI ネット銀行が構築した「NEOBANK ai」では、前述の 4 つのシステム要件を満たすため、AWS の生成 AI をはじめとする複数のサービスを組み合わせたアーキテクチャを採用しています。本セクションでは、各要件に対応するアーキテクチャ上のポイントと、採用した AWS サービスの役割をご紹介します。 1. スケーラブルな AI エージェント実行基盤 住信 SBI ネット銀行が構築した「NEOBANK ai」において、AI エージェント実行基盤の要件を実現するため、AI エージェント機能をスケーラブルに実行可能なマネージドサービスである Amazon Bedrock AgentCore Runtime が採用されています。フロントエンドからのリクエストは、 Amazon API Gateway を経由してセキュアに受け付けられます。API Gateway の後段では、AWS Lambda がリクエストの認証・前処理および Amazon Bedrock AgentCore Runtime へのルーティングを担います。Amazon Bedrock AgentCore Runtime は負荷に応じた自動スケーリングを備えており、ピーク時に多数のユーザーが同時に AI エージェントとやり取りする場合でも、安定した応答を維持できます。この構成により、利用状況に応じた柔軟なスケーリングと高いコスト効率を両立しています。 2. 実行モデルを切り替えられる柔軟性 Amazon Bedrock AgentCore の活用により、さまざまな基盤モデルへのアクセスが可能となり、必要に応じて外部モデルを統合できる柔軟性を確保しました。この設計により、将来的なモデルの技術進歩や、実行タスク・コスト・性能といったビジネス要件の変化にも対応でき、実行モデルを柔軟に切り替え可能なアーキテクチャを実現しています。「NEOBANK ai」では、このモデル切り替えの柔軟性を活かし、処理の特性に応じて以下異なる AI モデルを使い分けています。 ž意図理解・行動決定処理：お客さまの発話から意図を理解し、振込用 UI を描画するといった行動を決定する処理では、チャットボットとしての素早い応答速度を重視し、軽量・高速な推論に適した AI モデルを使用しています。 žガードレール判定処理：不適切な応答を防止するためのガードレール機能では、判定精度を優先し、高精度な分類・判定に強みを持つ AI モデルを採用しています。 このように、モデルの推論性能と生成速度のバランスを用途ごとに最適化することで、素早い応答速度と高い回答品質の両立を実現しています。 3. AI エージェントの可視性 また、AI エージェントの可視性要件を満たすために Amazon Bedrock AgentCore Observability を採用しています。これにより、AI エージェントがお客さまからの自然言語入力をどのように解釈し、どのようなプロセスを経て応答を生成したのかについて、エンドツーエンドの包括的な可視性を確保しています。具体的には、開発環境における検証・デバッグだけでなく、本番環境における品質監査や性能傾向の評価にも活用されており、AI エージェントの実行プロセスがブラックボックス化することを防いでいます。 4. AI セキュリティ対策 社外向けの大規模サービスとして安心・安全な AI 活用を実現するため、複数のレイヤーでセキュリティ対策を講じています。 まず、AI 固有の攻撃に対する対策として、プロンプトインジェクションや銀行取引と関連性のないトピックを検知・制御するガードレールを実装しています。前述のとおり、このガードレール判定には高精度な分類・判定に強みを持つ AI モデルを採用し、検知精度を高めています。 加えて、API Gateway を通過したリクエストに対し、Amazon DynamoDB を用いてクライアントごとのレートリミットを設定・制御することで、過剰なリクエストによるサービスへの影響を防止しています。また、お客さまから入力される自然言語情報の保存にも DynamoDB を活用し、監査証跡の確保に役立てています。 住信 SBI ネット銀行株式会社 執行役員渡邊 弘様からのコメント 「当社は、顧客体験の革新を最重要課題として位置づけ、生成 AI 技術を活用したお客さま向けサービスの高度化に継続的に取り組んでまいりました。その取組の一環として、このたび Amazon Bedrock AgentCore を採用し、NEOBANK ai を通じて、より質の高いサービスをお客さまに提供してまいります。特に、従来のルールベースの仕組みに代えて AI エージェントを活用することで、お客さまとの対話がより自然で、付加価値の高いものになることを期待しています。 セキュリティや可用性といった金融機関として不可欠な要件を満たしながら、同時にイノベーションを実現できる AWS のプラットフォームは、当社のデジタルトランスフォーメーションを推進するうえで欠かせないパートナーです。 今回のシステム構築を通じて得られた知見やノウハウは、今後のさまざまなサービス開発にも積極的に活かしていく所存です。今後も、AWS の豊富なマネージドサービス群と進化を続ける生成 AI 技術を活用し、お客さまに真に価値あるデジタル金融サービスを迅速に提供し続けることで、金融サービスのイノベーションをリードしてまいります。」

本記事は 2025 年 5 月 19 日に公開された How Amazon maintains accurate totals at scale with Amazon DynamoDB を翻訳したものです。翻訳は Solutions Architect の嶋田 朱里が担当しました。 Amazon の Finance Technologies Tax チーム (FinTech Tax) は、世界中の法域で税額計算、税額控除、納付、報告といった重要なサービスを管理しています。このアプリケーションは、複数の国際マーケットプレイスで年間数十億件の取引を処理しています。 この投稿では FinTech Tax チームが Amazon DynamoDB のトランザクションと条件付き書き込みを使用して、段階的な源泉徴収を実装した方法を紹介します。 これらの DynamoDB の機能を使用することで、拡張性と回復力があるイベント駆動の税額計算サービスを構築し、大規模でもミリ秒レベルのレイテンシーを実現しました。 また、一貫したパフォーマンスを実現しながら、データの正確性を厳密に維持するための設計上の決定と実装の詳細についても探ります。 要件 Amazon は複数の法域にまたがる複雑なフィンテック (金融技術) 分野の税制環境で事業を行っており、さまざまな源泉徴収税の要件を管理する必要があります。同社には、膨大な取引量を処理できる堅牢な税処理ソリューションが必要です。このシステムは、毎日数百万件の取引をリアルタイムで処理し、個人ごとの累積取引額の正確な記録を源泉徴収税計算のために維持する必要があります。主な要件には、段階的な源泉徴収税率を正確に適用すること、および Amazon の既存システムとのシームレスな統合が含まれます。このソリューションはデータの整合性と高可用性を維持し、さまざまな源泉徴収税制度に対する規制遵守をサポートする必要があります。 課題 主な課題は世界中の複雑に絡み合った税法に厳密に準拠することにあります。特に、段階的課税モデルでは、個人の総取引額が財務年度内の特定の閾値を超えるかどうかに基づいて、異なる源泉徴収税率が適用されます。個人の累積取引額が増加し、あらかじめ定義された閾値を超えると、その取引に適用される源泉徴収税率が変更されます。例えば、総額が 100,000 インドルピー (INR) に達するまでは低い税率が適用され、その閾値を超えると、より高い税率が適用されます。 次の図は、累積取引金額の閾値に基づいて税率が段階的に変化する様子を示した、3 段階の税率モデルを示しています。 段階的課税モデルの課題は、源泉徴収についてリアルタイムの計算を行いながら、各個人の累計取引額を正確に追跡・記録管理することにあります。 Amazon は 1 日に数百万件のトランザクションを処理しなければなりません。 さらに、正の取引・負の取引（例：プラスまたはマイナスの会計調整）に関わらず、正しい源泉徴収税率をリアルタイムで適用することが求められます。 これには高い取引量 (個人あたり約 150 トランザクション/秒) を処理しながら、正確な記録を維持できるシステムが必要です。 ソリューションの概要 次の図は Amazon の源泉徴収税計算サービスの全体アーキテクチャです。 ワークフローは以下のステップで構成されています: クライアントが Amazon API Gateway に源泉徴収税計算リクエストを送信します。 API Gateway が税額計算 (Tax Computation) AWS Lambda を呼び出します。 税額計算 Lambda 関数が、DynamoDB の個人の累積トランザクションストア（Cumulative Transaction Store）テーブルを取得します。累積トランザクションストアテーブルは過去の累計値をもとに、ユーザーごとの累積取引金額をリアルタイムで管理します。これにより、段階的な税率を適用するための個人の累積取引金額の合計を正確に追跡できます。 Lambda 関数は取引の詳細と個人の累計金額に基づいて、ルールエンジンライブラリから適用される税率を取得します。取得した税率と取引データをもとに、税額が計算されます。 計算結果は取引データの監査と履歴管理のために DynamoDB の取引監査ストア (Transaction Audit Store) に格納されます。 現在の取引金額をもとに、個人の累積取引金額が累積トランザクションストアに更新されます。 DynamoDB 操作中に発生する一時的なエラー (例: ConditionalCheckFailed 、 TransactionConflict ) は、 Amazon Simple Queue Service (Amazon SQS) キューに送られ、再試行されます。 クライアントエラー (400 Validation Exception、401 Unauthorized、403 Forbidden など) や永続的なサーバー障害によるエラーは、SQS DLQ で処理されます。 実装上の考慮事項 トランザクションを受信すると、システムはルールエンジンから導出された閾値に対して個人の累積取引額を評価して、適用される税率を判断します。その後、累積取引金額は累積トランザクションストアに更新され、監査証跡も記録されます。 複数のスレッドが同一個人のデータベースを同時に更新しようとすると、競合が発生します。一般的な 楽観的排他制御 (OCC) の手法は、累積値を読み取り、指定範囲の値に対する税率を計算し、累積値が読み取り以降変更されていないという条件付きでトランザクションを書き込みます。もし値が変更されていた場合はループの最初から処理をやり直します。 トラフィックが多い場合、この再実行が頻繁に発生する可能性があります。 私たちのアプローチは、一般的な OCC パターンを改良したものです。条件の判定を「累積値が最初に読み取った時点の範囲内に留まっているか」のみに絞っています。 累積値が変化しても、その値が閾値を超えない限り、ループを再実行する必要はありません。 この方法により、条件の不一致が少なくなるため、スループットが上がります。個人の累積値がより高い範囲に移行した場合は、書き込み操作が失敗します。 その場合は、更新された値をもとに、読み取りと書き込みを再試行する必要があります。 OCC 戦略とは異なり、このアプローチでは最後の読み取り以降に値が変化していても処理が成功します。これにより、競合を最小限に抑え、スループットを向上させることができます。同時更新（累積合計が閾値を超えるケース）によって条件付き書き込みが失敗し、 ConditionalCheckFailedException が発生することがありますが、これは想定された動作であり、データの不整合を示すものではありません。 一時的なエラーを処理し、同じトランザクションの重複処理を防ぐために、クライアント要求トークン (Client Request Token, CRT) を含んだ TransactWriteItems 操作を実行することで、インクリメント操作を冪等性のある状態で行えます。 TransactionCanceledException は、 エクスポネンシャルバックオフ などのエラー処理メカニズムで処理されます。 この戦略の組み合わせにより、システムはデータの整合性を維持しながら、高いスループットとスケーラビリティを実現できます。 複雑なロック機構が不要になり、従来のOCCソリューションと比べて効率性が向上します。また、大規模な設定やチューニングを必要とせず、さまざまなトランザクション量や同時実行レベルに柔軟に対応できる、高性能なソリューションを提供します。 累積トランザクションストア 累積トランザクションストアテーブルは、特定の個人の取引金額の累積和を維持するために使用されます。以下のデータモデルを使用します: { "indvidual_id": { "S": "TIN1" // 累積合計を管理する単位となる一意識別子 }, "cumulative_amount_consumed": { // 使用された金額の累積合計を表す "N": "0" } } 税控除対象品目の在庫管理 税額控除監査ストア（Tax Deduction Audit Store）テーブルは、各取引の税控除率の監査記録を保存するために使用されます。以下のデータモデルを使用します: { "transaction_primary_key": { "S": "XXX111#2024-01-01T13:05:28" // トランザクションの一意識別子(PartitionKey#SortKey) }, "transaction_amount": { "S": "1000". //トランザクション全体の金額 }, "transaction_tax_amount": { "S": "100". //控除される税額 }, "transaction_tax_rate":{ "S":"10". //このトランザクションに適用される税率(パーセント表記) } ... } 条件付き書き込みのコード 次のコードは dynamodb.transact_write_items() を使用して、累積トランザクションストアと取引監査ストアの 2 つの DynamoDB テーブルにまたがるアトミックな条件付き書き込み操作を示しています。累積トランザクションストアから既存のレコードを取得し、現在の取引金額と既存データに基づいて cumulative_amt_consumed  （累積消費金額）の更新値を計算します。同時に、取引監査ストアに新しいレコードを記録し、ID、値、税額、税率などのトランザクション詳細を記録します。 transact_write_items() メソッドは、取引トランザクションストアテーブルへの更新操作と取引監査ストアテーブルへの put 操作を 1 つのトランザクションとして実行します。 2 つの操作がともに成功すれば、両方のテーブルに変更がコミットされます。そうでない場合は、トランザクション全体がロールバックされ、データの整合性が保たれます。 SAMPLE_TIN = 'TIN1' # 累積トランザクションストアにおける一意の識別子を表す SAMPLE_AMOUNT = 5000 # transact_write_items で処理される売上値を表す SAMPLE_TRANSACTION_ID = 'XXX111' DEFAULT_TAX_RATE = 10 # 既定の税率(パーセンテージ値) LOWER_TAX_RATE = 5 # 低い方の税率(パーセンテージ値) RETRYABLE_ERRORS = ( 'TransactionConflictException', 'ConditionalCheckFailedException', 'ProvisionedThroughputExceededException', 'ThrottlingException', 'ServiceUnavailableException', 'InternalServerErrorException' ) MAX_RETRIES = 3 RETRY_DELAY = 0.1 # 秒 def send_to_error_queue(error_message, is_retryable, transaction_id): queue_url = 'TransientErrorQueue' if is_retryable else 'NonTransientErrorQueue' message_body = { 'error_message': error_message, 'transaction_id': transaction_id } try: sqs.send_message( QueueUrl=queue_url, MessageBody=json.dumps(message_body) ) except Exception as e: print(f"Failed to send message to {queue_url}: {str(e)}") def process_transaction(tin, amount, transaction_id): for attempt in range(MAX_RETRIES + 1): try: response = dynamodb.get_item(TableName='CumulativeTransactionStore', Key={'cumulativeStore_primary_key': {'S': tin}}) item = response.get('Item') if not item: print("Record not found.") return cumulative_amount_consumed = int(item.get('cumulative_amount_consumed', {}).get('N', '0')) threshold_value = int(item.get('threshold_value', {}).get('N', '0')) current_amount = amount if (cumulative_amount_consumed + current_amount < threshold_value): update_expression = 'SET cumulative_amount_consumed = cumulative_amount_consumed + :val, tax_rate = :tax_rate' tax_rate = DEFAULT_TAX_RATE max_value = threshold_value min_value = 0 else: update_expression = 'SET cumulative_amount_consumed = cumulative_amount_consumed + :val, tax_rate = :tax_rate' tax_rate = LOWER_TAX_RATE max_value = sys.maxsize min_value = threshold_value expression_attribute_values = { ':val': {'N': str(current_amount)}, ':tax_rate': {'N': str(tax_rate)}, ':lo': {'N': str(min_value)}, ':hi': {'N': str(max_value)} } dynamodb.transact_write_items( TransactItems=[ { 'Update': { 'TableName': 'CumulativeTransactionStore', 'Key': {'cumulativeStore_primary_key': {'S': tin}}, 'UpdateExpression': update_expression, 'ConditionExpression': 'cumulative_amount_consumed < :hi AND cumulative_amount_consumed >= :lo', 'ExpressionAttributeValues': expression_attribute_values, } }, { 'Put': { 'TableName': 'TaxDeductionAuditStore', 'Item': { 'transactionID': {'S': transaction_id}, 'transaction_amount': {'N': str(amount)}, 'transaction_tax_amount': {'N': str(amount * tax_rate / 100)} } } } ], ClientRequestToken=transaction_id ) print(f"Transaction processed successfully on attempt {attempt + 1}") return # Success, exit the function except Exception as e: error_code = e.response['Error']['Code'] error_message = f"Error accessing DynamoDB: {error_code} - {e.response['Error']['Message']}" is_retryable = error_code in RETRYABLE_ERRORS if is_retryable and attempt < MAX_RETRIES: print(f"Retryable error occurred on attempt {attempt + 1}. Retrying...") time.sleep(RETRY_DELAY * (2 ** attempt)) # Exponential backoff else: send_to_error_queue(error_message, is_retryable, transaction_id) # If we've exhausted all retries error_message = f"Max retries ({MAX_RETRIES}) exceeded. Last error: {error_message}" send_to_error_queue(error_message, True, transaction_id) # Main execution try: process_transaction(SAMPLE_TIN, SAMPLE_AMOUNT, SAMPLE_TRANSACTION_ID) except Exception as e: print(f"Transaction processing failed: {str(e)}") 結果 システムのパフォーマンス評価では、実行時間を 30 秒に固定し、スレッド数を変えながら一連のテストを実施しました。 各実行後に累積トランザクションストアをゼロにリセットすることで、さまざまな負荷条件下でのシステムの動作を包括的に分析しました。 1 スレッドから 130 スレッドにスケールアップするにつれて、処理されたトランザクション数が一貫して増加したことから、システムが大規模な並列処理の場面においても高い並行性を効果的に処理できることが示されました。 しかし、この処理能力の向上には一時的な競合の増加が伴いました。これは、大規模な並列処理の場面において、パフォーマンスと競合管理のトレードオフを浮き彫りにしています。 一時的なアクセスの競合は、複数のトランザクションが同時に同じアイテムを更新しようとしたときに発生し、一部のトランザクションがキャンセルされることになります。このデータが示すのは、スレッド数を増やしても競合管理のオーバーヘッドが増大するため、スループットが大幅には向上しなくなるということです。 次のグラフはスレッド数とトランザクションメトリクスの相関関係を示しています。 これにより、スループットと競合率が同時実行スレッドの増加に伴ってどのように変化するかがわかります。 結論 この投稿では、Amazon Fintech チームが DynamoDB の強力な条件付き書き込み機能を使用することで、段階的税率アプリケーション向けのシンプルかつ高いスケーラビリティを持つソリューションを実装した方法を紹介しました。 この手法を採用し、まれに発生する ConditionalCheckFailedException を先に見越して処理することで、大量の同時トランザクションが発生するシナリオにおいても、高いスループットとスケーラビリティを実現しながら、データの一貫性を維持することができます。 この手法は、同時リクエスト数が増加するにつれボトルネックになりがちな楽観的ロックの必要性をスマートに排除しています。代わりに、Amazon Fintech システムは DynamoDB の組み込みの同時アクセス制御メカニズムを活用し、高負荷状況でも一貫したデータと効率的な更新を可能にしています。 拡張性のあるトランザクション処理システムを独自に実装するには、DynamoDB の 条件付き更新 機能を確認してください。詳しいガイダンスが必要な場合は、DynamoDB の ドキュメント を参照するか、AWS サポートにお問い合わせください。 著者について Jason Hunter はカリフォルニア在住の Amazon DynamoDB 専任のプリンシパルソリューションアーキテクトです。2003 年から NoSQL データベースに携わっています。Java、オープンソース、XML への貢献で知られています。 DynamoDB の投稿 や Jason Hunter が書いた他の投稿は、 AWS Database Blog で見つけることができます。 Balajikumar Gopalakrishnan は、Amazon Finance Technology の Principal Engineer です。 2013 年から Amazon に在籍し、Amazon の顧客の生活に直接影響を与える技術を通じて、実世界の課題を解決してきました。 仕事以外では、ハイキング、絵画、家族と過ごすことを楽しんでいます。また、映画好きでもあります。 Jay Joshi は、Amazon Finance Technology のソフトウェア開発エンジニアです。 2020 年から Amazon に在籍し、主に世界各地の法域での税額計算とレポーティングのためのプラットフォームの構築に従事しています。 仕事以外では、家族や友人と過ごしたり、新しい料理の行き先を探索したり、バドミントンをするのが好きです。 Arjun Choudhary は 2019 年からAmazon の Finance Technology 部門でソフトウェア開発エンジニアとして働いています。主な業務は、グローバルな法人税の源泉徴収プラットフォームの開発です。仕事以外では、小説を読んだり、クリケットやバレーボールをしたりして楽しんでいます。

本ブログは 2024 年 10 月 17 日に公開された AWS Blog “ An unexpected discovery: Automated reasoning often makes systems more efficient and easier to maintain ” を翻訳したものです。 先日、 米国防高等研究計画局 (DARPA) を訪問した際にある傾向について話したところ、強い関心を持たれました。 Amazon Web Services (AWS) で過去 10 年にわたって自動推論を適用する中で、形式的検証されたコードは、置き換え前の未検証のコードよりもパフォーマンスが優れていることが多いことを確認しています。 これは、形式的検証の過程で行うバグ修正が、実行時パフォーマンスにもプラスの影響を与えることが多いためです。また、自動推論によってビルダーは自信を持ってさらなる最適化に取り組めるようになり、システムパフォーマンスがいっそう向上します。形式的検証されたコードは更新や変更、運用も容易であり、深夜のログ分析やデバッグの頻度も減ることがわかっています。この記事では、DARPA との議論で取り上げた 3 つの事例を紹介します。 自動推論: 基礎 AWS では、お客様にとってシンプルで直感的なサービスの構築に取り組んでいます。そのシンプルさの裏側には、毎秒数十億件のリクエストを処理する、広大で複雑な分散システムがあります。こうした複雑なシステムの正しさを検証することは大きな課題です。本番サービスは、新機能の追加、コンポーネントの再設計、セキュリティの強化、パフォーマンスの最適化に伴って常に進化し続けています。これらの変更の多くはそれ自体が複雑であり、AWS やお客様のセキュリティやレジリエンスに影響を与えることなく実施する必要があります。 設計レビュー、コード監査、ストレステスト、フォールトインジェクションは、いずれも日常的に使用しており、今後も使い続ける非常に重要なツールです。しかし、多くのケースで正しさの確認には、これらの手法だけでは不十分であることもわかっています。特に大規模でフォールトトレラントなアーキテクチャでは、巧妙なバグが検出をすり抜ける可能性があります。また、問題の中には実装上の欠陥ではなく、元のシステム設計自体に根本原因があるものもあります。サービスの規模と複雑さが増すにつれて、従来のテスト手法を数学とロジックに基づくより強力な手法で補完する必要が生じました。ここで人工知能 (AI) の一分野である 自動推論 が力を発揮します。 従来のテストが 特定の シナリオにおけるシステムの動作検証に重点を置くのに対し、自動推論は あらゆる シナリオにおけるシステムの動作をロジックで検証することを目指します。中程度の複雑さのシステムでさえ、発生しうるすべての状態とパラメータの組み合わせを再現するには、途方もない時間がかかります。自動推論を使えば、システムの正しさの論理的な証明を導出することで、同じ効果をすばやく効率的に達成できます。 自動推論を活用するには、ビルダーに異なるマインドセットが求められます。考えうるすべての入力シナリオとその問題点を洗い出そうとするのではなく、システムがどう動作 すべき かを定義し、正しく動作するために満たすべき条件を特定します。そして、数学的な証明を使ってその条件が真であることを検証します。つまり、このアプローチによってシステムの正しさを検証できるのです。 自動推論では、システムの仕様と実装を数学的に表現し、アルゴリズム的なアプローチで実装が仕様を満たすことを検証します。システムを数学的にエンコードし、形式的論理を用いて検証することで、システムの将来の動作に関する重要な問いに効率的かつ確実に答えることができます。システムは何ができるのか？何をするのか？何を絶対にしないのか？自動推論は、最も複雑で大規模な、さらには上限のないシステムについても、こうした問いに答えることができます。これは従来のテストだけでは網羅的に検証できないシナリオです。 自動推論によって完璧は達成できるのでしょうか？いいえ、できません。自動推論もまた、システムのコンポーネントが正しく動作することや、システムとその環境のモデルとの関係について、一定の仮定に依存しています。例えば、システムのモデルが、コンパイラやプロセッサなどの基盤コンポーネントにバグがないと誤って仮定している可能性があります (ただし、これらのコンポーネントも形式的検証することは可能です)。とはいえ、自動推論によって、従来のソフトウェア開発やテスト手法では得られない、より高い水準の正しさへの確信が得られるようになります。 開発の高速化 自動推論は、数学者や科学者だけのものではありません。 Amazon Simple Storage Service (Amazon S3) のエンジニアは、バグを防ぐために日々自動推論を活用しています。S3 のシンプルなインターフェイスの裏側には、400 兆個のオブジェクトとエクサバイト規模のデータを保持し、毎秒 1 億 5,000 万件を超えるリクエストを定常的に処理する、世界最大級かつ最も複雑な分散システムの 1 つがあります。S3 は多数のサブシステムで構成されており、それぞれが独立した分散システムであり、その多くは数万台のマシンで動作しています。お客様に大規模にご利用いただいている中でも、新機能は常に追加され続けています。 S3 の主要コンポーネントの 1 つが S3 インデックスサブシステムです。これは、高速なデータ検索を可能にするオブジェクトメタデータストアです。このコンポーネントには、非常に大規模で複雑なデータ構造と、精巧に最適化されたアルゴリズムが含まれています。S3 の規模ではアルゴリズムを人間が正確に実装するのは難しく、検索でエラーは許されません。変更を確信を持って行うには極めて慎重な対応と広範なテストが必要なため、新たな改善はおよそ四半期に 1 回のペースにとどまっていました。 S3 は 15 年にわたる経験の上に堅牢に構築され、十分にテストされたシステムです。しかし、S3 インデックスサブシステムには、長い間根本原因を特定できないバグが存在していました。システムはその例外から自動的に回復できたため、バグがシステムの動作に影響を与えることはありませんでした。それでも、この状態に満足してはいませんでした。 なぜこのバグは長期間残り続けたのでしょうか？S3 のような分散システムには多数のコンポーネントがあり、それぞれに固有のコーナーケースがあります。そして、複数のコーナーケースが同時に発生することもあります。300 を超えるマイクロサービスを持つ S3 では、これらのコーナーケースの組み合わせは膨大な数になります。バグが存在する証拠やその根本原因の推測があったとしても、開発者がコーナーケースを 1 つ 1 つ検討し尽くすことは不可能です。ましてや、コーナーケースのあらゆる組み合わせを検討することなど到底できません。 この複雑さがきっかけとなり、自動推論を使って潜在的な状態やそこに潜むエラーを探索する方法を検討しました。システムの形式的仕様を構築することで、バグを発見し、同種のバグがこれ以上存在しないことを証明できました。自動推論の活用により、年に 3～4 回だったアップデートと改善のリリースを、1～2 か月ごとに行えるようになりました。 コードの高速化 AWS Identity and Access Management (IAM) サービスの正しさは、お客様のワークロードのセキュリティの基盤です。数百万のお客様、数千のリソースタイプ、数百の AWS サービスにわたり、すべての API コール (つまり、AWS へのすべてのリクエスト) は IAM の認可エンジンによって処理されます。毎秒 12 億件を超えるリクエストです。これは AWS の中でも最もセキュリティ上重要で、最大規模にスケールされたソフトウェアの 1 つです。 AWS では、いかなる変更も本番環境に反映する前に、システムがセキュアかつ正しい状態を維持していることについて、極めて高い確信が求められます。自動推論を使うことで、あらゆる状況においてシステムが特定のセキュリティプロパティに準拠していることを証明できます。これを 証明可能なセキュリティ と呼んでいます。自動推論により、お客様に証明可能なセキュリティの保証を提供できるだけでなく、機能、セキュリティ、最適化を大規模に提供できるようになっています。 S3 と同様に、IAM も 15 年をかけて進化してきた、時間の試練を経た信頼性の高いシステムです。しかし、さらに水準を引き上げたいと考えました。既存の IAM 認可エンジンの動作を捉える形式的仕様を構築し、ポリシー評価の原則を証明可能な定理として定式化し、自動推論を使ってより効率的な新しい実装を構築しました。2024 年初めに、正しさが証明された新しい認可エンジンをデプロイしましたが、誰も気づきませんでした。自動推論により、AWS インフラストラクチャの中で最も重要なコンポーネントの 1 つである認可エンジンを、正しさが証明された同等の実装にシームレスに置き換えることができたのです。 仕様と証明が整ったことで、高い確信を持って安全かつ大胆にコードを最適化できるようになりました。IAM の膨大な規模では、わずか 1 マイクロ秒のパフォーマンス向上でさえ、お客様のエクスペリエンスの改善と AWS のコスト最適化に直結します。文字列マッチングの最適化、不要なメモリ割り当てや冗長な計算の削除、セキュリティの強化、スケーラビリティの向上を実現しました。変更のたびに証明を再実行し、システムが正しく動作し続けていることを確認しました。 最適化後の IAM 認可エンジンは、以前のバージョンと比較して 50% 高速になりました。自動推論がなければ、これほどインパクトのある最適化をこれほどの確信を持って実現することは到底できなかったでしょう。この取り組みの詳細については、こちらの AWS re:Inforce セッション をご覧ください。 デプロイの高速化 (とコードの高速化) オンラインで行われるトランザクションの大半は、暗号によって保護されています。例えば、RSA 暗号化アルゴリズムは 2 つの鍵を生成してデータを保護します。1 つはデータの暗号化用、もう 1 つは復号用です。これらの鍵により、安全なデータ伝送とデジタル署名が実現します。暗号においては、正しさとパフォーマンスの両方が不可欠です。暗号化アルゴリズムのバグは壊滅的な結果を招きかねません。 お客様がワークロードを AWS Graviton に移行するにつれて、 ARM 命令セット 向けに暗号を最適化するメリットは増しています。しかし、パフォーマンス向上のための暗号の最適化は複雑であり、変更した暗号化アルゴリズムが正しく動作しているかの検証は困難です。自動推論を導入する以前は、暗号ライブラリの最適化を本番環境にリリースするまでに、数か月にわたるレビューが必要になることも珍しくありませんでした。 ここで自動推論が威力を発揮しました。 Graviton で RSA を高速化し、形式的検証で正当性を証明し開発も加速しました 。 楕円曲線暗号に自動推論を適用 した場合にも、同様の成果が得られています。 好循環の形成 過去 10 年にわたり、AWS ではクラウドインフラストラクチャとサービスの正しさを証明するために、自動推論技術の適用を拡大してきました。正しさの検証だけでなく、セキュリティと信頼性の向上、設計上の欠陥の最小化にも、日常的にこれらの手法を活用しています。自動推論を使うことで、システムの精密でテスト可能なモデルを作成し、変更が安全であることをすばやく検証できます。また、本番環境に影響を与えることなく、変更が安全でないことを事前に把握することもできます。 インフラストラクチャに関する重要な問いに答え、データを露出させる可能性のある設定不備を検出できます。他の手法では発見できなかったであろう、目立たないが深刻なバグが本番環境に到達するのを防ぐことができます。モデル検査なしでは到底挑戦できなかったような、大胆なパフォーマンス最適化を実現できます。自動推論は、重要なシステムが期待どおりに動作することについて、厳密な数学的保証を提供します。 AWS は、この規模で自動推論を活用する 初めてかつ唯一のクラウドプロバイダー です。自動推論ツールの導入が広がるにつれ、ユーザビリティとスケーラビリティの向上に対するより大きな投資が正当化しやすくなります。ツールが使いやすく、強力になるほど、導入はさらに進みます。クラウドインフラストラクチャの正しさをより多く証明できるほど、セキュリティを最重視するお客様にとってクラウドの魅力は高まります。そして、この記事の事例が示すように、セキュリティの保証を高めるだけでなく、よりパフォーマンスの高いコードをお客様に迅速に提供し、最終的にはお客様に還元できるコスト削減も実現しています。 セキュリティ、コンプライアンス、可用性、耐久性、安全性といった重要な特性を、大規模なクラウドアーキテクチャに対して自動的に証明できる時代が始まりつつあると考えています。AI ハルシネーションの潜在的な問題の防止から、ハイパーバイザー、暗号、分散システムの分析に至るまで、確かな数学的推論を基盤に据え、構築するものを継続的に分析し続けていることが、Amazon ならではの強みです。 関連情報 Amazon Science ブログ で自動推論の詳細をご覧ください AWS が自動推論により 証明可能なセキュリティ を提供する方法をご覧ください AWS Automated Reasoning Group でのインターンシップにご興味がある方は、 お問い合わせください   この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。   Byron Cook Byron はユニバーシティカレッジロンドン (UCL) のコンピュータサイエンスの教授であり、英国王立工学アカデミーのフェローです。2015 年に Amazon Automated Reasoning Group を設立し、現在は AWS で Vice President 兼 Distinguished Scientist of Automated Reasoning を務めています。関心分野は、コンピュータおよびネットワークセキュリティ、プログラム解析と検証、プログラミング言語、定理証明、論理学、ハードウェア設計、オペレーティングシステム、生物学的システムです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 9 月 10 日に公開された Amazon Science Blog “ Better-performing “25519” elliptic-curve cryptography ” を翻訳したものです。 自動推論と CPU マイクロアーキテクチャ固有の最適化により、パフォーマンスと実装の正当性の保証がともに向上します。 暗号アルゴリズムはオンラインセキュリティに不可欠です。Amazon Web Services (AWS) では、Google の BoringSSL プロジェクトのコードをベースにしたオープンソースの暗号ライブラリ AWS LibCrypto (AWS-LC) に暗号アルゴリズムを実装しています。AWS-LC は、セキュリティと AWS ハードウェアへの最適化を両立した暗号アルゴリズムの実装をお客様に提供しています。 近年利用が広がっている暗号アルゴリズムに x25519 と Ed25519 があります。どちらも Curve25519 として知られる 楕円曲線 に基づいています。これらのアルゴリズムの実装をさらに改善するため、AWS では最近 AWS-LC における実装の見直しに取り組みました。本記事では以降、x25519 および Ed25519 をまとめて x/Ed25519 と表記します。 2023 年、AWS は AWS-LC における x/Ed25519 のアセンブリレベルの実装を複数リリースしました。 自動推論 と最先端の最適化技術を組み合わせることで、従来の AWS-LC 実装と比べてパフォーマンスが向上し、正当性の保証も強化されています。 具体的には、自動推論を用いて機能的正当性を証明するとともに、命令セットアーキテクチャ (ISA) の x86_64 および Arm64 において、特定の CPU マイクロアーキテクチャをターゲットとした最適化を行っています。また、実行時間の差異から秘密情報を推測するサイドチャネル攻撃を防ぐため、アルゴリズムの 定数時間 実行にも細心の注意を払っています。 本記事では、自動推論による正当性の証明プロセス、マイクロアーキテクチャ ( μ arch) の最適化技術、定数時間コードに関する考慮事項、パフォーマンス向上の定量的な評価など、この取り組みのさまざまな側面を紹介します。 楕円曲線暗号 楕円曲線の例 楕円曲線暗号は、公開鍵と秘密鍵のペアを使用する公開鍵暗号の一手法です。最もよく知られた公開鍵暗号方式の 1 つが RSA で、その公開鍵は非常に大きな整数であり、対応する秘密鍵はその整数の素因数です。RSA はデータの暗号化/復号とデータの署名/検証の両方に使用できます。(2024 年 9 月に、AWS チームのメンバーが Amazon Science ブログにて、自動推論を活用した Amazon Graviton2 チップ上の RSA 実装の 高速化とデプロイの容易化 について紹介しています。) 楕円曲線は、公開鍵と秘密鍵を数学的に関連付ける別の手法です。この手法により、暗号方式をより効率的に実装できる場合があります。楕円曲線の数学理論は広範かつ奥深いものですが、暗号で使用される楕円曲線は通常、 y 2 = x 3 + ax 2 + bx + c ( a、b、 c は定数) の形の方程式で定義されます。この方程式を満たす点は 2 次元グラフ上にプロットできます。 楕円曲線には、2 点で曲線と交わる直線は他に高々もう 1 点でしか曲線と交わらないという性質があります。この性質を利用して曲線上の演算を定義します。例えば、曲線上の 2 点の加算は、最初の 2 点を通る直線が曲線と交わる第 3 の点そのものではなく、その第 3 の点を対称軸に関して反転した点として定義されます。 楕円曲線上の加算 ここで、曲線上の点の座標をある整数を法としてとると、曲線は平面上の離散的な点の集合になります。しかし対称性は依然として保たれるため、加算演算は引き続き矛盾なく定義できます。Curve25519 は大きな素数 (具体的には 2 255 – 19) にちなんで名付けられています。この素数を法とする数の集合と、同じ素数を法とする乗算などの基本算術演算を組み合わせることで、楕円曲線演算の基盤となる 体 (field) が定義されます。 楕円曲線の加算を繰り返し行うことをスカラー倍算と呼び、スカラーは加算の回数を表します。暗号で使用される楕円曲線では、スカラー倍算の結果のみがわかっている場合、スカラーが十分に大きければ元のスカラーを復元することは計算上困難です。このスカラー倍算の結果が公開鍵の基礎となり、元のスカラーが秘密鍵の基礎となります。 x25519 と Ed25519 暗号アルゴリズム x/Ed25519 の各アルゴリズムにはそれぞれ異なる目的があります。x25519 は鍵共有アルゴリズムであり、2 つのピア間で安全に共有シークレットを確立するために使用されます。一方、Ed25519 はデジタル署名アルゴリズムであり、データの署名と検証に使用されます。 x/Ed25519 アルゴリズムは TLS や SSH などのトランスポート層プロトコルで広く採用されています。2023 年には、NIST が Ed25519 の追加を含む FIPS 185-6 Digital Signature Standard の更新を発表しました。また、x25519 アルゴリズムはポスト量子暗号ソリューションにおいても重要な役割を果たしており、TLS 1.3 や SSH のポスト量子鍵共有ハイブリッド方式において、古典的アルゴリズムとして仕様に組み込まれています。 マイクロアーキテクチャの最適化 特定の CPU アーキテクチャ向けにアセンブリコードを記述する際には、その ISA を使用します。ISA は、利用可能なアセンブリ命令とそのセマンティクス、プログラマがアクセスできる CPU レジスタなどのリソースを定義するものです。ここで重要なのは、ISA はあくまで CPU の抽象的な定義であり、ハードウェアとしてどのように実現するかを規定するものではないという点です。 CPU のハードウェアレベルの詳細な実装はマイクロアーキテクチャと呼ばれ、各 μ arch には固有の特性があります。例えば、AWS Graviton 2 CPU と AWS Graviton 3 CPU はどちらも Arm64 ISA に基づいていますが、 μ arch の実装は異なります。AWS では、この μ arch の違いを活用することで、AWS-LC の既存実装よりもさらに高速な x/Ed25519 実装を実現できるのではないかと考えました。実際に、この仮説は正しいことが確認されました。 ここでは、 μ arch の違いをどのように活用したかを詳しく見ていきましょう。Curve25519 上にはさまざまな算術演算を定義でき、これらの演算を組み合わせて x/Ed25519 アルゴリズムが構成されます。概念的には、必要な算術演算は以下の 3 つのレベルに分けて考えることができます。 体の演算: Curve25519 の素数 2 255 – 19 で定義される体における演算 楕円曲線群の演算: 2 点 P1 と P2 の加算など、曲線上の要素に対する演算 トップレベルの演算: スカラー倍算など、楕円曲線群の演算を繰り返し適用して実現される演算 各レベルにおける演算の例。矢印はレベル間の依存関係を示しています。 各レベルにはそれぞれ独自の最適化の余地があります。AWS ではレベル 1 の演算に μ arch 固有の最適化を集中させ、レベル 2 と 3 については既知の最先端技術を採用しており、異なる μ arch 間でほぼ同一の実装となっています。以下に、x/Ed25519 の実装で採用した μ arch 固有の選択の概要を示します。 最新の x86_64 μ arch では、MULX、ADCX、ADOX 命令を使用しています。これらは、一般に BMI および ADX と呼ばれる命令セット拡張に含まれる命令で、標準アセンブリ命令 MUL (乗算) および ADC (キャリー付き加算) の変形です。これらの命令の特長は、組み合わせて使用することで 2 つのキャリーチェーンを並列に維持できる点にあり、最大 30% のパフォーマンス向上が確認されています。これらの命令セット拡張をサポートしない旧世代の x86_64 μ arch では、従来のシングルキャリーチェーンを使用しています 整数乗算器が改良された AWS Graviton 3 などの Arm64 μ arch では、比較的単純な筆算方式の乗算でも良好なパフォーマンスが得られます。一方、AWS Graviton 2 は乗算器が小さい Arm64 μ arch であるため、乗算を再帰的に分解する減算形式の カラツバ乗算 を採用しています。これは、この μ arch では 128 ビットの結果を生成する 64×64 ビット乗算のスループットが他の演算と比べて大幅に低く、カラツバ最適化がより小さな数値サイズでも有効になるためです すべての μ arch に共通するレベル 1 の演算についても最適化を行いました。その一例が、バイナリ最大公約数 (GCD) アルゴリズムによる モジュラー逆元 の計算です。AWS ではバイナリ GCD の 「divstep」形式 を採用しています。この形式は効率的な実装に適している一方、もう一つの目標である正当性の形式的な証明はより困難になります。 バイナリ GCD は 2 つの引数を持つ反復アルゴリズムで、最大公約数を求めたい数を初期値として使用します。各イテレーションで引数は明確に定義された方法で縮小され、いずれか一方がゼロになるとアルゴリズムは終了します。 n ビットの 2 つの数に対しては、標準的な実装では各イテレーションで合計少なくとも 1 ビットが除去されるため、2 n 回のイテレーションで十分です。 しかし divstep の場合、基底ケースに到達するために必要なイテレーション回数を解析的に決定するのは困難と考えられています。この上界に対する最も扱いやすい証明は、引数値に対応する点を含む 2 次元空間の領域を証明可能な形で過大近似する精巧な「stable hull」に基づいており、入念な帰納法の議論が展開されています。x25519 と Ed25519 の発明者の一人である Daniel Bernstein 氏は、本記事の著者の一人である John が開発した HOL Light 対話型定理証明器を使用して、この上界の 形式的な正当性 を証明しました。(HOL Light の詳細については、先述の RSA に関する記事 をご覧ください。) パフォーマンスの結果 ここでは、パフォーマンスの向上について紹介します。簡潔にするため、AWS Graviton 2、AWS Graviton 3、Intel Ice Lake の 3 つの μ arch に焦点を当てます。パフォーマンスデータの収集には、各 CPU μ arch に対応する EC2 インスタンス (それぞれ c6g.4xlarge、c7g.4xlarge、c6i.4xlarge) を使用しました。各アルゴリズムのベンチマークには AWS-LC speed tool を使用しました。 以下のグラフでは、単位はすべて 1 秒あたりの演算回数 (ops/sec) です。「before」列は AWS-LC の既存の x/Ed25519 実装のパフォーマンスを、「after」列は新しい実装のパフォーマンスを表しています。 Ed25519 の署名演算では、3 つの μarch 全体で、新しい実装により 1 秒あたりの演算回数が平均 108% 向上 Ed25519 の検証演算では、3 つの μarch 全体で、1 秒あたりの演算回数が平均 37% 向上 最も大きな改善が見られたのは x25519 アルゴリズムです。なお、以下のグラフにおける x25519 の演算には、x25519 鍵共有に必要な 2 つの主要な演算である基底点乗算と可変点乗算の両方が含まれています。 x25519 では、新しい実装により、3 つの μarch 全体で 1 秒あたりの演算回数が平均 113% 向上 AWS Graviton 2、AWS Graviton 3、Intel Ice Lake の 3 つの μ arch 全体で、平均 86% のパフォーマンス向上を達成しました。 正当性の証明 AWS では、AWS-LC における x/Ed25519 実装のコア部分を s2n-bignum で開発しています。s2n-bignum は、暗号アプリケーション向けに設計された AWS が所有する整数演算ルーチンライブラリです。s2n-bignum ライブラリでは、 HOL Light を使用して実装の機能的正当性も証明しています。HOL Light は、高階論理 (Higher-Order Logic、略して HOL) のための対話型定理証明器です。名前の「Light」が示すとおりシンプルさを重視して設計されており、構成による正しさ (correct by construction) のアプローチで証明を行います。このシンプルさにより、「証明された」とされるものが本当に厳密に証明されたものであり、証明器のバグによる誤りではないという高い確信が得られます。 実装をアセンブリで記述する際にも、同じシンプルさの原則に従っています。アセンブリでの記述はより困難ですが、正当性の証明においては明確な利点があります。コンパイラに依存しない証明が可能になるためです。 下の図は、x/Ed25519 の正当性の証明プロセスを示しています。このプロセスには 2 種類の入力が必要です。1 つ目は評価対象のアルゴリズム実装、2 つ目はアルゴリズムの正しい数学的挙動と CPU の挙動をモデル化した証明スクリプトです。証明は HOL Light 固有の関数列として記述され、証明戦略とその適用順序を定義します。証明の記述は自動化されておらず、開発者の創意工夫が求められます。 HOL Light は、アルゴリズム実装と証明スクリプトを入力として受け取り、実装が正しいと判定するか、判定できない場合は失敗を返します。HOL Light はアルゴリズム実装をマシンコードのバイト列として扱い、CPU 命令の仕様と証明スクリプト内に開発者が記述した戦略を用いて、実行の正当性を検証します。 CI 統合により、正当性の形式的証明に合格しない限り、アルゴリズム実装コードの変更を s2n-bignum のコードリポジトリにコミットできないことが保証されます。 正当性の証明のこのステップは自動化されており、s2n-bignum の継続的インテグレーション (CI) ワークフローにも組み込まれています。CI がカバーするワークフローは、図中の赤い点線で示されています。CI 統合により、正当性の形式的証明に合格しない限り、アルゴリズム実装コードの変更を s2n-bignum のコードリポジトリにコミットできないことが保証されます。 CPU 命令の仕様は、正当性の証明において最も重要な要素の 1 つです。証明が実際に正しいものであるためには、仕様が各命令の実際のセマンティクスを正確に捉えている必要があります。この信頼性を高めるため、AWS では実際のハードウェア上で命令仕様に対するランダム化テストを実施し、ファジングによって不正確さを検出しています。 定数時間 AWS では、セキュリティを最優先事項として実装と最適化を設計しました。暗号コードは、権限のないユーザーが秘密情報を抽出できるような サイドチャネル を排除するよう努める必要があります。例えば、暗号コードの実行時間が秘密の値に依存する場合、攻撃者は実行時間からその値を推測できる可能性があります。同様に、CPU キャッシュの動作が秘密の値に依存する場合、キャッシュを共有する権限のないユーザーがその値を推測できる可能性があります。 x/Ed25519 の実装は、定数時間を念頭に置いて設計されています。入力値にかかわらずまったく同じ基本 CPU 命令シーケンスを実行し、データ依存のタイミングを持つ可能性のある CPU 命令は使用しません。 アプリケーションでの x/Ed25519 最適化の活用 AWS では、さまざまな AWS サービスのサブシステムにおける暗号処理に AWS-LC を広く使用しています。本記事で紹介した x/Ed25519 の最適化は、アプリケーションで AWS-LC を使用することで活用できます。アプリケーションへの AWS-LC の統合方法については、 GitHub の AWS-LC をご覧ください。 開発者がより簡単に統合できるよう、AWS は AWS-LC から複数のプログラミング言語へのバインディングを作成しました。これらのバインディングは、明確に定義された API を通じて AWS-LC の暗号機能を提供するため、高水準プログラミング言語で暗号アルゴリズムを改めて実装する必要はありません。現在、AWS は Java 向けの Amazon Corretto Cryptographic Provider ( ACCP ) と Rust 向けの AWS-LC ( aws-lc-rs ) のバインディングをオープンソースとして公開しています。さらに、 CPython が AWS-LC に対してビルドし、Python 標準ライブラリのすべての暗号処理に AWS-LC を使用できるようにするパッチも提供しています。以下に、暗号処理に AWS-LC を採用しているオープンソースプロジェクトの一部を紹介します。 暗号処理に AWS-LC を採用しているオープンソースプロジェクト 取り組みはこれで終わりではありません。AWS は引き続き x/Ed25519 のパフォーマンス改善に取り組むとともに、s2n-bignum と AWS-LC がサポートする他の暗号アルゴリズムの最適化も推進しています。最新情報については、 s2n-bignum と AWS-LC の GitHub リポジトリをご確認ください。 著者について Torben Hansen Torben Hansen は AWS Cryptography のアプライドサイエンティストです。 John Harrison John Harrison は Amazon Automated Reasoning Group のシニアプリンシパルアプライドサイエンティストです。s2n-bignum と HOL Light 定理証明器のメンテナーを務めています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 8 月 8 日に公開された Amazon Science Blog “ Formal verification makes RSA faster — and faster to deploy ” を翻訳したものです。 Amazon の Graviton2 チップ向け最適化で効率が向上し、形式的検証により開発時間も短縮しました。 オンラインにおける安全な取引のほとんどは、RSA のような公開鍵暗号方式によって保護されています。RSA のセキュリティは、大きな数の素因数分解が困難であることに基づいています。公開鍵暗号によって秘密鍵を安全に交換できるため、セキュリティが向上します。ただし、大きな整数のべき乗剰余演算などの重い計算処理が必要となるため、大きな計算オーバーヘッドが伴います。 研究者やエンジニアは公開鍵暗号の効率を高めるためにさまざまな最適化手法を導入してきましたが、最適化に伴う複雑さのため、暗号アルゴリズムの正しさを検証することが難しくなっています。暗号アルゴリズムのバグは致命的な結果をもたらしかねません。 この記事では、Amazon Automated Reasoning Group が Graviton2 チップにおける RSA 署名のスループットを鍵サイズに応じて 33～94% 向上させ、形式的検証を用いて最適化コードの機能的正当性を証明した取り組みについて紹介します。 AWS Graviton チップ Graviton2 は、Amazon Annapurna Labs が開発した Arm Neoverse N1 コアベースのサーバークラス CPU です。Graviton2 での RSA 署名のスループットを向上させるため、剰余演算を高速化するさまざまな手法と Graviton2 固有のアセンブリレベルの最適化を組み合わせました。最適化したコードの機能的正当性を証明するため、チームメンバーの John Harrison が開発した HOL Light 対話型定理証明器を用いて形式的検証を行いました。 コードは、秘密情報に依存する分岐やメモリアクセスパターンを排除する定数時間スタイルで記述されています。これは、関数の実行時間などの観測可能な情報から秘密情報を推測するサイドチャネル攻撃を防ぐためです。最適化した関数とその証明は、Amazon Web Services が提供する形式的検証済み多倍長整数演算ライブラリ s2n-bignum に含まれています。これらの関数は、AWS が管理する暗号ライブラリ AWS-LC と、そのバインディングである Amazon Corretto Crypto Provider ( ACCP ) および AWS Libcrypto for Rust ( AWS-LC-RS ) でも利用されています。 鍵サイズ (ビット) ベースラインスループット (ops/sec) 改善後スループット (ops/sec) 高速化率 (%) 2048 299 541 81.00% 3072 95 127 33.50% 4096 42 81 94.20% Graviton2 上の AWS-LC における RSA 署名のスループット改善。 ステップ 1. Graviton2 での RSA の高速化 Graviton2 上で RSA アルゴリズムを最適化するには、乗算命令の配置と活用を慎重に検討する必要があります。64 ビット Arm CPU では、2 つの 64 ビット数値を乗算して最大 128 ビットの積を得る処理 (一般に 64×64→128 と表記) は、下位 64 ビットを返す MUL と上位 64 ビットを返す UMULH の 2 つの命令で構成されます。Graviton2 では、 MUL の レイテンシは 4 サイクル で、発行後 2 サイクルの間乗算パイプラインをストールさせます。一方、 UMULH のレイテンシは 5 サイクルで、発行後 3 サイクルの間乗算パイプラインをストールさせます。Neoverse N1 の乗算パイプラインは 1 つしかないのに対し加算パイプラインは 3 つあるため、乗算のスループットは 64 ビット加算の約 10 分の 1 にとどまります。 スループットを向上させるため、(1) 乗算命令を加算命令に置き換える別の乗算アルゴリズムを適用し、(2) SIMD (Single Instruction/Multiple Data) 命令を使用して乗算処理の一部を CPU のベクトルユニットにオフロードしました。 アルゴリズムの最適化 モンゴメリモジュラ乗算は、高速かつ安全な剰余演算を実現するために広く使われている手法です。モンゴメリ乗算は数値をモンゴメリ形式と呼ばれる特殊な形式で表現します。RSA アルゴリズムのように一連の剰余演算を実行する場合、中間積をモンゴメリ形式のまま保持することで、計算をより効率的に行えます。 モンゴメリ乗算を、多倍長整数乗算と独立したモンゴメリリダクションの組み合わせとして実装しました。これは 2 つの 標準的な実装方法 の 1 つです。 Graviton2 では、このアプローチを採用することで、よく知られたカラツバアルゴリズムを用いてコストの高い乗算を加算に置き換えることができます。カラツバアルゴリズムは、1 つの乗算を 3 つのより小さな乗算といくつかのレジスタシフトに分解する手法です。再帰的に適用でき、大きな数に対しては標準的な乗算アルゴリズムよりも効率的です。 カラツバアルゴリズムは、2,048 ビットや 4,096 ビットなどの 2 のべき乗のビットサイズに対して適用しました。それ以外のサイズ (例: 3,072 ビット) では、二次乗算を引き続き使用しています。また、カラツバ乗算は 2 つのオペランドが等しい場合にさらに最適化できるため、二乗演算に特化した関数も作成しました。 これらの最適化により、元のコードと比較して 2,048 ビットおよび 4,096 ビットの RSA 署名で 31～49% の高速化を達成しました。 マイクロアーキテクチャの最適化 多くの Arm CPU は Neon SIMD (Single Instruction/Multiple Data) アーキテクチャ拡張を実装しています。この拡張により、さまざまなサイズ (8/16/32/64 ビット) のベクトルとして扱える 128 ビットレジスタファイルと、それらのベクトルの一部または全部を並列処理できる SIMD 命令が追加されます。さらに、SIMD 命令はスカラ命令とは異なるパイプラインを使用するため、両者を並列に実行できます。 ベクトル化の戦略 ベクトル化とは、同じ演算の逐次的な繰り返しを、複数の値に対する単一の演算に置き換える手法で、一般的に処理効率が向上します。SIMD 命令を使用して、スカラの 64 ビット乗算をベクトル化しました。 多倍長整数乗算では、ベクトル化した 64 ビットの下位乗算コードが、スカラの 64 ビット上位乗算命令 ( UMULH ) とうまくオーバーラップしました。二乗演算では、2 つの 64×64→128 ビットの二乗演算をベクトル化することが効果的でした。モンゴメリリダクションにおける乗算では、64×64→128 ビットの乗算と 64×64→64 の下位乗算をベクトル化することが有効でした。ベクトル化するスカラ乗算を選定するにあたり、さまざまなベクトル化パターンを列挙して実行時間を計測するスクリプトを作成しました。短いコードフラグメントでは全パターンの列挙が可能でしたが、大きなコードフラグメントでは経験的な判断に頼る必要がありました。最終的な手法は、 Seo et. al. at ICISC’14 に記述された手法をはじめ、他の代替手法との広範な比較実験を経て決定しました。 スカラユニットと SIMD ユニットは並列に動作しますが、整数レジスタと SIMD レジスタ間で入力値や中間結果を移動する必要が生じることがあり、これが大きな複雑さの要因となります。 FMOV 命令を使えば 64 ビットスカラレジスタから SIMD レジスタにデータをコピーできますが、この命令はスカラ乗算器と同じパイプラインを使用するため、スカラ乗算のスループットが低下します。 代替手段として、まずベクトルレジスタにロードしてから MOV でスカラレジスタにコピーする方法もありますが、レイテンシは低いものの SIMD パイプラインを占有するため、SIMD 演算のスループットが低下します。直感に反しますが、最善の解決策は整数レジスタと SIMD レジスタに対して別々にメモリからロードし、それらの相対的な配置に注意を払うことでした。ただし、SIMD の結果が既に SIMD レジスタにある場合は、ストアロードによる往復よりも高速であるため、 MOV 命令を使って一部の SIMD 結果を整数レジスタにコピーしました。 高速な定数時間テーブルルックアップコード もう 1 つの独立した改善点として、高速なべき乗剰余アルゴリズム向けの定数時間ルックアップテーブルをベクトル化して再実装しました。この改善を先述の最適化と組み合わせることで、初期コードと比較して 2,048/4,096 ビット RSA 署名のスループットが 80～94% 向上し、3,072 ビット署名でも 33% の高速化を達成しました。 命令スケジューリング Graviton2 はアウトオブオーダー CPU ですが、リオーダーバッファや発行キューなどのコンポーネント容量が有限であるため、パフォーマンスを最大化するには命令を慎重にスケジューリングすることが重要です。ここで述べた実装は手動の命令スケジューリングによるもので、良好な結果は得られましたが、かなりの時間を要しました。 制約求解と (簡略化された) マイクロアーキテクチャモデルに基づく SLOTHY スーパーオプティマイザ を使用して、この作業を自動化する方法も検討しました。カラツバアルゴリズムで使用する一部の数値を事前計算するようにモンゴメリリダクションを追加調整し、SLOTHY による最適化を適用した結果、2,048/4,096 ビットのスループットで 95～120%、3,072 ビットで 46% の改善を実現しました。ただし、自動スケジューリングの正当性検証が困難であることが判明したため、この手法はまだ AWS-LC に組み込まれていません。スケジューリング最適化の正当性を自動的に証明する手法については、現在研究を進めています。 ステップ 2. コードの形式的検証 最適化したコードを本番環境にデプロイするには、正しく動作することを確認する必要があります。ランダムテストはシンプルな既知のケースを素早くチェックできる手軽なアプローチですが、より高い保証を得るために形式的検証を使用しています。このセクションでは、暗号プリミティブの機能的正当性を証明するために形式的検証をどのように適用するかを説明します。 s2n-bignum の紹介 AWS の s2n-bignum は、(1) x86-64 および Arm のアセンブリコードの形式的検証を行うためのフレームワークであり、同時に (2) そのフレームワークを使用して検証された暗号向けの高速なアセンブリ関数のコレクションです。 s2n-bignum における仕様 s2n-bignum のすべてのアセンブリ関数 (RSA で使用する新しいアセンブリ関数を含む) には、機能的正当性を記述した仕様が用意されています。仕様では、ある事前条件を満たすすべてのプログラム状態に対して、プログラムの出力状態がある事後条件を満たさなければならないと規定しています。例として、 bignum_mul_4_8(uint64_t *z, uint64_t *x, uint64_t *y) は 2 つの 256 ビット (4 ワード) の数値を乗算して 512 ビット (8 ワード) の結果を生成する関数です。入力状態 s に対する事前条件 (省略版) は以下のとおりです。 aligned_bytes_loaded s (word pc) bignum_mul_4_8_mc ∧ read PC s = word pc ∧ C_ARGUMENTS [z, x, y] s ∧ bignum_from_memory (x,4) s = a ∧ bignum_from_memory (y,4) s = b これは、 bignum_mul_4_8 のマシンコードがプログラムカウンタ PC の現在のアドレスにロードされていること ( aligned_bytes_loaded )、C のアプリケーションバイナリインターフェイス (ABI) に従って関数引数にシンボリック値が割り当てられていること ( C_ARGUMENTS … )、そしてシンボル a と b で表される多倍長整数がそれぞれ x と y の指すメモリ位置に 4 ワード分格納されていること ( bignum_from_memory … ) を意味します。 出力状態 s に対する事後条件 (省略版) は以下のとおりです。 bignum_from_memory (z,8) s = a * b これは、乗算結果 a * b が位置 z から始まる 8 ワードのバッファに格納されることを意味します。 もう 1 つの構成要素として、入力状態と出力状態の間で満たすべき関係があります。 (MAYCHANGE_REGS_AND_FLAGS_PERMITTED_BY_ABI; MAYCHANGE [memory :> bytes(z,8 * 8)]) (s_in,s_out) これは、コードの実行によって ABI で許可されたレジスタやフラグ、および z から始まる 8 ワードのバッファは変更される可能性がありますが、それ以外の状態はすべて変更されないことを意味します。 HOL Light を用いたアセンブリの検証 実装が仕様に対して正しいことを証明するために、HOL Light 対話型定理証明器 を使用しています。「ブラックボックス」型の自動定理証明器とは異なり、HOL Light のようなツールは、定型的な証明ステップの自動化と、ユーザーによる明示的かつプログラム可能なガイダンスのバランスを重視しています。紙の上や頭の中に証明があれば、熟練したユーザーはそれを対話型定理証明器で効率的に記述できます。s2n-bignum では、プログラムの検証に以下の 2 つの戦略を組み合わせています。 記号実行 記号実行では、特定の値の代わりにシンボリック変数を使用して入力プログラム状態を表現し、コード断片の実行後のシンボリック出力状態を推論します。これは実質的に、プログラム実行をより厳密かつ一般化した形で行うことに相当します。事後条件の証明は依然として必要ですが、プログラム実行に伴うアーティファクトが取り除かれ、純粋な数学的問題に帰着されます。 フロイド-ホーア論理スタイルの中間アノテーション 各中間アサーションは、先行するコードの事後条件であると同時に、後続するコードの事前条件として機能します。アサーションには、対応する事後条件を証明するために必要な詳細のみを含めれば十分です。この抽象化により、自動推論の処理能力の面でも、人間が結果を理解しやすくなるという面でも、記号シミュレーションがより扱いやすくなります。 Arm ハードウェアが s2n-bignum のモデルどおりに動作することを前提としていますが、モデルは慎重に開発されており、ハードウェアとの広範なクロスチェックによって検証されています。 形式的検証の今後の改善 s2n-bignum の形式的検証は、コードの実行時間などのサイドチャネルを通じた情報漏洩の有無といった、実装の非機能特性についてはまだカバーしていません。現在は、規律ある実装スタイルによって対処しています。具体的には、除算のように実行時間が変動する命令を使用せず、秘密データに依存する条件分岐やメモリアクセスパターンを排除しています。さらに、シンプルな静的チェックによってこれらの特性の一部を簡易検証し、ビット密度が大きく異なる入力でコードを実行して実行時間を分析し、予期しない相関がないか調査しています。 これらの規律と簡易チェックは AWS の標準的な手法であり、本記事で説明したすべての新しい実装に適用しています。情報漏洩がないことの形式的検証については、現在研究を進めています。 著者について June Lee Juneyoung Lee は Amazon Automated Reasoning Group のアプライドサイエンティストです。形式的検証済み暗号プリミティブをアセンブリで実装するライブラリを構築する s2n-bignum プロジェクトに取り組んでいます。 Hanno Becker Hanno Becker は Amazon Automated Reasoning Group のシニアアプライドサイエンティストです。Mbed TLS の元開発者であり、Arm 上の高性能な (耐量子) 暗号技術に情熱を注いでいます。SLOTHY スーパーオプティマイザの作者でもあります。 John Harrison John Harrison は Amazon Automated Reasoning Group のシニアプリンシパルアプライドサイエンティストです。s2n-bignum および HOL Light 対話型定理証明器のメンテナーです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは ミツイワ株式会社 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 企業の DX 推進が加速する中、IT インフラの迅速な構築と安定運用は、ビジネスの成否を左右する重要な要素となっています。特に、新しいアプリケーションやサービスを導入する際、実行基盤の準備に時間がかかり、サービス開始までのリードタイムが長期化することは、多くの企業が直面する課題です。 従来のインフラ構築では、顧客からの問い合わせ内容の整理、要件定義、環境設計、構築作業、そして運用設定まで、多くの工程で人手を介する必要がありました。その結果、担当エンジニアの負担が大きく、品質のばらつきや属人化といった問題も発生していました。また、最新の IT サービスを導入するためには専門領域外の高度な学習が必要となり、技術の習得コストも課題となっていました。 今回ご紹介するのは、ミツイワ株式会社様が、Amazon Bedrockと AWS CloudFormation を活用して、インフラ構築プロセスを一気通貫で自動化した先進的な事例です。 ミツイワ株式会社様の状況と課題 ミツイワ株式会社様は、ICT サービス事業を核に、企業の情報システム導入から運用、さらには最先端の DX 推進まで、ICT ライフサイクル全体をサポートするワンストップソリューションを提供されています。マネージドサービスを通じて多くの企業の IT インフラを支えてきた同社ですが、急速な IT 技術の進化に伴い、以下のような課題に直面していました： リードタイムの長期化 顧客からの問い合わせが未整理のまま届き、内容確認と要件整理に多くの時間を要していた 業務課題を解決するために新たなアプリケーションを導入しようとしても、実行基盤の準備に時間がかかり、実際のサービス開始まで長期間を要していた 顧客ごとに異なる環境を手作業で構築するため、リードタイムの長期化と品質のばらつきが発生していた 品質維持と運用負荷 クラウド環境の構築依頼から完了まで、担当エンジニアの負担が大きく、本来注力すべき業務改善に時間が割けない状況であった 導入したアプリケーションや実行基盤の品質維持に多くの工数が割かれていた 運用設計の標準化が不十分で、属人化のリスクがあった 学習コストと属人化 最新の IT サービスを導入するために、専門領域外の高度な学習が必要となり、技術習得に時間がかかっていた 技術が属人化しやすく、担当者の異動や退職時に業務の継続性に懸念があった ミツイワ様はこれらの課題を解決するため、自社のマネージドサービスを進化させ、顧客の価値向上に繋げるべく、生成 AI と IaC を活用した次世代インフラ自動構築ソリューションの開発に至りました。 ソリューション ミツイワ株式会社様は、AWS の生成 AI サービスとマネージドサービスを最大限活用し、以下のようなアーキテクチャを構築しました： Amazon Bedrock による解析の自動化 顧客からの問い合わせ内容を Amazon Bedrock が自動で解析し、要件を構造化 解析結果に基づいて、最適な AWS CloudFormation テンプレートを自動選定 生成 AI の自然言語処理能力により、未整理の問い合わせでも適切に解釈し、必要な AWS リソースを特定 AWS CloudFormation によるコード管理 AWS のリソース構築や運用設計をあらかじめテンプレート化し、高い再現性と品質を確保 AWS CloudFormation により、インフラのプロビジョニングと設定を自動化し、手作業によるミスを排除 テンプレートのバージョン管理により、環境の変更履歴を追跡可能にし、必要に応じてロールバックを実現 サーバーレスな高速構成 AWS Lambda のサブプロセスで MCP サーバーを起動し、高速かつサーバーレスな構成を実現 ジョブ型非同期処理により、利用者が処理状況を追跡可能となり、ユーザーエクスペリエンスが向上 サーバー管理が不要なサーバーレスアーキテクチャにより、運用負荷を最小化 一気通貫の自動化フロー 本ソリューションは、以下のような一連のプロセスを人手を介さずに自動化します： 1. 問い合わせ受付: 顧客からの問い合わせを受付 2. 要件解析: Amazon Bedrock が問い合わせ内容を解析し、必要な AWS リソースを特定 3. テンプレート選定: 解析結果に基づき、最適な AWS CloudFormation テンプレートを自動選定 4. 環境構築: AWS CloudFormation により AWS 環境を自動構築 5. 初期設定: 運用に必要な初期設定を自動適用 6. 完了通知: 構築完了を利用者に通知 この自動化により、従来は数日から数週間かかっていたプロセスを、大幅に短縮することが可能になりました。 導入効果 AWS の生成 AI と IaC を活用した次世代インフラ自動構築ソリューションの導入により、以下の効果が得られました： リードタイムの大幅短縮 問い合わせの受付から基盤の準備、初期設定までを標準化・自動化し、サービスインまでの期間を大幅に短縮 AWS のサービスを使うことで短期間で依頼内容の整理から環境構築まで自動化され、ビジネスの俊敏性が向上 業務時間の再配分 構築・運用の自動化により、余剰となった時間を業務改善や新たな価値創出へ再配分することが可能に エンジニアが本来注力すべき業務に集中できるようになり、顧客への提供価値が向上 安定稼働と継続性の向上 運用設計をテンプレート化したことで学習コストと属人性を抑制 サポートセンターによる運用と合わせて、システムの安定稼働と継続運用性を向上 AWS CloudFormation によるコード管理により、環境の再現性が格段に向上し、品質のばらつきを解消 ユーザーエクスペリエンスの向上 ジョブ型非同期処理により、利用者が処理状況を追跡可能となり、透明性が向上 自動化により、迅速かつ正確なサービス提供が可能になり、顧客満足度が向上 お客様の声 Amazon Bedrock と AWS CloudFormation を組み合わせることで、インフラ構築の全自動化を実現できました。特に、AWS Lambda 上で MCP サーバーを起動するサーバーレスな構成は、高速かつ運用負荷の少ないアーキテクチャを実現する上で非常に効果的でした。問い合わせ解析から AWS 環境構築までを一気通貫で自動化したことで、エンジニアの工数を大幅に削減し、本来注力すべき業務に集中できるようになりました。また、AWS CloudFormation によるテンプレート管理により、環境の再現性と品質が向上し、属人化のリスクも軽減されました。 今後の展望 ミツイワ株式会社様は今後、以下の取り組みを通じて、さらなる顧客価値の最大化を目指しています： ITSM 連携の強化 利用申請からサービスの提供、その後の設定変更の管理やインシデント管理に至るまで、自動化の範囲を拡大 IT サービスマネジメント（ITSM）ツールとの連携により、エンドツーエンドの自動化を実現 マルチアカウント展開 複数の AWS アカウントにまたがる環境構築を自動化し、大規模な組織での展開を支援 AWS Organizations と連携した、ガバナンスとセキュリティを考慮した自動構築を実現 継続的な改善 生成 AI の進化に合わせて、解析精度と自動化の範囲を継続的に拡大 顧客からのフィードバックを基に、テンプレートの拡充とプロセスの最適化を推進 まとめ 本事例は、Amazon Bedrock と AWS CloudFormation を組み合わせることで、インフラ構築プロセスの全自動化を実現した先進的な取り組みです。生成 AI による問い合わせ解析と、IaC による環境構築の自動化により、リードタイムの大幅短縮、品質の向上、そして属人化の解消を同時に達成しました。特に注目すべきは、AWS Lambda 上で MCP サーバーを起動するサーバーレスな構成により、高速かつ運用負荷の少ないアーキテクチャを実現している点です。本事例が、インフラ構築の自動化や生成 AI の活用をご検討中のお客様の参考になれば幸いです。 ミツイワ株式会社（左から）： AWS技術監修：福園　智憲様 ソフトウェア開発担当：芳我 俊祐様 AWSインフラ担当：浅羽　瞬様（パーソル＆サーバーワークス株式会社よりプロジェクト参画） Amazon Web Services Japan 合同会社： アカウントマネージャー 植木 輝（右端） ソリューションアーキテクト 森 瞭輔（左端）

本記事は 2026 年 2 月 26 日 に公開された「 Amazon OpenSearch Serverless introduces collection groups to optimize cost for multi-tenant workloads 」を翻訳したものです。 本日、Amazon OpenSearch Serverless のコレクショングループ機能の一般提供を開始しました。テナントごとの暗号化による安全なテナント境界を維持しながら、マルチテナントワークロードのコンピューティングコストを削減できます。コスト効率とアプリケーションに必要な分離・セキュリティレベルを柔軟に調整できます。 Amazon OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションで、検索や分析ワークロードを大規模に実行する際のインフラストラクチャ管理が不要になります。使用パターンが変化しても、リソースを自動的にプロビジョニング・スケーリングし、高速なデータ取り込みとミリ秒単位のレスポンスタイムを実現します。マルチテナント環境を管理する組織にとって、テナントのデータを暗号化して保護するデータ分離 (多くの場合、独自の暗号化キーを使用) はコンプライアンス要件です。 従来、OpenSearch Serverless は物理的な分離で高いセキュリティを確保していました。各 AWS Key Management Service キー (KMS キー) には、完全な物理的データ分離を維持するための専用 OpenSearch Compute Units (OCU) が必要でした。このアーキテクチャは高い保護を提供する一方、大規模なマルチテナントデプロイでは課題がありました。共有暗号化キーを使用する複数テナントの場合、OCU リソースは効率的にプールされ、経済性は良好です。しかし、データ分離のために独自の KMS キーを必要とする小規模テナントを多数管理する場合、コストが高くなるという課題がありました。一意のキーごとに専用 OCU リソースが必要なため、個々のテナントが OCU 容量のごく一部しか使用しない場合、インフラストラクチャコストが過大になる可能性がありました。特に、顧客に Bring Your Own Key (BYOK) 機能を提供したいサービスプロバイダーに影響し、持続不可能なコストを負担するか、サービス提供を制限するかの選択を迫られていました。 OpenSearch Serverless は、コスト管理のための最大 OCU 設定による柔軟なキャパシティ管理を提供してきました。ほとんどのワークロードでは、需要に応じてキャパシティがスケールアップ・ダウンするため、使用した分だけ支払えば済みます。しかし、一部のワークロードパターンでは、最初から一定のベースラインコンピューティングを確保しておく方が適しています。突発的なトラフィックスパイク、高速データ取り込みパイプライン、負荷テストなどのシナリオでは、キャパシティを事前に割り当てておくことで、最初のリクエストから他のリクエストと同じ応答性で処理できます。同様に、マルチテナントアーキテクチャや時間的制約のあるオペレーションでは、コレクションがアクティブになった瞬間から予測可能で一貫したパフォーマンスが求められます。 コレクショングループによる柔軟な制御 コレクショングループにより、セキュリティ境界とリソース割り当てを柔軟に制御できます。画一的なアプローチではなく、セキュリティ要件とコスト要件に合わせてアーキテクチャを調整できます。仕組みは次のとおりです。 ニーズに合ったセキュリティ境界の定義 : コレクショングループは、関連するコレクションの論理的なセキュリティ構成です。各コレクショングループは、他のコレクショングループとメモリ、CPU、ディスクが物理的に分離されており、異なるセキュリティ構成間の強固なセキュリティ境界を確保します。 暗号化キー間でのリソース共有 : KMS キーの共有・個別使用に関係なく、コレクションをコレクショングループに割り当てられます。異なる暗号化キーを持つコレクションが同じセキュリティ境界内で OCU リソースを共有できるようになり、各テナントの完全な暗号化保護と論理的分離を維持しながら、コストを大幅に削減できます。 柔軟なネットワークアクセスでのデプロイ : コレクショングループは異なるネットワークアクセスタイプのコレクションをサポートし、パブリックエンドポイントと VPC エンドポイントのコレクションを同じグループ内に組み合わせられます。セキュリティと接続要件に合わせながら、グループ内の全コレクションで共有リソース管理のメリットを享受できます。 コストとパフォーマンスの制御 : 最大 OCU で支出を制限し、最小 OCU でベースラインパフォーマンスを保証します。二重制御により各コレクショングループのリソース範囲が明確になり、予期しないコスト増加を防ぎつつ一貫したパフォーマンスを確保できます。 インサイトによる最適化 : コレクショングループ全体のリソース消費、相対的な使用パターン、レイテンシーを示す詳細な CloudWatch メトリクスにアクセスできます。インサイトを活用して、割り当ての適正化、最適化の機会の特定、実際のワークロード動作に基づくパフォーマンスチューニングが可能です。 コレクショングループにより、最小・最大 OCU 設定の両方でリソース割り当てを完全に制御できます。 最大 OCU: コスト制御 リソースの上限を設定して、コレクショングループごとの過剰なスケーリングを防ぎ、コストを制御します。予期しないトラフィックスパイク時でも予算を超えないようにできます。コレクショングループのキャパシティ制限はアカウントレベルの制限とは独立して動作します。アカウントレベルの最大 OCU 設定はコレクショングループに関連付けられていないコレクションにのみ適用され、コレクショングループの最大 OCU 設定はそのグループ内のコレクションに適用されます。(全コレクショングループの最大 OCU の合計 + アカウントレベルの最大 OCU 設定) がアカウントの Service Quota で許可された最大 OCU 以下である必要があります。アカウントレベルとコレクショングループレベルの分離により、異なるセキュリティコンテキスト間できめ細かなコスト制御が可能です。 最小 OCU: パフォーマンス保証 コレクショングループに常に割り当てるベースラインコンピューティングリソースを定義し、一貫したパフォーマンスとリソースの可用性を確保します。OCU はコレクショングループ専用に予約され、次のメリットがあります。 コールドスタートなしの即時利用 : コレクションはスケーリング遅延なしで即座に利用できます。リソースは常にウォーム状態で準備されており、トラフィック到着時の遅延がありません。 キャパシティの保証 : 低アクティビティ期間中や他のコレクショングループとの競合時でもリソースが常に利用可能で、低トラフィック時でも予測可能なパフォーマンスを確保します。 予測可能なコスト : 最小 OCU は継続的に課金され、予測可能な請求と引き換えに予約キャパシティを提供します。保証されたパフォーマンスと引き換えにコストの確実性が得られます。予約ベースラインはオートスケーリングの基盤となり、需要の増加に応じて最大制限までキャパシティを拡張します。 最小・最大 OCU の組み合わせにより、要件に基づいてコスト最適化とパフォーマンス保証を柔軟に調整できます。 コレクショングループによるマルチテナントのコスト経済性 マルチテナントアーキテクチャのコスト管理では、分離、パフォーマンス、効率のバランスが常に求められ、いずれかを犠牲にすることが多くありました。コレクショングループは、セキュリティ境界を犠牲にすることなくコレクション間で共有キャパシティを実現し、従来の前提を覆します。コレクショングループの有無による違いを以下に示します。 コレクショングループ導入前 : データ分離のためにそれぞれ独自の KMS キーを必要とする 10 テナントの顧客を考えます。テナントのほとんどは控えめなデータ要件で、通常 10〜100 GB、大半はその範囲の小さい方です。実際のキャパシティニーズに関係なく、各テナントの暗号化キーに専用リソースを管理することで、大規模な運用の複雑さとコストの課題が生じていました。 コレクショングループ導入後 : 同じ顧客が、類似のセキュリティ要件を持つテナントをコレクショングループにまとめ、コレクション間で OCU リソースを共有できます。OCU キャパシティのごく一部しか必要としないテナントに専用リソースを割り当てる必要がなくなり、小規模テナントが多いワークロードではコストを最大 90% 削減できます。 最小 OCU 設定の場合 : プレミアムテナントは最小 OCU を設定したコレクショングループに配置してパフォーマンスを保証し、スタンダードテナントはより低い最小しきい値のコレクショングループでコスト効率を高められます。 次の表は、コレクショングループの有無で異なるテナント構成におけるインフラストラクチャコストを比較し、さまざまなデータサイズとクエリ負荷でのコスト削減効果を示しています。 一意の KMS キーを持つテナント数 データサイズとクエリパラメータ 完全なデータ分離のコスト (コレクショングループなし) コレクショングループ使用時のコスト 補足 10 データサイズ: 60 GB 以下 クエリ: ベース OCU (冗長コレクションの場合 1) を超えるコンピューティングが不要 $3,500 $350 コストを 10 分の 1 に削減。 10 データサイズ: 60 GB 以下 クエリ: ピーク時にベース OCU (冗長コレクションの場合 1) を超えるコンピューティングが必要 (例: コレクショングループなしではテナントあたり追加 5 OCU、コレクショングループでは共有インフラのメリットにより全テナントで 40 OCU)。 $3,500 + ピーク時のテナントごとのスケールアウト ($8,650) $350 + ピーク時のスケールアウト ($6,912) 追加のクエリ負荷がかかるとシステムがスケールアップし、追加 OCU がデプロイされます。負荷が減少するとシステムはベース OCU にスケールインします。 10 テナントごとのサンプルデータサイズ (GB): [3, 5, 7, 8, 10, 15, 18, 25, 28, 150] クエリ: データサイズに対する最小 OCU で一定レベルまでクエリを処理し、負荷に応じてスケールアウト。 サンプルデータサイズの場合、最小 OCU 要件は [2, 2, 2, 2, 2, 2, 2, 2, 2, 8] = 26 OCU [$4,492] + ピーク時のテナントごとのスケールアウト 最小コストは全テナントのデータを保持するために必要な OCU 数 (OCU あたり 120 GB × 2) + ピーク時のスケールアウトで決まります。サンプルデータサイズの場合、8 OCU [$1,382] + ピーク時のテナントごとのスケールアウト 追加のクエリ負荷がかかるとシステムがスケールアップし、追加 OCU がデプロイされます。負荷が減少するとシステムはデータを保持するために必要な最小 OCU 数にスケールインします。 注: 上記の計算は 冗長性が有効 なコレクションを前提としています。非冗長モードの場合、上記の計算の半分になります。 コレクショングループの使用開始 コレクショングループと最小 OCU 設定は、 OpenSearch Serverless が提供されている全 AWS リージョン で追加料金なしで利用できます。コレクショングループを作成し、新しいコレクションをグループに直接追加して管理を強化できます。既存のコレクションはコレクショングループとは独立して変更なく動作し続けますが、新しいコレクションでコレクショングループをすぐに使い始められます。 現在、新しく作成したコレクションのみコレクショングループに関連付けることができ、グループ内の全コレクションは同じタイプ (検索、時系列、またはベクトル検索) である必要があります。既存のコレクションは現在のキャパシティ管理設定で独立して動作し続け、1 つのコレクショングループ内に異なるコレクションタイプを混在させることはできません。AWS マネジメントコンソール、AWS CLI、AWS CloudFormation、または AWS CDK でコレクショングループを作成できます。次のセクションでは、OpenSearch Service コンソールでの作成方法を説明します。 最初のコレクショングループを作成するには: OpenSearch Service コンソール を開きます。 左のナビゲーションペインで Serverless を選択し、 Collection groups を選択します。 Create collection groups を選択します。 collection groups name にコレクショングループの名前を入力します。名前は 3〜32 文字で、小文字で始まり、小文字、数字、ハイフンのみ使用できます。 (オプション) Description にコレクショングループの説明を入力します。 Capacity management セクションで OCU 制限を設定します。 Maximum indexing capacity – グループ内のコレクションがスケールアップできるインデキシング OCU の最大数。 Maximum search capacity – グループ内のコレクションがスケールアップできる検索 OCU の最大数。 Minimum indexing capacity – 一貫したパフォーマンスを維持するためのインデキシング OCU の最小数。 Minimum search capacity – 一貫したパフォーマンスを維持するための検索 OCU の最小数。 (オプション) Tags セクションで、コレクショングループの整理と識別に役立つタグを追加します。 Create collection groups を選択します。 コレクションをコレクショングループに割り当てるには Amazon OpenSearch Service コンソール を開きます。 左のナビゲーションペインで Serverless を選択し、 Collections を選択します。 Create collection を選択します。 Collection name にコレクションの名前を入力します。名前は 3〜28 文字で、小文字で始まり、小文字、数字、ハイフンのみ使用できます。 (オプション) Description にコレクションの説明を入力します。 Collection groups セクションで、コレクションを割り当てるコレクショングループを選択します。コレクションは一度に 1 つのコレクショングループにのみ所属できます。 (オプション) Create a new group を選択して新しいグループを作成することもできます。コレクショングループの作成が完了したら、ステップ 1 に戻って新しいコレクションの作成を開始します。 ワークフローを続行してコレクションを作成します。 コレクショングループの管理 コレクショングループを作成したら、アーキテクチャの進化に合わせて設定を更新できます。 Amazon OpenSearch Serverless のドキュメント に、AWS マネジメントコンソール、CLI、CloudFormation でのコレクショングループの編集・削除、OCU 制限の更新、グループ設定の変更に関するステップバイステップのガイダンスがあります。 まとめ OpenSearch Serverless のコレクショングループは、セキュリティ要件と運用効率を両立する柔軟なデプロイモードを提供し、マルチテナントデプロイのアーキテクチャを変革します。コレクショングループで論理的なセキュリティ境界を定義し、同じ KMS キーを共有するか異なる KMS キーを使用するかに関係なく、コレクション間で OCU リソースを共有できます。 コレクショングループの柔軟性は、従来マルチテナントデプロイを困難にしていたコスト課題に直接対応します。コレクショングループ内にコレクションを統合することで、暗号化とテナント分離を維持しながらインフラストラクチャコストを削減できます。各コレクショングループに最小・最大 OCU の両方を設定することで、コールドスタートとキャパシティ保証の課題を解決します。最小 OCU により、コレクションは高速取り込み、突発的なトラフィックスパイク、負荷テストをパフォーマンス低下なく処理するための準備済みコンピューティングリソースを維持します。最大 OCU はコストの予測可能性と支出制御を提供します。最小・最大の二重設定により、コールドスタートの不確実性とコスト超過のリスクの両方を排除するリソース範囲が明確になります。 コレクショングループと最小 OCU 設定の詳細については、 Amazon OpenSearch Serverless のドキュメント をご覧ください。 著者について Madhusudhan Narayana Madhusudhan は、Amazon Web Services のシニアソフトウェアエンジニアです。OpenSearch Service に注力しており、ソフトウェアエンジニアリング、分散システム、自律システムの分野で長年の経験があります。コンピュータサイエンスの修士号を取得しています。 Prashant Agrawal Prashant は、Amazon OpenSearch Service のシニアサーチスペシャリストソリューションアーキテクトです。仕事以外では旅行や新しい場所の探索を楽しんでいます。食べる → 旅する → 繰り返す、がモットーです。 Xian Huang Xian は、AWS のプロダクトマーケティングマネージャーです。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。

本記事は 2026 年 2 月 26 日 に公開された「 Improving order history search using semantic search with Amazon OpenSearch Service 」を翻訳したものです。 Amazon で買い物をしたことがあれば、 注文履歴 を使ったことがあるでしょう。この機能は 1995 年まで遡る注文履歴を保持しており、すべての購入を追跡・管理できます。注文履歴の検索機能では、検索バーにキーワードを入力して過去の購入品を見つけられます。商品を見つけるだけでなく、同じ商品や類似商品を簡単に再購入でき、時間と手間を節約できます。 Rufus や Alexa など、Amazon のショッピング体験を支えるさまざまな機能が注文履歴検索を活用し、過去の購入品を見つける手助けをしています。そのため、注文履歴検索には過去の購入品をできるだけ正確かつ迅速に見つける能力が求められます。 本記事では、Your Orders チームが Amazon OpenSearch Service と Amazon SageMaker を使い、既存のレキシカル検索システムにセマンティック検索機能を導入して注文履歴検索を改善した方法を紹介します。 レキシカル検索の限界 注文履歴検索では、 レキシカルマッチング を使って、検索キーワードの少なくとも 1 つの単語に一致する商品を顧客の注文履歴全体から取得しています。たとえば「orange juice」と検索すると、オレンジジュースだけでなく、過去に注文した生のオレンジや他のフルーツジュースも取得されます。レキシカルマッチングは検索キーワードに正確に一致する商品の 再現率 は高いものの、この例の「health drinks」のような関連キーワードや汎用的なキーワードではうまく機能しません。 Amazon の AI ショッピングアシスタント Rufus の登場以来、効率的で充実したショッピング体験を求める顧客が増え、Rufus で過去の購入品を検索するケースも増えています。「Show me healthy drinks」のように、「kombucha」「green tea」「protein shakes」といった長く正確な用語を気にせず検索できるようになりました。検索体験が会話的で意図ベースになり、商品をより直感的に見つけられるようになっています。Rufus が「Show me the healthy drinks I bought last year」のような注文履歴検索に同じ直感的な体験で応えるには、基盤となる注文履歴データストア (Your Orders) に、従来のレキシカルマッチングを超えて検索キーワードの意味を理解する セマンティック検索 機能が必要です。 セマンティック検索の実装における課題 この規模でセマンティック検索を実装するにあたり、次の技術的課題がありました。 スケール – 世界中の顧客の注文履歴に対応する数十億件のレコードでセマンティック検索を有効にする必要がありました。 ゼロダウンタイム – バックエンドでセマンティック検索を導入する変更を行う間も、システムの可用性を 100% 維持する必要がありました。 検索品質の低下防止 – セマンティック検索は検索品質の向上が目的ですが、逆効果になるケースもあります。たとえば、顧客が商品名を正確に覚えていてその名前に一致する商品だけを見つけたい場合、類似商品も表示すると結果が混雑し、目的の商品を見つけにくくなります。同様に、注文 ID のように固有の意味を持たない識別子で検索する場合、セマンティック検索は機能しません。このようなシナリオではレキシカル検索のみを使用します。 ソリューション概要 セマンティック検索は 大規模言語モデル (LLM) を基盤としています。LLM は主に人間の言語で学習されており、学習済みの言語のテキストを受け取り、入力テキストの長さに関係なく固定長のエンベディングベクトルを出力するように適応できます。エンベディングベクトルは入力テキストの意味を捉えるよう設計されており、意味的に類似した 2 つのテキストは、それぞれのエンベディングベクトルの コサイン類似度 が高くなります。注文履歴のセマンティック検索では、エンベディング生成と類似度計算の対象となる入力テキストは、顧客の検索フレーズと購入済み商品の商品テキストです。 ソリューションは 2 つのパートに分かれます。 大規模リクエスト処理に向けたスケーラビリティとレジリエンシーの向上 – セマンティック検索を実装する前に、増加する計算負荷に対応できるインフラストラクチャを確保する必要があり、 セルベースアーキテクチャ を採用しました。すべてのユースケースで必要ではありませんが、リクエスト量やデータ量が非常に大きいシステムでは、セマンティック検索のようなリソース集約型機能の実装前に大きな効果を発揮します。 セマンティック検索の実装 – まず利用可能なエンベディングモデルを評価し、 Amazon Bedrock のオフライン評価機能でさまざまなモデルをテストしました。モデルを選定した後、エンベディングベクトル生成のインフラストラクチャを構築しました。 システムのスケーラビリティとレジリエンシーの向上 スケーラビリティとレジリエンシーの向上には、 セルベースアーキテクチャ の設計パターンを採用しました。セルベースの設計では、システムを同一の小さな自己完結型のチャンク (セル) に分割し、各セルがシステム全体のトラフィックの一部のみを処理します。次の図は、注文履歴検索のセルベース設計の概要を示しています。 各セルは定義された顧客のサブセットを担当します。セル間で顧客リクエストを処理するための通信は不要です。各顧客はセルに割り当てられ、その顧客からのリクエストはすべて該当セルにルーティングされます。各セルの OpenSearch Service ドメインは、担当する顧客のサブセットのデータのみを保持します。セル数 (N) とセル間のデータ分散はビジネスユースケースに依存しますが、データとトラフィックをできるだけ均等に分散させることが目標です。 ルーティングロジックはユースケースに応じてシンプルにも高度にもできます。セル割り当て値はリクエストごとにランタイムで計算するか、一度計算して Amazon DynamoDB などのキャッシュや永続データストアに書き込み、以降のリクエストで参照する方法があります。注文履歴検索では、ロジックがシンプルで高速だったため、リクエストごとにランタイムで実行しました。永続データストアからセル割り当てを参照する方法は、一部のセルが時間とともに「重く」なるリスクがある場合に特に有効です。その場合、パーティショニングロジックを変更する代わりに、データストア内の特定キーのセル割り当て値を上書きするだけで、重いセルのデータを再分散できます。パーティショニングロジックの変更はすべてのセルのデータ分散に影響する可能性があります。 システムの負荷が増加した場合、セル数を増やして追加トラフィックに対応できます。セル数を増やさなくても、負荷の高いセルから軽いセルにキーを再割り当てすることで、既存の N セル間でデータを再分散し、負荷をより均等に分散させてインフラストラクチャをより効率的に活用できます。 セルベースアーキテクチャはシステムのレジリエンシー向上にも役立ちます。たとえば、1 つのセルが失われた場合、キャパシティの低下は 100% ではなく 1/N にとどまります。さらに、パーティショニングキーを 2 つ以上のセルに割り当てて複数のセルに書き込むことで、キャパシティ低下をさらに抑えられます。この場合、単一セルの喪失がデータ損失につながることはありません。 セマンティック検索の実装 注文履歴検索にセマンティック検索を実装するには、いくつかの重要な判断と技術的ステップが必要でした。まず利用可能なエンベディングモデルを評価し、Amazon Bedrock のオフライン評価機能でさまざまなモデルをビジネスドメインの要件に照らしてテストしました。この評価でユースケースに最適なモデルを特定し、選定後にエンベディングベクトル生成のインフラストラクチャを構築しました。エンベディングモデルをコンテナ化して Amazon Elastic Container Registry (Amazon ECR) に登録し、SageMaker 推論エンドポイントにデプロイして大規模なベクトル計算を処理しました。 検索インフラストラクチャには、セマンティック検索機能の実装に OpenSearch Service を選択しました。OpenSearch Service は、必要なベクトルストレージと、ユーザーに関連性の高い結果を提供する検索アルゴリズムの両方を備えていました。 最大の課題の 1 つは、既存の注文でセマンティック検索をサポートするために過去のデータを更新することでした。 AWS Step Functions でワークフローをオーケストレーションし、 AWS Lambda 関数でレガシーデータのベクトル生成を処理するデータ処理パイプラインを構築し、対象のすべてのレコードでセマンティック検索を提供できるようにしました。 次の図は、アーキテクチャの概要を示しています。 モデルの評価と選定 注文履歴検索では、Amazon 固有のデータで学習されたエンベディングモデルを使用しています。ドメイン固有の学習は、生成されるエンベディングベクトルがビジネスコンテキストで適切に機能し、質の高い結果を返すために不可欠です。 候補モデルの評価には、Amazon Bedrock 上の Anthropic Claude を使った LLM-as-a-judge 手法を採用しました。Anthropic Claude に、顧客の注文履歴から匿名化された商品テキストと検索フレーズを含むプロンプトを与え、関連性に基づいて商品をフィルタリングおよびランク付けしました。この結果を比較用のグラウンドトゥルースとして使用しました。 モデルの評価には標準的なランキング指標を使用しました。 Normalized Discounted Cumulative Gain (NDCG) – 理想的な順序に対するランキング品質を測定 Mean Reciprocal Rank (MRR) – 最初の関連アイテムの位置を考慮 Precision – 取得結果の精度を評価 Recall – すべての関連アイテムを取得する能力を評価 このプロセスにより最適なモデルを決定しました。 検索戦略: 顧客スコープの包括的検索 注文履歴検索には 2 つの重要な要件があります。 リクエスト元の顧客の注文履歴のみを検索する – ある顧客の注文履歴の商品が別の顧客の検索結果に表示されてはなりません。 その顧客の履歴をすべて検索する – 検索アルゴリズムが何らかの理由で評価しなかったために、顧客の検索フレーズに関連する商品が表示されないことがあってはなりません。 このアプローチでは、OpenSearch Service を使って検索クエリを発行した顧客のすべての商品を取得し、検索フレーズに対する各商品の関連性スコアを計算し、スコア順にソートして上位 K 件の結果を返します。各顧客に対して包括的な結果カバレッジを提供します。 OpenSearch Service によるベクトルストレージ 効率的なベクトルストレージと検索のために、OpenSearch Service の 2 つの機能を使用しました。 knn_vector データ型 – エンベディングベクトルを格納するための組み込みサポート。既存のドメインでもインデックスの再作成なしにこのフィールド型を追加でき、すべてのレコードに対する正確な kNN 検索が可能です。ほとんどの顧客のレコード数は正確な kNN でスケールできる範囲だったため、近似 kNN は不要でした。 スクリプトスコアリング – Painless スクリプトがサーバーサイドでベクトル類似度を計算し、クライアントの複雑さを軽減しつつ低レイテンシーを維持します。 ハイブリッド検索 ハイブリッド検索とは、レキシカル検索とセマンティック検索の結果を組み合わせ、それぞれの強みを活かすことです。OpenSearch Service のハイブリッドクエリ機能により、クライアントは単一のリクエストで両方のクエリタイプを指定でき、ハイブリッド検索の実装が簡素化されます。OpenSearch Service は両方のクエリを並列実行し、結果をマージし、サブクエリの関連性スコアを正規化し、指定されたソート順 (デフォルトは関連性スコア) で結果をソートしてからクライアントに返します。 両方の検索タイプの利点を活用できます。たとえば、顧客が orderId で検索する場合のように、検索フレーズに意味的な意味があまりないシナリオがあります。セマンティック検索はこのようなケースには適しておらず、キーワードマッチングが最適です。 ハイブリッド検索機能により、注文履歴検索の実装工数と潜在的なレイテンシー増加を抑えられました。 過去のデータの更新 インフラストラクチャのセットアップ後、新しく取り込まれるレコードは関連するエンベディングベクトルとともに永続化され、セマンティック検索をサポートします。しかし、顧客が検索する際は通常、以前に購入した商品を検索します。そのため、古いレコードにエンベディングがなければ、顧客体験の改善にはつながりません。バックフィルの方法はデータ規模に依存します。 潜在的な顧客影響を最小化するリリース 最後のステップは、問題発生時の影響を最小限に抑えながらクライアントに変更をリリースすることでした。具体的には以下の方法を採用しました。 セマンティック検索フローで一時的な問題が発生した場合、リクエスト全体を失敗させるのではなく、レキシカルのみの検索にフォールバックするよう実装する。セマンティック検索が実行されなくても、空の結果ではなくレキシカル検索の結果をクライアントに返せるようにする。 デフォルトの動作をレキシカルのみの検索とし、セマンティック検索機能が必要なクライアントはリクエストに追加フラグを渡す必要があるようにゲーティングする。これにより、該当リクエストのみでセマンティックまたはハイブリッドフローが実行される。 初期期間中は新しいフローをフィーチャーフラグの背後に配置し、重大な問題が検出された場合に完全にオフにできるようにする。 顧客体験の改善例 Rufus が注文履歴を照会して顧客の質問に答えた例を紹介します。 次のスクリーンショットは、「sustainable utensils」のクエリで木製スプーンが検出される例と、タイトルの説明に「charger」というキーワードがないウォールコネクターを含むさまざまな種類の充電器が検出される例を示しています。 次のスクリーンショットは、タイトルの説明にクエリキーワードが含まれていなくても、セマンティック検索が関連する結果を検出する例を示しています。 セマンティック検索機能の導入により、Rufus が関連商品を取得して顧客に表示できるようになりました。導入前は、こうしたクエリに対して結果を返せませんでした。 ビジネスへの影響 主なビジネス成果は以下のとおりです。 顧客体験の改善 – クエリの再現率が 10% 向上し、関連する結果を返す検索の割合が増加しました。また、過去の注文の検索に関するカスタマーサービスへの問い合わせも減少しました。 パートナー連携の成功 – Alexa と Rufus の自然言語処理能力が強化され、注文履歴クエリの解釈精度が向上しました。パートナーチームによるリランキングや後処理の必要性も軽減されました。クエリ成功率は 20% 向上し、より多くの顧客検索が少なくとも 1 つの関連商品を返すようになりました。また、結果カバレッジが 48% 向上し、レキシカル検索では見逃されていた関連する一致をセマンティック検索が一貫して検出するようになりました。 まとめ 本記事では、Amazon の注文履歴検索をセマンティック検索機能に対応させた方法を紹介しました。既存インフラストラクチャの制約の中で最先端の AI 技術を活用し、機能アップグレード中もサービスの中断を回避して SLA を維持するソリューションを開発しました。実装にはバックフィルも含まれ、通常の取り込み速度の数倍のレートで数十億のドキュメントを処理し、過去に購入された商品のエンベディングベクトルを計算しました。慎重なエンジニアリングが求められましたが、極端な負荷下でも OpenSearch Service のレジリエンシーを活用して対応しました。 この基盤を活かして、検索技術を継続的に進化させられます。エンベディングベクトルのフレームワークに改良モデルを組み込めるほか、パーソナライゼーションやマルチモーダル検索など新機能への拡張にも対応できます。 Exact k-NN search の手順に従って、正確な k-NN 検索を今すぐ始められます。OpenSearch クラスターのマネージドソリューションをお探しの場合は、 Amazon OpenSearch Service をご確認ください。 著者について Shwetabh Shwetabh は、Amazon のシニアソフトウェアエンジニアで、分散システムと機械学習に関心があります。仕事以外では、技術的な深掘りや示唆に富むノンフィクションを好む読書家です。 Harshavardhan Miryala Harshavardhan は、Amazon のソフトウェアエンジニアで、機械学習、特に情報検索と分散コンピューティングに関心があります。仕事以外では、ラケットスポーツやサッカー観戦を楽しんでいます。 Ayush Kumar Ayush は、Amazon のテックリーダーで、14 年以上の経験を持つビルダーです。Your Orders Search プロダクトをリードしています。余暇にはクリケット観戦や幼い子どもとの遊びを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。

本記事は 2026/02/23 に公開された “ Introducing Strands Labs: Get hands-on today with state-of-the-art, experimental approaches to agentic development ” を翻訳したものです。 私たちは、開発者がエージェンティック AI 開発のための実験的な最先端のアプローチを実際に試せるように設計された新たな Strands GitHub 組織である Strands Labs を紹介します。 Python と TypeScript 両方で利用可能な Strands Agents SDK は、2025 年 5 月のオープンソースリリース以降、開発者コミュニティで大きな支持を集めています。SDK は 1400 万回以上ダウンロードされており、AWS チームは新しい機能を積極的に追加しています。これには、 Steering のような実験も含まれています。これは、非常に活発な開発者コミュニティをサポートするためのものです。Strands のモデル駆動型アプローチは、プロトタイピングからエンタープライズの本番ワークロードまで、シンプルで強力かつスケーラブルであることが実証されています。Strands とモデル駆動型アプローチの詳細については、 こちら をご覧ください。 私たちは、実験を通じてイノベーションを促進し、エージェンティック開発の最前線を押し進めるために、Strands Labs を別の GitHub 組織にすることを選びました。また、Amazon 全体のすべての開発チームに Strands Labs を開放しました。これは、すべてのチームが革新的なオープンソースプロジェクトに貢献し、コミュニティからの利用とフィードバックを得られます。このモデルは、Strands SDK とその本番リリースサイクルから実験を分離して、Strands の開発者コミュニティのより速い実験、学習、成長を促進します。Strands-Labs のすべてのプロジェクトは、明確なユースケース、機能的なコード、テストとともに提供される予定です。 ローンチ時に、Strands Labs は 3 つのプロジェクトで利用可能になります。最初のプロジェクトは Robots 、2 番目のプロジェクトは Robots Sim 、そして 3 番目のプロジェクトは AI Functions です。 Robots: Robots では、AI エージェントがエッジや物理世界にどのように拡張されるかを見ていきます。ここでは、AI エージェントは情報を処理するだけでなく、私たちの周りの物理環境と相互作用します。統一された Strands Agents インターフェースを通じて、フィジカル AI エージェントは AI 機能を物理センサーやハードウェアに直接接続することで、多様なロボットを制御できます。 Robots Sim: Robots Sim は、エージェンティックロボットをシミュレートされた 3D 物理学対応の世界と統合します。これにより、物理的なロボットハードウェアを必要とせず、安全なシミュレーション環境で迅速なプロトタイピングとアルゴリズム開発が可能になります。これは、エージェント戦略の反復や Vision-Language-Action（VLA）モデルポリシーのテストに最適です。また、実環境の展開前のアプローチの検証にも適しています。 AI Functions: AI Functions では、開発者はコードの代わりに自然言語仕様を使用してエージェントを定義します。動作を検証し、実装を生成する事前・事後の条件は Python で書きます。この実験は、LLM でコードを生成する際の信頼ギャップを狭めることを目指しています。開発者の時間を意図の検証に集中させ、残りはフレームワークに委ねます。 これらの各プロジェクトがエージェンティック開発の最前線をどのように押し進めているかを以下で詳しく見ていきましょう。 Strands Robots エージェンティック AI システムは急速にデジタル世界を超えてフィジカル領域に拡大しています。ここで AI エージェントは実際の環境で知覚、推論、そして行動します。AI システムがロボティクス、自律車両、スマートインフラを通じてフィジカル世界と相互作用するにつれて、基本的な疑問が浮かび上がります：物理的なセンシングやアクチュエーションに必要なミリ秒単位の応答性を維持しながら、複雑な推論のために大規模なクラウドコンピューティングを活用するエージェントを、どのように構築すればよいのでしょうか？ Strands Robots は、オーケストレーション、インテリジェンス、そしてインフラストラクチャレイヤーを提供し、個々のエッジデバイスをエージェントと連携してフィジカル AI システムへと変換します。このプロジェクトを通じて、私たちの目標は、シンプルな API、オープンソースライブラリ、そしてマネージドサービスを通じてフィジカル AI を民主化することです。 Strands Robots は、Strands Agents の機能を拡張して、AI エージェントが物理センサーやハードウェアに接続する統一的な Strands Agents インターフェースを通じて物理ロボットを制御できるようにします。また、物理的なロボットハードウェアを必要とせずに、安全なシミュレーション環境で迅速なプロトタイピングとアルゴリズム開発を可能にします。これは、エージェント戦略の反復、VLA ポリシーのテスト、実世界への展開前のアプローチ検証に最適です。 このラボデモンストレーションでは、 SO-101 ロボットアーム が NVIDIA GR00T ビジョン言語アクションモデル（VLA）と連携して操作を処理します。VLA モデルは、単一のモデルで視覚的知覚、言語理解、そしてアクション予測を組み合わせます。GR00T はカメラ画像、ロボットの関節位置、言語命令を入力として受け取り、直接新しいターゲット関節位置を出力します。NVIDIA とのパートナーシップにより、NVIDIA GR00T を Strands Agents と統合しました。これにより、SO-101 ロボットアームを制御するデモンストレーションを&nbsp; NVIDIA Jetson エッジハードウェア上で実行しました。これは、高度な AI 機能が組み込みシステム上で直接実行できることを示しています。 さらに、私たちは Hugging Face の LeRobot と統合しました。これは、ロボットハードウェアの作業を容易にするデータとハードウェアインターフェースを提供します。LeRobot のようなハードウェア抽象化と VLA モデル（例：NVIDIA GR00T）を組み合わせることで、フィジカル世界で知覚、推論、行動するエッジ AI アプリケーションを作成できます。 この取り組みの一環として、ビルダーにとってこれをより簡単にするために、私たちは VLA モデル（例：NVIDIA GR00T）のようなハードウェアに接続するためのシンプルなインターフェースを備えた実験的な Robot クラスをリリースしました。例えば、SO-101 ロボットアームと NVIDIA GR00T VLA モデルを組み合わせて、リンゴをバスケットに拾って置くなどのタスクを実行するには、エッジデバイス上にエージェントをデプロイします。Strands Robot クラスは以下のように使用できます： from strands import Agent from strands_robots import Robot #カメラ付きロボットの作成 robot = Robot( tool_name="my_arm", robot="so101_follower", cameras={ "front": {"type": "opencv", "index_or_path": "/dev/video0", "fps": 30}, "wrist": {"type": "opencv", "index_or_path": "/dev/video2", "fps": 30} }, port="/dev/ttyACM0", data_config="so100_dualcam" ) #ロボットツール付きエージェントの作成 agent = Agent(tools=[robot]) agent("place the apple in the basket") エッジデバイス上で実行される Robot クラスは、必要に応じて LLM やその他のモデルを使用してクラウドに複雑な推論を委任できます。VLA モデルは物理的なアクションに対してミリ秒レベルの制御を提供します。しかし、複数ステップのタスクの計画や過去のパターンに基づく決定の実施など、より深い推論が必要な場合は、クラウドベースのエージェントに相談できます。 Strands Robot Sim Strands Robot Simulation は、物理的なロボットハードウェアを必要とせずにエージェンティックロボティクスの迅速なプロトタイピングのための環境を提供します。これは、Libero ベンチマーク環境、ZMQ を介した isaac-GR00T VLA ポリシーサポート、VLA プロバイダーのための拡張可能なインターフェース、MP4 ビデオとしてのシミュレーションエピソードのキャプチャ、ステータスモニタリング付きの非ブロッキングシミュレーション、依存関係不要の高速テスト、そして GR00T 推論サービス管理をサポートします。このシミュレーションプロジェクトは、最終結果を含む完全なエピソード実行と、バッチごとの視覚的フィードバック付きの反復制御の 2 つの実行モードをサポートしています。Strands Robot Simulation のモジュラー設計により、開発者はコアロジックを再構築することなく、ポリシー実装やシミュレーション環境を交換できます。制御ループはステップを順次実行し、カメラや関節センサーから観測を収集し、このデータを固定サイズのアクションホライズン内でモーターコマンドを生成するポリシーモデルに供給します。 例えば、以下の例は、strands_robots_sim から SimEnv クラスを利用して、NVIDIA GR00T によって生成されたポリシーを用いて Libero 環境内でシミュレートされたロボットを制御する方法を示しています。この例では、以下の前提条件を満たしていることを想定しています：Libero がインストールされている、GR00T 推論サービスがポート 8000 で動作している、isaac-gr00t コンテナがアクセス可能な Docker が利用可能であることです。 import asyncio import argparse import random from strands import Agent from strands_robots_sim import SimEnv, gr00t_inference def main(max_episodes=10): # シミュレーション環境の作成 sim_env = SimEnv( tool_name="my_libero_sim", env_type="libero", task_suite="libero_10", data_config="libero_10" ) # エージェントの作成 agent = Agent(tools=[sim_env, gr00t_inference]) try: # GR00T 推論の開始 result = agent.tool.gr00t_inference( action="start", checkpoint_path="/data/checkpoints/gr00t-n1.5-libero-long-posttrain", port=8000, data_config="examples.Libero.custom_data_config:LiberoDataConfig" ) async def init_sim_env(): return await sim_env.sim_env.initialize() if not asyncio.run(init_sim_env()): raise RuntimeError("シミュレーション環境の初期化に失敗しました") # タスクをランダムに選択 selected_task = random.choice(sim_env.sim_env.available_tasks) # 環境にタスク名を設定 sim_env.sim_env.set_task_name(selected_task) # 自然言語でシミュレートされたロボットを制御 agent(f"'{selected_task}' タスクを {max_episodes} エピソード実行し、エピソードあたりの最大ステップ数を 500 に設定し、ビデオを記録します") # 最終ステータスの確認 final_status = agent.tool.my_libero_sim(action="status") print(f"最終ステータス: {final_status}") except Exception as e: print(f"エラーで例外が発生しました: {e}") print("- シミュレーションの依存関係をインストール: pip install strands-robots[sim]") if __name__ == "__main__": parser = argparse.ArgumentParser(description='GR00T ポリシーで Libero シミュレーションを実行') parser.add_argument('--max-episodes', type=int, default=10, help='実行する最大エピソード数 (デフォルト: 10)') args = parser.parse_args() main(max_episodes=args.max_episodes) AI Funcions AI Functions は、コードを書く代わりに自然言語の仕様で Python 関数を書く新しい方法を導入します。@ai_function デコレータを使用して、説明と検証条件を通じて関数に何をさせたいかを定義します。AI Functions は Strands エージェントループを活用して実装を生成し、出力を検証し、検証に失敗した場合は自動的に再試行します。不明な形式のファイルからインボイスデータを読み込むことを考えてみましょう。従来のアプローチでは、ファイル形式を決定し、各形式に対して変換ロジックを書き、プロンプトを構築し、応答を解析し、検証に失敗した場合に再試行を調整する必要があります。これには通常何十行ものコードが必要で、すべてのシナリオを考慮できない場合があります。AI Functions を使用すると、望む出力を説明する小さな関数と、成功の様子を表現するバリデータ関数を書きます。LLM がファイル形式を決定し、変換コードを書き、実際の Python DataFrame オブジェクトを返します。 from ai_functions import ai_function from pandas import DataFrame, api def check_invoice_dataframe(df: DataFrame): """事後条件: DataFrame 構造を検証します。""" assert {'product_name', 'quantity', 'price', 'purchase_date'}.issubset(df.columns) assert api.types.is_integer_dtype(df['quantity']), "quantity は整数でなければなりません" assert api.types.is_float_dtype(df['price']), "price は浮動小数点数でなければなりません" assert api.types.is_datetime64_any_dtype(df['purchase_date']), "purchase_date は datetime64 でなければなりません" assert not df.duplicated(subset=['product_name', 'price', 'purchase_date']).any(), "product_name、price、purchase_date の組み合わせは一意でなければなりません" # コード実行は明示的に有効にする必要があります @ai_function( code_execution_mode="local", code_executor_additional_imports=["pandas. ", "sqlite3", "json"], post_conditions=[check_invoice_dataframe], ) def import_invoice(path: str) -&gt; DataFrame: """ ファイル {path} には購入ログが含まれています。以下の列を持つ DataFrame でそれらを抽出します: - product_name (str) - quantity (int) - price (float) - purchase_date (datetime) """ @ai_function( code_execution_mode="local", code_executor_additional_imports=["pandas. "], ) def fuzzy_merge_products(invoice: DataFrame) -&gt; DataFrame: """ 同じ製品の異なるバージョンを示す製品名を見つけ、バージョンサフィックスを削除し、 表記の揺れを統一して正規化し、正規化された名前で製品名を更新し、 同じ構造（同じ列と行）の DataFrame を返します。 """ #JSON をロードします（エージェントは JSON を検査して DataFrame にマッピングする方法を理解する必要があります） df = import_invoice('data/invoice.json') print("請求書の合計:", df['price'].sum()) #SQLite データベースをロードします。エージェントは動的にスキーマをチェックし、 $それを読み取り、目的の形式に変換するために必要なクエリを生成します) df = import_invoice('data/invoice.sqlite3') # 同じ製品のリビジョンをマージします &nbsp;df = fuzzy_merge_products(df) 今後、Strands-Labs を通じて Strands 開発者コミュニティとより多くのプロジェクトを共有し、Strands をより良いものにするためのフィードバックを楽しみにしています。 エージェンティック AI の新たなアプローチを体験し、 Strands Labs で今すぐ実験を始めましょう。 <!-- '"` --> Joy Chakraborty Joy Chakraborty は AWS Agentic AI Foundation のシニアテクニカルプログラムマネージャーです。現在、Strands Agents と AgentCore Integration プログラムを管理しています。以前は、Amazon Retail Store の AWS CloudFormation プログラムと Catalog Variation プログラムを率いていました。 Alessandro Achille Alessandro Achille は AWS Agentic AI の主任アプリケーションサイエンティストで、自律コーディングエージェント、機械学習の基礎、プライバシー、ハードウェアとソフトウェアの共同設計に取り組んでいます。 Arron Bailiss Arron Bailiss は AWS のエージェンティック AI に焦点を当てた主任エンジニアで、人工知能、機械学習、ロボティクスの交差点で働いています。彼は、ビルダーが洗練された AI 駆動型アプリケーションを作成できる開発者ツールの未来を形作るのを助けています。 Andrew Shamiya Andrew Shamiya は AWS Agentic AI のマーケティングマネージャーです。彼は開発者がエージェントシステムを選択し展開するのを助けることに焦点を当てています。以前は Twitch で Monetization Product Marketing を率いており、フリータイムには読書と絵を描くことを楽しんでいます。 Ryan Coleman Ryan Coleman は Amazon Web Services の製品マネージャーで、AI 開発者ツールとエージェントフレームワークに焦点を当てています。DevOps とオープンソースのバックグラウンドを持ち、ビルダーが大規模言語モデルの力を活用してインテリジェントでスケーラブルなソフトウェアシステムを作成するのを助けています。

2026 年 2 月 24 日、 AWS Elemental Inference が発表されました。このサービスは、オーディエンスを大規模にエンゲージするために動画のライブ配信とオンデマンド配信を自動的に変換し、最大限に高めるフルマネージド AI サービスです。リリース後は、動画コンテンツをモバイルプラットフォームとソーシャルプラットフォーム向けに最適化された縦型形式にリアルタイムで調整するために AWS Elemental Inference を使用できるようになります。 AWS Elemental Inference を使用すると、配信者やストリーマーは手作業によるポストプロダクション作業や AI の専門知識なしで TikTok、Instagram Reels、YouTube Shorts などのソーシャルプラットフォームとモバイルプラットフォームのオーディエンスにリーチできます。 今日の視聴者によるコンテンツの消費方法はほんの数年間で変化し、以前とは異なるものになっています。しかし、ほとんどの配信は従来の視聴方法向けの横型形式で制作されています。これらの配信をモバイルプラットフォーム向けの縦型形式に変換するには時間のかかる手動での編集が必要になるのが一般的であり、配信者とストリーマーが「バズる」瞬間を見逃し、視聴者をモバイルファーストな配信先に奪われる原因になっています。 試してみましょう AWS Elemental Inference では、既存のワークフローに適合する柔軟なデプロイオプションが提供されています。スタンドアロンコンソールを使用してフィードを作成する、または AWS Elemental MediaLive コンソール経由で AWS Elemental Inference を設定することが可能です。 AWS Elemental Inference の使用を開始するには、 AWS マネジメントコンソール に移動して、 AWS Elemental Inference を選択します。ダッシュボードから [フィードを作成] を選択して、AI 駆動の動画処理のためのトップレベルリソースを確立します。フィードには機能設定が含まれています。作成は、CREATING 状態で始まり、準備が整うと AVAILABLE に移行します。 フィードが作成されたら、縦型の動画クロッピング用またはクリップ生成用に出力を設定できます。クロッピングの場合は、空のフィードから開始できます。AWS Elemental Inference は、動画の仕様に基づいてクロッピングパラメータを自動的に管理します。クリップ生成の場合は、 [出力を追加] を選択し、名前 (「highlight-clips」など) を入力してから、出力タイプに [クリッピング] を選択してステータスを [有効] に設定します。 このスタンドアロンインターフェイスは、AI 駆動の動画変換を設定して管理するための効率的なエクスペリエンスを提供するため、縦型動画の作成やクリップ生成を簡単に開始できます。 別の方法として、AWS Elemental MediaLive チャネル設定内で AWS Elemental Inference を直接有効にすることもできます。この統合されたアプローチを使用して既存のライブ動画ワークフローに AI 機能を追加でき、アーキテクチャを変更する必要はありません。チャンネル設定の一部として必要な機能を有効にすると、AWS Elemental Inference が動画エンコーディングと並行して動作します。 有効にした後は、 [出力グループ] 内にあるさまざまな解像度仕様の出力で [スマートクロップ] を設定できます。 AWS Elemental MediaLive のチャンネル詳細ページには、専用の AWS Elemental Inference タブが追加されています。このタブは、AI 駆動の動画変換設定の一元的なビューを提供するもので、サービスの Amazon リソースネーム (ARN) 、データエンドポイントに加えて、有効化されている機能 (スマートクロップなど) と、それらの現在の運用ステータスといったフィード出力の詳細が表示されます。 AWS Elemental Inference の仕組み このサービスは、動画をリアルタイムで分析し、適切な最適化を適切なタイミングで自動的に適用するエージェンティック AI アプリケーションを使用しています。縦型動画クロッピングとクリップ生成の検出は個別に行われ、人間の介入を必要としないマルチステップ変換を実行して価値を引き出します。 AWS Elemental Inference は動画を分析して AI 機能を自動的に適用するため、ヒューマンインザループプロンプティングは必要ありません。ユーザーが高品質動画の制作に集中している間にコンテンツを自律的に最適化し、オーディエンス向けにパーソナライズされたコンテンツエクスペリエンスを創り出します。 AWS Elemental Inference はライブ動画と並行して AI 機能を適用するため、従来のポストプロセッシングアプローチで発生する数分間のレイテンシーが 6～10 秒に短縮されます。この「一度処理してあらゆる所で最適化」する手法では、同じ動画ストリーム上で複数の AI 機能が同時に実行されるため、機能ごとにコンテンツを再処理する必要がなくなります。 AWS Elemental Inference は AWS Elemental MediaLive とシームレスに統合されるので、既存の動画アーキテクチャを変更しなくても AI 機能を有効化できます。AWS Elemental Inference は、自動的に更新および最適化されるフルマネージド型の 基盤モデル (FM) を使用していることから、専任の AI チームや専門知識は必要ありません。 リリース時の主要機能 AWS Elemental Inference のリリース時には、以下の主要機能をご利用いただけます。 縦型動画の作成 – AI 駆動のクロッピングが、横型配信をソーシャルプラットフォームとモバイルプラットフォーム向けに最適化された縦型形式 (アスペクト比 9:16) にインテリジェントに変換します。被写体を追跡し、主要アクションを常に可視化する AWS Elemental Inference は、配信品質を維持しながら、コンテンツをモバイル視聴用に自動的に再フォーマットします。 高度なメタデータ分析を用いたクリップ生成 – ライブコンテンツからクリップを自動的に検出および抽出して、リアルタイム配信のための特別な瞬間を際立たせます。ライブ配信の場合は、サッカーやバスケットボール試合の勝敗を決めるプレーを特定するという意味になります。このため、手作業による編集が数時間から数分に短縮されます。 今後もこの分野にご注目ください。 AWS Elemental のコアサービスとのより緊密な統合や、お客様が動画コンテンツを収益化するために役立つ機能など、2026 年全体を通じてさらに多くの機能が導入される予定です。 今すぐご利用いただけます AWS Elemental Inference は、2026 年 2 月 24 日から米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (ムンバイ) の 4 つの AWS リージョン でご利用いただけます。AWS Elemental Inference は、AWS Elemental MediaLive コンソールから有効にする、または AWS Elemental MediaLive API を使用してワークフローに統合することができます。 従量制料金になっているため、お支払いいただくのは使用する機能と処理する動画の料金のみであり、初期費用や契約は必要ありません。つまり、ピークイベント中はスケールし、閑散期にはコストを最適化できます。 AWS Elemental Inference の詳細については、 AWS Elemental Inference 製品ページ をご覧ください。技術的な実装の詳細については、 AWS Elemental Inference ドキュメント を参照してください。 原文は こちら です。

本記事は 2026 年 2 月 23 日に公開された Joe Hsu, Shweta Garg, Murali Krishna Ramanathan による “ The hidden inefficiencies in AI coding (and how we find them) ” を翻訳したものです。 タスクが完了しました。コードはコンパイルされ、テストはグリーンになり、全員が次へ進みます。しかし、その「合格」したタスクが、エージェントがすぐそこにあるファイルを見つけられなかったために 17 ターンもかかっていたとしたら？絶対に成功しないシェルコマンドのパターンでリトライを繰り返していたとしたら？ ベンチマークはこれを捉えられません。合格/不合格のメトリクスは成功を確認して次へ進むだけです。私たちはより深く、エージェントが最終的にどこに到達したかだけでなく、そこに至るまでの全経路を見たいと考えました。そこで、推論と適応学習による継続的最適化のための専門システムを構築しました。社内では愛称で CORAL と呼んでいます。 なぜベンチマークだけでは不十分なのか AI コーディングエージェントは通常、合格率・トークン数・レイテンシといったベンチマークで評価されます。これらのメトリクスは 何が 起きたかを教えてくれますが、 なぜ 起きたかは教えてくれませんし、全体的なプロセスをどう改善すべきかも示してくれません。 タスクが「合格」しながらも、エージェントが壊れた検索パターンでターンを無駄にしていることがあります。また、モデルの性能が低いからではなく、ツールの説明が誤解を招くものだったために失敗することもあります。毎日何千ものエージェントインタラクションを処理している場合、手動レビューはスケールしません。 私たちには、本番環境から自動的に学習し、ベンチマークが見逃すパターンを発見できるシステムが必要でした。 エージェントの動作を分析する方法 私たちの適応学習システムは、実際の Kiro インタラクションを分析して、合格/不合格のメトリクスが見落とす非効率性を浮き彫りにします。 1 チェスプレイヤーが自分の対局を振り返るようなものです。試合後、彼らは結果を確認するだけではありません。 どこでテンポを失ったか？どのパターンがミスにつながったか？次回はどうすべきか？ と問いかけます。私たちのシステムは、これを Kiro のエージェントに対して自動的かつ大規模に行います。 そのために 軌跡ベースの学習（trajectory-based learning） を使用しています。コードがコンパイルされるかどうかを確認するだけでなく、エージェントが取った一連のアクション全体、つまりすべてのツール呼び出し、すべての意思決定ポイント、すべての回復試行を検証します。5 つのクリーンなステップで合格するタスクと、17 の雑然としたステップで合格するタスクは大きく異なり、システムはその違いを識別できます。 仕組み 毎日、私たちは同意を得たユーザーの実際の Kiro セッションを何千件もサンプリングし、LLM ベースの分析を使って検証します。各軌跡に対して、エージェントが何をしたか、何が問題だったか（あるいは正しかったか）、そしてその理由を問いかけます。 「検索結果が返ってこなかった」といった表面的な結果だけを見るのではありません。エージェントが試みたこと、どのように回復したか、どこで時間を失ったかという一連のアクション全体を追跡します。その一連の流れから、LLM が根本原因分析を行い、一般化可能な教訓を抽出します。一時的な修正ではなく、タスク全体に適用できるものです。 その教訓は、すでに学習済みのすべての内容と照合されます。新しいものか？具体的に対処できるものか？既存のインサイトと矛盾しないか？これらをパスすれば、ツール使用・ワークフローパターン・エラー回復・行動ガイダンスといったカテゴリで整理された構造化ナレッジベースに追加されます。 各インサイトはエビデンスも追跡します。あるパターンが多くの軌跡にわたって繰り返し現れると、信頼度が高まります。以前のインサイトが問題を引き起こすことが判明した場合は、修正または削除されます。ナレッジベースは静的ではなく、エージェントとツールの変化に合わせて進化します。 高信頼度のインサイトが見つかると、それを具体的な修正に変換します。ツールの説明の更新、システムプロンプトの変更、またはエージェントの動作修正です。これらはモデルの再トレーニングなしに即座にリリースされます。エージェントが改善されると、実際のセッションからより多くのデータが収集され、サイクルが続きます。 2 つの実例 発見 #1: サイレント検索失敗 ほとんどのメトリクスが見逃してしまうパターンを捉えた例を紹介します。 何が起きていたか : エージェントが *.py のようなパターンでファイルを検索し、結果がゼロになっていました。検索はツール呼び出しとして成功とマークされていた（エラーは発生しない）ため、エージェントはファイルが単純に存在しないと判断していました。しかし、ファイルは存在していました。エージェントが見つけられなかっただけです。 理由 : LLM は ripgrep のようなツールから学習しており、 *.py はデフォルトで再帰的に検索されます。しかし Code-OSS 上に構築された Kiro の検索 API では、再帰的なマッチングには **/*.py が必要です。微妙な違いですが、ツールの説明にはその点が明記されていませんでした。 コスト : grep 検索の 4 分の 1 以上がサイレントに失敗していました。検索が何も返さないとき、エージェントは諦めません。即興で対応します。ファイルを手動で読み込み、別のクエリで再試行し、ディレクトリツリーを探索します。平均して、エージェントは失敗した検索ごとに約 5 ターンの余分な作業を費やしており、本来不要だった作業をしていました。 修正 : ツールの説明に 1 行追加するだけ。 - includePattern (optional): 対象ファイルの glob パターン（例: '*.ts'） + includePattern (optional): 対象ファイルの glob パターン（例: '**/*.ts'）。再帰検索には ** を使用してください。 結果 : メトリクス 修正前 修正後 誤ったパターン率 26.10% 0.30% 影響を受けたセッション 約 23% &lt;0.3% 1 行の変更で、本番環境における誤った grep パターンを 約 99% 削減しました。 発見 #2: cd コマンドの罠 何が起きていたか : エージェントが cd src &amp;&amp; npm test のようなシェルコマンドを記述していました。これらはすべて失敗していました。Kiro の executeBash ツールは各コマンドをワークスペースルートから実行し、入力バリデーションによって cd の使用を拒否するため、 cd は永続的な効果を持ちません。このツールにはまさにこの目的のために cwd パラメータが用意されていますが、bash 呼び出しの約 4% で、モデルはツールの説明に従う代わりにトレーニングデータから学習した慣れ親しんだシェルパターンに戻ってしまっていました。 理由 : cd dir &amp;&amp; command はシェルスクリプトの一般的なパターンです。LLM はこれを何百万回も見てきました。 cwd パラメータのアプローチは馴染みがないため、エージェントは学習済みのパターンに頼ってしまいました。 コスト : 全シェル呼び出しの 3.46% がこのパターンを使用しており、18% のセッションに影響を与えていました。すべての試みが失敗し、エージェントはコマンドの再試行・代替手段の探索などで平均 2.7 ターンの回復作業を費やし、セッション内で完全に回復できないこともありました。 修正 : 制限をより強くプロンプトするだけでなく、自動修正を構築しました。エージェントが送信すると、 executeBash(command="cd src &amp;&amp; npm test") Kiro はそれを自動的に変換します。 executeBash(command="npm test", cwd="src") 実行後、正しいパターンを強化するための穏やかなリマインダーが表示されます。 &lt;system-reminder&gt; 作業ディレクトリがワークスペースルートに戻りました。別のディレクトリでコマンドを実行するには cwd パラメータを使用してください。 &lt;/system-reminder&gt; これによりエージェントは常に現在地を把握できます。作業ディレクトリを見失うことで生じる混乱や連鎖的なエラーを防ぎます。 予測される影響 : メトリクス 修正前 修正後（予測） cd コマンドの誤用によるエラー率 100% 約 0%（自動修正） 影響を受けたセッション 18% 約 0% 注目しているパターン 分析は大きな成果だけを見つけるわけではありません。積み重なると大きな影響を持つ小さなパターンを継続的に浮き彫りにします。現在積極的に調査中のものをいくつか紹介します。 ツールインタラクションパターン フォーマット後のコンテンツドリフト。 エージェントがファイルを編集した後、Prettier や Black のようなフォーマッターが空白と構造を整形します。エージェントの次の編集は、ファイルが書いた時と同じ状態であると仮定しますが、実際には変化しています。私たちの分析では、エージェントがフォローアップの変更を試みる際に「oldStr が見つからない」という失敗が繰り返し発生することが判明しました。自動フォーマットされた可能性のあるファイルに対してさらなる編集を試みる前に、エージェントが変更されたセクションを再読み込みする方法を検討しています。 散在するマルチファイル編集。 変更が複数のファイルにまたがる場合、すぐに編集に入るエージェントは他のファイルの関連コードを見落とすことがよくあります。変更を加える前にコードベース全体の変更ポイントをまずマッピングする（検索を使用して）エージェントの方が、より完全で一貫した結果を生み出すことがわかりました。クロスファイルタスクに対してこの「まず把握、次に編集（map first, edit second）」パターンを促進する方法を検討しています。 コミュニケーションパターン 承認の行き詰まり。 エージェントがリクエストに対して「了解しました」や「わかりました」と応答した後、何もしない軌跡を発見しました。ユーザーは実際の作業を進めるために再度プロンプトを送る必要があります。小さなことですが、1 ターンを無駄にし、フローを妨げます。エージェントが単に承認するだけでなく、すぐに行動するよう行動ガイダンスに取り組んでいます。 曖昧さのコスト。 最善の行動が明確化の質問をすることである場合があります。エージェントが曖昧なリクエストに対して誤った推測をし、間違ったものを構築し、作業をやり直さなければならない軌跡を発見しました。最初に 1 つの質問をするだけで、複数ターンの無駄な作業を節約できたはずです。推測するのではなく明確化を求めるようエージェントを促すタイミングと方法を調査しています。 複合効果 個々の修正は小さなものです。ツールの説明の 1 行、行動への一押し、自動修正。しかし、あなたにとってはそれらが積み重なります。5 回目ではなく 1 回目の試行で正しいファイルを見つける検索。失敗して再試行するのではなく、そのまま動作するシェルコマンド。無駄なターンが減ることで、より速い結果が得られ、エージェントが軌道を見つけるのを待つ時間が短縮されます。 これらの問題の多くを軌跡レベルの分析で迅速に修正できると確信しています。従来の評価は合格したタスクを確認して次へ進みます。このシステムは、壊れた検索パターンで 17 ターンかかった完了タスクを見て、 次回はどうすれば 5 ターンにできるか？ と問いかけます。 結果を測定するだけでなく、合格/不合格のメトリクスが見逃す非効率性を発見するために、完全な実行パスを積極的に分析しています。 継続的に改善される開発者体験 これらはすべてバックグラウンドで実行され、チームがレビューしてリリースできる修正を洗い出します。目標は、このループを将来的に完全に自動化することです。今日の Kiro エージェントは先月より優れており、来月はさらに良くなります。あなたが何かをする必要はありません。ただし、Kiro の提案にフィードバックを残したり、問題を報告したり、何かおかしいと感じたことにフラグを立てたりすると、そのシグナルが私たちの学習システムに取り込まれます。あなたの入力が Kiro をすべての人にとってよりスマートにするのに役立ちます。 上記の発見はほんの始まりに過ぎません。毎週新しいパターンを発見しており、学んだことを共有し続けます。 Kiro を使い始めて 、継続的な改善を体験してください。 1 Kiro のインタラクションの共有を オプトアウト することができます。 エンタープライズユーザー はデフォルトでオプトアウトされています。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2025/10/10 に公開された “ Transform Supply Chain Logistics with Agentic AI ” を翻訳したものです。 AI はあらゆるサプライチェーンプロセスを変革する可能性があります。予測分析、モノのインターネット（IoT）、機械学習（ML）などの既存技術は、サプライチェーンの効率性と可視性を向上させましたが、組織は依然として重大な課題に直面しています。今日のサプライチェーン実務者は、地政学的緊張から自然災害に至るまでの複雑なシナリオに対応しながら、複数のシステムに散在するデータを管理しなければなりません。これらの課題は、大きなビジネスインパクトを生み出します。例えば、複雑な組立品で 1 つの締結部品(ボルト・ナット等)が欠けているだけで、納品が数週間遅れ、重大な財務損失と顧客体験の低下を招きます。他のすべてのプロセスが完璧に機能していてもです。エージェンティック AI（サプライチェーンエージェント）は、これらの根強い課題を解決できるでしょうか？このブログでは、Amazon Web Services（AWS）プロフェッショナルサービス（ProServe）が、組織が本番運用可能なレベルのエージェンティック AI ソリューションを実装し、サプライチェーン業務変革をどのように支援しているかを説明します。 サプライチェーンにおけるビジネス価値の機会 生成 AI は、サプライチェーンに大きな影響を与えると考えられています。マッキンゼーによると、サプライチェーンの総コストは運用コストの 3〜4%分、全産業合計で 2,900 億ドルから 5,500 億ドル削減可能とされています。この可能性により、EY（アーンスト・アンド・ヤング） はサプライチェーン組織の 40% が生成 AI 技術に投資していると指摘しています。これは、企業が生成 AI の価値を認識しており、アーリーアダプターがこの技術をサプライチェーンプロセスの中核に採用し始めていることを示しています。 生成 AI は、以下のようなビジネス成果を生み出す可能性があります： 関連する洞察や文書を速く見つけ、サプライチェーン専門家の時間を定型業務から解放し、労働生産性を向上させます。 原材料の状態の可視化と基礎データへの信頼性により過剰在庫を削減し、緊急配送や航空輸送の回数を減らします。 処理の自動化と自動生成される推奨事項により意思決定プロセスを最適化し、専門知識の活用、管理業務、ステークホルダーとの調整を効率化します。 エージェンティック AI システムが協力して複雑なタスクを解決 エージェンティック AI システムとは、独立して動作し、相互作用し、動的な環境で自律的な決定を下すデジタルシステムを指します。これらのシステムは、複数のエージェントを調整し、他の AI システムと通信してタスクを効率的に遂行し、複雑な問題解決と自動化を可能にします。生成 AI はエージェンティック AI システムとエージェントの基盤を提供し、AWS では顧客は Amazon Bedrock AgentCore を利用します。論理ベースの推論と文脈理解を通じて、エージェントはアクションを計画し、他のエージェントと協力し、タスクを効率的に実行し、人間の論理と推論を模倣します。サプライチェーン実務者がしばしば複数のシステムや部門横断的なチームやパートナーを扱うため、AI エージェントを使用することで、組織はより効率的になり、価値を生み出すことができます。 モデルベース、目標ベース、学習ベース、自律型、LLM、エージェンティックエージェントなど、異なるタスクを完了するためのエージェントタイプが増えています。これらのエージェントは、異なる機能を持ち、協力して目的の結果を達成します。例えば、顧客が納品を迅速化することを要求したとします。1 つのエージェントが納品のステータスを確認し、別のエージェントが在庫を確認します。さらに、別のエージェントが迅速化テーブルとコストを確認し、最後のエージェントはすべての情報に基づいて次の推奨アクションをまとめます。これらのエージェンティック機能は、複数のデータソースを組み合わせて、内外の顧客体験を向上させます。さらに、情報をまとめて推奨を行うだけでなく、組織が許可すれば、エージェントがシステム上のデータを更新することができます。 物流における AI エージェント 物流はリアルタイムでのステータス更新の必要性、絶えず変化するビジネス環境、そして異なる形式の複数のシステムとデータソースが存在するため、課題に溢れています。多くの企業は、アラートとプロアクティブなモニタリングでこれらの課題を解決していますが、これらのアラートには文脈情報が不足し、潜在的な解決策を提供せず、問題を 1 か所で解決する事ができません。 ガイドラインとして、AI エージェント（メイン）は物流エージェント、在庫エージェント、補充エージェント、調達エージェントなどの焦点を絞ったペルソナを持つことが推奨されます。これらのエージェントは共通の目標に向かって協力します。AI エージェントチームが協力して作業する様子を図 1 に示します。焦点を絞ったペルソナは、エンドユーザーがエージェント（メイン）の担当タスクを理解しやすくします。また、ユーザーデータアクセスを制限し、エージェントが処理する必要があるデータの量を減らします。特に物流では、倉庫、品質、文書生成、補充、関税/規制コンプライアンス、調達/契約、内部・外部の顧客体験など、様々なタイプのエージェントのユースケースがあります。焦点を絞ったペルソナを定義した後、次のステップは、エージェントが解決するべき問題とデータへのアクセス方法を定義することです。以下では、物流エージェントに焦点を当てます。 図 1: 協力して作業する AI エージェントチーム AWS ProServe が A*STAR 向けに物流エージェントを作成 2024 年 9 月、AWS はシンガポール貿易産業省（MTI）と科学技術研究庁（A*STAR）が設立した 製造セクター AI センター・オブ・エクセレンス （AIMfg）の立ち上げに参加しました。これはシンガポールの国家 AI 戦略 2.0 の一環です。このコラボレーションの最初の取り組みは「物流の未来」の探求に焦点を当てており、AWS ProServe は Amazon Bedrock を活用した物流エージェントを開発しました。 先進再製造技術センター （ARTC）は A*STAR 内の研究機関です。このセンターは航空宇宙、陸上輸送、消費財、バイオメディカル製造、エネルギーの 5 つの主要分野にわたる 96 のコンソーシアムメンバーで構成されています。この組織は、次の 4 つの戦略的テーマで研究開発を推進しています： 次世代製造プロセス 自律型製造 ネットゼロ製造（脱炭素製造） 強靭なバリューチェーン Industry 5.0 の人間中心的、持続可能、強靭な生産を重視する A*STAR ARTC は、プラントチームにエージェンティック AI を提供しています。これにより、仮想 AI エージェントが以下のような機会を創出します： 計画、実行、サプライヤー協業にわたる 組織の知識を集約 し、それを組織の業務 DNA に組み込む 目標駆動型の意思決定を行い、フィードバックループを通じて自己改善し、文脈の認識を維持することで、 自律的に運用する 。 AWS ProServe と共同で、A*STAR ARTC は物流の専門家とデータ分析者向けにカスタマイズされた AI エージェントを開発しました。このインテリジェントシステムにより、サプライチェーンの実務者は以下の項目を実現することができます： リアルタイムデータを集約・統合 します。ERP（基幹業務システム）、TMS（輸送管理システム）、WMS（倉庫管理システム）、顧客向けポータルからデータを収集します。 内部および外部の問い合わせに対して即時かつ正確な回答 を提供します。これにより、手動での検索と照合の作業負荷を最大 50％ 削減します。 緊急配送コストを総物流費用の 3〜5％削減 し、逸失収益を軽減します。また、納品から配送までのサイクルを短縮します。 手戻り作業を最小化することで計画担当者の 生産性を向上させ 、例外管理、ネットワーク最適化、戦略的サプライヤー連携に集中できるようにします。 迅速で透明性の高い更新情報と予測到着時刻（ETA）のインサイトを通じて、 顧客満足度を向上 させます。 一時的な効率向上を超えて、この AI 駆動型アプローチは堅牢なデータ戦略を支え、キャパシティプランニングからアフターサービスまでのオペレーションバリューチェーン全体にわたり、物流をスマートで情報に基づく意思決定を促進する触媒として位置づけられます。 物流エージェントの構築アプローチと結果 AWS ProServe チームと A*STAR は協力して、エージェントが解決すべき複数の問題やタスクを定義しました。例えば、出荷最新の情報や影響を受ける発注書のアラートなどです。サプライチェーンの専門家は、自然言語と会話型 AI を使用してデータと対話します。これにより、問い合わせに対して変更、キャンセル、推奨を行うことができます。チームが様々な問題やタスクを定義した後、Amazon Bedrock やその他の AWS サービスを利用して物流エージェントを構築しました。 ビデオ 1：AI エージェント – 問題の定義から実行まで ビデオ 1 に示されているように、物流エージェントの導入により、チームは複数のソース（天気、出荷状況など）からより速く最新の情報を取得し、実行可能な対策についての洞察を得て、問い合わせに対する標準的な回答を受け取ることができます。例えば、ユーザーが発注書の更新を要求し、自然言語で質問を入力します。AI エージェントは質問を理解し、適切なデータソースを識別します。これには、構造化または非構造化データの分析が含まれます。これには、ERP システムや Excel スプレッドシートなどの内部データソース、または港湾のウェブサイトや航空貨物運送業者へのアプリケーション・プログラミング・インターフェース（API）接続などの外部ソースが含まれます。次に、AI エージェントは関連データにアクセスし、自然言語処理を使用して質問に答え、正確な回答を提供します。データ接続とエージェントのセットアップがどのように設定されているかの可視化については、図 2 を参照してください。 図 2：内外のデータへのアクセスを持つエージェントセットアップの例 要約すると、ロジスティクスアナリストは手動で情報を検索し、洞察を導き出したりする必要がなくなり、より戦略的なタスクに集中できるようになりました。これは一つの例ですが、サプライチェーン全体で適用可能な例は多くあり、生成 AI とサプライチェーンエージェントが組織の運営方法を変革しています。AI エージェントは洞察を即座に導き出し、エンドカスタマーの問い合わせに数秒で回答し、セルフサービスの問い合わせを可能にし、カスタマーエクスペリエンスの向上に役立ちます。 まとめ エージェンティック AI 機能は、物流の実務者が日々の業務を遂行し、エンドカスタマーエクスペリエンスを向上させる方法を変革しています。物流 AI エージェントにより、サプライチェーンチームは自然言語で対話し、組織のコンテキストを理解し、適切なデータソースを自動的に識別し、AI 推論を利用して結論を導き出したり、次の最善のアクションを推奨したりすることができます。ビジネス価値を基礎とする取り組みにより、サプライチェーンのあらゆる機能において、生産性の向上、収益の増加、速度の向上、コストの削減、無駄の排除につながる機会があります。エンドカスタマーの要求がさらに厳しくなる中で、この分野のリーダーは、価値を早期に得て、競争優位性に変えることができるでしょう。 この技術を導入する企業は、ビジネス価値をより早く実現し、すぐに競争優位性を獲得できます。AWS のお客様は、Amazon Bedrock サービス群やその他の利用可能なサービスで、今日から構築を始めることができます。変革の旅を加速させたいお客様は、 AWS プロフェッショナルサービス のアカウントエグゼクティブまたは AWS アカウントマネージャーにお問い合わせください。 物流エージェントの初期構築に貢献した Sam Gordon、さらなる開発と継続的なサポートを提供した Annie Naveh、追加のサポートとガイダンスを提供した Emily O’Kelly に特別な感謝を申し上げます。 翻訳は、ソリューションアーキテクトの山本が担当しました。 <!-- '"` --> Joe Pazak Joe Pazak は、アジア太平洋・日本（APJ）のエンドツーエンドのサプライチェーンとデジタルトランスフォーメーションを支援する責任者です。Joe は、需要計画、供給計画、生成 AI、高度な分析、物流、調達をカバーする複数の業界との大規模な変革プロジェクトから、深いサプライチェーンの専門知識をもたらします。彼は顧客を支援することを熱望しており、次世代のサプライチェーンツールとテクノロジーに移行するにつれて、大きなアイデアを考えるよう促します。Joe はシドニーを拠点としています。 Dr. Manuel Baeuml Dr. Manuel Baeuml は、ASEAN の AWS 製造・小売プラクティスをリードしています。Manuel は、スマート製造、顧客体験、サプライチェーンに注目し、製造および小売企業が重要なデジタル機能の定義・構想・実装を支援しています。過去 15 年間、Manuel はアジア太平洋とヨーロッパの業界リーダーと働いてきました。Manuel はシンガポールを拠点としています。

2026 年 2 月 16 日週、私のチームは米国サンノゼで開催された Developer Week で大勢の開発者と会ってきました。ここでは、私の同僚である Vinicius Senger が Renascent Software (リネイセントソフトウェア) に関する素晴らしい基調講演を行いました。Renascent Software とは、アプリケーションを構築して進化させる新たな手法であり、Kiro を使用することで人間と AI が 共同開発者として連携します。他の同僚は、本番環境対応の AI エージェントの構築とデプロイについて話しました。講演後も参加者全員がその場に残り、エージェントメモリ、マルチエージェントパターン、メタツール、フックに関する質疑応答を行いました。実際にエージェントを構築している開発者がこれほど多かったのは、大変興味深いと思いました。 私たちは、今後も開発者向けのサードパーティーカンファレンスで開発者の皆さんと会い、フィードバックをお聞きしたいと思っています。最も長い歴史を持ち、最大の規模を誇る Java エコシステムカンファレンス、 dev/nexus (3 月 4～6 日に米国アトランタで開催) にも参加する予定です。このカンファレンスでは、同僚の James Ward が Spring と MCP を使用した AI エージェントの構築について講演し、 Vinicius Senger と Jonathan Vogel は AI を用いて Java コードをアップグレードするための 10 のツールとヒントについて講演します。これ以外にも、皆さんが AWS とつながることができる場をご紹介していくつもりです。 2026 年 2 月 16 日週のリリース 以下は、2026 年 2 月 16 日週行われたその他の発表の一部です。 Amazon Bedrock の Claude Sonnet 4.6 モデル – Claude Sonnet 4.6 を使用できるようになりました。このモデルは、コーディング、エージェント、専門性を要する作業でフロンティアパフォーマンスを大規模に実現します。Claude Sonnet 4.6 は Opus 4.6 に迫るインテリジェンスを低コストで提供します。タスクをより迅速かつ高品質に完了することが可能になるため、大量のコーディングや知識作業のユースケースに最適です。 第 5 世代 AMD EPYC プロセッサ搭載の Amazon EC2 Hpc8a インスタンス – 最大 40% 優れたパフォーマンス、より広範なメモリ帯域幅、300 Gbps の Elastic Fabric Adapter ネットワークを提供する新しい Hpc8a の使用が可能になりました。コンピューティング集約型のシミュレーション、エンジニアリングワークロード、密結合 HPC アプリケーションを高速化できます。 カスタム Amazon Nova モデル向けの Amazon SageMaker Inference – Amazon SageMaker Inference を使用して、カスタム Nova モデルのデプロイ向けのインスタンスタイプ、自動スケーリングポリシー、同時実行設定をニーズに最も適した方法で構成できるようになりました。 仮想 Amazon EC2 インスタンスでのネストされた仮想化 – 仮想 EC2 インスタンスで KVM または Hyper-V を実行することにより、ネストされた仮想マシンを作成できます。この機能は、モバイルアプリケーション用のエミュレーターの実行、自動車用車載ハードウェアのシミュレーション、Windows ワークステーションでの Windows Subsystem for Linux の実行などのユースケースに利用できます。 Amazon Aurora でのサーバー側暗号化のデフォルト実行 – Amazon Aurora は、AWS 所有のキーを使ってサーバー側の暗号化をすべての新規データベースクラスターにデフォルトで自動適用することで、セキュリティ体制をさらに強化します。フルマネージド型のこの暗号化は、ユーザーに対して透過的なものであり、コストやパフォーマンスへの影響はありません。 AWS GovCloud (米国) リージョンでの Kiro – 政府ミッションに対応する開発チームのために Kiro を使用できるようになりました。規制対象環境で作業する開発者は、必要とされる厳格なセキュリティ管理機能を備えた Kiro のエージェンティック AI ツールを活用できるようになります。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 Introducing Agent Plugins for AWS – オープンソースの Agent Plugins for AWS が、AWS にアプリケーションのデプロイするためのスキルを備えたコーディングエージェントを提供する方法をご覧いただけます。 deploy-on-aws プラグインを使用することで、アーキテクチャ上の推奨事項、コスト見積もり、Infrastructure-as-Code をコーディングエージェントから直接生成できます。 A chat with Byron Cook on automated reasoning and trust in AI systems – AI システムがコードの生成や重要な意思決定を行うときに正しく行動していることを、自動推論を使用して確認する方法について学ぶことができます。AWS における正確性の証明に 10 年を費やしてきた Byron Cook のチームは、これらのテクニックをエージェンティックシステムに適用しています。 Best practices for deploying AWS DevOps Agent in production – 調査機能と運用効率のバランスを維持する DevOps Agent Space を設定するためのベストプラクティスを読むことができます。 Swami Sivasubramanian によると、インシデントを解決し、それらをプロアクティブに防止するフロンティアエージェントである AWS DevOps エージェントは、何千件ものエスカレーションを処理しており、Amazon 内での根本原因特定率は 86% を超えると推定されています。 AWS コミュニティからの記事 私が個人的に気に入っている AWS コミュニティの記事をご紹介します。 Everything You Need to Know About AWS for Your First Developer Job – 開発者として働く最初の 1 週間は、これまで従ってきたチュートリアルのようにはいきません。Ifeanyi Otuonye による、新しい仕事を始める人のための現実的な AWS ガイドを読みましょう。 Let an AI Agent Do Your Job Searching – 就職活動のためのキャリアページのチェックを手動で行っていませんか? AWS ヒーローである Danielle H. は、その作業をユーザーに代わって行う AI エージェントを構築しました。 Building the AWS Serverless Power for Kiro – AWS サーバーレスヒーローに認定されたことのある Gunnar Grosch は、開発ライフサイクル全体で利用できる 25 の MCP ツール、10 のステアリングガイド、構造化された意思決定ガイダンスを統合する Kiro Power を構築しました。 AWS Builder Center に参加して、コミュニティとつながり、知識を共有し、開発をサポートするコンテンツにアクセスしましょう。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit にご参加ください。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 Amazon Nova AI Hackathon – 世界中の開発者とともに、フロンティア基盤モデルを使用して革新的な生成 AI ソリューションを構築しましょう。2026 年 2 月 2 日から 3 月 16 日までの 6 週間にわたるこのチャレンジでは、エージェンティック AI、マルチモーダル理解、UI オートメーション、音声エクスペリエンスなどの 5 つのカテゴリーの賞金 40,000 USD を目指して競い合います。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスであり、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われます。今後のイベントには、 アーメダバード (2 月 28 日)、 JAWS Days in Tokyo (3 月 7 日)、 チェンナイ (3 月 7 日)、 スロバキア (3 月 11 日)、 プネ (3 月 21 日) が含まれます。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026 年 2 月 23 日週のニュースは以上です。2026 年 3 月 2 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

※&nbsp;この投稿はお客様に寄稿いただいた記事です。 開発チームに生成AIアシスタントを導入しても、「どう使えばいいかわからない」という理由で利用が広がらない——これは多くの組織が直面する課題です。 本稿では株式会社 NTTドコモ（以下、ドコモ）の主要な Web サービス提供基盤である『 POPLAR 』において、 Amazon Q Developer を個人利用から組織全体の標準ツールへと展開した実践的なアプローチをご紹介します。 一定規模の開発組織における先行事例の創出、ノウハウの体系化、標準化、そして継続的な改善まで、段階的な取り組みの全体像をお伝えします。 1. 先行利用事例の創出 POPLARでは、Amazon Q Developer の導入後も「どの場面で使うと効果があるかわからない。」という声から利用が伸び悩んでいました。この課題を解消するため、実案件を題材にした先行利用事例の創出に取り組みました。 ■ POPLARで先行事例が特に効いた理由 一定規模な開発組織であるため、“再現可能な成功例”が必要だった Software/Middleware のバージョンアップ案件は影響調査・差分分析の負荷が高く、AI効果が可視化されやすい工程構造だった 成果を共有する文化があり、成功事例が口コミのようにプロジェクト内に広がった こうした背景から、Software/Middleware のバージョンアップ案件を題材に、影響調査・設計・コーディングでAmazon Q Developerを活用しました。その結果、最大で約50%の効率化が確認されています。 図1のとおり、影響調査とコーディングで特に大きな改善が見られました。 （図1：先行開発案件の概要と効率化結果） また、図2のとおり、Amazon Q Developerに対してバージョンアップ作業の前提条件を追加して改修指示をすることで、精度向上が図れました。 （図2：プロンプト活用例） この様な成功事例を明確に示すことで、開発者の信頼向上およびプロジェクト全体での利用拡大が進むきっかけとなりました。 2.プロジェクト全体へのノウハウ共有と利用促進 先行事例で得た知見をプロジェクト全体へ展開するため、Amazon Q Developer を活用する際に必要な情報を体系化し、Amazon Q Developer という新しいツールを使うことに対する心理的障壁を下げる取り組みを進めました。 具体的には以下を整備しています。 (1) Amazon Q Developer 利用ガイドライン 機能概要、開発フェーズ別の活用パターン、利用時の制約事項、アカウント申請フローなど、AmazonQ Developer を利用するための各種ノウハウを整理し、開発チーム全体へ公開。 (2) 環境設定マニュアル（VS Code／サーバ） VS Code のセットアップ、IAM Identity Center 設定、既存リポジトリの取得方法など、利用開始に必要な手順をマニュアル化。 (3) コンテキスト活用ガイド プロジェクト固有のルールや制約事項をコンテキストとして整理し、VS Code に配布。プロジェクト特有の情報を踏まえた高精度な回答を得られる環境を整備。 (4) ユースケース別プロンプト集 実際の利用者からフィードバックを収集し、用途別のプロンプト集として体系化し公開。 説明会やデモの実施により、初めてのメンバーでも迷わず利用開始できる状態を構築しています。 3. Amazon Q Developer のさらなる利用促進に向けた取り組み 一定の利用拡大が進んだ後も、さらなる活用促進のために次の取り組みを実施しております。 （1）開発利用の標準化（生成AI開発ガイドライン） Amazon Q Developer の利用方法を工程別に整理し、生成AI開発ガイドラインとして文書化しました。 ガイドライン適用案件では最大約30%の効率化を達成しています。 また、図3のとおり、工数削減と品質安定を再現可能とする取り組みも進めています。 （図3：標準化効果） （2）MCP Server 連携環境の整備 図4のとおり、複数のMCP Serverと連携できるVS Code環境を整備し、共通設定ファイルや連携アプリを配布しました （図4：MCP Server連携構成） なお、POPLARプロジェクトでは以下のMCP Serverを活用しています。 Core MCP Server AWS Documentation MCP Server AWS CDK MCP Server AWS Knowledge MCP Server POPLAR Atlassian MCP （3）利用状況の可視化と個別フォロー 利用ログを用いて利用状況をダッシュボードにて可視化し、プロジェクトに所属する全メンバーの日次でのユーザ単位の「使用状況(チャット・コード生成行数・サジェスチョン数)」を確認出来る様にしました。また、その情報を活用し、利用が進まないメンバーには個別フォローを実施しています。 4. まとめ 本記事では、POPLAR における Amazon Q Developer の活用をプロジェクト全体へ拡げるための取り組みをご紹介しました。 先行事例の創出から始め、以下の通り段階的に取り組むことで生産性向上と利用拡大を実現しました。 STEP1　小さな成功で信頼を獲得（価値証明） STEP2　ノウハウを体系化して展開（情報共有） STEP3　組織の仕組みとして定着（標準化） 今回の取り組みが Amazon Q Developer を活用した開発の参考になれば幸いです。 今後も Kiro を活用した仕様駆動型開発などと組み合わせ、AWS が提供する生成AIアシスタントを最大限活用しながら、POPLAR のさらなる進化に取り組んでいきます。 第1回：NTT ドコモの Web サービス基盤『 POPLAR 』開発における Amazon Q Developer 活用はこちら 著者について 株式会社 NTTドコモ 情報システム部 デジタルデザイン担当 担当部長 深谷 治男 ( Haruo Fukaya ) 担当課長 小柴 辰久 ( Tatsuhisa Koshiba ) 主査 川口 晃平 ( Kouhei Kawaguchi )

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いきなりですが、 AWS Builder Center はご存じですか？ハンズオンワークショップで生成 AI やサーバーレスアーキテクチャを実践したり、コード例やチュートリアルで具体的な実装方法を学んだり、AWS Heroes や Community Buildersと繋がって知見を共有したり。さらに、AWS 製品チームへのフィードバックや機能提案もできます。技術記事、ユーザーグループ、実践的なラボまで、ビルダーに必要なリソースが一箇所に集約されている、それが AWS Builder Center です！今週の週刊 AWS で気になったトピックがあれば、Builder Center でさらなる知識の深掘りもいかがですか？ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年2月16日週の主要なアップデート 2/16(月) Amazon EC2 がネスト仮想化をサポート Amazon EC2 でネスト仮想化がサポートされ、EC2 インスタンス内に更に仮想環境を作成できるようになりました。従来はベアメタルインスタンスでしかネスト仮想マシンを作成できませんでしたが、通常の EC2 インスタンス上でも KVM や Hyper-V を実行可能になります。モバイルアプリのエミュレーター実行や自動車の車載システムシミュレーション、Windows 環境での Linux 実行など、より柔軟な仮想環境構築が可能です。 AWS Backup が AWS 上の SAP HANA に対する PrivateLink サポートを発表 AWS Backup が SAP HANA システム向けに AWS PrivateLink をサポート開始しました。これまで SAP HANA のアプリケーション通信は PrivateLink を使ってプライベートネットワーク経由にできましたが、バックアップ通信はパブリックエンドポイントを経由する必要がありました。今回のアップデートで、バックアップトラフィックもプライベートネットワーク経由でルーティングできるようになり、インターネットを経由しない完全にプライベートな通信が実現します。金融、医療、政府機関など規制の厳しい業界では HIPAA や PCI DSS などのコンプライアンス要件でプライベート通信が求められることが多く、このアップデートによりエンドツーエンドでプライベートなデータ保護戦略を実装できます。詳細は こちらのドキュメントをご参照ください。 Amazon DocumentDB 5.0 での長期サポート (LTS) の発表 Amazon DocumentDB 5.0 で長期サポート (LTS) の提供が開始されました。LTS 版ではデータベースのアップグレード頻度とメンテナンス負荷を大幅に軽減できます。新機能の追加は行わず、重要な安定性とセキュリティパッチのみを適用するため、本番環境での安定運用を重視する企業にとって理想的な選択肢です。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora が保存時のサーバーサイド暗号化をサポート Amazon Aurora で新しく作成するデータベースクラスターに対して、デフォルトで暗号化が自動適用されるようになりました。これまで手動で設定が必要だった暗号化が、今後は新規作成時に自動で有効になります。AWS が管理する暗号化キーを使用するため、コストやパフォーマンスへの影響はありません。セキュリティ設定の手間を省きつつ、データ保護を強化できるのがメリットです。詳細は こちらのドキュメントをご参照ください。 AWS Glue 5.1 が 18 の追加リージョンで利用可能に AWS Glue 5.1 が新たに大阪リージョンを含む 18 のリージョンで利用可能になりました。AWS Glue はサーバーレスなデータ統合サービスで、複数のデータソースからデータを発見・準備・移動・統合できます。AWS Glue 5.1 では Apache Spark 3.5.6 や Python 3.11 への対応により性能とセキュリティが向上し、これまで読み取り専用だった Lake Formation のアクセス制御が書き込み操作にも対応しています。 2/17(火) Claude Sonnet 4.6 が Amazon Bedrock で利用可能に Amazon Bedrock で Claude Sonnet 4.6 が利用可能になりました。このモデルは従来の Claude Sonnet 4.5 から大幅にアップグレードされ、コーディングやエージェント機能、ビジネス業務において優秀な性能を発揮します。企業では表計算作成、コンプライアンス確認、データ要約などの専門的な業務に活用でき、高品質な結果を効率的に得られます。詳細は こちらのリリース記事をご参照ください。 Amazon Connect でエージェントの休暇申請がドラフトスケジュールに含まれるようになりました Amazon Connect でエージェントの休暇申請がドラフトスケジュールに含まれるようになりました。これまでは、特定の日にエージェントがスケジュールされていない理由を確認するのに、別の休暇スケジュールを確認して再調整する必要がありました。このアップデートにより、例えば来月のスケジュール作成時に、普段月〜金で働くエージェントが最初の週にいない理由が休暇取得だとすぐに判明します。スケジュール管理者は公開前にカバレッジ不足を素早く特定し調整できるため、より効率的な運用が可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora MySQL 3.12 (MySQL 8.0.44 互換) が一般提供開始 Amazon Aurora MySQL の最新バージョン 3.12 が提供開始されました。MySQL 8.0.44 に対応し、セキュリティ強化やバグ修正に加え、可用性が向上しています。既存のデータベースから手動アップグレードまたは自動更新設定が可能で、ダウンタイムを最小限に抑えながら最新機能を利用できます。高いパフォーマンスと安定性を求めるアプリケーションに最適で、全ての Aurora MySQL 対応リージョンで利用可能です。 2/18(水) Amazon OpenSearch Service が Graviton4 (c8g、m8g、r8g) インスタンスのサポートを拡張 Amazon OpenSearch Service で最新の Graviton4 ベース EC2 インスタンス (c8g, m8g, r8g, r8gd) のサポートが拡張されました。Graviton4 は従来の Graviton3 と比べて最大 30% のパフォーマンス向上を実現し、コンピュート集約型、汎用、メモリ集約型ワークロードで最高の価格性能比を提供します。大阪リージョンなど 12 の新しいリージョンでも利用可能となり、より幅広い地域でコスト効率の高い検索・分析処理が可能になります。詳細は こちらの Blog 記事をご参照ください。 Amazon Aurora DSQL が Kiro powers と AI エージェントスキルと統合 Amazon Aurora DSQL が Kiro powers と AI エージェントスキルと統合し、AI エージェントの支援でデータベースアプリケーション開発が大幅に効率化されました。これまで手動で行っていたスキーマ設計や性能最適化を AI がサポートし、開発者は事前知識がなくても安心して Aurora DSQL を活用できます。Kiro IDE でワンクリックインストールでき、Claude や Cursor など主要な AI コーディングエージェントで利用可能です。 AWS Certificate Manager が新しいガイドラインに準拠するため、デフォルトの証明書有効期間を短縮 AWS Certificate Manager (ACM) でパブリック証明書の有効期限が 395 日から 198 日に短縮されました。これは 2026 年のセキュリティ標準強化に先立つ対応で、証明書の更新頻度が上がることでセキュリティが向上します。既存証明書はそのまま利用でき、自動更新も継続されるため追加作業は不要です。さらに、エクスポート可能証明書の価格が約半額に下がり (15 ドル→7 ドル)、コスト削減にもつながります。詳細は こちらのドキュメントをご参照ください。 2/19(木) Amazon EC2 M8i-flex インスタンスが東京リージョンで利用可能に Amazon EC2 M8i-flex インスタンスが東京、ソウル、シンガポール、マレーシア、フランクフルト、カナダ中央リージョンで利用開始されました。Intel Xeon 6 プロセッサを搭載し、従来の M7i-flex と比較して 15% のコストパフォーマンス向上と 2.5 倍のメモリ帯域幅を実現します。PostgreSQL で 30%、NGINX で 60%、AI 深層学習で 40% の性能向上が期待でき、Web アプリケーションやマイクロサービスに最適です。詳細は こちらの Blog 記事をご参照ください。 Amazon EC2 G7e インスタンスが東京リージョンで利用可能に Amazon EC2 G7e インスタンスが東京リージョンで利用開始となりました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、従来の G6e と比較して最大 2.3 倍の推論性能を実現します。大規模言語モデル (LLM) や生成 AI モデルの展開に最適で、最大 8 GPU と GPU あたり 96 GB のメモリを提供します。グラフィックス処理と AI 処理の両方が必要な空間コンピューティングワークロードで最高のパフォーマンスを発揮し、マルチモーダル AI アプリケーションの構築がより効率的になります。 2/20(金) Amazon RDS for Oracle が 2026 年 1 月リリース更新と Spatial パッチバンドルをサポート Amazon RDS for Oracle が 2026 年 1 月のリリースアップデート (RU) に対応しました。Oracle Database 19c と 21c 向けのセキュリティ修正が含まれており、データベースの安全性が向上します。また 19c 向けには Spatial Patch Bundle も提供され、地理空間データを扱う Oracle Spatial 機能のパフォーマンスと信頼性が改善されます。メンテナンス時間中の自動アップグレードも設定でき、運用負荷の軽減が可能です。詳細は こちらのドキュメントをご参照ください。 2 月もあと１週間です！このままだんだん暖かくなるといいですね！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は 2026 年 2 月 23 日 に公開された「 Implement a data mesh pattern in Amazon SageMaker Catalog without changing applications 」を翻訳したものです。 Amazon SageMaker Unified Studio でプロジェクトを作成する際、プロジェクトプロファイルを選択してプロビジョニングするリソースとツールを定義します。Amazon SageMaker Catalog はこれらを使ってデータメッシュパターンを実装します。ただし、プロジェクトと共にプロビジョニングされるリソースを利用したくない場合もあります。たとえば、既存のアプリケーションやデータプロダクトに変更を加えたくない場合などです。 本記事では、現在のデータリポジトリとコンシューマーアプリケーションを変更せずに Amazon SageMaker Catalog でデータメッシュパターンを実装する方法を説明します。 ソリューション概要 本記事では、Amazon SageMaker Catalog 導入前に存在するデータプロデューサーとデータコンシューマーに基づくシナリオをシミュレートします。サンプルデータセットを既存データとしてみなし、AWS Lambda 関数は既存アプリケーションを代替します。実際のデータとワークロードでも同様の構成を利用することが可能です。 次の図は、ソリューションアーキテクチャの主要な構成を示しています。プロデューサーアカウントの Amazon Simple Storage Service (Amazon S3) バケットと AWS Glue Data Catalog で既存のデータリポジトリを表しています。コンシューマーアカウントの Lambda 関数で既存のコンシューマーアプリケーションです。 アーキテクチャで表現されている主要な構成要素は次のとおりです。 Amazon SageMaker ドメインの一部として、プロデューサープロジェクト (プロデューサーアカウント) とコンシューマープロジェクト (コンシューマーアカウント) を作成します。他のリソースとともに、関連付けられたアカウントの各プロジェクトにプロジェクト AWS Identity and Access Management (IAM) ロールが作成されます。 プロデューサーアカウントで、AWS Lake Formation でプロデューサープロジェクトの IAM ロールに既存のデータアセットへのアクセス許可を付与します。 プロデューサープロジェクトから Amazon SageMaker Catalog にデータアセットを公開します。 コンシューマープロジェクトからデータアセットをサブスクライブします。 コンシューマーアカウントで、サブスクライブしたデータアセットにアクセスするために、Lambda 関数がコンシューマープロジェクトの IAM ロールを引き受けるよう設定します。 本アーキテクチャは、次の Amazon Web Services (AWS) のサービスと機能に基づいています。 Amazon SageMaker Catalog でデータと AI を安全に検出、ガバナンス、コラボレーションできます。 Amazon SageMaker Unified Studio はデータを検出して構築するための単一のデータと AI 開発環境です。Amazon SageMaker Unified Studio プロジェクトはデータと AI タスクを実行するための共同作業の境界です。 Amazon SageMaker のレイクハウスアーキテクチャは Apache Iceberg と完全に互換性があります。Amazon S3 データレイク、Amazon Redshift データウェアハウス、サードパーティおよびフェデレーテッドデータソース全体でデータを統合します。 AWS Lake Formation で分析と機械学習のためにデータを一元的にガバナンス、保護、共有できます。 AWS Glue Data Catalog は、データアセットの永続的なメタデータストアです。テーブル定義、ジョブ定義、スキーマ、その他の制御情報が含まれており、AWS Glue 環境の管理に役立ちます。 Amazon S3 は業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを備えたオブジェクトストレージサービスです。 リソースのセットアップ このセクションでは、ソリューションに必要なリソースと設定を準備します。 3 つの AWS アカウント このソリューションを実行するには 3 つの AWS アカウントが必要で、AWS Organizations の同じ組織に属している必要があります。 プロデューサーアカウント – 公開するデータアセットをホストします コンシューマーアカウント – プロデューサーアカウントから公開されたデータを消費するアプリケーションをホストします ガバナンスアカウント – Amazon SageMaker Unified Studio ドメインを設定する場所です 各アカウントには、2 つの異なるアベイラビリティーゾーンに少なくとも 2 つのプライベートサブネットを持つ Amazon Virtual Private Cloud (Amazon VPC) が必要です。手順については、「 VPC とその他の VPC リソースを作成する 」を参照してください。このソリューションを適用する予定のリージョンで両方の VPC を作成してください。 この例では、独立したガバナンスアカウントを利用していますが、Amazon SageMaker はプロデューサーアカウントまたはコンシューマーアカウントで設定および管理できるため、厳密には必須ではありません。3 つのアカウントを用意できないケースでも、本記事を使用して、現在のデータリポジトリとコンシューマーアプリケーションを変更せずに Amazon SageMaker Catalog でデータメッシュパターンを実装するために必要な主要な設定を理解できます。 プロデューサーアカウントでデータリポジトリを作成する まず、次の手順に従ってサンプルデータセットを作成します。 テキストエディタを開きます。 新しいファイルに次のテキストを貼り付けます。 name,stars oak,3 maple,2 birch,3 willow,4 pine,5 mango,1 neem,2 banyan,5 eucalyptus,3 teak,2 ファイルを trees.csv として保存します。これがサンプルデータファイルです。 サンプルデータセットを作成したら、プロデューサーアカウントに S3 バケットと AWS Glue データベースを作成します。これがデータリポジトリです。 プロデューサーアカウントで S3 バケットを作成し、 trees.csv ファイルをアップロードします。 プロデューサーアカウントで S3 コンソールにアクセスします。 S3 バケットを作成します。手順については、「 汎用バケットの作成 」を参照してください。 作成した trees.csv サンプルデータファイルを S3 バケットにアップロードします。手順については、「 オブジェクトのアップロード 」を参照してください。 プロデューサーアカウントで AWS Glue データベースとテーブルを作成します。 プロデューサーアカウントで Glue コンソールにアクセスします。 ナビゲーションペインの Data Catalog で、 Databases を選択します。 Add database を選択します。 Name に collections と入力します。 Description に This database contains collections of statistics for natural resources と入力します。 Create database を選択します。 ナビゲーションペインの Data Catalog で、 Tables を選択します。 Add table を選択します。 テーブル作成のガイド付き手順で、 Step 1: Set table properties に次の入力を行います。 Name に trees と入力します。 Database で collections を選択します。 Description に This table captures ratings data related to the characteristics of various tree species と入力します。 Table format で Standard AWS Glue table (default) を選択します。 Select the type of source で S3 を選択します。 Data location is specified in で my account を選択します。 Include path に s3://&lt;bucket-name&gt;/&lt;prefix&gt;/ と入力します。 &lt;bucket-name&gt; は前の手順で作成した S3 バケットの名前、 &lt;prefix&gt; はアップロードした trees.csv ファイルのオプションのプレフィックスです。 Data format で CSV を選択します。 Delimeter で Comma (,) を選択します。 Next を選択します。 Step 2: Choose or define schema で次のように入力します。 Schema で Define or upload a schema を選択します。 Edit schema as JSON を選択し、ポップアップに次のスキーマを入力します。 [ { "Name": "name", "Type": "string", "Parameters": {} }, { "Name": "stars", "Type": "string", "Parameters": {} } ] Save を選択します。 Next を選択します。 Create を選択します。 コンシューマーアカウントで Lambda 関数を作成する コンシューマーアカウントで Lambda 関数を作成します。データコンシューマーアプリケーションをシミュレートします。まず、コンシューマーアカウントで Lambda 関数に割り当てる IAM ポリシーと IAM ロールを作成します。 コンシューマーアカウントで IAM コンソールにアクセスします。 次のポリシーを使用して IAM ポリシーを作成し、 smus_consumer_athena_execution という名前を付けます。プレースホルダー &lt;AWS_Region&gt; と &lt;AWS_account_ID_number&gt; をリージョンとコンシューマーアカウント ID 番号に置き換えてください。 &lt;workgroup_id&gt; プレースホルダーは後で置き換えます。IAM ポリシー作成の手順については、「 IAM ポリシーの作成 (コンソール) 」を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AthenaExecution", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:GetQueryResults" ], "Effect": "Allow", "Resource": "arn:aws:athena:&lt;AWS_Region&gt;:&lt;AWS_account_ID_number&gt;:workgroup/&lt;workgroup_id&gt;" } ] } AWS Lambda サービス用の IAM ロールを作成し、 smus_consumer_lambda という名前を付けます。AWS マネージドアクセス許可 AWSLambdaBasicExecutionRole と、作成したばかりの smus_consumer_athena_execution という名前のアクセス許可を割り当てます。手順については、「 AWS サービスにアクセス許可を委任するロールの作成 」を参照してください。 Lambda 関数の IAM ロールが配置されたら、コンシューマーアカウントで Lambda 関数を作成できます。 コンシューマーアカウントで Lambda コンソールにアクセスします。 ナビゲーションペインで Functions を選択します。 Create function を選択し、次の情報を入力します。 Function name に consumer_function と入力します。 Runtime で Python 3.14 を選択します。 Change default execution role セクションを展開します。 Execution role で Use an existing role を選択します。 Existing role で smus_consumer_lambda を選択します。 Create function を選択します。 Code タブの Code source で、既存のコードを次のコードに置き換えます。 import boto3 import time sts_client = boto3.client('sts') role_arn = "&lt;role_arn&gt;" session_name = "AthenaQuerySession" catalog = "AwsDataCatalog" database = "&lt;database_name&gt;" workgroup = "&lt;workgroup_id&gt;" query = "select * from "+catalog+"."+database+".trees" def lambda_handler(event, context): # Assume SageMaker Unified Studio project role assumed_role_object = sts_client.assume_role( RoleArn=role_arn, RoleSessionName=session_name ) # Get temporary credentials credentials = assumed_role_object['Credentials'] # Create Athena client using temporary credentials athena = boto3.client( 'athena', aws_access_key_id=credentials['AccessKeyId'], aws_secret_access_key=credentials['SecretAccessKey'], aws_session_token=credentials['SessionToken'], region_name='eu-west-1' ) # Execute Athena Query response = athena.start_query_execution( QueryString=query, QueryExecutionContext={ 'Database': database, 'Catalog': catalog }, WorkGroup=workgroup ) query_execution_id = response['QueryExecutionId'] # Polling with exponential backoff wait_time = 0.25 # Start with 0.25 seconds max_wait = 8 # Maximum wait time of 8 seconds while True: result = athena.get_query_execution(QueryExecutionId=query_execution_id) state = result['QueryExecution']['Status']['State'] if state in ['FAILED', 'CANCELLED']: raise Exception(f"Query {state}") elif state == 'SUCCEEDED': break elif state in ['QUEUED', 'RUNNING']: time.sleep(wait_time) wait_time = min(wait_time * 2, max_wait) # Double wait time, cap at max_wait # Retrieve results results = athena.get_query_results(QueryExecutionId=query_execution_id) return results Deploy を選択します。 Lambda 関数に提供されたコードには、後で必要な情報を入手した後に置き換えるプレースホルダーがいくつか含まれています。プレースホルダーをまだ置き換えていないので、この時点では Lambda 関数をテストしないでください。 管理者アクセス権を持つユーザーを作成する Amazon SageMaker Unified Studio は、AWS IAM Identity Center ベースのドメインと IAM ベースのドメインという 2 つの異なるドメインタイプをサポートしています。本記事の執筆時点では、IAM Identity Center ベースのドメインのみが複数アカウントの関連付けをサポートしているため、本記事では IAM Identity Center を必要とするこのタイプのドメインを使用します。 ガバナンスアカウントで、IAM Identity Center を有効にし、Amazon SageMaker Unified Studio ドメインを作成および管理する管理ユーザーを作成します。管理者アクセス権を持つユーザーを作成します。 ガバナンスアカウントで IAM Identity Center を有効にします。手順については、「 IAM Identity Center の有効化 」を参照してください。 ガバナンスアカウントの IAM Identity Center で、ユーザーに管理者アクセス権を付与します。IAM Identity Center ディレクトリを ID ソースとして使用するチュートリアルについては、「 デフォルトの IAM Identity Center ディレクトリでユーザーアクセスを設定する 」を参照してください。 管理者アクセス権を持つユーザーとしてサインインします。 IAM Identity Center ユーザーでサインインするには、IAM Identity Center ユーザーを作成したときにメールアドレスに送信されたサインイン URL を使用します。IAM Identity Center ユーザーを使用したサインインのヘルプについては、「 AWS アクセスポータルにサインインする 」を参照してください。 SageMaker Unified Studio ドメインを作成する ガバナンスアカウントで Amazon SageMaker Unified Studio ドメインを作成するには、「 Amazon SageMaker Unified Studio ドメインの作成 – クイックセットアップ 」を参照してください。 ドメインが作成されたら、Amazon SageMaker Unified Studio ポータル (Web アプリケーション) に移動できます。ポータルでは分析と AI のためにデータと設定されたツールを使用できます。後で使用するため、Amazon SageMaker Unified Studio ポータルの URL を保存してください。 ソリューションの手順 前提条件が整ったので、次の 10 個の手順でソリューションを実装できます。 プロデューサーアカウントとコンシューマーアカウントを Amazon SageMaker Unified Studio ドメインに関連付ける まず、プロデューサーアカウントとコンシューマーアカウントを新しく作成した Amazon SageMaker Unified Studio ドメインに関連付けます。プロデューサーアカウントとコンシューマーアカウントをドメインに関連付ける際は、 AWS RAM share managed permission セクションで IAM users and roles can access APIs and IAM users can log in to Amazon SageMaker Unified Studio を選択してください。ステップバイステップの手順については、「 Amazon SageMaker Unified Studio の関連アカウント 」を参照してください。AWS アカウントが同じ組織に属している場合、関連付けリクエストは自動的に承認されます。ただし、AWS アカウントが同じ組織に属していない場合は、ガバナンスアカウントで他の AWS アカウントとの関連付けをリクエストし、プロデューサーアカウントとコンシューマーアカウントの両方で関連付けリクエストを承認します。 2 つのプロジェクトプロファイルを作成する 次に、プロデューサープロジェクト用とコンシューマープロジェクト用の 2 つのプロジェクトプロファイルを作成します。 Amazon SageMaker Unified Studio では、プロジェクトプロファイルは Amazon SageMaker ドメイン内のプロジェクトの上位テンプレートを定義します。プロジェクトプロファイルは、プロジェクトリソースの作成に使用される再利用可能な AWS CloudFormation テンプレートを提供するブループリントのコレクションです。 プロジェクトプロファイルは特定の AWS アカウントに関連付けられます。つまり、プロジェクトが作成されると、プロジェクトプロファイルにリストされているブループリントが関連付けられた AWS アカウントにデプロイされます。プロジェクトプロファイルを使用するには、プロジェクトプロファイルに関連付けられた AWS アカウントでブループリントを有効にする必要があります。 プロデューサープロジェクトプロファイルを作成する プロデューサーアカウントに関連付けられたプロデューサープロジェクトプロファイルを作成します。このプロジェクトプロファイルでプロデューサープロジェクトを作成します。このプロファイルには、IAM ユーザーロールやセキュリティグループなどのプロジェクトリソースを作成する Tooling ブループリントがデフォルトで含まれています。 プロジェクトプロファイルを作成する前に、次の手順を使用してプロデューサーアカウントで Tooling ブループリントを有効にします。 プロデューサーアカウントで SageMaker コンソールにアクセスします。 ナビゲーションペインで Associated domains を選択します。 セットアップ中に作成したドメインを選択します。 Blueprints タブで、 Tooling blueprint セクションの Enable を選択します。次の画像を参照してください。 Virtual private cloud (VPC) でアカウントの VPC を選択します。 Subnets で、異なるアベイラビリティーゾーンの少なくとも 2 つのサブネットを選択します。 Enable blueprint を選択します。 ガバナンスアカウントでプロジェクトプロファイルの作成に進みます。 ガバナンスアカウントで SageMaker コンソールにアクセスします。 ナビゲーションペインで Domains を選択します。 前提条件の一部として作成したドメインを選択します。 Project profiles タブで Create を選択し、次の情報を入力します。 Project profile name に producer-project-profile と入力します。 Project profile creation options で Custom create を選択します。 Blueprints でブループリントを選択しないでください。 Tooling ブループリントはすべてのプロジェクトプロファイルにデフォルトで含まれているためです。 Account で Provide an account ID を選択します。 Account ID にプロデューサーアカウント ID を入力します。 Region で Provide region name を選択し、作業しているリージョンを選択します。 Authorization で Allow all users and groups を選択します。 Project profile readiness で Enable project profile on creation を選択します。 Create project profile を選択します。 コンシューマープロジェクトプロファイルを作成する コンシューマープロジェクトプロファイルも作成し、コンシューマーアカウントに関連付けます。このプロファイルでコンシューマープロジェクトを作成します。コンシューマープロジェクトプロファイルには、データ管理用の AWS Glue データベースとクエリ用の Amazon Athena ワークグループを備えたレイクハウス環境を作成するために必要な LakeHouseDatabase ブループリントが含まれています。 Tooling ブループリントはプロジェクトプロファイルにデフォルトで含まれています。 プロジェクトプロファイルを作成する前に、コンシューマーアカウントで Tooling と LakeHouseDatabase ブループリントを有効にします。 コンシューマーアカウントで SageMaker コンソールにアクセスします。 ナビゲーションペインで Associated domains を選択します。 前提条件の一部として作成したドメインを選択します。 Blueprints タブで、 Tooling blueprint セクションの Enable を選択します。 Virtual private cloud (VPC) でアカウントの VPC を選択します。 Subnets で、異なるアベイラビリティーゾーンの少なくとも 2 つのサブネットを選択します。 Enable blueprint を選択します。 ナビゲーションペインで Associated domains を選択します。 前提条件の一部として作成したドメインを選択します。 Blueprints タブで LakeHouseDatabase ブループリントを選択します。 Enable を選択します。 Enable blueprint を選択します。 コンシューマーアカウントでブループリントが有効になったら、プロジェクトプロファイルの作成に進むことができます。 ガバナンスアカウントで SageMaker コンソールにアクセスします。 ナビゲーションペインで Domains を選択します。 前提条件の一部として作成したドメインを選択します。 Project profiles タブで Create を選択し、次の情報を入力します。 Project profile name に consumer-project-profile と入力します。 Project profile creation options で Custom create を選択します。 Blueprints で LakeHouseDatabase を選択します。 Account で Provide an account ID を選択します。 Account ID にコンシューマーアカウント ID を入力します。 Region で Provide region name を選択し、作業しているリージョンを選択します。 Authorization で Allow all users and groups を選択します。 Project profile readiness で Enable project profile on creation を選択します。 Create project profile を選択します。 SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する Amazon SageMaker Unified Studio では、プロジェクトはドメイン内の境界であり、他のユーザーと協力してビジネスユースケースに取り組むことができます。プロジェクトでは、データとリソースを作成して共有できます。Amazon SageMaker Unified Studio でプロデューサープロジェクトとコンシューマープロジェクトを作成するには、次の手順を使用します。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択します。 Create project を選択し、次の情報を入力します。 Project name に Producer と入力します。 Project profile で producer-project-profile を選択します。 Continue を選択します。 Continue を選択します。 Create project を選択します。 Producer プロジェクトを作成したら、 Project overview に表示される Project role ARN をテキストファイルにメモします。次の画像を参照してください。プロジェクトロール名は、プロジェクトロール Amazon Resource Name (ARN) の arn:aws:iam::&lt;account_ID&gt;:role/ に続く文字列です。プロジェクトロール名と ARN の両方を後で使用します。 前の手順を繰り返して Consumer プロジェクトを作成します。 Project name に Consumer と入力し、 Project profile で consumer-project-profile を選択してください。作成後、 Project role ARN をテキストファイルにメモします。プロジェクトロール名は、プロジェクトロール ARN の arn:aws:iam::&lt;account_ID&gt;:role/ に続く文字列です。プロジェクトロール名と ARN の両方を後で使用します。 プロデューサーアカウントから独自データを持ち込む Amazon SageMaker Unified Studio の Producer プロジェクトに独自のデータを持ち込み(取り込み)ます。AWS はこれを実現するためのいくつかのオプションを提供しています。最初のオプションは Amazon SageMaker レイクハウスでの自動オンボーディング(導入)で、データセットの Amazon SageMaker レイクハウスメタデータを Amazon SageMaker Catalog に取り込みます。このオプションでは、新しい Amazon SageMaker Unified Studio ドメインの作成の一部として、または既存のドメインに対して Amazon SageMaker レイクハウスデータをオンボードできます。 Amazon SageMaker レイクハウスデータの自動オンボーディングの詳細については、「 Amazon SageMaker Unified Studio でのデータのオンボーディング 」を参照してください。他のオプションとして、プロジェクトの Data ページと Compute ページを使用するか、GitHub で提供されているスクリプトを使用して、既存のリソースを Amazon SageMaker Unified Studio プロジェクトに持ち込むことができます。 Data ページと Compute ページの使用、またはスクリプトの使用の詳細については、「 既存のリソースを Amazon SageMaker Unified Studio に持ち込む 」を参照してください。本記事では、Amazon SageMaker レイクハウス機能を使用して trees AWS Glue テーブルを Producer プロジェクトにインポートします。 テーブルの Amazon S3 ロケーションを登録する trees テーブルへのきめ細かいアクセス制御に Lake Formation アクセス許可を使用するには、 trees テーブルの Amazon S3 ロケーションを Lake Formation に登録する必要があります。次のアクションを実行します。 プロデューサーアカウントで Lake Formation コンソールにアクセスします。 ナビゲーションペインの Administration で、 Data lake locations を選択します。 Register location を選択し、次の情報を入力します。 S3 URI に s3://&lt;bucket-name&gt;/&lt;prefix&gt;/ と入力します。 &lt;bucket-name&gt; は前提条件で作成した S3 バケットの名前、 &lt;prefix&gt; は前提条件の一部としてアップロードした trees.csv ファイルのオプションのプレフィックスです。 IAM role で AWSServiceRoleForLakeFormationDataAccess を選択します。 Permission mode で Lake Formation を選択します。 Register location を選択します。 Producer プロジェクトロールにデータベースのアクセス許可を付与する Producer プロジェクトに関連付けられた IAM ロールにデータベースアクセスを付与します。このロールはプロジェクトロールと呼ばれ、プロジェクト作成時に IAM で作成されました。 Amazon SageMaker Unified Studio の Producer プロジェクトから AWS Glue Data Catalog の collections データベースにアクセスするには、次のアクションを実行します。 プロデューサーアカウントで Lake Formation コンソールにアクセスします。 ナビゲーションペインの Data Catalog で、 Databases を選択します。 collections データベースを選択します。 Actions メニューから Grant を選択し、次の情報を入力します。 IAM users and roles で、 Producer プロジェクトのロール名を選択します。これは、ステップ 3「SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する」でメモした Producer プロジェクトロール ARN の一部である datazone_usr_role_ で始まる文字列です。 Database permissions で Describe を選択します。 Grant を選択します。 Producer プロジェクトロールにテーブルのアクセス許可を付与する Producer プロジェクトに関連付けられた IAM ロールに trees テーブルアクセスを付与します。これらのアクセス許可を付与するには次の手順に従います。 プロデューサーアカウントで Lake Formation コンソールにアクセスします。 ナビゲーションペインの Data Catalog で、 Tables and MVs を選択します。 trees テーブルを選択します。 Actions メニューから Grant を選択し、次の情報を入力します。 IAM users and roles で、 Producer プロジェクトのロールを選択します。これは、ステップ 3「SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する」でメモした Producer プロジェクトロール ARN の一部である datazone_usr_role_ で始まる文字列です。 Table permissions で Select と Describe を選択します。 Grantable permissions で Select と Describe を選択します。 Grant を選択します。 IAMAllowedPrincipals の既存のアクセス許可を取り消す アクセスに Lake Formation アクセス許可を適用するには、データベースとテーブルの両方で IAMAllowedPrincipals グループのアクセス許可を取り消す必要があります。詳細については、「 Lake Formation コンソールを使用したアクセス許可の取り消し 」を参照してください。 プロデューサーアカウントで Lake Formation コンソールにアクセスします。 ナビゲーションペインの Permission で、 Data permissions を選択します。 Principal が IAMAllowedPrincipals に設定され、 Resource が collections または trees に設定されているエントリを選択します。次の画像を参照してください。 Revoke を選択します。 revoke と入力します。 再度 Revoke を選択します。 Producer プロジェクトでデータが利用可能であることを確認する Producer プロジェクトで collections データベースと trees テーブルにアクセスできることを確認します。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンメニューを選択し、 Producer プロジェクトを選択します。 ナビゲーションペインの Overview で、 Data を選択します。 Lakehouse を選択します。 AwsDataCatalog を選択します。 collections を選択します。 tables を選択します。 trees テーブルの横にある 3 点アクションメニューを選択し、 Preview data を選択します。次の画像を参照してください。 次の画像に示すように、 trees テーブルのデータが表示されます。 Amazon SageMaker Catalog アセットを作成する プロジェクトでアクセス可能であっても、Amazon SageMaker Catalog で trees テーブルを操作するには、データソースを登録して Amazon SageMaker Catalog アセットを作成する必要があります。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Producer プロジェクトを選択します。 プロジェクトページのナビゲーションペインの Project catalog で、 Data sources を選択します。 Create Data Source を選択し、次のように選択します。 Name に collections と入力します。 Data source type で AWS Glue (Lakehouse) を選択します。 Database name で collections を選択します。 Next を選択します。 Next を選択します。 Next を選択します。 Create を選択します。 データソースが作成されたら、 collections データソースページで Run を選択します。これによりメタデータがインポートされ、Amazon SageMaker Catalog アセットが作成されます。 collections データソースの Data source runs タブで、実行が Completed とマークされ、 trees アセットが Successfully created と表示されます。次の画像を参照してください。 Amazon SageMaker Catalog でデータアセットを公開する データアセットを手動で公開することは、他のユーザーがカタログを通じてデータアセットにアクセスできるようにするために実行する必要がある 1 回限りの操作です。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Producer プロジェクトを選択します。 プロジェクトページの Project catalog で、 Assets を選択します。 Inventory タブで利用可能な trees データアセットを選択します。次の画像を参照してください。 (オプション) データソースの作成時に自動メタデータ生成が有効になっている場合、アセットのメタデータ (アセットのビジネス名など) を確認して承認または拒否できます。 Automated Metadata Generation バナーで Accept All または Reject All を選択できます。 Publish Asset を選択します。次の画像を参照してください。 Publish Asset を選択します。 Amazon SageMaker Catalog でデータアセットをサブスクライブする Consumer プロジェクトでデータアセットを消費するには、サブスクリプションリクエストを作成してデータアセットをサブスクライブします。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Consumer プロジェクトを選択します。 Discover メニューで Catalog を選択します。 検索ボックスに trees と入力し、検索から返されたデータアセットを選択します。ステップ 7「Amazon SageMaker Catalog でデータアセットを公開する」で Automated Metadata Generation バナーの Accept All を選択した場合、データアセットには自動メタデータ推奨機能によって生成された別のビジネス名が付けられます。データアセットのテクニカルネームは trees です。次の画像を参照してください。 Subscribe を選択します。 Comment に、 This data asset is needed for model training purposes などの正当な理由を入力します。 再度 Subscribe を選択します。 デフォルトでは、アセットサブスクリプションリクエストにはデータ所有者による手動承認が必要です。ただし、 Consumer プロジェクトのリクエスターが Producer プロジェクトのメンバーでもある場合、サブスクリプションリクエストは自動的に承認されます。サブスクリプションリクエストの承認の詳細については、「 Amazon SageMaker Unified Studio でサブスクリプションリクエストを承認または拒否する 」を参照してください。 サブスクライブしたデータアクセスにアクセスするように Lambda IAM ロールを設定する Lambda 関数がサブスクライブしたデータアセットにアクセスできるようにするには、Lambda 関数が Consumer プロジェクトロールを引き受けることを許可する必要があります。 Consumer プロジェクトの IAM ロール信頼関係を編集します。 コンシューマーアカウントで IAM コンソールに移動します。 ナビゲーションペインの Access management で、 Roles を選択します。 Consumer プロジェクトの IAM ロールを選択します。これは、ステップ 3「SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する」でメモした Consumer プロジェクトロール ARN の一部である datazone_usr_role_ で始まる文字列です。 Trust relationships タブで、 Edit trust policy を選択します。 バックアップのため、既存の信頼ポリシーのコピーをテキストファイルに作成します。 Edit trust policy ウィンドウで、信頼ポリシーの他の既存のステートメントを削除または上書きしないようにしつつ、次のステートメントを既存の信頼ポリシーに追加します。プレースホルダー &lt;account_id&gt; をコンシューマー AWS アカウント ID に置き換えてください。 { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::&lt;account_id&gt;:role/smus_consumer_lambda" }, "Action": [ "sts:AssumeRole" ] } Update policy を選択します。 サブスクライブしたデータアセットへの Lambda 関数のアクセスをテストする Lambda 関数をテストする前に、関数コードと IAM ポリシーのプレースホルダーを置き換える必要があります。置き換える必要があるプレースホルダーは 3 つあります: &lt;role_arn&gt; 、 &lt;database_name&gt; 、 &lt;workgroup_id&gt; です。 &lt;role_arn&gt; については、ステップ 3「SageMaker Unified Studio のプロデューサープロジェクトとコンシューマープロジェクトを作成する」でメモした Consumer プロジェクトのロール ARN という実際の値がすでにあります。次のセクションでは、他のプレースホルダーの値を取得する手順を説明します。 AWS Glue Data Catalog データベース名を取得する Consumer プロジェクトと共に作成された AWS Glue Data Catalog データベースの名前を取得します。次に、この値を使用して consumer_function Lambda 関数コードの &lt;database_name&gt; プレースホルダーを置き換えます。AWS Glue Data Catalog データベース名を取得するには、次の手順に従います。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Consumer プロジェクトを選択します。 プロジェクトページの Overview で、 Data を選択します。 Lakehouse を選択します。 AwsDataCatalog を選択します。 データベースの名前をコピーします。次の画像のように、 glue_db で始まる英数字の文字列である必要があります。 Athena ワークグループ ID を取得する Consumer プロジェクトと共に作成された Athena ワークグループの ID を取得します。次に、この値を使用して consumer_function Lambda 関数コードと smus_consumer_athena_execution IAM ポリシーの &lt;workgroup_id&gt; プレースホルダーを置き換えます。Athena ワークグループ ID を取得するには、次の手順を使用します。 Amazon SageMaker Unified Studio ポータルにアクセスします。 Select a project ドロップダウンリストを選択し、 Consumer プロジェクトを選択します。 プロジェクトページの Overview で、 Compute を選択します。 SQL analytics タブで project.athena を選択します。次の画像を参照してください。 Workgroup ARN をコピーしてテキストファイルに保存します。Athena ワークグループ ID は、Workgroup ARN の arn:aws:athena:&lt;region&gt;:&lt;account_ID&gt;:workgroup/ に続く文字列です。 smus_consumer_athena_execution IAM ポリシーのプレースホルダーを置き換える smus_consumer_athena_execution IAM ポリシーの &lt;workgroup_id&gt; プレースホルダーを置き換えるには、次の手順を使用します。 コンシューマーアカウントで IAM コンソールにアクセスします。 ナビゲーションペインで Policies を選択します。 検索フィールドに smus_consumer_athena_execution と入力します。 smus_consumer_athena_execution ポリシーを選択します。 Edit を選択します。 &lt;workgroup_id&gt; を前にメモした値に置き換えます。 Next を選択します。 Save changes を選択します。 Lambda 関数コードのプレースホルダーを置き換えてテストする consumer_function Lambda 関数コードの &lt;role_arn&gt; 、 &lt;database_name&gt; 、 &lt;workgroup_id&gt; プレースホルダーを置き換え、 trees テーブルのデータにアクセスする関数の機能をテストします。 コンシューマーアカウントで Lambda コンソールにアクセスします。 ナビゲーションペインで Functions を選択します。 consumer_function を選択します。 Code タブで、 &lt;role_arn&gt; 、 &lt;database_name&gt; 、 &lt;workgroup_id&gt; プレースホルダーを前にメモした各値に置き換えます。 Deploy を選択します。 Test タブで、 Event name に mytest と入力します。 Test を選択します。 実行が完了した後に表示される Executing function というタイトルの緑色のバナーで Details を選択します。 実行ログに trees テーブルの内容が報告されます。次の画像を参照してください。 Lambda 関数の実行がタイムアウトで失敗する場合は、次のように関数のタイムアウト設定を変更します。 コンシューマーアカウントで Lambda コンソールにアクセスします。 ナビゲーションペインで Functions を選択します。 consumer_function を選択します。 Configuration タブで Edit を選択します。 Timeout に 15 秒以上の値を入力します。 Save を選択します。 タイムアウトを増やした後、関数を再度テストします。 クリーンアップ 作成したリソースが不要になった場合は、追加料金が発生しないように削除してください。まず、ガバナンスアカウントで Amazon SageMaker Unified Studio ドメインを削除します。詳細については、「ドメインの削除」を参照してください。 プロデューサーアカウントから AWS Glue collections データベースを削除するには、次の手順に従います。 プロデューサーアカウントで Glue コンソールにアクセスします。 ナビゲーションペインの Data Catalog で、 Databases を選択します。 collections データベースを選択します。 Delete を選択します。 Delete を選択します。 プロデューサーアカウントから S3 バケットを削除するには、バケットを空にしてからバケットを削除できます。バケットを空にする方法については、「 汎用バケットを空にする 」を参照してください。バケットの削除については、「 汎用バケットの削除 」を参照してください。 コンシューマーアカウントから Lambda 関数を削除するには、次の手順に従います。 コンシューマーアカウントで Lambda コンソールにアクセスします。 ナビゲーションペインで Functions を選択します。 consumer_function Lambda 関数を選択します。 Actions メニューを選択し、 Delete function を選択します。 confirm と入力します。 Delete を選択します。 クリーンアップの最後に、コンシューマーアカウントで smus_consumer_lambda という名前の IAM ロールを削除し、次に smus_consumer_athena_execution という名前の IAM ポリシーを削除します。IAM ロールの削除については、「 ロールまたはインスタンスプロファイルの削除 」を参照してください。IAM ポリシーの削除については、「 IAM ポリシーの削除 」を参照してください。 まとめ 本記事では、既存のアプリケーションとデータリポジトリを再設計せずに、データガバナンスのために Amazon SageMaker Catalog を採用する方法について説明しました。Amazon SageMaker Unified Studio で既存のデータをオンボードし、カタログで公開し、Amazon SageMaker Unified Studio プロジェクトのコンテキスト外にデプロイされたリソースからデータをサブスクライブして利用する方法を説明しました。このソリューションは、Amazon SageMaker Catalog でデータメッシュパターンの実装を加速し、組織内でデータを安全に公開、検索、アクセスするのに役立ちます。 詳細については、「 Amazon SageMaker とは 」を参照し、 Amazon SageMaker ワークショップ を実行して、データ、分析、AI の統合エクスペリエンスを試してください。 著者について Paolo Romagnoli Paolo は、AWS のエネルギーおよび公益事業向け Senior Solutions Architect です。エンタープライズソリューションの設計と構築に 20 年以上の経験があり、グローバルなエネルギー企業と協力して、ビジネスと技術のニーズに対応するソリューションを設計しています。テクノロジーに情熱を持ち、ランニングを楽しんでいます。 Joel Farvault Joel は、AWS の Principal Specialist SA Analytics で、エンタープライズアーキテクチャ、データガバナンス、分析に 25 年の経験があります。その経験を活用して、データ戦略と技術基盤についてお客様にアドバイスしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。

2026 年 2 月 16 日、 Amazon Elastic Compute Cloud (Amazon EC2) Hpc8a インスタンスの一般提供についてお知らせしたいと思います。このインスタンスは、最新の第 5 世代 AMD EPYC プロセッサを搭載した新しいハイパフォーマンスコンピューティング (HPC) 最適化インスタンスタイプであり、周波数は最大 4.5 GHz です。Hpc8a インスタンスは、数値流体力学、より高速な設計イテレーションのためのシミュレーション、限られた作業時間内での高解像度気象モデリング、迅速な TTR (Time-to-Results) を必要とする複雑な衝突シミュレーションなど、コンピューティング集約型の密結合 HPC ワークロードに最適です。 新しい HPC8a インスタンスは、前世代の Hpc7a インスタンス よりも最大 40% 優れたパフォーマンス、42% 広いメモリ帯域幅、最大 25% 優れた料金パフォーマンスを実現します。お客様は、コンピューティング集約型のシミュレーションワークロードでの効率的なスケーリングとジョブ完了時間の短縮に役立つ、高いコア密度、メモリ帯域幅、低レイテンシーネットワーキングからメリットを得られます。 Hpc8a インスタンス Hpc8a インスタンスでは、192 個のコア、768 GiB のメモリ、300 Gbps の Elastic Fabric Adapter (EFA) ネットワーキングを利用して、高レベルのノード間通信を大規模に行う必要があるアプリケーションを実行できます。 インスタンス名 物理コア数 メモリ (Gib) EFA ネットワーク帯域幅 (Gbps) ネットワーク帯域幅 (Gbps) アタッチされたストレージ Hpc8a.96xlarge 192 768 最大 300 75 EBS のみ Hpc8a インスタンスは 96xlarge サイズのみで提供されており、コアとメモリの比率は 1:4 です。インスタンス起動時に必要なコアの数をカスタマイズすることで、HPC ワークロード要件に基づいて適切なサイズを設定できます。これらのインスタンスは第 6 世代の AWS Nitro Card も使用しており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードして、ワークロードのパフォーマンスとセキュリティを強化します。 Hpc8a インスタンスは、 AWS ParallelCluster および AWS Parallel Computing Service (AWS PCS) で使用してワークロードの送信とクラスターの作成を簡素化、または Amazon FSx for Lustre で使用してストレージにミリ秒未満のレイテンシーと 1 秒あたり最大数百ギガバイトのスループットを実現できます。HPC ワークロードで最高のパフォーマンスを達成するため、このインスタンスでは同時マルチスレッド (SMT) が無効化されています。 今すぐご利用いただけます Amazon EC2 Hpc8a インスタンスは、米国東部 (オハイオ) と欧州 (ストックホルム) AWS リージョン で今すぐご利用いただけます。リージョンごとの提供状況と今後のロードマップについては、 AWS Capabilities by Region の [CloudFormation リソース] タブでインスタンスタイプを検索してください。 このインスタンスは、 オンデマンドインスタンス および Savings Plan として購入できます。&nbsp;詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で Hpc8a インスタンスをお試しください。詳細については、 Amazon EC2 Hpc8a インスタンスページ をご覧ください。フィードバックは、 AWS re:Post for EC2 に送信するか、通常の AWS サポート連絡先経由でお寄せください。 – Channy 原文は こちら です。

AWS New Summit 2025 で Amazon SageMaker AI の Amazon Nova カスタマイズ をリリースして以来、お客様からは Amazon SageMaker Inference でオープンウェイトモデルをカスタマイズする場合と同じ機能を Amazon Nova でも使用したいと伺っていました。また、本番環境のワークロードに必要なインスタンスタイプ、自動スケーリングポリシー、コンテキストの長さ、同時実行設定について、カスタムモデル推論の制御と柔軟性を高めたいという声もお聞きしました。 2026 年 2 月 16 日、Amazon SageMaker Inference でのカスタム Nova モデルサポートの一般提供を発表いたしました。これは、フルランクのカスタマイズされた Nova モデルをデプロイおよびスケールするための、本番環境グレードかつ設定可能で、コスト効率の高いマネージド推論サービスです。 Amazon SageMaker Training Jobs または Amazon HyperPod を使用して Nova Micro、Nova Lite、Nova 2 Lite の各モデルを推論機能付きでトレーニングし、Amazon SageMaker AI のマネージド推論インフラストラクチャを利用してシームレスにデプロイする、エンドツーエンドのカスタマイズジャーニーをご体験いただけるようになりました。 カスタム Nova モデル用の Amazon SageMaker Inference では、 P5 インスタンス の代わりに Amazon Elastic Compute Cloud (Amazon EC2) の G5 および G6 インスタンスを使用した GPU 使用率の最適化、5 分間の使用パターンに基づく自動スケーリング、設定可能な推論パラメータを通じて推論コストを削減できます。この機能により、継続的な事前トレーニング、教師ありのファインチューニング、またはユースケースに合わせた強化ファインチューニングを使用して、カスタマイズされた Nova モデル向けにデプロイできます。また、コンテキストの長さ、同時実行数、バッチサイズに関する詳細設定を設定して、特定のワークロードのレイテンシーとコスト精度のトレードオフを最適化することもできます。 カスタマイズした Nova モデルを SageMaker AI リアルタイムエンドポイントにデプロイする方法、推論パラメータを設定する方法、テスト用にモデルを呼び出す方法を見てみましょう。 SageMaker 推論にカスタム Nova モデルをデプロイする AWS re:Invent 2025 では、Nova モデルを含む一般的な AI モデル向けに Amazon SageMaker AI の新しいサーバーレスカスタマイズ を導入しました。数回クリックするだけで、モデルとカスタマイズ手法をシームレスに選択し、モデル評価とデプロイを行うことができます。トレーニング済みのカスタム Nova モデルアーティファクトが既にある場合は、 SageMaker Studio または SageMaker AI SDK を通じて SageMaker Inference でモデルをデプロイできます。 SageMaker Studio の [モデル] メニューで、お使いのモデル内のモデルで、トレーニング済みの Nova モデルを選択します。 [デプロイ] ボタン、 [SageMaker AI] 、 [新規エンドポイントを作成] を選択して、モデルをデプロイできます。 エンドポイント名、インスタンスタイプ、およびインスタンス数、最大インスタンス数、アクセス許可とネットワークなどの詳細オプション、 [デプロイ] ボタンを選択します。GA の起動時には、Nova Micro モデルの場合は g5.12xlarge 、 g5.24xlarge 、 g5.48xlarge 、 g6.12xlarge 、 g6.24xlarge 、 g6.48xlarge 、 p5.48xlarge インスタンスタイプ、Nova Lite モデルの場合は g5.24xlarge 、 g5.48xlarge 、 g6.24xlarge 、 g6.48xlarge 、 p5.48xlarge 、Nova 2 Lite モデルの場合は p5.48xlarge を使用できます。 エンドポイントを作成する際には、インフラストラクチャのプロビジョニング、モデルアーティファクトのダウンロード、推論コンテナの初期化に時間がかかります。 モデルのデプロイが完了し、エンドポイントのステータスで [InService] と表示されたら、新しいエンドポイントを使用してリアルタイムの推論を実行できます。モデルをテストするには、 [プレイグラウンド] タブを選択し、 チャット モードでプロンプトを入力します。 SageMaker AI SDK を使用して 2 つのリソースを作成することもできます。1 つは Nova モデルアーティファクトを参照する SageMaker AI モデルオブジェクトで、もう 1 つはモデルのデプロイ方法を定義するエンドポイント設定です。 次のコードは、Nova モデルアーティファクトを参照する SageMaker AI モデルを作成します。 # Create a SageMaker AI model model_response = sagemaker.create_model( ModelName= 'Nova-micro-ml-g5-12xlarge', PrimaryContainer={ 'Image': '123456789012.dkr.ecr.us-east-1.amazonaws.com/nova-inference-repo:v1.0.0', 'ModelDataSource': { 'S3DataSource': { 'S3Uri': 's3://your-bucket-name/path/to/model/artifacts/', 'S3DataType': 'S3Prefix', 'CompressionType': 'None' } }, # Model Parameters 'Environment': { 'CONTEXT_LENGTH': 8000, 'CONCURRENCY': 16, 'DEFAULT_TEMPERATURE': 0.0, 'DEFAULT_TOP_P': 1.0 } }, ExecutionRoleArn=SAGEMAKER_EXECUTION_ROLE_ARN, EnableNetworkIsolation=True ) print("Model created successfully!") 次に、デプロイインフラストラクチャを定義するエンドポイント設定を作成し、SageMaker AI リアルタイムエンドポイントを作成して Nova モデルをデプロイします。このエンドポイントはモデルをホストし、推論リクエストを行うための安全な HTTPS エンドポイントを提供します。 # Create Endpoint Configuration production_variant = { 'VariantName': 'primary', 'ModelName': 'Nova-micro-ml-g5-12xlarge', 'InitialInstanceCount': 1, 'InstanceType': 'ml.g5.12xlarge', } config_response = sagemaker.create_endpoint_config( EndpointConfigName= 'Nova-micro-ml-g5-12xlarge-Config', ProductionVariants= production_variant ) print("Endpoint configuration created successfully!") # Deploy your Noval model endpoint_response = sagemaker.create_endpoint( EndpointName= 'Nova-micro-ml-g5-12xlarge-endpoint', EndpointConfigName= 'Nova-micro-ml-g5-12xlarge-Config' ) print("Endpoint creation initiated successfully!") エンドポイントが作成されたら、推論リクエストを送信してカスタム Nova モデルから予測を生成できます。Amazon SageMaker AI は、ストリーミング/非ストリーミングモードのリアルタイム用の同期エンドポイントと、バッチ処理用の非同期エンドポイントをサポートします。 例えば、次のコードはテキスト生成用のストリーミング補完形式を作成します。 # Streaming chat request with comprehensive parameters streaming_request = { "messages": [ {"role": "user", "content": "Compare our Q4 2025 actual spend against budget across all departments and highlight variances exceeding 10%"} ], "max_tokens": 512, "stream": True, "temperature": 0.7, "top_p": 0.95, "top_k": 40, "logprobs": True, "top_logprobs": 2, "reasoning_effort": "low", # Options: "low", "high" "stream_options": {"include_usage": True} } invoke_nova_endpoint(streaming_request) def invoke_nova_endpoint(request_body): """ Invoke Nova endpoint with automatic streaming detection. Args: request_body (dict): Request payload containing prompt and parameters Returns: dict: Response from the model (for non-streaming requests) None: For streaming requests (prints output directly) """ body = json.dumps(request_body) is_streaming = request_body.get("stream", False) try: print(f"Invoking endpoint ({'streaming' if is_streaming else 'non-streaming'})...") if is_streaming: response = runtime_client.invoke_endpoint_with_response_stream( EndpointName=ENDPOINT_NAME, ContentType='application/json', Body=body ) event_stream = response['Body'] for event in event_stream: if 'PayloadPart' in event: chunk = event['PayloadPart'] if 'Bytes' in chunk: data = chunk['Bytes'].decode() print("Chunk:", data) else: # Non-streaming inference response = runtime_client.invoke_endpoint( EndpointName=ENDPOINT_NAME, ContentType='application/json', Accept='application/json', Body=body ) response_body = response['Body'].read().decode('utf-8') result = json.loads(response_body) print("✅ Response received successfully") return result except ClientError as e: error_code = e.response['Error']['Code'] error_message = e.response['Error']['Message'] print(f"❌ AWS Error: {error_code} - {error_message}") except Exception as e: print(f"❌ Unexpected error: {str(e)}") 完全なコード例を使用するには、「 Amazon SageMaker AI での Amazon Nova モデルのカスタマイズ 」をご参照ください。モデルのデプロイと管理に関するベストプラクティスの詳細については、「 SageMaker AI のベストプラクティス 」をご覧ください。 今すぐご利用いただけます カスタム Nova モデル用の Amazon SageMaker Inference は、2026 年 2 月 16 日、米国東部 (バージニア北部) および米国西部 (オレゴン) の AWS リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 この機能は、自動スケーリングを使用して EC2 G5、G6、P5 インスタンスで実行される、推論機能を備えた Nova Micro、Nova Lite、Nova 2 Lite モデルをサポートします。使用したコンピューティングインスタンス分のみに対してお支払いいただきます。時間単位の請求で、最小契約はありません。詳細については、 Amazon SageMaker AI の料金ページ をご覧ください。 Amazon SageMaker AI コンソール をぜひお試しいただき、 AWS re:Post for SageMaker 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週号も盛りだくさんです。開催直前になりますが、2 月 27 日 （金）に「 企業でつかうためのCoding Agent「Kiro」 オンライン勉強会 」が開催されます。まだ申し込み受付中ですのでAI エージェントを活用した開発プロセスの効率化に関心がある方はぜひ参加ください！また 3 月 26 日（木）には「 Amazon Quick Suite で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。分析業務や定型業務の効率化に興味がある方はぜひご参加ください！ それでは 2 月 16 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI事例ブログ「BMW Group が AWS 上のエージェンティック検索でペタバイト規模のデータからインサイトを引き出す」を公開 BMW Group が AWS Professional Services と協力し、Amazon S3 Vectors、Amazon Bedrock、Amazon Bedrock AgentCore を活用したエージェンティック検索ソリューションを構築した事例が紹介されています。20 PB のデータを保有する同社のデータレイクハウスに対し、ハイブリッド検索・網羅的検索・SQL クエリの 3 つのアプローチを AI エージェントが自動的に切り替えることで、技術的な専門知識がなくても自然言語で大規模データからインサイトを引き出せるようになりました。生成 AI を活用してデータ分析の民主化を実現するアーキテクチャの実例として、エージェンティック AI の実装パターンやサーバーレスアーキテクチャによるコスト効率の高い運用方法を学ぶことができます。 AWS生成AI国内事例ブログ「『導入しても使われない』を解決する ― 三菱電機 電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化」を公開 三菱電機 電力ICTセンターが、開発者向けエージェント型 IDE「Kiro」の Steering・Powers・MCP の 3 層構造と GitLab を組み合わせ、「AI に聞けばワークフローに沿った開発ができる」というプラットフォームを構築した事例が紹介されています。Issue 作成からブランチ作成、実装、MR 作成、レビューまでの開発フロー全体を Powers に定義し、さらに Kiro によるコード生成と GitLab Duo によるレビューという AI 同士の協働により、人間のレビュー負担を軽減しながら品質を担保するワークフローを実現しています。生成 AI を活用した開発効率化に取り組むユーザーにとって、ドキュメントを読んでも AI に聞いても同じ結果にたどり着ける仕組みづくりや、AI エージェントの振る舞いを組織のルールに沿って制御する具体的な方法を学ぶことができます。 AWS生成AI国内事例ブログ「メック株式会社の事例：Amazon Bedrock AgentCore で研究業務を効率化 – AI エージェントによる情報検索と更新の自動化」を公開 メック株式会社が Amazon Bedrock AgentCore と Amazon S3 Vectors を活用し、研究業務における情報検索と情報更新を AI エージェントで自動化したソリューションを約 3 週間で構築した事例が紹介されています。情報検索エージェントはユーザーの質問をそのまま検索するのではなく専門知識をもとに最適なクエリを自動生成し、情報更新エージェントは新規情報にコンテキストやメタデータを自動付与することで、経験年数に関わらず高品質な情報アクセスと知的資産の体系的な蓄積を実現しています。生成 AI を活用したエージェント開発に取り組むユーザーにとって、Bedrock AgentCore Runtime のサーバーレスなランタイム環境と Strands Agents を組み合わせた PoC のスモールスタート事例として参考になります。 AWS生成AI国内事例ブログ「小売業界の未来を切り拓く：東芝テックが AWS の AI エージェントを活用した店舗運営支援ソリューションを開発」を公開 東芝テックが Amazon Bedrock と Amazon Bedrock AgentCore、Strands Agents SDK を活用し、POS データや在庫情報、IoT センサーデータを AI エージェントが継続的にモニターして売り場責任者に具体的な推奨アクションを通知する店舗運営支援ソリューションを開発した事例が紹介されています。ベテラン担当者の業務知識を管理画面から自然言語でインプットするだけでノーコードで AI エージェントを開発でき、24 時間 365 日バックグラウンドで稼働することで、経験年数に関わらずデータドリブンな意思決定が可能になります。生成 AI を活用した小売業向けソリューションに取り組むユーザーにとって、AgentCore Runtime によるサーバーレスなエージェント運用や AgentCore Memory による対話の記憶を活かしたパーソナライズなど、実践的なアーキテクチャの参考になります。 ブログ記事「AWS で NVIDIA Cosmos world foundation models を実行」を公開 自律走行車やロボティクス、スマートファクトリーなどのフィジカル AI 開発では、高品質なトレーニングデータの不足が大きな課題となっています。本ブログでは、NVIDIA Cosmos ワールドファウンデーションモデル (WFM) を AWS 上にデプロイし、物理的に妥当性のある合成データを大規模に生成する方法として、Amazon Elastic Kubernetes Service (Amazon EKS) を使ったリアルタイム推論と AWS Batch を使ったバッチ推論の 2 つの本番環境向けアーキテクチャを紹介しています。生成 AI を活用したフィジカル AI の開発に取り組むユーザーにとって、実世界のデータ収集に頼らず合成データで開発サイクルを加速できる具体的な実装パターンを学ぶことができます。 ブログ記事「リファクタリングを正しく行う：プログラム解析により AI エージェントの安全性と信頼性を高める方法」を公開 AI コーディングアシスタントにシンボルの名前変更やファイル移動といったリファクタリングを依頼すると、インポートの破損や参照の欠落が発生しがちですが、本ブログでは開発者向けエージェント型 IDE「Kiro」が IDE の言語サーバーを活用した「セマンティックリネームツール」と「スマートリロケートツール」でこの課題をどう解決するかを解説しています。LLM によるテキストベースの検索置換に頼るのではなく、コードの構造を理解するプログラム解析を組み合わせることで、ワークスペース全体にわたる変更を安全かつ正確に反映でき、リファクタリング後のデバッグ作業を大幅に削減できます。生成 AI を活用した開発に取り組むユーザーにとって、AI エージェントの出力をより信頼できるものにするための「構築による正確性」というアプローチの具体的な実装例として参考になります。 ブログ記事「バグ修正と既存アプリの上に構築するための新しい Spec タイプ」を公開 開発者向けエージェント型 IDE「Kiro」の仕様駆動開発ワークフロー Specs に、「デザインファースト」と「バグ修正」の 2 つの新しい Spec タイプが追加されました。デザインファースト Spec は技術的アプローチがすでに決まっている既存アプリへの機能追加に、バグ修正 Spec は「現在の振る舞い」「期待される振る舞い」「変更されない振る舞い」の 3 セクション構造で外科的な修正を行う場合に適しており、いずれもプロパティベーステストによる検証まで一貫して行えます。生成 AI を活用した開発に取り組むユーザーにとって、新規開発だけでなく既存コードベースの保守・改善においても、AI エージェントと効果的に協働するための実践的なアプローチを学ぶことができます。 ブログ記事「Claude Sonnet 4.6 が Kiro で利用可能になりました」を公開 開発者向けエージェント型 IDE「Kiro」の IDE および CLI で、Anthropic の Claude Sonnet 4.6 が利用可能になりました。Sonnet 4.6 は Sonnet 4.5 からの完全なアップグレードで、Opus 4.6 に匹敵する知能を持ちながらトークン効率が高く、複数ステップのツール呼び出しや長いセッションでのコンテキスト維持など、エージェント作業に特化して構築されています。生成 AI を活用した開発に取り組むユーザーにとって、機能構築やリファクタリング、デバッグなどの反復的な開発ワークフローにおいて、より高速で高品質なタスク完了が期待できるモデルです。 ブログ記事「Kiro のエンタープライズ ID 連携と使用状況メトリクス」を公開 開発者向けエージェント型 IDE「Kiro」が、外部 ID プロバイダー（Okta と Microsoft Entra ID）との連携とユーザーレベルのアクティビティメトリクスをサポートしました。管理者は既存の SSO ポリシーや MFA 適用をそのまま Kiro に適用でき、IDE・CLI・Web アプリ全体でのチーム利用状況をクライアントタイプごとに可視化できるようになります。組織で生成 AI を活用した開発ツールの導入を検討しているユーザーにとって、既存の ID 基盤やコンプライアンス要件を維持しながらチーム全体への展開と利用状況の把握を実現できるエンタープライズ向け機能として注目です。 ブログ記事「エージェンティック・クラウドモダナイゼーション: AWS MCP と Kiro によるモダナイゼーションの加速」を公開 開発者向けエージェント型 IDE「Kiro」と公式の AWS MCP サーバーを統合することで、レガシーシステムのクラウドモダナイゼーションにおける分析・計画・実装の 3 フェーズを自動化し、従来数週間かかっていた評価やアーキテクチャ設計を数日に短縮するアプローチが紹介されています。Kiro が既存コードベースを分析してアーキテクチャ図やドキュメントを自動生成し、AWS Well-Architected Framework に沿ったターゲットアーキテクチャの設計、リアルタイムのコスト見積もり、AWS CloudFormation や AWS CDK 等の Infrastructure as Code の生成まで一貫して行えます。生成 AI を活用したモダナイゼーションに取り組むユーザーにとって、AWS ドキュメント・料金・CDK などの各種 MCP サーバーを組み合わせた具体的なセットアップ方法と実装パターンを学ぶことができます。 ブログ記事「AI で強化された脅威アクターによる FortiGate デバイスへの大規模な不正アクセス」を公開 Amazon Threat Intelligence が、商用生成 AI サービスを活用した脅威アクターが 55 か国以上・600 台超の FortiGate デバイスを侵害したキャンペーンを観測・分析した調査結果が共有されています。技術力の低い脅威アクターでも、AI を活用して攻撃計画の策定やツール開発、認証情報の抽出を大規模に行えるようになった一方、侵害の主因はインターネットに公開された管理インターフェイスと脆弱な認証情報という基本的なセキュリティの欠陥であり、堅実なセキュリティの基本が依然として有効な防御策であることが示されています。AWS を利用するユーザーに対しては、Amazon GuardDuty や Amazon Inspector、AWS Security Hub を活用した脅威検出やセキュリティポスチャの継続的な可視化など、具体的な推奨事項が紹介されています。 サービスアップデート Amazon Bedrock の強化学習ファインチューニングが OpenAI 互換 API でオープンウェイトモデルをサポート Amazon Bedrock の強化学習ファインチューニング（RFT）が、qwen.qwen3-32b や openai.gpt-oss-20b などのオープンウェイトモデルに対応し、OpenAI 互換のファインチューニング API が利用可能になりました。大規模なラベル付きデータセットや深い機械学習の専門知識がなくても、少量のプロンプトセットとルールベースの評価関数や AI ベースのジャッジを使ってモデルをカスタマイズでき、ファインチューニング完了後は追加のデプロイ手順なしに Responses API や Chat Completions API でそのまま推論に利用できます。生成 AI を活用するユーザーにとって、小型で高速かつコスト効率の高いモデルを自社の業務要件に合わせて最適化し、フルマネージドかつセキュアな環境で運用できる選択肢が広がるアップデートです。 Claude Sonnet 4.6 が Amazon Bedrock で利用可能に Amazon Bedrock で Anthropic の Claude Sonnet 4.6 が利用可能になりました。Sonnet 4.5 からの直接アップグレードとして、Opus 4.6 に匹敵する知能を低コストで提供し、コーディング、エージェンティックワークフロー、ブラウザベースの自動化（コンピュータ使用）において高いパフォーマンスを発揮します。生成 AI を活用するユーザーにとって、マルチモデルパイプラインでのリードエージェント・サブエージェント両方の役割を担えるほか、スプレッドシート作成やコンプライアンスレビューなどのエンタープライズ用途にも活用でき、Sonnet 4.5 からの移行も軽微なプロンプト調整のみで対応できます。 Kiro が AWS GovCloud (US) リージョンで利用可能に 開発者向けエージェント型 IDE「Kiro」が、AWS GovCloud (US-East) および AWS GovCloud (US-West) リージョンで利用可能になりました。高いコンプライアンス要件を持つワークロードに対して、スペック駆動開発やドキュメント・ユニットテストの自動生成、ネイティブ MCP サポートによるデータベースや API との連携など、エージェンティック AI 開発の機能が提供されます。AWS IAM Identity Center によるエンタープライズ認証に対応しており、政府機関や規制産業で生成 AI を活用した開発に取り組むユーザーにとって、ミッションクリティカルな開発ワークフローに Kiro を導入できるようになるアップデートです。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。