Yahoo! テキスト解析API ルビ振りAPI

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

現在は世に散らばるWebAPIの活用方法を検証します。
今回も前回と同じく、Yahooのテキスト解析APIから、ルビ振りAPIという機能を検証します。

ルビとは

ルビとは、以下のように漢字にフリガナをつける機能のことです。

遠藤（えんどう）　太志郎（たしろう）

このような表示を可能としているのは、<ruby>というHTMLタグです。
ブラウザによって対応していたり、していなかったりしますが、
最近のHTML5対応型ブラウザであれば対応していることが多いです。

HTML5の情報については、すでにネットに大量に転がっていますので、ここでは割愛とさせて頂きます。

しかし、上記のような「ルビ＝漢字の読み仮名」という図式は、まあ一応は標準的な使い方とされているわけですけれども、使い道は色々と自由になりますよね。
だって、ベースとなる文字の上に小さな文字をつけるというシンプルな機能であって、別に「カタカナ拘束」のような制約はありませんから。

例えば、

遠藤　太志郎（技術開発事業部）

遠藤　太志郎（記）

遠藤　太志郎（８０％オフ）


みたいに、その単語にちょっと付属情報を入れる、みたいな使い方が出来ます。
こういうのを駆使してより良いインターフェースを作っていきたいものです。

ルビ振りAPI

上記では<ruby>の使い道について記述しましたが、今回のメインであるYahooのルビ振りAPIは、「漢字かな交じり文に、ひらがなとローマ字をつける」という標準的な用途の為のAPIです。

公式サイトは以下です。

http://developer.yahoo.co.jp/webapi/jlp/furigana/v1/furigana.html

さて、ここを見ますと、以下のような説明がありました。

どうやら、「子供向けにフリガナを振る」というのが本来の趣旨のようです。
子供用の教育サイトとか、子供用新聞記事とか、そういったサイトであれば需要がありそうです。

とはいえ、私は業務システム開発がメインのＳＥですので、そんな子供用機能は需要が無いです。

しかし、そこを何か別の形で利用出来るのではないかな、と思って考えてみました。

例えば、以下のように名前とフリガナを入力する機能があるとします。

姓　　名
セイ　メイ

でも、両方入れるのは面倒なので、漢字だけ入れればカタカナは自動補完してくれると便利なのに、と常々思っています。

というわけで、私の名前でルビ振りAPIを実行してみました。

実行プログラムは依然と全く一緒。送信先URLを変えるだけで実行出来ました。
以下の過去記事をご確認ください。

1. Yahoo! Web API　登録編
2. Yahoo! テキスト解析API　キーフレーズ抽出（送信機能作成編）

さて、実行した結果は以下になりました。

• 遠藤⇒えんどう(endou)
• 太志郎⇒ふとししろう(hutosisirou)

ん～、ダメか。。。
やる前からなんとなく想像がついていましたが、私の名前は珍しいので対応出来ません。
「遠藤太郎」でやってみたら、正常に機能しました。

言語解析である以上は仕方のないことかもしれませんが、


「精度が１００％ではない。」


という問題がついて回ってきてしまいます。
このため、業務システムに導入するのはタイミングが難しそうです。

活用方法考案

このＡＰＩは、「精度が１００％ではない」という絶対的な問題があります。

だからと言って、「それじゃ使えねーよ」と断じてしまうのは早計でしょう。
別の考え方をすれば「大体は合っている」わけですので、「精度が大体ＯＫであれば十分」という用途ならば使えるわけです。

例えば、私はルビ振りAPIの機能のうち、「ローマ字機能」の方に着目してみました。

システムを扱っていると、「ファイル名は半角英数字で保存しなければならない」という制約に必ずぶつかります。
例えば、ファイルアップローダーです。

「打ち合わせ資料20130112.zip」をアップロードすると、大抵の場合は「142453.zip」みたいに名前がシーケンス番号等に変換されてリンク先URLになっています。

• http://tasy.com/download/142453.zip

みたいな感じですが、これじゃあURLだけでは中身が何か分かりません。
そこを、このローマ字変換機能を使います。すると、

• http://tasy.com/download/142453/utiawasesiryou20130112.zip

という形で保存出来るわけですよ。
URLの一意性はディレクトリ構成で対処、ファイル名はローマ字変換です。
完璧とは言えませんが、シーケンス番号よりは良くなったでしょう？


「システム＝精度１００％とは限らない。気持ち便利になった程度でも価値がある」


こういうシチュエーションもあるということです。

終わりに

引き続き、世の中にあるWebAPIの検証をしていきます。

