DEIM Forum 2016 F1-5

Web データ抽出システム Ducky におけるブラウザ GUI と抽出ルール生成・自動更新機構の構築
金岡慧†

遠山元道 ††† †† 慶應義塾大学理工学研究科開放環境科学専攻〒 223-8522 神奈川県横浜市港北区日吉 3-14-1
E-mail: †kei@db.ics.keio.ac.jp, ††toyama@ics.keio.ac.jp
あらまし Web は巨大な情報資源であり, これらのデータを 2 次利用のために得たいというニーズがある. しかしその場合, 手作業で書き出すかスクレイピングプログラムを記述するなど, ユーザにとって負荷であったり, 高度な知識が要求される. これらの問題を解決するべく, 著者らは Ducky を構築した. Ducky は対象となる Web ページの URL や

CSS セレクタから成る独自のデータ抽出ルールに基づいてデータ抽出を行うシステムである. その独自のデータ抽出
ルールの文法により, 抽出されるデータのノイズ除去や, 複数ページにまたがる大型サイトからのデータ抽出・統合なども可能なことが特徴である. Ducky ではブラウザ GUI によってユーザが直感的に目的の要素を選択することができる. ブラウザ GUI 上でユーザが選択した要素はデータ抽出ルールに変換され, システムに登録される. また Web ページのレイアウトや構造が変化した場合, データ抽出ルールを再定義することで, ユーザの管理の負荷を軽減することが
できる.
キーワード

Web 情報システム, Web スクレイピング, データ統合

1. は じ め には行われてきた. それらは Web ページを入力とし, ページレイアウトを解析し, ページ内における抽出したい情報の位置の把Web 上には膨大な量のデータが存在し, これらを 2 次利用の

握, すなわち抽出ルールの導出を自動で行う必要がある. そのために得たいというニーズがある. その場合, 手作業で書き出際, 事前に教師データとしてユーザにトレーニングサンプルをすかスクレイピングプログラムを記述する方法が考えられる.

入力されるものも提案されてきた. Web ラッパーの自動生成,

前者の手動での記述の場合, 手間と時間のコストが大きくなり,

半自動生成とでは, 抽出されるデータの精度とユーザに対する誤りが生じる危険性もある. 一方後者のスクレイピングプログ

負荷といった点で, トレードオフが生じる.

ラムを記述する方法は, 知識のないユーザにとっては敷居の高

これらの問題に対し, 著者らは半自動の Web ラッパーを含む,

い方法となってしまう. そのため, それらのデータを得るため

Web ページからの情報抽出・管理を可能とする Ducky [8] [9] シに Web ページやサイトを機械的に処理する様々な手法がこれステムの提案, 開発を行っている. Ducky は様々な構造の Webまでに提案されてきた. このように Web を巨大な知識ベース

ページ, 複数のページから成る大型 Web サイトを対象にデータと捉え, Web から有用な知識を取り出す情報抽出技術の研究はを抽出・統合することができるシステムである. ユーザはシス

現在までに数多く行われてきた [13].

テムのブラウザ GUI を通し, 普段のブラウジングのような動作研究として問題となるのは, Web ページやサイトはそれぞれで直感的に目的の要素を選択できることができる. 選択されたHTML の構造が異なる点である. それらはその作成者によっ

データはデータ抽出ルールに変換され, システムに登録される.

て人が認識・理解しやすい形でデザインされ, ブラウザ上に描

また本論文で新たに提案する, データ抽出ルール自動更新機構画され, 利用されるということが前提になっている. この問題

により, Web ページへの変化への追従を試みる. これらの機構に対し, 著者らは HTML 文書からデータを抽出し, 構造化するにより, ユーザのデータ抽出・管理の負荷を軽減する.

Web ラッパーに注目した. Web ラッパーとは, Web ページか

本論文の構成は以下の通りである. まず, 2. 章で Ducky シス

ら特定の情報を抽出する抽出ルールおよび抽出プログラムのこ

テムの概要を説明する. 3. 章でブラウザ GUI と抽出ルール生とである. Web ラッパーはその抽出ルールによって HTML 文成機構, 4. 章でデータ抽出ルール自動更新機構について説明し,書から特定の情報の位置を把握し, 抽出を行うことで, 構造を再5. 章で評価を行う. 6. 章で関連研究について述べ, 7. 章でまと

