このブログは、自社のCMS「writeWired」のサイトを、AIと一緒に作り直してきた記録です。この記事の作業は、2026年7月27日の1日で、Claudeと進めました。

やりたかったこと：127本を、ただの一覧でなく、製品ページの中身にしたい

127本の解説は、前日までにそろっていた

writeWiredの製品ページは、売り文句から始まり、機能の一覧は最後に軽く並べてあるだけでした。そこで、機能1つをそれだけで意味の通る1ページに書き、その上に製品ページを組み立てることにしました。管理画面の1画面を1ページにした解説で、「機能リファレンス」と呼んでいます。

127本の文章は、Claudeが画面のキャプチャを読んで書き、私が事実を確かめて赤を入れました。本文の確認で直したのは、127本中1件だけです。画像も1枚ずつ確かめ終えていました。どの機能を1ページにするか、どの順で並べるかは、Excelの台帳で管理しています。

並べただけでは、目録にしかならない

ただ、127本を並べただけでは、機能の目録です。読む人には、自分の仕事があります。メールを配信する人なら、送る準備をして、送って、結果を見る。その流れに沿って、必要なページが必要な順で製品ページに並んでいてほしい。

この日やりたかったのは、127本を公開し、製品ページの中に、読む人の作業の順で並べることでした。

こうやってみた：CSVで一括公開し、まとまりを作業の順に割り付けた

朝：台帳から作ったCSVで、127本を一括公開した

writeWiredには、CSVでコンテンツをまとめて登録する機能があります。私がwriteWiredから出力したCSVの見本を渡すと、Claudeはその形式に合わせて、台帳から127本分のCSVを作りました。62列×127行、すべて機械で作ったものです。

取り込みは、まずテストモードで検証し、通ったら公開します。通りました。127本をその場で公開しました。そのときの私の言葉は「はいった。ぱない」でした。

あわせて、以前の機能紹介ページのURLから新しいページへのリダイレクトを29本設定しました。古いURLで来る人や検索エンジンを、行き止まりにしないためです。

まとまりを、作業の順に製品ページへ割り付けた

127本は、事前に36の「まとまり」に束ねてありました。関連するページをいくつかずつまとめたもので、どのまとまりを、どの製品ページに、どの順で載せるかの割付表も台帳に作ってあります。載せ先は、CMSやメール配信など領域ごとの製品ページ9枚と、機能リファレンスのトップの計10枚です。割り付けは全部で151、23本は複数のまとまりに載ります。127本すべてがどこかのまとまりに載っていることは、機械で確かめてあります。

たとえば今のメール配信の製品ページでは、まとまりがこの順に並んでいます。

  • 送る準備をする（メールアドレス、メールテンプレートの登録）
  • 送る（送信メールの登録、自動返信、問い合わせや会員へのメール送信）
  • 結果を見る（送信メールの一覧、開封ログ、クリックログ）
  • 受け取る・やり取りする（受信ボックス、受信メールへの返信）

ページを上から読むと、メール担当者の作業の順になります。まとまりの名前は、この日は仮のものでした。

表示の処理は、Claudeが書いた

製品ページがまとまりを受け取り、そこに入っている各ページのタイトルとリードを引いて並べる。この表示の処理は、Claudeが書きました。私はできたファイルをサーバーに置き、画面を確かめて、おかしなところを伝えます。この日、私はプログラムを書いていません。

動くと、機能リファレンスからまとまりへ、まとまりから製品ページへ、製品ページから機能リファレンスへ、行き来できる画面が現れました。そのときの私の言葉は「繋がった。やばい。かっこいい」です。

こうなってしまった：Claudeが「どの製品ページに載るか」を項目にも持たせようとした

機能リファレンスのトップには、ページを分類で絞り込む入口を置くつもりでした。分類は、CMS、メール配信といった製品ページの区分です。

ところが、機能リファレンスの「機能カテゴリ」の項目は、一つしか選べない作りでした。1本のページが、複数のまとまりを通して複数の製品ページに載ることがあります。そこでClaudeは、この項目を複数選べる形に変え、127本それぞれに載り先の分類を入れ直す案を出し、そのためのデータの作り直しまで進めていました。