Yahoo! テキスト解析API キーフレーズ抽出（レスポンス検証編）

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

今回はいよいよ、「Yahoo! テキスト解析API　キーフレーズ抽出」を実行してその結果を見てみたいと思います。

使い方

キーフレーズ抽出ＡＰＩの公式サイトは以下です。

http://developer.yahoo.co.jp/webapi/jlp/keyphrase/v1/extract.html

ヤフーの良い所は、公式ドキュメントが日本語で整っていることですね。
GoogleやFaceBook、Twitterなどは英語しか無いのでどうやって使えば良いのか、仕様を読み取るだけでも一苦労です。

そのような解読が難しいAPIであれば、APIのパラメータ指定方法等についてもこのブログで解説する所ですが、
ヤフーの場合は不要でしょう。
公式サイトを見た方が分かりやすいと思います。

というわけで、前回作ったリクエスト送信機能を使って、早速レスポンス結果をチェックしてみます。

テスト送信

最初にテストとして流すのは、

「私は株式会社ジェニシス、技術開発事業部の遠藤　太志郎です。」

この一文を実行してみます。

すると以下のようなXMLのレスポンスが返ってきました。



このAPIでは「xml」「json」「PHP Serialize」の３パターンでレスポンスを取得出来ますが、特に指定が無ければXMLの形で帰ってきます。

ヤフー側で文章を単語毎に分割して、抽出した単語をKeyphraseタグ、その重要度をScoreタグで表現してくれています。

この結果を読みやすいようにリスト化した結果が、以下のようになりました。

順位	キーフレーズ	重要度
1	太志郎	100
2	株式会社ジェニシス	81
3	技術開発事業部	51
4	遠藤	45
5	私	10

なるほどなるほど。
ちゃんと『日本語の単語』毎に分割してくれていますね。
この辺りの正確さがヤフーの「日本語形態素解析」の技術力なのです。

このケースだと、私の名前「太志郎」が重要度ＴＯＰに輝くことになりました。

検証：単語のレア度

上記の結果では私の名前「太志郎」が重要度ＴＯＰになりました。
しかし、自分で言うのも何ですが、私の「太志郎」という名前は珍しい名前だと思います。
同じ名前の人に会ったこと無いですし、ネットで検索しても余り出てきません。

では、名前がありふれた名前だったら？
そこで、次に以下の文章を流してみます。

「私は株式会社ジェニシス、技術開発事業部の遠藤　太郎です。」

「太郎」という日本一普通な名前にして実行してみたところ、以下のようになりました。

順位	キーフレーズ	重要度
1	株式会社ジェニシス	100
2	技術開発事業部	62
3	遠藤	55
4	太郎	48
5	私	13

何と、太郎さんは一気に４位まで転落してしまいました。
この結果から考察すると、このWebAPIには以下の傾向があると推察されます。


単語毎に「レア度判定」があり、レアな単語ほどポイントが高い。

検証：長文解析

次に、短い一文を流すのではなく、長文の解析を行います。
このAPIは一度のリクエストサイズは「100KBまで」という制限があります。
この為、大量情報を一気に解析することは出来ませんが、短い小説くらいなら耐えられます。

そこで、サンプルとして、青空文庫より芥川龍之介の羅生門を拝借してきました。
比較的短めのストーリーで、知名度も高く、サンプルとしては向いていると思います。

その結果がこちら。
全部掲載するのは冗長である為、ベスト５だけ掲載します。

順位	キーフレーズ	重要度
1	下人	100
2	老婆	71
3	面皰（にきび）	64
4	羅生門	64
5	雨やみ	61

なるほど。
まさに「羅生門」な結果になりました。
羅生門における重要フレーズを見事に突いていると思います。
「何の小説を解析した結果でしょう？」というクイズに使えそうなくらいの正確さであると思います。

次にもう一つ、同じく青空文庫より白雪姫を解析してみます。

サイズオーバーしたので少し文章を削りましたが、その結果がこちら。

順位	キーフレーズ	重要度	登場回数
1	おまえさん	100	10
2	白雪姫	79	50
3	こくたん	67	4
4	まま母	67	5
5	小人	63	52

ＴＯＰは「おまえさん」ですか。。。
これはちょっとハズレな気がしますね。

それぞれの単語の登場回数もカウントしましたが、余り順位との相関関係が見られません。
「文章中にその単語が何回使われているか」も重要度を決定する上では考慮されている可能性もありますが、それだけではないのは確実です。
上記で考察した「レア度」など、複数の要素でポイントを算出しているようです。

