技術トレンド調査レポート 2026-08-24
このページは、情報収集スレッドのメモから自動生成している技術トレンドの調査ログです。速報ソースやX由来のリンクは確認前の候補を含むため、意思決定に使う前にリンク先の一次情報や公式発表を確認します。
08:30 JST
Cloudflare Web Analyticsのsoft navigation計測、SPAのpageviewとCore Web Vitalsの見え方が変わる
Cloudflareは2026-08-21に、Cloudflare Web AnalyticsのReal User Monitoringでclient-side soft navigationの計測精度を改善すると発表した。React、Angular、Vue、SvelteのようなSPAでは、ページ遷移時にdocument全体を再読み込みせず、Navigation APIやHistory APIで画面を切り替えることが多い。今回の変更では、対応ブラウザでChromeのSoft Navigation APIを使い、soft navigationごとのLCPを測れるようにしている。
実務上の注意点は、dashboardやGraphQL APIに出るpageview数が変わり得ることだ。従来はHistory API由来の遷移を大まかに扱っていたため、SPA内の画面遷移が過小評価されていた可能性がある。CloudflareはnavigationTypeを拡張し、通常のhard navigation、Soft Navigation APIで検出したsoft navigation、Soft Navigation APIが使えない環境でNavigation API/History APIからfallback計測した遷移を区別できるようにしている。fallback側ではLCPは取れないが、他のCore Web Vitalsは残る。
guppi向けの見方: AstroやNext.js、React系のサイトで「どのページが遅いか」を見るとき、SPA的な遷移が計測から漏れると体感とdashboardがずれる。guppiguppi.comのような個人ブログでも、将来アプリ寄りの画面やclient navigationが増えるなら、pageview増減を単純な成長/減少と読まず、計測方式変更の影響を分けて見る必要がある。特にLCPは初回表示だけでなく、client-side遷移後の主要コンテンツ表示も見たい。
- 確認状況: Cloudflare Developers公式Changelogで確認。X/search系はクレジット不足で利用できなかったため、公式情報を一次情報として採用。
- 重要度: 🟡 あとで読む
- Links: source 1
Cloudflare Durable ObjectsのDeployments tab、gradual rollout中の実トラフィック分布を見やすくする
Cloudflareは2026-08-20に、Durable Object namespaceのdashboardへDeployments tabを追加した。Durable Object namespaceは背後のWorker scriptに紐づくため、liveになっているWorker versions、traffic split、versionごとのrequests、error rate、wall timeをnamespace側から確認できる。これまではgradual deploymentの状況を見るためにbacking Worker側へ移動する必要があったが、Durable Objectの運用画面で直接見られるようになる。
重要なのは、configured traffic splitとactual traffic shareを分けて表示する点だ。Durable Objectsでは、設定したsplitが個別requestではなくObject instanceへ効く。すでに起動しているObjectは新しいdeploymentを作るまで開始時のversionにpinされるため、50/50や100%へ設定を変えても、実際のtraffic shareがすぐ追随するとは限らない。CloudflareはGraphQL Analytics API由来の観測値でactual shareを表示し、requests、error rate、median wall timeと合わせてrollout判断できるようにしている。
guppi向けの見方: Durable Objectsはchat、collaboration、queue coordination、session stateのような「状態を持つedge機能」で使いたくなる。stateful componentのrolloutでは、statelessなWorkerより「古いversionがどれだけ残っているか」「errorが特定versionに寄っていないか」が重要になる。Cloudflareを使うプロダクトでDurable Objectsを入れる場合、release手順にdeployment tabの確認、actual splitの待ち時間、rollback基準を組み込むとよい。
- 確認状況: Cloudflare Developers公式Changelogで確認。公式発表内のGraphQL Analytics API、gradual deployment説明も参照。
- 重要度: 🟡 あとで読む
- Links: source 1
Vercel Observability custom metrics、Functionsから事業指標と技術指標を同じ場所へ出せる
Vercelは2026-08-20に、Vercel Observabilityでcustom metricsをサポートした。@vercel/functionsのmetric()関数から、Vercel Functions内で任意の数値をemitし、query builder、Notebooks、vc metrics CLIで分析できる。例としてdatabase query latencyやbusiness event countのような値に属性を付け、deploymentやfunction regionなどVercelが自動付与する属性と一緒に集計できる。
これは、単なる監視項目追加よりも「アプリの運用判断をどこで見るか」の話に近い。serverless functionでは、request数、duration、errorだけでは、ユーザー操作やDB外部依存の劣化を説明しにくい。custom metricsを使うと、stripe.webhook_lag_ms、auth.callback_failures、db.query_ms、agent.tool_error_countのようなサービス固有の値をdeployment単位で追える。Vercel側ではcustom metricsはobservability eventsとして課金され、Pro/EnterpriseのObservability Plusで利用可能と説明している。
guppi向けの見方: Cloudflare Pages/Workersを主戦場にしていても、custom metricsの考え方はそのまま使える。将来サービスを運営するなら、ログだけでなく「ユーザーに影響する数値」を早めに決めて、releaseやincident調査で見られる場所へ送るべきだ。特に決済、認証、メール送信、AI agentのtool callは、成功/失敗だけでなくlatency、retry、外部APIのエラー率を追うと、障害の切り分けが速くなる。
- 確認状況: Vercel公式Changelogで確認。料金・plan条件は変わり得るため、導入前に最新docsとdashboardで再確認したい。
- 重要度: 🟡 あとで読む
- Links: source 1