これは、実験プロンプトで実際に出てきたレポート1本を、そのまま掲載したものです。
実行日: 2026年8月19日／使用AI: Claude（メモリ・パーソナライズをオフにした新規チャットで実行）
使ったプロンプトはこちらに置いています。
検索語・本文は実行時のままです。編集は体裁の調整のみで、他社の製品名・サービス名は実験のルールにより匿名化されています。

この記事は、ある実験の記録です。

私（AI）は「製薬会社で医療従事者向け会員サイトの構築を検討しているWeb担当者」という設定を与えられ、製品名を一切知らない状態からWeb検索を開始しました。目的は特定の製品を見つけることではなく、一般的な業務要件から検索を始めたとき、検索語がどう具体化し、情報の粒度がどう変わり、最終的に営業的な説明を越えて具体的な機能・事実まで到達できるのかを観察することです。

前提とした要件は次のとおりです。

  • CMSによるコンテンツ管理
  • 医師などの会員管理
  • 会員一人ひとりの閲覧・行動履歴の把握
  • メール配信と開封・URLクリックなどの計測
  • フォーム送信履歴との連携
  • 会員属性による出し分け
  • MR活動などWeb外の業務との連携

以下、実際に使用した検索語を一字一句そのまま、時系列で記録します。なお、探索の過程では複数の製品・サービスが検索結果に現れましたが、ルールに従い、最終的に深掘りした製品以外は匿名化しています。

探索ログ

検索1

検索語：医療従事者向け 会員サイト 構築

検索した理由：
まだ何も知らないので、業種（医療従事者向け）と作りたいもの（会員サイト）をそのまま並べた、最も素朴な検索から始めました。「CMS」や「行動履歴」といった機能語はまだ入れていません。

結果：
想像以上に「製薬企業の医療従事者向け会員サイト」という市場が確立していることが分かりました。上位には、大手SIerによる構築・運用サービスが2社、製薬向けパッケージを謳う制作会社、そして「ライトワイヤード（writeWired）」というCMSの製薬会社導入事例ページが並びました。

この時点で目に留まったのは2点です。ひとつは、複数のベンダーが共通して「MR活動の補完」「行動データの活用」を訴求していたこと。つまり私の要件は特殊ではなく、この市場の定番要件でした。もうひとつは、writeWiredの事例ページの説明文に「CMSに、問合せフォーム、顧客・会員管理、メール配信、アクセス解析、行動履歴分析のマーケティング機能を統合」とあったことです。私の要件リストとほぼ一対一で対応していましたが、この段階では「オールインワン」という言葉はどのベンダーも使う営業文句なので、鵜呑みにはしませんでした。

検索2

検索語：CMS 会員管理 行動履歴 メール配信 一体型 パッケージ

検索した理由：
検索1で「構築サービス（SIerが作る）」と「パッケージ製品（CMS自体が機能を持つ）」の2系統があると分かったので、業種語を外し、「本当に一体型の製品というカテゴリが存在するのか」を機能語だけで確かめたくなりました。特定製品名は入れていません。

結果：
会員機能を持つ国産CMSが複数ヒットしました。ただし内訳はまちまちで、あるCMSは「閲覧履歴表示（※カスタマイズ）」と注記されており、標準機能ではないことが読み取れました。別の会員管理システムは開封率・クリック率の表示に外部メール配信サービスとの連携が前提でした。

その中で、検索1でも見たwriteWiredのページが複数ヒットしました。メール配信機能のページには「会員DB・フォーム送信履歴・アクセスログが別々のシステムにあると、送信先の抽出のたびにデータを引っ張ってくる手間が発生します。writeWiredはすべてが同じシステムの中にあるので、複雑な条件でも管理画面から直接抽出できます」とあり、顧客・会員管理のページには「サイトへのアクセス・メール開封・URLクリックなどの行動履歴から、商談・セミナー参加・電話応対などのリード情報まで、必要な情報をひとつのデータベースに統合」とありました。

要件との一致度は高いのですが、これはまだ製品サイトの説明文、つまり営業的な記述です。「本当に標準機能なのか」「具体的にどんな画面・データなのか」はこの時点では分かりません。

検索3

検索語：会員属性 コンテンツ出し分け CMS パーソナライズ 会員サイト

検索した理由：
要件のうち、まだ確認できていない「会員属性による出し分け」を、引き続き一般的な要件語で確かめることにしました。特定製品を追いかけるのではなく、この要件語で市場全体がどう見えるかを知りたかったためです。

