AI時代のコンテンツ設計――書くことから、事実を持つことへ

著者: 鴻田孝雄（STSD株式会社 代表取締役）　発行: 2026年9月（初版）

1. はじめに——情報を分かりやすく伝える

Webサイトは、情報を分かりやすく伝えるためにあります。

私たちはこれまで、そのために「ページを作る」ことをしてきました。文章を書き、写真を選び、レイアウトを整え、一枚の完成品に仕上げる。この作り方を、長いあいだ疑いませんでした。

生成AIが加わって、ここが変わりました。同じ事実から、短い説明も、詳しい説明も、FAQも、営業向けのページも、カタログも作れるようになりました。ページは人が読むものであると同時に、AIが読む材料にもなりました。

そうなると、重要なのは最初から完成したページを作ることではなく、伝えるべき事実を、使える状態で持っていることではないか。本書は、この考えにもとづいて自社サイトを実際に作り直した記録と、そこから再現できる形に整理した設計の説明です。

作り直しの途中で、二つの実感を書き留めました。

一つは、公開中の導入事例20件を構造化された本文に移し替えたときのものです。「レイアウトの心配は要らなかった。伝わる形は、情報の構造の側にあった」。

もう一つは、作業全体を通してのものです。ページを書いているというより、データベースを設計しているのと同じ感覚でした。

本文では、この二つの実感に至るまでに何を作り、何を検証し、何が分かったのかを、実物と数字で説明します。

2. ページを原本にすると、情報が閉じ込められる

従来の作り方を否定する必要はない。一枚のページとして完成させる工程は、伝わる形を人が最後まで確かめられるという点で合理的だった。

問題は、事実・原稿・HTML・完成ページが一体化していることにある。この形では、情報はそのページの中に閉じ込められる。

同じ機能を、FAQでも説明する。営業向けのページでも説明する。資料でも説明し、AIにも渡す。原本がページしかなければ、そのたびに別々に書くことになる。書くたびに重複が生まれ、内容は少しずつずれていく。

ずれは、書いた直後には見えない。当社サイトで実際に起きていた二つの例を挙げる。

一つ目は、約2年前にAIに書かせて公開した解説記事群である。68本を現在のAIで一括監査したところ、根拠を示せない表現や、古くなった記述が多数見つかった。一本ずつ完成品として公開した記事は、一本ずつ人が読み直さない限り、劣化に気づけない。この68本は、本文を構造化してCSVで往復する形に改め、1日で全数を修正した［注1］。

二つ目は、手書きのHTMLで公開していた導入事例である。構造化された本文への移行時に機械で照合したところ、見た目は通常の文字と同じだが検索ではヒットしない文字が7ページに紛れていた。ほかにも誤字や説明文の脱字が見つかった。いずれも目視の校正では発見できない種類の摩耗である［注2］。

ページを原本にする作り方は、作る工程だけを見れば完結している。しかし、直す工程と確かめる工程が、ページの枚数分だけ人手に残る。情報が増えるほど、この残りは大きくなる。

先に持つべきは完成品ではなく、確かめられる形の事実である。次章から、その作り方を説明する。

注1　デジタル運用ガイド（/knowledges/）全68記事の監査・修正。2026年9月実施。

注2　導入事例20件の移行検証。詳細は第5章。

3. 先に「事実」を作る——種類の違う情報を混ぜない

当社が最初に作ったのは、ページではなく「機能リファレンス」である。管理画面の1画面につき1ページを割り当て、その機能について、これは何か、何ができるか、どんな場面で使うか、根拠は何か、を固定した記述の集合である。現在142本を公開している［注3］。

作った動機は検索対策ではない。AIに製品について書かせるための、照合先を用意することだった。AIは滑らかな文章を書くが、書いてよいことの境界を自分では持たない。境界は人が先に引くしかない。機能リファレンスは、その境界を機械が照合できる形にしたものである。

このとき守った原則が一つある。種類の違う情報を混ぜないことだ。

当社サイトの情報は、次の四つに分けて持っている。

事実と意見を同じ器に入れると、照合ができなくなる。「この機能は便利です」は、確かめる手段を持たない評価である。「この機能は一覧画面のCSV出力に対応している」は、管理画面と突き合わせて確かめられる。四つの分類は、確かめ方が違う情報を、確かめ方ごとに分けたものと言い換えられる。

各記述には識別子を与え、一覧表で管理している。識別子と台帳の役割は第10章で述べる。

