前回までのあらすじ

前回までに、製品の事実を機能リファレンス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の作成という当初の目的を達成できたので、ここでコンテンツの追加は止めます。次回以降は、効果の検証を模索していきます。

「こういう困りごとを持っている人」は、うちのコンテンツに辿り着けるのでしょうか?