2026 年 8 月 21 日、 AWS Glue 6.0 の一般提供について発表しました。これにより、価格が以前の AWS Glue バージョンよりも 30% 低くなり、 Apache Iceberg v3 の機能が完全にサポートされるようになりました。AWS Glue 6.0 は、完全に近代化されたランタイム、Apache Spark 4.1、Python 3.12、および Scala 2.13 に基づいて構築されており、より高速なパフォーマンスを実現しています。 このリリースにより、AWS Glue は、完全にサーバーレスのマネージド型の Spark サービスで最も完全な Iceberg v3 実装を実現するとともに、ETL オーサリングを簡素化し、 PySpark のパフォーマンスを向上させ、1桁ミリ秒のレイテンシーでリアルタイムストリーミングを可能にする新機能も提供します。 AWS Glue 6.0 の新機能は何ですか AWS Glue 6.0 は、Iceberg 1.11.0 をベースに構築された完全なApache Iceberg v3仕様を提供します。主な特長は、シュレッダ処理をサポートする VARIANT データ型です。これにより、半構造化データ用の従来の文字列データ型の列と比較して、クエリの読み取りパフォーマンスが向上します。 VARIANT  のシュレッディングを使用すると、スキーマをフラット化しないで JSON、ログ、イベントデータを保存してクエリできます。これにより、スキーマが変更されたときに重複するデータコピーやカスタム解析コード、パイプラインが破損することがなくなります。この機能により、チームが半構造化データの大規模処理の方法が変わります。 Iceberg v3 のその他の機能には以下が含まれます。 幾何学と地理データタイプ : GIS分析、ロケーションインテリジェンス、および地理空間データパイプラインのネイティブ空間処理をマネージド Spark で直接有効にします。 ナノ秒精度のタイムスタンプ : 標準ミリ秒を超える精度を必要とする IoT センサーデータ、科学計算、および高頻度の金融ワークロードをサポートします。 未知の型処理 : パイプラインに障害が発生することなく、予期しないスキーマや、進化するスキーマを含むデータを処理できるため、上流のスキーマ変更に対する回復力が高まります。 AWS Glue 6.0 には、最新のランタイムエンジンである Spark 4.1 の最も重要なアップグレードも含まれています。 Spark 宣言型パイプライン : Spark 宣言型パイプラインでは、ETLオーサリングへのシンプルなアプローチが導入されています。データエンジニアは変換を宣言してデータをどのように表示するかを指定し、エンジンは実行順序と最適化を自動的に決定します。これにより、パイプライン開発の複雑さが軽減され、手動によるオーケストレーションのオーバーヘッドがなくなります。 アローネイティブ Python UDF と UDTF : AWS Glue 6.0 では、Python ユーザー定義関数 (UDF) とユーザー定義テーブル関数 (UDTF) の Arrow ネイティブ実行が導入されました。これにより、Python と JVM 間のシリアル化のオーバーヘッドがなくなり、複雑な変換での PySpark のパフォーマンスが向上します。 リアルタイムストリーミングモード : AWS Glue 6.0 では、ステートレスストリーミングのユースケース向けに、1桁ミリ秒のレイテンシーを実現するリアルタイムストリーミングモードが導入されています。Glue に最適化された実行機能を備えた Spark 4.1 のリアルタイムモードに基づいて構築されたこの機能は、リアルタイムのイベント処理、低遅延のデータ変換パイプライン、および時間に敏感なデータルーティングをサポートします。 AWS Glue 6.0 の開始方法 AWS Glue 6.0 を使用するのに、API を変更する必要はありません。 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS Glue Studio 、 Amazon SageMaker Unified Studio 、および優先する IDE から create-job または update-job API で既存の --glue-version パラメーターを使って、新しいバージョンを選択することができます。 AWS Glue 6.0 ジョブを AWS Glue Studio コンソール で開始するには、[AWS Glueジョブ] を開き、 ジョブ詳細 タブで、バージョン Glue 6.0 – Spark 4.1、Scala 2、Python 3 をサポート を選択します。AWS Glue 6.0で新しい AWS Glue ジョブを作成することで、改善によるメリットを受けること、および既存の AWS Glue ジョブを移行することもできます。 AWS Glue 6.0 を AWS Glue Studio ノートブックで使用したり、Jupyter Notebook を介してインタラクティブセッションを開始したりするには、 %glue_version マジックで 6.0 を設定してください。 また、AWS Glue Studio の Spark アップグレードエージェント を使用して既存のジョブを Glue 6.0 にアップグレードしたり、既存の Glue ジョブの自動アップグレード機能を使用して自動的に Glue 6.0 にアップグレードしたりすることもできます。 詳細については、AWS ドキュメントの 「AWS Glue 6.0 バージョンの詳細」 および 「AWS Glue for Spark ジョブの AWS Glue バージョン 6.0 への移行」 を参照してください。 今すぐご利用いただけます AWS Glue 6.0 は現在、AWS Glue が運用されているすべての AWS リージョンで一般的に利用可能です。リージョンごとの提供状況や今後のロードマップについては、 リージョン別の AWS 提供機能 にアクセスしてください。API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 クローラー (データの検出) と抽出、変換、ロード (ETL) ジョブ (データの処理と読み込み) には、時間単位の料金を秒単位で請求します。AWS Glue データカタログの場合は、メタデータの保存とアクセスにシンプルな月額料金を支払う必要があります。最初の 100 万個のオブジェクトは無料で、最初の 100 万個のアクセスは無料です。詳細については、 AWS Glue 料金表ページ をご覧ください。 AWS Glue Studio コンソール でお試しいただいた後、 AWS re:Post for AWS Glue または通常の AWS サポート窓口までフィードバックをお寄せください。 – Channy 原文は こちら です。

本ブログは 2026 年 8 月 25 日現在の内容を基に記載しております。記載内容については今後変更される可能性があります。 こんにちは ! テクニカルインストラクターの室橋です。AWS クラウドの知識やスキルを証明する方法としての「 AWS 認定 」はご存知の方も多いかと思います。しかし、2025 年末より AWS Skill Builder に順次コースが追加されている「マイクロクレデンシャル」という新しいスキル証明については、まだご存じない方や、AWS 認定との違いがよくわからないという方もいらっしゃるかもしれません。 この記事では、マイクロクレデンシャルとは何か、AWS 認定との違い、そしてどう組み合わせて活用できるかをわかりやすく解説します。 マイクロクレデンシャルって何 ? マイクロクレデンシャルとは、 AWS Skill Builder 上で取得できる、特定の技術領域に特化した実践スキルの証明 です。 AWS 認定が広い範囲の知識とスキルを体系的に問うのに対し、 マイクロクレデンシャルは「その技術を実際に使えるか」にフォーカスしています。 ハンズオンラボを使用した実践的な評価を通じて、 特定のサービスや技術を「知っている」だけでなく「使える」ことを証明できます。 現在提供されているマイクロクレデンシャルの例を挙げると、以下のようなものがあります。 AWS データレイクハウスの実証 (2026 年 7 月末に新規追加) : AWS Glue ETL インジェスト、Apache Iceberg テーブルの最適化、AWS Lake Formation ガバナンスのトラブルシューティングを行い、故障した E コマースレイクハウスプラットフォームを診断して修正します。Amazon Athena、AWS Glue、Apache Iceberg、Amazon EventBridge、AWS Lake Formation、Amazon Data Firehose を含むデータ分析サービスの習熟度を実証する必要があります。 AWS データストリーミングの実証 (2026 年 7 月末に新規追加) :リアルタイムインジェスト、イベントストリーミング、ストリーム処理、データ配信パイプライン、ポイズンピル処理、スキーマ駆動型フォーマット変換のトラブルシューティングを行い、故障したヘルスケアストリーミングインフラストラクチャを診断して修正します。Amazon Kinesis Data Streams、Amazon MSK、Amazon Data Firehose、Amazon Managed Service for Apache Flink、AWS Glue を含むデータ分析サービスの習熟度を実証する必要があります。 AWS データビジュアライゼーションの実証 (2026 年 7 月末に新規追加) : 機械学習を活用した予測の設定、行レベルおよび列レベルのセキュリティの実装、再利用可能な SQL ビューの構築、テーブル計算と条件付き書式を含むダッシュボードの公開を行い、ストリーミングプラットフォームの分析レイヤーを構築します。Amazon QuickSight、Amazon Athena、Amazon Redshift Serverless、AWS Glue Data Catalog を含むデータ分析サービスの習熟度を実証する必要があります。 AWS MLOps の実証 (2026 年 5 月末に新規追加) : Amazon SageMaker AI、Amazon Elastic Container Registry、Amazon API Gateway、AWS Lambda、Amazon CloudWatch を含む機械学習サービスの習熟度を実証する必要があります。 AWS エージェンティック AI の実証 (2026 年 5 月末に内容更新) : Amazon Bedrock AgentCore、Amazon Bedrock Guardrails、Amazon Cognito、AWS Lambda、Amazon OpenSearch Service を含むエージェンティック AI サービスの習熟度を実証する必要があります。 AWS アプリケーションネットワークの実証 : Elastic Load Balancing、Amazon VPC Lattice、Amazon API Gateway、Amazon CloudFront、Amazon Elastic Container Service (Amazon ECS) を含むネットワーキングサービスの習熟度を実証する必要があります。 AWS インシデント対応の実証 : AWS CloudTrail、AWS Identity and Access Management、Amazon EC2、Amazon S3、Amazon RDS、AWS Config を含むセキュリティサービスの習熟度を実証する必要があります。 AWS サーバーレスの実証 : Amazon CloudFront、AWS CodeBuild、AWS CodePipeline、Amazon DynamoDB、AWS Lambda、Amazon Simple Storage Service、Amazon Simple Notification Service、Amazon Simple Queue Service、AWS Step Functions、AWS WAF を含むサーバーレスサービスの習熟度を実証する必要があります。 いずれも、特定のユースケースや技術領域に絞り込んだ内容になっているのが特徴です。 注意 : 各マイクロクレデンシャルには制限時間が設けられており、 途中で中断することはできません。 開始する前に、まとまった時間をしっかり確保してから取り組んでください。また、不合格になった場合は再受験までに 25 日間 の間隔を空ける必要があります。 十分に準備を整えてから臨むようにしましょう。 なお、本番に取り組む前に、 AWS マイクロクレデンシャル – お試し版  で動作環境や出題の雰囲気をあらかじめ確認することができます。初めて挑戦する方はまずこちらから試してみることをおすすめします。お試し版にも少しハードルを感じる場合は AWS のテクニカルインストラクターがマイクロクレデンシャルについて紹介している  無料の動画コース で雰囲気をつかんでいただくのも良いでしょう。 マイクロクレデンシャルのもう一つの大きな魅力は、 AWS Skill Builder から無料で挑戦できる 点です。リリース当初は有料サブスクリプションが必要でしたが、現在は Skill Builder にアクセスさえできれば誰でも無料で挑戦できます。また、登場してまだ日が浅いコンテンツということもあるため、早い段階で取得すれば、実践スキルを持つエンジニアとして差別化を図れます。 さらに、マイクロクレデンシャルに合格すると Credly からデジタルバッジが発行 されます。LinkedIn などの SNS やプロフィールでシェアすることで、実践スキルをアピールする際に役立てることができます。 AWS 認定との違い マイクロクレデンシャルと AWS 認定は、どちらも「AWS のスキルを証明するもの」ですが、目的や評価の観点が異なります。 比較項目 AWS 認定 マイクロクレデンシャル 対象範囲 幅広いサービスと概念を網羅 特定の技術・ユースケースに特化 評価方法 選択式の試験 ハンズオンラボ・実践的な課題 証明できること 広範な知識やスキルを「理解、所持している」こと 特定スキルを「実際に使える」こと 学習範囲 幅広い学習が必要 特定領域に集中した利用や学習が必要 取得場所 AWS 認定試験会場 / オンライン試験 AWS Skill Builder 一言でまとめると、 AWS 認定は「知識の幅」、マイクロクレデンシャルは「スキルの深さ」を証明するもの と言えます。 こんな方におすすめ マイクロクレデンシャルは、 すでに AWS 認定 (Associate レベル以上) を保有している方が次のステップとして取り組むのに最適 です。 AWS 認定は幅広い知識やスキルを体系的に証明するものですが、「実際の現場でそのサービスを使いこなせるか」という実践面はカバーしていません。 Associate レベル以上の認定を持つ方は前提となる知識の土台がすでにあるため、マイクロクレデンシャルのハンズオン評価に取り組む準備ができている と言えます。 逆に、認定未取得の状態でマイクロクレデンシャルに挑戦すると、前提知識の不足から難易度が高く感じる可能性があります。まずは関連する AWS 認定の学習で知識の土台を固め、その上でマイクロクレデンシャルで実践スキルを証明するのが効率的な進め方です。 AWS 認定と関係性の深いマイクロクレデンシャルはこれ 各マイクロクレデンシャルは、特定の AWS 認定と内容的なつながりを持っています。関連する AWS 認定の学習をしながらマイクロクレデンシャルに取り組むと、理解がより深まります。 マイクロクレデンシャル 関連するAWS認定 AWS データレイクハウスの実証 DEA (Data Engineer – Associate) AWS データストリーミングの実証 DEA (Data Engineer – Associate) AWS データビジュアライゼーションの実証 DEA (Data Engineer – Associate) AWS MLOps の実証 MLA (Machine Learning Engineer – Associate) AWS エージェンティック AI の実証 ・DVA (Developer – Associate) ・MLA (Machine Learning Engineer – Associate) AWS アプリケーションネットワークの実証 ・SOA (CloudOps Engineer – Associate / 旧 SysOps Administrator – Associate) ・ANS (Advanced Networking – Specialty : 2026 年 12 月 31 日に試験終了) AWS インシデント対応の実証 ・SOA (CloudOps Engineer – Associate / 旧 SysOps Administrator – Associate) ・SCS (Security – Specialty) AWS サーバーレスの実証 DVA (Developer – Associate) たとえば、 AWS Certified Data Engineer – Associate (DEA) の取得を目指している方であれば、 データレイクハウス・データストリーミング・データビジュアライゼーション の 3 つのマイクロクレデンシャルがすべて関連しています。 認定試験の勉強と並行して取り組むことで、実践的なスキルも同時に身につけられるのではないでしょうか。 まとめ: 両方合わせることで「知識」と「スキル」の両方を証明できる AWS 認定とマイクロクレデンシャルは、それぞれ単独でも価値がありますが、 組み合わせることでより説得力のあるスキル証明 になります。 AWS 認定 : 「このサービス群を体系的に理解している」という広い知識・スキルの証明 マイクロクレデンシャル : 「この技術を実際の場面で使える」という実践的なスキルの証明 たとえば、AWS Certified Machine Learning Engineer – Associate (MLA) を持ちながら AWS MLOps Demonstrated も取得していれば、「機械学習の知識があり、MLOps の実践的な運用もできる」と示せます。採用担当者やプロジェクトのステークホルダーに対しても、より具体的な能力をアピールできます。   AWS 認定 マイクロクレデンシャル 強み 知識やスキルの幅・体系性 実践スキルの深さ 活用シーン キャリアの基盤づくり、転職・昇進のアピール 特定プロジェクトへのアサイン、専門性の強化 ぜひ、AWS 認定の学習を進めながら、関連するマイクロクレデンシャルにも取り組んでみてください。知識とスキルの両輪を揃えることで、AWS エンジニアとしての市場価値をさらに高めることができます。 まずは自分が目指している、もしくは所持している AWS 認定に対応するマイクロクレデンシャルから始めてみるのがおすすめです。 著者について 室橋 弘和 (Hirokazu Murohashi) AWS トレーニングサービス本部 Technical Instructor 兼 Customer Success Manager Cloud Quest とデカ盛りのお店巡りをこよなく愛するマン。老眼鏡が必要になってきました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 気づけば 8 月も残りわずかとなりました。朝晩には少しずつ秋の気配も感じられますね。今週は国内のお客様事例が豊作です。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、8 月 17 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「PKUTECH が Amazon Bedrock を活用して実現した AI-CSPM「Egeria-Security」のセキュアな設計」を公開 PKUTECH 様は、システムインテグレーション事業を展開し、生成 AI を活用した自社プロダクト開発に注力する企業です。従来の CSPM ツールには、チェックの根拠がブラックボックス化しやすく、カスタムルール作成のハードルが高いという課題がありました。AI-CSPM「Egeria-Security」は、自社のコンプライアンス文書を起点に Amazon Bedrock でスキャンポリシーを自動生成することでこれを解決しています。PoC では取り込んだ観点の約 50〜60% のポリシー自動生成を確認し、MVP 完成までの期間も想定 12〜18 ヶ月から約 4〜6 ヶ月に短縮されました。ハルシネーション対策や閉域推論など、機密データを扱う AI SaaS の設計判断も具体的に語られています。 AWS生成AI国内事例ブログ「株式会社日新 × AWS：人とAIが協働する新しい物流「オプティマAI」」を公開 株式会社日新様は、1938 年創業のグローバルな国際物流企業です。貿易書類の作成・照合や HS コード (税番) の判定に、多大な時間と専門知識を要する課題がありました。「人とAIの協働」をコンセプトに、Amazon Bedrock の RAG で税番候補を根拠付きで提示する「オプティマHS」と、AI-OCR で貿易書類を照合する「オプティマAI-OCR」を実用化しています。AI が候補を提示し人が最終判断する設計で、生産性向上とノウハウ継承を両立しました。将来は顧客と日新の AI 同士が MCP などで連携する、サプライチェーン全体の最適化を構想しています。 AWS生成AI国内事例ブログ「サンリオのエンジニア 6 名が 2 日間で体感した AI 駆動開発の可能性 — AI-DLC Unicorn Gym 座談会」を公開 サンリオ様のデジタル事業開発部と開催した、AI 駆動開発ライフサイクル (AI-DLC) 体験ワークショップのレポートと座談会記事です。2 チーム 6 名が Kiro を活用して実プロダクトを題材に全フェーズを体験し、inception 開始から本番マージまで約 5 時間で完了したストーリーもあります。AI との対話の結果「あえて実装しない」判断に至った話など、AI で実装が速くなるほど「何を作らないか」に価値が生まれるという気づきが印象的です。 AWS生成AI国内事例ブログ「Amazon Bedrock とロボティクスで目指す「未来の実験室」 ― AWS Summit Japan 2026 の Physical AI ―」を公開 コニカミノルタ様と共同執筆した、AWS Summit Japan 2026 での Physical AI 展示の解説記事です。「緑色を作ってください」という自然言語の指示を Amazon Bedrock 上の基盤モデルが構造化し、ロボットアームがフィルムを重ねて目標色に近づける閉ループ実験を紹介しています。LLM の役割を中間表現への変換に絞り、座標制御は決定論的な制御層に任せる設計で、軽量モデルでも安全性と速度を両立している点が読みどころです。 AWS生成AI国内事例ブログ「【開催報告】AWS Summit Japan 2026 レポート：SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX」を公開 AWS Summit Japan 2026 に出展された SUMCO 様のブース展示を共同で振り返る開催報告です。半導体ウェーハ製造のビッグデータを Amazon Redshift 中核の基盤に集約し、データ加工の仕組み「RedPulse」と、生成 AI で自然言語データ解析を行う「SynchroFabAI」により、組織全体のデータ活用の底上げを図る取り組みを紹介しています。厳しいセキュリティ要件下でデータと生成 AI の活用を検討する製造業の方におすすめです。 ブログ記事「AWS Bedrock LLM Day Japan【開催報告】」を公開 2026 年 7 月 28 日に東京で開催された「AWS Bedrock LLM Day Japan」の開催報告です。最新アップデートの紹介に加え、NEC 様 (Claude Cowork を 2 週間で 12 万人規模に本番展開)、丸紅様、ファストドクター様、リクルート様、jinjer 様の 5 社が本番運用の実践知を共有しました。生成 AI を PoC から本番へスケールさせるヒントが凝縮されています。 ブログ記事「AWS ジャパン地域創生支援プログラム（LEAP by AWS ジャパン）を発表 — 地域経済のAIトランスフォーメーションを包括支援」を公開 地域経済の AI トランスフォーメーションを包括支援する日本独自の新プログラム「LEAP by AWS ジャパン」が発表されました。地域企業の AI・クラウド活用支援 (条件を満たせば最大 5 万 US ドル相当の AWS クレジット)、地域 IT サービス企業のスキル強化、デジタル人材育成、地域データ活用支援の 4 つのメニューで構成されます。8 月 18 日から 28 日に全国 8 か所で開催される「デジタル社会実現ツアー」でも順次紹介されます。 ブログ記事「どの Kiro アプリを選べばいい？」を公開 Kiro は IDE、CLI、Web、Mobile、Kiro Crew という複数のアプリとして利用できます。本記事では、これらが単一のエージェントハーネスに接続する「玄関口」であることを解説し、用途に応じて使い分けるための判断フレームワークを紹介しています。どのアプリでも同じエージェントと設定が付いてくるので、Kiro をどこから触るか迷っている方はぜひご一読ください。 サービスアップデート Amazon Quick の Microsoft 365 拡張機能が一般提供開始 Excel、PowerPoint、Word、Outlook の中で Amazon Quick が直接タスクをこなす Microsoft 365 拡張機能が一般提供開始されました。ピボットテーブルの作成、組織テンプレートに沿ったスライド生成、変更履歴付きの文書編集、受信トレイの整理といった作業を、Quick が持つ業務データを踏まえて AI に任せられます。東京リージョンを含む 6 リージョンで利用可能です。 Amazon Quick がカスタム権限のデフォルト拒否に対応 Amazon Quick のカスタム権限に、新しい AI 機能をユーザーに届く前に自動で制限するガバナンス設定 Deny by default が追加されました。これまで新機能はリリースと同時に全ユーザーが利用可能になるため、管理者は事後の対応を迫られていました。カスタム権限プロファイルで AI 機能カテゴリを制限しておけば、以後の新機能はリリース時点で自動的に拒否され、管理者が準備できたものから個別に許可できます。詳細は こちらのドキュメント をご参照ください。 AWS Security Agent が予算コントロールと検出結果の再検証に対応 AI エージェントが Web アプリケーションの脆弱性を自律的にテストする AWS Security Agent (現在は AWS Continuum の一部) が、タスク時間の上限設定と検出結果の再検証に対応しました。テストは上限に達するとそれまでの検出結果を保持したまま停止するため、コストを予見しながらペネトレーションテストを実行できます。また修正のデプロイ後に特定の検出結果だけを再検証して解消済みかどうかの判定を得られるようになり、フルテストの再実行なしで修正確認が完結します。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock が OpenAI モデルの API サポートを拡大し Cross Region Inference を導入 OpenAI の GPT-5.6 (Sol、Terra、Luna) が bedrock-runtime エンドポイントに対応し、Responses、Chat Completions、Converse の各 API から利用できるようになりました。あわせて Global および Geo (US) の Cross Region Inference に対応し、容量管理なしで高いスループットと低いトークン単価を利用できます。ログやコスト配分を他のモデルと共通の仕組みで扱える点も嬉しい改善です。 Amazon Bedrock で OpenAI GPT-5.6 Sol の値下げを発表 Terra、Luna に続き、GPT-5.6 Sol の API 価格が引き下げられました。入力は 100 万トークンあたり 4 USD (20% の値下げ)、出力は 20 USD (33.3% の値下げ) となり、少なくとも 2026 年 11 月 21 日までこの価格が適用されます。エージェンティックコーディングに強いモデルを、大量トークンを消費するワークロードでも使いやすくなりました。 Amazon Bedrock が SpaceXAI Grok 4.6 をサポート コーディングやエージェントタスク向けのフロンティアモデル SpaceXAI Grok 4.6 が Amazon Bedrock で利用可能になりました。US Geo と Global の Cross Region Inference に対応し、データ処理を米国内に保ちながらのスケールと、需要ピーク時の高スループットを両立できます。 AgentCore payments が Amazon Bedrock AgentCore で一般提供開始 AI エージェントが有料の API、MCP サーバー、コンテンツを自律的に発見・支払いできる AgentCore payments が一般提供開始されました。Coinbase や Stripe Privy のウォレット統合、インフラレイヤーで強制される支払い上限、AgentCore Observability による可観測性を備え、「取引するエージェント」を本番で安全に運用できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore の Web Search がフィルタリング機能を追加、東京リージョンに拡大 AI エージェントの回答を最新の Web 情報でグラウンディングする AgentCore の Web Search Tool が、東京リージョンとアイルランドリージョンに拡大されました。あわせてツール呼び出しごとにドメインの許可/除外リストや公開日の期間を指定できるようになり、情報源と鮮度に統制が求められるエージェントを構築しやすくなりました。国内でエージェントを運用している方には待望のアップデートです。 Amazon SageMaker の生成 AI 推論レコメンデーションが SageMaker AI Studio で利用可能に 生成 AI モデルのデプロイに最適なインスタンスや最適化戦略を提案する Generative AI Inference Recommendations が、SageMaker AI Studio からノーコードで利用できるようになりました。ユースケースと最適化目標を選ぶだけで実 GPU 上のベンチマークが実行され、計測データ付きの推奨構成が返ります。数週間かかっていた構成探索を数時間に短縮でき、東京リージョンを含む 7 リージョンで利用可能です。 AWS Console-to-Code が対応サービスを 32 に拡大、クロスリージョン記録に対応 コンソール操作を記録して IaC コードに変換する Amazon Q Developer の Console-to-Code が、対応サービスを 6 から 32 へ拡大しました。リージョンやブラウザタブをまたいだ操作も 1 つのリストに統合して記録できるようになり、マルチリージョン構成も文脈を失わずにコード化できます。詳細は こちらのドキュメント をご参照ください。 Kiro の週次アップデート (Web の Okta / Microsoft Entra ID 対応、CLI 2.19 ほか) Kiro Web が Okta と Microsoft Entra ID によるサインインに対応し、既存の OIDC アプリケーションの設定追加だけでチーム利用を開始できるようになりました (Kiro Pro 以上)。Kiro CLI 2.19 では、スペックレビューのマウス操作対応と、接続断やスロットリングからの自動復旧が入り、長時間セッションの安定性が向上しています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

2026 年 6 月 12 日、TOPPAN 株式会社の皆さまを対象に、AWS のハンズオンワークショップ Accelerating Smart Product SDLC with AI Agent Workshop を開催しました。本ワークショップは AI エージェント Kiro CLI を使い、ソフトウェア開発ライフサイクル（SDLC）の主要フェーズを AI と協調しながら回す体験型のワークショップです。 生成 AI をソフトウェア開発の中で個別に取り入れる動きは広がってきました。一方で、要件定義からテスト、リリース、運用まで含めた SDLC 全体に AI をどう組み込むかは、多くの開発現場が模索しているテーマです。本ワークショップは、その問いに対して 1 つの具体的な進め方を示すものです。本記事では、TOPPAN 株式会社の皆さまが当日体験した内容と、現場のエンジニアとしてつかんだ手応えを、寄稿いただく形でお届けします。 ワークショップの位置づけ 最初に、本ワークショップについて アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト の三好から少しだけご紹介させていただきます。 スマートプロダクト開発と聞くと、ハードウェア寄りの特殊な世界に見えるかもしれません。しかし本ワークショップが提示するのは、ハード固有の話ではなく、 多くのソフトウェア開発に共通する SDLC（Research → Plan → Development → Release → Operation）に AI エージェントをどう組み込むか というテーマです。題材として、ビルや施設の空調機器を制御する HVAC（Heating, Ventilation, and Air Conditioning：冷暖房・換気・空調）コントロールシステムを用いていますが、そこで得られる学びは、業務システムでも Web アプリケーションでも、SaaS でも応用できます。 特別な開発手法を新たに導入するのではなく、今ある SDLC の各フェーズに AI エージェントを自然に溶け込ませる ── それが本ワークショップの狙いです。 ワークショップは SDLC の各フェーズに対応した複数のラボで構成されており、今回は半日で SDLC の流れを体感できるよう、Lab1（Research）、Lab2（Plan）、Lab4（Release）をピックアップして実施しました。Lab3（Development）と Lab5（Operation）も Workshop Studio のカタログページ で公開されているので、ご興味のある方はそちらでお試しいただけます。 AI エージェントとして使うのは Kiro CLI で、 人間が「何を作るか」「どう作るか」を判断し、AI が手を動かす ── この役割分担を徹底する形になっています。 それでは、お待たせしました。ここからは、ワークショップに参加された TOPPAN 株式会社 IoT ソリューション事業部 ICT 本部の加納・大石の両氏による寄稿です。当日のリアルな手応えを、どうぞお楽しみください！ ※※※　以下、TOPPAN 株式会社 IoT ソリューション事業部 ICT 本部 所属の 加納・大石 両氏による寄稿です。※※※ 参加の背景 TOPPAN 株式会社の 加納・大石 です。私たちの部門では、「自社プロダクトの企画・開発」「クライアントワーク」を中心に、ハードとソフトを組み合わせた、IoT ソリューション事業 を展開しています。 加納: 私は、受託事業から自社サービスまで、IoT ソリューションを中心としたさまざまな事業領域 で フルスタックエンジニアとして自社ソリューションや社内システムの設計・開発などを担当しています。バイブコーディングによる開発が浸透する中、開発時に AI へ与えるコンテキストや AI が生成するコンテキストが、各開発者のローカルに閉じてしまう点に課題を感じていました。その結果、開発で用いる AI の思想やアウトプットに開発者間のばらつきが生じ、引き継ぎが難しくなる場面も見てきました。そこで改めて、一人の開発者が AI を活用するフェーズから一歩進み、「チームとして AI を組み込んだ開発プロセスを確立すること」や「AI 開発の再現性」を課題として捉えるようになりました。 大石: 私は、主に自社プロダクトの開発領域 で 生成 AI を組み込んだ Web アプリケーション開発を担当している入社 2 年目のジュニアエンジニアです。近年、生成 AI を開発に取り入れる動きは社内でも広がっています。一方で、実装やテストを除く、要件定義や設計、運用といった他フェーズでの本格的な活用には十分に踏み込めていませんでした。入社して 1 年は、ひたすらコーディングで AI を使ってきましたが、2 年目になり最近では、「仕様駆動開発」の手法を取り入れ始め、AI エージェントをコーディング以外の開発プロセスへどのように組み込めるか考える機会が多くなりました。 こうした課題を抱える中で、AWS から本ワークショップの案内をいただきました。SDLC 全体に AI を組み込むという発想は、まさに私たちが模索していたテーマでした。AI との真の協調へとどう移行するか、その実感を得たいという思いで参加しました。 ワークショップの全体像 参加メンバーは 20 名、開発エンジニアとプロジェクトマネジメントをメイン業務とするメンバーを中心に構成され、各自が手元の Kiro CLI を操作しながら進めました。参加者をエンジニアに限定しない点には、こだわりがありました。プロジェクトを牽引しマネジメントする立場のメンバーにも、生成 AI を組み込んだ開発プロセスの概念理解に加え、マネジメント手法も併せてアップデートする必要があると考えたためです。 今回のワークショップの題材となる HVAC コントロールシステムは、温度センサーやアクチュエーターを持つ典型的な組み込みシステムですが、その内側にあるのは「要件があり、設計があり、実装・テスト・リリース・運用がある」という、ごく一般的なソフトウェア開発の構造です。だからこそ、ここで得られる体験は、私たちが普段手がけている開発にも素直に持ち帰れると感じました。 当日の体験：実施したラボの振り返り Lab1: Research ── レガシーコードを AI に読ませ、HTML モックで新 UI を高速試作 大石: 私は、最近になって AI を活用した開発の難しさを感じていました。プロンプトだけでは自分が想像しているものと AI が解釈したものにギャップが生じることが多く、実装後に画面を見てから「思ったのと違う」と気づき、そこからまた修正するというやり取りが発生していました。Lab1 では、実装に入る前に AI が HTML で画面イメージをサクッと作成し、認識をすり合わせながら実装に進める手法を体験し、これまで課題に感じていた実装後の手戻りを減らせると思いました。 レガシーコードの画面 AI を使って検討した画面 大石: AI 駆動開発に馴染みのないメンバーでも、開発における AI 活用の基本概念を学べました。さらにハンズオン形式だったことで、人間が思考しながら AI に実行させる、まさに AI 駆動開発のプロセスを実践的に体験できました。 Lab2: Plan ── 既存コードから設計書をリバースエンジニアリングし、次世代仕様へ 加納: GitLab での Issue 管理自体を Kiro に実施させることによって、人間側は要件の精緻化などに時間をかけることができ、かつ開発コンテキストを継続的に管理できると学びました。 加納: 生成 AI が登場した当初は、AI を活用した開発は新規プロジェクトと相性が良いイメージを受けた一方で、既存プロジェクトへの導入にはまだ課題が多いと感じていました。しかし今回の Lab2 を通じて、AI 駆動開発の進化に驚きました。特に現状システムの実態と、仕様変更や改修の積み重ねによって、システムの実態と設計書をはじめとしたドキュメント類の間にはギャップが生じやすい点を踏まえると、リバースエンジニアリングという視点はシステムとの整合性を高められ、実務でも効果的に活用できる可能性を感じました。 Lab4: Release ── AWS MCP Server を活用し、AI と CI/CD パイプラインを構築 大石: AWS CodeBuild や AWS CodePipeline に触れたことがなかったため、AWS の CI/CD のサービスを実際に扱えたのがまず良かったです。さらに、MCP と AI を活用して CI/CD パイプラインをスピーディーに構築できる点が非常に興味深かったです。 加納: 日々進化している AWS サービスに追従して CI/CD を構築するには、相応の知識が必要でした。ですが AWS MCP Server を使うことで、最新情報を AI に参照させながら進められ、手戻りを大幅に減らせると実感しました。さらに、エラーが出ても AI が内容を参照して修正できるため、設定完了までほぼ自律的に動作させることができました。 加納: Lab4 の体験は、私たちがいま課題としている「チームにおける AI を活用した開発手法の確立」に向けて、大きなヒントになりました。設計の背景や意思決定の理由を Issue に記録しながら進めることで、チームとして AI を活用した開発をどのように運用するかのイメージが一気に具体化しました。さらに、開発者が日頃利用しているコードツールやチケット管理ツールと連携しながら学べたことも、得られた気づきを現場で試しやすいと感じました。 学び ワークショップを通じて、私たちは特に以下の 3 点を持ち帰りました。 ① AI を組込み「速さ」と「再現性」を両立する秘訣は、プロセスと意思決定の透明化 ハンズオンを通じて、チケット管理ツールと連携した AI 駆動開発の体験では、チームとして AI を使いこなすことで、AI 開発の「再現性」がコード生成の速さ以上に恩恵をもたらしてくれると思いました。 直面している課題、「チームにおける AI を活用した開発手法の確立」に対して、設計の意図や AI とのやり取りを記録として残し、誰がどのように判断したのかをプロジェクト管理ツールと連携させながら運用していく SDLC は、これまでに発想がなかったアプローチだったため、非常に勉強になりました。身をもってそのプロセスを実践することができたため、一人のスキルに依存しないチームでの開発プロセスを具体的にイメージすることができました。 ② AI が真価を発揮するのは新規開発だけでない、リバースエンジニアリングで「生きた設計書」を実現する 長年更新されていない設計書や、複雑化した既存コードの解読は、多くの開発現場を悩ませる課題です。今回のハンズオンでは、現状のソースコードを AI に読み解かせ、ドキュメントとして再構築するリバースエンジニアリングの威力を目の当たりにしました。この使い方は、保守運用段階や途中参画のプロジェクトにおいて、チーム全体のシステム理解を飛躍的に高めます。常にシステムの全体像と整合性を把握できる状態を保つことができ、属人化を防ぎつつ保守運用を効率化する有効性は、新たな発見でした。 ③ ツールが進化しても変わらないもの、顧客の「信頼」を守るのはリスクと向き合う人間の姿勢 TOPPAN 内には、生成 AI を高度に活用して開発を進めるチームがいる一方で、活用の適用範囲や進め方を検討しているメンバーもおり、状況はさまざまです。プロジェクトの特性上、より堅牢なセキュリティ環境が求められ「このデータを AI に渡してよいか」という判断の迷いに直面することもしばしばです。こうした、セキュリティやガバナンス基準を整備し適切に管理された環境をつくることは、早急に対応すべきであることを実感しました。 どれほど AI が手軽で優秀になろうとも、最終的なデータの取り扱いやリスクを「判断」するのは人間にしかできない役割です。個人利用の枠を脱し、組織として AI を定着させるには、この「顧客の信頼を守る」という揺るぎない基準をチーム全体で確立し、運用する仕組みが最大の鍵となります。 これからの展望 今回得た手応えを踏まえ、社内の開発プロセスへ段階的に取り込んでいく予定です。これまで AI 駆動開発に馴染みのないメンバーは、まず AI エージェントを活用した業務プロセスを取り入れるところから着手します。そのうえで、個人の AI 活用から組織への仕組みへと発展させていきたいです。並行して、AI を活用した開発を実行していく人間のリテラシーが最も重要だと感じているため、教育にも力を入れていきたいです。 今回学んだ開発手法は、あくまで “AI エージェントによる開発手法の一例” と捉えています。そのため、弊社の中でも各開発現場ごとに合ったやり方を工夫していくことが必要と感じました。メンバーの成熟度などに応じて、どこまで厳格にルールを整備するかは試行錯誤する必要がありそうです。例えば、開発チームに新人メンバーがいる場合は、skills などで厳密なワークフローを提示することも検討しています。 AI エージェントによる開発は、開発速度、正確性の向上が期待できます。その効果をチームとして高めていくために、一人の開発者に閉じずに、コンテキストが共有できる、「チームにおける AI を活用した開発プロセス」を実際の案件にも適用していくことが中期的な目標です。 (寄稿ここまで) — 本ワークショップに興味を持たれた方は、 Accelerating Smart Product SDLC with AI Agent Workshop をご覧ください。ソフトウェア開発ライフサイクル（SDLC）の主要フェーズを AI と協調しながら回すワークショップを体験いただけます。 著者 TOPPAN 株式会社 加納 広太 TOPPAN 株式会社 IoT ソリューション事業部 ICT 本部・フルスタックエンジニア（フロント / バック / クラウドインフラ） 入社以来、自社ソリューションの開発・保守に従事。クラウドインフラを強みとしつつ、バックエンド／フロントエンドを含む Web アプリケーションの設計・開発を担当。直近では、生成 AI を前提とした開発フローの整備や、開発者が生成 AI を効率的に活用するための支援に取り組んでいる。 大石 尋斗 TOPPAN 株式会社 IoT ソリューション事業部 ICT 本部・ジュニアエンジニア AWS の利用を開始して約 1 年。入社 2 年目で AWS 認定資格、SAP（AWS Certified Solutions Architect – Professional）を取得。業務では生成 AI を組み込んだアプリケーション開発に従事し、新規機能開発および改修を担当。フロント／バック／クラウドインフラまで、幅広い領域をカバーしている。 アマゾンウェブサービスジャパン 合同会社 三好 史隆 アマゾンウェブサービスジャパン 合同会社 技術統括本部 自動車・製造 ソリューション部 ソリューションアーキテクト システム構築のためのアーキテクチャ提案や人材育成のためのワークショップ提供など、技術的な面からお客様のクラウド活用をご支援しています。

