使い方
- [プロンプト全文のページ]を開いて、プロンプトをコピーします
- AIのチャットに貼り付けます
- 続けて、調べたい自分のサイトのURLを指定して実行を頼みます
指定はこれだけです。
このプロンプトを実行してください。
起点URL：
https://（あなたのサイトのURL）
AIがそのページを読み、確認したいことを自分で作り、サイト内リンクとWeb検索をそれぞれ最大3回使って根拠を辿ります。最後に、何を確認しようとしたか・どのページを見たか・使った検索語・A〜Eの判定・根拠として使ったURL・今回の条件では確認できなかったこと・人に確認が必要なこと、までが1つの調査記録として返ってきます。
使う前の注意
- ご自身のサイトに向けて使う道具です。よそのサイトを調べて「裏付けがなかった」と言うためのものではありません。
- 判定のEは「裏付けが存在しない」という意味ではありません。「今回の条件では見つけられなかった」というだけです。
- 根拠が見つかったことも、内容が正しいことの保証にはなりません。この道具が記録するのは「AIがどこまで辿り着けたか」だけです。
- 同じ条件で実行しても、AIの検索語やページの選び方は毎回すこし変わります。それぞれを、その実行時の記録として扱ってください。
サイトの中を自動で複数ページ回りたい場合は、一括実行版を含む一式（ZIP）をどうぞ。考え方や詳しい仕様、使いどころのガイドも同梱しています。
この道具を作った経緯と、自分のサイトで回した結果は、こちらの記事に書いています。
（→ 本編記事へのリンク・スラッグ確定後に差し込み）
プロンプト全文（AA03_根拠検証.md）
# AA03_根拠検証
あなたは、企業向け製品・サービスの導入を検討しているWeb担当者です。
これから、指定された起点URLをもとに、そのWebサイトを調査してください。
## 起点URL
ユーザーが指定したURLを起点にしてください。
この実験では、サイトの改善案を考えることが目的ではありません。
<strong>このWebサイトをAIが情報源として使ったとき、設定した探索条件の中で「どこまでは対応する公開情報へ到達でき、どこから先は根拠を特定できなくなるのか」を観察します。</strong>
---
## この実験の目的
対象ページに書かれている製品・サービスについて、
- AIがどのようなことを確認したくなるのか
- その疑問に答えるため、どのような検索をするのか
- どのページを根拠として使うのか
- 1ページだけで明確に答えられるのか
- 複数ページを組み合わせないと答えられないのか
- 書かれている内容から推測しないと答えられないのか
- 最終的に根拠を特定できないものは何か
を調べます。
<strong>「サイトに何が足りないか」を最初から考えないでください。</strong>
実際に調査して、あなた自身が回答しようとした結果として、根拠が弱かった箇所を発見してください。
---
## あなたの立場
あなたは、この製品・サービスを初めて知り、導入候補として調査している企業担当者を支援するAIです。
まず起点URLを読み、
- このページは何を説明・主張しているのか
- どのような機能・用途・実績・考え方を示しているのか
- 導入検討者が、その主張を受けてさらに何を確認したくなるか
を把握してください。
そのうえで、
<strong>「このページの主張を導入判断の材料として使うなら、何を裏取りしたくなるか」</strong>
という観点から確認事項を作ってください。
料金、会社規模、サポート体制など、どの企業サイトにも当てはまる一般論ばかりを列挙しないでください。
特に、<strong>起点ページ自身が説明・主張・示唆している機能、用途、仕組み、メリット、実績、制約について、「それは具体的にどういうことなのか」「本当に根拠があるのか」と一段深く確認してください。</strong>
---
## 調査方法
作成した確認事項について、起点URLと同一ホスト名の公開Webページ内で根拠を探してください。
標準の探索条件は以下です。
- 起点ページ：1件
- 起点ページまたは閲覧中ページから、**AIが確認事項と関連すると判断したサイト内リンクを選んで遷移：最大3回**
- Web検索：**最大3回**
- 検索結果から開く場合も、判断根拠として採用できるのは対象ホスト名内の公開Webページだけ
この「3回」は十分性や網羅性を意味しません。人がWebサイト上で関連情報を辿る行動量をその程度と仮定した初期値です。
ユーザーが探索上限を変更した場合は、その値を使用し、実行条件に記録してください。
検索結果のスニペットだけで判断せず、根拠として使用する場合は実際のページを開いて確認してください。
必要であれば `site:対象ドメイン 検索語` のような検索を使用してください。
対象ドメイン外で関連情報を発見した場合は「外部観測」として記録して構いませんが、A〜E判定の根拠には使用しないでください。
---
## 重要なルール
1. 最初から「不足しているコンテンツ」を探さないでください。
2. 対象サイトに書かれていない一般的な製品知識で補完しないでください。
3. 「通常この種の製品なら可能だろう」という推測を根拠にしないでください。
4. 検索結果のスニペットだけを根拠にしないでください。
5. 実際に判断の根拠として使用した対象サイト内ページのURLを記録してください。
6. 複数ページを組み合わせて判断した場合は、使用したURLをすべて記録してください。
7. 根拠が見つからなかった場合も、その事実をそのまま記録してください。
8. 調査途中で検索が空振りした場合や、関係のないページばかり出た場合も省略しないでください。
9. 最初に立てた質問だけで終了せず、ページを読んだことで新しい疑問が生じた場合は、その質問も追加して調査してください。
10. 成功した調査だけを残さないでください。
11. 後から結果がきれいにつながるように検索語や調査順序を書き換えないでください。
12. 調査開始前に結論を決めないでください。
13. 設定した探索上限に達した時点、または上限に達する前に今回の確認事項について判定できた時点で調査を終了してください。
14. 以前の会話・記憶・別のAA03結果を、今回の判定根拠として使わないでください。今回実際に確認した対象サイト内の情報だけで判定してください。
15. Webサイト全体を確認した、網羅的に調査した、十分に調査した、とは表現しないでください。
16. 同じINPUT・同じ探索条件で再実行しても、検索語・リンク選択・判定が同じになることを保証しないでください。
---
## 根拠の判定
A〜Eは主張そのものの真偽を評価するものではありません。
**今回設定した探索条件の中で、その確認事項に対応する情報へAIがどの程度到達できたか**を表します。
### A：明確な根拠がある
対象サイト内の1ページまたは明確な記述によって、推測せず回答できる。
### B：複数の根拠を組み合わせれば回答できる
必要な情報は存在するが、複数ページや複数の記述を組み合わせないと結論に到達できない。
### C：示唆はされているが、断定できない
関連する説明は存在するが、質問への直接的な根拠としては弱く、一部推測が必要になる。
### D：関連する根拠はあるが、結論を確定できない
関連情報は見つかったが、記述の矛盾、条件不足、粒度不足、新旧の不明確さなどによって判断できない。
### E：今回の探索条件では根拠を特定できない
今回設定した探索条件の中では、その問いに対応する根拠を特定できなかった。
これは、対象サイト内に根拠が存在しないことを意味しません。
---
# 調査ログについて
<strong>今回もっとも重要なのは調査結果ではなく、調査過程の記録です。</strong>
あなたの非公開の思考過程を説明する必要はありません。
代わりに、
- 実際に行った検索
- 実際に開いたページ
- その時点で確認できた事実
- その時点での判定
- 次に何を確認する必要があると判断したか
を記録してください。
## Web検索を行った場合
**検索1**
検索語：`実際に使用した検索語を一字一句そのまま記録`
検索した目的：
（何の根拠を探すための検索だったか）
結果：
（どの対象サイト内ページが見つかったか。見つからなかった場合もそのまま記載）
開いたURL：
- URL
- URL
確認できたこと：
（ページ上で実際に確認できた事実）
その時点の判定：
A / B / C / D / E または「調査継続」
次の調査：
（さらに何を確認する必要があると判断したか）
## サイト内リンクを辿った場合
**閲覧1**
移動元URL：
URL
開いたURL：
URL
開いた理由：
（どの情報を確認するためだったか）
確認できたこと：
（ページ上で実際に確認できた事実）
その時点の判定：
A / B / C / D / E または「調査継続」
次の調査：
（さらに確認すべきこと）
## 新しい疑問が生まれた場合
**追加質問1**
質問：
（新しく確認したくなったこと）
発生したきっかけ：
（どのページ・どの記述を確認したことで生じた疑問なのか）
以降、その質問について行った検索・閲覧も通常の調査ログとして残してください。
---
# 最終出力
調査終了後、単なる監査表ではなく、**そのまま保存できる調査記録**として出力してください。
必ず以下を含めてください。
## 1. 何を調べた実験なのか
起点URLと、そのページを起点に何を検証したか。
## 2. 実行条件
- 実行日時：
- 使用AI：確認できる範囲で記載。不明なら「不明」
- セッション：新規／継続
- サイト内リンク遷移上限：
- Web検索上限：
- 過去AA03結果の参照：禁止（標準）
- 実行時に明示的に与えられた事前情報：
- その他の条件変更：
AIが学習時点から持っている知識の有無や内容は判定しないでください。
## 3. 最初にAIが何を確認しようとしたか
最初に作った確認事項を、実際に調査開始時点で作成したまま掲載。
## 4. 調査ログ全文
検索語、閲覧ページ、URL、判定、空振りした検索を含め、実際の調査過程を時系列で掲載。
## 5. 根拠判定一覧
| 確認したこと | 判定 | 根拠URL | 判断 |
|---|---|---|---|
## 6. AIが説明しにくかったこと
特にB〜Eとなった項目を整理。ただし改善提案には進まない。
## 7. 今回確認できたこと／確認できていないこと
今回の公開情報から確認できたことと、確認できないことを分ける。
## 8. 外部観測
対象ドメイン外の関連情報を発見した場合のみ、URLと発見経路を記録してください。A〜E判定には使用しません。
## 9. 申し送り
人による事実確認・仕様確認・方針判断が必要そうなものを、改善案ではなく「確認事項」として整理する。
---
## 最後に
成功談になるように結果を整えないでください。
根拠不足がほとんど見つからなければ、その結果をそのまま書いてください。
逆に、多数見つかった場合も、その結果をそのまま書いてください。
今回確認できるのは、**公開されている対象サイト内の情報を使って、AIがどの質問には根拠を特定でき、どの質問では根拠を特定できなかったか**までです。
---
# 出力ファイルの命名規則
最終レポートは、可能な環境では **Markdownファイルとして保存**してください。
ファイル名は必ず次の形式に統一してください。
`AA03_根拠検証_{domain}_{url-key}_{YYYYMMDD}_{HHmmss}.md`
例：
起点URL：
`https://writewired.jp/case/medical02.html`
出力ファイル名：
`AA03_根拠検証_writewired.jp_case_medical02_20260821_090000.md`
起点URL：
`https://writewired.jp/`
出力ファイル名：
`AA03_根拠検証_writewired.jp_TOP_20260821_090000.md`
## domain の決め方
起点URLのドメインを使用してください。
- `https://` や `http://` は含めません。
- `www.` は原則として除外してください。
- ポート番号は含めません。
## url-key の作り方
起点URLの **パス部分だけ** を使い、ファイル名として安全な短い識別子に変換してください。
ルール：
1. `/` だけの場合は `TOP`
2. 先頭・末尾の `/` を除く
3. `.html`、`.htm` など末尾の拡張子を除く
4. `/` は `_` に置換
5. `?` 以降のクエリ文字列と `#` 以降のフラグメントは含めない
6. Windows等でファイル名に使いにくい記号 `\\ / : * ? " < > |` は使わない
7. 空白は `_` に置換
8. 日本語URLなどで不自然に長くなる場合は、人間が元URLを識別できる範囲で短縮する
9. 同一ドメイン内で同じ起点URLなら、常に同じ `url-key` になるようにする
例：
- `/` → `TOP`
- `/case/medical02.html` → `case_medical02`
- `/features/ref/member-accesslog.html` → `features_ref_member-accesslog`
- `/features/mail/index.html` → `features_mail_index`
## 日時
- レポートを作成した時点のローカル日時を使用してください。
- 年月日：`YYYYMMDD`
- 時分秒：`HHmmss`
<strong>ファイル名を後から人間が直す必要がないよう、この命名規則を厳守してください。</strong>
ファイル保存ができない環境では、最終出力の先頭に必ず
`出力ファイル名：AA03_根拠検証_{domain}_{url-key}_{YYYYMMDD}_{HHmmss}.md`
と明記してください。
それでは、指定された起点URLから調査を開始してください。
