Cloud

概要 AWSは、組み込み型のオープンソース分析データベースDuckDBを開発するオランダ・アムステルダム拠点のDuckLabs B.V.を買収することで最終契約を締結したと発表した。買収額は非公開だが、取引は2026年9月の完了を見込んでいる。DuckDBは1日あたり300万件を超えるダウンロードを記録する人気プロジェクトで、SQLiteが軽量なトランザクション処理向けデータベースとして普及したのと同様に、分析(OLAP)向けの「組み込み型」データベースとして広く使われている。C++で実装され、サーバーのインストールや管理を必要とせずアプリケーションに直接組み込める点や、PythonのPandasライブラリなどと直接連携できる点が特徴だ。 買収後もDuckDB自体はMITライセンスの下でオープンソースとして提供され続け、独立したDuckDB Foundationがプロジェクトの統治を継続する。共同創業者のHannes MühleisenとMark Raasveldtは、アムステルダムを拠点にAWS社内でエンジニアリングチームを率い、技術的な方向性を主導していく。AWSのAndy Warfield副社長は「DuckDBは素晴らしいコミュニティを持つ優れたオープンソースプロジェクトであり、S3の顧客に広く使われ、愛されている」とコメントしている。 買収の狙いと技術的背景 DuckDBは、世界のSQLクエリの9割以上を占めるとされる1TB以下の中小規模データ分析に特化した設計で、ベクトル化実行エンジンによりコンパイルを介さずにクエリを高速処理できる点が強みだ。AWSはこのアーキテクチャを、S3やRedshiftといったエンタープライズ規模のサービスと統合し、特にAIエージェントがデータと対話する際の基盤として最適化したい考えを示している。両社の協業は今回が初めてではなく、2025年初頭にはAmazon S3 TablesおよびSageMaker LakehouseへのDuckDB統合が既に進められていた。実例として、Allen Instituteでは数分かかっていたクエリが1秒未満に短縮され、Amazon QuickではDuckDB統合により平均クエリレイテンシが30%削減されたという成果も報告されている。 ガバナンスと業界への影響 オープンソースプロジェクトが大手クラウドベンダーに買収される事例では、コミュニティのガバナンスが特定企業の意向に左右されるのではないかという懸念が付きまとう。これに対しDuckLabsのMühleisen CEOは、DuckDB Foundationの役割を拡大し、新たに技術諮問委員会(Technical Advisory Board)を設置する方針を示した。これにより、DuckDBの拡張機能をエコシステムに組み込む他のクラウドベンダーや企業も、AWSとの利害対立を懸念することなくプロジェクトの方向性に関与できる仕組みを整えるとしている。DuckDBの拡張機能エコシステムについても、サードパーティによる署名付き拡張への対応拡大が計画されている。ライセンスと統治体制の独立性が実際にどこまで維持されるかは、今後のFoundationの運営体制が注目点となりそうだ。