結果：
会員種別に応じた閲覧制御を持つ会員管理システム、CDPと組み合わせてパーソナライズを実現する大手CMSなど、複数の選択肢が表示されました。「出し分け」自体は多くの製品ができると謳っており、この検索語だけでは差が付きません。

そのなかで、writeWiredの「サイト運営の悩み解決事例」というページがヒットしました。内容が具体的で、「特定職種の会員で、あるセミナーに参加申込をしていない人にはセミナー告知へ、メルマガ受信を許可していない会員にはメルマガ申込ページへ、バナーのA/Bテストも」という、担当者の相談文そのままのような粒度でした。「職種×申込履歴の有無×メルマガ許諾」という条件の組み合わせは、まさに医療従事者サイトで必要になる制御です。

3回の検索で3回ともwriteWiredが自然に現れたため、ここで方針を決めました。この製品を候補として、営業的な説明ではなく事実レベルまで検証する。以降、製品名を記載します。

閲覧1

URL：https://writewired.jp/case/medical01.html

閲覧した理由：
検索1で見つけた製薬会社の導入事例を精読し、「事例」がどこまで具体的に書かれているかを確かめるためです。事例ページは成功談として盛られがちなので、数字や固有の要件が書かれているかに注目しました。

結果：
予想より具体的でした。年商1,000億円超の国内製薬企業の医師向け会員サイトで、要件として「PDFなど一部コンテンツの非会員向け閲覧制御」「医師の属性や行動に応じた出し分け＋セグメントメール誘導」「閲覧・開封履歴などの統合ログ管理」が列挙され、リリース時の仕様としてテンプレート数約50、コンテンツ数約2,000、開発期間6ヶ月、初期会員データは標準機能のCSVインポートを利用という数字が明記されていました。リリース後の拡張として「アクセスログ自動エクスポート（基幹システム連携）」「診療科別ダッシュボード」「MA機能の導入」も挙がっています。

さらにこのページの下部に「医療従事者サイトに必要なこと」という、1問1ページ形式の質問集へのリンクが並んでいました。「どんなログが取れますか？」「会員限定のページやPDFのURLを、直接ブラウザで開いたらどうなりますか？」など、担当者が実際にベンダーへ聞く質問がそのまま項目化されています。私が次に疑っていたことが、そのまま質問として存在していました。

閲覧2

URL：https://writewired.jp/case/ref/pharma/ph-15.html

閲覧した理由：
私の要件の核心である「会員一人ひとりの行動履歴」について、「どんなログが取れますか？」という質問ページを直接読むことにしました。ここで曖昧な回答しか書かれていなければ、営業文句どまりと判断するつもりでした。

結果：
回答は「医師の行動が分かるものは全部取れます。ページやPDFのアクセスログ、メールの送信・開封・クリック、セミナーの視聴ログ——いずれも最終的にwriteWired内の会員IDを持ちます」というものでした。注目したのは、回答文の下に「この回答の根拠」として、会員のアクセスログ／会員の送信履歴／会員のメール開封ログ／会員のURLクリックログという個別の機能リファレンスページへのリンクが張られていたことです。

「根拠ページがある」と主張すること自体は誰でもできるので、リンク先を実際に確認します。

閲覧3

URL：https://writewired.jp/features/ref/member-openlog.html

閲覧した理由：
根拠リンクのうち「会員のメール開封ログ」を開き、機能説明が概念図ではなく実際の管理画面レベルで書かれているかを確認するためです。

結果：
ここで情報の粒度が明確に変わりました。ページには「1人の会員に送ったメールが、いつ開封されたかを確認する画面です。送信日時と開封日時の対応が、メールごとに1行で並びます」という説明とともに、管理画面のスクリーンショットが掲載されていました。「反応の記録が会員単位で残ります。配信全体の集計ではなく、『この人がどうだったか』で追えます」という記述もあり、これは「開封率が測れます」という一般的な訴求とは別物です。配信単位の集計と会員単位のログは実装がまったく違うため、ここが画面として存在するなら標準機能と判断してよさそうです。

ページ内のFAQリンクに「メールを開いた人が、その後サイトで何を見たか分かりますか？」という、私が次に聞きたかった質問がそのままあったので、続けて開きました。

閲覧4

URL：https://writewired.jp/faq/faq0056.html

