Windowsの名前解決の順序 ── hosts・DNSキャッシュ・LLMNR/mDNS・DoH

「同じ設定なのに、このPCだけ社内サーバーに繋がらない」「ブラウザーでは開けるのに、業務アプリでは名前解決に失敗する」「hostsに書いたのに効かない」。

こうした問題を調べるとき、最初に確かめたいのはその名前に、どの仕組みが答えているかです。Windowsにはキャッシュ、hosts、DNSサーバー、LLMNR、NetBIOS、mDNSという複数の経路があり、アプリによってはWindowsとは別の経路を使います。

この記事では、まず全体像をつかみ、名前の形と各経路の違いを整理してから、実際の切り分け手順へ進みます。急いで調査したい方は、次の表から該当箇所へ進んでください。

この記事の前提

パケットキャプチャ記事が扱うのは線を流れるパケット、プロキシ記事が扱うのは「誰のプロキシ設定を読むか」です。本記事は、その手前の「宛先のIPアドレスはどこから来たのか」をMicrosoftの一次情報にもとづいて整理します。

1. まず結論

覚えておきたいのは、次の三点です。

• Windowsの名前解決は、いつも一本の列を順番に進むわけではありません。キャッシュとhostsが先ですが、単一ラベル名では既定でDNSとLLMNR・NetBTが並行して動きます。³⁴
• 同じ名前でも、PCの設定とアプリの経路が違えば結果は変わります。サフィックス、VPN、NRPT、ブラウザーの内蔵リゾルバーを分けて考えます。⁵⁶⁷
• 調査では、使う経路を限定して結果を比べます。Resolve-DnsNameのスイッチでキャッシュ・DNS・リンクローカルを分け、繋がるPCとの設定差分とキャプチャで確かめます。⁸

まずは次の図を、全体の見取り図として使ってください。

flowchart TB
    accTitle: 名前解決は層の重なり
    accDescr: 名前解決の依頼はアプリのAPIからDNSクライアントサービスに渡り、キャッシュとhostsが先に見られ、次にDNSサーバーと、単一ラベル名のときだけLLMNR・NetBIOS（既定ではDNSと並行）が試される。.local名には設定済みDNSに加えてmDNSという経路も加わる。ブラウザーはこの列の外に独自のリゾルバーを持つ
    app["アプリ（getaddrinfo）"] --> svc["DNSクライアントサービス"]
    svc --> cache["キャッシュ（hostsを含む）"]
    cache -->|無ければ| dns["DNSサーバーへ問い合わせ"]
    cache -->|"無ければ・単一ラベル名（既定はDNSと並行）"| ll["LLMNR / NetBIOS"]
    svc -->|".local名（追加の経路）"| mdns["mDNS"]
    browser["ブラウザー"] -.->|独自リゾルバー・DoH| ext["別経路"]

キャッシュを先に見て、その先でDNSと、単一ラベル名ならLLMNR・NetBIOSが並行して動く。ブラウザーは別経路を持つ。

以下では「どこが答えるか」を3〜5章、「どう送るか」を6章、「どう確かめるか」を7〜8章に分けます。DoHはDNSサーバーへの輸送路をHTTPSに替える機能であり、hosts・キャッシュ・NRPTの順序を置き換えるものではありません。⁹

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全48件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 「名前解決」はひとつの処理ではない

アプリに返るのは、アドレスかエラーだけ

アプリがwww.example.comのような名前で接続するとき、Winsockのgetaddrinfo(Unicode版はGetAddrInfoW)が呼ばれます。この関数はNS_DNS名前空間に対して、DNS、ローカルのhostsファイル、その他の仕組みで名前をアドレスに変換します。複数の名前空間プロバイダーが応答すれば、それを集約して返します。¹⁰

つまり、アプリが結果を受け取っただけでは、どの層が答えたかまでは分かりません。

.NETのDns.GetHostAddressesも、Windowsではgetaddrinfoを使います。hostsに記述されたホストなら、DNSサーバーに問い合わせずそのアドレスを返します。HttpClientもこのDnsクラスの上で動くため、宛先へ直接接続する.NETアプリはWindowsの名前解決の順序を引き継ぎます。¹¹

HTTPプロキシ経由では、解決する名前が変わります。ローカルで解決するのはプロキシの名前で、宛先の名前はプロキシ側で解決されます。この場合、ローカルのhosts・キャッシュ・サフィックス・NRPTは宛先の解決に関与しません。どのプロキシ設定が使われるかはプロキシ記事で扱っています。

2.1 DNSクライアントサービスが順序を決める

getaddrinfoの下で働くのが、DNSクライアントサービス(サービス名Dnscache)です。Microsoftの資料は、基本の順序を次のように説明しています。³

1. キャッシュを確認する。
2. hostsファイルを確認する。
3. DNSサーバーに問い合わせる。

hostsの内容はサービス起動時にキャッシュへ読み込まれるため、本記事では最初の二つをまとめて第1層「キャッシュとhosts」として扱います。⁵

その先は、名前とポリシーによって分かれます。

既定の「スマートマルチホーム名前解決」は、DNS・LLMNR・NetBTの問い合わせを全ネットワークへ並行して出します。どの応答を採用するかは、4.3節と5.2節の規則で決まります。⁴

したがって、「問い合わせを出すタイミング」と「返った答えを採用する優先順位」は別の話です。キャプチャにLLMNRやNetBTが見えても、それだけで「DNSが失敗した」とは言えません。本記事の「3層」は整理のための区分であり、常に時間順に直列に動くという意味ではありません。

2.2 列の外にいるもの

特に混同しやすいのが、次の二つです。

Edgeの内蔵クライアントを使うこと自体は、DNSサーバーの変更を意味しません。別のプロバイダーを選ぶセキュアDNSの設定とは分けて、6.2節で確認します。

3. 第1層 ── キャッシュとhosts

この層で知りたいのは、PC内にどんな答えが残っているかです。キャッシュには、正しい答えだけでなく、古い答えや「名前が無い」という答えも残ります。

3.1 hostsはキャッシュに読み込まれる