イントロダクション 「変化を歓迎する」──それはアジャイルが一貫して大切にしてきた姿勢です。そしていま、生成 AI の急速な普及は、ソフトウェア開発に大きな変化をもたらしています。AI コーディングエージェントが日常のツールとなり、要件定義から実装、運用に至るまでのプロセス全体が再定義されつつあります。求められる人材のスキルも、内製化と外部パートナーの役割分担も、そのあり方が問い直されています。 だからこそ、計画に固執せず変化に適応し、短いサイクルで小さく試して学びを回し続けるアジャイルの真価が、AI 時代にこそ問われています。AI を開発のどこに委ねるのか、スピードと品質をどう両立するのか、文化を組織にどう根付かせるのか、各社の試行錯誤を持ち寄り、対話する場としてのイベントを開催しました。本記事ではその様子をご紹介します。 イベント概要 2026 年 6 月 9 日、AWS 麻布台オフィスにて「FY26 アジャイルへの取り組み 異業種情報交換イベント」を開催しました。本イベントには、株式会社サイバーエージェント様、東海旅客鉄道株式会社様、株式会社日立ハイテク様、富士フイルムホールディングス株式会社様の 4 社から、アジャイルに取り組んでいる実務者の方々にご参加いただきました（以降、参加企業名については情報保護の観点から、A 社、B 社などのアルファベット表記とします）。 参加各社が扱うプロダクトは、サプライチェーン最適化のための DX 基盤、社内向け AI プラットフォームなど多岐にわたり、業界や組織文化も大きく異なります。各社それぞれの特徴あるスタイルでアジャイル開発を推進されている点が印象的でした。 ラウンドテーブル ラウンドテーブルでは、6 つのテーマで議論を行いました。 AI、開発のどこに使っていますか？ 各社共通して、コーディング支援とドキュメント生成は確かな成果が出始めている領域として挙がりました。一方、要件定義の上流や組織横断の意思決定を伴う領域では、AI を活かしきるための運用設計がまだ模索中であることが共有されました。A 社様からは「生成 AI 支援から自動化へ」、すなわち AI に手伝ってもらう段階から AI に任せる段階への移行が次のチャレンジとして語られ、B 社様からは、AI を前提とした内製プラットフォームの社内展開で月単位の業務削減効果を計測している事例が紹介されました。AI 活用は「何に使うか」だけでなく「フィードバックをどう次の改善に回すか」が決定的に重要、という認識が共有されました。 アジャイル文化の浸透、最初の突破口は何でしたか？ 複数社から共通して挙がったのは、「動くものを早期に見せる」ことの強さです。机上の説明では伝わらない価値も、実際に動くプロダクトを目にすると一気に理解が進む、という経験は各社に共通していました。C 社様からは運用改善ワークショップを起点に Phase 分けで段階的に進め、現場の納得感を醸成しながら自動化アジャイルを浸透させている取り組みが、D 社様からは、3 年前にスクラムを始めた当初に社内の評価制度や承認プロセスとの摩擦を一つずつ解消してきた経緯が紹介されました。組織特性によってアプローチは異なりますが、「小さな成功を見せる」「現場の納得を起点に広げる」という点で各社の経験は一致していました。 スピードと品質、どう両立していますか？ A 社様からは、シフトレフト活動による後工程不良の低減と、リリーススピード重視で生まれた技術負債の精算を並行して進める取り組みが紹介されました。デプロイ頻度を継続的に伸ばす中で品質を担保し続けるための仕組み作りの重要性が強調されました。B 社様からは、機能規模の拡大に伴い毎週リリースが困難になりつつあり、リリースサイクルの見直しが必要になってきている、というリアルな悩みが共有されました。C 社様からは、ゲートキーパー型からガードレール型への運用転換、すなわち「事前審査で止める」のではなく「動きながらガードレールで守る」という発想転換が紹介されました。「品質を確保することが結果的にスピードアップにつながる」という、スピードと品質を二項対立で捉えない視点が印象的でした。 アジャイルの成果、社内にどう説明していますか？ A 社様からは、アクティブ開発者数、開発ステップ数、マージ済 MR 数、変更リードタイム、デプロイ頻度といった開発生産性指標を継続的に計測し、KLOC のような従来指標も含めた複数の物差しで価値を語るアプローチが共有されました。B 社様からは社内利用時間の業務削減効果や全社 MAU といったユーザー側の指標で価値を語る取り組みが、C 社様からは自動化による工数削減率など運用自動化ならではの ROI の見せ方が、D 社様からは、プレスリリースや AWS Summit といった外部発信を通じて社内に対しても「成果が世の中に届いている」ことを可視化する効果が紹介されました。経営層への説明においては、開発側と顧客・利用側の指標を組み合わせて多角的に価値を提示することの重要性が、改めて確認されました。 新メンバーの立ち上がり、何を工夫していますか？ A 社様からは、新規メンバーがスクラムチームへ参画する際の早期立ち上がりが現在進行形の課題として提起され、ドキュメント整備、ペア作業、徐々に責任範囲を広げる段階的アプローチが共有されました。C 社様からは運用改善ワークショップを通じて新規メンバーが業務全体像を可視化するところから始める手法が、D 社様からは自社内スクラムマスターの養成と、開発・運用・広報を並行して進める中で各役割を体験的に学ぶ仕組みが紹介されました。技術力だけでなく自律性と改善マインドを育てる重要性は過去にも取り上げられてきましたが、今回は「AI ツールに早く慣れることが立ち上がりを加速する」という新しい視点も加わりました。 ふりかえり、形骸化させない秘訣は？ お悩みのポイントは「同じ話の繰り返しになる」「アクションが実行されない」というものでした。これに対し、フォーマットを定期的に変える、外部ファシリテーターを入れる、アクションのオーナーと期限を必ず決める、次回冒頭で前回アクションをレビューする、といった具体的な工夫が共有されました。A 社様からは品質指標の推移を見ながらふりかえることで感覚的な議論ではなくデータドリブンなふりかえりを目指している取り組みが、B 社様からは Slack や Notion を活用してフィードバックを日常的に集め、ふりかえりを「2 週間に 1 度の特別なイベント」ではなく「常時走るプロセス」にする取り組みが紹介されました。「ふりかえりは儀式ではなく改善のエンジン」という言葉が印象的に残ったテーマでした。 参加者の声 イベント終了後のアンケートでは、多くの参加者から高い満足度と前向きなコメントをいただきました。 自分たちだけが持っている知見だけに捉われている部分があったので、各会社様の話を聞けて有意義な時間となった スピードと品質の両立において、品質を確保することによって手戻りが減少し、スピードアップにもつながること 他社の使用ツール、振り返り方法、要件定義から実装に移るまでのフロー、AI の活用方法を知れた 組織の制約の中でアジャイルを進める工夫をいろいろ伺えてよかった、今後の活動に活かしていきたい 一方で、「ディスカッションの時間がもう少しあると良い」「もう少し参加社数が多くても良い」など、次回に向けた建設的なご要望もいただきました。これらの声は次回イベントの企画に活かしてまいります。 まとめ 今回のイベントを通じて、いくつかの重要な気づきが共有されました。第一に、AI はアジャイルを置き換えるものではなく、アジャイルの中に組み込まれて進化を加速させるパートナーであるということです。第二に、スピードと品質は二項対立ではなく相互強化の関係にあるということです。品質を担保する仕組みが手戻りを減らし、結果的にスピードを生みます。第三に、アジャイルの成果を語る言葉は多角的でなければならないということです。開発側、顧客側、運用側の指標を組み合わせて経営層に価値を提示する力が問われます。そして最後に、「自律と改善」のマインドセット、小さな成功を積み重ねる実践的アプローチ、業界を越えた情報交換の重要性、これらは AI 時代になっても変わらないアジャイルの本質です。本イベントで参加各社が得た知見が実務に反映され、次の一歩につながることを期待しています。

Amazon Bedrock で OpenAI GPT-5.6 モデルが 25 を超える AWS リージョンから利用可能になり、クロスリージョン推論 (CRIS) に対応しました。クロスリージョン推論に対応する GPT-5.6 のモデルは Sol、Terra、Luna の 3 つで、それぞれ性能とコストのバランスが異なります。 この対応で日本拠点のお客様にとって特に重要なのは、 東京リージョン (ap-northeast-1) と大阪リージョン (ap-northeast-3) が、グローバル推論プロファイルの呼び出し元 (ソース) リージョンに含まれている ことです。すでに東京リージョンで Amazon Bedrock をお使いのお客様は、 アプリケーションの接続先リージョンを変更することなく、いま使っている環境のまま GPT-5.6 を呼び出せます。 本記事では、GPT-5.6 モデルの概要、地理的 (Geographic) 推論プロファイルとグローバル推論プロファイルの違い、そしてそれが日本拠点のお客様にとって具体的に何を意味するのかを整理します。あわせて、導入を判断する前に必ず把握しておくべきデータの所在とレイテンシの論点を扱い、最後に Amazon Bedrock コンソールで試す手順を紹介します。 コード例、IAM ポリシー、SCP、クォータ管理といった実装の詳細は、関連記事「 東京リージョンから Amazon Bedrock の OpenAI GPT-5.6 を呼び出す実装ガイド 」で解説しています。 Amazon Bedrock の GPT-5.6 Amazon Bedrock の GPT-5.6 ファミリーには、汎用のモデルと、サイバーセキュリティに特化したモデルがあります。本記事で扱うのは、クロスリージョン推論に対応する 3 つの汎用モデル (Sol、Terra、Luna) です。 3 つのモデルに共通する仕様は次のとおりです。 入力はテキストと画像、出力はテキスト コンテキストウィンドウは 100 万トークン 推論 (reasoning) モード、サーバーサイドツール呼び出し、プロンプトキャッシュに対応 OpenAI Responses API、OpenAI Chat Completions API、Amazon Bedrock Converse API から呼び出し可能 ストリーミングは Responses API と Chat Completions API の stream=True 、および ConverseStream に対応 モデル間の主な違いは、位置づけと対応リージョンです。対応リージョンは呼び出し方 (In-Region / Geo / Global) ごとに異なるため、次の表ではその区分で整理しています。最新の提供状況は、後述のドキュメントリンクからご確認ください。 GPT-5.6 Sol GPT-5.6 Terra GPT-5.6 Luna 位置づけ 最も高性能。エージェント用途・コーディング向け バランス型。日常的な本番ワークロード向け 高速・低コスト。大量処理向け In-Region (リージョン内) 対応 us-east-1 、 us-east-2 us-east-1 、 us-east-2 、 us-west-2 us-east-1 、 us-east-2 、 us-west-2 Geo ( us. ) 対応 us-east-1 、 us-east-2 、 us-west-1 、 us-west-2 同左 同左 Global ( global. ) 対応 東京・大阪を含む商用リージョン全体 同左 同左 料金はモデルごとに異なります。最新の単価は Amazon Bedrock の料金 ページをご確認ください。各モデルの提供リージョンの正式な一覧は、 Amazon Bedrock のリージョン別モデルサポート ページをご参照ください。 GPT-5.6 におけるクロスリージョン推論の仕組み クロスリージョン推論自体は Amazon Bedrock でかねてより提供されているもので、新機能ではありません。 推論プロファイル (inference profile) を通じて動作します。推論プロファイルは、モデルと、Amazon Bedrock がリクエストをルーティングできる AWS リージョンの組み合わせを定義した論理的な識別子で、生のモデル ID の代わりに指定します。 お客様はソースリージョンからプロファイルを呼び出し、Amazon Bedrock がそのリクエストを宛先リージョンにルーティングして、そのリージョンの計算リソースで処理します。 クロスリージョン推論は、第一義的にはキャパシティのための仕組みです。 1 つのリージョンで利用可能なキャパシティに縛られるのではなく、より広い計算リソースのプールを利用できるようにすることで、スループットを高め、負荷がかかった状況でも安定した性能を維持しやすくします。 GPT-5.6 のローンチでは、2 種類のクロスリージョン推論プロファイルが導入されました。この 2 つは、 データがどこで処理されうるか が異なり、その違いがコンプライアンス上の主要な判断ポイントになります。 Geo (地理的) 推論プロファイル ： us. のように地理コードが接頭辞として付きます (例: us.openai.gpt-5.6-terra )。推論処理をあらかじめ定義された地理的範囲内のリージョンに限定します。リクエストはソースリージョンから入り、その地理的範囲内の宛先リージョンにのみルーティングされます。データレジデンシー要件のあるワークロードでも、境界の内側で複数リージョンにスケールできます。 グローバル推論プロファイル ： global. が接頭辞として付きます (例: global.openai.gpt-5.6-terra )。そのモデルが展開されている、サポート対象のすべての AWS 商用リージョンに対して、リアルタイムのキャパシティ状況に基づいてリクエストをルーティングできます。最も広いキャパシティプールを利用でき、地理的な処理要件がないワークロードに適した選択肢です。 どちらのプロファイルでも、リクエストはすでに Amazon Bedrock を呼び出しているリージョンからプロファイル ID を指定して送信し、どのバックエンドリージョンが処理するかは Amazon Bedrock が決定します。レスポンスは同じ呼び出しの中で返ります。 アプリケーションのコード側で、どの宛先リージョンが処理したかを追跡する必要はありません。 補足として、次の点を押さえておいてください。 請求とクォータの消費は、どのバックエンドリージョンが処理したかに関係なく、お客様のアカウントに対して記録されます。 そのため、支出とスループットは引き続き 1 つのビューで把握できます。 グローバル CRIS を経由するデータは、そのモデルの対象リージョン群をまたいで処理される可能性があります。 処理を特定の地理的範囲に限定するデータレジデンシー要件がある場合は、該当する地理の Geo プロファイル (例: us.openai.gpt-5.6-terra ) を使うか、単一リージョンへの直接呼び出しを使ってください。 クロスリージョン推論の仕組みそのものについては、Amazon Bedrock の クロスリージョン推論のドキュメント で解説されています。GPT-5.6 の各リージョンがどの呼び出し方 (In-Region / Geo / Global) に対応しているかは、 リージョン別モデルサポート ページのリージョン別の対応表をご確認ください。 ソースリージョンと宛先リージョン まず押さえておきたいのは、 us. プロファイルのソースリージョンは米国とカナダのリージョンに限られており、東京リージョンと大阪リージョンは含まれていない 点です。つまり、東京リージョンから us.openai.gpt-5.6-terra を呼び出すことはできません。 これは仕組み上の制約ではなく、提供状況によるものです。 ご自身の環境で呼び出せるプロファイルは、次のコマンドで確認できます。 aws bedrock list-inference-profiles --region ap-northeast-1 \ --query "inferenceProfileSummaries[?contains(inferenceProfileId, 'gpt-5.6')].[inferenceProfileId,status]" \ --output table 一方で、 東京リージョンと大阪リージョンは、グローバル推論プロファイルのソースリージョンに含まれています。 以下の表は、グローバル推論プロファイル ( global.openai.gpt-5.6-sol / -terra / -luna ) を呼び出せるソースリージョンと、リクエストが処理されうる宛先リージョンの一覧です。ルーティングの内容は Sol、Terra、Luna の 3 モデルで共通です。 ソースリージョン 宛先リージョン 米国 : us-east-1 、 us-east-2 、 us-west-2 、 us-west-1 カナダ : ca-central-1 欧州 : eu-north-1 、 eu-west-3 、 eu-west-1 、 eu-central-1 、 eu-south-2 、 eu-south-1 、 eu-west-2 、 eu-central-2 アジアパシフィック : ap-southeast-4 、 ap-southeast-2 、 ap-northeast-1 (東京) 、 ap-northeast-3 (大阪) 、 ap-northeast-2 、 ap-south-1 、 ap-south-2 、 ap-southeast-1 、 ap-southeast-3 、 ap-southeast-7 、 ap-southeast-5 、 ap-east-2 中東 : me-central-1 、 il-central-1 南米 : sa-east-1 仕組み上はサポート対象の AWS 商用リージョン全体が対象。実際の処理先はモデルがデプロイされているリージョン ( us-east-1 、 us-east-2 、 us-west-2 ) 各プロファイルのルーティング対象リージョンの正式な一覧は、 リージョン別モデルサポート ページの GPT-5.6 の対応表をご確認ください。クロスリージョン推論プロファイル全般の仕様 (オプトインリージョンの扱いや、ソースリージョンによって宛先が変わる場合があることなど) は、 推論プロファイルのサポート対象リージョンとモデル ページに記載されています。 日本拠点のお客様にとって、これが何を意味するか 具体的なメリットは次の 3 点です。 1. 既存の Amazon Bedrock 利用環境をそのまま使える すでに東京リージョンで Amazon Bedrock をお使いであれば、エンドポイントもリージョン設定も、VPC エンドポイントも、CloudTrail の集約先も、いま使っているものがそのまま使えます。アプリケーションコードで変えるのは modelId (または model ) パラメータに渡す文字列だけ です。 - model_id = "anthropic.claude-...." + model_id = "global.openai.gpt-5.6-terra" 米国リージョン側にスタックやエンドポイントを追加で用意する必要はありません。 ただし、 コード以外に必要な準備が 2 つあります。 ひとつは IAM ポリシーで、グローバル推論プロファイルの呼び出しには 3 つのステートメントが必要です。もうひとつは、利用可能リージョンを制限する SCP を使っている場合の除外設定です。いずれも 実装ガイドの記事 で解説しています。 2. 単一リージョンより広いキャパシティプールを使える グローバル推論プロファイルは、リアルタイムのキャパシティ状況に基づいてルーティングします。特定リージョンの需要が高まっている時間帯でも、単一リージョンに固定した呼び出しに比べてスロットリングの影響を受けにくく、負荷時のスループットが安定しやすくなります。新しいモデルの提供開始直後は需要が集中しやすいため、この効果は特に大きくなります。 3. 運用の可観測性は東京リージョンに残る リクエストがどのリージョンで処理されても、CloudTrail のイベント、モデル呼び出しログ、CloudWatch メトリクス、Service Quotas はすべて ソースリージョンである東京 に記録されます。監視・課金・クォータ管理のダッシュボードを日本国外に分散させる必要はありません。 日本拠点のお客様が事前に理解しておくべきこと グローバル CRIS の利点と引き換えに、必ず理解しておくべき論点が 2 つあります。導入判断の前に、社内のセキュリティ・コンプライアンス担当と共有してください。 推論処理は日本国外のリージョンで行われる これが最も重要な点です。東京リージョンからグローバル推論プロファイルを呼び出した場合、 推論処理はモデルがデプロイされているリージョンで実行されます。 プロンプトと生成結果は、処理のために日本国外に送信されます。 執筆時点では、GPT-5.6 がデプロイされているのは米国の 3 リージョン ( us-east-1 、 us-east-2 、 us-west-2 ) です。 グローバル推論プロファイルという名称は「全世界のリージョンにルーティングしうる仕組み」を指しますが、実際にリクエストが到達できるのはモデルが配置されているリージョンに限られます。したがって東京から呼び出した GPT-5.6 のリクエストは、米国内で処理されます。 ただし、 この前提は将来にわたって保証されるものではありません。 グローバル推論プロファイルの宛先はモデルの展開状況に追随するため、対応リージョンが増えれば処理先も変わりえます。加えて、どのリージョンが処理するかはリアルタイムのキャパシティ状況に基づいて Amazon Bedrock が自動的に選択し、 お客様が処理先リージョンを指定することはできません。 そのため、データレジデンシーの観点では「現時点で米国内に収まっている」ことを設計の前提に置くのではなく、 地理的範囲を限定しない仕組みである という理解でご検討ください。処理範囲を確実に限定する必要がある場合は、グローバル推論プロファイルではなくジオ推論プロファイルが適切な選択肢です。 特定のリージョンで処理する必要がある場合、一般には「そのリージョンのモデルを直接呼び出す」という選択肢があります。ただし 東京・大阪リージョンから GPT-5.6 を直接呼び出す方法は提供されていません。 bedrock-runtime エンドポイントは推論プロファイルの指定を求め、生のモデル ID を受け付ける別のエンドポイント ( 実装ガイドの記事 で解説) は東京・大阪では GPT-5.6 を利用できません。そのため、処理リージョンを日本国内に固定する必要があるワークロードでは、別のモデルを検討してください。 あわせて、 不正利用検知の目的で入力プロンプトと出力結果が保存される場合がある 点を、社内のコンプライアンス担当と共有してください。GPT-5.6 を含む一部のモデルでは、自動不正利用検知の分類器がフラグを立てたトラフィックが最大 30 日間保持されます (詳細は後述の「セキュリティとコンプライアンス」を参照)。 ここで、 リージョンをまたぐデータと、ソースリージョンに留まるデータを区別しておくことが重要です。 データ 保存先 出典 モデル呼び出しログ (リクエスト・レスポンスの全文を含む) ソースリージョン (東京) モデル呼び出しのモニタリング CloudTrail イベント、CloudWatch メトリクス ソースリージョン (東京) グローバルクロスリージョン推論 不正利用検知でフラグが立った入力・出力 (最大 30 日間) 宛先リージョン (推論処理が行われたリージョン) 不正使用の検出 モデル呼び出しログについては、配信先として指定できるのが 同一アカウント・同一リージョンの Amazon S3 または CloudWatch Logs のみ である点がドキュメントに明記されています。そのため、プロンプトとレスポンスの全文を保管したい場合でも、その保管先は東京リージョン内に収まります。 一方で、 不正利用検知のために保持されるコンテンツは、処理が行われた宛先リージョン側に保存されます。 不正使用の検出のドキュメントには次のように記載されています。 If cross-region inference is enabled for these models, retained inputs and outputs are stored in destination regions (i.e., the region where your inference request is processed). この点はデータレジデンシーの検討で見落としやすいため、コンプライアンス担当と共有しておくことを推奨します。なお、リージョンをまたいで転送されるリクエストは AWS のネットワーク内を暗号化されて流れ、パブリックインターネットを経由しません。 判断のための整理は次のとおりです。 ワークロードの要件 推奨される選択 データ処理を日本国内に限定する必要がある 執筆時点では GPT-5.6 で要件を満たせません。 日本ジオ ( jp. ) の推論プロファイルが提供されている他のモデル、または東京リージョンで In-Region 呼び出しに対応した他のモデルを検討してください データ処理を特定の地理的範囲に限定したい Geo プロファイルが該当します。ただし GPT-5.6 に提供されるのは us. (米国) のみで、 東京からは呼び出せません 。米国リージョンをソースとして呼び出す構成が必要です 処理リージョンを 1 つに固定したい 東京・大阪をソースとする GPT-5.6 では実現できません。 クロスリージョン推論では処理先を指定できず (仕様上の挙動であり設定で変更できません)、日本リージョンから GPT-5.6 を直接呼び出す方法も提供されていません。別のモデルをご検討ください 地理的な処理要件はない グローバル CRIS が最適です。 最も広いキャパシティプールを利用できます レイテンシに処理先までのネットワーク往復が加わる 処理が日本国外のリージョンで行われるため、東京から呼び出す場合、ネットワークの往復時間がリクエストごとに上乗せされます。処理先が米国リージョンであれば、太平洋を往復する分の時間が加わります。 また、複数の処理先候補の中からリクエストごとに選択されるため、レイテンシは一定ではありません。 対話型 UI のように応答の速さが体験に直結するワークロードでは、次の対策が有効です。 ストリーミングを使う ： stream=True または converse_stream を使うことで、最初のトークンが届いた時点から表示を開始できます。ネットワークの往復は最初の 1 回に集約されるため、体感の待ち時間を大きく削減できます。 プロンプトキャッシュを活用する ：長い共通プレフィックス (システムプロンプトや few-shot 例) の再処理を省けるため、キャッシュ対象部分の処理時間を短縮できます。 実測する ：一般的な目安ではなく、実際のプロンプトサイズと出力長で、本番と同じ経路で計測してください。処理先が変動する性質上、 平均値だけでなく p90 / p99 も併せて確認すること を推奨します。Converse API のレスポンスには metrics.latencyMs が含まれるため、まずは短いプロンプトで往復を確認し、その後に本番相当の負荷で計測するとよいでしょう。 ストリーミングとプロンプトキャッシュの具体的な実装方法は、 実装ガイドの記事 で解説しています。 重要なのは、これがトレードオフであって欠陥ではないという点です。 バッチ処理、非同期のドキュメント処理、エージェント的なワークフロー、社内ツールなど、数百 ms のレイテンシが問題にならないワークロードは多く、そうしたケースではグローバル CRIS のキャパシティ上の利点がそのまま享受できます。一方、ミリ秒単位の応答性が要件であれば、その要件を先に確認してから設計してください。 セキュリティとコンプライアンス クロスリージョン推論は、同一リージョン内での直接呼び出しと同じ Amazon Bedrock のセキュリティモデルを使用します。リクエストは AWS Identity and Access Management (IAM) の認証情報で認証され、IAM ポリシーによってロールが呼び出せる推論プロファイルを制御できます。 Amazon Bedrock はチップレベルで実施される ゼロオペレーターアクセス (ZOA) セキュリティモデルを採用しており、AWS のオペレーターがお客様のプロンプトや生成結果にアクセスすることはできません。すべてのモデル呼び出しはお客様の IAM ポリシー配下で実行され、VPC エンドポイント経由で VPC からプライベートに到達でき、AWS CloudTrail に記録されます。データ境界ポリシーによって、アカウントやネットワークの境界をまたぐデータの流出を防ぐこともできます。 Amazon Bedrock は既定でゼロデータ保持 (ZDR) のモデルを採用しており、モデルへの入力と出力を保存しません。ただし GPT-5.6 を含む一部のモデルでは、自動不正利用検知の分類器がフラグを立てたトラフィックが、オフラインでの不正利用検知のために最大 30 日間保持されます。 クロスリージョン推論を使う場合、 保持されるコンテンツは宛先リージョン (推論処理が行われたリージョン) に保存されます。 保持されたデータは AWS が保存・処理し、お客様が明示的に許可しない限りサードパーティのモデルプロバイダーと共有されることはありません。要件に応じて、完全な ZDR の適用を AWS のアカウントチームに相談できる場合があります。 対象となるモデルと仕組みの詳細は、Amazon Bedrock ユーザーガイドの 不正使用の検出 をご参照ください。 Amazon Bedrock コンソールで GPT-5.6 を試す GPT-5.6 を最も手軽に試せるのは、Amazon Bedrock コンソールのプレイグラウンドです。コードや SDK のセットアップは不要です。プロンプトを送信し、推論パラメータを調整し、モデルを切り替えながら、API 統合の前に各モデルの感触を確かめられます。 モデルセレクターには地理的推論プロファイルとグローバル推論プロファイルの両方が表示されるため、コードを書く前にどちらのクロスリージョン推論オプションも試せます。 東京リージョンから試す手順: Amazon Bedrock コンソールを開き、 リージョンセレクターでアジアパシフィック (東京) ap-northeast-1 を選択します 。 ナビゲーションペインの Test の下から Playground を選択します。 ページ中央の Select model を選択します。 OpenAI GPT-5.6 Sol を検索し、 Global OpenAI GPT-5.6 Sol を選択して Apply を選択します。 プロンプトを入力し、 Run を選択して応答を生成します。 まとめ この記事では、Amazon Bedrock の OpenAI GPT-5.6 におけるクロスリージョン推論の仕組みと、東京・大阪リージョンをソースとして使う場合に押さえるべき論点を整理しました。 GPT-5.6 には 3 つのモデルがあります。要求の厳しいエージェント用途とコーディングには Sol、日常的な本番ワークロードには Terra、大量処理とレイテンシに敏感なアプリケーションには Luna です。 日本拠点のお客様にとって、この対応の実際的な意味は次の 3 点に集約されます。 グローバルキャパシティへのアクセス ：東京リージョンと大阪リージョンはグローバル推論プロファイルのソースリージョンに含まれます。アプリケーションの接続先リージョンを変更することなく、いま使っている環境から GPT-5.6 を呼び出せます。 スループットの改善 ：グローバル推論プロファイルはリアルタイムのキャパシティ状況に基づいてルーティングするため、単一リージョンに固定した呼び出しよりも広い計算リソースのプールを利用できます。需要が集中する時間帯でも性能が安定しやすくなります。 可観測性はソースリージョンに集約される ：呼び出しログ、CloudTrail、CloudWatch メトリクス、Service Quotas はすべて東京リージョンに記録されます。監視基盤を日本国外に分散させる必要はありません。 一方で、 グローバル CRIS を使うと推論処理は日本国外のリージョンで実行されます。 執筆時点で GPT-5.6 がデプロイされているのは米国の 3 リージョンのため、実際の処理は米国内で行われますが、グローバル推論プロファイルは地理的範囲を限定しない仕組みであり、処理先を指定することもできません。データレジデンシー要件があるワークロードには適さず、レイテンシには処理先までのネットワーク往復が加わります。導入前に、この点を社内のセキュリティ・コンプライアンス担当と共有してください。 なお、 GPT-5.6 に日本ジオ ( jp. ) の推論プロファイルは提供されていません。 推論処理を日本国内に限定する必要がある場合は、 jp. プロファイルが提供されている他のモデル、または東京リージョンで In-Region 呼び出しに対応した他のモデルをご検討ください。実際の導入時には、記事中の list-inference-profiles コマンドと AWS 公式ドキュメントで最新の対応状況をご確認ください。 次のステップ Amazon Bedrock コンソールを 東京リージョン で開き、Playground から Global OpenAI GPT-5.6 Sol にテストプロンプトを送ってみてください。 実装に進む場合は、関連記事「 東京リージョンから Amazon Bedrock の OpenAI GPT-5.6 を呼び出す実装ガイド 」で、3 種類の API のコード例、IAM ポリシー、SCP、クォータ管理を解説しています。 本番ワークロードのサイジング前に、 Amazon Bedrock の料金 ページで GPT-5.6 の最新単価を確認してください。 問題が発生した場合やコミュニティに質問したい場合は、 AWS re:Post で検索または投稿するのが有効です。 著者について 本橋 和貴 (Motohashi, Kazuki) は、AWS Japan の機械学習ソリューションアーキテクトです。AI/ML 領域には9年ほど携わっており、最近は主に自動車業界のお客様を対象にAWS の生成 AI/ML サービスのご利用をサポートしています。博士 (理学)。