概要 Anthropicは、英国のAIインフラ新興企業Nscaleと6年間で総額450億ドル規模のコンピュート調達契約を締結した。年間平均約75億ドルに相当するこの契約は、ウェストバージニア州に建設中のNscaleの主力データセンターの計算能力、約460メガワット分を対象とする。稼働開始は2027年後半を予定しており、Nvidiaの次世代チップシステム「Vera Rubin」を用いて計算資源を供給する。Vera Rubinは6種類の異なるチップが協調動作する構成で、現時点のチップ設計の最先端に位置づけられる。 Nscaleという企業とディールの位置づけ Nscaleはロンドンに拠点を置く設立からわずか2年ほどの新興企業でありながら、Microsoftとも契約を結ぶなど急成長を遂げてきた。今回のウェストバージニア州の施設は、もともとMicrosoftが計画していたものの撤退した経緯があり、そこにAnthropicが入る形となった。今回の契約はNscaleが抱える総額510億ドルの契約残高の中でも最大規模となる。Nscaleは米国での新規株式公開(IPO)を準備しており、Anthropic自身も将来的なIPOを見据えているとされ、両社にとって今回の大型契約は資本市場での評価を高める材料となる可能性がある。 計算資源獲得競争の加速 Anthropicはこの8カ月間で、ノルウェーのVoltaとの100億ドル規模の契約、AMDとの50億ドル規模の関連契約、SpaceXとの月額12.5億ドル相当の契約、さらにAmazon・Google・Broadcomとの契約拡張など、立て続けに大型のコンピュート調達契約を結んできた。背景には、OpenAIをはじめとする競合他社との開発競争があり、モデルの学習・推論を支える計算基盤の確保が各社にとって最優先課題となっている。Google、OpenAI、Metaも同様に計算資源の争奪戦に加わっており、AI業界全体で数百億ドル規模のインフラ投資が連鎖的に発表される状況が続いている。 今後の見通し Nscaleの施設が稼働を開始する2027年後半までには、Vera Rubin世代のチップが実際にどの程度の性能を発揮するかが注目される。Anthropicにとっては、複数のクラウド・チップベンダーと分散して契約を結ぶことで供給リスクを分散しつつ、モデル開発のスケールを維持する狙いがあるとみられる。一方で、こうした巨額契約の積み重ねはAnthropicの資金調達負担を増大させており、IPOを含む資本戦略の行方が今後の焦点となりそうだ。

概要 AWSは2026年8月20日、AWS Direct Connectに「インバウンドプレフィックス制御」という新機能を追加したと発表した。この機能により、オンプレミスネットワークからAWSへ接続するプライベートVIF（Virtual Interface）およびトランジットVIFごとに、受け入れるインバウンドルートプレフィックスの割り当て数をワークロードの要件に応じて管理できるようになる。あわせて、VIF1本あたりに受け入れ可能な経路数の上限が、IPv4・IPv6それぞれ従来の100プレフィックスから1,000プレフィックスへと10倍に引き上げられた。 技術的な詳細 従来のDirect Connectでは、オンプレミス側からアドバタイズされる経路プレフィックスをプライベートまたはトランジットVIF上で受け入れる際の上限が100プレフィックスに固定されており、多数のVPCやオンプレミスセグメントを持つ大規模なネットワーク構成ではこの制約がボトルネックになりやすかった。新機能では、この上限が1,000プレフィックスまで拡張されるだけでなく、VIF単位でどれだけのプレフィックス容量を割り当てるかをユーザー自身が制御できる仕組みが導入される。 プレフィックスの容量プールは、専有接続（dedicated connection）レベルと、複数の接続やリージョンをまたいで経路を集約するDirect Connect Gateway（DXGW）レベルの両方に用意される。VIFを作成する際に特定数のプレフィックスを割り当てると、その割り当ては接続レベルとDXGWレベルの両方のプールから消費される仕組みとなっており、ネットワーク全体でのプレフィックス配分を柔軟に設計できる。設定はAWS Direct Connectコンソール、CLI、APIのいずれからも行える。 対応リージョンと料金 この機能はすべての商用AWSリージョンに加え、AWS GovCloud（US-East、US-West）、および中国の北京・寧夏の各リージョンで利用可能となっている。機能の利用に追加費用は発生せず、既存のDirect Connect利用者はそのまま新しい制御機能を使い始められる。 背景と今後の展望 近年、企業のハイブリッドクラウド環境は多数のVPCやオンプレミスサブネットを抱えるケースが増えており、経路プレフィックス数の上限は大規模なマルチアカウント・マルチVPC構成を運用する組織にとって現実的な制約となっていた。今回の10倍への拡張とVIF単位での柔軟な割り当て管理により、AWSはより大規模で複雑なネットワークトポロジーをDirect Connect経由で構築しやすくする狙いがあるとみられる。詳細な設定方法については、AWSが公開しているDirect Connectユーザーガイドの該当ページで確認できる。

