Cloud

概要 調査会社Omdiaは2026年3月、2025年第4四半期（10〜12月）のグローバルクラウドインフラ支出に関するレポートを発表した。支出総額は前年同期比29%増の1,109億ドルに達し、2024年Q3から数えて6四半期連続で20%超の成長率を維持している。2026年通年でも27%の成長が予測されており、クラウド市場の拡大基調は当面続く見通しだ。この成長を主導しているのは、AWS・Microsoft Azure・Google Cloudのいわゆる「ハイパースケーラー3社」によるAIインフラへの積極的な設備投資である。 各社の業績と市場シェア Q4 2025時点での市場シェアは、AWSが32%でトップを維持し前年比24%成長、Microsoft Azureが22%で同39%成長、Google Cloudが12%で同50%成長となった。特にGoogle Cloudの成長率は3社の中で最も高く、バックログ（受注残）も前四半期比で大幅に積み上がり2,400億ドルに達している。AWSのバックログも2,440億ドルと高水準で推移しており、いずれも今後の安定的な収益基盤を示している。 AI関連サービスでも各社の拡大が際立つ。AWSではAmazon Bedrockが数十億ドルの年換算実行率に達し、前四半期比60%増という急成長を遂げた。MicrosoftはMistral Large 3やGPT-5.2、Claude Opus 4.6など多数のモデルをプラットフォームに統合し、AI活用の幅を広げている。GoogleはAppleとの提携により次世代基盤モデルの開発を進めるなど、3社それぞれが独自のAI戦略を加速させている。 AI需要が変える設備投資の規模感 各社が公表している2026年の設備投資（CapEx）計画は、いずれも過去最大規模となっている。AWSは2025年の1,320億ドルから50%以上増加となる2,000億ドルを予定しており、Microsoftは四半期CapExが375億ドルに達した（前年同期比150億ドル増）。Googleは年間1,750〜1,850億ドルを計画しており、前年比でほぼ2倍の規模となる。 注目すべきは、この投資がGPUに偏っていた従来とは異なり、CPU・ストレージ・ネットワーク機器を含むフルスタックのインフラ全体へと波及している点だ。AIワークロードの多様化・本格化に伴い、特定のアクセラレータだけでなくデータセンター全体の刷新が求められるようになっている。 今後の展望と課題 Omdiaのシニアディレクター、Rachel Brindley氏は「ベンダーの課題は単なる容量スケーリングにとどまらず、投資ペースとリソース配分における規律あるアプローチが求められる」と指摘する。同社シニアアナリストのYi Zhang氏も「AIをスケールで実用的に統合できるかどうかが重要であり、ツールのガバナンスとワークフロー編成への投資強化が不可欠だ」と述べ、エンタープライズAIが実験フェーズから本番運用フェーズへと移行しつつある現状を強調している。 競争の差別化軸は「インフラスケール」「資本効率」「AIエージェント機能」へとシフトしており、特にエージェント開発とワークフロー統合が今後の主要な競争領域となる見通しだ。Microsoftはサウジアラビア東部に新たなデータセンターを2026年Q4に開設予定であるなど、地理的な拡張も加速している。

