2025 年 7 月 4 日（金）および 2025 年 12 月 17 日（水）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。登壇者の所属部署および肩書きは登壇当時のものとなります。 AWS メディア業界向け勉強会 #7（2025 年 7 月 4 日開催） ABC キャッチアップ配信 CMS をサーバーレスで構築してみた 朝日放送グループホールディングス株式会社 DX・メディアデザイン局 サービス開発チーム チーフ 金谷 洋佑 氏 朝日放送グループホールディングス株式会社では TVer や ABEMA 向けに公開している放送素材の管理を行う CMS を2016年頃から AWS 上で稼働していましたが、メタデータの仕様に大きな変更があったことや、Amazon EC2 と Amazon RDS をベースに構築したシステムで運用保守の負荷やコストに課題があったことから、サーバーレスサービスを用いた構成に全面刷新を行いました。CMS のフロントエンドは Amazon Cognito を用いたシングルサインオンと、 Amazon S3 の 静的ウェブサイトホスティング 機能を利用、バックエンドについては Amazon API Gateway 、 AWS Lambda 、 Amazon DynamoDB を中心に構成し、社外システムとの連携に関わる部分で AWS Secrets Manager や Amazon SES なども利用しています。 本システムに登録されている2万件を超える放送素材の中から、社内ユーザーは出演者などをキーに必要な素材の検索を行いますが、これらのメタデータの蓄積や検索を、これまで使っていた Amazon RDS ではなく Amazon DynamoDB を用いて実現したことが今回のシステム刷新の中での最大のチャレンジでした。放送素材は通常、シリーズ、シーズン、エピソードという3つの階層で管理されていますが、これを一つのパーティションキーで管理したり、配信先や入稿済みかどうかの情報も一つのソートキーで管理したりするなど、複数の情報を 複合キーで表現 することや、 グローバルセカンダリインデックス を活用することで、ランニングコストの低い Amazon DynamoDB 上で、複雑なクエリを高速に実行することを可能としました。 従来 Amazon EC2 上で動かしていたロジックは 90 近くの Lambda 関数に置き換え、 AWS Compute Optimizer による奨励事項を適用することで適切なメモリーサイズの指定とコストの低減を実現することができました。Amazon S3 上に保管する映像素材についても、 S3 Glacier Instant Retrieval ストレージクラス を利用することでコストの低減を実現しています。サーバーレスサービスの活用と上述のさまざまなコスト低減策によって、AWS の費用を従来の 1/3 まで削減できました。 ライブキリトリ・タテ型動画生成システム 『シン・キリトリ君』の開発 讀賣テレビ放送株式会社 DX推進局 放送DX部 但馬 晋二 氏 今回開発した『シン・キリトリ君』は、収録した映像素材を専用の編集機上で編集、別の PC に編集後の素材を転送して SNS へと投稿という、複雑な縦型動画の制作フローをもっと簡単に実現したいという社内のニーズから生まれた、動画の切り取りと縦型動画への変換を行うシステムです。SNS の流行りに合わせたシステム改修が今後も続くことが予想される一方で、生成 AI の登場や AWS のマネージドサービスの利用でコーディング量を大きく減らすことができることから、讀賣テレビ放送株式会社では外注ではなく社内メンバーでの内製を選択しました。このシステムは、ライブ配信中にイン点とアウト点を指定して必要な映像素材を切り出す「収録アプリ」と、横型の動画から縦型の動画を切り出したり、縦型フォーマットに合わせた背景画像を挿入したりすることが可能な「切り出しアプリ」から構成されています。切り出しアプリは、複数の動画クリップから1つの動画を作成することや同一素材を複数ユーザーで共有することなども可能です。 Web アプリとして構築したことにより場所を問わず作業が可能になったことと、サーバーレスアーキテクチャの採用によって作業への立ち合いなどの作業負荷や AWS の利用コストを低減できたことが本システムの大きな特徴です。映像素材の変換には AWS Elemental MediaConvert を、動画の合成処理には AWS Lambda を利用しており、MediaConvert 上の変換処理が終了すると Amazon EventBridge 経由でイベントが発火し、AWS Lambda を用いた後処理を自動で開始できるようにしています。 本システムは他社でも活用されており今後も機能追加を進める予定です。既に Amazon EC2 上で YOLO モデルを実行することで物体や顔のトラッキングデータが取得できる ことを確認していますが、これらを活用した縦型動画の切り抜きや特定のシーンのみを集めた動画の作成、字幕の自動付与などにも今後チャレンジする予定でいます。 資料のダウンロードは こちら LT枠: AWS で文字起こし検証してみた 関西テレビ放送株式会社 DX推進局DX戦略部 兼 総合技術局制作技術センター 渡邊 真也 氏 近年の AI の発展によって多くの文字起こしサービスが乱立していることから、各社の文字起こしサービスの精度を比較してみました。AWS では Amazon Transcribe という音声テキスト変換サービスがあり、 音声の合計時間に基づいて課金 されます。ファイルを Amazon S3 バケットにアップロード、もしくはストリーミング形式によってデータの入力が可能で、特定の言語を指定することも、言語を自動識別させることも可能です。 今回は社内の人間に関西弁で話をしてもらい、これを正しく文字起こしできるかを確認しました。1分程度の素材の場合、出力結果が出るまで20-30秒掛かりました。他の文字起こしツールと比べても Amazon Transcribe の出力結果の精度は良く、専門ツールと張り合うことが可能な精度であると感じています。ファイルを入力する場合、一般ユーザーが Amazon S3 にファイルをアップロードすることに障壁があると感じていて、ユーザーに使い勝手の良い Web アプリ等を作成して、その裏側で Amazon Transcribe を動かすような実装が必要になりそうだと考えています。 LT枠: Amazon Nova を使ってみて 株式会社ytvメディアデザイン ICT技術 藤本 駿 氏 Amazon Nova を含む複数の生成 AI が、静止画から動画を作成したり、画像の描写を行う能力をどの程度持つのかについて調べてみました。影が物体に追従するような違和感の無い動画を生成するモデルもあれば、途中から新たな物体が急に登場する動画を生成するモデルもあり、モデルによって得手不得手があるようでした。 次に食べ物が写っている静止画を入力して、レストランの口コミサイトにあるようなグルメリポートを Amazon Nova に作成してもらいました。ある程度の精度のグルメリポートを作成することは可能でしたが、他のモデルと同様、食べ物によってはそれを正しく識別できなかったり、文字数のカウントが正しく行われないなどの課題もありました。各モデルの進化に期待したいと考えています。 LT枠: ラジオ番組ショート動画生成システム『クリボー(CRIVO)』 株式会社毎日放送 放送運営センター 送出担当 萬谷 和樹 氏 社内ハッカソンをきっかけに生まれた『クリボー(CRIVO)』は、アップロードしたラジオ番組の音声ファイルと静止画ファイルからショート動画を生成することのできるシステムです。30分の素材をアップロードすると、8分ほどの処理時間の中で5本のショート動画を作成することができます。これまでこの作業は人の手で4-5時間掛かっていました。 AWS Lambda を経由して外部の文字起こしサービスを利用、 Amazon Bedrock を用いて生成 AI に面白い箇所を選んでもらい、出力された動画ファイルを社内のチャットツールを経由して社内メンバーに共有するというアーキテクチャとなっています。これまでアプリケーション開発の経験はほぼありませんでしたが、社内ハッカソンから AWS を触り始めて今は他の開発メンバーと本システムの追加機能を鋭意進めています。 資料のダウンロードは こちら LT枠: クラウドスイッチャーで配信してみた 名古屋テレビ放送株式会社 方便 剛 氏 ケーブルレスでの制作環境の構築やクラウド上のソフトウェアスイッチャーを用いたコンテンツ制作の知見を蓄積するために、 Amazon EC2 上でソフトウェアスイッチャーの vMix を動かし 、その映像を 動画配信サイト Locipo で配信するということにチャレンジしました。vMix の操作は Stream Deck と呼ばれる物理スイッチを使ってリモートから行っていますが操作性に問題はありませんでした。 クラウドであるか無いかに関わらず、局舎外に映像を伝送する場合には伝送や処理に掛かる遅延が気になるところですが、ともに AWS 上で構築している vMix と Locipo の配信基盤との間は、遅延を3秒以内に収めることができました。またこの配信の後に vMix 上の設定を見直したところより低遅延での配信も実現できたため、今後の配信でこれらの知見を活かせるのではないかと考えています。 資料のダウンロードは こちら AWS メディア業界向け勉強会 #8（2025 年 12 月 17 日開催） カンテレのクラウドセキュリティ第一歩 関西テレビ放送株式会社 DX推進局 DX戦略部 主事 石井 克典 氏 関西テレビ放送株式会社では AWS 上での会計システムの本格稼働を前に、AWS のアカウントチーム、株式会社 JSOL、Security-JAWS などに助言を求めながら、クラウド上で稼働するワークロードに対する、セキュリティ対策の標準化を行いました。一定レベルの安全性を全てのワークロードで担保すること、組織として対応にあたることでセキュリティ対策の継続性や作業負荷の軽減を実現することがこの取り組みの狙いです。 主な対策として AWS セキュリティ成熟度モデル に記載の優先度の高いアクションの実行 AWS Control Tower の有効化とその一機能である リージョン拒否コントロール の活用 ベストプラクティス に基づいたマルチアカウント環境の構築 在阪放送局セキュリティガイドライン に基づいた Amazon GuardDuty , AWS Security Hub CSPM , AWS IAM Access Analyzer 等の AWS のセキュリティ、アイデンティティ、ガバナンスサービスの有効化 などを行っています。当初はこれらのサービスを有効化することに対するコスト増を懸念していましたが、AWS 全体のコストに占めるこれらのサービスの利用料は想定範囲に収まっています。今後は立ち上げたばかりの AWS 活用・推進チームを人材育成などを通じてより強化するとともに、作業の自動化を推し進めることでより少ない負荷でのクラウドの運用や維持を実現を目指します。 資料のダウンロードは こちら 内製の著作権管理システムを AWS へ──移行を通して見えた「設計の真価」 株式会社毎日放送 コンテンツ戦略局 プラットフォームビジネス部 山下 遼河 氏 著作権管理システムをクラウドサービスから AWS へと移行する際に考慮した「調査性の向上」「同型性の実現」「複雑さの上限を設定」という3つの設計の考え方についてお話しをいただきました。調査性の向上、つまり内部状態の確認とデバッグをより容易に実現するために、これまで使用していたクラウドサービスでは実現が難しかったコンテナ内部へのアクセスを、 Amazon ECS およびその一機能である ECS exec を用いることで実現しました。また AWS Lambda と Amazon CloudWatch を組み合わせて、エラーの通知などをリアルタイムに Slack に送るなどの工夫も施しています。 同型性の実現、つまりローカル環境やステージング環境、本番環境を可能な限り同じ構造で動かすために行ったこととしては、非同期処理を従来のクラウドサービスベースのものから Rails で一般的な Sidekiq と Redis の構成へ変更したことや、それによってローカル環境でも本番時と同じ Sidekiq の処理フローを再現できるようになったことがあります。これによりローカルと本番の動作の差異が解消され、ローカル環境でのデバッグや検証作業の精度が大幅に向上しました。また、複雑さの上限を設定、つまり対応できる担当者が限られてしまうほどの複雑性をシステムに持たせたり、過剰にコストが掛かりすぎることを防ぐために、各コンポーネントが満たすべき可用性を個別に判断して、コンポーネントによってはあえてマネージドサービスを採用せずに Amazon EC2 上で機能構築するなどの判断も行っています。 人事異動等による開発メンバーの交代もありうる中で、低い負荷でシステムを育てそれを運用するためには、これら3つの設計原則は非常に重要です。またこれを実現するために、 AWS Cloud Development Kit (CDK) によるインフラストラクチャーの開発や CI/CD パイプラインの構築によるデプロイの自動化も行っています。 資料のダウンロードは こちら 内製ってたのしいよ 東海テレビ放送株式会社 総務局システム部 兼 デジタルビジネス局コンテンツ事業部 瀧 祐作 氏 東海テレビ放送株式会社の AWS の利用は古くは公式サイトの AWS 移行に始まり、視聴者投票システム、 プレゼント応募システム 、データ放送中間サーバ、 AI を用いた PR 文の作成 などのシステムについても、社内のメンバーで内製して AWS 上で稼働させています。内製する最も大きなメリットは、自分たちで決めた仕様に沿ってシステムをすぐに作ったり変更を加えたりできること。自由度の高さやオンプレ時と比べてコスト削減できる点も AWS を用いて内製する際の大きな魅力だと感じています。内製する中で新たな技術スタックを試すことは、自身のスキルアップにも貢献します。 内製の取り組みを進める中で最近開発したのは、電話や FAX 等を介して視聴者から寄せられるご意見を集約する「番審システム 」です。AI の手を借りた Vibe Coding へのチャレンジや AWS Cloud Development Kit (CDK) によるインフラストラクチャーの開発、CI/CD パイプラインを用いたデプロイもこのプロジェクトの中で実現しており、ベンダーに外注する場合と比べて数週間単位でスケジュールを短縮することができました。 DevSecOps の考え方にも注力しており、現在の CI/CD パイプラインをより強化していくことも今後予定しています。 資料のダウンロードは こちら LT枠: クラウドマスター実現に向けた機能拡充の研究 関西テレビ放送株式会社 総合技術局放送推進センター 主任 中道 尚宏 氏 関西テレビ放送株式会社では、 Inter BEE におけるクラウドを活用した各社のマスター展示 などを受けて、自社でもそれを検証する取り組みを進めています。2024年の夏頃から AWS メディアサービス を用いてマスター機能の実現に取り組み、すぐに環境を立ち上げたり落としたりできるクラウドのメリットを最大限享受すべく、最近では AWS CloudFormation を用いた Infrastructure as Code（IaC）の実現にもチャレンジしています。 現在は AWS メディアサービスを用いた映像ストリームの処理と、時刻制御などのロジック、またそれを外部から制御するための API 等を構築済みで、今後は Amazon CloudWatch のメトリクスをベースにしたモニタリングや、 Amazon SageMaker AI を用いて独自モデルを作成するなどして、異常が起こる前にそれに気づくための異常予知システムの実現を予定しています。 資料のダウンロードは こちら LT枠: 「AWS の呼吸 壱ノ型：Twelvelabs 動画分析!!」～全集中で”AI 柱”を目指す～ 九州朝日放送株式会社 谷本 亮輔 氏 九州朝日放送株式会社では、技術メンバーが各部署へ足を運び、現場のニーズをヒアリングして、内製によってこれらに応える取り組みを進めています。その活動により、280件ほどのニーズを収集し、現在は80件ほどが解決に至っています。こうした取り組みを継続する中で、未着手の課題を精査したところ、分析や切り出し等の放送素材に関する要望が複数部署から寄せられており、業務効率化への期待が非常に高いことが判明しました。そこで、動画理解が可能なマルチモーダル基盤モデル（FM）である TwelveLabs Pegasus を用いて、映像分析を行うアプリケーションを開発しました。 このアプリケーションに放送素材をアップロードすると、映像と音声を同時に分析し、この素材に含まれるコンテンツを時系列順に抽出・要約して表示します。これにより、番組や素材構成を一目で把握できます。また、解析結果として表示される各項目をクリックするだけで、該当箇所から即時に再生できる仕組みを取り入れました。あわせて、イン点とアウト点の指定（尺指定）、もしくは範囲を視覚的にドラッグすることで、任意部分だけを切り出してダウンロードすることができます。これにより、編成部署における「放送内容と視聴率データの照合による人気コーナーの特定や、番組改編に向けた検討材料の創出」、営業部署における「取引先が露出した箇所の抽出・切り出しおよび送付業務」といった、これまで複数名で多大な時間を要していた手作業が、低く見積もっても従来の10分の1程度の時間で完結できる見通しとなりました。また、1時間の素材をわずか5～10分ほどで解析完了できる処理スピードは、実運用への移行に向けた強力な足掛かりとなっています。 本アプリケーションは、フロントエンドに React を使用。 Amazon S3 に保存した放送素材に対して Amazon Bedrock 上の TwelveLabs Pegasus で分析を行い、その結果を Amazon DynamoDB に格納しています。 資料のダウンロードは こちら まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。内容について詳しく知りたい方は、記事上部より資料のダウンロード及び動画を視聴いただけますのでご確認ください。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

こんにちは! 私にとって 2026 年最初の記事になるこの記事は、家の前の雪に埋まった車道が掘り起こされるのを見ながら書いています。皆さんがこれを読んでいる場所が安全で暖かく、データの流れが止まっていませんように! 2026 年 1 月 26 日週は、GPU 集約型のワークロードを実行するお客様にとってうれしいニュースをお届けします。NVIDIA 最新の Blackwell アーキテクチャを搭載した最新のグラフィックスおよび AI 推論インスタンスがリリースされました。いくつかのサービス強化やリージョン拡大に加えて、今週のアップデートは AWS のお客様が利用できる機能も拡大し続けています。 2026 年 1 月 19 日週のリリース こちらは、私が興味深いと感じたプロジェクト、ブログ記事、ニュースです。 Amazon EC2 G7e インスタンスの一般提供開始 – NVIDIA RTX PRO 6000 Blackwell Server Edition GPU によって高速化された新しい G7e インスタンスは、G6e インスタンスよりも最大 2.3 倍優れた推論パフォーマンスを提供します。2 倍の GPU メモリを搭載し、最大 8 個の GPU をサポートすることで合計 768 GB の GPU メモリを提供するこれらのインスタンスでは、単一の GPU を用いて最大 70B パラメータの中規模モデルを FP8 の精度で実行できます。G7e インスタンスは、生成 AI 推論、空間コンピューティング、および科学コンピューティングワークロードに最適です。現在は、米国東部 (バージニア北部) と米国東部 (オハイオ) でご利用いただけます。 Amazon Corretto の 2026 年 1 月付け四半期更新 – AWS は、OpenJDK の Amazon Corretto Long-Term Supported (LTS) バージョンに対する四半期ごとのセキュリティ更新と重要更新をリリースしました。Corretto 25.0.2、21.0.10、17.0.18、11.0.30、および 8u482 が利用可能になったため、Java 開発者は最新のセキュリティパッチとパフォーマンス改善にアクセスできます。 Amazon ECR がリポジトリ間でのレイヤー共有のサポートを開始 – Amazon Elastic Container Registry では、blob マウントを使用することで共通のイメージレイヤーをリポジトリ間で共有できるようになりました。この機能により、既存のレイヤーを再利用することでイメージプッシュをより迅速に実行するとともに、共通のレイヤーを一度だけ保存し、リポジトリ間でそれらを参照することでストレージコストを削減できます。 Amazon CloudWatch Database Insights がさらに 4 つのリージョンに拡大 – CloudWatch Database Insights のオンデマンド分析が、アジアパシフィック (ニュージーランド)、アジアパシフィック (台北)、アジアパシフィック (タイ)、メキシコ (中部) でも利用可能になりました。この機能は、機械学習を使用することでパフォーマンスボトルネックの特定を助け、具体的な修正アドバイスを提供します。 Amazon Connect がステップバイステップガイドに条件付きロジックとリアルタイム更新を追加 – マネージャーは、ユーザーのやり取りに応じて適応する動的なガイド付きエクスペリエンスを構築するために Amazon Connect のステップバイステップガイドを使用できるようになりました。また、フィールドを表示または非表示にする、デフォルト値を変更する、または以前の入力に基づいて必須フィールドを調整するドロップダウンメニューを備えた条件付きユーザーインターフェイスも設定できます。この機能は Connect リソースからの自動データ更新もサポートしているため、エージェントは常に最新の情報を用いて作業できます。 今後の AWS イベント 今後のイベントをチェックしてサインアップしましょう。 Best of AWS re:Invent (1 月 28～29 日、バーチャル) – AWS re:Invent からの最もインパクトのある発表と、一番人気のセッションをお届けする無料のバーチャルイベントにご参加ください。オープニングセッションでは、AWS VP 兼 Chief Evangelist である Jeff Barr がハイライトをご紹介します。セッションは、アメリカ大陸: 1 月 28 日午前 9 時 (太平洋標準時)、アジア太平洋/日本: 1 月 29 日午前 9 時 (シンガポール時間)、欧州/中東/アフリカ: 1 月 29 日午前 9 時 (中央ヨーロッパ標準時) に開催されます。セッションに登録して、厳選された技術的学習、AWS リーダーからの戦略的インサイト、AWS エキスパートとのライブ Q&A にアクセスしましょう。 AWS Community Day Ahmedabad (2026 年 2 月 28 日) – 第 11 回目のこのコミュニティ主導 AWS カンファレンスでは、エキスパート主導のテクニカルセッション、実在のユースケース、ライブデモを行う技術展示ブース、およびネットワーキング機会のためにクラウドプロフェッショナル、開発者、アーキテクト、学生が一堂に会します。この無料イベントでは、朝食、昼食、限定ノベルティグッズが提供されます。 AWS Builder Center に参加して、AWS コミュニティのビルダーと学び、構築し、交流しましょう。お住まいの地域で今後開催される対面イベントとデベロッパー向けのバーチャルイベントをご覧ください。 2026 年 1 月 26 日週のニュースは以上です。2026 年 2 月 2 日週の Weekly Roundup もお楽しみに! – Micah 原文は こちら です。

本記事はAWSとSAPが共同で執筆しました。成功したパートナーシップとこのブログ記事への貢献について、SAP Joule For Consultantチームの Sachin Kaura 氏に感謝いたします。 はじめに：コンサルタントが直面する課題 SAPコンサルタントが複雑なクラウドトランスフォーメーションプロジェクトに取り組む機会が増える中、重要な実装ガイダンスやベストプラクティスへのアクセスが課題となっています。コンサルタントは、特定のお客様のシナリオに適した情報を見つけるために、膨大なドキュメント、認定資料、SAP Knowledge Base記事を検索することに貴重な稼働時間を費やすことがよくあります。主要な実装手順、構成の詳細、トラブルシューティングガイダンスは複数のソースに分散しているため、コンサルタントはお客様に価値を提供することに集中すべき時間を技術ドキュメントの検索に費やしています。これにより、プロジェクトの提供が遅延し、チームが重要な実装フェーズで期限を守るのに苦労するため、手戻りのリスクが増加します。 これらの課題に対処するため、SAPチームはAWSと提携して SAP Joule for Consultants（J4C） を開発しました。 Amazon Bedrock を介した Anthropic の Claudeモデル を使用することで、J4CはSAPの最も権威があり包括的な知識への自然言語アクセスを提供します。このイノベーションにより、コンサルタントは権威あるSAPコンテンツとの会話型AI対話を通じて、技術的な実装要件を迅速にナビゲートし理解できます。J4Cは、コンサルタントがビジネス要件を具体的な実装に変換するのを支援します。 SAP Joule for Consultantsとは？ SAP Joule for Consultants は、 SAP Joule アシスタントの会話型AI機能であり、コンサルタントがSAPの最も独占的で最新のナレッジベースを使用して、専門家のガイダンスによりSAPプロジェクトを加速するのを支援します。Jouleアシスタントのこのコンサルティング機能は、独占的なSAPコンテンツに基づいた迅速で信頼性の高い回答を提供し、設計上の意思決定を支援し、ベストプラクティスとの整合性を確保することで、コンサルタントの生産性を向上させるように設計されています。 Joule for ConsultantsがSAPコンサルタントとパートナーを支援する方法 SAP Joule for Consultantsを使用すると、コンサルタントは特定のビジネスシナリオのソリューションを迅速に評価し、実装のベストプラクティスにアクセスできます。この機能は、長いドキュメントを会話形式でアクセス可能なガイダンスに変換し、広範な検索を必要としないため、プロジェクト提供中に費やす時間を大幅に削減します。ジュニアコンサルタントとエキスパートの両方を含むコンサルタントは、お客様とのエンゲージメントに取り組む際の効率が向上し、専門知識がリアルタイムのコンテキストでよりアクセスしやすくなります。その結果、情報やドキュメントの検索に費やす時間が減り、お客様や個人的な対話により多くの時間を費やすことができます。 基盤の構築：ビジョンから最初の展開まで Claudeモデルを特徴とする Amazon BedrockとSAPのGenerative AI Hubの統合 が発表された後、AWSはSAPのJouleチームと協力ワークショップを開始し、SAPの膨大な認定資料、ナレッジベース記事、コミュニティコンテンツのリポジトリを生成AI強化の主要候補として特定しました。 プロジェクトは、品質と精度を確保するための包括的な評価データセットの作成から始まりました。チームは、 learning.sap.com/certifications の広範な認定カタログを通じて、SAPの既存の資料を活用しました。このアプローチでは、既に存在する構造化された質問と回答のペアを利用し、包括的な評価データセットを作成できました。重要なブレークスルーは、質問と回答のペアを使用して完全に自動化されたデータ駆動型評価パイプラインを開発したことでした。このアプローチにより、チームは複数の候補モデルとRetrieval-Augmented Generation（RAG）実装を迅速かつ体系的にベンチマークできました。 チームは、モデルのパフォーマンスを最適化するために一連のプロンプトエンジニアリング実験を行いました。例えば、「あなたは専門のSAPテスト受験者です」のような権威ある言葉を使用すると、「あなたはSAPテスト受験者として行動しています」のような控えめな表現よりも大幅に良い結果が得られることを発見しました。認定データセットに対する継続的なテストによって導かれたこれらの改良は、コンサルタント向けの対話のベストプラクティスを確立するのに役立ちました。さらに、チームは、評価データセットに意図的にひっかけ問題を使用するよりも、実際のQ&Aの方が効果的であることを発見しました。 アーキテクチャの詳細：バックボーンとしてのRetrieval Augmented Generation 「Joule For Consultant」プロジェクトは、Retrieval-Augmented Generation（RAG）パターンを活用して、SAP認定学習資料、SAP KBA、SAP Notesから直接コンサルタントのクエリに正確な回答を提供することに焦点を当てています。認定資料はマルチモーダルであり、テキスト、画像、チャートが含まれており、Anthropic Claudeモデルはこれらの理解に優れています。 RAGシステムには、SAPの広範な認定ナレッジリポジトリに合わせたデータ取り込みおよび処理パイプラインが含まれていました。SAP認定資料の構造化および非構造化ドキュメントが体系的に収集、クレンジングされ、検索可能な形式にチャンク（小さな単位）に分割されました。主要なステップには、テキスト、メタデータ（SAP製品バージョン、適用性、実装フェーズなど）の抽出、およびドキュメント間の相互参照の解決が含まれます。セマンティックチャンキングなどの前処理技術が適用され、SAP固有の技術的なニュアンスを保持しながら、コンテンツを文脈的に意味のある単位にセグメント化しました。これらのチャンクは、RAG実装のために高次元ベクトル埋め込みにエンコードされました。処理されたデータは、高速類似性検索用に最適化されたHANAベクトルエンジンにインデックス化され、検索中にコンサルタントのクエリを最も関連性の高いSAPコンテンツに効率的にマッピングできるようにしました。 クエリフェーズでは、RAGサービスは検索と生成を組み合わせて、正確なコンサルティングガイダンスを提供します。コンサルタントがクエリを送信すると、システムはまずベクトルデータベースを活用して、クエリの意図と意味的に整合した上位のSAPナレッジスニペットを取得します。優先順位付けステップでは、関連性スコア、コンテンツの新しさ、または適用性基準に基づいて結果を優先順位付けし、最新で実用的なインサイトを確保します。取得されたコンテキストは、SAPのGenerative AI Hubを介してAmazon BedrockのClaudeモデルに供給され、コンサルティングシナリオに合わせた簡潔な自然言語応答を合成します。重要なことに、応答は取得されたソースに厳密に基づいており、透明性とさらなる探索のために元のSAPドキュメントへの組み込み引用が含まれています。このハイブリッドアプローチは、速度と精度のバランスを取り、コンサルタントがリアルタイムで実装の課題を解決できるようにし、ハルシネーション（AIによる誤った情報生成）を最小限に抑え、従来のサポートチャネルへの依存を減らし、プロジェクトの提供を加速します。 お客様の価値とメリット SAP Business AIおよびSAP Joule for Consultantsのチーフアーキテクトである、Sachin Kaura氏によると： 「SAP Joule for Consultantsは、SAPの権威あるナレッジベース（ 2,500万を超えるドキュメントと12テラバイトのSAP専門知識データ にわたる）で構築されており、数秒で明確で引用された回答を提供します。 Amazon Bedrock上のAnthropic Claudeモデルを活用することで 、SAPのグローバルコンサルティングエコシステムに対してこの機能を拡張し、あらゆるレベルのコンサルタントをサポートし、チームが お客様向けにSAPプロジェクトを最大14%高速化 して提供できるよう支援しています。」 追加のお客様の声とインサイトについては、 SAP Joule for Consultantsページ をご覧ください。 SAP J4Cを通じてコンサルティング体験を向上させるSAPの取り組みは、SAPパートナーエコシステム全体に大きなビジネス価値を提供します。ビジネスへの影響は、個々のコンサルタントの生産性を超えて広がります。SAPのパートナーエコシステムでは、コンサルタントの効率の向上は、大規模な経済的利益につながります。SAP J4Cは、信頼できるSAPナレッジへの即座のアクセスを通じて、コンサルタントが1日あたり最大1.5時間を節約し、SAPプロジェクトのタイムラインを大幅に短縮します。 結論 SAP Joule for Consultantsは、エンタープライズコンサルティングの課題に生成AIを思慮深く適用することの変革的な影響を示しています。SAPのGenerative AI Hubを通じたAmazon Bedrock上のAnthropicのClaudeモデルの統合を活用することで、チームは、SAPの膨大なコンサルティングナレッジリポジトリに対する会話型AI機能を実装することで、ナレッジアクセシビリティの根本的な問題に対処しました。このソリューションは、複雑な実装プロジェクト中に権威あるSAPガイダンスへの効率的なアクセスという重要なニーズに対応しています。 SAP Joule for Consultantsを探索し、生成AIがコンサルティングプラクティスとプロジェクト提供能力をどのように変革できるかを直接確認し、Amazon BedrockとAnthropic Claudeのページをレビューして、これらのテクノロジーをより深く理解することをお勧めします。 本ブログはAmazon Bedrockによる翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

