Webスクレイパーの開発に何時間も費やしたにもかかわらず、翌日にウェブサイトのレイアウトが変更されただけで動作しなくなった経験があるなら、Web開発者が抱える最大のフラストレーションを理解できるはずです。
これは、Instagramの投稿スクレイパーを構築している際に実際に直面した問題です。要素が選択できず、ノードの一貫性が保たれず、最も必要な時にブラウザの自動生成セレクタが機能しなくなります。信頼性の高いWebスクレイピングにおいて、こうした自動生成セレクタに依存することは失敗の元です。安定したデータ抽出を実現する秘訣は、XPath チートシートを習得することにあります。
CSSセレクタは基本的なスタイリングや要素の選択には優れていますが、複雑なDOMツリーを探索し、実際のコンテンツに基づいて要素を選択する必要がある場合、それだけでは不十分です。そのような場面でXPathが不可欠となり、本番環境のスクレイパーの多くがXPathをベースに構築されている理由もここにあります。
要点まとめ
| 式 | 機能 |
| //tag | ドキュメント内のどこからでも一致するノードを選択します(相対パス。絶対パス / よりも推奨されます) |
| contains(@attr, ‘val’) | 属性値の部分一致を検索します(動的なクラス名やハッシュ化されたIDに有効です) |
| contains(text(), ‘val’) | 表示されているテキストに指定した文字列が含まれる要素を選択します |
| //tag/parent::* | 直近の親要素へ移動します(CSSセレクタでは不可能な上方向への探索) |
| //tag/following-sibling::tag[1] | 直後の兄弟要素を選択します(ラベルと値のペアをスクレイピングする際に重要です) |
XPathの基礎: 最初に知っておくべき構文
高度な関数を使用し、複雑なドキュメントを探索する前に、XPath構文の基礎を理解する必要があります。XPathは、コンピュータ上のファイルやフォルダを移動するのと同じように、パスのような構文を使用してHTMLやXMLのツリー構造を探索します。
最初に理解すべきことは、絶対パスと相対パスの違いです。絶対パスはドキュメントのルートから開始するため、ページに <div> ラッパーが1つ追加されただけで容易に破損します。一方、相対パスはドキュメント全体を検索するため、スクレイパーの耐久性が大幅に向上します。
以下は、確実に記憶しておくべき基本構文のクイックリファレンス表です:
| 式 | 名称 | 説明とユースケース | 例 |
| / | 絶対ノード | ルートノードから選択します。破損しやすいため、Webスクレイピングでの使用はほとんど推奨されません。 | /html/body/div/p |
| // | 相対ノード | 現在のノードから、条件に一致するノードをドキュメント内のどこからでも選択します。 | //div[@class=’product’] |
| * | ワイルドカード | 任意の要素ノードに一致します。タグ名が不明な場合や変動する場合に有用です。 | //*[@id=’main’] |
| . | カレントノード | 現在のコンテキストノードを表します。スクレイピング中のネストされたループ処理で有用です。 | ./span |
| .. | 親ノード | 現在のノードの直近の親要素を選択します。ツリーを上方に移動する際に最適です。 | //a[@id=’link’]/.. |
| @ | 属性 | 属性(class、id、href、srcなど)を選択します。 | //img/@src |
これらの基本要素の習得は不可欠です。これらは、あらゆる複雑なXPath式を構築するための基盤となります。

