本記事は 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 がレビューしました。

Kiro 好きの Solutions Architect の吉村です。普段はヘルスケア業界のお客様の技術支援に加えて、業界問わず Developer Experience に関するご支援をさせていただいております。 本記事では、医療情報システム開発で避けて通れない数多くの業界ガイドラインに対して、Kiro を医療情報システム開発をよく理解したチームの一員へと育て上げ、一緒に立ち向かうというアプローチをご紹介します。本アプローチは、 第 30 回日本医療情報学会春季学術大会 の AWS ブースや AWS Summit Japan 2026 のヘルスケアブースでのデモ展示で、来場者の皆様と議論し、好意的なフィードバックをいただいたものをベースにしています。 はじめに 医療情報システムの開発には、 医療情報システムの安全管理に関するガイドライン 第 7.0 版 （いわゆる 3 省 2 ガイドラインの 1 つで、厚生労働省が定めるもの。以降「医療情報ガイドライン」）や、 電子カルテの標準仕様 、公共 SaaS 要件 ( GCAS ガイド ) など、参照するべき業界ガイドラインが数多く存在します。医療領域で AI を使おうとする多くの開発現場が「AI 駆動開発でスピードを上げたいけど、大量の業界ガイドラインをどう扱えばいいのか」という悩みに直面します。 今回のアプローチは、AI 活用のベストプラクティスを組み合わせた実験的なもので、皆さんの組織やプロジェクトに合わせて取捨選択・カスタマイズして使うことを前提とします。本記事では Kiro の Agent Skills と Agent Steering で具体化しますが、本質は動的に読み込める知識と開発ルールを与えることにあります。そのため Claude Code など他のコーディングエージェントでも応用でき、皆さんの普段の開発に後付けで組み込めます。 医療情報システム開発で AI 駆動開発がぶつかる壁 規制やガイドラインの多い医療ドメインでは、AI 駆動開発にまつわる様々なアンチパターンに遭遇することがしばしばあります。具体的なアプローチに入る前に、まずは私たちがぶつかる壁を整理します。 AI 駆動開発における課題 大規模言語モデル (LLM) には、コンテキストウィンドウ（エージェントが一連の作業の中で参照できる情報の枠）があります。ここにはシステムへの指示、会話の履歴、読み込んだファイル、ツールの実行結果などが収まり、その容量はトークン量で決まる有限の予算のようなものです。コンテキストウィンドウが大きくなればそれだけ多くの情報を投げ込めて、より良い結果が得られると考えがちですが、実際はそう単純ではありません。入力が長くなるほどパフォーマンスが低下することが、近年さまざまな研究で報告されています。 Chroma が 2025 年に公開した技術レポート 「Context Rot: How Increasing Input Tokens Impacts LLM Performance」 で、入力長が増えると単純なタスクでも性能が大きく変動すると報告しています。 We observe that model performance varies significantly as input length changes, even on simple tasks. Nelson F. Liu 氏らが 2023 年に発表した研究 「Lost in the Middle: How Language Models Use Long Contexts」 では、関連情報が長いコンテキストの中間に置かれると見落とされやすい傾向が報告されています。 significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models. Philippe Laban 氏らが 2025 年に発表した研究 「LLMs Get Lost In Multi-Turn Conversation」 は、指示が曖昧なまま会話がマルチターン化すると、トップクラスのモデルでも性能が低下する。一度誤った仮定を置くと、その後もそれに固執して立て直せなくなる傾向があると報告しています。 when LLMs take a wrong turn in a conversation, they get lost and do not recover クラウド上のワークロードを設計・運用するためのベストプラクティス集である AWS Well-Architected Framework の Agentic AI Lens でも、今のタスクに必要なものだけを組み立て、残りは圧縮・要約することをベストプラクティスとして挙げ、会話履歴やツール定義を毎回すべて詰め込むことをアンチパターンとしています。 これらは、曖昧な指示が AI を不要な仮定へと突き進ませるという現場の実感とも重なります。さらに不要・冗長な情報を詰め込めば、いわゆる AI slop と呼ばれる質の低い出力やハルシネーションを招きます。結果として、指示の質によって成果物の品質に差が生まれます。 医療情報システムにおける課題 こうした一般的な問題に、医療領域ではドメイン固有の事情が重なります。まず、参照するべき業界ガイドラインが大量にあります。医療情報ガイドラインだけを見ても、 概説編 ・ 経営管理編 ・ 企画管理編 ・ システム運用編 ・ 保守委託機関編 の 5 編から成り、全体で 160 ページを超えます。医療情報ガイドライン全体の概要は、AWS ブログ「 医療情報ガイドラインをクラウド上で実践する -概要編- 」でも解説しています。さらに標準仕様に準拠した電子カルテの開発では、GCAS ガイドや電子カルテの標準仕様書の遵守が必要で、Web ページや大量の PDF・エクセルなど形式もさまざまです。これらを人間がすべて理解して AI に的確に指示するのは、簡単ではありません。 ここで 1 つ皆さんにクイズです。Kiro IDE は添付したドキュメントをネイティブのドキュメントブロックとして読み込むことができますが、「医療情報ガイドラインのうち、システム運用編という 1 編だけを添付したら、Claude Opus 4.8 の 100 万トークンのコンテキストは何割くらい埋まるでしょうか？」 Claude Opus 4.8 で医療情報ガイドラインのシステム運用編を添付した直後のコンテキスト消費量 実際に Claude Opus 4.8 で試すと、 この 1 編だけで対話開始時点のコンテキストの約 29% が消費されました。全 5 編ではさらに膨らみ、加えて開発標準や MCP も読み込まれると、やり取りできる余地はますます狭まります。コンテキスト上限に近づくと、多くのコーディングエージェントでは内容が自動的に圧縮 (コンパクション) されます。このことからも、ドキュメントを「とにかく全部 AI に渡す」のは筋が悪く、「必要なときに、必要な情報を、必要な分だけ」渡すべきです。 そして、最終的な妥当性を担保し、責任を持つのは人間です。ドキュメントを与えずに指示を出す場合、その人の理解度がそのまま AI への指示の正確さと出力の精度を左右します。結果として、関わるロールや習熟度によって、指示や成果物の品質に差が生まれやすくなります。 医療情報システムの AI 駆動開発が直面する課題 Kiro をチームの一員に育て上げる ここまで見てきた課題に立ち向かうために、Kiro を「医療情報システム開発をよく理解したチームの一員」に育て上げます。医療情報システム開発に必要な知識と組織の開発の進め方を少しずつ授けていきます。 Kiro とは Kiro は、AI にコードを書かせるだけの段階を越えて、エージェントと協働してソフトウェアを設計・実装する、agentic engineering のための開発環境です。プロンプトから実行可能な仕様 (Spec) を起こす 仕様駆動開発 や、複数のエージェントによる並行作業などを特徴とし、今回活用する Agent Skills・Agent Steering のほか、 MCP ・マルチモーダル入力・ ドキュメント添付 といった機能を備えています。 アプローチの全体像 本記事では、[企画] → [準備] → [開発] → [改善] という 4 つのフェーズに沿って、ソフトウェア開発ライフサイクル (SDLC) 全体を通してこのアプローチを見ていきます。 [企画] Kiro と壁打ちしてアイデアを言語化 [準備] ガイドラインの知識を Agent Skills として与え、コンテキストを構築 [準備] 開発標準やルールを Agent Steering として与え、ハーネスを構築 [開発] 要件定義から設計・実装・テスト・デプロイなど、SDLC 全体を Kiro と一緒に推進 [改善] 開発で見えた学びやプロダクトの成熟度に応じて、知識やハーネスを洗練 企画・準備・開発・改善の 4 フェーズと、各フェーズ共通の制御ループ この 4 つのフェーズに共通して、人間と AI が交互に手を動かしながら、以下の制御ループを繰り返します。 人間が AI にタスクを依頼 AI が計画を作成 人間がレビュー AI が計画を見直し 人間が計画を承認 AI が計画を実行 人間が AI の成果物を検証 このループを各フェーズで回すことで、Kiro に丸投げするのではなく、人間が意思決定権と監督責任を持ち続けます。 しかし、人間の意図は曖昧性をはらんでいます。出発点が曖昧になると AI は不要な仮定を置き、望んでいない方向へ進み始めます。この曖昧性をできる限り排除するために、Kiro が作成する計画の中に、曖昧な部分についての逆質問を含めさせます。曖昧なまま進めず、不明点を [Question] として挙げさせ、人間が [Answer] で意図を伝え、独自の判断で先に進ませません。計画に合意してから実行に移すことで、曖昧な指示による手戻りを未然に防げます。 AI に逆質問させるプロンプト例。不明点を [Question] で挙げさせ、人間が [Answer] で意図を伝える それでは、各フェーズを具体的に見ていきます。 [企画] Kiro と壁打ちして構想を固める これから作るものの構想を、Kiro と壁打ちしながら言語化します。漠然としたアイデアを整理し、ビジネスチームとエンジニアチームが同じ言葉で議論できる共通認識をつくります。 このとき活躍するのが、Kiro のマルチモーダル入力です。ホワイトボードのラフな構成図や手書きのスケッチ、画面イメージなど、言語化しにくいものを画像で渡し、Kiro と対話しながらドキュメントへ落とし込めます。 あわせて、構想の実現可能性や業界の動向も Kiro と一緒に調べ、技術的な選択肢や懸念点を洗い出しながら具体化します。ここでも制御ループが効き、計画段階での逆質問で曖昧な構想の穴を早めに埋められます。 [準備] ガイドラインの知識を Agent Skills として与える ここからが、Kiro へ開発に必要なコンテキストを与えるフェーズです。 まずは、医療情報システム開発に必要なガイドラインの知識を Agent Skills として用意します。スキルは動的に読み込まれるので、Kiro は常に全文を抱え込むのではなく、そのとき必要な知識だけを読み込んで参照します。大量のガイドラインで最初からコンテキストを圧迫することなく、「必要なときに、必要な情報を、必要な分だけ」読み込みます。 スキルの作り方はシンプルで、Kiro 自身にスキルを作らせます。医療情報ガイドラインのような PDF はドキュメントとして直接添付し、GCAS ガイドのように Web で公開されている情報はビルトインの web_fetch ツールでコンテキストに取り込みます。あとは全体像で触れた制御ループに沿って、どんな粒度で分割すべきかを Kiro に計画させ、曖昧な部分は質問させて詰めたうえで、計画を承認してからスキルを生成、成果物を人間がレビューします。 たとえば、ネットワークや認証、データ管理、セキュリティといったトピックごとのスキルに分割し、 SKILL.md にどんな場面で参照すべきかという説明を、 references フォルダに詳細な要件をまとめた参照ファイルを配置します。 [準備] 開発標準を Agent Steering として与える スキルで知識を渡したら、次は開発の進め方を Kiro に教えます。Agent Steering は、ワークスペースの標準やアーキテクチャ、コーディング規約といった前提を Markdown ファイルに定義しておくと、セッションのたびにユーザーが指示しなくても自動的にコンテキストへ読み込まれる仕組みです。プロダクト概要 ( product.md )、技術スタック ( tech.md )、プロジェクト構造 ( structure.md ) といった基盤ファイルや、コーディング規約などの独自ファイルを用意できます。 ここでハーネスという考え方を取り入れます。ハーネスとは、AI を信頼できる開発の担い手にするために、その周りに用意する仕組みです。どれだけ高性能なモデルでも、それ単体で常に期待どおりに動くとは限りません。適切なコンテキストを渡し、進め方や守るべきルールを与え、振る舞いを制御し、出力を検証する。こうした足場を整えてはじめて、AI に開発の一員として安心して任せられるようになります。 ハーネスは単一の機能ではなく、複数の要素の組み合わせです。たとえば、知識を与える Agent Skills、開発の進め方や規約を効かせる Agent Steering、外部のツールやデータへ安全につなぐ MCP、成果物を機械的に検査するテストや静的解析などです。Agent Steering はこれらのピースの一つです。 最初から完璧に作り込む必要はありません。小さく始めて、開発を回しながら見えてきた学びを少しずつ反映したり、プロジェクトの成熟度に合わせて洗練させていくのが現実的です。 たとえば、すでに組織の開発標準や設計方針がドキュメント化されているなら、それらを入力に Kiro と一緒に Agent Steering へ落とし込めます。まだなければ、制御ループの中で Kiro に組織の開発プロセスのあるべき姿を深掘りさせ、一緒に形にしていくこともできます。これらをプロジェクトのハーネスの出発点にすることができます。 ここまで見てきた Agent Skills も Agent Steering も、その実体は Markdown ファイルです。そのため、ソースコードと同じように Git などのバージョン管理ツールで変更を追跡でき、GitHub などを通じてプロジェクトのメンバー全員へ配布できます。こうして育てた Kiro のコンテキストとハーネスは、チームの共有資産として扱えます。 [開発] 整えた土台の上で、Kiro とともに開発する 準備フェーズまで終えると、実は開発フェーズで新しくお伝えすることは、それほど多くありません。ここまで整えてきたコンテキストとハーネス、そして制御ループの上で、皆さんの組織の開発プロセスと設計手法に沿って開発を進めるだけです。 ただし、これは従来どおりの開発を行うだけではありません。Kiro とともに AI ネイティブな開発へとシフトします。人間は実現したい意図を Kiro に伝え、制御ループの中でその意図を一緒に洗練し、コードやドキュメントを書く作業そのものは Kiro に任せます。そのうえで人間は、生成された成果物をレビューし、最終的な意思決定と監督責任を担う立ち回りへと移ります。 開発の進め方そのものは、組織やプロジェクトによってさまざまです。たとえば、チームのための AI ネイティブな開発方法論である AI-DLC を実践するために、OSS で公開されている補助ツール AI-DLC Workflow をベースにしたとします。AI-DLC は Inception・Construction・Operations の 3 つのフェーズからなり、クロスファンクショナルなチームがモブワークで AI と協働し、AI の提案をその場で検証しながら進めるのが特徴です。 要件定義のフェーズ (Inception) では、ユーザーに届けたい価値を起点にユーザーストーリーや受け入れ基準を定義し、並行開発できる単位へとタスクを分解します。 設計・実装のフェーズ (Construction) では、詳細設計から実装、テストへと進めます。このとき Kiro は、準備フェーズで与えたガイドラインの知識や開発標準を参照しながら、成果物を生成します。これらの成果物を人間が検証していきます。 ただし、AI-DLC Workflow はあくまで一例です。重要なのは、皆さんの組織固有の開発プロセスそのものを Kiro に教え、AI ネイティブなプロセスへと変革させていくことです。 AI-DLC については「 AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 」をご参照ください。 [改善] ハーネスを育て続ける ここまで構築してきたコンテキストとハーネスは、一度作って終わりではありません。開発で得た学びやプロダクトの成熟度に応じて、コンテキストとハーネスの 2 つの面から育て続けます。 まず、Kiro に与えた知識（コンテキスト）を最新に保ちます。医療情報ガイドラインのように、規制やガイドラインそのものが改定されることもあります。こうしたとき、改定版を読み込ませて変更点を整理し、該当する Agent Skills を更新すれば、最新の内容に追従し続けられます。膨大な改定内容の読み込みと差分の整理を、Kiro は人間よりはるかに高速にこなせます。これが、規制やガイドラインの多い医療ドメインで、AI ネイティブな開発を行う意義でもあります。 あわせて、開発を支える仕組み（ハーネス）も強化します。たとえば SAST (静的解析) やテストを整備し、ガイドライン遵守・セキュリティ・品質の観点を継続的に検査できるようにします。さらに Kiro の Agent Hooks を使えば、ファイルの保存やタスクの完了といったイベントをきっかけに、これらの検査やレビューを自動で実行できます。手作業の抜け漏れやセキュリティ上の見落としを、仕組みで防げるようになります。 こうしてコンテキストとハーネスが育つほど、Kiro は医療情報システム開発を理解したチームの一員として、ますます頼れる存在になっていきます。 このアプローチの何が嬉しいか ここまで、Kiro をチームの一員に育て上げる流れを見てきました。このアプローチがもたらす効果を整理します。 1 つ目は、開発に関わる全ロールが「同じ前提を備えた Kiro」と協働できることです。医療情報システム開発に必要な知識も開発標準も Kiro 側に持たせているため、それらを参照するのは人間ではなく Kiro です。企画担当も設計者も実装者も QA も、同じ知識とハーネスを備えた Kiro を相棒にできます。これにより、人間が的確な指示を出す難しさや曖昧さを、組織全体で減らせます。 2 つ目は、いま使っている開発プロセスに後付けできることです。このアプローチの本質である Agent Skills と Agent Steering は Markdown ファイルにすぎません。そのため、既存のワークフローやツールチェーンを置き換える必要はなく、非侵襲的に組み込めます。ゼロから作り直さなくてよいので、導入のハードルも低いです。 そして 3 つ目は、組織全体の AI 活用のバーを引き上げられることです。こうして育てた Kiro は、組織全体で共有できます。AI はあくまで人の力を増幅する Amplifier であり、担当者ごとの個人差そのものがなくなるわけではありません。ただ、知識もハーネスもない素の状態に比べれば、どの役割の人もより良い結果にたどり着きやすくなります。 まとめ 本記事では、医療情報システム開発で避けて通れない数多くの業界ガイドラインに対して、Kiro をチームの一員に育て上げて一緒に立ち向かうアプローチをご紹介しました。大量の業界ガイドラインを抱え込んでコンテキストを圧迫するのではなく、ガイドラインの知識を Agent Skills として与え、開発標準を Agent Steering として最初のハーネスを組み込み、制御ループの中で人間が意思決定権と監督責任を持ちながら Kiro と協働する。その土台作りと洗練を重ねることが、このアプローチの核です。 冒頭でも触れたとおり、このアプローチは確立された方法ではなく、AI 活用のベストプラクティスを組み合わせた実験的なものです。だからこそ、皆さんの組織やプロジェクトに合わせて取捨選択し、カスタマイズしていただければと思います。本質は動的に読み込める知識と開発ルールを与えることなので、いま使っているコーディングエージェントや開発プロセスに後付けで試せます。まずは小さなスキルやステアリングを 1 つ作るところから、Kiro と一緒に始めてみてください。 皆さんの開発現場で Kiro が頼れるチームの一員になることを願っています。そしてより良い医療情報システムをより早く提供できる未来を信じています。 著者について Hiroaki Yoshimura AWS Japan のパブリックセクターのソリューションアーキテクトです。ヘルスケア領域のお客様への技術的なご支援と、業界を問わずお客様の Developer Experience に関わるご支援を行っています。また、Kiro に関する ブログ投稿 やイベント登壇も行っています。

