本稿は 2025 年 7 月 31 日に公開された “ Reach plc delivers impactful journalism with AI driven Guten powered by AWS ” を翻訳したものです。 本稿は Reach plc のシニアデータサイエンティストである Lewis James とグループデータ・アナリティクスディレクターである Dan Taffler と共同執筆しました。 ニュースは目まぐるしいスピードで発生します。パブリッシャーは公開までのプロセスを加速するために、ビジネスプロセスを常に評価し、イノベーションを行っていく必要があります。この状況を変えることが、あるパブリッシャーのミッションとなりました。Amazon Web Services（AWS）を活用した独自の生成 AI プロダクトを作成し、ジャーナリストが倫理を守りながら、 刻一刻と変化するニュースの最前線に立ち続けることを支援しています。 ミッション 英国（UK）およびアイルランドで最大の商業・国・地域ニュースのパブリッシャーとして、 Reach plc は数千人のジャーナリストを擁する社内編集チームを有しています。彼らは 120 以上のブランド（ The Mirror , The Express 、 Daily Record 、 Manchester Evening News 、 Daily Star など）をカバーし、読者に力を与え、啓発し、楽しませています。Reach は毎月、英国のオンラインの読者の 69％、そして最近設立された米国ブランド（ The Mirror US など）を通じて米国のオンラインの読者の 11％ にニュースを配信しています。 ジャーナリストが価値の高い、影響力のあるジャーナリズムに集中できるようにするミッションの一環として、Reach の Data Science チームは Guten を開発しました。Guten は Amazon Bedrock に実装された基盤モデルを活用したプロダクトで、記事タグの追加や記事コンテンツのドラフト作成など、手動で行っていた非中核なタスクを自動化します。 Guten プロダクトの起源 Guten プロジェクトは、Reach の基礎となるビジネス指標を深く考えることから始まりました。Reach は複数のシステムで行っている非中核的な手動によるタスク（記事へのハイパーリンクの追加や、異なる分析ツール間での様々な指標の組み合わせ）の時間を削減したいと考えていました。また、全ての Reach ブランドでの総ページビューを増やし、速報ニュースの公開時間を短縮したいと考えていました。 生成 AI がパブリッシャー業界の新たな戦略的転換点となる中、Reach は PoC から開始して活用を決定しました。これによりニュースルームとの深い協力関係が生まれ、ジャーナリストの日常業務を妨げる制約、ボトルネック、反復的なタスクを特定するために逆算して取り組みました。 ユーザーリサーチにより、Reach は 3 つの課題を特定しました： 仕事を遂行する際に異なるツール間で 頻繁にコンテキストの切り替え があり、速報ニュースと記事のパフォーマンスに影響を与えている 検索エンジン最適化（SEO）のバックリンクやシステム間でのコンテンツのコピーなど、 反復的で複雑性の低いタスク 現在のトレンド、話題の信頼性、情報源となるコンテンツの入手可能性に関する 複雑な判断 を、統計的な分析ではなく直感に頼っている を、統計的な分析ではなく直感に頼っている Guten がゲームをどのように変えたか その名前は、1448 年に印刷機を発明したドイツの金細工師で発明家のヨハン・グーテンベルクに由来しています。Guten は複雑さを抽象化し、データサイエンスと生成 AI へのアクセスを民主化します。Reach のジャーナリストは、プロンプトエンジニアリング、基盤モデルの選択、評価について心配する必要がありません。AI を理解するための追加の技術スキルを必要とせず、自分の役割で最も価値を付加することに集中できます。 The Mirror と OK Magazine の数名の献身的なジャーナリストから始まり、Guten のパイロット運用は成功しました。その後の 1 年で迅速な改良を通じて拡大・展開され、Reach の他の出版物全体で採用されました。 Guten は、ニュースワイヤーの取り込み、ワイヤー記事の提案、記事アイデアの推奨、コンテンツ生成を含む Reach の編集ワークフローの全ての部分を最適化します。コンテンツ管理システム（CMS）や他のビジネスツールとも統合されています。Guten は速報ニュースのリリース速度を大幅に向上させ、公開時間を 9 分から 90 秒に短縮しました。 Reach の Content Hub では、専門のジャーナリストチームが複数の国・地域ブランド向けにトラフィックを促進するコンテンツを制作しています。Guten は Reach のコンテンツを取り上げ、同じ記事の全てのバージョンを最初から書き直すことなく、他の出版物のスタイルとトーンで書き直す機能を提供しています。 開始から 2 年で、Guten は 2024 年に 18 億以上のページビュー の促進を支援しました。 Guten の AWS アーキテクチャ Guten のアーキテクチャは、主要な AWS サービス（ AWS Fargate 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon OpenSearch Service 、Amazon Bedrock、 AWS Step Functions 、 Amazon Simple Storage Service（Amazon S3） など）を活用しています。 以下の手順は、Guten ユーザーの典型的なワークフローを説明しています： AWS Step Functions は、S3 バケットに保存されている人間が評価した記事の処理をオーケストレーションします 人間が評価した記事を使用して、Guten のモデルサービスは Cohere Embed v3 を使用してベクトル埋め込みを生成します。ベクトル埋め込みは、コサインやユークリッド類似度などの組み込みアルゴリズムでセマンティック検索をサポートする Amazon OpenSearch Service ナレッジベースに保存されます ジャーナリストは、AWS Fargate・Amazon ECS で実行されている Web アプリケーションである Guten UI を使用して、ドラフトを生成するためのソースコンテンツを選択します Guten のモデルサービスは、ナレッジベースを使用してターゲットとなる出版物から類似の記事を取得し、Amazon Bedrock のモデル（ Anthropic の Claude Sonnet 4 など）を使用してドラフトを生成します ジャーナリストは生成されたすべてのコピーの human-in-the-loop レビューを実行し、必要な変更を加えてから、Guten UI を使用して最終記事をコンテンツ管理システムに公開します 図 1：Guten AWS アーキテクチャ 責任ある AI を活用して採用を拡大 Guten の採用を拡大する際、Reach は安全性を指針原則としました。生成 AI は非常に有能で強力ではありますが、読者の信頼を損なうような誤った情報（ハルシネーション）を返したり、ブランドのスタイルを捉えていない言葉遣いをするなど、独特のリスクをもたらします。 Reach はモデル出力のハルシネーションを減らすために Guten を継続的に改善しています。ジャーナリストはこのリスクを理解し、モデル出力の間違いを特定して解決するメカニズムを支援しています。Guten は生成された全ての出力に対して human-in-the-loop レビューを促進するように設計されています。ジャーナリストは最終公開前にコンテンツを簡単に修正または変更できます。こうした仕組みによりビジネス全体での Guten の採用が加速されました。 パブリッシャー業界特有のもう一つのリスクは引用の忠実性です。引用部分が情報源と同一であるようにすることです。情報源を誤って引用することは重大な法的影響をもたらす可能性があるため、Guten の UI で引用の変更を検出した場合にユーザーに警告します。さらに、Guten のモデル評価には引用の忠実性のスコアリングが組み込まれており、情報源と生成された引用部分が異なる可能性を減らしています。 さらに Guten は情報源と生成されたテキストの両方のコピーから抽出されたエンティティの不一致を強調表示します。これらには、人、場所、日付などのカテゴリが含まれます。抽出されたエンティティの違いは、ハルシネーションを示している可能性があり、特別な注意が必要です。 ブランドスタイルの捕捉 120 以上の Reach のブランド固有の文体や編集方針を捉えることは、重要な技術的課題となっています。文体を不正確に捉えてしまうと、生成後に過度な編集が必要となり、記事の公開までの時間に悪影響を及ぼします。 以下は、Reach のブランドやコンテンツにおけるスタイルとトーンの違いの一部です： 政治的傾向の完全なスペクトラム（ The Express と The Mirror の間など） 幅広いターゲット読者層— OK! Magazine のような出版物は有名人やエンターテインメントなどの特定のトピックに焦点を当て、 In Your Area は地元のニュース、情報、コミュニティに焦点を当てています アメリカのコンテンツは、アメリカの言語慣習に合わせてローカライズする必要があります Reach のデータサイエンスチームは人間とルールベースの評価の両方を使用して、モデル出力を配信先のコンテンツに合わせて調整します。使用される評価は常に変化しており、継続的な実験のポイントとなっています。Guten はタイトルと記事本文の生成の両方で、コンテンツ固有のデータを活用してモデル出力を差別化します。Reach のジャーナリストからのフィードバックは緊密なフィードバックループを確立するために不可欠であり、責任ある AI の導入に必要な信頼関係を構築します。 現在、Guten はユーザーのフィードバックを提供する 3 つのメカニズムを提供しています： 見出しと記事生成の サムズアップ/ダウンのフィードバック は、モデルのバリエーションを分割テストする際のユーザー満足度のシグナルとして機能します ジャーナリスト は、特定の生成された記事に対してテキストベースのフィードバックを提供できます ユーザー は UI を通じてバグと製品機能リクエストの両方を直接送信でき、長期的に Guten の改善に役立ちます 絶え間ない革新と進化 ニュースは決して休むことがなく、Reach も Guten の機能を革新し進化させ続けています。Reach は以下の機能を積極的に開発しています： 生成 AI を使用したコンテンツ推薦により、ワイヤーコンテンツ、出版物、ジャーナリストのマッチングにかかる時間を節約 SEO パフォーマンスを向上させるための画像推薦と選択の最適化 オーガニックページビューに影響を与えるソーシャルメディアチャネルの最適化とオーケストレーション 結論 Guten はデータサイエンス、データエンジニアリング、従来のソフトウェアエンジニアリング技術（AWS サービスを活用）の適用を Reach の編集プロセスと統合しています。彼らはコンテンツの公開に至るまで、更には異なるブランドやコンテンツ間でも、プロセスを正確に加速することができます。編集プロセスから逆算し、ユーザーフィードバックを深く理解することで、Reach は生成 AI を活用し、ジャーナリストが倫理的に影響力のあるジャーナリズムを提供できるよう支援し続けています。 パブリッシャーのワークフローを強化する AWS のメリット については、AWS の Media &amp; Entertainment 業界の担当者に 連絡 して詳細をご確認ください。 参考文献 &nbsp; Introducing Claude 4 in Amazon Bedrock, the most powerful models for coding from Anthropic Increase engagement with localized content using Amazon Bedrock Flows Enabling publishers to customize content while maintaining editorial oversight with Amazon Bedrock How UK’s Reach is using AI to help produce more content faster Reach plans to move 300 journalists into central traffic-driving content hub 翻訳はソリューションアーキテクトの向井が担当しました。 <!-- '"` --> Benjamin Le Benjamin Le は AWS の通信、メディア、エンターテインメント、ゲーム、スポーツチームのソリューションアーキテクトで、パブリッシャーやインターネットサービスプロバイダーと協働しています。生成 AI（Generative AI）ソリューションを使用してお客様のビジネス変革の加速を支援しています。

※ この記事はお客様に寄稿いただき、AWS が加筆・修正したものとなっています。 株式会社 AJA は、 株式会社サイバーエージェント のグループ会社として、 ABEMA をはじめとしたプレミアム動画メディア向けの広告マーケットプレイス「AJA SSP」を提供しています。さらに、広告主向けプラットフォーム「AJA DSP」や、動画の考査を最短かつ簡便に行える「AJA Video Platform」、地上波テレビ CM の視聴データを活用しコネクテッド TV へ効果的に広告配信を行う「インクリー」、地上波テレビ CM の広告効果をデジタル広告と同一指標で評価・可視化できる運用サービス「ミエル TV」など、多彩なプロダクトを展開しています。これらのサービスを通じて、AJA は優良メディアの収益向上と企業の多様なマーケティング課題の解決に積極的に取り組んでいます。 AJA SSP ではペタバイトスケールのデータ基盤を運用していますが、ビジネスがますます成長していく中で、アドホックなクエリのパフォーマンスや AJA DSP のデータとの統合的な分析に課題が生じていました。これらの課題を解決するために、 Apache Iceberg を使ったアーキテクチャを導入しました。 Iceberg は大規模なデータを効率的に扱うことができるオープンなテーブルフォーマットで、 Apache Spark や Trino 、 Apache Flink といった様々なエンジンやサービスがサポートしています。 Apache Parquet のような列指向データファイルと、テーブル単位の統計データを含むメタデータファイルから構成されており、これによってファイルレベルのプルーニングを効率よく行うことができます。 AWS では Amazon EMR や Amazon Athena 、 Amazon Data Firehose といったサービスで Iceberg テーブルを読み書きすることができ、 AWS Glue Data Catalog の自動コンパクションといった運用をサポートする機能も提供されています。 本ブログでは、Iceberg や AWS のサービスを活用して、AJA SSP が課題解決に挑んだ取り組みについて述べます。 課題 AJA SSP では主に広告配信におけるプランニングやレポーティング、コンテンツ分析のために毎時 Amazon Managed Workflows for Apache Airflow (MWAA) で Spark のバッチ集計ジョブを実行しています。各集計ジョブは依存関係を持ち、再集計を行うこともあります。そのため直感的な構文で依存関係を定義し、また特定期間の同一ジョブをまとめて実行することができる Airflow を利用しています。これによって集計されたテーブルはメディアの広告枠の設定などを行う管理画面のレポート機能やアドホックな分析で Athena から参照されています。 ビジネスの成長に伴い、組織としてもこれまで以上にデータを活用していく動きが進む中で 2 つの課題がありました。 ひとつはアドホックなクエリのパフォーマンスです。以前と比べて複雑な分析やトラブルシューティングを行うようになり、レポーティングのための集計済みサマリーテーブルでは粒度が大きすぎるため、生のログに近いテーブルを参照する機会が増えてきました。しかしそのようなテーブルは 1 日あたり数 TB ほどになり、数ヶ月にわたって参照したり複雑な JOIN を行ったりすると、Athena のクエリの完了まで数十分かかったり、scale factor 起因のリソース枯渇を示すエラーで失敗することもありました。 もうひとつはプロダクトを跨いだデータの分析です。AJA SSP は AWS 上、AJA DSP は他社クラウド上で動いていることもあり、手動でデータをエクスポートしアップロードするといった運用が行われていました。その結果、分析に時間を要し、また再利用性やデータの鮮度も低下していました。あわせて、組織のデータを最大限活用できるようにしつつも、意図しない用途でデータが利用されないよう適切なアクセス権限の設定も必要でした。 取り組み この 2 つの課題を解決するため Iceberg を中心とした構成に移行しました。 アドホックなクエリを実行する基盤として Snowflake を採用しました。Snowflake は各種クラウド上で動くフルマネージドなデータプラットフォームで、コンピューティングリソースであるウェアハウスのサイズを大きくすることで重いクエリにも対応でき、ウェアハウスを自動で起動、シャットダウンさせることにより、実行したクエリに対する従量課金のように利用することができます。アクセス制限に関してはテーブルだけではなく行や列に対してもかけることができます。また、Snowflake を使っている他の組織とのデータ連携が容易である点も採用する決め手となりました。 管理画面などのアプリケーションでは性能に関して課題がなく、新たに認証情報を与える必要がない Athena を引き続き利用する方針だったので、 Snowpipe などで Snowflake に S3 のデータをロードすることは Single Source of Truth (SSOT) の観点で望ましくありませんでした。S3 を外部テーブルとして参照すればこの点は解消できますが、Snowflake 側にもスキーマ定義が必要となり、スキーマの二重管理の懸念がありました。一方で Iceberg テーブルとして作成すると、Snowflake 側でのスキーマ定義が不要となりスキーマまで含めた SSOT を実現できます。さらに Glue Data Catalog を参照 することで Iceberg のメタデータファイルのパス を渡すことなくテーブル名だけで最新のデータを参照することができます。 // Snowflakeで実行するDDL // カタログ統合を作成 CREATE CATALOG INTEGRATION IF NOT EXISTS GLUE_CATALOG_INTEGRATION CATALOG_SOURCE = GLUE CATALOG_NAMESPACE = '(database_name)' TABLE_FORMAT = ICEBERG GLUE_AWS_ROLE_ARN = 'arn:aws:iam::...:role/...' GLUE_CATALOG_ID = '...' GLUE_REGION = 'ap-northeast-1' ENABLED = TRUE; // 外部ボリュームを作成 CREATE EXTERNAL VOLUME IF NOT EXISTS AJA_SSP_ICEBERG STORAGE_LOCATIONS = ( ( NAME = 'AJA_SSP_ICEBERG' STORAGE_PROVIDER = 'S3' STORAGE_BASE_URL = 's3://...' STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::...:role/...' ) ); // AWS Glue Data Catalogに登録されているIcebergテーブルを使用して、Apache Icebergテーブルを作成 CREATE OR REPLACE ICEBERG TABLE TABLE_NAME CATALOG = GLUE_CATALOG_INTEGRATION, EXTERNAL_VOLUME = AJA_SSP_ICEBERG, CATALOG_TABLE_NAME = '(table_name)', CATALOG_NAMESPACE = '(database_name)', AUTO_REFRESH = TRUE; 他社クラウドのデータも含めて Iceberg に統一することで同様の手順でデータを参照することができ、用途に応じて自由にクエリエンジンを選択できる環境が整いました。 Spark での Iceberg テーブルの読み書き方法については従来と大きく変わりませんでした。移行中は新旧両方のテーブルに書き込んでいます。 /* 旧テーブルへの書き込み */ df.write.mode(SaveMode.Overwrite).parquet(s"s3://.../ymd=.../hour=...") /* Spark で Glue Data Catalog や S3 と合わせて Iceberg を利用する際の設定 "spark.sql.catalog.iceberg": "org.apache.iceberg.spark.SparkCatalog", "spark.sql.catalog.iceberg.warehouse" : "s3://.../", "spark.sql.catalog.iceberg.catalog-impl": "org.apache.iceberg.aws.glue.GlueCatalog", "spark.sql.catalog.iceberg.io-impl": "org.apache.iceberg.aws.s3.S3FileIO", "spark.sql.extensions": "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions", */ /* 新テーブルへの書き込み */ df.writeTo(s"iceberg.(database_name).(table_name)")).overwritePartitions() ただ、運用にするにあたってテーブルのスキーマをどう定義するかという問題があります。 従来のテーブルは AWS CDK で作成していたのですが、現状 CDK で Iceberg テーブルを作成し、スキーマの更新などを行うと Iceberg テーブルとして扱われなくなるという 課題 があります。そのため、当初は Amazon Athena for Apache Spark の Notebook から手動で CREATE TABLE を実行していましたが、本格的な運用が始まりバージョン管理に乗せるにあたって、宣言的にスキーマを定義できたり SQLFluff でフォーマットをかけられるといった点で、 dbt 公式の Athena アダプタである dbt-athena で 0 件のレコードを append することでテーブルの作成およびスキーマの更新のみを行うようにしました。 {{ config( materialized = 'incremental', incremental_strategy = 'append', table_type = 'iceberg', format = 'parquet', s3_data_naming = 'table', on_schema_change = 'append_new_columns', partitioned_by = ['ymd', 'hour'] ) }} SELECT CAST(NULL AS DATE) AS ymd, CAST(NULL AS INT) AS hour, ... WHERE false しかし、この方法は特定のテーブルプロパティしか設定できず、パーティションが更新できないといった Athena 由来の制約があります。AJA DSP では先んじて dbt による集計に移行し、 Cosmos で dbt の model を Airflow の DAG に変換して動かしていることもあり、 AJA SSP でも将来的には集計ごと dbt-spark に移行することも検討しています。 ちなみに、集計ジョブは従来 EMR on EC2 で動かしていましたが、配信サーバーの Amazon Elastic Kubernetes Service (EKS) 移行に伴い、 EMR on EKS に移行し、同じクラスタで Spark のジョブも動かすようにしました。これにより配信サーバーと集計でクラスタ管理の知見を共用できるようになったことに加え、余剰リソースを集計に割けるようになり、また、集計分のリソースを配信サーバーがスケールアウトする際のバッファとして用いることもできるようになりました。 パフォーマンス 普段実行されているクエリの中からプルーニングが十分効くであろうクエリを選んで比較してみました。 70 TB ほどのログの中から特定リクエスト ID のレコードを抽出するクエリを Athena で 実行したところ、Parquet では 49 秒かかっていたのに対して同じパーティション粒度の Iceberg では 8 秒で完了しました。 加えて、Glue Data Catalog の統計情報の生成ジョブを実行し JOIN に用いるカラムの Number of Distinct Values (NDV) を含む Puffin ファイルを生成したところ、クエリでの順番にかかわらず、ハッシュテーブルが小さくなるように JOIN の順番が最適化されることも確認できました。 なお、次のテーブルプロパティを設定することで Parquet ファイルに Bloom Filter が書き込まれるようになり、カーディナリティが高いカラムにおいて Row group に特定の値のデータが存在し得るかの判定が効率化されることが期待されます。しかし今回のケースでは、スキャン量のみが増加する結果となりました。 ALTER TABLE (database_name).(table_name) SET TBLPROPERTIES ( 'write.parquet.bloom-filter-enabled.column.(col_name)' = 'true', 'write.parquet.bloom-filter-max-bytes' = '10485760', 'write.parquet.bloom-filter-fpp.column.(col_name)' = '0.01' ) /* $ parquet bloom-filter xxx.parquet -c (col_name) -v aaa,bbb,ccc Row group 0: -------------------------------------------------------------------------------- value aaa maybe exists. value bbb NOT exists. value ccc NOT exists. */ 続いて、特定パターンでの週間リクエスト数とユニークユーザー数の集計は、スキャン量は 15 GB 程度ですが時間のかかるクエリでした。元々の Athena + Parquet では 5 分かかっていましたが、Iceberg にすることで 103 秒で実行でき、スキャン量も 5 GB まで減りました。さらに Snowflake の X-Large ウェアハウス では 77 秒、4X-Large では 15 秒まで短縮することができ、リソースを増やして高速にクエリを実行する選択肢ができました。 Iceberg を採用することで、従来の Athena のクエリも高速化しました。Athena は実行したクエリでスキャンされたデータ量に基づいて計算される従量課金なので、スキャン量が減ったことでコストも削減できました。さらに、Snowflake では、ウェアハウスを大きくすることでさらなる高速化が実現できました。結果として、Iceberg でコストパフォーマンスを改善しつつ、求める要件によって柔軟にクエリエンジンを選べるようになりました。 最後に AJA SSP では Iceberg の採用によって、エンジンが柔軟に選択できるようになり、クエリのパフォーマンスも向上したことで分析サイクルを高速に回せるようになりました。ひとつ目の課題として挙げたアドホックなクエリのパフォーマンスは、Iceberg との組み合わせによりクエリエンジンを問わず効果が確認されています。2 つ目の課題であったプロダクトを跨いだデータの分析も、AJA SSP、AJA DSP それぞれの Iceberg フォーマットのデータを Snowflake から参照することによって SSOT で実現できました。Iceberg というオープンなテーブルフォーマットで S3 に保持しておくことは、耐久性やコストパフォーマンス、技術選定の自由度の高さといった点でも利点があると考えています。 今後の AWS の機能拡充にも期待しています。Iceberg への移行にあたり AWS の皆様には技術的な相談に乗っていただき感謝申し上げます。 著者 坂本 泰規（Taiki Sakamoto） 株式会社 AJA, データマネージメントチーム リーダー 半場 光晴（Mitsuharu Hamba） アマゾンウェブサービスジャパン合同会社, ソリューションアーキテクト &nbsp;

北半球の AWS Summit はほぼ終了しましたが、地球のそれ以外の地域にいる私たちにとって、楽しみと学習はまだ終わっていません。先週の AWS Summit Mexico City と AWS Summit Jakarta では、コミュニティ、お客様、パートナー、AWS 従業員が学習とネットワーキングの 1 日を満喫しました。 撮影: Nelly Andrade (AWS Summit Mexico City) 撮影: Shafraz Rahim (AWS Summit Jakarta) 8 月 4 日週のリリース 私が注目した 8 月 4 日週のリリースをご紹介します。 AWS での OpenAI オープンウェイトモデル – OpenAI オープンウェイトモデル (gpt-oss-120b と gpt-oss-20b) を AWS で利用できるようになりました 。オープンウェイトモデルは、コーディング、科学的分析、数学的問題解決に優れており、主要な代替モデルと同等のパフォーマンスを発揮します。 Amazon Elastic VMware Service – VMware Cloud Foundation (VCF) 環境を Amazon Virtual Private Cloud (Amazon VPC) 内で直接実行できるようにする新しい AWS サービス、Amazon Elastic VMware Service (Amazon EVS) の一般提供を開始しました 。 自動推論チェック – AWS re:Invent 中にプレビューした新しい Amazon Bedrock のガードレールポリシーである自動推論チェックの一般提供を開始しました。自動推論チェックは、基盤モデル (FM) によって生成されたコンテンツの正確性をドメインの知識に照らして検証するのに役立ちます。これが AI のハルシネーションによって引き起こされる可能性がある事実誤認を防ぐのに役立つ方法について詳しくは、 Danilo による記事 をご覧ください。 マルチリージョンアプリケーションのリカバリサービス – この記事 で、Sébastien が Amazon Application Recovery Controller (ARC) のリージョン切り替えの発表について書いています。これは、組織が自信をもってリージョン切り替えを計画、練習、オーケストレートできるようにし、リージョン間のリカバリオペレーションに関する不確実性を排除する、可用性の高いフルマネージド機能です。 その他のアップデート 興味深いと感じたプロジェクト、ブログ記事、ニュース記事をご紹介します。 Amazon Simple Queue Service (Amazon SQS) – Amazon SQS は、 メッセージのペイロードの最大サイズを 256 KiB から 1 MiB に増やしました 。これにより、お客様は Amazon SQS 標準キューと FIFO キューを通じて、より大きなメッセージを送受信できるようになりました。 AWS Lambda が GitHub Actions のサポートを開始 – AWS Lambda では GitHub Actions を使用して、コードまたは設定の変更を GitHub リポジトリにプッシュしたときに、GitHub Actions を使用して Lambda 関数を自動的にデプロイできるようになりました 。これにより、サーバーレスアプリケーションの継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインが合理化されます。 Amazon DynamoDB での Console-to-Code – Amazon DynamoDB は、 Amazon Q Developer を利用した Console-to-Code のサポートを発表しました 。Console to Code では、自動化コードの使用を開始することで、大規模な DynamoDB リソースを簡単かつ迅速に、費用対効果の高い方法で作成できます。 AWS ヒーローの Faye Ellis 氏 が作成した このコースを受講すると、Amazon Lex を使用した会話型 AI について詳しく学ぶ ことができます。このコースは無料トライアルの一環として、無料でご利用いただけます。 AWS コミュニティビルダーの Raphael Manke 氏 は、 非公式な AWS re:Invent セッションプランナー 2025 を公開しました。このプランナーは、数年前に初めてリリースされて以来、毎年大いに待ち望まれています。 AWS ヒーローの Rosius Ndimofor 氏 は、 Educloud Academy を構築しました。このプラットフォームの恩恵を受けているコミュニティメンバー ( 最新の Cloud and AI Challenge に参加しているこのビルダー など) による話は心温まるものです。 近日開催予定の AWS イベント 今後のイベントにぜひご登録ください。 AWS re:Invent 2025 (2025 年 12 月 1 日〜5 日、Las Vegas) — AWS の主力年次カンファレンスでは、ピアツーピア学習、専門家主導のディスカッション、貴重なネットワーキングの機会を通じて、共同イノベーションを提供します。 AWS Summit – クラウドコンピューティングコミュニティが集まり、交流し、協力し、AWS について学ぶことができる無料のオンラインイベントと対面イベントにご参加ください。 間もなくサンパウロ (8 月 13 日) と ヨハネスブルグ (8 月 20 日) で AWS Summit が開催されます。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18 日)、 南アフリカ (9 月 20 日) です。 AWS Builder Center に参加して、AWS コミュニティで AWS ビルダーとともに学び、構築し、交流しましょう。今後開催される追加の 対面イベント と デベロッパー向けのバーチャルイベント をこちらでご覧ください。 8 月 11 日週のニュースは以上です。8 月 18 日週にお届けする次回の Weekly Roundup もお楽しみに! – Veliswa 原文は こちら です。

