Linux（Debian）にMeCabとmecab-java（javaバインディング）のインストール方法

必要なファイルはMecab、IPA辞書、mecab-java。

1.MeCabのインストール

> tar -xvzf mecab-0.96.tar.gz
> cd mecab-0.96
> ./configure
> make
> make install

2.IPA辞書のインストール＋UTF-8に変換

> tar -xvzf mecab-ipadic-2.7.0-20070610.tar.gz
> cd mecab-ipadic-2.7.0-20070610
> ./configure
> make
> make install
> /usr/local/libexec/mecab/mecab-dict-index -f euc-jp -t utf-8
> make install

3.mecab-javaのインストール

mecab-javaのMakefile内6行目を以下のように修正

INCLUDE=/usr/local/src/jdk1.5.0_12/include/ # 自分のjavaのincludeFileへのパス

makeする

> make

すると、MeCab.jarとlibMeCab.soファイルが出来る。

4.テストの実行

> export LD_LIBRARY_PATH=.../mecab-java-0.96:$LD_LIBRARY_PATH
> export CLASSPATH=.../mecab-java-0.96/MeCab.jar:.
> javac test.java
> java test

DeNAのロジカルシンキング講座に参加

IT業界でもかなりの注目株だと思っているDeNAのセミナーに行ってきた。
まず一言で言うと、アカデミックなエンジニアとして非常に聞く価値があった。
というのも、ビジネスで通用するサービスをどんなふうに考えていけばいいのかという道筋を示してくれたからである。
ロジカルシンキング講座と銘打っているが、実は新規事業の立ち上げ方講座と言ってもいい内容であった。

セミナーの流れとしては、
基礎講座⇒休憩⇒実践講座（グループディスカッション含む）
といった感じだった。
基礎講座でのポイントは

• 儲かる仕組みを回す人ではなく創る人になれ
• 感覚的な解は無意味
• ビジネスでは「だいたいこっち」ってのを早く出すのが大事
• 実際を見てきたほうがよい
• ツールを使いこなして考えを引き出す

実践講座でのポイントは

• プロジェクト＝ブレスト⇒業界研究⇒PLAN⇒検証⇒実行
• 数字を押さえることが大事
• PLAN＝目的⇒解決⇒実現
• 検証＝仮説⇒切り分け⇒分析⇒ソース
• 仮説の切り分け＝調査のタスク
• 実行が一番大事（企画に時間使いすぎるな）
• サービスは雨乞いと一緒（気合だー）

全体の感想としては、グループディスカッションのリーダーをさせていただいたのだが、いろいろな意見をまとめたり、方向修正したり、自分の意見を言ったりするのが初めてだったので、それも為になった。
三人寄れば文殊の知恵とはいうけど、ほんとにいろんな意見をぶつけているといろいろと思い浮かんで面白かったなぁ。

WindowsにSenをインストールする方法

必要なファイルは、Perl(今回はActivePerl)、Ant、そしてSen。

1. 導入
Perlはインストーラでお手軽インストール。
Ant、SenはDownloadしたら、Program Files内には入れてはいけない。
スペースがあるとうまくPathが通らないためにエラーに泣かされる。
なのでC:\Javaとか作ったりしてどっちも突っ込んどく。

2.辞書の構築
UTF-8にしたかったら

sen\conf\sen.xml、sen-processor.xml　内
<charset>utf-8</charset>　に変更

sen\dic\dictionary.properties　内
sen.charset=UTF-8　に変更　# dic.charset=EUC_JPは変更しない

コマンドプロンプトで、

> cd c:\Java\sen\ <-senを解凍したディレクトリ
> cd dic
> c:\Java\apache-ant-*.*.*\bin\ant -Dperl.bin=c:\Perl\bin\perl.exe

3.動作確認

> cd c:\java\sen\bin
> set JAVA_HOME="c:\Program Files\Java\jdk*.*.*"
> set SEN_HOME="c:\Java\sen"
> sen.bat
.....
SenはJavaで実装された形態素解析器です。 <- 入力したテスト文
Sen (Sen) 未知語(0,3,3) null null
は (は) 助詞-係助詞(3,4,1) ハ ワ
Java (Java) 未知語(4,8,4) null null
で (で) 助詞-格助詞-一般(8,9,1) デ デ
実装 (実装) 名詞-サ変接続(9,11,2) ジッソウ ジッソー
さ (する) 動詞-自立(11,12,1) サ サ
れ (れる) 動詞-接尾(12,13,1) レ レ
た (た) 助動詞(13,14,1) タ タ
形態素 (形態素) 名詞-一般(14,17,3) ケイタイソ ケイタイソ
解析 (解析) 名詞-サ変接続(17,19,2) カイセキ カイセキ
器 (器) 名詞-接尾-一般(19,20,1) キ キ
です (です) 助動詞(20,22,2) デス デス
。 (。) 記号-句点(22,23,1) 。 。

