Sorry, this page is available in Japanese only.

2025 年 2 月から KODANSHAtech にジョインし、初めて WordPress 開発に携わることになりました。WordPress の基本的な思想やカスタマイズ方法など、ほとんど知識がない状態からのスタートでしたが、Claude Code のおかげで慣れていない技術スタックでも効率的に開発を進められています。

この記事では、数ヵ月間再現できず調査が難航していた不具合を、Claude Code を使って短時間で原因を特定できた事例を紹介します。

発生した不具合と調査の経緯

私が担当している AD ステーションでは、Yoast Duplicate Post プラグインと WordPress の標準的な権限グループ（寄稿者・編集者・管理者）を組み合わせた運用でコンテンツを管理しています。

Yoast Duplicate Post は、既存の記事を複製して編集・公開できる WordPress プラグインです。「Rewrite & Republish」機能を使うと、公開中の記事を複製して下書きとして編集し、完成後に元の記事と置き換えて公開できます。これにより、公開中の記事に影響を与えずに大幅な改訂作業を進められます。

この機能と WordPress の権限グループを組み合わせることで、寄稿者が記事を複製して編集し、編集者がレビュー・承認・公開まで行う、以下のようなレビューフローを実現しています。

※管理者権限は開発者が持っており、緊急時などに調査を行うために使用します。

発生した問題

ある日、寄稿者から「特定の投稿に対して Rewrite & Republish で複製できない」という問い合わせがありました。
CMS の画面を確認すると本来なら投稿に対してホバーを行うと表示されるはずの Rewrite & Republish のメニューが表示されておらず操作ができない状態でした。

正常時のスクリーンショット
正常時：Rewrite & Republish が表示されている状態
異常時のスクリーンショット
異常時：Rewrite & Republish が表示されていない状態

調査してみると、その投稿の複製がすでに存在しているため、新たに複製を作成できない状態でした。
不思議だったのは、データベース上には複製が存在しているのに、CMS の管理画面上には一切表示されないことでした。画面上に出てこないため、UI から複製の編集・削除などの操作ができません。そのため、暫定対応として SQL でデータベースから直接該当の複製記事を削除して解決しました。

再現が難しくプラグインの解析が必要になる

後日、原因調査を始めましたが、ローカル環境で全く再現できず、不具合時に本番のデータベースのスナップショットも取り損ねていたため、手がかりがない状態で調査は行き詰まっていました。

それから数ヵ月後、私が別の作業していると偶然ローカルで似た事象が発生しました。当時調査していたエンジニアに再現できているか確認したところ、同じ事象ではないことが判明しましたが、これをきっかけに当時の状況を整理することができました。

  • 管理者権限であっても、存在するはずの複製が CMS の一覧画面に出てこなかった
  • 寄稿者は所属する属性に応じて表示される投稿がフィルタリングされるカスタマイズを行っている（編集者・管理者はフィルタリングを行わない）

ここで 一覧画面に表示される・されない投稿 の条件が分かれば、原因を特定できそうな気がしてきました。
ただ、その条件を特定するには WordPress の仕様の理解や Yoast Duplicate Post プラグインのコード解析が必要であり、WordPress に詳しくない自分が調査するには時間がかかりそうだと感じていました。

Claude Code での解決プロセス

ここまで整理したところで、Claude Code に以下のようにお願いしました。

WordPress で管理者なのに Yoast Duplicate Post プラグインの Rewrite & Republish で作成した複製が一覧表示に出てこない。ローカルで再現できないので原因が分からず困っているので、原因調査してください。

すると、Claude Code は以下のような調査を進めてくれました。

  1. Yoast Duplicate Post プラグインのソースコード全体を解析: 正常なフローと異常なケースの違いを特定
  2. プロジェクトのカスタマイズコードを調査: 寄稿者権限に応じたフィルタリング実装を解析

そして、詳細なレポートを作成してくれました。レポートには以下の内容が含まれていました。

  • 正常な再公開(Republish)フローの詳細な説明
  • dp-rewrite-republishという特殊なステータスの仕組み
  • リダイレクト後のクリーンアップ処理が実行されないケースの特定
  • 具体的な再現方法
  • アーキテクチャ上の問題点の指摘

レポートで示された再現方法を試したところ、見事に事象を再現することができました。これにより、レポートの内容に対する信頼性がさらに高まりました。

