PIGNOTE
PIGNOTEは、運営担当がほぼ1人で回しています。
具体的には、コンテンツ戦略、執筆、入稿、サムネ作成、GA4・GSCでの計測、リライト判断までの、すべての作業です。
そんな環境で一番業務を効率化できたのが、Anthropic の Claude Code（ターミナルで動くAIエージェント）でした。本記事では、PIGNOTEで実際に動いている実装の中身を、媒体特有のハマりどころまで含めて公開します。
「AIで業務効率化」のような抽象論ではなく、具体的なAPI叩き方やWAF回避まで踏み込みます。
PIGNOTEのSEO運用フロー全体像
PIGNOTEのSEO運用は、おおまかに以下のフローで回しています。
| フェーズ | 作業内容 | Claude Code化 |
|---|---|---|
| 分析 | GA4・GSCでデータ取得・トレンド検出 | ◎ |
| 戦略 | カニバリ検出、リライト優先度判定 | ◎（候補抽出まで） |
| 制作 | 記事執筆、サムネ生成 | △（指示出しベース） |
| 入稿 | WordPress入稿、メタ設定 | ◎ |
| 計測 | 公開後の動向追跡、Slack通知 | ◎ |
担当者が判断するのは「戦略を立てる部分」と「最終OK出し」だけ。それ以外の手作業はほぼClaude Codeに渡しています。
1日のフロー例
朝：Claude Codeが自動でGA4・GSCをまとめた朝レポートをSlackへ通知。それを見て動向チェック
午前：順位やセッションが落ちている記事があれば「記事14006のセッションが先月から半減してる。GSCで直近の主流入KWと順位変動を出して、本文の見出し構成と現1〜3位を比較して、原因仮説を3つ挙げて」のように指示。Claude CodeがGSC・本文・SERPを横断的にチェックして、原因仮説と改善案を提示
午後：リライト・新規執筆。原稿のたたきはClaude Codeに作らせ、担当者はトーン・一次情報の差し込みに集中
夕方：入稿・サムネ生成・記事管理表更新は丸投げ、担当者は最終確認だけ
「機械的な作業はAIに、判断と表現は人間に」というシンプルな分業です。
実装1：WordPress REST APIで記事を入稿する
PIGNOTEはWordPressで動いており、入稿を完全自動化するには REST API（外部プログラムからWordPressを操作するための窓口）を叩く必要があります。ここで一番ハマったのが認証問題でした。
ロリポップのWAFが Authorization ヘッダー（本人確認情報）を剥がす
WordPressのREST API認証は通常、Application Password による Basic認証（ユーザー名とパスワードを直接送るシンプルな認証方式）で通します。ところが、PIGNOTEのサーバー環境（ロリポップ）では プロキシ（利用者とサーバーの間で通信を中継する仕組み）が Authorization ヘッダー（HTTPリクエストで本人確認情報を送る項目）をサーバーに到達する前に削除するという挙動があり、Basic Authが機能しません。
# Basic Authでは認証エラーになる(プロキシがヘッダーを剥がすため)
curl -u "user:app_password" https://www.pignus.co.jp/wp-json/wp/v2/posts/123
# → 401 Unauthorized解決策: カスタムヘッダー認証
WordPressの functions.php に、独自ヘッダーを受け取って認証する処理を追加します。
add_filter('determine_current_user', function ($user) {
$key = $_SERVER['HTTP_X_PIGNUS_API_KEY'] ?? null;
if ($key && hash_equals(get_option('pignus_api_key'), $key)) {
return get_user_by('login', 'pignus')->ID;
}
return $user;
});これでPIGNUS独自の合言葉（X-Pignus-Api-Key という名前のAPIキー）経由でアクセス元を識別できるようになり、curlコマンドから記事データを取得・更新できるようになり、サーバーからは 200 OK（「成功」を意味する応答コード）が返るようになります。
# カスタムヘッダー認証 → 通る
curl -H "X-Pignus-Api-Key: $WP_API_KEY" \
https://www.pignus.co.jp/wp-json/wp/v2/column/5005
# → 200 OKカスタム投稿タイプ（CPT）のエンドポイントに注意
PIGNOTEの記事は column というカスタム投稿タイプ（CPT、標準の「投稿」とは別建てで管理される記事タイプ）です。WordPress標準の記事用エンドポイントは /wp/v2/posts ですが、PIGNOTEはカスタム記事タイプのため /wp/v2/column/{id} を叩く必要があります。これに気付かず半日溶かしました。
WAF（不正アクセスを防ぐ仕組み）がブロックする記事タイプにも注意
shellコマンドや plist XML を本文に含む記事を入稿しようとすると、ロリポップのWAFが「攻撃と判定」してsilent fail（HTTP 200 が返るのに保存されない状態）で弾きます。HTTPは200で返ってくるのに、本文が更新されていないという困った挙動。
コードブロックを多用する技術記事は、本文部分だけ手動コピペが安全です。
実装2：サムネをHTMLテンプレート→PNGで自動生成する
サムネは HTML テンプレート（1200×630）を Headless Chrome でPNG化しています。テンプレートにカテゴリ・タイトル・アクセントカラーを差し込むだけで、統一感のあるサムネが数秒で量産可能です。
詳細は別記事で解説しています。
実装3：GA4を毎朝Slackに自動レポートする
GA4 Data API を Claude Code から MCP（Model Context Protocol、AIエージェントが外部ツールやAPIに接続するための共通規格）経由で叩き、前日比・前週比・直近リライト記事の動向まで含めた朝レポートをSlackに自動投稿しています。
実装の詳細・つまづきポイントは別記事にまとめました。
実装4：GSCデータからカニバリ・低CTRを検出する
PIGNOTE運用で最も「Claude Codeに任せて良かった」と感じているのがカニバリ検出です。
カニバリの3軸判定ロジック
Google Search Console の Search Analytics API で page × query 単位のデータを取り、以下3軸で判定します。
| 軸 | チェック内容 |
|---|---|
| タイトル軸 | 記事タイトルと実流入KWがマッチしているか（意図とコンテンツのズレ検出） |
| 実流入KW軸 | 同じKWで複数記事がランクインしていないか |
| imp軸 | impは取れているのに順位が35-55位で停滞 = 「正規ページ判定」が分散しているシグナル |
3軸すべてに該当する記事クラスタが見つかったら、それは統合候補です。
実際の検出は、Claude Codeに以下のような指示を出すだけで動きます。
「直近3ヶ月のGSCデータから、同一KWで複数記事がランクインしているクラスタを抽出して。imp上位の記事と、imp下位の瀕死記事を分けて表示」
すると、ページ×クエリの全データを取得→KW単位でグループ化→imp/順位の分布で判定、までやってくれます。担当者はその出力を見て統合戦略を決めるだけ。
統合判断は人間が、実装は Claude Code が
統合戦略（どの記事を主軸にし、どれを301で吸収するか）は人が決めます。Claude Codeは以下を引き受けてくれます。
- 各記事の本文をAPI経由で取得し、構造を比較
- 主軸記事に統合用のH2セクションをマージ
- 旧記事を Redirection プラグインの REST API で301設定
Redirection プラグインも REST API で操作可
Redirection プラグインの REST API /wp-json/redirection/v1/redirect は、先ほどのカスタムヘッダー認証でそのまま通ります。WP管理画面に入らずにリダイレクト設定までスクリプト化できます。
curl -X POST \
-H "X-Pignus-Api-Key: $WP_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"/column/content/1647/","action_data":{"url":"/column/content/5005/"},"match_type":"url","action_type":"url","action_code":301,"group_id":1}' \
https://www.pignus.co.jp/wp-json/redirection/v1/redirectAIエージェントに任せていい作業 / 任せてはいけない作業
ここまで「半自動化」と書きましたが、実際は任せていい/ダメな線引きを強く意識して運用しています。
任せていい作業
- データ集計（GA4・GSC API叩き）
- 機械的に判定できる検出作業（カニバリ、404、メタ抜け）
- 定型のAPI操作（入稿、リダイレクト設定）
- サムネ生成、画像リサイズ
- メモリーへの知見蓄積と引き出し
任せてはいけない / 慎重にすべき作業
- 記事の戦略判断（どの記事を主軸にするか、どのKWを狙うか）
- トーン・ブランドに関わる文章表現
- 既存記事の大規模リライト（AIに丸投げするとブランドの一貫性が崩れる）
- 公開直前の最終チェック（誤情報、URL間違いなど）
「戦略は人間、実装と運用はAI」という分業がうまくいく境界線でした。
まとめ
PIGNOTEで実装しているSEO運用の自動化を、実装レベルで公開しました。
| 自動化対象 | 効果 |
|---|---|
| WordPress入稿 | 1記事あたり10-15分の入稿作業がほぼゼロ秒 |
| サムネ生成 | デザインソフト不要、テンプレ流用で数秒生成 |
| 朝のGA4レポート | 毎朝Slackに自動通知、確認だけで済む |
| カニバリ検出 | GSCを1記事ずつ見る必要がなく、リスト化される |
「AIで業務効率化」と一括りにされがちですが、実装レベルまで踏み込まないと、本当の生産性は上がりません。とくにロリポップのようにセキュリティ制限があるレンタルサーバーでは、その環境に合わせた地道な調整が欠かせません。
PIGNOTEはこれから、AI Overview や Perplexity などの GEO（生成エンジン最適化）領域も、同じやり方で運用していきます。続報は別記事で書きます。
監修者
