前回までのあらすじ
前回までに、製品の事実を機能リファレンス127本に、詳しい話を用途別のQA集61問に、入口を用途別LP19本にしました。Webサイトとしては、これで一区切りです。
残っていたのが、資料でした。
「資料をください」に、渡せるものがなかった
商談では、PDFの資料を求められます。ところが手元にあるのは、作り直す前の古い資料だけ。LPのお問い合わせボタンの隣に「カタログ」と書きたくても、渡せるものがありませんでした。
新しく資料を書き起こす気は、ありませんでした。書けば、また売り文句に戻ります。
Webを、そのままPDFにした
考え方は単純です。サイトの公開情報は、コンテンツをデータとして持っています。機能リファレンスも、LPも、CMSからCSVで出力できます。その出力データをHTMLに組み直し、PDFに変換する。カタログのために新しく書いた文章は、表紙の副題と、会社概要くらいです。
つまり、カタログは「書くもの」ではなく、同じコンテンツのもう一つの表示形式でした。
全部盛り1冊と、用途別19冊
作ったのは2種類です。
- 全部盛り(8ページ)——用途の一覧と、9つの製品領域の「できること」、機能リファレンス127本の目次
- 用途別(各1ページ)——LPと同じ構成: 誰向けか・使う機能・QA集への入口。19の用途ぶん
どちらも、詳細を紙に書き込まない「目次カタログ」として意図的に設計しています。各項目にはWebページへのリンクを埋め込み、詳しい内容はWebで読んでもらう。紙に転記した瞬間から古びていく詳細はWebに置いたままにして、情報の新鮮度を担保するためです。その旨は、PDF自体にも書いてあります。
2種類といっても、生成の仕組みは一つで、違うのは「どのコンテンツを入れるか」だけです。Webページで空欄のセクションを表示しない作りは、紙でもそのまま成立しました。QA集のないLPのカタログには、QA集の節が出ません。
登録は不要です、と書いた
配り方も決めました。ダウンロードに、会員登録やメールアドレスの入力は求めません。/catalog/のページに「登録は不要です」と書きました。
資料を小出しにしてメールアドレスと引き換える、というやり方が、私は好きではありません。製品情報はサイトに全部出しています。同じ情報のPDF版に、名前を書かせる理由がありません。
一日で、20冊できた
朝に「カタログを作り直そう」と話し始めて、夜には全部盛り1冊と用途別19冊、あわせて20冊のPDFと置き場の/catalog/ページまで公開できました。元のデータが揃っていたからです。事実が変わったら、出力をやり直して同じ名前のPDFに差し替えるだけです。
この夏、作ったもの
カタログで一区切りなので、この期間に作ったものを全部並べます。
| 作ったもの | 元にしたもの | 誰がどのように | できたもの | 件数 | 採用 |
|---|---|---|---|---|---|
| 台帳 | 管理画面の全機能 | 私が数え上げ、AIが整備 | 機能・パターンのxlsx台帳 | 2冊(機能の台帳はv97まで改版) | 〇 |
| 画面キャプチャ | デモ環境と本番 | 私が撮影、AIがチェック | 掲載用の画面カット | 150カット | 〇 |
| 機能リファレンス | 台帳とキャプチャ | AIが下書き、私が赤入れ | 1画面1ページの事実 | 127本 | 〇 |
| FAQ(初代) | 旧製品ページ | AIで量産 | ページ内の問答ほか | 多数 | × 表示をやめ削除 |
| FAQ(作り直し) | 機能ページの事実 | 質問は資産、答えは全部書き直し | 根拠つき1問1ページ | 117問 | 〇 |
| 設計リファレンス | 私へのAIインタビュー | AIが聞き、私が答える | 開発の考え方 1パターン1ページ | 15本(候補52から) | 〇 |
| 事例リファレンス | 公開中の導入事例20本 | AIが読者役で質問を量産 | 質問の台帳 | 1,527問 | × 9割を捨て、公開0(第8回) |
| QA集 | 私へのAIインタビュー | AIが聞き、私が答える | 用途別の1問1ページ | 61問 | 〇 |
| 用途別LP | 127本の事実とQA集 | AIが組み立て、私が赤入れ | 用途の入口ページ | 19本 | 〇 |
| カタログPDF | 公開コンテンツのCSV出力 | AIが変換 | 全部盛り1冊+用途別19冊 | 20冊 | 〇 |
| ブログ | 作業の記録 | 私が語り、AIが整える | この連載 | 13本(本記事含む) | 〇 |
振り返って
向きが、全部逆になりました。その分、出口——利用のかたち——が広がりました。
今のGoogleは、検索ワードに対して売り手が記事を作り込んだ結果、「〜とは」コンテンツの羅列になっています。利用者は自分で必要な情報を探すしかなく、大量の「とは」コンテンツがそれをさらに妨げる。自分の知りたいこと、やりたいこと、それを叶えるものが、探せない。
今回やったことは、その真逆です。機能単位に、売り文句を含めずに「何ができるか」をAIが書きました。この過程では、実際の画面キャプチャをAIに解析させ、不明な点や、実際にはできないことを書かないよう徹底しました。突き合わせ先は、管理画面そのもの、導入事例、ときには実際のプログラムコードです。これが、最小単位の機能リファレンスです。
次に、その事実を元に、AIがユーザーの疑問を質問として起こし、機能リファレンスからは読み取れない経験値を、人間である私が答えて補いました。FAQと、用途別のQA集です。ここでもAIが事実と照合し、確認できないものは消していきました。
こうして積み上げた事実を機能ページにまとめ、「こういう困りごとを持っている人がいるだろう」という誘導の窓として、LPを作りました。LPからはQA集を経て、最終的に機能リファレンスの事実に辿り着きます。読者は、自分の望むことが本当に実現できるのか、売り文句ではなく事実で確認できます。
そして、LPを見た人が社内で相談するために持ち帰れるものとして、カタログPDFを用意しました。カタログもAIが作りましたが、渡したのはLP・機能ページ・機能リファレンスのコンテンツをCSVにしたものだけです。
上の表の工程で、コンテンツの作成に携わった人間は私一人です。期間は1カ月半。一番時間がかかったのは台帳の作成とキャプチャの用意、次に、AIのインタビューへ答えることでした。
私は、一行も文章を書いていません。書く代わりに、喋りました——直しの指摘と、判断だけです。CMSテンプレートの新規作成も修正もAIで、プログラムも書いていません。コンテンツの受け渡しはCSVだけで、AIがうちの製品のCSV形式を理解して作るので、そのまま登録・更新できました。ページに表示する関連コンテンツの紐づけもAIが作り、リンク先が実在することの照合まで済ませています。
副産物ですが、機能を事実として棚卸ししたことで、会社の財産にできたと思います。
今回は、AIにコンテンツを拾ってもらうためのフラグメント化、という形で始めました。やってみて、コンテンツの設計も、あり方も、作成の流れも、AI時代で確実に変わってきたな、ということを経験できました。
いったん、手を止めます
カタログPDFの作成という当初の目的を達成できたので、ここでコンテンツの追加は止めます。次回以降は、効果の検証を模索していきます。
「こういう困りごとを持っている人」は、うちのコンテンツに辿り着けるのでしょうか?