PR

AIへの指示がうまくなりたいなら、この視点を持っておこう｜LP制作で学ぶ設計思考

副業

「AIがコードを書いてくれるなら、もう自分で勉強しなくていいんじゃ？」

そう感じたことがある方も多いと思います。ChatGPTやClaudeに頼めば、それらしいHTMLやCSSがすぐに出てきます。使わない手はありません。

ただ、実際にAIを使って開発していると、こんな場面に出くわしませんか？

  • 指示が曖昧で、的外れなコードが返ってくる
  • とりあえず動くけど、後から直せなくて困る
  • 生成されたコードの意味がわからず、バグに対応できない

これらはすべて、「設計の視点」が抜けていることで起きます。AIは実装は得意ですが、「何をどう作るか」の判断はあなたがするものです。その判断の質が、そのままAIへの指示の質になります。

この記事では、LP（ランディングページ）制作を例に、AIへの指示力が上がる7つの設計視点を紹介します。難しい話ではありません。知っておくだけで、AIとのやり取りが変わります。

AIへの指示がうまくなりたいなら、この視点を持っておこう

「AIがコードを書いてくれるなら、もう自分で勉強しなくていいんじゃ？」

そう感じたことはありませんか？確かに、ChatGPTやClaudeにお願いすれば、それらしいHTMLやCSSがすぐに出てきます。便利な時代になったのは間違いありません。

でも、実際にAIを使って開発をしてみると、こんな壁にぶつかる人が多いです。

  • 指示が曖昧すぎて、使えないコードが返ってくる
  • とりあえず動くけど、後から修正できなくて困る
  • AIが生成したコードの意味がわからず、バグを直せない

これらはすべて、「設計の視点」が抜けていることから生まれる問題です。

AIに良い指示を出すためには、その分野の知識が必要です。何を作るか、どう構成するか、なぜそう設計するか——そういった判断軸を持っていると、AIへの指示は格段に具体的になり、返ってくるコードの質も上がります。

この記事では、LP（ランディングページ）制作を例に、エンジニアとして知っておくと「AIへの指示力」が上がる設計の視点を紹介します。WordPressやECサイトにも通じる考え方なので、ぜひ最後まで読んでみてください。

AIが得意なこと、苦手なこと

まず前提として、AIはコードを書くのがとても得意です。「ボタンのCSSを書いて」「レスポンシブ対応にして」といった具体的な実装依頼には、かなり精度よく答えてくれます。

一方で、AIが苦手なのは「設計判断」です。

  • このLPは使い回すのか、一回きりなのか
  • 後からセクションを追加する可能性があるか
  • 他のメンバーも触るコードなのか

こういった文脈や背景はAIには判断できません。あなたが指示として渡してあげないと、AIはとりあえず「動くもの」を作るだけです。

だからこそ、設計の視点を持っている人ほど、AIをうまく使いこなせます。「どう指示するか」の質が、アウトプットの質を決めるのです。

LP制作は設計思考を学ぶのにちょうどいい

LP（ランディングページ）とは、広告や検索から訪れたユーザーが最初に目にする1枚のページです。商品紹介、サービス申し込み、イベント告知など、目的はさまざまですが、基本的には1ページで完結します。

シンプルに見えますが、このLP制作には実にさまざまな設計判断が含まれています。規模がコンパクトな分、「考え方を学ぶ入口」としてとても適しています。

では、具体的にどんな視点を持っておくといいのか、見ていきましょう。

視点1：「単発か、複数展開か」を最初に決める

LPを作り始める前に、まず確認したいのが「このLPは使い回すのか」という点です。

たとえば春のキャンペーン用にLPを作ったとします。夏にも似たキャンペーンをやる予定があるなら、最初からテンプレートとして設計しておくべきです。逆に完全に一回限りなら、再利用性より「今すぐ仕上げること」を優先した方が合理的です。

AIへの指示がこう変わる

この判断を持っていると、AIへの指示が具体的になります。

曖昧な指示：「LP作って」

良い指示：「このLPは季節ごとに使い回す想定です。ヘッダーとフッターは共通パーツとして分離して、メインコンテンツは差し替えやすいセクション構成にしてください」

前者ではAIは「とりあえず動くもの」を作ります。後者なら再利用しやすい構成のコードが返ってきます。指示の中に設計の意図を含められるかどうかが、アウトプットの質を左右します。

視点2：関心の分離（HTML・CSS・JSを混ぜない）

「関心の分離」とは、それぞれの役割を持つコードは別の場所に書くべき、という考え方です。

  • HTML → ページの構造（何を表示するか）
  • CSS → 見た目（どう見せるか）
  • JavaScript → 振る舞い（どう動くか）

