AIクローラーの巡回状況をログで確かめる｜月次で見る数字を決める

• Facebook
• X(旧:Twitter)
• はてブ
• LINE

AIクローラーが医院のホームページへ来たかは、サーバーに残るアクセスログで確かめます。接続の記録から対象の通信を絞り、どのページへアクセスして、どんな応答を受け取ったかまで確認するのが基本です。

巡回数の増加が示すのは、観測した接続が増えたという事実です。AIの回答への掲載や来院への貢献は、それぞれ別の確認が必要です。月次では記録がそろっているかを先に確かめ、巡回のあった日数・到達したページ・応答の変化を同じ条件で追います。

この記事では、AIクローラーのログを確認する順序と月次で残す数字、記録を取れない環境での代替手段をまとめています。

AIクローラーの足跡はアクセスログに残る

確認の入口は、ホームページへの接続を受けた機器やサービスのアクセスログです。閲覧数の報告書とは別に、通信ごとの記録を取り出せるかを確かめます。

閲覧数の報告書と接続記録の違い

アクセスログは、ページなどの取得要求に対してサーバーが応答した履歴です。人が画面を読んだかどうかとは別に記録されるため、巡回の有無を調べる材料になります。

院長が閲覧数から巡回の有無を判断するには、まず計測の対象を確かめる必要があります。ページ内の計測用処理が動いた回数だけを数える方式では、その処理を実行しないクローラーの通信は計測の対象外です。訪問者数の表にクローラーの名前がなくても不在とは判断せず、接続記録で確認します。

訪問者数だけでは、クローラーの接続日時やアクセス先を確認できません。制作会社には、この2つが分かる記録の保存状況を尋ねましょう。画面の閲覧権限がなくても、必要な期間の集計を受け取れれば月次の観測を始められます。

記録場所によって見える通信が変わる

自院のホームページについて、接続を最初に受ける場所を制作会社に確認します。本体サーバーの手前に配信を代行するサービスがあれば、そこで保存済みのページを返して応答する経路もあります。その経路では本体へ取得要求が届かないため、本体のログだけを月次報告に使うと観測範囲が狭まります。

そのため、本体側の記録が少ない月は、手前の配信サービスにも接続記録が残るかを確かめます。両方を取得できる場合は別々に集計し、同じ要求を重ねて数えない扱いが必要です。

保存期間と欠けた日を先に確認

月間の件数を読む前に、その月の初日から末日まで記録が残っているかを確認します。保存期間が短く、月初の記録が消えていれば、月末に取り出した数字を1か月分として扱えないからです。

取得できた日付の範囲に加え、途中で記録が止まった時間や収集方法の変更日も残します。全期間を保存する仕組みが用意できるまでは、取得できた範囲だけを観測期間として明記する形で十分です。

AIクローラーのログは日時・ページ・応答を一緒に読む

対象らしい接続が見つかっても、件数だけで巡回成功とは判断できません。相手を識別した根拠に、アクセス先と応答結果を組み合わせると、実際にどこまで届いたかが分かります。

抽出に必要な記録の項目

最初に見るのは、接続日時・要求先のURL・応答コード・接続元の識別情報です。URLはページの住所に当たり、応答コードは要求に対してサーバーが返した結果を数字で表します。

医院側で通信を絞り込むときは、接続元が送る名乗りの文字列であるユーザーエージェントを手掛かりにします。これは相手の自己申告なので、名乗りの一致は候補を探す段階の情報です。担当者には、候補の件数に加えて通信元まで確認できた件数を別欄で示してもらい、確認済みと候補を分けて読みます。

• 接続日時 … 日付と時刻に加え、記録に使われる時刻帯
• 要求先 … 対象サイトとページの住所、取得要求の種類
• 応答結果 … 応答コードと、記録があれば返したデータ量
• 識別の根拠 … 接続元の名乗りや通信元の確認状況

通信の候補と確認済みを分ける

名乗りが一致した件数は、まず候補として扱います。通信元の照合を行った集計なら、その確認方法も報告に添えてもらうと、翌月の数字と同じ基準で比較できます。

たとえば、今月から照合を厳しくした場合は、候補だった通信が対象外になって件数が減る可能性があります。集計方法を変えた月には変更前後の数字を分け、巡回自体が減ったと早合点しない扱いが大切です。

