JP6456423B2 - 解析装置、解析方法、およびプログラム - Google Patents

Description

本発明は、解析装置、解析方法、およびプログラムに関する。

従来、ウェブページなどのユーザインターフェースとして機能する電子ページは、プログラマーやデザイナーなどの設計者が設計している。なお、近年、機械学習におけるハイパーパラメータを、ガウス過程などの確率的手法により決定する技術が知られている（例えば、特許文献１参照）。

特開２０１６−２１８８６９号公報

しかしながら、従来の技術では、ユーザインターフェースとなる画面を構成するコンポーネントのパラメータを自動的に決定することについて考慮されていなかった。

本発明は、上記の課題に鑑みてなされたものであり、ユーザインターフェースとなる画面を構成するコンポーネントのパラメータを自動的に決定することができる解析装置、解析方法、およびプログラムを提供することを目的としている。

本発明の一態様は、ユーザインターフェースとして機能する電子ページと、前記電子ページを閲覧したユーザによってとられた行動が評価された評価値とを取得する取得部と、前記取得部により取得された電子ページを構成する一以上のコンポーネントのパラメータと、前記取得部により取得された評価値とに基づいて、未知関数の最適化手法により、前記コンポーネントのパラメータとして好ましいパラメータである改善パラメータを決定する決定部と、を備える解析装置である。

本発明の一態様によれば、ユーザインターフェースとなる画面を構成するコンポーネントのパラメータを自動的に決定することができる解析装置、解析方法、およびプログラムを提供することができる。

第１実施形態における解析装置２００を含む解析システム１の一例を示す図である。 第１実施形態におけるサービス提供装置１００の構成の一例を示す図である。 ページログ情報Ｄ１の一例を示す図である。 ページ毎評価情報Ｄ２の一例を示す図である。 第１実施形態における解析装置２００の構成の一例を示す図である。 第１実施形態における解析側制御部２１０により実行される処理の一例を示すフローチャートである。 ＵＩページを模式的に示す図である。 パラメータ情報Ｄ３の一例を示す図である。 コンポーネントのパラメータを数値に変換する方法を説明するための図である。 第１実施形態における解析側制御部２１０により実行される処理の他の例を示すフローチャートである。 ベイズ的最適化手法による改善パラメータの決定方法を説明するための図である。 改善パラメータを再決定する方法を説明するための図である。 ページ毎関数情報Ｄ４の一例を示す図である。 過去の解析済みのＵＩページを用いて新規解析依頼を受けたＵＩページの最適パラメータを決定する方法を説明するための図である。 探索範囲ΔＸをベイズ的最適化手法を用いて決定する方法を説明するための図である。 実施形態のサービス提供装置１００および解析装置２００のハードウェア構成の一例を示す図である。

以下、本発明を適用した解析装置、解析方法、およびプログラムを、図面を参照して説明する。

［概要］
解析装置は、一以上のプロセッサによって実現される。解析装置は、ユーザインターフェースＵＩとして機能する電子ページと、電子ページを閲覧したユーザによってとられた行動が評価された評価値とを取得し、取得した電子ページから、電子ページを構成する一以上のコンポーネントのパラメータを抽出する。そして、解析装置は、抽出したパラメータと、取得した評価値とに基づいて、未知関数の最適化手法により、前記コンポーネントのパラメータとして好ましいパラメータである改善パラメータを決定し、この改善パラメータを出力する。これによって、ユーザインターフェースとなる画面（電子ページ）を構成するコンポーネントのパラメータを自動的に決定することができる。

未知関数の最適化手法とは、事前に形状が分からない未知関数（未知の目的関数）を最適化する手法であり、例えば、ベイズ的最適化手法、遺伝的アルゴリズム、差分進化法、焼きなまし法、グリッドサーチ法などである。以下の実施形態では、未知関数の最適化手法としてベイズ的最適化手法を適用した場合の例について説明するが、遺伝的アルゴリズムや差分進化法などの他の手法を用いてもよい。この場合、更に、分布推定アルゴリズム（Estimation of Distribution Algorithms）などを利用して、最適化手法として行われる探索処理の過程で得られるパラメータ（探索点）を基に、ある確率モデルに従う関数（分布）を求めてもよい。

ベイズ的最適化手法とは、上述したように、ある未知関数を導出する際に、何かしらの事前分布を仮定し、関数の事後分布を基に未知関数を最適化する手法である。本実施形態では、一例として、ガウス過程（Gaussian process）と呼ばれる確率過程（確率変数の集合）を用いて事前分布を仮定するベイズ的最適化手法について説明するが、他の確率過程を用いて事前分布を仮定してもよい。

＜第１実施形態＞
［全体構成］
図１は、第１実施形態における解析装置２００を含む解析システム１の一例を示す図である。第１実施形態における解析システム１は、例えば、一以上の端末装置１０と、サービス提供装置１００と、解析装置２００とを備える。これらの装置は、ネットワークＮＷを介して接続される。なお、サービス提供装置１００は、解析装置２００内に集約されていてもよい。

図１に示す各装置は、ネットワークＮＷを介して種々の情報を送受信する。ネットワークＮＷは、例えば、無線基地局、Ｗｉ‐Ｆｉアクセスポイント、通信回線、プロバイダ、インターネットなどを含む。なお、図１に示す各装置の全ての組み合わせが相互に通信可能である必要はなく、ネットワークＮＷは、一部にローカルなネットワークを含んでもよい。

端末装置１０は、ユーザによって使用される装置である。端末装置１０は、例えば、スマートフォンなどの携帯電話、タブレット端末、パーソナルコンピュータなどのコンピュータ装置である。

端末装置１０は、ユーザから所定の操作を受け付けると、ウェブブラウザを介して、サービス提供装置１００が提供するウェブサイトにアクセスする。例えば、サービス提供装置１００により提供されるウェブサイトは、検索サイトやショッピングサイト、ＳＮＳ（Social Networking Service）、メールサービス、情報提供サービス（例えばニュースや天気予報など）などを享受可能なウェブサイトである。

また、端末装置１０は、ユーザから所定の操作を受け付けると、予めインストールされたアプリケーションを介してサービス提供装置１００と通信を行い、アプリケーション上で表示或いは再生するコンテンツを取得する。コンテンツは、例えば、動画データや、画像データ、音声データ、テキストデータなどである。例えば、コンテンツが広告の場合、動画データは広告動画であり、画像データは広告画像である。これによって、端末装置１０には、アプリケーションを介して、上述した各種ウェブサイトにより提供されるサービスと同様のサービスが提供される。

サービス提供装置１００は、インターネット上において、ショッピングサイトや検索サイトなどのウェブサイトを提供するウェブサーバ装置であってよいし、アプリケーションが起動された端末装置１０と通信を行って、各種情報の受け渡しを行うアプリケーションサーバ装置であってもよい。

