ブログの内部リンク管理は、AIに公開記事の確認・一覧化・図の更新を任せ、人は案内先が読者に必要かを判断する形にすると進めやすくなります。
「新記事から関連記事へリンクは貼った。でも、既存記事から新記事へ来られるだろうか」。記事が増えるたびに、全ページを自分で開き、表と図を作り直すのは手間がかかります。
この記事では、AIへの依頼文を使って記事一覧・内部リンク全体図・変更履歴を作り、新記事の公開後も更新できる形に整えます。初回調査、新記事追加、修正後確認の3種類のプロンプトを載せました。2026年10月18日時点の方法と記録です。
この記事でわかること・準備するもの
- AIに渡す範囲と、調査結果で最初に確認する点。
- Notionに残す記事一覧・接続表・図・変更履歴の見本。
- 新記事を追加したとき、リンクを直したときの更新依頼。
準備の目安は約5分。 ブログURL、同じテーマの公開記事URLを3〜5本、Notionの保存先を用意します。調査と確認にかかる時間は、記事数とAIが閲覧できる環境によって変わります。
初回調査のプロンプトへ／新記事追加のプロンプトへ／修正後確認のプロンプトへ
LIFE STEP LABでは31記事・128組の本文リンクを調べ、本文からの入リンクが0の記事を1本確認しました。図と確認方法は後半の実例で紹介します。
利用前に確認： AIごとに公開ページを読める範囲は異なり、Notionへの保存には接続と権限が必要です。プロンプトを1回送るだけで継続監視は始まりません。リンクの表示を確認できても、クリック・順位・収益への効果は別に測ります。
この記事で使う「棚卸し」は、対象記事と本文リンクを一覧にすること。「接続表」は、リンク元とリンク先を1行ずつ記録する表です。「入リンク」は、ほかの記事本文からその記事へ来るリンクを指します。
AIに任せる作業と、人が判断すること
任せるのは調査と整理、判断するのはリンクを置く理由です。 AIが出した線や数字だけで、追加・削除を決める必要はありません。
AIには調査・記録・提案を依頼し、人が公開本文の修正を選びます。WordPressの編集や公開をAIに頼む場合は、対象記事と文案を別に指定します。
手順1：ブログURL・調査範囲・保存先を渡す
今やること：AIに渡すURLと、記録を残す場所を決める。
最初に用意するのは、次の3つです。
- ブログのURLと、最初に調べる3〜5記事の公開URL。
- 対象範囲。「この5記事間」なのか「全公開記事」なのか。
- Notionの保存先ページ。接続できなければ、あとで貼り付けるページ。
調べるのは本文中のリンク（関連記事カードを含む）です。メニュー・自動関連記事・前後記事ナビは対象外にします。下書きや固定ページも、最初は混ぜません。
サイトやNotionを直接見られない場合
AIに、実際に読み取れたページと読めなかったページを報告させます。閲覧できない場合は、対象記事の本文HTMLを、記事URLと対応させて渡す方法があります。
普通のテキストや画像だけでは、リンク先URLが分からないことがあります。その場合は、リンク元URL・リンク先URLを別に渡してください。検索結果の抜粋だけで、本文リンクの有無を確定させないようにします。
Notionへ書き込めなければ、表・図のコード・履歴を会話内に出してもらい、自分で保存すれば始められます。接続できない部分を「完了」にせず、できた作業と残った作業を分けるのがポイントです。
手順2：初回の棚卸しをAIに依頼する
今やること：下のプロンプトの角括弧を置き換えて依頼する。
次の依頼文は、この記事用に整理したひな形です。後半の実例を、この文面だけで再現したという意味ではありません。利用するAIの閲覧・保存機能に合わせて使ってください。
コピー用：初回調査のプロンプト
置き換える3項目：ブログURL／対象記事URL／Notion保存先。 接続できない保存先は「会話内へ出力」と指定します。
依頼文を表示・折りたたむ
私のブログの内部リンクを調査し、記事一覧・接続表・全体図を作ってください。
ブログURL：[ブログのURL]
対象記事：[公開URLを3〜5本、または全公開記事と指定]
Notion保存先：[ページURL。接続できなければ会話内へ出力]
対象は公開記事の本文にある記事間リンクです。本文中の関連記事カードと折りたたみ内のリンクを含め、共通メニュー・自動関連記事・前後記事ナビ・自己リンクは除外してください。
最初に、閲覧できる範囲とNotionへの保存可否を確認してください。全記事を対象にする場合は、記事一覧の取得元と調査件数、未取得の可能性も示してください。
記事名・公開URL・確認日時・本文の確認状態を一覧にしてください。リンクのない記事も残してください。
実際のリンクは「リンク元URL→リンク先URL」で記録し、リンク文または掲載見出し、確認状態、根拠となる本文箇所を添えてください。同じ元から同じ先は1組、逆向きは別組です。
設置済み・正常、設置済み・要修正、移動先未確認、未設置の追加候補を分けてください。開けないリンクも表から消さないでください。
対象内で正常な接続の入リンク・出リンクを集計してください。未確認は0にせず、対象のリンク元をすべて調べ終えてから入リンク0を確定してください。範囲外の接続は別記してください。
全記事の箱を残したMermaid図を作成し、確認済みは実線、未設置候補は破線にしてください。表を正本とし、図を抜粋する場合は対象範囲を明記してください。
本文からの入口不足と、サイト内のどこからもリンクされていない状態を区別してください。ホーム等を確認していなければ、サイト全体で孤立していると断定しないでください。
最後に、修正候補を最大3件、候補ごとの理由と設置場所案を示してください。関連性の薄い既存リンクも現状表に残し、削除候補の判断と分けてください。
指定先に今回の調査記録を追加してください。過去の図・履歴は削除せず、保存できなければ出力だけ行ってください。WordPressの編集・公開は行わないでください。返ってきたら、調査件数と根拠を先に見る
最初に見るのは、きれいな図より「何記事中、何記事を確認できたか」です。5記事の依頼に対して3記事しか読めていなければ、残り2記事は未確認として残します。
たとえば架空の3記事「A：始め方」「B：収益化の仕組み」「C：ASP3社比較」で、A→Bだけが確認済み、B→Cは未設置の候補なら、正常な接続は1組です。候補を接続数へ足さず、図には3記事の箱を残します。
手順3：Notionに「一覧・接続・図・履歴」を残す
今やること：AIの調査結果を、次回更新できる4つの記録にする。
会話だけに残すと、別の日に「何を対象に、どこまで調べたか」を引き継ぎにくくなります。保存先ページには、次の見出しを用意すると整理できます。
| 記録 | 残す内容 |
|---|---|
| 調査概要・記事一覧 | 調査日時、範囲、取得元、記事名・URL、確認済み件数、未確認記事 |
| 接続表 | 元URL・先URL、本文のリンク文や見出し、状態、確認日時 |
| 全体図 | 表に基づく矢印図。確認済みと候補、全件と抜粋を区別 |
| 提案・変更履歴 | 理由、人の判断、変更前後、変更日、再確認結果、次回確認日 |
最初から複雑なデータベースを作る必要はありません。1ページに表を分けて置けば試せます。記事管理全体の流れは、AI×Notionでブログ記事を管理する方法で紹介しています。
接続表の見本：事実と追加候補を別の状態にする
次は同じ架空例です。実際の表には、記事名だけでなくそれぞれの公開URLと本文の根拠を記入します。
| 接続と根拠 | 状態 | 判断 |
|---|---|---|
| A：始め方→B：収益化の仕組み。本文「収益の流れは〜」 | 設置済み・正常 | 維持 |
| B：収益化の仕組み→C：ASP3社比較。比較先を選ぶ説明あり | 未設置・追加候補 | 人の判断待ち |
「追加したい」と「すでにある」を同じ状態にしないことが大切です。開けない既存リンクは「設置済み・要修正」として残し、正常な接続の集計とは分けます。
図はAIにコードで残してもらう
次のコードも架空例です。A→Bは確認済み、B→Cは未設置候補として分かれています。画像だけで保存するより、元になるコードを残すと更新を依頼しやすくなります。
flowchart TD
A["A：始め方"] --> B["B：収益化の仕組み"]
B -. "追加候補・未設置" .-> C["C：ASP3社比較"]Notionで図として表示するときは、コードブロックの言語をMermaidにします。引用符は半角の " です。このコードをNotionへ貼って表示を確認してください。表示できない環境でも、接続表とコードを残せば再生成できます。Notion公式：コードブロック
手順4：AIの提案から、必要な修正を選ぶ
今やること：リンクを読む理由が説明できる候補だけを選ぶ。
「入リンク0だから、とにかく1本追加する」ではなく、どの記事の読者がその説明を必要とするかを見ます。
- 追加：仕組みを理解した人が、比較先を選べず止まっている。
- 修正：案内文とリンク先が一致していない。
- 削除候補：その箇所の疑問と関係が薄く、読む流れを妨げている。
AIには「リンク元のどの見出しの後に、どんな案内文を置くか」まで提案させると、判断しやすくなります。役割に迷う場合は、収益記事と集客記事の違いを基準の例にしてください。
必要な修正がなければ、修正不要で完了にできます。 Googleも、文脈に合う内部リンクと、リンク先が分かる案内文を勧めています。本数だけを目標にしないようにしましょう。Google公式：リンクの推奨事項
変更する場合は、対象記事と文案を確認してからWordPressへ反映します。操作手順が必要なら、WordPress内部リンクの貼り方を参照してください。AIが編集までできる環境でも、調査依頼だけで公開ページを変えさせない形にしておくと、判断と履歴をそろえられます。
手順5：新記事の公開・リンク変更のたびにAIへ更新を依頼する
今やること：新記事のURLか変更箇所を、前回の記録と一緒に渡す。
プロンプトを一度送っただけで、その後も自動的に監視・更新が続くわけではありません。まずは「新記事を公開したとき」「リンクを変えたとき」に依頼する運用で十分です。
コピー用：新記事を追加したときのプロンプト
置き換える項目：新記事URL／前回のNotion記録／確認範囲。
依頼文を表示・折りたたむ
新記事を公開したので、内部リンクの記録を更新してください。
新記事URL：[公開URL]
前回のNotion記録：[ページURL。読めなければ前回の表を貼り付ける]
確認範囲：[全公開記事、または指定URL一覧]
まず前回の調査日時・範囲・集計ルールを確認してください。前回の記録は実リンクの証拠にせず、今回の公開本文を読み直してください。
新記事から既存記事へのリンクと、既存記事本文から新記事へのリンクを両方調べてください。新記事への入リンク0は、対象の既存記事をすべて調べ終えてから判定してください。
読めない記事と確認範囲外の記事は未確認として残し、サイト全体で入口がないと断定しないでください。
入口が不足している場合は、関連する既存記事の設置場所・案内文・理由を最大3案示してください。未設置の案は実線や接続数に含めないでください。
今回の日時を付けて一覧・接続表・図・前回との差分を保存してください。比較条件が違えばその旨を記録し、前回の件数へ推測で足し引きしないでください。
保存先へ書けなければ更新案を会話内に出してください。WordPressの編集・公開は行わず、判断待ちで止めてください。コピー用：リンク修正後の確認プロンプト
置き換える項目：変更した記事URL／リンク先URL／変更内容と理由／Notion記録。
依頼文を表示・折りたたむ
次の内部リンクを変更しました。公開ページを確認し、記録を更新してください。
変更した記事URL：[リンク元の公開URL]
リンク先URL：[追加・修正・削除したリンク先]
変更内容と理由：[何を、なぜ変えたか]
Notion記録：[保存先URL。接続できなければ会話内へ出力]
編集画面の保存内容ではなく、公開本文を再取得して確認してください。追加・修正したリンクは、表示箇所・リンク文・実際の移動先を確認してください。削除した場合は該当箇所から消えているかを確認してください。
PCとスマホの表示確認ができる環境なら、文字・画像・カードのはみ出しも見てください。できなければ未確認として残してください。
変更日と確認日時を分け、変更前後・根拠・確認結果・未確認事項・次回確認日を履歴に追記してください。今回読めた範囲だけを更新し、全体件数の更新に再集計が必要ならその旨を示してください。
確認済みの接続を表と図へ反映し、過去の記録は残してください。保存できなければ更新案を出力してください。リンクが表示されたことと、クリック・順位・収益への効果は分け、計測していない効果を断定しないでください。履歴は、例えば「変更：C→Dを追加／理由：比較後に登録方法へ案内／確認：公開本文と移動先を確認／効果：未確認」のように残します。これは架空の記入例です。クリック計測がなければ、リンクを置いた時点で「回遊が改善した」と記録しません。
LIFE STEP LABでは、入口不足を調査記録から見つけた
LIFE STEP LABでは、公開記事の本文を照合し、内部リンクの全体図と変更履歴をNotionに残しています。ここで参考になるのは、過去の不足を直しても、新記事の入口は別に確認する必要があったことです。
2026年10月18日の調査時点では、公開31記事に128組の接続を確認しました。本記事は入稿中のため、この集計には含めていません。同じリンク元から同じ先への重複を除き、本文中のカードと折りたたみ内のリンクを含め、共通ナビなどを除いた記録です。
| 確認したこと | 調査時点の結果 |
|---|---|
| 他記事本文からの入リンク0 | ASP3社比較の1記事 |
| 出リンク0 | 0記事 |
| 過去に入口不足だった5記事 | いずれも本文からの入口を確認 |
実線は「始め方→収益化の仕組み」「収益化の仕組み→A8.net登録方法」「ASP3社比較→A8.net登録方法」です。「収益化の仕組み→ASP3社比較」は、調査時点では未設置の候補でした。
次は、収益化の仕組みの記事にあった登録方法への案内です。公開本文のリンク文と移動先を確認し、「収益化の仕組み→A8.net登録方法：正常」と接続表に残します。
ASP3社比較の記事はホームの新着一覧から開けたため、サイト全体で孤立していたとはいえません。また、本記事にも比較記事へのリンクがあるので、公開後は当時の「本文入リンク0」という状態が変わります。公開後の件数は再確認して追記し、推測で更新しません。
過去には、10月7日に既存13記事へ23本のリンクを追加し、10月13日には収益化の説明から登録時期の記事へつなぎ直し、関連性の薄いリンクを削除した記録もあります。追加だけでなく、残す・直す・削る判断を記録してきました。
10月4日の「27記事・89本」は当時の記録表記、10月18日の「31記事・128組」は今回の集計条件です。対象や数え方をそろえず、差を作業成果として単純比較しないようにしています。順位・PV・収益への効果は未確認です。
この記事の3つのプロンプトは、こうした確認ルールを依頼文へ落とし込んだひな形です。自動運用の成功実績や、どのAIでも同じ結果になることを示すものではありません。
まずは3〜5記事の調査をAIに頼んでみよう
今日やることは、公開URLを3〜5本選び、初回調査のプロンプトを送ることです。返答を確認し、次がそろったら最初の作業は完了にできます。
- 対象記事と確認日時、確認済み・未確認の件数が残った。
- 接続表にリンク元・リンク先と本文の根拠がある。
- 全体図で確認済みと追加候補を区別できる。
- 修正候補を選んだ。必要なければ修正不要と判断した。
- 記録をNotionへ保存した。直接保存できなければ、出力を貼り付けた。
その後は新記事の公開時に、既存記事からの入口もAIに調べてもらいます。調べる作業をAIに任せ、読む理由の判断と記録を人が引き継げる形にする。 そこから始めれば、全体図を作って終わりにせず、更新に使える管理記録にできます。
コメント