本記事は 2026 年 7 月 20 日 に公開された「 Introducing KNFSD File Cache: Extending your NFS storage into the clouds 」を翻訳したものです 長年にわたり、 Amazon Web Services (AWS) はコンピューティングインフラをスケールアップ、スケールアウト、そして広域展開する手段を提供してきました。一方、ストレージ面、特に Network File System (NFS) を基盤とし、オンプレミスやハイブリッド環境にデータを持つ組織にとっては、同じペースで進化が進んでいませんでした。コンピューティング負荷の高いワークロードでより高いスループットが必要な場合、並列ジョブ向けに高速な共有アクセスが必要な場合、あるいはデータを複製せずに別の AWS リージョンやアベイラビリティーゾーンにコンピューティングを配置したい場合でも、課題は共通しています。移行やクライアント側の変更なしに、弾力的なコンピューティングに見合ったデータアクセスのスケールを実現することは、依然として難しい問題でした。 KNFSD File Cache (KNFSD) はその課題を解決します。 Amazon Elastic Compute Cloud (Amazon EC2) 上で動作するオープンソースの NFS キャッシングプロキシソリューションで、既存の NFS サーバーを透過的に AWS へ拡張します。クラウドインスタンスのすぐ近くに高性能なキャッシュ層を配置することで、ワークロードの実行場所を問わず、共有データへの高速アクセスを実現します。 本記事では、KNFSD の仕組みと、オンプレミスのファイラー、サードパーティ製品、 Amazon FSx などの AWS サービスを含む NFS 準拠のストレージとの組み合わせ方を説明します。また、単一の Terraform モジュールで本番環境向けのオートスケーリングクラスターをデプロイする方法と、100 Gb/秒の合計スループットを 1 時間あたり 6 ドル未満で実現する方法についても解説します。 「AWS との共同作業で行った初期の KNFSD プロトタイプにより、極めて長距離でも高性能なキャッシングがクラウドレンダリングで実用的であることが証明されました。KNFSD File Cache 向けの新しい AWS Solution Guidance の採用を楽しみにしています。これは、私たちが手作業で構築しなければならなかった機能をまさに製品化したものです。」 – Kimball Thurston、CTO、Wētā FX 対象となるユーザー KNFSD は、クラウド上の NFS データへの高性能かつ読み取り中心のアクセスと、ソースへの書き戻しが必要なあらゆる組織を対象に設計されています。ユースケースには以下が含まれますが、これらに限りません。 読み取り I/O が多いコンピューティング集約型の業界: 既存の NFS インフラに保存された大規模データセットへの高速な共有アクセスを必要とするワークロード全般。メディア & エンターテインメント (レンダーファーム)、ハイパフォーマンスコンピューティング、金融サービス、ヘルスケア & ライフサイエンス、エネルギー、気象 & 気候科学などが含まれます。 ハイブリッドクラウドおよびマルチクラウド: オンプレミスのファイラーや他のクラウドプロバイダーから、データの移行や複製なしに既存の NFS インフラを AWS へ拡張したい組織。 マルチリージョンおよびマルチ AZ : AWS リージョンまたはアベイラビリティーゾーン をまたいでコンピューティングを分散させるスタジオや研究チーム。KNFSD がデータをローカルにキャッシュすることで、中央の NFS ソースへのレイテンシーを解消します。 「KNFSD キャッシングソリューションは期待を上回る結果をもたらしました。開発中に AWS と協力し、本番環境でのスケール運用に必要な重要な内部メトリクスが確実に公開されるようにしたことで、独自ツールの構築が不要になりました。この取り組みのおかげで、不確実な状態から脱却し、複数のプロジェクトにわたって本番環境でこのソリューションを効果的に運用できるという確信を持てるようになりました。」 – Greg Newman、シニアマネージャー、プロダクションエンジニアリング & デジタルリソース、Industrial Light & Magic (ILM) KNFSD File Cache とは KNFSD は、ハイブリッドおよびバーストコンピューティングのユースケース向けに設計された高性能 NFS キャッシングプロキシを提供する、オープンソースの AWS Solution Guidance です。既存のオープンソースプロジェクトをフォークし、AWS との統合機能を加えて拡張しています。AWS 上での動作最適化 ( AWS Graviton を含む)、開発環境および本番環境向けのコンテナサポート、OpenTelemetry と Amazon CloudWatch を活用した包括的なメトリクスダッシュボード、そして Common Vulnerabilities and Exposure (CVE) 対策による強化されたセキュリティを備えています。 KNFSD File Cache は、実績ある Linux カーネル技術を基盤としています。 nfs-kernel-server – NFS マウントの再エクスポートをサポートする Linux カーネルネイティブの NFS サーバーです。プロキシがソースの NFS エクスポートをマウントし、まるで元のファイラーであるかのように下流のクライアントへ提供します。 cachefilesd (FS-Cache) – ネットワークファイルシステムのデータをローカルディスクに永続的にキャッシュする Linux カーネルモジュールです。同じファイルへの再リクエスト時は、ソースから取得するのではなく、キャッシュから直接提供されます。 KNFSD は kernel NFS daemon の略で、ソリューションを支えるカーネル空間コンポーネントへの敬意を込めた名称です。独自エージェント、ベンダー固有のプロトコル、特定のストレージソリューションへの依存は一切ありません。既存のファイラーに対して NFSv3 または NFSv4 で通信できる NFS クライアントであれば、変更なしに KNFSD と連携できます。 2 段階のキャッシュ KNFSD は、各プロキシインスタンスに 2 層のキャッシュ階層を提供します。 レイヤー 技術 媒体 特性 L1 Linux ブロックキャッシュ RAM 超低レイテンシー、インスタンスメモリ量に依存 L2 FS-Cache (cachefilesd) ローカル NVMe 高スループット、再起動後もデータが保持され、テラバイト級の容量 クライアントがファイルをリクエストすると、プロキシはまず L1 (RAM) を確認します。RAM からデータが退避されている場合は、L2 (NVMe ディスク) がローカルストレージの速度で提供します。完全なキャッシュミスが発生した場合のみ、プロキシはソースファイラーからデータを取得します。ファイルの取得後、そのプロキシに接続しているクライアントからの後続の読み取りはキャッシュから提供されます。 “EngineLab では、Barnstorm VFX などのスタジオ向けクラウドバーストレンダリングアーキテクチャの中核として KNFSD を導入しています。オンプレミスのコンピューティングリソースが枯渇した瞬間に AWS 上でレンダリング容量をスケールでき、KNFSD が限られた帯域幅接続でテクスチャなどの共通アセットを効率的にキャッシュします。レンダリング中はコンピューティングの料金のみを支払い、不要な時はゼロにスケールダウンできます。私たちが目指しているのはまさにこれです。インフラの制約を取り除くことで、お客様がクリエイティブな作業に集中し、より野心的なプロジェクトに挑戦でき、レンダーファームの規模によって締め切りが左右されることのない環境を実現することです。” – Sam Reid、CEO/Co-Founder、EngineLab 仕組み アーキテクチャはシンプルです。次の図は、コンピューティングが低レイテンシー・高帯域幅で NFS データにアクセスできるよう、KNFSD を使って再エクスポートされた NFS データへのローカルアクセスを提供するデプロイ構成を示しています。 図 1: KNFSD アーキテクチャ図 この構成には以下の機能が含まれています。 ソースマウント – 各プロキシインスタンスは、オンプレミスのファイラー、NFS 対応の Amazon FSx サービス、別のアベイラビリティーゾーンやリージョン、または他のクラウドプロバイダーなど、ソース NFS デバイスのエクスポートをマウントします。 接続 – KNFSD は、 AWS Site-to-Site VPN 、 AWS Direct Connect 、 AWS Interconnect (マルチクラウド) など、他の AWS インフラと同じ接続方式をサポートし、オンプレミスストレージへの安全で低レイテンシーなアクセスを提供します。 負荷分散 – Amazon EC2 Auto Scaling グループ が複数の KNFSD インスタンスを管理します。クライアントトラフィックは DNS ラウンドロビンまたは Elastic Load Balancing (Network Load Balancer) で分散されます。 クライアントへの透過性 – NFS クライアントは、通常の NFS 共有と同じ方法で KNFSD のエクスポートをマウントできます。特別なドライバー、エージェント、設定は不要です。 利用 – Amazon EC2 インスタンスはワークロードの処理に合わせてスケールし、変更なしに KNFSD 経由でソースデータにアクセスし、必要に応じて結果を書き戻します。また、スループット要件の増加に応じて KNFSD インスタンスのスケールアップを促すシグナルを提供します。 “NFS キャッシュは、長年にわたってお客様から繰り返しご要望いただいてきた機能です。自信を持ってお客様に提案できる AWS サポート付きのソリューションが登場したことを嬉しく思います。” – Paul Judkins、VP Cloud Services、Integrated Media Technologies (IMT) Global KNFSD File Cache の位置づけ AWS は幅広いストレージサービスを提供しています。耐久性の高いオブジェクトストレージと分析向けの Amazon Simple Storage Service (Amazon S3) 、フルマネージドの高性能ファイルシステム向けの Amazon FSx、そして弾力的なサーバーレス NFS 向けの Amazon Elastic File System (Amazon EFS) などがあります。これらはいずれも、対象ワークロードのプライマリストアとして設計されています。 データを移行したりクライアントのマウントパスを変更したりすることなく、既存の NFS ソースからバーストスケールのスループットを必要とするワークロードには、透過的なアクセラレーションレイヤーが必要です。 Amazon File Cache や Amazon FSx for NetApp ONTAP FlexCache などのマネージドオプションはこれらのシナリオの一部に対応していますが、Amazon EC2 上で動作するシンプルで低コストなオープンソースのキャッシュレイヤーが最適なケースも多くあります。特に、チューニングの完全な制御、透過的な NFS 再エクスポートのセマンティクス、そして柔軟なスケールアップ・スケールアウトが必要な場合に適しています。 KNFSD が埋めるのはこのニッチです。リポジトリには、強化された AMI、ルート Terraform モジュール (複数の子モジュールと独立したデータベース・メトリクスモジュールを含む)、組み込みのオブザーバビリティ、ヘルスチェック、オートスケーリング、ファンアウトトポロジーが含まれています。 キャッシュは KNFSD 層に保持されるため、ダウンストリームのコンピューティングインスタンスを Amazon EC2 スポットインスタンス (AWS が短い通知で回収できる、大幅に割引された中断可能なキャパシティ) として実行しても、データ損失や再取得のリスクはありません。スポットインスタンスが回収されて新しいインスタンスに置き換えられた場合も、新しいインスタンスはすぐにウォームキャッシュの恩恵を受けられます。 “『Avatar: The Way of Water』では、オンプレミス設備の 250% の規模のクラウドレンダーファームを運用し、AWS と共同開発した NFS キャッシュがショーのデータへのアクセスをスケールさせる上で不可欠な役割を果たしました。Avatar 後に改善点として挙げていた領域 (弾力的なスケーリング、ロードバランシング、階層型キャッシング) は、まさに AWS が KNFSD File Cache に組み込んだ機能です。ハイブリッドレンダーパイプライン全体への導入と、オープンソースプロジェクトへの貢献を楽しみにしています。” – Andy Wright、Head of Pipeline、Wētā FX 主な機能 KNFSD は、迅速なデプロイ、シンプルな運用、初日からのオブザーバビリティを実現するよう設計されています。このセクションでは、本番環境で特に重要な機能を説明します。 事前構築済み AMI リポジトリには Packer ビルドスクリプトが含まれており、Ubuntu ベースの最適化された Amazon Machine Images (AMI) を生成します。従来の x86 Intel・AMD プロセッサと、AWS Graviton Processors (ARM64) などの ARM ベースプロセッサの両アーキテクチャに対応しています。 Packer ビルドで作成されるイメージには以下が含まれます。 NFS 再エクスポートと FS-Cache を有効化したチューニング済み Linux カーネル CloudWatch と OpenTelemetry を使用したオブザーバビリティ向けの KNFSD メトリクスエージェント ヘルスチェックとステータス確認用の KNFSD HTTP エージェント ビルド検証用のスモークテスト AWS はストレージ最適化された Amazon EC2 インスタンス (L2 層向けのローカル NVMe 搭載) を幅広く提供しており、各パイプラインステージのアクセスパターンに合わせて KNFSD インスタンスを選択できます。数百万件の小さなファイル読み取りが中心のワークロードには、最新の i7ie および i8g ファミリーの低レイテンシー NVMe が適しており、大きなシーケンシャル読み取りには im4gn および i3en ファミリーの高スループットと大容量キャッシュが有利です。 AWS Graviton の優位性は特に注目に値します。NFS 再エクスポートとディスクキャッシングは、高いシングルスレッド性能を必要とせず複数コアに並列化しやすいため、AWS Graviton のアーキテクチャと自然に適合します。im4gn.16xlarge は i3en.24xlarge と同等の毎秒 10〜12 GB のスループットを、オンデマンドの時間単価でおよそ半分のコストで実現します。次の表は比較のための Amazon EC2 インスタンスタイプの一例です。最新のインスタンスタイプとリージョン別料金については、 Amazon EC2 インスタンスタイプ のドキュメントをご参照ください。 インスタンス アーキテクチャ ネットワーク ローカルNVMe $/時間 ** 用途 im4gn.16xlarge ARM 100 Gbps 30 TB $5.82 高スループット、GB/sあたりのコスト効率が最適 i8g.16xlarge ARM 50 Gbps 15 TB $5.49 最新世代NVMe、小規模ファイルのIOPSワークロード i3en.24xlarge x86 100 Gbps 60 TB $10.85 大容量キャッシュ、KNFSDの主力インスタンス i7ie.48xlarge x86 100 Gbps 120 TB $24.95 NVMeレイテンシが65%改善、レイテンシに敏感な読み取り処理 ** 執筆時点の US-East-1 (バージニア北部) の料金 ファンアウトアーキテクチャ 多数のクライアントが同じ大規模データセットを読み取るワークロードに対して、KNFSD はオプションの 2 層ファンアウトデプロイをサポートしています。単一の高メモリプロキシ (Tier 1) がソースファイラーとの通信をすべて処理することで、各ファイルが広域ネットワーク (WAN) を通過するのを 1 回のみに抑え、高レイテンシー・低帯域幅の環境にも対応します。2 つ目の小規模プロキシクラスター (Tier 2) がファンアウトして数百のクライアントを提供します。これにより、キャッシュソリューションは実質的に 2 つの役割に分かれます。プライマリの Tier 1 KNFSD インスタンスによる初回の長距離転送と NFS 再エクスポート、そしてクライアントに直接 NFS を提供するセカンダリ Tier 2 KNFSD インスタンスの仕様と最適化です。この構成により、セカンダリ KNFSD インスタンスはクラウド側のキャッシュ充填を維持しながらスケールアップ・ダウンおよびスケールイン・アウトが可能となり、初回の長距離転送の繰り返しを防ぎ、インフラ変更後も迅速に再キャッシュできます。次の図は基本的なファンアウトアーキテクチャを示しています。 図 2: 2つのティアの例, KNFSD ファンアウトアーキテクチャ この構成には以下の機能が含まれています。 ソースマウント – データのキャッシュ元となり、処理済みデータの書き戻し先となるソース NFS ファイルサーバーです。 長距離転送 – データはプライマリの Tier 1 KNFSD インスタンスにキャッシュされ、低帯域幅・高レイテンシー環境に対応します。 Tier 1 KNFSD インスタンス – このプライマリ層のインスタンスは、長距離トラフィックのキャッシュを一元的に担い、書き込みをソースファイラーに返します。 キャッシュ間転送 – KNFSD の Tier 1 と Tier 2 インスタンス間のデータ転送は、 Amazon Virtual Private Cloud (Amazon VPC) 内で行われます。 Tier 2 KNFSD インスタンス – スループット要件に対応するためにファンアウト構成を取るインスタンスです。ワークロードの性能特性に合わせてインスタンスタイプを選択でき、ローカルの Amazon VPC を活用した高速転送が可能です。 コンピュート・キャッシュ間転送 – コンピュートインスタンスは、同じ低レイテンシー・高帯域幅のローカル Amazon VPC 接続を使用して Tier 2 KNFSD インスタンスにマウントします。 エラスティックコンピュート – Amazon EC2 インスタンスはワークロードの処理に合わせてスケールし、変更なしに Tier 2 KNFSD インスタンス上の依存ソースデータにアクセスします。必要に応じて結果を書き戻し、スループット要件を満たすために Tier 2 のスケールアップを促すシグナルも提供します。 オブザーバビリティとメトリクス 従来の NFS インフラはクローズドなシステムとして運用されることが多く、ストレージが遅いと感じていても、その原因を診断したり、キャパシティに関する適切な判断を下したりするための詳細情報が不足しがちです。KNFSD は、CloudWatch Agent と OpenTelemetry ベースの KNFSD メトリクスエージェントを使用して、70 以上のカスタムメトリクスを CloudWatch に公開します。これらのメトリクスはキャッシュインフラの各層を包括的に可視化し、インフラのパフォーマンスをデータに基づいて深く理解するための基盤を提供します。以下の図は、ダッシュボードに表示されるメトリクスの例を複数示しています。 図 3: KNFSDで利用可能な複数の指標ビュー メトリクスのカテゴリ 公開されているメトリクスは、次の 5 つの主要領域をカバーしています。 NFS 接続数とクライアント数 – クラスターの使用率を追跡し、KNFSD インスタンスのスケールアウトが必要なタイミングを把握できます。 読み取り/書き込みスループットとレイテンシー (RTT および EXE) – クライアントがローカル速度に近いパフォーマンスを得られているかを確認し、劣化を早期に検出できます。 FS-Cache のヒット率/ミス率、LRU (least recently used) アクティビティ、ストレージ使用率 – ソースからデータを取得するのではなく、キャッシュがホットデータをどれだけ効果的に提供できているかを把握できます。 NFS スレッドおよびソケットのキュー深度 – プロキシのリクエスト処理パイプラインの飽和を、クライアントに影響が出る前に検出できます。 マウント別・エクスポート別の内訳 – 負荷の原因となっている特定のエクスポートやソースサーバーを特定し、ピンポイントでチューニングできます。 これらのメトリクスを組み合わせることで、プロキシの健全性、キャッシュの有効性、クライアント側の体感を総合的に把握でき、キャパシティ、パフォーマンスチューニング、コスト最適化に関する適切な判断が可能になります。 「AWS がメトリクスと直接連携し、実際の状況をリアルタイムで把握できるソリューションを提供してくれたことは、非常に大きな意味を持ちます。ダッシュボードは完成度が高く、ほとんどのチームがレンダーファームのデータについて持ち得ないレベルの可視性を提供してくれます。」 – Rob Dueckman、シニアソリューションアーキテクト、Integrated Media Technologies (IMT) Global 構築済み CloudWatch ダッシュボード 標準のインフラストラクチャーアズコードデプロイの一環として、構築済みの CloudWatch ダッシュボードがクラスターと同時にデプロイされます。手動でメトリクスを設定することなく、すぐに可視化を開始できます。ダッシュボードにはキャッシュヒット率、アクティブオブジェクト数、読み取り/書き込み帯域幅、IOPS、プロキシごとのトラフィック分散など、運用上重要なメトリクスが一目で確認できる形で表示されます。 Prometheus および Grafana へのエクスポート メトリクスエージェントは OpenTelemetry ベースのため、必要に応じてテレメトリを Prometheus や Grafana にエクスポートすることも可能です。 インフラのサイジングとコスト管理 最も重要なメトリクスであるキャッシュヒット率は、プロキシがオリジンサーバーへの読み取り負荷をどれだけ効果的に吸収できているかを直接示します。LRU エビクション率やスレッド・ソケットのキュー深度と組み合わせることで、適切な対応策が明確になります。接続が飽和しているがヒット率が良好な場合はスケールアウト (KNFSD インスタンスの追加)、エビクションが増加してヒット率が低下している場合はキャッシュディスクのスケールアップが必要です。 これらのメトリクスはパフォーマンス問題が発生した際の推測作業も不要にします。ネットワークの制約、キャッシュディスクの飽和、プロキシの過負荷を素早く切り分け、やみくもにキャパシティを追加するのではなく、適切な対処を取ることができます。 開発者体験とデプロイ このプロジェクトは、リポジトリのクローンから稼働クラスターまでの手順を最小限の手間で完了できるよう設計されています。リポジトリには Visual Studio Code Dev Container が同梱されており、Terraform、Packer、Go、Python、 AWS Command Line Interface (AWS CLI) 、各種リンティング・テストツールを含む開発環境がすぐに使える状態で提供されます。ローカルへのインストールは不要で、リポジトリを開いてコンテナを起動すれば、すぐに AMI のビルドやクラスターのデプロイを開始できます。 デプロイは単一の Terraform モジュールで完結し、Amazon VPC サブネット、AMI ビルド、ソース NFS エクスポートを指定するだけで開始できます。KNFSD インフラ (Amazon EC2 Auto Scaling グループ、セキュリティグループ、ヘルスチェック、DNS レコード、オプションのロードバランサー、FSID データベースなど) は宣言的に作成・管理されます。リリースタグでバージョンを固定し、標準の Terraform ワークフローで任意のタイミングでアップデートできます。 同じ Dev Container 環境が開発ライフサイクル全体をサポートします。Packer による AMI ビルド、パフォーマンスの実行とプロファイリング、テストクラスターのデプロイ、Terratest 統合によるスモークテストの実行まで対応しています。コントリビューター環境とデプロイ環境に差異はなく、両者は同一の環境です。 オートスケーリング NFS キャッシュのオートスケーリングは、標準的なメトリクスではうまく機能しません。CPU 使用率はプロキシの負荷を適切に反映しないため、NFS 接続が飽和していても CPU 使用率が 40% にとどまるケースがあります。KNFSD では代わりに、インスタンスごとのアクティブ NFS 接続数というカスタム CloudWatch メトリクスを基にスケーリングします。接続数が設定したしきい値を超えると、クラスターは自動的にキャパシティを追加します。スケーリングポリシーはスケールアップのみに設定されています。スケールダウンすると、構築に時間を要したウォームキャッシュデータが失われるだけでなく、より重大な問題として、アクティブな NFS マウントが切断され、クライアントで I/O ストールが発生するためです。ワークロードが落ち着いた後のスケールダウンは、任意のタイミングで手動で行います。 はじめに KNFSD は Apache 2.0 ライセンスのオープンソースプロジェクトとして、 GitHub で公開されています。 リポジトリには以下が含まれています。 開始するための詳細な 前提条件 ソース NFS サーバー、KNFSD プロキシ、NFS クライアントのエンドツーエンドのデプロイ手順を解説したステップバイステップの チュートリアル すべての機能、設定変数、運用上の考慮事項を網羅した包括的な ドキュメント Amazon FSx for NetApp ONTAP、Amazon FSx for OpenZFS、サードパーティの NFS ゲートウェイデバイス向けのすぐに使える サンプル 質問、機能リクエスト、フィードバックは以下からお寄せください。 GitHub Issues メールでのお問い合わせ まとめ NFS インフラはデータセンターの壁で止まるように設計されたものではありません。KNFSD を使えば、その必要もなくなります。 数千コアにわたる計算負荷の高いタスクを実行する場合でも、パイプラインを再設計せずにハイブリッドワークフローを AWS に拡張する場合でも、KNFSD はコンピュートがすでに AWS で享受しているのと同じ弾力性を、透過的かつ高性能に、ストレージのロックインなしでデータにもたらします。 今すぐ KNFSD File Cache から始めましょう。 参考資料 AWS HPC コミュニティによる NFS 再エクスポートの詳細: Accelerating file reads with a storage caching server (AWS HPC Blog) Avatar 2: Way of Water で Wētā FX が NFS 再エクスポートを使用して AWS 上でスケールした方法: How Wētā FX scaled NFS for Avatar: The Way of Water (DigiPro 2023) TAGS: amazon ec2 , Media & Entertainment , storage Andy Hayes Andy は、AWSのVisual Computing担当シニアソリューションアーキテクトです。 DJ Rahming DJ は、AWSのVisual Computing担当シニアソリューションアーキテクトです。 Mike Owen Mike は、AWSのVisual Computing担当プリンシパルソリューションアーキテクトです。 Sean Wallitsch Sean は、AWSのVisual Computing担当シニアソリューションアーキテクトです。   参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先:  awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本記事は Kiro ブログの記事「 Introducing Kiro Crew 」（2026年8月4日、著者: Bolin Chen、Zejiang (Joe) Guo、Zezhen Xu）を翻訳したものです。 気持ちのいい金曜日の午後。そろそろ仕事を切り上げて、外の天気を楽しもうとしています。ちょうど片付けを始めたところで、チームメイトから緊急のレイテンシー急増について助けてほしいと連絡が入ります。あなたは似たようなインシデントを覚えています。どのメトリクスを調べればいいか、どの診断を走らせるか、前回ログがどこを指し示していたか。問題の切り分け自体は、それほど難しくありません。ただ、いくつものツールをまたいで動く必要があるのに、あなたは一度に一箇所にしかいられないのです。 これが現実のエンジニアリング業務の姿です。それは決して「1 つのセッションで 1 つのタスク」ではありませんでした。リポジトリ、ツール、レビュー、そして何日もの時間にまたがります。たとえ 1 つのタスクが自走していても、それを支えているのは結局あなたです。コンテキストをつなぎ直し、ハンドオフを調整し、手持ちのツールを縫い合わせて、動き続ける何かに仕立てる。気づけばあなた自身が、自分のツール同士をつなぐ統合レイヤーになっています。そしてあなたが席を離れた瞬間、すべては止まり、あなたが戻るのを待ち始めます。 Kiro Crew は、その仕事を代わりに引き受けます。Crew にメッセージを 1 通投げれば、前回どう対応したかを探し出し、まとめ、同僚に送るところまでを、あなたが再び手を入れることなく進めてくれます。あなたはその日の仕事を終えて外に出て、「問題は解決しました」というチームからのメモを目にするだけです。 チケットのキューを渡せば、Kiro Crew はトリアージして振り分け、オーナーを特定し、あなたの判断が必要なものにフラグを立てます。複数リポジトリにまたがるインシデントを指し示せば、あなたが修正に集中している間に調査を進めます。マイグレーションを開始すれば、あなたが会議中でも眠っている間でも、チェックポイントとリトライを通じて前進し続けます。すでにあなたが使っているツールをつなぎ、セッションをまたいで作業を調整するので、戻ってきたときに待っているのは「やり直すべきワークフロー」ではなく「進んだ結果」です。 Kiro Crew の始まり Kiro Crew は、Amazon 社内の MeshClaw という個人プロジェクトとして始まりました。私たち 3 人は、社内には存在しなかったシンプルなものを求めていました。タスクを投げて、その場を離れ、戻ってきたらレビューする価値のある成果ができている。そして 1 つのプロンプトに付き添い続けるのではなく、複数のタスクを同時に走らせられる。そんな仕組みです。私たちは OpenClaw や、自己学習するエージェントで AI 開発を担う各種ツールの勢いに刺激を受けていましたが、社内開発のセキュリティ要件を満たすものが必要でした。日常的に使っているコーディングツールが Kiro だったので、CLI 経由で Kiro のハーネスの上に構築するのが自然な選択でした。 私たちはまず自分たちのために作りました。やがて Amazon 社内の他のビルダーたちが使い始め、そこで起きたことこそが、これをオープンに公開する理由そのものです。さまざまなバックグラウンドを持つビルダーたちは、単に使うだけでなく、自分の必要に合わせて拡張していきました。誰かが自分のワークフローで穴に気づけば、必要なピースを足し、それはその人自身にも、後から来る全員にも残りました。そうして作られたものの多くは、本来ならバックログに埋もれていたはずの作業です。狭いエッジケース、細かな使い勝手の改善——そのワークフローの中で生きている人だけが思いつくような修正です。6 か月足らずで、Kiro Crew は Amazon 社内の 39,000 人を超えるビルダーに採用され、500 人近いコントリビューターが 597 件の更新を、平均で週 143 コミットのペースで届けてきました。小さく具体的な貢献が積み重なり、個人のサイドプロジェクトは、エンジニアだけに限らない多様な職種のコミュニティによって維持されるものになりました。 この複利的な貢献こそが、オープンソース化を決断させた理由です。あなたのコードとツールにアクセスするワークスペースは、読めて、好きな場所で動かせて、中を検査でき、変更できるべきです。たとえその変更を望んでいるのが自分ひとりだったとしても。この分野は急速に変化しており、オープンソースこそが、すでに有用だと分かっているものを開発者の手に届け、それを使う人たちと一緒に進化させ続けるための手段です。 実務に仕事に耐えるセキュリティ 作業を任せるということは、Kiro Crew にコードや CI への本物のアクセスを渡すということです。だからこそ、最初のコミットから安全であるように作られています。Kiro Crew は初日から多層防御を備えています。OS レベルのサンドボックス、デフォルト拒否のコマンド制御、疑わしいパターンのブロック、入力検証、機密パスのブロック、認証情報のマスキング、そしてすべてのアクションを記録する署名付き監査ログです。オープンソースのエージェントは他にもたくさんあります。Kiro Crew に実務を任せられるのは、それが開発者のために一から作られており、プロダクションコードが要求するセキュリティ姿勢を備えているからです。オープンであるからこそ、すべてのレイヤーをソースと突き合わせて検証し、与えたアクセス権で何をしているかを見張ることができます。 あなたのコードに対して動くワークスペースが、ブラックボックスであってはなりません。Kiro Crew は Agent Client Protocol （ACP）の背後でエージェントをオーケストレーションし、すべてのステップをリアルタイムに観測できます。タスクをどう計画し、並列のサブエージェントをどう起動し、どのツールを呼ぶかをどう決め、各アクションを承認のためにどうゲートし、結果をどう統合し直すのか——そのすべてを見られます。Activity ビューには、各エージェントの推論、すべてのツール呼び出し、そしてその結果が発生順に、ダッシュボード上のエージェントごとのカードとして表示されます。 動かす場所も自分で選べます。デスクトップアプリ、Web ダッシュボード、TUI から Kiro Crew を直接操作でき、会話・ファイル・タスク・承認・メモリ・スケジュール・Apps を横断して扱えます。ローカルでも、自分が管理するリモートマシンでも実行できます。Slack、Telegram、Discord といったツールを接続すれば、ワークスペースやその状態を移すことなく、別のクライアントから同じ作業を続けられます。ダッシュボードはデフォルトでローカルにバインドされ、機密パスと認証情報は実行時に保護され、ツールのリクエストには承認を必須にでき、アクティビティはレビューのために記録されます。 開発者の仕事のしかたに、端から端まで寄り添う Kiro Crew は、複数リポジトリにまたがるインシデントを同時に調査する、あなたが不在の間に数時間かかるマイグレーションを走らせる、あるいはあなたがログインする前にオープンな PR をチェックして flaky なテストを直しておく朝の定期処理など、セッションをまたいで動くように作られています。それを可能にしているのは、いくつかの要素です。 エージェントは自己学習し、自己進化する: メモリが設定・アクティブなプロジェクトのコンテキスト・関連する履歴を新しいセッションへ引き継ぐので、ゼロから始まりません。あなたの訂正は永続的な「教訓」となり、以降の振る舞いを変えます。プロジェクト固有のガイダンス用に、ワークスペース単位の教訓も使えます。繰り返し現れるパターンは、検査・編集・削除ができる再利用可能なスキルになります。メモリ、教訓、スキルはつねに可視化されているので、Crew が何を持ち越すかはあなたが決められます。 あなたのエージェント Crew は、あなたがいないときも働き続ける: 定期ジョブはあなたが定義したスケジュールで動きます。朝のダイジェストがあなたの注意を必要とするものを集め、ハートビートが PR やデプロイの状態が変わるまで見張り、認証付き Webhook が外部イベントの到着をきっかけに作業を開始します。推論を必要としないジョブは、モデル呼び出しなしの素のスクリプトやコマンドとして実行されます。長時間のタスクは、あなたが別の作業をしている間も、チェックポイント・検証・リトライを通じて前進し続けます。 複数のエージェントを協調させる: 複数の会話のほうが向いている作業では、それぞれ独立したコンテキストを持つ会話を同時に走らせることもできますし、独立した調査や実装をサブエージェントに委譲し、その結果を親の会話に返させることもできます。専門エージェントが並列で作業を処理する間、メインの会話はゴールに集中し続けられます。 作業を目的専用のインターフェースへ持ち込む: すべての作業がチャットウィンドウに向いているわけではありません。Kiro Crew はそれを Apps に持ち込みます。Apps は共有可能で目的に特化したインターフェースで、一つひとつの指示をチャットせずに日々の業務を自動化できます。Apps はカスタム UI と、エージェント・スキル・スケジュール・インテグレーション・バックエンドサービスを組み合わせたものです。MCP Apps とプラグインがデータとアクションをその体験に持ち込み、Kiro Crew は受付からレビュー、完了までの作業の流れを整えます。たとえば Issue トリアージ App は、リポジトリのデータをリーディングペイン付きのキューに取り込み、トリアージ用のコントロール、専門エージェント、定期スキャンを備えます。App のストアページで利用できる Apps は今後も拡大していきますが、ローンチ時点ではワークツリー管理の DevFleets 、長時間タスクを実行する Task Runner 、Issue と PR をトリアージする Issue Radar などが含まれます。まだ用意されていないツールやユースケース、あるいは「自分の思い描く形」にするために、App SDK で独自の Apps を作ることもできます。 Launch Darkly アプリは、機能管理（フィーチャーマネジメント）の機能をKiro Crew に直接統合します。開発者はワークスペースを離れることなく、あらゆるプロジェクトや環境にわたって Launch Darkly の機能フラグを閲覧、検索、作成、更新できます。Launch Darkly の MCP サーバーとパブリックAPIを基盤としているため、フラグは AI コーディングセッションのネイティブな一部として機能します。エージェントはコード内のフラグ参照を特定し、フラグを利用した変更を実装した上で、ロールアウト（展開）の制御をユーザーに引き継ぐことが可能です。 自分のものにする Kiro Crew が広がったのは、そのアーキテクチャのおかげではありません。人々が自分の仕事や好みに合わせて曲げられたからです。その同じ可能性が、いまあなたのものになります。あなた専用のエージェントの Crew を組み上げ、あなた固有のツールとワークフローを横断して協調させ、仕事を止めずに進めてください。 今日ローンチする機能は、Kiro Crew を自分の実務で使っていた人たちが作ったものです。次にあなたが必要とする機能は、あなたが作れます。すでに使っているツールを MCP で持ち込み、App を作り、オーケストレーションを形づくり、作ったものを反復し続けてください。すでに持っているスキルもここで動きます。オープンな標準に基づく他のエージェントプラットフォーム向けに作られたものは、Kiro Crew でも変更なしに動くので、ゼロから始め直すのではなく、手元のものを持ち込めます。 プロジェクトの運営方法 私たちは、社内で MeshClaw を育ててきたときと同じ「Kiro Crew で作る楽しさ」を、開発者コミュニティにも体験してほしいと考えています。そのため Kiro Crew はオープンに開発されており、それはガバナンスの進め方も含みます。プロジェクトは MAINTAINERS.md に公開されたメンテナーによるステアリングコミッティが運営し、意図的にミニマルなガバナンスモデルを採っています。提案はプルリクエストとして提出され、リポジトリ上で議論され、決定はそこに記録されて誰でも読めます。どの開発者もその議論に参加できます。コントリビューション、議論、ガバナンス、ロードマップ計画はすべてオープンな場で行われ、次に何が出荷されるかをコミュニティが直接形づくれます。 私たちが言う「オープン」は、信頼に関わる意味でもオープンです。他の AI コーディングツールやプロバイダーとのインテグレーションを含め、あらゆる種類のコミュニティ貢献を歓迎します。開発者の仕事に役立つのであれば、それが Kiro 自身の製品戦略に合致するかどうかに関わらず、ここに置かれるべきです。Kiro はコアプロジェクトを健全に保ち、すべての Issue と PR に対応するためにエンジニアを専任で配置しています。まずは Kiro と AWS のエンジニアがプロジェクトをメンテナンスし、信頼できるコントリビューターが現れるにつれて、私たちのチーム外のメンテナーを含む形へとモデルを拡張していけます。ロードマップは通達ではなく、対話であるべきものです。 Kiro の上に構築 すでに Kiro を使っているなら、設定はそのまま引き継がれます。Kiro Crew はローンチ時点で Kiro CLI の上で動き、既存の .kiro 設定をそのまま読み込むので、ステアリングファイル、スキル、カスタムエージェントは追加設定なしで移行できます。 はじめかた Kiro Crew のページ からダウンロードするか、 GitHub リポジトリ を今日クローンしてください。リポジトリには macOS、Linux、Windows のセットアップ手順と、Slack、Telegram、WeCom を接続するためのガイドが含まれています。 まずは、すでに 1 セッションを超えて広がっている作業から始めてみてください。マイグレーション、定期的なレビュー、監視が必要なプルリクエストなどです。そこから App をインストールし、繰り返しているワークフローからスキルを作り、あるいはあなたの仕事に次に必要なインテグレーションをコントリビュートしてください。Kiro Crew は、開発者が自分にとって効いたものを共有することで育ってきました。オープンソースとしての公開は、これから何になるかを誰もが形づくれるようにするためのものです。あなたがどんなユースケースや機能を作り出すのか、私たちは待ちきれません。そして私たちと同じくらい、遊びながら試すことを楽しんでもらえたら嬉しいです。 ダウンロード | GitHub で見る | ドキュメントを読む | Discord に参加する

