はじめに AWS Resilience Day は、ワークロードの回復力向上に役立つアーキテクチャのベストプラクティスや AWS サービスを学べる無料のワークショップです。座学とハンズオンを通じて、高可用性ワークロード、災害復旧の設計、エラー修正プロセスの実装について学んでいただけます。重要なアプリケーションの回復力を IT 運用のライフサイクルの中で継続的に改善したい開発者様、運用者様に特に役立つ内容です。 過去の開催状況は以下の Blog をご参照下さい。 【開催報告】AWS Resilience Day in Tokyo を開催しました！！（2024年10月24日） 【開催報告】AWS Resilience Day in Osaka を開催しました！！（2025年3月17日） レジリエンスについて レジリエンス（Resilience）とは、回復力・抵抗力・弾力性を意味する言葉です。IT 分野におけるレジリエンスとは、IT システムが障害や災害によってサービスの停止・劣化に至った際、迅速に正常な状態へ復旧する能力のことです。昨今、FISC 安全対策基準や金融庁ガイドラインでもレジリエンスに関する指針が示されており、その重要性の認知が広がっています。 レジリエンスにおける課題 しかしながら、レジリエンスの重要性は認識しつつも、いざ自社のシステムに実装するとなると何からどう手を付ければよいのか分からない、という声を多く聞きます。AWS Resilience Day では、Resilience Lifecycle というフレームワークに沿って進めます。Resilience を引き上げるには、目標設定、設計と実装、評価とテスト、運用、対応と学習といったライフサイクルの各項目において、各フェーズで求められる施策を確実に実行することが重要です。本ワークショップでは、そのノウハウを座学とハンズオンで段階的に学び、現場ですぐ活かせる構成としています。 ワークショップのご提供 クレディセゾン様では、クレジットカードをはじめ、ファイナンス・デジタル・グローバルへと多角的に事業を展開される中で、複数のサービス基盤として AWS をご活用いただいています。レジリエンスについても前述の通りの課題感をお持ちでした。また、レジリエンス関連の AWS サービスについても理解を深めたいというご意向があり、本ワークショップ開催の運びとなりました。ワークショップは半日の構成で、クレディセゾン様のオフィスにて個社向けに実施しました。 アジェンダ 本セミナーは レジリエンスライフサイクル からピックアップしたトピックを座学のコンテンツとして共有し、 ハンズオン を交互に織り交ぜて進行しました。 形式 セッション 担当 座学 AWS におけるレジリエンス入門、レジリエンスの目標を設定する 中戸川 浩 ハンズオン RPO / RTOの目標設定、高可用性のための設計と実装、評価とテスト 中戸川 浩 座学 レジリエンスの設計と実装 石倉 徹 ハンズオン ディザスタリカバリに備えた設計と実装 石倉 徹 座学 レジリエンスの評価とテスト Yun Suwon ハンズオン AWS Fault Injection Service を用いたレジリエンス評価とテスト Yun Suwon 【座学】AWS におけるレジリエンス入門、レジリエンスの目標を設定する 最初のセッションでは、事例紹介、レジリエンスの基礎、レジリエンスライフサイクルにおける目標設定について説明いたしました。 事例としては、金融業界においてレジリエンスの重要性を理解し、その実践に取り組まれている企業様の事例を紹介しました。 レジリエンスの基礎としては、メンタルモデルおよびレジリエンスの責任共有モデルについてお伝えしました。AWS の責任範囲については、クラウド基盤のレジリエンスを支えるサービスオーナーシップモデルや CoE プロセスなどの取り組みを紹介しました。お客様の責任範囲については、レジリエンスライフサイクルフレームワークを用いた実践方法をご説明しました。 レジリエンスライフサイクルの説明では、はじめの第一歩となる目標設定についてご説明しました。目標がなく測定もできなければ、何をどこまで改善すべきか判断できません。ここではアプリケーションの重要度に応じてどの程度の回復力が必要かを見極め、RTO / RPO として測定可能な形で定めることを推奨しました。RTO / RPO は長く設定するほどシステム障害時のビジネス影響が大きくなり、短くするほどコストと実装難易度が上がるというトレードオフがあります。そのため、エンジニア部門だけで決めるのではなく、ビジネス部門を含めて利用者目線で適切な水準を選ぶことが重要であるという点を強調しました。 中戸川 浩（Technical Account Manager） 【ハンズオン】AWS Resilience Hub を活用した RPO / RTO の設定 AWS 上で稼働するアプリケーションのレジリエンシーを、具体的にどう高めていくか。ハンズオンでは、アプリケーションの回復力を分析・管理・改善できる AWS Resilience Hub の使い方を学びました。 ※ 本ワークショップで利用している AWS Resilience Hub は旧バージョンとなります。現在の最新バージョンは「次世代の AWS Resilience Hub 」です。 AWS Resilience Hub – 目標 RTO / RPO を入力 まずは AWS Resilience Hub にアプリケーションの目標 RTO / RPO を登録します。 【座学】レジリエンスの設計と実装 次のセッションでは、レジリエンスの設計原則を踏まえ、AWS におけるレジリエンスアーキテクチャのベストプラクティスと実装パターンをお伝えしました。 まず AWS の障害分離境界として、AWS サービスにおけるコントロールプレーンとデータプレーンの動作、静的安定性の重要性について、ベストプラクティスとバッドプラクティスの両面を交えて説明いたしました。続いて、セルベースアーキテクチャ、グレースフルデグラデーション、バイモーダル動作など、回復力を高めるアーキテクチャとソフトウェアデザインパターンを具体例とともに解説しました。あわせて、アーキテクチャの選択には要件とコストのトレードオフが伴うことも、重要な観点としてお伝えしました。 石倉 徹（Sr. Solutions Architect） 【ハンズオン】高可用性とディザスタリカバリのための設計と実装 続くハンズオンでは、AWS Resilience Hub を使ってアプリケーションのレジリエンシーを評価しました。 AWS Resilience Hub – レジリエンシーの評価結果（改善前） アプリケーションが目標 RTO / RPO を満たしているかが可視化されます。この時点では、リージョン障害時の RTO / RPO がいずれも目標値（2 時間 / 1 時間）に届かず、Unrecoverable と判定されました。また、判定理由についても確認が可能です。 AWS Resilience Hub – レジリエンシーの評価結果（改善後） AWS Resilience Hub が提示する改善案に沿ってアプリケーションを修正した結果、目標 RTO / RPO を満たす状態になったことを確認できました。 【座学】レジリエンスの評価とテスト 設計と実装の次は、評価とテストです。このセッションでは、カオスエンジニアリングを用いてシステムの弱点・脆弱性・障害モードを特定する方法を紹介しました。 システムが分散し規模が大きくなるほど、起こりうる障害の予測は難しくなります。カオスエンジニアリングは、想定外の状況でも回復力を発揮するアプリケーションを構築するために欠かせない手法です。本番で問題が顕在化する前に、さまざまな障害シナリオへ意図的にさらして潜在的な弱点を洗い出す進め方と、その意義について理解を深めていただきました。 Yun Suwon（Sr. Technical Account Manager） 【ハンズオン】AWS Fault Injection Service を用いたレジリエンス評価とテスト AWS Resilience Hub は、目標 RTO / RPO を満たすアーキテクチャを提案するだけでなく、障害注入実験用の AWS CloudFormation テンプレートも提供します。ここでは AWS Fault Injection Service が利用されます。 AWS Resilience Hub – 障害注入実験のテンプレート Amazon CloudWatch ダッシュボード – バックエンドの応答状況 推奨テンプレートから必要なものを選び、「RDS インスタンスがフェイルオーバーしても、フロントエンドとバックエンドは2分以上オフラインにならない」という仮説を検証しました。 お客様の声 今回はテクノロジーセンターとエンタープライズ開発センター部門の 26 名の方にご参加いただきました。ご参加いただいたお客様からは、座学で学んだ後にハンズオンへ進む構成だったので分かりやすかった、AWS Resilience Hub や AWS Fault Injection Service に実際に触れて理解が深まった、といった声をいただきました。ご参加くださったみなさま、ありがとうございました。 おわりに AWS Resilience Day は、レジリエンスの実践を体系的に学ぶことができるワークショップです。レジリエンスの取り組みを始めたい、チームの理解を底上げしたいといったご要望がございましたら、ぜひ担当のアカウントチームへお気軽にお声がけください。本記事の内容が、みなさまの業務のお役に立てば幸いです。 著者について 中戸川 浩（Nakatogawa Hiroshi） Technical Account Manager テクニカルアカウントマネージャーとして Enterprise Support にご加入頂いている金融業のお客様を担当しております。コスト最適化、運用効率化、セキュリティ改善など AWS の運用面での課題に対しての支援を行っています。

本記事は 2026 年 8 月 28 日 に公開された「 Razor Group’s journey to a modern data lakehouse on AWS 」を翻訳したものです。 Razor Group は、複数のグローバルマーケットプレイスで 250 以上のブランドを展開する、欧州有数の EC アグリゲーターです。売上高は 4 億ドルを超え、ダイナミックプライシングや在庫最適化から広告費の配分、サプライチェーンの制御に至るまで、あらゆる重要な経営判断をデータで支えています。 事業の中心にあるのが、独自プラットフォームの Razor Operating System (ROS) です。9,300 以上のデータパイプラインを通じて月間 3 億 7,000 万件を超える API 呼び出しを処理し、マーケットプレイスのシグナルを大規模な自動アクションへと変換しています。 本記事では、Razor Group が AWS 上に レイクハウスアーキテクチャ を構築し、データプラットフォームを最適化した方法を紹介します。アーキテクチャ上の意思決定、段階的な移行アプローチ、そして測定可能なビジネス成果を取り上げます。ワークロードのパフォーマンス向上、インフラコストの削減、分析基盤でのマルチエンジン対応、いずれを目指す場合でも、本記事の設計図から自社に合わせて応用できる具体的な知見が得られます。 ビジネス課題: 急成長を支えるデータ基盤のスケーリング Razor Group のブランドポートフォリオが急速に拡大するにつれ、データプラットフォームへの要求も大きく高まりました。価格決定、在庫補充、広告入札がほぼリアルタイムで行われる EC のスピードに、分析基盤を追随させる必要があったのです。 Amazon Redshift のプロビジョンドクラスターで構築した既存アーキテクチャは、初期の成長段階では十分に役割を果たしていました。しかしワークロードが多様化しデータ量が急増すると、いくつかの最適化の余地が見えてきました。 図 1: 移行前の Razor Operating System データアーキテクチャ ワークロードの競合 : ETL、変換、分析用の 1,000 を超える SQL モデルが同じコンピューティングリソースを取り合い、処理のピーク時に競合が発生していました。 コストと使用率のミスマッチ : クラスターは 24 時間 365 日稼働し続けていましたが、ワークロードを分析すると、コンピューティング需要の 98% はインタラクティブな分析ではなくバッチ ETL によるものでした。その結果、オフピーク時に大量のアイドル容量が生じていました。 データ鮮度のギャップ : バッチ中心のパイプラインではデータの反映に 4〜6 時間の遅延があり、動きの速いマーケットプレイスの状況にチームが対応しきれませんでした。 スケーリングの制約 : 同時利用ユーザーとパイプラインの複雑さが増すなか、垂直スケーリングだけでは、ワークロードを分離したい、容量を柔軟に調整したいというニーズには応えられませんでした。 いずれも特定のサービスの欠陥ではありません。Razor Group のワークロードの規模と多様性に合わせて、アーキテクチャを進化させる時期に来ていることを示すものでした。 なぜレイクハウスアーキテクチャなのか Razor Group は既存の投資を置き換えるのではなく、モダンなレイクハウスアーキテクチャを採用して ワークロードの配置を最適化する 機会があると捉えました。意思決定を後押しした基本原則は次のとおりです。 オープンテーブルフォーマット : Apache Iceberg は ACID トランザクション、タイムトラベル、スキーマ進化を備えています。データは一度だけ保存され、互換性のあるどのエンジンからも重複なくアクセスできます。 ワークロード単位の柔軟なスケーリング : データを Amazon Simple Storage Service (Amazon S3) に永続化することで、各エンジンが自身のワークロードに合わせて独立してコンピューティングをスケールできます。各エンジンはピーク処理時に起動し、アイドル時にはゼロまでスケールダウンするため、共有インフラを過剰にプロビジョニングせずに済みます。 マルチエンジンの柔軟性 : ワークロードごとに要件は異なります。負荷の高い ETL は分散 Spark 処理、アドホックな探索はサーバーレスクエリ、ビジネスインテリジェンス (BI) ダッシュボードは高性能なウェアハウスエンジンと、それぞれの目的に最適なエンジンを活用できます。 こうした方針により、Razor Group はプラットフォーム全体からアクセスできる、ガバナンスの効いた単一のデータコピーを維持しつつ、 各ワークロードを最適なエンジンに適正配置 できるようになりました。 ソリューションの概要 Razor Group は AWS と協力し、複数の AWS サービスがそれぞれ補完的な役割を担う包括的なレイクハウスアーキテクチャを構築しました。 図 2: AWS 上のエンドツーエンドのレイクハウスアーキテクチャ スケールを見据えた設計: レイクハウスのビジョン Razor Group の新アーキテクチャを支えた核心はシンプルでした。どのエンジンからもクエリできる、単一のオープンフォーマットデータレイクを構築することです。旧モデルでは、ツールごとに独自のデータコピーを保持していました。新モデルでは、Amazon S3 上の単一のオープンフォーマットデータレイクが信頼できる唯一の情報源となり、目的別に用意した複数のコンピューティングエンジンが、その時々のワークロードに応じてそこからデータを読み取ります。 一般にレイクハウスアーキテクチャと呼ばれるこの転換は、データレイクのコスト効率とスケーラビリティに、データウェアハウスのクエリ性能とガバナンスを組み合わせたものです。レイクハウスのオープンテーブルフォーマットである Apache Iceberg は、ACID トランザクション、スキーマ進化、タイムトラベルを提供し、ベンダーロックインもありません。 ストレージとガバナンス: オープンなデータ基盤 Apache Iceberg を用いた Amazon S3 Tables (Amazon S3 の機能) — 主要なストレージレイヤーであり、ACID トランザクション、パーティション進化、タイムトラベルを備えたオープンフォーマットのテーブルを提供します。データは一度だけ保存され、Iceberg 互換のどのエンジンからもアクセスできます。 AWS Glue Data Catalog — すべてのコンピューティングエンジンで一貫したデータ探索を実現する、統合メタデータリポジトリです。 AWS Lake Formation — 列レベル・行レベルのセキュリティによるきめ細かなアクセス制御を提供し、ガバナンスをプラットフォームの成長に合わせてスケールさせます。 コンピューティング: 適切なワークロードに適切なエンジンを Amazon Elastic Compute Cloud (Amazon EC2) 上の Apache Spark — 負荷の高い ETL や変換ワークロード向けの、柔軟な分散コンピューティングです。コスト最適化のために AWS Graviton インスタンスと Amazon EC2 スポットインスタンスを利用します。 Amazon Athena — アドホックな探索や軽量なクエリを、Iceberg テーブルに対して直接実行できるサーバーレス SQL です。管理すべきインフラはありません。 Amazon Redshift Serverless — BI ダッシュボード、Tableau のワークロード、インタラクティブ分析向けの高性能なサービングレイヤーです。Amazon Redshift Serverless は需要に応じて自動的にスケールし、アイドル時には一時停止するため、最も得意とする分析ワークロードでコスト効率を保ちます。 オーケストレーションとオブザーバビリティ Apache Airflow — 依存関係の追跡とサービスレベルアグリーメント (SLA) の監視により、9,300 を超えるデータパイプラインを管理するパイプラインオーケストレーションです。 包括的なオブザーバビリティスタック — すべてのレイヤーにわたるコスト配賦、パイプラインの正常性監視、データ品質チェックを実現します。 注: このアーキテクチャを当初設計した時点では、Amazon Redshift が Iceberg への書き込みに対応していなかったため、セルフマネージドの Spark が唯一実現可能な取り込み経路でした。この制約はすでに解消されています。 Amazon Redshift は現在、Apache Iceberg の DML (UPDATE、DELETE、MERGE) を完全にサポート しており、従来の CREATE/INSERT 機能や AWS Glue の Iceberg マテリアライズドビューを補完します。これにより、読み書きの両方に対応した完全な Iceberg エンジンとなりました。 移行アプローチ Razor Group は、リスクの高い一括切り替えではなく、5 つのステージからなる段階的な移行を採用しました。各ステージはそれ単体で価値を生みながら、次のステージの土台を築きます。移行期間中は Amazon Redshift と Spark の両パイプラインを並行稼働させ、事業継続性を保ちつつ、チームが出力を確実に比較できるようにしました。本番パイプラインが停止したり、ダッシュボードが利用できなくなったりする瞬間は一度もありませんでした。 移行の道のり: 5 つのフェーズ 移行は体系化された 5 つのフェーズで進み、各フェーズが前段を土台としつつ、次に進む前に段階的な価値を提供しました。 フェーズ 1: レイクハウスの基盤を確立する クエリを 1 つ移行する前に、Razor Group は 3 つの問いに答える必要がありました。データはどこに置くのか、どう管理するのか、そしてどうクエリするのか、という問いです。 セルフマネージドの Iceberg ではなく S3 Tables を選んだ理由 Razor Group はすでに、テーブルフォーマットとして Apache Iceberg の採用を決めていました。オープンでエンジンに依存せず、ACID トランザクションとタイムトラベルを備えているためです。残る問いは、標準の S3 バケット上で Iceberg をセルフマネージドで運用するか、Amazon S3 Tables を使うかでした。 セルフマネージドの Iceberg は強力ですが、運用コストがかさみます。スモールファイルの増殖を防ぐためにコンパクションジョブを回す担当者が必要です。メタデータの肥大化がクエリプランニングを劣化させる前に、古いスナップショットを期限切れにする担当者も必要です。書き込みが中断した後に残る孤立したデータファイルを片付ける担当者も要ります。40 以上のスキーマにまたがる 700 以上のモデルが稼働し、その多くが 1 日に複数回マテリアライズされる環境では、こうした保守負荷はプラットフォームの成長とともに縮小するどころか拡大してしまいます。 S3 Tables は、こうした一連の作業をまるごと不要にしました。コンパクション、スナップショット管理、参照されないファイルの削除が、継続的かつ自動的に実行されます。統合された Iceberg REST Catalog API により、Spark、Trino、Athena、Amazon Redshift、Flink など互換性のあるエンジンは、個別のメタストアを維持することなくテーブルを検出してクエリできます。探索は AWS Glue Data Catalog を通じて統一されており、同カタログは現在、Iceberg REST Catalog プロトコルをアクセスインターフェイスとして公開しています。テーブルがファーストクラスの AWS リソースであるため、アクセス制御、暗号化、ライフサイクルポリシーは、ファイルパスの命名規則の上に複雑な S3 バケットポリシーを重ねるのではなく、テーブルレベルで機能します。 オープンテーブルフォーマットの保守をセルフマネージドで抱え込みたくない企業にとって、これが決め手となりました。 AWS Glue Data Catalog は、すべての階層にわたる統合メタデータ探索を提供します。Lake Formation は列レベル・テーブルレベルのアクセス制御を担い、最小権限の原則に従う AWS Identity and Access Management (IAM) ロールと、完全な監査証跡のために有効化した AWS CloudTrail を組み合わせています。 クエリプロトコルの選択 アーキテクチャの再設計前、Amazon Redshift クラスターの処理は 98% が ETL で、アナリストの SELECT クエリはコンピューティング時間のごく一部にすぎませんでした。置き換えるエンジンには、負荷の高いバッチ変換と、インタラクティブなアドホッククエリの両方に対応できることが求められました。 従来の Spark (spark-submit) はバッチ ETL をうまく処理しますが、クライアントとクラスターが密結合になります。ジョブごとにドライバー JAR のパッケージング、クラスパスの管理、クラスター内部からの投入が必要です。日々膨大なデータ量を処理する 200 以上の本番用有向非巡回グラフ (DAG) を運用するプラットフォームにとって、こうした運用上の摩擦は受け入れがたいものでした。 Spark Connect は、Spark 3.4 で導入された gRPC ベースのクライアント/サーバープロトコルであり、この密結合の問題を完全に解決しました。クラスターは永続的な gRPC エンドポイントを稼働させます。クライアントはリモートで接続し、クエリをネットワーク越しに投入します。Airflow のオペレーターはシンクライアントになります。セッションを開き、SQL を投入して結果を受け取り、成功と失敗がそのままタスクの状態に対応します。ドライバー JAR もポーリングも不要です。パイプラインのオーケストレーター、ウェブアプリケーション、開発者のノートブックなど複数の利用者が、いずれもローカルに Spark をインストールすることなく 1 つのクラスターを共有できます。 Spark Connect のデプロイ Razor Group は、Amazon EC2 上にセルフホストの Spark クラスターをデプロイしました。オンデマンドの AWS Graviton リーダーノード、約 70% のコスト削減となるスポットワーカー、そして内部の Network Load Balancer を通じて公開した Spark Connect エンドポイントで構成されています。カスタムの Amazon マシンイメージ (AMI) に Spark、Iceberg、S3 Tables の一式を組み込んであるため、プライベートサブネットのノードは実行時にインターネットへアクセスしなくても必要なものをすべて備えています。 このフェーズ自体は直ちにビジネス価値を生むものではありませんでしたが、その後のすべてを可能にしました。 フェーズ 2: データ取り込みを移行する Razor Group の取り込みレイヤーは、Amazon Selling Partner API、Seller Central ポータル、NetSuite ERP、そして独自のウェブスクレイパーからデータを取得します。旧アーキテクチャでは、これらすべてが COPY コマンドを通じて Amazon Redshift に取り込まれていました。そのためデータ鮮度はバッチジョブのスケジュールに左右され、分析クエリを処理するのと同じクラスター上でリソースを奪い合っていました。 Razor Group は取り込みパイプラインを、Apache Airflow がオーケストレーションする AWS Lambda 関数へ移行し、データを Iceberg 形式で S3 Tables に直接書き込むようにしました。スケジュール駆動からイベント駆動への転換により、鮮度が大幅に向上しました。Lambda 関数は処理すべきデータがあるときにのみ起動し、Airflow のセンサーは新しいデータが到着した瞬間に下流の変換をトリガーします。その結果、1 時間ごとの固定的なバッチウィンドウは、分単位で測れるデータ鮮度に置き換わりました。 オーケストレーションレイヤーは、90 以上のフローにまたがる 200 以上の DAG を管理し、数十のソースからのデータを大規模に処理します。移行にあたっては、書き込み先を Amazon Redshift の COPY から Iceberg 書き込みへ配線し直す必要がありましたが、オーケストレーションのロジック自体は最小限の変更で引き継げました。 このフェーズだけで、取り込みにおける常時稼働クラスターへの依存を断ち切り、コンピューティングコストを約 40% 削減しました。 フェーズ 3: 処理パイプラインを変換する フェーズ 3 は技術的に最も難易度が高く、Razor Group が最も多くを学んだフェーズでもありました。チームは 1,000 以上の SQL モデルを Amazon Redshift から Apache Spark へ移行し、40 以上のスキーマにまたがる依存関係の連鎖を段階的にたどりながら進めました。モデルはメダリオン構造に沿って移行しました。取り込んだ生データの Bronze、クレンジングして整形したデータの Silver、そしてビジネスで即利用できる集計データの Gold です。 Razor Group は自動変換ツールと検証フレームワークを構築し、Amazon Redshift と Spark の出力を並行して実行して、何かを廃止する前に結果を 1 行ずつ比較しました。いくつかの種類の変換は、自動化で対応できる限界を試すものでした。 ウィンドウ関数 : Amazon Redshift の QUALIFY 句には Spark に相当するものがありません。使用箇所ごとに明示的な行番号付けを伴うサブクエリでラップする必要があり、在庫スキーマだけでも数十のモデルに影響しました。 JSON のシリアライズ : 最も時間を要したカテゴリです。Amazon Redshift で JSON STRING として格納されていた複雑な列は、Spark では手書きの STRUCT 定義を伴う from_json() が必要でした。広告、注文、取引の各パイプラインにわたるネストされたペイロード列はいずれもスキーマの調査を要し、近道はありませんでした。 関数の方言 : NVL から COALESCE、DATEADD からインターバル演算、LISTAGG から ARRAY_JOIN(COLLECT_LIST()) など、20 を超える関数レベルの変換がありました。 スナップショットの排除 : 最大の隠れたコストでした。ある時点の状態を保存するためだけに 1 日に複数回実行されるテーブル全体のコピーは、週あたり 35 時間を超える Amazon Redshift のコンピューティングを消費していました。Iceberg のネイティブなタイムトラベルにより、これらは一夜にしてコストゼロの操作になりました。 1,000 以上の SQL モデルを移行する際、機械的な構文変換は自動化ツールでうまく処理できます。しかしモデルの約 30% は人間の判断を必要としました。複雑な JSON ペイロード、深くネストされたウィンドウ関数、スキーマをまたぐスナップショット依存を含むモデルです。これらのモデルが移行工数の 70% を占めました。 Razor Group は、この作業を加速するために Claude を活用した構造化された移行ワークフローを構築しました。ソース SQL を読み取り、依存関係を特定し、構文を変換し、不足しているベーステーブルを解決し、JSON パースを追加し、出力を検証してレイクハウスに書き込む、という流れです。このシステムは単に SQL を変換するだけではありませんでした。スキーマのコンテキストを適用し、モデル間の依存関係をたどり、エンジニアが手作業で見つけるには何時間もかかるようなエッジケースを検出しました。数年がかりになりかねなかった取り組みが、数週間で測れる体系的かつ再現可能なプロセスになったのです。このアプローチは移行のスピードを根本から変えました。 フェーズ 4: サービングレイヤーを統一する データが Iceberg テーブルを流れるようになったことで、Razor Group はサービングレイヤーを 1 つに集約しました。エンドユーザーは Amazon Redshift Serverless を通じて Gold レイヤーの Iceberg テーブルにクエリを実行し、社内の探索や機械学習 (ML) のワークロードは Spark Connect を通じて同じテーブルを読み取ります。利用者ごとに別々のデータコピー、マテリアライズドビュー、抽出ジョブを維持する必要はなくなりました。 これがオープンテーブルフォーマットの戦略的な成果です。S3 上の Iceberg テーブルはエンジンに依存しません。今日はバッチ変換に Spark、明日はインタラクティブクエリに Trino、来四半期はストリーミングに Flink といった具合です。Iceberg を扱えるエンジンであれば、変換や移行なしにデータを読み取れます。Razor Group は単一ベンダーの SQL 方言に縛られていた状態から、ストレージレイヤーに手を加えることなく新しいエンジンを採用できる自由を手に入れました。 フェーズ 5: 運用体制とオブザーバビリティを整える 最後のフェーズで、レイクハウスを本番グレードに仕上げました。Razor Group は、すべてのパイプラインコンポーネントからメトリクス、トレース、ログを集約し、統一されたビューにまとめる包括的なオブザーバビリティスタックを構築しました。このビューは、一元的なログ検索、異常検知、そしてデータプラットフォーム全体にわたる障害を関連付ける自動アラートを支えます。 このオブザーバビリティレイヤーは、単に可視性を提供する以上のものでした。チームに自信をもたらしたのです。1 日に何千ものパイプライン実行を回しているとき、何かが壊れたら数分以内に、それが何によって引き起こされ、どの下流の利用者が影響を受けるのかを把握する必要があります。それが、後手に回る火消しと、先手を打つ運用との違いです。 パイプラインのオーケストレーションは 3 つのパターンに集約されました。日次パイプライン (取り込みからマテリアライズ、エクスポート、AI エージェントによる分析まで)、15 分ごとにポーリングする運用ワーカー、そして週次のスクレイパージョブです。 切り替えは設計上ゼロダウンタイムでした。2 週間にわたって両方のスケジューラーを並行稼働させ、旧アーキテクチャのシステムを無効化する前に、すべてのパイプラインが同一の出力を生成することを自動比較チェックで検証しました。 成果とビジネスインパクト レイクハウスアーキテクチャは、あらゆる面で測定可能な改善をもたらしました。 指標 移行前 移行後 改善 P95 クエリ実行時間 180 秒 63 秒 65% 高速化 インフラコスト 常時稼働のプロビジョンドクラスター 柔軟でワークロード最適化された構成 63% 削減 データ鮮度 4〜6 時間のバッチサイクル イベント駆動のパイプライン 15 分の鮮度 同時処理容量 クラスターサイズによる制約 柔軟で独立したスケーリング 無制限 エンジンの柔軟性 単一エンジン マルチエンジン (Spark、Athena、Amazon Redshift) オープンフォーマットによる移植性 63% の削減は、レイクハウス稼働後のコスト (2026 年 1〜3 月) と、再設計前のコスト (直前の 3 か月間にあたる 2025 年 10〜12 月) を比較したものです。この数値は、両アーキテクチャのコンピューティングとストレージを含む、同一条件で比較したインフラの総合値です。移行前の列は Amazon Redshift クラスターのコンピューティングとマネージドストレージを対象としています。移行後の列は Amazon EC2 (オンデマンドとスポットの両方の Spark ワーカー)、AWS Lambda、AWS Glue、Amazon Athena、Amazon Redshift Serverless、S3 Tables のストレージを対象としています。データ転送や付随サービスは、2 つの期間で大きな差がなかったため除外しています。ワークロードの構成 (パイプライン数、モデル数、エンドユーザーのクエリ量) は、2 つの期間でおおむね同等に保ちました。 学んだこと ツールではなく意思決定のループから始め、ウェアハウスを置き換える前に自社のワークロードを把握する。 移行全体で最も価値のあった活動は、コードを 1 行書くことではありませんでした。アーキテクチャ上の意思決定を下す前に実施した、Amazon Redshift のワークロード分析です。コンピューティングの 98% が ETL で、アナリストのクエリに回っているのはごくわずかだと判明したことが、オンデマンドの Spark への移行を裏付けました。同時に、ほとんど存在しないインタラクティブワークロードのために置き換え先のインフラを過剰にプロビジョニングすることも防げました。アーキテクチャの意思決定は常に、価格精度、プロモーションへの即応性、日中の損益の可視性といった、事業の根幹にある要件にさかのぼるべきです。テクノロジーではなく、そこから始めましょう。 複数のコンピューティングエンジンを前提に設計し、ワークロードごとに適切なエンジンを選ぶ。 単一エンジンのアーキテクチャを運用して得られた最も明確な教訓は、それによって何を手放すことになるかということです。BI、取り込み、バックフィル、ML のすべてを 1 つのコンピューティングレイヤーに縛りつけるのは避けましょう。それぞれコストとパフォーマンスの特性が根本的に異なるからです。いったん移行してしまえば、Iceberg、Spark、S3 Tables は最初から問題なく連携します。難しいのはテクノロジーではありません。難しいのは、40 以上のスキーマにまたがる 1,000 以上のモデルを対応付け、200 以上の DAG を通じて依存関係をたどり、ある列が実は 2 つのエンジン間で密かに異なる形でシリアライズされた JSON 文字列だったと突き止めることです。移行は、エンジニアリングであると同時に発掘プロジェクトでもあります。 変換は自動化しつつ、残る 30% を見込んでおく。 自動化ツールは機械的な構文変換をうまく処理するので、まず手を伸ばすべきツールです。しかし複雑な JSON ペイロード、深くネストされたウィンドウ関数、スキーマをまたぐスナップショット依存を含むモデルは人間の判断を要し、その作業は圧縮できません。当社のモデルの約 30% が大幅な手作業を必要とし、それらが移行工数全体の 70% を占めました。最初から正直に見込んでおきましょう。 オブザーバビリティにはコスト配賦を含めなければならない。そして思わぬコストの落とし穴に注意する。 スナップショット操作は最大の想定外でした。ある時点の状態を保存するために 1 日に複数回実行されるテーブル全体のコピーが、週 35 時間を超えるコンピューティングを消費していたのですが、「スナップショットとはそういうもの」だと誰も疑いませんでした。Iceberg のタイムトラベル機能がそのコストを解消し、この 1 つの機能だけで移行のかなりの部分が正当化できました。より広く言えば、見えないものは最適化できないので、クエリレベルの使用状況を追跡し、チームや機能に配賦しましょう。コストのオブザーバビリティはあれば嬉しいものではなく、基盤そのものです。 ガバナンスは任意ではない。基盤に組み込み、初日からステークホルダーの足並みをそろえる。 カタログとアクセス制御は、採用を拡大した後ではなく、その前に整える必要があります。同じ原則が人にも当てはまります。移行はインフラプロジェクトではなく、部門横断のプログラムです。当社の 2 週間の並行稼働は、行レベルの検証ではまったく捉えられなかったエッジケースを検出しました。Amazon Redshift と Spark の間のタイムゾーンの違い、同時書き込み時のパーティションプルーニングの挙動、非決定的なウィンドウ関数における微妙な並び順の違いです。並行稼働は単なるセーフティネットではありませんでした。移行の真価が実証された場そのものでした。適切なステークホルダーが最初から関与し、足並みをそろえていなければ、何ひとつ成り立ちません。 まとめ Razor Group の道のりは、データアーキテクチャの最適化を目指す組織に貴重な教訓を提供します。 まずワークロードの構成を分析する。 コンピューティングの 98% がインタラクティブクエリではなく ETL だと理解できたことが、負荷の高い処理を柔軟な Spark にオフロードしつつ、最も得意とするインタラクティブ分析には Amazon Redshift Serverless を残すという判断を導きました。 マルチエンジンの柔軟性を前提に設計する。 Apache Iceberg のようなオープンテーブルフォーマットは、単一エンジンを選ぶ必要をなくします。各ワークロードは、アクセスパターン、コスト特性、パフォーマンス要件に最も適したエンジンで動きます。 移行を自動化しつつ、複雑さを見込む。 自動トランスパイルは SQL モデルの 70% を処理しましたが、残る 30% がエンジニアリング工数の 70% を占めました。それを踏まえて計画しましょう。 オブザーバビリティにはコスト配賦を含める。 ワークロード単位のコストが見えなければ、最適化は当て推量になります。Razor Group は、Iceberg のスナップショット保守だけで週 35 時間を超えるコンピューティングを消費していたことを突き止めました。オブザーバビリティが表面化させ、自動化が解決した隠れたコストです。 ガバナンスを基盤に組み込む。 AWS Lake Formation と AWS Glue Data Catalog は、移行後に後付けするのではなく、初日からきめ細かなアクセス制御を提供しました。 並行システムで検証する。 新旧アーキテクチャの 2 週間の並行稼働は、自動テストが見逃したエッジケースを検出し、自信をもった本番切り替えを支えました。 今後の展望 レイクハウスの基盤が整ったことで、Razor Group は AWS 上の統一されたオープンでガバナンスの効いたデータプラットフォームを原動力に、リアルタイムの価格モデルから AI 主導の在庫最適化まで、イノベーションを加速できる体制になりました。 同社の変革は、モダンなデータアーキテクチャがサービスの二者択一ではないことを示しています。それは 各ワークロードを最もパフォーマンスの高い場所に配置し 、オープンフォーマットでサイロを解消し、ビジネスの成長に応じて各レイヤーを独立してスケールさせることなのです。 他の組織が AWS 上で同様のレイクハウスアーキテクチャをどう実装しているかについては、 How BigBasket uses the Iceberg-based lakehouse architecture on AWS to power lightning-fast grocery delivery across India を参照してください。 著者について Yaswanth Kothainti Yaswanth は、売上高 4 億ドル超の EC 企業 Razor Group で VP of Data Engineering & Platform を務めています。同社のデータプラットフォームをゼロから構築し、65 名からなるグローバルなエンジニアリング組織を率いています。専門はエンタープライズデータプラットフォーム、データガバナンス、FinOps、エージェント型 AI システムで、複雑なプラットフォーム投資を測定可能なビジネス成果へと結びつけてきた実績があります。 Shubham Purwar Shubham は、AWS の Analytics Specialist Solutions Architect です。スケーラブルでセキュア、かつ高性能な分析ソリューションを AWS 上で設計・実装し、組織がデータの潜在能力を最大限に引き出せるよう支援しています。余暇には家族と過ごしたり、世界各地を旅したりするのが好きです。 Ravi Kompella Ravi は Principal Analytics Specialist です。インドの多様な業界において、スタートアップや SaaS プロバイダーを含むあらゆるセグメントを対象に、モダンなデータアーキテクチャ、エンタープライズデータレイクハウス、リアルタイムデータシステムの採用を推進してきた経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 「スキーマ変更は利用の少ない深夜に、フェイルオーバー試験は休日に。」データベースを止めないための調整に、エンジニアの時間が少しずつ削られていく。そんな場面に直面することはありませんか。9/14(月) 14:00 から麻布台ヒルズで開催する 「Amazon Aurora DSQL Day Tokyo」 では、こうした運用調整からエンジニアを解放する分散 SQL データベース Amazon Aurora DSQL について、来日するプロダクトマネージャーと日本のスペシャリスト SA が、技術詳細から適用判断のポイントまでを解説します。IVRy 様、MIXI 様、東京海上日動システムズ様など、実際に本番システムで採用されたお客様の生の知見を聞ける現地開催イベントです。深夜や休日の調整にあてていた時間をサービス開発に使えるようになるための第一歩としてご活用いただけます。参加には事前登録が必要ですので、ぜひ上記のリンクからお申し込みください。 それでは、先週の主なアップデートについて振り返っていきましょう！ 2026年8月24日週の主要なアップデート 8/24(月) Amazon Connect Customer がエージェントの音声およびチャット会話からの情報抽出に対応 Amazon Connect Customer (旧 Amazon Connect) の会話分析に、生成 AI による情報抽出機能が追加されました。音声およびチャットの会話から、口座番号や予約 ID などの発話どおりの値 (verbatim) と、問い合わせ理由や約束したネクストステップなどの推論による値 (derived) を構造化データとして自動取得できます。抽出は機密情報のマスキング前の生データに対して実行されるため、録音や文字起こしから機密情報を秘匿しつつ、業務に必要な値だけを取り出せます。抽出結果は After Contact Work 中のエージェント画面、コンタクト検索、API、Kinesis Data Streams、S3 出力ファイルで利用でき、メール送信、タスク作成、ケース作成などのルールアクションにも直接渡せます。東京リージョンを含む対応リージョンで利用できます。 Amazon EKS がクラスターあたり複数の外部 OIDC ID プロバイダーをサポート Amazon EKS が、1 つのクラスターに複数の外部 OpenID Connect (OIDC) ID プロバイダーを関連付けられるようになりました。Kubernetes 1.32 以降のクラスターでは最大 10 個のプロバイダーを関連付けられます。従業員、契約社員、CI/CD システムなど、認証基盤が分かれているユーザー層をそれぞれのプロバイダーで直接認証できるため、Dex や Keycloak のような中間 ID ブローカーの運用や、単一プロバイダーへのユーザー統合が不要になります。追加料金はなく、Amazon EKS が利用可能なすべての AWS リージョンで利用できます。 Amazon ECS がエージェント接続に障害のあるコンテナインスタンスを自動検出・修復 Amazon ECS が、コンテナインスタンス全体のエージェント接続を継続的にモニタリングし、エージェント接続に障害のあるコンテナインスタンスを自動的に検出、修復するようになりました。これにより、検出されないまま残るワークロード障害を減らし、アプリケーションの可用性を高められます。EBS ボリューム劣化、ホストの熱イベント、ネットワーク障害などで ECS エージェントとコントロールプレーン間の接続が切断されると、新しいヘルスチェックタイプ AGENT_CONNECTIVITY として検出されます。検出後の動作はコンピューティングオプションによって異なり、AWS Fargate と Amazon ECS Managed Instances では、タスクのドレイン、代替キャパシティの起動、障害インスタンスの登録解除までを ECS が自動で行います。一方 ECS on EC2 では自動修復は行われず、EventBridge に配信されるヘルス変更イベントをもとに、ユーザー自身がインスタンス置き換えワークフローを構築します。 8/25(火) AWS Lambda 関数が IAM リソースベースポリシーをフルサポート AWS Lambda 関数が、IAM リソースベースポリシーをフルサポートしました。これにより、プラットフォーム管理者やセキュリティチームは、IAM の機能をフルに活用してきめ細かなアクセス許可を定義できるようになります。従来は AddPermission API でプリンシパルごとに Allow ステートメントを 1 つずつ追加する方式で、使える条件キーも aws:SourceArn、aws:SourceAccount、aws:PrincipalOrgID の 3 種類に限られており、マルチアカウント環境などでの大規模な権限管理には柔軟性が不足していました。今回追加された PutResourcePolicy API では、複数プリンシパル・複数アクションを 1 つのポリシードキュメントにまとめられるほか、IAM 条件キーをフルに活用して送信元 IP やプリンシパルタグに基づくアクセス制限が可能になります。 AWS Batch が Amazon ECS Managed Instances をサポート AWS Batch のコンピューティング環境として Amazon ECS Managed Instances (ECS MI) を選択できるようになり、GPU を使うジョブや計算負荷の高いバッチワークロードを AWS 管理のインフラで実行できるようになりました。これまで GPU を使うジョブや 32 vCPU / 244 GiB を超えるジョブは EC2 コンピューティング環境が必要で、AMI の更新やインスタンスの管理を利用者側で担う必要がありましたが、本アップデートによりこうしたインフラ管理なしで GPU インスタンスを利用できます。料金は EC2 インスタンス料金に加えてインスタンスタイプごとの管理料金が発生します。AWS Batch が利用可能なすべての AWS リージョンでサポートされます。 8/26(水) AWS Backup が Amazon DocumentDB のクロスリージョンバックアップコピーと論理的エアギャップボールトを 9 リージョンで追加サポート AWS Backup が、Amazon DocumentDB バックアップのクロスリージョンコピーと論理的エアギャップボールト (Logically Air-gapped Vault) への保管を、香港、ジャカルタ、メルボルン、大阪、スペイン、ストックホルム、チューリッヒ、ケープタウン、テルアビブの 9 リージョンで追加サポートしました。バックアッププランまたはオンデマンドコピージョブにより、これらのリージョンとの間で DocumentDB バックアップをコピーできます。また、論理的エアギャップボールトはデフォルトでロックされた不変ストレージであり、AWS RAM でボールトを共有して別アカウントから復旧できるほか、アカウント侵害時にはマルチパーティ承認 (Multi-party approval) でボールトへのアクセスを保護できます。日本のユーザーにとっては大阪リージョンが対象に含まれた点が重要で、東京 – 大阪間の国内完結型 DR 構成を DocumentDB でも構築できます。 Mountpoint for Amazon S3 がメモリ使用量の制御機能を追加 Mountpoint for Amazon S3 の v1.24.0 で、メモリ使用量を制御する機能が追加されました。新しい –memory-target オプションでメモリ使用量の目標値を MiB 単位で指定できるほか、指定しない場合は実行環境 (システム全体または cgroup によるコンテナのメモリ上限) を自動検出し、その 95% をデフォルト値として使用します。これまで Mountpoint はプリフェッチなどの動作によりメモリ使用量が使用パターンに応じて増加し、ML トレーニングや分析ワークロードなどメモリを多く使うアプリケーションと同居させると、パフォーマンスや安定性の問題を引き起こすことがありました。今回の機能により、Amazon EKS などメモリ割り当てが厳格なコンテナ環境でも Mountpoint を安定して運用できます。 Amazon Connect Customer がエージェントスケジュールで計画外シュリンケージをサポート Amazon Connect Customer のエージェントスケジューリング機能で、計画外シュリンケージを入力できるようになりました。遅刻ログインや急な病欠など、事前にスケジュールへ組み込めないエージェントの不在率の想定をアップロードすると、スケジュール済みヘッドカウント、ネットスタッフィング、予測サービスレベルなどのメトリクスが即座に再計算されます。WFM 管理者はスケジュール上の人員不足を事前に把握し、対策を打てるようになります。 8/27(木) Amazon Aurora DSQL が外部キー制約をサポート Amazon Aurora DSQL で、新規テーブルおよび既存テーブルに外部キー制約 (FOREIGN KEY) を定義できるようになりました。これまでアプリケーション側で実装する必要があった参照整合性のチェックを、データベース側に任せられます。参照先の行が削除・更新されたときの動作として、NO ACTION、RESTRICT、CASCADE、SET NULL、SET DEFAULT の 5 種類の参照アクションを指定できます。なお、Aurora DSQL はロックではなく楽観的同時実行制御 (OCC) によりコミット時に競合を検証する設計のため、競合時は直列化エラーが返り、アプリケーション側でのリトライ実装が前提になる点は外部キーの利用時も変わりません。 AWS Backup が Amazon FSx for NetApp ONTAP のクロスリージョンおよびクロスアカウントバックアップに対応 AWS Backup で作成した Amazon FSx for NetApp ONTAP のバックアップを、別の AWS リージョンや別の AWS アカウントにコピーできるようになりました。コピーはバックアッププランによるポリシーベースの自動実行と、オンデマンドのコピージョブの両方に対応します。これまで AWS Backup では FSx for ONTAP バックアップのリージョン間・アカウント間コピーは非対応でしたが、今回の対応によりコピーを AWS Backup で一元管理できます。AWS Organizations と組み合わせることで、組織全体でコピーを自動化することも可能です。 Amazon Redshift が Agent Toolkit for AWS と統合、AI 支援によるデータウェアハウス管理に対応 Amazon Redshift が Agent Toolkit for AWS と統合され、Claude Code、Kiro、Cursor などの AI コーディングエージェントから Redshift データウェアハウスおよびデータレイクの構築、クエリ、トラブルシューティング、Redshift への移行を実行できるようになりました。この統合は 2 つの要素で構成されます。ユーザーの認証情報を使って AWS API を実行する AWS MCP Server と、AI エージェントが Redshift のタスクを確実にこなせるよう検証済みの手順や参照情報をパッケージ化した Redshift skills です。導入は、利用中のエージェントに aws-data-analytics プラグインをインストールするだけで、MCP Server の設定と Redshift skills が 1 ステップでまとめてセットアップできます。 8/28(金) Amazon CloudWatch agent が journald ログのサポートを追加 Amazon CloudWatch agent が、systemd journal (journald) のログを直接読み取って Amazon CloudWatch Logs に送信できるようになりました。Amazon Linux 2023 のように systemd journal を主要なログ基盤とし、/var/log/messages などのテキストログをデフォルトでは書き出さないディストリビューションでも、ファイルへのエクスポート設定なしで OS ログを収集できます。systemd ユニット、journal 優先度、journal フィールドマッチ、正規表現の 4 種類のフィルターを送信前に適用できるため、取り込み量とコストを制御できます。すべての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用できます。 Amazon Bedrock AgentCore Memory がきめ細かなアクセス制御をサポート Amazon Bedrock AgentCore Memory が、きめ細かなアクセス制御 (FGAC) に対応し、独自の認可ロジックを実装することなく、ユーザー単位・テナント単位のメモリ分離を強制できるようになりました。具体的には、Memory リソースの前段に OAuth (JWT) 認証を構成した AgentCore Gateway を配置し、Cedar ポリシー (AWS が開発したオープンソースの認可ポリシー言語) を適用することで、分離をインフラ層で強制します。従来はアプリケーションコードが actorId や namespace を正しく設定することに依存していた分離処理を、認証済みトークンのクレームに基づくポリシー評価に置き換えられます。基盤となる AgentCore Memory connector は、12 の Memory 操作を Cedar アクションとして公開します。 Amazon Bedrock AgentCore Memory がフレキシブルな namespace 変数をサポート Amazon Bedrock AgentCore Memory で、長期メモリの namespace テンプレートにカスタム変数を定義できるようになりました。従来は actorId、sessionId、memoryStrategyId の 3 つの組み込み変数しか使えませんでしたが、組織、テナント、チーム、環境といったアプリケーション固有の軸でメモリを分離できます。メモリリソースごとに最大 5 個のキーを定義し、CreateEvent API 実行時に値を渡すと、長期メモリ抽出時に namespace テンプレートへ代入されます。あわせて、IAM 条件キー bedrock-agentcore:namespaceVariable/<キー名> を使うと、書き込みパスでのテナント分離をポリシーで強制できます。AgentCore Memory が利用可能なすべての AWS リージョンで追加料金なしで利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWS サービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

