このブログは、第一三共株式会社 スマートリサーチ第二研究所と QSimulate による共著です。 はじめに 第一三共株式会社 (以下、第一三共) では D4 を活用し、DMTA サイクル (Design-Make-Test-Analyze) の中で Structure Based Drug Design (SBDD) 及び親和性予測を通じた創薬効率化を推進している。 創薬研究の高度化に伴い、親和性予測の精度向上はますます重要な課題となっている。Free Energy Perturbation (FEP) の活用に加え、より正確なエネルギー関数の導入が求められており、特に今後複雑化が見込まれる化学モダリティにおいては、従来の FEP では対応が困難であった非古典的相互作用や共有結合系の親和性予測を高い精度で実施できる技術が不可欠である。こうした背景のもと、QSimulate との国内外での面談を通じ、同社が有する量子化学 (QM) を組み込んだ FEP 計算技術 (QM-FEP) を評価した。同社は、創薬研究に求められる実用的なスループットを確保しながら、クラウド環境を活用した計算コストの最適化にも取り組んでいる。計算精度と速度を高い水準で両立する同社の技術は我々のニーズに合致するものと判断した。 QSimulate の紹介、特長 QSimulate は創薬研究を加速するためのシミュレーション技術を開発するボストン発のスタートアップであり、ノースウェスタン大学教授であった CEO 塩崎亨らにより 2018 年に設立された。独自の量子化学計算技術を駆使することで、世界で唯一 QM に基づく FEP を商用プロダクト QUELO として展開している。QUELO は QM 力場と独自の AI 力場を併用することにより、従来の標的に対する高精度・高スループットとともに、金属配位性リガンドのような非古典的相互作用や共有結合系での高精度な結合親和性予測も可能にした。QUELO の機能強化や精度改善を目指して、現在はボストン、バークレー、ベルギー、東京の四拠点を中心とした国際チームで開発を推進している。 QUELO はコストパフォーマンスの優れた Amazon Elastic Compute Cloud (Amazon EC2) G7e や G6e インスタンス上で効率的に動作するように、単精度と倍精度を組み合わせた独自の混合精度アルゴリズムを採用している。従来の量子化学計算と比べて約 1,000 倍の高速化を達成し、タンパク質・リガンド複合体の量子化学計算が 1 スナップショットあたりミリ秒単位で処理可能となった。これまで数ヶ月かかっていたシミュレーション時間を数時間へと短縮、計算コストも 100 〜 1,000 分の 1 に削減することで、QM-FEP による創薬研究を現実的なものにした。 図 1: QUELO プラットフォームの図 QUELO は AWS ParallelCluster 上に展開され、 AWS CloudFormation を使った迅速なデプロイと簡易な運用を実現している。Amazon EC2 のオンデマンドインスタンスとスポットインスタンスを使い分けることで、状況に応じた弾力的な計算リソースの確保が可能である。またデータ基盤には Amazon Relational Database Service (Amazon RDS)、ストレージには Amazon Simple Storage Service (Amazon S3) を採用することで、データの堅牢性とアクセス利便性を確保している。さらに知的財産保護のため、ウェブアプリケーションを保護する AWS WAF など、AWS の豊富なセキュリティ機能を全面に活かした安全な環境を提供している。 図 2: AWS 上に展開された QUELO のアーキテクチャ図。QUELO は AWS ParallelCluster、Amazon EC2、Amazon RDS、 AWS Lambda 、Amazon S3、AWS WAF などの様々な AWS の機能を活用しています。 QSimulate の評価 (既存課題の貢献など) QUELO の技術導入により、従来の課題解決に向けた成果が得られてきている。QM 力場を活用した計算では良好な予測精度が確認され、さらに同社独自の AI 力場を組み合わせることで、計算精度と計算速度の両立が実現されている。 クラウド環境の活用においては、通常時はスポットインスタンス、緊急時はオンデマンドインスタンスを使い分けることで、現場のニーズに応じた柔軟な計算実行が可能であることが確認された。AI 力場の適用では計算時間の短縮を、QM 力場の適用では従来手法では対応が困難であった非古典的相互作用への対応をそれぞれ実現した。 既に複数の創薬プログラム・標的に活用しており、実際のプロジェクトにおいて新規ケモタイプ創出にも貢献した。今後、共有結合系において Warhead の比較が必要な場面での親和性予測についても、技術革新によってさらなる精度の向上と適応範囲拡大を期待している。 まとめ 創薬研究において、化合物候補を迅速に高活性な群へと絞り込むことは、効率化を行う上で必須なプロセスである。QSimulate 技術の活用は、QM 力場による高い予測精度と、 AI 力場およびクラウド環境を組み合わせた計算速度の向上を同時に実現できることが示され、本課題に対する有効な解決策の一つといえる。 今後は、本技術を複数創薬プロジェクトへ適用し、さらに推進していく予定である。計算精度・速度の両立がもたらす恩恵を享受し、創薬サイクルの加速と成功確率の向上に継続的に貢献していきたい。 おわりに 本ブログでご紹介した第一三共株式会社と QSimulate の取り組みや関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について 第一三共株式会社 岡田 晃季 (Akitoshi Okada) スマートリサーチ第二研究所 第三グループ シニアサイエンティスト: 創薬効率化に向けた、計算化学/機械学習による活性/物性予測を担当。「計算とはいつも二手三手先を考えて行うものだ…」と言えるようになりたい。 森友 紋子 (Ayako Moritomo) スマートリサーチ第二研究所 第三グループ プリンシパルサイエンティスト: 計算化学の活用を通じた創薬研究効率化実現を目指しています。仕事においても私生活においても、まず状況を整理したうえで効率を重視して行動するタイプで、息抜きは読書とピアノです。 芹沢 貴之 (Takayuki Serizawa) スマートリサーチ第二研究所 第三グループ長: マルチモダリティインフォマティクスの推進を基軸とする業務変革推進、研究効率化に興味があります。スポーツ観戦が好きですが種目がドッジボールからバレーボールと陸上に代わりました。 QSimulate 塩崎 亨 (Toru Shiozaki) QSimulate CEO: 創薬におけるコンピュータ・シミュレーションの新しいあり方を提案するために QSimulate をボストンで起業。前職ではノースウェスタン大学化学科で研究室を運営。最近庭いじりにはまっています。 井本 翔 (Sho Imoto) QSimulate Japan, Chief Scientist: 計算化学による研究開発加速をできるように、デプロイ支援から技術指導まで包括的なサポートを目指しています。元々は水泳をやっていましたが、最近は陸上進出を果たしマラソンにも熱中しています。 アマゾン ウェブ サービス ジャパン合同会社 中島 丈博 (Takehiro Nakajima) ハイテク & ヘルスケア・ライフサイエンス部 シニアソリューションアーキテクト: ヘルスケア・ライフサイエンスのお客様を中心にクラウド利用の技術支援をしており、ユースケースの紹介やお客様のご要望を具現化するための活動をしています。週末は旅の予定に思いを巡らせています。

