三田ブログ

JiroSearch がリリースされたが、 手順の詳細など、 正式ページに出ていない情報をここに書き足していく予定ですので、よろしくお願いします。

環境によっては、 タイトルのようなエラーが出ることがある。

[webmaster]$ ant createIndex
Unknown argument: -cp
ant [options] [target [target2 [target3] ...]]
Options:

これは ant のデフォルト設定が何かを邪魔しているのが原因らしい。 その場合は、 --noconfig というオプションを付けると実行できる。 例えば、こんな感じ。

ant --noconfig filecrawl

次のようになる。

[webmaster]$ ant --noconfig createIndex
Buildfile: build.xml

createIndex:
     [java] 18:16:05,981  INFO org.springframework.core.CollectionFactory:76
         - JDK 1.4+ collections available
     [java] 18:16:06,003  INFO org.springframework.core.CollectionFactory:80
         - Commons Collections 3.x available
     [java] 18:16:06,136  INFO org.springframework.beans.factory.xml.XmlBeanDefinitionReader:347
         - Loading XML bean definitions from file [/usr/local/jiro/search/search/WEB-INF/applicationContext.xml]
     [java] 18:16:07,475  INFO org.springframework.beans.factory.xml.XmlBeanDefinitionReader:347
         - Loading XML bean definitions from file [/usr/local/jiro/search/search/WEB-INF/systemProperties.xml]
     [java] 18:16:07,601  INFO org.springframework.context.support.AbstractRefreshableApplicationContext:100
         - Bean factory for application context [org.springframework.context.support.FileSystemXmlApplicationContext;hashCode=7043360]: 
        org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [sessionBean,queries,highlightFilter,searchBean,fileCrawler,fileInfoUpdater,stubSearcher,analyzer,searcher,documentSearcher,htmlDocumentFactory,textDocumentFactory,indexUpdater,indexManager,xmlParser,propertyParser,propertyXmlWriter,fileInfoXmlWriter,systemProperties,facade,simpleTextParser,mappingFilter,tagMapper,titleParser,bodyParser,webPageParser]; root of BeanFactory hierarchy
     [java] 18:16:07,625  INFO org.springframework.context.support.AbstractApplicationContext:322
         - 26 beans defined in application context [org.springframework.context.support.FileSystemXmlApplicationContext;hashCode=7043360]
     [java] 18:16:07,703  INFO org.springframework.context.support.AbstractApplicationContext:473
         - Unable to locate MessageSource with name 'messageSource': using default [org.springframework.context.support.DelegatingMessageSource@1db7df8]
     [java] 18:16:07,715  INFO org.springframework.context.support.AbstractApplicationContext:495
         - Unable to locate ApplicationEventMulticaster with name 'applicationEventMulticaster': 
        using default [org.springframework.context.event.SimpleApplicationEventMulticaster@79717e]
     [java] 18:16:07,725  INFO org.springframework.beans.factory.support.DefaultListableBeanFactory:261
         - Pre-instantiating singletons in factory [org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [sessionBean,queries,highlightFilter,searchBean,fileCrawler,fileInfoUpdater,stubSearcher,analyzer,searcher,documentSearcher,htmlDocumentFactory,textDocumentFactory,indexUpdater,indexManager,xmlParser,propertyParser,propertyXmlWriter,fileInfoXmlWriter,systemProperties,facade,simpleTextParser,mappingFilter,tagMapper,titleParser,bodyParser,webPageParser]; root of BeanFactory hierarchy]
     [java] 18:16:26,514  INFO jp.co.crm.util.xml.XmlWriterImpl:35
         - write: filename = /usr/local/jiro/search/fileInfo.xml

BUILD SUCCESSFUL
Total time: 22 seconds

これは間違いなく仕様通りの動作なのだが、 検索語を入れたときに、 タグで絞り込まれていることに気付かずに指定してしまって、 期待した結果が得られないことがある。 つまり、ユーザビリティ的な問題がないわけではない。

名案がないのだが、 例えば[検索]というボタンを [絞り込んで検索][タグを解除して検索] の2つにするという方法は可能である。 なお、検索してからタグを解除するのは単にタグの欄を空白にしてやればいい。

JiroSearch は検索ユーザーをセッションで管理しているので、 ブラウザを閉じたりセッションタイムアウトするまでの間の検索履歴を使おうと思えば使える。 パンくずのようなものを残しておけば、 少し前の条件に戻って検索するというUIも実装可能だと思う。