本記事は 2026 年 8 月 3 日に公開された Clare Liguori、Romain Dura、Al Harris、Richard Threlkeld による “ One agent, every surface: how we built the Kiro agent harness ” を翻訳したものです。 Kiro の開発初期、私たちは開発者の 1 日のなかでエージェント駆動の開発がどのように感じられるべきかを議論し始めました。繰り返し立ち返ったのは、セッションがラップトップとクラウドサンドボックスの間を摩擦なく行き来する姿でした。1 日の終わりにラップトップを閉じても、Kiro セッションはクラウドで動き続けます。コーヒーを取りに行く合間にスマートフォンから状況を確認できます。翌朝、Kiro IDE を開いて中断したところから作業を再開します。 Web 版 Kiro でプロジェクトを開始し、Kiro IDE でコンテキストを追加し、既にテストとイテレーションを進めているターミナルでは Kiro CLI を使い続け、Slack から進捗を確認します。エージェント駆動の開発とは、作業するあらゆるクライアントを横断する 1 つの連続した会話であるべきです。 今年の初め、私たちはエージェントのアーキテクチャがこのビジョンの実現を妨げていることに気づきました。当時、Kiro IDE、CLI、Web の各クライアントは、それぞれ独自のセッションフォーマット、ツールセット、設定モデルを持つ専用のエージェントを実行していました。セッションと環境の間を容易に移動するには、どのクライアントを使っていても、どこで動作していても同じように振る舞う単一のエージェントが必要です。クライアント専用のエージェントアーキテクチャでは、エージェント同士が十分な共通基盤を持っていなかったため、あるクライアントで開始したセッションを別のクライアントに移すことができませんでした。本記事では、3 つのエージェントのコードベースを 1 つの Kiro エージェントハーネスに統合した過程 (もちろん Kiro 自身を使って構築しました) と、私たちのビジョンを実現可能にしたアーキテクチャ上の決定について解説します。 分岐していった 3 つのハーネス Kiro を作り始めた当初、私たちはスピードと実験を優先しました。各クライアントチームが独自のエージェントハーネスを作ることを推奨しました。エージェントハーネスとは、エージェントループ、ツール実行、サブエージェントへの委譲、セッション管理、設定のロード、モデルとの通信を管理するオーケストレーション層のことです。IDE チームは Code OSS の拡張モデルに合わせて TypeScript で、CLI チームはパフォーマンスを重視して Rust で、Web チームは最新のエージェント研究に近い場所に居るために Python で、それぞれ独自に構築しました。 ハーネスを分けたことで各チームは独立して素早くリリースし、イテレーションできましたが、同時にそれぞれのチームが異なる選択をすることも意味しました。セッションストレージはクライアントごとに動作が異なりました。権限システムは独立して設計されており、互換性のない構文を使っていました。CLI は正規表現ベースの allowedCommands / deniedCommands を使い、IDE は trustedCommands にプレフィックスマッチを、denylist にはサブストリングマッチを使っていました。コンパクション戦略も分岐しました。サブエージェントのコンテキスト共有も異なるモデルに従っていました。カスタムエージェントもクライアントごとに動作が違いました。機能セットも分裂しました。仕様駆動開発と powers は IDE のみで動作し、プランモードとコードインテリジェンスは CLI のみで動作していました。 実装コストは時間とともに複利で膨らみました。新しい機能は 3 回作って 3 回保守する必要があり、その結果としてエージェントの挙動がわずかに異なることもありました。バグも 3 回修正する必要がありました。ユーザーはどのクライアントを選ぶかによって不整合を体験することになりました。セッションがクライアントとコンピュートを横断して移動するという私たちのビジョンは、共有のセッションフォーマット、共有のツールセット、共有の設定モデルが存在しないためアーキテクチャ的に不可能でした。各チームの独立性と個別のスピードを維持するために、クライアント間でエージェントの振る舞いに関する契約を合意し、3 つのハーネスそれぞれで実装するという案も検討しました。しかしインターフェースの整合を取ることも、新機能ごとに増えていく調整コストを生みます。新機能ごとに仕様書、3 つの実装、そして同一の振る舞いを継続的に検証する作業が必要になるのです。 転機となったのは、Web 版 Kiro のパブリックローンチの準備を進めていたときでした。Web 版 Kiro を独自のエージェントとともにローンチし、この複利的な実装コストを払い続けるのではなく、各チームが学んだベストな知見を組み合わせた単一のエージェントハーネスを構築することを決めました。単一のハーネスであればチーム間の重複がなくなり、すべての労力を 1 箇所に集中投資できます。 Kiro エージェントハーネスのアーキテクチャ 私たちが早い段階で下した重要なアーキテクチャ判断は、ハーネスを各クライアントにコンパイルして組み込むライブラリではなく、独立したサーバープロセスとして構築することでした。過去の試みから、共有ライブラリでは十分に強い境界を強制できないことがわかっていました。クライアントコードは公開を意図していない内部メソッドを呼び出し始めるか、ライブラリの上に独自のエージェントロジックを重ねてしまいます。そうなれば実装は再び分岐していきます。独立したプロセスであれば、この分離が現実のものになります。ハーネスとクライアントは同じ言語やランタイムを共有する必要がないため、各クライアントは自分のプラットフォームに適したスタックのまま留まれます。 これにより、3 つの密結合したクライアントとエージェントのペアではなく、 ┌────────────┐ ┌────────────────────────────────┐ │ Kiro IDE ├──────│ IDE agent (TypeScript) │ └────────────┘ └────────────────────────────────┘ ┌────────────┐ ┌────────────────────────────────┐ │ Kiro CLI ├──────│ CLI agent (Rust) │ └────────────┘ └────────────────────────────────┘ ┌────────────┐ ┌────────────────────────────────┐ │ Kiro Web ├──────│ Web agent (Python) │ └────────────┘ └────────────────────────────────┘ クライアントと単一のエージェントハーネスとの間にきれいな分離ができました。 ┌─────────────────────────┐ ┌─────────────────────────────────┐ │ Clients │ │ Kiro agent harness │ │ │ │ │ │ UX and presentation │ │ Agent loop │ │ User interaction │───protocol───│ Tools and sub-agents │ │ Platform-native tools │ │ Session state │ │ (optional overrides) │ │ MCP client │ │ │ │ Configuration and steering │ │ │ │ Permissions │ │ │ │ Telemetry │ └─────────────────────────┘ └─────────────────────────────────┘ Kiro エージェントハーネスはコードベースの隣で動作する軽量なプロセスで、高速に起動し、エージェント側のすべてを所有します。クライアントはユーザーがエージェントとどのようにやり取りするか、エージェントの作業をどのように提示するかを所有します。この境界を越える唯一の方法は、定義されたプロトコルインターフェースです。コンパイルされて組み込まれるライブラリではなく独立したプロセスであるため、あらゆるコンピュート上で動作できます。同じハーネスがラップトップ上でも、クラウド上の VM 内でも、クライアントに意識させることなく起動できます。 サーバーとクライアントの間に明確なインターフェースがあるということは、エージェントのコードがクライアントとは独立して進化することを意味します。ハーネスの変更がプロトコルインターフェースに影響を与えない場合 (たとえば新しいツールの追加、プランニングの改善、エージェントループのチューニング)、クライアント側の変更ゼロですぐにすべてのクライアントにリリースできます。たとえば最近、カスタムエージェントのライブリロード機能を追加しました。セッション中に .kiro/agents/ のファイルを編集すると、ハーネスがすぐに検知し、利用可能なコマンドをクライアントに再度通知します。利用可能なコマンドの通知タイプはすでにプロトコルに存在していたため、クライアントの変更は不要でした。どのクライアントも追加の変更なしにこの機能を手に入れられたのです。 サポート対象のクライアントが多様なため、このハーネスは画一的な設計ではありません。クライアントごとに機能が異なり、一部の操作はクライアントネイティブの機能を使ってクライアント層で実装するほうが理にかなっています。クライアントは独自のツールを提供して組み込みツールを抑制でき、自分のフォームファクター (form factor) に合ったものを使えます。たとえば IDE はファイル操作に Code OSS の API を使い、ファイルシステム上で直接動作するハーネスの組み込みツールではなく、独自のファイル読み書きツールを提供しています。エージェントがこれらのクライアント提供ツールのいずれかを実行する必要があるときは、クライアントに通知し、クライアントがツールを実行して結果を返します。 プロトコル: Agent Client Protocol (ACP) クライアントとハーネスの境界を定義するプロトコルとして、 Agent Client Protocol (ACP) を選びました。ACP はエージェントとクライアントの通信を標準化した仕様で、2026 年 6 月に 1.0 に到達しました。このプロトコルは JetBrains の IDE、Xcode、Zed といった IDE や、Obsidian、Emacs、Neovim といったほかのエディターでもサポートされています。私たちは今年の初めに Kiro CLI で ACP を採用した経験 から、これらのアプリケーション内で直接 Kiro とやり取りできるようにしていました。統一されたハーネスにも ACP を採用することにしたのは、サードパーティ製エディター向けだけでなく、Kiro 自身のクライアントと私たち自身のエージェントの間のインターフェースとして使うためです。ACP の 2 つの性質がこれを可能にしました。カスタムメソッドに対する拡張性と、トランスポートの柔軟性です。 ACP は公式にトランスポートとして stdio をサポートしています。これはハーネスがエディターやターミナルの子プロセスとして動作するローカルクライアントで機能します。Web 版 Kiro や iOS アプリのようなリモートクライアントには、別のトランスポートが必要でした。これらのクライアントがクラウドサンドボックスで動作するハーネスに接続できるように、独自の WebSocket ベースのトランスポートを追加しました。クライアントがどのトランスポートを使うかに関わらず、バイナリ、ツール、エージェントの振る舞いは同一です。 ┌─────────────────────────────────────────────────────────────┐ │ Kiro agent harness │ └──────────┬────────────────┬────────────────┬────────────────┘ │ stdio │ stdio │ WebSocket │ │ │ ┌──────┴──────┐ ┌──────┴─────┐ ┌───────┴──────────────┐ │ Kiro CLI │ │ Kiro IDE │ │ Kiro Web · iOS app │ │ (terminal) │ │ (Code OSS) │ │ (browser · mobile) │ └─────────────┘ └────────────┘ └──────────────────────┘ トランスポートを超えて、私たちは ACP のメソッドセットを Kiro-ACP と呼ぶものに拡張しました。標準の ACP は基本的な部分 (セッションのライフサイクル、メッセージのストリーミング、ツール呼び出しのレポート) を扱いますが、Kiro の機能にはそれ以上のものが必要でした。たとえばライブステアリングを追加しました。ユーザーはエージェントの作業中でもメッセージを送信でき、そのメッセージが次の推論ターンで注入されることで、キャンセルや待機なしにエージェントの方向性を調整できます。ACP はメッセージのキューイングをサポートしていないため、ライブステアリングを実現するために新しいメソッドプロパティと通知で ACP を拡張しました。また Kiro の仕様駆動開発ワークフローを専用のメソッド群としてモデル化し、ACP の基本的なツール承認を豊富なマルチスコープの権限システムへと拡張し、コンテキストウィンドウの使用状況とフック実行に関する通知を追加しました。合計で Kiro-ACP はベースプロトコルに加えて 20 を超えるエージェント呼び出し可能なメソッド、15 のクライアント呼び出し可能なメソッド、20 の通知タイプを追加しています。ACP の拡張モデルはこれをきれいに保ちます。仕様どおり、カスタムメソッドはアンダースコアのプレフィックスを使い、Kiro の拡張はすべて _kiro/ 名前空間の下に配置されています。プロトコルをフォークすることなく、Kiro 固有の機能のために拡張できるのです。 結果として、サードパーティのクライアントはファーストパーティのクライアントと同じ方法で接続できます。ACP 互換のクライアントであれば、ツール、サブエージェント、セッション管理、MCP 接続を含む完全なエージェントを利用できます。ファーストパーティのクライアント (IDE、CLI、Web、iOS) は加えて Kiro-ACP の拡張を利用して、ライブステアリング、仕様、リッチな権限 UI、コンテキスト使用量トラッキングといった機能を提供します。 仕様、エージェント、フックがどこでも使える 単一のハーネスがもたらす直接的なメリットは、これまで 1 つのクライアントに閉じ込められていた機能が、同じ設定フォーマットと同じ振る舞いで、どのクライアントでも使えるようになったことです。 仕様駆動開発 は以前は IDE 限定でした。今では CLI ( /spec new で開始できます) と Web 版 Kiro でも動作します。エージェントは仕様ワークフローを駆動する LLM とのやり取りと自動化された推論 (要件の生成、技術設計の作成、作業のタスクへの分解) を扱い、各クライアントは自分のフォームファクターに合った形でそれを提示します。IDE は仕様のアーティファクトを横並びのペインで表示します。CLI はターミナル内でレンダリングします。Web 版 Kiro はブラウザーでインラインレビューとマルチユーザーコラボレーションとともに表示するので、チームが一緒に仕様をイテレーションできます。エージェントは ACP を話し、クライアントは出力をどう提示するかを決めます。 カスタムエージェント は、どのクライアントでも同じ .kiro/agents/ Markdown フォーマットを使います。エージェントには説明、システムプロンプト、タグベースのツール選択 (個別のツール名ではなく read 、 write 、 shell といったシンプルなタグ)、アクセス可能なサブエージェント、インラインの MCP サーバー定義、インラインの権限ルールを定義できます。カスタムエージェントの設定をバージョン管理にコミットすれば、チームメンバー全員がすべてのクライアントで使えるようになります。 --- description: セキュリティ上の問題を確認するコードレビューエージェント tools: [read, shell, "@github"] permissions: rules: - capability: fs_read effect: allow - capability: shell match: ["git diff *", "git log *", "npm audit"] effect: allow mcpServers: github: url: https://api.githubcopilot.com/mcp/ headers: Authorization: Bearer ${GITHUB_TOKEN} --- あなたはセキュリティに重点を置いたコードレビュアーです。現在の差分を レビューし、脆弱性、認証情報の漏洩、安全でないパターンを確認してください。 依存関係のアドバイザリは npm audit で確認してください。 フック は同じ .kiro/hooks/*.json フォーマットを使い、同じトリガー ( SessionStart 、 PreToolUse 、 PostToolUse 、 FileCreate 、 FileSave ) で、すべてのクライアントで同じように動作します。 機能の可用性を超えて、統一されたハーネスは、正しく作るのが難しい領域でも一貫した振る舞いを提供します。コンテキスト管理、コンパクション、要約は、どのクライアントを使ってもすべて同じように動作します。以前はハーネスごとに独自のコンパクション戦略を持っていたため、IDE、CLI、Web クライアントのどれを使っているかによってセッションが長くなるにつれて振る舞いが変わることがありました。今では 1 箇所で実装、テスト、改善される単一の実装があります。統一されたハーネスをクライアント全体に展開して以来、コンテキスト保持を改善するため、ハーネスにより良いコンパクションプロンプトをすでにリリースしています。またハーネスの深い部分でレジリエンスとパフォーマンスの改善もリリースしました。モデル推論リクエストの改善されたリトライロジック、高速な権限評価、より弾力性のある MCP サーバー接続などです。すべてのクライアントがこれらの変更の恩恵を受けます。結果として、どのクライアントを好むかに関わらず、一貫した品質と信頼性が得られます。 単一のポリシー言語 統一ハーネスが登場する前、各クライアントは異なる構文、異なるセマンティクス、異なる設定場所を持つ独自の権限システムを持っていました。CLI は正規表現パターンによる allowedCommands / deniedCommands を使いました。IDE はプレフィックスマッチによる trustedCommands と、サブストリングマッチによる別の commandDenylist を使いました。どちらのクライアントでも権限はツール単位でした。 .env への読み取りを拒否する といった単一の意図は、ファイルを読める各ツール (read、glob、grep、コードインテリジェンス) に対して個別に設定する必要があります。1 つでも見落とすと、エージェントは別のツール経由でそのファイルにアクセスできてしまうのです。ユーザーはツール呼び出しごとに y を押し続けるか、すべてを信頼するかの二択を迫られ、その中間の実用的な選択肢がありませんでした。私たちが求めていたのは、ケイパビリティレベルで意図を表現でき、永続的かつ組み合わせ可能な同意によって承認疲れ (acceptance fatigue) を減らせる権限モデルでした。 今では、形式的に検証されたポリシー言語である Cedar に支えられた、単一のケイパビリティベースの権限モデルがあります。1 つのルールで、すべてのツールにまたがる同種の操作をまとめて対象にできます。 rules: # Block all tools that read files from accessing secrets - capability: fs_read match: [".env", ".env.*", "secrets/**", "**/*.pem"] effect: deny # Allow specific shell commands without prompting - capability: shell match: ["npm test *", "npm run build", "git status"] effect: allow # Allow an MCP server's tools - capability: mcp match: ["github/*"] effect: allow ケイパビリティはツールを機能ごとにグループ化します。 fs_read 、 fs_write 、 shell 、 web_fetch 、 mcp 、 subagent などです。fs_read の deny は、ファイルを読むすべてのツール ( read_file 、 grep_search 、 file_search 、そして今後追加される read 系ツール) を個別に列挙することなくブロックします。 ポリシーは複数のスコープにまたがって合成でき、deny が常に勝つセマンティクスでマージされます。Kiro 自体は変更不可能なセキュリティ不変条件を適用します (たとえば、エージェントは自身の権限ファイルを変更できません)。エンタープライズ管理者は MDM 経由で制限をプッシュできます。ユーザーは自分のルールをユーザーレベルまたはワークスペースレベルで設定します。エージェントプロファイルはその役割に応じた権限を宣言できます。セッションレベルの判断は、作業しながら積み上がっていきます。事前の設定は不要です。ポリシーは同意の判断を下すにつれて自然に育っていき、意味のあるスコープでそれを永続化できます。 ハーネスがビジョンを解き放つ 新しいエージェントハーネスアーキテクチャの成果はすでに現れています。すべてのクライアントが統一ハーネスに移行して以来、クライアント側の変更ゼロで複数の機能をクライアント横断でリリースしてきました。グローバルフックとポリシープリセットもその一例です。 グローバルフック は ~/.kiro/hooks/ でフックを一度定義するだけで、すべてのワークスペースで自動的に発火するため、保存時のリント実行やコミット前のセキュリティチェックといった横断的な振る舞いをプロジェクトごとに複製する必要がなくなります。 ポリシープリセット は edit-workspace や dev-shell のような合成可能な名前付きルールセットで、一般的なワークフローにおけるプロンプト疲れ (prompt fatigue) を減らします。権限にポリシープリセットを追加すると (たとえば policies: [dev-shell, edit-workspace, read-all] )、ハーネスのポリシーエンジンがロード時にそれらを個別のルールに展開します。どちらの機能もハーネスのアップデートだけですべてのクライアントに提供されました。 本記事の冒頭で述べたビジョンには、まだ構築が必要なエージェントの能力 (ケイパビリティ) がいくつかあります。たとえば、環境間でセッションを移動するためのセッションパッケージングや、ローカルとクラウドの両方のセッションをどのクライアントからも制御できる機能などです。統一されたハーネスなら、新しい能力を一度作るだけで済みます。多くの場合、グローバルフックやポリシープリセットのように、クライアント側の変更ゼロですべてのクライアントに配信できます。統一ハーネスがクライアント側の作業を完全になくしたわけではありませんし、そうしたいわけでもありませんでした。ターミナル、デスクトップの IDE、ブラウザー、スマートフォンは異なるインタラクションモデルを持っており、私たちは画一的な体験を提供するのではなく、各クライアントがそのフォームファクターに合った体験に感じられることを望んでいます。新しいエージェントハーネスアーキテクチャなら、エージェントのロジックはクライアント全体で同一で、各クライアントチームはそれとどうやり取りするのがベストかに集中できます。 Kiro のユーザーとして、新しいエージェントハーネスアーキテクチャは、新しい能力がより速く届き、一貫した振る舞いを示し、あなたが好むクライアントに関わらず同じ設定で動作することを意味します。 新しい Kiro エージェントハーネスを試す 新しい Kiro エージェントハーネスは 4 つの Kiro クライアントすべてでライブ稼働しているので、今日から試せます。 Kiro IDE 1.0 は、ケイパビリティベースの権限、タグベースツールとインライン MCP を備えたカスタムエージェント、並列セッションを指揮するためのエージェントフォーカスモード、ドッキング可能なチャットタブ、セッションエクスポートを提供します。 IDE 1.0 のドキュメントと移行方法 を参照してください。 Kiro CLI v3 (アーリーアクセス) は、仕様駆動開発、permissions.yaml、拡張されたフック、新しいエージェント設定フォーマットを備え、ターミナルで同じ統一ハーネスを実行します。 kiro-cli --v3 で試せます。 CLI v3 のドキュメントと移行方法 を参照してください。 Web 版 Kiro (プレビュー) はクラウドサンドボックスでハーネスを実行し、ブラウザーで仕様を使った自律的な開発、マルチリポジトリセッション、GitHub と GitLab の統合を提供します。 サインイン / サインアップ できます。 iOS 版 Kiro (プレビュー) は Web 版 Kiro と同じクラウドセッションにスマートフォンから接続し、ラップトップを開かずに自律的な作業のキックオフ、差分のレビュー、変更の承認を行えます。 アーリーアクセスをリクエスト してください。 翻訳は Solutions Architect の吉村が担当いたしました。

本ブログは 2026 年 8 月 5 日現在の内容を元に記載しております。記載内容については今後変更される可能性があります。 こんにちは ! テクニカルインストラクターの室橋です。AWS 認定に上位・下位関係があることはご存知の方も多いかと思います。しかし、 「具体的にどの認定を更新すると、どの認定が一緒に更新されるのか」 を正確に把握されている方は意外と少ないのではないでしょうか ? 今回は、この上位・下位関係を図とともに整理してお伝えします。 はじめに AWS 認定には Foundational、Associate、Professional、Specialty の 4 カテゴリがありますが、このうち Specialty 以外の 3 カテゴリには明確な上位・下位関係が定義されています。この記事では、その関係を図で整理しつつ、再認定時の活用方法と注意点を解説します。 上位・下位関係の定義されている AWS 認定の 3 つのカテゴリ 上位・下位関係の定義されている AWS 認定は、以下の 3 つのカテゴリに分かれており、上位カテゴリの認定を取得 (または更新) すると、その下位にあたる認定も自動的に更新されます。 Professional (上級): Solutions Architect Professional、DevOps Engineer Professional など、青緑のバッジのもの Associate (中級): Solutions Architect Associate、Developer Associate など、青いバッジのもの Foundational (基礎): Cloud Practitioner、AI Practitioner など、グレーのバッジのもの ※ 上記に加えて、Specialty (専門) という別カテゴリの認定もあります (後述)。 具体的な上位・下位関係は以下の通りです。 Solutions Architect 系 Solutions Architect Professional (上位) └→ Solutions Architect Associate (中位) └→ Cloud Practitioner (下位) DevOps Engineer 系 DevOps Engineer Professional (上位) ├→ CloudOps Engineer Associate (中位) ├→ Developer Associate (中位) └→ SysOps Administrator Associate (中位) └→ Cloud Practitioner (下位) Generative AI Developer 系 Generative AI Developer Professional (上位) ├→ Data Engineer Associate (中位) └→ Machine Learning Engineer Associate (中位) ├→ Cloud Practitioner (下位) └→ AI Practitioner (下位) つまり、例えば Solutions Architect Professional を更新すれば、Solutions Architect Associate と Cloud Practitioner も一緒に更新されることになります。こちらの内容をまとめたものが下図となります。 ただし、注意点があります。上位認定を更新した場合に下位認定も更新されるのは、 その下位認定をすでに取得している場合に限ります。 上位認定を取得・更新したからといって、まだ取得していない下位認定が自動的に付与される (取得されたことになる) わけではありませんのでご注意ください。加えて、 認定が更新されるのは「そのタイミングで有効な認定のみが対象となる」 点も注意が必要です。上位認定を更新した際に、失効状態の下位の認定が後から再度有効になることはありません。下位の認定を有効にしたい場合は再度認定を取得しなおしていただく必要があります。 この仕組みを活用した再認定戦略 複数の認定を持っている場合、上位・下位関係を理解しておくと、効率的に再認定ができます。 例えば: Cloud Practitioner と Solutions Architect Associate を持っている場合 → Solutions Architect Associate を再認定すれば Cloud Practitioner も更新される Associate 複数と Professional を持っている場合 → Professional の再認定をすればその下位に紐づく Associate と Foundational も更新される さらに、 認定に合格すると「次回以降の試験で使える50%オフのバウチャーコード」が特典として付与されます。 再認定の際にはこちらを活用することで、費用を抑えながら継続的にチャレンジいただけます。 再認定の具体的な方法 (試験の再受験、認定更新プログラムなど) については、こちらのブログ記事で詳しく解説しています: →　 AWS 認定の新しい更新方法についてのブログ記事 Specialty は独立している もう一つ押さえておきたい点は、 Specialty (専門) 認定は、ここまででご案内してきた上位・下位関係に含まれない ということです。 つまり、Specialty 認定は他の認定と上位・下位の関係がないため、Professional を更新しても Specialty は更新されませんし、その逆も同様です。Specialty を維持したい場合は、Specialty 自体を個別に再認定する必要があります。 なお、AWS Certified Advanced Networking – Specialty は 2026 年 8 月 25 日をもってリタイア (廃止) となる予定です。リタイア後は新規受験ができなくなりますのでご注意ください。 まとめ 本ブログをまとめると下記の内容となります。 AWS 認定には Professional、Associate、Foundational、Specialty の 4 カテゴリがある その中の 3 つのカテゴリには Professional → Associate → Foundational という上位・下位関係がある 上位の認定を更新すると、取得している有効な下位の認定も自動的に更新される 複数認定を持っている場合は、上位・下位関係を活用して効率的に再認定が可能 Specialty 認定はこの上位・下位関係に含まれない (独立して再認定が必要) ぜひこの上位・下位関係をうまく活用して、効率的な再認定計画を立ててみてください。皆さまの継続的なスキルアップを応援しています ! 著者について 室橋 弘和 (Hirokazu Murohashi) AWS トレーニングサービス本部 Technical Instructor 兼 Customer Success Manager Cloud Quest とデカ盛りのお店巡りをこよなく愛するマン。老眼鏡が必要になってきました。

