生成AIが出来る前までのプラグインの作り方——PHPとフックの時代を振り返る

いまでは「AIに頼んで貼るだけ」でサイトの見た目を変えられるようになりましたが、ほんの数年前まで、WordPressのプラグインやテーマのカスタマイズは、まったく別の世界でした。この記事では、生成AIが登場する前のプラグイン開発がどういう営みだったのかを振り返ります。いまの便利さがどこから来たのかを知ると、AIとの付き合い方も見えてきます。

すべてはPHPと「フック」の理解から始まった

WordPressのプラグインは、本体が用意した「フック」（アクションとフィルター）に自分の処理を差し込む仕組みで動きます。生成AI以前は、これを使いこなすためにPHPの文法、WordPressの読み込み順序、テンプレート階層、データベース構造といった前提知識を、一つずつ自分の頭に入れる必要がありました。

学習の入り口は公式ドキュメント（Codex、のちのデベロッパーハンドブック）と、先人のブログ記事。「functions.phpに貼るだけ」のコピペスニペットが人気を集めたのは、裏を返せばゼロから書ける人が少数派だったからです。

典型的な開発の流れ

当時のプラグイン作りは、おおよそこう進みました。

• 要件整理 — 何をどのフックで実現するかを調べる。この「調べる」が一番長い
• 実装 — PHPを書き、ローカル環境（MAMP、XAMPP、のちにLocalやwp-env）で動かす
• デバッグ — 真っ白な画面（いわゆるホワイトスクリーン）と向き合い、エラーログを読む
• 保守 — WordPress本体やPHPのバージョンアップのたびに動作確認と修正

簡単なお問い合わせフォームひとつでも、nonce（CSRF対策）、サニタイズ、バリデーション、メール送信…と積み上げが必要で、動くものを作るまでの初期コストがとにかく高い。だからこそ「作れる人」と「使う人」がはっきり分かれていました。

「作れない人」はどうしていたか

プログラミングができない人の選択肢は、実質3つでした。既存プラグインを探して組み合わせる、開発者にお金を払って外注する、あきらめる。プラグインディレクトリに6万個ものプラグインが並んでいるのは、この「自分では作れないから探す」需要の大きさの表れでもあります。ただし探し物にはハズレも多く、更新が止まったプラグインを掴んでしまうリスクとも隣り合わせでした。

この時代が残した良いもの

一方で、この時代に築かれた文化には価値があります。コーディング規約、セキュリティのお作法（エスケープ・権限チェック・nonce）、後方互換性への執念。これらは生成AIの時代になってもまったく古びていません。AIが書いたコードの良し悪しを判断する基準は、結局この時代に積み上げられたものだからです。

次回は、生成AIの登場でこの風景がどう変わったのかを見ていきます。→ 生成AIが出来てからのプラグインの作り方