第１ 調査の目的と，結論を支える証拠を決める
法律事務所・税理士事務所のウェブサイトの点検，顧問先の制作・保守委託の検収，又は公開ページについて改善を求める場面では，技術の専門家へ意見を求めることがある。
その際は，専門家の肩書だけでなく，誰のどの操作を調べ，どの資料と条件で検証し，何を判断するために使う報告かを定める必要がある。
本記事は令和８年１０月１８日を基準に，公開資料を利用した調査の依頼方法を整理するものであり，特定のサイトの安全性や法的責任を認定するものではない。
公開ソースに記載された設定，実際のブラウザの挙動，管理者側の設定・ログ及び被害の発生は，別々の確認対象である。
取得したソースがHTTP版だけであれば，その内容をHTTPS版の現在の実装と同一であると推測せず，取得できた範囲を報告する。
原因が分からない接続失敗は，調査者の環境で確認できた接続失敗として扱い，サイト全体の停止と直ちに結び付けない。
第２ 問題に応じて専門家と依頼内容を選ぶ
１ 表示・操作とアクセシビリティ
表示崩れ，重なり，ボタンやリンクの動作は，フロントエンド又はWebの品質検証に実績のある技術者へ相談する。
キーボード，読み上げ，拡大表示等を含む評価では，Webアクセシビリティの診断経験を確認する。
利用者が必要な情報へ到達できるかという問題には，ユーザビリティ評価の経験も関係する。
依頼には，調べるページと操作経路，対象端末，ブラウザ，画面幅及び補助技術を含める。
例えば「法律相談の予約先へ移動できるか」「新着情報の分類をキーボードで切り替えられるか」のように，利用者が達成する作業を示す。
W3Cも，ツールだけではアクセシビリティ基準への適合を判断できず，知識のある人による評価が必要であると説明している。
２ 性能とセキュリティ
表示速度や画面のずれは，Webの性能計測と原因分析の経験がある技術者へ相談する。
安全性については，Webアプリケーションのセキュリティ診断者に，公開情報の点検，設定確認又は許可を得た診断のどこまでを依頼するか示す。
事故後の侵入・操作・持出しの有無を調べるフォレンジック調査と，平時の脆弱性診断は，目的と必要資料が異なる。
公開ページの閲覧を依頼したことを，管理画面へのアクセス，攻撃的な試験，負荷試験又は個人情報の入力まで許可した意味にしない。
診断の対象，管理者の許可，実施時間，許される手法及び停止・連絡条件を契約又は依頼書で定める。
専門家の選定では，同種の報告書の見本，担当者の経験，制作・保守担当との利害関係及び再検証への対応も確認する。
第３ 調査資料と再現条件を残す
１ 原資料と加工物を分ける
公開HTML，CSS，JavaScript，HTTP応答，画面画像，操作記録及び通信記録は，それぞれ何を示すかが異なる。
取得URL，到達したURL，取得日時とタイムゾーン，実測した応答状態，取得方法及びファイルとの対応を残す。
HTMLから抽出した文字，抜粋又は注釈付き画像は原資料と区別し，加工前の資料へ戻れるようにする。
ファイルのSHA-256等は，同じバイト列かを照合するために利用できる。
ただし，ハッシュが一致することだけで，取得元の真正，取得日時，内容の正確さ又は調査結論まで証明されるわけではない。
通信記録に認証情報や相談内容が含まれる場合は，原本のアクセス権と，外部へ渡すために必要な範囲へ限定した写しを分ける。
２ 設定した条件と実測した条件
画面幅は，ツールで指定した値とブラウザで実際に描画された幅を区別する。
ブラウザの版，拡大率，ログインの有無，キャッシュ，通信条件及び操作順も記録し，遅延読込みや自動切替がある場合は，どの状態を測ったか示す。
性能の数値は指標名と計測条件を明記し，一回の測定値を全利用者の体感速度へ一般化しない。
再現手順には，開始したページ，行った操作，期待される動作，実際の動作及び確認回数を記載する。
複数条件のうち一部だけで起きた場合は，起きた条件と起きなかった条件の両方を残す。
別環境で再現しなかったことも，原因を絞るための資料となる。
第４ 判断基準と確認結果を分ける
１ 標準・契約・改善推奨を区別する
アクセシビリティでは，採用するWCAG等の版，達成基準，対象範囲及び評価方法を特定する。
例えばWCAG 2.2の2.1.1はキーボード操作，4.1.2は操作部品の名前・役割・状態等，2.2.2は動きや自動更新の制御を扱う。
1.4.10では原則として幅320 CSSピクセル相当でのリフローを検討するが，二次元配置を必要とする部分の例外もある。
標準の達成基準，その理解を助ける解説，実装例及び診断者の改善推奨は区別する。
推奨される実装例と異なるだけで直ちに不適合とせず，適用する基準と実際の挙動から評価する。
また，技術的な不適合の有無と，契約上の要求に違反したか，損害が生じたか等の判断は，それぞれの資料と要件に即して検討する。
２ 検査が成立したかを合否の前に確かめる
検査の実施状態は，実施済み，未実施，実施不能又は対象外として記録する。
実施した検査について，基準を満たす，満たさない又は判定保留という結果を付ける。
接続できなかった検査を，問題がなかったという合格にも，サイト側の不具合が立証されたという不合格にも置き換えない。
未確認事項がある報告も，確認した範囲と限界が明確なら判断材料になり得る。
「全部確認した」と表現する代わりに，対象ページ，操作，環境及び適用基準ごとの確認状況を示す。
追加確認が必要な場合は，何を確かめればどの結論が変わるかを明記する。
第５ 反証を調べ，技術上の可能性を実害へ飛躍させない
古いライブラリの版表示が見付かった場合は，開発元の脆弱性情報，対象範囲及び修正情報と照合する。
対象版の検出，問題を生じさせる処理への到達可能性，攻撃の成立及び実際の情報漏えいは，同じ事実ではない。
当該環境に修正が加えられているかを含め，確認していない範囲は残す。
例えばjQuery開発元のCVE-2020-11022に関する告知は，影響を受ける版と，信頼できないHTMLをDOM操作メソッドへ渡す場合の問題を説明している。
その対象範囲に入る版表示を見たことだけで，特定サイトへの攻撃成功や情報漏えいまで認定することはできない。
逆に，攻撃成功を確認していないことだけで，更新や追加点検が不要とも判断しない。
自動切替の停止ボタンが見当たらない場合も，別の操作による停止処理や設定を調べる。
重複したスクリプトの配置はソースから確認できても，通信の重複，二重計測又は遅延の量は，実行結果を別に測る必要がある。
疑いを支持する材料だけでなく，結論を弱める材料と，それを踏まえて変更した評価も報告に含める。
第６ 依頼書と報告書に求める項目
１ 依頼時に示す事項
依頼時には，判断の目的，対象ページと操作，確認したい問題，許可する手法，提供資料，実施条件，成果物及び停止条件を示す。
報告書には，指摘ごとの対象箇所，根拠資料，再現手順，観察事実，判断基準，推論，反証，未確認事項，利用者への影響及び改善案を求める。
依頼者が望む結論を先に固定したり，不具合の件数を埋めるよう求めたりしない。
簡潔な依頼文としては，次の形が考えられる。
対象ページについて指定した利用者の操作を検証し，確認できた問題と追加検証が必要な懸念を分けてください。
各指摘に，確認条件，根拠資料，再現手順，適用基準，反証，影響及び改善後の検証方法を付け，実施できなかった検査を明記してください。
２ 受領後と改善後の確認
報告書を受領した弁護士・税理士は，各結論がどの資料までで支えられ，顧客又は依頼者の判断に何が不足しているかを確認する。
安全性に関する技術的な懸念，サービスの使いにくさ，契約上の要求及び法的責任を一つの評価語にまとめない。
対外説明では，調査の時点，対象，確認条件及び重大な留保を，結論から切り離さない。
改善後は，修正を行ったという報告だけでなく，現在の公開状態で元の再現手順を試す。
問題の解消に加え，主要な別操作が壊れていないかを確認し，検証できなかった条件は未確認として残す。
調査報告書の完成，修正作業の終了，保存値の確認及び公開面での解消確認は，別の状態として記録する。
第７ 関連記事と一次資料
１ 関連記事
依頼文に資料・手法・照合先を書く方法は，次の記事で整理している。
AIに頼む仕事を深くする４つの問い―弁護士・税理士は役を名乗らせず，資料・手法・照合先を指定する（AI作成）
合否の基準と確認手段の割当ては，次の記事を参照されたい。
AIの仕事の評価基準を育てる手順―失敗の言語化，理想の成果物，落とし穴メモ及び評価を作り込む業務の選び方（AI作成）
権限，完了条件及び証拠台帳の分け方は，次の記事で扱っている。
法律事務所のAIエージェント業務設計－目的・コンテキスト・権限・完了条件をどう分けるか（AI作成）
２ 一次資料と確認範囲
以下は技術的な評価方法と基準を確認する資料であり，日本法上の責任を直接決める法源ではない。
本記事は特定の裁判例を根拠に法的結論を導いておらず，個別サイトの適合性，攻撃可能性又は被害の有無を判定していない。
①W3C「Evaluating Web Accessibility Overview」：ツールと人による評価の役割。
https://www.w3.org/WAI/test-evaluate/
②W3C「Understanding Success Criterion 2.1.1: Keyboard」：キーボードによる操作。
https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html
③W3C「Understanding Success Criterion 4.1.2: Name, Role, Value」：操作部品の名前・役割・状態等。
https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html
④W3C「Understanding Success Criterion 2.2.2: Pause, Stop, Hide」：動きと自動更新の制御。
https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html
⑤W3C「Understanding Success Criterion 1.4.10: Reflow」：幅とリフロー，例外。
https://www.w3.org/WAI/WCAG22/Understanding/reflow.html
⑥W3C「Tabs Pattern」：タブの役割・状態とキーボード操作の実装例。
https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
⑦jQuery開発元「Potential XSS vulnerability in jQuery.htmlPrefilter and related methods」：CVE-2020-11022の影響範囲と条件。
https://github.com/jquery/jquery/security/advisories/GHSA-gxr4-xjj5-5px2