JiroSearch は Spring Framework を使っているので、 設定の大部分を applicationContext.xml を編集して変更することができる。 JiroSearch は Lucene の CJKAnalyzer を使っているが、 これを JapaneseAnalyzer を使うように変更する方法は次の通り。

WEB-INF/applicationContext.xml 内に、次のような記述がある。

  <bean id="analyzer"
    class="org.apache.lucene.analysis.cjk.CJKAnalyzer"/>

これを、次のように変更する。

  <bean id="analyzer"
    class="org.apache.lucene.analysis.ja.JapaneseAnalyzer">
    <constructor-arg type="java.lang.String"
      value="/usr/local/jiro/sen-1.2.2.1/conf/sen.xml"/>
  </bean>

変更箇所はここだけで、 Java のプログラムの再コンパイル等は一切必要ない。 ただし、 analyzer を入れ替えたら今までの index は使えないので、 index の再構築が必要になる。 具体的には、 fileInfo.xml と、index ディレクトリの中身を削除して、 ant で fileCrawler、createIndex を実行する。 もちろん、sen を事前にインストールしておく必要がある。

sen は環境変数をみてインストールされたディレクトリを判定する仕組だが、 コンストラクタに設定ファイル sen.xml を指定すれば、 環境変数を指定しなくても使うことができる。 Spring Framework でコンストラクタを使った初期化を行うには、 前述の例のように constructor-arg を使う。 例は /usr/local/jiro/ に sen1.2.2.1 をインストールした場合のもので、 他の場所にインストールした場合は、 インストールしたディレクトリの conf/sen.xml を指すように指定すればよい。

JiroSearch 側の設定変更はこれだけだが、 動作させるためには、 sen.jar と lucene-ja.jar が必要になるので、 これらを WEB-INF/lib にコピーしておく。

これらのライブラリは、 https://sen.dev.java.net/servlets/ProjectDocumentList?folderID=755&expandFolder=755&folderID=0 からダウンロードする。 こちらの動作確認には、 lucene-ja-2.0test2.zip の Japa に入っている lucene-ja.jar と、 sen-1.2.2.1.zip に入っている sen.jar を使った。 lucene-ja-2.0test2.zip にも sen.jar が入っているので、 そちらを使ってもいいと思われるが、 sen-1.2.2.1.zip に入っているものの方が日付が新しいので、 そちらを使った。

方法1: 環境変数 ANT_OPTS の値を設定する。

Windows の場合、 setpath.bat に次の行を追加する。

set ANT_OPTS=-Xmx256m

linux の場合、 setpath.bash の最後に次の行を追加する。

ANT_OPTS=-Xmx256m
export ANT_OPTS

方法2: build.xml の java タスクでメモリサイズを指定する。

    <java classname="jp.co.crm.jirosearch.lucene.IndexUpdater"
      classpathref="project.class.path"/>

上記の箇所を、 次のように1行追加する。

    <java classname="jp.co.crm.jirosearch.lucene.IndexUpdater"
      fork="true" maxmemory="256m"
      classpathref="project.class.path"/>

Windows版のJDKは、Administrator権限でないとインストールできません。このため
JiroSearchのインストール用に、\usr\local\jiro\javaに直接インストールする場合、直後にインストールが促されるJREで、JDKを上書きしないように注意が必要です。

JiroSearch が検索結果を表示するときに、 本文の一部を表示している。

一般に、検索結果の一部を表示するには、 本文を適当な長さのブロック(チャンク、パラグラフ)に分割し、 それぞれに対して、 与えられた検索語に対する評価を行い、 関連性が高いものを選択する、 という処理を行う。 このためのクラスが Lucene には用意されている。 ( org.apache.lucene.search.highlight.Highlighter )

ただし、 現在の版の JiroSearch は、 このクラスを使っていない。 文章の真ん中にある検索語の前後を表示する という単純なロジックで抜き出しているのだ。 例えば「検索」という言葉が文章中に5個出現したら、 3番目の「検索」という文字の前後を表示しているのである。

最初は、 見つかった検索語の前後を表示してみたのだが、 サイトの多くがヘッダやフッタのような定型的な内容を含んでいて、 意外とそこに検索語があることが多いので、 あまりいい結果が得られない。 ということで、真ん中あたりを出した方がいいだろ、 という安直な発想でそのような処理に変更したのだ。 結果はご覧の通りで、そう悪くはないような気がする。

