AIBR プレミアム
拓海先生、お忙しいところ恐れ入ります。最近、部下から『Deep Web』や『Hidden Web』なる言葉が出てきまして、うちの受注データや製品仕様が見つからないと困る、と。これって要するにインターネット上の“見えない倉庫”を探す話ですか？
素晴らしい着眼点ですね！その通りです。Deep Webは一般的な検索エンジンが拾えない情報の総称で、フォームや検索窓の奥に隠れているデータのことですよ。大丈夫、順を追って説明すれば必ず理解できますよ。
なるほど。で、そのDeep Webにあるデータを自動で拾うクローラというものがあると。うちで使う場合、どの程度現場に負担がかかりますか。投資対効果が一番気になります。
大丈夫、一緒にやれば必ずできますよ。要点を3つだけ挙げると、1) どの領域のフォームを狙うかという『ドメイン設計』、2) フォームに適切な入力値を当てるための『意味の辞書』、3) 得られたページを整理する『適合判定』です。投資対効果の観点では最初は狙う領域を絞るのが肝心ですよ。
拓海先生、その『意味の辞書』というのは要するにデータの関係性や言葉の意味を教える辞書のようなものですか。具体的にはどう作るのですか。
素晴らしい着眼点ですね！その辞書は『Ontology（オントロジー）』と呼ばれます。オントロジーは用語とその関係性を構造化したもので、例えば『製品名』と『型番』がどう結び付くかを定義すると、フォームに適切な組み合わせで入力できるんですよ。身近に例えるなら、部品表のように関係を明示するルールブックです。
それなら理解しやすいです。これって要するにうちの製品分類や顧客属性を事前に整理しておけばクローラが効率的に拾えるということ？実務ではどこから手を付ければ良いのか教えてください。
大丈夫、一緒にやれば必ずできますよ。現実的な着手は小さく始めることです。まずは社内で最も価値の高い項目、たとえば『型番』『出荷日』『仕様PDF』などを決め、そこに合うオントロジーを作り、限られたフォームで試験的に収集すると良いですよ。
なるほど。最後に一点確認ですが、作ったオントロジーは自動で賢くなるのか、それとも定期的に手で更新する必要がありますか。現場の人手は限られています。
素晴らしい着眼点ですね！この論文で示された設計は『適応的（adaptive）』で、新たに取得したページからオントロジーを拡張できる仕組みを備えるとしています。つまり完全自動ではなく、人がレビューする仕組みと組み合わせることで精度と現場負担の両立が可能になるんですよ。
わかりました。では私の言葉で確認しますと、まず価値の高い領域を絞ってオントロジーを用意し、それを使って隠れたフォームからデータを取ってきて、取れてきたデータでオントロジーを賢くしていくという流れで、最初は手作業の確認を挟む仕組みが必要ということですね。
