現在、日本におけるウェブデータがどの程度あり、そのうち保存管理に用いることのできる記述メタデータ（タイトル、著者名、キーワード等）がどの程度設定されているかを把握するためにクローラを用いた調査を行った。この調査の仕様と要件を表1に示す。

　調査に関する問合せ対応等に要した期間を除いた実質クロール調査日数は23日であり、この期間での調査ウェブデータ量は4.9TB、調査ファイル数は1億2000万ファイルとなった。既読URL発見率の推移から日本におけるウェブデータ総量とファイル総数を推定するとそれぞれ18.4TB、4億5000 万ファイルとなった。これを表2に示す。

2.2.2. ファイルタイプ別調査ウェブデータ量とファイル数

　本調査で得られたウェブデータ量とファイル数をファイルタイプ別に分けて表3に示す。

　本調査において対象としたURLのホスト名部分からドメイン別にユニークホスト数を集計した結果を図1に示す。jpドメイン全体では約18万ホストで、このうちco.jpドメインのウェブホストが約3分の1を占める。jpドメイン以外では約13万ホストで、このうち.comドメインのウェブホストが半分以上を占める。

図1　ドメイン別ウェブホスト数

　本調査において各ホスト内のウェブデータ量とファイル数についても集計を行った。その結果を表4と表5に示す。これらの表から96%のウェブホストはファイルを2,000以下しか保有していないことが分かる。
　また、少数であるが膨大な量のウェブデータを持つウェブサイト（最高で102GB）と膨大な数のファイルをもつウェブホスト（最高で72,773ファイル）が存在することが確認できた。

　タイトル等メタデータについて集計を行った結果を表6に示す。タイトルについては95%のHTMLファイルで設定されていたものの、著者については 5%、概要については14%、キーワードについては14%の割合でしか設定されていないことが分かった。さらに、ダブリンコアの設定（<meta_dc.title>、 <link_dc.creator>の様な形式で設定されているもの）については非常に少数（0.3%未満）であった。
このように記述メタデータの設定割合は低く、こういったメタデータだけで分類を行うのは不十分であることが分かる。

　本調査で明確になったウェブアーカイブの要件について、「収集」「蓄積・保存」「閲覧」の3つの機能に分けて概要を示す。

　収集において、事前公告などの事前準備と、収集条件の設定や収集機能に関してポイントとなる事項を以下にまとめる。

1. 収集方法や条件などを記載した説明ページの設置と、FAQのメンテナンス
   　特に収集拒否（ロボット排除指定）の方法を明示することが重要である。また公開時の利用制限種別の指定方法も、それまでに決めて公告する必要がある。
2. 優先収集するウェブサイトの確定と協力依頼
   　優先収集するウェブサイト（やドメイン）を確定し、当該ウェブサイトのファイル数とデータ量を事前確認しておく。あらかじめ定めた収集期間内に収集完了できる条件を算出し、必要があれば、当該ウェブサイト管理者に高頻度収集等について事前許諾（もしくはファイルの媒体提供協力）を得ることが必要である。
3. 一般サイトの収集条件（リクエスト間隔や最大転送速度など）の決定
   　被収集サイトに過剰な負荷を与えないように収集する必要がある。本調査中に寄せられたサイト管理者等からの問合せやコメントから判断すれば、リクエスト間隔30秒で転送速度最大1Mbpsまでとしファイルサイズを最大60MBまでとした、本調査での収集条件を一応の目安とすることができる。
4. インターネットサービスプロバイダ等への協力依頼
   　人権侵害などの理由によりプロバイダの判断で編集・削除した場合に、ウェブアーカイブでも収集ファイルに対して同じ対応ができるように、編集・削除の内容を通知してもらう必要がある。
5. 起点URLの収集
   　収集前に、クロールの起点となるURLを十分に収集しておく。理想的には、収集対象となるURLを継続して集め、効率的に収集できるよう精査選別しておくことが望ましい。

1. 収集範囲
   　本調査の範囲と同じとする。しかしながら、継続して、利用されるプロトコルやデータ形式の普及度合いに応じて随時見直していく。
2. 推定収集データ量
   　平成18年度で約5.4億ファイル、22TBとなる。これまでの推移から、今後数年は年率20〜30%程度で増加するものと推定されるが、毎年見直しが必要である。

1. リクエスト間隔と転送速度
   　事前許諾を得ていないサイトでは連続アクセス時には30秒を空けるものとし、また、最大の転送速度は1Mbpsまでとする。この条件で収集期間内に収集し終わらないサイトは、途中までの収集となる。収集できるファイル数は、サイト内のファイルサイズ分布によるが、収集期間が60日であれば、1サイトあたり平均して6万ファイルとなることが見込まれる。
2. サイト毎の収集条件設定
   　優先収集するサイトでの高頻度高速転送に対応するため、あるいは、収集日時を指定されるサイトに対応するために、サイト毎に収集条件を設定できる必要がある。
3. ロボット排除指定の遵守
   　WARP（ユーザエージェント名:ndl-japan-warp-0.1）用など、国会図書館が用いている全てのクローラのユーザエージェント名をサイト管理者が認識できるようにする。また、googleやYahoo！など代表的な検索サービス事業者のクローラで独自拡張しているロボット排除指定方法にも対応しておく。

1. 一般のサイト
   　1年間に60日程度の収集期間とすると、平成18年度は平均して約1,000万URL／日の収集性能が必要であり、その後は、少なくとも年率20〜30%程度で性能向上が可能な拡張性を有していることが必要である。
