公開2024.06.13更新2026.08.16 AWS

AWS re:Inforce 2024の発表まとめ｜6件の現在のGA状況と2026年のre:Invent統合

AWS re:Inforce 2024の前後に発表されたセキュリティ機能は、2年余りを経てプレビューを抜けたもの、値下げされたもの、対応リージョンが確定したものに分かれました。この記事では主要6件それぞれの2026年8月時点の状況を、AWSの公式発表と現行ドキュメントの記述に沿って確認します。あわせて、2026年からre:Inforceという単独イベントが無くなる点も整理します。

まとめ：re:Inforce 2024前後の発表6件と2026年8月時点の状況

発表（2024年6月前後）	当時の段階	2026年8月時点	その後の主な変化
AWS Private CA Connector for SCEP	プレビュー	GA（2024年9月16日）	2026年3月にPrivateLink対応
IAMのパスキー対応	GA（6月11日）	GA継続	Windows Helloのローカル登録は非対応
ルートMFA義務化（別ロールアウト）	管理／スタンドアロン	全アカウント種別	2025年春から段階適用
IAM Access Analyzer 是正推奨	GA（6月11日）	GA継続・追加料金なし	2025年6月に組織内アクセス検証がGA
GuardDuty Malware Protection for S3	GA（6月11日）	GA継続	2025年2月にスキャン単価85%減
CloudTrail Lake 自然言語クエリ	プレビュー	GA（2024年11月13日）	東京を含む7リージョンで提供

プレビューだった2件はいずれもGAに到達しました。実務でコスト影響が大きいのはGuardDutyの85%値下げ、設計影響が大きいのはルートユーザーMFAの全アカウント義務化です。なお表の3行目にあるルートMFA義務化はキーノートでの新機能発表ではなく、2024年5月から並行して進んでいた別のロールアウトです。

2026年からre:Inforceはre:Inventに統合

まず押さえるべきなのは、AWS re:Inforceがイベントとして単独開催されなくなった点です。AWSの公式イベントページは「In 2026, AWS re:Inforce will join AWS re:Invent.」と明記し、次の開催先としてre:Invent（2026年11月30日から12月4日、ラスベガス）を案内しています。単独開催の最後は2025年6月16日から18日のフィラデルフィア開催で、キーノートはAWSのバイスプレジデント兼CISO（最高情報セキュリティ責任者）であるAmy Herzog氏が務めました。

この統合は、過去のre:Inforce記事を情報源として扱うときの注意点にもなります。2026年以降は「re:Inforceで発表」という区切りが存在せず、セキュリティ関連の新機能はre:Inventのアナウンスに混ざります。年次イベント単位で追う運用をしているなら、参照先をre:Inventのwhat’s newに切り替える必要があります。

AWS Private CA Connector for SCEP：2024年9月GA、追加料金なし

2024年6月にプレビューで登場したSCEPコネクタは、2024年9月16日にGAとなりました。SCEPはMDMがCAから証明書を受け取るために広く使われるプロトコルで、コネクタを挟むことでMicrosoft IntuneやJamf Proといった「SCEP対応MDM」からAWS Private CAに証明書を発行させられます。AWSの発表は対応MDMを「including, but not limited to」と書いており、IntuneとJamf Proだけに限定されるわけではありません。

料金は「この機能自体は追加料金なし」で、支払うのはAWS Private CA本体と発行した証明書の分だけです。GA発表時点での提供範囲は、AWS Private CAが使えるリージョンのうちGovCloudと中国リージョンを除いた範囲とされていました。2026年3月12日にはPrivateLink対応が追加され、VPCエンドポイント経由でコネクタに接続できるようになりました。インターネットゲートウェイやNATデバイス、VPN接続を用意せずに閉域で証明書を配れるため、MDMをVPC内で運用している構成では設計が一段簡単になります。なお、公開証明書の管理はAWS Private CAではなくACMの役割で、両者の違いはAWS Certificate Managerの有効期間198日化とACME対応をまとめた記事で整理しています。