デジタル庁は2026年6月12日、『行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（第2.0版）』（政府ガイドライン）を公開しました。本ガイドラインは「デジタル社会推進標準ガイドライン（DS-920）」の一つとして、政府機関による生成AIの安全かつ効果的な活用方法を包括的に示すものです。 第1.0版の枠組みを踏襲しつつ、対象範囲とリスク管理を実態に合わせて拡張・精緻化したのが第2.0版です。今回の改定では、対象とする生成AIが音声・画像にも拡大されたほか、セキュリティ要件の強化が盛り込まれ、調達チェックシートの要求事項も29項目から33項目に拡充されています。AWS は、政府機関の調達担当者とパートナー企業向けに、政府ガイドラインの調達チェックシートの各要件に対する回答例を提供します。この回答例は、Amazon Bedrock を活用したオープンソースアプリケーション『 Generative AI Use Cases（GenU） 』を用いた 生成AIアプリケーション に対応し、政府機関の調達プロセスとパートナー企業の提案書作成を支援します。 １．政府ガイドライン（第2.0版）の概要 政府ガイドライン策定・改定の背景 政府における 生成AI の活用は、行政サービスの効率化や質の向上に大きな可能性をもたらします。一方で、情報漏えいや不適切な出力などのリスクも存在するため、適切なガバナンスとリスク管理が不可欠です。今回の政府ガイドラインは、 生成AI の利活用促進とリスク管理を表裏一体で進めることを目的として策定されました。 第2.0版では、「AI事業者ガイドライン（第1.2版）」や「人工知能関連技術の研究開発及び活用の推進に関する法律」、同法に基づく「人工知能基本計画」「AI指針」など、最新の法令・指針の動向を踏まえて内容が更新されています。主な改定点は次のとおりです。 対象とする生成AIの範囲を拡大（従来のテキスト生成AIに加え、入力＝テキスト・音声、出力＝テキスト・画像・音声に対応。画像・動画生成やAIエージェント等もAIガバナンスの枠組みの対象に） 高リスク判定のリスク軸を見直し（従来の4軸から3軸へ整理。「要機密情報・個人情報の学習等の有無」の軸を整理・統合） セキュリティ確保に関する記載の拡充（ISMAP の活用、システム監査、要機密情報保護のための権限管理、生成AIの特性を考慮したログ取得 等） 調達チェックシート・契約チェックシートの詳細説明を整理 調達チェックシートとは 政府ガイドラインの中核となるのが「調達チェックシート（生成AIシステム用）」（別紙３）です。これは、政府機関が 生成AIシステム を調達する際に、事業者に対して確認すべき要件を体系化したものです。チェックシートには、納入事業者のAIガバナンス、適切なインプット・アウトプットやデータの取扱い、偽誤情報の出力防止を含む品質確保、生成AIシステム特有のリスクケース発生時の対応、国民等が利用する場合の適切な取扱い（生成AIによる出力であることの表示等）、個人情報や知的財産の保護、セキュリティや説明可能性の確保といった観点から、調達時の要求事項とその対策例が整理されています。 政府機関の企画者は、この調達チェックシートを参照して調達仕様書に要求事項を盛り込み、提案書を評価します。事業者にとっては、政府が求める技術要件を明確に把握し、適切な提案を行うための指針となります。第2.0版では要求事項が29項目から33項目に拡充され、ベンダーロックイン回避のためのアーキテクチャ要件（#12）、知的財産保護の生成段階／学習段階の分離（#24, #25）、インシデント発生後の封じ込め・復旧能力（#27）が新たに追加されています。いずれも、生成AIを「導入して終わり」にせず、調達後の運用・移行・インシデント対応まで見据えた要件強化といえます。あわせて、調達契約時に確認すべき事項を整理した「契約チェックシート（生成AIシステム用）」（別紙４）、ユースケースのリスクレベルを簡易的に判定する「高リスク判定シート」（別紙１）も用意されています。 主要なポイント ［対象範囲］ 対象システム：本ガイドラインが対象とする生成AI（原則として入力はテキスト・音声、出力はテキスト・画像・音声）を構成要素とする政府情報システム 適用開始：2026年9月1日施行（CAIO の対応事項は2026年6月30日までに必要な措置、AIガバナンスの枠組みの対象は2026年7月1日から適用） 対象外：特定秘密・重要経済安保情報・秘密文書として取扱う情報、安全保障や公共の安全・秩序の維持といった機微な情報を扱う政府情報システム ［ガバナンス体制の構築］ AI統括責任者（CAIO）：各府省庁に設置し、生成AIシステムのライフサイクルを通じた統括監理を担う 先進的AI利活用アドバイザリーボード：政府横断で調達・利活用状況の把握、高リスク案件への助言、ベストプラクティスの発信等を実施 AI相談窓口：デジタル庁が技術的・専門的観点から各府省庁を支援 ［リスク管理の仕組み］ 高リスク判定：3つのリスク軸（業務の性格／利用範囲／職員等による出力判断）でリスクレベルを評価 調達チェックシート：調達・契約時の要件確認を体系化 インシデント対応：生成AIシステム特有のリスクケースへの対応体制 ２．AWS のサンプル回答 – GenU を活用した調達チェックシート要件対応例 GenU の特徴 AWS では、政府機関の生成AI活用を支援するため、 GenU という Amazon Bedrock を活用したオープンソースのアプリケーション実装を提供しています。 GenU は最短10分でデプロイが完了する迅速な導入が可能で、セキュリティ・統制機能を標準搭載した安全性重視の設計となっています。また、チャット、RAG、文書生成、翻訳など多様なユースケースに対応しており、使った分だけの従量課金制によりスモールスタートでコスト効率よく始めることができます。 AWS サンプル回答の活用方法 政府ガイドラインでは、政府機関の生成AIシステムの調達時に「調達チェックシート」の活用が求められています。 AWS では、このチェックシートの各項目に対して、GenUを活用した場合の具体的な対応例をサンプル回答として提供し、政府機関とパートナー企業の皆様を支援いたします。サンプル回答の見方については補足資料をご参照ください。 GenUを活用した場合の具体的な対応例をサンプル回答 ［政府機関職員の皆様へ］ 調達・契約時での活用：Amazon Bedrock を活用した応札企業の技術提案と AWSサンプル回答 の対応例を照合し、データプライバシー保護や有害情報制御などの重要要件への技術的実現可能性を客観的に評価 ［パートナー企業の皆様へ］ 提案書作成での活用：調達チェックシート要件に対する Amazon Bedrock での技術的対応方針を検討し、適切な技術構成と実装方法を提案書に記載する際の参考資料として活用 ３．まとめ 政府ガイドライン（第2.0版）は、安全で効果的な 生成AI 活用のための重要な指針です。 AWS のサンプル回答は、この政府ガイドラインで示された調達チェックシート要件に対する AWS としての技術的考え方と対応例をまとめた参考資料として、政府機関の調達担当者とパートナー企業の提案書作成者にご活用いただけます。 参考情報： Generative AI Use Cases JP (GenU) Amazon Bedrock 公共機関における生成 AI の活用案 行政の進化と革新のための生成AIの調達·利活用に係るガイドライン（第2.0版） お問い合わせ 政府機関向けの 生成AI 導入に関するご相談は、 AWSパブリックセクター までお気軽にお問い合わせください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料は政府ガイドラインの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 著者： Makoto Uehara (AWS Japan, Public Sector, Senior Manager, Solutions Architect) Atsushi Kimura (AWS Japan, Public Sector, Proposal Manager)

