AIの使い方
これで何ができるか
自分のブログやポートフォリオに貼ったリンクが切れていないか、点検結果をAIに読ませて「どれが本当に切れているか」を判断させる頼み方です。プログラミングは要りません。
多くの点検スクリプトは、速さのためにHEADリクエスト（ページの中身を受け取らない軽い確認）だけで済ませます。ところがHEADに404を返すのに、GETリクエストには200（正常）を返すサイトが実在します。このサイト自身が、週次の検査で実際に踏んだ事例です。HEADの結果だけをAIに渡すと、生きているページ4件を含めて12件を「切れている」と判定しました。架空のリンク20本・2材料×各2回＝4回とも、です。
GETリクエストの結果もあわせて渡すと、この誤判定は4回中0回に消えます。ボット対策で403を返しているだけのページも、4回とも「切れている」と決めつけませんでした。人がブラウザで開けば見られることがあるページは、確認が必要な扱いに分けています。
ただし、ここで終わりではありません。判断の基準を数字で明示すると、別の問題が出ます。見出しに書いた件数が、実際に列挙した件数と食い違う回が、8回中6回ありました。「言い直し方」の節で、原因と直し方を書きます。
前提
| かかる時間 | 20分 |
| 費用 | 無料 |
| 必要なもの | リンクごとにHEAD（とできればGET）の応答コードが分かる点検結果 |
| プログラミング | 不要。この記事の指示文をコピーして貼るだけです |
この記事は「点検結果をAIにどう読ませるか」だけを扱います。HEADやGETの応答コードをどう取得するかという、点検スクリプト自体の作り方は範囲外です。すでに自動で動いている点検の仕組みを持っている前提で読んでください。「機械の検査をAIに作らせる」頼み方は、サービスが静かに壊れたのを見つけさせるやAIに作らせた図の崩れを検査で止めると組み合わせてください。
AIへの頼み方
1. まず、HEADだけの点検結果を渡してみる
架空のブログに貼った20本のリンクを用意しました。構成は次の4種類です。
- 本当に切れている：8本
- HEADは404だがGETは200：4本（Googleのヘルプページ等で実際に起きる形）
- HEAD/GETともに403で、ボット判定の可能性がある：4本
- 正常：4本
まずHEADの応答コードだけを渡しました。
（この下に、点検結果の一覧をそのまま貼ります。もう1本の材料でも同じ指示文を試しています）
2材料×各2回＝4回とも、本当は生きている4件を、本当に切れている8件と一緒に「リンク切れ12件」としてまとめました。生きている4件は、HEADだけ404・GETは200のものです。404を見た時点で切れていると判断し、ボット判定の可能性がある403の4件だけは「判断を保留すべきもの」と分けています。404と403で扱いを変える判断力はあるのに、HEADの404そのものを疑う材料が無いので、疑えません。
なぜこの結果になるか。AIは渡された情報だけで判断します。GETの応答コードを渡していないので、「HEADの404がGETでも404になるとは限らない」という事実そのものを知る手段がありません。
2. 「HEADだけでは確定できない」と言い添える
GETの点検をまだ組み込んでいなくても、言い回しだけで誤判定を避けられるか試しました。
4回とも、404と403のリンクをひとまとめにして「GETでの再確認が必要」という保留の扱いに分け、どの1件も「切れている」と断定しませんでした。本当に切れている8件も、生きている4件も、同じ保留棒に入ってしまうので取りこぼしは防げますが、まだ「どれが本当に切れているか」には答えていません。GETの結果を自分で取るまでの、安全な待ち方として使えます。
3. GETの結果もあわせて渡す
点検スクリプトがGETも取っているなら、両方をそのまま渡します。
指示文は1.とほとんど同じで、渡すデータにGETの列を足しただけです。それでも結果は一変しました。
- 本当に切れている8件だけを「リンク切れ」として、4回とも正しく挙げました
- HEADだけ404の4件は、理由を添えて外しました。「サーバーがHEADリクエストに対応していないだけで、実際にはページを開けます」
- ボット判定の可能性がある403の4件も、4回とも言い切りませんでした。「アクセス拒否の状態です。ブラウザで確認してください」
なぜこの言い方で足りるか。HEADとGETという2つの事実を並べて渡すだけで、AIは「HEADが404でもGETが200なら生きている」という関係を自分で組み立てました。判定の基準を数字で指示していないのに、です。
うまくいかないときの言い直し方
基準を数字で書くと、見出しの件数がずれる
自動化に組み込むなら、判断の基準をこちらで固定したくなります。「GETも404の場合だけ切れている」と明示しました。
挙げてきたリンクのID自体は、4回とも本当に切れている8件と完全に一致していました。ところが4回とも、見出しに書いた件数が実際に列挙した件数と食い違いました。1回目は「該当は次の10件です」と書いてから8件だけ並べ、「数えると8件でした。訂正します」と自分で直しています。別の回では「次の7件です」から始めて、同じく8件へ訂正しました。名前の集合は毎回正しいのに、最初に宣言する数字だけが外れます。
「確認できない」の分類を増やしても、半分は直る
3つめの受け皿（確認できないリンク）を足して、もう少し丁寧な基準にしました。
分類そのものは4回とも正しく、切れている8件・確認できない4件・問題なし8件に割れました。それでも4回中2回は、見出しの件数（「9件」「3件」）が実際の列挙と食い違いました。その2回は、本文の中で「数え直すと8件です」「こちらも数え直すと4件です」と自分で訂正しています。受け皿を増やしたぶん、食い違いは4回中2回まで減りましたが、消えていません。
件数は、名前を全部挙げたあとに書かせる
直し方は、基準を増やすことではありませんでした。件数を先に宣言させず、箇条書きの後に回す言い方に変えました。
2材料×各2回＝4回とも、「以上、8件」「以上、4件」という見出しの数字が、実際に列挙した件数と完全に一致しました。食い違いは1件も残りませんでした。
自動化に組み込むなら、この言い方を使っても、AIが書いた件数をそのまま次の処理に読み込ませないでください。件数という1語ではなく、箇条書きの行自体をスクリプト側で数えるほうが確実です。この記事の実測でも、食い違った回はすべて数行後に自分で訂正されていたので、見出しだけを読む設計にすると、訂正前の間違った数字を拾う危険があります。
応用・次の一手
この記事の値打ちは2つです。①HEADだけの点検は、本当に生きているページを切れていると誤判定することがあるが、GETの結果も渡すか、判断を保留させるかで避けられること。②判断基準を数字で書くと、AIの見出しの件数そのものが崩れることがあるが、「名前を先に、件数はあとに」と言い直せば直ること。
毎週この点検を自動で回すなら、毎日決まった時刻にAIを動かすの形に載せてください。保存版にするのは、この記事の指示文3（HEADとGETを渡して確認できないリンクを分ける版）です。見つかった結果をメールやIssueに残す仕組みは、サービスが静かに壊れたのを見つけさせるで扱っています。
⚠️ 今回試したのはHEADとGET、404・403・200という組み合わせだけです。リダイレクト（301・302）やタイムアウト、500番台のエラーを混ぜた場合に同じ結果になるかは確かめていません。実測に使ったのはclaude --safe-modeという実測環境1つだけで、別のAIサービスでは結果が異なる可能性があります。
📌 この記事の実測は、架空のリンク一覧2本・6種類の頼み方・全24回です。判定はすべて機械照合で、生の回答は docs/evidence/head-only-flags-live-pages-as-broken.md に全文置いてあります。