本記事は 2026 年 05 月 12 日に公開された “ Filter, transform, and load your DynamoDB table exports using AWS Glue ” を翻訳したものです。翻訳は Solutions Architect の嶋田 朱里が担当しました。 この記事では、 Amazon DynamoDB のフルまたはインクリメンタルテーブルエクスポートを 2 つ目の DynamoDB テーブルにロード（インポート）する方法を紹介します。何をロードするか、どの書き込みレートでロードするかを正確にコントロールでき、進捗を観察する機能も備えています。この技術は、最大限の制御が必要な大規模なデータマイグレーションや同期を推進するのに役立ちます。ここで説明するメカニズムは、オープンソースの Bulk Executor for DynamoDB のコマンドとして提供されています。これは、DynamoDB テーブルに対してバルクコマンドを実行するためのユーティリティセットです。このコマンドを使用することで、DynamoDB のエクスポート（済みデータ）を細かく制御しながらロードでき、アイテムを変換したり、データをフィルタリングしたり、コマンドのオプションの transform パラメータを使用して宛先テーブルに何を配置するかをカスタマイズしたりできます。 背景 DynamoDB はフルおよびインクリメンタル両方の テーブルエクスポート をサポートしています。両タイプのエクスポートはサービス駆動型で、読み込みキャパシティを消費せず、AWS マネジメントコンソール、コマンドライン、または SDK を通じて開始できます。エクスポートを実行するには、テーブルでポイントインタイムリカバリ (Point in Time Recovery, PITR) を有効にする必要があります。 フルエクスポートには、指定された時点でのテーブル内のすべてのアイテムが含まれます。エクスポートプロセスは、データを一連のオブジェクトとして Amazon Simple Storage Service (Amazon S3) に送信します。 ファイルは DDB-JSON フォーマットまたは Ion フォーマットで、1 行に 1 アイテムずつ記録されます 。インクリメンタルエクスポートのフォーマットは少し異なります。指定された期間中に変更されたアイテムのみが含まれ、各アイテムのプライマリキー、指定された期間内の最終変更時刻、（オプションで）期間開始時のアイテムの変更前イメージ、期間終了時のアイテムの変更後イメージが含まれます。アイテムの変更前と変更後の両方のイメージを確認できるため、エクスポートされた期間中にそのアイテムがどのように変化したかを把握できます。 ネイティブ機能として、DynamoDB は、S3 にフルエクスポートされたデータを新しいテーブル（ロードの過程で作成されます）に取り込む機能をサポートしています。AWS は、ロード中に処理された圧縮されていないデータの GB 単位でこの機能を価格設定しています。この記事で説明する技術は、この機能を補完し、ロードレート制御、カスタムアイテム操作、フィルタリングされたアイテムロード、既存テーブルの進捗追跡の機能を提供します。 なお、DynamoDB には現在、インクリメンタルエクスポートに基づいてデータをロードするネイティブ機能はありません。ここで説明する技術を使用すると、フルエクスポートと同じ柔軟性でこれらのファイルをロードできます。 使用方法 Bulk Executor は、”load-export” コマンドを使用してフルおよびインクリメンタルエクスポートされたデータのロードをサポートしています。 インストール手順 では、ツールのセットアップ方法を説明しています。セットアップ後の使用方法は次のとおりです。 ./bulk load-export --table <target> --s3-path <s3://bucket/path/to/data> [--transform <transform_module>] <target> を宛先テーブルの名前に置き換えます。このテーブルは既に存在している必要があります。空でもデータがあっても構いません。ロードはプライマリキーが一致する既存のアイテムを上書きします。 s3-path パラメータには、エクスポートされたデータを含む Amazon S3 のロケーションへのフルパスを指定します（例: s3://<bucket-name>/prod/AWSDynamoDB/01716790307109-5f9d6aaa ）。エクスポートされたデータは、フルまたはインクリメンタルエクスポートのいずれかです。データフォーマットは自動的に検出され処理されます。 オプションの transform パラメータは、各アイテムをロードする前に加工を加えるためのユーザー定義ロジックを含む Python ファイルの名前を受け取ります。ロードが各アイテムを処理する際、フルロードかインクリメンタルロードかに応じて、Python ファイルの transform_full_record(FullExportRecord) または transform_incremental_record(IncrementalExportRecord) 関数を呼び出します。この関数内で、以下を返すことができます。 レコード: 調整なしでアイテムをロード（または削除） 空のリスト: このアイテムのロード（または削除）を抑制 変更されたレコード: 調整付きでアイテムをロード 複数のアイテムのリスト: 1 つのソースレコードから複数のアイテムを書き込むためにファンアウト この関数は完全にカスタマイズ可能なので、これから行うアクションのあらゆる側面を操作できます。transform モジュールコードのブートストラップに関する詳細情報については、リポジトリ内の readme ファイルを参照してください。 AWS Glue ジョブは、任意の大きさのデータセットを処理するために並列実行でロードを実行し、標準の Bulk Executor のレート制限パラメータを介してレート制限が利用可能です。 ユースケース フルおよびインクリメンタルエクスポートをロードする機能は、さまざまなユースケースをサポートします。次のセクションでは、2 つの一般的なユースケースを概説します。 独立したテーブル同期 一般的なユースケースは、 グローバルテーブル とそのアクティブ-アクティブ伝播を使用せずに、一連のインクリメンタルエクスポートをロードして、2 つのテーブルを切り離された一方向の方法で同期することです。これは、ステージングまたは開発テーブルを本番と一致させたり、サードパーティのテーブルコピーを自分のものと同期させたり、隔離された環境内のテーブルコピーを維持したりするのに有用です。通常、毎回 2 つ目のテーブルを完全に作成するよりも、インクリメンタルエクスポートを適用する方がコスト効率と時間効率が高くなります。 以前の記事では、 継続的なデータ保持を推進する方法 について説明しています。 データの変換 もう 1 つの一般的なユースケースは、変換機能を使用して、あるテーブルから別のテーブルにデータを移動する際にデータをフィルタリングまたは変更することです。 例えば、フィルタリング関数を使用して、フルエクスポートを実行し、属性駆動型のフィルタリングで変換を行うことで、あるテーブルから別のテーブルにデータの一部をコピーできます。ロード中に各アイテムの属性を評価し、そのアイテムが 2 つ目のテーブルに伝播するかどうかを判断できます。SaaS (software as a service) 企業で、複数のテナントを持つテーブルがあり、1 つのテナントを切り出したい場合などに使用できます。これを実現するには、そのテナントのデータのみをロードします。または、最近のデータのみを保持する新しいテーブルのコピーが必要な場合は、最近のタイムスタンプを持つアイテムのみを許可する変換でロードを実行できます。 別の用途は、修飾子としての使用です。SSN や DOB 属性などの個人を特定できる情報 (Personally Identifiable Information, PII) をダウンストリームテーブルにロードする際にロードを抑制できます。また、タイムスタンプ属性を ISO 8601 文字列から数値エポック形式に調整することもできます。ファンアウト関数を使用すると、単一のアイテムから値のリストを個々の値の個別アイテムに分割できます。キースキーマを調整することもできます。 transform 関数を使用して、新しいキースキーマに移行することもできます。例えば、エクスポートされたデータで last_name と first_name がそれぞれパーティションキー (PK) とソートキー (SK) として含まれている場合などです。宛先テーブルには、PK として user_id という新しいフィールドがあります。transform 関数を使用すると、ロード中に各アイテムに GUID を user_id として正常に注入し、他の既存の属性を維持できるため、新しいキースキーマに効果的に移行できます。 技術的な内部構造 load-export コマンドは、Bulk Executor フレームワークを使用して実行されます。Bulk Executor は差し込み式のコマンドをサポートしているため、最初に load-export コマンドをカスタムコマンドとして作成し、その後公式リポジトリに貢献しました。 検証 ロードプロセスが開始される前に、コードはマニフェストに基づいてエクスポート全体を検証し、すべてのファイルが存在し、その署名がマニフェストと一致することを確認します。これにより、エクスポートデータに偶発的に生じた破損を防ぎます。 読み込み ロードプロセスは AWS Glue を使用して、Amazon S3 オブジェクトを Spark Resilient Distributed Dataset (RDD) にロードし、フルまたはインクリメンタルエクスポートかどうかを検出します。 変換 transform 機能は、2 つの主要な関数を公開します。1 つはフルロード中にレコードを変換するためのもので、もう 1 つはインクリメンタルロードのためのものです。現在処理中のソース Amazon S3 レコードがこの関数にパラメータとして渡されます。このレコードはすべての内部データを辞書型で公開するため、ロードプロセスを完全に制御できます。次の例は、 status 属性が active 値を持つアイテムのみを含める方法を示しています。 def transform_full_record(record: FullExportRecord) -> list[FullExportRecord]: """ Example: Only load items where 'status' attribute is 'active'. Args: record: record.item is the deserialized Item dict, record.table_key_schema has key info. Returns: list[FullExportRecord]: Single-element list to keep, empty list to skip """ if record.item.get("status") == "active": return [record] return [] def transform_incremental_record(record: IncrementalExportRecord) -> list[IncrementalExportRecord]: """ Example: Only load items where 'status' attribute is 'active'. Behavior: - If new_image exists and status is 'active': load the item (PUT) - If new_image exists but status is not 'active': skip the item - If new_image is None (a delete): return the record, i.e. respect the delete Args: record: record.keys, record.new_image, record.old_image, record.table_key_schema, record.write_timestamp_micros Returns: list[IncrementalExportRecord]: Single-element list to keep, empty list to skip """ if record.new_image: if record.new_image.get("status") == "active": return [record] else: return [] return [record] transform コードは完全にあなたの管理下にあります。通常、効率のために単純なアルゴリズムチェックを実行させますが、レイテンシーを許容できる場合は、決定を下しながら CRM や別のデータベースにクエリを実行するなど、外部ソースをクエリすることもできます。 並列化とレート制限 次に、コマンドはデータを AWS Glue ワーカーに分散して、DynamoDB に並列で書き込みます。各 AWS Glue スロットは独立したライターとして動作します。この大量並列化がテーブルのスループット容量を超えるのを防ぐために、Bulk Executor の 分散レート制限 機能を使用します。これにより、設定可能な読み込みまたは書き込みキャパシティを使用できます。 検証 ロードが完了した後、 bulk diff ツール機能を使用して 2 つのテーブルを比較する ことで、データの整合性を検証できます。両方のテーブルが一致する場合、次のような出力が表示されます。 ./bulk diff --table source --table2 destination … No differences found コストに関する考慮事項 ロード中にコストを左右する主な要因は、次の 2 つです。 DynamoDB テーブルの書き込み消費: 書き込まれるアイテムの数とサイズに基づきます。 AWS Glue データ処理ユニット (Data Processing Unit, DPU): AWS Glue ジョブ中のワーカーの数、ワーカーのタイプ、実行時間に基づきます。 次の実行は、1 億レコードを保持するフルエクスポートに対するフルロードのテスト実行を示しています。デフォルトのワーカータイプ (G.1X) と デフォルトの AWS Glue ワーカー数 (220 までオートスケーリング) を使用しました。ロード速度を上げるために、毎秒 240,000 書き込みユニットで 事前ウォームアップ されたオンデマンドテーブルを作成しました。bulk ツールに 240,000 すべてを使用するよう指示しました。総実行時間は 12 分 27 秒でした。 >> ./bulk load-export \ --XMaxWriteRate 240000 \ --table ... \ --s3-path s3://... \ --XTimeout 10080 \ --XWaitForDPU … Destination Table: … S3 export: 100,000,000 items across 512 files (FULL_EXPORT, DYNAMODB_JSON) DynamoDB write costs depend on how many items are being written and the size of the items. Here we estimate the command will write 100,000,000 items with average size 256 bytes; each write incurs an average of 1 write units Write units required (approx): 100,000,000 This does not include costs for secondary indexes! Approx DynamoDB cost for on-demand writes consuming 100,000,000 WRUs (using us-east-1 prices): $69.50 Writing items to DynamoDB... =============================================================== JOB COMPLETED SUCCESSFULLY - Total items in export: 100,000,000 - Total items written: 100,000,000 - Execution time: 707.3 seconds … Waiting 40 seconds for DPU metrics to gather... Job completed successfully. Job duration: 0:12:27 (24.06 DPU hours) 実行では、ロードのサイズに基づいて DynamoDB のコストを早期に見積もり、ここでは小さなアイテムの約 1 億回の書き込みに対して $69.50 となっています。出力には最後に AWS Glue のコストが表示されます。 us-east-1 で 1 DPU 時間あたり $0.44 の価格 で、約 $10 です。 制限事項 load-export コマンドは DDB-JSON フォーマットを使用したエクスポートのみをサポートし、ロードは同じプライマリキーを持つ既存のアイテムを上書きします。異なる動作が必要な場合は、コードを変更できます。 まとめ この記事では、Bulk Executor を使用して DynamoDB のフルおよびインクリメンタルエクスポートをバルクロードする方法を概説しました。オプションの変換機能を使用して、ロードするデータとその構造を思いどおりに選択でき、組み込みの レート制限 が書き込みキャパシティの飽和を防ぎます。Bulk Executor の リポジトリ をクローンして、今日最初のロードを実行することから始めましょう。 著者について Ruskin Dantra Ruskin はカリフォルニアを拠点とするソリューションアーキテクトです。彼は元々「長く白い雲のたなびく地」ニュージーランド出身で、アプリケーション開発の 18 年のベテランで、ネットワークを愛しています。彼の人生における情熱は、AWS を使用して複雑なものをシンプルにすることです。 Jason Hunter Jason はカリフォルニアを拠点とする Amazon DynamoDB を専門とするプリンシパルソリューションアーキテクトです。彼は 2003 年から NoSQL データベースに取り組んでいます。Java、オープンソース、XML への貢献で知られています。 AWS Database Blog で、より多くの DynamoDB の投稿 や Jason Hunter が書いた 他の投稿を見つけることができます。

本稿は、2026 年 8 月 18 日に公開された “ Amazon EVS with NSX Federation for Disaster Recovery and Multi-site Networking ” を翻訳したものです。 はじめに Amazon Elastic VMware Service (Amazon EVS) が NSX Federation をサポートしました。これにより、AWS 上で VMware ワークロードを実行する際のエンタープライズ規模のネットワーク、ディザスタリカバリ (DR)、マルチサイトネットワークのための強力な新しいオプションが利用可能になります。 NSX Federation は、複数の NSX 環境を単一の Global Manager コントロールプレーンの下で接続する VMware のネットワーク機能です。オーバーレイネットワーク、セキュリティポリシー、ゲートウェイサービスを複数のロケーションに拡張し、各サイトを個別に設定するのではなく、複数サイトのネットワークを統一されたファブリックとして管理できます。 VMware Cloud Foundation Operations HCX (HCX) は、マイグレーションおよびマイグレーション中のネットワーク拡張のための VMware のソリューションです。NSX Federation は、大規模な Layer 2 拡張、ロケーション間での統一されたセキュリティポリシー、マルチサイトメッシュ接続、および 1 分未満のフェイルオーバーによるネイティブ DR を必要とするシナリオに対応することで、HCX を補完します。 この記事では、これが重要である理由、NSX Federation が HCX 単体では提供できないネットワーク機能をどのように拡張するか、そしてワークロードの真のマルチサイトネットワークをどのように実現するかを説明します。 課題: エンタープライズネットワークが単一ソリューションの範囲を超える場合 VMware HCX Network Extension (NE) は、マイグレーション中にサイト間で Layer 2 セグメントを延伸するための実績のある専用技術です。マイグレーションワークフローや小規模な DR シナリオでは効果的かつ迅速にデプロイできます。しかし、企業がスケールするにつれて、HCX に加えて追加の機能が必要になることがあります。 大量の VLAN 数 – 数百の VLAN を持つ環境では、アプライアンスペアごとの拡張ではなく、ファブリックレベルのアプローチが有効です。 統一されたセキュリティポリシー – 単一サイト内だけでなく、すべてのロケーションで一貫して適用される Distributed Firewall (DFW) ルール。 マルチサイトメッシュネットワーク – 複雑なハブアンドスポークトポロジなしに 3 つ以上のロケーションをネイティブにサポート。Federation により、ネットワーク全体を再設計することなく、設定ステップとして新しいサイトを追加できます。 ステートフル DR フェイルオーバー – フェイルオーバー中にステートフルサービスが完全に保持された状態での 1 分未満のネットワーク接続復旧。 ここで NSX Federation が登場します。HCX の代替ではなく、これらのエンタープライズ規模の要件に対応する補完機能です。 ソリューション: Amazon EVS 上の NSX Federation NSX Federation は、参加するすべてのロケーションにまたがる 単一の Global Manager によって管理される 、統一されたオーバーレイネットワークファブリックを作成します。HCX と並行して動作し、それぞれの技術がその強みを発揮します。 NSX Federation が提供する機能 機能 メリット 数千のセグメント Global Segments はフェデレーションファブリック全体で 数千にスケール 統一された Distributed Firewall (DFW) DFW ルールは Global Manager 上で一度定義され、すべてのロケーションで一貫して適用 マルチサイトメッシュ Federation は複数のロケーションをネイティブにサポート。3 番目や 4 番目のサイトの追加は設定ステップであり、複雑なポイントツーポイントリンクを構築することなく真のマルチサイト接続を実現 ステートフルゲートウェイフェイルオーバー Active-Standby Tier-0 ゲートウェイがステートフルサービス (NAT、Gateway Firewall) を含む 1 分未満のフェイルオーバー を提供 シングルペインオブグラス Global Manager がすべてのフェデレーションロケーションの一元管理を提供 マルチサイトネットワークの実践 Federation の大きな利点の 1 つは、マルチサイト接続です。従来のアプローチでは、3 つ以上のサイトを接続するには、個別のポイントツーポイントリンクを構築し、各ペア間のルーティングを管理する必要がありました。Federation は、すべてのロケーションを単一ファブリックのメンバーとして扱うことで、この複雑さを排除します。 サイト A のワークロードは、追加の設定なしに同じ Global Segment 上でサイト B またはサイト C と通信できます。 DFW ポリシーは、ファブリック内のどのサイトで実行されているかに関係なく、ワークロードに追従します。 Global Manager に登録してローカル Edge ノードをデプロイすることで、新しいサイトの追加ができます。既存ネットワークのオブジェクト (セグメント、ファイアウォールルール、ゲートウェイ) は自動的に新しいロケーションに拡張されます。 これにより、Federation は複数の AWS リージョンやアベイラビリティーゾーンをまたいで運用する組織や、オンプレミスデータセンターとのハイブリッド接続を維持する組織にとって特に価値があります。 ビジネス価値: エンタープライズクラウド導入にとって重要な理由 1. 停滞しているマイグレーションの解消 複数の企業が、マルチサイト DR および数百のネットワークセグメントにまたがる IP 保持接続の要件が、マイグレーションツールで実現可能ではあるものの、大規模であれば非実用的なリソースコストでしか達成できないため、Amazon EVS の採用がブロックされていました。NSX Federation はこれらの組織のブロックを直接解消し、本番環境のデプロイメントを進めることを可能にします。 2. 運用複雑性の削減 Federation は大規模な L2 拡張を単一のマネージドファブリックに統合します。運用負荷は大幅に低下します。 1 つの Global Manager がすべてのロケーションにわたる一元的な制御を提供 1 つの DFW ポリシーセット がどこでも一貫して適用 1 つのフェイルオーバーメカニズム (Active-Standby T0) がネットワークフェイルオーバーをネイティブに処理 3. 真のビジネス継続性 Amazon EVS 上の NSX Federation は以下を実現します。 ネットワーク RTO: 1 分未満の Active-Standby Tier-0 ゲートウェイフェイルオーバー 。これを実現するには、NSX フェイルオーバーおよびルートテーブルの更新などの AWS 側のネットワーク変更のためのオートメーションが必要です。 RPO: Amazon FSx for NetApp ONTAP SnapMirror レプリケーションで 約 5 分 (またはマルチ AZ デプロイメントで RPO 0) フェイルオーバーの前、最中、後において、両サイトで DFW ルールがアクティブな状態での 一貫したセキュリティポスチャ HCX と NSX Federation: 組み合わせによる相乗効果 HCX と NSX Federation は補完的な目的を持ち、組み合わせて効果的に機能します。それぞれが適しているユースケースは以下の通りです。 ユースケース 推奨アプローチ マイグレーション (バルク vMotion/レプリケーション) HCX、マイグレーションワークフロー向けに専用設計 少数の VLAN での 2 サイト間 L2 拡張 HCX Network Extension、シンプルかつ迅速にデプロイ可能 大規模な L2 拡張 (大量の VLAN 数または 3 サイト以上) NSX Federation、アプライアンスごとの上限なしのファブリックレベルアプローチ ステートフルフェイルオーバーによるマルチサイト DR NSX Federation、Active-Standby T0 で 1 分未満の RTO サイト間で一貫した DFW ポリシー NSX Federation、Global Manager からの統一されたセキュリティ 3 サイト以上 NSX Federation、ネイティブマルチロケーションメッシュ マイグレーション + DR (組み合わせ) 両方: HCX でマイグレーション処理、Federation で恒久的なネットワークと DR エンタープライズ企業は HCX と NSX Federation の両方を使用できます。HCX がマイグレーションの過程を処理し、NSX Federation がワークロードの配置後に長期的なネットワークと DR の基盤を提供します。 まとめ この記事では、Amazon EVS 上の NSX Federation が AWS 上のエンタープライズ VMware ネットワークの可能性をどのように拡大するかを紹介しました。ファブリックレベルの L2 拡張、統一されたセキュリティポリシー、ネイティブマルチサイトメッシュ接続、1 分未満の DR フェイルオーバーにより、HCX を補完します。これらの機能を組み合わせることで、マイグレーションを超えたエンタープライズ規模の要件に対応するためのツールが提供されます。 大規模なマイグレーションを計画している場合でも、マルチサイト DR アーキテクチャを構築している場合でも、複数の AWS ロケーションとオンプレミスデータセンター間でワークロードを接続している場合でも、Amazon EVS 上の HCX と NSX Federation の組み合わせが、それを正しく実現するためのネットワーク基盤を提供します。 始める準備はできましたか？ お使いの環境での NSX Federation デプロイメントについては、AWS アカウントチームにお問い合わせいただくか、 Amazon EVS のドキュメント で詳細をご確認ください。 著者について Ron Wedel Ron Wedel は AWS のシニアソリューションアーキテクトです。20 年以上にわたり仮想化技術に携わっており、パートナーやお客様が AWS への次のステップを踏み出す支援を楽しんでいます。AWS ソリューションアーキテクトとして、VMware 環境、ネットワーク、コンピューティングインフラストラクチャの最適化を専門としています。これらの技術に関する包括的なバックグラウンドが、AWS のお客様が AWS 上でモダンインフラストラクチャを構築・成長させるためのアプローチの基盤となっています。 Jay Scheponik Jay Scheponik は AWS のシニアスペシャリストソリューションアーキテクトで、マイグレーションとモダナイゼーションを担当しています。エンタープライズ IT およびインフラストラクチャにおける長年の実践経験を活かし、お客様の VMware ワークロードの AWS への移行を支援しています。Jay は 12 の AWS 認定資格を保有し、VMware Certified Design Expert (VCDX) でもあります。仕事以外では、ゴルフ、レコードを回すこと、ゲーム、家族との時間を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。