本ブログは dSPACE Japan 様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 1. はじめに 自動車分野で行われている自動運転技術の開発では、データ駆動型アプローチの重要度が高まっています。膨大な実走行データを体系的に整備・活用することで多様な運転環境への対応が可能になり、モデルの汎化性能と信頼性を継続的に向上させることができます。 しかし、自動運転システムが生成するデータ量は膨大であり、その管理と活用には大きな課題が伴います。データ収集から学習、検証、デプロイ、モニタリングまでを統合管理する「MLOps」の導入が不可欠です。 本記事では、30 年以上にわたり車両開発ツールを提供してきた dSPACE 社の製品と、AWS クラウドサービスを統合した MLOps ソリューションをご紹介します。 2. 自動運転開発における課題 自動運転技術の進展に伴い、AI を活用した認識・判断アルゴリズムの高度化が急速に進んでいます。一方で、実際の車両開発・量産適用を見据えると、単なるモデル精度の向上だけでは解決できない、複合的な課題に直面されているのではないでしょうか。 膨大かつ多様なセンサーデータの管理と活用 先進的な自動運転システムでは、1 時間あたり 1 テラバイトを超えるカメラデータに加え、LiDAR、Radar、GPS など多種多様なセンサーデータが生成されます。これらのデータは地理的にも分散して収集されることが多く、効率的な保存・検索、シナリオや条件に基づくデータ抽出、開発・検証フェーズ間での一貫したデータ利用を実現することが大きな課題となっています。 学習精度と車両環境での挙動の乖離 クラウド環境で学習した AI モデルが高い認識精度を示していても、リアルタイム実行制約、センサー同期誤差やノイズ、車載ハードウェア上での実行条件といった要因により、実車両環境では期待通りに動作しないケースが少なくありません。このため、学習結果をそのまま車両に適用するのではなく、車両環境を考慮した検証・評価プロセスを MLOps と連携させることが不可欠となります。 検証と学習の分断による改善サイクルの停滞 自動運転の安全性は、まれなエッジケースや特定シナリオへの対応によって大きく左右されます。しかし多くの開発現場では、クラウドを中心とした AI 開発・MLOps チームと、SIL (Software-in-the-Loop)／HIL (Hardware-in-the-Loop)／実車評価を担う車両開発チームが、異なるツールやプロセスで作業しています。この分断により、どのシナリオで性能低下が発生したのか、その原因となるデータをどのように再学習へ反映させるのかといった情報がチーム間で共有されず、検証結果を効率的に再学習へフィードバックする仕組みが整っていないケースが多く見られます。検証結果と学習データを結び付け、継続的な改善サイクルを回すことが大きな課題です。 再現性・説明責任の確保と検証コストの増大 自動運転 AI の開発では、使用したデータ、学習条件、モデル構成、検証環境を後から正確に説明・再現できることが求められます。しかし、実験管理、検証条件、車両構成情報が個別に管理されることで、結果の再現性やトレーサビリティの確保が困難になり、社内レビューや将来的な認証・法規対応を見据えた際に重大なリスクとなります。さらに、データ駆動型開発ではモデル更新が頻繁に行われるため、そのたびに同等レベルの検証を実施することは大きな負担となります。すべてを再検証するのではなく、モデル変更の影響範囲を見極め、効率的に検証を行う仕組みが必要とされています。 これらの課題を解決するためには、クラウド MLOps のスケーラビリティと、車両開発・検証を熟知したツールチェーンを統合し、データ収集から学習、検証、デプロイ、モニタリングまでを一貫して管理できる基盤が求められます。次章では、こうした課題に対応する dSPACE と AWS による統合 MLOps ソリューションについて詳しく説明します。 3. ソリューション： dSPACE と AWS による自動運転向け統合 MLOps アーキテクチャ 自動運転 AI 開発における効率化を実現するため、dSPACE と AWS はそれぞれの強みを活かし、AI モデルの学習から SIL/HIL での検証、さらに実運用を見据えた評価・改善までをつなぐ統合 MLOps 環境を共同で提供します。本ソリューションでは、データ駆動開発（DDD）で扱うデータ収集・整備・検証の流れ（左側）と、MLOps で扱う学習・追跡・デプロイの流れ（右側）を接続します。これにより、学習と検証が分断されがちな自動運転 AI 開発において、改善サイクルを一貫したパイプラインとして回すことを目指します。 本アーキテクチャの特徴は、dSPACE 製品と AWS サービスがシームレスに連携できる点にあります。 図1: AWS サービスと dSPACE 製品の統合アーキテクチャ Data Collection：後工程で“使える形”を前提にしたデータ収集 本パイプラインの起点は、走行試験、評価ベンチ、シミュレーションなど多様なソースから得られるデータの収集です。自動運転開発ではデータ量の多さだけでなく、どの条件・どのシナリオで取得されたかが重要となるため、後工程での検索・抽出・学習・検証に耐えうる形で蓄積することが求められます。 この Data Collection フェーズでは、 RTMaps を活用することで、カメラ、Radar、LiDAR など複数センサのデータをリアルタイムに扱いながら、システム全体としての振る舞いを意識したデータ取得が可能となります。さらに、RTMaps を用いたデータ収集は、後続の検証や SIL/HIL を含むシステム統合試験でも同一の処理構成を再利用できるため、データ取得と検証の分断を抑えたパイプライン設計につながります。こうして収集されたデータは、次の Data Preparation フェーズにおいて IVS に引き渡され、タグ付けや検索、データセット化といった処理へとスムーズに接続されます。 Data Preparation：IVS によるデータマネジメントとデータセット管理 収集したデータは、学習にそのまま利用できるとは限りません。Data Preparation フェーズでは、 dSPACE IVS (Intempora Validation Suite) を用いて、データの自動タグ付け、検索、変換を行い、学習に適したデータセットとして整理します。 重要なのは、単にデータを整えるだけでなく、どの条件で抽出・加工されたデータセットなのかを後から辿れることです。本パイプラインでは、IVS を介してデータセット定義と証跡（トレーサビリティ）を管理し、以降の学習・検証フェーズと一貫して結び付けます。 Training：AWS を活用した学習の自動化と実験・モデル管理 整備されたデータセットは、AWS のクラウドサービスへシームレスに受け渡され、大規模な学習処理が実行されます。本構成では、 Amazon SageMaker AI を中心とした学習基盤を活用し、必要な計算リソースを柔軟に利用することで、効率的なモデル学習を実現します。 SageMaker Training Jobs は、学習ジョブごとに GPU インスタンスを自動的にプロビジョニングするため、高価な GPU リソースを学習実行時のみ使用でき、コスト効率に優れています。また、学習コードをコンテナイメージとして Amazon ECR に格納し、学習データを Amazon S3 に配置するアーキテクチャにより、「コード・データ・環境」の三要素が分離され、実験の再現性が担保されます。さらに、実験管理には SageMaker AI のマネージド MLflow を用い、学習条件、評価指標、生成されたモデルを一元的に管理します。これにより、モデルの品質担保に必要な履歴情報を体系的に蓄積し、後工程の検証や将来の説明責任に対応します。 Validation / System Integration & Testing（SIL/HIL）：学習成果を車両開発レベルで検証し、信頼性を高める 学習によって得られた AI モデルは、SIL や HIL を活用して、自動運転システムとしての機能検証や統合試験へと進みます。 dSPACE の SIL/HIL ソリューション は、制御ソフトウェアや AI モデルを実車に近い条件で段階的に評価できる点が特長です。SIL では、アルゴリズムやソフトウェアの論理的な正しさや機能挙動を早期に確認でき、モデル更新による影響を効率的に洗い出すことができます。さらに HIL では、実際の ECU (Electronic Control Unit) として AI モデルを接続することで、リアルタイム性やインタフェース、システム全体としての振る舞いを含めた検証が可能となります。 検証フェーズで得られた結果は、データ条件やモデル情報とひも付けて管理され、Data Preparation フェーズへフィードバックされます。これにより、SIL/HIL で顕在化した課題を起点に学習データセットを見直し、再学習へつなげるといった、検証起点の改善サイクルを回すことが可能となります。結果として、モデル開発と車両開発・検証を分断することなく、品質向上と開発効率化の両立を支援します。 4. 開発環境「Kiro」を活用した開発効率化 MLOps 開発プロセスをさらに効率化するためには、AWS が提供する開発環境「 Kiro 」を利用することが考えられます。 Kiro は Spec 駆動開発を特徴とし、要件定義・設計・実装タスクを構造化されたドキュメントとして管理しながら、エージェント機能によるコード生成を行うことで、開発者が本質的なアルゴリズム設計に集中できる環境を提供します (図 2 参照)。 図 2: Kiro による MLOps 開発ワークフローの効率化 ここでは、MLOps 開発において Kiro がどのように活用できるか、いくつかの例をご紹介します。 ハイパーパラメータ最適化スクリプトの生成 エージェント機能に最適化要件を伝えることで、2 フェーズアプローチの最適化スクリプトを生成できます。Phase 1 (粗探索) でパラメータ範囲を広く設定し、ランダムに 20 組をサンプリングして並列・短時間で完了させ、Phase 2 (細探索) で Phase 1 の結果を基に最良パラメータ周辺を詳細に探索するといった、重要なパラメータを体系的に調整するスクリプトの生成が可能です。 学習データ品質チェックの自動化 学習データの品質チェックスクリプトの生成にも活用できます。データセット構造チェックでは必要なディレクトリ構成や設定ファイルを検証し、PIL (Python Imaging Library) を使った画像破損チェック、YOLO フォーマットのラベル形式検証、画像-ラベル対応関係チェックにより、不整合を検出します。破損画像や不正確なアノテーションを学習前に自動検出することで、無駄な学習実行を防止できます。 このほか、train.py や Dockerfile などのボイラープレートコード生成、SageMaker ジョブ投入スクリプトの雛形作成など、MLOps 開発における定型的な作業にも Kiro を活用することで、開発者が本質的なアルゴリズム設計に集中でき、開発サイクルの短縮が期待できます。 5. まとめ 本記事では、自動運転 AI 開発における課題と、dSPACE と AWS による統合 MLOps ソリューションをご紹介しました。RTMaps と IVS によるデータ収集・整備から、Amazon SageMaker AI と MLflow を活用した学習・実験管理、さらに SIL/HIL による車両レベルでの検証までを一貫したパイプラインとして接続することで、学習と検証の分断を解消し、検証起点の改善サイクルを回すことが可能となります。加えて、開発環境「Kiro」を活用することで、ハイパーパラメータ最適化やデータ品質チェックといった定型作業を自動化し、エンジニアが本質的なアルゴリズム設計に集中できる環境を実現します。 自動運転 AI 開発の効率化や継続的改善を検討されている方にとって、本記事がソリューション選定の一助となれば幸いです。ご質問やご相談は、dSPACE および AWS の担当者までお気軽にお問い合わせください。 著者について 丹羽 伸二 AWS Japan のシニアソリューションアーキテクトとして自動車業界のお客様を担当。自動車業界で15年以上の経験を持ち、主にプロダクトエンジニアリング領域におけるモダナイゼーションや AI 活用の取り組みを支援しています。 村山 哲也 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループリーダー。データドリブン開発や開発環境のプラットフォーム化などのクラウド系ソリューション、および自動車開発に関わる AI 活用に関するプロトタイピング活動とエンジニアリングをリードしています。 宮本 敬丈 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループ AI チームリーダー。データサイエンティストとして、製造業、自動車領域における AI 活用、MLOps 基盤構築、エンジニアリングプロセスの自動化に従事。AWSを含むクラウドアーキテクチャの構想や生成 AI、RAG、MCP を活用した業務高度化に取り組んでいます。  

大阪開催の経緯 みなさん、こんにちは。AWS アカウントマネージャーの岩上です。 2026年7月2日、AWS 大阪オフィスにて 「Claude , Kiro実践ワークショップ」 を開催しました。参加者35社62名、満足以上の回答率98% という結果を頂きました。 本ワークショップの基本的なプログラム構成や背景については、先行して公開している 麻布台オフィス開催のブログ記事 をご参照ください。本記事では大阪開催の特徴であるOSPホールディングス様のユーザー登壇にフォーカスしてお伝えします。 OSPホールディングス様のユーザー事例登壇 大阪開催では新たな試みとして、ワークショップ参加企業である OSPホールディングス様 に事例登壇いただきました。IT企画課の桒原様が15分間、自社での取り組みと成果を共有してくださいました。 登壇の背景 OSPホールディングス様は、4月にアカウントチームで実施したAIコーディングワークショップをきっかけに、Kiroの全社活用に向けた取り組みを開始されました。わずか 3ヶ月で30名規模の利用体制を構築 されています。 特筆すべきは、IT企画課の桒原様が 自ら社内勉強会を企画・実施し、継続的にアクティブユーザーを増やしていく動き をされている点です。ワークショップをきっかけにお客様自身が推進役となり、組織を動かしていく — まさに理想的な展開です。 登壇内容のハイライト   　生産性向上の実績 (Before→After/効率化倍率) 　・メールアーカイブ作業(514時間→3時間/171倍） 　・会計データの見える化（半年→3日/60倍) 　・受注分析（1週間→3時間/57倍) 　推進のポイント 　・ワークショップ参加（10名）→ 社内勉強会（30名）→ 実務伴走と段階的にスケール 　・ゲーム開発を題材に若手〜ベテランまで楽しく体験 　・4テーマ×計8回の推進リーダーによる伴走支援で実務定着 なぜユーザー登壇が効果的だったのか アンケートでも好評だったように、 実際に推進されたお客様の生の声は説得力が違います。 参加者にとって「自社でもできるかもしれない」という実感につながり、ワークショップ本編のハンズオンに対するモチベーションも高まりました。 OSPホールディングス様は今後、一般業務部門展開 → PoC拡大 → 全社展開へと進んでいかれます。 アプリ発表事例 大阪開催でもハンズオン後に参加者がアプリ発表を行いました。代表的な発表を紹介します。 在宅勤務管理アプリ ：在宅している人が分かりにくいという課題を解決。上司向けにカレンダーや上限チェックのタブを設置 市場・技術動向ニュース配信アプリ ：丸一日かかりそうな調査が5分程度で完了する所感。リンクもクリックして遷移可能 交通費経費精算自動化アプリ ：モバイルICOCAの履歴データをアップロード → 文字読み取り → 精算書PDF保存 マラソン練習メニュー提案アプリ ：レースの種類・目標タイム等を入力するとランニングコースを提案。Google Map連携やシューズDBへの接続まで実装 旅行ルート比較アプリ ：距離やマイルなどかなり正確な結果。指示していないプレミアポイント表示もKiroが自動実装 サカイ引越センター　経営企画部　森田様の旅行ルート比較アプリの発表 大阪開催ならではの工夫 大阪開催ではワークショップ終了後に ピザ懇親会 を実施しました。 Amazonには「2 Pizza Rule（2枚のピザで足りる人数＝6〜8名がチームの理想サイズ）」という考え方があります。小さなチームだからこそ迅速に意思決定でき、オーナーシップを持って動ける — この考え方はAIコーディングツールの社内展開にもそのまま当てはまります。 懇親会ではまさに2枚のピザを囲む規模感のテーブルで、参加者同士が「うちの会社ではこう使い始めた」「こういう課題にぶつかった」という率直な会話を交わしていました。ワークショップ本編では聞けなかった各社の生の悩みや工夫が共有され、 企業の垣根を超えた横のつながりが生まれる場 となりました。 OSPホールディングスの桒原様も「登壇資料を見せてほしい」と声をかけられる場面があり、ユーザー事例登壇と懇親会のセットが参加者間のナレッジシェアを加速させる効果を実感しました。 まとめ 大阪開催では、ユ ーザー事例登壇 という新しい要素を加えることで、単なるツール体験に留まらない 「自社での展開イメージ」 を参加者に提供できました。 OSPホールディングス様のように、ワークショップをきっかけにお客様自身がチャンピオンとなり組織を動かしていく流れは、AIコーディングツールの導入における理想的なモデルです。ツールを配るだけでは組織は変わりません。現場の担当者が「自分ごと」として推進し、成功体験を社内に広げていくことが、継続的な業務変革につながります。 本ワークショップの基本的な設計思想やプログラム構成の詳細については、 麻布台オフィスでの開催記録 をご覧ください。 ワークショップ後の支援 AWS では、ワークショップで「自分でも作れる」と実感いただいた後も、お客様の状況に応じた継続支援をご用意しています。活用方法の共有会、業務課題の深掘り、セキュリティ面の技術説明など、次のステップについては担当のアカウントマネージャーまでお気軽にご相談ください。 本記事公開時点では、当該ワークショップは招待制のイベントとなります。AWS側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください 。 関連リンク Claude Desktop セットアップガイド（Zenn） Kiro IDE セットアップガイド（Zenn）

本記事は 2026 年 7 月 20 日 に公開された「 Connection pooling strategies in Amazon Aurora DSQL 」を翻訳したものです。 本記事では、Aurora DSQL の接続負荷を減らし、1 秒あたり 100 接続のレート制限を超えず、再接続が一斉に集中する thundering herd を避けるための、具体的な 4 つの戦略を解説します。読み終える頃には、大規模でも安定した性能を発揮する接続プールを構成するための、本番運用に使えるチェックリストが手に入ります。 接続プーリングの戦略次第で、 Amazon Aurora DSQL アプリケーションが安定してスケールするか、負荷で破綻するかが決まります。Amazon Aurora DSQL 独自のアーキテクチャは、接続プーリングの効果をさらに大きくします。トランザクション単位の多重化と AWS Identity and Access Management (IAM) による認証により、Aurora DSQL では適切なプーリング戦略が、従来の PostgreSQL の接続管理では実現できない形で性能を高めます。 注: 本記事は、PostgreSQL の接続管理の概念と基本的な IAM 認証を理解していることを前提としています。Amazon Aurora DSQL を初めて使う場合は、これらの戦略を適用する前に、まず Getting Started ガイド から始めてください。 サーバーレス環境での接続プーリング Amazon Aurora DSQL は運用の複雑さを自動的に処理しますが、それでも接続プーリングは欠かせません。新しい接続のたびに、コストの高い TLS ハンドシェイクと認証情報の交換が発生します。プーリングは確立済みの接続を再利用し、この負荷を抑えてレイテンシーを削減します。また、トラフィックが急増すると、1 秒あたり 100 接続 (バースト時 1,000) のレート制限に達することがあり、既存の接続を再利用すればサービスの制限内に安全に収まります。さらに、Amazon Aurora DSQL には接続の最大有効期間があり、クライアントは 1 時間で切断されます。適切に構成したプールはこの制限に達する前に接続をリサイクルし、セッションを透過的に維持します。 トランザクション単位のプーリング: アーキテクチャに組み込み済み Amazon Aurora DSQL はトランザクションプーリングモデルを採用しています。接続を Query Processor に割り当てるのは、セッション全体ではなくトランザクションの実行中だけです。標準的な PostgreSQL では、接続はバックエンドのサーバープロセスと 1:1 のセッション関係を持続的に維持します。一方 Amazon Aurora DSQL はこの対応関係を切り離すため、少数の Query Processor ではるかに多くの接続を処理できます。 この設計は、接続の使用率が低いこと、つまりほとんどの接続が大半の時間アイドル状態であることを前提としています。使用率が低いほど、接続プールに必要な Query Processor は少なくて済みます。そのため、PgBouncer や pgpool-II のようなデータベース側のプロキシは使うべきではありません。トランザクション単位の接続多重化がデフォルトで組み込まれているため、これらのツールはサービスの接続アーキテクチャと重複します。 さらに、一部の PostgreSQL 機能はサポートされていません。SQL レベルの PREPARE/DEALLOCATE ステートメント (ただし拡張クエリプロトコル経由のプリペアドステートメントは正常に動作します)、WITH HOLD カーソル、セッションレベルのアドバイザリーロックです。 Amazon Aurora DSQL の 4 つの接続プーリング戦略 以下の 4 つの戦略は、それぞれ Amazon Aurora DSQL の接続管理の特定の側面に対応します。組み合わせて適用すれば、アプリケーションがサービスの制限内に収まり、負荷がかかっても安定した性能を保てます。新しいアプリケーションを構築する場合は戦略 1 から始め、既存の PostgreSQL アプリケーションを移行する場合はチェックリストとして活用してください。 戦略 1: 公式の AWS コネクタを使う 公式の Amazon Aurora DSQL コネクタ の利用をお勧めします。トークンの生成、有効期間の 80% でのキャッシュ、透過的な更新など、IAM トークンのライフサイクル全体を自動的に処理します。 表 1: プログラミング言語別の推奨接続プールライブラリと主要な設定パラメータ 言語 プーリングライブラリ 主要な設定 Java HikariCP maximumPoolSize Python psycopg ConnectionPool min_size Node.js node-postgres (pg.Pool) max Go pgxpool MaxConns Java (HikariCP) — Spring Boot、Quarkus、Micronaut のアプリケーションでは HikariCP を使います。 HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:postgresql://<cluster-endpoint>:5432/<db>?ssl=true&sslmode=verify-full&sslrootcert=<path>"); config.setMaximumPoolSize(20); config.setMaxLifetime(55 * 60 * 1000); // 55 minutes config.setIdleTimeout(10 * 60 * 1000); // 10 minutes config.setConnectionTimeout(30 * 1000); // 30 seconds config.setKeepaliveTime(5 * 60 * 1000); // 5 minutes HikariDataSource ds = new HikariDataSource(config); Python (psycopg ConnectionPool) — Django、Flask、FastAPI のアプリケーションでは psycopg ConnectionPool を使います。 from psycopg_pool import ConnectionPool pool = ConnectionPool( conninfo="host=<endpoint> dbname=<db> sslmode=verify-full", min_size=2, max_size=20, max_lifetime=55 * 60, # 55 minutes in seconds max_idle=10 * 60, # 10 minutes idle timeout reconnect_timeout=30, # 30 seconds to reconnect ) Node.js (node-postgres) — Express.js、NestJS、サーバーレスの Node.js 関数では node-postgres の Pool を使います。 const { Pool } = require("pg"); const pool = new Pool({ host: "<cluster-endpoint>", database: "<db>", ssl: { rejectUnauthorized: true }, max: 20, idleTimeoutMillis: 10 * 60 * 1000, // 10 minutes connectionTimeoutMillis: 30 * 1000, // 30 seconds }); Go (pgxpool) — Gin、Echo、AWS Lambda Go ランタイムで構築する Go アプリケーションでは pgxpool を使います。 connStr := "host=<cluster-endpoint> dbname=<db> sslmode=verify-full" config, _ := pgxpool.ParseConfig(connStr) config.MaxConns = 20 config.MinConns = 2 config.MaxConnLifetime = 55 * time.Minute // 55 minutes config.MaxConnIdleTime = 10 * time.Minute // 10 minutes idle pool, _ := pgxpool.NewWithConfig(ctx, config) AWS Lambda: プールはハンドラーの外でインスタンス化する AWS Lambda は Aurora DSQL のワークロードでよく使われるコンピューティングサービスです。Lambda の実行モデルには特有のプーリングパターンが必要です。接続プールをモジュールスコープ (ハンドラー関数の外) で作成し、同じ実行環境のウォーム呼び出し間で保持されるようにします。 Lambda が実行環境を再利用すると、モジュールスコープで作成したプールはアクティブなまま残ります。以降の呼び出しでは TLS ハンドシェイクと IAM トークンの交換を完全にスキップできます。コールドスタート時にはプールが一度だけ初期化され、その環境が存続する間は再利用されます。 同時に実行される各 Lambda 呼び出しはそれぞれ独立した実行環境で動くため、プールも個別に持ちます。多数の同時実行にわたって接続を過剰に確保しないよう、プールサイズは小さく (Lambda インスタンスあたり 1〜3 接続) 保ってください。 Lambda の主なガイドライン: プールはハンドラーの外でインスタンス化する。これが最も重要なルールです。 最大プールサイズを 1〜3 に設定する。各 Lambda インスタンスは (バッファ呼び出しを使わない限り) 一度に 1 リクエストしか処理しないため、大きなプールは無駄になります。 アイドルタイムアウトを設定しない。接続は実行環境が存続する間ずっと維持させます。 Lambda 以外のワークロードと同様に、1 時間のハード制限に達しないよう、最大有効期間を 55 分にしてジッターを加える。 コールドスタートのレイテンシーを考慮する。最初の呼び出しでは TLS と IAM 認証の負荷が発生します。以降のウォーム呼び出しではプールされた接続を再利用します。 Python (psycopg ConnectionPool) — Lambda # pool is created ONCE at module scope, reused across warm invocations from psycopg_pool import ConnectionPool import boto3 pool = ConnectionPool( conninfo="host=<cluster-endpoint> dbname=<db> sslmode=verify-full", min_size=1, max_size=2, max_lifetime=55 * 60, # 55 minutes reconnect_timeout=30, ) def handler(event, context): """Lambda handler — pool is already initialized.""" with pool.connection() as conn: result = conn.execute("SELECT * FROM orders WHERE id = %s", [event["order_id"]]) return result.fetchone() Node.js (node-postgres) — Lambda // Pool is created ONCE at module scope, reused across warm invocations const { Pool } = require("pg"); const pool = new Pool({ host: "<cluster-endpoint>", database: "<db>", ssl: { rejectUnauthorized: true }, max: 2, // small pool per Lambda instance idleTimeoutMillis: 0, // don't close idle connections connectionTimeoutMillis: 30 * 1000, // 30 seconds }); exports.handler = async (event) => { // Pool is already warm on subsequent invocations const client = await pool.connect(); try { const result = await client.query("SELECT * FROM orders WHERE id = $1", [event.orderId]); return result.rows[0]; } finally { client.release(); } }; Go (pgxpool) — Lambda package main import ( "context" "time" "github.com/aws/aws-lambda-go/lambda" "github.com/jackc/pgx/v5/pgxpool" ) // Pool created at package scope — initialized once per execution environment var pool *pgxpool.Pool func init() { connStr := "host=<cluster-endpoint> dbname=<db> sslmode=verify-full" config, _ := pgxpool.ParseConfig(connStr) config.MaxConns = 2 config.MinConns = 1 config.MaxConnLifetime = 55 * time.Minute config.MaxConnLifetimeJitter = 5 * time.Minute pool, _ = pgxpool.NewWithConfig(context.Background(), config) } func handler(ctx context.Context, event map[string]string) (string, error) { row := pool.QueryRow(ctx, "SELECT name FROM orders WHERE id = $1", event["order_id"]) var name string err := row.Scan(&name) return name, err } func main() { lambda.Start(handler) } ヒント: Lambda 関数の同時実行数が多い場合 (数百の同時実行)、各実行環境がそれぞれプールを作成します。最大プールサイズ 2 で 500 の Lambda が同時実行されると、Aurora DSQL への接続は最大 1,000 になり得ます。接続の総数を監視し、クラスターあたり 10,000 同時接続のクォータ内に収めてください。 重要: クライアント接続には sslmode=verify-full を設定し、証明書を完全に検証して経路上の攻撃 (on-path attack) を防ぎます。Aurora DSQL は verify-ca や require といった弱いモードでも接続を受け付けますが、これらはサーバーの正当性を検証しません。 安定した接続プールを維持するには、IAM トークンのライフサイクルの理解が重要です。 新しい接続ごとに、新しい IAM 認証トークンを生成します。トークンの生成はローカルでの署名操作で、負荷はごくわずかです。公式の AWS コネクタはこれを自動的に処理します。独自のプールを使う場合は、トークンを手動でキャッシュするのではなく、接続ファクトリの beforeConnect フックで generate-db-connect-auth-token コマンドを呼び出してください。 トークンは、基となる IAM 認証情報より長くは有効になりません。1 時間のセッションでロールを引き受けた場合、 --expires-in の値に関係なく、トークンは最大でも 1 時間で失効します。 データベースロールは最小権限に絞る。 IAM 認証は誰が接続できるかを制御しますが、接続後にそのセッションが何をできるかは制限しません。各アプリケーションのデータベースロールには、必要な最小限の権限だけを付与します。たとえば、読み取り専用のサービスには SELECT を付与し、書き込みアクセスは特定のスキーマやテーブルに限定します。アプリケーションの接続プールで管理者ロールを使うのは避けてください。 手順の詳細は、 Authorizing database roles to use SQL in your database を参照してください。 戦略 2: 最大接続有効期間にジッターを設定して接続の失効を防ぐ Amazon Aurora DSQL には、1 時間という接続の最大有効期間のハード制限があります。接続がこの期間に達すると、アイドル中でもトランザクションの途中でも、サービスはその接続を閉じます。プールはそうなる前に接続をリサイクルする必要があります。 ジッターが重要な理由: プール内のほとんどの接続がほぼ同じタイミング (たとえばアプリケーションの起動時) に作成された場合、それらはほぼ同時に失効します。すると新しい接続リクエストが一斉に集中する「thundering herd」が発生し、1 秒あたり 100 接続のレート制限を超えることがあります。最大有効期間にランダムなジッターを加えると、接続のリサイクルが時間的に分散されます。 // Go (pgxpool) — Use native per-connection jitter config.MaxConnLifetime = 55 * time.Minute config.MaxConnLifetimeJitter = 5 * time.Minute // Each connection independently gets a lifetime between 55-60 minutes // Java (HikariCP): maxLifetime already applies per-connection jitter automatically // Python: use max_lifetime with a randomized offset in your pool factory 期待される結果: 接続のリサイクルが個々の接続にわたって時間的に均等に分散し、新しい接続リクエストが 1 秒あたり 100 のレートクォータを十分に下回った状態を保てます。 戦略 3: プールサイズを最適化する Amazon Aurora DSQL は多数の同時接続でも高い性能を発揮しますが、スループット、レイテンシー、リソース消費のバランスをとれるようにプールサイズを設定する必要があります。 表 3: 接続プールのサイズ設定パラメータの推奨初期値 パラメータ 推奨初期値 理由 最小プールサイズ 2〜5 接続 低負荷時にリソースを無駄にせず、プールをウォームに保つ 最大プールサイズ アプリケーションインスタンスあたり 10〜20 控えめに始める。アプリケーションインスタンスを追加してスケールアウトする 接続タイムアウト 30 秒 トラフィックが多いイベント中に、DSQL の接続バーストキュー (100/秒) を消化できるようにする アイドルタイムアウト 無効 (または MaxConnLifetime に合わせる) アイドル接続にコストはかからない。開いたままにしておけば、再接続時の不要な TLS/認証の負荷を避けられる Amazon CloudWatch で DPU (Distributed Processing Unit) の消費を監視し、容量の追加が必要なタイミングを把握します。トラフィックの急増が予想される場合 (スケジュールされたバッチジョブやマーケティングキャンペーンなど) は、事前にプールをウォームアップしておきます。インスタンスあたりの接続数を増やすのではなく、小さめのプールを持つアプリケーションインスタンスを増やして水平方向にスケールアウトします。Amazon Aurora DSQL は、短期的な負荷増加には垂直スケーリングで、長期的な変動にはフリート全体の水平スケーリングで対応します。クラスターあたり 10,000 同時接続のクォータを活用し、必要であれば AWS Support に連絡して上限を引き上げてください。 期待される結果: ワークロードに合わせてプールが適切にサイズ設定され、接続の負荷とプール枯渇エラーの両方を最小限に抑えられます。 戦略 4: マルチリージョンでのプーリングの考慮事項 Amazon Aurora DSQL のマルチリージョン active-active デプロイを使うグローバル分散アプリケーションでは、接続プーリングにもう一段の検討が必要です。 このサービスのマルチリージョンアーキテクチャでは、SQL の実行、読み取り、書き込みのスプーリングをクライアントのリージョン内でローカルに処理します。リージョン間の通信は、コミット時に Adjudicator と Journal のレプリケーションプロトコルを通じてのみ発生します。マルチリージョンモードでも読み取りはローカルなので、読み取り専用トランザクションはリージョン間のレイテンシーなしで完了します。読み書きトランザクションでリージョン間レイテンシーが発生するのは COMMIT 時のみで、実行した SQL ステートメントの数に関係なく、リージョン間のラウンドトリップ約 1〜1.5 回分です。各ステートメントごとにラウンドトリップが発生する転送ベースの設計と比べ、レイテンシーを削減できます。リージョンの選択も重要です。接続性の良いリージョンの組み合わせほどコミットレイテンシーが低く、地理的に離れた組み合わせほどそれに比例して大きくなります。 マルチリージョンでのプーリングでは、リージョンごとに個別の接続プールを作成し、それぞれローカルの Amazon Aurora DSQL エンドポイントを指すようにします。トークン更新のロジックがリージョンごとの IAM エンドポイントを考慮していることを確認してください。アプリケーションは active-active アクセスを前提に設計します。このサービスにはプライマリリージョンという概念がなく、各リージョンは対称的に動作します。 期待される結果: リージョン間レイテンシーはコミット時にのみ発生し、読み取りはローカルリージョンの速度で完了します。 オブザーバビリティ: データベースだけでなく接続プールも監視する Aurora DSQL の CloudWatch メトリクス (TotalTransactions や CommitLatency など) はデータベースレベルの挙動を示しますが、接続プールがボトルネックかどうかまではわかりません。プールの健全性を把握するには、アプリケーション側に計測を組み込む必要があります。次に挙げるクライアント側のメトリクスが、接続プーリングの問題を捉える重要なシグナルです。 アプリケーションに組み込むべきメトリクス メトリクス 示す内容 アラートのしきい値 発生時のアクション プール取得レイテンシー (.get() の所要時間) プールから接続を取得するまでアプリケーションが待つ時間 P95 > 500 ms プールが飽和している。最大プールサイズを増やすか、アプリケーションインスタンスをスケールアウトする アクティブ接続数 現在トランザクションを実行中の接続数 最大プールサイズに張り付いている すべての接続が使用中。プールサイズを増やすか、トランザクションの実行時間を短くする アイドル接続数 プール内で使われていない接続の数 0 のまま張り付いている トラフィックのバーストに対する余裕がない。最小プールサイズを増やすか、急増が予想される前にウォームアップする リクエストの同時実行数 対 プールサイズ 処理中の同時リクエスト数と最大プールサイズの比率 同時実行数が最大プールサイズの 80% を超える プール枯渇に近づいている。スケールアウトするか、プールサイズを増やす プール枯渇イベント 利用可能な接続を待って接続リクエストがタイムアウトした回数 > 0 直ちに対応が必要。プールサイズを増やす、トランザクションの実行時間を短くする、またはアプリケーションインスタンスを追加する 接続作成レート プールが 1 秒あたりに開く新規接続の数 100/秒 に近づく Aurora DSQL のレート制限に達するリスクがある。ジッターを加える、インスタンスの起動をずらす、または最小プールサイズを増やして接続の入れ替わりを減らす ほとんどの接続プールライブラリは、これらの統計をネイティブに公開しています。 Java (HikariCP): HikariPoolMXBean を使って getActiveConnections() 、 getIdleConnections() 、 getThreadsAwaitingConnection() 、 getTotalConnections() にアクセスします。Micrometer 経由で CloudWatch やアプリケーションパフォーマンスモニタリング (APM) ツールにエクスポートします。 Python (psycopg ConnectionPool): pool.get_stats() を使います。 pool_min 、 pool_max 、 pool_size 、 pool_available 、 requests_waiting 、 requests_num を返します。 Node.js (node-postgres): pool.totalCount 、 pool.idleCount 、 pool.waitingCount に直接アクセスします。一定間隔で、またはリクエストごとに出力します。 Go (pgxpool): pool.Stat() を使います。 AcquireCount() 、 AcquiredConns() 、 IdleConns() 、 TotalConns() 、 AcquireDuration() を提供します。 これらはカスタム CloudWatch メトリクスとして発行するか ( PutMetricData API またはログ内の CloudWatch Embedded Metric Format を使用)、既存の APM ツール (AWS X-Ray、Datadog、Prometheus/Grafana など) に送信します。 補足: Aurora DSQL の CloudWatch メトリクス 主要なシグナルはクライアント側のメトリクスであるべきですが、プールサイズを決めるうえで役立つ Aurora DSQL のメトリクスが 1 つあります。 メトリクス プーリングに役立つ理由 TotalTransactions プール取得レイテンシーと関連付けて見ます。トランザクションが増えているのに取得レイテンシーが横ばいなら、プールサイズは適切です。両方が増えているなら、容量の追加が必要です。 よくある接続プールの問題のトラブルシューティング アラートが発生したら、この表を使って最もよくある障害シナリオを診断し、対処してください。 表 5: よくある Amazon Aurora DSQL 接続プール問題のトラブルシューティングガイド 症状 考えられる原因 診断ステップ 対処 プール枯渇 (接続タイムアウトエラー) トラフィックに対して maxPoolSize が低すぎる アクティブ接続とアイドル接続を比較して監視する 最大プールサイズを増やすか、アプリケーションインスタンスを追加する 約 55 分後の認証失敗 トークンの失効が処理されていない トークン更新のログを確認する 公式コネクタを使っているか確認する。MaxConnLifetime の設定を確認する 新規接続レートのエラー 起動時の thundering herd 接続作成のタイムスタンプを確認する MaxConnLifetime にジッターを加える。アプリケーションインスタンスの起動をずらす クイックリファレンス: 主要な制限と設定 接続の有効期間、トランザクションタイムアウト、接続レート、同時実行数などの最新の制限については、 Cluster quotas and database limits を参照してください。 まとめ 本記事では、Amazon Aurora DSQL のトランザクション単位のプーリングモデルが従来の PostgreSQL とどう違うかを解説しました。また、コネクタの選択からマルチリージョンでのプーリングまで、アプリケーションの性能と回復力を保つための具体的な 4 つの戦略も紹介しました。PgBouncer や pgpool-II のようなデータベース側のプロキシは使わないでください。このサービスはトランザクション単位の多重化をネイティブに処理します。マルチリージョンのデプロイでは、リージョン間レイテンシーがコミット時にのみ発生することを覚えておいてください。トランザクションはローカルの読み書きを活かせるように設計しましょう。 これらの戦略に従えば、アプリケーションは Amazon Aurora DSQL の自動スケーリング、強整合性、高可用性を最大限に活用できます。接続の負荷を最小限に抑え、大規模でもレイテンシーを予測可能に保てます。 著者について Tejas Dubey Tejas は、 Tejas は AWS のテクニカルアカウントマネージャーで、エンタープライズのお客様が回復力とセキュリティに優れ、AI 対応のクラウドアーキテクチャを構築できるよう支援しています。新しいテクノロジーを実際のビジネス価値に変えることに情熱を注いでいます。仕事を離れているときは、息子を追いかけたり、ピックルボールをしたり、最新のテクノロジーをいじったりしています。 Dhvani Shah Dhvani は、 Dhvani はテクニカルアカウントマネージャーで、クラウドの回復力、セキュリティ、生成 AI の導入に関する戦略的なガイダンスでエンタープライズのお客様を支援しています。デジタルトランスフォーメーションを加速する、スケーラブルで安全なソリューションの設計を支援しています。仕事以外では、旅行やバドミントン、家族と過ごす時間を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Arisa Izuno がレビューしました。

