記事を書いて公開した後、「どの既存記事から内部リンクを張るべきか」を毎回手作業で考えるのは地味に大変です。そこで、Search Consoleの露出データと記事の被リンク数を突き合わせて、改善すべき記事を自動で特定し、修正をdraft PRとして提案する仕組みをGitHub Actionsで作りました。本記事はその設計と、あえて「完全自動」にしなかった理由の記録です。

やりたかったこと

• 毎週、検索露出（インプレッション）はあるのに内部リンクが少ない記事を見つけたい
• そこへ関連性の高い既存記事から内部リンクを自動で足したい
• ただし本番には勝手に反映せず、レビューしてからマージしたい

仕組みの全体像

毎週月曜（GitHub Actions・定期実行）
  1. Search Console API で各ページの露出を取得
  2. 記事本文をスキャンして「被リンク数」を集計
  3. 露出あり × 被リンク少 の記事を抽出（高ROI候補）
  4. 同カテゴリで関連度の高い既存記事を選び、内部リンクを追記
  5. 変更を draft PR として作成し、チャットに通知
        ↓
  人がレビューして問題なければマージ

ポイントは、修正を 決定論的（自サイト内リンクの追加のみ） に限定したことです。AIに本文を書き換えさせると品質や規約面のリスクが出ますが、「関連記事ブロックを足すだけ」なら壊れにくく、レビューも一瞬で済みます。

「露出 × 被リンク数」で優先度を決める

改善の優先順位は、次の2軸の掛け合わせで決めます。

軸	取得元	意味
検索露出（インプレッション）	Search Console API	すでに検索で見られている＝伸ばす価値がある
被リンク数（本文内の内部リンク）	記事ファイルの走査	少ない＝オーソリティが集まっていない

「露出はあるのに被リンクが少ない」記事は、少し手を入れるだけで順位が動きやすい最優先ターゲットです。逆に露出ゼロの記事をいくら補強しても、効果は出にくい。限られた時間を、効く場所に集中させるための指標です。

冪等にするためのマーカー

自動追記が毎週重複しないよう、追記ブロックをコメントマーカーで囲み、再実行時はその中身を上書きします。

<!-- seo-auto-related:start -->

## あわせて読みたい

- [関連記事タイトル](/category/slug/)

<!-- seo-auto-related:end -->

注意点として、MDX（.mdx）ではHTMLコメント <!-- --> が使えません。MDXでは {/* */} 形式のコメントを使う必要があり、ここを間違えるとビルドが壊れます。ファイル拡張子でマーカーを切り替える実装にしておくと安全です。

あえて「完全自動マージ」にしなかった理由

技術的には、PRを自動でマージすることも可能です。それでもdraft PRで人のレビューを挟む設計にしたのは、過去に「無確認の変更が長期間気づかれずに事故になった」経験があるからです（別記事のGA4計測ゼロ問題もその一例）。

• コンテンツの改変は規約・事実確認の観点で人の目を通すべき
• 自動で本番を変え続けると、誤りを誰も止められない
• draft PR ＋ 通知なら「人はマージを承認するだけ」で、手間はほぼゼロ

自動で働かせるが、最終承認は人。これがコンテンツ運用における自動化の現実的な落としどころだと考えています。

認証はリフレッシュトークンをSecretsに

Search Console APIをCIから叩くには、OAuthのリフレッシュトークン（webmasters.readonly スコープ）をGitHub Secretsに保存し、環境変数から認証します。ローカルで一度だけ同意フローを通してトークンを取得すれば、以降はブラウザ操作なしで定期実行できます（同じ要領でGmail監視などにも応用できます）。

まとめ

• 「露出 × 被リンク数」で改善対象を機械的に決めると、効く場所に集中できる
• 修正は決定論的（内部リンク追加）に限定し、draft PRでレビューを挟むと安全
• MDXのコメント記法の違いなど、細かい落とし穴に注意
• 「自動で働く・人は承認だけ」にすると、継続的なSEO改善が片手間で回る

---

※ 本記事は当方の実運用での構築をもとにした技術メモです。具体的なトークンやシークレット名は伏せています。