2026 年 8 月 5 日、 Amazon DynamoDB でのベクトル検索の一般提供についてお知らせします。運用データとともにベクトル埋め込みを DynamoDB に保存し、別のベクトルストアにデータを複製することなく、そのデータに対して直接類似度検索を実行できるようになりました。 DynamoDB は、99%以上の再現率を維持しながら、1桁ミリ秒のレイテンシーでネイティブなベクトル検索をサポートします。また、数兆個のベクトルを含む大規模なデータにも対応できるよう設計されています。サーバーのプロビジョニング、パッチ適用、管理は一切不要で、ソフトウェアのインストール、保守、運用も必要ありません。このサービスにはバージョンの管理がなく、メンテナンスウィンドウも設定されておらず、メンテナンスによるダウンタイムもゼロです。 ベクトルインデックスにはストレージ容量の制限がなく、データの増加に応じて水平方向にスケールします。DynamoDB のネイティブなベクトル検索を利用することで、エージェント型メモリ、検索拡張生成（RAG）、レコメンデーションエンジン、パーソナライズされたエクスペリエンス、異常検知など、セマンティック検索を必要とするアプリケーションを構築できるようになりました。 アプリケーションですでに DynamoDB を使用している場合、これまではベクトル検索を追加するために、データを専用のベクトルデータベースにコピーし、2つのサービス間でデータを同期するパイプラインを維持する必要がありました。これにより、運用上のオーバーヘッド、データ移動コスト、ライセンスコストが増加し、さらに大規模環境で予測可能な低レイテンシーを維持するという課題も生じていました。DynamoDB にベクトル検索が組み込まれているため、ベクトルデータと運用データを同じサーバーレスインフラストラクチャ上で管理し、同じ従量課金（リクエスト単位の課金）モデルを利用できます。 DynamoDB のベクトル検索では、ベクトル埋め込みを格納する属性に対して作成する新しいタイプのインデックスが導入されています。任意のモデル（Amazon Bedrock Titan Text Embeddings、Cohere Embed、OpenAI のテキスト埋め込みモデルなど）を使用して埋め込みを生成し、標準の PutItem 呼び出しを使用して、浮動小数点数のリストとしてテーブルに保存できます。次に、その属性に対してベクトルインデックスを作成し、次元数、距離関数、およびクエリ実行時に検索結果を絞り込むためのフィルターとして使用する非ベクトル属性を指定します。 SearchVectors API は、クエリベクトル、返される結果の数 (最大 100)、およびオプションのフィルター条件を受け入れます。類似度でランク付けされた結果を返します。 運用データがすでに DynamoDB に存在していて、別のデータベースをプロビジョニングしたり、同期パイプラインを管理したりせずに類似検索を追加したい場合は、DynamoDB のベクトル検索を使用してください。DynamoDB は完全にサーバーレスなので、ベクトル検索はインフラストラクチャを管理しなくても自動的にスケーリングされます。最大 4096 次元、ユークリッド、コサイン、ドット積の距離関数、およびインラインフィルタリングをサポートします。 DynamoDB でのベクトル検索入門 このチュートリアルでは、 DynamoDB コンソール を使用して既存の DynamoDB テーブルにベクトル検索を追加する方法を示します。このシナリオには、製品カタログテーブルを備えたオンラインスポーツ用品店が含まれています。各アイテムには、 ProductID 、 カテゴリ 、 説明 、 マーケットプレイス 、 名前 、 価格 などの標準的な操作属性があります。目的は、セマンティック検索を追加することで、購入者が完全一致するキーワードではなく、自然言語によるクエリを使って商品を検索できるようにすることです。 1.DynamoDB テーブルを準備する セマンティック検索を有効にするために、まずテーブルにすでに保存されている商品説明のベクトル埋め込みを生成します。埋め込みとは、機械学習モデルによって生成され、テキストの内容が持つ意味を捉えた数値表現です。説明が似ている2つの項目は、ベクトル空間上で互いに近い位置にある埋め込みを持つため、これによって類似度検索が可能になります。 Amazon Bedrock Titan Text Embeddings やその他の埋め込みモデルを使用して埋め込みを生成し、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS CloudFormation 、またはその他の IaC ツールを使用して、それらをテーブルに追加できます。 既存の ProductCatalog のようなテーブルでは、 UpdateItem 呼び出しを使用して、各項目に descriptionEmbedding という新しい属性として埋め込みを追加します。DynamoDB は、既存の List データ型を使用してベクトル埋め込みを格納します。リストの各要素は、埋め込みベクトルの単一の浮動小数点数を表す 数値 です。つまり、既存の運用データの属性と一緒にベクトルを保存するために、新しいデータ型を導入したり、スキーマを変更したりする必要はありません。 2.ベクトルインデックスの作成 DynamoDBコンソール で ProductCatalog テーブルを開き、 インデックス タブを選択します。 ベクトルインデックスを作成 を選択します。 ベクトルインデックスを作成 ページでは、次のようにインデックスの詳細を入力します。 インデックス名 として ProductDescriptionIndex 、 ベクトル属性 として descriptionEmbedding を入力します。 埋め込みモデルの出力と一致する 次元数 を入力し、 距離関数 として コサイン を選択します。コサインはベクトルの大きさではなく角度を測定する指標であり、そのためテキスト埋め込みの意味的類似性を比較するのに有効です。DynamoDB のベクトル検索では、コサイン に加えて、 ユークリッド距離 と ドット積 の距離関数もサポートされています。 ユークリッド :購入回数などの数値でアイテムをクラスタリングする場合など、ベクトルの大きさが意味のある場合に使用します。 ドット積 :方向と大きさの両方が重要な場合に使用します。たとえば、関心の位置合わせと周波数を一緒に重み付けするレコメンデーションシステムの場合などです。原則として、距離関数を埋め込みモデルのトレーニングに使用した関数と一致させると、精度が最も高くなります。 パーティションキー として マーケットプレイス に入ります。ベクトルインデックスのパーティションキーは、DynamoDB がベクトルを各パーティションにどのように分散配置するかを制御するものであり、予測可能な低レイテンシーを維持しながら、インデックスを水平スケールアウトできるようにします。各検索は1つのパーティションキー値を対象として実行されます。そのため、複数のマーケットプレイス向けの商品カタログであっても、インデックス全体をスキャンすることなく、特定のマーケットプレイスの在庫のみを検索できます。パーティションキーは必須ではありませんが、大規模なデータセットやクエリスループットが高いワークロードでは、使用することが推奨されます。 インラインフィルター属性 を展開し、 フィルター属性としてカテゴリ を追加します。これにより、クエリ時に検索結果を特定の製品カテゴリに絞り込むことができます。フィルター条件では、完全一致の値のみサポートされます。 BETWEEN や BEGINS_WITH のような範囲条件はサポートされていません。検索結果にすべてのテーブル属性が含まれるよう、 属性の投影 は すべて に設定したままにしています。 ベクトルインデックスを作成 を選択し、インデックスのステータスが アクティブ に変わるまで待ちます。 3.ベクトル検索を実行 商品説明に使用したのと同じ埋め込みモデルを使用して、「 夏用の軽量ランニングシューズ 」などの自然言語検索用語からクエリベクトルを生成します。DynamoDB コンソールでは、左側のナビゲーションペインで 項目を検索 を選択し、 ProductCatalog テーブルを選択します。 検索 を選択してベクトル検索モードに切り替えます。 ベクトルインデックスを選択 ドロップダウンから ProductDescriptionIndex を選択し、クエリベクトルを 検索ベクトル フィールドに貼り付け、 結果の数 (上位 K) を 5 に設定します。 パーティションキー値 として US と入力して、検索範囲を米国のマーケットプレイスに限定します。  インラインフィルター属性を拡張し 、 カテゴリ を フットウェア と同じに設定して、検索をフットウェア製品のみに絞り込みます。最後に、 実行 を選択します。 DynamoDB は、フットウェアカテゴリ内で意味的に最も類似している5件の商品を、類似度スコアの高い順に返します。また、そのレスポンスには、商品名や価格などの通常の運用データ属性もあわせて含まれます。類似度スコアの意味は、インデックスに選択した距離関数によって異なります。コサイン距離関数とユークリッド距離関数では、類似度スコア値が低いほど類似度が高く、スコアが 0 の場合はベクトルが同一であることを示します。点積距離関数では、類似度スコアの値が高いほど類似度が高くなります。 API の呼び出しやドキュメントの検索など、ベクトル検索をプログラムで操作するには、お好みの AI コーディングツールで AWS MCP サーバー と プラグイン を試してください。 詳細については、 Amazon DynamoDB 開発者ガイドをご覧ください 。 今日から始めよう Amazon DynamoDB のベクトル検索は、一般的に AWS GovCloud (米国) リージョンを含むすべての商用 AWS リージョンで利用できます。リージョンごとの提供状況や今後のロードマップについては、 AWS のリージョン別提供機能 にアクセスしてください。料金の詳細については、 Amazon DynamoDB 料金表ページ をご覧ください。 ぜひ 8 月 5 日から DynamoDB のベクトル検索をお試しください。ご意見やご要望は、 Amazon DynamoDB の AWS re:Post 、または通常ご利用の AWS サポート窓口までお寄せください。 – Esra 原文は こちら です。