AWS メディア業界向け勉強会 #9（2026 年 7 月 10 日開催） 2026 年 7 月 10 日（金）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。この記事では、カスタムモデルの生成等を通じてリアルタイム翻訳の精度を向上させた事例や、社内の基幹システムをクラウド移行する際の勘所、AI 会話システムの構築、クラウド編集環境の構築、社内ハッカソンにおける Kiro の活用などのメディア業界におけるクラウド活用事例を知ることができます。登壇者の所属部署および肩書きは登壇当時のものとなります。 鳥人間コンテスト Live 配信におけるリアルタイム英語字幕 読売テレビ放送株式会社 クロステック局 放送DXグループ 福岡 一輝 氏 読売テレビ放送株式会社では、毎年夏に琵琶湖で開催される鳥人間コンテストの公式 YouTube ライブ配信において、海外ファンに向けたリアルタイムの英語字幕付与を昨年から実施しています。エンジニア 1 名がわずか 2 か月で AWS 上にフルマネージドサービスを組み合わせた独自システムを構築し運用を開始しています。 リアルタイム字幕生成の流れは、 Amazon Transcribe による文字起こし、生成 AI サービスによる翻訳、番組専用の校正 AI による後処理の 3 段階で構成されています。Amazon Transcribe ではカスタムボキャブラリーやカスタム言語モデルを活用して認識精度を向上させています。校正処理では、 Amazon SageMaker AI を用いてファインチューニングした番組専用モデルを構築し、 Amazon Bedrock にCustom Model Import 機能を用いてカスタムモデルをデプロイしました。これにより、チーム名や専門用語などの固有名詞の補正や、主語の誤変換などを解決しています。独自モデルの構築にあたっては、Amazon SageMaker AI の JumpStart 機能を活用、過去の 10 時間分の配信音声を全て文字起こしし、正解データを手作業で作成するという学習データ整備も行っています。 映像の処理には Amazon Elastic Container Service（Amazon ECS） を採用し、機能ごとにマルチコンテナ設計とすることでリスク分散を図っています。 AWS Fargate の採用により複雑なインフラ管理が不要となり、開発者がアプリケーションロジックに集中できる環境を実現しています。また、字幕と映像のタイミングを一致させるため、映像をバッファリングして音声処理の遅延を吸収する仕組みを実装し、フロントエンドの UI からも微調整が可能な設計としています。YouTube Live への出力には AWS Elemental MediaLive を使用しています。さらに、 AWS SAM による Infrastructure as Code（IaC）でシステム全体を管理しており、環境の再現やアーキテクチャ情報の把握が容易になっています。配信後には海外視聴者からポジティブなコメントが多数寄せられました。 資料のダウンロードは こちら 社内の基幹システムを AWS に移行してわかった勘所と注意点 株式会社毎日放送 デジタルストラテジー局 副部長 田中 淳史 氏 関西テレビ放送株式会社 DX推進局 DX戦略部 主事 石井 克典 氏 読売テレビ放送株式会社 コーポレート局 情報システムグループ 谷 尚大 氏 読売テレビ放送、関西テレビ放送、毎日放送の 3 社は同一の会計パッケージを AWS 上に導入しています。この共通点を活かしてパネルディスカッション形式にて、基幹システムの AWS 移行における勘所と注意点についてお話しいただきました。放送局の基幹システムがクラウドで安定運用できることを 3 社の実例で示していただいた貴重なセッションです。 移行のきっかけについては、長年稼働してきた会計システムのモダナイズに合わせて自然にクラウドを選択した局がある一方、他局の先行事例や構築ベンダーからの推薦が後押しになった局もありました。共通していたのは、クラウドへの移行に対する社内の抵抗感が以前ほど大きくなかったという点です。 構築においては、 AWS Direct Connect の敷設や社内セキュリティ基準の策定など、初めてのクラウド本格利用ならではの苦労もありました。一方で、従来はハードウェアも含めてベンダーに委ねていた領域を自社で理解し運用する体制へと変化したことで、Savings Plans による長期コミット割引やインスタンスの稼働時間調整といったクラウドならではのコスト最適化を主体的に活用できるようになっています。会計システムの稼働後に他のワークロードでも AWS の利用が広がっていることが前向きに語られました。 もう一度やり直すとしたら何を変えるかという問いに対しては、「会計システム単体ではなく将来的なマルチアカウント構成を見据えた全体設計をすべきだった」「関係者間の役割分担を最初に明確にすべきだった」などの声があり、これから移行を検討される方へのアドバイスとして共有されました。 自社のマスコットキャラクターを AI で再現してみた 株式会社CBC Dテック テクニカルセンター プラットフォーム技術部 大石 祐貴 氏 株式会社 CBC Dテックでは、 Amazon Bedrock を用いて CBC テレビの公式マスコットキャラクター「シェアシェア」の AI 会話システムを開発しました。当初は応答速度を重視して Amazon Nova Lite を使用していましたが、回答精度を重視して Amazon Nova Pro に切り替えました。用途に応じて最適な基盤モデルを簡単に切り替えられることが Amazon Bedrock のメリットです。キャラクターの性格や口調はプロンプトエンジニアリングで制御しており、音声合成には外部サービスでオリジナルの音声モデルを作成して使用しています。コーディングエージェントを活用することで、プログラミング経験がほぼない中でもシステムを構築しました。 今年 3 月の自社イベントにて来場者向けに展示し、フリートーク、定型文のポン出し、しりとりなどの機能を提供しました。今後は RAG や Amazon SageMaker AI によるファインチューニングでキャラクターの再現精度を高めることを検討しています。 資料のダウンロードは こちら Amazon AppStream 2.0 を使用したクラウド編集環境の構築 読売テレビ放送株式会社 クロステック局 放送実施グループ 香川 駿貴 氏 読売テレビ放送株式会社では、 Amazon WorkSpaces Applications（旧 Amazon AppStream 2.0） を使用したクラウド編集環境の構築と検証を実施しました。クラウド上に編集環境を構築することで、場所を問わず映像編集が可能になり、物理的な編集機の台数に縛られない柔軟な運用が実現できます。システム構成は、オンプレミスからクラウドストレージに素材を同期し、Amazon WorkSpaces Applications 上で EDIUS を動作させるというものです。3 つのアベイラビリティゾーンにサブネットを作成し、ここに編集機やライセンスサーバーを配置しています。 セッション起動時に証明書とバックグラウンドサービスを再生成するスクリプトを組み込んだマスターイメージを作成することで、当初から動いていた EDIUS 9 に加えて EDIUS 10、EDIUS 11 でも動作に成功しています。使用時間に基づくコストも明確になり、従量課金モデルによる編集環境のコスト可視化という点でも価値のある検証となりました。 資料のダウンロードは こちら Kiro を使ったエンジニアハッカソンをやってみた 株式会社毎日放送 コンテンツ戦略局 プラットフォームビジネス部 村嶋 優吾 氏 株式会社毎日放送では、社内開発人口の増加を目的として、AWS の AI コーディングツール Kiro を使用した 2 日間のエンジニアハッカソンを開催しました。技術職の若手を中心に参加し、全チームが動くプロトタイプのデプロイまで到達しています。成果物の 1 つである新人研修用システムは、現在も開発が継続され実用化を目指しています。Kiro を選定した理由として、社内に AWS の精算フローが確立されており事務コストが低いこと、ターミナル操作や複雑なコマンド入力が少なく参加者層にマッチしていること、そして Kiro の「スペック駆動開発」の設計思想が放送局の技術職の働き方と相性が良いことが挙げられました。スペック駆動開発では仕様を自然言語で言語化してから AI に開発を指示するため、コーディング経験の少ない参加者でも効率的に開発を進めることができます。 運営者としての学びとして 2 つのポイントが共有されました。1 つ目は「仕様の言語化が最短経路」であること。事前にスペックをしっかり定義してから開発を始めたチームは AI の出力精度が高く、開発もスムーズに進みました。従来のハッカソンでは「早く手を動かす」ことが正義でしたが、生成 AI 開発においてはその気持ちを抑えて仕様の言語化に集中することが結果的に最短経路になるという気づきが得られました。2 つ目は「評価の壁」です。生成 AI により実装は容易になった一方で、セキュリティ設定の適切性やテストケースの網羅性など、成果物の品質担保が新たなボトルネックとして浮上しています。実装コストが削減された分、成果物を正しく評価するリテラシーの強化が今後重要になります。 資料のダウンロードは こちら まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。今回の 5 つのセッションでは、リアルタイム字幕生成、基幹システムのクラウド移行、AI キャラクター、クラウド編集環境、AI 開発ハッカソンと、幅広いテーマが取り上げられました。生成 AI と AWS のマネージドサービスを組み合わせることで、限られたリソースの中でも新しい価値を素早く生み出せることが各社の事例を通じて示されています。内容について詳しく知りたい方は、記事上部より資料のダウンロード及び動画を視聴いただけますのでご確認ください。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願いいたします。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 いよいよ 8 月、夏本番ですね。連日の暑さに負けず、今週も生成 AI 界隈のアップデートをキャッチアップしていきましょう。 8 月の builders.flash 記事が出ていますので生成AI関連のものをピックアップしてみます。今月も多くの生成AIに関する記事が出ています。 AWS Summit Japan 2026 Builders’ Fair 人気投票第 1 位「ペン字見ます ! ~ AI Agent 先生の辛口査定 ~」の裏側 ! 少量のレガシー言語プログラムを Amazon Quick で解読してみた Amazon Bedrock AgentCore harness と AWS Step Functions を組み合わせて安全に AI エージェントを構築してみよう ! Kiro、1 歳。コードを書く IDE から、仕事を任せるチームへ どの記事も実践的かつ生成AI活用の観点が異なっており参考になりますね。 また新しい AWS Black Belt オンラインセミナー資料・動画 も続々と出ています。生成 AI 関連では「Amazon Bedrock AgentCore Runtime Dive Deep」と「AWS FinOps Agent (preview)」の資料が公開されています。是非チェックしてみてください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、7 月 27 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「全従業員の行動変容を目指すAstemo が自己破壊を経て見つけたAI駆動開発の実効性」を公開 Astemo 様は、自動車部品・システムを手がけるグローバルメガサプライヤーです。自動車のソフトウェア定義化 (SDV) が進む中、全従業員の行動変容を目指し、44 名・7 チームが実業務テーマで AI 駆動開発ライフサイクル (AI-DLC) を 3 日間体験しました。人間はレビューと意思決定に集中するスタイルで、3 日間で 9 マイクロサービス / 4,500 行超を開発し、開発スピードは約 200% 向上しています。7 チーム全てがデモ可能なプロトタイプを完成させ、あるチームは翌週に本番リリースまで到達しました。 ブログ記事「Outpost VFX が ビジュアルエフェクト向けに AI モデルのトレーニングを AWS で加速した方法」を公開 Outpost VFX 様は、英国、カナダ、インドにスタジオを構える VFX 制作会社です。フェイスリプレースメント用 AI モデルの学習がシングル GPU の制約で 1〜2 週間かかり、制作のボトルネックになっていました。AWS Generative AI Innovation Center と連携し、Amazon EC2 P5 インスタンスでの分散トレーニングへ移行した結果、学習速度は最大 8 倍に向上しています。初回レビュー用の納品期間も 1〜2 週間から 2 日間へ短縮されました。 ブログ記事「【開催報告】AWS Summit Japan 2026 物流業界向けブース展示「スマートグラス×生成AIエージェントで倉庫業務を革新」」を公開 AWS Summit Japan 2026 の物流業界向けブースで展示した、スマートグラスと生成 AI エージェントによる倉庫ピッキング支援デモの解説記事です。「ピッキングリストをください」と話しかけるだけで、Amazon Nova 2 Sonic が音声のまま理解して WMS から作業リストを取得し、QR スキャンで完了記録まで自動化します。1 会話あたり約 8.9 円というコスト試算まで公開されているのが実践的です。 ブログ記事「【開催報告】AWS Summit Japan 2026 〜 流通小売・消費財・飲食業界向けブース」を公開 「AI エージェントが業務の主役になる日」をテーマにした流通小売・消費財・飲食業界向けブースの開催報告です。バーチャル AI エキスパートから Agentic Commerce まで 6 テーマ 7 デモに加え、株式会社ユナイテッドアローズ様と株式会社カインズ様の事例展示も紹介されています。各デモの詳細解説ブログへのリンク集としても便利です。 ブログ記事「AWS Summit Japan 2026：完全自律型 AI Agent が変える SaaS の世界」を公開 AWS Summit Japan 2026 で展示した、Amazon Bedrock AgentCore を活用したマルチテナント AI CRM デモの解説記事です。メールの分類から回答生成、担当者アサインまでを 6 種類の Agent が協働で処理し、人間は承認のみを行うことで、従来 2 時間かかっていた対応が 5 分以内で完了します。「Agent を取り込む SaaS」設計の 4 つのポイントが整理されており、SaaS 事業者の方におすすめです。 ブログ記事「エージェンティック AI と AWS Transform でメインフレームアプリケーションを再構想 (reimagine) する」を公開 メインフレームのレガシーアプリケーションを、エージェンティック AI でクラウドネイティブに作り変える reimagine パターンの解説記事です。AWS Transform for mainframe が COBOL からビジネスロジックを抽出し、Kiro がマイクロサービス仕様とコードを生成する 3 フェーズの方法論を紹介しています。Human in the Loop の検証を挟み、スピードとリスク低減を両立させる考え方が参考になります。 ブログ記事「Amazon GuardDuty 調査エージェントのご紹介: オンデマンドの AI を活用した脅威評価」を公開 Amazon GuardDuty の調査エージェント (パブリックプレビュー) の紹介記事です。AI がセキュリティ検出結果の調査を自動化し、数時間かかっていた調査を数分に短縮します。リスクレベルや MITRE ATT&CK マッピング、推奨アクションが構造化された形で得られ、AWS MCP サーバー経由で AI ワークフローにも統合できます。 ブログ記事「Security Hub が AI ワークロード保護と Microsoft Azure 対応のマルチクラウドサポートを追加」を公開 AWS Security Hub の 2 つの大きな拡張が発表されました。AI ワークロード保護として、異常なモデル呼び出しやコストハーベスティングを検出する GuardDuty AI Protection、調査を自動化する AI-powered investigations、AI 資産を可視化する Security Hub AI inventory が加わります。マルチクラウド対応では、Microsoft Azure の検出結果を AWS と並べて優先順位付けできるようになりました。 ブログ記事「オープンソースサプライチェーン攻撃の背後にいる北朝鮮のハッカーグループを Amazon が特定」を公開 Amazon Threat Intelligence が、axios、debug、chalk、typo-crypto という人気 NPM パッケージの侵害が同一の北朝鮮関連脅威アクターによるものと初めて特定した調査記事です。生成 AI で悪意のあるパッケージの「見た目の不自然さ」が消えつつあることや、スロップスクワッティングといった新たな脅威も解説されています。OSS に依存する全ての開発者に関係する内容です。 サービスアップデート Amazon Bedrock が OpenAI GPT-5.6 モデルの最大 80% 値下げを発表 Amazon Bedrock 上の OpenAI GPT-5.6 のオンデマンド推論価格が値下げされました。高速・低コストの Luna は 80%、バランス型の Terra は 20% の値下げで、設定変更なしで新価格が自動適用されます (Sol は据え置き)。あわせて Kiro でも GPT-5.6 のクレジット倍率が引き下げ られました (Luna 0.6x → 0.1x、Terra 1.2x → 1.0x)。詳細は こちらのドキュメント をご参照ください。 Grok 4.3 が AWS GovCloud (US-West) の Amazon Bedrock で利用可能に xAI の Grok 4.3 が AWS GovCloud (US-West) の Amazon Bedrock で利用可能になりました。GovCloud への xAI モデルの提供は今回が初めてです。推論の深さを 4 段階で設定でき、ツール利用と指示追従、トークン効率に強みがあります。 Gemma 4 モデルが AWS GovCloud (US-West) の Amazon Bedrock で利用可能に Google DeepMind のオープンウェイトモデル Gemma 4 ファミリーが AWS GovCloud (US-West) の Amazon Bedrock で利用可能になりました。256K トークンコンテキストの 31B、コスト重視の MoE 構成 26B-A4B、低遅延の E2B の 3 バリアント構成です。35 以上の言語と、テキスト・画像・動画・音声のマルチモーダル入力に対応します。 Amazon SageMaker Unified Studio が全プロジェクトツールで Git バージョン管理を強化 Amazon SageMaker Unified Studio の全プロジェクトツール (Query Editor、Visual ETL、Workflows、Notebooks) で、ファイルレベルの Git バージョン管理が利用できるようになりました。これまで Git 非対応だった Notebooks も対象になり、ブランチ作成や競合解決までプロジェクト内で完結します。詳細は こちらのドキュメント をご参照ください。 Amazon OpenSearch Service が OpenSearch 3.7 をサポート Amazon OpenSearch Service で OpenSearch 3.7 が利用可能になりました。1-bit スカラー量子化により、検索精度を維持しながらベクトルワークロードのストレージとメモリ使用量を削減できます。RAG の検索基盤のコストとパフォーマンスに効くアップデートです。詳細は こちらのドキュメント をご参照ください。 AWS Security Hub MCP App がプレビュー公開 Security Hub のエクスポージャー検出結果を Claude Desktop から直接扱える、ローカル実行の MCP サーバーがプレビューになりました。自然言語で上位のエクスポージャーを確認し、攻撃パスの掘り下げから修復の推奨事項まで得られます。全ツールが読み取り専用のため、環境に変更が加わる心配なく試せます。詳細は こちらのドキュメント をご参照ください。 Kiro CLI 2.16.0 / 2.15.0 と IDE 1.0.242 が公開 Kiro CLI 2.16.0 では、会話履歴を引き継いだままサイド会話に分岐できる /tangent コマンドと、/context のツール別トークン内訳表示が追加されました。CLI 2.15.0 では /spec new のガイド付きステップと、Plan モードでの承認後の自動実行が入っています。IDE 1.0.242 では、右クリックメニューの Kiro サブメニューや、エラーに対する「Ask Kiro to Fix」クイックフィックスが加わりました。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 はじめに、7月28日に熊本県で発生した地震(令和8年熊本地震)により被害に遭われた皆様に、心よりお見舞い申し上げます。被災された皆様の安全と、一日も早い復旧を心よりお祈りしております。 話題は変わりますが、AWS 認定をこれから取得したい方、あるいはスキルアップを考えている方に向けたキャンペーンのご案内です。現在、 AWS 認定 AI スキルアップキャンペーン が実施されており、AWS Certified AI Practitioner (AIF-C01) を 2026 年 9 月 30 日までに受験すると試験料が 50% 割引になります。さらに合格すると、AWS Certified Cloud Practitioner (CLF-C02) を無料で受験できます。この夏、AI 分野の認定取得にチャレンジしてみるのはいかがでしょうか。 それでは、先週の主なアップデートについて振り返っていきましょう！ 2026年7月27日週の主要なアップデート 7/27(月) Amazon RDS for SQL Server が Multi-AZ インスタンスでの TDE データベース復元に対応 Amazon RDS for SQL Server で、TDE (Transparent Data Encryption) を有効にした SQL Server データベースを Multi-AZ インスタンスおよび同一リージョン内のリードレプリカを構成したインスタンスに復元できるようになりました。ネイティブバックアップ・リストア機能を使用します。従来は Single-AZ インスタンスでのみ TDE 有効データベースの復元が可能で、暗号化データを復元するには TDE を無効化するか Single-AZ 構成への移行が必要でした。今回の対応により、保存時暗号化 (TDE) と Multi-AZ の高可用性の両方を必要とする移行・復旧のワークフローを簡素化できます。この機能は Amazon RDS for SQL Server が提供されるすべての AWS リージョンで利用できます。 AWS Security Hub MCP App で、エクスポージャー検出結果を自然言語で調査可能に (プレビュー) AWS Security Hub MCP App のパブリックプレビューが開始されました。これは Claude Desktop 内で動作するローカルの Model Context Protocol (MCP) サーバーで、Security Hub のエクスポージャー検出結果について、攻撃パスの深掘りや修復方法の提案などを自然言語で調査できます。すべてのツールは読み取り専用 (read-only) で、環境に変更を加えずに利用できます。Security Hub の利用者は追加費用なしで使うことができます。 Amazon EKS がクラスター OIDC エンドポイント向けの AWS PrivateLink に対応 Amazon EKS が、クラスターの OIDC ディスカバリおよび JWKS エンドポイント向けの AWS PrivateLink に対応しました。インターフェイス型 VPC エンドポイント (サービス名 `com.amazonaws.[リージョン名].oidc-eks`) を作成することで、VPC 内の eksctl や Terraform、独自のトークン検証ツールが、IAM roles for service accounts (IRSA) のセットアップやトークン検証を、インターネットに出ることなく閉域 VPC 内で実行できるようになりました。追加料金はなく、標準の AWS PrivateLink 料金のみが適用されます。 7/28(火) Amazon S3 Tables が Apache Iceberg V3 の Variant データ型に対応 Amazon S3 Tables が Apache Iceberg V3 仕様の Variant データ型に対応しました。JSON などの半構造化データを事前にスキーマを固定せずに直接書き込めます。書き込み時に Iceberg V3 対応エンジンが Variant データを隠しカラムに分解 (shredding) し、Parquet のカラム統計を生成します。クエリエンジンはこの統計を使ってファイルプルーニングを行い、分析クエリがスキャンするデータ量を減らします。S3 Tables は Variant カラムに対してもコンパクションを含むテーブルメンテナンスを継続実行します。東京を含む、15 の AWS リージョンで利用できます。 AWS DataSync Enhanced mode が HDFS、Azure Blob、オブジェクトストレージのロケーションと Hyper-V エージェントに対応 AWS DataSync の Enhanced mode が、エージェント経由での HDFS (Hadoop Distributed File System)、Microsoft Azure Blob Storage、および自己管理型オブジェクトストレージへの転送に対応しました。あわせて Enhanced mode のエージェントを Microsoft Hyper-V 上に展開できるようになりました。HDFS 転送では複数 NameNode 構成 (High Availability) と Kerberos 認証を用いた TDE (Transparent Data Encryption) に対応します。これにより規制業界の組織が、可用性を維持したままペタバイト級の暗号化 Hadoop データを移行できます。この機能は DataSync が提供されているすべての AWS リージョンで利用できます。 AWS DataSync Enhanced mode が Amazon EFS および Amazon FSx for Lustre をサポート AWS DataSync の Enhanced mode が、転送元・転送先として Amazon EFS と Amazon FSx for Lustre に対応しました。従来これらのストレージへの転送は Basic mode に限定されていましたが、今回のアップデートで Enhanced mode を選択できるようになりました。Enhanced mode はデータを並列に処理し、ファイル数の上限がなく、詳細な転送メトリクスを提供します。大規模なデータ移行や AI/ML の学習データ準備、HPC、ゲノム解析、メディアレンダリングといったワークロードで利用できます。AWS DataSync が提供されているすべての AWS リージョンで利用可能です。 7/29(水) IAM Identity Center が Identity Center ディレクトリのマルチリージョン対応を拡張 AWS IAM Identity Center が、ID ソースとして Identity Center ディレクトリを使用する組織インスタンスでもマルチリージョンレプリケーションに対応しました。これまで外部 IdP 接続のインスタンスに限られていた機能が拡張されています。プライマリリージョンで有効化したインスタンスを、デフォルトで有効化されている 17 の商用リージョンから選んだリージョンへ複製できます。ユーザー ID、権限セット、割り当て、セッションなどが自動でレプリケートされ、プライマリリージョンで障害が発生してもプロビジョニング済みのアクセスを維持できます。利用にはマルチリージョン対応の customer managed KMS key (CMK) が必要です。 AWS Interconnect – multicloud (Oracle Cloud Infrastructure 対応) が一般提供を開始 AWS は AWS Interconnect – multicloud の Oracle Cloud Infrastructure (OCI) 対応を一般提供 (GA) しました。この機能を使うと、AWS の VPC と OCI の VCN (Virtual Cloud Network) の間に、専用帯域を持つプライベート接続を短時間で作成できます。従来は複数クラウド間の相互接続を自前で構築する必要がありましたが、その運用負荷を AWS と接続先プロバイダーが肩代わりします。GA 時点では OCI と Google Cloud に対応し、米国東部 (バージニア北部) リージョンで利用できます。Microsoft Azure は 2026 年後半に対応予定です。 AWS Glue の REST API コネクタが VPC 接続、フィルタプッシュダウン、パーティションに対応 AWS Glue の REST API コネクタに 3 つの機能が追加されました。プライベートサブネットや VPN、AWS PrivateLink 経由の非公開 REST API に接続できる VPC 対応、クエリ条件を API ネイティブのパラメータに変換して転送量を減らすフィルタプッシュダウン、大規模データを複数の Spark ワーカーに分割して並列読み取りするパーティション対応です。これにより REST API を持つ任意のデータソースから、カスタムコードを書かずに ETL パイプラインを構築できます。 7/30(木) AWS Managed Microsoft AD が Standard から Enterprise Edition へのアップグレードに対応 AWS Directory Service は、AWS Managed Microsoft AD の Standard Edition ディレクトリを Enterprise Edition へ直接アップグレードする機能に対応しました。AWS Management Console、AWS CLI、API、AWS Tools for PowerShell から実行でき、新しいディレクトリへの移行や既存ワークロードのドメイン再参加は不要です。信頼関係、アプリケーション統合、グループポリシー、DNS 設定はそのまま維持されます。所要時間は 4 時間から 5 時間で、ドメインコントローラー (DC) を 1 台ずつ入れ替えるため、その間は性能低下とダウンタイムが発生する可能性があります。アップグレードは不可逆であり、以前のスナップショットはアップグレード後のディレクトリには使用できません。アップグレードには追加料金が発生するため、詳細は Directory Service の料金ページをご確認ください。 AWS Transit Gateway のポリシーベースルーティングが一般提供開始 AWS Transit Gateway (TGW) でポリシーベースルーティング (PBR) の一般提供が開始されました。従来の宛先 IP アドレスのみによる転送判断に加えて、送信元 IP、宛先 IP、送信元ポート、宛先ポート、プロトコルの組み合わせでトラフィックを分類し、転送先の TGW ルートテーブルを選択できます。設定はポリシーテーブルという新しいリソースで行い、アタッチメントに関連付けます。ルールは番号の昇順に評価され、最初に一致したルールが適用されます (first-match-wins)。TGW が提供されているすべての商用リージョンで利用でき、標準の TGW 料金を超える追加課金はありません。ただしポリシーテーブルを関連付けたアタッチメントでは Site-to-Site VPN と Connect への BGP 経路広報が停止するため、導入前に影響確認が必要です。 Amazon SageMaker Unified Studio が全プロジェクトツールで Git バージョン管理を拡充 Amazon SageMaker Unified Studio のリポジトリ機能が更新され、Query Editor、Visual ETL、Workflows、Notebooks の 4 ツールでファイル単位の Git バージョン管理に対応しました。従来の自動同期 (保存ごとにリモートへ force push する方式) を置き換え、コミットメッセージ付きの push とブランチ操作ができるようになりました。これまで Git 非対応だった Notebooks も対象に含まれます。リポジトリはプロジェクト作成時ではなく任意のタイミングで追加でき、1 つのプロジェクトから複数のリポジトリとブランチへ同時に接続できます。既存プロジェクトへの適用はオプトインで、プロジェクトの更新を実行して切り替えます。 7/31(金) Amazon CloudWatch がマネージド Prometheus コレクターを発表 Amazon CloudWatch が、エージェントを配置せずに Prometheus 互換メトリクスを収集するマネージドコレクターに対応しました。従来は自己管理の OpenTelemetry Collector を配置、スケール、保守する必要がありましたが、スクレイプ設定とサブネット、セキュリティグループを指定すれば AWS 側がプロビジョニングとスケーリングを行います。対応対象は Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、Amazon OpenSearch Service です。収集したメトリクスは OpenTelemetry 形式で CloudWatch のデータセットに配信され、PromQL でクエリできます。AWS ベンダーメトリクスと同じ画面でアラームとダッシュボードを構成できます。 Amazon RDS for Oracle が R8i および M8i インスタンスのリザーブドインスタンスを提供開始 Amazon RDS for Oracle で、R8i および M8i インスタンスに対する 1 年および 3 年のリザーブドインスタンス (RI) を購入できるようになりました。オンデマンド価格と比較して最大 53% のコスト削減となります。RI の割引は Multi-AZ 構成と Single-AZ 構成の双方に適用され、同一インスタンスクラスタイプ内であれば構成を変更できます。BYOL ライセンスモデルではサイズ柔軟性が働き、同一インスタンスファミリー内のどのサイズの使用量にも割引レートが自動適用されます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

