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