AWS Summit が各地で開催されており、多忙な日々を過ごしています。私は New York City Summit において、「Building AI architectures with AWS Serverless」というワークショップを開催しました。そして、ビルダーたちが、エージェントとサーバーレスサービスを組み合わせて、わずか半日で実際の課題を解決していく様子を見るのは、とても楽しいものでした。6 月 29 日週は Washington, DC Summit に向かいます。このイベントは、常に公共部門におけるイノベーションにスポットライトを当てています。現地にいらっしゃる方は、ぜひお声がけください。 これらのイベントで私がよく受ける質問の 1 つは、「エンジニアリングの長いバックログの解消を待つことなく、チームはどのように AI を業務で活用できるのか」というものです。そして、今週最大のリリースは、まさにその問いに応えるものでした。Amazon Connect Customer は、ビジネスチームがノーコードで AI を活用したカスタマーエクスペリエンスを自ら設計するための方法を提供します。それでは、6 月 29 日週の AWS ニュースを見ていきましょう。 主なトピック Amazon Connect Customer は、AI を活用したセルフサービスエクスペリエンスを設計およびデプロイするためのノーコードキャンバスである Agentic CX Designer (NLX) をプレビューとしてリリースしました。ビジネスチームは、エージェンティック AI と決定論的 AI を、ガバナンスの効いた単一のフローに統合した音声およびデジタルエクスペリエンスを構築してリリースできます。これにより、設計から、テスト、シミュレーション、そして本番対応のエクスペリエンスまでを、数か月間ではなく数週間で完了できるようになります。今回のリリースには、プレビュー版の Live Sync も含まれています。これは、顧客が話したり、入力したりするのに合わせて、ウェブやモバイルでのエクスペリエンスをリアルタイムで連動させる特許取得済みのテクノロジーです。発信者は、会話を中断することなく、フォームへの入力や適切な製品ページの表示を行うことができます。誰がカスタマーエクスペリエンスを設計するのかを、これがどのように変革するのかにを知るには、「 business user is the new architect of customer experience 」というブログ記事をお読みいただくとともに、 Amazon Connect Customer ページにアクセスしてください。 6 月 22 日週のリリース 6 月 22 日週のリリースのうち、私が注目したリリースをいくつかご紹介します: AWS Lambda MicroVMs – 各ユーザーまたはジョブ VM レベルの分離を提供する新しいサーバーレスコンピューティングプリミティブ。ほぼ瞬時の起動および再開速度に加えて、実行を一時停止し、最大 8 時間後に再開する機能も備えています。Firecracker を基盤として構築されており、仮想化インフラストラクチャの管理や、分離、速度、状態のトレードオフを強いられることなく、マルチテナントアプリケーション内でユーザーや AI が生成したコードを実行できるよう設計されています。 Amazon EC2 AMI ウォーターマーク – プライベート AMI にカスタム識別子を埋め込むことができます。この識別子は、コピー、リージョン、アカウント共有にわたって、派生するすべての AMI に自動的に引き継がれます。許可された AMI や宣言型ポリシーとウォーターマークを組み合わせることで、承認されたイメージに対してのみ起動するよう制限できます。これは、すべての AWS リージョンで追加コストなしでご利用いただけます。 AWS Outposts セルフサービスおよびライフサイクル管理 – コンソール、CLI、API から直接、セルフサービスの設定、見積り、注文、サブスクリプションの管理、更新、および廃止を追加します。新しい見積りツールは、数秒でリアルタイムのコスト見積りを生成し、お客様が注文を送信する前に、アカウントやリージョンレベルの制約を表示します。 Amazon MSK AI エージェントスキル – Kiro、Claude Code、Cursor などの AI コーディングアシスタントに、Amazon MSK の運用に関する専門的かつ最新のガイダンスを提供します。これは、トラブルシューティング、サイズ設定、設定、モニタリング、および外部 Kafka クラスターから MSK Express への移行をカバーします。かつては専門知識が必要だったタスクが、デベロッパーが自力で完了できるガイド付きのプロセスとなります。 Amazon OpenSearch Service の AI が支援する移行 – Migration Assistant にエージェントがガイドするエクスペリエンスが含まれるようになりました。これは、Kiro や Claude Code などのツールを利用して、セルフマネージド型の Apache Solr、Elasticsearch、または OpenSearch のデプロイを OpenSearch Serverless やマネージドクラスターに移行するのに役立ちます。また、Solr 向けに、ライブトラフィックキャプチャおよびリプレイのサポートも新たに追加されています。 Amazon GuardDuty の AI を活用した調査 (プレビュー) – 実際の脅威と無害なアクティビティを区別するのに役立つよう、ナレッジグラフや脅威インテリジェンスを使用し、直近 90 日間のコンテキストや関連アクティビティを調査して、検出結果とアカウントを自動的に分析します。各調査では、信頼度スコア、MITRE ATT&CK 分類、実用的なレコメンデーションを含む判定結果が数分で返されます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: MySQL 向けのオープンガバナンス – Oracle は、MySQL 向けのコミュニティガバナンスモデルを発表しました。これは、Oracle 以外の組織にもプロジェクトにおける明確な役割を与えるものです。これには、新たに設置される Steering Committee に Oracle 以外の組織向けの 4 つの席を設けることや、GitHub を一般公開することが含まれます。AWS も席を有しており、この取り組みを支持する理由や、MySQL を利用するすべてのユーザーのために、既にアップストリームへの修正を提供していることについて説明しています。 AWS 認定を最新の状態に保つ新しい方法 – 対象となる AWS 認定は、あらためて受験する代わりに、AWS Skill Builder において、厳選されたトレーニングとハンズオンラボを完了することで、有効期間をさらに 1 年間延長できるようになりました。このオプションは現在、一部の Associate および Professional 認定を対象にオープンベータ版として提供されており、年内には対象がさらに拡大される予定です。 2026 年応募者向け「All Builders Welcome Grant」完全ガイド – AWS Builder Center で公開されているコミュニティガイド。キャリア初期のビルダーを対象に、この助成金の申請方法を順を追って説明しています。これは、AWS re:Invent 2026 のフルカンファレンスパス、航空券、ホテル費用をカバーします。現在応募を受け付けており、締め切りは 7 月 14 日です。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 他のビルダーと直接交流する機会をお求めですか? お近くの都市で開催される AWS Summits をチェックしたり、世界中のユーザーグループが主催する地元の AWS Community Day を探したり、 AWS Builder Center でチュートリアル、コミュニティコンテンツ、スキルアップのための方法を探索したりしてみてください。 6 月 29 日週のニュースは以上です。7 月 6 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Micah 原文は こちら です。