NEC は 2026 年 6 月 1 日、全社員（最大 12 万人）が利用できる Claude Cowork の本番環境を Amazon Bedrock 上で稼働させました。設計着手は 5 月 18 日、要件定義から全社リリースまで 2 週間です。検討を進めていた 2026 年 5 月の時点では、この構成はまだ一般提供（GA）開始前 (*1) でした。前例の少ない構成を採用しながら、国内完結の推論・監査証跡・コスト管理を備えた環境を立ち上げています。本記事では、現場を率いた NEC 野口氏の視点と、AWS が担った役割の両面から振り返ります。 本記事は、日本電気株式会社（以下、NEC）コーポレートIT・AIイノベーション部門 AIプラットフォーム統括部 ディレクター 野口 忠則 氏と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 吉川 晃平の共著です。 はじめに（AWS 吉川） 生成 AI アシスタントの全社導入では、 「使えるようにする」ことと「統制の効いた状態で使えるようにする」ことの間に大きな隔たりがあります。データの所在、認証・認可、監査ログ、コストの可視化といった非機能要件は、利用者が数万人規模になると難易度が跳ね上がり、多くの場合は後から足すことができません。 2026 年 7 月 28 日に開催された AWS Bedrock LLM Day Japan にて、NEC の野口氏が「Anthropic 協業の舞台裏 〜 AI ネイティブ化に向けた Cowork on Bedrock 適用 〜」と題して登壇されました。私は本プロジェクトを担当するソリューションアーキテクトとして、NEC のプロジェクトチームをご支援してきました。そのセッションで語られた内容を軸に、NEC が何に挑み、どう乗り切り、Amazon Bedrock を選んで何を得たのかをお伝えします。 なお、本記事で扱う構成は、Anthropic のデスクトップアプリ Claude Desktop（Chat・Claude Cowork・Claude Code を含みます）の推論を Amazon Bedrock に向けるもので、正式名称は Claude Desktop on Amazon Bedrock です。NEC が全社展開されたのは Claude Cowork の利用であるため、本記事では通称の Claude Cowork on Amazon Bedrock を用い、機能そのものを指す場合は Claude Cowork と表記します。 ここからは、NEC の野口氏にバトンを渡します。 全社が使い始める、その日までに（NEC 野口） NEC は 2026 年 4 月 23 日に Anthropic との協業を発表し、6 月 1 日から社内での利用を開始しました（図 1）。発表から利用開始までの期間は限られており、準備に使える時間は多くありませんでした。ここからお話しするのは、5 月の連休明けから 6 月 1 日のリリースまで、展開の現場で何が起きていたかです。 図 1: 協業発表から全社利用開始、その後の展開までのタイムライン（出典: AWS 作成） Claude Cowork を社内で利用する方式は 2 つあります。Anthropic のサービスプラン Claude Enterprise を契約する方式と、Amazon Bedrock に接続する方式です。5 月中旬の時点で、私たちは社内利用に必要な技術検証を進めていました。プロキシ経由の通信など社内ネットワーク特有の課題は、どちらの方式でも共通の検討事項です。その頃、Amazon Bedrock に接続する方式についても AWS への相談を始めました。ただし 2026 年 5 月の時点では一般提供前であり、このときは「いずれ AWS 上でも構築しよう」という受け止めでした。 その 1 週間後、全社の利用開始に合わせて AWS 上にセキュアな環境を構築する方針が決まりました。期限は 6 月 1 日です。当初の想定より前倒しの判断でしたが、私たちはこれを妥当だと受け止めました。理由は 2 つあります。 1 つは、Amazon Bedrock であれば推論とデータを国内に閉じられることです。これが私たちにとって最も重い要件でした。 もう 1 つは、利用者が自分の手で作り上げていく設定を、後から移すコストです。会話履歴やメモリ、プロジェクトの設定には、方式をまたいで引き継ぐ仕組みがありません。スキルは中身がファイルなので移植そのものは可能ですが、一括で取り出す手段は用意されておらず、どれを登録し有効にしていたかという状態も引き継げません。人手での再構築が必要になります。数万人が使い始めた後にそれをやるのかと考えたとき、答えは決まっていました。利用者にとっての「使い始め」に、その後も使い続ける環境を用意しておく。それが 6 月 1 日という期限の意味でした。 2 週間で本番環境をつくるということ（NEC 野口） 方針が決まっても、それだけで現場が動くわけではありません。セキュリティ設計、動作確認、社内認証連携といった工程は、通常であれば数か月をかけるものです。大規模システムの本番構築を経験された方であれば、2 週間という期間がどれほど過酷かご想像いただけると思います。短い期間で進めることに対して、慎重な意見もありました。当然です。だからこそ、精神論ではなく段取りで通すしかないと考えました。状況を共有しながら一緒に進めるほかありません。私自身、プロジェクトマネジメント（PM）とシステムアーキテクト（SA）の経験はありますが、この部署に来てまだ 1 年。頼れる関係を一から築きながらの 2 週間でもありました。 それでも「一緒にやりましょう」と手を挙げてくれたメンバーが数名いました。この数名がいなければ、6 月 1 日はありませんでした。徹底したのは、 作業の優先順位を明確にすること 、 タスクの範囲を限定すること 、 構築状況を踏まえて次に実施すべきことを判断し共有すること です。加えて、短期間で新しい技術を扱う案件では、経営層の理解と後押しが欠かせません。組織全体が AI 活用に前向きだったことは、成功の要因の一つでした。こうして出来上がったのが図 2 の構成です。 図 2: 完成したアーキテクチャ。推論は日本国内リージョンで完結し、利用者 ID は Microsoft Entra ID で連携する（出典: AWS 作成、NEC 登壇資料に基づく） 技術面で注意したのは 2 点です。1 つは、国内完結の推論を要件としたため、海外リージョンへ推論を分散できないこと。事前に把握していたので、性能設計と負荷テストを 2 週間の中に組み込みました。もう 1 つは外部システムと接続するコネクタ部分で、これが最も工数を要しました。 最も苦労した点 — MCP サーバーの OAuth 実装差異への対応（NEC 野口） Amazon Bedrock 利用時は、管理者が MCP（Model Context Protocol）サーバーの設定を端末へ配布することで、利用者はアプリの UI からコネクタを簡単に追加できます。ところが、簡単に安定稼働させられるかというと、そうではありませんでした。接続先の SaaS ごとに MCP や OAuth の実装が細かく異なるため、接続が成立することと期待どおりに動作することは、それぞれ確認が必要でした。 2026 年 5〜6 月時点では、Claude Desktop on Amazon Bedrock が対応する方式と接続先の実装との間に複数の差異がありました。DCR（Dynamic Client Registration）による OAuth クライアントの動的登録に対応していない接続先では事前の手動登録が必要になり、クライアント認証方式にも違いがありました。そこで NEC は、 これらの差を吸収する認可中継サーバーを独自に設計・構築 しました。このサーバーは 7 月 18 日に社内リリースし、接続可能なサービスを順次広げています。 リリース 1 週間前に判明した認可動作の差異 最初の 1 週間が過ぎた 5 月 22 日金曜の夜、メンバーから、想定と異なる挙動があるという報告が入りました。自社だけでは原因の切り分けができず、その夜のうちに AWS のアカウントチームへ連絡しました。翌日の土曜から調査に入ってもらえることになりましたが、リリースまで 1 週間しかありません。正直に申し上げると、その週末は崖っぷちに立たされた気分で、6 月 1 日のリリースは無理だと思っていました。 それが、日曜の夕方には問題の所在が判明します。AWS の担当チームが全力で入ってくれたおかげでした。原因は、OAuth クライアントの登録と認可フローの動作が私たちの理解と異なっていたことでした。公開情報だけでは判断が難しい部分があり、AWS のエンジニアと一緒に実機で確認して初めて整理できた内容です。 もっとも、分かったのは「なぜ動かないのか」であって、そこから 6 月 1 日までの対応は決して楽ではありませんでした。新しい領域の技術を早い段階で採用するうえでは起こり得ることですが、リリース前に把握できたことは大きかったと考えています。 プロジェクトの目的と体制（NEC 野口） プレスリリースでは「Claude を利用する AI ネイティブエンジニア体制」として発表しましたが、Claude Cowork は全員が業務で使うため、最大 12 万人規模で使える環境を構築しました。目的は単なる AI ツールの導入ではなく、大きく 2 つあります。1 つは 独自構築 で、コアとなる要件まで自ら設計・構築し、環境のコントロールを自社で握ることです。もう 1 つは Client Zero 、つまり自社を最初の顧客として実践し、日本企業共通の課題に対する先駆的なリファレンスを確立することです。 体制は、NEC の 統括チーム （中央官庁の大規模 SI でのプロジェクトマネージャー・システムアーキテクト 経験者）と 社内 SE チーム （社内 IT ・インフラシステムエンジニア）、そして本プロジェクトのために AWS 側で編成した AWS チーム という、3 つの専門性を持ち寄る編成としました（図 3）。これが短納期での実現につながったと考えています。 図 3: 要件定義・設計/構築・テスト・運用を 2 週間に凝縮したスケジュール（出典: NEC 登壇資料） Claude Cowork on Amazon Bedrock の適用価値（NEC 野口） Claude を Amazon Bedrock 経由で利用する以外の選択肢もありましたが、要件を整理した結果、国内利用限定という私たちの要件を満たせると判断できたのは Amazon Bedrock でした。図 4 の 3 つの適用価値のうち、最も重視したのは国内データ保管です。 図 4: ①NEC 基準にカスタマイズ可能なセキュアクラウド、②データを国内に閉じた構成、③早期リリースによる先行利用とノウハウ獲得（出典: NEC 登壇資料） 機能面では、Claude Enterprise（Anthropic のサービスプラン。AWS Marketplace 経由でも調達できます）を契約する方式のほうが先に提供される機能や、Amazon Bedrock 接続では提供されない機能もあり、利用者から要望をいただくこともあります。それでも情報システム部門としては、 国内データ保管とガバナンスを最優先とする要件のため、Claude Cowork を Amazon Bedrock に接続する構成を選びました 。判断にあたっては、AWS から提供を受けた 2 つの方式の整理（図 5）を材料としています。 図 5: NEC が Amazon Bedrock 接続を選んだ理由。左は NEC が優先した要件、右は Claude Enterprise 契約で提供され利用者から要望のあった機能。NEC の要件に照らした整理であり、一般的な優劣を示すものではない（出典: AWS 作成、2026 年 7 月時点の公開情報および NEC 登壇内容に基づく） 成果と成功のポイント（NEC 野口） 綱渡りの連続でした。一つひとつの判断が結果に直結し、退路のない 2 週間でした。無事に立ち上がったと言えるようになったのは、しばらく経ってからです。6 月 1 日のリリースから 2026 年 7 月時点までの約 2 か月間、大きなトラブルなく安定稼働しています。利用者は 8 月 18 日時点で 11,000 名まで広がっています。国内完結の推論・監査証跡・コスト管理を完備し、国内大手 IT ベンダーとして先行事例をつくれたと考えています。業務効果の定量的な測定は今後の課題です。成功のポイントは 3 点です。 組織の後押しと許容 — AI 領域は技術の進化が速く、評価の段階では想定どおりに動かない場面も出てきます。経営層の理解と許容があってこそ、提供スピードは上がります。 大規模システムの PM 力 × アーキテクト力 — 重要タスクを見極め、優先順位をつけて執行し続けること。リード役は細部の完璧さより全体を前に進める判断を優先すべきです。 One Team 体制の推進 — 前例の少ない構築では、地道な検証と改善の繰り返しが必要です。ベンダーと一体で進める体制は、経営層の関与があって初めて成り立ちます。 今後は AI 基盤をさらに進化させ、エージェントの本番活用へ拡張していきます（図 6）。 図 6: 大規模・短納期での構築の成果、成功ポイント、今後の展望をまとめた登壇資料のスライド（出典: NEC 登壇資料） 同じような判断を前にされている方に、少しでも参考になればと思います。 ここからは、AWS の吉川に戻ります。 AWS の支援内容（AWS 吉川） 本プロジェクトで AWS が担った役割は 4 つです。 利用方式の提示と、ご要件に対する事実の回答。 Claude Cowork には Claude Enterprise を契約する方式と Amazon Bedrock に接続する方式があり、いずれも AWS からご利用いただけます。この 2 つの選択肢があることをお伝えしたうえで、NEC からご照会のあった観点について、Amazon Bedrock 接続での構成・運用に関する事実をお答えしました（図 5）。データレジデンシー、閉域網構成、キャパシティ、AI ガードレール、マルチモデル対応、各種のセキュリティ・コンプライアンス認証、MDM による環境設定の大規模展開、MCP サーバーの設定や Agent Skills の利用者への展開などです。Amazon Bedrock 接続では利用できない機能とその代替手段もお伝えしています。両方式の機能差分は Anthropic の公式ドキュメント に一覧が公開されています。要件の定義と優先順位付け、方式の選択はいずれも NEC のご判断です。 国内完結の推論構成の設計支援。 日本国内のリージョン間で推論を完結させるクロスリージョン推論プロファイル（cross-Region inference profile。推論プロファイル ID が jp. で始まるもの。以下、JP-CRIS）を用いた構成をご提案しました。プロンプトと応答は国内にとどまり、リージョン間通信も AWS のプライベートネットワーク内で完結します。認証は Microsoft Entra ID による利用者 ID 連携とし、AWS Identity and Access Management (IAM) による認可など AWS のセキュリティ機能と一体で運用する設計としています。 大規模キャパシティの設計と実測検証。 国内完結の推論を要件とすると、利用できる推論プロファイルが国内に限られ、モデルごとの TPM（Tokens Per Minute）クォータが実効的な上限になります。野口氏が挙げられた「海外リージョンへ推論を分散できない」という制約はこの点を指します。モデル別のクォータ設計とパイロット実測に基づく容量計画をご支援し、リリース後も使用率を継続モニタリングしています。2026 年 7 月時点では、いずれのモデルも上限に十分な余裕があり、スロットリングは発生していません。 週末を含む切り分けの伴走。 5 月 22 日金曜夜のご連絡を受け、本件では土曜の朝からアカウントマネージャーとソリューションアーキテクトでチームを組み、日曜の夕方までに切り分けを完了しました。前例の少ない構成をご採用いただくことは、お客様だけにリスクを負っていただくことではありません。ここは AWS が前に出るべき場面だと考えています。 おわりに（AWS 吉川） 本事例の示唆は技術選定に留まりません。後から足せない要件は何か、後から移すと人手のかかるものは何かを見極め、「使い始めの日」から逆算する。そしてその判断を実行に移せる体制と経営の後押しを確保する。NEC が 2 週間でやり切られたのは、この順序を間違えなかったからだと感じています。 本記事で述べた Claude Desktop の Amazon Bedrock 経由での利用は、 2026 年 7 月 9 日に一般提供が開始されています 。Claude Desktop の機能追加も続いており、例えば 2026 年 6 月 30 日のアップデート では、Amazon Bedrock 接続の構成でも プラグインマーケットプレイス （ベータ）が使えるようになりました。社内の Git リポジトリを配布元として指定し、任意の導入・自動導入・必須指定の 3 段階で配布を統制できます。 NEC でも、こうした機能の追加を踏まえ、統制と利用者の利便性を両立させるスキル配布のあり方について、継続して検討を進められています。一般提供の開始前に始まった取り組みは、早期のリリースを実現した後も社内サービスの改善として続いており、AWS も新機能の評価や運用設計の面で継続して支援しています。 Amazon Bedrock は、Claude をはじめ複数ベンダーの基盤モデルを AWS のセキュリティ・ガバナンス機能と一体で運用できる AWS サービスです。閉域網、ガードレール、監査ログ、支出管理といった運用設計は、将来別の AI エージェントを導入する際にもほぼそのまま再利用できます。NEC が次に注力されるテーマについても、引き続きご一緒していきます。 Claude と Amazon Bedrock のエンタープライズ活用にご関心のある方は、 Amazon Bedrock をご覧いただくか、担当のアカウントチームまでお問い合わせください。 日本電気株式会社について NECは、125年以上の歴史を有する、AIやサイバーセキュリティ、通信などの技術を強みとするグローバルテクノロジー企業です。社会と産業のAIトランスフォーメーションを推進するITサービス事業と、日本をはじめ世界の安全保障に貢献する社会インフラ事業を展開しています。業種横断の先進的な知見と最先端技術を結集し体系化した価値創造モデル「BluStellar(ブルーステラ)」を中核に、世界に革新と安心を届け、誰もが人間性を十分に発揮できる社会の実現を目指します。 著者について 野口 忠則 — 日本電気株式会社 コーポレートIT・AIイノベーション部門 AIプラットフォーム統括部 ディレクター。1999 年 NEC 入社。IP-PBX の開発を経て、19 年間にわたり中央官庁向け SI のプロジェクトマネジメントとシステムアーキテクトを担当（2016 年システム部長）。2025 年より社内 IT の AI 業務変革に従事。 吉川 晃平 — ソフトウェア開発者およびシステムインテグレーターとして 20 年以上従事した後、2020 年から AWS Japan でソリューションアーキテクトとして活動中。日本の多くの製造業や SI 事業のお客様の AWS 活用を支援してきた。最近は AI 開発エージェントを用いた製品開発ライフサイクルの加速に取り組んでおり、お客様との会話のネタが尽きない毎日を送っている。 (*1) : Claude Desktop の推論を Amazon Bedrock などの外部の推論基盤に向ける構成（Claude Desktop on third-party）は、2026 年 7 月 9 日に一般提供が開始されました。詳細は Anthropic の公式ドキュメント Claude Desktop on third-party (3P) の概要 を参照してください。