サービス提供装置１００によりサービスとして提供されるウェブページまたはアプリケーション用のページは、ユーザの操作を受け付けることが可能なユーザインターフェースＵＩとして機能する電子ページである。以下、ユーザインターフェースＵＩとして機能する電子ページを「ＵＩページ」と称して説明する。

ＵＩページには、例えば、入力フォーム、テキストフィールド、ボタンなどのコンポーネントが含まれる。例えば、ＵＩページに対するコンポーネントの位置や、大きさ、色彩などのパラメータは、ＵＩページの設計者が適宜設定するパラメータである。例えば、ＵＩページが検索サイトのウェブページである場合、コンポーネントのパラメータは、テキストフィールドにおいて表示する文字の最大数、フォント、色、大きさであったり、検索窓の位置、大きさ、その窓枠の色、窓枠内の背景色であったり、検索窓に入力されたクエリによって検索を開始するための検索ボタンの位置、大きさ、形状、ボタン領域内の文字（例えば「検索」という文字の内容である。また、コンポーネントがＵＩページに画像や動画、音声、アニメーションなどのコンテンツを配置して適宜再生するコンポーネントである場合、そのコンポーネントのパラメータは、コンテンツの種類やコンテンツの再生時間、コンテンツの動き（例えば、どういった画像をどのようなコマ送りで再生するのか）などを含んでよい。例えば、コンテンツが広告画像の場合、そのコンポーネントのパラメータは、広告のデザインや、サイズ、表示位置などを含む。なお、コンポーネントのパラメータは、上述した例に限られず、設計者が設定可能（プログラム可能）なパラメータであれば如何なる態様であってもよい。

解析装置２００は、サービス提供装置１００によりサービスとして提供されるウェブページまたはアプリケーション用のＵＩページを解析して、それらのＵＩページに含まれるコンポーネントのパラメータから、ベイズ的最適化手法などの未知関数の最適化手法を用いて、コンポーネントのパラメータとして好ましいパラメータである改善パラメータを決定する。

［サービス提供装置の構成］
以下、サービス提供装置１００および解析装置２００の各構成について説明する。図２は、第１実施形態におけるサービス提供装置１００の構成の一例を示す図である。図示のように、サービス提供装置１００は、例えば、サービス提供側通信部１０２と、サービス提供側制御部１１０と、サービス提供側記憶部１３０とを備える。

サービス提供側通信部１０２は、例えば、ＮＩＣ（Network Interface Card）などの通信インターフェースやＤＭＡ（Direct Memory Access）コントローラを含む。サービス提供側通信部１０２は、ネットワークＮＷを介して、端末装置１０または解析装置２００などと通信する。

サービス提供側制御部１１０は、例えば、サービス提供部１１２と、評価値導出部１１４と、解析依頼部１１６とを備える。サービス提供側制御部１１０の構成要素は、例えば、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）などのプロセッサがサービス提供側記憶部１３０に格納されたプログラムを実行することにより実現される。また、サービス提供側制御部１１０の構成要素の一部または全部は、ＬＳＩ（Large Scale Integration）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアにより実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。

サービス提供側記憶部１３０は、例えば、ＨＤＤ（Hard Disc Drive）、フラッシュメモリ、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）などにより実現される。サービス提供側記憶部１３０は、ファームウェアやアプリケーションプログラムなどの各種プログラムの他に、後述するページログ情報Ｄ１やページ毎評価情報Ｄ２などを記憶する。

サービス提供部１１２は、サービス提供側通信部１０２を用いて、サービスとしてＵＩページを端末装置１０に提供する。例えば、サービス提供装置１００がウェブサーバ装置である場合、サービス提供部１１２は、サービス提供側通信部１０２により端末装置１０からＨＴＴＰ（Hypertext Transfer Protocol）リクエストが受信されると、このリクエストに対応したウェブページとして、ＨＴＭＬ形式のテキストデータや、ＣＳＳ（Cascading Style Sheets）などのスタイルシート、画像データ、動画データ、音声データなどを、ＨＴＴＰリクエストの送信元である端末装置１０に送信する。これを受けて、端末装置１０の画面には、ウェブブラウザの機能によりＵＩページが描画される。

また、例えば、サービス提供装置１００がアプリケーションサーバ装置である場合、サービス提供部１１２は、アプリケーションが起動された端末装置１０からサービス提供側通信部１０２により所定のリクエストが受信されると、このリクエストに応じて、画像データ、動画データ、または音声データなどのコンテンツを、リクエストの送信元である端末装置１０に送信する。これらのコンテンツの配置位置などを決めるためのコンポーネントを含むスタイルシートは、端末装置１０によりアプリケーションのインストール時に取得されてもよいし、アプリケーションの実行中に取得されてもよい。端末装置１０に提供されるアプリケーションのスタイルシートは、例えば、ＨＴＭＬや、ＣＳＳ、ＪａｖａＳｃｒｉｐｔ（登録商標）などで記述されてよい。端末装置１０は、コンテンツを受信すると、画面に、スタイルシートに基づくＵＩページを描画する。

また、例えば、サービス提供部１１２は、ＵＩページがウェブサイトのあるウェブページである場合、インプレッション数および評価対象情報を、セッションごとに収集することでページログ情報Ｄ１を生成する。

図３は、ページログ情報Ｄ１の一例を示す図である。図示のように、ページログ情報Ｄ１は、例えば、ＵＩページを識別するためのＵＩページＩＤに対して、インプレッション数と、評価対象情報とが対応付けられた情報である。評価対象情報は、例えば、コンバージョン数やＵＩページの閲覧時間、クリック数などの各種情報を含む。

セッションとは、例えば、クッキー等の状態管理機能の有効期間である。例えば、ウェブサイト内のあるウェブページにアクセスしてから所定時間経過（タイムアウト）するまでの期間が一つのセッションとして扱われる。また、セッションとは、ウェブサイト内のあるウェブページにアクセスしてから、当該ウェブサイト内の他のウェブページ、または他のウェブサイト内のウェブページに切り替わるまでの期間であってもよい。また、セッションとは、ウェブサイト内のあるウェブページにアクセスしてから、当該ウェブページを表示するウェブブラウザを閉じるまでの期間であってもよい。

また、例えば、サービス提供部１１２は、ＵＩページがウェブサイトのあるウェブページである場合、ウェブサイトにおいてログインが継続している期間ごとに、インプレッション数および評価対象情報を収集することでページログ情報Ｄ１を生成してもよい。

また、例えば、サービス提供部１１２は、ＵＩページがアプリ用のページである場合、アプリのログインが継続している期間ごとに、インプレッション数および評価対象情報を収集することでページログ情報Ｄ１を生成してよい。