hostsファイルはC:\Windows\System32\drivers\etc\hostsにあります。DNSクライアントサービスの起動時に、名前とIPアドレスの対応がリゾルバーキャッシュへ読み込まれます。DNSへの問い合わせで得たレコードも、TTL(生存時間)のあいだ同じキャッシュに保持されます。⁵

ipconfig /displaydnsには、hostsから読み込んだ項目と、最近のDNS問い合わせで得た項目の両方が表示されます。¹³ Microsoftの例でも、hostsにcontoso.comを書けばResolve-DnsName contoso.comはそのアドレスを返し、DNSの通信は流れません。³

DNSパケットが無いときの読み方

FQDNをDoH・DoTなしで引き、名前解決が成功しているのに53番の問い合わせが無ければ、キャッシュかhostsが答えていると考えられます。ただし、先に次の別経路を除外します。

「53番が無い」だけでキャッシュと決めつけず、使われ得る経路を併せて見ます。開発機に残った検証用hostsの1行が、調査を迷わせることもあります。

hostsの編集には管理者権限が必要で、変更をセキュリティ製品が検知する場合もあります。業務アプリの運用をhostsに依存させる設計は避けるべきです。

3.2 否定応答もキャッシュされる

「見つからなかった」も、キャッシュされる答えの一つです。DNSクライアントは肯定応答だけでなく否定応答も保存します。⁵

ipconfig /displaydnsで対象名に「Name does not exist」と表示されるなら、DNSサーバーの否定応答がクライアントに残っています。Microsoftの手順は、ipconfig /flushdnsでそれを捨てるよう案内しています。¹⁴¹³

否定キャッシュの保持時間は、HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\ParametersのMaxNegativeCacheTtlで、既定は5秒です。¹⁵ DNSにレコードを追加した直後でも、そのPCが数秒間は失敗を返すことがあるのはこのためです。

3.3 TTLと「一部のPCだけ古い」

肯定応答もTTLのあいだ残ります。サーバーのIPアドレスを変更する前に名前を引いたPCは古い答えを使い続け、変更後に初めて引いたPCは新しい答えを得ます。同じDNSサーバーを使っていても、引いた時刻が違えば結果は変わります。⁵

Clear-DnsClientCacheはipconfig /flushdnsと同じ動作で、否定応答を含むキャッシュの全内容を削除します。¹⁶ Get-DnsClientCacheなら、キャッシュをオブジェクトとして取り出し、レコード種別や残りTTLを確認できます。¹⁷

# 特定の名前がキャッシュにあるか、残りTTLは何秒か
Get-DnsClientCache -Entry 'app01.corp.example.com' |
    Select-Object Entry, Type, Status, TimeToLive, Data

# hostsとキャッシュの中身をまとめて確認
ipconfig /displaydns | Select-String -Pattern 'app01' -Context 0,6

# キャッシュを捨てる(否定応答も含めて)
Clear-DnsClientCache

第1層で答えが出れば、今回の検索はDNSサーバーに届く前に決まります。ただし、誤った答えを元々DNSサーバーから学習していた可能性は残ります。消して終わりにせず、8章の手順3で再取得した答えも確かめてください。

4. 第2層 ── DNSサーバーへの問い合わせ

第1層に答えが無ければDNSへ進みます。ここでは、何という名前を、どのサーバーへ、どのタイミングで送るかを分けて考えます。

4.1 単一ラベル名とサフィックス

まず、アプリが渡した名前の形を確認します。⁵

サフィックスは、短い名前の後ろに補うドメイン部分です。app01にcorp.example.comを付ければ、問い合わせる名前はapp01.corp.example.comになります。

検索リストがある場合

DNSサフィックス検索リストの先頭から順にサフィックスを付け、末尾に点を付けた名前を送ります。検索リストを構成すると、そのリストだけが使われます。プライマリサフィックス、接続固有サフィックス、名前の切り詰めは使われません。¹⁸

検索リストがない場合

プライマリDNSサフィックスを付けて送ります。名前の切り詰め(devolution)が有効なら、失敗するたびに左端のラベルを落として試します。たとえばwww.test.contoso.comからwww.contoso.comへ進みます。アダプターに接続固有のDNSサフィックスがあれば、それも付けて送ります。⁵

このため、グループポリシーで検索リストを配る環境と、ドメイン参加でプライマリサフィックスが付く環境では、同じserver01でも展開先が違います。

長いリストは待ち時間も増やす

正しいサフィックスがリストの後ろにあれば、そこに到達するまでの問い合わせ時間が積み上がります。Microsoftも、6つのサフィックスを試す例でこの遅延を説明しています。特定の展開結果だけを試すときは、internal.contoso.com.のように末尾に点を付けます。³

# 全体設定: 検索リストと切り詰め
Get-DnsClientGlobalSetting

# インターフェイスごと: 接続固有サフィックスと登録設定
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering

# インターフェイスごとのDNSサーバー(IPv4とIPv6の両方)
Get-DnsClientServerAddress | Where-Object ServerAddresses | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Get-DnsClientGlobalSettingは検索リストや切り詰めの有無・段数などの全体設定、Get-DnsClientはインターフェイスごとの設定を返します。¹⁹²⁰

4.2 複数DNSサーバーの順序とタイムアウト

「失敗しないが数秒待たされる」ときは、無応答のDNSサーバーへの再送を疑います。1枚のNICに設定したDNSサーバーについて、既定の再送タイミングを並べると次のようになります。²¹

これは応答が無い場合の表です。特に、次の二つを混同しないでください。

「片方を止めたのに切り替わらない」とき、古いゾーンを持ったサーバーが動き続けて否定応答を返していれば、次には進みません。²¹

4番目以降のサーバーには、4秒後まで届かない

応答できるサーバーがリストの4番目以降にあると、最初の問い合わせから最低4秒待ちます。アプリの期限がそれより短ければ、名前解決の段階で失敗します。問い合わせを早めるには先頭3つのどれかへ移す必要がありますが、根本対策は不達の先行サーバーを直すか、設定から外すことです。アプリ側のタイムアウトも見直します。²¹