そして注目しなければならないのは、この表に「リンゴ」がありませんね。
ベスト５のみならず、ベスト２０にも入っていません。
白雪姫のストーリー上、「毒リンゴ」は最重要キーワードなはずですが、カスリもしないという結果になりました。

つまり、


単語を解析する機能であって、ストーリー上の重要性は考慮されない。


ということです。
やはりストーリー性までをアルゴリズム化することは不可能なようです。
「そりゃそうだろう」という結果ですが、利用者はちゃんと認識しておかなければならない要素です。

利用方法検討

以上の検証により、「Yahoo! テキスト解析API　キーフレーズ」の傾向が分かってきました。

• 特徴的な単語を抽出することが可能である。
• 特徴的な単語を抽出する機能であって、重要な単語を抽出する機能ではない。
• フリーの長文を解析することが可能である。

これらを総合すると、「フリーの長文を読み込ませて特徴的な単語を抽出し、その中で何が重要であるかは人間が見て判断する」という用途に役立てることが出来そうです。

現実の業務でどのようなタイミングで使用出来るかと考えると、アンケート解析に使えそうです。

「その他、ご自由にお書き下さい」とか、アンケートにはフリー項目の欄が設けられていることも多いです。
もちろん、それらは担当者の人が実際に読んで、大事な部分を読み取る作業が必要不可欠です。
その作業を完全に自動化することは不可能ですが、補助ツールとしては利用価値があるのではないでしょうか？

終わりに

最後にもう一つ、テキストを読み込ませてみたいと思います。

わが社の公式ホームページに掲載されている、「社長からのご挨拶」。

http://www.genesis-net.co.jp/company/message.html


これをキーフレーズ抽出します！！
結果は以下でした。

順位	キーフレーズ	重要度
1	ジェニシス	100
2	最先端	56
3	フィードバック	49
4	新大陸	45
5	輝かしい財産	43

この解析結果の評価につきましては、一社員である私はコメントを差し控え、読者である皆様各自にてご判断頂きたく思います。

Yahoo! テキスト解析API キーフレーズ抽出（送信機能作成編）

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

現在は巷にあるWebAPIの検証を行っています。

リクエスト送信機能

さて、WebAPIを実行するにはリクエスト送信機能が無くてはなりません。

HTTPリクエスト送信には一般に「Getメソッド」と「Postメソッド」があります。

本当はHTTPには「Deleteメソッド」とか「Putメソッド」とか色々と策定されているのですが、HTTPブラウザを初めとして送受信するソフトウェアの方が非対応だったりすることが多く、ほとんど使われていません。
「各メソッドはちゃんと決められたルールに則って使おう」という呼びかけもありますが、それが実現するのはまだ相当先となるでしょう。（永久に来ないかも）

というわけで、今回は「Getメソッド」と「Postメソッド」のみを考察します。

GetとPostの本来の用途は以下です。

• Get：リソースの取得に使用する。(例えば、テーブルの主キーをGet送信して検索し結果を取得する、など)
• Post：情報の送信に使用する。(例えば、入力フォームの全情報をPost送信してテーブルに保存する、など)

今回のテキスト解析APIは「テキスト解析結果を取得する」機能ですので、Getを使う方が標準と言えます。

しかし、Getメソッドの場合、Webサーバに最大長制限があります。
（Apacheの場合はデフォルトで「8190バイト」など。）

今回のテキスト解析ＡＰＩでは、解析するテキストの長さがどれくらいになるか分かりませんので、
「Getで大量データを送信したらエラー」といったケースが想定されます。

その一方、Postにも上限はありますが、こちらはGetよりも大量データを送信出来ます。
（Tomcatの場合はデフォルトで「2メガバイト」など。）

この為、今回はPost送信を使います。

• テーブルの主キー検索など、リクエスト長の上限が明確に決まっている場合はGetメソッド。
• 今回のテキスト解析ＡＰＩのテキスト送信みたいに、リクエスト長が不明 or 大量な場合はPostメソッド。

こういう使い分けにするのが合理的でしょう。

以下に私がJavaで作ったPost送信機能のサンプルソースを記載しておきます。
特に変わった機能は無く、普通に送信して、人間が目で見て分かりやすい形に出力するソースです。

HTTP通信は汎用的なプロトコルですので、JavaScript、PHP、Rubyなど、各言語でも作成できます。
各自の環境で都度、都合の良いように作れば良いでしょう。

public class RequestSender {

 /** logger */
 private Logger logger = Logger
   .getLogger(RequestSender.class);