本記事は 2026 年 8 月 17 日 に公開された「 Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch 」を翻訳したものです。 Amazon Aurora DSQL は Amazon CloudWatch Database Insights による可観測性の強化に対応しました。実際に体感するパフォーマンスや支払うコストに直結する、時間ベースのパフォーマンス診断が利用できます。 Amazon Aurora DSQL の可観測性は、DSQL クラスターの動作について具体的な改善につながる洞察を提供することを目指しています。本記事では、可観測性モデルとそのパフォーマンス・コストとの関係、そして CloudWatch Database Insights、PromQL、DSQL システム診断 AI スキルを実際に使う方法を解説します。 なぜ時間ベースの可観測性なのか Aurora DSQL は、リクエストの処理に費やした時間とリソースを反映する DPU (Distributed Processing Units) に基づいたオンデマンド料金モデルを採用しています。そのため DSQL では、データベースがユーザーのために処理を行っているときにのみ DPU が発生します。この課金モデルにより、セッションがどこで時間を費やしているかを把握することが極めて重要になります。DSQL の可観測性モデルは、まさにこの点を示してくれます。 DSQL の可観測性は、すべての開発者が気にするであろう「時間はどこで費やされているのか」に明確に答える、直接的なシグナルを提供することに重点を置いています。その大部分は時間という概念を軸に構築されており、観測する内容と体感する内容を直接結びつけます。時間はパフォーマンスにおいて最も重要な単位です。さらに、DSQL のオンデマンド料金モデル、つまり使った分だけ支払うという仕組みとも直接相関します。これは完全に意図されたもので、この相関により、観測可能なパフォーマンスと歩調を合わせてコストを管理できます。クエリが速いほど、消費する DPU は少なくなります。 DSQL は実績のあるアプローチを基盤としています。時間ベースの可観測性は、商用データベース、PostgreSQL、MySQL など、数年にわたり多くのデータベースで成果を上げてきました。DSQL はこの実績あるモデルを、分散 SQL 環境にネイティブに持ち込み、数百ものカウンターによる混乱を招くこともありません。 DASH の紹介 DSQL Active Session History (DASH) は、クラスター内のセッションのアクティビティを監視することで、可観測性メトリクスを支えています。DASH はクラスター内のすべてのアクティブなセッションを 1 秒ごとにサンプリングし、1 分間隔で集計したデータポイントを CloudWatch OTel メトリクスとして発行します。次のいずれかに該当する場合、セッションはアクティブとみなされます。 セッションが CPU を実際に消費している セッションが待機イベント (ストレージ待機やコミット待機など) でブロックされている セッションがトランザクション内にあるが、アプリケーションからのリクエストを待っている これらの状態はいずれもトランザクションのレイテンシーと DPU に影響します。DPU は DSQL の課金単位であり、その大部分はクエリの処理に費やした時間を反映します。DPU はアクティブなセッション時間に比例するため、クエリが待機に費やす時間 (または非効率な処理に費やす時間) を減らすことが、そのままコスト削減につながります。 各サンプルには追加のコンテキストが含まれ、特に重要なのはサンプル取得時点で実行されていた SQL テキストの先頭 256 文字です。これにより、サンプル取得時に何が実行され、何を待っていたかがわかります。 DASH は 1 秒に 1 回サンプリングします。一見すると粗く感じるかもしれません。しかし実際には、この頻度で「クラスター内で時間はどこに費やされているのか」という基本的な問いに答えられます。DASHはサンプリングによる統計的な全体像を提供することで、診断のオーバーヘッドを最小限に抑えつつ、ほとんどのパフォーマンス診断シナリオで根本原因を確実に浮き彫りにします。本記事の後半で示す PromQL の例が、これを実際に示しています。 DASH はデフォルトですべての Aurora DSQL クラスターで有効化されており、追加コストはかかりません。クラスターを作成した瞬間から可観測性データが得られます。 CloudWatch Database Insights Amazon CloudWatch Database Insights は、DASH データを直感的に扱う手段を提供します。2 つの重要な問い、つまり「セッションが最も多くの時間を費やしているのはどこか」「最もアクティブな SQL 文はどれか」に答えます。 図 1: 待機イベント別のデータベース負荷と最もアクティブな SQL 文を表示する CloudWatch Database Insights AWS は Aurora DSQL 向けに 1 分間隔メトリクスの CloudWatch Database Insights Standard Mode を追加料金なしで提供し、すべてのクラスターでデフォルトで有効化します。DSQL は DASH データを 15 か月間保持します。これにより、トレンド分析、キャパシティプランニング、そして長期間でしか表面化しない散発的な問題の調査に十分な履歴を確保できます。 CloudWatch Database Insights は、Amazon Relational Database Service (Amazon RDS) や Amazon Aurora (非 DSQL) のデータベースと同じ、使い慣れたビューを表示します。上部のペインには、その期間中にサンプリングされた待機イベントについて、Average Active Sessions (AAS) を使った DBLoad のタイムラインが表示されます。 RDS や Aurora (非 DSQL) のデータベースとの顕著な違いは、 Max vCPU のラインがない点です。DSQL は弾力的にスケールするため、キャパシティの上限が固定されていません。そのため、システムの健全性は本記事の後半で説明する別の方法で判断します。 下部のペインには、その期間中に最もアクティブだった SQL が表示されます。これは、サンプル取得時にその SQL 文を実行していた Average Active Sessions の数で定義されます。RDS や Aurora とは異なり、DSQL のビューには現在、累積 SQL 統計や実行計画情報へのドリルダウンは含まれていません。 待機イベント DSQL の待機イベントは、コミュニティ版 PostgreSQL と比べて数が少ないです。待機イベントのリストは、より細かい粒度を実現するために今後増える可能性はありますが、たとえば PostgreSQL 18 で現在定義されている 273 個に近づくことはまずないでしょう。これは、DSQL のクエリプロセッサ (QP) がラッチ ( LWLock )、データロック、IPC を管理する必要がないためです。これらはコミュニティ版 PostgreSQL で定義されている待機イベントの大半を占めています。次の表に、現在の DSQL の待機イベント一覧を示します。 待機名 説明 OnCpu セッションは外部からの入力を待っておらず、CPU 上で実際に実行しています。これには解析、プランニング、式の評価、結果の処理が含まれます。 ClientRead セッションはオープンなトランザクション内でアイドル状態にあり、アプリケーションが次の SQL 文またはコミット / ロールバックコマンドを送信するのを待っています。 ClientRead 待機が頻繁または長時間にわたる場合、アプリケーションの過剰なラウンドトリップや、必要以上に長く開いたままのトランザクションを示していることがよくあります。 ClientWrite 結果がネットワーク経由でデータベースからアプリケーションへ送信されています。 ClientWrite が高い場合、大きな結果セットや、アプリケーションとデータベース間のネットワークレイテンシーを示していることがあります。 Commit セッションはコミットを開始し、コミットサービスからの確認応答を待っています。応答は成功か、アボート (シリアライゼーションエラー) のいずれかです。どちらの結果も Commit 待機を経て発生します。 FkExistenceCheck セッションは参照先の外部キーの行が存在するかを検証しています。この検証には、関係を確認するための読み取りが必要です。 PgSleep アプリケーションが明示的に pg_sleep() を呼び出したため、セッションがスリープしています。これはアプリケーション起因の待機であり、データベースが課す待機ではありません。 ScatteredBatchRead セッションはストレージからのバッチ読み取りを実行し、連続していない複数のキーを 1 回のストレージ呼び出しで取得しています。 SequentialScanRead セッションはストレージから連続した範囲のキーを読み取っています。これは必ずしもフルテーブルスキャンを意味しません。比較的小さな連続キー範囲を対象とする場合もあります。 SingleRead セッションはストレージから単一のタプル (ポイントルックアップ) を読み取っています。このイベントは、バッチサイズ 1 の ScatteredBatchRead にほぼ置き換えられており、現在の DSQL バージョンではまれです。 StartTransaction セッションは分散トランザクションを開始する準備をしています。 UniqueConstraintCheck セッションは一意キー制約を検証しており、重複をチェックするためにストレージの読み取りが必要です。これは、主キー以外の列に対する一意制約と、新しい行の挿入時の主キー制約の両方に適用されます。 表 1: DSQL の待機イベント SQL 文 DSQL は SQL 文を Query ID で参照します。Query ID は、QP が SQL テキストに基づいて生成する一意のクエリ ID を base32 でエンコードしたものです。DSQL は DASH データ内のすべての SQL に Query ID を割り当てます。SQL テキストは正規化された形式で記録され、リテラル値を $ プレフィックス付きの数値識別子に置き換えられます。 PromQL による直接クエリ PromQL は、Database Insights を使う代わりに、基盤となる DASH データを直接クエリする手段です。DSQL は DASH データを CloudWatch OTel メトリクスとして公開しており、Amazon CloudWatch Query Studio で PromQL を使ってクエリできます。これにより Database Insights と同じ情報に加え、カスタム分析用の追加ディメンションが得られます。 次の PromQL の例では、3 つの一般的なユースケースを扱います。1 つ目は、どの待機イベントが最も多くの時間を蓄積しているかの特定です。2 つ目は、待機に最も多くの時間を費やしているクエリの発見です。3 つ目は、ストレージ待機で最も長く待っているクエリの特定です。Query Studio でこれらのクエリを試す前に、必ず my_cluster_id を実際のクラスター ID に置き換えてください。 Average Active Sessions によるデータベース負荷 avg by("db.wait.event") ({"db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="my_cluster_id"}) 図 2: 待機イベント別にグループ化した Average Active Sessions によるデータベース負荷 Average Active Sessions 上位 5 クエリ topk(5, avg by("db.query.normalized_text") ({"db.active_sessions.avg","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 3: Average Active Sessions 別の上位 5 クエリ Average Active Sessions と待機イベント別の上位 5 クエリ topk(5, avg by("db.query.normalized_text", "db.wait.event") ({"db.active_sessions.avg","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 4: Average Active Sessions と待機イベント別の上位 5 クエリ Average Active Sessions とストレージ待機別の上位 5 クエリ topk(5, sum by("db.query.normalized_text") ({"db.active_sessions.avg","db.wait.event"=~"S.*Read|.*Check","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 5: Average Active Sessions とストレージ待機別の上位 5 クエリ アプリケーションの健全性 他の AWS リレーショナルデータベースサービスでは、インスタンス内の vCPU 数と同じだけのセッションが CPU 上にある状態は、健全ではない兆候です。アプリケーションからの要求が利用可能なコンピューティングを上回ると、レイテンシーが悪化します。前述のとおり、DSQL にはクラスターが需要に合わせて弾力的にスケールするため Max vCPU という概念がありません。そのため、アプリケーションの健全性を判断する別の方法が必要です。 まず、AAS の観点で健全なシステムがどのようなものかを考えてみましょう。これに唯一の答えはありません。アプリケーションごと、そしてそのアプリケーションの負荷ごとに異なります。あるアプリケーションは、5 つのセッションが同時にアクティブでストレージ読み取りを待っているときは正常に動作し、10 のセッションがストレージ読み取りを待っているときは動作が悪化するかもしれません。別のアプリケーションは、500 のセッションがストレージ読み取りを待っていても完璧に動作するかもしれません。重要な考え方は、アプリケーションごとに正常動作時の AAS プロファイルが異なるということです。待機セッションの具体的な数だけでは、健全性の低さを示すことにはなりません。 DSQL の弾力的なスケーリングの性質からも、ある日は 100、翌日は 1,000 の待機セッションがあったとしても、必ずしも健全性の低下を示すわけではありません。単にシステムが 10 倍のトランザクションを処理していることを意味するだけかもしれません。では、どうやって健全性を判断すればよいのでしょうか。 答えは、絶対的な数値ではなく、時間の経過に伴う待機イベントの割合を比較しなければならないということです。たとえば、健全なアプリケーションが次の表のような待機プロファイルを示すと仮定します。 待機イベント 待機セッション数 SequentialScanRead 40 Commit 10 OnCpu 50 表 2: 正常時の待機イベントの割合 忙しい日にはこれらの数値がそれぞれ 80、20、100 に増えるかもしれません。相対的な割合は同じままで、システムの負荷が 2 倍になっても健全であることを示しています。DSQL は追加の負荷に対応して自動的にスケールします。しかし、待機プロファイルが次の表のようになる日があれば、何かがおかしくなったとわかります。 待機イベント 待機セッション数 SequentialScanRead 90 Commit 3 OnCpu 7 表 3: 異常時の待機イベントの割合 このケースでは、アプリケーションの変更や SQL プランの変更によって、セッションが変更の処理やコミットよりもデータのスキャンに多くの時間を費やすようになった可能性が高いです。待機イベントの割合が期待される分布から大きく外れているため、これは健全でない状態です。 複雑に思えるかもしれませんが、実際には Database Insights を使えば視覚的に素早く把握できます。一貫した色の割り当てにより、通常の動作がどのようなものかをすぐに見分けられるようになります。もちろん、本番システムを適切に管理するには目視での確認だけでは不十分なため、自動アラームの設定をお勧めします。これらのアラームは、待機イベントごとの AAS の上限 / 下限のしきい値として CloudWatch で設定できます。より詳細な分析を行うには、生データに対してトレンドクエリを実行し、待機の分布を時系列で確認してください。 DSQL システム診断 AI スキル Agent Plugins for AWS の一部である databases-on-aws プラグインを使うと、DSQL システム診断のヘルスチェックが簡単になります。設定後は、さまざまな期間にわたって DSQL クラスターのパフォーマンスチェックをリクエストできます。これにより、CloudWatch MCP サーバーを使って選択した複数の期間の DASH データを分析するワークフローが起動します。エージェントにインストールすると、次のようなプロンプトを発行できます。 「us-east-1 の DSQL クラスターのパフォーマンスをチェックして、markdown レポートを作成して」 スキルはその後、履歴のベースラインと比較します。デフォルトでは、直近 1 時間、昨日の同じ時間帯、先週の同じ時間帯が対象ですが、次のようなプロンプトで変更できます。 「直近 4 時間のパフォーマンスをチェックして、先週の月曜日と比較して」 Markdown レポートの例は次のとおりです。 図 6: DSQL システム診断 AI スキルが生成した Markdown パフォーマンスレポートの例 このレポートの例では、さらに先の部分で、特定のクエリを実行計画が不適切な候補として指摘しています。 図 7: 実行計画が不適切な候補となるクエリを指摘するレポート 特定のクエリに問題がありそうな場合、スキルは SQL に特化した詳細な診断ワークフローを自動的に開始し、その SQL 文に関する診断情報を報告します。 まとめ DSQL の時間ベースの可観測性アプローチは、セッションがどこで時間を費やしているかを直感的に把握でき、観測結果をパフォーマンスの体感やコストに直接結びつけることができます。CloudWatch Database Insights による視覚的な概要把握、PromQL による DASH データの直接クエリ、DSQL スキルによる自動分析のいずれを使っても、ボトルネックのすばやい特定からクエリの最適化、DSQL クラスターの安定運用まで対応できるツールが揃っています。ぜひこれらのツールを活用して、DSQL クラスターのパフォーマンス改善に役立ててください。 著者について James Morle AWS のプリンシパルエンジニアで、Amazon Aurora DSQL に取り組んでいます。データベースのパフォーマンスとスケーラビリティに関する数十年の経験を持ち、世界最大級で最も要求の厳しいトランザクションデータベースシステムをいくつも構築してきました。開発者と運用者の双方にとってデータベースの可観測性を直感的で実用的なものにすることに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

本ブログは 2026 年 7 月 8 日に公開された AWS Blog “ The CISO’s guide to post-quantum mandates and migrations ” を翻訳したものです。 現在、十数の主要国・地域がポスト量子暗号 (PQC) の導入ガイダンスを公開しています。CISO であれば、既に移行計画をかなり進めており、最も難しい部分はアルゴリズムの変更そのものではないとご存じでしょう。リーダーシップにおける本当の課題は、大規模で複雑な組織全体で協調的な変革を推進することです。非対称暗号は、あらゆるプロトコル、あらゆるベンダー依存関係、そして目立たないところで鍵交換やデジタル署名を担っているあらゆるレガシーシステムに組み込まれているからです。このガイドでは、コンプライアンス期限を守りながら組織のセキュリティガバナンスをモダナイズするプログラムを実現する必要がある CISO、CTO、その他のシニアリーダー向けに、規制の背景と戦略的プレイブックを提供します。 多忙な経営層向けの概要 本記事の重要なポイントは次の 5 つです。 トップから始める。 暗号のモダナイゼーションを、明確なタイムラインと測定可能なマイルストーンを持つエンタープライズリスクの低減として位置づけ、取締役会レベルのスポンサーシップを確保します。この取り組みの責任を担い、優先順位付けの基準を設定し、事業部門横断でデリバリーを調整する中央集約型のプログラムオフィスを立ち上げます。 すべてをインベントリ化するのではなく、依存関係を分類する。 ワークロードレベルで理解すべきことは 3 つです。プロバイダーが代わりにアップグレードしてくれるもの、期限内にアップグレードされず置き換えが必要なもの、そして自組織が所有し直接対応しなければならないものです。移行範囲を削減する最速の方法は、可能な限り暗号の責任を最初のカテゴリ (プロバイダーが代わりにアップグレードしてくれるもの) に移すことです。 暗号テレメトリに投資する。 移行作業と並行して可視化の仕組みとモニタリングを整備します。この能力は不可欠ですが、移行の勢いを犠牲にしてはいけません。アルゴリズムの使用状況、PQC カバレッジ率、移行速度をワークロードレベルで追跡します。テレメトリは複数年にわたるプログラムを通じて取締役会のスポンサーシップを維持し、中央チームが優先順位を設定するためのフィードバックループを提供します。 一度きりのコンプライアンスではなく、俊敏性のために構築する。 目標は PQC を一度デプロイすることにとどまるべきではありません。暗号の移行は繰り返し発生する運用上の要件になるため、標準の進化に合わせてプロトコル、アルゴリズム、鍵長を切り替えられる組織的な体制を築きます。 セキュリティとガバナンスのモダナイゼーションとして扱う。 徹底したパッチ適用の規律、信頼性の高い 継続的インテグレーションと継続的デリバリー (CI/CD) 、自動化されたライフサイクル管理は、PQC 移行の後も長く活用できる能力です。これらは、脆弱性が発見されるまでの期間が数週間から数時間へと短縮される、AI によって加速された脅威に対応するために必要な能力と同じです。アルゴリズムをオンデマンドで切り替えられる組織は、AI 主導の新たなエクスプロイトに対するパッチ適用も可能です。 以下、プレイブックの全容を説明します。 グローバルな規制動向 2024 年 8 月、 NIST は、鍵カプセル化 (ML-KEM)、格子ベースのデジタル署名 (ML-DSA)、ハッシュベースの代替署名方式 (SLH-DSA) をカバーする最初の 3 つのポスト量子標準を公開しました。これらの標準は、ほとんどの国・地域が移行期限を設定する際に参照するベースラインとなっています。米国、欧州連合、英国、ドイツ、フランス、オーストラリア、カナダ、日本、韓国、インド、シンガポール、UAE はいずれも正式なガイダンスを公開しています。金融サービス業界の FS-ISAC や通信業界の GSMA のような業界団体も、独自の追加タイムラインを設けています。 これらのタイムラインは国・地域によって異なりますが、いずれも同じ方向を向いています。ほとんどの地域では、2027 年までに新規調達において PQC への対応準備を求めており、完全な移行の期限は業界や地域に応じて 2030～2035 年に設定されています。国境を越えて事業を展開する組織にとって、事業を行う各国・地域の具体的な要件に対応することは、コンプライアンスと競争上のポジショニングの両面で不可欠です。 Amazon Web Services (AWS) は、「 Migration to quantum-resistant cryptography 」ページの FAQ セクションで、地域ごとの規制と期限を詳しく整理して公開しています。 移行のスコープ設定 歴史的に見ると、暗号の移行は予想よりはるかに長い時間がかかってきました。SHA-1 の廃止は、最初に脆弱性が公表されてから主要なブラウザが最終的に拒否するまで、約 20 年を要しました。MD5、3DES、RC4 も、移行が急務であるという明確な技術的コンセンサスがあったにもかかわらず、組織の対応が遅いという同じパターンをたどりました。また、これらの移行は、現在利用できるモダンなクラウドインフラストラクチャ、自動化されたオーケストレーション、リアルタイムのテレメトリがない時代に行われました。これらの能力を活用する組織は、より速く移行しながら、同時に将来に備えたセキュリティ基盤を構築できます。 移行のスコープ設定という課題は、明確に 2 つの系統に分かれます。1 つ目は、TLS、IPsec、SSH のような有効期間の短い認証プロトコルまたは暗号化プロトコルの一部としてアルゴリズムをネゴシエートするソフトウェアシステムです。これらのワークロードについては、クラウド中心のライフサイクル管理、自動パッチ適用、集中化されたライブラリのアップグレードにより、過去の暗号移行よりも容易になっています。マネージドサービスは透過的にアップグレードを処理でき、テレメトリツールによってエンドポイント全体のアルゴリズム使用状況をリアルタイムで可視化できます。CI/CD パイプラインを使用すれば、確実なロールバック経路を確保しながら段階的なロールアウトが可能です。モダンなクラウドインフラストラクチャを持つ組織にとって、暗号移行のこの側面を高速に実行できる環境は、かつてないほど整っています。 移行対象の 2 つ目の系統は、長期間使用される組み込みシステムです。これは、鍵とアルゴリズムのコードを含むファームウェアが書き込まれ、その場でのアップデートができないデバイスです。この対象範囲を削減する最速の方法は、暗号ワークロードをマネージドサービスにオフロードすることです。これにより、プロバイダーがハードウェアの更新サイクルを引き受け、移行したワークロードの分だけ計画対象のデバイスが減ります。専用ハードウェア上に残るものについては、年次の設備投資 (capex) レビューに量子への備えを組み込みます。量子技術の進歩は決まったスケジュールで訪れるわけではないため、量子ハードウェアの進展に照らして、組み込みの暗号資産を毎年評価してください。運用上問題なく何年も使えるデバイスもあれば、脅威が現実化するまでの期間が短くなるにつれて置き換えの前倒しが必要になるデバイスもあります。年次評価を行うことで、早期の廃止は予算外の緊急事態ではなく、計画されたビジネス上の意思決定になります。 戦略的プレイブック 以下のプレイブックは、組織の状況に合わせて適用できる PQC 移行への戦略的アプローチの概要です。各ステップは、企業全体の足並みをそろえ、不明確な点を実行可能なフレームワークで解消し、プログラムへの予算確保と計画どおりの進行を維持するための測定可能な進捗を実現するように設計されています。 取締役会レベルのコミットメントを確保する CISO は、格子ベースのアルゴリズムに関する技術説明としてではなく、規制コンプライアンスと競争上のリスクに紐づくビジネスリスクの議論として、PQC を取締役会に提起する必要があります。その際には、誤解を正すことが重要です。取締役会レベルでよくある誤解の 1 つは、PQC 移行には保管中のすべてのデータの再暗号化が必要だというものです。これは事実ではありません。標準の 256 ビット対称暗号で暗号化された保管中のデータは、量子コンピュータに対して脆弱ではありません。この区別は実際の変更範囲を大幅に絞り込むものであり、スコープを過大に設定することを防ぐため、早い段階で伝えるべきです。 規制のタイムラインは具体的に提示してください。例えば、 CNSA 2.0 が 2027 年 1 月までに新製品での PQC 採用を義務付けていること、そしてこれらのタイムラインが金融サービス、ヘルスケア、政府、防衛といった規制対象の業種では調達の関門として機能することを説明します。また、規制対象の業種に属する売上とワークロードをマッピングすることで、組織のリスクエクスポージャーを定量化できます。例えば、公共部門の顧客との既存契約や進行中の商談を、リスクにさらされているビジネスの定量的なデータとして活用できます。 これを実践するとどのようになるか、例を示します。1 つ目に、規制対象の業種において、PQC コンプライアンスの文言が既に含まれている、または更新時に含まれる見込みの既存契約を特定します。それに紐づく売上を計算し、18 か月以内の更新日をコンプライアンスクリフ (期限切迫リスク) として洗い出します。2 つ目に、進行中のパイプラインを確認します。PQC への対応準備を既に参照している RFP、ベンダーアンケート、調達要件はありますか? 自組織がコンプライアンスを実証できず、競合他社が実証できる場合、そのパイプラインの価値は、選定対象から除外されるリスクにさらされます。3 つ目に、規制が発効しつつある業種における獲得可能な市場機会の総額を算定し、準備ができていなければどの程度の市場を取り逃すことになるかを示します。顧客がベンダー契約に PQC への対応準備要件を盛り込むようになっている中、コンプライアンスを実証できない組織は、将来のビジネスで選定対象から除外されるリスクがあります。 最後に、取締役会レベルのスポンサーシップのもとで、専任の人員とベンダー予算を要求します。これは既存のセキュリティ運用に吸収されるサイドプロジェクトであってはなりません。四半期ごとに定量的な成果をリーダーシップレベルで追跡する経営層レビューを優先してください。 専任の移行リーダーを任命する セキュリティ、エンジニアリング、コンプライアンス、調達にまたがる部門横断的な責任範囲を持つ暗号のセンターオブエクセレンス (CoE) を立ち上げます。プログラム全体をエンドツーエンドで所有し、経営層に直接報告する移行リーダーを任命します。PQC はネットワーキング、アイデンティティ、アプリケーション開発、ベンダー管理、コンプライアンスのすべてに同時に影響するため、これらの領域から代表者を集めてチームを構成してください。 このチームに、暗号ポリシー、ライブラリの使用、移行タイムラインに関する組織標準を設定する権限を与えます。また、同チームにベンダーやサプライヤーとの連携機能を持たせ、PQC への対応準備に関するクラウドプロバイダーやサードパーティベンダーとの関係を、責任を持つ 1 つのチームが推進できるようにします。 このチームに資金を投じ、各事業部門がゼロから作り直すのではなく再利用できる、中央集約型の対応パターンの整備を推進する役割を持たせてください。同チームが、リファレンス実装、承認済みのライブラリバージョン、テストフレームワーク、ロールアウトプレイブックを所有します。あるチームが特定のワークロードタイプの移行パターンを解決したら、中央チームがそのソリューションをパッケージ化し、組織内のすべての類似ワークロードに展開します。 依存関係を分類し、移行対象範囲を削減する 明示的に義務付けられている国・地域を除き、ボトムアップの包括的な暗号インベントリを推奨するガイダンスには注意してください。その作業は数か月を費やし、実際の移行を遅らせる可能性があります。代わりに、依存関係を 3 つのカテゴリに分類します。 他者が代わりにアップグレードしてくれるワークロード。マネージドクラウドサービス、 Software as a Service (SaaS) プロバイダー、および PQC ロードマップを積極的に進めているインフラストラクチャベンダーがここに該当します。自組織の役割は、プロバイダーのタイムラインを検証し、確実に履行されるようにすることです。 他者がスタックを所有しているが、期限内にアップグレードされないワークロード。これらは置き換えが必要なベンダー依存関係であり、計画上の耐用年数が終わる前に置き換える可能性もあります。置き換えの意思決定を調達や設備投資のサイクルに早期に組み込めるよう、今すぐ洗い出してください。 自組織が所有し、自らアップグレードしなければならないワークロード。これらについては、その場でアップグレードするか、暗号レイヤーがマネージドになるクラウドへモダナイズするかを判断します。 最初の 2 つのカテゴリはベンダーリスク評価プログラムの範疇です。3 つ目のカテゴリが、自組織内で管理し、逆算スケジュールで完了まで推進すべきワークストリームです。どの依存関係が検証済みか、どの置き換えが進行中か、自己管理のスタックのうちどれにアップグレード計画があるかを追跡します。この 3 カテゴリモデルは、際限のない棚卸し作業に陥ることなく、中央チームに明確な意思決定フレームワークを提供します。 オブザーバビリティを構築し、進捗を継続的にモニタリングする 暗号の状況を可視化することは、計画、実行、そして監査人へのコンプライアンス実証に不可欠です。ただし、オブザーバビリティをワークロード移行の前提条件にすべきではなく、移行の勢いを犠牲にしないよう、並行するワークストリームとして捉えるべきです。可視化ツールが整備された後は、それまでに完了したすべての作業を遡って示すとともに、組織レベルの進捗をリアルタイムで把握できるようになります。 多くの組織は TLS から着手します。TLS は通常、最も広範に展開された暗号であり、ウェブアプリケーション、API、マイクロサービス全体で転送中の機密データを保護する主要なメカニズムだからです。サービスログのメタデータフィールドを使ってポスト量子と従来型の TLS トラフィックを区別し、すべてのエンドポイントにわたるアルゴリズム使用状況を示す TLS メトリクスダッシュボードの構築を推進してください。「 AWS Config を使用したポスト量子暗号 (PQC) 対応の自動化 」で紹介している PQC Readiness Scanner は、この種の可視化ツールを構築・デプロイする方法の一例です。時間の経過とともに、同じオブザーバビリティを IPsec、SFTP、SSH などの他のトランスポートプロトコルにも拡張します。 全社共通の KPI を設定した継続的な評価プログラムを確立し、その結果を経営層レビューに反映できるようにしてください。テレメトリは棚卸しに役立つだけでなく、複数年にわたるプログラムを通じて取締役会のスポンサーシップを維持するための、経営層レベルの進捗メトリクスも提供します。いくつかの例を挙げます。 TLS 1.3 と ML-KEM 鍵交換を使用している TLS 接続の割合 定義したカテゴリ全体での PQC カバレッジ率 検証済みのベンダータイムラインと未確認のものの比率 新しい依存関係が非準拠として検出されてから修復までの時間 PQC カバレッジ率をワークロードレベルおよび組織レベルで追跡してください。これらのメトリクスにより、PQC 移行は一度きりのプロジェクトから継続的なガバナンス機能へと変わります。パッチ適用サイクル、脆弱性 SLA、コンプライアンス状況を既に管理しているのと同じ形です。目標は、将来の暗号移行を、そのたびに新しいプログラムを立ち上げるのではなく、日常的な運用作業として吸収できる恒常的な能力を育てることです。 ベンダー、規制当局、業界団体と連携する PQC 移行は組織の境界を越えるものであり、サプライチェーン全体での協調した動きが必要です。クラウドプロバイダーと PQC ロードマップについて対話し、どのサービスが既に PQ-TLS をサポートしているか、どれがロードマップにあるか、いつサポートが見込まれるかを把握してください。サードパーティのソフトウェアベンダーや SaaS プロバイダーに対しては、PQC サポートのタイムラインについて明確な質問を投げかけ、今後は調達要件やベンダー契約に PQC への対応準備を盛り込んでください。 自組織が属する国・地域の規制当局や標準化団体と連携し、自組織の業界に適用される具体的なタイムライン、コンプライアンスの仕組み、監査の期待事項を把握してください。金融サービス、通信、ヘルスケア、重要インフラにはそれぞれセクター固有の PQC ワーキンググループがあり、同業組織がアプローチや教訓を共有しているため、業界フォーラムにも参加してください。この協調的なアプローチは、社内に消極的なステークホルダーがいる場合に、移行に必要な投資を獲得する助けにもなります。 所有するワークロードの優先順位を付けてロードマップを策定する すべてを一度に移行しようとするのではなく、段階的なアプローチを採用してください。リスクとユースケースに基づいてワークロードの優先順位を付けます。「 AWS ポスト量子暗号への移行計画 」ブログ記事に、この優先順位付けの例が紹介されています。ロードマップの実行にあたっては、あらゆる段階で信頼性の高いリリースとロールバックの仕組みを構築してください。PQC アルゴリズムはパフォーマンスやサイズの特性が異なるため、本番環境の負荷下で予期しない挙動が現れる可能性があります。レガシーな依存関係が移行の障害になる前に特定してください。カスタム TLS ライブラリやハードコードされた暗号スイートを使用しているシステムは、プロセスの早い段階で洗い出しておく必要があります。 PQC の対象範囲を削減する最速の方法は、カスタムの暗号スタックを完全に排除することです。マネージドサービスに移行したワークロードの分だけ、チームが手動でアップグレードしなければならないワークロードが減ります。AWS は既に、パフォーマンスへの影響を体感できないほど抑えつつ、複数のサービスエンドポイントでポスト量子鍵交換を提供しており、 AWS Key Management Service (AWS KMS) と AWS Private Certificate Authority を通じてポスト量子署名も提供しています。クラウドのコンピューティング環境やオンプレミス環境の独自コードについては、 AWS-LC のようなオープンソースの暗号ライブラリが、本番利用可能で FIPS 140-3 検証済みの PQC 実装を提供しており、チームは今すぐ採用できます。 クリプトアジリティを備えた企業へ移行する クリプトアジリティ (暗号の俊敏性) とは、アルゴリズムの切り替え、プロトコルの更新、暗号の変更を、専用プログラムとしてではなく通常業務として吸収できる運用能力です。暗号標準は今後も進化し続けます。アルゴリズムは廃止され、置き換えられていきます。この能力を今のうちに構築した組織は、次回の移行時に新たなプログラムを必要としません。 クリプトアジリティには、4 つの分野での卓越性が求められます。 パッチ適用とアップグレードの規律: 現在、フリート全体で一貫したパッチ適用サイクルを維持できていない場合、PQC 移行はそのギャップをエンタープライズ規模で顕在化させます。成熟した脆弱性管理プログラムは、既存の運用の自然な延長として PQC を取り入れます。 確実なロールバックを伴う段階的リリース: PQ アルゴリズムは署名と鍵のサイズが大きく、パフォーマンスプロファイルも異なります。変更を段階的にデプロイし、本番環境で挙動を検証し、想定どおりに動作しない場合に確実にロールバックできる必要があります。 一貫した CI/CD パイプライン: 非対称暗号に触れるすべてのアプリケーションは評価が必要で、場合によっては更新されたアルゴリズムやライブラリで再構築・再デプロイが必要になります。不安定なデプロイプロセスや手動のデプロイプロセスは、移行全体の妨げになります。 自動化されたセキュリティライフサイクル管理: 証明書のライフサイクル、鍵のローテーション、シークレットの保管、署名操作、コンプライアンス検証は、すべてマシンスピードで動作しなければなりません。現在は機能している手動プロセスも、セキュリティ要件が進化するにつれて破綻します。 これらは必ずしも PQC 固有の投資ではありません。適切に運営されているセキュリティ組織の基盤となる能力です。AI によって脆弱性の発見と悪用の速度が加速する中、クリプトアジリティを運用体制に組み込んでいる組織は、AI によって加速された脅威への対応において有利な立場にあります。優れたセキュリティリーダーは、脅威の状況が進化する中で組織に必要な運用上のレジリエンスを構築する契機として、PQC を活用できます。 まとめ PQC 移行は、次世代のエンタープライズセキュリティプログラムがどのように構築され、測定されるかを決定づけるものになります。過去のどの暗号移行よりも速くこの移行を実行するための技術ツールは既に存在します。今行動する組織は調達要件を形作り、業界の競争基準を設定することになります。先送りする組織は、タイムラインの圧縮、コストの増加、選択肢の減少に直面することになります。 AWS は、PQC 移行のプロセスを進めるお客様を支援します。最新のガイダンスと資料は「 Migration to quantum-resistant cryptography 」でご覧いただけます。 AWS Security Assurance Services と AWS プロフェッショナルサービス は、お客様自身のアプリケーションとワークロードのアップグレードを支援する専門的なガイダンスと、検証済みの実装アプローチを提供します。まずは、無料の Post-Quantum Readiness Accelerator の紹介ミーティング をリクエストできます。 Rushir Patel Rushir は AWS でワールドワイドのデータ保護ビジネス開発を率いており、AWS の暗号、アイデンティティ、データ保護サービスの市場開拓戦略を推進しています。サイバーセキュリティ、クラウド、AI で 15 年以上の経験を持ち、コーポレートファイナンスと電気工学のバックグラウンドがあります。仕事以外では、ガーデニング、スキー、ワイン、旅行を楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 8 月 11 日に公開された AWS Blog “ Accelerate cyber defense with OpenAI and AWS: Daybreak Red & Daybreak Blue now available to eligible customers on Amazon Bedrock ” を翻訳したものです。 サイバー防御者がこれほど多くの能力を手にしたことはありません。そして、その能力がこれほど必要とされたこともありません。フロンティアモデルは、コードベース全体にわたって推論を行い、脆弱性を根本原因まで追跡し、数分で修正案を提案できるようになりました。しかし、同じ能力は攻撃者も利用できます。そのため、脆弱性が開示されてから悪用されるまでの期間はますます短くなっています。防御者は、広範囲に及ぶ不慣れなコードベースでも後れを取らずに対応し、どの検出結果が重要かを検証し、確実に機能するパッチをリリースすることが求められます。しかもこれらすべてを、機密性の高いコードや脆弱性データを自らが管理・監査できる環境内に保持したまま行わなければなりません。もはや課題は潜在的な問題を見つけることではなく、どれが本当の問題かを見極めて修正し、その対応を攻撃者に悪用される前の限られた時間内に完了させることにあります。 AWS は、セキュリティを最初から組み込むという原則に基づいて一貫して事業を行ってきました。これは AI についても同様です。お客様は、推論から完全自律型のエージェントまで、さまざまなワークロードを Amazon Bedrock で実行しています。そこに適用されるインフラストラクチャ、コントロール、ガバナンスは、お客様が AWS 全体で信頼して利用しているものと同じです。本日 (2026 年 8 月 11 日)、AWS と OpenAI は、この基盤をサイバー防御にも広げます。OpenAI の Daybreak Red と Daybreak Blue を、対象のお客様向けに Amazon Bedrock で提供開始しました。Daybreak Red は、サイバーセキュリティ専用にトレーニングされたモデルである GPT-5.6 Cyber へのアクセスを提供します。Daybreak Blue は、安全対策を防御的なサイバーセキュリティ業務向けに調整した GPT-5.6 Sol へのアクセスを提供します (訳注: 一般提供されている GPT-5.6 Sol とは提供形態が異なり、利用には後述の Trusted Access for Cyber への登録が必要です)。どちらも、OpenAI のサイバー防御イニシアチブである Daybreak の一部であり、防御者にフロンティア AI への統制されたアクセスを提供します。Daybreak には、エージェント型ツール、アプリケーションのレッドチーム演習、検出結果から検証済みの修正へと進むための支援サービスが含まれます。 「AWS と OpenAI は、防御者が優位に立つべきだという考えを共有しています。この提携により、OpenAI の Daybreak Red と Daybreak Blue を Amazon Bedrock で提供します。AWS のセキュリティチームは現在、両方のモデルを使用してソースコードの分析、脆弱性の発見、レッドチームの調査を行っています。Amazon Bedrock 上でのこの作業は、AWS が他のすべての重要なワークロードに適用しているのと同じインフラストラクチャコントロールのもとで実行されます。これらのモデルが進化を続けるにつれて、防御者が Amazon Bedrock 上でこれらのモデルを使ってできることも進化していくでしょう」 — AWS Security Vice President John Sheehan 許可を得た高度なサイバーセキュリティ業務向けの専用モデル 脆弱性の発見から修正までの道のりは長いものです。悪用可能性の確認、脆弱なコンポーネントへの到達経路の追跡、リグレッションを引き起こさずに根本原因に対応する修正の開発、現実的な条件下でその修正が機能することの検証、そして開示後の限られた期間内でのパッチのリリースが必要です。防御者には、これらすべてのステップを加速できるモデルが必要です。しかし、サイバーセキュリティは本質的にデュアルユース (防御にも攻撃にも利用可能) です。脆弱性の再現やエクスプロイトチェーンのリバースエンジニアリングを求めるリクエストは、意図の善悪にかかわらず同じように見えるため、汎用モデルはリクエストを拒否することでこの曖昧さを解消します。Daybreak Red と Daybreak Blue は、誰がモデルを使用しているのか、作業がどこで行われるのか、そのアクセスをどのような安全対策が管理しているのか、というコンテキストによってこの問題を解決します。 ほとんどのセキュリティチームにとって、Daybreak Blue が適切な出発点になります。Daybreak Blue は、脆弱性の発見、検出エンジニアリング、インシデント対応をサポートします。Daybreak Red は、脆弱性調査、エクスプロイトの再現、対策の開発といった高度なタスク向けに設計されています。これらのタスクでは、拒否しきい値 (モデルがリクエストを拒否する基準) を下げつつ、それに見合った強力な本人確認、モニタリング、アクセスコントロールを組み合わせることで、調査のスピードと深さを高められます。 OpenAI によると、セキュリティ研究者は Daybreak Red を通じて GPT-5.6 Cyber を使用し、Chrome で使用されている JavaScript エンジンである V8 において、これまで知られていなかった 2 つの脆弱性を特定しました。これらを連鎖させると、メモリ破壊とヒープサンドボックスエスケープを引き起こす可能性がありました。最初の脆弱性は修正され、CVE-2026-15903 として公開されました。これは、2026 年に V8 CTF で成功したわずか 4 件のゼロデイエントリのうちの 1 つです。 すでに信頼している基盤の上で実行 サイバーセキュリティのワークロードでは、独自のソースコード、未修正の脆弱性の詳細、本番システムからのライブテレメトリといった、最も機密性の高い情報をモデルに入力します。これらの情報がモデルを通過する前に、それがどこに送られ、誰が見ることができるのかを確実に把握しておく必要があります。 両モデルは、高いパフォーマンス、セキュリティ、信頼性を実現するために構築された Amazon Bedrock の次世代推論エンジン上で動作します。ゼロオペレーターアクセス (ZOA) はチップレベルで強制されるため、AWS のオペレーターであっても推論中のプロンプトや出力にアクセスすることはできません。データは転送中および保管中に暗号化されます。アクセスは AWS Identity and Access Management (IAM) ポリシーによって管理され、AWS CloudTrail に記録され、仮想プライベートクラウド (VPC) エンドポイントを経由します。組織レベルでデータ境界ポリシーを設定することで、アカウントやネットワークの境界を越えたデータの流出を防ぐことができます。 推論データはモデルトレーニングに使用されず、どちらのモデルでも OpenAI とのデータ共有にオプトインする必要はありません。 自動不正使用検出 のために、分類器によってフラグが付けられたトラフィックは AWS によって最大 30 日間保持され、プログラムによって処理されます。これらのモデルでゼロデータ保持を必要とする場合は、AWS アカウントチームを通じてリクエストできます。詳細については データ保持 を参照してください。 利用開始方法 Daybreak Red: GPT-5.6 Cyber と Daybreak Blue: GPT-5.6 Sol を、次の AWS リージョン の Amazon Bedrock で、対象のお客様向けに提供開始しました: 米国東部 (オハイオ)。これらのモデルを利用するには、OpenAI の Trusted Access for Cyber への登録が必要です。登録するには、OpenAI にご連絡いただくか、対象条件については AWS アカウントチームにお問い合わせください。承認された後は、AWS アカウントチームと連携して AWS 側でアクセスをリクエストしてください。詳細については、 ドキュメント を参照してください。 Amazon Bedrock 上の GPT-5.6 ファミリー全体の詳細については、「 Get started with OpenAI GPT-5.6 Sol, Terra, and Luna on Amazon Bedrock 」を参照してください。 Amazon Bedrock がお客様をどのように支援できるかにご興味がある方は、 お問い合わせ ください。 著者について Tanvi Girinath Tanvi は Amazon Web Services (AWS) で Amazon Bedrock を担当するプロダクトマーケティングマネージャーです。お客様が Amazon Bedrock を使用して AI アプリケーションやエージェントを導入し、スケールするための支援を行っています。 Saurabh Trikande Saurabh は Amazon Web Services (AWS) で Amazon Bedrock を担当するシニアプロダクトマネージャーです。主要プロバイダーのフロンティアモデルによる推論を、あらゆる規模のお客様にとってパフォーマンス、セキュリティ、コスト効率に優れたものにする取り組みを主導しています。 Chris Dickens Chris は OpenAI の Member of Product Staff として OpenAI API を担当しています。Amazon Bedrock における AWS との連携にも取り組んでおり、OpenAI のフロンティアモデルを開発者が広く利用できるようにする活動を行っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

AWS では、AI を活用した新しいソフトウェア開発手法「 AI-DLC（AI-Driven Development Life Cycle） 」を提唱しています。AI-DLC は、AI を単なる補助ツールとしてではなく、要件定義から設計・実装・テストまでの開発ライフサイクル全体に組み込みながら、人間が主導権を握る（Human-in-the-Loop）ことを前提とした開発手法です。この AI-DLC を短期間で体験・実践いただくワークショップが「AI-DLC Unicorn Gym（以下 UG）」です。 2026 年 6 月 11 日〜12 日、株式会社サンリオ デジタル事業開発部の皆様と 2 日間の「サンリオ AI-DLC UG」を開催しました。本記事では、開催レポートと、参加メンバーの皆様に体験を語っていただいた座談会の様子をお届けします。 1. サンリオ AI-DLC Unicorn Gym 開催レポート サンリオ AI-DLC Unicorn Gym 参加メンバー サンリオのデジタル事業開発部は、「キャラフォリオ」（公式とファンがつながる創作プラットフォーム）や「オモイデバッジ」（イベント参加記録・ユーザー交流 SNS）など、デジタルプロダクトの企画・開発を担っています。2025 年から開発の内製化に舵を切り、少数精鋭のチームで Claude Code を中心とした AI 活用開発を実践してきました。個人の生産性向上の先にある「チームとして、上流工程からどう AI を組み込むか」という課題への答えを求めて AI-DLC に着目されたことが、今回の開催のきっかけです。 当日はデジタル事業開発部 プロダクト開発課 シニアマネージャー 倉井 龍太郎 氏をはじめとする 2 チーム 6 名のエンジニアとプロダクトマネージャーが参加し、実際のプロダクトを題材に AI-DLC の全フェーズを体験しました。ツールには Kiro を利用し、AI エージェントを中心に据えた開発ワークフローを実践しています。AWS 側はアカウントマネージャーの荻原 賢大、ソリューションアーキテクトの山澤 良介・瀧田 直斗が各チームに伴走しました。 チーム テーマ 技術構成 成果 チーム A （オモイデバッジ） オモイデバッジ 管理機能拡張 — パッケージ詳細への URL リンク設置 TypeScript / Kiro inception から本番マージまで 約 5 時間 で完了。デプロイ済み。 チーム B （新規アプリ） 新規アプリの立ち上げ TypeScript / Kiro 管理者向け管理画面まで構築完了 チーム A の成果 — 「作らない」判断と、約 5 時間での本番マージ チーム A では 2 つのユーザーストーリーを検討しました。1 つ目は、AI と一緒に価値と実現方法を掘り下げた結果「機能を実装しなくても運用でカバーできる」と判断し、あえて実装しないことを選択。AI で実装が速くなるほど「何を作らないか」の判断に価値が生まれることを示す成果となりました。 2 つ目のストーリー「パッケージ詳細への URL リンク設置」では、AI-DLC の全フェーズを一気通貫で体験しました。 時刻 フェーズ 内容 Day 2 10:59 Inception インタビュー型の add-inception スキルを作成 Day 2 13:59 Inception AI のインタビューを受けて inception ドキュメントを作成・マージ Day 2 15:03 Construction 既存の設計スキルで設計書を作成し、自律実装へ Day 2 15:58 マージ backend / API / 管理画面 / アプリの実装をマージ inception 開始から本番マージまで 約 5 時間 2. 座談会 — 参加メンバーに聞く 荻原（AWS） 今回の AI-DLC UG が実現した経緯を教えてください。 倉井氏（サンリオ） 日頃から Claude Code を使って開発していましたが、個人の生産性は上がっても「チームとして、上流工程からどう AI を組み込むか」がずっと課題でした。AWS の AI-DLC のブログを見つけたとき、まさにこれだと思って、すぐにミーティングで相談しました。 荻原（AWS） AI にインタビューされながらユーザーストーリーを作るプロセスはどうでしたか。 チーム A メンバー（サンリオ） 「何を・誰に・どんな価値を・どう検証するか」を AI が順番に聞いてくれるので、抜け漏れを防げました。価値のコンフリクトや成功指標など、一人では飛ばしがちな観点を確実に通過できたのが大きいです。またインタビューをスキル化し、改善ステップも組み込んだので、誰がやっても同じ品質のインセプションプロセスを踏めるようになりました。 荻原（AWS） AI-DLC を体験したことで、今後の開発にどう活かしていきたいですか。 倉井氏（サンリオ） 大きく 2 つあります。1 つ目は、インセプションプロセスで言語化することで、企画側の目的をしっかり理解した上で開発が進められ、手戻りを大幅に減らせること。2 つ目は、ユーザーストーリーを書くことでプロジェクトメンバー全員が同じ情報を持った上で開発が進むことです。非常にスムーズでした。 チーム A メンバー（サンリオ） 今後は実際の開発フローに PM の作業も組み込みたいと考えています。PM・エンジニアの「作業」をエージェントに任せて、人間は設計とレビューに専念する — それが目指す姿です。 倉井氏（サンリオ） 内製化を進める中で「少人数でいかに大きな価値を届けるか」が常に課題です。AI-DLC はそのための方法論として非常に手応えを感じました。AI-DLC の旅はまだ始まったばかりです。 3. 今後の展開と AWS の支援 サンリオ デジタル事業開発部では、今回の UG で得た知見を実プロダクト開発に本格導入していく予定です。 Inception の標準化 — 今回作成したインタビュー型スキルをチーム標準プロセスとして運用開始 「人間は設計とレビュー」モデルの実践 — AI が実行し、人間が監視・判断する AI-DLC の本質を日常の開発に浸透させる ワークショップを運営して感じたのは、AI-DLC の Inception フェーズが Amazon の Working Backwards （お客様の体験から逆算して考える手法）と本質を同じくする、ということです。「誰に・どんな価値を・なぜ届けるのか」を AI のインタビューに答えながら言語化し、チーム全員で合意する。AI が「問い」を投げかけることで議論の抜け漏れが構造的に防げるため、経験の浅いチームでも質の高い要件定義ができるようになります。 AWS は、サンリオの AI 活用パートナーとして、UG で作成したスキルの実プロダクトへの適用と AI 駆動開発の定着を引き続き支援してまいります。倉井氏をはじめ、ご参加いただいた皆様、ありがとうございました。 本記事は、2026 年 6 月 11 日〜12 日に開催した「サンリオ AI-DLC Unicorn Gym」および参加メンバーの皆様との座談会をもとに構成しました。 著者プロフィール 荻原 賢大 アマゾン ウェブ サービス ジャパン合同会社 営業部 広域事業部門。株式会社サンリオを担当するアカウントマネージャー。お客様のビジネス変革を技術で支援することに情熱を注いでいます。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への展開にも取り組んでいます。 山澤 良介 AWS のソリューションアーキテクトとして、製造業を中心にエンタープライズ企業の支援をしています。その活動の傍ら、最近は Claude Code / Cowork の国内展開に向けた技術支援やコンテンツ作成に取り組んでいます。

本記事は 2026 年 8 月 20 日 に公開された「 Long-term system tables retention in Amazon Redshift with Amazon S3 Tables 」を翻訳したものです。 Amazon Redshift のシステムテーブルは、実行されたすべてのクエリ、確立されたすべての接続といった運用シグナルを継続的に記録します。収集したデータは、データウェアハウス全体の可観測性、パフォーマンス分析、コンプライアンス監査を支えます。しかしこれまで、システムテーブルがこの重要なデータを保持できる期間はわずか 7 日間で、独自の回避策なしに長期的なコンプライアンス対応や監査を行うのは困難でした。 Amazon Simple Storage Service ( Amazon S3 ) の機能である Amazon S3 Tables と Amazon Redshift システムテーブル の統合により、システムテーブルのログデータが自動的に Amazon S3 Tables に配信され、 Apache Iceberg 形式で保存されます。Amazon Redshift システムテーブルの保持期間を現在の 7 日間の上限を超えて設定でき、独自の ETL パイプラインやクラスターリソースを消費することなく、コンプライアンス対応、監査、ウェアハウス横断の可観測性を長期にわたって実現できます。データはオープンかつ堅牢で、Amazon Redshift、 Amazon Athena 、 AWS Glue 、 Amazon EMR 、その他の Apache Iceberg 対応エンジンからクエリできます。 本記事では、Amazon Redshift システムテーブルの統合がどのようにログデータを Amazon S3 Tables に配信するのかを解説します。本機能は、RA3 および RG のプロビジョンドクラスターと Amazon Redshift Serverless ワークグループでサポートされています。 課題 Amazon Redshift を運用していると、システムテーブルの保持期間が 7 日間に制限されていることに起因する運用上の課題によく直面します。 クエリの傾向が把握しにくい: 同じクエリの 30 日前と現在のパフォーマンスを比較したいことがあります。パフォーマンスが徐々に変化する場合、長期的なベースラインがあれば、場当たり的なトラブルシューティングではなく、データに基づいた根本原因分析が可能になります。 変更前後の比較: 新しいワークロードの追加、インスタンスタイプの変更、 Workload Management (WLM) キューの調整を行う際には、その影響を正確に測定したくなります。保持期間を延長すれば、必要なベースラインデータを残しておけます。 季節性を考慮したキャパシティプランニング: 月末のスパイク、四半期末の急増、年間のピークを把握して計画するには、数か月分の履歴データが必要です。保持期間を延長すると、数か月から数年にわたる季節的なパターンが見えてきます。 独自 ETL パイプラインの負荷: 保持期間の制限を回避するため、システムテーブルのデータを 1 時間ごとまたは 1 日ごとに Amazon Redshift マネージドストレージ内の永続テーブルにコピーする独自パイプラインを構築するチームもあります。こうしたパイプラインはクラスターリソースを消費し、本番ワークロードと競合し、継続的なエンジニアリング保守を必要とします。Amazon Redshift がシステムテーブルのスキーマやデータ共有の設定を更新すると、パイプラインには手作業での対応が必要になり、記録に欠落が生じます。 コンプライアンス要件: 規制対象の業界では、数か月から数年に及ぶ監査証跡の保持が求められます。7 日間の上限のもとでこの要件を満たすには、独自のインフラが必要でした。Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、この課題が解決されます。 仕組み Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、Amazon Redshift システムテーブルのデータを Apache Iceberg 形式で自動的に Amazon S3 テーブルに書き込むフルマネージド機能です。パーティショニング、圧縮、保持期間の管理は AWS が自動的に処理します。ログの書き込み処理は独立したバックグラウンドプロセスで実行され、本番ワークロードとのリソース競合を抑えます。パイプラインの管理は AWS が代行します。 本機能はリリース時点で 25 を超えるシステムビューをサポートしています。サポート対象のシステムビューについては ドキュメント を参照してください。 セットアップ Amazon Redshift コンソールから Amazon S3 Tables とのシステムテーブル統合を有効にするには、次の手順に従います。 Amazon Redshift コンソールを開き、[System table integrations] ページに移動します。プロビジョンドクラスターまたは Serverless ワークグループの詳細ページからもアクセスできます。 Create System table integration を選択します。設定ウィザードが起動します。 本機能を有効にする Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループを選択します。   図 1: システムテーブル統合ウィザードでの Amazon Redshift データウェアハウスの選択 Available system tables リストから公開するシステムビューを選択します。個々の SYS_* ビューを選ぶか、 Select all supported system tables を選択して、現在および将来サポートされるすべてのビューを公開します。すべてを選択した場合、将来追加される新しいビューは設定を変更しなくても自動的に含まれます。   図 2: [Available system tables] リストから公開するシステムビューを選択 デプロイモデルを選択します。Amazon S3 Tables でのデータの整理方法を選びます。 データウェアハウスごと・システムテーブルごとに個別の S3 テーブル : 各ウェアハウスのデータを専用のテーブル群に保持します。 データウェアハウス横断でシステムテーブルごとに共有の S3 テーブル : アカウント内の複数のウェアハウスのデータを共有のテーブル群に集約します。 必要に応じて、AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで暗号化を設定します。デフォルトでは、データは Amazon S3 マネージドキー (SSE-S3) で暗号化されます。 変更を保存します。Amazon Redshift は選択したビューの Amazon S3 Tables への公開を開始し、一定の間隔で新しいレコードを追加し続けます。 統合が有効になっているかを確認するには、次のようにします。 クラスターまたはワークグループの詳細ページに移動します。 統合のステータスと、各ビューの最終取り込み時刻を確認します。 公開されたデータは Amazon S3 Tables コンソールからも確認できます。 有効化すると、Amazon Redshift は本番ワークロードとは別の独立したバックグラウンドプロセスを通じて、定期的にログデータを Amazon S3 テーブルに書き込みます。保持されたログのクエリを開始するには、AWS Glue Catalog を介して Amazon Redshift 環境と Amazon S3 Tables のデータを接続する初回セットアップが必要です。次の手順を実行します。 AWS Glue Data Catalog と Amazon S3 Tables へのアクセスに必要な権限を持つ AWS Identity and Access Management (IAM) ロールを作成し、Amazon Redshift クラスターまたは Amazon Redshift サーバーレスネームスペースに関連付けます。 AWS Glue Data Catalog で、ログが格納されている Amazon S3 Tables データベースを指すリソースリンクを作成します。 Amazon Redshift で、リソースリンクを参照する外部スキーマを作成します。 CREATE EXTERNAL SCHEMA <schema_name> FROM DATA CATALOG DATABASE '<resource_link_database>' IAM_ROLE '<iam_role_arn>'; 設定が完了すると、使い慣れた 2 部構成の表記法で過去のシステムテーブルデータをクエリできます。 SELECT * FROM <schema_name>.<table_name>; Amazon S3 Tables へのアクセスは読み取り専用のため、監査証跡の整合性は本質的に保たれます。 IAM ポリシーの例を含む詳細なセットアップ手順については、 S3 Tables と Data Catalog の統合の有効化 を参照してください。 データは Apache Iceberg 形式で保存される システムテーブルのデータは、オープンテーブル形式である Apache Iceberg で保存されるため、互換性のあるクエリエンジンを自由に選べます。可観測性や監査のデータを、すでに使っているツールでそのまま扱えます。 運用データは次のサービスで分析できます。 Amazon Redshift: S3 テーブルバケットを AWS Glue Data Catalog と統合したうえで、Amazon Redshift でリソースリンクを指す外部スキーマを作成し、保持されたテーブルをクエリします。 Amazon Athena: インフラのプロビジョニングなしで、過去のログに対してサーバーレスの SQL クエリを実行します。 AWS Glue: 運用データを基盤に、自動化されたデータ処理・変換ジョブを構築します。 Amazon EMR: 複雑なウェアハウス横断分析のために、Spark ベースの分析を大規模に実行します。 データは Amazon S3 Tables にオープンな Apache Iceberg 形式で保存されるため、Amazon Redshift、Amazon Athena、自然言語クエリ用の AI エージェントスキル、 Amazon SageMaker Unified Studio 、Iceberg 対応エンジン、ビジネスインテリジェンス (BI) ツール、可観測性システムなど、さまざまな手段でクエリできます。 コスト効率 Amazon Redshift から Amazon S3 Tables へのログ配信に追加費用はかかりません。料金が発生するのは、Amazon S3 Tables のストレージ、メンテナンス、および選択したエンジンでのデータのクエリに対してのみです。 ソリューションの概要 以下のシナリオでは、Amazon Redshift システムテーブルと Amazon S3 Tables の統合が、Amazon Redshift 環境全体でよくある運用・コンプライアンス・可観測性の課題をどのように解決するかを紹介します。また、本機能のために専用のスキル querying-aws-redshift を用意し、AWS MCP Server に組み込みました。これにより、Amazon S3 Tables から Amazon Redshift システムテーブルをクエリできます。 シナリオ 1: クエリの傾向を長期的に追跡する 数か月から数年分の SYS_QUERY_HISTORY データを保持しておけば、個々のクエリのパフォーマンスを長期間にわたって追跡できます。あるクエリの実行時間、キュー時間、リソース消費量を、日単位・週単位・月単位で比較できます。 パフォーマンスが劣化し始めた時期を正確に特定し、新しいスキーマ、データ量の急増、同時実行ワークロードの追加といった変更と関連付けられます。保持期間を延長することで、トラブルシューティングは事後対応から、先を見据えたデータドリブンな根本原因分析へと変わります。 シナリオ 2: 変更前後のワークロードへの影響を評価する 新しい ETL パイプライン、インスタンスタイプの変更、Workload Management (WLM) キューの調整、アドホッククエリを実行するアナリストチームの追加など、ワークロードの変更はいずれもシステムに影響します。問われるのはいつも、その変更がパフォーマンスにどう影響したかです。 Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、自信を持ってデータに基づいた意思決定ができます。 SYS_QUERY_HISTORY をクエリして、変更前の数週間と変更後の数週間で、実行時間、キューでの待機時間、同時実行スケーリングのイベントを比較します。2 週間前に新しいレポートワークロードを導入し、既存のクエリへの影響を把握したい場合、それを確認するためのデータはすでに揃っており、独自パイプラインは一切不要です。 シナリオ 3: 可観測性ダッシュボードを構築する システムテーブルのデータは Apache Iceberg で保存され、AWS Glue でカタログ化されます。つまり、Apache Iceberg を読み取れる可観測性ツールやビジネスインテリジェンス (BI) ツールから直接接続できます。経営層向けのレポートとして、ワークロードの分散傾向を Amazon Quick Sight で可視化できます。より深い分析や、運用データからの AI 主導のインサイト生成には、Amazon SageMaker Unified Studio を利用します。AWS のサービスにとどまらず、使い慣れたサードパーティの可観測性システムや BI ツールを接続して、クエリ量の追跡、接続パターンの監視、異常検知のアラート設定、あるいは Amazon Redshift の運用データとアプリケーションレベルのログの相関分析も行えます。 可観測性や監査のデータを、すでに使っているツールでそのまま活用できます。堅牢で構造化された運用データに、好みのツールから直接アクセスできます。 シナリオ 4: 季節性を踏まえてキャパシティを計画する ワークロードの需要は 1 年を通じて変動します。月次決算、四半期末のレポート、年間の計画サイクル、プロモーションイベントはいずれも予測可能な使用量のスパイクを生みますが、それはパターンを見て取れるだけの履歴データがあってこそです。 保持期間を延長すれば、複数のビジネスサイクルにまたがる使用状況の傾向を分析できます。キャパシティの上限に常に近づくのはいつかを特定し、需要が四半期ごとにどう変化するかを測定し、プロビジョニング済みのリソースが実際の使用量と見合っているかを検証できます。 シナリオ 5: コンプライアンスの監査証跡を維持する 規制対象の業界にとって、保持期間の延長は、整合性を標準で備えたフルマネージドの監査証跡をもたらします。 SYS_CONNECTION_LOG はすべての認証試行を記録します。 SYS_USERLOG はユーザーアカウントの変更を記録します。 SYS_QUERY_HISTORY はウェアハウスに対して実行されたすべてのクエリを記録します。 保持期間は、90 日、1 年、あるいは数年など、組織のデータ保持ポリシーに合わせて設定します。読み取り専用のアクセスポリシーにより、書き込み後のレコードが管理者を含む誰かによって改変されるのを防げます。 シナリオ 6: ウェアハウス群全体で運用の可観測性を一元化する 複数の Amazon Redshift ウェアハウスを運用している場合、運用データを統合的に把握できるメリットがあります。本機能は、組織構造に合わせて 2 つのデプロイパターンをサポートします。 ウェアハウスごとの個別テーブル: 各ウェアハウスが専用の Amazon S3 テーブルに書き込むため、コンプライアンス上の配慮が必要な環境向けに完全なデータ分離を実現します。複数のウェアハウスをまとめてクエリするには、 UNION 操作が必要です。 共有テーブル: 同じアカウント・同じ AWS リージョン内のウェアハウスが、共有された 1 組の Amazon S3 テーブルに書き込み、データは warehouse_name 列で区別されます。ウェアハウスで絞り込めば、クラスター横断の分析をすぐに行えます。 ベストプラクティス プライバシー上の理由でログの分離が必要なウェアハウスを特定し、それらには ウェアハウスごとの個別テーブル オプションを選択します。残りのウェアハウスには、管理を簡素化するために 共有テーブル (集約) オプションを使用します。 保持期間はコンプライアンス要件に合わせます。ストレージコストを抑えるため、コンプライアンス要件を満たす最小限の保持期間を設定します。 保持されたシステムテーブルをクエリする際は、 warehouse_account_id 、 warehouse_region_name 、 warehouse_namespace_arn 、 warehouse_name 、 s3_tables_ingestion_time などのメタデータ列で絞り込み、スキャン範囲を減らしてパフォーマンスを高めます。複数のウェアハウスにまたがる大量の履歴データをクエリする場合は、特に重要です。 監査証跡の整合性は、標準で備わる読み取り専用アクセスに任せます。保持期間や暗号化の設定は、Amazon S3 Tables の設定 API で管理します。 暗号化の方針は早い段階で計画します。設定後の変更には統合の再作成が必要になるため、暗号化キーはセットアップ時に慎重に選びます。将来的にウェアハウスを集約する見込みがあるなら、最初から共有の AWS KMS キーを選んでおきます。 まとめ Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、独自の ETL パイプラインをフルマネージドのソリューションに置き換え、Amazon Redshift の運用データを保持します。Apache Iceberg ベースのストレージへの自動保存、オープン形式でのクエリ、標準で備わる監査整合性により、数か月から数年分の可観測性データをフルマネージドで得られます。 AWS Management Console 、 AWS Command Line Interface (AWS CLI) 、 AWS SDK から有効にできます。 詳しくは、 Amazon Redshift システムテーブルのドキュメント を参照してください。 著者について Nidhi Nayak Nidhi は、AWS のシニアテクニカルアカウントマネージャーです。エンタープライズのお客様がスケーラブルで高性能なクラウドアプリケーションを構築し、クラウド運用を最適化できるよう支援しています。データ分析の分野で 10 年以上の経験を持ち、現在は Amazon Redshift と、Redshift への生成 AI の統合に注力しています。 Raza Hafeez Raza は、Amazon Redshift のシニアプロダクトマネージャー (テクニカル) です。エンタープライズのデータウェアハウスの構築と最適化に 15 年以上携わり、あらゆる規模のお客様にとってクラウド分析を使いやすく、コスト効率の高いものにすることに情熱を注いでいます。 Shubham Purwar Shubham は、AWS の Analytics スペシャリストソリューションアーキテクトです。AWS プラットフォーム上でスケーラブルかつ安全で高性能な分析ソリューションを設計・実装し、お客様がデータの潜在能力を最大限に引き出せるよう支援しています。AWS の分析サービスに関する深い専門知識を活かし、お客様と協力して個別のビジネス要件を明らかにし、具体的なインサイトをもたらしてビジネスの成長を促すカスタマイズされたソリューションを構築しています。プライベートでは、家族と過ごしたり世界中を旅行したりするのが好きです。 Amrita Singh Amrita は、米国ソルトレイクシティを拠点とする AWS のシニアテクニカルアカウントマネージャーです。Amazon Redshift を専門とし、エンタープライズのお客様がデータウェアハウス環境をパフォーマンス、スケーラビリティ、コスト効率の面で最適化できるよう支援しています。お客様と直接連携してクラウド活用のガイダンスや技術支援を提供し、AWS のサービスによって柔軟性、スケール、耐障害性を高められるよう手助けしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 6 月 4 日 に .NET on AWS Blog で公開された「 AWS Transform SQL Server to PostgreSQL Schema Validation in .NET Application Modernization 」を翻訳したものです。 本記事の執筆には Sayan Ghosh、Yuhao Zhang、Uday Kiran Erukulla、Srinivasa Varadan Saragur Madabhushi、Koushik Rajagopal、Khurram Khawaja、Vikas Babu Gali、Luke Huan が協力しました。 Microsoft SQL Server から Amazon Aurora PostgreSQL – Compatible Edition へのデータベース移行は、ライセンスコストの削減、スケーラビリティの向上、オープンソースデータベース技術の活用を目指す組織にとって一般的なモダナイゼーション戦略です。ただし、SQL Server データベースを Aurora PostgreSQL に移行する際、スキーマ変換はあくまで出発点に過ぎません。真の課題は、すべてのテーブル、制約、ストアドプロシージャ、トリガーが正しく移行され、移行先の PostgreSQL 環境でも同一の動作をすることを検証する点にあります。小数精度の変更をひとつ見落としたり、ストアドプロシージャの変換に誤りがあったりするだけで、本番環境でデータ破損やアプリケーション障害、ビジネスロジックの誤動作を招くおそれがあります。 手動でのスポットチェック、スモークテスト、単純な行数比較に頼る従来の移行テストでは、こうした微妙な意味の違いを捉えられません。オブジェクトが存在するかどうかだけでなく、機能的に等価であるかまで検証する体系的なアプローチが必要です。 この記事では、 AWS Transform が構造分析、意味検証、動作テストを組み合わせた 3 層の検証モデルによって、SQL Server から PostgreSQL への移行に対する包括的なスキーマ検証を実現する仕組みを紹介します。あわせて、 Amazon Bedrock を活用した AI エージェントが検証結果を分析し、根本原因ごとに問題をまとめ、重大度を判定して修正の優先順位付けを支援する流れも解説します。 ソリューション概要 AWS Transform のスキーマ検証は、移行元と移行先の両方を稼働中のデータベースエンジンにデプロイし、そこに対して直接チェックを実行することで、移行済みデータベーススキーマの検証をエンドツーエンドで自動化します。この検証は移行先スキーマの作り方に依存しません。ルールベースのツール、エージェンティックなソリューション、独自に構築した生成 AI (GenAI) 変換パイプラインのいずれで生成したスキーマにも適用できます。図 1 は、移行元と移行先のスキーマが検証ワークフローをどのように流れるかを示しています。 図 1. エンドツーエンドのスキーマ検証ワークフロー 図 1 のとおり、検証は以下の流れで進みます。 移行元の SQL Server スキーマと移行先の PostgreSQL スキーマを、それぞれ専用の Amazon Elastic Container Service (Amazon ECS) コンテナに読み込む 両方のスキーマが Tier 1 (構造的検証) に入り、検証ワークフローが各オブジェクトが移行先に存在するかをプログラムでチェックする 構造チェックを通過したオブジェクトが Tier 2 に進み、意味的な等価性を比較する 意味チェックを通過したストアドプロシージャが Tier 3 (動作検証) に進み、ランタイムでテストする 各 Tier がオブジェクトごとの判定 (PASS、FAIL、または WARNING) を出力し、スコアリング層に集約される エキスパートアセスメントエージェントがすべての判定を確認し、両方の稼働中データベースにクエリを発行してフラグの立った問題を裏付ける。その後、検出内容を根本原因ごとにまとめ、重大度を判定し、最終的な本番移行準備レポートを生成する ウォークスルー このワークフローは、内部的には以下の 5 つのステップとして実行されます。 移行元 SQL Server と PostgreSQL の検証コンテナを Amazon ECS 上で起動する 移行元と移行先のスキーマを、対応する検証用データベースに読み込む 両方のデータベースにクエリを発行してルールベースのチェックを実行する Amazon Strands Agents を使って AI エキスパートによる分析を実行する 最終的な検証レポートを生成する この検証は 2 つの原則に基づいています。 正規表現による解析ではなく、稼働中のデータベースを使う 。バリデーターは稼働中の各データベースに直接クエリを発行します。生の SQL ファイルの記述内容ではなく、エンジンが実際に解釈した内容を報告します。 決定論的な処理を先に、LLM は後に 。ルールベースのチェックを大規模言語モデル (LLM) 層より前に実行し、LLM にはフィルタリング済みの入力を渡します。これにより LLM は決定論的なシグナルを置き換えるのではなく、補強する役割を担います。 これらの原則のもと、ルールベースのチェックと AI 分析は以下のように動作します。 1. 構造的検証 (Tier-1) 目的 : 移行元スキーマのすべてのデータベースオブジェクトが移行先スキーマに存在することを検証する この Tier では、移行元と移行先の両方のデータベースに直接クエリを発行し、すべてのスキーマオブジェクトに対してルールベースの存在チェックを並行して実行します。以下の表に例を示します。 オブジェクトタイプ チェック内容 テーブル 各テーブルが移行先に存在し、列と NULL 許可のルールが一致することを確認する 制約 主キー、外部キー (カスケードルールを含む)、一意制約、CHECK 制約を検証する 構造の照合で見落としやすい課題が、名前の正規化です。SQL Server は既定で大文字小文字を区別しませんが、PostgreSQL は引用符で囲まない識別子を小文字に折りたたみ、大文字小文字を区別して扱います。さらに PostgreSQL は識別子を 63 バイトで切り詰めます。そのため、SQL Server 上では別名だった 2 つのプロシージャが PostgreSQL 上では同じ名前に統合されることがあり、正しく移行できたテーブルが単純なバイト単位の比較では不一致と判定されてしまいます。これを避けるため、構造の照合では大文字小文字の折りたたみ、切り詰め、引用符の除去という段階を踏んで名前を正規化し、各段階でレコードの正規化を適用します。 2. 意味的検証 (Tier-2) 目的 : 移行したオブジェクトが構造として存在するだけでなく、意味的に等価であることを検証する Tier 1 がオブジェクトの存在を確認するのに対し、Tier 2 はその定義が意味的に等価かどうかをチェックします。チェックはルールベースで、SQL Server と PostgreSQL の型システム間の型マッピングと精度のルールを組み込んでいます。以下に例を示します。 チェック 例 型マッピング nvarchar(100) から character varying(100) への変換は有効。integer への変換は無効 数値精度 decimal(18,2) は numeric(18,2) のままである必要があり、numeric(10,0) では不可 意味チェックが等価性を捏造することはありません。正規化できない場合 (既定値に互換性がないなど) は、黙って修正を適用するのではなく WARNING を出します。これにより、不要なアラートを増やさずに本番環境での問題を防げます。 3. 動作検証 (Tier-3) 目的 : ランタイムの動作が期待どおりであることを確認する Tier 2 で定義を検証したうえで、Tier 3 では実際のランタイム動作をテストします。2 つのルーチンが構造チェックと意味チェックの両方を通過しても、スタブ、分岐処理のバグ、変換で失われる方言固有の機能などが原因で、異なる結果を返すことがあります。こうした問題を洗い出すため、動作検証は次の 3 ステップで段階的に踏み込みます。 ステップ 1: スタブの検出 バリデーターは、PostgreSQL 側のルーチン本体が意味のある実装になっているか、それとも BEGIN RETURN 0; END のようなプレースホルダーのロジックだけかを調べます。スタブの生成は自動変換で最も起こりやすい失敗パターンのひとつなので、最初に検出しておくことで後続ステップの無駄な作業を防げます。 以下は、変換時に AI エージェントが SQL Server プロシージャから生成した PostgreSQL のスタブの例です。 SQL Server プロシージャ : --SQL Server procedure CREATE PROCEDURE BabelFish.bf_collationproperty @collation_name SYSNAME = 'Traditional_Spanish_CS_AS_KS_WS', @prop_name VARCHAR(255) = 'CodePage' AS BEGIN SELECT COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'CodePage') AS 'CodePage' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'LCID') AS 'LCID' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'ComparisonStyle') AS 'ComparisonStyle' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'Version') AS 'Version'; END; PostgreSQL のスタブプロシージャ : --PostgreSQL stub procedure CREATE OR REPLACE PROCEDURE babelfish.bf_collationproperty(IN collation_name varchar(128) DEFAULT 'Traditional_Spanish_CS_AS_KS_WS', IN prop_name varchar(255) DEFAULT 'CodePage') LANGUAGE plpgsql AS $body$ BEGIN RAISE NOTICE 'Stub: babelfish.bf_collationproperty - needs manual T-SQL to PL/pgSQL conversion'; END; $body$; ステップ 2: 構造の検証 バリデーターは両側のルーチンのシグネチャ、入出力パラメータ、戻り値の型を検査し、移行後のアプリケーションで呼び出しエラーを引き起こす構造の不一致を特定します。 ステップ 3: ミューテーションテストと LLM による評価 バリデーターはテスト入力を生成し、両方のデータベースに対して実行して結果を比較します。行レベルで 1 件でも差異があれば、それが 2 つのルーチンが等価でないことを示す具体的な反例になります。ミューテーションテストで判断がつかない場合は、Amazon Bedrock を通じた LLM による評価で機能的な等価性を判定し、最終的な結論を出します。 4. スコアリング 各チェックは、オブジェクトごとに PASS/FAIL または WARNING を出力します。レポートには 決定論的な 2 つの主要スコア が示され、同じ入力であれば実行ごとに同じ値になります。 Storage Score – データを保持するオブジェクト (テーブル、インデックス) 全体でのスキーマの一貫性を測る Code Score – 実行可能なオブジェクト (ビュー、ストアドプロシージャ、関数、トリガー) 全体での機能カバレッジを測る この 2 つの数値で移行のカバレッジを素早く把握できますが、最終的な評価を決めるのはこれらではありません。それを担うのが AI ジャッジ ( LLM-as-a-Judge )です。これは、エキスパートレビュワーとして振る舞う Amazon Strands Agents です。ルールベースのチェックが答えるのは「何が違うのか」です。これに対して AI ジャッジが答えるのは「それは重要なのか、どう直すべきか」です。 この AI ジャッジは両方の稼働中データベースに読み取り専用でアクセスでき、フラグの立った問題を裏付けたり否定したりするために自ら検証クエリを発行できます。そのうえで、この Strands Agents が検出内容を根本原因ごとのクラスターにまとめます。たとえば、スキーマがひとつ欠けていることが原因で 29 個のトリガーが欠落している場合、29 件ではなく 1 件のクラスターとして扱われます。各クラスターには次の重大度が割り当てられます。 重大度 基準 CRITICAL ユーザーデータの損失または破損 HIGH 将来的に気づきにくい障害が起きる、またはアプリケーションからの呼び出しが失敗する MEDIUM アプリケーションが意図どおりに動作しない可能性がある LOW 表示上の問題で、動作を妨げない 根本原因ごとにまとめるこのアプローチでは、影響を受けたオブジェクトを個別に列挙するのではなく、大元の問題に対処するためノイズが減ります。共通の原因を修正すれば、そこから派生したすべての症状が一度に解消します。 本番移行準備の判定ルール Critical の検出があれば、他のスコアに関わらず本番デプロイをブロックする High のクラスターがあれば条件付きの準備完了となる (追加の検証が必要) Medium と Low の問題は、Critical や High のブロッカーを上書きしない まとめ SQL Server から PostgreSQL への移行は影響範囲の大きい変更であり、テストに合格したというだけでは正しさの証明にはなりません。AWS Transform の 3 層検証ワークフローは、その主張を監査可能な成果物に変えます。Tier 1 ですべてのオブジェクトが移行できたことを確認し、Tier 2 で個々のオブジェクトが意味的に等価であることを確認し、Tier 3 でルーチンが同じ結果を返すことを実際に検証します。さらに AI ジャッジである Amazon Strands エージェントが検出内容を根本原因ごとにまとめ、重大度にもとづいた評価を出すため、主要スコアが高いだけで重大なデータ損失の問題が見過ごされることはありません。 まずは最初のスキーマ移行の検証を AWS Transform で試してみてください。詳細は以下のリソースをご覧ください。 AWS Transform Amazon Aurora PostgreSQL Amazon Bedrock Amazon Strands Agents 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Amit Kachroo Dr. Amit は、Amazon Agentic AI Science チームのシニアアプライドサイエンティストとして、コード変換のための生成 AI および LLM システムを構築しています。さまざまなプログラミング言語やデータベースに対応した変換機能を開発するサイエンスチームを率いています。詳しくは https://amitkac.github.io/ をご覧ください。 Vijay Mandadi Vijay は、AWS Migrations and Modernizations グループのエンジニアリングリーダーです。分散システム、クラウドコンピューティング、仮想化、ワークロード変換、ヘルスケアの分野で 16 年以上の経験を持ちます。AWS では、生成 AI とエージェンティック AI を活用して、お客様のアプリケーションワークロードのモダナイゼーションとクラウドネイティブ化を加速することに取り組んでいます。 Nits Jeganathan Nits は、AWS Transform のプロダクトリーダーです。IT 業界で 15 年の経験を持ち、エッジコンピューティング、システム開発、アプリケーションモダナイゼーションの分野で 12 件の特許と 2 件の論文があります。複雑な課題の解決とカスタマーエクスペリエンスの向上に情熱を注いでおり、現在は生成 AI を使ったレガシーアプリケーションのモダナイゼーション加速に注力しています。

このブログは、2026 年 8 月 3 日に公開された「  Modernize SQL Server databases to Aurora PostgreSQL using AWS Transform  」を翻訳したものです。 はじめに SQL Server データベースの Aurora PostgreSQL へのモダナイゼーションは、始める前から停滞することがよくあります。インフラストラクチャーのセットアップ、ネットワーク構成、資格情報の共有、セキュリティレビューといった準備作業に何週間もかかり、移行の中身を評価する段階にすらたどり着けないのです。 AWS Transform フルスタック Windows モダナイゼーション  の Offline Source を使用すると、こうした障壁を飛び越えて、SQL Server データベースのスキーマファイルをアップロードするだけで Microsoft SQL Server データベースの  Amazon Aurora PostgreSQL-Compatible Edition  (Aurora PostgreSQL) へのモダナイゼーションを開始できます。 SQL Server 環境を管理していて、始めるまでの複雑さからモダナイゼーションを先送りにしてきた方に、ぜひ読んでいただきたい記事です。Offline Source がインフラストラクチャーの事前準備をどのように不要にするか、.NET アプリケーションコードのアセスメントを含む変換ワークフローがエンドツーエンドでどのように動くか、そして SQL Server スキーマの DDL エクスポートから、変換済みアプリケーションコードを伴う検証済み Aurora PostgreSQL スキーマに至るまでの流れを解説します。 課題: アセスメント前のインフラストラクチャー要件 SQL Server データベースのモダナイゼーションアセスメントには従来、以下が必要でした : ソースデータベースと変換ツール間のネットワーク接続 ソースサーバーへの資格情報の共有またはエージェントのインストール スキーマ分析のための中間環境のプロビジョニング 厳格なセキュリティポリシー、規制環境、または企業ファイアウォールの背後にあるデータベースを持つ組織にとって、アセスメント作業を始める前の段階でこれらの前提条件だけでモダナイゼーションプロジェクトが数週間から数か月遅れることもありました。 ソリューション概要 AWS Transform  の Offline Source を使用すると、標準的な Data Definition Language (DDL) エクスポートファイルからソースデータベースの構造を再現できます。稼働中の SQL Server インスタンスに接続する必要はなく、 DDL をアップロードするだけで AWS Transform がアセスメントから変換、検証、Aurora PostgreSQL へのデプロイまでを実行します。インフラストラクチャーの事前準備は一切不要です。 図 1: AWS Transform Offline Source ワークフロー ワークフローは 5 つのステージで構成されます : データベースアセスメント : データベースオブジェクトの複雑さ、依存関係、作業量レベルを分析 スキーマ変換 : SQL Server オブジェクトの PostgreSQL への LLM ベースの変換 検証 : 3 層の検証 (構造的、意味的、機能的) デプロイ : 検証済みスキーマを Aurora PostgreSQL クラスターに適用 アプリケーションのアセスメントと変換 : .NET ソースコードを接続し、スキーマと並行してデータベース依存のアプリケーションコードをアセスメントおよび変換 前提条件 開始する前に、以下を確認してください : AWS Transform console へのアクセスを持つ AWS アカウント DDL を抽出するための SQL Server に接続する資格情報 Aurora PostgreSQL クラスターを作成する権限を持つ AWS アカウント (AWS Transform はデプロイステップの一部としてターゲットクラスターをプロビジョニングします) オプション : .NET アプリケーションアセスメント用の、 AWS CodeConnections 経由でアクセス可能な、または Amazon S3 や Personal Access Token (PAT) 経由でアップロードされたソースコードリポジトリ (GitHub、GitLab、または Bitbucket) AWS Transform for SQL Server は US East (N. Virginia) us-east-1 でのみ利用可能です。他のリージョンのデータベースの場合、変換のために us-east-1 にクローンしてください。 AWS アカウントで IAM Identity Center が有効化されていること Microsoft SQL Server バージョン 2008 R2 から 2022 (すべてのエディションがサポートされています)。SQL Server は AWS 上または AWS 外でホストできます。 オプション (.NET アセスメント用): .NET Core 6、7、8、または 10 アプリケーション。レガシーな .NET Framework 4.x 以前はサポートされていません。 ウォークスルー 以下のセクションでは、Offline Source ワークフローの各ステージを説明します。 ステップ 1: SQL Server DDL を抽出してアップロード AWS Transform は DDL を抽出するための 2 つの方法を提供します : オプション 1 (推奨): 変換ジョブを作成すると、AWS Transform は SQL Server に対して実行する抽出スクリプト ( ExtractDatabaseMetadata.ps1 ) を提供します。このスクリプトはデータベースごとに SQL Server オブジェクトタイプ (テーブル、ストアドプロシージャ、関数、トリガーなど) の DDL 定義を抽出し、複数の機能領域 (SSIS、SSRS、Service Broker、Agent Jobs など) を検出するため、アセスメントに最も完全な情報を提供します。 オプション 2 (手動): SSMS または sqlpackage を使用して SQL DDL ファイル ( CREATE TABLE 、 CREATE PROCEDURE  などのステートメント) を手動でエクスポートし、zip にしてアップロードします。各 SQL ファイルには 1 つのデータベースのステートメントのみを含める必要があります。 結果の DDL ファイル (または zip) を AWS Transform にアップロードして Offline Source を作成します。 ステップ 2: アセスメントの確認 AWS Transform はすべてのデータベースオブジェクトの複雑さと依存関係を分析します。アセスメントレポートには以下が含まれます : オブジェクト間の関連性を可視化する依存関係マップ 各オブジェクトの複雑さスコア (Simple、Moderate、Complex) 手動変換と自動変換の作業量 (LOE) の見積もり エージェントによる自動化で削減できる工数と、人的レビューが必要な部分の内訳 アセスメントでは、PostgreSQL のイベントトリガーへの置き換えが必要な DDL トリガーや、例外ブロック内でのみ有効な構文を使用している関数など、手動レビューが必要になる可能性のある項目も識別されます。これらの情報をもとに、変換開始前にチームの作業計画を立てることができます。 ステップ 3: 変換をカスタマイズ アセスメントを確認した後、AWS Transform は変換の実行方法を定義する変換プランを生成します。プランは実行戦略、フェーズの順序付け、変換ルール、インフラストラクチャー構成を単一のレビュー可能なアーティファクトに統合します。デフォルトを受け入れて進めることも、変換開始前に任意の側面をカスタマイズすることもできます。 変換プランは 4 つの領域をカバーします : 実行ウェーブ – データベースはウェーブ順に変換され、各ウェーブ内で最大 5 つのデータベースが並行して実行されます。次のウェーブは現在のウェーブのすべてのデータベースが完了した後にのみ開始されます。ウェーブ間でデータベースの順序を変更したり、完全に除外したりできます。 ジョブプラン – 変換ジョブのフェーズの順序 (スキーマ変換、ターゲットプロビジョニング、スキーマデプロイ、コード変換、およびオプションの合成テストデータ生成)。必要に応じてオプションフェーズをスキップできます。 変換およびカスタムルール – 型マッピング (例: SQL Server の MONEY から PostgreSQL の DECIMAL(19,4) )、スキーマ名マッピング (例: 単一データベース移行での dbo から public )、関数マッピング (例: GETDATE から CURRENT_TIMESTAMP )、IDENTITY 列戦略 ( GENERATED BY DEFAULT または GENERATED ALWAYS )、およびプロシージャ結果のハンドリング (refcursor または関数リターンスタイル)。適切なデフォルトが自動的に適用されるため、ユースケースに合わないものだけを変更するだけで済みます。 ターゲットプロビジョニング構成 – 新しい Aurora PostgreSQL クラスターを作成するか既存のものに接続するか、およびインスタンスクラス、ネットワーク設定、資格情報管理。 これらの設定は、コンソールでプランを直接編集するか、自然言語でプリファレンスを記述するか、JSON 構成ファイルを提供することでカスタマイズできます。例えば、「MONEY を DECIMAL(19,4) にマッピングし、dbo に public を使用し、GENERATED ALWAYS で IDENTITY 列を生成する」とリクエストすると、AWS Transform が該当するルールを適用します。 ステップ 4: LLM ベースのスキーマ変換の実行 AWS Transform では、大規模言語モデル (LLM) を使用して SQL Server スキーマオブジェクトを PostgreSQL に変換します。変換はコンテキストを考慮し、構文だけでなくビジネスロジックの意図を保持します。 変換はステージごとに進行します: 基盤オブジェクト (スキーマ、シーケンス、シノニム、ユーザー定義型) テーブルと主キー 制約とインデックス プログラマブルオブジェクト (ストアドプロシージャ、関数、ビュー、トリガー) LLM ベースのアプローチは、ルールベースのツールでは通常手動変換が必要な複雑な T-SQL パターンやプロプライエタリな SQL Server 構文を処理します。これにより、自動変換率が向上し、手動介入が減少します。 ステップ 5: 変換済みオブジェクトの検証 変換されたオブジェクトは、以下の 3 層の自動検証を通過します : 構造的検証 は、変換された PostgreSQL スキーマが構文的に正しくデプロイ可能であることを確認します。 意味的検証 は、変換されたオブジェクトがソースの論理的な意味と動作を保持していることを検証します。 機能的検証 は、ソースとターゲット間のクエリ動作を比較し、本番環境に影響する前に差異を検出します。 各検証パスでは分離されたサンドボックスが起動し、ソースとターゲット両方のスキーマをロードした上で、型マッピング、制約、ルーチンを検査する AI エキスパートレビュワーが実行されます。AWS Transform はストレージオブジェクトの変換後とコードオブジェクトの変換後にそれぞれ検証レポートを生成します。各レポートでは、カテゴリごと (テーブル、列、制約、インデックス、ビュー、プロシージャ、関数) に Pass、Warning、Fail の結果が示されます。 検証完了後、エキスパートアセスメントが全体の変換を評価します : Ready: オブジェクトが完全に変換および検証済み Conditional: オブジェクトが変換済みで、レビュー用にマイナーな問題がフラグ付けされている Not Ready: 手動介入が必要なオブジェクト ステップ 6: 残りの問題への対応 Conditional または Not Ready と評価されたオブジェクトについて、AWS Transform は具体的な次のステップを含む Schema Conversion Report を提供します。2 つのオプションがあります : 組み込みの AWS Transform Web コンソールを使用して、ローカル IDE のインストールなしにブラウザで直接変換の問題を確認して修正する。 または、Kiro や他のローカル AI コーディングアシスタントと  AWS Transform MCP Server  を使用して、好みの IDE にアーティファクトを取得する。 修正を加えた後に検証を再実行し、スキーマ全体が検証に合格するまで繰り返しデプロイできます。 Web コンソールでは、変換レポートの確認、SQL の編集、検証の再実行、変更のデプロイまでをブラウザ上で一貫して行えます。ローカル開発を好むチームには、MCP Server を使って IDE から AWS Transform ワークスペースに接続して普段の開発ワークフローのまま、同じアーティファクトとデプロイ機能を利用できます。 ステップ 7: Aurora PostgreSQL にデプロイ 検証が完了したら、AWS Transform に AWS アカウントへのアクセスを付与するデータベースコネクタを設定します。AWS Transform はターゲットの Aurora PostgreSQL クラスターをプロビジョニングし、変換済みスキーマをデプロイします : 既存のクラスターを選択するか、AWS Transform に新しいクラスターを作成させます。 AWS Transform が変換済みオブジェクトをターゲットに適用します。 データベース資格情報が生成され、AWS Secrets Manager に保存されます。 問題がないかデプロイレポートを確認します。 デプロイ後、継続的な運用に不要な場合は、オプションで RDS Data API を無効にできます。 ステップ 8: .NET アプリケーションコードのアセスメントおよび変換 スキーマのデプロイが完了すると、コード変換が実行可能になります。アプリケーションのアセスメントと変換を行うために、.NET Core (6、7、8、または 10) のソースコードリポジトリを接続します。アプリケーションのデータベースアクセスには ADO.NET または Entity Framework (6.3-6.5、または EF Core 1.0-8.0) を使用している必要があります。なお、アセスメントはスキーマデプロイ前でも開始できますが、コード変換にはスキーマが先にデプロイされている必要があります。 ソースコードへの接続には、以下を使用できます :   AWS CodeConnections (GitHub、GitLab、または Bitbucket リポジトリ用) ソースコードの直接アップロード用の Amazon S3 AWS Secrets Manager  に保存する Personal Access Token (PAT) 接続すると、AWS Transform は : コネクタを通じて利用可能なリポジトリを検出します。 ソースコードをダウンロードして分析し、データベース参照、Entity Framework モデル、接続文字列、SQL クエリパターンを識別します。 モダナイゼーションの複雑さ (Low、Medium、High) と具体的な変換レコメンデーションを含むアプリケーションアセスメントレポートを生成します。 アセスメント完了後、コード変換を開始して .NET アプリケーションコードを Aurora PostgreSQL をターゲットとするように更新できます。コード変換はスキーマ変換の結果を使用して、アプリケーション内の接続文字列、ORM マッピング、インライン SQL クエリを更新します。 ステップ 9: テストデータで検証する (オプション) AWS Transform は本番データを公開することなく、ターゲットクラスターに検証用のテストデータを生成できます。テストデータ生成レポートには何が作成されたかが記載され、代表的なデータボリュームに対してストアドプロシージャ、ビュー、アプリケーションクエリの徹底的なテストが可能になります。 クリーンアップ このウォークスルー中にテスト目的で新しい Aurora PostgreSQL クラスターを作成した場合 : Amazon RDS console に移動します。 作成したクラスターを選択します。 Actions > Delete を選択します。 削除を確認します。 AWS Transform ワークスペースは追加料金なしでそのまま残しておけるため、後から参照することができます。 まとめ AWS Transform for SQL Server の Offline Source を使うことで、SQL Server モダナイゼーションにおける 2 つの大きな障害、すなわち「始めるまでのハードル」と「スキーマ変換の精度・検証」を解消できます。稼働中のデータベースへの接続設定は不要で、DDL ファイルをアップロードするだけで始められます。インフラストラクチャーのプロビジョニングなしに、スキーマのアセスメントから変換、検証、Aurora PostgreSQL へのデプロイまでを実行できます。さらに .NET ソースコードリポジトリを接続すれば、データベースと合わせてアプリケーションコードの変換も可能です。これらすべてが単一の統合ワークフローで完結します。 Offline Source を開始するには、 AWS Transform console  を開いて最初の変換ワークスペースを作成してください。詳細については、 AWS Transform ドキュメント を参照してください。モダナイゼーションターゲットとしての Aurora PostgreSQL の詳細については、 Amazon Aurora PostgreSQL-Compatible Edition  を参照してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 Vikas Babu Gali Vikas Babu Gali は Amazon Web Services のシニアスペシャリストソリューションアーキテクトで、SQL Server の移行、モダナイゼーション、クラウドデータベース変換を専門としています。Vikas は Fortune 500 企業の多くのお客様を大規模なミッションクリティカルなクラウド変換でガイドしてきました。 Nits Jeganathan Nits Jeganathan は AWS Transform のプロダクトリーダーで、15 年の IT 業界経験、12 件の特許、エッジコンピューティング、システム開発、アプリケーションモダナイゼーションに関する 2 件の出版物を持っています。Nits は複雑な課題の解決とカスタマーエクスペリエンスの改善に情熱を注いでいます。現在は生成 AI を使用したレガシーアプリケーションのモダナイゼーション加速に注力しています。 Shashank Kalki Shashank Kalki は Amazon Web Services のデータベース移行スペシャリストソリューションアーキテクトです。お客様と連携して最も困難なデータ移行の課題を解決し、Amazon Aurora と Amazon RDS への移行の計画、実行、最適化を支援しています。専門分野は大規模な異種データベース変換と移行のベストプラクティスです。

本記事は 2026 年 8 月 11 日 に公開された「 Natural language queries on Oracle Database 26ai: Getting started with Select AI on Amazon RDS for Oracle with Amazon Bedrock 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Oracle で Oracle Database 26ai が利用可能になりました。Amazon RDS における Oracle 初の AI ネイティブなデータベースリリースで、生成 AI、ベクトル検索、機械学習がエンジンに直接組み込まれています。バックアップ、パッチ適用、マルチ AZ による高可用性、リードレプリカは Amazon RDS が処理するため、インフラストラクチャの管理ではなく AI アプリケーションの構築に集中できます。 本記事では、新機能のなかでも特に効果の大きい Select AI を紹介します。Select AI では、Amazon Bedrock の基盤モデル (FM) を使い、自然言語のプロンプトでリレーショナルデータを照会できます。「今四半期の売上上位 5 社の顧客は?」とデータベースに尋ねれば、コードを 1 行も書かずに、正しい SQL とその実行結果が返ってきます。内部では、Oracle の DBMS_CLOUD_AI パッケージがテーブルのスキーマを含むプロンプトを組み立て、選択した基盤モデルに送信します。生成された SQL を実データに対して実行し、結果を返すまでのすべてが同一のデータベースセッション内で完結します。 このアーキテクチャなら、AI インフラストラクチャを自前で構築する運用負荷がなくなります。Amazon Bedrock はフルマネージドかつサーバーレスです。プロビジョニングする GPU も、ホストするモデルも、維持する推論エンドポイントもありません。Anthropic、Meta、Amazon といったプロバイダーの基盤モデルに単一の API でアクセスでき、 DBMS_CLOUD_AI プロファイルの属性を 1 つ変えるだけでモデルを切り替えられます。セキュリティは、すでに使い慣れた Amazon RDS のモデルに従います。Select AI のリクエストは Virtual Private Cloud (VPC) インターフェイスエンドポイントを経由するため、データは VPC 内に留まり、パブリックインターネットを通りません。 DBMS_CLOUD_AI はネイティブな PL/SQL なので、すでに持っている SQL のスキルで生成 AI 機能を構築できます。別途 AI スタックを学んだり維持したりする必要はありません。 本記事は、Amazon RDS 上の Oracle Database 26ai の AI 機能を扱う 3 回シリーズの第 1 回です。今回は、Amazon Bedrock の認証情報の設定から自然言語クエリの実行まで、Select AI を一通り解説します。第 2 回では Oracle AI Vector Search による Retrieval Augmented Generation (RAG) を、第 3 回では SQL プロパティグラフを使った GraphRAG を取り上げ、グラフ探索、ベクトル検索、リレーショナルなフィルタリングを 1 つの SQL クエリで組み合わせる方法を紹介します。 Amazon RDS 上の Oracle Database 26ai の AI 機能 Amazon RDS 上の Oracle Database 26ai と Amazon Bedrock を組み合わせると、次の機能が使えます。 機能 内容 ユースケースの例 Select AI (NL2SQL) 自然言語のプロンプトを SQL に変換し、クエリを実行して、単一の SQL セッション内で結果を返す ビジネスアナリストが SQL を書かずに売上データを照会する。経営層がダッシュボードから即座に答えを得る DBMS_CLOUD_AI.GENERATE PL/SQL から基盤モデルを呼び出し、チャット、要約、翻訳、合成データ生成を行う CLOB 列に格納されたサポートチケットを要約する。開発/QA 環境向けに現実的なテストデータを生成する。製品説明を翻訳する Oracle AI Vector Search 標準的な SQL でベクトル埋め込みをリレーショナルデータと並べて保存、インデックス化、検索する 製品カタログのセマンティック検索。類似する顧客プロファイルの検索。レコメンデーションエンジンの実現 Retrieval Augmented Generation (RAG) ベクトル検索と大規模言語モデル (LLM) の生成を組み合わせ、AI の回答を実際のビジネスデータに基づかせる 社内文書やデータベースのレコードを使って質問に答える AI アシスタント データベース内 ONNX 推論 埋め込み、分類、回帰などの ML モデルを、外部 API を呼び出さずに Oracle 内部で実行する 挿入時に埋め込みを生成する。不正な取引をリアルタイムで分類する。ラウンドトリップなしでリードをスコアリングする プロパティグラフでの Select AI SQL プロパティグラフに対して、自然言語のプロンプトでグラフの関係を照会する 「サプライヤー X と顧客 Y の間の最短サプライチェーン経路を見せて」 ソリューションの概要 この手順を終えると、次のことができるようになります。 AWS Identity and Access Management (IAM) の認証情報を作成し、 DBMS_CLOUD.CREATE_CREDENTIAL で Oracle 内に格納する。 VPC インターフェイスエンドポイントを設定し、プライベートな Amazon RDS インスタンスからインターネットを経由せずに Amazon Bedrock に到達できるようにする。 Claude Sonnet や Amazon Nova などの Amazon Bedrock の基盤モデルを指す DBMS_CLOUD_AI プロファイルを作成、管理する。 LLM から Oracle のテーブルに合成テストデータを直接生成する。 SELECT AI の SQL 構文を使い、自分のテーブルに対して自然言語クエリを実行する。 DBMS_CLOUD_AI.GENERATE() をチャット、SQL の説明、要約に使う。 次の図は全体のアーキテクチャです。 図 1: Amazon RDS for Oracle 26ai と Amazon Bedrock による Select AI 主なコンポーネントは次のとおりです。 コンポーネント 役割 Amazon RDS for Oracle Database 26ai DBMS_CLOUD_AI を含み、Select AI のクエリを実行する Amazon Bedrock 基盤モデル (Claude、Nova) へのマネージドなアクセスを提供する VPC インターフェイスエンドポイント ( bedrock-runtime ) プライベートな Amazon RDS のサブネットからの Amazon Bedrock API 呼び出しを、インターネットを経由せずにルーティングする IAM 認証情報 DBMS_CLOUD.CREATE_CREDENTIAL で Oracle に格納したアクセスキー ID とシークレット。Oracle がすべての Amazon Bedrock 呼び出しを SigV4 で署名するために使う 動作の流れ: ユーザーが SQL クライアントで自然言語の質問を入力します。Oracle が SELECT AI ステートメントを受け取り、質問と対象テーブルのスキーマメタデータを含むプロンプトを構築します。そして IAM ユーザーのアクセスキーで署名したリクエストを、VPC インターフェイスエンドポイント経由で HTTPS により Amazon Bedrock に送信します。LLM が返した SQL を Oracle が実データに対して実行し、結果セットを返します。ここまでのすべてが同一の SQL セッション内で行われます。 前提条件 始める前に、次を確認してください。 プライベートな VPC サブネットにデプロイした Amazon RDS for Oracle Database 26ai インスタンス。本記事では、データベースインスタンスとして一般的なパターンかつ推奨構成である、プライベートな Amazon RDS for Oracle インスタンスを前提とします。テスト目的であれば、インスタンスをパブリックに公開することもできます。 DBMS_CLOUD パッケージと DBMS_CLOUD_AI パッケージがインストールされていること (確認方法はステップ 1 で説明します)。 IAM ユーザーと VPC エンドポイントを作成する権限を持つ AWS アカウント。 対象の AWS リージョンで Amazon Bedrock が利用できること。Amazon Bedrock ではほとんどの基盤モデルがデフォルトで利用可能です。必要に応じて Amazon Bedrock コンソールの モデルアクセス で確認してください。 踏み台ホストまたは AWS Systems Manager Session Manager のポートフォワーディング経由で Amazon RDS インスタンスに接続した SQL Developer、SQLcl、その他の Oracle SQL クライアント。 Amazon RDS インスタンスに関連付けられた VPC ID、サブネット ID、セキュリティグループ ID。 DBMS_CLOUD と DBMS_CLOUD_AI の両方に EXECUTE 権限を持つデータベースユーザー (例: AIUSER)。必要なら、先に作成しておきます。 GRANT EXECUTE ON DBMS_CLOUD TO AIUSER; GRANT EXECUTE ON DBMS_CLOUD_AI TO AIUSER; ステップ 1: DBMS_CLOUD_AI が利用可能か確認する 設定を始める前に、必要なパッケージがインストールされていることを確認します。Amazon RDS for Oracle 26ai では、インスタンス作成時に DBMS_CLOUD と DBMS_CLOUD_AI がデフォルトでインストールされます。 SELECT object_name, object_type, status FROM dba_objects WHERE object_name IN ('DBMS_CLOUD', 'DBMS_CLOUD_AI') AND object_type IN ('PACKAGE', 'PACKAGE BODY') ORDER BY 1, 2; 4 行が返るはずです。 DBMS_CLOUD と DBMS_CLOUD_AI のそれぞれについて PACKAGE と PACKAGE BODY です。パッケージが見つからない場合は、Amazon RDS インスタンスが Oracle Database 26ai で動作しているか確認してください。 ステップ 2: Amazon Bedrock ランタイム用の VPC インターフェイスエンドポイントを作成する Amazon RDS for Oracle DB インスタンスは、ポート 443 (HTTPS) で Amazon Bedrock ランタイムのエンドポイント ( bedrock-runtime.<region>.amazonaws.com ) に到達できる必要があります。この通信を AWS ネットワーク内のプライベートな経路に留め、インターネットアクセスを不要にするには、Amazon Bedrock ランタイムサービス用の VPC インターフェイスエンドポイントを作成します。Amazon RDS インスタンスをプライベートに保てるため、VPC インターフェイスエンドポイントの利用が推奨されます。本記事の例でも VPC インターフェイスエンドポイントを使います。 もう 1 つの選択肢は NAT ゲートウェイです。NAT ゲートウェイを使う場合、DB インスタンスのサブネットに NAT ゲートウェイ経由でインターネットへ向かうルートが必要です。NAT ゲートウェイの設定は、 ドキュメント の「Amazon VPC network requirements」セクションのオプション 2 を参照してください。 エンドポイントを作成する AWS マネジメントコンソールで VPC 、 エンドポイント 、 エンドポイントを作成 の順に移動します。 サービスカテゴリ で AWS サービス を選択します。 サービス名 の検索で bedrock-runtime と入力し、 com.amazonaws.<your-region>.bedrock-runtime を選択します。 VPC では、Amazon RDS インスタンスがある VPC を選択します。 サブネット では、Amazon RDS の DB サブネットグループが使っているサブネットと同じものを選択します。 セキュリティグループ では、Amazon RDS インスタンスのセキュリティグループからの インバウンド TCP ポート 443 を許可するセキュリティグループをアタッチします。 ポリシー では フルアクセス を選択します。 プライベート DNS 名 を有効にします。ここが重要です。有効にすることで Oracle が bedrock-runtime.<region>.amazonaws.com をプライベート IP に解決し、通信が VPC 内でルーティングされます。 エンドポイントを作成 を選択し、状態が 利用可能 になるまで待ちます。 ステップ 3: Amazon Bedrock エンドポイントへのネットワーク ACL アクセスを許可する Oracle はアクセスコントロールリスト (ACL) でアウトバウンドのネットワークアクセスを制御します。AIUSER ユーザーに、 bedrock-runtime.<your-region>.amazonaws.com への HTTP/HTTPS のアウトバウンド接続を許可します。 BEGIN DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE( host => 'bedrock-runtime.<your-region>.amazonaws.com', ace => xs$ace_type( privilege_list => xs$name_list('connect', 'resolve', 'http'), principal_name => 'AIUSER', principal_type => xs_acl.ptype_db ) ); END; / DNS 解決を確認する エンドポイントが有効になったら、Oracle が Amazon Bedrock のホスト名をプライベート IP に解決することを確認します。 -- Should return a private IP, not a public AWS IP SELECT UTL_INADDR.GET_HOST_ADDRESS( 'bedrock-runtime.<your-region>.amazonaws.com' ) AS resolved_ip FROM dual; 出力例: RESOLVED_IP --------------- 172.31.17.236 ステップ 4: AWS の認証情報を作成し Oracle Database に格納する DBMS_CLOUD_AI は IAM のアクセスキー ID とシークレットアクセスキーで Amazon Bedrock に認証します。設定手順としては、Amazon Bedrock の基盤モデル呼び出しに必要な最小限の権限だけを付与した専用の IAM ユーザーを作成し、そのユーザーのアクセスキーを発行します。認証情報を取得したら、 DBMS_CLOUD.CREATE_CREDENTIAL を呼び出して Oracle データベース内に格納します。Oracle はキーを保存時に暗号化し、 DBMS_CLOUD_AI がアウトバウンドの Amazon Bedrock API リクエストの署名に自動的に使用します。 ステップ 4a: Amazon Bedrock アクセス用の IAM ユーザーを作成する 次のポリシーを持つ IAM ユーザーまたはロールを作成します (既存の ID にアタッチしても構いません)。 { "Version": "2012-10-17", "Statement": [{ "Sid": "BedrockInvoke", "Effect": "Allow", "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"], "Resource": ["arn:aws:bedrock:region::foundation-model/*"] }] } 特定のモデルだけにアクセスを制限するには、ワイルドカードを次のように個別のモデル ARN に置き換えます。 arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 ステップ 4b: アクセスキーを発行する 作成したユーザーを開き、 セキュリティ認証情報 タブに移動します。 アクセスキー で アクセスキーを作成 を選択します。 ユースケースを選択し、 アクセスキーを作成 を選択します。 アクセスキー ID とシークレットアクセスキーをコピーまたはダウンロードします。 セキュリティに関する注意: アクセスキーは長期的な認証情報です。本番環境では、IAM コンソールで定期的にローテーションすることを検討してください。この IAM ユーザーにはコンソールアクセス (パスワード) を与えないようにします。 ステップ 4c: IAM ユーザーのアクセスキーを Oracle に格納する Amazon Bedrock のモデルアクセス: 2025 年時点で、Amazon Bedrock のほとんどの基盤モデルはデフォルトで利用可能で、明示的な有効化は不要です。アカウントとリージョンでのモデルの利用可否は、 Amazon Bedrock コンソール の モデルアクセス で確認または変更できます。Amazon RDS for Oracle 26ai の DBMS_CLOUD_AI で動作を検証済みのモデルは次のとおりです。 モデル名 モデル ID 備考 Anthropic Claude Sonnet 4.6 us.anthropic.claude-sonnet-4-6 NL2SQL の精度が最も高い (推奨) Anthropic Claude Haiku 4.5 us.anthropic.claude-haiku-4-5-20251001-v1:0 最速 / 最低コスト Amazon Nova Pro us.amazon.nova-pro-v1:0 高性能な AWS ネイティブモデル Amazon Nova Lite amazon.nova-lite-v1:0 単純なクエリ向けの超高速モデル 重要: クロスリージョン推論のプレフィックス: Anthropic Claude と Amazon Nova Pro のモデル ID には us. プレフィックスが必要です。このプレフィックスによってリクエストがクロスリージョン推論プロファイル経由でルーティングされ、可用性が高まります。プレフィックスのないベースモデル ID を使うと ORA-20400: HTTP 400 が返ります。 DBMS_CLOUD.CREATE_CREDENTIAL を使い、ステップ 4a で取得したアクセスキーとシークレットキーを Oracle の認証情報ストアに格納します。Oracle は認証情報を暗号化し、所有ユーザーだけがアクセスできるようにします。 BEGIN DBMS_CLOUD.CREATE_CREDENTIAL( credential_name => 'AWS', username => '<your-access-key-id>', password => '<your-secret-access-key>' ); END; / 認証情報が正しく作成されたか確認します。 SELECT credential_name, username, enabled FROM all_credentials WHERE credential_name = 'AWS'; username 列には指定したアクセスキー ID が表示されます。シークレットキーは暗号化されて格納され、クエリでは返りません。 ステップ 5: サンプルテーブルを作成する Select AI のデモには E コマースのスキーマを使います。既存のテーブルがある場合は、ステップ 6 に進んでプロファイルの object_list で自分のテーブルを指定してください。 CREATE TABLE customers ( customer_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, first_name VARCHAR2(50), last_name VARCHAR2(50), email VARCHAR2(100), city VARCHAR2(50), country VARCHAR2(50), signup_date DATE, segment VARCHAR2(20) -- 'PREMIUM', 'STANDARD', 'NEW' ); CREATE TABLE products ( product_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, product_name VARCHAR2(100), category VARCHAR2(50), unit_price NUMBER(10,2), stock_qty NUMBER ); CREATE TABLE orders ( order_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, customer_id NUMBER REFERENCES customers(customer_id), order_date DATE, status VARCHAR2(20), -- 'COMPLETED', 'PENDING', 'CANCELLED' total_amount NUMBER(10,2) ); CREATE TABLE order_items ( item_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, order_id NUMBER REFERENCES orders(order_id), product_id NUMBER REFERENCES products(product_id), quantity NUMBER, unit_price NUMBER(10,2) ); ステップ 6: DBMS_CLOUD_AI プロファイルを作成する プロファイル は Select AI の中心となる設定オブジェクトです。AI プロバイダー、認証情報、呼び出す Amazon Bedrock のモデル、そしてプロンプトのコンテキストにスキーマを含めるデータベーステーブルを指定します。 DBMS_CLOUD_AI はデフォルトで bedrock-runtime.us-east-1.amazonaws.com に接続します。us-east-1 以外のリージョンの Amazon Bedrock ランタイムエンドポイントを使う場合は、プロファイル属性の JSON に region 属性と target_language 属性を含めます。 region には Amazon Bedrock ランタイムエンドポイントがあるリージョン (例: us-west-2) を設定します。 region を設定する場合は、 target_language (または source_language ) も含める必要があります。 chat や runsql のように翻訳を使わないアクションでも、この 2 つの属性は必ずセットで設定してください。 target_language の値が影響するのは translate アクションだけです。セットで指定しなければならないのは、Oracle の DBMS_CLOUD_AI パッケージに既知の制限があるためです。 region なしで target_language だけを指定した場合、プロファイルは bedrock-runtime.us-east-1.amazonaws.com を使い続けます。VPC インターフェイスエンドポイントが別のリージョンにあると、Oracle はエンドポイントが存在しないリージョンへパブリックインターネット経由で接続を試み、ネットワーク構成でパブリックアクセスを許可していない限り、すべての呼び出しが ORA-30699 でタイムアウトします。 次の例では、Amazon Bedrock のクロスリージョン推論 (CRIS) 経由で Anthropic Claude Sonnet 4.6 を使うプロファイルを作成します。 BEGIN DBMS_CLOUD_AI.CREATE_PROFILE( profile_name => 'CLAUDE_SONNET', attributes => '{"provider": "aws", "credential_name": "AWS", "region": "<your-bedrock-region>", "model": "us.anthropic.claude-sonnet-4-6", "target_language": "en", "object_list": [ {"owner": "AIUSER", "name": "CUSTOMERS"}, {"owner": "AIUSER", "name": "PRODUCTS"}, {"owner": "AIUSER", "name": "ORDERS"}, {"owner": "AIUSER", "name": "ORDER_ITEMS"} ] }' ); END; / object_list は、LLM 向けのスキーマコンテキストを構築するときに含めるテーブルとビューを Oracle に伝えます。Oracle はデータディクショナリから列名、データ型、列コメントを自動的に読み取り、プロンプトに組み込みます。スキーマを手作業で記述する必要はありません。 異なるモデルを指すプロファイルを複数作成し、セッションごとに切り替えることもできます。 -- Amazon Nova Pro profile BEGIN DBMS_CLOUD_AI.CREATE_PROFILE( profile_name => 'NOVA_PRO', attributes => '{"provider": "aws", "credential_name": "AWS", "region": "<your-bedrock-region>", "model": "us.amazon.nova-pro-v1:0", "target_language": "en", "object_list": [ {"owner": "AIUSER", "name": "CUSTOMERS"}, {"owner": "AIUSER", "name": "PRODUCTS"}, {"owner": "AIUSER", "name": "ORDERS"}, {"owner": "AIUSER", "name": "ORDER_ITEMS"} ] }' ); END; / セッションでプロファイルを有効化し、確認します。 EXECUTE DBMS_CLOUD_AI.SET_PROFILE('CLAUDE_SONNET'); -- Confirm active profile SELECT DBMS_CLOUD_AI.GET_PROFILE() FROM dual; -- List all profiles SELECT profile_name, status FROM user_cloud_ai_profiles; ステップ 7: 合成データを生成する Amazon Bedrock にアクセスできる AI プロファイルを設定したら、 DBMS_CLOUD_AI.GENERATE_SYNTHETIC_DATA でテーブルに現実的なテストデータを自動投入できます。 GENERATE_SYNTHETIC_DATA は、指定した AI プロファイル経由で LLM を使い、文脈に沿ったレコードを生成します。 object_list パラメータには、対象テーブルとそれぞれの生成レコード数を指定する JSON 配列を渡します。 次の PL/SQL ブロックを実行して、4 つのテーブルに合成データを生成します。 BEGIN DBMS_CLOUD_AI.GENERATE_SYNTHETIC_DATA( profile_name => 'CLAUDE_SONNET', object_list => '[ {"owner": "AIUSER", "name": "CUSTOMERS", "record_count": 50}, {"owner": "AIUSER", "name": "PRODUCTS", "record_count": 250}, {"owner": "AIUSER", "name": "ORDERS", "record_count": 500}, {"owner": "AIUSER", "name": "ORDER_ITEMS", "record_count": 1000} ]' ); END; / 実行すると、顧客 50 件、製品 250 件、注文 500 件、注文明細 1,000 件が生成されます。テストデータを手作業で作り込まなくても、クエリ、レポート、アプリケーションロジックの検証に使える現実的なデータセットが手に入ります。 内部では、Oracle が対象テーブルの DDL、制約、メタデータを読み取り、データ型と外部キーを満たす現実的な行を生成するよう LLM にプロンプトを出します。生成方法は次の要素でカスタマイズできます。 sample_rows : 既存のレコードを例として渡し、生成されるデータを実データのスタイルに合わせます。 user_prompt : 「英国の郵便番号のみ」「2009 年公開の映画」といったルールを指定します。 テーブル統計 (デフォルトで有効): 列の最大値・最小値と個別値のリストを使って出力範囲を制限します。 列コメント: 列にヒント (例: 許可される Status の値) を付けると、LLM は生成時にヒントに従います。 一意制約: LLM のレスポンスから重複行を自動的に破棄します。 ステップ 8: Select AI で自然言語クエリを実行する プロファイルを設定してデータを投入したら、 SELECT AI の SQL 構文で平易な英語のままリレーショナルデータを照会できます。Oracle はステートメントを受け取り、質問と object_list のテーブルスキーマメタデータを組み合わせたプロンプトを構築し、Amazon Bedrock のモデルを呼び出して結果を返します。 実行前に生成された SQL を確認する showsql を使うと、LLM が生成した SQL を実行せずに確認できます。精度の検証や信頼性の確認に役立ちます。 SELECT AI showsql how many customers do we have per country; 出力例: SELECT country, COUNT(*) AS customer_count FROM customers GROUP BY country ORDER BY customer_count DESC 実行して結果を返す runsql に切り替えると、生成された SQL を実行して結果を返します。 SELECT AI runsql how many customers do we have per country; SELECT AI runsql what is the total revenue by product category; SELECT AI runsql who are the top 3 customers by total spend; SELECT AI runsql how many orders were cancelled; SELECT AI runsql show me all pending orders with customer name and amount; 結果を自然言語の文章で返す narrate アクションは、クエリ結果を平易な英語で要約して返します。ビジネスレポートやダッシュボードに適しています。 SELECT AI narrate give me a sales summary for 2024; SELECT AI narrate who are our best customers and what do they buy; 1 つ目のクエリの出力例: Based on the 2024 sales data, total completed revenue is $14,299.98 across six completed orders. Frank Wilson is the top-spending customer at $7,000.00, followed by Alice Johnson at $6,099.99. The Software category leads all product categories in revenue. Two orders remain in Pending status with a combined value of $2,500.00. 既存の SQL を平易な英語で説明する explainsql アクションは、既存の SQL クエリを受け取って平易な英語の説明を返します。ドキュメント作成やオンボーディングに役立ちます。 SELECT AI explainsql SELECT c.first_name, c.last_name, SUM(o.total_amount) AS total FROM customers c JOIN orders o ON c.customer_id = o.customer_id WHERE o.status = 'COMPLETED' GROUP BY c.first_name, c.last_name ORDER BY total DESC; 出力例: Query Analysis & Oracle SQL Conversion Original Query Issues: - Missing schema names - Missing double quotes around case-sensitive identifiers - 'COMPLETED' is not in double quotes in the question; must use UPPER() for case-insensitive comparison Converted Oracle SQL: SELECT c."FIRST_NAME" AS first_name, c."LAST_NAME" AS last_name, SUM(o."TOTAL_AMOUNT") AS total FROM "AI_TEST"."CUSTOMERS" c JOIN "AI_TEST"."ORDERS" o ON c."CUSTOMER_ID" = o."CUSTOMER_ID" WHERE UPPER(o."STATUS") = UPPER('COMPLETED') GROUP BY c."FIRST_NAME", c."LAST_NAME" ORDER BY total DESC; ステップ 9: DBMS_CLOUD_AI.GENERATE() を他の AI タスクに使う SELECT AI 構文に加えて、 DBMS_CLOUD_AI.GENERATE() を使うと Amazon Bedrock のモデルに直接アクセスできます。自由形式のチャット、要約、プロンプトからの SQL 生成のように、データベースのスキーマコンテキストを必要としないタスクに使えます。 テキストを要約する SELECT DBMS_CLOUD_AI.GENERATE( prompt => 'Oracle Database 26ai introduces AI Vector Search, hybrid BM25 and semantic search, an embedded ONNX inference runtime, SQL/PGQ property graph queries, JSON-Relational Duality Views, native BOOLEAN type, and lock-free reservations for high-concurrency workloads.', profile_name => 'CLAUDE_SONNET', action => 'summarize' ) AS summary FROM dual; インラインのテキストを要約するだけでなく、 DBMS_CLOUD_AI.GENERATE を Amazon Simple Storage Service (Amazon S3) バケットに保存された文書を直接処理することもできます。次のクエリは Amazon S3 から PDF を取得し、 DBMS_VECTOR_CHAIN.UTL_TO_TEXT でテキストに変換します。そのうえで内容を LLM に渡して要約させます。ここまでを 1 つの SQL ステートメントで実行します。 SELECT DBMS_CLOUD_AI.GENERATE( prompt => DBMS_VECTOR_CHAIN.UTL_TO_TEXT( DBMS_CLOUD.GET_OBJECT( credential_name => 'AWS', object_uri => 'https://s3.us-west-2.amazonaws.com/<Bucket Name>/<File Name>')), profile_name => 'CLAUDE_SONNET', action => 'SUMMARIZE') FROM DUAL; / 内部では、3 つの関数が 1 つの SQL ステートメント内で連鎖します。 DBMS_CLOUD.GET_OBJECT が指定した認証情報を使って Amazon S3 バケットから PDF 文書を取得します。 DBMS_VECTOR_CHAIN.UTL_TO_TEXT がバイナリの内容を LLM が処理できるプレーンテキストに変換します。 DBMS_CLOUD_AI.GENERATE が抽出したテキストを AI プロファイル経由で Amazon Bedrock に送信し、要約を返します。Amazon RDS for Oracle インスタンスから Amazon S3 に到達できるようにするには、前提条件が 2 つ追加で必要です。1 つは Amazon S3 用の VPC ゲートウェイエンドポイントで、Amazon RDS のサブネットに関連付けられたルートテーブルに追加し、通信をパブリックインターネットから切り離します。もう 1 つは対象バケットへの s3:GetObject と s3:ListBucket の権限を付与する IAM ポリシーで、ステップ 4a で作成したユーザーにアタッチします。 トラブルシューティング 次の表に、遭遇しやすいエラーと根本原因、対処方法をまとめます。 エラー 根本原因 対処 ORA-30699: network connection failed: connection timed out bedrock-runtime の VPC エンドポイントがない、またはプロファイルの "region" が未指定か誤っている 正しいリージョンに bedrock-runtime の VPC インターフェイスエンドポイントを作成する。すべてのプロファイルに "region": "<your-region>" を追加する DNS がパブリック IP に解決される VPC エンドポイントでプライベート DNS 名が有効になっていない エンドポイントを編集してプライベート DNS 名を有効にする ORA-20400: HTTP 400 モデル ID が単一リージョン / オンデマンドの形式 (旧形式) になっている モデル ID にクロスリージョン推論の us. プレフィックスを追加する ORA-20404: HTTP 404 そのリージョンでモデルが利用できない、またはアクセスが有効になっていない Amazon Bedrock → モデルアクセスでリージョンでのモデルの利用可否を確認する。モデル ID が正しいことを確認する ORA-20400: HTTP 403 IAM ユーザーに bedrock:InvokeModel の権限がない BedrockInvokeModelPolicy が IAM ユーザーにアタッチされているか確認する ORA-20001: profile not found プロファイルが作成されていない、または名前が間違っている SELECT profile_name FROM user_cloud_ai_profiles を実行する ORA-29024: Certificate validation failure Oracle ウォレットに Amazon Bedrock の CA 証明書がない Amazon RDS では file:/rdsdbdata/rds-metadata/dbms_cloud_wallet にプリインストールされたウォレットに必要な CA が含まれているため、対応は不要 クリーンアップ この手順で作成したリソースを削除するには、次を実行します。 -- Drop AI profiles EXECUTE DBMS_CLOUD_AI.DROP_PROFILE('CLAUDE_SONNET'); EXECUTE DBMS_CLOUD_AI.DROP_PROFILE('NOVA_PRO'); -- Drop the Bedrock credential EXECUTE DBMS_CLOUD.DROP_CREDENTIAL('AWS'); -- Drop sample tables (if created for this walkthrough) DROP TABLE order_items; DROP TABLE orders; DROP TABLE products; DROP TABLE customers; AWS マネジメントコンソールでは、次の手順を実行します。 IAM → ユーザー で、ステップ 4a で作成した IAM ユーザーを削除します。 VPC → エンドポイント で、 bedrock-runtime の VPC インターフェイスエンドポイントを削除します。 まとめ 本記事では、AI プロバイダーとして Amazon Bedrock を使い、Amazon RDS for Oracle Database 26ai で Select AI を設定する一連の手順を説明しました。IAM コンソールでの AWS 認証情報の作成、Oracle への認証情報の格納、VPC エンドポイントのセットアップ、自然言語クエリの実行までを、パブリックインターネットアクセスのないプライベートな Amazon RDS インスタンスで行いました。 Select AI を使えば、データを活用する人に SQL のスキルは不要になり、AI のロジックは信頼できる Oracle 環境の内側に留まります。ビジネスアナリストは SQL Developer や Oracle に接続したツールから、平易な英語で本番データを直接照会できます。データベース管理者は、モデルに公開するテーブル、有効にする基盤モデル、使用する IAM 認証情報を完全に制御し続けられます。いずれも Oracle 標準のプロファイルと認証情報の仕組みで管理できます。 本記事は Oracle Database 26ai と Amazon Bedrock を扱う 3 回シリーズの第 1 回です。 第 1 回 (本記事): Amazon RDS での Select AI と DBMS_CLOUD_AI による自然言語クエリ。 第 2 回: Oracle 26ai のネイティブなベクトル検索と Amazon Bedrock による RAG パイプラインの構築。 第 3 回: Amazon RDS 上の Oracle Database 26ai と Amazon Bedrock によるデータベース内 GraphRAG。 著者について Yamuna Palasamudram Yamuna は AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトです。AWS のリレーショナルデータベースチームで、Oracle などの商用データベースエンジンを担当しています。お客様と協力して AWS 上のリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援し、技術的なガイダンスを提供することにやりがいを感じています。 Ibrahim Emara Ibrahim は Amazon Web Services のデータベーススペシャリストソリューションアーキテクトで、AWS のお客様向けにデータベースソリューションの設計と実装を担当しています。Oracle、PostgreSQL、Amazon Aurora、AWS Database Migration Service に関する専門知識を活かし、クラウド移行の推進とデータベースパフォーマンスの改善に取り組んでいます。 Minu Hong Minu は AWS の Amazon RDS for Oracle のシニアプロダクトマネージャーです。クラウドネイティブかつ AI を活用したソリューションで、お客様がデータの可能性を最大限に引き出せるよう支援することに情熱を注いでいます。仕事以外では、旅行、テニス、スキー、料理を楽しんでいます。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

