本ブログは 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 森が担当しました。原文は こちら をご覧ください。

本ブログは 2026 年 6 月 24 日に公開された AWS Blog “ Restrict AWS Management Console access to expected networks with sign-in resource-based policies and RCPs ” を翻訳したものです。 Amazon Web Services (AWS) は 2026 年 6 月 16 日に、 リソースベースポリシー と リソースコントロールポリシー (RCP) を AWS サインイン でサポートすることを発表しました。リソースベースポリシーと RCP を使用すると、 AWS マネジメントコンソール へのサインインと aws login CLI セッションへのアクセスを、想定するネットワーク、オンプレミスのデータセンターネットワーク、およびお客様の Amazon Virtual Private Cloud (Amazon VPC) からのリクエストに制限できます。 サインインのリソースベースポリシーと RCP は、いくつかのセキュリティ目標に対応します。具体的には、コンソールサインインを企業ネットワークに制限すること、コンソールにサインインできるプリンシパルを限定すること、そして AWS Organizations の組織全体にわたって一貫した ネットワーク境界制御 を適用することです。 この記事では、一般的なユースケースを取り上げます。規制コンプライアンスのために、ある金融サービス企業がコンソールアクセスを企業ネットワークに制限するというケースです。単一アカウントに対してサインインのリソースベースポリシーを使用してこれを実装する方法、 AWS CloudTrail で制御を検証する方法、そしてこれらのポリシーが AWS Management Console Private Access やより広範な AWS データ境界フレームワーク とどのように統合されるかを説明します。 コンソールサインインアクセスを企業ネットワークに制限する ある金融サービス企業が、 AWS マネジメントコンソール へのサインインを企業ネットワークから行うことを求めているとします。この企業には次の要件があります。 ユーザーは、企業 VPN、オフィスネットワーク、またはお客様の VPC からのみコンソールにサインインする 個人ネットワーク、公衆 Wi-Fi、その他の想定外の場所からのサインイン試行は拒否しなければならない ロックアウトを防ぐため、指定したプリンシパルはどのネットワークからでもアクセスを保持できるようにする コンプライアンスの証跡として、すべてのサインイン試行 (許可および拒否) を CloudTrail に記録しなければならない 以下のステップでは、単一アカウントでこれらの要件を適用するリソースベースポリシーを作成する方法を紹介します。 前提条件 AWS Command Line Interface (AWS CLI) が最新バージョンでインストールされ、設定されていること サインインのリソースポリシーを管理する権限。AWS マネージドポリシーの AWSSignInResourcePolicyManagement をアタッチするか、各プリンシパルに次のアクションへの権限を付与します。 リソース許可ステートメントの管理: signin:PutResourcePermissionStatement , signin:DeleteResourcePermissionStatement , signin:ListResourcePermissionStatements , signin:GetResourcePolicy. コンソール認可の管理: signin:PutConsoleAuthorizationConfiguration , signin:GetConsoleAuthorizationConfiguration , signin:DeleteConsoleAuthorizationConfiguration 特定の企業ネットワーク: IP CIDR 範囲または VPC ID 除外する指定プリンシパルの Amazon リソースネーム (ARN)。これにより、ネットワーク条件が変わってもアクセスを保持できます 注: AWS サインインアクションの完全なリストについては、サービス認可リファレンスの AWS Signin のアクション、リソース、および条件キー を参照してください。 ステップ 1: リソース許可ステートメントを作成する ほとんどのリソースベースポリシーでは、作成者がポリシードキュメント全体 (JSON ステートメント) を入力する必要があります。サインインのリソース許可ステートメントは異なります。パラメータを指定すると、AWS サインインがポリシーを生成します。 次のコマンドでは、企業 IP 範囲、VPC、除外プリンシパルをパラメータとして指定します。AWS サインインはこれらのパラメータを使用して、コンソールサインインをそれらのネットワークに制限しつつ、除外プリンシパルがどのネットワークからでもサインインできるようにするポリシーを生成します。お客様が制御するのはパラメータの値であり、ポリシーの構造ではありません。生成されたポリシーは、 get-resource-policy コマンドでいつでも確認できます。 注: リソース許可ステートメントは、ステップ 2 でコンソール認可を有効にするまで効果を発揮しません。そのため、効果が発生する前に完全なポリシーを確認できます。なお、書き込み操作は us-east-1 を対象にする必要があります。 リソース許可ステートメントを作成するには、次の手順を実行します。 1. ターミナルを開き、最新の AWS CLI がインストールされていることを確認します。 2. 次のコマンドを実行し、プレースホルダー値 <my-vpc> 、 <my-vpc-region> 、 <my-corporate-cidr> 、 <excluded-IAM-principal-arn> を、お客様の具体的な設定に置き換えます。 aws signin put-resource-permission-statement \ --source-vpc <my-vpc> \ --requested-region <my-vpc-region> \ --source-ip <my-corporate-cidr> \ --excluded-principal <excluded-IAM-principal-arn> \ --region us-east-1 3. 出力に statementId があることを確認して、コマンドが成功したか検証します。 出力例: { "statementId":"b2HfHli9qCF1P4eGNll13CrZtusXlcPxxVBqz2aYLjlAcWtWQHP6Hg0" } 4. get-resource-policy コマンドを実行して、完全なリソースベースポリシーを確認します。 aws signin get-resource-policy 出力例: { "signinResourceBasedPolicy": { "Version": "2012-10-17", "Statement": [ { "Effect": "DENY", "Principal": {"AWS": "*"}, "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": {"signin:PrincipalArn": ["<excluded-IAM-principal-arn>"]}, "NotIpAddress": {"aws:SourceIp": ["<my-corporate-cidr>"]}, "StringEquals": {"aws:ResourceAccount": ["<account-id>"]}, "StringNotEquals": {"aws:SourceVpc": ["<my-vpc>"]} } }, { "Effect": "DENY", "Principal": {"AWS": "*"}, "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": {"aws:PrincipalArn": ["<excluded-IAM-principal-arn>"]}, "NotIpAddress": {"aws:SourceIp": ["<my-corporate-cidr>"]}, "StringEquals": {"aws:ResourceAccount": ["<account-id>"]}, "StringNotEquals": {"aws:SourceVpc": ["<my-vpc>"]} } }, { "Effect": "DENY", "Principal": {"AWS": "*"}, "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": {"signin:PrincipalArn": ["<excluded-IAM-principal-arn>"]}, "StringEquals": {"aws:SourceVpc": ["<my-vpc>"]}, "StringNotEquals": {"aws:RequestedRegion": ["<my-vpc-region>"]} } }, { "Effect": "DENY", "Principal": {"AWS": "*"}, "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": {"aws:PrincipalArn": ["<excluded-IAM-principal-arn>"]}, "StringEquals": {"aws:SourceVpc": ["<my-vpc>"]}, "StringNotEquals": {"aws:RequestedRegion": ["<my-vpc-region>"]} } } ] } } 生成されたポリシーには 4 つのステートメントが含まれ、2 つのペアにグループ化されています。最初のペアはネットワークソースによってアクセスを制限し、企業 IP 範囲 (<my-corporate-cidr>) または VPC (<my-vpc>) の外部からリクエストを行うプリンシパルを拒否します。2 番目のペアは、VPC がターゲットにできる AWS リージョンを制限し、 <my-vpc> から発信されたリクエストを、 <my-vpc-region> に向けられたものでない限り拒否します。このリージョンへのバインディングが必要なのは、VPC ID が単一リージョン内でのみ一意であるためです。 AWS サインインはこれらのポリシーを 2 つのフェーズ、つまり認証前と認証後で評価します。認証後の評価は、コンソールセッションが新しい認証情報をリクエストするたびに繰り返されます。各ペアの中で、1 つのステートメントは認証前フェーズをカバーし、もう 1 つは認証後フェーズをカバーします。 認証前のステートメントは signin:Authenticate アクションを評価します。このフェーズではプリンシパルがまだ認証されていないため、ステートメントは signin:PrincipalArn 条件キーを使用して除外プリンシパルを免除します。このキーはすべてのプリンシパルタイプ (ルートユーザー、 AWS Identity and Access Management (IAM) ユーザー、フェデレーションユーザー、ロール) をサポートします。 認証後のステートメントは signin:AuthorizeOAuth2Access および signin:CreateOAuth2Token アクションを評価します。AWS サインインは、コンソールセッションを確立するトークンを発行する認証後に、これらのアクションを評価します。これらのアクションは signin:PrincipalArn キーをサポートしません。代わりに、認証済みのプリンシパルに解決される aws:PrincipalArn を使用します。 aws:ResourceAccount の値は受信側のアカウント ID です。AWS サインインが呼び出し元の認証情報から自動的に取得するため、お客様が自分で設定する必要はありません。サポートされるアクションと条件キーの完全なリスト (各フェーズと各プリンシパルタイプにどのキーが適用されるかを含む) については、 Controlling console access with resource-based policies and resource control policies および AWS Sign-In condition keys reference を参照してください。 ステップ 2: アカウントのサインインポリシー適用を有効にする このステップでは、ステップ 1 で作成したポリシーの適用を有効にします。このステップを実行するまで、ステップ 1 で作成したリソース許可ステートメントは効果を発揮しません。 5. 次のコマンドを使用して、サインインポリシーの適用を有効にします。 aws signin put-console-authorization-configuration \ --target-id <account-id> \ --region us-east-1 6. 出力に "consoleAuthorizationEnabled": true があることを確認して、コマンドが成功したか検証します。 出力例: { "Output": { "consoleAuthorizationEnabled": true, "scope": "ACCOUNT", "targetId": "<account-id>" } } 7. 以下のように get-console-authorization-configuration コマンドを実行して、設定を検証することもできます。 aws signin get-console-authorization-configuration \ --target-id <account-id> \ --region us-east-1 8. 適用を無効にしたり個別のステートメントを削除したりするには、 delete-console-authorization-configuration または delete-resource-permission-statement を使用します。詳細については、 AWS サインイン ユーザーガイド の Controlling console access with resource-based policies and resource control policies を参照してください。 実装の検証 適用が有効になったので、サインイン試行はリソースベースポリシーに照らして評価されます。さまざまなネットワーク条件からサインインをテストして、動作を検証しましょう。 シナリオ 1: 企業ネットワークからの許可されたサインイン 許可された企業 IP 範囲または VPC からサインインするプリンシパルは、正常にサインインできます。 CloudTrail イベント には ConsoleLogin:Success が表示されます。 コンソールサインイン成功時の CloudTrail イベント詳細の例: { "userIdentity": { "type": "AssumedRole", "principalId": "AROAEXAMPLEID:Dev1", "arn": "arn:aws:sts::123456789123:assumed-role/Developer/Dev1", "accountId": "123456789123" }, "eventTime": "2026-06-09T19:20:38Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-1", "sourceIPAddress": "192.0.2.100", "responseElements": { "ConsoleLogin": "Success" }, "eventID": "dd004e78-6447-4f56-8d2d-a795da66f598", "readOnly": false, "eventType": "AwsConsoleSignIn", "managementEvent": true, "recipientAccountId": "123456789123", "eventCategory": "Management" } シナリオ 2: 想定外のネットワークからの拒否されたサインイン 許可された IP アドレス範囲、またはソース VPC にアタッチされた VPC エンドポイント以外のネットワークからサインインするプリンシパルはブロックされます。CloudTrail イベントには ConsoleLogin: Failure が表示され、拒否の原因となったポリシーを特定するエラーメッセージが含まれます。 コンソールサインイン失敗時の CloudTrail イベント詳細の例: { "userIdentity": { "type": "IAMUser", "accountId": "123456789123", "accessKeyId": "", "userName": "Dev1" }, "eventTime": "2026-06-09T19:20:38Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-1", "sourceIPAddress": "198.51.100.76", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36", "errorCode": "AccessDenied", "errorMessage": "Authorization denied because of a resource-based policy", "requestParameters": null, "responseElements": { "ConsoleLogin": "Failure" }, "eventID": "d88a7543-ae89-4186-b1b6-d3116413f2ee", "readOnly": false, "eventType": "AwsConsoleSignIn", "managementEvent": true, "recipientAccountId": "123456789123", "eventCategory": "Management" } エラーメッセージフィールドには、拒否の原因となったポリシータイプが表示されます。 "Authorization denied because of a resource-based policy" (リソースベースポリシーにより認可が拒否されました)。 RCP による大規模展開 上記のステップでは、サインインのリソースベースポリシーを単一アカウントに適用します。多数のアカウントを管理する組織にとっては、RCP がより優れた方法です。RCP は AWS Organizations の組織、OU、またはアカウントレベルでアタッチでき、対象範囲内のすべてのアカウントに自動的に適用されます。RCP の例については、 こちら を参照してください。 RCP によってコンソールへのサインインが拒否された場合、エラーメッセージフィールドには拒否が "Authorization denied because of a resource control policy" (リソースコントロールポリシーにより認可が拒否されました) と表示されます。 Console Private Access とデータ境界による拡張 作成したサインインのリソースベースポリシーは、どのネットワークがお客様のアカウントのサインインフローに到達できるかを制御します。 AWS Management Console Private Access は補完的な制御を追加します。具体的には、お客様のネットワーク内から、コンソールアクセスを既知の AWS アカウントのセットに限定し、想定外の AWS アカウントへのサインインを防ぎます。 これらの機能を組み合わせることで、コンソールアクセスのデータ境界の形成に役立ちます。 ネットワーク境界: サインインのリソースベースポリシーと RCP は、コンソールサインインを想定するネットワーク (企業 IP 範囲、VPC) に制限します アイデンティティ境界: サインインのリソースベースポリシーと RCP は、信頼できるアイデンティティのみがコンソールにサインインできることを保証します。コンソール VPC エンドポイントポリシーとサインイン VPC エンドポイントポリシーは、信頼できるアイデンティティのみがお客様の VPC からコンソールを使用できることを保証します リソース境界: サインイン VPC エンドポイントポリシーとコンソール VPC エンドポイントポリシーは、お客様のネットワークからどの AWS アカウントに到達できるかを制限します この記事の制御はコンソールアクセスに焦点を当てています。これらの境界を他の AWS サービスやより広範な実装シナリオに拡張するには、 Data perimeter policy examples リポジトリと Data Perimeters Blog Post Series を参照してください。 まとめ サインインのリソースベースポリシーと RCP を使用することで、AWS マネジメントコンソールへのアクセスを想定するネットワークに制限できます。これらの制御は、すべての AWS 商用リージョンで追加料金なしで利用できます。 使い始めるには、 AWS サインイン ユーザーガイド を参照してください。組織全体での適用については、AWS Organizations ユーザーガイドの Resource control policies を参照してください。 Swara Gandhi Swara Gandhi は、AWS Identity Solutions チームのシニアソリューションアーキテクトです。安全でスケーラブルなエンドツーエンドのアイデンティティソリューションの構築に取り組んでいます。アイデンティティ、セキュリティ、クラウドに関するあらゆることに情熱を注いでいます。 Rishi Tripathy Rishi は、AWS Identity and Access Management (IAM) チームのプリンシパルプロダクトマネージャーです。企業が大規模に AWS 環境を保護するのに役立つアクセス制御メカニズムに焦点を当てています。導入が簡単で誤設定しにくいセキュリティプリミティブの構築に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は「 Introducing Agent Focus – Kiro 」を翻訳したものです。 開発者が AI と協働する方法は変わりつつあります。モデルは今や複数ステップの作業を計画し実行できるようになり、より多くの開発者が、自分で一行ずつコードを打ったり直接編集したりするのではなく、エージェントを導くことに一日を費やすようになっています。 IDE は別の場面のために作られたものです。IDE はコードを中心に据えますが、それはまさに「自分で編集しているとき」に欲しいものです。しかし、主な仕事がエージェントに実行させる作業を定義し、洗練し、方向づけることであるとき、それが必ずしも欲しいものとは限りません。 2026 年 6 月 25 日、私たちは Agent Focus を発表します。これは Kiro IDE における実験的な新しいビューで、エージェントとのやり取りを前面に押し出すものです。チャットファーストな働き方の基盤を築きます。やりたいことを記述し、会話を通じて洗練させ、作業を開始し、エージェントが進める様子を確認する——という流れです。これまでの IDE 体験がなくなるわけではありません。Agent Focus はそれと並んで存在し、いつでも両者を行き来できます。 Agent Focus でできること このビューの中では、複数のワークスペースをまたいで、独立して並行に動く複数のセッションを立ち上げられます。エージェントとチャットしてコードを書いたり、アイデアを探ったり、問題を解いたり——あるいはもっと構造が必要なときには仕様（spec）を定義・洗練したりできます。各セッションで何が起きているかを高い視点で把握し、対応が必要になったら介入する。じっくり見る必要がある作業のときには、コード中心のビューに戻って直接編集できます。 このビューは 3 つのパネルで構成されています。 エージェントパネル（左）: 新しいセッションを作成し、ワークスペースごとにグループ化して閲覧でき、各セッションの状態——作業中、入力待ち（ブロック中）、一時停止中——を一目で確認できます。終わったものはクリアできます。 チャットパネル（中央）: 刷新された新しいチャット体験。エージェントを導き、意図を洗練させ、作業が進む様子を見守れます。ファイルの変更はインラインのコード差分として表示されるので、ビューを切り替えることなく追えます。 補助パネル（右）: 必要になるまで非表示。エージェントが変更されたファイルや仕様のサマリーを示すために表示することもあれば、じっくり見たいときに自分で開くこともできます。 一部の機能はまだこのビューにネイティブ実装されていないため、Agent Focus は設定、powers、skills、MCP、ターミナル、完全な git、直接のファイル編集といったものについて、IDE へ戻る明確な経路を保っています。 これは実験であり、慣れ親しんだ IDE はそのまま残ります Agent Focus は実験的なリリースです。ぜひ試して、何がうまくいき、何がうまくいかないかを、インターフェース内の「Report issue」ボタン、 GitHub の issue、あるいは Discord で教えてください。ただし、中核となる IDE 体験は変わりません。IDE は引き続きデフォルトであり、今日あなたが行っていることはすべて今までどおりに動作し、好きなだけそこにとどまれます。Agent Focus は、私たちが早い段階であなたの手に委ねる「もう一つの働き方」です。 切り替え方法 切り替えは手間がかからないように作られています。Agent Focus はウィンドウ右上に常に 1 クリックで届く場所にあり、「Agent Focus」とラベル付けされています。戻りたいときは、同じ場所にあるコントロールが「IDE」とラベル付けされています。いつでも、どちらの方向にも、自分の作業位置を失うことなく行き来できます。 入手方法 Agent Focus は最新版の Kiro 1.0 に同梱されています。 Kiro ダウンロードページ から Kiro をアップデートし、新しいビルドになると Agent Focus がウィンドウ右上に表示されます。 Agent Focus は、Kiro におけるチャットファーストでエージェント中心の構築スタイルへの私たちの第一歩であり、ここから成長していきます。その最良の形は、あなたが実際にどう使うかによって形づくられるものです。 Kiro をダウンロード し、右上から Agent Focus を開き、いくつかセッションを動かして、気づいたことを私たちに教えてください。

本記事は「 One Task, Two Providers: Coordinating Changes Across GitLab and GitHub in one session 」を翻訳したものです。 Kiro Web は、既存の GitHub サポートに加えて、 GitLab でも動作する ようになりました。より興味深いのは、コードが GitLab と GitHub の両方にまたがって存在する場合に何が起きるかです。両方からリポジトリを同じセッションに追加し、単一の変更を記述すれば、Kiro がそれを両方にわたって実行し、一方にはマージリクエスト（MR）を、もう一方にはプルリクエスト（PR）を開いてくれます。これは、コードが 1 つのきれいな場所に収まっていないときに意味を持ちます。 2 つの場所に存在するコード 多くのチームはプロバイダーをまたいで分かれており、たいていそれには正当な理由があります。オープンソースの SDK はコミュニティが見つけられるように GitHub に置かれ、それが通信するサービスは GitLab 上にプライベートのまま残されている。あるいは買収によって、組織の半分が一方のプロバイダーに、もう半分が別のプロバイダーに分かれてしまった。あるいはフロントエンドとバックエンドのチームが、何年も前にたまたま別々のツールに落ち着いただけ、ということもあります。理由が何であれ、そのコストは変更が両方にまたがった瞬間に現れます。1 つの論理的な更新が、2 つのコンテキストで 1 つのプルリクエストと 1 つのマージリクエストになり、ステップを忘れて両者が同期からずれてしまう機会が 2 回生じるのです。 小さな例 ここで使うセットアップを示します。本物の代わりとして、あえてシンプルなものにしています。その場所に、あなたの実際のサービスと SDK を思い浮かべてください——数千行、本物のビジネスロジック、本物の利用者がいるものを。 GitLab 上のプライベートサービスがあるとします。 そして、 GitHub 上のパブリック SDK が、そのサービスをラップしています。 email フィールドをエンドツーエンドで追加したいとします。サーバー側の変更は GitLab に属し、SDK 側の変更は GitHub に属します。これは、2 つのリポジトリ、2 つのプロバイダーにまたがって、変更を加えないといけません。 1 つのプロンプト、両方のリポジトリ GitLab と GitHub の両方をすでに接続した状態で、セッションを開始し、両方のリポジトリ（GitLab の user-service と GitHub の user-sdk ）をアタッチします。そして、変更をシンプルな言葉で記述します。 両方のリポジトリがセッション内にあるため、Kiro はそれらを無関係な 2 つのタスクとして扱うのではなく、一緒に推論します。 隔離されたサンドボックスの中で作業し、両方のリポジトリを探索し、それぞれの側が何を必要とするかを把握し、変更を行います。サービスではレコードとレスポンスに email を追加し、SDK では User 型と使用例を更新します。各リポジトリにフィーチャーブランチを作成し、明確なメッセージでコミットします。 完了すると、2つの変更が待っています。サービス用の GitLab 上のマージリクエスト は以下のようになります。 そして、SDK 用の GitHub 上のプルリクエスト は以下のようになります。 それぞれが、何が変わったかと、そのアプローチの説明を伴っています。あなたは各変更を、それぞれのホームプロバイダー上で、チームがすでに使っているまさにそのワークフローでレビューしてマージします。レビュープロセスについては何も変わりません。ただ、クロスリポジトリの調整作業を自分でやらなくて済んだ、というだけです。 まとめ プロバイダーをまたぐ分割は、しばしば現実的で、維持する価値があります——パブリック対プライベート、あるチーム対別のチーム。維持する価値がないのは、1 つの変更を両方にわたって整合させるための手作業の労力です。Kiro Web に GitLab と GitHub を接続すれば、1 つのプロンプトが変更をエンドツーエンドで一貫させ、それでもあなたはすでに信頼しているプロバイダー上で、きれいな MR と PR をレビューできます。 Kiro Web で GitLab と GitHub を接続し、両方にまたがる変更を試してみてください。Kiro Web は app.kiro.dev で、Pro・Pro+・Power のサブスクライバー向けにプレビュー提供中です。さらに詳しくは GitLab ガイド をご覧になり、次に何がリリースされるかを知るには Kiro Web の changelog をフォローしてください。