概要 第3回FabConと初開催のSQLConがアトランタ（ジョージア州）で合同開催され、約8,000名が参加した。Microsoftはこの場で「SQL Serverは置き換えられるのではなく、格上げされる」というメッセージを軸に、SQL Server・Azure SQL・Microsoft FabricをAI対応の統一データプラットフォームへ収斂させる方針を明確に打ち出した。FabricはGA（一般提供開始）から約2年半で31,000社以上に採用されており、Microsoftのデータプラットフォーム史上最速の成長を記録している。SQL Server 2025の採用速度も前バージョンの2倍に達しているという。 新機能の詳細 今回の発表で中心的な位置を占めるのがDatabase Hub in Fabric（アーリーアクセス）だ。Azure SQL、Azure Cosmos DB、Azure Database for PostgreSQL、SQL Server（Azure Arc経由）、Azure Database for MySQL、Fabric databasesなど、エッジ・PaaS・Fabric全体のデータベースを一元管理するUXを提供する。探索・監視・ガバナンス・最適化をひとつの画面から実行できる。 OneLakeセキュリティは数週間以内のGA（一般提供）が予告された。行・列レベルのアクセス制御と統合権限モデルを備え、Sparkノートブックや Power BIレポート、Fabric data agentなど全アナリティクス経験を横断して権限を自動適用する。ショートカット・ミラーリング機能によりAWS、Google Cloud、Oracle、オンプレミス、SAP、Snowflake、Azure Databricksへのゼロコピー・ゼロETL接続も可能になる。 分析データと運用データ（テレメトリ・時系列・グラフ・地理空間データ）を統合するセマンティックフレームワークFabric IQも注目の発表だ。テーブルやスキーマではなくビジネスエンティティ・関係・プロパティ・ルール・アクションのオントロジーで操作でき、近日中にMCPサーバー（プレビュー）として公開予定。AIエージェントがセマンティックレイヤーを発見・理解・操作できるようになる。 AIエージェント連携とMCP対応 Fabric MCP（Model Context Protocol）では2種類のサーバーが用意された。Fabric local MCPはすでにGAしており、GitHub CopilotなどAIコーディングアシスタントをFabricに直接接続するOSSローカルサーバーとして提供される。既存のRBACに準拠しながら権限管理やワークスペース作成、定義の活用が可能だ。一方のFabric remote MCPはパブリックプレビューで、AIエージェントや自動化ツールがFabric内で認証済みアクションを実行できるセキュアなクラウドホスト実行エンジンを提供する。 Power BI: Translytical Task FlowsがGAとなり、レポートから直接ワークフローをトリガーしてデータ課題を解決できるようになった。手動でのリクエスト提出が不要になり、分析と運用の融合を体現する機能として位置づけられている。また、Azure Data Factory・Synapse Analytics・Azure SQL向けの移行アシスタント（パブリックプレビュー）も発表され、AI支援の互換性チェックによりパイプライン・ノートブック・DBスキーマをFabricへ移行できるようになった。 今後の展望 OneLakeセキュリティのGAや Fabric IQ MCPサーバーのプレビュー公開が直近の予定として示されており、データプラットフォームとAIエージェントの統合はさらに加速する見通しだ。次回のFabCon/SQLConはヨーロッパ大会として2026年9月28日〜10月1日にスペイン・バルセロナで開催される予定。

概要 Google Cloudは2026年上半期版「Threat Horizons」レポートを公開し、クラウドセキュリティの脅威動向における重大な変化を報告した。2021年のレポートシリーズ開始以来初めて、サードパーティソフトウェアの脆弱性がクラウド侵害の最大の初期侵入経路となった。2025年下半期のインシデントでは、ソフトウェアの脆弱性に起因するものが**44.5%**に達し、脆弱または未設定の認証情報（27.2%）を大きく上回った。これは2025年上半期に同指標が2.9%だったことと比較すると、わずか半年で劇的な変化が起きたことを示している。 主要な脅威動向 今回のレポートで特に注目されるのは、脆弱性の悪用スピードの加速だ。2025年下半期には、脆弱性の公開から実際の攻撃に悪用されるまでの時間が、従来の「数週間」から「数日」に短縮されている。組織がパッチを適用する前に攻撃が始まる状況が常態化しており、人手による対応の限界が浮き彫りになっている。 また、全インシデントの83%にアイデンティティの侵害が関与していることも判明した。攻撃者はランサムウェアや恐喝の一環としてクラウドリソースを意図的に破壊し、被害者が独立して復旧できないよう妨害する手法を採用している。さらに、国家支援型グループを含む主要なランサムウェアグループのほぼすべてが、ログ、コアダンプ、スナップショットなどのフォレンジック証跡を削除するなど、フォレンジック機能への干渉を行っていることも報告されている。北朝鮮系の脅威アクターによるKubernetesの特権コンテナを悪用した暗号資産窃取キャンペーンも確認されている。 推奨対策と今後の展望 Google Cloudは本レポートで、こうした脅威に対応するために組織がより自動化された防御へ移行することを強く推奨している。具体的には、CIEM（クラウドインフラストラクチャ権限管理）やWorkload Identity Federationを活用した非人間アイデンティティの自動ガバナンスへのシフトが求められる。人間中心の認証管理から脱却し、機械的・自動的なアイデンティティ管理が今後の重要課題となる。 AIを活用した標的プロービングの増加も確認されており、攻撃者側のAI活用が進む中、防御側も多層防御戦略（アイデンティティセキュリティの強化、堅牢なリカバリ機構、ソーシャルエンジニアリング対策、サプライチェーンの完全性確保）を組み合わせた体系的な対応が不可欠だ。ソフトウェアサプライチェーンへの攻撃が主要な侵入経路となった現在、パッチ管理の自動化と脆弱性の早期検知がクラウドセキュリティの最前線課題となっている。