Gilead (訳注: 米国バイオ製薬企業) 傘下の企業である Kite (訳注: がん治療に特化した米国医薬品企業)は、細胞治療によって治癒を実現することに注力しており、現代の研究が求める規模と複雑さに対応するため、バイオインフォマティクス基盤を進化させてきました。断片化されたプロジェクト固有のワークフローから、標準化されたクラウド対応のアプローチへ移行することで、Kite は一貫性を高め、運用負荷を軽減し、研究チーム全体で計算ツールへのアクセスを拡大しました。 この取り組みは、複雑な生物学的データを、細胞治療候補の開発に資する知見へと変換する Kite の能力を支えています。これらの変化は、プログラム横断での再現性とスケーラビリティを支えると同時に、科学者がますます複雑化するデータセットから知見を生み出すことにより集中できるようにします。この移行には、レガシーな SaaS プラットフォームから、バイオインフォマティクスのワークフローを高速化するマネージドサービスである AWS HealthOmics への移行が含まれています。 この移行により、バイオインフォマティクスの科学者にとっての効率とコスト管理が改善されると同時に、既存のラボシステムを通じて、より広範なセルフサービス型の計算ワークフローへのアクセスが可能になりました。 課題: 細胞治療のR&Dに向けたバイオインフォマティクスのスケール Kite のバイオインフォマティクス・ゲノミクス部門は、自社ラボで生成した高次元オミクスデータと、公共リポジトリのデータの双方を活用し、治療標的の特定と新規細胞治療の設計を行っています。しかし、このミッションを支える基盤は、科学の進展に合わせて進化させる必要がありました。 プロジェクトごとに、バイオインフォマティシャンはインデックス作成、アライメント、定量化にどのツールを使うかをゼロから判断する必要がありました。スクリプトはローカルマシン、専用サーバー、 AWS Batch 環境などに散在し、プロジェクト間で一貫性がありませんでした。ロギング、実行（ラン）の追跡、成果物の登録に関する標準的なプロセスも存在しませんでした。プロジェクトが完了した際、そのメタデータを誰が所有し、どこに記録すべきかが不明確でした。 「複数のサンプルやプロジェクトにわたって、ワークフローとデータ管理に一貫性をもたらしつつ、チーム横断での再現性とアクセス性を改善できる仕組みが必要でした」と、Kite Pharma のバイオインフォマティクス ディレクターである Alexander Falk 氏は述べています。「HealthOmics 導入以前は、バイオインフォマティクスのパイプラインを実行するには、個々のバイオインフォマティシャンがそれぞれ独自のツールや手法を用いて対応する必要があり、その結果、ワークフローの不統一、高い調整コスト、コミュニケーションのサイロ化が生じていました。また、出力の保存方法や再現性のための結果の文書化についても標準化されたアプローチがありませんでした。私たちの目標は、既存の LIMS と統合された標準化パイプラインを実装し、より広範で一元化されたアクセスを可能にすることでした」 — Alexander Falk 氏、Kite Pharma バイオインフォマティクス ディレクター これらの課題に加えて、サードパーティ製の SaaS ワークフロープラットフォームに対して多額のライセンス料を支払っていましたが、チームは十分に活用しきれていませんでした。この固定費型のライセンスモデルは、断続的・散発的にバッチ処理が発生する製薬 R&D のパターンとかみ合っていませんでした。また、科学者たちは、検体の受け入れ（アクセッショニング）や実験の追跡において、既存の電子実験ノート（ELN：Electronic Laboratory Notebook）を唯一の信頼できる情報源として使用していました。そのため、新たなコンピューティング基盤は、このシステムを置き換えるのではなく、連携できることが求められました。 Kite で最も計算負荷の高いワークロードの 1 つであるシングルセル・トランスクリプトーム解析は、スケーリングの課題を一層深刻なものにしていました。臨床試験プログラムの拡大に伴って全体の検体数が増加する中、ローカル環境での計算処理はもはや現実的な選択肢ではありませんでした。チームには、事前にキャパシティを確保することなく利用できる、柔軟に拡張できる（エラスティック）基盤が必要でした。 目標は、その場しのぎのスクリプト作成から脱却し、ELN と完全に統合された、より標準化・再現可能なアプローチへ移行し、運用の複雑さを軽減しつつ、データから知見を生み出す効率を高めることでした。 スケーラブルなクラウド型バイオインフォマティクスアプローチの実装 AWS Professional Services との協業により、Kite はオンプレミスのシーケンシング基盤とクラウドベースのバイオインフォマティクス ワークフローを接続する、完全自動化・イベント駆動型のゲノミクス パイプラインを設計・展開しました。これらはすべて、科学者が使い慣れた ELN インターフェースを通じてオーケストレーションされます。 イベント駆動アーキテクチャ 全体像として、このソリューションはシーケンサーから科学者までを結ぶ自動化されたデータフローを実行します。 バイオインフォマティシャンがシーケンシングの実行をトリガーし、データセンター内でデマルチプレックスを行って FASTQ データを生成します。 AWS DataSync が、Kite のオンプレミスのファイル共有から Amazon S3 へ、自動スケジュールで FASTQ ファイルをコピーし、手動でのファイル転送を不要にします。 FASTQ ファイルが S3 に到着すると、 AWS Lambda 関数がファイルヘッダーを解析してシーケンシングのメタデータ（機器 ID、ラン ID、フローセル ID、サンプル識別子）を抽出し、REST API を介して ELN に構造化されたレコードを作成します。 ELN インターフェースから、バイオインフォマティシャンが FASTQ エントリ（レコード）を特定の HealthOmics ワークフローに関連付け、パラメータを設定します。 この操作により、ELN が持つ Amazon EventBridge とのネイティブ統合を通じてイベントが発行されます。これが前処理用の Lambda 関数をトリガーし、入力ペイロードを構築して、AWS HealthOmics のプライベート ワークフロー実行を開始します。 次に AWS HealthOmics が、コンテナ化された Nextflow パイプラインを、フルマネージドかつエラスティックな計算リソース上で実行します。プロビジョニングや保守が必要なインフラはありません。ワークフロー出力は、処理済みデータ用のAmazon S3 バケットに生成されます。 ワークフローが完了すると、HealthOmics はステータスイベントを EventBridge に発行します。これが後処理用の Lambda をトリガーし、結果、品質メトリクス、出力ファイルの場所を ELN に書き戻します。 障害処理専用のLambda 関数が Amazon SQS のデッドレターキューをポーリングし、失敗したトランザクションを再処理することで、データの損失がないようにします。 図：Kite Pharma のイベント駆動型アーキテクチャ。Kite のオンプレミスストレージ、Kite の ELN、および AWS サービスの統合を示しています。AWS への自動データ転送を実現し、エンドユーザーからはインフラを抽象化して、ELN をインターフェースとして AWS 上でオミクスデータを処理できるようにします。 研究者の体験 研究者から見ると、クラウド基盤は目に見えません。バイオインフォマティシャンは、自分のワークフロー用にあらかじめ用意された ELN テンプレート（例：「nf-core による scRNA-seq」）を開き、サンプルのエンティティや、参照ゲノム・コア数といったパラメータを入力し、ワークフロー実行を登録します。登録すると、CLI やコンソールへのアクセス、インフラの知識を一切必要とせずに、自動的に実行が開始されます。実行ステータスは進行に応じて ELN 上で動的に更新され、完了すると出力ファイルは親のワークフロー実行に自動的にリンクされ、完全な来歴（プロベナンス）と追跡可能性（トレーサビリティ）が維持されます。 「残された課題の 1 つは、チーム横断で標準化されたワークフローとパラメータについて足並みをそろえることです。これは逆に言えば、技術的な複雑さの多くが日常利用から切り離されて意識されていないことを物語っています。」と、Kite Pharma のバイオインフォマティクス エンジニアリング担当アソシエイト サイエンティストである Tanner MacPhee 氏は述べています。「このプロジェクトの目標は、スケーラブルなバイオインフォマティクス ワークフローを実行する手段を提供することだけでなく、Kite の広範な科学コミュニティ全体でメタデータの取得、モニタリング、アクセス性を改善することでもありました。ELN を入口とすることで、ユーザーは基盤となるインフラを直接管理することなく、自身の ELN エントリとワークフローを直接統合できます。」 — Tanner MacPhee 氏、Kite Pharma バイオインフォマティクス エンジニアリング担当アソシエイト サイエンティスト 主要な設計上の判断 この設計は、Kite の研究および運用上のニーズに沿ったいくつかの優先事項を反映しています。呼び出しごとに課金の Lambda 関数とワークフローの実行ごとに課金される HealthOmics を用いた「サーバーレス ファースト」のアプローチは、アイドル状態のインフラコストを削減するのに役立ちます。双方向の ELN 統合により、メタデータは REST API を介して ELN に書き込まれ、一方で ELN は EventBridge を介して AWS 上のワークフローをトリガーします。プライベート ワークフローにより、Kite はコンテナ化された Nextflow パイプライン、ツールのバージョン、パラメータを完全に制御できます。ソリューション全体は再現性のために Terraform でデプロイされ、すべての Lambda 関数はネットワークレベルのセキュリティ分離のために Kite の VPC 内で実行されます。 成果: 効率化とスケーラブルなアクセス 本番稼働以降、このソリューションはコスト効率、ワークフロー実行、科学者のエクスペリエンスにわたって運用面での改善をもたらしてきました。ソリューションは 18 か月以上にわたり本番環境で稼働しており、AWS HealthOmics 上に 20 種類のバイオインフォマティクス ワークフローが展開され、シングルセル RNA シーケンシング（scRNA-seq）、バルク RNA-seq、全エクソームシーケンシング、タンパク質構造予測、その他の次世代シーケンシング ワークロードを処理しています。 このアプローチはまた、研究ニーズに沿った計算リソースの効率的な利用を可能にし、従来のワークフローにあった非効率を排除しました。「この統合により、解析を実行するために必要だった手作業のステップと依存関係の数が削減され、効率が向上し、チームがデータから知見へとより速く進めるようになりました」と Falk 氏は述べています。 バイオインフォマティクスの科学者たちは、その場しのぎの解析に費やす時間が大幅に減ったと報告しています。インフラのプロビジョニングからメタデータの登録に至るまでの手作業のステップを削減したことで、チームは新規の開発や科学的な業務により多くの時間を割けるようになりました。 現在、100 名を超える研究者が ELN 統合を通じてバイオインフォマティクス ワークフローにアクセスできるようになっています。ワークフローテンプレートに Wiki のような補足情報が付与されているため、たとえば分子生物学者が「タンパク質構造予測（protein structure prediction）」を検索すると、利用可能な AlphaFold Multimer ワークフローを直接発見でき、バイオインフォマティクス担当者を介さずにチーム間の壁（サイロ）を解消につながります。展開済みの 20 種類のワークフローのうち 5 種類は、セルフサービスでの実行のために ELN と完全に統合されており、さらに継続的に追加が進められています。 シーケンサーから直接取得されるデータから、前処理、ELN への登録、そしてクラウドベースのワークフロー内での解析実行に至るまでのフロー全体が、バイオインフォマティクス担当者の介在なしに動作します。このエンドツーエンドの自動化は、18 か月以上にわたって継続的に本番稼働しています。 今後の展開 Kite は AWS HealthOmics を含むクラウド活用型バイオインフォマティクスツールの利用をさらに広げています。デプロイ済みの 20 個のワークフローすべてを ELN からセルフサービスで実行できるようにし、管理されたオントロジーやバリデーション要件との整合も図る計画です。パイプラインの数が増えるのに合わせて、継続的インテグレーションとデプロイの仕組みも強化し、ワークフローのバージョン管理にかかる手作業を減らしています。 さらに先を見て、パイプラインの作成、バリデーション、更新を速めるための AI ベースのツールやエージェントも検討しています。汎用コンピューティング、データカタログ、マルチモーダルな研究データセットでのチーム間コラボレーションに向けた追加ツールの評価も進めています。 「Kite のバイオインフォマティクス＆データサイエンスの領域では、AI によって、バイオインフォマティクスのパイプラインをより迅速かつ一貫して構築、反復、テスト、デプロイできるようになっています。運用のオーバーヘッドを削減し、開発者にかかる時間とコストの負担を軽減しつつ、ワークフロー全体の標準化と検証プロセスを改善しています。HealthOmics により、トランスクリプトミクスからタンパク質・RNA のフォールディングや構造予測に至るまで、計算負荷の高いオミクス解析を、インフラの深い専門知識を必要とせずに実行できます。バイオインフォマティクス データの生成と取り込みが増え続ける中で、効果的なメタデータの取得、登録、検索性の重要性が一層高まっています」と MacPhee 氏は述べています。 — Tanner MacPhee 氏、Kite Pharma まとめ Kite の経験は、同様の課題に直面する製薬・バイオテクノロジー企業に向けた、バイオインフォマティクス基盤の近代化に関するより広範なアプローチを映し出しています。すなわち、科学者のワークフローを妨げることなく、いかにしてバイオインフォマティクス基盤をモダナイズするか、という課題です。既存のラボシステムとの緊密な統合を維持しながら、効率性、標準化、ワークフローへのアクセス性を改善することで、Kite は患者に細胞治療を届けるというミッションに、より多くのリソースを集中できます。 「私たちは、HealthOmics と AWS のサービス群を引き続き活用し、研究者が次世代の治癒的細胞治療を患者のために構築できるよう、革新的な方法を開発していけることに大きな期待を寄せています」と Falk 氏は述べています。 — Alexander Falk 氏、Kite Pharma AWS HealthOmics をはじめよう バイオインフォマティクスのワークフローをモダナイズする準備はできましたか？ AWS HealthOmics のページ で、マネージド基盤によって、あなたのチームがサーバーではなくサイエンスに集中できる方法をご確認ください。無料利用枠でのパイロットから始める、すぐに実行可能な (Ready2Run) ワークフローを試す、あるいは AWS のゲノミクスチーム にユースケースをご相談いただけます。 参考資料 AWS HealthOmics の機能と料金 AWS for Health and Life Sciences AWS HealthOmics と Amazon EventBridge を使ったバイオインフォマティクスワークフローのイベント駆動アーキテクチャ設計 Kite は Gilead 傘下の企業で、CAR T 細胞療法における世界的なリーダーです。詳しくは kitepharma.com をご覧ください。 原文は こちら です。 著者について Nadeem Bulsara AWS のプリンシパル Solutions Architect で、ゲノミクスとライフサイエンスを専門としています。バイオインフォマティクス、ソフトウェアエンジニアリング、クラウド開発で 13 年以上の経験と、研究および臨床のゲノミクス・マルチオミクスの知見を活かし、世界中のヘルスケア・ライフサイエンス企業を支援しています。人々が長く健康な人生を送れるようにするという業界のミッションが原動力です。 Naveen Garg Amazon Web Services のプロフェッショナルサービスチームに所属するシニアクラウドアーキテクトです。Fortune 500 企業のクラウド変革・移行の取り組みを支援しています。 Ryan Greene Amazon Web Services のグローバルヘルスケア・ライフサイエンスチームでシニアプロダクトマーケティングマネージャーを務めています。ビルダーとしての視点と、チームの働き方を変えることへの情熱を持ち、大規模で複雑な課題に取り組むのが好きです。2 人の幼い子どもから刺激を受けており、世界で最も規模の大きな顧客課題やワークロードに新しいアプローチで挑むことに関心を持っています。 Tanner MacPhee Kite Research Bioinformatics のバイオインフォマティクスエンジニアで、大規模オミクスデータを処理・解析するパイプラインの設計を専門としています。次世代の細胞治療の開発に取り組む科学者を支えることを目標に活動しています。バイオインフォマティクスの修士号を持ち、過去 8 年間、腫瘍領域で計算生物学チームと IT チームの両方と仕事をしてきました。 この記事は Solutions Architect の Masahiro Imai が翻訳を担当しました。