確認の根拠が取れない環境では「名乗りによる候補」と明記し、確認済みの件数へ合算せずに残します。

応答コードで取得結果を切り分ける

自院のページへの到達を評価する際は、応答コードを見て、ページを返せた通信と別の住所へ案内した通信、処理に失敗した通信を分けます。同じページへの10件の接続でも、すべて成功した月と、繰り返し失敗した月では判断が変わります。

別の住所への案内が続くページなら、制作会社への確認対象は移動先の応答です。失敗が続くページなら、該当日時を添えて原因の確認を依頼します。

ただし、200が返っていても、クローラーが内容を保存したか、回答に採用したかまではログから分かりません。取得要求の種類によっては本文を伴わないため、本文を返した通信と混ぜずに集計します。

月次の数字は同じ条件で比べます

前月との差を判断するには、収集範囲をそろえたうえで、比較に必要な少数の数字を並べます。件数の大小だけで評価せず、増減の理由を説明できるかを確かめます。

件数に巡回日数とページ数を添える

取得要求の件数に、巡回があった日数と、アクセスされたページの種類数を添えます。1日に同じページへ100回届いた記録と、10日にわたって複数ページへ届いた記録を区別できるためです。

同じ住所へ繰り返し届いた要求は件数として数え、ページ数では1つとして扱います。画像などの取得を本文ページの集計に含めるかも初回に決めておけば、サイト更新に伴う通信の増加を読み違えにくくなります。

重要ページは個別に到達を記録

サイト全体の集計とは別に、診療内容や診療時間など、患者さんが受診前に必要とする公開ページの到達を追います。全体のページ数が増えていても、確認したい案内に要求が届いているとは限らないからです。

初回に対象ページを選び、毎月の最終到達日時と、そのときの応答を同じ行に残します。月の途中で案内を更新した場合は更新日時も添え、更新後に接続があったかを時系列で読める形にしておきましょう。

更新後の200応答が記録されても、新しい内容がAIの回答に反映されたという意味にはなりません。

集計の定義は初月に固定

比較条件として固定するのは、期間の区切りと時刻帯、対象サイト、通信の抽出条件です。日本時間と別の時刻帯が混ざると月末付近の要求が別の月へ移るため、件数や最終到達日には集計に使った条件を添えます。

サイトの住所の扱いも、ページ数を左右する集計上の条件です。住所の末尾に付く追加情報を含めるかなど、同じページの数え方を記録し、途中で変えた月は比較条件の変更として表示します。

月の日数が違う場合は総件数に加えて1日当たりの件数も使えますが、欠けた時間がある月は日数で割るだけでは補正しきれないため、欠測の注記を残します。

巡回数が増えた月をどう評価すべきか？

増減の評価は、応答の内訳と対象ページを見てから決めます。総件数だけを成果にすると、同じ要求の繰り返しや取得失敗まで改善として数えてしまいます。

増加の中身は成功か再試行か

要求が増えたときは、まずどのページと応答コードが増えたかを確認します。少数の住所への要求とエラーが同時に増えていれば、巡回範囲が広がったと評価する前に、失敗が続く理由を調べる必要があります。

たとえば、要求が前月の2倍でも、同じページへの失敗が増えただけなら到達状況の改善とは言い切れません。反対に、全体件数が横ばいでも、重要ページへ正常な応答を返せた記録が増えていれば、その変化を独立して残せます。

この例の倍率は評価基準ではなく、内訳を読むための仮の数字です。

減少したら記録条件から照合

減少が見えた月は、保存漏れや収集対象の変更を先に確認します。配信サービスを切り替えた場合などは、本体の記録に現れる件数だけが変わり、サイトへの接続全体とは異なる動きを示すためです。

一方、記録条件が同じでエラーも増えていない場合、ログだけで巡回が減った理由を特定するのは困難です。すぐに対策を追加するより、変化が始まった日と到達先を残して次の期間と照合します。

投資判断では到達状況を根拠に限定

月額の支出が続いても手応えが見えなければ、巡回数の増加を成果として受け止めたくなるものです。ログで確かめられるのは接続と応答の事実なので、集患効果の説明とは根拠を分けて受け取るのが適切です。

