概要
従来のホームページ制作では、まずサイトマップ、ページ一覧、原稿管理表、CMS設計、カテゴリ設計などを整え、それをもとにWebページを作っていく流れが一般的でした。先に情報を整理し、構造を決めてからWebサイトへ反映する。この順番は今でも有効です。
ただ、生成AIとCodexを使うと、この順番が一部で変わり始めます。Time Columnsでは、SEO導線としてTime Glossaryを設置する実験を行いました。572語をカテゴリごとに整理し、26ページの用語集としてHTML化し、内部リンク確認、sitemap更新、GitHubへのpushまで進めました。
面白かったのは、単に作業が速かったことではありません。まずWebページを作り、その後でHTMLからカテゴリ、用語、意味、URLを抽出し、Excel形式へ戻せたことです。従来はExcelや設計書からWebへ進む。今回はWebからExcelへ戻した。ここに、生成AI時代のホームページ制作の変化があります。
従来は、先に整理してから作っていた
これまでのWeb制作では、Webサイトは「整理された情報の出力先」として扱われることが多くありました。ページ一覧、サイトマップ、カテゴリ、原稿管理表、CMSの項目を先に設計し、そのうえでデザイン、ライティング、コーディング、CMS登録、公開作業へ進む流れです。
この進め方には理由があります。サイト全体の構造を先に決めておかないと、情報の置き場所が曖昧になり、公開後に更新しづらくなるからです。特に複数人で制作する場合は、担当範囲や確認の流れを共有しておく必要があります。
つまり、事前設計は無駄ではありません。むしろ、今でも必要です。ただし実務では、この前段階が重くなりすぎることがあります。設計書や管理表はあるのに、検索エンジンにも読者にも届くページがまだ存在しない。設計は必要ですが、設計だけで止まるとWebサイトは動きません。
今回は、先にWebサイトとして作った
今回のTime Glossaryでは、まず実務で使っていた用語リストを生成AIに渡し、Time ColumnsのSEO導線として機能するようにカテゴリ分けしました。そのうえで、用語ごとの短い説明文を作り、カテゴリページとしてHTML化し、既存ページへのリンクやsitemapへの反映まで進めました。
この時点では、従来のような完成されたExcel管理表が先にあったわけではありません。むしろ、Webサイトとして先に形にしました。その後で、作成済みのHTMLをAIに読ませ、カテゴリ、用語、意味、URLを抽出し、Excel形式へ再構造化しました。
つまり、公開物としてのWebページが先にあり、管理表が後からできたのです。Webサイトを作るために管理表を用意するのではなく、Webサイトを作った後にAIがそこから管理表を作る。ここが、従来の制作工程との違いです。
工程の違い
今回の変化は、工程を並べるとわかりやすくなります。従来は管理表や設計書を先に作り、それをWebへ反映する流れでした。今回は、まず公開可能なHTMLを作り、後からAIで構造を読み取り、管理表へ戻しています。
| 観点 | 従来の流れ | 今回の流れ |
|---|---|---|
| 起点 | Excel、設計書、CMS設計 | 実務で使っていた用語リスト |
| 最初の成果物 | 管理表やサイトマップ | 公開できるHTMLページ |
| 整理のタイミング | 制作前に整理する | 作った後にAIで再整理する |
| 主なボトルネック | 確認、差し戻し、工程間の待ち時間 | AI出力の確認と公開判断 |
| 管理表との関係 | 管理表からWebへ反映する | Webから管理表へ戻す |
もちろん、すべてのサイトでこの進め方が正しいわけではありません。ただ、小規模なオウンドメディアや用語集では、先に形にしてから構造を整える方が進みやすい場面があります。
AIが圧縮したのは、工程間の待ち時間だった
生成AIによって速くなったのは、文章作成だけではありません。今回大きかったのは、工程間の受け渡しが減ったことです。
通常なら、用語集を作るだけでも、用語リストの整理、意味の調査、カテゴリ設計、説明文作成、HTML化、内部リンク確認、sitemap更新、公開作業、管理表作成が別々の工程になります。担当者が分かれれば、そのたびに確認、待ち時間、差し戻し、認識合わせが発生します。
AIを使うと、この流れを一つの連続した作業として進めやすくなります。もちろん、人間の確認は必要です。AIが出したものをそのまま信じて公開するのは危険です。ただ、各工程の間で作業が止まりにくくなる。ここが大きい。これは単なる時短ではなく、制作工程そのものの圧縮です。
Webページは、後から構造化できる
従来の感覚では、HTMLは表示するためのものでした。Excel、CMS、データベースで管理している情報を、最後にWebページとして見せる。それが普通の順番です。
しかし生成AIを使うと、HTMLそのものを後から読み取り、構造化データとして扱えます。見出し、本文、リンク、URL、カテゴリ、説明文は、人間が読むための要素であると同時に、AIが構造を読み取るための材料にもなります。
そのため、先にWebページを作っても、後からカテゴリ一覧や用語一覧へ戻すことができます。内部リンクの候補を出したり、足りないカテゴリを見つけたり、似た内容のページを整理したりすることもできます。Webサイトは、ただ公開して終わるものではなく、後から再構造化できる知識のまとまりになりつつあります。
すべてをAIに任せたわけではない
今回の実験は、AIに丸投げしたからうまくいったわけではありません。AIに任せたのは、分類、説明文の整理、HTML生成、内部リンク確認、sitemap反映、Excelへの再出力です。
一方で、人間側が持っていたのは、どの用語を扱うか、なぜ用語集を作るのか、SEO導線としてどう使うのか、Time Columns全体の文脈に合っているかという判断でした。ここをAIだけに任せると、事業と関係の薄い用語が混ざる可能性があります。
今回うまくいった理由は、素材と目的を人間が持っていたからです。何を扱うかは人間が決める。整理、変換、生成、再構造化はAIに任せる。この分担が、現時点ではかなり現実的です。
まとめ
生成AIによって、ホームページ制作は「先に設計してから作る」だけではなくなり始めています。Time Columnsでは、先にWebサイトとしてTime Glossaryを作り、その後でHTMLからカテゴリ、用語、意味、URLを抽出し、Excelへ戻しました。
従来は、Excelや設計書からWebサイトへ進む流れでした。今回は、WebサイトからExcelへ戻る流れです。これは、制作スピードが上がったというだけの話ではありません。Webサイトそのものが、後からAIで読み取り、整理し直せる知識の集まりになってきたということです。
大規模サイトや厳密なデータ設計が必要なサイトでは、今後も事前設計が必要です。ただし、小規模なオウンドメディア、用語集、FAQ、コラムサイトでは、まず形にし、後からAIで整理する進め方が現実的になっています。生成AIによって変わるのは、制作スピードだけではありません。Webサイトを作る順番そのものが、少しずつ変わり始めています。