本記事は 2025 年 3 月 18 日 に公開された「 Streamlining access to tabular datasets stored in Amazon S3 Tables with DuckDB 」を翻訳したものです。 データドリブンな意思決定への依存が高まるなか、データ分析のプロセスを効率化・高速化するツールへの需要が増しています。重要な意思決定を進める場面では、アプリケーションアーキテクチャの効率性とシンプルさが競争優位につながります。開発者は、既存のアプリケーションスタックとスムーズに統合できる軽量で柔軟なツールを求めています。特に、データレイクに保存されたデータセットを素早く効率的にクエリするための手段が重視されています。 こうした状況において、 DuckDB は複雑なインストールなしにデータを素早く分析できる実用的な選択肢として注目されています。DuckDB はホストプロセスに完全に組み込まれ、別プロセスとして動作しないため、インストール・更新・保守が必要な別サーバーやソフトウェアを用意する必要がありません。軽量な設計により、Python、Java、その他の環境に容易に統合でき、対話型のデータ分析に適しています。DuckDB には最近、 Apache Iceberg REST API を利用して Amazon S3 Tables に格納されたテーブルを読み取る プレビューサポート が追加されました。S3 Tables は表形式ストレージ専用に設計されており、Apache Iceberg 形式のデータを直接、高性能かつ低コストで保存・クエリできます。S3 Tables はストレージを継続的に最適化してクエリ性能を最大化し、コストを最小化するため、追加のインフラ構築なしにデータレイク運用を効率化したい企業に適しています。DuckDB と S3 Tables の統合により、開発者は Amazon S3 に格納されたデータをクエリでき、複雑なデータ移動や追加のインフラなしにテーブルへアクセスしながら、企業はデータレイクを効率化・集約できます。 本記事では、 Amazon SageMaker Lakehouse Iceberg REST エンドポイント と AWS Lake Formation のアクセス許可を利用して、ローカルマシンから DuckDB で S3 テーブルバケット内の Iceberg テーブルを読み取る方法を紹介します。同じデータ利用ワークフローは、リソースが限られた小型のエッジデバイスから、100 コア超の CPU を搭載する数テラバイトメモリの大型サーバーまで、幅広い環境で適用できます。DuckDB と S3 Tables の組み合わせは、AWS 上でスケーラブルなデータレイク構築を始めるための、直接的で堅牢な基盤になります。 ソリューションの概要 本記事では、 AWS CloudShell の CLI で DuckDB を使い、ローカルシステムから S3 バケットのテーブルを読み取る方法を紹介します。ここではコマンドラインインターフェイスを使いますが、DuckDB は複数のプログラミング言語とクライアント API をサポートしています。対応言語と統合オプションの一覧は、 DuckDB 公式ドキュメント を参照してください。また、本記事では、開発者やデータサイエンティストがローカル環境でクエリをテスト・反復してから本番規模でデプロイするという、一般的なパターンを扱います。まずクライアントに DuckDB をインストールし、次の図のように S3 テーブルバケットに格納されたテーブルへアクセスするための Lake Formation のアクセス許可を接続します。その後、クライアント上の DuckDB インスタンスにカタログをアタッチし、テーブルに対するクエリを試します。 前提条件 本記事の手順を実行するには、次の AWS サービスにアクセスできる AWS アカウントが必要です。 Amazon S3 Tables AWS Identity and Access Management (IAM) Amazon SageMaker Lakehouse Amazon Athena AWS Lake Formation ウォークスルー 本ソリューションを実装するには、S3 テーブルバケットにテーブルを用意し、テーブルを読み取るためのアクセス許可を設定し、ローカルクライアントに DuckDB インスタンスを構成する必要があります。以降のセクションで各ステップを説明します。 Part A: S3 Tables のセットアップ Part B: アクセス許可のセットアップ (オプション) Part C: DuckDB のセットアップ Part A: S3 Tables のセットアップ DuckDB は現時点で S3 Tables を読み取り専用モードでサポートしています。アカウントにテーブルがない、または AWS 分析サービスとの統合が未設定の場合は、以下の手順に従ってください。すでに設定済みであれば、本セクションはスキップできます。本セクションでは、テーブルバケットの作成、テーブルのセットアップ、データ追加を通じて、DuckDB で分析するためのデータを準備する手順を説明します。すでにデータが入ったテーブルがある場合は、本セクションをスキップして次のセクションに進んでください。 1. S3 テーブルバケットを作成し、AWS 分析サービスとの統合をセットアップする 1.1. AWS マネジメントコンソール で S3 に移動します。左のナビゲーションメニューから Table buckets を選択し、 Create table bucket を選びます。テーブルバケット名を指定し、次の図のように AWS 分析サービスとの統合が未有効の場合は Enable integration を選択します。この統合により、この AWS リージョン とこのアカウントで作成されたすべてのテーブルを SageMaker Lakehouse と Lake Formation で検出でき、 Amazon Data Firehose 、Athena、 Amazon Redshift 、 Amazon EMR などの AWS 分析サービスからアクセスできるようになります。統合の詳細は、 Using Amazon S3 with analytics services を参照してください。 1.2. テーブルバケット mytraveldata が作成されました。DuckDB のセットアップで後ほど使うため、コピーアイコンでテーブルバケットの Amazon リソースネーム (ARN) をコピーしておきます。 2. テーブルバケットに新しいテーブルを作成する 2.1. S3 コンソールで対象のバケットに移動し、 Create table with Athena を選択します。 2.2. テーブルバケット内に名前空間とテーブルを作成する Create table ワークフローで Namespace name を追加します。 続けて Create table with Athena に進みます。 SageMaker Lakehouse に nyc という名前のデータベースが作成されます。 2.3. Athena クエリエディタで、次の SQL コマンドを使ってテーブルを作成します。 CREATE TABLE nyc.nyc_trips (trip_id INT, pickup_datetime TIMESTAMP, dropoff_datetime TIMESTAMP, passenger_count INT, trip_distance DOUBLE, fare_amount DOUBLE, payment_type STRING, pickup_zone STRING) TBLPROPERTIES ( 'table_type'='ICEBERG' ); 3. S3 Tables にデータを挿入する ここでは、次の SQL コマンドを使い、ニューヨーク市のタクシー走行に関するサンプルデータを、作成済みのテーブルに挿入します。 INSERT INTO nyc.nyc_trips (trip_id, pickup_datetime, dropoff_datetime, passenger_count, trip_distance, fare_amount, payment_type, pickup_zone) VALUES (1, TIMESTAMP '2023-03-01 08:30:00', TIMESTAMP '2023-03-01 09:15:00', 2, 5.8, 22.50, 'Credit Card', 'Midtown'), (2, TIMESTAMP '2023-03-01 12:15:00', TIMESTAMP '2023-03-01 12:45:00', 1, 3.2, 15.00, 'Cash', 'Upper East Side'), (3, TIMESTAMP '2023-03-01 17:00:00', TIMESTAMP '2023-03-01 17:45:00', 3, 7.1, 28.75, 'Credit Card', 'Financial District'), (4, TIMESTAMP '2023-03-02 09:45:00', TIMESTAMP '2023-03-02 10:30:00', 1, 4.5, 18.25, 'Credit Card', 'Chelsea'), (5, TIMESTAMP '2023-03-02 14:30:00', TIMESTAMP '2023-03-02 15:15:00', 2, 6.3, 24.50, 'Cash', 'Greenwich Village'), (6, TIMESTAMP '2023-03-02 20:00:00', TIMESTAMP '2023-03-02 20:30:00', 4, 2.8, 14.75, 'Credit Card', 'Times Square'), (7, TIMESTAMP '2023-03-03 07:15:00', TIMESTAMP '2023-03-03 08:00:00', 1, 8.2, 32.00, 'Credit Card', 'Brooklyn Heights'), (8, TIMESTAMP '2023-03-03 11:30:00', TIMESTAMP '2023-03-03 12:15:00', 2, 5.5, 21.75, 'Cash', 'East Village'), (9, TIMESTAMP '2023-03-03 16:45:00', TIMESTAMP '2023-03-03 17:30:00', 3, 6.7, 26.25, 'Credit Card', 'SoHo'), (10, TIMESTAMP '2023-03-03 22:00:00', TIMESTAMP '2023-03-03 22:45:00', 1, 4.9, 19.50, 'Cash', 'Upper West Side'); この SQL コマンドを実行すると、データが nyc_trips テーブルに取り込まれます。 Part B: アクセス許可のセットアップ (オプション) 当該アカウントで AWS 分析サービスとテーブルバケットの統合を行ったユーザーとは別のユーザーの場合、テーブルに対する Lake Formation のアクセス許可を付与してもらう必要があります。詳細は Grant permission on a table or database を参照してください。本記事では、コンソール上で AWS 分析サービスとの統合を行った同じユーザーが、DuckDB インスタンス経由でテーブルにアクセスすることを前提とします。 Part C: DuckDB のセットアップ 1. DuckDB をインストールする DuckDB のインストールページ にアクセスし、最新の DuckDB Command line (執筆時点は v1.2.1) を入手します。 Installation セクションの curl コマンドをコピーします。 AWS マネジメントコンソールで CloudShell 環境に移動します。 次の curl コマンドを実行します。 curl https://install.duckdb.org | sh 次の図は curl コマンドの実行例です。 2. CloudShell インスタンスで DuckDB インスタンスを実行する DuckDB インスタンスを起動するには、AWS Command Line Interface (AWS CLI) で次のコマンドを入力します。 /home/cloudshell-user/.duckdb/cli/latest/duckdb 3. Iceberg 拡張機能をロードする S3 Tables の DuckDB サポートは、現時点では nightly 拡張ビルドの一部として提供されています。最新の Iceberg 拡張機能をインストールするには、次のコマンドを実行します。 FORCE INSTALL iceberg FROM core_nightly; ここまでで DuckDB インスタンスのセットアップは完了です。 4. AWS 認証情報を登録する AWS 認証情報を含むシークレットを作成します。CloudShell を使用している場合、これは AWS コンソールの認証情報にあたります。DuckDB はこのシークレットを使ってテーブルデータにアクセスします。設定オプションの詳細は DuckDB のドキュメント を参照してください。 CREATE SECRET (   TYPE S3,   PROVIDER credential_chain ); 5. カタログをデータベースとしてアタッチする ここでは、テーブルバケットをデータベースインスタンスとして DuckDB にアタッチします。 ATTACH '<account-id>:s3tablescatalog/mytraveldata' AS duck_db (TYPE ICEBERG, ENDPOINT_TYPE 'GLUE'); 6. テーブルバケットに格納されたデータにアクセスする 次のコマンドを使い、DuckDB がテーブルバケット内のテーブルを検出できることを確認します。 SHOW ALL TABLES; 結果から、 mytraveldata には nyc という名前空間が 1 つあり、その中に nyc_trips というテーブルが 1 つ存在することがわかります。以下はテーブルに格納されたデータを分析するサンプルクエリの例です。 6.1. テーブルに格納されたすべてのデータを表示します。 SELECT * from duck_db.nyc.nyc_trips 6.2. 支払い方法別の運賃合計を取得します。 SELECT payment_type, SUM(fare_amount) AS total_fare FROM duck_db.nyc.nyc_trips GROUP BY payment_type; 6.3. 2023 年 3 月 1 日の走行に対する運賃合計を取得します。 SELECT SUM(fare_amount) AS total_fare FROM duck_db.nyc.nyc_trips WHERE pickup_datetime BETWEEN '2023-03-01 00:00:00' AND '2023-03-01 23:59:59'; 本記事では、DuckDB インスタンスへの接続に Amazon SageMaker Lakehouse Iceberg REST エンドポイント を利用しました。もう 1 つの選択肢として、 S3 Tables Iceberg REST Catalog API で DuckDB に接続することもできます。この場合は、次の ATTACH コマンドを使用します。 ATTACH '<table-bucket-arn>' AS duck_db (TYPE ICEBERG, ENDPOINT_TYPE 'S3_Tables'); 1 つの S3 テーブルバケット内の表形式データに基本的な読み取りアクセスが必要な場合は S3 Tables Iceberg REST Catalog API を使い、すべての表形式データを対象とした統一的なデータ管理、データガバナンス、きめ細かなアクセス制御が必要な場合は S3 Tables を SageMaker Lakehouse と組み合わせて利用できます。 クリーンアップ リソースをクリーンアップするには、次の手順を実行してください。 S3 テーブルを 削除 する。 テーブルバケット内の名前空間を 削除 する。 S3 テーブルバケットを 削除 する。 まとめ 本記事では、Amazon SageMaker Lakehouse と AWS Lake Formation のアクセス許可を活用し、DuckDB で Amazon S3 上の Iceberg テーブルを読み取る方法を紹介しました。S3 テーブルバケットにテーブルを作成し、データを投入し、DuckDB クライアントからテーブルにアクセスする流れをウォークスルーしました。DuckDB と Amazon S3 Tables を組み合わせることで、小規模から大規模までのあらゆる環境で、追加のインフラなしにデータレイク内のテーブルを扱えます。 著者について Anupriti Warade Anupriti Warade は AWS の Amazon S3 チームで Senior Technical Product Manager を務めています。お客様のイノベーションと課題解決につながるソリューションの構築に情熱を注いでいます。ワシントン州シアトルを拠点に、家族や友人との時間、料理、DIY クラフトを楽しんでいます。 Yuri Zarubin Yuri Zarubin は AWS の Amazon S3 チームで Principal Engineer を務めています。データ保護を専門とし、S3 Replication のエキスパートです。現在は S3 Tables を Apache Iceberg テーブル向けにもっとも高性能なストレージソリューションとするための開発に取り組んでいます。余暇は旅行と、子どもと一緒に遊ぶ次の PC ゲーム探しを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2026 年 4 月 15 日 に公開された「 Get to insights faster using Notebooks in Amazon SageMaker Unified Studio 」を翻訳したものです。 本記事では、Amazon SageMaker Unified Studio のノートブックがインフラの設定を簡素化し、インサイト獲得までの時間を短縮する仕組みを紹介します。住宅価格データの分析、スケーラブルなデータテーブルの作成、分散プロファイリング、機械学習 (ML) モデルの学習を、単一のノートブック環境で行う流れをご覧いただけます。 データサイエンティストやアナリストは、分析を始めるまでにインフラ設定と複数データソースの認証管理に何日も費やすことがしばしばあります。Amazon Simple Storage Service (Amazon S3)、Amazon Redshift、Snowflake、ローカルファイルにまたがるデータを扱う場合、認証設定の繰り返し、コンピュートスケーリングの手動判断、ツール切り替えの手間が積み重なり、インサイト獲得が遅れます。 Amazon SageMaker Unified Studio のノートブックは、12 以上のデータソースへの即時アクセス、ローカルから分散処理までのコンピュートスケーリング、AI によるコード生成を、単一のブラウザベース環境で提供します。ポリグロットプログラミング、マルチエンジンコンピュート、AI 支援による開発を活用し、疑問からインサイトまでの道のりを短縮する方法を解説します。 Amazon SageMaker Unified Studio のノートブックとは Amazon SageMaker Unified Studio のノートブックは、データ分析、探索、エンジニアリング、機械学習ワークフローのためのインタラクティブな環境を提供します。統合された 5 つの機能を備えています。 ポリグロットプログラミング : 同じノートブック環境で Python と SQL を相互に切り替えながらコードを書けます 統合されたデータアクセス : Amazon S3、AWS Glue Data Catalog、Apache Iceberg テーブル、Snowflake や BigQuery などのサードパーティソースに保存されたデータへ即座に接続できます ネイティブな可視化 : Python や SQL の結果から直接チャートを作成し、没入感のあるデータ分析ができます AI による開発支援 : SageMaker Data Agent を通じて自然言語プロンプトでコードを生成できます。データ分析、データサイエンス、ML タスク向けの的確なチャットインターフェイスを備えています 柔軟なコンピュート : ニーズの拡大に応じて、基本的なインスタンスから GPU 搭載環境までスケールできます アーキテクチャ 本セクションでは、ノートブックのアーキテクチャを説明します。ノートブックは、複数のコンピュートエンジン、多様なデータソース、AI アシスタントを統合したクラウドネイティブアーキテクチャにより、ブラウザベースのシンプルさでエンタープライズ規模の分析を実現します。 プレゼンテーション層 Amazon SageMaker Unified Studio 経由でノートブックインターフェイスにアクセスします。コード実行用のコードセル、ドキュメント用のマークダウンセル、チャートやテーブル用の可視化セルを備えた、使い慣れたインターフェイスで操作できます。 コンピュート層 専用のノートブックサーバーがカーネルのライフサイクルとセッション状態を管理します。主要コンポーネントには、コード補完用の Language Server、データサイエンスライブラリをプリロードした Python 3.11 ランタイム、Python、PySpark、SQL の実行を同じノートブック内で処理する Polyglot Kernel が含まれます。作成した各ノートブックは、永続的な Amazon Elastic Block Store (Amazon EBS) ストレージにバックアップされます。 実行層 ノートブックは複数の実行エンジンをサポートし、コードを最適な処理エンジンに自動的にルーティングします。インメモリ実行は、小規模なデータセットや迅速なプロトタイピングを処理します。Amazon Athena 経由の Apache Spark は、Spark Connect を介した大規模分析向けの分散処理を提供します。Amazon Athena (Trino)、Amazon Redshift、Snowflake、BigQuery へのネイティブ接続により、SQL クエリを処理します。 データ統合 AWS ネイティブ (Amazon S3、AWS Glue、Amazon Athena、Amazon Redshift) とサードパーティ (Snowflake、BigQuery、PostgreSQL、MySQL) を含む 12 以上のデータソースに統一的にアクセスできます。サポートされている最新のデータソースについては、 Connect to data sources を参照してください。 AI 層 SageMaker Data Agent は、2 つのモードで利用できます。複数ステップの分析ワークフロー向けの Agent Panel と、セル単位のコード生成に特化した Inline Assistance です。詳細は Accelerate context-aware data analysis and ML workflows with Amazon SageMaker Data Agent を参照してください。 作業を保護するため、セキュリティはアーキテクチャ全体に組み込まれています。データアクセスは AWS Identity and Access Management (AWS IAM) の権限に従います。ノートブックとエージェントは、利用が許可されたデータソースにのみアクセスできます。コンポーネント間の通信は暗号化チャネルを使用し、ノートブックのストレージは保存時に暗号化されます。AI エージェントには、破壊的な操作を防ぐガードレールが組み込まれており、コンプライアンスと監査のためにやり取りをログに記録します。 前提条件 始める前に、以下が必要です。 Amazon SageMaker Unified Studio のリソースを作成する権限を持つ AWS アカウント。必要な権限の詳細は、 Set up IAM-based domains を参照してください。 Python プログラミングと SQL クエリの基本的な知識 データ分析の概念と ML ワークフローの理解 サンプルの住宅データセットへのアクセス (ウォークスルー内で提供) ノートブックを使い始める まず、 Amazon SageMaker コンソール を開き、 Get started を選択します。 データとコンピュートへのアクセス権を持つ既存の AWS Identity and Access Management (AWS IAM) ロールを選択するか、新規ロールを作成するかを求められます。本ウォークスルーでは、 Create a new role を選択し、他のオプションはデフォルトのままにします。 Set up を選択します。環境の準備には数分かかります。 ユースケース 本記事では、ノートブックと SageMaker Data Agent を使って以下を実行します。 データセットの操作: サンプルデータセット housing.csv をアップロードし、データエクスプローラーで探索 ポリグロットプログラミング: DuckDB 経由で SQL によるデータフレームのクエリ AWS Glue によるマルチエンジンアクセス: AWS Glue テーブルを作成し、Athena SQL/Spark エンジンで分散処理を実行 高度な分析: Athena Spark でデータプロファイリング AI 支援による開発: Data Agent でプロファイリングと ML のコードを生成 ML ワークフロー: Random Forest モデルを学習し、結果を評価 まずインターフェイスを見て、コア機能を確認しましょう。 インターフェイスの理解 ノートブックのインターフェイスは、コード実行用のセルとドキュメント用のマークダウンという、使い慣れたノートブック規約に従っています。ノートブック内では、現在のプログラミング環境 (Python 3.11 など) とコンピュートプロファイルの仕様を確認できます。このインターフェイスでは以下ができます。 ファイルの参照、データカタログの探索、サードパーティ接続の管理を通じてデータにアクセス ノートブックのコンテキスト内で作成された変数を監視 ワークロード要件に応じて仮想 CPU と RAM を調整し、GPU インスタンスまでオンデマンドでコンピュートリソースをスケール Python パッケージを必要に応じてインストールおよび設定してパッケージを管理 データセットの操作 本ウォークスルーでは、 このページ からダウンロードできる housing.csv サンプルデータセットを使用します (リンク先ではファイル名が canvas-sample-housing.csv になっています)。左パネルの Files アイコンを選択し、 Local タブを選択します。 Local タブでノートブックに CSV ファイルをアップロードします。 ノートブックはデータ資産への即時アクセスを提供します。データエクスプローラーを使えば、AWS Glue Data Catalog、Amazon S3 テーブルカタログ、Amazon S3 バケット、設定済みのサードパーティ接続を参照できます。 3 点リーダーのオプションメニューを選択します。 Read as dataframe を選択し、ノートブックに挿入されたセルを実行して結果を確認します。 import pandas as pd <<df_csv_xxxx>> = pd.read_csv('housing.csv') <<df_csv_xxxx>> データフレームを返すと、ノートブックは自動的なデータプロファイリングを備えたリッチなテーブル形式で表示します。 ポリグロットプログラミング: Python と SQL を同時に ノートブックのもっとも強力な機能の 1 つが、Python と SQL の相互運用性です。データを Python のデータフレームに読み込んだ後、すぐに SQL でクエリできます。たとえば、海への近さ別に人口と世帯数の合計を計算するには、次のように実行します。 select sum(population) ,sum(households),ocean_proximity from<<df_csv_xxxx>> group byocean_proximity ノートブックのオートコンプリート機能はコンテキスト内のデータフレームを認識するため、SQL クエリを直感的に書けます。 この SQL クエリは DuckDB (インメモリの SQL データベースエンジン) 上で実行され、個別のインストールやサーバー保守は不要です。DuckDB は軽量な設計で、Python、Java、その他の環境に組み込めるため、迅速な対話型データ分析に適しています。分散処理が必要な場合は、データセット用の AWS Glue テーブルを作成した後、Apache Spark や Trino などのエンジンを使用できます。 データセット用の AWS Glue テーブルを作成する AWS Glue テーブルを作成すると、Amazon Athena SQL (Trino) や Amazon Athena Spark など、AWS Glue カタログ対応のさまざまなエンジンでデータセットをクエリできます。これらのエンジンは、それぞれのワークロード要件に対して最適な価格性能比を提供します。 まず AWS Glue データベースを作成します。ノートブックで新しいセルを作成するために SQL を選択し、 Amazon Athena (SQL) を選びます。 次の SQL を実行してデータベースを作成します: create database demo; 次に、データエクスプローラーに移動し、左上の +Add を選択して Create table を選びます。先ほど作成したデータベースを選択し、テーブル名を入力します。先ほど使用した housing.csv データセットファイルをアップロードします。サイドパネルで Next を選択して、テーブルを作成します。 次に、Amazon Athena SQL を使って新しいセルでサンプル SQL クエリを実行してみましょう。 select sum(population) , sum(households), ocean_proximity fromdemo.housing group by ocean_proximity Athena Spark による高度な機能 住宅価格を予測する ML モデルを構築する前に、データセットをさらに分析し、追加のインサイトを得るためにデータプロファイリングを実行しましょう。高度な探索には、ノートブック内で Amazon Athena Spark を使用できます。そのために、組み込みの Spark セッションを持つ新しい Python セルを作成します。次のコードを実行して Spark のバージョンを確認します。 # Verify Spark version spark.version SageMaker Data Agent によるデータプロファイリング 定型的なコードを手動で書く代わりに、組み込みの生成 AI 機能を活用できます。 プロンプト : 「Perform data profiling and create visualization for housing table」 AI アシスタントは、基本統計の算出、列単位のプロファイリング、データ型の分析、欠損値の検出を含む、包括的なプロファイリングコードを生成します。 エージェントは AWS Glue Data Catalog にアクセスし、housing テーブルの構造を把握したうえで、対象の列とデータ型に合わせたプロファイリングコードを生成しました。この文脈認識により、汎用的なコードスニペットを自環境向けに調整する際にありがちな試行錯誤が減ります。生成されたコードを確認して実行します。応答が速いため、分析を効率的に反復できます。 エラーが発生した場合は、次の図のように Fix with AI で解決できます。実行時にエラーが発生すると、 Fix with AI 機能がトレースバックを分析し、根本原因を診断して修正済みコードを生成するため、分析を止めずに進められます。 ML モデルの学習 次に、Data Agent を使って住宅価格を予測するモデルの学習コードを生成します。 プロンプト: 「Generate code to train a model that predicts housing prices. Use table housing.」 AI アシスタントは、次のようなエンドツーエンドのコードを生成します。 Amazon Athena Spark を使って AWS Glue カタログから住宅データを読み込み、pandas に変換 文字列型の列を数値化し、One-Hot エンコーディングでエンコードし、欠損値を除去 Random Forest モデルを学習して住宅価格の中央値を予測 モデル性能を評価 (RMSE、MAE、R-square) 予測に対する重要度が高い上位 10 個の特徴量を表示 この複数ステップのオーケストレーションにより、データアクセスからモデル評価までのワークフロー全体を任せられ、開発時間を数時間短縮できます。 エラーが発生した場合は、結果のトレースバックセクションにある Fix with AI で解決できます。 このワークフローでは、ノートブックの統合機能を紹介しました。ローカルからファイルをアップロードし、マルチエンジンアクセス用に AWS Glue テーブルを作成し、Amazon Athena Spark で分散プロファイリングを実行し、AI 支援による ML 開発で住宅価格を予測しました。これらすべてを、ツールを切り替えずに 1 つのノートブック環境で行いました。 主なメリットとベストプラクティス Amazon SageMaker Unified Studio のノートブックには、いくつかの利点があります。 インサイト獲得までの時間短縮 : 従来の環境では、分析を始める前に設定に数時間かかることもあります。ノートブックはこうした負荷を回避し、すぐに作業を始められます。 コラボレーションの向上 : 一貫した環境でノートブックを共有でき、再現性が確保され、「自分の環境では動く」問題が減ります。 複雑性の低減 : データソースや処理エンジンごとに別々のツールを使い分けるのではなく、複数のデータソースとコンピュートエンジンに 1 つのインターフェイスからアクセスできます。 AI による開発の加速 : タスク特化型のコードを生成し、的確な提案を受けられるため、繰り返しのコーディング作業にかかる時間を減らせます。 スケーラブルな性能 : メガバイトからペタバイト規模のデータセットを、適切なコンピュートリソースで処理できます。データ量の増加に応じてシステムが自動的にスケールします。 ベストプラクティス まずは小さめのインスタンスから始め、ニーズの拡大に合わせてスケールアップする形で、適切な コンピュートプロファイル で開始する。 繰り返し作業や複雑な操作には、自然言語プロンプトで AI アシスタントを活用する 。 大規模処理には Amazon Athena Spark、データウェアハウスには Amazon Redshift、その他特定のワークロードには専用エンジンを使うなど、 エンジンを戦略的に組み合わせる 。 マークダウンセルを使い、コードと並行して 作業内容を文書化する ことで、生きたドキュメントを作る。 複雑なワークフローを論理的なステップに分割し、 複数のセルで整理する ことで、可読性とデバッグ性を高める。 クリーンアップ 今後の課金を避けるため、本ウォークスルーで作成したリソースを削除します。 Amazon SageMaker Unified Studio コンソールで、Notebook ページに移動する ノートブックを削除する AWS Glue Data Catalog から demo データベースと housing テーブルを削除する 本ウォークスルーで作成した Amazon SageMaker Unified Studio ドメインを削除する 本ウォークスルー用に新しい IAM ロールを作成した場合は、IAM コンソールから削除する まとめ 本記事では、Amazon SageMaker Unified Studio のノートブックが作業効率を高め、インサイトをより速く提供する仕組みを紹介しました。使い慣れたノートブックインターフェイスに、エンタープライズ規模のコンピュート、マルチエンジンサポート、生成 AI 支援を組み合わせることで、チームはデータと AI のワークフローを効率化できます。 Python と SQL の統合、多様なデータソースへの即時アクセス、的確なコード生成機能により、ノートブックは現代のデータチームにとって価値あるツールになります。探索的データ分析、複雑なデータパイプラインの構築、ML モデルの学習を、単一の直感的な環境で必要な柔軟性とパワーを備えて実行できます。 使い始める準備はできましたか? Amazon SageMaker Unified Studio で最初のノートブックを作成 し、数分でデータ分析を始めましょう。 追加機能を探る: 季節分解と予測を用いた時系列分析ワークフロー テキスト分類や感情分析のための自然言語処理パイプライン ML モデルのバージョン管理のための Amazon SageMaker Model Registry との統合 ペタバイト規模の処理に対応する高度な Spark 最適化手法 詳細情報: Amazon SageMaker Unified Studio Administrator Guide Amazon SageMaker Unified Studio User Guide Notebooks in SageMaker Unified Studio Use the SageMaker Data Agent Pricing information 著者について Praveen Kumar Praveen Kumar は AWS の Principal Analytics Solutions Architect で、クラウドベースのサービスを用いた最新のデータおよび分析アプリケーションの設計、構築、実装に精通しています。関心領域はサーバーレステクノロジー、データガバナンス、データドリブンな AI アプリケーションです。 Majisha Namath Parambath Majisha Namath Parambath は Amazon SageMaker の Principal Engineer で、AWS で 10 年以上の経験を積んでいます。エージェント型システムを重視した包括的なデータ分析とインタラクティブな機械学習機能を提供する次世代サービス、Amazon SageMaker Unified Studio の重要な取り組みを主導しています。専門はシステム設計、アーキテクチャ、部門横断の実行で、エンタープライズ規模でのセキュリティ、パフォーマンス、信頼性に注力しています。エンジニアリング以外では、読書、料理、スキーを楽しんでいます。 Siddharth Gupta Siddharth Gupta は SageMaker の Unified Experiences で生成 AI を率いており、AI システムが複雑なタスクをユーザーに代わって自律的に実行する、エージェント型体験の推進に注力しています。以前は AWS でエッジ機械学習ソリューションを率いていました。彼の仕事は、開発者やデータサイエンティストが AI とやり取りする方法の改善、より直感的なデータ統合の実現、機械学習モデルを構築・デプロイするためのより良いツール作りに焦点を当てています。University of Illinois at Urbana-Champaign 出身で、Yahoo、Glassdoor、Twitch で豊富な経験を積んでいます。 LinkedIn で連絡できます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

概要 Amazon CloudWatch Logs が Application Load Balancer (ALB) のログを Vended Logs としてサポート しました。これにより、ALB の健全性とパフォーマンスを追加の設定や開発なしで可視化できます。ALB の 3 種類のログ (アクセスログ、接続ログ、ヘルスチェックログ) は、いずれもフィールド名の付いた構造化 JSON として配信されます。そのため、5xx エラーの原因がロードバランサー側かアプリケーション側かを切り分ける、レイテンシー上昇の要因になっているルートを特定する、失敗しているヘルスチェックを診断する、といった対応がすぐに行えます。 Amazon S3 バケットの管理、 Amazon Athena のテーブル設定、独自の ETL パイプラインは一切不要です。 以下のダッシュボードは、リクエスト量とステータスコードの分布、ロードバランサーとターゲットのどちらに起因するかを切り分けたエラー傾向、ルートごとのレイテンシーパーセンタイル、ターゲットのヘルス状態、クライアント/ターゲットの上位ランキングを表示します。このダッシュボードは、本記事で提供する AWS CloudFormation テンプレート を使ってデプロイしたものです。 図 1: ロードバランサー全体のリクエスト量、エラー分析、レイテンシー内訳を表示する ALB Insights ダッシュボード はじめに AWS 上でエンドユーザーに公開されるワークロードの大半では、Application Load Balancer がリクエストパス上に配置されています。ALB はアプリケーションよりも先にすべてのリクエストを受け取るため、ターゲットに到達しなかったリクエストまで把握しています。サービスに問題が生じたとき、オンコールエンジニアが最初に抱く「これはロードバランサーの問題か、ネットワークか、それとも自分のアプリケーションか」という疑問に答えてくれるのが ALB のログです。 ALB は次の 3 種類のログを出力します。 アクセスログ 接続ログ ヘルスチェックログ 今回のリリース以前は、これらのログは圧縮されたスペース区切りファイルとして Amazon S3 に出力されていました。そのため、S3 のライフサイクルポリシーを管理し、ALB がフィールドを追加するたびに Athena テーブルを保守し、アラート用に別のインフラを構築する必要がありました。今後は ALB のレコードが VPC フローログ、AWS WAF ログ、アプリケーションログと同じ場所に届くため、CloudWatch Logs がすでに備えている機能をそのまま活用できます。具体的には、Log Analytics、メトリクスフィルター、Contributor Insights、Live Tail、異常検出、そしてクロスアカウント・クロスリージョンの集約です。 導入手順: 有効化とデプロイ このセクションでは、テレメトリ有効化ルール (Telemetry enablement rules) で ALB ログの配信を有効にし、提供している CloudFormation テンプレート でサンプルダッシュボードをデプロイするまでの手順を説明します。 ステップ 1: テレメトリ有効化ルールで ALB ログの取り込みを有効化する Amazon CloudWatch のテレメトリ有効化ルール を使うと、AWS リソースのテレメトリ収集を自動的に設定できます。ルールを使えば、組織全体でテレメトリ収集の方法を統一し、監視範囲を一定に保てます。1 つのルールは、スコープ内にある既存のロードバランサーと新しく作成されるロードバランサーの両方に配信設定を適用します。そのため、一度ロギングを有効にしておけば、デプロイパイプラインが後から作成するロードバランサーも自動的にカバーされます。 ALB ログの CloudWatch への取り込みを有効化する手順は次のとおりです。 管理アカウントまたは委任管理者アカウントで CloudWatch コンソール を開きます。 ナビゲーションペインで 取り込み 、続いて 有効化ルール を選択します。 ルールを追加 を選択します。 データソース で Amazon Elastic Load Balancer – アプリケーション を選択し、 テレメトリを設定 をクリックします。 ルール名 に分かりやすい名前 (例: ALB-Logs-Enablement ) を入力します。 ルールのスコープ で 組織 、 組織単位 、 アカウント のいずれかを選択します。 図 2: ステップ 1「範囲を指定」: ルール名、ソースアカウント、オプションのデータソースタグ、対象リージョン ロググループ名のパターン 、 保持期間 、 出力形式 を設定し、内容を確認してルールを作成します。 Telemetry type で Logs を選択し、収集したいログタイプ (アクセスログ、接続ログ、ヘルスチェックログ) を選びます。 (オプション) タグのキー/値のペアを追加して、ルールの対象を一部のロードバランサーに絞り込みます (例: Environment: Production)。 図 3: ステップ 2「送信先を指定」: ロググループ名のパターン、保持期間、暗号化、3 種類の ALB ログタイプの選択 内容を確認し、 Amazon Elastic Load Balancer – アプリケーション Logs を設定 をクリックします。 図 4: ステップ 3「確認と作成」: ルール名、ソースアカウント、対象リージョン、CloudWatch Logs の送信先、選択したログタイプのサマリー 有効化ルールが有効になると、CloudWatch はルールのスコープ内にあるリソースから ALB ログの取り込みを開始します。ログは自動的に構造化 JSON 形式へ変換され、CloudWatch Logs のロググループに保存されます。3 種類のログはすべて同じロググループに届き、次のようにログストリームのプレフィックスで区別されます。 アクセスログ – ALB_Access_Logs/app/<lb-name>/<lb-id> 接続ログ – ALB_Connection_Logs/app/<lb-name>/<lb-id> ヘルスチェックログ – ALB_Health_Check_Logs/app/<lb-name>/<lb-id> ステップ 2: CloudFormation テンプレートで CloudWatch ダッシュボードをデプロイする CloudWatch ダッシュボード は、ALB のログデータを一元的に可視化する場を提供できます。サンプルダッシュボードは、CloudWatch Log Analytics のクエリ、メトリクス、Contributor Insights ルールを組み合わせて、監視対象のすべてのロードバランサーに共通する運用上のパターンを可視化します。運用チームはトラフィックの監視、エラーの調査、ターゲットのヘルス確認を 1 か所で行えるようになります。 図 5: リクエスト量、5xx エラー数、最も遅いターゲットの p99 レイテンシー、ステータスコード分布、ヘルスチェック詳細を示す ALB Insights ダッシュボード すぐに始められるよう、ダッシュボードをデプロイする CloudFormation テンプレートを用意しています。 CloudFormation の YAML テンプレート をダウンロードします。 AWS CloudFormation コンソール を開きます。 スタックの作成 > 新しいリソースを使用 (標準) を選択します。 テンプレートをアップロードし、 次へ を選択します。 スタック名を入力し、パラメーターを設定します。 DashboardName – ダッシュボードの名前 (デフォルト: ALB-Insights) DefaultTimeRange – ダッシュボードを開いたときに表示される期間 (デフォルト: -PT3H) CreateContributorInsightsRules – Contributor Insights ルールも作成する場合は Yes、ダッシュボードだけを作成する場合は No ALBLogGroupName – ALB ログを受け取るロググループ (デフォルト: /aws/elb)。Contributor Insights ルールでのみ使用されます。 ResourcePrefix – ルール名に付けるプレフィックス (デフォルト: ALB) 次へ を選択し、必要に応じてスタックオプションを設定して 次へ を選択します。 設定内容を確認し、 送信 を選択します。 スタックの作成が完了すると CloudWatch ダッシュボードが利用可能になり、イベントが届くにつれて ALB ログのパターンが表示されていきます。 図 6: ダッシュボードと 2 つの Contributor Insights ルールが CREATE_COMPLETE になった CloudFormation のリソースタブ Log Analytics による ALB ログの分析 ダッシュボードをデプロイした後は、アドホックなクエリを直接実行することもできます。 CloudWatch コンソール で ログ > ログ分析 を開いてください。ここでは、運用でよく問われる疑問に答えるクエリを紹介します。 5xx はロードバランサー由来かアプリケーション由来か SOURCE logGroups() | filterIndex @data_source_name in ["aws_alb"] | filterIndex @data_source_type in ["access"] | filter elb_status_code >= 500 | parse elb /^app\/(?[^\/]+)/ | fields if(target_status_code = "-", "load balancer / network", "target application") as owner | stats count(*) as errors, count_distinct(target_port) as targets_affected, earliest(time) as first_seen, latest(time) as last_seen by owner, lb, elb_status_code | sort errors desc 遅いルートはどれか SOURCE logGroups() | filterIndex @data_source_name in ["aws_alb"] | filterIndex @data_source_type in ["access"] | filter target_processing_time >= 0 | parse request_line /^(?\S+)\s+(?\S+)/ | parse url /^[a-z]+:\/\/[^\/]*(?[^?]*)/ | parse path /^\/(?[^\/]*)\/?(?[^\/]*)/ | fields if(s2 = "", concat("/",s1), concat("/",s1,"/",s2)) as route | stats count(*) as requests, avg(target_processing_time)*1000 as avg_ms, pct(target_processing_time,90)*1000 as p90_ms, pct(target_processing_time,99)*1000 as p99_ms, max(target_processing_time)*1000 as max_ms by route | sort p99_ms desc | limit 15 アクセスログとヘルスチェックログを組み合わせたターゲット別の信頼性 SOURCE logGroups() | filterIndex @data_source_name in ["aws_alb"] | filterIndex @data_source_type in ["access","health_check"] | fields coalesce(target_port, target_addr) as target | filter ispresent(target) | parse elb /^app\/(?[^\/]+)/ | stats count(request_line) as requests, sum(elb_status_code >= 500) as errors_5xx, sum(elb_status_code >= 500)*100.0/count(request_line) as error_pct, pct(target_processing_time,99)*1000 as p99_ms, count(status) as probes, sum(status = "FAIL") as probe_failures by lb, target | sort probe_failures desc, errors_5xx desc | limit 20 ログアラームで ALB のヘルスチェック失敗を通知する CloudWatch ログアラーム を使うと、カスタムメトリクスを用意しなくても、Log Analytics のクエリから直接アラームを作成できます。クエリはスケジュールに従って実行され、集計式が算出した数値が設定したしきい値を超えるとアラームが発生します。ログアラームは Log Analytics と同じクエリ言語を使用し、カスタムメトリクスの取り込みや保存にかかる追加費用も発生しません。 例: ヘルスチェック失敗に対するアラーム CloudWatch コンソールを開き、 アラーム に移動します。 アラームの作成 を選択し、 データソース として ログ を選択します。 Log Analytics でクエリを作成する をクリックします。 以下のクエリを実行し、 アラームに進む をクリックします。 SOURCE logGroups() | filterIndex @data_source_name in ["aws_alb"] | filterIndex @data_source_type in ["health_check"] | filter status = "FAIL" | stats count(*) as probe_failures by elb 集計式 に SUM(probe_failures) を入力します。 アラームの状態 で より大きい を選択し、 0 を入力します。 スケジュール で実行頻度 (例: rate(5 minutes) ) を選択します。 開始時間オフセット を 300 秒に設定します (5 分間隔のスケジュールに合わせます)。 アラームを実行するデータポイント を 1 / 1 に設定し、最初の 1 回で検知するようにします。 通知用に Amazon SNS トピックを設定します。 ログアラームを作成 を選択します。 これでアラームは 5 分ごとにクエリを評価し、ヘルスチェックのプローブがひとつでも失敗するとアラーム状態になります。 (オプション) 機能の拡張 ここまでの有効化ルールと CloudFormation テンプレートだけでも、十分に使い始められます。以下では、さらに活用したいチーム向けのオプション機能を説明します。 パイプラインで取り込み時に ALB ログをエンリッチする CloudWatch Logs パイプライン は、取り込みの時点で ALB のレコードを処理します。これにより、ログがロググループに届く前にフィールドをエンリッチしたり、変換・整形したりできます。 パイプラインを作成する CloudWatch コンソール を開き、 取り込み > パイプライン に移動します。 パイプラインを作成 を選択します。 一般設定 ページで次を設定します。 データソースを選択 で AWS Application Load Balancer logs を選択します。 ログソースタイプ でエンリッチしたいログタイプ (Access、Connection、Health Check) を選択します。 Service access で Auto create and use a new service role を選択し、必要な IAM ロールを CloudWatch に作成させます。 次へ を選択し、パイプラインの送信先とロググループの設定を行います。 プロセッサを設定 ページで JSON を解析 プロセッサーを選択して追加し、データを変換します。以下は ALB ログで役立つプロセッサーの例です。 タイプを変換 (ミューテートイベント) – elb_status_code を文字列から整数に変換します。これにより、メトリクスフィルターでの数値比較 (例: { $.elb_status_code >= 500 }) が正しく評価されるようになります。 GeoIP (エンリッチ) – client_ip フィールドを基に地理情報 (国 ISO コード、都市名、ASN の組織名) をレコードに追加し、結果を新しい client_geo フィールドへ書き込みます。条件式 ( client_ip != "" ) を指定して、client_ip フィールドが空のレコードはスキップします。外部の IP 参照サービスを保守しなくても、「トラフィックはどこから来ているのか」をクエリだけで確認できるようになります。 翻訳 (ミューテートイベント) – 静的マッピングを使って、elb_status_code の値を人が読める elb_status_meaning フィールドに変換します (例: 503 -> “no_registered_or_healthy_targets”)。実行条件 ( elb_status_code != "" かつ elb_status_code != "200" ) を追加してエラーレスポンスのときだけ動作させれば、成功したリクエストにはこのフィールドが付かないため、ノイズを抑えられます。 図 7: JSONを解析、タイプを変換、GeoIP プロセッサーを追加したプロセッサー設定画面 Test processors を選択し、保存する前にサンプルのログイベントで設定を検証します。 内容を確認してパイプラインを作成します。 ALB ログを 1 つのアカウントに集約する 複数のアカウントにまたがってワークロードを運用している場合は、 CloudWatch Logs の集約 (centralization) を使って、複数のアカウントとリージョンのロググループを 1 つの送信先アカウントに統合できます。集約されたロググループには @aws.account と @aws.region のフィールドが付加されるため、プラットフォームチームは 1 か所からすべての環境をまとめてクエリできます。 詳細な手順は Amazon CloudWatch Logs の一元化を使用したログ管理の簡素化 を参照してください。 Contributor Insights Contributor Insights は、あるパターンに寄与している上位 N 件の要因を継続的にランキングします。テンプレートは次の 2 つのルールを作成します。 ルール キーフィールド ランキング対象 TopClientIPs-ConnectionLogs $.client_ip 接続数の多いクライアント IP の上位 (接続ログから) TopTargetsByRequests-AccessLogs $.target_port リクエスト量の多いターゲットの上位 (アクセスログから) 上位クライアント IP のルールを手動で作成する手順は次のとおりです。 CloudWatch コンソール を開き、 ログ > Contributor Insights に移動します。 もし、 Contributor Insights がメニューにない場合は ログ > ログ分析 を選択し、 オプトアウト (Log insights) をクリックしてください。） ルール を作成 を選択します。 ロググループ で ALB のロググループ (例: /aws/elb) を選択します。 ルールタイプ で カスタムルール を選択します。 ログの形式 で JSON を選択します。 コントリビューション で次を設定します。 キー に $.client_ip を入力します。 フィルター を追加します。 一致 に $.client_ip を入力します。 状態 に IsPresent を選択します。 値 で true を選択します。 集計 で カウント を選択します。 次へ を選択します。 ルール名 に ALB-TopClientIPs-ConnectionLogs を入力します。 次へ を選択します。 ルールを作成 を選択します。 図 8: 3 時間のウィンドウで接続数上位 10 件のクライアント IP をランキングする TopClientIPs-ConnectionLogs ルール クリーンアップ 料金の発生を止めるには、次の順序でリソースを削除します。 取り込み > 有効化ルール からテレメトリルールを削除します。 パイプラインを作成した場合は、 取り込み > パイプライン から削除します。 CloudFormation スタックを削除します (ダッシュボードと Contributor Insights ルールが削除されます)。 ALB のロググループを削除するか、保持期間を短く設定します。 まとめ ALB のアクセスログ、接続ログ、ヘルスチェックログが構造化 JSON として CloudWatch Logs へ直接配信されるようになり、ワークロードの入口をリクエスト単位・接続単位・ターゲット単位で可視化できるようになりました。有効化ルールを 1 つ作成すれば、AWS 組織内のすべてのロードバランサーをカバーできます。Log Analytics はロードバランサーの障害とアプリケーションの障害を切り分け、ログアラームは問題が起きたときに通知し、Contributor Insights はトラフィックの大半を占めるクライアントとターゲットを上位から示します。パイプラインもパース処理も追加のインフラも必要ありません。 まずは CloudWatch コンソールを開いて 取り込み > 有効化ルール に移動し、Application Load Balancer 向けのルールを作成してみてください。詳細は Amazon CloudWatch Logs のドキュメントを参照してください。 著者について Raviteja Sunkavalli Raviteja Sunkavalli は Amazon Web Services のシニアワールドワイドスペシャリストソリューションアーキテクトで、AIOps と生成 AI のオブザーバビリティを専門としています。複雑で分散したクラウド環境において、世界中のお客様がオブザーバビリティとインシデント管理のソリューションを実装できるよう支援しています。仕事以外では、クリケットをしたり、新しい料理のレシピを試したりして過ごしています。 Siva Guruvareddiar Siva Guruvareddiar は AWS のシニアソリューションアーキテクトで、お客様が高可用性システムを設計できるよう支援することに情熱を注いでいます。マイクロサービス、コンテナ化、オブザーバビリティ、サービスメッシュ、クラウド移行といった技術を活用してプラットフォーム基盤と内部アーキテクチャをモダナイズし、クラウドネイティブへの移行を加速させる支援をしています。LinkedIn: linkedin.com/in/sguruvar 本ブログは 2026 年 8 月 25 日に公開された Analyze Application Load Balancer Logs with Amazon CloudWatch Logs の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