この考え方はアプリ開発の「MVC（Model-View-Controller）」という設計パターンと同じ発想です。それぞれの責任を明確に分けることで、修正しやすく、読みやすいコードになります。

よくある悪い例として、HTML内に直接スタイルを書いてしまうケースがあります。

悪い例：
<div style="color: red; font-size: 20px; margin: 30px auto;">申し込みはこちら</div>

これは動きますが、色を変えたいとき・サイズを調整したいとき、HTML内を全部検索して直す必要があります。管理が煩雑になり、ミスも増えます。

良い例：
<div class="cta-button">申し込みはこちら</div>
（スタイルはCSSファイルの .cta-button にまとめて書く）

AIが生成するコードは、style属性をHTMLに直書きすることがあります。「動いているからOK」と見落としがちですが、保守性の観点では良くありません。

AIへの指示がこう変わる

曖昧な指示：「CTAボタンを作って」

良い指示：「CTAボタンをHTML+CSSで作ってください。styleはインラインで書かず、CSSクラスとして分離してください」

関心の分離を知っていると、こうした具体的な制約を指示に含められます。すると、保守しやすいコードが返ってきます。

視点3：命名規則（名前は設計の一部）

「命名規則」とは、クラス名や変数名のつけ方のルールです。難しそうに聞こえますが、要するに「後から見てもわかる名前をつけましょう」ということです。

たとえばお申し込みフォームのセクションに、こんなクラス名がついていたとします。

  • box1 → 意味不明
  • red-section → 見た目だけ（色が変わったら嘘になる）
  • contact-form → 役割が一目でわかる

クラス名を見るだけで「ここが何をするセクションか」わかることが大切です。

LPのCSSでよく使われる命名規則に「BEM」があります。Block（塊）・Element（要素）・Modifier（バリエーション）の頭文字をとったもので、こんな形で書きます。

.hero（ブロック）
.hero__title（ヒーローの中のタイトル＝要素）
.hero--dark（ダーク背景バージョン＝修飾）

チームで作業するとき、後から別の人が修正するとき、3ヶ月後に自分が見返すとき——命名がしっかりしているかどうかで、作業のしやすさが大きく変わります。

AIへの指示がこう変わる

曖昧な指示：「ヒーローセクションのHTMLを作って」

良い指示：「ヒーローセクションをBEM命名規則でHTMLとCSSを作ってください。ブロック名は “hero” で統一してください」

命名規則を知っていれば、こう指示できます。AIはBEMを理解しているので、指示するだけで規則に沿ったコードを出してくれます。

視点4：DRY原則（同じことを繰り返さない）

DRYとは「Don’t Repeat Yourself」の略です。「同じことを繰り返すな」という意味で、プログラミングの世界で広く知られた原則です。

LPのCSSでよくある例を見てみましょう。サイト全体のメインカラーが「#1E90FF（青）」だとします。

