【GAE】スタート編１ アカウント作成

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

只今、クラウド基盤「Google App Engine(以下、GAE)」について連載を始めたばかりです。

さて、GAEについて連載すると言いましても、その規模が超膨大でどこから初めて良いやら……、という状態です。
ひとまず、連載最初は「スタート編」と題しまして、とにかくプロジェクトを始めてみましょう。

スタート編でやること

• Googleアカウントを作る。
• とにかくプロジェクトを始める。(接続先URLの確保)
• Eclipseセットアップ
• Eclipse内でプロジェクト作成
• リリース

以上です。
「これくらい、マウスでちょっとカチカチやるだけで終わるだろ」と思ってはいけません。
これだけでも詰まるのがGAEです。

悪戦苦闘した私の記録が、少しでも後の世の発展に繋がることを切に願います。

アカウント作成の前に

最初はアカウント作成です。
GAEを使うにはGoogleアカウントが必要です。

ここで早速、第一チェックポイントです。

Googleアカウントを使ってGoogleにアクセスして開発するわけですから、「社内/社外」という概念はありません。

普通の開発の場合、

• 開発環境は社内からしか参照できない場所にあるサーバを使う。
• 本番環境はインターネットに公開するサーバに展開する。

まず大抵はこのような体制で開発しています。

GAEにはこのような「社内/社外」という概念はありません。
本番環境も開発環境も同じくインターネットに繋がっており、家からでも普通にアクセス出来ます。

場所を問わないことがクラウド開発の非常に大きなメリットです。
お客様にもアカウントを用意して貰えばお客様も開発環境に入ることが可能ですので、開発の進捗状況をリアルタイムかつダイレクトに報告出来るのです。
仕様変更などを電話相談する時も便利そうですね。

しかし一方で、家からでも開発環境、本番環境、両方にログイン出来てしまう環境ですから、セキュリティ的には従来開発よりも低いです。
このセキュリティ水準を認められない開発の場合は諦めるしかありません。

ただし、アカウント毎に権限を付与して、「本番環境にログイン出来る人はこの人だけ」「開発環境にアクセス出来るのはこの人だけ」というような運用は出来ます。
また、「この人が何時何分にこういう操作を行った」という記録も残っています。

この辺りがGoogleのセキュリティ水準の方針なのですね。

その辺の管理権限につきましては、しばらく後、別の章でご紹介することになると思います。

アカウント作成

では、アカウント作成に行きましょう。
すでにアカウントを有している人は作成する必要はありませんが、それでも読んで損はない情報を以下に記載します。

皆様ご存じ、Googleのトップページの右上に「ログイン」というボタンがありますね？

その人のログイン状況に応じて少し画面は違いますが、とにかくその先から以下のような「アカウント作成画面」に進むことが出来ます。
ここに名前や、希望するアカウント名、パスワード等を入力していきます。

ここで第二チェックポイントです。

名前は個人名にして下さい。

上の画像には「遠藤　太志郎」と入っていますよね？
そう、名前は個人名でなければいけません。

「このアカウントは管理者間で使い回しする予定だから、名前は『ジェニシス　アドミン』にしよう」

とかダメなんですよ。

『ジェニシス　アドミン』のように個人名ではない名前を入力してアカウントを作ると、そのタイミングでは確かに入力出来ます。
しかし、数日内にGoogleより「ポリシー違反です。修正しなければアカウントを削除します」みたいな警告が届いてしまいます。
「個人名判定ロジック」が定期実行されているのです。

これはGoogle+の名前付けポリシーによるものです。

https://support.google.com/plus/answer/1228271?hl=ja

最近のGoogleは全機能をGoogle+を中心に連結する試みがなされており、Google+を使うつもりが無くてもGoogle+の影響下に置かれてしまいます。

「アカウントの使いまわしをするな。ちゃんと権限で管理しろ」というGoogleの意思表示なんですね……。

よって、共通の使い回しアカウントはなるべく使わないことをオススメします。
どうしても共通アカウントが必要な場合は、代表者の名前を入力すると良いでしょう。
（偽名を考える、という手もありますけどね）

ここまで

長くなってきたので今回はここまでです。
アカウント一個作るだけでもこれだけ色々あるのです。

次回はプロジェクト作成からスタートします。

【GAE】Google App Engine 始めに

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

最近……、というほど最近ではありませんが、
最近のIT業界ではクラウドへの関心が高まっていますね。

しかしIT業界にクラウドがどれくらい普及しているかと問われると、まだまだ発展途上だと思います。
発展途上であるということは、今がチャンス、狙い目です。

クラウドにも複数種類がありますが、これからしばらくの連載では、私がロックオンしたGoogle App Engine(以下、GAE)についてご紹介していきたいと思います。

クラウドとは

GAEの話は膨大ですので、最初である今回はクラウド周りの小話からスタートしたいと思います。

さて、この連載のテーマである「クラウド」ですが、「クラウドとは何か？」と問われると、私も困ってしまいます。
余り定義が明確ではないのです。
どんなクラウドでも必ず共通する特徴としましては「インターネットの先にデータが置いてある」ということですけれども、それを言っちゃあ今の世の中、何でもインターネットの向こうじゃないですか。
昔はインターネット常時回線の無い時代があったと伝え聞いていますが、今の若い世代にとっては「歴史の授業」みたいな感覚です。
今の時代は「インターネット＝当たり前」ですので、そこをアピールしても特徴になりません。