本記事は「 Are AI coding agents actually getting better? 」を翻訳したものです。 Kiro IDE のコーディングエージェントがコードを書いたり変更したりすると、 diagnostics ツール が静的解析器を実行して出力をチェックします。これは、開発者がエディタ上で下線として目にするのと同じチェックです。実際にこのツールは、モジュールの import 漏れ（ Cannot find module 'aws-cdk-lib' or its corresponding type declarations ）、解決できない Java の import（ The import org.junit cannot be resolved ）、型の不一致（ Argument of type 'string | undefined' is not assignable to parameter of type 'string' ）、 implicitly typed any 、 undefined symbol といったものを検出します。これらは、本来であればビルド時になって初めて表面化するような種類の問題です。 Kiro での diagnostics ツールの実際の動きをおさらいするために、下のスクリーンショットはツールが動作している様子を示しています。次の TypeScript コードを考えてみてください。ツールは 2 件の 型の不一致 （Type ‘number’ is not assignable to type ‘string’ と Cannot assign to read-only ‘executionTime’）と、1 件の プロパティのハルシネーション （Property ‘itemAge’ does not exist on type ‘StackProps’）を報告します。これらの diagnostics は、エージェントに対して修正を生成し、変更を再検証するための具体的なフィードバックを与えます。この「生成 → 検証 → 修正」のループは、静的型付け言語を扱うときに頻繁に発生します。多くのよくあるコーディングエラーを、language server が早期に捕捉できるためです。 図1: diagnostics ツールの動作。エージェントは 3 件のエラー（25 行目の number を string に代入できない型不一致、45 行目の read-only な ‘executionTime’ への書き込み、55 行目の StackProps に存在しない ‘itemAge’ プロパティのハルシネーション）を検出し、ファイルを編集して再チェックし、残りエラーがゼロであることを確認しています。 この記事では、生成中のエージェントによる diagnostics ツールの呼び出しを調べます。すなわち、モデルがタスクの途中でどのくらいの頻度で自発的に静的解析器を呼び出すのか、それらの解析器がどのようなエラーを表面化させるのか、そしてモデルが最終的な編集を行う前にそれらを解決しているのか、という点です。 diagnostics は、開発者が IDE にインストールしている言語拡張機能によって生成されるため、チェックの内容はワークスペースの構成によって変わります。今回のデータでは、diagnostics は各エコシステムの標準的な解析器から生成されています。TypeScript/JavaScript は tsserver、Java は jdtls、Python は Pyright、Rust は rust-analyzer、Kotlin は Kotlin language server、Go は gopls、C/C++ は clangd、そして ESLint のようなスタイル・正当性のリンターです。Swift の diagnostics（ Cannot switch on a value of type Region. Only convertible int values, strings or enum variables are permitted ）も観測されました。さらに従来のコンパイルエラーの枠を超えて、Lean 4 の定理証明器の diagnostics も観測されており、ここではツールが構文の誤りではなく不完全な証明を指摘しています（ Dependent elimination failed: Failed to solve equation, unsolved goals ）。 この 6 か月間、Kiro はさまざまな モデルファミリーとバリアント をサポートしてきました。Opus 4.5 から 4.8、Sonnet 4 から 4.6 までです。 新しいモデルは単純にエラーを生成しなくなる、と予想するかもしれません。エラー率は確かに低下しているものの、実態はそれよりも込み入っています。これらのモデルは単に間違いを減らしているのではなく、異なる種類の間違いをするようになっているのです。以前の世代で支配的だったエラーのカテゴリが姿を消し、その代わりに新しいカテゴリが現れています。全体の軌跡は前向きですが、エラー構成のこの変化は理解しておく価値があります。この記事では、私たちが見つけたことを共有します。 最終状態の品質と、途中の自己修正シグナルを区別する。 AI コーディングエージェントが改善しているかどうかを評価するには、互いに補完的な 2 つの方法があります。1 つ目は事後（post-hoc）の静的解析で、エージェントの最終出力に対して固定の解析器一式を実行し、残存エラーを数える方法です。これは最終状態のコード品質（開発者が実際に受け取る成果物）を測るもので、「モデルは正しいコードを生成したか？」の最も直接的な代理指標です。2 つ目は本研究が調べるもので、生成中のエージェントによる diagnostics ツールの呼び出しです。すなわち、モデルがタスクの途中でどのくらいの頻度で自発的に静的解析器を呼び出すのか、それらの解析器がどんなエラーを表面化させるのか、そしてモデルが最終的な編集の前にそれらを解決しているのか、という点です。 この後者のシグナルは、2 つの理由からモデルの能力についてより多くを語ります。1 つ目に、これはモデルの自己監視の能力を捉えます。これは最終状態の計測では見えない振る舞い上の性質です。というのも、自分の成果物を一度もチェックせずにたまたまきれいなコードを出したモデルと、チェックしてエラーを検出し修復したモデルとは、最終状態だけを見ると区別がつかないからです。2 つ目に、呼び出しレベルのデータはより豊かな分解を可能にします。モデルが どの エラーカテゴリを生成するのか、そのうちどれを自律的に修正できるのか、そのために追加でどれだけのツール呼び出しがかかるのかを明らかにし、モデルの認知がどこで成功しどこで失敗するのかを粒度細かく見せてくれます。対して事後解析は、このプロセスを 1 つの合否ビットに畳み込んでしまいます。要するに、事後解析はユーザーが受け取った品質が 何であったか を教えてくれますが、diagnostics 呼び出しのデータはモデルがその品質を どのように 達成した（あるいは達成しそこねた）かを教えてくれ、時系列でのモデル改善の軌跡を診断するうえでより強力なシグナルになります。 データ 2026 年 1 月から 6 月までの 6 か月間の窓で、私たちは Kiro IDE における約 150 万件の会話を、7 つの Claude モデル（Opus 4.5 から 4.8、Sonnet 4 から 4.6）にわたり、TypeScript、Python、Java、Rust、Go、Kotlin、C++、Swift を含む複数の言語を対象に分析しました。データは Amazon 社内ユーザーから得たものです。 私たちは 40.6 万件の diagnostics 呼び出し、すなわちエージェントが静的解析拡張機能を使ってコードファイルをチェックする組み込みツールを呼び出した瞬間を抽出しました。Opus 4.5 と 4.6 が分析データの 51% 超を占め、ボリュームの大半を構成しています。より新しい Opus モデルはデータ点が少なめです。Sonnet 4.5 の呼び出しがさらに全分析リクエストの 45% を占め、Sonnet 4 と 4.6 はデータ点が少なめです。 これらの結果を解釈する際に心に留めておくべきことが 3 つあります。 私たちが測っているもの、測っていないもの。 ここで分析している diagnostics は、コーディングエージェントがファイル編集を行った後に実行される Kiro IDE の Diagnostics Tool から来ています。これはユーザーの環境にインストールされた拡張機能に依存します。典型的には language server や静的解析器（TypeScript の tsc、ESLint、Pylint など）に加え、リソースのプロパティ・必須引数・リソース参照をデプロイ前にチェックする CloudFormation や Terraform のバリデーターといったインフラ関連の拡張機能です。つまり、私たちが捉えているのは問題の一部にすぎません。ランタイムエラー、ロジックのバグ、パフォーマンス退行、そして動的解析やテストを要するものはすべて、このデータには見えません。diagnostics のチェックがクリーンであることは、コードが正しいことを意味しません。それは単に、コードが静的解析を通過したことを意味するだけです。 環境はユーザーごとに異なる。 利用できる diagnostics は、ユーザーがインストールしている拡張機能に依存します。厳格な ESLint ルールと CloudFormation バリデーターを備えた開発者は、最小構成の開発者よりも多くの警告を表面化させます。このことがユーザー間の比較をノイズの多いものにし、集計されたエラー率がコーディング品質 と ツールの厳格さの両方を混ぜ合わせたものになることを意味します。実務上は、AI のコーディング品質をエラー率に加えて、スタック別・言語別・環境別に評価すべきです。ただし、今回のデータは共通のツール標準とベストプラクティスを共有する Amazon 社内ユーザーから来ているため、このデータセットでの環境のばらつきは、一般的な開発者集団全体で見た場合よりも狭い可能性が高いです。 モデルの改善だけが変数ではない。 diagnostics は孤立して動作するわけではありません。steering プロンプト、hooks、subagents、その他のオーケストレーション層を含む、より広いシステムの中で動作します。これらのコンポーネントのいずれかがこの 6 か月の窓の中で変更されれば、モデルの能力改善とは独立にエラー率へ影響し得ます。ここで示された改善を、モデルのアップグレードだけにきれいに帰属させることはできません。一部はおそらく、周辺インフラの改善を反映しています。この 2 つを切り分けるには、オーケストレーション層を固定した対照実験が必要ですが、この観察データはそれを提供しません。 1. モデルはどのくらいの頻度で diagnostics を呼び出すのか？ まず私たちは、 diagnostics 呼び出し率 、すなわちモデルが diagnostics ツールを少なくとも 1 回呼び出したコーディング会話の割合を調べました。この比率は、モデルが自分の成果物をチェックするために、利用可能な diagnostics ツールをどれだけ積極的に使うかを捉えます。 図2: 各モデルが diagnostics ツールを少なくとも 1 回呼び出したコーディング会話の割合。Opus 4.5 が 14.58%、Opus 4.6 が 22.26%（最高点）、Opus 4.7 が 10.15%、Opus 4.8 が 10.85%、Sonnet 4 が 7.65%、Sonnet 4.5 が 2.74%（最低点）、Sonnet 4.6 が 13.89%。 Opus 4.6 が最も積極的で、会話の 22.26% で diagnostics を呼び出しています。しかし、その後の Opus のバージョン（4.7 と 4.8）は約 10% まで戻りました。Sonnet ファミリーは別の物語を語ります。Sonnet 4.5 は diagnostics をほとんど呼び出しませんでした（2.74%）が、Sonnet 4.6 は 13.89% へ跳ね上がりました。これはツールへの意識の高まりを示す大きな増加です。全体として呼び出し率はおおよそ 3〜22% で、ほとんどの会話が、モデルが静的に見つかるエラーを積極的にチェックしないまま完了していることを示しています。これは、モデルは学習時のツールをデフォルトで使い、明示的なプロンプトやファインチューニングなしには diagnostics ツールをめったに使わない、という 最近の知見 と整合します。同様の実験は、エラーが解決されるまでエージェントの確定をブロックするために diagnostics を使うと、誤ったコードの受け入れを約 90% から約 8% へ大幅に減らせることを示唆しています。これは、diagnostics を単に任意のツールとして利用可能にしておくよりもはるかに大きな効果です。 2. チェックされたファイルあたりの報告エラー数: モデルは良くなっているのか？ 私たちは、モデルのバージョンをまたいでファイルあたりの平均エラー数を比較しました。この指標は、生成されたコードがどれだけ「コンパイルに近い」かを捉えます。完全に成功しない場合でも、ファイルあたりのエラーが少なければ、手作業の修正が少なくて済みます。 図3: モデルのバージョン別の、チェックされたファイルあたりの平均 diagnostics エラー数。Sonnet の線は 3.01（Sonnet 4）から 2.90（Sonnet 4.5）、1.29（Sonnet 4.6）へ低下。Opus の線は 1.74（Opus 4.5）、1.21（Opus 4.6）、1.82（Opus 4.7）、1.21（Opus 4.8）で、両ファミリーとも最新版では 1.2 付近に収束。 Sonnet の線は明確な改善の物語を語ります。Sonnet 4 のファイルあたり 3.01 エラーから Sonnet 4.6 の 1.29 まで、57% の削減が観測されました。Opus ファミリーは非単調なパターンを示します。Opus 4.6 と 4.8 はいずれも 1.21 に達する一方、Opus 4.5 と 4.7 は 1.7〜1.8 前後とやや高めです。これは、Opus ファミリーの中では、静的に見つかる diagnostics の観点で必ずしもすべてのバージョンが厳密な改善を表すわけではない、ということを示唆しているのかもしれません。全体として、両ファミリーとも本研究の最新版ではチェック済みファイルあたり約 1.2 エラーへ収束します。これは、そのままでコンパイル可能なコードを生成するモデルへ向けた意味のある前進を示している可能性があります。 3. 呼び出しあたりのチェック対象ファイル数: 広いスコープか、狭いスコープか エラー率を超えて、モデルが diagnostics ツールを どう 使うかについて興味深いことに気づきました。新しいモデルは、1 回の呼び出しでより多くのファイルをチェックしています。 図4: モデルが diagnostics ツールを呼び出すたびにチェックする平均ファイル数。Opus は 1.78（Opus 4.5）から 1.87（Opus 4.6）、2.04（Opus 4.7）、その後 1.91（Opus 4.8）へ上昇。Sonnet は 1.57（Sonnet 4）から 1.72（Sonnet 4.5）、1.86（Sonnet 4.6）へ上昇し、新しいモデルほど 1 回の呼び出しでより多くのファイルをチェックしている。 初期の頃、Sonnet 4 は diagnostics を呼び出すたびに平均 1.57 ファイルをチェックしていました。実質的には一度に 1 ファイル、たまに 2 ファイル目という程度です。Sonnet 4.5 でこれは 1.72 へ、Sonnet 4.6 は 1.86 へ上がりました。Opus ファミリーも同様の傾向を示します。Opus 4.5 は呼び出しあたり平均 1.78 ファイル、Opus 4.6 は 1.87、Opus 4.7 は 2.04 でピークに達し、Opus 4.8 は 1.91 に落ち着きました。 これが重要なのは、コードチェック戦略の転換を表しているからです。ファイルを編集してそのファイルだけをチェックするのではなく、新しいモデルは 関連する ファイルをまとめてチェックすることが増えています。たとえば、実装とそのテスト、あるいはモジュールとその利用側です。 呼び出しあたり約 1.6 ファイルから約 2.0 ファイルへの移行はささやかに聞こえるかもしれませんが、数十万回の呼び出しにわたって見れば、モデルが以前の世代よりも高い頻度でクロスファイルの退行（import の破損、インターフェースの不一致、下流の型エラーなど）を捕捉していることを意味します。 4. 報告されたエラーカテゴリのトップ5 診断されたエラーが何なのかを理解するため、私たちはエラーの種類を分類し、各モデルごとに分布を可視化しました。 図5: 各モデルの diagnostics エラーカテゴリの分布。Opus 4.5・4.6・4.7・4.8、Sonnet 4・4.5・4.6 の 7 つのドーナツチャート。カテゴリは解決できない import、未定義シンボル、構文エラー、implicit any、プロパティアクセス、解決できない参照、Kotlin 標準ライブラリの解決、その他。解決できない import はすべてのモデルで最大のスライスで、Opus 4.7 では 57.6% に達する。一方 Sonnet 4.5 や Opus 4.5 のようなモデルはカテゴリ間により均等に広がっている。 すべてのモデルにわたって、「解決できない import」が単独で最大のエラーカテゴリであり、多くの場合すべての diagnostics の約 3 分の 1 を占め、Opus 4.7 では半分超に達します。「未定義シンボル」と、型システムのエラーの長い裾（構文エラー、解決できない参照、implicit any など）が残りを構成します。注目すべきは、エラー分布がモデル間で異なる点です。Opus 4.7 は import 解決の失敗に大きく偏っており、他のエラータイプは比較的少ないのに対し、Sonnet 4.5 や Opus 4.5 のようなモデルはカテゴリ間により均等に広がった分布を示します。これは、モデルによって失敗の仕方が異なることを示唆しているのかもしれません。あるモデルは主に依存関係の解決に苦戦し、別のモデルは型システムとシンボルの全体にわたって間違いをより広く分散させます。 5. ソースファイル対テストファイル: どちらがより多くのエラーを生むのか？ テストコードは、モデルが正しく書くのが一貫して難しい対象です。テストにはモッキングフレームワーク、アサーションライブラリ、複雑なセットアップのパターンが関わり、テストツールとテスト対象コードの両方を理解している必要があります。 図6: モデル別の、ソースファイルとテストファイルにおけるファイルあたり平均エラー数。ソースエラーは青、テストエラーは赤。Opus 4.5 は 1.35 対 5.98、Opus 4.6 は 0.96 対 3.64、Opus 4.7 は 1.40 対 4.62、Opus 4.8 は 0.81 対 6.00、Sonnet 4 は 2.20 対 7.31、Sonnet 4.5 は 2.26 対 9.13（最も差が大きい）、Sonnet 4.6 は 1.08 対 3.56 で、テストファイルは常にソースファイルよりはるかに高い。 Opus ファミリーは概してソースファイルのエラーを 1.4 未満に保ちますが、テストファイルのエラーは 3.64（Opus 4.6）から 6.00（Opus 4.8）まで幅があります。Sonnet 4.5 は最も差が大きく、ソースファイルあたり 2.26 エラーに対しテストファイルあたり 9.13 エラーです。Sonnet 4 はソースエラー 2.20、テストエラー 7.31 を生み、Sonnet 4.6 は Sonnet の中で最も強く、それぞれ 1.08 と 3.56 です。モデルのサイズや世代にかかわらず、テストファイルが依然としてエラーの主な発生源であるように見えます。 6. 言語の地形図: Java は難しく、Python は易しい コードを生成するとき、他より多くのエラーを生む言語があります。Opus 4.6（最大のトラフィック）のファイルレベルのエラー率を見ると、そのばらつきは非常に大きいです。ただし、これらの数値はモデルの能力を超えた 2 つの要因によっても形作られています。顧客がインストールしている静的解析拡張機能の精度（より厳格なリンターほど多くの問題を表面化させる）と、Kiro IDE のユーザー層が各言語をどう使うかのばらつきです。 図7: Opus 4.6 における言語別のファイルエラー率（低いほど良い）。低い順に、JavaScript 1.6%、Python 4.0%、Go 8.0%、Kotlin 8.5%、TypeScript 8.6%、TSX（React）11.2%、C++ 12.2%、Rust 15.1%、Java 26.7%（最も長いバー）。 Java は 26.7% のファイルエラー率でトップに位置します。これは、生成された Java ファイルの 4 つに 1 つ超が少なくとも 1 件の diagnostics エラーを含むことを意味します。冗長な import、複雑なジェネリクス、検査例外、厳格な型解決の組み合わせが、本研究で分析した AI モデルにとって Java を最も難しい言語にしており、その差は大きく開いています。次に来るのは Rust の 15.1%、続いて C++ の 12.2% です。 中間層は TSX/React、TypeScript、Kotlin、Go で構成され、エラー率は 8〜11% の範囲です。これらはモデルをつまずかせるだけの構造を持った静的型付け言語ですが、Java ほど厳格ではありません。 最下位に位置するのは Python（4.0%）と JavaScript（1.6%）です。Python の動的型付け、import のボイラープレートの少なさ、寛容な構文は、一貫してきれいな結果を生みます。JavaScript の底値の 1.6% は少しばかり誤解を招きます。これはモデルがより良いコードを 書いている ことではなく、素の JS で利用できる静的解析が最小限であることを反映しています。TypeScript の型システムを上に乗せると、この率は 8.6% へ跳ね上がります。JavaScript に当てはまる同じ但し書きが、より微妙な形で Python にも当てはまります。動的型付け言語であり、静的解析が通常は軽いため、一部の Python のエラーはランタイムになるまで diagnostics として表面化しません。したがって、低い静的エラー率は編集時に捕捉できるものを反映しているのであって、そのコードが Java よりも必ずしも正しいことを意味しません。Java ではコンパイラがほぼすべてを前もって捕捉するのです。 チームが Java コードベースで AI コーディングエージェントを重点的に使っているなら、Python や TypeScript のコードベースよりも diagnostics のクリーンアップに多くの時間を費やすことを見込んでおいてください。 まとめ 6 か月と 50 万件近い diagnostics 呼び出しは、AI コーディングエージェントが正しいコードを書くうえで測定可能なかたちで改善していることを示していますが、その実態は単一の数字よりも込み入っています。 エラー率は低下している。 両モデルファミリーとも、より強力なバージョンでファイルあたり約 1.2 エラーへ収束します。 モデルは会話の 3〜22% で diagnostics ツールを積極的に呼び出す。 新しいモデルは一度により多くのファイルをチェックする。 より最近のモデルでは、関連ファイル（たとえば実装とそのテスト）をまとめてチェックすることが増えています。 解決できない import が支配的。 モデルにかかわらず、全エラーの約 30〜58% を占めます。 テストコードは正しく書くのが 3〜4 倍難しいように見える。 モッキングフレームワークやアサーションライブラリは、実装ファイルよりも一貫してはるかに多くのエラーを生みます。 言語は重要。 Java のエラー率（26.7%）は Python（4.0%）の 6.7 倍です。JavaScript の低い 1.6% は、より良い生成ではなく弱い静的解析を反映しています。 diagnostics は、Kiro のエージェントがコードを書いて洗練させる過程で自動的に実行されます。その仕組みを見て、さらに深く知るには、 diagnostics のドキュメント と モデルの概要 を読み、 Kiro をダウンロード してご自身のコードベースで試してみてください。

本記事は2026年4月17日に公開された「 Introducing granular cost attribution for Amazon Bedrock 」を翻訳したものです。 AI による推論がクラウド支出の大きな割合を占めるようになる中、誰が、そして何がコストを押し上げているのかを把握することは、チャージバック、コスト最適化、財務計画にとって不可欠です。本日、Amazon Bedrock 推論のきめ細かなコスト配分機能を発表します。 Amazon Bedrock は、推論コストを API コールを実行した IAM プリンシパルに自動的に紐付けるようになりました。 IAM プリンシパル とは、IAM ユーザー、アプリケーションが引き受けたロール、または Okta や Entra ID などのプロバイダーからのフェデレーテッド ID のことです。この紐付けは AWS Billing に反映され、モデルを問わず機能します。管理すべきリソースはなく、既存のワークフローを変更する必要もありません。オプションのコスト配分タグを使用すれば、AWS Cost Explorer や AWS Cost and Usage Reports (CUR 2.0) で、チーム別、プロジェクト別、またはカスタムディメンション別にコストを集計できます。 この記事では、Amazon Bedrock のきめ細かなコスト配分の仕組みを紹介し、コスト追跡のシナリオ例を解説します。 きめ細かなコスト配分の仕組み CUR 2.0 では、データエクスポート設定で IAM プリンシパルデータを有効にすると、どの AWS Identity and Access Management (IAM) プリンシパルが Amazon Bedrock を呼び出しているか、またそれぞれがいくら使っているかを確認できます。以下に例を示します。 line_item_iam_principal line_item_usage_type line_item_unblended_cost arn:aws:iam::123456789012:user/alice USE1-Claude4.6Sonnet-input-tokens $0.069 arn:aws:iam::123456789012:user/alice USE1-Claude4.6Sonnet-output-tokens $0.214 arn:aws:iam::123456789012:user/bob USE1-Claude4.6Opus-input-tokens $0.198 arn:aws:iam::123456789012:user/bob USE1-Claude4.6Opus-output-tokens $0.990 ここでは、Alice が Claude 4.6 Sonnet を、Bob が Claude 4.6 Opus を使用していること、そしてそれぞれが入力トークンと出力トークンにいくら費やしているかを確認できます。以下の表は、各アイデンティティタイプに対して line_item_iam_principal 列に含まれる内容を示しています。 Bedrock の呼び出し方法 line_item_iam_principal AWS IAM ユーザー …user/alice Bedrock キー (IAM ユーザーにマッピング) …user/BedrockAPIKey-234s AWS IAM ロール (例: AWS Lambda 関数) …assumed-role/AppRole/session フェデレーテッドユーザー (例: ID プロバイダーからのユーザー) …assumed-role/Role/user@acme.org タグを使った集計と Cost Explorer での活用 チーム別、プロジェクト別、またはコストセンター別にコストを集計するには、IAM プリンシパルにタグを追加します。タグは次の2つの方法で請求データに反映されます。 プリンシパルタグ は、IAM ユーザーまたはロールに直接アタッチされます。一度設定すれば、そのプリンシパルからのすべてのリクエストに適用されます。 セッションタグ は、ユーザーやアプリケーションが IAM ロールを引き受けて一時的な認証情報を取得する際に動的に渡されるか、ID プロバイダーのアサーションに埋め込まれます。詳細については、「 Pass session tags in AWS STS 」を参照してください。 AWS Billing で コスト配分タグ として有効化すると、両方のタグタイプが CUR 2.0 の tags 列に iamPrincipal/ プレフィックス付きで表示されます。以下に例を示します。 Bedrock の呼び出し方法 line_item_iam_principal tags AWS IAM ユーザー …user/alice {“iamPrincipal/team”:”ds”} AWS IAM ロール …assumed-role/AppRole/session {“iamPrincipal/project”:”chatbot”} フェデレーテッドユーザー …assumed-role/Role/user@acme.org {“iamPrincipal/team”:”eng”} コスト配分戦略の構築に関する詳細なガイダンスについては、「 Best Practices for Tagging AWS Resources 」を参照してください。 シナリオ別クイックスタート セットアップ方法は、ユーザーやアプリケーションが Amazon Bedrock をどのように呼び出すかによって異なります。以下の表は、各アクセスパターンにおいて CUR 2.0 で利用可能な紐付け情報と、タグベースの集計のために設定すべき内容をまとめたものです。 セットアップ CUR 2.0 での紐付け情報 タグによる集計および Cost Explorer のための設定方法 シナリオ IAM ユーザーまたは API キーを使用する開発者 各ユーザーの ARN が CUR 2.0 に表示される IAM ユーザーにタグをアタッチする 1 IAM ロールを使用するアプリケーション 各ロールの ARN が CUR 2.0 に表示される IAM ロールにタグをアタッチする 2 IdP を通じて認証するユーザー ARN 内のセッション名でユーザーを識別 IdP からセッション名とタグを渡す 3 Bedrock にプロキシする LLM ゲートウェイ ゲートウェイのロールのみ表示される (全ユーザーが単一の ID) ユーザーごとに AssumeRole でセッション名とタグを追加する 4 注: シナリオ 1～3 では、CUR 2.0 の line_item_iam_principal 列により、呼び出し元ごとのアイデンティティの紐付け情報が得られます。タグが必要になるのは、カスタムディメンション (チーム、コストセンター、テナント) で集計したい場合や、Cost Explorer で視覚的な分析やアラートを利用したい場合のみです。シナリオ 4 では、ユーザーレベルの紐付け情報を得るために、ユーザーごとのセッション管理が必要です。これがない場合、すべてのトラフィックがゲートウェイの単一ロールに紐付けられます。 タグを追加した後、AWS Billing コンソールまたは UpdateCostAllocationTagsStatus API で コスト配分タグを有効化 してください。タグは 24～48 時間以内に Cost Explorer と CUR 2.0 に反映されます。 以降のセクションでは、いくつかの一般的なシナリオを解説します。 シナリオ 1: IAM ユーザーと API キーによるユーザーごとの追跡 ユースケース: 個々の開発者が IAM ユーザーの認証情報や Amazon Bedrock API キーを使用する、小規模チーム、開発環境、または迅速なプロトタイピングを行う場面。 仕組み: 各チームメンバーは長期認証情報を持つ専用の IAM ユーザーを持っています。例えば user-1 や user-2 が Amazon Bedrock を呼び出すと、Amazon Bedrock は認証時にその IAM ユーザーの Amazon Resource Name (ARN) を自動的に記録します。CUR 2.0 では、誰がいくら使っているかを確認できます。 チーム別、コストセンター別、またはその他のディメンション別にコストをまとめたい場合 — 例えばデータサイエンスチームのメンバー全体の合計支出を確認したい場合 — IAM ユーザーにタグをアタッチします。タグは IAM コンソール、AWS Command Line Interface (AWS CLI)、または AWS API で追加できます。以下の例では AWS CLI を使用しています。 # データサイエンスチームのユーザーにタグを付ける aws iam tag-user \ --user-name user-1 \ --tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345" aws iam tag-user \ --user-name user-2 \ --tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345" CUR 2.0 に表示される内容: Cost and Usage Report には個々のユーザー ID とそのタグの両方が記録されるため、以下の例に示すように、2 つのディメンションで分析を行うことができます。 line_item_iam_principal line_item_usage_type line_item_unblended_cost tags arn:aws:iam::123456789012:user/user-1 USE1-Claude4.6Sonnet-input-tokens $0.0693 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-1 USE1-Claude4.6Sonnet-output-tokens $0.2145 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-2 USE1-Claude4.6Opus-input-tokens $0.1980 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} arn:aws:iam::123456789012:user/user-2 USE1-Claude4.6Opus-output-tokens $0.9900 {“iamPrincipal/team”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} line_item_usage_type 列にはリージョン、モデル、トークンの方向 (入力と出力) がエンコードされているため、「user-1 が Sonnet の入力トークンと出力トークンにそれぞれいくら使ったか？」や「誰が Opus を使っていて、誰が Sonnet を使っているか？」といった質問に答えることができます。 このデータから、いくつかの方法でコストを分析できます: ユーザー別: line_item_iam_principal でフィルタリングすると、各ユーザーの正確な支出額を確認できます。ヘビーユーザーの特定や、個人の実験コストの追跡に役立ちます。 モデル別: line_item_usage_type でフィルタリングすると、モデルごとの支出を比較できます。例えば、誰が Opus のコストを押し上げていて、誰が Sonnet を使っているかがわかります。 チーム別: iamPrincipal/team でグループ化すると、データサイエンスチームのメンバー全体の合計支出を確認できます。部門別のチャージバックに役立ちます。 このアプローチは、ユーザー数が管理可能な範囲にあり、最もシンプルなセットアップで済ませたい場合に最適です。各ユーザーの認証情報によって請求データ上で直接本人を識別することが可能になり、タグを使えばコストをより上位のディメンションにまとめることもできます。 Amazon Bedrock API キーの使用: Amazon Bedrock は、他の AI プロバイダーと同様のシンプルな認証体験を提供する API キーもサポートしています。 API キー は IAM プリンシパルに関連付けられています。API キーで行われたリクエストは対応する IAM アイデンティティに紐付けられるため、同様に line_item_iam_principal およびタグベースの紐付けがそのまま適用されます。つまり、開発者に API キーを配布したり、アプリケーションに埋め込んだりしている組織でも、コストを元の IAM ユーザーやロールまで追跡できます。 シナリオ 2: IAM ロールによるアプリケーションごとの追跡 ユースケース: (人間ではなく) アプリケーションが Amazon Bedrock を呼び出す本番用ワークロードで、プロジェクトやサービスごとにコストを追跡したい場合。 仕組み: 例えば、ドキュメント処理サービス (app-1) とチャットサービス (app-2) という 2 つのバックエンドアプリケーションがあるとします。各アプリケーションはコンピューティングインフラストラクチャ (Amazon EC2、AWS Lambda、Amazon Elastic Container Service (Amazon ECS) など) 上で動作し、専用の IAM ロールを引き受けて Amazon Bedrock を呼び出します。いずれかのアプリケーションが Amazon Bedrock を呼び出すと、引き受けたロールの ARN が自動的に記録されます。この紐付け情報は CUR 2.0 レポートに反映され、アプリケーションごとのコスト可視性が得られます。 line_item_iam_principal でフィルタリングすると、ロール名が含まれているため、アプリケーションごとの合計支出を確認できます。また、 line_item_usage_type でフィルタリングすると、サービス間でのモデル使用状況を比較できます。タグの使用は任意です。アプリケーションがリクエストやバッチジョブごとに一意のセッション名を生成する場合は、さらに細かいレベルでコストを追跡できます。 プロジェクト別、コストセンター別、またはその他のディメンション別にコストをまとめたい場合 — 例えば DocFlow と ChatBackend の合計支出を比較したい場合 — IAM ロールにタグをアタッチします。 # ドキュメント処理ロールにタグを付ける aws iam tag-role \ --role-name Role-1 \ --tags Key=project,Value="DocFlow" Key=cost-center,Value="12345" # チャットサービスロールにタグを付ける aws iam tag-role \ --role-name Role-2 \ --tags Key=project,Value="ChatBackend" Key=cost-center,Value="12345" app-1 が Role-1 を引き受けて Amazon Bedrock を呼び出すと、リクエストは引き受けたロールのセッションに紐付けられます。ロールのタグは自動的に請求データに反映されます。 CUR 2.0 に表示される内容: line_item_iam_principal には、以下の例に示すように、セッション名を含む引き受けたロールの完全な ARN が表示されます。 line_item_iam_principal line_item_usage_type line_item_unblended_cost tags arn:aws:sts::123456789012:assumed-role/Role-1/session-123 USE1-Claude4.6Sonnet-input-tokens $0.0330 {“iamPrincipal/project”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-1/session-123 USE1-Claude4.6Opus-output-tokens $0.1650 {“iamPrincipal/project”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-2/session-456 USE1-NovaLite-input-tokens $0.0810 {“iamPrincipal/project”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} arn:aws:sts::123456789012:assumed-role/Role-2/session-456 USE1-NovaLite-output-tokens $0.0500 {“iamPrincipal/project”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} これにより、複数の方法で分析できます。 ロールでフィルタリング: ARN のロール名部分を使って、アプリケーションごとの合計支出を確認できます。 セッションでフィルタリング: セッション名を使って、リクエストやバッチジョブごとのコストを追跡できます。 プロジェクトで集計: iamPrincipal/project でグループ化して、DocFlow と ChatBackend のコストを比較できます。 コストセンターで集計: iamPrincipal/cost-center でグループ化して、同じチームが所有するアプリケーション全体の合計支出を確認できます。 このアプローチは、各サービスが独自の IAM ロールを持つマイクロサービスアーキテクチャに最適です。これはセキュリティのベストプラクティスであると同時に、コスト配分のメカニズムとしても機能します。 シナリオ 3: フェデレーテッド認証によるユーザーごとの追跡 ユースケース: ユーザーが企業の ID プロバイダー (Auth0、Okta、Azure AD、Amazon Cognito) を通じて認証し、OpenID Connect (OIDC) または Security Assertion Markup Language (SAML) フェデレーション経由で AWS にアクセスするエンタープライズ環境。 仕組み: ユーザーは ID プロバイダー (IdP) を通じて認証し、共有の IAM ロールを引き受けます。ユーザーごとの紐付けは 2 つのメカニズムによって得られます。 セッション名 (引き受けたロールの ARN に埋め込まれたユーザー ID) と セッションタグ (IdP から渡されるチーム、コストセンターなど) です。1 つの IAM ロールがすべてのユーザーに対応するため、ユーザーごとの IAM リソースを管理する必要はありません。 セッション名 (緑色でハイライト) が line_item_iam_principal に表示される内容です: arn:aws:sts::123456789012:assumed-role/BedrockRole/ user-1@acme.org 図 1. フェデレーテッド認証シナリオにおける ID フロー OIDC フェデレーション (Auth0、Cognito、Okta OIDC) の場合: IdP を IAM OIDC プロバイダーとして登録し、 sts:AssumeRoleWithWebIdentity と sts:TagSession を許可する信頼ポリシーを持つロールを作成し、IdP が ID トークンに https://aws.amazon.com/tags クレームを挿入するよう設定します。AWS Security Token Service (AWS STS) はこのクレームからセッションタグを自動的に抽出します。呼び出し元のアプリケーションは、 AssumeRoleWithWebIdentity を呼び出す際に –role-session-name をユーザーのメールアドレス (または別の識別子) に設定します。 SAML フェデレーション (Okta、Azure AD、Ping、ADFS) の場合: IdP で SAML 属性マッピングを設定し、アサーションに RoleSessionName (例: ユーザーのメールアドレス) と PrincipalTag:* 属性 (チーム、コストセンター) を渡すようにします。セッション名とタグはどちらも署名済みアサーションに埋め込まれるため、呼び出し元のアプリケーションが個別に設定する必要はありません。IAM ロールには sts:AssumeRoleWithSAML と sts:TagSession の権限が必要です。 どちらの場合も、タグはアサーションまたはトークン内に暗号的に署名されているため、ユーザーが自身のコスト配分情報を改ざんすることはできません。 CUR 2.0 に表示される内容:&nbsp; line_item_iam_principal line_item_usage_type line_item_unblended_cost tags …assumed-role/Role-1/user-1@acme.org USE1-Claude4.6Opus-input-tokens $0.283 {“iamPrincipal/team”:”data-science”,”iamPrincipal/cost-center”:”12345″} …assumed-role/Role-1/user-1@acme.org USE1-Claude4.6Opus-output-tokens $0.990 {“iamPrincipal/team”:”data-science”,”iamPrincipal/cost-center”:”12345″} …assumed-role/Role-1/user-2@acme.org USE1-Claude4.6Sonnet-input-tokens $0.165 {“iamPrincipal/team”:”engineering”,”iamPrincipal/cost-center”:”67890″} …assumed-role/Role-1/user-2@acme.org USE1-Claude4.6Sonnet-output-tokens $0.264 {“iamPrincipal/team”:”engineering”,”iamPrincipal/cost-center”:”67890″} この例では、user-1 が Opus を、user-2 が Sonnet を使用しています。両者は同じ IAM ロールを共有していますが、それぞれ個別に識別できます。 iamPrincipal/team でグループ化すれば部門別のチャージバックが可能になり、セッション名を抽出すればユーザーごとの分析ができます。 シナリオ 4: LLM ゲートウェイを介したユーザーごとの追跡 ユースケース: ユーザーと Amazon Bedrock の間に大規模言語モデル (LLM) ゲートウェイまたはプロキシ (LiteLLM、カスタム API ゲートウェイ、Kong、Envoy、または自社開発サービス) を配置している組織。 問題点: ゲートウェイは独自のレイヤーでユーザーを認証した後、ゲートウェイのコンピューティングにアタッチされた単一の IAM ロールを使用して Amazon Bedrock を呼び出します。追加の対応を行わない場合、すべての Amazon Bedrock コールが CUR 2.0 上で単一のアイデンティティとして表示され、ユーザーごとやテナントごとの可視性は得られません。 解決策: ユーザーごとのセッション管理 ゲートウェイは各ユーザーに対して Amazon Bedrock スコープのロールに対し AssumeRole を呼び出し、ユーザーの ID を --role-session-name として、ユーザーの属性 (チーム、テナント、コストセンター) を --tags として渡します。生成されたユーザーごとの認証情報はキャッシュされ (最大 1 時間有効)、同じユーザーからの後続リクエストに再利用されます。これには 2 つの IAM ロールが必要です。1 つ目はゲートウェイ実行ロールで、 sts:AssumeRole と sts:TagSession のアクセス許可を持ちます。2 つ目は Amazon Bedrock 呼び出しロールで、ゲートウェイロールから信頼され、Amazon Bedrock API にスコープが限定されています。 図 2. LLM ゲートウェイシナリオにおける ID フロー 実装上の主な考慮事項: セッションのキャッシュ : AssumeRole によるレイテンシーの追加はわずかです。TTL (Time to Live) を 1 時間に設定すれば、STS の呼び出しはリクエストごとではなく、ユーザーごとに 1 時間に 1 回で済みます。 キャッシュサイズは 総ユーザー数ではなく、 同時接続ユーザー数に比例します (同時接続ユーザーが 500 であれば、キャッシュされるセッションも約 500)。 STS のレート制限 はデフォルトでアカウントあたり毎秒 500 AssumeRole コールです。高スループットのゲートウェイの場合は引き上げをリクエストしてください。 セッションタグは一度設定するとそのセッション内では変更できません 。タグの変更は次回のセッション作成時に反映されます。 CUR 2.0 に表示される内容: line_item_iam_principal line_item_usage_type line_item_unblended_cost tags …assumed-role/BedrockRole/gw-user-1 USE1-Claude4.6Sonnet-input-tokens $0.081 {“iamPrincipal/team”:”data-science”} …assumed-role/BedrockRole/gw-user-1 USE1-Claude4.6Sonnet-output-tokens $0.163 {“iamPrincipal/team”:”data-science”} …assumed-role/BedrockRole/gw-tenant-acme USE1-Claude4.6Opus-input-tokens $0.526 {“iamPrincipal/tenant”:”acme-corp”} …assumed-role/BedrockRole/gw-tenant-acme USE1-Claude4.6Opus-output-tokens $0.925 {“iamPrincipal/tenant”:”acme-corp”} ゲートウェイでユーザーごとのセッション管理を行わない場合、ゲートウェイのトラフィックはすべてゲートウェイの単一ロールに紐付けられます。セッション管理を追加することが、ユーザーごとおよびテナントごとの紐付けを実現するための鍵となります。 シナリオの選び方 IAM ユーザーまたは Amazon Bedrock API キーを使用する開発者 → シナリオ 1 AWS コンピューティング上で IAM ロールを使用するアプリケーション/サービス → シナリオ 2 IdP (Auth0、Okta、Azure AD) を通じて認証するユーザー → シナリオ 3 Amazon Bedrock の前段に配置された LLM ゲートウェイまたはプロキシ → シナリオ 4 マルチテナント SaaS を構築する場合 → シナリオ 4 (テナント ID をセッション名 + セッションタグとして使用) Claude Code ワークロード → シナリオ 3 AWS Billing でのタグの有効化 AWS Billing コンソール を開きます コスト配分タグ に移動します タグが少なくとも 1 つの Amazon Bedrock リクエストに使用された後 (最大 24 時間かかります)、AWS マネジメントコンソールの IAM カテゴリの下にそのタグが表示されます 有効化したいタグを選択し、「 有効化 (Activate) 」を選択します CUR 2.0 の場合は、データエクスポート設定の作成時または更新時に IAM プリンシパルを有効にする必要もあります。 Cost Explorer でのコスト表示 有効化すると、IAM タグが Cost Explorer の「 タグ (Tags) 」ドロップダウンの IAM カテゴリの下に表示されます。以下のことが可能です。 team = data-science でフィルタリングして、そのチームの Amazon Bedrock の合計支出を確認する tenant でグループ化して、顧客間のコストを比較する ディメンションを組み合わせて、「今月エンジニアリングチームが Claude Sonnet にいくら使ったか？」といった質問に答える 利用を開始するには Amazon Bedrock の新しいコスト配分機能は、追加費用なしで商用リージョンで利用可能です。開始するには以下の手順に従ってください。 アクセスパターンを特定する。 開発者が IAM ユーザーや API キーで Amazon Bedrock を直接呼び出しているか (シナリオ 1)？ アプリケーションが IAM ロールを使用しているか (シナリオ 2)？ ユーザーが ID プロバイダーを通じて認証しているか (シナリオ 3)？ それともトラフィックが LLM ゲートウェイを経由しているか (シナリオ 4)？ CUR 2.0 で IAM プリンシパルデータを有効にする。 データエクスポート設定を更新して、IAM プリンシパルデータを含めるようにします。 集計が必要な場合や Cost Explorer でフィルタリングしたい場合はタグを追加する。 IAM ユーザーまたはロールにタグをアタッチするか、IdP からセッション名とタグを渡すよう設定するか、ゲートウェイにユーザーごとのセッション管理を追加します。その後、AWS Billing コンソールでコスト配分タグを有効化します。 分析する。 有効化から 24～48 時間以内に、タグが Cost Explorer と CUR 2.0 に表示されます。チームでフィルタリング、プロジェクトでグループ化、またはディメンションを組み合わせて、「今月エンジニアリングチームが Claude Sonnet にいくら使ったか？」といった質問に答えることができます。 まとめ 推論に誰がいくら使っているかを把握することは、チャージバック、予測、最適化の第一歩です。Amazon Bedrock のきめ細かなコスト配分を使えば、既に導入済みの IAM アイデンティティとタグのメカニズムを活用して、推論リクエストを特定のユーザー、アプリケーション、またはテナントまで追跡できます。チームが IAM 認証情報で Amazon Bedrock を直接呼び出す場合でも、フェデレーテッド認証を経由する場合でも、LLM ゲートウェイを介する場合でも、AWS CUR 2.0 と AWS Cost Explorer が必要な可視性を追加費用なしで提供します。 著者について Ba’Carri Johnson は Amazon Bedrock チームのシニアテクニカルプロダクトマネージャーで、AWS AI のコスト管理とガバナンスを専門としています。AI インフラストラクチャ、コンピューターサイエンス、戦略のバックグラウンドを持ち、プロダクトイノベーションと組織が責任を持って AI をスケールさせるための支援に取り組んでいます。余暇には旅行やアウトドアを楽しんでいます。 Vadim Omeltchenko は Amazon Bedrock の Go-to-Market 担当シニアソリューションアーキテクトです。AWS のお客様がクラウドでイノベーションを実現するための支援を推進しています。 Ajit Mahareddy はプロダクトおよび Go-To-Market (GTM) の経験豊富なリーダーで、プロダクトマネジメント、エンジニアリング、Go-to-Market の分野で 20 年以上の経験を持っています。現在の役職に就く前は、Uber、Turing、eHealth などの大手テクノロジー企業で AI/ML プロダクトのプロダクトマネジメントを率いていました。生成 AI 技術の発展と、生成 AI による実社会へのインパクトの創出に取り組んでいます。 Sofian Hamiti は 12 年以上にわたり AI ソリューションの構築に携わってきたテクノロジーリーダーで、顧客の成果を最大化するハイパフォーマンスチームを率いてきました。多様な人材がグローバルなインパクトを生み出し、キャリア目標を達成できるよう支援することに取り組んでいます。 <!-- '"` --> 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