繰り返しの例：
h1 { color: #1E90FF; }
.cta-button { background: #1E90FF; }
.highlight { border-color: #1E90FF; }

このように色を直接書いていると、「やっぱり緑にしよう」となったとき、全箇所を検索して書き換えが必要です。1ヶ所でも漏れると色がバラバラになります。

DRY原則に従うと、CSSカスタムプロパティ（変数）を使います。

:root { --color-primary: #1E90FF; }
h1 { color: var(--color-primary); }
.cta-button { background: var(--color-primary); }

こうすれば --color-primary の値を1箇所変えるだけで、サイト全体に反映されます。

AIへの指示がこう変わる

曖昧な指示：「LPのCSSを書いて」

良い指示：「LPのCSSを書いてください。色・フォントサイズ・余白はCSSカスタムプロパティで変数管理してください。同じ値を複数箇所に直書きしないようにしてください」

DRY原則を知っていると、「変数で管理して」という指示が自然に出てきます。AIはこの指示に従って、保守しやすいCSSを生成してくれます。

視点5：KISS原則（シンプルに保つ）

KISSとは「Keep It Simple, Stupid」の略です。「シンプルにしておけ」という意味で、過度な複雑さを避けることの重要性を説いています。

AIにコードを生成させると、時として必要以上に複雑なコードが返ってくることがあります。「ボタンをクリックしたらメニューを開く」という単純な機能に対して、クラスを継承した大がかりな構造を提案してくるケースなどです。

LPのような単発ページにそこまでの複雑さは必要ありません。シンプルなコードほど、読みやすく、バグが少なく、他の人が修正しやすくなります。

AIへの指示がこう変わる

良い指示：「ハンバーガーメニューのJSを書いてください。シンプルな実装で、クラスの付け外しだけで開閉できるようにしてください。フレームワークは使わないでください」

KISS原則を知っていると、「シンプルに」「フレームワークなし」という制約を指示に盛り込めます。AIは言われなければ、便利そうに見える複雑な実装を選ぶことがあります。

視点6：YAGNI（今必要ないものを作らない）

YAGNIとは「You Aren’t Gonna Need It」の略です。「どうせ必要にならない」という意味で、「将来使うかもしれない機能」を先回りして作ることへの警告です。

LP制作でありがちなのが、「将来アニメーションを追加するかもしれないからJSライブラリを入れておこう」「いつかA/Bテストをするかもしれないからバリエーション用のCSSも書いておこう」という判断です。

一見すると先を見越した設計に思えますが、実際にはコードが複雑になり、ページが重くなり、結局使わない可能性が高い——というリスクを抱えます。YAGNIの精神は「今必要なものだけを、しっかり作る」です。

AIへの指示がこう変わる

曖昧な指示：「将来のことも考えて汎用的に作って」

良い指示：「今回はキャンペーンLP1枚のみの実装です。将来の拡張は考えなくていいので、今必要な機能だけをシンプルに実装してください」

スコープを明確にして指示することで、AIは余計な複雑さを持ち込まずに実装してくれます。「将来も考えて」と言うと、YAGNIを無視した過剰なコードが返ってきやすくなります。

視点7：単一責任（1つのものは1つのことだけやる）

「単一責任の原則」とは、1つのパーツは1つの役割だけを持つべき、という考え方です。オブジェクト指向の設計原則として知られていますが、LP制作でも同じ発想が使えます。

たとえばCSSファイルの構成を考えてみましょう。すべてのスタイルを1つのstyle.cssに書いても動きますが、ページが大きくなると管理が大変になります。役割ごとに分けると、こうなります。

  • base.css → リセットや基本設定
  • layout.css → レイアウト・グリッド
  • components.css → ボタン・カードなどの部品
  • pages/lp.css → LP特有のスタイル

さらにHTMLのセクション設計にも応用できます。ヒーロー・特徴・料金・CTAといったセクションそれぞれを独立したブロックとして設計しておくと、後からセクションの追加・削除・並び替えがしやすくなります。

AIへの指示がこう変わる

良い指示：「LPのCSSはreset.css・layout.css・components.cssに分けて生成してください。それぞれのファイルに役割を明確に分離してください」

「ファイルを分けて」「役割を分離して」という指示は、単一責任の考え方を知っていないと出てきません。AIはこの指示に従って、整理されたファイル構成で出力してくれます。

設計の視点を持つと、AIとの会話が変わる

ここまで7つの視点を紹介しました。改めて整理します。

  • 単発 vs 複数展開 → 使い回しを想定した構成を指示できる
  • 関心の分離 → HTML/CSS/JSを分けた実装を依頼できる
  • 命名規則（BEM） → 読みやすいクラス名のルールを指定できる
  • DRY原則 → 変数管理・重複排除を依頼できる
  • KISS原則 → シンプルな実装を明確に求められる
  • YAGNI → スコープを明確にして過剰な実装を防げる
  • 単一責任 → ファイル・セクションの役割分離を指示できる

これらは「AIに何を指示するか」の解像度を上げるための視点です。知っているだけで、AIとのやり取りが具体的になり、返ってくるコードの質が上がります。

もうひとつ大事なことをお伝えします。AIが生成したコードは、必ずしも正しいとは限りません。動いているように見えて、保守性が低かったり、パフォーマンスに問題があったりすることがあります。

「このコードはDRYになっているか？」「KISS原則に反していないか？」——そう問い返せる目を持つことが、AIを使いこなすエンジニアと、ただ使うだけの人との違いになります。

この記事で紹介した原則が1冊にまとまっている本

今回紹介したDRY・KISS・YAGNI・単一責任といった原則は、『プリンシプル オブ プログラミング』という本に体系的にまとまっています。「3年目までに身につけたい」というサブタイトルの通り、駆け出しエンジニアのうちに読んでおくと、その後の開発の考え方がガラッと変わる一冊です。

AIへの指示力を上げるためにも、こうした原則を言語化して持っておくことがとても重要です。辞書的に使えるので、手元に置いておくだけで安心感が違います。


まとめ

AIは強力なツールです。でも、使う人の知識と視点によって、アウトプットの質はまったく変わります。

今回紹介した設計の視点は、LP制作に限った話ではありません。WordPressのテーマ開発でも、ECサイト構築でも、あらゆるWeb開発に通じる考え方です。LPという小さな単位で学んでおくことで、規模が大きくなっても応用が効きます。

焦る必要はありません。まずは次にAIへ指示を出すとき、今日紹介したどれか1つの視点を意識してみてください。それだけで、指示の質が変わるはずです。

次回は、WordPressテーマ開発編として、同じ設計視点がどう活かされるかを解説します。