また、一時期クラウドという言葉が流行りましてね、「単なるレンタルサーバなのに、クラウドサービスを騙る」という詐欺みたいなサービスも少なくなかった。。。

定義が曖昧なので「クラウド」と言っても人によって認識が分かれてしまい、私は軽率に「クラウド」という単語を使うことを避けています。
しかし、最近はようやく「クラウド基盤」として認められるだけの価値のあるサービスが安定してきました。
いずれ「クラウド」という言葉の乱用乱発にも終止符が打たれると思います。

今回、連載のテーマとしているGAEも、代表的なクラウドたるクラウド基盤として認知されているものです。

クラウド基盤

クラウド基盤を標榜するサービスは複数あります。

• Google App Engine(Google)
• Amazon EC2(Amazon)
• Force.com(Force.com)
• Windows Azule(Microsoft)
• さくらのクラウド(SAKURA)

キリが無いのでこの辺にしておきますが、とにかくクラウドを名乗るサービスは沢山あります。
海外製の方が主力ですが、日本製もありますよ。

しかし、上記にもありますように、「詐欺みたいなクラウドサービス」もありますので、クラスド基盤選択は慎重にご検討を。
ここでは名指ししませんが、昔、担当者の作業ミスでバックアップも含めて多数のサーバのデータを丸ごと消し飛ばしたトンデモ企業があり、発展途上だった日本のクラウド業界に盛大に冷や水をぶっかけたのです。。。

まあ、そんなトンデモサービスは置いておいても、クラウド基盤には個性があります。
アプリケーションの要件に応じて向き不向きがありますので、導入の際はそれらに見識を持っていることが肝要です。

寄らば大樹の陰

そうは言うものの、複数のクラウドサービスに精通している人なんてそうそういません。
クラウド基盤というのは、その利用方法を習得して理解を深めるのに多大な勉強コストが必要になります。
一口に「クラウド基板」と言っても、それぞれ全然別物。
一人で全部習得するのはかなり厳しく、むしろ特定のクラウド基板を「得意分野」として習得する方が現実的だと思います。

その中で今回、私がGAEを選んでいる理由としましては、以下があります。

１．Googleであること

最大の理由はコレ、提供企業がGoogleであること、ネームバリューです。
クラウドサービスはデータの保管を他社に丸投げしてしまいますので、その会社が潰れたり、障害でデータが消し飛んだりしたら一貫の終わり。
何よりも信頼性が第一です。
技術、経営、歴史、実績、知名度……。そういった全方位的信頼性が何よりも重いのです。

「日本のクラウド基盤業者の方が日本語が使えて分かりやすいし……」とか、そんなのは二の次。
クラウド基盤本体が頑強であること、これが最優先となります。

２．簡単らしい

上記にも「クラウド基盤は習得に勉強コストが必要」と書きました。
クラウド基盤開発は普通の開発よりも、開発者に高い技術的ハードルを要求してきます。
GAEは、そのハードルが比較的低めであると言われています。
実際、この連載を始めるにあたってある程度調査を行っていますが、シンプルな作りになっていると思いました。
まあ、それでも十分難しいと思いますが、他よりはやりやすそうな印象です。

クラウド基盤は以下の相反するどちらかの性質があると言われていますが、

・特定分野の開発に絶大な開発効率を発揮するけど、応用が効かない。
・色々と応用が効くけど、開発効率はそんなに高くない。

GAEは下です。
シンプルである代わりに手間暇は必要ですが、その分だけ理解が早く、リスクも低いです。

「参入ハードルの低さ」

私はここが気に入っています。

ただし、相対的に簡単というだけで、やってみるとやっぱり結構難しいです。
経験の浅い人がいきなり始めるのはオススメ出来ません。
最初は普通の開発で基本的スキルを身につけ、応用力をつけてからGAEに参戦するのが良いと思います。

３．Javaが使える

これは完全に私個人の都合ですが、私はJavaが第一言語ですので、Javaを使わせて貰えると大変助かります。
他のクラウド基板でもJavaを使える所はありますが、Googleと言えばAndroidの提供も行っている会社ですよね。
AndroidもJavaで動いているのは言うまでも無く。

つまり、Googleは全てのクラウド基板業者の中で一番のJavaの守護神なのです。

他の基盤を選んでおいて数年後、
「ウチはJavaを支持しないからJavaのサポートをやめます。代わりに.NETを使ってね」
なんて事になったら困りますから。

Javaプログラマーとしては、やっぱりGoogleの存在は絶大なのです。

おわりに

第一回である今回はご挨拶ということで、雑談ベースになりました。

クラウド基板というのは、「サーバ」でもなければ「ＯＳ」でもなく、言語でも無ければDBでもネットワークでも無い。
サービスリリースに必要となる全ての技術をまとめた総合パッケージですので、必然的に習得しなければならない技術が膨大になります。

連載に当たっては相当な長期化が予想されますが、末永くお付き合い下さい。

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

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