Microsoftの例でも、4台中1台しか届かない構成では完了まで約4秒かかっています。Measure-Commandで所要時間を測れ、同資料は1秒未満を許容範囲としています。³

# 特定のサーバーに直接DNSだけで聞き、所要時間をミリ秒で得る
(Measure-Command {
    Resolve-DnsName -Name 'app01.corp.example.com' -Server 10.0.1.2 -DnsOnly
}).TotalMilliseconds

このコマンドはサーバーを固定するため、そのサーバー単体の応答時間を測ります。リストの4番目へ到達するまでの遅延は、-Serverを付けない問い合わせや、そのキャプチャで確認します。

なお、DNSクライアントは応答の速いサーバーを上位へ動かし、無応答のサーバーを記憶して定期的に再試行します。最初のタイムアウトも過去の実績から25〜1,000ミリ秒の範囲で調整されます。上の表は既定の骨格であり、実測にずれがあるのはこのためです。⁵

4.3 複数NICと「スマートマルチホーム名前解決」

有線とWi-Fiを持つPCや、VPNアダプターが加わるPCでは、DNSサーバーのリストだけでなくネットワーク間の問い合わせと応答の選択も確認します。

複数アダプターへの再送

Microsoftの問い合わせ手順では、優先アダプターの先頭のDNSサーバーへ送り、1秒待ちます。応答が無ければ、候補に残る全アダプターの先頭サーバーへ送って2秒待ち、その後は全アダプターの全サーバーへ、待ち時間を2秒・4秒・8秒と取りながら送ります。あるアダプターのサーバーが否定応答を返すと、そのアダプターの他のサーバーは候補から外れます。⁵

並行問い合わせを制御するポリシー

グループポリシー「スマート マルチホーム名前解決を無効にする」は、次の動作を制御します。⁴

「無効にする」という名前のポリシーなので、ポリシーを有効にすると最適化が無効になる点に注意してください。

VPNで結果が変わる例

社内名を聞いたとき、VPN側のDNSは社内アドレスを返し、自宅ルーター側のDNSも別の肯定応答を返すことがあります。社内と同じドメイン名の公開アドレスや、存在しない名前を置き換えた広告ページのアドレスなどです。

肯定応答が二つあれば、採用はバインド順で決まります。現在のWindowsでは、この優先順位はインターフェイスメトリックで決まり、Get-NetIPInterfaceのInterfaceMetricが小さいほど優先されます。PCごとの順序の違いが、結果の違いになります。²²

一方、自宅側が否定応答を返した場合は、そのアダプターが候補から外れ、VPN側の答えが使われます。⁵ VPN製品がNRPTや「スマート マルチホーム名前解決を無効にする」を配布するのは、こうした違いを制御するためです。

4.4 NRPT ── 名前空間ごとに問い合わせ先を変える

NRPT(Name Resolution Policy Table、名前解決ポリシーテーブル)は、.corp.contoso.comなどの名前空間ごとに、使うDNSサーバーやDirectAccess・DNSSECの設定を指定する表です。DirectAccessやAlways On VPNのプロファイルが規則を書き込み、「社内名だけ社内DNSへ向ける」といった動作を作ります。²³⁶

Get-DnsClientNrptPolicy -Effectiveで、実際に効いている規則を確認できます。

# 実際に効いているNRPTの規則
Get-DnsClientNrptPolicy -Effective

# 特定の名前空間の規則だけを表示する。-NamespaceはNamespace属性で絞るだけで、名前との一致判定はしない。
# 'app01.corp.example.com'を渡しても'.corp.example.com'のサフィックス規則は返らない。
# ある名前にどの規則が効くかは、8章の手順4のように規則を列挙して自分で照合する
Get-DnsClientNrptPolicy -Effective -Namespace '.corp.example.com'

NRPTが効くのは、Windows DNS APIを使うアプリだけです。独自のDNS実装を持つアプリは、その経路を迂回します。VPNv2 CSPの資料はnslookupを例に挙げ、NRPTの確認にはResolve-DnsNameを使うよう求めています。ブラウザーの内蔵リゾルバーやDoHも、Windows DNS APIの外側です。⁶

5. 第3層 ── 単一ラベル名の逃げ道: LLMNR・NetBIOS、そしてmDNS

5.1 三つのプロトコルの違い

LLMNRとNetBIOS over TCP/IP(NetBT)は、app01のような単一ラベル名を解決する別の手段です。既定ではDNSと並行して動き、DNSが肯定応答を返してもリンクローカルの応答が採用される場合があります。DNS失敗後の直列になるのは、スマートマルチホーム名前解決を無効にしたときだけです。⁴

mDNSはこれとは別で、.local名に加わる経路です。単一ラベル名のDNS解決に失敗した後の受け皿ではありません。²⁴

.localでも、DNSの確認を飛ばさない

.localがmDNS専用になるわけではありません。Active Directoryドメインがcorp.localなどの場合、その名前は引き続き設定済みDNSサーバーやNRPTでも解決されます。RFC 6762もユニキャストDNSとの併用を認めています。.local名の調査でも、DNSとVPNのポリシーを確認してください。²⁴

NetBTは、WINSの有無とノードタイプで変わる

WINS未構成ならB-node、1台でも構成されていればH-nodeが既定です。²⁹ LLMNRとNetBTのブロードキャストはサブネットを越えませんが、WINSへの問い合わせはユニキャストなので越えられます。

nbtstat -cでNetBIOS名キャッシュを表示し、nbtstat -Rでキャッシュの消去とLMHOSTSの再読み込みができます。³¹

5.2 どれが優先されるか

並行して問い合わせた後、どの応答を優先するかもポリシーで変わります。⁴

自宅や外出先のネットワークでは、同じ名前を持つ近くの機器の答えがDNSより優先されることがあります。ここでも、応答の優先順位と、問い合わせが直列か並行かを分けて読むことが大切です。

5.3 Microsoftの方針: mDNSへ寄せる

Microsoftは2022年4月、mDNSに揃え、NetBIOS名前解決とLLMNRを段階的に縮退させる方針を公表しました。²⁷ Computer Browserのような、古く安全でない機器探索プロトコルも非推奨になっています。³² 単一ラベル名をマルチキャストやブロードキャストで補う設計は、縮小していく方向です。