概要 HashiCorpは2026年3月31日、HCP Terraformのレガシー無料プラン（ユーザー数ベース）のサポートを終了し、残存していたすべての組織を新しいエンハンスド無料プランへ自動移行した。エンハンスド無料プランは2023年に導入されたもので、今回の移行によって旧来のプランへの切り戻しはできなくなる。すでにエンハンスド無料プランを利用中のユーザーへの影響はない。 移行対象の組織には製品内に「今すぐ新しい無料プランへ移行」というプロンプトが表示されており、移行フローでは管理リソース数の上限500件と現在の使用状況、および利用可能な機能の比較が確認できた。自分から移行しなかった場合も3月31日をもって自動的に新プランへ切り替わっている。 エンハンスド無料プランの内容 エンハンスド無料プランの主な特徴は次のとおりだ。 管理リソース500件まで無料（ユーザー数の制限なし） SSO（シングルサインオン）が無料で利用可能 Policy as Code（SentinelおよびOPA）が利用可能 Run Tasks・Run Task Enforcement が利用可能 HCP Terraform エージェントが利用可能 コスト見積もり機能が利用可能 「管理リソース」とはHCP Terraformが管理するステートファイル内のmode = "managed"なリソースを指し、初回のplan/apply実行時からカウントされる。null_resourceはカウントから除外される。 移行の背景と影響 HashiCorpが2023年にエンハンスド無料プランを導入した際の目的は、セキュリティのベストプラクティス（SSOやポリシー管理）をより早い段階から利用しやすくすることと、ユーザー数ではなくリソース数という実態に即した指標でプランを計測することにあった。今回の移行完了により、すべての無料ユーザーが統一された基準のもとで同等の機能を利用できるようになる。 500件の管理リソースを超えた場合は有料プランへのアップグレードが必要となるため、大規模な環境を運用している組織は自身のリソース数を確認しておくことが推奨される。

概要 オープンソースのKubernetesセキュリティプラットフォーム「Kubescape」がバージョン4.0に達し、一般提供（GA）を開始した。KubeCon + CloudNativeCon Europe 2026での発表に合わせたリリースで、ランタイム脅威検知エンジンとAIエージェント（KAgent）向けセキュリティスキャンが主要な新機能として加わった。コアメンテナーのBen Hirschberg氏は、ランタイム検知エンジンについて「大規模環境で厳密にテストされ、安定性が実証済みだ」と述べている。Kubescapeは2025年1月にCNCFサンドボックスからインキュベーティング層へ昇格しており、ARMO社がメンテナンスをリードしている。 ランタイム脅威検知とアーキテクチャの刷新 新しいランタイム検知エンジンはCommon Expression Language（CEL）ルールを使ってプロセス、Linuxケーパビリティ、システムコール、ネットワークイベント、ファイルアクティビティをリアルタイムで監視する。検知ルールはKubernetesのカスタムリソース定義（CRD）として管理され、アラートをAlertManager・SIEM・Syslog・Webhookにルーティングできる。また「Kubescape Storage」もGAとなり、セキュリティメタデータを標準のetcdインスタンスから分離してKubernetes Aggregated APIで保持する設計を採用し、大規模・高密度クラスターへの対応を強化した。 アーキテクチャ面では、従来の侵襲的なhost-sensor DaemonSetとhost-agentを廃止し、単一のnode-agentにその機能を統合した。Direct API接続への移行により安定性と監査性が向上している。 AIエージェントセキュリティへの対応 Kubescape 4.0の注目点は、急増するAIエージェントのインフラ管理への対応だ。KAgentネイティブプラグインを導入し、AIアシスタントがKubernetesのセキュリティポスチャ（脆弱性・RBAC設定・コンテナの振る舞いパターン）を直接クエリできるようにした。さらに、KAgentのCRDにおけるセキュリティ上重要な42の設定ポイントをカバーする15の新OPA Regoベースコントロールを追加した。空のセキュリティコンテキスト、NetworkPolicyの欠如、過剰な権限でのネームスペース監視といった脆弱性への対処が含まれる。開発チームは「AIエージェントの自律性が高まる中、高リスクなアクションを実行されないよう堅牢なセキュリティガードレールが不可欠だ」と強調している。 コンプライアンス対応 コンプライアンス面では、CISベンチマークのバージョン1.12（バニラKubernetes）とバージョン1.8（EKS/AKS）のサポートが追加された。既存のNSA-CISAおよびMITRE ATT&CKフレームワークへの対応と合わせ、企業が求めるセキュリティ標準への準拠をさらに充実させている。CVEノイズを95%以上削減できるとされており、セキュリティ運用の効率化に貢献する。