本ブログは 株式会社 PKUTECH と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 伊勢田氷琴です。 機密データを扱う SaaS を AWS 上で構築する際、どのサービスを組み合わせ、どのような設計判断を下せばよいのでしょうか。特に、お客様のコンプライアンス文書や監査指摘事項といった機微な情報を AI に処理させる製品では、データ保護、顧客環境への最小権限アクセスなど、考慮すべき論点がいくつも重なります。この記事では、PKUTECH が Amazon Bedrock をはじめとする AWS サービスを組み合わせて開発した純国産 AI-CSPM ソリューション「Egeria-Security」を題材に、機密文書を扱うセキュリティ SaaS の設計判断とその背景をご紹介します。クラウドセキュリティ（CSPM）運用に課題を抱える方々にとっても、その解決アプローチとして参考になる内容です。 セキュリティ SaaS が直面する 2 つの設計課題 Egeria-Security は、Cloud Security Posture Management（CSPM）の機能を提供する SaaS 製品です。CSPM とはクラウド環境のセキュリティ設定を継続的に監視・評価するソリューションを指します。課題を 2 つの視点から整理します。 まず、利用者側（CSPM を導入する企業）の課題です。多くの CSPM ツールには CIS Benchmark や NIST などの膨大な標準ポリシーセットがあらかじめ搭載されていますが、大量のアラートの中から「なぜその項目が自社のシステムに必要なのか」を理解するには高度な専門知識が求められます。また、自社のセキュリティ規程や監査法人からの独自指摘に合わせてカスタムルールを作成するには、ポリシー言語の深い理解が必要であり、技術的なハードルが高い状況でした。結果としてチェックの根拠がブラックボックス化し、「設定の逸脱を検知しても、どう直すべきか判断できない」「監査の際にチェックの正当性を説明できない」という状況に陥りがちです。 次に、提供者側（セキュリティ SaaS を開発する企業）の課題です。顧客のコンプライアンス文書や監査指摘事項は機密性の高い情報であり、SaaS のバックエンドで安全に処理する必要があります。加えて、LLM を活用する場合、入力データが学習に利用されないこと、推論トラフィックが閉域を通ること、顧客のクラウド環境へのアクセスが最小権限で制御されていること、これらをすべて同時に満たすことが望ましいです。 コンプライアンス文書を起点としたポリシー自動生成 PKUTECH は、2002 年の創業以来、NTT データグループをはじめとする大手企業向けのシステムインテグレーション事業を展開してきました。近年は自社プロダクトの開発にも注力しており、生成 AI を活用した Egeria シリーズを展開しています。 同社が着目したのは、自社のコンプライアンス文書そのものをスキャンポリシーの源泉にするというアプローチでした。既存の CSPM ツールは CIS Benchmark や NIST など汎用的な標準ポリシーセットを起点とするため、自社環境に関係のないアラートが混入しやすく、「なぜそのチェックが必要か」の根拠が読み手に伝わりにくいという課題がありました。Egeria-Security はこの順序を逆転させ、自社のコンプライアンス文書から出発して、そこに記載された推奨事項をそのままスキャンポリシーに変換する仕組みを採用しました。生成された各チェック項目には、推奨事項 ID・準拠フレームワーク・カテゴリ・重要度といった文書由来の根拠メタデータが紐づくため、スキャン結果の根拠をたどりやすくなります。 AWS を基盤として選択した理由 Egeria-Security の基盤として AWS を選択した理由は、主に以下の 3 点です。個別のサービス機能だけを比較すると類似の選択肢は他のクラウドベンダーにも存在しますが、機密データを扱うセキュリティ SaaS の全要件をバランスよく満たす組み合わせとして AWS を選択しました。 第一に、LLM 推論におけるデータ保護です。 Egeria-Security が処理するコンプライアンス文書には、組織のセキュリティポリシーや監査指摘事項など機密性の高い情報が含まれます。Amazon Bedrock では、ユーザーのデータがモデルのトレーニングに使用されないため、機密文書を LLM に投入する前提条件を満たします。 第二に、機密データを扱う AI SaaS に必要な要素が単一プラットフォーム内で統合されている点です。 生成 AI 推論（Amazon Bedrock）、RAG のベクトルストア（ Amazon OpenSearch Service ）、閉域ネットワーク（ Amazon Virtual Private Cloud (Amazon VPC) 、 AWS PrivateLink ）、認証・鍵管理（ AWS Identity and Access Management (IAM) 、 AWS Key Management Service (AWS KMS) ）、コンテナレジストリ（ Amazon Elastic Container Registry (Amazon ECR) ）、ロードバランシング（ Elastic Load Balancing ）、DNS（ Amazon Route 53 ）、証明書管理（ AWS Certificate Manager ）。これらの個々の機能は類似のものが他のクラウドにも存在しますが、同一のプラットフォーム・同一の認証基盤の上で統合的に運用・監査できることが、セキュリティ SaaS の説明責任の観点で重要でした。複数クラウドをまたぐ構成では、認証・ログ・監査の連携が複雑化し、セキュリティ製品としての信頼性確保に追加コストがかかります。 第三に、顧客 AWS 環境とのシームレスな接続です。 CSPM の主要な利用シーンは顧客の AWS アカウントをスキャンすることです。SaaS 基盤も AWS 上にあれば、 AWS Security Token Service （AWS STS）によるクロスアカウントアクセスなど、AWS ネイティブな統制で顧客環境との連携を実現できます。 こうした設計判断の結果として、GPU 推論基盤の構築・運用といった非差別化領域を AWS マネージドサービスに委ね、インフラ層のコンプライアンス証跡には AWS が提供する認証・レポートを活用できるようになりました。責任共有モデルのもとアプリケーション層の統制は同社が引き続き担いますが、開発リソースをコア差別化領域であるコンプライアンス文書の RAG 処理と Cloud Custodian DSL の自動生成ロジックに集中投下できました。PKUTECH の試算では、自前で LLM 推論基盤を構築した場合と比較して、GPU 調達・運用で 2〜3 人月、LLM ホスティング・スケーリングの開発で 3〜6 人月の工数が不要となり、SaaS の立ち上げリードタイムは約 12〜18 ヶ月の想定に対し約 4〜6 ヶ月で MVP 完成に至りました。 ソリューションの概要：コンプライアンス文書からスキャンポリシーを自動生成 Egeria-Security は、SaaS 型で提供される純国産の AI-CSPM ソリューションです。ユーザーはまず CIS Benchmark、NIST SP 800-53 などの標準フレームワークや、自社の社内規程、委託先管理基準などのコンプライアンス文書を PDF でアップロードします。次に、取り込んだ文書をもとに Amazon Bedrock を活用した AI チャットで対話しながら、自社に必要な「推奨事項」を抽出します。抽出した推奨事項から AI の支援を受けながら Cloud Custodian ポリシー（YAML 形式）を自動生成し、生成されたポリシーを用いて実際のクラウド環境（AWS や Azure）をスキャンします。スキャン結果は複数回にわたる違反の発生・解消の推移をタイムラインで追跡でき、改善状況を可視化します。 3 つの設計判断 Egeria-Security のアーキテクチャは、前述の AWS 選択理由と連動した 3 つの設計判断で構成されています。 図1: Egeria-Security の AWS アーキテクチャ 設計判断 1：コンプライアンス文書 → DSL 変換のためのエージェント設計 非定型な PDF（コンプライアンス文書）を、Cloud Custodian が解釈可能な YAML という厳格な DSL に変換する必要がありました。 開発初期は PDF ファイル全体をそのままプロンプトに投入し、1 ステップで YAML ポリシーを生成する方式を試みました。しかし、数十ページ規模の文書では存在しない AWS リソース名や属性の生成などハルシネーションが頻発し、「適切なアクセス制御を実施する」のような抽象的記述に対して具体的なチェックロジックに落とし込めない、同じ文書を再投入しても生成結果のばらつきが大きく再現性が確保できないといった問題が顕在化しました。 図2: 2 つのエージェント（前段 = 取り込み／後段 = ポリシー作成）と内部 4 ステップ これらの課題を解決するため、最終的に役割を 2 つのエージェントに分離し、Amazon OpenSearch Service 上の構造化ドキュメントを介して疎結合に繋ぐ構成としました。前段の PDF 取り込みエージェントが文書から「推奨事項タイトル」「論理的根拠」「監査手順」「修正手順」「重要度」「準拠フレームワーク」等の構造化データを抽出して Amazon OpenSearch Service に格納します。後段のポリシー作成エージェントは、まず Cloud Custodian の公式スキーマ（ custodian schema コマンド）から取得した有効リソースタイプ一覧を選択肢として推奨事項に対応するリソースを特定し、次に Amazon OpenSearch Service に格納された Cloud Custodian リファレンスのコード例を RAG で参照しながら YAML ポリシーを生成します。生成結果がリスト内に存在するかを厳格に検証することで、ハルシネーションを抑制しています。図2 は、この 2 つのエージェントが内部で実行する処理を 4 つのステップ（Step1 PDF 解析/構造化、Step2 対話、Step3 ポリシー生成、Step4 構文チェック/修正）として示したものです。Step1〜2 を前段の PDF 取り込みエージェントが、Step3〜4 を後段のポリシー作成エージェントが担います。後段は、スキーマ参照・自動修正・最終レビューを含む複数のノードで構成されます。 この設計の技術的なポイントは、「自由に書かせる」から「決められた選択肢から選ばせる」への発想転換です。Cloud Custodian の公式スキーマを選択肢の制約として用いることで、存在しないリソースタイプや属性の生成を抑制し、独自辞書を手作業で保守する範囲を減らしています。なお、この制約が担保するのは構文上の妥当性であり、生成されたポリシーが文書の意図に合致しているかは生成後のレビューで確認します。また、PDF 取り込みエージェントに構造化抽出の責任を集中させたことで、ポリシー作成エージェントが文書原文を直接扱う必要がなくなり、再現性の向上にも寄与しました。 設計判断 2：機密データの LLM 推論を閉域で完結させる コンプライアンス文書は SaaS のバックエンドから LLM に渡されますが、この経路がインターネットを通過しない設計としています。ユーザーがブラウザからコンプライアンス文書をアップロードする区間は HTTPS（TLS 暗号化）によるインターネット経由の通信ですが、SaaS バックエンドが受信した文書を LLM 推論に渡す経路は Amazon VPC 内で完結します。バックエンドは VPC 内に配置され、アプリケーション間の通信は VPC 内で閉じています。Amazon Bedrock への LLM 推論アクセスは VPC Interface Endpoint（AWS PrivateLink）を経由するため、バックエンドから Bedrock への経路は AWS バックボーンネットワーク内で処理が完結し、この通信にパブリックインターネットへの egress は発生しません。つまり、機密文書が LLM 推論に渡される区間を閉域で保護する構成です。 この閉域設計により、機密文書を扱う通信のうち外部に公開される経路を減らし、データ経路の制御と監査可能性を確保しています。設計にあたっては、AWS Well-Architected Framework のセキュリティの柱における「転送中のデータの暗号化とネットワーク経路の制限」のベストプラクティスを参照しています。 設計判断 3：顧客 AWS 環境への最小権限・最小干渉のアクセス CSPM として顧客環境をスキャンするには一定の権限が必要ですが、セキュリティ製品である以上、顧客環境への干渉は最小限でなければなりません。PKUTECH は当初、アクセスキー直接入力方式（長期キーの管理リスクが高い）、AWS Organizations 連携方式（運用負荷が大きい）、オンプレエージェント方式（SaaS としての即時性を損なう）といった代替案を検討しましたが、いずれも金融領域の厳格なセキュリティ要件や SaaS としての導入容易性と両立できないと判断し、最終的に AWS CloudFormation テンプレート + STS AssumeRole + ExternalID の組み合わせに至りました。 具体的には、お客様が自社の AWS マネジメントコンソールで CloudFormation の Deep Link を開くだけで Egeria-Security 専用の IAM ロールが作成されます。付与される権限は既定で AWS 公式の SecurityAudit マネージドポリシー（読み取り専用）であり、変更・削除権限は含まれません。スキャン実行時には、テナント ID とランダム値の複合キーを ExternalID として指定した STS AssumeRole により、有効期限 1 時間の一時認証情報を都度取得します。ExternalID の照合は、顧客側 IAM ロールの信頼ポリシーに設定された sts:ExternalId 条件によって行われます。AssumeRole 呼び出し時にはセッションタグでテナント ID を付与しており、顧客側の AWS CloudTrail で監査ログの追跡が可能です。SaaS 側で保存するのは Role ARN や ExternalID などの連携情報で、これらは AES-256-GCM により暗号化しています。AssumeRole で取得した一時認証情報は、スキャン実行環境で永続化せず使用後に破棄します。 この構成は金融領域に関わる IT 企業での PoC におけるセキュリティレビューを経て改修を重ねたものです。具体的には、IAM ロールテンプレートの用途別分離（顧客側がマネージドポリシー ARN を選択可能化）、ExternalID のテナント分離強化、セッションタグによる監査追跡の追加が、PoC 評価者のレビューを経て実装されました。 導入効果：PoC での実証 金融領域に関わる IT 企業での PoC 検証を経て、以下の効果が確認されました。 導入の初期障壁の低さ PoC では、コンプライアンス文書の登録からポリシー生成、スキャン実行までの一連の流れが問題なく実行できることが確認されました。エージェントレスかつ文書ベースのポリシー自動生成のため、SaaS 型で提供する場合、デプロイから文書登録、スキャン実行までは 1 営業日以内に完了できる見込みです（PKUTECH の試算）。また、PoC 評価者からは「AWS や Azure の専門知識がなくてもスキャンに必要なポリシーを容易に設定可能」との評価をいただいており、Cloud Custodian の YAML 構文を意識することなくポリシーを策定できることが確認されました。 ポリシー網羅率 PoC で取り込んだコンプライアンス文書から自動生成された有効ポリシーは、取り込み観点の約 50〜60% をカバーしました（この数値は取り込んだ観点のうち実行可能なポリシーとして生成できた範囲を示すもので、生成結果の修正不要率や検知精度を表すものではありません）。残りの 40〜50% は「適切なアクセス制御を実施する」のような抽象的記述や、Cloud Custodian が直接扱えない人手プロセス（ドキュメンタリ統制等）で、別途人手での運用設計が必要です。PoC 評価者からは「文書ベースで半分のポリシーが自動生成できるだけでも、実装工数の短縮になる」とのご評価をいただいています。 CNAPP 化に向けた今後の展開 PKUTECH は、Egeria-Security の CSPM 機能を起点として、AI を活用した CNAPP（Cloud Native Application Protection Platform）の実現を目指しています。今後、クラウドユーザーのアクセス権・特権を自動チェックする AI-CIEM、クラウド環境内の脅威やポリシー違反を検出する AI-CWPP、Infrastructure as Code で記述されたインフラ構成を自動チェックする AI-IaC スキャンを順次追加する予定です。 お客様の声 本プロジェクトを主導した PKUTECH クラウド＆セキュリティ事業部長の渡部寿春氏は、次のようにコメントしています。 「Amazon Bedrock を PrivateLink 経由で利用する閉域設計により、機密文書の AI 推論をインターネットに出すことなく実行でき、セキュアなセキュリティガバナンスを実現できました。金融領域に関わる IT 企業での PoC でも実証された通り、コンプライアンス文書を取り込む独自の AI アプローチにより、Cloud Custodian の専門知識がなくても自社基準に即したクラウドセキュリティ運用が可能となり、セキュリティ人材不足に悩む多くの企業のご支援に繋がると確信しています。」 また、PoC に参加された金融領域に関わる IT 企業のシステム部門ご担当者様からは、利用者側の視点でコメントをいただいています。 「従来の CSPM では、自社独自のセキュリティポリシーに合わせてルールをカスタマイズすることに高い技術的ハードルがありました。今回の PoC で Egeria-Security に自社のコンプライアンス文書を読み込ませたところ、ドキュメントの『構造化』精度が非常に高く、具体的な運用文書から自動的にシステムチェック観点へ落とし込める点に大きな可能性を感じました。既存の CSPM とは一線を画す明確な差別化ポイントがあります。今後のさらなる機能の成熟と安定性の向上により、エンタープライズのクラウドガバナンス運用において価値を発揮するソリューションになるものと期待しています。」 まとめ PKUTECH が開発した Egeria-Security は、自社のコンプライアンス文書を起点としてスキャンポリシーを自動生成するアプローチにより、CSPM 運用における監査説明性とカスタムポリシー作成のハードルを同時に下げるソリューションです。 本記事では、この製品を題材に、機密データを扱うセキュリティ SaaS を AWS 上で構築する際の設計判断を 3 つの視点から整理しました。コンプライアンス文書から DSL への変換では 1 ステップ生成の失敗から 2 エージェント分離に至った経緯、閉域設計では PrivateLink を活用した機密データ経路の制御、顧客環境連携では PoC のセキュリティレビューを経て改修を重ねた実践についてです。個々の AWS サービスの機能比較ではなく、機密データを扱う AI SaaS に必要な要素が単一プラットフォーム上で統合的に利用できることが、本事例における AWS 選択の決め手でした。 同様の課題を抱える SaaS ベンダーや、生成 AI を自社製品に組み込もうとする企業にとって、設計の参考になれば幸いです。クラウドセキュリティの運用に課題を感じている方は、 Egeria-Security の製品ページ をご覧ください。Amazon Bedrock を活用した生成 AI ソリューションの構築に興味がある方は、 Amazon Bedrock の詳細ページ もあわせてご参照ください。本記事で取り上げた AWS サービスの詳細は、 Amazon OpenSearch Service 、 AWS PrivateLink 、 AWS CloudFormation の各ページをご覧ください。 左より PKUTECH：セキュリティエンジニア 遠藤 操希 氏 Amazon Web Services Japan：アカウントマネージャー 今井 彩渚 PKUTECH：デザイナー＆スクラムマスター 坂野 茉夢 氏 PKUTECH：AWS アーキテクト 杜 利民 氏 PKUTECH：クラウド＆セキュリティ事業部長 渡部 寿春 氏 PKUTECH：技術リーダー 釜石 智史 氏 PKUTECH：Python エンジニア 及川 大地 氏 Amazon Web Services Japan：ソリューションアーキテクト 伊勢田 氷琴 ソリューションアーキテクト 伊勢田氷琴