現在の処理は、 検索語の個数の真ん中に注目しているのだが、 もう一つ似た考え方で、 テキストの真ん中に一番近いもの、という方法もある。 JiroSearch のソースでは、 jp.co.crm.jirosearch.util.TextUtils クラスの getExcerpt メソッドがその処理になっているので、 ここを変更すれば抜き出す内容を変えることができる。

ant filecrawl を実行するときに、 パスに含まれる文字列を指定して、 対象から外すことができる。 この指定は、 systemProperties.xml 内の次の箇所で指定している。

    <property name="excludeCrawlPatterns">
      <list>
        <value>/intra/</value>
      </list>
    </property>

この例だと、/intra/ という文字列が含まれているパスを走査対象から外すことになる。 仮に /hoge/intra.html のようなパスがあったら、 ここには「/intra/」という文字列は含まれていないので除外されない。 /hoge/intra/foo.html なら「/intra/」という文字列が含まれるので、走査対象から除外される。

Windows で実行する場合は、 パスが「\」になることに注意。 「\hoge\intra\foo.html」 というパスには「/intra/」が含まれていないため、除外されない。 これを除外するには 「\intra\」という指定が必要になる。

org.apache.lucene.queryParser.QueryParser は、どうやって Field.Index.TOKENIZED と Field.Index.UN_TOKENIZED の判断をしているのだろうか?

というのは、 API reference manual の、UN_TOKENIZED のところには、次のように書いてある。

Index the field's value without using an Analyzer, so it can be searched. As no analyzer is used the value will be stored as a single term. This is useful for unique Ids like product numbers.

ということで、JiroSearch ではタグの検索するために Field に追加する場合、 UN_TOKENIZED を指定していたのだが、 これがどうもうまく検索してくれない。 というか、 UN_TOKENIZED を指定した field も analyzer を call しているような気がする。

ただし、 index を作る時には analyzer を呼んでいないと思われる。 マニュアルの記述をよく読めば、 index を作る時に呼ばないと書いてあるだけであって、 検索する時にも呼ばないとは書いてないような気もする。 ただ、仮にそうだとして、 検索時だけ analyzer を必ず通すというような実装でもうまく検索できるものなのだろうか、 という疑問が生じる。

QueryParser のソースを追いかけてみても、 どこで field (ただしこれはフィールドの名前を示す String であり、Field ではない) を使っているのか分からないというか、 他に丸投げしているだけで、 QueryParser の中では一切 field に関する判定をしていないような気がする。 関口さんのブログの「関口宏司のLuceneブログ | 独自QueryParserの作成（５）」に独自実装した MyQueryParser というクラスのソースが公開されているのだが、 そちらを見ても、 field という String の中身がどうあれ analyzer を呼び出しているような気がする。

じっくり見たわけではないので私が何か見落としている可能性も高い。 一番ありそうなのは、 field が UN_TOKENIZED の場合はそもそも QueryParser に飛んでこない、 というような実装が上位でされている、というような状況の見落としだが、 動かしていると実際呼ばれているとしか思えないような振る舞いをしているような気がしてしょうがない。

また、もし前述のような実装になっているとしたら、 field という String を何のために analyzer を呼び出すときの引数に指定しているのかが分からない。 もしかして、 そのあたりに何か仕掛けがあるのだろうか?

昨日書いた QueryParser の field の謎の件は簡単に解決しそうにない。 多少工夫してみたのだが、 どうあっても Analyzer を呼び出してしまうので、 Analyzer を呼ばないようにするのは諦めた。 要するに Analyzer が何もしなければいいのだから、 何もしない Analyzer を用意して、それを指定すればいいのでは。 という逆転の発想である。

試しに SimpleAnalyzer とか StandardAnalyzer を使ってみたのだが、 殆どうまくいく。 しかし、レアケースではあるが、 例えば文字列に white space が入っているといけない。 space は区切りと解釈してしまうからである。 例えば "DS Lite" は、"DS" と "Lite" の2つの Token に分かれてしまう。 tag に登録されている String は "DS Lite" だからうまくない。

何もしない Analyzer というのはないのか。 なさそうな気がしたので、 作った方が早いだろと思って作ってみた。 まず、何もしない Tokenizer を作る。

package jp.co.crm.jirosearch.lucene;

import java.io.Reader;

import org.apache.lucene.analysis.CharTokenizer;

public class NoActionTokenizer extends CharTokenizer {

	public NoActionTokenizer(Reader input) {
		super(input);
	}