評価値導出部１１４は、上述した各種コンポーネントにより構成されるＵＩページを閲覧したユーザによってとられた行動が評価された評価値を、ＵＩページごとに導出する。例えば、ユーザによってとられた行動とは、ＵＩページにおいて行われた「検索」であったり、商品またはサービスの「購入」であったり、画像の「閲覧」であったり、動画または音声の「再生」であったりする。この行動に関する評価値は、例えば、コンバージョンが成立した回数に基づくＣＶＲ（Conversion Rate）として導出されてよい。コンバージョンとは、例えば、ＵＩページを提供する提供主が期待する所定の行動をとったことを意味する。例えば、評価値導出部１１４は、ＵＩページが検索サイトのウェブページである場合、「ＵＩページの検索窓にクエリを入力して検索ボタンを押した」という行動が取られた場合に、「コンバージョンが成立した」と判定する。そして、評価値導出部１１４は、例えば、コンバージョンの成立回数、すなわち、検索回数をＵＩページの閲覧数（インプレッション数）で除算した値をＣＶＲとして導出してよい。

また、評価値導出部１１４は、ＵＩページがショッピングサイトのウェブページである場合、ユーザによって「ＵＩページに掲載された商品またはサービスを購入した」という行動や「ＵＩページに掲載された商品またはサービスをショッピングカートに入れるために選択した」という行動が取られた場合に、「コンバージョンが成立した」と判定してよい。この場合、評価値導出部１１４は、例えば、コンバージョンの成立回数、すなわち、選択回数や購入数、購入額などをＵＩページの閲覧数で除算した値をＣＶＲとして導出してよい。

また、評価値導出部１１４は、ＣＶＲを導出するのに代えて、或いは加えて、ＣＴＲ（Click Through Rate）、ＣＰＭ（Cost Per Mill）、再生時間や閲覧時間、選択回数や購入回数といった他の指標値を評価値として導出してもよい。

そして、評価値導出部１１４は、導出した評価値と、その評価の対象としたＵＩページとを対応付けた情報を生成し、この生成した情報をページ毎評価情報Ｄ２として記憶部１３０に記憶させる。

図４は、ページ毎評価情報Ｄ２の一例を示す図である。図示のように、ページ毎評価情報Ｄ２は、例えば、ＵＩページを識別するためのＵＩページＩＤに対して、そのＵＩページの評価値が対応付けられた情報である。例えば、「ＡＡＡ」のＵＩページＩＤには、評価値としてＣＶＲが対応付けられ、「ＢＢＢ」のＵＩページＩＤには、評価値としてＣＴＲが対応付けられている。このように、各ＵＩページＩＤには、互いに異なる評価値が対応付けられてもよいし、同じ評価値が対応付けられてもよい。また、「ＤＤＤ」のＵＩページＩＤに対応付けられた評価値のように、互いに異なる複数の評価値が一つのＵＩページＩＤに対応付けられてもよい。

また、ページ毎評価情報Ｄ２において、評価値が対応付けられたＵＩページが改変された場合、評価値導出部１１４は、改変されたＵＩページの評価値を導出してよい。ＵＩページの「改変」とは、例えば、ＵＩページのデザインなどを変更するために、そのＵＩページのスタイルシートなどの記述内容（ソースコード）を変更して、ＵＩページ上のコンポーネントのパラメータである位置や大きさ、色彩などを変更することである。

例えば、プログラマーやデザイナーなどのＵＩページの設計者が、評価値導出部１１４により導出された評価値を参照して、現状のＵＩページから、よりコンバージョンが成立しやすいＵＩページへと改変するために、コンポーネントのパラメータを変更することが想定される。

例えば、ＵＩページ改変されると、サービス提供部１１２は、サービス提供側通信部１０２を用いて、改変されたＵＩページ（以下、改変済みＵＩページと称する）を、所定のユーザが操作する端末装置１０へと送信する。所定のユーザとは、例えば、不特定多数のユーザにより構成されたクラウドソーシングに参加するユーザである。クラウドソーシングとは、依頼した業務の協力を募ることである。例えば、サービス提供部１１２は、クラウドソーシングに参加するユーザの端末装置１０に対して、改変済みＵＩページを提供することで、提供する改変済みＵＩページにアクセスしてもらい、適宜検索やショッピングなどをしてもらう。

そして、評価値導出部１１４は、改変されたＵＩページがサービス提供部１１２により端末装置１０へと提供され、その端末装置１０を操作するユーザによって検索やショッピングなどがなされると、この改変されたＵＩページの評価値を導出する。例えば、評価値導出部１１４は、ページ毎評価情報Ｄ２において、その改変済みＵＩページのＩＤに対応付けられた評価値を更新してもよいし、改変済みＵＩページのＩＤを新たなＵＩページＩＤとして扱うことで、ページ毎評価情報Ｄ２に改変済みＵＩページごとに評価値のログをレコードとして追加してもよい。

解析依頼部１１６は、サービス提供側通信部１０２を用いて、サービス提供部１１２によりサービスとして提供されるＵＩページのうち、解析対象のＵＩページを解析依頼として解析装置２００に送信する。解析対象のＵＩページは、予めＵＩページの設計者が決めてもよいし、所定のアルゴリズムにより決定されてもよい。所定のアルゴリズムとは、例えば、所定期間におけるＵＩページの閲覧数（アクセス数）の減少度合が閾値以上のＵＩページを優先的に解析対象のＵＩページとする、といったアルゴリズムである。また、サービス提供装置１００により提供される全てのＵＩページが解析対象のＵＩページとして決定されてもよい。

また、解析依頼部１１６は、解析依頼として解析対象のＵＩページを解析装置２００に送信する前に、予め、評価値が導出されたＵＩページと、そのＵＩページの評価値を含むページ毎評価情報Ｄ２とを、サービス提供側通信部１０２を用いて解析装置２００に送信する。また、解析依頼部１１６は、解析依頼として解析対象のＵＩページを送信するタイミングで、評価値が導出されたＵＩページと、そのＵＩページの評価値を含むページ毎評価情報Ｄ２とを送信してもよい。以下の説明では、解析依頼がなされる前にページ毎評価情報Ｄ２が送信されるものとする。

［解析装置の構成］
図５は、第１実施形態における解析装置２００の構成の一例を示す図である。図示のように、解析装置２００は、例えば、解析提供側通信部２０２と、解析側制御部２１０と、解析側記憶部２３０とを備える。

解析提供側通信部２０２は、例えば、ＮＩＣなどの通信インターフェースやＤＭＡコントローラを含む。解析提供側通信部２０２は、例えば、ネットワークＮＷを介して、サービス提供装置１００などと通信する。

解析側制御部２１０は、例えば、取得部２１２と、パラメータ抽出部２１４と、パラメータ決定部２１６と、出力部２１８とを備える。解析側制御部２１０の構成要素は、例えば、ＣＰＵやＧＰＵなどのプロセッサが解析側記憶部２３０に格納されたプログラムを実行することにより実現される。また、解析側制御部２１０の構成要素の一部または全部は、ＬＳＩ、ＡＳＩＣ、またはＦＰＧＡなどのハードウェアにより実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。

