このブログはWordPressで運営しています。そしてここ数週間、Claude Code(Anthropicが提供するAIコーディングツール)を使って、記事の作成・編集・SEO設定・品質監査まで、ブログ運用のほぼ全てをAIと一緒にやってきました。
結論から言うと、「できることは多い。でも限界もはっきり見えた」。
この記事では、Claude Code × WordPressで実際にやったこと、ぶつかった壁、そして次に専門ブログを立てるなら何を選ぶかを、全て体験ベースでお話しします。
Claude Code × WordPressでできたこと
WordPress REST APIを使えば、Claude Codeから記事の作成・編集・公開が直接できます。実際にやったことを挙げると:
- 記事のCRUD操作:新規作成、本文の編集、ステータス変更(下書き→公開)、カテゴリ・タグの変更まで全てAPIで完結
- 80記事の品質監査:全記事をAPIで取得して、文字数・構造・内容を分析。AdSense審査に不利になりそうな低品質記事を特定し、約10記事にnoindexを設定
- SEOメタ情報の設定:CocoonテーマのカスタムフィールドにREST API経由でSEOタイトル・メタディスクリプションを書き込み
- カテゴリの一括整理:「フリーランス」カテゴリを廃止して、該当記事を「ビジネス考察」に移行
- GSC・GA4のデータ分析:検索パフォーマンスを確認しながら、タイトル変更やリライトの判断をAIと壁打ち
WordPress REST APIでの記事自動化について、詳しくはこちらの記事でも書いています。

率直に言って、かなりのことができます。Claude Codeにブログの運用方針やルールをメモリファイルとして渡しておけば、文脈を理解した上で記事の執筆・編集をしてくれます。「この記事のSEOタイトル設定して」「この記事公開して」と言えば数秒で完了です。
GSC・GA4との連携についてはこちらも参考にどうぞ。