LLMNRの脆弱性に関するMicrosoftの情報は、回避策としてTCP/UDP 5355の遮断や、グループポリシー「マルチキャスト名前解決を無効にする」の有効化を挙げています。その影響として、コンピューターが他のコンピューターから見えなくなる場合があることも明記しています。²⁵ このポリシーを有効にすると、DNSクライアントの全アダプターでLLMNRが無効になります。⁴

無効化の方向自体は正しい判断ですが、消える経路の代わりをDNSに用意する必要があります。DNS未登録の機器はAレコードを登録するか、DHCPによる動的登録を有効にし、宛先をFQDNへ変更します。mDNS対応機器なら.local名を使えますが、届く範囲はマルチキャストが通る範囲に限られます。

5.4 「一部のPCだけ繋がらない」の典型: 単一ラベル名

設定ファイルやショートカットに\\fileserver01やhttp://app01/と書かれていると、同じ名前でも次の違いが出ます。

Resolve-DnsName app01 -LlmnrOnlyで分かるのは「LLMNRで解決できるか」です。普段の問い合わせで採用された答えの出所までは分かりません。スイッチなしの結果との比較やキャプチャは、8章の手順5で行います。⁸

根本対策はFQDN化とDNS登録

単一ラベル名に依存する宛先をFQDNへ変更し、名前解決をDNSに集約します。

SMB2以降はTCP 445で直接接続し、NetBIOSのセッションを使いません。³³ しかし、それは輸送路の話です。\\fileserver01\shareという宛先の名前を解決する段階では、LLMNRやNetBTが使われる場合があります。\\fileserver01.corp.example.com\shareのようにFQDNで指定して、単一ラベル名の経路への依存を外します。

ただし、FQDNにも次の注意が残ります。末尾に点のないFQDNは、複数ラベル名へのサフィックス付加ポリシーが有効なら補完も試されます。.localで終わる名前はmDNSを併用し得ます。無条件に固定するための絶対名は末尾に点を付けた形です。実務で「FQDNならDNSに固定される」と扱う前提は、上記ポリシーが無効で、社内ドメイン名に.localを使っていないことです。

6. DNSサーバーへの輸送路 ── DoHは順序を変えない

6.1 Windows 11 / Windows Server 2022のDoH

WindowsのDoHは、DNSサーバーへの問い合わせをHTTPSで送る機能です。既存のhosts・キャッシュ・NRPTや、アダプター・プロファイルごとのリゾルバー指定と統合され、3〜4章の順序は置き換えません。⁹

Windows 11のDNSクライアントはDoHに対応し、新しいバージョンではDoT(DNS over TLS)にも対応します。ただし、Microsoftの解説はDoTの対応バージョンを明示していないため、本記事の前提環境すべてで使えるとは限りません。以下ではDoHを扱います。⁹

まず、既知のDoHサーバー一覧を確認する

DDRを有効にしていない場合、使えるのは既知のDoHサーバー一覧に載ったサーバーです。既定の一覧にはCloudflare・Google・Quad9があり、Get-DnsClientDohServerAddressで確認できます。社内DNSなどは、DoHテンプレートとフォールバック・自動格上げの設定を登録します。¹³⁴

# 既知のDoHサーバー一覧
Get-DnsClientDohServerAddress

# 社内DNSをDoHサーバーとして登録(平文フォールバックなし・自動格上げあり)
Add-DnsClientDohServerAddress -ServerAddress '10.0.1.2' `
    -DohTemplate 'https://dns.corp.example.com/dns-query' `
    -AllowFallbackToUdp $false -AutoUpgrade $true

netsh dnsclient add encryptionでも登録できます。全体のnetsh dnsclient set global doh=yes|no|autoは、サーバーごとのautoupgradeとは別の設定です。³⁵

autoだけでは平文への復帰を禁止しません。失敗時にUDPへ戻すかは、サーバーごとのudpfallback、PowerShellでは-AllowFallbackToUdpが別に決めます。暗号化だけに限定するなら、フォールバックも無効にします。³⁵

DDRが有効なら、動的な発見経路もある

DDR(Discovery of Designated Resolvers)に対応したバージョンでは、平文で設定したリゾルバーが暗号化DNSのエンドポイントを通知できます。静的な一覧への登録なしに暗号化へ格上げされ得るため、「一覧に無いからDoHではない」とは言い切れません。³⁵

DDRが働くには、全体のnetsh dnsclient set global ddr=yesと、アダプターごとのset interface <名前> ddr=yesの両方が必要です。DDRで得た暗号化解決に失敗したときの平文復帰はddrfallbackで決まり、既定は無効です。

調査では既知一覧に加え、netsh dnsclient show globalとnetsh dnsclient show state、DNSサーバーを持つアダプターにset interfaceで設定した値を確認します。資料に定義されたshowはencryption・global・stateで、アダプター専用の表示サブコマンドはありません。³⁵

「許可」「要求」と平文への復帰を分ける

設定アプリではDNS設定を手動にし、優先DNSサーバーが既知一覧にあるときだけ「優先DNS暗号化」を選べます。選択肢は次の三つです。¹

グループポリシー「DNS over HTTPS (DoH) 名前解決の構成」には、許可・禁止・要求があります。許可の場合は、既知一覧への登録に加え、自動格上げ・アダプターの暗号化設定・全体のdoh=autoなどの条件でDoHを使います。「要求」ではDoH非対応サーバーによる名前解決そのものが失敗します。¹³⁵

ドメイン参加PCに「DoHを要求」を適用してはいけません。Microsoftは明確に注意しています。Active Directory Domain ServicesはDNSに強く依存し、Windows Server標準のDNSサーバーサービスがDoHの問い合わせに対応していないためです。¹

キャプチャでは、設定と実際の通信を分けて読む

実際にDoHで送った問い合わせはUDP 53ではなく、443番のTLSに入ります。ただし「DoHを許可」していても、既知一覧に無いサーバーへの問い合わせや、暗号化失敗後のフォールバックは平文で流れます。DoHの設定があるだけで、53番の通信が消えるわけではありません。

