Zenn
Open7

AIを使ったWordPressプラグイン開発

AI
PHP
WordPress
ChatGPT
Claude 3
せりぽよせりぽよ

もう粗方開発が完了してから記録するものではないと理解はしているが、AIを使ったWordPressプラグイン開発で思ったことなどを記録するよ。

今回WordPressプラグイン開発に使ったAI

  • ChatGPT
    • GPT-4
  • Perplexity AI
    • GPT-4 Turbo
    • Claude 3 Opus
せりぽよせりぽよ

各AIを開発に使った所感

当然、AIと言えどそれぞれで特徴がある。どのAIが良い悪いと言うのではなく、やりたい事に適したAIかどうかを考える事が重要だと思っている。

という訳で、開発する上で使ったAIに対するお気持ち表明をしておく。

GPT-4(OpenAI)

  • 安定の王道感。もともとChatGPTを課金してたことからそのまま利用。
  • 入力できるテキスト量が安定して多いのでコードファイルを添付しなくても修正指示を出しやすい。
  • 逆にファイルを添付するとプロンプトを工夫しないとファイルを分析読み込みしようとして出力に時間がかかりやすい。
  • それでもBard以外の後者2つよりかは出力スピードが一定してある程度早い。めっちゃ遅いとは感じない。
  • チャット量が蓄積されてくる中盤以降でも、やや出力スピードは遅くなるとしても明らかに後者より早いのでサクサク解決したい時にはこれがいいと思ってる。
  • 自分がコードを見ればざっくり何に対するコードかわかるけど細かくコードに対してコメントを追加したい時とかはコードを投げてGPT-4に「各コードで何を実行、取得、保存、処理しようとしてるのか初心者でも分かるように日本語でコメントを追加して」的なプロンプトでコメントを追加してもらってた。

GPT-4 Turbo(Perplexity AI)

  • GPT-4よりも出力するコードの精度が高いように感じる。
  • Perplexity上では若干Claude3 Opusより出力が早いかもしれない。
  • 同じ「細かく条件分岐するデバッグ用コードを作成する」プロンプトでも条件分岐の量がClaude 3 Opusより多めな印象。
  • 「Aを修正してください」のようなプロンプトに対する回答に更なる修正を求めるような場合、Claude 3 Opusよりも建設的に改善を試みる傾向にあるのが良い。
  • 何か知らんが唐突に出力が英語になることがある。日本語出力にしてくれと言っても治らないので、どうしても日本語出力にしたい場合は新規チャットを作る必要がある。
  • Perplexityは回答文に対して「AIを切り替えて書き直す」機能が搭載されているので、Claude 3 Opusが後述のように事故り始めたり回答に納得いかなかったりする時に同じプロンプトに対するGPT-4 Turboの回答を出力すると解決することが多い印象にある。

Claude 3 Opus(Perplexity AI)

  • 攻撃力が高い。ただし重い。RPGで言うところの物理特化キャラみたいなイメージ。
  • 攻撃力が高い=今回の中だと高精度なコードを出す割合が非常に多かった
  • Perplexity上だと最初の方のチャットだとファイルを添付しててもそこそこ早い。
  • ただしチャット量が蓄積してくる中盤以降は出力が重くなりやすく、ブラウザウインドウ自体が読み込みが遅すぎて、途中まで出力しても落ちる事も多かった。
  • ウインドウが落ちてリロードした後に入力したプロンプトに対する回答が出力されているかはガチャ。
    • すべての回答文が出力されているか、プロンプト自体を入力していないことになっているかのどちらか。
    • なので動作が重くなってきた中盤以降は処理落ちしてもいいようにプロンプトをコピーしておくと良い。
  • 「Aを修正してください」の回答に対して「修正されないから再度修正して」のように情報量が多くなってくると同じ提案をし続けたり、唐突に英語出力かつコードの提案をしなくなったりする事がある。
    • この場合はあきらめて新規チャットを作るかGPT4 Turboに切り替えた方が良い。

Bard(現Gemini)

  • 記事執筆やSEO、マーケティング分析などに向いているAIという印象が強い。
  • 同じプロンプトに対して回答パターンが3種類あるのはいいんだけども、少し入り組んだ内容のコード作成や修正を依頼する場合はどの回答を適用しても機能が実装されないことが多かった。
  • ただし流石Google開発AIなだけあり、開発方針についての壁打ちには適していた。方法論を多数提案してくれるので柔軟にやり方を考える指針にはなった。
  • でも開発では使おうと思えず、初期の初期で使用を中止した。
