内部リンクをAIに提案させると、便利な一方で不自然なリンクや死にリンクが混ざります。この記事では、Link WhisperやInLinksといった既製ツールの公式機能を参照します。そのうえで、自作プロンプトで内部リンクを提案させる出力形式と、検証観点の作り方を示します。本誌は実際に、記事間参照の実タイトル表記における死にリンクを機械検出する仕組みを運用しています。
検証環境：Google Search Central公式ドキュメント（検索の仕組み・SEOスターターガイド）を2026-08-08に確認しています。加えてLink Whisper公式ブログ、InLinks公式サイトも同日に確認しています。
01結論：内部リンクのAI提案は「候補を出す」より「検証観点を作る」が要
AIに内部リンクの候補を出させること自体は難しくありません。難しいのは、出てきた候補が正しいかを検証する仕組みを別に持つことです。候補を出す工程と、検証する工程を分けて設計しないと、不自然なリンクや存在しない記事への参照がそのまま公開されます。
本誌は候補の生成をAIに任せつつ、検証は独立した機械検査に任せています。生成と検証を同じAIの同じ実行に任せると、AI自身が出した誤りをAI自身が見逃しやすくなるためです。
02なぜ内部リンクの提案をAIに任せる設計が必要なのか
Google検索は、既知のページからリンクを抽出することで新しいページを発見します。カテゴリページのようなハブページから新しい記事へのリンクは、その典型例です（出典: Google Search Central・2025-12-18更新）。
Google公式のSEOスターターガイドも、関係のあるリソースへリンクすることを推奨しています。新しいページの発見のほとんどはリンクを通じて行われるとも説明しています（出典: Google Search Central・2025-12-18更新）。
本誌は2026-08-08時点で75本の記事を持ち、記事間の関連付けだけを人手で洗い出すと、対象の組み合わせが急激に増えます。だからこそ、候補を出す工程はAIに任せ、正しさの検証だけを機械に固定化する設計が要ります。
03内部リンク提案ツールは何を見ているか｜Link WhisperとInLinksの比較
内部リンクをAIに提案させる既製ツールは、複数の観点でリンク候補を評価しています。次の表は、Link WhisperとInLinksが公式に掲げる機能を比較したものです。
| 観点 | Link Whisper | InLinks |
|---|---|---|
| 提案の仕組み | 文の構造・キーワードの文脈・ページの権威性を学習したモデルが提案 | トピックプランナーによるエンティティベースの関連付け |
| 一括処理 | キーワードと遷移先を指定して既存記事へ一括でリンクを挿入 | プロジェクト単位でページ数に応じた自動化を提供 |
| アンカーテキスト | 同じ語の反復を避ける、意味の近い言い換えを提案 | エンティティの表記ゆれを踏まえた関連付け |
| 健全性の可視化 | 孤立ページ・リンク切れ・404を検出するダッシュボード | 該当なし（公式サイトでは言及を確認できず） |
Link Whisper公式ブログによると、提供開始は2017年です（出典: Link Whisper公式ブログ・2025-07-29公開）。2025年7月時点で4万件を超えるサイトに導入され、134の国と地域で使われています（出典: 同上）。InLinks公式サイトによると、利用者は23,000人を超えています（出典: InLinks公式サイト）。
いずれのツールも、単純なキーワード一致ではなく、文脈やトピックの関連性を見て候補を絞り込む設計です。この「文脈で絞り込む」という発想は、自作プロンプトを設計するときにも参考にできます。
04自作プロンプトで内部リンクを提案させる設計
既製ツールを導入しない場合も、同じ発想を自作プロンプトに落とし込めます。次の例は、本誌が内部リンクの候補を出させるときに使う指示の骨格です。
役割：AI MARKETING JOURNAL編集部の内部リンク担当
指示：次の記事本文について、関連する既存記事への内部リンク候補を提案してください。
入力：対象記事の本文、既存記事の一覧（ID・タイトル・要約）
制約：
1) 候補は2〜4本を目安にする（多すぎる候補は本文を読みにくくする）
2) キーワードの一致だけでなく、読者がその話題を掘り下げたくなる文脈で提案する
3) 参照先は既に執筆済みの記事のみとする。未執筆のタイトルは候補にしない
出力形式：候補ごとに「参照先ID・実タイトル・挿入したい本文位置・提案理由」を1件1行で出す制約3が要です。既製ツールは自社サイト内の実在ページだけを対象にしますが、自作プロンプトでは、AIが「こういう記事があるはずだ」と存在しないタイトルを候補に含めてしまうことがあります。既存記事の一覧を入力として明示的に渡すことが、この誤りを防ぐ土台になります。プロンプトに何を投入すると出力の質が変わるかという設計の考え方は『AI生成記事の独自性を左右する設計｜プロンプトに足す3要素』でも扱っています。
05内部リンク提案の出力形式をどう設計するか
出力形式は、後工程の検証がそのまま機械処理できる形にします。本誌は「参照先ID・実タイトル・挿入したい本文位置・提案理由」の4項目を1行ずつ出させています。IDとタイトルを両方出させるのは、タイトルだけでは表記ゆれが起きやすく、IDだけでは人間のレビューが読みにくいためです。
提案理由を出力に含める設計にも意味があります。理由が「キーワードが一致するため」のような表層的な説明にとどまる候補は、文脈の関連性が薄い疑いがあります。理由の質を見るだけで、レビュー担当は候補の絞り込みにかかる時間を減らせます。
06不自然なリンクをどう除外するか
内部リンクの候補には、機械的には正しくても読者には不自然なものが混ざります。除外の基準は、次の3点で確認します。
- 参照先の記事が、今読んでいる話題の掘り下げとして自然に読めるか
- 同じ記事への参照が、本文中に2回以上重複していないか
- 1記事あたりの参照本数が、2〜4本という目安を超えていないか
Link Whisper公式ブログによると、1記事あたりの内部リンク本数の目安は3本から10本です（出典: Link Whisper公式ブログ・2025-07-29公開）。本誌は記事の分量とテンプレート構成を踏まえ、2本から4本という目安を独自に設定しています。
07提案の正しさを検証する仕組み｜本誌の死にリンク検査
AIが出した候補をそのまま採用せず、機械検査で正しさを確認する仕組みが要ります。本誌はcheck_internal_refs.pyという検査を運用しています。検査項目は3種類です。
- 関連記事として設定したIDに対応する二重かぎ括弧の実タイトル参照が、本文中に実在するかを確認する
- 本文中の「」（一重かぎ括弧）の中身が、実在する記事タイトルと完全に一致していないかを確認する（表記統一の漏れを検出する）
- 本文中の『』（二重かぎ括弧）の中身が、実在するどの記事タイトルとも一致しない誤字・旧タイトル残存でないかを確認する
2026-08-08時点の実測では、検査対象は75本の記事です。このうち二重かぎ括弧による参照が105件検出されました（実測: 2026-08-08、qa/check_internal_refs.py実行結果）。いずれも実在するタイトルと一致していました。
この検査の実効性は、記事本数が増えるほど問われます。同じ検査を2026-08-08中に再実行したところ、検査対象は99本まで増えていました。二重かぎ括弧による参照は147件に増加していました（実測: 2026-08-08、qa/check_internal_refs.py再実行結果）。
147件のうち146件は実在するタイトルと一致していましたが、1件は実在するどの記事タイトルとも一致しない出力として検出されました。記事本数が75本から99本に増えるあいだに、参照の食い違いが実際に発生したことになります。人手でのレビューだけでは、この種の食い違いを本数の増加に比例して見落とすリスクが高まります。機械検査を運用し続ける理由は、ここにあります。
この差は、候補を出す工程と検証する工程を分けているからこそ、公開前に発見できたものです。生成と検証を同じ担当が兼ねていれば、この1件は見過ごされていた可能性があります。
この検査が捉えるのは、AIが提案した参照先が「本当に存在するか」という一点です。文脈が本当に関連しているかという判断は、機械検査の対象にしていません。文脈の妥当性は、提案理由を出力に含めさせたうえで、人がレビューする工程に委ねています。
08既製ツールの機能を自作プロンプトでどう代替するか
既製ツールを導入しない場合、その機能を何で代替するかを決めておく必要があります。次の表は、Link Whisperが持つ主な機能と、本誌がプロンプトと検査スクリプトで代替している方法の対応です。
| 機能 | 既製ツールでの実現方法 | 自作プロンプト＋検査での代替 |
|---|---|---|
| リンク健全性の可視化 | リンク切れ・404を検出するダッシュボード | check_internal_refs.pyによる実タイトル突合 |
| 候補の生成 | 文脈・キーワードを学習したモデルが提案 | 既存記事一覧を入力に渡すプロンプト |
| アンカーテキストの多様化 | 意味の近い言い換えを自動提案 | 「同じ語を繰り返さない」という制約の明記 |
代替を検討する手順は、次の2ステップに整理できます。
- 既製ツールの機能を1つずつ書き出し、どの機能が自社にとって必須かを判断する。入力は既製ツールの公式機能一覧、期待される出力は必須機能のリスト
- 必須機能ごとに、プロンプトの制約か、検査スクリプトのどちらで代替するかを決める。入力は必須機能のリスト、期待される出力は機能ごとの代替方法
表の3行を見ると、生成に関わる機能はプロンプト側で、検証に関わる機能は検査スクリプト側で代替する傾向が分かります。候補を出す工程と正しさを検証する工程を分ける、という本記事冒頭の結論と同じ構造です。
09内部リンク提案でつまずきやすい点
AIに内部リンクを提案させる運用では、次の点でつまずきやすくなります。
- 既存記事の一覧を渡さず、AIに存在するはずの記事タイトルを想像させてしまう
- 候補の本数を制限せず、本文が内部リンクだらけになってしまう
- 同じアンカーテキストを繰り返し使い、表記の単調さを検査できていない
- 提案理由を出力させず、文脈の妥当性を後から検証できない状態にしてしまう
- 記事のタイトルを改訂した際、既存記事側の参照表記を更新し忘れる
- 検証を機械検査だけに任せ、文脈が実際に自然かどうかを人が確認していない
10内部リンク提案の検証観点チェックリスト
- 既存記事の一覧（ID・タイトル・要約）を入力として明示的に渡したか確認した
- 参照先を既に執筆済みの記事だけに限定する制約を指示に入れたか確認した
- 候補の本数を、自社で定めた目安の範囲に収めたか確認した
- 提案理由を出力させ、文脈の妥当性を人がレビューできる形にしたか確認した
- related_articlesの指定に対応する実タイトル参照が本文にあるか機械検査したか確認した
- 本文中の『』の中身が実在するタイトルと一致しているか機械検査したか確認した
- 記事タイトルを改訂した際、参照している他記事側の表記も更新したか確認した
11FAQ
内部リンクの提案はAIに全部任せてよいですか
候補の生成はAIに任せられますが、正しさの検証は別の仕組みで行うことをおすすめします。本誌は提案の生成と、死にリンクの機械検査を別工程として分けています。
Link WhisperやInLinksを導入すれば、自作プロンプトは不要になりますか
不要にはなりません。既製ツールは候補生成を自動化しますが、記事間の実タイトル表記や自媒体固有の参照ルールは、自社の執筆規約に合わせて別途設計する必要があります。
内部リンクの本数に決まった正解はありますか
決まった正解はありません。本文中で示した既製ツール公式の目安は、あくまで一般的な参考値です。自社の記事の分量やテンプレート構成に応じて、独自の目安を設定してください。
死にリンクはどうやって検出すればよいですか
本文中の参照表記を、実在する記事タイトルの一覧と機械的に突き合わせる検査を作ることをおすすめします。本誌はcheck_internal_refs.pyで、参照表記と実在タイトルの不一致を検出しています。記事制作全体の分業設計は『AIで記事を作る工程設計｜構成から入稿までの分業表』にまとめています。
内部リンクの提案理由を出力させる意味は何ですか
理由が表層的なキーワード一致にとどまっているかどうかを、レビュー担当が見分けやすくするためです。理由の質を確認するだけで、文脈の関連性が薄い候補を効率よく除外できます。