プログラマティック広告（※）に携わる DSP（Demand-Side Platform）・SSP（Supply-Side Platform）事業者なら、一度はこのジレンマに直面したことがあるのではないでしょうか。広告枠を提供するパートナーであるパブリッシャーと広告主との接続を増やせば入札機会が広がり、広告主にもパブリッシャーにも価値を届けられる。しかし現実には、接続のたびに発生するネットワークコストとインフラ構築の時間が、その判断にブレーキをかけてきました。DSP 事業者のUNICORN株式会社 と SSP 事業者の株式会社fluct は、AWSの広告テクノロジーワークロード向けマネージドサービスである AWS RTB Fabric を共通基盤として活用することで、この接続コストとスピードのジレンマを乗り越え、広告配信ネットワークの拡大に踏み出しています。両社は概念実証（PoC）を経て既に本番稼働を開始しており、本記事ではその取り組みと成果を説明します。 ※ プログラマティック広告とは、データとアルゴリズムを用いて広告の買い付け・配信を自動で行う手法。 接続コストとスピードのジレンマ プログラマティック広告の入札処理（Real-Time Bidding）では、1秒間に数十万〜数百万件の入札リクエストが DSP・SSP 間を行き交います。より多くのパートナーと接続し、より多くの入札機会を得ることが、広告主にとってもパブリッシャーにとっても価値を生みます。 しかし現実には、接続先を増やすほど以下のジレンマが深刻になります。 コストのジレンマ： 広告枠を提供するパートナーを増やすほどネットワークコストが膨らみ、応札数の拡大が利益を圧迫する。コストを抑えるためにフィルタリングを強化すれば、本来獲得できた広告枠を逃す。 スピードのジレンマ : 新規パートナーとの接続にコロケーション手配やネットワーク構成の調整が必要で、数週間〜数ヶ月を要する。ビジネス判断のスピードに技術が追いつかない。 パフォーマンスの制約 : ミリ秒単位の入札処理を安定的に維持しながら、トラフィックの急増にも対応し続ける必要がある。 ジレンマを解消に導くAWS RTB Fabricとは このような課題に対処するために生まれた広告テクノロジーワークロード向けフルマネージドサービスであるAWS RTB Fabric の主な技術的特長と構成を紹介します。 AWS RTB Fabricは、SSPとDSP間のリアルタイム入札通信を最適化するAWSのフルマネージドネットワークサービスです。SSPが広告枠のビッドリクエストをDSPに送信する際はパブリックインターネットを経由するのが一般的ですが、AWS RTB Fabricは専用プライベートネットワークを提供し、1桁ミリ秒の低レイテンシーでSSP⇔DSP間の入札リクエスト・レスポンスを交換可能にします。また、RTBワークロードは大量のビッドリクエスト/レスポンスを高頻度で交換するため、通常のインターネットエグレス料金が膨大になりがちですが、AWS RTB Fabricの専用ネットワークを経由することでデータ転送コストを大幅に圧縮できます。これにより標準的なクラウドネットワーキングコストと比較して最大80%のコスト削減が可能です。 AWS RTB Fabricを活用することでコストのジレンマとスピードのジレンマを解消できるのではという期待のもとUNICORN社 と fluct社 は、それぞれ DSP 側・SSP 側からこのジレンマに向き合い、2026年3月よりAWS RTB Fabric を活用した広告配信ネットワークの構築PoCに踏み出しました。 UNICORNとfluctが実施したAWS RTB FabricのPoC 今回の取り組みで両社がPoCを行ったのは、両社（SSP⇔DSP間）の通信経路を「パブリックインターネット経由」から「AWS RTB Fabricの専用プライベートネットワーク経由」に切り替えるというアーキテクチャ変更です。 ＜机上検討＞ AWSが公開しているドキュメントでの仕様確認を経て、利用対象とする機能を特定しました。また、マネージドサービスの利用ということで、特にスケーリングに関するサービス仕様の詳細確認や、モニタリング方法の確認、可用性要件をどのように実現できるかの確認・検討を行いました。また、公開されている価格表からコスト試算を実施したところ、コスト削減の見通しが立ったため、実環境への適用開始を決定しました。 ＜段階的なトランザクションの流入開始＞ 実際の環境でAWS RTB Fabricへの通信切り替えを段階的に実施しました。まずはコスト試算結果の妥当性確認のため、両社のSSP/DSP間で行われている通信の10％をAWS RTB Fabric経由に切り替えることから開始しました。 AWS RTB Fabricを実環境に適用したところ、以下のような結果が得られました。 ネットワークコスト 80～86.5% 削減 — 従来のパブリックインターネット経由と比較し、同一トラフィック量に対するデータ転送コストを大幅削減。これはフィルタリング強化による「入札機会の犠牲」ではなく、通信経路の最適化による純粋なコスト削減です。 入札処理の安定性維持 — レイテンシーの改善により、トラフィック急増時にもタイムアウト率を抑制し、応札率を維持できることを確認。 運用可視性の向上 — DSP 単位でのメトリクスとコストをリアルタイムで把握可能に。 このPoC結果を踏まえ、両社間のトランザクションを全面的にAWS RTB Fabricに切り替えることを決定。2026年5月より両社間のトランザクションのすべてをAWS RTB Fabricを用いた通信に切り替え、現在も安定的に運用を続けています。 ～概念図～ PoCでは以下の結果を確認することができました。 ネットワークコスト80%削減 — 従来のパブリックインターネット経由と比較し、同一トラフィック量に対するデータ転送コストを80%削減。これはフィルタリング強化による「入札機会の犠牲」ではなく、通信経路の最適化による純粋なコスト削減です。 入札処理の安定性維持 — レイテンシーの改善により、トラフィック急増時にもタイムアウト率を抑制し、ビッドレート（応札率）を維持できることを確認しました。 また本件について実際に取り組みを実施した両社からは下記のようなコメントを頂いています。 UNICORN株式会社　取締役 璩 暁毅 様 「AWS RTB FabricのPoCを通じて特に可能性を感じているのは、既存の配信基盤へ比較的容易に組み込めるアーキテクチャである点です。導入や接続にかかる負荷を低減できることで、より多くのパートナーが参加しやすいオープンなエコシステムの実現が期待できます。また、コスト効率の改善に加え、UNICORNとSSP間の処理経路が最適化されることで、広告取引におけるレイテンシの短縮も期待しています。これは広告主やメディアにとっての価値向上だけでなく、ページ表示や広告配信の高速化を通じて、ユーザー体験のさらなる改善にもつながると考えています。今後、こうした取り組みが業界全体の接続性と効率性を高め、オープンインターネットにおけるプログラマティック広告市場のさらなる発展につながることを楽しみにしています。」 株式会社fluct 代表取締役COO 黒田 岳志 様 「ネットワークコストの高騰は、DSPへの接続拡大における大きな課題でした。AWS RTB Fabricの適用によりデータ転送コストを80%削減できたことで、UNICORN様への入札リクエスト数を増加させることが可能となり、パブリッシャーの収益機会の拡大という具体的なビジネス成果に繋がっています。今後もAWSと連携し、配信基盤の強化を通じてパブリッシャーの成長を支援してまいります。」 AWS Japan 常務執行役員技術統括本部長 巨勢 泰宏 は今回の取り組みの成功について、以下のようにコメントしています。 「AWSは、Amazonの広告ビジネスで培った大規模データ処理と低レイテンシー技術の知見を活かし、広告業界のイノベーションを推進してまいりました。AWS RTB Fabricは、DSPとSSPを同一プラットフォーム上で直接接続することで、広告業界が長年抱えてきた大量データ転送と低レイテンシーという課題を解決し、広告の収益性と効果を最大化するサービスです。UNICORN様、fluct様をはじめとするお客様がこのテクノロジーを活用し、新たなイノベーションを生み出すことで、日本の広告業界のさらなる発展につながるものと確信しております。AWSは今後も、広告業界の未来を切り拓くテクノロジーの提供を通じて、業界全体の成長に貢献してまいります。」 UNICORN と fluct の取り組みは、AWS RTB Fabric を活用した広告配信ネットワーク構築の先行事例です。 AWS Japan は、この成果をもとに以下の展開を進めていきます。 ネットワークの拡大 — より多くの DSP・SSP・アドネットワーク事業者への参画呼びかけ ユースケースの深化 — リテールメディア、CTV（コネクテッドTV）など新しい広告領域への展開 技術支援の強化 — 導入を検討する事業者向けの技術ガイダンスと PoC 支援プログラムの提供 広告配信ネットワークへの参画にご関心のある DSP・SSP 事業者の皆様、ぜひお気軽にお問い合わせください。 本ブログに関連するイベント開催について 本ブログ執筆にご協力いただいたUNICORN社とfluct社にもご登壇頂くイベントを下記のとおり開催いたします。AWS RTB Fabric を活用した広告配信ネットワークの輪を広げることに少しでも関心を持たれている方がいらっしゃいましたらぜひご参加ください。 イベント名：AdTech meet up！ 「変わる広告、変わらない価値 ― いまAdTech事業者がAWSに集まる理由」 日時：2026年7月17日（金）16:00-19:00 場所：麻布台ヒルズ森JPタワー 36階 セミナールーム（東京都港区麻布台1-3-1） 対象：プログラマティック広告配信に携わる事業オーナー、エンジニアの方 申し込みWebページ： AdTech meet up「変わる広告、変わらない価値 ― いまアドテク事業者がAWSに集まる理由」 イベント概要： 広告の在り方は変わっても、届けたい付加価値は不変です。ただ、付加価値の届け方が過渡期を迎えています。AIとクラウドが稼ぐ力を引き上げ、そしてコストを大きく押し下げることが容易になったこの変革期に、アドテク事業者の皆様は、何に投資し、何を行い、そして誰と協働すべきでしょうか。 本イベントでは、AIが変えるプログラマティック広告の最前線、AWSのアドテク事業者様向けの最新テクノロジーであるAWS RTB Fabric によるコスト削減と収益拡大の実践、そしてDSP事業者 × SSP事業者によるオープンエコシステム戦略の対談を通じて、その答えを探ります。 また、それらセッションの後にはDSP・SSP事業者同士が直接つながるネットワーキングの場もご用意。同じ課題意識を持つ事業責任者様との交流を通じて、是非とも次の成長の起点を探って頂くことを心から願っております。 アジェンダ： AWS Session① ：AIが変えるプログラマティック広告 スピーカー：アマゾン ウェブ サービス ジャパン合同会社 アド ＆ マーケティング テクノロジーコミュニティ ソリューションアーキテクト　鈴木 康士郎 AWS Session② ：広告コストを収益に変える – AWS RTB Fabric スピーカー：アマゾン ウェブ サービス ジャパン合同会社 アド ＆ マーケティング テクノロジーコミュニティ ソリューションアーキテクト　関藤 寛喜 DSP事業者×SSP事業者による対談 ：アドテク事業者はどこに投資すべきか？—オープンエコシステムが切り拓く次の成長戦略 パネリスト：株式会社fluct　代表取締役COO　黒田 岳志 様 UNICORN株式会社　取締役　璩 暁毅 様 アマゾン ウェブ サービス ジャパン合同会社　プリンシパル事業開発マネージャー　松本 鋼治 本ブログは松原（AdTech Team, Account Executive）・安守（AdTech Team, Account Executive）・久野（Solutions architect）が担当しました