本ブログは ITbook 株式会社 様とAmazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの尾形龍太郎です。 公共調達の提案書づくりに携わったことがある方なら、調達仕様書と評価基準を何度も読み返し、必須項目の取りこぼしに神経をすり減らした経験があるのではないでしょうか。締め切り間際に「あの加点項目はどこに書いたのか」を探し回る時間も、その一つです。本ブログでは、自治体・国向けのコンサルティングを手がける ITbook 株式会社様が、 Amazon Bedrock を活用した提案書作成支援システムを構築し、ドラフト作成にかかっていた約十日分の作業を半日にまで短縮した取り組みをご紹介します。生成 AI を「人の代わり」ではなく「人が考える時間を生み出す道具」として組み込んだ、コンサルティング会社の新しい働き方の事例です。 お客様の状況と課題 ITbook 株式会社様は、自治体・国の案件に対して提案書を提出し、案件を獲得していくコンサルティング事業を主軸とする企業です。提案活動の起点になるのが、公共機関から示される調達仕様書や評価基準書を読み解き、限られた期間内に提案書を仕上げる作業です。 この提案書作成は、コンサルタント一人ひとりの知見と経験が大きく活きる、専門性の高い業務です。一方で、案件数の増加に伴い、事前調査や構成の作り込みにかけられる時間を案件ごとに十分確保することが、組織共通のテーマになっていました。提案の評価を最大化するうえで、評価基準で求められる必須項目や加点項目を確実に押さえる精度を、組織全体で一段引き上げることの重要性が増していました。 とりわけ繁忙期には複数の案件が同時に進行し、提出期限までに構成を磨き込む時間の確保が大きな論点になっていました。過去の類似案件や関連資料を数十件単位で読み込む準備作業の負荷も大きく、コンサルタントが本来注力すべき提案の中身づくりに、より多くの時間を振り向けられる仕組みが求められていました。案件数が増えるほど効果が見込める、品質を保ちながら数をこなすための仕組みづくりが課題でした。 解決策の検討 ITbook 株式会社様がまず明確にしていたのは、「機械的にできる部分は AI に任せ、人は代替のきかない部分に集中する」という考え方でした。ITbook 株式会社様は、コンサルタントの強みは最新情報の反映や複数の知見の統合といった思考にあると考えました。その前段にあたる「調達仕様書を読み、必須項目を整理し、提案のドラフトを組む」工程をいかに短縮できるかが、解決したいテーマでした。 この課題に対し、当初は社内プロセスの整備で対処するか、生成 AI を活用するかが議論されました。検証を進める中で、評価基準と提案内容を突き合わせて構造化する作業は生成 AI が得意とする領域であり、十分な品質が見込めると判断したことから、Amazon Bedrock を採用する方向に至りました。 AIMS（ISO/IEC 42001） を取得し AI ガバナンスを重視する同社にとって、データを学習に使わない形で基盤モデルを利用できる Amazon Bedrock は、自治体の機微な情報を扱う上でも安心して採用できる選択肢でした。 ソリューションの概要 構築したシステムは、社内で利用している提案書作成支援システムです。提案担当のコンサルタントや営業担当者が、公共機関向け提案の初期フェーズで利用します。 利用者はまず提案の概要を入力し、続いて提案依頼書・調達仕様書・評価基準書・提案書作成要領などの資料をアップロードします。システムはこれらの資料を生成 AI で読み解き、 提案依頼書 の概要（背景・課題）、提案に含めるべき提案項目、採点基準（必須・加点）、遵守すべき制約条件を抽出して画面に整理します。抽出結果は人が確認・編集できるようになっており、調整が必要な箇所はその場で編集できます。 図1：システム画面 図2：抽出した提案項目一覧 整理された情報をもとに、システムは提案書のアウトラインを生成します。これは目次ではなく、各章で何をどの目的で書くかを示した、生成 AI 向けの指示書です。利用者がアウトラインを確認・調整したうえで本文生成を実行すると、章ごと、あるいは全章の提案書ドラフトが生成されます。一連の流れには人が確認・修正を挟む Human-in-the-loop の設計が貫かれており、生成結果をそのまま使うのではなく、人が記載内容を確認・修正して仕上げていける構成になっています。 図3：生成した提案書のアウトライン ソリューションの構成 システムは AWS 上で構築されており、提案書の生成エンジンとして Amazon Bedrock を中心に据えています。アップロードされた提案資料は Amazon S3 に保存され、提案書生成時に生成 AI へ直接渡されます。一方、過去の提案内容や都道府県のガイドラインといった参照知識は、これらの提案資料とは別にナレッジとして登録し、 Amazon OpenSearch Service を用いた検索基盤を通じて本文生成時に参照します。利用者は、どのナレッジを使うか、いつの時点の資料を参照するかを選択でき、古くなった情報を除外する運用も行えます。 このシステムの技術的な要点は、提案書生成の処理を一つにまとめず、役割ごとに分割した点にあります。 提案依頼書から、いきなり本文を生成するのではなく、まず「提案書を生成するために必要な情報の抽出」を行い、その結果をもとにアウトライン作成、本文生成へと段階を踏みます。本文生成では、 Amazon Bedrock AgentCore Runtime と Amazon Bedrock AgentCore Gateway を用いたナレッジ検索ツールを組み合わせ、ディープリサーチのように必要な情報を追加で検索しながら本文を生成する、エージェント型の構成を採用しています。 図4：システム構成 処理を分けたことは、品質とコストの両立にもつながりました。提案依頼書の概要抽出や提案項目の抽出といった比較的単純な工程には軽量なモデルを割り当ててコストを抑え、最も思考力が求められる本文生成にコストを集中させる設計です。基盤モデルには Amazon Bedrock 上の Anthropic の AI モデル Claude を中心に用いて、用途に応じて軽量なモデルも使い分けています。ドキュメントの取り込みでは、抽出結果をマークダウン形式に整えることで後続処理の精度を高める工夫も取り入れました。 開発を通じて得られた学びは、「必要な情報さえ正しく抽出できれば、出力品質はある程度担保できる」という見立てでした。だからこそ、元データから必要な要素を取り出す工程を丁寧に設計しました。この部分は軽量なモデルでも実現できることを検証したうえで進めています。 導入効果：十日分の作業が半日に、思考に使える時間が二倍以上に 導入の効果は、提案書作成のリードタイムに明確に表れました。従来、提案書の骨子を作成するのに約十日を要していた作業が、半日程度で完了するようになりました。 時間が生まれたことで、コンサルタントが本来注力すべき思考の工程に充てられる日数が増えました。従来は付加価値を高める検討に平均二日程度しか取れていなかったところ、平均五日以上と二倍以上の時間を確保できるようになりました。「本質的でない部分はデータや AI に任せ、代替のきかない部分に集中する」という同社の狙いが、実際の業務で形になりました。 品質面でも効果が表れています。評価基準で求められる必須項目や加点項目を、限られた時間の中でも確実に押さえられるようになり、提案書の品質を組織として安定的に担保できる状態に近づきました。これまで個人の経験に依存しやすかった準備工程も、システムによる抽出と編集機能によって組織の標準プロセスとして底上げされています。 今後の展開 ITbook 株式会社様は2026年6月時点で本システムを社内でトライアル的に利用しながら改善を進める段階にあります。今後は、性能改善に加え、管理機能の整備を進める計画です。 適用範囲の拡大も視野に入れています。本システムは公共機関向けに作られていますが、提案書作成は民間企業でも共通するため、段階的に適用範囲を広げていく構想があります。さらに将来的には、提案する側だけでなく、自治体職員が調達仕様書を作成する作業の支援にまで広げることを最終的な目標として描いています。 お客様の声 ITbook株式会社 代表取締役社長 宇田川 燿平 氏からは、以下のようなコメントをいただいています。 「国や自治体の調達仕様書から提案書を生成する受注者支援に加え、将来的には調達仕様書そのものの作成支援にも活用予定です。コンサルタントは付加価値の高い業務に集中でき、生成 AI を起点としたコンサルティングの新しいビジネスモデルへの転換を推進します。」 まとめ ITbook 株式会社様の取り組みは、生成 AI を人の仕事をそのまま代替する道具としてではなく、人が考える時間を生み出すための基盤として業務に組み込んだ事例です。Amazon Bedrock を中心に、処理を役割ごとに分割し、Human-in-the-loop で人の判断を残す設計によって、提案書作成のリードタイムを短縮しつつ、品質を組織として底上げすることを両立しました。AIMS を取得し AI ガバナンスを重視する同社にとって、データを学習に使わない形で基盤モデルを利用できる点も、安心して全社的な活用へ踏み出す後押しになっています。コンサルティング会社が AI ネイティブな働き方を模索するうえで、一つの参考になれば幸いです。 Amazon Bedrock の詳細については Amazon Bedrock のサービスページ を、エージェント開発については Amazon Bedrock AgentCoreのサービスページ をご覧ください。 なお、本ブログで記載する開発は、ITbook 株式会社様とAWS 上での AI エージェント開発に知見を持つ アクロクエストテクノロジー株式会社 様（以下、アクロクエスト）が協業して推進しました。ITbook 株式会社様が業務要件と品質基準を定義し、アクロクエスト様が実装を担う役割分担で、2026年1月に開発を開始しました。 アカウントマネージャー 尾形龍太郎

