> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# XPathとCSSセレクタ

> CSSセレクタとXPathはどちらもページ上の要素を特定しますが、壊れ方が異なります。それぞれの仕組み、使い分け、長持ちするセレクタの書き方。

セレクタはルールベースのスクレイパーの土台です — スクレイピングツールにページのどの要素からデータを抜き出すかを正確に伝えます。よく書かれたセレクタはサイトの軽微な更新を越えて動き続けますが、脆いセレクタは開発者がクラス名を1つ変えたり、レイアウトを並べ替えたりした瞬間に壊れます。長持ちするセレクタの書き方を理解することは、Webスクレイピングで最も実用的なスキルの1つです — セレクタを自動生成してくれるビジュアルツールを使っていても、ここに時間を投資する価値があります。

主なセレクタ言語は2つあります:**CSSセレクタ**と**XPath**。どちらもHTML文書の中で[要素を特定](/docs/jp/academy/anatomy-of-a-web-scraper)できますが、仕組みが違い、それぞれに相手にない強みがあります。

## CSSセレクタ

CSSセレクタは、Web開発者がスタイルシートに書くのと同じ構文を使うため、フロントエンドの経験が少しでもあれば直感的に感じられます。タグ名、クラス、ID、属性、そして他の要素との関係に基づいて要素を選びます。例えば`div.product-card h2`は、クラス`product-card`を持つdiv内のすべての`h2`要素を選びます。CSSセレクタは一般に短く、読みやすく、ブラウザでの評価も速いです。多くの直接的な抽出タスクでは、まずこちらが既定の選択肢になります。

## XPath

XPathはより強力ですが、より冗長です。HTML文書をツリーとして扱い、どの方向にも辿れます — 親から子への下方向だけでなく、上方向に親へ、横方向に兄弟へ、さらに文書全体を横断することもできます。重要なのは、XPathが**テキスト内容に基づいて**要素を選べることです — `//a[contains(text(), "Next Page")]` のように — これはCSSセレクタにはできません。これにより、ラベルでボタンを見つけたり、書かれている内容で表のセルを特定したりするタスクにXPathは不可欠です。XPathは条件式、関数、複雑な述語もサポートしており、変則的なページ構造に対する表現力が高くなります。

## どちらをいつ選ぶか

両者のトレードオフは、簡潔さと柔軟性の対立に帰着します。CSSは多くの一般的なケースをよりきれいに扱います。XPathは、HTML構造が扱いにくいとき、テキストベースのマッチングが必要なとき、欲しい要素が直接の親ではなく兄弟や祖先との関係でしか特定できないときに、手を伸ばす道具です。

## 長持ちするセレクタの書き方

どちらの言語を使うにせよ、耐久性はいくつかの原則に集約されます:

* **自動生成のクラス名を避ける**。[React・Vue・Angular](/docs/jp/academy/scrape-javascript-pages)のようなフレームワークは、ビルドごとに変わるクラス名(`.css-1a2b3c` のたぐい)を生成しがちで、地雷です。
* **意味のある属性を優先する**。`id`、`data-*`、`role`、`aria-label`はスタイリング以上の意味を担っているため変わりにくいです。`[data-product-id]`に錨を下ろしたセレクタはスタイルシートの書き換えを生き延びますが、`.flex-row__inner--lg`を頼ったセレクタは生き延びません。
* **セレクタは短く保つ**。親子関係の鎖が長くなるほど、途中のレイアウト変更で鎖全体が壊れる可能性が高くなります。
* **位置に依存するセレクタを避ける**。`nth-child`や`/html/body/div[3]/div[2]/ul/li[1]`のような絶対XPathパスは、要素がDOM上の正確な位置にあり続けることを前提にします — ほぼ常に成り立たない前提です。
* **最も近い安定したランドマークに錨を下ろす**。文書のルートから辿るのではなく、意味があって変わりにくい識別子を持つ最も近い要素を見つけ、そこからの相対で選びましょう。