概要 Kubernetesプロジェクトは8月26日、最新版となる「Kubernetes 1.37」を正式リリースした。今回の目玉は、実に9年近くベータ版のまま据え置かれていたMetrics API（metrics.k8s.io）がついに安定版（GA）へ到達したことだ。同APIは2017年3月にAlphaとして導入され、同年9月にBetaへ昇格して以降、Horizontal Pod Autoscaler（HPA）やkubectl topコマンドなど、実運用で広く使われながらも長らくベータのステータスにとどまっていた。スキーマ自体はほとんど変更されておらず、安定した実績を踏まえて今回ようやく正式に昇格した形だ。なお新しいv1と既存のv1beta1はAPIの見た目上は同一で、移行は非破壊的に行われ、v1beta1は今後のリリースで段階的に廃止される予定となっている。 Kubernetes 1.37全体では、KYAMLの出力サポートやPodレベルのリソース管理、DRA（Dynamic Resource Allocation）関連の機能強化など、合計16件のエンハンスメントが安定版に昇格した。これらを含め、Alpha・Beta・Stableの各段階への昇格を合わせると28件の変更が今回のリリースに盛り込まれている。 技術的な詳細 安定版に到達した主な機能としては、kubectl向けの新しい出力形式「KYAML」が挙げられる。KYAMLはマップを波括弧{}、リストを角括弧[]で表現することで、インデントの解釈違いなどYAML特有の落とし穴（いわゆる「ノルウェー問題」）を解消する標準フォーマットとして安定版入りした。また、コンテナ間でCPU・メモリ・hugepageのリソースプールを共有できる「Pod-level resources」も安定版に昇格している。 DRA関連では、ハードウェア障害時の扱いを制御する「デバイスレベルのtaintとtoleration」がGAに到達したほか、NUMAノードのトポロジー情報を標準的に公開するresource.kubernetes.io/numaNode属性の導入、ドライバー固有の状態情報を扱う「Resource Claim Status」の安定化、DRAのメタデータをDownward API経由でワークロードに公開する機能のBeta昇格など、ハードウェアリソースのきめ細かな管理に向けた改善が進んだ。このほか、SELinuxマウントの最適化が安定版に昇格し、コンテナ単位のulimit設定がAlpha機能として新たに追加されている。 非推奨化と廃止の動き 今回のリリースでは複数の機能で非推奨化・段階的廃止が進められた。kubectl runコマンドの--filename/-fフラグは、生成されるPodがCLI引数のみから構築される設計であることを理由に非推奨となった。また、Static PodがSecretやConfigMapを直接参照することも禁止される。Static PodはAPI経由で作成されないため、こうしたAPIリソースへの直接参照は本来の設計外だったための対応だ。 kube-proxyのIPVSモードについても、多リリースにわたる段階的な非推奨化が始まった。1.37では非推奨の警告ログが出力されるようになり、1.40でデフォルト無効化、1.43で完全削除される計画が示されている。背景にはIPVSがKubernetes Servicesの実装を完全にはカバーしておらず、内部的にiptablesへの依存が残っていることがある。並行してkube-proxyのデフォルトをNFTablesへ移行する動きも進んでおり、1.37ではその移行に向けた警告が出始めている。さらに、cgroup v1のサポート廃止に向けた動きも継続しており、1.35以降kubeletの設定でfailCgroupV1がデフォルトで有効になっているため、明示的な設定なしにcgroup v1に依存するノードはkubeletの起動に失敗するようになっている。 今後の展望 Metrics APIのGA到達は、長年ベータのまま実運用を支えてきたコンポーネントに正式な安定性の裏付けが与えられたという意味で象徴的な出来事だ。一方で、IPVSモードやcgroup v1、kubectl run -fなど複数の機能が今後複数リリースにわたって段階的に姿を消していく方針が示されており、運用者にはNFTablesやcgroup v2への移行、CLIスクリプトの見直しなど、計画的な対応が求められることになる。