次にWebサービスを作る時に考えたいこと

私は「ひ☆かく★すぅ」というWebサービスを公開していたのは、以前のエントリーでも書いた。
ひ☆かく★すぅの概要は以下の通りだ。

1. ひ☆かく★すぅ では、ひらがなの名前から、名前の候補を表示します。(ただし、名前の候補がない場合は、何も表示されません。)
2. 名前の候補それぞれにおいて、順位とポイントが表示されます。
3. 表示では、名前はポイントが高いほうから順に並べられています。(ポイントの高いほうから順に順位がつけられています。)
4. 表にあるラジオボタンをクリックすると、チェックされた名前に関する運勢とWikipedia検索結果が表示されます。
5. 「エゴサーチ」ボタンをクリックすると、チェックした名前に関するいろいろな検索が出来ます。
6. 「今日の運勢」ボタンをクリックすると、あなたの今日の運勢が表示されます。また、楽天にラッキーアイテムが存在すると、ラッキーアイテム関連検索を行い、別のタブで開きます。

今だから思う、もっとこうしたら良かった点などをまとめてみる。

• ユーザーが「また来たい」と思う仕組み作りをする

静的なデータのみを使っていると、結果は変わることがない。
すると頻繁にアクセスしてくれるような常連ユーザーは存在せず、アクセスが増えていかない。

ではどうすればいいのだろうか？

ユーザーがデータを追加していける仕組みを作ることである。
ニコニコ動画やflicker、Twitterなどはすべてそうである。つまり、ユーザー参加型サービスである。
これによって、ユーザーが増えるだけコンテンツも増えるのでまた来たいと思ってもらえる。

ユーザーがカスタマイズできる仕組みを作ることである。
iGoogleなどである。これによってサービスが身近に感じてもらえ、使ってもらえる。

• いろいろな使い方をされるようなものを作る

機能が一つに決まっていては、つまらない。
サービスの中でもある程度楽しみ方が自由であった方がおもしろい。
例えば、詩や歌などがそうだ。
感じ方や楽しみ方は聞いている人によってそれぞれであり、それによって作った本人も考えさせられるようなもの。
そういうものを私も作りたい。

予測入力まとめ

今までの予測入力には大きく分けて二つのタイプがある。

1. 辞書にあるものを先頭一致で補完するタイプ(省略補完)
2. ドキュメント中の単語と共起して単語を補完するタイプ(動的補完)

このうちの1においてさらに

1. 静的な辞書を用いるもの(国語辞書など)
2. 動的な辞書を用いるもの(ユーザー辞書など)

の二つに大別できるだろう。
以下に、各システムの予測入力の特徴を列挙してみる。

MS-IME

• 優先度あり
• 字面のみを用いる(意味を考えない)
• 共通部分を抜き出す
• メモリorファイルに書き出す
• 予測候補はユーザーの変換履歴からのみ
• 先頭一致

ATOK

• 優先度あり
• 形態素で区切って、それぞれを予測に反映
• 最小の形態素と次の形態素を加えたものを表示する（次の形態素を加えたものの方が優先度が高い）
• 合わせたら一つの意味となりそうなものが前に来ていたら、くっつけて登録
• よく使うもの(?)は自動的にユーザー辞書に収録
• メモリorファイルに書き出す
• 予測候補は各種辞書(カスタマイズ可能)、ユーザーの変換履歴
• 先頭一致

Nanashiki

• 優先度あり(一番最後に発見した単語)
• 予測候補はコンテキスト文書(辞書化しない)
• migemoで動的サーチ後に周辺を茶筅で切って、単語の先頭ならば候補にする

Kukura

• 優先度あり(最近閲覧した文書)
• 予測候補は閲覧した文書
• あらかじめ茶筅で単語を切っておく
• 候補は名詞、未知語及びそれらの複合語
• 複合語はすべての候補の組み合わせを有効にしていない

PRIME

• 要調査

MS-IMEとATOKの違い

• MS-IMEでは、意味を全く考えないため、"新潟大学"、"新潟大地震"を確定するとその共通部分である"新潟大"が一番優先度が高くなるが、ATOKでは同様の確定をしても"新潟大学"、"新潟大地震"しかでない
• ATOKでは"新潟"で確定後に"大"を確定すると"新潟大"が登録される
• ATOKでは"複合名"で確定後に"名"を消して"名詞"を確定しても"複合名名詞"が登録されることはない