本ブログは 2026 年 7 月 30 日に公開された AWS Blog “ Extend Amazon Inspector SBOM Generator with Plugins ” を翻訳したものです。 Amazon Inspector は、 Amazon Web Services (AWS) のワークロードを継続的にスキャンしてソフトウェアの脆弱性を検出する、自動化された脆弱性管理サービスです。Amazon Inspector の脆弱性管理機能は、 Amazon Inspector SBOM Generator (inspector-sbomgen) と呼ばれる資産インベントリエンジンによって支えられています。これはスタンドアロンのコマンドラインツールで、コンテナイメージ、ディレクトリ、アーカイブ、ローカルシステム、コンパイル済みバイナリなどから ソフトウェア部品表 (SBOM) を生成します。過去 2 年間で、AWS は inspector-sbomgen のカバレッジを数十のプログラミング言語エコシステム、オペレーティングシステム、広く導入されているアプリケーションへと拡大してきました。 今回、inspector-sbomgen を利用するビルダー向けの新機能として、独自のカスタムパッケージコレクターを記述できる プラグインシステム を発表します。ソースコードのコンパイルや公式リリースを待つ必要はなく、すぐに使い始めることができます。 inspector-sbomgen の最新バージョンは、 Amazon Inspector ユーザーガイド からダウンロードできます。 この記事では、inspector-sbomgen プラグインシステムでできること、これを構築した理由、そして数分で最初のプラグインを書く方法を紹介します。あわせて、プラグインが生成したパッケージコンポーネントを Amazon Inspector の脆弱性スキャンと統合する方法や、セキュリティが強化された予測可能なプラグイン動作を実現するプラグインの安全性モデルについても解説します。 プラグインシステムを構築した理由 ソフトウェアのエコシステムは動的です。新しい言語パッケージマネージャー、ロックファイル形式、エンドユーザーアプリケーションが絶えずリリースされ、その多くは迅速に採用されます。中にはセキュリティの検証がほとんど行われないまま使われるものもあります。その結果、セキュリティチームには可視性のギャップが残ります。つまり、SBOM ツールがまだ認識できないソフトウェアが本番ワークロードで動いているという状態です。お客様からは、こうしたエコシステムの多くを直接インベントリ化したいという要望をいただいてきました。最近まで、それを実現する唯一の方法は、機能リクエストを出して inspector-sbomgen チームがエコシステムに対応し、新しいリリースをデプロイするのを待つことでした。 inspector-sbomgen プラグインシステムは、この状況を変えます。プラグインを使うと、次のことができます。 inspector-sbomgen が標準では対応していないエコシステムへの対応 – 新しいオープンソースエコシステム、ニッチまたは変化の速いパッケージ形式、組織独自のツールなど、inspector-sbomgen を変更することなくインベントリ化できます エコシステム検出の迅速なプロトタイピング – 開発者にも AI コーディングアシスタントにも扱いやすいプラグインシステムを設計しました。プラグインは Lua で記述され、実行時にロードされるため、Go ツールチェーンもコンパイルも不要です。組み込みのテストハーネスを使ってプラグインを繰り返し改善し、すぐに結果を確認できます 安定した基盤の上での構築 – プラグイン API はアーティファクトの種類による違いを抽象化するため、検出ロジックを一度書くだけで、コンテナイメージ、アーカイブ、ローカルシステムなどでシームレスに動作します。また、プラグインは sbomgen の内部構造から分離されているため、コアツールでリグレッションが発生した場合の影響範囲も小さく抑えられます 実際、私たち自身もこのプラグインシステムを内部で活用し、新しいエコシステムのカバレッジを以前より速く提供できるようになりました。 1.13 リリース では、Apache Tomcat、NGINX、MySQL、Redis、WordPress、OpenSSH ツールチェーンなど、これまで Go で実装されていた 20 以上のエコシステムが、プラグインとして sbomgen バイナリに組み込まれています。同じリリースでは、Apache Cassandra、Apache Struts、Conda、Swift パッケージ、AI エージェントコレクター (Amazon Q Developer、Kiro CLI、Claude Code、GitHub Copilot、Ollama) など、10 を超える新しいエコシステムもプラグインとして追加されました。 inspector-sbomgen プラグインの仕組み sbomgen プラグインは 2 段階のパイプラインで動作します。 検出 (discovery) – アーティファクトのファイルシステムをスキャンし、インストール済みパッケージのメタデータを含むファイルを特定します 収集 (collection) – 検出された各ファイルを開き、ファイルの内容を解析して、結果を SBOM にパブリッシュします 内部では、イベントバスが検出プラグインと収集プラグインをつないでいます。検出プラグインは検出したファイルの一覧をイベントとしてパブリッシュし、1 つ以上の収集プラグインがそのイベントをサブスクライブして、パッケージ収集をトリガーします。開発者にとっては、これは オブザーバーパターン としておなじみの動作でしょう。 この分離により、1 つの検出プラグインが複数のコレクターにデータを供給できます。例えば、あるコレクターはパッケージメタデータを抽出し、別のコレクターはシークレットをスキャンし、さらに別のコレクターはポリシーをチェックする、といった構成が可能です。各収集プラグインは、計算コストの高いアーティファクトファイルシステムの再走査を行うことなく、同じファイルリストを利用できます。 5 分で書ける最初のプラグイン inspector-sbomgen を使えば、プラグイン環境を簡単にセットアップできます。 plugin new コマンドで sbomgen に新しいプラグインワークスペースを作成させ、 --with-example フラグを指定すると、すぐに実行できる検出プラグインと収集プラグインのペアがワークスペースに用意されます。 inspector-sbomgen plugin new --with-example 上記のコマンドを実行すると、プラグイン名と、プラグインワークスペースを格納するディレクトリの入力を求められます。カスタム値を指定することも、デフォルト値をそのまま使うこともできます。 Plugin name (identifies the software ecosystem your plugin will inventory, e.g. debian-dpkg, rhel-rpm, python-pip, cmake) [my-custom-ecosystem]: <enter> Project directory [my-sbomgen-plugins]: <enter> Created plugin "my-custom-ecosystem" in my-sbomgen-plugins/ なお、対応するコマンドラインインターフェイス (CLI) 引数でプラグイン名とディレクトリを指定すれば、対話形式のプロンプトをスキップできます。 inspector-sbomgen plugin new \ --with-example \ --name my-custom-ecosystem \ --path my-sbomgen-plugins プラグインワークスペースを作成すると、inspector-sbomgen は次のステップを案内する画面を表示します。開発者や AI コーディングアシスタントに対して、変更が必要なソースファイルや関連ドキュメントの場所を示してくれます。 Next steps: Get started: 1. Open plugin folder in a code editor (VS Code recommended) 2. Add test files that your plugin will discover and parse (e.g., config files, lockfiles, binaries, etc.): my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/ Develop: 3. Edit discovery: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua 4. Edit collection: my-sbomgen-plugins/collection/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua Test: 5. Write unit tests: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init_test.lua 6. Run unit tests: inspector-sbomgen plugin test --path my-sbomgen-plugins Deploy: 7. Distribute your plugin directory wherever you run inspector-sbomgen: inspector-sbomgen <arguments> --plugin-dir /path/to/my-sbomgen-plugins Example: inspector-sbomgen container --image alpine:latest -o /tmp/sbom.json --plugin-dir /path/to/my-sbomgen-plugins For code completion, install the VS Code Lua language server extension: https://luals.github.io/#vscode-install For more information: - Plugin guide: my-sbomgen-plugins/docs/sbomgen-plugin-developer-guide.md - Testing guide: my-sbomgen-plugins/docs/sbomgen-plugin-testing-guide.md - API reference: my-sbomgen-plugins/docs/sbomgen-plugin-api-reference.md - Documentation: https://docs.aws.amazon.com/inspector/latest/user/sbom-generator.html プラグインワークスペースができたので、その中身を詳しく見てみましょう。 tree my-sbomgen-plugins ├── AGENTS.md ├── collection │   └── cross-platform │   └── extra-ecosystems │   └── my-custom-ecosystem │   └── init.lua ├── discovery │   └── cross-platform │   └── extra-ecosystems │   └── my-custom-ecosystem │   ├── _testdata │   │   ├── empty │   │   └── example.lock │   ├── init_test.lua │   └── init.lua ├── docs │   ├── sbomgen-plugin-api-reference.md │   ├── sbomgen-plugin-developer-guide.md │   └── sbomgen-plugin-testing-guide.md ├── library │   └── sbomgen.lua └── README.md スキャフォールディングされたプロジェクトには、動作する検出プラグインと収集プラグインのペア、 _testdata/ 配下のテストフィクスチャを使ってパスするユニットテスト、統合開発環境 (IDE) 連携用の .vscode/settings.json 、開発者ドキュメントのローカルコピーが含まれています。 スキャフォールディングは、人間と AI コーディングアシスタントの両方が読みやすいように、意図的に簡潔で完結した内容になっています。各ファイルには、それぞれの関数の役割と、プラグイン作成者が記述すべき箇所を説明する明確なコメントが付いています。 プラグインをテストするには、まずパッケージロックファイルやコンパイル済みバイナリなど、スキャン対象となるものが必要です。サンプルプラグインは、次の内容を持つ架空の example.lock をインベントリ化します。 my-package-alpha==1.0.0 my-package-beta==2.3.1 my-package-gamma==0.9.5 付属の検出プラグインは、アーティファクトのファイルシステム内で example.lock のインスタンスを探す方法を知っています。 -- my-custom-ecosystem discovery plugin -- Discovers example.lock files in the artifact file list. function discover() return sbomgen.find_files_by_name({"example.lock"}) end そして、付属の収集プラグインは、 example.lock の内容を解析し、パッケージ情報を出力 SBOM にパブリッシュする方法を知っています。 -- my-custom-ecosystem collection plugin -- Parses example.lock files and extracts package name and version. function collect(file_path) local content = sbomgen.read_file(file_path) if content == nil then return end for line in content:gmatch("[^\n]+") do local name, ver = line:match("^(.+)==(.+)$") if name and ver then sbomgen.push_package({ name = name, version = ver, purl_type = "generic", namespace = "my-custom-ecosystem", component_type = sbomgen.component_types.APPLICATION, }) end end end テストの実行 プラグインにはテストフレームワークが組み込まれているため、実際のアーティファクトをスキャンする前にロジックを検証できます。テストは Lua で記述し、プラグインと同じ場所の init_test.lua に配置して、 _testdata/ 内のフィクスチャデータを参照します。 function test_discovers_packages() local result = testing.scan_directory("_testdata") testing.assert_equals(3, #result.findings) testing.assert_equals("my-package-alpha", result.findings[1].name) testing.assert_equals("1.0.0", result.findings[1].version) end function test_no_findings_for_empty_directory() local result = testing.scan_directory("_testdata/empty") testing.assert_equals(0, #result.findings) end 次のコマンドでテストを実行します。 inspector-sbomgen plugin test --path my-sbomgen-plugins -v === RUN my-custom-ecosystem/discovery/init_test/test_discovers_packages --- PASS: my-custom-ecosystem/discovery/init_test/test_discovers_packages (0.04s) === RUN my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory --- PASS: my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory (0.04s) ok 2 tests passed これは、私たちが設計し得た最も短い開発ループです。Go ツールチェーンも、再ビルドも、コンテナの起動も不要です。テストを書き、実行し、繰り返し改善するだけです。 実際のアーティファクトのスキャン プラグインが結果を生成するには、プラグインが探すファイルを含むアーティファクトを inspector-sbomgen に与える必要があります。サンプルプラグインの場合、 example.lock ファイルを含む任意のディレクトリが対象になります。先ほど生成したフィクスチャがちょうど良い題材です。 inspector-sbomgen directory \ --plugin-dir ./my-sbomgen-plugins \ --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ -o sbom.json --plugin-dir フラグは、Lua プラグインの読み込み元を inspector-sbomgen に伝えます。生成される SBOM には、 example.lock 内の 3 つのパッケージそれぞれに対応する CycloneDX コンポーネントが含まれます。例を以下に示します。 { "bom-ref": "comp-2", "type": "application", "name": "my-package-alpha", "version": "1.0.0", "scope": "optional", "purl": "pkg:generic/my-sbomgen-plugin/my-package-alpha@1.0.0", "properties": [ { "name": "amazon:inspector:sbom_generator:source_path", "value": "./my-sbomgen-plugins/example.lock" } ] } プラグインが生成するすべてのコンポーネントには、収集元のファイルを記録する amazon:inspector:sbom_generator:source_path プロパティが付いています。そのため、コンポーネントを生成元のアーティファクトまで常にたどることができます。 Amazon Inspector による脆弱性スキャン プラグインが生成したパッケージ情報は、他のコンポーネントと同等の正式な SBOM コンポーネントとして扱われます。Amazon Inspector を含め、CycloneDX SBOM を読み取るあらゆる下流のツールで利用できます。SBOM を Amazon Inspector に送信して脆弱性分析を行うには、 --scan-sbom フラグを追加します (有効な AWS アカウントが必要です)。 inspector-sbomgen directory \ --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \ --plugin-dir ./my-sbomgen-plugins \ --scan-sbom \ --aws-profile your_profile \ --aws-region your_region \ -o /tmp/sbom.json まったく新しいエコシステムに対応する際の重要な注意点 : プラグイン作成者は任意のエコシステムをインベントリ化できますが、Amazon Inspector が脆弱性を報告できるのは、アドバイザリが存在するコンポーネントに限られます。アドバイザリフィードにまだ含まれていないエコシステムのコンポーネントを Amazon Inspector に渡すと、Amazon Inspector は Component skipped: no supported rules found (コンポーネントはスキップされました: サポートされるルールが見つかりません) というプロパティ付きでコンポーネントを返します。以下に例を示します。 { "bom-ref": "comp-1", "name": "my-package-alpha", "properties": [ { "name": "amazon:inspector:sbom_scanner:path", "value": "my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/example.lock" }, { "name": "amazon:inspector:sbom_scanner:info", "value": "Component skipped: no supported rules found." } ], "purl": "pkg:generic/my-custom-ecosystem/my-package-alpha@1.0.0", "type": "application", "version": "1.0.0" } これはエラーではなく、想定どおりの動作です。SBOM は正しく生成され、コンポーネントは引き続き追跡され、 source_path によってどのファイルから生成されたかを正確に把握できます。Amazon Inspector がそのエコシステムのアドバイザリカバレッジを追加すれば、プラグインを一切変更することなく、同じ SBOM から脆弱性の検出結果が生成されるようになります。Amazon Inspector がすでにサポートしているエコシステムについては、プラグインが生成したコンポーネントは組み込みスキャナーが生成したコンポーネントと区別なく扱われます。 ファーストクラスの IDE サポート AWS は、プラグインを書くときの生産性と効率を重視しています。オートコンプリートのようなモダンな便利機能なしで Lua を書くのは快適とは言えません。そのため、 plugin new コマンドでスキャフォールディングされたすべてのプラグインプロジェクトには、 library/sbomgen.lua 定義ファイルと、それを VS Code の Lua Language Server 拡張機能に自動的に接続する .vscode/settings.json が付属します。 コード補完と IDE サポートを利用するには、まず sumneko.lua 拡張機能をインストールし、VS Code でプラグインプロジェクトを開きます。これにより、すべての sbomgen.* 関数で次の機能が使えるようになります。 型情報付きのパラメータヒント ホバー時のドキュメント表示 定数のオートコンプリート ( sbomgen.component_types.* 、 sbomgen.groups.* 、 sbomgen.platform.* ) 関数呼び出しの型チェック push_package() に必須フィールドが欠けている場合のインライン警告 この定義ファイルのおかげで、AI コーディングアシスタントによるプラグイン開発もうまく機能します。型情報とドキュメントがツールで読み取れる形式で埋め込まれているため、アシスタントは、素の Lua で記述する場合に比べてはるかに少ない人手の確認で正しいプラグインコードを生成できます。 安全な基盤 プラグインは inspector-sbomgen と同じプロセス内で実際のコードを実行するため、そのコードが安定し、セキュリティが強化された状態を保てるように実行環境を設計しました。すべての Lua プラグインは隔離されたサンドボックス内で実行されます。各 Lua 仮想マシン (VM) は、安全な操作のみが許可されるように、Lua 標準ライブラリの制限されたサブセットにのみアクセスできます。 ファイルシステムへの直接アクセスの禁止 – Lua の io ライブラリはロードされません。すべてのファイル操作は sbomgen.* 関数を経由して sbomgen の内部処理にルーティングされるため、ディスク上のディレクトリ、コンテナイメージ、圧縮アーカイブ、マウントされたボリュームのいずれをスキャンする場合でも、プラグインは同じように動作します サブプロセスの実行や環境の変更の禁止 – Lua の os ライブラリはブロックされているため、プラグインはプロセスの起動、環境変数の変更、アーティファクト外のファイルへのアクセスができません VM のイントロスペクションの禁止 – Lua の debug ライブラリはブロックされています 無制限なコードロードの禁止 – dofile 、 loadfile 、 loadstring は削除されています。 require() は利用できますが、プラグイン自身のディレクトリツリーに制限されているため、プラグインは自身のヘルパーモジュールを共有できる一方、他のプラグインやシステムパスからコードをロードすることはできません プラグインが未処理の Lua エラーを発生させた場合、inspector-sbomgen は警告をログに記録し、次のファイルまたはプラグインの処理を続行します。1 つの不具合のあるプラグインが他のプラグインの実行を妨げることはありません。また、プラグインが inspector-sbomgen の組み込みパッケージコレクターを上書きすることもありません。すべてのプラグインは一意の名前を宣言する必要があり、カスタムプラグインが公式の組み込みプラグインですでに使われている名前を使用した場合、そのカスタムプラグインは警告付きでスキップされます。組み込みプラグインが常に優先されるため、カスタムプラグインがツール自身の検出動作をひそかに置き換えたり隠したりすることはできません。 次のステップ 今すぐ独自のプラグインの構築を始めるには、次の手順に従ってください。 Amazon Inspector ユーザーガイド から最新の inspector-sbomgen をインストールします inspector-sbomgen plugin new --with-example を実行し、プロンプトに従います inspector-sbomgen plugin test --path ./my-sbomgen-plugins -v を実行し、サンプルテストがパスすることを確認します サンプルのロジックを、独自のエコシステム向けの検出ロジックに置き換えます すべての関数、定数、コマンドについては、以下の完全なリファレンスドキュメントで詳しく説明しています。 Lua プラグイン開発者ガイド : プラグインの概念、ディレクトリ構造、ライフサイクル Lua プラグインテストガイド : テストフレームワークのリファレンスとフィクスチャの規約 Lua プラグイン API リファレンス : sbomgen.* API の完全なカタログ まとめ 組織独自のロックファイル形式への対応の追加、新しいオープンソースエコシステム向け検出のプロトタイピング、あるいは自作スキャナーから組織全体で大規模に運用できる仕組みへの置き換えなど、どのような用途であっても、このプラグインシステムは、アイデアから動作する SBOM までの道のりをできる限り短くするように設計されています。皆さんがこれを使って何を作るのか、とても楽しみにしています。 この記事に関するご質問がある場合は、 AWS サポートにお問い合わせください 。 Michael Long Michael は AWS の Amazon Inspector 担当 Senior Security Researcher です。Amazon Inspector SBOM Generator と Amazon Inspector for GitHub Actions の研究開発を率いています。AWS 入社前は、MITRE ATT&CK チームで principal adversary emulation engineer を務めていました。また、U.S. Army (米国陸軍) で約 10 年間、軍事情報およびサイバー作戦に従事しました。 Charlie Bacon Charlie は AWS の Amazon Inspector 担当 Head of Security Engineering and Research です。Amazon Inspector や他の Amazon Security の脆弱性管理ツールを支える脆弱性スキャンおよびインベントリ収集サービスを担当するチームを率いています。AWS 入社前は、金融業界とセキュリティ業界で 20 年間にわたり、研究と製品開発の両分野で上級職を務めました。 Anthony Verleysen Anthony は Amazon Inspector 担当の Senior Technical Product Management です。Amazon Inspector の前は、AWS Systems Manager の Product Manager として Node Management 機能を担当していました。仕事以外では、テニスとサッカーに熱心に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 2 月 12 日に公開された AWS Blog “ Identify Java nested dependencies with Amazon Inspector SBOM Generator ” を翻訳したものです。公開後のサービスアップデートを訳注として補足しています。 Amazon Inspector は自動化された脆弱性管理サービスであり、 Amazon Web Services (AWS) のワークロードを継続的にスキャンして、ソフトウェアの脆弱性や意図しないネットワークの露出を検出します。Amazon Inspector は現在、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Container Registry (Amazon ECR) に保存されたコンテナイメージ、および AWS Lambda に対する脆弱性レポートをサポートしています。 訳注: 2025 年 6 月の Code Security 機能の一般提供開始 により、現在は GitHub および GitLab 上のソースコードリポジトリ (SAST / SCA / IaC スキャン) も対象となっています。 Java アーカイブファイル (JAR、WAR、EAR) は、Java アプリケーションやライブラリのパッケージングに広く使用されています。これらのファイルには、アプリケーションが正しく動作するために必要なさまざまな依存関係を含めることができます。場合によっては、JAR ファイルの構造の中に別の JAR ファイルが含まれ、ネストされた依存関係が生じることがあります。Java アプリケーションのセキュリティと安定性を維持するには、こうしたネストされた依存関係を特定し、管理することが不可欠です。 本記事では、ネストされた Java 依存関係を発見する際の課題への対処方法を紹介し、JAR ファイルを分析してこれらの依存関係を明らかにするプロセスを解説します。ここでは、 Amazon Inspector SBOM Generator を使用して Amazon Inspector が特定する脆弱性に焦点を当てます。 ネストされた Java 依存関係を発見する際の課題 Java アプリケーションのネストされた依存関係には、古くなっているものや、 共通脆弱性識別子 (CVE) に関連付けられた既知の脆弱性を含むものが存在することがあります。ここでお客様が直面する重要な問題は、分析やトリアージの際にネストされた依存関係が見落とされがちなことです。この見落としにより、脆弱性が誤検知と判断され、セキュリティリスクにつながる可能性があります。 この課題は、以下のような複数の要因から生じます。 脆弱性の量 : 大量の脆弱性に直面すると、その数の多さに圧倒され、それぞれを徹底的に分析するための十分な時間とリソースを確保することが難しくなります ツールの不足または不十分なツール : ネストされた依存関係を効果的に特定できるツール ( mvn dependency:tree や OWASP Dependency-Check など) が十分に整備されていないことがよくあります。適切なツールがなければ、アプリケーションの深部に隠れた重要な依存関係を見逃す可能性があります 複雑さの理解 : 複雑に絡み合ったネストされた依存関係を理解するには、特定のスキルセットと知識が必要です。こうしたスキルや知識が不足していると、効果的な分析とリスク緩和の妨げになる可能性があります ネストされた依存関係の概要 ネストされた依存関係は、アプリケーションが必要とするライブラリやモジュールが、さらに別のライブラリやモジュールに依存している場合に発生します。これはモダンなソフトウェア開発では一般的なシナリオです。開発者は、既存のソリューションを土台にし、オープンソースコミュニティに蓄積された知見を活用するために、サードパーティライブラリを頻繁に使用するからです。 JAR ファイルの文脈では、JAR ファイルの構造の一部として別の JAR ファイルが含まれる場合に、ネストされた依存関係が生じることがあります。これらのネストされたファイルは独自の依存関係を持つことがあり、それがさらに別のライブラリに依存して、依存関係の連鎖を作り出します。ネストされた依存関係はコードのモジュール化と再利用を促進する一方で、適切に管理されないと複雑さが増し、セキュリティ上の脆弱性が生じる可能性が高まります。 JAR ファイルで使用されている依存関係を把握することが重要な理由 ネストされた依存関係がどのように構成されているかを示すために、Java アプリケーションの典型的なファイル構造を表す以下の例を見てみましょう。 例 1: Log4J の依存関係 MyWebApp/ |-- mywebapp-1.0-SNAPSHOT.jar | |-- spring-boot-3.0.2.jar | | |-- spring-boot-autoconfigure-3.0.2.jar | | | |-- ... | | | | |-- log4j-to-slf4j.jar この構造には、以下のファイルと依存関係が含まれています。 mywebapp-1.0-SNAPSHOT.jar はメインのアプリケーション JAR ファイルです mywebapp-1.0-SNAPSHOT.jar の中には、メインアプリケーションの依存関係である spring-boot-3.0.2.jar があります spring-boot-3.0.2.jar の中には、推移的依存関係である spring-boot-autoconfigure-3.0.2.jar がネストされています spring-boot-autoconfigure-3.0.2.jar の中には、ネストされた Log4J の依存関係である log4j-to-slf4j.jar があります この構造は、Log4J が他のライブラリの中にネストされる形で、Java アプリケーションにネストされた依存関係が含まれる仕組みを示しています。実際のネストの深さや依存関係は、プロジェクトで使用する特定のライブラリとバージョンによって異なります。 例 2: Jackson の依存関係 MyFinanceApp/ |-- myfinanceapp-2.5.jar | |-- jackson-databind-2.9.10.jar | | |-- jackson-core-2.9.10.jar | | | |-- ... | | |-- jackson-annotations-2.9.10.jar | | | |-- ... この構造には、以下のファイルと依存関係が含まれています。 myfinanceapp-2.5.jar はアプリケーションのプライマリ JAR ファイルです myfinanceapp-2.5.jar の中には、メインアプリケーションが JSON 処理のために利用するライブラリである jackson-databind-2.9.10.jar があります jackson-databind-2.9.10.jar の中には、 jackson-core-2.9.10.jar や jackson-annotations-2.9.10.jar などの他の Jackson コンポーネントがネストされています。これらは jackson-databind 自体が動作するために必要な依存関係です この構造は、JSON 操作に Jackson を使用する Java アプリケーションの例です。Jackson ライブラリは、パフォーマンスの最適化やセキュリティ修正など、さまざまな問題に対応するために頻繁に更新されるため、開発者はアプリケーションを最新かつ安全な状態に保つうえで、これらのネストされた依存関係を把握しておく必要があります。これらのコンポーネントがアプリケーション内のどこにネストされているかを詳しく把握していれば、保守やアップグレードが容易になります。 例 3: Hibernate の依存関係 MyERPSystem/ |-- myerpsystem-3.1.jar | |-- hibernate-core-5.4.18.Final.jar | | |-- hibernate-validator-6.1.5.Final.jar | | | |-- ... | | |-- hibernate-entitymanager-5.4.18.Final.jar | | | |-- ... この構造には、以下のファイルと依存関係が含まれています。 myerpsystem-3.1.jar はアプリケーションのプライマリ JAR ファイルです myerpsystem-3.1.jar の中では、 hibernate-core-5.4.18.Final.jar がオブジェクトリレーショナルマッピング (ORM) 機能の依存関係として機能します hibernate-validator-6.1.5.Final.jar や hibernate-entitymanager-5.4.18.Final.jar などのネストされた依存関係は、Hibernate が提供するバリデーションおよびエンティティ管理機能に不可欠です MyERPSystem が Hibernate のバージョンと別のライブラリとの不一致 (例えば、新しいバージョンの Spring が異なるバージョンの Hibernate を想定している場合など) により運用上の問題に直面した場合、開発者は Amazon Inspector SBOM Generator が提供する詳細な情報を活用できます。このツールを使用すれば、Hibernate とそのネストされた依存関係の正確なバージョンを迅速に特定でき、互換性の問題をより早く解決できます。 JAR ファイル内で使用されている依存関係を理解することが重要な理由を、いくつか挙げます。 セキュリティ : ネストされた依存関係が古い、または既知のセキュリティ問題を抱えている場合、脆弱性をもたらす可能性があります。代表的な例は、 2021 年後半に発見された Log4J の脆弱性 (CVE-2021-44228) です。Log4J は広く使用されているロギングフレームワークであり、脅威アクターがこの欠陥をリモートから悪用でき、深刻な結果を招く恐れがあったため、この脆弱性は重大なものとなりました。さらに問題を悪化させたのは、Log4J がさまざまな Java アプリケーションにネストされた依存関係として存在することが多く ( 例 1 を参照)、組織が Log4J を含む箇所をすべて洗い出してパッチを適用するのが困難だったことです コンプライアンス : 多くの組織は、ライセンス、規制、またはセキュリティ上の理由から、サードパーティライブラリに関する厳格なポリシーを順守する必要があります。依存関係、特に Log4J のケースのようなネストされた依存関係を把握していないと、これらのポリシーに違反する可能性があります 保守性 : 適切なタイミングで更新や置き換えを行うためには、プロジェクト内の依存関係を常に把握しておくことが不可欠です。Jackson ライブラリ ( 例 2 ) は、新機能の導入やセキュリティ脆弱性の修正のために頻繁に更新されます。特にライブラリがネストされた依存関係である場合、これらの更新の管理は複雑になる可能性があります トラブルシューティング : 依存関係の特定は、運用上の問題を迅速に解決するうえで重要な役割を果たします。その一例が、バージョンの不一致に起因する、アプリケーション内の Hibernate と他の Java ライブラリやフレームワーク間の互換性問題への対処です ( 例 3 )。このような問題は、予期しない例外やパフォーマンスの低下として現れることが多いため、関係するライブラリを正確に把握する必要があります これらの例からわかるように、目の前の脅威から保護し、アプリケーションの長期的な健全性とコンプライアンスを確保するには、JAR ファイルの内容を詳細に把握できる状態にしておく必要があります。 既存ツールの限界 Java アプリケーションのネストされた依存関係を分析する際の主な課題の 1 つは、既存のツールではこれらの依存関係の正確な場所を効率的に絞り込めないことです。この問題は、 mvn dependency:tree や OWASP Dependency-Check をはじめとする同様の依存関係分析ソリューションで特に顕著です。 Java アプリケーションのネストされた依存関係を分析するツールは存在するものの、いくつかの重要な領域で不十分なことがよくあります。以下に、これらのツールの一般的な限界を挙げます。 依存関係ツリーの深さの不足 : 既存のツールはプロジェクトの依存関係を階層的に表示しますが、多くの場合、ネストされた依存関係、特に他の JAR ファイル内に埋め込まれているものを明らかにするほど深くは掘り下げられません。ネストされた依存関係はライブラリ内に再パッケージ化されており、標準の依存関係ツリーではすぐには見えません 具体的な場所情報の欠如 : これらのツールは通常、JAR ファイル内のネストされた依存関係の正確な場所を特定するために必要な粒度の情報を提供しません。大規模で複雑な Java アプリケーションでは、特定の依存関係、特に深く埋め込まれているものを特定して対処するのが難しい場合があります 大規模プロジェクトにおける複雑さ : 依存関係が広範かつ複雑に絡み合ったプロジェクトでは、これらのツールは明確で実用的な洞察を提供するのに苦労することがあります。出力が複雑で扱いにくくなり、重要な依存関係を特定するための明確な道筋が得られないことがあります Amazon Inspector SBOM Generator によるツールの限界への対処 Amazon Inspector SBOM Generator (Sbomgen) は、Java アプリケーションのネストされた依存関係の特定において大きな進歩をもたらします。依存関係の監視という概念自体はソフトウェア開発において十分確立されていますが、AWS はソフトウェア構成の複雑さに対する可視性を高めるためにこのツールを設計しました。コンテナイメージのソフトウェア部品表 (SBOM) を生成することで、Sbomgen は、従来のツールでは見落とされがちな隠れたネストされた依存関係を含む、システムにインストールされたソフトウェアの詳細なインベントリを提供します。この機能は既存のツールキットを補完し、アプリケーションの依存関係構造をより詳細かつ実用的に理解できるようにします。 Sbomgen は、インストールされたパッケージに関する情報を含むファイルをスキャンすることで動作します。該当するファイルが見つかると、パッケージ名、バージョン、その他のメタデータなどの重要なデータを抽出します。その後、このメタデータを CycloneDX SBOM に変換し、依存関係の構造化された詳細なビューを提供します。 Sbomgen のインストール方法については、Amazon Inspector ユーザーガイドの「 Sbomgen のインストール 」を参照してください。 訳注: 本記事公開時点の Amazon Inspector SBOM Generator は v1.0 系ですが、2026 年 8 月時点の最新は v1.13 系です。対応エコシステムは Go / Rust バイナリや Windows アプリケーションなどに大幅に拡大しているほか、v1.13 では Lua で独自のパッケージコレクタを追加できるプラグインシステムが導入されました。詳細は “ Amazon Inspector SBOM Generator をプラグインで拡張 ” を参照してください。本記事のコマンドは翻訳時点の最新バージョン(v1.13 系)で動作することを確認していますが、最新の構文は Amazon Inspector SBOM Generator のドキュメント を参照してください。 Sbomgen の主要な機能の 1 つは、各依存関係への明示的なパスを提供できることです。 例えば、コンパイル済みの JAR アプリケーション MyWebApp-0.0.1-SNAPSHOT.jar がある場合、Sbomgen で以下の CLI コマンドを実行できます。 ./inspector-sbomgen localhost --path /path/to/MyWebApp-0.0.1-SNAPSHOT.jar --scanners java-jar 出力は以下のようになります。 { "bom-ref": "comp-11", "type": "library", "name": "org.apache.logging.log4j/log4j-to-slf4j", "version": "2.19.0", "hashes": [ { "alg": "SHA-1", "content": "30f4812e43172ecca5041da2cb6b965cc4777c19" } ], "purl": "pkg:maven/org.apache.logging.log4j/log4j-to-slf4j@2.19.0", "properties": [ ... { "name": "amazon:inspector:sbom_generator:source_path", "value": "/tmp/MyWebApp-0.0.1-SNAPSHOT.jar/BOOT-INF/lib/spring-boot-3.0.2.jar/BOOT-INF/lib/spring-boot-autoconfigure-3.0.2.jar/BOOT-INF/lib/logback-classic-1.4.5.jar/BOOT-INF/lib/logback-core-1.4.5.jar/BOOT-INF/lib/log4j-to-slf4j-2.19.0.jar/META-INF/maven/org.apache.logging.log4j/log4j-to-slf4j/pom.properties" } ] } この出力では、 amazon:inspector:sbom_generator:source_path プロパティが特に重要です。このプロパティは、アプリケーションの構造内における特定の依存関係 (この場合は log4j-to-slf4j ) の場所への明確で完全なパスを提供します。このレベルの詳細な情報は、以下のような理由から極めて重要です。 正確な場所の特定 : 各依存関係の正確な場所を迅速かつ正確に特定できます。これは、通常は見つけにくいネストされた依存関係の場合に特に役立ちます 効果的なリスク管理 : 依存関係の正確なパスがわかると、これらの依存関係に関連するセキュリティリスクをより効率的に評価し、対処できます 時間とリソースの効率化 : 依存関係を手動で追跡・分析するために必要な時間とリソースを削減し、脆弱性管理プロセスを効率化します 可視性と透明性の向上 : アプリケーションの依存関係構造をより明確に理解できるようになり、全体的な管理と保守の改善に貢献します 包括的なパッケージ情報 : Sbomgen が提供する名前、バージョン、ハッシュ、 パッケージ URL を含む詳細なパッケージ情報により、各依存関係の詳細を十分に理解でき、正確な脆弱性の追跡とソフトウェアの整合性検証に役立ちます 脆弱な依存関係への対処 Java JAR ファイル内のネストされた依存関係を特定したら、次はそれらの依存関係が古くなっていないか、脆弱性がないかを検証する必要があります。Amazon Inspector は以下を行うことで、この検証を支援します。 発見された依存関係を既知の脆弱性のデータベースと比較する 脆弱な可能性のある依存関係のリストを、関連する CVE の詳細情報とともに提供する 依存関係をより新しく安全なバージョンに更新するなど、リスクを緩和する方法についての推奨事項を提供する Amazon Inspector をソフトウェア開発ライフサイクルに統合することで、Java アプリケーション内の脆弱なネストされた依存関係を継続的に監視し、アプリケーションの安全性とコンプライアンスの維持に必要な措置を講じることができます。 まとめ Java アプリケーションの安全性を高めるには、ネストされた依存関係の管理が欠かせません。Amazon Inspector は、JAR ファイル内の脆弱な可能性のある依存関係を自動的かつ効率的に検出し、対処する方法を提供します。Amazon Inspector の機能を活用することで、Java アプリケーションのセキュリティポスチャを改善し、ベストプラクティスに準拠させることができます。   本記事に関するご質問がある場合は、 AWS サポートにお問い合わせください 。 Chi Tran Chi はセキュリティリサーチャーとして、AWS のサービス、アプリケーション、ウェブサイトが最高のセキュリティ基準で設計・実装されるよう支援しています。Amazon Inspector の分野専門家 (SME) として、高度な問題やユースケースを抱えるお客様を熱心にサポートしています。Chi が情熱を注いでいるのは情報セキュリティです。具体的には、API セキュリティ、ペネトレーションテスト (OSCP、OSCE、OSWE、GPEN の認定を保持)、アプリケーションセキュリティ、クラウドセキュリティです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は「 GPT‑5.6 update: lower credit multipliers for Terra and Luna 」を翻訳したものです。 OpenAI が GPT‑5.6 Terra および Luna の価格を引き下げたため、その値下げ分を Kiro のお客様に還元します。OpenAI の新価格を反映した最新のクレジット倍率が、現在すでに適用されています。 GPT‑5.6 Luna は 0.6x から 0.1x に引き下げ GPT‑5.6 Terra は 1.2x から 1.0x に引き下げ GPT‑5.6 Sol は 2.4x のまま変更なし GPT‑5.6 Sol、Terra、Luna は、Kiro Pro、Pro+、Pro Max、Power の お客様向けに実験的サポート として提供されています。Kiro における GPT‑5.6 の詳細については、 最初のリリース記事 をご覧ください。