概要 Google Cloudは8月20日、Gartnerが発表した2026年版「Magic Quadrant for Cloud-Native Application Platforms（CNAP）」において3年連続でリーダーに選出されたと発表した。同部門では、サーバーレス、コンテナ、そしてエージェント型ワークロードまでを単一の環境で扱える、開発者中心のプラットフォームであることが評価のポイントとなっている。インフラの複雑さを開発者から隠蔽し、コードを書くことそのものに集中できる設計思想が一貫して評価につながっているという。 アイデアから実装までを支える機能群 Google Cloudは、開発の初期段階を支える取り組みとして、Google AI Studio上でフルスタックのアプリケーションを構築し、ワンクリックでCloud Runにパッケージング・公開できる「Vibe Coding」の仕組みを挙げている。あわせて、Model Context Protocol（MCP）に対応したGoogle管理のCloud Run MCPサーバー（run.googleapis.com/mcp）を提供し、IAMやVPC Service Controls、Model Armorによるコンテンツセキュリティと統合することで、AIエージェントが安全に外部ツールと連携できる基盤を整えている。さらに、Agent Registry上で公開される認定済みスキルを集めた「Google Skills Repository」も用意し、Cloud Runやセキュリティ・信頼性・コスト最適化といったWell-Architectedの各柱に対応したスキルを提供している。 エンタープライズ向けの構築・運用・デプロイ機能 本番運用を見据えた機能も強化されている。構築フェーズでは、多段階のAI推論を開発ワークフローに統合する「Google Antigravity」や、Terraform・YAML設定の自動生成とビジュアルなアーキテクチャ設計を可能にする「Application Design Center（ADC）」があり、Gemini Cloud Assistの設計エージェントと連携してポリシー準拠のインフラ構成を自動プロビジョニングできる。運用フェーズでは、Gemini Cloud AssistがログやメトリクスからDay-2インシデントの根本原因分析や修復案の提示を行い、機械学習によるコスト異常検知も備える。デプロイフェーズでは、単一のgcloudコマンドでマルチリージョン展開や自動フェイルオーバーを実現できる高可用性機能に加え、CNCFへの主要貢献を通じたオープンソース戦略も継続している点が紹介されている。 エージェント時代を見据えたプラットフォーム基盤 もう一つの柱が「Gemini Enterprise Agent Platform」だ。セッション管理やメモリバンクによるパーソナライゼーション、OpenTelemetryベースのエージェント観測性、ゴールデンセットによるエージェント評価・シミュレーションといった機能を備えたAgent Runtimeが中核となる。Cloud Run上では、長時間稼働するシングルトンリソース向けの「Cloud Run instances」（近日提供予定）や、500ミリ秒未満のコールドスタートで未信頼コードを実行できる「Cloud Run sandboxes」が用意される。ガバナンス面では、非人間ID向けのIAMや暗号化ID・監査証跡を扱う「Agent Identity」、認定済みエージェントやツールを管理する「Agent Registry」、Model Armorのポリシーに基づき危険な挙動をブロックする「Agent Gateway」といった仕組みでエージェントの安全な運用を支える。 背景と今後の展望 Gartnerの評価は、生成AIの普及により開発サイクルが大幅に短縮される中、初級開発者からエンタープライズのAIエージェントフリート運用まで幅広いペルソナに対応できるかが問われる時流を反映したものとみられる。Google Cloudは今後、Agent Runtimeのガバナンス機能をGKEやCloud Runにも拡大するほか、Cloud Run instancesの正式提供やマルチクラウド対応の拡充を進める方針としている。