解析側記憶部２３０は、例えば、ＨＤＤ、フラッシュメモリ、ＥＥＰＲＯＭ、ＲＯＭ、ＲＡＭなどにより実現される。解析側記憶部２３０は、ファームウェアやアプリケーションプログラムなどの各種プログラムの他に、ページ毎評価情報Ｄ２と、パラメータ情報Ｄ３と、ページ毎関数情報Ｄ４などを記憶する。パラメータ情報Ｄ３およびページ毎関数情報Ｄ４については後述する。

［事前処理］
以下、フローチャートに即して解析側制御部２１０の各構成要素について説明する。図６は、第１実施形態における解析側制御部２１０により実行される処理の一例を示すフローチャートである。本フローチャートの処理は、例えば、サービス提供装置１００により解析依頼として解析対象のＵＩページが送信される前に、事前処理としてＵＩページおよびページ毎評価情報Ｄ２が送信される場合に、解析側制御部２１０によって行われる処理を表している。この処理は、所定の周期で繰り返し行われてよい。

まず、取得部２１２は、解析提供側通信部２０２によってサービス提供装置１００からＵＩページと、そのＵＩページの評価値を含むページ毎評価情報Ｄ２とが受信されるまで待機し（Ｓ１００）、ＵＩページおよびページ毎評価情報Ｄ２が受信されると、これらの受信情報を取得した情報として解析側記憶部２３０に記憶させる。

例えば、取得部２１２は、サービス提供部１１２により提供されたＵＩページがウェブページである場合、ＨＴＭＬ形式のテキストデータやＣＳＳなどのスタイルシートをＵＩページとして取得してよい。また、取得部２１２は、サービス提供部１１２により提供されたＵＩページがアプリ用のページである場合、ＨＴＭＬや、ＣＳＳ、ＪａｖａＳｃｒｉｐｔなどで記述されたスタイルシートをＵＩページとして取得してよい。

次に、パラメータ抽出部２１４は、ページ毎評価情報Ｄ２と共に取得されたＵＩページの構文定義情報に基づいて、そのＵＩページを解析することで、ＵＩページを構成するコンポーネントのパラメータを抽出する（Ｓ１０２）。構文定義情報とは、例えば、ＵＩページがどのような言語で記述されているのか、或いはその言語の文法がどのような形式であるのかなどを定めた情報である。

例えば、パラメータ抽出部２１４は、ＵＩページとしてのテキストデータまたはスタイルシートの記述内容（ソースコード）を、その記述言語の形式文法に基づいて構文解釈することにより、コンポーネントのパラメータを抽出する。

図７は、ＵＩページを模式的に示す図である。図示の例では、ＵＩページは、検索サイトのウェブページである。このようなウェブページには、検索窓を表示するコンポーネントＣ１、検索ボタンを表示するコンポーネントＣ２、サービスのカテゴリー一覧を表示するコンポーネントＣ３、各種ニュース記事の要約文を表示するコンポーネントＣ４、検索頻度の高いクエリの情報を表示するコンポーネントＣ５、メールのアカウント情報や気象情報などを表示するコンポーネントＣ６などが含まれてよい。例えば、パラメータ抽出部２１４は、図７に例示するウェブページをパラメータの抽出対象とする場合、コンポーネントＣ１〜Ｃ６の各種パラメータを抽出する。

次に、パラメータ抽出部２１４は、抽出したコンポーネントのパラメータと、そのパラメータの抽出元であるＵＩページとを対応付けた情報を生成し、この情報をパラメータ情報Ｄ３として解析側記憶部２３０に記憶させる（Ｓ１０４）。これによって、本フローチャートの処理が終了する。

図８は、パラメータ情報Ｄ３の一例を示す図である。図示のように、例えば、パラメータ情報Ｄ３は、各ＵＩパラメータＩＤに対して、コンポーネントのパラメータとして抽出された種々のパラメータ（Ｐ１、Ｐ２、Ｐ３、…）が対応付けられた情報である。種々のパラメータとは、上述したように、あるコンポーネントの位置、大きさ、色、表示または再生するコンテンツの種類、コンテンツの動きなどである。これらのパラメータは、ＵＩページごとに種類が異なっていてよい。例えば、ＵＩページが検索サイトのウェブページであれば、検索ボタンの大きさや色などがパラメータとして抽出されてよいし、ＵＩページがショッピングサイトのウェブページであれば、商品またはサービスの画像の位置や種類、特徴量などがパラメータとして抽出されてよい。すなわち、コンポーネントのパラメータは、複数のパラメータを要素としてもつ多次元のパラメータであってもよいし、いずれか一つのパラメータを要素とした一次元のパラメータであってもよい。

このとき、各パラメータの値は、その値が０〜１の数値範囲となるように正規化されてよい。例えば、パラメータが「赤」「緑」「青」を基準としたＲＧＢカラーモデルによって表される場合、パラメータ抽出部２１４は、抽出したＲＧＢカラーモデルの輝度値を、その輝度値が取り得る最大値（２５５）で除算することで正規化してよい。

また、パラメータ抽出部２１４は、コンポーネントの位置や大きさ、色のように、スタイルシート上で既に数値として記述されているパラメータの他に、コンポーネントの形状やコンポーネントが表示するコンテンツの種類のように、必ずしも数値で記述されていない概念的なパラメータについては、ある規則に従って０〜１の数値に変換してよい。

図９は、コンポーネントのパラメータを数値に変換する方法を説明するための図である。図示のように、例えば、コンポーネントのパラメータが多角形の形状を示している場合、パラメータ抽出部２１４は、三角形のコンポーネントは０．１に変換し、四角形のコンポーネントは０．２に変換し、五角形のコンポーネントは０．３に変換する。このとき、各コンポーネントの形状に応じたパラメータの数値は、その形状数で除算されてよい。例えば、コンポーネントの形状が５種類の場合、各コンポーネントの形状に応じたパラメータの数値は１／５倍にされる。このように、パラメータ抽出部２１４は、概念的なパラメータについては、所定の規則に従って数値に変換してよい。なお、図示の例では、パラメータ抽出部２１４は、多角形の内角の和が大きくなるほど、その多角形をより大きな数値に変換したがこれに限られず、例えば、各形状を０〜１の数値範囲の任意の数値に変換してよい。

［解析処理］
図１０は、第１実施形態における解析側制御部２１０により実行される処理の他の例を示すフローチャートである。本フローチャートの処理は、例えば、解析依頼としてサービス提供装置１００により解析対象のＵＩページが送信された後に、解析側制御部２１０によって行われる処理を表している。この処理は、所定の周期で繰り返し行われてよい。

まず、取得部２１２は、解析提供側通信部２０２によってサービス提供装置１００から解析依頼として解析対象のＵＩページが受信されるまで待機し（Ｓ２００）、解析対象のＵＩページが受信されると、これらの受信情報を取得した情報として解析側記憶部２３０に記憶させる。