SAPを運用する企業は、SAP S/4HANAの実装、技術的負債の削減、新しいビジネス機能の提供といった課題に直面しています。お客様からは、SAP S/4HANAへの移行時にアップグレードが必要なカスタムSAP ABAPプログラムが数千個あるという声を良く伺います。これらのSAP ABAPプログラムはドキュメントが不足していることが多く、トランスフォーメーションプロジェクトと日常的なサポートの両方をさらに複雑にしています。さらに、SAP開発者は、SAP CAP（cloud application programming）やSAP RAP（Restful ABAP Programming model）のようなクリーンコアプログラミングモデルとともに、最新のSAP ABAPプログラミングモデルを採用するために高い学習障壁に直面しています。 私たちは、お客様がソフトウェア開発ライフサイクル（SDLC）全体を支援するために、ABAP Acceleratorを提供開始します。ABAP AcceleratorはMCPサーバーで、お客様がより速く、より高いコード精度でコードを作成、テスト、ドキュメント化、変換することを支援します。ABAP Acceleratorは、SAP ABAP Test Cockpitに接続してコードを検証し、含まれるカスタムコードを取得することで、開発者がハルシネーションを削減するのに役立ちます。 Kiro CLI 内で、お客様はABAP Acceleratorをインストールした後、大量のコード分析と変換を実行できます。 ABAP AcceleratorがSAP開発ライフサイクルを最適化する6つの方法をご紹介します： 1. SAP ECCからSAP S/4HANAへの自動コード変換 ABAP Acceleratorは、レガシーECC ABAPコードをS/4HANA互換コードに自動的に変換し、移行プロジェクトごとに数百または数千の開発時間を節約できる可能性があります。SAPのABAP Test Cockpitと直接統合することで、ABAP Acceleratorは変換がSAPの品質基準を満たしながら、ビジネスロジックを保持することを保証します。 要点：S/4HANAマイグレーション中の手動変換作業の大幅な削減。 2. SAP ABAP Test Cockpitとの統合 ABAP Acceleratorは、SAP環境に直接接続することで、システムを認識したコード生成を実行します。構文チェックを実行し、カスタムバリアントでABAP Test Cockpit（ATC）検証を実行し、オブジェクトのアクティベーションを自動的に処理します。このアプローチにより、生成されたコードがSAPの要件とお客様のガイドラインの両方に準拠し、生成AIツールに共通する「ハルシネーション」を削減します。ATCがコードの問題（構文、セキュリティ、パフォーマンス、命名規則など）を特定した場合、ABAP Acceleratorはコードを修正し、解決されるまで複数のサイクルを繰り返します。 要点：初回コード品質の向上、デバッグサイクルの削減、本番環境への迅速なデプロイ。 3. トランスフォーメーションのリスクを軽減するテスト駆動開発（TDD） ABAP Acceleratorは、トランスフォーメーションリスクを削減するためのテスト駆動アプローチを実装します。既存のプログラムを分析し、現在の機能をドキュメント化する単体テストを生成することから始まり、プログラムの動作のベースラインを確立します。このベースラインを検証した後、ABAP Acceleratorは変更を実装します。 新しい機能が追加されると、システムはテストスイートを拡張して既存の機能と新しい機能の両方をカバーし、完全なスイートを実行して100%のカバレッジを確保します。このアプローチは、構文的に正しいコードでも、ビジネス機能を壊す可能性のある論理エラーが含まれている可能性があるため、非常に重要です。これらのテストスイートは、オブジェクトのライフサイクル全体を通じてリグレッションテストのための永続的な資産となり、システムメンテナンス、SAP S/4HANAマイグレーション、技術アップグレード中の意図しない結果から保護します。 要点：プロジェクトリスクの削減と、永続的なテスト資産による長期的なコード保守性の向上。 4. 合理化されたクリーンコア開発 RESTful ABAP Programming Model（RAP）を採用するチームのために、ABAP Acceleratorは開発プロセス全体をガイドします。CDSビュー、動作定義、サービス定義、サービスバインディングを含むRAPアーティファクトを生成し、各実装ステップの背後にある決定を説明します。たとえば、シンプルなQ Developerプロンプトで、フロントエンド、バックエンドCDSビュー、およびすべての相互依存オブジェクトを含む完全なFioriアプリケーションを構築できます。 このアプローチにより、開発者はRAPアーキテクチャを学びながらビジネスロジックに集中できます。ABAP Acceleratorは技術的なセットアップとアクティベーションプロセスを処理し、最新のSAP開発パターンに移行するチームの開発タイムラインと学習曲線を加速します。 要点：学習曲線を削減しながら、クリーンコアと最新のSAP開発プラクティスの迅速な採用。 5. 常に最新のドキュメント ABAP Acceleratorは、作成または変更するすべてのオブジェクトのドキュメントを、組織固有のテンプレートとスタイルに従って生成します。外部ドキュメントシステムとは異なり、この知識はSAPオブジェクト内に直接埋め込まれ、別のシステムを検索する必要がなくなり、ドキュメントがライフサイクル全体を通じてコードとともに保持されることを保証します。 システムは、ナレッジマネジメント統合のためにドキュメントをローカルにエクスポートすることもできます。このアプローチにより、ドキュメント化されていないコードの課題が解消され、レガシーシステムの標準化されたドキュメントが提供され、既存の機能を理解、変更、拡張するために必要な時間が短縮されます。 要点：属人的知識への依存の削減、新しいチームメンバーのオンボーディングの迅速化、コードと同期しないドキュメントの排除。 6. SAPサポートチーム向けのAI支援エラー解決 ABAP Acceleratorは、SAPエラーを分析することでサポート活動を強化します。サポートチームは、エラーメッセージ、スクリーンショット、デバッグ情報、ジョブログ、またはショートダンプ（ST22）を入力でき、ABAP Acceleratorは根本原因を特定しながら解決ガイダンスを提供します。この機能により、サポートは反応的なトラブルシューティングから積極的な問題解決に変わります。システムのSAPアーキテクチャとエラーパターンの理解により、実行パスをトレースして修正を提案でき、通常はシニア開発者へのエスカレーションが必要な問題を解決することがよくあります。 要点：インシデント解決の迅速化、エスカレーションの削減、AI駆動の診断機能。 ABAP Acceleratorの使用開始 ABAP Acceleratorは無料でダウンロード可能なDockerイメージです。インストール後、標準のMCPサーバーと同じように接続できます。セットアッププロセスは簡単です： Installation: 詳細なインストール手順とセットアップガイダンスについては、 ABAP Accelerator リポジトリをご覧ください。 README ファイルの手順に従って、環境でMCPサーバーを構成して使用してください。 Integration: 標準のADT（ABAP Development Tools）を使用して、ABAP AcceleratorをSAPシステムに接続します。 Configuration: ATCバリアントで開発設定と品質チェックをセットアップします。 Start Developing: 完全なシステムコンテキストでAI駆動のSAP開発の活用を開始します。 エンタープライズSAP開発のための専用ソリューション ABAP Acceleratorは、SAP開発における根本的な変化を表しており、成功は書かれたコードの量ではなく、それが提供するビジネス価値によって測定されます。オブジェクトの作成、構文チェック、ATC検証、アクティベーション、単体テスト、トランスポートリクエスト管理、ドキュメント化を統合することで、断片化されたプロセスを開発サイクルを加速する合理化されたワークフローに変換します。 ABAP Acceleratorは、より速く、より信頼性が高く、SAPプラクティスに準拠した開発エクスペリエンスを作成します。SAP S/4HANAマイグレーションの管理、レガシーアプリケーションのモダナイゼーション、または新しいクラウドネイティブソリューションの構築のいずれの場合でも、ABAP Acceleratorはチームに対してAI駆動の加速を提供します。 本ブログはAmazon Bedrockによる翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本記事は 2026 年 1 月 22 日 に公開された「 Power up your analytics with Amazon SageMaker Unified Studio integration with Tableau, Power BI, and more 」を翻訳したものです。 by Narendra Gupta, Durga Mishra, Nishchai JM, and Ramesh H Singhon 22 JAN 2026in Advanced (300) , Amazon SageMaker Unified Studio , Technical How-to Permalink Comments Share 複数のデータソースにまたがるガバナンスされたデータに、セキュリティとガバナンスを維持しながら、使い慣れたビジネスインテリジェンス (BI) や分析ツールでアクセスして分析する際、組織は新たな課題に直面します。Tableau、Power BI、Excel などの使い慣れたツールを Amazon SageMaker のデータアセットに、データガバナンスとセキュリティ機能を損なうことなくシームレスに接続する必要があります。Amazon SageMaker は Amazon Athena JDBC ドライバーによる認証をサポートしており、データユーザーは Tableau、Power BI、Excel、SQL Workbench、DBeaver などの一般的な BI および分析ツールを使い、サブスクライブしたデータレイクアセットにクエリできます。データユーザーは使い慣れたツールで Amazon SageMaker の管理化にあるデータにアクセスして分析でき、生産性と柔軟性が向上します。 Amazon SageMaker Unified Studio では、データユーザーが単一のプロジェクト内で複数のソースからデータを検索してサブスクライブでき、データアクセスとガバナンスが効率化されます。Amazon SageMaker Unified Studio は Amazon Athena 、 Amazon Redshift 、 Amazon SageMaker AI などの Amazon 固有のオプションとネイティブに統合されており、ユーザーはプロジェクトのガバナンスされたデータを分析できます。これらに加え、今回の JDBC 接続のリリースにより、Amazon SageMaker Unified Studio はアナリストやサイエンティストを含むデータユーザーへのサポートを拡大し、SQL Workbench、Domino、 Amazon Athena などの Amazon ネイティブソリューションなど、好みのツールで作業しながら、Amazon SageMaker Unified Studio 内で安全でガバナンスされたアクセスを確保できます。 はじめに まず、使用するツール向けの最新の Athena JDBC ドライバー をダウンロードしてインストールします。インストール後、Amazon SageMaker Unified Studio ポータルから JDBC 接続文字列をコピーして JDBC 接続設定に貼り付け、ツールからの接続を確立します。企業の認証情報を使ったシングルサインオン (SSO) で認証するよう指示されます。接続後、Amazon SageMaker Unified Studio でガバナンスされたデータを、既に使い慣れた信頼できるツール内でクエリ、可視化、共有できます。 本記事では、Athena JDBC ドライバーで各種分析ツールを Amazon SageMaker Unified Studio に接続し、Amazon SageMaker Unified Studio プロジェクト内でサブスクライブしたデータにシームレスにアクセスする手順を説明します。 ソリューション概要 マーケティングチーム(Marketing Team)が店舗別および営業担当者別の売上パターンを理解するために売上データを分析したいというユースケースで、これらの機能を実証します。マーケティングチームは営業チーム(Sales Team)が所有する sales_performance_by_store と sales_performance_by_rep のデータにアクセスする必要があります。データプロデューサーとして機能する営業チームは、 必要なデータアセットを公開 して Amazon SageMaker Unified Studio に登録し、コンシューマーであるマーケティングチームがこれらのアセットを 検索してサブスクライブ できるようにします。 サブスクリプションが承認されると、データアセットは Amazon SageMaker Unified Studio のマーケティングチームのプロジェクト環境内で利用可能になります。マーケティングチームは好みのツールでデータ探索を実行できます。DBeaver を使ったアーキテクチャ例を次の図に示します。 前提条件 本記事の手順を実行するには、次の前提条件が必要です。 AWS アカウント – アクティブな AWS アカウントをお持ちでない場合は、 新しい AWS アカウントを作成してアクティブ化する方法 を参照してください。 Amazon SageMaker リソース – Amazon SageMaker の ドメイン と 2 つの Amazon SageMaker プロジェクト が必要です。（訳注：マーケティングチームと、営業チームがそれぞれ別のプロジェクトに所属するため） データアセットの公開 – 営業チームのデータプロデューサーとして、個々のデータアセットを Amazon SageMaker Unified Studio に取り込めます。本ユースケースでは、 データソースを作成 し、 AWS Glue Data Catalog から sales_performance_by_store と sales_performance_by_rep という 2 つのデータアセットの技術メタデータをインポートします。データアセットにビジネス説明を追加してカタログに公開してください。 注: ここでは Glue カタログ内のテーブルを使用していますが、SageMaker Lakehouse では他のソースからアセットを取り込むオプションもあります。 データアセットのサブスクライブ – マーケティングチームのデータアナリストとして、データアセットを検索してサブスクライブできます。営業チームのデータプロデューサーがサブスクリプションをレビューして承認します。正常に完了すると、データアセットが SageMaker プロジェクトに追加されます。 公開とサブスクライブの詳細な手順については、 Amazon SageMaker Unified Studio ユーザーガイド を参照してください。 次の図は、マーケティングプロジェクトにあるカタログのサブスクライブ済みアセットセクションを示しています。 次のセクションでは、Amazon SageMaker Unified Studio からサブスクライブ済みアセットを利用するための DBeaver の設定手順を説明します。 サブスクライブ済みデータアセットにアクセスするための DBeaver の設定 本セクションでは、 Marketing プロジェクトからサブスクライブ済みアセットにアクセスするための DBeaver の設定を行います。 DBeaver を設定する方法: JDBC で接続: Amazon SageMaker Unified Studio で、(1) Marketing プロジェクトを開き、(2) Project overview 画面で、(3) JDBC connection details タブを選択します。 JDBC 接続 URL をテキストエディタにコピーします。URL には、DBeaver でデータベース接続を設定するために必要な次のパラメータが含まれています – Domain ID、Environment ID、Region、IDC Issuer URL。 最新の Athena ドライバーをダウンロードしてインストールします。 DBeaver に Athena ドライバーがプリインストールされている場合、古い (v2) バージョンの可能性があります。Amazon SageMaker Unified Studio との互換性を確保するには、必要な認証機能を含む最新のドライバー (v3) が必要です。 最新の JDBC ドライバー—バージョン 3.x をダウンロードします。 最新のドライバーをインストールするには: DBeaver で Database から Driver Manager に移動します。 Athena ドライバーを選択して Edit を選択します。 Libraries タブを開きます。 Download/Update を選択して最新のドライバーバージョンを取得します。 プロンプトが表示されたら、適切なバージョンを選択してダウンロードを確認します。 DBeaver SQL クライアントで、新しいデータベース接続を作成し、Athena ドライバーを選択します。 Driver Properties タブに切り替え、Amazon SageMaker Unified Studio からコピーした JDBC 接続 URL に含まれる次のプロパティの値を入力します。これらのプロパティがまだ存在しない場合は、追加してそれぞれの値を指定できます。 CredentialsProvider : AWS へのリクエストを認証するための認証情報プロバイダー DataZoneDomainId : Amazon DataZone ドメインの ID DataZoneDomainRegion : ドメインがホストされている AWS リージョン DataZoneEnvironmentId : DefaultDataLake 環境の ID IdentityCenterIssuerUrl : トークン発行のために AWS Identity and Access Management (IAM) Identity Center が使用する発行者 URL OutputLocation : クエリ結果を保存するための Amazon S3 パス Region : 環境が作成されたリージョン Workgroup : 環境の Amazon Athena ワークグループ ListenPort : 任意の 4 桁のポート番号を選択します。これは IAM Identity Center レスポンスをリッスンするポート番号です Test Connection… を選択します。 IAM Identity Center サインインポータルにリダイレクトされます。Marketing ユーザーの認証情報でサインインします。シングルサインオン (SSO) で既にサインインしている場合、この手順はスキップできます。 サインイン後、 DataZoneAuthPlugin の承認を求められた場合は、 Allow access を選択して DBeaver から Amazon DataZone へのアクセスを承認します。 サインインが完了すると、次のメッセージが表示されます。ウィンドウを閉じて DBeaver に戻ります。 接続が確立されると、次の成功メッセージが表示されます。 これで、DBeaver 内でサブスクライブ済みアセットをすべて表示してクエリできます。 これらの手順は、JDBC 接続をサポートする他の分析ツールやクライアントにも適用できます。別のツールを使用している場合は、Amazon SageMaker Unified Studio データアセットへの適切な設定とアクセスを確保するために、これらの手順を適宜調整して利用してください。 他のアプリケーションとの統合 標準的なデータベース接続をサポートする他の BI および分析ツールでも同様の手順を使用できます。 Tableau Desktop への接続 Athena JDBC ドライバーを使用して Tableau を Amazon SageMaker Unified Studio に接続し、サブスクライブ済みデータを可視化します。 Tableau Desktop に接続する方法: 最新の Athena JDBC 3.x ドライバー を使用していることを確認します。 JDBC ドライバーファイルをコピーして、オペレーティングシステムに応じた適切なフォルダに配置します。 Mac OS の場合: ~/Library/Tableau/Drivers Windows の場合: C:\Program Files\Tableau\Drivers Tableau Desktop を開きます。 To a Server 接続メニューから Other Databases (JDBC) を選択して Amazon SageMaker Unified Studio に接続します。 SageMaker Unified Studio ポータルからコピーした JDBC 接続 URL を URL に貼り付けます。 Dialect 、 Username 、 Password などの他のフィールドは空白のままにして、 Sign in を選択します。 ポートが占有されているというエラーが表示された場合は、URL に “;ListenPort=8055” を追加してポートを変更します。任意のポート番号を使用できます。 IAM Identity Center で認証するようリダイレクトされます。SageMaker Unified Studio ポータルへのサインインに使用した Identity Center ユーザーの認証情報を入力します。 DataZoneAuthPlugin が Tableau から Amazon DataZone にアクセスすることを承認します。接続が成功メッセージとともに確立されると、プロジェクトのサブスクライブ済みデータを Tableau 内で直接表示してダッシュボードを構築できます。 Microsoft Power BI への接続 次に、Windows 上で Amazon SageMaker Unified Studio を Microsoft Power BI に接続する方法を説明します。Amazon Athena は Microsoft Power BI などの ODBC 互換ツールに接続するためのネイティブ ODBC ドライバーを提供していますが、現在 Amazon SageMaker Unified Studio 認証をサポートしていません。そのため、本記事では ODBC-JDBC ブリッジを使用して、SageMaker Unified Studio 認証をサポートする Athena JDBC ドライバーで Amazon SageMaker Unified Studio を Microsoft Power BI に接続します。 本記事では、ODBC-JDBC ブリッジとして ZappySys ドライバーを使用しています。別途ライセンス料が必要なサードパーティソリューションであり、AWS ソリューションには含まれていません。ODBC-JDBC ブリッジには他のソリューションを選択することもできます。Power BI に接続するには: ODBC Data Source Administrator を実行するためには、管理者権限が必要です。 Windows のスタートメニューから、 管理者として実行 を使用して ODBC Data Source Administrator (64 ビット版) を実行します。 ZappySys JDBC Bridge Driver で 新しいデータソース を作成します。接続の詳細を入力するよう求められます。 SageMaker Unified Studio ポータルからコピーした JDBC URL を、ドライバークラスと JDBC ドライバーファイルとともに Connection String に貼り付けます。最新の Athena JDBC 3.x ドライバー を使用していることを確認します。 Test Connection を選択します。接続が成功すると、新しいダイアログウィンドウがポップアップ表示されます。 IAM Identity Center で認証するようリダイレクトされます。SageMaker Unified Studio ポータルへのサインインに使用した Identity Center ユーザーの認証情報を入力します。 DataZoneAuthPlugin を承認します。 ZappySys JDBC Bridge Driver ウィンドウで Preview タブを選択し、サブスクライブ済みテーブルの 1 つを選択してデータにアクセスします。 データソースの設定後、Power BI を起動します。空白のレポートを作成するか、既存のレポートを使用して新しいビジュアルを統合します。 Get Data を選択し、作成したデータソースの名前を選択します。新しいブラウザウィンドウが開き、認証情報を認証します。DataZone Auth プラグインを承認するためにアクセスを許可します。承認が完了すると、サブスクライブ済みデータアセットを使って Microsoft Power BI でレポートを作成できます。 SQL Workbench への接続 SQL インターフェイスで Amazon SageMaker Unified Studio のプロジェクトを通じてサブスクライブしたデータレイクテーブルとビューをクエリしたいユーザー向けに、SQL Workbench を Amazon SageMaker Unified Studio に接続する方法を説明します。 SQL Workbench に接続するには: 最新の Athena JDBC 3.x ドライバー を使用していることを確認します。 SQL Workbench/J を開き、 Manage Drivers を選択します。 新しいドライバーを追加するオプションを選択します。SMUSAthenaJDBC などの名前を入力し、前の手順でダウンロードしたドライバーをインポートします。 新しい接続プロファイルを作成し、smus-profile などの名前を付けます。 Driver ドロップダウンで、設定したドライバーを選択します。 URL には、jdbc:athena://region=us-east-1; という文字列を入力します (この例では、バージニアリージョンを使用しています)。 Extended Properties を選択します。 Extended Properties で、SageMaker Unified Studio ポータルからコピーした次のパラメータを追加します。これらのパラメータは JDBC (URL) 接続文字列に含めることもできます。 OK を選択します。 Workgroup OutputLocation DataZoneDomainId IdentityCenterIssuerURL CredentialsProvider DatazoneEnvironmentId DataZoneDomainRegain また、任意のポート番号で “ListenPort” を追加します。 IAM Identity Center で認証するようリダイレクトされます。SageMaker Unified Studio ポータルへのサインインに使用した Identity Center ユーザーの認証情報を入力します。 DataZoneAuthPlugin を承認します。 接続が成功したら、SQL Workbench/J の Database Explorer で、SageMaker unified studio のマーケティングプロジェクトからデータベースを選択します。サブスクライブ済みテーブルを選択します。 Data タブを選択して、テーブル内のデータを表示します。 クリーンアップ テスト後に追加料金が発生しないようにするには、Amazon SageMaker Unified Studio ドメインを削除してください。手順については、 ドメインの削除 を参照してください。 まとめ Amazon SageMaker Unified Studio は機能を増やし続けており、サブスクライブ済みデータへのアクセス、分析、可視化においてより高い柔軟性を提供します。Athena JDBC ドライバーのサポートにより、幅広い一般的な BI および分析ツールを使用できるようになり、Amazon SageMaker Unified Studio を通じてアクセスするデータがこれまで以上に利用しやすくなりました。Tableau、Power BI、その他の使い慣れたツールのいずれを使用する場合でも、Amazon SageMaker Unified Studio との統合により、データは安全に保たれ、承認されたユーザーがアクセスできます。 本機能は、Amazon SageMaker Unified Studio が現在利用可能な すべての AWS 商用リージョン でサポートされています。技術 ドキュメント の確認から始めましょう。 著者について Narendra Gupta Narendra は、AWS の Specialist Solutions Architect で、AWS 分析サービスに重点を置いてお客様のクラウドジャーニーを支援しています。仕事以外では、新しいテクノロジーの学習、映画鑑賞、新しい場所への訪問を楽しんでいます。 Durga Mishra Durga は、AWS の Solutions Architect です。仕事以外では、家族と過ごす時間を楽しみ、アパラチアントレイルでのハイキングや自然の中で過ごすことを愛しています。 Ramesh Singh Ramesh は、ワシントン州シアトルの AWS で Senior Product Manager Technical (External Services) を務めており、現在は Amazon SageMaker チームに所属しています。最先端テクノロジーを使用してエンタープライズのお客様が重要な目標を達成できるよう支援する、高性能な ML/AI および分析製品の構築に情熱を注いでいます。 Nishchai JM Nishchai は、Amazon Web Services の Analytics Specialist Solutions Architect です。ビッグデータアプリケーションの構築を専門とし、お客様のクラウド上でのアプリケーションモダナイゼーションを支援しています。データは新しい石油であると考えており、データから洞察を引き出すことに時間の大半を費やしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の 下佐粉 昭 (Akira Shimosako) がレビューしました。