ここが限界だった
しかし、使い込むほどに「WordPressとAIの相性の悪さ」が見えてきました。
CocoonのカスタムフィールドがAPIで完全制御できない
一番痛かったのがこれです。Cocoonテーマには「noindex設定」「SEOタイトル」「メタディスクリプション」などのカスタムフィールドがあります。REST APIから値を書き込むことはできるのですが、削除が効かない。
具体的には、APIでnoindexを設定(”1″を書き込み)した後、解除しようとして””、”0″、0、false、null、”no”——あらゆる値を試しましたが、どれも効きませんでした。
原因を調べたところ、CocoonのUIはWordPressのupdate_post_metaで値を管理しているのに対し、REST APIは別のメタレコードを作成してしまうケースがある。結果、Cocoon UIからは見えない「幽霊レコード」が残り、UIで手動ON→OFFしないと消せないという状態に。
APIで設定できるのに、APIで解除できない。これはかなりストレスでした。
HTMLブロックの操作が冗長
WordPressのGutenbergエディタは、記事をHTMLブロックの集合体として管理しています。APIで記事を取得すると、こんな形式で返ってきます:
<!-- wp:paragraph --><p>本文テキスト</p><!-- /wp:paragraph -->
AIに「この段落を修正して」と頼むと、このブロック構造を壊さないように編集する必要があります。謎の<hr>タグが混入したり、リンクがブログカード形式にならなかったり、細かいトラブルが頻発します。
本来やりたいのは「文章を書く・直す」というシンプルな作業なのに、HTMLタグの整合性を気にしながら編集するという余計なレイヤーが挟まっている。これがAIとの共同作業を地味に非効率にしています。
記事がファイルではなくデータベースにある
WordPressの記事はMySQLデータベースに格納されています。つまり、記事を読むにも書くにもREST APIを経由する必要があります。
これが何を意味するかというと、Claude Codeの最大の強み——「ローカルファイルを直接読み書きできる」が活かせないということです。
もし記事がMarkdownファイルとしてローカルに存在していたら、Claude Codeは直接ファイルを開いて編集して保存するだけで済みます。APIのレスポンスを解析して、HTMLを組み立てて、POSTリクエストを送って……という手順が全て不要になる。この差は、使えば使うほど大きく感じます。
次に専門ブログを作るならHugo + GitHub Pagesを選ぶ
この経験を踏まえて、もし今からゼロで新しいブログを立ち上げるなら、Hugo + GitHub Pagesを選びます。
Hugoは、Go言語で書かれた静的サイトジェネレーターです。Markdownで記事を書くと、HTMLに変換して静的サイトを生成してくれます。
AIとの相性が圧倒的に良い
Hugo最大の魅力は、記事が全てMarkdownファイルであること。Claude Codeから直接ファイルを作成・編集できます。APIを叩く必要がない。HTMLブロックを気にする必要もない。
SEOタイトルやメタディスクリプションも、Markdownファイルの先頭にあるYAMLフロントマターで管理します。記事本文とメタ情報が1ファイルに収まっている。シンプルそのものです。
サーバー代が0円
Hugoで生成された静的ファイルは、GitHub Pagesに置くだけで公開できます。月額のサーバー代は0円。必要なのはドメイン代(年1,000〜2,000円程度)だけです。SSLもGitHub Pagesが無料で提供してくれます。
WordPressのレンタルサーバー代が毎月かかっている身からすると、この差は大きい。
SEOは不利にならない
「静的サイトってSEO的に大丈夫?」と思うかもしれませんが、むしろ有利です。
静的サイトはサーバー処理がないためページ表示が爆速で、GoogleがランキングのSEO要因にしているCore Web Vitalsのスコアが自然と高くなります。サイトマップやrobots.txtもHugoが自動生成します。OGPタグもテーマが対応しています。
今のGoogleが重視しているのはHTMLタグの構造ではなく、コンテンツの質と専門性(E-E-A-T)です。技術基盤で検索順位に差がつく時代ではありません。
WordPressの「便利さ」はHugoでも再現できるのか
「WordPressの管理画面って本当に便利じゃないですか。カテゴリ、タグ、ブログカード、目次、サイドバー……それと同じことがHugoでできないなら移行は厳しいですよね?」という疑問は当然あると思います。
結論から言うと、ほぼ全て再現できます。
カテゴリ・タグ:Hugoの標準機能(Taxonomy)として組み込まれています。記事のMarkdownファイル先頭にcategories: ["AI"]と書くだけ。カテゴリ・タグ別の一覧ページも自動生成されます。
ブログカード:Hugoの「ショートコード」という機能で実現できます。Markdownの中に{{< blogcard url="URL" >}}と書くと、ビルド時にカード型HTMLに変換されます。内部リンクなら、記事情報はビルド時に全て揃っているのでJavaScriptすら不要です。
目次の自動生成:Hugoの標準機能です。テンプレートに1行追加するだけで、見出しから自動的に目次が生成されます。
ヘッダー・サイドバー・フッター:レイアウトテンプレートで管理します。WordPressの子テーマと同じ発想で、テーマのデフォルトテンプレートを必要な部分だけ上書きできます。テンプレート言語はGoのhtml/templateで、PHPより簡潔です。
レスポンシブ対応:テーマが対応しています。ただし、Cocoonのような日本語圏向けの「全部入り」テーマは存在しません。海外テーマを選んで、必要なら日本語対応のカスタマイズを行う必要があります。ここがWordPress(Cocoon)との最大の差です。
管理画面がないことを「不便」と感じるかもしれませんが、Claude Codeと組み合わせるなら管理画面の代わりにターミナルとエディタで全て完結します。むしろGUIを介さない分、AIとの連携はスムーズです。
AIに記事を書かせるなら「体験談」が必須である理由
ここからが一番大事な話です。
Hugo + Claude Codeで効率的にブログを運用できる環境が整ったとして、じゃあAIに記事を量産させればいいのか? 答えはNoです。
AI量産記事はスパム扱いされる
2024年3月、Googleのコアアップデートで「Scaled content abuse」というポリシーが追加されました。AIを使って大量に記事を生成し、検索流入を狙う行為が明確にスパム扱いされるようになったのです。
実際に、AI量産サイトがインデックスから大量に消えました。「AIで効率よく記事を増やせば検索で勝てる」という時代は、始まる前に終わりました。
Googleが見ているのは「誰が書いたか」
GoogleのE-E-A-T(Experience, Expertise, Authoritativeness, Trustworthiness)の最初のE——Experience(経験)が、まさにここに効いてきます。
「Stable Diffusionのおすすめモデル10選」という記事は、AIが公式ドキュメントをまとめれば書けます。でもそれは、すでに大手サイトが同じことをやっている。
一方、「俺が実際に7モデル試して、このプロンプトでこの結果が出た」という記事は、その人にしか書けない。実際にこのブログのStable Diffusion記事群は、大量の生成画像と試行錯誤の過程を載せているおかげで、直帰率が0〜34%と異常に低い回遊装置になっています。
最強の運用は「体験 × AI推敲」
じゃあAIは使えないのかというと、全くそんなことはありません。むしろ、使い方を間違えなければ最強のツールです。
ポイントは「素材は自分、構成と推敲はAI」という役割分担です。
- 体験を殴り書きする:文章として成立していなくていい。箇条書きでも、メモ書きでもいい。「何をやって、何が起きて、何を感じたか」を記録する
- AIと壁打ちして構成を決める:殴り書きを元に、どういう記事にするか議論する。「この体験談、どういう切り口で書いたら面白い?」とAIに聞く
- AIに推敲させる:構成が決まったら、殴り書きを渡して「この内容を読み取って、記事として整えて」と指示する
- 自分で最終チェック:AIは論理の穴を見つけるのが苦手。断定が強すぎないか、主張が飛躍していないか、自分の目で確認する
この4ステップなら、体験という「その人にしか書けない素材」がベースにあるので、Googleにも読者にも価値のある記事になります。そしてAIのおかげで、構成と推敲にかかる時間が大幅に短縮される。
AIを使ったブログ記事の作成やリライトについては、以下の記事でも実践方法を紹介しています。


実際、このブログではGrok(Xの対話型AI)との壁打ちから記事のアイデアが生まれることも多い。AIとの雑談の中で「あ、これ記事になるな」と気づく瞬間がある。AIは執筆者であると同時に、ネタ出しの壁打ち相手でもあるのです。
まとめ:WordPressは「今」の現実解、Hugoは「次」の理想解
現時点では、このブログはWordPressで運営を続けます。80記事以上の移行リスクは大きいし、Cocoonテーマの恩恵(ブログカード、目次自動生成、レスポンシブ対応)を捨てるほどの理由はまだない。
ただ、次に新しい専門ブログを立ち上げるなら、迷わずHugo + GitHub Pagesを選びます。Markdownで書いて、git pushで公開。Claude Codeとの連携もシームレス。サーバー代は0円。
そして、どんな技術スタックを選んでも、一番大事なのは「自分の体験を書くこと」です。AIは推敲はできても、あなたの代わりに体験することはできません。体験を記録し、AIで磨く。この運用が、2026年のブログにおける最適解だと思っています。


コメント