次に、パラメータ抽出部２１４は、取得部２１２により取得された解析対象のＵＩページからコンポーネントのパラメータを抽出する（Ｓ２０２）。上述したように、例えば、パラメータ抽出部２１４は、解析対象のＵＩページのテキストデータまたはスタイルシートの記述内容を、その記述言語の形式文法に基づいて構文解釈することにより、コンポーネントのパラメータを抽出してよい。

次に、パラメータ決定部２１６は、事前処理において生成されたパラメータ情報Ｄ３を参照し、パラメータ抽出部２１４により抽出されたコンポーネントのパラメータと同じパラメータに対応付けられた評価値を用いて、ベイズ的最適化手法により、解析対象のＵＩページのコンポーネントのパラメータとして、変更を推奨するパラメータである改善パラメータを決定する（Ｓ２０４）。また、パラメータ決定部２１６は、上述したＳ２０２の処理を省略し、事前処理において生成されたパラメータ情報Ｄ３から、解析対象のＵＩページのＵＩページＩＤを同じＩＤに対応付けられた評価値を用いて、ベイズ的最適化手法により、改善パラメータを決定してもよい。

図１１は、ベイズ的最適化手法による改善パラメータの決定方法を説明するための図である。例えば、コンポーネントのパラメータをＸとした場合、評価値は、パラメータＸを要素としたある未知関数（以下、ブラックボックス関数Ｆ（Ｘ）と称する）として表すことができる。上述したように、パラメータＸは、例えば、位置を表すパラメータＰ１、大きさを表すパラメータＰ２、色彩を表すパラメータＰ３、といったように複数のパラメータＰを要素としてもつ多次元のパラメータであってよい。

ブラックボックス関数Ｆ（Ｘ）を同定するために、パラメータ決定部２１６は、事前処理の過程で求められた実測値であるパラメータ情報Ｄ３の評価値を初期値として利用する。図示の例では、初期値としてパラメータＸａおよびＸｂが与えられている。図中μは、この２点の初期値を基にガウス過程（確率変数であるパラメータＸがＮ次元のガウス分布Ｎ（μ，σ^２）に従う）により推定されるブラックボックス関数Ｆ（Ｘ）の平均を表している。また、図中ＣＢは、ブラックボックス関数Ｆ（Ｘ）の平均μに標準偏差σ（分散σ^２）を加算した信頼区間（μ±σ）を表している。例えば、標準偏差σ（分散σ^２）は、ガウス過程を基に求められてよく、１σ、２σ、３σのように任意に決定されてよい。

例えば、パラメータ決定部２１６は、ブラックボックス関数Ｆ（Ｘ）の信頼区間ＣＢの大きさ（絶対値）を表すacquisition function（以下、ａ（Ｘ）と称する）が最も大きくなるパラメータＸ（不確実性の高いパラメータＸ）を、改善パラメータとして決定する。ａ（Ｘ）は、例えば、以下の数式（１）に基づいて求められてよい。式中Ｋは、カーネル関数を表す。

ａ（Ｘ）＝（μ（Ｘ）＋Ｋσ（Ｘ））…（１）

図示の例では、パラメータＸｃのときにａ（Ｘ）が最大となるため、パラメータ決定部２１６は、パラメータＸｃを改善パラメータに決定する。

次に、出力部２１８は、解析依頼に対する解析結果として、パラメータ決定部２１６により決定された改善パラメータを出力する（Ｓ２０６）。例えば、出力部２１８は、解析提供側通信部２０２を用いて、解析依頼として解析対象のＵＩページを送信したサービス提供装置１００に対して、改善パラメータを送信する。

これを受けて、サービス提供装置１００は、液晶ディスプレイなどの表示装置（不図示）に解析装置２００から受信した改善パラメータを表示する。例えば、サービス提供部１１２により提供されるＵＩページの設計者は、この改善パラメータを参考に解析対象のＵＩページのソースコードを書き直すなどして解析対象のＵＩページを改変する。

また、サービス提供部１１２が、解析装置２００から受信した改善パラメータに基づいて、解析対象のＵＩページを改変してもよい。例えば、サービス提供部１１２は、解析対象のＵＩページのＨＴＭＬ形式のテキストデータにおいて、ＨＴＭＬの木構造を変化させることで、解析対象のＵＩページを改変してよい。

サービス提供装置１００のサービス提供部１１２は、改善パラメータに基づいて解析対象のＵＩページが改変されると、サービス提供側通信部１０２を用いて、改変済みＵＩページを端末装置１０に送信する。そして、サービス提供装置１００の評価値導出部１１４は、改変済みＵＩページの評価値を導出する。

次に、解析装置２００の取得部２１２は、解析提供側通信部２０２を用いて、サービス提供装置１００から改変済みＵＩページの評価値を取得する（Ｓ２０８）。

次に、パラメータ決定部２１６は、改変済みＵＩページの評価値（実測値）を用いて、ベイズ的最適化手法により、改善パラメータを再決定する（Ｓ２１０）。

図１２は、改善パラメータを再決定する方法を説明するための図である。例えば、上述した図１１において例示したように、パラメータＸｃが改善パラメータに決定され、このパラメータＸｃとなるように解析対象のＵＩページのコンポーネントのパラメータが改変された場合、パラメータ決定部２１６は、初期値であるパラメータＸａおよびＸｂと、前回改善パラメータとして決定したパラメータＸｃとを固定点（確率的に求めた推測値ではなく観測したい事象の実測値）として用いて、ガウス過程によりブラックボックス関数Ｆ（Ｘ）の平均μを推定する。そして、パラメータ決定部２１６は、ａ（Ｘ）が最も大きくなるパラメータＸを、改善パラメータとして再度決定する。図示の例では、パラメータＸｄのときにａ（Ｘ）が最大となるため、パラメータ決定部２１６は、パラメータＸｄを改善パラメータに決定する。

このとき、パラメータ決定部２１６は、設計者がコンポーネントのパラメータＸを決定する際に考慮する知見に基づいて、改善パラメータを決定してもよい。例えば、これまでの設計で培った知識として、検索ボタンの色が緑色である場合、他の色の時と比べてＣＶＲなどの評価値が向上しやすいという知見があるとする。この場合、パラメータ決定部２１６は、検索ボタンの色に関するパラメータにおいて、緑色のパラメータ値に対して予め評価値が小さくなるような重みを付与してよい。これによって、例えば、緑色以外の色が改善パラメータとして決定されやすくなる。このように、パラメータ決定部２１６は、既に評価値との関係が明らかになっているパラメータについては、そのパラメータを改善パラメータとして決定せずに、未だ評価値との関係が十分に明らかでないパラメータについては優先的に改善パラメータとして決定することで、従来の常識にとらわれない革新的なＵＩページを、より効率良く生成させることができる。