本ブログは 2024 年 12 月 10 日に公開された AWS Blog “ AWS-LC FIPS 3.0: First cryptographic library to include ML-KEM in FIPS 140-3 validation ” を翻訳したものです。 AWS-LC FIPS 3.0 が National Institute of Standards and Technology (NIST) の Cryptographic Module Validation Program (CMVP) の 審査中モジュール リストに追加されたことを発表いたします。AWS-LC のこの最新の検証では、ML-KEM (Module Lattice-Based Key Encapsulation Mechanism) のサポートが導入されています。ML-KEM は、FIPS で新たに標準化されたポスト量子暗号アルゴリズムです。これは、米国連邦政府の通信を含む、最も機密性の高いワークフローの長期的な機密性を強化するための重要なステップです。 この検証により、 AWS LibCrypto (AWS-LC) は、FIPS モジュール内でポスト量子アルゴリズムのサポートを提供する初のオープンソース暗号モジュールとなります。 FedRAMP 、 FISMA 、 HIPAA などの連邦コンプライアンスフレームワークに基づいて運用されている組織など、FIPS 検証済み暗号モジュールを必要とする組織は、AWS-LC 内でこれらのアルゴリズムを使用できるようになります。 今回の発表は、新しい FIPS 140-3 認証を継続的に取得するという AWS-LC の長期的なコミットメントの一環です。AWS-LC は 2023 年 10 月に AWS-LC-FIPS 1.0 で 最初の認証を取得 しました。その後のバージョンである AWS-LC-FIPS 2.0 は、2024 年 10 月に 認証を取得 しました。この記事では、ポスト量子暗号アルゴリズム ML-KEM の FIPS 検証、AWS-LC FIPS 2.0 および 3.0 における既存アルゴリズムのパフォーマンス改善、バージョン 3.0 で追加された新しいアルゴリズムのサポートについて説明します。また、新しいアルゴリズムを使用してハイブリッドポスト量子暗号スイートを実装する方法と、将来の脅威から保護するために今すぐ設定できる構成オプションについても説明します。 FIPS ポスト量子暗号 大規模な量子コンピュータは、現在公開鍵暗号で保護しているデータの長期的な機密性に対する脅威となります。今記録して後で復号する攻撃 (record-now, decrypt-later 攻撃) として知られる手法では、攻撃者は今日のインターネットトラフィックを記録し、鍵交換と暗号化された通信をキャプチャします。そして、十分に強力な量子コンピュータが利用可能になったときに、暗号の安全性を支える計算上の困難性を突破することで、過去に記録した通信の共有シークレットと暗号鍵を解読できます。 ML-KEM は、量子コンピュータの脅威から公開鍵暗号を守るために NIST が標準化を進めている新しい鍵カプセル化メカニズムの 1 つです。 RSA 、Diffie-Hellman (DH)、または楕円曲線 Diffie-Hellman (ECDH) 鍵交換と同様に、2 者間で共有シークレットを確立することで機能します。ただし、RSA や DH とは異なり、ML-KEM は量子コンピュータでも突破が困難と考えられている数学的問題に基づいて鍵交換を行います。 現時点では、このような大規模な量子コンピュータを実現する技術はまだ確立されていません。そのようなコンピュータの実現には、さらなる科学技術のブレークスルーが必要です。しかし、将来実現する可能性に備えて、ML-KEM などのポスト量子アルゴリズムを今日の鍵交換プロトコルに導入することで、record-now, decrypt-later 攻撃のリスクを軽減できます。AWS は、ECDH などの従来の鍵交換方式と ML-KEM を組み合わせたハイブリッド鍵交換アプローチを採用し、現在および将来の攻撃者に対するリスクを軽減することを推奨しています。この記事の後半では、将来の脅威から保護するために今すぐハイブリッドポスト量子暗号スイートを実装する方法を紹介します。 AWS-LC FIPS 3.0 では、ML-KEM アルゴリズムの 3 つのパラメータセット (ML-KEM-512、ML-KEM-768、ML-KEM-1024) をすべてサポートしています。3 つのパラメータセットは、NIST が指定する異なるレベルのセキュリティ強度を提供します ( FIPS 203 [9, Sect. 5.6] または ポスト量子セキュリティ評価基準 を参照)。ML-KEM-768 は汎用的なユースケースに推奨されます。ML-KEM-1024 は、より高いセキュリティレベルを必要とするアプリケーションや、国家安全保障システムの所有者およびオペレーター向けの Commercial National Security Algorithm Suite (CNSA) 2.0 などの明示的な指令への準拠が必要なアプリケーション向けに設計されています。 アルゴリズム NIST セキュリティカテゴリ 公開鍵 (B) 秘密鍵 (B) 暗号文 (B) ML-KEM-512 1 800 1632 768 ML-KEM-768 3 1184 2400 1088 ML-KEM-1024 5 1568 3168 1568 表 1. ML-KEM の 3 つのパラメータセットにおけるセキュリティ強度カテゴリ、公開鍵、秘密鍵、暗号文のサイズ (バイト単位) s2n-tls との統合 ML-KEM は、TLS 1.3 のハイブリッド鍵交換 (draft-ietf-tls-hybrid-design) を通じて、AWS のオープンソース TLS 実装である s2n-tls で利用可能になりました。また、TLS 1.3 のハイブリッド ECDHE-ML-KEM 鍵合意 (draft-kwiatkowski-tls-ecdhe-mlkem) のサポートと、Curve x25519 および ML-KEM-768 の新しい鍵共有識別子も追加しました。 FIPS 140 準拠モードでのハイブリッド鍵確立では、コンポーネントアルゴリズムの 1 つが NIST 承認メカニズムである必要があります ( NIST ポスト量子 FAQ で詳細を確認できます )。ML-KEM が NIST 承認アルゴリズムのリストに追加されたことで、Curve x25519 のような FIPS 標準化されていないアルゴリズムもハイブリッド暗号スイートに含めることができるようになりました。TLS 暗号スイートを ML-KEM-768 と x25519 を使用するように設定することで (draft-kwiatkowski-tls-ecdhe-mlkem)、FIPS 検証済み暗号モジュール内で初めて x25519 を使用できます。これにより、AWS-LC が提供する高度に最適化され機能検証された Curve x25519 実装を通じて、より効率的な鍵交換が可能になります。 新しいアルゴリズムと新しい実装 AWS-LC FIPS の継続的な検証に対する AWS のコミットメントにおいて重要な 2 つの要素は、承認された暗号サービスとして新しいアルゴリズムを含めることと、既存アルゴリズムについてパフォーマンスを改善し形式検証で正しさを証明した新しい実装を追加することです。 新しいアルゴリズム AWS は、開発者が FIPS 検証済みの暗号を採用できるよう、認定された暗号アルゴリズムの最新リビジョンと新しいプリミティブを継続的に検証することにコミットしています。最新の標準化リビジョンでアルゴリズムを検証することで、グローバル標準に準拠した高品質な実装を提供しています。 AWS-LC FIPS 3.0 では、SHA（Secure Hash Algorithm）標準の最新規格である SHA-3 を追加しました。SHA-3 ファミリーは、さまざまなアルゴリズムをサポートするために使用される暗号プリミティブです。AWS-LC FIPS 3.0 では、ECDSA と RSA の署名生成および検証を SHA-3 と統合し、ポスト量子アルゴリズム ML-KEM 内でも統合しました。AWS-LC では、ML-KEM が FIPS 検証済みの SHA-3 関数を呼び出し、SHA-3 と SHAKE ハッシュ手順の最適化された実装を提供します。つまり、AWS-LC の SHA-3 実装を継続的に改良・最適化することで、ML-KEM など SHA-3 を使用するアルゴリズム全体のパフォーマンスも向上していきます。 EdDSA は、曲線 Ed25519 を使用した楕円曲線に基づくデジタル署名アルゴリズムです。NIST の更新された Digital Signature Standard (DSS) である FIPS 186-5 に追加されました。この署名アルゴリズムは、AWS-LC 3.0 FIPS モジュールの一部として提供されるようになりました。鍵合意については、共有シークレットから鍵を導出するために使用される Single-step Key Derivation Function (SSKDF) ( SP 800-56Cr2 ) が、ダイジェストベースと HMAC ベースの両方の仕様で利用可能です。SSKDF は、例えば KMS で ECDH を使用 した際に生成される共有シークレットから鍵を導出するために使用できます。さらに、Key-based Key Derivation Function (KBKDF) である SP 800-108r1 を使用して、元の鍵からさらに鍵を導出できます。これは HMAC に基づくカウンターモードを使用して利用可能です。 パフォーマンス改善 AWS は、TLS プロトコルなどのトランスポートプロトコルで広く使用されている公開鍵暗号アルゴリズムのパフォーマンス向上に注力しました。例えば、 Graviton2 での RSA 署名 は、ビット長 2048 で 81%、3072 で 33%、4096 で 94% 高速化され、主要な演算が正しく動作することの形式検証も追加されました。第 3 世代 Intel Xeon 以降で利用可能な Intel の AVX512 Integer Fused Multiply Add (IFMA) 命令を使用して、 Intel の開発者がこれらの命令と幅広い AVX512 レジスタを使用する RSA 実装を AWS-LC にコントリビュート しました。これは既存の実装の 2 倍の速度です。 EdDSA 署名のスループットは平均 108% 向上し、検証は 37% 向上しました。この平均は、Graviton2、Graviton3、Intel Ice Lake (Intel Xeon Platinum 8375C CPU) の 3 つの環境で測定されています。 このパフォーマンス向上は 、 s2n-bignum ライブラリから各ターゲット向けのコア演算のアセンブリ実装を統合することで達成されています。さらに、コア演算は定数時間で実装されており、各演算が正しく動作することが形式検証で証明されています。 以下の図 1 では、AWS-LC FIPS 1.0 と比較したバージョン 2.0 および 3.0 でのパフォーマンス改善の割合を示しています。2.0 で達成された改善は 3.0 でも維持されており、グラフでは繰り返し表示していません。グラフには対称鍵の改善も含まれています。セッション確立後の通信を暗号化するために TLS で広く使用されている AES-256-GCM では、Intel Ice Lake と Graviton4 全体で 16 KB メッセージを暗号化する際に平均 115% の向上があります。ディスクストレージで使用される AES-256-XTS では、256 B の入力の暗号化が Intel Ice Lake で 360%、Graviton4 で 90% 高速化されています。 図 1: AWS-LC FIPS バージョン 2.0 および 3.0 でのパフォーマンス改善のグラフ 今すぐ ML-KEM を使用する方法 s2n-tls と AWS-LC の両方の TLS ライブラリを設定して、鍵交換に X25519MLKEM768 と SecP256r1MLKEM768 を有効にすることで、今すぐ ML-KEM によるハイブリッドポスト量子セキュリティを有効にできます。AWS は、各ライブラリの既存の TLS 設定 API を使用して、AWS-LC libssl と s2n-tls の両方でこれらのハイブリッドアルゴリズムのサポートを統合しました。TLS 接続をネゴシエートするには、以下のコマンドのいずれかを使用してください。 # AWS-LC クライアント CLI の例 ./aws-lc/build/tool/bssl s_client -curves X25519MLKEM768:SecP256r1MLKEM768:X25519 -connect <hostname> : <port> # S2N-tls クライアント CLI の例 ./s2n/build/bin/s2nc -c default_pq -i <hostname> <port> まとめ この記事では、オープンソース暗号ライブラリ AWS-LC を通じて提供している暗号技術の継続的な開発、最適化、検証について説明しました。 また、FIPS 検証済みポスト量子アルゴリズムの追加と、将来の脅威に備えて今すぐこれらのアルゴリズムを使用するための設定方法を紹介しました。 AWS-LC-FIPS 3.0 は、AWS-LC の新しいバージョンを継続的に FIPS 認証を取得していくという AWS のコミットメントの一環です。新しいアルゴリズムが標準化されるたびに認証対象に追加し、既存アルゴリズムのパフォーマンスと形式検証の水準も引き上げています。このコミットメントを通じて、 AWS Libcrypto for Rust (aws-lc-rs) や ACCP 2.0 ライブラリ への統合により、Rust、Java、Python 開発者のより広いコミュニティを引き続きサポートしています。また、 CPython への統合を促進 し、AWS-LC に対してビルドして Python 標準ライブラリのすべての暗号処理に使用できるようにしています。さらに、 rustls が FIPS サポートを提供できるようにしました 。 この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。 Jake Massimo Jake は AWS Cryptography チームの応用科学者です。国際会議、学術文献、標準化団体への参加を通じて Amazon とグローバルな暗号コミュニティをつなぎ、ポスト量子クラウドスケール暗号技術の採用を促進することを目標としています。最近は、ポスト量子移行をサポートするための AWS 暗号ライブラリの開発に注力しています。 Nevine Ebeid Nevine は AWS Cryptography のシニア応用科学者で、AWS の暗号ライブラリである AWS-LC のアルゴリズム開発、マシンレベルの最適化、FIPS 140-3 要件に注力しています。AWS 入社前は、自動車およびモバイルセキュリティアプリケーションにおけるさまざまな暗号ライブラリとプロトコルの研究開発に従事していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 3 月 5 日に公開された Amazon Science Blog “ Latency from post-quantum cryptography shrinks as data increases ” を翻訳したものです。 ポスト量子暗号によりデータ量が増加した TLS 1.3 が実際の接続に与える影響を評価する際、最初のバイト到達時間 (TTFB: 最初のデータが届くまでの時間) ではなく最終バイト到達時間 (TTLB: データ転送が完了するまでの時間) を使用すると、より期待できる結果が得られます。 量子コンピュータが現在広く使用されている暗号標準を破る可能性があるというリスクは、ポスト量子暗号アルゴリズムの標準化と TLS 1.3 などのトランスポート暗号化プロトコルへの導入に向けた数多くの取り組みを促しています。ポスト量子アルゴリズムの選択は当然ながら TLS 1.3 のパフォーマンスに影響します。これまでの研究では、2 者間でポスト量子暗号接続を確立するために必要な「ハンドシェイク時間」、つまり 最初のバイト到達時間 (TTFB) に焦点が当てられてきました。 これらの研究はハンドシェイク時間の増加を定量化する上で重要でしたが、実際の TLS 1.3 接続に対するポスト量子暗号の影響の全体像を示すものではありませんでした。実際の接続では、多くの場合かなりの量のデータが転送されます。2024 年の Workshop on Measurements, Attacks, and Defenses for the Web (MADweb) で、私たちは ML-KEM (ML 鍵カプセル化メカニズム) や ML-DSA (ML 電子署名アルゴリズム) などのデータ量の多いポスト量子暗号アルゴリズムが実際の TLS 1.3 接続に与える総合的な影響を評価する指標として 最終バイト到達時間 (TTLB) を提唱する 論文 を発表しました。この論文では、新しいアルゴリズムがかなりの量のデータを転送する接続に与える実際の影響は、TLS 1.3 ハンドシェイク自体に与える影響よりもはるかに小さいことを示しています。 ポスト量子暗号 TLS 1.3 は、トランスポート層セキュリティプロトコルの最新バージョンであり、クライアントとサーバー間で転送されるデータを暗号化および認証するセキュアチャネルのネゴシエーションと確立に使用されます。TLS 1.3 は、オンラインバンクやストリーミングメディアなど、数多くの Web アプリケーションで使用されています。 TLS 1.3 で使用されているような非対称暗号アルゴリズムのセキュリティは、離散対数問題や素因数分解の困難さに依存していますが、暗号解読能力を持つ量子コンピュータが実現すれば、これらを効率的に解くことが可能になります。米国国立標準技術研究所 (NIST) はポスト量子暗号アルゴリズムの標準化に取り組んでおり、鍵交換用に ML-KEM を選定しました。また、署名 (暗号認証) 用に ML-DSA も選定しています。 これらのアルゴリズムが使用する公開鍵、暗号文、署名はキロバイト単位の大きさです。従来のアルゴリズムでは 50〜400 バイト程度だったため、TLS ハンドシェイクで交換されるデータ量が大幅に増加することになります。従来の TLS 1.3 鍵交換および認証とポスト量子鍵交換および認証を使用した場合のハンドシェイク時間を比較した研究が数多く行われてきました。 これらの比較は、各新アルゴリズムが 最初のバイト到達時間 (TTFB) 、つまりハンドシェイクプロトコルの完了に導入するオーバーヘッドを定量化するのに有用でした。しかし、ハンドシェイク時間とともにアプリケーションがデータ処理を開始するまでの総遅延を構成する、セキュア接続上のデータ転送時間は無視されていました。接続開始からデータ転送終了までの総時間が 最終バイト到達時間 (TTLB) です。TTLB の遅延がどの程度許容されるかは、アプリケーションによって大きく異なります。 実験 私たちはさまざまなネットワーク条件をシミュレートする実験を設計し、クライアントが小さなリクエストを送信しサーバーが数百キロバイト (KB) のデータで応答する TLS 1.3 接続において、従来のアルゴリズムとポスト量子アルゴリズムの TTLB を測定しました。Ubuntu 22.04 仮想マシンインスタンスで Linux 名前空間を使用しました。名前空間は仮想イーサネットインターフェースを使用して相互接続されました。名前空間間の「ネットワーク」をエミュレートするために、Linux カーネルの netem ユーティリティを使用しました。これにより、クライアントとサーバー間にネットワーク遅延の変動、帯域幅の変動、パケット損失を発生させることができます。 クライアントとサーバーの Linux 名前空間および netem でエミュレートされたネットワーク条件を使用した実験セットアップ。 実験では、以下のパラメータを変更することで、安定・不安定、高速・低速といったさまざまなネットワーク条件下でポスト量子アルゴリズムが TTLB に与える影響を比較しました。 TLS 鍵交換メカニズム (従来の ECDH または ECDH+ML-KEM ポスト量子ハイブリッド) 従来の RSA または ML-DSA 証明書に対応する TLS 証明書チェーンサイズ TCP 初期輻輳ウィンドウ (initcwnd) クライアントとサーバー間のネットワーク遅延、またはラウンドトリップ時間 (RTT) クライアントとサーバー間の帯域幅 パケットあたりの損失率 サーバーからクライアントに転送されるデータ量 結果 実験結果は論文で詳細に分析されています。基本的に、ポスト量子の公開鍵、暗号文、署名による TLS 1.3 ハンドシェイクでの数 KB の追加データは、数百 KB 以上を転送する接続では気にならないことを示しています。10〜20 KB 未満のデータを転送する接続は、新しいデータ量の多いハンドシェイクの影響をより受ける可能性があります。 図 1: 従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TLS 1.3 ハンドシェイク時間の増加率。帯域幅 = 1Mbps、損失率 = 0%、1%、3%、10%、RTT = 35ms および 200ms、TCP initcwnd=20。 Y 軸が「ハンドシェイク時間の増加率」、X 軸がパーセンタイル (50、75、90) の棒グラフ。各パーセンタイルには 2 本の棒があり、青が従来のハンドシェイクプロトコル、オレンジがポスト量子ハンドシェイクを表す。3 つのケースすべてで、オレンジの棒は青の棒の約 2 倍の高さ。 図 1 は、1Mbps 帯域幅、0%、1%、3%、10% の損失率、35 ミリ秒および 200 ミリ秒の RTT で収集された集計データセットの 50、75、90 パーセンタイルにおける TLS 1.3 ハンドシェイク時間の増加率を示しています。ML-DSA サイズ (16KB) の証明書チェーンは、8KB のチェーンのほぼ 2 倍の時間がかかることがわかります。つまり、ML-DSA 認証データの量を少なく抑えることができれば、低帯域幅接続でのポスト量子ハンドシェイクの速度が大幅に向上します。 図 2: 損失率 0% における従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率。帯域幅 = 1Gbps、RTT = 35ms、TCP initcwnd = 20。 図 2 は、損失率 0%、帯域幅 1Gbps の条件下で、すべてのパーセンタイルと異なるデータサイズにおける、従来のアルゴリズムに対するポスト量子ハンドシェイクの所要時間の増加率を示しています。サーバーからのデータが 0 KiB (キビバイト、1,024 バイト) の場合 (ハンドシェイクのみに相当)、速度低下は約 3% と小さく、サーバーからのデータ転送が増加するにつれて約 1% までさらに小さくなることがわかります。90 パーセンタイルでは速度低下がわずかに小さくなっています。 図 3: 損失率 0% における従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率。帯域幅 = 1Mbps、RTT = 200ms、TCP initcwnd = 20。 図 3 は、帯域幅 1Mbps、RTT 200ms、損失率 0% の条件下で、サーバーから 0〜200KiB のデータを転送する従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率を各パーセンタイルで示しています。3 つのパーセンタイルの増加率はほぼ同じです。サーバーからのデータが 0KiB の場合は高い値 (約 33%) から始まりますが、サーバーからのデータサイズが増加するにつれて約 6% まで低下します。これは、ハンドシェイクのデータサイズが接続全体で分散されるためです。 図 4: 従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率。損失率 = 10%、帯域幅 = 1Mbps、RTT = 200ms、TCP initcwnd = 20。 図 4 は、帯域幅 1Mbps、RTT 200ms、損失率 10% の条件下で、サーバーから 0〜200 KiB のデータを転送する従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率を各パーセンタイルで示しています。損失率 10% では、TTLB の増加率はすべてのパーセンタイルで 20〜30% の範囲に収まります。RTT 35ms での同じ実験でも同様の結果が得られました。20〜30% の増加は高いように見えるかもしれませんが、シナリオ全体のネットワーク不安定性により、実験を再実行すると増加率が小さくなったり大きくなったりすることがあります。また、サーバーからのデータ 200KiB、RTT 200ms、損失率 10% の条件下での従来のアルゴリズムの TTLB は 4,644ms、7,093ms、10,178ms であったのに対し、ポスト量子接続の同等値は 6,010ms、8,883ms、12,378ms でした。損失率 0% では 2,364ms、2,364ms、2,364ms でした。つまり、ポスト量子接続の TTLB は従来の接続に比べて 20〜30% 増加しましたが、従来の接続はすでにネットワーク損失により (97〜331%) 劣化しています。すでに大幅に劣化した接続時間に対して、追加の 20〜30% はそれほど大きな違いにはならないでしょう。 図 5: 「不安定なネットワーク」条件下、損失率 0% における従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率。帯域幅 = 1Gbps、RTT = 35ms、TCP initcwnd = 20。 図 5 は、損失率 0%、サーバーから 0〜200KiB のデータを転送する条件下での、従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率を示しています。非常に不安定な RTT をモデル化するために、平均 35ms、ジッター 35/4ms のパレート正規分布を使用しました。ポスト量子接続の TTLB 増加率は、サーバーデータ 0KiB で高い値から始まり、4〜5% まで低下します。以前の実験と同様に、損失率が高いほど増加率の変動は大きくなりましたが、全体として、「不安定なネットワーク条件」下でも転送データ量が増加するにつれて TTLB は許容可能なレベルまで低下することが結果から示されています。 図 6: ポスト量子 TLS 1.3 接続の TTLB 累積分布関数。サーバーから 200KiB、RTT = 35ms、TCP initcwnd = 20。 不安定なネットワーク条件下での変動を確認するために、サーバーから 200KiB を転送するポスト量子 TLS 1.3 接続の TTLB 累積分布関数 (CDF) を使用しました (図 6) 。あらゆる種類の不安定な条件 (1Gbps で損失率 5%、1Mbps で損失率 10%、パレート正規分布のネットワーク遅延) において、TTLB は実験測定サンプルの非常に早い段階で増加しており、総接続時間が非常に不安定であることを示しています。不安定なネットワーク条件下での TLS 1.3 ハンドシェイク時間でも同じ観察結果が得られました。 結論 この研究では、データ量の多いポスト量子アルゴリズムが TLS 1.3 接続に与える実際の影響は、ハンドシェイク自体に与える影響よりも小さいことを実証しました。損失率が低く、低帯域幅または高帯域幅の接続では、かなりの量のデータを転送する場合、ポスト量子ハンドシェイクの影響はほとんどありません。また、損失率が高い不安定な条件や遅延の変動が大きい条件下では、ポスト量子ハンドシェイクの影響は変動する可能性がありますが、一定の範囲内に収まり、転送データの総量が増加するにつれて低下することも示しました。さらに、不安定な接続ではそもそも接続完了までに長い時間がかかるため、ポスト量子ハンドシェイクによるわずかな遅延増加があっても、以前より使いにくくなることはありません。ただし、これはハンドシェイクデータ量の削減が不要という意味ではありません。アプリケーションデータの送信量がハンドシェイクメッセージのサイズに対して少ない場合は、ハンドシェイクデータの削減が特に重要になります。 詳細については、 論文 をご覧ください。 著者について Panos Kampanakis Panos Kampanakis は Amazon Web Services のプリンシパルセキュリティエンジニアです。サイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理の経験があります。サイバーセキュリティに関する論文を共同執筆し、セキュリティ情報共有、暗号、公開鍵基盤のための共通の相互運用可能なプロトコルと言語を提供するため、さまざまなセキュリティ標準化団体に参加しています。現在は、エンジニアや業界標準パートナーと協力して、暗号学的に安全なツール、プロトコル、標準を提供しています。 Will Childs-Klein Will Childs-Klein は Amazon Web Services Cryptography のシニアソフトウェアエンジニアです。暗号ライブラリの開発、ソフトウェアパフォーマンスの最適化、ポスト量子暗号の導入に注力しています。以前は AWS で Storage Gateway、Elastic File System、DataSync などのデータストレージおよび転送サービスに携わっていました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2022 年 7 月 5 日に公開された AWS Blog “ How to tune TLS for hybrid post-quantum cryptography with Kyber ” を翻訳したものです。 2024 年 1 月 30 日: このブログ記事の API は、AWS CRT Client の新しいバージョンで変更されました。 詳細についてはこちらのページを参照してください 。 2023 年 1 月 25 日: AWS KMS、ACM、Secrets Manager の TLS エンドポイントは、NIST のラウンド 3 で選定された KEM である Kyber のみをサポートするように更新されました。 s2n-tls と s2n-quic も Kyber のみをサポートするように更新されました。標準化の進行に伴い、BIKE やその他の KEM が追加される可能性があります。 2022 年 8 月 3 日: この記事は Secrets Manager の情報を含むように更新されました。 AWS は、 AWS Key Management Service (AWS KMS) 、 AWS Secrets Manager 、 AWS Certificate Manager (ACM) への接続に Kyber を使用したハイブリッドポスト量子 TLS を提供しています。このブログ記事では、ハイブリッドポスト量子 Kyber 実装のパフォーマンス特性を紹介し、Maven プロジェクトでの設定方法を説明し、Kyber ポスト量子暗号 (PQC) に向けた接続設定の準備について解説します。 学術機関、暗号コミュニティ、 米国国立標準技術研究所 (NIST) のパートナーによる 5 年間の集中的な研究と暗号解析を経て、NIST はポスト量子鍵カプセル化メカニズム (KEM) の標準化に Kyber を選定しました。これは次世代の公開鍵暗号の幕開けを意味します。やがて、RSA や楕円曲線暗号 (ECC) など現在使用されている従来の鍵確立アルゴリズムは、量子耐性のある代替手段に置き換えられることになります。AWS Cryptography チームは、NIST 選定プロセスの各ラウンドを通じて候補 KEM の研究と分析を行ってきました。AWS は ラウンド 2 から Kyber のサポートを開始し、現在もそのサポートを継続しています。 RSA や ECC を解読できる暗号解読能力を持つ量子コンピュータはまだ存在しません。しかし、AWS は現在 Kyber を使用したハイブリッドポスト量子 TLS を提供しています。これにより、お客様は PQC のパフォーマンスの違いがワークロードにどのような影響を与えるかを確認できます。また、PQC を使用することで、 AWS KMS 、 Secrets Manager 、 ACM への接続における既に高いセキュリティ基準がさらに向上するため、長期的な機密性を必要とするお客様にとって特に有効な機能となっています。 (訳注：本ブログ執筆時点では Kyber は標準化前でしたが、2024 年 8 月に NIST により ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) として正式に標準化されました。AWS KMS、ACM、Secrets Manager は現在、標準化された ML-KEM をサポートしています。詳細は「 ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager 」を参照してください。) Kyber を使用したハイブリッドポスト量子 TLS のパフォーマンス ハイブリッドポスト量子 TLS は、従来の暗号のみと比較してレイテンシーと帯域幅のオーバーヘッドが発生します。このオーバーヘッドを定量化するために、 s2n-tls がハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立と ECDHE 単独のネゴシエーションにかかる時間を測定しました。テストは、米国東部 (バージニア北部) AWS リージョンの Amazon Elastic Compute Cloud (Amazon EC2) c6i.4xlarge インスタンス上で Linux perf サブシステムを使用して実施し、一般的なインターネットレイテンシーを含めるために米国西部 (オレゴン) リージョンで稼働するテストサーバーに 2,000 回の TLS 接続を開始しました。 図 1 は、従来の ECDHE とハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立を使用した TLS ハンドシェイクのレイテンシーを示しています。列は、クライアントとサーバーが消費した CPU 時間と、ネットワーク経由でのデータ送信に費やした時間を比較できるように分けて表示しています。 図 1: 従来の TLS ハンドシェイクとハイブリッドポスト量子 TLS ハンドシェイクのレイテンシー比較 図 2 は、従来の ECDHE とハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立の両方について、クライアント側で測定した TLS ハンドシェイク中の送受信バイト数を示しています。 図 2: 従来の TLS ハンドシェイクとハイブリッドポスト量子 TLS ハンドシェイクの帯域幅比較 このデータから、ハイブリッドポスト量子鍵確立を使用した場合のオーバーヘッドは、クライアント側で 0.25 ms、サーバー側で 0.23 ms、ネットワーク上で 2,356 バイトが追加されることがわかります。リージョン内テストではネットワークレイテンシーはより低くなります。レイテンシーは、ネットワーク状況、CPU パフォーマンス、サーバー負荷、その他の変数によっても異なる場合があります。 結果は、Kyber のパフォーマンスが優れていることを示しています。追加のレイテンシーは、 以前のブログ記事 で分析した NIST PQC 候補の中でトップクラスです。実際、これらの暗号のパフォーマンスは最新のテストで向上しています。これは、x86-64 アセンブリ最適化バージョンの暗号が利用可能になったためです。 Maven プロジェクトでハイブリッドポスト量子 TLS を設定する このセクションでは、Kyber を使用したアセンブリ最適化済みのハイブリッドポスト量子 TLS を設定するための Maven 設定とコード例を紹介します。 Maven プロジェクトでハイブリッドポスト量子 TLS を設定するには AWS SDK for Java 2.x 用 AWS Common Runtime HTTP クライアント のプレビューリリースを取得します。Maven の依存関係設定では、以下のコードサンプルに示すようにバージョン 2.17.69-PREVIEW 以降を指定する必要があります。 <dependency> <groupId>software.amazon.awssdk</groupId> aws-crt-client <version>[2.17.69-PREVIEW,]</version> </dependency> コードの初期化時に目的の暗号スイートを設定します。以下のコードサンプルは、最新のハイブリッドポスト量子暗号スイートを使用するように AWS KMS クライアントを設定する方法を示しています。 // Check platform support if(!TLS_CIPHER_PREF_PQ_TLSv1_0_2021_05.isSupported()){ throw new RuntimeException("Hybrid post-quantum cipher suites are not supported."); } // Configure HTTP client SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder() .tlsCipherPreference(TLS_CIPHER_PREF_PQ_TLSv1_0_2021_05) .build(); // Create the AWS KMS async client KmsAsyncClient kmsAsync = KmsAsyncClient.builder() .httpClient(awsCrtHttpClient) .build(); これで、AWS KMS クライアントで行われるすべての呼び出しがハイブリッドポスト量子 TLS を使用するようになります。上記の例と同様に、 AcmAsyncClient または AWSSecretsManagerAsyncClient を使用することで、ACM や Secrets Manager でも最新のハイブリッドポスト量子暗号スイートを使用できます。 ハイブリッドポスト量子 TLS の接続設定をチューニングする ハイブリッドポスト量子 TLS は初回ハンドシェイク時にレイテンシーと帯域幅のオーバーヘッドが発生しますが、そのコストは TLS セッションの期間全体で分散でき、接続設定を微調整することでさらに削減できます。このセクションでは、ハイブリッド PQC が TLS 接続に与える影響を軽減する 3 つの方法として、接続プーリング、接続タイムアウト、TLS セッション再開について説明します。 接続プーリング 接続プールは、サーバーへのアクティブな接続数を管理します。接続を閉じて再度開くことなく再利用できるため、接続確立のコストを時間の経過とともに分散できます。接続セットアップ時間の一部は TLS ハンドシェイクであるため、接続プールを使用することでハンドシェイクレイテンシーの増加による影響を軽減できます。 これを説明するために、テストサーバーに対して毎秒約 200 トランザクションを生成するテストアプリケーションを作成しました。HTTP クライアントの最大同時接続数設定を変更し、テストリクエストのレイテンシーを測定しました。AWS CRT HTTP クライアントでは、これは maxConcurrency 設定です。接続プールにアイドル状態の接続がない場合、リクエストレイテンシーには新しい接続の確立時間が含まれます。Wireshark を使用してネットワークトラフィックをキャプチャし、アプリケーションの実行期間中に発生した TLS ハンドシェイクの数を観察しました。図 3 は、 maxConcurrency 設定を増加させた場合のリクエストレイテンシーと TLS ハンドシェイク数を示しています。 図 3: 同時接続プールサイズの増加に伴うリクエストレイテンシーの中央値と TLS ハンドシェイク数 最も大きなレイテンシー改善は、 maxConcurrency 値が 1 より大きい場合に発生しました。それ以上では、レイテンシーの改善効果は頭打ちになりました。 maxConcurrency 値が 10 以下のすべてのケースで、接続内で追加の TLS ハンドシェイクが発生しましたが、レイテンシーの中央値にはあまり影響しませんでした。これらの変曲点はアプリケーションのリクエスト量によって異なります。重要なポイントは、接続プーリングにより接続を再利用でき、TLS ネゴシエーション時間の増加コストを多くのリクエストに分散できるということです。 maxConcurrency オプションの使用方法の詳細については、 AWS SDK for Java API リファレンス を参照してください。 接続タイムアウト 接続タイムアウトは接続プーリングと連携して機能します。接続プールを使用していても、アイドル状態の接続がプールによって閉じられるまでの時間には制限があります。この時間制限を調整することで、接続確立のオーバーヘッドを削減できます。 この設定を視覚化する良い方法は、バースト的なトラフィックパターンを想像することです。接続プールの同時接続数をチューニングしても、バースト期間がアイドル時間制限より長いため、接続が閉じ続けてしまいます。最大アイドル時間を増やすことで、バースト的な動作にもかかわらず、これらの接続を再利用できます。 接続タイムアウトの影響をシミュレートするために、10 個のスレッドを起動し、それぞれが 1 分間にわたって 5 秒ごとの定期スケジュールで同時にアクティブになるテストアプリケーションを作成しました。各スレッドが独自の接続を持てるように maxConcurrency を 10 に設定しました。AWS CRT HTTP クライアントの connectionMaxIdleTime を最初のテストでは 1 秒に、2 番目のテストでは 10 秒に設定しました。 最大アイドル時間が 1 秒の場合、各バースト間の時間中に 10 個すべてのスレッドの接続が閉じられました。その結果、テスト期間中に合計 100 個の接続が形成され、リクエストレイテンシーの中央値は 20.3 ms になりました。最大アイドル時間を 10 秒に変更すると、最初の 10 個の接続が後続の各バーストで再利用され、リクエストレイテンシーの中央値は 5.9 ms に減少しました。 アプリケーションに適した connectionMaxIdleTime を設定することで、TLS ネゴシエーション時間を含む接続確立のオーバーヘッドを削減し、アプリケーションのライフサイクル全体で時間を節約できます。 connectionMaxIdleTime オプションの使用方法の詳細については、 AWS SDK for Java API リファレンス を参照してください。 TLS セッション再開 TLS セッション再開により、クライアントとサーバーは新しい共有シークレットを確立するために通常実行される鍵合意をバイパスできます。代わりに、以前にネゴシエートされた共有シークレット、または以前のシークレットから派生した共有シークレットを使用して通信を迅速に再開します (実装の詳細は使用している TLS のバージョンによって異なります)。この機能はクライアントとサーバーの両方がサポートしている必要がありますが、利用可能な場合、TLS セッション再開により、ハイブリッドポスト量子 TLS に関連するハンドシェイク時間と帯域幅の増加を複数の接続のライフサイクル全体で分散できます。 まとめ この記事で説明したように、Kyber を使用したハイブリッドポスト量子 TLS は AWS KMS、Secrets Manager、ACM で利用可能です。この新しい暗号スイートによりセキュリティ基準が向上し、ワークロードをポスト量子暗号に備えることができます。ハイブリッド鍵合意は従来の ECDHE と比較して追加のオーバーヘッドがありますが、接続プーリング、接続タイムアウト、TLS セッション再開などの接続設定をチューニングすることで、これらの増加を軽減できます。 AWS KMS 、 Secrets Manager 、 ACM で今すぐハイブリッド鍵合意の使用を開始しましょう。 Brian Jarvis Brian は AWS Cryptography のシニアソフトウェアエンジニアです。ポスト量子暗号と暗号ハードウェアに関心を持っています。以前は AWS Security で、社内全体で使用される内部サービスの開発に携わっていました。Brian は Vanderbilt University で学士号を、George Mason University でコンピュータエンジニアリングの修士号を取得しています。「いつか」博士号を取得する予定です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2022 年 7 月 26 日に公開された Amazon Science Blog “ Preparing today for a post-quantum cryptographic future ” を翻訳したものです。 Amazon はポスト量子暗号の標準策定を支援し、お客様が活用できる有望な技術を提供しています。 ポスト量子暗号は、量子コンピュータでも破られない公開鍵暗号の新しい標準を開発することを目指しています。 米国国立標準技術研究所 (NIST) は先日、ポスト量子暗号の標準化プロセスの 第 3 ラウンドを完了 しました (※訳注)。量子コンピューティングはまだ黎明期にありますが、基礎物理学のより深い理解や困難な計算問題のより高速な解決など、社会に大きな恩恵をもたらす可能性を秘めています。多くの強力な新技術と同様に意図しない結果を招く可能性もあります。将来十分に大規模な量子コンピュータが構築された場合、現在データを保護するために使用されている公開鍵暗号アルゴリズムが破られる可能性があるとの見方もあります。 （訳注：その後 2024 年 8 月に、本ブログで言及されている Crystals Kyber は ML-KEM (FIPS 203) として、SPHINCS+ は SLH-DSA (FIPS 205) として正式に標準化されました） NIST、Amazon、そして広範な科学コミュニティは、ポスト量子時代にも耐えられる新しい公開鍵アルゴリズムの開発に取り組んでいます。歴史的に見ると、広く普及している高信頼性暗号アルゴリズムの置き換えには約 20 年を要してきました。Amazon では長期的な視点を重視しており、世界の動向を見据えて、可用性とセキュリティに対する大規模な長期投資を継続しています。 例えば、数年前に私たちは多大なコストと労力をかけて独自のチップを設計するという決断をしました。これにより、AWS のお客様にはセキュリティとパフォーマンスの大幅な向上がもたらされ、Alexa ユーザーはより素早く応答を得られるようになりました。ポスト量子暗号は、お客様の将来のために投資している分野のもう一つの例です。 Amazon は、ハッシュ関数、ワンタイム署名 (OTS)、Few-time 署名 (FTS) を使用する暗号署名スキームである SPHINCS+ の提案に貢献しました。図は「 The SPHINCS+ signature framework 」より引用 第 3 ラウンドの結果、NIST は鍵確立アルゴリズムの最終候補 (Crystals Kyber) と、Amazon が貢献した SPHINCS+ を含むデジタル署名アルゴリズムの 3 つの最終候補を選定したことを発表しました。これにより、これらの技術の標準化への道が開かれました。 NIST はまた、第 4 ラウンドで鍵確立のための追加アルゴリズムを評価することを示しました。これには Amazon チームメンバーが貢献した SIKE と BIKE が含まれます。Amazon は、 ETSI QSC 技術委員会、 IETF 、 Open Quantum Safe イニシアチブ、 NIST NCCoE PQ Migration などのプロジェクトや標準化活動にも業界の仲間とともに参加しています。これらの取り組みは、ポスト量子暗号の幅広い普及に向けた重要なステップです。 AWS におけるポスト量子暗号 新しい暗号技術の標準化が進む中、Amazon は AWS 上でポスト量子アルゴリズムと従来のアルゴリズムを併用できる機能を提供し、パフォーマンスの最適化を進めています。AWS はすでにポスト量子ハイブリッドキー交換に関する ドラフト標準 に貢献し、その仕様をオープンソースの s2n-tls に実装しました。s2n-tls は AWS 全体で Transport Layer Security (TLS) プロトコルの実装に使用されています。 また、 AWS Key Management Service (KMS) と AWS Certificate Manager (ACM) 、および AWS Secrets Manager の TLS エンドポイントにポスト量子対応の s2n-tls を導入しました。これにより、AWS SDK でハイブリッドポスト量子 TLS を有効にしてこれらのサービスに接続するお客様に、ポスト量子暗号のメリットを提供しています。全体として、2024 年までに複数の AWS サービスでお客様にポスト量子技術を提供するという目標に向けて取り組んでいます。これにより、お客様はポスト量子時代に備えて実験を行うことができます。 お客様のデータのセキュリティは Amazon の最優先事項です。将来起こりうる変化を予測し、潜在的に破壊的な技術に対してお客様が備えられるよう取り組んでいます。量子コンピューティングは大きなブレークスルーをもたらす可能性を秘めています。お客様がその技術革新を活用しながらもデータを長期にわたって安全に保てるよう、AWS は準備を進めています。 Amazon の研究と標準化活動の詳細については、以下のリンクをご覧ください。 ETSI CYBER; Quantum-safe Hybrid Key Exchanges Hybrid key exchange in TLS 1.3 Use of Post-Quantum KEM in the Cryptographic Message Syntax (CMS) Algorithms and Identifiers for Post-Quantum Algorithms in the Internet X.509 Public Key Infrastructure Post-quantum Hybrid Key Exchange in SSH Suppressing CA Certificates in TLS 1.3 On constant-time QC-MDPC decoding with negligible failure rate QC-MDPC decoders with several shades of gray Fast polynomial inversion for post quantum QC-MDPC cryptography On the Applicability of the Fujisaki-Okamoto Transformation to the BIKE KEM Prototyping post-quantum and hybrid key exchange and authentication in TLS and SSH Security of hybrid key encapsulation Faster post-quantum TLS handshakes without intermediate CA certificates PQ-HPKE: Post-Quantum Hybrid Public Key Encryption 著者について Matthew Campagna Matthew Campagna は Amazon Web Services のシニアプリンシパルセキュリティエンジニアです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2026年も1月後半に入り、新年の抱負を実行に移す時期になりましたね。「1月は行く、2月は逃げる、3月は去る」という言葉がありますが、気づけばもう月末です。みなさまの年始に立てた目標への取り組みはいかがでしょうか？ 年明けから4週間続けることができたなら、それはもう習慣化への第一歩です。私は体幹トレーニングのプランクを年初から継続中です。このままいけば 12 月頃に開催予定の re:Invent 2026 のキーノートは、最初から最後までプランクをしながら視聴できるようになっている予定です。継続は力なり！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年1月19日週の主要なアップデート 1/19(月) この日のサービスアップデートはありませんでした。 1/20(火) Amazon EVS が VCF と VMware ESX のソフトウェアバージョン選択をサポート Amazon EVS で VMware Cloud Foundation (VCF) と ESX ソフトウェアのバージョンを選択できるようになりました。これまでは決められたバージョンでしか環境構築できませんでしたが、今回のアップデートで複数のサポート済みバージョン組み合わせから選択可能です。オンプレミスの VMware 環境から AWS への移行時に、既存システムとの互換性を保ちながらスムーズに移行できるメリットがあります。詳細はこちらの サービス詳細ページ と ドキュメントをご参照ください。 Amazon RDS ブルー/グリーンデプロイがダウンタイムを 5 秒未満に短縮 Amazon RDS ブルー/グリーンデプロイ で、データベースのスイッチオーバー時間が大幅に短縮されました。これまで長いダウンタイムが発生していた本番環境でのデータベース更新作業が、わずか 5 秒以下で完了できるようになります。ブルー/グリーンデプロイ は、本番環境 (ブルー) を安全に保ちながら、別環境 (グリーン) でテストを行い、問題がなければ瞬時に切り替える仕組みです。メジャーバージョンアップグレードや定期メンテナンス時に、サービス停止時間を最小限に抑えられるため、24 時間稼働が求められるアプリケーションに特に有効です。詳細は こちらのドキュメントをご参照ください。 Amazon QuickSight が SPICE データセットの拡張サイズ、高速取り込み、豊富なデータ型サポートを開始 Amazon QuickSight の SPICE エンジンが大幅に強化されました。データセット容量が従来の 1TB から 2TB に倍増し、より大規模なデータ分析が可能になります。また取り込み速度も向上したため、データの更新時間が短縮され、リアルタイムな分析により近づけます。さらに文字列データの制限が 2K から 64K 文字に拡張され、長いテキストデータも扱えるようになりました。これにより AI 分析など複雑なワークロードにも対応でき、データ活用の幅が大きく広がります。詳細は こちらのドキュメントをご参照ください。 SageMaker Unified Studio がクロスリージョンおよび IAM ロールベースのサブスクリプションのサポートを追加 Amazon SageMaker Unified Studio で、クロスリージョンサブスクリプションと IAM ロールベースサブスクリプションがサポートされました。従来は同一リージョン内でのデータアクセスに限られていましたが、今回のアップデートにより異なるリージョンの AWS Glue テーブルや Amazon Redshift テーブルにもアクセスできるようになりました。また IAM ロールを使用することで、プロジェクトを介さずに直接データにアクセス可能になり、組織全体でのデータ活用がより柔軟になります。 詳細はこちらのドキュメントをご参照ください。 1/21(水) Amazon RDS for SQL Server が差分およびトランザクションログ復元サポートを強化 Amazon RDS for SQL Server で差分・トランザクションログ復元のサポートが強化されました。Multi-AZ や read replica を設定したインスタンスにおいて、以前は Single-AZ モードに変更してから復元し、再度 Multi-AZ や read replica を設定し直す必要がありましたが、この手順が不要となり復元時間を大幅に短縮できます。高可用性を維持したまま効率的なデータ復旧が可能になるため、ビジネス継続性の向上に役立ちます。詳細は こちらのドキュメントをご参照ください。 AWS がアクセス拒否エラーメッセージに追加のポリシー詳細を導入 AWS IAM でアクセス拒否エラーが発生した際に、どのポリシーが原因かを特定しやすくなりました。これまでエラーメッセージにはポリシーの種類のみ表示されていましたが、今回のアップデートで具体的なポリシー ARN が含まれるようになります。同じ種類のポリシーが複数ある環境では、トラブルシューティング時間を大幅に短縮できます。詳細は こちらの ドキュメントをご参照ください。 AWS Clean Rooms が SQL でのジョインおよびパーティションヒントのサポートを追加 AWS Clean Rooms で SQL クエリに join と partition hints 機能が追加されました。これまで大きなテーブル結合時の処理が非効率だった問題が解決され、broadcast join hint でクエリパフォーマンスが向上し、コストも削減できます。また partition hints により並列処理が改善されます。例えば、スポーツ視聴世帯数の分析で lookup テーブルに hints を適用することで、処理速度とコスト効率が大幅に改善されます。詳細は こちらのドキュメントをご参照ください。 1/22(木) Microsoft Office、Visio、Project 2024 アプリが Amazon WorkSpaces で利用可能に Amazon WorkSpaces Personal と Core で Microsoft Office LTSC Professional Plus 2024 や Visio 2024、Project 2024 といった最新の Microsoft 製品群が利用可能になりました。これまで古いバージョンに制限されていた環境でも、最新の生産性ツールを使った業務が可能です。既存の WorkSpaces バンドルを変更することなく、管理されたアプリケーションカタログから必要なアプリケーションを選択して追加できるため、運用負荷を抑えつつ標準化されたセキュアなデスクトップ環境を構築できます。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Browser がカスタムブラウザ拡張機能をサポート Amazon Bedrock AgentCore Browser で Chrome 拡張機能が利用できるようになりました。これまで標準的なブラウザ自動化では対応が困難だった複雑なワークフローを、カスタム拡張機能を使って自動化できます。拡張機能を S3 にアップロードすることで、ブラウザセッション中に自動インストールされる仕組みです。カスタム認証フローや自動テスト、広告ブロックによるパフォーマンス最適化など、企業での実用的な活用が期待できます。東京リージョンを含む 9 つのリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS Config が 13 の新しいマネージドルールを追加 AWS Config で新たに 13 個の管理ルールが追加されました。AWS Config は AWS リソースの設定変更を監視・記録するサービスで、今回のアップデートにより Amazon Cognito や EBS スナップショット、CloudFormation スタックなどのセキュリティチェックが自動化できます。これまで手動で確認していたセキュリティ設定の検証作業を大幅に削減でき、Conformance Packs を使えば組織全体に一括展開も可能です。詳細は こちらのドキュメントをご参照ください。 1/23(金) Amazon Connect がステップバイステップガイドに条件付きロジックとリアルタイム更新を追加 Amazon Connect の Step-by-Step Guides に条件付きロジックとリアルタイム更新機能が追加されました。これにより、マネージャーはユーザーの入力に応じてドロップダウンメニューの表示切り替えや必須フィールドの調整など、より柔軟なガイド体験を作成できるようになります。また、Connect リソースからの自動データ更新により、エージェントは常に最新情報で作業できます。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for Oracle が Oracle マルチテナント構成でのレプリカをサポート開始 Amazon RDS for Oracle で Oracle multi-tenant configuration でのレプリカサポートが開始されました。従来はこの構成でレプリカを作成できませんでしたが、これにより複数のプラガブルデータベースを統合管理しながら読み取り負荷を分散できるようになりました。クロスリージョンレプリカによる災害復旧や、レプリカのプライマリ昇格も可能です。コスト削減と運用効率化を同時に実現できる点が魅力です。詳細は こちらのドキュメントをご参照ください。 EC2 Auto Scaling がグループ削除保護の新しいメカニズムを導入 EC2 Auto Scaling で削除保護機能が強化されました。新しいポリシー条件キー autoscaling:ForceDelete により、IAM ポリシーでインスタンスが稼働中の Auto Scaling グループの強制削除を制限できます。さらにグループレベルでの削除保護設定も可能になり、重要なワークロードを誤削除から守れます。従来は削除操作の制御が難しかったですが、これにより本番環境での安全性が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Route 53 Domains が .ai およびその他のトップレベルドメインのサポートを追加 Amazon Route 53 Domains で .ai や .shop など 10 個の新しいドメインが登録できるようになりました。AI 企業なら .ai ドメイン、オンラインショップなら .shop ドメインなど、業界や用途に特化したドメインを選択できます。従来の .com や .org に加えて、よりブランドに適したドメインを AWS 上で一元管理でき、DNS 設定や自動更新も統合されているため運用が簡単になります。詳細は こちらをご参照ください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 本年も皆様に役立つ状況をタイムリーにお届けできればと思っていますので、よろしくお願いします！ 2 月 17 日に「 第6回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～ 」を開催します。様々な業界のモデル開発・利用の取り組みを発表予定です。ぜひご参加いただければと思います。 それでは、1 月 19 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース お客様事例/技術記事 AWS生成AI国内事例ブログ「株式会社デジナーレが Strands Agents と AgentCore で実現した脆弱性情報収集の完全自動化」を公開 株式会社デジナーレ様が Amazon Bedrock、Strands Agents、Amazon Bedrock AgentCore Runtime を活用して、脆弱性情報の収集から分析、レポート作成までを完全自動化したシステムを構築した事例を紹介しています。調査・執筆・校正の 3 段階で構成されるエージェントワークフローにより、従来数時間かかっていた調査作業がゼロ時間になったという結果が報告されています。 AWS生成AI国内事例ブログ「Amazon Bedrock AgentCore を使った業務支援 AI Agent 開発」を公開 株式会社 Works Human Intelligence 様と AWS GenAIIC が共同で取り組んだ AI Agent 開発事例を紹介しています。通勤手当申請の承認を支援するエージェントと、ブラウザ操作エージェントの 2 つを Amazon Bedrock AgentCore Runtime で構築し、プロンプトキャッシュやモデル変更により処理コストを最大 97% 削減することに成功しました。 ブログ記事「【開催報告 & 資料公開】Security for App Builders @ Loft #1 〜AI Coding 時代のセキュリティ実践〜」を公開 2025 年 11 月に開催された「Security for App Builders @ Loft #1」イベントの開催報告です。Coding Agent が生成したコードの安全性確保をテーマに、脅威モデリング、セキュリティのシフトレフト、マネージドサービスによるアプリケーションセキュリティの実装について解説しています。各セッションの資料も公開されています。   ブログ記事「Amazon Bedrock の次世代推論エンジン Mantle におけるゼロオペレーターアクセス」を公開 Amazon Bedrock の次世代推論エンジン Mantle のセキュリティ設計について解説しています。AWS Nitro System のアプローチに従い、ゼロオペレーターアクセス（ZOA）を実現し、AWS オペレーターが顧客データにアクセスする技術的手段を設計段階から排除しています。 Nitro Trusted Platform Module (NitroTPM)  から暗号署名されたアテステーション・メジャーメントによる高い保証によって信頼性が裏付けられています。 ブログ記事「『行政の進化と革新のための生成AIの調達・利活用に係るガイドライン』対応 – 調達チェックシート要件へのAWSサンプル回答」を公開 デジタル庁が公開した政府機関向け生成 AI ガイドラインの調達チェックシートに対する AWS のサンプル回答を提供しています。Amazon Bedrock を活用したオープンソースアプリケーション「 GenU 」を用いた対応例を示しており、政府機関の調達担当者やパートナー企業の提案書作成を支援します。 ブログ記事「NVIDIA RTX PRO 6000 Blackwell Server Edition GPU で高速化された Amazon EC2 G7e インスタンスのご紹介」を公開 Amazon EC2 G7e インスタンスが一般提供開始されました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、G6e インスタンスと比較して最大 2.3 倍の推論パフォーマンスを実現します。最大 768 GB の GPU メモリ、最大 1,600 Gbps のネットワーク帯域幅をサポートし、生成 AI 推論やグラフィックワークロードに最適です。 ブログ記事「LangGraph と Amazon DynamoDB で耐久性のある AI エージェントを構築する」を公開 LangGraph と Amazon DynamoDB を使用して、耐久性のある状態管理を備えた本番環境対応の AI エージェントを構築する方法を紹介しています。新しい DynamoDBSaver コネクタにより、チェックポイントを永続化し、障害からの回復、長時間実行ワークフローの維持、ヒューマン・イン・ザ・ループレビューなどが可能になります。 Kiro関連記事 ブログ記事「すべてのタスクを一括実行：リリースを見送り続けていた機能をついに公開」を公開 Kiro に待望の「すべてのタスクを実行」機能が追加されました。当初は意図的に実装しなかったこの機能ですが、プロパティベーステスト（PBT）、開発サーバー、LSP 診断、サブエージェントなどの検証基盤を構築したことで、安全にバッチ実行できるようになりました。各タスクの出力が自動検証されるため、信頼性を保ちながら開発を加速できます。 ブログ記事「IDE 診断機能による Kiro の進化」を公開 Kiro が IDE の診断情報（型エラー、リンティング結果など）にリアルタイムでアクセスできるようになりました。従来のコーディングエージェントは IDE が検出したエラーを認識できませんでしたが、この統合により、コマンド実行が29% 削減され、コード品質が向上しました。TypeScript から Terraform まで多様な言語・設定ファイルに対応しています。 ブログ記事「Kiro CLI 新機能まとめ : v1.21.0 から v1.23.0」を公開 Kiro CLI の v1.21.0 から v1.23.0 までのアップデートをまとめて紹介しています。Web 検索機能、LSP 統合によるコードインテリジェンス、Knowledge Management 機能、サブエージェント、Plan エージェント、Grep/Glob ツール、マルチセッションサポート、MCP Registry サポートなど、開発体験を大きく向上させる機能が多数追加されています。 ブログ記事「Kiro CLI 1.24.0：スキル、カスタム Diff ツール、改善されたコードインテリジェンス、会話の圧縮」を公開 Kiro CLI 1.24.0 の新機能を紹介しています。Skills による段階的なコンテキスト読み込み、カスタム Diff ツール対応、18 言語に対応した組み込みコードインテリジェンス、AST パターンツール、会話圧縮の詳細コントロール、web_fetch の URL 権限管理、リモート認証サポートなど、開発ワークフローを強化する機能が満載です。 サービスアップデート AWS Security Agent が GitHub Enterprise Cloud をサポート開始 AWS Security Agent が GitHub Enterprise Cloud に対応し、プライベートリポジトリでも AI によるセキュリティ分析が可能になりました。これまで GitHub Enterprise の組織では利用できなかった自動セキュリティレビュー、ペネトレーションテスト統合、自動修復機能が使えます。プルリクエスト時に脆弱性を自動検出し、修正コードも自動提案してくれるため、開発チームのセキュリティ対応が大幅に効率化されます。米国東部(バージニア北部)リージョンで提供中です。詳細は こちらの製品ページ をご参照ください。 Amazon Bedrock AgentCore Browser がカスタムブラウザ拡張機能をサポート Amazon Bedrock AgentCore Browser で Chrome 拡張機能が利用できるようになりました。これまで標準的なブラウザ自動化では対応が困難だった複雑なワークフローを、カスタム拡張機能を使って自動化できます。拡張機能を S3 にアップロードすることで、ブラウザセッション中に自動インストールされる仕組みです。カスタム認証フローや自動テスト、広告ブロックによるパフォーマンス最適化など、企業での実用的な活用が期待できます。東京リージョンを含む 9 つのリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 SageMaker Unified Studio がクロスリージョンおよび IAM ロールベースのサブスクリプションのサポートを追加 Amazon SageMaker Unified Studio で、クロスリージョンサブスクリプションと IAM ロールベースサブスクリプションがサポートされました。従来は同一リージョン内でのデータアクセスに限られていましたが、今回のアップデートにより異なるリージョンの AWS Glue テーブルや Amazon Redshift テーブルにもアクセスできるようになりました。また IAM ロールを使用することで、プロジェクトを介さずに直接データにアクセス可能になり、組織全体でのデータ活用がより柔軟になります。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod がライフサイクルスクリプトデバッグ機能を強化 Amazon SageMaker HyperPod でライフサイクルスクリプトのデバッグ機能が強化され、AI/ML クラスター作成時のエラー原因特定が従来より簡単になりました。詳細なエラーメッセージと CloudWatch ログの場所表示、コンソールからの直接ログアクセス、実行進捗追跡機能により、開発チームの問題解決時間を大幅短縮できます。詳細は こちらのドキュメント をご参照ください。 Amazon EC2 G7e インスタンスが一般提供開始 Amazon EC2 G7e インスタンスが一般提供開始されました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、従来の G6e と比較して推論性能が最大 2.3 倍向上しています。大規模言語モデル (LLM) やマルチモーダル生成 AI モデルの展開、空間コンピューティングワークロードに最適です。最大 8 GPU と GPU あたり 96 GB のメモリを提供し、グラフィックスと AI 処理の両方を必要とするワークロードで最高性能を発揮します。米国東部(バージニア北部)と米国東部(オハイオ)で利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本ブログは 2025 年 12 月 8 日に公開された AWS Blog “ New report: Cloud “fundamental” for European national security and defense ” を翻訳したものです。 クラウドコンピューティングは、欧州全体で国家安全保障・防衛能力を支える重要な基盤として台頭しています。 英国王立防衛安全保障研究所 (RUSI) が発表した 新しいレポート (AWS の支援を受けて独立した調査として実施) では、4 つの欧州諸国がハイパースケールクラウドインフラストラクチャを活用し、複雑化する脅威の状況の中で防衛態勢を強化し、国益を守っている方法を明らかにしています。NATO とその欧州加盟国が技術的優位性を維持・強化できる最新のデジタル基盤を求めている今、これは重要なレポートといえます。 クラウド採用の戦略的必要性 RUSI のレポートは、クラウド技術が欧州の国家安全保障にとって基本となる 3 つの目標、すなわちレジリエンスの達成、レガシーシステムの刷新、人工知能 (AI) などの先進技術の活用を支援することを論じています。この変化は単なるデジタルモダナイゼーションにとどまりません。「NATO と欧州の同盟国にとって、クラウド採用は単なるデジタルモダナイゼーションの問題ではなく、戦略的即応性の問題でもある。相互運用可能でスケーラブルかつ安全なデジタル能力を展開できるかどうかが、新たな脅威を抑止し対応する同盟の能力を左右する」とレポートは主張しています。そして「クラウドコンピューティングは欧州の国家安全保障・防衛にとって基盤となる能力になった」と結論付けています。 各国でのクラウド活用事例 RUSI のレポートは、さまざまなクラウドサービスプロバイダーを活用している英国、ウクライナ、エストニア、フィンランドのケーススタディに基づき、ネットワーク接続性、法規制上の課題、市場集中、地政学的リスクなどの課題に対処しながら、クラウド採用の戦略的・運用的影響を評価しています。 ウクライナ ロシアの侵攻が始まると、 ウクライナは AWS の支援を受けて 、重要な行政データベースとデジタルサービスをクラウドインフラストラクチャに迅速に移行しました。これにより、絶え間ないサイバー攻撃や物理的攻撃にもかかわらず、重要な政府サービスの継続性が確保されました。 RUSI のレポートには、クラウド採用とその影響を説明するために、さまざまなクラウドサービスプロバイダーの事例が含まれています。レポートでは、ウクライナがその後 Delta Platform を展開したことが説明されています。これは、複数のデータソースを統合してリアルタイムの状況認識、安全な軍事通信、自動化された脅威検出を可能にするクラウドネイティブの指揮統制プラットフォームです。クラウドベースのアプローチは、状況に即応した速度と大規模に運用するための基盤となっています。また、レポートが指摘するように、英国・ウクライナサイバープログラムなどのプログラムを通じた国際パートナーのサイバー能力支援も可能にしました。これは、有事の際にクラウドインフラストラクチャが同盟国間の迅速な国際協力をいかに促進できるかを示しています。 エストニア エストニアは、ルクセンブルクにデータ大使館を設立することで、デジタル継続性に対して積極的なアプローチを取っています。このデータ大使館には、国が侵攻された場合に亡命政府がアクセスできる重要な政府データベースが保存されており、最も極端なシナリオでも重要なデジタルガバナンス能力が存続することを保証しています。 フィンランド フィンランドは、ライブ・バーチャル・コンストラクティブ (LVC) 訓練システムを通じて、クラウドコンピューティングを活用して軍事訓練に変革をもたらしました。これらのクラウドベースのプラットフォームは、実機と仮想シミュレーターを統合し、従来のアプローチではコスト的に実現不可能な高度な訓練シナリオを可能にしています。このシステムは、国の規模にかかわらずクラウドを通じて高度な軍事能力にアクセスできることを実証しており、パフォーマンス分析とリアルタイムの訓練データ伝送により、かつてない訓練効果を実現しています。 英国 英国は、国家サイバーセキュリティセンターの Protective Domain Name Service (PDNS) などの取り組みを通じて、クラウド技術を国家サイバー防衛戦略に統合しています。このクラウドベースのシステムは、悪意のあるドメインへのアクセスを防止し、政府ネットワークと重要インフラをリアルタイムで保護します。英国政府は 2025 年 3 月に Borealis 宇宙監視システムを発表しました。このシステムは、衛星を保護し軍事的意思決定を支援するために、最高機密レベルまでの複数のソースからの情報を収集・処理することを目指しています。このプログラムは、クラウドが複雑な宇宙作戦に必要なスケールを提供しながら、機密性の高い防衛データを安全に処理できることを裏付けています。この事例は、クラウド環境での機密データの取り扱いを検討している各国の防衛当局にとって参考になります。 ウクライナ、エストニア、フィンランド、英国の事例は、クラウドコンピューティングが現代の国家安全保障インフラストラクチャの一部となったことを表しています。脅威が進化し続け、より高度化するにつれて、デジタル能力を迅速に展開、スケール、適応させる能力が、国家安全保障の成果をますます左右するようになるでしょう。 戦略的課題と考慮事項 RUSI のレポートは、欧州各国政府が検討すべき課題を挙げています。これには、ネットワーク接続性、相互運用性に影響を与えるレガシーシステムとの統合、デジタル主権の概念をめぐる不確実性、従来のインフラストラクチャ向けに設計された調達システムなどが含まれます。レポートは次のように結論付けています。「したがって、戦略的に検討すべきことは、政府がクラウド技術を採用すべきかどうかではなく、国家安全保障・防衛のメリットを最大化するためにトレードオフをどのように乗り越えるかである」 政府の行動に関する RUSI の推奨事項 RUSI のレポート は、国家安全保障・防衛目的でクラウドコンピューティングを活用しようとする欧州各国政府に対して、以下の推奨事項を提示しています。 国家安全保障・防衛のニーズに特化したクラウド採用の明確な戦略的方向性を策定し、原則に基づくトップダウンのアプローチで全機関の意思決定を導く 国家安全保障アプリケーションのクラウド採用を可能にするよう法的枠組みを改訂する シナリオベースのモデリングを使用して将来のコンピューティング要件を計画し、さまざまな状況における必要なコンピューティングリソースを把握する クラウドサービスの調達と保証機能を一元化する リスクベースのアプローチを採用する。データとサービスの重要度に基づいて調達を行い、有益なクラウド採用を妨げる過度に制限的なポリシーを避けながら、適切なセキュリティ対策を講じる クラウドソリューションを効果的に特定、採用、調達するために必要なスキルを人材が持てるよう、内部能力を構築する。これにより、調達の意思決定が技術的専門知識に基づいて行われるようになる クライアント側の暗号化、データポータビリティ要件、相互運用性標準、ハイブリッドまたはマルチクラウド戦略を含む依存性軽減戦略を実施する 共同演習、責任共有モデル、規制監督を通じて、政府とクラウドサービスプロバイダー間の信頼と透明性を醸成する。これにより、高度な機能へのアクセスを維持しながら、デジタル主権に関する懸念に対処できる つまり、ミッションを変革するには、組織全体が変革する必要があります。変革は、IT、調達、セキュリティ、法務、その他多くの機能にわたる新しい働き方を通じて実現される、強力なトップレベルのリーダーシップビジョンから始まります。組織全体が進化する必要があるのです。 クラウド技術により、ミッションベースのアプリケーションとサービスをアジャイルな方法で開発し、必要に応じて過度なコストをかけずにスケールできます。また、防衛組織にサイバーセキュリティの強固な基盤を提供します。オンプレミスでは多様なセキュリティ機能を常に最新の状態で維持することが難しいですが、クラウドであれば継続的に更新される豊富なセキュリティ機能を活用し、防衛組織のセキュリティ基盤を強化できます。 詳細情報 レジリエントなクラウドサービスの構築 AWS におけるデジタル主権 Trusted Secure Enclaves on AWS AWS NATO チームへのお問い合わせ 専門サポートのための認定 AWS パートナーへのお問い合わせ Chris Bailey Chris は AWS のグローバル国家安全保障・防衛担当ディレクターです。防衛業界での 30 年以上の経験を持ち、国家安全保障・防衛のクラウド採用プログラムの提供に関する専門家です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