月額費用に対する成果を確かめる際は、実施した作業と、その前後で減った取得失敗を対応させて見ます。正常に取得できる状態への改善は、ホームページの運用上の成果として評価できます。ただし、その件数を来院数や売上へ換算する根拠にはできません。

AIクローラーが0件でも不在と即断しない

記録が0件なら、抽出条件と観測範囲を確認したうえで「この条件では観測されなかった」と扱います。見えない理由を順に分けると、不要な作業を増やさずに次の確認へ進めます。

全体の接続記録が残っているか

対象の通信を探す前に、同じ期間に一般の接続記録が残っているかを確認します。全体が空なら、巡回の有無より先に、ログの保存や取得に問題がないかを調べる順序です。

日付の抜けがある場合は、記録がある日だけを観測期間として示します。動作確認のために行った自分のアクセスは日時と対象ページを控えておくと、記録の所在を探す際の目印になります。

抽出漏れと閲覧範囲の不足を分離

全体の記録があるのに対象が見つからなければ、抽出に使った項目が保存されているかを確認します。画面上で一部だけ表示されている場合もあるため、一覧表示と取り出した記録の範囲が同じかを照合します。

また、公開サイトと別の管理用画面の記録を見ていないか、対象の住所を確かめる必要があります。複数のサイトを同じ契約で運用している環境では、医院の公開ページを対象として絞った数字かどうかが大切です。

観測できた範囲を結論に添える

記録と抽出条件を確認しても0件なら、その月の観測結果として残します。「接続なし」とだけ書くより、「月初から月末の配信側ログで、指定した識別条件に一致する要求は0件」と記した方が次月との比較に使えます。

0件という結果が当てはまるのは、記録が保存され、指定した条件で通信を探せた期間に限られます。そこから次回の巡回予定は判断できません。初月に到達がなかったページも監視対象に残し、同じ期間の長さと条件で観測を続けます。

到達を確認できなかったページには、対象ページと観測期間を添えて「期間内に観測なし」と記します。最終到達日時や応答を空欄にするだけでは、調べた結果が0件なのか、まだ確認していないのかを区別できないためです。

ログを取れない環境で残せる判断材料

生の接続記録を受け取れなくても、提供元の集計や一定期間の観測を利用できる場合があります。必要なのは巡回の事実をどこまで確認できたかを明記し、空欄を推測で埋めない運用です。

管理画面の集計に定義を添える

サーバーや配信サービスの管理画面に自動巡回の集計があれば、対象期間と分類方法を添えて保存します。自動接続全体の数字だけならAIクローラーの件数として扱わず、分類できている範囲を確認する必要があります。

画面の数字が全件の集計か、一部を抽出した推計かでも意味が変わります。ページ別の応答を確認できない画面では、件数の推移は残せても、重要ページの取得成功まで判断する材料にはできません。

取得できる期間から記録を開始

過去のログが残っていない環境では、今後の記録開始日を決めます。月の途中から始めた初回は途中集計と明記し、翌月から1か月単位の比較へ移すと、開始直後の増加を過大に評価せずに済みます。

取得方法を検討する際は、次の条件を先にそろえます。

• 観測場所 … 公開サイトへの接続を受ける場所
• 保存範囲 … 記録開始日と保存できる期間
• 受け取り方 … 生の記録か、定義付きの集計か
• 月次の担当 … 取得する担当者と確認する日

共有資料には必要な集計だけを載せ、個別の接続元情報や不要なURLの追加情報を広く配らずに済む形にします。

月次報告は事実・未確認・次の確認で結ぶ

月次の結論は、観測できた事実と、記録不足で判断できない部分を分けて書きます。最後に次月の確認対象を1つ置くと、数字を並べるだけの報告から継続して判断できる資料に変わります。

たとえば「重要ページへの接続を確認、応答別の内訳は取得できず、次月は内訳を取得」と残せば、巡回の有無と取得結果の確認状況を混同せずに済みます。取得手段がなければ、その項目は未確認のままにし、観測可能な範囲を増やす作業が見合うかを判断します。

最初の1か月は基準となる記録を作る期間です。翌月以降も同じ数字を追い、エラーや到達先に変化があったときだけ対象を絞って調べる運用なら、院長が毎回大量の記録を読む負担も抑えられます。

よくある質問

• Facebook
• X(旧:Twitter)
• はてブ
• LINE