次に、出力部２１８は、解析提供側通信部２０２を用いて、パラメータ決定部２１６により再度決定された改善パラメータを、前回改善パラメータを出力したサービス提供装置１００に対して出力する（Ｓ２１２）。

次に、解析側制御部２１０は、改善パラメータを決定する演算処理の回数が所定回数に達したか否かを判定し（Ｓ２１４）、演算回数が所定回数に達していない場合、上述したＳ２０８に処理を移す。これによって、演算回数が所定回数に達するまでの間に、改善パラメータが繰り返し決定されるのに応じて、解析対象のＵＩページのコンポーネントのパラメータが改変され、改変済みＵＩページが生成される。改善パラメータが繰り返し決定されるのに応じて生成される改変済みＵＩページは、「各世代の電子ページ」の一例である。例えば、改善パラメータの決定する演算処理が一回繰り返される毎に、ＵＩページの「世代」が一世代分更新される。

サービス提供装置１００のサービス提供部１１２は、改変済みＵＩページが生成される度に、各世代の改変済みＵＩページをクラウドソーシングに参加するユーザの端末装置１０に送信する。そして、評価値導出部１１４は、各世代の改変済みＵＩページごとに評価値を導出する。

これによって、パラメータＸに応じてどの程度の評価値が得られるのかが判明するため、パラメータ決定部２１６は、ブラックボックス関数Ｆ（Ｘ）がどういった傾向の関数であるのかを導出することができる。

一方、演算回数が所定回数に達した場合、解析側制御部２１０は、解析対象のＵＩページと、ブラックボックス関数Ｆ（Ｘ）とを対応付けた情報を、ページ毎関数情報Ｄ４として解析側記憶部２３０に記憶させる（Ｓ２１６）。

図１３は、ページ毎関数情報Ｄ４の一例を示す図である。例えば、ページ毎関数情報Ｄ４は、各ＵＩページのＩＤに対して、そのＵＩページのパラメータＸと、ブラックボックス関数Ｆ（Ｘ）とが対応付けられた情報である。

次に、出力部２１８は、ブラックボックス関数Ｆ（Ｘ）において、評価関数（すなわちＦ（Ｘ））が閾値以上となるパラメータＸを、最適パラメータ（改善パラメータの一例）としてこれまで改善パラメータを出力してきたサービス提供装置１００に対して出力する（Ｓ２１８）。これを受けて、サービス提供装置２００は、最適パラメータを基に評価値がより大きくなるように改変されたＵＩページを端末装置１０に提供することができる。これによって、本フローチャートの処理が終了する。

以上説明した第１実施形態によれば、ＵＩページと、ＵＩページを閲覧したユーザによってとられた行動が評価された評価値とを取得する取得部２１２と、取得部２１２により取得されたＵＩページを構成する一以上のコンポーネントのパラメータと、取得部２１２により取得された評価値とに基づいて、ベイズ的最適化手法などの未知関数の最適化手法により、ＵＩページのコンポーネントのパラメータとして好ましいパラメータである改善パラメータを決定するパラメータ決定部２１６と、を備えることにより、ユーザインターフェースとなる画面（すなわちＵＩページ）を構成するコンポーネントのパラメータを自動的に決定することができる。

例えば、検索窓はＵＩページの上部に設けるのが一般的である。これに対して、本実施形態では、ベイズ的最適化手法を用いて検索窓のコンポーネントのパラメータを決定するため、例えば、ＵＩページの下部や中段などに検索窓が位置するように改善パラメータが決定され得る。これによって、設計者がこれまで見逃してきたパラメータを改善パラメータとして決定することができ、従来の常識を覆すような革新的なＵＩページを生成することができる。

また、上述した第１実施形態によれば、パラメータ抽出部２１４がＵＩページを解析してパラメータを抽出するため、ＵＩ設計者が意識せずに設計したパラメータについても評価値を向上させる可能性のある改善パラメータとして決定することができる。言い換えれば、設計者は、従来通りにコンポーネントのパラメータを意識せずにＵＩページを設計することができると共に、解析装置２００による解析結果を参照することで、その設計したＵＩページのコンポーネントのパラメータを定量的に評価することができる。

また、上述した第１実施形態によれば、例えば、未知関数の最適化手法として、ベイズ的最適化手法を用いた場合、ガウス過程に基づくブラックボックス関数（連続性のある関数）を仮定し、そのブラックボックス関数において不確実性の高いパラメータを改善パラメータに決定するため、上述したような、ＵＩページの改変に対してユーザがどういった行動をとったのかという一連の試行処理（ライブテスト）に時間を要する場合、試行処理の結果が大量に必要な遺伝的アルゴリズムなどの他の未知関数の最適化手法と比べて、より速く目的関数であるブラックボックス関数を最適化することができる。

また、上述した第１実施形態によれば、解析したＵＩページのコンポーネントのパラメータと評価値との関係を示すブラックボックス関数を、そのＵＩページ毎に対応付けて記憶するため、ベイズ的最適化手法などの未知関数の最適化手法により得られた知見として、どのパラメータを変更すれば評価値を向上させることができるのかを、設計者間で共有することができる。これによって、例えば、ＵＩページの設計知識の乏しい設計者であっても、高い評価値を得ることが可能なＵＩページを設計することができる。

＜第２実施形態＞
以下、第２実施形態について説明する。第２実施形態の解析装置２００は、サービス提供装置２００または他のサービス提供装置から、新規の解析依頼として解析対象のＵＩページを取得した場合、過去の解析済みのＵＩページに基づいて、新規解析依頼を受けたＵＩページの最適パラメータを決定する点で上述した第１実施形態と相違する。以下、第１実施形態との相違点を中心に説明し、第１実施形態と共通する点については説明を省略する。なお、第２実施形態の説明において、第１実施形態と同じ部分については同一符号を付して説明する。

図１４は、過去の解析済みのＵＩページを用いて新規解析依頼を受けたＵＩページの最適パラメータを決定する方法を説明するための図である。第２実施形態におけるパラメータ抽出部２１４は、例えば、取得部２１２によって、サービス提供装置２００または他のサービス提供装置から、新規に解析依頼として解析対象のＵＩページが取得された場合、新規解析依頼のＵＩページからコンポーネントのパラメータを抽出する。そして、パラメータ決定部２１６は、既に解析依頼を受けたＵＩページのブラックボックス関数Ｆ（Ｘ）を含むページ毎関数情報Ｄ４を参照し、パラメータ抽出部２１４により抽出されたパラメータ（新規解析依頼のＵＩページのパラメータ）と同じパラメータを要素とするブラックボックス関数Ｆ（Ｘ）を選択する。「パラメータが同じ」とは、例えば、ＵＩページ上に同じコンポーネントが配置されているような状況を意味する。言い換えれば、パラメータ決定部２１６は、既に解析依頼を受けたＵＩページのうち、新規解析依頼のＵＩページのコンポーネントと同じコンポーネントを含むＵＩページのブラックボックス関数Ｆ（Ｘ）を選択する。