構成する.

めを行う.

Web ラッパーは自動生成, 半自動生成など, 自動のレベルの異なるものがこれまでに提案されてきた. 膨大な量の Web ペー
ジやサイト群に対し, Web ラッパーを半自動で生成することは現実的でないという観点から, Web ラッパーの自動生成の研究

前よりも複雑化しており, この傾向は一般的に見受けられる. 特

2. システム概要に近年では, Web デザイナーは DB から引き出したデータそれ

2. 1 システム全体像

ぞれに対して HTML タグの id 属性や class 属性を付与し, 特Ducky の全体像を図 1 に示す. ユーザは今回新たに構築し定の意味を持たせる傾向にある. 例えば同じカテゴリに属するたシステムのブラウザ GUI を通して, データ抽出を行う Web

データは同じ class 属性が付与されるというようなものである.

ページを表示し, 目的の要素をマウスオーバーで選択すること

このため, そのようなデータは同じセレクタで指定することがができる. Web ページの URL や, 目的の要素の位置情報などできる. 先の例に挙げた映画.com においても, 映画のタイトル

は全てデータ抽出ルールに変換され, 格納される. そのフォーを内包する div タグには unit というクラス属性が付与されてマットを図 2 に示す. 目的の要素の位置情報は, CSS セレク

いるといったことが見受けられる. またフォント, 色, 視覚的パタ (2. 2. 1) で表される. 抽出されるデータの形式は, xml, json,

ターンといったスタイルの指定は CSS セレクタを用いて CSS

csv から選択する. またデータ抽出を行う頻度を設定し, 抽出において定義され, ユーザがブラウジングしやすいように Web

データを自動でアップデートすることができる. これらの情報ページやサイトはデザインされる.
また近年, Web 開発者はソースコードの簡潔さや可読性向上

もデータ抽出ルールに格納される.

のため, しばしば JavaScript ライブラリを用いる. 中でも最も有名なものはドキュメントオブジェクトモデル (DOM) 操作ができる jQuery である. W3Techs（注 2） によると, 2015 年 8 月時
点で jQuery を利用している Web サイトは全体の 65.5 ％と示されている. jQuery では要素の指定に CSS セレクタを用いることから, 多くの Web 開発者は CSS セレクタに精通している
と言える.

図1

システム全体像{"name" : "",\\名前"author" : "",\\作成者"frequency" : "",\\抽出頻度"format" : "",\\出力の形式"scraping" : [{…}]\\データ抽出}

図 3 HTML 構造

2. 2. 2 データ抽出ルール
データ抽出に関する設定は, データ抽出ルールの scraping
フィールドに定義される. そのフォーマットと定義されるフィー

ルドを図 4 と表 1 に示す. ブラウザ GUI を通してユーザによっ

図 2 データ抽出ルール フォーマット

て選択された Web ページ上の目的の要素の位置情報は, CSS
セレクタとして selector フィールドに格納される. scraping

2. 2 データ抽出

フィールドで記述されたパラメータを元に, データ抽出部にお2. 2. 1 CSS セレクタ

いてデータの抽出を行う. 処理の流れは次のようになる.

CSS セレクタは Xpath のように, マークアップ言語である
HTML 文書の特定の部分を指定することができる言語構文で（ 1 ） “url”, “selector”の処理ある. たとえば図 3 の映画.com（注 1） を例にとると, 今回得たい指定された URL にリクエストを送り, HTML 文書を取得.

データが映画のタイトルやその公式 HP の URL である場合,指定された CSS セレクタを用いて取得した HTML 文書をパー

それらは HTML の構造から全て同じ CSS セレクタ, “div.unit

ス. CSS セレクタで指定された要素を取得.

li > a”で指定することが出来る. このように CSS セレクタはHTML 要素をそれらの id 属性, class 属性, その他の属性など（ 2 ） “data”の処理を用いて表すことができ, その記法はシンプルでわかりやすい抽出した要素のテキストノードを抽出. “field”で抽出されたといった特徴が挙げられる. Ducky において CSS セレクタをデータの項目名を定義. “attr”, “find”が記述されている場合,

用いる理由として, 以下に 2 つの背景を挙げる.