 /**
  * リクエストをPOST送信する
  *
  * @param url
  * @param postBody
  * @return
  * @throws IOException
  */
 public String sendPost(String url, String postBody) throws IOException {

  //log4j使用
  //送信パラメータをトレースログに出力
  if(logger.isTraceEnabled()){
   logger.trace("送信先URL：" + url);
   logger.trace("リクエストボディ：" + postBody);
  }

  URL sendURL = new URL(url);
  URLConnection con = sendURL.openConnection();

  // POST送信モードを指定
  con.setDoOutput(true);

  // 送信実行
  OutputStreamWriter osw = null;
  BufferedWriter bw = null;
  try {
   osw = new OutputStreamWriter(con.getOutputStream());
   bw = new BufferedWriter(osw);

   // POSTの内容を書き出す
   bw.write(postBody);

  } finally {
   if (bw != null) {
    bw.close();
   }
   if (osw != null) {
    osw.close();
   }
  }

  // 受信
  InputStreamReader isr = null;
  BufferedReader br = null;

  StringBuilder bul = new StringBuilder();

  try {
   isr = new InputStreamReader(con.getInputStream());
   br = new BufferedReader(isr);

   String line;
   while ((line = br.readLine()) != null) {
    //肉眼で見やすいように改行コードを付与
    bul.append(line).append(System.getProperty("line.separator"));
   }

  } finally {
   if (br != null) {
    br.close();
   }
   if (isr != null) {
    isr.close();
   }
  }

  //apachecommons使用
  //最後の改行コード削除
  return StringUtils.chomp(bul.toString());

 }

}

リクエスト発行編へ

文面が長くなってきましたので、今回はここまで。
次回はいよいよ、上記ソースを使ってレスポンスの中身を検証してみます。

Yahoo! Web API 登録編

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

しばらくは世に溢れる「WebAPI」の機能について検証していきたいと思います。

最初はヤフーのWeb APIです。

Yahoo! Web API

YahooはWebAPIをいくつも提供しておりまして、その種類も豊富。
WebAPI界の大御所と言えるでしょう。

しかも良い所は、日本語の説明ドキュメントがある点ですね。
Google、FaceBook、Twitter辺りだと英語しか無いので、大変助かります。

公式サイトは以下です。

http://developer.yahoo.co.jp/

さて、早速テキトーにリクエストを投げて……ん？

どうやらリクエスト送信には「アプリケーションID」の取得が必要なようですね。

このようにWebAPIにはIDの取得を求められることが多いです。
WebAPIは使えば使うほど、WebAPI側のネットワークやサーバの負荷が掛かりますので、誰がどれくらい使っているかを管理する為にIDが必要ということですね。

従量課金制になっている所も多く、リクエストが多いIDほど、多くの金が取られるということです。

• WebAPI業者はIDで使用者を管理している。

逆に言いますと、「ＩＤさえ分かればなりすまし可能」という意味ですよ。

つまり、「JSファイルにIDをベタ書きして、Ajaxでリクエスト発行」とかやるとJSソースを解析されてIDが盗まれますので、
大事なIDはサーバ側で保管しておき、WebAPI発行はサーバ側から行うと良いでしょう。

• WebAPIのリクエスト発行はクライアントサイドからAjaxでも行えるが、セキュリティを考えるならサーバから発行した方が良い

以上、簡単なことですが大事なことなのでお忘れ無く。

アプリケーションID取得

では、本題のアプリケーションID取得に入りましょう。

YahooJapanにログインしている状態で以下のページにアクセスします。

• アプリケーション管理画面

ここの「新しいアプリケーションを開発」のボタンをクリックします。


すると、以下のような画面が表示されます。
（メアドが表示されていますので、その部分は隠させて頂きました）

これを見ると、「サーバサイド」「クライアントサイド」と、利用目的に応じて違う設定が必要なようです。
クライアントサイドの方に「OAuth 2.0 Implicit」と書いてありますが、これは超巨大なセキュリティホールが出来るという噂の認証方式……。
今回は「サーバサイド」を選択して進んでみようと思います。


そこから先に続くのは「アプリケーション名」や「サイトＵＲＬ」等ですが、今回は動作検証用ですので、
デフォルト値のままにしておきます。

最後に「同意」を選んで確認ボタンをクリックしますと、確認画面を表示した後に、ＩＤの取得が完了します。

次の画面に進んだ時には、もうＩＤが発行されています。
（モザイクで見えなくさせて頂いておりますが）

簡単ですね！！

