Google Sheetsで管理しているSEOデータをもとに、被リンクが少ない記事へAIが内部リンクの候補を提案するツールを作りました。承認後は、WordPress記事へ自動で挿入します。
実測では、APIモードで約200記事を約50分で処理でき、コストは約1,500〜2,000円という条件で完了しています。
このツールは、内部リンクエージェントとWordPress自動反映機能の2つで構成しています。稼働中でv1.4.8まで継続的にアップデートしながら、複数のクライアント様に納品してきました。
この記事は、記事数が数百本規模になり内部リンクの見直しが追いつかなくなったメディア運営者やSEO担当者に向けて書いています。何ができるのか、どのくらいの効果が見込めるのか、自社に当てはまるのかを、具体的な数値とともに説明します。
内部リンク自動化ツールの仕組み｜何を入力すると何が出力されるか
このツールは、記事一覧のデータを入力すると内部リンクの候補と挿入先の見出しをAIが提案します。承認を経て、記事本文へ自動で反映するところまでを担います。
4つの工程で動く仕組み
処理はSpreadsheet読込→AIエージェントによる提案→人の承認→WordPressへの自動挿入という4つのフェーズで構成しています。SEOデータをGoogle Sheetsに用意しておけば、被リンクが不足している記事を特定できます。そのうえで、関連性の高い記事へのリンク候補と挿入位置の見出しをAIが提案します。
ただし、提案内容は人が確認してから反映する流れにしているため、AIの判断がそのまま記事に反映されるわけではありません。
入力に使うのは、記事ごとのURL・キーワード・被リンク数などをまとめたスプレッドシートです。
実際の画面（URL・記事名はダミーに置き換えています）
左側の列に既存記事の情報を並べておくと、H列より右にAIが提案したリンク候補が書き込まれます。処理が終わった行にはステータスが入るため、どこまで進んだかを表の上で追えます。
起動はチャットから行います。精度モードを選ぶと、あとは処理が流れます。
実際の画面（スプレッドシートのURLは伏せています）
処理が完了すると、スプレッドシートに候補が書き込まれます。そのうえで、WordPressへ挿入するかどうかを確認する流れです。
この仕組みの全体像は実績ページでも公開しています。
実行方法は2種類ある
処理の実行方法は2種類あります。追加コストがかからないCLIモードと、Anthropic APIを直接呼び出すAPIモードです。
CLIモードはClaude Desktop Proからのチャット指示で逐次処理する方式です。APIモードは5並列で処理する方式です。どちらも記事の規模や予算に応じて選べます。
なぜこの仕組みが必要だったか｜記事数が増えるほど深刻になる被リンク不足
記事数が多いサイトでは、被リンクが不足している記事を手作業で洗い出すのが大変です。関連記事の判断や見出し位置の特定、WordPressへの反映も同様です。
この状況を解決するために、AIによる提案と自動反映の仕組みを作りました。
同様の発想で、SEO記事制作そのものを自動化した際の進め方はSEO記事制作の自動化事例でまとめています。
あるサイトを分析したところ、CSVで管理していた231記事のうち213件が被リンク数1以下でした。これは全体の92%にあたります。
この結果は、記事数が増えるほど内部リンクの管理が人の手では難しくなるという課題の規模を示しています。
導入すると何が変わるか｜処理時間とコストの実測値
内部リンクの見直しにかかる時間とコストは、実行方式によって変わります。ここではAPIモードとCLIモードそれぞれの実測値を、測定条件とあわせて示します。
APIモードの処理時間とコスト
APIモード・5並列実行の条件で、約200記事の処理に約50分かかりました。このときのコストは、Claude Sonnetを使用して約1,500〜2,000円でした。
この条件から、まとまった記事数を短時間で処理したい場合に向いている方式といえます。
CLIモードでの処理量の目安
CLIモードは、Claude Desktop Proでのチャット指示をもとに処理します。1セッション(約5時間)で処理できる件数の目安は約25件でした。200記事を処理する場合、Claude Proの契約であれば約2日(8セッション)、Claude Maxの契約であれば数時間が目安になります。
そのため、追加のAPI費用をかけずに運用したい場合はこちらの方式が選択肢になります。
なお、初回実行時は全記事のHTML取得とキャッシュ作成を含むため、200記事で30〜60分程度かかります。導入直後の処理時間を見積もる際は、この初回実行の条件が前提になります。
品質をどう担保しているか｜AI判定の基準づくりと検証
内部リンクの提案は、AIが機械的にリンクを増やせばよいわけではありません。どの記事とどの記事をつなぐべきかという判断基準を、実際のサイト分析をもとに作り直しています。
内部リンクの評価基準をどう作ったか
実サイトを分析した結果、上位概念の記事から下位の詳細記事へつなぐパターンは効果的でした。一方、同じジャンルの記事同士を横並びでつなぐパターンは効果が薄いとわかりました。
この違いは点数にも表れています。旧プロンプトでは、同ジャンル横並びの記事ペアが72点で採用対象になっていました。評価基準を見直した新プロンプトでは、同じペアが15〜22点となり不採用に変わっています。一方で上位から下位へのパターンは新プロンプトで82点となり、採用対象として残っています。
AI採点で採用する記事の閾値は、60点(100点満点中)に固定して運用しています。
推測で実装を進めないというルール
開発では、根拠が薄い判断やその場限りの対応で実装を進めないようにしています。記事内のテキストをリンクだと決めつけて対応した実例があり、そこから判断に迷う場合は確認してから実装する方針に変えました。
また、テスト専用の機能も本番用のコードに含めず別ファイルに分離しています。クライアント様への納品時に、余計な機能が入り込むのを防ぐためです。
他人が運用できる形にするまでにやったこと
複数のクライアント様に納品する以上、自分の環境だけで動けばよいわけではありません。ここでは、他の環境でも安定して動く状態にするために向き合った不具合を、簡潔にまとめます。
WordPressの更新リクエストは成功のステータスを返すのに、実際には記事の内容が反映されない不具合がありました。原因は、登録していたURLがhttp形式のままだったことです。https側へのリダイレクト時に、更新内容が正しく保存されていませんでした。
この経験から、URLをhttps形式に自動変換する処理と、実際に保存されているかどうかを確認する検証ロジックを追加しています。
また、記事全体を対象にした重複チェックが原因で、指定した見出しへの挿入自体がスキップされる不具合も見つかりました。対応として、記事全体ではなくセクション単位で重複を判定する方式に切り替えています。
こうした不具合への対応を重ねてきたことが、複数の環境で継続して運用できている理由です。
導入実績
このツールは、脱SEOコンサルの中川裕貴さん（@ny__marketing）に導入いただいています。
運用の中で出てきたご要望をもとに機能追加を重ね、現在はv1.4.8まで更新しています。実際に使っていただく中で見つかった不具合や、運用環境に合わせた拡張の要望が、そのまま改善につながってきました。
どんな場合に向いているか
この仕組みが効果を発揮しやすいかどうかは、サイトの記事数と運用体制によって変わります。判断材料として、向いているケースを整理します。
- 記事数が数百本規模になり、内部リンクの見直しに時間がかかっている場合
- WordPressで記事を運用しており、REST API経由での更新が行える場合
- AIが提案した候補を人が確認してから反映する運用フローを許容できる場合
- 追加コストを抑えたい場合はCLIモード、処理速度を優先したい場合はAPIモードというように、実行方式を選べる場合
WordPressのバージョンが古く、認証方式に制約がある場合は、別の認証方法を検討します。この点は導入前に運用環境を確認しておくと、スムーズに進めやすくなります。
よくある質問
導入を検討する際によく聞かれる点をまとめました。
リンクの挿入はすべて自動で行われますか
AIが候補を提案するところまでで、実際の挿入は人が承認したあとに自動で反映されます。承認のステップを挟むことで、意図しないリンクがそのまま公開されることを防いでいます。
処理中にエラーで止まることはありますか
長時間の処理を続けると、Claudeの使用枠の上限に達して処理が止まる場合があります。この場合は表示されたリセット時刻(目安として約5時間ごと)まで待ち、同じ記事から処理を再開する運用にしています。
添付ファイルが多いと処理できなくなることはありますか
プロンプトが長大化すると、処理できないというエラーが表示されることがあります。この場合は添付したファイルを外して再送信します。それでも解決しない場合は、会話をリセットしてURLを送り直します。
WordPressのバージョンが古くても使えますか
WordPress5.6未満でApplication Passwordsという認証方式が使えないクライアント様の環境も実際にありました。この場合は、コード変更が不要な認証プラグインの導入を優先候補として検討しています。
最初から何百記事も一気に処理できますか
処理は可能ですが、初回実行は全記事のHTML取得とキャッシュ作成を含むため、200記事で30〜60分程度かかります。この条件を踏まえて導入直後のスケジュールを見積もると、見通しが立てやすくなります。
まとめ
内部リンクの見直しは、記事数が増えるほど手作業では追いつかなくなります。今回の仕組みは、被リンク不足の記事をAIが特定し、候補の提案から承認、WordPressへの反映までをつなげるものです。
処理時間とコストは実行方式によって変わります。まとまった記事数を短時間で処理したいならAPIモード、追加費用を抑えたいならCLIモードという選び方になります。
また、評価基準や重複検知の仕組みは実際のサイト分析と運用で見つかった不具合をもとに作り直してきました。
自社のサイトで効果が出るかどうかは、まず被リンクが足りていない記事がどのくらいあるかを見れば見当がつきます。今回の分析対象では、231記事のうち213件（92%）がその状態でした。
内部リンクの見直しにお困りの方へ
記事数が数百本規模になり、内部リンクの管理が手作業では追いつかなくなっている。WordPressで運用していて、リンクの貼り直しに時間を取られている。
どちらかに当てはまるなら、まず自社サイトの状況を数字で把握するところから始められます。
記事一覧のデータをご用意いただければ、被リンクが不足している記事がどのくらいあるかを洗い出し、内部リンクの候補をAIが提案する形までお見せできます。提案を人が承認してから反映する運用なので、意図しないリンクがそのまま公開されることはありません。
ご相談はスポット開発支援で承っています。まずは自社サイトの被リンク状況を確かめるところから、始めてみましょう。