span を引数で持ち回らなくてよくなった。Workers tracing に4つの API が追加

要約

Cloudflare は 2026-09-25、Workers のトレーシングに4つの API を追加しました。OpenTelemetry の span 仕様への対応範囲を広げるものです。

tracing.startSpan(name) は、アクティブなコンテキストを変えずに span を作ります。既存の span 作成 API と異なり、作った span が「現在の span」にはなりません。そのため終了は span.end() の明示呼び出しが必要です。並行して走る処理をそれぞれ独立に計測したい場合に使う形です。

tracing.getActiveSpan() は、現在アクティブな span を取得します。これが実務上いちばん効きます。従来、深い階層の関数から span に情報を付けたい場合、span オブジェクトを引数として上から下まで引き回す必要がありました。処理そのものには不要な引数が、計測のためだけに関数シグネチャに入る。公式の表現では “annotate the current span from anywhere”。どこからでも現在の span に注釈を付けられるようになりました。

span.recordException(exception) は、例外イベントを span に直接記録します。受け取れるのは Error オブジェクト、文字列、または code / name / message を持つオブジェクトです。受け口が広いため、外部ライブラリが投げる形の揃わないエラーもそのまま渡せます。

span.setAttributes(attributes) は、複数の属性を一度に設定します。これと既存の setAttribute()（単数）の両方がメソッドチェーンに対応しました。属性を複数付ける処理が1行で書けます。

4つに共通するのは、書き方の負担を下げる方向の変更だという点です。 新しく計測できる対象が増えたわけではありません。同じことを、コードを歪めずに書けるようになったという性質の更新です。

何が変わったか

• tracing.startSpan(name): アクティブコンテキストを変えずに span を作成。span.end() の明示呼び出しが必要
• tracing.getActiveSpan(): 現在アクティブな span を取得。引数で引き回さずヘルパー関数の内側から注釈を追加できる
• span.recordException(exception): 例外を span に直接記録。Error オブジェクト / 文字列 / code・name・message を持つオブジェクトを受け取る
• span.setAttributes(attributes): 複数属性を一括設定。setAttribute() と併せてメソッドチェーンに対応
• いずれも OpenTelemetry の span 仕様への対応範囲拡大

業務インパクト（一般企業向け）

効くのは、可観測性を後付けする場面です。 すでに動いているアプリケーションに計測を入れる作業は、「どこに何を仕込むか」より「仕込むためにコードをどれだけ触るか」で難しさが決まります。 span を引数で引き回す設計だと、計測を1か所追加するためにその経路上のすべての関数シグネチャを変更することになります。変更範囲が広がり、レビューが重くなり、結果として「今は入れない」判断になりがちです。

getActiveSpan() はこの壁を下げます。 注釈を付けたい場所で現在の span を取ればよく、上流の関数を一切触らずに済みます。 計測の追加が局所的な変更になるため、必要になったときに入れるという運用が現実的になります。「最初に全部仕込む」か「入れない」の二択から抜けられます。

関数シグネチャに観測用の引数を混ぜない、という設計原則の話でもあります。 ビジネスロジックの関数が span を受け取っている状態は、ドメインの関心事とインフラの関心事が混ざっているということです。テストのたびにダミーの span を用意する必要が出ますし、関数の責務が読み取りにくくなります。分離できる手段が提供された以上、混ざっている箇所は整理の対象になります。

recordException() の受け口の広さは、実務的な配慮です。 JavaScript のエラーは形が揃いません。ライブラリによって Error を投げるもの、文字列を投げるもの、独自形式のオブジェクトを投げるものがあります。受け取る側で正規化するコードを毎回書かずに済むのは、地味ですが積み上がる差です。

OpenTelemetry への追随という意味も見ておく価値があります。 対応範囲が仕様に近づくほど、他の実行環境で書いた計測コードがそのまま動く可能性が上がります。Workers とそれ以外の環境を併用している組織にとって、計測の書き方を環境ごとに分けなくてよくなる方向です。ベンダー固有 API への依存を減らせるかどうかは、移行可能性の評価に直結します。

副業・個人活用視点

「動いているが遅い」の調査を請ける形が作りやすくなります。 既存の Workers アプリに対して、上流のコードを触らずに計測を差し込めるなら、調査の作業範囲が明確です。「まず計測を入れて、どこが遅いかを特定して報告する」という成果物が定義しやすい小さな案件になります。改修を請ける前の第一段として提案しやすい形です。

引数で span を引き回しているコードは、リファクタリングの提案材料です。 既存案件で見かけたら、**「計測用の引数をビジネスロジックから外せる」**と指摘できます。効果は分かりやすく（関数シグネチャが短くなる、テストが軽くなる）、リスクは低く、作業量も読めます。技術的負債の返済提案としてちょうどいい規模です。

個人開発では、入れるタイミングが変わります。 従来は「後から入れるのが面倒だから最初に仕込む」か「面倒だから入れない」でした。局所的に追加できるなら、問題が起きてから入れればいい。 先行投資を減らせるのは、時間が限られている個人にとって実利です。

OpenTelemetry を覚える価値が上がった、と捉えるのが正しい。 各社が独自 API を出すのではなく仕様に寄せているなら、仕様側を理解しておけばどの環境でも通用します。 Cloudflare、AWS、GCP で別々に学び直すのではなく、一度身につけたものが複数の案件で使える。 学習の投資効率という観点で、追随の動きは追う価値があります。