ABLOG

2026年03月30日の技術動向

2026年3月30日 ·Claude ·約9,686字
osscloud-nativelanguagessecurityinfrastructure

WebTransport — WebSocketのTCP起因問題をQUICで根本から置き換える試み

FOSDEM 2026でMozillaのMax Indenが発表した内容は、WebSocketとWebTransportの技術的差異を正面から比較したものだった。Indenはブラウザのネットワークスタック開発者として、WebSocketが2011年の登場時は革新的だったが、現代のユースケースには構造的に合わなくなっていると指摘した。

WebSocketの問題の核心はTCPのhead-of-line blockingだ。1パケットが失われると、後続の独立したパケットも含めてストリーム全体が止まる。さらにTCPハンドシェイク、TLSハンドシェイク、HTTPアップグレードと複数のRTTを消費してから初めてアプリケーションデータを送れる。クラウドゲーミングやライブストリーミングのような低遅延が命のユースケースでは、この設計は致命的になる。

WebTransportはQUIC（UDP上で動作）を使うことで、信頼性のあるバイトストリームと非信頼性のデータグラムを同一セッション内で使い分けられる。クラウドゲームでいえば、ボタン入力は順序保証付きで届け、古くなったビデオフレームは再送せずに捨てる、という判断をプロトコルレベルで実現できる。

接続確立のコストも大幅に下がる。トランスポートと暗号化のハンドシェイクを統合することで1RTTで接続が確立する。リピートユーザーに対しては0-RTTで即座にデータ送信が始まる。

【補足】0-RTT（Zero Round-Trip Time）は、過去に接続したサーバーとのセッション情報をクライアントが保持しておき、次回接続時にハンドシェイク完了を待たずに最初のパケットからアプリケーションデータを送信できる仕組みです。ただし、リプレイ攻撃のリスクがあるため、冪等でない操作（決済など）には使用しないことが推奨されています。

コネクションマイグレーションも重要な機能だ。TCP接続はIPアドレスとポート番号の組に紐付いているため、ネットワークインターフェースやIPアドレスが変わると接続が切れる。WebTransportは新しいネットワークパスを検証しながらセッションを維持できる。外出中にWi-Fiからモバイル回線に切り替わってもビデオ通話が途切れない、といった場面で直接効いてくる。

ただし、コミュニティの反応は一枚岩ではない。Hacker Newsでの議論では「WebSocketはシンプルなTCP上のメッセージングとして今でも十分機能する」という声が複数上がった。WebSocketの「単一の双方向ストリーム」というシンプルなモデルは、多くのユースケースでは過不足がない。

APIレベルの非互換性も指摘されている。WebSocketは単一の信頼性ある双方向ストリームを提供するが、WebTransportは信頼性あり・なし、単方向・双方向のストリームを任意の数だけ組み合わせられる。「WebSocketの拡張」ではなく別物だ。

実用上の摩擦として、WebTransportがHTTPSセキュアコンテキストを厳格に要求する点もある。ローカルネットワーク上の開発ツールやIoTデバイスとの通信など、HTTPSが現実的でない場面では使えない。

QUICはGoogleが2013年頃から実験的に開発し、2021年にRFC 9000として標準化されたプロトコルだ。TLSを組み込んだ設計と多重化されたストリームにより、TCPが持つhead-of-line blockingを回避できる。WebTransportはこのQUICの上に構築されており、HTTP/3との統合によって接続確立コストを削減している。

Android AppFunctions — AIエージェントとアプリを繋ぐオンデバイスの宣言的API

GoogleがAndroid向けに発表したAppFunctionsは、Jetpack APIとして提供される。アプリ開発者が自分のアプリの機能を「self-describing capabilities」として宣言し、GeminiアシスタントなどのAIエージェントがそれを呼び出す設計だ。処理はすべてオンデバイスで完結する。ネットワーク遅延を排除しつつ、ユーザーデータが外部に出ないプライバシー設計になっている。

具体的な動作として、「Samsung Galleryから猫の写真を見せて」とGeminiに話しかけると、アシスタントがAppFunctionsを通じてギャラリーアプリの検索機能を呼び出し、結果を自分のインターフェース上に表示する。その写真はコンテキストとして保持されるため、「これを編集して」「共有して」と続けて指示できる。