概要 Solo.ioは2026年3月25日、アムステルダムで開催されたKubeCon + CloudNativeCon Europe 2026において、Kubernetes上でAIエージェントを実行するオープンソースフレームワーク「kagent」のCNCF（Cloud Native Computing Foundation）サンドボックスプロジェクトへの寄贈を正式に発表した。あわせて、AnthropicのModel Context Protocol（MCP）に対応した新ツール「MCP Gateway」も披露された。kagentはリリースからわずか1週間でCNCFのランドスケープ登録に必要な300 GitHubスターを達成し、最速クラスで成長しているCNCFサンドボックスプロジェクトの一つとなっている。 kagentとMCP Gatewayの技術詳細 kagentは、AIエージェント・ツール・モデル設定をすべてKubernetes CRD（カスタムリソース定義）として管理するKubernetesネイティブなAIエージェントフレームワークである。Solo.ioがOSSとして公開してから100日間で100名以上のコントリビューター（85%以上が外部）と1,000以上のGitHubスターを獲得した。 MCP GatewayはAI開発で広く採用が進むMCPプロトコルに対応した新ツールで、複数のMCPツールサーバーを単一の安全なエンドポイントに集約（フェデレーション）する機能を持つ。Solo.io共同創業者兼CEOのIdit Levine氏はKubeCon基調講演でその意義を「すべてのツールサーバーを単一エンドポイントに統合できる」と説明した。MCP Gatewayはkgatewayとのタイトな統合が特徴で、上席OSS担当ディレクターのLin Sun氏は「kgatewayをMCP Gatewayプロキシのコントロールプレーンとして捉えることができる」と述べている。 Solo.ioのアジェンティックインフラ戦略 Solo.ioはkagentのCNCF寄贈と並行して、AIエージェントインフラ全体をカバーするOSSエコシステムを構築している。その主要な4つの柱は以下のとおりである。 kagent — KubernetesネイティブなAIエージェント構築・実行のためのCNCFサンドボックスプロジェクト agentgateway — MCPおよびA2A（Agent-to-Agent）プロトコルを完全サポートするLinux Foundation傘下のAIネイティブデータプレーン agentregistry — AIエージェント・MCPツール・エージェントスキルの一元的なCNCFレジストリ。KubeCon Europe 2026でCNCFへの寄贈が発表された agentevals — OpenTelemetryを活用してAIエージェントの動作を継続的に評価・スコアリングする新OSSプロジェクト CEO Levine氏は「評価（evaluation）はアジェンティックインフラにおける最大の未解決問題だ」と述べ、agentevalsがプロダクション環境での信頼性確保を担う重要な位置づけにあることを強調した。 今後の展望 kagentはCNCFサンドボックスでインキュベーション申請が進行中であり、最新のCNCFテクノロジーレーダーのアジェンティックAI部門でも取り上げられている。agentregistryはKubernetes、AWS AgentCore、Google Vertex AIとの統合や、未統制のエージェントを検出するランタイムディスカバリ機能を備え、エンタープライズ規模でのAIガバナンスの基盤となることが期待される。KubeCon Europe 2026では「Agentics Day: MCP + Agents Hosted by CNCF」と題したハーフデイイベントも開催されるなど、KubernetesとAIエージェントの融合は急速に進んでいる。