クラウドコンピューティングの初期の頃、AWS は世界中の都市で AWS Pop-up Lofts と呼ばれる物理的なスペースで建設業者を対象とした集中学習をサポートしていました。これらのスペースは、スタートアップ起業家、開発者、およびイベント、ミーティング、共同作業で AWS についてもっと知りたいと考えている人が利用できました。最近の生成 AI の登場により、 AWS Gen AI Lofts は世界中でポップアップスタイルのコラボレーションスペースを提供し、スタートアップや開発者に没入型の体験を提供しました。 私たちは、実践的な体験、コミュニティ主導の共有、技術的なコラボレーションを通じて、学生や開発者が学び、つながり、貢献できる常設のコミュニティスペースが必要であることに気づきました。2025 年 7 月にサンフランシスコでオープンして以来、最初の AWS Builder Loft は 22,500 人以上の開発者を迎え、地元の技術コミュニティが一堂に会するハッカソン、ワークショップ、デモナイト、コミュニティ主導のイベントを開催してきました。 2026 年 8 月 18 日、ベルリン、ハイデラバード、サンパウロに新しいビルダーロフトをオープンする計画を発表しました。各場所は、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コラボレーション/コワーキングエリア、イベント主催を提供する常設コミュニティスペースとなり、ドアを通り抜けたい開発者、学生、技術専門家向けに、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ作成スペース、コラボレーション/コワーキングエリア、イベントの開催が可能になります。 そこでは引き続き AWS の専門家に会うことができますが、それ以上に、 AWS User Groups や AWS Student Builder Groups 、すでに参加している独立した開発者グループまで、地域の技術コミュニティの本拠地を作りたいと考えています。テクノロジーコミュニティのリーダーとして、ミートアップを開催するためのスペースの予約を無料でリクエストしていただけます。 なぜ 3 都市なのか この拡張は、各地域の重要な人材とイノベーションの拠点である開発都市が急成長していることを反映しています。 ベルリン : AWS European Sovereign Cloud を立ち上げた後、私たちはヨーロッパの開発者コミュニティへの取り組みを深めています。ベルリンの Builder Loft は、デジタル主権に関する教育セッション、ハッカソン、セキュリティ対策ワークショップ、コミュニティミートアップを開催し、ドイツの成長を続けるスタートアップエコシステムと、より広範なヨーロッパおよび世界のテクノロジー環境をつなぐコミュニティミートアップを開催します。 ハイデラバード : Hyderabad Builder Loft は、インドの開発者に AI のスキルアップ、クラウドネイティブアーキテクチャの探求、次世代アプリケーションを構築する仲間との交流のための専用スペースを提供します。 サンパウロ : ブラジルのクラウド市場は毎年 30 % の成長を遂げており、サンパウロはラテンアメリカのテクノロジーブームの中心に位置しています。Builder Loft は、地域の開発者のハブとして機能し、地域社会、大学、スタートアップネットワークと連携して無料のプログラミングを提供します。 ビルダーロフトでの典型的な一週間 サンフランシスコの Builder Loft では、生成 AI に関する技術的なディープダイブからスタートアップのピッチナイト、学生向けのコーディングワークショップから地域全体の開発者が集まるネットワーキングセッションまで、毎週 4 〜 8 件のコミュニティイベントを開催しています。 スペースは柔軟に設計されています。火曜日の朝、トレーニングルームは 50 人以上の学生でいっぱいになります。夕方になると、スタートアップが潜在的なコラボレーターの部屋に最新のプロトタイプを披露するデモステージに変わります。週末には、コミュニティグループが独自のミートアップを開催します。 このモデルが機能する理由は、コミュニティ自体によって推進されているということです。地元の開発者、ミートアップ主催者、技術リーダーがプログラミングを形作ります。AWS はスペース、インフラストラクチャ、サポートを提供しますが、エネルギーは参加するビルダーから得られます。 今後のイベント を検索するか、サンフランシスコの Builder Loft での 独自のイベントの開催 をリクエストしてください。 ご期待ください Builder Loft は、今後のブログ記事で 3 都市でのオープンについて発表しますので、最新情報にご期待ください！ Builder Lofts の詳細を確認したり、最新情報を入手したりするには、 Rick のブログ投稿 と AWS Builder Loft のページ をご覧ください。 – Channy 原文は こちら です。

