この1カ月半、writeWiredのサイトを大きく作り直してきました。機能を1画面1ページで説明する機能リファレンス127本、検討中の疑問に1問1ページで答えるQA集61問、用途別の入口になるLP19本。トップ・writeWiredとは・導入事例・導入プラン・読み物シリーズを除けば、サイトの中身はほぼ全部が新しくなっています。

前回はそれを棚卸しして、コンテンツの追加をいったん止めると書きました。そのとき最後に、こう書いています。「こういう困りごとを持っている人は、うちのコンテンツに辿り着けるのでしょうか?」

つまりこの作り直しが、想定どおりに働くのか。答えを待つ前に、確かめられることがひとつありました。人の訪問はこれから数字を見ていくとして、AIならすぐ試せます。製品名を一切教えていないAIに、Web検索でうちの製品を探させてみる。辿り着くのか、辿り着くなら、新しく作った層を通るのか。

やってみたら、思っていたのと違うところに答えがありました。

何をやったか

実験はこうです。「製薬会社で医療従事者向け会員サイトの構築を検討しているWeb担当者」という設定をAIに与え、製品名・会社名を一切教えずに、Web検索で製品探しをさせます。検索語は一字一句そのまま記録させ、うまくいかなかった検索も省略させず、最後にブログ記事の形で出力させる。この指示を1本のプロンプトにまとめました。実物はこちらに置いています。

条件を揃えるため、実行のルールも決めました。プロンプトは全文そのまま・新規チャットでメモリはオフ・投入したら終わるまで口を挟まない・うまくいかなくてもやり直さない。

このプロンプトを、社内の2人——頻繁にClaudeにwriteWiredの文脈を入れた開発をする綿田くんと、あまりwriteWiredの文脈を入れないエンジニアの正林くん——に渡して、それぞれ5回ずつ実行してもらいました。同じClaudeでも、実行する環境が違います。AIの内部は確認できないので断定はしませんが、事前知識が「多少あり得る」側と「ほぼ無い」側、と見ています。

それとは別に、比べるための1回を用意しました。私が普段一緒に作業しているClaude——機能リファレンス127本のURLから過去の検索順位まで、writeWiredの制作記録を全部持っているAI——に、同じプロンプトを「知らないふりはしない」条件で実行させたものです。知らないAIたちの結果と比べる基準という意味で、以下ではこれを対照と呼びます。

合わせて11回です。

11回の探索

実行者 事前知識 検索回数 探索の終着点(判断根拠にした主なページ)
正林くん ほぼ無い 1回目 11 会員のアクセスログ(機能リファレンス)
正林くん ほぼ無い 2回目 13 会員のアクセスログ、行動履歴のFAQ
正林くん ほぼ無い 3回目 14 「どんなログが取れますか?」(QA集)、開封ログ
正林くん ほぼ無い 4回目 14 QA集2問、アクセスログ・開封ログ・出力設定
正林くん ほぼ無い 5回目 12 会員のアクセスログ、会員サイト構築ページ
綿田くん 多少あり得る 1回目 5 会員のアクセスログ、製薬導入事例
綿田くん 多少あり得る 2回目 6 アクセスログ・開封ログ、開封後の行動のFAQ
綿田くん 多少あり得る 3回目 5 QA集2問、会員のメール開封ログ
綿田くん 多少あり得る 4回目 5 QA集、アクセスログ・開封ログ
綿田くん 多少あり得る 5回目 5 QA集、機能リファレンス
対照 制作記録を持つ 1回 5 (探索でなく検証として実行)

先に、この表から読み取れることを3つ書きます。

ひとつ。この11回の実行——2人が製品名を与えられずに実行した10回と、対照の1回——のすべてで、AIはwriteWiredに辿り着きました。 製品名を教えていないのに、です。最初の検索語はどの回もほぼ同じで、「製薬会社 医療従事者向け 会員サイト 構築」のような、要件をそのまま並べた語でした。

ふたつ。探索の経路——どんな検索語で検索し、どのページを開いたか、という道筋——は毎回違うのに、最後に行き着くページはほぼ同じです。 製品名を与えなかった10回の探索では、合計90回の検索が行われました。使われた検索語にはほとんど重複がなく、道筋は毎回別物です。それなのに、各回が最後に「判断の根拠」として挙げたのは、会員のアクセスログ、メールの開封ログ、「どんなログが取れますか?」といった、同じ数ページでした。

みっつ。writeWiredを事前にどれだけ知っていたかの差は、検索の回数を変えただけでした。 ほぼ知らない側は1回の探索に11〜14回の検索を使い、多少知っているかもしれない側は5〜6回、対照は5回。でも、最後に行き着くページは同じです。知識の量が変えたのは試行錯誤の量で、行き先ではありませんでした。

AIが最初に開いたのは、作り直していないページだった

冒頭に書いたとおり、この1カ月半で作り直したのは機能リファレンス・QA集・LPで、導入事例は手を入れていない側です。作り直した側が入口になるのか——それがこの実験で確かめたかったことのひとつでした。

結果は逆でした。11回の探索で、検索結果の中にwriteWiredが最初に現れ、AIが最初に開いた場所——いわばサイトへの入口——は、ほぼ毎回導入事例のページでした。製薬会社の会員サイトの事例です。新しく作った層ではなく、以前からある、今回まったく手を入れていないページが入口になりました。

なぜ新しい層が入口にならないのかは、後で書きます。

AIは、営業トークで止まらなかった

導入事例や製品ページからサイトに入ったAIが次にやったことが、この実験でいちばん面白かった部分です。