本記事は2026年8月12日に公開された「 Part 2: Amazon Bedrock cost attribution with Amazon Athena and CUDOS 」を翻訳したものです。 Part 1 では、Amazon Bedrock のきめ細かなコスト配分について紹介しました。この機能は、すべての推論リクエストを API コールを実行した IAM プリンシパルまで自動的に追跡します。新しい line_item_iam_principal 列によって、ユーザーごとおよびアプリケーションごとの可視性が得られることを示しました。オプションのコスト配分タグを使用すれば、AWS Cost Explorer を使ってチーム別、プロジェクト別、またはテナント別に支出を集計することもできます。このアプローチにより、Claude Code や Codex などのサードパーティツールであれ、独自に構築したものであれ、Bedrock を活用するあらゆるサービスやアプリケーションの利用状況を、必要な粒度で追跡できるようになります。この記事では、Amazon Athena クエリと CUDOS ダッシュボードを使用して、Amazon Bedrock のコスト配分を可視化・分析する方法を紹介します。 まず、この記事では Cost and Usage Report (CUR) 2.0 を IAM プリンシパルデータを含む Data Exports で設定する方法を説明します。次に、Amazon Athena を使用して CUR データをクエリし分析する方法を示します。その後、Bedrock のきめ細かなコストおよび使用状況データを含む、CUDOS ダッシュボードの新機能を紹介します。Athena は集計の柔軟性、さまざまなビジネスインテリジェンス (BI) ツールとの統合、チャージバックプロセスへの対応に優れている一方、CUDOS は自組織の構造に応じたビジュアルがあらかじめ用意されています。 IAM プリンシパルごとおよび使用タイプごとの Amazon Bedrock コストを示すクエリ出力例 Cost and Usage Reports (CUR 2.0) の設定 Amazon Bedrock のコストを分析する前に、CUR 2.0 のデータエクスポートを設定し、Amazon Athena に接続する必要があります。 前提条件 以下が必要です: 請求コンソールへのアクセス権を持つ AWS アカウント CUR 2.0、S3、Athena に対する IAM アクセス許可 CUR データを保存するための S3 バケット SQL と AWS マネジメントコンソールの基本的な知識 (オプション) 自動セットアップのための Claude Code または Kiro-CLI 必要な IAM アクセス許可 があることを確認してください。 Amazon Bedrock のコスト配分を利用するには、CUR 2.0 のデータエクスポートで IAM プリンシパルデータを有効にして、 line_item_iam_principal 列と関連する IAM プリンシパルタグのデータが記録されるようにする必要があります。 IAM プリンシパルデータを含む CUR 2.0 データエクスポートの作成 「 Creating a standard export 」の手順に従って CUR 2.0 のデータエクスポートを設定してください。データエクスポートを設定する際、最終的な設定に以下のオプションが含まれていることを確認してください。 発信者 ID (IAM プリンシパル) の割り当てデータを有効にした CUR 2.0 データエクスポートの作成 「 その他のエクスポートコンテンツ (Additional export content) 」で、以下のチェックボックスを選択します: 「 発信者 ID (IAM プリンシパル) 割り当てデータを含める (Include caller identity (IAM principal) allocation data) 」 — これが line_item_iam_principal 列にデータを記録し、コストデータに IAM プリンシパルタグ ( iamPrincipal/ プレフィックス付き) を表示させるための重要な設定です。 「 データテーブルの設定 (Data table configurations) 」において: 「 時間粒度 (Time granularity) 」: 最大限の詳細を得るために「時間単位 (Hourly)」を選択します。 「 データエクスポート配信オプション (Data export delivery options) 」において: 「 ファイルのバージョニング (File versioning) 」: 重複データの保存を避けるために「既存のデータエクスポートファイルを上書き (Overwrite existing data export file)」を選択します。 重要: IAM プリンシパルデータを有効にすると、CUR ファイルのサイズが増加します。これは、以前は 1 行だった使用量が、その使用量に寄与した各 IAM プリンシパルごとに 1 行ずつ、複数行に展開されるためです。多数の異なるプリンシパルを持つ大量のワークロードの場合は、Amazon S3 のストレージを適切に計画し、古い CUR ファイルに対して Amazon S3 ライフサイクルポリシー の使用を検討してください。 AWS が最初の CUR 2.0 レポートを S3 バケットに配信するまで、最大 24 時間かかる場合があります。 CUR 2.0 の Amazon Athena への接続 Amazon Athena を使用すると、インフラストラクチャを管理することなく、標準 SQL で CUR データをクエリできます。このセットアップを効率化するために、Claude Code、Kiro-CLI、Codex などの AI アシスタントで使用できる agent.md スキルリポジトリが用意されています (オプションで利用可能)。これにより、Athena 環境を CUR データに接続する一連のプロセスを自動化できます。 ※ 訳注: エージェントを実行するには、リポジトリの README に記載された最小権限の IAM ポリシーが必要です。 リポジトリをクローンします ( git clone https://github.com/aws-samples/sample-cur-iam-principal-bedrock-tracking )。 このディレクトリで Claude Code ( claude ) または Kiro CLI ( kiro ) を起動します。 以下のようにプロンプトを入力します: 「agent.md を読み、そのワークフローに従って Cost and Usage Report のトラッキングを設定し、当月の Amazon Bedrock のプリンシパル別クエリを実行してください。」 手動のセットアップ手順 に従うこともできます。 CUDOS ダッシュボードも合わせてデプロイする予定がある場合は、 AWS CloudFormation からデプロイ できます。このプロセスの一部として、Athena クエリデータベースもデプロイされます。 デプロイが完了したら、以下のサンプルテストクエリを Athena クエリエディタ で実行できます。 SELECT line_item_iam_principal, line_item_usage_type, line_item_unblended_cost --# Note: replace your_cur_table_name, like `cid_data_export.cur2` FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND line_item_iam_principal IS NOT NULL LIMIT 10; このクエリが IAM プリンシパルの ARN と Bedrock の使用タイプを含む行を返せば、セットアップは完了しており、より詳細な分析を行う準備が整っていることになります。 Bedrock コスト追跡のための Athena クエリパターン CUR 2.0 データが Athena で利用可能になったので、SQL を使用してきめ細かなコスト配分に関する質問に答えることができます。このセクションでは、最も一般的な分析シナリオをカバーする 3 つのクエリパターンを、シンプルなものから高度なものまで段階的に紹介します。 注: 以下のクエリでは、 your_cur_table_name を実際の CUR Athena テーブル名 (例: cid_data_export.cur2 ) に置き換えてください。 クエリ 1: IAM プリンシパルおよび使用タイプ別の Bedrock コスト このクエリは、発信者 ID とモデル使用量別に Amazon Bedrock の支出を完全に分解します。これは「誰がどのモデルを呼び出していて、いくら使っているか?」という質問に答えるものです。 SELECT line_item_iam_principal, line_item_usage_type, SUM(line_item_usage_amount) AS total_tokens, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL -- AND line_item_usage_type LIKE '%Sonnet%input%' GROUP BY line_item_iam_principal, line_item_usage_type ORDER BY total_cost DESC; 出力例: line_item_iam_principal line_item_usage_type total_tokens total_cost arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USW2-anthropic.claude-opus-4-8-mantle-cache-write-tokens-standard 1629.5 $11.2029 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USW2-Claude4.6Sonnet-output-tokens 68.579 $1.131 arn:aws:sts::123456789012:assumed-role/ClaudeCode/chat USW2-Claude4.6Sonnet-cache-write-input-token-count 831.74 $3.4309 arn:aws:iam::123456789012:user/alice USW2-Claude4.6Sonnet-input-tokens 17.33 $0.0572 分析にあたってのヒント: line_item_usage_type LIKE '%Sonnet%output%' や %nova% のような LIKE パターンを使用して、特定のモデルでフィルタリングできます。 line_item_iam_principal 列には完全な ARN が含まれています。引き受けたロールの場合、最後の / の後のセッション名で特定のユーザーやセッションを識別できます。 クエリ 2: 既知の IAM プリンシパルタグ別のコスト内訳 IAM プリンシパルに team 、 project 、 costcenter などのディメンションでタグを付け (さらにそれらをコスト配分タグとして有効化した場合)、CUR 2.0 データの tags 列に iamPrincipal/ プレフィックスに続くタグキーとして表示されます。このクエリを使えば、それらのタグでコストをグループ化し、 「今月エンジニアリングチームが Bedrock にいくら使ったか？」 や 「チャットボットプロジェクトの Bedrock の合計コストはいくらか？」 といった質問に答えることができます。 プロジェクト別の場合: SELECT tags['iamPrincipal/project'] AS project, line_item_usage_type, SUM(line_item_usage_amount) AS total_tokens, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL GROUP BY tags['iamPrincipal/project'], line_item_usage_type ORDER BY total_cost DESC; 出力例: project line_item_usage_type total_tokens total_cost data-science USW2-Claude4.5Sonnet-cache-write-input-token-count 433.893 1.789808625 data-science USW2-Claude4.6Sonnet-cache-read-input-token-count 5372.659 1.77297747 engineering USW2-Claude4.5Sonnet-input-tokens 29.481 0.0972873 engineering USW2-Claude4.5Sonnet-output-tokens 31.102 0.513183 注: このクエリは、IAM プリンシパルに該当するキーでタグが付けられており、かつそれらのタグがコスト配分タグとして有効化されている場合にのみ結果を返します。 クエリ 3: UNNEST を使用した未知のタグスキーマの動的検出 大規模な組織では、すべての IAM プリンシパルにどのタグが適用されているか事前にわからない場合があります。チームによって異なるタグキーを使用していたり、時間の経過とともに新しいタグが追加されたりすることがあります。以下の例では、Athena の UNNEST 関数を使用して動的にタグを探索する方法を示します。 このクエリは、Bedrock ワークロード全体で使用されているすべての IAM プリンシパルタグを検出し、各タグのキーと値のペアごとのコスト配分を表示します: WITH iam_principal_costs AS ( SELECT t.key AS tag_name, t.value AS tag_value, line_item_usage_type, line_item_unblended_cost FROM your_cur_table_name CROSS JOIN UNNEST(tags) AS t(key, value) WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService') AND line_item_iam_principal IS NOT NULL AND line_item_iam_principal != '' AND t.key LIKE 'iamPrincipal/%' ) SELECT tag_name || ': ' || tag_value AS tags, line_item_usage_type, SUM(line_item_unblended_cost) AS total_cost FROM iam_principal_costs GROUP BY tag_name, tag_value, line_item_usage_type ORDER BY total_cost DESC; 実際のユースケース: マルチサービスのコスト比較 複数の AI 搭載サービスを運用するプラットフォームチームを考えてみましょう。例えば、ドキュメント要約パイプライン (DocProcessor) と顧客向けチャットボット (ChatApp) を運用しているとします。チームは各サービスに独自の IAM ロールを割り当てることができます。前のセクションのクエリパターンを使えば、以下のクエリで各サービスの支出の推移を個別に確認できます。 SELECT line_item_iam_principal, line_item_usage_type, SUM(line_item_usage_amount) AS total_usage, SUM(line_item_unblended_cost) AS total_cost FROM your_cur_table_name WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService') AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m') AND line_item_iam_principal IS NOT NULL AND ( line_item_iam_principal LIKE '%DocProcessor%' OR line_item_iam_principal LIKE '%ChatApp%' ) GROUP BY line_item_iam_principal, line_item_usage_type ORDER BY total_cost DESC; 出力例: line_item_iam_principal line_item_usage_type total_usage total_cost arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USE1-Claude4.6Sonnet-output-tokens 4,800,000 $72.00 arn:aws:sts::123456789012:assumed-role/ChatApp/session-1 USE1-Claude4.6Sonnet-input-tokens 2,900,000 $8.70 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USE1-NovaLite-output-tokens 6,100,000 $1.46 arn:aws:sts::123456789012:assumed-role/DocProcessor/batch-7 USE1-NovaLite-input-tokens 3,200,000 $0.19 この出力から、プラットフォームチームは以下のような質問に答えることができます。 今月の Bedrock 支出に最も寄与しているアプリケーションはどれか？ &nbsp;この例では、ChatApp が Claude 4.6 Sonnet を使用して 80 ドル以上を占めている一方、DocProcessor は Nova Lite を使用して 5 ドル未満に収まっています。 ワークロードごとに異なるモデルを使用することでコストを削減できるか？ &nbsp;DocProcessor は既に Nova Lite (単純な要約タスクに適しています) を使用しています。一方、ChatApp の一部のやり取りをより軽量なモデルで処理できれば、チームとしては現在 72 ドルかかっている出力トークンコストを削減できる可能性があります。 Athena クエリのコスト 料金は実行したクエリに対してのみ発生します。各クエリでスキャンされたデータ量に基づいて課金されます。各クエリの実行後に Athena コンソールでこの情報が表示されるほか、「最近のクエリ」タブでも確認できます。 Athena クエリの課金は、スキャンしたデータ 1 TB あたり 5 ドルです (クエリあたり最低 10 MB)。このテーブルは billing_period に対して Hive パーティションプロジェクション を自動的に使用するため、単一の月にスコープを限定したクエリはその月のフォルダ内の Parquet ファイルのみをスキャンします。スキャン量は通常 10 MB を大きく下回るため、クエリあたりのコストは約 0.00005 ドル (10 MB の最低料金) です。 ※ 訳注: 料金はリージョンによって異なる場合があります。最新の料金は&nbsp; Amazon Athena の料金ページ &nbsp;をご確認ください。 コストを低く抑えるために、常に WHERE billing_period = ... フィルタを含め、 SELECT * ではなく必要な列のみを選択するようにしてください。 Cloud Intelligence Dashboards フレームワーク CUDOS ダッシュボード は、オープンソースの Cloud Intelligence Dashboards (CID) フレームワーク の一部であり、提供されている Infrastructure as Code (IaC) テンプレートを使用して AWS アカウントにデプロイできます。このフレームワークにより、AWS 組織全体で財務上の説明責任を果たし、運用効率を高めることができます。CUDOS ダッシュボードは、詳細で実用的なインサイトを提供し、AWS インフラストラクチャ全体のコスト効率に関するデータドリブンな意思決定を支援します。 CUDOS における Amazon Bedrock のコストおよび使用状況インサイト CUDOS バージョン 5.8 では、AI/ML タブに包括的な Amazon Bedrock セクションが導入され、IAM プリンシパルによるコスト配分を完全にサポートしています。このダッシュボードは以下を提供します。 柔軟なグルーピングディメンション: Amazon Bedrock の支出を、IAM プリンシパル、IAM プリンシパルタグ (プロジェクトやチームなど)、モデル/リソースグループ、リージョン、またはダッシュボードのデプロイ時に設定したその他のコスト分類フィールドでグループ化できます。 100 万トークンあたりのコスト追跡: 支出チャートに重ねて表示されるトレンドラインにより、100 万トークンあたりのコストが時間の経過とともにどのように変化しているかを確認できます。これにより、モデル選択の変更やプロンプト最適化の取り組み (例えばキャッシュなど) の効果を測定できます。 以下の図は、CUDOS ダッシュボードの AI/ML タブにある Amazon Bedrock Summary セクションを示しています。IAM プリンシパル別にグループ化され、プリンシパルごとのコスト内訳と 100 万トークンあたりのコストのトレンドが表示されています。 IAM プリンシパル別にグループ化された Amazon Bedrock の支出を表示する CUDOS ダッシュボード インタラクティブなドリルダウンフィルタリング: トップレベルの支出チャートで任意の値 (特定のプロジェクト、プリンシパル、アカウントなど) を選択すると、他のすべてのビジュアルが自動的にその選択内容でフィルタリングされます。これにより、ダッシュボードから離れることなく、概要レベルからモデル別や使用タイプ別の詳細へとドリルダウンできます。 きめ細かなモデルおよび使用状況の内訳: トップレベルのチャートでフィルタリングされた追加のビジュアルにより、モデル別、使用タイプ別の支出、およびモデル別の 100 万トークンあたりのコストが表示されます。これにより、特定のチームやプロジェクトのコストを押し上げているモデルやトークンタイプを特定できます。 グルーピングを「IAM Principal Tag Project」に切り替えて特定のプロジェクト (この例では「chatbot-v2」) を選択すると、他のすべてのビジュアルが自動的にフィルタリングされ、そのプロジェクトの支出のみが表示されます。各ビジュアルでは、その支出がモデル別、使用タイプ別、および単価のトレンドとして分解されます。 IAM プリンシパルタグ「Project」別にグループ化され、chatbot-v2 プロジェクトでフィルタリングされた Amazon Bedrock の支出を表示する CUDOS ダッシュボード これらのビジュアルにより、SQL を書くことなく、「出力トークンコストを最も押し上げているプロジェクトはどれか?」「チャットボットチームはコスト効率の良いモデルを使用しているか?」「Opus から Sonnet に切り替えてから 100 万トークンあたりのコストはどう変化したか?」といった質問にすばやく答えることができます。 CUDOS の利用を開始する CUDOS の利用を開始するにあたって、 インタラクティブなデモ ダッシュボードで Bedrock セクションを試すことができます。自身の組織に CUDOS をセットアップするには、 デプロイガイド に従ってください。 既に CUDOS を使用している場合は、 アップデートガイダンス に従ってバージョン 5.8 にアップグレードしてください。また、 組織分類 (organizational taxonomy) の追加 により、既存の CUDOS ダッシュボードに IAM プリンシパルデータを追加することもできます。 クリーンアップ まず、Athena テーブルと AWS Glue データベースを削除します (これらはメタデータであるため、実行中のコンピューティングリソースはありません)。 警告: Athena テーブルと Glue データベースを削除すると、CUR データをクエリできなくなります。将来的に請求データを分析したい場合は、前述のセクションに従ってこれらのリソースを再作成する必要があります。 aws glue delete-table --region us-east-1 --database-name your_cur_table_name --name curexport aws glue delete-database --region us-east-1 --name your_cur_table_name 次に、コストデータ自体が不要になった場合は、AWS Billing and Cost Management コンソールの Data Exports でエクスポートを無効にし、書き込み先の S3 プレフィックスを空にしてください。これは生の請求履歴であるため、確実に不要であることを確認した上で削除してください。 最後に、蓄積された Athena クエリ結果をクリアします。 aws s3 rm s3://&lt;your-cur-bucket&gt;/athena-results/ --recursive 削除すべきクローラー、AWS Lambda 関数、スケジュールはありません。パーティションプロジェクションを使用しているため、継続的なコストは CUR ファイル自体の S3 ストレージのみであり、通常は月あたり数セントです。 CUDOS のクリーンアップについては、 CUDOS ダッシュボードの削除手順 を参照してください。 まとめと次のステップ この 2 部構成のシリーズでは、Amazon Bedrock の推論コストを理解し管理するための包括的なツールキットを紹介しました: Part 1 では、きめ細かなコスト配分を紹介しました。Amazon Bedrock がすべての推論コールについて、それを実行した IAM プリンシパルを自動的に記録する仕組みと、コスト配分タグを使用してチーム別、プロジェクト別、またはテナント別に支出を集計する方法を説明しました。 Part 2 (この記事) では、そのデータを活用する方法を示しました。IAM プリンシパルデータを含む CUR 2.0 の設定、Amazon Athena でのコストパターンのクエリ、プロジェクトやプリンシパル間での支出比較によるコスト配分の意思決定への活用について説明しました。また、Bedrock に関する同様のインサイトを備えた包括的な AI/ML シートを提供する CUDOS ダッシュボードも紹介しました。 AWS Billing コンソールで発信者 ID データを含む CUR 2.0 を有効にし、提供されている agent.md ファイルを使用して Athena に接続し、最初のプリンシパル別コストクエリを実行してみてください。CUDOS ダッシュボードを使えば、組織全体での Bedrock の導入状況を追跡できます。 著者について Abhi Shivaditya Abhi は AWS のプリンシパルソリューションアーキテクトで、戦略的なグローバルエンタープライズ組織と連携し、人工知能、分散コンピューティング、ネットワーキング、ストレージなどの分野における AWS サービスの導入を支援しています。Abhi は、AWS エコシステム内で高性能な機械学習モデルを効率的にデプロイするお客様を支援しています。 Brenno Passanha Brenno はシニアテクニカルアカウントマネージャーです。Cloud Operations Technical Field Community に所属し、クラウド財務管理に取り組んでいます。仕事以外では、子育て、世界各地への旅行、新しい体験を通じた思い出づくりを楽しんでいます。 Yash Yamsanwar Yash は Amazon Web Services (AWS) の機械学習アーキテクトで、大規模 LLM 推論およびエージェント型 AI システム向けの高性能でスケーラブルなインフラストラクチャを設計しています。トレーニングから本番デプロイまで、機械学習モデルのライフサイクル全体にわたる業務に携わっており、大規模な生成 AI システムの最適化に注力しています。Yash は ML リサーチチームと緊密に連携し、大規模言語モデルやその他の最先端機械学習技術の可能性を広げる取り組みを行っています。 <!-- '"` --> 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの 最終回 となる第 8 回レポートです。シリーズの背景や全体像については、 大阪・IT 企業編レポート をご覧ください。 前日（5 月 14 日）の AI を自社の業務に活かしたい企業の皆様向けセッション に続き、2026 年 5 月 15 日は同じ北海道にて、AI で顧客を支援する IT 企業のエグゼクティブ・技術部門の皆様をお迎えし、「 AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 」と題したイベントを開催しました。会場は前日に引き続き、北海道で地域密着の技術支援を続ける クラスメソッド株式会社 の札幌オフィスをお借りしました。 イベントの流れ 当日はまず、私 Amazon Web Services Japan のソリューションアーキテクト田中から「AWS で一歩先へ！生成 AI 時代のビジネスモデル変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる存在」へと進化してきた流れを整理しながら、AI エージェント時代に IT 企業がお客様の期待にスピーディーかつ継続的に応え続けるための打ち手として、 Kiro のデモを交えながら解説しました（AWS セッションの詳細については 大阪・IT 企業編のレポート をご覧ください）。 AWS セッションを通じて AI エージェント時代のビジネス変革の全体像をつかんでいただいたあと、事例セッションへと進みました。北海道に根差し、自社の開発現場で AI 活用に挑戦し続けている企業の実体験をお話しいただきました。 事例紹介：株式会社アドウイック様 〜「低い点数でもいい」──小さな成功体験が若手エンジニアを変えた AI 活用〜 ご登壇いただいたのは 株式会社アドウイック 技術部 次長の菅原 幸憲 様です。アドウイックは 1977 年創業、親会社のほくやく・竹山ホールディングス（医薬品卸・医療機器・薬局・介護など北海道に根差した総合ヘルスケアグループ）の ICT 事業を一手に担うシステム会社です。グループ会社向けシステムや医療機関向けシステムに加え、業種業界を問わないシステム開発も手がけており、医療機関の待ち時間短縮を目的とした自社製品「シマエナガ・シリーズ」なども展開しています。 ベテランへの集中と人材育成のジレンマ 菅原様はまず、長年抱えてきた課題として人材不足を挙げられました。新卒・若手中途採用はある程度できているものの、育成に時間がかかる。急ぎの案件が多くてナレッジが広がらない。結果としてスピードが上がらず、新しいチャレンジもなかなかできないという状況でした。若手を即戦力に育てることと、ベテランへの集中を解消することを同時に実現するために、2025 年 1 月に AI 活用をスタートさせました。「今いるメンバーでより多くのことを行っていくために、AI を活用していこう」と決断した時点では、ベテランを交えて一緒に挑戦する余裕もない状況でした。だからこそ「若手を中心にチャレンジする」という方針を取ったといいます。 5 名チームで始めた検証、VS Code の延長線上で始められる Cursor を選択 検証はまず、菅原様ご自身が個人でいくつかのツールに課金して試すところから始まりました。「まずやってみる」を自ら体現するスタートです。その後 5 名の少人数チームで複数のコーディングエージェントを比較検証し、品質・スピード・再現性の観点から効果が見込めることを確認した上でプロジェクト全体への展開に踏み切りました。採用したツールは Cursor です。AWS のイベントで Kiro ではなくて申し訳ない、と照れ笑いを交えながら、菅原様は選定理由を語ってくださいました。「VS Code の置き換えが容易なこと」と「複数のモデルが利用できること」──既存の開発環境からの移行ハードルが低く、若手がすぐ使い始めやすい点を重視した選択でした。 3 つのアプリで積み上げた「成功体験」 取り組みを開始してからの 1 年で、チームは Cursor を使って 3 つのサービスをゼロから開発しました。 1 つ目は、FileCarrier というファイルの安全な送受信サービスです。サーバーレス構成を採用し、大事なファイルを扱うためセキュリティには特に力を入れて構築しました。「意識して作ったつもりでも、やはり不安は拭えなかった」と菅原様は振り返られました。そこでクラスメソッドさんに構成レビューを依頼し、お墨付きをもらったことで安心して社内展開を進めることができたといいます。現在は社内利用にとどまっていますが、今後は社外へのサービス展開も視野に入れており、コスト最適化の構成も Cursor と壁打ちしながら固めています。 2 つ目は、BizcaHolder という名刺管理アプリです。アドウイックとして初めて AI を活用したサービスで、もともとは OCR サービスを使っていましたが、読み取り精度がなかなか上がらないという課題がありました。そこに Amazon Bedrock 上の Claude を活用し、AI による文字認識に切り替えたところ、縦書きも横書きも問題なく読み取れるほど精度が格段に向上しました。 3 つ目は、MIMOMO という議事録作成アプリです。音声から文字起こしを実施して AI が要約し、その内容を社内テンプレートにはめ込む、というフローを実現しています。社員からはこの 3 つの中でも特に好評を得ているといいます。 成功体験の連鎖が組織の意欲を引き上げる 菅原様がこの取り組みを通じて大事にした考え方は 3 つです。1 つ目は「まずやってみること」。「いきなり 100 点を狙うのではなく、低い点数でもいいので、まずは試してみる」という姿勢です。実は菅原様、資料作成時には「60 点でいい」と書いていたそうですが、「60 点にこだわる必要もない」と考え直し、「低い点数でも」という表現に変えたのだといいます。前日に同じ会場でご登壇いただいた 北海道文化放送様 の「ある程度で一旦始めてみる」というメッセージと、偶然重なった瞬間でした。2 つ目は「小さく始めること」。大きなシステムを一気に作るのではなく、小さいアプリ・小さい機能から着手してブラッシュアップを繰り返す。3 つ目は「メンバーを巻き込むこと」。指示して動かすのではなく、一緒にやる。各アプリはメンバーを入れ替えながら開発し、参加者を増やして輪を広げていったといいます。 こうした小さな成功体験の積み重ねは、組織に目に見える変化をもたらしました。2016 年から AWS を利用し勉強会も重ねてきたアドウイック様ですが、AI 活用に本格的に取り組む前はクラウドプラクティショナーを取ったら満足という状況が続いていました。ところが昨年は、AWS のプロフェッショナル・スペシャリティ級を含む資格の取得数が、メンバー全体で 1 年に 20 個近くにのぼりました。資格手当・受験料支給・一発合格報奨金といった会社の支援制度との相乗効果で、若手がチャレンジに踏み出すハードルが大きく下がったことも後押しになっています。 見えてきた課題と、次のチャレンジ 一方で課題も見えてきました。経験の浅いメンバーほど AI への依存度が高くなり、AI が生成したコードをそのまま採用してバグが発生するケースが出てきました。また、利用するモデルによってはすぐ上限に達してしまう点もあり、コストを意識した活用の設計が次のテーマになっています。 今後の展望として、社内アプリ開発の継続（すでに 2 つのアプリを作成中）とともに、今回構築したサービスの社外製品化の準備も進めています。50 年近い歴史を持つ会社ならではのレガシーシステムのモダナイゼーションにも、小さな分析から着手しています。運用面では、ルールの見直しに加え MCP の活用による品質・スピードのさらなる向上を模索しているほか、社内での利用拡大に向けた情報共有や勉強会も検討中とのことです。そして菅原様が力を込めて話されたのが、外部との連携強化です。「今まで自社内でなんとかしようという意識がメンバーに強かった」と振り返りながら、今後は AWS のトレーニング・ハンズオン、クラスメソッドさんへの構成レビューやセキュリティ相談など、外部パートナーを積極的に活用していきたいと述べられました。セッション後の質疑応答では「札幌に知見のある会社が構えていてくれる安心感は大きい」という言葉もあり、地域に技術パートナーがいることの価値を改めて感じさせる一幕でした。コミュニティへの参加を通じた外部発信も、次のチャレンジとして挙げていただきました。 写真: 株式会社アドウイック 菅原様によるセッション まとめ 全 8 回にわたり大阪・名古屋・広島・福岡・北海道の 5 拠点を巡ってきた本シリーズを通じて、各地で共通して、AI を「完璧になってから使う」のではなく、「最初のゴールは小さく設定して、すぐ試す」というスタイルが、組織の変化を生み出していることが見えました。本シリーズが、読者の皆様の「まず一歩を踏み出す」きっかけになれば幸いです。 AWS では、日本全国の様々な拠点に対して、最新情報の発信や、AI に関するお取り組みのご支援を今後も行っていきます。 もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に AI を活用したビジネス変革に取り組みたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 広島編（#5/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 博多編（#6/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 北海道編（#7/8）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 7 回レポートです。シリーズの背景や全体像については、 初回の大阪・事業会社編レポート をご覧ください。 大阪・名古屋・広島・福岡に続き、2026 年 5 月 14 日は北海道にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。会場は、北海道で地域密着の技術支援を続ける クラスメソッド株式会社 と共催で、札幌オフィスをお借りする形で開催いたしました。 写真: クラスメソッド株式会社札幌オフィスでのイベント当日の様子。クラスメソッド東日本営業本部 本部長三浦様よりご挨拶 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト木村 友則から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる」存在へと進化してきた流れ、人手不足という社会課題に対して AI エージェントが果たせる役割、そして AI コーディングツールの Kiro と AI エージェントプラットフォームの Amazon Quick を、デモを交えてご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: ソリューションアーキテクト木村によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、事例セッションへと進みました。ここでは、AI によるナレッジ継承の新しいアプローチに取り組む企業様に、その現場で得られた知見をお話しいただきました。 事例紹介：クラスメソッド株式会社様 &amp; 北海道文化放送株式会社様 〜暗黙知をデジタル資産に変える、AI によるナレッジ継承〜 事例紹介は、 北海道文化放送株式会社（UHB） 営業推進部 武舎 巧真 様と クラスメソッド株式会社 AI Experience Center Director 舘野 勉 様の共同登壇です。UHB は、1972 年開局のフジテレビ系列のテレビ局で、北海道を拠点に報道・情報番組から地域密着コンテンツまで幅広く手がける放送会社です。当日はクラスメソッド舘野様より新サービス ghoost 誕生秘話のご紹介を、UHB 営業推進部の武舎様から、実際に ghoost を活用したお取り組みの事例をお話しいただきました。 組織の「知恵」はなぜ継承されないのか 「AI をただ導入しただけだと、使う人となかなか利用にいたらない人が存在し、生産性の幅が生じてしまう。優秀な人の知見を組織全体に広めることに課題を持っている企業は多い」。舘野様は、ツールの機能の優劣以上に「自分の業務にどう絡ませるか」のデザインが成果に大きく影響する、という経験則を持っておられました。この問いから生まれたのが、クラスメソッドが開発した AI エージェントサービス ghoost です。 ghoost は、個人の知見・思考パターン・判断基準をインタビューと分析を通じて AI エージェントとして再現するデジタルツインサービスです。初期エージェントの生成は 1〜2 時間という迅速さで、1 人のユーザーに対して「職種のスペシャリストとしての顔」「チームリーダーとしての顔」といった複数の側面を多面的に合成して構成するところが特徴です。同僚や後輩がそのゴーストにいつでも話しかけられる環境をつくることで、「欲しいときに欲しい情報をすぐ回答してもらえる環境」を組織全体に届けることを目指しています。このように、普段の業務と密接に関連した知識を持ち、普段の業務判断に近い応答結果を出力できることで、AI がまるでチームメンバーの一人のように普段の業務に参加していくことを目指したサービスです。2026 年 3 月に開始した クラスメソッドでの早期検証では、16 名を対象に 162 セッションを実施し、生成された ghoost の回答のうち 92.3% が「本人らしい」と第三者に評価されました 。 暗黙知を「動くデジタル資産」に変える挑戦 UHB 武舎様は「番組制作に関わる業務は、ベテランの経験と感性に強く依存することが多かった」と、テレビ制作業界の特性について語られました。こうした属人化の課題は、視聴率分析の業務においても見られ、相談が特定の専門家に集中しやすく、ナレッジが個人の中に閉じやすいという課題を長年抱えていました。 これに対する打ち手として、ghoost を活用し、個人の知見をデジタルツインとして再現することで課題解決につなげる方向性を議論し、クラスメソッドと共同で PoC をスタートしました。PoC を始めるにあたり、「過去に突発的な案件を短いスケジュールで応えていただいた」、「リモートが当たり前になった今でも、拠点が近く、必要な時にすぐ顔を合わせて議論できる」点があったからこそ、信頼感を持って新しい取り組みに踏み出せたということです。 検証で成果を測り、現場に根づかせる UHB 様では、社員へのインタビューを通じて、個人の知見や判断基準を ghoost として再現する検証を進めました。また、検証フェーズに入る前には、導入可否を判断しやすくするため、あらかじめ撤退基準を設ける工夫も行いました。評価にあたっては、ROI の見える化（定量値）と、ghoost を実際に活用した社員自身が「これは自分らしい」と感じられるかどうか（定性値）、の二軸で検証しました。この基準を事前に定めておいたことで、結果として投資判断がしやすい状況を整えることができたということです。 UHB の武舎様は、「今後も地道な伴走が不可欠で、現場が主体的にこのツールを活用していくまでに、粘り強い活動も必要」と述べられました。さらに、「残業時間の削減、作業効率の向上、といった短期的な成果に加えて、『浮いた時間を思考的・戦略的な業務に投入できる』という中長期的な成果の価値を、社内で伝え続けることも重要」とも述べられました。 さらに「自分たちにとって 100 点のサービスを期待していると、待っているだけで終わってしまう。ある程度で一旦始めてみて、信頼できる方に相談しながら進めるといい」と、信頼のおけるプロジェクト体制の重要さも語られました。 写真: UHB 武舎様 によるセッション まとめ セッション後のディスカッションタイムやネットワーキングでは、参加者同士で自社の AI 活用における課題について活発な議論が交わされました。北海道内の異業種の参加者が一堂に会する、忌憚のない情報交換ができた場になったと感じています。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしています。次回はシリーズ最終回、北海道 IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 広島編（#5/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 博多編（#6/8）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

20 年前の 8 月 25 日、 Jeff Barr が Amazon EC2 ベータ版を公開したブログ記事を書きました。その記事では、1 つのリージョン (米国東部) で 1 つのインスタンスタイプ ( m1.small ) の、時間単位で課金されるサイズ変更可能な Linux 仮想サーバーをクラウド内で紹介しました。最小限でありながら有用であり、コンピューティングインフラストラクチャに対する世界の考え方を変えました。 2021 年、Jeff は EC2 の 15 年にわたる歴史について、その裏話や記憶に残る EC2 の立ち上げについて取り上げました 。過去 5 年間、AWS はクラウドコンピューティングが提供できることの限界を押し広げ続け、汎用ワークロードと AI ワークロード用のカスタムシリコンを構築し、2006 年のお客様が想像もできなかった新しいフォームファクターとデプロイモデルに EC2 を拡張してきました。 20 年の概要 Jeff は 15 周年記念記事の中で、今日でも顧客が頼りにしている基本的なビルディングブロックを確立した EC2 の重要なマイルストーンを選びました。 Amazon Elastic Block Store (2008) は永続ブロックストレージを提供しました。 エラスティックロードバランシング、オートスケーリング、Amazon CloudWatch (2009) により、アプリケーションのスケーラビリティと可用性が高まりました。 Amazon 仮想プライベートクラウド （2009）は、顧客に論理的に分離されたネットワークを提供しました。 AWS Nitro System (2017) は、より迅速なイノベーションと強化されたセキュリティを実現しました。 AWS Graviton プロセッサ (2018) は、コスト重視のスケールアウトワークロード向けに設計されました。 20 年以上かけて、EC2 は 1 つのインスタンスタイプから 1,200 を超えるインスタンスタイプへと成長し 、汎用、コンピューティング、メモリ、ストレージに最適化された、アクセラレーテッドコンピューティングファミリー、ハイパフォーマンスコンピューティングファミリーにわたる顧客のニーズに応えました。これらのインスタンスは、1 つの AWS リージョンから世界で 39 のリージョンに拡大しました 。また、AWS は EC2 インスタンスをローカルで実行する AWS Outposts (2018)、各地に配置する AWS ローカルゾーン (2019)、世界中の 5G 通信事業者ネットワーク内の AWS Wavelength (2019) により、リージョンの境界を越えて EC2 を拡張しました。 えこひいきはしたくありませんが、過去 5 年間の EC2 のリリースの中からお気に入りをいくつか選びたいと思います。 大規模な ML 推論のための AWS Inferentia (2019): AWS Inferentia チップを搭載した専用の ML 推論インスタンス (inf1) を導入しました。 Amazon EC2 Inf2 インスタンスは 、2023 年 4 月に大規模な生成 AI 推論ワークロード向けに一般公開されました。AWS Trainiumインスタンスは、Inferentiaファミリーとともに、推論とトレーニングの両方における AI ライフサイクルのあらゆる段階に最適化された、AWS が設計したシリコンのフルスタックを顧客に提供するようになりました。 EC2 Mac インスタンス (2020): 最初の Mac インスタンス (mac1) は、AWS ニトロシステム上のインテルコア i7 (コーヒーレイク) を搭載した Apple Mac mini 上に構築されました。 Mac M1 (mac2) インスタンスは、EC2 で初めての ARM ベースの macOS インスタンスとして 2022 年 7 月にリリースされました。 2023 年には M2 Pro Mac インスタンス 、 2025 年には M4とM4 Pro Mac インスタンス 、 2026 年にはM3 Ultra Mac インスタンスと M4 Max Mac インスタンスが続きました 。これにより、Apple の開発者は、macOS、iOS、iPadOS、tvOS、watchOS、および&nbsp; VisionOS アプリケーション向けの幅広いクラウドベースのビルドおよびテスト環境を利用できます。 大規模なフルスタック AI ワークロード向け AWS Trainium (2021) : 2021 年 11 月、ハイパフォーマンスなディープラーニングトレーニングに最適化された AWS Trainium アクセラレータを搭載した Trn1 インスタンスをプレビューしました。2024 年 12 月、AWS Trainium2 を搭載した Trn2 インスタンスがローンチされました 。 Trn2 UltraServer は NeuronLink を介して 64 基の Trainium2 アクセラレーターをリンクし、1兆パラメーターの基礎モデルをレーニングするためのものです。AWS re: Invent 2025 では、AWS Trainium3 を搭載した Trn3 UltraServer が、次世代のエージェント、推論、およびビデオ生成アプリケーションに最高のトークンあたりのコスト効率を提供します。1台の Trn3 UltraServer が最大144個の Trainium3 チップを相互接続して、最大規模のフロンティアモデルのトレーニングとサービスを提供します。現在、AWS Trainium3 は、ハイパフォーマンスな AI トレーニングと推論を大規模に実施する業界トップクラスのコストパフォーマンスを実現しています。 機械学習用 EC2 Capacity Blocks (2023): この新しい EC2 利用モデルは、機械学習と生成 AI モデルのトレーニングとデプロイに GPU インスタンスに簡単にアクセスできるようにすることで、ML の民主化をさらに促進し、ML の民主化をさらに促進します。必要な GPU 容量 (最初は P5 インスタンス ) を将来の日付のために予約し、必要な期間のみ予約します。&nbsp;2024 年 11 月、ML 用 EC2 キャパシティブロックは、 プロビジョニングを数分で行えること と、最長 6 か月まで延長できることをサポートするようになりました。 現在、ML 用 EC2 キャパシティブロックは、P5 に加えて P6-B300 、 P6-B200、P5e 、 P5en 、P4d 、P4de、Trn1、Trn2、Trn3 の各インスタンスをサポートしています。 AWS Graviton5 (2025): 2018 年から 8 年間続いてきた Graviton のイノベーションをもとに、AWS re: Invent 2025 で Graviton5 チップをプレビューし、Graviton5 を搭載し、第 6 世代の AWS Nitro System上に構築された M9g と M9gd インスタンス を立ち上げました。 C9gとC9gdは2026年6月に続きました 。現在、 Graviton5 は192コア、5 倍のキャッシュ、コア間のレイテンシーを最大&nbsp; 33%&nbsp; 低減するという特徴を備えているため、大規模で継続的かつ高スループットの CPU コンピューティングを必要とするリアルタイム推論、コード生成、マルチステップのタスクオーケストレーションなど、高まるエージェンティック AI ワークロードの需要の高まりに適しています。 AWS Nitro 分離エンジン (2026): お客様は、当社からの連絡だけでなく、Nitro ハイパーバイザーにおけるワークロード分離の証拠を見たいと考えていました。Nitro Isolation Engine は、Nitro Hypervisor内の専用コンポーネントであり、正式な検証を利用してお客様のワークロードが相互に、また AWS オペレーターから分離されていることを数学的に保証します。これにより、数学的に証明されたクラウドセキュリティの新しい標準が開拓されます。この機能も、2017 年の導入以来進化を続けてきた第 6 世代の AWS Nitro システムに基づいています。 その根底にある基盤 20 年にわたる革新にもかかわらず、Amazon EC2 の基本的な価値提案は変わっていません。お客様はこれを利用して、安全でサイズ変更可能なコンピューティング容量を数分で手に入れることができ、支払いは使用した分のみで、長期的な契約なしにオンデマンドで拡張できます。その柔軟性は、2006 年には誰も予想していなかった規模のAIワークロードにも及んでいます。 EC2 は依然として AWS の基盤となるコンピューティングレイヤーです。 Amazon ECS、 Amazon EKS 、AWS Lambda、AWS Fargate、AWS Batch 、 Amazon EMR、Amazon SageMaker AI、Amazon Bedrockは最終的に EC2 キャパシティで動作します 。シンプルなウェブサーバーから数兆のパラメータを持つ基礎モデルトレーニングクラスターまで、お客様が過去 20 年間に構築してきたすべてのアーキテクチャパターンは、インスタンスを起動する決定から始まります。 私たちは 2006 年に確固たる基本決定を下し、サービスを拡大する余地を残しました。20 年経った今も、最小限でありながら便利なサービスを作成し、迅速にリリースし、お客様のフィードバックに応じて迅速に反復するという戦略が、私たちが構築する方法の指針となっています。今後 20 年間のクラウドコンピューティングには、私たちがまだ想像していなかった機能が必要になります。Amazon EC2 は引き続き、お客様のワークロードを実行する基盤となります。 Amazon EC2 の詳細については、Amazon EC2 製品ページをご覧になるか 、 EC2 の新機能をご覧ください 。 – Channy 原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は 2026 年 7 月 17 日（金）、麻布台ヒルズの AWS ジャパンオフィスにて「Adtech Meetup ～変わる広告、変わらない価値 ― いまアドテク事業者が AWS に集まる理由～」を開催しました。アドテクノロジー（アドテク）・マーケティングテクノロジー事業を展開する企業 19 社から 39 名のお客様にご参加いただき、AI 時代の広告ビジネスの構造変化と成長戦略をテーマに、セッションと懇親会を通じて活発な議論と交流が行われました。 サードパーティ Cookie の廃止に代表されるシグナルロスや AI の台頭など、いまインターネット広告を支えるアドテク事業者は大きな転換点を迎えています。AWS はこうした変化に向き合うお客様を支援するため、リアルタイム広告取引（RTB: Real-Time Bidding）ワークロード専用のネットワークサービス AWS RTB Fabric を提供しており、 国内では株式会社 fluct 様と UNICORN 株式会社様による国内初の商用本番接続 が始まっています。本イベントは、この転換点を乗り越える新たな武器となる AI やインフラのトレンドをお届けすること、そして業界の垣根を越えた事業者間連携のきっかけを作ることを目的に企画しました。本記事では、イベントの模様をレポートします。 イベント概要 日時: 2026 年 7 月 17 日（金）16:00 – 19:00 会場: 麻布台ヒルズ 森JPタワー 36 階 AWS セミナールーム 参加者: アドテク・マーケティングテクノロジー関連企業 19 社 39 名 アジェンダ オープニング Session ①: AI が変えるプログラマティック広告 ― いま起きている変化と、これからの対応 Session ②: 広告コストを収益に変える – AWS RTB Fabric のご紹介 Session ③: パネルディスカッション「アドテク事業者の成長戦略 ― オープンエコシステムが切り拓く次の一手」 クロージング 懇親会・ネットワーキング オープニング イベントの冒頭では、AWS ジャパン 代表執行役員社長 白幡 晶彦より開会の挨拶を行いました。広告業界の各事業者の皆様が麻布台ヒルズに一堂に会したことへの感謝とともに、広告テクノロジーを取り巻く市場が大きく変化する中、お客様を起点にアドバタイジング領域に取り組んでいく AWS の姿勢を伝え、イベントの幕を開けました。 Session ①「AI が変えるプログラマティック広告 ― いま起きている変化と、これからの対応」 Speaker: 鈴木 康士郎（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト） 最初のセッションでは、AWS ジャパンの鈴木より、プログラマティック広告を取り巻く 2 つの大きな変化を解説しました。1 つ目は、サードパーティ Cookie の廃止・制限やプライバシー規制の拡大により、ユーザーの興味や行動に基づく広告配信が困難になる「シグナルロス」、2 つ目は、生成 AI が検索から購買まで消費者行動に入り込む「AI の購買プロセスへの浸透」です。そのうえで、この変化に対応し成果を出している先行企業の取り組みを、(1) オーディエンスセグメンテーション × AI、(2) AWS Clean Rooms × AI、(3) メディアプランニング × AI、(4) Agentic AI の 4つの領域に整理して事例とともに紹介し、「変化への対応は『やるかどうか』ではなく『いつやるか』の問題」と締めくくりました。 Session ②「広告コストを収益に変える – AWS RTB Fabric のご紹介」 Speaker: 関藤 寛喜（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト） 続いて、AWS ジャパンの関藤より、広告配信のインフラ層を支える AWS RTB Fabric を紹介しました。RTB では、一連の入札処理を概ね 100 ミリ秒以内に完了させる必要があります。この要件を満たすために維持する大規模なインフラのコストが利益を圧迫することが、SSP（Supply-Side Platform）/ DSP（Demand-Side Platform）事業者の構造的な課題となっています。 AWS RTB Fabric は、この課題を解決する RTB 通信に特化したネットワークサービスです。本イベントのタイトルにある「変わらない価値」、すなわちお客様が磨き上げてきた独自の入札ロジックや最適化アルゴリズムはそのままに、10 ミリ秒未満のレイテンシーと、標準的なクラウドネットワーク費用と比較して最大 80% のコスト削減を実現します。削減したコストと処理時間は、接続先の拡大による収益機会の最大化や、新たな取り組みへの投資に振り向けられます。サービスの詳細や海外事業者の導入事例については、 ブログ や AWS Black Belt の資料 をご参照ください。 Session ③ パネルディスカッション「アドテク事業者の成長戦略 ― オープンエコシステムが切り拓く次の一手」 パネリスト: 株式会社 fluct 代表取締役 COO 黒田 岳志 氏 UNICORN 株式会社 取締役 KYO 氏 モデレーター: 松本 鋼治（アマゾン ウェブ サービス ジャパン合同会社 戦略事業開発本部 プリンシパル事業開発マネージャー） パネルディスカッションでは、AWS RTB Fabric 上で国内初の商用本番接続を実現した SSP 事業者の fluct 様と DSP 事業者の UNICORN 様をお迎えし、事業課題から成長戦略、AI 時代の展望までを議論いただきました。 アドテク事業者が直面する転換点 議論の出発点となったのは、生活者のデジタル利用時間の約 55% を Open Web が占める一方、広告費は約 30% しか投資されていないというギャップです。Open Web へのシフトが進む中で自社がどう変わっていくか、そして「買っていただける在庫供給とは何か」をどう追求するかといった経営課題が挙がったほか、サードパーティ Cookie 廃止によるターゲティングへの影響や、リテールメディア・CTV といった新しい広告在庫の拡大など、業界の転換点を示すトレンドも共有されました。 課題にどう向き合うか ― データクリーンルームと AWS RTB Fabric の価値 こうした課題への打ち手として、パブリッシャーのデータを外部に出さずに活用するデータクリーンルームの取り組みや、オンラインとオフラインを横断する新しい配信インフラの構想が紹介されました。 インフラ面では AWS RTB Fabric が話題となり、SSP の立場からは、「リクエストを絞る」という売上を下げる行為をしなくてよくなることで、守りのコスト削減ではなく攻めのビジネスにエンジニアリソースを振り向けられるという価値が語られました。DSP の立場からも、リクエストを多く受けるほど売上が上がる構造にあるため、通信コストを気にせず配信できる仕組みへの期待が示されました。 AI 時代の展望 ― テクノロジーと人の両輪で 最後に、AI 時代の展望について議論しました。複雑化する広告環境での最適なマッチングや、既存トラフィックの価値の再発見といった AI 活用の方向性が語られ、AI エージェントがメディアプランニングを担う時代には Open Internet が再評価されるのではないかという見方も示されました。一方で印象的だったのは、登壇者が揃って「人」の重要性を強調したことです。買い付けの利便化により事業者間の人的なやり取りが減っている今こそ、コミュニケーションを密にし、連携してサービスを作っていくべきだという見解で一致しました。AWS に対しては、データ流通の信頼性担保や個人情報対応など、事業者が本業に集中できる仕組みづくりへの期待が語られ、セッションは幕を閉じました。 クロージング・懇親会 クロージングでは、本日の議論で挙がった課題への次の一手につながる AWS からのご提案として、パネルでも議論になった事業者間連携を後押しする、AWS RTB Fabric のエコシステムを活かしたお客様同士の共創・マッチング支援などをご案内しました。イベント後のアンケートでは、多くの企業からこれらのご提案への関心が寄せられました。 セッション終了後の懇親会では、参加企業名を会場に投影し、参加者同士のネットワーキングを促進しました。同じ業界でビジネス上の接点がある企業同士でも「リアルでは初めまして」という挨拶が会場のそこかしこで交わされ、業界の垣根を越えた新たなつながりが生まれる場となりました。 参加者の声 ご参加いただいたお客様からは、以下のような声をいただきました。 「RTB Fabric をはじめ、他社の広告事業の方向性についても知る機会をいただき、大変参考になりました。AWS さんのネットワークを通じて広告業界が盛り上がれると嬉しいです！」 「RTB Fabric、新規に構築しようとしているサービスでは是非使ってみたいです！」 「広告業界の動向・データ連携の進化、AI 時代における取り組みなど多くを学ぶことができ大変参考になりました。懇親会でも幅広く情報を得られました。」 アンケートにご回答いただいた方の 8 割以上から「今後もこのようなイベントに参加したい」との回答をいただきました。また、参加企業の多くがすでに広告配信基盤として AWS をご利用いただいていることも、あらためて確認できました。 おわりに 本イベントのタイトルである「変わる広告、変わらない価値」の通り、シグナルロスや AI によって広告を支えるテクノロジーと手法は大きく変わりつつあります。一方で、アドテク事業者の皆様が磨き上げてきた独自の技術やデータという事業の価値、そして事業者同士がつながり業界を盛り上げていくことの価値は変わりません。 本イベントでは、こうした転換点を乗り越える新たな武器として、AI の活用パターンや AWS RTB Fabric をはじめとするインフラの最新動向をお届けしました。また、パネルディスカッションから懇親会までを通じて事業者間連携の重要性があらためて共有され、アンケートで「接続可能なパートナー企業を紹介してほしい」という具体的なご要望を複数いただくなど、業界の垣根を越えた新たなつながりが生まれるきっかけとなりました。 AWS は、サービスの提供とお客様同士の共創・協働を支える場づくりを通じて、広告業界の発展に貢献してまいります。今後も同様のイベントを企画していく予定です。 AWS RTB Fabric の詳細や個別のご相談については、担当のアカウントチームまたは お問い合わせ よりお気軽にご連絡ください。 このブログは、ソリューションアーキテクトの久野が執筆しました。

AWS にいる間、私はいつも学生と一緒に働く機会を探していました。私は地域の大学で 50 回以上の講演を行ってきましたが、会場で可能性を観察することは常に強いモチベーションになっています。それは、なぜ私がこの仕事をしているか、また今日会う学生が明日私たちの顧客や協力者になるかもしれないということを思い出させてくれます。それが、私が 2026 年 8 月 24 日週に AWS Builder Center で学生リワードを提供できることを嬉しく思う理由です。 Rick Suttles 氏が「 AWS Builder Center での学生リワードの紹介 」を公開しました。これは、認定を受けた高等教育学生向けの新しい特典です。SheerID を通じて登録を確認し、Builder Center プロファイルを完了すると、12 か月間のプレミアム AWS Skill Builder アクセス (900 以上のコース、ハンズオンラボ、認定試験の準備、ゲームベースの学習) がロック解除されます。そこから、Builder Center でのアクション (記事の公開、コメント、エンゲージメントの維持) を通じてバッジを獲得できます。バッジが 7 個になると、10 USD の AWS クレジットをロック解除できます。バッジが 14 個になると、さらに 20 USD のクレジットが得られます。バッジが 21 個になると、AWS 基礎認定試験バウチャー (100 USD 相当) を獲得できます。 これは、この新学期シーズンに 5 億 USD 以上のリソースのコミットメントを表しており、クラウドと AI でのキャリア構築を始めるために必要なトレーニング、ツール、認定資格を学生に提供します。学生リワードは、世界中の認定高等教育機関に在籍している 18 歳以上の学生を対象としています。ただし、検証と利用規約の対象となります。 学生のステータスを確認して 、学習を開始し、バッジを獲得し、リワードをロック解除しましょう! 2026 年 8 月 17 日週のローンチ その他、8 月 24 日週に発表された事項をご紹介します。 ネバダ州ラスベガスの新しい AWS ローカルゾーン — この新しいローカルゾーンは、Amazon EC2 C7i、M7i、R7i、C8gn インスタンス、Amazon EBS、Amazon ECS、Amazon EKS、Application Load Balancer、AWS Direct Connect をサポートします。AWS ローカルゾーンは、世界中の 30 を超える大都市圏で利用できるようになりました。さらに、AWS は 欧州 (ロンドン) リージョンに 4 つ目のアベイラビリティーゾーン を追加し、汎用コンピューティングに加えて Trn3 と P6 の高速インスタンスによる次世代 AI と ML のキャパシティを提供しました。 Amazon EC2 Auto Scaling がバッチインスタンスの終了をサポートするようになりました – 最大 100 個のインスタンス ID を TerminateInstanceInAutoScalingGroup API に渡してバッチとして終了できるようになりました。これにより、自動スケーリンググループのスケールダウンに必要な API コールの数が削減されました。バッチ終了は、AI/ML トレーニングジョブ、コンテナオーケストレーター、または一時的に大規模なフリートをスピンアップするイベント駆動型アーキテクチャなど、迅速なスケールダウンが必要なワークロード向けに設計されています。 AWS CloudShell に組み込みのビジュアルファイルエディタが含まれるようになりました – CloudShell には、単一の編集コマンドを使用してシェルセッションから直接起動できるビジュアルファイルエディタが含まれるようになりました。このエディタは、シンタックスハイライト、検索と置換、複数行選択、コピーアンドペースト、元に戻す/やり直すを単一のブラウザセッションでサポートしています。デプロイスクリプトの更新、エージェントステアリングファイルの変更、CloudFormation テンプレートの編集、Lambda 関数の修正のいずれを行っている場合でも、このエディタは CloudShell から離れることなくシームレスに編集して実行できるようにします。 Amazon Bedrock がクロスリージョン推論による SpaceXAI Grok 4.6 をサポートするようになりました – コーディング、エージェントタスク、ナレッジワーク向けに構築されたフロンティアモデルである Grok 4.6 が、Amazon Bedrock 上で利用できるようになりました。&nbsp;このモデルは、レスポンス、チャット完了、コンバース API をサポートする bedrock-runtime エンドポイント上で実行され、モデル呼び出しログ記録、Amazon CloudWatch メトリクス、AWS Cost Explorer のコスト項目化など、既存のアカウントレベルのコントロールと連携します。 Amazon Bedrock が API サポートを拡張し、OpenAI モデルにクロスリージョン推論を導入しました – Amazon Bedrock が、レスポンス、コンバース、チャット完了 API で OpenAI GPT-5.6 モデル (Sol、Terra、Luna) をサポートするようになり、クロスリージョン推論が追加されました。地理的クロスリージョン推論は、事前定義された地域内でリクエストをルーティングします (今回のローンチでの米国地域サポートを含む)。一方、グローバルクロスリージョン推論は、低いトークンあたりのコストで、あらゆる商用 AWS リージョンからのリクエストを処理します。 AgentCore 支払いが Amazon Bedrock AgentCore で一般的に利用できるようになりました – 一般提供時点では、AgentCore コンソール内での Coinbase 認証情報の直接プロビジョニングのためのクイック作成、AgentCore Gateway を介した従量課金型の x402 エンドポイントの厳選された Coinbase Bazar MCP サーバー、Machine Payment Protocol (MPP) のサポート、および x402 プロトコルの「upto」スキームが含まれます。推論に応じた料金とダイナミックプライシングのユースケースに対応します。詳細については、 AI ブログの記事 をご覧ください。 AWS Glue 6.0 が 30% の料金引き下げと Iceberg v3 のサポートを提供 – AWS Glue 6.0 は、完全にモダナイズされたランタイム、Apache Spark 4.1、Python 3.13、および Scala 2.13 に基づいて構築されており、以前の AWS Glue バージョンよりも 30% 低い料金を提供しています。Iceberg v3 では、Glue 6.0 には、半構造化データの読み取りを高速化する自動シュレッダー処理、高性能な行レベルの更新のための削除ベクトル、空間処理用のジオメトリおよび地理データ型、および柔軟なスキーマ展開機能を備えた VARIANT データ型が追加されました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 AWS サインインエクスペリエンスの更新 – AWS では、サインインおよびサインアップエクスペリエンスの更新を徐々に導入しています。再設計されたサインインページでは、新しい E メールベースのサインイン方法を使用するルートユーザーと顧客のための統一された E メールエントリポイントが導入され、IAM ユーザーは引き続きアカウント ID、ユーザー名、およびパスワードを使用してサインインできます。このページには、サポートされている ID プロバイダー (Google、GitHub、Apple、または Amazon.com) を使用して AWS アカウントを作成した顧客向けのサインインオプションも含まれています。再設計されたセッション選択ページにより、複数のアクティブなアカウントおよびロールセッションの表示と管理が簡素化されました。サインインページを操作するブラウザ自動化またはスクリプト化されたワークフローに組織が依存している場合は、投稿を確認して、これらの変更が構成にどのように影響する可能性があるかを理解してください。 開発中: ベルリン、ハイデラバード、サンパウロの AWS Builder Loft – 私の同僚の Channy が 3 つの都市に新しい Builder Loft をオープンする計画を発表しました。2025 年 7 月にサンフランシスコに最初の Builder Loft がオープンして以来、22,500 人以上の開発者を迎えてきました。新しい場所はそれぞれ、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コワーキングエリアを提供する常設コミュニティスペースになります。ベルリンはデジタル主権とセキュリティ対策に、ハイデラバードは AI とクラウドネイティブアーキテクチャに、サンパウロはラテンアメリカの開発者エコシステムのサポートに焦点を当てます。 AWS と Amazon WorkSpaces が 2026 Gartner Magic Quadrant for Desktop as a Service のリーダーとして認められました – AWS は、ビジョンの完全性と実行能力が評価され、2026 Gartner Magic Quadrant for Desktop as a Service (DaaS) で、3 年連続でリーダーに選ばれました。Gartner は、オペレーション、地理的戦略、および全体的な存続可能性に強みがあると認めました。また、人間のユーザーと同じデスクトップ環境、セキュリティ境界、および監査証跡内で AI エージェントを実行する機能である Amazon WorkSpaces for AI エージェントが評価対象になったのは今年が初めてです。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – ビルダーやイノベーターがクラウドで最新情報を学び、交流し、探求するための無料の対面イベント。開催予定: チューリッヒ (9 月 2 日)、 サンパウロ (9 月 3 日)、 テルアビブ (9 月 10 日)、 ドバイ (9 月 30 日)。また、 AWS Summits Global Livestream + On-Demand Hub で基調講演やセッションを視聴することもできます。特定の Summit のライブコンテンツやオンデマンドコンテンツにアクセスするには、そのイベントに登録する必要があります。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 ボリビアのサンタクルス (8 月 29 日)、 カナダのトロント (8 月 29 日)、 東京の JAWS SONIC (9 月 5 日)、 ポーランドのワルシャワ (9 月 8 日) などがあります。 AWS Builder Center にアクセスして、他のビルダーと交流したり、ソリューションを提供したり、構築を継続するのに役立つリソースを見つけたりしましょう。 夏も徐々に終わりに近づいています。私は、これから雨の多い秋を乗り切るために、今後数か月のうちに数日の休みを計画しています。お客様も同じように計画していることを願っています。8 月 31 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。

本記事は 2026 年 8 月 26 日 に公開された「 AWS and DuckLabs: Building the future of analytics together 」を翻訳したものです。 本日、 Amazon が DuckLabs を買収する最終契約を締結したこと を発表します。DuckLabs はオープンソースの分析データベース DuckDB を開発する、アムステルダム拠点の企業です。取引は通常のクロージング条件が満たされ次第、まもなく完了する見込みです。DuckDB を開発し DuckLabs を共同創業した Hannes Mühleisen と Mark Raasveldt は、AWS の一員として引き続きチームとオープンソースプロジェクトの技術的方向性を率いていきます。DuckDB オープンソースプロジェクトも引き続き DuckLabs チームが推進し、独立した Foundation (DuckDB を統括する非営利団体) の下でオープンソースとして維持され、現在と同様に MIT ライセンスで利用可能です ( DuckLabs ブログ を参照)。 データは常に企業の中核となる資産であり、差別化の源泉でした。組織が自社のデータで推論をカスタマイズし AI エージェントを構築する今、その重要性はこれまで以上に高まっています。AWS は 20 年間、データの最前線を切り拓いてきました。あらゆるビジネスにデータレイクをもたらした Amazon S3 のローンチに始まり、初のクラウド分析サービスである Amazon EMR、初のクラウドデータウェアハウスである Amazon Redshift、さらに Athena や Glue ETL などで導入してきた数々の機能があります。S3 Tables で直接利用できる Apache Iceberg 機能、データレイク内のベクトルストレージ、新しく最適化された Graviton ベースの Redshift クラスターなど、AWS のお客様のためにデータ領域での革新を続けています。 DuckDB もまた、世界のデータの扱い方を変える最前線に立ってきました。Hannes と Mark は、Python を生み出したことでも知られるオランダの国立研究機関 Centrum Wiskunde &amp; Informatica (CWI) 在籍中に DuckDB を開発しました。DuckDB の創業者たちは、従来のデータベースや Spark のような分析エンジンが超大規模データ処理のパフォーマンスに注力する一方で、多くのお客様が SQL 分析で行う作業の中心を占める、より小さなサイズのデータクエリに効果的に「スケールダウン」する手段を持っていないと気づきました。 DuckDB が取り組んだのは、今日のデータクエリの 90% 以上を占める、分析やダッシュボード作成で 1 テラバイト以下のデータを扱うクエリを圧倒的な速度で処理する課題です。DuckDB のアーキテクチャは「日常的な SQL クエリを超高速にする」という前提に基づいており、他のアプリケーションのインプロセスで動作するため、アプリケーションとのデータのやり取りが簡単かつ高速になります。DuckDB はベクトル化実行によって大きなパフォーマンス向上を実現しています。 SELECT * FROM table のような単純な文の実行に重たいコンパイラを必要としないためです。日常的なクエリでうまく機能する仕組みは、当然ながらエージェントでもうまく機能します。エージェントはデータと対話するときに人間とよく似た振る舞いをするからです。軽く探ってみる。試してみる。本当にやりたいことを見極める前に、小さなデータセットで探索的な分析を行う。DuckDB は AI エージェントが使うのに自然と最適化された形になっています。学術プロジェクトとして始まったものが、今ではデータエンジニアリング、データサイエンス、分析、そして AI エージェントに至るまで、使いやすさと純粋なパフォーマンスの点で広く採用されています。私たちは、1 テラバイト以下の日常的なクエリにおける DuckDB の強みを、エクサバイト超のエンタープライズ規模で実績のある S3 と、数百テラバイトからペタバイト級のデータで分析を支える Redshift、Athena、EMR、Glue-ETL、SageMaker プラットフォームなどの AWS 分析サービスと組み合わせる計画です。AWS の Distinguished Engineer である Andy Warfield が、Werner Vogels の All Things Distributed ブログで DuckDB and the Changing Physics of Analytics について語っています。 お客様は現在、DuckDB を AWS サービスと組み合わせて活用しており、その速度とシンプルさを高く評価しています。たとえば DuckDB は現在、ローカルや S3 などのクラウドストレージに保存された Parquet、CSV、JSON といった外部ファイルに対して SQL を直接実行し、他に類を見ないパフォーマンスと大幅に低いコストを実現しています。 Allen Institute の Scientific Computing 担当 Executive Director である David Feng 氏は次のように述べています。 「Allen Institute は、生物学における最大級の問いに大規模に取り組むことで、より健康な世界のための科学を加速しています。そこには、大規模でマルチモーダルなデータの広範な分析が伴います。私たちは 2025 年に数テラバイトの科学データを分析するために DuckDB を使い始め、大変気に入っています。神経生理学および行動データのリアルタイム品質管理と分析のためにデータを S3 に保存しており、これは次のデータ取得を進める上で欠かせません。数分かかっていたクエリが 1 秒未満で返るようになり、データとのまったく新しい対話方法が可能になりました。」DuckDB は AWS Lambda 関数のインプロセスで実行することもできます。 DuckDB アプリケーションが AWS で最高のパフォーマンスを発揮するようにし、DuckDB と AWS のビルディングブロックサービスとの深い統合に引き続き投資していきます。 AWS 自身のインフラでも DuckDB を活用しています。Amazon Quick は独自のダッシュボードエンジンのパフォーマンスを強化するにあたり、S3 Tables のデータへのクエリに DuckDB を選びました。Quick チームは、DuckDB エンジンが CPU 数に応じてスムーズにスケールし、単一のライブラリを Quick の内部コントロールプレーンサブシステムに簡単に組み込めることを確認しました。2025 年 10 月に Quick を提供開始して以来、DuckDB との統合と最適化を組み込んだ独自の Quick クエリエンジンで 25 億件を超えるクエリを処理してきました。DuckDB との統合と最適化により、Amazon Quick は平均クエリレイテンシーを 30% 削減できました。データと分析領域の他の AWS サービスでも、DuckDB のパフォーマンスとシンプルさをどのように取り込めるかを検討していきます。 DuckLabs と AWS が、アプリケーション、データエンジニア、AI のためにデータの最前線をどう再定義していくのか、そしてお客様の現状に寄り添いながら AWS の中で DuckDB のイノベーションの恩恵をどのように届けていくのか。続報にご期待ください。 著者について Mai-Lan Tomsen Bukovec AWS の Technology Vice President である Mai-Lan Tomsen Bukovec は、デジタル変革、ビジネス分析、機械学習、生成 AI、次世代のカスタマーエクスペリエンスにおいて数百万人の AWS のお客様が信頼を寄せる Amazon のクラウドデータサービスを率いています。テクノロジー業界で 25 年以上の経験を持ち、クラウド技術を活用してビジネスを変革するお客様の取り組みを支援するパイオニアです。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

はじめに 7 月は AWS オブザーバビリティにとってアップデートの多い月となりました。すでに収集しているテレメトリをより実用的なものにし、その収集にかかる運用作業を AWS 側で引き受ける機能をリリースしました。ログ分析は、ログクエリから直接実行できるアラームと、取り込み時に行われるエンリッチメントによって、アクションに繋げやすくなりました。アプリケーションレベルのオブザーバビリティは、エラーとデプロイイベントを自動的に捕捉するようになりました。AI コーディングエージェントの可視化が、新しいオブザーバビリティのカテゴリとして登場しました。Prometheus メトリクスのスクレイピングのために自前で運用していたエージェントは、マネージドコレクションによって不要になりました。そしてこれらすべてを支える基盤として、OpenTelemetry と Prometheus が引き続き中核的な役割を果たしています。 Amazon CloudWatch 、 Amazon Managed Service for Prometheus 、 Amazon Managed Grafana 、 AWS DevOps Agent の最新情報をご紹介します。 これらのリリースのライブデモをご覧になりたい方は、9 月 16 日開催の「 I didn’t know Amazon CloudWatch could do that! 」ウェビナーにご登録ください。過去のまとめを見逃した方は、「 今月の AWS オブザーバビリティ 」の 2026 年 1 月〜5 月 および 2026 年 6 月 のブログをご覧ください。 ログ分析: クエリからアクションへ 7月のテーマとして最も分かりやすいのは、ログクエリと、そこから起こすアクションに繋げやすくすることでした。 CloudWatch Logs のクエリから直接アラームを作成 できるようになりました。クエリを記述してしきい値を設定すれば、エラーが急増したときに周辺のログコンテキストとともにアラートを受け取れます。これら一連の操作が 1 つのワークフローで完結します。メトリクスフィルターやカスタムメトリクスを事前に作成する中間ステップは不要になりました。ログアラームは、Amazon Simple Notification Service や Amazon EventBridge を含む、すでに利用している標準的なアラームアクションをサポートしているため、他の CloudWatch アラームと同じ通知・自動化の経路にルーティングできます。 新しい ログエンリッチメント用の lookup プロセッサ は、アップロード済みの CSV のルックアップテーブルとログイベントのフィールドを照合することで取り込み時にコンテキストを追加します。カスタムのエンリッチメントロジックを書かなくても、IP アドレスから担当チームへ、エラーコードから人が分かりいやすい説明文へ、ユーザー ID からアカウントのメタデータへ、といったマッピングができます。エンリッチメントはデータの到着時に行われるため、クエリ、ダッシュボード、アラームのすべてが追加されたフィールドの恩恵を直ちに受けられます。 CloudWatch Logs が、 Application Load Balancer のログを Vended Logs (AWS のサービスが発行するログ) としてサポート するようになりました。Application Load Balancer のアクセスログ、接続ログ、ヘルスチェックログが CloudWatch Logs に直接ストリーミングされ、Logs Insights でのクエリ、メトリクスフィルターの作成、Live Tail によるリアルタイム監視が可能になります。テレメトリ有効化ルールにより、組織内の既存および新規のロードバランサーに対してロギングが自動構成されるため、1 つずつ手作業で設定する必要はありません。 CloudWatch Logs Insights には、7 月に 25 個の新しいクエリコマンドと関数 が追加されました。統計関数、セッション化 (sessionization)、外れ値検出、NULL 処理などが含まれます。これらにより、結果を別の場所で後処理するのではなく、クエリ言語の中でより多くの分析を直接実行できます。 コスト効率の良いログストレージ ログを 1 か所に集めるほど、ストレージコストが課題になります。7 月はこの点にも対応しました。 CloudWatch Logs Intelligent Tiering は、直近のアクセス状況に基づいて、ログデータを Standard、Infrequent Access、Archive Instant Access の 3 つの階層に分類します。30 日間アクセスされていないデータは Infrequent Access に移動し、90 日間アクセスされていないデータは Archive Instant Access に移動します。古いデータをクエリすると、自動的に Standard に戻ります。クエリの操作感は 3 つの階層すべてで同じであるため、チームの運用を変えることなくストレージコストを削減できます。有効化はアカウントレベルで行います。 アプリケーションのオブザーバビリティ Application Signals が、計装済みのサービスから エラー、パフォーマンス異常、デプロイイベントを自動的に捕捉 するようになりました。追加のコード変更は不要です。例外とレイテンシーのイベントスナップショット、関数レベルのパフォーマンスデータ、デプロイイベントを記録します。そのため、何か変化が起きたときには Errors ビューを直接開き、最近のデプロイが新しい例外を引き起こしたかどうかを確認できます。この機能は、AWS Distro for OpenTelemetry SDK、または Amazon Elastic Kubernetes Service (Amazon EKS) 用の CloudWatch Observability アドオンで計装された Java、Python、JavaScript のサービスでサポートされます。イベントはログとして、関数メトリクスは OpenTelemetry メトリクスとして配信されるため、既存のオブザーバビリティデータとまとめて扱えます。 AI コーディングエージェントのオブザーバビリティ Coding Agent Insights は、AI コーディングツールが組織全体でどのように価値を生み出しているかを、エンジニアリングリーダーが把握できるようにします。Claude Code、Codex、GitHub Copilot と統合され、追加の計装なしで OpenTelemetry メトリクスを収集します。データは既存の CloudWatch の運用ビュー上に表示されます。支出のトレンドを追跡し、トークン課金のアラートを設定し、エージェントの導入状況をコミットのスループットやプルリクエストの速度と突き合わせ、どのモデルが最も優れたコスト対アウトプット比を実現しているかを特定できます。コーディングエージェントを大規模に導入していくチームにとって、リターンを推測ではなく計測する手段となります。 OpenTelemetry とマネージドコレクション Managed Prometheus collectors は、エージェントのデプロイや保守なしに、Prometheus メトリクスをフルマネージドで収集します。スクレイプ設定を用意すれば、プロビジョニング、スケーリング、収集は CloudWatch が処理します。エージェントを一切デプロイ・管理することなく、Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、Amazon OpenSearch Service のワークロードの監視を有効化できます。メトリクスは OpenTelemetry 形式で配信され、AWS Vended メトリクス (AWS のサービスが発行するメトリクス) とともに PromQL でクエリできます。 AWS Cloud Operations Blog の関連記事 (2026 年 7 月) 2026 年 7 月に AWS Cloud Operations Blog で公開された記事は以下のとおりです。 Getting per-resource alarm notifications with Amazon CloudWatch &nbsp; – Himanshu Dewan, Ashish Kumar, Radheshyam Baliga Bantwal Autonomous Root Cause Analysis for AWS Systems Manager Patch Failures Using AWS DevOps Agent &nbsp; – Rizwan Mohammed, Samir Behara, Shanmukha Jaya Harsha Alluri, Vinod Kisanagaram Build bespoke operational workflows with AWS DevOps Agent custom SRE agents &nbsp; – Harish Mandhadi, Brent Everman, Joe Alioto, Janardhan Molumuri Automate CI/CD troubleshooting with AWS DevOps Agent and GitHub &nbsp; – Purushotham G K, Abhishek Taparia Extend Amazon CloudWatch Beyond Native Connectors with Cribl Stream &nbsp; – Gabriel Costa, Kishore Vinjam How Amazon Achieved Full Stack Observability Across 400 Offices with Amazon OpenSearch Serverless &nbsp; – Shivansh Singh, Arijit Chakravorty, Bishr Tabbaa, Leonardo Quintero Deploy OpenTelemetry Gateway on AWS: Monitoring Your Observability Pipeline&nbsp; – Ankita Saxena, Jyothi Madanlal Amazon CloudWatch アラームをアクション可能なシグナルに変える &nbsp; – Helen Ashton, Gagandeep Singh Using Amazon S3 Server Access Logs with Amazon CloudWatch Logs &nbsp; – Isaiah Salinas, Erik Weber まとめ 7 月のリリースによって、ログ分析はクエリとアクションのギャップを埋め、ストレージの階層化はデータ保持コストを抑えやすくしました。さらに、アプリケーションのオブザーバビリティは追加のコードなしで重要なイベントを捕捉し、AI コーディングエージェントは計測可能になり、マネージドコレクションはエージェント運用の負担を取り除きました。これらはすべて OpenTelemetry と Prometheus の基盤の上に構築されています。 これらの機能を使い始めるには、以下を実施してください。 CloudWatch コンソール で、ログクエリから直接アラームを作成する。 CloudWatch Pipelines で 取り込み時にログをエンリッチするルックアップテーブル をアップロードする。 エラーとデプロイの自動捕捉のために、Application Signals のサービスイベントを有効にする。 Coding Agent Insights にデータを取り込むために、 Claude apps gateway のテレメトリを設定する 。 自己管理型のコレクターを マネージド Prometheus コレクター に置き換える。 テレメトリ有効化ルールを使って、 Application Load Balancer のログ を CloudWatch Logs にストリーミングする。 ストレージコストを自動的に削減するために、ログアカウントで CloudWatch Logs Intelligent Tiering を有効にする。 最近のリリースの一覧については、Amazon CloudWatch で絞り込んだ AWS What’s New ページ をご覧ください。 さらに詳しく知りたい方へ 9 月 16 日開催の「 I Didn’t Know Amazon CloudWatch Could Do That 」ウェビナーにご参加ください。これらの新機能の実際の動作をご覧いただき、トラブルシューティングの迅速化にお役立てください。 著者について Dot Ho Dot は AWS オブザーバビリティのシニアテクニカルプロダクトマーケティングマネージャーです。WCA (World Cube Association) の 3×3 マルチブラインド (目隠しで複数のキューブを解く種目) の記録向上に向けて練習中です。 Erik Weber Erik Weber は AWS Cloud Operations サービスのシニアワールドワイドスペシャリストソリューションアーキテクトです。AWS Systems Manager、AWS Config、AWS CloudTrail、AWS Audit Manager を専門としています。仕事以外では、ハイキング、料理、サイクリングを愛好しています。 Kevin Lewin Kevin は Amazon Web Services のクラウドオペレーションスペシャリストソリューションアーキテクトです。オブザーバビリティと自動化を通じて、お客様が運用目標を達成できるよう支援することに注力しています。 本ブログは 2026 年 8 月 18 日に公開された This Month in AWS Observability: July 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

このブログ記事は、AWS ソリューションアーキテクトの多田慎也が執筆し、株式会社MonotaRO が監修しています。 はじめに 株式会社MonotaRO （モノタロウ）は、工具、部品、消耗品をはじめとする間接資材のインターネット通販を展開し、連結売上高 3,338 億円（2025 年 12 月期）、登録ユーザー数 1,100 万以上、取扱商品点数 2,800 万点以上を誇る事業者向け EC プラットフォームです。同社はこのたび、事業の根幹を支える基幹データベースをオンプレミスの MySQL から Amazon Aurora MySQL（以下、Aurora MySQL）へ移行し、 Amazon Aurora Global Database （以下、Aurora Global Database）によるマルチリージョン DR 構成とフルマネージド運用を実現しました。本ブログでは、移行の背景と課題、選定理由、移行アプローチ、そして得られた成果についてご紹介します。 背景と課題 MonotaRO の基幹データベースは、日々の受発注処理をはじめとする事業のコアシステムとして、大量のクエリを処理しています。同社はクラウド活用を推進してきましたが、基幹データベースがオンプレミスに残っていること、そしてその基盤となる MySQL 環境そのものに、複数の領域で課題を抱えていました。 オンプレミスの基幹データベースがクラウド移行のボトルネックに 基幹アプリケーションやバッチ処理は、基幹データベースに対して大量のクエリを発行しています。アプリケーションとデータベースの間にネットワーク遅延が入ると処理時間が大きく伸びるため、データベースがオンプレミスにある限り、関連するアプリケーション群もオンプレミスに残らざるを得ない状況でした。これにより、クラウドネイティブな開発基盤への移行が制約されていました。 さらに、基幹データベースは事業の広範な領域と密結合しており、ひとたび障害が発生すると、基幹業務のドメイン同士にとどまらず、EC サイトや周辺業務にまで影響が波及する構造でした。この「基幹データベースがオンプレにあるためにアプリもクラウドに移せない」「密結合ゆえに障害影響が広い」という課題は、多くの企業が直面する共通の課題です。 レプリケーション遅延の変動 オンプレミス環境では、プライマリとリードレプリカ間の論理レプリケーション遅延が処理内容によって変動し、状況によっては十数分規模に達することもありました。この遅延により、データ鮮度が求められる処理ではリードレプリカではなくプライマリを参照せざるを得ないケースが生じ、プライマリへの負荷増大を招く要因にもなっていました。 MySQL 保守期限への対応 基幹データベースは旧バージョンの MySQL で稼働しており、保守期限が迫っていました。セキュリティパッチの提供終了リスクへの対処が急務となっていました。 18 台レプリカのセルフマネージド運用負荷 参照負荷に対応するため 18 台のリードレプリカを運用していましたが、すべてセルフマネージドでした。スケールアップ/ダウン作業やメンテナンス対応など、多くの時間が割かれていました。 マネージドなマルチリージョン DR の不在 従来も障害時の復旧手段は備えていましたが、いずれも手動運用を前提としたセルフマネージドな構成であり、マネージドかつ自動化されたマルチリージョン DR は実現できていませんでした。事業の成長に伴い、リージョン障害にも耐えうる DR を、運用負荷を抑えたマネージドな形で整備し、事業継続性をさらに強化することが求められていました。 こうした課題に対し、Aurora の I/O 性能やストレージレベルレプリケーション機能の向上、大阪リージョンの活用によるレイテンシー面の改善、これまでの MySQL 移行で培った移行の練度といった追い風もあり、Aurora への移行が有力な選択肢として本格的に検討されました。 Aurora MySQL 選定の理由 MonotaRO が Aurora MySQL を選定した理由は、以下の 4 点に集約されます。 ストレージレベルレプリケーションによる遅延の根本解消 Aurora はストレージレベルでレプリケーションを行うため、従来の論理レプリケーションで発生していた変動の大きい遅延を根本的に解消できます。リーダー（Reader）は通常ミリ秒オーダーの遅延でライター（Writer）と同期されます。 MySQL 8.0 互換によるアプリケーション改修の最小化と EOSL 解消 Aurora MySQL は MySQL 8.0 互換であり、既存アプリケーションからの接続方法や SQL 構文の互換性が高いため、アプリケーション改修を最小限に抑えながらバージョンアップを実現できます。これにより、保守期限の問題もクラウド移行と同時に解決されます。 フルマネージドによる運用負荷削減と TCO 最適化 Aurora のマネージドサービスとしての特性により、18 台のセルフマネージドレプリカの運用負荷を大幅に削減できます。リージョン内でのインスタンス障害時の自動フェイルオーバー、自動バックアップ、パッチ適用など、従来手動で行っていた運用作業が自動化されます。さらに、ハードウェアの保守・更改やデータセンター運用が不要になり、必要な性能に応じてキャパシティを柔軟に調整できるため、運用工数まで含めた総所有コスト（TCO）の最適化にもつながります。 Aurora Global Database によるリージョンレベルの DR Aurora Global Database を採用することで、大阪リージョンをプライマリ、東京リージョンをセカンダリとするマルチリージョン構成を実現し、リージョンレベルの障害にも対応可能な DR 構成を構築できます。セカンダリリージョンへのレプリケーションは専用のストレージレベル基盤を通じて行われ、通常 1 秒未満の遅延で同期されます。リージョンレベルの切り替えは、スイッチオーバー（計画的な切り替え）や手動フェイルオーバーにより、迅速かつ制御された形で実施できます。 移行アプローチと技術的ポイント PoC による性能・信頼性の検証 MonotaRO の開発チームが主導し、約 4 ヶ月間の PoC（Proof of Concept）を実施しました。インフラストラクチャ観点での性能検証やフェイルオーバー動作の確認に加え、アプリケーションの動作検証も行い、本番ワークロードに耐えうることを確認した上で、Aurora MySQL の採用を正式に決定しています。 中継機を用いたレプリケーションでのデータ移行 MySQL のレプリケーションは隣接するメジャーバージョン間でのみサポートされるため、MySQL 5.6 から複数のメジャーバージョンをまたいで Aurora MySQL 3 系（MySQL 8.0 互換）へ直接レプリケーションすることはできません。そこで、MySQL 5.7 の中継用インスタンス（中継機）を挟み、「MySQL 5.6 →（中継機）MySQL 5.7 → Aurora MySQL 3 系」の順でバージョンを 1 段ずつ引き上げながらレプリケーションすることで、オンプレミスから Aurora へ安定してデータを同期しました（図 1）。 (図1: 中継機を用いた段階的レプリケーションによるデータ移行) 参照系から更新系への段階的な切り替え 移行はビッグバン的に一度で切り替えるのではなく、段階的なアプローチを採用しました。まず影響範囲の小さい参照系（Read）のアプリケーションから先に新しいデータベースのリーダーへ接続を切り替え、最後に更新系（Write）のアプリケーションを切り替えました。小さな単位で少しずつ切り替えることで、各段階で動作を検証しながら問題の早期発見と切り戻しを可能にし、ミッションクリティカルなシステムの移行リスクを最小化しました。 AWS Countdown Premium の活用 さらに MonotaRO は、こうした移行を確実に進めるため AWS Countdown Premium を活用しました。同社には過去にオンプレミスから Aurora へのデータベース移行経験がありましたが、今回は過去に対応したことのない規模であり、かつミッションクリティカルなシステムであることから、AWS の専門家による支援を組み合わせる判断をしました。 MonotaRO が AWS Countdown Premium の活用を通じて得た価値は、以下の通りです。 専門家レビューによるリスクの事前特定 : リソースレビューを通じて、現時点では顕在化していないものの、将来のスケールや運用の中で課題となり得る設計上のポイントを洗い出し、先回りして対処 インフラメトリクスの立ち合いレビュー : 移行前後のメトリクスを専門家がリアルタイムで確認し、開発チームと専門家の直接コミュニケーションにより、開発チームの安心感を醸成 包括的な視点でのアドバイス : データベースだけでなく、データベースに関連するネットワークや運用面も考慮した総合的なアドバイスを提供 以上のように、開発チーム主導の PoC による検証、参照系から更新系への段階的な切り替え、中継機を用いた安定したデータ移行、そして AWS Countdown Premium による専門家支援を組み合わせた結果、移行は計画メンテナンスの範囲内で実施され、予期しないサービス影響を出すことなく完了しました。 構成と成果 最終構成 移行後の構成は、Aurora Global Database を中核としたマルチリージョン構成です（図 2 参照）。 プライマリリージョン : 大阪リージョン セカンダリリージョン : 東京リージョン (図2: Aurora Global Database 構成図 ) 定量成果 指標 Before （オンプレミス MySQL） After （Aurora / Aurora Global Database） レプリケーション遅延 （DB 内リーダー同期） 処理内容により変動（状況により十数分規模） 通常 100 ミリ秒未満 ※1 運用対象レプリカ 18 台セルフマネージド フルマネージド DR 構成 手動運用のセルフマネージド構成 マネージドなマルチリージョン Global Database リージョン内フェイルオーバー （ライター障害）RTO 手動・約 2 時間 自動・1 分未満 ※2 ※1 本表のレプリケーション遅延は Aurora クラスター内のリーダー参照における値で、通常ミリ秒オーダー（多くの場合 100 ミリ秒未満）です。一方、Aurora Global Database によるクロスリージョンのレプリケーションは通常 1 秒未満です。なお、Aurora から下流のオンプレミス連携先へのデータ連携は、従来と同様の方式で行われます。 ※2 リージョン内フェイルオーバーは、障害の自動検知と自動フェイルオーバーによって実行されます。一般的な復旧時間は 60 秒未満（多くの場合 30 秒未満）であり、本記事では保守的に「1 分未満」と記載しています。 障害時の可用性向上と機会損失の削減 今回の移行で最も大きな効果は、 基幹データベース障害時の事業影響（機会損失）を大幅に削減できる 点です。 ライター（Writer）のダウン（AZ 障害）時の RTO は、従来の手動切り替えで約 2 時間を要していたところ、Aurora 化により自動フェイルオーバーで 1 分未満 に短縮されました。障害からの復旧時間が大幅に短縮されることで、ダウンタイムに伴う機会損失を削減できます。 リージョン障害時にも、Aurora Global Database のセカンダリリージョンへの昇格により、マネージドなクロスリージョン DR を実現しました。従来は手動運用を前提としたセルフマネージドな復旧構成であったのに対し、マネージド化・自動化されたことで運用負荷を抑えつつ、プライマリリージョンの復旧を待たずにサイトの注文受付を再開できます。 セキュリティ・運用面の向上 Aurora は AWS のマネージドサービスであり、ホスト OS への直接アクセスを前提としない運用となるため、実行環境に対する不正アクセスや改竄のリスクを低減できます。あわせて、パッチ適用やバックアップといった運用作業がマネージド化されることで、運用チームはより付加価値の高い業務に注力できるようになりました。 お客様の声 「当社はかねてより全社的なシステムのモダナイゼーションを進めてきましたが、その最大のボトルネックの１つであったオンプレの基幹データベースを Amazon Aurora 上へ移行させることができました。参照系から更新系へと段階的に切り替えることでリスクを下げ、業務影響を最小限にとどめながら安全にコントロールされた移行を実現できました。AWS様の的確なサポートにも大変助けられました。今回の移行は MySQL 8.0 へのバージョンアップを兼ねており、多数のリードレプリカに対するレプリケーション遅延の解消に加え、Instant DDL や Blue/Green Deployments によりスキーマ変更をかけにくいという長年の課題も解消。これによりデータ構造のリファクタリングが容易になりました。またクローン機能により検証用データベースも即時に用意できるようになり開発環境の自動化を加速できます。さらに CloudWatch Database Insights によるクエリパフォーマンスの可視化と改善サイクルを早くまわせる仕組みを導入準備中です。今後もモダナイゼーションを進めることでシステムの変更容易性を獲得し、当社の競争優位をさらに強固なものにしてまいります。」 — 株式会社MonotaRO 常務執行役 ソフトウェア本部長 普川氏 「オンプレミス環境の稼働メトリクスや全クエリを生成 AI も活用して事前に分析し、移行後に問題となり得る箇所を洗い出したうえで、参照系から更新系へと段階的に切り替えていきました。ミッションクリティカルなシステムでありながら、計画メンテナンスの範囲内で移行を完了できています。現在は、稼働状況をもとに Amazon Bedrock で改善案を生成し、プルリクエストとして開発チームへ提案する仕組みに加え、今後のバージョンアップに備えて現行バージョンと次期バージョンの挙動を突き合わせ、同様にプルリクエストとして提案する仕組みの構築を進めており、Aurora への移行はその土台となりました。」 — 株式会社MonotaRO ソフトウェア本部 コアシステムエンジニアリング部門 基幹モダナイゼーショングループ 石田氏（本プロジェクト PM） 「オンプレミスでは、データベース運用の多くが手作業であること、レプリケーション遅延が各システムに影響すること、データベースがオンプレミスにあるためアプリケーションもクラウドへ移せないことなど、長年にわたり様々な課題がありました。Aurora MySQL への移行でその多くに解決の見通しが立ち、システム設計と運用の自由度が大きく広がりました。」 — 株式会社MonotaRO ソフトウェア本部 プラットフォームエンジニアリング部門 サービスインフラグループ 中島氏（インフラ担当） 今後の展望 MonotaRO は以前からクラウド活用やモダナイゼーションを進めてきましたが、基幹データベースはオンプレミスに残り、関連するアプリケーション群のクラウド移行を妨げる要因となっていました。今回の移行によってこの制約が解消され、モダナイゼーションをさらに加速できる状態になりました。 基幹システムのモダナイゼーション加速 : これまで基幹データベースがオンプレミスに存在していたことで制約されていた関連アプリケーション群のクラウド移行が可能になりました。今後はクラウドネイティブ化（コンテナ基盤への移行）を進め、開発者が新サービス開発や事業成長に直結する業務により集中できる環境の実現を目指します。 リーダーへの読み取り振り分けによる負荷分散 : レプリケーション遅延が解消されたことで、これまでデータ鮮度の都合でライター（Writer）に向けざるを得なかった読み取り処理も、リーダー（Reader）へ振り分けられるようになります。ライターの負荷を軽減し、読み取りのスケールアウトを進める土台が整いました。 メンテナンス運用の最適化 : Aurora MySQL の Blue/Green Deployments を活用することで、メジャーバージョンアップやスキーマ変更といった計画メンテナンスを、ダウンタイムを最小化して実施できます。Blue/Green Deployments では、本番環境の複製（グリーン環境）で事前に変更を検証したうえで、通常 1 分未満・データ損失なしで切り替えが可能です。 継続的な運用改善 : Aurora が提供する CloudWatch Database Insights や Enhanced Monitoring などの機能を活用し、継続的な運用改善に取り組んでいます。 まとめ MonotaRO は、基幹データベースをオンプレミス MySQL から Aurora Global Database に移行し、レプリケーション遅延の根本解消、マルチリージョン DR の実現、18 台のセルフマネージドレプリカからフルマネージド運用への転換を達成しました。加えて、障害時の RTO 短縮により、障害時の事業影響（機会損失）を大幅に削減できる見込みです。この移行は、単なるデータベースの載せ替えではなく、クラウドネイティブな開発基盤への移行を加速させる重要な一歩です。