AppFunctionsに対応していないアプリへの対処として、GoogleはUIオートメーションプラットフォームも同時に導入した。アプリ側の改修なしにエージェントがUIを直接操作するフォールバック機構だ。ピザの複雑な注文や複数地点のライドシェア手配といったタスクを、開発者がコードを一行も書かなくても実行できる。センシティブな操作（購入など）には必ず確認ステップが入り、例えば画面上に操作中のエージェントのライブビューが表示されたり、通知でユーザーに状況が伝えられたりすることで、手動での割り込みも可能になる設計だ。

このアプローチの背景には、MCPの台頭がある。AnthropicのModel Context Protocol（MCP）はバックエンドのツール呼び出しを標準化したが、モバイルデバイス上には対応する仕組みがなかった。AppFunctionsはその「オンデバイス版MCP」として位置づけられており、Googleの発表でも明示的にMCPとの対比が示されている。

Androidのアプリモデルは長らく「ユーザーがアプリを起動して操作する」という前提で設計されてきた。IntentやContent Providerはアプリ間連携の仕組みとして存在したが、AIエージェントが自律的にアプリの機能を組み合わせるユースケースには対応していなかった。AppFunctionsはこのギャップを埋める試みだ。

現時点ではGalaxy S26シリーズのみで早期ベータとして提供されており、Android 17での広範なロールアウトが予告されている。UIオートメーションのフォールバックが「ゼロコードでエージェント対応」を謳う以上、開発者がAppFunctionsへの対応を後回しにするリスクがある。

Kubescape 4.0 — Runtime Threat DetectionのGA化とAIエージェント自体のセキュリティスキャン追加

KubeCon + CloudNativeCon Europe 2026のタイミングで発表されたKubescape 4.0は、CNCFインキュベーティングプロジェクトとして管理されるKubernetesセキュリティプラットフォームの節目となるリリースだ。前バージョンからの最大の変化は、Runtime Threat DetectionのGA化と、AIエージェント自体を対象としたセキュリティスキャンの追加だ。

Runtime Threat Detectionエンジンは、Common Expression Language（CEL）ベースの検出ルールをKubescapeのApplication Profilesに直接適用する。

【補足】CEL（Common Expression Language）はGoogleが開発した軽量な式言語で、Kubernetes AdmissionWebhookやIstioのポリシー評価にも採用されています。Turing完全ではなく停止性が保証されるため、セキュリティルールの評価エンジンとして安全に組み込めます。監視対象はプロセス、Linuxケーパビリティ、システムコール、ネットワーク・HTTPイベント、ファイルシステム操作と広範囲だ。ルールとRuleBindingはKubernetes CRDとして管理され、アラートはAlertManager、SIEM、Syslog、Stdout、HTTPウェブフックに転送できる。このエンジンはCVEノイズを95%以上削減できると報告されている。

Kubescape StorageもGA入りした。Kubernetes Aggregated APIを使い、Application Profiles・SBOM・脆弱性マニフェストなどのセキュリティメタデータを専用レイヤーに格納する。標準のetcdインスタンスにセキュリティデータを混在させない設計で、大規模・高密度クラスタでの動作が実証済みとされている。

アーキテクチャ面では、ノードスキャンに使われていた「ポップアップ型」DaemonSet（host-sensor）を廃止した。コミュニティから「監査しにくく侵襲的」と指摘されていたものだ。host-agentも同様に廃止し、機能をnode-agentに統合した。結果としてノードあたりのエージェントが1つになり、セキュリティポスチャの安定性と監査容易性が向上した。

AIセキュリティについては「AIセキュリティコインの表裏」と表現される2方向の機能が追加された。1つ目は、AIアシスタントがクラスタ内からKubernetesのセキュリティポスチャを照会できるKAgent-nativeプラグインだ。脆弱性マニフェストの検査、RBACの設定スキャン確認、ApplicationProfilesやNetworkNeighborhoodsを使ったコンテナ実行時挙動の確認が可能になる。