2026 年8 月 10 日週、 OpenSearch と Valkey のチームはソウルを訪問し、 Open Source Summit Korea 2026 と MCP DevSummit Seoul 2026 でオープンソース開発者とコントリビューターに会いました。4 日間のイベントでは、オープンソースプロジェクトと新興エージェント AI のコミュニティリーダーとユーザーが集まり、知識を共有し、ソリューションについて協力し、プロジェクトを推進しました。 韓国の OpenSearch コミュニティのリーダーたちがブースにボランティアとして参加し、 ユーザーグループのミートアップ でネットワークを作り、交流する時間もありました。 OpenSearch は、大規模な非構造化データに秩序をもたらすオープンソースのエンタープライズグレードの検索およびオブザーバビリティスイートです。2026 年 6 月 9 日、 OpenSearch 3.7 では、ログ、トレース、メトリックにわたる SLO のクエリ、アラート、追跡を単一のインターフェースから行い、ベクトルの取得を最大 5.5 倍高速化して検索パフォーマンスを向上させるように設計された新しいツールが導入されました。2026 年 7 月 30 日以降、 Amazon OpenSearch Service で OpenSearch バージョン 3.7 を実行できるようになりました。これにより、ベクトル検索のパフォーマンス、検索の関連性、クエリインサイトが向上します。 Valkey はオープンソースの高性能キー/値データストアで、キャッシュ、メッセージキューなどのさまざまなワークロードをサポートし、プライマリデータベースとしても機能します。2026 年 5 月 19 日、 Valkey 9.1 は再設計されたI/Oスレッドモデルを導入しました。これにより、スループットが最大 17％ 向上し、128 バイト未満の文字列のメモリ使用量が最大 20％ 削減されます。2026 年 6 月 23 日以降、ノードベースのクラスター用に Amazon ElastiCache で Valkey 9.1 を実行できるようになりました。これにより、マルチテナントワークロードのスループットが向上し、メモリ効率が向上し、アクセス制御が強化されます。 今後開催される OpenSearch と  Valkey のイベント で、当社のオープンソースチームに会うことができます。 8 月 10 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon EC2 アプリケーションステータスチェック : Amazon EC2 では、EC2 インスタンスのアプリケーションレベルの問題を検出して対応するのに役立つ新しいステータスチェックが導入されました。アプリケーションステータスチェックにより、EC2 はアプリケーションを監視して、リクエストの受け付けを停止したウェブサーバー、実行中の Docker デーモン、不適切なネットワーク構成、トラフィックを渡さなくなったネットワークインターフェイスなどの問題を検出します。詳細については、 アプリケーションステータスチェックのドキュメント をご覧ください。 AWS IAM ロールマネージャーによる IAM ロールの自動セットアップ: AWS サービスに必要な IAM ロールを自動的にセットアップする新しいロールマネージャーを使用できます。コンソールでサポートされているサービスを設定すると、ロールマネージャーはユーザーに代わってデフォルトのロールを作成するか、必要な権限と一致する場合はアカウントにすでに存在するロールを再利用します。ロールマネージャーは、起動時に 6 つの AWS サービスコンソールをサポートします。詳細については、「 AWS IAM ロールマネージャーが IAM ロールの開始点を再考する方法 」を参照してください。 OpenAI Daybreak は、Amazon Bedrock の対象となるお客様が利用できます : Daybreak は OpenAI のサイバー防衛イニシアチブで、防御側がサイバーセキュリティ業務のためにフロンティア AI にガバナンスを利用できるようにします。ほとんどのセキュリティチームにとって、GPT-5.6 Sol を搭載した Daybreak Blue は、脆弱性の発見、検出エンジニアリング、インシデント対応などの防御ワークフローの出発点となります。新しい GPT-5.6 Cyber を搭載した Daybreak Red は、脆弱性調査、エクスプロイトの複製、緩和策の開発など、承認された高度なタスク向けに設計されています。登録するには、OpenAI に連絡するか、AWS アカウントチームに連絡して資格に関するガイダンスを受けてください。詳細については、 AI ブログ記事 をお読みください。 Amazon SageMaker JumpStart の新しいファンデーションモデル : AWS のお客様が利用できるファンデーションモデルのポートフォリオを拡大しています。これらのモデルは、さまざまなエンタープライズ AI の課題に特化した機能で対処します。 NVIDIA の Nemotron 3.5 Lightning モデル NVIDIA の Nemotron-Nano-12b-V2、Z.ai の GLM-5.2 FP8、GLM-OCR モデル NVIDIA の LocateAnying-3B、QWEN-AgentWorld-35B-A3B、Qwen 3.5-122B-A10B モデル Black Forest Labsの FLUX.2-small-decoder と Google の gemma-4-12B-it モデル Redis の langcache-embed-v3-small、JetBrains の Mellum2-12B-A2.5B-Thinking、LightOn の LightOnOCR-2-1B モデル AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のプロジェクトやニュース項目をいくつかご紹介いたします。 AWS Certificate Manager (ACM) におけるメール認証の廃止 : ACM は、2027 年 9 月 30 日をもって、メール認証による公開証明書のサポートを終了します。ACM パブリック証明書に E メール検証を使用する場合は、その日までに DNS 検証に移行する必要があります。Amazon CloudFront ディストリビューションでは、HTTP 検証も利用できます。 CLI サポートと管理コントロールを備えた次世代 AWS VPN クライアント : OpenVPN3 上に構築された新しい AWS VPN クライアントを使用できます。新しいクライアントでは、既存の AWS Client VPN エンドポイントとの完全な下位互換性を実現すると同時に、エンタープライズネットワーキングチームが求めていた自動化機能とセキュリティ体制を実現できます。 Oracle AI データベース用 Exascale 上の Oracle Exadata @AWS : Exadb-XS は、消費ベースのモデルを通じて Exadata クラスのパフォーマンスと可用性を実現します。ExADB-xS を使用すると、コンピューティングとストレージを個別に少しずつ拡張でき、支払いは使用した分だけです。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 8 月 17 日週のニュースは以上です。8 月 24 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! — Channy 原文は こちら です。

ゲノム研究は、変革の岐路に立っています。シーケンシングデータが指数関数的に増加するなか、それに見合う高度な解析能力が求められています。 1000 Genomes Project によれば、典型的なヒトゲノムは参照配列 (リファレンス) に対して 410 万〜500 万か所で異なり、そのほとんどは一塩基多型（SNP）と短い挿入・欠失（indel）です。これらのバリアントは、多くの人のデータを合わせると、ポリジェニックリスクスコア（PRS：Polygenic Risk Score）として捉えられる疾患のかかりやすさの違いに寄与します。しかし、ゲノム解析ワークフローは、こうした大規模なバリアントデータを実際に活用できる知見へと変換することに苦労しています。ワークフローは依然として断片化しており、研究者はバリアントアノテーション、品質フィルタリング、 ClinVar のような外部データベースとの統合といった複雑なパイプラインを、手作業で組み立てる必要があります。 AWS HealthOmics のワークフローは、 Amazon S3 Tables および Amazon Bedrock AgentCore と組み合わせることで、これらの課題に対する変革的なソリューションを提供します。HealthOmics のワークフローは、Variant Call Format（VCF）ファイルに有用なオントロジーを付与するアノテーション処理をシームレスに統合できます。続いて、Variant Effect Predictor (VEP) でアノテーションした VCF ファイルを構造化データセットへ変換し、最適化された S3 Tables に格納します。これにより、大規模なバリアントコホート全体でのクエリ性能を高めます。Amazon Bedrock AgentCore 上で動作する Strands Agents SDK は、セキュアでスケーラブルな AI エージェントアプリケーションを提供し、研究者は専門的なクエリの知識を持たずとも、複雑なゲノムデータセットを扱えるようになります。 本ブログ記事では、エージェント型 (agentic) ワークフローが、自然言語インターフェースによって、ゲノミクスパイプラインの処理と解釈を大規模に高速化する方法をご紹介します。ここでは、自動化されたデータ処理とインテリジェントな解析を組み合わせた、包括的なゲノムバリアント解釈エージェントをデモンストレーションします。このエージェントは、生の VCF ファイルの取り込みから対話型クエリインターフェースまで、ワークフロー全体に対応します。最も重要な点として、このソリューションは、従来はゲノム解析を専門のバイオインフォマティシャンに限定してきた技術的な障壁を取り除きます。これにより、臨床研究者は生の VCF ファイルをアップロードし、たとえば「BRCA1 に病原性バリアントを持つ患者は誰か？」や「このコホートにおける薬剤耐性バリアントを見せて」といった質問を、すぐに投げかけられるようになります。本ソリューションのコードは、AWS 上のライフサイエンス向けスターターエージェントを集めた オープンソースのツールキット リポジトリで公開されています。 ゲノム解析におけるバリアントアノテーションの理解 ゲノムバリアント解釈の土台は、生の遺伝的バリアントを生物学的・臨床的な文脈に結びつける包括的なアノテーションパイプラインです。Variant Effect Predictor（VEP）と ClinVar は、現代のゲノム解析ワークフローにおける 2 つの不可欠な構成要素であり、それぞれが相互に補完的な情報を提供します。研究者は、意味のある知見を得るために、これらを統合する必要があります。 この比較図は、ClinVar と VEP による、ゲノムバリアント解釈のための、相補的でありながら異なるアノテーション機能を示しています。左側の ClinVar アノテーションは、主に臨床的意義の評価に重点を置き、キュレーションされた病原性分類（CLNSIG）、エビデンスの品質を示す指標（CLNREVSTAT）、そして臨床判断に直接関わる疾患との関連（CLNDN）を提供します。右側の VEP アノテーションは、影響 (コンシークエンス) タイプ（missense_variant、synonymous_variant、intron_variant）、影響度分類（HIGH、MODERATE、LOW、MODIFIER）、遺伝子シンボル、位置情報を含むトランスクリプトごとの効果など、包括的な機能情報を提供します。 現在のアノテーションワークフローの課題 バリアントアノテーションのワークフローは、通常、次のようなシーケンシャルなプロセスをたどります。 初期の VCF 処理：シーケンシングシステムから出力される生の Variant Call Format（VCF）ファイルは、表記を正規化し、低品質なコールを除去するための前処理が必要です。 VEP アノテーション：Variant Effect Predictor ツールの実行には多くの計算リソースを要します。特に、サンプルあたり数百万のバリアントを含む全ゲノムシーケンシングデータでは、その傾向が顕著です。VEP 解析は、利用可能な計算リソースとアノテーションの深さに応じて、ゲノムあたり 2〜8 時間かかることがあります。 ClinVar 統合：臨床アノテーションは ClinVar から取得し、別の処理でバリアントと照合する必要があり、データベース検索やフォーマット変換が求められます。 マルチサンプル統合：コホートレベルの解析を行うには、サンプル間で複雑な結合（join）操作が必要になります。これは通常、専用ツールで行われますが、生成されるのは大きくフラットなファイルで、効率的なクエリが困難です。 解釈：さらに科学者は、さまざまなツールを使って、アノテーション済みデータのフィルタリング、ソート、解析を行う必要があります。これは多くの場合、独自のスクリプトと相応のバイオインフォマティクスの専門知識を要します。この技術的なボトルネックにより、臨床研究者は自らのゲノムデータを自力では探索できず、生物学的な問いを立ててから答えを得るまでに数日から数週間の遅延が生じます。 データセットの複雑さと規模 ゲノムバリアント解析の規模を象徴するのが、 1000 Genomes Phase 3 Reanalysis with DRAGEN のようなデータセットです。このデータセットには次のものが含まれます。 多様な集団に由来する 2,500 を超える個別サンプル 全サンプルにわたる、約 8,500 万件のユニークなバリアント 整合させる必要のある複数のアノテーションバージョン（DRAGEN 3.5、3.7、4.0、4.2） SNP や indel に加えて、複雑な構造変異（structural variant） こうした複雑さは、フラットファイルの処理や手作業での統合ステップに依存する従来型の解析パイプラインにおいて、大きなボトルネックを生み出します。 ソリューションの概要 ゲノムコホートの構築や、複数の患者にわたって PRS を計算したりするには、 Variant Effect Predictor （VEP）のようなツールを用いて、結合されたバリアントコールテーブルと包括的なアノテーションを生成する必要があり、多くの計算リソースを要します。最も重要なのは、これらのワークフローが、SQL の専門知識とバリアントファイル形式への深い理解を持つバイオインフォマティシャンだけが意味のある知見を引き出せる、という技術的障壁を生み出している点です。その結果、臨床研究者は基本的なゲノムクエリでさえ専門の技術チームに依存せざるを得ません。 私たちの AI を活用したアプローチの変革的な利点は、自然言語による対話を通じてゲノム解析を誰もが使えるものへと民主化することにあります。従来の VEP パイプラインでは、「薬剤耐性遺伝子に高影響度 (high-impact) のバリアントを持つ患者は誰か？」といった臨床的な問いに答えるのに数日の技術的作業を要しました。一方、私たちのソリューションを使えば、研究者はこうした質問を会話形式で問いかけ、数分で答えを得られます。これは、技術への依存から、セルフサービス型のゲノム解析への移行を意味します。臨床研究者、腫瘍ボード（tumor board）、ゲノミクスチームは、バイオインフォマティクスの支援を待つことなく、自らのデータを直接探索できるようになります。 本ソリューションは、自動化されたデータ処理と、インテリジェントな自然言語解析を組み合わせた、生成 AI 活用型のゲノムバリアント解釈エージェントをデモンストレーションします。このアーキテクチャは、生の VCF ファイルの取り込みから対話型クエリインターフェースまで、ゲノム解析ワークフロー全体に対応します。 本ソリューションは、生のゲノムデータを実際に活用できる知見へと変換する、6 つの主要ステップで構成されます。 生の VCF 処理：シーケンシングプロバイダーからの生の VCF ファイルが Amazon S3 ストレージにアップロードされ、S3 イベント通知を通じて AWS Lambda 関数をトリガーします。この Lambda 関数が AWS HealthOmics のワークフローをオーケストレーションします。 VEP アノテーション： AWS HealthOmics のワークフローが、Variant Effect Predictor（VEP）を使って生の VCF ファイルを自動的に処理し、機能予測と臨床アノテーションを並列で付与してバリアントを強化します。その後、アノテーション済みの結果を S3 に格納します。 イベント連携： Amazon EventBridge がワークフローの完了を監視し、Lambda 関数をトリガーして、 Amazon DynamoDB 内のジョブステータスを更新します。また、 AWS Batch の Fargate コンピューティング環境で、PyIceberg モジュールを用いて、VEP アノテーション済み VCF ファイルと ClinVar アノテーションを Iceberg 形式に変換します。 データの整理：PyIceberg ローダーは Amazon S3 Tables の Iceberg REST エンドポイントと連携します。Amazon S3 Tables は、テーブルのメタデータを AWS Glue Data Catalog に登録します。アノテーション済み VCF と ClinVar アノテーションについて、スキーマ情報（列、データ型、パーティション）がカタログ化されます。また、下流の分析のための分析コネクタも確立します。 SQL による分析： Amazon Athena が、列指向 (カラムナ) 型ストレージ形式を通じてゲノムデータに対する SQL ベースのクエリ機能を提供します。これにより、数百万のバリアントにわたる大規模解析を、最適なクエリ応答で実現します。 自然言語による対話：AgentCore Runtime 上の Amazon Bedrock LLM を活用した Strands オーケストレーターエージェントが、Athena クエリを実行する 5 つの専用ツールを通じて自然言語インターフェースを提供します。 query_variants_by_gene：特定の遺伝子に関連するバリアントを取得します query_variants_by_chromosome：染色体単位のバリアント解析を可能にします compare_sample_variants：患者サンプル間の比較ゲノミクスを可能にします analyze_allele_frequencies：集団遺伝学的な知見を提供します execute_dynamic_genomics_query：柔軟なアドホック解析のリクエストに対応します このアーキテクチャには、きめ細かなアクセス管理のための AWS IAM と、モニタリングのための Amazon CloudWatch による包括的なセキュリティ制御が組み込まれています。この自動化されたイベント駆動型のパイプラインは、VCF ファイルのスケーラブルな並列処理をサポートし、増え続けるゲノムデータセットに自動的に適応しながら、一貫したアノテーション品質と分析能力を維持します。 PyIceberg を用いたAmazon S3 Tables : VCF から構造化コホートへの変換 PyIceberg と Amazon S3 Tables を組み合わせることで、VEP アノテーション済みの VCF ファイルを、構造化されたコホート、つまり AI 駆動の分析に最適化されたクエリ可能なデータセットへと変換します。これにより、自然言語インターフェースが複雑なゲノムデータと効率的に対話するためのデータ基盤が生まれます。 PyIceberg は、S3 Tables 形式で Apache Iceberg テーブルを作成し、次のような利点をもたらします。 最適なクエリ：エージェントは、最適化された列指向 (カラムナ) 型ストレージを通じて、数百万のバリアントにわたる複雑なゲノムクエリを最小限のレイテンシで実行できます。従来は数時間の SQL 開発と実行を要した分析が、対話による即時応答へと変わります。 豊富なアノテーションへのアクセス：VEP と ClinVar のアノテーションは、Amazon Athena を介した SQL で直接クエリ可能になり、AI エージェントが特定のゲノム知見を抽出できるようになります。 コホートレベルの解析：構造化された Iceberg 形式（PyIceberg）は、自然言語を通じた集団レベルのクエリのために、患者コホート間の効率的な比較が可能になります。 S3 Tables においてバリアントデータとアノテーションデータを分離することで、AI を活用した分析に適したデータ基盤となります。ゲノムバリアントの S3 Tables はエージェントが高速にフィルタリングできる中核的な位置情報が含まれ、一方でアノテーション／臨床情報の S3 Tables にはバリアントの解釈に必要な豊富な機能的・臨床的コンテキストが格納します。 この構造により、Strands エージェントは AWS Glue Data Catalog コネクタを通じて、ユーザーの質問に的確に答える、対象を絞ったクエリを構築できます。 生の VCF ファイルから構造化テーブルへのこの変換こそが、研究者が Amazon Bedrock AgentCore 上の Strands オーケストレーターエージェントを通じて、複雑なゲノムデータセットを会話形式でクエリできるようにするものです。 Strands Agents と AgentCore Runtime によるインテリジェントなゲノム解析 この対話型インターフェースは、私たちのゲノミクス AI ソリューションの中核をなすイノベーションであり、Strands Agents SDK を用いて構築され、Amazon Bedrock AgentCore Runtime 上にデプロイされています。この高度な AI エージェントは、複雑なゲノミクスの概念を理解し、自然言語のクエリを、構造化されたゲノムデータセットに対する適切な分析操作へと変換します。 AgentCore Runtime は、動的な AI エージェントとツールのデプロイおよびスケーリングのために専用設計された、セキュアでサーバーレスなランタイムです。本ソリューションは、ゲノム分析において次のような主要な利点をもたらします。 モデルとフレームワークの柔軟性：AgentCore のサービスは組み合わせ可能 (コンポーザブル) であり、Amazon Bedrock の内外を問わず、オープンソースまたはカスタムのフレームワークおよびモデルと連携します。 数時間規模の エージェント型ワークロード：最長 8 時間の長時間実行ワークロードと、最大 100MB のペイロードをサポートします。 セキュリティ：ユーザーセッションごとに専用のマイクロ VM（microVM）を割り当て、完全に分離します。 エンタープライズグレードの統合：AgentCore Identity と AWS IAM による認証を標準で備えています。 オブザーバビリティ：エージェントの推論とツール呼び出しを包括的にトレースします。 プライベートリソースへのアクセス：Amazon Virtual Private Cloud (VPC) 内のデータベースや API への接続が可能です。 市場投入までの時間短縮：AI エージェントソリューションのデプロイと開発のサイクルを加速します。 Amazon Bedrock AgentCore の機能に関する詳細は、 Amazon Bedrock AgentCore のドキュメント を参照してください。 Strands Agents は、エージェンティックループ（agentic loop）の概念を用いてゲノム解析ツールをオーケストレーションする、モデル駆動のアプローチにより、専門的な機能を備えたドメイン特化型 AI エージェントを構築するための堅牢な基盤を提供します。この反復的な推論フレームワークにより、エージェントは解析要件に応じて適切なツールを動的に選択・実行できます。私たちのゲノムバリアント解釈エージェントは、Amazon S3 Tables が作成した構造化データを活用する、次の 5 つの主要ツールを実装しています。 バリアントのクエリ：遺伝子ベースの質問を、関連するバリアントを取得する的確な Athena SQL クエリへと変換します。 染色体解析：自然言語を通じて、特定のゲノム領域を対象とした問い合わせを可能にします。 サンプル比較：SQL の結合 (join) を必要とせずに、患者横断のゲノム解析を可能にします。 集団頻度解析：1000 Genomes のような参照データセットに照らして、結果所見を文脈づけます。 動的なクエリ生成：複雑な自然言語のリクエストを、最適化された SQL へと変換します。 自然言語によるクエリ このエージェントは、多様な種類のクエリを扱う際に卓越した能力を発揮します。従来のモデルでは、臨床研究者はバイオインフォマティクスチームが独自のスクリプトを書き、複雑な解析を実行するのを待たなければなりませんでした。しかし今では、SQL クエリの作成や VCF ファイル形式との格闘に数日を費やす代わりに、研究者はゲノミクスの専門家と会話するように自然に、自らのゲノムデータを探索できます。 コホートレベルの分析 ユーザー 「このコホートについて、患者ごとのバリアント総数と病原性を表形式でまとめてください」 このクエリでエージェントは次の処理を行います。 execute_dynamic_genomics_query ツールを使用します。 コホート内のサンプル全体のバリアントデータを解析します。 患者数とバリアントの統計を含むコホートのサマリーを生成します。 結果を表形式で整理して提示します。 コホートレベルの頻度分析 ユーザー 「このコホートと 1000 Genomes で共有される、病原性または病原性の可能性が高いバリアントのアレル頻度を教えてください」 エージェントはこれを次のようなクエリへと変換します。 execute_dynamic_genomics_query ツールと analyze_allele_frequencies ツールを実行し、その患者の病原性バリアントの一覧を取得します。 臨床的に重要な病原性バリアントを絞り込み（フィルタリング）ます。 ClinVar から疾患レベルの情報を、VEP からアレル頻度を抽出します。 関連するコンテキストとともに結果を提示します。 併存疾患（コモルビディティ）のリスク関連分析 ユーザー 「chr10:111079820 の ADRA2A 遺伝子にバリアントを持つ患者は誰か。また、これらの患者はスタチンやインスリン抵抗性に関連する、追加の高影響度のバリアントを持っているか？」 このクエリに対して、エージェントは次のように動作します。 特定の疾患コンテキストについて、薬剤耐性経路における追加のリスクバリアントを検索します。 併存疾患に関して、個々の患者レベルで臨床的意義と結びつけます。 臨床と薬剤耐性経路を統合した臨床的示唆を提供します。 この自然言語インターフェースにより、研究者が複雑な SQL 構文を習得したり、基盤となるデータ構造を理解したりする必要が最小限になり、技術的背景を問わず、臨床チームと研究チームがゲノム知見へアクセスしやすくなります。 高度な分析処理 クエリに加えて、このゲノムバリアント解釈エージェントは、基本的なバリアント同定を超える高度な分析能力を発揮します。研究者は、従来は数日の解析を要した複雑な問いを探索できます。 臨床意思決定支援 ユーザー 「患者 NA21144 について徹底的な解析を行い、この患者のリスク層別化を提示してください」 このクエリに対して、エージェントは次のように動作します。 疾患経路の遺伝子やファーマコゲノミクスにおけるバリアントを解析し、エビデンスに基づく推奨を提供します。 バリアントの影響予測と臨床的意義の分類を組み合わせて、リスク層別化を行います。 意義不明のバリアント（VUS：Variant of Uncertain Significance）を特定します。 臨床的に重要な遺伝子における高影響度のバリアントにフラグを立てます。 ファーマコゲノミクスに基づく投薬戦略 研究者は、次のようなクエリを通じて、大規模コホートにわたる高度なファーマコゲノミクス経路解析にエージェントを活用できます。 ユーザー 「この患者コホートで、遺伝的バリアントが有意に集積している主要な薬剤関連経路はどれか。最も影響の大きいファーマコゲノミクス経路と、関連する患者 ID を教えてください」 これにより、バリアント頻度の分布、影響 (コンシークエンス) タイプのパターン、集団ごとの遺伝子レベルのバリアント負荷を、複雑な SQL やバイオインフォマティクスパイプラインを介さず、会話型インターフェースを通じて探索できます。 利点と制限事項 本ソリューションは現在の課題を次のように解決します。 課題 解決策 初期の VCF 処理 – 低品質なコール エージェントがバリアント解釈の判断前に、コールの品質を自動でチェックします 大規模な VEP アノテーション 20 件単位のバッチで VCF のアノテーションを自動化し、適切な計算リソースを使って必要な性能を確保します。 ClinVar との統合 エージェントがクエリの文脈を評価し、ユーザーの関心に応じて結合クエリを動的に組み立てます。 複数サンプルの統合 Iceberg 形式の Amazon S3 Tables と統合することで、VCF ファイルのコホートに十分な性能でクエリできます。 ゲノムの解釈 エージェントが文脈とユーザーの関心を理解し、アノテーションや自社データの適切なエビデンスに基づいて慎重に推論し、根拠のある判断を示します。 本ソリューションには、次のような制限事項があります。 Lambda ランタイムの制約：現在の実装では、VCF／GVCF 処理に AWS Lambda を使用しており、最大実行時間は 15 分です。大きな VCF ファイル、特に非常に大きな GVCF ファイルを Iceberg の S3 Tables に読み込む場合、これらの操作は Lambda のタイムアウト制限を大幅に超えることがあるため、この制約では不十分な場合があります。大規模なゲノムデータセットを扱う本番ワークロードでは、データ読み込み処理を扱うために、より長い実行時間を持つ AWS HealthOmics ワークフロー、AWS Batch、ECS タスク、または EC2 インスタンスの利用を検討してください。 スキーマ最適化のトレードオフ：本スキーマ実装では、サンプルおよび染色体によるパーティショニングを使用しており、患者レベルの解析に最適化されています。しかし、コホートレベルの解析では通常、大規模で最適なパフォーマンスを得るために、異なるパーティショニング戦略とスキーマ設計が必要です。数百サンプルを超えてコホートサイズが拡大するにつれ、単一のスキーマ内で患者レベルとコホートレベルの両方の分析を高性能に保つことは、ますます困難になります。大規模なコホート研究（数千〜数万サンプル）では、特定の分析パターンに最適化された別個のスキーマやマテリアライズドビューの実装、あるいは集団レベルのクエリをより適切にサポートする非正規化構造の検討を推奨します。 今後の技術的な発展 本ソリューションのモジュール型アーキテクチャは、AI 活用型ゲノム解析における継続的なイノベーションの基盤を確立します。将来のバージョンでは、追加のアノテーションデータベースや外部 API を統合し、ゲノムデータと臨床記録・画像を組み合わせたマルチモーダル解析のサポートが考えられます。ゲノムデータでのドメイン特化型のファインチューニングは解釈精度をさらに高め、電子カルテ（EHR）との統合は、診療現場（point-of-care）でのゲノム知見の提供を可能にするでしょう。 とりわけ有望な方向性が、医薬品研究機関 R&D におけるマルチエージェント連携です。このゲノムバリアント解釈エージェントが、薬剤プロファイリング、標的同定、文献エビデンス、仮説生成を担う専門エージェントと協調して動作できます。この協調的なエージェントフレームワークは、バリアントレベルの知見を治療開発へと直接つなぎ、遺伝的発見から臨床応用への橋渡しを効率化することで、創薬パイプラインを劇的に加速できます。 まとめ この次世代のゲノミクス エージェント型 AI ソリューションは、研究者や臨床医がゲノムデータとどのように対話するかという点で、根本的な変革をもたらします。自動化されたバリアントアノテーションとデータ変換を担う AWS HealthOmics と、インテリジェントな解釈のための Amazon Bedrock AgentCore をシームレスに統合することで、ゲノム解析ワークフロー全体をカバーする包括的なソリューションを実現しました。 自動化された VEP アノテーションワークフロー、VCF データをクエリ可能な Iceberg テーブルへ変換する S3 Tables、そして自然言語での対話のための Amazon Bedrock AgentCore 上の Strands Agents。これらの組み合わせにより、バリアントアノテーション、データ処理、臨床的解釈の間にある従来の障壁を最小化するシステムが生まれます。複雑な技術的プロセスを自動化し、直感的な対話手段を提供することで、研究者は技術的な実装の詳細ではなく、生物学的な問いそのものに集中できるようになります。 ゲノムデータが指数関数的に増え続け、臨床応用がますます高度化する中で、このようなシステムは、精密医療（プレシジョンメディシン）を前進させ、科学的発見を加速するための不可欠なインフラとなるでしょう。1000 Genomes Phase 3 Reanalysis データセットで示したこのソリューションは、大規模なゲノムコホートでさえ、シンプルな会話型インターフェースを通じて解析でき、高度なゲノム知見へのアクセスを誰もが使えるよう民主化できることを示しています。 本ソリューションのコードは Life sciences agents toolkit で公開されています。ぜひこのテンプレートを試し、発展させてみてください。Amazon Bedrock AgentCore を使い始めるためのサンプルについては、 Amazon Bedrock AgentCore リポジトリ をご確認ください。 原文は こちら です。 著者について Edwin Sandanaraj AWS のゲノミクス Solutions Architect です。神経腫瘍学の博士号と、ヘルスケアゲノミクスのデータ管理・解析における 20 年以上の経験を持ち、アジアパシフィックおよび日本でのプレシジョンゲノミクスの取り組みを豊富な知識で支えています。クラウドを活用したプレシジョンケアの実現に向けて、臨床ゲノミクスとマルチオミクスに強い関心を持っています。 Hasan Poonawala AWS のシニア AI/ML Solutions Architect で、ヘルスケア・ライフサイエンス分野のお客様を担当しています。AWS 上での生成 AI および機械学習アプリケーションの設計、デプロイ、スケーリングを支援しています。機械学習、ソフトウェア開発、クラウドでのデータサイエンスを合わせて 15 年以上の実務経験があります。休日は自然を巡ったり、友人や家族と過ごしたりするのが好きです。 Charlie Lee AWS のアジアパシフィックおよび日本におけるゲノミクス業界リードで、バイオインフォマティクスを専門とするコンピューターサイエンスの博士号を持っています。バイオインフォマティクス、ゲノミクス、分子診断で 20 年以上の経験を持つ業界のリーダーとして、最先端のシーケンス技術とクラウドコンピューティングを用いたゲノミクスで、研究の加速とヘルスケアの向上に情熱を注いでいます。 この記事はSolutions Architect の Masahiro Imai が翻訳しました。