注3　機能リファレンス索引: /features/ref/index.html。件数はいずれも2026年9月時点の公開数。

4. AIの仕事は「書く」から「変換する」へ

事実が揃うと、制作の工程が変わる。ゼロから原稿を書く工程が消え、既にある事実を用途に合わせて変換する工程に置き換わる。

当社では、機能リファレンスと導入事例を原本として、次の派生物をAIに変換させた。よくある質問への回答集、対話形式のQA集61件、困りごと別のLP16本、PDFカタログ、長文の全体説明である。この一連の制作期間は約1カ月半で、派生物の本文を人が手で書いた行は無い。人とAIのやり取りは、一覧表形式のCSVの受け渡しに統一した［注4］。

工程が変わると、人の仕事も変わる。この期間に人がしたことは、次の三つに要約できる。

第一に、何を事実として残すかを決めること。機能リファレンスの記述は、AIが管理画面の実物から起こし、人が事実かどうかを確かめて確定した。第二に、変換の指示を出すこと。誰向けに、どの事実を、どの形式へ、を決めるのは人である。第三に、出てきたものを採用するか判断すること。生成された文章は、そのまま使う場合も、捨てる場合もある。

書く工程が消えても、判断の工程は消えない。むしろ、判断だけが残る。

図2　同じ原本から、用途に応じた複数の表現を生成する。

注4　制作実績の棚卸しは開発日誌「一行も書かずに、ここまで作った」（/blog/not-a-single-line.html）に詳細がある。本書の数字は同記事の確定値による。

5. 「出す」工程の分離——データと表現

前章までは「書く」工程の話である。本章では「出す」工程、すなわち原本をHTMLにして表示する工程を扱う。

論点は一つ。データと表現を分離すると、表現力は落ちるのか。

これを、公開中の導入事例20件で検証した。導入事例は当社サイトで最後まで手書きHTMLで残っていた領域で、写真の回り込みや表組みを含み、うち2件は雑誌の誌面のような組み方をしたインタビュー記事である。表現力の損失が最も出やすい素材と言える。

20件の本文を構造化された記述（Markdown）に移し替え、表示はテンプレート側の変換に任せた。結果は次のとおりである。

• 20件すべてが移行後も成立した
• 表現側で必要になった調整は、スタイル3点（画像の中央寄せ・画像の最大幅・表の列幅）のみ
• インタビュー2件も、装飾を除いた構造は他の18件と同じだった。誌面ふうに再構成する工程は用意したが、使用しなかった
• データ側は移行後、一切修正していない

移行の副産物として、機械照合により従来の目視では発見できない不具合（検索にヒットしない文字・誤字脱字）が検出された。これは第2章で述べた［注5］。

結論として、失われた表現は写真の回り込み程度であり、伝達に影響しなかった。ページの枠（見出し・自動生成される目次・ナビゲーション）が、誌面の役割を既に担っていたためである。原本は変えず、出力の方法だけを選ぶ。テンプレートで変換してもよいし、特別な見せ方をしたいページだけAIにHTMLを組ませてもよい。この分離が成立することが確かめられた。

注5　検証の経緯は開発日誌「書く、出すに、AIが加わった」（/blog/writing-and-rendering.html）。

6. 事実を固定すると、表現は自由になる

構造化には、画一化の懸念がつきまとう。同じ原本から出力すれば、同じようなページばかりになるのではないか。観測された結果は逆だった。

同じ原本群から、前章の導入事例20件——装飾を抑えた淡々とした構成——と、次に示す性格の異なるLP7種の、両方が出た。

7種は表現の振れ幅を意図的に広げた実験である［注6］。これが可能だったのは、参照境界——機能リファレンスという照合先——が固定されていたからである。表現がどれだけ強くても、使った語と数字が境界の内側にあるかどうかは、照合で確かめられる。

照合は、制作中に実際に機能した。二例を挙げる。

一つ目は語の照合である。「セミナー機能」と書こうとしたが、機能リファレンスにその名前の機能は存在しない。実在するのは申込みフォームと履歴の機能である。見出しは「セミナーなどの申込みと、その履歴」に改めた。

二つ目は数字の照合である。営業型のLPで使った数字は、公開している導入事例から確認できる3点（12,000ページ・1万人以上・2008年から）に限定した。「会員3万人」のような、それらしく見えるが公開情報で確認できない数字は使わなかった。

