先日、第8回東京山梨AIミートアップで短い時間ながら登壇の機会をいただいた。テーマは「ClaudeとGoogle StitchでつくるLP手順」。時間は短かったけれど、資料をまとめる過程でClaudeやStitchへの自分の理解が整理され、特にskillという考え方を取り入れてからAIとの情報共有の密度が格段に変わったという実感を得られた。このブログでは、当日話しきれなかった部分も含めて、その全貌を改めて言語化してみたい。
イベントページ：第8回東京山梨AIミートアップ
第1章：課題の深掘り——「こんなLP作って」では微妙なものしか出てこない
AIを使ったウェブ制作、とりわけLP（ランディングページ）の制作に取り組んでいる人なら、一度は感じたことがあるはずだ。「こんなイメージのLPを作って」とAIに頼んでも、返ってくるものはなんとなく整ってはいるが、どこか自分の意図とズレているという感覚。
なぜそうなるのか。ひと言で言えば、「AIへの伝え方が毎回ゼロリセットされているから」だと思っている。
私はウェブ制作を生業にしているが、クライアントごとにデザインの方向性も、訴求軸も、使いたい言葉のトーンも異なる。それをプロンプトで毎回一から説明し直すのは、時間的にも精神的にも消耗する。しかも、1回のプロンプトで全てを伝えようとすれば自然と長文になり、AIが要点を正しく拾い上げてくれるかどうかは運頼みになってしまう。
さらに深刻なのは再現性の問題だ。一度うまくいったLPがあったとして、「あのときのプロンプト」を再現しようとしても、記憶は曖昧で、テキストで残しておいても文脈が抜け落ちていることが多い。同じクライアントの追加ページを作ろうとしたとき、一から作り直しに近い状態になることもある。
そして改善のしやすさも大きなネックだ。「フォントをもう少し読みやすく」「キャッチコピーのトーンをやわらかく」——こうした修正を加えるとき、どこを直せば全体の一貫性が保てるのか、プロンプトベースの管理では把握しにくい。結果として、ちょっとした変更が全体の見た目を崩すことになりがちだった。
要約すると、当時の私が抱えていた課題はこの2点に集約される。
- 再現性：同じ品質のLPを、別のタイミングでも確実に作り直せるか
- 改善のしやすさ：修正・更新を、全体の一貫性を保ちながら積み上げられるか
プロンプトをその都度書いている限り、この2つは解決しない。何かしら「構造」が必要だった。
第2章：skill.mdの発想——「AIへの伝え方」をファイルで管理する転換
転機は、Xでとあるスライドを見つけたことだった。
参考：Claude Codeでマーケターの課題を解決する（Speaker Deck）
このスライドで紹介されていた考え方が、「skill.md」だ。
一言で言えば、「AIに何をどう伝えるかを、プロンプトの中ではなくファイルとして外出しして管理する」という発想の転換だ。
従来のやり方では、AIへの指示はプロンプトの中に埋め込まれていた。つまり、指示とリクエストが一体化していた。毎回のやりとりのたびにコンテキストが消え、次のセッションでは一から説明し直す必要があった。
skill.mdの考え方は、それを切り離す。「自分はどういう仕事をしていて、どんなこだわりを持っていて、どんな品質基準で成果物を出したいのか」——そういった恒久的な情報をファイルに書いておき、AIにそれを読み込ませる。AIとのセッションが変わっても、ファイルさえあれば文脈が引き継がれる。
これを見た瞬間、「これだ」と思った。LP制作に当てはめれば、「自分（あるいはクライアント）のこだわりをファイルで定義する」ことができる。プロンプトを書くのではなく、ファイルを育てる。その発想の転換が、私のLP制作ワークフローを大きく変えることになった。
第3章：3つのMDファイルの設計——役割を分けることで「育てる」仕組みへ
skill.mdの考え方を導入するにあたって、LP制作という文脈では1つのファイルでは足りないと感じた。「何を伝えるか」「どう見せるか」「どう構成するか」は、それぞれ独立した関心事であり、混在させると管理が複雑になる。そこで3つのファイルに役割を分けることにした。
1. design-system.md——色・フォント・トーンの定義（theme.jsonの代わり）
このファイルには、そのLPのビジュアル的な「憲法」を書く。使う色のカラーコード、フォントの種類とウェイト、余白の基準、ボタンのスタイル、全体のトーン（明るく活発か、落ち着いた信頼感か、など）。
エンジニアやデザイナーならtheme.jsonに相当するものだと思ってもらうとわかりやすい。ただし、ここでは厳密なコードより「意図」を優先して書く。「瀬戸内の空と海を感じるブルー系で、地域への愛着と信頼感を表現したい」といった記述が入る場合もある。AIはそこから適切な色を提案したり、一貫したトーンを保ったりする判断材料にしてくれる。
このファイルがあることで、「全体のトーンはこれ」という基準点が生まれ、Claudeへの指示のたびにゼロから説明する必要がなくなる。
2. lp-structure.md——セクション構成と順序の定義（ワイヤーフレームの代わり）
このファイルには、LPのページ全体の構成を書く。「ファーストビュー → コンセプト説明 → サービス一覧 → お客様の声 → 料金 → CTA」というような流れと、各セクションで何を伝えるべきかの意図をセットで記述する。
ウェブ制作でいうワイヤーフレームに近い役割を担うが、コンポーネントの配置図ではなく「なぜこの順番で伝えるのか」という情報設計の意図を言語化している点が特徴だ。「読者が最初に感じる不安をここで解消する」「ここで信頼性を高める」といった戦略的な意図をAIと共有することで、単なるレイアウト指示以上の精度で生成してもらいやすくなる。
3. content-source.md——文言・実績・訴求軸の定義（構成案の代わり）
このファイルには、実際にLPに載せる素材をまとめておく。クライアントの実績（「移住サポート実績〇件」など）、使いたいキャッチコピーの案、強調したい訴求軸（「他にはない〇〇」「△△が他社と違うポイント」）、お客様の声の文章、FAQなど。
AIへの「材料渡し」をするファイルだ。このファイルがあることで、「材料はここに全部ある。それを使ってLPを組み立てて」という指示が一行でできるようになる。逆に言えば、このファイルの充実度がそのままLP品質に直結する。
3ファイルの連携
この3ファイルが揃うと、Claudeへのプロンプトはシンプルになる。
「design-system.md・lp-structure.md・content-source.md を読んで、それに沿ったLPのHTMLを生成して」
それだけだ。Claudeはファイルを読み込み、ビジュアル・構成・内容を統合したコードを出力する。その後、Google Stitchでビジュアルを確認・微調整するというフローになる。「誰でも・何度でも再現できる」という感覚は、この3ファイルが揃って初めて得られたものだった。
（実際には、google-stitch-skillsを使い、表現力を強化していますが割愛します。）
第4章：実践での改善——碧設計事務所のLP制作を通じて
このワークフローを実際に試したのが、香川を拠点とする設計事務所のLPだ。瀬戸内での移住・住まい・ライフスタイルをトータルで支援するサービスを展開している。
従来のやり方では、プロンプトに「瀬戸内の空と海をイメージした青系のデザインで、移住支援サービスのLPを作って。コンセプトは…（長文）」と書き、毎回微妙にズレたアウトプットを修正するループを繰り返していた。「もう少し落ち着いた青に」「このボタンのテキストをこう変えて」という細かい修正の積み重ねで、完成までに多くの往復を要した。
3ファイル導入後では、design-system.mdに「瀬戸内の空と海を想起させる #2563EB 系のブルー、白を基調とした清潔感、フォントはクリーンで視認性の高いサンセリフ」と一度書いておくことで、その後の生成・修正のたびにトーンが安定した。構成についても lp-structure.md で「ファーストビューにキャッチコピーと海の風景写真、すぐ下に無料相談へのCTA」と定義済みなので、「ファーストビューのCTAの位置を変えて」という指示が一行で伝わるようになった。
修正の往復回数が減っただけでなく、「あの設定なんだったっけ」という記憶の引き出しに使うコストがほぼゼロになったのも大きな改善点だった。ファイルを見れば設計の意図が全部入っているので、数週間後に追加ページを作る際にもスムーズに再開できる。
まだ完全に最適化できているわけではないが、「再現性と改善のしやすさ」という当初の課題に対して、明確な手応えを感じている。
第5章：今後の課題と展望——3ファイルをどう「育てて」いくか
ワークフローの骨格はできた。次の課題は、この3つのMDファイルをどう継続的に育てていくかだ。
現状では、LPを1つ作るたびに3ファイルを一から書き起こしている。これはこれで効果があるが、複数のクライアントを抱えると管理が煩雑になる。「共通のベーステンプレート + クライアント固有の差分」という形で構造化できないか、模索中だ。
また、バージョン管理の問題もある。design-system.mdを更新したとき、過去に生成したLPとの整合性をどう保つか。Gitで管理する方法も考えているが、非エンジニアのクライアントと共有するには敷居が高い。もう少し簡易な「変更履歴」の仕組みが必要かもしれない。
さらに言えば、Google Stitch側のフィードバックをファイルにどう反映するかもまだ確立できていない。StitchでビジュアルをいじってAIが生成したコードに手を入れると、そのノウハウがどこにも残らない。修正の経緯をcontent-source.mdにメモとして残すことは始めているが、体系化にはまだ至っていない。
この「3ファイルを育てる仕組み」ができれば、AIと自分の間の情報共有はさらに密度を増すはずだ。続きはXやFacebookで随時発信していく予定なので、興味のある方はぜひつながってほしい。
クロージング
今回、登壇資料をまとめるという作業が、単なる「発表の準備」以上のものになった。自分がClaudeやStitchをどう使っているかを言語化することで、何となくうまくいっていた部分の理由と、まだうまくいっていない部分の輪郭がはっきりした。
skillという概念でAIへの伝え方を構造化すること——これは「プロンプトを書く技術」の話ではなく、「AIと継続的にどう関係を築くか」という問いへの答えの一つだと思っている。
迷いながらも、少しずつ再現できるようになってきた実感がある。引き続き試行錯誤を続けていくので、同じような課題を感じている方はぜひ一緒に考えたい。