CSS の発展によって Web ページやサイトのレイアウトは以（注 2）：Web 上で使われているテクノロジーのシェアや種類を調査・報告を行っている.

（注 1）：http://eiga.com/link/

http://w3techs.com/

表 1 フィールド一覧
フィールド名型

概要

scrapingarray

データを抽出するのに必要な以下のフィールドを定義

url

string

起点となる URL を定義

selector

string

現在のページから抽出したい要素の CSS セレクタを定義

data

array

抽出されるデータをどのようなオプション (以下) で抽出するかを定義

field

string

抽出データの項目名を定義

attr

stringselector で指定したタグの属性を指定

find

stringselector で抽出したタグの子要素を CSS セレクタで指定“blank”

空白削除“parentheses”

括弧と括弧内の文字列の削除

removearray

replacearray

抽出されたデータの文字列置換

next

object起点のページからの遷移がある場合に使用記述された正規表現, 文字列を削除

stringル化され (2. 2. 2) , システムに登録される.
"scraping" : [{以下, ブラウザ GUI の外部仕様と内部仕様を, Ameba 芸能"url" : "…",

人・有名人ブログ（注 3） における具体的なデータ抽出例を用いて"selector" : "…",

説明する (図 5) . 50 音順のリンクがリストアップされたペー"data" : [{ジ（注 4） をスタートとし, 遷移先のページには芸能人・有名人の"field" : "…",

ブログへのリンクが更にリストアップされている. このサイト"attr" : "…",

から芸能人の名前とそのブログのページへの URL を抽出対象"find" : "…",とし, それぞれ “name”, “url”という項目名を付与するとする.

"remove" : ["…", "…", …],

最終的に生成されるデータ抽出ルールは図 6 に示す.

"replace" : [["…", "…"], …]

}],

3. 1 外 部 仕 様"next" : {…}3. 1. 1 要素の選択
ユーザはまずスタートのページの URL を GUI に与える. 表}]

示されたページ上で任意の要素へマウスオーバーすると, シア
図4

データ抽出に関するルール定義

ンの色で色付けられる. 今回の場合, 50 音順のリンクへマウス
オーバーすると, それらが色付けられる. これらのリンクは全抽出した要素の属性もしくは子要素のテキストノードを取得.

て同様のスタイルが適用されており, 同様の CSS セレクタで指“remove”や “replace”が記述されている場合, 取得したデータ定することができることから, ユーザへの視覚的フィードバッ

に対して指定の処理を行う.

クとしてこのように返される. クリックの動作によって, マウ（ 3 ） “next”フィールドの有無“next”フィールドが記述されている場合, 取得した URL を“url”フィールドの値として処理 (1) に戻る. 記述されていない
場合, 取得したデータを DB へ渡す. “next”フィールドは同一
テンプレートで生成されている遷移先 Web ページ群に対し, それぞれへリクエストを送り, 情報抽出・統合を行う. (3. 2. 3 参
照)スオーバーの要素を指定することができる.

3. 1. 2 抽出対象要素をポップアップから選択
クリックでの要素の指定の後, 指定の要素がテキストノード
以外にも情報を保持していた場合, それらはポップアップ上に表示される (図 5 右図) . 得たい項目にはチェックボックスに印を付けることで, 抽出対象として選択することができる.

3. 1. 3 ページ遷移

3. ブラウザ GUI
ブラウザ GUI を用いることで, ユーザはデータ抽出を直感的に行うことが出来る. ユーザがシステムに目的の Web ページの URL を入力すると, システムはその URL へリクエストを送り, HTML 文書を受け取る. そしてそのページが GUI に表示される. ユーザは目的のデータをマウスオーバーやクリックといった普段のブラウジングと同じ動作で選択することができる.
ユーザがブラウザ GUI 上で行った動作は全てデータ抽出ルー指定された要素に URL が含まれていた場合, ツールバー上の矢印ボタンをクリックすることでページ遷移が可能となる (図5 中央の図).
3. 2 内 部 仕 様
3. 2. 1 CSS セレクタの生成システムは GUI 上でのユーザのマウスオーバーの動作を監（注 3）：http://oﬃcial.ameba.jp/（注 4）：http://oﬃcial.ameba.jp/genrekana/kanatop.html

図5ブラウザ GUI を用いたデータ抽出例