2026 年 5 月 22 日、金融庁と日本銀行は 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (金総政第 3245 号ほか) を公表し、経営トップを含めた経営層の直接関与の下で、短期的な対応に取り組むよう金融機関等に要請しました。 要請では、いわゆる「フロンティア AI」により、脆弱性の発見・修正等のサイバーセキュリティ性能の急速な向上が見込まれることを踏まえ、これに対応する取組が必要不可欠とされています。フロンティア AI を用いてソフトウェアの脆弱性を発見・修正する取り組みとしては、2026 年 4 月に Anthropic が発表した Project Glasswing と、その中核となる新クラスのモデル Claude Mythos があります。AWS はこの取り組みのローンチパートナーの一社であり、AWS Blog 「AI を活用した大規模なセキュリティ防御の構築 – 脅威が出現する前に」 で自らの取り組みを公開しています。 本記事では、金融庁・日本銀行の要請が求める 9 つの短期的対応のそれぞれについて、AWS のサービスと機能がどう役立つかを整理します。本記事で取り上げるサービスや機能は代表的な例であり、利用可能な選択肢のすべてを網羅するものではありません。また、AWS の利用だけで要請への対応が完了するものではなく、最終的な評価・統制・意思決定は各金融機関が行うものです。実際の対策の選定にあたっては、自組織のリスク特性やシステム構成を踏まえてご検討ください。 要請が指摘する脅威の変化 要請では、フロンティア AI により、従来は発見が困難だった脆弱性が短期間に発見され得ることに加え、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮され得ることが指摘されています。規模の目安として、次の数字があります。2025 年の 1 年間に公開された CVE (共通脆弱性識別子) は 48,185 件 (前年比約 20% 増) でした。一方、Anthropic が公表した 経過報告 (Project Glasswing: An initial update) によれば、Project Glasswing では約 50 のパートナー組織が Claude Mythos Preview を使い、開始から約 1 か月で深刻度 High または Critical の脆弱性を 1 万件超発見しています。さらに Anthropic 自身も 1,000 以上のオープンソースプロジェクトをスキャンし、モデルの推定を含め 23,019 件 (うち High/Critical は推定 6,202 件) の脆弱性候補を発見しました。Anthropic は発足時に、プロジェクトで得られた知見を 90 日以内に公に報告すると表明し、上記の経過報告として公開しました。また、発見された個々の脆弱性は、協調的脆弱性開示 (CVD) ポリシーに沿って、独立した検証とメンテナーへの通知、修正のための開示猶予期間を経て順次公開されています。これらの数字は、公開済みの CVE 件数とは期間・対象・検証状況が異なるため直接比較はできないものの、発見の後に続く検証・開示・修正の工程の処理能力が課題になり得ることを示しています。 ここで課題になるのが、パッチ適用までの時間差です。脆弱性が公表されパッチが公開されても、それを適用し終えるまでは脆弱性が残ります。この、公表から N 日が経過した既知の脆弱性を狙う攻撃は「N デイ攻撃」と呼ばれます (未知の脆弱性を狙うゼロデイ攻撃と対になる用語です)。Amazon の脅威インテリジェンスチームは、攻撃者が公開されたエクスプロイトを開示から数時間～数日で攻撃に転用する状況を観測しています。しかもこの速度は国家支援型のグループに限りません。公開された PoC や生成 AI の活用により、高度な技術を持たない攻撃者にも広がりつつあります。「四半期ごとに」「十分なテストを経てから」パッチを当てるという従来モデルでは、対応が間に合わない可能性があります。金融庁・日本銀行の要請でも、短期的に脆弱性やパッチが集中的に発見・提供される可能性を踏まえ、「経営トップを含めた経営層の直接関与」の下で迅速かつ適切に対応できる態勢の点検・強化が求められています。 一方で、英国 AI Security Institute (AISI) の 評価報告 (Our evaluation of Claude Mythos Preview’s cyber capabilities) では、現時点のフロンティア AI は十分に防御された IT システムに対しては攻撃を達成できるとは言えないとされています。つまり、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」に基づく基本的な対策を、より迅速かつ確実に実行していくことが、引き続き最も重要な出発点になります。 9 つの短期的対応に AWS サービスがどう役立つか 要請は 9 つの短期的対応を挙げています。これらは IT・サイバーセキュリティ担当部署のみで完結するものではなく、経営トップの正確な理解と危機意識の下で必要なリソース (予算・人員) を確保することが不可欠、というのが要請全体を貫く前提です。以下、各項目について AWS のサービスと機能でできることを整理します。 ① フロンティア AI への対応を経営課題として扱う この脅威は IT・サイバーセキュリティ部門にとどまらず、各業務所管部門・リスク管理・財務部門が横断的に連携すべき全社的な経営課題です。AWS では、サポート階層にかかわらず無料で利用できる Security Health Improvement Program (SHIP) や、 AWS セキュリティ成熟度モデル を通じて、自組織の現状を客観的に把握し、経営として優先順位とリソース配分を判断するための材料を提供しています。セキュリティ成熟度モデルは過去 1 年間で世界の 50,000 を超えるお客様に利用されています。 ② 優先的に対応すべきサービス/IT システムを特定する どのシステムが重要業務を支えているか、その業務影響の評価はお客様自身にしかできない判断です。技術面で支援できるのは、その判断の前提となる資産の把握です。 AWS Config や AWS Systems Manager のインベントリ機能を使うと、AWS 上のリソース構成や導入ソフトウェアを継続的に記録でき、「どこに何があるか」を洗い出す作業を支援します。そのうえで、 Amazon Inspector がワークロードを継続的に監視し、新しい脆弱性が公開されるとニアリアルタイムで再スキャンして、CVSS (共通脆弱性評価システム) のスコアだけでなくネットワーク到達性や悪用可能性を加味したリスクスコアを算出するため、インターネットバンキング等を支える外部公開システムから優先的に対処する、といったリスクベースの絞り込みに役立ちます。さらに、後述する AWS Continuum (限定プレビュー) は、インフラ・アクセス許可・ネットワーク構成に加え、ドキュメントやビジネス上の優先事項といった組織のコンテキストを取り込み、IT 資産の重要度を考慮した対応の優先順位付けを支援します。 ③ 特定した資産の技術負債を解消しておく 優先対象について、ソフトウェア構成・ネットワーク構成を再確認し、脆弱性発見時に即座にパッチ適用対象を特定できる状態を確保します。不要なネットワークポートの閉塞、特権 ID の削除、サポート終了製品のサポート対象バージョンへの更新が重要です。Amazon Inspector は監視対象リソースのソフトウェア部品表 (SBOM) を CycloneDX/SPDX 形式でエクスポート でき、サプライチェーンを含む構成の可視化に役立ちます。また、スタンドアロンツールの Amazon Inspector SBOM Generator を使うと、CI/CD パイプラインの中でコンテナイメージ等の SBOM を生成し、デプロイ前の脆弱性検出に活用できます。加えて、後述のマネージドサービスへの移行そのものが、OS・ミドルウェア層の技術負債を構造的に減らす有効な手段になります。 ④ パッチ適用に係る人的リソースを追加する / ⑤ ベンダーとの維持保守契約を確認する 人的リソースの追加やベンダー契約 (SLA/SLO、夜間・休日対応、責任分担) の確認は、まず組織・契約面の課題です。技術面からは、2 つの時間軸で補完できます。 短期的には、今あるサーバーのパッチ作業自体の自動化です。 AWS Systems Manager Patch Manager は、パッチベースラインとメンテナンスウィンドウを定義して、Amazon EC2 上のサーバーだけでなくオンプレミスのサーバーも含めてパッチの適用状況の確認と適用を自動化できます。手作業の適用・確認に費やしている時間を減らすことは、人的リソースの追加と同じ方向の効果を持ちます。 中長期的には、パッチ適用の対象そのものを減らすという考え方があります。 AWS Lambda 、 Amazon API Gateway 、 AWS Fargate 、 Amazon Aurora Serverless 、 Amazon DynamoDB などのサーバーレス・マネージドサービスを活用すると、責任共有モデルのもとで、基盤となるインフラストラクチャや AWS が管理するランタイムのパッチ適用が AWS の責任範囲となり、お客様はアプリケーションコード、コンテナイメージ、およびそれらの依存関係など、お客様の責任範囲に集中できます。 マネージドサービスへの移行に際して、AWS 側で行われる基盤メンテナンスが業務に影響しないか、気になるかもしれません。この点は、AWS がマネージドサービスをどのような構造で提供しているかという、責任共有モデルの AWS 側の設計から説明できます。 ホワイトペーパー「 AWS 障害分離境界 」が説明するとおり、Amazon DynamoDB や Amazon SQS などのマネージドサービスの多くは「リージョンサービス」として提供されます。リージョンサービスは、AWS が物理的に分離された複数のアベイラビリティーゾーン (AZ) の上に構築したサービスであり、お客様が複数 AZ の活用方法を設計する必要はありません。たとえば Amazon S3 はリクエストとデータを複数の AZ に分散し、1 つの AZ の障害から自動的に回復するように設計されています。この冗長な構造が、基盤の一部を更新しながらサービス全体は稼働を続ける、という運用の土台になっています。各サービスには、月間稼働率のサービスコミットメントと未達時の取り扱いを定めた SLA (サービスレベルアグリーメント) が公開されています。 その更新のプロセスについて、AWS は CSA (Cloud Security Alliance) の Consensus Assessments Initiative Questionnaire (CAIQ) への回答 の中で、本番環境へのすべての変更が「中断を最小化するための実装・ロールバック計画」「非本番環境でのテスト」「ピアレビュー」「承認」を経て、可能な限り手動ステップを排した継続的デプロイのパイプラインで実施されることを説明しています。個別のサービスにもこの設計は表れており、 Amazon DynamoDB はバージョンやメンテナンスウィンドウという概念自体を持たず「アップグレードやダウンタイムを必要とせず、可用性、信頼性、パフォーマンス、セキュリティ、機能を継続的に改善」し、Amazon Aurora の ダウンタイムのないパッチ適用 (ZDP: Zero-Downtime Patching) はエンジンのアップグレード中もクライアント接続の維持を試みます。実例として、Log4Shell (CVE-2021-44228) の際には、 稼働中の JVM にライブでパッチを当てるホットパッチ を AWS が開発してオープンソースとして公開し、AWS Fargate や AWS Lambda などのマネージドサービスの基盤には、お客様のアクションを必要とせず数日で展開しました。なお、要請ではクラウド事業者により提供される IT システムについて、パッチ適用に関する SLA/SLO の内容や適用状況が適切に報告される契約内容となっていることの確認が求められており、上記のホワイトペーパー・CAIQ 回答・SLA は、その確認の際の参考になります。 ⑥ パッチ適用プロセスをリスクベースにする CVSS スコアが高くない脆弱性でも実際の攻撃に使われる実態があり、この傾向はフロンティア AI によりさらに加速する可能性があります。Amazon Inspector は EPSS スコアや CISA の Known Exploited Vulnerabilities カタログ、公開された攻撃コードの有無、推奨パッチ適用期間といった脅威インテリジェンスを取り込み、攻撃が成立する蓋然性を踏まえた優先順位付けを可能にします。アプリケーションのテストとデリバリーについては、 AWS CodePipeline を中心とした CI/CD パイプラインで自動ビルド・自動テスト・段階デプロイ・自動ロールバックを構成することで、テスト不足によるシステム障害リスクを抑えつつパッチ適用期間を短縮できます。 ⑦ パッチ適用以外の対策も強化する 多層防御は、単一の対策の突破を前提に複数の防御層を重ねる、すべてのセキュリティ対策の基本です。パッチ適用も防御層の 1 つであり、適用そのものが困難な場合や適用までに時間を要する場合でも、他の層が攻撃の成立を防ぎ、被害を抑えます。要請では、こうした対策の例として、クラウド型の WAF 等を用いた「仮想パッチ」(個々の脆弱性に対応した侵入防御ルールにより、本来のパッチを早急に適用することが難しい場合に攻撃通信をブロックする暫定的なソリューション) の適用が挙げられています。AWS では、ウェブアプリケーションの層は AWS WAF が WAF 機能を提供し、既知の脆弱性を悪用する通信パターンをブロックするルールをまとめたマネージドルールが AWS により更新・提供されています。ネットワークの経路上では AWS Network Firewall が Suricata 互換の侵入防止システム (IPS) 機能を提供し、脆弱性を悪用する通信をシグネチャで検知・遮断するルールをまとめたマネージドルールグループが AWS により更新・提供されています。いずれも、アプリケーションやサーバーを修正するまでの間の防御層として利用できます。なお要請の脚注にあるとおり、こうした対策は恒久的な対応ではなく、パッチ適用までの暫定措置と位置づけることが重要です。このほか、ネットワーク分離、特権 ID への多要素認証、端末での不正検知・対応 (EDR) などがあります。要請が挙げる内部侵入後の横展開への対策としては、検知の層も必要です。 この多層防御の各層で活用できるのが、AWS の脅威インテリジェンスです。AWS は 1 日あたり 400 兆を超えるネットワークフローを分析し、 ハニーポットシステムの MadPot と、その脅威インテリジェンスをもとに悪意のあるアクティビティを自動的に制限する Sonaris を核とする アクティブディフェンス を運用しています。2025 年だけで Amazon S3 上のファイルへの不正暗号化の試み 3 億件超をブロックしました。この脅威インテリジェンスは AWS 内部の防御にとどまらず、お客様が利用できるサービスにも組み込まれています。 Amazon GuardDuty は AWS とサードパーティーの脅威インテリジェンスを機械学習と組み合わせてアカウントとワークロードのログを継続的に分析し、既知の脅威アクターとの通信や認証情報の悪用など、侵入後の横展開の兆候を検出します。 AWS Network Firewall のアクティブ脅威防御 は、MadPot が追跡するマルウェア URL やボットネットの C&C サーバー等の攻撃インフラを、マネージドルールグループ「AttackInfrastructure」として提供し、これらとの通信を自動的にブロックします。前述の AWS WAF マネージドルールも、この脅威インテリジェンスの還元先の 1 つであり、パッチ適用までの防御層として機能します。実例として、 React2Shell (CVE-2025-55182) では公開から数時間以内に国家支援型グループの悪用試行を MadPot で観測 し、Sonaris・AWS WAF マネージドルール等による多層の自動保護を展開したことをブログで公開しています。 ⑧ 優先サービス/IT システムの停止に備える 各種対策を徹底してもサイバー攻撃を防ぎきれない可能性を前提に、事業継続計画 (BCP) の有効性や緊急時の連絡体制、能動的なサービス停止の判断基準を明確にしておくことが求められます。これは共同運営形態やクラウド事業者が提供する IT システムについても同様です。マネージドサービスを活用している場合、基盤の可用性は AWS の責任範囲に含まれますが、業務要件に応じた構成、復旧目標、依存関係の整理、停止判断はお客様が設計・検証します。業務停止時の顧客対応手順も、引き続きお客様側で整備しておく必要があります。停止後の復旧の備えとしては、 AWS Backup の論理的にエアギャップされたボールトへのバックアップ保管が、ランサムウェア等でデータが侵害された場合の復旧手段の 1 つになります。 ⑨ 外部との連携を維持・強化する フロンティア AI に関する情報は短期間に多数公開されるため、自組織のみでの網羅的な把握は困難です。金融 ISAC や各業界団体・当局からの情報に積極的にアクセスするとともに、AWS からは AWS Security Bulletins や、 Amazon の脅威インテリジェンスチームによる注意喚起ブログ を通じた情報を継続的に提供しています。 AI の活用で脆弱性の発見を早める 要請への対応は「公開されるパッチにいかに追いつくか」が中心です。一方で Anthropic は、 Project Glasswing の拡大発表 の中で、6～12 か月以内に他の多くの AI 企業も Mythos クラスのモデルを持つと予想され、悪用を防ぐセーフガードなしにリリースされる可能性があると述べています。同様の能力が広く利用可能になれば、パッチが存在しない未知の脆弱性を突くゼロデイ攻撃への備えも重要性を増します。その 1 つとして、お客様自身が AI を活用して脆弱性を発見・修正するアプローチがあります。 AWS Security Agent (現在は AWS Continuum の一部) は、一般提供が開始されたオンデマンドペネトレーションテストにより、24 時間 365 日稼働する自律型のテストを手動テストと比べてわずかなコストで提供します。潜在的な脆弱性を特定した後に実際にエクスプロイトを試み、正当なリスクであることを検証したうえで、CVSS スコア・再現手順・修正提案付きでレポートします。設計ドキュメントや設計・ソースコードからの脅威モデリング (STRIDE 形式、プレビュー)、プルリクエストごとの自動スキャンとリポジトリ全体の深い分析の両方に対応するコードレビュー (プレビュー)、数時間で完了するペネトレーションテストと、設計からデプロイまでの開発ライフサイクル全体をカバーします。ペネトレーションテストは、AWS 上の環境だけでなく、他社クラウド上で稼働するシステムやオンプレミス、SaaS 環境にも対応します。新規のお客様は 2 か月間の無料トライアルを利用できます。 さらに、脆弱性を「見つけた後」の工程をマシンスピードで処理するのが AWS Continuum です。フロンティア AI により脆弱性の発見は速く・安価になった一方、どの脆弱性が自社のビジネスにとって重要かを判断し、実際に悪用可能かを検証し、修正までつなげる後工程は、人手による判断と部門間の調整に依存したままでは追いつきません。Anthropic 自身も、Project Glasswing の教訓として「制約は脆弱性を見つける速さではなく、検証・開示・修正の速さに移った」と述べています。Continuum for code vulnerabilities (限定プレビュー) はこの工程を対象とし、発見・優先順位付け・検証・緩和と修復という 4 つのフェーズを、脅威が生まれるのと同じマシンスピードで継続的に実行します。既存ツールの検出結果と独自スキャンを取り込み、インフラ・アクセス許可・ネットワーク構成などのコンテキストからビジネス影響を評価して優先順位付けし、隔離されたサンドボックス内で再現可能なエクスプロイトの構築を試みることで、悪用可能性が確認された問題に絞り込んだうえで、コードパッチやポリシー変更を提案します。これは、発見された脆弱性について「攻撃が成立する蓋然性も踏まえた評価」と「リスクベースの優先順位付け」を求める要請⑥の趣旨に沿ったアプローチです。動作は人間が推奨内容を確認して承認する learn モードから始まり、お客様の判断で自動修復 (enforce モード) へ段階的に引き上げる設計です。なお Continuum for code vulnerabilities は限定プレビューの段階にあり、金融サービス業界のお客様のフィードバックとともに形作られています。 独自のセキュリティワークフローを構築したい組織には、 Amazon Bedrock 上で複数のプロバイダーの最新フロンティアモデルから用途に合ったものを選ぶ選択肢があります。AWS PrivateLink の VPC エンドポイントを介して、インターネットを経由せずお客様の VPC から Bedrock に接続できます。ポリシー適用型のアクセス制御、モデルの検出効果を測る組み込みの評価ツール、お客様が定義したポリシーやドメインルールとの論理的一貫性を形式的手法で検証する自動推論チェック (AWS が公表した評価の範囲で最大 99% の検証精度)、カスタマイズ可能なガードレールを備え、自社のソースコードのスキャンを支援するワークフローの構築に活用できます。Amazon Bedrock は、日本政府のクラウドサービス評価制度である 「政府情報システムのためのセキュリティ評価制度 (ISMAP)」 の対象範囲に含まれています。また、Amazon Bedrock Marketplace を除き、Payment Card Industry Data Security Standard (PCI DSS) の対象範囲にも含まれています。これらの情報は、お客様が自組織のセキュリティ・コンプライアンス要件への適合性を評価する際の参考資料として利用できます。 まとめ – 今すぐ着手すること、中長期で取り組むこと フロンティア AI による脅威変化への対応は、2 つの観点から整理できます。 Project Glasswing 以降のパッチ公開ペースの変化に対しては、 今すぐパッチ適用を日常業務化し、インシデント対応体制を変革すること。中長期では、マネージドサービスを多用した IT システムのモダナイズにより、基盤レイヤーのパッチ運用の一部を AWS に委ね、お客様の運用負荷を軽減していくこと。 フロンティア AI の一般化により攻撃の高度化やゼロデイ攻撃のリスクが高まる可能性に対しては、 今すぐ AI を活用した脆弱性スキャンとセキュリティレビュー (AWS Security Agent、Amazon Bedrock + 最新モデル) で発見を早めること。中長期では、侵害を前提とした多層防御を徹底し、攻撃の影響を最小化すること。 いずれも、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」に基づく基本的な対策を確実に実行することが土台です。まずは自組織の現状把握から始めることをお勧めします。無料アセスメントプログラムの SHIP と AWS セキュリティ成熟度モデルをご活用いただけますので、担当の AWS アカウントチームにお気軽にお声がけください。 早見表 – 金融庁・日本銀行の要請と AWS サービスの活用 金融庁・日本銀行が求める 9 つの短期的対応について、AWS のサービス・機能がどう役立つかを一覧に整理しました。 # 金融庁・日本銀行の要請 AWS サービスの活用 (主なサービス・機能) ① フロンティア AI への対応を経営課題として扱う SHIP (無料) と AWS セキュリティ成熟度モデルで現状を客観評価し、経営としての優先順位付けとリソース配分の判断材料を提供 ② 優先的に対応すべきサービス/IT システムを特定する AWS Config / Systems Manager インベントリで資産を把握。Amazon Inspector が CVSS・ネットワーク到達性・悪用可能性を相関したリスクスコアを算出し、外部公開システムからの優先対処を支援。AWS Continuum (限定プレビュー) は組織のコンテキストから IT 資産の重要度を考慮した優先順位付けを支援 (業務影響の最終評価はお客様の判断) ③ 特定した資産の技術負債を解消しておく Amazon Inspector の SBOM (CycloneDX/SPDX) エクスポートで構成を可視化。Inspector SBOM Generator で CI/CD 内の SBOM 生成も可能。マネージドサービス移行で OS・ミドルウェア層の技術負債を構造的に削減 ④ パッチ適用に係る人的リソースを追加する 短期: Systems Manager Patch Manager でパッチ作業を自動化 (オンプレミス含む)。中長期: サーバーレス/マネージドサービス (Lambda、Fargate、Aurora Serverless、DynamoDB 等) で、責任共有モデルのもと、基盤インフラと AWS が管理するランタイムのパッチ適用を AWS の責任範囲に (コンテナイメージや依存関係はお客様責任)。マネージドサービスの多くは複数 AZ 上に構築されたリージョンサービスで、月間稼働率のサービスコミットメントを定めた SLA を公開 ⑤ ベンダーとの維持保守契約の内容を確認する AWS 全体の変更管理は CAIQ 回答で公開 (中断最小化・ロールバック計画・継続的デプロイ)。DynamoDB はメンテナンスウィンドウなし、Aurora は ZDP によりエンジン更新時のクライアント接続の維持を試みる (例: Log4Shell の稼働中 JVM ホットパッチ )。SLA/SLO・報告内容の確認の参考に ⑥ パッチ適用プロセスをリスクベースにする Amazon Inspector が EPSS・CISA KEV・攻撃コードの有無を取り込みリスクベースで優先順位付け。AWS Continuum (限定プレビュー) が悪用可能性をサンドボックスで検証し、確認された問題から修正を提案。AWS CodePipeline で自動テスト・段階デプロイ・自動ロールバック ⑦ パッチ適用以外の対策も強化する AWS WAF と AWS Network Firewall (IPS 機能) の各マネージドルールによる脆弱性悪用通信の遮断 (パッチ適用までの暫定措置)、ネットワーク分離、多要素認証、EDR 等の多層防御。脅威インテリジェンスを活用した防御として、Amazon GuardDuty (侵入後の兆候検知)、AWS Network Firewall アクティブ脅威防御 (攻撃インフラとの通信ブロック)。 AWS のアクティブディフェンス (MadPot/Sonaris) が観測した脅威を各サービスにフィードバック ⑧ 優先サービス/IT システムの停止に備える マネージドサービスの基盤の可用性は AWS の責任範囲。業務要件に応じた構成・復旧目標・停止判断の設計と検証、BCP・顧客対応手順の整備はお客様側で実施。AWS Backup の隔離バックアップが復旧手段の 1 つに ⑨ 外部との連携を維持・強化する AWS Security Bulletins と脅威インテリジェンスに基づく情報提供。金融 ISAC 等との連携を補完 加えて、公開されるパッチへの追随の先にある、AI による攻撃の高度化やゼロデイ攻撃への備えとして、 AWS Security Agent (一般提供のペネトレーションテストに加え、脅威モデリングとコードレビューはプレビューで提供)、 AWS Continuum (限定プレビュー。脆弱性の発見から優先順位付け・検証・修復までのライフサイクル全体をマシンスピードで自律処理)、 Amazon Bedrock + 最新フロンティアモデル (ソースコードのセキュリティレビューを支援するワークフローの構築。VPC エンドポイント経由で接続可能) をご活用いただけます。 関連情報 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請について (金融庁) AI を活用した大規模なセキュリティ防御の構築 – 脅威が出現する前に AWS Continuum のご紹介: マシンスピードで実現するセキュリティ AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 FISC 安全対策基準・解説書に関する AWS の情報 本記事は、金融庁・日本銀行 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (2026 年 5 月 22 日) および AWS の公開情報に基づいて作成しています。本記事で紹介するサービス・機能は代表的な例であり、すべての選択肢を網羅するものではありません。また、特定の対策の実施により被害の防止を保証するものではありません。記載のサービス仕様・提供状況・料金は変更される場合があります。最新情報は各サービスの公式ドキュメントをご確認いただき、具体的な対策の選定は自組織の環境に応じてご判断ください。 著者 能仁 信亮 (Shinryo Nonin) – 金融ソリューション本部 プリンシパルソリューションアーキテクト 中島 章博 (Akihiro Nakajima) – パブリックセクター技術統括本部 シニアセキュリティソリューションアーキテクト

はじめに この記事で学べること 前提知識・条件 結論となる3つの設計原則 原則1: コンテキストロットを前提に設計する すべての LLM（大規模言語モデル）は入力長に応じて性能が劣化する 1万行程度でもコンテキストに収まりづらい 実際どのくらいから劣化する？ ノイズとして取り込まれる要素 スマートゾーンとダムゾーン コンテキストエンジニアリング 対策としてのセッション・コンパクション 原則2: ソフトウェアを境界で分割し、近接して配置する（Pragmatic Lambda / モノレポ） なぜ境界が必要か モノレポで近接して配置する Lambda 関数の分割粒度、Pragmatic Lambd…