## Shadow DOMという新しい壁

セレクタにとって新たに立ちはだかるのが **Shadow DOM** — DOMの一部を閉じた境界の中にカプセル化するWebコンポーネントの機能です。標準のXPathもCSSセレクタも、シャドウルートの内側には届きません — つまりWebコンポーネント内の要素は、伝統的なスクレイピング手法からは見えません。モジュラーなUI構築のためにWebコンポーネントを採用するサイトが増えるにつれて、これは実際的な問題になりつつあります:スクレイパーにコンポーネントの外殻は見えても、その中で描画されている中身が見えないということが起きます。解決にはシャドウルートを貫けるツールが必要です。Playwrightは標準セレクタを`>>`構文で拡張してこれを実現します;Octoparseも同様に、XPathをカスタム構文で拡張し、生成されたセレクタが通常のDOMサブツリーを辿るのと同じ仕方でシャドウルートの内側に届くようにしています。

## Octoparseのセレクタへのアプローチ

Octoparseは要素のターゲティングに主に **XPath** を使います — これは意図的な選択です。XPathのツリー走査モデルは、技術者ではないユーザーがページ構造について考える仕方に自然に対応します — 「この商品カードの中の価格」という捉え方は、CSSセレクタの連鎖よりXPath式に直接訳しやすいのです。これにより、開発者ではないがセレクタを見直したり調整したりする必要があるユーザーにとっても、扱いやすさが保たれます。

さらに重要なのは、ユーザーが要素をクリックしたとき、Octoparseは「とりあえず動くXPath」を生成するのではなく、**インテリジェントな属性優先度アルゴリズム**を適用していることです。システムは利用可能な属性をその意味的な安定性で評価します:`id`・`data-*`・`role`のような意味のある識別子を、移ろいやすいクラス名や脆い位置インデックスより優先します。自動生成されるXPathは、サイトの軽微な変更を生き延びるように設計されています — 並べ替えられたレイアウトや更新されたスタイルシートは、安定した`data-product-id`属性に錨を下ろしたセレクタを壊しません。`三番目のセクションの中の二番目のdiv`という経路に頼ったセレクタなら壊れるところを、です。

このアルゴリズムは **Octoparse 10.1.0** でゼロから作り直され、自動生成されるセレクタの精度はトップクラスになりました — 大半のページで、最初のクリックで正確かつ堅牢なXPathを生成するため、セレクタを手作業で直す時間が減ります。

Webコンポーネントで作られたページに対しては、同じジェネレータが **Octoparse独自のShadow DOM向けXPath拡張** を使ったセレクタを生成します — シャドウルート内側の要素も、通常のDOMの要素と同じ仕方でアドレスできます。別のセレクタ方言に乗り換える必要はありません。

新しいジェネレータに加えて、Octoparseは2つのAI機能を備えています:

* **AI支援のXPath生成** — より広いページコンテキストを評価して、より耐久性の高いセレクタを生成する
* **AIによる自己修復** — 壊れたセレクタを検知し、変化したページ構造に基づいて再構築する。**ページネーション**（移動・改名された「次へ」コントロール）と**フィールド**セレクタ（レイアウト内で位置が変わった値）の両方に対応し、本来なら止まってしまうタスクを動かし続けます

これらの追加は、現代のWebが向かっている方向を反映しています — ページはより動的に、よりコンポーネント化され、よりカプセル化されつつあります。スクレイピングツールはそれに追いつかなければなりません。

## まとめ

ビジュアルツールを使うときも、セレクタの基本に時間を投資しましょう。何がセレクタを脆くし、何が長持ちさせるのかを理解していれば、自動生成された結果を評価でき、タスクが壊れたときにトラブルシュートでき、最初の実行だけでなく数週間・数ヶ月にわたって動き続けるスクレイパーを作れます。セレクタが生の値を取ってきたら、次のステップは[そのテキストを実際に欲しいデータに整形すること](/docs/jp/academy/refining-data-with-regex)です。