概要 AWSは2026年8月20日、米ネバダ州ラスベガスに新しいAWS Local Zone「us-west-2-las-2a」の一般提供を開始したと発表した。米国西部(オレゴン)リージョンに属するこのLocal Zoneにより、ラスベガス都市圏のユーザーは主要なAWSサービスを1桁ミリ秒台の低遅延で利用できるようになる。AWS Local Zonesは、コアとなるAWSサービスをリージョンの外にある大都市圏に拡張し、地理的に近い場所でコンピュートやストレージを提供する仕組みで、今回の開設により世界で30以上の大都市圏にLocal Zoneが展開されたことになる。 対応サービスとアクセス方法 新設のLocal Zoneでは、コンピュートとしてC7i、M7i、R7i、C8gnの各EC2インスタンスタイプ、ストレージとしてgp3、gp2、io1、sc1、st1のEBSボリュームタイプが利用可能となっている。コンテナサービスとしてはECSとEKSに対応し、ネットワーク関連ではApplication Load BalancerおよびAWS Direct Connectも利用できる。ユーザーはAWS Management ConsoleのAWS Global ViewにあるRegionsタブから該当Local Zoneを有効化するか、ModifyAvailabilityZoneGroup APIを利用して有効化できる。 想定される用途と背景 AWSはLocal Zonesの狙いとして、レイテンシーに敏感なアプリケーションの高速化、データレジデンシー要件への対応、AI/ML推論ワークロードの近接処理、そしてレガシーアプリケーションのクラウド移行支援を挙げている。ラスベガスは大規模なイベント産業やエンターテインメント施設が集積する都市であり、こうした現地拠点でのリアルタイム性が求められる用途に対して、リージョンをまたぐ通信よりも低遅延なインフラを提供できる点が今回の開設の意義といえる。 今後の展望 AWSはLocal Zonesの展開を継続的に拡大しており、既存の30以上の大都市圏に加えて今後も対象地域が増えていくとみられる。企業が特定の都市圏でエッジに近い形でAWSサービスを利用したいというニーズに応える形で、Local Zonesはハイブリッドクラウドやエッジコンピューティング戦略の選択肢の一つとして位置づけられている。

概要 AWSは8月21日、フルマネージドのデータ統合サービス「AWS Glue」の新ランタイム「AWS Glue 6.0」を一般提供開始したと発表した。最大の目玉は料金体系の見直しで、従来バージョンと比較して30%の値下げを実施した。あわせて、データレイクフォーマットとして急速に採用が広がっているApache Iceberg v3の全機能をサポートし、データレイクの構築・運用コストを大幅に削減できるとしている。 技術的な詳細 AWS Glue 6.0は、Apache Spark 4.1、Python 3.13、Scala 2.13を採用したモダナイズ済みのランタイムを基盤としている。Iceberg v3対応の目玉機能として、セミ構造化データ向けの新しい「VARIANT型」とそのシュレッディング（分割格納）機能が挙げられ、従来の文字列型カラムと比較して高速なクエリ読み取り性能を実現するという。このほか、GIS分析向けの地理情報型、IoTセンサーや金融取引データに適したナノ秒精度のタイムスタンプ、スキーマの互換性のない型変更にも対応する仕組みが追加された。 Spark 4.1側の改善としては、パイプライン開発の複雑さを軽減する宣言的パイプライン機能や、シリアライゼーションのオーバーヘッドを削減するArrowネイティブのPython UDFが搭載されている。またリアルタイムストリーミング処理では1桁ミリ秒台のレイテンシを実現するとしており、低遅延が求められるユースケースへの対応力を高めている。 移行方法 既存のAWS Glueユーザーは、AWS Glue Studioコンソールやジョブ設定の--glue-versionパラメータを6.0に指定するだけで新ランタイムへ切り替えられる。自動アップグレード機能も用意されており、比較的スムーズな移行が可能だとしている。料金引き下げとIceberg v3対応が同時に行われたことで、既にIcebergベースのデータレイク運用を検討している企業にとっては、移行を後押しする材料になりそうだ。