例えば、新規解析依頼のＵＩページとして、検索サイトのウェブページＡが提供された場合、パラメータ決定部２１６は、ウェブページＡと同様に検索ボタンや検索窓などのコンポーネントを含むＵＩページＢのパラメータに対応したブラックボックス関数Ｆ（Ｘ）を選択する。

図示の例では、新規解析依頼のＵＩページからパラメータＸ_Ｌが抽出されている。この場合、パラメータ決定部２１６は、パラメータＸ_Ｌを要素とするブラックボックス関数Ｆ（Ｘ_Ｌ）を選択する。出力部２１８は、パラメータ決定部２１６により選択されたブラックボックス関数Ｆ（Ｘ_Ｌ）において評価値が閾値以上となるパラメータを、最適パラメータとして新規解析依頼を受けた装置へと出力する。これによって、ベイズ的最適化手法により未知の評価値のパラメータを改善パラメータとして決定し、その改善パラメータに反映させたＵＩページの評価値（実測値）を取得することを繰り返すことで、未解析のＵＩページに対応したブラックボックス関数Ｆ（Ｘ）を導出するという処理を省略することができる。

以上説明した第２実施形態によれば、新たに解析対象のＵＩページを取得した場合、過去の解析済みのＵＩページに基づいて、新たなＵＩページの最適パラメータを決定することにより、ユーザインターフェースＵＩに関するパラメータ（コンポーネントのパラメータ）を決定する際の処理負荷を軽減することができる。

＜第３実施形態＞
以下、第３実施形態について説明する。第３実施形態の解析装置２００は、ＵＩページの改善パラメータを決定する際に、改善パラメータの取り得る範囲（以下、探索範囲ΔＸと称する）を、ベイズ的最適化手法を用いて決定する点で上述した第１および第２実施形態と相違する。以下、第１および第２実施形態との相違点を中心に説明し、第１および第２実施形態と共通する点については説明を省略する。なお、第３実施形態の説明において、第１および第２実施形態と同じ部分については同一符号を付して説明する。

図１５は、探索範囲ΔＸをベイズ的最適化手法を用いて決定する方法を説明するための図である。例えば、第３実施形態のパラメータ決定部２１６は、改善パラメータの探索範囲ΔＸを設定し、設定した探索範囲ΔＸにおいて、ａ（Ｘ）が最も大きくなるパラメータＸを改善パラメータとして決定する。このとき、パラメータ決定部２１６は、探索範囲ΔＸの範囲幅または設定位置を要素とし、ブラックボックス関数Ｆ（Ｘ）が一意に同定されるまでの処理時間などを評価値としたときの関数をベイズ的最適化手法により導出する。これによって、より速やかにブラックボックス関数Ｆ（Ｘ）を導出することが可能な処理条件を見出すことができる。

＜その他の実施形態＞
以下、その他の実施形態（変形例）について説明する。上述した実施形態における解析装置２００は、解析依頼として受信した解析対象のＵＩページのコンポーネントのパラメータとして好ましい改善パラメータを決定する際、または解析対象のＵＩページのコンポーネントの最適パラメータを決定する際に、過去に解析したＵＩページのコンポーネントのパラメータを利用してもよい。

例えば、解析依頼として、あるアプリケーションにより提供される電子ページが受信された場合、パラメータ決定部２１６は、このアプリ用の電子ページのコンポーネントのパラメータＸから、ベイズ的最適化手法により、ブラックボックス関数Ｆ（Ｘ）を導出する際に、過去に解析したＵＩページとして、あるウェブページのコンポーネントのパラメータＸから導出したブラックボックス関数Ｆ（Ｘ）を利用する。このとき、ウェブページのコンポーネントのパラメータＸの種類（例えば、位置や大きさ、色彩など）は、アプリケーション用の電子ページのコンポーネントのパラメータに含まれているものとする。

そして、出力部２１８は、ウェブページのコンポーネントのパラメータＸから導出したブラックボックス関数Ｆ（Ｘ）において、評価値が閾値以上となる最適パラメータを抽出し、これをアプリケーション用の電子ページの最適パラメータとしてサービス提供装置１００に送信する。

これを受けて、サービス提供装置１００のサービス提供部１１２は、ウェブページのコンポーネントのパラメータＸを基にした最適パラメータを、アプリケーション用の電子ページの最適パラメータに変換する。

例えば、最適パラメータがウェブページでのコンポーネントのサイズを指定している場合、サービス提供部１１２は、ウェブページにおいて最適とされるコンポーネントのサイズを、アプリケーション用のページサイズにリスケーリングする。より具体的には、ウェブページにおける最適パラメータは、そのウェブページにおけるページサイズなどで正規化されているため、サービス提供部１１２は、（ウェブページの最適パラメータの数値：正規化時に分母としたウェブページのサイズ）＝（未知数Ｚ：正規化時に分母とするアプリ用ページのサイズ）という関係式を解くことで、未知数Ｚとして、アプリ用ページにおける最適パラメータの数値を導出する。これによって、ウェブページにおける最適パラメータを、アプリ用の電子ページにおける最適パラメータに変換することができる。

なお、上述した例では、未解析のアプリ用の電子ページにおけるコンポーネントのパラメータのモデル（ブラックボックス関数Ｆ（Ｘ））に、解析済みのウェブページにおけるコンポーネントのパラメータのモデルを適用したがこれに限られず、未解析のウェブページにおけるコンポーネントのパラメータのモデルに、解析済みのアプリ用の電子ページにおけるコンポーネントのパラメータのモデルを適用してもよい。

また、上述した例では、パラメータ決定部２１６が、異種ページのコンポーネントのパラメータのモデルであるブラックボックス関数Ｆ（Ｘ）を利用して、解析依頼を受けた解析対象のＵＩページのコンポーネントの最適パラメータを決定したがこれに限られず、解析対象のＵＩページのコンポーネントのパラメータとして好ましいパラメータである改善パラメータを決定してもよい。

このような処理により、ウェブページとアプリケーション用のページのように、サービスとして提供される電子ページの形態が異なっている場合であっても、両者の間でベイズ的最適化手法のモデルであるブラックボックス関数Ｆ（Ｘ）を共用することができる。

また、上述した実施形態において、例えば、ユーザが端末装置１０を利用して、複数のＵＩページにアクセスした場合、解析装置２００は、複数のＵＩページのそれぞれのコンポーネントのパラメータと、各ＵＩページの評価値とを用いて、ベイズ的最適化手法により、各ページのコンポーネントの改善パラメータを決定してよい。

