第１ URLの確認では取得方法と確認範囲を指定する
AIに公開URLを渡す場合は，そのページの何を確かめたいかを先に決めるとよい。
特定の記事の現在の題名や本文を正確に確かめたい場合と，関連資料を広く探したい場合とでは，適した入口が異なる。
この記事では，ウェブ検索，直接HTTP取得及びブラウザーによる確認を説明上区別し，方法の選び方と読めないときの切り分けを整理する。
特定の公開URLの精密な確認では，利用環境とサイトの条件が許す直接取得を最初の候補にする方法が考えられる。
ただし，直接取得で得たHTMLだけでは，画面に後から表示される内容，画像内の文字，リンク先のPDF等を確認し切れない場合がある。
取得の成否，読んだ範囲及び回答の根拠を分けて確認することが大切である。
製品ごとの利用可能なツールや許可範囲は異なる。
以下は特定のサービスに共通する操作モードを定義するものではなく，取得方法を選ぶための実務上の整理であり，仕様の確認日は令和８年１１月１４日である。
第２ ウェブ検索・直接取得・ブラウザーの違い
１ ウェブ検索は資料の所在を探す入口になる
検索は，関連資料，公式の掲載元，別の掲載先及び更新情報を探すときに役立つ。
検索結果の題名や抜粋だけでは，対象ページ全体を読んだことにはならないため，重要な記載は掲載元を開いて確認する。
検索用のツールにも，ページを開く機能やページ内を探す機能を備えるものがある。
例えばOpenAIのResponses APIのweb_searchには，search，open_page及びfind_in_pageという処理が説明されている。
したがって，「ウェブ検索用のツールを使ったから検索結果だけを見た」とも，「URLを渡したから必ず掲載元の全文を取得した」とも一律にはいえない。
根拠はOpenAIのWeb search公式資料のOutput and citationsである。
２ 直接取得は指定URLから返るデータを調べる
この記事でいう直接取得は，許可されたHTTPクライアント等から指定URLへリクエストし，応答の本文やヘッダーを受け取る方法である。
題名，本文中の語句，リンク先及び応答コードを確かめ，取得したデータを比較用に残したい場合に向く。
もっとも，ブラウザーもHTTP等を使って通信するため，直接取得とブラウザーは通信方式が完全に別という関係ではない。
主な違いは，受け取ったデータをどこまで処理し，画面上の表示や操作まで確かめるかにある。
HTTPとウェブページの構成についてはMDNのHTTP概説が参考になる。
３ ブラウザーは表示と操作を確かめる
JavaScriptによって後から表示される本文，展開ボタンの内側，表の配置及び埋込みの表示を確かめる場合には，ブラウザーが必要になることがある。
それでも，画面に見えた部分だけでページ全体やリンク先まで読んだことにはならない。
どの画面を開き，どの範囲を見たかを記録する必要がある。
| 方法 | 主に役立つ目的 | 追加確認が必要な例 |
|---|---|---|
| ウェブ検索 | 関連資料や掲載元を探す | 抜粋の前後，原資料の本文，現在の掲載状態 |
| 直接HTTP取得 | 指定URLの応答と取得データを照合する | 後から表示される内容，画像，画面配置 |
| ブラウザー | 実際の表示や展開操作を確かめる | 未表示部分，別ページ，リンク先の資料 |
第３ 最初に使う方法は目的で選ぶ
１ 特定URLの精密確認では直接取得を優先する
題名の一致や特定の文章の有無を確かめる依頼であれば，まず指定URLの応答を直接取得し，転送後のURL，題名及び該当箇所を照合する方針が考えられる。
検索結果を経由せず対象を確かめられ，何を取得したかを記録しやすいからである。
これは目的に応じた手順の提案であり，全てのサービスで直接取得が利用できるという説明ではない。
一方，調査対象の所在が不明な場合や，どの資料が関連するかを広く調べたい場合は，検索から始める合理性がある。
表示や展開操作自体が確認対象なら，ブラウザーから始めることも適切である。
常に検索を先に使う必要も，常に直接取得だけで完了させる必要もない。
２ 直接取得でも最新版とは限らない
直接HTTP取得でも，配信側や中継側で保存された応答が返る場合がある。
ブラウザーには，これらとは別にブラウザー自身のキャッシュが使われる場合もある。
したがって，直接取得という方法名だけで，発信元の最新版を受け取ったと断定できない。
更新が争点になる場合は，取得時点，ページに記載された更新日，版を識別する表示等を照合し，食い違いがあれば原因未確定として扱う。
キャッシュの基本はMDNのHTTP cachingで説明されている。
また，OpenAIのResponses APIには，web_searchの外部アクセスを有効にする設定と，キャッシュ・索引だけを使う設定がある。
これは同APIの仕様であり，ChatGPT等の全画面の取得経路を説明するものではない。
ツール名だけから，今回どの経路でどの版を得たかを推測しない方がよい。
根拠はOpenAI公式資料のLive internet accessの項である。
第４ 読めないときは止まった段階を分ける
「取得できなかった」という結果だけでは，サイトがAIを拒否したのか，通信に問題があるのか，本文を抽出できなかったのかは分からない。
まず実際の応答やエラー記録を確認する。
| 段階 | 確認する事実 | その事実だけではいえないこと |
|---|---|---|
| 通信 | 名前解決，接続，TLS等のどこで失敗したか | サイトから４０３応答が返ったこと |
| HTTP応答 | 応答コード，転送先，返された本文 | ４０３の具体的な判定条件や運営者の意図 |
| 本文抽出 | データは得たか，本文や表を抽出できたか | 抽出文にない記載が原ページにもないこと |
| 画面表示 | 展開後の内容，画像，表，埋込み | 未表示部分やリンク先も確認できたこと |
４０３は，サーバーがリクエストを理解した上で処理を拒否する意味の応答である。
しかし，そのコードだけで，ユーザーエージェント，IPアドレス，認証その他のどの条件が理由なのかまでは確定しない。
定義はRFC 9110の15.5.4節にある。
同じURLがブラウザーで開け，別の取得経路では開けない場合には，経路による結果の違いが確認できる。
ブラウザーと他の経路では複数の条件が異なり得るため，その比較だけで原因を一つに決めない。
通信段階で失敗してHTTP応答を受け取っていない場合には，「４０３で拒否された」と報告しない。
別の確認方法を使う場合も，その環境で許された手段に限る。
認証・有料制限，サイトの取得条件，ツールの明示的な停止・拒否を迂回せず，利用できる公式の別掲載先や提供された資料で確認できる範囲を整理する。
同じ失敗を繰り返すより，未取得の範囲と次に必要な資料を明らかにする方がよい。
第５ 取得できた後に確認すること
①取得先を確かめる。
要求したURLと転送後のURL，ページの題名，発信主体及び対象年度・版を照合する。
同じような題名の旧年度資料を，現在の資料として扱わない。
②必要な範囲を実際に読む。
該当する文だけでなく，対象，条件，例外，注記及び前後の文脈を確認する。
画像やPDFの表が問題になる場合には，文字抽出だけで足りるかも検討する。
③取得と読了を分けて記録する。
ファイルを取得したことは，全文を読んだことと異なる。
読んだ節や頁と確認できなかった部分を示せば，後から確認範囲を追いやすい。
④結論との対応を確かめる。
原ページにある文章を正確に読み取れても，そこから回答の結論が導けるとは限らない。
法的命題の確認では，事案，適用時点及び判旨の射程も別に照合する。
この段階の手順は生成AIで法律調査をする方法で扱っている。
第６ AIへの依頼文の例
次の文は，特定の公開URLについて精密な確認を依頼する例である。
実際に利用可能なツールと権限に合わせて使う。
次の公開URLの現在の題名と該当箇所を，実際に開いて確認してください。
許可された直接HTTP取得を最初の候補とし，取得した応答だけで足りない表示内容はブラウザー等で確認してください。
要求URL，転送後URL，確認日時，題名，実際に読んだ範囲及び確認できなかった部分を示してください。
失敗した場合は，通信，HTTP応答，本文抽出，表示のどの段階で止まったかを，確認できた事実に基づいて説明してください。
取得制限やツールの明示的な拒否は迂回しないでください。
「最初に直接取得を試す」という順序だけでなく，何を確認して完了とするかも一緒に指定する点が重要である。
特定の資料を指定していない概要調査では，この例をそのまま当てはめず，関連資料の探索を依頼すればよい。
第７ よくある質問
１ 直接取得ならAIの回答も正確になるか
直接取得は，対象ページのデータを照合しやすくする方法である。
抽出漏れ，読み違い，古い版の採用及び推論の誤りは別に起こり得るため，取得方法だけで回答の正確性は保証されない。
２ 公開ページの本文とCMSに保存された本文は同じか
公開画面に表示される本文と，CMSに保存された編集用の本文は，同一であると決めつけられない。
WordPressでは，投稿の本文をデータベースから取得した後，画面に出力する前に，the_contentフィルターで本文が加工される場合がある。
自分が管理するサイトの記事を編集するときは，読者に見える状態の確認には公開画面を，保存内容の確認には管理画面の保存値を，それぞれの目的に応じて照合する。
公開HTMLを取得できたことだけで，保存値まで確認したと扱わない。
根拠はWordPress「the_content」のMore Informationである。
３ この方針をスキルにすれば必ず自動で使われるか
スキルに手順を書いたことと，実際の依頼で選ばれ，処理が完了したことは異なる。
対象条件の説明，利用環境の呼出し設定及び実際の動作を確認する必要がある。
確認方法はClaude Code・Codexのスキルが増えすぎたときの整理方法を参照されたい。
第８ 関連記事
AIエージェントで法務省の司法試験ページを読むときの障壁は，法務省資料の過去の検証とPDF等の個別の問題を扱う。
AIの出典リンクは信用できるかは，リンクの実在，主張への対応及び裏付けの独立性を扱う。
弁護士のClaude Code Skills活用法は，調査手順をスキルとして継続して使う方法を扱う。
第９ 出典・参考資料
MDN「Overview of HTTP」のHTTP通信とウェブページの構成に関する説明を参照した。
MDN「HTTP caching」の応答の保存・再利用に関する説明を参照した。
OpenAI「Web search」のOutput and citations及びLive internet accessを参照した。
APIの説明を，他の製品画面の内部動作へ一般化していない。
WordPress「the_content」のMore Informationを参照した。
RFC 9110「HTTP Semantics」15.5.4節の４０３の定義を参照した。
以上の公開資料の確認日は令和８年１１月１４日である。