図3　強い表現を許しても、語と数字を原本へ照合することで逸脱を検出できる。

表現は自由にする。語と数字は境界の内側から出さない。この二つが両立するのは、境界が文書の規約ではなく、照合可能なデータとして存在するからである。逸脱は、書き手の注意ではなく、検査で検出できる。

注6　7種の実物は /lp/ 配下で公開している。実験の経緯は開発日誌「同じ製品で、LPを7本作った」（/blog/seven-lps.html）。

7. 公開事実の全量集約——6万字ページの生成と検証

事実を分けて持つ設計は、逆向きの操作も可能にする。分けたものを、全部集めるという操作である。

本章では、公開しているすべての事実を1ページに集約する実験を述べる。ルールは次のとおりとした。要約しない。検索対策の語を足さない。営業表現を足さない。公開情報から確認できないことは書かない。各事実には個別の参照先へのリンクを付ける。そして、長さを理由に削らない。人間の通読は前提にしない。検索エンジンとAIが、巨大な1ページから事実を発見し引用できるかを見る実験だからである。

集約は機械で行った。機能リファレンスとFAQの出力データ、導入事例の本文を材料に、AIが1ページに組み上げた。人が本文を書いた箇所は無い。

結果は、60,952字のページになった［注7］。機能リファレンス142本の定義とできること、FAQ110問、導入事例20件の要点を収載し、目次は21項になった。この字数は目標として設定したものではない。既に存在する事実を集めたら、この長さが出た。

生成したページは、原本と機械照合で突き合わせた。結果を示す。

この検証で重要なのは、生成できたことよりも、検証できたことである。6万字のページを人が読んで確かめることは現実的でない。原本が構造化されているから、収載の脱落も、記述の改変も、出典のないリンクも、機械で検出できる。3件の混入も、人の通読ではなく照合が見つけた。

この全量ページは、書いたページではない。原本から出たページである。同じ原本からは、第6章の入口の軽いLPも、この全量の1枚も出る。薄い入口から原本へ辿らせる形と、全量を一枚に展開する形は、同じ原本の両端の出力と位置づけられる。

集約にかかる手間は、原本の構造化の度合いに反比例する。原本が構造化されていれば、全量ページは機械で出る。されていなければ、人が書き直すことになる。全量ページが機械で作れるかどうかは、それ自体が、その組織の情報の持ち方の診断になる。

注7　/lp/all-facts.html。字数・件数は2026年9月の公開時点。

8. 「作れる状態」を持つ

前章の6万字ページが、すべての企業サイトに必要なわけではない。本書の主張は、特定のページを作ることではない。必要になったとき、必要なページを出せる状態を持つことである。

情報への要求は、相手と場面で変わる。製品を全部説明してほしい。特定の業種に関わる部分だけ抜いてほしい。営業資料の形にしてほしい。AIに読ませる資料にしてほしい。初心者向けの問答にしてほしい。要求されるたびに原稿を書き起こすのが従来の対応である。原本を持っていれば、対応は変換になる。

当社が同じ原本から実際に出した派生物を示す。

これらの派生物は、機能リファレンス・FAQ・導入事例のいずれか、またはその組み合わせを原本としている［注8］。派生物を作るたびに原本を書き換える必要はなく、原本を修正すれば、派生物は再生成できる。

この一覧で注目すべきは、製品紹介のページが含まれていることである。従来なら会社が最も力を入れて書く「製品とは何か」のページも、当社では原本から導出した。書き下ろした紹介文と、事実から組み上げた紹介文の違いは、後者は個々の記述の出典を指せることである。

作れる状態は、蓄積の結果として手に入るものではない。第3章の分類と、識別子による管理と、照合可能な形式。この三つを先に決めた結果として手に入る。次章で、この構造を一般化する。

注8　機能カタログは /catalog/、製品紹介は /about/ で公開。カタログは一覧データを渡して生成し、各項目に参照先リンクを埋め込む形式を取る。

9. 三層モデル——事実・編集・表現

ここまでの章は、実物の記述に徹した。本章で初めて、その構造に名前を付ける。

当社が行ってきたことは、三つの層に整理できる。

事実層。 何が事実かを持つ層である。機能の定義、仕様、実績、数字。第3章の四つの分類——機能リファレンス、FAQ、設計リファレンス、導入事例——は、確かめ方の違いごとに分けた事実層の原本群である。

