本ブログは、株式会社エナリス 星野 友宏 氏、KDDI アジャイル開発センター株式会社 御田 稔 氏、同 山本 直弥 氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 脱炭素に関する規制や情報開示のルールは変化が速く、企業が追うべき情報は増え続けています。今回は、 株式会社エナリス （以下、エナリス）と KDDI アジャイル開発センター株式会社 （以下、KAG）が Amazon Bedrock AgentCore と Strands Agents で構築した「ESG 戦略意思決定プラットフォーム」（以下、ESG ダッシュボード）をご紹介します。ESG 関連のニュースや規制動向を AI エージェントが日次で収集し、エナリスの事業視点で読み解いた記事と、取るべき対応アクションを提示する仕組みで、2026 年 7 月から社内で利用されています。本記事では、担当者の判断を AI の記憶として蓄積し、次回以降の記事に反映する仕組みを中心に、品質とコストを両立させるための設計を紹介します。 背景と課題 エナリスは、需給管理・電力卸・電力小売で培ったノウハウをもとに、PPA や VPP などの脱炭素ソリューションを展開する企業です。その事業は電力に関する制度や脱炭素関連の規制と密接に結びついており、制度の変化は自社サービスの設計や顧客への提案に直結します。一方で、ESG 関連のニュースや規制動向の調査は担当者の手作業に頼っており、情報の網羅性や解釈の深さが個人に左右されていました。 また、ニュースを要約するだけでは、「エナリスとして何をすべきか」を考える工程は人に残ります。そこで、自社への影響と対応アクションまでを AI が提示すること、そして担当者の判断を次回以降の提案に反映できる仕組みにすることを目指しました。 ESG ダッシュボードの概要 ESG ダッシュボードは、次の 3 つの画面で構成されています。 記事一覧 ：日次で自動生成された記事と、URL やキーワードを指定してその場で生成した記事を表示します。各記事には、エナリスの視点で再構築した本文、リスク／機会、対応アドバイス、AI による信頼性評価が表示され、担当者はコメントを登録できます 週次サマリ ：優先度の高い記事を週単位でまとめます。担当者は、提示された対応アクションにエナリスとして取り組むかを、記事ごとに「承認」「保留」「却下」で登録します 意思決定履歴 ：過去の判断と、却下した場合の理由を振り返れます ESG ダッシュボードの記事一覧画面 ESG ダッシュボードの週次サマリ画面 アーキテクチャ システム全体構成図 ESG ダッシュボードは、次の 4 つの経路で構成しています。 リアルタイム記事生成 ：AWS Amplify 上のフロントエンドから、Amazon Cognito の ID トークンを使って AgentCore Runtime を直接呼び出します。Runtime は JWT による呼び出し元の認可 に対応しているため、Amazon API Gateway を挟まずに呼び出せます。生成結果は ストリーミング で逐次表示します 画面表示・データ登録 ：記事一覧の取得や、意思決定・コメントの登録は、API Gateway と AWS Lambda による REST API で処理します 日次の記事生成 ：Amazon EventBridge が毎日起動する Lambda が、Amazon S3 の収集対象 URL リストを読み込み、URL ごとに Runtime を起動します 週次サマリの生成 ：Lambda が Amazon DynamoDB の記事をもとに Amazon Bedrock のモデルを直接呼び出し、サマリを生成します。決まった形式で集約するだけの処理なので、ここではエージェントを使っていません Runtime は起動元に合わせてリアルタイム用と日次用の 2 つがあり、どちらも生成した記事を DynamoDB に直接書き込みます。担当者の意思決定とコメントは、Lambda が DynamoDB と AgentCore Memory の両方に書き込みます。DynamoDB は画面に表示するための記録、AgentCore Memory はエージェントが参照するための記憶、と役割を分けています。 AgentCore Runtime 内部のエージェント構成 Runtime の中は Strands Agents の Agents as Tools パターンで構成しており、オーケストレーターがサブエージェントをツールとして持ち、①→②→③→④ の順に呼び出します。 ① 情報源判定（ Claude Haiku 4.5 ） ：収集対象のサイトを選定します。①の中で呼び出す robots.txt 確認のエージェント（ Claude Sonnet 4.6 ）が、AI エージェント向けの外部 Web 検索 API で利用規約と robots.txt を確認し、取得してよいかを判定します。この検索結果は判定専用とし、生成や評価には使いません ② 記事取得・意味分解（Claude Haiku 4.5） ：ニュース記事（リアルタイムでは最新 2 件、日次では対象日付の記事）を取得し、関連情報を 2 つの経路で集めます。エナリスが自社サイトで公開している「 エナリスジャーナル 」の関連記事は AgentCore Browser 上の独自ツールで都度取得し、制度動向に関する社内の解釈をまとめた資料は Amazon Bedrock Knowledge Bases からセマンティック検索で引き出します。取得は②で完了させ、③④はその結果を引き継ぎます ③ 記事再構築・リスク／機会判定（Claude Sonnet 4.6） ：②の情報と、AgentCore Memory から取り出した過去の判断をもとにニュースを再構築し、リスクと機会、実務・経営への示唆を整理します ④ 対応アドバイス・信頼性評価（Claude Haiku 4.5） ：③の記事を前提に対応策を提言し、その内容を自動評価します。完了後、オーケストレーターが結果を DynamoDB に保存します 技術的ポイント 1：担当者の判断を記憶し、次の記事に反映する 担当者が画面で登録した意思決定とコメントは、Lambda が CreateEvent で AgentCore Memory に書き込みます。書き込んだ内容からは 組み込みの戦略 で長期記憶が抽出され、次回以降の記事生成で参照されます。使っている戦略は次の 2 つです。 User preference 戦略 ：過去のコメントやレビューの観点 Semantic 戦略 ：進行中、または予定している対応策 意思決定は承認・却下のときだけ、コメントは常に登録します。保留を登録しないのは意図的な設計で、迷いのある判断を混ぜず、確定した判断だけを記憶に残すためです。 AgentCore Memory は、ユーザーとエージェントの会話から好みや重要な事実を抽出し、以降の会話に活かす使い方が代表的ですが、ESG ダッシュボードでは会話ではなく、業務画面で登録された担当者の判断を API で直接書き込んで記憶の元にしています。チャットのような対話の形をとらない業務システムでも、利用者の判断を記憶として蓄積し、エージェントの出力に反映できる一例です。 記憶の取り出しには、 RetrieveMemoryRecords を呼ぶ独自のツールを戦略ごとに用意し、それぞれ関連度の高い上位 5 件を取得します。取得した記憶は③記事再構築で参照し、どの観点でニュースを読み解くか、エナリスの取り組みに照らして何をリスクや機会と捉えるかの判断材料にします。④の対応アドバイスは③の記事を前提に作られるため、記憶の内容はアドバイスにも間接的に効きます。モデルを再学習させるのではなく、蓄積した判断を生成のたびに参照する仕組みです。 組織としての知見は、ナレッジベースに持たせています。格納しているのは、電力・燃料関連の制度動向について社内で共有・議論し、その解釈をまとめた資料です。規制の条文などの一次情報はその都度 Web から取得し、ナレッジベースには「その規制変更をエナリスとしてどう捉えるか」を持たせる、という役割分担にしています。 技術的ポイント 2：自動評価と人の確認を組み合わせて品質を担保する エージェントを分割する ：開発の初期には、複数のニュースをまとめて処理すると、本来は別々のニュースの内容が混ざり、1 本の記事にまとまってしまう問題がありました。プロンプトの改善では解消できず、役割ごとのサブエージェントに分けることで解決しています。Agents as Tools では各サブエージェントが独立したコンテキストで処理を行うため、情報の混線を防げたと考えられます。 自動評価と、その限界 ：エナリスと KAG は 前回の記事 でも、人と AI が相互にフィードバックし合って精度を高め合う HCAI（Human-Centered AI）の仕組みを取り入れてきました。ESG ダッシュボードでもこの考え方を引き継ぎ、④が Strands Agents の評価用 SDK である Strands Evals を使って、生成した対応アドバイスをその場で採点します。③の再構築記事、取得した関連情報、ナレッジベースの内容を根拠として渡し、アドバイスが根拠に忠実かといった 9 つの指標で評価して、平均値を A／B／C の 3 段階で画面に表示します。 ただし、この評価の対象は④のアドバイスで、③の記事は根拠の側にあります。③で誤りが混入していても、④がそれに忠実であれば評価は高くなります。多段のパイプラインで最終出力だけを評価しても、途中で生じた誤りは検出できません。そこで③の記事は担当者が画面で確認し、その判断が技術的ポイント 1 の記憶を通じて次回の③に戻る設計にしています。自動評価が④を守り、自動評価の届かない③を人が確認して、その判断を③に返す。守る場所と、判断を活かす場所がそろっていることが、この仕組みの要点です。 評価には当初、オープンソースの評価フレームワークである RAGAS を使っていましたが、別系統で動く外部ライブラリとの連携にオーバーヘッドがありました。Strands Evals への移行で 1 件あたりの評価時間は約 8 分から約 4 分へと約 40% 短縮し、判定結果は移行の前後で一致しています。 技術的ポイント 3：品質を保ったままコストを下げる 構築当初はすべての処理を Claude Sonnet 4.6 で動かしており、LLM の利用コストが課題になりました。Amazon CloudWatch でトークン使用量を可視化し、入力トークンの量とモデルの単価の 2 つの軸で打ち手を重ねた結果、1 回の実行あたりの入力トークンは数千万トークン規模から数十万トークン規模へと 98% 以上減り、1 日あたりの LLM コストは約 88% 下がっています。 入力を削る Web の取得方法を見直す ：HTML をタグごと渡していた処理を改め、①ではページの内容をテキストで返す外部 Web 検索 API に切り替えました（情報源判定 1 件あたり約 800 万 → 約 40 万トークン）。②では AgentCore Browser 上の独自ツールで HTML の除去と構造化を行っています（記事取得 1 件あたり約 100 万 → 約 40 万トークン） 単価を下げる キャッシュを使う ：システムプロンプトやツール定義など毎回同じ部分を プロンプトキャッシュ の対象にしました。情報源判定 3 件での測定では約 400 万トークンがキャッシュからの読み込みになり、その分は通常の入力より低い単価で処理されています モデルを使い分ける ：サブエージェントごとに Claude Haiku 4.5 の出力を検証し、品質に影響が出ない①②④を Haiku 4.5 に移しました。③と、①の中の robots.txt 確認は Sonnet 4.6 のままです。robots.txt 確認は機械的に見えますが、解釈を誤ると取り込んではいけない情報を取り込むことになります。モデルは処理の重要度ではなく、誤りをどこまで許容できるかで選んでいます。 導入効果 2026 年 1 月から AgentCore の導入を進め、約 4 か月の開発を経て、2026 年 7 月からサステナビリティ推進の担当部署で利用が始まりました。 業務面 担当者が手作業で行っていた ESG 関連情報の収集と整理が日次で自動化され、自社への影響と対応アクションの案を起点に検討を始められるようになりました 承認・却下の判断とその理由が意思決定履歴として残り、判断の経緯を後から振り返れるようになりました 技術面 開発の過程で見直しを重ねた結果、構築当初（すべての処理を Claude Sonnet 4.6 で実行し、評価に RAGAS を使っていた時点）と比べて、次の効果が出ています。 入力トークン（1 回の実行あたり）：数千万トークン規模 → 数十万トークン規模（98% 以上削減） LLM コスト（1 日あたり）：約 88% 削減 評価時間（1 件あたり）：約 8 分 → 約 4 分（約 40% 短縮） また、サーバーレス構成のため、ベースとなるインフラの固定費は月額数十ドル程度に抑えられ、OS の保守などの運用負荷もかかりません。 現在は、実際に利用する担当者のフィードバックを受けて改善を続けています。 今後の展望 週次サマリを経営層の意思決定の場でも活用していくほか、同じ構成を、規制への適合性をアドバイスする「規制／ルール分析」機能へ展開する予定です。あわせて、これまでの社内の解釈に加えて、公式の制度ルールや法改正の情報もナレッジベースに順次取り込んでいきます。まずは社内で運用しながら、データの取得方法や、外部に公開できるデータの範囲を整備し、将来的には規制分析の知見を活かした外部向けサービスとしての展開を目指しています。 まとめ エナリスと KAG は、Amazon Bedrock AgentCore と Strands Agents を使い、担当者の判断を AgentCore Memory に蓄積して次回以降の記事に反映する ESG ダッシュボードを構築しました。自動評価の届かない工程を人が確認し、その判断を記憶として同じ段に返す設計は、HCAI を実運用に落とし込む一つの形です。AI エージェントの本番運用に取り組む方の参考になれば幸いです。 著者 星野 友宏 株式会社エナリス 事業企画本部 みらい研究所 技術開発部門 御田 稔 KDDI アジャイル開発センター株式会社 テックエバンジェリスト 山本 直弥 KDDI アジャイル開発センター株式会社 ビジネスイノベーション開発本部 ビジネスイノベーション開発4部 ソフトウェアエンジニア 安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト

本ブログ記事は、株式会社インフキュリオン 菊田 慎一郎 様、向後 宗一郎 様、石原 幸治 様、佐々木 明良 様 および アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 松原 武司 の共著です。 請求書のカード払いを実現するプラットフォーム「 Winvoice 」を提供する株式会社インフキュリオンは、2026 年 6 月、Winvoice 機能を AI エージェントから呼び出せるリモート MCP（Model Context Protocol) サーバーを公開しました。日本の請求書カード払い領域における MCP 対応サービスとしては初の事例です（インフキュリオン調べ）。 生成AI をめぐる技術は数か月で新しい要素が生まれ、トレンドも入れ替わり続けています。株式会社インフキュリオン様は「早く出して先行者になること」自体が競争力に直結すると考え、MCP 対応クライアントが普及し始めたこのタイミングにて、企画から公開までを約 1 か月で走り切ることを目標とし、それを実現されました。 本ブログ記事では、その短期間でのローンチを成立させたアーキテクチャ上の判断を軸に、課題、リモート MCP サーバー方式と Amazon Bedrock AgentCore ( AgentCore Runtime ) の選定理由、Fintech ならではのセキュリティ・統制設計、そして得られた価値を共有します。 実際に設計と実装を担当された株式会社インフキュリオンのエンジニアの方々に、以下をご説明いただきます。 株式会社インフキュリオン と 請求書カード払いプラットフォーム 「Winvoice」 課題：分断された経理業務と、AI 活用の壁 アーキテクチャの全体像 主なアーキテクチャ上の判断と今後の展望 株式会社インフキュリオン と 請求書カード払いプラットフォーム 「Winvoice」 株式会社インフキュリオンは 2006 年創業の Fintech 企業で、決済領域を中心に金融サービスプラットフォームを提供しています。「決済から、きのうの不可能を可能にする」をミッションに、ライセンス対応からカスタマーサクセスまでワンストップで支援する事業を展開しています。 Winvoice は、その中で「請求書カード払い」に特化したプラットフォームです。請求書を受領する側がカード払いに切り替えられる機能と、請求書を発行する側がカード決済オプションを追加できる機能を提供し、AI-OCR、承認ワークフロー、KYB (Know Your Business：企業確認) / KYC (Know Your Customer：顧客確認) 審査、3Dセキュア対応を備えています。SaaS 企業、金融機関、商社・卸といったプラットフォーマーが、自社サービスに請求・支払機能を組み込んで利用しています。 課題：分断された経理業務と、AI 活用の壁 Winvoice を利用する企業の経理現場では、請求書の受領から支払完了までの作業が複数のシステムにまたがって分断されていました。会計ソフト、経費精算、Winvoice、メール、各種ファイルといったソースを行き来する手作業が、月末月初の負担として残っていました。 一方で、AI を業務に取り入れたいというニーズは強く存在しました。しかし、ローカル環境のセットアップや API 連携の難易度が、非エンジニアの現場では着手の障壁になっていました。Claude Desktop をはじめとする MCP 対応クライアントが普及し始めたこのタイミングで、Winvoice 側からも MCP に応える側を準備することが、現場の経理担当者に AI 活用を届ける現実的な手段だと判断しました。 加えて、この判断には時間軸の制約もありました。MCP という規格そのものがまだ立ち上がり期にあり、対応クライアントの普及とともに主導権の所在が短期間で動く局面です。ここで早く実装を届けられるかどうかが、請求書カード払い領域での立ち位置を左右すると考え、私たちは短期リリースを前提にプロジェクトを設計しました。 請求書カード払いサービスで初の挑戦としての位置づけ 請求書カード払いは、決済という慎重さを必要とする領域です。インフキュリオン は、本プロジェクトを「業務効率化」だけでなく「Fintech サービスにおける AI エージェント連携のリファレンス事例」として位置づけました。 同時に、早く届けることに価値があるプロジェクトでもありました。生成 AI をめぐる技術と対応クライアントは数か月で様変わりし、この領域では先に出したサービスが事実上の参照点になります。そこで私たちは、企画から公開までを約 1 か月で完了させることを最初のマイルストーンとしました。 この短納期を現実的にしたのが、テックリードの菊田が描いた「既存資産の流用と AWS マネージドサービスの活用による MCP サーバー構築」という技術方針です。認証基盤には Winvoiceチームが本番運用してきた Amazon Cognito をそのまま使い、実行基盤にはチームが日常的に扱ってきた AWS、とりわけ Amazon Bedrock を中心とするマネージドサービスを選択する。ゼロから作り込むのではなく運用実績と習熟のある構成要素を組み合わせることで、限られた時間を Fintech として外せない統制の設計に集中させる— この方針を軸に、新卒入社の若手エンジニアが設計・実装の中核を担い、開発リードは入社 3 年目の佐々木が務めました。その具体的な構成は、次のアーキテクチャ全体像と設計判断で順に説明します。 また、本プロジェクトでは次の三項を同時に満たすことをゴールに置いています。 先行者として早期に届けること： 技術が数か月で入れ替わる中、企画から公開までを約 1 か月で実現する 非エンジニアの経理担当者・経営者にも届く体験 ：URL を 1 行設定するだけで AI エージェント側から Winvoice を呼び出すことができる状態 規制業種として求められる統制 ：認証・認可、テナント分離、監査ログ、最終承認における人の関与 アーキテクチャの全体像 システムは 3 層構成です。MCP クライアント層、Amazon Bedrock AgentCore Runtime 上で動作するリモート MCP サーバー層、そして既存の Winvoice バックエンド層です。MCP サーバーは Winvoice 既存の認証基盤と接続し、ユーザーが本来権限を持つ範囲のみを公開します。 設計判断 #1：リモート MCP サーバー方式の採用 MCP に対応する方式には、利用者がソースコードを取得して自分の端末で動かすローカル方式と、サーバー側でホストし利用者は URL を設定するだけで使えるリモート方式があります。 検証 や MVP (Minimum Viable Product) の段階では、ソースコードを GitHub などで配布するローカル方式が手軽で、実際に多くの事例がこの形を採用しています。Winvoice においても、社内での概念実証の段階ではこの方式で進めていました。 しかし Winvoice は、決済という利用者からの信頼が何よりの土台となる領域のサービスです。開発者以外の外部利用者へ正式に提供する際には、ローカル方式のままでは、この信頼を支えきれないと判断しました。ソースコードを公開すること自体が攻撃の起点になりうること、開発者でなければ安全に導入・運用できないこと、機能を更新するたびに各利用者の端末へ配布し直さなければならないことは、いずれも決済サービスに求められる安全性と一貫した運用を損ないます。 そこで インフキュリオンでは、サーバー側で認証・認可・監査を一元的に管理でき、利用者にはソースの管理も環境構築も求めず、接続も HTTPS だけで完結する、より信頼性と安全性の高いリモート方式を採用しました。この方式では、機能改善もサーバー側の反映だけで全利用者へ届けられるため、立ち上がり期の規格を扱う上で欠かせない「出した後に速く直せること」も同時に満たせます。 リモート MCP サーバー方式は、生成 AI を業務に組み込もうとする多くの企業で共通の論点になります。利用者側の環境構築を不要にできるため、配布コスト・サポートコストを抑えながら、対象ユーザー層を一気に広げられる点が事業判断としても有効です。Fintech のように非エンジニアのユーザーが多い業界では、特に効果が大きいアプローチです。 設計判断 #2：リモートMCP採用にあたってのAWSアーキテクチャの検討 リモート MCP サーバーの実行基盤は、複数の構成案を検討し、タイムアウト仕様の調査と PoC での検証を経て絞り込みました。壁になったのは、Winvoiceの提供機能に含まれる最大10分程度を見込む処理においても、その進行状況をMCP の Streamable HTTP プロトコルにおいてサーバーサイドからクライアントに状況をSSE (Server-Sent Events) で通知可能とすることでした。 AWS App Runner や、 Amazon CloudFront + AWS Lambda 構成も候補に挙がりましたが、この観点から除外しました。 最終的に Amazon Elastic Container Service (ECS) と Amazon Bedrock AgentCore Runtime が候補として残りましたが、AgentCore Runtime の採用を決定しました。採用の決め手となったのは以下の 3点 です。 MCP プロトコルのサポート ：SSE ストリーミングに最大 60 分対応し、ハートビートのような回避策なしに長時間接続要件を満たすことができます。 ステートフルなセッションを標準機能で実現 ：セッションごとに専用の マイクロ仮想マシン (microVM) が割り当てられ、セッション継続性とテナント間の分離を仕組みで担保できます。 運用負荷とコストの最小化 ：クラスタ管理・パッチ適用が不要で、セッション期間中の CPU・メモリの秒単位従量課金、I/O 待機中は CPU 無課金のため、常時稼働構成を避けることができます。 また、AgentCore Runtime の microVM から Amazon S3 や Amazon Cognito などの AWS サービスへアクセスする経路には、VPC ネットワークモード と VPC エンドポイント（ AWS PrivateLink ）を採用しました。これにより、AWS内にトラフィックが留まるセキュアな通信経路を確立しています。 さらに、既存の Winvoice 本番環境とは VPC 自体を完全に分離する設計としました。万が一、リモート MCP サーバーが設計上意図しない動作を行うような事態が発生した場合でも、その影響を最小限に止め、Winvoice 側が持つ機密情報への不正アクセスを未然に確実に防ぐ「多層防御」のアーキテクチャを実現しています。 設計判断 #3：認証・認可 ― 既存の認証基盤を無改修で接続する AI エージェントという新しい入口を設ける上で、認証と認可において、次の 3つの問い に答える必要がありました。 認証 ：OAuth 2.1 + PKCE と Protected Resource Metadata（RFC 9728）によるディスカバリを求める MCP クライアントを、既存の認証基盤とどう繋ぐか アウトバウンド ：MCP サーバーは、どのような権限で Winvoice API を呼び出すか 認可 ：MCP 連携を、誰にどう開放するか いずれのポイントでも、稼働中の決済サービスである点を鑑み、「既存アプリケーションには極力手を加えない」ことを共通の前提 (制約) としました。採用した構成の全体像は次のとおりです。 認証：Hub & Spoke 型の Cognito フェデレーション MCP クライアントはブラウザーリダイレクト型の OAuth フローを前提としますが、Winvoice の既存認証はこれに対応していません。加えて、Winvoice はプラットフォーマーごとにテナントを分離したマルチテナント構成で、Cognito ユーザープール もテナント別に分かれています。そこで、MCP 専用の Cognito ユーザープール（Hub）を新設し、テナント別の既存ユーザープール（Spoke）を OIDC IDプロバイダー(IdP) としてフェデレーションする構成を採用しました（図 の ①・②）。ポイントは次の 3 点です。 シンプルな接続体験 ：MCP クライアントからは OAuth 2.1 + PKCE に対応した認可サーバーが 1 つ見えるだけです。ユーザーは既存の Winvoice アカウントをそのまま使ってサインインでき、新たなアカウント発行やパスワード管理は不要です。 既存基盤は無改修 ：既存の ユーザープール は OIDC IdP として参照されるだけで、稼働中のアプリケーションに影響を与えません。 自前実装の最小化 ：トークンの検証は Bedrock AgentCore Identity の インバウンド認証（ カスタムJWTオーソライザー設定 ）に委譲し（図の③）、独自実装部はディスカバリ用メタデータ応答の検証などの薄いレイヤーのみです。 アウトバウンド：「AI に権限を渡さない」トークン設計 MCP サーバーが Winvoice API を呼び出す際は、AgentCore Identity の機能である Token Vault が提供する 3-Legged OAuth により、ユーザー本人の同意を経て取得した本人のトークンを使用します（図の④・⑤）。Winvoice API 側からは MCP 経由のアクセスを通常のユーザーアクセスと同一に扱えるため、既存の認可・テナント分離・監査の仕組みがそのまま最終防壁として機能します。AI エージェント経由でも、権限の主体は常に人 (ユーザー) のままという設計原則です。 認可：二段構えの許可リスト 決済に関わるサービスとして全ユーザーへの一斉開放は行わず、「誰に AI 連携を許すか」を利用企業自身がガバナンスできる形にしています。 層 操作者 内容 ① 法人単位の利用設定 利用企業の管理者 利用規約に同意して MCP 連携を有効化。無効化すれば配下ユーザーの利用許可も一括で解除 ② ユーザー単位の許可リスト 利用企業の管理者 有効化した法人の中でも、明示的に許可したユーザーのみが利用可能 この二段構えにより、β版としての段階的な開放にも、問題発生時の即時取り消しにも、同じ仕組みで対応できます。許可リストの正本は Cognito ユーザープール の「 グループ 」に配置し、トークンに含まれるグループ情報で判定することで、ここでも既存アプリケーションの無改修と独自実装する範囲の最小化を徹底しました。 Winvoice 今後の展望 本リリースは、Winvoice における AI エージェント連携の第一歩です。株式会社インフキュリオン は 以下の方向で取り組みを検討し、アマゾン ウェブ サービス ジャパン は、そのご支援を継続します。 会計ソフト・経費精算サービスとの横断連携を MCP 越しに実現し、AI エージェントを経理業務のハブにする 既存機能や外部請求書取込といった機能を、MCP ツールとして順次拡張する Claude 以外の MCP 対応クライアントへの対応拡大など、ベーシック機能を拡充する 蓄積した取引データと AI を組み合わせ、資金ショート予測といった先回りの提案へ踏み込む まとめ Winvoice はリモート MCP サーバー方式により、URL 設定のみで AI エージェントから請求書カード払い業務を呼び出せる体験を実現しました。 既存の Amazon Cognito と、チームが習熟していた Amazon Bedrock を中心とする AWS 環境を活かしたことが、企画から公開まで約 1 か月という短納期を後押ししました。 Amazon Bedrock AgentCore Runtime のセッション分離・認証認可の統合により、Fintech に求められる統制と AI 活用を両立しました。 最終承認は人間が画面で実施するヒューマンインザループ設計により、規制業種としての安全性を担保しました。 本アプローチは、AIエージェント連携を業務システムへ組み込む際の、Fintech 領域での参考事例の1つとなります。 著者について 菊田 慎一郎 (株式会社インフキュリオン) Winvoice 部 テックリード 前職ではソフトウェアエンジニアとして EC サイトのリプレイスなどを担当。 2025 年 4 月にインフキュリオンに中途入社し、Winvoice のテックリードとしてアプリケーション開発に従事。本プロジェクトでは、約 1 か月での公開を現実にするため「既存資産の流用と AWS マネージドサービスの活用」という技術方針を描き、テックリードとして設計・実装に伴走。若手エンジニアが中核を担う体制を支えた。 向後 宗一郎 (株式会社インフキュリオン) Winvoice 部 ソフトウェアエンジニア 2021 年新卒入社。Wallet Station でフロントエンドテックリードを経てプロダクトアーキテクトを務め、次世代アーキテクチャの構想・設計を主導。2026 年より Winvoice のスクラムチームリーダーとしてチームに合流。本プロジェクトでは認証認可設計・アーキテクチャレビュー・実装支援を横断的に担当。 石原 幸治 (株式会社インフキュリオン) プロダクトマネジメント部/Winvoice 部（兼務）インフラエンジニア 前職では VMware を中心としたオンプレ基盤の設計・構築・運用に加え、オンプレ基盤と外部ネットワーク間の接続設計・構築を担当。2026 年 2 月にインフキュリオンに中途入社し、Winvoice の AWS インフラ基盤の設計・構築・運用と Terraform による IaC 管理を担当する。本プロジェクトではリモート MCP サーバーのインフラ設計・構築を担当。 佐々木 明良 (株式会社インフキュリオン) Winvoice部 ソフトウェアエンジニア 2024年新卒入社。請求書AI-OCR機能の開発やAI審査支援など、AIの業務適用領域を主に担当。本プロジェクトでは開発リード兼プロジェクト推進として、要件定義からステークホルダーとの調整、進捗管理、MCPサーバのアプリ実装までを幅広く担当。 松原 武司 (アマゾン ウェブ サービス ジャパン合同会社) シニア ソリューションアーキテクト 決済領域のお客様の AWS 活用を支援。本プロジェクトでは、リモート MCP サーバーのアーキテクチャ検討と Amazon Bedrock AgentCore Runtime 採用判断をご支援・伴走。

本記事は 2026 年 9 月 17 日 に公開された「 Free Sandbox Environments for Amazon Connect Customer on AWS Builder Center 」を翻訳したものです。 はじめに Amazon Connect Customer の ワークショップ が、 AWS Builder Center の 無料サンドボックス環境 で利用できるようになりました。AWS アカウント・クレジットカード不要で、予期しない請求なく、あらゆる顧客接点で優れたカスタマーエクスペリエンスを実現するエージェンティック AI ソリューションの構築をハンズオンで体験できます。AI を活用したカスタマーエクスペリエンスを試したい開発者、コンタクトセンターソリューションを評価する IT リーダー、Amazon Connect Customer に関心のあるビルダー、どなたでもサンドボックス環境ですぐに始められます。 なぜ重要なのか Amazon Connect Customer は、あらゆる規模の企業が優れたカスタマーエクスペリエンスを提供するために使用するクラウドコンタクトセンターサービスです。これまで、ワークショップで Amazon Connect Customer を試すには、自分の AWS アカウントと支払い方法の設定が必要でした。この要件が、多くのビルダーにとって最初の障壁となっていました。 2025 年 11 月に Builder Center でワークショップが公開されて以来、2026 年 8 月時点で 167,000 回以上のページビューと 12,200 人以上のビルダーによるワークショップの閲覧があり、ハンズオン学習への明確なニーズが確認できました。しかし、多くのビルダーはアカウントのセットアップで離脱しています。AWS アカウントを持っていない、支払い方法を登録できない、セットアップの手間であきらめるなどの理由です。 Builder Center の無料サンドボックス環境により、この障壁がなくなりました。事前にプロビジョニングされた実際の AWS 環境で、コンタクトフローの構築やエージェントルーティングの設定などを試すことができます。 使い方 数回のクリックで始められます。 対象ワークショップを探す — AWS Builder Center にアクセスし、サンドボックスバッジが付いた Amazon Connect Customer ワークショップを探します。 サンドボックスをリクエストする — ワークショップカードの「無料サンドボックス環境をリクエスト」を選択します。アカウント作成も支払い情報も不要です。 構築を始める — 事前にプロビジョニングされた AWS 環境が 15 分以内に準備されます。8 時間、ハンズオンを利用できます。 自動クリーンアップ — セッション終了後、環境とすべてのリソースが自動的に削除されます。手動でのクリーンアップは不要です。 注意 : 同時に利用できるサンドボックスは 1 つまでで、リクエストは週 1 回 (毎週日曜日にリセット) です。 図: AWS Builder Center の Amazon Connect ワークショップで表示される「Request free sandbox environment (無料サンドボックス環境をリクエスト)」ボタン。 構築できるもの Amazon Connect Customer のサンドボックスワークショップでは、以下のような実践的なシナリオを体験できます。 コンタクトセンターのセットアップ — Amazon Connect Customer インスタンスの作成、電話番号の取得、営業時間の設定を行います コンタクトフロー の構築 — ドラッグ & ドロップのフローブロックで IVR (自動音声応答) エクスペリエンスを設計します AI によるセルフサービスの追加 — Amazon Lex チャットボットを統合し、自然言語によるインタラクションを実現します ルーティングの設定 — キュー、ルーティングプロファイル、エージェント割り当てを設定します 分析の有効化 — 会話分析機能でリアルタイム分析や通話後分析を確認します 各ワークショップはセルフペースで進められ、ファシリテーターなしで完了できる設計になっているため、自分のスケジュールに合わせて学習できます。 対象ユーザー ビルダーや開発者 — AWS アカウントなしで Amazon Connect Customer を実践的に体験したい方 ソリューションアーキテクト — 組織向けのコンタクトセンターアーキテクチャを評価している方 IT 意思決定者 — 導入の計画前に Amazon Connect Customer の実際の動作を確認したい方 学生やキャリアチェンジを目指す方 — 費用負担ゼロでクラウドスキルを習得したい方 セキュアな設計: 安心して体験 サンドボックス環境はサンドボックスレベルの権限で実行されます。ワークショップを完了するのに十分なアクセス権がありながら、セキュリティを損なう操作や過剰なコストが発生する操作は防止されます。各サンドボックスには以下の特徴があります。 時間制限あり — 8 時間のセッション後、自動的に削除されます 分離された環境 — サンドボックスは専用の環境であり、他の環境に影響しません。本番の AWS サービスやアカウントへの接続はありません コスト管理 — 引き下げられたサービス制限により、コストが予算内に収められています 安全性 — すべてのワークショップは、サンドボックス有効化の前にセキュリティスキャンを通過しています 一時的 — セッション中に作成されたすべてのデータは、サンドボックスの削除時に自動的に消去されます 今すぐ始めましょう AI を活用したコンタクトセンターの構築を始めましょう。 AWS Builder Center Workshops にアクセスし、 サンドボックスバッジ が付いた Amazon Connect Customer ワークショップを探してください。ワンクリックで無料のハンズオン学習をすぐに始められます。 AWS アカウント、クレジットカード、コストは一切不要です。すぐに構築を始められます。 関連リソース Amazon Connect Customer — 製品ページ AWS Builder Center Introducing Sandbox Environments on AWS Builder Center AWS Builder Center のサンドボックス環境は一部のワークショップで利用でき、対象は随時拡大されています。最新の対象ワークショップは builder.aws.com でご確認ください。 著者について Abhishek Pandey は、テキサス州ヒューストンを拠点とする Amazon Web Services のワールドワイドテックリーダーです。業界を問わずビジネスイノベーションを推進するクリエイティブなソリューションの設計に情熱を注いでおり、Amazon Connect および Applied AI ポートフォリオ全般を活用したエージェンティックなカスタマーエクスペリエンスソリューションの設計・実装を専門としています。AWS 全体の技術力向上を推進するプログラムを主導し、re:Invent のコンテンツリーダーおよびスピーカーとして AWS の主要イベントに貢献しています。 Ekta Vasa は、カリフォルニア州サンフランシスコを拠点とする AWS ワールドワイドパブリックセクターチームのシニアソリューションアーキテクトです。IT 分野で 10 年以上の経験とソフトウェアエンジニアリングのバックグラウンドを持ち、カリフォルニア州政府機関のクラウドモダナイゼーションを支援しています。支援範囲は、コンタクトセンターの変革、マイグレーション、生成 AI、データ分析、ハイブリッドネットワーキングなど多岐にわたります。Amazon Connect および AWS エコシステム全般を活用した AI 搭載コンタクトセンターソリューションの実装に専門知識を持っています。Ekta は、お客様が AWS クラウド上でセキュアかつスケーラブルでコスト効率の高いソリューションを構築できるよう支援することに情熱を注いでいます。 Vijay Chauhan は、イギリス・ロンドンを拠点とする AWS Applied AI のシニアワールドワイドソリューションアーキテクトです。コンタクトセンターの変革、AI を活用したカスタマーエクスペリエンス、エンタープライズ CX アーキテクチャに深い専門知識を持ち、EMEA の大手金融サービス企業が Amazon Connect を活用したインテリジェントな顧客エンゲージメントソリューションを設計・実装できるよう支援しています。Vijay は、クラウドネイティブな CX の適用範囲を従来のテレフォニーを超えて、エージェンティック AI、バックオフィスの自動化、オムニチャネルイノベーション (ビデオバンキング、チャット、支店内の録音分析など) へと拡大することに情熱を注いでいます。 この記事はテクニカルアカウントマネージャーの高橋が翻訳しました。

本ブログは 2026 年 5 月 26 日に更新された AWS Blog “ Welcoming the AWS Customer Incident Response Team ” を翻訳したものです。 2026 年 5 月 26 日 : この記事は 2022 年 7 月に初めて公開したものです。現在利用できる支援の依頼方法、Threat Technique Catalog for AWS (TTC) などの新しい脅威インテリジェンスリソース、追加のオープンソースツールを反映し、AWS CIRT による支援と AWS Security Incident Response マネージドサービスの違いも明確にするために更新しました。 以前からの読者の方も、初めての方も、ご覧いただきありがとうございます。私たちは AWS Customer Incident Response Team (CIRT) です。この記事では、チームの概要と、いざというときにどのようにお役に立てるのかをご紹介します。 AWS CIRT は、 Amazon Web Services (AWS) 内にある 24 時間 365 日体制の専門グローバルチームです。 AWS 責任共有モデル におけるお客様の責任範囲でセキュリティイベントが進行しているときに、お客様を支援します。チームはセキュリティエンジニアで構成されており、クラウドのセキュリティイベントに対応するだけでなく、その対応に使用するツールやリソースも構築しています。 重要 : AWS 環境でセキュリティイベント (不正アクセス、データ流出、ランサムウェアなど) が進行中の場合は、AWS サポートケースを作成して支援を依頼してください。 AWS に支援を依頼する手順は次のとおりです。 影響を受けた AWS アカウントで AWS サポートセンターコンソール を開き、サポートケースを作成します 。 セキュリティイベントに最も関連するサービスを選択します (例: Amazon Elastic Compute Cloud (Amazon EC2) 、 AWS Identity and Access Management (IAM) 、 Amazon Simple Storage Service (Amazon S3) )。 ケースの説明欄に、 緊急のセキュリティインシデント が発生していることを明記します。 影響を受けたアカウントからサポートケースを作成すると、AWS がアカウントの所有権を確認できるほか、支援の状況を追跡するためのケース番号も発行されます。アカウントチーム (TAM、Account Manager、Solutions Architect) がいる場合は、アカウントチームに連絡してエスカレーションを開始することもできます。 アカウントにアクセスできなくなった場合でも、 支援リクエストを送信 できます。 AWS CIRT による支援では、AWS のサービスログや AWS コントロールプレーンで確認できるセキュリティイベントの調査に重点を置いています。分析には、 AWS CloudTrail と Amazon VPC フローログ に加え、 Amazon GuardDuty の検出結果などの情報源を活用します。また、トリアージ、分析、封じ込めを支援するとともに、今後のセキュリティイベントを防ぐための推奨事項とベストプラクティスも提供します。 AWS CIRT は、AWS の脅威インテリジェンスチームやセキュリティオペレーションチームと連携しています。支援の際には、最新の脅威インテリジェンスと AWS インフラストラクチャに関する知見を分析や推奨事項に役立てています。 オペレーティングシステムのフォレンジック、メモリ分析、アプリケーションコードのレビューなど、ホストレベルやアプリケーションレベルの分析が必要な調査については、デジタルフォレンジックとインシデントレスポンス (DFIR) に対応できる専門の AWS パートナー のサービスを併用し、AWS CIRT による支援を補完することをお勧めします。 図 1 は、責任共有モデルの 2 つの側面を示しています。AWS は「クラウドのセキュリティ」に、お客様は「クラウド内のセキュリティ」に責任を負います。 図 1: お客様と AWS の責任共有モデル 脅威インテリジェンス: Threat Technique Catalog for AWS AWS CIRT は、さまざまな支援の中で同じパターンが繰り返し現れることを日常的に目にしています。TTC はもともと、各支援で得られた知見をチーム内で追跡、共有し、同じ問題に個別に取り組むことを避けるための社内向けリファレンスとして始まりました。やがて、チームのために蓄積してきた知識こそ、お客様が同じ脅威に先手を打つために必要なものだと明らかになり、一般公開しました。複数のお客様の環境で同じ手法が繰り返し観測されるのであれば、それらの手法を文書化して知識として共有することが、お客様を支援する効果的な方法です。そうすれば、お客様はインシデントへの対応が必要になる前に対策を講じることができます。 そこで開発したのが Threat Technique Catalog for AWS (TTC) です。 MITRE ATT&CK Cloud Matrix に基づく一般公開のカタログで、AWS CIRT が観測した、脅威アクターによる AWS 固有の戦術、手法、手順 (TTPs) を文書化しています。各エントリには、AWS 環境に特化した検出ガイダンスと緩和策が記載されています。アカウントで使用している AWS のサービスでフィルタリングすれば、関連性の高い情報に絞り込むことができます。 TTC の知見は、 Amazon GuardDuty などの AWS のサービスが備える検出ロジックにも反映されており、お客様の環境における自動化された保護の強化に役立っています。 図 2: MITRE ATT&CK Cloud Matrix に基づく Threat Technique Catalog for AWS オープンソースツール AWS CIRT は、支援の中で見られるパターンを基に、いくつかのツールをオープンソースとして公開しています。これらのツールは既存のセキュリティツールを置き換えるものではなく、補完するものです。インシデントレスポンスプログラムを構築するための包括的なフレームワークについては、「 AWS セキュリティインシデント対応ガイド 」を参照してください。 以下のツールは、AWS CIRT が繰り返し直面してきた問題を解決するために、もともと社内向けに構築したものです。 AWS Customer Playbook Framework – セキュリティイベントから得た教訓を基にした、一般公開の対応フレームワーク Assisted Log Enabler – Amazon VPC フローログ 、 AWS CloudTrail 、 Amazon Elastic Kubernetes Service (Amazon EKS) の監査ログと認証ログ (authenticator logs)、 Amazon Route 53 Resolver クエリログ、 Amazon Simple Storage Service (Amazon S3) サーバーアクセスログ、 Elastic Load Balancing のログなどの有効化を支援するツール AWS CloudSaga – AWS CIRT が確認している一般的なセキュリティイベントを基に生成したシミュレーションイベントを使用して、AWS 環境内のセキュリティコントロールとアラートをテストするツール Athena Security Analytics Bootstrap – Amazon Athena をすばやくセットアップし、S3 バケットにアーカイブされた AWS のサービスログを調査したいお客様向けのツール ワークショップ AWS CIRT は、 一般公開されている 5 つのワークショップ を提供しています。最新のセキュリティイベントをシミュレートできるよう定期的に更新しており、AWS CIRT が日々使用しているツールや手順を学ぶことができます。ワークショップでは、IAM 認証情報の不正使用、Amazon S3 でのランサムウェア、クリプトマイニング、IMDSv1 におけるサーバーサイドリクエストフォージェリ (SSRF)、インシデントレスポンスの準備に役立つツールを取り上げています。必要なのは、AWS アカウントとインターネット接続、そして AWS クラウドでのインシデントレスポンスについて学びたいという意欲だけです。これらのワークショップは、チームの社内トレーニングと同じシナリオを使用して構築されています。これらのシナリオを誰もが利用できるようにしたいという思いから公開しました。 AWS CIRT への連絡方法 AWS のお客様であれば、サポートプランのレベルにかかわらず、 AWS サポートケース から AWS CIRT に支援を依頼できます。アカウントチームがいるお客様は、アカウントチームを通じて AWS CIRT へのエスカレーションを開始することもできます。また、Enterprise Support または Unified Operations をご利用のお客様は、セキュリティイベントのトリアージと対応を行うマネージドサービスである AWS Security Incident Response を導入することもできます。 最後までお読みいただきありがとうございます。この記事では、お客様が常に備えられるよう、AWS CIRT が把握しているセキュリティのトレンド、新しいリソース、脅威インテリジェンスを共有しています。AWS CIRT の支援を受けた経験があり、改善点についてご意見がございましたら、AWS アカウントチームまたは aws-cirt@amazon.com までご連絡ください。 それでは、また次回お会いしましょう。ログの有効化、認証情報のローテーション、アラートの確認をお忘れなく。 また、AWS のサービスに関するセキュリティイベントの通知を受け取れるよう、 AWS セキュリティ速報 の購読をお勧めします。 RSS フィード を購読して、最新情報を入手することもできます。 Jason Hurst Jason は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアで、ネットワーク分析とクラウドセキュリティの調査を専門としています。人材育成に情熱を注いでおり、地元の技術系カレッジで非常勤講師も務めています。余暇は 3 匹の愛犬と楽しく過ごしています。 Shannon Brazil Shannon は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアで、デジタルフォレンジックとクラウドセキュリティの調査を専門としています。コミュニティでは awslady として知られており、セキュリティ教育と、次世代のセキュリティ防御を担う人材の育成に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 9 月 14 日に公開された AWS Blog “ Zero operator access for self-managed databases using EC2 instance attestation ” を翻訳したものです。 セルフマネージド型データベースには、プライベートキーや認証情報から、個人を特定できる情報 (PII)、金融取引に至るまで、組織にとって最も機密性の高いデータが保存されていることがよくあります。コンプライアンスや規制の要件が課されるセキュリティ重視のアプリケーションでは、ホストへのアクセス権を持つ者がこうしたデータにアクセスするリスクを許容できません。そのため、ホスト上でゼロオペレーターアクセス (ZOA) の実現を目指します。 この記事では、完全に再現可能な ZOA 環境で、ステートフルなデータベースを設計し、実装する方法を説明します。この環境は、 Amazon Elastic Compute Cloud (Amazon EC2)、EC2 インスタンス構成証明 、 Nitro Trusted Platform Module (NitroTPM)、および Attestable AMI によって実現します。これらの機能を利用すると、 Linux Unified Key Setup ( LUKS ) で暗号化された Amazon Elastic Block Store (Amazon EBS) ボリュームの対称キーを、特定の Amazon Machine Image (AMI) の暗号学的な測定値に紐付けることができます。その結果、EC2 インスタンスは、正しい Attestable AMI で起動された場合にのみストレージを復号できるようになります。この Attestable AMI で想定されるブート測定値は、AMI のビルド時にあらかじめ算出されています。 ここでは PostgreSQL をワークロードの例としてこの手法を紹介しますが、同じパターンは、AI モデルの重みや独自のアルゴリズムなど、暗号化されたデータにアクセスできるワークロードを厳格に制限するガードレールが必要なあらゆるユースケースに適用できます。 前提条件とデプロイ 始める前に、以下の内容を理解しておいてください。 Nix Flakes : Nix Flakes は、完全に自己完結型のビルドフレームワークです。 flake.nix ファイルでシステム全体 (カーネル、パッケージ、サービス、構成) を宣言的に定義し、 flake.lock ファイルですべての入力を特定の git コミットハッシュに固定します。これにより、内容がソースコードによって完全に決まる、ビット単位で再現可能な AMI イメージを生成できます。 Linux のブートプロセス : Unified Kernel Image (UKI) 、 dm-verity (読み取り専用ファイルシステムの整合性確保用)、および LUKS (暗号化ボリューム用)。 TPM/PCR の概念 : Platform Configuration Register (PCR) がブート測定値を蓄積する仕組みと、PCR を偽造できない理由。 AWS のサービス : EC2 、 AWS KMS 、 EBS 、および IMDS 。KMS キー、EC2 インスタンス、EBS ボリューム、 AWS Identity and Access Management (IAM) ロール を作成する権限を持つ AWS アカウント が必要です。 プロビジョニングスクリプトや NixOS ベースのイメージビルドを含む完全なリファレンス実装は、 https://github.com/aws/nitrotpm-attestation-samples リポジトリで公開されています。 適切な AWS コンフィデンシャルコンピューティングソリューションの選択 AWS Nitro Enclaves は、ステートレスなワークロード向けとして広く利用されているコンフィデンシャルコンピューティング機能です。ただし、Nitro Enclaves は厳格に分離された環境で動作し、永続ストレージを持たず、ネットワーク機能も vsock チャネル経由に限られます。EBS ボリュームへの直接アクセス、高いスループット、永続的な状態を必要とするデータベースワークロードをエンクレーブ上に構築しようとすると、これらの制約を回避するために多大なエンジニアリング作業が必要になります。 EC2 インスタンス構成証明は、ハードウェアとネットワークへの完全なアクセスを維持したまま、信頼できるソフトウェアとブートプロセスのみがインスタンス上で実行されていることを暗号学的に証明します。Nix Flakes のような再現可能なビルドシステムと組み合わせることで、データベースに求められるストレージの特性やパフォーマンスを犠牲にすることなく、ゼロオペレーターアクセスを実現できます。 ZOA データベースのユースケースには、EC2 インスタンス構成証明が適しています。必要な機密性を確保しながら、暗号化された EBS ボリュームのマウント、高いスループットでのクエリ処理、標準的なネットワークでの運用をこれまでどおり行うことができます。 再現可能な Attestable AMI の構築 このセクションでは、Nix Flakes を使用して、完全に再現可能で構成証明可能な AMI を構築する方法を詳しく説明します。図 1 は、再現可能で構成証明可能な AMI を構築するために必要な 5 つの大まかなステップを示しています。 図 1: Amazon EC2 インスタンス構成証明 (ビルド時のみ)。再現可能な AMI を作成し、その参照測定値を生成します。 1. Nix ビルド : ロックされた flake の入力から決定論的にビルドを行い、AMI の raw イメージを生成します。このイメージは、ESP (UKI)、 dm-verity ハッシュツリー、 nix store (erofs、読み取り専用) で構成されます。入力が同じであればビット単位で同一の AMI が生成されるため、 PCR4 測定値も同じになります。 2. dm-verity によるストアの紐付け : UKI の cmdline には、 nix store に対するマークルツリー (Merkle Tree) のルートハッシュが含まれます。ビルド後にストアを変更するとルートハッシュが変わり、その結果 PCR4 も変わります。オプションとして、ビルド後に UKI に署名してセキュアブート署名を追加することもできます。テンプレートでは --secure-boot フラグを使用してこの処理を行っています。 3. nitro-tpm-pcr-compute : このビルド時ユーティリティは、UKI の .efi ファイルのみを読み取り、測定アルゴリズムをオフラインで再現して PCR 値を算出します。PCR 値は 96 文字の SHA-384 ダイジェストで表されます。 4. 参照測定値 : このツールは tpm_pcr.json を出力します。 PCR4 (Boot Manager Code): UEFI 環境が実行するブートバイナリのハッシュです。Attestable AMI では、このハッシュが 構成証明ドキュメント に追加され、AWS KMS キーポリシーに設定された PCR4 値と一致するかどうかを AWS KMS が評価します。これにより、KMS キーを利用できるコードを PCR4 で厳密に固定できます。 PCR7 (Secure Boot Policy、セキュアブートが有効な場合のみ): UEFI セキュアブートポリシーのハッシュです。この値は AMI を更新しても変わらないため、特定の AMI の測定値ではなく、セキュアブート証明書を検証する AWS KMS ポリシーを 1 つ記述するだけで済みます。 PCR12 : カーネルコマンドラインに加えられた変更 (アドオンファイルによる変更など) のハッシュです。 PCR4 と組み合わせて、コマンドラインが改ざんされていないことを確認するために使用します。 5. AWS Key Management Service (AWS KMS) キーポリシーへの組み込み : 参照測定値を RecipientAttestation 条件として設定します。これにより AWS KMS は、 実際の 測定値が一致するインスタンスに対してのみキーを提供するようになります。 それでは、図 1 に示した各ステップの実装の詳細を見ていきましょう。ステップ 1 と 2 に対応する処理として、まず Linux カーネル、カーネルコマンドライン、initramfs、一部のメタデータを含む、強化された Unified Kernel Image (UKI) をビルドします。 ビルドには Nix を使用することをお勧めします。Nix を使用すると、ビルドを宣言的かつ再現可能にできます。ロックされた同じソースからは常にバイト単位で同一の UKI が生成されるため、PCR4 測定値も常に同じになります。図 1 のステップ 3 と 4 のとおり、ビルドでは raw イメージとともに tpm_pcr.json ファイルが出力されます。 { "Measurements": { "PCR4": "f3a1e2...", "PCR7": "a32b31...", "PCR12": "000000..." } } 管理下にある Attestable AMI の PCR 測定値を持つ EC2 インスタンスにのみ AWS Key Management Service (AWS KMS) キーでの復号を許可するため、参照測定値を使用して AWS KMS キーポリシー を設定します。 { "Sid": "Allow decryption for the Instance role", "Effect": "Allow", "Principal": { "AWS": "${INSTANCE_ROLE}" }, "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEqualsIgnoreCase": { ${PCR_VALUES} } } } AWS KMS キーポリシーの JSON オブジェクト内にある ${PCR_VALUES} には、ビルド中に生成された tpm_pcr.json の測定値が入ります。 ここで重要なのは、インスタンス構成証明によって暗号学的に検証された AMI にのみ復号オペレーションを許可する唯一の制御点が、AWS KMS キーポリシーであるという点です。そのため、PCR 値は CI/CD パイプラインで自動更新するのではなく、慎重な手動プロセスで固定し、レビューする必要があります。自動更新を行うと、変更されたイメージや未承認のイメージが気付かないうちに許可され、構成証明による保証がすべて無効になるおそれがあります。 この例では、PostgreSQL データベース用の AMI を作成して、その PCR 測定値を取得します。そして、その測定値を使用して AWS KMS を設定し、正しい測定値で構成証明に成功した場合にのみ、データベースの EBS ボリュームのキーを復号できるようにします。それでは、Nix を使用して記述的かつ再現可能な形で実現できる、具体的なポイントをいくつか見ていきましょう。 ゼロオペレーターアクセス ゼロオペレーターアクセスを強制して不正アクセスの攻撃対象領域を限定するために、SSH やシリアル接続によるアクセスを含め、マシンへのあらゆる形式のログインを無効にします。 services.sshd.enable = lib.mkForce false; また、次の設定も行います。 systemd.services."autovt@" = lib.mkForce {}; systemd.services."getty@" = lib.mkForce {}; systemd.services.getty-static = lib.mkForce {}; systemd.services."serial-getty@" = lib.mkForce {}; ファイアウォールとインスタンスメタデータサービス (IMDS) の制御 さらに、インバウンド通信を PostgreSQL に必要なポート 5432 のみに制限し、 インスタンスメタデータサービス (IMDS) へのアウトバウンドアクセスを kms-init サービスにのみ許可できます。EC2 インスタンスで実行されるサービスが新しい一時的な AWS 認証情報を取得するには、IMDS へのアクセスが必要です。 networking.firewall = { # Allow inbound PostgreSQL connections over mTLS allowedTCPPorts = [ 5432 ]; # IMDS access control - only kms-init user can reach IMDS extraCommands = " # Allow kms-init service to access IMDS for KMS operations ${pkgs.iptables}/bin/iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner kms-init -j ACCEPT [...]"; }; 読み取り専用ファイルシステムの測定 エフェメラルなルートファイルシステム ( tmpfs 、ディスクや永続ストレージを使用しない) を / に配置します。 "/" = { fsType = "tmpfs"; options = ["mode=0755"]; }; 一方、実際のアプリケーションデータ (例えば postgres バイナリ) は /dev/mapper/usr に格納され、 /usr に読み取り専用でマウントされます。 "/usr" = { device = "/dev/mapper/usr"; # explicitly mount it read-only otherwise systemd-remount-fs will fail options = ["ro"]; fsType = config.image.repart.partitions.${partitionIds.store}.repartConfig.Format; }; ここで注意が必要なのは、 /dev/mapper/usr は UKI に含まれないという点です。そのため、NitroTPM の測定値 (UKI のビルド時に算出する PCR 値) は、/dev/mapper/usr に保存したデータと直接紐付いていません。 この状態は望ましくありません。権限のないユーザーがこの領域にアクセスできた場合、例えば postgres バイナリを改ざんされたビルドに置き換えることで、データベースの整合性と機密性を損なう可能性があるためです。 マウントされた /dev/mapper/usr ( /usr にマウントされ、 nix store を含む) の内容が想定どおりで変更されていないことを検証するため、 Linux dm-verity を使用してこの領域を PCR 測定値に紐付けます (図 1 のステップ 2 を参照)。Attestable AMI のビルド時に、 /dev/mapper/usr 全体の マークルツリー を計算し、そのルートハッシュをカーネルブートパラメータとして渡します。 カーネルコマンドラインはビルド時に UKI に埋め込まれ、バイナリ全体を対象とする PCR4 の測定範囲に含まれます。カーネルコマンドラインには systemd.verity_root_options=panic-on-corruption が含まれているため、 dm-verity が /usr パーティションで破損を検出すると、改ざんされたコードを実行する代わりにカーネルパニックが発生し、インスタンスが再起動します。 セキュアブートのバリエーション ユースケースによっては、Attestable AMI を定期的に再ビルドしたり、異なるアプリケーションの Attestable AMI に同じポリシーを適用したりする必要があります。AMI への変更は PCR4 測定値に反映されるため、AWS KMS キーポリシーを PCR4 値で制御すると、AMI を変更するたびにキーポリシーも更新しなければなりません。これが運用上望ましくない場合は、代わりにセキュアブートを有効にし、その結果得られる PCR7 測定値にポリシーを紐付けることができます。 PCR7 はセキュアブートの状態を表す測定値で、UKI の署名者のアイデンティティが含まれます。つまり、Attestable AMI のビルド時にセキュアブートを有効にし、事前に定義したキーで署名すれば、AWS KMS へのアクセスを PCR7 測定値のみで制御できます (ポリシーから PCR4 と PCR12 を除外)。これにより、Attestable AMI と、それを実行する EC2 インスタンスのフリート全体を 1 つのポリシーでカバーできます。 ブート時の信頼チェーン 次に、ブート時に信頼チェーンがどのように評価されるかを見ていきましょう。図 2 は、EC2 のブート中に NitroTPM、Attestable AMI、AWS KMS の間で信頼チェーンが確立されるまでの 8 つのステップを示しています。 図 2: Amazon EC2 インスタンス構成証明のブート時の信頼チェーン。Attestable AMI 内の systemd サービスが、ブート時に暗号化されたキーの取得、復号、EBS ボリュームのロック解除、マウント、データベースの起動を連携して実行します。 0. UEFI による UKI の測定 : ブート時に AWS Nitro ファームウェアが ESP から UKI をロードし、NitroTPM の PCR を拡張します。実行される UKI は PCR4 に、cmdline (すべてゼロ) は PCR12 に、セキュアブートキー (オプション) は PCR7 に反映されます。 1. 構成証明のリクエスト : network-online になると、NitroTPM が発行した構成証明ドキュメント (実際の PCR 値を含む) が kms-init に渡されます。 2. ユーザーデータの取得 : kms-init が インスタンスメタデータサービス (IMDS) のユーザーデータから暗号化されたキーを読み取ります。 3. AWS KMS での復号 : kms-init が、署名された構成証明ドキュメントと暗号文を AWS KMS に送信します。AWS KMS は実際の測定値と参照測定値を比較し、一致した場合は対称キー ( tmpfs にのみ保持) を返します。 4. luks-unlock : 対称キーを使用して、Linux の cryptsetup で LUKS EBS ボリュームのロックを解除し、暗号化されたボリュームを読み書きできるようにします。 5. cert-init (並列) : 同じキーを使用して、PostgreSQL の Transport Layer Security (TLS) 用のサーバー証明書バンドルを復号します。 6. data.mount : ステップ 4 でロックを解除した ext4 ボリュームを /data にマウントします。これは、 tmpfs (エフェメラル) 以外で唯一の書き込み可能なボリュームです。 7. postgresql : cert-init が用意した TLS 証明書を使用して起動します。 dm-verity で保護された nix store から実行され、 /data/postgresql に対して読み書きを行います。 ブート時に同じキーを TLS サーバーアイデンティティにも活用 次に、AWS KMS で保護された対称キーを使用して、ブート時に機密情報を管理する方法を見ていきましょう。 ブートチェーンで提供される対称キーは汎用的なものです。プロビジョニング時にこのキーで暗号化したアーティファクトであれば、同じ構成証明済みのブートで復号できます。リファレンス実装では、この特性を利用して、AMI の測定値に紐付けられた PostgreSQL 用の TLS サーバーアイデンティティもプロビジョニングしています。認証局 (CA)、サーバー証明書、サーバーのプライベートキーを tarball にまとめ、同じ対称キーで暗号化したうえで、データベースの暗号文とともに EC2 ユーザーデータに埋め込みます。 cert-init.service は、Attestable AMI 内でこのバンドルを tmpfs ディレクトリに復号します。PostgreSQL は clientcert=verify-full を強制した状態でポート 5432 で接続を受け付け、同じ CA によって署名された証明書を持つクライアントとの間で相互 TLS を確立します。 リファレンス実装のビルドとデプロイ リファレンス実装は、そのままエンドツーエンドで実行できます。 --secure-boot や --debug など、利用可能なデプロイオプションの詳細については Readme を参照してください。 リポジトリをクローンし、そのディレクトリに移動します。 git clone https://github.com/aws/nitrotpm-attestation-samples && cd nitrotpm-attestation-samples 十分な IAM 権限があることを確認します。必要な権限は、 Readme の「 Minimal IAM Privileges 」セクションに記載されています。 リポジトリ内で次のコマンドを実行します。AWS リソースがプロビジョニングされ、セキュアブートと secrets-manager を使用して、構成証明済みの LUKS 暗号化ボリューム上で PostgreSQL を実行する EC2 インスタンスが起動します。 cd nix/examples/postgres-kms ./scripts/e2e-test.sh --secure-boot --secrets-manager --authorize-my-ip --create-roles --no-cleanup クリーンアップ この例で作成したすべての AWS リソースを削除するには、次のコマンドを実行します。 ./scripts/clean.sh まとめ この記事では、Amazon EC2 インスタンス構成証明を使用して、ゼロオペレーターアクセスを実現する PostgreSQL 用の Attestable AMI を再現可能な形でビルドするプロセスについて説明しました。また、NitroTPM ベースのブート検証プロセスと、ブートに成功した後に暗号化された EBS ボリュームをマウントする方法についても詳しく解説しました。さらに、PCR 測定値を使用して AMI への変更を検出し、EC2 インスタンスのブートを阻止するとともに、改ざんされたコードが AWS KMS での復号に必要な権限を取得できないようにする方法も紹介しました。 さっそく nitrotpm-attestation-samples リポジトリをクローンし、ニーズに合わせてテンプレートをカスタマイズして、Attestable AMI によるデータ保護を始めましょう! 著者について David-Paul Dornseifer David-Paul は AWS の Confidential Compute and Systems Architect です。デジタル資産のカストディ、コンフィデンシャル推論、低レイテンシーの取引インフラストラクチャを専門としています。 Ben Liderman Ben 氏は Fireblocks のシステムアーキテクトです。コンフィデンシャルコンピューティングを活用して高価値なデジタル資産の運用を保護する、セキュアな金融インフラストラクチャの設計に携わっています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 8 月 11 日に公開された AWS Blog “ Amazon EC2 defenses against L1TF Reloaded ” を翻訳したものです。 AWS Nitro System および Nitro Hypervisor を使用する AWS のお客様のゲストデータが、「L1TF Reloaded」と呼ばれる攻撃によって危険にさらされることはありません。お客様による追加の対応は不要です。ただし AWS は、AWS の公開ドキュメントに記載されているとおり、インスタンス、エンクレーブ、または関数の境界を使用してワークロードを分離することを引き続き推奨しています。AWS Nitro System と Nitro Hypervisor は、この種の攻撃からの保護に役立つように設計されています。 研究論文「 Rain: Transiently Leaking Data from Public Clouds Using Old Vulnerabilities 」と、その講演「 Spectre in the real world: Leaking your private data from the cloud with CPU vulnerabilities 」では、L1TF Reloaded という攻撃が実証されています。この攻撃は、ハーフ Spectre ガジェット (half-Spectre gadget) と L1 Terminal Fault (L1TF) を組み合わせてゲストデータを漏洩させるものです。アップストリームの Linux/カーネルベース仮想マシン (KVM) や他のクラウドプロバイダーからはゲストデータを漏洩させることに成功していますが、 AWS Nitro System および Nitro Hypervisor を使用する AWS のお客様のゲストデータには影響しません。 Nitro Hypervisor が L1TF Reloaded を防げているのは、特定のパッチや事後的な緩和策によるものではなく、AWS がセキュリティに対してプロアクティブなアプローチを取っているためです。Nitro Hypervisor の基本的なセキュリティ設計原則は、この種の攻撃に対して強力な保護を提供します。特に重要なのが、 XPFO (eXclusive Page Frame Ownership) の概念 (文脈によっては プロセスローカル メモリ とも呼ばれます) を広範に活用したシークレットハイディング (secret hiding) の実装です。L1TF Reloaded は、一時的実行攻撃 (transient execution attack) における革新的な手法です。この攻撃は、一見すると緩和済みの脆弱性を脅威アクターが組み合わせることで、個々の要素の総和を超える新たな攻撃を生み出せることを示しています。この研究はすばらしいもので、実環境に適用可能な多層的なエンドツーエンドのエクスプロイトを構築しています。AWS はこの研究の一部をスポンサーとして支援しました。また、研究者の皆様の協力と協調的な情報開示に感謝いたします。以降では、公開された研究について詳しく解説します。 Nitro Hypervisor: セキュリティのための専用設計 Nitro Hypervisor は AWS Nitro System の基盤となるコンポーネントであり、セキュリティを最優先事項として一から設計されています。汎用オペレーティングシステムから発展してきた従来のハイパーバイザーとは異なり、Linux/KVM をベースとする Nitro Hypervisor は意図的に最小化されており、割り当てられた役割の遂行に必要な機能だけを備えた専用設計となっています。 Nitro Hypervisor の役割は、意図的に限定されています。Nitro Hypervisor は、Nitro Controller から仮想マシン (VM) の管理リクエストを受け取り、ハードウェアの仮想化機能を使用してメモリと CPU リソースを分割し、PCIe デバイスを VM に割り当てます。これらの PCIe デバイスには、Nitro ハードウェアが提供する物理機能 (PF) とシングルルート I/O 仮想化 (SR-IOV) の仮想機能 (VF) の両方が含まれます。例えば、EBS およびインスタンスストレージ用の NVMe や、ネットワーク用の Elastic Network Adapter がこれに該当します。さらに、サードパーティーのデバイス (GPU) も含まれます。重要な点として、Nitro Hypervisor では、従来のハイパーバイザーに存在する機能がカテゴリごと除外されています。ネットワークスタック、汎用ファイルシステムの実装、周辺機器のデバイスドライバーのサポート、シェル、対話型アクセスモードは一切ありません。このように不要な機能を徹底的に除外することで、リモートネットワーク攻撃やドライバーを悪用した権限昇格など、他のハイパーバイザーに影響しうる問題や攻撃ベクトルのカテゴリ全体を回避しやすくなります。 一時的実行の脆弱性の理解 Nitro Hypervisor の防御が L1TF Reloaded に有効である理由を理解するには、まず 2018 年に明らかになった一時的実行の脆弱性の基本を理解しておくことが重要です。現代の CPU は、アウトオブオーダー実行や、予測に基づく投機的実行を実装しています。これにより、操作が必要になる前、あるいはその操作を実行すべきかどうかを CPU が判断する前に操作を実行して、パフォーマンスを最適化しています。予測が誤っていた場合や、実行時のフォールトが発生した場合、CPU は最終的にこれらのエラーを検出し、投機的に計算されたアーキテクチャ状態への変更をすべてロールバックします。しかし、こうした「一時的実行」の痕跡は、CPU キャッシュに投機的に読み込まれたデータなど、マイクロアーキテクチャ状態に検出可能な形で残ります。その結果、サイドチャネル攻撃によってデータが漏洩する余地が生まれます。 ハーフ Spectre ガジェット: 不完全だが危険なコードパターン 従来の Spectre 攻撃には、シークレットデータへのアクセスと、サイドチャネルを通じたそのデータの送信の両方を行う、完全な「ガジェット」が必要です。これに対して研究者たちは、「ハーフ Spectre ガジェット」と呼ばれる、より弱いクラスのガジェットを特定しました。これは、投機的な境界外メモリアクセスを実行するものの、それだけで悪用可能になるための送信コンポーネントを備えていない、不完全な Spectre 類似のコードパターンです。 典型的な Spectre v1 ガジェットには、2 つの主要な要素があります。1 つ目は、シークレットデータを読み込む投機的アクセスです (例えば、 x = A[index] で index  が境界外である場合)。2 つ目は、サイドチャネルを通じてデータを漏洩させる送信メカニズムです (例えば、 y = B[64 * x]  のように、シークレット値に基づいたキャッシュパターンを生成するもの)。ハーフ Spectre ガジェットには、1 つ目の要素である投機的アクセスのみが含まれ、送信コンポーネントは含まれていません。 ハーフ Spectre ガジェットは単独では無害に見えるため、ハイパーバイザーを含むさまざまなソフトウェアに広く存在しています。これらのガジェットは通常、境界チェックを伴う配列インデックス操作から生じます。しかし、境界チェックの結果が確定する前の一時的実行のウィンドウでは、境界外アクセスが可能になります。ガジェットには、絶対型 (アクセスするアドレスを直接指定する) と相対型 (ベースアドレスからのオフセットを制御する) があり、一般的な配列インデックスのパターンにより、相対型ガジェットの方が多く見られます。L1TF Reloaded の重要な洞察は、ハーフ Spectre ガジェットは単独では無害であっても、L1TF のような他の脆弱性と組み合わせると危険になるという点です。脅威アクターは、ハイパーバイザー内のハーフ Spectre ガジェットをトリガーして任意のデータを L1 データキャッシュに投機的に読み込ませ、その後 L1TF を使用してキャッシュされたデータを抽出できます。これにより、「無害な」ハーフ Spectre ガジェットが、事実上完全なガジェットに変わります。 Intel L1TF: 投機的なアドレス変換の悪用 L1TF は、2018 年 1 月に発見され、2018 年 8 月に公開された、一時的実行の脆弱性の中でも重大なものです。この脆弱性は、Coffee Lake までの Intel プロセッサに影響します。これらのプロセッサは、一部の第 5 世代 EC2 インスタンスファミリーと、それより古いすべてのインスタンスタイプで使用されています。L1TF は、一時的実行中に無効なページテーブルエントリにアクセスした際に発生する、誤ったアドレス変換を悪用します。通常の動作では、present ビットがクリアされている、または予約ビットが設定されているページテーブルエントリ (PTE) に CPU が遭遇すると、アドレス変換は直ちに停止するはずです。しかし、L1TF の影響を受ける Intel プロセッサは、一時的実行中にこうした無効なページテーブルの状態を無視し、部分的に変換されたアドレスを使用します。対象データが L1 データキャッシュに存在する場合、本来はブロックされるべきアクセスであるにもかかわらず、CPU はそのデータを投機的に読み込み、後続の命令から利用できるようにします。この動作は、仮想化環境で特に問題になります。悪意のあるゲストオペレーティングシステムは、自身のページテーブルの present ビットを意図的にクリアして、ターミナルフォールトをトリガーできます。すると CPU は、通常のホストアドレス変換プロセスをスキップし、ゲストの物理アドレスを L1 データキャッシュに直接渡します。これにより、脅威アクターは、所有権や特権の境界に関係なく、システム上のキャッシュされた任意の物理メモリを読み取れる可能性があります。影響を受けるプロセッサにおいて、ソフトウェアで包括的に緩和するには、同時マルチスレッディング (SMT) の無効化、コンテキストスイッチごとの L1 データキャッシュのフラッシュ、拡張ページテーブル (EPT) の完全な無効化といった、コストの高い対策が必要です。これらのパフォーマンスへの影響は非常に大きいため、多くのシステムでは部分的な緩和策しか実装されていません。 L1TF Reloaded 攻撃: Spectre を使って緩和策の不備を悪用 この研究論文は、脅威アクターがハーフ Spectre ガジェットと L1TF を組み合わせることで、前述の緩和策が完全には実装されていないハイパーバイザーに対する強力な攻撃ベクトルを生み出せることを実証しています。この攻撃は、個別には緩和済みとみなされている脆弱性であっても、新しい方法で組み合わせれば依然として悪用できることを示しています。L1TF の緩和策である L1 データキャッシュのフラッシュやコアスケジューリングは、ゲスト間の攻撃の防止には役立ちますが、ゲストからホストへの攻撃を完全には緩和できません。L1TF Reloaded は、この点を突いた攻撃です。この攻撃は、SMT コア内で L1 データキャッシュを共有する論理コアにまたがって動作します。脅威アクターは、一方の論理コアでハーフ Spectre ガジェットをトリガーします。分岐予測器を意図的に誤学習させることで、ハイパーバイザーに境界外メモリへ投機的にアクセスさせ、機密データを共有 L1 データキャッシュに読み込ませます。同時に、もう一方の論理コアで L1TF を使用して、キャッシュされたデータを抽出します。 他の研究論文でも L1TF の悪用は実証されています が、この研究論文は、アップストリームの Linux/KVM や他のクラウドプロバイダーに対する多層的なエンドツーエンドの攻撃の実証に成功しました。著者らが実行した手順は次のとおりです。まず、既存のハーフ Spectre ガジェットを使用してホストのカーネルアドレス空間配置のランダム化 (KASLR) を突破し、ホストのアドレス変換機能を獲得しました。次に、ホスト上で実行されているすべてのプロセスを見つけ出し、被害者の VM を特定しました。さらに、ゲストの KASLR を突破してゲストのアドレス変換機能を獲得し、被害者の VM 内の init プロセスを特定しました。その後、init プロセスの子プロセスを列挙して nginx ウェブサーバーのプロセスを特定し、ゲストプロセスのヒープ内でプライベート TLS 証明書を見つけ出し、最終的にその証明書を漏洩させました。しかし、AWS インスタンスで同じ攻撃を試みたところ、著者らは重大な制約に直面しました。機密性のない一部のホストデータは漏洩させることができたものの、ゲストデータにはアクセスできなかったのです。著者らはその原因を「ハイパーバイザー内に存在する、被害者のデータをハイパーバイザーからアンマップする文書化されていない防御」と説明しています。この「文書化されていない防御」こそが Nitro Hypervisor によるシークレットハイディングの実装であり、この種の攻撃を防いだアーキテクチャ上の基本的な設計判断です。 シークレットハイディング: ハイパーバイザーのメモリアーキテクチャの再考 従来のハイパーバイザーの設計は、上位の特権レベルがそれより下位のレベルのすべてのメモリにアクセスできる、階層型の特権モデルに従っています。従来のシステムでは、最も高い特権レベルで実行されるハイパーバイザーが、正当な管理目的という名目で、すべての VM メモリにアクセスできます。しかし、この設計には脆弱性があります。脅威アクターがハイパーバイザーをだましてゲストデータに投機的にアクセスさせることができれば、そのデータはサイドチャネル攻撃によって抽出可能になってしまうのです。Nitro Hypervisor は、シークレットハイディングと呼ばれる手法によって、根本的に異なるアプローチを採用しています。ハイパーバイザーがすべての VM メモリにアクセスできる従来のモデル (図 1) に従うのではなく、ゲストデータがハイパーバイザーの仮想アドレス空間に存在しないようにしています。AWS は、VM メモリページをハイパーバイザーの仮想アドレス空間から取り除く (図 2) ことで、たとえ脅威アクターがハイパーバイザー内のガジェットをトリガーできたとしても、一時的実行攻撃によってゲストデータにアクセスされる可能性を排除しています。 図 1: VM1 のコンテキストにおける、緩和策のないハイパーバイザーのメモリビュー 図 2: VM1 のコンテキストにおける Nitro Hypervisor のメモリビュー。ゲストメモリはマッピングされておらず、アクセスできるのはアクティブなゲストの状態のみです。他のゲストの状態にはアクセスできません。 このアーキテクチャ上の設計判断により、L1TF、ハーフ Spectre ガジェット、その他の一時的実行の脆弱性のいずれによって Nitro Hypervisor で一時的実行が発生しても、漏洩しうるゲストデータがそもそも存在しません。これが、この種の脆弱性に対する障壁となります。Nitro Hypervisor がアクセスできるのは自身のデータのみであり、ゲストデータは分離され、アクセスできない状態に保たれます。AWS は、L1TF Reloaded そのものを正確に予測できたわけではありません。しかし、一時的実行の脆弱性が今後も発見され続けることはわかっていたため、AWS インスタンス上のゲストデータの抽出を阻止する多層防御の仕組みを構築しました。この設計判断は、Nitro Hypervisor の開発時にプロアクティブに行われたもので、ハイパーバイザーを悪用するゲストからホストへの攻撃を明示的に想定した AWS の脅威モデルに基づいています。AWS は、L1TF のような既知の脆弱性か、将来の未知の攻撃ベクトルかを問わず、脅威アクターが Nitro Hypervisor 内で一時的実行の脆弱性をトリガーする方法を見つけ出す可能性があると想定しました。そのうえで、こうした攻撃の影響範囲を当初から限定するようにシステムを設計しました。 メモリにとどまらず: ゲスト CPU コンテキストの保護 VM のスケジューリングやコンテキストスイッチの際には、汎用レジスタや浮動小数点レジスタの内容などのゲスト CPU コンテキスト情報を保存および復元する必要があります。ゲスト CPU コンテキストには、機密性の高い情報が含まれる場合があります。例えば、レジスタには、暗号鍵、アドレス空間配置のランダム化 (ASLR) を突破しうるメモリアドレス、アプリケーションがセキュリティのために依存しているその他のシークレットが含まれている可能性があります。従来のハイパーバイザーでは、ゲスト CPU コンテキストはハイパーバイザーからアクセス可能なメモリに保存されることが多く、一時的実行攻撃のもう 1 つの潜在的な標的となります。元の XPFO の実装では、メモリページにアクセスできるのはユーザー空間とカーネルのどちらか一方のみであり、両方がアクセスすることはできません。ただし、ゲスト CPU コンテキストはカーネルが排他的に所有しているため、保護の対象外です。Nitro Hypervisor は、XPFO の概念をゲスト CPU コンテキストにまで拡張しています。前述の図 2 に示すように、ゲスト CPU コンテキストは、プロセス固有のカーネル PTE によってのみマッピングされるメモリ (プロセスローカルメモリとも呼ばれます) に保存されます。このメモリは、所属するプロセスのコンテキストにおいてのみ、Nitro Hypervisor からアクセスできるように設計されています。そのため、たとえ脅威アクターが Nitro Hypervisor 内で一時的実行の脆弱性をトリガーできたとしても、他のゲストの CPU コンテキストにはアクセスできません。研究者たちもこの保護を確認しており、AWS の脅威モデルがゲストからホストへの攻撃を考慮していること、そしてシークレットハイディングが既存の L1 データキャッシュのフラッシュおよびコアスケジューリングと組み合わさることで、ゲストデータの漏洩を防いだことを指摘しています。シークレットハイディングに対するこの包括的なアプローチは、Nitro System の多層防御の理念を示しています。既知の攻撃ベクトルへの対策にとどまらず、 AWS は、ゲストデータの漏洩につながる潜在的な発生源を体系的に特定して保護しています 。これには、VM メモリとゲスト CPU コンテキストの両方が含まれます。 Xen へのシークレットハイディングの原則の適用 現在、AWS の Xen インスタンスの大部分は AWS Nitro System 上で実行されており、 Xen-on-Nitro によって Nitro Hypervisor のメリットを享受しています。AWS Xen Hypervisor 上で実行されるインスタンスファミリーについても、AWS は一時的実行攻撃から保護するために、同様の シークレット ハイディング の原則を実装しています。 多層防御: Nitro Hypervisor の実証されたセキュリティモデル L1TF Reloaded は、一見すると緩和済みの脆弱性を組み合わせて新たな攻撃ベクトルを生み出せることについての理解を大きく深めるものです。Rain 論文の研究者たちは、L1TF とハーフ Spectre ガジェットを連携させて、ハイパーバイザーからゲストデータを漏洩させる方法を実証しました。AWS は、研究者たちの取り組みを支援し、協力できることをうれしく思います。Nitro Hypervisor が L1TF Reloaded を防げているのは、特定のパッチや事後的な緩和策によるものではなく、高度な攻撃者からマルチテナントのクラウド環境を保護するために AWS が多大な投資を続けてきた結果です。この研究により、既知および未知の攻撃ベクトルに対する Nitro System のセキュリティモデルへの確信がさらに強まりました。AWS のプロアクティブなセキュリティアプローチには、多層防御の原則に基づいてシステムを一から設計することが含まれます。脅威の状況は今後も変化し続けます。それと同時に、Nitro Hypervisor や AWS のその他の製品およびサービスに組み込まれた多層防御の仕組みは、お客様が必要とするパフォーマンスと機能を維持しながら、今後も高度な攻撃から AWS のお客様を保護するのに役立ちます。 この記事に関するご質問やフィードバックがある場合は、 AWS サポートにお問い合わせ ください。 Ali Saidi Ali は AWS のバイスプレジデント兼 Distinguished Engineer です。ミシガン大学でコンピュータサイエンスおよびエンジニアリングの博士号を取得しています。2017 年に AWS に入社して以来、AWS Nitro System、AWS Graviton、EC2 インスタンスファミリーの設計と開発に注力しています。 Filippo Sironi Filippo は AWS の Sr. Principal Engineer です。ミラノ工科大学でコンピュータサイエンスエンジニアリングの博士号を取得しています。2015 年に AWS に入社して以来、AWS Nitro System、Nitro Hypervisor、および EC2 の Core、High Memory、高速コンピューティングインスタンスファミリーの設計と開発に注力しています。 Moritz Lipp Moritz は AWS の Sr. Security Engineer です。グラーツ工科大学でコンピュータサイエンスの博士号を取得しており、在学中はマイクロアーキテクチャ攻撃を専門としていました。2022 年に AWS に入社して以来、ハードウェアセキュリティの研究と安全なシステムアーキテクチャの開発を通じて、クラウドインフラストラクチャの保護に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさまこんにちは。自動車・製造インダストリーソリューションアーキテクトの 小川 です。10月に入っても関東は秋雨模様のお天気から徐々に秋晴れの日も増えてきましたね。こちらの「 月刊AWS製造 」ブログでは直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例や今後開催予定のイベントなどを毎月お届けしています。最近Amazonの独自チップ開発に関する記事やニュースが複数出ていたので、今月は製品設計開発領域でのAI活用に関して、ピックアップトピックとして触れさせて頂きます。 ピックアップトピック: Amazonの独自チップ開発とEDAツールベンダーとのコラボレーションに垣間見るAIネイティブ設計 Amazonは2015年1月に半導体設計開発を行うAnnapurna Labsをチームに加え、AWSのデータセンター ネットワーク や 仮想化基盤 、 Graviton や Trainium 、 Inferentia などの独自チップを内製で開発し利用・提供しています。これらのチップはチップ単位で外販しておらず、独自チップを社内で運用しドッグフーディングできているのは、大規模なインフラを運用しているAWSだからできるユニークな取り組みと言えます。顧客の機能要求をチップレベルで実装しAIチップのロードマップを形作ったストーリーなども こちらのAmazon News で触れられているので、ご興味ある方は参照ください。 EDAツールベンダーのSynopsysと組む狙い 先日 9/30に EDAツール大手のSynopsys社とAmazonが総額10億ドルにおよぶライセンス契約と双方の協業についてプレスリリース を行いました。この契約にはSynopsysが有するIPやソフトウェアプロダクトをAmazonが利用する契約に加えて、SynopsysがAWSのクラウド環境を使用して、EDAアプリケーションの開発スピードを早めたり、AIネイティブなエンジニアリングを目指す事で、双方のチームの生産性を上げることが掲げられています。 先端プロセスの半導体は1チップのトランジスタ数が 10 Billion を超える世界になっており、Amazonも公開しているものだと、 Graviton4のチップで 730億のトランジスタ を集積しています。このような巨大チップを開発するにはEDAを駆使し大量のコンピューティング能力を使ってシミュレーションする必要があり、人的にも物的にも開発リソースの逼迫が次世代チップの開発の妨げになっています。この壁を乗り越えるアプローチがAIネイティブなエンジニアリングであり、EDAツールベンダーとコラボレーションすることで、設計者は使い慣れた開発ツールの延長でAIを活用して開発を効率化できる機会を得られる可能性があります。 製造業の設計開発現場でのAI活用の現在地 製造業の設計開発現場ではエレキ設計のEDA、メカ設計のCAD、工学シミュレーションのCAE など各種ツールチェーンを用いて設計開発を行っています。ソフトウェア開発の領域ではAWSだと Kiro に代表されるコーディングエージェントの台頭によって AI活用が急速に進んでいますが、CAD、CAE、EDAなど各種アプリケーションを操作して開発を行う現場では、その特性上 エンジニアリング現場でのAI活用はユースケース毎に分けて活用されているというのが現在地です。 例えばシミュレーション結果を予測するAIサロゲートモデル、マニュアルドキュメントやナレッジを検索/要約して設計作業を支援するRAG、自然言語でCADやCAEのアプリケーションを操作するMCPなどの活用が挙げられます。これらはアプリケーションベンダー側でもAIの新プロダクトとして提供したり、既存CAD/CAE/EDAツールにAI機能を付加するなどの動きがあり、先のSynopsysのプレスリリースはこれらの流れを組むものです。かたや、複数ベンダーのツールチェーンをAIエージェントが横断的に連携処理させたり、自社のルールに則った設計内容になっているかAIにチェックさせたい、といった需要もよく聞かれ、これには独自にカスタムしたエージェントやMCPを用意したり、自社の設計データやドキュメントならびにツールチェーンのナレッジなどを加えたファインチューニングによる独自AIモデルを作成するようなアプローチが考えられます。AWSでは製品設計開発における AI活用のデモ 、 ワークショップ 、 情報発信 など数々行っていますので、チェックして頂き、気になるものがあれば近くのAWSメンバーに相談ください。 この分野はすさまじいスピードで進化しており、最近も空間認知能力をもつとされる GPT-6 Astra がリリースされた事で、吊るしの基盤モデルで3D設計も職人級の仕事ができてしまうようになる日もそう遠くないのかもしれません。 直近で開催予定のイベント 10/13 – 10/16 CEATEC 2026 JEITA 主催のデジタルイノベーションの総合展示会が幕張メッセで開催、AWSもブース展示を行います。AWSブースのテーマは「日本の担い手と、フィジカルAI社会を実現するAWS Japan 」です。安川電機様とコラボレーションした展示や、今回 CEATEC AWARDを受賞 した「AIエージェントがロボットを育てる ― 一行の指示から実機までをつなぐPhysical AI自律R&D基盤」など複数の展示を行う予定ですので是非AWSブースにお立ち寄りください。 11/7 JAWS FESTA 2026 年に一度、全国各地で開催されるJAWS-UGのお祭イベント。 JAWS-UG （ユーザーコミュニティ）主催 で、特定業種ではなく 横断的な技術テーマ が中心で、製造業「専用」のトラックやセッションはありませんが、スマート農業×AI/XR、IoT現場活用、設計書のAI活用、BCP、データ基盤 といった、製造業でも応用できるセッションが複数あります。 11/18 – 20 EdgeTech+2026 組込み・エッジ技術を中心にAI/IoT/セキュリティ等の最新技術を集めた、300社以上が出展する国内最大級のエッジテクノロジー総合展示会です。パシフィコ横浜で開催され、AWSは組み込み開発や自動車関連の講演を予定しています。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されています。 製造業でフィルタリングしたセッションカタログ の他、キーノートや展示などでも製造業に関わるトピックが例年存在します。オンラインで視聴できる内容もありますので、是非チェックしてください。 製造関連ブログのご紹介 9/2 Building a Production AI Agent on AWS: A Six-Pillar Walkthrough 「PoC では動いたエージェントが、本番にはなかなか載らない」。その原因を、作る・試す・動かす・守る・観測する・統制する（Build / Test / Run / Secure / Observe / Govern）の 6 つの柱に分解して解説した記事です。走る例として自動車製造工場の部品在庫エージェントを使い、Amazon Bedrock AgentCore や Bedrock Guardrails、Cedar によるポリシー制御を組み合わせています。エージェントの試作は済んだものの、本番運用に向けた守りと統制の設計をこれから固めたい方に参考になります。 9/9 Manage ESG data and simplify Sustainability reporting with Amazon Quick サステナビリティ報告の難所は、設備管理・調達・カーボン会計など各所に散らばった情報を監査に耐える開示へまとめ上げる点にあります。本記事は Amazon Quick をサステナビリティ情報のハブとして、要件分析からレポート生成までを 5 つのフェーズで組み立て、ESRS や CDP など複数フレームワークへ一元データからマッピングする構成を示します。報告フレームワークへの対応に追われている方の負担を軽くするヒントになります。 9/10 How Apollo Tyres Uses AI-Driven APC for First Time Right Tyre Extrusion タイヤの押出ラインでは、レシピを変えるたびに規格外の材料が出る立ち上げが発生し、1 日 30〜35 回の段取り替えを行う現場では総生産量の 5〜6% を占めていました。Apollo Tyres 様は、エッジで動く予測モデルと閉ループの APC 制御で最適な立ち上げ速度を自動付与し、立ち上げ時の手直しを約 26%、安定化時間を約 40% 削減、月あたり約 20 時間の生産時間を回収しました。Apollo Tyres Ltd の Harsh Vardhan 氏との共著です。段取り替えの多いプロセス系ラインで歩留まりとスループットの両立を狙う方におすすめです。 9/10 Reducing paint shop downtime with Industrial Data Fabric on AWS システムごとにデータが閉じていると、ライン停止の原因を SCADA や MES、停止ログの突き合わせで探すことになり、根本原因分析に 2〜4 時間かかることもあります。Mahindra 様の塗装工場では、分断データを Industrial Data Fabric で文脈化したナレッジグラフ（Amazon Neptune）に統合し、Amazon Bedrock AgentCore 上の 2 つのエージェントが上流の原因まで自然言語で提示します。平均修復時間（MTTR）を 20%、他工場への横展開時間を 30% 削減しました。同じ仕組みを複数拠点へ広げたい方の設計の参考になります。 9/27 Building AI-augmented B-pillar DFMEA on AWS: Architecture, multi-agent orchestration, and implementation 設計 FMEA（DFMEA）は品質工学の中核ですが、手作業では潜在的な故障モードを見落としやすい課題があります。本記事は自動車の B ピラーを題材に、オントロジーで表現した知識グラフとマルチエージェントのオーケストレーションで、故障モードの網羅性とトレーサビリティ（ISO 26262 / IATF 16949）を高める実装例をサンプルコードとともに示します。確信度が低い場合は人に差し戻す設計で、自律化と品質保証を両立します。FMEA の網羅性やトレーサビリティに課題を感じる設計・品質部門の方に向いた内容です。 9/30 【開催報告】組み込みソフトウェア開発でも AI エージェントは活用できる ─ 日立産業制御ソリューションズ様とのワークショップ 日立産業制御ソリューションズ様との共催ワークショップでは、既存の組み込みコード（HVAC 制御システム）を題材に、コードの読み解きから仕様の捉え直し、設計、実装、テストまでを AI コーディングエージェント Kiro で体験しました。指示を GitLab の Issue に書き、エージェントが経過をコメントに書き戻すことで、人が判断した箇所がチケットに残る点が長期保守向きです。2 回のワークショップに開発者 102 名が参加しました。既存コードの保守・仕様化という上流工程で AI を活用した効率化を進めたい方におすすめです。 製造関連の主要なサービスアップデート 9/18 Amazon Bedrock AgentCore の新しい AgentCore Runtime が一般提供開始 エージェント実行基盤のサーバーレス環境が刷新されました。セッション中に使われていないメモリを回収する弾力的なメモリ管理と、イメージサイズによらず一定の高速なコールドスタートが特長です。現場支援や保全のエージェントを本番運用する際のコスト最適化につながります。東京リージョン（ap-northeast-1）でも利用できます。ピックアップトピックで触れたエージェントの本番化を下支えする機能です。 9/18 Amazon SageMaker HyperPod Inference Gateway HyperPod 上での大規模言語モデル推論に向けた、Kubernetes ネイティブなルーティング層です。KV キャッシュの使用率やキューの深さといった実シグナルに基づいてルーティングし、初回トークンまでの遅延を最大 82% 削減します。大規模な産業向け AI 推論基盤を運用する際に関係します。 9/26 Amazon CloudWatch Omni アプリケーションと AI エージェントを単一の画面で観測できる新しいオブザーバビリティ機能です。OpenTelemetry ベースで既存のテレメトリをそのまま取り込み、サービスの自動検出や依存関係のマッピングを提供します。前述のエージェントの可観測性（Observe の柱）を実装する際の選択肢になります。 9/26 Amazon EventBridge の強化されたカスタムイベントバス 組織をまたいだイベント駆動アプリケーション向けに、カスタムイベントバスが強化されました。AWS RAM 経由で複数アカウントが共有できる集中バス、順序保証、コンテンツベースの重複排除などに対応します。工場やサプライチェーンをまたぐイベント連携の基盤として活用できます。 最後まで読んでいただきありがとうございました。 季節の変わり目で寒暖差疲労を起こしやすい時期ですので、風邪などお召しにならないよう体調管理に気をつけてお過ごしください。また来月も 月刊AWS製造ブログ でお会いしましょう！ 著者について 小川 貴士 (Takashi Ogawa) 国内システムインテグレーターでインフラエンジニアとして従事した後、HPCソリューションアーキテクトとしてAWSに入社。現在は自動車・製造業にフォーカスするインダストリーソリューションアーキテクトとして、主にR&D部門のお客様のDXをご支援しています。

「フィジカル AI 開発支援プログラム by AWS ジャパン」第 2 期の応募受付を開始 AWS ジャパンは2026年 10 月 より、「フィジカル AI 開発支援プログラム」第2期の応募受付を開始いたします。本プログラムは AWS 上で Vision-Language-Action (VLA) をはじめとしたロボット基盤モデル*1 等を開発する、日本に法人または拠点を持つ企業・団体を支援します。データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまでの一連のパイプライン構築を支援し、AI のロボティクスへの活用を推進することを目指します。本プログラム採択者には、フィジカル AI 領域スペシャリストによる技術支援、コスト最適化支援、ロボティクス・⽣成 AI コミュニティ形成、Go-to-Market ⽀援を提供します。 *1: その要素技術として必要なVision Language Model（VLM：視覚言語モデル ) や、世界モデルなど周辺技術の開発もスコープに含みます。 プログラム内容 「フィジカル AI 開発支援プログラム by AWS ジャパン」第2期は、ロボット基盤モデル等を開発する企業・団体の状況に応じて、主に以下のサポートを提供します。 フィジカル AI 領域スペシャリストによる技術支援 ： ロボット基盤モデル開発支援（サンプルコード提供含む）、AWSアーキテクチャガイダンス、計算資源確保サポート コスト最適化支援　アーキテクチャ設計に応じた最適なコストのご提案 ロボティクス・生成AI コミュニティ形成 – 勉強会などによる実践例や知見の共有、参加企業・エンジニア間の交流・情報交換 Go-to-Market (GTM) 支援 – モデル開発企業とロボット導入企業、導入パートナーご紹介も含める、ビジネスマッチング機会提供、登壇機会のご提供 プログラムスケジュール 2026 年 11 月 16 日（月） : 応募締め切り ※ 11月中目処に選考結果を通知します。 2026 年 12 月初旬から 4月まで : 開発支援期間 同期間内で AWS から上記 のサポートを提供致します。 2027 年 4 月中 : 本プログラムの成果発表会を開催 応募概要 プログラム対象者 ロボット基盤モデルの開発を中心に、AI のロボティクスへの活用を推進することを目指す日本に法人または拠点を持つ企業・団体。Vision-Language-Action (VLA) モデル等の開発企業・団体を想定しています。 検証環境を持つ企業 (ロボットを現場で扱っている企業) が望ましいですが必須ではありません。 応募〜選考手続き 2026 年 11月 16 日（月）まで応募を受け付け、選考を行います。 応募いただいた中から、技術的観点、ビジネス的観点、それらの実現性及びインパクト等、総合的に見て選考させていただきます。 11月中を目処に選考結果を通知いたします。 応募方法 本プログラムへの応募を希望される企業・団体様は、 応募フォーム よりご連絡ください。 応募フォームのご提出をもって応募の受付とさせていただきます。 なお、フィジカル AI の社会実装、企業間の連携、フィジカル AI 向けモデルの実証環境の提供など Go-to-Market に関心のある企業の方は、AWS ジャパン生成 AI 実用化推進プログラムのモデル活用コースにご応募ください。 応募にあたりご不明な点がございましたら、事務局メールアドレス：aws-jp-generative-ai-acceleration-program@amazon.co.jp までお問い合わせください。 よくあるご質問（FAQ） 1.フィジカル AI 開発支援プログラムは AWS ジャパン独自のプログラムですか はい、AWS ジャパンが日本に法人または拠点を持ち、ロボット基盤モデル等のフィジカル AI を開発する企業・団体に向けて実施するプログラムです。 2. AWS ジャパン生成AI実用化推進プログラムとは別のプログラムですか？ AWS ジャパン生成 AI 実用化推進プログラムの1コースです。 3. フィジカル AI 開発支援プログラムの参加者は何を得られますか？ 本プログラムでは フィジカル AI 領域スペシャリストによる技術支援、コスト支援、 ロボティクス・生成AI コミュニティ形成、 GTM支援等のサポートを提供します。 4. フィジカルAIでAWSと取り組む利点は何ですか？ 以下の取り組みで用いられたものを含む AWS サービスの利用と、それに基づくお客様のワークロード支援経験です。 1. 日本における生成 AI 基盤モデル開発支援の実績 (2023年の AWS LLM 開発支援プログラム、それに続く経済産業省 GENIAC や、生成 AI 実用化推進プログラムなど)、 2. フィジカル AI の一分野である自動運転開発での AWS 利用実績、 3.Amazon でのロボティクス導入と AI 活用の実績 5. 何社が採択されますか？またどんな基準で選考を行いますか？ 最大で数十社の参加企業・団体を採択いたします。応募いただいた中から、技術的観点、ビジネス的観点、それらの実現性及びインパクト等から総合的にみて選考します。 6. 対象の企業や団体に制限、条件などありますか？ 対象の条件は、日本に法人または拠点を持ち、ロボット基盤モデル等の開発を中心に、AI のロボティクスへの活用を推進することを目指す企業・団体であることです。これには、スタートアップ企業から大企業まで、また大学や研究機関まで、広く含まれます。本プログラムに参加いただくにあたっては、AWS アカウントが必要となります。なお、以下に該当する企業・団体はご応募いただけません。 違法行為、または、AWS Acceptable Use Policy 違反のあった企業・団体 Amazon の関連会社 米国政府、欧州連合、若しくはその加盟国またはその他適用ある政府当局が発動した制裁措置の対象者 7. 既に Vision-Language-Action (VLA) モデル開発を進めている企業・団体も応募できますか？ はい、ご応募いただけます。例えば、現在まさに VLAモデル 開発を行っている最中であったり、既に開発した VLA モデルを所有しているものの、本プログラムを通じてより実践的な VLAモデル を作りたいといった方も歓迎です。 8. 第1期（2026年1月～8月）に申し込んだ企業・団体も応募できますか？ はい、ご応募いただけます。

これまで、管理対象デバイスでエンタープライズユーザーが Kiro にどの方法でサインインするかを制御する手段はありませんでした。組織として IAM Identity Center の利用を必須にしていても、ユーザーは個人アカウント（Google、GitHub、Builder ID）で Kiro にサインインできてしまっていました。 Kiro では、利用できるサインイン方法を管理者が決められるようになりました。ユーザーには組織が許可した選択肢だけが表示されます。 管理者向けの新しい制御 サインイン制御を使うと、管理者は次のことができます。 サインイン方法を制限する : 組織がサポートする選択肢だけを表示し、それ以外は非表示にします。 IAM Identity Center の情報を事前入力する : ユーザーがスタート URL やリージョンを調べる必要がなくなります。 ヘルプリンクを追加する : サインイン画面から組織の IT サポートページへ直接案内できます。 デバイスコードフローを有効化または無効化する : リモートマシンのようにブラウザがない環境からのサインインを、Kiro コンソールから直接管理できます。 ユーザーには管理者が許可したものだけが表示されます。ユーザーが制限を回避しようとした場合、Kiro はそのサインインを拒否します。 仕組み 管理者はサインインのルールを managed-settings.json に定義します。これは管理者権限で保護された設定ファイルで、Kiro が各マシンで読み込みます（詳細は ドキュメント を参照してください）。これらの制御は、Kiro IDE と Kiro CLI のどちらから開始したサインインにも適用され、 device flow も対象です。 例: サインインを IAM Identity Center のみに制限する 次の設定は、ユーザーのサインイン方法を IAM Identity Center に限定し、組織のスタート URL とリージョンを事前入力したうえで、組織の IT ヘルプページへのリンクを追加します。 { "rules": [ { "capability": "signin_method", "effect": "deny", "exclude": ["idc"] } ], "settings": { "idc_start_url": "https://my-org.awsapps.com/start", "idc_region": "us-east-1", "signin_help_url": "https://it.example.com/kiro-help" } } このルールは、 idc （IAM Identity Center） 以外 のすべてのサインイン方法を拒否します。ユーザーのサインイン画面には「Your organization」の選択肢だけが表示されます。 idc_start_url と idc_region は Identity Center のフォームに事前入力されるため、ユーザーが詳細を手入力する必要はありません。 signin_help_url は IT ヘルプページへのリンクを追加し、サインインで行き詰まったユーザーがサインイン中に参照できるようにします。 サインイン方法のリファレンス 管理者ルールでは、 deny に exclude （許可リスト）または match （拒否リスト）を組み合わせて使います。特定の方法だけを拒否して残りを利用可能にしておくには、 match を使います。 { "capability": "signin_method", "effect": "deny", "match": ["social"] } 名前 サインインの選択肢 idc Your organization（AWS IAM Identity Center） builder_id AWS Builder ID google Google github GitHub social Google と GitHub（省略形） 設定のリファレンス 以下はトップレベルの settings キーの下に追加します。いずれも省略可能です。 設定 内容 idc_start_url IAM Identity Center のスタート URL を事前入力します。 https:// で始まる必要があります。 idc_region IAM Identity Center のリージョンを事前入力します。 idc_start_url と組み合わせた場合のみ使われます。 signin_help_url サインイン画面に IT ヘルプページへのリンクを表示します。 https:// で始まる必要があります。 サインイン画面以外にも、管理者は Kiro コンソールからデバイスコードフローを直接有効化または無効化できます。 提供状況 サインイン制御は、Kiro IDE 1.2 および Kiro CLI 2.29.0 以降で、米国東部（バージニア北部）および欧州（フランクフルト）リージョンで利用できます。この機能を使うには、ユーザーがこれらのバージョン以降にアップグレードする必要があります。詳細は ドキュメント をご覧ください。 この記事は Kiro ブログの Introducing improved enterprise sign-in controls を翻訳したものです。

本ブログは 2026 年 10 月 12 日に公開された AWS Blog “ GuardDuty Extended Threat Detection has added five new indicators to surface attack sequences ” を翻訳したものです。 Amazon GuardDuty 拡張脅威検出 は、弱い GuardDuty シグナルの組み合わせが信頼性のしきい値を超えると、それらを相関付けて、重要度が Critical の単一の攻撃シーケンスの検出結果にまとめます。2026 年 5 月 20 日から、攻撃シーケンスに 5 種類の新しいインジケーター ( MALICIOUS_PACKAGE 、 MISCONFIGURATION 、 REACHABILITY 、 SENSITIVE_DATA 、 VULNERABILITY ) が付与されるようになりました。詳細については、「 Document history for Amazon GuardDuty 」および「 Attack sequence finding details 」を参照してください。 これらのインジケーターの情報源は、 Amazon Inspector 、 Amazon Virtual Private Cloud (Amazon VPC) Reachability Analyzer 、 Amazon Macie 、そして AWS Security Hub を通じて提供されるポスチャデータです。これらのサービスを既に別の目的で利用しているお客様もいるでしょう。今回のアップデートにより、拡張脅威検出はこれらのサービスのシグナルを攻撃シーケンスの検出結果に取り込むようになりました。この記事は、前提条件となるサービスを既に利用しているチーム向けの運用ガイドです。新しいインジケーターが検出結果にどのように表示されるか、リリース後のデータから何がわかるか、そしてインシデント対応ワークフローにどう組み込むかについて説明します。これらのインジケーターにより、拡張脅威検出はアカウント内で最も優先すべきシグナルを判断しやすくなります。その結果、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) のランタイムアクティビティをモニタリングするアクティブディフェンス戦略の一環として、ワークロード領域でより信頼度の高い検出結果が得られます。 新しいインジケーターの概要 GuardDuty におけるシグナルとは、GuardDuty が不審なアクティビティを探す際に評価するあらゆるイベントを指します。弱いシグナルとは、それ単体では脅威を明確に示さないシグナルのことで、5 つの新しいインジケーターはこれに該当します。例えば、ホスト上で Common Vulnerabilities and Exposures (CVE) が 1 件検出されたとしても、それは脆弱性が存在することを示すだけで、攻撃者がその脆弱性を悪用していることを示すわけではありません。次の表に示すように、これらの検出結果は、GuardDuty が既に追跡している不審なアクティビティのシグナルと相関付けられることで、初めて価値を発揮します。 インジケーター ソース 示される内容 VULNERABILITY Amazon Inspector Common Vulnerability Scoring System (CVSS) の重要度と Exploit Prediction Scoring System (EPSS) の悪用可能性スコアを含む CVE のリスト。 MALICIOUS_PACKAGE Amazon Inspector Amazon Inspector の MAL-* パッケージインジケーター。Amazon Inspector による脆弱性のスコアリング方法の詳細については、「 Amazon Inspector Security Research 」を参照してください。 REACHABILITY Amazon VPC Reachability Analyzer ホストまたはクラスターがインターネットから到達可能かどうか MISCONFIGURATION AWS Security Hub のコントロール (ポスチャ管理) リソースの設定が、AWS または 業界のベストプラクティス に沿っていないこと。例えば、IMDSv1 が有効なままになっている、管理者ポリシーの権限が過剰である、パブリックにアクセス可能な Amazon Simple Storage Service (Amazon S3) バケットがある、などです。 SENSITIVE_DATA Amazon Macie リソース内で機密データと思われる情報が検出されたこと。 これら 5 つの値は、GuardDuty の AWS マネジメントコンソールで攻撃シーケンスの検出結果を開いたときの [インジケーター] タブと、 GetFindings の JSON ファイルに表示されます。 図 1: 攻撃シーケンスの検出結果の [インジケーター] セクション VULNERABILITY インジケーターには EPSS が含まれるため、ここで EPSS について補足しておきます。「 FIRST EPSS overview 」によると、EPSS スコアは、公開済みの CVE が今後 30 日以内に実際の環境で悪用される確率を 0～1 の範囲で表したものです。EPSS は CVSS を置き換えるものではありません。CVSS が脆弱性本来の重要度を表すのに対し、EPSS は近いうちに悪用される可能性の高さを表すため、インシデント対応ではより役立つ数値となります。 前提条件 インジケーターにデータを反映させるには、次の AWS サービスを有効にしておく必要があります。 Amazon Inspector (Amazon EC2 および Amazon EKS で有効化): VULNERABILITY と MALICIOUS_PACKAGE に対応します。 AWS Security Hub : AWS Foundational Security Best Practices に基づいて MISCONFIGURATION を提供します。 Amazon VPC Reachability Analyzer (本番環境の VPC で有効化): REACHABILITY に対応します。 GuardDuty Runtime Monitoring (Amazon EC2、Amazon ECS、Amazon EKS で有効化): 生成されるすべてのシグナルが、相関付けの起点 (アンカー) になり得ます。 Amazon Macie : SENSITIVE_DATA を提供します。 弱いランタイムシグナルの強化 プロセスの呼び出し、ポッドでの exec、システムコールのパターンなどのランタイムシグナルは、ノイズが多くなることがあります。既知の攻撃ツールのパスに一致しないランタイムシグナルは単体では重要な意味を持たず、リソース状態のコンテキストがなければ、通常は重要度が Critical の攻撃シーケンスとなるしきい値に達しません。 新しいインジケーターは、この欠けていたコンテキストを補います。弱いランタイムシグナルが観測されたホストに、優先度の高いパッチ未適用の CVE、既知の悪意のあるパッケージ、IMDS の設定ミス、インターネットからの到達可能性が併存する場合、拡張脅威検出はそれらをまとめて、高い信頼度で重要度が CRITICAL の単一の攻撃シーケンスに昇格させます。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。このリソース状態のコンテキストを加えることで、弱いシグナルが対応可能なアラートへと変わります。 実際に、ランタイムプロセス領域では新規の攻撃シーケンスの検出結果が大幅に増加し、優先順位付けされたランタイムプロセスの攻撃シーケンスのおよそ 4 件に 1 件を占めるまでになりました。一方、ネットワークベースの侵害の痕跡 (IOC) 領域ではほとんど変化はありませんでした。リリース後 1 週間で、このパターンは多くのお客様のアカウントで確認されています。従来は弱く相互に関連のない複数の検出結果としてばらばらに表示されていた攻撃シーケンスが、重要度が CRITICAL の単一の検出結果として表示されるようになったのです。 例: Amazon EKS で新規に検出された攻撃シーケンス 追加のインジケーターによって拡張脅威検出がどのように改善されたかを説明したところで、これらのインジケーターがどのような価値をもたらすかを具体的な例で見ていきましょう。ここでは、Amazon EKS クラスターで実際に観測されたシナリオを分析します。このアクティビティは 8 日間にわたって発生し、11 件の異なる GuardDuty の検出結果が生成されました。 図 2: 拡張脅威検出がシグナルを相関付ける前の EKS クラスターのアクティビティの概要 図 2 に示すように、GuardDuty が 8 日間にアクティビティ領域で観測したのは、55 件の EKS_AUDIT_LOGS シグナル (ポッドでの exec、ロールの引き受け、 AssumeRoleWithWebIdentity の呼び出し) と、18 件の検出結果レベルのシグナルでした。これらはすべて、198.51.100.69 という単一の外部 IP アドレスから発生していました。この IP アドレスから、同じ EKS クラスターに対して 4 つの異なる AWS Identity and Access Management (IAM) アイデンティティによる認証が行われていました。ワーカーノード上のランタイムアクティビティは、既知の攻撃ツールのパスに一致するプロセスがなく、実行プロファイルのフラグも立たなかったため、ありふれたものに見えました。リリース前の相関ロジックでは、このシーケンスを検出するには EKS_MALICIOUS_PROCESS ルールが発動する必要がありました。このルールの発動には、悪意のある exec パスか、異常で疑わしいツールのプロファイルのいずれかが必要です。今回のアクティビティにはどちらも該当しなかったため、相関付けられた攻撃シーケンスの検出結果は生成されませんでした。 新しい GuardDuty 拡張脅威検出のインジケーターによって、この EKS の例に追加された情報は次のとおりです。 MALICIOUS_PACKAGE (クラスター上): Amazon Inspector の識別子 MAL-2022-4933 が検出されています。 VULNERABILITY (Amazon Inspector の全出力、クラスター上): 合計 42 件の CVE があり、そのうち 33 件が CVSS で CRITICAL と評価されています。 クラスター上: CVE-2022-1471 (SnakeYAML のデシリアライゼーション、EPSS 0.94)、CVE-2024-4577 (PHP-CGI の引数インジェクション、EPSS 0.97)、CVE-2024-34351 (Next.js の SSRF)、CVE-2025-29927 (Next.js の認証バイパス)、CVE-2023-44487 (HTTP/2 Rapid Reset)、CVE-2022-37434 (zlib のヒープオーバーフロー、EPSS 0.92) を含む 12 件の CVE があります。 5 つのワーカーノード全体: 合計 379 件の CVE があり、そのうち 68 件が Amazon Inspector によって CRITICAL と判定されています。 REACHABILITY : クラスターの API エンドポイントがインターネットから到達可能で、5 つのワーカーノードのうち 3 つもインターネットから到達可能です。 MISCONFIGURATION (EC2 IMDS): 5 つのワーカーノードすべてで、引き続き IMDSv1 にアクセスできる状態になっています。 これらの追加インジケーターを考慮すると、この一連のアクティビティは単一の AttackSequence:EKS/CompromisedCluster の検出結果として表示されます。重要度は CRITICAL で、データが反映された 4 つのインジケーターすべてが [インジケーター] タブに表示されます。また、 MITRE ATT&CK® の Initial Access (External Remote Services)、Discovery、Persistence へのマッピングも示されます。 図 3: 攻撃シーケンス内の新しい脆弱性インジケーター この検出結果には、ワーカーノードレベルで 100 件を超える Amazon EC2 の CVE が記載されています。CVSS が CRITICAL のものが 1 件、 HIGH のものも多数ありますが、EPSS スコアが低いため、ほとんどは脆弱性の優先度が LOW です。GuardDuty が優先度の高いものを強調表示するため、100 件を超える検出結果を精査してどれから対処すべきかを判断する必要はなく、最も効果の高い箇所に対応作業を集中できます。 例: 暗号資産マイニングと脆弱なホスト 2 つ目の例では、EC2 インスタンスグループのケースを取り上げます。このケースでは、GuardDuty は暗号資産マイニングを示す有力なネットワークベースの検出結果を既に得ていましたが、新しいインジケーターが修復に役立つ追加のコンテキストを提供したことで、インシデント対応を迅速化できました。 図 4: EC2 インスタンスに対する暗号資産マイニング攻撃 複数の EC2 インスタンスが既知の暗号資産マイニングの宛先と通信しており、この宛先は脅威インテリジェンスによって mining/misc としてフラグ付けされていました。ネットワーク IOC の証拠は、それ単体でも十分に強力なものでした。 新しいインジケーターによって追加された観測内容 : VULNERABILITY により、関与した 3 つのインスタンスのうち 2 つで、EPSS が約 0.9 の CVE-2007-4559 (Python tarfile) が示されました。 結果 : AttackSequence:EC2/CompromisedInstanceGroup の検出結果を基に、「 宛先 IP のブロック 」にとどまらない対応が可能になりました。暗号資産マイニングツールが侵入に悪用したと考えられる脆弱性と、それを修復するパッチが示されるため、アウトバウンド接続を遮断するだけでなく、根本的な侵入経路に対処できます。 GuardDuty は EC2 インスタンスグループで暗号資産マイニングが行われている強力な証拠を得ていたため、この攻撃シーケンス自体は脆弱性のコンテキストがなくても生成されていたはずです。ただし、コンテキストが増えることで、トリアージを迅速に行えます。 リリース後 1 週間のサンプルで観測された侵害の痕跡 次の CVE (EPSS スコアは観測当時の値) は、リリース後の最初の 1 週間に新しい拡張脅威検出のインジケーターが付与されたお客様のアカウントのホストで、各インジケーターの検出結果が生成された時点で観測されたものです。EPSS スコアは特定時点の値であるため、今後の検出結果に表示される CVE の優先度は、ここに示す値ではなく、その時点の EPSS に基づきます。 CVE-2024-4577 – Windows 上の PHP-CGI の引数インジェクション。EPSS 0.97 以上。 CVE-2022-1471 – SnakeYAML のデシリアライゼーション。EPSS 0.94。CVSS は Critical。 CVE-2022-37434 – zlib のヒープバッファオーバーフロー。EPSS 0.92。 CVE-2007-4559 – Python tarfile のパストラバーサル。2026 年時点でも EPSS は 0.9 以上。 CVE-2025-29927 – Next.js の認証バイパス。Node ベースのウェブ層で頻繁に検出。 CVE-2024-34351 – Next.js の SSRF。 CVE-2023-44487 – HTTP/2 Rapid Reset。 ランタイムモニタリングでは、侵害されたホストから回収されたマルウェアやツールのアーティファクトに関連する弱いシグナルが検出されました。 HackTool ファミリーの Linux/frp : Fast Reverse Proxy の亜種で、コマンドアンドコントロールトンネルとして使用されていました。Amazon EKS ワーカーノード上では、多くの場合 kuboard-agent や kuboard-agent-server というバイナリに偽装されていました。また、 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/.../usr/bin/ 配下で、コンテナスナップショットのパスとの一致も観測されました。frp バイナリはコンテナイメージ内とノード上の両方に存在するため、パッチが適用されていない AMI からノードを再構築するだけでは修復として不十分です。 Burp Collaborator のアウトオブバンドのコールバックホスト名が *[.]oastify[.]com 配下で見つかり、パターン <35-char base32>[.]oastify[.]com に一致していました。これらは同じ EKS シーケンス上で frp と同時に観測されており、共有インフラストラクチャ上で 2 つ目のツールまたは別のアクターが活動していた可能性が高いと考えられます。 Amazon Inspector の悪意のあるパッケージインジケーター MAL-2022-4933 が、Amazon EC2 と Amazon EKS の両方のコンテキストで検出されました。 上記のツール関連のシグナルと相関していたアイデンティティとアクセスのパターンは次のとおりです。 単一の外部送信元 IP から、短期間のうちに Amazon EKS、Amazon ECS、Amazon EC2 の別々の領域にまたがって、人間が使用する複数の異なる IAM アイデンティティによる認証が行われていました。これは、新規に検出されるようになった Amazon EKS プロセス関連のクラスで最も多く見られたアイデンティティのシグネチャです。 これらのインジケーターを活用した攻撃シーケンスへの対応 新しいインジケーターによって、既に発生した攻撃シーケンスに対するインシデント対応のランブックが変わるわけではありません。新しいインジケーターが意味を持つのは新規の検出結果であり、それらの検出結果は、ランタイムモニタリング関連のシグナルが強化された領域に集中しています。新規の検出結果には、次のように対応してください。 シーケンスに緊急に対応してください 。 MALICIOUS_PACKAGE と優先度の高い VULNERABILITY が示されている場合、そのホストは侵害されるリスクにさらされてきただけでなく、現在もさらされています。露出しているリソースを封じ込め、脆弱性を修復してください。また、攻撃者にさらされた可能性があるすべての IAM 認証情報、 インスタンスプロファイル 、 IAM Roles for Service Accounts (IRSA) にバインドされたロール をローテーションしてください。 EPSS で重み付けした優先度に基づいてパッチを適用してください 。CVSS の値だけで判断しないでください。検出結果に含まれる優先度の高い VULNERABILITY リストは、既に EPSS の高い CVE に絞り込まれています。 パブリックなリソースを隔離してください 。 REACHABILITY インジケーターで示されたリソースが対象です。悪用可能な脆弱性があり、インターネットから到達可能なホストは、修復のために隔離する必要があります。 さらに詳しい対応方法については、「 Remediating detected GuardDuty security findings 」の修復手順と、GuardDuty の検出結果とアカウントを AI で分析するセキュリティ分析機能である GuardDuty Investigation を参照してください。 まとめ GuardDuty 拡張脅威検出は、セキュリティチームが特に支援を必要とすることが多いランタイムワークロード領域 (Amazon EC2、Amazon ECS、Amazon EKS) で、信頼度の高い攻撃シーケンスの検出結果をより多く提供できます。これは、GuardDuty のアクティビティシグナルと、他の AWS サービスから得られるリソース状態のコンテキストを組み合わせることで実現しています。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。拡張脅威検出は、こうした弱いシグナルを脆弱性、パッケージリスク、到達可能性、設定ミス、機密データの各インジケーターと相関付けることで、ノイズを、重要度が CRITICAL の対応可能な検出結果に変えます。AWS Security Hub、Amazon Inspector、Amazon VPC Reachability Analyzer、Macie、GuardDuty Runtime Monitoring を既に有効にしている場合、新しいインジケーターは攻撃シーケンスの検出結果に自動的に表示されます。これらのサービスをまだ使用していない場合は、新しい GuardDuty 拡張脅威検出のインジケーターと、各サービス自体が提供する価値を活用するために、ぜひ有効化をご検討ください。 この記事に関する質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせください 。 Aman Khare Aman は Amazon GuardDuty のシニアソフトウェア開発者です。 拡張脅威検出 の開発に携わり、AWS インフラストラクチャで検出された悪意のある攻撃チェーンをお客様が正確に特定できるよう支援しています。以前は Amazon OpenSearch のパフォーマンスとレジリエンシーに関する取り組みを主導し、クラスターマネージャーのメモリ使用量の 10 分の 1 への削減や、1,000 ノード規模のクラスターの実現などを達成しました。仕事以外では、旅行、アドベンチャーアクティビティ、読書、ボードゲームを楽しんでいます。 Kyle Koeller Kyle は Amazon GuardDuty チームのセキュリティエンジニアで、脅威検出を専門としています。クラウドの脅威検出とオフェンシブセキュリティに情熱を注いでおり、CompTIA Security+、PenTest+、CompTIA Network Vulnerability Assessment Professional、SecurityX の資格を保有しています。仕事以外では、ジムで過ごしたり、ニューヨーク市を散策したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 10 月 12 日に公開された AWS Blog “ Quantum-resistant signing on AWS, Part 2: Enforce your ML-DSA algorithm policy with SCPs and IAM ” を翻訳したものです。 この記事では、暗号アルゴリズムポリシーを設定し、 Amazon Web Services (AWS) 環境でポリシーに準拠しない選択を防ぐ方法を紹介します。ポスト量子暗号を導入する際に最初に直面する判断の 1 つは、どのアルゴリズムとパラメータセットがビジネスニーズに合うかという選択です。この選択では、セキュリティと、署名サイズ、キーサイズ、パフォーマンスとのバランスを取る必要があります。クラウド環境の役割は、その判断をポリシーとして表現し、一貫して適用できるようにすることです。これにより、承認された選択肢は引き続き問題なく使用でき、除外された選択肢は導入できなくなります。この記事では、AWS での具体的な例を 1 つ取り上げ、組織の暗号アルゴリズムポリシーを予防的コントロールと発見的コントロールに変換する方法を説明します。現在の承認済みセットがどのようなものでも、また標準の進化に伴ってそれがどう変わっても、同じパターンを適用できます。 この記事は、AWS における耐量子署名に関する 2 部構成のシリーズのパート 2 です。パート 1 の「 ML-DSA によるソフトウェアサプライチェーンの構築 」はビルダー向けの記事で、バイナリ、コンテナイメージ、ソフトウェア部品表を対象とするエンドツーエンドの ML-DSA 署名パイプラインを構築します。パート 2 となるこの記事は、そのパイプラインをはじめ組織内のあらゆるものが使用してよいアルゴリズムを決定し、その決定を確実に適用する必要があるセキュリティ、ガバナンス、コンプライアンスの各チームを対象としています。 AWS Key Management Service (AWS KMS) は、ML-DSA-44、ML-DSA-65、ML-DSA-87 の 3 つのパラメータセットで ML-DSA デジタル署名方式 (FIPS 204) をサポートしており、それぞれ NIST セキュリティカテゴリ 2、3、5 を対象としています。3 つとも強力で標準化された選択肢です。いずれも、署名サイズ、キーサイズ、速度と、セキュリティマージンとの間にトレードオフがあります。セキュリティマージンとは、目標とするセキュリティカテゴリに対して、パラメータセットが余力として備えている暗号強度のことです。ML-DSA-44 は最もコンパクトで高速です。ML-DSA-65 と ML-DSA-87 はより大きなセキュリティマージンを備えているため、長期間にわたって信頼性を保つ必要がある署名に適しています。 この記事では、全体を通じて同じポリシー例を使用します。ML-DSA-65 と ML-DSA-87 を標準として採用し、ML-DSA-44 を承認済みセットから除外したい組織の例です。これは標準化に関する判断であり、ML-DSA-44 が安全でないという判断ではありません (次の注を参照)。以降のコントロールで ML-DSA-44 が登場する箇所は、自組織のポリシーに含まれないバリアントと読み替えてください。どのような許可/拒否の区分を選択しても、仕組みは同じです。ここでの承認済みセットは、 パート 1 のアーキテクチャでデプロイするものと同じで、ルート認証局 (CA) には ML-DSA-87、下位 CA とコード署名キーには ML-DSA-65 を使用します。パート 1 で選択を行い、この記事でその選択を確実に守らせる仕組みを作ります。 注 : ML-DSA-44 は有効な選択肢です。ML-DSA-44 は NIST によって完全に標準化されたパラメータセット (FIPS 204) で、NIST セキュリティカテゴリ 2 に該当し、おおよそ 128 ビットクラスの古典的セキュリティを目標としています (カテゴリ 2 は SHA-256 の衝突耐性を基準としています)。3 つのバリアントの中で署名とパブリックキーが最も小さく (パブリックキーは 1,312 バイト、署名は 2,420 バイト)、署名と検証も最も高速です。そのため、リソースが限られたデバイス、大量の署名処理、帯域幅やストレージの制約が厳しいワークロードに適しています。ML-DSA-65 や ML-DSA-87 を選択するのは、長期間にわたって信頼性を保つ必要がある署名のためにセキュリティマージンを上乗せしたい場合や、社内標準に合わせたい場合であり、ML-DSA-44 が脆弱だからではありません。 目指す状態 承認済みのバリアント (この例では ML-DSA-65 と ML-DSA-87) は、常に問題なく使用できる状態を保ちます。排除したいのは、ポリシー外のバリアント (ここでは ML-DSA-44) の導入です。具体的には、対象範囲内の AWS サービスにおいて、プリンシパルが次の操作を実行できないようにします。 ML-DSA-44 のキーマテリアルを作成する 既存の ML-DSA-44 キーを署名または検証に使用する ML-DSA-44 を持ち込むことになるプライベート認証局 (CA) を立ち上げる また、これらの設定からのドリフトはすべて検出できるようにします。 対象範囲と制限事項 これらのコントロールは AWS サービスの API に対して機能し、主な対象は AWS KMS、 AWS Private Certificate Authorit y (AWS Private CA) 、 AWS Certificate Manager (ACM) です。お客様が管理するコンピューティングリソース上で実行される暗号処理は対象外であり、統制することもできません。例えば、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、 AWS Lambda 関数上で、OpenSSL やアプリケーションが ML-DSA-44 署名を実行する場合が該当します。また、OpenSSH のハイブリッド ssh-mldsa44-ed25519 公開鍵認証などのプロトコルレベルでの使用も、 サービスコントロールポリシー (SCP) や AWS Identity and Access Management (IAM) では制御できないため、この記事では取り上げません。 acm:ImportCertificate や iam:UploadServerCertificate で取り込まれる証明書マテリアルも、アルゴリズムを考慮した制御ができません (Private CA のセクションを参照)。その他の TLS 終端サービスや署名サービス (例えば Amazon CloudFront や Amazon API Gateway ) と AWS IAM Roles Anywhere はこの記事の対象外のため、別途評価してください (このシリーズの パート 1 では ML-DSA 証明書と共に IAM Roles Anywhere を使用していますが、このサービスのコントロールはここでは扱いません)。 これらのコントロールは、 多層防御 として適用することを想定しています。どの程度厳格に統制したいかに応じて、すべてを適用することも、一部だけを適用することもできます。 組織ルートに包括的な SCP を適用すると、メンバーアカウントで ML-DSA-44 キーを作成または使用できなくなります (SCP は管理アカウントには適用されないため、管理アカウントのワークロードは制限されません)。 本番用の組織単位 (OU) に SCP を適用すると、本番アカウントでのみキーが制限されます。 アカウント内で柔軟性が必要な場合は、SCP でアカウント全体に設定を強制するのではなく、IAM のアクセス許可の境界を使用します。 運用モデルに合った組み合わせを選択してください。ここで示すポリシー例は、すべての AWS リージョンに適用されるように記述しています。特定のリージョンだけを対象にする必要がある場合は、 aws:RequestedRegion 条件を追加してください。 この記事で紹介するポリシーは、出発点として示す例です。お客様の環境に合わせた SCP、IAM ポリシー、アクセス許可の境界の作成、検証、保守は、お客様の責任で行ってください。デプロイ前に非本番環境ですべてのポリシーをテストし、組織の承認済み標準に合わせて例の値 (ポリシー名やキーの Amazon リソースネーム (ARN) など) を調整してください。 暗号アジリティに関する注意点 アルゴリズムポリシーは永久に固定されるものではなく、これらのコントロールも同様です。ポリシーを AWS のコントロールとして表現する意義は、ニーズや関連する標準の変化に応じて、アーキテクチャを再設計することなくポリシーを修正できる点にあります。承認済みセットを厳格化することも、緩和することも、入れ替えることもできます。ここで示す例は、現在のポリシーに合わせて調整するテンプレートとして扱ってください。 特定のアルゴリズムを指定して拒否するコントロールは、事実上、指定していないものをすべて許可する許可リストとして機能します。ここで問題となるのがデフォルト許可です。明示的に拒否していないパラメータセットはすべて許可されるため、まだ評価していないものも含め、新たに導入されたバリアントは、気付いて拒否リストに追加するまで使用できてしまいます。一方、承認済みのバリアントを非推奨にする場合は、そのバリアントを拒否リストに追加するだけなので、このモデルで簡単に対応できます。このモデルだけではとらえられないのは、新しいバリアントの登場です。これらのコントロールを定期的に見直し、拒否リストと検出を組み合わせることで、ポリシー外のバリアントが偶然見つかるまで放置せず、すぐに把握できるようにしてください。 もう 1 つの方法は、除外対象ではなく承認済みセットを基準に条件を記述することです。 Deny ステートメントで StringNotEquals と承認済みキー仕様のリストを使用すると、リクエストのキー仕様がそのいずれにも一致しない場合に拒否が発動します。そのため、新しいバリアントやまだ評価していないバリアントは、リストに追加するまでデフォルトでブロックされます。この方法ではデフォルト許可の問題は解消されますが、新たに承認したバリアントを使えるようにするには、先にポリシーを更新する必要があります。このシリーズの パート 1 で紹介したファミリーレベルの SCP はこの形式で、キー仕様が ML_DSA_* ではない署名キーの作成をすべて拒否します。この記事の例はもう一方の形式を採用し、除外するバリアントを指定しているため、承認済みバリアントはポリシーを変更しなくても引き続き使用できます。どちらも有効な方法です。新しいものをまずブロックして後から承認したいのか、まず検知してからその時点で判断したいのかに応じて選択してください。 { "Sid": "OnlyApprovedMlDsaVariants", "Effect": "Deny", "Action": "kms:CreateKey", "Resource": "*", "Condition": { "StringLike": { "kms:KeySpec": "ML_DSA_*" }, "StringNotEquals": { "kms:KeySpec": ["ML_DSA_65", "ML_DSA_87"] } } } StringLike 句は、ステートメントの対象を ML-DSA のキー仕様に限定し、他のキータイプに影響しないようにします。 StringNotEquals 句は、承認済みリストにない ML-DSA バリアントをすべて拒否します。 アルゴリズムやキーサイズが時間とともに追加されたり、承認済みから未承認に変わったりするのと同様に、AWS サービスのオペレーションも変化します。現在 ML-DSA-44 キーを使用できるオペレーション (AWS KMS の Sign 、 Verify 、 GetPublicKey ) は現時点のサービス機能に基づくものであり、AWS が新機能をリリースするにつれて増える可能性があります。作成だけでなく使用もブロックする方針の場合は、サービスの進化に合わせて、制限対象のオペレーションのリストを定期的に見直してください。 背景: キー仕様と署名アルゴリズムの比較 AWS KMS の ML-DSA サポートでは、3 つのキー仕様 ( ML_DSA_44 、 ML_DSA_65 、 ML_DSA_87 ) が導入されていますが、いずれも同じポスト量子署名アルゴリズム ML_DSA_SHAKE_256 を使用します。この違いによって、どのコントロールが有効かが決まります。 kms:KeySpec : キーの KeySpec プロパティを反映します。この条件キーは、 CreateKey (リクエストされたキー仕様) と、特定のキーに対して実行される AWS KMS キーリソースオペレーション ( Sign 、 Verify 、 GetPublicKey など) の両方で評価されます。そのため、 kms:KeySpec は ML_DSA_44 を ML_DSA_65 や ML_DSA_87 と区別でき、ML-DSA-44 キーの作成の防止と既存キーの使用の制限の両方で信頼できる手段となります。 kms:SigningAlgorithm : Sign と Verify で指定された署名アルゴリズムを反映します。この値は 3 つのバリアントすべてで ML_DSA_SHAKE_256 です。そのため、ML-DSA-44 を承認済みバリアントと区別できず、この目的には使用できません。 実務上の結論として、AWS KMS で保持するキーについては、ML-DSA-44 キーマテリアルの作成を防止することが、単独のコントロールとして最も堅牢です。ML-DSA-44 の KMS キーが存在しなければ、AWS KMS を通じた署名に使われることも、証明書のサブジェクトキーになることもありません。なお、CA のキーと TLS サーバーキーは別のマテリアルです。AWS Private CA は CA のキーペアを独自の HSM で生成して保持し、ACM が発行した TLS 証明書や、インポートまたはアップロードされた TLS 証明書は、それぞれ独自のキーを持ちます。そのため、これらは後述する AWS Private CA と証明書のコントロールで管理します。ML-DSA-44 の KMS キーが既に存在する場合は、 kms:KeySpec を使用してその使用をさらに制限できます。 SCP を使用した組織レベルおよびアカウントレベルのブロック ML-DSA-44 を制限するために、SCP を組織ルートまたは特定の OU に適用できます。適用範囲は SCP をどこに配置するかで決まります。ルートにアタッチすると組織全体に、OU にアタッチするとその OU 内のアカウントに適用されます。SCP は、利用できる予防的コントロールの中で最も適用範囲の広いものです。 なお、SCP はメンバーアカウントと OU には適用されますが、組織の管理アカウントには 適用されません 。SCP による制限が及ばないため、ML-DSA-44 を使用できるワークロードを管理アカウントで実行しないようにしてください。 次の SCP の例では、ML-DSA-44 キーの作成 ( kms:CreateKey ) と使用 ( kms:Sign 、 kms:Verify 、 kms:GetPublicKey ) の両方を、 ML_DSA_44 キー仕様との一致を条件に拒否します。作成の拒否は新しいキーの作成を防ぎます。使用の拒否は既存のキーを対象とし、SCP のアタッチ前に作成されたキーや、後から OU に参加したアカウントに存在するキーにも適用されます。これは、 kms:KeySpec がこれらの使用オペレーションでもリクエスト時に評価されるためです。SCP はガードレールです。SCP 内の Deny は、メンバーアカウント内のどの IAM ポリシーでも上書きできません。 次の SCP を組織ルート (または該当する OU) にアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyMLDSA44KeyCreation", "Effect": "Deny", "Action": "kms:CreateKey", "Resource": "*", "Condition": { "StringEquals": { "kms:KeySpec": "ML_DSA_44" } } }, { "Sid": "DenyMLDSA44KeyUsage", "Effect": "Deny", "Action": [ "kms:Sign", "kms:Verify", "kms:GetPublicKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:KeySpec": "ML_DSA_44" } } } ] } 使用の拒否は、キー仕様を評価する 3 つのアクションに限定します。 使用を拒否する Deny の対象は、 kms:Sign 、 kms:Verify 、 kms:GetPublicKey に限定してください (テストにより、 kms:KeySpec が 3 つすべてで評価されることを確認しています)。包括的な kms:* は避けてください。このワイルドカードは、 DescribeKey 、 DisableKey 、 ScheduleKeyDeletion などの管理オペレーションまで対象にしてしまいます。これらは対象のキーを調査したりクリーンアップしたりするために必要なオペレーションであり、拒否すると、削除しようとしているキーを管理できなくなってしまいます。マルチリージョンキーを使用する場合は、作成の拒否に kms:ReplicateKey も追加してください。ML-DSA-44 のプライマリキーをレプリケートすると別のリージョンに新しい ML-DSA-44 キーが作成され、 kms:KeySpec は ReplicateKey でも評価されるためです。 ファミリーレベルのガードレールとの組み合わせ。この SCP はどの ML-DSA パラメータセットを許可するかを制御するもので、RSA や ECDSA については何も規定しません。このシリーズの パート 1 では、キー仕様が ML-DSA ではない署名キーの作成をすべて拒否する補完的な SCP を紹介しています。両方を併せてアタッチすると、新しい署名キーはすべて ML-DSA であり、かつ承認済みバリアントでなければならなくなります。 運用上の考慮事項。 組織ルートでの包括的な Deny は最も強力なコントロールですが、トレードオフもあります。対象範囲内のどこでも ML-DSA-44 キーを作成できなくなり、例外を設ける手段もないため、正当なテストがブロックされたり、ML-DSA-44 キーの作成を試みる Infrastructure as Code (IaC) やパイプラインの実行が失敗したりする可能性があります。柔軟性を残したい場合は、 Deny の対象を本番 OU に限定し、ビルドアカウントや非本番アカウントでは IAM のアクセス許可の境界 (次のセクションを参照) を使用することを検討してください。 呼び出し元に表示される内容。 SCP によってリクエストが拒否されると、呼び出し元はサービスコントロールポリシーによる明示的な拒否を示す AccessDenied エラーを受け取ります。同じアカウント内や同じ組織内からのリクエストであれば、エラーには拒否したポリシーのタイプが含まれます。また、拡張エラーメッセージが各サービスに順次展開されるにつれて、そのポリシーの ARN も含まれるようになります。エラーには SCP のポリシー内容は表示されず、ブロックされたユーザーは自分の環境に適用されている SCP を確認できないことがよくあります。サポートチームが AccessDenied の原因をすばやく特定できるように、SCP の ARN とその目的を社内で文書化しておいてください。 AWS KMS での ML-DSA-44 キー作成の防止 (プリンシパルレベル) 次の IAM ポリシーは、プリンシパルレベルで ML-DSA-44 をブロックします。前述の SCP に相当するアイデンティティベースのポリシーであり、組織全体のガードレールではなく、アカウント単位やロール単位で制御したい場合に役立ちます。制限したい IAM ロールまたは IAM ユーザーにアタッチしてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyMLDSA44KeyCreation", "Effect": "Deny", "Action": "kms:CreateKey", "Resource": "*", "Condition": { "StringEquals": { "kms:KeySpec": "ML_DSA_44" } } } ] } 重要なポイント 条件の値は ML_DSA_44 です (ハイフンではなくアンダースコア)。 このポリシーがブロックするのは CreateKey だけです。プリンシパルレベルで既存の ML-DSA-44 キーの使用もブロックするには、 Sign 、 Verify 、 GetPublicKey の拒否を追加してください。この拒否は 「既存の ML-DSA-44 キーの使用の制限」 セクションで紹介しています。 上書きできない包括的な保護を実現するには、プリンシパルレベルのポリシーだけに頼らず、SCP としてデプロイしてください。 IAM のアクセス許可の境界 IAM のアクセス許可の境界は、アイデンティティベースのポリシーが IAM ロールや IAM ユーザーに付与できるアクセス許可の上限を設定するもので、SCP の代わりとしても、SCP を補完するものとしても使用できます。実際に有効なアクセス許可は、アイデンティティベースのポリシーと境界が重なる部分になり、境界内の Deny はアタッチされたポリシーで上書きできません。境界は、複数アカウントにまたがる包括的な拒否ではなく、アカウント単位やロール単位で柔軟に制御したい場合 (例えば、ビルドアカウントや非本番アカウント) に役立ちます。 運用上の考慮事項。 アクセス許可の境界は、それがアタッチされたプリンシパルにしか効果がありません。境界をコントロールとして機能させるには、すべての IAM プリンシパルに境界をプログラムで強制する仕組みが必要です。その一例として、次のような SCP が考えられます。 iam:CreateRole 、 iam:CreateUser 、 iam:PutRolePermissionsBoundary 、 iam:PutUserPermissionsBoundary は、承認済みの境界が設定されていない限り拒否します ( iam:PermissionsBoundary 条件キーを使用)。さらに、 iam:DeleteRolePermissionsBoundary と iam:DeleteUserPermissionsBoundary は無条件に拒否し、後から境界を削除できないようにします。また、準拠していないプリンシパルを定期的に調べ、 PermissionsBoundary を自動的にアタッチするなどの対応を行うこともお勧めします。IAM ユーザーは使用すべきではありませんが、強制の仕組みでは IAM ユーザーが存在する可能性も考慮しておく必要があります。 境界は上限を設定するだけで、それ自体がアクセス許可を付与するわけではありません。そのため、まずすべてのアクションに Allow を指定したうえで、ML-DSA-44 キーの作成を明示的に拒否します。次のアクセス許可の境界は、ML-DSA-44 キーの作成を拒否します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAll", "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Sid": "DenyMLDSA44KeyCreation", "Effect": "Deny", "Action": "kms:CreateKey", "Resource": "*", "Condition": { "StringEquals": { "kms:KeySpec": "ML_DSA_44" } } } ] } この境界が設定されたプリンシパルについて、既存の ML-DSA-44 キーの使用もブロックするには、次のセクションで紹介する Sign 、 Verify 、 GetPublicKey の拒否ステートメントを追加します。このステートメントでも同じ条件キー ( kms:KeySpec) を使用します。 既存の ML-DSA-44 キーの使用の制限 「背景」セクションで説明したように、 kms:KeySpec は Sign 、 Verify 、 GetPublicKey でも評価され、使用されるキーの KeySpec を反映します。そのため、 kms:KeySpec が ML_DSA_44 の場合にこれらのオペレーションを拒否しつつ、 ML_DSA_65 と ML_DSA_87 は引き続き許可できます。次の IAM ポリシーを IAM プリンシパルにアタッチすると、この制御を実現できます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyMLDSA44KeyUsage", "Effect": "Deny", "Action": [ "kms:Sign", "kms:Verify", "kms:GetPublicKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:KeySpec": "ML_DSA_44" } } } ] } この拒否は AWS KMS のキーポリシーに記述することもできます。同じ kms:KeySpec による拒否を、AWS KMS キーのキーポリシーに直接記述できます。キーポリシーはリソースポリシーであるため、ステートメントには Principal 要素が必要です。一方、アイデンティティベースのポリシーと SCP では、適用対象のプリンシパルを指定しません。キーポリシー内の拒否は特定のキーを保護するリソース側の最後の防衛線となり、SCP は上書きできない組織全体の保護を提供します。前の例を AWS KMS キーポリシーに変換するには、ステートメントに Principal 要素 (例えば "Principal": {"AWS": "*"} 、またはより具体的なプリンシパル) を追加し、それ以外はそのままにします。 その他のアプローチ 目的によっては、使用を拒否するだけでなく、キーマテリアル自体を削除したい場合もあるでしょう。ただし、何らかの方法で追跡していない限り、特定のキーでどのデータが署名されたかを把握するのは困難です。使用済みのキーを削除すると、署名を検証できなくなります。キーを削除する前に、そのキーが使用されていないことを慎重に確認してください。 キーを無効化するか、削除をスケジュールします。 無効化するとキーの使用が直ちに停止し、後から元に戻すこともできます。キーの削除は、待機期間の経過後に確定し、元に戻せなくなるため、削除をスケジュールする前に十分に確認してください。 特定のキー ARN を指定して Sign 、 Verify 、 GetPublicKey を拒否します。 キー仕様全体ではなく、特定のキーだけを対象にできます。そのためには、IAM ポリシーの Resource 要素に対象のキー ARN を列挙します (条件キーは不要です)。この方法は特定のキーだけを対象にする場合には効果的ですが、キー ARN のリストを維持するのは手間がかかります。この方法は必要な場合に限って使用してください。なお、キー ARN を指定した IAM ポリシーを検討している場合は、対象キーのキーポリシーに Deny を記述しても同じ目的を達成でき、その拒否はキー自体にアタッチされることを覚えておいてください。 既存のキーの検索 (無効化または削除する場合にのみ必要)。 IAM ポリシーや SCP で Deny を kms:KeySpec に基づいて指定する場合は、リクエスト時にキー仕様に基づいて適用されるため、どのキーが存在するかを把握しておく必要はありません。一方、既存の ML-DSA-44 キーを無効化または削除したい場合は、それらのキーを見つける必要があります。AWS KMS にはキー仕様で絞り込むサーバー側のフィルターがないため、 ListKeys でキーを列挙し、 DescribeKey を呼び出して各キーの KeySpec を確認します。このようにクライアント側でフィルタリングするパターンは AWS API で広く使われており、AWS SDK のページネーション機能で容易に実装できます。また、 AWS Config を使用して KMS キーリソースを記録し、クエリすることもできます。 参考: Choosing a KMS key spec – kms:KeySpec condition key 承認済み ML-DSA バリアントと AWS Private CA の制御 AWS Private CA では、CA の作成時に CertificateAuthorityConfiguration パラメータを CreateCertificateAuthority に指定して、CA の署名アルゴリズムを設定します (有効な値には ML_DSA_44 、 ML_DSA_65 、 ML_DSA_87 などがあります)。現在、アルゴリズムに対応する条件キーはないため、SCP で署名アルゴリズムを強制することはできません。このセクションで紹介するアプローチでは、CA を作成できるプリンシパルを制御し、その信頼されたパスでアルゴリズムを固定したうえで、 AWS CloudTrail を利用した検出で補完します。 推奨されるアプローチ CA を作成できるプリンシパルを制限します。 SCP で acm-pca:CreateCertificateAuthority を広く拒否し、少数の信頼されたロールや承認済みのプロビジョニングパイプラインにのみ許可します。これにより、任意のプリンシパルが未承認のアルゴリズムで CA を立ち上げることができなくなります。 信頼されたパスでアルゴリズムを固定します。 承認済みのパイプラインや IaC テンプレートで、 SigningAlgorithm を ML_DSA_65 または ML_DSA_87 として CertificateAuthorityConfiguration 内にハードコードします。AWS Private CA にはアルゴリズムの条件キーがないため、このプロビジョニングパスがアルゴリズムを強制する箇所になります。なお、CA のアルゴリズムで固定されるのは、その CA が発行する証明書の署名です。各証明書のサブジェクトキーは CSR から取得され、AWS Private CA はそのアルゴリズムを検証せずにそのままコピーします。そのため、同じ発行パイプラインで CSR のキーアルゴリズムも固定してください。 信頼チェーンを制御します。 PKI 側では、承認済みの CA のみをトラストストアと発行階層に追加し、ML-DSA-44 の証明書を発行する可能性がある CA を信頼したり、下位 CA として配置したりしないでください。これにより、未承認の CA が信頼されたパスに入り込むのを防止できます。 ドリフトを検出します。 CloudTrail で CreateCertificateAuthority の呼び出しを記録し、AWS Config で設定に ML_DSA_44 を使用している CA にフラグを立てます。これにより、未承認の CA をすばやく検出できます。 このシリーズの パート 1 では、この仕組みを実際に構築しています。具体的には、 CreateCertificateAuthority を使用して ML-DSA-87 のルート CA と ML-DSA-65 の下位 CA を作成し、それらをアクティブ化して、生成された証明書チェーンを検証者に配布します。ここで説明するモデルでは、これらの呼び出しを実行できるのは承認済みのプロビジョニングパイプラインだけです。 ML-DSA の値を CertificateAuthorityConfiguration に設定する方法。 KeyAlgorithm フィールドと SigningAlgorithm フィールドの両方に同じバリアントを指定します (例えば、 KeyAlgorithm=ML_DSA_65 と SigningAlgorithm=ML_DSA_65 )。AWS KMS と AWS Private CA では署名アルゴリズムの指定方法が異なる点に注意してください。AWS Private CA の SigningAlgorithm にはバリアントの値 ( ML_DSA_44 、 ML_DSA_65 、 ML_DSA_87 ) を直接指定し、 ML_DSA_SHAKE_256 は受け付けません。一方、AWS KMS では署名アルゴリズムとして ML_DSA_SHAKE_256 を使用します。また、一部の古い AWS コマンドラインインターフェイス (AWS CLI) ビルドでは、組み込みの CLI ヘルプに ML-DSA バリアントの説明が含まれていませんでした。有効な値を確認する際は、AWS CLI のヘルプに頼らないでください。詳細については、「 CertificateAuthorityConfiguration API Reference 」を参照してください。 既知の制限事項。 一部の対象にはアルゴリズムの条件キーがないため、ポリシーではなくプロビジョニングと検出によって強制します。 acm-pca:CreateCertificateAuthority にはアルゴリズムの条件キーがなく、 acm:ImportCertificate と iam:UploadServerCertificate はアルゴリズムを認識しません。そのため、作成、インポート、アップロードされる証明書の署名設定が許可されていないものであっても、IAM ポリシーや SCP の条件でブロックすることはできません。これらはプロビジョニングプロセスで管理し、呼び出せるプリンシパルを制限したうえで、不要な場合はインポートとアップロードのアクションを完全に拒否してください。現時点で利用できる緩和策は、上記のコントロールです。 特に iam:UploadServerCertificate には、特定のアルゴリズムの使用を防止する手段がまったくありません。また、AWS はこの API を使用した証明書の生成とアップロードを推奨していません。この API は ACM より前から存在するもので、主に ACM がまだ利用できない AWS リージョンやパーティションに対応するために用意されています。新しいリージョンやパーティションの構築中は、ACM のサポートが提供される前でもワークロードに TLS サーバー証明書が必要になる場合があります。その間、IAM に証明書をアップロードすれば、証明書を保存して参照できます。そのリージョンで ACM が利用可能になったら、ACM に切り替えてください。このような限られたケースを除き、本当に必要な場合以外は iam:UploadServerCertificate を拒否してください。 ACM が発行するリーフ証明書。 CA 自体のキーと署名アルゴリズムは、ACM がその CA から発行するリーフ証明書とは別物です。ACM でリーフ証明書をリクエストする場合は、 acm:KeyAlgorithm 条件キーを acm:RequestCertificate で使用して、リーフ証明書のキーアルゴリズムを制限できます。これにより、前述の AWS KMS の例と同様に、SCP や IAM ポリシーでリーフ証明書の承認済みアルゴリズムを許可リストとして指定できます。なお、この記事の執筆時点では、ACM は ML-DSA のリーフ証明書を提供していません。そのため、このポリシーは差し迫った ML-DSA-44 のリスクへの対策ではなく、将来を見据えた多層防御のコントロールです。次の IAM ポリシーは説明用の例です (承認済みアルゴリズムの例を使用しています)。サービスの中でも変化が続いている領域のため、実際に利用する前に必ずお使いの環境で検証してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictACMLeafKeyAlgorithm", "Effect": "Deny", "Action": "acm:RequestCertificate", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "acm:KeyAlgorithm": [ "EC_secp384r1", "RSA_2048" ] } } } ] } この例では、 Deny と StringNotEqualsIfExists を組み合わせているため、許可されていないアルゴリズムを指定したリクエストに加えて、リクエストコンテキストに acm:KeyAlgorithm が含まれないリクエストも拒否されます。 ...IfExists 演算子は、条件キーが存在しない場合に条件を true と評価するためです。通常の StringNotEquals を使用した場合も、キーが存在しなければ条件は true となり、同じく拒否されます。条件キーが存在する場合に限って未承認のアルゴリズムを拒否したい場合は、 StringNotEquals による比較と、 "Null": {"acm:KeyAlgorithm": "false"} による存在チェックを同じ Condition 内に記述してください。 NLB と ALB の TLS での ML-DSA-44 の使用の防止 Elastic Load Balancing は、 Network Load Balancer (NLB) と Application Load Balancer (ALB) のどちらでも、アプリケーションに代わって TLS を終端します。これらのリスナーが使用する証明書は、ACM でリクエストされたもの、ACM にインポートされたもの、または IAM にアップロードされたもののいずれかです。ネゴシエーション時に提示される内容は、リスナーに設定されたセキュリティポリシーと証明書によって決まります。この記事の執筆時点では、ACM のリクエストとインポートは RSA キーと ECDSA キーのみに対応しており、NLB と ALB のリスナーも RSA 証明書と ECDSA 証明書のみに対応しています。そのため、現時点では ML-DSA 証明書をリスナーにバインドすることはできません。前述の ACM リーフ証明書のポリシーと同様に、このセクションのコントロールは、差し迫った ML-DSA-44 のリスクへの緩和策ではなく、将来を見据えた多層防御です。 証明書のコントロール (ML-DSA-44 に有効な仕組み) リスナーの API コールでは証明書を ARN でしか参照しないため、 CreateListener 、 ModifyListener 、 AddListenerCertificates に対して、証明書のアルゴリズムを検査する SCP を記述することはできません。IAM の条件では、別途参照されるリソースの属性を参照できないためです。したがって、TLS から ML-DSA-44 を排除するには、関連付け可能な ML-DSA-44 の証明書マテリアルをそもそも存在させないことが前提となります。 プライベート CA が ML_DSA_65 または ML_DSA_87 の証明書のみを発行するように設定し、CA を作成できるプリンシパルを制御します。 AWS KMS で ML-DSA-44 キーの作成を防止し、AWS KMS で保持している ML-DSA-44 キーが証明書のサブジェクトキーにならないようにします。なお、ACM が発行した証明書や、インポートまたはアップロードされた証明書の TLS サーバーキーは KMS キーではないため、項目 1 と 3 で管理します。 AWS Private CA のセクションで説明したように、インポートおよびアップロードされる証明書をプロビジョニングプロセスで管理するか、不要な場合はインポートとアップロードのアクションを拒否します。 発見的コントロール CloudTrail は、このセクションで扱う証明書とリスナーの API コールを記録します。対象は、証明書の作成とインポート ( acm-pca:CreateCertificateAuthority 、 acm:ImportCertificate 、 iam:UploadServerCertificate ) と、リスナーの設定 ( CreateListener 、 ModifyListener 、 AddListenerCertificates ) です。イベントにアルゴリズムが記録されるかどうかは、呼び出し自体にアルゴリズムの情報が含まれているかどうかで決まります。アルゴリズムを入力として受け取る作成系の呼び出しでは、アルゴリズムが記録されます。 kms:CreateKey では KeySpec が、 acm-pca:CreateCertificateAuthority では署名アルゴリズムが記録されます。そのため、CloudTrail は ML-DSA-44 のキーマテリアルや CA の作成を検出するのに効果的です。一方、リスナーへのバインドでは証明書を ARN でしか参照しないため、そのイベントには証明書のアルゴリズムが記録されません。バインドされた証明書やインポートされた証明書のアルゴリズムを評価するには、発見的コントロールの最後の防衛線として AWS Config のリソース評価を使用してください。 TLS のまとめ 主な予防的コントロールは、証明書マテリアルそのものの管理です。ML-DSA-44 の CA も ML-DSA-44 の KMS キーも存在せず、証明書のインポートとアップロードが制御されていれば、ML-DSA-44 証明書を発行することもバインドすることもできません。許可する TLS セキュリティポリシーを許可リストとして運用している場合は、 elasticloadbalancing:SecurityPolicy 条件キー ( CreateListener と ModifyListener で使用) で、リスナーが使用できる TLS ポリシーをさらに制限することもできます。 コントロールのまとめ 次の表は、ポリシー例 (ML-DSA-65 または ML-DSA-87 を許可し、ML-DSA-44 を除外する) に対応する利用可能なコントロールをまとめたものです。自組織のポリシーで定める承認済みアルゴリズムのセットに合わせて、コントロールを調整してください。 領域 コントロール ステータス ML-DSA-44 キーの作成をブロックする (組織全体、または組織の OU 内のすべてのアカウント) SCP で kms:CreateKey を制限。条件キー: kms:KeySpec 条件キーで完全にサポート ML-DSA-44 キーの作成をブロックする (アカウント単位またはロール単位) IAM ポリシーまたはアクセス許可の境界。条件キー: kms:KeySpec サポート (境界をプログラムで強制する必要あり) 既存の ML-DSA-44 キーの使用をブロックする 拒否対象: Sign 、 Verify 、 GetPublicKey 。条件キー: kms:KeySpec (キーポリシー、IAM、または SCP)。必要に応じてキーの無効化と削除も実施 サポート。条件キー: kms:KeySpec ( kms:SigningAlgorithm は不可) Private CA で承認済みバリアントのみを許可する CA を作成できるプリンシパルを制限。プロビジョニングパスで ML_DSA_65 または ML_DSA_87 を固定 アルゴリズムの条件キーなし。プロセスと検出で強制 インポートまたはアップロードされた TLS 証明書のバリアントを制限する プロセスによる制御、またはインポートやアップロードの API を拒否 ( iam:UploadServerCertificate ではなく ACM を推奨) API はアルゴリズムを認識しない Network Load Balancer (NLB) と Application Load Balancer (ALB) の TLS で ML-DSA-44 の使用をブロックする TLS ポリシーを制限。条件キー: elasticloadbalancing:SecurityPolicy 。証明書マテリアルを制御 TLS ポリシーの制限はサポート。証明書ごとのアルゴリズム条件はなし 未承認のバリアントの使用を検出する CloudTrail (API レベル) と AWS Config のカスタムルール AWS Config のカスタムルールでサポート (マネージドルールは非対応) まとめ この記事では、ML-DSA を例に、暗号アルゴリズムポリシーを実際に強制できる AWS のコントロールに変換する方法を説明しました。中心となるのは kms:KeySpec 条件キーです。この条件キーを使うと、承認済みのパラメータセット (ML-DSA-65 と ML-DSA-87) を問題なく使用できる状態に保ちながら、除外したパラメータセット (ML-DSA-44) の作成と使用を防止できます。対象となるのは CreateKey に加えて、 Sign 、 Verify 、 GetPublicKey の各オペレーションです。これらのオペレーションでは、 kms:SigningAlgorithm を使ってもバリアントを区別できません。これらのコントロールを SCP、IAM ポリシー、アクセス許可の境界、KMS キーポリシーによる多層防御として適用し、アルゴリズムの条件キーがない対象 (AWS Private CA、証明書のインポート、Elastic Load Balancing の TLS) にはプロビジョニング制御と AWS CloudTrail および AWS Config によるドリフト検出で対応することで、未承認のバリアントをアカウントから一貫して排除できます。 このパターンは ML-DSA-44 に限ったものではありません。アルゴリズムポリシーは標準や自組織の要件の変化に伴って変わっていくため、これらのコントロールを再利用可能なテンプレートとして扱い、同じ条件キーとガードレールを、その時点の承認済みセットに合わせて適用し直してください。強制の仕組みを作り直すことなく許可する内容を変更できる、この適応性こそが暗号アジリティの実践的な意味です。 まずは「 ML-DSA keys in AWS KMS 」と「 Choosing a KMS key spec 」を確認し、デプロイする前に非本番環境でポリシー例をテストしてください。 これらのコントロールで管理するワークロードについては、このシリーズの パート 1 をお読みください。パート 1 では、ここで強制する承認済みセットを使用して、キーの作成と PKI の構築からアーティファクトの署名と検証まで、ML-DSA 署名パイプライン全体を構築します。 リソース AWS における耐量子署名、パート 1: ML-DSA によるソフトウェアサプライチェーンの構築 AWS KMS adds support for post-quantum ML-DSA digital signatures ML-DSA keys in AWS KMS AWS KMS condition keys (kms:KeySpec evaluated on CreateKey and key resource operations) Choosing a KMS key spec (kms:KeySpec) Use condition keys with ACM (acm:KeyAlgorithm) Actions, resources, and condition keys for AWS Private Certificate Authority Private CA CertificateAuthorityConfiguration API Actions, resources, and condition keys for Elastic Load Balancing v2 (elasticloadbalancing:SecurityPolicy) Enhanced access denied error messages with policy ARNs Harshvardhan Chunawala Harshvardhan は AWS のソリューションアーキテクト兼セキュリティ SME で、Amazon Leo、Amazon Security、AWS Agentic AI と連携したチーム横断的な取り組みを主導しています。クラウドセキュリティ分野で 10 年以上の経験を持つ Golden Jacket 受賞者であり、カーネギーメロン大学ではアドバイザリーボードメンバー、客員教員、研究者も務めています。世界中の経営幹部、エンタープライズのリーダー、スタートアップの創業者に対して、安全でスケーラブルなクラウドプラットフォームの構築について助言しています。 Blake Roberts Blake Roberts は AWS のシニアソリューションアーキテクトで、AWS Security Technical Field Community のメンバーです。英国の公共部門のお客様が直面するセキュリティの課題や疑問の解決を支援しており、ポスト量子暗号、脅威の検出とインシデント対応、戦略レベルでのガバナンスなど、幅広い分野をカバーしています。AWS に入社する前は、英国陸軍に 9 年間勤務していました。大の読書家であり、熱心なランナーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 10 月 12 日に公開された AWS Blog “ Quantum-resistant signing on AWS, Part 1: Build a software supply chain with ML-DSA ” を翻訳したものです。 ソフトウェアサプライチェーン攻撃は、頻度と巧妙さの両面で増しています。最近注目を集めた、ビルドシステムやオープンソースの依存関係の侵害事例は、ソフトウェアの完全性を検証する信頼メカニズムを攻撃者が標的にするケースが増えていることを示しています。こうした信頼メカニズムはデジタル署名アルゴリズムに依存しており、現在その多くが RSA (Rivest-Shamir-Adleman) や ECDSA (Elliptic Curve Digital Signature Algorithm) などの従来型のアルゴリズムを使用しています。十分に強力な量子コンピュータによってこれらの署名が偽造できるようになると、攻撃者は署名済みアーティファクトに不正なコードを挿入したり、ビルドアテステーションを捏造したり、正当な発行元になりすましたりできる可能性があります。耐量子署名を今から使用しておくことで、将来出現する可能性のある脅威に備えることができます。 米国国家安全保障局 (NSA) が公開した Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) は、2025 年以降、米国国家安全保障システム (NSS) に対して、ソフトウェアとファームウェアの署名に耐量子方式を「サポートし優先する (support and prefer)」ことを求めており、2030 年までには耐量子署名のみを使用することを義務付けています。 EU サイバーレジリエンス法 (CRA) は 2027 年 12 月に全面適用されます。CRA は、製品のライフサイクル全体を通じて、検証可能な形でソフトウェアの完全性を維持することを製造業者に求めています。米国連邦機関にソフトウェアを提供する組織や欧州市場で製品を販売する組織は、時期が重なる複数の期限に直面しており、今すぐ対応を始める必要があります。 Amazon Web Services (AWS) は、本番環境に対応した一般提供済みのサービスで、耐量子ソフトウェアサプライチェーンを今すぐ構築するための構成要素を提供しています。この記事では、 ML-DSA (Module-Lattice-Based Digital Signature Algorithm) キーを AWS Key Management Service (AWS KMS) で、ML-DSA 証明書階層を AWS Private Certificate Authority で、ML-DSA トラストアンカーを AWS Identity and Access Management (IAM) Roles Anywhere で用意し、それらを組み合わせて、バイナリ、コンテナイメージ、ソフトウェア部品表 (SBOM) を対象とするエンドツーエンドの署名アーキテクチャを構築する方法を紹介します。 この記事は、 NIST FIPS 204 で標準化された ML-DSA 署名を AWS で導入するための 2 部構成シリーズのパート 1 です。2026 年 10 月時点で、このシリーズは、ML-DSA の信頼のルート (root of trust) の確立から組織全体でのアルゴリズムポリシーの適用まで、ソフトウェアサプライチェーン全体にわたる耐量子署名を扱うエンドツーエンドのガイドとして、クラウドプロバイダーが提供する初めてのものです。パート 1 はビルダー向けで、署名パイプラインの構築と運用の手順を説明します。パート 2「 SCP と IAM による ML-DSA アルゴリズムポリシーの強制 」はセキュリティチームとガバナンスチーム向けで、ここで選択したアルゴリズムを、組織全体にわたる予防的コントロールと発見的コントロールに落とし込む方法を紹介します。 「 今収集し、後で偽造する (harvest now, forge later) 」脅威を理解する 暗号解読能力を持つ量子コンピュータ (CRQC) が実現すると、現在の公開鍵暗号の安全性を支えている数学的問題を効率的に解けるようになります。計算量の多さから現在は現実的でない攻撃も、CRQC を使用すれば一気に現実的なものになります。ポスト量子暗号 (PQC) に関する議論のほとんどは、データの機密性に対する「 今収集し、後で復号する (harvest now, decrypt later) 」脅威に焦点を当てています。転送中のデータを保護する非対称鍵は CRQC を使用すれば効率的に導出できるため、保護されるはずだったデータが露呈してしまいます。デジタル署名も、非対称暗号と同じ数学的問題に依存しており、CRQC が実現すればその安全性は破られます。つまり、ソフトウェアサプライチェーンも、機密性ではなく完全性を標的とする同様の脅威にさらされています。署名済みアーティファクトを今のうちに記録しておいた攻撃者は、将来 CRQC を使用して、まったく別のアーティファクトに対する署名を偽造できます。 2026 年に ECDSA P-256 で署名され、組み込みデバイスのフリートにデプロイされたファームウェアを例に考えてみましょう。これらのデバイスは、15 年間の運用期間中、起動のたびにファームウェアの署名を検証します。また、デプロイ後に再署名のために回収することはできません。2035 年に CRQC が稼働した場合、攻撃者は改ざんしたファームウェアに対して有効に見える署名を作成でき、フリート内のすべてのデバイスが次回の再起動時にそれを本物として受け入れてしまいます。ソフトウェアの完全性を検証する主な手段として古典的なデジタル署名に依存している組織にとって、これは検証チェーンの重要な部分が弱体化することを意味します。CNSA 2.0 がデジタル署名に厳しいタイムラインを定めているのはこのためです。今日署名するアーティファクトは、運用期間全体にわたって信頼できる状態を維持しなければなりません。 ML-DSA は、古典コンピュータと量子コンピュータのどちらからの攻撃にも耐えられるように設計されています。AWS KMS、AWS Private CA、AWS IAM Roles Anywhere はいずれも ML-DSA をサポートしているため、追加のツールなしで、サプライチェーン全体にわたって将来の署名偽造の脅威に今すぐ対処できます。 アーキテクチャの概要: 耐量子サプライチェーンの 5 つの柱 このアーキテクチャは、連携してソフトウェアデリバリーパイプラインを保護する 5 つの信頼の柱で構成されています。 AWS KMS での ML-DSA キー管理 – すべての署名キーは、FIPS 140-3 セキュリティレベル 3 のハードウェアセキュリティモジュール (HSM) で生成、保護されます。プライベートキーが HSM の境界の外に出ることはありません。 AWS Private CA による ML-DSA 公開鍵基盤 (PKI) – 証明書階層 (ルート CA、下位 CA、エンドエンティティ証明書) によって ML-DSA パブリックキーをアイデンティティにバインドし、誰が何に署名したかを明確にします。CA のプライベートキーは、サービスが管理するハードウェア保護された HSM で生成、保存され、HSM の境界の外に出ることはありません。 耐量子ワークロードアイデンティティ (外部ビルドエージェント向け) – AWS の外部で実行され、X.509 証明書で認証する継続的インテグレーションと継続的デリバリー (CI/CD) エージェントについては、ML-DSA 証明書を使用する IAM Roles Anywhere によって、署名者のアイデンティティを同じ耐量子の信頼のルートに結び付けます。 ML-DSA アーティファクト署名 – ビルド出力 (バイナリ、コンテナイメージのマニフェスト、パッケージ) には、AWS KMS の ML-DSA キーで署名します。署名はアーティファクトと一緒に Amazon Simple Storage Service (Amazon S3) または Amazon Elastic Container Registry (Amazon ECR) に保存します。 ML-DSA SBOM 完全性アテステーション – 各リリースの SBOM を、記述対象のアーティファクトをダイジェストで指定する in-toto Statement でラップし、その Statement に同じ ML-DSA コード署名キーで署名します。これにより、依存関係のマニフェストが改ざんされていないこと、そして添付先のアーティファクトに対応するものであることを、耐量子の方式で証明できます。 これらの柱によって信頼のチェーンが形成されます。AWS Private CA は自身の HSM でルート CA キーを保護し、アイデンティティを AWS KMS のコード署名キーにバインドする証明書を発行します。IAM Roles Anywhere はそれらの証明書を使用してビルドエージェントを認証し、認証されたエージェントは、自身が生成するすべてのアーティファクトと SBOM に署名します。 図 1: AWS におけるエンドツーエンドの耐量子ソフトウェアサプライチェーン 図 1 では、このアーキテクチャを 4 つのレイヤーに分け、構築する順に番号を付けて示しています。 信頼のルート (柱 1 と 2) – AWS Private CA の階層を確立し、AWS KMS でコード署名キーを作成します。 ワークロードアイデンティティ (柱 3) – CA を IAM Roles Anywhere のトラストアンカーとして登録し、ビルドエージェントに ML-DSA 証明書を発行します。これにより、署名者のアイデンティティを同じ耐量子の信頼のルートまでたどれるようにします。 アーティファクト署名 (柱 4 と 5) – 認証されたビルドエージェントを使用して、バイナリ、コンテナイメージ、SBOM に署名します。 検証と適用 – デプロイ時に署名を検証し、ML-DSA のみを許可するポリシーを適用します。 前提条件 この手順を実行するには、以下が必要です。 AWS KMS、AWS Private CA、IAM Roles Anywhere、Amazon ECR でリソースを作成する権限を持つ AWS アカウント。 AWS Command Line Interface (AWS CLI) v2 (適切な認証情報を設定済みのもの)。 ワークロードの認証に使用する IAM Roles Anywhere 認証情報ヘルパー ( aws_signing_helper ) v1.8.0 以降。ML-DSA キーと証明書に対応した最初のリリースです。 IAM Roles Anywhere のドキュメント からダウンロードできます。 OpenSSL 3.5 以降 (ML-DSA 署名の検証と mu の計算に必要)。 ORAS CLI v1.2 以降 (コンテナイメージに Open Container Initiative (OCI) リファラーアーティファクトを添付するために使用)。代わりに、カスタムプラグインを使用した Notation CLI や、 OCI Referrers API をサポートする任意の OCI 準拠クライアントを使用することもできます。 jq (SBOM アテステーションに使用する in-toto Statement の作成と解析、および ORAS 出力の解析に使用)。 SBOM の例で使用する Amazon Inspector SBOM Generator (Sbomgen)、または CycloneDX JSON 形式の SBOM を生成できる別のツール。Sbomgen は Linux (x86-64 および ARM64) でのみ動作するため、該当する手順は Linux のビルドエージェントまたはコンテナで実行してください。Sbomgen は、 oras login が Docker の設定ファイルに保存したレジストリ認証情報を使用します。 --username オプション、または INSPECTOR_SBOMGEN_USERNAME と INSPECTOR_SBOMGEN_PASSWORD の環境変数で認証情報を渡すこともできます。 Java 11 以降と Apache Maven (「ML-DSA PKI 基盤の構築」のステップ 4 で、コード署名用の証明書署名リクエスト (CSR) を生成する diy-code-signing-kms-private-ca サンプルの実行に使用)。 Amazon ECR にプッシュ済みのコンテナイメージ (コンテナ署名の例で使用)。 ML-DSA PKI 基盤の構築 まず、サプライチェーンの信頼の基点となる証明書階層を作成します。AWS Private CA では、認証機関 (CA) を作成すると、その CA の署名キーがハードウェア保護された HSM 内で生成、保存されます。ルート CA には ML-DSA-87 (NIST セキュリティカテゴリ 5。AES-256 の全数鍵探索と同等以上に破ることが困難であると定義されています) を使用します。これは、最も長期間使用されるトラストアンカーであるルート CA を保護するためです。下位 CA には ML-DSA-65 (NIST セキュリティカテゴリ 3) を使用し、頻繁に発行される証明書の署名サイズを抑えつつ、セキュリティとのバランスを取ります。 ここで使用するパラメータセット ML-DSA-87 と ML-DSA-65 は、このシリーズの パート 2 で強制可能なコントロールに落とし込むアルゴリズムポリシーの例でも、承認済みのセットとして使われています。組織で別のセットを標準として採用している場合は、以降のコマンド内のパラメータセットをそのセットに置き換えてください。ビルド手順自体は変わりません。 ステップ 1: AWS Private CA でルート CA を作成する KeyAlgorithm: ML_DSA_87 を指定すると、Private CA が内部で ML-DSA-87 キーペアを生成します。CA 用に別途 AWS KMS キーを作成する必要はありません。 aws acm-pca create-certificate-authority \ --certificate-authority-configuration '{ "KeyAlgorithm": "ML_DSA_87", "SigningAlgorithm": "ML_DSA_87", "Subject": { "CommonName": "PQC Supply Chain Root CA", "Organization": "Example Corp", "Country": "US" } }' \ --certificate-authority-type ROOT 作成直後のルート CA は PENDING_CERTIFICATE 状態です。証明書に自己署名してアクティブ化します。ルート CA の有効期間はこの手順で設定します (ルート CA では 10 年が一般的です)。 # Retrieve the root CA's CSR aws acm-pca get-certificate-authority-csr \ --certificate-authority-arn <root-ca-arn> \ --output text > root-ca.csr # Self-sign the root CA certificate (valid for 10 years) ROOT_CERT_ARN=$(aws acm-pca issue-certificate \ --certificate-authority-arn <root-ca-arn> \ --csr fileb://root-ca.csr \ --signing-algorithm ML_DSA_87 \ --validity Value=3650,Type=DAYS \ --template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \ --query CertificateArn --output text) # Retrieve and install the self-signed root certificate aws acm-pca get-certificate \ --certificate-authority-arn <root-ca-arn> \ --certificate-arn $ROOT_CERT_ARN \ --query Certificate --output text > root-ca-cert.pem aws acm-pca import-certificate-authority-certificate \ --certificate-authority-arn <root-ca-arn> \ --certificate fileb://root-ca-cert.pem ステップ 2: コード署名用の下位 CA を作成する aws acm-pca create-certificate-authority \ --certificate-authority-configuration '{ "KeyAlgorithm": "ML_DSA_65", "SigningAlgorithm": "ML_DSA_65", "Subject": { "CommonName": "PQC Code Signing CA", "Organization": "Example Corp", "Country": "US" } }' \ --certificate-authority-type SUBORDINATE 作成直後の下位 CA は PENDING_CERTIFICATE 状態で、まだルートとはリンクされていません。下位 CA の CSR にルート CA で署名して、アクティブ化します。 # Retrieve the subordinate CA's certificate signing request aws acm-pca get-certificate-authority-csr \ --certificate-authority-arn <sub-ca-arn> \ --output text > sub-ca.csr # Sign the CSR using the root CA (this establishes the trust hierarchy) SUB_CERT_ARN=$(aws acm-pca issue-certificate \ --certificate-authority-arn <root-ca-arn> \ --csr fileb://sub-ca.csr \ --signing-algorithm ML_DSA_87 \ --validity Value=1825,Type=DAYS \ --template-arn arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1 \ --query CertificateArn --output text) # Retrieve the signed certificate and import it to activate the subordinate CA aws acm-pca get-certificate \ --certificate-authority-arn <root-ca-arn> \ --certificate-arn $SUB_CERT_ARN \ --query Certificate --output text > sub-ca-cert.pem aws acm-pca import-certificate-authority-certificate \ --certificate-authority-arn <sub-ca-arn> \ --certificate fileb://sub-ca-cert.pem \ --certificate-chain fileb://root-ca-cert.pem ステップ 3: AWS KMS でコード署名キーを作成する ビルドエージェントはこのキーでアーティファクトに署名するため、ビルドエージェントの IAM ロールには、このキーに対する kms:Sign 権限が必要です。下位 CA が発行するエンドエンティティ証明書によって、アイデンティティがこのキーのパブリックキーにバインドされます。 aws kms create-key \ --key-spec ML_DSA_65 \ --key-usage SIGN_VERIFY \ --description "PQC code-signing key for supply chain" \ --tags TagKey=Purpose,TagValue=CodeSigning CI/CD スクリプトから参照しやすいように、エイリアスを作成します。 aws kms create-alias \ --alias-name alias/pqc-code-signing \ --target-key-id <key-id-from-above> ステップ 4: エンドエンティティのコード署名証明書を発行する 証明書を発行するには CSR が必要です。ML-DSA プライベートキーは AWS KMS の HSM の外に出ないため、OpenSSL を使用してローカルで CSR を生成することはできません。代わりに、サブジェクト名とパブリックキーを含む CSR の TBS (to-be-signed) 構造を作成し、 aws kms sign を呼び出してリモートで署名したうえで、それらを組み合わせて最終的な CSR を作成します。 AWS KMS で管理されるプライベートキーを使用して ML-DSA CSR を作成し、AWS KMS で署名する実装例については、「 AWS Private CA と AWS KMS を使用したポスト量子 (ML-DSA) コード署名 」と、GitHub で公開されている diy-code-signing-kms-private-ca サンプル (Java、Maven でビルド) を参照してください。この手順は AWS CLI だけでは完結しません。CSR はコードで作成して署名する必要があり、このサンプルがそのリファレンス実装です。 code-signing.csr ファイルが用意できたら、下位 CA から証明書を発行します。 # Issue a code-signing certificate valid for one year, signed by the subordinate CA using ML-DSA-65. # Replace <sub-ca-arn> with the ARN that create-certificate-authority returned for the subordinate CA in Step 2. CODE_SIGNING_CERT_ARN=$(aws acm-pca issue-certificate \ --certificate-authority-arn <sub-ca-arn> \ --csr fileb://code-signing.csr \ --signing-algorithm ML_DSA_65 \ --validity Value=365,Type=DAYS \ --template-arn arn:aws:acm-pca:::template/CodeSigningCertificate/V1 \ --query CertificateArn --output text) # Retrieve the issued certificate aws acm-pca get-certificate \ --certificate-authority-arn <sub-ca-arn> \ --certificate-arn $CODE_SIGNING_CERT_ARN \ --query Certificate --output text > code-signing-cert.pem この証明書によって、署名者のアイデンティティが AWS KMS のコード署名キーマテリアルにバインドされます。なお、検証者が証明書の確認だけで署名を検証できる期間は、証明書の有効期間 (この例では 365 日) で決まります。AWS Private CA では、発行元 CA 自身の証明書の有効期限を超えない範囲で、発行する証明書の有効期間を自由に選択できます。この例では、ステップ 2 で作成した下位 CA 証明書の有効期間が 1,825 日であるため、後述の 3 年のオプションもその範囲内に収まります。証明書の有効期限が切れた後も検証できる状態を維持する必要があるアーティファクトについては、次のアプローチを検討してください。 証明書の有効期間の延長 – プライベート PKI では発行ポリシーを自組織で管理できるため、コード署名証明書を複数年の有効期間 (例えば、 Value=1095,Type=DAYS で 3 年) で発行するのが一般的です。 信頼されたタイムスタンプ (RFC 3161) – 署名時に、タイムスタンプ局 (TSA) から取得した RFC 3161 タイムスタンプで各署名に副署します。タイムスタンプによって、証明書の有効期間中に署名が作成されたことが証明されるため、無期限に検証できるようになります。AWS はマネージド TSA を提供していないため、サードパーティの TSA を使用するか、独自の TSA を運用してください。 再署名 – 証明書の有効期限が切れる前に、新しく発行した証明書で、現在使用中のアーティファクトに再署名します。 署名を検証する必要があるシステムに、証明書チェーン (ルート CA 証明書、下位 CA 証明書、エンドエンティティ証明書) を配布します。 CI/CD パイプラインでの ML-DSA によるアーティファクトの署名 PKI 階層の準備ができたら、ML-DSA 署名をビルドプロセスに組み込みます。方法はアーティファクトの種類によって異なります。ML-DSA-65 の署名サイズは 3,309 バイト (ECDSA P-256 では 64 バイト) ですが、ML-DSA に対する AWS KMS の Sign オペレーションのレイテンシーは、既存の非対称オペレーションと同程度です。署名サイズの増加は、数メガバイトのコンテナイメージやパッケージと一緒に保存する場合にはほとんど影響しません。ただし、低帯域幅のリンク経由で送信される組み込みデバイスイメージなど、サイズに制約のある環境では考慮しておく必要があります。 バイナリとパッケージの署名 コンパイル済みのバイナリやパッケージなど、ほとんどのビルド出力は、 aws kms sign に渡すメッセージに対して AWS KMS が設けている 4,096 バイトの上限をはるかに超えるサイズです。パイプラインのデフォルトには EXTERNAL_MU メソッドを使用してください。この方法では、OpenSSL 3.5 を使用して 64 バイトのメッセージ代表値 (mu) を外部で計算し、mu だけを AWS KMS に渡します。任意のサイズのアーティファクトを処理でき、アーティファクトが大きくなっても変更は不要です。AWS KMS では、 --message-type RAW を使用して、最大 4,096 バイトまでのコンテンツを直接渡すこともできます。ただし、 RAW は、後述のコンテナイメージの例で扱う 71 文字のマニフェストダイジェストのように、構造上サイズが固定されている入力にのみ使用してください。現時点で上限に収まるアーティファクトでも、いずれ上限を超える可能性が高く、その時点で RAW に依存しているパイプラインは失敗します。どちらの方法でも、暗号学的に同一の署名が生成されます。検証者はどちらの方法が使用されたかを知る必要はなく、いずれの場合も標準的な ML-DSA 検証を適用できます。 # Retrieve the public key aws kms get-public-key --key-id alias/pqc-code-signing \ --query PublicKey --output text | base64 --decode > pk.der # Extract raw public key bytes from the DER-encoded SubjectPublicKeyInfo. # The BIT STRING starts at offset 17 for all ML-DSA key sizes. # Expected output: 1,312 bytes (ML-DSA-44), 1,952 bytes (ML-DSA-65), or 2,592 bytes (ML-DSA-87). openssl asn1parse -inform DER -in pk.der -strparse 17 -noout -out pk_raw.bin # Compute mu per FIPS 204 Section 6.2 printf '\x00\x00' | cat - artifact.bin > m_prime.bin openssl dgst -shake256 -xoflen 64 -binary pk_raw.bin > pk_hash.bin cat pk_hash.bin m_prime.bin | openssl dgst -shake256 -xoflen 64 -binary > mu.bin # Sign the mu value aws kms sign \ --key-id alias/pqc-code-signing \ --message fileb://mu.bin \ --message-type EXTERNAL_MU \ --signing-algorithm ML_DSA_SHAKE_256 \ --query Signature --output text | base64 --decode > artifact.bin.sig .sig ファイルは、アーティファクトと一緒に Amazon S3 またはパッケージリポジトリに保存します。アーティファクトと署名の両方の完全性を保護するために、 S3 Object Lock (WORM 保護) を有効にするか、少なくとも書き込みアクセスを制限したうえで S3 バージョニングを有効にしてください。攻撃者がどちらかのファイルを変更または削除できる状態では、検証結果を信頼できません。包括的なガイダンスについては、「 Amazon S3 のセキュリティのベストプラクティス 」を参照してください。 コンテナイメージの署名 コンテナイメージの署名には、 OCI Image and Distribution Specifications v1.1 で定義されている OCI リファラーパターンを使用します。リファラーとは、署名や SBOM などのアーティファクトのうち、そのマニフェストの subject フィールドで別のイメージを指定しているものです。Amazon ECR をはじめ、このパターンをサポートするレジストリは、クライアントがイメージのリファラーを要求すると、これらのアーティファクトを返します。この方法では、AWS KMS の ML-DSA キーで署名を生成し、それをイメージのリファラーとして保存します。 # Repository URI used by ORAS here and in the SBOM steps; replace the account ID and Region ECR_URI=111122223333.dkr.ecr.us-east-1.amazonaws.com/myapp # Authenticate ORAS to Amazon ECR aws ecr get-login-password --region us-east-1 | \ oras login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com # Get the image manifest digest IMAGE_DIGEST=$(aws ecr batch-get-image \ --repository-name myapp \ --image-ids imageTag=v1.2.0 \ --query 'images[0].imageId.imageDigest' --output text) # Sign the digest. It is a fixed 71 characters, so RAW is safe here (see Binary and package signing). # AWS CLI v2 expects blob parameters to be base64, so write the digest to a file and pass it with fileb:// echo -n "$IMAGE_DIGEST" > digest.txt aws kms sign \ --key-id alias/pqc-code-signing \ --message fileb://digest.txt \ --message-type RAW \ --signing-algorithm ML_DSA_SHAKE_256 \ --query Signature --output text | base64 --decode > image.mldsa.sig # Attach signature as OCI referrer using ORAS oras attach $ECR_URI@$IMAGE_DIGEST \ --artifact-type "application/vnd.example.mldsa-signature.v1" \ image.mldsa.sig:application/octet-stream デプロイ時には、アドミッションコントローラーがリファラーアーティファクトを取得して ML-DSA 署名を検証し、その後でイメージの実行を許可します。検証ワークフロー全体とアドミッションコントロールの実装については、この記事の後半にある「 デプロイ前のコンテナイメージ署名の検証 」を参照してください。 SBOM の署名 SBOM は、ソフトウェアリリースに含まれるすべてのコンポーネント、ライブラリ、依存関係をまとめた構造化インベントリです。パッケージ名、バージョン、サプライヤー、依存関係を記載します。組織は SBOM を使用して脆弱性の追跡やライセンスコンプライアンスの検証を行い、侵害されたコンポーネントが公表された際に迅速に対応します。 SBOM ファイルだけに署名した場合、署名後にインベントリが改ざんされていないことは証明できますが、そのインベントリがどのアーティファクトを記述しているかは証明できません。イメージの署名と SBOM の署名が互いに独立していると、クリーンなイメージに対して正当に署名された SBOM を手に入れた攻撃者は、それを別の署名済みイメージに添えて提示し、両者が対応していると主張できてしまいます。SBOM を OCI リファラーとしてイメージに添付するだけでは、このギャップは解消されません。リファラーマニフェストの subject フィールドはリファラーをプッシュする人が設定するものであり、関連するアーティファクトを見つけるための仕組みにすぎず、暗号学的なバインドではないためです。バインドは、署名の対象となるバイト列の中に含める必要があります。 このバインドを実現するには、署名の前に SBOM を in-toto Statement でラップします。Statement は、記述対象のアーティファクトを subject フィールドでダイジェストにより指定し、SBOM を predicate として保持します。イメージマニフェストのダイジェストが署名対象のコンテンツに含まれるため、検証者は手元の SBOM が、これからデプロイするイメージに対して発行されたものであることを確認できます。SBOM やダイジェストが差し替えられていれば、検証は失敗します。イメージのファイルシステムに SBOM を埋め込むと、イメージダイジェストが SBOM のバイト列もカバーするようになるため、この方法でも両者をバインドできます。この記事で Statement を使う方法を採用しているのは、完成したイメージをスキャンして生成した SBOM、バイナリやファームウェアなどファイルシステムを持たないアーティファクト、既にレジストリにあるイメージのいずれにも適用でき、さらにイメージをプルしなくてもレジストリから SBOM を読み取れるためです。 任意のツール (コンテナイメージの場合は Amazon Inspector SBOM Generator (Sbomgen) など) で SBOM を生成して Statement でラップし、バイナリと同じ EXTERNAL_MU の手順で Statement に署名します。 # Scan the pushed image by digest so the inventory describes exactly the manifest you signed. # Sbomgen reuses the registry login from the oras login step in the previous section. inspector-sbomgen container --image $ECR_URI@$IMAGE_DIGEST -o sbom.json # Wrap the SBOM in an in-toto Statement whose subject is the image manifest digest. # This puts the digest inside the signed bytes, which binds this SBOM to this image. jq -n \ --arg name "$ECR_URI" \ --arg digest "${IMAGE_DIGEST#sha256:}" \ --slurpfile sbom sbom.json \ '{ "_type": "https://in-toto.io/Statement/v1", "subject": [{"name": $name, "digest": {"sha256": $digest}}], "predicateType": "https://cyclonedx.org/bom", "predicate": $sbom[0] }' > sbom.statement.json # Sign using EXTERNAL_MU (same mu computation as binary signing above, # with sbom.statement.json as the input) # ... compute mu from sbom.statement.json ... aws kms sign \ --key-id alias/pqc-code-signing \ --message fileb://mu.bin \ --message-type EXTERNAL_MU \ --signing-algorithm ML_DSA_SHAKE_256 \ --query Signature --output text | base64 --decode > sbom.statement.json.sig # Attach the Statement and its signature to the image as an OCI referrer so # verifiers discover them alongside the image signature oras attach $ECR_URI@$IMAGE_DIGEST \ --artifact-type "application/vnd.example.mldsa-sbom-attestation.v1" \ sbom.statement.json:application/vnd.in-toto+json \ sbom.statement.json.sig:application/octet-stream Statement とその .sig ファイルは必ずセットで配布してください。SBOM 自体は Statement の predicate フィールドに格納されており、検証者は検証後にそれを抽出します。同じパターンで、SBOM をバイナリやパッケージにバインドすることもできます。その場合は、イメージマニフェストのダイジェストの代わりに、ファイルの SHA-256 をサブジェクトダイジェストに設定します。バインドを完結させるサブジェクトの確認を含めた検証ワークフロー全体については、この記事の後半にある「 バイナリまたは SBOM の署名の検証 」セクションで説明します。 ビルドエージェント用の耐量子ワークロードアイデンティティ ML-DSA キーによるアーティファクトの署名で保護できるのは、アーティファクト自体の完全性です。これとは別に、AWS の外部で実行されるビルドエージェント (オンプレミスの Jenkins、セルフホスト型の GitHub Actions ランナー、サードパーティの CI/CD システム) は、通常 RSA や ECDSA で署名された X.509 証明書や OIDC トークンを使用して認証します。これらの認証情報は、パイプラインにおける古典暗号への依存となります。ML-DSA 証明書を使用する IAM Roles Anywhere は、この依存を解消します。外部のビルドエージェントが提示する認証情報も、それを保証する CA も、量子攻撃に脆弱なアルゴリズムに依存しなくなります。(リクエストを伝送する TLS 接続では、現在のパブリック TLS と同様に、引き続き従来型の証明書で AWS エンドポイントが認証されます。これはトランスポート層の問題であり、この記事で扱う署名アイデンティティとは別のものです。) IAM ロールがアタッチされ、AWS 上で実行されるビルドエージェントには、この依存はありません。こうしたビルドエージェントの API リクエストは AWS Signature Version 4 (SigV4) で認証されます。SigV4 は、対称方式のハッシュベースメッセージ認証コード (HMAC-SHA256) を使用します。このような対称方式は既に耐量子であると考えられているため、追加の対応は必要ありません。 ステップ 1: ワークロードアイデンティティ用の CA をトラストアンカーとして登録する このウォークスルーでは、前の手順で作成した下位 CA を再利用します。こうすることで、2 つ目の CA の月額料金を避けられます。以降のコマンドも、この CA を前提としています。本番環境では、コード署名用の CA とは別に、ワークロードアイデンティティ証明書専用の下位 CA を使用してください。これにより、いずれかの CA が侵害されて失効させる必要が生じた場合の影響範囲を限定でき、2 種類の証明書にそれぞれ異なる発行ポリシーを適用できます。 # Use the ARN that create-certificate-authority returned when you created the # subordinate CA earlier. If you no longer have it, list your CAs and copy the # ARN of the SUBORDINATE one. aws acm-pca list-certificate-authorities \ --query "CertificateAuthorities[?Type=='SUBORDINATE'].[Arn,Status,CertificateAuthorityConfiguration.Subject.CommonName]" \ --output table SUB_CA_ARN=arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/abc-123 # replace with yours # Register the subordinate CA as an IAM Roles Anywhere trust anchor aws rolesanywhere create-trust-anchor \ --name "PQC-CI-CD-Trust-Anchor" \ --source "sourceType=AWS_ACM_PCA,sourceData={acmPcaArn=$SUB_CA_ARN}" \ --enabled ステップ 2: ビルドエージェントのロールと、それを参照するプロファイルを作成する IAM Roles Anywhere プロファイルでは、トラストアンカーとして登録した CA が発行した証明書で認証したワークロードが引き受けられる IAM ロールを指定します。まず、ロールを作成します。ロールの信頼ポリシーでは、IAM Roles Anywhere がロールを引き受けられる条件を、トラストアンカー経由であること、かつサブジェクトのコモンネームがビルドエージェントを示す証明書であることに限定します。これらの条件がないと、トラストアンカーの CA が発行したどの証明書でもロールを引き受けられてしまいます。ロールのアクセス許可ポリシーでは、署名に必要な権限だけを、コード署名キーに対してのみ付与します。信頼ポリシーを build-agent-trust.json として保存し、トラストアンカーの ARN を、ステップ 1 で create-trust-anchor が返した ARN に置き換えます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"Service": "rolesanywhere.amazonaws.com"}, "Action": ["sts:AssumeRole", "sts:TagSession", "sts:SetSourceIdentity"], "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:111122223333:trust-anchor/ta-id" }, "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "pqc-build-agent-01" } } } ] } アクセス許可ポリシーを build-agent-permissions.json として保存し、リソースをキーの ARN に置き換えます (ARN は aws kms describe-key --key-id alias/pqc-code-signing --query KeyMetadata.Arn --output text で確認できます)。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["kms:Sign", "kms:GetPublicKey", "kms:DescribeKey"], "Resource": "<code-signing-key-arn>" } ] } ロールを作成してポリシーをアタッチし、そのロールを参照するプロファイルを作成します。 aws iam create-role \ --role-name PQCBuildAgentRole \ --assume-role-policy-document file://build-agent-trust.json aws iam put-role-policy \ --role-name PQCBuildAgentRole \ --policy-name pqc-code-signing \ --policy-document file://build-agent-permissions.json aws rolesanywhere create-profile \ --name "PQC-Build-Agent-Profile" \ --role-arns "arn:aws:iam::111122223333:role/PQCBuildAgentRole" \ --enabled ステップ 3: ビルドエージェントの証明書を発行し、認証情報ヘルパーを設定する OpenSSL を使用してビルドエージェントの ML-DSA-65 キーペアと CSR をローカルで生成し、下位 CA からクライアント認証証明書を発行します。その後、その証明書を提示するように IAM Roles Anywhere 認証情報ヘルパーを設定します。 # Generate the build agent's key pair and CSR. The CN must match the # aws:PrincipalTag/x509Subject/CN condition in the role's trust policy. openssl genpkey -algorithm ML-DSA-65 -out build-agent-mldsa-key.pem chmod 400 build-agent-mldsa-key.pem openssl req -new -key build-agent-mldsa-key.pem \ -subj "/C=US/O=Example Corp/CN=pqc-build-agent-01" \ -out build-agent.csr # Issue a 30-day client authentication certificate from the subordinate CA # registered as the trust anchor in Step 1. BUILD_AGENT_CERT_ARN=$(aws acm-pca issue-certificate \ --certificate-authority-arn $SUB_CA_ARN \ --csr fileb://build-agent.csr \ --signing-algorithm ML_DSA_65 \ --validity Value=30,Type=DAYS \ --template-arn arn:aws:acm-pca:::template/EndEntityClientAuthCertificate/V1 \ --query CertificateArn --output text) aws acm-pca get-certificate \ --certificate-authority-arn $SUB_CA_ARN \ --certificate-arn $BUILD_AGENT_CERT_ARN \ --query Certificate --output text > build-agent-mldsa.pem # In production, store the private key in a TPM or HSM rather than as a plaintext file. aws_signing_helper credential-process \ --certificate build-agent-mldsa.pem \ --private-key build-agent-mldsa-key.pem \ --trust-anchor-arn arn:aws:rolesanywhere:us-east-1:111122223333:trust-anchor/ta-id \ --profile-arn arn:aws:rolesanywhere:us-east-1:111122223333:profile/profile-id \ --role-arn arn:aws:iam::111122223333:role/PQCBuildAgentRole ヘルパーは、ビルドロールに権限が限定された短期間有効な AWS Security Token Service (AWS STS) の認証情報を生成するため、長期間有効な AWS アクセスキーが不要になります。本番環境では、Trusted Platform Module (TPM)、HSM、ファイルのアクセス許可を制限した暗号化認証情報ストアなど、ハードウェアベースのストレージで ML-DSA プライベートキーを保護してください。ここで示しているプレーンテキストファイルのパスは、デモンストレーション用です。このプライベートキーはコード署名インフラストラクチャへのアクセスを認可するものなので、他の署名キーと同等のレベルで保護する必要があります。Linux のビルドエージェントでは、少なくともファイルの所有者をサービスアカウントにしたうえで、 chmod 400 でアクセスを制限してください。また、PKCS#11 プロバイダーを使用して、未加工のキーをディスクに一切保存しない構成も検討してください。 検証とポリシーの適用 署名アーキテクチャの強さは、検証の強さで決まります。署名を生成するだけでは全体の半分にすぎません。残りの半分は、デプロイパイプライン、Kubernetes のアドミッションコントローラー、パッケージをインストールするエンジニアなど、アーティファクトをデプロイするシステムや人に対して、アーティファクトのデプロイや実行の前に署名を検証し、信頼できるかどうかを判断するための具体的な手段を提供することです。 信頼チェーンの配布 検証者が署名を確認するには、まずコード署名証明書を発行した CA を信頼している必要があります。この信頼はトラストストアによって確立されます。トラストストアとは、システムが信頼できるものとして扱うルート CA 証明書をローカルにまとめたものです。トラストストアは、オペレーティングシステム (Linux の /etc/pki/ca-trust/ 、macOS の Keychain など)、言語ランタイム (Java の cacerts )、コンテナベースイメージ、カスタムアプリケーションの設定などに存在します。 この記事で構築するようなプライベート PKI 階層の場合、ルート CA 証明書はデフォルトのパブリックトラストストアには含まれていません。署名を検証するすべてのシステムのトラストストアに、ルート CA 証明書を明示的に追加する必要があります。一般的な方法は次のとおりです。 ビルドプロセスでルート CA 証明書をコンテナベースイメージに組み込む 構成管理 ( AWS Systems Manager Parameter Store 、 AWS Secrets Manager 、または既存の構成ツール) を通じて配布する バージョニングとアクセスログ記録を有効にした内部の S3 バケットで公開する 保護対象のイメージと一緒に、OCI アーティファクトとして Amazon ECR に保存する トラストストアの管理は、認証情報の管理と同じくらい厳密に行ってください。攻撃者が不正なルート証明書をトラストストアに挿入できれば、偽造した署名を有効に見せかけることができてしまいます。トラストストアへの書き込みアクセスを制限し、AWS CloudTrail またはシステムレベルの監査ログで変更を監査してください。 証明書チェーンをエクスポートするには、ルート CA に加えて、署名の検証に関係する証明書を発行する下位 CA をエクスポートします。 # Export the root CA certificate aws acm-pca get-certificate-authority-certificate \ --certificate-authority-arn <root-ca-arn> \ --query Certificate --output text > root-ca.pem # Export the subordinate CA certificate. Select only the Certificate field: for a # subordinate CA this call also returns CertificateChain, and --output text would # print both on one tab-separated line, producing a file that OpenSSL can't parse. aws acm-pca get-certificate-authority-certificate \ --certificate-authority-arn <sub-ca-arn> \ --query Certificate --output text > sub-ca.pem # Bundle the full chain for verifiers cat root-ca.pem sub-ca.pem > trust-chain.pem 検証者はこのチェーンを使用して、コード署名のパブリックキーが信頼できる CA によって発行されたものであることを確認します。 ウォークスルーを簡潔にするため、この記事の CA は失効設定なしで作成しており、以降の検証コマンドでも失効ステータスは確認しません。本番環境では、下位 CA に証明書失効リスト (CRL) または OCSP (Online Certificate Status Protocol) レスポンダーを設定してください (AWS Private CA ユーザーガイドの「 AWS Private CA 証明書の失効方法を計画する 」を参照してください。どちらも ML-DSA CA で使用できます)。CRL を使用する場合は、信頼チェーンと一緒に CRL を配布し、オプション -crl_check -CRLfile <crl-file> を後述の openssl verify コマンドに追加します。 <crl-file> には、AWS Private CA が S3 バケットに公開する CRL を指定します。これにより、失効したコード署名証明書は検証に失敗するようになります。 バイナリまたは SBOM の署名の検証 まずコード署名証明書を信頼チェーンに照らして検証し、想定どおりの署名者に発行されたコード署名証明書であることを確認します。そのうえでパブリックキーを抽出し、OpenSSL 3.5 で署名を検証します。2 つ目の確認は重要です。チェーンの確認だけでは、前のセクションで発行したビルドエージェント用のクライアント証明書を含め、CA 階層が発行したすべての証明書が受け入れられてしまいます。そのため、検証者の設定で想定するサブジェクトを固定してください。 # Step 1: Verify that the code-signing certificate chains to the trusted root CA and carries the # Code Signing extended key usage. -purpose codesign (OpenSSL 3.2 and later) rejects a certificate # that chains correctly but was issued for another purpose, such as a build agent's client # authentication certificate from the same subordinate CA. # trust-chain.pem contains the root CA and subordinate CA certificates distributed in the previous section. openssl verify -CAfile trust-chain.pem -purpose codesign code-signing-cert.pem # Confirm that the certificate was issued to the signer you expect. Replace <signer-cn> with the # common name in your code-signing certificate's subject. openssl x509 -in code-signing-cert.pem -noout -subject -nameopt RFC2253 | grep -q "CN=<signer-cn>" || { echo "Unexpected signer"; exit 1; } # Step 2: Extract the public key from the verified certificate. openssl x509 -in code-signing-cert.pem -pubkey -noout > signing-key.pem # Step 3: Verify the artifact signature using the trusted public key. openssl pkeyutl -verify \ -pubin -inkey signing-key.pem \ -in artifact.bin \ -sigfile artifact.bin.sig \ -rawin 検証に成功すると Signature Verified Successfully (署名の検証に成功しました) と出力され、終了ステータス 0 が返されます。検証に失敗すると Signature Verification Failure (署名の検証に失敗しました) と出力され、0 以外の終了ステータスが返されます。シェルスクリプトでは、各コマンドの終了ステータスを確認するか、 set -e を指定してブロックを実行してください。こうすることで、証明書チェーンの確認に失敗した場合は署名の検証前にスクリプトが停止し、署名の確認に失敗した場合は後続の処理がブロックされます。 SBOM の場合は、 sbom.statement.json を -in の入力ファイル、 sbom.statement.json.sig を -sigfile の署名ファイルとして指定して同じ 3 つのステップを実行し、さらに 4 つ目のステップとして、検証済みの Statement 内のサブジェクトダイジェストが、これからデプロイするアーティファクトのダイジェストと一致することを確認します。署名の検証によって Statement が本物であることが証明され、サブジェクトの確認によって Statement が別のアーティファクトではなくこのアーティファクトを記述していることが証明されます。比較に使うダイジェストは、Statement からではなく、必ずアーティファクト自体から取得してください。イメージの場合はレジストリから取得し、バイナリの場合はファイルから計算します。イメージの場合、このダイジェストはイメージ署名の検証に使用するダイジェストと同じものです。そのため、2 つの確認を組み合わせることで、この SBOM がこの署名済みイメージを記述していることを確かめられます。 # Step 4 (SBOM only): the signed Statement must name the image being deployed. # Resolve the digest from Amazon ECR, not from the Statement. IMAGE_DIGEST=$(aws ecr batch-get-image \ --repository-name myapp \ --image-ids imageTag=v1.2.0 \ --query 'images[0].imageId.imageDigest' --output text) SUBJECT_DIGEST=$(jq -r '.subject[0].digest.sha256' sbom.statement.json) [ "sha256:$SUBJECT_DIGEST" = "$IMAGE_DIGEST" ] || { echo "SBOM does not describe this image"; exit 1; } # Only now extract the SBOM for downstream tooling jq '.predicate' sbom.statement.json > sbom.json バイナリの場合は、サブジェクトダイジェストを sha256sum artifact.bin の出力と比較します。署名とサブジェクトのどちらかの確認に失敗した場合は、その SBOM を拒否してください。 デプロイ前のコンテナイメージ署名の検証 Amazon ECR の OCI リファラーアーティファクトから ML-DSA 署名をプルし、イメージマニフェストのダイジェストに対して検証します。 # Pull the signature referrer. ORAS 1.2 lists referrers under "manifests"; # ORAS 1.3 and later list them under "referrers". The jq filter accepts either. oras discover $ECR_URI@$IMAGE_DIGEST \ --artifact-type "application/vnd.example.mldsa-signature.v1" --format json | \ jq -r '(.referrers // .manifests)[0].digest' | \ xargs -I{} oras pull $ECR_URI@{} -o /tmp/sig/ # Re-derive the image digest and verify echo -n "$IMAGE_DIGEST" > /tmp/digest.txt openssl pkeyutl -verify \ -pubin -inkey signing-key.pem \ -in /tmp/digest.txt \ -sigfile /tmp/sig/image.mldsa.sig \ -rawin # Exit code 0 = image is authentic; non-zero = reject deployment 同じ oras discover コマンドに --artifact-type "application/vnd.example.mldsa-sbom-attestation.v1" を指定すると、SBOM アテステーションとその署名を取得できます。取得したら、サブジェクトの確認も含め、前のセクションで説明した手順で検証してください。ここで示した jq フィルターは、指定したタイプの最初のリファラーを取得します。レジストリがリファラーを返す順序には依存しないでください。また、イメージを再署名した後は、リファラーが複数存在することを想定しておく必要があります。本番環境の検証者は、そのタイプのリファラーをすべて確認し、トラストストアまでチェーンをたどれる証明書で少なくとも 1 つの署名が検証できた場合に、イメージを受け入れるようにしてください。最初のリファラーだけを確認する方法では、正しく署名されたイメージを誤って拒否することはあっても、署名されていないイメージを受け入れることはありません。 デプロイ時にこれらのチェックを適用するには、Kubernetes のアドミッションコントローラーでチェックを実行します。アドミッションコントローラーは、API サーバーがポッドを受け入れる前に呼び出すコンポーネントで、リクエストを拒否できます。アドミッションコントローラーは、検証用のアドミッション Webhook として独自に作成するか (Kubernetes ドキュメントの「 Dynamic Admission Control 」を参照)、 Open Policy Agent (OPA) Gatekeeper (OPA ポリシーエンジンで評価したポリシーを適用するアドミッション Webhook) を使用し、制約から呼び出される Gatekeeper の 外部データプロバイダー として検証手順をパッケージ化します。イメージ署名に基づいて Amazon EKS へのデプロイを制御する実例については、「 AWS Signer と Amazon EKS におけるコンテナイメージ署名の提供開始 」を参照してください。同記事では、Kyverno を使用してアドミッション時に AWS Signer の署名を検証しており、代替手段として Gatekeeper やカスタム Webhook についても説明しています。この記事の ML-DSA 署名リファラーは、これらのツールではそのまま検証できないカスタムアーティファクトタイプであるため、このセクションの検証手順は独自に用意したコードで実行します。どちらの設計でも、コントローラーはポッドがスケジュールされる前に実行され、Amazon ECR に有効な ML-DSA 署名リファラーがないイメージや、SBOM アテステーションがデプロイ対象のイメージを指定していないイメージを拒否します。 予防的コントロールと発見的コントロール 署名の検証によって、信頼されていないアーティファクトがデプロイ時に使用されるのを防げます。組織レベルのコントロールは、それよりも早い段階で、より広い範囲に適用されます。予防的コントロールは、チームが従来型の署名キーを新たに作成することを防ぎます。発見的コントロールはすべての署名オペレーションを記録するため、どのプリンシパルがいつ各アーティファクトに署名したかを監査できます。 予防的ガードレール。 セキュリティ上重要なアカウントで従来型の署名キーの作成をブロックし、新しい署名ワークロードすべてに ML-DSA の使用を強制するには、次のような AWS Organizations サービスコントロールポリシー (SCP) を使用します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RequirePQCSigningKeys", "Effect": "Deny", "Action": "kms:CreateKey", "Resource": "*", "Condition": { "StringNotLike": { "kms:KeySpec": "ML_DSA_*" }, "StringEquals": { "kms:KeyUsage": "SIGN_VERIFY" } } } ] } この SCP により、チームは RSA や ECDSA の署名キーを新たに作成できなくなり、新しいワークロードでは耐量子署名が唯一の選択肢になります。なお、この SCP で制限されるのはアルゴリズムファミリーであり、パラメータセットではありません。そのため、このアーキテクチャでは使用しない ML-DSA-44 キーの作成は引き続き許可されます。このシリーズのパート 2 は、まさにこの点から始まります。パート 2 では、完全なアルゴリズムポリシー (その例では ML-DSA-65 と ML-DSA-87 を承認し、ML-DSA-44 を除外) を、SCP、IAM のアクセス許可の境界、AWS KMS キーポリシーで kms:KeySpec 条件キーを使用した多層的なコントロールとして表現する方法を紹介します。さらに、既存のキーの使用を制限する方法や、アルゴリズムの条件キーがない AWS Private CA などの領域を管理する方法も説明します。この SCP とパート 2 のパラメータセット用の SCP は組み合わせて使用します。両方をアタッチすると、新しい署名キーはすべて承認済みのパラメータセットを使用しなければならなくなります。 監査証跡。 AWS CloudTrail は、すべての kms:Sign および kms:Verify API コールをログに記録し、各アーティファクトがいつ、どのプリンシパルによって署名されたかを示す変更不可能な記録を提供します。組織の証跡を使用し、Amazon Athena でそのログをクエリすることで、複数のアカウントにわたる署名アクティビティを分析し、デプロイイベントと関連付けてください。 規制のタイムラインと推奨アクション 次の表は、規制上のマイルストーンと、この記事で説明したアーキテクチャを使用して今すぐ実行できる具体的なアクションの対応を示しています。この情報は一般的な情報提供のみを目的としたものであり、法律上またはコンプライアンス上の助言ではありません。組織固有の義務については、法務チームやコンプライアンスチームに確認してください。PQC に関する世界各国の規制タイムラインの概要については、「 Migrating to Post-Quantum Cryptography 」を参照してください。 規制 期限 規制の文言 AWS でのアクション CNSA 2.0: サポートと優先 2025 年 (適用中) CNSA 2.0 タイムライン (2022 年 9 月、FAQ v2.1 は 2024 年 12 月): ソフトウェアとファームウェアの署名は、2025 年までに CNSA 2.0 アルゴリズムを「サポートし優先する (support and prefer)」必要がある AWS KMS で ML-DSA キーを作成し、既存の従来型の署名と並行して ML-DSA によるアーティファクトの署名を開始する CNSA 2.0: 新規システムの調達 2027 年 1 月 CNSA 2.0 FAQ v2.1 (2024 年 12 月): 「2027 年 1 月 1 日以降、すべての新規 NSS 調達は、デプロイ時に CNSA 2.0 に準拠している必要がある (All new NSS acquisitions must be CNSA 2.0 compliant at deployment, effective 1 January 2027)」 ML-DSA PKI を本格運用し、IAM Roles Anywhere のトラストアンカーで ML-DSA を使用し、すべての新規ビルドに ML-DSA 署名を付与する EU サイバーレジリエンス法 2027 年 12 月 11 日 規則 (EU) 2024/2847、附属書 I、第 I 部 (2)(f): 製品は「保存、送信、またはその他の方法で処理されるデータ (個人データかその他のデータかを問わない)、コマンド、プログラム、設定の完全性を、ユーザーが許可していない操作や変更から保護し、破損について報告する (protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions)」必要がある。第 II 部 (7): 製造業者は「アップデートを安全に配布するメカニズムを提供する (provide for mechanisms to securely distribute updates)」必要がある EU 市場向けに出荷するすべてのソフトウェアアップデートに ML-DSA コード署名を適用し、すべてのリリースに署名済みの SBOM を添付する CNSA 2.0: 排他的使用 2030 年 CNSA 2.0 タイムライン: ソフトウェアとファームウェアの署名は、2030 年までに CNSA 2.0 アルゴリズム「のみを使用する (exclusively use)」必要がある サプライチェーンから従来型の署名キーを削除し、SCP によって ML-DSA キー以外の作成を禁止する PCI DSS 4.0 要件 12.3.3 2025 年 3 月から必須 PCI DSS v4.0.1、要件 12.3.3: 「使用中の暗号スイートとプロトコルを文書化し、少なくとも 12 か月に 1 回レビューする (Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months)」(使用中の暗号スイートとプロトコルの最新のインベントリを含む) AWS KMS で暗号インベントリを文書化し、ML-DSA キーと従来型のキーを区別するタグを付け、移行の進捗状況を追跡する NSS のお客様およびその他の CNSA 2.0 採用組織への注意事項: CNSA 2.0 は、NSA が NSS に要求する耐量子アルゴリズムスイートです。NSS とは、機密情報を扱う連邦システム、または諜報、暗号、軍の指揮統制、兵器の各機能をサポートする連邦システムを指します。CNSA 2.0 では、ソフトウェアとファームウェアの署名を含め、あらゆる署名用途で ML-DSA を使用する場合、ML-DSA-87 パラメータセットのみが許可されています。(ソフトウェアとファームウェアの署名については、ステートフルなハッシュベースの方式である LMS と XMSS も承認されていますが、この記事では扱いません。) この記事のコード署名の例で使用している ML-DSA-65 パラメータセットは、商用ワークロードには適していますが、NSS では許可されていません。CNSA 2.0 が拘束力を持つのは NSS に対してのみですが、その範囲を大きく超えて自主的に採用されています。採用しているのは、米国および同盟国で米国の防衛市場や諜報市場に製品を供給し、その製品が NSS の要件を満たす必要があるサプライヤーや、米国内外の商用組織です。商用組織が CNSA 2.0 を保守的なベースラインとして採用するのは、CNSA 2.0 が NIST の最高セキュリティカテゴリを指定しており、後でパラメータの選択を見直す必要がなくなるためです。システムが CNSA 2.0 の対象範囲に該当する場合や、CNSA 2.0 への準拠を選択した場合は、すべての署名キーと証明書で ML-DSA-87 を使用してください。このシリーズの パート 2 では、この置き換えを強制可能にする方法を紹介します。パート 2 の例で ML-DSA-44 を除外している kms:KeySpec のコントロールをそのまま利用し、 ML_DSA_87 を唯一の承認済みキー仕様として指定できます。 米国政府と EU の商用市場の両方を対象とする組織にとって、2027 年 1 月と 2027 年 12 月の期限は 1 つの移行期間に集約されます。今すぐ着手すれば、テスト、キーローテーションの計画、証明書チェーンの検証のための余裕を確保できます。 クリーンアップ これまでの手順と例では、多数の暗号リソースを作成しました。AWS Private CA では CA ごとに、AWS KMS ではキーごとに月額料金が発生します。継続的に料金が発生しないように、使用していないリソースは削除してください。まず、既存のリソースを一覧表示し、繰り返し実行したことで生じた重複も含めて、作成したすべてのリソースを把握します。以下のコマンドは 1 つのリージョンを対象とします。複数のリージョンで作業した場合は、リージョンごとに --region を指定してコマンドを繰り返し実行してください。 # List every private CA with its type, status, key algorithm, and subject. # A CA you already deleted shows DELETED until its restoration window ends. aws acm-pca list-certificate-authorities \ --query 'CertificateAuthorities[].[Arn,Type,Status,CertificateAuthorityConfiguration.KeyAlgorithm,CertificateAuthorityConfiguration.Subject.CommonName]' \ --output table # List every ML-DSA key in AWS KMS with its state and creation date. # A key already scheduled for deletion shows PendingDeletion. for KEY_ID in $(aws kms list-keys --query 'Keys[].KeyId' --output text); do aws kms describe-key --key-id "$KEY_ID" \ --query 'KeyMetadata.[KeyId,KeySpec,KeyState,CreationDate]' --output text done | grep ML_DSA # Show which alias points at which key. A key that no alias points at # is usually a leftover from an earlier run. aws kms list-aliases --query 'Aliases[].[AliasName,TargetKeyId]' --output text | grep -v '^alias/aws/' AWS Private CA には、CA が発行した証明書を一覧表示するコマンドはありません。後述の失効手順でシリアル番号が必要な場合は、 aws acm-pca create-certificate-authority-audit-report を使用して監査レポートを生成してください。このコマンドは、CA が発行または失効させたすべての証明書の一覧を、サービスに書き込みアクセスを許可した S3 バケットに出力します。 一覧で見つかった余分なコピーも含めて不要なリソースをそれぞれ削除し、再度一覧を表示して何も残っていないことを確認します。 # Revoke any issued end-entity certificates while the subordinate CA is still active aws acm-pca revoke-certificate \ --certificate-authority-arn <sub-ca-arn> \ --certificate-serial <serial-number> \ --revocation-reason CESSATION_OF_OPERATION # Delete the IAM Roles Anywhere resources that reference the CA aws rolesanywhere delete-profile --profile-id <profile-id> aws rolesanywhere delete-trust-anchor --trust-anchor-id <trust-anchor-id> # Delete the build agent role that the profile referenced, and the local copy of its private key aws iam delete-role-policy --role-name PQCBuildAgentRole --policy-name pqc-code-signing aws iam delete-role --role-name PQCBuildAgentRole rm -f build-agent-mldsa-key.pem # Delete the AWS KMS code-signing key (schedule 7-day waiting period). # ScheduleKeyDeletion doesn't accept an alias, so resolve the key ID first. KEY_ID=$(aws kms describe-key --key-id alias/pqc-code-signing \ --query KeyMetadata.KeyId --output text) aws kms schedule-key-deletion --key-id $KEY_ID --pending-window-in-days 7 # Remove the alias. It survives key deletion and would otherwise show up in the # listing above on your next run. aws kms delete-alias --alias-name alias/pqc-code-signing # Disable and delete the subordinate CA aws acm-pca update-certificate-authority \ --certificate-authority-arn <sub-ca-arn> --status DISABLED aws acm-pca delete-certificate-authority \ --certificate-authority-arn <sub-ca-arn> --permanent-deletion-time-in-days 7 # Disable and delete the root CA aws acm-pca update-certificate-authority \ --certificate-authority-arn <root-ca-arn> --status DISABLED aws acm-pca delete-certificate-authority \ --certificate-authority-arn <root-ca-arn> --permanent-deletion-time-in-days 7 長期的な運用を前提にこの構成を応用する場合は、ログの保持について計画してください。CloudTrail のイベント履歴に保持されるのは直近 90 日間の管理イベントのみであり、証跡の代わりにはなりません。前述の監査証跡を実現するには、保持要件に合ったライフサイクルポリシーとアクセスコントロールを設定した S3 バケットに配信する証跡を作成してください。 まとめ この記事では、AWS KMS での ML-DSA 署名、AWS Private CA での ML-DSA 証明書階層、IAM Roles Anywhere を通じた ML-DSA ワークロード認証を組み合わせて、AWS で耐量子ソフトウェアサプライチェーンを構築する方法を紹介しました。このアーキテクチャは、認証されたビルドエージェントから、署名済みのバイナリ、コンテナイメージ、SBOM、デプロイ時の検証とポリシーの適用に至るまで、パイプライン全体をカバーしています。 この記事で使用した ML-DSA の機能は、いずれも一般提供されています。AWS Private CA と IAM Roles Anywhere は、すべての商用 AWS リージョン、AWS GovCloud (米国) リージョン、中国リージョンで ML-DSA をサポートしています。AWS KMS は、商用 AWS リージョンで ML-DSA をサポートしています。標準化団体やサードパーティのツールによる PQC 対応が確定するのを待つ必要はありません。必要な基本要素は既にそろっています。 まずは AWS KMS で最初の ML-DSA キーを作成し、テスト用のアーティファクトに署名してみてください。次に PKI 階層を構築し、ビルドエージェント向けに IAM Roles Anywhere を統合して、コンテナと SBOM のワークフローに ML-DSA 署名を追加していきましょう。 パイプラインの構築は、作業の半分にすぎません。残りの半分は、アカウント、チーム、標準が変化しても、選択したアルゴリズムが引き続き確実に適用されるようにすることです。これが、このシリーズのパート 2「 SCP と IAM による ML-DSA アルゴリズムポリシーの強制 」のテーマです。パート 2 は、この課題を担当するセキュリティチームとガバナンスチームを対象としています。 詳細については、以下を参照してください。 AWS における耐量子署名、パート 2: SCP と IAM による ML-DSA アルゴリズムポリシーの強制 Post-quantum cryptography on AWS ML-DSA keys in AWS KMS AWS Private CA と AWS KMS を使用したポスト量子 (ML-DSA) コード署名 IAM Roles Anywhere post-quantum digital certificates AWS ポスト量子暗号への移行計画 Harshvardhan Chunawala Harshvardhan は AWS の Solutions Architect 兼 Security SME です。Amazon Leo、Amazon Security、AWS Agentic AI と連携し、チーム横断の取り組みを主導しています。クラウドセキュリティ分野で 10 年以上の経験を持つ Golden Jacket 受賞者で、カーネギーメロン大学ではアドバイザリーボードメンバー、客員教員、研究者を務めています。世界中の経営幹部、企業のリーダー、スタートアップの創業者に対し、安全でスケーラブルなクラウドプラットフォームの構築について助言しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの大久保です。今週から週刊AWS を皆様にお届けする新たなメンバーとして活動させていただきます。どうぞよろしくお願いします！ では今週も 週刊AWS をお届けします。 11 月 5 日 (木) に、オンラインのワークショップ「 開発ライフサイクルで学ぶ Amazon ECS コンテナセキュリティ実践ワークショップ 」を開催します。コンテナのビルドからデプロイ、ランタイムまで、各段階でセキュリティをどう担保するかを座学で整理したうえで、AWS Fargate 上の Amazon ECS を題材に、Amazon Inspector による脆弱性の検知や Amazon GuardDuty Runtime Monitoring による不審な通信の検知をハンズオンで体験できます。今回ご紹介するアップデートにも GuardDuty や AWS Security Hub のものがありますので、コンテナのセキュリティ対策を見直したい方はぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月5日週の主要なアップデート 10/5(月) 音声エージェント向けに推論能力を改善した Amazon Nova 2.5 Sonic を発表 AWS は、リアルタイム音声エージェント向け speech-to-speech モデルの最新版である Amazon Nova 2.5 Sonic の一般提供を発表しました。Nova 2 Sonic と比較して推論、指示追従、ツール呼び出し精度が改善され、レイテンシも低減しています。音声エージェントが会話の文脈を保持したまま、注文照会や返品処理といった複数ステップのタスクをツール連携で完了できます。同時に GA となった Strands Bidi Agents と組み合わせることで、少ないコード量で本番向け音声エージェントを構築できます。バージニア北部、オレゴン、ストックホルム、東京の 4 リージョンで利用でき、料金は Nova 2 Sonic と同額です。 AWS Client VPN がデバイスポスチャ評価をサポート AWS Client VPN が、接続元デバイスのセキュリティ状態を検証するデバイスポスチャ評価に対応しました。CrowdStrike、Jamf、JumpCloud をデバイストラストプロバイダーとして設定し、コンプライアンススコア、ディスク暗号化状態、リスクレベルなどのシグナルを Cedar ポリシーで評価して、要件を満たすデバイスだけに接続を許可できます。評価は接続時だけでなくセッション中も 5 分ごとに行われ、非準拠になったデバイスは自動的に切断されます。接続を切断せずログのみ記録するシャドウモード (モニタリングモード) も用意されており、Client VPN が利用できるすべてのリージョンで追加料金なしで利用できます。 Amazon EC2、Amazon Machine Image の共有タグを導入 Amazon EC2 は AMI のタグを共有先アカウントから参照できるようにする AMI タグ共有機能を提供開始しました。タグキーに ec2:SharedTag/ プレフィックスを付けるだけで、個別アカウント共有、AWS Organizations の組織・OU 共有、パブリック共有のいずれでも、共有先の全アカウントがそのタグを参照できます。従来必要だった SNS + Lambda などによるタグ複製ワークフローが不要になります。共有タグは共有先では読み取り専用で、オーナー側の 1 リソースあたり 50 タグのクォータのみを消費します。全リージョンで追加費用なしで利用できます。 AWS Continuum for Penetration Testing が CI/CD パイプラインに統合された継続的ペネトレーションテストに対応 AWS Continuum for Penetration Testing (旧 AWS Security Agent) が、CI/CD パイプラインへの直接統合をパブリックプレビューとして提供開始しました。GitHub Actions、GitLab CI/CD、Bitbucket Pipelines、Azure DevOps Pipelines の 4 つのプラットフォームに対応し、デプロイ後のゲートとしてペネトレーションテストを実行できます。テストは前回クリアしたコミットからの差分に自動的にスコープされ、攻撃対象領域に影響しない変更は遅延なくパイプラインを通過します。設定済みの重大度しきい値 (デフォルトは HIGH) 以上の検出事項があると本番への昇格をブロックし、修正後のプッシュで自動的に再テストが実行されます。 AWS IAM Identity Center が Identity Store のネットワークアクセス制御をサポート AWS IAM Identity Center のユーザー・グループを格納する Identity Store に対して、リクエスト元ネットワークに基づくアクセス制御を設定できるようになりました。Identity Store API には VPC エンドポイント経由の強制、送信元 VPC の限定、許可 IP レンジの指定ができ、SCIM API には許可 IP レンジの指定ができます。設定は UpdateIdentityStore API を AWS CLI または SDK から呼び出して行い、デフォルトでは無効です。IAM Identity Center が提供される全リージョンでご利用可能です。SCIM トークン漏洩時の被害範囲限定や、組織のデータ境界 (data perimeter) 戦略の強化に使えます。 Amazon Redshift が Apache Iceberg マテリアライズドビューの作成とリフレッシュに対応 Amazon Redshift が、結果を Apache Iceberg テーブルとして Amazon S3 または S3 Tables に保存するマテリアライズドビュー (MV) に対応しました。CREATE MATERIALIZED VIEW … USING ICEBERG という SQL で作成でき、結果は AWS Glue Data Catalog に登録されます。Amazon Athena、Apache Spark (Amazon EMR / AWS Glue)、Trino、Snowflake など Iceberg 互換エンジンから追加設定なしで読み取れます。リフレッシュは手動実行で、COUNT / SUM 集計と内部結合については変更分のみを再計算するインクリメンタルリフレッシュが動作します。Redshift Serverless と RG (Graviton) プロビジョンドインスタンスで利用でき、RA3 / DC2 では利用できません。 10/6(火) AWS Batch が Amazon CloudWatch へのジョブメトリクス発行に対応 AWS Batch がジョブのライフサイクルに関するメトリクスを Amazon CloudWatch の AWS/Batch 名前空間へ自動発行するようになりました。追加料金なしで、ジョブキューごとの状態遷移数 (送信、実行中、成功、失敗など) と、状態間の所要時間 (送信から実行可能まで、実行時間など) を確認できます。これまで EventBridge と Lambda を組み合わせて自前で構築する必要があったジョブ監視を、CloudWatch のダッシュボードとアラームだけで構成できます。AWS Batch が利用可能なすべてのリージョンで提供されます。 10/7(水) Claude Haiku 5.5 が AWS で利用可能に Claude 5.5 ファミリーで最速・最も効率的なモデルである Claude Haiku 5.5 の提供を開始しました。Anthropic によると、ほとんどのタスクで Claude Haiku 4.5 より約 75% 低コストで、トークン単価は入力 $0.10 / 100 万トークン、出力 $0.50 / 100 万トークンからです。Haiku として初めて effort パラメータ (low / medium / high / xhigh / max) に対応し、タスクごとにコストと性能のバランスを調整できます。コンテキストウィンドウは 100 万トークン、最大出力は 128K トークンです。アクセス経路は Amazon Bedrock と Claude Platform on AWS の 2 つで、データレジデンシーや AWS 管理機能を重視する場合は Bedrock、Anthropic ネイティブの最新機能を使いたい場合は Claude Platform on AWS を選択します。 AWS Config が 77 の新しいリソースタイプをサポート AWS Config が新たに 77 種類のリソースタイプの記録に対応しました。対象には Amazon Q Business (6 種類)、Amazon S3 Files (4 種類)、AWS PCS (3 種類)、各種メディアサービス、GuardDuty や Inspector などのセキュリティサービスが含まれます。全リソースタイプの記録を有効化している環境では、設定変更なしで新しいリソースタイプの追跡が自動的に始まります。追加されたリソースタイプは Config rules と Config アグリゲーターでも利用できます。記録される Configuration Item (CI) が増えるため、コストへの影響を事前に確認することを推奨します。 10/8(木) Amazon GuardDuty RDS Protection が Aurora および RDS データベースでのデータ流出とデータ破壊を検出可能に Amazon GuardDuty の RDS Protection が拡張され、従来のログイン異常検知に加えて、Aurora PostgreSQL と Amazon RDS for PostgreSQL を対象としたデータ流出 (Exfiltration) およびデータ破壊 (Impact) の検出に対応しました。RDS Protection for data activity として提供され、ML による異常検知と脅威インテリジェンスを組み合わせてデータベースのクエリパターンを継続的に監視します。エージェントや追加インフラ、データベース側の設定変更は不要です。既存の RDS Protection (ログインアクティビティ) のアドオンとして有効化でき、アカウント・リージョンごとに 30 日間の無料トライアルが利用できます。 Amazon RDS for Oracle がマイナーバージョンアップグレードのプリチェックとパッチ適用ダウンタイムを短縮するのに役立つ新しい RDS イベントをサポート Amazon RDS for Oracle で、マイナーバージョンアップグレードの事前チェック (プリチェック) をユーザー自身が任意のタイミングで実行できるようになりました。新しいプロシージャ rdsadmin.rdsadmin_precheck_tasks.precheck_minor_upgrade を使うと、ストレージ不足や無効なトリガーなど、アップグレードを中断させる問題をメンテナンスウィンドウ前に検出して修正できます。あわせて、パッチ適用中に DB インスタンスが接続受付を再開した時点で発行される新イベント RDS-EVENT-0596 が追加されました。残りのメンテナンスタスクはオンラインで完了するため、このイベントを契機にアプリケーションを復帰させることで、パッチ適用時のアプリケーションダウンタイムを短縮できます。本機能は RDS for Oracle が利用可能なすべての AWS 商用リージョンと AWS GovCloud (US) リージョンで追加費用なしに利用できます。 AWS Cost Explorer、Budgets、Dashboards が Amazon Bedrock の product attributes に対応 AWS Cost Explorer、AWS Budgets、AWS Cost Management Dashboards で、Amazon Bedrock のコストを product attributes (製品属性) という新しいディメンションで分析できるようになりました。属性はモデル、モデルプロバイダー、推論タイプ、機能の 4 種類です。Cost Explorer と Dashboards ではこれらの属性によるグループ化とフィルタリング、Budgets では予算のフィルタリングに利用できます。タグの事前設定なしで「どのモデルがいくら使っているか」を標準の請求ツール上で確認できるため、ファイナンスチームやプラットフォームチームの Bedrock コスト管理に役立ちます。追加料金なしで利用できます。 10/9(金) Amazon Quickで、ブランドイメージに沿ったプレゼンテーションやドキュメントを作成するためのブランドテンプレートをサポート Amazon Quick で、組織の承認済みブランドテンプレートをアップロードし、ビジュアルアイデンティティに沿ったプレゼンテーションやドキュメントを生成できるようになりました。ブランドマネージャーが PowerPoint または Word のテンプレートを一度登録すると、Quick が色、フォント、ロゴ、レイアウト、ブランドルールを抽出し、組織全体に公開できます。利用者はチャットのたびにテンプレートファイルを探して添付する必要がなくなります。本機能は Amazon Quick デスクトップアプリで一般提供を開始しており、Enterprise エディションでのみ利用できます。 AWS Lambda がセルフマネージド Apache Kafka イベントソースの OAuth 認証をサポート AWS Lambda のセルフマネージド Apache Kafka イベントソースマッピング (ESM) が、OAuth 2.0 (SASL/OAUTHBEARER) 認証に対応しました。対象は顧客が自前で運用する Kafka クラスターに加え、Confluent Cloud、Aiven、Redpanda などのマネージドサービスです。Amazon Cognito や Okta などのエンタープライズ IdP で Lambda の Kafka コンシューマーを認証できるため、Kafka クラスターと Lambda で同一の ID ガバナンスを適用できます。従来は SASL/PLAIN、SASL/SCRAM、mTLS のみの対応だったため、OAuth 必須の規制産業では ESM を利用できませんでした。セルフマネージド Kafka ESM が利用可能なすべての AWS 商用リージョンで利用できます。 AWS Security Hub が findings の S3 への CSV / JSON 形式エクスポートに対応 AWS Security Hub が、findings を Amazon S3 バケットへ CSV または JSON (OCSF) 形式でエクスポートする機能を発表しました。コンソールの各 findings ページ (All Findings、Threats、Exposure、Vulnerabilities、Posture Management、Sensitive Data) から、適用中のフィルタを引き継いだままオンデマンドでエクスポートを開始できます。コンプライアンスレポートや監査証跡の作成のために、EventBridge などを使った抽出パイプラインを自前で構築・保守する必要がなくなります。本機能は Security Hub が利用可能なすべてのリージョンで提供されています。 それでは、また来週お会いしましょう！ 著者について 大久保 裕太(Yuta Okubo) 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっているソリューションアーキテクトで、IoT 領域を得意としています。好きな AWS サービスは AWS IoT Core です。最近は、デスクワークによる姿勢の崩れを筋トレで解消しようとしています

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 さて、 re:Invent 2026 のセッションカタログ はもうチェックされましたでしょうか？2200を超えるセッションが登録されておりカタログを参照するだけでも楽めます。 10月になり、builders.flash も生成 AI 関連の記事が 新規公開されました。ぜひこちらもご覧ください。 builders.flash 記事 builders.flash 記事「 既存プロダクトに Amazon Bedrock AgentCore runtime でLLM ワークフロー基盤を後付けした設計判断 」 株式会社うるるの入札情報速報サービス「NJSS」には、エリアと業務内容を自然な言葉で入力すると LLM を使ったワークフローが入札市場の分析レポートを生成する「AI リサーチ機能」が、2026 年 6 月下旬に β 版としてリリースされました。この機能を Laravel（PHP）で動く既存バックエンドに後付けするにあたっての 5 つの設計判断がテーマです。LangGraph のワークフローの実行環境に Amazon Bedrock AgentCore runtime を選んだ理由、SSE（Server-Sent Events）で配信する API を FastAPI の別サービスとして AWS Fargate 上に分けた理由、会話履歴と実行状態を Amazon DynamoDB に保存した理由が、ブラウザを閉じても処理を完走させる要件とあわせて率直に書かれています。既存プロダクトに LLM ワークフローを追加するときの判断材料になります。 builders.flash 記事「 AI にデータを渡すと何が変わる ? – Amazon Quick の構造化データ活用とセマンティックレイヤー – 」 Amazon Quick で構造化データ（データベースや CSV などの数値データ）を自然言語で分析する際、その精度を左右するのが「セマンティックレイヤー」です。データセットにビジネスコンテキストを自然言語で付与する Dataset Enrichment と、複数のデータセットをリレーション定義で論理的に統合する Multi-Dataset Topic の 2 つの仕組みが解説の中心です。金融事業会社の取引データを例に、社内用語の「対面」をデータ上の値「店頭」に対応づける定義や「売上」が指すカラムの指定で AI の回答がどう変わるか、顧客マスターとの自動 JOIN で地域別の融資延滞件数に答えられるようになる様子を画面イメージで示しています。AI の解釈や前提、計算ロジックをボタンひとつで確認できる Chat Explainability にも触れています。毎回プロンプトで背景を説明する代わりに、データとビジネスルールを事前に仕込んでおくという考え方を整理するのに役立つ内容です。 builders.flash 記事「 サーバーレス30秒クッキング 「作りたいもの」を書くと構成図とサンプルコードを作ってくれる AI エージェント 」 AWS Summit Japan の Serverless TFC ブースで展示した「サーバーレス 30 秒クッキング」は、来場者が作りたいアプリのアイデアを入力すると Strands Agents SDK で作った AI エージェントがサーバーレス構成を設計し、AWS 公式アイコンの構成図と AWS CDK のコードを生成して QR コードで持ち帰れるデモアプリです。その制作の裏話と、ブースで分かったことを紹介しています。技術的な核は、エージェントに diagram_output という自作ツールを 1 つ持たせ、サービス・接続・グループを構造化した JSON として出力させている点です。あわせて、AWS Agent Plugins として公開されている AWS Serverless プラグインの Skills でベストプラクティスを構成に反映させる工夫や、人が待つ構成図の生成には Claude Sonnet、裏側の IaC 生成には Claude Opus を使うというモデルの使い分けも紹介しています。30〜50 秒の待ち時間をリスのシェフ（シェフリス）の調理アニメーションに見立てた体験設計も読みどころです。現在はサンプルコードとして公開できるよう準備が進められています。 それでは 10 月 5日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 株式会社アテナが Claude Code on Amazon Bedrock で実現した、非エンジニア向け生成 AI 全社展開 」 BPO サービスを提供する株式会社アテナ様が、非エンジニアの社員を中心とした生成 AI の全社利用基盤を Amazon Bedrock で構築しました。Claude の Team プランを 100 名弱で契約していましたが、使わない社員の分まで固定費がかかる点や、静的な API キーを端末に長期保存させたくない点、処理を日本国内に限定したい点が課題でした。そこで Claude Desktop の接続先を Amazon Bedrock に向ける構成を 2〜3 か月で作り上げました。認証は Microsoft Entra ID との OIDC フェデレーションで行い、AWS STS から有効期限 12 時間の一時的な認証情報を取得するため、端末に静的な API キーは置きません。推論には、東京・大阪リージョンにのみルーティングされる日本国内クロスリージョン推論を使います。誰が使えるかは Entra ID、AWS 上の権限は IAM ロール、端末の接続先や機能は MDM で配布するレジストリで統制しています。有志 22 名で 9 営業日の費用を実測すると、月額換算の合計は Team プラン 22 席分の約 3.9 倍でした。一方で 1 稼働日あたりの費用には利用者間で約 51 倍の開きがあり、利用の偏りがはっきり分かりました。「どのサービスを使うか」より「既存の ID 運用と端末管理にどう載せて統制するか」が問われるという指摘は、全社展開を検討する企業の参考になります。 ブログ記事「 AI-Driven Modernization – AIエージェントに規律ある移行作業をさせる「AI Modernization Flow」を公開しました 」 AWS Japan では、従来は過大な工数やコストで断念していたアプリケーションのモダナイゼーションを AI で実現する取り組みを「AI-Driven Modernization」と呼んでいます。その中核となるツールが、AWS Samples に公開した AI Modernization Flow（AIMF）です。ビジネスロジックを変えずに技術スタックを最新化する Refactor 型の移行作業を、Kiro や Claude Code などの AI エージェントに決められた手順で進めさせるワークフローです。AI に「移行して」と頼むだけでは、ビルドもテストも通ったのに一部の機能が動かない、機能を勝手に削る、実装の理由を説明できないといった問題が繰り返し起きていました。AIMF は移行を分析から最終確認までの 6 つの Phase で進めます。インターフェースの変更や機能の除外、Phase の境界では AI が作業を止めて人の判断を求め、その理由を ADR（Architecture Decision Record）に残します。工程の完了はビルドの成功ではなく、検証スクリプトによるテストで判定します。約 15 万行の Apache Roller を Java 11 から Java 21 や Jakarta EE 10 の構成へ、人とのやり取りを含めて 4 日間で移行した実例も紹介されています。 ブログ記事「 Amazon Bedrock の自動推論ポリシーの自動改善 」 Amazon Bedrock Guardrails の自動推論チェック（Automated Reasoning checks）は、形式検証で回答の正しさを証明する機能です。ただ、自動推論ポリシーをテストで検証しながら仕上げる反復的なチューニングが、ポリシー開発の最大のボトルネックになっていました。今回発表されたポリシーの自動改善では、改善エンジンが失敗したテストを診断して形式論理の修正案を提示します。お客様が承認した変更だけが DRAFT ポリシーに反映されます。改善モードは 2 つです。自然言語から変数への変換は正しいのに検証結果が期待と合わないルールの問題には、ソースドキュメントと任意のフィードバックを基にルールや変数の変更を提案する Iterative Refinement を使います。TRANSLATION_AMBIGUOUS が返る変換のあいまいさには Ambiguous Variable Refinement が対応し、重複する変数の統合や明確な変数の説明を提案します。コンソールでは提案された差分とテストへの影響を確認してから、承諾か破棄を選びます。記事では人事ポリシーを例にしたウォークスルーと、4 つのベストプラクティスも紹介しています。訳注のとおり、2026 年 9 月現在、自動推論チェックが対応する言語は英語です。 ブログ記事「 Amazon Bedrock の自動推論チェックが変える生成 AI のコンプライアンス 」 別の大規模言語モデルに出力を評価させる LLM-as-a-judge パターンは、確率的なシステム同士の検証にとどまります。そのため、規制業界が求める形式的で監査可能な保証は得られません。Amazon Bedrock Guardrails の自動推論チェック（Automated Reasoning checks）は、数理論理学に基づく形式的検証で AI の出力を定義済みのルールと制約に照らして検証します。違反があれば、どのルールにどのような理由で違反しているかを特定します。記事では 6 つの業界の活用例を紹介しています。Amazon Logistics は電気自動車充電ポイントの設置提案のエンジニアリングレビューを約 8 時間から数分に、Lucid Motors は PwC および AWS と協力して予測の生成を数週間から 1 分未満に短縮しました。教育分野の First Education & Technology Group は PwC および AWS と協力し、Safer Technologies 4 Schools の原則を変換した 10 個の形式論理ルールで生徒向け生成 AI の応答を検証して、ルール設定の作業を最大 80%、継続的なコンプライアンスの運用負荷を 50% 削減しました。確率的な確信から数学的な証明へ進むための道筋を示す記事です。 ブログ記事「 Agent Skills で Amazon Bedrock の自動推論ポリシーのライフサイクルを自動化 」 Amazon Bedrock の自動推論チェック（Automated Reasoning checks）のポリシーを作るには、SMT-LIB（自動定理証明器の標準入力形式）でのルール記述や、ビルド・テスト・改善のループに慣れる必要があります。Agent Skills は、Anthropic が提供するオープンなフォーマットです。この記事では、そのスイートを使ってポリシーの構築からテスト、デプロイ、検証までをコーディングエージェントから一貫して行う方法を紹介しています。スイートは builder、reviewer、tester、debugger、deployer、validator の 6 つのスキルで構成され、ライフサイクルの各段階を 1 つずつ担当します。Kiro、Claude Code、Cursor、Codex など、このフォーマットに対応するエージェントにインストールできます。育児休暇の人事ポリシーを例にしたウォークスルーでは、3 文のソーステキストから 6 つのルール、4 つの変数、1 つのカスタム型が抽出されました。SATISFIABLE はポリシーと矛盾しないものの証明もされない回答を示す判定であり、失敗ではないという教訓も共有されています。 ブログ記事「 AWS Continuum が自律型コードセキュリティの新たな基準を確立: CyberGym-E2E で成功率 89.0% を達成 」 AWS が、自律型セキュリティの AWS Continuum for code vulnerabilities を公開ベンチマーク CyberGym-E2E で評価しました。CyberGym-E2E は、エージェントが実際のコードベースから脆弱性を見つけ、動作する概念実証で実証し、プロジェクトのテストでカバーされた動作を損なわずに修正するまでを評価するベンチマークです。139 のオープンソースプロジェクトで過去に OSS-Fuzz が検出した脆弱性に基づく 920 件のタスクで構成されます。エンドツーエンドの成功を測る主要指標 S3（パッチ適用後も機能テストにパスする）で、Continuum は 920 件中 819 件をパスし、成功率 89.0% を達成しました。従来の公開最高値 65.9% を 23.1 ポイント上回る結果です。Continuum は発見、検証、修復の各フェーズに専用のエージェントを置くマルチエージェントシステムです。記事では、CyberGym-E2E が C および C++ のメモリ安全性の脆弱性に焦点を当てており、デプロイコンテキストを踏まえた優先順位付けは評価範囲外である点も明記しています。 ブログ記事「 AI を活用した脆弱性検出ハーネス (パート 1 構築編): 3 層パイプラインによる検出結果の絞り込み 」 脆弱性スキャナーが生成する検出結果は、手動のトリアージで処理できる速度を上回っています。その多くは悪用される可能性が低いものです。記事では、未加工の検出結果を、悪用可能性の証拠が文書化された優先順位付きの少数の検出結果に絞り込む 3 層のパイプラインを紹介しています。第 1 層では複数のスキャナーを独立して実行し、2 つ以上が同じ検出結果を示すかで妥当性を確認します。第 2 層ではコードの抽象構文木（AST）を使い、スキャナーが説明した関数やファイルが実在し、データがその経路で流れ得るかを照らし合わせます。確認できない検出結果は却下します。第 3 層では CloudFormation や Terraform などの IaC テンプレートを読み込み、AWS WAF ルールやネットワーク分離、認証要件、入力検証といった既存のコントロールを攻撃者が回避できるかを段階的な尺度で評価します。AI が生成した主張は人がレビューする前に検証が必要であることや、ハーネスはコードの修正や人によるレビューの代わりにはならないことも明確に示されています。 ブログ記事「 AI を活用した脆弱性検出ハーネス (パート 2 設定編): ステアリングファイルで実現する証拠ベースの脆弱性トリアージ 」 前編で紹介した 3 層パイプラインの中で、モデルの動作を制御するステアリングファイルを解説しています。同じフロンティアモデルでも、指示次第で捏造した攻撃チェーンや過大な重大度を出力します。モデルの能力は変わりません。設定で変えられるのはモデルの判断です。ステアリングファイルは、Kiro の .kiro/steering/ 配下の Markdown や Claude Code の CLAUDE.md のように、AI コーディングアシスタントがセッション開始時に読み込む永続的な指示です。記事では 5 つの設定セクションの設計判断を解説しています。報告前にコード構造との照らし合わせを必須にする構造的検証では、ステアリングなしのモデルの検出結果の約 30% が存在しないコード構造を参照していましたが、指示を加えた後のテストではゼロになりました。信頼度は自己申告ではなく、テイント分析によるフロー確認など 5 つの二値シグナルの重み付きの式で計算します。コントロールの乗数や脅威インテリジェンスのブーストを加えたうえで、P0 から P3 の 4 階層に分類します。既知の脆弱性 10 件を含む検証用アプリケーションでは、ステアリングありのモデルが 10 件中 9 件を検出し、緩和済みの 2 件を根拠付きで P3 に引き下げました。ステアリングファイルは GitHub で公開されています。 ブログ記事「 【開催報告】AWS Cashless Frontier ― 決済業界のフロントランナーと描くAI × デジタル通貨の未来 」 2026 年 9 月 2 日に AWS 麻布台ヒルズオフィスで開催され、決済業界の IT 推進・ビジネスリーダー約 30 社 60 名が参加しました。AWS からは国内外の最新動向に加えて、USDC を利用したエージェントコマースを支える買い手側の Amazon Bedrock AgentCore Payments と、売り手側の AWS WAF の機能を紹介しました。Customer Lightning Session には 3 社が登壇しました。三菱UFJニコス株式会社様は Amazon Connect の導入経緯と、AWS Transform、Kiro、AWS Security Agent の検証を発表しました。SP.LINKS株式会社様は CCoE 主導のクラウド標準化と、AWS DevOps Agent や Kiro の活用を共有しました。株式会社ネットプロテクションズ様は「NP後払い」のコンタクトセンターに 3 段階のガードレールとヒューマン・イン・ザ・ループを組み込み、対象カテゴリーで AI 回答率 80% 以上を達成した取り組みを紹介しました。パネルディスカッションでは、株式会社インフキュリオンの丸山 弘毅 様と GMOペイメントゲートウェイ株式会社の三谷 隆 様が、エージェンティック・コマースの現在地から 2030 年のキャッシュレスビジョンまで 4 つのテーマで議論しました。 ブログ記事「 Kiro CLI V3 をデフォルトのエクスペリエンスとして順次展開します 」 Kiro CLI V3 は、Kiro IDE や Kiro Web と同じエージェントハーネスをターミナルで使えるようにするもので、6 月からオプトインで提供されてきました。10 月 12 日から、10 月末の CLI 3.0 リリースに先立って V3 への切り替えを案内する起動時のプロンプトが順次展開されます。プロンプトを待たずに kiro-cli --v3 で試すこともできます。V3 では、クラウドセッション（現時点では米国東部（バージニア北部）のみ）、チャットセッションをまたぐメモリ、spec モード、 /tangent 、バックグラウンドで計画・実装・レビューを進める workflows（オプトイン）などが使えます。プロンプトの選択肢は「Switch to V3 and upgrade my configs」「Remind me later」「Don’t ask again」の 3 つです。ただし最後を選んでも、10 月末の CLI 3.0 リリース時点で V3 にアップグレードされます。V3 には use_aws ツールがなく、AWS CLI のコマンドはシェルツール経由で実行されます。CLI 3.0 ではシェルのインライン自動補完と CLI デスクトップアプリ、Classic エクスペリエンスが廃止されます。 サービスアップデート 音声エージェント向けに推論を改善した Amazon Nova 2.5 Sonic を発表 Amazon Nova 2.5 Sonic が一般提供開始となりました。リアルタイムの音声エージェント向けの最新の speech-to-speech モデルで、推論、指示追従、ツール呼び出しの精度が改善され、レイテンシーも低くなりました。音声エージェントがコンテキストを保持し、複数ステップの指示に従い、接続したツールで顧客のタスクを完了できます。たとえばカスタマーサービスのエージェントが、1 つの会話の中で注文を検索し、返品の可否を確認し、返品手続きを開始できます。7 言語の表現力のある音声や制御可能なターンテイキング、256K のコンテキストウィンドウといった既存の機能も引き継いでいます。あわせて一般提供となった Strands Bidi Agents と組み合わせると、本番向けの音声エージェントを数行のコードで構築できます。東京リージョンを含む米国東部（バージニア北部）、米国西部（オレゴン）、欧州（ストックホルム）、アジアパシフィック（東京）の Amazon Bedrock で、Nova 2 Sonic と同じ料金で利用できます。 AWS Continuum for Penetration Testing が CI/CD パイプラインに直接統合された継続的なペネトレーションテストに対応 AWS Continuum for Penetration Testing（旧 AWS Security Agent）が、既存の CI/CD システムに直接統合した継続的なペネトレーションテストにパブリックプレビューで対応しました。これまでも第三者のベンダーと契約せずに継続的かつオンデマンドのペネトレーションテストを提供していましたが、今回の統合でペネトレーションテストがデプロイ時のイベントになります。開発者は重大度、影響を受けるエンドポイント、修復ガイダンスを含む検出結果をパイプラインの出力で直接受け取れます。セキュリティに関係しない変更は目立った遅延なく完了し、修復後はパイプラインが手動の再トリガーなしに再テストして修正を検証します。利用開始にセキュリティの専門知識は不要で、自動生成されるパイプラインスニペットを既存のパイプラインに貼り付けるだけで 5 分以内に設定できます。アプリケーションのコンテキストは初回実行時に自動で準備されるため、事前にフルのペネトレーションテストを実施しておく必要もありません。 Z.ai の GLM 5.3 が Amazon Bedrock で一般提供開始 Z.ai の GLM 5.3 が Amazon Bedrock で一般提供開始となりました。エージェンティックコーディングや長期にわたるソフトウェアエンジニアリング作業向けの新しい選択肢です。GLM 5.3 は Z.ai のフラッグシップモデルで、総パラメータ 753B、トークンあたりの活性パラメータ約 40B の Mixture-of-Experts アーキテクチャを採用しています。GLM 5.2 と同じベースモデルの上で、ポストトレーニングの規模を広げて改善しました。100 万トークンのコンテキストウィンドウと最大 128K の出力トークンを備え、推論は常に有効です。レイテンシーとトークン消費をタスク性能と引き換えにできる effort レベルも選べます。Amazon Bedrock ではシステムプロンプトとメッセージにキャッシュポイントを置く明示的なプロンプトキャッシュに対応しており、呼び出しをまたいでコンテキストを再利用する際のレイテンシーと入力コストを抑えられます。対象となるエンタープライズのお客様が、US および Global のクロスリージョン推論プロファイル経由で利用できます。 Claude Haiku 5.5 が AWS で利用可能に Anthropic の Claude Haiku 5.5 が AWS で利用可能になりました。Claude 5.5 ファミリーで最も高速かつ効率的なモデルで、サブエージェントや大量でコストに敏感な処理向けに設計されています。Anthropic によれば、ほとんどのタスクで Claude Haiku 4.5 より約 75% 低コストです。コーディング、ツール使用、コンピュータ操作、エージェントの各面で Haiku 4.5 から大きく進化し、タスクごとにコストと知能のバランスを調整できる effort 制御を備えた初の Haiku でもあります。音声エージェントのようなリアルタイムの体験や、分類や要約などの大量処理に向いています。Claude Opus 5.5 のような高性能なモデルが作業を計画し、明確に定義されたタスクを Haiku に引き渡せば、多数のエージェントを並列に動かす構成も現実的です。利用方法は Amazon Bedrock と Claude Platform on AWS の 2 つです。Amazon Bedrock ではリージョン内のデータレジデンシーを保ちながら Guardrails や Knowledge Bases と組み合わせて使えます。Claude Platform on AWS では、Anthropic と直接取引する場合と同じ API や機能、コンソール体験を AWS の請求と認証に統合した形で利用できます。 Claude Haiku 5.5 が AWS GovCloud (US) で利用可能に Claude Haiku 5.5 が AWS GovCloud (US) でも利用可能になりました。Claude 5.5 ファミリーで最も高速かつ効率的なモデルで、Anthropic によればほとんどのタスクで Claude Haiku 4.5 より約 75% 低コストです。effort 制御を備えた初の Haiku として、音声エージェントなどのリアルタイムの体験や、分類・要約といった大量処理、サブエージェントとしての利用に向いています。AWS GovCloud (US) では Amazon Bedrock を通じて、リージョン内のデータレジデンシーを保ちながら Guardrails や Knowledge Bases と組み合わせて利用できます。 TwelveLabs Pegasus 1.5 モデルが Amazon Bedrock で利用可能に TwelveLabs の Pegasus 1.5 が Amazon Bedrock で利用可能になりました。動画から構造化されたタイムコード付きのメタデータを生成する video-to-text モデルです。これまで大規模な動画ライブラリから特定の瞬間を見つけるには、質問する前にどこを探すべきかを知っている必要がありました。Pegasus 1.5 は動画全体を読み取り、何がいつ起きたかにラベルを付けて、映像をアプリケーションから問い合わせできるデータに変えます。編集上のセグメントや話者の切り替わり、スポーツのプレー、ブランドの登場など、ビジネスにとって重要な事柄を定義しておくと、該当する瞬間をタイムスタンプ付きで返します。画面に映るもの、音声、画面上の文字を 1 回のパスで分析するため、事前のインデックス作成や取り込みパイプラインの構築は不要です。US および Global のクロスリージョン推論プロファイル経由で利用できます。 OpenAI GPT-6.1 Sol が Amazon Bedrock で Ultrafast モードに対応 OpenAI の GPT-6.1 Sol が Amazon Bedrock で Ultrafast モードに対応しました。Ultrafast モードは、速度を最も重視するワークロード向けにより高速な推論を提供します。リアルタイムのコーディングアシスタントやインタラクティブなエージェント、素早く質の高い応答が求められる顧客向けの体験など、レイテンシーに敏感なアプリケーションに向いています。GPT-6.1 Sol は機能の構築、問題のデバッグ、複雑なコードベースの調査、複数ステップのワークフローの完了を支援します。既存の AWS のコントロールでワークロードの保護、アクセスの統制、モデル呼び出しの監査ができ、Amazon Bedrock コンソールまたは対応する Amazon Bedrock API から利用を開始できます。 Amazon Quick がブランドに沿ったプレゼンテーションとドキュメントのためのブランドテンプレートに対応 Amazon Quick にブランドテンプレートをアップロードし、承認済みのビジュアルアイデンティティに沿ったプレゼンテーションやドキュメントを作成できるようになりました。ブランドマネージャーが PowerPoint や Word のテンプレートをアップロードするか、SharePoint のような接続済みのファイルストアから取り込むと、Quick が色、フォント、ロゴ、レイアウト、ブランドルールを抽出します。ブランドマネージャーはその内容を確認・編集したうえで組織全体に公開します。利用者はチャットごとに正しいファイルを探さなくても、ブランドに沿った成果物を得られます。Quick はテンプレートのルールに従ってアセットを作成し、リクエストがルールに反する場合はその理由を説明してブランドに沿った代替案を提案します。テンプレートはブランドマネージャーが書いたガイダンスに基づいてタスクごとに選ばれますが、利用者が別のテンプレートを選ぶこともできます。作成・公開できる人はカスタム権限で管理者が決められます。ブランドアセットは Amazon Quick デスクトップアプリで一般提供されています。 Amazon Bedrock が OpenAI モデルの reasoning summary に対応 Amazon Bedrock が、Responses API を通じて OpenAI モデルの reasoning.summary パラメータに対応しました。モデルの応答とあわせて、推論内容の人が読める要約をリクエストできます。コーディングや分析、複数ステップの問題解決といった複雑なタスクにモデルがどう取り組んだかが分かり、応答の評価やアプリケーションのデバッグに役立ちます。モデルの考え方をユーザーに示す用途にも使えます。要約は、reasoning 出力アイテムの summary 配列で回答と並んで返されます。リージョン内推論、地理的（GEO）クロスリージョン推論、グローバルクロスリージョン推論を含め、OpenAI の GPT モデルが利用できるすべての AWS リージョンで、Amazon Bedrock 上のすべての OpenAI モデルに対して利用できます。 Anthropic Claude Sonnet 5.5 と Claude Opus 5.5 が AWS GovCloud (US) の Kiro で利用可能に AWS GovCloud (US) リージョンの Kiro IDE と Kiro CLI で、Anthropic の Claude Opus 5.5 と Claude Sonnet 5.5 が利用可能になりました。Claude Opus 5.5 は Anthropic の Opus モデルとして最も高性能で、長時間のエージェンティックなコーディング作業で Opus 5 から進化しています。リクエストごとにタスクに必要な労力を判断して思考し、Kiro の内部ベンチマークでは Opus 5 と比べて約 40% 少ないツール呼び出しと約半分のトークンでタスクを完了します。1M のコンテキストウィンドウと 2.0x のクレジット倍率で提供され、倍率は Opus 5 の 2.2x から下がりました。Claude Sonnet 5.5 はこれまでで最も高速な Sonnet で、出力は 30% 以上速くなり、実際のコーディングやナレッジワークの性能は Opus 5.5 に近づいています。1M のコンテキストウィンドウと 1.3x のクレジット倍率で提供されます。IDE または CLI を最新バージョンに更新して再起動すると、モデルセレクターから選べます。 Kiro CLI 2.29 : チャットセッションをまたぐ Memory Kiro CLI 2.29 では、ローカルの V3 セッションで Memory が使えるようになりました。リポジトリのコマンドや規約といった作業中に得たコンテキストを Kiro が学習し、後のチャットセッションで呼び出すため、同じ説明を繰り返さずに済みます。たとえばローカルデータベースをシードしないと統合テストが失敗すると学習していれば、次のセッションでは先にシードできます。管理はローカルの V3 セッションで /memories と入力し、 config から read & write 、 read only 、 off を選びます。アクセス設定の変更は次のセッションから反映されます。 read & write のときは Automatic memory updates を有効にでき、セッション終了後も含めてメモリの作成と改良を Kiro に許可できます。信頼していないワークスペースでは読み取りのみで、追加・変更・削除はできません。 list では保存済みメモリの検索やプレビューができ、修正や削除はチャットで Kiro に依頼します。あわせて、エージェント JSON ファイルを V2 と V3 の両方が読める形式にする kiro-cli agent upgrade の追加など、改善と修正も含まれています。 Kiro IDE 1.2.56 : Workflows のフィードバック、Powers の検索、柔軟な Hook マッチング Kiro IDE 1.2.56 では、Workflows のフィードバックリンクが追加され、ワークフローの信頼性や spec 専用コマンド、Hook のマッチングが改善されました。チャット、ターミナル、ソースコントロールの多くの問題も修正されています。デスクトップアプリでは、チャットの Workflows ドロワーから短いフィードバック調査を開けます。この調査は GovCloud、AWS isolated Regions、China Regions では利用できません。Available Powers ビューでは名前でカードを絞り込めるようになり、 /quick-spec 、 /architecture-selection 、 /bug-fix は spec セッションでのみ表示されます。PreToolUse と PostToolUse の Hook では、ツール ID を個別に列挙する代わりに shell 、 read 、 write 、 @builtin 、 @mcp 、 @server 、 @server/tool というカテゴリとセレクタでツールのグループをマッチできます。修正では、複数リポジトリのワークスペースで Generate Commit Message が誤ったリポジトリを使う問題や、長いチャットでメモリ使用量が増え続ける問題などが解消されました。 Kiro CLI 2.28 : Classic から 3.0 への切り替え、カテゴリベースの Hook マッチング、より安定した V3 セッション Kiro CLI 2.28 では、Classic ユーザーがターミナルを離れずに 3.0 へ切り替えられるようになりました。3.0 を実行できるホストでインタラクティブな Classic セッションを開始すると、Kiro が切り替えを提案します。「Switch to 3.0 and upgrade my agent configs」を選ぶと、3.0 がデフォルトとして保存され、エージェント設定がアップグレードされ、コマンドが 3.0 で再実行されます。断った場合はおよそ週に一度、再度案内されます。V3 セッションでは、ツールの前後に実行する Hook を内部のツール ID だけでなく、shell、read、write や特定の MCP サーバー・ツールといったカテゴリでマッチできます。 /model と /effort は Kiro の作業中でもピッカーを開けるようになり、選択は現在のターンの終了後に適用されます。V3 は終了したターンをメモリに保持せず解放するため、長いチャットでの蓄積が抑えられます。このほか、 /settings > Display > Full Screen への Copy on select の追加など、改善と修正も含まれています。 生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「 AWS ジャパン生成 AI 実用化推進プログラム 」をご用意しています。ぜひご活用ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。

本ブログは 2026 年 10 月 6 日に公開された AWS Blog “ Responsible AI governance: How AWS positions customers to align with ISO/IEC 42005:2025 ” を翻訳したものです。 生成 AI の導入は パーソナルコンピュータやインターネットの普及を上回るペースで進んでおり 、 2025 年の世界の AI 関連投資額は 5,816 億 9,000 万ドルに達しています 。こうした状況の中、組織は AI を責任ある形で活用して業務を強化できるよう、従業員の体制を整える必要があります。AI Adoption Initiative に所属する研究者らは、 従業員は AI イノベーター、ファシリテーター、ユーザーで構成される AI Labor Stack (AI 労働スタック) を通じて AI とかかわっていると論じています。さらに、ファシリテーターは「企業、業界、公共サービス全体で、AI の能力を実際のデプロイにつなげる」役割を担っているにもかかわらず、各国の AI 戦略では「欠けている中間層」となっていることが多いと指摘しています (Ferrone et al., 2026)。 AWS は、国際規格 ISO/IEC 42005:2025 のレビューを通じて、このファシリテーター層が組織内で AI ガバナンスへの体系的なアプローチを導入または改善できるよう支援します。その一環として、AI 影響評価を組織のより広範なガバナンスのエコシステムへ効率的に統合する方法について、この規格が示すガイダンスを考察します。 規格に基づくガバナンスフレームワークは、今後に向けた実践的な道筋を示すものであり、AWS はこうしたフレームワークを実際に活用できるものにするための投資を行ってきました。Amazon は、 国際標準化機構 (ISO) による AI リスク管理の規格策定プロジェクトを支持してきました。複数の AI サービス (Amazon Bedrock、Amazon Q Business、Amazon Transcribe、Amazon Textract) で認証を取得するとともに、お客様にも自社サービスの認証にこれらの規格を活用していただくよう推奨しています。 Amazon Web Services (AWS) は、ISO/IEC 42005 やその他の責任ある AI のベストプラクティスに沿ったガバナンス業務を支援するツールを提供しています。具体的には、「 AWS における ISO/IEC 42001:2023 AI マネジメントシステム (AIMS) 実装ガイド 」や、お客様が企業のリスク管理エコシステムでこの規格を活用する際に役立つ「 Well-Architected Framework: Responsible AI Lens 」があります。本記事では、AI システム影響評価とは何か、全社的なリスク管理をどのように改善するのか、そして ISO/IEC 42005 が AI システム影響評価のベストプラクティスをどのように体系化しているのかを解説します。 AI システム影響評価 AI システム影響評価とは、AI システムを開発、提供、または使用する組織が、組織、個人、コミュニティ、グループ、社会への影響を検討するための、文書化された AI システムのリスク特定プロセスです。また、AI システム影響評価プロセスでは、プライバシーへの影響、差別的な影響、パフォーマンスへの影響の特定といった成果を、組織のリスク管理の意思決定に反映します。このプロセスを活用することで、組織は特定したリスクの管理に適したガードレールを選択し、AI のデプロイを責任を持って管理できます。 AI 影響評価による全社的なリスク管理の促進 AI システム影響評価は、組織全体のリスク管理プロセスに不可欠な要素です。ISO/IEC 42005 は、AI システム影響評価を企業内の既存の影響評価プロセスに統合する方法について、明確なガイダンスを提供しています。多くの企業では、IT システムを対象としたさまざまな種類の影響評価 (リスク、プライバシー、サイバーセキュリティなど) が既に実施されています。 十分に整備された影響評価のエコシステムを持つ組織向けに、ISO/IEC 42005 の附属書 D では、影響評価を簡素化して重複を避けるためのプロセスを示しています。これにより、AI システム影響評価で必要となる関連レビュー (リスク、法務、セキュリティ、プライバシー、調達、アーキテクチャなど) を調整しやすくなります。 AI 影響評価を単独で実施したい組織向けには、ISO/IEC 42005 の附属書 E で、独立した形での評価実施にすぐに使えるテンプレートが提供されています。 ISO/IEC 42005 による AI ガバナンスプロセスとの連携 ISO/IEC 42005 を活用することで、お客様はより統合された AI ガバナンスプロセスを実現できます。具体的には、この規格では、AI システム影響評価の内容の策定方法と実施方法、AI ライフサイクルのどの段階で評価を組み込むべきか、そして評価プロセスとその結果の文書化方法についてのガイダンスを提供しています。 反復可能で拡張性のある AI システム影響評価プロセスの構築 AI システム影響評価の実施と文書化について、構造化された一貫性のあるアプローチを確立したいお客様は、ISO/IEC 42005 のガイダンスを参考にできます。この規格は、評価のライフサイクル全体 (スコーピングと実施、分析と報告、継続的なモニタリングとレビューなど) を網羅しています。また、AI システム影響評価をいつ実施すべきか、どの程度包括的に行うべきか、再評価のトリガーをどのように設定するかについても示しています。 より広範な AI 開発ライフサイクルに合わせて評価と再評価のタイミングを設定する際、この規格では、再評価が必要になる可能性を示すトリガーを (外部要因と内部要因の両方を考慮して) 検討することを推奨しています。例えば、適用される法的要件、契約上の義務、社内ポリシー、顧客の期待、再評価が必要となる可能性のある変更 (AI システム、その運用環境、またはそのコンテキストに対する変更)、その他の要因などです。また、本格的な評価や再評価に着手する前に、より軽量な AI システム影響評価のトリアージを実施する方法も説明しています。トリアージとは、(リスクのレベルに応じて) より包括的な評価が必要かどうかを判断するための簡易的な分類です。 評価の設計: 評価で答えるべき質問 AI システム影響評価をどこから始めればよいか検討しているお客様は、ISO/IEC 42005 を参考にできます。この規格では、テンプレート化された評価アプローチを通じて、AI システム影響評価で文書化すべき具体的な情報を規定しています。また、重複を避けるために、企業が既に実施している可能性のある他のリスク評価を活用する方法も説明しています。文書には、次のような項目を含めることが推奨されます。 AI システムとその意図された用途の説明 予見可能な誤用の形態 AI システムの開発に使用されたデータ、その基盤となるコンポーネントとアルゴリズム AI システムがデプロイされる環境 AI システムの影響を受ける可能性のある個人とコミュニティ ISO/IEC 42005 は、システムがどのように使用または誤用されうるかを考慮することで、AI システムのプラスとマイナスの両方の影響を特定するための方法論を提供しています。この規格は、組織が優先事項として選択できるさまざまな AI に関する目標 (公平性、信頼性、プライバシー、セキュリティなど) を、危害と便益の両面から影響を評価する基準として用いています。そのため、組織が責任ある AI の原則を実践するうえで役立ちます。また、AI システム影響評価プロセスにおけるステークホルダーの特定と協議に関する考慮事項も示しており、多様なコミュニティから意見を募り、評価に反映することを推奨しています。 ISO/IEC 42001 認証の取得支援 ISO/IEC 42001 の認証取得を目指す組織にとって、ISO/IEC 42005 は、ISO/IEC 42001 の主要な管理策である AI 影響評価への対応方法について有益なガイダンスとなります。ISO/IEC 42005 の附属書 A では、同規格が ISO/IEC 42001 の要件への対応をどのように支援するかを具体的に説明しています。 AWS は、AI サービスについて、認定された認証機関から ISO/IEC 42001 認証を 取得しています 。対象となるサービスは Amazon Bedrock 、 Amazon Q Business 、 Amazon Textract 、 Amazon Transcribe です。AWS はこの経験に基づき、責任ある AI への取り組みにおいて AI 影響評価が組織をどのように支援できるかを含め、AWS のベストプラクティスを策定しました。 責任ある AI への取り組みを支援する AWS のツール AWS Well-Architected Responsible AI Lens は、ビルダーチームが特定のユースケースに向けた AI ソリューションを責任を持って構築、運用できるよう支援します。AWS Responsible AI Lens は、ISO/IEC 42005 と密接に整合しています。 便益と危害の特定: どちらも、期待される便益と潜在的な危害を特定するようビルダーを導きます。 リスク管理の統合: どちらも、リスクの特定と分析の結果を、リスク対応の意思決定と緩和策に反映することを重視しています。 ライフサイクルへの統合: どちらも、影響評価を 1 回限りのコンプライアンス作業ではなく、AI 開発ライフサイクルに不可欠な要素として位置付けています。 さらに AWS は、2026 年 5 月に最新のコンプライアンスガイド「 AWS における ISO/IEC 42001 の実装 」を公開しました。このガイドは、AWS のサービスを使用して AIMS を設計、運用する組織を支援します。 まとめ ISO/IEC 42001 や ISO/IEC 42005 などの国際規格は、信頼、相互運用性、説明責任を支えます。これらの要素が、多様なグローバル環境における AI のイノベーションとデプロイを推進します。AWS は、これらの規格との整合を支援するツールの構築に取り組んでいます。この取り組みは、責任ある AI の開発とデプロイに対する AWS のコミットメントについて、独立した検証による裏付けをお客様に提供します。また、AWS の AI サービスがコンプライアンスへの取り組みをどのように加速できるかをお客様に示すものでもあります。 免責事項: 本ブログで紹介するリスク評価と影響評価に関するガイダンスは、ISO/IEC 42001 に基づく AI リスク管理の実装、ISO/IEC 42005 との整合、AI リスク管理基盤の確立について、一般的な方向性と実践的な知見を提供することを目的としています。ただし、規格および規制当局が求めるとおり、各組織はそれぞれの状況に応じたリスク評価を独自に実施する責任を負います。本ブログは、いかなるリスク管理の 規格や法律についても、準拠のための網羅的なアプローチを示すもの、または準拠を保証するものとして解釈されるべきではありません。 著者について Adam Powers Adam は Amazon の Director of Privacy Science and Responsible AI です。Adam の組織は、Amazon がお客様のデータを保護するために用いる科学的手法と技術を開発しています。また、Amazon の責任ある AI を統括する部門を率い、全社における AI の標準とコンプライアンスプログラムを策定し、ツールを整備しています。Amazon では以前、Worldwide Customer Service Security と Devices & Services Privacy を率いていました。Amazon に入社する前は、メディアおよび通信業界で 20 年にわたり、スタートアップの共同創業者兼 CTO、テクノロジー部門の幹部、国際標準化団体のリーダーとして活躍しました。ブロードバンドネットワーキングやインタラクティブテレビから、言語モデルベースのリスク特定に至るまで、幅広い分野で特許を保有しています。 Peter Hallinan Peter は Amazon の Director of Responsible AI として、AWS における責任ある AI の科学と実践を推進する組織を率いています。AI (ハーバード大学で博士号を取得) と起業 (Blindsight を Amazon に売却) に関する深い専門知識を有しています。ボランティア活動として、スタンフォード大学医学部の顧問教授や、マダガスカル米国商工会議所の会頭を務めた経験があります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 5 月 6 日に公開された AWS Blog “ New compliance guide available: ISO/IEC 42001:2023 on AWS ” を翻訳したものです。 AWS は、最新のコンプライアンスガイド「 ISO/IEC 42001:2023 on AWS 」を公開しました。このガイドは、AWS サービスを使用して AI マネジメントシステム (AIMS) を設計、運用する組織に向けて、実践的なガイダンスを提供します。 組織がクラウドで AI や生成 AI のワークロードをデプロイするにあたり、 ISO/IEC 42001:2023 などの国際的に認められた規格との整合を図ることは、AI ガバナンス、リスク管理、責任ある AI の実践を強化するうえで重要なステップとなります。このガイドは、クラウドアーキテクト、AI/ML エンジニア、セキュリティチーム、コンプライアンス責任者、DevOps 実践者を対象としています。AI 向けの AWS 責任共有モデル を適用しながら、AWS サービスを使用して ISO 42001 に沿った管理策を実装、運用する方法を理解するのに役立ちます。 このガイドでは、ISO 42001:2023 の箇条 4～10 と、AI システムに固有の附属書 A の管理策で定められた要件に対応するために、組織が AWS サービスを AIMS に統合する方法を説明しています。また、お客様が AI システムの可視性を維持し、運用の一貫性を向上させ、監査ですぐに提示できるエビデンスを準備するうえで、AWS の AI サービス、セキュリティ機能、モニタリング、自動化がどのように役立つかについても紹介しています。 AWS は責任ある AI の機能を組み込んだ、安全でコンプライアンス要件を満たすクラウドインフラストラクチャを提供しています。一方で、AIMS の適用範囲の定義、管理策の実装、認証審査での適合性の実証は、引き続きお客様の責任となります。 ガイドの内容 ISO 42001 とその附属書の理解や、より広範な ISO の AI 規格ファミリーとの関係を含む、ISO/IEC 42001:2023 フレームワークの 概要 AWS のセキュリティアーキテクチャとの統合と、AI ワークロードへの AWS 責任共有モデルの適用に関する ガイダンス 環境内での AI システムの境界の定義を含む、AWS で AIMS を確立する際の 状況および適用範囲に関する考慮事項 組織の状況、リーダーシップ、計画、支援、運用、パフォーマンス評価、改善を対象とする、ISO 42001:2023 の箇条 4～10 と AWS サービスおよびアーキテクチャ機能との マッピング AI ポリシー、内部組織、AI システムのための資源、影響評価、AI システムのライフサイクル管理、データガバナンス、利害関係者への透明性、AI システムの使用、第三者および顧客との関係を含む、附属書 A の特定の管理策 (A.2～A.10) の 実装ガイダンス AWS ネイティブのツールを使用したエビデンス収集、文書化、監査への準備に関する 推奨事項 自動化と Infrastructure as Code を活用して AI コンプライアンス活動を運用に組み込むためのベストプラクティス このガイドを活用して、ISO 42001 の箇条と附属書 A の管理策を AWS 環境にマッピングし、エビデンス収集を自動化することで、認証審査の準備にかかる労力を削減しましょう。 ダウンロード: ISO/IEC 42001:2023 on AWS Compliance Guide さらにサポートが必要な場合は、 AWS Security Assurance Services までお問い合わせください。 Abdul Javid Abdul は Senior Security Assurance Consultant です。PECB ISO 42001 Lead Auditor、IAPP Certified AI Governance Professional、ISACA Advanced in AI Security Management の資格を保有しています。25 年以上にわたる豊富な経験を活かし、コンプライアンスに関して AWS のお客様を支援しています。IIT Chicago でコンピュータサイエンスの修士号を取得している他、IAPP、AWS、ISO、HITRUST、ISACA、CMMC、PMI、PCI DSS、ISC2 の認定資格を多数保有しています。 Satish Uppalapati Satish は AWS Security Assurance Services の Associate Assurance Consultant です。IT リスク、ガバナンス、規制アシュアランスの分野で 8 年以上の経験があります。AWS のお客様と協力し、クラウド環境を ISO 27001、SOC 2、FFIEC などのフレームワークに準拠させるための支援を行っています。また、ISO/IEC 42001 などの新しい規格を含め、AI システムのガバナンスの推進にも注力しています。 Amber Welch Amber は AWS Security Assurance Services の Senior Privacy Consultant として、AI とプライバシーのリスク管理およびコンプライアンスについて AWS のお客様にアドバイスを提供しています。英語専攻の修士号に加え、ISO 42001 Lead Auditor、IAPP CIPM、IAPP CIPP/E の認定資格を保有しています。AI とプライバシーに関するトピックで数多くの講演や執筆を行っており、AWS Privacy Reference Architecture の主執筆者でもあります。 Jonathan Jenkyn Jonathan (通称「JJ」) は AWS Security Assurance Services の Sr Security Assurance Solution Architect です。30 年以上の経験を持ち、堅牢なクラウドセキュリティを実現してきた実績あるセキュリティリーダーです。JJ は AWS People with Disabilities アフィニティグループのメンバーとしても積極的に活動しており、ランニング、サイクリング、家族と過ごす時間を楽しんでいます。 Muhammad Sharief Muhammad は AWS Security Assurance Services (SAS) の Security Assurance Consultant で、PECB 認定の ISO/IEC 42001 Lead Auditor です。AWS GovCloud (米国) と商用環境の両方で、エンタープライズのお客様が FedRAMP、CMMC、ISO 27001、ISO 42001、NIST 800-53 への準拠を達成し、維持できるよう支援しています。お客様、パートナー、AWS のサービスチームと緊密に連携しながら、エビデンス収集を自動化するアーキテクチャの設計、AI ガバナンスの推進、クラウドのセキュリティおよびコンプライアンス要件とビジネス目標の整合に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 5 月 12 日に公開された AWS Blog “ Enabling AI sovereignty on AWS ” を翻訳したものです。 クラウドと AI は、研究の加速や顧客体験の向上から、ビジネスプロセスの最適化や公共サービスの充実に至るまで、かつてないスピードで産業や社会を変革しています。 Amazon Web Services (AWS) は、クラウドと AI がその可能性を最大限に発揮するには、お客様がデータをコントロールでき、ワークロードをどのように、どこで実行するかを選択できる必要があると考えています。2022 年には、 AWS Digital Sovereignty Pledge によってコントロールと選択肢へのコミットメントを正式に表明しました。これにより、クラウドで利用できる最も高度な主権コントロールと機能を、すべての AWS のお客様に提供しています。AI の導入が加速する中、AWS はお客様と協力し、 主権要件を満たしながら AI イノベーションを取り入れられるよう 支援してきました。AWS は、お客様が AWS クラウドの機能、パフォーマンス、イノベーション、セキュリティ、スケールを犠牲にすることなく、AI 主権を含む主権のニーズを満たしながら、AI の変革力を引き続き活用できるよう取り組んでいます。AI 主権に対する AWS のアプローチは、こうしたニーズと、それに伴う実際の導入上の課題に対する深い理解に基づいています。 お客様、パートナー、アナリスト、規制当局との議論を通じて、デジタル主権、そして AI 主権の意味はステークホルダーによって異なることがわかりました。国や地域ごとに独自の主権要件があり、その要件も変化し続けています。また、どのワークロードやセクターが準拠すべきかについて、統一的なガイダンスはありません。このように違いがある一方で、共通するテーマも見えてきました。それは、データ主権 (データレジデンシーとオペレーターによるアクセスの制限を含む) と運用主権 (レジリエンス、存続性、独立性を含む) です。AI 主権はこれらを基盤とし、さらに AI の出力において文化的規範、価値観、現地の言語を守るといった新たな考慮事項が加わります。つまり、デジタル主権と AI 主権の要件を満たすことは、最終的にはお客様により多くのコントロールと選択肢を提供することにほかなりません。 AI スタック全体でのお客様によるコントロールと選択肢の実現 AI 主権には、AI スタック全体にわたるコントロールと選択肢が必要です。AI スタックとは、コンピューティング、ネットワーキング、データ管理、セキュリティコントロール、専門的なアプリケーションサービス、そして人材を組み合わせた包括的なクラウドインフラストラクチャを指します。お客様独自のニーズ、規制要件、イノベーションの目標に沿って、ロケーション、依存関係、サービス、パートナーなどをスタック全体で意図的に選択できることも、これに含まれます。AWS を利用することで、お客様はデータを安全かつ自らのコントロール下に置いたまま、信頼できる基盤の上で AI を開発できます。また、 専用設計の AWS シリコン や、NVIDIA、AMD、Intel のチップなど、AI に最適化された幅広いチップから自由に選択できるため、ワークロードに最適なチップを選べます。AWS は 20 年にわたって培ってきた専門知識を包括的な AI スタックに活かしており、組織はデータと運用を完全にコントロールしながら、最先端の機能を活用して地域の課題を解決できます。 AWS は、AI を個別のユースケースにとどめず、バリューチェーン全体に組み込むためのインフラストラクチャとツールをお客様に提供しています。これにより AI は、モデルのトレーニングとデプロイ、そして卓越したパフォーマンスを備えた高度な AI アプリケーションや生成 AI アプリケーションの構築を可能にする基盤的な能力となります。その結果、お客様はインフラストラクチャではなくイノベーションに集中できます。さらに、 AWS AI Factories 、 AWS Outposts 、 AWS Local Zones 、 AWS Dedicated Local Zones 、 AWS リージョン ( AWS European Sovereign Cloud を含む) など、さまざまな選択肢の中から、最も必要とされる場所でクラウドを利用できます。例えば、ミッションクリティカルな AI ワークロードの主権要件を満たすために専用のデプロイを必要とするお客様は、AWS AI Factories を利用できます。お客様専用に構築され、物理的に分離されたこのデプロイ環境は、 AWS Trainium アクセラレーター、NVIDIA GPU、専用のネットワーキング、ストレージといった最新の AI インフラストラクチャを組み合わせています。AWS AI Factories は、トレーニング、ファインチューニング、リアルタイム推論を安全に実行できるオンプレミスの AI 機能を提供し、AI 主権のニーズに対応します。 AWS の AI ポートフォリオは、 基盤モデル (FM) を提供する Amazon Bedrock から、 Amazon SageMaker AI などの機械学習サービス、 Amazon Q などのアプリケーションサービス、 Kiro などの開発者ツールまで、幅広いサービスで構成されています。これらはいずれも、お客様がデータをコントロールし、AI のデプロイ方法を選択できるように設計されています。Amazon Bedrock では、AI21 Labs、Anthropic、Amazon、Cohere、Mistral AI、OpenAI などの主要プロバイダーが提供する数百のモデルから選択できます。お客様は、特定のニーズに最適な FM を評価して選択し、デプロイ先を決められるほか、独自のデータを使用してモデルをプライベートにファインチューニングすることもできます。データは常にお客様のコントロール下にあります。特に重要な点として、お客様の Amazon Bedrock への入力や Amazon Bedrock からの出力が、 Amazon Nova やサードパーティーのモデルのトレーニングに使用されることは一切ありません。 国家 AI 戦略の支援 AI 戦略を成功させるには、地域の人材を育成し、スタートアップを支援し、業界固有のアプリケーションを開発し、官民パートナーシップを促進する包括的な環境を構築する必要があります。クラウドによって、AI は巨額の投資を必要とする一部の組織だけの技術から、あらゆるセクターや規模の組織がイノベーションに活用できる身近なツールへと変わりました。AI 主権を考える際には技術インフラストラクチャに注目が集まりがちですが、各国の FM が持つ文化的・戦略的な側面も同様に重要です。こうした FM は単なる計算ツールではありません。文化的な知識、言語のニュアンス、社会的な文脈といった要素を取り込めるため、地域との関連性は後から付け加えるものではなく、設計段階から考慮すべき事項となります。また、こうした FM は技術的な能力にとどまらない役割を果たします。地域でトレーニングされた FM は、その地域の法制度、商慣行、規制の枠組みを理解しながら、国の教育カリキュラムや文化的価値観を反映できます。現地の言語、方言、文化的文脈でトレーニングされたモデルは、言語の多様性を支え、これまで十分に扱われてこなかった言語が AI 製品やサービスに反映されるよう後押しします。 AWS は、文化的規範、価値観、現地の言語の保護や、地域や現地の言語に対応した言語モデルの能力開発など、国家にとって重要な優先事項やお客様のミッションを支援しています。 モデルをカスタマイズする 際には、 Amazon SageMaker AI を使用して、音声への対応やドメインへの特化を行ったり、モデルの精度を評価したりできます。例えば、2024 年 3 月に初のギリシャ語の大規模言語モデル (LLM) として公開された Meltemi は、Mistral-7B をベースに構築され、AWS のインフラストラクチャ上で稼働しています。さらに、285 億のギリシャ語トークンからなるデータセットで継続的な事前トレーニングを行うことで、ギリシャ語の能力を高めています。Meltemi は HuggingFace で利用できます。 SEA-LION は東南アジア向けのオープンソースの多言語 LLM ファミリーで、マネージド GPU クラスターを使用し、すべて AWS 上でトレーニングされました。開発チームは 30 億パラメータのモデルをわずか 3 か月で完成させており、これは同等のオンプレミスプロジェクトと比べて 60% 速いペースです。 データアクセスに対する検証可能なコントロール 主権は、データがどこに保存されているかだけの問題ではありません。誰が、どのような条件でデータにアクセスできるかという問題でもあります。AI の文脈では、アクセス制限の対象はインフラストラクチャにとどまらず、モデルの入力と出力、トレーニングプロセス、さらに AI が実行される運用環境にまで及びます。従来のインフラストラクチャとは異なり、AI ワークロードには新たなアクセス対象が存在します。具体的には、モデルそのもの、モデルのトレーニングに使用されるデータ、そして機密性の高い入力が流れる推論パイプラインです。そのため、IT システムにおける検証可能なガバナンスとアイデンティティの伝播の必要性がさらに高まっています。 お客様データの機密性と完全性を確保するため、最新のすべての Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、 AWS Inferentia や AWS Trainium などの AI アクセラレーターを搭載したインスタンスも含め、 AWS Nitro System の業界をリードするセキュリティ機能によって保護されています。お客様がワークロードの実行に使用する Nitro EC2 インスタンス上のお客様データに、AWS の誰であってもアクセスできる仕組みは、設計上存在しません。Amazon EC2 上に構築された AI 機能を持つサービスを含め、AWS のサービスはこれと同じ保護を継承しています。これらの保護は AWS Nitro System 上で処理される AI データに適用されるため、モデルトレーニングから推論まで、あらゆる段階でデータが保護されます。独立したサイバーセキュリティ企業である NCC Group は、 Nitro System の設計を検証 しました。AWS は、このレベルの透明性を提供することが、信頼の構築と維持に不可欠であると考えています。 AI エージェントがユーザーに代わって複数のシステムにまたがるアクションを実行することが増える中、誰が、また何がリソースにアクセスできるかを制御し、人間による適切な監督を確保することが重要になっています。 AWS Identity and Access Management (IAM) は、きめ細かなアクセス許可と包括的な監査証跡によって、認可されたユーザーとアプリケーションだけが AI リソースにアクセスできるようにします。AI エージェントや自動化されたワークロードについては、 Amazon Bedrock AgentCore Identity がアイデンティティと認証情報の管理機能を提供するため、エージェントは必要最小限のアクセス許可だけで動作します。 透明性と保証 透明性は、AWS のデジタル主権へのコミットメントの中核です。AWS は、データをどこに保存し、誰がアクセスでき、どのように使用されるかをお客様がコントロールできるよう、業界をリードする包括的な技術的対策、運用上のコントロール、契約上の保護を提供しています。また、AWS のサービスの設計と運用についてより高い保証を提供するため、お客様のコンプライアンスニーズへの対応に役立つ第三者による証明、認定、認証の取得に引き続き取り組んでいます。 AWS は、お客様への保証と透明性を引き続き強化しています。例えば、 AWS サービス条件を更新 して技術的保護に関するコミットメント (AWS Nitro System など) を反映したほか、お客様データの開示を求める第三者からの要請の取り扱いについて、契約で詳細なコミットメントを示しています。さらに、お客様が主権に関する事項について十分な情報に基づいて判断できるよう、補足的な説明やリソース ( CLOUD Act に関するブログ など) も提供しています。こうした取り組みは 責任ある AI へのコミットメントにも及んでおり、お客様が AWS のサービスを使用して、安心して AI アプリケーションを責任ある形で構築、運用できるよう支援しています。ISO/IEC 42001 は、組織が AI システムの責任ある開発と使用を推進するための要件と管理策を定めた国際的なマネジメントシステム規格です。AWS は、 主要クラウドサービスプロバイダーとして初めて、認定を受けた認証機関から AI サービスを対象とした ISO/IEC 42001 認証を取得 しました。対象には Amazon Bedrock、 Amazon Q Business 、 Amazon Textract 、 Amazon Transcribe が含まれます。2025 年 11 月には、ISO 42001:2023 の初回サーベイランス審査を 指摘事項なし で完了し、責任ある AI の実践に対する AWS の継続的なコミットメントを改めて示しました。 革新的なテクノロジーには、安全で信頼できる基盤が欠かせません。AWS は 140 を超えるセキュリティ標準とコンプライアンス認証をサポートしており、お客様やパートナーはこれらを継承することで、各地域の法律や規制への準拠に役立てることができます。AWS は 20 年にわたり、規制当局やサイバーセキュリティ当局と緊密に連携し、提供するサービスを国家の優先事項に合わせるとともに、ソリューションがイノベーションとコントロールの両方を支えられるよう取り組んできました。また、進歩を妨げることなく新たな動向に対応できるフレームワークづくりにも積極的に貢献しています。 お客様の主権目標の達成に向けた継続的なコミットメント AWS は、お客様がデータに対して持っているのと同じコントロールと選択肢を、AI システムに対しても提供することに取り組んでいます。AWS クラウドの機能、パフォーマンス、イノベーション、セキュリティ、スケールを維持しながら、お客様が AI の変革力を活用できるよう支援します。クラウドと AI の進化に合わせて、AWS は今後も、利用可能な最も高度な主権コントロールと機能を提供し続けます。 Stéphane Israël Stéphane は、AWS European Sovereign Cloud のリーダー兼 Managing Director です。AWS European Sovereign Cloud のインフラストラクチャ、テクノロジー、サービスを含む管理と運用に加え、AWS におけるより広範なデジタル主権の取り組みを担当しています。AWS に入社する前は Arianespace の CEO を務め、ジェイムズ・ウェッブ宇宙望遠鏡の打ち上げをはじめ、成功を収めた数多くの宇宙ミッションを統括しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

開催概要 2026年9月2日に、AWS麻布台ヒルズオフィスにて「 AWS Cashless Frontier 」を開催いたしました。決済業界のIT推進・ビジネスリーダー約30社60名の皆様にご参加いただき、エージェンティック・コマースやステーブルコイン、AIエージェント活用といった最新テーマについて、実践知の共有とネットワーキングが行われました。本記事では、イベントを企画した背景から各セッションの様子、パネルディスカッションの内容をお届けします。 企画の趣旨 ― AIのプロダクション利用を見据えて 決済はあらゆる経済活動の重要な基盤であり、キャッシュレス化は生活者の利便性に直結します。キャッシュレスの推進に向けては、システムのサイロ化やレガシーシステムからの脱却をカード会社、決済代行会社、フィンテック企業など決済業界全体で進める必要があります。そのような背景から、ユーザーにシームレスな体験を届けるために「 決済をなめらかにつなぎ、お客様の感動を創出する 」というビジョンをAWS Cashless teamでは掲げています。ビジョンの実現に向けて、最新情報のお届けや業界課題について踏み込んだ意見交換を行うイベントを、毎年テーマを発展させながら行っています。 この1年で決済業界を取り巻く環境は大きく変わりました。AIエージェントが商品の検索・比較から決済まで自律的に実行するエージェンティック・コマースとその基盤となるステーブルコインやトークン化預金といったプログラマブルな通貨の台頭、不正検知や顧客対応の自動化など生成AIによる業務変革、そしてAI駆動開発と言われるようなAIネイティブな開発スタイルの浸透といったトレンドが同時に立ち上がりました。こうした変化の最前線に立つ決済企業の皆様と共に、リアルな実践知を交換し業界横断でのイノベーションを加速する場として、本イベントを企画しました。 イベント概要 日時: 2026年9月2日（水）15:00–19:30 会場: AWS麻布台ヒルズオフィス 参加者: 決済関連企業 約30社60名 オープニング・AWS 決済業界クラウド活用最新動向 AWS 新相よりこの1年間の国内外の動きを紹介しました。2025年末のAWS re:InventでCoinbaseがx402プロトコルによるエージェントがステーブルコインを使い即時決済できる仕組みを実装した事例、2026年5月のFinancial Services SymposiumでVisa・Stripeが発表したTrusted Agent ProtocolやMachine Paymentなど、エージェントが安全に決済するためのインフラが急速に整備されてきた流れを振り返りました。 日本についてはJPYCがAWS上にステーブルコイン発行基盤を構築した事例や、シンプレクスのオンチェーン関連の取り組み、DCPのトークン化預金と国際決済の事例を紹介しました。AIエージェントによる決済は目新しいものに捉えられがちですが、本セッションで実用化が進んでいることをお届けしました。 AWS 金融・決済関連 最新サービスのご紹介 技術セッションでは、AWS松原よりエージェンティック・コマースの定義と影響を体系的に発表しました。入力支援から完全自律型購買までエージェントのレベル分けと決済プロトコルの全体像を解説しました。 その上でAWSのサービスとして、USDCを利用したエージェントコマースの実現を支援する、買い手側のエージェント決済実装のための Amazon Bedrock AgentCore Payments と、売り手側リソースに支払いリクエストを追加する AWS Web Application Firewall (WAF) の機能を紹介しました。 決済プロトコルについては「エージェンティック・コマースのプロトコルが次々登場しているが、1つが全てを代替するものではなく相互に協調している」と述べ、AWSも決済プロトコルの領域において、x402 Foundation や UCP Tech Councilにメンバーとして参加し貢献していることを紹介しました。 Customer Lightning Session ― Frontier Builders、3社が語るAI実践知 三菱UFJニコス株式会社 ― クラウド活用のベストプラクティスと次の一手 三菱UFJニコス株式会社 システム基盤・運用部 共通システム基盤グループ 次長 中村 貴治 様には、DCカードとMUFGカードのシステム統合という大規模プロジェクトを乗り越えてきた経験と、次のステップとしてのAI活用について発表いただきました。 同社は2019年にAWSの利用を開始し、コロナ禍ではAmazon WorkSpacesを数ヶ月でリリースしました。2025年にはシステム統合プロジェクトで設置したお客様窓口でAmazon Connectを採用。ランニングコストの削減とともに、状況に応じたコールフローの迅速な変更を実現しました。導入にあたり社内に対してAWS担当者とともに説明を行い、約3ヶ月で導入を実現したエピソードは、多くの参加者の関心を集めていました。 今後に向けては、基幹システムのモダナイゼーションやAI活用を推進しています。AWS Transformを活用したリライト分析や、Kiroを活用したAI駆動開発の検証に取り組んでいます。また、AWS Security Agentを活用したソースコードレビューやペネトレーションテストの検証を進めており、新たな観点での評価できる可能性を確認しています。同サービスを検討・検証されている多くのご参加者からご関心が寄せられました。 SP.LINKS株式会社 ― CCoE主導のクラウド標準化とDevOps高度化の実践 SP.LINKS株式会社 IT Infrastructure Unit / Cloud Management1 Group 小柴 敦 様からは、ベンダー依存からの脱却と内製化推進のリアルな歩みを共有いただきました。 同社は決済代行事業を展開しており、2022年に決済サービスをオンプレミスからクラウドへ移行。CCoEを作り内製開発を推進してきました。参加者の多くがチャレンジしている、ベンダー委託の課題から脱却するために、クラウドネイティブな開発体制を構築した経緯を率直にお話しいただきました。 PCI DSS対象も含むシステムを内製で運用していくには統制が必要でしたが、サービス拡大の需要とのバランスが課題でした。そこで、AWS Professional Serviceサービスを活用して内製開発を安全に拡大するためのガイドラインや環境を整備しました。現在はAWS DevOps Agentを活用した問題調査の効率化、Kiroを用いたAI駆動開発の試行にも取り組んでいます。「標準化した知見をAIで活用し、DevOpsを高度化する」と紹介されたステップアップの道すじは、多くの企業が直面している「組織でAIをどう活用するか」のという課題へ示唆となる内容でした。 株式会社ネットプロテクションズ ― 顧客の「不安」を即時解決するAIサポート 株式会社ネットプロテクションズ AI Enablementグループ Enablement担当 田中 哉太 様には、後払い決済サービス「NP後払い」のコンタクトセンター業務にAIを活用した取り組みを発表いただきました。 支払い・請求に関する問い合わせに対して、FAQだけでは個人に合わせた回答ができず、データベースを参照した正確な回答が不可欠でした。しかしAIに直接SQLを生成させるとリスクが高いため、AWS Step Functionsで順序性を固定したフローを構築し、3段階のガードレール(①本人確認 ②DB参照成否チェック ③AIの自律判断)を配置しました。さらにヒューマン・イン・ザ・ループとして、DB参照を含む回答は必ず人間が確認してから送信する設計としました。 2026年8月のリリース後、対象カテゴリーにおいてAI回答率80%以上、うち60%はデータベース参照に成功という成果を達成。担当オペレーターからも他のカテゴリーに展開しても問題ないレベルという評価を得ています。一方で「フローの複雑化により、作成者本人でも全体像を追えなくなる」という率直な課題共有もありました。ハルシネーションという言葉が浸透してきていますが、実体験での取り組みや効果は参加者が直面する課題へのアクションにつながる内容でした。 Customer Panel Session ― Envisioning the Frontier、業界リーダーが描く決済の再定義 パネルディスカッションでは、株式会社インフキュリオン 代表取締役社長 CEO 丸山 弘毅 様、GMOペイメントゲートウェイ株式会社 専務執行役員 CTO 三谷 隆 様をパネリストに迎え、モデレーター：飯田 哲夫 様（株式会社ACSiON 社外取締役 兼 株式会社カンム 社外取締役）の進行により、4つのテーマで議論が交わされました。 テーマ1: エージェンティック・コマースの現在地 三谷様からは「エージェンティック・コマースでの取引は、B2B決済を中心にすでに広がってきている」というご体感、丸山様からは、自社で発表したエージェンティック・コマースのホワイトペーパーの反響と、すでにその内容を一般常識にしないといけない温度感になっていると双方より実体験をもとにした市場の勢いを共有されました。 テーマ2: 不正検知・セキュリティの新課題 三谷様は「AIエージェントはBOTに近い。これまではBOTをブロックする方向だったが、正しいBOTを判別する方向にルールチェンジが起きている」と見解を示されました。そして、正規のエージェントと悪意のあるBOTの判別が紙一重になっており、パケットレベルの監視が必要になるほど高度化していると述べました。 丸山様は「エージェントが本人のものかどうかの真正性、さらにマンデート（委任範囲）に沿っているかどうかの確認が最大の課題。」とコメント。チャージバックのルールやリスク負担ルールがまだ定まっていない現状の業界課題もあげられました。 テーマ3: 次世代決済プラットフォームに向けて（レジリエンス・AI駆動開発） 三谷様からは「入られる前提で考える」というサイバーセキュリティの方針転換について実践例が語られました。年に1回、経営陣向けのランサムウェア攻撃シミュレーションを実施しており、PCI DSSの再認証含めて考慮する必要があるという学びを共有されました。 丸山様からはAI駆動開発について、コーディング自体の効率化は進んでいるが、レビューは依然として人間が必要。求められる人材の質が変化してきているという見解を自社の経験から示されました。 テーマ4: 2030年のキャッシュレスビジョンとAWSへの要望 三谷様は「決済は気づかないうちに済ませておいてという世界。テクノロジーの観点では壁をなくして全日本で強くなりたい」と業界協力のビジョンを語りました。丸山様も同様に「テクノロジー面では業界全体で協力し、ビジネス面では競い合う。企業同士が協力して、表のコンシューマーには決済が見えなくても自由に取引ができる世界を作りたい」と呼応されました。 AWSへの要望としては、「グローバルで乱立するプロトコルを吸収できるレイヤーの役割」「政府に向けたクラウドの安全性の説明」「本イベントのような、企業の壁を越えた本音ベースのトークの場を続けてほしい」という率直な声をいただきました。ご登壇者の対話に加え、参加者からも質問が続き会場全体の熱意が感じられるセッションとなりました。 まとめ 本イベントではビジネス・IT両面のAIエージェントの活用について、一番大事なユースケースをお客様と深掘りました。懇親会でも社内や顧客向けに何が良くなるのかといった意見交換が活発にされ、ご参加者皆様の熱意を感じました。 AWSでは、差別化を生まない重労働をAWSに預けていただけるサービスを提供しています。AIエージェントをお客様が構築するにあたり、Amazon Bedrock AgentCore、さらには Amazon Bedrock AgentCore Payments や AWS WAF などのマネージドサービスを提供し、お客様の新たなビジネス創出を支援してまいります。 また、開発・運用に関しては、Kiro、AWS DevOps Agent、AWS Security Agentなどすぐにお使いいただけるフロンティアエージェントや、金融リファレンスアーキテクチャ日本版 をはじめとする実践的なコンテンツを提供し、各社のナレッジの体系化と金融システムにおけるミッションクリティカル領域の強化を支援いたします。 本イベントにご参加いただいた皆様、ご登壇いただいた皆様に改めて御礼申し上げます。今後もAWS Cashless Initiativeでは業種・業態の垣根を越えた対話と共創を通じて、新しい決済の未来を皆様と共に切り拓いてまいります。 関連ブログ 【開催報告】AWS Future of Money ～AI × ブロックチェーンが創る新金融エコシステム～ 金融リファレンスアーキテクチャ日本版 v2 リリース

Kiro CLI V3 は、Kiro IDE と Kiro Web を動かしているものと同じ エージェントハーネス をターミナルで使えるようにします。V3 では、計画・実装・レビューが必要なタスクを Kiro に渡し、 workflow のエージェントがバックグラウンドで各ステップを進めている間も、ご自身は作業を続けられます。 クラウドセッション を開始すれば、ノート PC を閉じても作業は止まりません。新しい spec モード では、Kiro がコードを書き始める前に要件と設計を Kiro と一緒にレビューできます。新しい tangent モード を使うと、メインセッションのコンテキストに影響を与えずに、並行する会話へ分岐できます。 V3 は 6 月にオプトインのエクスペリエンスとして提供を開始し、その後も新しい機能を追加してきました。オプトインしたお客様に新機能をご活用いただいており、今回 V3 をすべてのユーザーのデフォルトにする準備を進めています。10 月 12 日から、10 月末の CLI 3.0 リリースに先立って V3 への切り替えを案内する起動時のプロンプトを順次展開します。プロンプトがすぐに表示されない場合もありますが、 kiro-cli --v3 でいつでも V3 を試せます。今回の展開の対象は Kiro CLI のみです。 ほとんどのユーザーは、切り替えにあたって設定を変更する必要はありません。エージェント、権限、連携をカスタマイズしている場合は、Kiro が自動で移行する内容と確認が必要な内容を以降のセクションで説明します。CLI 3.0 では、シェルのインライン自動補完と CLI デスクトップアプリを廃止します。また Classic エクスペリエンスも廃止し、新しい機能はターミナル UI に集中して開発していきます。 V3 でできること V3 には引き続き新機能を追加しています。最近のリリースから主なものを紹介します。 ノート PC を「起こしたまま」にする工夫をしなくても、 ノート PC を閉じた後も作業を続けられる ようになりました。 kiro-cli --cloud でクラウドセッションを開始してリポジトリを紐付ければ、Kiro がマネージドなクラウドサンドボックスで作業します。接続を切ってもエージェントは作業を続け、別のマシンからセッションを再開できます。組織で IAM Identity Center を使っている場合は、先に管理者がクラウドセッションを有効にする必要があります。なお、クラウドセッションは現時点では米国東部 (バージニア北部) us-east-1 でのみ動作します。 新しい メモリ管理 により、 Kiro がチャットセッションをまたいでコンテキストを学習 できるようになりました。Kiro はローカルの V3 セッションでの作業から、リポジトリのコマンドや規約などの有用なコンテキストを学習し、後のセッションで呼び出します。同じことを何度も説明する必要はありません。Kiro が覚えている内容は /memories で管理できます。 IDE の spec モードが CLI でも使える ようになりました。実装の前にアプローチをレビューできます。Kiro がコードを書き始める前に、要件と設計を Kiro と一緒に詰められます。ドキュメントにインラインコメントを付けたり、実行するタスクを選んだりする操作も、すべてターミナルから行えます。 /spec new から始めてください。 CLI V1 で実験的機能として最初に導入した /tangent を改良して復活 させました。メインセッションのコンテキストに影響を与えずに、脇道のスレッドを探索できます。tangent は特に要望の多かった機能のひとつで、V3 で再び提供できることを嬉しく思います。 セッションの数が増えるにつれて、目的のセッションを見つけるのは干し草の山から針を探すように難しくなっていました。そこで 新しい /sessions ペイン を追加しました。セッションの一覧表示、ブックマーク、名前の変更などができ、セッション管理が簡単になります。 複雑な複数ステップの作業を、ローカルでもクラウドでも workflows に任せられます 。Kiro にタスクを渡すと、workflows がエージェントを協調させて計画・実装・レビューを進めます。各ステップは新しいコンテキストを持つ独立したセッションで実行されるため、レビュアーがコーディングエージェントの推論を引き継ぐことはありません。workflow をバックグラウンドで実行している間もメインのチャットで作業を続けられ、必要に応じて軌道修正や一時停止ができます。workflows はオプトインの機能なので、初回の実行前に設定で有効にしてください。 セットアップの再利用 もしやすくなりました。グローバルな フック を使うと、同じ自動化を複数のワークスペースで使えます。さらに、 AGENTS.md ファイルをリポジトリのルートだけでなくサブディレクトリにも置けるようになり、プロジェクトの部分ごとに Kiro への指示を分けられます。たとえば、あるディレクトリにはフロントエンドの規約を、別のディレクトリにはバックエンドのテスト手順を置けます。 Kiro 全体でひとつのハーネス Kiro CLI V3 は、Kiro IDE と Kiro Web を動かしているものと同じ エージェントハーネス をターミナルで使えるようにします。ハーネスがツール、コンテキスト、権限、モデルとのやり取りを受け持ち、各クライアントはそれぞれのインターフェースを持ちます。 ユーザーにとっては、ハーネスに組み込んだ機能を後から移植するのではなく、他のクライアントと同時にターミナルにも届けられるということです。最近の workflows のリリースがその一例で、すべてのクライアントで同時に公開しました。共通のハーネスによって、クライアント間で設定と権限のモデルも共通になるため、リポジトリの .kiro/ 設定を複数のクライアントで使い回せます。各クライアントがサポートする内容にはまだ違いがあり、CLI の現在のサポート状況は V3 のドキュメント に記載しています。 ひとつのエージェントハーネスを作った理由 もあわせてご覧ください。 早期アクセスから学んだこと V3 は 6 月からオプトインで提供してきました。早期アクセスでいただいたフィードバックから、エージェントハーネスを切り替えるたびにセットアップを作り直すべきではないという考えが強まりました。エージェント、権限、慣れたワークフローはそのまま持ち越せる必要があります。この考えが移行体験の設計につながりました。 私たちは、既存の V2 の設定を保持したまま V3 に必要な設定を追加する「ユニバーサル設定」形式を定めました。移行ツールはカスタムエージェントをこの形式に更新し、元の設定をバックアップし、サポートされている設定を自動で変換したうえで、確認が必要な項目を知らせます。 切り替えの流れ V3 の展開期間中、Kiro CLI は起動時に切り替えを案内するプロンプトを表示します。選択肢は 3 つです。 Switch to V3 and upgrade my configs: V3 をデフォルトのハーネスとして保存し、エージェントの自動アップグレードを有効にして、ワークスペースとグローバルのカスタムエージェント設定の移行を開始します。 Remind me later: 切り替えを先送りし、後でまたプロンプトを表示します。 Don’t ask again: プロンプトの表示を止めます。これで V2 に留まれる わけではなく 、10 月末に CLI 3.0 がリリースされた時点でセットアップは V3 にアップグレードされます。 今すぐ切り替えたい場合は、プロンプトを待つ必要はありません。 kiro-cli --v3 を実行すると、新しいセッションで V3 を試せます。V3 をデフォルトとして保存するには、次のコマンドを実行します。 kiro-cli settings chat.agentEngine v3 すでに V3 をお使いの場合は、10 月末の CLI 3.0 の展開で V3 がデフォルトになった後は --v3 フラグを付ける必要がなくなります。 V2 に戻す必要がある場合は kiro-cli --v2 を実行します。このフラグはその起動時にのみ適用されます。V2 のセッションは V3 で再開できますが、V3 で作成したセッションを V2 で再開することはできません。 切り替える前に ほとんどのユーザーは、切り替えにあたって設定を変更する必要はありません。セットアップをカスタマイズしている場合に向けて、自動で引き継がれる内容と確認が必要な内容を説明します。以降のセクションでは、自動補完と Classic の廃止、ACP 連携の変更点についても取り上げます。 カスタムエージェント 移行プロンプトを承認すると、Kiro は元の設定をそれぞれ <name>.json.bak としてバックアップし、既存の V2 の設定を保持したまま V3 に必要な設定を追加します。プロンプト、モデルの選択、リソース、MCP サーバーの定義はそのまま引き継がれます。 移行ではサポートされているフックも変換します。変換できないフックは V3 の設定から除外され、警告として報告されます。警告を確認し、該当するフックを手動で更新してください。元の設定はバックアップに残っています。移行を自分で実行したりやり直したりするには、 /upgrade-agent を使います。 チームでエージェントを中央のリポジトリで管理している場合は、 v2.29 以降で kiro-cli agent upgrade <dir> を使って ディレクトリ全体を一度にアップグレード できます。まず --dry-run を付けて実行し、変更内容と警告を事前に確認してください。書き換えるのは V2 形式のままのエージェントだけで、すでに V3 のセクションを持つエージェントは変更しません。 カスタム権限 V2 では信頼済みツールのリストとツールごとの設定を使っていました。V3 では、シェルコマンドやファイルパスといったアクションとリソースに対するルールを使います。ルールが重なった場合は、スコープに関係なく deny が ask より、ask が allow より優先されます。 移行ではサポートされている設定を変換しますが、確認や手動での置き換えが必要なパターンもあります。移行後は /upgrade-agent diagnostics を実行し、移行したルールに頼る前に変換時の警告に対処してください。 --trust-all-tools は V3 でも引き続きサポートされます。個々の設定が新しいモデルにどう対応するかは、 権限の移行ガイド で説明しています。 use_aws を使っているエージェント V3 には use_aws ツールがありません。AWS CLI のコマンドはシェルツールを通じて実行され、シェルの承認ルールに従います。 use_aws の allow と deny の設定は、シェルの権限ルールとして作り直してください。継続的に承認したいコマンドは、プロンプトが表示されたときに「Always allow」を選ぶこともできます。 aws * のような広いパターンを許可せず、ルールは具体的に保ってください。移行の手順は権限のガイドを参照してください。 自動補完 シェルのインライン自動補完と CLI デスクトップアプリ は廃止され、CLI 3.0 の展開以降は利用できなくなります。 Classic Classic は V3 ではサポートされず、段階的に廃止します。新しい機能は ターミナル UI で開発しています。 TUI に切り替えるには、エイリアスやショートカットから --classic を外して kiro-cli を起動してください。 ACP クライアント エージェント設定の移行では、ACP 連携は更新されません。クライアント側の変更については ACP の移行ガイド に従い、V3 の ACP サーバーは kiro-cli acp --agent-engine=v3 で起動してください。 通常の CLI をターミナルで使っているユーザーは、この手順を省略できます。 今すぐ V3 を試す V3 への切り替えを案内する起動時のプロンプトを順次展開していきます。10 月末の CLI 3.0 リリースまでに切り替えを承認して新機能を試し、セットアップで確認が必要な点に対処しておくことをお勧めします。 次のタスクはぜひ V3 で実行してみてください。タスクを workflow に任せる、spec をレビューする、席を外している間もクラウドセッションに作業を続けさせる、といった使い方ができます。セットアップ方法と現在のサポート状況は V3 のドキュメント にまとめています。うまくいったことや困ったことは、 /feedback または Discord でお知らせください。展開の進み具合は CLI の changelog でご確認いただけます。 本記事は 2026 年 10 月 9 日に公開された Pooja Giri、Jay Raval による Kiro CLI V3 is rolling out as the default experience を翻訳したものです。

「自治体のためのクラウドコスト最適化」シリーズについて 自治体がガバメントクラウド上で業務システムを運用する場合、クラウド利用料の管理はオンプレミスとは性質の異なる実務になります。従来は、機器を調達した時点で費用がほぼ固定され、その後の管理は保守契約の範囲で済みました。クラウドは使った分だけ課金されるため、構成を変えれば費用も変わります。移行しただけでは費用は下がらず、稼働後に構成を見直し続けることで効果が出ます。 ところがこの見直し作業は、技術的な判断を伴うため日々の運用を担う事業者に委ねられがちです。結果として、自治体側に判断の材料が届かないまま請求額だけが確定していくことがあります。クラウド利用料は自治体の予算から支出され、住民や議会に説明する主体は自治体です。本シリーズは、 自治体が自らクラウド費用を把握し、事業者と協働して最適化を続けられる状態 を目標にしています。 ただしコスト最適化は、コンソールで数値を確認する日々の運用から、調達仕様書への反映、予算要求・決算の手続き、システム基盤そのものの設計まで、性質の異なる複数の作業で成り立っています。これらは担い手も検討のタイミングも異なるため、本シリーズでは領域ごとに記事を分けています。 # タイトル 扱う領域 自治体職員 ベンダー 情報政策 担当 財政担当 運用管理 補助者 ASP ① 定期レビューで回すコスト最適化の手順 日々の運用 ● ○ ● ○ ②-1 運用管理補助者との協働体制を調達仕様書に落とし込む 調達・契約 ● ○ ○ ○ ②-2 AI Agent でコスト分析を自動化する（公開予定） 運用の効率化 ● ○ ○ ③ 予算要求・執行・決算の実務（本記事） 予算・会計 ○ ● ④ 20業務の最適化設計と実践（公開予定） 基盤の設計 ○ ● ● 補足： ②-2、④は今後公開予定です。公開時にはこの表からリンクします。 ● は主な対象、 ○ は関連する範囲で参考になる読者です。 情報政策担当 ：情報システム部門でクラウド環境の運用を所管する職員 財政担当 ：予算要求・執行・決算の手続きを担当する職員 運用管理補助者 ：ガバメントクラウドの運用管理を自治体から受託する事業者 ASP ：業務システム（パッケージ）を提供し、その動作保証を担う事業者 どこから読むか ：情報政策を担当される方は①から、財政を担当される方は③から始めてください。運用管理補助者・ASP の方は④が中心になります。 本記事について シリーズ②-1では、GCASガイド「継続的運用経費最適化(FinOps)ガイド」において、クラウドサービスの利用実績の可視化、削減提案、翌事業年度の改善提案・目標設定等に取り組むこととされていることを紹介しました。これらを実現するためには、運用管理補助者・ASP、政策担当原課、情報システム部門、財政部門が各々の立場で役割を果たすことが必要になります。 そこで今回は、クラウドコストの予算管理等をテーマとし、特に、財政部門の皆さまがクラウド経費の予算査定・執行管理を行う際の実務的な視点で記載しています。 目次 1. はじめに ― 従量課金等のクラウドサービスの特徴に伴う運用の違い 1.1 クラウドサービス利用料の特徴 1.2 クラウドの特性を踏まえた新たな予算管理の考え方 1.3 コスト最適化への取組 2. 年度予算要求時のコスト見積もり 2.1 移行初年度の見積もり 2.2 2年目以降の見積もり 3. 年度途中のコスト変動への対応 3.1 AWS Budgets による予算設定・予算超過の防止 3.2 執行残発生時の扱い 4. まとめ Appendix 長期利用割引（リザーブドインスタンス・Savings Plans）の予算上の扱い 1. はじめに ― 従量課金等のクラウドサービスの特徴に伴う運用の違い 1.1 クラウドサービス利用料の特徴 自治体の予算制度は単年度が原則です。従来のオンプレミス方式（庁舎内又はデータセンターにサーバーを設置する方式）では、5年リースの契約時に年間費用が確定し、リース料を長期継続契約や債務負担行為により複数年にわたる経費の平準化と予算の見通しを確保してきました。 一方、クラウドサービスは初期投資不要/従量課金で利用できる特性を有するため、システム利用状況に合わせて無駄なく利用できる一方、予算の編成や執行等において、従来のオンプレミスとは異なる運用が必要になります。例えば、AWSのクラウドサービスの利用料には、次のような特徴があります。 従量課金 ：使った分だけ請求される仕組みであり、月ごとに金額が変動します。繁忙期（確定申告時期等）にはリソースを拡張し、閑散期には縮小することで無駄を抑制できます。 USD（米ドル）建て ：ガバメントクラウド（AWS）の利用料は米ドルで計算されるため、為替レートの変動が円換算後の支出に影響します。なお、為替を固定する契約方式も選択肢として存在します。 運用中のリソース最適化・コスト最適化が可能 ：オンプレミスでは契約更新時にしかコスト見直しができませんが、クラウドでは稼働中に随時リソースの追加・削減が可能です。 つまり、クラウドの予算管理では「予算要求時の見積もり精度」と「年度途中の予実管理」の双方が重要になります。 1.2 クラウドの特性を踏まえた新たな予算管理の考え方 また、オンプレミスの情報システムの構成をそのままクラウドに移行する「単純リフト」では、クラウドの特性を活かしきることができず、サーバーの規模が過大なまま稼働するなどにより、利用料がオンプレミス時代を上回るおそれがあります。デジタル庁による先行・検証事業等においても、単純移行ではコスト増となる事例が報告されています。 こうしたなか、財政部門としては、予算査定の際に「コスト最適化計画」の実行状況を確認することが有効となります。クラウドの費用対効果を発揮するには、移行後にコスト適正化（不要リソースの削減、サーバー規模の見直し等）を継続的に実施することが重要になります。デジタル庁が整備しガバメントクラウドに関する情報を提供しているGCASガイドにおいても、本番稼働後に継続的なコスト最適化へ取り組むことの重要性が示されています。 1.3 コスト最適化への取組 クラウドは本番稼働後がコスト最適化のスタート地点です。財政課としては、最適化の取組が継続的に行われているかを経年の予算査定や四半期報告の中で確認することが考えられます。従来、運用経費としてまとめられている経費の詳細な内訳、費目、区分が判然とせず、算出することも困難な状況にありました。しかし、クラウドサービスの特徴と、AWS Cost Explorer、AWS Budgets 等の管理ツールにより、リアルタイムで状況を可視化できます。毎月の従量課金の請求を踏まえることで、どのサービスを、どのように活用しているのか、関連する運用の人件費との切れ目はどうなっているのか、工数・人月・単価は適切かどうか、人件費のほかシステムやサービス利用料以外が過大になっていないかなどを精査できるようになります。 例えば、クラウド利用料だけを見ると「新規コストが発生した」ように見える場合であっても、オンプレミス時代には「見えにくい形」で発生していた「隠れたコスト」を含めた総保有コスト（TCO）で比較すると、クラウド移行によりシステム全体のコストが削減されているケースもあります。 （隠れたコストの例） データセンターの電気代・空調費（施設管理費の中に含まれていたもの） 職員がサーバー管理に費やしていた工数（人件費の中に含まれていたもの） 5年ごとのハードウェア更新費用（更新年度に一括計上されていたもの） 災害対策用のバックアップ設備投資 このように、コスト最適化の取組によりクラウドサービスに適した運用管理を実施していくためには、事業者（ASP/運用管理補助者）も含め、各部門が連携するスキームを確立して運用することが重要です。また、各部門の役割分担と報告ルート（情報システム部門→原課→財政課）を予め明確にしておくことで、PDCAサイクルに基づく継続的なコスト適正化が実現します。 また、例えば、情報システム専任部署を持たない小規模団体においては、ASP事業者からの月次コストレポートを受領することを基本とし、四半期ごとに財政担当が確認するという簡易な運用から始めることも方法のひとつです。この場合、ASP契約仕様書において、コストレポート（利用量・費用明細）の月次提出義務を含めておくことが考えられます。 なお、このコスト最適化には、予算を縮減することばかりが含まれるのではなく、より適切なサービスを利用するため、あるいは、より適した人材をアサインするために予算の枠内で割り当てを再分配したり、必要な経費等を増加させることも含まれる点にご留意ください。 （参考） 利用方式や環境によっては、AWS マネジメントコンソール（AWS Cost Explorer、AWS Budgets 等を含む）の閲覧権限が自治体職員に付与される場合があり、従来はASP（事業者）経由でしか確認できなかったコスト情報を、自治体職員が自ら確認できる事例も出ています。閲覧権限の付与を運用管理補助者に求める際の調達仕様書の記載例は、シリーズ②-1 の 3.1 で紹介しています。 以降、自治体の予算サイクル（予算要求→執行→決算）に沿って、クラウドコストの管理方法を具体的に解説します。 図: クラウドコストと自治体の予算サイクル（括弧内は本記事の対応章） 2. 年度予算要求時のコスト見積もり 原課又は情報システム担当から提出されるクラウド利用料の予算要求書を査定する際に、財政課が確認するとよいポイントを解説します。なお、ガバメントクラウドの利用形態は「共同利用方式」と「単独利用方式」に大別され、それぞれ見積もり精査のポイントが異なります。本記事では主に共同利用方式を念頭に記載しますが、単独利用方式の場合は、AWS アカウント内のリソースがすべて自団体の費用等となるため按分が不要となり、見積もりにおいて、共同利用方式と比較して考慮事項等が少ない特徴があります。 2.1 移行初年度の見積もり ガバメントクラウドへの移行初年度は、過去の実績データがないため、見積もりの難度が最も高い年度です。主に、 AWS Pricing Calculator を用いて概算を行います。現行システムの構成（サーバー台数、CPU/メモリ/ディスク等）を整理し、対応するAWSサービスにマッピングして試算します。また、デジタル庁がGCAS上で提供する利用料比較の仕組み（提供状況・利用方法はデジタル庁の案内をご確認ください）を活用し、人口規模や業務内容が類似する他団体の利用実績を参考値（メルクマール）とすることで、見積もりの妥当性を検証することも重要です。財政部門が予算査定を行う際は、これらの比較データの提示を求めることが有効です。 また、クラウドへの移行完了までの既存システム運用費が見落とされてしまうと、システム停止を余儀なくされてしまう可能性があります。このような移行過渡期に係る費用についても適切に計上されていることを確認してください。なお、クラウド移行に当たっては、テスト環境の稼働、一時的なスケールアップ、想定外のデータ転送等のコストの考慮も必要になります。提供する行政サービス等の停止等を防ぐためにも、初めてのシステムの移行は抜け漏れなく慎重に、かつ従量課金を加味してバッファを持つことが考えられます。そのため、類似する、あるいは先行する同規模の事例を参照した上で、初年度は特に余裕を持った予算を確保することを推奨します。 確認項目 主なチェックポイント 見積もり根拠 AWS Pricing Calculator 等のツールを使った試算結果が添付されているか スペック インスタンスサイズ（サーバー規模）が現行システムの実使用量に対し適正か。類似規模の他団体における実績値と大きく乖離していないか クラウド利用料・移行スケジュール ・何月からクラウド利用料が発生するか（月数 × 月額で積算されているか） ・テスト環境稼働から移行完了後年度末までの月数分が適切に計上されているか 移行作業費 データ移行、環境構築、テスト等に要する作業費用が適切に計上されているか 環境稼働 ・テスト環境の稼働時間が限定されているか（24時間稼働は不要） ・共同利用方式の場合、運用管理部分（監視・バックアップ等）及びネットワーク部分の費用が適切に按分されているか ・開発環境・テスト環境が移行計画に沿ったタイミングで縮退・終了される計画となっているか（稼働後も残存していないか） 並行稼働費 移行完了までの既存システム運用費が適切に計上されているか 為替考慮 為替変動と為替固定の双方の契約方式における費用や差異を比較しているか 査定のコツ : 初年度は「不確実性が高い」ことを前提に、予算を認める代わりに「四半期ごとの実績報告」を条件として付すことで、執行段階での管理を担保できます。 2.2 2年目以降の見積もり 2年目以降は、前年度の実績データが最も信頼できる見積もり根拠になります。 見積もり手順： 前年度の月別利用実績（USD）をAWSの請求データから取得します。 季節変動（確定申告時期の負荷増、年度末処理等）による増減を考慮します。 新規サービスの追加・既存サービスの廃止の影響を加味します。 前年度に実施したコスト最適化施策の通年効果（年度途中の実施分を12か月に拡張）を反映します。 為替レートを設定してJPYに換算します。 予見し難い環境変化への対応に要する経費として予備的な経費を上乗せします。なお、予算査定においては、予備的な経費分の予算については執行保留分とする運用も考えられます。いずれにせよ、予備的な経費の設定にあたっては根拠の明示が重要です。 （参考）計算例：前年度の月平均利用額が$4,200の場合、通年換算で$50,400。変動要因（+$5,100）と最適化効果（▲$4,800）を加味すると$50,700。レート160円/USDで換算すると約811万円。予備的な経費として仮に12%（97万円）を加えると、予算要求額は908万円となります（12%は計算のための仮の値です）。 長期利用割引（リザーブドインスタンス・Savings Plans）を適用している場合、または適用を予定している場合の予算上の扱いは、Appendix で補足しています。 確認項目 主なチェックポイント 前年度実績 月別実績データ（USD）が添付されているか。根拠のない増額要求になっていないか 変動要因 増額の場合：具体的な理由（利用者増、新機能追加等）が示されているか 最適化効果の反映 前年度の削減施策の効果が次年度見積もりに反映されているか（反映されていなければ過大） リスク予見・予備的な経費 過去1年間の実際の変動幅に対して上乗せ幅が過大でないか（2年目以降も初年度と同じ上乗せ幅のままになっていないか） 3. 年度途中のコスト変動への対応 情報システム担当または原課から四半期ごとに報告を受ける際、次の観点で確認します。 確認項目 主なチェックポイント 予算消化率 経過月数に対し、許容範囲であるかどうか 年度内の予算消化 予算内に収まる見通しかどうか 為替の影響 実績が予算レートを上回っている場合、予算の枠内に収まる見込みかどうか 最適化の取組 施策が実施されているか（「特になし」は要確認） 3.1 AWS Budgets による予算設定・予算超過の防止 GCASガイドの予実管理では、AWS Budgets に月次予算を設定することとされています。年間予算額（USD）を利用月数で除算して月次予算額を算出しつつ、季節変動を考慮し、繁忙月（確定申告時期の1〜3月等）は多めに、閑散月は少なめに配分されていることを確認してください。これらの設定を行うことで、予算超過が見込まれる場合に事前アラートにより早期検知と対策が可能になります。アラートの主な設定方法としては、①AWS Budgetsにより閾値を設定して予算上限超過を監視する、②AWS Cost Anomaly Detectionによりコスト急騰などの異常検知を行う、の2つが挙げられます。 アラートが発報された場合の原課の主な対応は、次のとおりです。 設定ミスや不要リソースの放置であれば即時是正 月末までと年度末までの累計見込みを算出し、意思決定権者に報告 予算超過が見込まれる場合に事前アラートの通知先に、財政課を含めておくことで、財政課側から対応を指示することが可能となり、早期の対策による予算超過の予防にも繋がります。 図: （参考）AWS Budgets と AWS Cost Anomaly Detection による予算超過・異常の検知 3.2 執行残発生時の扱い 従量課金では、利用が少なかった場合に執行残が発生します。発生要因には、次のようなケースがあります。 コスト最適化施策の成果（積極的な取組の結果） 想定より利用量が少なかった（利用者数が見込みを下回った等） 為替レートが有利に推移した（外部要因） 見積もり時の予備的な経費の設定が過大だった このうち、最適化の成果による執行残は、クラウドサービス及びFinOpsの活動の優れた成果になります。一方で、執行残が発生したことを理由に、翌年度予算を機械的に削減することにはリスクもあります。最適化の取組の再現性の検証、関連システムも含めた全体最適としての運用の確認等、次年度以降の変動事由の考慮等を踏まえる必要があります。そこで、最適化の効果が生じた翌年度（N＋1年度）は、効果が継続しているかを検証する期間とし、効果が定着したことを確認できた段階で、翌々年度（N＋2年度）の予算の見直しに反映するといった段階的な扱いも考えられます。政策目的に照らした適切なシステム運用等を目指しつつ、原課の意欲を最大限発揮することが可能な仕掛けで、FinOpsと効果検証を着実に進めることが重要です。 また、クラウドサービスの強みは、柔軟な機能拡張やログ分析基盤をスピーディに構築し、最新技術の短期間の試験運用等が可能である点です。これらは、住民サービスの向上、DXの加速化、セキュリティ強化にも直結するものであり、さらなる利便性と安心の好循環を生み出すことが期待されます。また、平時の運用管理やシステム/サービスを活用した執務の遂行について、更なる業務効率化に向け、最新のデジタル技術やAI等の活用を図ることも効果的です。 そのため、最適化の取組等により発生した執行残について、予算活用の短期・中期の運用サイクルとして、本来的な政策目的等を含め、原課・情報システム課・財政課その他の関係機関で認識合わせを行うことが重要です。その際、例えば、予算執行のルールの範囲内において、執行残をうまく活用しつつ、FinOpsの結果の定性化や最新技術の試用や実証実験等への活用を選択肢の一つとして検討することで、コスト最適化の取組を継続する動機付けにもなり得ると考えられます。 4. まとめ 以上、クラウドコストの予算管理をテーマとし、クラウド経費の予算査定・執行管理を行う際の実務的な視点についてご紹介いたしました。 繰り返しになりますが、クラウドは本番稼働後がコスト最適化のスタート地点です。クラウドサービス利用料の適正化によるコスト削減に努めつつ、柔軟な機能拡張やログ分析基盤をスピーディに構築し、最新技術の短期間の試験運用等を通じて、住民サービスの向上、DXの加速化、セキュリティ強化に取り組むことが期待されます。クラウドサービスの利用実績の可視化、削減提案、翌事業年度の改善提案・目標設定等のサイクルを効果的に実施することで、デジタル技術を使いこなし、効率的な行政運営と豊かで便利な社会を実現していただければと存じます。 より詳しく知りたい方へ 本記事で扱わなかった日々のコスト確認や調達仕様書への反映などは、シリーズの他の記事で解説しています。 やりたいこと 参照先 定期的なコスト確認の手順・チェックリストを知りたい シリーズ① 調達仕様書へのFinOps要件の反映方法を知りたい シリーズ②-1 生成 AI を使ったコスト確認の効率化を知りたい（公開予定） シリーズ②-2 運用管理補助者・ASPとして具体的に何をすべきか知りたい（公開予定） シリーズ④ Appendix 長期利用割引（リザーブドインスタンス・Savings Plans）の予算上の扱い AWSには、一定期間（1年又は3年）の利用を約束（コミット）することで割引を受けられる仕組みがあります。これは、自治体が複合機やコピー用紙を「年間契約」することで単価が下がるのと同じ考え方です。 通常利用（従量課金） ：毎月、使った分だけ定価で請求されます。 長期利用割引適用後 ：Savings Plans は「1時間あたりの利用金額（USD）」、リザーブドインスタンスは「インスタンスの種類と台数」を単位としてコミットし、コミット分には割引単価が適用されます。コミットを超えた利用分は通常の従量課金単価で請求されます。 購入・設定の流れ ガバメントクラウドでは、リザーブドインスタンス・Savings Plans のいずれも、自治体と合意した内容に基づいて運用管理補助者が購入・設定します。財政部門としては、購入の時期・期間・コミットの水準が予算と整合しているかを、情報システム担当とあらかじめ確認しておくことが考えられます。コミットは期間中の変更・取消が原則できないため、確実に利用する水準で設定することが重要です。購入時期の考え方は、シリーズ①の 2.2 で紹介しています。 自治体が過去の利用実績を基に、確実に利用する最低水準のコミット額を算出します。 デジタル庁に対して長期利用割引の適用を申請します。 デジタル庁が申請を取りまとめ、一括で割引を購入・適用します。 割引効果が自治体の月次利用料に反映されます。 ※ コミットは期間中の変更・取消が原則できないため、確実に利用する最低水準で設定することが重要です。申請手続きの詳細や最新の運用は、デジタル庁の案内をご確認ください。 免責事項 : 本記事の内容は情報提供を目的としたものであり、特定の環境や要件に対する推奨を保証するものではありません。実際の効果は個別の環境・構成により異なります。AWS サービスの料金は変更される場合がありますので、最新の料金情報は AWS 料金ページ をご確認ください。 ガバメントクラウドに関するご相談: ガバメントクラウドの利活用に関するご質問やご相談は、 AWS ガバメントクラウド相談窓口 までお問い合わせください。 筆者について Chisaki Noguchi 野口 智紗樹（Chisaki Noguchi）は、自治体向けの新規事業開発等担当です。中央省庁での勤務経験を活かし、政府の方針等を踏まえた中長期的な視点で、クラウドやAIを活用した行政課題・地域課題の解決、持続可能なサービスの構築等による豊かで便利な社会の実現に取り組んでいます。 Kazuki Fujimoto 藤本 一樹（Kazuki Fujimoto）は、パブリックセクターの自治体担当のソリューションアーキテクトです。自治体の基幹システムのクラウド移行やそれに伴うコスト最適化とモダナイゼーション、生成 AI の活用支援などをおこなっています。