アプリケーションＩＤは「ハッシュ値」みたいな文字列です。

上記にもありますが、アプリケーションＩＤは大事な値ですので、推測も出来ないようになっていなければなりません。
更に一意性も必要ですので、「ログインＩＤ＋シーケンス番号した文字列をハッシュ変換」といった方式で出力しているものと推測されます。

そしてもう一つ、「シークレット」というものが出ています。
これにつきましては、調べたのですが詳細が分かりません。
YahooにはユーザＩＤがバレてもログイン出来なくする「シークレットＩＤ」なる機能もありますが、こちらはそれとは別物の模様。
詳細が分かり次第、記事にしたいと思います。


さて、これでIDの取得は完了です。
もうWebAPIを発行出来る状態になっています。

試しに、画面に表示されているサンプルリクエストを送信してみました。

ちゃんとレスポンスが返ってきていますね。
これで動作確認も取れました。

後は発行するだけでＯＫです。
実に簡単でした。

次回

次回からは、いよいよ本格的にWebAPIの機能検証に入ります。

WebAPI 導入編

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

今回から「WebAPI」の連載をスタートしたいと思います。

WebAPIとは

連載のテーマであるWebAPIとは、特に厳密な定義があるわけではないのですが、要するにインターネット経由で余所からデータを取ってくる機能のことです。

例を挙げるとすると、ヤフーのニュース記事の下にあるTwitter部分。

これです。
これはヤフーのその記事と関連のあるツイートを表示しているわけですが、これをどうやって取得しているのかと言うと、Twitterが提供しているWebAPIを利用しているのです。

• https://dev.twitter.com/docs

カラクリとしましては、HTTP通信でリクエストを投げると、レスポンスで「XML」か「JSON」かの形式で返ってきますので、それをパースして……。
と難しい話は以降の連載にしましょう。

ようするに、「リクエストを送信すると文字列が戻ってくるので、それを画面に出す」というだけのシンプルな機能です。

もちろん、こういった機能は自前で作ることも、別に難しいことではありません。
自前でWebAPIを作って公開し、使用料を取るというビジネスも普及しています。

WebAPIのニーズ

このWebAPIというサービス形態は昨今……というにはちょっと遅い気もしますが、最近注目のサービスです。
理由としましては、やはりスマートフォンやタブレットといった次世代携帯端末の存在でしょう。

これらの機器は内部にアプリを入れて機能するわけですが、やはり携帯端末ですのでリソースが少なく、そんなに重い機能を実装出来ないのです。
そこで、重い処理はWebAPIを動かしている巨大サーバで行って、必要な情報だけを取得して携帯端末に表示する。
そんなエンドユーザ端末の機器に優しいことがWebAPIの長所です。

WebAPIの現状

とは言え、私はWebAPIを使ったシステム開発は一度しかありません。
注目度の割にはあんまり出番が来ないサービスというイメージがあります。

その理由として、二つの理由を考えてみました。

１．出番が無い

まずはこれでしょう。
「Twitterの情報を取得したところで遊びにしか使えないじゃないか」みたいに、不特定多数のエンドユーザを想定したサービスが多いです。
元からオシャレなスマホアプリ作成を生業としている人ならともかく、私のような企業向け業務システム開発が中心のエンジニアには滅多に使用機会が訪れないのです。

２．お金＆余所様のデータであること

もう一つの理由は、これ。
WebAPIはどこまで行っても他社様のデータを貰ってくるサービスですので、契約とか権利とかの理由で、業務用には敬遠されてちまいがち。軽く使いたいだけでも「法務部」とかそんなレベルの話になってしまい、内部調整が非常に大変です。

何より困るのが「仕様変更」ですね。
少し前にTwitterが急に仕様変更したせいで取れていたデータが取れなくなり潰れたサービスがありました。
WebAPI提供業者の都合に振り回されてしまうのも欠点です。

WebAPIの利用価値

このように難点も多いWebAPIですが、一方で凄く便利で高機能なサービスがあるのも確かです。

業務用システムエンジニアである私の立場では、「天気予報取得」「居酒屋の口コミの取得」など永遠に出番が無さそうなサービスも大量にありますが、中には「漢字に読み仮名を降る」「PDF変換」など、もしかしたら使い道もありそうな雰囲気のサービスもちらほら見かけます。
興味が湧いてきましたね。

というわけで、今回の連載では「業務用システムエンジニアから見たWebAPI」というテーマで、調査したWebAPIのご紹介をしていこうと思います。

次回予告

最初はヤフー提供のWebAPI『テキスト解析API』から調査開始です。