AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

3642

はじめに Q. 日々、テレビでながれる、国会における国会議員と大臣の議論。霞が関では多くの国家公務員が夜遅くまで働いていますが、国会での議論に先立って、どのような業務が行われているかご存知でしょうか? A. 様々ありますが、その主な業務の一つが、国会において想定される質問と、それに対する回答案や関連情報をまとめた資料(想定問答)を作成することです。 国会答弁は、国民及び国民の代表である国会議員に対して、政府の政策や方針、予算について国会で説明し、行政の透明性と説明責任を果たすためのものです。その質を支えるのが、国会答弁の想定問答作成業務であり、正確性や首尾一貫性などが厳しく求められる重要度の高い業務となっています。それゆえに職員の負担も大きく、 昨今の公務員の働き方改革や生成 AI 技術の急速な発展も相まって、本業務のさらなる高度化・効率化への期待が高まっています。AWS はとある省庁のシステム担当部局と、この想定問答の作成・審査業務における、 AI を活用した高度化・効率化の可能性を検討してきました。本稿では、AWS の公共部門のアカウントチームおよびプロトタイピングチームが伴走し、省庁が組織内に持つ過去の想定問答ファイルを横断検索しながら、AI による想定問答のドラフトの生成や、人の手による修正を含む審査プロセスを支援する AI アプリケーションを構築した取り組みをご紹介します。 プロトタイピングチームについて AWS パブリックセクタープロトタイピングチームは、公共・教育・医療・NPO などの分野のお客様が抱える課題の解決を無償で支援・加速するチームです。プロトタイピングという名前の通り、お客様の「実現したいこと」を、実際に動作するプロトタイプとして形にし、お客様に(技術)提供することで課題解決のご支援を行っています。 背景と課題 国会答弁のための想定問答を作成する際には、過去に作成した想定問答ファイルや国会会議録を、限られた時間の中で正確に参照する必要があります。しかし、参照すべき文書や資料の候補は大量にあり、検索対象も複数あることなどから、極めて限られた時間の中で、必要な情報に素早くたどり着くこと自体、容易ではないケースが多々あります。 補足:国会対応業務の流れ 国会対応における行政職員の作業の概要は以下の通りです(あくまで概略であり、実際の業務とは異なる場合があります)。 質問内容の聞き取り :次の委員会で質問することが予定されている国会議員やその秘書の方から、質問内容やその趣旨・背景について、事前に聞き取ります。 答弁案の初稿作成 :質問の対象となっている施策や領域の担当部局の行政職員が、現在の政府方針や現行法令、そのときどきの経済・社会情勢や過去の答弁等の関連情報を踏まえ、答弁案の初稿を作成します。 関係部局との調整 :答弁案の初稿に対して、関連する部局と調整を行います。質問や回答案が他の省庁に関係する場合は、他の省庁とも調整を行い、内容を精査します。 答弁審査 :担当部局が作成した答弁案について、過去の説明や他の部局が担当している施策、当日など直前に決まった政府方針などを踏まえているかどうか、質問に対する応答として正しく成立しているか、国民目線で適切な答弁案となっているかといった総合的な観点から、一言一句、審査が行われます。 レクチャー :答弁者への完成した原稿を、答弁者である大臣などに説明し、国会での議論に備えます。 今回のプロトタイプで注目したのは、このうち 答弁作成 と 答弁審査 の工程です。AI によって答弁案の作成を効率化したいという期待がある一方で、そもそも実際に役に立つ AI 支援ツールの作成は実現可能なのか。ユーザーである国家公務員の期待に応える水準の機能を提供できるのか。こうした問いを本格的な導入の前に見極めたい——それが今回のプロトタイピングプログラムの出発点です。 なお、本取り組みは答弁の最終的な判断や回答案の表現を AI に委ねるものではなく、あくまで人間の判断を中心に据えた上、関連する文書の検索やドラフトの準備など機械的に処理できる部分を AI に担わせることで、職員がより本質的な検討に集中できる環境を目指すものです。 なぜ AWS のプロトタイピングプログラム支援だったのか AWS のプロトタイピングプログラムは、公共のお客様のアイデアをプロトタイプに落とし込み、技術的な実現可能性を短期間で検証するための無償の支援プログラムです。アイデアを机上の議論にとどめず、現場の業務に近い形で動かし、使用者のフィードバックを得ながら評価したいという職員の方々のニーズに対し、Amazon Bedrock をはじめとするマネージドな AI サービス群と AWS アカウントチーム、そしてプロトタイピングチームの伴走により、最小限のリードタイムで検証サイクルを回せる本プログラムが最も適していると判断し、支援を開始しました。 プロトタイピングの進め方 一般的にプロトタイピングプログラムは1~3ヶ月程度で行いますが、本件では本番環境での導入を目指し約半年にわたって担当部局の方々と反復改善を重ね、画面の使い勝手から検索精度、運用面を含めた部分まで、利用者の声を起点に作り込みました。その結果、設定変更を含めた5回のメジャーバージョンと11回のマイナーバージョンを経て、本番運用を前提とした水準のプロトタイプとなりました。 進め方は、以下のサイクルを高頻度で回す共創型のアプローチです。 ヒアリングした要件を元に機能を開発。 担当部局の方々に実際にデプロイして使っていただき、フィードバックを収集する。 フィードバックを要件や設計に落とし込み、機能として実装する。 2に戻る。2で必要であれば、デプロイ支援、トラブルシューティング、バグ修正を行う。 サイクル完了後は、AWS 社内でセキュリティレビューを行い品質を保った状態のソースコード一式および「Path to Production(本番環境への移行ガイド)」を含むプロトタイプアセットをお客様にハンドオーバーします。 作成したプロトタイプについて 作成したプロトタイプ(DietSearch)は、想定問答における答弁案の初稿ドラフト案の生成と、その修正プロセスにおける審査を支援する AI アプリケーションです。組織が持つ過去の想定問答ファイルを検索し、文脈に即して初稿ドラフト案を作成し、その際に参照した過去の想定問答を、その類似度や関連性に応じてソートして表示することで審査を支援します。主な機能について、より詳しくは以下のとおりです。 文書のナレッジベース化 :組織が保有する過去の想定問答ファイルをセキュアな環境にアップロードすると、関連するメタデータを生成・付与することができ、検索可能なナレッジベースを構築できます。 メタデータの生成部分のカスタマイズ機能 :ユーザーが事前に定義したルールがシステム内で自動的に適用され、各文書に対してリッチで文脈豊かなメタデータが生成されます。(このメタデータにより、検索時の関連度合いや検索精度が飛躍的に向上します。)ルールの定義は UI 上で完全にカスタマイズ可能で、組み込みの AI アシスタントのサポートによりルールロジックの改善や拡張が容易に行えます。 例1:文書のファイルパスから年月、日時の情報をメタデータとして抽出 例2:文書情報やプロパティから構造化された洞察を導出 ドラフト生成 :入力された質問に対して、LLM による検索でヒットした文書をコンテキストとして参照し、 AI が答弁の初稿ドラフト案を作成します。ドラフトの各パラグラフには参照した過去の想定問答ファイルが紐づくため、過去の答弁案での記載を確認しながら加筆・修正できます。 過去の想定問答ファイルの横断検索(ハイブリッド検索) :修正後の答弁案に対して、改めて過去の類似する内容を含む想定問答ファイルを検索できます。過去答弁の検索には、ベクトル検索と全文検索を組み合わせたハイブリッド検索を採用。リランキングと日本語処理を組み合わせて、高い精度の検索を実現しています。 答弁案審査支援 :作成・修正された答弁案に対して、過去の想定問答との類似性を検証し、関連性の高い箇所をハイライト表示します。レビュー者は過去の類似のケースでどのように説明していたかを示す文書を並べて確認しながら、効率的にチェックできます。 国会会議録検索システムとの連携 :公開されている 国会会議録検索システム API と連携し、議事録を取得することで、検索結果として表示された組織内の過去の想定問答について、対応する日付の該当委員会において、実際にどのような発言があったか、あるいはなかったかを確認できるようになっています(LLM によってマッチしているかを段落ごとで判別しハイライトし可視化)。 また、利用者のフィードバックを起点に使いやすさと運用性にもこだわりました。検索結果と答弁案を左右に並べて比較できる UI、議事録原文のプレビュー、検索条件のフィルタリング、作業状況の他ユーザーへの共有、ロールベースのアクセス制御(既存の認証システムとの連携)、少ない操作でのファイルアップロードと同期を実現する機能などを備えています。 アプリイメージ図 アーキテクチャと採用サービス DietSearch は AWS のサーバーレス構成を基本とし、運用負荷やコストを抑えながらスケールできるよう設計しています。 フロントエンド配信 :Amazon CloudFront + Amazon S3、AWS WAF による保護 認証・認可 :Amazon Cognito (Identity Pool) によるロールベースアクセス制御(管理者/一般利用者) Amazon Cognito (User Pool) と Azure Entra ID との SAML 連携による認証部分の繋ぎ込みも行い、現場の既存の認証システムでのアプリの使用を可能にしました。 API :AWS Lambda (Function URL, TypeScript・Hono を利用) 検索・生成 :Amazon Bedrock Knowledge Bases を基盤とし、埋め込みモデルに Amazon Titan Text Embeddings V2、推論モデルに Claude 等を選択可能、セーフガードに Amazon Bedrock Guardrails を採用 ベクトルストア :Amazon Aurora Serverless v2 (PostgreSQL + pgvector) または Amazon OpenSearch Serverless を要件に応じて選択可能 データ管理 :Amazon S3 (文書データソース)、Amazon DynamoDB (データ管理) セキュリティ・運用 :AWS KMS による暗号化、Amazon CloudWatch によるモニタリング インフラはすべて IaC ( SST / Pulumi ) で管理し、セキュリティやコンプライアンスの観点からPulumi Policy Pack によるインフラ検証をデプロイ前のチェックに組み込んでいます。以下に DietSearch のシステム構成図を示します。 アーキテクチャ図 お客様の評価と今後の展望 担当部局の方々から以下のコメントを頂戴しております。 担当部局管理職より 本プロジェクトは、数か月という短期間で、構想段階からプロトタイプのリリースまでを進めることができた貴重な取組となりました。 初期的な要望に合わせて作成いただいたアプリケーションを、実際にユーザーとなり得る職員が試用し、その過程で判明した追加要望や課題を短いサイクルで設計や機能改善に反映いただけたことで、効率的にプロトタイプをブラッシュアップしていくプロセスを実践できました。 また、デプロイ作業や非機能要件に関する検討、課題対応の過程においても、AWSプロトタイピングチームから緊密なコミュニケーションをいただけたことは、アプリケーションの構成や運用方法に加え、インフラ環境に対する理解を深めることにもつながりました。 本プロジェクトを通じて、他の分野も含む今後のシステム開発の進め方について、多くの示唆が得られたと考えています。 担当部局職員より 本システムの構築にあたっては、AWS社との間で何度もフィードバックを重ねる機会を得ることができ、その結果、当組織の業務実態に即した、非常に使い勝手の良いアプリケーションを実現することができました。 一般に、官公庁におけるシステム構築ではウォーターフォール型の開発が主流であり、完成後に想定と異なる操作性となるケースも少なくありません。これに対し、本取組においてはアジャイル型の開発手法を採用したことで、利用者のニーズを反映した改善を随時行うことが可能となり、結果として業務効率化に大きく寄与するアプリケーションを構築するに至りました。 実際に組織内に部分的に展開したところ、「作成される初稿ドラフトの質が想像よりも高かった」「ファイルを自分で開いて確認する手間や国会議事録検索システムを検索する手間が減り、作業が早くなる」など、好評をいただいております。 当該省庁では、2026 年の秋から本格導入を目指し、準備を進めています。あわせて、本ソリューションは中央省庁にとどまらず、他の省庁や地方自治体での展開可能性も期待されています。AWS は引き続き、パートナーとともに本番運用に向けた支援を継続してまいります。 まとめ 「まず動かして確かめる」というプロトタイピングのアプローチは、 AI のように実際に動かしてみなければ効果を判断しにくい領域で、本格導入の判断材料を得るために特に有効です。AWS のパブリックセクター プロトタイピングチームは、公共のお客様のアイデアを短期間で形にし、次の意思決定を後押しします。同様の検討をされている方は、ぜひお近くの AWS 担当者にご相談、または次のメールアドレスにご連絡ください。 aws-jpps-prototyping@amazon.com 著者について Shota Kishimoto – Associate Prototyping Solutions Architect, AWS (プロトタイプチーム) Jorge Lanzarotti – Sr. Prototyping Solutions Architect, AWS (プロトタイプチーム) Hiromichi Miyawaki – Account Executive, Central Government, AWS (アカウントチーム) Naoki Miyaguchi – Solutions Architect, Central Government, AWS (アカウントチーム)
本記事は 2026 年 7 月 2 日 に公開された「 Amazon Redshift RG: Faster and lower cost, Graviton-powered 」を翻訳したものです。 Amazon Redshift は、Graviton プロセッサを搭載した新しいインスタンス RG の一般提供を開始しました。Amazon 独自の Graviton プロセッサ上に構築された RG は、以下を実現します。 データウェアハウスワークロードで RA3 と比較して最大 2.2 倍高速なパフォーマンス 統合されたベクトル化データレイクエンジンにより、Iceberg クエリで最大 2.4 倍、Parquet クエリで 1.5 倍高速 データレイククエリに対する TB あたりのスキャン料金が不要。RA3 クラスターに適用されていた Amazon Redshift Spectrum のコストを排除 RA3 と比較して vCPU あたりのコストが 30% 低減 RG はより高速かつ低コストです。一般的にクラウドベンダーは高速なパフォーマンスや新世代ハードウェアに対してより高い料金を設定しますが、Amazon Redshift はより高いパフォーマンスをより低いコストで提供します。 本記事では、RG インスタンスが高速な理由を説明します。また、RG が他の主要データウェアハウスと比較して最大 4.2 倍優れたプライスパフォーマンスを実現するベンチマーク結果も紹介します。 RG が高速な理由 新しい RG インスタンスは、Graviton プロセッサの性能を最大限に活用するためにゼロから設計されています。Amazon Redshift のベクトル化エンジンは Graviton ベースの SIMD (Single Instruction, Multiple Data) カーネルで最適化されており、分析ワークロードに対して高速で並列化された実行を実現します。Parquet エンコーディングに対する述語評価などの操作では、Graviton のベクトル比較、テーブルルックアップ、ベクトル操作のインストリンシクス(組み込み命令)を活用しています。処理速度の向上を支えるため、RG インスタンスはカスタムビルドの Nitro SSD を使用します。高速なローカルストレージをキャッシュレイヤーとして活用し、 Amazon Redshift Managed Storage (RMS) やデータレイクスキャン、メモリに収まらない計算の中間結果セットに対応します。また、RG の JIT (Just-In-Time) Analyze 機能は、クエリの実行中にデータレイクファイルの統計情報を自動的に収集・保存するため、オプティマイザが大幅に優れたクエリプランを生成できます。ハードウェアアクセラレーション (Graviton)、ベクトル化実行 (SIMD カーネル)、高速ストレージ (Nitro SSD)、適切なクエリプランニング (JIT Analyze) と、スタック全体で最適化を実現しています。 上記の最適化と、RG 専用に構築された高性能ベクトル化データレイクエンジンの組み合わせにより、Amazon Redshift の RG インスタンスは分析ワークロードで RA3 と比較して最大 2.2 倍高速に動作し、コストも 30% 低く抑えられます。 専用の高性能ベクトル化データレイクエンジン RA3 では、データレイククエリのスキャンを Amazon Redshift Spectrum と呼ばれる別のコンピュートフリートにオフロードしていました。データレイククエリが別のコンピュートで実行されるため、RA3 クラスターと Spectrum フリート間でクエリメタデータや結果を転送する際に追加の負荷が発生していました。Amazon Redshift RG インスタンスには、データレイク向けにゼロから設計された、まったく新しい組み込みスキャンレイヤーが含まれています。新しいスキャンレイヤーには、データレイテンシーを削減するスマートプリフェッチ機能を組み込んだ専用 I/O サブシステムが含まれます。また、Iceberg で最も一般的に使用されるファイル形式である Apache Parquet の処理に最適化されており、Graviton 向けに最適化された SIMD カーネルによる高速なベクトル化スキャンを実行します。スキャンレイヤーには、パーティションレベルとファイルレベルの両方で動作する高度なデータプルーニングメカニズムが含まれており、スキャンが必要なデータ量を大幅に削減します。プルーニング機能はスマートプリフェッチシステムと連携して動作し、データ取得プロセス全体の効率を最大化します。 新しい専用ベクトル化データレイクエンジンは、Iceberg クエリで RA3 と比較して最大 2.4 倍、Parquet クエリで 1.5 倍高速です。 新しいベクトル化データレイクエンジンは Amazon Redshift のコア実行エンジンに直接統合されているため、RA3 と比較して新たなパフォーマンス最適化が可能です。この統合アーキテクチャにより、RG でのデータレイククエリは高速なローカルデータキャッシュ、改良されたブルームフィルタ、ベクトル化 Parquet スキャン、高度なフィルタリングとプルーニングの恩恵を受けられます。 RG は、データレイクのクエリでお客様が直面する一般的な問題も解決します。Amazon Simple Storage Service (Amazon S3) 上の Iceberg などのオープンフォーマットファイルには有用なメタデータや統計情報が不足していることが多く、SQL クエリを最適に実行することが困難でした。 統計情報とは、個別値の数、最小値/最大値、分布パターン、行数などのデータに関するメタデータです。クエリオプティマイザはこの情報を使用して、クエリの最も効率的な実行方法を選択します。たとえば、2 つのテーブルを結合する際、オプティマイザは適切な結合戦略を選択するために各側が生成する一意の値の数を把握する必要があります。統計情報がなければ推測に頼ることになり、多くの場合、結合が遅くなりノード間で不要なデータ移動が発生します。ここで Amazon Redshift の新機能 JIT (Just-In-Time) Analyze が役立ちます。RG インスタンスはクエリの実行中に Iceberg ファイルの統計情報を自動的に取得・保存するため、Amazon Redshift は統計情報がない場合と比較してはるかに最適化されたクエリ実行戦略を選択できます。 Iceberg や Parquet データのスキャンが RA3 よりも大幅に高速になります。Amazon Redshift Spectrum のコンピュートが不要になったことで、RG インスタンスではデータレイククエリの $5/TB のコストも排除されます。データレイククエリがより安価になり、コストの予測も容易になります。パフォーマンスの向上、コンピュートコストの低減、TB あたりのスキャンコストの撤廃という 3 つのメリットにより、データレイクのプライスパフォーマンスが大幅に改善します。 データロードの高速化によるインサイト取得の迅速化 Amazon Redshift RG の高速 I/O と Graviton 最適化エンジンにより、RA3 と比較してデータロードが高速化されています。パフォーマンス改善を測定するため、同等サイズの RA3 と RG クラスターで 10TB TPC-DS および TPC-H のデータ取り込みステップを実行しました。RG は TPC-DS データセットを 2 倍高速に、TPC-H データセットを 1.4 倍高速に取り込みました (次の図を参照)。 新しい Graviton ベースの RG インスタンスは、RA3 インスタンスと比較してデータロードが最大 2.0 倍高速です。ワークロードはより早く最新データを取得でき、ユーザーやエージェントはより迅速に最新のインサイトを得られます。RG でのデータ取り込み高速化は RA3 と比較して 30% 低いコストで実現されており、データロードのプライスパフォーマンスは RA3 インスタンスと比較して最大 2.9 倍です。 お客様の声 Amazon Redshift のお客様は、RG への切り替えによるパフォーマンスとコストのメリットをすでに実感しています。Southwest Airlines と tombola はビジネスクリティカルなワークロードでテストを行い、パフォーマンスの向上とコスト削減を確認しました。 Southwest Airlines 「Amazon Redshift RG インスタンスは、Southwest Airlines に大きなビジネスインパクトをもたらす可能性があります。開発環境での初期テストでは、データウェアハウスワークロードが 50〜60% 高速化し、データレイク分析は 45% 高速化しました。チームはより早くインサイトを得て、運用状況に迅速に対応し、低レイテンシーでデータドリブンな意思決定を行えるようになります。これらの初期結果は期待が持てるもので、本番環境での検証とスケールアップが楽しみです。さらに、TB あたりの Spectrum スキャン料金が不要になり、燃料価格が業界のマージンを圧迫し続ける中、RA3 と比較して 30% のコスト削減を実現しています!」 — Sean Lynch、Vice President, Data and Architecture、Southwest Airlines tombola 「Graviton ベースの Amazon Redshift RG インスタンスは、バッチジョブと分析ジョブの多様なセットで、RA3 と比較して 1.8〜2 倍の書き込みスループットと最大 2.2 倍の読み取り速度を実現しました。同じ時間枠で 40% 多くの処理が可能になりました。ETL サイクルが短縮され、インサイト取得までの時間が加速し、パイプラインによる意思決定のボトルネックがなくなりました。これらの改善により、アナリストやビジネスチームにより新鮮なデータがより早く届くようになりました。さらに魅力的だったのは、パフォーマンス向上と同時にコンピュート費用が 30% 削減されたことです。より少ないコストでより多くを実現するのは稀な成果であり、強調する価値があります。クエリレイテンシーとコストがスケールに伴い複合的に影響する tombola のような大量データを扱うゲーム業界では、今年最もインパクトのあるプラットフォーム決定の一つとなりました。」 — Akshay Srinivasan、Data Engineer、tombola Qoala 「Amazon Redshift クラスターを RA3 から Graviton ベースの RG インスタンスに移行した結果、BI および分析ワークロード全体でクエリ処理時間が 60〜70% 高速化しました。数百万件の保険契約トランザクションを処理する成長中のインシュアテックプラットフォームとして、インサイト取得までの時間短縮は、データチームがダッシュボードやレポートをより早くビジネスに届けられることを意味します。将来の成長に対応するためにより大きなノード構成に移行しましたが、パフォーマンスの向上は追加投資をはるかに上回り、今年最もインパクトのあるインフラストラクチャ決定の一つとなりました。」 — Umar Abdul Aziz、VP of Data、Qoala パフォーマンス結果 RG の実力を確認するため、業界標準の TPC-DS および TPC-H ベンチマークをベースとしたベンチマークを 10TB スケールで、新しい Amazon Redshift RG インスタンスおよび主要な代替データウェアハウスで実行しました。ベンチマークは、アドホック、レポーティング、反復的なオンライン分析処理 (OLAP)、データマイニングなど、さまざまな運用要件と複雑性を持つクエリを実行するよう設計されています。各データウェアハウスをほぼ同じオンデマンドコスト ($32/時間) でサイジングし、特別なチューニングやカスタマイズなしにそのままの状態で 3 回のパワーランを実行しました。結果は以下のチャートのとおりです。 新しい RG インスタンスが大差をつけてリードしています。プライスパフォーマンスが優れているということは、パフォーマンスが高く、 かつ コストが低いことを意味します。 まとめ Amazon Redshift RG インスタンスは次世代の分析エンジンであり、データウェアハウスとデータレイクワークロードに高いパフォーマンスを提供します。RG は RA3 と同じワークロードと機能をすべてサポートしているため、利用開始は簡単です。アップグレードして、より低コストでより高いパフォーマンスを得る方法については、 移行ガイド を参照してください。 ワークロードに最適なプライスパフォーマンスを見つける 本記事で使用したベンチマークは、業界標準の TPC-DS および TPC-H ベンチマークをベースとしており、以下の特徴があります。 TPC-DS および TPC-H のスキーマとデータを変更せずに使用しています。 クエリは公式の TPC-DS および TPC-H キットを使用し、キットのデフォルトのランダムシードで生成されたクエリパラメータで生成されています。デフォルトクエリの SQL ダイアレクトをサポートしていないデータウェアハウスでは、TPC 承認済みのクエリバリエーションを使用しています。 テストには TPC-DS の 99 個の SELECT クエリと TPC-H の 22 個の SELECT クエリが含まれます。メンテナンスとスループットのステップは含まれません。 3 回のパワーランを実行し、各データウェアハウスで最も良い結果を採用しています。 プライスパフォーマンスは、時間あたりのコスト (USD) を 1時間あたり 3,600 秒で割り、ベンチマークの幾何平均 (秒) を掛けて計算します。これはクエリあたりの幾何平均コストに相当します。すべてのデータウェアハウスで最新の公開オンデマンド料金を使用しています。 Cloud Data Warehouse ベンチマークと呼ばれるこのベンチマークの結果は、 GitHub リポジトリ で公開されているスクリプト、クエリ、データを使用して再現できます。本記事で説明したとおり TPC-DS ベンチマークをベースとしていますが、公式仕様に準拠していないため、公開済みの TPC-DS 結果とは比較できません。 著者について Stefan Gromoll Amazon Redshift チームのプリンシパルエンジニアで、Redshift のパフォーマンスを担当しています。プライベートでは料理、4 人の息子たちとの遊び、薪割りを楽しんでいます。 Ankit Sahu データ製品やサービスの構築に 18 年以上の経験を持ち、プロダクト戦略、Go-to-Market 実行、デジタルトランスフォーメーションの幅広い経験があります。現在は Amazon Web Services (AWS) のシニアプロダクトマネージャーとして、Amazon Redshift のビジョンと戦略を推進しています。 Mohammed Alkateb Amazon Redshift のエンジニアリングマネージャーで、クエリ最適化、データレイクアクセス、パフォーマンスエンジニアリング、新しいインスタンスの検証にわたるソフトウェアエンジニア、アプライドサイエンティスト、Amazon Scholar のチームを率いています。Amazon 入社前は Teradata のオプティマイザチームに 12 年以上在籍。バーモント大学で博士号を取得し、主要なデータベースカンファレンスでの論文発表や米国特許を多数保有しています。 Yousuf Hussain Amazon Redshift のシニアソフトウェアエンジニアで、大規模クラウドデータウェアハウスシステムの構築と運用に 11 年の経験があります。分析に情熱を持ち、Amazon Redshift のお客様に高パフォーマンスな体験を提供するためにインスタンス戦略、可用性、信頼性に注力しています。 Nita Shah ニューヨーク拠点の AWS シニアアナリティクススペシャリストソリューションアーキテクトです。20 年以上にわたりエンタープライズデータプラットフォーム、データウェアハウス、分析ソリューションを構築しており、Amazon Redshift を専門としています。エンタープライズ規模の Well-Architected な分析・意思決定支援プラットフォームの設計と構築を支援しています。 Sanket Hase Amazon Redshift チームのエンジニアリングマネージャーで、データレイク分析、ハードウェア・ソフトウェア協調設計、ベクトル化クエリ実行に焦点を当てたクエリ実行チームを率いています。カーネギーメロン大学でコンピューターサイエンス修士号を取得し、データベースシステム分野で複数の米国特許を保有しています。 Jingbo Zhang Amazon Redshift のデータエンジニアで、新しいインスタンスの検証とパフォーマンスバリデーションを担当しています。RG、r8gd、r7gd を含む複数の Graviton ベース Redshift インスタンスファミリーの検証とローンチに貢献し、ベンチマーク、パフォーマンス分析、自動化に注力しています。カーネギーメロン大学でデータアナリティクス修士号を取得しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。
本記事は 2026 年 7 月 1 日 に公開された「 AI-powered performance recommendations for Amazon Redshift 」を翻訳したものです。 Amazon Redshift を運用するデータプラットフォームチームは、 SYS_QUERY_HISTORY 、 SVV_TABLE_INFO 、 SVV_ALTER_TABLE_RECOMMENDATIONS などのシステムビューや、キャパシティ、クエリ実行、ストレージに関する Amazon CloudWatch メトリクスからパフォーマンステレメトリを収集しています。課題はテレメトリの解釈です。 QueryRuntimeBreakdown のコミット時間の急増と数百件の小規模な INSERT 文の関連性を見抜く、あるいはディスクスピルの多発とコンピュートの不足を結びつけるには、深い専門知識と数時間に及ぶ手作業の分析が必要です。 本記事では、テレメトリを収集し、パフォーマンスシグナルを事前計算し、CloudWatch と相関分析を行い、 Amazon Bedrock で優先度付きの推奨事項を生成する AI ソリューションの構築方法を解説します。ソースコードは GitHub リポジトリ sample-ai-performance-advisor-for-amazon-redshift で公開しています。 シグナルベースの設計により、汎用的なアドバイスではなく的確な推奨を生成できます。システムビューの生出力をそのまま大規模言語モデル (LLM) のプロンプトに渡すのではなく、コレクターが真偽値やしきい値に基づく検出結果を事前計算し、CloudWatch との相関を付与したうえで、構造化されたコンテキストをモデルに渡します。これにより、モデルの出力で具体的なクエリ ID、テーブル名、メトリクス値を参照できます。 ソリューション概要 2 つの AWS Lambda 関数が 24 時間間隔の Amazon EventBridge スケジュールで実行されます。 コレクター Lambda は、 Amazon Redshift Serverless に対して 13 の診断 SQL クエリを実行し、ワークグループの Workload Management (WLM) 設定を読み取ります。また、キャパシティ、クエリ実行、WLM、接続数、ストレージの CloudWatch メトリクスも収集します。これらの入力からパフォーマンスシグナルを計算し、テレメトリ JSON ファイルを Amazon Simple Storage Service (Amazon S3) に書き込みます。 アナライザー Lambda は Amazon S3 からテレメトリを読み取り、CloudWatch とシグナルの相関をインラインで含む構造化プロンプトを構築します。相関情報を活用して Amazon Bedrock ( Anthropic Claude Sonnet 4.6) を呼び出し、生成された推奨事項 JSON を Amazon S3 に書き戻します。 Amazon Simple Notification Service (Amazon SNS) トピックが、上位の推奨事項をメールでサブスクライバーに送信します。 図 1 – アーキテクチャ図 前提条件 デプロイ前に、以下を準備してください。 データベースとクエリ履歴がある Amazon Redshift Serverless ワークグループ。 Amazon Redshift データベース管理者ユーザー (スーパーユーザー)。コレクターはスーパーユーザーのみがクエリできるビュー ( SVV_TABLE_INFO 、 SVV_ALTER_TABLE_RECOMMENDATIONS 、 SVV_MV_INFO 、 SYS_SERVERLESS_USAGE 、 SYS_AUTO_TABLE_OPTIMIZATION ) を読み取ります。 管理者の認証情報を AWS Secrets Manager に保存し、シークレット ARN をコレクターに渡します。 別の方法として、既存のスーパーユーザーで ALTER USER "IAMR:redshift-performance-recommendations-role" CREATEUSER; を一度実行し、Lambda ロールにスーパーユーザー権限を付与する方法もあります。 使用するモデルの Amazon Bedrock モデルアクセス。本ソリューションでは、マルチリージョン推論用に us.anthropic.claude-* モデルを推奨しますが、特定のモデルに依存しない設計です。 AWS Command Line Interface (AWS CLI) のインストールと設定、および GitHub リポジトリのクローン。 サポートリソースの作成 Lambda 関数を実行するには、Amazon S3 バケット、Amazon SNS トピック、 AWS Secrets Manager シークレット、 AWS Identity and Access Management (IAM) ロールが必要です。 Amazon S3 バケットの作成 Amazon S3 バケットに出力レポートを保存します。 Amazon S3 コンソールを開き、 バケットを作成 を選択します。 グローバルに一意の名前 (例: amzn-s3-demo-bucket ) を入力し、デフォルト設定のまま バケットを作成 を選択します。 コレクターは telemetry/ プレフィックス配下にテレメトリ JSON を書き込み、アナライザーは recommendations/ プレフィックス配下に推奨事項を書き込みます。 Amazon SNS トピックとサブスクリプションの作成 レポート作成後の通知に Amazon SNS を使用します。 Amazon SNS コンソールを開き、 トピック 、 トピックの作成 の順に選択します。 スタンダード を選択し、名前に redshift-performance-recommendations と入力します。 トピックの作成 を選択します。 トピック詳細ページで サブスクリプションの作成 を選択します。 プロトコルとして E メール を選択し、メールアドレスを入力して サブスクリプションの作成 を選択します。 AWS Notifications からの確認メールを開き、 サブスクリプションの確認 を選択します。 図 2 – SNS トピックの作成 管理者の認証情報を AWS Secrets Manager に保存 ハードコードされた認証情報を避けるため、AWS Secrets Manager シークレットを作成して Amazon Redshift に接続します。 AWS Secrets Manager コンソールを開き、 新しいシークレットを保存する を選択します。 その他のシークレットのタイプ を選択し、 プレーンテキスト タブを選択して以下を貼り付けます。 <ADMIN_PASSWORD> はワークグループの管理者パスワードに置き換えてください。 {"username":"admin","password":"<ADMIN_PASSWORD>"} 次へ を選択し、シークレット名に redshift-performance-admin と入力して、 次へ 、 次へ 、 保存 を選択します。 シークレット詳細ページからシークレットの Amazon Resource Name (ARN) をコピーします。後のステップでコレクターに渡します。 図 3 – シークレットの作成 IAM ロールの作成とポリシーのアタッチ リポジトリには、 iam/trust-policy.json に信頼ポリシー ( lambda.amazonaws.com がロールを引き受けることを許可) と、 iam/lambda-role-policy.json に最小権限のアクセス許可ポリシーが含まれています。アクセス許可ポリシーの <ACCOUNT_ID> 、 <REGION> 、 <YOUR_BUCKET> 、SNS トピック ARN のプレースホルダーを自身の値に置き換えてから、 AWS マネジメントコンソール または以下の AWS CLI コマンドでロールを作成します。 aws iam create-role --role-name redshift-performance-recommendations-role \ --assume-role-policy-document file://iam/trust-policy.json aws iam put-role-policy --role-name redshift-performance-recommendations-role \ --policy-name redshift-performance-policy \ --policy-document file://iam/lambda-role-policy.json アクセス許可ポリシーは、両方の Lambda 関数に必要な Amazon Redshift Data API、Amazon S3、Amazon SNS、Amazon Bedrock、AWS Lambda 呼び出し、AWS Secrets Manager、 Amazon CloudWatch Logs の権限を付与します。 Lambda 関数のデプロイ コレクターのソースは lambda/collector.py にあり、実行時に sql/ 配下の SQL ファイルを読み込みます。デプロイパッケージには両方を含める必要があります。 コレクターのパッケージング ターミナルまたはシェルを開き、コレクターのコードと SQL をフォルダにコピーしてアーカイブを作成します。 mkdir -p build/collector/sql cp lambda/collector.py build/collector/ cp sql/*.sql build/collector/sql/ (cd build/collector && zip -qr ../collector.zip .) コレクター関数の作成 AWS マネジメントコンソールで AWS Lambda に移動します。 関数の作成 を選択します。   図 4 – AWS Lambda 関数の作成 一から作成 を選択し、名前に redshift-performance-collector と入力して、 Python 3.14 を選択します。 カスタム設定 を展開し、 カスタム実行ロール を切り替えて、 既存のロール を選択し、 redshift-performance-recommendations-role を選択して 保存 を選択します。 関数ページで アップロード元 、 .zip ファイル を選択し、 build/collector.zip をアップロードします。 ランタイム設定 で 編集 を選択し、 ハンドラ を collector.lambda_handler に設定します。   図 5 – AWS Lambda ハンドラの設定 設定 、 編集 を選択し、タイムアウトを 5 分、メモリを 256 MB に設定します。   図 6 – AWS Lambda のタイムアウトとメモリの設定 設定 で 環境変数 を選択し、以下のキーを追加します。 WORKGROUP : Amazon Redshift Serverless ワークグループ名。 NAMESPACE_NAME : ワークグループが属する名前空間。 DATABASE : dev (または対象のデータベース)。 BUCKET : 先ほど作成した Amazon S3 バケット名。 SECRET_ARN : 先ほどコピーした AWS Secrets Manager シークレット ARN。 ANALYZER_FN : redshift-performance-analyzer 。 アナライザーのパッケージングと作成 lambda/analyzer.py を使用して、アナライザーも同様の手順で作成します。タイムアウトは 15 分です。 (cd lambda && zip -q ../build/analyzer.zip analyzer.py) Lambda コンソールで redshift-performance-analyzer を作成し、ハンドラを analyzer.lambda_handler 、タイムアウトを 15 分、メモリを 256 MB、同じ実行ロールを設定して、以下の環境変数を追加します。 BUCKET : 同じ Amazon S3 バケット。 SNS_TOPIC : SNS トピック ARN。 MODEL_ID : us.anthropic.claude-sonnet-4-6 。 アナライザーは read_timeout=600 と max_tokens=16384 を指定して Amazon Bedrock クライアントを作成し、大規模なプロンプトと長い応答に対応します。フルテレメトリペイロードでの Anthropic Claude 推論は通常 2〜4 分かかります。 シグナルとプロンプトの仕組み シグナル計算やプロンプト構築のカスタムコードを書く必要はありません。どちらもリポジトリに含まれています。 lambda/collector.py の compute_signals() 関数は、テレメトリをスキャンして真偽値としきい値に基づくアンチパターンを検出します。テーブルレベルでは、行の偏り (skew)、ゴースト行(論理削除行)、統計情報の陳腐化、未ソートデータ、最適でないソートキーや分散キー、過大な VARCHAR カラムを検出します。ランタイムとワークロードの問題として、ディスクスピル(中間データのディスク書き出し)、小規模 INSERT のバースト、DDL (データ定義言語) の多発、最適化されていない COPY ファイルサイズも検出します。さらに、パーティションプルーニングに失敗した Amazon Redshift Spectrum クエリや、フルリフレッシュを行うデータ共有マテリアライズドビューも検出します。また、ディスクスピルブロック数やクエリ実行時間の制限など、Query Monitoring Rules (QMR) が欠如している WLM 設定も検出します。シグナルとしきい値の全セットは関数内にインラインで定義されています。しきい値の調整やカスタムシグナルの追加は、この関数を編集して再デプロイするだけで対応できます。 lambda/analyzer.py の build_prompt() 関数は、Amazon Bedrock プロンプトを 4 つのセクションで構築します。第 1 セクションはトリガーされたシグナルの一覧です。第 2 セクションは CloudWatch メトリクスを追加し、各シグナルとそのサポートメトリクスを対にする  >> CORRELATION 行で注釈をつけます。第 3 セクションはフィルタリングされたサポートデータで、シグナルをトリガーしたテーブル行とクエリ行に限定されています。第 4 セクションは、すべての推奨事項で特定のテーブル名、クエリ ID、メトリクス値を参照するパイプ区切りテキストを返すよう明示的に指示します。この構造により、モデルは汎用的なベストプラクティスではなく具体的な出力を生成します。 日次実行のスケジュール設定 Amazon EventBridge コンソールでコレクターを 24 時間ごとにトリガーします。 EventBridge コンソールを開き、 Scheduler の スケジュール 、 スケジュールを作成 を選択します。 スケジュール名 に redshift-performance-daily と入力し、 定期スケジュール と レートベースのスケジュール を切り替えます。 レート式 に 24 と入力し、 時間 を選択します。 フレキシブルタイムウィンドウ で オフ を選択し、 次へ を選択します。 図 7 – Amazon EventBridge スケジュールの作成 ターゲットを選択 ページで、 AWS Lambda を選択し、 redshift-performance-collector 関数を選択して 次へ を選択します。   図 8 – Amazon EventBridge スケジュールターゲットの選択 設定 のデフォルトを受け入れて 次へ を選択します。EventBridge は Lambda 関数にリソースベースのアクセス許可を自動的に追加し、ルールが関数を呼び出せるようにします。 スケジュールを作成 を選択します。 実行して出力を確認する コレクターを手動で呼び出し、パイプライン全体が動作することを確認します。 Lambda コンソールで redshift-performance-collector 関数を開き、 テスト を選択します。テストイベント名に manual 、本文に {} と入力して テスト を選択します。   図 9 – エンドツーエンドワークフローのテスト 関数は 1 分以内に完了します。 モニタリング タブの CloudWatch ライブログ リンクで呼び出しログを確認します。 Amazon S3 コンソールでバケットを開きます。 telemetry/ プレフィックスに現在のタイムスタンプの JSON ファイルがあることを確認します。 2〜4 分以内にアナライザーが SNS トピックにメッセージを発行します。登録したメールアドレスで上位 10 件の推奨事項サマリーを確認します。Amazon S3 の recommendations/ プレフィックスに完全な JSON があることも確認します。 各推奨事項には、優先度 (critical、high、medium、low) とカテゴリ ( query_optimization 、 table_design 、 capacity 、 wlm 、 maintenance 、 ingestion ) があります。また、推奨をトリガーしたシグナルと CloudWatch メトリクスを示す signal_source 、平易な言葉での説明、具体的な SQL または設定アクション、想定される影響の見積もりも含まれます。 図 10 – アナライザーのメール出力サンプル ベストプラクティス しきい値をワークロードに合わせて調整する。 compute_signals() のデフォルトしきい値は Amazon Redshift 運用レビュープレイブックに基づいています。高速取り込みや小規模クラスター環境では、小規模 INSERT のしきい値を下げる、統計情報の陳腐化ウィンドウを広げる、テーブル固有のカスタムシグナルを追加するなどの調整を検討してください。 シグナルとメトリクスの相関を最新に保つ。 シグナルを追加する場合は、 build_correlations() に対応する相関も追加してください。インラインの >> CORRELATION 行が、インフラストラクチャメトリクスとアプリケーションレベルの症状を結びつけます。 推奨事項は実行前にレビューする。 アナライザーは優先度付きの提案を生成しますが、 VACUUM 、 ANALYZE 、 ALTER TABLE はテーブルの状態を変更します。各推奨事項の説明とアクションを確認し、スキーマに対して SQL を検証してから、メンテナンスウィンドウ中に実行してください。 クリーンアップ 不要な課金を避けるため、本ソリューション用に作成したリソースを削除してください。 2 つの AWS Lambda 関数: redshift-performance-collector と redshift-performance-analyzer 。 Amazon EventBridge ルール: redshift-performance-daily 。 Amazon SNS トピックとメールサブスクリプション: redshift-performance-recommendations 。 Amazon S3 バケット ( telemetry/ と recommendations/ のオブジェクトを含む)。 AWS Secrets Manager シークレット: redshift-performance-admin 。 IAM ロールとインラインポリシー: redshift-performance-recommendations-role 。 まとめ Amazon Redshift Serverless の日次パフォーマンスレビューを AWS Lambda で実行し、結果を Amazon S3 に保存し、優先度付きの推奨事項をメールで配信する仕組みが完成しました。シグナルベースのプロンプトパターンにより、Amazon Bedrock のコストを抑えつつ、ワークロード固有の推奨を生成できます。 詳細については、以下のリソースを参照してください。 ソースコード: GitHub の sample-ai-performance-advisor-for-amazon-redshift 。 Amazon Redshift のシステムテーブルとビュー 。 Amazon Bedrock ユーザーガイド 。 Amazon CloudWatch での Amazon Redshift Serverless のモニタリング 。 著者について Steve Phillips Steve は、AWS 北米リージョンのプリンシパルテクニカルアカウントマネージャー兼 Analytics スペシャリスト。データウェアハウスのアーキテクチャ設計、AI/ML データ基盤、データレイク、データ取り込みパイプライン、クラウド分散アーキテクチャに注力しています。 Richard Raseley Richard は、北米のシニアテクニカルアカウントマネージャーとして、ゲーム業界のお客様を担当。自動化、クラウドコンピューティング、ネットワーク、ストレージのバックグラウンドを活かし、お客様の AI ソリューション構築を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。
本記事は 2026 年 6 月 29 日 に公開された「 Scale analytics with Amazon Redshift multi-warehouse enhancements 」を翻訳したものです。 Amazon Redshift のリモートテーブル DDL の改善、マテリアライズドビューの機能強化、ゼロ ETL および 自動コピー向けの同時実行スケーリング拡張により、大規模なアナリティクスワークロードを効率的にオンボードできるようになりました。 組織がアナリティクス機能を拡張する際には、本番環境の運用を中断せず、単一のデータウェアハウスのリソースに制約されずにワークロードを追加できる柔軟性が求められます。本記事では、 Amazon Redshift のマルチウェアハウスおよびスケーリング機能を強化する新機能として、リモートマテリアライズドビュー (MV) 操作、リモートテーブル DDL サポート、ゼロ ETL および S3 イベント統合向け同時実行スケーリングの拡張を紹介します。各機能を組み合わせることで、Amazon Redshift 上でスケーラブルかつ高パフォーマンスな分散型アナリティクスアーキテクチャを構築できます。 マルチウェアハウスの新機能で大規模アナリティクスをどのように実現できるか確認していきましょう。 リモートマテリアライズドビュー操作の新機能 Amazon Redshift では CREATE MATERIALIZED VIEW がユーザーワークロードとして分類される ようになりました。リソース競合時に同時実行スケーリングが追加のウェアハウスで MV ロジックを実行できるため、高負荷時でもクエリが MV のパフォーマンスメリットを安定して享受できます。 Amazon Redshift で リモートデータ共有上での MV 作成 がサポートされるようになりました。Redshift ウェアハウス間でデータを共有しているお客様が、ローカルデータと共有データの両方で MV のパフォーマンスメリットを活用できます。 コンシューマーウェアハウスで、 プロデューサーで作成された MV のリフレッシュや、データ共有された MV の上に MV を作成 できるようになりました。データ共有アーキテクチャのプロデューサーとコンシューマーのウェアハウス間で MV の機能が完全に同等になりました。 リモートテーブル DDL 操作の新機能 ALTER TABLE ALTER DISTSTYLE 操作が、同時実行スケーリングとデータ共有を通じてリモートウェアハウスで動作するようになりました。分散環境全体でデータ分散を動的に最適化し、データ移行なしでクエリパフォーマンスとリソース使用率を改善できます。複数のウェアハウスにまたがるパフォーマンスチューニングを行うデータエンジニアや、変化するクエリパターンに対応する管理者にとって特に有用です。 ALTER TABLE APPEND 操作が、同時実行スケーリングとデータ共有を通じてリモートウェアハウスに拡張されました。分散環境間でデータを統合でき、複雑なデータ移動や ETL プロセスなしで効率的にテーブルを結合できます。複数環境にまたがる動的テーブル操作を管理する組織が、運用負荷を軽減しながらデータの一貫性を維持できます。 同時実行スケーリングの改善 Amazon Redshift の拡張された ゼロ ETL 機能が同時実行スケーリングをサポート し、アプリケーションやオペレーショナルソースからの自動データ取り込みに対応しました。 Amazon Redshift の拡張された 自動コピー機能が同時実行スケーリングをサポート し、S3 からの自動データ取り込みに対応しました。 Amazon Redshift の同時実行スケーリングが Amazon S3 からの COPY クエリをサポートするようになりました。バッチワークロード向けに 同時実行スケーリングでデータ取り込みを自動的にスケール できます。 同時実行スケーリングの拡張により、既存のウェアハウスパフォーマンスを損なわずに一貫したデータ鮮度を維持できます。アナリティクスとデータロードのトレードオフが解消されます。同時実行スケーリングを有効にする以外に、追加の変更は不要です。 お客様のユースケース ここでは、金融サービスとゲーム業界の 2 つのユースケースを紹介します。 金融サービスのユースケース 以下は、グローバル展開する大手金融サービスのお客様のサンプルアーキテクチャです。同社は Amazon Redshift 上にマルチウェアハウスアーキテクチャを構築しています。 ステージング (STG) ウェアハウスは、メダリオンアーキテクチャのブロンズレイヤーのように、さまざまなソースからのデータの 生データゾーンです。STG ウェアハウスは 生データのクレンジングと標準化も行い、シルバーレイヤーとして後続処理に利用可能にします。また、MV を使用して数百万件のネストされた JSON メッセージを処理し、属性をスカラーのカラム型 Amazon Redshift テーブルに抽出します。 CREATE MATERIALIZED VIEW rawdb.fsi.customer_orders_raw distkey(c_custkey) sortkey(c_custkey) AS ( SELECT c_custkey, o.o_orderstatus, o.o_totalprice, o_idx FROM customer_orders_lineitem c, c.c_orders o AT o_idx ); REFRESH MATERIALIZED VIEW rawdb.fsi.customer_orders_raw; DWH ウェアハウスはプライマリ Amazon Redshift インスタンスおよびゴールドレイヤーとして、Business Objects や Tableau などのコンシューマーアプリケーションにデータを提供します。ゼロ ETL 同時実行スケーリングの改善により、ゼロ ETL の取り込みスパイクと DWH の高負荷ワークロードが同時に発生しても、一貫したデータ鮮度を維持できます。DWH の MV は、Tableau エクストラクトや Business Objects のライブレポート向けに集約データへの高速アクセスを提供します。DWH ウェアハウスは、DWH インスタンス上で複数の MV をリフレッシュする必要がある場合に同時実行スケーリングを活用します。 CREATE MATERIALIZED VIEW bodb.final.customer_churn_tbl AS ( SELECT state, account_length, area_code, total_charge/account_length AS average_daily_spend, cust_serv_calls/account_length AS average_daily_cases, churn FROM custdb.final.customer_activity_all ); REFRESH MATERIALIZED VIEW bodb.final.customer_churn_tbl; ETL01/02 ウェアハウスはプロジェクト固有の ETL ジョブを実行する専用コンピュート環境として、USR01/02 ウェアハウスは dbt からのアドホック分析やモデル構築などのユーザーワークロードを処理します。ユーザーワークロードに新しいオブジェクトが必要な場合、リモートのプロデューサーウェアハウス (DWH) 上で作成・管理されます。 ALTER TABLE salesdb.final.sales_report_all ALTER DISTKEY sales_id; ALTER TABLE APPEND salesdb.final.sales_report_all FROM stagingdb.sales.sales_2026_02; ゲーム業界のユースケース 大手ゲーム会社は、アナリティクスインフラ全体を AWS 上に構築しており、アナリティクスチームがゲームからのデータストリーミング、データウェアハウジング、BI ツールを管理しています。同社は Amazon EC2 上で稼働していた Vertica から移行し、Amazon Redshift を組織全体で標準化しました。クラスターリサイズ操作に関する初期の課題を克服した後、チームは Amazon Redshift の強力な推進者となり、現在は 32 ノードの ra3.16xlarge でプライマリ本番クラスターを運用しています。 データ取り込みパイプラインの成長に伴い、クエリワークロードがデータ取り込みプロセスと競合し、パフォーマンスのボトルネックが発生しました。プライマリクラスターをスケールアップするのではなく、Amazon Redshift データ共有を使用したワークロード分離戦略を実装しました。プライマリクラスターをプロデューサーとして、16 ノードの ra3.4xlarge クラスターをデータ共有コンシューマーとして起動しました。データ共有アーキテクチャにより、コンシューマークラスターにコンシューマーワークロードを移行し、プロデューサーはデータ取り込みに集中することで、プライマリクラスターのサイズを増やすことなく成長に対応できました。 分散アーキテクチャの利点を認識した同社は、ワークロードを Amazon Redshift Serverless に移行してアプローチを拡大し、ワークロード分離のためにデータ共有モデルをさらに活用しました。Amazon Redshift のリモートマテリアライズドビュー機能により、プロデューサークラスターが共有するデータ上に直接マテリアライズドビューを作成できるようになりました。各コンシューマークラスターが、固有のワークロードパターンに最適化されたマテリアライズドビューを構築できます。事前集約データセット、カスタム結合戦略、ワークロード固有のデータ分散を、プロデューサークラスターのパフォーマンスに影響を与えずデータの重複も不要で実現できました。プロデューサーウェアハウスは汎用的なエンタープライズニーズ向けに設計されたデータ分散とソート戦略を維持し、すべてのコンシューマーに対して一貫したデータ品質を提供します。一方、コンシューマーウェアハウスはリモートマテリアライズドビューを使用して、リアルタイムのプレイヤーアナリティクス、BI ダッシュボード、アドホックなデータサイエンスワークロードなど、固有の分析要件に合わせてクエリパフォーマンスを最適化しました。データ消費を最適化する分散アプローチは同社にとって不可欠でした。プロデューサークラスターを信頼できる唯一の情報源 (Single Source of Truth) として維持し、冗長なデータコピーの管理負荷を回避しながら、多様な分析ワークロード全体で高速なクエリパフォーマンスを実現しました。 ベストプラクティス 新機能を最大限に活用するために、以下のベストプラクティスを検討してください。 Amazon Redshift クラスターおよび Serverless ワークグループで同時実行スケーリングを有効にし、ETL やユーザークエリの実行をさらに高速化して、レポートやダッシュボードのパフォーマンスを安定させましょう。 Amazon Redshift プロビジョンドクラスターおよび Serverless ワークグループの両方で、適切な MaxRPU 設定により同時実行スケーリングの使用制限を設定しましょう。予期しない追加コストの発生を防げます。詳細については、Amazon Redshift の使用制限に関するドキュメントを参照してください。 リモート MV を使用して、リソース集約型の MV 作成やリフレッシュ操作をプライマリウェアハウスからリモートデータ共有クラスターにオフロードしましょう。 まとめ 本記事では、MV リフレッシュの新機能、リモートテーブル DDL 機能、ゼロ ETL および S3 自動コピー向けの同時実行スケーリングサポートの拡張について紹介しました。各機能により、単一ウェアハウスの制約を超えることができます。複数環境にまたがる動的テーブル管理を必要とし、データの一貫性を維持しながら変化するワークロードに迅速に適応する分散データアーキテクチャを管理する組織にとって特に価値があります。利用を開始するには、最新の Amazon Redshift バージョン を実行していることを確認してください。続いて Amazon Redshift のドキュメントで 同時実行スケーリング 、 データ共有 、 マテリアライズドビュー の詳細をご覧ください。 著者について Raza Hafeez Raza は、Amazon Redshift のシニアテクニカルプロダクトマネージャー。エンタープライズデータウェアハウスの構築と最適化に 15 年以上の経験があり、あらゆる規模のお客様にとってクラウドアナリティクスを利用しやすく費用対効果の高いものにすることに注力しています。 Ravi Animi Amazon Redshift チームのシニアプロダクトリーダー。空間アナリティクス、ストリーミングアナリティクス、クエリパフォーマンス、Spark インテグレーション、アナリティクスビジネス戦略など、Amazon Redshift クラウドデータウェアハウスサービスの複数の機能領域を管理しています。リレーショナルデータベース、多次元データベース、IoT 技術、ストレージおよびコンピュートインフラサービスの経験があり、最近では人工知能 (AI) とディープラーニング、コンピュータビジョン、ロボティクスの分野でスタートアップの創業者としての経験もあります。 Satesh Sonti Satesh は、アトランタ拠点のプリンシパルアナリティクススペシャリストソリューションアーキテクト。エンタープライズデータプラットフォーム、データウェアハウジング、アナリティクスソリューションの構築を専門としています。20 年以上にわたり、世界中の銀行・保険のお客様向けにデータ資産の構築と複雑なデータプラットフォームプログラムのリードに携わっています。 Milind Oke Amazon Web Services で 3 年間勤務するシニア Redshift スペシャリストソリューションアーキテクト。AWS 認定ソリューションアーキテクト – アソシエイト、セキュリティ – 専門知識、アナリティクス – 専門知識を保有。ニューヨーク州クイーンズ在住。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。
本記事は 2026 年 6 月 29 日 に公開された「 Amazon Redshift delivers faster performance for BI dashboards and real-time analytics 」を翻訳したものです。 ビジネスインテリジェンス (BI) ダッシュボードとリアルタイム分析は、迅速な意思決定に欠かせないツールです。現代のデータウェアハウスは、複雑で長時間実行される分析クエリに優れるだけでなく、インタラクティブなリアルタイム体験を支える短時間のアドホッククエリにもサブ秒のレスポンスタイムを実現する必要があります。エージェントが大量のデータから新たなインサイトを探索・導出するようになった今、低レイテンシーの要件はさらに重要になっています。朝のダッシュボードで KPI を確認する経営層から、エージェントを使ってデータセットをインタラクティブに探索するデータアナリストまで、クエリが高速かつ安定した応答を返すことへの期待は明確です。 Amazon Redshift はこうしたユースケース向けに長年最適化されてきました。BI やリアルタイム分析ワークロードのクエリパフォーマンスを向上させるため、結果キャッシュ、マテリアライズドビュー、自動ワークロード管理 (AutoWLM) など、多くの機能を導入しています。こうした機能により、数千のお客様がレスポンスの良いダッシュボードやリアルタイムアプリケーションを Amazon Redshift 上に構築してきました。しかし、インタラクティブ分析ではミリ秒単位の差が重要です。ダッシュボードの読み込み高速化と探索的クエリの応答時間短縮に引き続き注力しています。 本日、Amazon Redshift の新しいパフォーマンス最適化を発表します。リアルタイム分析アプリケーションや BI ダッシュボードが生成する低レイテンシー SQL クエリのレスポンスタイムを改善する機能です。SQL クエリの実行準備にかかる時間を短縮することで、クエリレイテンシーが改善されます。クエリの開始が速くなるため、結果もより早く返されます。 最適化の仕組み 今回の改善を理解するために、まず Amazon Redshift の既存のコアパフォーマンス機能であるコード生成について説明します。コード生成は、各 SQL クエリを分析し、クエリ固有の C++ コードを内部的に生成する最適化手法です。生成されたコードはコンパイルされ、利用可能な Amazon Redshift コンピューティングノード全体で並列実行されて結果を返します。コード生成は Amazon Redshift のクエリパフォーマンスの基盤であり、複雑な分析クエリを高い効率で実行します。 コード生成により高いクエリ実行性能を実現する一方で、新しいクエリは初回実行時に一度だけコンパイルの負荷が発生します。Amazon Redshift はすでにコンパイル済みコードをキャッシュしており、 Amazon Redshift フリート内のクエリの 99% 以上がキャッシュされた生成コードで実行され 、コンパイルの負荷は発生しません。まだキャッシュされていないクエリの場合、初回コンパイルの負荷は高速実行クエリ (ミリ秒や 1 桁秒台のクエリなど) で特に顕著で、全体の実行時間に対して大きな割合を占めることがあります。 今回の最適化により、Amazon Redshift はコンパイルの負荷を軽減します。具体的には、Amazon Redshift がクエリを受信すると、まずフリート内で過去に類似クエリを実行した際の最適化済みコンパイル済み C++ コードがキャッシュに存在するかを確認します。存在する場合は最高のパフォーマンスを得るためにそのコードを使用します。存在しない場合、Amazon Redshift は新しいクエリコンパイル最適化を適用し、コンポジションを使ってクエリを即座に処理します。コンポジションは、既存のロジックの軽量な組み合わせを生成する手法です。同時に、クエリ固有の最適化コードを作成し、利用可能なコンピューティングリソース全体でコンパイル・実行してパフォーマンスをさらに向上させます。コンポジションにより、コンパイルがクエリ実行のクリティカルパスから外れ、バックグラウンドでコンパイルが進行する間に即座に実行を開始できます。その結果、Amazon Redshift で処理される新しいクエリの開始が速くなり、2 回目以降の実行と同等のパフォーマンスが得られます。 コンポジションにより初回クエリの開始が大幅に高速化される一方、繰り返し実行されるクエリは Amazon Redshift のコード生成がもたらす優れた価格性能比の恩恵を引き続き受けられます。 重要な点として、このパフォーマンス最適化を利用するためにユーザー側の操作は不要です。Amazon Redshift が利用可能なすべての AWS リージョンにおいて、プロビジョンドクラスターまたはサーバーレスワークグループのすべてのユーザーのすべての SQL クエリにデフォルトで有効化されており、追加費用はかかりません。 実環境でのパフォーマンス結果 Amazon Redshift のお客様クラスターに対する今回の最適化の効果を分析しました。コンパイルキャッシュでキャッシュヒットせず、コンパイルが必要だった 1% のクエリセグメントのコンパイル時間を測定しました。次のグラフがその結果です。最適化前の P50 コンパイル時間は 4.3 秒でした。最適化後は 25.7 倍短縮され、170 ミリ秒になりました。 今回の最適化により、BI ダッシュボードの読み込みが速くなり、インタラクティブな探索がよりレスポンシブになり、リアルタイム分析アプリケーションがより低レイテンシーでインサイトを提供できます。 お客様の声 「FastCompile クエリパフォーマンス機能を有効にしたクラスターで、Amazon Redshift がコールドクエリ実行のパフォーマンスを大幅に改善したことを確認しました。コンパイル時間が 12 秒から 5 秒に短縮され、2.4 倍高速なクエリパフォーマンスを達成したことを受け、分析ソリューションとして Amazon Redshift を採用しました」 — Vijay Hiremath 氏 (Intuit、Group Manager、Business Platforms) 「中国の大手酒類企業のデータプラットフォームリーダーとして、エンタープライズデータウェアハウスに Amazon Redshift を活用しています。多様な分析クエリパターンがあるため、初回コンパイル時のパフォーマンスに課題がありました。Redshift の新しいコールドクエリコンパイル強化機能をテストしたところ、コールドクエリがウォームクエリとほぼ同等の速度で実行されるようになり、多様なクエリで大幅な速度改善が見られました」 — Yujie Wang 氏 (JNC、Data Platform Leader) 「約 85 GB のデータを日次で複雑な ETL パイプライン (複数テーブル、混合 DML 操作) を通じて処理し、1.7 TB の Amazon Redshift データウェアハウスに格納する中規模のお客様において、fast compile 機能の強化によりメンテナンス後の ETL パイプラインが 25% 高速化されました。データロードが早く完了し、アナリストがより迅速に意思決定できるようになりました」 — Jagan Mohan 氏 (Algonomy、Product Engineering Head) 技術の詳細については、 VLDB 2026 Boston カンファレンス に採択された論文「 FastCompose: Eliminating compilation cold starts in query execution with composition 」をご覧ください。 あらゆるワークロードに対して業界最高の価格性能比 今回の最適化の効果を示すため、業界標準の TPC-DS ベンチマークから派生したベンチマークを使用して、短時間実行の BI 型低レイテンシーワークロードをシミュレーションしました。3 ノード RG xlarge の Amazon Redshift クラスター上で、比較的小規模な 100 GB のスケールでワークロードを実行しました。このクラスターサイズとスケールでは、クエリはミリ秒から 1 桁秒台で完了し、一般的な BI ダッシュボードで期待されるレイテンシーに相当します。派生 TPC-DS ベンチマークには 99 の異なるクエリが含まれ、レポートクエリ、アドホック分析、データ探索パターンなど、現実的なビジネスインテリジェンスワークロードの組み合わせを表しています。テストでは、Amazon Redshift RG クラスターでのコールド 1 回実行と、同等の他社クラウドデータウェアハウスでの同様の実行を比較しました。ウェアハウスを起動し、データをロードし、99 クエリを 1 回実行して、合計実行時間とクエリの幾何平均を測定しました。その他のクラスターウォームアップやセットアップは行っていません。今回のクエリパフォーマンス改善はハードウェアに依存しません。Amazon Redshift でサポートされるすべてのハードウェアインスタンスタイプ (プロビジョンドクラスターの RA3 と RG、サーバーレスワークグループをサポートするハードウェア) で動作します。 結果を以下の表にまとめ、続くグラフに要約しています。今回の最適化により、Amazon Redshift は短時間クエリに対して最速の実行時間と幾何平均を最低コストで実現し、新しいクエリに対して他社の主要データウェアハウスの最大 8.3 倍の価格性能比を達成しています。 . コスト/時間 実行時間 (秒) 幾何平均 (秒) 実行時間比較 幾何平均比較 幾何平均価格性能比 Redshift 3-node RG.xlarge $2.28 235 1.7 ベースライン ベースライン ベースライン Alternative Warehouse A $3.00 327 2.3 1.4 倍遅い 1.3 倍遅い 1.7 倍高コスト Alternative Warehouse B $4.00 538 3.4 2.3 倍遅い 2 倍遅い 3.4 倍高コスト Alternative Warehouse C $6.00 907 5.5 3.9 倍遅い 3.2 倍遅い 8.3 倍高コスト まとめ Amazon Redshift の新しいクエリ起動最適化は、分析ワークロード全体にわたる高速パフォーマンスへの取り組みの一環です。コンパイルの負荷を軽減することで、BI ダッシュボードやリアルタイム分析アプリケーションのレスポンスを向上させつつ、定評のあるクエリ実行パフォーマンスを維持しています。 すべての Amazon Redshift ユーザーに自動的に有効化されているため、すぐに効果を体験できます。設定変更やクエリの書き換えは不要です。既存のクエリがそのまま高速に実行されます。 詳細については、 Amazon Redshift をご覧ください。 Amazon Redshift Serverless を使えば、データウェアハウスインフラストラクチャのセットアップや管理なしに数分でクエリを開始できます。パフォーマンスのベストプラクティスについては、 Amazon Redshift Database データベース開発者ガイド  を参照してください。 ワークロードに最適な価格性能比を見つける 本記事で使用したベンチマークは業界標準の TPC-DS ベンチマークから派生したもので、以下の特徴があります。 スキーマとデータは TPC-DS をそのまま使用しています。 クエリは TPC-DS から変更せずに使用しています。ウェアハウスがデフォルトの TPC-DS クエリの SQL 方言をサポートしていない場合は、TPC 承認済みのクエリバリエーションを使用しています。 テストには 99 の TPC-DS SELECT クエリのみが含まれます。メンテナンスとスループットのステップは含まれていません。 TPC-DS キットのデフォルトランダムシードで生成したクエリパラメーターを使用して、単一のパワーランを実行しました。単一のコールド実行の合計実行時間と幾何平均を結果として使用しています。 価格性能比は、幾何平均 (秒) を 1時間あたり 3,600 秒で除算し、ウェアハウスの時間あたりのコストを乗算して算出しています。結果はクエリあたりの幾何平均コストに相当します。すべてのデータウェアハウスで公表されているオンデマンド価格を使用しています。 Cloud Data Warehouse Benchmark と呼ぶこのベンチマークは、 GitHub で公開されているスクリプト、クエリ、データを使用して結果を再現できます。TPC-DS ベンチマークから派生したものであり、仕様に準拠していないため、公表された TPC-DS 結果とは比較できません。 ワークロードにはそれぞれ固有の特性があります。初めて検討する場合は、概念実証 (PoC) が要件に対する Amazon Redshift のパフォーマンスを理解する最良の方法です。PoC を実行する際は、適切なクラスターサイジングと適切な指標 (時間あたりのクエリ数であるクエリスループットと価格性能比) に焦点を当ててください。概念実証の 支援をリクエスト するか、 システムインテグレーションおよびコンサルティングパートナー と協力することで、データに基づいた意思決定が可能です。 Amazon Redshift の最新の開発状況を把握するには、 What’s New in Amazon Redshift の RSS フィードをご購読ください。 著者について Stefan Gromoll Amazon Redshift の Principal Engineer として、スタック全体にわたる Redshift のパフォーマンスを担当しています。余暇には料理、3 人の息子との遊び、薪割りを楽しんでいます。 Ravi Animi Redshift チームの Senior Product Management リーダーとして、Amazon Redshift クラウドデータウェアハウスサービスのパフォーマンス、クエリ処理、マテリアライズドビュー、空間分析、ストリーミング分析、移行戦略など複数の機能領域を管理しています。リレーショナルデータベース、多次元データベース、IoT テクノロジー、ストレージおよびコンピューティングインフラストラクチャサービスの豊富な経験があり、AI/ディープラーニング、コンピュータービジョン、ロボティクスを活用したスタートアップ創業者としての経験もあります。Washington Univ. St. Louis で物理学と電気工学の学士号を、Stanford で工学修士号を、Chicago Booth で MBA を取得しています。 Venkat Govindaraju Amazon Web Services (AWS Redshift) の Principal Engineer として、大規模データ管理システムの構築、最適化、スケーリングに 25 年以上の経験があります。University of Wisconsin-Madison でコンピューターサイエンスの Ph.D. を取得し、コンパイラ支援による動的ハードウェア特殊化を通じたエネルギー効率の高いコンピューティングを研究しました。分散システム、クエリエンジン、ハードウェアとソフトウェアの協調設計に精通し、VLDB、SIGMOD、MICRO、ISCA など一流会議での発表実績と複数の米国特許を保有しています。過去には Facebook、Oracle Labs、Epic Systems に在籍していました。 Kiran Chinta Amazon Redshift エンジニアリングチームの Senior Development Manager です。Amazon Redshift の主要機能を複数リードしてきた実績があります。Amazon Web Services、IBM、その他の企業でソフトウェアエンジニアリングチームをリードした豊富な経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。
本記事は 2026 年 6 月 29 日 に公開された「 Optimize your Tableau integration with Amazon Redshift Serverless 」を翻訳したものです。 本記事は、Tableau at Salesforce の Adiascar Cisneros との共著によるゲスト投稿です。 Tableau と Amazon Redshift Serverless を統合すると、サーバーレスのスケーリングと最小限のキャパシティプランニングで高性能なアナリティクスを実現できます。自動スケーリングによりウェアハウス管理は自動化されますが、最適化にはデータモデリング、セキュリティ、クエリ管理への戦略的なアプローチが必要です。 本記事では、Tableau の Relationships と Amazon Redshift Serverless アーキテクチャを活用し、すべての Redshift Processing Unit (RPU) を最大限に活かしながらサブ秒レベルのインサイトを提供する方法を解説します。具体的には、次の 5 つの領域を取り上げます。クエリパフォーマンスに最適なデータモデル設計、セキュリティ構成とアクセス制御、スマートな構成によるパフォーマンス最適化、コスト管理戦略、クエリと結合の最適化手法です。 前提条件 最適化戦略を実装する前に、以下を準備してください。 Tableau Desktop (バージョン 2022.1 以降) または Tableau Server がデプロイ済みであること。 アクティブな Amazon Redshift Serverless ワークスペースがあること。 認証とアクセス制御を構成するための AWS Identity and Access Management (IAM) 権限があること。 Tableau 環境と Amazon Redshift Serverless 間のネットワーク接続が構成済みであること。 ネイティブ Amazon Redshift ドライバーがインストール済みであること。 基盤の構築 アナリティクスシステムの成功はデータモデルから始まります。スケーラビリティの鍵はエンドユーザー体験にあります。データモデルは単なるストレージ構造ではなく、ダッシュボードの応答性の基盤です。Amazon Redshift のデータベース設計を分析要件に合わせることで、Tableau が効率的なクエリを生成できるようになり、コスト削減とユーザーのデータへのエンゲージメント向上を実現できます。 Amazon Redshift に接続する際は、Tableau の論理データモデル、具体的には Relationships の使用をお勧めします。Relationships を使用すると、各テーブルのネイティブな詳細レベルが保持されるため、Tableau は 結合カリング (join culling) を実行し、特定のビジュアライゼーションに必要なテーブルのみを動的にクエリできます。 Amazon Redshift スキーマを設計する際は、適切な場合にはスタースキーマ、スノーフレークスキーマ、または 1 つの大きな非正規化テーブルを実装します。これにより、Tableau がクエリ実行を自動的に最適化できるようになります。最新の Amazon Redshift デプロイメントでは、 Automatic Table Optimization (ATO) が大きなメリットをもたらします。ATO は AI と機械学習 (ML) を使用してソートキーとディストリビューションキーを継続的に監視・調整します。ATO を活用するには、テーブル作成時にソートキーとディストリビューションスタイルをデフォルトの AUTO 設定のままにします。ATO がワークロードパターンを継続的に監視し、クエリパフォーマンスを向上させるためにキーを調整します。 まず既存のワークブックに Relationships を実装して、 結合カリング (join culling) とクエリパフォーマンスの向上を活用しましょう。 接続のセキュリティ保護 ネイティブデータベースドライバーは、汎用の ODBC や JDBC に比べて、セキュリティ機能が強化され、Amazon Redshift の機能とより良く統合されます。 アナリティクスの信頼性は、プラットフォーム間の接続品質に依存します。汎用の ODBC や JDBC ではなく、ネイティブ Amazon Redshift ドライバーを使用してください。ネイティブドライバーは Amazon Redshift の高度な機能を活用するよう設計されており、 AWS IAM Identity Center などの最新のセキュリティプロトコルをすぐに使用できます。ネイティブドライバーを使用すれば、最新のセキュリティパッチとパフォーマンス最適化が適用された安全で効率的な接続を確立できます。詳細については、「 Integrate Tableau and Okta with Amazon Redshift using AWS IAM Identity Center 」を参照してください。 大規模環境での接続安定性 Amazon Redshift のカーソルは、結果セット全体を一度にメモリにロードせず、行単位または小さなチャンクでデータを取得する仕組みです。大規模環境では、大きな結果セットの処理方法が接続の安定性に影響します。一部の高ボリュームシナリオでは、Amazon Redshift のカーソルがリソース負荷を発生させ、ユーザーの同時実行性に影響を与えることがあります。ワークロードを監視し、必要に応じて Tableau Data Customization (TDC) ファイルを使用して接続構成を微調整します。TDC ファイルは、Tableau がデータベースに接続する方法をカスタマイズする XML 構成ファイルです。具体的には、カーソルを無効にすることでスループットが改善されるかどうかを検証してください。 重要 : この構成ではデータセット全体がメモリにロードされます。大規模なデータセットの場合、パフォーマンスの低下やメモリ不足エラーが発生する可能性があります。この設定を有効にする前に、データセットのサイズとビジネス要件を評価してください。デプロイメントのチューニングにおける重要なステップであり、Amazon Redshift のリソースがアドホック分析に対して十分な応答性を維持できるかの確認に役立ちます。 セキュリティのベストプラクティス Amazon Redshift Serverless のデプロイ時は セキュリティ のベストプラクティスに従ってください。Tableau Server および Desktop の IP 範囲からのインバウンドアクセスを制御するセキュリティグループを構成します。 IAM 認証 を主要な方法とし、すべての接続に SSL/TLS 暗号化を組み合わせます。 ロールベースのアクセス制御 (RBAC) がセキュリティフレームワークの基盤となります。 IAM ロールをデータベースユーザーにマッピングする。 データベースセキュリティコントロール を使用して Amazon Redshift で最小権限アクセスを実装する。 監査ログ で全体を監視する。 ログイン失敗の試行には Amazon CloudWatch を使用する。 AWS CloudTrail で API アクティビティを追跡する。 認可については、多層セキュリティモデルを実装します。 明示的な GRANT ステートメントを適用する。 ビジネス機能に合わせた個別のデータベースロールを作成する。 Amazon Redshift のシステム定義ロールを慎重に使用する。 機密データにはダイナミックデータマスキングを適用する。 継続的な保護を維持するため、定期的にセキュリティ監査を実施する。 現在の接続タイプを監査し、ODBC や JDBC 接続を使用している場合はネイティブ Amazon Redshift ドライバーに移行してください。 スマートな構成によるパフォーマンスの向上 スマートな構成は、クエリするデータ量、複雑なロジックの処理先、ダッシュボードの設計方法、接続のチューニング方法にわたります。以下のセクションで各領域を取り上げます。 データ量の管理 ワークブックの効率を最大化するには、まずデータ量を厳格に管理します。Amazon Redshift は大規模なデータセットを適切に処理できますが、ダッシュボードでは厳密に必要なデータのみをクエリすべきです。本番環境では Tableau Hyper Extracts を使用して、反復的なクエリ処理を Amazon Redshift からオフロードする一貫した高速キャッシュを提供します。ライブ接続が必要な場合は、Data Source Filters を使用し、未使用のフィールドをすべて非表示にして、データ取り込みを厳密に制限します。Tableau がより軽量なクエリを生成するようになり、ネットワークレイテンシーと処理時間を大幅に削減できます。 複雑な処理のデータベースへの移行 次に、複雑な処理の負担をビジュアライゼーション層から移します。エクストラクト内で計算をマテリアライズするか、複雑なロジック (特に行レベルの文字列操作や正規表現) を Amazon Redshift データベースレベルに直接プッシュダウンします。ユーザーがダッシュボードを読み込む前に値を事前計算しておくことで、実行時の高コストな処理を排除できます。 Tableau 内のロジックは、複雑な IF/THEN ステートメントの代わりに CASE ステートメントや Sets などのネイティブ機能を使用してシンプルにします。テストでは、ディメンションのグループ化に対してこれらの方法が大幅に高速であることが示されています。 ダッシュボード設計の効率化 さらに、ダッシュボード設計を効率化してレンダリングプロセスを最適化します。 ダッシュボードあたりのビジュアライゼーション数を制限する。 サーバー側キャッシュの効果を最大化するため、固定サイズのダッシュボードを優先する。 高カーディナリティフィルター (数千の一意の値を持つフィールド) を避ける。 大規模なデータセットでは「関連値のみ表示 (Show Only Relevant Values)」設定を使用しない。ダッシュボードを遅くする余計なバックグラウンドクエリが実行されるためです。 接続とパラメータのチューニング 同時接続ユーザー数に合わせた 接続プーリング を有効にして Tableau のパフォーマンスを最適化します。日時処理と並列クエリ実行の設定をワークロードパターンに合わせて構成します。 パラメータの最適化により、Amazon Redshift Serverless の自動リソース管理を強化できます。主要なパラメータは以下のとおりです。 開発中は enable_result_cache_for_session を OFF に設定し、キャッシュではなくライブクエリのパフォーマンスをテストできるようにします。本番では ON に設定します。 スパイクのあるワークロードには AI スケーリング を使用する。 キューベースのクエリリソース管理 を使用して、コンピューティング使用量を制御し、暴走クエリの影響を防止する監視ルールを設定する。 エクストラクトとライブクエリの選択は、基本的なアーキテクチャ上の決定です。一律のポリシーではなく、特定のユースケースに合わせたハイブリッドアプローチをお勧めします。 ライブクエリを使用する場合 ライブクエリはリアルタイムアナリティクスに最適です。Amazon Redshift Serverless の自動スケーリングを活用して、大規模なデータセットをその場でクエリします。次のような場合に使用します。 最新のデータが必要な場合。 エクストラクトには大きすぎるデータセット。 データベースレベルの行セキュリティが必要なシナリオ。 Amazon Simple Storage Service (Amazon S3) データに対する Amazon Redshift Spectrum との統合。 ライブ接続はデータベースのパフォーマンスに完全に依存するため、インタラクティブ性を維持するには Amazon Redshift テーブルの最適化 とデータベース内での マテリアライゼーション 手法の使用が重要です。 エクストラクトを使用する場合 データが静的な場合やクエリパフォーマンスが重要な場合、Tableau Hyper Extracts は処理負荷を Amazon Redshift から Tableau のデータエンジンに移行する高速キャッシュを提供します。これは、複雑な計算 (行レベルの文字列操作や重い集約など) を含むダッシュボードに有効で、エクストラクトが結果を事前にマテリアライズし、ユーザーがビューを読み込む前にロジックを組み込むことができます。これらの重い処理にエクストラクトを使用することで、Amazon Redshift のコンピューティング負荷を減らし、コストを削減しながらエンドユーザーにサブ秒の応答時間を提供できます。 エクストラクトの適正なサイズ設定 効率を最大化するために、ダッシュボードの特定のニーズに合わせてエクストラクトを適正なサイズに設定します。 SELECT * の考え方を避ける。 データソースにフィルターを使用して行を制限する。 未使用のフィールドを非表示にして冗長な列を削除する。 より高いレベルの分析には、エクストラクトプロセス中にデータを集約する。たとえば、日次トランザクションを月次トレンドに要約すると、ファイルサイズとクエリ時間を大幅に削減できます。 オフピーク時間にリフレッシュをスケジュールする。 インクリメンタル更新を使用して新しい行のみを追加し、Amazon Redshift の RPU 使用量とネットワーク負荷を最小化する。 パフォーマンスとコストのバランスを取るため、ビジネスのデータ鮮度要件とデータの複雑性に合わせて接続方法を選択します。使用パターンを監視し、時間の経過とともにバランスを調整してください。 スタースキーマのクエリと結合の最適化 Tableau Relationships を使用して、スタースキーマの結合とクエリを最適化し、実行時間とコンピューティングコストを削減します。Relationships はテーブルを分離したまま保持し、ビュー内のフィールドに必要なテーブルのみを Tableau が自動的にクエリできるようにします。Relationships は結合よりも柔軟で、すべてのフィールドに対して行レベルのマージを強制しないため、多くの場合パフォーマンスが向上します。 非効率な結合と最適化されていないクエリは、Amazon Redshift に不要なデータのスキャンを強制し、クエリ実行時間とコンピューティングコストの両方を増加させます。 クエリ最適化のベストプラクティス Tableau にクエリを複雑なサブセレクトでラップさせるカスタム SQL を避けてください。代わりに、テーブルやビューに直接接続して、データベースオプティマイザーが効果的に機能するようにします。 Amazon Redshift スキーマで主キーと外部キーを定義し、Tableau が参照整合性を仮定できるようにします。 重要 : Amazon Redshift は主キーや外部キーの制約を強制しません。これらは情報提供のみであり、クエリオプティマイザーがより効率的な実行プランを生成するために使用します。データの整合性はアプリケーション層または ETL 層で管理する必要があります。詳細については、「 テーブルの制約 」を参照してください。 Assume Referential Integrity は、定義されたキーリレーションシップをクエリ時に検証せずに信頼するよう Tableau に指示する設定で、クエリの複雑さを軽減します。 マテリアライズドビュー を使用して重い集約を事前計算し、頻繁にアクセスされるデータパターンの実行時間を短縮します。たとえば、一般的な日付ベースの集約やカスタマーレベルのサマリー用にマテリアライズドビューを作成します。 複雑な結合を最小化するためにデータを非正規化して Amazon Redshift Serverless を最適化します。変更を適用した後、Tableau のパフォーマンス記録を使用してクエリ速度を定期的に検証し、ボトルネックを特定してください。 コストの最適化とモニタリング Amazon Redshift Serverless は RPU 時間を秒単位 (最小 60 秒) で課金するため、実行したワークロードに対してのみ料金が発生します。 クエリ量とリソース使用量を最適化することで、Amazon Redshift Serverless のコストを制御し、予測可能な支出を維持できます。コンピューティングコストの制御には、データソースのフィルターと「未使用フィールドをすべて非表示 (Hide All Unused Fields)」を使用して、Tableau クエリが Amazon Redshift に到達する前に最適化します。必要な行と列のみをスキャンする軽量な SELECT ステートメントが生成されるようになります。Amazon Redshift Serverless はワークロードに基づいてリソースをスケールするため、Tableau ソース層でデータ量と複雑性を削減することで RPU 消費量とコストを低減できます。 詳細については、「 Amazon Redshift Serverless の課金 」を参照してください。 コストバッファーとしてのエクストラクトの使用 Tableau Hyper Extracts は、高トラフィックのダッシュボードに対するコストバッファーとして機能します。データを Tableau のインメモリエンジンに抽出することで、データベースのコストは通常、個々のユーザーインタラクションごとではなく、スケジュールされたリフレッシュ時に発生します。ライブ接続では、サーバーキャッシュポリシーを「更新頻度を下げる (Refresh less often)」に設定して Tableau のキャッシュアーキテクチャを最大限に活用し、反復的なダッシュボードビューがメモリからすぐに提供され、冗長な課金対象クエリを回避するようにします。 モニタリングとアラート RPU 使用パターンを監視し、課金アラートを設定してコスト管理を維持します。 クエリ結果のキャッシュとリソース集約型タスクの戦略的なスケジューリングを組み合わせる。 スケーリングイベントデータとクエリパターンを使用してしきい値を定義する。 RPU 消費量のスパイクに対して Amazon CloudWatch アラームを設定する。 最適化の機会を特定するため、Amazon Redshift の クエリモニタリングメトリクス を毎週確認する。 クリーンアップ 継続的な料金の発生を避けるために、本記事で説明した構成のテスト中に作成したリソースを削除してください。 テスト用に作成した Amazon Redshift Serverless のワークグループと名前空間を削除する。 Tableau 接続用に作成した IAM ロール、ポリシー、ユーザーを削除する。 Tableau Server または Desktop の IP アクセス用に構成したセキュリティグループを削除する。 テスト中に作成したマテリアライズドビュー、テーブル、スキーマを削除する。 テストワークグループに接続されたスケジュール済みの Tableau エクストラクトの更新をキャンセルする。 テスト環境を参照する Tableau データソースとワークブックを削除する。 テストリソースのモニタリング用に設定した CloudWatch アラームや CloudTrail の構成を削除する。 Amazon Redshift Serverless リソースの管理の詳細については、「 Amazon Redshift Serverless での請求 」を参照してください。 まとめ 本記事では、Tableau と Amazon Redshift Serverless の統合に関する主要な最適化戦略を取り上げました。Relationships を使用したデータモデルアーキテクチャ、ネイティブドライバーと AWS IAM によるセキュリティ構成、エクストラクトとスマートな構成によるパフォーマンス最適化、RPU モニタリングによるコスト管理、クエリ最適化手法です。 AI 駆動の最適化が進化する中、Tableau Pulse を含む Amazon Redshift の AI 機能とベストプラクティスの最新情報を把握することが重要です。Tableau と Amazon Redshift Serverless の統合がセキュアでコスト効率が高く、高パフォーマンスを維持するよう、構成、パフォーマンス、セキュリティを定期的に確認してください。 最適化は継続的で反復的なプロセスです。環境を最適な状態に保つために、設定を定期的に確認し、パフォーマンスを監視し、ワークロードパターンの変化に適応してください。組織の成長に合わせてスケールするコスト効率の高いアナリティクス環境を維持できます。 スピードとコスト効率の両方を提供するセキュアで高性能なアナリティクスソリューションを構築する準備はできましたか? Salesforce と AWS のパートナーシップ Web ページ にアクセスして、今すぐインサイトのスケーリングを始めましょう。 著者について Nidhi Nayak Nidhi は、AWS のシニアテクニカルアカウントマネージャーとして、エンタープライズのお客様がスケーラブルで高性能なクラウドアプリケーションを構築し、クラウド運用を最適化するのを支援しています。データアナリティクス分野で 10 年以上の経験があり、現在は Redshift と Redshift への生成 AI 統合に注力しています。 Nita Shah ニューヨークを拠点とする AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。20 年以上にわたりエンタープライズデータプラットフォーム、データウェアハウス、アナリティクスソリューションを構築しており、Amazon Redshift を専門としています。お客様がエンタープライズ規模の Well-Architected なアナリティクスおよび意思決定支援プラットフォームを設計・構築するのを支援しています。 Bill Tarr AWS のプリンシパルパートナーソリューションアーキテクトとして、Salesforce、MuleSoft、エージェント AI のインターオペラビリティを含むビジネスアプリケーションを専門としています。ソフトウェア開発者からアーキテクトまで、20 年以上にわたってスタートアップからエンタープライズにわたる SaaS テクノロジー戦略の経験があります。AWS re:Invent で 12 以上のセッションを発表し、「Building SaaS on AWS」を 71 エピソード制作しています。 Adiascar Cisneros Tableau at Salesforce のシニアプロダクトマネージャーです。Tableau と Amazon Web Services の技術的なリレーションシップを管理し、ロードマップの優先順位付け、コネクタの改善、カスタマーイベント、出版物の調整を担当しています。2018 年に Tableau に入社し、ジョージア州アトランタを拠点としています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。
みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 2026 年も折り返し地点を過ぎ、いよいよ下半期に入りました!上半期は生成 AI とエージェントに関するアップデートが目立ちましたが、その勢いは下半期も止まる気配がありません。今週も Claude Sonnet 5 の登場や Amazon WorkSpaces for AI agents の一般提供開始など、エージェント活用を後押しするアップデートが多数ありました。 一方で 6/30 には AWS のサービス提供状況が更新され、いくつかのサービスがメンテナンスモードやサンセット (提供終了予定) へ移行しています。本記事にて主張なアップデートとして取り上げておりますのでご確認の上、該当サービスをご利用中の方は、代替サービスへの移行計画をお早めにご検討ください。 それでは、先週の主なアップデートについて振り返っていきましょう! 2026年6月29日週の主要なアップデート 6/29(月) Amazon S3 サーバーアクセスログが Amazon CloudWatch Logs と Amazon S3 Tables への配信に対応 Amazon S3 のサーバーアクセスログを Amazon CloudWatch Logs へ直接配信できるようになりました。これにより、アクセスログデータに対する即時クエリ、アラーム、クロスアカウント/クロスリージョンの集約、AWS Key Management Service (KMS) 暗号化が利用可能になります。また、追加のストレージコストなしで Apache Iceberg 形式の Amazon S3 Tables にミラーリングすることも可能です。CloudWatch Logs への配信ではエラー率のアラーム設定やアクセスインシデントの調査などに活用できます。S3 Tables にミラーリングされたログは Amazon Athena や Amazon Redshift など Iceberg 互換のクエリエンジンから標準 SQL で即座にクエリでき、アクセスパターンの監査やコスト要因の分析に役立ちます。AWS 中国リージョンおよび AWS GovCloud (米国) を除くすべての AWS リージョンで利用可能です。 AWS WAF が Amazon Bedrock AgentCore Gateway のサポートを追加 Amazon Bedrock AgentCore Gateway 向けの AWS ウェブアプリケーションファイアウォール (AWS WAF) 保護の一般提供が発表されました。エージェンティック AI ワークロードを一般的なウェブ脆弱性や悪用から保護できるようになります。AWS WAF 保護パックを AgentCore Gateway に関連付けることで、IP ベースのアクセスコントロール、レートベースのルール、一般的なルールセット・既知の不正入力・Bot Control を含む AWS マネージドルールグループを適用できます。Gateway レベルで一度設定するだけで、その背後にあるすべてのターゲットに一貫して適用されるため、単一の設定でダウンストリームのツールやエージェント、統合をまとめて保護できるのがポイントです。AWS WAF と Amazon Bedrock AgentCore Gateway の両方が利用可能なすべての AWS リージョンで提供されます。 6/30(火) AWS のサービスおよび機能の提供状況変更のお知らせ 複数の AWS サービスおよび機能について、提供状況が更新されました。メンテナンスに移行するサービスは 2026 年 7 月 30 日以降、新規のお客様はご利用いただけません (既存のお客様は継続利用可、AWS の運用・サポートも継続)。対象は、Amazon Bedrock Agents (2023 年 11 月リリース版、Amazon Bedrock Agents Classic に名称変更)、Amazon Cognito Sync、Amazon Kendra、Amazon Q Business、AWS Directory Service – Simple AD、AWS IoT Device Defender – Detect (2026 年 8 月 31 日以降)、AWS Mainframe Modernization – Self-Managed Experience、AWS Management Console – myApplications、AWS Resource Groups – Group Lifecycle Events、AWS Service Catalog – Application Registry、AWS Systems Manager – Application Manager、Amazon SageMaker AI の A2I / Clarify / Debugger / GeoSpatial / Ground Truth / Mechanical Turk / Model Monitor / Role Manager / Studio Lab です。サンセット (提供終了予定) に移行するサービスは、Amazon WorkSpaces – PCoIP / Pool、AWS Managed Services (AMS) Advanced、AWS re:Post Private、Amazon SageMaker AI – Profiler です。2026 年 6 月 30 日をもってサポート終了となったのは、Amazon Chime SDK – Carrier Voice Focus、Amazon SageMaker AI – Ground Truth Plus です。詳細は AWS 製品ライフサイクルページをご覧ください。 Amazon SageMaker AI が Gemma 4 モデルのサーバーレスモデルカスタマイズをサポート Amazon SageMaker AI が、教師ありファインチューニング (SFT)、直接選好最適化 (DPO)、強化ファインチューニング (RFT) を用いた Gemma 4 E4B および 31B モデルのサーバーレスカスタマイズをサポートするようになりました。Gemma は Google DeepMind が構築したオープンモデルのファミリーです。今回のリリースにより、Gemma 4 を含む Nova、Nemotron 3、Qwen、Llama、gpt-oss、DeepSeek などのモデルファミリーが SageMaker AI でサーバーレスカスタマイズに利用できるラインナップに揃いました。サーバーレスカスタマイズではインフラのプロビジョニングとトレーニングのオーケストレーションを SageMaker AI が引き受けてくれるため、クラスター管理ではなくデータと評価に集中できます。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用可能です。 Claude Sonnet 5 が利用可能に AWS で Claude Sonnet 5 の提供が開始されました。Anthropic の最新世代における最初の Sonnet モデルで、Sonnet の価格帯を維持しつつコーディング・エージェント・専門業務でトップクラスのインテリジェンスを提供します。コーディングでは大規模なコードベースの複数ファイルにまたがる変更やデバッグ・リファクタリングを、エージェント用途ではツール呼び出しや多ステップの状態保持・エラー回復を、ナレッジワークではドキュメント起草や非構造化データの構造化変換をこなします。アクセス方法はAmazon Bedrock 経由での利用と Claude Platform on AWS での利用の2 種類あります。Amazon Bedrock 経由ではデータを AWS インフラストラクチャ内に保持したまま、Guardrails や Knowledge Bases、リージョンデータレジデンシーなどのマネージド機能と組み合わせて利用できます。Claude Platform on AWS では、AWS コンソールから Anthropic のネイティブプラットフォーム体験に直接アクセスでき、Anthropic と直接やり取りする場合と同じ API・機能・コンソールを AWS の請求と認証に統合された形で利用できます。 Amazon WorkSpaces for AI agents の一般提供を発表 AI エージェントがマネージド WorkSpaces 環境を通じてデスクトップアプリケーションに安全にアクセス・操作できる Amazon WorkSpaces for AI agents が、一般提供開始となりました。ERP、CRM、メインフレーム、独自ツールなど、モダナイズが難しいデスクトップアプリケーションを、アプリの改修なしにエージェントから操作できるのが特徴です。エージェントは人間のユーザーと同じ ID 制御、ネットワーク分離、コンプライアンス境界を継承するため、ガバナンスを損なわずに保険金請求処理や取引決済などのバックオフィス業務を自動化できます。Model Context Protocol (MCP) を使うあらゆるエージェントフレームワークと連携します。プレビュー期間中のフィードバックを反映し、MCP 呼び出しで直接アプリケーションや OS を操作する MCP ツールフォワーディング、オペレーターがエージェント活動をライブで可視化しセッション中のアクセスを取り消せるリアルタイムセッション制御、既存の Active Directory ID の下で動作させられるドメイン参加フリートサポートといった機能も追加されています。 7/1(水) Amazon OpenSearch Service にログ分析向けに最適化された新エンジンが登場 Amazon OpenSearch Service に、ログ分析ワークロード向けに専用設計された新エンジンが導入されました。集計ワークロード向けのカラムナーストレージにより最大 70% のストレージ削減を実現し、同じコストで最大 3 倍のデータを保持できます。加えて、同じハードウェアで最大 2 倍の取り込みスループットと 2 倍高速な分析クエリを提供します。ポイントは、OpenSearch が得意とするフルテキスト検索と、新エンジンによる高速な集計・分析クエリを同一クエリ内で組み合わせられる点で、集計とインシデント調査を 1 つのドメインで両立できます。開始するには OpenSearch 3.5 以上でドメインを作成し、オブザーバビリティのユースケースを選択、エンジンモードを optimized に設定してください。米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、カナダ (中部)、アジアパシフィック (ムンバイ、シンガポール、シドニー、東京)、欧州 (フランクフルト、アイルランド、ロンドン、スペイン) のグローバル 12 リージョンで利用可能で、新エンジンの利用に追加料金はかかりません。 AWS AppConfig が A/B テスト向けのマネージド実験ツールを提供開始 AWS AppConfig で、A/B テストや機能実験を実行できる実験ツールの一般提供が開始されました。個別の実験インフラストラクチャを構築・管理する必要なく、25 年以上にわたる Amazon の実験ベストプラクティスをベースに、AI 駆動のガイダンスで堅牢な実験の構築を支援します。UI 変更やレコメンデーションアルゴリズム、AI モデルの選択やプロンプト実験まで、アプリケーションスタック全体で A/B テストや多変量実験を実行可能で、機能バリエーションの定義やトラフィック割り当て率の設定を、AWS Management Console、CLI、API、AWS CDK から行えます。結果は Amazon CloudWatch や既存の分析ツールで分析でき、勝ちパターンは AppConfig の安全なロールアウトで本番環境へ適用できます。この機能は Amazon EC2、AWS Lambda、Amazon ECS、Amazon EKS、AWS AppConfig Agent 経由のオンプレミスサーバー上で動作します。AWS GovCloud (米国) を含むすべての AWS リージョンで利用可能です。 Amazon RDS のクロスリージョン自動バックアップが 4 つの追加 AWS リージョンで利用可能に Amazon RDS のクロスリージョン自動バックアップレプリケーションが、4 つの AWS リージョンで追加提供されました。今回のリリースで、メキシコ (中部) と欧州 (アイルランド) または米国西部 (北カリフォルニア) の間、アジアパシフィック (台北) とアジアパシフィック (シンガポール) または アジアパシフィック (東京) の間、アジアパシフィック (ニュージーランド) とアジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (メルボルン) の間、アジアパシフィック (タイ) とアジアパシフィック (シンガポール) または アジアパシフィック (ジャカルタ) の間で、自動バックアップレプリケーションを設定できるようになりました。クロスリージョン自動バックアップレプリケーションでは、RDS がスナップショットとトランザクションログを選択した送信先リージョンへレプリケートしてくれるので、プライマリリージョンが利用できなくなった場合でも、セカンダリリージョンで任意の時点に復元して迅速にオペレーションを再開できます。Amazon RDS for PostgreSQL、MariaDB、MySQL、Db2、Oracle、Microsoft SQL Server で利用できます。 7/2(木) AWS Config が 8 つの新しいリソースタイプに対応 AWS Config が、Amazon API Gateway、Amazon EC2、Amazon S3 Vectors を含む主要サービスにわたる 8 つの追加リソースタイプに対応しました。追加されたリソースタイプは、AWS::ApiGateway::DomainNameV2、AWS::ApiGatewayV2::VpcLink、AWS::EC2::VPCEncryptionControl、AWS::NetworkFirewall::ContainerAssociation、AWS::OpenSearchServerless::SecurityPolicy、AWS::OSIS::Pipeline、AWS::S3Vectors::VectorBucket、AWS::S3Vectors::VectorBucketPolicy の 8 種類です。すべてのリソースタイプの記録を有効にしている場合、これらの新規リソースは自動的に追跡されます。新しくサポートされたリソースタイプは Config ルールと Config アグリゲーターでも利用可能で、リソースが利用可能なすべての AWS リージョンで対応します。 Amazon EC2 X8i インスタンスが追加リージョンで利用可能に Amazon EC2 X8i インスタンスが、アジアパシフィック (ソウル)、アジアパシフィック (マレーシア)、アジアパシフィック (東京) の各リージョンで利用可能になりました。AWS でのみ提供されるカスタム Intel Xeon 6 プロセッサを搭載しており、クラウド上の同等 Intel プロセッサの中で最高のパフォーマンスと最速のメモリ帯域幅を提供します。前世代の X2i と比較して、最大 43% 高いパフォーマンス、1.5 倍のメモリ容量 (最大 6TB)、3.3 倍のメモリ帯域幅を実現し、SAP HANA、大規模データベース、データ分析、電子設計自動化 (EDA) などのメモリ集約型ワークロードに適しています。X2i との比較で SAPS 性能は最大 50%、PostgreSQL 性能は最大 47%、Memcached 性能は 最大 88%、AI 推論性能は 最大 46% の高速化が期待できます。large から 96xlarge まで、2 つのベアメタルオプションを含む 14 サイズで提供され、Savings Plans、オンデマンド、スポットで購入可能です。 Amazon SageMaker Unified Studio が Terraform によるプロビジョニングをサポート Amazon SageMaker Unified Studio が Terraform に対応しました。オープンソースの terraform-aws-sagemaker-unified-studio モジュールを使用して、バージョン管理されたテンプレートから SageMaker Unified Studio ドメインをデプロイできます。プラットフォームチームは、既存の Infrastructure-as-Code パイプラインに SageMaker Unified Studio を組み込むことで、開発・ステージング・本番アカウント間の一貫性を維持できます。サブモジュールにより、ブループリントの有効化、プロジェクトプロファイルへの構成、プロジェクトの独立作成が可能で、既存の IAM ロールを流用したプロジェクト作成もできます。SageMaker Unified Studio が利用可能なすべての AWS リージョンで利用できます。 それでは、また来週お会いしましょう! 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。
みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 AWS Summit Japan 2026 も大盛況のうちに終了し、いよいよ今年も後半戦ですね。各種セッションの オンデマンド視聴 環境が準備されておりますので、見逃したセッションをぜひご覧ください。 AWS の技術情報マガジン builders.flash の 7 月号が公開されました。生成 AI 関連の記事を 6 本ピックアップします。 ゴールが決まるまで笛は鳴らない ~ Kiro CLI の goal コマンドで「完了」を勝ち取る  – エージェントが検証可能な受入基準を満たすまで実装・検証・修正を自律的に反復する Kiro CLI の /goal コマンドを解説 (Physical AI を) やらないか 〜 ACT 学習 & 動作検証編  – オープンソースロボットアーム SO-101 を Amazon SageMaker AI 上で ACT(模倣学習)させる実験記 AWS Lambda durable functions と AI Agent で勉強会資料作成を任せてみた(株式会社ウェザーニューズ様) – AWS Lambda durable functions と Amazon Bedrock AgentCore Runtime で資料作成を自動化する Bot の構築事例 Slack から日程調整 URL を丸投げできる AI エージェントを構築してみよう!  – Strands Agents SDK と Amazon Bedrock AgentCore のブラウザツールを使ったハンズオン AI エージェントに DJ と VJ パフォーマンスをさせてみた。  – AWS Summit Japan 2026 の Builders Fair 展示「DJ Agent」の技術解説 モダナイズ対象のメインフレームコードベースを AWS Transform for mainframe で確立する  – 欠落ファイルの検出・補完を反復する実践記事 どれも手を動かして試せる内容になっていますので、気になるテーマがあればぜひご覧ください。 それでは、6 月 29 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース 接客スキルの属人化に悩む企業へ ― プリモグローバルホールディングス様、Amazon Bedrock で AI ロールプレイ研修を導入 プリモグローバルホールディングス様は、ブライダルジュエリーの企画・販売を手がける企業です。接客スキルが担当者ごとに大きく異なり、教育にかかる工数も大きな負担となっていました。これを解決するために、複数の LLM を使い分けながら音声認識と連携し、接客ロールプレイに対して AI がフィードバックを返す研修プログラムを Amazon Bedrock を活用して構築しました。その結果、6 回以上利用した従業員の満足度が 91% を超える結果となっています。今後は 2026 年 4 月から新入社員研修への本格活用を予定しているそうです。 株式会社ラクス様、伝票作成 AI エージェントの構築と、品質を支える評価設計の取り組み 株式会社ラクス様は、「楽楽精算」などの SaaS を提供する IT サービス企業です。経費精算業務では伝票作成が手作業に依存しており、担当者の負荷が課題でした。これを解決するために、Amazon Bedrock を中心とした伝票作成 AI エージェントを構築し、AWS Generative AI Innovation Center と協業してオフライン・オンライン双方の評価設計を整えました。その結果、品質を維持しながらエージェントをリリースできる体制が整ったそうです。今後はエピソード記憶を活用した自己改善ループの実現を目指しています。 ITbook 株式会社様の AWS 生成 AI 活用事例:提案書のドラフト作成を十日から半日に短縮 ITbook 株式会社様は、自治体・国向けのコンサルティングを行う企業です。要件文書からの提案書作成には約 10 日かかっており、担当者の負荷が課題でした。これを解決するために、Amazon Bedrock AgentCore Runtime / Gateway と Amazon OpenSearch Service によるベクトル検索を組み合わせ、要件抽出・アウトライン作成・本文生成を段階的に行う仕組み(Human-in-the-loop)を構築しました。その結果、提案書のドラフト作成期間を半日に短縮し、担当者が思考に使える時間を 2 倍以上に増やすことができたそうです。今後は民間企業への展開も検討しています。 AWS Local Executive Roadshow 博多編: 株式会社オーレックホールディングス様、生成 AI 利用禁止から全社員の 4 割が活用する組織へ 株式会社オーレックホールディングス様は、福岡県に拠点を置く従業員 580 名の農業機械メーカーです。当初は情報漏えいなどのリスクを懸念して生成 AI の利用を禁止していましたが、方針を転換し、AWS のオープンソースソリューション「Generative AI Use Cases JP(GenU)」を導入しました。その結果、全社員の約 40%(200 名)が日常的に利用するまでに広がり、特許調査や法令チェックといった専門業務への活用にも広がっているそうです。禁止から活用への転換プロセスが語られている開催レポートです。 ブログ記事「【開催報告 & 資料公開】公共分野における AI 活用最新アップデート」を公開 2026 年 4 月 28 日に開催された AWS 公共セミナーの開催報告です。デジタル庁の対話型検索システム「源内」や国土交通省の「RAPID」、つくば市、品川区、藤田医科大学、東北大学、東京科学大学の Swallow プロジェクトなど、Amazon Bedrock や Amazon Bedrock AgentCore、Amazon SageMaker HyperPod、Kiro を活用した公共分野 8 事例が一挙に紹介されています。公共機関における生成 AI 活用の最前線を知りたい方におすすめです。 【ブース展示報告】AWS Summit Japan 2026 不動産ブース 不動産業の未来を、生成 AI で切り拓く この記事では、AWS Summit Japan 2026 の不動産ブースで展示された 4 つの生成 AI ソリューションを、開発・流通・管理・可視化の視点から紹介しています。都市分析を行う AI エージェントや AI コンシェルジュ、施設管理向けデジタルツイン、Amazon Quick を使ったデータ可視化など、Amazon Bedrock AgentCore や Amazon Connect Customer AI Agents を活用した展示の様子がまとめられています。 ブログ記事「Kiro とともに医療情報システムのガイドライン遵守開発に挑む」を公開 医療情報システムの開発では、多数の業界ガイドラインへの準拠が求められます。この記事では、AI を活用した IDE である Kiro に業界知識(Agent Skills)と開発標準(Agent Steering)を教え込み、いわば「チームの一員」として育てていくアプローチを、企画・準備・開発・改善の 4 フェーズに分けて解説しています。規制の厳しい業界で AI コーディングエージェントを活用したい方の参考になる内容です。 ブログ記事「Kiro Web が GitLab と GitHub をまたぐ変更を 1 セッションで調整」を公開 ブラウザで動作する Kiro Web が GitLab に対応し、GitHub と GitLab のリポジトリを同一セッションにアタッチして、1 回の指示でそれぞれにマージリクエストとプルリクエストを生成できるようになりました。合わせて、新しい実験的ビュー「 Agent Focus 」も紹介されており、エージェントパネル・チャットパネル・補助パネルの 3 パネル構成でチャットファーストな作業ができるようになっています。複数のリポジトリをまたいだ開発をされている方は要チェックです。 ブログ記事「Kiro で OpenAPI / Swagger 仕様からテストスイートを数秒で生成する」を公開 この記事では、Kiro に OpenAPI / Swagger 仕様を渡すだけで、axios や Express モックを使った Node.js のテストスイートを数秒で生成する手法を紹介しています。単純なコード生成ツールとの違いとして、削除のライフサイクル検証や認証への対応、CI/CD 上でのヘッドレスな再生成まで踏み込んで解説されており、API テストの自動化を検討している方の参考になります。 サービスアップデート Claude Sonnet 5 が AWS で利用可能に Anthropic の Claude Sonnet 5 が、Amazon Bedrock と Claude Platform on AWS の両方で利用可能になりました。前世代の Sonnet 4.6 から性能が大幅に向上し、コーディングや長時間のエージェント型タスクにおいて上位モデルの Opus 4.8 に迫る性能を、Sonnet の価格帯で利用できます。日々の開発ワークロードのコストパフォーマンスを重視する方におすすめのアップデートです。 AWS WAF が Amazon Bedrock AgentCore Gateway のサポートを追加 AWS WAF が Amazon Bedrock AgentCore Gateway をサポートし、一般提供が開始されました。これにより、エージェント型 AI ワークロードが受け取るリクエストに対しても、Web アプリケーションと同様の脆弱性対策を適用できるようになります。エージェントを本番運用する上でのセキュリティ境界を強化したい方に有用な機能です。 Amazon Bedrock AgentCore が 4 つの追加リージョンで利用可能に、デフォルトのランタイムクォータも増加 Amazon Bedrock AgentCore が、アジアパシフィック(バンコク)、アジアパシフィック(マレーシア)、欧州(ミラノ)、欧州(スペイン)の 4 リージョンで新たに利用可能になりました。あわせて、デフォルトのランタイムクォータも引き上げられ、最大 5,000 の同時セッションを申請なしで利用できるようになっています。グローバルにエージェントを展開したい方、大規模なトラフィックを見込んでいる方の両方にとって嬉しいアップデートです。 Amazon SageMaker AI が Gemma 4 のサーバーレスモデルカスタマイズに対応 Amazon SageMaker AI が、Google DeepMind のオープンウェイトモデル Gemma 4(E4B / 31B)のサーバーレスなモデルカスタマイズに対応しました。インフラのプロビジョニングやクラスター管理を SageMaker AI に任せながら、独自データでのファインチューニングが行えます。アジアパシフィック(東京)を含むリージョンで利用可能です。 Amazon SageMaker AI のコンテナイメージキャッシュで、スケールアウト時間を最大半減 Amazon SageMaker AI の推論エンドポイントに、コンテナイメージのキャッシュ機能が追加されました。スケールアウト時にコンテナイメージのダウンロードを待つ時間を短縮でき、最大で半分程度まで起動時間を削減できます。トラフィックの急増に合わせて推論インフラを素早く拡張したい方に嬉しいアップデートです。 Amazon SageMaker Unified Studio が Terraform でのプロビジョニングに対応 Amazon SageMaker Unified Studio のプロジェクトやドメインを、Terraform を使ってコードとして管理・プロビジョニングできるようになりました。手動でのコンソール操作に代えて、IaC(Infrastructure as Code)の運用フローに組み込むことができます。データ基盤の構築を Terraform で統一的に管理しているチームにとって嬉しい機能です。 Claude Sonnet 5 が Kiro で利用可能に AI を活用した IDE である Kiro で、Anthropic の Claude Sonnet 5 が利用可能になりました。Claude Sonnet 4.6 から大幅に強化され、Sonnet の価格帯で上位モデル Opus 4.8 に近い性能を発揮します。米国東部(バージニア北部)と欧州(フランクフルト)から段階的に展開され、1M トークンのコンテキストウィンドウにも対応しています。 Kiro IDE v1.0.89 が公開 Kiro IDE の最新バージョン v1.0.89 が公開されました。セッションの自動復元やアイドル時のリソース消費削減が行われ、プリペイドのクレジットパックの残量をダッシュボードで確認できるようになりました。あわせて権限管理・hooks・steering に関する不具合修正も含まれています。 Kiro の従量課金(overage)対策が強化 Kiro で、従量課金(overage)の予測しづらさに対応する機能が追加されました。チーム向けには AWS Service Quotas 経由でのキャップ設定が可能になり、管理者が Kiro プロファイルごとの overage 上限を制御できます。個人向けには クレジットパックの事前購入が追加され、1 クレジット 0.04 ドルから 5 ドル〜100 ドルのパックを購入できます(最大 5 パックまで保有可能、有効期限 12 カ月)。予算管理をしながら Kiro を使いたい方に嬉しいアップデートです。 AWS Security Hub CSPM が AI Security のベストプラクティス標準を発表 AWS Security Hub CSPM に、AI Security Best Practices 標準が追加されました。Amazon Bedrock や Amazon SageMaker AI などの AI ワークロードを対象とした 31 のセキュリティコントロールが含まれており、設定の不備を継続的にチェックできます。AI ワークロードのセキュリティ体制を可視化したい方に役立つアップデートです。 Amazon WorkSpaces for AI agents が一般提供開始 Amazon WorkSpaces for AI agents が一般提供開始されました。AI エージェントが Model Context Protocol(MCP)を通じて仮想デスクトップ上のアプリケーションを操作できるようになる機能で、レガシーなデスクトップアプリケーションを含む既存のワークフローを自動化したい場合に活用できます。GUI 操作しか手段がない業務にエージェントを組み込みたい方におすすめです。 AWS Security Agent がアジアパシフィックの複数リージョンで利用可能に AWS Security Agent が、アジアパシフィック(ムンバイ)、アジアパシフィック(シンガポール)、南米(サンパウロ)の各リージョンで利用可能になりました。Kiro や Claude Code と連携したセキュリティレビュー機能も含まれており、開発フローの中でセキュリティチェックを組み込みたいチームにとって選択肢が広がるアップデートです。 生成 AI を活用したビジネス変革に取り組むお客様を支援する 生成 AI 実用化推進プログラム は引き続き参加企業を募集しています。ご興味のある方はぜひご覧ください。 今週は以上です。それでは、また来週お会いしましょう! 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。 a
本ブログは 2026 年 6 月 30 日に公開された AWS Blog “ Safely Releasing Frontier Models to Customers ” を翻訳したものです。 AWS は、あらゆるワークロードを実行する場所として最も安全であることを目指しています。その実現のために、20 年以上前の創業以来、AWS はサービス全体にわたるセキュリティに深く投資してきました。Amazon Bedrock のような AI サービスも、この基盤の上に同じ姿勢で構築されています。Amazon Bedrock は、世界トップクラスのパフォーマンス、セキュリティ、プライバシーに加え、どこよりも幅広いモデルの選択肢をお客様に提供しています。昨年、AWS は 業界をリードするプライバシー とモデルの重みの保護を備えた Bedrock Mantle を発表しました。お客様からは、モデルのリリース後できるだけ早く最新モデルを利用したいという声を日頃からいただいており、Amazon Bedrock はお客様が AWS に期待するエンタープライズ機能とともにこれを実現しています。このたび、Anthropic の Claude Fable 5 モデルが、悪用を防ぐためのさらに強力なガードレールを備えて Amazon Bedrock 上で再びお客様にご利用いただけるようになりました。 モデルをリリースする際、AWS はお客様に対する責任だけでなく、インターネットと社会全体に対する責任も考慮しています。Anthropic の Claude Mythos のような最新世代のフロンティアモデルは、特にサイバーセキュリティの分野で強力な新機能を備えています。AWS は Project Glasswing の取り組みを通じてこれを直接体験しており、Mythos クラスのモデルを防御側に届けたいと強く考えています。防御側がこれらのモデルを活用すれば、私たち全員が依存するシステムのセキュリティを大幅に向上させることができます。しかしその一方で、企業、政府、学術機関が自らの資産を守る態勢を整える前に、攻撃者に著しく高度な洞察力や能力を与えてしまうことは避けなければなりません。このバランスを取ることは、モデルを広くリリースするうえでの重要な課題です。そのため AWS は、Project Glasswing において Anthropic をはじめとする業界パートナーと緊密に連携し、この新しいクラスのモデルに対するガードレールの改善に取り組んできました。攻撃者が高度な脆弱性調査を行う能力を手に入れることを防ぐことが、これらのガードレールの最も重要な目的であるという点で、私たちの認識は一致しています。 AI は今、エキサイティングな時代を迎えており、ほぼ毎日のように新しい機能が登場しています。これらの高度なモデルの能力を、安全でプライバシーを保護する環境ですべてのお客様が利用できるようにすることは、セキュリティリスクを生み出すことなく多くのメリットを享受するために不可欠だと AWS は考えています。現在のガードレールの効果についての知見が深まり、新しいモデルがリリースされるのに合わせて、新たなガードレールを継続的に開発していくことが重要です。AWS はパートナーとともに改善を重ね、より多くの価値を提供し、業界の変化に対応していきます。 これらのモデルのリリース後に問題が発生した場合、それが適切に対処されるようにすることも同様に重要です。Anthropic はブログ「 Redeploying Fable 5 」を公開し、この新しいクラスのモデルの能力に対する考え方と、報告された問題に対応するためのコミットメントおよび SLA (サービスレベルアグリーメント) について説明しています。サイバー能力を持つモデルに対する問題の重大度と対応の最初の枠組みを明確にした Anthropic の透明性と協力に感謝するとともに、私たちが学びを深めてこの枠組みを改善していくなかで、業界全体での対話が続いていくことを期待しています。 AWS の AI Red Team は Anthropic と協力して Fable の保護機能をさらに改善しました。最新のガードレールにより、非常に高い能力を維持しながら、攻撃者による悪用リスクをさらに最小限に抑えたモデルが実現していると考えています。このモデルは、攻撃者に大きな新しいセキュリティ能力を与えることなく、ほとんどの分野で大幅に強化された推論能力を発揮します。ガードレールが作動した場合は、すでに一般公開されている世界トップクラスのモデルである Opus 4.8 に自動的にフォールバックします。 Anthropic のパートナーシップと防御側へのコミットメントに感謝するとともに、今後も Anthropic および業界全体と協力して、フロンティアモデルを安全かつセキュアに提供し続けられることを楽しみにしています。 著者について Amy Herzog Amy Herzog は Amazon Web Services (AWS) のバイスプレジデント兼最高情報セキュリティ責任者 (CISO) であり、セキュリティを最優先事項とする同社において、クラウドセキュリティの専門家からなるグローバルな組織を率いています。AWS に加わる前は、Amazon の Devices and Services、Media and Entertainment、Advertising の各事業の CISO を務め、Alexa+ や Ring などのコンシューマー向けテクノロジー製品のセキュリティを統括するとともに、低軌道衛星を通じて世界中のお客様やコミュニティに高速で信頼性の高いブロードバンドを提供する Amazon の取り組みである Project Kuiper のセキュアな開発においても重要な役割を果たしました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。
本記事は 2026 年 7 月 1 日に公開された “ Announcing Amazon EKS Rollback for safe and reliable management of cluster upgrades ” を翻訳したものです。 本日、 Amazon EKS バージョンロールバック を発表します。これは、クラスター管理者が Amazon Elastic Kubernetes Service (Amazon EKS) クラスターにおける Kubernetes バージョンのアップグレードを安全にロールバックできる新機能です。この機能により、追加のセーフティネットを備えた状態で EKS フリート全体に新しいバージョンのアップグレードを自信を持って展開できるようになりました。 Kubernetes は年間 3 つのマイナーバージョンというリリースサイクルにより、セキュリティと機能を維持するためにクラスターを定期的にアップグレードする必要があります。しかし、Kubernetes のバージョンアップグレードは必ずしも容易ではありません。新しいバージョンでは、機能の追加、API の非推奨化、内部コンポーネントの変更など、既存のアプリケーションに影響を与える可能性のある変更が導入されることがよくあります。オープンソースの Kubernetes は、その設計上、アップグレード完了後に Kubernetes コントロールプレーンをロールバックする機能を備えていません。ネイティブなロールバックの手段がないため、多くの組織はコストのかかる緩和戦略を採用してきました。これには、インフラストラクチャコストが 2 倍になるブルー / グリーンデプロイメントや、多大なエンジニアリング時間を消費するクラスター状態の手動スナップショットが含まれ、いずれもネイティブには存在しなかったセーフティネットを構築するためのものでした。 Amazon EKS バージョンロールバックにより、アップグレード後に問題を発見した場合、Kubernetes コントロールプレーンを既知の正常な状態へ安全に戻せるようになりました。EKS Auto Mode を使用しているクラスターの場合、ロールバック機能はデータプレーンにも及び、クラスター全体にわたる包括的な保護を提供します。この機能は 2 つの重要なメリットをもたらします。1 つ目は、本番環境のアップグレードに信頼性の高いセーフティネットを提供し、災害復旧計画に関する規制要件を満たす手段を提供することです。2 つ目は、ロールバックによって遅延の理由がなくなるため、セキュリティ体制を強化するより迅速なアップグレードをサポートすることです。その結果、チームはプロアクティブにアップグレードを行い、既知の CVE を含むバージョンを実行する時間を短縮し、サポートされ積極的にパッチが適用されたソフトウェアを要求するフレームワークへのコンプライアンスを維持できます。アップグレードを元に戻す手段を提供することで、EKS バージョンロールバックは運用の信頼性を維持しながら、最新の Kubernetes リリースへの追従を支援します。 EKS バージョンロールバックの仕組み バージョンロールバックにより、プラットフォームエンジニアやクラスター管理者は、インプレースアップグレードのためのセーフティネットを手に入れます。アップグレード後に問題が発生した場合、7 日以内にクラスターを以前の Kubernetes バージョンに戻すことができます。EKS は Amazon EKS ロールバックインサイトを使用して、以前のバージョンとの互換性についてクラスターを自動的にスキャンし、ロールバックの安全性に影響を与える可能性がある問題を表面化させます。 ロールバックをトリガーすると、EKS は以下を含む包括的な安全性チェックを実行します。 API 互換性 : リソースが使用する API が以前のバージョンと互換性があることを検証します。 API フィールドの変更 : バージョン間での互換性のない API フィールドの使用をチェックします。 クラスターの健全性 : ロールバックの成功を妨げる健全性の問題がないことを検証します。 Kubelet バージョンスキュー : ワーカーノードが Kubernetes バージョンスキューポリシーに準拠していることを検証します。 Kube-proxy 互換性 : kube-proxy バージョンの互換性を検証します。 アドオンバージョン : インストールされている EKS アドオンがターゲットバージョンと互換性があることをチェックします。 EKS Auto Mode におけるロールバック 前述のセクションで説明したロールバックの動作は、標準的な EKS クラスターに適用されます。また、 Amazon EKS Auto Mode を使用しているクラスターでは、これがさらに強化されたものになります。EKS Auto Mode は、コンピューティング、ネットワーキング、ストレージを含むインフラストラクチャを組み込みのベストプラクティスで自動的に管理することで、クラスター運用を簡素化します。 Auto Mode 対応クラスター でコントロールプレーンのロールバックを開始すると、EKS はまず Auto Mode ワーカーノードを自動的にロールバックし、その後コントロールプレーンのロールバックを続行します。これにより、ロールバックプロセス全体を通じて Kubernetes バージョンスキューポリシーへの準拠が検証されます。 ロールバックは、実行中のワークロードへの影響を最小限に抑えるため、NodePool disruption budgets や PodDisruptionBudgets (PDBs) を含む、設定された disruption budgets を遵守します。 --force フラグは EKS ロールバックインサイト の警告をバイパスし、潜在的な互換性の問題が検出された場合でもロールバックを続行します。ただし、 --force は disruption budgets やポッドレベルの中断制御を上書きしません。これらは、ワークロードの可用性を維持するため、ロールバックプロセス全体を通じて引き続き遵守されます。 EKS Auto Mode クラスターの場合、バージョンロールバックは以下を検証します。 NodePool disruption budgets – Karpenter の disruption budgets がドリフトベースのノード置換を許可し、ノードの中断を無期限にブロックするように設定されていないことを検証します。 Pod disruption アノテーション – ロールバック中のノード終了を遅延させる可能性がある karpenter.sh/do-not-disrupt アノテーションを持つポッドをチェックします。 PodDisruptionBudgets (PDBs) – PDBs が十分なポッドの退避を許可し、ノードの中断をブロックするような形で誤って設定されていないこと (例: maxUnavailable: 0) を検証します。 Node disruption アノテーション – ロールバック中のノード置換を妨げる karpenter.sh/do-not-disrupt アノテーションを持つノードを特定します。 これらの検証は、ロールバックを開始する前に潜在的なブロッカーを特定することで、データプレーンのロールバックがスムーズに進行できることを確認するのに役立ち、自動化されたノード置換プロセスを遅延または妨げる可能性のある設定を可視化します。 ロールバックが予想より長くかかっている場合や、別のアプローチで問題に対処することを決定した場合は、 CancelUpdate API を使用して進行中のロールバックをキャンセルできます。これは、ロールバックの完了を待つのではなく修正を前進させて適用したい場合や、進行中のロールバック操作によって別の重要な更新がブロックされている場合に便利です。この機能は Auto Mode のロールバックでのみ利用可能です。ノードのロールバックフェーズは長時間実行される操作になる可能性があるためです (保守的な disruption budgets の場合は最大 7 日間)。Auto Mode を使用しない標準クラスターはロールバックを迅速に完了し、キャンセル可能なフェーズはありません。 ロールバックをキャンセルするには、cancel-update API を呼び出します。 aws eks cancel-update \ --name my-cluster \ --update-id <update-id> \ --region <aws-region> キャンセル後、クラスターはロールバックが開始された時点のバージョンで ACTIVE 状態に戻り、次の操作に進むことができます。 ロールバック中のスケーリング Amazon EKS は、バージョンロールバックの進行中であっても、ワークロードの需要に応じてクラスターの応答性を維持します。EKS はクラスターの同時更新をサポートしていませんが、アクティブなロールバック操作中も、必要に応じてクラスターのコントロールプレーンのスケーリングを継続します。これは、ロールバックの期間中にクラスターの API サーバーの負荷が増加した場合、EKS が需要に対応するためコントロールプレーンのインフラストラクチャを自動的にスケーリングすることを意味します。バージョンの復元が処理されている間、ワークロードは影響を受けません。 Amazon EKS バージョンロールバックの始め方 ロールバックを開始するには、既存の UpdateClusterVersion API、AWS Command Line Interface (AWS CLI)、Amazon EKS コンソール、またはその他の任意のツールを使用できます。 AWS CLI を使用する ロールバックプロセスでは、アップグレードに使用するものと同じ API を使用しますが、以前のバージョンを指定します。 # バージョン 1.33 から 1.32 にロールバック aws eks update-cluster-version \ --name my-cluster \ --kubernetes-version 1.32 ロールバックを開始する前に、EKS クラスターインサイトで ロールバックインサイト を確認してください。 # ロールバックインサイトの一覧を取得 aws eks list-insights \ --cluster-name my-cluster \ --filter category=ROLLBACK_READINESS # 特定のインサイトの詳細情報を取得 aws eks describe-insight \ --cluster-name my-cluster \ --id <insight-id> クラスターインサイトがエラー (ERROR ステータス) を報告した場合は、ロールバックを続行する前にそれらの問題を解決する必要があります。PASSING、WARNING、または UNKNOWN ステータスのインサイトはロールバックをブロックしません。 Amazon EKS コンソールを使用する Amazon EKS コンソールで、以下の操作を行います。 クラスターに移動し、 Actions メニューを選択します。 ロールバッククラスターバージョン を選択します。 ロールバックインサイト を確認して、ブロックする問題がないか特定します。 ターゲットバージョンを選択し、 Initiate rollback を選択します。 ロールバックアクションを確認します。 Salesforce における EKS ロールバック導入の歩み Amazon EKS は、EKS クラスター向けの Kubernetes バージョンロールバックを導入しました。この機能により、クラスター管理者は、インプレースアップグレードの完了後の任意の時点で、コントロールプレーンのアップグレードを以前のマイナーバージョンに戻すことができます。この機能は、アップグレードプロセスで長らく有効な手立てがなかった重大なリスクを根本から解消します。 ロールバック適用の前提条件 ロールバック機能の最も重要な前提条件は、コントロールプレーンとデータプレーン (kubelet) の間のバージョン関係です。ノードの kubelet がアップグレードされたバージョン (N+1) にリサイクルされた後、コントロールプレーンを元に戻すには、対応するデータプレーンのロールバックが必要です。 これにより、現在のアップグレードパイプラインへの直接的な依存関係が生じます。そのパイプラインは、ステージ間のベイク期間なしに、コントロールプレーン、アドオン、データプレーンを単一の連続した実行で進めます。 したがって、コントロールプレーンとデータプレーンのアップグレードを明確に分離することが、ロールバック機能を有意義に活用するための前提条件となります。 推奨プロセス:コントロールプレーンのベイク期間を設けた段階的アップグレード ロールバックの期間を維持し、アップグレード後のリグレッションの範囲を縮小するために、アップグレードシーケンスを次のように再構成することをお勧めします。 アドオンのアップグレード – マネージドアドオンを、N-1、N、N+1 の K8s バージョンと相互に互換性のあるバージョンにアップグレードします。これにより、アドオンがロールバックまたはアップグレードのいずれかのブロック要因にならないことを検証します。 コントロールプレーンのアップグレードとベイク – コントロールプレーンをターゲットバージョンにアップグレードし、環境ごとに約 1 週間のベイク期間を設けます。この期間により、データプレーンが新しいバージョンにアップグレードされる前に、コントロールプレーンのリグレッションを早期に検出できます。 データプレーンのアップグレード – ベイク期間の後、ノードのリサイクルを進めて kubelet をターゲットバージョンにアップグレードします。 注意 : サイクルの早い段階でリグレッションを表面化させるため、コントロールプレーンとデータプレーンのバージョンを一致させた初期検証の実施をお勧めします。 推奨されるシーケンスは、コントロールプレーンのアップグレード、次に 1 週間のベイク期間、続いてデータプレーンのアップグレード (ノードの入れ替え) です。 データプレーンのアップグレード中または後にリグレッションが特定された場合は、以下のようになります。 データプレーンのリグレッションのみ: ワーカーノードを N-1 の kubelet にロールバックします。コントロールプレーンは N のままです。 コントロールプレーンとデータプレーンの両方のリグレッション: まずデータプレーンをロールバックし (kubelet を N-1 に戻す)、その後コントロールプレーンのロールバックを開始します。 メリット: このアプローチにより、フリート全体で迅速なコントロールプレーンの展開が可能になり (コントロールプレーンのアップグレードは高速)、EKS 拡張サポート料金の発生を抑えることができます。 これにより、ベイク期間中もロールバックの期間が開いたままになり、インシデント対応がより迅速かつ低リスクになります。 トレードオフ: フリートで完全なアップグレードサイクル (コントロールプレーン + データプレーン) の実施完了に時間がかかります。 シナリオ例 シナリオ 1: 問題が検出されないクリーンなロールバック クラスターが 1.30 から 1.31 にアップグレードされました。ロールバックインサイトはすべて PASSING を示しています。管理者がロールバックを開始します。 aws eks update-cluster-version --name my-cluster --kubernetes-version 1.30 # Returns InProgress VersionRollback update シナリオ 2: インサイトエラーによってロールバックがブロックされる クラスターが 1.30 から 1.31 にアップグレードされました。データプレーンのノードはすでに kubelet 1.31 にリサイクルされています。ロールバックインサイトは kubelet/kube-proxy のバージョンスキューについて ERROR を示しています。 解決策: 影響を受けるノードを 1.30 の kubelet にリサイクルして戻し、kube-proxy を互換性のあるバージョンにロールバックし、インサイトを更新してからロールバックを再試行します。 シナリオ 3: 複数バージョンのロールバックを試みる クラスターが 1.29 から 1.30、そして 1.31 にアップグレードされ、その後 1.30 にロールバックされました。管理者が 1.29 へのロールバックを試みます。 aws eks update-cluster-version --name my-cluster --kubernetes-version 1.29 # Error: The cluster cannot be rolled back to the Kubernetes version specified. # You can only rollback by 1 version. ロールバックインサイトの対象範囲 ロールバックインサイトは EKS マネージドアドオン (coredns、VPC CNI、kube-proxy) をチェックします。cluster-autoscaler のようなセルフマネージドアドオンは自動的にはチェックされません。Salesforce では、ロールバックのターゲットバージョンとのセルフマネージドアドオンの互換性について、独自の検証を維持する必要があります。 当社の Kubernetes アップグレードプロセスは、さまざまなバージョンにわたる複数のアップグレードサイクルを経て、広範な検証、ベイク期間、自動化されたサインオフ、段階的な本番展開を備えた厳格な多段階プログラムへと構築されてきました。これらすべては、1 つの根本的な制限を補うために設計されたものでした。それは、 EKS がコントロールプレーンのロールバックをサポートしていなかった ことです。 EKS バージョンロールバックのローンチは、Kubernetes アップグレードのリスクの捉え方・考え方を根本的に変えます。 本番環境のアップグレードのための真のセーフティネット — いずれかの段階的ロールアウトの各グループでアップグレード後の問題が表面化した場合でも、ロールバックはもはや選択肢から外れることはありません。 フリート全体でのより迅速なコントロールプレーンの展開 — コントロールプレーンとデータプレーンのアップグレードをベイク期間で分離することにより、チームはフリート全体でコントロールプレーンのバージョンを迅速に進めることができ、拡張サポート料金が発生するリスクを軽減します。 規制リスクの低減 — 規制対象のワークロードでは、文書化されテストされたロールバックの手段が、災害復旧計画のコンプライアンス要件に対応します。 この機能を最大限に活用するには、対象を絞ったパイプラインの変更を行う必要があります。すなわち、コントロールプレーンとデータプレーンの展開の分離、コントロールプレーンとデータプレーンにおけるアップグレードステージ間のベイク期間の導入、そしてロールバックインサイトの統合と適切なガードレールを備えたロールバック専用パイプラインの構築です。 当社の既存のアップグレードの厳格さと EKS バージョンロールバックのサポートを組み合わせることで、チームは大規模なクラスターフリート全体をより高い信頼性と縮小された影響範囲でアップグレードできる態勢が整います。 考慮事項 この機能に関する主要な考慮事項は以下のとおりです。 ロールバックの範囲 – バージョンロールバックは、1 つの Kubernetes マイナーバージョン (N から N-1) のロールバックをサポートします。複数バージョンのロールバックは現在サポートされていません。クラスターがインプレースアップグレードを通じて現在のバージョンにアップグレードされた場合にのみロールバックできます。バージョン N で作成されたクラスターは N-1 にロールバックできません。 サポートされるバージョン – バージョンロールバックは、現在サポートされている EKS バージョンで利用できます。これにより、ローンチ時点で現在サポートされているすべての EKS バージョンでのロールバックサポートが検証されます。 ロールバックの期間とタイムアウト – 以前のバージョンが EKS によってサポートされ続けている限り、アップグレード完了後 7 日以内であれば、いつでもロールバックを開始できます。ただし、新しいバージョンの新しい API や機能を利用する変更を加えた場合は、ロールバックする前にそれらの変更を元に戻す必要があります。 デフォルトでは、EKS はロールバック操作を失敗と見なす前に、完了までに最大 7 日間を許可します。さらに、ロールバックの準備状況を評価するのに役立つロールバックインサイトは、アップグレード後 7 日間のみ利用可能であるため、その期間内に評価して対応することが重要です。ただし、AWS CloudFormation や Terraform (それぞれ 36 時間および 24 時間の独自の操作タイムアウトを適用します) のような infrastructure-as-code (IaC) ツールを使用してクラスターを管理している場合、7 日間のロールバック期間が自動化パイプラインとの競合を引き起こす可能性があります。 これに対処するために、ロールバックリクエストでカスタムの timeoutMinutes を指定して、EKS が操作を失敗させる前にロールバックを試みる最大時間を定義できます。これにより、EKS のロールバック動作を IaC ツールのタイムアウト設定に合わせることができます。 aws eks update-cluster-version \ --name my-cluster \ --kubernetes-version 1.32 \ --rollback-config timeoutMinutes=1440 拡張サポート – 拡張サポート対象のバージョンにロールバックすると、クラスターに拡張サポート料金が発生し始めます。標準サポート対象のバージョンに再度アップグレードすると、拡張サポート料金は停止します。 ワーカーノードのロールバック – Auto Mode クラスターの場合、EKS はワーカーノードのロールバックを自動的に管理します。Managed Node Groups の場合は、 UpdateNodegroupVersion API を使用してワーカーノードをロールバックします。セルフマネージドノードおよびハイブリッドノードは、お客様が手動でロールバックする必要があります。 Fargate : バージョンロールバックは AWS Fargate ワーカーノードではサポートされていません。Fargate ベースのクラスターのコントロールプレーンはロールバックできますが、ロールバック前のコントロールプレーンと同じ Kubernetes バージョンを実行している Fargate ポッドは、ERROR ステータスの kubelet バージョンスキューインサイトをトリガーします。これは、基盤となるインフラストラクチャが API サーバーとは独立した kubelet バージョンのダウングレードをサポートしていないために発生します。これを回避するには、ロールバックを開始する前に影響を受ける Fargate ポッドを削除するか、 --force を使用してインサイトチェックをバイパスします。そうすれば、コントロールプレーンのロールバックが完了すると、新しいポッドがロールバックされたバージョンで起動します。 アドオンの互換性 – UpdateAddon API または EKS コンソールを通じて希望するアドオンバージョンを指定することで、EKS アドオンを手動でロールバックできます。クラスターインサイトは、ロールバックの安全性に影響を与える可能性のあるアドオン互換性の問題を特定します。 安全性チェック – EKS ロールバックインサイトは、ロールバックを許可する前に、API 互換性、feature gate 互換性、バージョンスキューポリシーを含む複数の安全性チェック項目に照らしてクラスターを自動的に検証します。ロールバックを続行する前に、すべてのエラーを解決する必要があります。EKS アップグレードインサイトは、標準的な Kubernetes および EKS コンポーネントの既知の互換性チェックをカバーしていることに注意することが重要です。カスタムアドオン、カスタムビルドされた AMI、または特注の設定については、アップグレード前にお客様の責任で検証する必要があります。さらに、バージョンロールバックは、日常的なアップグレードワークフローとしてではなく、アップグレード後の問題に対するセーフティネットとして設計されています。アップグレードインサイトが評価する内容の詳細については、 EKS クラスターインサイトのドキュメント を参照してください。 今すぐご利用いただけます Amazon EKS バージョンロールバックは、Amazon EKS が利用可能なすべての AWS リージョンで利用できるようになりました。リージョンごとの提供状況については、AWS リージョン別サービスページをご覧ください。 バージョンロールバックの使用に追加料金はかかりません。 詳細は、Amazon EKS ユーザーガイドの Amazon EKS バージョンロールバックのドキュメント をご覧ください。 Amazon EKS コンソールでぜひお試しいただき、AWS re:Post for EKS または通常の AWS サポート窓口を通じてフィードバックをお寄せください。 翻訳者について 小西 杏典 (Kyosuke Konishi) 2025 年に Amazon Web Services Japan に新卒入社したソリューションアーキテクトです。 好きなサービスは Amazon EKS と Kiro CLI であり、業務のかたわら OSS への貢献など 開発活動にも日々取り組んでいます。 ・X : https://x.com/_konippi
このブログは、東海旅客鉄道株式会社(以下、JR 東海)中央新幹線推進本部 リニア開発部 藤原 海渡氏と、アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションマネージャー 西部 信博、プロフェッショナルサービス本部 正村 雄介、森田 和真による共著です。 1. はじめに JR 東海では、中央新幹線の保守・運用として、山梨リニア線において超電導リニアの電気設備保守の省力化・高度化を進めています。本活動の一環として、状態監視保全(Condition Based Maintenance、以下 CBM)の実現を目的に、AWS 上に IoT プラットフォームを段階的に構築してきました。機械学習の運用(MLOps)も IoT と切り離さず、この IoT プラットフォームの中に統合する方針としています。変電所・開閉所・トンネル区間など設置環境が多様な拠点に、エッジコンピュータやセンサデバイスといった種類の異なる IoT 機器が分散して設置される中で、構成情報を継続的に把握し遠隔から運用していくことが、保守業務の品質を左右する重要なテーマになっています。 本記事では、IoT プラットフォームの概要と構築にあたっての工夫点や得られた知見についてご紹介します。 2. 全体像 2-1. 本システムで実現したいこと(論理アーキテクチャ) IoT プラットフォームで実現したいのは、現地に出向かなくても設備の状態をデータで捉え続けることです。具体的には、次の能力を備えることを目指しました。 機器のメーター情報をデジタル化して取り込み 動作音や電流値をもとにした設備状態の数値化 メーター情報や各種計測情報を統合した状態把握 2-2. 構築した AWS アーキテクチャ(物理アーキテクチャ) 電気設備保守における IoT プラットフォームでは、多様な拠点に設置された IoT デバイスから設備のデータを取得し、エッジで処理した結果と必要なデータのみをクラウドに連携する構成としています。 エッジとクラウドにまたがる IoT システムでは、現場での即時処理とクラウドでの一元管理を両立させる構成が鍵になります。本アーキテクチャでは、 AWS IoT Greengrass がエッジ側の処理ランタイムとして現場固有の推論・前処理を担い、 AWS IoT Core がそのエッジとクラウドをつなぐ通信のハブとなります。クラウド側では AWS IoT SiteWise が設備データをモデル化して時系列で管理し、 Amazon SageMaker AI がエッジ推論向けの異常検知モデルの学習を担います。これらのマネージドサービスを組み合わせることで、通信・運用基盤そのものの開発を最小化し、設備保守の本質的な作り込みに集中できる構成になっています。 この IoT プラットフォームの設計思想は、「処理はできる限りエッジに寄せ、設備も機器も同じ階層モデルで構造化し、その構成を一元的に運用し続ける」 という点に集約されます。以降の 3 つの工夫は、いずれもこの思想を具体化したものです。 3. 工夫①:エッジ処理を中心とした状態監視システムの構築 実装に落とすうえで、まず向き合ったのがデータ取得と通信の制約です。電気設備の状態を正しく捉えるには高いサンプリングデータ・カメラ画像・動作音などが必要ですが、これらをそのままクラウドへ転送すると、通信回線の制約・通信コスト・クラウド側の処理負荷のいずれもが課題となります。 通信量の最適化(3-1)とエッジでの機械学習推論(3-2)という 2 つのアプローチで、この課題に取り組みました。 3-1. エッジ処理と通信量の最適化 Greengrass のコンポーネントとして、カメラ画像からのメーター値読み取り、動作音の特徴量抽出、機械学習モデルによる異常推論などを実装し、クラウドには集計値・推論結果と必要最小限の分析用データだけを送る構成としています。 また、標準コンポーネントに加え、現場固有の処理(カメラ機種ごとの画像切り出しやノイズ除去など)をプライベートコンポーネントとして実装することで、デバイスや設置環境ごとに柔軟な処理を実現しました。 3-2. 機械学習モデルの構築とエッジへのデプロイ 状態監視の中核は、設備の異常検知モデルをエッジ上で推論実行することです。モデルを Amazon SageMaker AI で学習・構築し、オープンソースの ONNX (Open Neural Network Exchange)形式へ変換したうえで、 Greengrass コンポーネントとしてエッジにデプロイしています。これによりモデルを軽量化し、計算資源の限られたエッジコンピュータ上でも無理なく推論を実行できる構成を実現しました。 4. 工夫②:多様な拠点・設備・機器のモデル化 中央新幹線では、監視対象となる拠点・設備が多様であり、それを監視するエッジ構成(IoT 機器やネットワーク)もまた多様になります。そこで 、これらの多様な設備や機器群を共通の構造(モデル)に落とし込み、保守員が一貫した方法で管理できるようにすることを目指しました。 4-1. 拠点・設備のモデル化 拠点・設備は、 AWS IoT SiteWise の Asset Model を活用し、「エリア」→「拠点」→「設備」という階層構造でモデル化しています。これにより、保守員は監視ダッシュボード上で拠点や設備種別を横断して状態を俯瞰したり、特定の設備にドリルダウンしたりといった操作を、共通の枠組みで行えるようになりました。 4-2. エッジ構成のモデル化 エッジ構成は、ネットワーク機器・コンピュータ・センサといった種別に分類したうえで、各機器のハードウェア構成(CPU・メモリや、NIC・USB などの外部接続インターフェース)を共通の属性としてモデル化しています。ネットワーク構成についても、NIC や USB を介した機器間の接続関係としてモデル化し、物理配置は階層的な属性(エリア/拠点/ゾーン/フロア/詳細位置)として表現しています。 5. 工夫③:IoT 機器と機械学習モデルの一元管理・自動運用 拠点とデバイスの数が増えるにつれ、運用上の最大の課題となったのが、モデル化した構成を実体に合わせて正確に把握し続けることです。 以下のようなオペレーションを行うには、正確な構成情報が不可欠です。 ソフトウェアの一括更新 機器のリプレース IP アドレス管理 新規拠点の構築 こうした情報を台帳と現場の作業記録に頼って管理すると、機器が増えるほど負担も増し、台帳と実機の乖離も広がっていきます。そこで 、これらの構成情報を一元管理する仕組みを新たに構築しました。 5-1. 構成情報の自動収集と一元管理 IoT 機器の構成を、実値で最新化し続ける仕組みとして IoT 構成管理システムを構築しました。エッジの構成情報を自動で集約し、機器の物理配置情報も紐付けることで、一元管理を実現しました。 IoT 構成管理システムのアーキテクチャ IoT 構成管理システムは Web アプリケーションとして実装しました。バックエンドは AWS AppSync による GraphQL API と Amazon DynamoDB で構成し、フロントエンドは Next.js で実装して AWS Amplify Hosting でホスティングしています。サーバーレスのマネージドサービスと、Next.js をはじめとする既成のフレームワーク・コンポーネントを最大限に活用したことで、少ない実装コストで素早く立ち上げられました。インフラの運用負荷を抑えられる点も、少人数での継続運用に寄与しています。 エッジ構成の自動収集 構成管理で主となる課題は、機器の構成を実体に合わせて常に同期し続けることです。OS バージョン、 Greengrass の外で動くネイティブアプリケーション、ネットワーク情報まで含めてエッジの構成全体を収集対象としたのが特徴です。これらを集める「構成情報収集機能」を Greengrass コンポーネントとして実装し、 AWS IoT Core 経由でクラウドへ送信して構成管理データベースを定期的に最新化することで、エッジの構成を一元的に把握できるようにしました。これにより、保守員は台帳と実機の乖離を心配することなく運用できます。 5-2. 機械学習モデルのビルド自動化と運用効率化 電気設備の異常検知では、設置環境によってデータの特性が異なるため、設備ごとに特化したモデルの方が精度を得やすい一方、運用面では多数のモデルのライフサイクル管理が新たな課題となります。 そこで 、 Amazon SageMaker Pipelines による学習パイプラインと、 AWS Step Functions による Greengrass コンポーネントへのビルドパイプラインを組み合わせ、学習から配信までの各作業を自動化しています。学習 – ONNX 化 – コンポーネント化 – 配信までを一連の流れとしてスムーズに回せるようにしました。 また、学習済みモデル自体を Greengrass コンポーネントとして扱うことで、IoT 機器のソフトウェア構成管理の枠組みにそのまま乗せられるようにし、IoT と機械学習を別管理にしない運用を実現しています。 6. Professional Services との伴走による内製化の推進 本取り組みは、リニア開発部と AWS Professional Services が伴走する形で進めてきました。週次のスプリントで要件整理・設計・プロト開発・QA を協働で行うことで、リニア開発部のメンバーが IoT・機械学習・Web アプリケーションそれぞれの実装ノウハウを段階的に獲得することができ、開発スピードと内製化の両立につながっています。 リニア開発部自身が運用と改善を主導できる体制を作るうえで、伴走型の開発スタイルは非常に有効でした。 7. まとめ JR 東海では、中央新幹線の将来運用を見据えた電気設備保守の高度化に向け、IoT プラットフォームを段階的に構築・拡充してきました。この取り組みは、次の 3 つの柱に支えられています。 エッジ処理を中心とした状態監視システムの構築(通信量最適化+エッジでの機械学習推論) 多様な拠点・設備・機器のモデル化(設備データ+機器/ネットワーク/接続関係) IoT 機器と機械学習モデルの一元管理・自動運用(構成管理+MLOps) 今後は、将来の営業線運用に向けて、生成 AI を活用した開発・運用ナレッジの継承支援機能追加を検討しています。IoT と機械学習を横断する高度な専門知識を組織に定着させ、現場作業や障害対応の場面で必要なナレッジに素早くアクセスできる環境を整えることを目指しています。 おわりに 本ブログでご紹介した JR 東海の取り組みや関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について 東海旅客鉄道株式会社 藤原 海渡 (Kaito Fujiwara) 中央新幹線推進本部 リニア開発部 在来線の電気設備保守、リニア電気設備の運用・保守・開発、営業線システムの検討を経て、現在は AWS を活用した IoT プラットフォームと MLOps の推進を担当しています。 アマゾン ウェブ サービス ジャパン合同会社 西部 信博 (Nobuhiro Nishibe) カスタマーソリューションマネージャー カスタマーソリューションマネージャーとして、エンタープライズのお客様を中心に、技術・非技術問わずクラウドジャーニーにおける課題の特定から解決までをご支援しています。好きな AWS サービスは Kiro と AWS IoT シリーズです。 正村 雄介 (Yusuke Shomura) プロフェッショナルサービス本部 IoT コンサルタントとして、製造業や鉄道事業者のお客様を中心に、IoT・生成 AI を活用したシステムの構築をご支援しています。通信分野の研究者を経て AWS に入社しました(工学博士)。好きな AWS サービスは AWS IoT Core と Amazon Bedrock です。趣味は読書とコーヒーです。 森田 和真 (Kazuma Morita) プロフェッショナルサービス本部 アソシエイトデリバリコンサルタントとして、金融や鉄道事業者のお客様をはじめとして、クラウド基盤・生成 AI 基盤に関連したご支援を中心に行っています。好きな AWS サービスは Kiro と Amazon Bedrock AgentCore です。
こんにちは。アマゾン ウェブ サービス ジャパン合同会社 パートナー ソリューション アーキテクト の深井宣之です。 2026 年 4 月 28 日に「公共分野における AI 活用最新アップデート」と題した Webinar を開催しました。本ブログでは開催内容について Blog にまとめたものになります。投影資料もダウンロードすることが可能です。 本セッションでは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 CSM・プロトタイプ・パートナー ソリューション技術本部 本部長の高田 智己が登壇し、生成 AI の最新トレンドとして「チャットボット + RAG」の時代から「Agentic AI」の時代への移行を解説しました。AWS が提供する AI サービスの全体像を紹介したうえで、中央省庁・地方自治体・ヘルスケア・大学など公共分野における生成 AI 活用の最新ユースケースを多数紹介しました。 セッション概要 資料(PDF)の ダウンロードはこちら から可能です。 生成 AI の最新トレンド ― Agentic AI 時代へ 2022 年末に ChatGPT が登場して以降、生成 AI や RAG(検索拡張生成)が注目を集めてきました。しかし 2025 年 3 月頃からは「AI 駆動開発」「MCP(AI と既存システム連携)」「AI エージェント」といったキーワードが中心となり、AI エージェントが気軽に使える状況が整ってきています。 生成 AI はシンプルなコンテンツ生成を行う「アシスタント」から、単一ゴールを自律的に達成する「生成 AI エージェント」、そしてワークフロー全体を完全自動化する「Agentic AI システム」へと進化しています。Amazon 自身も Alexa+ や代理購買サービス「Buy For Me」など、多くのプロダクトで AI エージェントを活用しています。 AWS の提供する生成 AI サービス AWS では 3 層の AI サービスポートフォリオを用意しています。 AI モデルを作りたい方向け : AWS Trainium / Inferentia によるカスタムチップ、Amazon SageMaker HyperPod などのインフラストラクチャ AI エージェントを作りたい方向け : Amazon Bedrock(基盤モデルへの API アクセス)、Amazon Bedrock Agents、Amazon Bedrock AgentCore、Strands Agents などのフレームワーク すぐに使える AI エージェント : Kiro(AI 統合開発環境)、Amazon Quick Suite、AWS Transform、Amazon Connect など Amazon Bedrock Amazon Bedrock は東京リージョンを含む複数のリージョンで一般提供されている、基盤モデルを活用した生成 AI アプリケーションの構築サービスです。Anthropic の Claude シリーズをはじめ幅広いモデルを利用でき、データプライバシーの観点ではお客様のデータが他のお客様のために使用されることはなく、日本国内クロスリージョン推論もサポートされています。 Amazon Bedrock AgentCore AI エージェントの大規模かつ安全なデプロイ・運用を実現するプラットフォームです。認証・認可(Identity)、ツール管理(Gateway)、実行環境(Browser / Code Interpreter)、セッション記憶管理(Memory)、運用監視(Observability)などの機能を提供し、お客様は AI エージェントのコア開発に集中できます。 AI コーディングエージェント AWS が提供する AI コーディングエージェントとして、生成 AI 統合開発環境の Kiro と、Anthropic 社の Claude Code を Amazon Bedrock 上で利用する方法を紹介しました。Kiro では仕様駆動開発によりプロトタイプからプロダクションまでを支援し、レガシーアプリケーション(Delphi/Pascal)の解析とモダン化にも活用できることをデモで示しました。 公共分野における生成 AI 活用の最新ユースケース 本セッションの後半では、公共分野における生成 AI 活用の最新ユースケースとして、以下の事例が紹介されました。 事例 1: デジタル庁 ― ガバメント AI「源内」 デジタル庁では、政府職員の業務効率化のために生成 AI 検証アプリ「源内(ゲンナイ)」を AWS 上に構築しました。GenU(Generative AI Use Cases)をベースに開発されており、機密性 2 情報の利用が可能です。2025 年 5 月にデジタル庁職員向けにリリースされ、2026 年 1 月から一部省庁で試験的利用を開始。2026 年度には全府省庁約 18 万人の政府職員が生成 AI を活用する大規模実証事業が予定されています。 なお、源内のベースとなっている GenU は AWS Japan の有志チームが開発したオープンソースの生成 AI アプリケーションで、チャット・翻訳・文書校正・要約など業務で活用できるユースケースを提供しており、1,000 を超えるお客様での利用実績があります。 事例 2: 国土交通省 ― AI 書類審査ソリューション「RAPID」 2025 年 4 月の改正建築基準法施行により 2 階建て木造住宅等も審査対象に追加され、審査機関の業務負荷が急増しました。国土交通省では、AWS プロトタイプチームが開発したオープンソースの AI 書類審査ソリューション「RAPID(Review & Assessment Powered by Intelligent Documentation)」を活用し、日本建築防災協会が提供する「建築確認申請図書作成支援サービス」を開発。OSS の活用により開発 2 か月でサービスをリリースし、申請補正指示案件の削減による審査業務負荷軽減が期待されています。 事例 3: つくば市 ― 相談業務効率化 つくば市では、ひとり親支援担当部署において相談記録のテキスト量が多く、転出時の要約資料作成に苦労していました。この課題に対し、GenU をベースにしたソリューションをガバメントクラウド上に構築し、生成 AI による相談記録の要約を実現。大量のケース記録から簡潔な要約を自動生成することで、転入先自治体への情報共有やケース会議での検討を効率化しています。 事例 4: 品川区 ― AI エージェントを活用した問合せ対応自動化 品川区では、人口増加に伴う住民ニーズの多様化や全国的な労働力不足、電話対応業務の負荷増大に課題を抱えていました。Amazon Connect と Amazon Bedrock を活用した AI 自動応答システムの実証実験を実施し、FAQ への自動応答、適切な部署へのルーティング、24 時間対応、必要に応じたオペレーターへのエスカレーションを実現。待ち時間短縮と住民満足度向上、職員の業務負荷軽減、持続可能な行政運営の実現を目指しています。 事例 5: 藤田医科大学 ― 退院時サマリー作成補助 藤田医科大学では、医師や医療従事者が業務時間の多くを文書作成に費やしており、退院時サマリー作成には 1 患者あたり 10〜15 分を要していました。Amazon Bedrock を活用したプロトタイピングプログラムにより、電子カルテ記事を元にサマリー生成の精度を 1 か月で検証。医師作成のサマリーに対し 9 割以上で整合性が取れることを確認し、10 分程度の作成作業が数秒で下書き完成に短縮されました。現在は 31 診療科に展開されています。 事例 6: ソフトウェア・サービス ― 電子カルテシステムへの生成 AI 活用 株式会社ソフトウェア・サービスでは、医師の 52.9% が週 60 時間超勤務、看護師の 7 割が時間外勤務という医療現場の深刻な業務負担に着目し、Amazon Bedrock を活用して電子カルテシステムに生成 AI を連携させました。その結果、サマリー作成時間 50% 削減、心理的負担 70% 低下を実現しています。 事例 7: 東北大学 ― 教職員向け生成 AI アプリ 東北大学では、2020 年に DX 推進チームを発足し、全国の大学に先駆けて生成 AI を導入してきました。GenU をカスタマイズし、チャット・文書作成・議事録作成などの AI ユースケースを全教職員向けに提供しています。検討から 1 か月で内製構築しサービスを開始。会議議事録作成時間が 1/4 に短縮され、ランニングコストも従来の 1/3 に抑えられています。 事例 8: 東京科学大学 ― 日本語大規模言語モデル Swallow の開発 東京科学大学(東京医科歯科大学と東京工業大学が 2024 年 10 月に統合)では、年度末までに大規模言語モデルの継続事前学習を完了させる必要があり、大規模並列の学習用計算環境が求められていました。Amazon SageMaker HyperPod を用いて ml.p5.48xlarge / ml.p5en.48xlarge の学習環境を数時間で構築し、FSx for Lustre と S3 を連携。GPT-4o に匹敵する高性能な日本語大規模言語モデル「Swallow」最新版(Llama-3.3-Swallow-70B 等)のリリースに貢献しました。 おわりに AWS では AI モデルを作りたいお客様へのインフラ提供から、AI エージェントを作りたいお客様へのサービス・フレームワーク提供、そしてすぐに AI エージェントを使いたいお客様向けのサービスまで、多くの選択肢を提供しています。デジタル庁の源内をはじめ、国土交通省、つくば市、品川区、藤田医科大学、東北大学、東京科学大学など、公共分野でも幅広く AWS の生成 AI サービスが活用されています。 本セッションでご紹介した AWS のサービスやソリューションにご興味がありましたら、御社担当の Partner Account Manager にお気軽にご連絡ください。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パートナー ソリューション アーキテクト 深井宣之が執筆しました。
Kubernetes コントロールプレーンのアップグレードは、長い間、一度行うと元に戻せないものでした。オープンソースの Kubernetes はコントロールプレーンのロールバックをサポートしていないため、一度アップグレードしたら後戻りはできません。コミュニティはここまで大きな進歩を遂げており、 KEP-4330 ではロールバックを容易にするためにエミュレートされたバージョンが導入されています。しかし実際には、この制約により、組織はベイク期間、スタッガーグループ、自動サインオフ、数か月にわたるアップグレードサイクルなど、精巧な補償メカニズムを構築する必要に迫られています。Kubernetes は年に 3 つのマイナーバージョンをリリースしているため、特に規制の厳しい環境では、何百ものクラスターを管理しているチームは、何か問題が発生した場合に回復できる自信がないために、アップグレードを完全に延期することがよくあります。その結果、クラスターは古いバージョンで行き詰まり、セキュリティパッチが適用されず、最終的にはサポート期間の延長に直面することになります。 2026 年 7 月 1 日、 Amazon Elastic Kubernetes Service (Amazon EKS) の Kubernetes バージョンロールバック についてお知らせします。これは、クラスター管理者がクラスターのアップグレードを実行する際のセーフティネットを提供する新機能です。バージョンロールバックを使用すると、アップグレード後に問題が発生した場合に 7 日以内に Kubernetes バージョンのアップグレードを取り消して、クラスターを以前の動作状態に戻すことができます。 エミュレートされたバージョンのようなアプローチではクラスターが過渡的な保持状態に保たれるのに対し、EKS バージョンロールバックはクラスターをエミュレートしたものではなく、本番環境で実行されていた完全に検証済みの以前のバージョンに戻します。これで、クラスターを例えば Kubernetes 1.34 から 1.35 にアップグレードして互換性の問題が見つかった場合、7 日以内に 1.34 にロールバックできます。クラスターを再構築したり、プレッシャーのかかる状況でトラブルシューティングを急いだりする必要はありません。Kubernetes のバージョンアップグレードの [元に戻す] ボタンと考えてください。 この機能は、EKS がアップグレードに使用するのと同じインクリメンタルアプローチに合わせて、一度に 1 つのマイナーバージョンにロールバックすることをサポートします。また、安全にロールバックできるように、EKS は クラスターインサイト を通じてクラスターのロールバック準備状況を自動的に評価し、処理を進める前にノードバージョンの互換性やアドオンの依存関係などの項目にフラグを付けます。状況をすでに評価していて、迅速に行動したい場合は、 --force フラグを使用してこれらのチェックをバイパスできます。上記は、独自のノードを管理する場合でも、AWS に処理させる場合でも、すべての EKS クラスターに適用されます。しかし、フルマネージドインフラストラクチャを採用しているお客様にとっては、ロールバックはさらに一歩進んだものです。 EKS Auto Mode のロールバック EKS Auto Mode では、本番環境に対応した Kubernetes クラスターをワンクリックでデプロイし、コンピューティング、ネットワーキング、ストレージの管理を自動化できるため、インフラストラクチャではなくアプリケーションに集中できます。EKS Auto Mode では、コントロールプレーンとマネージドノードの両方を同時にロールバックする必要があるため、 バージョンロールバック に関する追加の考慮事項があります。ノードのロールバックはポッドの中断バジェットを考慮しているため、設定によってはプロセスに時間がかかる場合があります。 このプロセスを制御できるように、どの時点でもノードのロールバックを停止できる キャンセル API を導入しました。ロールバックに時間がかかりすぎると判断した場合、またはアプローチを変更したい場合は、キャンセルして中断バジェットを調整して物事を加速させるか、別の今後の進め方を選択することができます。 デフォルトでは、EKS はワークロードの安定性を優先するため、ロールバック中に中断バジェットをバイパスすることはありません。必要に応じていつでも中断バジェットを自分で変更したり削除したりして、プロセスをスピードアップできます。 試してみましょう バージョンロールバックを試すために、Amazon EKS コンソールに移動し、最近アップグレードした私のクラスターの 1 つを選択しました。 クラスターの設定ページから、バージョンロールバックを開始するオプションと、現在のロールバックウィンドウに関する情報が表示されます。 ロールバックを開始する前に、ロールバックのインサイトを確認して、潜在的な問題がないかどうかを確認しました。インサイトにより、私のノードの状態がわかり、先に進む前に対処すべき点にフラグが付けられました。 確認後、ロールバックが開始されました。私のクラスターはプロセス全体を通して機能し続けました。コントロールプレーンのロールバックには、標準のアップグレードと同様に約 20 分かかりました。私の EKS Auto Mode クラスターでは、中断バジェット設定に従ってノードが正常にロールバックされました。 完了すると、私のクラスターは前の Kubernetes バージョンに戻り、期待どおりに動作しました。 今すぐご利用いただけます Amazon EKS の Kubernetes バージョンロールバック は、Amazon EKS が利用可能なすべての商用 AWS リージョンで、追加料金なしで今すぐご利用いただけます。通常発生する標準の EKS とコンピューティングコストのみをお支払いいただきます。ロールバック機能を使用しても、追加料金は発生しません。 コントロールプレーンのロールバックはすべての EKS クラスターで使用でき、ノードのロールバックは EKS Auto Mode を実行しているクラスターで使用できます。バージョンロールバックは、EKS 標準サポートと延長サポートで利用可能な Kubernetes バージョンを実行しているクラスターをサポートします。 開始するには、 Amazon EKS のドキュメント を参照するか、 Amazon EKS コンソール で直接試してみてください。 原文は こちら です。
2026 年 6 月 30 日、 AWS CloudFormation Express モードについてお知らせします。これは、インフラストラクチャで反復処理を行う開発者および AI ツールのデプロイを加速化する新しいデプロイモードです。Express モードは、CloudFormation がリソース設定の適用を確認したときに完了することで、長期にわたる安定化チェックを待機することなく、デプロイを加速化します。これにより、反復型の開発ワークフローと本番稼働シナリオのデプロイ時間が最大で 4 倍短縮されます。 仕組み すべての CloudFormation デプロイは、リソース設定が適用された後に安定化チェックを実行します。これらのチェックは、負荷をシフトする前にリソースがトラフィックを処理できることを確認する必要がある場合に重要な役割を果たします。 ただし、多くのワークフローでは、先に進むために完全な安定化は必要ありません。Express モードは、反復型の開発ワークフローと、最終的に安定化することを許容できる本番稼働シナリオという主要な 2 つのユースケースに役立ちます。これらのユースケースには、開発中のインフラストラクチャ設定での反復処理、アプリケーションの個々のコンポーネントのテスト、1 分未満のフィードバックループの恩恵を受ける AI 支援インフラストラクチャ開発などがあります。 Express モードでは、CloudFormation はリソース設定が適用されると、安定化チェックを待機せずに、デプロイを完了します。リソースは引き続きバックグラウンドで稼働するようになります。CloudFormation は、同じスタック内のプロビジョニング中に一時的な障害が発生した依存リソースを、顧客の介入なしに自動的に再試行します。この組み込みレジリエンスは、リソースが安定するまでのタイミングの問題に対処します。Express モードは、リソースがプロビジョニングされる 方法 ではなく、デプロイが完了する タイミング を変更します。 例えば、デッドレターキュー (DLQ) を含む Amazon Simple Queue Service (SQS) キューを作成すると、Standard モードでは 64 秒かかりますが、Express モードでは最長 10 秒で完了します。ネットワークインターフェイスアタッチメントがある AWS Lambda 関数を削除する場合、Standard モードでは 20〜30分 かかりますが、ベンチマークテストによると、Express モードでは最長 10 秒で完了します。 CloudFormation Express モードを開始する AWS マネジメントコンソール で CloudFormation スタックを作成するときに、 スタックデプロイオプション の [ Express モード ] で [ 有効化 ] を選択します。 また、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、または AWS Cloud Development Kit (CDK) などの IaC ツール、および Kiro などの AI ツールを使用することもできます。 スタックの作成、更新、削除時に --deployment-config パラメータを EXPRESS に設定して、Express モードを有効にします。テンプレートを変更する必要はありません。Express モードではデフォルトでロールバックが無効になっているため、イテレーションが最も速くなります。ロールバックを再度有効にするには、本番環境の deployment-config で disableRollback を false に設定するか、失敗したデプロイの監視/クリーンアップメカニズムを実装します。 aws cloudformation create-stack \ --stack-name my-app \ --template-body file://template.yaml \ --deployment-config '{"mode": "EXPRESS", "disableRollback": true}' \ 例えば、インフラストラクチャを段階的に構築し、リソースを 1 つずつ追加する場合は、Express モードを使用します。IAM ロールテンプレートが最小特権の原則に従っていることを確認してください。 # イテレーション 1: IAM ロールをデプロイする aws cloudformation create-stack \ --stack-name my-microservice \ --template-body file://iteration1-iam.yaml \ --deployment-config '{"mode": "EXPRESS"}' \ --capabilities CAPABILITY_IAM --role-arn arn:aws:iam::123456789012:role/CloudFormationDeployRole # イテレーション 2: Lambda 関数を追加する aws cloudformation update-stack \ --stack-name my-microservice \ --template-body file://iteration2-lambda.yaml \ --deployment-config '{"mode": "EXPRESS"}' \ --capabilities CAPABILITY_IAM --role-arn arn:aws:iam::123456789012:role/CloudFormationDeployRole # イテレーション 3: SQS キューとイベントソースマッピングを追加する aws cloudformation update-stack \ --stack-name my-microservice \ --template-body file://iteration3-sqs.yaml \ --deployment-config '{"mode": "EXPRESS"}' \ --capabilities CAPABILITY_IAM --role-arn arn:aws:iam::123456789012:role/CloudFormationDeployRole AWS CDK では、CDK スタックをデプロイするときに cdk deploy --express コマンドを使用して Express モードを有効にします。このコマンドは、生成された CloudFormation テンプレートを取得し、CloudFormation Express モードを介してデプロイします。このモードでは、CloudFormation スタックの一部としてリソースがプロビジョニングされます。 Express モードは、既存のすべての CloudFormation テンプレートで動作し、変更セットやネストされたスタックを含むすべての CloudFormation 機能をサポートします。親スタックで Express モードを有効にすると、ネストされたすべてのスタックも Express モードを使用します。トラフィックまたはテストに進む前にリソースを完全に動作させる必要がある場合は、完了前に安定化チェックを実行するデフォルトのデプロイ動作を引き続き使用してください。 今すぐご利用いただけます AWS CloudFormation Express モードは現在、すべての AWS 商用リージョンで追加料金なしでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 リージョン別の AWS 機能 」にアクセスしてください。API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP サーバー と プラグイン を使用してみてください。詳細については、 CloudFormation のドキュメント をご覧ください。 今すぐデプロイを加速させてください。また、フィードバックを AWS re:Post for AWS CloudFormation に送信するか、通常の AWS サポートの連絡先を通じて送信してください。 – Channy 原文は こちら です。
本記事は 2025 年 9 月 22 日 に公開された「 A scalable, elastic database and search solution for 1B+ vectors built on LanceDB and Amazon S3 」を翻訳したものです。 この記事は Metagenomi の Owen Janson、Audra Devoto、Christopher Brown との共著です。 CRISPR によるゲノム編集から産業用バイオ触媒まで、酵素はヘルスケア、エネルギー、製造業における変革的な技術を支えています。しかし、ゲノム工学における Cas9 のように産業を変えるような新規酵素を発見するには、生命の系統樹にまたがる膨大な生物がコードする数十億種類の酵素を探索しなければなりません。DNA シーケンシングとメタゲノミクスの進歩により既知のタンパク質配列を格納した大規模な公開・独自データベースが構築されてきましたが、そこから価値の高い候補を見つけ出すのは生物学の問題であると同時にビッグデータの問題でもあります。 Metagenomi では、独自の大規模メタゲノミクスデータベース (MGXdb) を活用し、新規遺伝子編集システムのツールボックスを構築することで、根治的な治療法の開発に取り組んでいます。この記事では、Metagenomi が Amazon Web Services (AWS) のスケーラブルなインフラを使い、エンベディングに基づく高性能タンパク質データベースと検索ソリューションを構築して、数十億タンパク質規模の酵素発見に挑んでいる方法を紹介します。独自の大規模データベースに含まれるすべてのタンパク質をベクトル空間にエンベディングし、 Amazon Simple Storage Service (Amazon S3) 上に構築した LanceDB でデータにアクセスできるようにして、 AWS Lambda で検索することで、酵素発見を最近傍探索問題に変換し、これまで未探索だった発見空間に高速にアクセスできるようになりました。 ソリューション概要 このソリューションの中心にあるのが LanceDB です。LanceDB はオープンソースのベクトルデータベースで、インデックス付きベクトルに対する高速な近似最近傍 (ANN) 検索を実現します。LanceDB は完全にファイルベースで Amazon S3 ストレージとも互換性があるため、サーバーレス構成に適しています。その結果、エンベディング済みタンパク質配列のデータベースを Amazon Elastic Block Store (Amazon EBS) のような永続ディスクではなく、比較的低コストな Amazon S3 に保存できます。常時稼働するサーバーは不要で、データベースをオンデマンドで検索するのに必要なのは、LanceDB を使って S3 上のデータから直接最近傍を見つける Lambda 関数だけです。 Metagenomi の大規模タンパク質データベースを表す数十億のベクトルエンベディングを取り込み・検索するために、データベースを均等なサイズのパーツ (フォルダ) に分割して Amazon S3 に低コストで保存し、それらを並列にインデックス化して Lambda による map-reduce アプローチで検索する方法を考案しました。以下の図がこのアーキテクチャを示しています。 処理は 4 つのステップで構成されています。 データのベクトル化 データのバケット分割 データの取り込みとインデックス作成 データベースへのクエリ データのベクトル化 LanceDB の高速な ANN 検索機能を利用するには、データをベクトル形式にする必要があります。Metagenomi のメタゲノミクスデータベースには数十億のタンパク質が含まれており、それぞれがアミノ酸の文字列です。各タンパク質を生物学的に意味のある情報を捉えたベクトルに変換するため、タンパク質言語モデル (pLM) に通し、モデルの隠れ層をそのタンパク質のベクトル表現として取得します。タンパク質エンベディングの生成にはさまざまな pLM が使用でき、求める生物学的情報と計算要件に応じて選択します。今回は AMPLIFY_350M モデル を使用しました。データベース全体へのスケーリングに十分な速度を持つ Transformer エンコーダモデルです。モデルの最終隠れ層に対して mean-pool を実行し、各タンパク質について 960 次元のベクトルを生成します。生成されたベクトルと対応する一意のタンパク質 ID は HDF5 ファイルに保存します。 データのバケット分割 タンパク質ベクトルを検索可能なデータベースにするために、LanceDB でクエリの ANN を高速に見つけるためのインデックスを構築します。しかしインデックス作成には時間がかかり、複数ノードへの分散も困難です。インデックス作成を高速化するため、まずデータをほぼ均等なサイズのバケットに分割します。エンベディング HDF5 ファイルを best-fit bin packing アルゴリズムで合計約 2 億ベクトルのバケットに割り当てます。バケット分割に使う具体的なサイズ決定方法は、ベクトルの数、次元数、フォーマットによって異なります。各バケットは Amazon S3 上の単一の LanceDB データベースオブジェクトストア内に独立したテーブルとして取り込まれます。 データをバケット分割することで、個別ノードで並列にインデックス化できる小さなデータベースを複数作成でき、インデックス作成時間を大幅に短縮できます。また、既存データ全体を再インデックスする代わりに、新しいバケットとしてデータを追加でき増分追加も容易です。 バケット分割データの取り込みとインデックス作成 ベクトル化されたデータがバケットに割り当てられたら、LanceDB テーブルに変換してインデックスを作成し、高速な ANN クエリを可能にします。データを LanceDB テーブルに変換する具体的な方法は LanceDB のドキュメント を参照してください。約 2 億ベクトルの各バケットに対して、コサイン距離の IVF-PQ インデックスを持つ LanceDB テーブルを作成します。インデックス作成では、パーティション数は挿入行数の平方根、サブベクトル数はベクトル次元数を 16 で割った値を使用します。 クエリをスムーズにするため、各テーブルは作成元のバケットにちなんだ名前を付け、単一の S3 ディレクトリにアップロードします。ファイル構造から見ると、複数テーブルを持つ 1 つの LanceDB データベースとして認識されます。 以下のコードスニペットは、 id カラムと embedding カラムを含む HDF5 ファイルからベクトルを LanceDB データベースに取り込み、コサイン距離による高速 ANN 検索用にインデックスを作成する例です。実行に必要なのは python >= 3.9 と lancedb 、 pyarrow 、 h5py パッケージです。このスニペットは非同期 LanceDB API を使用する lancedb バージョン 0.21.1 でテスト・開発されています。 from typing import List, Iterable from itertools import islice from math import sqrt import pyarrow as pa import datetime import asyncio import lancedb import h5py def batched(iterable: Iterable, n: int) -> Iterable[List]: """Yield batches of n items from iterable.""" while batch := list(islice(iterable, n)): yield batch async def vectors_to_db( vectors: str, db: str, table_name: str, vector_dim: int, ingestion_batch_size: int, ) -> int: """Ingest and index vectors from an HDF5 file into a LanceDB table. Args: vectors (str): An HDF5 file containing protein IDs and their 960-dimension vector representations. db (str): Path to the LanceDB database. table_name (str): Name of the table to create. vector_dim (int): Dimension of the vectors. """ # create db and table custom_schema = pa.schema( [ pa.field("embedding", pa.list_(pa.float32(), vector_dim)), pa.field("id", pa.string()), ] ) # count the total number of rows as they are added to the table total_rows = 0 # open a connection to the new database and create a table with await lancedb.connect_async(db) as db_connection: with await db_connection.create_table( table_name, schema=custom_schema ) as table_connection: # open vectors file with h5py.File(vectors, "r") as vectors_handle: # create a generator over the rows rows = ( {"embedding": e, "id": i} for e, i in zip( vectors_handle["embedding"], vectors_handle["id"], ) ) # insert rows in batches to avoid memory issues for batch in batched(rows, ingestion_batch_size): total_rows += len(batch) await table_connection.add(batch) # optimize the table and remove old data await table_connection.optimize( cleanup_older_than=datetime.timedelta(days=0) ) # configure the index for the table index_config = lancedb.index.IvfPq( distance_type="cosine", num_partitions=int(sqrt(total_rows)), num_sub_vectors=int( vector_dim / 16 ), ) # index the table await table_connection.create_index( "embedding", config=index_config ) # ingest and index your data asyncio.run( vectors_to_db( vectors="./my_vectors.h5", db="./test_db", table_name="bucket1", vector_dim=960, ingestion_batch_size=50000 ) ) ベクトル化、取り込み、各バケットのインデックス作成は、複数の AWS Batch ジョブで並列実行することも、単一の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行することもできます。 データベースへのクエリ データがバケット分割され Amazon S3 上の LanceDB データベースに取り込まれたら、クエリの手段が必要です。LanceDB は LanceDB Python API を使って Amazon S3 から直接クエリできるため、Lambda 関数でユーザーが指定したクエリベクトルを受け取り、ANN を検索して結果を返すことができます。ただし、データが複数テーブルにバケット分割されているため、各バケットで最近傍を検索し、結果を集約してからユーザーに返す必要があります。 クエリワークフローは AWS Step Functions の ステートマシン として実装しています。各バケットに対するクエリ処理を Lambda プロセスとして管理し、最後に単一の Lambda プロセスがデータを集約して結果の ANN を .csv ファイルとして Amazon S3 に書き込みます。AWS Batch プロセスやローカル実行でも代替可能です。以下のスニペットは、1 つのバケットに対して ANN クエリを実行するプロセスの例です。実行に必要なのは python >= 3.9 と pandas 、 lancedb パッケージです。取り込みセクションと同様に、非同期 LanceDB API と lancedb バージョン 0.21.1 を使用しています。 from typing import List, Iterable import asyncio import lancedb import pandas import random async def run_query_async( lancedb_s3_uri: str, table_name: str, q_vec: List[float], k: int, vec_col: str, n_probes: int, refine_factor: int, ) -> pandas.DataFrame: """Run a query on a LanceDB table. Args: lancedb_s3_uri (str): S3 URI of the LanceDB database. table_name (str): Name of the table to query. q_vec (List[float]): Query vector. k (int): Number of nearest neighbors to return. vec_col (str): Column name of the vector column. n_probes (int): Number of probes to use for the query. refine_factor (int): Refine factor for the query. Returns: pandas.DataFrame: DataFrame containing the approximate nearest neighbors to the query vector. """ # open a connection to the database and table with await lancedb.connect_async( lancedb_s3_uri, storage_options={"timeout": "120s"} ) as db_connection: with await db_connection.open_table(table_name) as table_connection: # query the approximate nearest neighbors to the query vector df = ( await table_connection.query() .nearest_to(q_vec) .column(vec_col) .nprobes(n_probes) .refine_factor(refine_factor) .limit(k) .distance_type("cosine") .to_pandas() ) return df # query the example bucket we produced in the last section bucket1_df = asyncio.run( snippets.run_query_async( lancedb_s3_uri="s3://mg-analysis/owen/20250415_lancedb_snippet_testing/test_db/", table_name="bucket1", q_vec=[random.random() for _ in range(960)], k=3, vec_col="embedding", n_probes=1, refine_factor=1, ) ) 上記のクエリは以下の構造を持つ pandas DataFrame を返します。 embedding id _distance [-5.124435, 4.242000, …] id_1 0.000000 [-5.783999, 4.340500, …] id_2 0.001000 [-6.932943, 3.394850, …] id_3 0.04020 embedding カラムには最近傍のベクトル表現、 id カラムにはその ID、 _distance カラムにはクエリベクトルとのコサイン距離が格納されています。 各バケットが個別のノードで検索され、それぞれが最近傍の DataFrame を返した後、結果をマージしてユーザーに返す必要があります。以下のスニペットはその方法の例です。 def aggregate_nearest_neighbors( dfs: List[pandas.DataFrame], k: int ): """Aggregate the nearest neighbors for each query vector. Args: dfs (List[pandas.DataFrame]): A list of DataFrames containing the nearest neighbors queried from each bucket. k (int): The number of nearest neighbors to aggregate. Returns: pd.DataFrame: A DataFrame with the aggregated nearest neighbors. """ # concatenate the DataFrames and get the top k nearest neighbors return ( pandas.concat(dfs, ignore_index=True) .sort_values(by=["_distance"], ascending=True) .reset_index(drop=True) .head(k) ) # add the dataframes from querying each bucket to a list dfs = [bucket1_df, bucket2_df, bucket3_df, bucket4_df, bucket_5] # aggregate the nearest neighbors across all buckets nearest_neighbors_all_buckets_df = aggregate_nearest_neighbors(dfs, 5) 大量クエリの最適化 Lambda で S3 上の LanceDB データベースを直接検索する方法は、1 つまたは少数のクエリベクトルの ANN 検索には適していますが、数千から数百万のベクトルをクエリする必要があるユースケースもあります。 大量クエリに対してスケールする方法として、先述のクエリ実装を変更し、まずデータベースのバケットの 1 つをローカルストレージにダウンロードしてから LanceDB API でローカルに検索する方式を採用しています。データベースバケットのストレージサイズが大きいため、この実装は Lambda よりも AWS Batch ジョブに適しており、EBS ボリュームではなく最適化されたインスタンスストレージ (例: i4i インスタンス) の使用を推奨します。すべてのクエリ Batch ジョブが完了した後、最終ジョブが結果を集約してからユーザーに返します。並列クエリジョブと集約ジョブのオーケストレーションには Nextflow が使用できます。バケットをディスクにダウンロードするオーバーヘッドとレイテンシーは増加しますが、大量のクエリをより効率的に処理でき、常時稼働のサーバーベースデータベースも不要です。 ベンチマーク結果 インデックス戦略やデータベース分割サイズは、求めるパフォーマンスに依存します。ユースケースに合わせてカスタマイズする際の一般的な最適化ガイダンスを以下に示します。 Metagenomi が作成したデータベースの例では、AMPLIFY で生成した 960 次元のベクトルエンベディング 35 億件を格納しています。この 35 億ベクトルエンベディングを 2 億ベクトルごとに分割し、 i4i.8xlarge インスタンスで取り込みとインデックス作成を行ったところ、合計 108 コンピュート時間で完了しました。このソリューションはサーバーレスで S3 オブジェクトストアから直接クエリできるため、データベースの固定コストは Amazon S3 上のストレージ容量のみです (35 億ベクトルのインデックス済みデータベースで約 12.9 TB)。Lambda によるクエリは非常に低コストで、多くのクエリが 1 セント未満で実行できます。 一般的に、分割サイズが大きいほどクエリのコスト効率は高くなりますが、実行時間とインデックス作成時間は長くなります。単一分割で許容可能なクエリ応答時間を維持できる最大サイズまでスケールアップし、同時に Lambda 同時実行数の上限などの並列化の制約も考慮することを推奨します。Metagenomi では 2 億ベクトルごとの分割が、小規模・大規模両方のクエリでコストと実行時間の最適なバランスを示しました。取り込みとインデックス作成には i4i ファミリーなどのストレージ最適化インスタンスの使用を推奨します。ディスクベースのデータベースでクエリを実行する場合 (Lambda + Amazon S3 ではなく) も、ストレージ最適化インスタンスの使用を推奨します。Lambda 実装では、最大 50,000 ANN を要求する単一クエリ、または 5 ANN 未満で最大 100 シーケンスのマルチクエリを素早く処理できました。以下のグラフに示すように、実行時間は要求する ANN 数に対して線形に増加します。 まとめ この記事では、Metagenomi が LanceDB を Amazon S3 と AWS Lambda 上に実装し、数十億のタンパク質エンベディングを低コストで保存・検索する方法を紹介しました。この取り組みは、Metagenomi が根治的な遺伝子治療の開発に向けて推進する、新規酵素の発見とエンジニアリングプラットフォームの加速に貢献しています。クエリタンパク質の ANN エンベディング空間に数秒でアクセスできるようになったことで、大規模な解析パイプラインに高速検索手法を統合し、多様で新規な酵素ファミリーの発見を加速し、研究者がエンベディングをオンザフライで生成・検索する手段を提供してタンパク質エンジニアリングの取り組みを可能にしています。Metagenomi がタンパク質・DNA データベースの急速な拡大を続ける中、並列にインデックス化・検索できるデータベース分割による水平スケーリングが、将来のニーズに対応するエンベディングデータベースソリューションを実現しています。 この記事で紹介したソリューションはタンパク質 大規模言語モデル (LLM) で生成したベクトルに焦点を当てていますが、他のベクトル化されたデータセットにも適用できます。Amazon S3 と統合した LanceDB の詳細は LanceDB のドキュメント を参照してください。 参考文献 Fournier, Quentin, et al. “Protein language models: is scaling necessary?.” bioRxiv (2024): 2024-09. 著者について Audra Devoto Audra はメタゲノミクスのバックグラウンドを持つデータサイエンティストで、AWS 上の大規模ゲノミクスデータセットの取り扱いに長年の経験があります。Metagenomi では大規模解析プロジェクトを支えるインフラを構築し、MGXdb からの新規酵素発見を推進しています。 Christopher Brown Christopher Brown 博士は Metagenomi の Discovery チーム責任者です。メタゲノミクスの専門家であり、遺伝子編集応用に向けた多数の新規酵素システムの発見と特性解析を主導してきました。 Patrick O’Connor Patrick は AWS のシニア WorldWide AI プロトタイピングエンジニアで、クラウド上で生成 AI ソリューションとエンドツーエンドのプロトタイプを構築しています。大規模言語モデルと分散 AI システムの実装を専門としており、IoT、サーバーレス技術、ハイパフォーマンスコンピューティングの知見を活かして企業の複雑な課題解決に取り組んでいます。 Owen Janson Owen は Metagenomi のバイオインフォマティクスエンジニアで、大規模ゲノミクスデータセットの解析を支えるツールとクラウドインフラの構築に注力しています。 Pavel Novichkov Pavel Novichkov 博士は AWS のシニアソリューションアーキテクトで、ゲノミクスとライフサイエンスを専門としています。15 年以上のバイオインフォマティクスとクラウド開発の経験を持ち、ヘルスケア・ライフサイエンス分野のスタートアップが AWS 上でクラウドベースのソリューションを設計・実装する支援を行っています。NIH の National Center for Biotechnology Information でポスドク研究を行い、Berkeley Lab で 12 年以上計算研究科学者として勤務しました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。
本ブログは株式会社ラクス様と Amazon Web Services Japan 合同会社が共同で執筆しました。 株式会社ラクス (以下、ラクス) は、「IT サービスで企業の成長を継続的に支援します!」というミッションを掲げ、企業の業務効率化に貢献する複数のクラウドサービスを提供している IT 企業です。「楽楽精算」「楽楽明細」など複数のサービスを提供しています。 今回は AI エージェントプロダクト「伝票作成 AI エージェント」の開発に AWS を活用して迅速にプロダクトをリリースできた成果と、AWS の 生成 AI イノベーションセンター (以下、GenAIIC) とともに取り組んだ「AI エージェントの評価設計」に関する知見についてご紹介します。 伝票作成 AI エージェントの提供開始 経費精算は多くの企業で日常的に発生する重要な業務です。しかし領収書の確認や入力、申請内容の紐づけといった作業は依然として手作業に依存しており、業務負荷やミスの原因となっています。こうした課題に対し、ラクスは「伝票作成 AI エージェント」をリリースしました。生成 AI を活用して経費精算業務そのものを自動化し、従来の入力支援を超えた業務プロセスの効率化を実現するものです。 従来、ユーザーは領収書の内容を確認して金額や日付を入力しながら、事前申請やクレジットカード明細と照合する必要がありました。 伝票作成 AI エージェントはこうした一連の処理を横断的に実行し、領収書データや過去の申請履歴など複数の情報をもとに最適な申請内容を自動で生成します。 ユーザーは領収書を選択するだけで、必要な項目が補完された状態で申請を進められます。繰り返しが多い申請作業の時間短縮ができ、業務負荷を大幅に軽減します。 マネージドサービスを活用した迅速な AI エージェント機能リリース 伝票作成 AI エージェントは、社内知見を活かす・インフラの管理負荷を下げることを重点に置き、開発速度の最大化を目指しました。AWS のマネージドサービスを積極的に活用し、チームがエージェントのロジック開発に集中できる環境を整えています。 エージェント実行基盤には Amazon Elastic Kubernetes Service (Amazon EKS) を採用し、既存サービスでも運用実績のある Argo CD による GitOps で高速なリリースサイクルを実現しています。キーバリューストア・キャッシュには、運用工数を下げるためそれぞれ Amazon DynamoDB とAmazon ElastiCache Serverless for Valkey を採用しました。 アプリケーションアーキテクチャ アプリケーション側では AI エージェントの関心事を明確に分離するため、Amazon EKS 上に 3 層のサービスを構成するアーキテクチャを採用しました。 ゲートウェイ すべての外部アクセスの入口となる API ゲートウェイです。認証・認可をこの層に集約し認証済みのコンテキストを後段のサービスへ伝搬します。バックエンドや AI エージェントは認証ロジックから解放され、ビジネスロジックに集中できます。内部サービスへはゲートウェイ経由でのみアクセスでき、外部から直接到達できない構成です。 バックエンド 楽楽精算の業務データへのアクセス層です。領収書、クレジットカード明細、事前申請、伝票履歴といった業務データを扱う API を提供します。プライベートな MCP サーバーも提供しており、AI エージェントがツールとして業務データにアクセスできます。AI エージェントとバックエンドを分離することで、エージェントフレームワーク・実装言語を柔軟に変更できる構成としています。 AI エージェント Mastra フレームワークを用いたワークフロー実行基盤です。領収書データを起点に、クレジットカード明細の提案、事前申請との紐づけ、伝票項目の補完といった複数のステップを順に実行し、最終的な伝票を自動生成します。LLM の呼び出しには LiteLLM プロキシを経由し、モデルの切り替えやリトライ、フォールバックをインフラ層に委譲しています。AI エージェントのコードはビジネスロジックのみに集中できます。ワークフローには Human-in-the-Loop のステップを組み込んでいます。AI エージェントが提案を生成した後、ワークフローを一時停止してユーザーの確認を待ちます。ユーザーが内容を確認・選択すると、Amazon Simple Queue Service (Amazon SQS) にメッセージが送信されワークフローが再開されます。確認待ちの間はリソースを消費しないため、効率的なスケーリングを実現しています。 オブザーバビリティ AI エージェントの評価には振る舞いを把握できるオブザーバビリティが重要です。Amazon EKS 上では Fluent Bit と OpenTelemetry Collector を用いて、不要なテレメトリをフィルタリングしつつログ・メトリクス・トレースを統合的に収集しています。 ログ: Web 上の情報の豊富さを重視し Fluent Bit で CloudWatch Logs に送る構成にしています。 メトリクス: OpenTelemetry Collector の AWS Container Insights Receiver と AWS CloudWatch EMF Exporter を利用し、EC2 メトリクスを収集・フィルタリング・CloudWatch Metrics に送信しています。 トレース: AWS X-Ray OTLP エンドポイントへ送信し、Amazon CloudWatch Application Signals と CloudWatch Generative AI Observability で可視化しています。OpenTelemetry Collector の構成を工夫し、多段の tail-based sampling と loadbalancer exporter を組み合わせて、収集コストを抑えつつ必要な軌跡を追えるようにしています。 このように Amazon EKS 上で、 スケーラビリティと変更柔軟性を担保した AI エージェントを設計し、継続的に改善するためのオブザーバビリティを整備しています 。 AI エージェントの評価の難しさ 伝票作成 AI エージェントは、複数の AI エージェントが連携して一連の業務を完結させる構成です。ユーザーの入力を起点に、提案、照合、データ生成といった各 AI エージェントが順に実行され、それぞれの結果が統合されて伝票が自動生成されます。 オフライン評価 (リリース前の性能評価) における課題 この構造においてまず課題となるのは、各 AI エージェントの正しさをどのように評価するかです。各 AI エージェントはそれぞれ独立して一定の妥当性を持つように見えても、それが本当に適切な判断であるかは、単体の出力だけでは判断できません。さらに、各 AI エージェントの結果が後続の処理に影響を与えるため、最終結果に問題があった場合でも、どの段階に起因するのかを特定することが難しくなります。 また、リリース前の段階では、AI エージェントのパフォーマンスを十分に把握したうえでリリースすることが求められます。特に伝票作成 AI エージェントにおいては、外貨処理や端数の扱い、入力の揺れといったエッジケースに対しても適切に動作するかを入念に確認する必要がありました。しかし、こうしたケースは実運用で初めて顕在化することも多く、事前にどこまで網羅的に検証できているかを判断することは容易ではありません。 オンライン評価 (リリース後の本番稼働における性能評価) における課題 リリース後の評価はさらに複雑です。伝票作成 AI エージェントからユーザーに提示されるのは途中段階の提案であり、正しさはユーザーの選択によって初めて確定します。AI エージェントの実行ログだけでは「その提案がユーザーにとって適切だったか」は判断できません。 加えて、AI エージェントが提示した候補がユーザーに選択されるかどうかは、別の処理として扱われ非同期的な状態遷移が発生します。その結果、単一のリクエストとレスポンスの対応関係だけでは処理全体を捉えることができず、従来のような単発の評価では実際の業務上の正しさを十分に測ることができません。 このように、複数の AI エージェントで構成され、かつユーザーの選択が結果に影響する構成では、各 AI エージェントの妥当性と最終的な成果の両方をどう評価するかが課題となります。 オフライン評価とオンライン評価の設計 これらの課題に対して私たちは AWS のアカウントチームおよび GenAIIC と協業し、AI エージェントの品質を担保するためのオフライン評価とオンライン評価を組み合わせた仕組みを設計しています。 評価設計における学び GenAIIC との協議を通じて、評価設計に対する考え方が大きく変わりました。 当初は個々の LLM 推論の精度指標(正解率や F1 スコアなど)を個別に設計し精度を高めることに注力していました。 しかし GenAIIC との議論で、まず問うべきは「AI エージェントがタスクを完了できるかどうか」であるという視点を得ました。 個々の LLM 推論の精度がどれだけ高くても、最終的にユーザーの経費精算タスクを完遂できなければ意味がありません。精度向上はタスク完了を実現するための手段であり、ゴールそのものではないのです。 もうひとつの学びは、全体の評価フレームワークを先に整理する重要性です。 個々の精度を積み上げて全体を捉えようとするのではなく、まずワークフロー全体を俯瞰して「何をもってタスク完了とするか」を定義し、そこから各 AI エージェントの評価指標へと分解していくアプローチを取りました。 全体像を体系的に整理することで、各指標の位置づけや優先度が明確になり、効率的な評価設計が可能になりました。 オフライン評価の解決策 まずリリース前の段階では、エージェントの挙動を再現可能な形で評価するために、オフライン評価用のデータセットを構築しました。伝票作成 AI エージェントは、業務プロセスごとに分かれた 3 つのエージェント(クレジットカード明細の提案・事前申請の提案・伝票の生成)で構成されています。評価の起点に置いたのは、「ワークフロー全体(業務全体)として、最終的に正しい伝票を生成できたか」というタスク完了の観点です。そのうえで、この全体評価を各エージェントの単位へと分解しました。分解にあたっては、途中の Human-in-the-Loop での人間への確認をはさんでいます。 各 AI エージェントは LLM の単発の呼び出しではなく、複数の推論ステップからなる業務プロセスです。評価も個々の LLM 呼び出しの正否ではなく、AI エージェントが業務プロセスとして期待される出力を達成できたかを単位としています。これにより最終的な成果だけでなく、どの AI エージェントが成否に影響しているかを切り分けて評価できるようにしました。 具体的には、各 AI エージェントが解いている問題の性質に合わせて評価指標を設計しました。AI エージェントごとに起こりうる誤り方が違うため、指標も分けて確認しています。 クレジットカード明細提案エージェントの評価 クレジットカード明細の提案エージェントは、領収書の明細とクレジットカード明細を突き合わせて「どの領収書がどのカード明細に対応するか」を判断します。複数の明細をまとめて対応づけたり対応相手が存在しないケースもあり、「取りこぼし」と「誤った対応づけ」の両方が起こりえます。そこで次の指標で評価します。 適合率 (Precision) : 提案した紐づけのうち正しかった割合。高いほど誤った提案が少ない。 再現率 (Recall) : 本来紐づけるべき紐づけのうち提案できた割合。高いほど取りこぼしが少ない。 F1 : 適合率と再現率のバランス。 たとえば「適合率は高いが再現率が低い」なら、提案は正確だが拾いきれていない候補がある状態だと分かります。 事前申請提案エージェントの評価 事前申請の提案エージェントは、領収書の明細を「既存の事前申請のどの明細に紐づけるか」それとも「新規の明細として扱うか」を判断します。マッチングに加えて「既存か新規か」の振り分けが入るため、確認すべき指標も多くなります。 既存マッチの適合率/再現率 :「既存」と判断した明細で、正しい相手を選べたか 振り分けの正答率 : そもそも「既存か新規か」の判断自体が正しいか 新規ケースの正答率 : 新規にすべき明細を、新規と判断できたか これにより「既存と判断した中での取り違え」なのか「既存/新規の判断ミス」なのか、どちらでつまずいたかを切り分けられます。こうして指標を分けて見ることで、各 AI エージェントの信頼できる範囲と弱点を具体的に把握できます。 伝票生成エージェントの評価 最終的な伝票については、生成された伝票がタスクとして正しく完成しているかを、次の観点で評価します。 提示したすべての領収書(明細)が、漏れなく伝票に反映されているか クレジットカード明細が正しく紐づけられているか 事前申請が伝票に正しく対応づけられているか 各ステップ間で金額が整合しているか 伝票全体が論理的に整合し、業務上そのまま利用できる形に完成しているか これらのうち、ID の一致や金額の整合のように決定的に判定できる項目はその形で確認し、伝票全体としての論理的な完成度は LLM-as-a-Judge で評価します。決定的な指標と確率的な推論評価を組み合わせ、タスクを完了できたかを総合的に判断しています。 また、通常のケースだけでなく実運用で発生し得るエッジケースを意図的に含めたデータセットを構築しました。GenAIIC との協議を通じて誤りが発生しやすいパターンを体系的に洗い出し、例えば、以下のような観点でテストケースを設計しています。 金額処理の複雑性: 外貨処理、為替レートによる端数差、税込・税抜の表記差、軽減税率の混在 表記の揺れ: 法人名の略称や言語差(英語/日本語)、同義語 時間的な不整合: 海外出張における日付またぎ、購入日と利用日のずれ パターンの多様性: 月額サブスクリプション、1伝票に対する複数明細・複数領収書の紐づけ これにより「想定通りに動くか」だけでなく、「想定外の入力にどこまで耐えられるか」を評価することが可能になりました。 オフライン評価の結果、AI エージェントごとに成熟度に差があることが明確になりました。本番投入可能な水準に達している AI エージェントがある一方で、明細行が多いケースなど特定の条件で精度が落ちる AI エージェントも特定でき、改善の優先順位を明確にすることができました。 オンライン評価の解決策 オフライン評価だけでは、実際のユーザー利用における正しさを十分に捉えることはできません。そのためリリース後は、オンラインで取得できるデータを活用した評価の仕組みを整備しました。 具体的には、AI エージェントの提案内容と、ユーザーが実際に選択した内容をそれぞれ DB 上に保存し、両者を突き合わせることで提案の妥当性を定量的に評価できる仕組みを整備しました。 例えば、クレジットカード明細の提案ステップにおいては、AI エージェントが提案した明細とユーザーが実際に採用した明細を比較します。一致していれば提案が正しかったと判断でき、不一致であればどのような条件で誤った提案をしたのかを分析できます。こうしたデータを継続的に蓄積することで、どのようなケースで提案が採用されやすいのか、あるいは改善が必要なのかといった傾向を分析し、AI エージェントの改善に活用できる基盤を構築しました。 このようにリリース前のオフライン評価とリリース後のオンライン評価を組み合わせることで、AI エージェントの挙動を多面的に捉え、継続的に品質を向上させる仕組みを実現できました。 今後の展望 今回構築した評価の仕組みは、単に現時点の品質を担保するためのものだけではなく、AI エージェントを継続的に改善していくための基盤として位置づけています。 自己改善ループの構築 AI エージェントは一度リリースして終わりではなく、実運用の中で得られるデータをもとに自ら改善していく仕組みが重要だと考えています。オンライン評価で蓄積されるユーザーの選択や修正の履歴は、エージェントにとっての「経験」です。この経験を Episodic Memory (エピソード記憶) のような形で蓄積し、過去の成功・失敗パターンをエージェントの振る舞いに反映させることで「使うほどに精度が向上する」自己改善ループの実現を目指しています。 評価の高度化 今回の評価設計は出発点であり、今後は評価基盤そのものも進化させていきます。 評価の多層化 評価対象には、入力の変換や ID の突合のように決定的に正誤を判定できる処理と、LLM の推論のように確率的に振る舞う処理が混在します。今後はこれらを役割の異なる層に整理し、決定的に検証できる部分は高速なユニットテストで固め、個々の推論ステップやプロンプト・ツール選択の粒度では確率的に評価し、ワークフロー全体ではタスクを完遂できるかを評価する多層構成を目指します。これにより品質劣化が「LLM の揺らぎ」か「実装不具合」かを切り分けやすくし、エージェント内部のどの判断が精度に効いているかをより細かく特定できるようにします。 評価データセットの継続的な拡充 オフライン評価の網羅性には限界があり、難しいケースの多くは実運用で初めて顕在化します。 今後は、オンライン環境で蓄積される実データから得られる洞察を、オフライン評価用データセットへ継続的に取り込む仕組みを整備していきます。 特に、エージェントの提案とユーザーの選択が食い違ったケースや、想定外の入力が行われたケースを分析し積極的に取り込むことで、既存の評価データセットを発展させ、本番で間違えやすいエッジケースを含む実践的な評価データセットへと拡充します。これにより、リリース前にエージェントの想定外の動作や意図しない品質低下を検知できる範囲を、継続的に広げていきます。 伝票作成 AI エージェントは、経費精算という業務を起点に、AI が業務の一部を担う新しい働き方を提示する取り組みです。今後も評価と改善を繰り返しながら、より実用的で信頼できる業務支援 AI へと進化させていきます。 著者について 松浦 拓哉 2022 年に株式会社ラクスへ新卒入社。 現在は AI エージェント課にて「楽楽精算」における AI エージェントの設計・実装・運用・評価と、それを支えるアプリケーションアーキテクチャの設計を担当。AI エージェントに仕事を任せるために、今日も人間がせっせと働いている。 竹田 舜 2023 年株式会社ラクスに新卒入社。 現在は AI エージェント課にて伝票作成 AI エージェントの開発に従事。Amazon EKS クラスタ構築、NW 構築、k8s Operator 検証/導入、監視基盤構築、CD パイプライン構築などプラットフォーム業務を担当。Kubernetes に全てを任せるべくせっせと自動化している。 Taketoshi Kazusa アマゾンウェブサービスジャパン合同会社 Senior Applied Scientist. 10年以上のAI・機械学習の業務経験を持ち、実ビシネスでの課題解決に機械学習の活用を支援している。 Hajime Onishi アマゾンウェブサービスジャパン合同会社 Solutions Architect. AWS でのサポートエンジニア経験を経て、現在は ISV/SaaS 企業のお客様の技術的な支援と業界を問わずお客様のクラウドガバナンス、オブザーバビリティに関わる支援をしている。
はじめに AWS Summit Japan 2026(6/25-26 @幕張メッセ)にご来場いただいた皆様、ありがとうございました。本ブログでは、建設・不動産業向けインダストリーブース(A057)の不動産パートの展示内容をご報告します。 不動産ブースのテーマ: 「不動産業の未来を、生成 AI で切り拓く ─ データと対話が変える、新しい不動産体験」 また、ブースの事前紹介は こちらの開催予告ブログ で公開しています。 不動産×AI ─ AI 時代のデータ戦略をどう描くか 不動産業界では、人口減少・空き家問題・人手不足といった構造的な課題が山積しています。これらに立ち向かうために、データと AI を組み合わせた業務変革が求められています。しかし、どれだけ優れた AI が登場しても、活用できるデータが整っていなければ課題解決は始まりません。今回のブースでは、不動産業の数ある業務の中でも 開発・流通・管理 という3つのフェーズに着目し、さらにそれらを横断する 意思決定・可視化 の視点を加えた4つの切り口で、業務課題を解決するためのデータと AI の活用方法をご紹介しました。 開発:オープンデータ× 自社データ活用。大量のデータを AI で解析し、エリア分析・将来予測 流通:自社の物件・顧客データを AI に提供。AI が自社システムにアクセスし、顧客体験をセルフサービス化 管理:設備データ・修繕履歴・IoT センサーを深く・継続的に蓄積。3D モデルや AI で解析・予測 可視化:データを横断的に可視化。Amazon Quick の生成 AI によるダッシュボード自動生成で、経営判断を加速 今、不動産業に求められるのは、ユースケースを正しく理解し、必要なデータを集め、求められる切り口で AI に活用させること。これが 2026 年における「AI 時代のデータ戦略」です。 ここからは、ブースで展示した各ソリューションをご紹介します。 展示① 都市・エリア分析 × AI エージェント「AI Urban Digital Twin」 概要 不動産業における 開発 フェーズにおいて「どこに」「何を」建てるかの意思決定を AI で支援するソリューションです。人口統計・地価・交通量・POI などの公開データと自社データを統合し、AI が都市特性を多角的に分析します。 本ソリューションには2つの側面があります。ひとつは、大量のオープンデータを事前に整形・統合し、3D 地図上にヒートマップや境界ポリゴンとして描画する可視化機能。もうひとつは、MCP(Model Context Protocol)で AI エージェントが不動産情報ライブラリ API や分析データベースにリアルタイムにアクセスし、「この地域の将来人口は?」などの自然言語クエリに即座に回答する対話型分析機能です。この2つを組み合わせることで、エリア分析を高速に実行し、不動産開発・用地選定の判断を加速します。 デモの見どころ エリアの開発ポテンシャル分析:生成AIが人口増加率・地価変動率・災害リスク・周辺施設の充実度など多角的な指標をもとにエリアをスコアリングし、地図上にエリアの状況を描画 開発企画の提案:エリア特性(人口分布・用途地域等)に基づき、住宅・オフィス・商業施設それぞれにおいて、周辺施設の状況などを踏まえた開発企画を AI が提案 将来予測の可視化:5年後・10年後・20年後の地価変動・人口予測をヒートマップで表示 データ取得・変換フロー 今回は、国土交通省が提供する「不動産情報ライブラリ」の情報を元に都市を分析するデモを作成しています。 不動産情報ライブラリは REST API として公開されており、以下の2種類の形式でデータを取得しています。 JSON API:市区町村・都道府県単位で取得。不動産取引価格(四半期別)など ベクトルタイル API(GeoJSON):将来推計人口、用途地域、災害リスク、施設POI など 不動産情報ライブラリ API から取得したデータは、 AWS Lambda を利用して変換し、 Amazon S3 に CSV として蓄積します。この際、データは都市コードごとに分類され、さらにデータ種別(将来推計人口・用途地域・地価・災害リスク等)ごとのディレクトリに整理して格納されます。2次処理では Amazon S3 上の全データを読み込み、空間統合・スコアリングを行った結果を Amazon DynamoDB のテーブルへ書き込みます。処理の中では、取得した各種ポリゴンデータを約250m四方の正方形グリッド(メッシュ)に変換・割り当てし、メッシュ単位でデータを統合しています。それぞれのテーブルには以下のようなデータが格納されます。 AreaData:同一用途地域ごとにグルーピングしたエリア単位の分析結果 PredictionData:エリアごとの5年刻みの将来予測データ BoundaryData:地図描画に使用するエリアの境界ポリゴン ZoningData:用途地域データや建ぺい率・容積率の区域データ PropertyData:自社物件データ(所在地・緯度経度・物件属性) なぜ、2段階の処理でデータを取得しているかというと、データ量の問題があります。1都市あたり約 200 MB、1,000ファイル以上にも渡る取得結果をそのまま描画するのはパフォーマンスの懸念がありました。そこで、 Amazon DynamoDB にデータを整形して投入することで、地図描画時のパフォーマンスを確保しています。また、 Amazon S3 に生データを残すことで、処理ロジックを改良した際にいつでも再処理が可能な設計としています。 フロントアプリケーションの構成とデータの活用 Amazon DynamoDB に格納されたデータは、API を経由してフロントエンドに提供されます。各 Lambda 関数がそれぞれの Amazon DynamoDB テーブルにアクセスし、用途に応じた形でデータを返却します。また、MCP Chat Lambda は Amazon Bedrock と連携して自然言語での対話型分析を、Geodata Lambda は Amazon Location Service と連携して地図描画を実現しています。 フロントアプリケーションでは以下の機能が提供されます。 AI 都市診断機能 各テーブルから取得したエリア分析結果を地図上に可視化し、ユーザーにデータ参照体験を提供します。さらに Amazon Bedrock がデータを解釈し、人口動態・地価・災害リスク・周辺施設などを総合した都市分析レポートを生成します。 開発企画生成機能 用途地域・施設充実度・人口構成などのデータを元に、生成 AI が当該エリアに適した開発企画(住宅/商業/オフィス等)を提案し、顧客に新たなインサイトを提供します。 未来の可視化機能 将来予測データを元に、都市の5年後・10年後・20年後の人口・地価の変化をヒートマップで表示します。時間軸を切り替えることで、エリアの将来性を直感的に把握できます。 自社物件マッピング機能 自社保有物件を地図上にプロットし、エリア分析結果と重ねて表示します。これにより「自社物件がどのようなエリア特性の中に位置しているか」を一目で把握できます。さらに、エリアのスコアや将来予測と自社物件を掛け合わせ、生成 AI が「このエリアの物件は将来的に価値が上がるか」「周辺施設の充実度に対して賃料設定は適切か」といった分析を提供します。開発判断やポートフォリオ見直しの材料として活用できます。 その他にも、用途地域ポリゴンを地図上に重ねて表示する機能や、洪水浸水想定区域・液状化リスク・土砂災害警戒区域といった防災情報の可視化機能も備えており、開発候補地のリスク評価を地図上で直感的に確認できます。 AI チャット機能 大規模なバッチ処理によって大量のデータ処理と可視化を実現している一方で、不動産情報ライブラリ API を MCP(Model Context Protocol)サーバーとして構成し、生成 AI を利用した対話型分析機能も提供しています。こちらはバッチ処理済みのデータに加え、国交省 API からリアルタイムに最新情報を取得して回答できるため、「直近の取引事例は?」「このエリアの最新の地価公示は?」といった鮮度の高い問いかけにも対応します。バッチによる俯瞰的な可視化と、MCP によるリアルタイムな対話分析の両輪で、ユーザーの意思決定を支援します。 このように、大量のデータを高速に参照して地図上に描画する用途と、チャットのようにリアルタイムで短い問いに即座に応答する用途では、求められるデータパイプラインが異なります。前者にはバッチ処理による事前整形と Amazon DynamoDB への投入が、後者には MCP を通じた API のリアルタイム呼び出しが適しています。ユースケースに応じてパイプラインを分けることが、データと AI を組み合わせたソリューション設計において重要なポイントです。 展示② 不動産流通支援 AI エージェント「AI コンシェルジュ」 概要 不動産業における顧客接点は Web・電話・メッセージアプリと多岐にわたりますが、どのチャネルでも一貫した体験を提供できている企業はまだ少ないのではないでしょうか。その背景には、物件データベースや予約管理システムなど自社の業務システムが個別に存在し、チャネルが分断している現状があります。本展示では、生成 AI エージェントが自社の物件データベースや予約管理システムに直接接続し、電話でもチャットでも、物件提案から内覧予約までをシームレスに完結させるオムニチャネル体験をお見せしました。AI が自社システムのデータにリアルタイムにアクセスすることで、顧客はどのチャネルからでもセルフサービスで物件探しから予約まで完了できます。 デモでは、チャットで「目黒駅の 2LDK を探している」と伝えると、AI が条件を整理して物件を提案し、内覧日時をその場で確定する、という一連の流れをお見せしました。 デモの見どころ 電話とチャットのオムニチャネルな体験:同じ AI エージェントがチャットでも電話でも対応。チャネルを問わず一貫した顧客体験を提供 生成AIが既存システムと連携:顧客の発話内容に応じて、AI が自社システムの API(物件検索・予約管理等)を自律的に呼び出しデータを取得・入力 顧客体験がセルフサービスで完結:物件提案から内覧予約の確定まで、人間の介在なしに AI が一連の業務を完結。24時間対応 アーキテクチャの特徴 Amazon Connect Customer AI Agents は、 Amazon Connect Customer 上で動作する AI エージェント機能です。音声やチャットチャネルを通じて顧客と直接会話し、質問への回答だけでなく予約の作成・変更・キャンセルといったアクションまで自律的に実行できます。解決が難しい場合はシームレスに人間のオペレーターにエスカレーションします。この仕組みの軸は、自社システムの API をツールとして AI エージェントに読み込ませることにあります。プロンプトで定義されたルールに基づき、AI エージェントが顧客の希望に合わせて能動的にツールを起動し、自社の物件データベースから条件に合う物件を検索したり、予約管理システムに内覧予約を書き込む操作を自律的に実行します。人間が介在せずとも、データの参照と入力の両方を AI が行える点がポイントです。 この仕組みはチャットだけでなく電話でも同様に機能します。 Amazon Connect Customer がオムニチャネルの入口となるため、顧客がどのチャネルから問い合わせても同じ AI エージェントが同じツールを使って対応します。 本展示で扱う物件データ(PropertyData)は、展示①のエリア分析で使用しているものと同じデータです。展示①では「エリア × 自社物件」の俯瞰的な分析視点で活用しているのに対し、展示②では同じデータを顧客向けのセルフサービス体験として提供しています。 展示③ 施設管理 × AI × デジタルツイン 概要 展示①と同じ地図ベースのソリューションですが、扱うデータが異なります。展示①がオープンデータと自社物件データで「都市」を分析するのに対し、本展示では施設のセンサーから取得する稼働データや修繕履歴データを用いて「管理されている施設の状態」を可視化・分析します。 不動産管理のフェーズでは、開発・流通とは異なる課題があります。管理施設が数十〜数千棟に散在する中で「どの施設が最もリスクが高いか」を一元的に把握する手段がなく、台帳はExcelや紙・個別システムに分散しているため横比較ができません。修繕優先度の判断は熟練者の勘に依存し、退職とともに知見が消失します。さらに、設備状態の確認には毎回現地巡回が必要であり、劣化に気づかないまま放置された結果、発見時には既に状態が深刻化し、大規模修繕による膨大なメンテナンスコストが発生するリスクがあります。 デモの見どころ 地図上の施設状態マッピング:施設のセンサー稼働データ・修繕履歴を元に劣化ランクを算出し、地図上に色分けで表示。コンディションベースでメンテナンスの意思決定が可能に 生成 AI アシスタント:取得したデータが生成 AI に連携され、施設に関する質問への回答や劣化予測・修繕優先度の提案を自然言語で取得可能(例:「築40年以上でFCIがD以上の施設は?」) デジタルツイン(3D可視化):これらの情報を建物の3Dモデル上にマッピングし、デジタルツインとして管理可能。現地に行かずに設備状態を空間的に把握 アーキテクチャの特徴 統合施設管理AIダッシュボードは、施設・設備の維持管理を支援するAIエージェント機能です。ダッシュボード上のチャットUIを通じて担当者と対話し、施設の劣化状況や修繕優先度に関する質問への回答だけでなく、修繕依頼の起票といったアクションまで実行できます。修繕依頼の作成にあたっては、プロンプトで定義されたルールに従って担当者に確認を求めたうえで書き込みを行います。 この仕組みの軸は、自社システムのAPIをツールとしてAIエージェント(Strands Agents SDK + Amazon Bedrock AgentCore )に読み込ませることにあります。プロンプトで定義されたルールに基づき、AIエージェントが担当者の要望に合わせて能動的にツールを起動します。 Amazon DynamoDB の施設・設備・修繕データから条件に合う施設を検索し、 Amazon Neptune Analytics の知識グラフに対してopenCypherクエリを発行して施設間の関係性(同型設備の故障リスク伝播、業者依存度、類似施設のクラスタリング)を分析し、確認を経たうえで修繕依頼を書き込む操作までを実行します。人間が最終判断を担いつつ、データの参照と入力の両方をAIが行える点がポイントです。 Amazon Bedrock の基盤モデルは、テキストの対話だけでなく画像の解析にも活用されています。点検時にアップロードされた写真をマルチモーダル基盤モデルが解析し、ひび割れ・錆・水損・劣化といった問題点の検出、重要度評価、推奨対応、概算費用の目安を構造化データとして返します。対話エージェントによるデータの参照・入力と、画像解析による点検の効率化が、いずれも同一のAI基盤の上で提供されています。 本ソリューションで扱う施設データは、単一のデータ基盤( Amazon DynamoDB )を複数の視点で共有しています。ダッシュボードでは「地図 × 3Dデジタルツイン( AWS IoT TwinMaker ) × KPI」という俯瞰的な管理視点でデータを活用するのに対し、AIエージェントでは同じデータを担当者向けの対話型セルフサービス体験として提供します。さらに、 Amazon DynamoDB Streams 経由で知識グラフ( Amazon Neptune Analytics )へ自動同期されるため、参照系(可視化)と実行系(修繕依頼の起票)のどちらの操作を行っても、俯瞰と対話の両方の視点で常に最新かつ一貫した情報にアクセスできる点が本アーキテクチャの特徴です。 展示④ Amazon Quick ─ データの見せ方を変え、新たなインサイトを得る ここまでの展示で使用したデータを Amazon Quick で可視化すると、地図や AI チャットとはまた異なる切り口が見えてきます。 Amazon Quick には自然言語からダッシュボードを生成する機能があります。例えば、展示①で取得したエリア情報に関しても、地価や取引状況に着目したダッシュボードとして生成し直すと、経営管理ダッシュボードとして生まれ変わります。 このように、不動産に関するデータは見せ方・使い方・その粒度によって、様々なインサイトを我々にもたらしてくれます。同じデータでも、地図上のヒートマップとして見れば開発判断に、ダッシュボードとして見れば経営判断に活用できる。データと AI の組み合わせ方次第で、不動産業の意思決定は大きく変わります。 まとめ 今回のブースでは、不動産ビジネスの 開発・流通・管理、そして 可視化 という4つの視点を通じて、「AI 時代のデータ戦略」をお伝えしました。 開発 ── 国交省のオープンデータと自社データを広く掛け合わせ、メッシュ単位で AI が俯瞰的に解析する 流通 ── 自社システムのデータに AI がリアルタイムにアクセスし、顧客と直接対話して業務を完結する 管理 ── 設備・修繕履歴という深いデータを長期的に蓄積し、AI が予兆を読み 3D で可視化する 可視化 ── すべてのデータを Amazon Quick に統合し、生成 AI でダッシュボードを自動生成。経営判断を加速する 生成 AI の時代、まず取り組むべきは派手な AI 機能の開発ではなく、自社のデータを整え、つなぎ、AI に渡せる状態にすること。その第一歩を一緒に踏み出しませんか。 ブースにお越しいただいた皆様、ありがとうございました。展示内容についてのご質問や、自社での活用についてのご相談がございましたら、お気軽に担当のソリューションアーキテクトまでお問い合わせください。 本ブログは、ソリューションアーキテクトの奈良、Fikko が執筆しました。 関連リンク ・ 【開催予告】AWS Summit Japan 2026 建設・不動産向けブース展示
リアルタイム分析、バッチ処理、ビデオエンコーディング、科学モデリング、CPU ベースの機械学習推論など、計算量の多いワークロードを実行する場合、パフォーマンスのあらゆるパーセンテージポイントが重要になります。チェックでのコストを抑えながら、vCPU あたりのスループットが高く、メモリアクセスが速く、ネットワーク帯域幅が大きいインスタンスが必要です。 2026 年6 月 30 日、 AWS Graviton5 プロセッサを搭載した Amazon Elastic Compute Cloud (Amazon EC2) C9g および C9gd インスタンスが一般公開されたことを発表できることを嬉しく思います。C9g インスタンスはコンピューティングに最適化されており、前世代の C8g インスタンスと比較して、最大で 25% 高い vCPU あたりのパフォーマンスを提供しています。それは、DDR5 8800MT/秒 の DIMM、5 倍以上の L3 キャッシュ、Graviton4 ベースのインスタンスと比較して最大で 3 倍高いパケット処理パフォーマンスを備え、クラウド内のすべてのプロセッサインスタンスで最速のメモリを搭載しています。メモリが速く、キャッシュが大きいほど、ワークロードがデータの待機に費やす時間が短くなり、インメモリ分析のスループットが高くなり、エージェントループが速くなり、リアルタイムアプリケーションの応答性が向上します。 C9g インスタンスは、 Amazon Elastic Block Store (Amazon EBS) をストレージ用に利用できるバッチジョブ、ビデオエンコーディングパイプライン、または分散分析に最適です。また、同時実行環境や CPU に依存する推論ステップが、Graviton5 の高いコア数と大容量のキャッシュの恩恵を受けるエージェンティック AIワークロードにも適しています。AI が、質問への回答から、アクションの実行、コードの実行、複数ステップのタスクのオーケストレーションに変化するにつれ、CPU コンピューティングの需要は高まっており、C9g インスタンスはこの変化に対応するために構築されています。 一部のワークロードには、その計算能力に加えて高速のローカルストレージも必要です。HPC シミュレーション中のスクラッチスペース、ML 推論用の一時キャッシュ、広告配信エンジン用のローカルバッファなど、高速で低レイテンシーのローカル NVMe SSD ストレージがアプリケーションにメリットをもたらす場合は、C9gd を選択してください。 NVMe インスタンスストアボリュームを備えた Graviton5 ベースのインスタンスは、 詳細なパフォーマンス統計もサポートして、最大 1 秒の精度で I/O サイズごとに分類されたレイテンシーヒストグラムなどの高解像度 I/O メトリクスを提供しており 、 Amazon CloudWatch または nvme-cli 経由で追加コストなしでアクセスできます。 一目で分かる C9g インスタンスと C9gd インスタンス C9g インスタンスと C9gd インスタンスには、medium から 48xlarge まで 11 のサイズがあり、ベアメタルオプションもあります。前世代と比較して、サイズ全体で平均で最大で 15% 高いネットワーク帯域幅と 20% 高い EBS 帯域幅を提供します。最大の 48xlarge サイズでは最大 100 Gbps のネットワーク帯域幅と最大 72 Gbps の EBS 帯域幅を実現し、2 倍に増加しています。 C9g vCPU 数 メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 2 最大 15 最大 12 large 2 4 最大 15 最大 12 xlarge 4 8 最大 15 最大 12 2xlarge 8 16 最大 17 最大 12 4xlarge 16 32 最大 17 最大 12 8xlarge 32 64 17 12 12xlarge 48 96 25 18 16xlarge 64 128 34 24 24xlarge 96 192 50 36 48xlarge 192 384 100 72 metal-48xl 192 384 100 72 C9gd インスタンスは、前世代のローカルストレージインスタンスと比較して最大で 30% 高いストレージパフォーマンスを備えたローカル NVMe SSD ストレージを追加します。 C9gd vCPU 数 メモリ (GiB) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 2 1 x 59 最大 15 最大 12 large 2 4 1 x 118 最大 15 最大 12 xlarge 4 8 1 x 237 最大 15 最大 12 2xlarge 8 16 1 x 474 最大 17 最大 12 4xlarge 16 32 1 x 950 最大 17 最大 12 8xlarge 32 64 1 x 1900 17 12 12xlarge 48 96 3 x 950 25 18 16xlarge 64 128 1 x 3800 34 24 24xlarge 96 192 3 x 1900 50 36 48xlarge 192 384 3 x 3800 100 72 metal-48xl 192 384 3 x 3800 100 72 両方のファミリーは、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、ゲーム、動画エンコーディング、科学的モデリング、分散分析、CPU ベースの機械学習推論、広告配信などに適しています。 その他の機能は次のとおりです: インスタンス帯域幅設定 (IBC) では、Amazon EBS と Amazon VPC ネットワーキング間の帯域幅割り当てを最大で 25% 調整できるため、データベースやキャッシュなどの特定の帯域幅要件を持つワークロードのパフォーマンスを最適化できます。 拡張ネットワーキングの ENA Express サポート 最大 128 個の EBS ボリュームを仮想インスタンスにアタッチできます。 Savings Plans、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、専有ホストのサポート。 Nitro Isolation Engine C9g インスタンスと C9gd インスタンスは、 AWS Nitro System の新機能である AWS Nitro Isolation Engine を搭載した、最初のコンピューティングに最適化された Amazon EC2 インスタンスです。Nitro Isolation Engine は、Rust で実装された Nitro Hypervisor の専用コンポーネントであり、仮想マシン間の分離を適用します。VM メモリ、CPU レジスタの状態、および I/O デバイスへのすべてのアクセスを、最小限の API セットを通じて仲介します。 Nitro Isolation Engine の詳細については、 ブログ投稿 をご覧ください。スコープや前提を含む正式な検証結果の詳細については、 テクニカルホワイトペーパー を参照してください。 今すぐご利用いただけます Amazon EC2 C9g および C9gd インスタンスは現在、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト) の AWS リージョンでご利用いただけます。その他のリージョンも順次追加される予定です。 C9g および C9gd インスタンスは現在、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して起動できます。料金の詳細については、 Amazon EC2 の料金ページ をご覧ください。 詳細については、Amazon EC2 C9g および C9gd インスタンスページをご覧ください。また、フィードバックを AWS re:Post for EC2 に送信するか、通常の AWS サポートの連絡先を通じて送信してください。 – seb 原文は こちら です。
アプリケーションの TLS 証明書を管理している場合、証明書が期限切れになると、顧客にエラーが表示されるか、サービスが停止するという課題をご存知だと思います。証明書の有効期間が短くなるにつれて( 認証局 (CA)/ブラウザフォーラム により、最大有効期間を 2027 年 3 月から 100 日間に短縮し、2029 年までに 47 日に短縮することが義務付けられています)、手動更新プロセスは受け入れられなくなります。自動化が必要です。 自動証明書管理環境 (ACME) は、人間の介入なしで TLS 証明書をリクエスト、更新、および取り消すためのオープンプロトコルです。Let’s Encrypt と同じプロトコルであり、あらゆるプラットフォームで数十のクライアントによってサポートされています。 2026 年 6 月 30 日、 AWS Certificate Manager (ACM) でのパブリック証明書の ACME サポートについてお知らせします。ACM では、 Certbot 、 Kubernetes の証明書マネージャー 、 acme.sh 、または既に使用しているその他のクライアントなど、ACMEv2 互換のクライアントならどれでも動作するフルマネージド ACME サーバーエンドポイントが提供されるようになりました。標準の ACME プロトコルを使用して、 Amazon Trust Services からパブリック TLS 証明書を発行できます。 これまで、ACME プロトコルを使用した自動化された証明書管理を希望していた場合、ACM に加えて外部の認証局に頼っていたため、可視性が断片化されていました。ACM に保存されていた証明書もあれば、中央ダッシュボードなしで外部で管理されていた証明書もあります。PKI 管理者は、誰が証明書をリクエストできるか、またどのドメインが許可されるかを制御することができませんでした。 ACM の ACME サポートにより、1 つ以上のマネージド ACME エンドポイントをセットアップして、組織全体の ACME 証明書の使用状況を一元的に管理および監視できるようになりました。 PKI 管理者として、お客様は基本的な証明書発行に留まらない一元的な管理が可能になります。IAM ロールを ACME アカウントにバインドすることで、各クライアントがどのドメインをリクエストできるかをきめ細かく制御できます。エンドポイントレベルでドメインスコープを定義して、組織全体のポリシーを適用できます。また、一元的なモニタリングと可視化を同じ場所で行うことができます。 AWS CloudTrail はすべての証明書リクエストを監査できるようにログに記録し、 Amazon CloudWatch は運用メトリクスを追跡し、ACM は証明書の更新が近づくと有効期限通知を送信します。ACM を使用すると、PKI チームは ACM コンソール、API コール、ACME のいずれで発行された証明書であっても、すべての証明書を検索できます。 仕組み 開始するには、まず専用の ACME エンドポイントをセットアップし、外部アカウントバインディング (EAB) を使用して認証制御を設定し、エンドポイントが証明書を発行できるドメインを検証し、既存の ACME クライアントを新しいエンドポイントにポイントします。 ドメイン認証ステップは重要です。これにより、証明書の発行をセットアップできる者と証明書をリクエストできる者が区別されます。PKI 管理者は、管理者が保持している DNS 認証情報を使用して、エンドポイントレベルでドメインを 1 回検証します。証明書を必要とするアプリケーション所有者は DNS に触れることはありません。彼らは EAB 認証情報を使用して登録し、エンドポイントはリクエストを許可するドメインとスコープを適用します。つまり、DNS キーを一緒に配布しなくても、証明書の自動化を組織全体に広く配布できるということです。 このデモを、AWS Certificate Manager コンソールの [ ACME 証明書 ] ページから開始します。 このアカウントには既にいくつかのエンドポイントと証明書があります。新しいエンドポイントと証明書を最初から作成する手順を説明します。まず、[ ACME エンドポイントの作成 ] を選択します。 エンドポイントに名前を付けます。[ エンドポイントタイプ ] は [ パブリック ] です。ACME クライアントはパブリックインターネット経由で接続します。[ 証明書タイプ ] は [ パブリック ] です。証明書は Amazon Trust Services によって発行され、ブラウザとオペレーティングシステムによってデフォルトで信頼されます。証明書キータイプでは、デフォルトの ECDSA P-256 のままにします。RSA 2048 と ECDSA P-384 は、クライアントが必要とする場合にも使用できます。 下にスクロールして、ドメインを設定します。ドメイン名を入力し、ドメインスコープを選択します。スコープは、ACME クライアントがこのドメインに対してどの証明書パターンをリクエストできるかを正確に制御します。[ 完全一致ドメイン ] のみをチェックすると、クライアントはその特定のドメイン名の証明書のみをリクエストできます。[ サブドメイン ] を追加すると、どのサブドメイン (api.example.com や dev.example.com など) の証明書も許可されます。[ ワイルドカード ] を追加すると、ワイルドカード証明書 (*.example.com) が許可されます。スコープのチェックをオフのままにしておくと、ACME リクエストが有効であっても、このエンドポイントを使用するクライアントはそのタイプの証明書をリクエストできなくなります。本番環境のエンドポイントでは、厳密なセキュリティ体制を適用するために、[ 完全一致ドメイン ] と [ サブドメイン ] のみを有効にし、[ ワイルドカード ] のチェックをオフのままにしておくことができます。 また、ドロップダウンメニューから [ Amazon Route 53 ] ホストゾーンを選択します。その後、ドメインの検証に必要な DNS CNAME レコードが ACM によって自動的に作成されるので、手動で行う必要はありません。ドメインが Route 53 の外部でホストされている場合、代わりに DNS プロバイダーで提供された CNAME レコードを手動で作成します。これは、各クライアントが独自のドメイン検証を個別に処理する一般的な ACME のセットアップとは大きく異なります。 これらの一元管理により、PKI 管理者は、ドメインの認証、クライアントがリクエストできる証明書の種類 (ECDSAまたはRSA) の制限、およびワイルドカードの発行の一元的な制限を行うことができます。これらのガバナンス機能が組み込まれているということは、証明書ライフサイクル管理製品を別途購入したり、カスタムポリシーレイヤーを自分で構築したりする必要がないということです。どちらも、多大なコストと運用上のオーバーヘッドを伴います。 [ ACME エンドポイントの作成 ] を選択します 数秒後、エンドポイントが作成されます。コンソールには、次のステップが記載された [ セットアップの進行状況 ] トラッカーが表示されます。ドメインには [検証中] ステータスが表示されます。検証方法は DNS 検証であり、ACM は特定の CNAME レコードをチェックしてお客様がドメインを管理していることを確認します。作成時に Route 53 ホストゾーンを選択したので、[ Route 53 にレコードを作成 ] を選択して ACM に DNS 検証を自動的に処理させます。 検証は数秒で完了し、ステータスが [ 成功 ] に変わります。 次に、外部アカウントバインディング (EAB) 認証情報を作成する必要があります。EAB 認証情報は、ACME クライアントが ACME サーバーにアカウントを登録できるようにするキー識別子と HMAC キーペアです。登録が完了すると、クライアントは独自の非対称キーペアを生成し、それを使用してその後のすべての証明書要求を認証します。エンドポイントの詳細ページで、[ 外部アカウントバインディング ] タブを選択し、[ EAB の作成 ] を選択します。認証情報に名前を付け、オプションで有効期限を設定します。理想的には、クライアント登録を完了するのに必要な時間を超えないようにします。 [ EAB 認証情報の作成 ] を選択すると、コンソールに [ キー ID ] と [HMAC キー] が表示されます。ACME クライアントの設定に必要なので、これらの値を書き留めておきます。セットアップの進行状況に 4 つの緑色のチェックマークが表示されました。 証明書をリクエストする準備ができました。エンドポイントの詳細ページで、[ CLI リファレンスセクション ] を展開します。コンソールには、 Certbot と acme.sh の両方ですぐに使えるコマンド例が用意されています。Certbot コマンドをコピーし、 certbot/certbot イメージを使用してコンテナ内で実行します。 certbot certonly --standalone --non-interactive --agree-tos \ --email <EMAIL> \ --server https://acm-acme-enroll.us-east-1.api.aws/<ENDPOINT_ID>/directory \ --eab-kid <EAB_KID> \ --eab-hmac-key <EAB_HMAC_KEY> \ --issuance-timeout <ISSUANCE_TIMEOUT> \ -d <DOMAIN> プレースホルダーをエンドポイント URL、EAB 認証情報、およびドメイン名に置き換えます。 --eab-kid および --eab-hmac-key 引数は、前に生成した外部アカウントバインディング認証情報を使用して Certbot が ACME エンドポイントに登録する方法です。各 ACME クライアントにはこのステップ用の独自の構文があるため、正確なフラグについてはクライアントのドキュメントを確認してください。 Certbot は ACME エンドポイントとコンタクトし、Amazon Trust Services によって署名された有効な証明書を返します。 証明書をインストールする前に、 openssl を使用して証明書を確認します。 これで、証明書が ACM コンソールの [ ACME 証明書 ] タブに、コンソールまたは API を通じて発行された証明書とともに表示されるようになりました。 利用可能性と料金 AWS Certificate Manager の ACME サポートは現在、すべての商用 AWS リージョンでご利用いただけます。後日、AWS GovCloud (米国)、中国リージョン、および AWS European Sovereign Cloud パーティション も利用できるようになります。 料金は発行時に各証明書に含まれるドメインごとで、完全修飾ドメイン名とワイルドカードでは料金が異なります。ボリューム階層は、お客様の AWS アカウントで毎月発行されるすべての証明書全体のドメイン出現数の合計に基づいて計算されます。詳細については、 ACM 料金ページ をご覧ください。 開始するには、 AWS コンソールの ACM セクション にアクセスするか、 ドキュメント をお読みください。 – seb 原文は こちら です。
本記事は 2026 年 7 月 1 日 に公開された「 Run log analytics for a fraction of the cost with the new engine for Amazon OpenSearch Service 」を翻訳したものです。 Amazon OpenSearch Service はリアルタイムの検索・分析エンジンで、AI ワークロードからログ分析まで幅広く使われています。業界全体で見ると、組織が扱うログ量は毎年 30〜40% ずつ増え続けており、オブザーバビリティ基盤のインフラコスト膨張とクエリ速度の低下が避けられない状況です。必要なデータを残すか、予算を守るか。多くのチームがこの二択を迫られています。 今回、Amazon OpenSearch Service にログ分析専用の新エンジンが加わりました。価格性能比は最大 4 倍、データ取り込み速度は 2 倍、分析クエリは最大 2 倍高速、ストレージコストは最大 70% 削減されます。ログ分析に最適化しつつも、OpenSearch の強みである全文検索は同じデータに対してそのまま使えるため、コスト削減と検索能力のトレードオフに悩む必要がなくなります。 この記事では新エンジンの仕組み、使い始める手順、そして数十億ドキュメントを使ったベンチマーク結果を紹介します。 最適化エンジンの仕組み 最適化エンジンは Amazon OpenSearch Service ドメイン内の新しいエンジンモードです。コンソール、API、セキュリティモデル、ネットワーク設定はすべて汎用エンジンと共通なので、運用の仕組みを変える必要はありません。 内部では、すべてのデータが Apache Parquet 形式で保存されます。検索対象として設定したフィールドには転置インデックスも作られるため、カラムナストレージの効率と全文検索の速度を両立しています。クエリが来ると Apache Calcite が解析・最適化を行い、カラムナデータの集計は Apache DataFusion、全文検索は Lucene と、処理に応じて最適なエンジンに振り分けます。この 2 つはクエリの途中で連携するため、ログ本文の検索と集計を 1 回のリクエストで完結できます。 利用者から見ると、取り込みには汎用エンジンと同じ REST API やクライアントライブラリがそのまま使えます。エージェントやパイプラインの変更は不要です。クエリ言語は Piped Processing Language (PPL) と SQL の 2 つに対応しており、どちらもベクトル化エンジンで直接実行されます。なお Domain Specific Language (DSL) のクエリ API はローンチ時点では未対応です。 使い方 ローンチ時点では、最適化エンジンはドメイン作成時に選ぶドメインレベルの設定です。既存ドメインへの追加や、個別インデックス単位での有効化には対応していません。最適化エンジンを使うには新しいドメインを作成し、取り込みパイプラインをそちらに向ける必要があります。 Amazon OpenSearch Service コンソールで新規ドメインを作成し、ユースケースに Observability を選ぶと、最適化エンジンがデフォルトで有効になった状態でドメインが構成されます。コンソール上には両エンジンの機能比較が表示されるので、自分のワークロードにどちらが適しているか判断できます。 ドメインが準備できたら、汎用エンジンと同じ Bulk API とクライアントライブラリで JSON を投入できます。既存の取り込みパイプラインやアプリケーションコードをそのまま流用できるため、移行時にコード変更は不要です。 ログ分析向け最適化エンジンのメリット 新エンジンで得られる改善をまとめます。 最大 4 倍の価格性能比 — 私たちが実施したベンチマークで汎用エンジンと比較した結果です。インシデント調査用の全文検索も引き続き利用できます。 最大 2 倍の分析クエリ速度 — データをカラム単位のバッチにまとめて処理するベクトル化実行パスにより、大規模データセットでも高速に結果を返します。 最大 2 倍の取り込みスループット — 追記専用のカラムナ書き込みパスで、持続的な取り込みレートが向上します。 最大 70% のストレージ削減 — カラムナストレージにより同じコストで最大 3 倍のデータを保持できます。 以下のセクションでは、数十億ドキュメント規模のオブザーバビリティワークロードで実施したベンチマークの方法、環境、結果を説明します。実際のワークロードでの効果はユースケースごとに異なるため、ご自身の環境でもテストされることをおすすめします。 ベンチマークの方法 OpenTelemetry の Telemetry Generator で合成トレースとログを大量に生成し、OTEL トレース、OTEL ログ、Web サーバーアクセスログの 3 種類のデータセットを作りました。生成データは bulk 形式の NDJSON として Amazon Simple Storage Service (Amazon S3) に保存し、AWS Fargate 上の Amazon Elastic Container Service (Amazon ECS) パイプラインで取り込みました。パイプラインは S3 からチャンクを読み、タイムスタンプを変換して OpenSearch の Bulk API に書き込む構成で、本番のオブザーバビリティフローを再現しています。 テスト環境は OpenSearch 3.5 を動かす 2 つの OpenSearch Service ドメインで、それぞれ 3 アベイラビリティゾーン構成、データノード 9 台です。 構成 最適化エンジン Standard Lucene インスタンスタイプ 9x or2.4xlarge.search 9x r8g.4xlarge.search リーダーノード 3x m7g.large.search 3x m7g.large.search EBS 2,500 GB gp3、7,500 IOPS、500 MB/s (ノードあたり) 2,500 GB gp3、7,500 IOPS、500 MB/s (ノードあたり) エンジンモード OPTIMIZED General Purpose ( best_compression ) 3 データセット合計で 244 億ドキュメント、9.5 TB の生 JSON を取り込みました。インデックスは 9 プライマリシャード、1 レプリカで、ISM ロールオーバーはプライマリシャードあたり 50 GB に設定しました。Lucene 側は best_compression (zstd) コーデック + _source 有効で、一般的な本番構成を再現しています。 取り込みパイプラインは同一 VPC 内の Fargate タスク 90 個 (各 16 vCPU、120 GB RAM、48 ライタースレッド、バルクサイズ 3,000 ドキュメント) で実行しました。 結果 取り込みスループット 最適化エンジンは追記専用のカラムナストレージを採用しており、ドキュメントごとに stored field を書く必要がありません。複数ドキュメントをまとめてカラムナセグメントとして一括書き込みするため、高いスループットを実現しています。 メトリクス 最適化エンジン Lucene ベースライン ピークスループット 178 万 docs/sec 約 64.7 万 docs/sec ピーク時クラスタ CPU 62% 72% Write rejection 0 0 取り込みドキュメント総数 244 億 157 億 同じ並列度で毎秒 178 万ドキュメントを維持し、Lucene の約 2 倍のスループットを CPU 負荷を抑えながら達成しました。write rejection は両ドメインともゼロでした。1 日に数テラバイトを取り込むチームなら、同じ量をより少ないノードで捌けるか、同じインフラでより長い保持期間を取れることになります。 ストレージ圧縮 Parquet のカラムナ形式では、同じフィールドの値がまとめて格納されるため、辞書エンコーディングや型に特化した圧縮が高い効率で効きます。加えて、行単位で生 JSON を保持する必要がないため、オブザーバビリティデータのストレージを大幅に削減できます。 244 億ドキュメントでの実測値: データセット ドキュメント数 ソース 最適化エンジン Lucene (デフォルト) 圧縮率 vs. ソース Lucene 比削減率 Web ログ 87.6 億 2,360 GB 254 GB 614 GB 89% 59% OTEL ログ 82.0 億 3,720 GB 815 GB 1,549 GB 78% 47% OTEL トレース 74.3 億 4,131 GB 841 GB 1,790 GB 80% 53% 合計 244 億 9,539 GB 1,910 GB 3,953 GB 80% 52% 結果として、生 JSON に対して 5 倍の圧縮 (80% 削減) を達成しています。デフォルトの Lucene 構成 ( _source 有効) と比べてもストレージはおよそ半分です。最適化エンジンは _source をクエリ時に Parquet カラムから再構成するため、ドキュメントの取得機能を維持しつつ生 JSON を別途保存する必要がなくなっています。 分析クエリ性能 オブザーバビリティダッシュボードの典型的なパターンとして、数十億のログイベントに対し 15 分間のタイムウィンドウで絞った分析集計のレイテンシーを計測しました。最適化エンジンは @timestamp カラムの row-group プルーニングでクエリ対象外のデータをスキップし、必要な部分だけを読みます。 クエリパターン データセット 最適化エンジン Lucene ベースライン 高速化倍率 サービス別エラー数 OTEL ログ 717 ms 2.8 s 3.9x ホスト別ログ量 OTEL ログ 252 ms 17.6 s 70x サービス・メソッド別 5xx エラー OTEL ログ 171 ms 885 ms 5.2x エラー上位サービス OTEL トレース 635 ms 569 ms 約 1x ポイントルックアップ (単一 traceId) OTEL トレース 394 ms 783 ms 2x すべてのクエリは 15 分ウィンドウでスコープ。インデックスサイズ: OTEL ログ 82 億イベント、OTEL トレース 74 億スパン。 最適化エンジンは、数十億ドキュメントに対する時間フィルター付き分析クエリを 171 ms〜717 ms で完了しました。特にフィルターなしの集計 (ホスト別ログ量: 70 倍高速) で差が顕著に現れており、必要なカラムだけを読むカラムナエンジンの特性が効いています。一方、Lucene の転置インデックスが高い選択性を発揮するクエリ (トレースのエラー上位サービス) では両者の性能は同程度でした。 検索とポイントルックアップ 分析だけでなく検索も高速です。最適化エンジンはカラムナストレージと Lucene 転置インデックスの両方を持っており、クエリプランナーが選択的なルックアップ (特定の traceId の検索など) を検出すると、カラムナスキャンではなく転置インデックスにルーティングします。74 億スパンに対する単一 traceId ルックアップは 165 ms で完了しました。 実際の障害調査では、まず集計で問題を絞り込み、次にポイントルックアップで該当トレースを引く、という流れが 1 つのドメインで完結します。 提供開始 Amazon OpenSearch Service のログ分析向け最適化エンジンは、OpenSearch Optimized Instances が利用できるすべての商用 AWS リージョン (AWS GovCloud (US) および中国リージョンを除く) で一般提供されています。 料金はインスタンスとストレージの標準 Amazon OpenSearch Service 料金に準じ、最適化エンジンの追加費用はかかりません。詳細は Amazon OpenSearch Service の料金 を参照してください。 設定と使い方の詳細は Optimized for Log Analytics (Amazon OpenSearch Service ドキュメント)、サービス概要は Amazon OpenSearch Service Log Analytics を参照してください。 フィードバックは AWS re:Post for Amazon OpenSearch Service または AWS サポートまでお寄せください。 著者について Jagadish Kumar Jagadish は Amazon Web Services のシニアソリューションアーキテクトで、OpenSearch と分析ワークロードを担当しています。 Rohin Bhargava Rohin は Amazon OpenSearch Service のシニアプロダクトマネージャーです。 Michael Supangkat Michael は Amazon Web Services のソリューションアーキテクトで、検索とオブザーバビリティを専門としています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。