概要 CoreWeave（Nasdaq: CRWV）は2026年1月、NVIDIA Rubinテクノロジーをクラウドプラットフォームへ統合すると発表した。同社は2026年下半期にNVIDIA Rubinプラットフォームを最初に展開するクラウドプロバイダーの一つとなる予定で、エージェント型AI・大規模推論・大規模インファレンスワークロードの構築・デプロイを支援する。CoreWeaveのCEO Michael Intrator氏は「エンタープライズ顧客は本物の選択肢と、複雑なワークロードを本番スケールで確実に実行できる能力を求めてCoreWeaveを選ぶ」とコメントしており、NVIDIA Rubinプラットフォームはその戦略をさらに強化するものと位置付けている。NVIDIA CEOのJensen Huang氏も「CoreWeaveのスピード、スケール、そして独創性はこの新時代のコンピューティングにおいて不可欠なパートナーだ」と述べている。 NVIDIA Rubinプラットフォームの技術仕様 NVIDIA Rubinプラットフォームは6種類のチップを極限まで協調設計（コデザイン）することで、AIシステムの構築・デプロイ・セキュリティ確保の新たな基準を打ち立てる。構成要素は以下の通りだ。 NVIDIA Vera CPU：88個のカスタムOlympusコア（Armv9.2互換）を搭載 NVIDIA Rubin GPU：第3世代Transformer Engineを搭載し、NVFP4で50ペタフロップスの計算性能を発揮 NVIDIA NVLink 6 Switch：GPU1基あたり3.6TB/sの帯域幅を実現するGPU間通信スイッチ NVIDIA ConnectX-9 SuperNIC：高速ネットワークインターフェース NVIDIA BlueField-4 DPU：AIネイティブなストレージ処理 NVIDIA Spectrum-6 Ethernet Switch：大規模クラスタ向けイーサネットスイッチング 旗艦ラック構成「Vera Rubin NVL72」にはRubin GPUを72基、Vera CPUを36基搭載し、合計260TB/sのトータル帯域幅を誇る。前世代のBlackwellプラットフォームと比較して、推論トークンコストを最大10分の1に削減し、混合専門家（MoE）モデルの学習に必要なGPU数を4分の1に抑えることができるとされている。 CoreWeaveの独自技術と展開戦略 CoreWeaveは単にNVIDIA Rubinを採用するだけでなく、自社開発の技術でその運用基盤を強化している。同社が構築したRack Lifecycle Controllerは、NVIDIA Vera Rubin NVL72ラック全体を単一のプログラマブルエンティティとして扱うKubernetesネイティブのオーケストレーターだ。電力供給、液体冷却、ネットワーク統合の緊密な要件を調整し、顧客のワークロードを投入する前にハードウェアの本番稼働準備を確実にする。 また、Rubinベースのシステムは業界初のAIワークロード向けオペレーティング標準であるCoreWeave Mission Controlと連携して展開される。これはトレーニング・インファレンス・エージェント型AIワークロードをセキュリティ、オペレーション、可観測性を統合して管理するものだ。CoreWeaveは既にGB200 NVL72やGrace Blackwell Ultra NVL72の一般提供を最初に実現した実績を持ち、SemiAnalysisのClusterMAX™ プラチナ評価を2度獲得している。 業界全体での展開動向と今後の展望 NVIDIA Rubinプラットフォームへの対応は、CoreWeaveだけにとどまらない。AWS、Google Cloud、Microsoft、OCIといった主要クラウドプロバイダーに加え、NVIDIA Cloud Partnersであるλambda、Nebius、Nscaleも2026年下半期にVera Rubinベースのインスタンスをいつしかのパートナーとともに提供予定だ。AI研究機関側でも、Anthropic、Meta、OpenAI、Mistral AI、xAIなど多数の企業がRubinプラットフォームへの期待を表明している。 CoreWeaveはNasdaq上場（2025年3月）後も、NVIDIAの最新プラットフォームへの早期アクセスを競争上の差別化要因として活用し続けている。薬物探索・ゲノム研究・気候シミュレーション・核融合エネルギーモデリングといった高負荷科学計算からエンタープライズAIまで幅広いユースケースをカバーするNVIDIA Rubinの採用を通じて、同社は専業AIクラウドとしての地位をさらに強固にしようとしている。