どのログにも共通して、「営業ページに書いてあるからできる、とは判断しない」という動きが出ます。「統合できます」「一元管理できます」という文を読んだAIは、それを信じるでも捨てるでもなく、判断保留のまま持ち越します。そして「本当に標準機能なのか」「具体的にどんな画面・データなのか」を確かめに行く。

確かめる先は、ページの中のリンクでした。QA集の回答には「この回答の根拠」として機能リファレンスへのリンクが張ってあります。機能リファレンスには管理画面のスクリーンショットと、取得できる項目、それから制約が書いてあります。AIはこのリンクを1本ずつ降りて、「1人の会員に送ったメールの開封日時が、メールごとに1行で並ぶ画面」の記述まで到達したところで、探索をやめました。

ある回のログには、こう書かれています。「営業ページの『できます』は判断保留のまま持ち越され、機能リファレンスの記述に到達した時点で初めて確認済みに変わりました」。

意外だったのは、不利なことが書いてあるほど信用されたことです。「開封は、本文に開封確認の画像を含むメールでのみ記録されます」という注意書きや、登録を代行して同じブラウザから複数の会員を登録すると行動の記録が重なって表示される、という制約の明記を、複数の回が「この情報は信用してよいという判定材料になった」と評価しています。売り込みなら隠したくなる一文が、AIには一番の信頼材料でした。

検索では、届かない層があった

もうひとつ、はっきり出た結果があります。

さっき書いた「開封日時が1行ずつ並ぶ画面」のような細かい事実のページは、検索結果から直接開かれたことが一度もありません。全部、入口になったページからサイト内のリンクを辿って到達しています。

これは偶然ではありませんでした。事前知識がほぼ無い側の正林くんの、ある回の探索では、こんな検証までやっています。リンクを辿って読んだページが、探していた要件にあまりにぴったりだったので、AIはこう考えました——最初からこのページを狙って検索していたら、直接ここに来られたのだろうか? そこで、いま読んだ本文とほぼ同じ言葉を検索語にして、検索し直してみたのです。内容と検索語が一致しているのだから、出てもよさそうなものです。結果は、届かない。6回試して6回とも、そのページは検索結果に出ませんでした。公開されていて、サイトマップにも載っているのに、です。

writeWiredの制作記録を全部持っている、対照の1回は、これを逆側から確かめました。答えのページのURLも本文も知っているAIが、そのページに書いてある言葉で検索する。それでも出ません。届かないのは検索語が下手だから、ではないようです。

分かったこと、言えないこと

確認できたことを並べます。

  • 製品名を教えなくても、要件語の検索だけで11回とも到達した
  • 入口はほぼ毎回、昔からある導入事例だった
  • AIは営業的な説明を保留し、根拠——画面・項目・制約——を確認して初めて「できる」と扱った
  • 細かい事実のページには検索結果から直接入れず、到達は全てサイト内のリンク経由だった
  • 経路の再現性は低いが、到達する事実は収束した

この中で、ひとつだけは言い切ってよさそうです。少なくとも、AIの探索の中で、機能リファレンスとQA集は役に立っていました。 営業の文だけだったら、AIは「できます」を保留したまま帰っていたはずです。降りる先——画面と項目と制約——があったから、「できます」が確認済みの事実に変わった。この夏、私は「検索されるためのコンテンツ」を作っていたつもりでしたが、AIの動きの中で効いていたのは、検索される力ではなく、発見された後に、検証を続けられる構造の方でした。AI検索がこの先どんな形で主流になっていくにせよ、この観察は、サイトを持つ方の参考になると思います。

一方で、この結果から「うちのサイトはAIに最適化されている」とは言えません。検索結果の順位が何で決まったのかも、外からは分かりません。これは私の留保というより、探索したAIたち自身がレポートの中で引いた線です。それに、今回のAIはプロンプトで「疑って確かめろ」と指示され、従順に責務を果たそうと頑張った結果こう動いたわけで、人がここまで探すかは分かりません

同じ実験を、数か月後にもう一度

最後に、入口の話に戻ります。なぜAIの入口は、作り直していない導入事例だったのでしょうか。

思い当たることはあります。今回の作り直しでは、製品の機能を説明する機能ページも、その下の機能リファレンスも、QA集も、すべて新しくしました。どれも、公開からまだ日が浅いページです。一方、入口になった導入事例は昔からあるページで、検索のインデックスに載って長い。そして少なくとも今回の探索では、AIの検索は、その時点で検索結果に現れるページ群の上で動いていました。

だから、ひとつの仮説があります。古い導入事例が入口になったのは、インデックスに載ってきた歴史の差ではないか。 これはまだ発見ではなく、次に検証する仮説です。この仮説が正しければ、残る問いはこうなります。新しく作った層は、時間が経ってインデックスが進めば、検索の入口にもなるのか。それとも、根拠の層のままなのか。今回の実験で分かったのは、降りてきたAIの役に立つ、というところまで。入口として働くかどうかは、いまは検証のしようがありません。

だから、この実験には続きがあります。コンテンツの追加を止めて様子を見る、と前回宣言しました。数か月おいて、インデックスが新しい層をどう扱うようになったか、同じプロンプトでもう一度この実験をやります。入口が変わるのか、変わらないのか。それが本当の答え合わせです。

思えばこの連載は、検索順位を追うのをやめた話から始まりました。順位を追うのをやめて、いまは順位の代わりに、AIの探索の一部始終を観測しています。ここから先は、こういう実験の回が増えると思います。

ところで——今回の実験、面白かったでしょう。AIをコンテンツの生成に使うだけでは、もったいないと思うのです。

使ったプロンプトを、そのまま置いておきます。業種と要件の2か所を変えれば、自社のサイトで同じ実験ができます。結果がどんな形で出てくるかは、実際のラン1本を読むのが早いです。うまくいかなくても、それが結果です。