ニューラルネットワークはポケモンの夢を見るか

TensorFlow(及び、ニューラルネットワーク)を使用して以前からやってみたいと思っていたことは数値処理だったりします。今回それに関して試してみることにしました。

対象を探していた時、ポケモン・サン&ムーンを見て思いつきました。フェスサークルのアトラクションに「タイプ相性 診断!」というのがあります。このミニゲームでは効果が「バツグン」なものを判断するというテーマになっています。例えば、その対象が「むし」「くさ」だと答えはほのおとなり、 「こうかはバツグン」ということになりポイントが入ります。この相性として、弱い順から「効果がない」, 「効果は今一つ」, 「普通」そして「効果はバツグン」という4つに別れます。

相性は表になっていますので、機械学習の余地が入る部分はあまりないのですが、はたして失敗から学ぶというアプローチは可能かどうかを試してみることにしました。

かなりのフェスチケットを消費して80ケース程度のログを貯めることができました。このようなデータを処理するための前処理など、初心者でありますので、何らかの参考文献を探したのですがTensorFlowは画像処理に偏った情報が多く、似たようなアプローチを取っているものとしてmtitg氏による、TensorFlowを使ったディープラーニングでタイタニックの生存予測という記事に行き当たりました。

氏の例では8個のパラメータを使用していますがポケモンでは3つのパラメーターになります。こちらで紹介されているコードはテキストのデータの前処理なども含め、非常に参考になるものでした。

こちらを当てはめたコードを使用して検証してみました。結論から言うと、80件程度のデータからは50%ほどの正答率しか得ることしかできませんでした。これは次の理由があるように思われます。

  • 手動で集めたデータであるため、データのバラエティが少なく、かなり多岐に渡るポケモンの相性の組み合わせを考えると一部しかカバーできていない。
  • 「普通」のデータが多すぎる。例えばほのおに影響を与える「むし」など、そういったものがない場合は「普通」になってしまう場合が多い。そのため、データは「普通」に傾いてしまい、他の3つのものよりも多くなってしまっている。
  • ニューラルネットワークはこの手の構造化されたデータには向かないのかもしれない。ロジスティック回帰やベイズアルゴリズムに向いた課題なのかも知れない。

結論

先に書いたように、相性のデータが存在している以上、あまり実用向けとは言えないが学習と楽しみには適切に感じました。

さらなる最適化と研究により、TensorFlowや機械学習はすでに存在するデータセットなどに対して、その中から意味ある見地を読み取るのに非常に有用であると感じ、また、さらなる価値を見出すことができるのではないかと考えます。画像認識や自動運転車など機械学習の応用として非常にクールではありますが、すでに手持ちのPCなどでこの技術を応用するという点に関して決して軽視されるべきではない分野なのではないかなと感じます。

PythonベースのノートブックシステムJupyter

最近よく使用しているツールでJupyterというのがあります。

特徴は

  • Pythonベース、元はIPythonというもので、インタラクティブなPython環境を提供するシステムだった。
    • 今はPython以外も使えるようになったので、Project Jupyterとなった。IPython自体はインタラクティブなPython環境を提供するものとして開発が続けられていて、JupyterもPython実行部分では使用している。
  • 表記記法としてMarkdown(LaTeX文法も使える!)を使用可能。
  • コード部分はノート内で実行可能。

というようなものです。(個人的にはPythonでしか使っていないので、他の言語部分については使用感などはよくわかっていません……。)

個人的に気に入っている点は

  • Pythonの様々な機能を利用できる。例えば、Tensorflowなどのライブラリも使える。目的に応じてSciPyNumPyを利用して高度な計算やプロットなどをしたり、SymPyを使用してCAS(数式処理システム)として使用できたり、Pandasや各種のPythonの内蔵のライブラリを使ってデータベースへのアクセスなどができたりします。
  • ノートは保存して共有できるので情報共有も可能。尚、nbviewerというのも存在しておりオンライン上に存在するノートブックを閲覧することも可能です。GitHubGistなどはこのため、ノートブックファイルを表示することが可能。
  • コードをPythonとして保存することも可能なため、インタラクティブに実行するPythonコード開発環境としても使える。表記したノートなどはコメントとして出力してくれる。

