AIを使ってコーディングを始めてみたものの、「なんとなく動くけれど、自分が思っていた形じゃない」と感じたことはないでしょうか。
私自身、普段からAIと一緒にWeb制作を進めていますが、うまくいくときと、やり直しを重ねてしまうときの差は、AIの性能よりも「任せる前の準備」にあるように感じています。
この記事では、AIに任せる前に人間側で決めておきたい3つのことを、実務の中で気づいた順に整理してみました。
この記事で分かること
- AIに丸投げしたときに起きやすい「ズレ」の正体
- AIに任せる前に、人間側で先に決めておきたい3つの軸（設計思想 / 受け入れ基準 / 保守の責任）
- 生成されたコードを「受け入れるかどうか」を判断する基準の持ち方
- AIと協業するときに、保守性の責任を誰が持つかという考え方
AIに「丸投げ」したときに起きること
AIにコーディングを任せると、指示の粒度が粗いほど「動くけれど、自分の思っていたものとは違うコード」が返ってくることがあります。私も、要件を細かく整理しないまま依頼をしてしまい、結果として修正の往復に時間を取られた経験が何度もあります。
このセクションでは、まずAI丸投げでよく起きる3つの現象を見ておきたいと思います。ここが、後半の「先に決めておくべき3つのこと」の出発点になります。
「動くけれど読めない」コードが生まれる
AIが返すコードは、単体で見ると動作します。ただ、「半年後の自分が読んで、その意図を思い出せるか」という視点で見直すと、かなり危ういコードになっていることが少なくありません。
変数名やクラス名が場当たり的だったり、同じ役割のスタイルが複数の書き方で混在していたり、コメントが付いていなかったり。動くから一見問題なさそうに見えても、後から修正が入ったときに「どこを触れば良いか分からない」状態になりがちです。
また、意図していないのにAI側が勝手に外部ライブラリをimportしてくるケースもあり、依存関係やセキュリティの観点でも油断できないと感じています。
同じ挙動を別の書き方で再現してしまう（設計の一貫性が崩れる）
AIは「毎回ゼロから」指示を解釈するような動きをするため、同じプロジェクトの中でも、別のタイミングで似たような実装を頼むと、命名・構造・実装方針が微妙に異なるコードが返ってくることがあります。
片方ではBEM風の命名、もう片方ではユーティリティクラス中心、といった具合に設計の一貫性が崩れていくと、コードベース全体の「読みやすさ」と「保守しやすさ」が少しずつ損なわれてしまうように感じています。
修正指示が増えるほど、AIに任せる前より時間がかかる
「なんとなく頼んで、出てきたものを見て、気になるところを都度直してもらう」というやり方は、一見スピーディに見えます。しかし実際には、「ここを直して」「じゃあこの影響で別の箇所が崩れたから直して」というやり取りが増えていき、最終的には自分で書いた方が早かったのでは、という気持ちになることもあります。
原因を振り返ると、「最初の段階で自分の頭の中にあった設計を、AIに渡していなかったから」という一点に行き着くことが多いです。ここから、「任せる前に決めておきたい3つのこと」の話に入っていきます。
任せる前に決めること1 — 「設計思想」を先に言語化する
3つの中で最初に置きたいのが「設計思想」です。コードの品質や一貫性の土台になる部分で、ここが言語化されていないと、後の受け入れ基準や保守の話がすべてブレてしまうように感じています。
なぜAIは「設計思想」を勝手に決めてくれないのか
AIは「一般的にはこう書くことが多い」という平均的な答えを返してくれる存在です。ただ、Web制作の現場では「このプロジェクトではこの設計でいく」という個別の方針があり、そこはAIが察してくれる領域ではないと感じています。
たとえば「FLOCSSで組む前提のプロジェクト」と「ユーティリティクラス中心のプロジェクト」では、同じUIでも最適なコードが変わります。AIに判断を委ねると、その時々で平均的な答えが返ってくるため、結果的に設計がバラバラになっていきます。
だからこそ、設計思想は人間側で先に決めて、言語化しておく必要があると考えています。
最低限伝えておきたい4項目
私が案件やブログのコーディングを始める前に、AIに渡しておきたいと感じている項目は次の4つです。
- CSS設計手法 — 例: FLOCSSを採用するのか、独自構成か
- 命名規則 — 例: BEM風か、ユーティリティ主体か
- レスポンシブ方針 — 例: モバイルファースト / 基準ブレークポイント（768pxなど）
- 実装スタック・既存資産 — 例: 素のCSSかSassか、既存テーマのクラス命名との衝突回避、既存のFLOCSSファイル構成にどう組み込むか、
_variables.scss/_mixins.scss等を読み込み済みとする前提など
特に4つ目の「実装スタック・既存資産」は見落としがちですが、ここを伝えておかないと、AIが勝手に新しい変数を切ったり、既存のmixinを使わずに同じ処理を書き直してしまうことがあります。既存の構成と合わないコードが混ざり込むのを防ぐ意味でも、最初に宣言しておきたい項目です。
コード例として、プロンプトに添えるメモは次のような形をイメージしています。
# 設計前提（AIに渡すメモ）
- CSS設計: FLOCSS（project / component / utility を分離）
- 命名: BEM風（block__element--modifier）
- ブレークポイント: 768px基準（min-width方式）
- Sass: 使う（ネスト3階層まで）
- 既存資産: _variables.scss / _mixins.scss を読み込み済み前提この5〜6行を用意しておくだけで、返ってくるコードの安定感がかなり変わるように感じています。
関連する設計手法については、こちらの記事もあわせて読んでいただけると前提が整いやすいと思います。
「伝える順番」も質を左右する（全体→個別）
もう一つ意識したいのが、伝える順番です。設計思想を渡すときは、先に「このプロジェクトはどういう方針か」という全体像を伝えてから、「このセクションをお願いします」という個別の依頼に入るようにしています。
個別依頼だけを投げると、AIは毎回「一般的な実装」で返してきますが、先に全体像を共有しておくと、「その方針のもとでは、このセクションはこう書くのが自然」という流れで応答してくれる印象があります。
任せる前に決めること2 — 「受け入れ基準（DoD）」を先に書く
2つ目は「受け入れ基準（DoD: Definition of Done）」です。ここは、生成されたコードを「採用するかどうか」を判断するための軸になります。
「AIが出したから正しい」ではなく「自分が受け入れられるか」
AIは自信を持って答えを返してきますが、それが今のプロジェクトにとって「正解」であるとは限りません。最終的に納品するのは人間であり、動作・保守・拡張の責任もこちらに残ります。
だからこそ、「AIが出したから正しい」ではなく、「自分の基準に照らして受け入れられるかどうか」を判断する姿勢が大事になってくると感じています。この判断軸を先に言語化しておくと、生成後のレビューがぐっと早くなります。
受け入れ基準に入れておきたい観点
私が意識している観点は、大きく4つです。
- 見た目の再現性 — デザインカンプとの差分がないか（主要なブレークポイントで確認）
- アクセシビリティ — キーボード操作が成立するか、focusの可視化があるか、altやラベルは適切か
- 保守性 — 半年後の自分が読んで、追加改修できる命名・分割になっているか
- ブラウザ対応 — 対応ブラウザで表示崩れが出ないか（iOS Safariを含めて確認）
これらをまとめて「このセクションのDoDチェックリスト」としてメモしておくと、AIに投げるときにも、レビューするときにも、同じ基準で話ができるようになります。
受け入れ基準は「プロンプトにも書く」
受け入れ基準はレビュー時の判断軸であると同時に、AIに対する「品質の指示」でもあります。プロンプトに含めておくと、生成の段階で基準を満たす方向にコードを寄せてくれる感覚があります。
テキストブロックとしては、次のようなイメージです。
# 受け入れ基準（このセクションのDoD）
- デザインカンプとの差分が目視で分からない（主要3ブレークポイント）
- キーボードのみで全操作が可能（focus可視化あり）
- 半年後の自分が読んで追加改修できる命名・分割になっている
- 主要ブラウザ最新版 ＋ iOS Safari最新版で表示崩れなしこのメモを設計前提メモと一緒に渡しておくと、AIが出してくるコードの粒度が揃いやすくなると感じています。
任せる前に決めること3 — 「保守の責任」が誰にあるかを決めておく
3つ目は「保守の責任」です。少し話が大きくなりますが、ここを意識しているかどうかで、採用する実装が変わってくると感じています。
AIは保守してくれない — 直すのは自分かクライアント
当たり前の話ではありますが、AIは納品後のコードを保守してくれません。半年後に「このサイトのここを直したい」と連絡が来るのは自分のところであり、クライアント側で別の制作者が触ることもあります。
この事実を踏まえると、「今この瞬間に動くコード」よりも、「半年後・1年後に誰かが読んで直せるコード」を選んだ方が、長期的には負担が少なく済むように感じています。
「半年後に自分が読めるか」を基準に採用するか決める
AIが出してくるコードの中には、「動くけれど難解」なものも混ざっています。短く書くことに寄せた結果として読みにくくなっているケース、流行りの書き方で手数だけ減らしているケースなど、いろいろなパターンがあります。
私は、AIの提案を採用するかどうかを判断するとき、「半年後の自分がこのコードを読んで、落ち着いて修正できるか」を基準に置くようにしています。読めそうになければ、たとえコード量が増えても、より明快な書き方を依頼し直します。
クライアント案件なら「修正しやすい設計」を優先する（速度より保守性）
クライアント案件では、納品後に自分以外の人がコードを触ることも珍しくありません。その場合、トリッキーな最短ルートよりも、「他のコーダーが見てもすぐ構造を掴める設計」を優先したいと考えています。
速度を出したい気持ちも分かりますが、後から修正が入ったときに現場で止まってしまうコードは、結果的にクライアントの時間を奪います。保守しやすい設計を残すことは、関わってくれた方への誠実さでもあると感じています。
3つを決めたあと、AIとの対話はどう変わるか
ここまでの3つ（設計思想 / 受け入れ基準 / 保守の責任）を先に決めておくと、AIとのやり取りそのものが軽くなります。具体的な変化を、短くまとめてみます。
プロンプトは短くて済むようになる
設計前提メモとDoDメモを一度用意してしまえば、セクションごとのプロンプトは「このセクションをお願いします」くらいの短さで済むようになります。毎回同じ前提を書き直さなくてよい分、思考のリソースを実装判断に回せるのが大きいと感じています。
生成後のレビューが速くなる
受け入れ基準を先に書いてあるので、レビューは「基準に照らして合致しているか」を確認する作業に変わります。「なんとなく気になる」という曖昧なチェックが減り、判断がスピーディになります。
「やり直し」の回数そのものが減っていく
前提と基準が揃っていると、最初から方向性の合ったコードが返ってくることが増えます。結果として、やり直しの往復回数自体が減り、最終的な作業時間も短くなる感覚があります。
参考として、プロンプトのビフォーアフターを1組だけ載せておきます。
# ビフォー（前提なし）
ハンバーガーメニューのCSSを書いてください。
# アフター（前提あり）
先に共有した「設計前提メモ」と「受け入れ基準」を踏まえて、
ヘッダーのハンバーガーメニューのCSSをお願いします。
該当パーツは Project レイヤー想定で、BEM風の命名でお願いします。同じ依頼でも、アフターの方が返ってくるコードの安定感が段違いに感じられるはずです。
よくある質問（FAQ）
- AIに任せる前の準備は、毎回するのですか？
プロジェクトの最初に一度しっかり決めて、ファイルやメモに残しておくと再利用しやすいです。案件ごとに「設計思想メモ」として用意しておくと、2回目以降は貼り付けるだけで済みます。
- 3つの中で、どれから始めれば良いでしょうか？
個人的には「設計思想」から取り組むのが分かりやすいと感じています。ここが決まっていないと、受け入れ基準も保守の基準もぶれやすいからです。
- 小さな修正や1行のコードでも、事前に決める必要はありますか？
ケースバイケースです。単発の小さな作業では過剰になる場合もあります。ただ、新しいファイルや新しいセクションを作るタイミングでは、事前に一度決めておくと後から楽になりやすいです。
- 事前に決めた内容を、途中で変えても良いですか？
問題ありません。むしろ、作業の中で気づきがあれば更新していく方が実態に合います。大事なのは「決めた内容をAIとの対話にも反映する」ことです。
まとめ
この記事では、AIにコーディングを任せる前に、人間側で決めておきたい3つのことを整理してみました。
- AIは手段であって、設計思想を持ってくれる存在ではない
- 「設計思想 / 受け入れ基準 / 保守の責任」の3つを先に決めるだけで、AIとの協業の質が変わる
- プロンプトを工夫する前に、人間側の準備に目を向けたい
AIの進化は速く、ツール選びやプロンプトの工夫にどうしても目が行きがちです。ただ、実際に手を動かしてみると、「AIは手段、人間の設計が土台」というシンプルな構図は変わらないように感じています。
カテゴリー「AI × Web制作」では、今後もAIを使いこなすための具体的な工夫や、実務で見えてきた気づきを記事にしていく予定です。この記事がその入り口として、同じように試行錯誤している方の参考になれば嬉しいです。
関連記事として、設計思想の土台づくりに役立つものを置いておきます。