AWS の年次フラッグシップイベントである  AWS re:Invent 2025  は、 2025 年 12 月 1 日から 5 日にかけて開催され、5 日間にわたる基調講演、ブレイクアウトセッション、製品発表、ライブデモが行われました。本イベントでは、多数の 新しいサービスや機能 が発表されました。本振り返りでは、自動車および製造業にとって特に重要なハイライトとして、主要な発表内容、実際のお客様事例、注目のデモを取り上げます。内容は戦略的なワークロード領域ごとに整理されており、現在のプロジェクトや優先事項に対応するトピックをすぐに確認できる構成になっています。 Autonomous Mobility 自動運転車 (AV) および高度運転支援システム (ADAS) の開発は、計算性能とストレージリソースの両面で非常に高い要求が課されるワークロードです。 AWS CEO の Matt Garman は 基調講演 において、 AWS Trainium3 チップを搭載した AWS Trainium3 UltraServers の一般提供開始を発表し、次世代の Trainium4 チップに関する展望も共有しました。Trainium3 UltraServers は、 AI トレーニングおよび推論ワークロード向けに高いパフォーマンスを提供し、 Trainium2 UltraServers と比較して最大 4.4 倍の計算性能、 4 倍のエネルギー効率、そして約 4 倍のメモリ帯域幅を実現します。これらは、次世代のエージェンティック AI 、推論モデル、強化学習に最適化されており、自動運転の意思決定システムのトレーニングや、複雑な運転シナリオを推論できる AI エージェントの開発に適しています。 AV および ADAS ワークロードでは、 Amazon S3 の最大オブジェクトサイズが 5 TB から 50 TB に 10 倍拡張されたことで、 LiDAR のポイントクラウド埋め込みやカメラ特徴ベクトルなど、巨大なセンサーデータセットの保存と分析が容易になりました。 Amazon S3 Vectors は現在一般提供されており、 1 インデックスあたり最大 20 億ベクトルまでスケールし、最大 90% のコスト削減を実現します。これにより、ペタバイト規模のデータで学習された知覚システムを支援します。 AWS はさらに、 Amazon OpenSearch Service においてサーバーレス GPU アクセラレーション と自動最適化されたベクトルインデックスを導入しました。これにより、大規模なベクトルデータベースを最大 10 倍高速かつ低コストで構築でき、リアルタイムの類似度検索が可能になります。加えて、 AWS Clean Rooms におけるプライバシー強化型の 合成データ生成 により、エッジケース向けのトレーニングデータ作成が可能になりました。また、 Amazon Nova 2 Omni （プレビュー） は、テキスト、画像、動画、音声を横断したマルチモーダル分析と推論を実現し、知覚および意思決定支援ワークフローを支えます。 AMZ304 のブレイクアウトセッションでは、 Zoox が Amazon SageMaker HyperPod を使用して自律走行ロボタクシー向けの基盤モデルをトレーニングしている事例を紹介しました。カメラ、 LiDAR 、レーダーデータを処理するマルチモーダルモデルを実行し、複雑なエッジケースに対応しています。Amazon SageMaker の Hybrid Sharded Data Parallelism (HSDP) とテンソル並列処理を組み合わせることで、 64 GPU を超える環境で 95% の GPU 利用率を達成し、 AWS Data Transfer Terminals を通じて最大 400 Gbps の速度で毎時最大 4 TB の車両データを取り込んでいます。Zoox は,   正式にサービスを開始した自律走行ロボタクシーサービスのデモンストレーションを、 re:Invent 期間中に実施しました。 Software Defined Vehicle (SDV) AWS は 2025 年 7 月に、仕様駆動型開発によって構想から本番までを支援する AI IDE Kiro をリリースしました。さらに AWS は、新たなクラスの AI エージェントである 3 つの frontier agents 発表しました。 Kiro 自律エージェント、 AWS Security Agent 、 AWS DevOps Agent は、ソフトウェア開発チームの一員として数時間から数日間稼働し続けることができます。 Kiro 自律エージェント は、ソフトウェア定義車両開発を加速するための仮想開発者として活用できます。 Matt Garman は基調講演で、 AWS 史上最も高性能かつ高効率な CPU である Graviton5 も紹介しました。 Graviton5 ベースの新しい Amazon EC2 インスタンスは、前世代と比較して最大 25% 高い性能を提供し、キャッシュサイズは 5 倍に拡大されています。 IND382 のセッションでは、日産自動車が AWS 上での新しい Nissan Scalable Open Software Platform を通じて、ソフトウェア定義車両の開発をどのように加速しているかを共有しました。このプラットフォームにより、テストは 75% 高速化され、世界中の 5,000 人以上の開発者がソフトウェア開発、データ管理、車両運用で協働できる統合クラウド環境が提供され、機能更新の迅速化が実現されています。また CMP360 のセッションでは、 AWS が Graviton5 の設計と性能について詳しく解説し、 Siemens 、 Synopsys 、 Honeycomb 、 Airbnb 、 SAP などの顧客による実ワークロードでの結果と、 Graviton プラットフォームへの移行および運用に関する知見が共有されました。 Connected Mobility すべての AWS お客様は、ワークロード向けに伸縮性と信頼性の高いコンピューティング基盤の恩恵を受けていますが、これはコネクテッドモビリティのバックエンドを運用する自動車業界のお客様にも当てはまります。 AWS は、 AWS Lambda (Lambda), Amazon Elastic Kubernetes (Amazon EKS) , Amazon EMR に対して、コネクテッドモビリティのユースケースに関連する新機能を発表しました。 AWS は Lambda Managed Instances を発表しました。これは、サーバーレスの運用の簡便さを維持しながら、独自の Amazon EC2 上で Lambda 関数を実行できる新機能です。この機能により、特定のコンピューティング要件への対応や、定常的なワークロードのコスト最適化が可能になります。 Lambda Durable Functions は、長時間実行されるタスクにおいて最大 1 年間の実行停止と自動チェックポイント、障害復旧を可能にし、信頼性の高いマルチステップアプリケーションや AI ワークフローを構築できます。 Amazon EMR Serverless は、 Apache Spark ワークロード向けに サーバーレスストレージ を提供し、ローカルストレージのプロビジョニングを不要にすることで、データ処理コストを最大 20% 削減し、ディスク容量不足によるジョブ失敗を防ぎます。 Amazon S3 Tables には 2 つの新機能が追加されました。データアクセスパターンの変化に応じてストレージコストを自動最適化する Intelligent-Tiering ストレージクラス と、 AWS リージョン および アカウント 間で Apache Iceberg テーブルの一貫したレプリカを自動的に維持する レプリケーション機能 です。これにより、地理的に分散したコネクテッド車両データの管理が可能になります。また AWS は、 AWS の Virtual Private Cloud (VPC) と他クラウド上の VPC を高速に接続できるマネージドプライベート接続サービス AWS Interconnect – multicloud （プレビュー） を発表しました。 IND308 のセッションでは、 BMW が Amazon API Gateway , AWS Step Functions , AWS Lambda , Amazon Simple Notification Service (SNS) , Amazon Simple Queue Service (SQS) , Amazon DynamoDB を用いて、モノリシックな Java EE アプリケーションからイベント駆動型サーバーレスアーキテクチャへ移行し、Connected Drive のリモートサービス基盤をモダナイズした事例を紹介しました。この新しいソリューションにより、新機能の市場投入までの時間は 60% 短縮され、 AWS インフラコストは 20% 削減され、インフラ運用負荷も軽減されました。現在では、 1 日あたり 166 億件以上のリクエストを処理し、 184 TB 以上のデータと 1 億件の API コールをサブ秒レイテンシーで処理し、 2,450 万台のコネクテッド車両を支えています。 Digital Customer Engagement デジタルカスタマーエンゲージメントは、音声、チャット、デジタルチャネル全体にわたって、シームレスでパーソナライズされ、信頼性の高い体験をエンドユーザーに提供すると同時に、ブランドの一貫性、コンプライアンス、運用ガバナンスを維持するというお客様のニーズによって推進されています。今回の発表では、会話型 AI モデルおよび本番環境で利用可能なエージェントに焦点が当てられました。 Amazon Nova 2 モデルファミリー は、顧客とのインタラクションの選択肢を拡張します。音声から音声までの体験を提供する Amazon Nova 2 Sonic 、 100 万トークンのコンテキストウィンドウによる拡張推論を可能にする Amazon Nova 2 Lite 、そしてテキスト、画像、動画、音声を横断したマルチモーダル入力に対応する Amazon Nova 2 Omni （プレビュー） が含まれます。カスタマージャーニーにおけるアクション実行のために、 Amazon Nova Act は、フォーム処理、検索および抽出、予約、 QA などの UI ワークフロー自動化を、信頼性高く構築、デプロイ、運用することを支援します。 エンタープライズ規模で安全かつ効果的にエージェントを構築、デプロイ、運用するために、 Amazon Bedrock AgentCore は、品質評価、ポリシー制御、強化されたメモリ機能、自然な対話機能を提供します。これにより、企業全体でエージェントを展開することが可能になります。さらに、 Amazon Bedrock では 18 種類のフルマネージドなオープンウェイトモデルを含むモデルカタログが拡充され 、品質、レイテンシー、コストのバランスに応じた柔軟な選択が可能になりました。 IND320 のセッションでは、 Toyota Motor North America と Toyota Connected が、 Amazon Bedrock を用いて AWS 上にエージェント型 AI プラットフォームを構築し、 RAG （検索拡張生成）ベースのディーラーアシスタントを提供している事例を紹介しました。このアシスタントは、公式な車両情報へ即座にアクセスでき、月間 7,000 件以上のインタラクションをサポートしています。 Toyota のプラットフォームは 2026 年に次世代システムへと進化し、 AgentCore Runtime , AgentCore Identity , AgentCore Memory を追加することで、安全にスケールし、ローカル在庫確認などのアクション実行を可能にする予定です。 IND3329 のセッションでは、 Cox Automotive が、エージェント型 AI をプロトタイプから本番環境へわずか数週間で移行した事例を紹介しました。同社は Amazon Bedrock AgentCore と Strands Agents を用いて 5 つのエージェント型 AI 製品をデプロイしました。完全自律型のバーチャルアシスタントは、人の介在なしに営業時間外の販売およびサービス対応を行っており、強力なガードレール、評価、コスト管理によって支えられています。 SPS313 のセッションでは、Volkswagen Group が、独自の画像ライブラリでトレーニングした カスタムファインチューニング 済みの拡散モデルと Amazon Nova を組み合わせ、各市場においてブランドガイドラインを自動的に適用することで、グローバルマーケティングをどのようにスケールさせたかを説明しました。 IND3326 および INV204 のセッションでは、大規模なデジタルエンゲージメントに焦点が当てられました。 Formula 1 は AWS Media Services とエージェント型 AI を活用し、同期されたマルチビュー配信を実現するとともに、運用上の根本原因分析を自動化しています。一方 Lyft は、会話型エージェントを用いてカスタマーサポートを変革し、解決までの時間を数分に短縮し、やり取りの半数以上を人のエージェントを介さずに解決しています。 製造およびサプライチェーン 生成 AI (GenAI) 、特にエージェント型 AI は、製造およびサプライチェーン管理を大きく変革しています。 Matt Garman の 基調講演 では、推論と行動が可能な最新の AI エージェント が、これまで専門家による判断や手作業を必要としていたタスクを担い始めていることが紹介されました。 Amazon Bedrock AgentCore は、品質評価、ポリシー制御、強化されたメモリ、自然な対話機能を追加し、信頼できる AI エージェントの展開を可能にします。これにより、メーカーは予知保全、品質管理、現場最適化といった領域で AI ソリューションを安心してスケールできます。さらに、 Strands Agents の エッジデバイス対応 により、 Strands Agents SDK を使って小規模デバイス上で動作する自律型 AI エージェントを構築でき、自動車、製造、ロボティクス分野における新たなエージェント型ユースケースが実現します。 IND367 のセッションでは、 Audi が AWS 上でトレーニングした AI ベースの品質検査モデルを製造品質プロセスに統合し、溶接継ぎ目の検査を手動サンプリングを大幅に上回るカバレッジで実施している事例を紹介しました。これにより、ほぼ 100% に近い溶接検査が可能となり、人的作業の削減と品質監視の向上を同時に実現しています。 HMC217 のセッションでは、 Rivian が AWS Outposts Gen2 を使用して、 SCADA （監視制御およびデータ収集）、 MES （製造実行システム）、ロボット制御などのミッションクリティカルな工場アプリケーションをエッジで実行している事例を紹介しました。クラウドネイティブなハイブリッド環境により、運用負荷を低減し、キャパシティプランニングを簡素化しています。 PEX305 のセッションでは、 Toyota が IBM などのパートナーとともに、 Amazon SageMaker AI などの AWS サービスを用いて、車両製造および物流全体にわたる配送 ETA の予測モデルを構築している事例を紹介しました。 API206-S のセッションでは、富士通が Amazon Bedrock AgentCore を活用してエージェント型サプライチェーンワークフローを実現している事例を共有しました。この仕組みでは、ガーディアンエージェントがエージェントの出力を継続的に監視し、エージェントの逸脱を修正します。 プロダクトエンジニアリング 自動車メーカーのプロダクトエンジニアリングチームは、コンセプト設計、生成最適化、シミュレーション、拠点間のエンジニアリングコラボレーションにおいて、迅速なサイクルを必要とします。 AWS は、 5 GHz プロセッサと 3 TiB のメモリを備えた新しい メモリ最適化・高周波数 EC2 X8aedz インスタンス の提供開始を発表しました。これらは、シミュレーションの前処理・後処理や大規模なエンジニアリングデータセットなど、メモリ集約型ワークロードを支援します。 Amazon SageMaker HyperPod のチェックポイントレスかつエラスティックなトレーニング は、エンジニアリング向け AI モデルの大規模トレーニングと反復に適用できます。グローバルチーム間で CAD、シミュレーション、テスト成果物を管理するために、 Amazon FSx for NetApp ONTAP と Amazon S3 の統合により、ファイルベースのエンジニアリングワークフローを維持しながら、 S3 スケールでのデータ階層化、共有、分析が可能になります。 CMP340 のセッションでは、 Toyota が AWS Parallel Computing Service (PCS) によって、 高性能コンピューティング (HPC) のセットアップ時間を 6 週間からわずか 30 分に短縮した事例を紹介しました。研究者はオンデマンドで大規模な CPU および GPU シミュレーションを起動し、長時間実行ジョブを実行し、ジョブ完了時に自動でリソースを停止できるようになり、ベンダーによる遅延が解消されました。 マイグレーションとモダナイゼーション AWS の自動車および製造業のお客様は、 AI を活用したサービスによってアプリケーションの移行とモダナイゼーションを加速しています。 AWS は AWS Transform を エージェント型機能 で拡張し、 Windows .NET アプリケーション、 VMware 環境、メインフレームのモダナイゼーションを支援しています。これにより、 11 億行を超えるコードを分析し、 81 万時間以上の手作業を削減しました。 AWS Transform custom は、あらゆるコード、API、フレームワーク、ランタイム、アーキテクチャ、言語、さらには企業独自のプログラミング言語やフレームワークに対して、組織全体でのモダナイゼーションを加速します。事前構築済みおよびカスタムの変換を通じて、多様なコードベースに対して一貫性と再現性のあるモダナイゼーションを実現します。また、 Amazon EKS Capabilities は、モダナイズされたプラットフォームにおけるワークロードのオーケストレーションとクラウドリソース管理を簡素化します。 IND218-S のセッションでは、 Mercedes-Benz が AWS 上で GenAI とエージェント型リファクタリングを活用し、メインフレームベースのグローバル受注システムをモダナイズした事例を紹介しました。 130 万行の COBOL を Java に変換し、最初のコミットから本番稼働まで 6 か月未満で、無事故のリリースを達成しました。 INV212 のセッションでは、 BMW と AWS が、 AWS Transform におけるドメイン特化エージェントが、調査、計画、リファクタリング、テストをどのように加速するかを紹介しました。AI 機能によって支えられた移行ファクトリーにより、テスト作成時間を数日から数時間に短縮し、75% 以上の時間と効率の改善、最大 60% のテストカバレッジ向上を達成しました。 BMW は MAM205 のセッションで再び登壇し、エージェント型 AI を活用したリファクタリングによってメインフレーム移行のリスクをどのように低減したかを詳しく説明しました。さらに、 PEX203 のセッションでは、 AWS Transform for VMware および .NET により、 EC2 と Aurora PostgreSQL 上の Linux ベースアーキテクチャへフルスタック Windows アプリケーションを移行できることが説明されました。 Toyota Motor North America は、サプライチェーンアプリケーションのメインフレーム移行を 50% 以上加速しています。 まとめ 本ブログでは、自動車および製造業界向けに関連性の高い AWS の発表内容と BMW 、 Toyota 、 Rivian 、 Nissan 、 Mercedes-Benz 、 Zoox といったお客様の革新的な事例をまとめました。これらの発表を確認し、ご自身のワークロードを支援できる機能を見極めていただくことをお勧めします。 新しい機能が組織の俊敏性と効率性をどのように支援できるかについて詳しく知りたい場合は、ぜひ AWS にご相談ください。 AWS for Automotive のページ をご覧いただくか、担当の AWS チームまでお気軽に お問い合わせ ください。 本ブログの翻訳はソリューションアーキテクトのショーン・セーヒー (Shawn Sehy) が担当しました。原文は「 AWS re:Invent 2025 Recap for Automotive and Manufacturing 」です。

