第1回・第2回で土台（オントロジー）を作った。第3回は、いよいよ「実際に作る」回です。
各自が自分のランディングページを、公開するところまで持っていきます。
蓄積したオントロジーとMarkdownのデータベースを使って、実際の制作物を作る。今回のゴールは明快で、参加者全員が自分のWebページをネット上に公開することでした。手を動かすほど、どこで品質が決まるのかが見えてきた回です。流れに沿って記録します。
制作の心臓は「企画書MD」
いきなりHTMLを書き始めるのではありません。まず企画書をMarkdownで書く。そこから制作が回り始めます。サイクルはこうです。
① 企画書MDを書く ↓ ② 内容をレビュー・修正する ↓ ③ 制作物（Webページ）を生成する ↓ ④ 修正した内容を、企画書に戻す （企画書が「未来の仕様書」として育つ）
ポイントは④です。Webページを直したら、その指示を企画書にフィードバックして蓄積する。こうしておくと、次に似たものを作るとき、AIへの指示の手間とミスマッチが減ります。企画書そのものが、AIと人間のコミュニケーションコストを下げる資産になる——これが今回の背骨でした。
「バイブコーディング」で公開まで
今回の作り方は「バイブコーディング」。人間は最低限の指示を出し、AIが実行と出力を担います。そのままGitHubやNetlifyを使って、公開まで持っていく。コードを書けなくても、企画書さえしっかりしていればWebページがネットに出る——その体験を全員で共有しました。
注意：Netlifyの無料枠
公開ツールのNetlifyには月300トークンの無料枠があります。デプロイやページ確認のたびに消費されるので、無料枠で回すなら修正回数に気をつける。「とりあえず何度もデプロイ」は枠を食う、という実地の注意が共有されました。
要件定義が、アウトプットの質を決める
参加者はそれぞれ別のプロジェクトを立てました。飲食店の紹介ページ、地域プロモーション、講座のLP——題材はバラバラです。共通して効いたのは「要件定義」でした。営業時間、場所といった必須項目を最初に明確にしておく。ここを曖昧にすると、AIのアウトプットも曖昧になります。質の高い出力は、質の高い要件定義から。当たり前のようで、いちばん差が出るところでした。
モデルとフォルダを使い分ける
道具の割り当ても共有されました。企画づくりには上位モデル（Claude Opusなど）、Web実装にはGemini。画像は「IMG」フォルダにまとめ、AIが参照すべき作業フォルダを明確にする。フォルダがぐちゃぐちゃだとAIが迷走するので、場所を決めてやることが精度に直結するという話でした。
企画書をいじると、全体がきれいに直る
出来上がった企画書MDを各自レビューし、イメージと違う箇所をAIに直させます。面白かったのは、タイトルやコンセプトといった「上流」を変えると、AIが全体を整合性を保ったまま再構築してくれること。部分を手で直すより、設計の根を変えるほうがきれいに揃う、という実演でした。
レイアウト（シンプルなテキストセクション、背景色）や、ドキュメンタリー風の映像ディレクションといったデザイン要件も、企画段階で具体的に指示します。過去の対話ログがオントロジーとして効いていて、こうした好みが自然に反映される。逆に、AIが古い情報や事実誤認を出してきたら、その場で直す。その修正がそのままオントロジーの更新になり、次の精度を上げます。
実装：企画書に「ない物を足すな」
企画書が固まったら、Webページの生成に移ります。ここでの肝は一つ。AIに、企画書にない要素を勝手に足させない。企画書の内容に忠実なHTMLを作らせることで、意図どおりの成果物になります。
技術選定では、更新のしやすさを考えてデータベース型ではなくHTMLで実装。そして、AIの検索に最適化するSEO設計を最初から企画に盛り込むのが推奨されました。生成後はスマートフォン表示まで確認し、崩れを直していきます。
画像はAIに「見えない」前提で
つまずきやすいのが画像です。AIはファイルや画像を直接見られません。だから、画像生成の指示は企画書の中に明確に書き込み、フォルダ構造を指定しておく。「見えない相手に、言葉で渡す」——この前提を押さえているかどうかで、結果が変わりました。
参加者のつまずきと、その場の解決
当日いちばん「現場」だったのは、やはりトラブル対応の時間です。
「ファイルが混ざりました」
複数のプロジェクトを同じフォルダで管理してしまい、ファイルが混ざるトラブルが起きました。修正と再デプロイでリカバリし、教訓は明確。プロジェクトごとにフォルダを分ける。混同を防ぐのは、凝った仕組みではなく、最初のフォルダ分けでした。
そして、公開
作ったHTMLをNetlifyにフォルダごとアップロードして公開します。プロジェクト名はユニークである必要があるので、デモ用は適当な名前、本番用は慎重に決める。公開できたら、URLをグループチャットで共有——各自が自分のページを「世に出した」瞬間でした。
ジョークデータは「AIをバカにする」
議論が白熱したのが、データの品質です。オントロジーに「ライス80万円」のようなジョークを入れていた参加者がいて、講師ははっきり止めました。ジョークはAIが不適切な知識として学習し、性能を落とす（＝バカになる）原因になる。
この勉強会は、ただの練習ではなく実際の事業開発を兼ねている。だから最初から、本番を見据えたリアルなデータで作る。
個人情報を省いたり、質の低いデータを使ったりすると、AIは「サボる」挙動を学習してしまう。ビジネスに使うなら、徹底してリアルなデータで構築する——アドバイザーがいる今のうちに、と念を押されました。
別のAIに「採点」させる
仕上げの工夫も共有されました。完成したHTMLやURLを別のAIエージェントに見せて客観的に評価させ、それを元のAIに反映する。自分とAIの二人三脚に、第三者の目を一つ足す。品質を一段引き上げる手でした。
今日のチェックリスト
第3回で各自が進めるべき作業を、手順として残します。
| ステップ | やること |
|---|---|
| ① 企画書を書く | 作りたいものをMarkdownの企画書に。必須項目（営業時間・場所など）を要件定義として明記 |
| ② レビューする | 企画書を読み返し、タイトル・コンセプトなど上流を直してAIに再構築させる |
| ③ 生成する | 企画書に忠実にHTML生成（企画書にない要素は足させない）。画像指示・フォルダ構造も明記 |
| ④ 確認する | PC・スマホ表示を確認し、崩れや事実誤認を修正 |
| ⑤ 企画書に戻す | 修正指示を企画書に追記して蓄積（次回の仕様書に育てる） |
| ⑥ 公開する | Netlifyにフォルダごとアップ。本番のプロジェクト名は慎重に。URLを共有 |
| ⑦ 採点させる | 完成物を別のAIに評価させ、フィードバックを反映 |
企画書がすべての中心。作って終わりではなく、直した分だけ企画書に戻す。その積み重ねが、次の制作を速くする——第3回はそれを手で確かめた回でした。
この回の内容を、教科書で体系的に
この回で扱った内容は、SOVREN Framework（無料・オープンソース）の教科書 S1「自分の情報体系を構築する」 に、手順として体系的にまとまっています。特別な技術知識は不要です。