生成された CSS セレクタで指定することができる全てのノードは, ユーザへのフィードバックとしてシアンの色で色付ける.
ユーザのクリックの動作によって, ノードの指定がなされる. 今回の例において, 50 音順のリンクをユーザがクリックすることによって生成された CSS セレクタは, 図 6 の “div.syllabaryMdl> table > tbody > tr > td > a”のようになる (一部抜粋) .
3. 2. 2 メタ情報・周辺要素の可視化
ユーザが指定した要素のテキストノードが抽出対象となるが,alt 属性などのメタ情報が存在した場合, それらもポップアッ
プで表示される仕様となっている (図 5 右) . また近年の Web
図 6 Ameba 芸能人・有名人ブログからのデータ抽出ルール

ページでは画像は画像でも, リンク付きの画像であることも多い. その HTML 構造は図 7 のように, a タグが img タグを内視し, マウスオーバーされているノードの CSS セレクタを生成する (Algorithm1). CSS セレクタは現在マウスオーバーされているノードから, body ノードまでさかのぼって生成される.
この際, それぞれのノードの class 属性も同時に取得する.

包する形となっている. そのような要素をユーザがクリックした場合, 親ノードである a タグの属性も抽出対象として含み,
ポップアップに表示する. つまり図 5 において田中将大の画像がユーザによってクリックされた場合, その HTML 構造は図 7のようになっているため, img タグがもつ src 属性と alt 属性のAlgorithm 1 Pseudocode of generating CSS selector
Declare CSS selector called C
Require: node
Ensure: C of node
T N ⇐ tagN ame of node

値, 親ノードである a タグの href 属性の値がポップアップに表示される.
ユーザがポップアップのチェックボックスで選択したものは,抽出対象として後にデータ抽出ルールに変換される.

CN ⇐ classN ame of node
while TN is not “Body” do
if CN is not null thenC+ = T N + “.” + CN
else
C+ = T N
end ifnode ⇐ parentN ode of nodeend while

図 7 リンク付き画像の HTML 構造例

データ抽出を行うことができなくなる.

3. 2. 3 ページ遷移
ツールバー上の矢印ボタンがユーザによってクリックされた
場合, 選択されている要素の href 属性の値を取得し, そのリン
ク先へページ遷移を行う. これはデータ抽出ルールにおいて,“next”フィールドを用いて表現される (図 6) . 図 6 において,3 行目に存在する “selector”フィールドの値 “div.syllabaryMdl> table > tbody > tr > td > a”は図 5 における 50 音順のリンクの位置を示す CSS セレクタである. ここで選択されたのは a タグであり, href 属性を持つ. その値である URL が次の“next”フィールドにおける “url”フィールドの値として用いられる (2. 2. 2) . つまり “あ”から “わ”までの URL 全てにリク
エストを送り, その遷移先のページにおいて芸能人の名前とそのブログの URL を取得するといった処理を行う. このように,“next”フィールドは遷移先の Web ページが同一のテンプレー

図 8 Web ページの変化 (パターン A)

トで生成されている Web ページに対して, それらの情報を抽出・統合することを可能にする.

4. データ抽出ルール自動更新機構
4. 1 Web ページの変化
Web ページやサイトは, 構造やレイアウトが変化することがありうる. パターンとしては, 表 2 に挙げる 3 パターンが想定される. Web ページにおいて表 2 に挙げるような変化が起こった際にも, 変化前と同様にデータ抽出を行う必要がある. 提案
システムにおいて, それぞれの変化のパターンにどのように追従することができるのかを, 例を用いて考察していく.
図 9 Web ページの変化 (パターン B)
表 2 Web ページの変化
パターン

レイアウト

構造

システムがデータ抽出の対象となる Web ページの変化を感

A

変化あり

変化なし

知できるのは, ユーザ指定のサイクルでデータ抽出を行うとき

B

変化あり

変化あり

である. その際, 抽出された結果のデータが 0 件になっていた場

C

変化なし

変化あり

合, つまり以前まで抽出できていたデータが全く抽出できなくなった場合, Web ページの構造に変化があったと言える. その

表 2 のパターン A の例を図 8 に示す. 図 8 の古い Web ペー

場合, ユーザに通知を行り, 再度ブラウザ GUI を通してデータ

