AIへのコーディング依頼をよく使うが、最初のころはやり直しが多かった。「ちゃんと指示したつもり」なのに、返ってくるものが全然違う——そのギャップに何度も詰まった。この記事では、そのときハマった失敗3つと、そこから変えた指示の出し方を記録した。正解の手順ではなく、同じ状況での向き合い方のヒントになれば。
原稿を渡したら、原稿ごと書き換えられた
ワイヤーフレームと原稿テキストをセットで渡して、コーディングを依頼したことがある。
出力されたコードを確認したとき、レイアウトはほぼ意図通りだった。ただ、テキストだけが違った。想定読者に向けて書いた文章が、どこか一般的な言い回しに変わっていた。AIが「良かれと思って」、より広い読者に向けた形に整えていた。そのまま使えない。確認と修正で、想定外の時間がかかった。
自分の指示を見返すと、「この原稿とWFでページをコーディングして。ページのデザインは以下URLのサイトを参考にして」と書いただけだった。原稿が確定稿であると、どこにも書いていなかった。漠然とした指示のせいで、原稿も参考テキストの一つだとAIに誤認させてしまったのだと思う。
自分が思っている前提は、書かなければ伝わらない——そのことに気づいた。その後は、データを渡すときの書き方を変えた。
Before
このWFと原稿でコーディングしてください。
After
WFはXX.html、テキスト内容はXX.mdです。
XX.mdの内容を遵守すること。文言の書き換え禁止。
どういう意図で資料を渡しているのかを明確にして、「これはやってほしくない」ことも一緒に書くようにした。大きな認識ずれは、だいぶ減った。
長いページを一括指示したら、途中からレイアウトが崩れた
LPのワイヤーフレームを渡して、そのままコーディングを依頼した。参考になるデザインのURLも添えて、「こういうトーンで」と伝えた。
出力されたコードを確認したとき、一瞬で「デザインされていない」と分かった。WFをそのままHTMLにしただけで、デザインの判断は何もされていなかった。ページ中盤からは、WF上のメモ書き——「料金プラン」などのセクションラベル——がそのまま表示されていた。余白もセクションごとにバラバラで、デザインとして統一されたルールがなかった。
後々分かったことだが、WFをhtmlで渡していたことが原因の1つのようだった。htmlで渡したことで、構造を優先して解釈された可能性がある。こ誤算だった。
やり直しになったので、進め方を変えた。
Before
このWFでLPをコーディングしてください（参考URL添付）。
After
- WFのhtmlをもとに、Design.mdを作成する（完璧でなくてもよい。全体のトンマナを決めることが目的）
- Design.mdをもとに全体をコーディングし、セクション単位で調整を進める
これは実際のWeb制作とも共通する考え方だった。LPのように共通するセクションが多い長いページは、先に共通コンポーネントやページ全体のトンマナを決めてから作る方が、後からの修正・手戻りが少ない。AIとのやり取りも同じだった。
PCで進めたら、SP表示が崩れた
PCのWFを渡して、そのままコーディングを依頼した。出力されたコードをPCブラウザで確認すると、きれいにできていた。おお、このレベルが一発で。
ちょっと感動しながらスマホサイズを確認したら、スマホではレイアウトを切り替えてほしかったところがばっちり崩れていた。
「あ、そうか」と思った。SP対応について、一言も伝えていなかった。AIは「当然こうするだろう」を補完してくれない——頭で分かっていたつもりで、実際には分かっていなかった場面だった。
対処は、SP最適化の指示を別で出すことにした。ブロックが積み上がる箇所や表組など、レスポンシブ対応が必要な箇所を具体的に指定して、SP表示を別工程として依頼した。崩れは解消した。
ただ正直に言うと、最初の段階で「XXセクションはSP時のレイアウトも考慮して組むように」と書いておけば、やり取りが一往復減ったはずだ。後付けで対応した分だけ手間がかかった。
3つに共通していたのは、伝えていなかったことだった
振り返ると、3つとも同じ構造だった。AIが勝手にやったのではなく、自分が書かなかった。
原稿の書き換えは「書き換えないでほしい」と書かなかった。LPのレイアウト崩れはデザインルールを先に決めなかった。SP崩れはSP対応が必要だと書かなかった。どれも「書いていなかったこと」が形になって返ってきた。
試行錯誤するなかで、意外と効いたのが「禁止事項を書く」という発想だった。「こうしてほしい」という指示だけ書いていると、それ以外がどうなるかは曖昧なままになる。「これはやらないでほしい」を一行加えるだけで、意図しない動作がかなり減った。
最初は、AIだから起きる特有の問題だと思っていた。けれど振り返ると、制作案件でよく起きる認識ずれと構造は同じだった。要件定義や仕様の整理が曖昧なまま進めると、あとで「そういう意図じゃなかった」が出てくる。AIとのやり取りも、まったく同じだった。言語化しなければ伝わらない相手に何かを頼む——その構造は変わらない。
今もまだ試行錯誤している。このサイト自体、作って・測って・改善することを繰り返す場所なので、AIとの付き合い方もそのサイクルで更新していくつもりだ。
まとめ
- 自分が思っている前提は、書かなければ伝わらない
- 曖昧な前提ほど、先に言語化しておく必要がある
- 「やらないこと」を先に決めておくと、認識ずれが減る
AIを使うようになってから、制作の前提整理が重要だということを改めて実感している。プロンプトの書き方より先に、何を作りたいのかを自分の中で言語化できていないとうまく進まない。その感覚は、制作案件で仕様を詰めるときと変わらなかった。