せりぽよせりぽよ

プラグインの開発背景

  • プロジェクト毎にWordPressに実装したい機能や使用するテーマは異なる。
  • そのため、WordPressの機能を拡張するには各プロジェクト毎にfunctions.phpに記載するコードを編集しなければいけない。
  • しかし、テーマ開発になれている人間はともかくそうじゃない人間がfunctions.phpを触るのはリスクが高い。
  • テーマ開発になれている人間が触るとしても、保有しているコードスニペットからプロジェクトごとに使用するコードを厳選してコピペするのは正直ダルいのが現実。
  • それであれば、WordPressテーマ開発への習熟度を問わずfunctions.phpを触る各機能を有効化できる手段があれば効率的では？と思い開発に至った。
せりぽよせりぽよ

プラグインを使用して欲しいターゲット層

  • 男女不問
  • WordPressでwebサイトを制作した経験が少なからずある
  • WordPressのデフォルト搭載機能に不満を持っていたり、もっと○○出来ればいいのにような願望を薄らとでも抱いたことがある。
  • 自分のwebサイトではなく、依頼により第三者のサイト制作を行うことが殆ど。
    • クライアントごとにサイトの目的や用途が異なるため、クライアントの利便性を考慮するとWordPressをカスタマイズできた方が良い
  • 制作する時は毎回同じテーマやブラグインの組み合わせで使用する訳ではなく、実装内容に応じて異なるテーマやプラグインを使う。
  • 導入したい機能の実装方法を調べた時に「functions.phpに以下のコードを追加し〜〜」のように、functions.phpに関する記載が出てくると「？？？」となる。
  • WordPressのコードを書く開発経験は少なめなので、できるだけコードを書かずにサイトを制作したい。
    • 駆け出しエンジニア
    • ノーコードでの制作をする
      • サイト製作者
      • メインはデザイナー など
せりぽよせりぽよ

ターゲット層の心情にありがちな事(随時更新)

  • WordPressでfunctions.phpの使用経験が乏しい
  • functions.phpを触ってやらかしたら嫌だからコードを触りたくない
  • functions.phpでどんな機能を実装出来るか把握しきれてない
  • 機能を拡張したいけど何をどうすればいいか分からない
  • WordPressに使いにくさや取っ付きにくさを感じている
  • このテーマを使うとプラグインAは不要だけどあの機能がないからプラグインBを使ってなどの組み合わせを考えるのがだるい
  • そもそも管理画面が使いにくくて納品する時にクライアントへ使い方を説明するのに苦労する。
  • クライアントに触らないで欲しいメニューを削除したい
  • クライアントにとって管理しやすいシステムであるに越したことはない。
  • サイト制作以外のオプション料金を取りたい
せりぽよせりぽよ

プラグイン開発の目的

functions.phpに記載しないと実装できない機能をプラグインの機能として有効/無効化できるプラグインを開発する。

開発における目標

  • コーディングを伴うWordPressでのサイト制作経験が少ない人でもfunctions.phpにコードを記載しなければ実装できない機能を使い分けられるようにする。
  • ノーコードでのサイト制作者やデザイナーでも直感的に操作できるUI設計での実装。
  • 利用者が第三者のwebサイトを制作する上で実装したいと思いがちな「痒いところに手が届くプラグイン」を目指す。
  • WordPressを触ったことがない初見ユーザーでも使いやすい管理画面を構築できる機能を失踪する。
  • 一部機能は有料でのみ利用可能とする。
せりぽよせりぽよ

開発方針について

  • Local by wheelを使用して構築できるローカルのWordPress環境を使用。
  • コマンド操作などはせず/wp-content/pluginsディレクトリにプラグインディレクトリを追加してから各ファイルを追加
  • できるだけ今後管理しやすいようになるべくファイルは分けて構築。
  • なるべく各コードにはAIを使用して誰が見ても何のためのコードか分かりやすいようにコメントを残す。
  • 個人的にdashiconsが直感的に分かりにくいと感じることが多いのでiconmoonを使用して作成したアイコンパックを追加する。
  • 実際にwebサイトを運用する人間と開発者が異なる場合を想定し、開発者が運用者にとって使いやすい管理画面を設計できるようにする。