記事の説明： 記事が大量にあるサイトで、検索に出てもクリックされないページをどう改善する？APIとAIで調査、優先順位付け、修正、確認をつなぐ方法と、暴走を防ぐ条件を解説する。
まず結論：人間が1万6000回クリックする必要はない
記事タイトルに問題があると気づいたとする。しかし対象が1件ならともかく、サイトに約1万6000ページもある。全部開いて、調べて、書き換えて、保存して、再確認する？ それは改善活動というより、マウスの耐久試験である。
ここで役立つのが、別のサービスへ必要な情報や操作を直接頼める仕組み、APIだ。AIが記事を読み、APIが検索データを集め、ファイルを保存する。人は方向性と安全条件を決め、例外を確かめる。もちろん、放っておけば必ず正解になる魔法ではない。
1. 手作業は記事数に比例して重くなる
仮に1ページの確認と修正が3分で済んでも、1万6000ページなら4万8000分、つまり800時間。これは計算上の例であり、実測ではない。1件ごとの作業が小さくても、件数が増えれば簡単に巨大な仕事になる。
しかも「1万6000ページ」は「1万6000本の独立した記事」と同じではない。1本の記事に12言語のページがあれば、同じ内容の仲間をまとめて管理した方がよい。ページ数と記事のまとまりを取り違えると、同じ内容を何度も直す事故が起きる。
2. APIは何をしてくれるのか
APIとは、サービス同士が決められた方法で情報をやり取りするための窓口だ。人が画面でボタンを押す代わりに、許された範囲でプログラムから情報を取得したり、ファイルを保存したりできる。
例えば、検索の実績を取得する窓口、記事の原稿を保存する窓口、決まった時刻に仕事を始める仕組みをつなげる。操作方法はサービスごとに違い、読み取り専用の窓口もある。APIがあるだけで、すべての操作が無料・無制限・自動になるわけではない。
3. AIが考え、APIが運ぶ
APIは「何を、どこへ送るか」が得意だ。AIは「このタイトルでは読者の疑問が伝わらないのでは」と文章を比較するのが得意だ。ただし、AIの提案が常に正しいとは限らない。
役割分担の例はこうなる。
- 検索データから改善候補を集める。
- 表示回数、クリック数、掲載順位、ページの内容を突き合わせる。
- AIがタイトルと本文の改善案を作る。
- ルールに通ったものだけ、APIを使って保存する。
- 一定期間の実績を見直し、改善したかを判定する。
人間の仕事は「1万6000件を手で直す」から「1万6000件に通用する判断基準を作る」へ移る。
4. クリックされない原因は、タイトルだけではない
検索に出ていないページと、表示されているのに選ばれないページは別問題だ。Google Search Consoleでは表示回数、クリック数、クリック率、平均掲載順位を調べられる。ただし、取得できる検索語や行には限界があり、すべての検索を完全に再現するものではない。
表示されないなら発見されていない可能性、検索需要、掲載順位などを調べる。表示されるのにクリックが少ないなら、タイトル、説明、検索者の期待を比較する。順位が極端に低いページを、タイトルのせいと決めつけてはいけない。犯人がタイトルだと思ったら、そもそも店が路地裏にあったという話かもしれない。
5. まず「直す価値のある記事」を選ぶ
全ページ一斉修正は、速そうでいて効果が読めない。公開後ある程度の時間がたち、検索表示と順位の実績があるページから始める。実務上は公開14日以上を最初の候補にする方法があるが、これはGoogleの公式な合格ラインではない。
次に、改善後の結果が分かる程度の表示回数、もともとの順位、直近の更新履歴を確認する。公開されたばかり、表示がほとんどない、すでに別の修正を試している記事は、急いで上書きしない。未表示の記事を「需要ゼロ」と断定するのも禁物だ。
6. タイトルだけ変えて本文を放置しない
悪い例は「便利なことを紹介」。何が便利なのか、誰のどんな疑問を解決するのか分からない。
例えば、この記事なら「APIで記事1万6000ページを自動改善できる？」と書けば、対象と疑問が見える。ただし、タイトルで自動改善を約束したのに本文がAPIの辞書的説明だけなら、読者を裏切る。
Googleの検索結果に出るタイトルは、ページの設定どおりに必ず表示されるわけではない。本文や見出しなどから自動的に作られることがあり、変更が検索に反映されるまで数日から数週間かかる場合がある。説明文も検索語に応じて変わる。したがって「保存した＝検索結果が変わった」ではない。
7. 12言語なら、12回の直訳では足りない
同じ記事を12言語で公開するなら、各言語の読者が普段どんな質問を検索するかを確かめる必要がある。日本語の「記事タイトルを改善する」を語順そのままで移すより、英語なら検索結果でクリックされない原因、ブラジル向けなら訪問が伸びない理由など、その言語で自然な入口から考える。
ただし、読者の期待に合わせるために事実を変更してはいけない。記事の主張と出典はそろえ、タイトル・導入・小見出し・例え・ユーモアは現地で通じる形に作り直す。1言語の修正を、残り11言語へ機械的に押し付けるのは「多言語対応」ではなく「誤りの国際配送」である。
8. 自動修正が暴走しない安全策
自動化の怖さは、間違いを人間より速く大量生産できることだ。よって保存前後に門番を置く。
- 読み取りと書き込みの権限を分け、必要最小限だけ許す。
- 記事の識別番号、言語、元の版を照合し、別の記事に書かない。
- 保存直前に元の版が変わっていないか確認する。競合したら読み直してから再試行する。
- すでに改善を試している記事は評価期間が終わるまで触らない。
- 最初は少数の記事で試し、機械検査と必要な人の確認を通してから広げる。
- 失敗、料金、利用上限、公開結果を記録し、元へ戻せる原稿を残す。
「修正ボタンを連打するAI」より、「怪しい時に手を止めるAI」の方が、長い目で見て頼もしい。
9. 本当に節約できるのは作業時間だけではない
APIで減らせるのはクリックやコピーの回数だけではない。毎回、同じ資料を開き、前回の判断を思い出し、作業の場所を探す手間も減る。一度判断基準を文章と検査にしておけば、新しい記事にも再利用できる。
一方で、最初に仕組みを作る費用、APIの利用上限、AIの誤判断、見直し作業は残る。大量に処理できることと、価値ある改善が大量にできることも別だ。処理件数だけを成功指標にすれば、1万6000回の無駄作業を1秒で実行する機械が完成する。
10. 改善を測るなら、変更前と変更後を比べる
修正前の表示回数、クリック数、順位、対象の検索語を記録する。修正日だけでなく、実際に検索へ反映されたかも確認する。14日・28日などで比較する運用は便利だが、Googleの保証期間ではない。表示回数の少ないページでは、短期の上下を勝敗として断定しない。
可能なら同じ条件の未修正記事も見て、季節変動や検索全体の増減を区別する。クリック率が上がっても訪問者の疑問が解決していないなら改善とは言い切れない。タイトル、本文、読者の満足までセットで確かめよう。
まとめ：ボタンを押す仕事から、仕組みを考える仕事へ
APIとAIの価値は、1万6000回の手作業を肩代わりするだけではない。「タイトルが弱いかも」と気づいた瞬間、その仮説を大量の記事で安全に調べ、直し、測れるようになることだ。
全部を一度に書き換える必要はない。効果を見ながら少しずつ広げればいい。人間は編集長、仕組みは働き者。ただし編集長が寝ている間に、全見出しを「衝撃の真実」に変えるアルバイトは雇わない。
参考資料（7件）
- Google Search Console API：検索実績の取得 https://developers.google.com/webmaster-tools/v1/searchanalytics/query
- Google 検索のタイトル表示 https://developers.google.com/search/docs/appearance/title-link
- Google 検索の説明文 https://developers.google.com/search/docs/appearance/snippet
- Google：役立つコンテンツの考え方 https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- Google：多言語サイトの管理 https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
- GitHub：ファイル保存時の競合と権限 https://docs.github.com/en/rest/repos/contents
- Cloudflare：定期実行 https://developers.cloudflare.com/workers/configuration/cron-triggers/