概要 Kubernetes v1.36のスナップショット（Sneak Peek）記事が2026年3月30日に公式ブログで公開された。正式リリースは2026年4月22日を予定しており、セキュリティ強化を軸に複数の重要な変更が加えられる。主な変更点は、長年の脆弱性対応としてspec.externalIPsフィールドの非推奨化、セキュリティリスクのあったgitRepoボリュームドライバーの完全削除、SELinuxラベリング改善のGA（一般提供）対応、そしてHPAのScale-to-Zeroのデフォルト有効化などだ。 セキュリティ関連の変更 spec.externalIPsの非推奨化は、CVE-2020-8554への対応として実施される。この脆弱性はServiceのexternalIPsフィールドを悪用することで中間者攻撃が可能になるもので、v1.36で非推奨となりv1.43での削除が計画されている。代替手段としてはLoadBalancer Service、NodePort Service、またはGateway APIへの移行が推奨されている。 gitRepoボリュームドライバーの削除も同リリースで実施される。このドライバーはv1.11から非推奨だったが、ノード上でroot権限によるコード実行を可能にするセキュリティ上の欠陥があったため、v1.36でついに完全削除される。代替手段としてはinitコンテナや外部のgit-syncツールの利用が推奨されている。 また、Ingress NGINXプロジェクトのリタイアが2026年3月24日に発表された。セキュリティバグ修正と新リリースが停止され、既存のデプロイメントは引き続き動作するものの、Gateway APIへの移行が強く推奨されている。 kube-proxyのIPVSモードもv1.35で非推奨となっており、v1.36で削除される。移行先としてはnftablesバックエンドのiptables、またはCiliumなどのeBPFベースのソリューションが選択肢となる。 新機能・改善 SELinuxボリュームラベリングの改善がGA（一般提供）に昇格する。従来は再帰的なファイルリラベリングが行われておりPodの起動遅延を招いていたが、mount -o context=XYZオプションを用いた新方式によりこの問題が解消される。v1.28のReadWriteOncePod向けベータ実装から始まり、v1.32のメトリクス追加を経て、v1.36では全ボリューム対応・デフォルト有効化としてGAに到達する。 HPA（Horizontal Pod Autoscaler）のScale-to-Zero機能がデフォルト有効となる。v1.16からアルファとして提供されていたHPAScaleToZeroフィーチャーゲートが有効化され、トラフィックがゼロになった際にPodを完全にスケールダウンし、需要が復帰した際に自動でスケールアップできるようになる。ステージング環境やバッチ処理、コスト最適化の観点で特に有用な機能だ。 イメージプルへのエフェメラルサービスアカウントトークンの採用（KEP-2535）も注目の変更点だ。これまでの長期有効なシークレットに代わり、Podのアイデンティティにスコープされた短命かつ自動ローテーションされるトークンを使用するようになる。v1.33でアルファ、v1.34でベータを経てv1.36で本番対応となる予定だ。 新しいアルファ機能として、HPAのPod選択の精緻化も導入される。メトリクス収集において、対象ワークロードが直接管理するPodのみを収集対象とすることで、孤立したPodによるスケーリングエラーを防止できるようになる。 今後の展望 containerd 1.6.x系のサポートについては、v1.36が古いバージョンをサポートする最後のリリースとなるため、該当ユーザーはcontainerd 2.x系へのアップグレードを検討する必要がある。リリーススケジュールは機能強化フリーズが2月11日に完了し、コード凍結が3月18日、ドキュメント凍結が4月8日、そして正式リリースが4月22日となっている。セキュリティを重視した今回の変更群は、長年先送りにされてきた脆弱性対応を一気に前進させるものであり、クラスター管理者には早期の影響評価と移行計画の策定が求められる。