本記事は、2026 年 6 月 22 日に公開された Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs を翻訳したものです。翻訳は Solutions Architect の齋藤 拓巳が担当しました。 本日、AWS Lambda MicroVMs を発表します。これは AWS Lambda 内の新しいサーバーレスコンピューティングプリミティブで、ユーザーや AI が生成したコードを分離されたステートフルな実行環境で実行できます。 仮想マシンレベルの分離、ほぼ瞬時の起動と再開、環境のライフサイクルと状態の直接制御が可能で、インフラストラクチャの管理や複雑な仮想化技術の専門知識は不要です。 Lambda MicroVMs は Firecracker を基盤としています。これは、月間 15 兆回を超える Lambda 関数の呼び出しを支えてきた軽量仮想化技術と同じものです。 この機能が求められる背景 ここ数年、新しい種類のマルチテナントアプリケーションが登場しています。これらのアプリケーションはすべて、エンドユーザーごとに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する必要があるという共通点を持っています。AI コーディングアシスタント、インタラクティブなコード環境、データ分析プラットフォーム、脆弱性スキャナー、ユーザー提供のスクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在この機能を構築するには、難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動しますが、カーネル共有アーキテクチャのため、信頼できないコードを安全に封じ込めるには大規模なカスタムのセキュリティ強化が必要です。Functions as a Service はイベント駆動型のリクエスト・レスポンスワークロードに最適化されていますが、ユーザーとのインタラクション間で環境の状態を保持する必要がある長時間実行のインタラクティブセッション向けには設計されていません。その結果、開発者はパフォーマンスと分離のトレードオフを受け入れるか、エンドユーザーに低レイテンシーの体験を提供しながら分離された実行を実現するために、カスタム仮想化インフラストラクチャの構築と運用に多大なエンジニアリングリソースを投資するかの選択を迫られます。これは深い専門知識を必要とし、本来構築しようとしているプロダクトからエンジニアリング時間を奪う取り組みです。 Lambda MicroVMs は、まさにこのギャップを埋めるために専用設計されています。 各 MicroVM は、単一のエンドユーザーまたはセッションに対して独自の分離された環境を提供し、高速に起動し、セッションの間メモリとディスクの状態を保持し、ユーザーが離席した際には低コストのアイドル状態に一時停止します。 同じ Firecracker テクノロジーが既に AWS Lambda Functions の基盤となっているため、このスタックを大規模に運用してきたサービスの運用成熟度をそのまま活用できます。 試してみましょう まず、AWS Lambda コンソールに移動すると、左側のナビゲーションメニューに Lambda MicroVMs が表示されるようになっています。最初に MicroVM イメージを作成する必要があります。 Flask ウェブアプリとその Dockerfile を zip ファイルにパッケージ化し、 Amazon Simple Storage Service (Amazon S3) バケットにアップロードしました。 Flask API – app.py import logging from flask import Flask, jsonify app = Flask(__name__) logging.basicConfig(level=logging.INFO) @app.route("/") def hello(): app.logger.info("Received request to hello world endpoint") return jsonify(message="Hello, World!") if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) Dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 python3-pip && dnf clean all WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"] 以下のコマンドを使用して MicroVM イメージを作成しました。 aws lambda-microvms create-microvm-image \ --code-artifact uri= --name \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn 上の画像のように、AWS コンソールで MicroVM Image を作成することもできます。 コマンドを実行すると、Lambda が zip を取得し、Dockerfile を実行し、アプリケーションを初期化して、実行中のディスクとメモリの状態の Firecracker スナップショットを取得しました。 ビルドログは /aws/lambda/microvms/ 配下の Amazon CloudWatch にリアルタイムでストリーミングされ、イメージの準備が完了すると、 Amazon Resource Name (ARN) とバージョン番号とともにコンソールに表示されました。 aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:::microvm-image:my-image \ --execution-role-arn arn:aws:iam:::role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' 起動は AWS コンソールまたは CLI からも行えます。 ここでは、イメージ ARN と、15 分間操作がないと自動的にサスペンドし、次のリクエストを受信すると自動的にレジュームするよう設定したアイドルポリシーを渡しました。 ネットワークの設定は不要です。 Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、新しい MicroVM を起動します。この MicroVM はスナップショットからレジュームされるため、Flask アプリはすでに実行された状態になっています。 実際、起動が完了した瞬間には Flask アプリはすでに動作していました。 たった 1 回の API 呼び出しで、完全に初期化されブートストラップされたコンピューティング環境が手に入ります。 トラフィックを送信するために、CLI で短期間有効な認証トークンを生成し、 X-aws-proxy-auth ヘッダーを使用して通常の HTTPS リクエストに添付しました。 リクエストはすぐに Flask アプリに到達しました。 その後、MicroVM をサスペンドのしきい値を超えてアイドル状態にしたところ、MicroVM はサスペンドされ、メモリとディスクの状態がスナップショットとして保存されました。 次に別のリクエストを送信すると、アプリケーションの状態が完全に保持されたまま再開されました。 クライアント側からは、一時停止が発生したことはまったくわかりませんでした。 仕組み 内部的には、Lambda MicroVMs は、これまで単一の AWS コンピューティングサービスでは同時に提供されていなかった 3 つの機能を実現しています。 1 つ目は、Firecracker による仮想マシンレベルの分離です。 各セッションは専用の MicroVM で実行され、ユーザー間でカーネルやリソースが共有されることはありません。 そのため、あるユーザーが提供した信頼されていないコードはそのユーザーの実行環境内に封じ込められ、他の環境や基盤システムへのアクセスはできません。 2 つ目は、高速な起動と再開です。 このモデルは「イメージを作成してから起動する」方式です。Dockerfile と Amazon S3 に zip アーティファクトとしてパッケージ化されたコードを提供して MicroVM Image を作成すると、Lambda が Dockerfile を実行し、アプリケーションを初期化し、実行中の環境のメモリとディスクの状態の Firecracker スナップショットを取得します。 そのイメージから起動される後続のすべての MicroVM は、コールドブートではなく事前に初期化されたスナップショットから再開されるため、起動とアイドル状態からの再開の両方でほぼ瞬時の起動レイテンシーを実現します。 数ギガバイト規模のインタラクティブセッションでも、エンドユーザーが快適に操作できるほど素早くオンラインに復帰します。 3 つ目は、ステートフルな実行です。 実行中の MicroVM は、ユーザーのセッション全体を通じてメモリ、ディスク、実行中のプロセスを保持します。 アイドル期間中、MicroVM はメモリとディスクの状態をそのまま維持したままサスペンドでき、トラフィックが到着すると再開されます。 インストール済みのパッケージ、ロード済みのモデル、作業中のファイルセットは、ユーザーがセッションを再開した際にすぐに利用可能です。 MicroVM は最大 8 時間の合計実行時間をサポートし、設定可能なアイドル時間の後に自動的にサスペンドできるため、数分で完了するソフトウェア脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間のアイドル期間を伴うインタラクティブなコーディングセッションなど、多様なプロダクトを簡単に構築できます。 Lambda MicroVMs は事前に初期化されたスナップショットから起動されるため、初期化時に一意のコンテンツを生成したり、ネットワーク接続を確立したり、一時的なデータをロードしたりするアプリケーションでは、互換性のためにサービスが提供するフックとの統合が必要になる場合があります。 Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、独自の API を備えています。 Lambda Functions は引き続きイベント駆動型のリクエスト・レスポンスワークロードに最適な選択肢であり、Lambda MicroVMs はマルチテナントアプリケーション向けに特化して構築されています。具体的には、各エンドユーザーやセッションに対して、ユーザーまたは AI が生成したコードを実行するための独立した分離環境を提供する必要があるアプリケーションに適しています。 この 2 つは互いを補完する関係にあります。 イベント駆動型のバックボーンに Lambda Functions を使用しているアプリケーションは、信頼できないコードを分離して実行する必要があるステップで Lambda MicroVMs を呼び出すことができます。 お客様がアプリケーションを持ち込み、サービスが実行環境を提供します。 提供開始 AWS Lambda MicroVMs は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) の各 リージョン で本日より利用可能です。ARM64 アーキテクチャ上で、MicroVM あたり最大 16 vCPU、32 GB のメモリ、32 GB のディスクを提供します。 アイドル状態の MicroVM は、API 呼び出しによる明示的なサスペンド、またはライフサイクルポリシーによる自動サスペンドが可能で、完全な状態を保持したまま高速に再開できるため、実行コストを削減できます。 料金の詳細は AWS Lambda の料金ページ をご覧ください。 開始するには、 AWS Lambda コンソール にアクセスするか、 Lambda MicroVMs 製品ページ で詳細をご確認ください。 ドキュメントについては、 Lambda MicroVMs デベロッパーガイド を参照してください。 著者について Micah Walter Micah Walter は、ニューヨーク市地域およびその他の地域のエンタープライズのお客様を支援するシニアソリューションアーキテクトです。クラウドへの移行のあらゆる段階で、エグゼクティブ、エンジニア、アーキテクトに対してアドバイスを行っており、サステナビリティと実践的な設計に深く注力しています。余暇には、アウトドアや写真撮影、家中を走り回る子どもたちを追いかけて楽しんでいます。 翻訳者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。