	@Override
	protected boolean isTokenChar(char c) {
		return true;
	}
}

isTokenChar(char c) が必ず true を返す。 ということは、この input には切れ目がなく、 全てが有効な文字ということだから、 CharTokenizer は与えられた文字列をそのまま単独の Token にしてくれるはずだ。 次に、これを使った Analyzer を作る。

import java.io.Reader;

import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.analysis.TokenStream;

public class NoAnalyzer extends Analyzer {

	@Override
	public TokenStream tokenStream(String fieldName, Reader reader) {
		return new NoActionTokenizer(reader);
	}
}

この NoAnalyzer を Analyzer として指定すれば、 与えた文字列を空白等も全部ひっくるめてそのまま1つの Token にするから、 結果的には Analyzer を呼ばなかったのと同じことになる。

これでタグに対して何もしない Analyzer を指定する準備が整った。 さて、タグに対してこの NoAnalyzer を指定し、 body には CJKAnalyzer を指定したい、 というような場合はどうすればよいか。

複数の Field に対して検索をかけたい場合は、 org.apache.lucene.queryParser.MultiFieldQueryParser を使う。 このクラスには、いくつか static な method が用意されている。 例えば、

static Query parse(String[] queries, String[] fields, Analyzer analyzer);

このように、 フィールドごとに query を指定することはできるのだが、 analyzer は一つしか指定できない。 Field によって異なる Analyzer を使い分けたい場合は、 org.apache.lucene.analysis.PerFieldAnalyzerWrapper を使ってラップすればいい。 このクラスには、 次のようなメソッドが用意されている。

void addAnalyzer(String fieldName, Analyzer analyzer);

手順としては、 PerFieldAnalyzerWrapper のインスタンスをまず作成しておき、 その後、 addAnalyzer メソッドを呼び出して、 デフォルトではない Analyzer を使いたいフィールドを指定することになる。

さて、これはこれでいいのだが、 JiroSearch は Spring Framework を使っているから、 フィールドに対する Analyzer の指定は applicationContext.xml に書きたいところだ。 ところが、 PerFieldAnalyzerWrapper には setter も getter もないから、 Analyzer を指定するのが面倒である。 ということで、 もともと小さいクラスだし、 勝手に setter、getter を追加した。

public class PerFieldAnalyzerWrapper extends Analyzer {
    private Analyzer defaultAnalyzer;

    private Map<String, Analyzer> analyzerMap = new HashMap<String, Analyzer>();

    public PerFieldAnalyzerWrapper() {
        super();
        this.defaultAnalyzer = new SimpleAnalyzer();
    }
    
    /**
     * Constructs with default analyzer.
     * 
     * @param defaultAnalyzer
     *            Any fields not specifically defined to use a different
     *            analyzer will use the one provided here.
     */
    public PerFieldAnalyzerWrapper(Analyzer defaultAnalyzer) {
        this.defaultAnalyzer = defaultAnalyzer;
    }

    /**
     * Defines an analyzer to use for the specified field.
     * 
     * @param fieldName
     *            field name requiring a non-default analyzer
     * @param analyzer
     *            non-default analyzer to use for field
     */
    public void addAnalyzer(String fieldName, Analyzer analyzer) {
        analyzerMap.put(fieldName, analyzer);
    }

    public TokenStream tokenStream(String fieldName, Reader reader) {
        Analyzer analyzer = analyzerMap.get(fieldName);
        if (analyzer == null) {
            analyzer = defaultAnalyzer;
        }

        return analyzer.tokenStream(fieldName, reader);
    }

    public String toString() {
        return "PerFieldAnalyzerWrapper(" + analyzerMap + ", default="
                + defaultAnalyzer + ")";
    }

    public Map<String, Analyzer> getAnalyzerMap() {
        return analyzerMap;
    }

    public void setAnalyzerMap(Map<String, Analyzer> analyzerMap) {
        this.analyzerMap = analyzerMap;
    }

    public void setDefaultAnalyzer(Analyzer defaultAnalyzer) {
        this.defaultAnalyzer = defaultAnalyzer;
    }
}

このように手を入れた class を使えば、 Spring の設定を次のように書くことができる。

  <bean id="analyzer"
    class="jp.co.crm.jirosearch.lucene.PerFieldAnalyzerWrapper">
    <property name="defaultAnalyzer"><ref local="simpleAnalyzer"/></property>
    <property name="analyzerMap">
      <map>
        <entry key="body"><ref local="cjkAnalyzer"/></entry>
        <entry key="tag"><ref local="simpleAnalyzer"/></entry>
      </map>
    </property>
  </bean>