生成されたレポートの一部

レポートの中で特に重要だった部分を抜粋して紹介します。

なぜ一覧に表示されないのか

WordPress は管理画面の投稿一覧で、publish、future、draft、pending、privateなどの標準ステータスのみを表示します。

Yoast Duplicate Post プラグインは、再公開処理中の中間状態としてdp-rewrite-republishという特殊なステータスを使用しています。

該当コード: plugins/duplicate-post/src/post-republisher.php:81-90

public function register_post_statuses() {
    $options = [
        'label'                     => \__( 'Republish', 'duplicate-post' ),
        'exclude_from_search'       => false,
        'show_in_admin_all_list'    => false,  // ← 一覧に表示しない
        'show_in_admin_status_list' => false,
    ];

    \register_post_status( 'dp-rewrite-republish', $options );
}

show_in_admin_all_listがfalseに設定されているため、このステータスの投稿は意図的に一覧から除外されます。

正常なフローとクリーンアップ処理

正常なフローでは、以下の流れで処理が進みます。

  1. ユーザーが複製記事の編集画面で「Republish」ボタンをクリック
  2. ステータスが強制的にdp-rewrite-republishに変更される
  3. 再公開処理が実行され、オリジナル記事の内容が更新される
  4. オリジナル記事の編集画面にリダイレクト
  5. リダイレクト先ページが読み込まれると、load-post.phpフックが発火し、クリーンアップ処理が実行される
  6. 複製記事が完全に削除される

問題のケース: リダイレクト後のクリーンアップに失敗するケース

クリーンアップ処理（ステップ 5）は、リダイレクト先のページが正常に読み込まれることを前提としています。

しかし、以下のような状況では、リダイレクト先ページが読み込まれず、クリーンアップ処理が実行されません。

  • ユーザーの操作による中断: ユーザーが「公開」クリック直後にブラウザやタブを閉じる、他のページに移動する、ブラウザがクラッシュする
  • ネットワークの問題: ネットワーク接続が切れる、タイムアウトが発生する
  • Nonce の検証失敗: Nonce の有効期限切れ、セッションタイムアウトなど

結果として、再公開処理は完了している（オリジナル記事は更新済み）にもかかわらず、複製記事がdp-rewrite-republishステータスのまま残ってしまいます。

なぜこの問題が発生しやすかったのか

原因が特定できたことで、腑に落ちる点がありました。
AD ステーションでは投稿の更新（再公開も然り）には、更新ボタンを押してから約 7 秒程度と、完了までにとても時間がかかります。
この原因は Advanced Custom Fields（ACF）で多くのカスタムフィールドを追加しているため、カスタムフィールドの数がパフォーマンスに影響し、更新処理が重くなってしまった結果です（裏を返せば最適化の余地があるということ……！）。

このため、編集者が再公開されるまでの間にページを閉じたり別ページに遷移したりすることで処理が中断されるケースが発生しやすくなっていたと考えられます。

問題への対応策

本質的な改善にはプラグイン側の修正が必要になるため、リポジトリにIssueを立てて相談中です。
プラグイン側の修正が入るまでは、運用でカバーする必要があります。そこで、WordPress のテーマを拡張してdp-rewrite-republishステータスの投稿を下記のように一覧画面に表示できるようにしました。これで編集者が画面から直接削除できるようになり、開発者が SQL を実行して削除する手間もなくなります。本番データベースに直接 SQL を実行するリスクも避けられるので、安心して運用できるようになりました。
dp-rewrite-republishステータスの投稿を一覧画面に表示

おわりに

今では開発のお供として Claude Code は必須ツールですが、これまではコードを書いてもらう用途が中心でした。
今回のようにこれまで解析を躊躇してしまうような大規模コードベースの調査にも活用できることが分かり、改めてその可能性を感じました。
もうひとつ良かったのは、WordPress の仕様を理解しながら調査できた点です。投稿ステータスの仕組みとかフックの動作など、WordPress 特有の概念って最初は分かりづらいんですが、Claude Code が解説しながら進めてくれるので、理解が追いつきやすかったです。
これまでは「ドキュメントを読んで基礎を学ぶ → 実装する」という流れが王道でしたが、「実際のコードベースを解析しながら学ぶ」というやり方もアリだなと思いました。
ぜひ皆さんも試してみてください！