メインフレーム基幹系システムの移行を真剣にご検討中のお客様をお迎えし、「AWS Mainframe Modernization Day Tokyo 2026」を開催します。メインフレームの価値は伝統的に RAS (Reliability, Availability, Serviceability) に象徴されます。本イベントでは、重要なシステムの安定稼働のために AWS が提供しているサービスや機能を各エリアの専門家が説明し、基幹システムを AWS クラウド上で稼働する際の懸念を解消します。 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ、セキュリティ、レジリエンシー、運用の高度化(オブザーバビリティと自動化)など、メインフレームからの移行後の安定稼働において最も重要な技術領域を、初めての方にもわかりやすく網羅的にカバーします。さらに、既に AWS 移行を推進されている先進的なお客様の生の声をお届けし、社内コンセンサス確立のための具体的なヒントを提供します。参加者同士の交流会では、AWS のスペシャリストやメインフレーム専門チームメンバーも交え、同じ課題に直面する企業間での直接的な情報交換の場を設けます。 背景と位置付け お客様が直面している課題 メインフレームを運用する多くのお客様は、安定稼働の継続、体制の転換、ノウハウの継承という構造的課題に直面していると考えられます。 ミッションクリティカルワークロードはメインフレーム上で過去数十年にわたり安定稼働してきました。それをクラウド移行後も同様に安定稼働することは、最も重要な移行要件の一つと考えられます。メインフレーム上の大規模なバッチワークロードはクラウド上でも同等の性能を示す必要があります。メインフレームは単一筐体内の構成要素の冗長化により高可用性を実現していますが、同等の安定稼働をクラウドでも実現できなくてはなりません。しかし、現在メインフレームのクラウド移行を検討しているお客様は、過去にその実績が少なく、経験者が社内に居ないケースが多くあります。そのため、移行後の安定稼働とセキュリティに確証を持てず、慎重になりがちです。関係者からクラウド移行の支持を獲得し、コンセンサスを確立するのは容易ではありません。 また、メインフレーム担当者は、自分達がリタイアした後も基幹系システムの安定稼働を継続できるよう、お客様社内で上層部から指示されているケースもあります。しかし、メインフレーム人材の減少により運用体制の維持が困難になりつつあり、希少スキルを持つ人材の育成や調達は容易ではありません。メインフレーム人材の育成は若手社員の動機付けが難しく、単純なクラウド移行は ROI が説明できず、板挟みになりがちです。メインフレーム担当者が持つ業務知識や、安定稼働のためのインフラの知識、運用ノウハウ等は、テクノロジーが変わっても有用なはずです。このままだと、経験を通じて得られた貴重なナレッジが引継ぎ先も無いまま喪失する危機に直面していると思われます。 本イベントの意義 本イベントは大規模開催ではなく、通常のセッションや打ち合わせでは得られない情報を、各領域の専門家から直接聞くことができる貴重な機会です。 特に以下のような方々に最適なイベントとなっており、日頃クラウドに接点のないメインフレーム担当組織からの参加を期待しています。 メインフレーム基幹系システムの AWS クラウド移行を具体的に計画されている方 専任のプロジェクトチームを立ち上げ、次期システム更改等のタイミングまでに AWS 移行を実施したい方 メインフレームの高可用性・高信頼性と同等の安定稼働を AWS クラウド上で実現する方法を知りたい方 AWS 移行に向けた予算申請や稟議を進めるにあたり、技術的な裏付けを得たい方 先進企業がどのように社内のステークホルダーの理解と賛同を得たか、具体的なアプローチを学びたい方 本イベントに参加することで、クラウド移行に漠然とした不安を感じていた方にも、AWS クラウド移行を前向きに考える機会にして頂ければと思います。 対象 IBM z/OS および富士通 GS21 OSIV/MSP で稼働する基幹系システムを担当する組織のリーダー的な役割の方を対象としています。基幹系システムの安定稼働を実現する AWS の技術的価値、先進的なお客様の移行経験や社内合意形成の工夫に焦点を当てますので、メインフレーム基幹系システムの AWS 移行を計画的に実施したい方にご参加頂きたいイベントです。 なお、本イベントはメインフレームの知識を前提とするセッションで構成されています。 イベントの構成 本イベントは 3 部構成で実施します。Part 1 の AWS セッションでは、メインフレームの RAS とは別のアプローチで基幹系システムの安定稼働を実現する AWS のテクノロジーや機能を各エリアの専門家が提示します。Part 2 のお客様セッションでは、先進的なお客様による移行経験を共有します。Part 3 の交流会では、参加者間の直接対話を通じて課題と解決方法を共有します。 Part 1: AWS セッション メインフレームの価値は伝統的に RAS (Reliability, Availability, Serviceability) に象徴されます。Reliability はハードウェアの自己診断・自己回復能力とソフトウェアの信頼性を、Availability は障害コンポーネントからの無停止回復を、Serviceability は障害原因の特定と影響を最小化した交換を意味します。 これと異なる方法で基幹系システムの安定稼働を実現する AWS のアプローチを、以下の 4 セッションで紹介します。 (1) 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ (2) セキュリティ (3) レジリエンシー (4) 運用の高度化 本セッションを通じて、メインフレーム利用者が基幹系システムを AWS クラウド上で稼働する際に感じる懸念を解消したいと考えます。 加えて、クラウド移行には、スケーラビリティ (需要に応じたリソースの弾力的な拡張/縮小)、コスト最適化 (従量課金モデルによる固定費からの脱却)、ベストプラクティスの豊富さ (開発および運用における膨大なナレッジとツール群)、人材の調達容易性(クラウドスキル人材市場の厚み)といった、積極的なメリットがあることは言うまでもありません。 Part 2: お客様セッション 基幹系システムの AWS 移行を既に実施しつつある先進的なお客様に登壇いただくべく、調整中です。そして、「Why (何故クラウド移行を決断したか)」と「How (どのようにして社内外の理解と賛同を得たか)」を語っていただきたいと考えています。 Part 3: お客様同士の交流会 同じ課題に直面するお客様同士で会話し、直接的な情報交換の場を設けます。 AWS セッションに登壇したスペシャリストや、メインフレーム専門チームメンバーも交え、ディープな Q&A を通じて日頃の疑問を投げ掛けて頂き、より実践的な情報を得ることができます。 イベント概要 開催日時 2026 年 9 月 17 日(木) 13:30 – 18:00 (13:00 受付開始) 開催場所 麻布台ヒルズ (東京) AWS オフィス 〒106-0041 東京都港区麻布台 1 丁目 3-1 麻布台ヒルズ 森 JP タワー 東京メトロ日比谷線 神谷町駅より徒歩約 9 分、東京メトロ南北線 六本木一丁目駅より徒歩約 7 分 ※入退館等詳細は別途ご連絡いたします 定員 15 社 (1 社あたり 2〜3 名) 可能であれば、アプリケーション担当者と基盤担当者のペアでお越しください 同一グループ企業内の事業会社および子会社は合わせて 1 社として扱わせて頂きます 前提となる知識/経験 メインフレーム (IBM z/OS または富士通 GS21 OSIV/MSP) 上の基幹系システムの開発や保守運用経験があることを前提に、AWSクラウドのインフラストラクチャ、セキュリティ、レジリエンシー、運用に関連したセッションを実施します。AWSの事前知識は不要です。 参加費 無料 参加申込方法 参加希望される方は、 イベント情報 のページの「今すぐ登録する」からお申込下さい。 なお、参加申込される方の代表者は、 事前アンケート のページで、基幹システムの概要や移行予定時期 (目標) 等についての情報提供をお願い致します。 ご留意事項 会場の収容人数に限りがあるため、お申込みいただいてもご参加をお受けできない場合がございます。あらかじめご了承ください。 募集期間: 2026 年 8 月 21 日 (金) まで 参加可否のご連絡: 2026 年 8 月 31 日 (月) まで プログラム内容 時間 内容 13:00 – 13:30 受付 13:30 – 13:40 オープニング・ご挨拶 Part 1: AWS セッション 13:40 – 14:20 (1) 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ 14:20 – 14:35 休憩 14:35 – 14:55 (2) セキュリティ 14:55 – 15:15 (3) レジリエンシー 15:15 – 15:35 (4) 運用の高度化 15:35 – 15:50 総括 15:50 – 16:05 休憩 Part 2: お客様セッション 16:05 – 16:45 お客様によるプレゼンテーションと Q&A (講師調整中) 16:45 – 17:00 オフィスツアー Part 3: 交流会 17:00 – 18:00 お客様同士の交流会

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 みなさんは AWS Builder Center を活用されていますか? AWS Builder Center は、世界中のビルダーが書いた記事や動画などのコンテンツ、コミュニティ、学習リソースがひとつに集まったプラットフォームです。トピックごとにコンテンツがまとまっているのが便利で、例えば agent-to-agent のトピックページ では、AI エージェント同士を連携させる A2A に関する記事を一覧で読むことができます。気になる技術分野のトピックをフォローしておくと、最新のノウハウを効率よくキャッチアップできるので、ぜひ覗いてみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月20日週の主要なアップデート 7/20(月) KNFSD File Cache のプレビュー提供を開始 AWS は NFS キャッシュソリューション KNFSD File Cache のプレビュー提供を開始しました。Apache-2.0 ライセンスのオープンソースで、オンプレミスや別リージョン、他クラウドの NFS サーバーをマウントし、AWS 内の NFS クライアントに再エクスポートします。頻繁に読み取られるデータをメモリとローカル NVMe にキャッシュし、高レイテンシー回線を越えるアクセスを 1 回に抑えて VPC 内速度で配信します。Linux カーネル標準の nfs-kernel-server と FS-Cache を利用し、Packer で AMI を構築後 Terraform でクラスターをデプロイします。全 AWS リージョンで利用でき、ライセンス費用はかからず消費した AWS リソースにのみ課金されます。 Amazon CloudWatch が Coding Agent Insights を発表 Amazon CloudWatch は、AI コーディングエージェントの利用状況を可視化する Coding Agent Insights を発表しました。Claude Code、OpenAI Codex、GitHub Copilot の OpenTelemetry (OTel) メトリクスを CloudWatch に取り込み、組織/部門/チーム/ユーザー単位で利用状況やコストを確認できます。Claude apps gateway for AWS と連携すると、追加の計装なしで Claude Code のテレメトリを収集できます。ダッシュボードは CloudWatch コンソールの GenAI Observability 配下に自動で表示され、料金は標準の CloudWatch OTel メトリクス取り込み料金が適用されます。 Amazon WorkSpaces Applications がマルチセッションフリートで Microsoft OneDrive と Google Drive に対応 Amazon WorkSpaces Applications のマルチセッションフリートで、永続ストレージオプションとして Microsoft OneDrive for Business と Google Drive が利用できるようになりました。従来はマルチセッションフリートで Amazon S3 バックエンドの home folder のみが選択肢でしたが、今回のアップデートでユーザーは自身の OneDrive / Google Drive アカウントを接続し、ストリーミングセッション内でクラウドファイルを直接参照・保存・同期できます。マルチセッションフリートは 1 つのフリートインスタンスを複数ユーザーで共有してセッション密度を高める構成で、コストを抑えながらクラウドストレージ体験を提供できます。機能の追加料金はなく、標準の WorkSpaces Applications 利用料金のみが適用されます。有効化には 2026 年 6 月 29 日以降にリリースされたエージェントを含むイメージが必要です。 Amazon Connect のエージェント型音声機能を対応言語と発話制御の拡張により強化 Amazon Connect は、agentic voice (エージェント型音声) 機能で 50 以上のロケール (言語) と 100 を超える音声オプションに対応しました。Spanish、French、Italian、Japanese、Korean、Portuguese、Thai などが含まれます。発話のペーシング、話者交替 (turn-taking) の精度向上に加え、速度/音量/感情を調整できる発話制御 (speech controls) を利用できます。この機能は Amazon Connect Customer のデフォルト音声プロバイダーとして提供され、米国/欧州/アジアパシフィックの 9 リージョンで利用できます。 AWS CloudTrail で ID 別にネットワークアクティビティイベントを選択的にログ記録 AWS は CloudTrail のネットワークアクティビティイベント (VPC エンドポイント向け) に対して、IAM ユーザー ID に基づくイベントフィルタリングを追加しました。API を呼び出した ID を条件にして、ログを記録するイベントを絞り込めます。例えば信頼済み IAM ロール以外からの VpceAccessDenied イベントだけを記録する、といった設定ができます。これにより、承認済みプリンシパルからの正常なトラフィックを除外し、ログ量とコストを抑えられます。この機能は AWS Management Console、AWS CLI、AWS SDK から利用でき、CloudTrail ネットワークアクティビティイベントが対応する全リージョンで使えます。 7/21(火) Amazon RDS for SQL Server が Microsoft SQL Server 2025 に対応 Amazon RDS for SQL Server が Microsoft SQL Server 2025 (Enterprise、Standard、Developer の各エディション) に対応しました。RDS で提供される最新マイナーバージョンは 17.0.4045.5 (CU5) です。SQL Server 2025 は T-SQL から外部 REST エンドポイントを呼び出す機能をデータベースエンジンに組み込んでおり、Amazon Bedrock や Amazon SageMaker、Amazon S3、AWS Lambda といった AWS サービスとアプリケーションを再設計せずに連携できます。また native vector データ型による埋め込みベクトルの格納/検索に対応し、Standard Edition は最大 32 コア/256 GB バッファプールへ拡張され Resource Governor も利用できるようになりました。既存の RDS インスタンスは DB エンジンバージョンの変更でアップグレードでき、オンプレミスからの移行も可能です。 Amazon ECS が Action Logs を提供開始 (デプロイとオーケストレーションの可視化) Amazon ECS は、サービスデプロイと ECS Managed Daemon 更新の際に ECS がユーザーに代わって実行する操作を、タイムスタンプ付きで記録する Action Logs を提供開始しました。従来は開始状態と終了状態しか観測できなかった中間操作 (コンテナイメージのダウンロード、ロードバランサー登録、セキュリティグループ設定など) を確認できるようになりました。ログはクラスターレベルで opt-in し、CloudWatch Logs、Amazon S3、Amazon Data Firehose のいずれかへ配信できます。Amazon Q が Action Logs と連携し、circuit breaker によるロールバックなどの原因分析をコンソール内で提供します。AWS GovCloud (US) を含む全 AWS リージョンで利用できます。 Amazon SES が料金プランを導入 Amazon SES は、個別のアドオンとして販売されていたメール到達性関連の機能を 3 段階の料金プラン (Essentials、Pro、Enterprise) にまとめて提供する仕組みを導入しました。各プランは下位プランの機能をすべて含み、上位ほど機能が増えます。従来の従量課金と比べて割引が適用されます。プランはアカウント単位かつ AWS リージョン単位で選択し、中東 (UAE) および中東 (バーレーン) を除く Amazon SES 提供リージョンで利用できます。新規アカウントは 2026 年 7 月 21 日以降 Essentials から開始します。 7/22(水) Amazon EKS の EKS Auto Mode と Karpenter で EFA と Placement Group をサポート Amazon EKS の EKS Auto Mode とオープンソースの Karpenter で、ノードプールの EC2 Placement Group (配置グループ) と Elastic Fabric Adapter (EFA) のネットワークインターフェース設定に対応しました。NodeClass または EC2NodeClass の定義から、EFA-only インターフェースの構成と、cluster / spread / partition の 3 種類の配置戦略を指定できます。EFA-only インターフェースは IP アドレスを消費しないため、VPC 内の IP 使用量を抑えながら EFA の帯域を利用できます。分散学習や分散推論のスループット最適化と、本番サービスの障害範囲 (blast radius) 縮小の両方に対応します。この機能は Amazon EKS が利用可能なすべての AWS リージョンで使えます。 Network Load Balancer がカスタムトラフィックルーティング向けのリスナールールに対応 Network Load Balancer (NLB) が、送信元 IP アドレスタイプ (IPv4 / IPv6) に基づいて接続を別々のターゲットグループへ振り分けるリスナールールに対応しました。1 台のデュアルスタック NLB で IPv6 クライアントの通信を IPv6 ターゲットへ、IPv4 クライアントの通信を IPv4 ターゲットへ送り、両方のアドレスファミリでクライアント元 IP をエンドツーエンドで保持できます。従来はロードバランサーを 2 台に分ける方法か、プロトコル変換で元 IP を失う方法のいずれかを選ぶ必要がありましたが、この機能でその制約がなくなりました。既存のデュアルスタック NLB に作り直しなしでルールを追加できます。全 AWS 商用リージョンと AWS GovCloud (US) リージョンで追加料金なしで利用できます。 7/23(木) Amazon CloudWatch Logs が Application Load Balancer ログに対応 Amazon CloudWatch Logs が Application Load Balancer (ALB) のログを vended logs として受け取れるようになりました。ALB のアクセスログ、接続 (connection) ログ、ヘルスチェックログの 3 種類を CloudWatch に直接配信し、Logs Insights クエリ、メトリクスフィルタ、Live Tail で分析できます。配信先は CloudWatch Logs のほか Amazon Data Firehose と Amazon S3 (Apache Parquet 形式対応) を選択できます。CloudWatch telemetry enablement rules を使うと、既存および新規の ALB に対してログ設定を自動適用できます。ALB と CloudWatch が利用可能なすべての AWS 商用および GovCloud リージョンで利用できます。 7/24(金) aws-bench (AWS 上の AI エージェント向けオープンソースベンチマーク) を発表 AWS は 2026 年、AI エージェントが実際の AWS タスクをどれだけ正確かつ効率的に完了できるかを測定するオープンソースベンチマーク aws-bench をリサーチプレビューとして公開しました。実際の AWS 環境を都度払い出し、エージェントに調査・トラブルシューティング・インフラ作成のタスクを実行させて採点します。テストケースは自然言語クエリ、クラウドリソースの状態、正解データの 3 点で構成され、任意のエージェントやモデルを一貫した基準で比較できます。テスト環境の構築・実行・採点・リセットを行う CLI が同梱され、GitHub (Apache License 2.0) で入手できます。 AWS で Claude Opus 5 が利用可能に AWS は 2026 年 7 月 23 日に Anthropic の最新モデル Claude Opus 5 の提供を開始しました。コーディング、長時間稼働エージェント、文書量の多い業務での推論精度が向上しています。提供経路は Amazon Bedrock と Claude Platform on AWS の 2 つで、Bedrock 版はゼロデータ保持 (ZDR) がデフォルトで有効です。コンテキストウィンドウは 1M トークン、最大出力は 128K トークンで、東京リージョン (ap-northeast-1) からは Global クロスリージョン推論経由で利用できます。入力 $5 / 出力 $25 (100 万トークンあたり) の価格で、前世代 Opus 4.8 と同水準の単価に据え置かれています。 Amazon EC2 Dedicated Hosts がセルフマネージドライセンスなしでホストリソースグループに対応 EC2 Dedicated Hosts のホストリソースグループ (Host Resource Groups, HRG) を、これまで必須だったセルフマネージドライセンス (Self-Managed Licenses, SML) の作成と AMI 関連付けなしで作成できるようになりました。ハードウェアレベルの分離だけを目的とする顧客や EC2 Mac インスタンスの顧客は、AWS License Manager でのライセンス設定手順を省略できます。BYOL (Bring Your Own License) ワークロードでは従来どおり SML 付きの HRG も作成でき、起動できる AMI の制限とホスト単位のライセンス消費追跡を継続できます。HRG がサポートされる全ての AWS リージョンで利用できます。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

