リリース前のチェックリストにリンク監査（サイト内のURLが正しく機能するか確認する作業）を入れているチームは、意外と少ないと感じることがあります。デプロイ直前まで機能実装とテストに追われ、ナビゲーションの遷移先や404の有無は「動いているはず」で済ませてしまいがちです。
この記事は、ドキュメントサイト・ECサイト・SaaSアプリケーションなど数百ページ規模のプロダクトを扱う開発者・QA担当者に向けたものです。リンク監査を手動のcurlコマンドで回すか、AIコーディングエージェントやスクリプトで自動化するか、判断に迷う場面の参考になれば幸いです。
リンク監査が必要になる場面
リンクの問題は、ページが正常なHTTPレスポンスを返していても発生します。
たとえば価格ページへのボタンが、相対パスの指定ミスでトップページに飛んでしまうケースがあります。ステータスコードは200 OK（リクエスト成功を示すHTTPステータス）でも、遷移先は誤りです。
こうした問題は次のような状況で表面化しやすいと考えられます。
- ドキュメントサイトのURL構造を刷新した直後
- メニューやカテゴリ構成を変更したあと
- 別プラットフォームからの移行作業を終えたあと
- 新規ページを追加したが、既存ページからリンクを張り忘れている場合
- 検索クローラーやアクセシビリティツールなど、自動化されたシステムがURLに依存している場合
特に最後の項目は見落とされがちです。検索エンジンのクローラーや支援技術（スクリーンリーダーなど）は、予測可能なURLと正しいHTMLに依存して動作します。リンク切れはユーザー体験だけでなく、こうした自動化システムの動作にも影響します。
判断軸1: 監査対象の規模
数十ページ程度の小規模サイトであれば、手動でのnavigation確認とcurlコマンドによる個別チェックでも十分に回せます。
一方、数百ページを超えるドキュメントサイトやSaaSアプリケーションでは、全URLを人手で洗い出すこと自体が現実的ではありません。ルーティング定義とサイトマップを突き合わせて、孤立ページ（orphan page、内部リンクからたどり着けないページ）を見つける作業には、スクリプトかAIエージェントによる横断的な走査が向いています。
判断軸2: リダイレクトチェーンの複雑さ
リダイレクトチェーンとは、あるURLが別のURLへ転送され、そこからさらに別のURLへ転送される状態を指します。
例として /old-guide → /documentation → /docs → /docs/getting-started のような多段構成が挙げられます。訪問者は最終的に目的のページへ到達しますが、途中の段数が多いほど失敗の余地が増えます。
内部リンクは本来、最終的な正規URL（canonical destination）へ直接張り直すべきです。この作業は、リンク元ファイルを横断的に検索し、置換対象を判断する必要があるため、grepベースのスクリプトかAIエージェントによる一括置換が効率的です。
判断軸3: 判定の文脈依存度
HTTPステータスコードの確認は、ターミナルから次のように行えます。
curl -I https://example.com/page200 OK、301 Moved Permanently（恒久的なリダイレクト）、404 Not Found（対象が見つからない）などのレスポンスが返りますが、非200のレスポンスをすべて不具合と判定するのは早計です。
認証が必要なページはセッション状態によって応答が変わりますし、意図的なリダイレクトも301や302として正常に機能しています。この「文脈判断」が多いプロジェクトほど、機械的な自動化だけでは判定を誤ります。
手動監査・スクリプト・AIエージェントの比較
| 方式 | 向いている規模 | 強み | 弱み |
|---|---|---|---|
| 手動 + curl | 数十ページ以下 | 導入コストゼロ、文脈判断の精度が高い | ページ数増加でスケールしない |
| リンクチェッカー(スクリプト) | 数百ページ規模 | ステータスコード網羅、CI組み込みが容易 | 孤立ページや文脈判断は苦手 |
| AIコーディングエージェント | 数百〜数千ページ、構造変更後 | ルーティング定義との突き合わせ、リダイレクト整理の提案 | 誤検知の目視確認が別途必要 |
ケース別の推奨
小規模なコーポレートサイトやランディングページ数枚程度なら、curl -I によるステータスコード確認とブラウザでの目視ナビゲーションチェックで足ります。CIに組み込むほどの手間をかけなくても、リリース前チェックリストに1項目加えるだけで十分です。
数百ページ規模のドキュメントサイトや、カテゴリ構成を頻繁に変更するSaaSプロダクトの場合は、リンクチェッカー系のCLIツールをCI/CDパイプライン（継続的インテグレーション・デリバリーの自動実行基盤）に組み込む方法が適しています。デプロイ前ステップとして全URLのステータスコードを機械的に検証し、404や500系エラーをビルド失敗として扱う設定が現実的です。
移行作業直後や大規模なメニュー再編のタイミングでは、AIコーディングエージェントにルーティング定義ファイルとサイトマップを渡し、「リンクが張られていないルートを列挙してほしい」と依頼する方法が有効です。孤立ページの発見は、リンクの有無という表面的な情報だけでなく、どのカテゴリに属すべきかという文脈判断を伴うため、単純なクローラーよりもエージェントの方が精度の高い提案を返しやすい領域です。ただし提案されたリンク追加案や削除案は、人間が最終確認してからマージする運用が安全です。
あえて自動化を見送るべき条件
すべてのプロジェクトでAIエージェントによる自動化が必要というわけではありません。
ページ数が少なく更新頻度も低いサイトでは、自動化のセットアップコスト（CI設定、チェックスクリプトの保守）の方が手動確認より重くなります。この場合は無理に仕組みを作らず、リリースチェックリストに手作業の項目として残す方が合理的です。
また、外部の旧URLやブックマーク経由でアクセスされる可能性がある古いページへのリダイレクトは、意図的に残す必要があります。自動化ツールが「不要なリダイレクト」として一律に削除を提案してくる場合は、その提案をそのまま適用せず、なぜそのリダイレクトが存在するのか履歴を確認してから判断すべきです。
まとめ
リンク監査の方式選びは、監査対象の規模・リダイレクトの複雑さ・判定に必要な文脈依存度の3点で決まります。
数十ページなら手動とcurlで十分ですが、数百ページ規模やドキュメント構造の変更直後は、スクリプトによるステータスコード網羅とAIエージェントによる孤立ページ検出を組み合わせる方法が現実的です。
まず手元のプロジェクトで curl -I を主要なURLに対して実行し、想定外のステータスコードが返っていないか確認するところから始めてみてください。そのうえで、ルーティング定義とサイトマップの突き合わせが手作業では厳しいと感じたら、AIエージェントへの一括チェック依頼を検討する流れが無理のない進め方です。