導入は個人的にはLinuxとWindowsで試しましたが、Anacondaを使用するのが一番楽だと思います。

(ちなみにAnaconda自体は商業プラットフォームとして追加のモジュールを販売していますので、特に業務利用などで追加のサポートや機能が必要で予算が取れる場合は、そのような方向にスケールできる、というメリットもあります。個人使用にはお高いですが……。)

もちろん特にLinuxの場合はそのままpipを使用してJupyterを入れるという方法もあります。

また気が向いたら細かい部分についても解説していきたいと思います。

LINEのLetter Sealingその後

以前、これまで、LINEのE2EE実装「Letter Sealing」初見LINEのLetter Sealingに関するフォローアップと2回に渡り、LINEのE2EE実装である、Letter Sealing機能に関して取り上げてきたわけですが、以前にも増してメッセンジャーにおけるE2EEが一般的になってきました。以前はE2EEを実装したメッセンジャーアプリはSignalTelegramぐらいしかなかったのですが、今ではFacebook傘下のWhatsappにもSignalと同じ方式のものが実装されましたし、また、Facebook MessengerもまもなくE2EEが実装されるようです。他にもGoogleもビデオチャットアプリであるDuoはE2EEを使用している他、また今後リリース予定のメッセンジャーAlloにもE2EEの実装が予定されているようです。

さて、最近、LINEのEnginners’ Blogにおいてメッセージの安全性のさらなる強化:Letter Sealingの適用拡大という記事が公開されました。内容的にはLetter Sealing機能が更新され、デフォルトでE2EEが有効となり、また、音声やビデオ通話、及びグループチャットにE2EEが使用できるようになった、ということです。

今回の更新で、以前、指摘した、暗号化されているかどうかがわかりにくい、という問題が解決したと思われます。ただ、今回の更新で、暗号化されているのがわかるようになったのですが、以前の記事で「現時点では、Letter Sealingはテキストメッセージと位置情報に対してのみ適用されます。」となっていますが、これが現在どのような実装になっているのかが気になるところです。(今回の記事でこちらの件に関しての言及はなかった。)もし、引き続き、Letter Sealingが「テキストメッセージと位置情報の対してのみ」行われているのであれば、こちらは錯誤を招く表示になってしまいますので、こちらは「何が暗号化されるのか」の詳細を知らせて欲しいところです。

次に、せっかくE2EEを実装しているのだから、もっとアピールしてもらいたいところです。現在、定点観測できるいくつかのトークグループがありますが、半分程度、この機能が有効になっていないグループがあり、そのほとんどが恐らくアプリの更新を怠っているのが原因であると考えます。LINEのユーザーは特にユーザー層が広く、技術的リテラシーにばらつきがあり、こちらは更新を促す施策を是非考えて欲しいところです。

Clannad英語版の特徴

そういえば、Clannad英語版の本編、まだ詳細を書いてなかったかも。
Clannad英語版タイトル画面
基本的にはClannad Fullvoiceが英語になっているものです。
メニュー項目で増えているのは「Dangopedia」と「Achivements」(実績)ですね。(ゲーム機版には実績機能はあるのかも知れませんが……。)
Clannad実績
この画面はSteam版のものなので、Steamの実績と連動しています。Dangopediaは本編と連動した機能で、文中に出てくる単語を解説してくれる機能です。
Clannad単語ハイライト
例えば、この画面では「anpan」という単語が赤くハイライトされています。これはDangopediaに当該項目があることを意味しています。
Clannad Dangopedia
例えば、この場合、anpan(あんぱん)に関して、Dangopediaに上記のような形で解説されています。
ちなみに英語版においては、三点、向上している点があります。
一点目は画面のアセットがHD版になっている、という点。
Clannad画面サイズ
上の画面サイズは1680×1050ですが、そのサイズに比べても内容が高解像度で表示されていることがわかります。(この画面写真はWINEで動作させているものなので、実際にネイティブ環境で動かしている場合は一部表示が異なる場合があります。もちろん、WINEでの動作は公式のサポート外です……。普通には動くのですが、ムービーの再生などに難があるので、一般人の人は普通にWindowsで動かしましょう……。)
二点目は、音楽がリファインされている点。こちらは違いは微妙だったりするのですが、印象が異なっている曲はあります。
三点目はDRMがなくなっている点。プレイするのにディスクを入れる必要がありません。ちなみにSteam版ではSteamクラウドに対応しているようで、セーブデータはオンライン保存ができるようになっています。
と、まあ、各種メッセージ等は英語ですが、声なんかは普通に日本語ですので。Sekai Project版ではプラネタリアンなんかは日本語も設定できるようにしてくれていますが、これがClannadに踏襲されるかは分かりません。(Dangopediaなど、独自作成部分が多いから難しいかな……Steam上で表示される実績は日本語ですが。)