AWS の年次フラッグシップイベントである  AWS re:Invent 2025  は、 2025 年 12 月 1 日から 5 日にかけて開催され、5 日間にわたる基調講演、ブレイクアウトセッション、製品発表、ライブデモが行われました。本イベントでは、多数の 新しいサービスや機能 が発表されました。本振り返りでは、自動車および製造業にとって特に重要なハイライトとして、主要な発表内容、実際のお客様事例、注目のデモを取り上げます。内容は戦略的なワークロード領域ごとに整理されており、現在のプロジェクトや優先事項に対応するトピックをすぐに確認できる構成になっています。 Autonomous Mobility 自動運転車 (AV) および高度運転支援システム (ADAS) の開発は、計算性能とストレージリソースの両面で非常に高い要求が課されるワークロードです。 AWS CEO の Matt Garman は 基調講演 において、 AWS Trainium3 チップを搭載した AWS Trainium3 UltraServers の一般提供開始を発表し、次世代の Trainium4 チップに関する展望も共有しました。Trainium3 UltraServers は、 AI トレーニングおよび推論ワークロード向けに高いパフォーマンスを提供し、 Trainium2 UltraServers と比較して最大 4.4 倍の計算性能、 4 倍のエネルギー効率、そして約 4 倍のメモリ帯域幅を実現します。これらは、次世代のエージェンティック AI 、推論モデル、強化学習に最適化されており、自動運転の意思決定システムのトレーニングや、複雑な運転シナリオを推論できる AI エージェントの開発に適しています。 AV および ADAS ワークロードでは、 Amazon S3 の最大オブジェクトサイズが 5 TB から 50 TB に 10 倍拡張されたことで、 LiDAR のポイントクラウド埋め込みやカメラ特徴ベクトルなど、巨大なセンサーデータセットの保存と分析が容易になりました。 Amazon S3 Vectors は現在一般提供されており、 1 インデックスあたり最大 20 億ベクトルまでスケールし、最大 90% のコスト削減を実現します。これにより、ペタバイト規模のデータで学習された知覚システムを支援します。 AWS はさらに、 Amazon OpenSearch Service においてサーバーレス GPU アクセラレーション と自動最適化されたベクトルインデックスを導入しました。これにより、大規模なベクトルデータベースを最大 10 倍高速かつ低コストで構築でき、リアルタイムの類似度検索が可能になります。加えて、 AWS Clean Rooms におけるプライバシー強化型の 合成データ生成 により、エッジケース向けのトレーニングデータ作成が可能になりました。また、 Amazon Nova 2 Omni （プレビュー） は、テキスト、画像、動画、音声を横断したマルチモーダル分析と推論を実現し、知覚および意思決定支援ワークフローを支えます。 AMZ304 のブレイクアウトセッションでは、 Zoox が Amazon SageMaker HyperPod を使用して自律走行ロボタクシー向けの基盤モデルをトレーニングしている事例を紹介しました。カメラ、 LiDAR 、レーダーデータを処理するマルチモーダルモデルを実行し、複雑なエッジケースに対応しています。Amazon SageMaker の Hybrid Sharded Data Parallelism (HSDP) とテンソル並列処理を組み合わせることで、 64 GPU を超える環境で 95% の GPU 利用率を達成し、 AWS Data Transfer Terminals を通じて最大 400 Gbps の速度で毎時最大 4 TB の車両データを取り込んでいます。Zoox は,   正式にサービスを開始した自律走行ロボタクシーサービスのデモンストレーションを、 re:Invent 期間中に実施しました。 Software Defined Vehicle (SDV) AWS は 2025 年 7 月に、仕様駆動型開発によって構想から本番までを支援する AI IDE Kiro をリリースしました。さらに AWS は、新たなクラスの AI エージェントである 3 つの frontier agents 発表しました。 Kiro 自律エージェント、 AWS Security Agent 、 AWS DevOps Agent は、ソフトウェア開発チームの一員として数時間から数日間稼働し続けることができます。 Kiro 自律エージェント は、ソフトウェア定義車両開発を加速するための仮想開発者として活用できます。 Matt Garman は基調講演で、 AWS 史上最も高性能かつ高効率な CPU である Graviton5 も紹介しました。 Graviton5 ベースの新しい Amazon EC2 インスタンスは、前世代と比較して最大 25% 高い性能を提供し、キャッシュサイズは 5 倍に拡大されています。 IND382 のセッションでは、日産自動車が AWS 上での新しい Nissan Scalable Open Software Platform を通じて、ソフトウェア定義車両の開発をどのように加速しているかを共有しました。このプラットフォームにより、テストは 75% 高速化され、世界中の 5,000 人以上の開発者がソフトウェア開発、データ管理、車両運用で協働できる統合クラウド環境が提供され、機能更新の迅速化が実現されています。また CMP360 のセッションでは、 AWS が Graviton5 の設計と性能について詳しく解説し、 Siemens 、 Synopsys 、 Honeycomb 、 Airbnb 、 SAP などの顧客による実ワークロードでの結果と、 Graviton プラットフォームへの移行および運用に関する知見が共有されました。 Connected Mobility すべての AWS お客様は、ワークロード向けに伸縮性と信頼性の高いコンピューティング基盤の恩恵を受けていますが、これはコネクテッドモビリティのバックエンドを運用する自動車業界のお客様にも当てはまります。 AWS は、 AWS Lambda (Lambda), Amazon Elastic Kubernetes (Amazon EKS) , Amazon EMR に対して、コネクテッドモビリティのユースケースに関連する新機能を発表しました。 AWS は Lambda Managed Instances を発表しました。これは、サーバーレスの運用の簡便さを維持しながら、独自の Amazon EC2 上で Lambda 関数を実行できる新機能です。この機能により、特定のコンピューティング要件への対応や、定常的なワークロードのコスト最適化が可能になります。 Lambda Durable Functions は、長時間実行されるタスクにおいて最大 1 年間の実行停止と自動チェックポイント、障害復旧を可能にし、信頼性の高いマルチステップアプリケーションや AI ワークフローを構築できます。 Amazon EMR Serverless は、 Apache Spark ワークロード向けに サーバーレスストレージ を提供し、ローカルストレージのプロビジョニングを不要にすることで、データ処理コストを最大 20% 削減し、ディスク容量不足によるジョブ失敗を防ぎます。 Amazon S3 Tables には 2 つの新機能が追加されました。データアクセスパターンの変化に応じてストレージコストを自動最適化する Intelligent-Tiering ストレージクラス と、 AWS リージョン および アカウント 間で Apache Iceberg テーブルの一貫したレプリカを自動的に維持する レプリケーション機能 です。これにより、地理的に分散したコネクテッド車両データの管理が可能になります。また AWS は、 AWS の Virtual Private Cloud (VPC) と他クラウド上の VPC を高速に接続できるマネージドプライベート接続サービス AWS Interconnect – multicloud （プレビュー） を発表しました。 IND308 のセッションでは、 BMW が Amazon API Gateway , AWS Step Functions , AWS Lambda , Amazon Simple Notification Service (SNS) , Amazon Simple Queue Service (SQS) , Amazon DynamoDB を用いて、モノリシックな Java EE アプリケーションからイベント駆動型サーバーレスアーキテクチャへ移行し、Connected Drive のリモートサービス基盤をモダナイズした事例を紹介しました。この新しいソリューションにより、新機能の市場投入までの時間は 60% 短縮され、 AWS インフラコストは 20% 削減され、インフラ運用負荷も軽減されました。現在では、 1 日あたり 166 億件以上のリクエストを処理し、 184 TB 以上のデータと 1 億件の API コールをサブ秒レイテンシーで処理し、 2,450 万台のコネクテッド車両を支えています。 Digital Customer Engagement デジタルカスタマーエンゲージメントは、音声、チャット、デジタルチャネル全体にわたって、シームレスでパーソナライズされ、信頼性の高い体験をエンドユーザーに提供すると同時に、ブランドの一貫性、コンプライアンス、運用ガバナンスを維持するというお客様のニーズによって推進されています。今回の発表では、会話型 AI モデルおよび本番環境で利用可能なエージェントに焦点が当てられました。 Amazon Nova 2 モデルファミリー は、顧客とのインタラクションの選択肢を拡張します。音声から音声までの体験を提供する Amazon Nova 2 Sonic 、 100 万トークンのコンテキストウィンドウによる拡張推論を可能にする Amazon Nova 2 Lite 、そしてテキスト、画像、動画、音声を横断したマルチモーダル入力に対応する Amazon Nova 2 Omni （プレビュー） が含まれます。カスタマージャーニーにおけるアクション実行のために、 Amazon Nova Act は、フォーム処理、検索および抽出、予約、 QA などの UI ワークフロー自動化を、信頼性高く構築、デプロイ、運用することを支援します。 エンタープライズ規模で安全かつ効果的にエージェントを構築、デプロイ、運用するために、 Amazon Bedrock AgentCore は、品質評価、ポリシー制御、強化されたメモリ機能、自然な対話機能を提供します。これにより、企業全体でエージェントを展開することが可能になります。さらに、 Amazon Bedrock では 18 種類のフルマネージドなオープンウェイトモデルを含むモデルカタログが拡充され 、品質、レイテンシー、コストのバランスに応じた柔軟な選択が可能になりました。 IND320 のセッションでは、 Toyota Motor North America と Toyota Connected が、 Amazon Bedrock を用いて AWS 上にエージェント型 AI プラットフォームを構築し、 RAG （検索拡張生成）ベースのディーラーアシスタントを提供している事例を紹介しました。このアシスタントは、公式な車両情報へ即座にアクセスでき、月間 7,000 件以上のインタラクションをサポートしています。 Toyota のプラットフォームは 2026 年に次世代システムへと進化し、 AgentCore Runtime , AgentCore Identity , AgentCore Memory を追加することで、安全にスケールし、ローカル在庫確認などのアクション実行を可能にする予定です。 IND3329 のセッションでは、 Cox Automotive が、エージェント型 AI をプロトタイプから本番環境へわずか数週間で移行した事例を紹介しました。同社は Amazon Bedrock AgentCore と Strands Agents を用いて 5 つのエージェント型 AI 製品をデプロイしました。完全自律型のバーチャルアシスタントは、人の介在なしに営業時間外の販売およびサービス対応を行っており、強力なガードレール、評価、コスト管理によって支えられています。 SPS313 のセッションでは、Volkswagen Group が、独自の画像ライブラリでトレーニングした カスタムファインチューニング 済みの拡散モデルと Amazon Nova を組み合わせ、各市場においてブランドガイドラインを自動的に適用することで、グローバルマーケティングをどのようにスケールさせたかを説明しました。 IND3326 および INV204 のセッションでは、大規模なデジタルエンゲージメントに焦点が当てられました。 Formula 1 は AWS Media Services とエージェント型 AI を活用し、同期されたマルチビュー配信を実現するとともに、運用上の根本原因分析を自動化しています。一方 Lyft は、会話型エージェントを用いてカスタマーサポートを変革し、解決までの時間を数分に短縮し、やり取りの半数以上を人のエージェントを介さずに解決しています。 製造およびサプライチェーン 生成 AI (GenAI) 、特にエージェント型 AI は、製造およびサプライチェーン管理を大きく変革しています。 Matt Garman の 基調講演 では、推論と行動が可能な最新の AI エージェント が、これまで専門家による判断や手作業を必要としていたタスクを担い始めていることが紹介されました。 Amazon Bedrock AgentCore は、品質評価、ポリシー制御、強化されたメモリ、自然な対話機能を追加し、信頼できる AI エージェントの展開を可能にします。これにより、メーカーは予知保全、品質管理、現場最適化といった領域で AI ソリューションを安心してスケールできます。さらに、 Strands Agents の エッジデバイス対応 により、 Strands Agents SDK を使って小規模デバイス上で動作する自律型 AI エージェントを構築でき、自動車、製造、ロボティクス分野における新たなエージェント型ユースケースが実現します。 IND367 のセッションでは、 Audi が AWS 上でトレーニングした AI ベースの品質検査モデルを製造品質プロセスに統合し、溶接継ぎ目の検査を手動サンプリングを大幅に上回るカバレッジで実施している事例を紹介しました。これにより、ほぼ 100% に近い溶接検査が可能となり、人的作業の削減と品質監視の向上を同時に実現しています。 HMC217 のセッションでは、 Rivian が AWS Outposts Gen2 を使用して、 SCADA （監視制御およびデータ収集）、 MES （製造実行システム）、ロボット制御などのミッションクリティカルな工場アプリケーションをエッジで実行している事例を紹介しました。クラウドネイティブなハイブリッド環境により、運用負荷を低減し、キャパシティプランニングを簡素化しています。 PEX305 のセッションでは、 Toyota が IBM などのパートナーとともに、 Amazon SageMaker AI などの AWS サービスを用いて、車両製造および物流全体にわたる配送 ETA の予測モデルを構築している事例を紹介しました。 API206-S のセッションでは、富士通が Amazon Bedrock AgentCore を活用してエージェント型サプライチェーンワークフローを実現している事例を共有しました。この仕組みでは、ガーディアンエージェントがエージェントの出力を継続的に監視し、エージェントの逸脱を修正します。 プロダクトエンジニアリング 自動車メーカーのプロダクトエンジニアリングチームは、コンセプト設計、生成最適化、シミュレーション、拠点間のエンジニアリングコラボレーションにおいて、迅速なサイクルを必要とします。 AWS は、 5 GHz プロセッサと 3 TiB のメモリを備えた新しい メモリ最適化・高周波数 EC2 X8aedz インスタンス の提供開始を発表しました。これらは、シミュレーションの前処理・後処理や大規模なエンジニアリングデータセットなど、メモリ集約型ワークロードを支援します。 Amazon SageMaker HyperPod のチェックポイントレスかつエラスティックなトレーニング は、エンジニアリング向け AI モデルの大規模トレーニングと反復に適用できます。グローバルチーム間で CAD、シミュレーション、テスト成果物を管理するために、 Amazon FSx for NetApp ONTAP と Amazon S3 の統合により、ファイルベースのエンジニアリングワークフローを維持しながら、 S3 スケールでのデータ階層化、共有、分析が可能になります。 CMP340 のセッションでは、 Toyota が AWS Parallel Computing Service (PCS) によって、 高性能コンピューティング (HPC) のセットアップ時間を 6 週間からわずか 30 分に短縮した事例を紹介しました。研究者はオンデマンドで大規模な CPU および GPU シミュレーションを起動し、長時間実行ジョブを実行し、ジョブ完了時に自動でリソースを停止できるようになり、ベンダーによる遅延が解消されました。 マイグレーションとモダナイゼーション AWS の自動車および製造業のお客様は、 AI を活用したサービスによってアプリケーションの移行とモダナイゼーションを加速しています。 AWS は AWS Transform を エージェント型機能 で拡張し、 Windows .NET アプリケーション、 VMware 環境、メインフレームのモダナイゼーションを支援しています。これにより、 11 億行を超えるコードを分析し、 81 万時間以上の手作業を削減しました。 AWS Transform custom は、あらゆるコード、API、フレームワーク、ランタイム、アーキテクチャ、言語、さらには企業独自のプログラミング言語やフレームワークに対して、組織全体でのモダナイゼーションを加速します。事前構築済みおよびカスタムの変換を通じて、多様なコードベースに対して一貫性と再現性のあるモダナイゼーションを実現します。また、 Amazon EKS Capabilities は、モダナイズされたプラットフォームにおけるワークロードのオーケストレーションとクラウドリソース管理を簡素化します。 IND218-S のセッションでは、 Mercedes-Benz が AWS 上で GenAI とエージェント型リファクタリングを活用し、メインフレームベースのグローバル受注システムをモダナイズした事例を紹介しました。 130 万行の COBOL を Java に変換し、最初のコミットから本番稼働まで 6 か月未満で、無事故のリリースを達成しました。 INV212 のセッションでは、 BMW と AWS が、 AWS Transform におけるドメイン特化エージェントが、調査、計画、リファクタリング、テストをどのように加速するかを紹介しました。AI 機能によって支えられた移行ファクトリーにより、テスト作成時間を数日から数時間に短縮し、75% 以上の時間と効率の改善、最大 60% のテストカバレッジ向上を達成しました。 BMW は MAM205 のセッションで再び登壇し、エージェント型 AI を活用したリファクタリングによってメインフレーム移行のリスクをどのように低減したかを詳しく説明しました。さらに、 PEX203 のセッションでは、 AWS Transform for VMware および .NET により、 EC2 と Aurora PostgreSQL 上の Linux ベースアーキテクチャへフルスタック Windows アプリケーションを移行できることが説明されました。 Toyota Motor North America は、サプライチェーンアプリケーションのメインフレーム移行を 50% 以上加速しています。 まとめ 本ブログでは、自動車および製造業界向けに関連性の高い AWS の発表内容と BMW 、 Toyota 、 Rivian 、 Nissan 、 Mercedes-Benz 、 Zoox といったお客様の革新的な事例をまとめました。これらの発表を確認し、ご自身のワークロードを支援できる機能を見極めていただくことをお勧めします。 新しい機能が組織の俊敏性と効率性をどのように支援できるかについて詳しく知りたい場合は、ぜひ AWS にご相談ください。 AWS for Automotive のページ をご覧いただくか、担当の AWS チームまでお気軽に お問い合わせ ください。 本ブログの翻訳はソリューションアーキテクトのショーン・セーヒー (Shawn Sehy) が担当しました。原文は「 AWS re:Invent 2025 Recap for Automotive and Manufacturing 」です。