ジと新しい Web ページにおいて, Web ページの閲覧者が見る抽出ルールの再定義を行ってもらうこともできる. しかし, そのページのレイアウトは変わってはいるが, 構造は変わっていな

ようなメンテナンスはユーザにとって負担となり得る. そこでい. つまり, 目的のデータを指定する CSS セレクタは変わって提案システムにおいて, パターン B や C のような Web ページ

いないことになる. このような場合, ユーザが古い Web ページの構造の変化の中でも, 図 9 に示したような単純な変化に対しにおいてシステムのブラウザ GUI を通して登録したデータ抽て, データ抽出ルールの再定義をシステム側で自動で行う, デー

出ルールは, 新しい Web ページに対しても適用することができ

タ抽出ルールの再定義機構を組み込んだ.

る.
一方, パターン B の例を図 9 に示す. 図 9 の古い Web ペー

4. 2 データ抽出ルール自動更新に至るまでと処理の流れ

ジと新しい Web ページにおいて, Web ページの閲覧者が見る

データ抽出ルール自動更新に至るまでとその処理の流れをページのレイアウトも, Web ページの構造も変化している. つ図 10 に示す. ユーザがブラウザ GUI を通して登録したデータ

まり, 目的のデータを指定する CSS セレクタに変化が生じてい抽出ルールを用い, システムはデータ抽出をユーザ指定の間隔ることになる. このような場合, ユーザが古い Web ページにで行う. 抽出されたデータが 0 件でない場合, データはデータ

おいてシステムのブラウザ GUI を通して登録したデータ抽出

ベースに格納される. 抽出されたデータが 0 件になっていた場

ルールは, 新しい Web ページに対しては適用することができ

合, データ抽出ルール自動更新機構が機能する. まず対象とな

ず, データ抽出を行うことができなくなる. 同様に, パターン

る Web ページにおいて, テキスト要素が存在する要素を全てC の場合に関しても, Web ページの構造が変化しているため,取得する. 次にテキスト要素が取得できた要素から, 3. 2. 1 のAlgorithm 1 によって CSS セレクタを生成する. ここで CSS
セレクタは重複を除き, 1 つ以上生成される. それらの各 CSS∩|Ak Ch |
Phk =
|Ch |

セレクタで指定することができるテキスト要素と, データベースに格納されているデータを比較する. データが完全に一致す

∩

Rhk =

るセレクタが, 目的の CSS セレクタとなる. 決定した CSS セ
レクタを用いて, データ抽出ルールの再定義を行う.

(1)|Ak Ch |
|Ak |

(2)

5. 4 商用システムとの比較
商用システムとの比較の結果を述べる. 比較対象のシステム
は, import io [1] と kimono [2] である.

5. 4. 1 機 能 比 較import io と kimono と提案システムの Ducky に関して, 以下に挙げる 4 項目の機能比較を行った.
（ 1 ） 形態（ 2 ） データのアップデート（ 3 ） 階層的 Web サイトへの対応（ 4 ） Web ページの更新追従
結果を表 3 に示す. まず比較項目 1 項目目の形態に関してだが, import io のみクライアントアプリケーションで, kimonoと Ducky は Web アプリケーションの形態となっている. 違い
図 10 データ抽出ルール自動更新に至るまでと処理の流れ

としては, import io はアプリケーション上で手動でデータ抽出を実行する必要があるのに対し, kimono と Ducky は Web

API によるデータの取得を可能としているといった利便性の点

5. 評

価

提案システムの評価として, 2 つの評価実験を行っている. 1
つ目は抽出されるデータの精度に関して, 既存の商用システムとの比較. 2 つ目は, データ抽出ルール自動更新の評価である.

であると考える. 2 項目目のデータのアップデートに関しては,kimono と Ducky に標準で備わっている機能となった. 3 項目
目の階層的 Web サイトへの対応に関しても同様である. 4 項
目の Web ページの更新追従に関しては, 提案システムである

Ducky 以外にはない機能となり, ユーザのデータ管理の負荷を
5. 1 実 験 項 目

軽減する強みとなる機能であると考えられる.

本章において, 提案システムの有用性を評価するために行っ

表 3 各システムの機能比較
import io

た実験に関して述べる. 以下の 2 つの実験を行った.

kimonoDucky

1 クライアントアプリケーション Web アプリケーション Web アプリケーション•

商用システムとの比較