Clannad英語版(ディスク版)開封の儀みたいなもの

本記事においてサウンドトラックに関する更新を行いました。

今日、この大きな箱が到着。
Sekai Projectより到着した箱
結構大きい……。ゆのさんと比べるとこんな感じ。
ゆのと大きさを比較
開封の儀みたいなものをやってみます。
開封
中は大きくともまあ、ほとんどが緩衝材です。
内容
内容的にはTierとして指定したものではなくて、デジタル版・ディスク版セットの上にいろいろとアドオンを追加したりしたものです。尚、プロジェクト自体はまだ続いている部分があるので、これは完全な発送ではないようです。

このボックス内の内容は:

  • Clannad英語版本体
  • ミニ色紙セット
  • オリジナルサウンドトラック
  • タペストリー

ミニ色紙セットは、箱の絵、実は持ってたりする画集の表紙の絵、もう一つは多分描き下ろしになっています。
Clannad英語版ボックス
ゲーム本体は特別な箱に入っています。
Clannad英語版ボックス裏面
裏はこんな感じ。
Kickstarterシリアル番号
シリアル番号が打ち込まれていて、自分のは920でした。自分のバッカー番号が1424だったので、もしこれが同じ基準であるとすれば、ディスク版を追加したのは65%ぐらいなのかも。ただし、1400番台ということで、結構熱心なファンが多い頃合いだったかも知れないので、このあたりは完全に憶測の域を出ません。そもそもこの番号が対応しているのかもわからないので。この箱に関してはもう少しあとで。
Clannad OST
サウンドトラックは日本で2014年に販売されたKSLA-0012〜14です。と考えると、ゲーム内の音楽はリファインされているということですので、実はこのサウンドトラックの一部はゲーム内のものと異なる、ということですね。

2016年9月29日更新:Sekai Projectによると新バージョンのサウンドトラックは提供されるとのことですが、デジタル版のサウンドトラックを選択した人のみに提供されるとのことです。これはデジタル版にこのような「特典」が付くことが出資(Kickstarterの場合、資本関係に入るわけではないので、事実上の「予約販売」です)前に知らさせな商品価値を不当に誤認させる不当な対応です。本件について、Sekai Project側は日本側の判断であるとのことですので、Visual Art’sに9月27日に問い合わせていますが、9月29日現在、未回答となっています。

ゲームの箱に移ります。
Clannadガイドブック
箱を開けるとまず入っているのがオフィシャルガイドブック。紙質も内容もなかなかしっかりしています。
Kickstarterバッカーリスト
Kickstarterのバッカーのリストがあるのですが、アルファベット順でもなく、自分を探し出すのに20分ぐらいかかりました。どんな順番になっているのかは不明。
Clannad英語版ディスク
その下に入っているのが英語版ディスク。ちなみにDRMはかかっていない(はず)です。
Clannad MABINOGI
その下に入っているのはアレンジサウンドトラックのMABINOGI。これは確か日本でも初回版以後は入ってなく、別売りもなかったと思うので新品としては実はかなり貴重なのかも知れません。
Clannadタペストリー
最後にタペストリ。こちらは箱の絵と同じです。
ということで、開封の儀(みたいなもの)でした。WINE立ち上げてプレイせねば。

