SEO記事公開をAPIで自動化する仕組み【自社事例】
業務効率化支援を行う「Ai-Raku（アイラク）」代表。国立大学でAIの研究を行い、ITコンサル・ウェブコンサルを経て独立。官公庁向けの業務効率化や上場企業の支援等を経て、中小企業の現場に定着するAI活用を企画から運用まで一気通貫で支援している。
「SEO記事を量産したいが、品質が落ちるのが怖い」「WordPressへの入稿作業だけでも毎回手間がかかる」——コンテンツマーケティングに取り組む担当者から、こうした声をよく聞きます。
この記事は、他社事例の紹介ではなくAi-Raku自身が実際に運用している、SEO記事のリサーチ〜執筆〜品質チェック〜WordPress公開までの自動化の仕組みを一次情報として解説します。運用の中で実際に起きた失敗（文字数の数え間違い、日本語検索のバグなど）も含めて、包み隠さずお伝えします。
本記事では、WordPress REST API/WP-CLIでの公開自動化・公開前に必ず止める品質チェック・Search Console APIでの公開後監視を解説します。全体設計の考え方は広告・SNS・SEOをMCP/APIで自動化する方法もあわせてご覧ください。
- Ai-Rakuが実際に運用している「執筆→QAチェック→公開」の自動化フロー
- WordPress側の準備（アプリケーションパスワード・WP-CLI）
- 公開前に必ず止める3つのQAチェック（実際に起きた失敗事例つき）
- Search Console APIでできること／Google Indexing APIのよくある誤解
- 【モデルケース試算】記事公開作業を自動化した場合の削減時間
結論：リサーチ〜執筆〜QA〜公開までを自律パイプライン化する
結論から言うと、SEO記事の自動化で最も重要なのは「執筆をAIに任せること」ではなく「公開前に必ず人・仕組みが止める関所を作ること」です。AIによる執筆自体はすでに実用レベルにありますが、チェックを飛ばして即公開する運用は、事実誤認や表現の事故につながります。Ai-Rakuでは、執筆から公開までを自動化しつつ、公開直前に機械的なQAチェックを必ず挟む設計で運用しています。
自動化の全体像｜Ai-Rakuの実運用フロー
| 工程 | やること | 自動化の度合い |
|---|---|---|
| キーワード調査 | 検索ボリューム・競合性を調査し、記事プランを作成 | AIエージェントが調査、人が優先順位を確認 |
| 見出し作成 | SERP分析をもとに構成案を作成 | AIが作成し、必ず人の承認を得てから執筆に進む |
| 執筆 | 見出しに沿って本文・FAQ・モデルケースを作成 | AIエージェントが実行 |
| QAチェック | 文字数・表記・数値の整合性を機械的にチェック | 完全自動（不合格は公開させない） |
| WordPress公開 | WP-CLI経由で記事を投稿 | 自動（QA合格後のみ実行） |
| 公開後確認 | 表示崩れ・見出し数・CSSの反映を確認 | 自動チェック＋人の目視 |
ポイントは、「見出し確定」と「QAチェック」の2箇所に必ず人・機械の関所を設けていることです。ここを飛ばして全自動にすると、次に説明するような事故が実際に起こります。
【手順】WordPress側の準備
WordPressへの自動投稿には、主に2つの方式があります。
| 方式 | 仕組み | 向いている場面 |
|---|---|---|
| アプリケーションパスワード＋REST API | WordPress管理画面の「ユーザー→プロフィール」で発行した専用パスワードでAPI認証する | 比較的手軽に始めたい場合 |
| SSH＋WP-CLI | サーバーに直接SSH接続し、コマンドラインから記事を投稿・カテゴリ設定・メタ情報登録まで一括操作する | 投稿以外の細かい設定（カテゴリ・アイキャッチ・FAQ構造化データ）まで自動化したい場合 |
Ai-Rakuでは、記事本文の投稿だけでなくカテゴリの自動作成・FAQの構造化データ登録まで一括で行うため、SSH＋WP-CLI方式を採用しています。どちらの方式でも、認証情報は.envなど安全な場所で管理し、公開リポジトリに含めないことが大前提です。
QAゲートで公開前に必ず止める3つのチェック
ここからは、実際にAi-Rakuの運用で起きた失敗を含めて紹介します。いずれも「対策していなければ気づかず公開していた」種類のミスです。
1. 文字数はバイトで測らない
日本語はUTF-8で1文字あたり約3バイトになります。シェルのwc -cコマンドで文字数を確認すると、実際の文字数の約3倍の数値が表示され、「20,000」と出ても実際の文字数は約7,000字ということが起こります。この誤差に気づかず「文字数は足りている」と判断すると、実際には規定量に満たない薄い記事を公開してしまいます。Ai-Rakuでは、HTMLタグ・空白を除いた実文字数で判定するチェックスクリプトを必ず通してから公開しています。
2. Markdown表の残留
AIが生成した本文に| 項目 | 値 |のようなMarkdown形式の表がそのまま残っていると、WordPress上では変換されず記号の羅列として表示されてしまいます。公開前に、Markdown表をHTMLの<table>タグへ変換する処理を必ず挟み、変換漏れがないかを機械的に確認しています。
3. 数字の裏取り
「〇〇社の調査では効率が850%向上」のような、裏取りのない数字を実在企業に紐づけて書いてしまうと、サイトの信頼性を直接損ないます。Ai-Rakuでは、数字を出す場合は一次情報を検索して出典リンクを本文に置くことをルール化し、確認できない数字は水増しせずに削除する運用にしています。
実際に起きた失敗：日本語検索が「文字化けで全件マッチ」した話
これは執筆時ではなく運用中に起きた事例です。サーバー上でSSH経由のコマンドを使い、日本語の文字列を条件にデータベースを検索したところ、本来は数件しか該当しないはずが、公開済み記事すべてにヒットしてしまいました。原因は、シェル→SSH→データベースという経路の途中で日本語の検索文字列が壊れ、事実上「条件なしの検索」になっていたためです。対照実験（条件を変えずに全体件数を数えてみる）で異常に気づき、正しい件数を確認できる別の方法に切り替えて事なきを得ました。「日本語の検索結果が全件ヒットする」ときは、結果を信じる前にクエリそのものを疑う——この教訓は、AIエージェントに運用を任せる上で欠かせない視点です。
Search Console APIで公開後を監視する
Google Search Console APIを使うと、次のデータをプログラムから取得できます。（参考：Google Search Console API 公式リファレンス）
- 検索アナリティクス：クエリ・ページ別の表示回数・クリック数・掲載順位
- サイトマップ管理：サイトマップの一覧取得・新規送信・削除
- URL検査：特定ページがGoogleにインデックスされているかの確認
これらを定期取得する仕組みを組んでおくと、新しく公開した記事がきちんとインデックスされているか、想定した検索意図で表示されているかを、人が毎回手作業で確認しなくても把握できます。
Indexing APIの誤解｜通常記事は対象外
「記事を公開したらすぐにIndexing APIでインデックス申請すればいい」という情報を見かけますが、これは公式な使い方ではありません。Google公式ドキュメントによると、Indexing APIが正式にサポートしているのは「JobPosting（求人情報）」と「BroadcastEvent（ライブ配信の動画）」の構造化データを持つページのみです。（参考：Google Indexing API公式方針の解説）
通常のブログ記事にIndexing APIでURLを送信しても、Googleは「サポート外の形式」として無視する可能性があるとされています。SEO記事のインデックスを早めたい場合は、Indexing APIではなくSearch Console APIのサイトマップ送信・URL検査を使うのが正しいアプローチです。この違いを知らずにIndexing APIを実装してしまう例は多く、注意が必要なポイントです。
人が最終確認すべき工程
| 工程 | 自動化の可否 | 理由 |
|---|---|---|
| キーワード調査・記事プラン作成 | ◎ 自動化推奨 | データに基づく調査は機械が得意 |
| 見出し（構成）の確定 | △ 必ず人の承認を挟む | ここで筋を誤ると本文全体がズレる |
| 本文の執筆 | ○ 自動化可（QA通過が条件） | QAゲートで機械的に品質を担保する |
| 実在企業・団体に紐づく数字の記載 | ✕ 自動化しない | 裏取りのない数字は信頼性を直接損なう |
| 公開ボタンを押す最終判断 | △ QA合格を条件に自動化可 | チェックを1つでも飛ばさない設計にする |
「自社のオウンドメディア運用を、品質を保ったまま自動化したい」という方は、無料相談でご相談ください。
【モデルケース】記事公開作業を自動化した場合の試算
従業員9名のIT関連サービス業V社を例に、月8本のSEO記事更新・公開作業を自動化した場合の試算です。
※V社は実在の企業ではなく、中小企業によくある状況をもとにしたモデルケース（試算）です。数値は「時給換算2,500円・月20営業日」を前提とした試算で、実際の効果は業務内容や運用方法により変動します。
| 業務 | 導入前(時間/月) | 導入後(時間/月) | 削減時間(時間/月) | 削減額(円/月) |
|---|---|---|---|---|
| キーワード調査・記事プラン作成 | 10 | 3 | 7 | 17,500 |
| WordPress入稿・カテゴリ設定作業 | 8 | 1 | 7 | 17,500 |
| 公開後の表示崩れ・インデックス確認 | 6 | 2 | 4 | 10,000 |
| 合計 | 24 | 6 | 18 | 45,000 |
合計で月18時間・約4.5万円分の作業が削減される計算です。V社では、QAチェックで不合格になった記事は自動公開せず必ず人が見直す運用にしたことで、記事本数を増やしながらも表現の事故を防いでいます。
よくある質問（FAQ）
Q. 記事を量産すると評価が下がる？
A. 内容の薄い記事を大量公開すると評価が下がるリスクはあります。Ai-Rakuでは公開前のQAチェックで文字数・独自性を機械的に確認し、不合格の記事は公開しない運用にしています。
Q. Indexing APIですぐ反映できる？
A. いいえ。Indexing APIは求人情報とライブ配信動画向けの構造化データ専用です。通常のブログ記事にはSearch Console APIのサイトマップ送信・URL検査を使うのが正しい方法です。
Q. 自動投稿はどの方式がおすすめ？
A. 投稿本文だけならアプリケーションパスワード＋REST APIで十分ですが、カテゴリ自動作成やFAQ構造化データまで扱うなら、SSH＋WP-CLI方式がより柔軟です。
Q. AIが書いた記事の数字は信用できますか？
A. 一次情報の裏取りをルール化していない場合は注意が必要です。Ai-Rakuでは、出典を確認できない数字は本文に載せず削除する運用を徹底しています。
Q. 執筆から公開まで完全に無人化できますか？
A. 技術的には可能ですが、見出し確定の段階だけは必ず人の承認を挟むことを推奨します。ここを飛ばすと、記事全体の構成がズレたまま量産されるリスクがあります。
まとめ
- SEO記事の自動化は「執筆の自動化」より「公開前に止める仕組み」が本質
- 文字数はバイトではなく実文字数で判定する。誤ると薄い記事に気づけない
- Google Indexing APIは通常記事には使えない。Search Console APIのサイトマップ・URL検査を使う
- 見出し確定と最終公開判断には、必ず人・機械的なQAゲートを挟む
「自社のSEOコンテンツ運用を、品質を保ったまま自動化したい」という方は、Claude導入支援の無料相談をご利用ください。全体設計の考え方は広告・SNS・SEOをMCP/APIで自動化する方法もあわせてご覧ください。