比較項目：機能, 抽出されたデータの精度

•

2

×

○

○

3

×

○

○

4

×

×

○

データ抽出ルール自動更新機構の評価

データ抽出ルール自動更新機構によって再定義したデータ抽出ルールによって抽出されたデータの精度

5. 4. 2 抽出データの精度比較
単一 Web ページと階層的 Web サイトに対して, 抽出されたデータの精度比較を行う. なお以下に示す表において, 項目は5. 2 実験データ

次のように定義する.

実験にはカテゴリを問わず, 実際の Web ページをランダムに選び, 評価対象とした.

a. Web ページの特徴
b. Web ページ総数

5. 3 評 価 方 法
各システムを用いて抽出された結果のデータを C ={C1 , C2 , · · ·, Ch } , 正解の抽出データを A = {A1 , A2 , · · ·, Ak }とし, 適合率 (式 (1)), 再現率 (式 (2)) を用いて評価を行った.

c. 平均データ項目数
d. 平均データ総数
A. 指定のノードにノイズが含まれない (HTML 構造が単純)

B. 指定のノードにノイズが含まれない (HTML 構造が複雑)

C. 指定のノードにノイズが含まれる

D. 項目に Null 値が存在する

複合パターン遷移に関しても同様である.

E. ページにバグが存在する

表 5 階層的 Web サイトからのデータ抽出精度比較

F. その他
a5. 4. 3 単一 Web ページ
各システムを用いて, 単一 Web ページからのデータ抽出をb

平均ページ遷移数

import io

kimono

再現率

適合率 再現率

適合率cd

単一パターン遷移 15

44

87.6

72.1

89.9

100

5 12615

複合パターン遷移

52

36.5

19.9

68.1

72.1

8 18739

2行った結果の精度比較を表 4 に示す. A〜F は対象 Web ページの特徴別に分けたものである. A の “指定のノードにノイズが含まれない (HTML 構造が単純)”場合に関しては, どのシステ
ムを用いても再現率と適合率ともに高いデータを得ることが出来た. B の “指定のノードにノイズが含まれない (HTML 構造が複雑)”場合に関しては, 実験を行ったサイト群それぞれに対して, 再現率と適合率にバラつきが生じる結果となった. C の“指定のノードにノイズが含まれる”場合に関しては, import io

5. 5 データ抽出ルール自動更新機構の評価
提案システムにおけるデータ抽出ルール自動更新機構の評価に関して述べる. 評価項目は, 再定義したルールによって新し
い Web ページから抽出されたデータの精度である. 対象となる Web ページは, この 2 年間で実際に Web ページの構造が変化し, データ抽出ルールを適用することができなくなった 6 サ
イトを用いた.

には抽出した文字列に含まれるノイズを除去する機能がないため, kimono と Ducky よりも再現率と適合率が劣った. kimonoの Web アプリケーションでは, PC やモバイル端末のようにドラッグの動作によって目的のデータを選択することができるた
め, 目的のデータでは含みたくないノイズの除去が可能となった. しかしこの機能が上手く動作しないような Web ページも,実験対象の中では生じることがあった. Ducky にもデータ抽出
ルールにおいてノイズを除去するオプションがあるため, 今回のような結果となった.

5. 5. 1 抽出データの精度結果と考察
データ抽出ルール自動更新機構によって再定義したデータ抽出ルールを用いて抽出されたデータの精度を, 以下の表 6 に示す. まずサイト 3, 4, 5 に関してだが, 再現率と適合率がともに 100%という結果になった. これらのサイトは, 図 9 に挙げたような CSS セレクタのみに変化が生じているようなケースであったため, 提案したデータ抽出ルール自動更新機構が上手く機能したと考えられる. しかしその一方で, データ抽出ルールに続いて D の “項目に Null 値が存在する”場合に関して説明する. “項目に Null 値が存在する”とは, 抽出する項目の中で値をもたないようなデータが存在するような場合のことを示す. import io を用いた場合, 実験対象ページにおいてデータを項目別に上手く整形することができない状態が多々発生した.

kimono に関しても, Null 値の項目を上手く整形することができているものと, できていないものが発生した.

おいて階層的 Web サイトのクローリングを可能とする “next”
フィールドを用いるようなサイト 1 の場合に関しては, 提案機
構ではデータの精度に課題が残る結果となった. またサイト 2,