2. 優先サイト
   　ファイル数の大きなウェブサイトでは、リクエスト間隔を短くする必要がある。例えば30万ファイルを有するサイトを60日程度で収集するためには、10秒程度の間隔とする必要がある。さらに、リンク一貫性を高く保つ必要のあるサイトでは、1秒に1回もしくはそれ以上でリクエストできるようにする。

1. リンク抽出
   　特に、JavaScriptのようにブラウザで動的に生成されるリンクの抽出精度がポイントとなるが、技術的に精度を高めるのが難しく今後も検討が必要である。また、この中には、ユーザが入力したデータによってURLが生成されるものがあり、これらに対しては機械的にURLを生成することはできない。
2. 安全性の確保
   　ページを書き換えてしまうようなリンクや、共有カレンダーなどでほぼ無限に自動生成されるリンク、あるいは悪意をもったサイト攻撃スクリプトへのリンクなど、危険なリンクにアクセスしないようにする。このためには、リンク情報だけでなくコンテンツ内容の解析も合わせることで安全性を向上するなど、継続して技術開発を進める必要がある。

　収集から公開まで期間が空く場合には、ユーザがURLを指定すると収集されたかどうかの確認ができるような機能を持つことが必要である。

　蓄積・保存に関して、保存すべき情報と形式、および消去申出対応についての概要を述べる。

1. コンテンツに関する情報
   　クローラのIPアドレスやリクエスト情報などリクエストした時の条件によって、収集されるファイルが変わる。このため、収集されるファイルだけでなくTCP/IPレイヤ以上の送受信データと収集日時を含めて保存しておく必要がある。
2. 収集除外理由
   　ページ内に記述されているMETAタグで排除されている場合には、そのページそのものが残せないため、このMETAタグ情報が残せない。文書等で収集拒否を受け付けた場合も含め、これらの情報を別途保存しておく。
3. 消去／編集履歴
   　収集後に消去あるいは編集した履歴情報も保存しておく。
4. 利用制限情報
   　閲覧に関して、ファイルの著作権者等から利用制限の条件が指定された場合には、この情報を保存しておく。

　オープンな規格にもとづくことが望ましいため、ARC形式をベースに拡張するのがよい。しかしながら、既存のツール類（オープンソースの閲覧ソフトなど）が使えなくなる可能性もあり、決定には、収集範囲等とあわせて十分な検討が必要である。
　WARPやThe Internet Archiveなど類似のシステムでの形式を調査し、これらを参考に詳細化を図る必要がある。

1. 受付方法
   　できる限りウェブのForm受付とするなど自動化を図るようにする。本人性の確認はロボット排除設定がなされているかどうかを確認することで行う。消去の申出をしたい人が、該当ファイルに対するロボット排除の設定ができる場合は、正当な申出であるとみなすことができる。したがって、ウェブのForm受付で申出をしてもらった際に、このロボット排除設定をしてもらうように促し、この設定が確認できれば消去する、といった自動化を行う方法が考えられる。
2. 消去・編集の単位
   　ARC形式で保存する場合は、消去・編集はファイル単位で行うこととなる。しかしながら、文書ファイルなどで編集が不可能な設定がされている場合は、編集できない。

　閲覧について、ウェブアーカイブに固有の重要な閲覧機能等について概要を述べる。

1. リンク書き換え機能
   　収集したファイルの中の全てのリンクを、ウェブアーカイブサイト内のアドレスを指すように書き換える必要がある。このためには、全てのリンクを抽出して書き換える。リンクを抽出する機能に関する問題点はクローラと同じである。リンクを書き換える機能に関しては、PDFなど文書ファイルでは、文書ファイルのレイアウトを壊してしまったり、編集が出来ないような設定がされていたりする場合があるため、対象外となる。
2. アクセス制御・ファイル提供制限機能
   　館内のみ閲覧を許可する場合や、閲覧は一切行わず保存のみ行う場合など、利用制限をファイル単位で指定できるようにしておく。また、ファイル種別によって提供を制限することも想定されるため、ファイル種別とドメイン（ホスト）でも条件指定が可能となるようにしておく。
3. ナビゲーション機能
   　通常のウェブサイトでのナビゲーションに関する要件に加えて、アーカイブでは、閲覧者がリンクを辿っている間に、勝手に別の時代のドキュメントに行かないようにすることが必要である。しかしながら、ブラウザで生成されるJavaScriptなどでのリンクは、ウェブアーカイブシステムで制御することができないために閲覧時点のURLとなってしまう。このため、気がつかない内に、アーカイブの外に出てしまうという問題が生じる。この解決のためには、さらに検討を要する。

　収集日時とURLを指定して閲覧に供するのが基本的な機能となる。タイトル、著者、キーワードなどのメタデータによる検索は、これらが設定されている HTMLでのみ有効であるが、タイトル以外の設定率は10%程度と低いため、検索の網羅性は低くなる。このため、全文検索機能の提供や、高度なコンテンツ解析を適用した自動分類支援機能を使った分類情報の提供を検討していく必要がある。

　「3.2.3. 消去・編集の申出対応」と同じく、できるだけ自動化を検討する。

　ポータルサイトや他のデジタルアーカイブシステムとの連携や、ユーザのコンピュータからの自動アクセス手段を提供することで、様々な利用価値が生じる。 ウェブサービスで用いられる標準的なインタフェースや、OAI-PMHのようなメタデータハーベストプロトコルによるインタフェースを整備していくことが望まれる。