このようにして、 tag を割り当てた field は Analyzer を通さずに検索し、 body の field に対しては、CJKAnalyzer を使う、 という処理になった。

先の投稿 で analyze しない NoAnalyzer というアナライザを使う話を書いたが、 別の掲示板を見るとやはりそういう時は KeywordAnalyzer を使えという話が書いてあって、 実際、NoAnalyzer を使う前に KeyworkAnalyzer を使ってみたのだが、 うまく行かなかったので、わざわざあのようなクラスを作ったのである。

ただ、その後普通に KeywordAnalyzer を使ってみたら、 何の問題もなくうまく動作する。 つまり、次のように指定すればいい。

  <bean id="simpleAnalyzer"
    class="org.apache.lucene.analysis.KeywordAnalyzer"/>

  <bean id="analyzer"
    class="jp.co.crm.jirosearch.lucene.PerFieldAnalyzerWrapper">
    <property name="defaultAnalyzer"><ref local="simpleAnalyzer"/></property>
    <property name="analyzerMap">
      <map>
        <entry key="body"><ref local="cjkAnalyzer"/></entry>
        <entry key="tag"><ref local="simpleAnalyzer"/></entry>
      </map>
    </property>
  </bean>

では元のコードはどこがおかしかったのか、 というのが変更しすぎてよく分からない。

JiroSearch の現在公開している版は、 index の生成を、最も基本的な方法、つまり、 単一のスレッドで indexWriter を順に呼ぶだけの処理を行っている。 おそらく、これは最も効率のよくない方法で、 大量のインデックスを作ると時間がかかりすぎるのではないか。

ということで、 マルチスレッドを使って org.apache.lucene.store.RAMDirectory を使って index を生成ながら、 最後に FSDirectory にマージする、 という方法がよく紹介されているようだ。 試しに、 インデックスの生成を RAMDirectory を使った処理にまず置き換えてみた。 すると、 当然だが大量のインデックスを作るときに、 うまくやらないと大量にメモリを使うことになる。

この時点でまだスレッドは単一である。 ターゲットになっているファイルは約60万あって、 これを約5万個に分けてインデックスを別々に作ってみると、 全て生成するのに、約 174分かかった。

この結果、15個の index に分かれた状態になっている。 Lucene は複数 index を同時検索することができるから、 このままでも使えるのだが、 試しに、1つの index にマージしてみた。 これには約 30 分かかった。 処理時間を見ていると、 最終結果になるインデックスに1つずつインデックスを追加していくため、 後になればなるほど時間がかかっている。

高速化する余力があるなら、 このあたり(60万ファイル / 200分) を一つの目安にすればいいと思う。 もちろん、状況によってこの時間は大きく変化すると思われる。 今回使ったマシンは Fedora 6 (linux)、 CPU が Pentium 4 2.8MHz、 メモリが 1GB、 という環境である。

index を生成するときに、 CJKAnalyzer を使ったが、 たまに MaxFieldLength をオーバーしているようだ。 この値はデフォルトで 10,000 なのだが、 10,000 だとちょっと少ないと思ったので 30,000 に増やしたのだが、 まだ足りなかった。

このメッセージを出すには、 IndexWriter の setInfoStream メソッドを使って、 例えば次のようにすればいい。 ただし、こうすると他の情報も大量に出てくる。

    indexWriter.setInfoStream(System.out);

Lucene で検索を行うには、 org.apache.lucene.search.Searcher クラスの

Hits search(Query query)

メソッドを使う。 このメソッドはデフォルトのスコア付けに基づいて結果を表示する。 フィールドに対してソートした結果を出したい場合は、 次のメソッドを使う。

Hits search(Query query, Sort sort)

2番目の引数には org.apache.lucene.search.Sort クラスのオブジェクトを渡す。 ソート対象が1つのフィールドの場合は、 コンストラクタ

Sort(String field)

を使って生成したオブジェクトを渡せばよさそうだが、 実際やってみたら、 確かに指定したフィールドの値でソートされるのだが、 フィールドの値が同じときの順番がバラバラで、 スコアが反映されていないような気がする?

ソートしたいフィールドが同点のときにデフォルトのスコアでソートするには、 複数フィールドを指定してオブジェクトを生成してやればいい。 SortField クラスは基本的にフィールドを指定するのだが、 デフォルトのスコア付けというのが特別な書き方があって、 フィールド名を null に指定し、 タイプを SortField.SCORE として、 次のコンストラクタを呼び出す。