概要 AWSは、Amazon Route 53 Global Resolverの一般提供（GA）を開始した。本サービスは2025年のre:Inventで11リージョンでのプレビューとして発表されていたもので、今回30のAWSリージョンに拡大して正式リリースとなった。Route 53 Global Resolverは、インターネット経由でアクセス可能なマネージドエニーキャストDNSリゾルバサービスであり、オンプレミスのデータセンター、ブランチオフィス、リモートクライアントなど、あらゆる場所からのDNSトラフィックのルーティングとセキュリティを簡素化する。パブリックインターネットドメインとRoute 53プライベートホストゾーンの両方の名前解決に対応しており、ハイブリッドクラウド環境におけるスプリットDNS構成を大幅に簡素化できる。 暗号化DNSとセキュリティ機能 Route 53 Global Resolverの大きな特徴は、DNS over HTTPS（DoH）およびDNS over TLS（DoT）による暗号化DNS通信のサポートである。これにより、DNSクエリが平文で送信されることを防ぎ、通信の盗聴やDNSスプーフィングのリスクを低減する。認証方式としては、DoH/DoT向けのトークンベース認証（有効期限や失効の設定が可能）と、Do53/DoT/DoH向けのIP/CIDRベースのACLによるアクセス制御の2つが用意されている。 セキュリティ面では、悪意のあるドメインへのDNSクエリをブロックするDNSフィルタリング機能を内蔵しており、DNSトンネリングやドメイン生成アルゴリズム（DGA）、辞書DGAに関連するドメインへのアクセスもブロックできる。さらに、CloudWatch、S3、Data Firehoseへの集中クエリログ出力に対応し、コンプライアンス要件への対応やセキュリティ監視を容易にする。 運用上の利点と今後の展望 Route 53 Global Resolverの導入により、企業はカスタムDNSフォワーダの構築・運用が不要になり、運用負荷を大幅に削減できる。複数リージョンへのデプロイにより、レイテンシの最適化とフェイルオーバーも実現される。VPNや企業ネットワークとの互換性も備えており、既存のネットワーク構成への統合が容易である。新規利用者には30日間の無料トライアルが提供されており、導入前の検証が可能となっている。IPv4およびIPv6の両方のDNSクエリトラフィックに対応している点も、モダンなネットワーク環境への適応を示している。

概要 Datadogは2026年3月20日、Terraformプロバイダーのメジャーバージョンアップとなるv4.0.0をリリースした。今回のリリースでは、モニターのアクセス制御における予測可能性の向上、AWS統合リソースの一本化、認証情報のセキュリティ強化、そしてTerraformプロトコルv6への移行という4つの主要な改善が盛り込まれている。Terraform CLI 1.1.5以降が必須となる破壊的変更を含むメジャーアップデートだが、段階的な移行パスが用意されており、v3を利用中のチームはレガシーリソースを引き続き利用しながら準備が整った段階でアップグレードできる。 モニターアクセス制御の改善 v4.0.0では、モニターのrestricted_rolesフィールドがデフォルトで「スティッキー」な動作に変更された。これにより、Terraform構成からフィールドを省略しても既存のロール制限が意図せず削除されることがなくなり、制限を完全に解除するには明示的に空配列[]を設定する必要がある。従来のv3では構成の省略がアクセス制限のリセットを引き起こす可能性があり、予期しない権限変更のリスクがあった。なお、非推奨だったlockedフィールドは完全に削除され、今後はrestriction_policyの利用が推奨される。ただし、restricted_rolesとrestriction_policyの併用は機能的な競合を引き起こすため注意が必要だ。 AWS統合リソースの統合 これまで4つの個別リソースに分散していたAWS統合の管理が、新しいdatadog_integration_aws_accountリソースに一本化された。この統合リソースでは、従来の機能に加えてログのタグフィルタリング、X-Rayトレーシング、EC2オートミュート制御、AWSパーティションサポートといった新機能が利用可能になっている。v4にアップグレードするチームは統合リソースへの移行が必要だが、移行ドキュメントがTerraform Registryで提供されている。なお、基盤となるv1 APIは引き続き稼働しており、後方互換性も維持されている。 セキュリティ強化と技術基盤の刷新 認証情報のセキュリティ面では、datadog_application_keyデータソースの削除と既存アプリケーションキーのインポート機能の廃止が行われた。これにより認証情報の露出経路が削減され、ワンタイムリード方式のアプリケーションキーとの互換性が確保された。Terraformで作成・管理している既存のキーはアップグレード後も引き続き機能する。技術基盤としては、Terraform Plugin SDK v2からプラグインフレームワークへの移行が実施され、Terraformプロトコルv6が採用された。これにより、将来的にネストされた属性のサポートなど、スキーマの改善が可能になる見通しだ。