先に事実ができていた
この夏、writeWiredのサイトには機能リファレンスというページ群を作りました（作った経緯は一行も書かずに、ここまで作った）。管理画面の1画面につき1ページ、130本。それぞれに「この画面は何をする画面か」「何ができるか」「どんな場面で使うか」が書いてあります。機能リファレンスを36の機能グループに束ねたページと、導入事例20本もあります。
以前は、製品を理解した人がaboutを書き、その下に個別の機能説明をぶら下げる順番でした。今は逆です。aboutより先に、aboutの材料が揃っていました。
全部読ませてみた
材料を2通り用意しました。
- 素材A: 機能リファレンス130本＋機能グループ36本＋導入事例20本
- 素材B: 素材Aに、現在の製品ページ9本を足したもの
素材Aは「事実だけ」、素材Bは「事実に、人が書いた製品説明を足したもの」です。この差で、人が書いた説明が無いと製品説明は出てこないのか、を見ます。
これをChatGPTとClaudeに、それぞれ新しいチャットで渡しました。計4回。指示は次の3つだけです。
- 添付にある事実だけを書く。無いことは書かない。迷ったら書かない
- 各段落の末尾に、根拠にした機能リファレンスのIDか事例名を付ける
- 最後に「この製品の芯だと判断したこと」「書きたかったが根拠が無くて書かなかったこと」「矛盾していると感じた箇所」を書く
2つ目の縛りが効きました。根拠を要求したことで、盛りにくくなりました。同じ縛りはカタログをAIに読ませた実験でも使っています。
4回とも、ほぼ同じものが出てきた
4本の原稿で、製品の芯として挙げられたものが揃いました。
- コンテンツを「ページ」ではなく「項目の集合」として持つ——4本中3本（残る1本は「一度登録した情報を複数の用途で使う」と言い方が違うだけで同じこと）
- 問い合わせ・会員・メール・サイト内の行動が、一人に紐づく——4本全部
どの原稿も「機能リファレンスの『特長』欄に繰り返し出てくるから」を理由に挙げています。製品ページを渡していない素材Aでも同じ芯が出ました。今の製品ページにそう書いてあるからAIがそう要約した、のではありません。130本の事実と20本の事例を平らに読むと、そこへ落ちました。
添付に無いことを書いた「盛り」は、4本合計で1箇所でした。「STSDが開発する」という一文で、材料には「STSDが構築を担当」と、主語の無い「完全自社開発」しかありません。事実としては正しいのですが、材料からは言えない。別の1本は同じ点を「根拠が無いので書かなかった」と申告していました。同じ材料でも、線の引き方はランによって違います。
書けなかったものがあった
今のaboutにはあって、4本のどれもうまく拾えなかったものがあります。
- 組織とサイトの関係（1つの環境で複数の組織が複数のサイトを持つ）
- サイトとディレクトリの構造
- 承認の仕組み
理由は単純です。機能リファレンスは「1画面＝1本」で書いてあります。それぞれの画面で何ができるかは書いてある。でも「この画面とあの画面は、製品全体ではこういう関係にある」は、どの画面にも書いていません。画面をまたぐ構造は、誰かが書かないと存在しない。
事実を全部揃えればAIが何でも理解する、のではありませんでした。今のaboutの前半は、まさにこの「画面に無い構造」を人が書いた部分で、そこだけがAI版に欠けました。
2つのAIで組み立てた
ここからは、4本の原稿を1本にまとめる作業です。私（鴻田）が指示を出し、ClaudeとChatGPTがそれぞれ案を出しました。役割を決めたわけではなく、成り行きでこうなりました。
Claudeは、AIが拾った芯に、人が書いていた構造（組織とサイト・ディレクトリ・権限）を足して統合版を作りました。ただ、構造を先頭に置いたので、初見の人には設計書のように見えます。
ChatGPTは同じ材料で別の案を出しました。「何をする製品か」を先に読ませて、器の構造は後ろに回す章順です。こちらの方が読みやすい。Claudeも「並びはこちらが良い」と認めました。
一方でChatGPT案には、存在しないページへのリンクが1本ありました。Claudeが機能リファレンスの一覧と突き合わせて見つけ、正しいページに直しました。ChatGPTは自分の誤りだと認めた上で、Claude案の冒頭の一文について「将来にわたって不変と読める。公開時に再確認したい」と指摘しました。この一文は今のaboutの結語から持ってきた、このページの主張そのものなので、直さずに再確認事項として残しました。
最終的に、ChatGPTの章順にClaudeの構造の精度を入れた統合版が固まりました。8章です。
- コンテンツを「ページ」ではなく「データ」として持つ
- 一度登録した情報を、別の場所・別の形で使う
- Webの反応も、人の情報も、同じところにつながる
- 集めた情報を、送る・自動化する・見る
- 複数のサイトと組織を、ひとつの環境で分けて運用する
- 公開を止めずに、複数人で運用する
- すでにあるシステムとつなぎ、必要な部分だけを足す
- 使われ方は、サイトの種類では決まらない
1〜4がAIが事実から拾った部分、5と6の一部が人が書いた構造、7と8は事例が支えています。全文はここには載せません。理由は後で書きます。
「これ、次も書かなくていいのでは」
ChatGPT2本、Claude2本、その後の統合案が2本。章の切り方も文章も違います。でも製品の芯は変わりませんでした。
理由は同じです。AIが芯として拾っているのは、機能リファレンスに繰り返し存在する事実だから。機能リファレンスが同じなら、別の日に別のAIで作り直しても、大筋は変わらない。
だとすると、次にaboutを更新するとき、人が古いaboutを開いて推敲する必要がありません。材料をもう一度渡せばいい。変わるのは、新しい機能リファレンスが足されたときと、新しい事例が足されたときだけです。
統合版の申し送りには、こう残しました。
再生成の合図: REFが足されたとき／事例が足されたとき。それ以外では触らない。
aboutは書くものではなくなりました。
aboutは派生物になった
整理すると、サイトのコンテンツはこういう層になりました。
- 機能リファレンス: 画面で確認できる事実
- 設計リファレンス: 複数の画面をまたぐ実現方法や考え方
- 導入事例: 実際にどう使われたか
- about: それらを横断して「この製品は何か」を説明する派生物
aboutは固定ページではなく、事実の層から作り直せるものになりました。事実を一か所に持って派生させる、という考え方はSingle Source of Truthを調べたら、もうやっていたに書いたものと同じです。作り方も残っています。材料の束ね方、プロンプト、検分の物差し。
ついでに分かったこともあります。130本を平らに読んだAIが「矛盾していると感じた箇所」として、機能リファレンス側の穴を9つ返してきました。会員属性による閲覧制御が事例では中心要件なのに機能リファレンスに無い、機能グループの名前が「4つの処理タイプ」なのに中身が5本、機能カテゴリの割り振りが揺れている、など。aboutを書かせたつもりが、台帳の点検になっていました。AIに根拠を辿らせたら宿題が21個返ってきたときと同じことが、別の入口から起きています。
人が書かなくなったわけではない
タイトルだけ見ると「AIが全部書けばいい」に読めます。実際にやったことは逆です。
人がやったのは、何を事実として残すか決めること、機能リファレンスを書くこと、事例を残すこと、画面に存在しない構造を書くこと、AIの出力を検分すること。AIがやったのは、それらを一度に読んで、説明として組み直すことです。
人が文章を書かなくなったのではなく、人が「説明文そのもの」を管理しなくてよくなった。これが一番正確だと思います。
新しいaboutは、まだ出しません
今のaboutはそのままです。統合版は固めましたが、公開は11月以降にします。
8月25日に、このサイトのコンテンツを凍結しました。製品名を知らないAIに検索させる実験を、数か月後に同じ条件でもう一度やるためです。それまではサイトの中身を動かさない、と決めています。aboutはAIが着地する面なので、差し替えると比較が汚れます。
だから今回は「作った、固めた、運用の仕方が決まった」までです。入れ替えたら、また書きます。
コンテンツを作る話から、使う話になった
AIでコンテンツというと、記事を書かせる、FAQを作らせる、紹介文を書かせる、という「生成」の話になりがちです。
今回は、すでにある130本の事実と20本の事例を読ませました。すると、製品説明ができ、不足している説明が見つかり、コンテンツ同士の関係が見え、about自体を再生成できるようになりました。
AIにaboutを書かせた、という話ではありません。aboutを書くための事実を先に管理しておけば、aboutは必要なときに作れるようになった、という話です。
作ったコンテンツを、次のコンテンツの材料として使う。aboutは書くものではなくなりました。