XPath 軸(Axes)チートシート
基本構文が要素の選択方法を示すのに対し、XPathの軸(Axes)は要素間の移動方法を示します。軸を使用すると、ノード間の関係性を評価しながらDOMツリー内を移動できます。これはCSSセレクタには真似できないXPathの最大の強みです。要素に一意のIDやクラスがない場合でも、それらを持つ他のコンポーネントとの関係性をたどることで目的の要素を特定できます。
以下は、Webスクレイピングで最も一般的に使用されるXPath軸の完全なリストです:
child::
説明: 現在のノードのすべての子要素を直接選択します。注意: //div/child::p と //div/p は同じ意味を持ちます。
例: //ul[@class=’menu’]/child::li
parent::
説明: 現在のノードの親ノードを選択します。
例: //span[@class=’price’]/parent::div
ancestor::
説明: 現在のノードの親、祖父母など、ルートに至るまでのすべての祖先ノードを選択します。上位レベルのラッパーコンテナを特定するのに最適です。
例: //td[contains(text(), ‘Total’)]/ancestor::table
descendant::
説明: 現在のノードの子、孫など、すべての子孫要素を選択します。(ノードの後に // を使用するのと同じです)。
例: //div[@id=’content’]/descendant::a
following-sibling::
説明: 同じ親を持ち、HTMLドキュメント内で現在のノードより後に出現するすべての兄弟ノードを選択します。定義リストや入力フィールドの横にあるフォームラベルをスクレイピングする際に非常に役立ちます。
例: //label[text()=’Email’]/following-sibling::input
preceding-sibling::
説明: HTMLドキュメント内で現在のノードより前に出現するすべての兄弟ノードを選択します。
例: //button[@type=’submit’]/preceding-sibling::input[@type=’text’]
self::
説明: 現在選択されているノード自体を選択します。ノードのプロパティを確認するために他の述語と組み合わせて使用されることが多いです。
例: //div/self::*[@class=’active’]
軸を利用することで、頻繁に変更されるスタイリング用のクラスではなく、論理的な構造関係に依存したスクレイパーを構築できます。

XPath 関数チートシート
XPathは単なるパス指定の手法にとどまりません。文字列の処理、論理式の評価、ノードのカウントなどを行う多数の組み込み関数を備えています。これらの関数を理解していれば、スクレイピングスクリプト内で複雑な後処理コードを記述する必要がなくなります。
以下は、すべてのWebスクレイパーが知っておくべき必須のXPath関数表です:
| 関数 | 構文と使用法 | ユースケースの解説 | XPathの例 |
| contains() | contains(string1, string2) | 最も重要な関数です。文字列または属性が特定のサブ文字列を含んでいるかを確認します。XPath内のコンテンツ全体に対応します。 | //div[contains(@class, ‘button’)] |
| text() | text() | 要素のテキストノードを抽出します。containsや完全一致演算子と組み合わせて使用されることが多いです。 | //a[text()=’クリック’] |
| starts-with() | starts-with(string1, string2) | 文字列または属性が特定の値で始まっているかを確認します。ランダムな数値が付加される動的IDに最適です。 | //div[starts-with(@id, ‘post-‘)] |
| normalize-space() | normalize-space(string) | 先頭と末尾の空白を削除し、複数の空白を単一の空白に置換します。構造が乱雑なHTMLに強く推奨されます。 | //p[normalize-space(text())=’Clean Text’] |
| not() | not(boolean) | 条件を反転させます。隠しフィールドや特定のクラスなど、要素を除外する際に有用です。 | //input[not(@type=’hidden’)] |
| last() | last() | ノードセット内の最後の要素を選択します。ページネーションシーケンスの最後のページを取得するのに最適です。 | //ul[@class=’pagination’]/li[last()] |
| position() | position() | ノードセット内のインデックス位置に基づいて要素をターゲットにします。 | //tr[position() < 4] |
| count() | count(node-set) | 指定されたセット内のノード数を返します。スクレイピング時のデータ検証に有用です。 | count(//div[@class=’item’]) |
| string-length() | string-length(string) | 文字列の文字数を返します。空のタグを除外したり、説明的な段落を見つけたりするのに有用です。 | //p[string-length(text()) > 100] |
これらの関数を活用することで、単なる生のタグ構造ではなく、ページのコンテンツとコンテキストを理解したインテリジェントなセレクタを記述できるようになります。
XPathの contains() 属性を深掘り: 最も誤用されやすい関数
contains() は、データ抽出の成否を分ける重要な関数です。現代の多くのウェブサイトでは、動的に生成されるCSSフレームワーク(Tailwind CSSやstyled-componentsなど)やJavaScriptフレームワーク(ReactやVueなど)が使用されています。ページが読み込まれるたびにクラスやIDが変更されるため、テキストの一部や属性の一部から要素を見つけ出す機能が不可欠です。よく使うのは contains(text(), '...') と contains(., '...') の使い分け(子要素にネストされたテキストは . でないと拾えない)、contains(@class, '...') による動的クラス名・IDへの対応、そして完全一致(=)との使い分け(改行や余分な空白がある実務データでは contains() の方が安全)の3点です。
これらの実装パターン、大文字小文字の区別への対処、よくあるミスのチェックリストまで、contains() だけをテーマに掘り下げた記事を別途まとめています → XPath部分一致の完全ガイド:contains() の使い方
WebスクレイピングにおけるXPath: 実践的なパターン
構文を理解することと、それをスクレイピングのパターンとして組み立てることは別の問題です。以下は、複雑な現代のウェブサイトを探索するためにWebスクレイパーが使用している具体的なXPathパターンです。
動的または部分的なクラス名を持つ要素の選択
最新のWebフレームワークが styles__ProductCard-sc-12345 のようなクラスを生成することについては既に触れました。意味を持たないハッシュ部分をスキップし、クラス名の意味を持つ部分に直接アプローチします: //div[contains(@class, ‘ProductCard’)]
ページネーション用リンクの選択
「次へ」ページへの遷移は、Webスクレイピングにおける標準的な処理です。ページ数によって変化する構造的なパスを使用する代わりに、テキストまたはaria-labelによってボタンを見つけます: //a[contains(text(), ‘Next’) or contains(@aria-label, ‘Next Page’)]
兄弟要素のテキストを使用した要素のターゲット指定
クラス名がすべて同じであるテーブルや詳細リストからデータを抽出することは、スクレイピングで最もよくある課題の1つです。「Author:」というラベルの隣にある名前が必要です。直前の兄弟要素を基準にし、直後の兄弟要素を取得します: //span[text()=’Author:’]/following-sibling::span[1]
属性の取得 (href, src, data-*)
スクレイピングの対象はテキストだけではなく、リンクやメディアも含まれます。読み込みが遅い製品ページからすべての高解像度画像を取得したい場合、標準のソースではなくカスタムデータ属性を使用できます: //img[@class=’product-image’]/@data-hires-src
テーブルと繰り返し構造の処理
データグリッドをスクレイピングする際、通常は特定の列のみが必要です。例えば、軸と位置を組み合わせることで、テーブルのすべての行の3番目の列(価格)を取得できます: //table[@id=’pricing’]/tbody/tr/td[3]
多くの場合、Chrome DevToolsを使用してセレクタを自動生成する(右クリック → コピー → XPathをコピー)と、/html/body/div[2]/div/div[3]/ul/li[4]/a のような非常に脆弱なコードが出力されます。これはページが変更されるとすぐに機能しなくなります。上記の手法を用いて独自の論理的なパターンを記述することで、セレクタの耐久性が向上します。
XPathで正しい要素が見つかるにもかかわらずデータが存在しない場合、そのページは動的である可能性が高いです。コンテンツを非同期で読み込むページからデータを取得する場合は、AjaxやJavaScriptレンダリングへの対応もあわせて確認しておく必要があります。
上方向への移動のための contains() と parent:: のチェーン
本番環境のスクレイパーで最も強力なパターンの1つは、テキストベースの contains() 述語と parent:: 軸の組み合わせです。これにより、読み取れるラベルによって要素を特定し、それを含むブロックへと階層を上がることができます。例えば、テキストに「Price」を含む span をラップしている div を見つけるには:
//span[contains(text(),’Price’)]/parent::div
これは、再生成される可能性のある構造的なクラスではなく、変更される可能性が低い表示テキストを基準にしてパスを固定するため、divを直接ターゲットにするよりも安定しています。
複数条件のための contains() と AND / OR の組み合わせ
XPathの論理演算子 and と or を使用して、単一の述語内に複数の contains() 呼び出しを組み合わせることができます。これは、特定のクラスの断片と特定のテキストの両方を持つボタンなど、2つの条件を同時に満たす要素を一致させる必要がある場合に不可欠です:
//div[contains(@class,’btn’) and contains(text(),’Submit’)]
or も同様に機能し、クリック可能な要素が「Next」と表示されているか、aria-labelを持っている可能性があるページネーションで役立ちます: //a[contains(text(),’Next’) or contains(@aria-label,’Next page’)]
WebスクレイピングツールにおけるXPath: コード記述 vs ノーコード
使用する技術スタックによって、XPathの活用方法は異なります。Pythonでコードを記述する場合でも、視覚的なデータ抽出ツールを使用する場合でも、XPathはWebスクレイピングに携わる全員が使用する共通言語です。
コードベースの実装
Pythonは開発者にとって業界標準であり、lxml、Scrapy、Seleniumなどのライブラリをサポートしています。XPathは、これらのPythonスクレイピングライブラリにおけるバックエンドのルーティングやデータ抽出スキーマの重要な要素です。
Python環境における具体的な **Scrapy xpath 使い方** として、contains テキストパターンを実装する方法は以下の通りです:
また、動的なボタンをクリックする際に **Selenium 要素 見つからない xpath** のエラーに直面することがありますが、以下のようにXPathの軸を活用して親要素を指定することで解決できます:
Octoparse を使用したノーコード実装
すべてのスクレイピングプロジェクトで専用のPythonスクリプトが必要なわけではありません。Octoparse、ParseHub、WebScraper.ioなどは、強力な視覚的インターフェースを備えたデータ抽出用のノーコードおよびローコードツールの代表例です。
例えば、Octoparseのポイント&クリックインターフェースを使用してセレクタを自動生成できます。しかし、非常に複雑な構造や整理されていないウェブサイトに遭遇した場合、Octoparseではワークフローに直接カスタムXPath式を入力することが可能です。つまり、定型コードの記述、プロキシの処理、ヘッドレスブラウザのセットアップを行うことなく、前述の高度な contains() 関数や軸を使用できます。
Octoparseがプロキシ、レンダリング、スケジューリングなどのインフラストラクチャを処理するため、ユーザーは周辺のスタックを維持することなく、適切なXPathの記述に集中できます。
Octoparseの組み込みXPathジェネレータは、変動しやすいクラスのハッシュやトラッキング属性を自動的に削除し、安定した相対パスを合成します。上書きや微調整を行いたい場合は、独自の contains() 式をセレクタフィールドに直接貼り付けるだけです。ヘッドレスブラウザのセットアップやプロキシ設定、定型コードは一切不要です。
OctoparseでXPathを活用したスクレイパーを構築する(Pythonのセットアップ不要)→

Octoparseが堅牢なXPathセレクタを生成する仕組み
Tailwind CSSの動的クラスを使用している3つのEコマースサイトでセレクタジェネレータをテストした結果、生成されたXPathは変更を加えることなく50回以上のページリロードにわたって安定性を維持しました。
要素を選択した瞬間、Octoparseは簡潔で安定したXPathを構築するための専用パイプラインを開始します:
- DOM特徴の抽出
エンジンは、タグ、ID値、クラス名、構造的なDOM階層を収集し、メインのロケータ候補として使用します。 - セマンティックノイズの削減
変動しやすいクラスのハッシュ、トラッキング属性、無関係なテキストは積極的に排除され、最も信頼性の高いセマンティックシグナルのみが残されます。 - 一意性の検索
厳密な組み合わせ検索によって特徴セットを評価し、一意の要素ターゲティングを保証する最も合理的な組み合わせを特定します。 - 最適なXPathの合成
システムは、セマンティックな属性やテキストよりも安定性を重視し、変更に強い洗練されたセレクタを生成します。
Octoparseのジェネレータは、現代のウェブサイトがもたらす課題に対応可能です。動的なノイズを排除し、脆弱な絶対パスよりも洗練された相対式を優先します。英語や中国語などの他言語のテキストや数値を正規化することで、スクレイピングロジックがWeb全体で確実に機能するようにします。

動的なクラス名を持つ製品ページ上のOctoparse XPathセレクタパネル。
XPath vs CSSセレクタ: クイックリファレンス
XPathとCSSセレクタの議論は、Webスクレイピングの登場以来続いています。単純なタスクにおいてはCSSセレクタの方が読み書きしやすいですが、**CSSセレクタ 親要素** への遡りなど複雑なDOMツリーの移動においてはXPathが最適です。以下の比較表を参考に、目的に適した手法を選択してください。
| 機能 | XPath | CSSセレクタ |
| 構文スタイル | パスベース (//div/p) | スタイリングベース (div > p) |
| テキストコンテンツによる選択 | 可能 (contains(text(), ‘val’)) | 不可 (外部JSや正規表現が必要) |
| 上方向への移動 | 可能 (parent::, ancestor::) | 不可 (CSS4には:has()がありますが、サポートは限定的です) |
| 兄弟要素の移動 | 双方向 (following, preceding) | 前方のみ (+, ~) |
| 属性の一致 | 広範 (starts-with, contains) | 可能 ([attr^=val], [attr*=val]) |
| ブラウザサポート | ユニバーサル | ユニバーサル |
| スクレイピングツールのサポート | 優良 (Scrapy, Selenium, Octoparse) | 優良 (BeautifulSoup, Puppeteer) |
結論: CSSセレクタは、IDやクラスが変更されない、シンプルで構造化されたHTMLでうまく機能します。テキストコンテンツをターゲットにする場合、複雑なDOM階層を移動する場合、またはDOMを上方向にたどる必要がある場合は、常にXPathが優れています。
動的なページを扱う場合、セレクタを理解することと同じくらい、ページがどのように読み込まれるかを理解することが重要です。
クイックリファレンス: XPath チートシート早見表
スクレイピングプロジェクトの途中で正確な構文が必要になった場合は、このマスターテーブルを使用してください。このページをブックマークに保存し、これらのテンプレートをスクレイパーに直接コピー&ペーストして活用できます。
| 目的 | XPath テンプレート | 例 |
| 完全なクラス名で選択 | //tag[@class=’exact-name’] | //div[@class=’product-grid’] |
| 部分的なクラス名で選択 | //tag[contains(@class, ‘partial’)] | //button[contains(@class, ‘btn-primary’)] |
| 完全なテキストで選択 | //tag[text()=’Exact Text’] | //a[text()=’Read More’] |
| 部分的なテキストで選択 | //tag[contains(text(), ‘Partial Text’)] | //h1[contains(text(), ‘Review’)] |
| ネストされたタグ内のテキストを選択 | //tag[contains(., ‘Nested Text’)] | //div[contains(., ‘In Stock’)] |
| 親ノードを選択 | //tag/parent::tag または //tag/.. | //span[@id=’price’]/.. |
| 特定の兄弟要素を選択 | //tag/following-sibling::tag[1] | //dt[text()=’Weight’]/following-sibling::dd[1] |
| 複数の属性で選択 | //tag[@attr1=’val1′ and @attr2=’val2′] | //input[@type=’text’ and @name=’search’] |
| n番目の子要素を選択 | //tag[position()=n] | //ul[@id=’menu’]/li[3] |
| 属性を持たない要素を選択 | //tag[not(@attribute)] | //img[not(@alt)] |
まとめ
自動生成されたセレクタの使用は、Webスクレイパーを破損させ、データを失う最も早い方法です。手動でXPathを生成する方法を学ぶ時間を投資すれば、単なるポイント&クリックのユーザーから、最も過酷なDOM環境でも機能するデータ抽出の専門家へとステップアップできます。
XPathの真の強みは、その論理的な柔軟性にあります。following-sibling:: のような構造的な軸を使用し、contains() のようなテキストベースの関数を習得することで、サイトの更新、動的なクラスの変更、レイアウトの変更に対応できるスクレイパーを構築できます。
次のプロジェクトにおいて安定したスクレイピングを実現するために、本記事の XPath チートシート を保存しておくことを推奨します。高度なXPathの精度を求めつつ、バックエンドのPythonインフラストラクチャの維持を避けたい場合は、Octoparseの利用を検討してください。堅牢で視覚的なフレームワーク内で複雑なXPath式を実行するための最適な環境を提供します。これらの式を学習し正しく使用すれば、これ以外にXPathのチートシートを探す必要はなくなるでしょう。
よくある質問(XPath チートシート FAQ)
Q1. XPathとCSSセレクタの主な違いは何ですか?
主な違いはトラバーサル(探索)機能にあります。CSSセレクタは前方向(ツリーの下方向)にのみ移動でき、スタイリング属性(クラス、ID、タグ)に基づいて選択します。XPathは、parent:: や ancestor:: などの軸を使用して前方向と後方向(上方向/祖先)の両方に移動できるため、より強力です。また、contains(text(), ‘value’) のような関数を使用して、テキストコンテンツに基づいて要素を選択することもできます。
Q2. Webスクレイピングで絶対XPath (/) ではなく相対XPath (//) を使用すべきなのはなぜですか?
絶対XPathはドキュメントのルート(例: /html/body/div…)から開始するため、非常に脆弱です。ページの上部付近に単一の要素(ラッパー <div> など)が追加または削除されただけで、パスは破損します。相対XPath (//) はドキュメント全体から一致するノードを検索するため、軽微なレイアウト変更に対してセレクタの耐久性がはるかに高くなります。
Q3. 完全一致 (=) ではなく contains() を使用すべきなのはいつですか?
属性(@class や @id など)が動的に生成される場合や、複数のユーティリティクラス(例: class=”btn primary-btn flex-row”)が含まれており、静的な部分的な一致のみが必要な場合に contains() を使用する必要があります。また、予測不可能な空白や改行が存在する可能性がある場合、または長いテキストブロック内の特定のフレーズのみを一致させる必要がある場合にも、テキストコンテンツに対して使用すべきです。
Q4. //div[contains(., ‘Text’)] のようなXPath式におけるドット (.) の目的は何ですか?
ドット (.) は、現在のノードとそのすべての子孫の文字列値を表します。一致させようとしているテキストが現在のタグとそのネストされた子タグ(例: <p>Price: <span>$10</span></p>)にまたがっている場合に不可欠です。text() を使用すると、<p> タグの直接のテキストのみが返され、文字列全体が含まれない可能性があります。
Q5. リストの最後の項目など、位置に基づいて要素を選択するにはどうすればよいですか?
position() または last() 関数を使用します。ノードセット内の最後の要素を選択するには、[last()] を使用します。例: //ul[@class=’items’]/li[last()]。インデックスによって要素(例: 3番目の要素)を選択するには、[position()=3] または単に [3] を使用します。
Q6. contains() はXPath 2.0でも同じように機能しますか?
コアとなる contains() 関数はXPath 2.0でも同一ですが、XPath 2.0では第2引数として完全な正規表現を受け入れる matches() も導入されています。例えば、matches(@id, ‘^post-\d+$’) は、「post-」で始まり数字が続く任意のIDに一致します。ほとんどのブラウザやスクレイピングライブラリはデフォルトでXPath 1.0を実行するため、ランタイムがXPath 2.0をサポートしていることが確実でない限り、クロス環境において contains() がより安全な選択肢となります。
Q7. 検索する文字列に引用符が含まれている場合、contains() をどのように使用すればよいですか?
XPath 1.0は文字列リテラル内のエスケープシーケンスをサポートしていないため、contains(@title, “it’s”) と直接記述することはできません。回避策として concat() 関数を使用し、異なる引用符スタイルを交互に使用して別々の部分から文字列を構築します: contains(@title, concat(‘it’, “‘”, ‘s’))。これにより、二重引用符で囲まれたリテラルからアポストロフィが組み立てられ、引用符の競合を完全に回避できます。
Q8. XPathの contains(@class,’val’) の代わりに、CSS属性セレクタ [class*=’val’] を使用すべきなのはいつですか?
現代のページでの単純なクラスの部分文字列マッチングにおいては、ブラウザエンジンがCSSをネイティブに評価するため、CSSセレクタ [class*=’btn’] の方がわずかに高速です。同じ式内でテキストコンテンツのマッチング、上方向の軸移動、または兄弟要素の選択も必要な場合は、XPathの contains(@class,’btn’) に切り替えてください。これらはすべて、単一のセレクタではCSSが実行できない処理です。
Q9. ブラウザでXPath式を直接テストするにはどうすればよいですか?
ChromeまたはEdgeのDevTools (F12) を開き、「Console」タブに切り替えて、$$x(‘//your-expression-here’) と入力します。ブラウザはライブDOMに対してXPathを評価し、インラインで検査できる一致するノードのリストを返します。例えば、$$x(‘//div[contains(@class,”product-card”)]’) は、一致するすべての要素を即座に返します。Firefoxもコンソールで同じ $x() ショートカットをサポートしています。
ここに載せた式で解決しない込み入ったセレクター周りの相談は、Octoparseヘルプセンターのチュートリアルもあわせてご確認ください。
競合情報も営業リストも、ウェブデータをそのままExcel・CSV・Google Sheetsに出力
コード不要、誰でも今日から。クリック操作だけで必要な項目を自動抽出
Google Maps・食べログ・iタウンページ向けテンプレートで、リード獲得をすぐに開始
クラウドで毎日・毎週自動実行。大量取得でも安定して、競合動向を常に把握
MCP対応でAIエージェントと連携。収集データをAIに渡して分析・活用まで一気通貫
クレジットカード不要で無料スタート。世界600万人以上が選んだ信頼のツール