本ブログは 2026 年 4 月 24 日に公開された AWS Blog “ Protecting your secrets from tomorrow’s quantum risks ” を翻訳したものです。 AWS のポスト量子暗号 (PQC) 移行計画 で説明したとおり、 harvest now, decrypt later (今すぐ収集し、後で復号する) 攻撃 (HNDL) のリスクへの対処は、ポスト量子移行計画の重要な部分です。量子耐性のある機密性をサポートするためにワークロードのクライアント側をアップグレードすることは、 PQC 責任共有モデル においてお客様側が担う重要な側面です。PQC アップグレードの計画と実行のタイムラインは、リージョンや業界によって異なり、お客様自身のビジネスリスクプロファイルに依存します。詳細については、AWS の PQC に関するよくある質問 を参照してください。 AWS Secrets Manager は SSL/TLS を使用して AWS リソースと通信し、現在すべての AWS リージョンで TLS 1.2 と 1.3 をサポートしています。この機能をサポートするクライアントに対しては、ハイブリッドポスト量子鍵交換を使用した TLS 1.3 をサポートしています。 ハイブリッドポスト量子 アプローチは、従来の暗号 (X25519 など) とポスト量子アルゴリズム (ML-KEM) を組み合わせて TLS 接続を確立することで、現在の古典的な攻撃と将来の量子コンピュータの脅威の両方からシークレットを保護します。ワークロードが Secrets Manager にどのようにアクセスする場合でも、HNDL によるシークレットへのリスクに対処するために必要なのは、このクライアント側のソフトウェアアップグレードだけです。保管中のシークレットは、 AWS Key Management Service (AWS KMS) が管理するキーを使用して、すでに暗号化されています。適切に実装された対称暗号は量子耐性があると考えられていますが、非対称暗号は量子の脅威に直面しています。詳細については、 AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified をご覧ください。 クライアント側のアップグレードにおける開発者の負担を軽減するため、以下の Secrets Manager クライアントが、Secrets Manager への接続を開始する際にポスト量子 TLS を有効化して優先するようになりました。対象となるのは、 Secrets Manager Agent ( v2.0.0 以降)、 AWS Lambda 拡張機能 (v19 以降)、 Secrets Manager CSI Driver ( v2.0.0 以降) です。SDK ベースのクライアントの場合、ハイブリッドポスト量子鍵交換はサポートされている AWS SDK で利用できます。有効化の要件は、言語、バージョン、オペレーティングシステムによって異なります。お使いの SDK クライアントについては、以下の表を参照してください。 このリリースは、システムをポスト量子暗号に移行し、お客様の移行も容易にするという AWS の継続的な取り組みの一環です。詳細については、 ポスト量子暗号 を参照してください。 クライアントのハイブリッドポスト量子鍵交換の要件 以下の表は、各クライアントの動作をまとめたものです。クライアントがハイブリッドポスト量子鍵交換をサポートするようにアップグレードされると、Secrets Manager のサービスエンドポイントは TLS ハンドシェイク中に自動的にこれを選択します。Secrets Manager API を呼び出す際にワークロードがハイブリッドポスト量子鍵交換を使用し始めるために必要なのは、表に記載されているバージョンへのアップグレードだけです。 クライアント 要件 Secrets Manager Agent TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( v2.0.0 以降 ) AWS Lambda 拡張機能 TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます (バージョン 19 以降) Secrets Manager CSI Driver TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( v2.0.0 以降) AWS SDK for Rust TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( 2025 年 8 月 29 日以降のリリース ) AWS SDK for Go TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( Go v1.24 以降 ) AWS SDK for Node.js TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( Node.js v22.20 および v24.9.0 以降 ) AWS SDK for Kotlin Linux で TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます (v1.5.78 以降) AWS SDK for Python AWS SDK for Python (boto3) は、TLS に OS が提供する OpenSSL を使用します TLS でのハイブリッドポスト量子鍵交換には、 OpenSSL 3.5 以降がインストールされた システムでの実行が必要です AWS SDK for Java v2 AWS SDK for Java v2 では、 postQuantumTlsEnabled を使用して設定する場合に、PQ TLS をサポートする AWS CRT HTTP クライアントが必要です Secrets Manager キャッシュクライアント Secrets Manager キャッシュライブラリは AWS SDK 上に構築されており、その TLS 動作を継承します。Java に関する注意: TLS でのハイブリッドポスト量子鍵交換を有効にするには、 JDBC ドライバーフラグ と Java キャッシュフラグ を設定する必要があります Secrets Manager Agent、Lambda 拡張機能、または CSI Driver を使用している場合は、TLS でのハイブリッドポスト量子鍵交換をデフォルトとして使用するために、記載されているバージョンにアップグレードしてください。表に記載されているバージョンの AWS SDK for Rust、Go、または Node.js を使用しているお客様は、すでにアップグレード済みであり、追加のアクションは必要ありません。SDK が API コールに対してハイブリッドポスト量子鍵交換を選択します。AWS SDK for Python を使用しているお客様の場合、TLS でのハイブリッドポスト量子鍵交換には、ホストシステムに OpenSSL 3.5 以降が存在する必要があります。これを確認して有効化する方法については、 AWS Secrets Manager ドキュメント を参照してください。AWS SDK for Java v2 を使用しているお客様の場合、TLS でのハイブリッドポスト量子鍵交換には AWS CRT HTTP クライアントの使用が必要です。これを有効にするには、CRT クライアントで postQuantumTlsEnabled(true) を設定する必要があります。 クライアントのバージョンが表に記載されている要件を満たした後は、接続が実際にハイブリッドポスト量子鍵交換を使用していることを検証できます。 接続がハイブリッドポスト量子鍵交換を使用していることを検証する方法 ML-KEM を使用したハイブリッドポスト量子鍵交換が Secrets Manager クライアントでデフォルトで有効になったため (前述の表を参照)、ほとんどのお客様にとって、正しい動作の検証やリグレッションの検出のための継続的なモニタリングは不要です。ただし、セキュリティチームやコンプライアンス責任者は、Secrets Manager API コールがハイブリッド鍵交換をネゴシエートしていることを確認したい場合があります。サーバー側では、 AWS CloudTrail を使用して TLS でのハイブリッドポスト量子鍵交換を確認できます。クライアント側では、Wireshark などのユーティリティを使用するか、主要なウェブブラウザに組み込まれた開発者ツールを使用して、TLS ハンドシェイクの詳細を確認できます。 検証は 2 段階のプロセスです。まず、Secrets Manager クライアントを使用してシークレットを取得し、 GetSecretValue API コールを生成します。次に、 AWS CloudTrail で、そのコールがハイブリッドポスト量子鍵交換をネゴシエートしたことを確認します。 Secrets Manager クライアントを使用してシークレットを取得する 以下の例では、Secrets Manager Agent、Lambda 拡張機能、CSI Driver を使用してシークレットを取得する方法を示します。これらはいずれも、 GetSecretValue API を呼び出す際に自動的にハイブリッドポスト量子鍵交換をネゴシエートします。 EC2 インスタンスで Secrets Manager Agent を使用してハイブリッドポスト量子 TLS を検証するには: Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにエージェントをインストールし、シークレットを取得するためのクライアントとして使用します。 AWS Secrets Manager Agent の手順に従います EC2 インスタンスプロファイルが、シークレットを取得するための secretsmanager:GetSecretValue 権限を持っていることを確認します プライベート EC2 インスタンス に接続します EC2 インスタンスにエージェントをインストールします エージェントを使用して シークレットを取得 します curl -H "X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)" localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN> CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します Lambda 拡張機能を使用してハイブリッドポスト量子 TLS を検証するには: AWS パラメータおよび Secrets Manager Lambda 拡張機能を使用して、直接 API コールを介して Secrets Manager からシークレットを取得する Lambda 関数を作成します。 AWS パラメータおよびシークレット Lambda 拡張機能の使用 に従って、Lambda レイヤーと Lambda 関数を作成します 最新の拡張機能バージョンを選択します CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します Amazon EKS で CSI Driver を使用してハイブリッドポスト量子 TLS を検証するには: Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで、 AWS Secrets Store CSI Driver プロバイダーを使用して Secrets Manager からシークレットを取得 し、Kubernetes ポッドで使用します。 インストールされているアドオンのバージョンが 2.0.0 以降であることを確認します eksctl get addon --cluster <CLUSTER-NAME> --name aws-secrets-store-csi-driver-provider シークレットをマウントするポッドを再起動するか、新しいポッドをデプロイして、シークレットの取得をトリガーします CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します CloudTrail を使用してハイブリッドポスト量子鍵交換を確認する CloudTrail ログ には、Secrets Manager API コールの tlsDetails フィールドが含まれています。TLS でのハイブリッドポスト量子鍵交換がアクティブな場合、 tlsDetails の keyExchange フィールドに X25519MLKEM768 が表示されます。各 CloudTrail レコードには、暗号スイートと、利用可能な場合は TLS ハンドシェイク中にネゴシエートされた鍵交換グループを含む tlsDetails フィールドが含まれています。 CloudTrail 用の AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、 CloudTrail イベント履歴 を操作できます。 コンソールを使用して CloudTrail イベントを検索するには: 正しい AWS リージョンにいることを確認します CloudTrail コンソールを開き、[イベント履歴] を選択します [ルックアップ属性] フィルターで、[イベント名] と [GetSecretValue] を選択します 図 1: イベント名で CloudTrail イベント履歴を検索 イベントを選択します 図 2: イベントを選択 ページの [イベントレコード] セクションで出力を表示します 図 3: CloudTrail – GetSecretValue イベント AWS CLI を使用して CloudTrail イベントを検索するには: AWS CLI を使用して、最新のイベントを選択し、出力を確認します。 aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \ --max-results 5 \ --region <YOUR-REGION> \ --query 'Events[0].CloudTrailEvent' \ --output text GetSecretValue API コールの CloudTrail イベントの例: 以下の例では、 userAgent フィールドは、Secrets Manager への接続にクライアントとして使用されたものを反映しています。 注 : userAgent の値は、使用するクライアントによって異なります。 { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89", "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89", "accountId": "111122223333", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE", "accountId": "111122223333", "userName": "YOUR-EC2-INSTANCE-PROFILE" }, "attributes": { "creationDate": "2026-03-27T17:08:37Z", "mfaAuthenticated": "false" }, "ec2RoleDelivery": "2.0" }, "inScopeOf": { "issuerType": "AWS::EC2::Instance", "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89" } }, "eventTime": "2026-03-27T17:12:54Z", "eventSource": "secretsmanager.amazonaws.com", "eventName": "GetSecretValue", "awsRegion": "eu-west-2", "sourceIPAddress": "1.2.3.4", "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0", "requestParameters": { "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret" }, "responseElements": null, "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223", "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73", "readOnly": true, "resources": [ { "accountId": "111122223333", "type": "AWS::SecretsManager::Secret", "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com", "keyExchange": "X25519MLKEM768" } } keyExchange フィールドに X25519MLKEM768 が表示されている場合、TLS でのハイブリッドポスト量子鍵交換がアクティブです。 X25519 などの従来のアルゴリズムが表示されている場合は、クライアントが ML-KEM のサポートを通知していないため、クライアントのバージョンと設定を確認する必要があります。 トラブルシューティング クライアントを更新した後も Secrets Manager API コールが X25519MLKEM768 をネゴシエートしない場合は、この記事の冒頭付近にある クライアントのハイブリッドポスト量子鍵交換の要件 セクションに記載されているとおり、SDK バージョン、OpenSSL バージョン (Python)、ファイアウォールまたはプロキシの設定を確認してください。 次のステップ このリリースは、より広範な移行における 1 ステップです。AWS は、 AWS PQC 移行計画 のワークストリーム 2 の一環として、AWS サービスの HTTPS エンドポイント全体で ML-KEM のサポートを引き続き展開しており、パブリック AWS エンドポイント全体での完全なカバレッジを目指しています。 ML-KEM の標準化前の前身である CRYSTALS-Kyber のサポートは、2026 年に AWS エンドポイント全体で段階的に廃止されます。CRYSTALS-Kyber のサポートのみを通知する古い SDK バージョンを使用しているお客様は、廃止されたアルゴリズムをネゴシエートするのではなく、従来の TLS に適切にフォールバックします。このフォールバックを回避するには、この記事に記載されている SDK バージョンにアップグレードしてください。 PQC 移行の道のりは、転送中のデータの機密性にとどまりません。AWS の PQC への取り組みやお客様側の責任共有に関する最新の動向を把握するには、 AWS ポスト量子暗号 ページをフォローしてください。 まとめ AWS Secrets Manager は、シークレットの保護とコンプライアンスの取り組みのサポートに役立てるため、ML-KEM を使用したハイブリッドポスト量子鍵交換をデフォルトで有効にするようになりました。この更新は、最新のクライアントバージョンを使用しているお客様にとって、コード変更や設定の更新を必要としません。 この記事では、AWS Secrets Manager がハイブリッドポスト量子暗号を使用して TLS 接続を保護する方法、どのクライアントがこの機能をサポートしているか、そして harvest now, decrypt later 攻撃から接続が保護されていることを検証する方法について説明しました。 今回のリリースの恩恵を今すぐ受けるには、以下を実施してください。 Secrets Manager クライアント (Agent、Lambda 拡張機能、または CSI Driver) を利用可能な最新バージョンにアップグレードして、ML-KEM を使用したハイブリッドポスト量子鍵交換を有効にする ワークロードがキャッシュクライアントではなく AWS SDK を使用している場合は、AWS SDK と基盤となる依存関係を、この記事に記載されている最小バージョンにアップグレードする Secrets Manager API コールの CloudTrail tlsDetails の keyExchange フィールドを確認して、TLS でのハイブリッドポスト量子鍵交換がアクティブであることを検証する 企業のファイアウォールやプロキシを経由するネットワークパスを含め、環境内でエンドツーエンドのハイブリッドポスト量子鍵交換 TLS 接続をテストする AWS は引き続きポスト量子暗号のサポートを展開していきます。より広範な移行の取り組みについては、 AWS PQC 移行計画 を参照してください。また、より広範な環境の最新の暗号インベントリを維持して、移行が必要となる従来の公開鍵暗号の他の使用箇所を特定してください。 CISA Quantum-Readiness ガイダンス と AWS PQC 移行計画が、その良い出発点となります。 追加リソース AWS KMS、ACM、Secrets Manager で ML-KEM ポスト量子 TLS をサポート開始 ポスト量子 TLS を Python で実装・検証する方法 P. Stéphanie Mbappe Stéphanie は Amazon Web Services のセキュリティコンサルタントです。お客様のセキュリティの取り組みのあらゆる段階で支援することに喜びを感じています。学習や新しいソリューションの設計、そして自分の知識を他の人と共有することを楽しんでいます。 Tobias Nickl Tobias は Amazon Web Services のセキュリティコンサルタントで、セキュリティアーキテクチャとクラウド変革を専門としています。AWS のお客様と協力して、現在および新たに出現する脅威の両方に対処するセキュリティアーキテクチャを設計および実装しています。その活動を通じて、組織がクラウドの成熟度とともに進化するセキュリティ戦略を構築できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。