6 に関しては, 再現率と適合率がともに 0%となってしまった.
これはそもそも対象となる Web ページの URL がリンク切れになっており, データ抽出を行うことができなかったためである. 今後提案システムにおいて, このような場合にはユーザに一方, E や F のように, Ducky では再現率や適合率が下がったり, 対応することができないような Web ページも生じた結果通知を送り, ルールの再定義を促すような機構が必要になると
考える.

となった.
表6
表4

a

b

単一 Web ページからのデータ抽出精度比較

import io

kimono適合率

Ducky
再現率 適合率cd

再現率

適合率 再現率

A 10

100

100

100

100

100

100

3 261

B 15

83.4

100

36.9

59.9

87.1

100

5

C 10

50

50

100

100

100

100

4 338

D

2

0

0

85

73.9

100

100

5

E

2

99.3

100

98.7

100

85.7

68.9

2 610

F

5

100

100

100

100

-

-

3 100

78

データ抽出ルール自動更新機構による抽出データの精度結果
サイト

再現率

適合率 データ総数

1

23.8

19.9

2

0

0

0

3

100

100

3631

4

100

100

41

5

100

100

52

6

0

0

0

10

60

5. 4. 4 階層的 Web サイト
kimono と Ducky を用いて, 階層的 Web サイトからのデータ抽出を行った結果の精度比較を表 5 に示す. 単一パターン遷移に関しては, 実験において用いた階層的 Web サイトにおいて,
ボタンリンクでページ遷移を行うような場合に kimono では対応することができないことがあり, 再現率と適合率が下がった.

6. 関 連 研 究
今日まで Web から情報を取得する研究は数多くなされてきた [13]. 提案システムに Web ラッパーが含まれていることから, その関連研究に関して述べる. ラッパーの作成には半自動(semi-automatic) と自動 (automatic) の 2 通りの方法がある.
半自動によるラッパーの作成では, ユーザがルールを事前に指定することで抽出を行う. Zhang らが提案したラッパー [14] やAdelberg が提案した NoDoSE [3] ではルール定義に設定ファイ抽出ルール生成・自動更新機構を提案した. 1 番目の評価実験

ルを用いる. 設定ファイルは XML などのフォーマットに, 対により, 既存の商用システムよりも有用なデータ抽出を行うこ象 URL や取得したい HTML 要素のパスなどを記述する. 定義とが可能であることが示された. また 2 番目の評価実験により,後はシステムが自動でデータ抽出を行う. ユーザはプログラミ

提案のデータ抽出ルール自動更新機構は階層構造を持つようなングを必要としないことが特徴である. OXPath [6] [12] では,

複雑な Web サイトに対しては課題が残される結果となった. 今

Xpath を拡張した独自の構文を開発し, データの抽出を行う.

後はこの点に関して対応を行っていきたいと考える.

しかし, 以上のような半自動のラッパー生成の手法では, 抽出対
象となるページそれぞれについてルール定義を行わなければな
らず, ユーザにかかる負担が高くなる. そこでユーザのルール
定義におけるコストを削減するために, ラッパーの自動生成を行なう研究も多くなされてきた.
ラッパーの自動生成で最も有名で古いものは, Kushmerick [10]によるラッパーである. Kushmerick はトレーニングサンプルを与えて抽出すべきコンテンツの前後に現われる文字列を学習するラッパー帰納問題による方法で, ラッパーの自動生成を行った. つまりこれは事前に教師データを必要とする. 一方, Chang
ら [5] は教師データを用いない方法でラッパーの自動生成を行った. Chang らが提案した IEPAD は, 入力 HTML の文字列の繰り返し, つまり規則性を探索とするものである. IEPAD は