なぜInboxよりもGmailが使いやすいか

ここ半年ほどInboxを使ってきましたが、Gmailの方が使いやすいな、と感じる部分がいくつか。ちょっとまとめてみる。

Inboxでの利点

Inboxのナビゲーション自体は良く出来ていて、全体的には使いやすいと感じる。添付ファイルなどが入っているとそれが大きく表示されるし、また全体的に使っていてより楽しいのがInbox。

処理的にもかなり意欲的な出来であり、メールの扱いのやり方を変えよう、という発想があるのは面白い。

短所と感じる部分

でも使っていて、使いにくいと感じる部分も多い。ほとんどがGmailで出来て、Inboxで出来ないことなので、かなり惜しく感じてしまう。

アドレスごとの署名管理がない

InboxではGmailと同じように複数のメールアドレスを管理できるのだが、Inboxには他のアドレスを使用した場合に、署名を切り替えることができなくなっている。コンベンション用など使い分けているのでこれができないのは非常に致命的。

HTML形式がデフォルトで変更できない

Inboxは送信メールはHTML形式がデフォルトであり、切り替えることができない。Gmailにはテキストメールへの切り替えができるようになっている。妙なメタデータが紛れ込んだりするので、できるだけHTMLは送信しないようにしているのでこれはかなり不便だったりする。

ソース表示ができない

これは多分99%の人には関係ないのだろうけど……。Gmailのメールはソースを見ることができないので、ヘッダの確認などをすることができない。微妙なメールが届いた時にざっと確認する場合もあるので、是非欲しいところなんだが。

変更ができない言語に依存した返信ヘッダ

これも煩わしい問題。Gmailで返信をすると次のようなヘッダが追加される。

2016-02-17 13:26 GMT-08:00 John Doe <johndoe@example.com>:

これをInboxですると次のような感じになる。

2016年2月17日(水) 13:26 John Doe <johndoe@example.com>:

なぜGmailの方が優れているかというと、受取人の言語に依存しないから。受け取る人が日本人であろうと、あメリカ人であろうと全く問題がない、言語非依存の形式お使用しているのがGmail。Inboxの場合、日本人しか読めない。せめて形式を指定できればいいのだが。

まとめ

上記を書いた後に考えると、恐らくInboxが想定しているのは読むのが主で、カジュアルなユーザーなのかな、と。Gmailにある機能がInboxに入るかその逆があればすごいいいと思うのだが……。

なぜGrub2の認証脆弱性は大きな問題ではないか

Linuxのブートローダー、Grub2にバックスペースを28回押すとレスキューシェルに入れてしまうバグがあるということがこの数日報道されています。

脆弱性があるということ自体に問題があるということを否定するわけではありませんが、まず、Grub2を含む、ブートローダーの認証を過信するのが問題です。実質的にブートローダーの起動パスワードが入力できる状態であるということは即ちハード自体へのアクセスがあることを意味します。ハード自体へのアクセスが行えるのであれば、ブートローダーをUSBドライブ経由などから読み込ませて起動すれば、レスキューシェルなど、簡単に実行できてしまいます。ハードのアクセスが物理的に行える以上、この脆弱性が存在しようがしまいが、本質的にはセキュリティには全く影響しないのです。

そのため、セキュリティ問題としてこの問題を解消するには次のような施策が必要になってきます。

  • ハードへの物理的なアクセスを制限する。
  • パーティションを暗号化する。

尚、Grub2の認証機能自体、そもそも幻想のセキュリティを提供する形になってしまっていますので、本来はこんな機能自体削除しまったほうがいいぐらいです。(カジュアルな運用でレスキューシェルへ簡単にアクセスできてしまうこと自体が問題になるのであれば、ブートローダーからレスキューシェルは取り外して、必要に応じてそれを有効にしたブートローダーを外部メディア経由で起動するほうが余程マシな運用です。)