DNSの問い合わせが見えなければ、hosts・キャッシュに加えてDoHとDoT(853番)も確認します。採取方法はパケットキャプチャ記事を参照してください。

6.2 ブラウザーのDoHはOSと別物

Edgeの内蔵DNSクライアントと、セキュアDNSによる問い合わせ先の変更は、二段階に分けると理解しやすくなります。

内蔵クライアントはBuiltInDnsClientEnabledで制御し、DoHの問い合わせは常に内蔵リゾルバーが行います。⁷ セキュアDNSは組織管理下のPCでは既定で無効で、DnsOverHttpsMode(off / automatic / secure)とDnsOverHttpsTemplatesで構成します。³⁶³⁷

別のプロバイダーを選んだEdgeは、社外サイトを引けても社内DNSしか知らない名前を引けない場合があります。逆に、OSのDNSが不調でもEdgeだけは開けることがあります。現在のプロバイダーのままなら、問い合わせ先が変わるわけではありません。

結論は、ブラウザーの成功と業務アプリの成功を、同じ経路の証拠として扱わないことです。OSの経路はResolve-DnsNameかpingで確かめます。

7. アプリはどの経路を通るのか

調査に使うツールを選ぶ前に、見ている経路を揃えます。

Resolve-DnsNameの主なスイッチを、調査目的で整理すると次のようになります。⁸

7.1 AとAAAA、IPv6が先に返る

名前解決が成功していても、その後のアドレス選択で接続が遅くなる場合があります。

DNSクライアントはA(IPv4)とAAAA(IPv6)の両方を問い合わせます。キャプチャでも両方の問い合わせが対で見えます。³ 答えを返した後に、getaddrinfoと接続側のスタックが使うアドレスを選びます。Windows Vista以降はRFC 3484のプレフィックステーブルを使い、既定ではIPv6のグローバルユニキャストをIPv4より優先します。³⁸

ただし、AAAAが返っただけで、必ずIPv6接続を試すわけではありません。宛先選択では、IPv6の送信元アドレスや経路が無いなど、使えない宛先を先に外してから候補を並べます。³⁹

問題になるのは、IPv6の送信元アドレスと経路が一見あるのに、実際には通らない環境です。名前解決は成功していても、接続で時間を失います。IPv6が本当に試されたかは、DNS応答だけでなく接続ログやキャプチャで確認します。

Microsoftは対処としてIPv6を無効化することを推奨していません。Windowsの一部コンポーネントが動かなくなるためです。代わりにDisabledComponentsを0x20にして、プレフィックスポリシーでIPv4を優先する方法を案内しています。³⁸ localhostが::1に解決され、127.0.0.1を想定した調査と食い違う例は、パケットキャプチャ記事でも扱っています。

8. 切り分け手順 ── 層を上から順に剥がす

繋がらないPCで、次の順に実行します。各コマンドは経路を限定するためのものであり、成功しただけで普段の解決経路まで証明できるわけではありません。結果の比較と、最後のキャプチャを組み合わせます。

手順1: 名前の形を確認する

ログか設定ファイルで、アプリが実際に渡している名前を確認します。単一ラベル名か、.localで終わるか、末尾に点があるかで経路が変わります。http://app01/のような短い名前なら、4.1節の補完と5.4節のPCごとの違いから調べます。

手順2: キャッシュとhostsだけで解決できるか

Resolve-DnsName -Name 'app01.corp.example.com' -CacheOnly
Get-DnsClientCache -Entry 'app01.corp.example.com'
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String -Pattern 'app01'

-CacheOnlyは今回の検索をローカルキャッシュに限定するだけです。誤った答えをDNSサーバーから学習していれば、消しても同じ値が戻ります。キャッシュにあったことは、DNSサーバーが無関係である証明にはなりません。⁸

手順3: DNSだけで解決できるか

# hostsを外し、LLMNR/NetBIOSも出さず、設定済みDNSサーバーだけで引く
Resolve-DnsName -Name 'app01.corp.example.com' -NoHostsFile -DnsOnly

手順2で答えが無く、ここで成功しただけなら、多くは通常のキャッシュミスです。キャッシュやhostsの問題と言えるのは、手順2に古い答え、誤った答え、否定キャッシュがあった場合です。

ここでも失敗するなら、DNSサーバーへの経路、サーバー側、クライアント側のポリシーを調べます。手順4へ進む前に、次を確認してください。

• Get-DnsClientNrptPolicy -Effective: 別のDNSサーバーへ向ける規則がないか。
• Get-DnsClientDohServerAddressとDoHのグループポリシー: 非対応サーバーに「DoHを要求」していないか。

NRPTがあれば手順4の対象サーバーが変わります。「DoHを要求」が原因なら、経路もサーバーも健全なまま名前解決だけが失敗します。4.4節・6.1節の確認を先に済ませます。

手順4: サーバーごとに直接聞く

接続中のアダプターのDNSサーバーを集め、対象名にNRPTが効く場合は、その規則のサーバーへ置き換えます。IPv6だけで設定されたDNSサーバーも対象にします。

$name = 'app01.corp.example.com'
# 接続中のインターフェイスのDNSサーバーをIPv4・IPv6の両方から集める。
# 切断中のVPNや仮想スイッチに残った設定のサーバーは今の解決経路に関わらないので除く(IPv6だけで設定されたサーバーは見落とさない)
$connected = @((Get-NetIPInterface -ConnectionState Connected).ifIndex | Select-Object -Unique)
$servers = @((Get-DnsClientServerAddress |
    Where-Object { $_.ServerAddresses -and ($connected -contains $_.InterfaceIndex) }).ServerAddresses)