IAMパスキー対応とルートMFA義務化：2024年6月開始、2025年に全アカウント種別へ

2024年6月の発表のうち、その後もっとも運用に効いたのが認証まわりです。ただしパスキー対応と義務化は別々の話で、混同すると導入設計を誤ります。

パスキーの位置づけ：第2要素でありパスワードレスではない

2024年6月11日の発表タイトルは「AWS Identity and Access Management now supports passkey as a second authentication factor」で、パスキーはあくまでMFAの第2要素です。パスワードを省略してパスキーだけでサインインできるという意味ではありません。この位置づけは2026年8月時点の公式ドキュメントでも変わっておらず、AWSはパスキーとセキュリティキーをフィッシング耐性のあるMFAとして推奨する一方、サインイン自体はパスワードとの組み合わせを前提にしています。パスワードそのものを廃する方式との違いはパスワードレス認証の方式4分類を整理した記事で確認できます。

対応認証器の変化：Windows Helloのローカル登録は非対応

2024年6月の発表文はビルトイン認証器として「Touch ID on Apple MacBooks and Windows Hello facial recognition on PCs」を挙げていましたが、2026年8月時点の現行ドキュメントの記述は異なります。IAMのサポート構成ページは「IAM does not support local passkey registration for Windows Hello.」と明記し、Windowsユーザーにはクロスデバイス認証を使うよう案内しています。モバイル端末やハードウェアセキュリティキー側でパスキーを作り、ノートPCでのサインインにそれを使う流れです。プラットフォーム認証器としてサポートされるのはTouch IDやFace IDで、発表当時の記述だけを見てWindows端末にローカル登録を計画すると、展開時につまずきます。

そのほか、ルートユーザーとIAMユーザーはそれぞれ最大8個のMFAデバイスを登録でき、サインインに必要なのはそのうち1個です。SMSによるMFAはすでにサポートが終了しています。

ルートMFA義務化の3段階：2025年春からメンバーアカウントへ

ルートユーザーのMFA必須化は一度に来たわけではなく、2024年5月にAWS Organizationsの管理アカウント、2024年6月にスタンドアロンアカウント、そしてメンバーアカウントへと広がりました。AWSのセキュリティブログは「Beginning in the Spring of 2025, customers who have not enabled central management of root access will be required to register MFA for their AWS Organizations member account root users in order to access the AWS Management Console.」と書いており、2025年春から段階的に適用されたうえで、2025年6月17日に全アカウント種別への適用が告知された流れです。現行のIAMドキュメントは「MFA is enforced for all account types for their root user.」と書いており、スタンドアロン・管理・メンバーのいずれであってもルートユーザーのMFAは前提条件になっています。多要素認証そのものの方式比較は多要素認証（MFA）の3つの認証要素と耐フィッシングMFAを解説した記事にまとめています。

CLI運用の落とし穴：パスキーはSTSに渡せない

導入前に確認すべき制約が2つあります。1つはパスキーとセキュリティキーの有効化がAWSマネジメントコンソールからしか行えず、AWS CLIやAPIでは登録できないこと。もう1つは、セキュリティキーやパスキーのMFA情報をAWS STSのAPIに渡して一時認証情報を要求できないことです。現行ドキュメントは「AWS supports using passkeys and security keys only in the AWS Management Console.」として、MFA保護されたAPI操作への利用も対象外としたうえで、CLIやSDKで使う認証情報はaws loginコマンドで取得するよう案内しています。既存のスクリプトが仮想MFAデバイスのコードをget-session-tokenに渡す前提で組まれている場合、パスキーへ一律に移行すると自動化が止まるため、人間のコンソール利用から段階的に切り替えるのが安全です。IAM全体の権限設計はAWS IAMの仕組みと権限設計のベストプラクティスを解説した記事を参照してください。

IAM Access Analyzer：未使用アクセスの是正推奨は追加料金なし