本記事は 2026 年 5 月 13 日 に公開された「 Getting Started with Wait and Save service-managed fleets on AWS Deadline Cloud 」を翻訳したものです。 ビジュアルエフェクトやアニメーションのスタジオは、 AWS Deadline Cloud を活用することで、クリエイティブな反復作業を加速し、より多くのレンダリングオプションを検討できます。AWS Deadline Cloud は、2D・3D グラフィックスおよび VFX を制作するチーム向けに、レンダー管理を簡単にするフルマネージドサービスです。Deadline Cloud はサービスマネージドフリート（SMF）を提供しており、AWS がコンピューティングリソースのプロビジョニングや管理を自動的に行うことで、ユーザーのインフラ管理の負担を軽減します。Deadline Cloud の SMF で利用できるようになった Wait and Save は、通常のレンダリングジョブが始まるまでの時間に幅を持たせる代わりに、CPU レンダリングのコンピューティング料金を割引する機能です。本記事では、Deadline Cloud のサービスマネージドフリート（SMF）で Wait and Save を設定し、CPU レンダリングコストを削減する方法を紹介します。以下のトピックを取り上げます。 SMF のキャパシティ確保の仕組みを理解する コスト削減を最大化するための専用 Wait and Save キューとフリートを設定する Wait and Save、Spot、On-Demand フリートのコストを比較する Deadline Cloud Monitor でジョブのステータス、待機時間、コストを追跡する Wait and Save フリートと Spot フリートを組み合わせたハイブリッドフリート構成でキャパシティとコストを最適化するための自動化を行う サービスマネージドフリート（SMF）のキャパシティ確保の仕組みを理解する Deadline Cloud の SMF は、主に 2 つの方法で Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを取得できます。On-Demand インスタンスと Spot インスタンスです。On-Demand インスタンスは安定したコンピューティングキャパシティを提供するため、継続的かつ中断のない処理が必要なワークロードに適しています。Spot インスタンスでは、Amazon EC2 の未使用キャパシティを On-Demand 料金と比べて大幅な割引 (最大 90% の節約になることも) で利用できます。このキャパシティは、AWS のデータセンター全体で未使用のコンピューティングリソースが生じた際に提供されます。ただし、Spot インスタンス上のワークロードは、On-Demand リクエストへの対応のために中断される場合があります。 Wait and Save は、レンダリングジョブの開始タイミングに柔軟性を持たせる代わりに、割引されたコンピューティング料金で余剰の CPU Spot キャパシティを活用します。Deadline Cloud が Spot キャパシティの可用性が高い時間帯を利用できるようにすることで、レンダリングワークロードの品質とスループットを維持しながら、大幅なコスト削減を実現できます。最新の料金情報については、 AWS Deadline Cloud の料金ページ をご覧ください。 Wait and Save によるスマートスケジューリング キャパシティと料金を最適化するための主な要素は以下のとおりです。 時間帯 – 顧客の利用パターンは一般的に 1 日の業務時間サイクルに連動しており、夕方や早朝はキャパシティの可用性が高くなる傾向があります。オフピーク時間帯にジョブを投入することで、より早くキャパシティを確保できます。 リージョン戦略 – 現在が業務時間外となる AWS リージョンへのジョブ投入を検討してください。たとえば、米国の日中に作業している場合、異なるタイムゾーンのリージョンでは、その時間帯により多くのキャパシティが利用できる可能性があります。異なるリージョンを使用する際は、組織のデータガバナンスおよびデータレジデンシーの要件への準拠を確認してください。 オフピーク時間帯にジョブを投入したり、別のリージョンを選択したりすることで、Wait and Save の利用可能なキャパシティへのアクセスを増やし、割引料金のメリットを享受できます。 Wait and Save を手軽に活用する方法として、Wait and Save フリートのみに紐付けた専用キューを使う方法があります。以降のセクションでは、Wait and Save フリートの基本的なセットアップ手順を説明し、コスト削減効果を示したうえで、既存の EC2 Spot または On-Demand フリートと Wait and Save フリートを統合する方法を紹介します。 前提条件 開始する前に、Wait and Save がワークロードの要件に合っているか確認し、必要な AWS リソースが設定済みであることを確認してください。 Wait and Save は以下のワークロードに対応しています。 CPU ベースのレンダリングワークロードのみ (GPU は非対応) スケジューリングに柔軟性があるプロジェクト 開始時間が変動しても対応できるワークロード 考慮すべき主な制限事項は以下のとおりです。 インスタンスタイプの選択 – Wait and Save は、指定した要件に合う CPU インスタンスタイプの中から自動的に選択します。特定のインスタンスタイプを指定することはできません。 待機時間 – ジョブは通常 24 時間以内に開始されます。実際の待機時間はリージョン、時間帯、利用可能なキャパシティによって異なります。 中断 – On-Demand リクエストへの対応のため、ワーカーが中断される場合があります。中断されたタスクは最初から再実行されます。 以下の AWS リソースが事前に用意されていることを確認してください。 Deadline Cloud を使用するための AWS アカウント 任意のリージョンに設定された Deadline Cloud モニター 　と以下を含みます。 ユーザー用のリージョナル AWS IAM Identity Center モニター URL Wait and Save フリートを設定するファーム (Deadline Cloud を初めて使用する場合は、 クイックスタートガイド を使ってリソースをプロビジョニングしてください) 対応するデジタルコンテンツ制作 (DCC) アプリケーションと、対応する Deadline Cloud サブミッター のインストール 専用キューの作成 以下の手順で専用キューを作成します。 Deadline Cloud コンソールのナビゲーションペインで Farms を選択します。 ファームの一覧から対象のファームを選択します。 Queues タブで Create queue を選択します。 キューの設定を行います (追加オプションについては Deadline Cloud キュー を参照してください)。 Queue name にわかりやすい名前を入力します (例: Wait and Save Queue )。 Job attachments で、ジョブの添付ファイル用の Amazon Simple Storage Service (Amazon S3) バケットを設定します。 Create queue を選択します。 図 1: Wait and Save フリート専用のキューを作成する Wait and Save フリートの作成 以下の手順で Wait and Save フリートを作成します。 Deadline Cloud コンソールのナビゲーションペインで Farms を選択します。 ファームの一覧から対象のファームを選択します。 Fleets タブで Create fleet を選択します。 フリートの詳細を設定します。 Fleet name にわかりやすい名前を入力します (例: Wait and Save Fleet )。 Fleet type で Service-managed を選択します。 Instance market type で Wait and Save を選択します。 Next を選択します。 図 2: サービスマネージドフリートタイプと Wait and Save インスタンスマーケットタイプを選択する フリートのハードウェアおよびソフトウェア要件を定義します。特定の EC2 インスタンスタイプを選択する必要はありません。Wait and Save は、指定した条件に合うインスタンスタイプの中から自動的に選択します。 Amount vCPU に vCPU 数の最小値と最大値を入力します (例: 4〜16)。 Amount memory (GiB) にメモリの最小値と最大値を入力します (例: 32〜64)。 Next を選択します。 ワークロードの要件に応じて Maximum worker count を設定します。デフォルトのクォータはリージョンあたり Wait and Save vCPU 50 個です。クォータはリソースの適切な使用とコスト管理を促進するために設定されています。大規模な本番ワークロードに対応するには、Deadline Cloud の Wait and Save vCPU のリージョンあたりのクォータ引き上げをリクエストしてください。クォータ引き上げのリクエスト手順については、 Service Quotas ユーザーガイド を参照してください。 Next を選択します。 Associate queues で、先ほど作成したキューに Wait and Save フリートを関連付けます。 Next を選択します。 図 3: Wait and Save キューをフリートに関連付ける 追加の設定とタグを行い (任意)、 Next を選択します。 内容を確認し、 Create fleet を選択します。 Wait and Save キューへのジョブ投入 Wait and Save の動作を確認するために、200 フレームのターンテーブルレンダーを投入します。この例では Autodesk Maya と Deadline Cloud サブミッターを使用しますが、他の対応 DCC でも同様の手順で投入できます。 Maya ファイルを保存します。 Maya のシェルフで Deadline Cloud を選択してサブミッターを開きます。 Shared job settings セクションで以下を設定します。 Farm Selection で、Wait and Save キューが含まれるファームを選択します。 Queue Selection で、作成した Wait and Save キューを選択します。 Submit を選択し、画面の指示に従ってジョブを Deadline Cloud に送信します。 図 4: 専用の Wait and Save キューを設定した Maya Deadline Cloud サブミッター Deadline Cloud Monitor でジョブのステータスとコストを確認する Deadline Cloud Monitor でジョブを追跡し、以下の情報を確認します。 ジョブのステータス – Wait and Save のキャパシティが確保されると、ジョブのステータスが Ready から Running に移行します。デスクを離れている間もジョブの開始や完了を把握できるよう、 Amazon EventBridge の通知を設定できます。詳細については、 Job Run Status Change イベント を参照してください。 待機時間 – ジョブの投入から実行開始までの時間を確認します。Wait and Save の待機時間は、時間帯、リージョン、ワークロードのサイズ、フリートの設定によって異なります。通常、待機時間は 24 時間未満です。以下のジョブモニターのスクリーンショットに示すように、ジョブの Create time から Start time までの詳細を確認すると、このジョブは実行開始まで約 7 時間かかっています。 図 5: ジョブモニターでジョブの作成日時、開始日時、終了日時を確認できる 中断時の処理 – 中断が発生した場合、未完了のタスクは最初から再実行されます。中断されたワーカーは、リソースが利用可能であれば他のインスタンスタイプから補充されます。短いタスクであれば影響は最小限ですが、実行時間の長いタスクは進捗が失われる場合があります。 使用状況とコストの追跡 – Deadline Cloud の使用状況エクスプローラーを使って、Spot や On-Demand の料金と比較したコストを確認し、実行時間のパターンを追跡できます。専用の Wait and Save キューを使用すると、キューフィルターでジョブの実行中、待機中、中断中の時間帯別の使用パターンを確認できます。 図 6: この使用状況エクスプローラーのビューは、各マーケットタイプ向けに作成した専用キューに同一のジョブを投入した結果を示しています。時間単位の表示設定により、各ジョブがいつ実行されたかを確認できます。 Wait and Save 専用セットアップによるコスト削減 例として送信した 200 フレームの Maya ターンテーブルレンダリングのコストへの影響を見てみましょう。実際の削減効果を示すために、マーケットタイプごとに専用キューを作成し、同一のワーカー性能で同じ Maya ジョブを Wait and Save、Spot、On-Demand の各フリートで実行しました。 3 つのマーケットタイプすべてで 200 フレームの Maya ターンテーブルレンダリングを実行した結果、次の表に示すとおり、コンピューティングコストに大きな差が生じました。このジョブ 1 件において、Wait and Save は Deadline Cloud の On-Demand と比較して 92%、Deadline Cloud の Spot と比較して 78% のコスト削減を実現しました。 サービスマネージドフリートのマーケットタイプ コンピューティングコスト ライセンスコスト 200 フレーム Maya ジョブの総レンダリングコスト On-Demand $2.09 $2.86 $4.95 Spot $0.76 $2.04 $2.80 Wait and Save $0.17 $2.18 $2.35 図 7: 各マーケットタイプにおける 200 フレーム Maya ターンテーブルレンダリングのコンピューティングコストとライセンスコストの合計: On-Demand (左)、Spot (中央)、Wait and Save (右)。 図 8: Deadline Cloud Monitor の使用状況エクスプローラーに表示された各マーケットタイプの総コスト内訳。 キャパシティとコストを最適化する自動ハイブリッドフリートのセットアップ ジョブのキャパシティ可用性を高めつつ、可能な限りコストを抑えたい場合は、既存の Spot フリートや On-Demand フリートと同じキューに Wait and Save を関連付けることができます。これにより、コスト最適化とキャパシティ可用性のバランスが自動的に取られ、ジョブを遅延なく実行できます。 次のオープンソースの AWS CloudFormation テンプレート は、 AWS Lambda と Amazon EventBridge Scheduler を使用して、Wait and Save ワーカーの可用性に応じて Spot フリートのキャパシティをリアルタイムで自動調整します。Lambda 関数は一定間隔で希望するフリートサイズを監視し、主に Wait and Save フリートから必要なワーカー数を確保しつつ、不足分はセカンダリの Spot フリートのインスタンスで補います。Deadline Cloud のワーカー終了ポリシーはワーカーレベルで適用されるため、インスタンスはタスクの完了後にのみ終了します。これにより、レンダリングを中断することなく、フリートを最もコスト効率の高い構成に保てます。 自動キャパシティ管理をデプロイするには、次の手順を実行します。 Wait and Save フリートを、既存のキューに On-Demand または Spot フリートと並べて関連付けます。 Wait and Save フリートの maxWorkerCount を希望するフリート全体のサイズに設定します (例: 両フリート合計で 20 ワーカー)。 CloudFormation テンプレートをダウンロードし、以下のパラメータを指定して README のデプロイ手順に従います。 TargetMaxWorkerCount : 両フリート合計のワーカー数 (Wait and Save の maxWorkerCount と一致させる必要があります) FarmId : Deadline Cloud のファーム ID WaitAndSaveFleetId : Wait and Save フリートの ID SpotFleetId : Spot フリートの ID CapacityCheckRateMinutes : キャパシティチェックの間隔 (デフォルト: 2 分) Lambda 関数は、Wait and Save ワーカーのオンライン・オフラインに応じて Spot フリートを自動的にスケールアップまたはスケールダウンし、希望する合計キャパシティを維持します。 多くの AWS サービスと同様に、Lambda は従量課金制で、100 万リクエストあたり $0.20 から利用でき、AWS 環境内でコードベースの自動化を素早く構築するためのコスト効率の高い手段です。レンダリングを行っていない間は、EventBridge スケジュールを無効にすることで、キャパシティ管理の自動化と Lambda の呼び出しコストを停止できます。フリート設定でワーカーの最小数が 0 に設定されているため、ジョブがなければワーカーは起動せず、レンダリングコストは発生しません。 クリーンアップ 本記事で作成したリソースが不要になった場合は、以下の手順に従ってください。 AWS アカウントで CloudFormation コンソールを開きます。 本記事の手順に沿って作成したスタックを検索します。 スタックの削除 を選択し、ステータスが DELETE_COMPLETE に変わるまで待ちます。これにより、Lambda 関数、EventBridge スケジュール、および IAM ロールがアカウントから削除されます。 Deadline Cloud のリソース (ファーム、フリート、キューなど) を削除するには、 Clean up your farm resources in Deadline Cloud を参照してください。 まとめ Wait and Save は、柔軟な CPU レンダリングワークロードに対して大幅なコスト削減をもたらします。Maya を使った例では、Spot 料金と比較して専用の Wait and Save 構成で 78% のコスト削減を実現しました。最大限の節約を目的とした専用キューの利用でも、柔軟な実行を目的としたハイブリッドフリート構成でも、Wait and Save はレンダリングコストを大幅に削減できます。大規模なプロジェクトではこの節約効果がさらに積み重なり、スタジオが予算内でより多くのコンテンツをレンダリングするのに役立ちます。 AWS 担当者 にお問い合わせいただき、ビジネスの加速に向けたサポートについてご相談ください。 参考資料 Wait and Save フリートのセットアップとコスト削減効果を確認したら、引き続き Deadline Cloud の機能を学び、レンダリングワークフローをさらに最適化しましょう。 他のフリートタイプと設定についても学び、レンダリングパイプラインを最適化しましょう。高度な設定オプションについては、 Service-managed fleets を参照してください。 Wait and Save と他のインスタンス市場タイプの詳細な料金情報およびリージョン別料金は、 AWS Deadline Cloud 料金ページ で確認できます。 Wait and Save ジョブの開始・完了時にアラートを受け取るには、 ジョブ実行ステータスイベントの EventBridge 連携 を使ったジョブステータス変更の自動通知設定について学びましょう。 コストの追跡と使用パターンの分析については、 Deadline Cloud の使用状況エクスプローラーによるコストと使用状況の追跡 を参照してください。 Deadline Cloud が提供する CloudFormation テンプレートの オープンソースサンプル もご覧ください。 著者について Isha Satpalkar Isha Satpalkar は AWS でデジタルコンテンツ制作のための製品開発に携わるソフトウェアエンジニアです。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。