この記事は Introducing the Amazon EKS Auto Mode workshop (記事公開日: 2025 年 4 月 15 日) を翻訳したものです。 本日、 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode の ハンズオンワークショップ を紹介できることを嬉しく思います。このワークショップは、お客様自身の AWS アカウントで実行することも、AWS が主催するイベントに登録して参加することも可能です。(訳注: ハンズオンワークショップの日本語訳を 2025 年 8 月に公開しました。) AWS での Kubernetes 運用を効率化する新機能である EKS Auto Mode は、 re:Invent 2024 で一般提供が開始 されました。EKS Auto Mode により、本番環境レベルの Kubernetes アプリケーションを大規模に実行するために必要なクラスターインフラストラクチャの管理に伴う運用オーバーヘッドを排除することで、組織のイノベーションを推進するアプリケーションの構築に集中できるようになります。本日紹介するワークショップは、EKS Auto Mode を使用して Kubernetes アプリケーションを迅速に起動するために必要な実践的な知識とスキルを提供することを目的としています。EKS Auto Mode の詳細については、 提供開始の記事 ならびに 入門 と 詳解 の記事をお読みください。 EKS Auto Mode ワークショップとは？ EKS Auto Mode ワークショップでは、Auto Mode を使用して Amazon EKS にワークロードをデプロイするために必要な知識を提供し、Kubernetes アプリケーションの実行に伴う運用オーバーヘッドをどのように効率化できるかを理解していただけます。ワークショップは一連の高レベルな学習モジュールに抽象化されており、各モジュールは前に習得した知識の上に構築されています。また、 EKS Auto Mode への移行方法 を扱う独立したラボもあり、オプションで完了することができます。ワークショップの完了には約 2 時間かかります。 ワークショップでは、以下の手順を実行します: EKS Auto Mode を有効にする方法を学ぶ: AWS Command Line Interface (CLI) 、Terraform、EKS CLI (eksctl)、またはコンソールなど、お好みのクラスター管理方法を使用して、既存のクラスターで EKS Auto Mode を有効にします。 アプリケーションのデプロイを習得する: Auto Mode を有効にすると、単一のコマンドだけで、追加の設定を必要とせずにアプリケーションをデプロイできます。EKS Auto Mode はアプリケーションの要件を評価して最適なコンピューティングインスタンスを選択・起動し、リソースを動的にスケーリングし、コストを継続的に最適化します。 EKS Auto Mode の組み込み機能を発見する: すでにデプロイされた Retail Store アプリの異なるコンポーネントを段階的に変更します。これにより、コンピューティング、オートスケーリング、ネットワーキング、ストレージで利用可能な様々な機能と設定オプションを深く理解できます。このモジュールの終了時には、ステートフルとステートレスの両方のコンポーネントを持つ、高可用性、自動スケーリング、ロードバランシング、外部アクセス可能なアプリケーションのセットをデプロイしたことになります。これらは完全に機能する Retail Store サンプルアプリケーションを形成します。 効率化されたクラスターアップグレードを体験する: EKS Auto Mode がクラスターアップグレードを完了させるプロセスをどのように効率化するかを理解し、次の Kubernetes バージョンへのアップグレードを実行する実践的な経験を積むことができます。 既存ワークロードの移行方法を理解する: クラスターにすでにデプロイされているアプリケーションを EKS Auto Mode に移行する方法を学ぶことができます。このモジュールは、必要ない場合はオプションです。 このワークショップの終了時には、EKS Auto Mode により AWS がどのように運用責任を拡大するかを理解できるようになります。これにより、AWS で Kubernetes アプリケーションを起動することがはるかに明確になり、今日から始めるために必要なすべての知識を得ることができます。 ワークショップの対象者は？ このワークショップは L300 レベルで、Kubernetes と Amazon EKS の基本的な理解を持つユーザー向けに設計されています。 お客様自身のアカウントで実行するための前提条件 AWS アカウントで EKS Auto Mode ワークショップを開始するには、まずワークショップで使用するベースラインインフラストラクチャをプロビジョニングします。これらの手順を自動化するために、ワークショップでは AWS CloudFormation を使用します。内部的には、CloudFormation テンプレートが 2 つのクラスターをプロビジョニングします: 1 つは EKS Auto Mode の開始用、もう 1 つは Amazon EKS から EKS Auto Mode への移行パターンのデモンストレーション用です。CloudFormation を使用してワークショップ環境をデプロイする方法については、 お客様自身の AWS アカウントでの開始方法 の手順を参照してください。 ワークショップのナビゲーション方法は？ ワークショップ環境がデプロイされると、CLI コマンドを通じて手順が完了します。ワークショップのすべてのコマンドについて、手順内の任意の場所を左クリックしてコマンドをコピーするか、次の図に示すように右上角のクリップボードアイコンを選択してすべてのコマンドをコピーできます。 図 1: ワークショップのコマンド例 ワークショップの作業を開始するためのセットアップ時間を短縮するため、 Amazon Elastic Compute Cloud (Amazon EC2) 上に Visual Studio Code Server IDE がプロビジョニングされ、ワークショップに必要なすべてのバイナリと設定が事前に読み込まれています。これには、kubectl、aws、eksctl などの CLI ツールが含まれます。IDE へのアクセス方法については、この 開始ガイド で確認できます。 リソースのクリーンアップ ワークショップが完了したら、プロビジョニングしたリソースをクリーンアップする必要があります。リソースをクリーンアップする手順は、 ワークショップの最後 に記載されています。 まとめ Amazon EKS Auto Mode ワークショップにより、お客様は新しい EKS Auto Mode 運用モデルの使用方法について実践的な知識を得ることができます。ワークショップ環境をデプロイしてセルフガイドの体験を 今日から始め 、ワークショップモジュールのステップバイステップの手順に従ってください。 EKS Auto Mode ワークショップの AWS が主催するイベントに参加するには、お客様に適した日時に登録してください。 また、 Amazon EKS コンソール で EKS Auto Mode を試すか、 Amazon EKS ユーザーガイド のドキュメントをご確認ください。 コントリビューター 著者は、Amazon EKS Auto Mode のこの新しいワークショップの開発において貴重な支援をいただいた以下の方々に感謝いたします: Ahmed Azzam、Alexander Pinsker、Borja Perez Guasch、Chakkree Tipsupa、Dmitry Nutels、Erez Zarum、Estefany Kuong Montalvan、Karan Thanvi、Mike Rizzo、Niall Thomson、Raymond Zhou、Robert Northard、Sai Vennam、Sebastien Allamand、Sheetal Joshi、Tsahi Duek、Vicky Whittingham。 訳者は、このワークショップを日本語に翻訳いただいた以下の方々に感謝いたします: Niall Thomson、Tsahi Duek、落水 恭介、林 政利。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

