検索エンジンはなぜ一瞬で見つけられるのか

🎬 アニメーション『検索の前準備と本番』の ①〜② のところです！

クローラの実体は、超大規模なHTTPクライアントです:

1. URLの一覧（フロンティア）から次の訪問先を取り出し、HTTPのGETでページを取得する——『パケットの旅』とまったく同じ手順を毎秒数百万回やっている
2. 取得したHTMLからリンクを抽出して、一覧に追加する
3. 訪問前にrobots.txt※1 を確認し、「入らないで」と書かれた場所は避ける
4. サイト側はサイトマップ※2 で「ここにページがあります」と案内できる
5. JSで中身を組み立てるページは、後段のレンダリング工程※3 の順番待ちになる

登場人物メモ（※の説明）:

• ※1 robots.txt — サイトの入り口に置く「クローラへのお願い」ファイル。強制力はない紳士協定
• ※2 サイトマップ — サイト側が提出するページ一覧。リンクの少ない新ページを見つけてもらう近道
• ※3 レンダリング工程 — クローラ側でJSを実行してページを完成させる処理。素のHTML取得より桁違いに高コストなので、別枠の順番待ちになる

⚠️ イレギュラー（クロールの落とし穴）:

• robots.txt を守りにしてしまう — 見られて困るページは認証で守る。robots.txt は「行儀のよい相手へのお願い」でしかない
• 無限に生成されるURL — カレンダーの「次の月」リンク等でURLが無限に湧くと、クローラの持ち時間（クロールバジェット）を浪費して肝心のページが読まれない

🎬 アニメーション『検索の前準備と本番』の ③ のところです！

「逆引き帳」の正式名は転置インデックス※1 です。作る手順:

1. ページ本文から単語を切り出す——日本語は空白で区切られていないので、形態素解析※2 で「カレー / の / 作り方」と分割する
2. 表記を正規化する（大文字小文字・全角半角・「作り方/つくりかた」などの揺れの吸収）
3. 「単語 → その単語を含む文書IDの一覧」の向きで表に積む。位置情報も添える（後でフレーズ検索や近接度に使う）

向きがすべてです。「文書→単語」の順だと検索のたびに全文書をめくることになる。「単語→文書」に転置してあるから、何十億ページでも一撃で引けます。

登場人物メモ（※の説明）:

• ※1 転置インデックス — 本の巻末索引と同じ向きのデータ構造。検索エンジンの心臓部
• ※2 形態素解析 — 文を最小の意味単位に切り分ける処理。日本語検索には必須の前処理

⚠️ イレギュラー（索引の宿命）:

• 索引は常に少し古い — ページを更新しても、再クロール・再索引までは古い内容で検索される
• 切り出しの失敗 — 新語や固有名詞は辞書にないと変な位置で切られ、検索に引っかからないことがある

🎬 アニメーション『検索の前準備と本番』の ④〜⑦ のところです！

0.5秒の本番でやっているのは「絞り込み」と「採点」です:

1. 検索語を同じ手順（形態素解析・正規化）で単語に分ける
2. 各単語の文書一覧を索引から引き、共通部分に絞り込む
3. 絞った候補を採点する。代表的な観点が2つ——関連度※1（その単語がその文書でどれだけ「効いて」いるか）と、PageRank※2（どれだけ信頼あるページからリンクされているか）
4. 実際は数百の要素（新しさ、モバイル対応、検索者の言語・地域…）を合成した総合点で並べる

⚠️ イレギュラー（採点をめぐる攻防）:

• SEOスパム — 単語の詰め込み、リンクの売買など、採点の癖を突く手口。採点式の非公開・随時更新はこのいたちごっこの防御側
• 順位は人によって違う — 言語・地域・履歴で採点が変わるので、「自分のPCでは1位」は他人の1位を意味しない

登場人物メモ（※の説明）:

• ※1 関連度（TF-IDFの発想） — 「その文書に多く登場し、かつ世間では珍しい単語」ほど効く、という重み付けの古典。現在は機械学習モデルに発展している
• ※2 PageRank — リンクを「他者からの推薦」とみなす採点。詰め込みスパムへの対抗として検索の歴史を変えた発想

まとめ——検索が一瞬なのは、巡回（HTTP）→ 切り出し（形態素解析）→ 転置（索引）→ 採点（関連度+リンク評価）という分業の賜物です。「検索に出ない」ときは、この順に「クロールされているか→索引に載ったか→採点で沈んでいるか」と切り分けていきます。