みなさん、こんにちは。 いなりく です。 新年あけましておめでとうございます。みなさん Kiro ライフをいかがお過ごしでしょうか。 Kiro CLI 1.24.0 では、 大規模なドキュメントセットの段階的な読み込みを可能にする Skills 、 カスタム Diff ツール 、 18 言語に対応した組み込みコードインテリジェンス 、 リモート認証 、 web_fetch ツールの詳細な権限管理 、 長時間のセッションをスムーズに維持する会話 圧縮の詳細なコントールが導入されました。これらのアップデートが私の Kiro ライフを更に快適にしてくれたので、今回はこれらの追加された機能を深堀ってご紹介します。Kiro って何？という方は「 Kiroweeeeeeek in Japan 開催のお知らせ 」を読んでいただけると Kiro の全体像を掴んでいただけると思います。気になるアップデートのセクションおよび移行ガイドだけを読んでいただいても問題ありません。Kiro CLI の v.1.21.0 から v.1.23.0 までのアップデートに関しては「 Kiro CLI 新機能まとめ : v1.21.0 から v1.23.0 」をぜひお読み下さい。 アップデート１ : Skills による段階的なコンテキスト読み込み アップデート２ : カスタム Diff ツール アップデート 3 : AST パターンツールによる正確なリファクタリング アップデート 4 : 改善されたコードインテリジェンス アップデート 5 : 会話圧縮の詳細なコントロール アップデート 6 : web_fetch ツールの詳細な URL 権限管理 アップデート 7 : リモート認証 移行ガイド アップデート 1 : Skills による段階的なコンテキスト読み込み Skills は起動時にはメタデータ（名前と説明）のみが読み込まれ、エージェントが必要と判断したときにのみ完全なコンテンツが読み込まれます。これにより、コンテキストウィンドウを効率的に管理しながら、広範なドキュメントへのアクセスを提供できます。 Skills の仕組み 従来の Steering ファイルは、エージェント起動時にすべてのコンテンツをコンテキストウィンドウに読み込みます。これは小規模なファイルには適していますが、大規模なドキュメントセットではコンテキストウィンドウを圧迫してしまいます。 Skills は以下のアプローチを採用しています。 起動時 ：名前と説明のみが読み込まれる 実行時 ：エージェントが関連性を判断し、必要に応じて完全なコンテンツを読み込む 効率性 ：使用されないドキュメントはコンテキストを消費しない Skills ファイルの作成 Skills ファイルには、YAML フロントマターで記述された説明的なメタデータが必要です。エージェントが完全なコンテンツを読み込むタイミングを確実に判断できるよう、具体的な説明を記述してください。 --- name: dynamodb-data-modeling description: DynamoDB データモデリングのベストプラクティスガイド。DynamoDB スキーマの設計または分析時に使用。 --- # DynamoDB データモデリング ## 概要 DynamoDB は NoSQL データベースで、適切なデータモデリングが重要です... ## パーティションキーの設計 パーティションキーは均等に分散する必要があります... ## ソートキーのパターン ソートキーを使用すると、効率的なクエリパターンが可能になります... Skills と Steering の使い分け Skills を使用する場合： 大規模なドキュメントセット（API リファレンス、アーキテクチャガイドなど） 特定のタスクでのみ必要な専門知識 コンテキストウィンドウの効率的な管理が必要な場合 複数のトピックに分かれた参照ドキュメント Steering を使用する場合： すべての会話で常に必要な小規模なファイル（README、設定ファイルなど） プロジェクトの基本情報やコンテキスト エージェントの動作を常に制御したいコーディング規約やスタイルガイド カスタムエージェント設定での Steering/Skills の使用 カスタムエージェントでは Skills/Steering ファイルは自動で読み込まれず、カスタムエージェント設定ファイルの resources フィールドで明示的に指定する必要があります。Glob パターンを使用すると、複数の SKill ファイルを一度に含めることができます。エージェントは各 Skills のメタデータを読み込み、会話の文脈に基づいて関連する Skill を自動的に読み込みます。 以下の例では README.md と Steering ファイル（coding-standards.md、project-rules.md）はカスタムエージェントで常に読み込まれ、Skills として、api-reference.md、architecture-guide.md、deployment-guide.md が必要なときだけ読み込まれます。 詳細については、 Skills リソースのドキュメント を参照してください。 { "resources": [ "file://README.md", "file://.kiro/steering/coding-standards.md", "file://.kiro/steering/project-rules.md", "skill://docs/api-reference.md", "skill://docs/architecture-guide.md", "skill://docs/deployment-guide.md" ] } アップデート ２ : カスタム Diff ツール Kiro がファイルの変更を提案する際、デフォルトでは組み込みの Diff ツールを使用して変更内容を表示します。1.24.0 では、外部の Diff ツールを設定できるようになり、シンタックスハイライト、サイドバイサイド表示、お気に入りの GUI ツールなど、好みの Diff 表示方法を選択できます。 設定方法 chat.diffTool 設定で、好みの Diff ツールを指定します。 kiro-cli settings chat.diffTool delta カスタム Diff ツール (delta を利用した場合) 組み込みの Diff には以下のコマンドで戻すことができます。 kiro-cli settings -d chat.diffTool 組み込み diff ツール ターミナルツール ターミナルで直接 Diff を表示するツールは、ワークフローを中断しません。 delta ：Git ユーザー向けのシンタックスハイライトと行番号表示 difftastic ：フォーマットの違いを無視する言語対応の構造的 Diff icdiff ：素早いサイドバイサイドのカラー比較 diff-so-fancy ：クリーンで人間が読みやすい出力 colordiff ：シンプルなカラー表示の Diff bat ：Git 統合を備えたシンタックスハイライト GUI ツール 変更内容を別ウィンドウで確認できる GUI ツールもサポートしています： VS Code ： code Meld ： meld KDiff3 ： kdiff3 FileMerge (macOS) ： opendiff Vim ： vimdiff Neovim ： nvim 注意： GUI Diff ツールは表示専用の一時ファイルを開きます。GUI ツールで行った編集は保存されず、Kiro の提案された変更には適用されません。 カスタム引数の使用 引用符で囲むことで、ツールの動作をカスタマイズできます。 # delta でサイドバイサイド表示を有効化 kiro-cli settings chat.diffTool "delta --side-by-side" 詳細については、 カスタム Diff ツールのドキュメント を参照してください。 アップデート 3 : AST パターンツールによる正確なリファクタリング 新しい pattern-search と pattern-rewrite ツールにより、エージェントはテキストの正規表現ではなく、構文木パターンを使用してコードを検索および変換できます。これにより、文字列リテラルやコメント内の誤検出がなくなります。 pattern-search の使用例 # すべての async 関数を検索 > async function $NAME($$$PARAMS) { $$$ } という構造のコードを検索して # 特定のメソッド呼び出しを検索 > $OBJ.setState($$$ARGS) のパターンを検索して pattern-rewrite の使用例 # var を const に変換 > var 宣言をすべて const に書き換えて # 古い API を新しい API に変換 > $O.hasOwnProperty($P) を Object.hasOwn($O, $P) に書き換えて メタ変数を使用してパターンを定義します。 $VAR ：単一のノード（識別子、式）にマッチ $$$ ：ゼロ個以上のノード（文、パラメータ）にマッチ これらのツールは、コードの構造を理解するため、テキストベースの検索置換よりも正確で安全なリファクタリングが可能です。 アップデート 4 : 改善されたコードインテリジェンス Kiro CLI は、セットアップ不要で 18 言語に対応した組み込みのコードインテリジェンスを提供します。エージェントは、シンボル検索、定義へのナビゲーション、構造的なコード検索を即座に実行できます。 対応言語 Bash、C、C++、C#、Elixir、Go、Java、JavaScript、Kotlin、Lua、PHP、Python、Ruby、Rust、Scala、Swift、TSX、TypeScript 組み込み機能 シンボル検索 ：コードベース全体で関数、クラス、変数を検索 ドキュメントシンボル ：ファイル内のすべてのシンボルをリスト表示 シンボルルックアップ ：定義に即座にジャンプ パターン検索 ：AST ベースの構造的コード検索 パターン書き換え ：AST パターンを使用した自動コード変換 コードベースマップ ：ディレクトリ構造の探索とコード構成の理解 コードベース概要 任意のワークスペースの概要を素早く取得できます。 /code overview クリーンな出力には --silent を使用します。 /code overview --silent これは以下の場合に便利です： 新しいコードベースへのオンボーディング プロジェクト構造に関する Q&A セッション 未知のパッケージを素早く理解 LSP 統合（オプション） 参照の検索、ホバードキュメント、リファクタリングのリネームなどの拡張機能を使用するには、LSP 統合を有効にできます。プロジェクトルートで以下のコマンドを実行することで、 .kiro/settings/lsp.json 設定が作成され、言語サーバーが起動します。 /code init 使用例 # シンボルを検索 > UserRepository クラスを検索して # すべての参照を検索 > Person クラスの参照をすべて検索して # 定義に移動 > UserService の定義を検索して # ファイル内のシンボルを取得 > auth.service.ts にはどんなシンボルがある？ # ホバードキュメントを取得 > AuthService の authenticate メソッドのドキュメントは？ # 利用可能なメソッドを発見 > s3Client インスタンスで使えるメソッドは？ 詳細については、 コードインテリジェンスのドキュメント を参照してください。 アップデート 5 : 会話圧縮の詳細なコントロール /compact コマンドを利用することで会話履歴を要約し、重要な情報を保持しながらコンテキストスペースを解放することができます。今回のアップデートでは保持するメッセージと最小コンテキストウィンドウの割合を指定することが可能になりました。 圧縮の仕組み 圧縮は、古いメッセージを要約しながら最近のメッセージを保持します。これにより、会話の文脈を維持しながら、コンテキストウィンドウを効率的に使用できます。 手動圧縮 ： /compact コマンドを実行 自動圧縮 ：コンテキストウィンドウがオーバーフローすると自動的にトリガー 設定 保持するメッセージの量を設定できます。 compaction.excludeMessages （デフォルト：2）：保持する最小メッセージペア数 compaction.excludeContextWindowPercent （デフォルト：2）：保持する最小コンテキストウィンドウの割合 両方の設定が評価され、より保守的な（大きい）値が優先されます。 圧縮後の操作 # 手動で圧縮を実行 /compact # 元のセッションに戻る /chat resume 詳細については、 会話の圧縮のドキュメント を参照してください。 アップデート 6 : web_fetch ツールの詳細な URL 権限管理 エージェント設定を通じて、エージェントがアクセスできる URL を制御できるようになりました。正規表現パターンを使用して、信頼できるドメインを自動的に許可したり、特定のサイトをブロックしたりできます。 設定方法 エージェント設定ファイルの toolsSettings で URL ベースの権限を設定します。 { "toolsSettings": { "web_fetch": { "trusted": [".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com.*"], "blocked": [".*pastebin\\.com.*"] } } } パターンの動作 パターンは正規表現で、自動的に ^ と $ でアンカーされます blocked は trusted よりも優先されます blocked の無効な正規表現は、すべての URL を拒否します（フェイルセーフ） trusted の無効な正規表現はスキップされます 信頼されたパターンに一致しない URL は、承認を求めるプロンプトが表示されます 使用例 { "toolsSettings": { "web_fetch": { "trusted": [ ".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com/myorg/.*", ".*stackoverflow\\.com.*" ], "blocked": [ ".*pastebin\\.com.*", ".*privatesite\\.internal.*" ] } } } この設定により、AWS ドキュメント、組織の GitHub リポジトリ、Stack Overflow への自動アクセスが許可され、特定のサイトがブロックされます。 詳細については、 web_fetch ツールのドキュメント を参照してください。 アップデート 7 : リモート認証 リモートマシン（SSH、SSM、コンテナ経由）で Kiro CLI を実行する際、Google または GitHub でサインインできるようになりました。ポートフォワーディングにより、認証が機能します。 Builder ID と IAM Identity Center Builder ID と IAM Identity Center の場合、デバイスコード認証がそのまま機能します。URL とコードをローカルブラウザに入力するだけです。 ソーシャルログイン（Google または GitHub） ソーシャルログインの場合、CLI は PKCE 認証を使用し、ポートフォワーディングが必要です。OAuth コールバックは localhost にリダイレクトされるため、トンネルなしではリモート CLI に到達できません。 リモートマシンでのサインイン手順 kiro-cli login を実行し、「Use for Free with Google or GitHub」を選択 表示されたポート番号をメモ（毎回異なります。例： 49153 ） ローカルマシンの新しいターミナルで、ポートフォワーディングを設定： ssh -L <PORT>:localhost:<PORT> -N user@remote-host <PORT> をステップ 2 のポートに、 user@remote-host をリモート認証情報に置き換えます。 CLI で Enter キーを押し、ローカルブラウザで URL を開きます 認証を完了すると、コールバックがトンネル経由で CLI に到達します SSH ポートフォワーディングの例 # 基本的なポートフォワーディング（49153 を実際のポートに置き換え） ssh -L 49153:localhost:49153 -N user@remote-host # カスタム ID ファイルを使用（EC2 で一般的） ssh -i ~/.ssh/my-key.pem -L 49153:localhost:49153 -N user@remote-host # SSH 設定エイリアスを使用 ssh -L 49153:localhost:49153 -N myserver 詳細については、 リモート認証のドキュメント を参照してください。 移行ガイド 既存の Kiro CLI ユーザーが 1.24.0 にアップグレードする際のガイドラインです。 ステップ 1：常に読み込みが必要ではない Steering ファイルを Skills に変換 既存の Steering ファイルの中に常に読み込みが必要ではないものがある場合は、Skills に変換することを検討してください。 変換前： { "resources": [ "file://docs/api-reference.md", "file://docs/architecture-guide.md" ] } 変換後： 1. 各ファイルに YAML フロントマターを追加 --- name: api-reference description: API リファレンスドキュメント。API エンドポイント、リクエスト/レスポンス形式、認証方法について記載。 --- # API リファレンス ... 2. エージェント設定を更新： { "resources": [ "skill://docs/api-reference.md", "skill://docs/architecture-guide.md" ] } ステップ 2：カスタム Diff ツールの設定 お気に入りの Diff ツールがある場合は、設定してください。 # delta を使用する場合 kiro-cli settings chat.diffTool delta # サイドバイサイド表示を有効化 kiro-cli settings chat.diffTool "delta --side-by-side" ステップ 3：URL 権限の設定 web_fetch ツールを使用している場合は、信頼できるドメインを設定してください。 { "toolsSettings": { "web_fetch": { "trusted": [ ".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com/your-org/.*" ] } } } ステップ 4：コードインテリジェンスの有効化 プロジェクトルートで LSP を初期化 /code init まとめ Kiro CLI 1.24.0 は、開発者の生産性を向上させる多くの新機能を提供します。Skills による効率的なコンテキスト管理、カスタム Diff ツールによる柔軟な変更レビュー、18 言語に対応した組み込みコードインテリジェンス、会話の圧縮による長時間セッションのサポート、詳細な URL 権限管理、リモート認証のサポートなど、開発ワークフローを強化する機能が満載です。 今すぐ Kiro CLI 1.24.0 にアップグレードもしくは インストール して、これらの新機能をお試しください！みなさんの Kiro ライフがより快適になることを願っています！ 著者 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

