このブログは、自社のCMS「writeWired」のサイトを、AIと一緒に作り直してきた記録です。この記事の作業は、2026年9月6日から8日にかけて、ChatGPTとClaudeの二つのAIと進めました。ホワイトペーパーの公開は9月9日です。
やりたかったこと：「結局、どう作ればいいの」に答える一本を作りたい
記録はあるのに、考え方のまとまりがなかった
このブログには、サイトを作り直すなかで試したことを、試した順に書いてきました。製品の機能を1画面1ページで説明したページを100本以上AIと作った話、そのページを元にFAQや案内ページを作った話、導入事例をMarkdownに移した話などです。
どれも「何が起きたか」の記録です。読んだ人から見れば、「面白いけれど、自分の会社でやるならどうすればいいのか」が分かりません。考え方は、何本もの記事に少しずつ散らばっていました。
記録と、再現できる設計を分けることにした
9月6日、ChatGPTから、これをホワイトペーパーにまとめてはどうかという案が出ました。私も同じことを考えていたので、そのまま進めることにしました。
分け方は、こう決めました。
- ブログ：何が起きたか。「私たちはこうやった」という記録
- ホワイトペーパー：そこから取り出した設計。「こう設計すると、こうなる」という、ほかの会社でも使える形
ただ、すぐには書き始めませんでした。当時、手書きのHTMLのまま残っていた導入事例20本を、Markdownに移す作業が残っていたからです。サイトのほかのページは、本文をMarkdownで持ち、テンプレートが表示を組み立てる形になっていました。導入事例だけがその外にありました。サイト全体の話として書くなら、全部が同じ作りになってからにしたい。私はそう判断し、着手を事例の移し替えの後にしました。その作業は9月7日に終わりました。
こうやってみた：章立てと書き方の決まりを先に決め、AIに章ごとに書かせた
11章の構成は、手段の名前から始めなかった
章立ては、9月8日にChatGPTが出した案を採りました。起点に置いたのは、「Webサイトは、情報を分かりやすく伝えるためにある」という、私の言葉です。MarkdownやCSVといった手段の名前からは始めない、という構成です。
- はじめに——情報を分かりやすく伝える
- ページを原本にすると、情報が閉じ込められる
- 先に「事実」を作る——種類の違う情報を混ぜない
- AIの仕事は「書く」から「変換する」へ
- 「出す」工程の分離——データと表現
- 事実を固定すると、表現は自由になる
- 公開事実の全量集約——6万字ページの生成と検証
- 「作れる状態」を持つ
- 三層モデル——事実・編集・表現
- CMSの中心は「制作」から「管理」へ
- おわりに——書かなくなる話ではない
前半の2〜8章は、ブログに書いてきた作り直しを、課題・設計・検証・結果の形に置き直したものです。後半の9〜10章で、それを一般化しています。
前の案には、まだ一度も実際に試していない仕組みの章が入っていました。新しい案ではそれが落ち、どの章も、実際にやったことを根拠に書けるようになりました。
ブログとは、書き方の決まりから変えた
私は「固めの資料にしたい」と伝え、書き方の決まりを先に決めました。
- 本文は「である」調。前書きと結びだけ「です・ます」
- 体験談の語り方はしない。課題→設計→検証→結果の順で書く
- 比喩は使わない
- 筆者の感想は前書きにまとめ、本文には置かない
- 数字は表と出典で示す。ブログの記事は脚注で示し、本文はブログを読まなくても通じるようにする
ブログは、つまずいたことも含めて時系列で書いています。同じ出来事でも、ホワイトペーパーでは「何が分かったか」だけを、ほかの会社が使える形で書く。その違いを、文体と構成の決まりで分けました。
Claudeが章ごとに書き、ChatGPTが見て、私が決めた
本文は、Claudeが章ごとに書きました。最初に1〜2章を書かせ、文体の見本にしました。ChatGPTがそれを読み、この固さで最後まで進めてよいと判断しました。私もそれで進めることにしました。そこから残りの章を書かせています。
書き終えたあと、Claudeに全文を照合させました。本文の数字とリンクを、公開している事実と突き合わせ、章と章の間で数字が食い違っていないかを確かめます。食い違いはありませんでした。
言い回しは、6か所直しました。たとえば3章には、もともと「『便利です』は事実ではない」という一文がありました。この本でいう事実は、公開している情報と照らして確かめられるものです。「便利です」は誤りではなく、照らして確かめる手段がない評価です。そこで「確かめる手段を持たない評価である」に直し、確かめられるかどうかという基準に揃えました。
図は3枚。全体の考え方、作り方の流れ、検証の仕組みを、線と文字だけで描いています。
こうなってしまった：Web版を、本の主張と逆の作り方で作りかけた
本文ができたところで、Web版の作成に移りました。Claudeは最初、ホワイトペーパー専用のHTMLページを一から組みました。
これを見て、私はこう返しています。
「今のJSPを使ってMDから変換をイメージしてた」
JSPは、writeWiredでページの表示を組み立てるテンプレートです。導入事例は、Markdownの本文をテンプレートが変換して表示する形に移したばかりでした。私は、ホワイトペーパーもそれと同じ形で出すつもりでいました。
5章「『出す』工程の分離」は、まさにその話です。本文のデータは一つにしておき、どう見せるかは変換の側で選ぶ。そう書いた本のWeb版を、手で組んだHTMLで出せば、本の主張と作り方が食い違います。
だからこうしてみた：Web版もPDF版も、同じ原本から変換した
Web版は、導入事例と同じテンプレートで表示した
専用のHTMLはやめました。Markdownの原本をCMSの本文欄にそのまま入れ、導入事例と同じテンプレートで変換して表示しています。
表示を整える段階では、余白や見出しの色などで何度か手直しが要りました。直したのは、どれもテンプレートやスタイルの側です。原本の本文には手を入れていません。
PDF版も、同じ原本から機械で組んだ
PDF版も、同じMarkdownの原本から、プログラムで組版しました。表紙、目次、章ごとの改ページ、ページ番号が付いて、A4で16ページです。
組むときに本文へ手を入れた行はありません。変換の側で決めたのは二つだけです。著者名は表紙に載るので、本文冒頭の著者の行はPDFでは出さない。サイト内へのリンクは、PDFから開けるように絶対URLに直す。
当初、PDFは30〜45ページくらいになると見込んでいました。16ページは、その見込みを下回ります。ページ数に合わせて本文を足すことはしませんでした。別の形式のために原本を書き足せば、形式ごとに別の文章が生まれます。
どうなったか
9月8日に一式ができあがり、9月9日に公開しました。
発行は「2026年9月（初版）」、著者は私です。末尾の「本書について」には、構成・整理・変換・照合に生成AIを使ったこと、何を事実として残し何を採用するかの判断は著者が行ったことを書いています。
11章のうち、全体の考え方だけを知りたい方は、9章「三層モデル」から読むのが早いと思います。初めての方は、1章からどうぞ。
その後
10月に、このブログの記事を書き直しています。Web版の脚注に載せていたブログの記事名と参照先は、それに合わせて更新する方針です。本文は初版のままにします。
今回の作業で分かったこと
記録と設計は、書き方の決まりから分ける
同じ出来事を書いても、ブログとホワイトペーパーでは役目が違いました。ブログは、つまずきも含めて「私たちはこうやった」を残す。ホワイトペーパーは、そこから「こう設計すると、こうなる」だけを取り出す。今回は、その違いを文体、構成、比喩や感想の扱い、数字の示し方といった書き方の決まりに落とし、AIに書かせる前に決めました。決まりが先にあると、AIの原稿を見るときも、何を直せばいいかの基準になりました。
方法を書いた文書は、その方法で作ると、作り方そのものが確かめになる
Web版は、最初は手組みのHTMLで作りかけました。原本1本から変換して出すと書いた本を、その方法で作れるか。テンプレートでの変換に切り替えてやってみると、Web版もPDF版も、本文に手を入れずに出せました。書いたことを自分の文書で試すと、主張が実際に成り立つかを確かめることにもなります。
原本を1本にしておくと、形式ごとの直しが要らない
Web版とPDF版で、別々に本文を直した箇所はありません。表示の手直しはテンプレートとスタイルの側で済み、PDFのページ数が見込みより少なくても、本文は足しませんでした。形式ごとに文章を持たないと決めておくと、本文を直す場所は原本の一か所になります。
