WordPress プラグインを生成 AI で保守する – サイクロマティック複雑度による制約と指針による複雑さの解決

WordPress プラグインによるサイトのカスタマイズやサービス間の連携強化は、開発後の運用も見据える必要があります。WordPress 本体の変更や連携先のサービスのアップデート・仕様変更、そして PHP のバージョンアップなど、様々な理由でプラグインの運用保守作業が発生します。

これらの作業を効率化するために、デジタルキューブでは生成 AI（コーディングエージェント）を導入しています。しかしコーディングエージェントを運用する上で、「AI が生成したコードや変更を人間が把握し切れるのか」という問題が新たに浮上しました。AI が生成したコードは確かに動作するものの、数ヶ月後に保守できるのか。複雑な条件分岐を含むコードを AI が生成した場合、それを人間がレビューし、理解し続けることができるのか etc…

この記事では、これらの問題を軽減させる挑戦として、「サイクロマティック複雑度」を試した経験について紹介します。「サイクロマティック複雑度」という制約を実装方針に含めることで、脳に収まるコードを AI が生成するのではないか。この仮説についての試行錯誤を紹介します。

サイクロマティック複雑度とは

サイクロマティック複雑度とは、プログラムの複雑さを測る指標の1つです。if / switchなどの処理が分岐する場所や for / map などのループ処理の数を数え、「分岐の数 + 1」の多寡でコードの複雑さを評価します。

例えば以下のコードは、ifが1つ、三項演算子による分岐が1つ、そして for でのループ処理が1つあるため、サイクロマティック複雑度は 4となります。

function greedings( members ) {
  const messages = []
  if (!members) return null
  for (const member of members ) {
    messages.push(`Hello ${member.name ? member.name : ‘john’}`)
  }
}

サイクロマティック複雑度が心理学者ジョージ・ミラーが提唱した「マジカルナンバー7±2」(人間が短期記憶に保持できる情報の数)における「人間が短期記憶に保持できる情報の数」とされる 7 を下回るかどうかを、今回のコーディングエージェントに対する制約と設定しました。

コードレビューにて見つかった技術負債

今回コーディングエージェントによるコードレビューを実施した WordPress プラグインでは、7を超える複雑度を持つメソッドが8つ存在し、最も複雑なものは複雑度10から12に達していることが判明しました。

さらにコーディングエージェントは複雑性を高めている分岐の中身についても調査を実施し、それにより複雑度の 70 % がデバッグログを出力するための処理系統であることを突き止めました。これはプラグインを設定した顧客からの調査依頼に対応するために後から追加した機構で、その時の要件を満たしてはいたものの、意図せずコードの複雑性を高めていたものと思われます。

複雑化しているコードを少し見てみましょう。次のコードでは、ただログを残すだけでなく、ログを残すかどうかの判定処理も含まれています。しかしログを残すためだけに、サイクロマティック複雑度を 2ポイント増加させていました。

    if ( $this->hook_service->apply_filters( 'c3_disabled_cron_retry', false ) ) {
        if ( $this->log_invalidation_params ) {
            error_log( '===== C3 CRON Job registration [SKIP | DISABLED] ===' );
        }
        return false;
    }

調査と制約に基づくリファクタリング

この発見に基づいて、AI は WordPress プラグインの設計パターンに沿った改善提案を行いました。Debug_Logger という専用クラスを作成し、デバッグ機能を集約するという方針です。これにより、WordPress のフィルターフックや`define()`関数によって定義された定数などでログ機能が有効化されているかの判定処理をメインの処理から隠匿します。

これはサイクロマティック複雑度を改善するだけではありません。WordPress プラグインの保守において、メソッドの複雑度が低いということは、新しいメンバーがコードを理解しやすく、バグ修正の影響範囲を予測しやすく、ユニットテストを書きやすいということを意味します。プラグインの長期運用において、これらは極めて重要な要素といえるでしょう。

生成 AI にとっての「外のモノサシ」を定義する

生成 AI / コーディングエージェントが意図した通りに動かない場合、多くの場合はコンテキストが不十分であると言われています。例えば 2025 年に開催された Open AI DevDay でのセッションでは、実行計画の整備や計画書の作成などの重要性が紹介されていました。

生成AIがモデルのトレーニングによって手に入れたモノサシではなく、その会社・プロジェクトに適したモノサシを使えるようにする。これからの AI コーディングでは「外のモノサシ」を AI に渡すという考え方が必要になるのではないでしょうか。

また、プラグインやアプリケーションコードをサイクロマティック複雑度で計測し、複雑さを解消することは、人間にとっても効果的な施策です。複雑度が低いコードは、新しいメンバーのオンボーディングが容易で、WordPress や PHP のバージョンアップへの対応もスムーズになります。プラグインを5年、10年と運用し続ける上で、技術負債の削減は単なる開発効率の改善ではなく、プロダクトの持続可能性そのものに関わる重要な要素といえるでしょう。

AI コーディングツールは、適切な制約と WordPress 固有の知識による監督があれば、長期運用されているプラグインの保守性を大幅に改善する強力なパートナーになり得ます。「自分たちのモノサシがどんなものか」を振り返り、生成 AI にとっての「外のモノサシ」をどう渡すのが良いかを考えていきましょう。