Azure Monitor Private Link Scope（AMPLS）配下の Log Analytics ワークスペース（LAW）で「クエリのパブリックアクセス」を無効にした途端、Application Insights の Transaction Search だけが何も表示されなくなる――この現象は、設定ミスというより「Transaction Search の通信方式」と「名前解決（DNS）」の噛み合わせで起きます。原因の切り分けから、最短で直す具体策までを整理します。
起きている症状（結論に直結するポイントだけ）
まず、今回の“ハマりどころ”を、状況として正しく言語化します。ここが整理できると、対処はほぼ DNS とネットワークの作業になります。
- Azure Monitor Private Link Scope（AMPLS）配下に Log Analytics ワークスペース（LAW）がある
- LAW の「パブリックアクセス（クエリ）」を 無効 にすると、Application Insights の Transaction Search ブレードでログが一切表示されない
- LAW の「パブリックアクセス（クエリ）」を一時的に 有効 にすると、Transaction Search が表示される
- Application Insights リソースも同じ AMPLS に関連付けても状況は変わらない
| 観測される挙動 | 意味するところ |
|---|---|
| Public Query を開けると Transaction Search が復活する | Transaction Search は「Private Link 経由」ではなく、どこかで パブリック到達性に依存 している可能性が高い |
| Application Insights を AMPLS にリンクしても変わらない | 問題は「リソース側の関連付け」ではなく、ポータル閲覧端末（ブラウザ）の通信経路 に寄っている可能性が高い |
根本原因：Transaction Search はブラウザから Query API を直接呼ぶ
今回の本質はここです。Transaction Search ブレードは、表示のためにブラウザが直接 API を呼び出す形になりやすく、端末側のネットワークと DNS が Private Link に対応していないと詰みます。
典型的には、ブラウザが以下のようなエンドポイントへクエリを投げます。
api.applicationinsights.azure.com（Application Insights Query API 系）api.loganalytics.io（Log Analytics Query API 系）
ここで、LAW の「パブリックアクセス（クエリ）」を無効化している場合、端末が次の状態だと Transaction Search の呼び出しがブロックされ、結果として“何も出ない”になります。
- 閲覧している PC が VNet 内にいない（VPN/ExpressRoute で入っていない）
- VNet に入っていても、端末の DNS が Private Link 用の名前解決になっていない
- オンプレ DNS があり、Azure 側の Private DNS / Private Resolver に転送できていない（条件付きフォワーダー未設定）
言い換えると、Transaction Search は「ポータルが裏側で代わりに Private Link を使ってくれる」タイプの画面ではなく、閲覧者のブラウザが直接データプレーンに到達する必要がある ケースがある、ということです。
（うまくいかない典型）
ブラウザ（自宅/社外PC）
→ DNS が public に解決
→ api.loganalytics.io / api.applicationinsights.azure.com（パブリック側）へ接続しようとする
→ LAW の Public Query 無効でブロック
→ Transaction Search は空/エラー/無限ロード
（うまくいく状態）
ブラウザ（VPN/ER で VNet に接続）
→ DNS が privatelink 側に解決
→ Private Endpoint 経由で Query API に到達
→ Transaction Search が表示されるなぜ「Logs（ログ）」ブレードや Workbooks では見えることがあるのか
同じ Azure Portal の画面でも、内部の実装（どこでクエリを実行しているか）が違うと、Private Link 環境での挙動が変わります。ここを理解すると、回避策（運用設計）も立てやすくなります。
| 機能 | クエリ実行のイメージ | Private Link 前提での相性 | ハマりやすい点 |
|---|---|---|---|
| Transaction Search | ブラウザが Query API を直接叩く構成になりやすい | 端末側の VNet 接続と DNS が整っていないと厳しい | LAW の Public Query を閉じると、端末側が public に解決した瞬間に詰む |
| Logs（ログ）ブレード | ポータル側（サービス側）がクエリ実行を肩代わりする構成になりやすい | AMPLS/Private Endpoint が正しければ動きやすい | ただしネットワーク/ポリシー次第で例外はあり得る |
| Workbooks | ワークブックの実行基盤がクエリを叩く形になりやすい | Logs 同様に相性が良いことが多い | 閲覧権限（RBAC）不足だと「何もない」に見えることがある |
今回のケースで「Transaction Search は見えないが、Public Query を一時的に開けると見える」という挙動は、この“クライアント直叩き”の特徴と一致します。
解決策は3パターン（最優先は DNS とネットワーク）
対処は大きく3つに分かれます。現場の制約（端末が社外なのか、VPN があるのか、運用で許せるのか）に合わせて選びます。
| パターン | 狙い | メリット | 注意点 | おすすめ度 |
|---|---|---|---|---|
| パターンA：端末を VNet + Private DNS に正しく参加 | Transaction Search を Private Link 経由で成立 させる | セキュアに“正攻法”で解決。運用も一貫する | VPN/ER、DNS 設計（条件付きフォワーダー等）が必要 | 高 |
| パターンB：Transaction Search を使わず Logs/Workbooks で代替 | UI 依存を減らし、KQL で同等の調査を行う | ネットワーク制約が強い環境でも回る。自動化しやすい | Transaction Search の“見やすさ”は一部失う | 中〜高 |
| パターンC：Public Query を一時的に有効化 | いまのネットワークのまま動かす | 最短で復旧（ただし“その場しのぎ”） | セキュリティリスクと運用事故（戻し忘れ） | 低（緊急時のみ） |
パターンA：端末側を VNet / Private DNS に正しく参加させる（推奨）
「すべて Private Link 経由で見えるはず」を実現するには、閲覧端末が Private Link を引ける場所にいる 必要があります。特にハイブリッド（オンプレ＋Azure）で、端末がオンプレ DNS を使っている場合は、条件付きフォワーダーが鍵になります。
やることの全体像
- 端末の通信経路を VNet に寄せる（VPN / ExpressRoute）
- 端末の DNS を Private Link 対応にする（オンプレ DNS → Azure 側へ条件付きフォワード等）
- Azure 側で Private DNS ゾーンと VNet リンク、AMPLS の Private Endpoint が正しいことを確認
- 最後に端末側で 名前解決の確認 と DNS キャッシュのクリア
手順1：端末を VNet に入れる（VPN / ExpressRoute）
Transaction Search を使う端末（利用者の PC）が、少なくとも「Private Endpoint のある VNet（または到達できる VNet）」へ入っている必要があります。
- 社内ネットワーク → ExpressRoute で Azure に接続
- リモート端末 → VPN（P2S/S2S）で VNet に接続
ここで重要なのは「ポータルが見える」ではなく、Query API の宛先がプライベート IP に向くことです。portal.azure.com にアクセスできても、Query API が public に解決されると同じ問題が再発します。
手順2：DNS を Private Link で解決できるようにする（条件付きフォワーダー）
症状の多くは DNS で決まります。オンプレ DNS を使っているなら、次のいずれかの形で「Azure 側の Private DNS 解決」を引けるようにします。
- オンプレ DNS に 条件付きフォワーダー を設定し、Azure 側 DNS（例：Azure DNS Private Resolver のインバウンド エンドポイント）へ転送
- 端末が参照する DNS サーバー自体を、Private DNS を解決できる構成に変更（環境により可否）
最低限、次の FQDN を引いたときに “private 側の名前解決” に乗る必要があります。
| 確認したい名前 | Transaction Search で重要な理由 | 期待する状態（概念） |
|---|---|---|
api.applicationinsights.azure.com | Application Insights の検索/トレース系 API の到達先になりやすい | 最終的に Private Endpoint のプライベート IP 側へ向く |
api.loganalytics.io | LAW に対するクエリの到達先になりやすい | 最終的に Private Endpoint のプライベート IP 側へ向く |
privatelink.monitor.azure.com（例） | Private Link 用の CNAME の着地点として登場しやすい | Private DNS ゾーンで A レコード（プライベート IP） が引ける |
ハイブリッド DNS の場合、オンプレ DNS から Azure 側に転送できていないと、端末は public 側の IP を引いてしまい、LAW の Public Query 無効によりブロックされます。
手順3：Azure 側の確認（Private DNS ゾーンと VNet リンク、Private Endpoint）
端末側を整える前に、Azure 側がそもそも正しいかを確認します。チェックする観点は次の3つです。
- Log Analytics ワークスペースと Application Insights が、狙った AMPLS に関連付いている
- AMPLS に紐づく Private Endpoint が、正しい VNet / サブネットに存在する
- Private DNS ゾーン（例：
privatelink.monitor.azure.com）が、Private Endpoint のある VNet（または到達させたい VNet）にリンクされている
ここがズレていると、端末側で頑張っても「private に解決できない」「解決はできても到達できない」になります。
手順4：端末側で名前解決と到達性を確認（ここで勝負が決まる）
実際の切り分けはシンプルです。Transaction Search を使う端末で、次を確認します。
- DNS が “private 側” を引いているか
- VPN/ER 経由で “private 宛先” に到達できるか
Windows 端末なら、まずは次のような確認が有効です。
nslookup api.loganalytics.io
nslookup api.applicationinsights.azure.com結果の見方は環境で異なりますが、ポイントは「最終的にプライベート IP に向かうこと」です。CNAME を辿って privatelink ドメイン配下に着地し、A レコードが RFC1918 のプライベート IP（10.x/172.16-31.x/192.168.x など）になるのが典型です。
そして、名前解決を直した直後は DNS キャッシュが残りやすいので、必ずキャッシュをクリアしてから再確認します。
ipconfig /flushdnsここまで整うと、LAW の「パブリックアクセス（クエリ）」を無効のままでも Transaction Search が表示される状態に寄せられます。実際に多い“最終解”は、オンプレ DNS から Azure DNS への条件付きフォワーダーを設定したら直ったという形です。
パターンB：Transaction Search を使わず、Logs / Workbooks で運用する
セキュリティ要件が強い環境では「端末を VNet に入れる」こと自体が難しい場合があります。その場合、Transaction Search に固執せず、Logs（KQL）と Workbooks で同等の調査体験を作る方が、結果的に安定します。
Logs で“Transaction Search 的なこと”をやるコツ
Transaction Search がやっていることは、雑に言うと「特定リクエスト（operation）を起点に、関連する依存関係・トレース・例外をつなげて見る」です。これは KQL で再現できます。
例えば「直近1時間で失敗したリクエストを探す」：
requests
| where timestamp > ago(1h)
| where success == false
| project timestamp, name, resultCode, operation_Id, cloud_RoleName
| top 50 by timestamp desc次に、operation_Id を起点に関連ログを集約する（ウォーターフォール代替の入口）：
let op = "<ここに operation_Id>";
union isfuzzy=true requests, dependencies, traces, exceptions
| where timestamp > ago(24h)
| where operation_Id == op
| project timestamp, itemType, name, message, resultCode, success, duration, cloud_RoleName
| order by timestamp ascこれを Workbooks 化して、入力パラメータ（operation_Id、時間範囲、RoleName 等）を付けると、Private Link 前提でも“チームで使える調査画面”になります。Transaction Search の UI に寄せるより、運用でブレないのが利点です。
「Logs は見えるのに Transaction Search は見えない」環境での現実解
- 日常運用：Logs / Workbooks を標準にする（Private Link と相性が良い）
- どうしても必要なときだけ：パターンA（VPN + DNS）で Transaction Search も使える端末を用意
“全部の端末で Transaction Search を動かす”を目標にするとネットワークが重くなりがちなので、調査フローの標準化（KQL/Workbooks）に振り切るのは合理的です。
パターンC：クエリのパブリックアクセスを一時的に有効化する（緊急回避）
どうしても今すぐ Transaction Search を使いたいが、VPN/DNS を直す時間がない――というケースでは、LAW の「パブリックアクセス（クエリ）」を一時的に有効化することで回避できることがあります。
ただし、これは “戻し忘れ” が事故になりやすく、設計としては推奨しません。実施するなら、最低限次の運用ルールをセットで入れます。
- 作業窓（メンテ時間）を決め、終わったら必ず無効に戻す
- 変更履歴が残る形（チケット、IaC、承認）で実施する
- RBAC を最小化し、不要なユーザーにクエリ権限を与えない
- 監査ログで変更とアクセスを追えるようにする
「Public を開けたら見える」という事実は、根本原因がネットワーク/DNS であることの裏返しでもあります。中長期ではパターンAまたはBへの移行を前提にした方が安全です。
追加のチェックポイント（ハマりやすい順）
次の表は、現場で“直したつもりなのに直らない”を潰すためのチェックリストです。上から順に確認すると、遠回りしにくいです。
| チェック項目 | OK の目安 | NG の典型 | 対処の方向性 |
|---|---|---|---|
| 端末は Private Endpoint のある VNet に到達できるか | VPN/ER 接続が安定し、VNet 宛のルートがある | ポータルは開けるが、実は VNet へ入れていない | VPN/ER、ルート、FW を見直す |
| 端末の DNS が private 側を解決できているか | nslookup api.loganalytics.io 等で最終的にプライベート IP | public IP に解決される / CNAME が privatelink に行かない | 条件付きフォワーダー、Private Resolver、VNet リンクを調整 |
| Private DNS ゾーンは正しい VNet にリンクされているか | Private Endpoint がある VNet（または到達させたい VNet）にリンク | 別 VNet にだけリンクしていて、端末の経路と一致しない | VNet リンクの追加/整理 |
| AMPLS と LAW / App Insights の関連付けは正しいか | 意図したスコープに紐付いている | 別スコープに紐付いている／途中で増減して混乱 | 関連付けを棚卸しして統一 |
| DNS キャッシュが残っていないか | 変更後に ipconfig /flushdns 実施 | DNS を直したのに端末だけ直らない | キャッシュクリア、ブラウザ再起動、端末再起動 |
| 社内プロキシ/セキュリティ製品が名前解決や通信を変えていないか | DNS は社内/指定サーバーを参照し、迂回がない | プロキシが TLS 終端、もしくは DNS を独自に上書き | 除外設定、PAC、FW ルール、ゼロトラスト製品の挙動確認 |
実務で効く「最短の切り分け手順」
作業者が増えるほど混乱しやすいので、現場では次の順で確認すると速いです。
- 端末で nslookup：
api.loganalytics.io/api.applicationinsights.azure.comが private を引いているか - 端末の経路：VPN/ER で VNet に入っているか（切れていないか）
- Azure 側：Private Endpoint の VNet と、Private DNS ゾーンの VNet リンクが一致しているか
- キャッシュ：DNS キャッシュとブラウザのキャッシュをクリアして再試行
この順番なら「Public Query を開けたら直る」タイプの問題を、短時間で Private Link 前提に戻しやすくなります。
よくある落とし穴（直ったと思い込むポイント）
- “VPN に繋いだ”だけで安心する：VPN は繋がっていても、端末の DNS が自宅/ISP 側のままだと public 解決されます
- Private DNS ゾーンは作ったが VNet にリンクしていない：ゾーンは存在しても、リンクがないと端末から引けません
- オンプレ DNS の条件付きフォワーダーが片系だけ：冗長構成で片側 DNS だけ設定し、フェイルオーバー時に再発します
- DNS キャッシュで古い解決結果を掴む：設定変更後にブラウザを開きっぱなしで“直らない”と判断しがちです
- 「App Insights も AMPLS に入れたから大丈夫」と思う：関連付けだけでは、Transaction Search の“端末→API”経路は変わりません
運用設計のおすすめ（セキュリティと使い勝手の両立）
Private Link 前提の監視基盤では、「全員がどの端末からでも Transaction Search を使える」よりも、次の形が安定しやすいです。
- 標準調査は Logs / Workbooks（KQL をチームでテンプレ化）
- 深掘り調査用に、VPN + DNS が整った端末/踏み台を用意（必要時のみ Transaction Search も利用）
- LAW の「パブリックアクセス（クエリ）」は基本 無効 のまま（例外は緊急時のみ）
この構成なら、Private Link のセキュリティを保ちつつ、運用の詰まりどころ（特定 UI が使えない問題）を最小化できます。
まとめ（この1ページで持ち帰るべき結論）
- Application Insights の Transaction Search が見えない原因は、ブラウザが Query API を直接叩く通信方式にある
- LAW の「パブリックアクセス（クエリ）」を無効にすると、端末が public 解決した瞬間にブロックされ、Transaction Search が空になる
- 根本解決は 端末を VNet に入れ、DNS を Private Link 対応にすること（特にオンプレ DNS の条件付きフォワーダー）
- 難しい場合は、Logs / Workbooks で代替し、必要時だけ Transaction Search を使える端末を用意するのが現実的
コメント