.NETでAgent365やOpenTelemetryのテレメトリを扱っている場合、今回の確認ポイントは「user.id がどの値から解決されるか」です。2026年5月5日にマージされた Fix GetCallerBaggagePairs: resolve userId across all channels では、GetCallerBaggagePairs() が AadObjectId だけに依存せず、AgenticUserId や From.Id へフォールバックするように修正されました。これにより、Teams以外のチャネルやA2A呼び出しで user.id が空になっていたケースが改善されます。(GitHub)
対応が必要なのは、.NETアプリでMicrosoft OpenTelemetry distro、Agent365関連のホスティングテレメトリ、または user.id を使ったログ分析・トレース検索・アラート・ダッシュボードを運用しているチームです。特に、user.id をMicrosoft Entra IDのオブジェクトIDと同じものとして扱っている場合は、今回の変更後に From.Id や AgenticUserId が入る可能性を前提に、クエリや後続処理を見直してください。
今回の.NET documentation updateで変わったこと
今回の変更は、TurnContextExtensions.GetCallerBaggagePairs() における user.id baggageの解決ロジックを修正するものです。
従来は、呼び出し元ユーザーのIDとして AadObjectId だけを参照していました。しかし、GitHub上の説明では、AadObjectId はTeams以外のチャネルやA2A呼び出しでは null になるケースがあるとされています。そのため、テレメトリ上の user.id が欠落し、ユーザー単位の追跡や障害調査がしづらくなる可能性がありました。(GitHub)
修正後の優先順位は次の通りです。
from?.AadObjectId ?? from?.AgenticUserId ?? from?.Id実装上も、OpenTelemetryConstants.UserIdKey に対して上記のフォールバック順で値を設定する形になっています。(GitHub)
| 項目 | 変更前 | 変更後 | 実務上の意味 |
|---|---|---|---|
user.id の取得元 | AadObjectId のみ | AadObjectId → AgenticUserId → From.Id | AadObjectId がないチャネルでもIDが入りやすくなる |
| Teams | 主に AadObjectId | AadObjectId が優先 | 既存のTeams中心の挙動は大きく変わりにくい |
| Teams以外のチャネル | null になりやすい | From.Id にフォールバック | user.id の欠落率が下がる可能性がある |
| A2A呼び出し | AadObjectId がないと欠落 | AgenticUserId にフォールバック | エージェント関連の呼び出し追跡がしやすくなる |
重要なのは、この変更が認証や認可の仕組みを変更するものではない点です。変わるのは、OpenTelemetry/Agent365のテレメトリに付与される user.id baggageの解決方法です。
なぜuser.id baggageの修正が重要なのか
OpenTelemetryのBaggageは、リクエストやワークフローに紐づくキーと値のコンテキスト情報を、サービス境界を越えて伝播させるための仕組みです。ユーザーIDやアカウントIDのように、後続のトレース、メトリック、ログ分析で使いたい情報を運ぶ用途で利用されます。(OpenTelemetry)
user.id が空のままだと、現場では次のような問題が起きます。
| 起きやすい問題 | 具体例 |
|---|---|
| 障害調査でユーザー軸の絞り込みができない | 「特定ユーザーだけ失敗しているか」をトレースから確認しづらい |
| ダッシュボードの集計が不正確になる | user.id が空のリクエストが「不明ユーザー」にまとまる |
| A2A呼び出しの追跡が途切れる | どのエージェント由来の処理かを後から追いにくい |
| アラートの条件が意図とずれる | user.id の欠落を異常として検知している場合、修正後に件数が変わる |
今回の修正で user.id が入りやすくなること自体は改善です。ただし、値の意味が常に同じとは限りません。AadObjectId、AgenticUserId、From.Id は同じ種類のIDとして扱うべきではありません。
影響を受けやすいシステム
今回の.NET documentation updateは、すべての.NETアプリに直接影響するものではありません。影響が出やすいのは、Microsoft OpenTelemetry distro for .NETのAgent365関連機能を使い、かつ呼び出し元ユーザーの情報をテレメトリで分析しているシステムです。
| 利用状況 | 対応優先度 | 確認ポイント |
|---|---|---|
| Teamsチャネルのみを利用している | 低〜中 | AadObjectId が引き続き優先されるため、既存クエリに大きな変化がないか確認する |
| Teams以外のチャネルも利用している | 高 | 修正後に From.Id が user.id として入るケースを確認する |
| A2A呼び出しを使っている | 高 | AgenticUserId が入るケースを想定して分析軸を見直す |
user.id をダッシュボードやアラート条件に使っている | 高 | 欠落率、ユニーク数、集計単位の変化を確認する |
user.id を認可やユーザー照合に流用している | 要注意 | テレメトリ用IDを業務ロジックに使っていないか確認する |
特に注意したいのは、user.id を「必ずEntra IDのオブジェクトIDである」とみなしている実装です。今回の修正後は、Teams以外のチャネルでは From.Id、A2Aでは AgenticUserId が入る可能性があります。GUID形式であることを前提にした処理や、Entra IDユーザー検索にそのまま渡す処理がある場合は、エラーや誤照合の原因になります。
変更後のチャネル別挙動
PR上では、修正後のチャネル別挙動として、Teamsでは AadObjectId、その他のチャネルでは From.Id、A2Aのユーザー文脈では AadObjectId、A2Aのエージェント文脈では AgenticUserId が使われると整理されています。(GitHub)
| チャネル・呼び出し | 修正後のuser.id | 確認すべきこと |
|---|---|---|
| Teams | AadObjectId | 既存のユーザー追跡が継続して機能するか |
| Teams以外のチャネル | From.Id | IDの形式、重複、チャネルごとのスコープを確認する |
| A2Aユーザー文脈 | AadObjectId | 従来のユーザー軸分析と整合するか |
| A2Aエージェント文脈 | AgenticUserId | エージェント由来の処理をユーザーと混同していないか |
この表から分かる通り、今回の修正は「単に null を埋める」だけではありません。チャネルによって user.id の由来が変わるため、分析側でIDの意味を区別できるようにしておくことが重要です。
移行時に確認すべきポイント
依存パッケージまたは参照コミットを確認する
まず、自社アプリが該当する変更を含むバージョンまたはコミットを参照しているか確認します。
GitHubの変更履歴では、2026年5月6日の 1.0.2 に「より多くのチャネルタイプで user.id baggageを解決するためのホスティングテレメトリ抽出ロジック更新」が追加されています。また、関連PRでは Microsoft.OpenTelemetry パッケージのバージョンが 1.0.1 から 1.0.2 に更新されたと説明されています。(GitHub)
確認対象は次の通りです。
| 確認箇所 | 見るべき内容 |
|---|---|
.csproj | Microsoft.OpenTelemetry のバージョン |
Directory.Packages.props | 集中管理しているパッケージバージョン |
| ロックファイル | 実際に復元されているバージョン |
| forkまたはソース参照 | TurnContextExtensions.cs にフォールバック処理が入っているか |
| CI/CD | 本番ビルドで古いパッケージが固定されていないか |
NuGetや社内フィードを使っている場合は、単にコードを変更するだけでなく、実際のデプロイ成果物に修正版が入っているかまで確認してください。
user.idを使うクエリとダッシュボードを見直す
修正後は、これまで空だった user.id に値が入る可能性があります。そのため、次のような集計は結果が変わることがあります。
| 見直す対象 | 変更後に起きる可能性 |
|---|---|
user.id の欠落率 | 欠落件数が減る |
| ユニークユーザー数 | From.Id や AgenticUserId 分だけ増える |
| エラー率のユーザー別集計 | 「不明ユーザー」に集約されていたエラーが分散する |
| アラート条件 | user.id is null を前提にした条件が変化する |
| SLA/SLO分析 | ユーザー単位の分母・分子が変わる |
移行後すぐに判断せず、リリース前後で同じ期間・同じチャネルごとに比較するのがおすすめです。特に、TeamsとTeams以外のチャネルを混ぜて集計している場合は、チャネル別に分けて差分を見ると原因を切り分けやすくなります。
user.idの意味を業務ロジックに使っていないか確認する
user.id はテレメトリ上の識別子です。今回の変更で値が入りやすくなるからといって、認可、課金、ユーザー本人確認のような業務ロジックにそのまま使うべきではありません。
特に避けたいのは次のような実装です。
| 避けるべき実装 | 理由 |
|---|---|
user.id をEntra IDのオブジェクトIDとして固定的に扱う | From.Id や AgenticUserId が入る可能性がある |
user.id の形式をGUID前提でバリデーションする | Teams以外のチャネルで形式が異なる可能性がある |
user.id だけでユーザーを一意に統合する | チャネルや呼び出し元の違いを無視すると誤集計につながる |
| Baggageに機密情報を追加する | サービス境界を越えて伝播され、ログや外部バックエンドに送られる可能性がある |
OpenTelemetryのドキュメントでも、Baggageはサービス境界を越えて伝播されるため、認証情報、APIキー、個人情報のようなセンシティブな情報を入れないよう注意されています。(OpenTelemetry)
テストで確認すべきシナリオ
PRのテスト計画では、既存テストに加えて、Teams以外のチャネルで From.Id にフォールバックするケース、A2Aで AgenticUserId にフォールバックするケース、すべての値が設定されている場合に AadObjectId が優先されるケースが追加されています。(GitHub)
自社環境でも、少なくとも次の4パターンを確認しておくと安全です。
| テストケース | 入力条件 | 期待するuser.id |
|---|---|---|
| Teams標準ケース | AadObjectId がある | AadObjectId |
| Teams以外のチャネル | AadObjectId がなく、From.Id がある | From.Id |
| A2Aエージェント文脈 | AadObjectId がなく、AgenticUserId がある | AgenticUserId |
| 優先順位確認 | AadObjectId、AgenticUserId、From.Id がすべてある | AadObjectId |
テストでは、単に値が入るかだけでなく、観測基盤側でどう表示されるかも確認してください。アプリケーション内では正しく設定されていても、エクスポーター、プロセッサ、バックエンドのマッピングによって、表示名や保存先の属性名が異なることがあります。
運用チームが見るべきメトリクス
移行後は、機能の成否だけでなく、テレメトリの品質が改善したかを確認することが大切です。
| 観点 | 確認方法 |
|---|---|
user.id の欠落率 | リリース前後で空値の割合を比較する |
| チャネル別の分布 | Teams、Teams以外、A2Aで集計を分ける |
| ユニークID数 | 急増していないか確認する |
| エラー分析の精度 | 「不明ユーザー」扱いだったエラーが適切に分散しているか見る |
| アラート影響 | 既存アラートの発火条件が意図せず変わっていないか確認する |
ユニークID数が大きく増えた場合は、必ずしも異常とは限りません。これまで欠落していた user.id が入るようになった結果かもしれません。一方で、チャネルごとのID体系を区別しないまま全体集計していると、ユーザー数を過大に見積もる可能性があります。
よくある誤解と注意点
user.idが入るようになれば、ユーザー識別は完全になる？
完全ではありません。今回の変更は、AadObjectId がない場合に別の候補へフォールバックする修正です。チャネルごとにIDの意味や形式が異なる可能性があるため、厳密なユーザー統合には、チャネル、テナント、会話IDなどの補助情報も合わせて扱う必要があります。
Teamsだけ使っていれば確認不要？
Teamsのみの場合でも、AadObjectId が引き続き優先されるため影響は限定的です。ただし、user.id を使ったアラートやダッシュボードを運用しているなら、リリース後に値の分布が変わっていないか確認しておくべきです。
Baggageに入った値は自動的にすべてのログ属性になる？
OpenTelemetryでは、Baggageはコンテキスト情報として伝播されるキー値ですが、Span、Metric、Logの属性とは別物です。属性として見えるかどうかは、明示的に取り込む処理や利用している計装・プロセッサに依存します。(OpenTelemetry)
そのため、GetCallerBaggagePairs() の修正後も、バックエンドで期待通りに検索できるかは実データで確認してください。
今回の更新で取るべき次の行動
今回の.NET documentation updateで確認すべき本質は、GetCallerBaggagePairs() の user.id 解決ロジックが AadObjectId 固定から、AadObjectId → AgenticUserId → From.Id のフォールバック方式に変わった点です。
まず、自社アプリがMicrosoft OpenTelemetry distro for .NETやAgent365のホスティングテレメトリを使っているか確認します。該当する場合は、依存バージョンまたは参照コミットを確認し、1.0.2相当の変更が入っているかを見ます。そのうえで、Teams、Teams以外のチャネル、A2A呼び出しのテストデータを流し、user.id の値、欠落率、ユニーク数、既存アラートへの影響を確認してください。
最も重要なのは、user.id を「常に同じ種類のユーザーID」とみなさないことです。テレメトリの精度は上がりますが、IDの由来を区別しないまま分析や業務ロジックに使うと、誤集計や誤判定につながります。移行時は、チャネル別の検証とダッシュボードの見直しまでをセットで行うのが安全です。
コメント