# この名前に効いているNRPTの規則のサーバー(Always On VPNやDirectAccessが書き込むもの)はアダプターの設定に現れないので、実効ポリシーから選ぶ。
# Get-DnsClientNrptPolicyの-Namespaceは規則のNamespace属性で絞るだけで、名前との一致判定はしない。
# そこでAny規則(.)・サフィックス規則(先頭が点。名前空間そのものと子ドメインに効く)・FQDN規則・プレフィックス規則(ホスト名部分。web*のようなワイルドカードも可)を自分で照合し、
# より具体的な(長い)規則を採用する。Any規則は最も短いので、他に一致する規則が無いときだけ選ばれる
# Namespaceは文字列の集合(Namespace : {.corp.example.com}のように表示される)なので、規則ごとに要素を展開して照合し、一致した名前空間の長さで並べる
# 末尾に点を付けた絶対名(app01.corp.example.com.)は照合のときだけ点を外す。Resolve-DnsNameには元の$nameを渡す
$matchName = $name.TrimEnd('.')
$label = $matchName.Split('.')[0]
$matched = foreach ($policy in @(Get-DnsClientNrptPolicy -Effective)) {
    foreach ($ns in @($policy.Namespace)) {
        if (-not $ns) { continue }
        $hit = if ($ns -eq '.') { $true }
               elseif ($ns.StartsWith('.')) { $matchName.Equals($ns.TrimStart('.'), [System.StringComparison]::OrdinalIgnoreCase) -or $matchName.EndsWith($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               elseif ($ns.Contains('.')) { $matchName.Equals($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               else { $label -like $ns }
        if ($hit) { [pscustomobject]@{ Namespace = $ns; Policy = $policy } }
    }
}
$rule = $matched | Sort-Object { $_.Namespace.Length } -Descending | Select-Object -First 1
$policyServers = @()
if ($rule) { $policyServers = @(@($rule.Policy.NameServers) + @($rule.Policy.DirectAccessDnsServers) | Where-Object { $_ }) }
if ($policyServers.Count -gt 0) {
    # NRPTがこの名前空間のサーバーを指定しているなら、手順3の問い合わせはそのサーバーへ向かう。アダプターのサーバーは経路の外なので置き換える
    $servers = $policyServers
}
$servers = $servers | Where-Object { $_ } | Select-Object -Unique
foreach ($server in $servers) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $r = Resolve-DnsName -Name $name -Server $server -DnsOnly -ErrorAction Stop
        $status = 'OK'
        # 複数レコードは応答ごとに並びが変わり得るので、並べ替えてから比較する
        $answer = ($r.IPAddress | Sort-Object) -join ','
    } catch {
        # 否定応答(名前が無い)・SERVFAIL・タイムアウトはここに来る。理由を捨てずに残す
        $status = $_.Exception.Message
        $answer = ''
    }
    [pscustomobject]@{ Server = $server; Status = $status; Answer = $answer; Milliseconds = [int]$sw.ElapsedMilliseconds }
}

まず、比較するサーバーを揃える

NRPTのNameServersやDirectAccessDnsServersは、アダプターのDNS設定には現れない場合があります。手順3でNRPTのサーバーへ聞いているのに、手順4でアダプターのサーバーだけを調べては、別の経路を比較してしまいます。

NRPTにはサフィックス、FQDN、プレフィックス、Any(.)などの規則があり、より具体的な規則が優先されます。⁴⁰ -Namespaceは規則の属性で絞るだけで、ホスト名との一致判定はしません。そこで、上のコードは規則の名前空間を展開し、対象名と照合しています。²³

分割DNSのVPNでは、自宅側のリゾルバーが社内名に否定応答を返し、NRPT側だけが肯定応答を返すのは正常です。経路外のサーバーも比較する場合は「対照」として別に記録し、ゾーンの不一致の判定には混ぜません。切断中のアダプターに残るサーバーへのタイムアウトも、現在の解決経路の遅延とは別です。

次に、結果を読み分ける

集合でも違うなら、ゾーンの内容やシリアル番号を確認します。また、ここは-Serverで宛先を固定した測定です。4.2節の「4番目以降に届くまで4秒」というリスト位置による遅延は、手順3やそのキャプチャで確認します。

手順5: リンクローカルの層を確認する

Resolve-DnsName -Name 'app01' -LlmnrOnly          # LLMNRだけ
Resolve-DnsName -Name 'app01' -LlmnrNetbiosOnly   # LLMNRかNetBIOSだけ(DNSは使わない)
nbtstat -c                                        # NetBIOS名キャッシュ

この確認は単一ラベル名が対象です。-NetbiosFallbackはDNS失敗時だけNetBIOSへ落とすため、DNSで引ける名前ではNetBIOSの確認になりません。⁸

結果は次のように読みます。

どちらのプロトコルが答えたかは、キャプチャでUDP 5355(LLMNR)とUDP 137(NetBT)を見分けます。普段の解決経路を確かめるには、スイッチなしのResolve-DnsNameが返すアドレスとも比較し、食い違う場合はキャプチャで採用された応答を確認します。既定ではDNSも並行して問い合わせられるためです。

手順6: 設定ダンプの差分を取る

「一部のPCだけ」の調査では、繋がるPCと繋がらないPCで同じスクリプトを実行して比較します。

# name-resolution-dump.ps1 -- 管理者権限で実行し、出力ファイルを2台分並べて比較する
$out = "$env:COMPUTERNAME-name-resolution.txt"
$sections = [ordered]@{
    'Get-DnsClientServerAddress' = { Get-DnsClientServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'Get-DnsClientGlobalSetting' = { Get-DnsClientGlobalSetting | Format-List | Out-String }
    'Get-DnsClient'              = { Get-DnsClient | Format-Table InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering -AutoSize | Out-String -Width 200 }
    'Get-DnsClientNrptPolicy'    = { Get-DnsClientNrptPolicy -Effective | Format-List | Out-String }
    'Get-DnsClientDohServerAddress' = { Get-DnsClientDohServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'netsh dnsclient show state' = { netsh dnsclient show state 2>&1 | Out-String }
    'Get-NetIPInterface'         = { Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table InterfaceAlias, AddressFamily, InterfaceMetric, ConnectionState, Dhcp -AutoSize | Out-String -Width 200 }
    'DNSClient policy registry'  = { Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue | Format-List | Out-String }
    'ipconfig /all'              = { ipconfig /all | Out-String }
}
$sections.GetEnumerator() | ForEach-Object {
    "===== $($_.Key) ====="
    try { & $_.Value } catch { "ERROR: $($_.Exception.Message)" }  # 無い項目(Windows 10のDoHなど)はエラーとして残す
} | Set-Content -Path $out -Encoding UTF8
Write-Host "wrote $out"

比較するのは、DNSサーバーの並び、検索リスト、接続固有サフィックス、NRPT、DoH、インターフェイスメトリック、ポリシー値です。

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClientには、「マルチキャスト名前解決を無効にする」のEnableMulticast、「スマート マルチホーム名前解決を無効にする」のDisableSmartNameResolution、検索リストやプライマリサフィックスなどが入ります。⁴ 差分を、ここまで整理した各層の働きと照らし合わせます。

手順7: パケットキャプチャで裏を取る

Microsoftのデータ収集手順は、クライアントとサーバーの両側でnetsh trace start capture=yesを開始し、ipconfig /flushdnsでキャッシュを捨ててから再現し、netsh trace stopで止める流れです。⁴¹

Wiresharkでは、dns.qry.name == "app01.corp.example.com"やdns.qry.name contains "app01"で絞り、どのサーバーに何を聞き、何が返ったかを確認します。

送信側のファイアウォールでUDP 53を遮断している場合、Resolve-DnsNameはタイムアウトし、キャプチャにもDNSの問い合わせが現れません。名前解決が成功して通信が出ない場合だけでなく、失敗して通信が出ない場合も切り分けます。³

DNS以外も、LLMNRは5355、mDNSはUDP 5353、NetBTの名前サービスはUDP 137を確認します。DoHは443、DoTは853です。キャプチャの採取と読み方はパケットキャプチャ記事にまとめています。

9. 業務アプリ側の設計 ── 名前解決に強くする

調査を軽くするには、アプリ側が「何という名前を、何に解決し、どこで失敗したか」を残せることが重要です。アプリのログと、情シスが採る設定ダンプ・キャプチャを突き合わせれば、8章のどこから調べるかを決めやすくなります。

宛先はFQDNで持ち、hostsに依存しない

設定ファイルの既定値、ショートカット、UNCパスはFQDNにします。単一ラベル名のサフィックス補完やLLMNR・NetBTへの依存を外すためです。ただし、.local名のmDNS併用と、末尾に点のない名前へのサフィックス付加ポリシーという5.4節の注意は残ります。

hostsは開発中の一時的な上書きには便利ですが、管理者権限と手作業が必要です。配布や変更履歴を管理しにくく、リゾルバーによっては参照もしません(nslookupは参照しません¹²)。宛先の切り替えは設定ファイルで行います。

名前解決の結果・時間・失敗理由を記録する

起動時などに、主要な宛先のIPv4・IPv6アドレスと所要時間を記録します。Dns.GetHostAddressesはgetaddrinfoと同じ結果を返すため、「どのPCで、いつから、何に解決されていたか」を追えます。¹¹

// 起動時に主要な宛先の名前解決結果を記録する(.NET 6以降)
static async Task LogNameResolutionAsync(ILogger logger, string host)
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var addresses = await System.Net.Dns.GetHostAddressesAsync(host);
        logger.LogInformation("名前解決 {Host} -> {Addresses} ({Elapsed} ms)",
            host, string.Join(",", addresses.Select(a => a.ToString())), sw.ElapsedMilliseconds);
    }
    catch (System.Net.Sockets.SocketException ex)
    {
        logger.LogError(ex, "名前解決失敗 {Host} エラー {Code} ({Elapsed} ms)",
            host, ex.SocketErrorCode, sw.ElapsedMilliseconds);
        throw;
    }
}

失敗はログに残して投げ直します。別の名前や固定IPへ黙って切り替えると、調査時に実際の経路が分からなくなるためです。エラーコードと所要時間があれば、情シスは手順2〜4のどこから始めるかを判断できます。

タイムアウトとIPv6の答えを見込む

DNSクライアントは、無応答のサーバーに対して問い合わせる候補一つあたり最大10秒を使います。²¹ サフィックス検索で候補が複数になれば、全体では10秒を超えることもあります。

接続タイムアウトを2〜3秒に詰めると、答えられるサーバーが4番目以降にある構成などでは、期限までに名前解決が終わりません。ただし2台目には1秒後、3台目には2秒後に問い合わせるため、1台落ちただけで必ず失敗するわけではありません。4.2節の再送時間を踏まえて設計します。

また、AAAAが返り、IPv6の送信元アドレスと経路があれば、Windowsは既定でIPv6を優先します。³⁸ IPv4だけを想定した接続コードでは、名前解決に成功したのに接続に失敗することがあります。名前解決の成功と接続の成功を分け、両方のアドレスを扱えるようにします。

10. まとめ

Windowsの名前解決で最初に分けるのは、名前の形、答えを返す層、アプリが通る経路です。

キャッシュとhostsが先に答え、単一ラベル名では既定でDNSとLLMNR・NetBTが並行して動きます。.localにはmDNSも加わります。DNSへ進んだ後は、サフィックス、再送時間、複数NIC、NRPTが結果を変えます。DoHはその輸送路を替える機能で、ブラウザーの内蔵リゾルバーとは分けて考えます。

調査は-CacheOnly→-NoHostsFile -DnsOnly→-Server→-LlmnrOnlyの順で経路を限定し、設定ダンプの差分とキャプチャで確かめます。否定キャッシュ、無応答と否定応答の違い、クライアント側のポリシーを見落とさないことが重要です。

「このPCだけ繋がらない」ときは、まず次の二つを確認してください。

その名前は、どの形で渡されていますか。そのPCでは、どの経路が答えていますか。

この二つを揃えると、調べる場所を絞れます。

関連記事

• Windowsのパケットキャプチャ実務 ── pktmon・netsh trace・Wiresharkの使い分け
• 社内プロキシとWindowsアプリ ── WinINET・WinHTTP・.NETのプロキシ解決を整理する
• HttpClientをusingで囲んではいけない ── C#業務アプリのHTTP通信実務(生成パターン・タイムアウト・リトライ)
• Windowsファイアウォールと業務アプリ ── 受信規則はインストーラーで登録する
• ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダー)を扱う
• 図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか
• PowerShell実用コマンド集 ── 日常作業でよく使う小さな機能を増やす

関連する相談領域

合同会社小村ソフトでは、「一部のPCだけ業務アプリが社内サーバーに繋がらない」「ブラウザーでは開けるのにアプリでは名前解決に失敗する」といった名前解決起因の通信トラブルの原因調査、LLMNR無効化・DoH・VPNといった環境変更に業務アプリが耐えられるかの設計レビュー、名前解決の結果とタイムアウトを記録する通信層の実装を扱っています。繋がるPCと繋がらないPCの設定ダンプを添えてご相談いただければ、調査の入口が早く決まります。

• 不具合調査・原因解析
• 技術相談・設計レビュー
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

hostsファイルを書き換えたのに反映されません。なぜですか？

Windowsのhostsファイルの内容はDNSクライアントサービスの起動時にキャッシュへ読み込まれ、名前解決はキャッシュ→hosts→DNSサーバーの順で進みます。反映されないときは、まずipconfig /displaydnsでその名前の項目を確認し、古い応答が残っていればipconfig /flushdnsで捨ててください。次に、調べているツールがWindowsのリゾルバーを通っているかを疑います。nslookupはOSのリゾルバーを使わず、キャッシュもhostsもNRPTも素通りしてDNSサーバーに直接問い合わせるため、hostsの内容は一切反映されません。hostsを含めた実際の解決結果を見るにはResolve-DnsNameかpingを使ってください。それでも反映されないなら、ブラウザーのように独自のリゾルバーやDoHを持つアプリかどうかを確認します。

ブラウザーではサイトが開けるのに、業務アプリだけ名前解決に失敗します。

ブラウザーとアプリが違う経路で名前を引いている可能性が高い状態です。Microsoft Edgeは、既定でOSのDNSクライアントではなく内蔵のDNSクライアントでDNSサーバーと通信し、セキュアDNS(DoH)で別のプロバイダーを選べば外部のリゾルバーに問い合わせます。一方、.NETのDns.GetHostAddressesや、宛先に直接接続するHttpClientはOSのgetaddrinfoを通るので、hosts・DNSキャッシュ・NRPT・サフィックス検索リストの影響をすべて受けます(HTTPプロキシ経由の要求では宛先の名前はプロキシ側で解決されます)。両者が別の答えを返す場合、どちらの経路がどのDNSサーバーに何を聞いたかをResolve-DnsNameとパケットキャプチャで突き合わせるのが最短です。

同じ設定のはずなのに、一部のPCだけ社内サーバーに繋がりません。何を比べればよいですか？

名前の形と、そのPCがどの層で答えを得ているかを比べます。単一ラベル名(server01のような点を含まない名前)は、PCのDNSサフィックス検索リストや接続固有のサフィックスで補われてDNSに送られ、既定ではそれと並行にLLMNRやNetBIOSブロードキャストといった同一サブネット限定の手段にも問い合わせられます(DNSの失敗後に順に試されるのは最適化を無効にしたときだけです。WINSが構成されていればNetBIOSはユニキャストでサブネットを越えられます)。ドメイン参加PCはサフィックスでFQDNに補完されて解決できても、VPN経由や別サブネットのPC、LLMNRとNetBIOSを無効化したPCでは同じ名前が解決できません。繋がるPCと繋がらないPCの両方でGet-DnsClientServerAddress・Get-DnsClientGlobalSetting・Get-DnsClient・Get-DnsClientNrptPolicy -Effectiveの出力を採り、差分を取るのが確実です。根本対策は、設定ファイルやショートカットの宛先をFQDNにすることです。

名前解決が失敗するのではなく、数秒待たされてからやっと繋がります。原因は何ですか？

DNSクライアントのタイムアウトとリトライの仕組みが表に出ている状態です。Windowsは応答のないDNSサーバーに対して開始から1秒・2秒・4秒・8秒の時点で再送し、10秒で打ち切ります。複数のDNSサーバーを設定していても、応答があるサーバーがリストの4番目以降にあると、最低4秒待ってからでないとそのサーバーに問い合わせません。また、長いDNSサフィックス検索リストは、単一ラベル名の解決でサフィックスを順に試すぶんだけ遅延を積み上げます。Measure-CommandでResolve-DnsNameの所要時間を測り、Wiresharkでdns.qry.nameのフィルターをかけて、どのサーバーへの問い合わせが無応答になっているかを見てください。

セキュリティ対策でLLMNRとNetBIOSを無効化したら、一部の機器に名前で繋がらなくなりました。

想定される副作用です。LLMNRとNetBIOS over TCP/IPは、DNSに登録されていない機器の単一ラベル名を同一サブネット内で解決する二次的な手段で、無効化すればその経路が消えます。Microsoft自身も2022年にmDNSへ寄せてNetBIOS名前解決とLLMNRを段階的に縮退させる方針を示しており、無効化の方向自体は正しい判断です。対策は名前解決をDNSに集約することで、機器のAレコードを社内DNSに登録するか、DHCPによる動的登録を有効にし、アプリや共有の宛先をFQDNに書き換えます。mDNSに対応した機器なら.local名で解決できますが、こちらもマルチキャストが届く範囲に限られます。

Windows 11のDoH(DNS over HTTPS)を有効にすると、社内の名前解決はどうなりますか？

DoHは、DNSクライアントが設定済みのDNSサーバーへ問い合わせる際の輸送路をHTTPSに替える機能で、hosts・キャッシュ・NRPTといった既存の順序はそのまま生きます。DoHが使えるのは、DDR(Discovery of Designated Resolvers)を有効にしていなければ、そのサーバーが既知のDoHサーバーの一覧に載っている場合だけで、社内DNSを使うなら管理者がAdd-DnsClientDohServerAddressで登録する必要があります。グループポリシーの「DNS over HTTPS (DoH) 名前解決の構成」で「DoHを要求する」にすると、DoH非対応のサーバーでは名前解決そのものが失敗します。Microsoftはドメイン参加PCでこの設定を有効にしないよう明記しています。Active Directoryが依存するWindows Server標準のDNSサーバーサービスがDoHの問い合わせに対応していないためです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。