先日、WordPressミートアップ西新宿にお声がけいただき、10分間のライトニングトークで登壇する機会をいただきました。テーマは「AIに任せる前に、聞くことがある」。AIを使ったサイト制作の話ですが、ツールの紹介ではなく、私が試行錯誤しながらたどり着いた「制作の進め方」についての話です。
正直に言うと、まだ完成した方法論ではありません。今も手直ししながら使っている、途中経過の話です。にもかかわらず、当日は予想していた以上の反応をいただき、終わったあとにも複数の方から質問をいただきました。ウェビナーや勉強会でノウハウを共有する機会をいただくたびに感じることですが、こうして人前で話す（＝言語化を強制される）ことで、自分の考えがまとまっていくのを実感します。今回もまさにそうでした。
せっかくなので、当日お話しした内容を、ブログの形でも残しておこうと思います。
「売りたいんじゃないんだ、広めたいんだ」
本題に入る前に、ひとつエピソードを共有させてください。以前、ある新素材を扱うコンサルタントの方とお打ち合わせをしていたときのことです。その方が、ふと、こうおっしゃいました。「売りたいんじゃないんだ。この素材を、もっともっと広めたいんだ」。この一言で、私がその方のために作ろうとしていたサイトの設計は、根本から変わりました。──ただ、この言葉、私がその前にお渡ししていた質問票には、一文字も書かれていませんでした。なぜ書かれなかったのか。どこから出てきたのか。それは、この記事の最後でお話しします。
AIで速くなったのに、なぜ手戻りは減らないのか
本題です。AIが登場して、サイトは確かに速く作れるようになりました。ここまで読んでくださっている方の多くも、実感されているのではないでしょうか。
でも、聞きたいことがあります。手戻りは、減りましたか。「思っていたのと違う」「やっぱりこの順番じゃない」。そうしたやり直し、減りましたか。少なくとも私は、最初あまり減りませんでした。速く作れるようになった分、速く作り直していただけでした。
結論から言うと、私は、サイト制作で決めるべきことを、全部4枚のMarkdownファイルに分けて整理することにしました。今日はその話をします。
決めるべきことを、4枚のMarkdownに分ける
全体の流れは、こうです。
- preparation.md（素材）に、インタビューの文字起こしと資料を集める
- そこから structure.md（骨格）・design.md（見た目）・text.md（言葉）の3枚を作る
- Figmaで色のついていないワイヤーフレームを作り、構成の順番だけを確認する
- design.mdを当てて、デザインカンプ（見た目込みの完成イメージ）にする
- ブロックエディター対応のコードを出力する
- WordPressに流し込む
この流れは、この後も何度か出てきますが、覚える必要はありません。大事なのは、この4枚それぞれの役割です。
preparation.md──素材
インタビューの文字起こしに、あとから調べたことや、追加でいただいた資料を足していく1枚です。ここが、すべての土台になります。
structure.md──骨格
ページの構成、見出しの順番、何を先に見せて何を後に回すか。骨組みだけを扱います。
design.md──見た目
色、フォント、余白。見た目に関することは、すべてこの1枚にまとめます。
text.md──言葉
実際にサイトに載る文章です。
大事なのは、役割を混ぜないことです。色コードはdesign.mdにしか書かない。文章はtext.mdにしか書かない。混ぜた瞬間に、修正のたびに全部を探し回ることになります。
実践フロー──色を消して順番を決め、器を先に渡す
ワイヤーフレームは、あえて無色で見せる
最初のポイントです。ワイヤーフレームは、Figmaでわざと無色（グレースケール）にして確認します。理由は単純で、色を付けた瞬間、打ち合わせの話題が「この青、もう少し濃く」になってしまうからです。この段階で決めたいのは、何を先に見せて、何を後に回すかという順番だけ。色を消すと、順番の話しかできなくなります。これは、お客様のためでもあり、私自身のためでもあります。
色と余白は、design.mdを当てて一気に
順番が固まったら、design.mdを当てます。すると、色・フォント・余白が一気に乗って、デザインカンプになります。「順番の議論」と「見た目の議論」を、時間的に分けること。これだけで、打ち合わせが驚くほど短くなりました。
コードはブロックマークアップで出す
カンプができたら、そこからコードを出力します。ここで大事なのは、ブロックマークアップという形式で出すことです。HTMLをそのまま書いてしまうと、納品した瞬間からお客様は何も触れなくなってしまいます。ブロックで出しておけば、文言の差し替えくらいはご自身でできる。「作って終わり」にしないための、地味ですが大事な一手です。
theme.jsonとブロックパターンを先に用意しておく
ここが、今回のライトニングトークでいちばんお伝えしたかった技術的なポイントです。design.mdは、theme.jsonに変換して、先にWordPressへ読み込ませておきます。色や余白が、トークン（あらかじめ決めた値の呼び名）として定義された状態です。同時に、ブロックパターン（よく使う組み合わせをあらかじめ用意しておく仕組み）も先に作っておきます。そうすると、AIが実装するときに、ゼロからHTMLを組み立てるのではなく、あらかじめ用意された器に流し込む動きになります。出力が毎回ブレる、という問題は、ここで解消できました。色コードを二度と手で書かなくて済む、という副次的な効果もありました。
器さえできてしまえば、2ページ目からはstructure.mdとtext.mdを渡すだけです。用意したパターンを並べるだけなので、下層ページはあっという間に立ち上がります。「AIで速くなった」の正体は、実はここにあります。1ページ目に手間をかけたぶん、2ページ目以降が速いのです。
成否の9割は、いちばん上の一枚で決まる
……という流れなのですが、正直にお伝えします。この工程、成否の9割は、いちばん上のpreparation.mdで決まります。素材さえ良ければ、下はほぼ自動で流れます。逆に、素材が悪いと、下で何をやっても直りません。
以前の私は、質問票をお渡ししていました。A4で数枚の、よくあるものです。返ってきた質問票は、たいてい空欄だらけでした。埋まっていても、「幅広い層」「信頼感」といった、当たり障りのない一行です。長いこと、「クライアントの熱量が足りないんだ」と思っていました。違いました。本業でお忙しい方に、慣れない「書く」という作業を押し付けていただけだったのです。しかも、書式そのものが答えを縛っていました。「訴求したいことは？」という設問には、「売りたいわけじゃない」という答えを書く欄が、そもそもありません。
今は、書いてもらうのをやめました。インタビューを、まるごと録音します。1時間でも2時間でも。それを文字起こしして、そのままpreparation.mdにします。整えません。脱線も、言い直しも、そのまま入れます。あとから調べたことや、追加でいただいた資料は、この1枚に足していきます。お客様にお願いすることは、話していただくことだけです。それなら、皆さん本当によく話してくださいます。そして、この「整えない」ということが、次の話につながります。
冒頭の一言に戻ります
冒頭のエピソードに戻ります。「売りたいんじゃないんだ。この素材を、もっともっと広めたいんだ」。もし質問票にお答えいただく形式だったら、この方はきっと「新素材の導入支援実績と専門性」と書かれていたと思います。嘘ではありません。でも、その方が本当に持っていたものは、そこにはありませんでした。
この一言が出てきたことで、サイトの設計は変わりました。text.mdだけではありません。structure.mdも書き換わりました。売る前提であれば、「サービス紹介→実績→問い合わせ」という順番になります。でも、「広めたい」が軸なら、素材そのものの解説を先に置くのが正しい。design.mdのトーンも、手堅い信頼感から、もう少し熱のあるほうへ寄せました。一言が、3枚とも書き換えたのです。
もうひとつ。「もっともっと」という繰り返し。これも、質問票であれば「普及」の二文字で終わっていたと思います。繰り返しや言い淀みにこそ、熱量が宿ります。だから、文字起こしは整えないのです。
まだ未完成なプロセスとして
まとめます。4枚のMarkdownが設計図です。AIは実装係で、器を先に渡しておけば、出力がブレません。そして、その設計図の材料は、書いてもらうのではなく、話してもらう。AIに任せる前に、聞くことがある。
冒頭でも触れたとおり、これはまだ完成した方法論ではありません。ミートアップでいただいた質問の中にも、私自身まだ答えを持てていないものがいくつかありました。preparation.mdの「整えない」という原則と、後工程での使いやすさをどう両立させるか。構造化データやアクセシビリティを、この4枚のどこに位置づけるか。まだ実践しながら考えている途中です。
登壇という場は、こうして自分の途中経過を人に晒し、フィードバックをもらえる貴重な機会だと、あらためて感じました。この4枚の設計図も、今後さらに実践の中で磨いていくつもりです。ここまで読んでくださり、ありがとうございました。