携帯電話の予測入力システム

1. POBox(Prediction Operation Based On eXample)
2. APOT(Advanced Prediction Optimization Technology)

POBoxとAPOTの違い

• APOTはPOBoxよりも付属語が長めに区切られる(例: "～して" → POBox: "～","し","て" APOT: "～","して")
• APOTは直前に使われた候補が先頭
• POBoxは頻度の高い候補が先頭

従来の予測入力での不便な所

• 数字や英数カナ変換で入力した文字は学習されない
• コピーアンドペーストは学習されない

携帯電話とパソコンの違い

• 入力するキーの数(=入力にかかる時間)

私が使う、『予測入力』

• 特殊な複合名詞(簡単な文であれば、いちいち予測入力候補を探さずに、一気にタイピングして変換をするのが早い)
• 繰り返し入力

予測用複合名詞の用意

• ユーザーの確定履歴から
• いま編集中の文章のコンテキストとなる文章から
• ユーザーが選べるように辞書を用意しておく

ひ☆かく★すぅ

Mash up Award 3rd にてpaperboy&co.賞を頂いたのですが、
その時にSunから借りていたレンタルサーバーが使えなくなって早1ヶ月。
まあ、無料だから仕方がないのですが、いきなり使えなくなったのにはびっくりしました。
賞を頂いたので、とりあえず研究室のサーバーを借りてサービスを続けようと思いますが、
新しく外部向けサーバーを買い換えるみたいなので、待っててください。
需要があるかは謎ですが(笑
また追って報告します。

Bloggerではてブ(はてなブックマーク)登録とusers(登録者数)の表示

いろんなサイトみて設定したんだけど、どっちも書いてあるところがなかったのでここにまとめておく。

テンプレート > HTMLの編集 にて

ローカルで編集したいなら→テンプレートのダウンロード
そのままブラウザで編集したいなら→「ウィジェットのテンプレートを展開」をチェック

はてブへの登録

<a expr:href='"http://b.hatena.ne.jp/add?mode=confirm&amp;url=" + data:post.url + "&amp;title=" + data:post.title'>
<img src="http://d.hatena.ne.jp/images/b_entry.gif" width="16" height="12" style="border: none;" alt="このエントリーをはてなブックマークする" />
</a>

usersの表示

<a expr:href='"http://b.hatena.ne.jp/entry/" + data:post.url' target='_blank'>
<img alt='このエントリーへのはてなブックマーク数' expr:src='"http://b.hatena.ne.jp/entry/image/" + data:post.url' style='border: 0pt none ;' />
</a>

こいつらを次のタグの下に挿入する

<a　expr:href='data:post.url'><data:post.title/></a>

ちなみにusersの画像はFirefoxだと出るまでに少し時間がかかりました。
IEだとすぐに反映されるのですが・・・。
何でなんでしょう??

シゴフミがおもしろい

「シゴフミ」
１・２話と見てみたが面白い。
ではシゴフミの何が面白いのだろう？考えてみた。

１．シナリオ
・いい意味での裏切り（例：１話の最後）
・表現のうまさ（所々に入る回想など）
・連鎖（シゴフミ）

２．絵
・ストーリーの雰囲気に合っているタッチ
・見せ方のうまさ（アングル、表情）

３．キャラ
・杖

４．声優
・うまい（１・２話のメインの女の子）

感想とか
特に期待もせず見ただけに印象がとても良い。
「シゴフミ」という名前からも、シゴフミを渡して読んで何か起こるのは当然だが、
それだけじゃない人間関係などのコンテキストをうまく表現している。
その上で連鎖する「シゴフミ」の存在が非常にうまく扱われている。

こういったコンテンツ的な面白さを、うまいこと違う土俵にも応用できたらいいのだが。
まだまだ面白いと感じるものについて掘り下げられていないからなぁ。
枯れた技術の水平思考じゃないけど、常に水平思考していきたい。

オープンなYahoo!という印象

ITmedia「Yahoo!サービス、Google携帯やiPhoneにも対応へ」

独自の携帯ソフトで既存の携帯電話と競合しようとするよりも、GoogleやAppleの端末に対応するインターネットサービスを提供することで、数億人の携帯電話ユーザーにリーチできるとボーリーズ氏は述べた。

お、Incやるじゃん！
Yahoo!Japanも後に続くかな？？続いて欲しいなぁ。
やっぱり戦うフィールドは広い方がいいし、囲い込み戦略は厳しいと思います。（参考：キングコング最強説）
これは親のソフトバンクの戦略だからYahoo!Japanにはどうしようもないのかな？
孫さん～！
日本でもGoogle携帯とかiPhoneが出始めたらYahoo!Japanの囲い込み戦略だけではSOFTBANKを選んでもらえないと思う。
私はYahoo!Japan好きなので、是非ともオープンにしてほしいものです。

キングコング最強説

@IT「グーグルはキングかゴリラか」

“キング”とは、顧客が他社製品・サービスへスイッチするコストが低い市場リーダーのことで、“ゴリラ”とは逆にスイッチング・コストが高い市場リーダーだ。 同じ市場リーダーであっても、キングは、いつでも競合他社にトップの座を奪われる可能性がある。一方、何らかの「囲い込み」によりスイッチング・コス トを高くしているゴリラは、市場のトップの地位を維持できる可能性が高い。従って、企業の将来価値は「市場自体の将来性、市場でのシェア、顧客のスイッチ ング・コストの高さの関数として表される」という。

私も個人的にはキングであることがWebサービスでは重要であると思う。
一ユーザとして、Webというものの上では自由であることを望んでいるし、自由であるべきだと思う。
様々なサービスから自分の好きなものを選べるのが楽しいし、たくさんのサービスの中から選んだものであればあるほど、選ばれたサービス提供企業はユーザに好きになってもらえると思う。
それを企業がゴリラになってしまっては興醒めである。
恋人が、「私の利益のために、これからも付き合ってね？」と言うようなものだ。
企業は利潤の追求を求めるのが仕事だが、私はそれ以上に嫌われたらおしまいだと思う。
これからは囲い込みチックな方向じゃなくて、ほんとに好かれるモノをすべてのWebサービス企業には作っていってほしい。
そして就活中の私も、そのような企業に入りたいと考えている。

早くATOK2008使いたい

今ATOK2007を使っているのだが、ついにATOK2008でn文節最長一致をやめるようだ。
ｎ文節最長一致とは、文を先頭からn文節目までの合計の長さがもっとも長いものを正しいと見なす方法である。ちなみに経験的に後半が長いものを正しいと見なすようだ。

さて、なぜATOK2008になって急にATOKはこのn文節最長一致をやめたのだろうか？

PC Watch「ジャストシステム、一太郎/ATOKなど含む「JUST Suite 2008」を発表」

ATOKは従来、最も長く取れる2文節を優先的に選択する「n文節最長一致法」を採用していたが、近年この手法による誤変換の発生が稀ではなくなってきた。そこで、出現頻度や言語的性質などを数学理論によって1つの評価軸の上に積算する統計的言語処理手法を採り入れた。また、機械処理に頼らず、人手によ る検証と微調整を重ねることで、体感的な変換精度を向上させたという。

うーむ。近年稀ではなくなってきたという表現が曖昧すぎる。
私としては、前からATOKは文節を長くすればするほど失敗してしまう印象だ。
だから今回の内部アルゴリズムの変更は「ついにやったか！」という感じだ。
統計的言語処理手法ということだが、最小コスト法ではないのか？
まぁ、手に入ったら実際に使ってみていろいろとレビューしてみたい。

≪追記≫

ATOK2008レビュー

Input Method

自分は日本語入力システム（かな漢字変換システム）の研究をしている。
わかりやすく言えばIMEを作っている。
IMEはInput Method Editorであるが、MicroSoftが自分たちのをMicroSoft-IMEとかつけちゃったので、単にIMEって言っちゃうとそれを指してると誤解されることが多い。困ったものである。
だからATOKやことえりのメタ概念を呼ぶ時はIM(もしくはインプットメソッド)と呼ぶ。
古い人達（うちのボスとか）はFEPと言っているが、それは昔の話で、今はもっぱらIMと呼んでほしい。
というのも、FEP(Front End Processer)はその名前の通り「前処理」を行うもの全般を意味しているからである。昔は多くの日本語入力システムがキーボードから入力された文字をOSに渡す前に処理するFEP方式を採用していたのでよかったのだが、最近は日本語入力システム以外のプログラムも同時に動作しているので、日本語入力システム=FEPではなくなっているのである。

でもIMってインスタントメッセンジャーの方がむしろメジャーになりつつあるからなぁ。
そこんとこを考えるとIMという略称は厳しいし分かりづらくなりそう。
ということで新しい呼び名を作るべきじゃないかなぁ。