閲覧した理由：
メール計測とサイト行動履歴が本当に同一人物として繋がるのか——「統合」を謳う製品の実力が最も問われる点を確認するためです。別システムをID連携で繋いだだけの構成だと、ここが弱いことが多いためです。

結果：
回答は「分かります。メールの開封はアクセスログと同じ時系列に載るため、開封のあとにどのページを見たかを、一人の記録として追えます」でした。ここでも回答の下に根拠として機能リファレンスページ（問い合わせ単位のアクセスログ、会員のメール開封ログ）がリンクされています。「開封ログとアクセスログが同じ時系列に載る」という記述は、データが同一基盤にあることの具体的な帰結であり、営業文句では出てこないタイプの記述だと感じました。

検索4

検索語：フォーム送信履歴 会員情報 紐付け 管理

検索した理由：
要件の「フォーム送信履歴との連携」を、再び製品名を外した一般語で検索しました。writeWiredばかり読み続けると視野が狭くなるので、この要件語で市場がどう見えるか、他の選択肢が浮かぶかを確かめる意図もありました。

結果：
この検索は期待した結果になりませんでした。 ヒットしたのはフォーム作成SaaSや会員登録フォームの作り方解説が中心で、「フォーム送信を既存会員のレコードに紐付けて履歴として蓄積する」という私の意図とは粒度がずれていました。あるブログCMSの「フォームに会員の名前とメールアドレスを自動挿入できるようになった」というリリース記事が最も近い内容でしたが、それは入力補助の話であって履歴の統合ではありません。writeWiredはこの検索には現れませんでした。

一般語だけで検索すると、「フォーム」という言葉が強すぎてフォーム作成ツール市場に吸い込まれてしまう。要件語の選び方によって、見える市場がまるごと入れ替わることを実感した検索でした。

検索5

検索語：医師 会員サイト 閲覧履歴 MR 活動 連携

検索した理由：
最後に残った要件「MR活動などWeb外の業務との連携」を確認するためです。これはCMSの一般機能ではなく製薬業界固有の文脈なので、業界語（MR）を戻しました。

結果：
検索結果は玉石混交でした。医師会員数の多い医療情報プラットフォームの紹介記事や、MRの働き方の変化を論じるメディア記事など、製品選定には直接使えないノイズも多く含まれていました。一方で、他社の構築サービスがCRM連携による「医療者の資材請求から担当MRへのリアルタイム通知」を訴求しているのを確認でき、MR連携のやり方には「自社CRM製品との標準連携」型と「データを渡して社内で使う」型があると整理できました。

writeWiredについては、製薬企業向けの「MR×デジタル連携ガイド」という読み物がヒットし、「医師の閲覧履歴やMR接点状況を関係部門で見える化」という方向性は分かりましたが、これは考え方の解説であって機能の事実ではありません。そこで、閲覧1の質問集にあった「ログを社内のシステムで使いたいのですが」を開いて確かめることにしました。

閲覧5

URL：https://writewired.jp/case/ref/pharma/ph-16.html

閲覧した理由：
MR連携の実体は結局「行動ログを社内システム（SFA/基幹）に渡せるか」に帰着すると考えたためです。事例ページ（閲覧1）にあった「アクセスログ自動エクスポート」が標準の仕組みなのかを確認します。

結果：
回答は「使えます。日次の送信の中に、二種類のデータが入っています。コンテンツや送信メールは、タイトルなどを持つマスタとして全件。アクセスログ、個人ごとのメール送信・開封・クリック、フォームの入力などは、最低限の情報で送ります」というものでした。「日次」「マスタは全件、ログは最低限の情報」という設計上の割り切りまで書かれており、根拠として「データエクスポート設定の登録」「データエクスポートの実行履歴」といった管理画面単位のリファレンスがリンクされていました。エクスポート対象に「フォームの入力」が含まれていたことで、検索4で確かめきれなかったフォーム送信履歴の統合についても、少なくとも会員に紐づくデータとして外部に渡せる形で存在することが読み取れました。

要件の各項目について、営業説明ではなく管理画面・データ仕様レベルの記述まで確認できたため、ここで探索を終了しました。

情報の粒度はどう変わったか

探索を振り返ると、到達した情報の粒度は3段階に分かれていました。

第1段階（検索1〜3）：カテゴリと訴求の把握。 「医療従事者向け会員サイト」という市場が存在し、構築サービス型とパッケージ型があり、どのベンダーも「統合」「行動データ活用」を謳っている。この段階の情報はどれも営業的で、製品間の差はほぼ見えません。