本ブログは 2026 年 7 月 29 日に公開された AWS Blog「 Amazon identifies North Korean hacker group behind open-source supply chain attacks 」を翻訳したものです。 Amazon は、北朝鮮 (朝鮮民主主義人民共和国、DPRK) に関連する脅威アクターが、世界中の企業がアプリケーション開発に利用する共有ビルディングブロックであるオープンソースソフトウェアライブラリを標的にしている実態について、新たな調査結果を公開します。Amazon Threat Intelligence は、最近発生した複数の人気 Node Package Manager (NPM) ライブラリの侵害が、同一の北朝鮮に関連する脅威アクターによるものであることを特定しました。この関連性はこれまで公に報告されていませんでした。また、この分析では、生成 AI が悪意のあるソフトウェアパッケージの姿をどのように変化させているか、そして脅威アクターが AI ベースのコードシステムをどのように探り始めているかについても説明します。この調査結果を公開することで、オープンソースコミュニティやセキュリティチームが、こうした事象をより的確に検知し、対処できるよう支援します。 これらの動きは、XZ Utils バックドア事件から 2 年後に発生しています。この事件は、忍耐強い攻撃者がボランティアのメンテナーの信頼や時間的な制約を悪用することで、重要なオープンソースソフトウェアをどのように侵害できるかを示しました。オープンソースソフトウェアは、オペレーティングシステム、ウェブサーバー、暗号化ライブラリ、そして企業が日常的に利用しているアプリケーションフレームワークなど、インターネットインフラの多くを支えています。攻撃者が広く使われているオープンソースパッケージを侵害すると、そのパッケージに依存するすべての組織が影響を受ける可能性があります。それ以降、Amazon Threat Intelligence は、北朝鮮に関連する脅威アクターやサイバー犯罪グループが大きく関与する形で、ソフトウェアサプライチェーン攻撃の件数と巧妙さが増していることを確認しています。 この記事では、Amazon Threat Intelligence と Amazon Inspector チームが、人気の NPM パッケージを狙った最近の攻撃活動について新たな詳細を共有します。これには、axios、debug、chalk、typo-crypto の各ライブラリの侵害が、同一の北朝鮮に関連する脅威アクターによって行われたという証拠が含まれます。この脅威アクターは、セキュリティコミュニティでは SAPPHIRE SLEET、STARDUST CHOLLIMA、BlueNoroff、CageyChameleon、Alluring Pisces として追跡されています。また、オープンソースリポジトリを侵害する手法がどのように進化しているか、そしてこうした変化がオープンソースソフトウェアに依存する組織にとってなぜ重要なのか、さらに、お客様がこれらの脅威を検知して対応できるよう、 Amazon Web Services (AWS) がどのような取り組みを行っているかについても説明します。 複数の NPM 侵害の背後にいる単一の北朝鮮関連グループ 2025 年 3 月、北朝鮮に関連する脅威アクターは typo-crypto パッケージを侵害しました。2025 年 9 月には、同じ脅威アクターが debug と chalk の NPM パッケージを侵害しました。2026 年 3 月には、同じ手口が axios パッケージの侵害でも確認されました。axios は、週間ダウンロード数が 1 億回を超える、最も広く使われている JavaScript ライブラリの 1 つです。いずれのケースでも、脅威アクターはパッケージの信頼されたメンテナーに対してソーシャルエンジニアリングを行うことでアクセス権を獲得し、その後、悪意のあるコードを含むソフトウェアアップデートを公開しました。これらのパッケージの最新バージョンを自動的に取得していた組織は、すべて侵害されたアップデートを受け取ったことになります。 axios の侵害については既に公にこの北朝鮮に関連する脅威アクターによるものと特定されていましたが、typo-crypto、debug、chalk の各インシデントについては、これまでこの脅威アクターとの関連が指摘されていませんでした。Amazon Threat Intelligence は、これらのサプライチェーン攻撃活動全体に共通する戦術、技術、手順 (TTP) を特定しました。具体的には、トロイの木馬化された NPM パッケージ、インストール後フック (パッケージのインストール時に自動的に実行されるスクリプト) の利用、そしてコードの再利用です。コマンドアンドコントロール (C2) の痕跡や TTP の分析に基づき、Amazon Threat Intelligence は、これらの攻撃活動が SAPPHIRE SLEET、STARDUST CHOLLIMA、BlueNoroff、CageyChameleon、Alluring Pisces として追跡されている北朝鮮に関連する脅威アクターによるものであると、中程度の確度で評価しています。これらの侵害がこの北朝鮮に関連する脅威アクターと公に結び付けられるのは、今回が初めてです。 Amazon Threat Intelligence は、これを金銭目的の攻撃パターンの一部と評価しています。少数の非常に人気の高いパッケージを侵害することで、このグループは数千もの下流環境に同時にアクセスできる可能性を得ます。金銭目的の脅威アクターにとって、このアプローチは組織を 1 つずつ標的にするよりもはるかに効率的です。 これらのインシデントの累積的な影響は、共有される依存関係を狙うことの効率性を浮き立たせています。Wiz Research の報告によると、debug と chalk のサプライチェーン事件では、わずか 2 時間の間に、クラウド環境の約 10 分の 1 が影響を受けました。 後の攻撃活動の前兆となった小規模な攻撃活動 axios の脅威アクターに関連する痕跡や TTP を定常的に分析していた際、Amazon Threat Intelligence は 2025 年に登録されたドメインとの関連性を発見し、その過去の活動について本格的な調査を行いました。その調査により、同一の北朝鮮に関連する脅威アクターが、2025 年 3 月に typo-crypto の NPM パッケージにトロイの木馬化されたファイルをコミットしていたことが判明しました。この悪意のあるファイル core.js は、typo-crypto リポジトリ内で正規の core-js NPM パッケージになりすましています。 確認されたダウンロード数が限られていることから、Amazon Threat Intelligence は、この攻撃活動が小規模なものであり、2025 年後半から 2026 年にかけて発生した、より大きく注目を集めたサプライチェーン攻撃活動の実験場となった可能性が高いと評価しています。このグループは、公に注目を集めた大規模な攻撃活動よりも 1 年以上前から、サプライチェーンの手法を洗練させていたようです。Amazon Inspector は、より広範なセキュリティコミュニティがこの調査結果を活用できるよう、このマルウェアを Open Source Vulnerabilities (OSV) データベースに報告し、現在は MAL-2026-3400 として追跡されています。 このトロイの木馬化されたファイルは、値 0098273 で始まるハッシュ入力を受け取ると実行されます。トリガーされると、ハードコードされた C2 サーバーから第 2 段階のペイロードをダウンロードし、被害者のオペレーティングシステムに応じて実行します。Windows、macOS、Linux それぞれに合わせた挙動が用意されています。このマルウェアは、ペイロードのローテーションを伴うファイルベースの永続性を実装しており、base64 エンコードされたテキストと 01042025 をキーとする XOR 暗号を組み合わせた多層難読化を使用しています。 関連する侵害の痕跡 (IoC) は以下のとおりです。 ドメイン : npmjs[.]store IP アドレス : 216[.]74[.]123[.]126 NPM パッケージ : typo-crypto (SHA256: 24604384b0e748ada07923630b3d037489e696284a98c4409fb9b6763565571f) トロイの木馬化されたファイル : core.js (SHA256: 2014d09c7ded74d89c885b5f11693865224116f1b25df9330e61fe528f419d73) Amazon Threat Intelligence は、このグループが、その後 axios、debug、chalk に対して行われた、より影響の大きい攻撃活動で使われた手法を、当時実験していたと評価しています。確認されたダウンロード数は少なかったものの、そのトレードクラフト (攻撃者に特徴的な手口や行動様式) は、より人気の高いパッケージへの攻撃で後に確認されたものと一致しています。 攻撃者のトレードクラフトの変化 過去 1 年間、Amazon Threat Intelligence と Amazon Inspector は、脅威アクターがオープンソースライブラリを標的にする際の手法を変化させていることを確認してきました。この変化は重要です。オープンソースパッケージは今なお魅力的な標的であり続けているからです。広く信頼されており、多くの環境で自動的に更新され、新しい貢献者を歓迎するコミュニティによって維持管理されています。以下のパターンは、攻撃者が最新の防御策を回避するために手法を適応させている様子を示しています。いずれの手法も、依存関係が検査される瞬間と、実際に実行される瞬間の間にあるギャップを悪用するように設計されています。1 年前は、悪意のあるパッケージそのものを探すのが主な手法でした。現在では、単体では無害に見えるパッケージ群に分割された、悪意のある挙動を探しています。 パッケージ単位の攻撃から、フラグメント単位の攻撃へ Amazon Inspector は、攻撃者が 1 つの悪意のあるワークフローを、一見ごく普通に見える複数のパッケージに分割するケースが増えていることを確認しています。あるパッケージは、設定ファイルを装った暗号化データを保持します。2 つ目のパッケージは、その復号ロジックを提供します。多くの場合、後から公開される 3 つ目のパッケージが、ペイロードを取得して実行します。 それぞれのパッケージを単独で見ると、無害に見えます。目立つインストールフックもなく、信頼できない入力を評価する明らかな処理もなく、不審に見えるネットワーク呼び出しもありません。悪意のある挙動は、これらのコンポーネントが意図された順序で組み合わせて使われたときにのみ現れます。このアプローチは、実際の依存関係グラフの中でパッケージ同士がどのように相互作用するかを考慮せず、1 つずつパッケージを評価するスキャナーを回避するように設計されています。 信頼の蓄積に投資する、長期にわたる攻撃活動 また、脅威アクターが信頼の蓄積を長期的な視点で捉えている様子も確認しています。明らかに悪意のあるコードを公開してダウンロードを待つのではなく、実際に有用なものを公開し、それを維持管理するのです。こうした攻撃者は、数週間から数か月にわたって、本物のメンテナーのように振る舞います。機能を追加し、バグを修正し、依存するプロジェクトを増やしていきます。 同じ忍耐強さは、人間側の行動にも表れています。場合によっては、目的は新しいパッケージを立ち上げることそのものではなく、既存プロジェクトの貢献者になることです。これは、XZ Utils バックドアから debug、chalk、axios のメンテナー侵害まで一貫して見られる流れです。いずれのケースでも、攻撃者は正当性を、アクセス権が最大になる瞬間に一度だけ使う資産として扱っていました。 パッケージとその挙動の分離 最近の多くのケースでは、公開されているレジストリ上ではパッケージがクリーンに見えても、実際には危険な場合があります。これは、パッケージの実際の挙動が、攻撃者が別の場所で管理しているリソースに依存しているためです。これには、実行時に外部リポジトリから取得される guard や license スクリプト、特定の挙動を制御する設定ファイル、起動時に参照されるリモートエンドポイントなどが含まれます。 これらの外部リソースが無害な状態を保っている限り、コードレビューは通過し、自動スキャンもクリーンな結果を返します。しかし、攻撃者がそのコンテンツを切り替えたり、それまでプレースホルダーを返していたエンドポイントを実際に機能させたりすると、新たなパッケージのリリースを行わなくても、既にインストールされているすべてのコピーが一斉に悪意のあるものになる可能性があります。現時点で悪意のある挙動を示していないパッケージは、設計上安全なパッケージと同じではありません。 基本的な難読化から、本格的な暗号技術へ 以前、攻撃者はミニファイや単層の base64 エンコードといった単純な難読化に依存していましたが、現在ではより強力な暗号技術を使う多段階のペイロードが確認されています。例としては、パスフレーズで保護された AES-GCM 暗号化データ、呼び出しごとに異なるキーを使う RC4 形式の文字列配列、base64 の上に重ねられた XOR 暗号、そして次の段階を暗号化されたフィールドとして保持し、メモリ内でのみ復号するネイティブローダーなどが挙げられます。 これらに共通する設計上の選択は、復号キーがパッケージ自体には決して保存されないという点です。復号キーは実行時のコンテキストから導出されたり、実行時にサーバーから取得されたり、ライセンスキーとして提供されたりします。つまり、ソースへの完全なアクセス権を持つアナリストであっても、静的な方法でペイロードを確実に復号することはできません。第 1 段階は単純な復号器に見えますが、悪意のあるコンテンツは、実際のターゲット上で実際のキーを使って実行されるまで暗号文のままです。 サンドボックスでの実行を回避するペイロード 防御側がクラウドサンドボックスでの自動分析をスケールさせるにつれて、攻撃者は自分たちのコードをより環境認識型にしてきました。ペイロードは、実行に先立って、自分が分析対象になっているかどうかを判断します。実際のパッケージインストールライフサイクルを経た場合にのみ実行されるようにしたり、1 回限りしか使えない環境変数を使ったり、本物の開発環境やビルド環境であることを示すシグナルを確認したりする挙動が確認されています。これには、対話型ターミナル、現実的なユーザー名やホスト名、ドメインへの参加状況、妥当なアップタイム、ローカルのファイル履歴、特定のオペレーティングシステム、そして分析用インフラストラクチャと通常のワークロードを区別するのに役立つクラウドメタデータなどが含まれます。 一部の配信サーバーは、クライアントに応じて提供する内容を変えることもあります。一般的なブラウザらしいリクエストには無害なデコイが返され、実際のペイロードは、マルウェアが使う正確なユーザーエージェントに対してのみ配信されます。その結果、クラウドサンドボックスから「安全」という判定が出たとしても、そのパッケージが本当に安全であることよりも、環境がどれだけ「本物らしく」見えるかを示している場合が多いのです。 生成 AI が攻撃と防御の両方を変えている 生成 AI は、攻撃者が作り出せるものと、防御側が頼れるものの両方を変化させています。攻撃者は今や、大規模に新しいコードやコンテンツを生成できます。これまで、多くの悪意のあるパッケージは、不自然な文章、内容の乏しいドキュメント、明らかなコピー & ペースト、サンプル間で再利用される特徴的な関数など、「見た目がおかしい」ことによって検知されてきました。生成 AI は、こうしたシグナルの多くを消し去ってしまいます。 現在、攻撃者は、説得力のあるドキュメント、妥当性のあるコミット履歴、架空のメンテナーの身元情報を伴う、一貫性があり、自然で、コメントが丁寧に付けられた数千行のコードをバックドアの周りに用意できます。それぞれのバリアントを変異させ、名前を変え、再構成し、再暗号化できるため、一致させるための単一の安定したシグネチャは存在しません。パターンベースの検知は、デプロイごとに一点物のように見えるマルウェアに対して、劣勢に立たされています。 AI はまた、新しい初期アクセスの経路も生み出しています。その 1 つが スロップスクワッティング (slopsquatting) です。これは、AI コーディングアシスタントが幻覚として生成した、実在しないパッケージ名を攻撃者があらかじめ登録しておく手法です。開発者や自律型コーディングエージェントが支援を求め、モデルが自信を持って存在しないパッケージを推奨してしまうと、攻撃者はその名前を事前に登録して待つことができます。その推奨に従った次の人物は、タイプミスをしたわけでも悪意のあるサイトを訪れたわけでもないにもかかわらず、マルウェアを受け取ってしまう可能性があります。実質的に、AI がその悪意のある依存関係を代わりに配信してしまったことになるからです。組織が、人によるレビューを限定的にしか行わずに依存関係をインストールするエージェントへと移行するにつれて、この経路は単なる興味深い事例ではなく、大規模に展開可能な配信チャネルとしての性格を強めていくと考えられます。 最も重要な点として、AI は防御の自動化における前提そのものを変えています。攻撃者はもはや、人間の目を欺くためだけにマルウェアを書いているわけではありません。AI レビューシステムが承認してしまうようなマルウェアを書いているのです。組織がコードのレビューやパッケージのトリアージに AI システムを頼るようになるにつれて、その AI システム自体がアタックサーフェスの一部になります。隠された指示によって AI システムに意図しない行動を取らせる手法である間接プロンプトインジェクションが、AI ベースのコードスキャナーを欺くために悪意のあるパッケージに組み込まれるケースが今後増えていくと予想しています。これらの指示は、ソースコードのコメント、README ファイル、docstring、テストフィクスチャなどに隠され、自動化システムを説得して、悪意のあるコードを安全と判定させたり、特定のファイルをスキップさせたり、分析中に意図しない動作を実行させたりするように作り込まれます。マルウェアが動作するために必要なコンテンツそのものが、それを検査する機械に向けた、もう 1 つの別のメッセージを同時に運んでいる可能性があるのです。 AWS の対応 Amazon Threat Intelligence と Amazon Inspector は、こうしたソフトウェアサプライチェーンリスクの変化する状況にお客様が適応できるよう、投資を続けています。Amazon は、巧妙な脅威アクターによる脅威を積極的に検知・軽減することで、お客様とインターネット全体のセキュリティ保護に貢献することに、引き続き取り組んでいます。Amazon は、Amazon 内の各チーム、業界パートナー、そしてセキュリティコミュニティと連携し、インテリジェンスを共有し、脅威を軽減する取り組みを続けていきます。この攻撃活動を発見した際、Amazon Threat Intelligence は Amazon Inspector と協力し、この悪意のあるパッケージを追跡してその脅威を軽減し、OSV データベースを通じてコミュニティに情報を共有しました。さらに、確認された侵害の痕跡は Amazon GuardDuty にも共有され、お客様にこの活動について警告できるようにしています。 Amazon Inspector は、これらの知見を活用して検知ロジックを改善し、レジストリ全体でのカバレッジを拡大し、この記事で説明したトレードクラフトの変化を反映するシグナルを優先しています。また、パッケージレジストリや Open Source Security Foundation (OpenSSF) といった業界パートナーとも連携し、調査結果を共有しています。 また、Amazon は、オープンソースのメンテナーがプロジェクトをより安全に保護できるようにするための取り組みにも投資しています。2026 年、AWS は Linux Foundation および他の業界のリーダー企業とともに、AI を悪用したサイバー脅威から重要なオープンソースソフトウェアを守るための協力イニシアチブである Akrites の立ち上げに参加しました。AWS はまた、AI を悪用した攻撃からオープンソースエコシステムを守るため、他の組織とともに 1,250 万ドルを共同で投資しています。これらの取り組みは、より大きな理念を反映しています。オープンソースソフトウェアのセキュリティは共有の責任であり、それを守るためには、それに依存する組織による継続的な投資が必要だという理念です。 Amazon の目標は、お客様の環境がオープンソースコンポーネントにどのように依存しているかを理解できるように支援し、不審な挙動を早期に特定し、ソフトウェアサプライチェーンが侵入経路として利用された際に迅速に対応できるようにすることです。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。この役割において、CJ は Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。セキュリティの利点を「最も抵抗の少ない道」にすることで、Amazon の各事業を支えることを使命としています。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO や、直近では AWS CISO など複数の役職を務めた後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 Amazon 入社以前、CJ は連邦捜査局 (FBI) の Cyber Division で、コンピュータおよびネットワーク侵入に関する技術分析を主導していました。また、空軍特別捜査局 (AFOSI) の特別捜査官としても勤務した経験があります。CJ は、現在のセキュリティ業界の基盤となっているとされる、複数のコンピュータ侵入捜査を主導してきました。 CJ は、コンピュータサイエンスと刑事司法の学位を保持しており、SRO GT America の GT2 クラスで現役のレースカードライバーとしても活動しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 11 日に公開された AWS Blog “ AWS Nitro Isolation Engine: Formally verifying the hypervisor in the AWS Nitro System ” を翻訳したものです。 Ali Saidi は AWS の VP 兼 Distinguished Engineer です 何百万ものお客様が、最も機密性の高いワークロードの保護に AWS Nitro System を利用しており、AWS はお客様のデータを保護するイノベーションにおいて業界をリードしています。お客様のデータの安全性と機密性を守ることは AWS の最優先事項であり、データの分離と保護のための専用ハードウェアとソフトウェアへの投資を継続しています。 2017 年、AWS は Nitro System をリリースしました。これは、ゼロオペレーターアクセス (オペレーターがお客様のデータに一切アクセスできない状態) を前提に設計された、初の主要なクラウドプラットフォームです。Nitro System は、次世代のすべての Amazon EC2 インスタンス の基盤となる専用のハードウェアとソフトウェアであり、仮想化、ストレージ、ネットワーキングの機能を専用ハードウェアと最小限のハイパーバイザーにオフロードします。Nitro System では、最も高い権限を持つ AWS オペレーターであっても、認証と監査が行われる管理用 API を通じてのみシステムとやり取りでき、これらの API からお客様のワークロードにアクセスすることはできません。このアーキテクチャはクラウドセキュリティの業界標準を確立し、NCC Group などの第三者機関が独立した立場でこのアプローチの妥当性を確認してきました。 そして今、AWS はさらに水準を高めます。AWS Nitro System の主な役割の 1 つは、インスタンスを互いに分離し、AWS オペレーターからも分離することです。これは 10 年以上にわたり Nitro System アーキテクチャの基盤となってきました。AWS Nitro Isolation Engine は、AWS re:Invent 2025 で初めて発表され、本日 (2026 年 6 月 11 日) よりすべての Graviton5 ベースのインスタンスで一般提供を開始しました。これは Nitro Hypervisor 内の専用コンポーネントであり、この分離を実施し、それを数学的な厳密さで証明する役割を担います。Nitro Isolation Engine は形式的検証を採用しています。形式的検証とは、ハードウェアやソフトウェアが特定のテストケースだけでなく、あらゆる状況で意図したとおりに動作することを数学的に証明する手法です。この徹底的な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなり、数学的に証明されたクラウドセキュリティの新しい標準を確立しました。 AWS Nitro Isolation Engine Nitro System において、AWS Nitro Hypervisor は、すべての仮想マシンについて、権限のないエンティティがお客様のデータを読み取ったり変更したりできないように設計されています。Nitro Isolation Engine は Nitro Hypervisor の専用コンポーネントであり、これらの仮想マシン間の分離を実施します。仮想マシンのメモリ、CPU レジスタの状態、および I/O デバイスへのすべてのアクセスを、Nitro Hypervisor の他の部分に公開される最小限の API セットを通じて仲介します。Nitro Isolation Engine は、お客様のデータへのアクセスを仲介する唯一のシステムコンポーネントです。Nitro Hypervisor の他のコンポーネントは、この制限されたインターフェイスを通じて動作する必要があり、お客様のワークロードに直接アクセスすることはできません。Nitro Isolation Engine のコードベースは最小限に抑えられているため、人による監査が容易になり、バグが混入し得る範囲が減り、その設計と実装に形式的検証を適用することが現実的になっています。 形式的検証 形式的検証は、数学的証明を用いて、システムの形式的モデルの特性が、あり得るすべてのシステム状態とすべての入力において成立することを示します。これは、あり得る状態と入力のうち (場合によっては大規模な) 一部に対してシステムの動作を確認するテストとは対照的です。形式的検証は、従来のテストよりも正確性についてはるかに強い根拠を提供します。Nitro Isolation Engine の場合、分離特性は、あり得るすべてのシステムの動作にわたって保証されます。テストと検証は相互補完的な関係にあります。検証はテストを補強し、テストはまだ検証されていないシステムの領域をカバーして、システムが意図したとおりに動作しているという経験的な裏付けを与えます。 お客様にとって、分離を実施するコードが形式的に検証されていることは、包括的なテストを超える保証となります。テストは引き続き不可欠であり、AWS はテストにおいても高い基準を維持していますが、テストで確認できるのは特定のシナリオに限られます。形式的検証はこれを補完するものであり、テストでカバーされるシナリオだけでなく、あり得るすべてのシナリオにわたって分離特性が数学的に保証されることを意味します。 形式的に検証された特性 Nitro Isolation Engine の形式的検証により、4 つの主要な特性が確立されます。 1. 機密性と完全性 – Nitro Isolation Engine は、ゲスト仮想マシン (VM) の機密性と完全性を維持します。機密性とは、ゲスト VM のプライベートデータが権限のないエンティティによって読み取られないことを意味し、完全性とは、ゲスト VM のプライベートデータが権限のないエンティティによって変更されないことを意味します。 2. 機能的正確性 – 検証されたすべてのハイパーコールは、仕様で定義された期待される動作と一致します。仕様には各ハイパーコールの事前条件と事後条件が記述されており、証明によって、実装がそれらから決して逸脱しないことが立証されます。 3. ランタイムエラーが発生しないこと – コードがランタイムエラーに遭遇することはなく、実装は仕様どおりに動作します。これらの特性の形式的検証を組み合わせることで、検証の対象となるあらゆる一連のイベントに対して Nitro System が分離を維持することが、数学的に厳密に保証されます。現時点では、この検証は、VM の起動、実行、および終了を担う VM のコアライフサイクルのハイパーコールを対象としています。 4. メモリ安全性 – バッファオーバーフロー、NULL ポインタ逆参照、範囲外アクセスなどのメモリ安全性違反が存在しないことを立証します。すべての検証済みソフトウェアと同様に、Nitro Isolation Engine の証明は、Rust コンパイラやハードウェアの正確性などの前提に基づいています。これらの前提、およびエンジニアリングと検証に対する AWS のアプローチについては、Nitro Isolation Engine のホワイトペーパーで詳しく説明されています。 Rust による実装 Nitro Isolation Engine は Rust で実装されています。Rust は、機密性の高いソフトウェアにおけるセキュリティ脆弱性の根本原因となってきた、よくあるプログラミング上の落とし穴を防ぐように設計されたシステムプログラミング言語です。Nitro Isolation Engine に Rust を採用したことで、複数の種類のバグを設計上まとめて排除しています。Rust が適している理由はその型システムにあります。型システムが厳格な所有権規則を適用するため、形式的検証の一部が容易になり、コンパイル時に第一段階の保証が得られます。 まとめ Nitro Isolation Engine は、お客様のデータの機密性を守るという AWS の継続的なコミットメントを体現するものです。そして、これはまだ出発点にすぎません。AWS は、セキュリティに影響を与える Nitro Isolation Engine のすべての主要コンポーネントに形式的検証を拡張し、新機能が導入されてもそれらの証明を維持し続けます。さらに、Nitro Isolation Engine のソースコードと形式的証明を第三者に提供し、独立した検査およびレビューを受けられるようにする予定です。このレベルの透明性は、クラウドプロバイダーが開かれた姿勢、コード品質、形式的検証をどのように示せるかについて、新しい標準を確立するものと考えています。 AWS Nitro System とコンフィデンシャルコンピューティングの詳細については、以下のリソースをご覧ください。 AWS Nitro Isolation Engine Whitepaper コンフィデンシャルコンピューティング： AWS の視点 (2021) AWS Nitro System のコンフィデンシャルコンピューティングに対する第三者評価の獲得 (2023) AWS Nitro Whitepaper AWS re:Invent 2025 presentation – Introducing Nitro Isolation Engine: Transparency through Mathematics 著者について Ali Saidi Ali は Amazon Web Services (AWS) のバイスプレジデント兼 Distinguished Engineer です。ミシガン大学でコンピュータサイエンスおよび工学の博士号を取得しています。2017 年に AWS に入社して以来、AWS Nitro System、AWS Graviton、および幅広い EC2 インスタンスファミリーのポートフォリオの設計と開発に注力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 10 日に公開された Amazon Science Blog “ EC2’s formally verified “isolation engine” provides mathematical assurance of virtual-machine isolation ” を翻訳したものです。 「分離カーネル (separation kernel)」を Nitro セキュリティシステムの他の部分から切り離し、Rust プログラミング言語のサブセットのみを使用して実装したことで、形式的検証が可能になりました。 本日 (2026 年 6 月 10 日)、AWS は Amazon Elastic Compute Cloud (Amazon EC2) の新しい M9g および M9gd インスタンスの一般提供開始を発表しました。これらは、汎用 CPU の最新世代である Graviton5 を搭載した初のインスタンスタイプです。Graviton5 では、コア数が前世代の 96 から 192 に倍増しています。 また、これらは新しい Nitro Isolation Engine を使用する初のインスタンスタイプでもあります。Nitro Isolation Engine は Nitro Hypervisor のコンポーネントであり、その唯一の役割は仮想マシン (VM) を相互に分離することです。この記事では、推論の各ステップが論理法則に従っているかを機械的にチェックするソフトウェアである Isabelle/HOL (高階論理) 定理証明支援系 (proof assistant) を使って、Nitro Isolation Engine が正しく動作し、VM 間の分離を強制することをどのように証明したかを解説します。Nitro Isolation Engine は、商用クラウド環境にデプロイされた初の形式的検証済みハイパーバイザーの重要なコンポーネントです。 Isabelle/HOL によるモデルと証明は、機械的に検証された 330,000 行の数学的記述から成ります。これは、現実的なオペレーティングシステムの検証が実現可能であることを初めて実証した画期的なプロジェクトであり、私たちの取り組みの着想源ともなった seL4 に匹敵する規模です。ただし seL4 とは異なり、Nitro Isolation Engine は商用クラウド環境向けに設計されており、Graviton5 のユーザーに対して常時有効な機能として本番ハードウェア上で提供されます。 2025 年の Amazon re:Invent カンファレンスで行った 講演 では、形式的検証の方法論を紹介しています。また、 ホワイトペーパー では、検証の範囲や前提条件など、結果の重要な側面をより詳しく解説しています。このブログ記事では、形式的検証の取り組みにおける主要な要素と、それらがどのように組み合わさっているかの概要を、わかりやすくご紹介します。 分離カーネルとは何か 「分離カーネル」という用語は、John Rushby 氏が 1981 年に生み出しました。これは、システムを分離されたコンパートメントに分割する最小限の OS コンポーネントを指します。重要なアイデアは、 ポリシー と メカニズム の分離です。分離カーネルは、何を分離するか、リソースをどう割り当てるか、どの VM をスケジュールするかを決定しません。それらの決定は別の場所で行われます。その代わり、分離の強制だけに専念します。この目的の明確さにより、分離カーネルはフル機能の OS カーネルよりもはるかにシンプルに実装できます。 2017 年の導入以来、Nitro Hypervisor は Amazon EC2 における分離の強制を担ってきましたが、同時にビジネスロジック、デバイスドライバー、AWS 固有の機能も処理しています。この複雑さが、正当性の証明を大幅に難しくしています。さらに、Nitro Hypervisor は当初から検証を想定して設計されたものではありませんでした。 ハイパーバイザーの重要な分離ロジックを Nitro Isolation Engine という最小限のコンポーネントに抽出したことで、検証と監査が可能な小さなサイズになり、分離がどのように強制されているかについて、お客様はかつてないレベルの可視性を得られます。また、Nitro Isolation Engine は、形式的検証との相性がより良い言語である Rust で記述しました。 Nitro Hypervisor は引き続きポリシー (VM の作成、リソース割り当て、移行、スケジューリング) を処理しますが、現在は権限が引き下げられており、ゲストの状態に触れるあらゆる操作を Nitro Isolation Engine に依頼する必要があります。Nitro Isolation Engine は、実行前にすべてのリクエストをチェックします。 Nitro Isolation Engine を有効にしたサーバーのシステムアーキテクチャ。 仕様と証明 この取り組みの 2 つの重要な要素は、仕様と証明です。形式仕様はシステムに期待される動作を正確に記述し、証明は実装がその仕様を満たしていることを立証します。 Nitro Isolation Engine に関する定理は、次の 4 種類の性質を対象としています。 機密性と完全性。 許可された情報フローのみが発生します。例えば、ゲストに割り当てられたメモリ領域は、再利用の前に必ずスクラブされます 機能的正当性。 実装は仕様どおりに正確に動作します ランタイムエラーの不在。 Rust における None オプション値の unwrap (プログラムの実行を停止させる誤ったコマンド呼び出し) のようなランタイムエラーが存在しません メモリ安全性。 バッファオーバーフローや NULL ポインタ参照といった問題が存在しません 実際には、後者の 3 つの性質は機能検証の結果としてまとめて扱い、機密性と完全性は別途扱います。これは、それぞれに異なる証明手法を用いるためです。 機能検証 機能検証における重要な要素は次のとおりです。1 つ目は μRust (マイクロ Rust) と呼ばれる Rust 言語のコアサブセットの形式化、2 つ目は仕様を正確に記述するための分離論理 (Separation Logic) を用いた表現力の高い仕様記述言語、3 つ目はプログラムが仕様に対して正しいことを証明するための検証手法である最弱事前条件計算 (weakest-precondition calculus) と独自の証明自動化です。これらはいずれも汎用的な証明インフラストラクチャの一部であり、2025 年に AutoCorrode ライブラリ としてオープンソース化しました。 より詳しく説明すると、μRust は Rust プログラミング言語の制限されたサブセットで、Nitro Isolation Engine を記述するのに十分な表現力を持ちながら、形式的な推論にも適しています。これは、トレイトや動的ディスパッチといった高度な Rust の機能を意図的に除外しているためです。μRust の形式的意味論は、Isabelle/HOL への 浅い埋め込み (shallow embedding) として定義されています。つまり、μRust の意味は、Isabelle/HOL の「ホスト言語」である高階論理を使って定義されます。 μRust プログラムの仕様は、事前条件と事後条件を持つ契約として定義されます。これらは、プログラム実行前後のシステム状態に関する表明です。この契約は「全正当性 (total correctness)」を規定しています。つまり、事前条件を満たすすべての状態において、プログラムは必ず終了し、その結果の状態は事後条件を満たします。この全正当性の条件は、プログラムがメモリ安全であり、ランタイムエラーがないことも意味します。仕様は、低レベルのポインタ操作プログラムについて推論するために設計された論理である 分離論理 を使って記述されています。 分離カーネルは比較的シンプルとはいえ、Nitro Isolation Engine の検証は、形式的検証で可能な範囲の限界に近い取り組みであり、仕様も証明も非常に大規模になります。例えば、以下の仕様は、実行中のゲスト仮想 CPU が自分自身の電源をオンにしようとした場合 (誤ったリクエスト) に何が起こるかを記述したものです。 対象の CPU をオンにするための電源状態関数 PSCI_CPU_ON の仕様。 上記の仕様は複雑ですが、その内容は直感的にはシンプルです。この状況では、Nitro Isolation Engine は、呼び出し元として動作するには当該の仮想 CPU が既にオンになっているはずだと判断し、定義済みのエラーコード AlreadyOn を返します。それ以外のシステム状態はすべて変更されません。仕様の複雑さは、モデリングの深さと、Nitro Isolation Engine の実装においてこの時点に到達するまでに他の複数のエラーチェックが既に実行されているという事実を反映したものです。 μRust プログラムが仕様に対して正しいことを証明するには、標準的な 最弱事前条件計算 を使用します。最弱事前条件計算とは、特定の操作の後のプログラムの状態が、指定された状態の範囲から外れないことを保証できる、最も制約の少ない条件を体系的に特定する方法です。例えば、式 x + y の最弱事前条件は、 x と y の値の加算がオーバーフローしない状態です。そのうえで、契約の事前条件が計算された最弱事前条件を含意することを示すのが証明義務となります。 機密性と完全性 機密性と完全性に関する 1 つ目の重要な要素は、Nitro Isolation Engine の動作を遷移関係として記述する高レベルの仕様です。ここでは、システムの各「高レベル」ステップ (ハイパーコールなど) が 1 つのアトミックな遷移となります。この仕様は、リファインメント (Refinement) と呼ばれる別の証明のアイデアを用いて、機能検証の結果で使用されるより具体的な分離論理の仕様と厳密に結び付けられています。2 つ目の重要な要素は、 非干渉性 (noninterference) という考え方です。 非干渉性とは、機密性と完全性を数学的に厳密なものにするために使用する、識別不能性の保存という考え方です。あるステップの前に 2 つの状態が観測者にとって識別不能であれば、ステップの後も識別不能なままでなければならない、というものです。これが機密性を表す直感的な理由は、そのステップによって観測者が新しい情報を何も得ていないためです。 識別不能性の保存がなぜ機密性を保証するのかは、少しわかりにくいところです。パブリックレジスタとプライベートレジスタを 1 つずつ持つ、2 つのシンプルなマシン A と B を考えてみましょう。プライベートレジスタは隠されているため、観測者は、パブリックレジスタが一致していれば 2 つのマシンを識別不能とみなします。以下の図では、A と B は識別不能です。 機密性違反の例。 ここで、プライベートレジスタの値によって分岐し、パブリックレジスタに 1 を代入するプログラムを実行するとどうなるかを考えてみましょう。結果として得られるマシン A’ と B’ は、パブリックレジスタの値が異なるため、 識別可能 になってしまいます。賢い観測者はこれを利用して元のプライベートレジスタの値を導き出せてしまいます。つまり、識別不能性が保存されないということは、観測者への不正な情報フローが生じていることを意味します。 今後の展開 ここまで、検証の取り組みにおける主要な要素の概要をご紹介しました。この取り組みには、適合性テストや、並行コードに関する推論の扱い方など、他にも多くの側面があります。今後の記事でお伝えできることを楽しみにしています。 著者について Dominic Mulligan Dominic Mulligan は、Amazon の Automated Reasoning Group の principal applied scientist です。 Nathan Chong Nathan Chong は、Amazon の Automated Reasoning Group の principal applied scientist です。並行システムコードの正当性、特にハードウェアとソフトウェアの境界領域を専門としています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 4 月 17 日に公開された Amazon Science Blog “ Isabelle/HOL: The proof assistant behind the Nitro Isolation Engine ” を翻訳したものです。 Isabelle/HOL は、数学的な記述の表現力、自動化、スケーラビリティのバランスによって、世界初の形式的に検証されたクラウドハイパーバイザーを実現しました。 2025 年の Amazon re:Invent カンファレンスにおいて、Amazon Web Services (AWS) は Nitro Isolation Engine (NIE) を発表しました。NIE は、お客様のデータのセキュリティを確保しながら AWS のお客様にリソースを提供する役割を担うソフトウェアモジュールです。あわせて AWS は、 Isabelle/HOL という定理証明支援系 (proof assistant) を使用して、この Isolation Engine の正当性とセキュリティ保証を形式的に検証したことも発表しました。世界初の形式的に検証されたクラウドハイパーバイザーとして、NIE はクラウドセキュリティの新しい標準を打ち立てています。 Isabelle はもともと ケンブリッジ大学 と ミュンヘン工科大学 で開発され、現在は世界中の機関や個人による数多くのコントリビューションを取り込んでいます。 定理証明支援系とは、人間のユーザーが形式的証明を構築するのを支援する自動化ツールです。その対象は、数学の定理からハードウェアやソフトウェアシステムの妥当性まで、あらゆるものに及びます。広く使われている定理証明支援系はいくつかありますが、私たちが Isabelle/HOL を選んだのは、表現力、自動化、証明の読みやすさ、スケーラビリティのバランスが私たちの用途に最も適していたからです。これは具体的にどういうことなのでしょうか? コンピュータによる論理的推論 数学に決まった言語というものはありませんが、プログラミング言語が計算タスクを表現するのと同じように、数学的推論を表現するための言語を作ることができます。そして、プログラミング言語に表現力とパフォーマンスのトレードオフがあるように、数学的言語にも表現力と自動化のしやすさのトレードオフがあります。形式的証明の構築は時間がかかり、極めて根気のいる作業であるため (ボトルの中に船を組み立てる作業に似ています)、自動化は不可欠です。 形式的証明の構築は、ボトルの中に船を組み立てる作業に似ています。厳格な論理的制約の中で、すべての部品を正確に組み立てなければなりません。Isabelle/HOL は、この緻密な作業を可能にするツールを提供します。 最も初歩的な数学的言語はブール論理です。これは、AND、OR、NOT といった論理演算子の世界です。この言語は非常にシンプルであるため、強力な自動ソルバーが存在します。2016 年、カーネギーメロン大学の Marijn Heule 教授 (現在は Amazon Scholar ) とその同僚たちは、未解決の数学的問題であるブール・ピタゴラス数問題をブール論理に符号化し、自動ソルバーを使って、200 テラバイトという 史上最大の証明 を作り上げました。 一階述語論理 と呼ばれるより豊かな数学的言語では、整数などの対象領域について語り、その領域上の関数を定義できます。また、「すべての～について」や「～が存在する」という 量化子 を主張に含めることで、ブール論理を超える表現が可能になります。この種の言語では、「2 より大きいすべての素数は奇数である」といった文を表現できます。また、Lewis Carroll による次の定理を証明することもできます。 ワルツを踊るアヒルはいない。ワルツを断る士官はいない。私の家禽はすべてアヒルである。ゆえに、私の家禽の中に士官はいない。 しかし、ほとんどの人は、プログラミングと同じように型を定義できる、さらに強力な数学的言語を好みます。 高階論理 には、 Haskell などの関数型プログラミング言語に見られるような関数型さえ存在します。高階論理は一階述語論理よりもはるかに豊かで、「 数 1 を含み、加法について閉じているすべての集合は、すべての正の整数を含む 」といった文を表現できます。数学の大部分を表現できるほど豊かであると考えられています。 最も豊かな数学的言語である 依存型理論 では、型が任意の値をパラメータとして取ることさえ可能です。例えば T(i) のように、 i を整数とすることができます。この種の言語で最もよく知られているのは Lean と Rocq です。 一階述語論理には強力な自動定理証明器が存在しますが、高階論理やそれ以上の言語では、完全な自動化は利用できません。これが表現力の代償です。 定理証明支援系 を使えば、ユーザーは部分的な自動化の支援を受けながら対話的に証明を構築でき、独自の証明探索をコーディングすることも可能です。定理証明支援系は、論理法則への厳格な準拠を強制します。これは通常、定理を作成する権限をコードの限られた部分にのみ与えるカーネルアーキテクチャによって実現されます。 定理証明支援系は、非常に大規模になり得る形式的仕様の階層を対話的に開発することもサポートします。例えば、Nitro Isolation Engine (NIE) の検証は、Graviton-5 プロセッサのアーキテクチャの仕様、ハイパーコールの Rust コードとその機能的正当性、そして証明すべきセキュリティ特性の仕様の上に成り立っています。形式的証明を構成する 25 万行の大部分は、これらの仕様が占めています。 高階論理は、密接に関連する 2 つの定理証明支援系である HOL と HOL Light でサポートされており、1990 年代からハードウェア設計、浮動小数点アルゴリズム、純粋数学の検証に使われてきました。AWS のシニアプリンシパルアプライドサイエンティストである John Harrison は HOL Light を開発し、暗号アルゴリズムの最適化バージョンを検証することで、Amazon の Graviton2 チップにおけるデジタル署名の パフォーマンスを最大 94% 向上 させました。このコードは繊細であり、網羅的なテストは 現実的ではありません 。このような重要なソフトウェアをデプロイする前に取り得る手段は、完全な機能的正当性の形式的検証しかありませんでした。しかし、ここで注目したいのは Isabelle/HOL です。 Isabelle/HOL の概要 Isabelle/HOL と他の HOL システム (いずれも高階論理に基づいています) の最も目に見える違いは、その仕様記述言語と証明言語です。ほとんどの定理証明支援系では、ユーザーは証明したいことを記述した後、一種のモグラたたきゲームのように、元のゴールを一連のサブゴールに置き換えるコマンドを次々と続けていきます。Isabelle では (Lean でもある程度は)、証明言語によって望ましい中間ゴールを明示的に書き出すことができるため、証明プロセスをより適切に制御でき、より読みやすい証明ドキュメントが得られます。 オンラインには多くの例 があります。 その他の 注目すべき機能 は以下のとおりです。 Rust 言語のかなりの部分を仕様に埋め込むことを可能にした ユーザー設定可能なパーサー 例えば + に、さまざまな数値型だけでなくマシンワードやその他の適切な文脈でも自然な意味を与える、原則に基づいたオーバーロードのための 型クラス 仕様の階層を定義し、証明の中でさえさまざまな方法で解釈できる軽量なモジュールシステムである ロケール (locales) 単純化と後ろ向き連鎖による証明探索を通じた、強力な 組み込みの自動化 さらに強力な外部の自動化にワンクリックでアクセスできる sledgehammer 実際には偽である主張を特定するための 反例発見ツール 適合性のテストに使用した、実行可能な高階仕様からの コード生成 NIE の検証にあたっては、まず 分離論理 (separation logic) と呼ばれる特化した言語を Isabelle/HOL の上に実装することから始めました。分離論理は、共有リソースを操作するプログラムコードの検証のために設計されたものです。私たちは独自の証明自動化をコーディングし、組み込みの自動化も活用しました。そのため、分離論理を使いつつ、必要に応じて通常の高階論理も使うことができました。Isabelle は、非常に巨大なサブゴールにも対処できるほど堅牢かつ効率的であることがわかりました。市販のラップトップを使って、25 万行の証明を 30 分で実行できたのです。 Isabelle/HOL の応用事例 NIE 以前の Isabelle の応用事例として最も印象的なのは、おそらく広く使われているマイクロカーネルである seL4 の検証 でしょう。この証明も最初に発表された時点では約 25 万行でしたが、現在ではさらに長くなっています。seL4 の開発者たちは、マイクロカーネルの C 実装が抽象的仕様を詳細化したものであることを証明し、コア操作の完全な機能的正当性を実現しました。そして、検証されたコード部分ではバグが一切観測されていません。ただし、未検証の部分や形式化できない一部の前提条件をカバーするために、テストは依然として重要な役割を果たしています。 Isabelle は以下のプロジェクトでも使用されました。 エラーの特定、特にその型システムの 健全性の証明 を目的とした、 WebAssembly 言語のセマンティクスの形式化 Cogent プログラミング言語のための 検証フレームワーク の作成 分散編集に使用される、競合のないレプリケートデータ型 (CRDT) のアルゴリズムの 正当性の証明 純粋数学における 数多くの結果の形式化 抽象レベルでの 暗号プロトコルの検証 Isabelle は無料のオープンソースソフトウェアであり、 ダウンロードして利用 できます。十分なメモリを備えたマシンであれば、主要なオペレーティングシステムすべてで動作します。 著者について Larry Paulson Larry Paulson は、ケンブリッジ大学の計算論理学の名誉教授であり、Amazon Scholar です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本稿は、Japan Digital Design 株式会社 佐藤様による「三菱UFJフィナンシャル・グループの DX を牽引する Japan Digital Design、Aurora DSQL の採用で DB コストを約 87% 削減し、運用負荷ほぼゼロを実現」に関する寄稿記事となります。 こんにちは。Japan Digital Design 株式会社 Technology & Development Division で Technical Project Manager を務めている佐藤です。 Japan Digital Design 株式会社は「金融の新しいあたりまえを創造し人々の成長に貢献する」というミッションのもと、AI・CX・Tech の各領域を組み合わせて三菱UFJフィナンシャル・グループの DX を支援しています。私が所属する Technology & Development Division では、システムの開発・運用からプラットフォーム構築、アーキテクチャ設計までを担っています。 今回、ドキュメント検索システムを新規構築するにあたり、データベースとして  Amazon Aurora DSQL  を採用しました。パートナーを介さず自社開発チームのみで導入を完了し、結果として  Aurora Serverless 比で約 87% のコスト削減と DB 運用負荷ほぼゼロ を実現できています。本記事では、私たちが Aurora DSQL を選定した背景、開発時に直面した課題とその対処、そして導入後に得られた効果をご紹介します。これから DSQL の採用を検討される方の参考になれば幸いです。 対象システム Aurora DSQL は、Japan Digital Design 株式会社が運営するドキュメント検索システムの一部である文書管理データベースとして利用しています。 本システムは、夜間バッチ連携される PDF や Web サイトの情報を取り込み・加工し、ユーザーが取込履歴や取込データ一覧を CSV としてダウンロードできる機能を提供しています。 アーキテクチャ 本システムは 2 つのワークロードで構成されています。 夜間バッチ処理 : 翌朝の Web アプリケーションの開局時間までに全ての取り込み・加工処理を終わらせる必要があるため、AWS Step Functions にて約 1,800 の Amazon ECS タスク（EC2 上で稼働）を並列起動。上流から取り込んだデータを各タスクが処理して、取込結果を Aurora DSQL に書き込む Web アプリケーション : Amazon CloudFront + ALB + Amazon ECS で構成された Web アプリケーションから Aurora DSQL のデータを読み取り、取込データ一覧を CSV として提供 夜間バッチでは、 ピーク時に 1 晩あたり 10 万件超 のファイル／レコードを処理します。バッチはユーザーが利用しない夜間にのみ稼働し、日中の Web アプリケーションからの読み取りとは時間帯が分離されています。 データベース選定の背景 本システムは新規開発だったため、システムの特性に合わせてデータベースをゼロベースで検討できました。私たちがデータベースに求めた要件は以下の 3 点です。 1. 複数環境運用におけるコスト効率 本番・ステージング・開発など複数環境を運用するため、未使用環境にも固定費が発生するインスタンス課金型 DB ではコストが見合わないという課題がありました。 2. スパイクワークロードへの対応 夜間に約 1,800 の ECS タスクが並列書き込みを行うスパイクワークロードへの対応が必要でした。書き込みが夜間に集中する特性上、スケーラブルなアーキテクチャが望ましいと考えていました。 3. 将来のデータ拡大への備え 将来的にデータ量を 10 倍規模に拡大する計画があり、その都度性能調査・性能試験を行う工数は避けたいと考えていました。 Aurora DSQL を選択した理由 他の候補として Aurora Serverless、Aurora、DynamoDB を比較検討し、以下の理由から Aurora DSQL を選択しました。 サーバーレス・従量課金 夜間バッチ時のみコストが発生し、未使用環境の固定費を解消できます。Aurora Serverless では、コールドスタートを避けるために最小 ACU を 0.5 に設定すると環境ごとに固定費が発生しますが、DSQL では利用しない環境にほとんど料金がかかりません。 さらに、Aurora DSQL はアイドル状態が長期間続いても接続時の遅延が極めて小さく抑えられます。Aurora DSQL のクラスターライフサイクルでは、一定期間アイドル状態が続くとリソースを縮小（Idle 状態）し、さらに長期間接続がないとリソースをゼロにスケール（Inactive 状態）しますが、接続するだけで自動的に Active 状態に復帰します。一方、Aurora Serverless の自動一時停止機能（0 ACU へのスケーリング）では、再開時に通常約 15 秒、24 時間以上の一時停止後は 30 秒以上の待機が発生します。Web システムでこの遅延を許容できない場合、最小 ACU を 0.5 以上に維持する（＝固定費が発生する）か、定期的な ping 処理でウォームアップを維持する必要があります。DSQL ではこうした考慮が大幅に軽減され、週に 1 回程度しか動かないようなワークロードでも実用的な応答速度で利用できます。 メンテナンスゼロ パッチ適用やキャパシティ管理が不要で、DB 運用負荷を最小化できます。 SQL 互換性 — DynamoDB ではなく DSQL を選んだ理由 DynamoDB も検討しましたが、テーブル設計の特性と SQL 互換性を重視して Aurora DSQL を選択しました。 本システムは業務システムとしてある程度の複雑性を持ちます。DynamoDB でも構築は可能ですが、アクセスパターンに合わせたテーブル設計が求められる NoSQL のアプローチよりも、やりたいことを素直に SQL で表現できる RDB の方が健全なシステムを構築できると判断しました。開発チームの SQL への習熟度が高く、これまでの RDB の知見をそのまま活かせることも大きな要因でした。 そのうえで、RDB の選択肢の中でコスト面で最も優れていたのが Aurora DSQL でした。 スモールスタートから大規模まで、再設計なしに拡張できる 本システムは社内の利用者が使うためのシステムのため、最大ユーザー数は限定的です。Aurora DSQL は GA 当初、マルチリージョンの大規模スケーラビリティが注目されがちでしたが、私たちはむしろ「小さく始められ、必要に応じて再設計なしに大規模まで成長できる」点を評価しました。完全サーバーレスでゼロまでスケールダウンできるため、間欠的・小規模なワークロードでも無理なく利用でき、その後データ量やスループットが拡大しても、同じデータベースの特性・体験のまま使い続けられます。 Aurora DSQL に向いているワークロードかを見極める 採用にあたっては、本システムのワークロード特性が DSQL の設計思想に合致するかを、以下の 3 つの観点で事前に評価しました。DSQL の導入を検討されている方にも、そのまま使える判断基準だと思います。 判断基準 本システムでの評価 楽観的同時実行制御（OCC）で問題ないか 1 タスク = 1 ドキュメントで各タスクが独立した処理対象を扱い、同一レコードへの同時更新が発生しない。さらに書き込み（夜間バッチ）と読み取り（日中）が同時に発生しない OLAP（分析・集計クエリ）のユースケースがないか データの格納と CSV 出力が主用途で、分析・集計クエリは不要 スパイク型ワークロードか 夜間のみ集中した書き込み処理が発生し、日中の負荷は限定的 この 3 条件を満たすワークロードであれば、Aurora DSQL の特性を最大限に活かせると判断し、採用を決定しました。 開発スケジュール 2025 年 5 月末の Aurora DSQL GA（一般提供開始）を受けて検討を開始し、以下のスケジュールで開発を進めました。 時期 マイルストーン 2025 年 6 月 AWS Summit で Aurora DSQL の実動作を確認し、採用検討を開始 2025 年 8 月 事前検証開始（マイグレーションツールの動作確認等） 2025 年 10 月 設計・開発開始 2026 年 1 月 本番ローンチ GA から約 3 ヶ月で事前検証を経て開発に着手し、約 3 ヶ月の開発期間で本番ローンチを迎えることができました。 開発時の取り組みとハマりどころ 私たちはパートナーを介さず、すべて自社開発で Aurora DSQL を導入しました。AWS 公式ドキュメントを主な技術情報源とし、約 3〜4 ヶ月で習熟に至っています。 PostgreSQL 互換とはいえ DSQL 固有の制約はいくつかあり、開発中に検討した内容、および直面した課題と対処法を共有します。 ORM として SQLAlchemy、マイグレーションツールとして Alembic を採用 DSQL を利用する際の ORM とマイグレーションツールの選定前に、ORM とマイグレーションツールによる各 DB 操作で実施できるもの・できないものを一通り確認していきました。その上で、最終的に SQLAlchemy + Alembic を採用しました。 SQLAlchemy については、AWS が公開している aws-samples リポジトリに利用例が掲載されていることが決め手となりました。 https://github.com/aws-samples/aurora-dsql-samples/tree/main/python/sqlalchemy また、SQLAlchemy、Alembic のいずれも必要に応じて生 SQL の実行をサポートしている点も採用理由の一つでした。 大量データのフェッチとメモリ制限 十数万レコードを CSV 化する要件に対して、当初 LIMIT OFFSET 構文による分割取得を試みたところ、トランザクションあたりのワークメモリ上限 128 MiB の制約に抵触しました。LIMIT OFFSET の仕組み上、不要な OFFSET 分のデータもすべて取得してから最終的な結果を返すためです。 対処法: Primary Key として UUIDv7 や連番など一意で時系列なキーを採用しました。データ取得方法についても Keyset Pagination（WHERE 句で前回取得した ID 以降のデータを抽出）に切り替えることで解決可能です。 トランザクションサイズの制限 Aurora DSQL には、トランザクションブロックで変更できるテーブル行の最大数 3,000 件、書き込みトランザクションで変更されるデータの最大サイズ 10 MiB といった制限があります。 対処法: 設計段階からトランザクションサイズを意識し、処理を分割する方式を採用しました。後から気づくと手戻りが大きいため、設計初期にこの制約を織り込んでおくことをお勧めします。 列の変更対応 DSQL では DROP COLUMN、ALTER COLUMN、NOT NULL カラムの追加といった列定義の変更ができません。変更が必要な場合は、別テーブルを用意してデータを移行する対応が必要でした。 ローカル開発環境の整備 現時点では、Aurora DSQL の制約まで再現したローカルエミュレータは存在しません。PostgreSQL コンテナで代替すると、DSQL 固有の制約にローカルでは気づけないケースがありました。 対処法: 制約に抵触しやすい開発モジュールについては、ローカル環境から直接 DSQL に接続して開発する手法を取り入れました。 振り返って：AWS への早期相談は有効 私たちは自社開発のみで導入を完了しましたが、振り返ると、開発段階から AWS アカウントチームに相談していれば、DSQL 固有の制約やノウハウ（フェッチの取り方など）をより早く把握でき、改善要望も早期に提出できたと感じています。AWS 側でも DSQL の制約に関するナレッジを蓄積しており、開発段階から共有いただける体制があるとのことです。これから導入を検討される方には、開発の早い段階でのアカウントチームへの相談をお勧めします。 導入後の効果 コスト約 87% 削減 Aurora Serverless（コールドスタート回避のため最小 ACU を 0.5 に設定した場合）比で、約 87% のコスト削減を実現しました。多数の環境を運用するエンタープライズ案件では、利用しない環境にほとんど料金がかからない DSQL の料金体系により、環境数に比例したコスト増加を回避できています。稼働していなければ放置しても課金が発生しないため、開発環境の上げ下げを管理するバッチ処理やスクリプトも不要になりました。 運用工数ほぼゼロ キャパシティ管理・パッチ適用が不要となり、DB 運用工数がほぼゼロになりました。他のシステムでは、開発環境の上げ下げのバッチ作成、インスタンスの容量拡張、コールドスタート回避のための ping 処理など、細かな運用タスクがどうしても発生します。DSQL ではこれらがすべて不要です。DB 周りの運用管理にリソースがほぼ発生しなくなり、チームは開発や上流工程のタスクに集中できるようになりました。 小規模なシステム、たとえば週に 1 回程度しか動かないようなワークロードでも、コールドスタートなしで即座に応答できる点は、運用の手間を大きく削減してくれています。 データ 10 倍拡大も設定変更・性能チューニングなし データ量を約 10 倍（現在数十 GB 規模）に拡大した際も、DB 側の設定変更や性能チューニングは一切不要でした。DSQL 側には何も影響がなく、性能劣化も発生していません。今後もデータ格納量やバッチ利用時のスループットは拡大していく見込みですが、性能調査や性能試験に時間を取られることなく、DSQL の自動スケーリングで対応できる見通しです。 Multi-AZ 標準装備 デフォルトで Multi-AZ が担保されており、追加設定なしで AZ 障害耐性を確保できています。 総括すると、 コストと運用負荷の削減が Aurora DSQL 導入の最大のメリット でした。環境数がかなり多い本システムでは、利用しない環境にほとんど料金がかからない DSQL の料金体系がマッチしていました。データ量を約 10 倍に拡大した際も、DB 周りは追加の設定変更なく対応できています。 最後に データ格納量やバッチ利用時のスループットは今後も継続的に拡大していく見込みであり、Aurora DSQL の強みを引き続き有効活用していく方針です。また、三菱UFJフィナンシャル・グループ各社への AI 活用展開に向けて、Amazon Bedrock をはじめとする AWS の AI 関連サービスの拡充にも期待しています。 Aurora DSQL 自体に対しては、クエリログ（監査ログ）の実装や ALTER TABLE/COLUMN 対応による列定義変更の柔軟性向上を期待しています。 本記事が、Aurora DSQL の採用を検討されている方の一助になれば幸いです。 執筆者 佐藤 慎 Japan Digital Design 株式会社 Technology & Development Division テクニカルプロジェクトマネージャ Japan Digital Design 株式会社にて金融機関向けシステム・AI導入案件のプロジェクトマネージャを担当。 Amazon Aurora DSQLをはじめとするクラウドネイティブ技術を活用したプロダクトの本番導入に取り組んでいる。