はじめに 高度に接続された現代社会では、モノのインターネット（IoT）機器が、家庭やオフィス、産業との関わり方を一変させています。スマートテクノロジーは今や家庭から自動車、産業機器にまで普及しています。これらのデバイスをリモートで制御することは不可欠であり、生産性、ユーザーエクスペリエンス、リスク管理の向上をもたらします。このブログでは、AWS IoT デバイスに安全かつ効果的にリモートコマンドを送信する方法について説明します。 IoT デバイスにリモートアクションを送信することは、スマートソリューションを構築する上で重要な要件です。リモートコマンドは、ユーザ、オペレータ、技術者が離れた場所からデバイスを制御、監視、管理することを可能にします。ユーザーは、物理的にその場にいなくても、デバイスのオン/オフ、設定値の調整、データの取得など、リアルタイムに近いアクションを行うことができます。リモートコマンドの送信は、自動車、ヘルスケア、製造、輸送、スマートホームなど、リモートデバイス管理によって効率の向上、コスト削減、全体的な運用の柔軟性の向上を行うことのできるような業種では極めて重要になっています。 リモートコマンドを送信するために、カスタムのソリューションやワークアラウンドを自前で開発し、IoTソリューションの機能を強化・拡張するケースがこれまでもありました。しかしながら、このような自社開発のソリューションは、時間が経つにつれて複雑化し、スケールさせるのが難しくなりがちで、インフラや運用コストを増加させることがあります。こうした課題に対処するため、AWS はリモートアクションの実行のライフサイクル管理を行う機能として AWS IoT Device Management コマンド をリリースしました。 概要 コマンド機能は、クラウドとデバイス間の双方向通信を可能にする　MQTT 標準に基づいたリモートアクション機能です。コマンド機能を使用することで、細かなアクセス制御メカニズムを実装し、承認されたユーザーのみが特定のデバイスにコマンドを送信できるようにすることができます。一般的な使用例には、デバイスアクションの開始、デバイス状態の更新、デバイス構成の変更があります。 コマンド機能は、個々のデバイスに対してリモートアクションを配信するための、細かいアクセス制御と効率的なデバイス管理ツールを提供します。 この機能は AWS IoT コンソールのリモートアクションのセクションからアクセスでき、JavaScript Object Notation (JSON)、Concise Binary Object Representation (CBOR)、Parquet、プレーンテキストなど、さまざまなデータ形式に対応した、カスタマイズ可能なデータペイロードを持つ一意の名前を持ったコマンドを作成することができます。 一度定義されたコマンドは、異なるターゲットデバイスに対して何度でも使用することができます。各コマンドの実行に対して特定のタイムアウト時間を設定したり、リアルタイムの更新と通知を通じてそのコマンド進行状況を監視することできます。以下のワークフローと手順は、コマンド機能の概要を説明しています。 図 1: AWS IoT デバイス管理コマンド機能のワークフロー AWS IoT Device Management を使ってデバイスにコマンドを送信する: 事前定義された再利用可能なコマンドを作成し、AWS IoT Device Management コマンドに保存する。 ターゲットデバイスに送信するコマンドのペイロードを指定する。 デバイスタイプを AWS IoT Thing もしくは MQTT client のどちらかに指定する。 デバイスは以下に示すコマンドトピックをサブスクライブする。 $aws/commands/[things|clients]/[&lt;thingname&gt;|&lt;clientId&gt;]/executions/+/request/ [json|cbor] ここに IoT コマンドが送信される。 クライアントアプリケーションを通してユーザがコマンドをトリガーし、それぞれのデバイスのリクエストトピックにコマンドのペイロードが送信される。 デバイスはリクエストトピックでコマンドペイロードを受信すると、想定されているアクションを行い、クラウドにレスポンスを送る。 デバイスは以下のトピックにコマンドの実行の進捗とステータスアップデートを送信する。 $aws/commands/[things|clients]/[&lt;thingname&gt;|&lt;clientId&gt;]/executions/&lt;executionid&gt;/response/[json|cbor] . コマンドサービスは $aws/events/commandExecution/&lt;CommandId&gt;/+ にNotificationをパブリッシュし、ユーザーは Notification を受け取る。( 注意: Notification の受信はオプションで、AWS IoT を通じて設定することが可能です。) AWS Device Management コマンドの主要な機能は以下となります: 単一のデバイス上で複数のコマンドを実行するための並列制御。 AWS IoT に登録されていないデバイスに対してのオペレーションサポート。 各コマンドの実行時間の上限を制御し、適切なタイミングでの完了を保証するための時間制限の設定。 コマンドの進捗状況のリアルタイムな更新。 セキュアなコマンドの送信と細かなアクセス制御。 リモートアクションを IoT デバイスに送信するための実際のユースケース AWS IoT Device Management コマンドはスマートホームや産業向け IoT 、車両のフリート管理アプリケーションにおいて、カスタムの MQTT ソリューションの構築を行うことなく、クラウドとデバイスの間の命令セットの送信を簡単化します。 スマートホーム OEM やスマートホームインテグレーターは、スマートフォンを使って住人が快適性、セキュリティ、エネルギーシステムを制御できるようリモートコマンド機能を実装することができます。 たとえば、スマートフォンから温度調節機能を用いて家に到着する前に暖房を入れたり、家を出たあとに消し忘れた照明をオフにしたりすることができます。 セキュリティカメラで異常なアクティビティを検知した場合は、リモートでドアの施錠、アラーム作動、あるいはスピーカーから話しかけることで不審者の侵入を防止することもできます。 休暇中には、指定した時間に照明やテレビのオンオフをスケジュール管理して不在を外部に知られなようにすることもできます。 天気予報に基づいて、設定を自動的に調整することも可能です。例えば、空調のコストをを下げるために暑い日にはスマートブラインドを閉じる、雨が降った場合には散水のスケジュールを調整する、といったことが可能になります。 産業向け IoT 大規模な製造工場では、IoT デバイスが製造ラインの機器やシステムに組み込まれ、プラント管理者がリアルタイムに近い形でリモートから製造のパラメータを調節することができ、需要の変動やサプライチェーンの不測の事態に対応することができます。センサーが機器の異常を検知した場合、リモートでの診断を行い、生産を停止することなく必要な調整を行うことができます。緊急時には安全プロトコルを起動し、特定の機器もしくはプラントのセクション全体を停止することができます。プラント管理者はリモートコマンドを用いて予兆保全を行い、リアルタイムに近い機器データを用いてメンテナンスのタスクをスケジュールし、ダウンタイムを最小化し、全体の運用効率を最適化することができます。 フリート管理 車両に搭載された IoT デバイスを用いて運輸会社はリモートで各種メトリクスをモニターすることができます。メトリクスには、リアルタイムの位置情報、燃料消費量、エンジンの状態、ドライバーの運転状況などが含まれます。フリート管理者は、機械的に問題のある車両の速度制限を下げることで損傷を事前に防ぐことができます。ドライバーがルートを外れた際には、ナビゲーションシステムの経路を変更することも可能です。悪天候の際には、フリート管理者は該当する車両に安全プロトコルを適用することもできます。さらに、リモートでの車両診断や、無線によるソフトウエアのアップデートを行うことができ、物理的なメンテナンスの必要性を減らすことができます。コマンド機能を使ったフリート管理ソリューションは安全性を向上させ、ダウンタイムを減らし、フリート全体にかかるメンテナンス費用を大幅に削減することができます。 AWS IoT Device Management コマンドとジョブ機能の違い リモートでのオペレーションを定義して AWS IoT に接続されている１つ以上のデバイスに送付して実施する方法として AWS IoT Jobs &nbsp;を使用する事もできます。コマンドを使用するか Job を使用するかは、利用者の IoT ユースケースの要件と、利用者がデバイスで実施したいやり取りの性質に依存します。 コマンド機能の開始方法 AWS IoT Device Management のコマンド機能を用いた実際のユースケースの一例として、スマート洗濯機を構築する方法を説明します。 ユースケース: あるエンジニアが、リモートから制御可能なスマート洗濯機を開発していることを想定します。ユーザーはどこからでもモバイルアプリからスマート洗濯機を管理することができます。ユーザーはアプリを通してコマンドを送信することができ、洗濯のスタート、ストップ、洗濯タイプのような設定の調整、水の温度の設定、回転スピードの設定などを行うことができます。これらのコマンドは MQTT プロトコルを通じて洗濯機に送られます。オペレーション中にはスマート洗濯機は MQTT を通じてステータスのアップデートを送り、ユーザーに残り時間を示したり、現在のサイクルを表示したり、アラートがあればアラートを表示します。問題が発生した場合には、技術者が問題解決のためにリモートから洗濯機にアクセスし、デバイスの設定を変更したりすることもできますが、この機能は通常のユーザーには制限されます。この機能はどのようなモバイルアプリにも統合することができますが、今回は IoT バックエンドの実装にフォーカスしているので、モバイルアプリの開発とインテグレーションは割愛しています。. 仮定: ここでは、デバイスはすでに AWS IoT Core に登録されており、「SmartWasher」というモノの ID を取得しているものと仮定します。新規デバイス登録については、 AWS IoT workshop をご参照ください。 ここでは、コマンド実行の実装と監視の手順をステップバイステップで説明します: システムに必要なコマンドを作成します。 デバイスが発行されたコマンドを受け取れるように、関連するトピックへのサブスクライブを設定します。 デバイスにて新しい「コマンド実行」を行うためにコマンドを起動します。 デバイスから実行ステータスをパブリッシュし、トラッキングアプリケーションで進捗を監視します。 重要なお知らせ: コマンドの作成と管理は、AWS SDK、AWS CLI、AWS 管理コンソールなど複数の方法で行うことが可能です。 このブログで紹介するサンプルでは、コマンドの作成と管理を AWS CLI と AWS 管理コンソールで実施します。 ステップ 1: コマンドの作成 スマート洗濯機の 3 つの主要機能を行うコマンドを作成しましょう。1. 既定の設定で通常の洗濯サイクルを開始する。2. 洗濯サイクルを終了する。3. 技術者が診断システムを実行し、診断データにアクセスできるようにする。 コマンド 1: 通常の洗濯サイクルを開始する AWS IoT で新しいコマンドを作成するには、AWS マネジメントコンソールにアクセスし、AWS IoT サービスに移動します。 そこで、左側のサイドバーにある「Manage」セクションを探し、「Remote actions」をクリックして「Commands」を選択します。 「Create Command」ボタンをクリックしてプロセスを開始します。 プロンプトが表示されたら、Command ID に「StartDefaultCycle」と入力します。 次に、必要なペイロードを含む JSON ファイル (　詳細は startdefaultcycle.json として以下に示されています) を作成する必要があります。 コマンド作成インターフェースの「Specify payload」セクションで、この JSON ファイルをアップロードします。 すべての詳細が正しいことを確認したら、「Create Command」ボタンをクリックしてプロセスを完了させ、新しいコマンドを AWS IoT システムに追加します。 startdefaultcycle.json &nbsp; { &nbsp;&nbsp;&nbsp; "Action": "RunWashCycle", &nbsp;&nbsp;&nbsp; "CycleType": "Normal", &nbsp;&nbsp; "Soak": "Yes", &nbsp; &nbsp; "SpinSpeed": "Medium", &nbsp;&nbsp; "WaterTemperature": "Warm" } 図 2: 通常サイクルの新しいコマンドを作成する コマンド 2: サイクルを停止する 以下のペイロードを使用して、洗濯機の停止コマンドを作成してください。 stopcycle.json { &nbsp; "Action": "StopWashCycle" } コマンド 3: 診断情報の取得 トラブルシューティングのために、このペイロードを使用して洗濯機のログを取得するコマンドを作成してください。 retrievediagnostics.json { &nbsp;&nbsp; "Action": "RetrieveLogs", &nbsp;&nbsp;&nbsp; "LogType": "DiagnosticMetrics", &nbsp; &nbsp; "TimeRange": "12Hr" } コマンドのホームページには、作成されたコマンドが表示されます。 図 3: AWS マネジメントコンソールのコマンドホームページ 作成したコマンドは、アクションメニューから管理することが可能です。オプションからは、設定の編集、一時的な無効化、もしくは必要に応じて完全な削除を行うことができます。 ステップ 2: デバイスのセットアップとトピックへのサブスクライブ コマンドサービスは、新しい実行が開始されるたびに、ターゲットデバイスに MQTT で通知を行います。コマンド実行を受信すると、デバイスは構造化されたアクションのシーケンスを開始します。最初に、デバイスは MQTT メッセージのペイロードに基づき、受け取ったコマンドを解釈します。次に、要求されたアクションを実行します。実行後、デバイスはクラウドに実行ステータスを報告し、操作が成功したか、問題があったかをレポートします。このようなコミュニケーションフローを実現するために、デバイスは、すべてのコマンド実行要求がパブリッシュされるリクエストトピックを購読する必要があります。コマンド処理後、デバイスは応答を指定された応答トピックに公開する必要があります。今回のシミュレーションでは、いくつかのシナリオをカバーするため、コマンド実行に成功した場合と失敗した場合の両方を実演します。 このブログでは、 AWS IoT Device SDK v2 for Python を使用して、スマート洗濯機をシミュレーションします。 リクエストトピック: $aws/commands/things/&lt;thing-id&gt;/executions/+/request/json サブスクリプションが成功したときのスマート洗濯機からのサンプルログ: 図 4: サブスクリプション出力を表示するターミナルウィンドウ レスポンストピック: $aws/commands/things/&lt;thing-id&gt;/executions/&lt;execution-id&gt;/response/json ステップ 3: コマンド実行 エンドユーザーにとって、スマート洗濯機とのインタラクションは、モバイルアプリなどのユーザーフレンドリーなアプリケーションインターフェースを通じて簡素化されています。今回のデモでは、CLI コマンドを使用してこの体験をシミュレートします。以下の CLI コマンドを実行すると、execution-ID が返されます。この一意の識別子は、コマンドの実行に関する情報を追跡および取得するために不可欠です。この ID を必ずメモしてください。以降のクエリで&lt;execution-id&gt; のプレースホルダーをこの execution-ID で置き換える必要があります。 注意：新しいコマンドの実行を開始するには、エンドポイントタイプを iot:Jobs として指定して、 DescribeEndpoint API を使用して固有のエンドポイントを取得してください。 通常の洗濯サイクルを開始する実行コマンド: サンプルリクエスト: aws iot-jobs-data start-command-execution \ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --command-arn arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/StartDefaultCycle \ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--target-arn arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:thing/SmartWasher \ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --execution-timeout-seconds 3600 \&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --endpoint-url &lt;endpoint-from-describe-endpoint-api-result&gt; サンプルレスポンス: { &nbsp;&nbsp;&nbsp; "executionId": "576fe4d7-c604-489d-af91-c37ca9f8303b" } StartCommandExecution API の呼び出しが成功すると、スマート洗濯機上で動作する MQTT クライアントが、リクエストトピックで MQTT メッセージを受信します。以下は スマート洗濯機で受信されたサンプルです。 図 5: MQTT メッセージを表示するターミナルウィンドウ ステップ 4: デバイスによるコマンド実行ステータスの更新 コマンド機能は、デバイスがクラウドに状態を報告するために UpdateCommandExecution MQTT トピックベースの API を提供します。上記の例では、スマート洗濯機が洗濯サイクルを開始すると、継続的に状態をクラウドに報告します。 スマート洗濯機からのステータス更新では、「SOAK」が完了したことを報告しています。AWS マネジメントコンソールのサンプル MQTT クライアントを使用して、洗濯機からのステータス更新をシミュレートします。洗濯機は、デバイスと実行に対して固有のレスポンストピックに実行ステータスを投稿します。 $aws/commands/things/SmartWasher/executions/&lt;execution-id&gt;/response/json { &nbsp; "status": "IN_PROGRESS", &nbsp; "result": { &nbsp;&nbsp;&nbsp; "SOAK": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "s": "COMPLETED" &nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp; "RINSE": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "s": "PENDING" &nbsp;&nbsp;&nbsp; }, &nbsp;&nbsp;&nbsp; "SPIN": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "s": "PENDING" &nbsp;&nbsp;&nbsp; } &nbsp; } } 開発者は、GetCommandExecution API を活用することで、アプリケーションにステータス監視機能を追加することができます。 ステップ5.1: エンドユーザー向けの進捗トラッキング（アプリケーション） エンドユーザーにコマンドの実行状況について通知するため、アプリケーションは定期的に GetCommandExecution API を呼び出し、特定のコマンド実行のほぼリアルタイムなステータスを取得できます。これにより、ユーザーは即時的に進捗をトラックすることができます。 実行ステータスを取得するためのサンプルリクエスト: aws iot get-command-execution --execution-id &lt;execution-id&gt; \ --target-arn arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:thing/SmartWasher ステップ 5.2: 管理者または技術者による進捗トラッキング 技術者および管理者は、指定されたコマンドのイベントトピックを使用して、フリート全体でのコマンドの実行状態を追跡できます。 $aws/events/commandExecution/&lt;command-id&gt;/&lt;CommandExecutionStatus&gt; この機能をテストするために、AWS IoT コンソールを利用できます。コンソールにログインし、MQTT テストクライアントに移動します。「トピックへのサブスクリプション」セクションで、上記のトピックを購読します。 図 6: コマンド実行ステータストピックをサブスクライブ 以下のコマンドのいずれかを実行し、生成される &lt;execution-id&gt; をメモしてください。MQTT テストクライアントを使用して、指定されたレスポンストピックにレスポンスを送信します。その後、メッセージがコマンド実行ステータストピックに正しく表示されることを確認してください。 図 7: レスポンストピックに成功のメッセージを送信 図 8: コマンド実行ステータストピックの結果を確認 図 9: レスポンストピックに失敗のメッセージをパブリッシュ 図 10: コマンド実行ステータストピックの結果を確認 ポリシー設定 セキュリティを強化するため、AWS IoT コマンドは、特定のユーザーのみが特定のデバイスにコマンドを送信する権限を付与できるように設定することができます。AWS IoT Core は、アイデンティティとアクセス管理（IAM）権限（ポリシーとも呼ばれる）を使用して、コマンド機能へのアクセスを制御します。これらのポリシーは、認証されたユーザーがデバイスにコマンドを送信できるかどうかを決定します。 IAM ポリシーは、個々のユーザー、グループ、またはロールに適用でき、特定のコマンドを実行できるユーザーを詳細に制御できます。例えば、スマート洗濯機システムに 3 つの異なるアクセス権限に応じたロールがあります: 管理者: スマート洗濯機のコマンドの作成と管理を担当します。このロールはシステム制御の最高権限を有します。 家族メンバー: 日常の洗濯作業で洗濯機を操作する一般ユーザー。アクセス権限は日常使用に必要な基本機能に限定されています。 技術者: 問題が発生した際にシステムのメンテナンスやトラブルシューティングを行う役割。診断や修理のための専門的な権限が与えられています。 以下のサンプル IAM ポリシーは参考の目的で提供されています。包括的なポリシー設定の手順については、 コマンドの作成と管理のドキュメント をご確認ください。セキュリティのベストプラクティスと最小権限の原則に従うため、 AWS IoT のIdentity and Access Management ガイド をご参照ください。これらの例はデモのためのものであり、実際の適用の場合には、相応のセキュリティ要件に合わせてポリシーをカスタマイズする必要あることに留意してください。 Policy1: 管理者ロール { &nbsp; "Version": "2012-10-17", &nbsp; "Statement": [ &nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp; "Action": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "iot:CreateCommand", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "iot:GetCommand", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "iot:UpdateCommand", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "iot:DeleteCommand" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Effect": "Allow", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Resource": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/*" &nbsp;&nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp;&nbsp; "Condition": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "ArnLike": { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "aws:PrincipalArn": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "arn:aws:iam::&lt;account-id&gt;:role/&lt;specific-role&gt;",&lt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"arn:aws:iam::&lt;account-id&gt;:user/&lt;specific-user&gt;"&lt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ] &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; } &nbsp; ] } Policy2:　家族メンバーおよび一般のユーザーロール { &nbsp; &nbsp;"Version": "2012-10-17", &nbsp;&nbsp; &nbsp;"Statement": [ &nbsp;&nbsp; &nbsp; &nbsp;{ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Action": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"iot:StartCommandExecution", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"iot:GetCommandExecution" &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;], &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Effect": "Allow", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Resource": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/StartDefaultCycle", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/StopWashCycle", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:thing/SmartWasher" &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;] &nbsp;&nbsp; &nbsp; &nbsp;} &nbsp;&nbsp; &nbsp;] &nbsp;} Policy3: 技術者ロール { &nbsp;&nbsp; &nbsp;"Version": "2012-10-17", &nbsp;&nbsp; &nbsp;"Statement": [ &nbsp;&nbsp; &nbsp; &nbsp;{ &nbsp; &nbsp; &nbsp; &nbsp;"Action": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"iot:StartCommandExecution", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"iot:GetCommandExecution" &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;], &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Effect": "Allow", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"Resource": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:command/RetrieveDiagnostics", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"arn:aws:iot:&lt;region&gt;:&lt;account-id&gt;:thing/SmartWasher" &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;] &nbsp;&nbsp; &nbsp; &nbsp;} &nbsp;&nbsp; &nbsp;] &nbsp;&nbsp;} まとめ 結論として、AWS IoT デバイス管理のコマンド機能は、IoT デバイスのコマンドをリモートで管理するための安全で効率的かつコスト効果の高い方法を提供し、優れたスケーラビリティを維持します。その軽量な設計、コスト効果の高い用途に応じた機能は、他のカスタム構築ソリューションに対し明確な優位性を提供します。スマートホームの管理であろうと産業施設の管理であろうと、コマンド機能は低遅延かつ高スループットのアプリケーションを開発する開発者に対して、クラウドからデバイスへのインタラクション、リモート監視、制御、診断をスケール可能な状態で実現します。これにより、ユーザーはどこからでもデバイスの制御が可能となります。 関連情報 AWS IoT Device Management のリモートコマンド実行 AWS IoT Device Management の料金 著者について Sara Akkandi は、Amazon Web Service（AWS）のソリューションアーキテクトとして、お客様と協力して well-architected のクラウドソリューションの設計と実装を支援しています。彼女の技術的な専門知識を活かし、組織が AWS のサービスとベストプラクティスを活用してビジネス上の課題を効果的に解決し、最適な結果を達成できるよう導いています。 Ryan Dsouza は、AWS のクラウドオプティマイゼーションサクセス組織においてプリンシパルソリューションアーキテクトを務めています。ニューヨーク市を拠点とする Ryan は、AWS の広範かつ深い機能を活用し、顧客がより安全でスケーラブルかつ革新的なソリューションを設計、開発、運用し、測定可能なビジネス成果を実現する支援を行っています。彼は、顧客がパフォーマンス、コスト効率、セキュリティ、耐障害性、運用 excellence を最適化するソリューションを設計するための戦略、ガイドライン、ツールの開発に積極的に取り組んでおり、AWS クラウド採用フレームワークと well-architected フレームワークに準拠したアプローチを推進しています。 この記事は Sara Akkandi, Ryan Dsouza によって書かれた Using AWS IoT Device Management commands to simplify remote actions on IoT devices の日本語訳です。この記事は&nbsp;プロフェッショナルサービス本部 シニアデリバリーコンサルタントの小林が翻訳しました。 <!-- '"` -->

この記事は Proven Practices for Succeeding with a Multicloud Strategy を翻訳したものです。 企業戦略家としての経験から、マルチクラウドに関する議論は多くの場合、混乱と矛盾したアドバイスに悩まされていることがわかります。マルチクラウド戦略を採用しないよう警告するアドバイザーもいれば、採用しなければ業界全体の変革に乗り遅れると指摘するアドバイザーもいます。マルチクラウド戦略の採用には正当な理由がありますし、また反対も同様です。成功には、マルチクラウド戦略がもたらす潜在的なビジネス価値と複雑性およびリスクのバランスをとることが不可欠です。 企業は通常、戦略的な理由からマルチクラウドを採用します。異なるプラットフォームで事業を展開する新たに買収した企業を統合したり、異なるプロバイダーの専門的な機能を活用したり、持株会社と事業会社のレベルで異なるクラウド戦略をサポートしたりするためです。 ただし、企業はマルチクラウド戦略を一般的な誤解、例えば全面的な採用、ベンダーロックインの軽減、可用性の向上、コストの優位性などに基づいて策定すべきではありません。 ( これらの考慮事項についてより深く掘り下げた議論は、以前の私の記事 Proven Practices for Developing a Multicloud Strategy をご覧ください。 ) マルチクラウドアプローチを成功させるには、既存のツールや将来の選択肢と シームレスに 連携するクラウドプラットフォームが必要です。他のクラウドサービスプロバイダ ( CSP ) の機能を追加する際に、すべてを再構築する必要はありません。また、すべてのプラットフォームのエキスパートになる必要もありません。 ( これが Multicloud on AWS において直接接続ポイントを構築する理由です。AWS 上で実行されるワークロードの性能を最大化しつつ、CSP 間の管理を簡素化するようにツールを設計しています。 ) お客様との経験に基づき、以下のプラクティスを推奨します。 1. 明確な戦略とそれを支えるガバナンスを確立する マルチクラウドアプローチを追求すると決めただけでは不十分です。どのワークロードをどこに、何のために配置するかについての明確なガバナンスを含め、マルチクラウドの目的を達成するための戦略も確立する必要があります。ワークロードとその依存関係を最適化する評価基準を選択してください。このような決定を個人任せにすると、 CSP 間の無秩序な拡大が生じ、達成しようとした価値を損なう可能性があります。CSP のパフォーマンスを定期的に評価し、その評価を CSP の選択、ワークロード配分基準、および将来の利用計画に活用してください。 ガバナンス戦略をサポートするためには、企業全体のサービス、アプリケーション、コンポーネントの総数について可視化する必要があります。そのためには、CSPを横断してタグ付け戦略を確立し、明確な所有権、利用状況、環境 ( 開発、QA、ステージ、本番など ) を定義してください。所有者が特定できない場合は、そのリソースを削除する必要があります。これによりガバナンスが明確化され、進捗を阻害することなく自動的に施行されます ( ゲートではなくガードレール ) 。 コスト、運用プロセス、セキュリティは、CSP 間で同じ方法で、同じ深さのデータと透明性をもって監視され、対処されなければなりません。 2. 隣接するワークロードをCSP間に分散させない 複数の CSP に跨がる単一のワークロードは、不必要な複雑性、リスク、コストをもたらし、サポート、デプロイ、アーキテクチャを複雑にするだけで付加価値はほとんどありません。 隣接したワークロードは通常、一緒に処理・分析する必要のある大量のデータを伴います。データを複数の CSP に分散させると、データの移動、同期、整合性に課題が生じます。また、複数の CSP 上の単一のワークロードを管理することは複雑で時間がかかります。各 CSP の API 、管理インターフェース、セキュリティモデル、運用プロセスに対応する必要があるためです。複雑性の増加は、エラーの可能性を高め、運用オーバーヘッドを増加させ、アジリティとスケーラビリティを阻害する可能性があります。 3. より長期的な統合戦略を持つ 異なるクラウドのアプリケーション間でデータを移動する際には注意が必要です。特に、ある CSP にコンピューティング／アプリケーションをデプロイし、別の CSP にデータ、ストレージをデプロイする場合はなおさらです。ワークロードとデータの配置を決定する際は、ワークロードとデータを他の機能と統合する長期的なニーズを考慮する必要があります。データが現在の範囲を超えて、高度な分析や ML に必要となるでしょうか?そのサービスは他の CSP でも幅広く利用されるでしょうか、それとも特定の CSP 内に限定されるでしょうか? より詳しいガイダンスと導入検討のための意思決定モデルについては Gregor Hohpe の以前の記事 Multi-cloud: From Buzzword to Decision Model をご覧ください。 4. コンテナを戦略的に活用する コンテナはモダンなアプリケーションに適していることが多く、ポータビリティの面で役立ちます。コンテナはプラットフォームに依存しないため、コンテナ化をサポートするあらゆるクラウドプラットフォームやインフラにも展開できます。アプリケーションを一度開発、パッケージ化すれば、大幅な修正なしに複数の CSP やオンプレミス環境に展開できます。 ただし注意が必要です。コンテナはすべてのケースに適しているわけではなく ( 大規模なモノリシックアプリケーションなど )、CSP 間のポータビリティのすべての問題 ( 特にデータ、ポリシー、セキュリティ ) を解決するわけではありません。 5. 単一のCCoE ( Cloud Center of Excellence ) を持ち、その中で専門化する 多くのお客様にアドバイス しているように、組織内に CCoE を形成し、クラウドに関する取り組みをリードし、標準化を推進することで、クラウドジャーニーを加速するべきです。マルチクラウドの場合、単一の CCoE を設置し、その中で各 CSP 特有のスキル、ツール、メカニズムに特化することで、企業はより成功しやすくなると我々は考えています。CSP ごとに別々の CCoE を設置すると、多くの場合、分断、再設計、無駄が生じがちです。 6. セキュリティが常に最優先事項であることを確認する 複数のセキュリティモデルを管理すると攻撃対象領域が広がり、ギャップが生まれます。マルチクラウドでは、アイデンティティ管理、ネットワークセキュリティ、資産管理、監査ログなど、複数の CSP のセキュリティモデルに対処する必要があります。その結果、複雑さにより透明性が低下し、セキュリティチームの負担が増大し、リスクが高まります。いくつかのセキュリティ実践がより重要になります: (1) セキュリティ運用を自動化し、デリバリパイプライン、クラウド環境、チームの優先事項に組み込むことによって、セキュリティ運用をシフトレフトする、(2) CSP 内または CSP 間で保存中および転送中のデータを暗号化する。 セキュリティ運用データの送信先を1つに絞る ( Single Pane of Glass ) ことが有効です。その上で、各 CSP のクラウドネイティブツールを使用して、その環境に最適なデータを表示します。 7. 均等分散ではなく 80/20 のアプローチを受け入れる CSP間でワークロードをどのように配分するかは、マルチクラウドの成功を左右します。投資の80％をプライマリプロバイダに集中させ、その他のプロバイダを特定機能の利用に限定することで、コストと複雑さを軽減できます。 80/20の配分により、プライマリプラットフォームの高度なサービスの活用を通じたイノベーションが加速します。トレーニングとツールの重複が減り、単一のセキュリティモデルのみ管理すればすみます。 エンジニアが1つのプラットフォームに精通することで、より効率的に構築し、より迅速にトラブルシューティングし、より洗練されたソリューションを実装できます。また、人材の定着にも良い影響があり、多くの技術に跨がってスキルを薄めるのではなく、市場価値の高い専門性を身につけられます。 マルチクラウド環境の管理と監視を簡素化し、どこに保存されていてもすべてのデータへのアクセスを提供し、マルチクラウド環境で生成AIを活用するのに役立つAWSサービスの詳細については、 Multicloud on AWS をご覧ください。 Tom Godden Tom Goddenは、Amazon Web Services (AWS)のエンタープライズストラテジスト兼エバンジェリストです。AWSに入社する前は、Foundation Medicineの最高情報責任者（CIO）として、FDAが規制する世界有数のがんゲノム診断、研究、患者アウトカムプラットフォームの構築を支援し、次世代の精密医療に情報を提供していました。それ以前は、オランダのアルフェン・アーン・デン・レインにあるWolters Kluwer社で複数のシニア・テクノロジー・リーダーを務め、ヘルスケアおよびライフサイエンス業界で17年以上の経験を持ちます。アリゾナ州立大学で学士号を取得。 翻訳はカスタマーソリューションマネージャー 西部 信博が担当しました。原文は こちら です。

物流業界を取り巻く環境は、深刻な人手不足や国際紛争、厳しい法規制などにより、ますます複雑で困難な状況になっています。このような厳しい環境の中でも、倉庫スタッフやトラックドライバー、海運・空運に携わる皆様が、社会基盤である物流を支えるために日々懸命に取り組んでおられることに、心から感謝しております。 一方で、現在の物流ビジネスを持続可能なものとするためには、そうした現場の努力に頼るだけではなく、企業全体あるいは社会全体として無駄をなくし効率化を図ることが必要です。特にデータを活用した改善は、物流DXとして総合物流施策大綱でも長年にわたり強く推奨されてきました。このような状況を受けて多くの物流企業がデータ活用を経営戦略の重要項目として位置付けているものの、実態としては有効な施策が打ち出せずにいるケースが多く見受けられます。これは、多くのシステムが存在するがシステム間のデータの連携が進んでいない、データ分析のスキルや経験を持った人材が少ないといった、物流業界全体として共通する課題あるためです。その打開策として専門のソフトウェアを導入したものの、想定ほどには活用が進まず、有用性に疑問を抱えつつも維持運用コストを負担し続けているような企業も少なくありません。 本ブログではそういった課題に悩まれる物流事業担当者向けとして、データ活用の成功モデルとして日本通運株式会社（以下Nippon Express）のデータ分析基盤「NX Data Station」を解説します。同社は既存リソースを最大限に活用しながら、コスト効果の高いデータ分析基盤を構築し、データを基に業務効率化と意思決定の質向上を実現しています。 以下は2025年7月15日に開催された Amazon SageMaker Roadshow でご登壇いただいた、NX情報システム 髙 為彦 様 および キヤノンＩＴソリューションズ 渡邊 哲也 様のセッション内容をもとに記載しています。特に引用元明記の無いスライドは同イベントでの発表からの引用です。 Nippon Express のデータ分析基盤 NX Data Station 日本最大の総合物流企業である Nippon Express（NXグループ）は、2020年の中期経営計画で「データドリブン経営」を掲げ、「NX Data Station」というデータ分析基盤の開発を開始しました。そこで重視されたのが業務部門や従業員一人ひとりが能動的にデータを利活用していく「ボトムアップ型アプローチ」です。 NX Data Stationの特徴は大きく三つあります。第一に、各事業（海運、航空、自動車、鉄道、倉庫）が別々に保持しているデータを横断的に集約できる点です。第二に、システムにないオフサイトデータやSaaSからのダウンロードなど、手持ちのデータも柔軟に取り込める点です。そして第三に、ダッシュボードによる可視化、機械学習による需要予測、生成AIの活用など、総合的なデータ活用環境を提供している点です。 そしてデータ活用の明確なイメージがあるユーザはこれらの機能を組み合わせて自ら創意工夫して利用できる一方、具体的なイメージや経験のないユーザはカタログ化されたデータ一覧や他部門の利用事例を参照できる環境を整備しています。 このようなアーキテクチャ/運用面の工夫により、Nippon Express のような多くの部門が存在する企業の中でも、データが各部門にまたがって定常的に蓄積され、スキルに合わせて自主的に分析/可視化を行える環境が実現されています。 NX Data Stationの具体的な活用事例の一つが、物流業界の2024年問題など労働力不足という社会課題への対応です。24時間稼働の大型倉庫では一日の労働者数が延べ数百人規模になることもあり、繁忙期・閑散期やキャンペーン・新商品販売などの波動に合わせた人員配置が必要です。 この課題に対して、NX Data Station ではWMS（在庫管理システム）からの入出庫データ、キャンペーン情報、天候データなどを組み合わせた需要予測を実施しています。この予測は作業スタッフのスキルを考慮した最適人員配置のために利用されています。倉庫内作業はマテハンによる効率化も進められていますがまだ人手に頼る部分も多く、このようなデータ駆動型の人員計画の最適化は大きな効果を生み出しています。 グローバル物流においては船会社とのスペース確保やレート交渉といった業務が発生します。この際、海外現地法人から収集したデータを集約・加工する必要がありますが、従来はこの作業に約2ヶ月かかっていました。つまり、2ヶ月前の古いデータに基づいて交渉せざるを得ませんでした。 NX Data Stationの構築により、集約したデータはその日のうちにダッシュボードに反映されるようになりました。これにより、交渉へのリードタイムが大幅に短縮され、直近の鮮度の良い客観的データに基づく多角的分析が可能になりました。この改善は、米国関税、中国籍船舶への課税、スエズ運河通行制限など、急な変化が頻発する現代の国際物流において、迅速な対応力の向上に大きく貢献しています。 さらに注目すべきは、業務部門が自らダッシュボードのメンテナンスやデータ組み合わせの改良を行う自走体制が確立されたことです。これはNXグループが目指すデータ活用文化の醸成 NX Data Station の上で着実に進んでいることを示しています。 NX Data Stationの運用では、キヤノンMJグループによる「伴走支援」が重要な役割を担っています。この取り組みはシステム構築にとどまらず、ハンズオンや勉強会を通じた啓蒙活動、最適なサービスの検討、内製化文化の醸成、自立・自走支援など、データ活用文化の定着を目指しています。その成果として、業務部門が自らダッシュボードを管理・活用できる体制が構築され、持続可能なデータドリブン経営の基盤が形成されつつあります。 AWS上での分析環境構築・運用のベストプラクティスとキヤノンMJグループによる伴走支援 ここからは、NX Data Stationのシステム構成とその運用についてみていきます。NX Data Stationでは、AWS 上でのデータレイク環境の構築についてだけでなく、運用もベストプラクティスにそった形で実施されています。 NX Data Station のアーキテクチャでは、データは全て Amazon S3 に蓄積されています。これはAWS上でのデータレイク構築のベストプラクティスに沿ったものです。 全体の構成としては、まずS3 までのデータ転送には Amazon Appflow や AWS Database Migration Service (DMS) を利用しています。データを蓄積した後は AWS Glue によりデータの前処理とカタログ登録を行い、それを Amazon Redshift (DWH) に格納します。可視化や予測としては、AWS Glue DataBrew (ノーコードデータ準備）、 Amazon SageMaker AI (機械学習)、 Amazon Bedrock (生成AI)、 Amazon QuickSight (BI) を活用する構成になっています。 利用している AWS サービスに共通しているのは、マネージドもしくはサーバーレスといった導入・運用の負担が少ないサービスであるという点です。マネージドサービス・サーバーレスサービスの活用は、基本的なAWS活用のベストプラクティスの1つです。 NX Data Station は最初から現在のような充実した構成になっていたわけではありませんでした。上図のように、最初はスモールスタートし、少しづつデータや利用ニーズの拡大に合わせて体制を整備し、新たなニーズに合わせてシステムを成長させるという方法がとられました。 このスモールスタートで利用状況少しづつ成長させる方式は、データ活用が成功しているユーザーに共通した運営のベストプラクティスです。昨今は分析環境に求められる機能やデータは変化が激しいため、事前に将来のニーズを予測したうえで設計することは不可能です。また、組織（ユーザー）側も新技術・新環境に少しづつ慣れ、習熟していく必要があります。そのため、スモールスタートしつつ、徐々に改善していく事が良い手法とされています。 ※上図はAWSの資料より このスモールスタートから段階的に拡張していくという観点でも、 S3をデータレイクとして活用することが良い方法です。AWSの多くのサービスはS3上にあるデータにアクセスする事が容易であるため、S3を中心にすることで、後から多様なサービスを活用することが可能になります。 ※上図はAWSの資料より また、多くのデータ分析関連サービスがサーバーレスで提供されているため、導入の負担が少ないだけでなく、運用面での調整負担も少なくすることが可能です このようなスモールスタートからの改善の繰り返しを支えているのが、キヤノンMJグループ（キヤノンITS）による伴走支援です。最初に決めた開発要件に合わせて成果物を構築・納品するといった方法ではなく、あくまでデータ活用の主体を Nippon Express 側におきつつ、継続的に側面から支援する方法です。図の中央にある データマネジメント推進チームの中では以下のような活動を行いました。 ・データスチュワード：データ活用の現場とシステムの間を取り持ち全体をリード ・データエンジニア：データ活用前の加工部分を技術支援 これらはあくまで伴走であり、主体である機械学習であればAIエンジニア/サイエンティスト、可視化であればBIエンジニア/アナリストが自走できることを目指しています。また、このような活動の中から生まれたニーズに対応するために、システムの継続的な改善も行われてきました。 このような活動の結果を数値でとらえることも重要なポイントです。環境が本当に活用されているのかという事を把握し、そこから次の改善を検討することが可能になるからです。NX Data Station では250以上あるBI (QuickSight)ダッシュボードの利用状況を自動的に収集しています。このデータによると現在、月々のBIダッシュボード参照回数が22,000回以上あります。 このように利用状況を把握したうえで、改善にも務めています。例えば業務の現場から意見をヒアリングしたり、利用が進むようなトレーニングを提供したり、もしくは課題を発見して新技術で対応したりといった形です。 例えば、NX Data Station では現在カタログを SharePoint上のドキュメントで管理しています。このカタログはITシステム連携していないため、IT側の変更の反映が手作業になっていたり、カタログで必要なデータを見つけても、そのデータにアクセス可能にするにはIT側に設定変更を依頼する必要がある等、課題の1つに挙げられています。今後は 次世代の Amazon SageMaker を導入することで、IT側の変更反映の自動化や、データアクセスを可能にするまでの自動化を実施していく予定です。 このようにスモールスタートした後にニーズを吸収しつつ広げていく手法は、上記のようなIT面の改善だけでなく人材育成や組織の連携の改善などにも及んでおり、これはまさにAWS上で分析環境を成長させる上でのベストプラクティスに沿っていると言えるでしょう。 まとめ 本稿では、NX Data Stationの事例を通して、物流業界が抱える課題と、データ活用による解決策について解説いたしました。既存データを最大限に活用しながら、コスト効果の高いデータ分析基盤を構築することで、業務効率化と意思決定の質向上を実現することができました。この成功の要因となったのは、ボトムアップ型のデータ活用アプローチと、AWSのマネージドサービスを活用したシステムの段階的な発展です。 また、データ活用はシステムを導入すればうまくいくというものではないというのも本事例から学べる重要なポイントでしょう。最初からどのような仕組みが必要かを完全に予測することは不可能であり、継続的に改善できるITの仕組みと人員体制にすることが重要です。本事例では、キヤノンMJグループが継続的な「伴走支援」を提供しており、Nippn Express側もパートナーに依頼したままにするのではなく、自グループ内でのデータ活用文化の醸成のための改善を続けており、これが大きな成果につながっています。 著者について 横山 誠：2019年より AWS Japan のソリューションアーキテクトとして、主に物流業のお客様に技術支援を行っています。機械学習を用いた需要予測や最近では生成AIの活用など幅広い領域でお客さまに役立つ情報をご提供しています。以前は通信キャリア様でのアプリケーション開発やデータベース製品のコンサルタントをしていました。今でも日本語よりSQLを書く方が得意です。 下佐粉 昭：2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 アップデートの前に一つ宣伝させてください。 AWS Innovate の次回開催が決まり、登録ページが公開されています。今回は、マイグレーション＆モダナイゼーションがテーマで、実践手法とそれを支えるAWSテクノロジーを学ぶことができる内容となっています。ご調整の上、ぜひご参加ください！ AWS Innovate: Migrate and Modernize 2025 年 9 月 18 日 | 13:00 – 17:20 登録は こちら それでは、先週の主なアップデートについて振り返っていきましょう。 2025年8月4日週の主要なアップデート 8/4(月) Amazon ECR now supports 100,000 images per repository Amazon ECR で、1つのリポジトリあたりに保存できるイメージの上限が、従来の 20,000 個から 100,000 個に拡張されました。コンテナアプリケーションの開発が進むにつれて大量のイメージを管理する必要がある場合に、これまでのような上限緩和申請の手間が不要になります。この上限は既存のレジストリにすでに適用されており、すべての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用可能です。ECR サービスのデフォルト上限の詳細については、 ドキュメント をご確認ください。 Mountpoint for Amazon S3 CSI driver accelerates performance and supports SELinux Mountpoint for Amazon S3 CSI ドライバー v2 がリリースされました。今回大きく4つの機能追加がされました。複数の Pod 間でのデータキャッシュにより繰り返しアクセスされるデータのパフォーマンス向上、SELinux サポート、Amazon EKS Pod Identity を使用したAmazon EKS クラスター全体でのアクセスポリシーの管理方法を簡素化。最後にkubectl を使用してログにアクセスしマウント情報を取得する方法を簡素化するものです。アップグレード方法は インストールガイダンス 、操作の詳細は ドキュメント を各々ご確認ください。 Amazon SQS increases maximum message payload size to 1 MiB Amazon SQS で送信できるメッセージの最大サイズが従来の 256 KiB から 1 MiB に拡大されました。これまでは256 KiB以上のデータを扱う際に複数メッセージに分割したり外部ストレージに保存する必要がありましたが、今回のアップデートで この手間をかけずに直接やりとりできるデータが増えることで利用シーンが広がります。この機能リリースと併せて、SQS 向けの AWS Lambda のイベントソースマッピングも 1 MiB ペイロードをサポートされています。この機能はすべての AWS 商用リージョンおよび AWS GovCloud (US) で利用可能です。詳細は ドキュメント をご確認ください。 Amazon CloudWatch introduces organization-wide VPC flow logs enablement Amazon CloudWatch で、組織全体の VPC フローログを自動的に有効化できるようになりました。これまではVPC ごとに手動で設定する必要がありましたが、CloudWatch テレメトリ設定で有効化ルールとAWS Config Service-Linked Recorderにより、ルールに合致する既存および新規のVPCで自動的に有効化できます。この機能は東京、大阪を含む17のリージョンで利用可能です。詳細は ドキュメント をご確認ください。 8/5(火) Amazon OpenSearch Serverless now supports backup and restore Amazon OpenSearch Serverless がバックアップとリストア機能をサポートしました。この機能は自動的に有効化され、全てのコレクションとインデックスは自動的にバックアップおよび14日間保持されるため運用負荷を軽減できます。また、利用したい際はAPIを使用して復元できます。OpenSearch Serverless&nbsp;の詳細は ドキュメント をご確認ください。 AWS announces general availability of Amazon Elastic VMware Service (Amazon EVS) Amazon Elastic VMware Service (Amazon EVS) が一般提供が開始されました。これにより、従来の VMware 環境をそのまま Amazon VPC 内で実行できるようになります。既存の VMware スキルを活かしながら AWS の拡張性や性能を利用でき、アプリケーションの再構築が不要になります。オンデマンド利用のほか、1年、 3 年間の利用オプションも提供されるため、利用期間と状況に応じて柔軟な選択が可能です。Amazon EVSは東京を含む 6 つのリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Anthropic’s Claude Opus 4.1 now in Amazon Bedrock Amazon Bedrock が Anthropic の最高知能モデル Claude Opus 4.1 を提供開始しました。従来の Opus 4 から置き換え可能で、コーディングや AI エージェント機能が大幅に向上しています。複雑な開発タスクを独立して計画・実行でき、フロントエンドコード生成やマルチステップタスクの処理精度も従来のOpus 4 から向上しています。この機能はオレゴン、バージニア北部、オハイオ リージョンでご利用可能です。 8/6(水) OpenAI open weight models now in Amazon Bedrock and Amazon SageMaker JumpStart Amazon Bedrock と Amazon SageMaker JumpStart で OpenAI のオープンウェイトモデル gpt-oss-120b と gpt-oss-20b が利用可能になりました。OpenAI オープンウェイトモデルは、コーディング、科学的分析、数学的推論タスクに優れており、両モデルとも 128K コンテキストウィンドウを備え、特定の要件に合わせて推論レベル (低/中/高) を調整することができます。Amazon Bedrock の統一された API を通じてこれらのモデルにアクセスでき、コードを書き直すことなく他のモデルとシームレスに実験や切り替えが可能です。これらのモデルはAmazon Bedrock では オレゴン リージョンで、Amazon SageMaker JumpStart では東京、ムンバイ、オハイオ、バージニア北部の各リージョンで利用可能です。詳細については ブログ も公開されているのでご確認ください。 Amazon OpenSearch Serverless introduces automatic semantic enrichment Amazon OpenSearch Serverless にセマンティック検索の実装を簡単にする、自動セマンティック強化機能が追加されました。例えば「頭痛治療」で検索すると「偏頭痛対処法」も結果に含まれるようなセマンティック検索の実装には、従来はMLの専門知識、モデルホスティング、OpenSearch 統合が必要でした。この機能はそれを簡素化し、対象フィールド指定のみでデータ取り込み中に自動処理されます。英語のみと多言語を選択でき、多言語は日本語を含む 15 言語に対応しています。東京を含む11のリージョンで利用可能です。詳細は ドキュメント や ブログ をご確認ください。 Amazon EC2 M7i and M7i-flex instances are now available in Asia Pacific (Osaka) Region Amazon EC2 の M7i と M7i-Flex インスタンスが、新たに大阪リージョンで利用可能となりました。このインスタンスはカスタムされた第4世代の Intel Xeon プロセッサー (Sapphire Rapids) が搭載されており、M7i はM6i と比較して最大 15 % 優れたコストパフォーマンスを実現します。また、M7i-Flex は、 M7i をより安価に利用出来る汎用的なインスタンスタイプです。通常 CPU 利用率は、低い時期と高い時期があるのが一般的ですが、Flex インスタンスは常時 100 % の力を発揮しなくても良いような利用方法に適したタイプです。CPU 性能の 40 % をベースラインとして常時提供し、ベースラインの 40 % を超える場合、95 % の確率で 100 % までスケールアップする仕組みを提供するものです。 8/7(木) Amazon Aurora Serverless v2 now offers up to 30% performance improvement Amazon Aurora Serverless v2 のプラットフォームバージョン 3 が公開され、最大 30 % パフォーマンスが向上しました。このプラットフォームバージョンは0から256ACU (Aurora Capacity Units) までのスケーリングに対応しています。ACU は約 2 GiB のメモリと CPU、ネットワークの組み合わせで、アプリケーションの需要に応じて自動スケールします。今回のパフォーマンス向上により、従来よりも高負荷なワークロードでも Aurora Serverless が活用できるようになりました。AWS GovCloud (US) リージョンを含むすべての AWS リージョンで利用可能で、既存のクラスターもクラスターの再起動もしくはBlue/Green Deployments を使用したアップグレードが可能です。できます。詳細は ドキュメント をご確認ください。 Amazon OpenSearch Serverless adds support for Hybrid Search, AI connectors, and automations Amazon OpenSearch Serverless が Neural Search、Hybrid Search、AIコネクター などの新機能をサポートしました。Neural Search では画像やテキストを使ったセマンティック検索、Hybrid Search は複数の検索手法を組み合わせての検索精度を向上を実現する機能です。また、Workflow API はモデル、コネクタ、パイプラインなどの OpenSearch AI リソースをテンプレートにパッケージ化して、Neural Search などの AI 機能を有効にするために必要な設定を自動化します。これらによりRAG (検索拡張生成) のような AI アプリケーションの構築がより手軽になります。この機能は東京を含む11のリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon EKS adds safety control to prevent accidental cluster deletion Amazon EKS で削除保護をする機能が追加されました。これまで EKS クラスターの誤削除を防ぐ仕組みはありませんでしたが、今回のアップデートにより 2 段階の確認プロセスでクラスターを削除保護が可能です。具体的には、AWS コンソールや CLI から削除操作をした際、一時的に削除がブロックされ、明示的に保護を無効化してからでないと削除できないようになります。これにより複数メンバーでクラスターを管理する開発チームや、自動化スクリプトによる誤操作が心配な本番環境での運用がより安全になります。この機能は、すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで利用できます。詳細は ドキュメント をご確認ください。 AWS Lambda now supports GitHub Actions to simplify function deployment AWS Lambda が GitHub Actions との統合をサポートし、サーバーレスアプリケーションのデプロイが大幅に簡単になりました。従来は Lambda 関数をデプロイするためには AWS CLI コマンドやカスタムスクリプトを書く必要があり、コードのパッケージング、IAM 権限設定、エラーハンドリングを手動で行う必要がありました。今回のアップデートにより GitHub Action を介して、GitHub リポジトリにコードをプッシュするだけで Lambda 関数が自動デプロイされ、CI/CD パイプラインを大幅に簡素化することができます。この機能は zip ファイルとコンテナイメージ両方のデプロイに対応し、OIDC 認証を使用して IAM とシームレスに統合されます。詳細は Lambda デベロッパーガイド と「Deploy Lambda Function」GitHub アクションの README をご確認ください。 8/8(金) Amazon SageMaker レイクハウスアーキテクチャが Apache Iceberg テーブルの最適化設定を自動化 Amazon SageMaker lakehouse アーキテクチャで Apache Iceberg テーブルの最適化設定が自動化されました。従来は各テーブルごとに個別設定が必要でしたが、今回のアップデートによりカタログレベルの設定により Amazon S3 に保存された Apache Iceberg テーブルの最適化を自動化し、メタデータのオーバーヘッドを削減してクエリパフォーマンスを向上させます。この機能を有効にすると、新しいテーブルまたは更新されたテーブルに対して、小さなファイルの圧縮、スナップショットの削除、不要になった参照されていないファイルの削除等が継続的に最適化され、ストレージコストの制御とクエリの高速化を実現します。東京を含む15のリージョンで利用可能です。詳細は ブログ と ドキュメント をご確認ください。 Amazon ECS コンソールが Amazon CloudWatch Logs Live Tail による リアルタイム ログ解析をサポート Amazon ECS コンソールで Amazon CloudWatch Logs Live Tail が利用可能になりました。これまでコンテナのログをリアルタイムで確認するには CloudWatch コンソールに移動する必要がありました。今回のアップデートにより ECS コンソール内で直接ログ監視が可能になります。これによりアプリケーションのトラブルシューティングやデプロイメント失敗の調査時に、コンソールを切り替えることなく効率的に作業できるようになります。詳細は ドキュメント をご確認ください。 Amazon Connect がリアルタイムキュー内位置取得 API を開始 Amazon Connect で、リアルタイムキュー内位置を返す新しい API が使えるようになりました。従来は顧客がどの位置で待っているかを正確に把握できませんでしたが、この API により待ち時間をより正確に推定し、プライマリキューと代替キュー間で情報に基づいたルーティング決定できるほか、長い待ち時間が予想される場合にコールバックなどの代替案を積極的に提案できるようになります。また、これにより顧客満足度向上と離脱率削減を同時に実現できます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

2025 年 6 月 から 7 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Aurora 概要編 AWS が提供するマネージドデータベースサービスである Amazon Aurora の概要をご紹介します。本コンテンツは Amazon Aurora の全体像、アーキテクチャについての基礎を取り扱います。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora の概要、他のデータベースとの違いを抑えたい方 本 BlackBelt で学習できること Amazon Aurora の概要および他のデータベースとの違いを抑えることができる スピーカー 藤田洋平 データベーススペシャリストソリューションアーキテクト Amazon Aurora 概要編 – コスト最適化 AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特にコストの削減方法についてフォーカスしてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora をご利用中で、コスト削減を検討中の方 本 BlackBelt で学習できること Amazon Aurora をご利用いただく際のコスト最適化手法として、Aurora のコスト構造の理解から費用の確認方法をご理解いただけます。その上で、コスト削減アプローチとしてインスタンスタイプの変更や、Reserved Instance の利用、Serverless V2 や IO Optimized の概要についてご理解いただけます。 スピーカー 西原 陽介 シニア テクニカル アカウント マネージャ Amazon Aurora 概要編 – 可用性 – 前半 AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特に可用性についてフォーカスしてご紹介するコンテンツの前半です。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora の可用性に関する機能について抑えたい方 本 BlackBelt で学習できること Amazon Aurora の概要をおさらいしつつ、まず一般的なデータベースにおける可用性の考え方を学習できます。その上で Amazon Aurora の高可用性を担保するアーキテクチャについてもご理解いただくことができます。 スピーカー 髙橋 敏行 パートナーソリューションアーキテクト Amazon Aurora 概要編 – 可用性 – 後半 AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特に可用性についてフォーカスしてご紹介するコンテンツの後半です。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora の概要や高可用性アーキテクチャについて抑えたい方 本 BlackBelt で学習できること Amazon Aurora の概要をおさらいしつつ、まず一般的なデータベースにおける可用性の考え方を学習できます。その上で Amazon Aurora の高可用性を担保するアーキテクチャについてもご理解いただくことができます。 スピーカー 髙橋 敏行 パートナーソリューションアーキテクト Amazon Aurora 概要編 – 性能とスケーラビリティ AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特に性能、スケーラビリティにフォーカスしてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora における、特に性能面について抑えたい方 本 BlackBelt で学習できること Amazon Aurora にて如何に性能を担保しているか、アーキテクチャや機能について学習できます。また Aurora Serverless V2 についても学習することができます。 スピーカー 鈴木 大樹 ソリューションアーキテクト Amazon Aurora 概要編 – 移行支援プログラム・サービス AWS が提供するデータベースのマネージドサービスである Amazon Aurora の概要について、特に Aurora への移行支援プログラムや移行方法についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora への移行における AWS による支援サービスやツール、また移行方式を把握したい方 本 BlackBelt で学習できること 主に Amazon Aurora への移行ステップや課題を理解し、その上で AWS が提供する移行支援プログラムである Database Freedom Workshop の概要や、Database Migration Service (DMS) や Schema Conversion Tool(SCT) といった移行ツールの概要を抑えていただけます。 スピーカー 長久保 武 データベース スペシャリスト ソリューション アーキテクト AWS Database Migration Service ベストプラクティス – 実践編 AWS Database Migration Service は、オンプレミスから AWS へのデータベース移行や異なるエンジン間でのデータ連携など、データベース間でのデータ移行に役立つデータベースサービスです。難易度の高いデータ移行が容易に移行できるようになることから、多くのお客様のデータ移行で採用頂いています。本セミナーでは、データベースのデータ移行におけるモニタリングやチューニングのノウハウやベストプラクティスについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Database Migration Service を用いたデータ移行を計画し環境構築を進めようとされている方 どのような観点をモニタリングするべきかについて学びたい方 動作性能の向上に向けて確認すべき点や取り得る方法について知りたい方 本 BlackBelt で学習できること データ移行の実現に際して、重要なパラメータおよび関連する AWS Database Migration Service の動作や推奨の設定について 動作の状況を把握するためにモニタリングするべき点について 動作のチューニングに向けて、確認するべき項目と性能改善に向けて取り得る手法について スピーカー 大井 基彰 クラウドサポートエンジニア PrivateLink and Lattice – AWS PrivateLink 編 AWS PrivateLink は、トラフィックをパブリックインターネットに公開することなく、AWS でホストされるサービスやリソース、オンプレミスネットワーク間にプライベート接続を提供するサービスです。本セッションでは、AWS PrivateLink の概要やユースケースなどについて学べます。前編として、Amazon VPC Lattice 編もありますので、そちらも合わせてご覧ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS を利用される予定のネットワーク担当者の方 AWS のネットワーク設計を担当している方 AWS PrivateLink に関⼼がある、または深く学びたい方 本 BlackBelt で学習できること AWS PrivateLink の概要や、AWS PrivateLink で接続させたいサービス別の詳細、ユースケースなどについて学べます。 スピーカー 武松 未来 ソリューションアーキテクト Amazon CloudFront（基礎編） AWS Black Belt Online Seminar Amazon CloudFront の基礎編になります。本コンテンツでは、Amazon CloudFront の概要と基本的な設定方法について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 CDN の利用を検討している方 Amazon CloudFront をこれから利用したい方 Amazon CloudFront の基本的な使い方を学びたい方 本 BlackBelt で学習できること 初めて Amazon CloudFront を利用する方に向けて、全体像を掴むことができる内容となっています。ディストリビューション、ビヘイビア、オリジンといった各構成要素の設定や、その他の主要機能について知ることができます。 スピーカー 鈴木隆昭 プロフェッショナルサービス AWS Direct Connect 概要〜これだけはおさえておきたいこと〜 AWS Direct Connect の基本から実践まで学べる Black Belt Online Seminar を公開しました。本セミナーでは、Direct Connect の基本機能、VPC との接続パターン、高可用性を実現する冗長構成など、実務で押さえておくべきポイントについて解説しています。AWS 環境でのネットワーク設計をご検討中の方は、ぜひご覧ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS クラウドに関わるエンジニアの方 AWS Direct Connect の基本を学びたい方 これから AWS Direct Connect を検討されるシステム担当者 オンプレミスと AWS Cloud を閉域網で接続する要件をお持ちの方 本 BlackBelt で学習できること AWS Direct Connect の基本的な機能と接続パターンを理解する AWS Direct Connect の冗長構成の基本を理解する 詳細情報へのポインタを得る スピーカー 齋藤 優弥 ソリューションアーキテクト 認証・認可サービス構築 on AWS 〜デザインパターンと Amazon Cognito 活用プラクティス〜 AWS 上に CIAM システム、認証・認可基盤を構築するためには、シーケンス、ビジネスユースケース、デザインパターンの理解が欠かせません。本書では Amazon Cognito、あるいは IDaaS や OSS、独自構築の IdP を組み合わせた目的別の多様なアイデンティティ・アーキテクチャをご紹介します。 資料（ PDF ）&nbsp; 対象者 CIAM システムや OAuth2 や OpenID Connect を活用した認証・認可システムを構築したいと考えている方 認証・認可システムを構築する際に Amazon Cognito をどう使うとやりたいことを実現できるのか、その他の選択肢はどのようなものか知りたい方 技術とユーザー体験の両面から、認証・認可システムが実現するアイデンティティ・アーキテクチャに対して理解を深めたい方 本 BlackBelt で学習できること CIAM システムあるいは認証・認可システムを AWS 上に構築する際の、目的別のアイデンティティアーキテクチャを学ぶことができます。 Amazon Cognito をどのように利用することができるか、あるいは別の手法を利用する際の判断ポイントやメリットについて理解できます。 関係者との効果的かつ適切な議論を行うために、多様なアーキテクチャのパターンを共通言語として活用できるようになります。 スピーカー 勝原 達也 シニア セキュリティ ソリューション アーキテクト AWS Transfer Family 本セッションを視聴することで、AWS Transfer Family とはどのようなサービスか説明できるようになります。また、AWS Transfer Family の FTP/FTPS/SFTP を用いたファイル転送機能を理解することができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Transfer Family の全体像を知りたい方、AWS Transfer Family の FTP/FTPS/SFTP を用いたファイル転送機能を知りたい方を対象としております。 本 BlackBelt で学習できること AWS Transfer Family の基本的な機能、AWS Transfer Family における FTP/FTPS/SFTP を用いたファイル転送の流れ、アクセス管理機能を知ることができます。 スピーカー 佐藤 真也 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-08 AWS Elemental Media Services を利用した動画配信について（基礎編） ソリューションアーキテクト 石井 悠太

みなさん、こんにちは。アマゾン ウェブ サービス (AWS) ジャパン合同会社 AI / ML 事業開発チームの近藤 祐丞です。業務への実装が進む生成 AI で汎用の大規模 LLM に加えて特定の業界やタスクに特化したモデルを開発される会社が増えてきています。 本日は、 AWS ジャパンの生成 AI 実用化推進プログラム を通じて独自の大規模言語モデルを開発された野村総合研究所 (NRI) AI ソリューション推進部の岡田智靖様、大河内悠磨様に AWS 目黒オフィスに来社頂き、「業界タスク特化型 AI モデルの開発」をテーマに NRI 様が開発されたモデルの技術的な特徴や今後のビジネスへの適用構想について、 AWS 生成 AI イノベーションセンター の畔柳竜生から質問させて頂きました。 業界タスク特化型モデルの開発に関して 畔柳 近年生成 AI の業界では Anthropic や OpenAI、Google、Amazon といった企業が、汎用的な大規模言語モデル (Large Language Model、LLM) の開発を行っております。その一方で 2024 年後半頃から汎用モデルに囚われない業界特化型モデルを開発されるお客様が急速に増えていると感じています。その中でも NRI 様は早い段階から特化型モデルの開発を開始されて、保険業界の営業コンプライアンスチェック試験において、商用大規模モデルを上回る正解率を実現しています。なぜ業界タスク特化型モデルが求められているのか、その開発背景を教えていただけますでしょうか？ 岡田 特化型 LLM が必要な理由は大きく3つあります。 1つめの理由は専門知識への適用です。業界・業種問わず、企業が実施している業務の中には業界の専門知識が必要なものや、その企業特有のルールやスタイルで行われている業務が多いのが実状です。そういった専門知識を学習させて個別のタスクを効果的にこなすような LLM の存在が求められています。 2つめは推論コストです。特化型 LLM は初期の学習コストはかかりますが、一度できれば少ない計算量で効率的に専門業務のタスクをこなす事が可能です。専門知識をロングコンテキストや Retrieval Augmented Generation (RAG)で与えるよりも運用コストが安く収まり、Total Cost of Ownership (TCO) を削減することが期待できます。 ３つめは安心・安全を考慮したコントロール性です。機密情報や個人情報が含まれるデータを SaaS の API に流すことに抵抗を感じたり、ルール上 NG としている企業は多いと考えています。加えて、専用 LLM があればモデルのバージョンが勝手に変わることがなく安定した回答が期待できます。 野村総合研究所 岡田智靖 様 畔柳 ありがとうございます。汎用モデルが学習することのできない専門知識を学習させることにより、大規模なモデルとの差別化を実現しているという事ですが、実際に業界タスク特化型モデルを開発される上で工夫された点を教えて頂けますでしょうか。 大河内 今回のモデル学習では業界知識の継続事前学習とタスク特化のファインチューニングを組み合わせた 2 段階アプローチを採用しました。学習データのデータセット作成には自動化パイプラインを構築し、特定の専門領域に関するテキストの自動収集や合成データを使ってバリエーションを拡大しました。これにより、LLM が業界特有の専門知識を獲得するとともに、実施したいタスクに適した振る舞いをするように学習することができました。 畔柳 AWS ジャパンでは生成 AI 実用化推進プログラムを通して、生成 AI のビジネス活用を目指す日本のお客様を支援しており、今年もこのプログラムへの応募を募集しています。NRI 様も 金融特化型 LLM の開発 の際にこのプログラムを活用していただきましたが、このプログラムを活用して良かった点や、このプログラムの活用を検討されているお客様へのアドバイスなどがあれば、ぜひお願いします。 岡田 テクニカル面とビジネス面の両方の面で、丁寧にサポートいただいたことが非常によかった点です。テクニカル面では、 AWS ParallelCluster や Amazon SageMaker などの AWS のサービスや、AWS 製 AI チップの AWS Trainium と AWS Inferentia の利用にあたって重点的にサポート頂けました。ビジネス面でも、特化型 LLM をどのようなユースケースで利用するかについてのディスカッションやミートアップへの参加、様々なプロモーションの機会も頂くことができました。 畔柳 テクニカル面では私自身が所属する AWS 生成 AI イノベーションセンターからも支援に入らせて頂きました。生成 AI に特化したグローバルチームである AWS 生成 AI イノベーションセンターでは、生成 AI の本番活用を見据えた PoC やアドバイザリも実施しています。実際に生成 AI イノベーションセンターからの支援を受けた感想などがあれば教えてください。 岡田 確かな専門家の方々にサポートいただいて心強かったです。PoC として範囲を定義した形で支援いただき、サンプルコードの提供や技術的なトラブルシューティング、最終レポートの提供も含め期待以上にサポート頂くことができました。また今後さらに柔軟にサポート頂けるメニューがあると嬉しいです。 畔柳 ありがとうございます。AWS の生成 AI に関わるユニークな点として自社で AI 用アクセラレータチップを開発し、それを搭載したコンピュートリソースをお客様にサービスとして提供している事があります。昨年の re:Invent では Amazon EC2 Trn2 インスタンス の一般利用開始を発表するとともに、AWS として AI チップの開発への継続的投資を行うことを発表しています。生成 AI 実用化推進プログラムの際に NRI 様でも、 Trn1 インスタンス と専用の SDK である AWS Neuron を用いた分散学習を行うことで、GPU を利用した場合と比較して 40% のコスト効率の改善ができること発表いただいています。AWS の AI チップ開発に関する取り組みについてのコメントや実際利用していただいた感想などがあれば、教えていただけると助かります。 大河内 はい、GPUと比較してコスト効率が良いのはメリットを感じています。また、AWS 内製のため、サポートが期待でき、安心できる点も大きいです。実際に利用してみてコスト効率のメリットも実感し、リソースが豊富にあるため確保しやすいメリットも感じました。 野村総合研究所 大河内悠磨 様 今後の展開とビジネス戦略 畔柳 日本では経済産業省・NEDO が GENIAC プログラム を実施する形で、国としても国産の LLM 開発を促進しています。このプログラムに採択されたお客様にも、AWS 上のコンピュートリソースを活用して LLM 開発を実施していただいております。2025 年に募集が行われた GENIAC Cycle 3 には NRI 様も採択されました。おめでとうございます。国が LLM 開発の促進を行っていることについて民間企業という観点からどのように感じていらっしゃるか、また GENIAC Cycle3 では NRI 様としてどのような開発に取り組んでいこうと考えていらっしゃるか教えて頂けますでしょうか。 岡田 国の生成AIの発展に大きく寄与することができる、素晴らしい活動だと考えています。国から認められることによって、NRI も生成 AI の開発ができる企業としてアピールすることができます。また、まとまった形で確保しにくい計算資源を確保する機会として活用することができます。 NRI としてはこれまでに開発してきた小規模の業界・タスク特化型 LLM から大きく方向性は変えませんが、規模を 10B-40B の中規模モデルに拡大して、様々な業界やタスクに適用可能な特化型モデル構築のプロセスを確立する事を計画しています。様々なモデルをベースに検証する他、タスクの種類も増やして金融業界向けの構築と検証をしたいと考えています。GENIACに採択されることによって、こういった規模を拡大した学習にもチャレンジできるようになりました。 アマゾンウェブサービス合同会社 畔柳 竜生 畔柳 今後 NRI 様が開発された業界タスク特化型モデルがどのように活用されていかれるのか、ビジネス展開を教えて頂けますでしょうか？ 岡田 AI エージェントとの連携や NRI が開発した業界・タスク特化型モデルを私達が持っているお客様向けサービスの中に組み込んでいくことを計画しています。実際のお客様への業務適用が始まりつつありますが、これをどんどん進めていきたいと考えています。また今後の展望として、流通・小売や製造業、システム開発など、他の業界やタスクにも展開していきたいと考えています。 畔柳 最後になりますが生成 AI 実用化推進プログラムの最終発表会での NRI 大河内様のプレゼンテーション後の懇親会では、参加されていた多くの方々が大河内様を囲んで質問攻めにしていたのを覚えています。NRI 様として、同じように業界タスク特化型 LLM 開発を目指される開発者の方々にアドバイスなどがあればよろしくお願いします。 大河内 プログラムの懇親会では、自分達でも業界タスク特化型 LLM の学習を試したけれどもなかなかうまく行かなかったという相談が多かったです。実際に開発をしてみると様々な試行錯誤や工夫が必要なことが分かると思いますので、まずはベースモデルの選定やデータセットの設計など色々な視点で試して頂くのが良いと考えています。 今回のインタビューを実施した野村総合研究所様とAWSメンバー 執筆： 畔柳 竜生、帆足 啓一郎、飯塚 将太、近藤 祐丞、本橋 和貴、常世 大史、山上 哲史

2025年7月4日、 経済産業省と国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が実施 する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の第3期 (2025年4月公募) における採択事業者のキックオフが行われ、本事業の採択事業者が発表されました。今回 AWS は NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンス ( p5.48xlarge )、NVIDIA H200 Tensor Core GPU を搭載するAmazon EC2 P5en インスタンス ( p5en.48xlarge ) 等の学習・推論に必要な仮想サーバーに加えて、採択事業者のニーズに合わせ Amazon SageMaker HyperPod および Amazon EC2 Trn2 インスタンス を提供します。 AWS は、 GENIAC バーチャルチーム を組成し、以下の支援を提供します: 計算資源 : Amazon EC2 P5, P5en, Trn2 インスタンス、あるいは Amazon SageMaker HyperPod の提供、 技術支援 : AWS Solutions Architect (SA) を中心としたメンバーにより、コンピュート (EC2)・ネットワーク ( Elastic Fabric Adapter (EFA) )・ストレージ ( Amazon FSx for Lustre および Amazon S3 ) で構成される分散学習環境の AWS ParallelCluster や SageMaker HyperPod を活用した構築・管理の支援、 開発者コミュニティ支援 : 海外モデルプロバイダーの開発メンバーとの 交流イベント による最先端の開発動向調査や 海外視察 、国内の機械学習エンジニア同士の交流による知見共有をはじめとした Meetup の実施、 事業化支援 : GENIAC を通じて開発された基盤モデル・生成 AI アプリケーションの Amazon Bedrock Marketplace 、 AWS Marketplace の活用による go-to-market (GTM) 支援、利用企業との AWS 主催イベントを通じたマッチング機会の提供。 これらは、経済産業省商務情報政策局情報処理基盤産業室、NEDO、ボストン コンサルティング グループ (BCG)、および AWS パートナーであるクラスメソッド株式会社と密に連携のうえで提供されます。 採択事業者のうち AWS を利用する事業者は以下です (現時点で承諾が得られたもののみを掲載): SDio株式会社 カラクリ株式会社 Sansan株式会社 ストックマーク株式会社 Zen Intelligence株式会社 Degas株式会社 Direava株式会社 Nishika 株式会社 株式会社野村総合研究所 株式会社Preferred Networks ONESTRUCTION株式会社 株式会社リコー 採択事業者からコメントを頂きました: GENAICサイクル3において、エンタープライズ向けの大規模映像基盤モデル（LVM）の開発に取り組むにあたり、AWSのEC2 P5インスタンス および AWS ParallelCluster を活用することで効率的に研究開発を進めることができると考えております。多方面での実用的なサポートをいただき大変感謝しております。 — SDio株式会社 代表取締役 カイ アバ AWS様には第2期に続き、GENIAC第3期でも生成AI開発の基盤としてご支援いただいております。引き続きAWS Trainiumを活用することで、学習コストを抑えつつ高性能なモデル開発を実現できており、大変心強く感じております。 また、インフラの安定性やドキュメントの充実度に加え、技術だけでなくビジネス面も含めた総合的な支援により、スピード感をもって開発を推進できています。今後もAWS様との連携を通じて、より実用的かつ価値ある生成AIの社会実装を目指してまいります。 — カラクリ株式会社 CPO 中山 智文 Sansan株式会社では、文書特化基盤モデル「Viola」をスクラッチで開発し、自社プロダクトのデータ化プロセスに導入しています。GENIACサイクル3では、EC2 P5インスタンスを用いて「Viola」を拡張し、Visual Grounding機能を搭載した「Cello」を開発します。AWSの高性能コンピューティングリソースを活用することで、ビジネスインフラとして働き方に革新をもたらすことを目指します。 — Sansan株式会社 技術本部 研究開発部 Automationグループ 研究員 内田奏 「製造業等で扱われる複雑でハイコンテクストな資料を実用レベルで読み解けるAIは未だに存在しておらず、ストックマークはこの領域での更なる強力な基盤モデルの開発にGENIACサイクル3では挑戦致します。強力なモデルの構築には、大規模でも実行効率高くかつ安定的に動くマルチノードGPUクラスタが不可欠であり、GENIACサイクル2に続いてAWSを活用させていただくことと致しました。」 — ストックマーク株式会社 取締役CTO 有馬 幸介 氏 Zen Intelligenceでは、Physical AIを通して建設業界の社会課題解決を目指しております。 GENIAC 第3期では、AWS様のAmazon EC2 P5enインスタンスを活用させて頂き、建築現場の施工管理を自動化する基盤モデルの開発を加速させていきます。 AWS様には、今後も大規模なモデル開発を進める上で多様かつ有用なサービスを期待しておりますとともに、多大なご支援感謝致します。 — Zen Intelligence CEO 野﨑 大幹 Degasは、先端AIと衛星観測データの力で、発展途上国の課題解決に挑むスタートアップです。今回のGENIAC採択を受け、衛星データ解析の直感性と実用性を飛躍的に高めるリモートセンシング用視覚言語モデル（VLM）の開発に取り組みます。 開発においては、Amazon EC2 P5インスタンスを活用し、大規模な基盤モデルの学習を効率的に推進します。AWS様と協力しながら、柔軟性とスケーラビリティを兼ね備えたインフラを活用し、AIの社会実装に向けた技術革新をさらに加速してまいります。 — Degas株式会社 CTO 中山 洋平 弊社は、GENIACにおいて手術支援のためのVision-Language統合AI基盤モデル開発に注力します。この革新的な取り組みにおいて、AWSが提供するEC2 P5インスタンスやAWS ParallelClusterといった最先端のインフラを最大限活用できることに深く感謝しております。 これらの強力なサポートを得て、術中の判断支援や意思決定を助ける生成AIの開発を効率的に推進し、医療現場の安全性と質の向上に貢献していきます。 — Direava株式会社 CTO 斎藤 洸輔 氏 GENIAC Cycle3に採択され、世界初のBIM情報要件（IDS）生成基盤モデルの開発に着手します。本プロジェクトではAWSのEC2 p5en.48xlarge（NVIDIA H200搭載）を活用します。AWSの圧倒的なレジリエンスと信頼性と、弊社のbuildingSMART Internationalの国際標準規格開発メンバーに、日本企業として唯一参画する弊社の強みを活かし、建設業界の高度な国際標準技術を民主化します。 AWSとのパートナーシップが、この挑戦を成功に導く重要な鍵となることを確信しています。 ー ONESTRUCTION株式会社 事業開発ユニット AI Lead 日高 洸陽 Nishikaでは、AWS様のEC2 P5インスタンスを活用し、要約タスク等を目標に出力形式への追従能力を高めたSLMを開発してまいります。今後、オンプレミス環境におけるより幅広いユースケースをターゲットとしたSLMを開発していく予定で、継続的に協働させていただければと思います。 — Nishika株式会社 代表取締役CTO 松田裕之 AWS様には生成AI実用化推進プログラムの支援で大変お世話になりました。 GENIACサイクル3では Amazon EC2 P5en インスタンスを活用し、業界・タスク特化型LLM構築を中規模モデルに拡張して取り組んでまいります。 — 株式会社野村総合研究所 AIソリューション推進部 チーフエキスパート 岡田 智靖 氏 前回に引き続きの採択となりましたが、さらに複雑な図表へ対応と高度な推論能力を持つマルチモーダルLLMの開発を通じて、企業に蓄積されたドキュメントの有効活用を実現して企業競争力のアップに貢献したいと考えております。開発を進める中では計画変更が避けられませんが、LLM開発においては大きな計算機資源の機動的な確保が必要になります。その対応力とサポートに優れたAWS様に今回もお世話になります。 — 株式会社リコー RICOH Digital Services BU AIサービス事業本部 デジタル技術開発センター LMM開発室 室長 長谷川 史裕 AWS では日本のお客様に対し、2023年の AWS LLM 開発支援プログラム にはじまり、 グローバルの Generative AI Accelerator や AWS ジャパン生成 AI 実用化推進プログラム といった取り組みを通して生成 AI ワークロードを支援しています。そこで得られた知見をもとに、GENIAC における日本の生成 AI 開発力向上に貢献できれば幸いです。

本記事は「 AI-Driven Development Life Cycle: Reimagining Software Engineering 」を翻訳したものです。 ビジネスとテクノロジーのリーダーは、生産性の向上、開発速度の向上、実験の促進、市場投入時間（ TTM ）の短縮、開発者体験の向上を常に目指しています。これらの長期的な目標が、ソフトウェア開発のプラクティスのイノベーションを推進しています。このイノベーションは、人工知能によってますます加速しています。特に、 Amazon Q Developer や Kiro などの生成 AI を活用したツールは、すでにソフトウェアの作成方法に革命をもたらし始めています。現状、多くの組織は主に 2 つのアプローチでソフトウェア開発に AI を活用しています：1 つは AI 支援型開発で、ドキュメント作成、コード補完、テストなどの特定のタスクを AI が強化するアプローチです。もう 1 つは AI 自律型開発で、ユーザーの要件に基づいて人間の介入なしに AI がアプリケーション全体を生成することを期待するアプローチです。これらのアプローチはいずれも、開発速度とソフトウェア品質の面で最適とは言えない結果を生み出しており、AI-DLC はこれらの課題に対処することを目的としています。 ソフトウェアにおける AI の革新的アプローチの必要性 既存のソフトウェア開発手法は、人間主導の長期的なプロセスとして設計されており、プロダクトオーナー、開発者、アーキテクトは皆、計画、会議、その他のソフトウェア開発ライフサイクル（ SDLC ）の儀式などの本質的ではない活動に時間の大部分を費やしています。AI をアシスタントとして単純に後付けすることは、その能力を制約するだけでなく、時代遅れの非効率性を助長することにもなります。AI の力を真に活用し、生産性向上の長期的な目標を達成するには、ソフトウェア開発ライフサイクルへのアプローチ全体を再構築する必要があります。 革新的な結果を達成するには、AI を開発プロセスの中心的な協力者およびチームメイトとして位置づけ、ソフトウェア開発ライフサイクル全体を通じてその能力を活用する必要があります。これが、AI の能力をソフトウェア開発の構造そのものに完全に組み込むよう設計された新しい方法論である AI 駆動開発ライフサイクル（AI-DLC） &nbsp;を導入する理由です。 AI 駆動開発ライフサイクル（AI-DLC）とは？ AI-DLC は、ソフトウェア開発に対する AI 中心の革新的なアプローチで、2 つの重要な要素を重視しています。： AI が実行し人間が監視する ：AI は体系的に詳細な作業計画を作成し、積極的に意図のすり合わせとガイダンスを求め、重要な決定は人間に委ねます。これが重要なのは人間だけが情報に基づいた選択を行うために必要なビジネス要件の文脈的理解と知識を持つからです。 ダイナミックなチームコラボレーション ：AI がルーティンタスクを処理する一方で、チームはリアルタイムでの問題解決、創造的思考、迅速な意思決定のために、コラボレーションしやすい環境で協力します。この孤立した作業から活気のあるチーム作業への転換は、イノベーションと成果物の提供を加速します。 これら 2 つの要素により、品質を犠牲にすることなく、より迅速にソフトウェアを提供できるようになります。 AI-DLC の仕組み AI-DLC の本質は、新しいメンタルモデルを通じて AI にワークフローを開始させ、指示することです： このパターンでは、AI が計画を作成し、文脈を理解するためにすり合わせのための質問をし、人間の検証を受けた後にのみソリューションを実装します。このパターンは、すべての SDLC 活動に対して迅速に繰り返され、すべての開発パスに統一されたビジョンとアプローチを提供します。 このメンタルモデルを核として、AI-DLC でのソフトウェア開発は 3 つシンプルなフェーズで行われます： 開始( Inception )フェーズ では、AI がビジネス意図を詳細な要件、ストーリー、ユニットに変換します。これは「モブエラボレーション( Mob Elaboration (※) )」を通じて行われ、チーム全体が AI の質問や提案を積極的に検証します。( ※訳註: elaboration は”推敲”や”入念な準備”と言う意味を持つ英単語です) 構築( Construction )フェーズ では、開始フェーズで検証されたコンテキストを使用して、AI が論理アーキテクチャ、ドメインモデル、コードによる実装、テストを「モブコンストラクション ( Mob Construction )」を通じて提案します。そこでは、チームが技術的決定とアーキテクチャの選択についてリアルタイムで明確化していきます。 運用( Operation )フェーズ では、AI が前のフェーズから蓄積されたコンテキストを適用して、チームの監督のもとで Infrastructure as Code とデプロイメントを管理します。 各フェーズは次のフェーズにより豊富なコンテキストを提供し、AI がより的確な提案を提供できるようにします。 AI は、プロジェクトリポジトリに計画、要件、設計成果物を保存し、すべてのフェーズにわたって永続的なコンテキストを保存・維持し、複数のセッションにわたって作業をシームレスに継続できるようにします。 AI 駆動の高度に協調的なアプローチを反映して AI-DLC は新しい用語と習慣を導入 します。従来の「スプリント」は「ボルト ( bolts )」に置き換えられます。これは、週単位ではなく時間や日単位で測定される、より短く集中的な作業サイクルです。エピックは作業単位 ( Units of Work) に置き換えられます。この用語の変更は、この手法がスピードと継続的デリバリーを重視していることを強調しています。同様に、他の一般的なアジャイルの用語も AI 中心のワークフローに合わせて再定義され、この手法のソフトウェア開発における革新的なアプローチをより適切に表現する用語体系が作られています。 この手法のメリット 開発速度 ：AI-DLC が提供する最大の利点は、開発速度の向上です。AI が要件、ストーリー、設計、コード、テストなどの成果物を迅速に生成・改良することで、プロダクトオーナー、アーキテクト、開発者が以前は数週間かかっていたタスクを数時間または数日で完了できるようになります。 イノベーション ：その結果、開発速度の向上と AI による重労働の肩代わりにより、イノベーションのための時間が大きく確保され、ビルダーは創造的なソリューションを探求し、可能性の限界に挑戦することができます。 品質 ：継続的な意図のすり合わせにより、チームは AI による抽象的/曖昧な意図の解釈ではなく、頭に描いているものを正確に構築できます。これにより、ビジネス目標により適合した製品が実現します。AI は、組織固有の標準（コーディング規約、設計パターン、セキュリティ要件）を一貫して適用しながら、包括的なテストスイートを生成することで品質を向上させます。このエンドツーエンドの AI 統合により、要件からデプロイメントまでの一貫性とトレーサビリティが向上します。 市場対応力 ：AI-DLC の迅速な開発サイクルにより、市場の需要とユーザーフィードバックに迅速に対応でき、結果として要件への迅速な適応が可能になります。 開発者体験 ：AI-DLC は、日常的なコーディングタスクから重要な問題解決にフォーカスを移すことで、開発者体験を変革します。AI が反復的なタスクを処理することで認知負荷を軽減し、開発者がビジネスコンテキストをより深く理解し、自分の作業がビジネス価値に直接影響を与えることを実感できるため、満足度が向上します。 開始方法 AI-DLC の導入には、3 つの明確なパスがあります：包括的な AI-DLC ホワイトペーパー を読む、 Amazon Q Developer ルール と Kiro カスタムワークフロー を活用して組織全体で一貫した AI-DLC の実装方法を探る、または AWS アカウントチームと連絡を取り、AI-DLC を組織の特定のニーズに合わせてカスタマイズする方法について相談する、のいずれかから始めることができます。 ソフトウェア開発の未来が到来しました。私たちは、AI を活用してシステム開発をより速く行うだけでなく、人間による重要な監督とコラボレーションを通じて正確性と品質を維持することをお手伝いできることを嬉しく思います。今すぐ AI-DLC の旅を始めて、AI 駆動型のイノベーションを通じて開発プラクティスを変革している組織のコミュニティに参加しましょう。 翻訳は、ソリューションアーキテクトの金森が担当しました。原文は こちら です。 Raja SP Raja は AWS のプリンシパルソリューションアーキテクトで、Developer Transformation プログラムを率いています。彼は 100 を超える大企業と協働し、モダンなアーキテクチャ、プラットフォームエンジニアリングプラクティス、Amazon にインスパイアされた運用モデルに基づいて構築されたミッションクリティカルなシステムの設計と提供を支援してきました。生成 AI がソフトウェア開発の状況を再構築する中、Raja と彼のチームは AI 駆動開発ライフサイクル（AI DLC）を作成しました。これは、AI 時代に大規模チームが協働してプロダクショングレードのソフトウェアを構築する方法を再構築する、エンドツーエンドの AI ネイティブ方法論です。

はじめに 多くのお客様は今日、SAP RISE を通じて SAP S/4HANA を実装することで、SAP ランドスケープを変革しています。しかし、まだ SAP RISE に移行していないお客様も多数おり、AWS 上で SAP システムをネイティブにホストしています。彼らは、厳しい可用性とパフォーマンス要件を満たし、改善するために、SAP システムの運用効率を最適化することを常に検討しており、その目標を達成するために AWS Systems Manager for SAP の機能を活用してきました。このブログでは、最新の機能強化により、HANA データベースを使用した SAP NetWeaver ABAP アプリケーションの開始/停止操作を自動化する方法を学びます。 AWS Systems Manager for SAP は、AWS 上の SAP アプリケーションを管理および運用するための自動化機能です。AWS サービスと AWS 上で実行される SAP アプリケーションとのシームレスな統合を提供します。HANA データベースに基づく NetWeaver ABAP アプリケーションをサポートするために、先月 AWS Systems Manager for SAP に 2 つの新機能がリリースが発表されました。お客様は、SAP HANA データベースを使用したSAP NetWeaver ABAP アプリケーションをAWS Systems Manager for SAP に登録できるようになりました。これにより、シングル構成、分散構成、高可用性（HA）構成のいずれの場合でも、アプリケーションの起動と停止を自動化することが可能になります。この機能強化により、S/4HANA や BW/4HANA などの幅広い SAP アプリケーションがカバーされ、追加のアプリケーションサーバーとウェブディスパッチャコンポーネントのサポートが拡張されます。この新機能により、複雑な SAP ランドスケープの管理が簡素化され、運用効率が向上し、高可用性と分散構成のサポートが強化されます。 SAP NetWeaver アプリケーションは、AWS Systems Manager Application Manager コンソールまたは AWS コマンドラインインターフェイス (CLI) で登録および管理できます。 AWS Systems Manager for SAP は追加費用なしでご利用いただけます。SAP 環境を管理および運用するために、プロビジョニングした AWS リソースの料金のみお支払いいただきます。 では始めましょう このブログでは、HANA データベースに基づく SAP NetWeaver ABAP アプリケーションを登録し、AWS Systems Manager Application Manager コンソールを使用してその開始/停止操作を自動化する方法について詳しく説明します。 次のステップに進む前に、以下にリストされているすべての前提条件を完了してください。 前提条件 1 – AWS Systems Manager for SAP の開始方法 前提条件 2 – SAP HANA データベースを AWS Systems Manager for SAP に登録する SAP NetWeaver ABAP ベースのアプリケーション登録 1. AWS Systems Manager コンソール を開きます。 2. 左側のナビゲーションペインで、[Application Manager] を選択します。 3. [Create Application] を選択し、[Enterprise Workload] を選んでください。 4. SAP アプリケーションタイプの下にある SAP ABAP -new を選択します 5. SAP ABAP アプリケーション の下に、例えば “ ABAPSSMTEST ” というアプリケーション名を入力します。 6. Browse instances ボタンを選択して、プライマリ SAP ABAP ワークロードのインスタンス ID を選択します。AWS Systems Manager for SAP は、HA およびディストリビューテッドトポロジーに関わるすべてのインスタンスを自動的に検出するため、すべてのインスタンスを添付する必要はありません。 7. SAP NetWeaver ABAP インスタンスの SAP システム識別子 (SID) を入力してください 8. SAP ABAP アプリケーションに関連付けられている SAP HANA データベースの Amazon Resource Name (ARN) を Browse databases を選択して指定してください。 9. (オプション) 「Connected Web Dispatcher components」の下で、アプリケーションで使用している SAP Web Dispatcher リソースの詳細を最大 5 つ入力できます。SAP Web Dispatcher リソースは、これらの詳細を入力した後に Systems Manager for SAP で検出可能になります。 「SAP System Identifier (SID)」は、SAP Web Dispatcher リソースの SAP システム識別子 (sapsid) です。 「Instance ID」は、SAP Web Dispatcher が現在実行中の Amazon EC2 インスタンス ID です。「Browse instances」を選択してインスタンス ID を検索できます。 10. (オプション) 「Application tags」の下で、リソースに関連付ける 100 個のタグを追加できます。 11. Create &nbsp;を選択します。 12. 登録が成功すると、アプリケーションの一覧にあなたのアプリケーションが表示されます。アプリケーションをクリックすると、そのアプリケーションの次のタブが表示されます。 13. Database をクリックすると、ABAP アプリケーションに接続されているデータベースが表示されます。 14. トポロジを確認するには、 Resources タブをクリックし、下部パネルで ABAP システムの Topology を確認してください。 操作の停止 15. 画面の右側にある Actions メニューから Stop application を選択してください SAP NetWeaver ABAP アプリケーションを停止する際、 追加オプション の下にある SAP HANA アプリケーションを停止する と SAP ABAP および SAP HANA コンポーネントをホストする EC2 インスタンスを停止するためのこのオプションを有効にする のオプションをチェックすることで、接続された SAP HANA アプリケーションと/または SAP NetWeaver ABAP と SAP HANA アプリケーションが実行されている関連する EC2 インスタンスを停止することができます。AWS Systems Manager for SAP はアプリケーションを認識しており、EC2 インスタンスをシャットダウンする前に、すべての SAP コンポーネントを適切な方法で停止します。 16. Stop を選択してアプリケーションを停止します。 17. フラッシュバナーに表示される 操作 ID をクリックするか、 アクション メニューから 操作の表示 を選択することで、操作の状況を監視できます。 イベントの下では、アプリケーションコンポーネントが停止される順序と、操作の現在の進行状況を確認できます。これらの操作イベントは、SAP アプリケーションサーバー、ASCS、ERS、Web ディスパッチャー、データベースなど、個々の SAP コンポーネントの粒度で表示されます。障害が発生した場合、停止に失敗したコンポーネントを簡単に特定でき、そのコンポーネントの問題をさらに特定できます。 18. 操作が正常に完了すると、アプリケーションが正常に停止されたというメッセージが表示されます。 19. ページを更新 し、 Resource タブに移動して、Topology の下にアプリケーションの Status を確認してください。 操作を開始 20. 画面の右側にある Actions メニューから Start application を選択してください。 21. Start を選択してアプリケーションを開始します。 22. フラッシュバナーに表示される 操作 ID をクリックするか、 アクション メニューから 操作の表示 を選択することで、操作の状況を監視できます。 イベントの下では、アプリケーションサーバーの起動順序と操作の現在の進行状況を確認できます。これらの操作イベントは、SAP アプリケーションサーバー、ASCS、ERS、Web ディスパッチャー、データベースなどの個々の SAP コンポーネントの粒度で表示されます。障害が発生した場合、お客様は起動に失敗したコンポーネントを簡単に知ることができ、そのコンポーネントをさらにトラブルシューティングできます。 23. 操作が正常に完了すると、アプリケーションが正常に開始されたというメッセージが表示されます。ページを 更新 し、Resource タブに移動すると、Topology&nbsp; の下にアプリケーションの Status が表示されます。 結論 このブログでは、HANA データベースに基づく SAP NetWeaver ABAP アプリケーションの登録方法と、 AWS Systems Manager for SAP を使用して開始/停止操作を自動化する方法を学びました。詳細については、AWS Systems Manager for SAP の詳細なドキュメントをご覧ください。 本ブログはパートナーソリューションアーキテクトの松本が翻訳しました。原文は こちら です。

(この記事は、 Improve PostgreSQL performance: Diagnose and mitigate lock manager contention を翻訳したものです。) ワークロードが拡張するにつれて、データベースの読み取り操作が予期せず遅くなっていませんか？PostgreSQL ベースのシステムを運用している多くの組織では、すぐには明らかにならないパフォーマンスのボトルネックに遭遇する事があります。多数のパーティションやインデックスを持つテーブルに対して多くの同時読み取り操作がアクセスすると、 PostgreSQL の高速パスロック機能 を使い果たし、システムが共有メモリロックを使用せざるを得なくなることがあります。高速パスから共有メモリロックへの切り替えは、ロックマネージャーにおいて軽量ロック ( LWLock ) の競合を生み出し、読み取り専用操作であってもデータベースのパフォーマンスに影響を与えます。 本投稿では、読み取り集約型のワークロードが、高速パスロックの制限を超えることによって LWLock 競合を引き起こす仕組みを探求します。これは、PostgreSQL エンジンとそのロック機構に基づく任意のシステムで発生する可能性がある問題です。デモンストレーション目的で本投稿では Aurora PostgreSQL 互換エディション を使用します。実際的な実験を通じて、パーティションスキャン、インデックスの使用、複雑な結合がロック動作にどのような影響を与えるかを実演します。また、ワークロードが低速パスロックに移行するタイミングを特定する方法と、より良いパフォーマンスのためにクエリ設計とスキーマ構造を最適化する具体的な技術を実装する方法も示します。 読み取り集約型のワークロードが増加するにつれて、データベース管理者 (DBA) は、データベースを健全に保つために LWLock 競合を監視し、対処する必要があります。同様に、開発者は過度の競合を引き起こすパターンを避けなければなりません。データベースが高速パスから低速パスロックに移行すると、スループットは大幅に低下する可能性があります (本投稿のテストでは最大 34 パーセントのパフォーマンス差を示しています)。このスループット低下は、 LWLock:lock_manager などの待機イベントを監視し、 pg_locks ビューを確認してワークロードを実行している バックエンドプロセス の高速パススロットが枯渇しているかどうかを確認することで特定できます。これらのボトルネックに対処するには、効果的な パーティションプルーニング 、慎重なインデックス管理、PostgreSQL のバックエンドプロセスあたり 16 スロットの高速パス制限内にワークロードを収めるシンプルな結合パターンなどの戦略が必要です。 LWLock 競合の理解 LWLock は、共有メモリ構造へのアクセスを調整するために PostgreSQL で使用される同期の仕組みです。 ヘビーウェイトロック ( ユーザー主導のデータベースオブジェクトレベルのロック) とは異なり、LWLock は軽量で高パフォーマンスに最適化されており、共有データへの同時アクセスを管理しながら低いオーバーヘッドを提供します。 LWLock 競合は、複数のプロセスが共有メモリ内の ロックデータ構造 上の同じ LWLock を取得しようと競合する際に発生し、遅延を引き起こします。この競合は通常、多くのバックエンドプロセスが次のような頻繁に共有されるリソースにアクセスする必要がある場合に発生します。 Buffer Manager – 読み取り/書き込み操作中に共有バッファを保護する Lock Manager – ロック関連のデータ構造へのアクセスを調整する WAL management – 先行書き込みログ ( WAL ) への書き込みを同期する LWLock 競合は、同時データベース接続数が増加するにつれて増大する可能性があります。 これは特に、Aurora PostgreSQL 互換エディションが、高並列処理、多数のパーティションを持つテーブル、または多数のインデックスを持つテーブルを含むワークロードの高スループット環境で顕著です。 テーブルに対して SQL クエリを実行する際、PostgreSQL はそのテーブルと関連するインデックスに対してロックを取得しようとします。これがパーティションテーブルの場合、SQL クエリによってアクセスされるテーブルパーティションに対してロックが取得されます。ロックをより高速かつ効率的にするため、システムが他のロックとの競合がないことを迅速に確認できる場合、制限の少ない弱いロック ( AccessShareLock 、 RowShareLock 、 RowExclusiveLock など) に対して高速パスロックが使用されます。 高速パスロック: 動作メカニズム PostgreSQL では、高速パスロッキング機構により、競合しない操作は共有メモリロックハッシュテーブルとそれに関連する LWLocks をバイパスすることができます。高速パスロッキングは、最も一般的な使用例、即ち、同じリレーションに競合する強力なロックが存在しない限り、弱いロックを取得する頻繁な同時クエリ向けに設計されています。 高速パスロックの動作は以下の通りです。 セッション別キャッシュ – 各バックエンドプロセスは、高速パスロックを格納するために、プライベート PGPROC 構造内に最大 16 個のスロット (デフォルトで FP_LOCK_SLOTS_PER_BACKEND = 16 ) を割り当てます。 迅速な高速パス適格性チェック – SELECT * FROM my_table; を実行すると、PostgreSQL は小さなバックエンド別の LWLock ( MyProc-&gt;fpInfoLock ) を取得して、現在の SQL クエリに高速パスロック機構が使用できるか、以下の項目をチェックします。 ロックモードが適格な弱いモードであること 他のセッションが競合するロックを保持していないこと バックエンドがローカルバックエンドメモリ配列の 16 スロットをすべて使用していないこと ローカル許可 – 上記の高速パス適格性チェックがパスすると、 FastPathGrantRelationLock() がバックエンドのローカルキャッシュにロックを格納します。共有メモリベースのロックハッシュテーブルを保護する共有メモリベースの LWLock は取得されず、関数は成功して即座にリターンします。 実際には、これはトランザクションがアクセスする最初の 16 個の一意のテーブル (またはインデックス) では、ロックマネージャーのオーバーヘッドはほぼゼロになることを意味します。 高速パスキャッシュは小さく、16 個のロックを超えたり、より強いロックモードを要求したりすると、PostgreSQL は低速パスにフォールバックしなければなりません。 既に取得済みの 16 個の高速パスロックを超える高速パスロックのすべての要求は、 FastPathTransferRelationLocks() を使用して共有ロックテーブルに移行されます ロックタグ（リレーション OID とロックモードを含む）は、共有メモリロックハッシュテーブルの 16 個のロックパーティションのうちの 1 つにハッシュ化されます PostgreSQL は次に、パーティション LWLock ( LWLockAcquire(partitionLock, LW_EXCLUSIVE) ) を取得し、共有ハッシュテーブルを更新し、LWLock を解放します それ以降、テーブルからインデックスまでの追加のロック取得は、ロックマネージャーを通じて行われ、同時実行下で LWLock:LockManager 待機イベントを生成します。 高速パス最適化から低速パス競合への移行を理解することで、高速パスの制限内に留まるクエリとスキーマを設計し、ロックマネージャーのボトルネックを完全に回避できます。 実験概要 以下のセクションでは、3 つの実験を通じて LWLock 競合の詳細を説明します。 パーティション化されたテーブルでのロックを観察する 使用されていない、または不要な複数のインデックスを持つパーティション化されていないテーブルでのロックを観察する マルチ結合クエリでのロック動作を観察する それぞれの実験では、スキーマのセットアップ、ワークロードの実行、PostgreSQL システムビューによるロック監視、および pgbench を使用した同時実行の影響分析を実演します。すべての実験は、db.r7g.4xlarge インスタンスを使用して Aurora PostgreSQL 互換エディション (PostgreSQL 16.6 と互換性あり) で実施しました。 前提条件 実験を開始する前に、以下が必要となります。 Aurora PostgreSQL データベースへのアクセス権を持つ AWS アカウント AWS Management Console へのアクセス権 Aurora PostgreSQL インスタンスへの接続性を持つ Amazon Elastic Compute Cloud (Amazon EC2) インスタンス Amazon EC2 インスタンス上にインストールされた PostgreSQL クライアント (psql など) Amazon EC2 インスタンス上にインストールされた pgbench Aurora PostgreSQL クラスターを作成・管理するための AWS Identity and Access Management (IAM) 権限 実験 1 : パーティション化されたテーブルでのロックを観察する この実験では、3 つの主要なテストシナリオを実行し、パーティション化されたテーブルを扱う際の PostgreSQL のロック動作を調査します。 orders テーブルのすべてのパーティションをクエリして、PostgreSQL がパーティション全体にわたってロックをどのように処理するかを観察します 特定のパーティションにアクセスするためにパーティションプルーニングを使用して、より的を絞ったアプローチを検証します 実世界のワークロードをシミュレートするため に pgbench を使用して、高い同時実行下で両方のアプローチをストレステストします これらのクエリを通じて、PostgreSQL の高速パスロック最適化がどのように動作するか、高速パススロットが枯渇したときに何が起こるか、および同時実行ワークロード下でパーティションプルーニングがいかにパフォーマンスを改善できるかを実演します。 order_ts タイムスタンプ列を使用して月単位でデータがパーティション化された orders テーブルを使用します。 この実験では、以下の点について重要な洞察が明らかになります。 PostgreSQL が読み取り専用操作中にロックをどのように管理するか 高速パスと低速パスロックの影響 パーティションプルーニングがどのようにロック競合を軽減できるか 高並行性環境におけるパフォーマンスへの影響 スキーマ準備 好みの PostgreSQL クライアント (psql など) を使用して、EC2 インスタンスから Aurora PostgreSQL インスタンスに接続し、12 の月次子パーティションを持つ orders テーブルを作成します。以下の SQL コードを実行してください。 -- Create the schema CREATE SCHEMA experiment_1; SET search_path TO experiment_1; -- Create the partitioned parent table CREATE TABLE orders ( id int NOT NULL, order_ts timestamp NOT NULL, customer_id int, amount numeric, PRIMARY KEY (id, order_ts) ) PARTITION BY RANGE (order_ts); -- Create child partitions (example: Jan 2025 - Jun 2025) DO $$ DECLARE month int := 1; partition_name text; from_date date; to_date date; BEGIN WHILE month &lt;= 12 LOOP partition_name := 'orders_2025_' || to_char(month, 'FM00'); from_date := make_date(2025, month, 1); to_date := from_date + interval '1 month'; EXECUTE format( 'CREATE TABLE %I.%I PARTITION OF %I.%I FOR VALUES FROM (%L) TO (%L)', 'experiment_1', partition_name, 'experiment_1', 'orders', from_date, to_date ); month := month + 1; END LOOP; END $$; テスト 1 : Orders テーブルの全パーティションをクエリして、ロック動作を観察する それでは、トランザクションを開始し、パーティション化された orders テーブルのすべてのパーティションに対してクエリを実行します。パーティションプルーニング無でクエリを実行すると、PostgreSQL はすべてのパーティションにアクセスする必要があり、ロックのオーバーヘッドが大幅に増加します。このテストを開始するには、Aurora PostgreSQL データベースへの新しい接続を開き、以下のコマンドを実行します (これをセッション 1 と呼びます) 。 postgres=&gt; set search_path to experiment_1; SET postgres=&gt; begin; BEGIN postgres=*&gt; select count(*) from orders; count ------- 0 (1 row) 上記のSQL ステートメントは、12 のパーティションすべてをスキャンするトランザクションを開始します。 COMMIT 、 ROLLBACK または End コマンドを実行せず、トランザクションを開いたままにしてロックを維持してください。 セッション 1 のトランザクションが開いたままの状態で、2 番目のセッション (これをセッション 2 と呼びます) を開き、データベース内のロックの状態を確認するために次の SQL クエリを実行してください。 postgres=&gt; SELECT n.nspname AS schema, c.relname AS table, l.locktype, l.mode, l.fastpath FROM pg_locks l JOIN pg_class c ON l.relation = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid AND n.nspname &lt;&gt; 'pg_catalog'; schema | table | locktype | mode | fastpath --------------+---------------------+----------+-----------------+---------- experiment_1 | orders_2025_07_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_07 | relation | AccessShareLock | t experiment_1 | orders_2025_06_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_06 | relation | AccessShareLock | t experiment_1 | orders_2025_05_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_05 | relation | AccessShareLock | t experiment_1 | orders_2025_04_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_04 | relation | AccessShareLock | t experiment_1 | orders_2025_03_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_03 | relation | AccessShareLock | t experiment_1 | orders_2025_02_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_02 | relation | AccessShareLock | t experiment_1 | orders_2025_01_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_01 | relation | AccessShareLock | t experiment_1 | orders_pkey | relation | AccessShareLock | t experiment_1 | orders | relation | AccessShareLock | t experiment_1 | orders_2025_11 | relation | AccessShareLock | f experiment_1 | orders_2025_09 | relation | AccessShareLock | f experiment_1 | orders_2025_09_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_11_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_08_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_10 | relation | AccessShareLock | f experiment_1 | orders_2025_08 | relation | AccessShareLock | f experiment_1 | orders_2025_10_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_12_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_12 | relation | AccessShareLock | f (26 rows) 前述の出力の最後の 10 行で fastpath 列の値が t (True) と f (False) のうち、f になっていることに注目してください。また、返された行の総数は 26 です。値 t は、16 の高速パススロットが使い果たされ、残りのパーティション/インデックスの AccessShareLock が共有メモリロックハッシュテーブル (低速パス) に移行されたことを意味します。トランザクションが完了すると、これらのロックは解放されます。 テスト 2 : 注文テーブルの特定のパーティションをクエリし、ロック動作の変化を観察する セッション 1 として、以下に示すように、新しいトランザクション内でパーティションプルーニングアプローチを使用するクエリを実行します。より多くのパーティションにアクセスし続けると、追加の高速パスロックが獲得されます。 postgres=&gt; set search_path to experiment_1; SET postgres=&gt; begin; BEGIN postgres=*&gt; SELECT * FROM orders WHERE order_ts &lt;= '2025-01-01'; id | order_ts | customer_id | amount ----+----------+-------------+-------- (0 rows) postgres=*&gt; SELECT * FROM orders WHERE order_ts &lt;= '2025-02-01'; id | order_ts | customer_id | amount ----+----------+-------------+-------- (0 rows) postgres=*&gt; SELECT * FROM orders WHERE order_ts &lt;= '2025-03-01'; id | order_ts | customer_id | amount ----+----------+-------------+-------- (0 rows) セッション 1 のトランザクションが開いたままの状態で、前回のテストで利用したセッション 2 で以下の SQL 文を実行して、データベース内のロックの状態を確認してください。 postgres=&gt; SELECT n.nspname AS schema, c.relname AS table, l.locktype, l.mode, l.fastpath FROM pg_locks l JOIN pg_class c ON l.relation = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid AND n.nspname &lt;&gt; 'pg_catalog'; schema | table | locktype | mode | fastpath --------------+---------------------+----------+-----------------+---------- experiment_1 | orders_2025_03_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_03 | relation | AccessShareLock | t experiment_1 | orders_2025_02_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_02 | relation | AccessShareLock | t experiment_1 | orders_2025_01_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_01 | relation | AccessShareLock | t experiment_1 | orders_pkey | relation | AccessShareLock | t experiment_1 | orders | relation | AccessShareLock | t (8 rows) この出力は、すべてのロックが高速パスロックであることを示しており、 fastpath 列の値が t (True) になっています。これにより、低速パスロックを取得する必要がなくなります。 これは高速パスの最適化を示していますが、同時実行を伴うシナリオについては説明していません。同時実行を伴うシナリオでは、各バックエンドが高速パススロットを使い切るか、16 スロットの制限内に留まるかのいずれかになります。この特定のシナリオを詳しく見ていきましょう。pgbench を使用してマルチユーザーワークロードをシミュレートします。 テスト 3.1 : Orders テーブルの全パーティションに複数クエリを同時実行し、ロック動作の変化を観察する パーティションプルーニングせずにパーティションにアクセスする複数の読み取りワークロードをシミュレートするには、以下の pgbench コマンドを使用します。このコマンドは複数のスレッドにわたって SELECT count(*) FROM orders クエリを継続的に発行します。このテストでは、トランザクションが高速パススロットを使い果たし、メインロックマネージャーを通じてロックの獲得を強制する ( LWLock:LockManager の待機をトリガーする) 高い並列度の下で、PostgreSQL の高速パスロック最適化がどのように動作するかを評価します。 pgbench -c 100 -j 10 -n -f transaction.sql -T 900 pgbench では、 -c と -j オプションを使用してベンチマークワークロードの同時実行性と並列性を制御します。-c オプションは同時クライアント数を指定し、同時にアクティブになるシミュレートされたユーザーセッションまたはデータベース接続の数を意味します。この数値によって、PostgreSQL データベースに適用される負荷のレベルが決まります。 -j オプションは pgbench がこれらのクライアント接続を管理するために使用するワーカースレッドの数を定義します。各スレッドは全クライアントの一部を処理し、ワークロードはスレッド間で均等に分散されます。これにより pgbench はマルチコアシステムをより効率的に使用し、クライアント側のボトルネックを回避できます。 実行時に認証情報を入力せずに pgbench コマンドを実行するには、次の環境変数を設定します： PGHOST (Auroraクラスターのエンドポイント)、 PGPORT (ポート番号、例えば 5432)、 PGDATABASE (データベース名、例えば postgres)、 PGUSER (データベースユーザー)、および PGPASSWORD (データベースユーザーのパスワード)。 上記の pgbench コマンドは、transaction.sql で定義されたトランザクションを実行する 100 の同時クライアント ( -c 100 ) を 15 分間または 900 秒 ( -T 900) シミュレートします。 transaction.sql ファイルには、 experiment_1 スキーマへの検索パスの設定とともに、次の SQL が含まれています。 set search_path to experiment_1; DO $$ DECLARE random_date date; last_day date; sql text; BEGIN random_date := date '2025-01-01' + floor(random() * 365)::int; last_day := (date_trunc('month', random_date) + interval '1 month - 1 day')::date; sql := format('SELECT COUNT(*) FROM orders'); EXECUTE sql; END $$; 前回のテストのセッション 1 ターミナルから、次の pgbench コマンドを実行してください。このコマンドは 15 分で完了します。このコマンドの実行中、 Amazon CloudWatch Database Insights のデータベースの待機イベントを監視します。 sh-5.1$ pgbench -c 100 -j 10 -n -f transaction.sql -T 900 transaction type: transaction.sql scaling factor: 1 query mode: simple number of clients: 100 number of threads: 10 duration: 900 s number of transactions actually processed: 42005251 latency average = 2.143 ms tps = 46672.159856 (including connections establishing) tps = 46672.894164 (excluding connections establishing) このワークロードでは、1 秒あたりの平均トランザクション数 (tps) は 46,672 に達し、テスト時間の 15 分間で 4,200 万のトランザクションが処理されました。 CloudWatch Database Insights の以下のスクリーンショットは、アクティブなセッションがインスタンスの CPU 容量を超え、著しいロック競合を伴う高負荷を経験しているデータベースを示しています。 上のスクリーンショットは、db.r7g.4xlarge インスタンスで実行されている Aurora PostgreSQL 16.6 クラスターが、CPU 使用率とロック競合の両方による高いデータベース負荷を示しています。平均アクティブセッション (AAS) は約 21 で維持されており、これはインスタンスの 16 vCPU 容量よりも高い値です。負荷の 66 パーセントは CPU 使用率に起因していますが、34 パーセントは LWLock:LockManager の待機に費やされており、PostgreSQL 内部ロック構造の競合を示しています。 次に、パーティションプルーニングを使用してパフォーマンスを評価します。 テスト 3.2 : パーティションプルーニングを使用して、Orders テーブルの特定のパーティションに複数クエリを同時実行する パーティションプルーニングを使用していない前回のテストと対比するために、ここではパーティションプルーニングがどのようにパフォーマンスを向上させるかを実証します。このワークロードでは、この実験に使用される transaction.sql ファイルには PL/pgSQL が含まれています。これは単純な SQL クエリの代わりに使用され、パーティション分割されたテーブルと実行時に生成される値を処理する際に、PostgreSQL で効率的なパーティションプルーニングを提供します。以下のクエリのように SQL を使用することもできますが、 order_ts に対するフィルターは共通テーブル式 (CTE) 内のランダムに生成された日付から派生しており、最適な実行計画を作成するクエリプランナーは、クエリ計画時に order_ts 値を決定できません。その結果、PostgreSQL はすべてのパーティションを考慮する必要があり、すべてのパーティションの不必要なロックとスキャンにつながります。しかし、ランダムな日付を計算し EXECUTE を使用してクエリを動的に構築する PL/pgSQL ブロックに切り替えることで、実際の日付値が SQL 文字列に直接注入されます。これにより、クエリプランナーの観点からフィルターが定数に変換され、効果的なパーティションプルーニングが可能になり、関連するパーティションのみがアクセスされロックされることが保証されます。 以下は、上記で説明した CTE ベースの SQL クエリで、すべてのパーティションをロックする可能性があります。 WITH rand_date AS ( SELECT (date '2025-01-01' + (floor(random() * 365))::int) AS dt ), last_day AS ( SELECT dt, (date_trunc('month', dt) + interval '1 month - 1 day')::date AS last_day FROM rand_date ) SELECT dt AS random_date, last_day, ( SELECT COUNT(*) FROM orders WHERE order_ts &gt;= last_day.last_day AND order_ts &lt; last_day.last_day + interval '1 day' ) AS order_count FROM last_day; 上記で説明した効果的なパーティションプルーニングを実現するために、以下の PL/pgSQL アプローチを使用した SQL を使用してください。 set search_path to experiment_1; DO $$ DECLARE random_date date; last_day date; sql text; BEGIN random_date := date '2025-01-01' + (floor(random() * 365))::int; last_day := (date_trunc('month', random_date) + interval '1 month - 1 day')::date; sql := format('SELECT count(*) FROM orders WHERE order_ts = %L', last_day); EXECUTE sql; 前回のテストと同じ手順に従い、セッション 1 のターミナルから pgbench コマンドを実行してください。このコマンドは 15 分でテストを完了し、コマンドの実行中、CloudWatch Database Insights のデータベースの待機イベントを監視します。 sh-5.15 pgbench -c 100 -j 10 -n -f transaction.sql -T 900 transaction type: transaction.sql scaling factor: 1 query mode: simple number of clients: 100 number of threads: 10 duration: 900 s number of transactions actually processed: 53240775 latency average = 1.690 ms tps = 59255.673468 (including connections establishing) tps = 59156.616479 (excluding connections establishing) 上記の pgbench 出力に示されているように、このワークロードは 1 秒あたり平均 59,255 トランザクションを達成し、15 分間のテスト期間中に約 5,330 万トランザクションが処理されました。ロック競合がない状態では、システムは 1,100 万トランザクションを追加で処理出来た事になります。 CloudWatch Database Insights の以下のスクリーンショットは、パーティションプルーニングを実装した後の改善されたデータベースパフォーマンスを示しており、安定した負荷パターンとロック競合がないことがわかります。 前述のワークロードにパーティションプルーニングを導入したことで、Aurora PostgreSQL 16.6 クラスターのパフォーマンスは大幅に向上しました。以前は、ワークロードは CPU 使用率と並んでデータベース負荷の約 34 パーセントを消費する LWLock:LockManager の待機イベントによって特徴付けられていました。 対照的に、現在のワークロードパフォーマンスはバランスの取れたワークロードを示しています。平均アクティブセッション (AAS) は最大 vCPU 閾値を下回っており、待機は Timeout:SpinDelay のごく一部が観測されているのみです。CPU は最適化された OLTP システムでは予想される通り、負荷の主要な要因となっています。そしてロック競合は大幅に減少しました。これは、パーティションプルーニングによって取得されるロックの数を削減し、各セッションが関連するパーティションとセッションごとの高速パスロックのみにアクセスするようになり、同時実行性が大幅に向上したことを意味します。パーティションプルーニングにより、AAS は最大 vCPU 閾値を下回ったままでした。 実験 2 : 複数の未使用または不要なインデックスを持つ非パーティションテーブルのロックを観察する この実験では、PostgreSQL が複数の B-tree インデックス を持つ非パーティション化テーブルでのロック動作をどのように処理するかを調査します。ここでは、使用されていないまたは不要なインデックスの影響に焦点を当てるためにパーティション化されていないテーブルを使用しています。E コマースまたは在庫システムを表す items テーブルを使用して、2 つの重要なテストシナリオを探ります。 まず、インデックスのみのスキャンを使用して単純なクエリを実行し、以下を観察します PostgreSQL が複数の未使用または不要なインデックス全体でロックをどのように管理するか 高速パススロットが使い果たされた場合に何が起こるか 20 個の B-tree インデックスを持つことがロック取得に与える影響 次に、高い同時実行性の下でシステムのストレステストを行い、以下を実証します 過剰なインデックスがロックマネージャーの動作にどのように影響するか 複数のインデックスによるロック競合のパフォーマンスへの影響 インデックス数と LWLock:LockManager の待機の関係 これらのテストを通じて、インデックス関連のロックオーバーヘッドに関する重要な洞察を明らかにし、高い同時実行性の環境におけるインデックス管理のための実践的なガイダンスを提供します。 スキーマ準備 以下の SQL コードを使用して、Aurora PostgreSQL データベースに items テーブルスキーマとそれに関連するインデックスを作成してください。 -- Create Schema CREATE SCHEMA IF NOT EXISTS experiment_2; SET search_path TO experiment_2; CREATE TABLE items ( item_id SERIAL PRIMARY KEY, sku TEXT NOT NULL, barcode TEXT, name TEXT NOT NULL, description TEXT,category TEXT, subcategory TEXT, vendor_id INT, vendor_region TEXT, brand TEXT, model TEXT,price NUMERIC(10,2), cost NUMERIC(10,2), discount NUMERIC(5,2), margin NUMERIC(5,2), quantity_in_stock INT, reorder_level INT, lead_time_days INT, rating NUMERIC(2,1) ,num_reviews INT, available BOOLEAN DEFAULT true, warehouse_location TEXT, is_active BOOLEAN DEFAULT true,last_restocked TIMESTAMP, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now() ); CREATE INDEX idx_items_sku ON items(sku); CREATE INDEX idx_items_barcode ON items(barcode); CREATE INDEX idx_items_name ON items(name); CREATE INDEX idx_items_category ON items(category); CREATE INDEX idx_items_vendor_id ON items(vendor_id); CREATE INDEX idx_items_brand ON items(brand); CREATE INDEX idx_items_model ON items(model); CREATE INDEX idx_items_price ON items(price); CREATE INDEX idx_items_cost ON items(cost); CREATE INDEX idx_items_quantity ON items(quantity_in_stock); CREATE INDEX idx_items_rating ON items(rating); CREATE INDEX idx_items_num_reviews ON items(num_reviews); CREATE INDEX idx_items_created_at ON items(created_at); CREATE INDEX idx_items_updated_at ON items(updated_at); CREATE INDEX idx_items_vendor_category ON items(vendor_id, category); CREATE INDEX idx_items_sku_available ON items(sku, available); CREATE INDEX idx_items_barcode_active ON items(barcode, is_active); CREATE INDEX idx_items_category_subcategory_price ON items(category, subcategory, price); CREATE INDEX idx_items_vendor_region_brand ON items(vendor_region, brand); CREATE INDEX idx_items_brand_model ON items(brand, model); 上記の SQL コードは、商品の詳細 ( SKU 、 price 、 inventory など) 用の 26 カラムを持つ E コマースの items テーブルと、よく検索されるカラムやカラムの組み合わせに対する 20 個の B-tree インデックスを作成します。 テスト 1 : 複数のインデックスを持つ非パーティションテーブルをクエリする 過剰なインデックスが PostgreSQL のロック動作にどのように影響するかの調査を始めるために、最初のテストとして items テーブルに対してクエリを実行しましょう。単純な名前検索クエリを実行して、ほとんどのインデックスがこのクエリには不要であるにもかかわらず、PostgreSQL が 20 個すべてのインデックスにわたってロック管理をどのように処理するかを観察します。これにより、過剰なインデックスを維持することで生じる基本的なロックオーバーヘッドを理解するのに役立ちます。トランザクションを開始し、インデックスアクセスパスを使用して items テーブルの特定のカラムにクエリを実行します。 postgres=&gt; set search_path to experiment_2; SET postgres=&gt; EXPLAIN SELECT name FROM items WHERE name = 'test'; QUERY PLAN ---------------------------------------------------------------- Index Only Scan using idx_items_name on items (cost=0.14..8.16 rows=1 width=32) Index Cond: (name = 'test'::text) (2 rows) postgres=&gt; BEGIN; BEGIN postgres=&gt; SELECT name FROM items WHERE name = 'test'; name ------ (0 rows) 前述の SQL クエリに対して、クエリプランナーはインデックスのみのスキャンパスを選択しました。この SQL では items テーブルから name カラムのみを選択しています。別のセッションで、ロック動作を観察します。 以下の出力で、 items テーブル、主キー、およびクエリ実行のためにプランナーが使用したインデックス ( idx_items_name ) とは別に AccessShareLock を獲得したインデックスに注目して下さい。返された行の総数は 22 で、高速パススロットは使い果たされ、6 つのロックが共有メモリロックテーブルに移動しました。このテーブルにさらにインデックスがあった場合、それらのインデックスも AccessShareLock を必要とし、高速パススロットが使い果たされているため共有メモリロックテーブルに配置されるでしょう。このテーブルに対して高い並行ワークロードが発生すると、共有メモリロックテーブルで競合が発生するため、パフォーマンスは低下する事が想定されます。 postgres=&gt; SELECT n.nspname AS schema, c.relname AS table, l.locktype, l.mode, l.fastpath FROM pg_locks l JOIN pg_class c ON l.relation = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid AND n.nspname &lt;&gt; 'pg_catalog'; schema | table | locktype | mode | fastpath --------------+--------------------------------------+----------+-----------------+---------- experiment_2 | idx_items_updated_at | relation | AccessShareLock | t experiment_2 | idx_items_created_at | relation | AccessShareLock | t experiment_2 | idx_items_num_reviews | relation | AccessShareLock | t experiment_2 | idx_items_rating | relation | AccessShareLock | t experiment_2 | idx_items_quantity | relation | AccessShareLock | t experiment_2 | idx_items_cost | relation | AccessShareLock | t experiment_2 | idx_items_price | relation | AccessShareLock | t experiment_2 | idx_items_model | relation | AccessShareLock | t experiment_2 | idx_items_brand | relation | AccessShareLock | t experiment_2 | idx_items_vendor_id | relation | AccessShareLock | t experiment_2 | idx_items_category | relation | AccessShareLock | t experiment_2 | idx_items_name | relation | AccessShareLock | t experiment_2 | idx_items_barcode | relation | AccessShareLock | t experiment_2 | idx_items_sku | relation | AccessShareLock | t experiment_2 | items_pkey | relation | AccessShareLock | t experiment_2 | items | relation | AccessShareLock | t experiment_2 | idx_items_vendor_region_brand | relation | AccessShareLock | f experiment_2 | idx_items_brand_model | relation | AccessShareLock | f experiment_2 | idx_items_vendor_category | relation | AccessShareLock | f experiment_2 | idx_items_barcode_active | relation | AccessShareLock | f experiment_2 | idx_items_sku_available | relation | AccessShareLock | f experiment_2 | idx_items_category_subcategory_price | relation | AccessShareLock | f (22 rows) テスト 2 : 高い同時実行性のもとで、複数のインデックスを持つ非パーティションテーブルをクエリする これらの不要なインデックスがパフォーマンスにどのように影響するかを理解するために、高い並行性の下でパーティション化されていない items テーブルのストレステストを行いましょう。パーティション化されたテーブル (実験 1) での実験と同様に、pgbench を使用して複数の同時ユーザーが同時にテーブルにアクセスすることをシミュレートします。 最初の実験と同じ pgbench コマンドを使用して、セッション 1 のターミナルから以下を実行します。このテストは 5 分間実行されます。テスト実行中、CloudWatch Database Insights のデータベースの待機イベントを監視します。 pgbench -c 100 -j 10 -n -f transaction.sql -T 300 transaction.sql ファイルには、前回のテストと同じ items テーブルに対する名前検索 SQL クエリが含まれています。 CloudWatch Database Insights の以下のスクリーンショットは、 items テーブルの過剰なインデックスによって、 LWLock:LockManager の待機時間が増加し、データベース負荷と CPU 使用率が増加する様子を示しています。 ここで観察された LWLock:LockManager 待ちは、主に items テーブルの過剰なインデックスによって引き起こされています。データが無い場合でも、PostgreSQL はクエリの計画と実行中に 20 個すべてのインデックスを調べ、関連するロックを取得し、カタログメタデータにアクセスする必要があるため、オーバーヘッドが発生します。高い並行性のため、多数のロックが関与し、データベースセッションは高速パスロックを使い果たし、バックエンドプロセスがメインロックマネージャーに頼らざるを得なくなり、追加の競合が発生しました。これにより、繰り返されるカタログスキャンによる CPU 使用率の増加と、ロック取得のオーバーヘッドによるデータベース負荷の上昇が生じました。不要なインデックスの数を減らすことは、クエリプランニングの複雑さを減少させるだけでなく、高速パスロッキングを維持するのに役立ち、高い並行性のワークロードの下でシステム効率を向上させるでしょう。 実験 3 : 複数結合クエリでのロック動作を観察する この実験では、PostgreSQL が複数の関連テーブルにまたがる複雑なクエリを実行する際にどのようにロックを管理するかを調査します。実際的な E コマースデータベーススキーマを使用して、2 つの重要なテストシナリオを探ります。 まず、単一のマルチ結合クエリを検証します ユーザーのカート内容、アイテム価格、注文状況、および支払い詳細を単一の読み取り専用操作で取得します 6 つの相互関連テーブル ( users 、 carts 、 cart_items 、 items 、 orders 、 payments ) を接続します PostgreSQL が複数のテーブルとそのインデックスにまたがるロックをどのように処理するかを実証します このクエリは、複数のテーブル結合が累積的なロックのフットプリントにどのように影響するかを観察する機会を提供します。各テーブルには独自の主キーと外部キーのインデックスがあるため、PostgreSQL はこれらの単純な読み取りに高速パスロックを使用できる可能性があり、共有メモリロックテーブルにエントリを取得するオーバーヘッドを回避できます。 次に、高い並行性の下でシステムのストレステストを行います 複雑な結合を実行する複数のセッションがロック管理にどのように影響するかを観察します 複数のインデックス付きテーブルにまたがるロック取得のパフォーマンスへの影響を測定します 結合の複雑さが CPU 使用率とロック競合の両方にどのように影響するかを実証します これらのテストを通じて、以下に関する重要な洞察を明らかにします。 複雑な相互接続されたテーブル構造におけるロック管理 テーブル結合、インデックス、およびロックオーバーヘッドの関係 高い並行性環境におけるマルチ結合クエリのパフォーマンスに関する考慮事項 スキーマ準備 以下の SQL コードを使用して、6 つの相互接続されたテーブル ( users 、 carts 、 cart_items 、 items 、 orders 、および payments ) とそれらに関連するインデックスおよび外部キー制約を含む E コマーススキーマを作成してください。このスキーマは、実際の E コマースデータベースをシミュレートするために、テーブルごとに複数のインデックスと適切な参照整合性制約を含む包括的な設計になっています。 -- Create Schema CREATE SCHEMA IF NOT EXISTS experiment_3; SET search_path TO experiment_3; -- USERS table CREATE TABLE users ( user_id SERIAL PRIMARY KEY, name TEXT NOT NULL, email TEXT UNIQUE NOT NULL, phone TEXT, role TEXT DEFAULT 'customer', is_active BOOLEAN DEFAULT TRUE, is_deleted BOOLEAN DEFAULT FALSE, created_by INT, updated_by INT, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), deleted_at TIMESTAMP ); -- Indexes for USERS CREATE INDEX idx_users_name_created_at ON users(name, created_at); CREATE INDEX idx_users_email_active ON users(email, is_active); CREATE INDEX idx_users_role_active ON users(role, is_active); CREATE INDEX idx_users_created_at ON users(created_at); -- ITEMS table CREATE TABLE items ( item_id SERIAL PRIMARY KEY, name TEXT NOT NULL, description TEXT, sku TEXT UNIQUE, category TEXT, price NUMERIC(10,2) NOT NULL, discount NUMERIC(5,2) DEFAULT 0.00, stock_quantity INT NOT NULL, restock_threshold INT DEFAULT 10, is_active BOOLEAN DEFAULT TRUE, is_deleted BOOLEAN DEFAULT FALSE, created_by INT, updated_by INT, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), deleted_at TIMESTAMP ); -- Indexes for ITEMS CREATE INDEX idx_items_price_stock ON items(price, stock_quantity); CREATE INDEX idx_items_category_active ON items(category, is_active); CREATE INDEX idx_items_name_price ON items(name, price); CREATE INDEX idx_items_created_at ON items(created_at); -- CARTS table CREATE TABLE carts ( cart_id SERIAL PRIMARY KEY, user_id INT REFERENCES users(user_id) ON DELETE CASCADE, status TEXT DEFAULT 'open', is_deleted BOOLEAN DEFAULT FALSE, expires_at TIMESTAMP, created_by INT, updated_by INT, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), deleted_at TIMESTAMP ); -- Indexes for CARTS CREATE INDEX idx_carts_user_created ON carts(user_id, created_at); CREATE INDEX idx_carts_user_status ON carts(user_id, status); CREATE INDEX idx_carts_status_expires ON carts(status, expires_at); CREATE INDEX idx_carts_created_at ON carts(created_at); -- CART_ITEMS table CREATE TABLE cart_items ( cart_item_id SERIAL PRIMARY KEY, cart_id INT REFERENCES carts(cart_id) ON DELETE CASCADE, item_id INT REFERENCES items(item_id) ON DELETE RESTRICT, quantity INT NOT NULL CHECK (quantity &gt; 0), price_at_addition NUMERIC(10,2), is_deleted BOOLEAN DEFAULT FALSE, added_at TIMESTAMP DEFAULT now() ); -- Indexes for CART_ITEMS CREATE INDEX idx_cart_items_cart_item ON cart_items(cart_id, item_id); CREATE INDEX idx_cart_items_item_deleted ON cart_items(item_id, is_deleted); CREATE INDEX idx_cart_items_cart_added ON cart_items(cart_id, added_at); CREATE INDEX idx_cart_items_added_at ON cart_items(added_at); -- ORDERS table CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, user_id INT REFERENCES users(user_id), cart_id INT REFERENCES carts(cart_id), status TEXT NOT NULL CHECK (status IN ('pending', 'paid', 'shipped', 'cancelled', 'refunded')), shipping_address TEXT, billing_address TEXT, tracking_number TEXT, payment_due_date TIMESTAMP, is_deleted BOOLEAN DEFAULT FALSE, total NUMERIC(10,2), created_by INT, updated_by INT, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), deleted_at TIMESTAMP ); -- Indexes for ORDERS CREATE INDEX idx_orders_status_created ON orders(status, created_at); CREATE INDEX idx_orders_user_status ON orders(user_id, status); CREATE INDEX idx_orders_user_created ON orders(user_id, created_at); CREATE INDEX idx_orders_tracking ON orders(tracking_number); -- PAYMENTS table CREATE TABLE payments ( payment_id SERIAL PRIMARY KEY, order_id INT REFERENCES orders(order_id) ON DELETE CASCADE, payment_method TEXT NOT NULL, payment_status TEXT DEFAULT 'initiated', transaction_id TEXT UNIQUE, currency TEXT DEFAULT 'USD', amount NUMERIC(10,2) NOT NULL, is_refundable BOOLEAN DEFAULT FALSE, paid_at TIMESTAMP DEFAULT now(), refunded_at TIMESTAMP ); -- Indexes for PAYMENTS CREATE INDEX idx_payments_method_paid_at ON payments(payment_method, paid_at); CREATE INDEX idx_payments_method_status ON payments(payment_method, payment_status); CREATE INDEX idx_payments_order_status ON payments(order_id, payment_status); CREATE INDEX idx_payments_currency_paid ON payments(currency, paid_at); テスト 1 : 複数のインデックステーブルにわたるマルチ結合クエリを実行する PostgreSQL が複雑な結合操作中にロックをどのように処理するかの調査を開始するために、ユーザーのショッピングカート情報を取得するマルチ結合クエリを使用して最初のテストを実行しましょう。このクエリは、PostgreSQL が複数のテーブルとそれらに関連するインデックスにわたってロックをどのように管理するかを示します。セッション 1 で、トランザクションを開始して次のクエリを実行します。 postgres=&gt; SET search_path TO experiment_3; BEGIN; SELECT u.user_id, u.name AS user_name, c.cart_id, i.name AS item_name, ci.quantity, i.price, (i.price * ci.quantity) AS line_total, o.order_id, o.status, p.payment_method, p.amount FROM users u JOIN carts c ON c.user_id = u.user_id JOIN cart_items ci ON ci.cart_id = c.cart_id JOIN items i ON i.item_id = ci.item_id LEFT JOIN orders o ON o.cart_id = c.cart_id LEFT JOIN payments p ON p.order_id = o.order_id WHERE u.user_id = (1 + floor(random() * 10))::int; SET BEGIN user_id | user_name | cart_id | item_name | quantity | price | line_total | order_id | status | payment_method | amount ---------+-----------+---------+-----------+----------+-------+------------+----------+--------+----------------+-------- (0 rows) セッション 1 で上記のトランザクションを開いたままにして、セッション 2 で以下のクエリを実行し、PostgreSQL がマルチ結合クエリに関わるすべてのテーブルとインデックスにわたってロックをどのように管理しているかを調べてください。 postgres=&gt; SELECT n.nspname AS schema, c.relname AS table, l.locktype, l.mode, l.fastpath FROM pg_locks l JOIN pg_class c ON l.relation = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid AND n.nspname &lt;&gt; 'pg_catalog'; schema | table | locktype | mode | fastpath ---------------+------------------------------+----------+----------------+---------- experiment_3 | idx_carts_status_expires | relation | AccessShareLock | t experiment_3 | idx_carts_user_status | relation | AccessShareLock | t experiment_3 | idx_carts_user_created | relation | AccessShareLock | t experiment_3 | carts_pkey | relation | AccessShareLock | t experiment_3 | idx_users_created_at | relation | AccessShareLock | t experiment_3 | idx_users_role_active | relation | AccessShareLock | t experiment_3 | idx_users_email_active | relation | AccessShareLock | t experiment_3 | idx_users_name_created_at | relation | AccessShareLock | t experiment_3 | users_email_key | relation | AccessShareLock | t experiment_3 | users_pkey | relation | AccessShareLock | t experiment_3 | payments | relation | AccessShareLock | t experiment_3 | orders | relation | AccessShareLock | t experiment_3 | items | relation | AccessShareLock | t experiment_3 | cart_items | relation | AccessShareLock | t experiment_3 | carts | relation | AccessShareLock | t experiment_3 | users | relation | AccessShareLock | t experiment_3 | idx_cart_items_item_deleted | relation | AccessShareLock | f experiment_3 | idx_orders_user_status | relation | AccessShareLock | f experiment_3 | idx_cart_items_cart_item | relation | AccessShareLock | f experiment_3 | idx_payments_order_status | relation | AccessShareLock | f experiment_3 | idx_carts_created_at | relation | AccessShareLock | f experiment_3 | idx_cart_items_cart_added | relation | AccessShareLock | f experiment_3 | idx_items_created_at | relation | AccessShareLock | f experiment_3 | orders_pkey | relation | AccessShareLock | f experiment_3 | payments_pkey | relation | AccessShareLock | f experiment_3 | idx_items_name_price | relation | AccessShareLock | f experiment_3 | idx_payments_method_status | relation | AccessShareLock | f experiment_3 | payments_transaction_id_key | relation | AccessShareLock | f experiment_3 | idx_items_category_active | relation | AccessShareLock | f experiment_3 | items_pkey | relation | AccessShareLock | f experiment_3 | idx_orders_status_created | relation | AccessShareLock | f experiment_3 | idx_items_price_stock | relation | AccessShareLock | f experiment_3 | idx_cart_items_added_at | relation | AccessShareLock | f experiment_3 | idx_orders_tracking | relation | AccessShareLock | f experiment_3 | idx_payments_currency_paid | relation | AccessShareLock | f experiment_3 | cart_items_pkey | relation | AccessShareLock | f experiment_3 | items_sku_key | relation | AccessShareLock | f experiment_3 | idx_orders_user_created | relation | AccessShareLock | f experiment_3 | idx_payments_method_paid_at | relation | AccessShareLock | f (39 rows) 上記の出力では、PostgreSQL が合計 39 個のロックを取得したことがわかります。 fastpath 列を見ると、23 行が f (false) を示しており、これらのロックは高速パスの代わりに共有メモリロックテーブルを通じた、低速パスを使用する必要があったことを示しています。これは、一見単純なネスト結合クエリでも、高速パススロットが使い果たされると著しいロック競合が発生する可能性があることを示しています。 テスト 2 : 高い同時実行性でマルチ結合クエリを実行する 上記の SQL クエリにおける複雑な結合が大規模環境でどのように実行されるかを理解するために、高い並行性の下で E コマーススキーマのストレステストを実施しましょう。前回の実験と同様に、pgbench を使用して複数の同時ユーザーが同時にマルチ結合クエリを実行することをシミュレートします。 前回の実験 (実験 1 と 2) と同じ pgbench コマンドを使用して、セッション 1 のターミナルから以下を実行します。このテストは 5 分間実行されます。 pgbench -c 100 -j 10 -n -f transaction.sql -T 300 transaction.sql ファイルには、前のテストと同じマルチ結合 SQL クエリが含まれています。テスト実行中、CloudWatch Database Insights でデータベース待機イベントを監視します。 CloudWatch Database Insights の以下のスクリーンショットは、多数のインデックスが付いたテーブル間のマルチ結合クエリが、アクティブセッションの 20 パーセントを消費する LWLock:LockManager 競合と、80 パーセントで飽和に近づく CPU 使用率という二重のパフォーマンス影響をもたらすことを示しています。 データベース負荷グラフは、複数のインデックスを持つテーブル間でのマルチ結合クエリによる著しい LWLock:LockManager 競合 (AAS の 20 パーセント) と高い CPU 使用率 (80 パーセント) を示しています。各結合は、PostgreSQL がインデックスに対して AccessShareLock ロックを取得することを強制し、高速パスロックを使い果たし、より遅いメインロックマネージャーに頼ることになります。クエリプランニング中の繰り返しのカタログスキャンにより、CPU 使用率は飽和に近づいています。このロックマネージャーのボトルネックは、結合プランニング中に複数のインデックス付きテーブル全体でロックを維持することの複合的なオーバーヘッドに起因しています。冗長なインデックスを減らし、結合パターンを簡素化することで、ワークロードで見られるロック競合と CPU 圧力の両方が軽減されるでしょう。 PostgreSQL のロック競合を管理するための主な緩和戦略 PostgreSQL のロック競合を軽減するための以下の主要な対策を検討してください。 パーティション化されたテーブルへの最適化されたアクセス パーティションプルーニングを有効にする – フルテーブルスキャンの代わりに明示的な日付範囲 ( WHERE order_ts BETWEEN X AND Y ) を使用します。 PostgreSQL のドキュメント からパーティションプルーニングについて詳細を学んでください。 定数のない動的 SQL を避ける – プルーニングを強制するため、本投稿の最初の実験のように CTE を PL/pgSQL ブロックに置き換えます。 パーティション数を制限する – 可能な場合はパーティションを減らし (例えば、月次パーティションの代わりに四半期パーティションを検討)、高速パスの制限内に収めます。 インデックスの合理化 未使用のインデックスを監査し削除する – pg_stat_user_indexes を使用して使用頻度の低いインデックスを特定します。 冗長なインデックスを統合する – 単一カラムのインデックスを複合インデックスに置き換えます (例えば、3 つの個別インデックスの代わりに( category , subcategory , price ))。 過剰なインデックス付けを避ける – OLTP にとって重要でない限り、テーブルあたりのインデックス数を制限します (例えば、10 以下)。 スキーマ設計の調整 不必要なパーティション化を避ける – 100GB を超えるテーブルまたは明確なアクセスパターンがあるテーブルのみをパーティション化します。テーブルパーティション化をいつどのように実装するかについての詳細なガイダンスは、「 Improve performance and manageability of large PostgreSQL tables by migrating to partitioned tables on Amazon Aurora and Amazon RDS 」を参照してください。 カバリングインデックスを使用する – テーブルアクセスを避けるために INCLUDE 列を追加します (リレーションロックを減らします)。カバリングインデックスとインデックスのみのスキャンの実装についての詳細は、 PostgreSQL のドキュメント を参照してください。 高並行性テーブルを正規化する – 幅広いテーブル (例えば、 items ) を分割してインデックスの拡散を減らします。 クエリの最適化 結合を簡素化する – マルチ結合クエリをマテリアライズドビューまたはステージドクエリに分割します。マテリアライズドビューの実装については、 PostgreSQL のドキュメント を参照してください。 小さな読み取りをバッチ処理にする – 小さな検索 (例えば、 IN (...) 句) を組み合わせてロック頻度を減らします。 PostgreSQL のチューニング max_locks_per_transaction を調整する – パーティション化が避けられない場合 (メモリを監視)、および余分なロックが共有メモリロックハッシュテーブルに移動される場合は増やします (例えば、256 から 512 へ)。 高速パスの使用状況を監視する – pg_locks を追跡してスロットの使い果たしを特定します。 クリーンアップ 本投稿のソリューションを実装することに関連した将来の料金が発生しないようにするには、作成したリソースを削除してください。 実験で作成したテストスキーマとテーブルを削除します テスト用に専用の Aurora PostgreSQL クラスターを作成した場合は、それを削除します 不要になった関連スナップショットを削除します 結論 PostgreSQL の読み取り負荷の多いワークロードにおける LWLock の競合は、高速パスロッキングの制限を超えることから生じます。これは、パーティションプルーニングの未実装、冗長なインデックス、および複雑な結合によって引き起こされます。本投稿の実験では、以下のことが実証されました。 パーティションプルーニングはロックのオーバーヘッドを削減し、ロックを高速パススロットに限定することで、34 パーセントのパフォーマンス向上 (46,000 tps から 59,000 tps へ) をもたらしました 使用されていない各インデックスはロック負荷を増加させ、空のテーブルでも低速パスへのフォールバックを強制します マルチ結合クエリは競合を増幅し、テストされたシナリオでは 60 パーセントのロックが低速パスに溢れました パーティションを意識したクエリの優先、厳格なインデックスの管理、および結合の簡素化によって、高速パスの効率を維持し、Amazon Aurora PostgreSQL とAmazon RDS for PostgreSQL で線形な読み取りスケーラビリティを提供できます。データベースが成長するにつれ、これらの最適化はロックのボトルネックなしで AWS の弾力性を活用するための基礎となります。 Aurora でのパフォーマンスチューニングとスケーラブルな PostgreSQL ワークロードの設計についての詳細は、「 Aurora PostgreSQL チューニングの基本概念 」を参照してください。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

本記事は米国時間 8 月 7 日に公開された「 Understanding Kiro’s Pricing: Specs, Vibes, and Usage Tracking 」を翻訳したものです。Kiro の最新情報は、 https://kiro.dev/&nbsp; をご覧ください。 先週 Kiro の新しい価格設定階層 を発表して以来、提案された価格モデルについて多くの質問をいただきました。主要な 3 つの質問が浮かび上がりました。 「Spec リクエスト」と「Vibe リクエスト」の違いは何ですか？ ユーザーはより明確な定義と例を求めています。 使用量をどのようにトラッキングできますか？ 現在のエディターには使用量トラッキングがないため、私たちのプランがニーズに合うかどうかユーザーが分からない状況です。 階層制限を超えた場合はどうなりますか？ Pro+（$40）を使用していて、より多くの容量が必要な場合、Power（$200）にジャンプする必要がありますか？ このブログ記事では、これら 3 つの質問すべてに答え、皆さんが求めていた追加の明確性を提供します。 「Specリクエスト」と「Vibeリクエスト」の違いは何ですか？ 多くのユーザーから、なぜ Spec と Vibe リクエストを分けているのか、そしてこれらのリクエストが使用量の観点で正確に何を意味するのかという質問をいただきました。私たちが Spec と Vibe モデルを選んだのは、Kiro の実際の使用パターンを反映し、コストを予測可能な方法で理解できるようにするためです。これらのリクエストが何なのかを詳しく見てみましょう。 Spec リクエスト は、Kiro の構造化された開発ワークフロー内でタスクを実行する際のものです。動作の仕組みは次の通りです。まず Vibe リクエストを使用して要件と設計ドキュメントを作成します。それらが生成された後、Kiro はプロジェクトの構築を開始するためのタスクリストを提示します。これらのタスクの 1 つ 1 つが大まかに 1 つの Spec リクエストに相当しますが、複雑さによって変動することがあります。 平均的な複雑さの Spec タスクを想定した場合のシナリオをいくつか示します。 「Start task」をクリックしたり「タスク 1 を実行」と言ったりすると 1 つの Spec リクエストになります。 複数のタスクを同時に実行する場合（例：「タスク1-3を実行」）、実行される各タスクが 1 つの Spec リクエストになります。 サブタスクの実行（タスク 2 にサブタスク 2.1 と 2.2 がある場合＝ 2 つの Spec リクエスト）は 2 つの Spec リクエストになります。 Vibe リクエスト は、Spec タスクの実行を含まない Kiro でのすべてのエージェント操作をカバーします。Vibe リクエストは、Kiro との 1 回のチャット相互作用を表します。通常は 1 つのユーザープロンプトとそれに対応する応答です（ただし、プロンプトの複雑さによって増加する可能性があります）。私たちはリクエストのサイズを調整して、1 つの Vibe リクエストが通常あなたからの 1 つのメッセージまたはプロンプトに等しく、1 つの Spec リクエストが 1 つのタスクの実行に等しくなるようにしました。 平均的な複雑さの Vibe リクエストを想定した場合のシナリオをいくつか示します。 Kiro で「このコードを説明して」のようにチャットすることは 1 つの Vibe リクエストです。 Spec やステアリングドキュメントの作成と改良は 1 つの Vibe リクエストになります。 エージェントフックのトリガーは 1 つの Vibe リクエストになります。 「X を行う API を作って」のような複雑な Vibe プロンプトは、完了するまでに複数の Vibe リクエストを要する可能性があります。 これら 2 つの次元を提供することで、相互作用やトークンを推定するよりも使用量をより明確に理解できます。また、Kiro の仕様 (Spec) 駆動開発アプローチを奨励するよう階層を設計しました。これにより、開発者がより高速に動作し、適切な問題を解決するための適切なコードを書くのに役立つと考えているからです。研究によると、開発段階で問題に対処することは、ソフトウェア開発ライフサイクルの計画段階で解決するよりも 5 〜 7 倍コストが高くなることが示されています。この原則は AI エージェントでも当てはまります。計画段階で Kiro と要件と設計について時間をかけて話し合うとき、1 つの Spec リクエストで、実装中に複数の Vibe リクエストが必要になるであろうことを達成できることが多いのです。 Kiro の使用量をどのようにトラッキングしますか？ フィードバックの 2 つ目の領域は、有料プランにコミットする前の詳細な使用量トラッキングと透明性の要求でした。今月後半に価格設定が開始される際、すべてのユーザーは各リクエスト後に更新される使用量ダッシュボードを利用できるようになります。 以下に示す IDE ダッシュボードを通じて、Vibe と Spec リクエストの使用量の両方を監視し、超過分を追跡し、現在の請求サイクルでの残り割り当てを確認できます。この透明性により、プラン選択について十分な情報に基づいた決定を行い、使用パターンを最適化できます。有料階層の加入者の場合、ダッシュボードは潜在的な超過料金の見積もりも提供し、コストをより適切に管理するのに役立ちます。 アカウント名、推定使用量（リセット日付付き）、プラン名、Spec/Vibe リクエスト数（プランでカバーされる合計の内訳）、超過分のトグルを示すスクリーンショット 階層制限を超えた場合はどうなりますか？ フィードバックの 3 つ目の領域は、Kiro プランで受け取るリクエスト数と、Pro+（$40）と Power（$200）階層の間のギャップに関するものでした。皆さんの中には、使用パターンとより良く合致する手頃な中間オプションへの関心を表明された方もいます。 私たちの解決策は、柔軟な超過オプションを通じてこれに対処します。Kiroの有料階層のいずれかをご利用の場合、$0.20/Specリクエストまたは$0.04/Vibeリクエストの料金で追加リクエストを支払うことを選択できます。これにより、階層間の柔軟性が提供され、より高いプランレベルにすぐにアップグレードすることなく、使用量を拡張できます。 Kiro の体験を最大限に活用する これらの回答が、Kiro から最大の価値を得る方法をより良く理解し、あなたの働き方に合った適切なオプションを見つけるのに役立つことを願っています。 近日中に、サブスクリプションの仕組みについての FAQ を詳しく説明する別のブログ記事と、コスト面から見た仕様（Spec）駆動開発のメリットを実演するビデオを公開する予定です。 Discord に参加して議論を続けましょう！

8 月 6 日、 AWS re:Invent 中にプレビューした 新しい Amazon Bedrock のガードレール ポリシーである自動推論チェックの一般提供が開始されたことをお知らせします。自動推論チェックは、 基盤モデル (FM) によって生成されたコンテンツの正確性をドメインの知識に照らして検証するのに役立ちます。これは、AI のハルシネーションを理由とする事実誤認を防ぐのに役立ちます。このポリシーは、数学的ロジックと形式検証の手法を用いて正確性を検証し、AI の応答の正確性をチェックするための明確なルールとパラメータを提供します。 このアプローチは、結果に確率を割り当てることで不確実性に対処する確率的推論手法とは根本的に異なります。実際、自動推論チェックは最大 99% の検証精度を実現し、AI のハルシネーションの検出において証明可能な保証を提供すると同時に、モデルの出力について複数の解釈が可能である場合の曖昧性の検出にも役立ちます。 一般提供の開始に伴い、次の新特徴量をご利用いただけます: 1 回のビルドにおける、最大 80,000 トークンの大規模ドキュメントのサポート – 膨大なドキュメントを処理します。これは、最大 100 ページ分のコンテンツに相当します 簡素化されたポリシー検証 – 検証テストを保存して繰り返し実行します。これにより、時間が経過する中でポリシーを維持および検証することがより容易になります シナリオの自動生成 – 定義からテストシナリオを自動的に作成することで、カバレッジをより包括的なものとしながら、時間と労力を削減できます 強化されたポリシーフィードバック – ポリシーの変更に関して自然言語での提案を提供することで、ポリシーの改善を簡素化します カスタマイズ可能な検証設定 – 特定のニーズに合わせて信頼スコアのしきい値を調整することで、検証の厳密さをより細かく制御できます これが実際にどのように機能するのかを見てみましょう。 Amazon Bedrock のガードレールでの自動推論チェックの作成 自動推論チェックを使用するには、まずナレッジドメインのルールを自動推論ポリシーにエンコーディングしてから、そのポリシーを使用して生成されたコンテンツを検証します。このシナリオでは、誰が住宅ローンの利用資格を得ることができるかを評価する AI アシスタントを保護するための住宅ローン承認ポリシーを作成します。AI システムの予測が、住宅ローンの承認用に確立されたルールとガイドラインから逸脱しないことが重要です。これらのルールとガイドラインは、自然言語で記述されたポリシードキュメントに含まれています。 Amazon Bedrock コンソール で、ナビゲーションペインから [自動推論] を選択してポリシーを作成します。 ポリシーの名前と説明を入力し、ポリシードキュメントの PDF をアップロードします。名前と説明は単なるメタデータであり、自動推論ポリシーの構築には役立ちません。ソースコンテンツの説明を入力して、それを形式ロジックにどのように変換すべきかについてのコンテキストを追加します。例えば、AI アシスタントからのサンプル Q&amp;A を含め、アプリケーションでポリシーをどのように使用することを計画しているのかを説明します。 ポリシーの準備ができたら、概要ページに移動し、ポリシーの詳細と、テストおよび定義の概要を表示します。ドロップダウンから [定義] を選択して、自動推論ポリシーを確認します。このポリシーは、自然言語ポリシーを形式ロジックに変換するために作成されたルール、変数、および型で構成されています。 [ルール] は、ポリシー内の変数がどのように関連し、生成されたコンテンツを評価する際にどのように使用されるのかを記述します。例えば、この場合においては、適用するしきい値と、いくつかの決定が行われる方法です。追跡可能性を確保するために、各ルールには一意の ID が付与されます。 [変数] は、元の自然言語ドキュメントで使用されている主要な概念を表します。各変数は、1 つ以上のルールに関係しています。変数を使用すると、複雑な構造を理解しやすくなります。このシナリオでは、一部のルールで頭金やクレジットスコアを確認する必要があります。 カスタム [型] は、ブール値と数値のいずれでもない変数のために作成されます。例えば、限られた数の値しか取れない変数のために作成されます。この場合、ポリシーには保険付き住宅ローンと従来型住宅ローンの 2 種類の住宅ローンが含まれています。 これで、テストを通じて、初期の自動推論ポリシーの質を評価できます。ドロップダウンから [テスト] を選択します。ここで、入力 (任意) と出力 (顧客と AI アシスタントのやり取りにおける質問とその考えられる回答など) で構成されるテストを手動で入力できます。その後、自動推論チェックから期待される結果を設定します。期待される結果は、有効 (回答が正しい)、無効 (回答が正しくない)、または前提次第で成立する (具体的な前提によって回答が真にも偽にもなる) のいずれかです。また、クエリ/コンテンツのペアを自然言語からロジックに変換するための信頼度しきい値を割り当てることもできます。 テストを手動で入力する前に、定義からシナリオを自動生成するオプションを使用します。これはポリシーを検証するための最も簡単な方法であり、(ロジックのエキスパートでない限り) ポリシー作成後の最初のステップにすべきです。 生成されたシナリオごとに、それが起こり得る (前提次第で成立する) か、起こり得ないか (無効) を示す、期待される検証を提供します。起こり得ない場合は、定義を更新するために使用できる注釈を追加できます。生成されたシナリオをより深く理解するために、 SMT-LIB 構文を使用してテストの形式的なロジック表現を示すことができます。 シナリオ生成オプションを使用した後、いくつかのテストを手動で入力します。これらのテストでは、異なる期待される結果を設定します。ポリシーに従っているため有効なもの、ポリシーに違反しているため無効なもの、特定の前提に依拠しているため前提次第で成立するものなどがあります。 その後、 [すべてのテストを検証] を選択して結果を確認します。ここでは、すべてのテストに合格しました。これで、ポリシーを更新する際に、これらのテストを使用して、変更によってエラーが発生していないことを検証できます。 各テストについて、検出結果を確認できます。テストに合格しなかった場合は、テストの失敗を引き起こし、期待される結果に反する矛盾を生み出したルールを確認できます。この情報を使用して、注釈を追加すべきか、ポリシーを改善すべきか、またはテストを修正すべきかを判断できます。 テストに満足したので、新しい Amazon Bedrock ガードレールを作成 (または既存のガードレールを更新) して、最大 2 つの自動推論ポリシーを使用して AI アシスタントの応答の有効性を確認できます。ガードレールによって提供される 6 つのポリシーはすべてモジュール式で、併用することも、個別に使用することもできます。例えば、自動推論チェックは、コンテンツフィルタリングやコンテキストグラウンディングチェックなどの他のセーフガードと併用できます。ガードレールは、 ApplyGuardrail API を介して、Amazon Bedrock が提供するモデル、または任意のサードパーティーのモデル (Open AI や Google Gemini など) に適用できます。また、 Strands Agents などのエージェントフレームワークでガードレールを使用する こともできます。これには、 Amazon Bedrock AgentCore を使用してデプロイされたエージェント が含まれます。 ポリシーの設定方法を確認したので、自動推論チェックが実際にどのように使用されるのかを見てみましょう。 お客様の導入事例 – ユーティリティのサービス中断時の対応管理システム 停電時には、一分一秒が重要です。そのため、ユーティリティ企業はサービス中断時の対応管理システムを改善するために AI ソリューションを活用しています。当社は、このスペースにおいて、 PwC とともにソリューションを開発しました。&nbsp;自動推論チェックを使用することで、ユーティリティ企業は、次を通じてオペレーションを効率化できます: 自動プロトコル生成 – 規制要件を満たす標準化された手順を作成します 計画のリアルタイム検証 – 対応計画が確立されたポリシーに準拠しているようにします 構造化されたワークフローの作成 – 定義された対応目標に基づき、重大度ベースのワークフローを開発します このソリューションの中核では、インテリジェントなポリシー管理と、最適化された対応プロトコルを組み合わせています。自動推論チェックは、AI によって生成された応答を評価するために使用されます。応答が無効であるか、または前提次第で成立すると判断された場合、回答を書き換えたり、強化したりするために、自動推論チェックの結果が使用されます。 このアプローチは、AI が従来のユーティリティのオペレーションをどのように変革し、効率性、信頼性、顧客ニーズへの対応力を高めることができるのかを示しています。数学的な精度と実用的な要件を組み合わせることで、このソリューションは、ユーティリティ分野におけるサービス中断時の対応管理における新たな基準を確立します。その結果、対応時間の短縮、精度の改善、ユーティリティと顧客の双方にとってのより良い成果が実現されます。 PwC の Global and US Commercial Technology and Innovation Officer である Matt Wood 氏は次のように述べています: 「PwC では、クライアントが自信をもって AI のパイロットから本番に移行するのをサポートしています。特に、一歩間違えればコストが金銭的な損失では済まない、規制の厳しい業界においてはなおさらです。自動推論チェックでの AWS とのコラボレーションは、責任ある AI における画期的な進歩です。数学的に評価された安全対策が、Amazon Bedrock のガードレールに直接組み込まれるようになったのです。弊社は AWS のリリースコラボレーターとして、信頼が単なる特徴量ではなく必須要件となる、製薬、ユーティリティ、クラウドコンプライアンスなどの分野において、このイノベーションを実現できることを誇りに思います」 知っておくべきこと Amazon Bedrock のガードレール の自動推論チェックは、本日より、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト、アイルランド、パリ) の AWS リージョン で一般提供が開始されました。 自動推論チェックでは、処理したテキストの量に基づいて料金をお支払いいただきます。詳細については、「 Amazon Bedrock の料金 」をご覧ください。 詳細を確認し、セキュアかつ安全な AI アプリケーションを構築するには、 技術ドキュメント と GitHub コードサンプル をご覧ください。 Amazon Bedrock コンソールに直接アクセスするには、こちらのリンク をクリックしてください。 このプレイリストの動画 には、自動推論チェックの概要、詳細なプレゼンテーション、ならびにポリシーの作成、テスト、および改良に関する実践的なチュートリアルが含まれています。これはプレイリストの 2 番目の動画で、私の同僚の Wale がこの機能についてわかりやすくご紹介しています。 原文は こちら です。 – Danilo

AWS は、業界で最も先進的な 基盤モデル (FM) の提供に努めており、業界をリードする AI イノベーターによる画期的なモデルをより幅広く採用できるように注力し続けています。これにより、常に最新の進歩を活用してビジネスの成長を促進することができます。 8 月 5 日、 Amazon Bedrock と Amazon SageMaker JumpStart で 2 つの新しい オープンウェイトの OpenAI モデル が利用可能になったことを発表できることを嬉しく思います。OpenAI gpt-oss-120b および gpt-oss-20b モデルは、テキスト生成と推論タスク向けに設計されており、開発者や組織がインフラストラクチャとデータを完全に制御して AI アプリケーションを構築するための新しいオプションを提供します。 オープンウェイトモデルは、コーディング、科学的分析、数学的問題解決に優れており、主要な代替モデルと同等のパフォーマンスを発揮します。どちらのモデルも 128K のコンテキストウィンドウをサポートし、特定のユースケース要件に合わせて調整可能な推論レベル (低/中/高) を提供します。モデルは外部ツールをサポートして機能を強化でき、たとえば Strands Agents のようなフレームワークを使用して、エージェントワークフローで利用することが可能です。 AWS では、Amazon Bedrock と Amazon SageMaker JumpStart を利用することで、OpenAI のオープンウェイトモデルを含む主要な AI 企業の数百もの FM にアクセスして、自由にイノベーションを起こすことができます。モデルの豊富なラインナップにより、いつでも最適なモデルの AI ワークロードを選ぶことができます。 Amazon Bedrock を利用すると、コードを書き換えることなく、さまざまなモデルを試したり、機能を組み合わせたり、プロバイダーを切り替えたりできます。これにより、 モデルの選択 を戦略的な利点に変え、新しいイノベーションの登場に合わせて AI 戦略を継続的にアップデートすることができます。提供開始時から、新しいモデルは OpenAI と互換性のあるエンドポイントを介して Bedrock で利用可能です。OpenAI SDK をこのエンドポイントに接続するか、Bedrock InvokeModel や Converse API を使用して利用できます。 SageMaker JumpStart を使用すると、ユースケースに合わせてモデルを迅速に評価、比較、カスタマイズできます。その後、SageMaker AI コンソールまたは SageMaker Python SDK を使用して、元のモデルまたはカスタマイズされたモデルを本番環境にデプロイできます。 実際にどのように機能するか見てみましょう。 Amazon Bedrock における OpenAI のオープンウェイトモデル入門 Amazon Bedrock コンソール では、ナビゲーションペインの [ 設定と学習 ] セクションから [ モデルアクセス ] を選択します。次に、このページに表示されている 2 つの OpenAI モデルに移動し、アクセスをリクエストします。 アクセスできるようになったので、 チャット/テスト のプレイグラウンドを使用してモデルのテストと評価を行っています。カテゴリとして OpenAI を選択し、次に gpt-oss-120b モデルを選択します。 このモデルを使用して、次のサンプルプロンプトを実行します。 ある家族が来年の休暇のために 5,000 USD を貯金します。年間 2% の利息が付く普通預金口座、または年間 4% の利息で休暇まで預金を引き出すことができない定期預金口座に預金することができます。その年の急な出費として 1,000 USD を確保しておく場合、休暇用の資金を最大限に活用するためには、2 つのオプションの間で資金をどのように分配すべきでしょうか。 このプロンプトは、結果の生成に使用された一連の考え方を含む出力を生成します。 モデルを OpenAI SDK で使用するには、API エンドポイント (ベース URL) を設定し、認証に Amazon Bedrock API キー を使用します。たとえば、米国西部 (オレゴン) の AWS リージョンのエンドポイント ( us-west-2 ) と Amazon Bedrock API キーを使用するように次の環境変数を設定しました。 export OPENAI_API_KEY="&lt;my-bedrock-api-key&gt;" export OPENAI_BASE_URL="https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1" 次に、OpenAI Python SDK を使用してモデルを呼び出します。 client = OpenAI() response = client.chat.completion.create( messages=[{ "role": "user", "content": "Hello, how are you?" }], model="openai.gpt-oss-120b-1:0", stream=True ) for item in response: print(item) AI エージェントを構築するには、Amazon Bedrock API または OpenAI API をサポートする任意のフレームワークを選択できます。たとえば、Amazon Bedrock API を使用する Strands Agents の開始コードは次のとおりです。 from strands import Agent from strands.models import BedrockModel from strands_tools import calculator model = BedrockModel( model_id="openai.gpt-oss-120b-1:0" ) agent = Agent( model=model, tools=[calculator] ) agent("Tell me the square root of 42 ^ 3") コード ( app.py ファイル) を保存し、依存関係をインストールして、エージェントをローカルで実行します。 pip install strands-agents strands-agents-tools python app.py エージェントに問題がなければ、 Amazon Bedrock AgentCore が提供する機能 (フルマネージド型のサーバーレスランタイム、メモリおよび ID 管理など) を使用して本番環境にデプロイできます。 Amazon SageMaker JumpStart における OpenAI のオープンウェイトモデル入門 Amazon SageMaker AI コンソール では、 SageMaker Studio で OpenAI のオープンウェイトモデルを使用できます。初めてこれを行う際には、SageMaker ドメインを設定する必要があります。よりシンプルなシングルユーザー向けまたは組織用に設定するオプションがあります。これらのテストでは、シングルユーザー設定を使用します。 SageMaker JumpStart モデルビューでは、 gpt-oss-120b モデルまたは gpt-oss-20b モデルの詳細な説明にアクセスできます。 gpt-oss-20b モデル を選択し、そのモデルをデプロイします。次のステップでは、インスタンスタイプと初期インスタンス数を選択します。数分後、デプロイによってエンドポイントが作成されることで、SageMaker Studio での呼び出しや、任意の AWS SDK の使用が可能になります。 詳細については、AWS AI ブログの OpenAI の GPT OSS モデルが SageMaker JumpStart で利用可能に をご覧ください。 知っておくべきこと 新しい OpenAI のオープンウェイトモデル は米国西部 (オレゴン) AWS リージョン の Amazon Bedrock で利用可能になりました。一方、 Amazon SageMaker JumpStart は、これらのモデルを米国東部 (オハイオ、バージニア北部) とアジアパシフィック (ムンバイ、東京) でサポートしています。 各モデルには、思考過程をすべて出力する機能が備わっており、モデルの推論プロセスを詳細に把握できます。この透明性は、解釈可能性や検証の水準が高いアプリケーションにおいて、特に役立ちます。&nbsp;これらのモデルでは、特定のニーズに合わせて自由に変更、調整、カスタマイズできます。この柔軟性により、独自のユースケースに合わせたモデルのファインチューニング、既存のワークフローへの統合、さらにこれを基に構築した業界やアプリケーションに合わせた新しい特殊なモデルの作成が可能になります。 これらのモデルには、包括的な評価プロセスと安全対策が施されており、セキュリティと安全性が核となっています。モデルは標準の GPT-4トークナイザーとの互換性があります。 どちらのモデルも、Amazon Bedrock のサーバーレスエクスペリエンスを使用する場合でも、SageMaker JumpStart の広範な 機械学習 (ML) 開発機能を使用する場合でも、お好みの環境で使用できます。モデルとサービスの使用に関連するコストについては、 Amazon Bedrock の料金表 と Amazon SageMaker AI の料金表 ページを参照してください。 詳細については、Amazon Bedrock のドキュメントにある モデルのパラメータ や チャット補完 API を参照してください。 Amazon Bedrock コンソール または Amazon SageMaker AI コンソール で AWS で OpenAI のオープンウェイトモデルを今すぐ利用開始しましょう。 – Danilo 原文は こちら です。

8 月 5 日、 Amazon Elastic VMware Service (Amazon EVS) の一般提供開始の開始を発表します。これは、 VMware Cloud Foundation (VCF) 環境を Amazon Virtual Private Cloud (Amazon VPC) 内で直接実行できるようにする新しい AWS サービスです。Amazon EVS を利用すると、ガイド付きワークフローを使用して、わずか数時間で完全に機能する VCF 環境をデプロイできます。また、認定された Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスで VMware ワークロードを実行し、 Amazon FSx for NetApp ONTAP などの AWS サービスとシームレスに統合できます。 オンプレミスで VMware ワークロードを実行している多くの組織は、改善されたスケーラビリティ、信頼性、クラウドサービスへのアクセスから恩恵を享受するためにクラウドへの移行を望んでいますが、これらのワークロードの移行には、アプリケーションとインフラストラクチャの設定の大幅な変更が必要になることがよくあります。Amazon EVS を利用すると、お客様は、アプリケーションを再設計したり、確立されたプラクティスを変更したりすることなく、既存の VMware の専門知識とツールを引き続き使用できます。そのため、移行プロセスが簡素化されると同時に、AWS の規模、信頼性、幅広いサービスへのアクセスも提供されます。 Amazon EVS を利用すると、Amazon VPC で VMware ワークロードを直接実行できます。これにより、AWS インフラストラクチャ上にいながら、環境を完全に制御できます。オンプレミスネットワークを拡張し、IP アドレスや運用ランブックを変更することなくワークロードを移行できるため、複雑さとリスクが軽減されます。 主な機能と特徴量 Amazon EVS は、VMware ワークロードの移行と管理のエクスペリエンスを効率化するために設計された包括的な一連の機能を提供します。このサービスは、リプラットフォームやハイパーバイザーの変更を必要とせずにワークロードのシームレスな移行を可能にするため、AWS に移行しながら、既存のインフラストラクチャに対する投資を維持できます。 AWS マネジメントコンソール での直感的なガイド付きワークフローを通じて、EVS 環境を効率的にプロビジョニングおよび設定できるため、AWS へのワークロード移行の複雑さが大幅に軽減されます。 Amazon EVS を利用すると、AWS 上で実行される完全に機能する VCF 環境を数時間でデプロイできます。このプロセスにより、従来のデプロイ中に頻繁に発生する多くの手動ステップと潜在的な設定エラーが排除されます。さらに、Amazon EVS を利用すると、AWS 上の仮想化スタックを最適化できます。VCF 環境は VPC 内で実行されるため、環境と関連付けられた管理アプライアンスに対する完全なルートアクセスが付与されます。また、 Amazon FSx for NetApp ONTAP や Pure Cloud Block Store などの外部ストレージ、 Veeam Backup and Replication などのバックアップソリューションなど、サードパーティーソリューションを統合することも可能です。 このサービスでは、自己管理することも、AWS パートナーと連携して環境を構築、管理、運用することもできます。これにより、全体的な目標に合わせてアプローチを柔軟に調整できます。 新しい VCF 環境のセットアップ 組織は、新しい VCF 環境を作成する前に必要なすべての前提条件が確実に満たされているようにすることで、セットアッププロセスを合理化できます。これらの前提条件には、アクティブな AWS アカウントがあること、適切な AWS Identity and Access Management (IAM) 許可が設定されていること、十分な CIDR スペースと 2 つの Route Server エンドポイント (各エンドポイントに独自のピアがある必要があります) を備えた Amazon VPC がセットアップされていることが含まれます。さらに、お客様は、VMware Cloud Foundation ライセンスキーを用意し、i4i.metal インスタンス専用の Amazon EC2 キャパシティ予約を確保するとともに、VLAN サブネット情報の計画を準備する必要があります。 円滑なデプロイプロセスを実現するのに役立つよう、EVS ホームページからアクセスできる 開始方法ハブ を提供しているほか、 ドキュメント では包括的なガイドをご覧いただけます。これらの準備ステップに従うことで、セットアップの遅延を回避し、環境を正常に構築できます。 Amazon EVS を利用して新しい VCF 環境をセットアップするプロセスを順に見ていきましょう。 VCF ライセンスを購入する際に Broadcom によって割り当てられたサイト ID と、ライセンスキーを提供する必要があります。初期デプロイを成功させるには、少なくとも 256 コアをカバーするのに十分なライセンスを有していることを確認する必要があります。これは、少なくとも 4 つの i4i.metal インスタンス (各インスタンスは 64 個の物理コアを提供します) を意味します。 このライセンス要件は、最適なパフォーマンスを維持し、必要なインフラストラクチャ仕様を環境が満たしているようにするのに役立ちます。これらの要件を事前に確認することで、デプロイの遅延を回避し、円滑なセットアッププロセスを実現できます。 必要な詳細をすべて入力すると、ホストの詳細を指定するように求められます。これらは、VCF 環境がデプロイされる基盤となる Amazon EC2 インスタンスです。 各ホストインスタンスの詳細を入力したら、ネットワーキングと管理アプライアンスの DNS の詳細を設定する必要があります。Amazon EVS で新しい VCF 環境を作成する方法の詳細については、 こちらのドキュメント をご覧ください。 VCF 環境を作成すると、AWS コンソールを通じてすべてのホストと設定の詳細を確認できます。 知っておくべき追加情報 Amazon EVS は現在、VCF バージョン 5.2.1 をサポートしており、i4i.metal インスタンスで実行されます。今後のリリースでは、デプロイのためにより高い柔軟性が提供されるよう、VCF バージョン、ライセンスオプション、およびインスタンスタイプのサポートが拡張される予定です。 Amazon EVS は柔軟なストレージオプションを提供します。Amazon EVS のローカルインスタンスストレージは、VMware の vSAN ソリューションを利用しており、複数の ESXi ホストにまたがるローカルディスクを単一の分散データストアにプールします。ストレージをスケールするために、外部の Network File System (NFS) または iSCSI ベースのストレージソリューションを活用できます。例えば、Amazon FSx for NetApp ONTAP は、NFS データストアまたは iSCSI 経由の共有ブロックストレージとして使用するのに特によく適しています。 さらに、Amazon EVS を利用すると、オンプレミス環境を AWS に簡単に接続できます。Direct Connect 接続またはトランジットゲートウェイを終端とする VPN を使用して、オンプレミスの vSphere 環境から Amazon EVS に接続できます。また、Amazon EVS は、VLAN サブネットから VM への基盤となる接続を管理します。 AWS は、Amazon EVS によってデプロイされるすべての AWS サービスについて包括的なサポートを提供し、直接的なカスタマーサポートを提供するとともに、高度なサポートニーズについては Broadcom と連携します。お客様は、サービスを実行しているアカウントで AWS ビジネスサポート を維持する必要があります。 利用可能なリージョンと料金 Amazon EVS は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (アイルランド)、アジアパシフィック (東京) の AWS リージョン で一般提供されています。近日中に他のリージョンでもご利用いただけるようになる予定です。料金は、使用した Amazon EC2 インスタンスと AWS リソースに基づいて算出され、最低料金や初期費用はありません。 詳細については、 Amazon EVS の製品ページ にアクセスしてください。 原文は こちら です。

このブログは 2025 年 7 月 15 日に Channy Yun によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 本日、 Amazon S3 Vectors のプレビュー版を発表します。これは、ベクトルのアップロード、保存、クエリの総コストを最大 90 % 削減できる、耐久性に優れたベクトルストレージソリューションです。Amazon S3 Vectors は、大規模なベクトルデータセットの保存をネイティブにサポートし、1 秒未満のクエリパフォーマンスを実現する初めてのクラウドオブジェクトストアです。これにより、企業が AI 対応データを大規模に低コストで保存できるようになります。 ベクトル検索は、 生成 AI アプリケーションで使用されている新しい手法で、距離または類似度メトリックを使用してベクトル表現を比較することにより、特定のデータに類似したデータポイントを検索します。ベクトルは 埋め込みモデル から作成された非構造化データを数値で表現したものです。ドキュメント内のフィールドの埋め込みモデルを使用してベクトルを生成し、ベクトルを S3 Vectors に保存してセマンティック検索を行います。 S3 Vectors では、ベクトルバケットが導入されました。ベクトルバケットは、インフラストラクチャをプロビジョニングせずにベクトルデータを保存、アクセス、クエリするための専用の API セットを備えた新しいバケットタイプです。S3 ベクトルバケットを作成すると、ベクトルデータをベクトルインデックス内に整理し、データセットに対して類似検索クエリを簡単に実行できるようにします。各ベクトルバケットには最大 10,000 個のベクトルインデックスを含めることができ、各ベクトルインデックスには数千万個のベクトルを格納できます。 ベクトルインデックスを作成した後、ベクトルデータをインデックスに追加するときに、メタデータをキーと値のペアとして各ベクトルに添付して、日付、カテゴリ、ユーザー設定などの一連の条件に基づいて今後のクエリをフィルタリングすることもできます。時間の経過とともにベクトルの書き込み、更新、削除を行うと、S3 Vectors は、データセットが拡大したり進化したりしても、ベクトルストレージのコストパフォーマンスが可能な限りベストになるように、ベクトルデータを自動的に最適化します。 S3 Vectorsは、 Amazon SageMaker Unified Studio を含む Amazon Bedrock Knowledge Bases ともネイティブに統合されており、費用対効果の高い Retrieval-Augmented Generation (RAG) アプリケーションを構築できます。 Amazon OpenSearch Service との統合により、クエリ頻度の低いベクトルを S3 Vectors に保存することでストレージコストを削減でき、需要が高まったときにそれらを OpenSearch にすばやく移動したり、リアルタイムで低レイテンシーの検索操作をサポートすることができます。 S3 Vectors を使用すると、画像、動画、ドキュメント、音声ファイルなどの大量の非構造化データを表すベクトル埋め込みを経済的に保存できるようになり、セマンティック検索、類似検索、RAG、ビルドエージェントメモリなどのスケーラブルな生成 AI アプリケーションが可能になります。また、ベクトルデータベースの管理に伴う複雑さやコストをかけずに、パーソナライズされた推奨事項、自動コンテンツ分析、インテリジェントな文書処理など、さまざまな業界のユースケースをサポートするアプリケーションを構築できます。 S3 Vectors の動作 ベクトルバケットを作成するには、 Amazon S3 コンソール の左側のナビゲーションペインで Vector buckets を選択し、 Create vector bucket を選択します。 ベクトルバケット名を入力し、暗号化タイプを選択します。暗号化タイプを指定しない場合、Amazon S3 は新しいベクトルの暗号化の基本レベルとして Amazon S3 管理キー (SSE-S3) を使用してサーバー側の暗号化を適用します。 AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用してサーバー側の暗号化を選択することもできます。ベクトルバケットの管理の詳細については、Amazon S3 ユーザーガイドの S3 ベクトルバケット をご覧ください。 これで、ベクトルインデックスを作成して、作成したベクトルバケット内でベクトルデータを保存およびクエリできます。 ベクトルインデックス名と、インデックスに挿入するベクトルの次元を入力します。このインデックスに追加されるすべてのベクトルは、完全に同じ数の値を持つ必要があります。 Distance metric では、 Cosine または Euclidean を選択できます。ベクトル埋め込みを作成する場合、より正確な結果を得るには、埋め込みモデルの推奨された距離メトリックを選択してください。 Create vector index を選択すると、ベクトルの挿入、一覧表示、クエリを行うことができます。 ベクトル埋め込みをベクトルインデックスに挿入するには、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDKs 、または Amazon S3 REST API を使用できます。非構造化データ用のベクトル埋め込みを生成するには、Amazon Bedrock が提供する埋め込みモデルを使用できます。 最新の AWS Python SDK を使用している場合は、次のコード例を使用して Amazon Bedrock を使用してテキストのベクトル埋め込みを生成できます。 # Generate and print an embedding with Amazon Titan Text Embeddings V2. import boto3 import json # Create a Bedrock Runtime client in the AWS Region of your choice. bedrock = boto3 . client ( "bedrock-runtime" , region_name = "us-west-2" ) # The text strings to convert to embeddings . texts = [ "Star Wars: A farm boy joins rebels to fight an evil empire in space" , "Jurassic Park: Scientists create dinosaurs in a theme park that goes wrong" , "Finding Nemo: A father fish searches the ocean to find his lost son" ] embeddings = [ ] #Generate vector embeddings for the input texts for text in texts : body = json . dumps ( { "inputText" : text } ) # Call Bedrock's embedding API response = bedrock . invoke_model ( modelId = 'amazon.titan-embed-text-v2:0' , # Titan embedding model body = body ) # Parse response response_body = json . loads ( response [ 'body' ] . read ( ) ) embedding = response_body [ 'embedding' ] embeddings . append ( embedding ) Python これで、ベクトル埋め込みをベクトルインデックスに挿入し、クエリー埋め込みを使用してベクトルインデックスのベクトルをクエリできるようになりました。 # Create S3Vectors client s3vectors = boto3 . client ( 's3vectors' , region_name = 'us-west-2' ) # Insert vector embedding s3vectors . put_vectors ( vectorBucketName = "channy-vector-bucket" , indexName = "channy-vector-index" , vectors = [ { "key" : "v1" , "data" : { "float32" : embeddings [ 0 ] } , "metadata" : { "id" : "key1" , "source_text" : texts [ 0 ] , "genre" : "scifi" } } , { "key" : "v2" , "data" : { "float32" : embeddings [ 1 ] } , "metadata" : { "id" : "key2" , "source_text" : texts [ 1 ] , "genre" : "scifi" } } , { "key" : "v3" , "data" : { "float32" : embeddings [ 2 ] } , "metadata" : { "id" : "key3" , "source_text" : texts [ 2 ] , "genre" : "family" } } ] , ) #Create an embedding for your query input text # The text to convert to an embedding. input_text = "List the movies about adventures in space" # Create the JSON request for the model. request = json . dumps ( { "inputText" : input_text } ) # Invoke the model with the request and the model ID, e.g., Titan Text Embeddings V2. response = bedrock . invoke_model ( modelId = "amazon.titan-embed-text-v2:0" , body = request ) # Decode the model's native response body. model_response = json . loads ( response [ "body" ] . read ( ) ) # Extract and print the generated embedding and the input text token count. embedding = model_response [ "embedding" ] # Performa a similarity query. You can also optionally use a filter in your query query = s3vectors . query_vectors ( vectorBucketName = "channy-vector-bucket" , indexName = "channy-vector-index" , queryVector = { "float32" : embedding } , topK = 3 , filter = { "genre" : "scifi" } , returnDistance = True , returnMetadata = True ) results = query [ "vectors" ] print ( results ) Python ベクトルインデックスへのベクトルの挿入、ベクトルの一覧表示、クエリ、削除の詳細については、Amazon S3 ユーザーガイドの S3 ベクトルバケット と S3 ベクトルインデックス をご覧ください。さらに、S3 Vectors embed コマンドラインインターフェイス (CLI) を使用すると、Amazon Bedrock を使用してデータのベクトル埋め込みを作成し、1 つのコマンドで S3 ベクトルインデックスに保存してクエリすることができます。詳細については、 S3 Vectors Embed CLI GitHub リポジトリ を参照してください。 S3 Vectors を他の AWS サービスと統合 S3 Vectors は、Amazon Bedrock、Amazon SageMaker、Amazon OpenSearch Service などの他の AWS サービスと統合することで、ベクトル処理機能を強化し、AI ワークロード向けの包括的なソリューションを提供します。 S3 Vectors を使用して Amazon Bedrock ナレッジベースを作成 Amazon Bedrock ナレッジベースで S3 Vectors を使用すると、RAG アプリケーションのベクトルストレージのコストを簡素化および削減できます。 Amazon Bedrock コンソール でナレッジベースを作成する場合、ベクトルストアのオプションとして S3 ベクトルバケットを選択できます。 Step 3 では、 Vector store creation method を選択して S3 ベクトルバケットとベクトルインデックスを作成するか、以前に作成した既存の S3 ベクトルバケットとベクトルインデックスを選択できます。 詳細な手順については、Amazon Bedrock ユーザーガイドの Create a knowledge base by connecting to a data source in Amazon Bedrock Knowledge Bases を参照してください。 Amazon SageMaker Unified Studio を使用する Amazon Bedrock を使用して生成 AI アプリケーションを構築すると、Amazon SageMaker Unified Studio で S3 Vectors を使用してナレッジベースを作成および管理できます。SageMaker Unified Studio は次世代の Amazon SageMaker で利用でき、Amazon Bedrock ナレッジベースを使用する生成 AI アプリケーションの構築やテキスト送信など、データと AI の統合開発環境を提供します。 生成 AI アプリケーションを構築する時に、Amazon Bedrock で作成された S3 Vectors を使用してナレッジベースを選択できます。詳細については、Amazon SageMaker Unified Studio ユーザーガイドの Add a data source to your Amazon Bedrock app をご覧ください。 S3 ベクトルデータを Amazon OpenSearch サービスにエクスポートする 長期的に利用するベクトルデータを Amazon S3 にコスト効率よく保存する一方で、優先度高く利用したいベクトルを OpenSearch にエクスポートしてリアルタイムのクエリパフォーマンスを実現する階層型戦略を採用することで、コストとパフォーマンスのバランスを取ることができます。 この柔軟性により、組織は OpenSearch の高パフォーマンス (高 QPS、低遅延) を利用して、製品の推奨や不正検出などの重要なリアルタイムアプリケーションにアクセスでき、時間的制約の少ないデータを S3 Vectors に保存できます。 ベクトルインデックスをエクスポートするには、 Advanced search export を選択し、次に Amazon S3 コンソールで Export to OpenSearch を選択します。 次に、OpenSearch ベクトルエンジンに S3 ベクトルインデックスをエクスポートするためのテンプレートを含む Amazon OpenSearch サービス統合コンソール が表示されます。事前に選択した S3 ベクトルソースとサービスアクセスロールを使用して エクスポート を選択します。 これで、新しい OpenSearch Serverless コレクションを作成し、S3 ベクトルインデックスから OpenSearch k-NN インデックスにデータを移行する手順が開始されます。 左側のナビゲーションペインで Import history を選択します。S3 ベクトルインデックスのベクトルデータを OpenSearch Serverless コレクションにコピーするために作成された新しいインポートジョブが表示されます。 ステータスが Complete に変わったら、 新しい OpenSearch Serverless コレクションに接続して 、 新しい OpenSearch knn インデックスをクエリできます 。 詳細については、Amazon OpenSearch サービス開発者ガイドの Creating and managing Amazon OpenSearch Serverless collections をご覧ください。 今すぐご利用いただけます Amazon S3 Vectors 、および Amazon Bedrock、Amazon OpenSearch Service、Amazon SageMaker との統合は、現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、ヨーロッパ (フランクフルト)、およびアジアパシフィック (シドニー) の各リージョンでプレビュー段階にあります。 今すぐ Amazon S3 コンソール で S3 Vectors を試してみて、 AWS re:Post for Amazon S3 か通常の AWS サポートの連絡先を通じてフィードバックを送ってください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの黒川が担当しました。

この記事は Resolve imperfect data with advanced rule-based fuzzy matching in AWS Entity Resolution (記事公開日 : 2025 年 7 月 30 日) を翻訳したものです。 様々な業界の企業は、顧客情報を正確に把握することで、パーソナライズされた顧客体験と最適化された広告キャンペーンの提供を目指しています。しかし、断片化され、一貫性がなく、しばしば乱雑なデータセット間でレコードを確実にマッチングすることは、困難で複雑な作業です。 従来のルールベースのマッチング技術を使用して完全一致のレコードを照合しようとする組織は、名前、メールアドレス、住所のわずかな違い (例 : Jon Smith と Jonathan Smith、または 123 Main St., Apt. 4B と 123 Main Street #4B) により、重要なつながりを見逃してしまうことがあります。このようなミスマッチは、キャンペーンのパフォーマンス低下、オーディエンスリーチの制限、広告費の無駄遣いにつながる可能性があります。 これらの課題に対応するために、企業は AWS Entity Resolution を使用して、複数のアプリケーション、チャネル、データストアにまたがる関連レコードのマッチング、リンク、情報の付加を行っています。これにより、顧客をより良く理解し、エンゲージメントを高めるためのデータ品質が向上します。AWS Entity Resolution は、ルールベースのマッチングと機械学習 (ML) ベースのマッチングを含む、複数の柔軟で設定可能なマッチング技術を提供します。 ルールベースのマッチング は、複数のフィールドにわたる厳密な条件を使用して、決定論的なロジックを定義します。例えば、メールアドレスと姓でマッチングを行うようなルールを設定することができます。この手法は高い精度と完全な透明性を提供し、事前に定義されたルールによる説明可能性が重要なユースケースで特に好まれます。 機械学習ベースのマッチング は、事前に学習させたモデルを活用し、データ内のパターンを自動的に学習して、データにノイズがある場合や一貫性がない場合、あるいは主要な識別子が不足している場合でも、適切なマッチングを特定することができます。この手法は設定の手間を軽減し、様々なタイプのデータに適応できる特徴があり、決定論的なルールでは見落としてしまう可能性のあるケースでも、より高い検出率を実現します。 本日、AWS Entity Resolution で高度なルールベースファジーマッチング機能を 発表しました 。これにより、Levenshtein Distance (レーベンシュタイン距離)、Cosine Similarity (コサイン類似度)、Soundex (サウンデックス) などのファジーマッチングアルゴリズムを使用してレコードをマッチングできるようになります。 この機能は、表記の揺れや入力ミスに対する許容性を持たせることで、特別な前処理を必要とせずに、より正確で柔軟な本人確認を可能にします。マーケターにとってこれは、マッチング率の向上、パーソナライゼーションの強化、そして効果的なクロスチャネルでのターゲティングやリターゲティング、効果測定のために必要な統合的な顧客視点の構築を実現できることを意味します。 業界のユースケース 高度なルールベースファジーマッチングは、様々な業界のお客様が直面する複雑なデータ統合の課題解決に役立ちます。具体的には以下のような例があります : 広告・マーケティング分野 : 識別子が不完全であったり、わずかなズレがある場合でも、異なるデータセット間でレコードをマッチングすることで、リーチや頻度分析の精度を向上させることができます。 小売・消費財分野 : 顧客関係管理 (CRM) データ内の誤字や異なる表記を含むレコードを紐付けることができます。 金融サービス分野 : 本人確認 (KYC) の検証、不正検知、またはマーケティング目的のために、本人確認データの解決を行うことができます。 高度なルールベースファジーマッチングの概要 AWS Entity Resolution の高度なルールベースファジーマッチングは、ルールベースと機械学習ベースのアプローチの間のギャップを埋めるものです。従来の厳密なルールベースの枠組みに確率的なマッチングを導入し、ユーザーがファジーマッチングアルゴリズム (レーベンシュタイン距離やコサイン類似度など) を使用して文字列フィールドの類似度のしきい値を設定できるようにします。これにより、ルールの説明可能性とコントロール性を保ちながら、確率的マッチングの柔軟性を実現する中間的なアプローチを提供します。 AWS Entity Resolution では、以下のファジーマッチングアルゴリズムを利用できます : レーベンシュタイン距離 : タイプミスや文字の小さな編集を検出し、名前やメールアドレス、スペルミスのあるエントリーをマッチングします (例 : john@gmail.co と jon@gmail.com の比較) 。 サウンデックス : 音声的な類似性を評価し、似た発音だが異なるスペルの名前をマッチングします (例 : Mary と Marie の比較) 。 コサイン類似度 : 単語やトークンの重なりに基づいて類似性を測定します。これは会社名や、語順が異なる、または部分的に一致するフリーテキストフィールドのマッチングに使用されます (例 : Acme Inc. と Acme Corporation の比較) 。 お客様は、ノイズを含むデータや一貫性のないデータ間でより柔軟で正確なマッチングを可能にするために、アルゴリズムを使用してカスタムの類似度のしきい値を定義できるようになりました。これは、ルールベースシステムのコントロール性と、機械学習ベースの近似マッチングの適応性を組み合わせたもので、説明可能性を損なうことなくマッチング率を向上させることができます。 お客様は、関連するファジーマッチングアルゴリズムでルール条件を設定し、必要に応じて適切なしきい値を設定することができます (図 1 参照) 。 図 1 : 高度なマッチングアルゴリズム 仕組み AWS Entity Resolution の新機能をソリューションで使用するには、まず、複数のアプリケーション、チャネル、データストアにまたがるレコードがデータレイク (Amazon Simple Storage Service ( Amazon S3 ) バケット) で利用可能な状態になっていることを確認します。 AWS Glue crawler を使用して Amazon S3 のデータの内容を自動的に判別し、 AWS Glue Data Catalog 内のメタデータテーブルを更新します。 AWS Entity Resolution は、サービス内で定義したルールを使用して、データセットを適切なマッチンググループに解決します。AWS Entity Resolution からの出力は Amazon S3 バケットで利用可能です。図 2 は、このソリューションを示すハイレベルのアーキテクチャ図です。 図 2 : ハイレベルアーキテクチャ 使用例の説明 AWS Entity Resolution のファジーマッチングルールを説明するために、テストデータセットを作成しました。このデータセットは架空の顧客情報で構成されており、CSV ファイル形式で Amazon S3 バケットにアップロードされています。 図 3 : サンプルデータセット 図 3 のデータセットには 4 つの個別のエンティティが含まれています。ただし、これらの個別エンティティには、名前、住所、電話番号フィールドが変更された複数のバリエーションも含まれています。 サンプルデータの問題を解決するために、以下の手順を実行しました : AWS Entity Resolution でサンプルデータのスキーマを解決するには、まず AWS Glue crawler を使用して AWS Glue Data Catalog テーブルを作成する必要があります。このテーブルは、入力されるクリックストリームデータを保持する Amazon S3 バケットを指します。 AWS Entity Resolution 内で スキーママッピング を定義し、サービスにデータの解釈方法を指示する必要があります。 スキーママッピング作成画面で、ソースデータを表す適切な AWS Glue データベースとテーブル を選択します。この例では、”fuzzymatchingaerdemo” を含むデータベース “fuzzymatchingdemo” を使用します。このデータベースのテーブルは、サンプルデータセットを含む Amazon S3 バケットで AWS Glue crawler を実行した際に作成されました。 図 4 : スキーママッピング – セットアップ ドロップダウンから一意の ID ( Unique ID ) を選択します (図 5 参照) 。一意の ID カラムは、データの各行を個別に参照する必要があります。これはデータベースの主キーカラムのようなものと考えてください。この場合、CSV ファイル内の uniqueid がそれに該当します。 下にスクロールし、解決に必要な 入力フィールド を選択します (図 5 参照) 。この場合、address (住所) 、first_name (名) 、last_name (姓) 、phone の各カラムが選択されています。 図 5 : スキーママッピング – 入力データフィールド セットアップ 次に、選択した入力フィールドを適切なデータタイプとマッチキーにマッピングします。入力タイプ (名前、メール、住所など) を指定することで、AWS Entity Resolution に各カラムのデータの解釈方法を指示し、必要に応じてそのカラムに適用する正規化ルールを設定できます。 マッチキー は、どのフィールドが類似しているか、そしてマッチング処理中に単一のユニットとして扱う必要があるかを決定します。 図 6 : スキーママッピング – フィールドのマッピング 「 次へ 」をクリックしてグループの作成に進みます。グループとは、単一の「名前」カラムの下にある関連する入力フィールド (名と姓など) のセットです。これにより、AWS Entity Resolution はマッチングや類似度の計算時に、個別ではなくまとめて比較することができ、より正確なマッチングが可能になります。 図 7 : スキーママッピング – グループフィールド グループの設定が完了したら、「 次へ 」をクリックして確認と作成画面に進みます。 すべての設定を確認し、「 スキーママッピングの作成 」をクリックします。これによりスキーママッピングが作成されます。 スキーママッピングが作成されたら、次はマッチングワークフローを作成します。マッチングワークフローは、ソース間でレコードをマッチングおよびリンクするために必要な入力、関連するマッチング手法、ルール、または機械学習を定義するのに役立ちます。マッチングワークフローを作成するには、左側のメニューにあるワークフローのドロップダウンから「 マッチング 」を選択し、「 マッチングワークフローの作成 」をクリックします。マッチングワークフローの詳細指定画面でワークフロー名を追加します。この例では「Fuzzymatchingdemo」としています。データ入力エリアで、前のステップで作成した適切な AWS Glue データベーステーブルとスキーママッピングを選択する必要があります (図 8 参照) 。 図 8 : マッチングワークフロー マッチング手法では、「 ルールベースマッチング 」を選択し、ファジーマッチングアルゴリズムを使用するためにルールタイプとして「 Advanced-new 」を選択します。 図 9 : マッチング手法 マッチングルールセクションでは、マッチングの目的に合わせて、ドロップダウンリストからマッチングアルゴリズムと適切なしきい値を選択し、ルールと条件を定義できます (図 10 参照) 。高度なマッチングルールビルダーでは、特定のフィールドに複数のマッチングアルゴリズムを適用することができます。「OR」条件を使用して2つの異なるアルゴリズムを組み合わせることで、マッチング解決の精度を最大化することができます。例えば、「名前」属性に対してサウンデックスとコサインの両方のアルゴリズムを適用することで、異なる種類の表記のバリエーションを捉えることができます。図 11 は、サンプルデータセットの重複を効果的に排除するために使用したルールを示しています。 図 10 : ファジーマッチング手法 セットアップ 図 11 : ファジーマッチングルール 最後のステップとして、ワークフローを作成する前に、すべての設定がマッチングの要件を正確に反映しているか確認し、「 作成して実行 」をクリックします。これによりマッチングワークフローが作成され、最初の処理が開始されます。 ジョブの完了までしばらく待つと (図 12 参照) 、ジョブメトリクスに処理された入力レコードの数と生成された一意のマッチ ID の数が表示されます。出力結果は設定された Amazon S3 バケットに書き込まれます。指定された出力用 S3 の場所に移動して出力ファイルをダウンロードし、結果を分析することができます。 図 12 : ファジーマッチングのジョブメトリクス 出力データ (図 13 参照) では、出力データの各レコードに AWS Entity Resolution が割り当てた MatchID が付与されます。マッチングレコードは、MatchRule で定義された条件を満たすデータセットから重複が排除されたエントリーを表します。MatchRule フィールドは、各マッチングレコードセットの生成に適用された具体的なルールを示しています。 図 13 : ファジーマッチングワークフローの出力 このチュートリアルで示したサンプルデータセットでは、AWS Entity Resolution のファジーマッチングワークフローは、関連するレコードをグループ化する 4 つの一意のマッチキーを生成しました。マッチングワークフローは、名前、住所、電話番号フィールドにバリエーションを含むレコードの重複を正常に排除し、4 つの個別のエンティティとして解決しました。 まとめ AWS Entity Resolution の高度なルールベースファジーマッチングは、カスタムコードを書くことなく、ファジーロジックを使用して現実世界の不完全なデータをマッチングするための柔軟性を提供します。広告、小売、金融、医療など、どの分野で働いているかに関わらず、この機能はデータに隠された関係性を見つけ出すのに役立ちます。お客様は、マッチングのためのファジーロジックに対して適切なしきい値を管理および設定することができます。 これは、ルールベースシステムのコントロール性と、機械学習ベースの近似マッチングの適応性を組み合わせたバランスの取れたマッチングアプローチです。説明可能性を損なうことなく、マッチング率を向上させることができます。 開始するには、 AWS Entity Resolution コンソール にアクセスし、高度なルールベースファジーマッチングを有効にして、今すぐインテリジェントなワークフローの構築を始めるか、 AWS の担当者 に連絡して、ビジネスの加速化に向けた支援方法についてご相談ください。 追加リソース AWS Entity Resolution Resources AWS Entity Resolution と Amazon Neptune を使用して顧客の 360 度ビューを作成 AWS Entity Resolution: Match and Link Related Records from Multiple Applications and Data Stores AWS Entity Resolution Workshops 顧客の統一ビューを構築する方法 Sid Patel Sid は、AWS 応用 AI (Applied AI) ソリューション内の顧客データ・インサイトチームのプロダクトリードです。AWS Entity Resolution や Amazon Connect Customer Profiles などのサービスを通じて、顧客アイデンティティとデータ統合に注力しています。 Archna Kulkarni Archna は、金融サービスとデータ変換技術を専門とする AWS のシニアソリューションアーキテクトです。AWS に入社する前は、フォーチュン 100 の金融サービス組織でデジタルトランスフォーメーションのエグゼクティブとして働いていました。Archna は AWS Entity Resolution、AWS Clean Rooms、Amazon Connect Customer Profiles などの AWS サービスを活用して、お客様のデータ統合と変革の取り組みを支援しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。