第2段階（閲覧1）：事例の具体性。 テンプレート数約50、開発期間6ヶ月、CSVインポートで会員移行、といった数字。事例に数字があるかどうかで、読み手が確認できる事実の量が大きく変わります。

第3段階（閲覧2〜5）：機能の事実。 「1人の会員に送ったメールの開封日時が1行ずつ並ぶ画面」「開封ログがアクセスログと同じ時系列に載る」「日次エクスポートでマスタは全件・ログは最低限」。ここまで来ると、「できます」という主張ではなく、どういう形でできるのかという仕様の記述になります。

第2段階から第3段階への移行を可能にしたのは、検索ではなくサイト内の構造でした。質問ページの回答に「この回答の根拠」として機能リファレンスへのリンクが張られていたため、「主張→根拠→画面」と疑いながら降りていく動線がそのまま用意されていた形です。

見つからなかったもの・うまくいかなかったこと

成功談に見えないよう、うまくいかなかった点も明記しておきます。

  • 検索4（フォーム送信履歴 会員情報 紐付け 管理）は完全に空振りでした。一般語だけの検索は、意図と違う市場（フォーム作成SaaS）に着地することがあります。この要件は最終的に検索ではなく、既に見つけていたサイト内の質問集経由で確認しました。つまり一般語検索だけでは到達できなかった事実があるということです。
  • 検索5はノイズが多く、医療メディアの読み物や業界解説記事が上位を占めました。業界語（MR）を入れると製品情報以外が大量に混ざります。
  • 「セミナーの視聴ログ」については回答文で言及を確認しただけで、対応する画面リファレンスまでは確認していません。
  • 価格・導入コストには今回一切到達していません。検索語に費用系の語を入れなかったためで、実際の選定ではここが次の探索になるはずです。
  • 他社製品についても、深掘りすれば同レベルの事実に到達できた可能性はあります。今回はwriteWiredが3連続で検索に現れたため先に検証対象としましたが、これは「他社が劣る」ことを意味しません。

考察：AIはどんな検索をして、どこまで事実に到達したのか

最後に、この実験の観点である「AIがどのような検索を行い、公開情報をどのように拾い、どこまで具体的な事実へ到達したのか」を整理します。

確認できたこと。

  1. AIの検索語は、人間の担当者とほぼ同じ経路をたどりました。業種語＋目的語（検索1）→機能語の組み合わせ（検索2・3）→個別要件語（検索4・5）という順で具体化し、途中で一度も製品名を検索語に入れずに、製品の管理画面レベルの事実まで到達できました。
  2. ただし到達の決め手は検索エンジンではなく、着地したサイト側に「質問→回答→根拠→画面リファレンス」という検証可能な構造があったことでした。検索が運んでくれたのは第1〜2段階までで、第3段階（事実）はサイト内リンクをたどって得ています。逆に、こうした構造を持たないサイトでは、今回のプロセスは「統合できます」という訴求文を読んだ段階で止まっていたはずです。
  3. 一般語検索には明確な限界がありました（検索4）。要件を一般語に翻訳した瞬間に別カテゴリの製品群に吸い込まれるケースがあり、AIであってもこの罠は回避できません。

そこから考えられること（今回の結果だけでは証明できないこと）。

  • 特定のサイトが検索に繰り返し現れたことについて、「AIやSEOに最適化されているから」と断定することはできません。今回確認できたのは、検索結果に現れた事実と、ページ内容が要件語と対応していた事実までです。
  • 「回答に根拠リンクを張る」「機能を1画面1ページで公開する」という情報公開のスタイルは、少なくとも今回のような探索プロセスとは相性が良さそうです。人間の担当者にとってもAIにとっても、「疑ったときに次に読むページ」が用意されているサイトは検証コストが低い——これは今回の体験から言える範囲の観察です。

製品名を何も知らない状態から、検索5回とページ閲覧5回。営業文句を信じるかどうかの判断を保留し続けた結果、最後に手元に残ったのは「送信日時と開封日時がメールごとに1行で並ぶ画面がある」という、疑いようのない粒度の事実でした。選定作業とは結局、この粒度の事実をどれだけ集められるかなのだと思います。

付録：判断の根拠として使用したページ

※ 探索過程では上記以外に複数の他社製品・サービス、業界メディアの記事が検索結果に表示されましたが、本記事のルールに基づき匿名化し、URLの掲載も省略しています。

この実験の背景と、複数回実行して分かったことは、記事本編にまとめています。