SortField(String field, int type)

具体的には、 次のような処理になる。

SortField[] fields = new SortField[2];
fields[0] = new SortField(null, SortField.SCORE);
fields[1] = new SortField(DocumentFactory.FIELD_RANK); // JiroSearch 定義の文字列

Hits hits = searcher.search(query, new Sort(fields));

ロングテール提唱者のアンダーソン氏、アマゾンの問題点を指摘
http://japan.cnet.com/news/media/story/0,2000056023,20342867,00.htm?tag=nl
上記の記事を読んでいたら、Findabilityが足りないと書かれている。
Findabilityを実現すれば、まだまだ売上が伸びると指摘している。

Findabilityの条件とは、なんだろうと？、ネットで検索。
「Ambient Findability」
「アンビエント・ファインダビリティ」という本が検索された。
http://www.oreilly.co.jp/books/4873112834/

そういえば、この本、以前購入して読んだことがあった。
だた、全く中身を覚えていない（笑）

ここらへんのFindabilityの課題に関しては、
JiroSearchのtagsユーザインターフェースが１つの解を持っているように思う。

具体的には、tagsを上手く利用することにより、
・関連する情報を広く、浅く、すばやく提供できること
・気づき効果の連鎖を与えることができること（１回だけではなく、連続して次から次へと気づき効果を与えることができる）
・情報の提供にとどまらず、簡単な操作でアクションを起こすことができること（情報とメソッドのオブジェクト化）→詳しくは、http://blog.japan.cnet.com/kenn/archives/002346.html （XMLとアフォーダンス）

NEC、キーワード入力が不要な情報検索システムを開発
http://japan.cnet.com/news/ent/story/0,2000056022,20342878,00.htm

　NECは2月13日、検索キーワードを入力することなく、提示される選択肢を選ぶだけで必要な情報を見つけられる情報ナビゲーションシステムを発表した。NECでは「携帯電話やカーナビなどの端末では、面倒なキーワード入力なしに簡単に必要な情報にアクセスできるシステムが実現できる」としている。

　このシステムは、検索対象コンテンツのカテゴリやキーワード分布、検索実行時のユーザーの状況、ユーザーの検索履歴といった情報にもとづき、着目すべきキーワードを自動的に抽出して選択肢として提示する。選択肢のキーワードが選ばれると、情報を絞り込むための選択肢を新たに提示し、目的の情報までユーザーを導く。

検索が、「検索する道具からシステムそのものに変化してきた」感じを強く受ける。
で、ここらへんがまさにTagsで実現出来そう。

さらにtagsだと、
ドリルダウン方式の、上から下へ階層的なナビゲーションだけではなく、
ランダムというか、有機的結合というか、それぞれの個の情報が起点となって、
自由自在にナビケーションが貼れるようになり、
どの情報からスタートして、目的地にすばやく辿りつくことができる。

「FASTはGoogleの検索技術より2年先行」
http://www.atmarkit.co.jp/news/200702/21/fast.html

ERP、CRMなどBI関連は20世紀で一巡したの思いがあった徳末氏は、検索技術の面白さと可能性に惹かれた。

ERPやCRMが無くなってしまうわけではないが、
エンタープライズ・サーチは、エンタープライズ領域のシステムにおいて
パラダイムシフトを起こす可能性を秘めている。
と、日々考えている自分にとっては、いよいよだね。
と思わせてくれたニュース。

なぜ、パラダイムシフトかと言えば、
それは、システムの設計が不要になるからであり、
嘘に聞こえてしまうかもしれないが、
それが、エンタープライズ・サーチの最大のメリットに他ならないと考えている。

で、システムの設計が不要になるということは、
何を意味するかと言えば、
設計に制約されないシステム運用が可能になるということであり、
←これじゃ、なんのことかよくわからないわ

言い換えると、
システムは、設計したもの以上のシステムにはなりえないわけで、
自律的にシステムが成長することはありえない。
つまり、
システムを成長させるためには、その都度システムの再設計が必要になる。

これが、エンタープライズ・サーチだと、
自律的に成長するシステムというものが出来上がる。
Web2.0のCGM（Consumer Generated Media）ではないが、
エンドユーザが参加型で自律的に成長していくシステム、
Temp的に勝手に命名すれば、UGS(User Generated System)が
出来上がるというわけだ。