2024年6月11日にGAとなった「未使用アクセスの是正推奨」は、検出して終わらせずに直し方まで示す点が要点です。未使用のロール・アクセスキー・パスワードについてはコンソールに削除用のクイックリンクが出ます。未使用の権限については、既存ポリシーを読んだうえで実際のアクセス実績に合わせた絞り込み版を提案します。ゼロから書き直すのではなくポリシーの構造を保ったまま未使用の権限だけを落とすため、レビューの差分が追いやすい形です。料金は未使用アクセスの検出（unused access findings）の範囲内で追加料金なしです。

リージョンの扱いは機能ごとに分かれるので注意してください。2024年6月の発表時点で「AWS商用リージョンのみ、GovCloud（US）と中国リージョンは対象外」とされたのは是正推奨（recommendations）の話です。検出機能そのものは後に拡大し、2025年7月22日に未使用アクセス検出・内部アクセス検出・カスタムポリシーチェックがGovCloud（US）へ対応しました。機能追加も続いており、re:Inforce 2025にあたる2025年6月17日には、AWS組織内のどのプリンシパルが重要リソースにアクセスできるかを検証するinternal access findingsがGAになっています。2024年時点の「使われていない権限を削る」から、「組織内部からの到達性を確かめる」方向へ守備範囲が広がりました。

GuardDuty Malware Protection for S3：2025年2月にスキャン単価を85%引き下げ

この機能は2024年6月11日にGAとして発表されました。S3バケットに新しくアップロードされたオブジェクトをスキャンし、結果はAmazon EventBridge経由で通知されます。検疫用バケットへの隔離や、タグを使ったバケットポリシーでのアクセス遮断といった後続処理を組める設計です。アカウントでGuardDuty本体を有効にしていなくても、この機能だけを単独で有効化できる点は、セキュリティ部門ではなくアプリ側のオーナーが導入する場合に効きます。

採用判断で重いのは料金です。課金はスキャンしたデータ量と評価したオブジェクト数の2軸で、2025年2月1日付でデータ量側の単価が85%引き下げられました。バージニア北部で1GBあたり0.60ドルから0.09ドルになった計算です。オブジェクト評価数側の単価は据え置きで、値下げは対応する全リージョンへ自動適用されたため、利用者側の作業は不要でした。2024年当時の見積もりで「S3全体のスキャンはコストが合わない」と見送った構成なら、データ量が支配的なワークロードでは再計算する価値があります。GuardDuty全体の保護プランと検出の仕組みはAmazon GuardDutyの脅威検出の仕組みを解説した記事で整理しています。

CloudTrail Lakeの自然言語クエリ：2024年11月GA、東京を含む7リージョン

2024年6月にプレビューで発表された自然言語クエリ生成は、2024年11月13日にGAとなりました。「先週、権限不足で失敗したAPIイベントは何か」といった問いを平易な英語で投げるとCloudTrail LakeがSQLを生成する機能で、AWS CLIのgenerate-queryコマンドからも利用できます。プロンプトは3文字以上500文字以下、英語のみという制約があります。対応リージョンはムンバイ、シドニー、東京、カナダ中部、ロンドン、バージニア北部、オレゴンの7つで、これはGA当時から2026年8月時点の公式ドキュメントまで変わっていません。

料金の考え方は明快です。ドキュメントは「There are no charges for generating queries; however, when you run queries, you incur charges based on the amount of optimized and compressed data scanned.」と書いており、生成自体は無料で、課金は実行時のスキャン量に紐づきます。生成が手軽になるぶん試行回数が増えやすいので、コスト管理としてはeventTimeの開始・終了を必ず付けて範囲を絞る運用が推奨されています。