例えば、ユーザが端末装置１０を利用して、あるＵＩページＡにアクセスし、そのＵＩページにリンクされたＵＩページＢにアクセスし、更に、ＵＩページＢにリンクされたＵＩページＣにアクセスしたとする。この場合、サービス提供装置１００の評価値導出部１１４は、各ＵＩページを閲覧したユーザの行動に応じた評価値として、各ＵＩページの滞在時間（回遊時間）を導出する。そして、解析依頼部１１６は、サービス提供側通信部１０２を用いて、上記のアクセスされた各ＵＩページを解析対象のＵＩページとして解析装置２００に送信する。

これを受けて、解析装置２００のパラメータ抽出部２１４は、解析対象の複数のＵＩページのそれぞれからコンポーネントのパラメータを抽出する。そして、パラメータ決定部２１６は、各ＵＩページについて、抽出されたコンポーネントのパラメータと、各ＵＩページの滞在時間とを基に、ベイズ的最適化手法により、ブラックボックス関数Ｆ（Ｘ）を求め、このブラックボックス関数Ｆ（Ｘ）において不確実性の高いパラメータを改善パラメータとして決定する。そして、出力部２１８は、各改善パラメータをサービス提供装置１００に送信する。これによって、サービス提供装置１００側において、複数のＵＩページが改変される。このような処理をサービス提供装置１００と解析装置２００との間で所定回数繰り返すことで、各ＵＩページにおいて、滞在時間を延ばしたり、または短くしたりするようなコンポーネントの最適パラメータを見出すことができる。

＜ハードウェア構成＞
上述した実施形態の解析システム１に含まれる複数の装置のうち、サービス提供装置１００および解析装置２００は、例えば、図１６に示すようなハードウェア構成により実現される。図１６は、実施形態のサービス提供装置１００および解析装置２００のハードウェア構成の一例を示す図である。

サービス提供装置１００は、ＮＩＣ１００−１、ＣＰＵ１００−２、ＲＡＭ１００−３、ＲＯＭ１００−４、フラッシュメモリやＨＤＤなどの二次記憶装置１００−５、およびドライブ装置１００−６が、内部バスあるいは専用通信線によって相互に接続された構成となっている。ドライブ装置１００−６には、光ディスクなどの可搬型記憶媒体が装着される。二次記憶装置１００−５、またはドライブ装置１００−６に装着された可搬型記憶媒体に格納されたプログラムがＤＭＡコントローラ（不図示）などによってＲＡＭ１００−３に展開され、ＣＰＵ１００−２によって実行されることでサービス提供側制御部１１０が実現される。ＣＰＵ１００−２が参照するプログラムは、ネットワークＮＷを介して他の装置からダウンロードされてもよい。

解析装置２００は、ＮＩＣ２００−１、ＣＰＵ２００−２、ＲＡＭ２００−３、ＲＯＭ２００−４、フラッシュメモリやＨＤＤなどの二次記憶装置２００−５、およびドライブ装置２００−６が、内部バスあるいは専用通信線によって相互に接続された構成となっている。ドライブ装置２００−６には、光ディスクなどの可搬型記憶媒体が装着される。二次記憶装置２００−５、またはドライブ装置２００−６に装着された可搬型記憶媒体に格納されたプログラムがＤＭＡコントローラ（不図示）などによってＲＡＭ２００−３に展開され、ＣＰＵ２００−２によって実行されることで、解析側制御部２１０が実現される。解析側制御部２１０が参照するプログラムは、ネットワークＮＷを介して他の装置からダウンロードされてもよい。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何ら限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

１…解析システム、１０…端末装置、１００…サービス提供装置、１０２…サービス提供側通信部、１１０…サービス提供側制御部、１１２…サービス提供部、１１４…評価値導出部、１１６…解析依頼部、１３０…サービス提供側記憶部、Ｄ１…ページ毎評価情報、２００…解析装置、２０２…解析側通信部、２１０…解析側制御部、２１２…取得部、２１４…パラメータ抽出部、２１６…パラメータ決定部、２１８…出力部、２３０…解析側記憶部、Ｄ２…パラメータ情報、Ｄ３…ページ毎関数情報、ＮＷ…ネットワーク

Claims (7)

1. ユーザインターフェースとして機能する電子ページと、前記電子ページを閲覧したユーザによってとられた行動が評価された評価値とを取得する取得部と、
   前記取得部により取得された電子ページを構成する一以上のコンポーネントのパラメータと、前記取得部により取得された評価値とに基づいて、未知関数の最適化手法により、前記コンポーネントのパラメータとして好ましいパラメータである改善パラメータを決定する決定部と、
   を備える解析装置。
2. 前記取得部により取得された電子ページの構文定義情報に基づいて、前記電子ページから前記パラメータを抽出する抽出部を備え、
   前記決定部は、前記抽出部により抽出されたパラメータと、前記取得部により取得された評価値とを用いて、前記改善パラメータを決定する、
   請求項１に記載の解析装置。
3. 前記決定部により決定された前記改善パラメータを出力する出力部を更に備え、
   前記取得部は、前記コンポーネントのパラメータが、前記出力部により出力された改善パラメータに変更された改変済み電子ページと、前記改変済み電子ページを閲覧したユーザによってとられた行動が評価された評価値とを取得し、
   前記決定部は、前記改善パラメータが繰り返し決定されるのに応じて生成された各世代の電子ページに関する前記評価値を固定点として、前記未知関数の最適化手法により、前記改善パラメータを新たに決定する、
   請求項１または２に記載の解析装置。
4. 前記決定部は、
   前記改善パラメータを繰り返し決定した後、対象とした電子ページに対応付けて、前記パラメータを要素として前記評価値を返す関数を導出し、
   前記取得部により、未だ改善パラメータが決定されていない新たな電子ページが取得された場合、前記導出した関数のうち、前記新たな電子ページを構成する一以上のコンポーネントと同じコンポーネントを有する他の電子ページに基づいて導出された関数を用いて、前記新たな電子ページの改善パラメータを決定する、
   請求項３に記載の解析装置。
5. 前記決定部は、前記改善パラメータを決定する際に、前記改善パラメータの取り得る範囲を、前記未知関数の最適化手法を用いて決定する、
   請求項１から４のうちいずれか１項に記載の解析装置。
6. コンピュータが、
   ユーザインターフェースとして機能する電子ページと、前記電子ページを閲覧したユーザによってとられた行動が評価された評価値とを取得し、
   前記取得した電子ページを構成する一以上のコンポーネントのパラメータと、前記取得した評価値とに基づいて、未知関数の最適化手法により、前記コンポーネントのパラメータとして好ましいパラメータである改善パラメータを決定する、
   解析方法。
7. コンピュータに、
   ユーザインターフェースとして機能する電子ページと、前記電子ページを閲覧したユーザによってとられた行動が評価された評価値とを取得させ、
   前記取得させた電子ページを構成する一以上のコンポーネントのパラメータと、前記取得させた評価値とに基づいて、未知関数の最適化手法により、前記コンポーネントのパラメータとして好ましいパラメータである改善パラメータを決定させる、
   プログラム。

Images