本記事は 2026 年 01 月 13 日 に公開された “Build durable AI agents with LangGraph and Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/build-durable-ai-agents-with-langgraph-and-amazon-dynamodb/ 私は AI エージェントの急速な進化に魅了されてきました。過去 1 年間で、AI エージェントがシンプルなチャットボットから、複雑な問題を推論し、意思決定を行い、長い会話全体でコンテキストを維持できる洗練されたシステムへと成長するのを見てきました。しかし、エージェントの性能はメモリの質次第です。 この記事では、 Amazon DynamoDB と LangGraph を使用し、新しい DynamoDBSaver コネクタを活用して、耐久性のある状態管理を備えた本番環境対応の AI エージェントを構築する方法を紹介します。DynamoDBSaver は、AWS が Amazon DynamoDB 向けに保守している LangGraph チェックポイントライブラリです。これは、DynamoDB と LangGraph 専用に構築された本番環境対応の永続化レイヤーを提供し、ペイロードのサイズに基づいてインテリジェントに処理しながらエージェントの状態を保存します。 この実装により、エージェントがスケールし、障害から回復し、長時間実行されるワークフローを維持するために必要な永続性を得る方法を学びます。 Amazon DynamoDB の概要 Amazon DynamoDB は、あらゆる規模で 1 桁ミリ秒のパフォーマンスを実現する、サーバーレスでフルマネージドな分散 NoSQL データベースです。構造化データまたは半構造化データを保存し、一貫したミリ秒単位のレイテンシーでクエリを実行し、サーバーやインフラストラクチャを管理することなく自動的にスケールできます。DynamoDB は低レイテンシーと高可用性を実現するように構築されているため、セッションデータ、ユーザープロファイル、メタデータ、またはアプリケーションの状態を保存するためによく使用されます。これらの同じ特性により、AI エージェントのチェックポイントとスレッドメタデータを保存するための理想的な選択肢となっています。 LangGraph の紹介 LangGraph は、複雑なグラフベースの AI ワークフローを構築するために設計された LangChain のオープンソースフレームワークです。プロンプトと関数を一直線に連鎖させる代わりに、LangGraph では分岐、マージ、ループが可能なノードを定義できます。各ノードはタスクを実行し、エッジがノード間のフローを制御します。 LangGraph はいくつかの重要な概念を導入しています: スレッド (Threads) : スレッドは、一連の実行の累積状態を含む各チェックポイントに割り当てられる一意の識別子です。グラフが実行されると、その状態はスレッドに永続化されます。これには、config で thread_id を指定する必要があります ( {"configurable": {"thread_id": "1"}} )。状態を永続化するには、実行前にスレッドを作成する必要があります。 チェックポイント (Checkpoints) : チェックポイントは、各スーパーステップで保存されるグラフ状態のスナップショットで、config、メタデータ、状態チャネル値、実行する次のノード、タスク情報 (エラーや中断データを含む) を含む StateSnapshot オブジェクトで表されます。チェックポイントは永続化され、後でスレッドの状態を復元できます。たとえば、シンプルな 2 ノードグラフは 4 つのチェックポイントを作成します: START での空のチェックポイント、node_a の前のユーザー入力を含むもの、node_b の前の node_a の出力を含むもの、そして END での node_b の出力を含む最終的なものです。 永続性 (Persistence) : 永続性は、チェックポインタの実装を使用して、チェックポイントがどこにどのように保存されるか (メモリ内、データベース、外部ストレージなど) を決定します。チェックポインタは各スーパーステップでスレッドの状態を保存し、履歴状態の取得を可能にし、グラフがチェックポイントから再開したり、以前の実行状態を復元したりできるようにします。 永続性により、ヒューマン・イン・ザ・ループレビュー、リプレイ、障害後の再開、状態間のタイムトラベルなどの高度な機能が可能になります。 InMemorySaver は、LangGraph の組み込みチェックポイントメカニズムで、会話の状態とグラフ実行履歴をメモリに保存し、永続性、タイムトラベルデバッグ、ヒューマン・イン・ザ・ループワークフローなどの機能を有効にします。 InMemorySaver は高速なプロトタイピングに使用できますが、状態はメモリ内にのみ存在し、アプリケーションの再起動時に失われます。 次の図は、LangGraph のチェックポイントアーキテクチャを示しています。高レベルのワークフロー (スーパーステップ) が START から END までノードを通じて実行される一方で、チェックポインタが継続的に状態スナップショットをメモリ ( InMemorySaver ) に保存します: 永続性が重要な理由 デフォルトでは、LangGraph は InMemorySaver を使用してチェックポイントをメモリに保存します。これはセットアップが不要で、即座に読み書きアクセスが可能なため、実験には最適です。 しかし、メモリ内ストレージには 2 つの大きな制限があります。それは一時的でローカルであることです。プロセスが停止すると、データは失われます。複数のワーカーを実行する場合、各インスタンスは独自のメモリを保持します。他の場所で開始されたセッションを再開することはできず、ワークフローが途中でクラッシュした場合に回復することもできません。 本番環境では、これは受け入れられません。エージェントが中断した場所から再開し、ノード間でスケールし、分析や監査のために履歴を保持できる、永続的でフォールトトレラントなストアが必要です。そこで DynamoDBSaver の出番です。 複雑な複数ステップの問い合わせを処理するカスタマーサポートエージェントを構築しているシナリオを想像してください。顧客が注文について尋ね、エージェントが情報を取得し、応答を生成し、応答を送信する前に人間の承認を待ちます。 しかし、次のような場合はどうなるでしょうか: ワークフローの途中でサーバーがタイムアウトした場合 複数のワーカーにスケールする必要がある場合 顧客が数時間後に戻って会話を続ける場合 エージェントの意思決定プロセスを監査したい場合 メモリ内ストレージでは、お手上げです。プロセスが停止した瞬間に、すべてが消えてしまいます。各ワーカーは独自の分離された状態を維持します。再開、リプレイ、または何が起こったかを確認する方法はありません。 DynamoDBSaver の紹介 langgraph-checkpoint-aws ライブラリは、AWS 専用に構築された永続化レイヤーを提供します。 DynamoDBSaver は、軽量なチェックポイントメタデータを DynamoDB に保存し、大きなペイロードには Amazon S3 を使用します。 仕組みは次のとおりです: 小さなチェックポイント (< 350 KB): thread_id 、 checkpoint_id 、タイムスタンプ、状態などのメタデータを含むシリアル化されたアイテムとして DynamoDB に直接保存されます 大きなチェックポイント (≥ 350 KB): 状態は S3 にアップロードされ、DynamoDB は S3 オブジェクトへの参照ポインタを保存します 取得 : 再開時、セーバーは DynamoDB からメタデータを取得し、S3 から大きなペイロードを透過的にロードします この設計により、DynamoDB のアイテムサイズ制限に達することなく、小さな状態と大きな状態の両方を効率的に処理しながら、耐久性とスケーラビリティを提供します。 DynamoDBSaver には、コストとデータライフサイクルの管理に役立つ組み込み機能が含まれています: Time-to-Live ( ttl_seconds ) により、指定された間隔でチェックポイントの自動有効期限が有効になります。古いスレッドの状態は手動介入なしでクリーンアップされ、一時的なワークフロー、テスト環境、または特定の期間を超えた履歴状態に価値がないアプリケーションに最適です。 圧縮 ( enable_checkpoint_compression ) は、状態データをシリアル化および圧縮することで、保存前にチェックポイントのサイズを削減し、取得時に完全な状態の忠実性を維持しながら、DynamoDB の書き込みコストと S3 ストレージコストの両方を削減します。 これらの機能を組み合わせることで、永続化レイヤーの運用コストとストレージフットプリントをきめ細かく制御でき、アプリケーションのスケールに応じて耐久性要件と予算制約のバランスを取ることができます。 はじめに 実行間でエージェントの状態を永続化し、履歴チェックポイントを取得する方法を示す実用的な例を構築しましょう。 前提条件 開始する前に、必要な AWS リソースをセットアップする必要があります: DynamoDB テーブル : DynamoDBSaver は、チェックポイントメタデータを保存するためのテーブルが必要です。テーブルには、PK (文字列) という名前のパーティションキーと SK (文字列) という名前のソートキーが必要です。 S3 バケット (オプション) : チェックポイントが 350 KB を超える可能性がある場合は、大きなペイロードストレージ用の S3 バケットを提供します。セーバーは、オーバーサイズの状態を自動的に S3 にルーティングし、DynamoDB に参照を保存します。 AWS Cloud Development Kit (AWS CDK) を使用して、これらのリソースを定義できます: const table = new dynamodb.Table(this, 'CheckpointTable', { tableName: 'my_langgraph_checkpoints_table', partitionKey: { name: 'PK', type: dynamodb.AttributeType.STRING }, sortKey: { name: 'SK', type: dynamodb.AttributeType.STRING }, timeToLiveAttribute: 'ttl', removalPolicy: cdk.RemovalPolicy.DESTROY, }); const bucket = new s3.Bucket(this, 'CheckpointBucket', { bucketName: 'amzn-s3-demo-bucket', encryption: s3.BucketEncryption.S3_MANAGED, blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, removalPolicy: cdk.RemovalPolicy.DESTROY }); アプリケーションが DynamoDBSaver を LangGraph チェックポイントストレージとして使用するには、次の AWS Identity and Access Management (AWS IAM) 権限が必要です: DynamoDB テーブルアクセス: dynamodb:GetItem – 個別のチェックポイントを取得 dynamodb:PutItem – 新しいチェックポイントを保存 dynamodb:Query – スレッド ID でチェックポイントを検索 dynamodb:BatchGetItem – 複数のチェックポイントを効率的に取得 dynamodb:BatchWriteItem – 単一の操作で複数のチェックポイントを保存 S3 オブジェクト操作 (350KB を超えるチェックポイントの場合): s3:PutObject – チェックポイントデータをアップロード s3:GetObject – チェックポイントデータを取得 s3:DeleteObject – 期限切れのチェックポイントを削除 s3:PutObjectTagging – ライフサイクル管理のためにオブジェクトにタグを付ける S3 バケット設定: s3:GetBucketLifecycleConfiguration – ライフサイクルルールを読み取る s3:PutBucketLifecycleConfiguration – 自動データ有効期限を設定 インストール pip を使用して LangGraph と AWS チェックポイントストレージライブラリをインストールします: pip install langgraph langgraph-checkpoint-aws 基本設定 大きなチェックポイント用のオプションの S3 バケットとテーブルを使用して、DynamoDB チェックポイントセーバーを設定します: from langgraph.graph import StateGraph, END from langgraph_checkpoint_aws import DynamoDBSaver from typing import TypedDict, Annotatedimport operator # 状態を定義 class State(TypedDict): foo: str bar: Annotated[list[str], add] # DynamoDB 永続性を設定 checkpointer = DynamoDBSaver( table_name="my_langgraph_checkpoints_table", region_name="us-east-1", ttl_seconds=86400 * 30, # 30 日 enable_checkpoint_compression=True, s3_offload_config={ "bucket_name": "amzn-s3-demo-bucket", } ) ワークフローの構築 グラフを作成し、チェックポインタでコンパイルして、呼び出し間で永続的な状態を有効にします: # セッション用の thread_id THREAD_ID = "99" workflow = StateGraph(State) workflow.add_node(node_a) workflow.add_node(node_b) workflow.add_edge(START, "node_a") workflow.add_edge("node_a", "node_b") workflow.add_edge("node_b", END) graph = workflow.compile(checkpointer=checkpointer) config: RunnableConfig = {"configurable": {"thread_id": THREAD_ID}} graph.invoke({"foo": "", "bar": []}, config) 状態の取得 現在の状態を取得するか、タイムトラベルデバッグのために以前のチェックポイントにアクセスします: # 最新の状態スナップショットを取得 config = {"configurable": {"thread_id": THREAD_ID}} latest_checkpoint = graph.get_state(config) print(latest_checkpoint) # 特定の checkpoint_id の状態スナップショットを取得 checkpoint_id = latest_checkpoint.config.get("configurable", {}).get("checkpoint_id") config = {"configurable": {"thread_id": THREAD_ID, "checkpoint_id": checkpoint_id}} specific_checkpoint = graph.get_state(config) print(specific_checkpoint) 実際のユースケース 1. ヒューマン・イン・ザ・ループレビュー 機密性の高い操作 (金融取引、法的文書、医療アドバイス) の場合、人間の監視のためにワークフローを一時停止できます: # エージェントが応答を生成 workflow.invoke({"query": "Approve my loan"}, config) # 人間が別のプロセス/UI でレビュー # チェックポイントは DynamoDB に安全に保存される # 承認後、再開 workflow.invoke({"approved": True}, config) 2. 障害回復 本番システムでは、障害が発生します。ネットワークの中断、API のタイムアウト、または一時的なエラーにより、実行が途中で停止する可能性があります。 メモリ内チェックポイントでは、進行状況が失われます。 DynamoDBSaver を使用すると、ワークフローは最後に成功したチェックポイントをクエリし、そこから再開できます。これにより、再計算が削減され、回復が高速化され、信頼性が向上します。 try: workflow.invoke({"input": "complex query"}, config) except Exception as e: # エラーをログに記録し、運用チームに警告 pass # 後で、最後に成功したチェックポイントから再試行 # 完了したステップを再実行する必要はない workflow.invoke({}, config) 3. 長時間実行される会話 一部のワークフローは数時間または数日にわたります。DynamoDB の耐久性により、会話が確実に永続化されます: # 1 日目: 顧客が問い合わせを開始 workflow.invoke({"messages": ["I need help"]}, config) # 2 日目: 顧客がさらに情報を提供 workflow.invoke({"messages": ["Here's my account number"]}, config) # 3 日目: エージェントがタスクを完了 workflow.invoke({"action": "resolve"}, config) プロトタイプから本番環境への移行は、チェックポインタを変更するだけで簡単です。 MemorySaver を DynamoDBSaver に置き換えて、永続的でスケーラブルな状態管理を実現します: クリーンアップ 継続的な料金の発生を避けるために、作成したリソースを削除します: AWS CDK を使用してデプロイした場合は、次のコマンドを実行します: cdk destroy CLI を使用した場合は、次のコマンドを実行します: DynamoDB テーブルを削除: aws dynamodb delete-table --table-name my_langgraph_checkpoints_table Amazon S3 バケットを空にして削除: aws s3 rm s3://amzn-s3-demo-bucket --recursive aws s3 rb s3://amzn-s3-demo-bucket まとめ LangGraph を使用すると、インテリジェントでステートフルなエージェントを簡単に構築できます。 DynamoDBSaver により、本番環境で安全に実行できます。 DynamoDBSaver を LangGraph アプリケーションに統合することで、耐久性、スケーラビリティ、および特定の時点から複雑なワークフローを再開する能力を得ることができます。人間の監視を伴うシステムを構築し、長時間実行されるセッションを維持し、中断から適切に回復できます。 今すぐ始めましょう プロトタイピング中はメモリ内チェックポイントから始めてください。本番環境に移行する準備ができたら、 DynamoDBSaver に切り替えて、エージェントが記憶し、回復し、自信を持ってスケールできるようにします。 pip install langgraph-checkpoint-aws でライブラリをインストールします。 利用可能な設定オプションを確認するには、 langgraph-checkpoint-aws ドキュメント で DynamoDBSaver の詳細をご覧ください。 本番ワークロードの場合は、 Amazon Bedrock AgentCore Runtime を使用して LangGraph エージェントをホストすることを検討してください。AgentCore は、スケーリング、モニタリング、インフラストラクチャ管理を処理するフルマネージドランタイム環境を提供し、AWS が運用の複雑さを管理する間、エージェントロジックの構築に集中できます。 著者について Lee Hannigan Lee は、アイルランドのドニゴールを拠点とする Sr. DynamoDB Database Engineer です。彼は、ビッグデータと分析技術の強固な基盤を持つ、分散システムにおける豊富な専門知識をもたらします。彼の役割では、Lee は DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に焦点を当てながら、顧客と社内チームがその機能を最大限に活用できるよう支援しています。