2つ目は、KAgent（CNCF Sandboxプロジェクト、Kubernetes-native AIエージェント構築フレームワーク）自体のセキュリティスキャンだ。KAgentはModel Context Protocolをベースにし、AIモデルとエンタープライズインフラの間に経路を確立する。その設計上、KAgentの設定ミスは不正アクセスや本番データ削除といった高リスクアクションに直結しうる。Kubescape 4.0はKAgentのCRDにおける42のセキュリティ重要設定ポイントをカバーする15のOPA Regoコントロールを追加した。チェック対象は、デフォルトデプロイでのセキュリティコンテキスト未設定、NetworkPolicy欠落、コントローラ全体での過剰な名前空間ウォッチ権限などだ。

コンプライアンス面では、CIS Benchmarkのvanilla Kubernetes 1.12版、EKS・AKS 1.8版のサポートも追加されている。

C++26 — コンパイル時リフレクション・コントラクト・std::execution・メモリ安全性強化が同時標準化

2026年3月、ロンドン（クロイドン）でのISO C++委員会会議でC++26の技術的作業が完了した。夏のCD（Committee Draft）投票で寄せられた411件の国際コメントへの対応を終えた。これからDIS（Draft International Standard）として承認投票に回り、最終的にISOから出版される。

リフレクションはC++26最大の変化だ。テンプレートの発明以来最大のアップグレードと位置づけられている。コンパイル時にC++自身の構造を記述・参照し、コードを生成できるようになる。ボイラープレートの自動生成やメタプログラミングの表現力が根本的に変わる。Herb Sutter自身が「C++が自分自身の機械へのキーを渡した瞬間」と表現している。C++11時代から議論されてきた機能で、15年近い議論の末の標準化だ。

メモリ安全性の改善は、既存コードを変更せずリコンパイルするだけで得られる。未初期化ローカル変数の読み取りによるUB（未定義動作）がC++26では消滅する。強化された標準ライブラリがvector・span・string・string_viewなどの主要型に境界チェックを提供する。これはすでにGoogleとAppleの本番環境で数億行規模のコードに展開済みだ。Googleでは1,000件以上のバグを修正し、本番フリートのセグフォルト率を30%削減した。平均オーバーヘッドは0.3%以下で、本番投入に耐える水準だ。

コントラクト（pre・post・contract_assert）が言語レベルで入った。関数宣言に事前条件・事後条件を書けるようになる。これまでC++でコントラクトを実現しようとすると、マクロやライブラリによる回避策に頼るしかなかった。言語仕様に入ることで、ツールチェーンが一貫したサポートを提供できる。

std::execution（非同期・並列処理の統一モデル）も入った。sender/receiverモデルに基づく非同期処理の標準化で、スレッドプールや非同期I/Oの扱いが統一される。

【補足】sender/receiverモデルでは、非同期操作の「記述（sender）」と「実行結果の受け取り（receiver）」を分離します。これにより、同じ非同期コードをスレッドプール・GPUカーネル・コルーチンなど異なる実行コンテキストに差し替えて動かすことができます。std::asyncが返すstd::futureは実行開始を呼び出し側が制御できないのに対し、senderは実行コンテキストへの接続（connect）が明示的に行われるまで実行されません。BoostのAsio、FacebookのFolly、NVIDIAのstdexecなど複数の実装が先行し、それらの経験を標準に取り込んだ形だ。これまでのstd::asyncやstd::futureでは実現できなかった、sender/receiverモデルに基づく統一的な非同期処理が可能になる。

C++の安全性をめぐる議論は、NSAやCISAが「メモリ安全な言語への移行」を推奨する声明を出した2022〜2023年以降、急速に政治的・技術的な圧力として高まっていた。C++委員会はこれに対し、「既存コードを捨てずに安全にする」方向で応えた形だ。

Nuxt Test Utils v4 — Vitest v4必須化とbeforeAllへのセットアップ移行

2026年2月7日に公開されたNuxt Test Utils v4.0.0は、Vitest v4への依存を核に据えた初のメジャーバージョンだ。変更の大半はVitest v4へのアップグレードに起因しており、テスト環境の初期化タイミングとモックの適用方法に大きな設計変更が入っている。

最も影響が大きい変更は、テスト環境のセットアップタイミングをsetupFilesからbeforeAllフックへ移行したことだ。v3ではsetupFilesのタイミングで環境セットアップが実行されていた。この設計では、vi.mockやmockNuxtImportの呼び出しがミドルウェアやプラグイン内のコンポーザブルに対して効かないケースがあった。コンポーザブルがモックの登録より先に評価されてしまうためだ。

