1 疎通確認の概要
1.1 目的と期待される成果
疎通確認は、通信経路や機器、サービスが意図した振る舞いを示すかを、手順化された観点で検証する作業である。単なる「つながった／つながらない」の判断にとどまらず、正常時に期待される品質（応答性、エラー率、欠損の有無など）が許容範囲に入っているかを確かめることが中核になる。
期待される成果は、(1) 早期に障害を発見できること、(2) 原因を再現可能な形で切り分けられること、(3) 運用者や保守担当が同じ手順で状況を確認できること、の3点に整理できる。
1.2 対象範囲（機器・経路・サービス）
対象は、物理層からアプリ層までの広い領域に及ぶ。代表的には、端末やサーバ、ルータやスイッチ、無線アクセスポイント、ゲートウェイ、経路制御機構、認証や名前解決を含む上位サービスが挙げられる。
また「どこまでを疎通確認とみなすか」は、運用の目的により異なる。例えば、配線とリンクが成立しているかを確認するだけでよいケースもあれば、特定のアプリ処理が完了するところまで求めるケースもある。したがって、対象範囲は開始前に明確化する必要がある。
1.3 成功条件と評価指標
成功条件は、可用性と品質の両方に基づいて定義される。可用性については「到達可能か」「接続が確立するか」が中心となる。品質については遅延、スループット、ジッタ、パケット欠損、リトライ回数、エラー応答の頻度などを評価指標として扱う。
評価指標は数値化し、許容上限または目標値を定めるのが望ましい。さらに、測定頻度や観測窓（短時間か、長時間か）も成功判定に影響するため、運用要件として記載しておくと判断のブレを抑えられる。
2 確認の手順
2.1 初期確認（物理・基本接続）
2.1.1 ケーブル・配線・端子の確認
初期段階では、物理的な接続の確実性を点検する。具体的には、ケーブルの差し込み状態、端子の損傷や緩み、配線の誤接続（別ポートへの接続、誤った回線の使用）、コネクタの種類の不一致（規格やカテゴリの相違）などを確認する。
無線の場合は、アクセスポイントの電源、アンテナの向き、想定した無線バンドやチャネル設定、設置環境による減衰を見直す。物理の誤りは再現性のない不安定さを生みやすいため、まずここを固める。
2.1.2 電源・リンク状態の確認
次に電源投入とリンク状態を確認する。有線ならリンクアップしているか、速度・デュプレックスが期待値に入っているか、エラーカウンタに異常がないかを見る。機器が対応していない速度設定でリンクが成立している場合、下位互換で落ちていることがあるため注意が必要である。
無線ではビーコンの受信、リンク品質指標、電波強度といった状態情報を参照し、端末側とアクセスポイント側で整合しているかを確認する。ここでの不一致は、無線の設定変更や電波環境の変化を示唆する。
2.1.1.1 ネットワークリンクの速度や稼働状態の把握
リンク速度、稼働状況、リロード頻度（再ネゴシエーションの回数）を把握すると、性能低下の兆候を早期に捉えられる。例えば、想定より低い速度で固定されている、一定間隔でリンクが揺らいでいる、リンク断が断続的に発生している等は、ケーブル品質やポート設定、電源供給の問題につながることがある。
また、管理画面やCLIで取得できるインタフェース統計（受信・送信エラー、廃棄数）を参照し、物理側の劣化を優先して検討する判断材料にする。
2.2 論理確認（アドレス・名前解決）
2.2.1 IPアドレス設定と経路情報の確認
論理確認では、端末や中継装置に設定されたアドレス情報と経路制御の整合性を確認する。まず、IPアドレスとサブネットマスクが所属ネットワークとして妥当か、デフォルトゲートウェイが正しく設定されているかを確認する。
加えて、経路テーブル（スタティック経路、動的経路の学習状況）やルーティングポリシーが期待通りであるかを検証する。誤った経路が優先されると、到達性は断続的に見えたり、近い相手だけ到達できたりするため、経路選択の根拠を確認することが重要になる。
2.2.2 名前解決（DNS等）の確認
名前解決は、ホスト名から到達先のアドレスを得る過程である。DNSサーバ設定（参照先、タイムアウト、再試行回数）が正しいか、権威情報とキャッシュの整合が崩れていないかを確認する。
また、名前解決が機能しているように見えても、特定ドメインだけ失敗する、順序付きの検索が別のゾーンに誘導される、といったパターンがある。したがって、対象の名前を複数の観点で確認し、結果が安定しているかを点検する。
2.3 応答確認（到達性）
2.3.1 基本的な疎通（ping等）による到達確認
到達性の基礎として、ICMPエコー等の疎通ツールを用いて相手に通信できるかを確認する。ここで得られるのは「応答がある／ない」だけであり、アプリ層までの完全な正常性を保証しない点に留意が必要である。
それでも、応答の有無、応答時間の分布、欠損の程度は、経路の成立や混雑の兆候を把握する手がかりになる。ICMPが抑制されている環境では別手段に切り替える判断が求められる。
2.3.2 ポート疎通（接続可否）の確認
次に、特定のサービスが利用できるかを確認するため、ポートレベルでの疎通を行う。TCPなら接続が確立するか、UDPならアプリプロトコルに準じたやり取りが成立するかを確認する。
同じホストでも、ポートごとに到達性が異なることがある。ファイアウォール設定、ルーティングの対象範囲、NATの振る舞いなどが影響するため、必要なサービスに対応したポートを選び、結果を記録する。
3 テスト方法と代表的な手段
3.1 ユーザー環境での確認
3.1.1 ブラウザ接続・アプリ疎通の確認
ユーザー視点では、ブラウザの画面遷移やアプリの機能が成立するかを直接確認することが有効である。ウェブならDNS解決からHTTP取引までを一連で観測でき、アプリは認証、セッション維持、データ取得といった一連の処理の完了を検証できる。
一方で、ユーザー環境は端末設定、キャッシュ、プロキシの存在など外部要因が混ざりやすい。したがって、可能なら再現条件（同一端末、同一ネットワーク、同一経路）を揃え、観測結果の比較可能性を確保する。
3.1.2 障害時の表示・ログ確認
障害発生時には、クライアントが表示するエラー種別（タイムアウト、証明書エラー、接続失敗など）と、アプリやOSのログを照合する。表示文言だけでは原因の特定が難しい場合があるため、時間帯と操作手順を合わせたログの確認が重要となる。
また、同時多発的な障害ではなく、特定サービスだけ失敗する場合がある。そのため、エラーコードのパターンを整理し、他の機能は正常か、同じネットワーク内で現象が再現するかを切り分ける。
3.2 管理者向けの確認
3.2.1 診断コマンドと手順
管理者向けの確認では、ネットワーク状況を観測するための診断コマンドを体系的に適用する。一般に、インタフェース状態の参照、経路表の確認、名前解決のテスト、疎通試験、稼働プロセスの点検などを段階的に実施する。
手順のポイントは、観測→仮説→再観測の流れを維持することである。例えば、リンク異常が疑われる場合はインタフェース統計を先に確認し、改善がなされてから経路や応答の確認へ進む。こうすると、作業の順番による誤診を減らせる。
3.2.2 監視ツール・通知の活用
3.2.1.1 ダッシュボードでの状態把握とアラート確認
監視ツールは、疎通確認を継続運用へ拡張する役割を担う。ダッシュボードでは、到達性チェックの成功率、応答時間の推移、エラー数、リンク状態、リソース使用量などを時系列で可視化し、異常の発生タイミングを特定する。
アラートは闇雲な通知を避けるため、閾値や抑制条件、通知経路を適切に設定する。ダッシュボード上の兆候とアラートの条件が整合しているかを定期的に見直すことで、取りこぼしや誤警報の双方を減らせる。
4 トラブルシューティング
4.1 よくある原因の分類
4.1.1 誤設定（アドレス・ゲートウェイ等）
誤設定は頻度が高く、症状が多様になりやすい。代表例として、サブネットの誤り、デフォルトゲートウェイの相違、誤ったDNS参照先、重複アドレスの発生、MTU不整合などがある。
これらは「特定の宛先だけ到達できない」「名前解決だけ失敗する」「小さな通信は動くが大きい通信で崩れる」といった形で表面化することが多い。設定変更履歴と対応づけることで、原因推定の精度を高められる。
4.1.2 ネットワーク混雑・性能劣化
混雑や性能低下では、リンク自体は成立していても、遅延の増大や欠損、再送の増加が起きる。原因としては回線の混雑、バッファ飽和、帯域制御、輻輳制御の不適合、過剰なトラフィック集中などが考えられる。
疎通確認の結果では、到達性は維持される一方で応答時間が伸びる、特定時間帯に悪化する、といった傾向が見える。統計の時間窓を揃えて比較することが重要になる。
4.1.3 機器不良・ケーブル不良
物理部品の劣化や故障は、断続的なリンクダウン、エラー増加、再接続の頻発として観測されることが多い。ケーブルの損傷、規格外品の使用、端子の接触不良、ポート故障、電源の不安定などが該当する。
この種の問題は、再現条件に依存して見逃されやすい。温度変化や振動、配線取り回しの変更で症状が現れる場合があるため、現場での観察と測定値の突合が求められる。
4.2 切り分けの考え方
4.2.1 層（物理・リンク・ネットワーク・アプリ）の整理
切り分けは層構造に沿って進めると整理しやすい。まず物理・リンクで成立しているか、次にネットワーク到達（経路やアドレス）で成立しているか、最後にアプリ処理（プロトコルや認証）で成立するかを順番に確認する。
この順序により、原因を絞り込みやすくなる。例えば、名前解決やポート接続で失敗する場合は上位アプリ以前の問題と判断できる一方、到達は可能でも処理が完了しない場合はアプリ側設定やデータ整合性が疑わしい。
4.2.2 既知の正常条件との比較
比較の基準として、既知の正常状態を保存しておくと効果が高い。正常時の設定値、インタフェース速度、経路表の代表的な内容、疎通の応答時間分布などを参照し、差分を観測する。
また、同一機器でも個体差や設置条件が異なることがあるため、比較対象は同等条件を選ぶのが望ましい。比較の設計が甘いと誤った結論に導かれやすい。
4.3 証拠の残し方（ログと結果）
4.3.1 検証結果の記録様式
検証結果は、観測時刻、実行した手順、対象（IP、ホスト名、装置名、ポート）、結果（成功/失敗、数値）、環境条件（ネットワーク種別、負荷状況）を体系的に記録する。これにより、後から判断を追跡できるだけでなく、別担当者が再調査できるようになる。
記録は簡潔であっても、再現に必要な情報を欠かないことが重要である。特に失敗時のエラー文やコード、タイムスタンプの一致は、証拠としての価値が高い。
4.3.2 再現手順の整理
再現手順は「誰が、どの条件で、何を実行し、何を観測するか」を明確にする。例えば、疎通確認であれば対象数、実施回数、待ち時間、測定ツール、パラメータ（タイムアウトやパケットサイズ等）を揃える。
また、検証の前後で設定変更が入っている場合は、それも手順に反映する。再現条件が揃わないと、検証結果が相互に比較できず、原因の確定が遅れる。
5 運用とガバナンス
5.1 定期点検と閾値管理
定期点検では、疎通確認を計画的に実施し、異常の早期検出につなげる。点検対象、頻度、実施時間帯、結果の保管期間などを運用規程に落とし込む。
閾値管理は、通知の過不足を左右する。単一指標の上限だけでなく、遅延の傾向変化や急増検知のようなパターンも考慮する。閾値は固定せず、環境の成長や通信需要の変化に合わせて見直す。
5.2 変更管理（構成変更時の確認）
構成変更時には、変更前後で疎通確認の結果が比較できる状態にしてから作業を行う。ネットワーク設定や機器交換、ルーティング方針の変更、ファイアウォール更新などが対象となる。
変更管理の観点では、ロールバック手順、切替時刻、影響範囲、事前の期待値（どの通信が維持され、どれが変わり得るか）を明確にする。これにより、問題が起きた場合に原因が変更由来かどうかを判断しやすくなる。
5.3 セキュリティに配慮した確認
5.3.1 権限・通信範囲の管理
診断やテストには権限が必要であるため、最小権限の原則に沿って実施する。加えて、疎通確認で発生する通信が不要な宛先に波及しないよう、スコープ（対象IP、対象ホスト、許可されたポート）を制限する。
特定のプローブはサービスに負荷を与える場合があるため、頻度や同時実行数を抑える。加えて、管理ネットワークとユーザネットワークを混同しないようにし、意図しない経路を通らないよう設計する。
5.3.2 診断時の情報取り扱い
ログや設定情報には、ホスト名、ユーザー識別子、内部アドレス、証明書に関する情報など機密性の高い要素が含まれ得る。したがって保存先のアクセス制御、保存期間、共有範囲を管理する。
また、障害報告においては必要な情報だけを抜粋し、原本を過度に転載しない。診断データを扱う担当者の教育や手順書の整備も、運用上のガバナンスとして重要になる。
6 よくある誤解と注意点
6.1 「到達できる＝正常」と限らない
到達性が確認できても、アプリの処理が遅延し続ける、認証が失敗する、表示が不完全になる、といった問題が残ることがある。特に、通信は通っているが特定の条件でだけ失敗するタイプの障害は、単一手段のテストで見落とされやすい。
したがって、目的に応じて層を上げた確認を行う必要がある。到達確認は出発点であり、完了条件は別に定義しておくと誤解を減らせる。
6.2 遅延や欠損を見落とすリスク
疎通確認が「成功/失敗」だけに偏ると、品質劣化の兆候が捉えられない。遅延がじわじわ増えている、欠損が断続的に起きている、再送が増えているといった状態は、ユーザー体験を悪化させるが、単発テストでは見えにくい。
対策として、測定回数や観測時間を揃え、遅延分布や欠損率を記録する運用が有効である。数値の比較ができる形で残すほど、判断の確度が上がる。
6.3 テスト条件の統一不足による混乱
テスト条件が揃っていないと、結果の解釈が難しくなる。例えば、端末の回線が途中で切り替わっている、バックグラウンド更新が走っている、DNSキャッシュ状態が異なる、同時に別の負荷がかかっている、といった違いが影響し得る。
このため、観測に先立って実施条件を固定するか、変動要因をログに残す。さらに、同一のパラメータで繰り返すことで、比較可能性を確保できる。