意味・編集層。 誰に、何を、どう伝えるかを決める層である。困りごとの切り口、問いの設計、事実の選択と組み合わせ、文脈の付与。第6章のLP群は、この層の設計を7通りに振った実験だった。

表現層。 形にする層である。Webページ、LP、記事、PDF、メール、AIへの回答。第5章で確かめたのは、この層を原本から切り離せることである。

図1　事実を原本として持ち、意味を編集し、表現へ変換する。AIは主に層の間を変換し、人は各層で判断する。

AIが担うのは、主に層と層の間の変換である。事実を問いに合わせて選ぶ。選んだものを形式へ組む。第4章で「書く」が「変換する」に変わったと述べたのは、この意味である。人が担うのは、各層の判断である。何を事実とするか。誰に何を伝えるか。出てきたものを採用するか。

この整理は、データベースの語彙で言い換えられる。事実層は原本の表、派生物はそこからの出力、照合は参照整合性の検査、識別子はキーである。第1章に記した「ページを書いているというより、データベースを設計しているのと同じ感覚」の説明は、この対応にある。

また、近年使われる語もこのモデルに収まる。Single Source of Truth（情報の原本を一つに保つ原則）は事実層の規律であり、Markdownは層間の受け渡し形式であり、CSVは入出力の器である。いずれも手段であって、目的は変わらない。情報を、分かりやすく伝えることである。

10. CMSの中心は「制作」から「管理」へ

ページをAIが作れるなら、CMSは要らなくなるのか。

当社の観測では、逆である。HTMLを作ることの価値は下がる。その分、原本を管理することの価値が上がる。

管理とは、次の問いに答えられることである。誰がこの事実を変更したか。どれが現行版か。承認されたものか。この事実はどこで使われているか。どのデータから何を生成したか。ページの制作をAIに移すほど、これらの問いは重くなる。生成は速く、大量で、原本の誤りをそのまま増幅するからである。

管理の実務から、二つの観測を挙げる。

一つ目は識別子である。機能リファレンスを10本追加した際、管理台帳の版を9回更新することになった。識別子の体系に意味を持たせているため、勘で割り振ると体系が壊れる。この経験から得た運用は、体系を守る作業はAIに任せ、人は識別子をどこで採るかだけを決める、というものである。情報を増やすとき最初に問われるのは、書く内容ではなく、識別子の採り方だった［注9］。

二つ目は出力の口である。事実層を外部に提供する仕組み——いわゆるAPI——を試作したところ、必要だったのは一覧用のテンプレート1枚だった［注10］。原本の管理ができていれば、出力の口は薄くて済む。逆に言えば、出力のたびに厚い仕組みが要るなら、それは原本側の管理が薄いことの兆候である。

CMSはContent Management Systemの略である。その中心が「ページ制作」から「情報の管理」へ移るのは、変質ではなく、名前の示す場所へ戻ることだと当社は考えている。

注9　開発日誌「AIに127本書かせた。その後の方が面倒だった」（/blog/where-do-you-get-the-id.html）

注10　開発日誌「SSOTのAPIを作ったら、テンプレートが1枚増えただけだった」（/blog/api-was-a-template.html）

11. おわりに——書かなくなる話ではない

「AI時代は、人間が文章を書かなくなる」。本書の結論は、そうではありません。

ここまで述べた作り直しの間、人間はずっと判断をしていました。何を事実として残すか。何が正しいか。どこまで言ってよいか。誰に何を伝えるか。出てきたものを採用するか。どれもAIには渡していません。

変わったのは、その判断のたびに、完成原稿まで手で作る必要がなくなったことです。判断と制作が分かれ、制作が変換になった。本書が「書くことから、事実を持つことへ」と呼んだのは、この変化のことです。

最後に一つ。本書自体が、本書で説明した方法で作られています。本文は構造化された原本として管理し、Web版とPDF版は同じ原本からの出力です。本文中の数字は、公開している事実と照合してあります。

Webサイトの仕事は、ページを作ることではありません。情報を、分かりやすく伝えることです。AIが加わって変わったのは、そのための作り方なのだと思います。

本書について

著者: 鴻田孝雄（STSD株式会社 代表取締役）。本書の構成・整理・変換・照合には生成AIを使用した。何を事実として残すか、何を採用するかの判断は著者による。本文中の事実は2026年9月時点の公開情報にもとづく。

PDF版（同一の原本からの出力）: /whitepaper/ai-content-design.pdf