日本から使う場合に効いてくるのが推論の処理地です。ドキュメントは「Inference requests originating within Japan will be processed within Japan」と明記しており、データ自体もリクエスト元のリージョンに保管されたままです。一方、同時に発表されたクエリ結果の要約機能は、2026年8月時点でもプレビューのままで、東京・バージニア北部・オレゴンの3リージョンに限られます。発表から1年9か月プレビューが続いている状態なので、本番の運用手順に組み込むのは待つのが無難です。CloudTrailの証跡設計と課金の考え方はAWS CloudTrailの仕組みと料金体系を解説した記事にまとめています。

生成AIセキュリティ：スコーピングマトリクスは5スコープ、エージェント向けは4スコープ

生成AIセキュリティはre:Inforce 2024のテーマの一つでしたが、実務で使うフレームワーク自体は機能発表とは別に公開されています。中心となるGenerative AI Security Scoping Matrixは5つのスコープで構成されます。Scope 1がConsumer app（公開の第三者生成AIサービスを利用）、Scope 2がEnterprise app（生成AI機能が組み込まれた第三者の業務アプリを利用）、Scope 3がPre-trained models（既存の第三者基盤モデルで自社アプリを構築）、Scope 4がFine-tuned models（自社データで第三者モデルをファインチューニング）、Scope 5がSelf-trained models（自社データでモデルをゼロから構築・学習）です。

AIエージェント向けには、2025年11月21日公開のAgentic AI Security Scoping Matrixが別建てで用意されており、こちらは4スコープです。Scope 1のNo agency（人が起動し、環境を変更せず読み取りのみ）、Scope 2のPrescribed agency（変更を提案できるが実行前に人の承認が必須）、Scope 3のSupervised agency（人が起動し、以降は承認なしで環境を変更できる）、Scope 4のFull agency（環境要因で自ら起動し、継続的に動作）という区分です。

ここで誤読しやすいのがScope 4の扱いです。実行のたびに人が承認する必要はなくなりますが、AWSは監督が不要になるとは書いていません。同記事はScope 4でも「maintain meaningful human oversight through strategic checkpoints, behavioral reporting, and manual override capabilities」と述べ、監督は消えるのではなく、戦略的なチェックポイント・挙動レポート・手動オーバーライドという形に変わると位置づけています。自社の用途がどのスコープに当たるかで責任分界と必要な統制が変わるため、生成AIとエージェントを混ぜて1つの基準で評価しないことが実務上の分かれ目になります。

よくある質問

re:Inforce 2024の発表を後から追う際に問い合わせの多い点を、一次情報に基づいて整理します。

AWS re:Inforce 2026は開催されますか？

単独開催はされません。AWSの公式イベントページは「In 2026, AWS re:Inforce will join AWS re:Invent.」として、2026年11月30日から12月4日にラスベガスで開催されるre:Inventへの統合を案内しています。単独イベントとしての最後は2025年6月16日から18日のフィラデルフィア開催でした。

re:Inforce 2024前後の発表のうち、今もプレビューのものはありますか？

本記事で扱う6件については、プレビューだったAWS Private CA Connector for SCEP（2024年9月16日GA）とCloudTrail Lakeの自然言語クエリ生成（2024年11月13日GA）が、いずれもGAに到達しています。ただしCloudTrail Lakeで同時期に発表されたクエリ結果の要約機能は、2026年8月時点の公式ドキュメントでもプレビュー表記のままです。

AWS IAMのパスキーでパスワードなしのログインはできますか？

できません。2024年6月11日の発表は「passkey as a second authentication factor」というタイトルのとおり、パスキーをMFAの第2要素として使う機能です。サインインにはパスワードとの組み合わせが必要で、この位置づけは2026年8月時点のドキュメントでも変わっていません。

AWSのパスキーはWindows Helloで登録できますか？

できません。現行のIAMサポート構成ページは「IAM does not support local passkey registration for Windows Hello.」と明記しています。Windows環境では、モバイル端末やハードウェアセキュリティキーで作ったパスキーをクロスデバイス認証で使う形になります。2024年6月の発表文にはWindows Helloの記載がありましたが、現在の記述とは異なる点に注意してください。