(57)【要約】【課題】Ｗｅｂアクセスルートを解析し、ユーザのアクセスシーケンスの高頻度なパターンを把握する方法を提供する。【解決手段】Ｗｅｂアクセスログから各ユーザのセッション毎のアクセスルートを求める前処理のステップと、該前処理で求めた各ユーザのセッション毎のアクセスルートの中から選んだ任意の二つのアクセスルートについて、ＬＣＳアルゴリズムを用いて前記二つのアクセスルートに共通するアクセスパターンを抽出するステップと、前記前処理で得られたすべてのアクセスルートについて前記ＬＣＳアルゴリズムを用いて抽出した共通アクセスパターンのうち、最も頻度が多いものを頻出アクセスパターンとして決定するステップとを具備することによって達成される。【選択図】図２
2004152209.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂアクセスログを基にして、ユーザのアクセスパターンを解析するＷｅｂアクセスログ解析方法において、
該方法は、
前記Ｗｅｂアクセスログから各ユーザのセッション毎のアクセスルートを求める前処理のステップと、
該前処理で求めた各ユーザのセッション毎のアクセスルートの中から選んだ任意の二つのアクセスルートについて、ＬＣＳアルゴリズムを用いて前記二つのアクセスルートに共通するアクセスパターンを抽出するステップと、
前記前処理で得られたすべてのアクセスルートについて前記ＬＣＳアルゴリズムを用いて抽出した共通アクセスパターンのうち、最も頻度が多いものを頻出アクセスパターンとして決定するステップと、
を具備するものであることを特徴とするＷｅｂアクセスログ解析方法。
【請求項２】
前記前処理のステップが、前記ＷｅｂアクセスログからＷｅｂページ間の移動情報を構成するために必要なリクエストファイル以外のファイルを取り除いてから各ユーザのセッション毎のアクセスルートを求めるものである、請求項１に記載のＷｅｂアクセスログ解析方法。
【請求項３】
前記Ｗｅｂページ間の移動情報を構成するために必要なリクエストファイルがＨＴＭＬファイルであることを特徴とする請求項２に記載のＷｅｂアクセスログ解析方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、Ｗｅｂサイトへのアクセスログの解析方法に関し、特に、Ｌｏｎｇｅｓｔ  Ｃｏｍｍｏｎ  Ｓｕｂｓｅｑｕｅｎｃｅ（ＬＣＳ）アルゴリズムを用いたＷｅｂアクセスログ解析方法に関するものである。
【０００２】
【従来の技術】
現在、Ｗｅｂサイトは広報・広告・マーケティングの手段として極めて重要な位置を占めている。Ｗｅｂサイトを開設し企業情報・商品情報を発信することはもはや企業の発展にとって必要不可欠な要件である。
【０００３】
現在は情報が氾濫している時代であり、ユーザは無数にあるＷｅｂサイトから自分の望む情報を効率良く獲得しようとする。もし、サイトの構成が悪くユーザに必要な情報が不透明であればユーザは即座に情報探索をあきらめ次のサイトヘ移ることになる。
【０００４】
このような状況の中で、Ｗｅｂサイトヘのアクセス状況を的確に把握し発信したい情報が受け手に確実に届いているかどうかを見極めることはＷｅｂサイト管理者の最も重要な仕事の一つである。その手法の一つとしてＷｅｂのアクセスログ解析がある。管理者はアクセスログの解析結果から取り出す情報を意思決定材料として、ユーザのニーズにあったサイト構築を行うことができる。
【０００５】
従来のアクセスログ解析のアプローチには、ページ別アクセス頻度、時間別、期間別アクセス頻度、訪問者の使用しているＯＳ、ブラウザの種類の集計、Ｗｅｂサイトのアクセス元の集計などが存在する。これらの解析手法によってサイト管理者はアクセス頻度の高いページ、時間帯別アクセス状況、自サイトへのアクセス元などを知ることができる。これらの情報も管理者にとって重要な要素の一つであるが、それだけでは訪問者がどのようにサイトを巡回する傾向にあるのか判断できない。
【０００６】
すなわち、これまでのアクセスログの解析は、ユーザが通った（部分）ルート（ＵＲＬの推移）が同一であるかどうかの判定はできるが、似たルートの中で、よく現れる共通パターンを抽出しては来なかった。
【０００７】
あるルートα＝（ａ１，ａ２，ａ３，…，ａｎ）について、ルート（ａｉ，ａｉ＋１，…，ａｊ）（１≦ｉ≦ｊ≦ｎ）を満たすものを部分ルートと呼ぶが、長さｎのルートに関してはｎ（ｎ−１）／２通りの部分ルートが存在する。部分ルートの統計からは、ある二地点間、三地点間における推移の頻度や、ノードの独立性の高さ、ページ間の推移の頻度も分かる。これらの情報を統合すれば、ある程度ユーザのたどるアクセスパターンを知ることはできる。
【０００８】
しかしながら、多くのＷｅｂサイトではユーザが欲しい情報を探索している場合に、ページ間の移動を頻繁に行いサーチとバックトラック操作を繰り返すのが一般的である。その際に残されるアクセスログは必ずしも連続性を持った情報ではない。ユーザがサーチを行った結果として残されるログは、サーバへリクエストされたものであり、すでにユーザ側にファイルのキャッシュがあれば当然ログとしては残されない。
【０００９】
バックトラックポイントの説明として例を示す。図５のようにな階層構造をもったサイトをあるユーザのサーチした結果に残されたログが（Ａ１，Ｂ１，Ｃ１，Ｃ２，Ｂ４）であったとする。このとき、ブラウザのキャッシュ機能を考慮に入れれば、このユーザが実際にサーチしたルートは（Ａ１，Ｂ１，Ｃ１，Ｂ１，Ｃ２，Ｂ１，Ａ１，Ｂ４）となるはずである。ここではバックトラックポイントはユーザの情報探索中に元来たノードへ戻る折り返し地点のことを指す。この例では（Ｃ１，Ｃ２）の２点がバックトラックポイントである。
【００１０】
このように、一般的にサーチ時に様々な寄り道はつきものである。すなわち、部分ルートからだけでは単純に２地点間のつながりの深さを知ることはできても、ユーザの一連の操作である真に頻出のアクセスパターンを見つけることは困難である。
【００１１】
以下、Ｗｅｂのページ構造を簡単化のためにリンクによる木構造にみたて（本来は、リンクによるグラフになっている）、ページに番号をふって説明を行う。根から深さを増すごとにＡ，Ｂ，Ｃ，Ｄ，Ｅとし、同じ深さのページに関して木の左から右へＢ１，Ｂ２，Ｂ３とする。
【００１２】
例えば、二人のユーザを想定して、それぞれのユーザのあるＷｅｂのアクセスルートが、ルートβ（Ａ１，Ｂ１，Ｃ１，Ｄ１，Ｅ１）とルートγ（Ａ１，Ｂ１，Ｃ２，Ｄ１，Ｅ１）であったとすると、従来の技術では、この二つのルートはまったく別なルートとして集計されることになる。
【００１３】
しかし、Ｗｅｂの構成を考える上では、二つのルートの中で、Ａ１，Ｂ１，Ｄ１，Ｅ１が共通であるという情報は重要である。
【００１４】
これまで、アクセス頻度の高いページ間のリンクを可視化して表現する等の手法はあったが、それでは頻出の共通ルートを抽出することはできない。
【００１５】
具体的には、大浦らによる、特定の問い合わせサイトにおいて、ユーザセッションのクラスタ化により問い合わせ拡張支援を行う手法についての実験報告がなされている（例えば、非特許文献１参照。）。これは、サイト内のページをアイテムとするセッションベクトルを用いてクラスタリングし、関連性の高いアイテムを分析する手法である。この手法はＹａｈｏｏ！などの検索サイト、あるいはＡｍａｚｏｎなどの問い合わせサイトといった、インデックスページとコンテンツページが明確に分かれており整然とした階層構造を持ったＷｅｂサイトにおいて非常に有効であった。しかし、インデックスページとコンテンツページが混在する一般的なサイトでは、セッションベクトルとすべきアイテムのレベルが並列ではなく、一般的に決めることが困難である。また、アクセスログのみを用いて解析を行うツールと比較すると解析の前処理のコストが大きい。
【００１６】
又、ユーザのクリック操作のビジュアル化を目的とする様々なツールを用いて視覚的にＷｅｂサイトのアクセス状況を示し、解析、改善を支援する研究も多数報告されている。アクセスログを２次元グラフで表現しユーザのアクセスパターンを視覚化する研究、ユーザの頻出操作パタ    ーンを発見するためのマイニングシステムの研究などが行われている（例えば、非特許文献２，３，４，５参照。）。
【００１７】
Ｗｅｂサイトの再構成の研究ではＲａｍａｋｒｉｓｈｎａｎ等（例えば、非特許文献６参照。）によるユーザのターゲットページまでのバックトラックポイントの減少を目的とする解析手法が提案されている。しかし、ユーザ操作はランダム性に富み、操作状況やネットワークの状態が完全にユーザごとに異なるため、アクセスログのみからバックトラックポイントと目的のページを区別することは容易ではない。
【００１８】
【非特許文献１】
大浦勇亮、喜連川優：Ｗｅｂアクセスログのクラスタリングによる問い合わせ拡張に関する検討：ｉタウンページ上での実験、電子情報通信学会データ工学ワークショップ  ＤＥＷＳ，  Ａ２−１，２００２．
【００１９】
【非特許文献２】
Ｂｏｗｏ  Ｐｒａｓｅｔｙｏ，  Ｉｋｏ  Ｐｒａｍｕｄｉｏｎｏ，  Ｋａｔｓｕｍｉ  Ｔａｋａｈａｓｈｉ，  Ｍａｓａｓｈｉ  Ｔｏｙｏｄａ，  ＭａｓａｒｕＫｉｔｓｕｒｅｇａｗａ：  “Ｎａｖｉｚ：  Ｕｓｅｒ  Ｂｅｈａｖｉｏｒ  Ｖｉｓｕａｌｉｚａｔｉｏｎ  ｏｆ  Ｄｙｎａｍｉｃ  Ｐａｇｅ”，  電子情報通信学会データ工学ワークショップ  ＤＥＷＳ，  Ｃ５−３，２００２．
【００２０】
【非特許文献３】
Ｐｉｔｋｏｗ，Ｊ．  ａｎｄ  Ｋ．  Ｂｈａｒａｔ．  ＷｅｂＶｉｚ：  “Ａ  Ｔｏｏｌ  ｆｏｒ  Ｗｏｒｌｄ−Ｗｉｄｅ  Ｗｅｂ  Ａｃｃｅｓｓ  Ｌｏｇ  Ａｎａｌｙｓｉｓ”，  Ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  Ｆｉｒｓｔ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  ｔｈｅ  Ｗｏｒｌｄ−Ｗｉｄｅ  Ｗｅｂ  １９９４．
【００２１】
【非特許文献４】
Ｍ．Ｓｐｉｌｉｏｐｏｕｌｏｕ  ａｎｄ  Ｌ．Ｃ．Ｆａｕｌｓｔｉｃｈ：  “Ａ  Ｗｅｂ  Ｕｔｉｌｉｚａｔｉｏｎ  Ｍｉｎｅｒ”，  Ｉｎ  Ｐｒｏｃ．  ｏｆ  ＥＤＢＴ  Ｗｏｒｋｓｈｏｐ  ＷｅｂＤＢ９８，Ｖａｌｅｎｃｉａ，Ｓｐａｉｎ，１９９８  Ｓｐｒｉｎｇｅｒ  Ｖｅｒｌａｇ．
【００２２】
【非特許文献５】
Ｃｕｇｉｎｉ，Ｊ．  ａｎｄ  Ｊ．Ｓｃｈｏｌｔｚ：  “ＶＩＳＶＩＰ：３Ｄ  Ｖｉｓｕａｌｉｚａｔｉｏｎ  ｏｆ  Ｐａｔｈｓ  ｔｈｒｏｕｇｈ  Ｗｅｂ  Ｓｉｔｅｓ”，  Ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｗｅｂ−Ｂａｓｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｖｉｓｕａｌｉｚａｔｉｏｎ  （ＷｅｂＶｉｓ’９９）．，  ｐｐ．２５９−２６３．  ＩＥＥＥ  Ｃｏｍｐｕｔｅｒ  Ｓｏｃｉｅｔｙ，  Ｓｅｐｔｅｍｂｅｒ  １−３  １９９９．
【００２３】
【非特許文献６】
Ｒａｍａｋｒｉｓｈｎａｎ  Ｓｒｉｋａｎｔ，  ａｎｄ  Ｙｉｎｇｈｕｉ  Ｙａｎｇ，：  “Ｍｉｎｉｎｇ  Ｗｅｂ  Ｌｏｇｓ  ｔｏ  Ｉｍｐｒｏｖｅ  Ｗｅｂｓｉｔｅ  Ｏｒｇａｎｉｚａｔｉｏｎ”，  ＡＣＭ  １−５８１１３−３４８  ｐｐ．４３０−４３７  ＡＣＭ，  Ｍａｙ  ２００１．
【００２４】
【発明が解決しようとする課題】
本発明は、かかる従来技術の問題点に鑑み為されたものであり、Ｗｅｂアクセスログを基にして、訪問者（ユーザ）ごとのセッションにおいてアクセスされたＵＲＬの推移、すなわちユーザのアクセスルートを解析し、ユーザのアクセスシーケンスの高頻度なパターンを把握する方法を提供することにより、Ｗｅｂサイトの管理者がサイトの構成上の問題点を的確に知り、Ｗｅｂ構成の改善や、Ｗｅｂの広告配置の戦略の策定等に利用することができるようにすることを目的とする。
【００２５】
【課題を解決するための手段】
本発明は、Ｗｅｂサイトへのアクセスログの解析方法に関し、本発明の上記目的は、Ｗｅｂアクセスログを基にして、ユーザのアクセスパターンを解析するＷｅｂアクセスログ解析方法において、該方法は、前記Ｗｅｂアクセスログから各ユーザのセッション毎のアクセスルートを求める前処理のステップと、該前処理で求めた各ユーザのセッション毎のアクセスルートの中から選んだ任意の二つのアクセスルートについて、ＬＣＳアルゴリズムを用いて前記二つのアクセスルートに共通するアクセスパターンを抽出するステップと、前記前処理で得られたすべてのアクセスルートについて前記ＬＣＳアルゴリズムを用いて抽出した共通アクセスパターンのうち、最も頻度が多いものを頻出アクセスパターンとして決定するステップとを具備することによって達成される。
【００２６】
また、本発明の上記目的は、前記前処理のステップにおいて、前記ＷｅｂアクセスログからＷｅｂページ間の移動情報を構成するために必要なリクエストファイル以外のファイルを取り除いてから各ユーザのセッション毎のアクセスルートを求めるようにすることにより、より効果的に達成される。前記Ｗｅｂページ間の移動情報を構成するために必要なリクエストファイルの一例としてはＨＴＭＬファイルが挙げられる。
【００２７】
【発明の実施の形態】
本発明は、多くのユーザがアクセスするＷｅｂサイトにおいて、その構成をユーザのアクセス履歴を基に改善する手法に関して、ユーザのアクセスログの解析にＬｏｎｇｅｓｔ  Ｃｏｍｍｏｎ  Ｓｕｂｓｅｑｕｅｎｃｅアルゴリズムを用いることで、従来不可能であったアクセス履歴の頻出パターンを抽出し、より効率のよいＷｅｂの構成を可能にするためのものである。
【００２８】
従来、遺伝子構造の解析などでは、頻出パターンを検出するためにＬｏｎｇｅｓｔ  Ｃｏｍｍｏｎ  Ｓｕｂｓｅｑｕｅｎｃｅ（ＬＣＳ）アルゴリズムがよく用いられている。しかし、これまでＬＣＳはＷｅｂのアクセスログ解析には用いられてはこなかった。
【００２９】
リストｘの部分系列ｚとリストｙの部分系列ｚのなかで両方のリストに共通に含まれるものを共通部分系列（Ｃｏｍｍｏｎ  Ｓｕｂｓｅｑｕｅｎｃｅ）という。共通部分系列のなかでもっとも長いものを最大共通部分系列という。最大共通部分系列は英語では、Ｌｏｎｇｅｓｔ  Ｃｏｍｍｏｎ  Ｓｕｂｓｅｑｕｅｎｃｅと呼ばれ、頭文字をとってＬＣＳという。例えば、Ｘ＝（Ａ，Ｆ，Ｂ，Ｄ，Ｅ）とＹ＝（Ａ，Ｂ，Ｃ，Ｄ，Ｅ）のＬＣＳ（Ｘ，Ｙ）は（Ａ，Ｂ，Ｄ，Ｅ）である。なお、（Ａ，Ｂ，Ｃ）とは、あるユーザが、Ａ、Ｂ、Ｃという順にＷｅｂサイト内のページをアクセスしたときのアクセスルートを表すものとする。
【００３０】
一般的なＬＣＳ計算アルゴリズムを数１示す。系列ＸｉとＹｊのＬＣＳの長さをＣ［ｉ，ｊ］に格納する。
【００３１】
【数１】
2004152209.tif 000003
ここでｃｏｎｓｔｒａｃｔ（）はＣ［Ｍ，Ｎ］からＬＣＳを構成するアルゴリズムであるがここでは省略する。ＬＣＳアルゴリズムは、Ｍの文字列とＮの文字列の計算量はＯ（ＭＮ）時間で解くことができる。
【００３２】
２つのリストの中に同じ要素が同じ順序で出現したものが共通部分系列なので、最大共通部分系列（ＬＣＳ）が長いということは、２つのリストの類似性が高いと解釈できる。例えば、上の例ではＸとＹのＬＣＳの長さは４である。両方の文字列の長さに対してこの長さは十分に大きい。
【００３３】
よって２つのリストは類似性が高いと判断できる。ＬＣＳの特徴として、実際に（Ａ，Ｂ，Ｄ，Ｅ）というリストはＸ，Ｙともに連続して出現しておらず部分列として出現していることがあげられる。つまり、連続していなくとも類似性が高ければ共通シーケンスとして拾って来ることができる。
【００３４】
この発明の着眼点は以下の通りである。すなわち、Ｗｅｂサイトをアクセスする場合、目的とする情報を含むページに行き着くまでに試行錯誤を行うことになるが、そのパスはユーザごとに異なる。しかし、多くのユーザで共通するパターンも存在することは容易に想像できる。共通する部分を切り出すことでユーザの動向を判定し、例えば一連のアクセスの中で共通しない部分が構造として不適当であると判断することも可能となる。
【００３５】
以下、図面を参照して、本発明について詳細に説明する。
【００３６】
図１は本発明の概念を示す図である。
【００３７】
ユーザ１はインターネット２を介してＷｅｂサイト３にアクセスし、希望するＷｅｂページ４を閲覧するが、ユーザによってアクセスするページやそのアクセス順序が異なる。そこで、複数のユーザ１が利用するＷｅｂサイト３において、そのユーザのアクセスログを取得し（１０）、解析を行う場合に、ＬＣＳアルゴリズムを適用することで、アクセス履歴の頻出パターンを抽出し、より効率のよいＷｅｂの構成に改善することが可能となる（３０）。なお、アクセスログを解析する前段階の処理として、セッションＩＤを用いたユーザのトラッキングとＷｅｂの構造を前提としたデータ選択と精錬を行う。これをここでは「前処理」と呼ぶ（２０）。これは、多数のアクセスログにそのままＬＣＳアルゴリズムを適用したのでは効率が悪いため、ＬＣＳアルゴリズムを適用する前にアクセスログに対して前処理を行い、効率を改善するためである。
【００３８】
図２は本発明に係る  Ｗｅｂアクセスログ解析方法の全体の流れを示すフローチャートである。
【００３９】
まず、Ｗｅｂサーバにおいてユーザのアクセスログを取得し（ステップＳ１０）、後述の前処理を行い（ステップＳ２０）、ＬＣＳによる解析を行い（ステップＳ３０）、頻出アクセスパターンを抽出し、それを基にしてＷｅｂサイトの改善を行うものである（ステップＳ４０）。
【００４０】
次に、前述の「前処理」について詳細に説明する。
【００４１】
まず、前処理の手順を説明する前に、前処理の基本となる「セッションＩＤを用いたユーザのトラッキング」と「データ選択と精錬」についての考え方を説明しておく。
【００４２】
（１）アクセスログの前処理
Ｗｅｂの一般的なアクセスログは、一例として
『２１０．７２．２８．ｘｘ−−［１３／Ｊａｎ／２００２：０６：３５：３７＋０９００］”ＧＥＴ／￣ｙｏｋｏｔａ／ｉｎｄｅｘ．ｈｔｍｌ…』
のようになっており、“ＩＰアドレス”、“アクセス時刻”、“リクエストパス”、“リモートホスト名”、“使用しているＯＳおよびブラウザの種類”、“ドメイン名”などが情報として含まれている。更に、リファレンス情報やＣｏｏｋｉｅ  ＩＤ等も含まれることもある。
【００４３】
（１−ａ）セッションＩＤを用いたユーザのトラッキング
訪問者がどのようにサイト内を巡回したかという情報を得るためには訪問者ごとのリクエストＵＲＬを一つのまとまった集合としてユーザごとのクリックストリームに整理する必要がある。このためＩＰによってユーザを区別することになるが、それだけではプライベートＩＰのアクセス先から複数アクセスがあった場合に誰がアクセスしたかを区別することはできない。そこで、このＩＰを完全にユニークなものにするための技術であるセッションＩＤを用いる。
【００４４】
まずＷｅｂサイトの訪問者にはセッションＩＤというユニークなＩＤが割りあてられる。以下にセッションＩＤを用いた場合に残されるＷｅｂログの一例を示す。
【００４５】
『２１０．１７２．２２８．ｘｘ．２３４０５９３４５８０３９４８５３４−−［１３／Ｊａｎ／２００２：０６：３５：３７＋０９００］”ＧＥＴ…』
このセッションＩＤは、ユーザ側にクッキー（Ｃｏｏｋｉｅ）として保存するか、またはＵＲＬに埋め込むかの二通りの手法がある。
【００４６】
クッキーを用いるのが最適であるが、ユーザ側で拒否される可能性を考えると信頼性はＵＲＬに埋め込む方が高い。これによりセッションサポート機能で任意の数の変数をリクエスト間で受取ることが可能となる。
【００４７】
セッションＩＤ  自体が有限な数の集合である以上、完全にユニークであるとは言い切れないが、確率的に事実上ユニークと考えても差し支えない。さらに、セッションが変わることでも異なるセッションＩＤが配布されるため同一ユーザからの時間をおいたアクセスの区別も可能となる。一般的に一つのセッションは同一ユーザから３０分以上リクエストがない場合に別セッションとみなされる。
【００４８】
以上の技術を用いることによりＩＰ別に整理されたパスの集合は個々の訪問者のとったクリックストリームとみなすことができる。本発明ではこれらのユーザセッションを単位として各ＬＣＳを計算していくことにより、ユーザのアクセスパターンを抽出する。
【００４９】
（１−ｂ）データ選択と精錬
必要なデータは、ユーザセッションごとの一連のリクエストＵＲＬである。そのため個々のユーザを区別するためのＩＰアドレスと使用ＯＳ、ホスト名、ドメイン名、また、アクセスルート抽出に用いるリクエストＵＲＬとリファレンスＵＲＬ、さらにルート構成と解析の際に重要となる各リクエスト時刻が必要である。これら素データはＷｅｂサーバのアクセス記録であるため、クライアント側の操作状況や使用ブラウザの機能、あるいはネットワークの状態によって欠損値が多く発生する性質を持っている。例えば、一つのユーザセッションとして複数のウィンドウを開いている場合には、セッションＩＤだけでは、アクセスシーケンスを追うことができない。ログ中のリファレンスＵＲＬを用いることでシーケンスを構成できる場合もあるが、Ｗｅｂの構成と比較して明らかにシーケンスになり得ないアクセスパターンは、解析対象から取り除く必要がある。よって、より正確なアクセスルートを抽出するためには前処理として前述のような不必要なデータを除く必要がある。本発明では、この作業を「データを精錬する。」と呼ぶこととする。
【００５０】
以上を前提として、前処理の手順を図３に基づいて説明する。
【００５１】
まず、ユーザがＷｅｂサーバへアクセスした際、ログには様々な種類のリクエストファイルが残されているが、Ｗｅｂページ間の移動情報を構成するために必要なものはＨＴＭＬファイルのみであり、それ以外の画像ファイル、音声ファイルなどは必要としない。そこでＨＴＭＬ以外のリクエストファイルを除去する必要がある（ステップＳ２１）。
【００５２】
個々のユーザごとのセッションに分類するため前述したセッションＩＤを用いたユニークなＩＰアドレス、クライアントの使用ＯＳ、ブラウザ、ホスト名、ドメイン名等の情報から同一ユーザの特定を行う（ステップＳ２２）。この際に欠損値があるデータは質の悪いデータとして対象から外す。
【００５３】
ユーザを特定したら、そのユーザについてＷｅｂの構成と比較して明らかにシーケンスになり得ないアクセスパターンを解析対象から取り除く、「データの精錬」を行う（ステップＳ２３）。データ格納後、ユーザのページ間の移動情報であるアクセスルートを抽出する。アクセスルートにはアクセス元であるリファレンスＵＲＬとアクセスしたページのＵＲＬの相互を補間させる。以上により、すべてのユーザについての精錬されたアクセスルートを抽出し、前処理を終了する。
【００５４】
（２）ＬＣＳによるログ解析
次に、前処理された各ユーザのセッション毎のアクセスルートについてＬＣＳアルゴリズムによる解析を行う。まず抽出した各アクセスルートをＵＲＬ単位の列集合とみなす。そして各ルートごとに総あたり的にＬＣＳアルゴリズムを適用し、全ての組合せのＬＣＳの抽出を行う。作成したＬＣＳテーブルについて各ＬＣＳの統計を行い、高頻度なアクセスパターンの特定を試みる。そのアルゴリズムは以下の数２のようになり、計算量はセッション数をＳとするとＯ（Ｓ２）となる。
【００５５】
【数２】
2004152209.tif 000004
なお、図４は本発明に係るＬＣＳアルゴリズムによるアクセスログ解析のフローチャートである。図中、ステップＳ３３のＬＣＳ計算は前述の数１のプログラムによって行われる。また、ステップＳ３７の集計は、前記数２のプログラムによって行われる。
【００５６】
例として、数３のような６セッションにより構成されたアクセスルート集合例（ｒｏｕｔｅ［０］，…，ｒｏｕｔｅ［５］）を考える。
【００５７】
【数３】
2004152209.tif 000005
まず、ｒｏｕｔｅ［Ｉ］とｒｏｕｔｅ［Ｊ］の間において、Ｉ＝０，Ｊ＝１としてＬＣＳ計算を行う（ステップＳ３３）。それをＩ行Ｊ列のＬＣＳテーブルの（０行、１列）に格納する（ステップＳ３４）。本実施例では（Ａ，Ｃ，Ｅ）となる。次に、Ｊ＝２として（ステップＳ３２）、ｒｏｕｔｅ［０］とｒｏｕｔｅ［２］の間でＬＣＳ計算を行い、それをＬＣＳテーブルの（０行、２列）に格納する（ステップＳ３４）。本実施例では（Ａ，Ｃ，Ｄ，Ｅ）となる。
【００５８】
このようにして、Ｊ＝５まで計算を行うと、今度は、Ｉ＝１として、Ｊ＝０から５までのＬＣＳ計算を行い、ＬＣＳテーブルに格納する。以下、Ｉ＝５まですべての組み合わせについてＬＣＳ計算を行う。
【００５９】
この例に対するＬＣＳテーブルは次の表１のようになる。
【００６０】
【表１】
2004152209.tif 000006
次に、抽出した全ＬＣＳの集計を行う（ステップＳ３７）。これらをアクセスルートＬＣＳ集合と呼ぶことにする。上の例に対するアクセスルートＬＣＳ集合は、
｛（ＡＣＥ，８），（ＡＤ，２），（ＡＢＣＥ，１），（ＡＣＤＥ，１）｝
となる。この例では（Ａ，Ｃ，Ｅ）というＬＣＳが最頻出であるという結果が得られた。しかし、実際にＡ→Ｃ→Ｅと連続してたどったルートはない。それにもかかわらず、（Ａ，Ｃ，Ｅ）という頻出アクセスパターンが抽出されたことはＬＣＳによるアクセスログ解析のもつ大きな特徴である。
【００６１】
次に、Ｗｅｂサイトの管理者はこの情報を基にして、Ｗｅｂサイトの改善計画を作成する（ステップＳ３８）。例えば、Ｗｅｂ管理者が発信したい情報を含むページに誘導したい場合には、高頻度のＬＣＳ内にあるページ（上記の例ではＡ，Ｃ，Ｅのいずれかのページ）において、目的とするページへ誘導するリンク等を用意したり、シーケンスの間にそのページを含むように構成する方法が考えられる。また、ＬＣＳでグループ化されたページ群はアクセスされやすい一連のページであるため、そのいずれかのページに流れに沿ったバナー広告を置くことで、効率的にユーザの目に留めることができる。
【００６２】
【発明の効果】
これまでのアクセスログ解析で使われていた部分ルートでは分からなかったユーザのアクセス動向を抽出することが可能となり、Ｗｅｂサイトの構成をユーザの動向に合わせて最適化するのに有効な情報を得ることが可能となる。
【図面の簡単な説明】
【図１】本発明の概念図である。
【図２】全体の処理の流れを示すフローチャートである。
【図３】前処理のフローチャートである。
【図４】ＬＣＳ解析のフローチャートである。
【図５】ユーザのサーチ例を示す図である。
【符号の説明】
１  ユーザ（訪問者）
２  インターネット
３  Ｗｅｂサイト
４  Ｗｅｂページ
【図１】
2004152209.tif 000007
【図２】
2004152209.tif 000008
【図３】
2004152209.tif 000009
【図４】
2004152209.tif 000010
【図５】
2004152209.tif 000011