AIでコードを書くことが当たり前になりつつある現在、多くの人が「どう質問すれば良いコードを生成してもらえるか」を考えています。
プロンプトの言葉選びや、指示の出し方そのものに意識が向きやすいのは、ごく自然なことだと思います。
しかし実際には、それ以上に重要なことがあります。
それは「どのような条件を定義するか」です。
今回紹介するのは、WordPressで実際に行った小さなカスタマイズ事例です。
内容自体は、wpForoに添付した画像をElementorのLightboxでグループ化し、左右に動かして切り替えられるようにするというシンプルなものです。
しかし、この開発の過程には、AI時代の開発に共通する重要な考え方が含まれていました。
この記事では、その思考プロセスを振り返りながら、「条件設計」の重要性について紹介します。
今回実装したかったのは、wpForoの添付画像をElementorのLightboxで一つのギャラリーとして扱うことでした。
調査を進めた結果、Elementorは data-elementor-lightbox-slideshow 属性を利用して画像をグループ化していることが分かりました。
つまり、新しいLightboxを導入する必要はありません。
JavaScriptで必要な属性を付与するだけで目的を実現できます。
この時点で、AIは実装案を提示してくれました。
コードも問題なく動作します。
ここだけを見ると、「これで完成」と判断しても不思議ではありません。
しかし、私は一つだけ気になったことがありました。
コードそのものではありません。
頭の中でwpForoの添付ファイル機能全体を思い浮かべたとき、自然に次の考えが浮かびました。
もしそうなら、
なども、同じJavaScriptの対象になってしまう可能性があります。
現時点では問題が起きていなくても、将来的に添付ファイルの種類が増えたとき、思わぬ不具合につながるかもしれません。
なぜこの一点が気になったのか。
理由は、今のコードが「現在の使い方」だけを前提にしていたからです。
今は画像しか添付していなくても、運用を続けていけば添付ファイルの種類は自然と増えていきます。
その時に初めて不具合が発覚するようでは、原因調査にも余計な手間がかかります。
つまり「今動くこと」と「今後も安定して動くこと」は、似ているようで別の条件なのです。
この時点で考えたことは、とてもシンプルです。
「画像だけを対象にした方が安全ではないか。」それだけでした。
この一つの条件をAIへ伝えたことで、実装は次のように改善されました。
結果として、将来の運用まで考慮した保守性の高いコードになりました。
AIがコードを書いたのではなく、
が、今回の成功のポイントでした。
今回もう一つ重要だったのは、Lightbox自体を作り直さなかったことです。
実現方法はいくつも考えられます。
例えば、
この中で選んだのは、Elementorの既存機能をそのまま活かす方法でした。
JavaScriptで data-* 属性を追加するだけなので、ライブラリが増えず、競合しにくく、コード量も少なく、保守性が高いというメリットがあります。
これはWordPressカスタマイズ全般に共通する考え方です。
何か新しい機能を追加したくなったとき、「まず既存機能で実現できないか」を考えるだけで、サイト全体はシンプルになります。
逆に、中途半端な機能追加を繰り返すと、似たような機能が複数存在する状態になり、管理も難しくなります。
CSS設計でも同じです。
共通クラスを作れば済むところを、毎回新しいクラスを作ってしまえば、管理コストはどんどん増えていきます。
つまり、サイト全体で使い回せるものは、できるだけ使い回す。
この発想が、保守性の高い設計につながります。
AIは非常に優秀です。
条件が明確であれば、実装まで一気に進められます。
しかし逆に言えば、条件が不足している場合、AIはその不足した条件の範囲内で最適解を作ります。
つまり、「AIが間違えた」のではありません。
人間が定義していない条件までは考慮できないというだけです。
今回も最初のコードは間違っていませんでした。
当初の条件では正しい実装です。
しかし、「画像だけを対象にしたい」という条件が追加されたことで、さらに保守性の高いコードへ改善されました。
この役割分担を整理すると、次のようになります。
| 人間 | AI |
|---|---|
| 目的を定義する | 実装する |
| 条件を整理する | 条件を満たすコードを書く |
| 対象・対象外を決める | 指定された範囲で最適化する |
| 将来の運用を考える | 現在の条件を忠実に反映する |
では、人間は具体的に何を意識すればよいのでしょうか。
次の章では、この「条件設計」という考え方が、WordPressに限らず、どのような場面でも通用する原理であることを見ていきます。
このように考えると、AIとの共同開発とは、人間が設計し、AIが実装するという役割分担であることが分かります。
今回の事例はWordPressでした。
しかし、この考え方は他の分野でも同じです。
例えば、
どれも、「どんな条件で動かすのか」を最初に定義しなければ、期待する結果にはなりません。
具体的に見てみます。
「会員一覧を取得する」という指示だけでは、退会済みの会員も含まれてしまうかもしれません。
「ステータスが有効な会員のみ」「過去1年以内にログインした会員のみ」といったWHERE句の条件を定義してはじめて、目的に合ったデータが取得できます。
AIにSQLを書いてもらう場合も同じで、条件を伝えなければ、AIは「全件取得」という最も単純な解釈で実装してしまいます。
「フォルダ内のファイルを自動で整理したい」という要望について考えてみます。
こちらも、対象とするファイル形式・対象外とする拡張子・処理済みファイルの扱いといった条件を決めずに依頼すると、どうなるでしょうか。
可能性として、想定外のファイルまで移動・削除されてしまうリスクがあります。
今回のWordPress事例で「画像以外のファイルを対象外にする」と決めたのと、構造的には同じ判断です。
「外部APIからデータを取得する」だけでは、取得頻度・エラー時の挙動・取得対象期間といった条件が定まりません。
条件を決めずに実装すると、API側の利用制限に引っかかったり、不要なデータまで取得し続けたりする事態につながります。
このように、分野が変わっても考え方の骨格は同じです。
AIはコードを書くことは得意です。
しかし、対象は何か、対象外は何か、将来どんな運用になるかといった条件は、人間が考える必要があります。
だからこそ、AI時代では「コードを書く力」だけではなく、「条件を設計する力」の価値がますます高まっていきます。
AIの進化によって、コードを書くこと自体のハードルは大きく下がりました。
一方で、何を実現したいのか、どのような制約があるのか、将来どのような運用を想定するのかを定義する作業は、人間の役割として残り続けます。
今回のカスタマイズも、最終的に実装を改善したきっかけは、一つの小さな問いでした。
「画像以外も対象になる可能性はないだろうか。」
この問いが条件設計につながり、結果としてより保守性の高いコードになりました。
AI時代に価値が高まるのは、答えを知っている人ではありません。
今回のWordPressカスタマイズは、小さなJavaScriptの実装に見えるかもしれません。
しかし、その本質はコードそのものではありません。
重要だったのは、
でした。
AIは、与えられた条件を実装する優秀なパートナーです。
だからこそ、人間が担うべき役割は、コードを書くこと以上に「何を実現したいのか」「何を対象とし、何を対象外とするのか」を設計することへと変わりつつあります。
今回の事例はWordPressカスタマイズの一例ですが、その背景にある「条件設計」という考え方は、AIと共同で何かを作るすべての場面で活用できる、再現性の高い原理なのです。
AIへの指示よりも、「何を対象にし、何を対象外にするか」という条件設計です。
現在だけでなく将来の運用まで考慮しないと、不具合や保守コストの増加につながるためです。
新しい機能を追加せず既存機能を活かすことで、コード量を抑え、保守しやすい構成にできるためです。
人間が目的や条件を設計し、AIがその条件を満たす実装を担当するのが基本です。
はい。Python、自動化、SQL、API連携など、AIを活用するあらゆる開発や業務に応用できます。
投稿をシェアする
【Nexus AI 代表】Web制作・デザイン・マーケティング・コンサルティング等の経験を積み、日本 AIコミュニティ Nexus AIを立ち上げる。AI技術を活用して、コミュニティ運営に役立てている。
変化を起こし続けるなら、その人生には意味がある。
よく使うAI：OpenAI（ChatGPT, OpenAI APIなど）
好きなゲーム：The Witcher、サイバーパンク2077、Forza Horizon、RDR、その他多数
Web制作・デザイン・マーケティング・コンサルティング等の経験を積み、ChatGPTコミュニティ Nexus AIを立ち上げる。AI技術を活用して、コミュニティ運営に役立てている。