v4では環境セットアップをbeforeAllフックに後退させた。Nuxtが起動する前にモックが登録されるため、モックの挙動がテストスイート全体で一貫する。これは「モジュールレベルのモックが無言で無視される」問題を解消するものだ。

ただしマイグレーションコストはある。describeブロックのトップレベルでuseRouter()やuseNuxtApp()を呼び出しているコードは、環境が未初期化の状態で実行されるため[nuxt] instance unavailableをスローするようになる。対処はbeforeAll内に移動することだ。

describe('router test', () => {
  let router: ReturnType<typeof useRouter>
  beforeAll(() => {
    router = useRouter()
  })
})

【補足】上記コードは`@nuxt/test-utils`から`mountSuspended`または`setup`関数でNuxtインスタンスを初期化した後に`beforeAll`が実行される前提です。`setupWithNuxt`（または`setup`）の呼び出しを`beforeAll`より前に配置しないと、`useRouter()`は依然として`[nuxt] instance unavailable`をスローします。

mockNuxtImportのファクトリ関数に元の実装が渡されるようになった。テストごとにモック全体をゼロから構築する必要がなくなり、実装の一部だけを上書きするパーシャルモックが少ないコードで書けるようになった。

registerEndpointにも2点の修正が入った。セットアップファイル内で登録したエンドポイントがモジュールリセット時に消失する問題の解消と、URLパターンにクエリパラメータを含むエンドポイントが正しくマッチするようになったことだ。パラメータ付きAPIパスを使うテストで発生していた失敗のクラス全体が解消される。

Vitest v4では、ファクトリ関数が明示的に返さなかったモジュールのエクスポートにアクセスすると、以前はundefinedを返していたが、v4では例外をスローする。推奨される対処はimportOriginalをスプレッドしてファクトリの戻り値に含めることだ。デフォルトで全エクスポートを維持しつつ、テストが必要な部分だけ上書きする形になる。

ピア依存の引き上げも伴う。happy-domは20.0.11以上、jsdomは27.4.0以上、@jest/globalsは30.0.0以上、@cucumber/cucumberは11以上が必要になった。バージョンを固定している環境では、Vitest v4のアップグレードと合わせてこれらの更新が必要だ。

今日の傾向

C++26がロンドン会議で411件の国際コメント対応を完了し、コンパイル時リフレクション・コントラクト・std::execution・メモリ安全性強化の4本柱を同時に標準化した。Googleの本番フリートでセグフォルト率30%削減・平均オーバーヘッド0.3%以下という実測値を根拠に、NSA/CISAの「メモリ安全言語への移行」圧力に対して「既存コードを捨てずに安全にする」路線で応えた形だ。

Kubescape 4.0はKAgentのCRDに対して15のOPA Regoコントロールを追加し、Model Context Protocolをベースにしたエージェントフレームワーク自体をスキャン対象に加えた。

【補足】OPA Rego（Open Policy Agent の問い合わせ言語）はCNCFの卒業プロジェクトであるOPAが採用するポリシー記述言語です。KubernetesのAdmission ControllerやCI/CDパイプラインでのポリシー評価に広く使われており、Kubescape自体も以前からRegoベースのコントロールを採用しています。GoogleのAppFunctionsも「オンデバイス版MCP」として位置づけられており、MCPが普及するにつれてMCPベースのコンポーネント自体のセキュリティが問われる局面が同日に2件登場した。

Nuxt Test Utils v4はVitest v4必須化に伴い、テスト環境のセットアップをsetupFilesからbeforeAllに移行した。describeトップレベルでのuseRouter()・useNuxtApp()呼び出しが[nuxt] instance unavailableをスローするようになるため、既存テストの修正が必要になる。

FOSDEM 2026でMozillaのMax IndenがWebTransportとWebSocketの比較を発表した。WebTransportはQUIC上で0-RTT接続とコネクションマイグレーションを実現するが、HTTPSセキュアコンテキストの厳格な要求がローカル開発やIoT用途での採用を制約する点として残っている。

参照記事

記録日: 2026-03-30