だからこうしてみた：関係は構造で持ち、項目には書き写さない

私は、機能リファレンスからまとまりへ、まとまりから製品ページへ、という関係ではなかったか、と差し戻しました。

どの製品ページに載るかは、まとまりがすでに知っています。まとまりは中身のページを参照で持ち、製品ページはまとまりを参照で持っているからです。同じ事実を各ページの項目にも書けば、まとまりを組み替えるたびに127本の項目を直すことになり、どこかで直し忘れた瞬間から、二つの食い違いが始まります。

だから、分類で絞り込むときは、製品ページからまとまりをたどって、その中のページを集める作りにしました。機能カテゴリの項目は触らず、フォームの変更もデータの作り直しも要らなくなりました。関係は構造で持つ。項目には書き写さない。

入口と関連リンクは、数えてから決めた

機能リファレンスのトップは、業務、分類（製品ページ）、まとまりの三つから引けるようにしました。

業務のタグを数えると、「導入を判断する」には1件も付いていませんでした。機能の解説に、導入の決裁をする人向けのページはありません。0件のタグを入口に出しても、開いた人は何も見つけられないので、該当するページがないタグは入口から自動で消える作りにしました。あとでページが付けば、自動で現れます。

各ページの関連リンクは72本ありました。数えると、同じまとまりの中で閉じるものが50本（69%）、まとまりをまたぐものが22本（31%）です。同じまとまりの中は、まとまりの一覧として並んでいるので、関連リンクとして重ねて見せる必要はありません。関連リンクには、またぐ22本だけを出すことにしました。

Claudeが同じ型のミスを2回した

この日、Claudeは同じ型のミスを2回しています。どちらも、現物を確かめずに進めたものです。

1回目は、導入前の技術確認向けのまとまりを、導入プランのページにも載せようとしたときです。Claudeは、そのページの本文を残したまま載せられる判定が、ページを振り分ける処理のどちらの分かれ道にもあるものと思い込み、確かめずに手順を出しました。実際は片方にしかなく、私が手順どおりに設定すると、そのページの本文（比較表など）が全部消えました。判定をもう片方にも足して、元に戻しました。

2回目は、私が手直しして置いていたファイルを、Claudeが古い版を元に作り直して渡したことです。製品ページが表示できなくなりました。

その場で、ルールを一つ決めました。私の手直しが入ったファイルは、私の手元の現行の実物を元に直す。台帳にも書き残しました。

その後

一日の終わりには、127本が公開され、製品ページ9枚のまとまりとつながり、機能リファレンスのトップから業務・分類・まとまりで引けるようになっていました。そのときの私の言葉は「完成した。思っていた世界観」です。

まとまりの名前は、このあと付け直しています。製品ページの売り文句の側は、この事実の上で、あとから書き直しました。

今回の作業で分かったこと

AIに書かせたページは、並べ方まで決めて、初めて読む人の役に立つ

127本は、この朝の時点でそろっていました。それが製品ページの中身になったのは、どのまとまりを、どのページに、どの順で載せるかを決めてからです。メール配信なら、送る準備、送る、結果を見る、という順に並べたことで、ページが担当者の作業の流れになりました。AIに大量に書かせたあとに残る仕事は、並べ方を決めることでした。

AIが便利な項目を足そうとしたら、その事実がもうどこにあるかを確かめる

「どの製品ページに載るか」を項目に持たせる案は、絞り込みを作るには手早い方法でした。でもその事実は、まとまりの参照としてすでにありました。項目に書き写せば、まとまりを組み替えるたびに127本を直すことになります。AIが項目を足す案を出したら、まず、同じ事実がすでにどこかにないかを確かめる。あるなら、そこからたどるようにします。

見せるかどうかは、数えてから決める

0件のタグを入口から消したのも、関連リンクをまたぐ22本だけにしたのも、数えてから決めました。数えれば、見せても役に立たないものが分かります。

AIが現物を確かめずに進めたら、その場でルールにする

Claudeの2回のミスは、どちらも現物を確かめずに進めたものでした。謝ってもらっても、次のやり取りで同じことが起きます。転んだら、その場でルールにして、台帳に残す。次のチャットのClaudeは、まずそれを読みます。