概要 Kubernetesプロジェクトは8月20日、v1.36.4、v1.35.8、v1.34.11の3系列にわたるパッチリリースを公開した。当初予定されていたリリース日はGitHub側の障害により延期されており、今回はその影響を受けた分もまとめて反映された形となる。今回のリリースはDynamic Resource Allocation(DRA)スケジューリング、kubelet、Podのプリエンプション処理に関する複数の不具合修正に加え、Go関連ライブラリのセキュリティアップデートを含んでいる。 技術的な詳細 最新系列のv1.36.4では、DRAスケジューリングまわりで2件のバグが修正された。1つは、構造化アロケータがプール名のみをキーとして共有カウンターキャッシュを管理していたため、同名のプールを公開する複数のドライバーが互いのカウンター定義を誤って参照し、デバイス割り当てが不正に許可・拒否される可能性があった問題(PR #140504)。もう1つは、PrepareResourcesが部分的に失敗した際、再試行時にCRIランタイムへ重複したCDIデバイスIDが渡され、コンテナ起動エラーを引き起こす問題(PR #140955)である。 スケジューリング領域では、プリエンプター(退避を実行する側)のPodが競合状態によりスケジュール不可能な状態のまま固着してしまう不具合が解消されている(PR #140685)。この修正はv1.35.8にも同様に取り込まれている。このほか、client-goのFakeCustomStoreが新しいcache.Storeインターフェースのメソッドを実装し、互換性が復旧された(PR #141001)。 依存関係とセキュリティ更新 v1.36系ではgolang.org/x/crypto(v0.47.0→v0.53.0)、golang.org/x/net(v0.49.0→v0.56.0)、golang.org/x/text(v0.33.0→v0.39.0)といったGo関連ライブラリがセキュリティアップデートとして更新された(PR #141226)。v1.35.8とv1.34.11についても、Go 1.26でのビルドへの切り替えとあわせて同様のx/crypto・x/net・x/text系ライブラリの更新が反映されており、いずれも機能追加よりも安定性とセキュリティ強化を優先した保守的なリリースとなっている。 今後の対応 DRAスケジューリングやプリエンプションの競合状態といった問題は、大規模クラスタや多数のカスタムリソースドライバーを運用する環境で顕在化しやすい種類の不具合であり、該当する3系列(v1.36、v1.35、v1.34)を利用しているユーザーは早めのアップグレードが推奨される。詳細な変更点はKubernetes公式リポジトリのCHANGELOGで確認できる。

概要 Snowflakeは8月18日、AIワークロードの統合管理基盤である「Cortex AI Gateway」に動的モデルルーティング機能を追加すると発表した。この機能は、タスクの複雑さや求められる品質・速度・コストのバランスに応じて、軽量な低コストモデルとフロンティア級の高性能モデルを自動的に使い分けるもので、Snowflake CoCoやSnowflake CoWorkに加え、サードパーティ製のAIエージェントでも横断的に利用できる。企業側でアプリケーションを作り直すことなく、モデルの性能や価格が変動してもルーティングが自動的に追従する点が特徴だ。 Snowflakeの社内評価では、単純なタスクをより安価なモデルに振り分けることで、dbtパイプライン構築において品質を維持したまま最大3倍のトークン効率の改善が確認されたという。さらに、エンジニアリングチームの実装作業全体でもトークン効率が25%向上したと報告されている。 新規オープンソースモデルの統合 Snowflakeは動的ルーティングの選択肢を広げる一環として、オープンソースモデルの「DeepSeek-V4-Flash 0731」と「GLM-5.3」を段階的にプライベートプレビューとして追加する計画も明らかにした。同社の評価によれば、DeepSeek V4 Flashはデータエンジニアリングタスクで74.4%のスコアを記録し、主要な商用モデルを上回る結果を示したという。 コスト管理とガバナンス Cortex AI Gatewayには、トークン使用量やコストを可視化する機能に加え、チームやエージェント単位での支出上限設定、ユーザーごとの利用クォータ設定、予算消費が上限に近づいた際のアラート通知といったガバナンス機能が備わっている。これにより、企業は複数モデルを横断的に利用しながらも、AI関連コストの予測可能性とコントロールを確保できる。 背景と業界の反応 Snowflakeは今回の発表に合わせて「インテリジェンス効率」という新しい指標を打ち出した。これは、コンピュートリソース、モデル、データ、コンテキストをどれだけ効率的にビジネス価値へと転換できるかを測る考え方だという。企業のAI活用が広がるにつれ、あらゆるタスクに同一の高性能モデルを使い続けるとコストが膨らむ一方、複数モデルを個別に管理することは開発チームの運用負荷を増大させるというジレンマが浮かび上がっており、動的ルーティングはこの両立を狙った取り組みと位置付けられる。 Snowflake CEOのSridhar Ramaswamy氏は「企業はAIの経済性をより厳密に評価するようになっており、問題はもはやAIをどれだけ使うかではなく、それが具体的なビジネス価値を生んでいるかどうかだ」と述べ、タスクごとに最適なモデルを選べる柔軟性の重要性を強調した。また、業界アナリストでSanjMo創設者のSanjeev Mohan氏は、企業が直面する本質的な課題は大規模環境でタスクごとに適切なモデルを選択する運用負荷にあると指摘し、こうした自動化がエンタープライズでの展開加速につながると評価している。

概要 セキュリティ企業Truffle Securityの調査により、2022年8月から2026年にかけてコードリポジトリやGit履歴、Dockerイメージ、CIログなどに公開状態で流出したAWSアクセスキーのうち、9,300件以上が今なお有効であることが判明した。調査ではコード上に露出した43万1,875件のAWSシークレットを分析し、重複を排除した結果、5万654個のAWSアカウントにひもづく6万4,024件のユニークなキーを抽出。検証可能だった1万616件のうち88%（2026年8月10日時点）が認証を通過し、依然として悪用可能な状態にあった。 企業に紐づくキーは817件確認され、うち526件はAWSにおいて最も強い権限を持つルートキーだった。さらに242件はIAMユーザーに付与されたAdministratorAccessポリシーを保持しており、攻撃者がこれらを悪用すれば企業のAWSアカウントを完全に乗っ取ることが可能な状態にある。 技術的な詳細 流出元として最大だったのはAI開発プラットフォームのHugging Faceで、8,482件のユニークな露出がここから発生していた。Hugging Face経由で流出したキーのうち17.9%はルートキーであり、他のソースと比べて特に危険度が高い。 流出したキーの深刻さを裏付けるのが、その「放置期間」の長さだ。流出から発見までの期間の中央値は1,831日、およそ5年に及び、最も古いものは17.4年間も公開状態のまま有効であり続けていた。ローテーション（キーの再発行・無効化）が行われた形跡が確認できたのはわずか13.7%にとどまり、多くの組織で認証情報の管理体制が長期にわたり機能していなかったことがうかがえる。また、読み取り可能だった2,754アカウントのうち予算アラートが設定されていたのは262件のみで、不正利用による異常な課金を検知する仕組みも十分に整っていなかった。 想定される影響と対応 管理者権限を持つキーが悪用された場合、攻撃者はデータの窃取、稼働中のサーバーやアプリケーションの乗っ取り、暗号資産マイニングツールの展開、さらには永続的なアクセス確保のための不正な管理者アカウント作成まで行える。AWSはBleepingComputerの取材に対し、「露出したキーを認識した際は常に顧客に通知し、徹底的な調査を行った上で隔離ポリシーを適用している」とコメントしている。 セキュリティ専門家は、ルートアクセスキーの使用を廃止し、IAM認証情報を定期的に監査すること、露出が疑われるキーは速やかにローテーションすること、そして予算アラートなど異常検知の仕組みを整備することを推奨している。今回の調査結果は、パブリックリポジトリや第三者プラットフォームへの認証情報の混入がいかに長期間見過ごされうるかを浮き彫りにしており、開発現場でのシークレット管理の徹底が改めて求められている。