2026 年 1 月 20 日、 Amazon Elastic Compute Cloud (Amazon EC2) G7e インスタンスの一般提供が発表されました。G7e インスタンスは生成 AI 推論ワークロードにコスト効率の高いパフォーマンスを提供し、グラフィックワークロードでは最も高いパフォーマンスを実現します。 G7e インスタンスは NVIDIA RTX PRO 6000 Blackwell Server Edition GPU によって高速化されており、空間コンピューティングや科学コンピューティングのワークロードなど、さまざまな GPU 対応ワークロードに適しています。G7e インスタンスは、 G6e インスタンス よりも最大 2.3 倍優れた推論パフォーマンスを提供します。 以前のインスタンスからの改善点は以下のとおりです。 NVIDIA RTX PRO 6000 Blackwell GPU – NVIDIA RTX PRO 6000 Blackwell Server Edition GPU は、G6e インスタンスと比較して 2 倍の GPU メモリと 1.85 倍の GPU メモリ帯域幅を提供します。G7e インスタンスが提供する大容量の GPU メモリを使用することにより、単一の GPU で最大 70B パラメータの中規模モデルを FP8 の精度で実行できます。 NVIDIA GPUDirect P2P – 単一 GPU のメモリでは対応し切れない大きさのモデルについては、複数の GPU にモデルまたは計算を分割することができます。G7e インスタンスは、PCIe インターコネクト経由での GPU 間直接通信を可能にする NVIDIA GPUDirect P2P をサポートしているため、マルチ GPU ワークロードのレイテンシーが低減します。これらのインスタンスは、同一の PCIe スイッチ上にある GPU に最も低いピアツーピアレイテンシーを提供します。さらに、G7e インスタンスは G6e インスタンスに搭載された L40s GPU よりも最大 4 倍広い GPU 間帯域幅を提供するため、マルチ GPU ワークロードのパフォーマンスが向上します。これらの改善により、単一のノード内で最大 768 GB の GPU メモリを提供する複数の GPU で大規模モデルの推論を実行できるようになります。 ネットワーク – G7e インスタンスは G6e インスタンスより 4 倍広いネットワーク帯域幅を提供するため、小規模のマルチノードワークロードでの使用が可能です。また、マルチ GPU G7e インスタンスは Elastic Fabric Adapter (EFA) 経由で NVIDIA GPUDirect Remote Direct Memory Access (RDMA) をサポートすることから、マルチノードワークロードのリモート GPU 間通信のレイテンシーが低減します。これらのインスタンスサイズは Amazon FSx for Lustre での NVIDIA GPUDirectStorage の使用もサポートしており、インスタンスへのスループットが G6e インスタンスよりも最大 1.2 Tbps 高くなるため、モデルをすばやくロードできます。 EC2 G7e の仕様 G7e インスタンスには、最大 768 GB の総 GPU メモリ (GPU あたり 96 GB のメモリ) を提供する最大 8 個の NVIDIA RTX PRO 6000 Blackwell Server Edition GPU と、Intel Emerald Rapids プロセッサが搭載されています。また、最大 192 個の vCPU、最大 1,600 Gbps のネットワーク帯域幅、最大 2,048 GiB のシステムメモリ、最大 15.2 TB のローカル NVMe SSD ストレージもサポートしています。 仕様は以下のとおりです。 インスタンス名 GPU 数 GPU メモリ (GB) vCPU 数 メモリ (GiB) ストレージ (TB) EBS 帯域幅 (Gbps) ネットワーク帯域幅 (Gbps) g7e.2xlarge 1 96 8 64 1.9 x 1 最大 5 50 g7e.4xlarge 1 96 16 128 1.9 x 1 8 50 g7e.8xlarge 1 96 32 256 1.9 x 1 16 100 g7e.12xlarge 2 192 48 512 3.8 x 1 25 400 g7e.24xlarge 4 384 96 1,024 3.8 x 2 50 800 g7e.48xlarge 8 768 192 2,048 3.8 x 4 100 1,600 G7e インスタンスの使用開始には、機械学習ワークロードに AWS Deep Learning AMI (DLAMI) を使用できます。インスタンスの実行には、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用できます。マネージド型のエクスペリエンスを希望する場合は、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) で G7e インスタンスを使用できます。 Amazon SageMaker AI のサポートも近日提供予定です。 今すぐご利用いただけます Amazon EC2 G7e インスタンスは、2026 年 1 月 20 日から米国東部 (バージニア北部) と米国東部 (オハイオ) の各 AWS リージョン でご利用いただけます。リージョンの提供状況と今後のロードマップについては、 AWS Capabilities by Region の [CloudFormation リソース] タブでインスタンスタイプを検索してください。 G7e インスタンスは、 オンデマンドインスタンス 、 Savings Plan 、 スポットインスタンス として購入できます。G7e インスタンスは、 ハードウェア専有インスタンス および 専有ホスト での利用も可能です。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で G7e インスタンスをお試しください。詳細については、 Amazon EC2 G7e instances ページ をご覧ください。フィードバックもお待ちしています。フィードバックは AWS re:Post for EC2 に送信するか、通常の AWS サポート連絡先経由でお寄せください。 – Channy 原文は こちら です。

デジタル庁は2025年5月27日、『行政の進化と革新のための生成AIの調達・利活用に係るガイドライン』（政府ガイドライン）を公開しました。このガイドラインは、政府機関による生成AIの安全かつ効果的な活用方法を包括的に示しています。 AWS は、政府機関の調達担当者とパートナー企業向けに、政府ガイドラインの調達チェックシートの各要件に対する回答例を提供します。この回答例は、Amazon Bedrock を活用したオープンソースアプリケーション『 Generative AI Use Cases（GenU） 』を用いた 生成AIアプリケーション に対応し、政府機関の調達プロセスとパートナー企業の提案書作成を支援します。 １．政府ガイドラインの概要 ・政府ガイドライン策定の背景 政府における 生成AI の活用は、行政サービスの効率化や質の向上に大きな可能性をもたらします。一方で、情報漏えいや不適切な出力などのリスクも存在するため、適切なガバナンスとリスク管理が不可欠です。今回の政府ガイドラインは、 生成AI の利活用促進とリスク管理を両立させることを目的として策定されました。 ・調達チェックシートとは 政府ガイドラインの中核となるのが「調達チェックシート」です。これは、政府機関が 生成AIシステム を調達する際に、事業者に対して確認すべき要件を体系化したものです。チェックシートには、データプライバシー保護、有害情報の出力制御、セキュリティ確保など、政府機関が重視する技術的・運用的要件が項目別に整理されており、調達担当者が提案書を評価する際の統一的な基準として活用されます。また、事業者にとっては、政府が求める技術要件を明確に把握し、適切な提案を行うための指針となります。 ・主要なポイント [対象範囲] • 対象システム：テキスト生成AIを構成要素とする政府情報システム • 適用開始：2025年5月（※全面適用は、令和８年度以降に調達・利活用を行う生成AI システムから） • 対象外：特定秘密や安全保障等の機微情報を扱うシステム [ガバナンス体制の構築] • AI統括責任者（CAIO）：各府省庁にAI統括責任者を新設 • 先進的生成AIアドバイザリーボード：各府省庁への助言・相談対応 • AI相談窓口：デジタル庁による技術的支援 [リスク管理の仕組み] • 高リスク判定：4つの観点（利用者範囲、業務性格、機密情報、出力判断）でリスク評価 • 調達チェックシート：調達・契約時の要件確認を体系化 • インシデント対応：生成AI特有のリスクケースへの対応体制 ２． AWS のサンプル回答 –  GenU を活用した調達チェックシート要件対応例 ・ GenU の特徴 AWS では、政府機関の生成AI活用を支援するため、 GenU という Amazon Bedrock を活用したオープンソースのアプリケーション実装を提供しています。 GenU は最短10分でデプロイが完了する迅速な導入が可能で、セキュリティ・統制機能を標準搭載した安全性重視の設計となっています。また、チャット、RAG、文書生成、翻訳など多様なユースケースに対応しており、使った分だけの従量課金制によりスモールスタートでコスト効率よく始めることができます。 ・ AWS サンプル回答の活用方法 政府ガイドラインでは、政府機関の生成AIシステムの調達時に「調達チェックシート」の活用が求められています。 AWS では、このチェックシートの各項目に対して、 GenUを活用した場合の具体的な対応例をサンプル回答 として提供し、政府機関とパートナー企業の皆様を支援いたします。サンプル回答の見方については 補足資料 をご参照ください。 [政府機関職員の皆様へ] ・調達・契約時での活用 Amazon Bedrock を活用した応札企業の技術提案と AWSサンプル回答 の対応例を照合し、データプライバシー保護や有害情報制御などの重要要件への技術的実現可能性を客観的に評価 [パートナー企業の皆様へ] ・提案書作成での活用 調達チェックシート要件に対する Amazon Bedrock での技術的対応方針を検討し、適切な技術構成と実装方法を提案書に記載する際の参考資料として活用 回答例は こちら からダウンロードできます。　回答例の見方については 補足資料 をご参照ください。 ３．まとめ 政府ガイドラインは、安全で効果的な 生成AI 活用のための重要な指針です。 AWS のサンプル回答は、この政府ガイドラインで示された調達チェックシート要件に対する AWS としての技術的考え方と対応例をまとめた参考資料として、政府機関の調達担当者とパートナー企業の提案書作成者にご活用いただけます。 参考情報： • Generative AI Use Cases JP (GenU) • Amazon Bedrock • 公共機関における生成 AI の活用案 お問い合わせ 政府機関向けの 生成AI 導入に関するご相談は、 AWSパブリックセクター までお気軽にお問い合わせください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料は政府ガイドラインの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 著者： Atsushi Kimura (AWS Japan, Public Sector, Proposal Manager) Keiji Toyohara (AWS Japan, Public Sector, Senior Manager, Solutions Architect)

本ブログは 2025 年 11 月 12 日に公開された AWS Blog “ Amazon Elastic Kubernetes Service gets independent affirmation of its zero operator access design ” を翻訳したものです。 本日 (2025 年 11 月 12 日)、 Amazon Elastic Kubernetes Service (Amazon EKS) のゼロオペレーターアクセス体制について、独立した第三者機関により裏付けられたことを発表しました。 Amazon Web Services (AWS) では、 セキュリティは最優先事項 です。この信念のもと、規制業界のお客様や最も厳格なセキュリティ要件を持つお客様が求めるデータプライバシーを実現できるよう、マネージド Kubernetes サービス向けの運用アーキテクチャを設計・実装しています。これにより、重要かつ機密性の高いワークロードを安心して AWS 上で実行できます。AWS のサービスは、Amazon EKS の管理において、AWS の従業員が顧客コンテンツを読み取り、コピー、抽出、変更、またはその他の方法でアクセスする技術的な経路を持たないように設計されています。 AWS では、信頼を獲得することは単なる目標ではなく、あらゆる意思決定の指針となる リーダーシッププリンシプル の 1 つです。お客様が AWS を選ぶのは、ワークロードの構築、移行、実行、およびデータの保存に最も安全なグローバルクラウドインフラストラクチャを提供すると信頼しているからです。この信頼をさらに高めるため、AWS は AWS Trust Center を立ち上げ、AWS クラウドでお客様の資産をどのように保護しているかについての情報をより入手しやすくしました。この立ち上げに合わせて、業界をリードするデータプライバシー体制を示すための オペレーターアクセス へのアプローチと、AWS クラウドにおける AWS 責任共有モデル での AWS の責任をどのように果たしているかについて、Trust Center で説明しています。 AWS のコアシステムとサービスの多くは、ゼロオペレーターアクセスで設計されています。これは、少なくともサービスの管理において顧客コンテンツへいかなる手段でもアクセスできないよう、アーキテクチャとモデルが運用されることを意味します。これらのシステムとサービスは、自動化とセキュアな API を通じて管理されており、過失であれ故意であれ顧客コンテンツへのアクセスを防いでいます。このようなサービスには、 AWS Key Management Service (AWS KMS) 、 Amazon Elastic Compute Cloud (Amazon EC2) （ AWS Nitro System を通じて）、 AWS Lambda 、 Amazon EKS 、 AWS Wickr があります。 AWS は AWSのデジタル主権に関するお客様との約束 において、AWS サービスがどのように設計・運用されているか、特に顧客コンテンツの取り扱いについて、お客様により高い透明性と保証を提供することを約束しました。この透明性向上の一環として、英国を拠点とする大手サイバーセキュリティコンサルティング会社である NCC Group に、Amazon EKS のアーキテクチャと、お客様に提供しているセキュリティ保証について独立したアーキテクチャレビューを依頼しました。NCC Group はレポートを発行し、AWS のセキュリティに関する主張を裏付けました。レポートには次のように記載されています。 “NCC Group found no architectural gaps that would directly compromise the security claims asserted by AWS.” (NCC Group は、AWS のセキュリティに関する主張を損なうようなアーキテクチャ上のギャップを検出しませんでした。) 具体的には、このレポートは Amazon EKS のセキュリティポスチャに関する以下の内容を検証しています。 AWS の従業員がマネージド Kubernetes コントロールプレーンインスタンスにインタラクティブにアクセスする技術的手段は存在しない AWS の従業員がマネージド Kubernetes コントロールプレーンインスタンス内の顧客コンテンツを読み取り、コピー、抽出、変更、またはその他の方法でアクセスする技術的手段は存在しない AWS の従業員が Kubernetes コントロールプレーンインスタンスを管理するために使用する管理 API は、Kubernetes データプレーン内の顧客コンテンツにアクセスできない Kubernetes コントロールプレーンを管理するために使用される管理 API への変更には、常に複数人によるレビューと承認が必要 AWS の従業員が etcd データベースのバックアップストレージ内の顧客コンテンツにアクセスする技術的手段は存在しない。etcd データベースのデータ保護に使用される平文の暗号化キーには、AWS の従業員は誰もアクセスできない AWS の従業員は、マネージド Kubernetes コントロールプレーンまたは Kubernetes データプレーン内の顧客コンテンツにアクセスすることなく、管理 API を使用してのみ Kubernetes クラスター API エンドポイントとやり取りできる。AWS の従業員が Kubernetes クラスター API エンドポイントで実行したすべてのアクションは、お客様が有効にした監査ログを通じてお客様に表示される 管理 API へのアクセスには常に認証と認可が必要。管理 API によって実行されるすべての運用アクションはログに記録され、監査される マネージド Kubernetes コントロールプレーンインスタンスは、信頼されたパイプラインによってデプロイされたテスト済みのソフトウェアのみを実行できる。AWS の従業員は、このパイプライン以外でマネージド Kubernetes コントロールプレーンインスタンスにソフトウェアをデプロイすることはできない NCC Group の詳細なレポートでは、これらの各主張について、NCC Group が主張を評価するために使用した範囲、方法論、手順を含めて検証しています。 Amazon EKS がゼロオペレーターアクセスを実現する仕組み AWS は常に最小権限モデルを採用し、 顧客コンテンツ を処理するシステムにアクセスできる人員を最小限に抑えています。各 AWS 従業員が割り当てられたタスクや責任を遂行するために必要な最小限のシステムにのみアクセスできるよう製品とサービスを設計し、そのアクセスも必要な時だけに制限しています。顧客データを保存または処理するシステムへのアクセスはすべてログに記録され、異常がないか監視・監査されます。AWS は、AWS の従業員が不正な目的で顧客コンテンツにアクセスすることを防ぐようにすべてのシステムを設計しています。これは AWS カスタマーアグリーメント と AWS サービス条件 で約束しています。AWS の運用において、お客様への通知と許可なしに顧客コンテンツにアクセス、コピー、または移動することは決してありません。 AWS の運用アーキテクチャでは、コンフィデンシャルコンピューティングを実現する AWS Nitro System ベースのインスタンスのみを使用して、マネージド Kubernetes コントロールプレーンを運用しています。 AWS は、限定的な操作のみ可能な管理 API を使用してアクセスを厳密に制御し、オペレーターが Kubernetes コントロールプレーンインスタンスへの直接アクセスやインタラクティブアクセスなしに、トラブルシューティングや診断のための許可リストに登録されたアクションを正確に実行できるようにしています。これらの API は、Kubernetes コントロールプレーンまたはお客様の Kubernetes データプレーン内の顧客コンテンツにアクセスする技術的手段を持たないよう最初から設計されています。 AWS の標準的な変更管理プロセスでは、これらの管理 API 自体の変更や、サービス運用のガードレールとなる関連ポリシーの変更には、複数人によるレビューと承認プロセスが組み込まれています。このモデルは、お客様が選択した Kubernetes データプレーンの起動モードに関係なく、すべての Amazon EKS クラスターで一貫して実装されています。 さらに、これらの限定的な操作のみ可能な管理 API とのすべてのやり取りはログを生成し、最小権限の原則に従って必須の認証と認可が行われます。クラスターの監査ログを有効にすることで、お客様は AWS の従業員がクラスターの API エンドポイントで実行したすべてのアクションを確認できます。 デフォルトで、AWS は すべての Kubernetes API データをエンベロープ暗号化 による保存時暗号化を適用して etcd データベースに格納し、さらに etcd データベースのバックアップストレージを保護することで、クラスタースナップショット内の顧客コンテンツへのアクセスを防ぐ多層的な保護を実現しています。また、AWS のシステムは、 etcd データベースとそのバックアップのデータを保護するために使用される平文の暗号化キーに AWS の従業員が誰もアクセスできないように設計されています。 これらのオペレーターアクセス制御は、ワーカーノードの実行方法に関係なく、Amazon EKS コントロールプレーンに一律に適用されます。セルフマネージド、 Amazon EKS Auto Mode 、 AWS Fargate のいずれでも同様です。 AWS 責任共有モデル に記載されているとおり、Amazon EKS Auto Mode と Fargate 起動モードを除き、Kubernetes ワーカーノードの設定のセキュリティ確保はお客様の責任となります。Amazon EKS における AWS マネージドデータプレーン起動モードのセキュリティの詳細については、 詳細情報 セクションの関連リンクを参照してください。 まとめ Amazon EKS は、AWS の従業員が Amazon EKS 内の顧客コンテンツを読み取り、コピー、変更、またはその他の方法でアクセスできないように設計・構築されています。AWS Nitro System ベースのコンフィデンシャルコンピューティング、限定的な操作のみ可能な管理 API、複数人による変更承認プロセス、エンドツーエンドの暗号化を使用することで、AWS はオペレーターアクセスの技術的経路を排除しています。NCC Group による独立した検証では、これらの保証を損なうようなアーキテクチャ上のギャップは検出されませんでした。Amazon EKS は最も厳格な規制要件やデジタル主権要件を満たすゼロオペレーターアクセスモデルを提供し、組織が最も機密性の高いミッションクリティカルなワークロードを AWS 上で安心して実行できるようにしています。 詳細情報 NCC Group レポート Amazon EKS ドキュメント Amazon EKS Auto Mode のセキュリティ概要 AWS Fargate のセキュリティ概要 AWSのデジタル主権に関するお客様との約束 AWS の継続的デリバリーの実践と安全なパイプラインの自動化 この記事に関するご質問がある場合は、 AWS サポート にお問い合わせください。 Micah Hausler Micah は AWS のプリンシパルソフトウェアエンジニアで、Kubernetes とコンテナセキュリティに注力しています。 Lukonde Mwila Lukonde は AWS の Amazon EKS チームのシニアプロダクトマネージャーで、ネットワーキング、レジリエンス、運用セキュリティに注力しています。アプリケーション開発、ソリューションアーキテクチャ、クラウドエンジニアリング、DevOps ワークフローにおいて長年の経験があります。 Manu Mazarredo Manu はオランダのアムステルダムを拠点とする AWS のプログラムマネージャーです。AWS リージョンと業界全体にわたるコンプライアンスおよびセキュリティ保証の監査とエンゲージメントをリードしています。過去 20 年間、情報システム監査、倫理的ハッキング、プロジェクト管理、品質保証、ベンダー管理に従事してきました。 Tari Dongo Tari はロンドンを拠点とする AWS のセキュリティ保証プログラムマネージャーです。EMEA 全体のサードパーティおよび顧客監査、証明、認証、評価を担当しています。以前は、Big 4 (四大会計事務所) および金融サービス業界でセキュリティ保証とテクノロジーリスクに従事していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 12 月 23 日に公開された AWS Blog “ Exploring the zero operator access design of Mantle ” を翻訳したものです。 Amazon では、改善点について率直かつオープンに議論する文化があります。この文化があるからこそ、お客様への価値提供の基準を継続的に引き上げるための投資とイノベーションに注力し続けることができています。2025 年 12 月初め、 Amazon Bedrock の次世代推論エンジンである Mantle において、このプロセスが実際に機能している例を共有する機会がありました。生成 AI の推論処理やファインチューニングのワークロードが進化し続ける中、お客様に最適化された方法で推論を提供する方法も進化させる必要があり、それが Mantle の開発につながりました。 次世代推論エンジンのアーキテクチャを再構築するにあたり、AWS はセキュリティの基準を引き上げることを最優先事項としました。AWS はお客様と同様に、セキュリティとデータプライバシーに一切妥協しない姿勢で取り組んでいます。これは当初からビジネスの中心であり、Amazon Bedrock においても初期段階から徹底してきました。生成 AI の推論ワークロードは、お客様がデータの潜在的な価値を引き出すための、かつてない可能性をもたらします。しかし、その可能性を活かすには、最も機密性の高いデータを処理し、最も重要なシステムと連携する生成 AI システムを構築する際に、セキュリティ、プライバシー、コンプライアンスの最高基準を確保する必要があることを、AWS は当初から理解していました。 前提として、Amazon Bedrock は AWS 全体に適用されているものと同じ運用セキュリティ基準で設計されています。AWS は常に最小権限モデルを運用に採用しており、各 AWS オペレーターは割り当てられたタスクを実行するために必要な最小限のシステムにのみアクセスでき、その権限はタスクの実行に必要な期間のみに限定されています。顧客データやメタデータを格納または処理するシステムへのアクセスはすべてログに記録され、異常がないか監視され、監査されます。AWS はこれらのコントロールを無効化またはバイパスするあらゆる行為を防止しています。さらに、Amazon Bedrock ではお客様のデータがモデルのトレーニングに使用されることはありません。モデルプロバイダーは顧客データにアクセスする手段を持っていません。推論処理は、AWS が管理する Amazon Bedrock のサービスアカウント内でのみ行われ、モデルプロバイダーはこのアカウントにアクセスできないためです。この強力なセキュリティポスチャにより、お客様は安心して機密データを生成 AI アプリケーションで活用できるようになっています。 Mantle では、AWS はさらに高い基準を設けました。 AWS Nitro System のアプローチに従い、Mantle をゼロから設計してゼロオペレーターアクセス (ZOA) を実現しました。これは、AWS オペレーターが顧客データにアクセスするための技術的手段を設計の段階から徹底して排除したものです。代わりに、システムとサービスは顧客データを保護する自動化とセキュアな API を使用して管理されます。Mantle では、AWS オペレーターが基盤となるコンピューティングシステムにサインインしたり、推論プロンプトや生成結果などの顧客データにアクセスしたりする手段はありません。Secure Shell (SSH)、 AWS Systems Manager Session Manager 、シリアルコンソールなどの対話型通信ツールは、Mantle のどこにもインストールされていません。さらに、すべての推論ソフトウェアの更新は、サービスにデプロイされる前に署名と検証が必要であり、承認されたコードのみが Mantle で実行されることを保証しています。 Mantle は、最近リリースされた EC2 インスタンスアテステーション機能 を使用して、顧客データ処理のための堅牢化され、制限された、イミュータブルなコンピューティング環境を構成しています。Mantle でモデルの重みを取り扱い、顧客プロンプトに対する推論処理を担当するサービスは、 Nitro Trusted Platform Module (NitroTPM) から暗号署名されたアテステーション・メジャーメントによる高い保証によってさらに裏付けられています。 お客様が Mantle エンドポイント (例: bedrock-mantle.[regions].api.aws ) を呼び出すと、Amazon Bedrock の Responses API を提供するエンドポイントなど、顧客データ (プロンプト) は TLS を通じてお客様の環境を離れ、ZOA で運用される Mantle サービスまで暗号化されたまま送信されます。フロー全体および Mantle 内で、AWS、お客様、モデルプロバイダーのいずれのオペレーターも顧客データにアクセスできません。 今後の展望 Mantle の ZOA 設計は、お客様のデータのセキュリティとプライバシーに対する AWS の長期的なコミットメントの表れです。だからこそ、AWS のすべてのチームがセキュリティの基準をさらに引き上げるための投資を行うことができています。同時に、NitroTPM アテステーションなど、Amazon 社内で使用している基盤となるコンフィデンシャルコンピューティング機能を、すべてのお客様が Amazon Elastic Compute Cloud (Amazon EC2) で使用できるようにしました。 AWS はここで止まることはありません。お客様のデータのセキュリティを強化するための投資を継続し、これをどのように実現しているかについて、より高い透明性と保証を提供することにコミットしています。 著者について Anthony Liguori は Amazon Bedrock 担当の AWS バイスプレジデント兼ディスティングイッシュドエンジニアであり、Mantle のリードエンジニアです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。