HTML をそのまま入力として利用できることから, 完全自動のラッパーであると言える. しかし対象ページを単一レコードを含むページに限定しており, 抽出不能なページに対しては何ら適用できないという問題点が存在する.
このように, これまでラッパーの自動生成に関する研究がされてきたが, これらのラッパーの抽出精度はいずれも完璧ではなかったり, 現在の HTML には対応できないものや, IEPADのように扱えないドキュメントが存在するなど, 課題が残されていると言える. また, 情報抽出の分野全体として見たとき, 取
得したいデータは単一の URL に存在しているとは限らず, 階層構造となっている Web サイトにまたがっていたり, 別々のWeb ページ上に点々と存在していることも考えられる. そこで,
文献 [4] や [7] では GUI を用いて様々なページからデータを取得し統合可能な抽出システムを開発した. また, [11] ではクローリングしデータ統合するためのページ URL を収集するアルゴ
リズムを提案している. OXPath [6] では独自の構文によって,階層構造の Web ページから構造化データを抽出し統合することができる. しかし OXPath において複雑な構造に対応する場合, 非常に複雑なルール定義になってしまい, ユーザにとってルール定義やメンテナンスが困難である.
このようにさまざまな方法で Web ドキュメントからデータを取得する方法が研究されてきたが, 自動とそうでない半自動の方法とではコストと精度がトレードオフの関係になり, 依然
課題として残っている問題点が数多く残されている. 特に対応できる Web サイトの構造, 複数ページからのデータ統合などの問題点を網羅的に解決する, 実際に利用できるシステムが少ないといった問題点が大きいと考える.

7. まとめと結論
本論文では Ducky の全体像とブラウザ GUI を示し, データ

文献[1] import io. https://import.io/.
[2] kimono. https://www.kimonolabs.com/.
[3] Brad Adelberg. NoDoSE - a tool for semi-automatically extracting structured and semistructured data from text documents. SIGMOD Rec., 27(2):283–294, June 1998.
[4] Sudhir Agarwal and Michael Genesereth. Extraction andintegration of web data by end-users. In Proceedings ofthe 22Nd ACM International Conference on Conference on
Information & Knowledge Management, CIKM ’13, pages
2405–2410, New York, NY, USA, 2013. ACM.
[5] Chia-Hui Chang and Shao-Chen Lui. Iepad: Information
extraction based on pattern discovery. In Proceedings of the10th International Conference on World Wide Web, WWW’01, pages 681–688, New York, NY, USA, 2001. ACM.
[6] Tim Furche, Georg Gottlob, Giovanni Grasso, Christian
Schallhart, and Andrew Sellers. Oxpath: A language forscalable data extraction, automation, and crawling on the
deep web. The VLDB Journal, 22(1):47–72, February 2013.
[7] Matthias Geel, Timothy Church, and Moira C. Norrie. Sift:
An end-user tool for gathering web content on the go. In
Proceedings of the 2012 ACM Symposium on Document Engineering, DocEng ’12, pages 181–190, New York, NY, USA,2012. ACM.
[8] Kei Kanaoka, Yotaro Fujii, and Motomichi Toyama. Ducky:
A data extraction system for various structured web documents. In Proceedings of the 18th International Database
Engineering & Applications Symposium, IDEAS ’14, pages
342–347, New York, NY, USA, 2014. ACM.
[9] Kei Kanaoka and Motomichi Toyama. Eﬀective web data
extraction with ducky. In Proceedings of the 19th International Database Engineering & Applications Symposium,
IDEAS ’15, pages 212–213, New York, NY, USA, 2014.
ACM.
[10] Nicholas Kushmerick. Wrapper induction: Eﬃciency andexpressiveness. Artif. Intell., 118(1-2):15–68, April 2000.
[11] Tiezheng Nie, Zhenhua Wang, Yue Kou, and Rui Zhang.
Crawling result pages for data extraction based on url classification. In Proceedings of the 2010 Seventh Web Information Systems and Applications Conference, WISA ’10,
pages 79–84, Washington, DC, USA, 2010. IEEE Computer
Society.
[12] Andrew Jon Sellers, Tim Furche, Georg Gottlob, Giovanni
Grasso, and Christian Schallhart. Oxpath: Little language,
little memory, great value. In Proceedings of the 20th International Conference Companion on World Wide Web,
WWW ’11, pages 261–264, New York, NY, USA, 2011.
ACM.
[13] H.A. Sleiman and R. Corchuelo. A survey on region extractors from web documents. Knowledge and Data Engineering, IEEE Transactions on, 25(9):1960–1981, September 2013.
[14] Suzhi Zhang and Peizhong Shi. An eﬃcient wrapper for web
data extraction and its application. In Computer Science
Education, 2009. ICCSE ’09. 4th International Conferenceon, pages 1245–1250, July 2009.