システムの概要図


機械学習モデルの構築


訓練データの収集


今回私たちが立ち向かうタスクは、入力されたキーのシーケンスからユーザーが意図する文字を予測することです。オンライン手書き文字認識に似たタスクではあるものの、その多くはペンタブレットやタッチスクリーンでの入力を前提としています。そのため、キーボードのように低解像度の入力に対応した機械学習モデルを構築するためには、一から訓練データを収集する必要がありました。

データを収集するため、私たちはまずデータ収集用のウェブアプリをつくることから始めました。入力する文字を指定してキーボード上にその文字を書くことで、入力されたキーのシーケンスが保存されるシンプルなアプリです。効率的なデータ収集のために、慣れた方には画面をタップすることで入力終了を判定する待ち時間をスキップする機能も搭載しました。その結果、プロ級の方になると 1 分間あたり約 60 個のデータを入力することが可能になり、高速なデータ収集が可能になりました。



人手によるデータ入力にはミスがつきものです。異常なデータをすばやく見つけて取り除けるよう、入力シーケンスの可視化インターフェイスも実装しました。他にも入力データ数による Contributor ランキングや各文字の累計データ数の表示など、データの入力をモチベートする細かな仕組みを搭載しています。



リリース前には社内で筆跡データ収集会を実施し、有志の Google 社員にデータ入力を手伝ってもらいました。その結果、約 4 万 6000 件の訓練データを収集することができました。収集されたデータは GitHub にて公開しています。データ構造の詳細については README をご覧ください。



データの前処理


訓練に使うデータは、以下のような入力されたキーのシーケンスによって表現されます。以下はひらがなの「い」が入力された一例で、各タプルは keydown イベントが発生したキーと発生した時間をミリ秒で表しています。ここでは複数のキーが同時に押された際の keydown イベントと keyup イベントの対応を特定する煩雑さを避けるため、ここでは keydown イベントのみを使っています。

[("e", 0), ("d", 55), ("c", 102), ("u", 428), ("j", 507)]

私たちはこのシーケンスデータから高精度に文字を予測する機械学習モデルを模索しました。その過程でキーボード上でのキーの位置がキーだと気づき、シーケンスデータを画像情報に変換して畳み込みニューラルネットワーク(Convolutional Neural Network)を適用することにしました。以下では、シーケンスデータから画像情報を抽出する具体的な方法について説明します。

まず、シーケンスデータに含まれる各キー情報を JIS キーボードの QWERTY 配列を前提として x, y 座標情報に変換します。

QWERTY キー配列と x, y 座標系の対応


先ほどの「い」の例では、シーケンスが以下のように変換されます。

[((2.5, 1), 0), ((3.0, 2), 55), ((3.5, 3), 102), ((6.5, 1), 428), ((7.0, 2), 507)]

次に、x, y 座標に対して min-max 正規化を施し、各キーの x, y 座標を 0 から 1 の間に収めます。その結果、シーケンスデータは以下のように変換されます。

[((0.00, 0.00), 0), ((0.11, 0.50), 55), ((0.22, 1.00), 102), ((0.89, 0.00), 428), ((1.00, 0.50), 507)]

最後に、シーケンス内の各点を順々につなげるようにして、16px 四方の正方形のキャンバスの上に描写します。


「い」を描画した例


指がキーボードから離れた区間については、ユーザーの指の動きを特徴量に組み込むために半分の濃さの線で描画しています [1]。物理手書き入力では、指がキーボードから離れたことを keydown イベントから特定する必要があります。ここでは keydown イベントが発生した間隔に着目し、あるキー間の keydown イベントの間隔が他の間隔よりも有意に大きい場合には指が離れたものと判定しています。

MobileNet によるモデルの軽量化


ニューラルネットワークモデルによる認識精度を向上するためには、ニューラルネットワークを多層にして表現力を向上することが有効です。一方で、ニューラルネットワークを多層にすると学習すべきパラメーターの数が増えてしまい、モデルのファイルサイズも大きくなってしまいます。学習済みモデルを Raspberry Pi Zero のような組み込み向けモジュールで使うことや、ブラウザにダウンロードして使うことを考えると、モデルのファイルサイズが大きくなってしまうことは好ましくありません。

そこで私たちは Google が提唱する軽量なニューラルネットワークモデル、MobileNet に用いられている分離式畳み込み層 (separable convolutional layer) を応用することでモデルの軽量化を図りました。分離式畳み込み層は、畳み込み演算を空間方向の畳み込み (depth-wise convolution) とチャンネル方向の畳み込み (point-wise convolution) に分けることによって、学習するパラメーターの数を減らします [2]。分離式畳み込み層を使うことによって、通常の畳み込み層による実装では数 MB になってしまうモデルのファイルサイズを、同程度の精度を維持しながらも 150 キロバイト程度にまで減らすことができました。これにより、後述するハードウェアとブラウザでの高速なモデルの読み込みが可能になりました。

ドメイン知識の活用


上記の方法だけでも文字を認識する機械学習モデルを構築できたものの、精度の面で課題が残りました。たとえば、単純にストロークを画像情報に変換するだけでは、右から左に書かれた線と、左から右に書かれた線を区別できなくなります。また、キーボードから与えられる位置情報は低解像度のため、本来は異なる線が重なって描写されてしまうこともしばしばです。こういったデータの前処理で落ちてしまう情報が原因となって、満足する精度を達成することができませんでした。ここでは、これらの課題を解決するために導入した工夫を紹介します。

まず、私たちは文字を構成する線を 8 方向に分解する方向分解特徴 (directional feature) を導入しました。方向分解特徴は手書き文字認識における重要なドメイン知識のひとつであり、入力データをスパースにすることで小さな画像の中にも効率的に情報を保持できることが知られています [1]。私たちは、単一のチャンネルに画像情報を変換するのではなく、方向分解を施すことで 8 チャンネルの画像に変換するアプローチを採用しました。


「あ」と書かれたストロークの方向分解特徴


方向分解特徴を採用しても、低解像度のために重なってしまう線については課題が残りました。たとえば「は」と「ほ」は画数が異なるものの、「ほ」の 3 画目が 2 画目と重なってしまうことが多く観測されました。このような課題を解決するためには、書き始めから書き終わりまでのどのタイミングで線が書かれるのか、という情報が有効に働くと考えました。

そこで導入したのが時間的特徴(temporal feature)です。方向分解特徴を表す 8 チャンネルに加えて、だんだん線が薄くなる画像とだんだん線が濃くなる画像を加えることで、全体的な時間変化を表した特徴を導入しました。既存の 8 チャンネルに加えてこの 2 チャンネルを加えることで、さらなる精度向上を実現しました。

「あ」と書かれたストロークの時間的特徴


下図に、各特徴量を利用したときの正確度の比較を示します。方向分解特徴、時間的特徴ともに文字認識精度の向上に効果があることが確かめられました。方向分解特徴が筆の動きを表すことで局所的な時間情報を組み込み、時間的特徴が書き始めから書き終わりまでの変化を表すことで大域的な時間情報を組み込むことで、精度向上に貢献していると考えられます。

確認用データセットにおける各特徴量の有無による正確度の比較


以上の特徴量を導入した結果、最終的な機械学習モデルは 16px 四方の正方形のキャンバスに対して 8 つの方向分解特徴と 2 つの時間的特徴を描画した計 10 チャンネルからなる画像を入力として受け取るものになりました。MobileNet のネットワーク構成を元にして、できるだけ少ない層の数で高い精度を実現する構成を模索した結果、以下のネットワーク構成に至りました。
  • 畳み込み層(カーネル: 3x3、フィルタ数: 32、ストライド: 2、活性化関数: Relu) 
  • 分離式畳み込み層(カーネル: 3x3、フィルタ数: 64、ストライド: 1、活性化関数: Relu) 
  • 分離式畳み込み層(カーネル: 3x3、フィルタ数: 128、ストライド: 2、活性化関数: Relu) 
  • 分離式畳み込み層(カーネル: 3x3、フィルタ数: 128、ストライド: 1、活性化関数: Relu) 
  • 全結合層


今回の訓練用プログラムは nazoru-input パッケージとして PyPi で公開されています。以下のように nazoru-input パッケージをインストールし、訓練データを指定して nazoru-training コマンドを実行することで、お手元の環境でも機械学習モデルを構築できます。今回用いた訓練データは https://github.com/google/mozc-devices/raw/master/mozc-nazoru/data/strokes.zip からダウンロードできます。

$ pip install nazoru-input
$ nazoru-training ./data/strokes.zip

この nazoru-training は標準的な TensorFlow の API を利用して実装されていますので、簡単にカスタマイズして利用していただけます。ハイパーパラメーターや入力データセットをコマンドラインオプションで変更することも可能です。詳しくは nazoru-training --help コマンドを参照してください。

ハードウェアでの推論


このようにして構築した機械学習モデルをユーザーが手軽に使えるようにするにはどうすればいいか、チーム内で活発な議論がなされました。パソコンやスマートフォンに特別なソフトウェアをインストールすることなくお気に入りのキーボードですぐに物理手書き入力を使えるようにするため、私たちは学習済みモデルを組み込んだハードウェア「物理手書きコンバーター」を製作することにしました。この物理手書きコンバーターは、訓練済みモデルを使って推論するプログラムを Raspberry Pi Zero にインストールしたものです。ここでは、物理手書きコンバーターを構築する手順を説明します。

推論用プログラムは訓練用プログラムと同様に nazoru-input パッケージ に含まれています。nazoru-input パッケージをインストールし nazoru-input コマンドを実行することで、お手持ちのコンピュータをつかって簡単に物理手書き入力を試すことができます。

$ pip install nazoru-input
$ nazoru-input


推論の機能を手軽に拡張して遊んでいただけるように、API もシンプルにしてあります。以下のようなコードを書くだけで学習済みモデルを利用した推論ができます。詳しくは nazoru-input のコードを参考にしてください。

from nazoru import get_default_graph_path
from nazoru.core import NazoruPredictor

predictor = NazoruPredictor(get_default_graph_path())

# [(key, ms_from_first_input)]
sample_input = [('e', 0), ('d', 100), ('c', 200), ('v', 300),
               ('u', 800), ('j', 900)]
results = predictor.predict_top_n(sample_input, 5)
for result in results:
 print('kana: %s, key: %s, probability: %.3f' % result)


物理手書きコンバーターは Raspberry Pi Zero に nazoru-input パッケージをインストールし、USB で接続されたキーボードから受け取ったキー情報を推論プログラムによって文字に変換、Bluetooth で出力することによって実装されています。このうち、キー入力から文字に変換する部分は基板がなくてもお試しいただけるので、ご家庭にある Raspberry Pi に nazoru-input ãƒ‘ッケージを入れるだけで手軽に手書き機能を利用したプログラムを実装することができます。

また、今回は物理手書きコンバーターのために製作した基板の設計図の CAD データを公開しました。この基板には Bluetooth 通信のためのモジュールやステータス表示のための LED が搭載されており、Raspberry Pi に接続することでパソコンやスマートフォンに Bluetooth を通じて文字を送信することが可能になります。利用する部品は Raspberry Pi Zero や RN42 といった通販や店頭で購入できるものに限定しました。Raspberry Pi Zero を利用することで大きさの制約も小さくしましたので、さまざまな形状のデバイスに組み込むことが可能です。CAD データを編集することで、自由に機能を変更、追加した基板も作製可能です。

さらに、公開されている基板には拡張性をもたせるために未接続のパッド、SPI・I2C 接続用のコネクタ、UART のための切断可能なパターンを用意してあります。これにより、モード切り替えスイッチを実装したり、SPI・I2C 接続のディスプレイによって軌跡を表示するなどの拡張が可能です。

物理手書きコンバーターのプリント基板図面


ブラウザでの推論


お手元に物理手書きコンバーターがない皆さまにもお手軽に物理手書き入力を楽しんでいただくため、私たちはブラウザ上で機械学習モデルが動作するデモを構築しました。TensorFlow で学習したモデルを TensorFlow.js に移植することでブラウザ上での推論を実現しています。

訓練用プログラム nazoru-training は訓練済みモデルを SavedModel 形式で出力します。SavedModel 形式で保存された訓練済みモデルを TensorFlow.js で読み込むには、TensorFlow.js converter を使って Web-friendly format に変換する必要があります。TensorFlow.js converter は変換のためのスクリプトと、変換済みモデルを読み込む Javascript API を提供するライブラリです。以下のコマンドのように tensorflowjs パッケージをインストールして tensorflowjs_converter コマンドを実行することで、訓練済みモデルを変換します。その際、変換するモデルの形式(この場合は SavedModel なので tf_saved_model)、出力層に相当するノードの名前(nazoru-training のデフォルト設定では Nazorunet/Predictions/Reshape_1)を指定します。

$ pip install tensorflowjs
$ tensorflowjs_converter \
   --input_format=tf_saved_model \
   --output_node_names='Nazorunet/Predictions/Reshape_1' \
   /nazorunet/saved_model \
   /nazorunet/web_model


変換が成功すると、tensorflowjs_converter は以下の 3 種類のファイルを出力します。
  • web_model.pb (the dataflow graph) 
  • weights_manifest.json (weight manifest file) 
  • group1-shard\*of\* (collection of binary weight files) 


ネットワークを構成する各パラメーターの重みは group1-shard\*of\* に記述され、モデルの大きさに応じて各ファイルが 4MB に収まるようにシャーディングされます。この工夫により、ブラウザにネットワークファイルがキャッシュされます。

あとは tfjs-converter npm パッケージをインストールし、以下のようにモデルを読み込めばブラウザでの推論ができます。

import * as tfc from '@tensorflow/tfjs-core';
import {loadFrozenModel} from '@tensorflow/tfjs-converter';
const model = await loadFrozenModel(
     '/nazorunet/web_model.pb',
     '/nazorunet/weights_manifest.json');
// Gets a canvas or image element.
const inputImage = document.getElementById('input-image');
const result = model.execute({input: tfc.fromPixels(inputImage)});
// Returns predicted probabilities for each class in a float array.
const probs = result.dataSync();

console.log(probs)  // Float32Array(88) [...]

アプリケーションによってはブラウザ上で高頻度で推論を繰り返すことも考えられるため、TensorFlow.js は効率的にメモリを管理するための便利なメソッドも用意しています。詳しくは Core Concepts in TensorFlow.js をご参照ください。

まとめ


以上、Gboard 物理手書き入力バージョンを支える機械学習技術を紹介しました。

「機械学習モデルの構築」では、効率的に訓練データを収集する仕組みの重要性について述べました。これまでにないタスクに取り組む場合、そもそも学習のためのデータがない場面も珍しくありません。そのような場合、データ収集を効率的に行うための仕組みづくり、インターフェイスの構築が重要になります。

ニューラルネットワークを多層にして表現力を豊かにすることがさまざまなタスクを解く上で有力である一方、機械学習応用の場が Raspberry Pi をはじめとする小型計算機やブラウザなどに広がっていることを考えると、高い精度を保持しながらもできるだけ軽量でシンプルな機械学習モデルを構築することは無視できない課題です。MobileNet をはじめとする軽量のネットワークモデルを採用すること、データの前処理に適切なドメイン知識を活用してモデルのサイズを保持しながらも精度を向上することが、このような課題に応える上で有効であることを示しました。

「ハードウェアでの推論」では、今回構築した機械学習モデルによる推論の方法を説明しました。Raspberry Pi を使ったデバイスの拡張方法についても述べ、推論プログラムに合わせてデバイスの振る舞いをカスタマイズする方法を紹介しました。

「ブラウザでの推論」では、TensorFlow.js を使ってブラウザで推論する方法を説明しました。TensorFlow.js Converter を使うことで簡単に訓練済みモデルの移植ができること、具体的な Javascript API の使用方法について述べました。

今回の記事が、さまざまなプラットフォームをサポートする機械学習システム構築の参考となれば幸いです。そして、Gboard 物理手書きバージョンが今後の文字入力のデファクト・スタンダードになる日がくることを願います。

参考文献


[1] Zhang, Xu-Yao, Yoshua Bengio, and Cheng-Lin Liu. "Online and offline handwritten chinese character recognition: A comprehensive study and new benchmark." Pattern Recognition 61 (2017): 348-360.
[2] Howard, Andrew G., et al. "Mobilenets: Efficient convolutional neural networks for mobile vision applications." arXiv preprint arXiv:1704.04861 (2017).


Written by:
- Shuhei Iitsuka - UX Engineer(Machine learning)
- Makoto Shimazu - Software Engineer(Hardware, System design)



この Google 日本語入力パタパタバージョン開発の裏話を聞くため、開発チームに集まってもらいました。ウェブマスターの小久保浩大郎と三浦健、ソフトウェア エンジニアの椎野裕樹、山口辰久、小松弘幸、マーケティングの虫賀千絵の 6 人です。

Q: Google 日本語入力チームは毎年様々なエイプリルフールネタを仕込んでいますね。まずは、なぜ今年はパタパタバージョンを作ることにしたのか、教えてください。

小松: Google 日本語入力は過去 2 回、エイプリルフールをやってますので、その流れは最初から意識していました。2010 年のドラム キーボードはキーの数が多すぎたので、その反省から 2012 年はキーの数を 1 つにしたモールスバージョンを開発しました。

山口: モールスバージョンにどんな課題があるのか? どんな改善ができるだろうか? と考えたところ......
椎野: 和文モールス符号を全部覚えなければならないのは、明らかな欠点だと気付いたのです!

一同:(コイツ...気付いてなかったのかよ... 最初からわかるだろ!)

小久保: キーの数は 1 つのまま、何も覚えなくても使える入力方法は何だろうと考えたところ、ダーツで入力できないか?というアイディアが出ました。文字を並べた板にダーツを投げるのです。馬鹿馬鹿しいでしょ?

山口: 「投げて当てる」と言えば、宝くじの抽選では番号を書いた回転する円盤に向かって矢を射りますが、同じ方法で日本語を入力できないか?というアイディアが出て...

椎野: 「回転するもの」と言えば、スロットマシンでも入力できそうだ、というアイディアが出たんです。他に似たものとして、歌番組の順位発表で使われる回転表示板、駅の発着案内板が候補に上がり、最終的に「パタパタ」というアイディアに辿り着きました。


初期のデザイン案

Q: 開発はどのように進めたのですか?

小松: 昨年同様に今年も実機(ハードウェア)とウェブ アプリケーション(ソフトウェア)の両方を作るつもりだったので、実機を山口が、ウェブ アプリを椎野が担当して並行して開発を進めました。今年はウェブ デザイナーの小久保もプロジェクトに参加してくれたので、サイト デザインを中心にビジュアル デザイン、UX デザイン全般を一任しました。

小久保: 各自の役割分担が明確でお互いに依存することが少なかったので、並行開発は簡単でした。JavaScript と CSS3 で書かれた体験アプリをウェブサイトに埋め込むのも一日でできました。

山口: 僕の方ではまず、パタパタの表示機構がどういう仕組みか調べるところから始めました。フラップ(パタパタと回転する板)を取り付けたドラムを正確に回転させることで特定の文字を表示するという、意外と単純なものであることがわかりました。ただ、フラップなどの部品を全部手作りするのは難しかったので既製品のパタパタ時計を分解して再利用しました。
使うボタンは 1 つだけというコンセプトからボタンはなるべく大きく、目立つものを選びました。筐体はパタパタに合わせて一昔前の家電やコンピュータを意識したデザインになっています。
モーターを正確に回転させ、また USB キーボードとして動作させるための電子回路部分は自作しました。これは去年のモールス キーの電子回路にモーターを 1 個制御する機能を付け加えたものになっています。

電子回路部分。緑のボタンを押すとモーターが回ります。

ビデオ撮影前に微調整。

椎野: ユーザーが体験できるウェブ アプリについては昨年の実績があったので、パタパタを回転させるアニメーションさえ実装できれば、あとは何とかなると思ってました。アニメーション GIF を使うアイディアもあったのですが、タイミングの制御が難しそうだったので、素直に CSS3 のアニメーション機能を使うことにしました。CSS3 のアニメーション機能は比較的新しい機能で、当時の Chrome、Firefox、Internet Explorer は最新バージョンでしか満足にサポートされていなかったのが最大の欠点ですね。
プログラム コードは昨年のモールスバージョンを大幅に再利用できると思っていたのですが、入力部分の仕様が細かく食い違っているため、予想よりもスクラッチから実装する部分が多かったです。

体験アプリの最初のデモ。CSS3 アニメーションで回るだけの簡単なもの。

小久保: ひとつの画面で多様なステータスを持つアプリ的性格の強いものだったのでそれらの管理と演出に苦労しました。アプリ的ということで、最初はタスク遂行効率を上げるためにユーザーの自由度を上げるモードレスな UI 設計を考えたのですが、今回の要件はシーンの演出・切り替えによってユーザーを誘導する性格の強いものだと気づいたため、シーンごとにユーザーの選択肢を制限したモーダルな設計に変更しました。
またシェアする URL はハッシュにメッセージをそのまま持たせるだけというシンプルすぎる仕様にしました。これは意図的なもので、ハックを簡単にすることで入力が面倒で難しくてもメッセージ表示の演出だけでも楽しんでもらおうと考えました。

Q: 技術的に工夫したところなど、教えてください。

椎野: 強いて言えば、クロス ブラウザ対応のコストを下げるために Closure Library を使い、かな漢字変換に Google Transliteration API を使ったくらいでしょうか。少人数かつ短期間で開発するために、あまり凝ったことはせずにシンプルな作りにしたのが一番の工夫ですね。

Q: なるほど。では、デザインで工夫したところがあれば、教えてください。

小久保: 現在の仕事ではリアルな物体の写真を扱う機会があまりありません。ましてや何かの模倣というのは普段はしないことなので、ここぞとばかりに楽しんでやりました。本物の駅の表示機は既に大半が LED 表示のものに置き換わっていて、昔のものでも実際には文字単位でパタパタするものはなかったため、空港の発着表示板のデザインを参考にしたりしました。パネル自体のデザインを CSS3 で行うことも考えたのですが、今回はディティールに凝りたかったので画像で作りました。あと駅っぽい背景の写真は実際に晴れの休日を狙って自分で駅に行って写真を撮りました。サイトを公開してすぐにネットで「これは千駄ヶ谷駅の総武線ホームから新宿方向を写したものだな」と見抜かれたので鉄のみなさんはさすがだなと思いました。

Q: 大変だったことはなんですか?

椎野: ウェブ アプリのデモを作って試しに遊んでみると... かなりストレスを感じるんですよね。想像以上に入力しにくいことこの上ない。少しでも入力しやすくするために、細かい仕様については二転三転させています。

小久保: 最初のアイディアは、ボタンを押すと回転し始めて、ボタンを離すと回転が止まり、文字が入力されるというものだったんですが、狙い通りの文字を入力するのが難しすぎて......

椎野: そこで少しわかり難いですが、ボタンを離した瞬間に文字を入力するのではなく、1 秒半ほど遅れて文字が入力されるようにしました。この 1 秒半の間に再びボタンを押した場合は、文字を入力せずにパタパタを回転させ続けます。

小松: 何を言っているのかわかり難いと思いますが、この仕組みがあると「ちょん、ちょん」と短くボタンを押していくことで、パタパタを 1 枚ずつゆっくりと回すことができるようになるんです。この「ちょん、ちょん」入力を使うと、比較的思い通りの入力ができます。

山口: アイディアの面白さと、遊びやすさのバランスをとるのは難しいですねぇ... 去年は入力が難しすぎたので、今年は改善したかったのですが... 今年も結局難しかったですね。(苦笑)

小松: 今年はアイディア出しもたいへん苦労しました。ドラム キーボードからモールスへの流れは、自然で思いつきやすかったんですけどねぇ。

山口: キーの数が少なくて、何も覚えなくても使える、という観点から「毛筆入力」というアイディアもあったんですが、ペン入力と同じで実用的すぎるという欠点(?)からボツになりました。

椎野: 何時間もミーティングルームに篭ってのブレインストーミングは、思い出したくないですね......


Q: 最後の追い込みが大変だったと聞いていますが。。。

椎野: しめきりこわい... こわいよ...。いろいろなことがギリギリでしたが、隠しコマンドは今年も実装しました。山手線やその他いくつかの主要路線の駅名や特急、急行などの列車種別を入力すると駅の発車メロディーが流れたり、ちょっと特別な動きをするんです。一部の方には気付いていただけたようで嬉しい限りです。

三浦: 効果音の作成も苦労しました。やはり、パタパタというからには、音がしっかりパタパタしている必要があります。そこで、パタという音を作るために、いろいろな種類のカードを落としたり、弾いたりして数百種類の音をサンプリングしました。その中でイメージにあったものにフィルターをかけて加工していくという感じですね。1 文字ずつ回す場合と、一斉に回り出す場合ではそれぞれ気持ちいい音となるポイントが少し変わるので、そこも微妙に調整しています。発車メロディーは駅の雑踏を思い出しながら、できるだけ駅の雰囲気が出るように、超適当につくりました。

小久保: こ、こわいよ...。最後の最後で休日なのになぜかオフィスにいた人を捕まえてユーザー テストをしてみたところ、やはり操作方法を理解するのが難しそうだ、という問題が発覚したので急遽ヘルプを実装したりしました。まあそれが必要かもしれないというのはある程度予測はしていましたが、やはり説明なしで理解してもらえるのが理想なのでちょっと悔しいですね。


怖い思いもしたけれど、ローンチできて本当に良かった...

Q: パタパタバージョンを自作してみたいという方のため、基板の回路がオープンソース化されたとのこと。詳細を教えてください。

山口: こちらに、2012 年のモールスバージョンと共にソースコードを公開してあります。
https://code.google.com/p/mozc-morse/

山口: パタパタ装置の設計図も一緒に公開できると良かったのですが、今回撮影用に作った装置には既製品の部品を流用したのでその部分はありません。電子回路部分とファームウェア部分のみ自作したので、この部分を公開しています。ただ、パタパタ装置が用意できない場合でも適当なモーターを用意していただければ写真のようにして使うことができます。

電子回路とステッピングモーターを組み合わせてテストしているところ。
USB ケーブルで Android に接続して入力している。
ステッピングモーターにはパタパタの代わりに円盤を付けている。

Q: パタパタとキー入力はどうやって連動させているのでしょうか?

山口: ドラムを回すために、写真に写っているステッピングモーターを使っています。これは複数のコイルに順次通電することで少しずつ、例えば 1 周の 200 分の 1 ずつ回転させ、正確に止めることのできるモーターです。電子工作の入門書などでよく取り上げられていますので、見たことのある方もおられるかもしれません。プログラムは基準位置からどれだけ回転させたかを常に数えていて、今どの文字が表示されているかを把握しています。ボタンを離してドラムが停止すると、この文字が入力されます。

Q: 実機の開発で苦労したことはなんですか?

山口: ファームウェアを限られた容量に収めるのに苦労しました。開発期間の都合で去年のモールスキーと同じワンチップマイコンを使ったため、ROM の容量が 2,048 byteしかなかったのです。現在実機に載っているプログラムで 2,028 byte あり、ほぼぎりぎりの大きさです。実機をかな入力ではなくローマ字入力にしているのもこれがひとつの理由です。平仮名よりも文字数の少ない英数字にすることで容量を節約しています。

Q: 最後に Google 日本語入力スペシャルバージョンの開発について、今後の展望を教えてください。

小松: こちらのビデオの後半に登場するメガネ バージョンも鋭意開発中です(キリッ)。ただ、早くも大きな課題が見つかっていまして... パタパタの風でドライアイになってしまうんですね。目薬を持ち歩かなくてはならないとなると、せっかくの携帯性が損なわれてしまいます。この部分さえうまく解決できれば、実用化は近いと考えています。


開発中のメガネ バージョン。

小久保: とりあえずあの試作機はとんでもなく重いので、軽量化のうえ年内にはなんとか実用化の目処をつけたいですね、はい。


重いメガネ バージョンを装着中の小久保。本当に重い。とんでもなく重い。

Q: 皆さん、お忙しい中ありがとうございました!


県名や市町村名などのラベルが製品版と違っているのですが、実はそこはすごく苦労しました。実際のドラクエには町にラベルはありませんから、いかに「それっぽく」するのか最後の最後まで調整に苦労しました。

Q: いろいろな場所のランドマークがありましたが、あれは実は Google 社員に呼びかけて作ってもらったのですよね?


A: はい。ランドマークのグラフィックは、すべて世界中の Google 社員が作って投稿してくれたものです。なので Google のオフィスがある所の近くはランドマークが充実している気がします。全部で 120 種類ほどあって、デザイナーに限らずエンジニアやプロダクトマネージャーなどの方も大勢協力してくれました。面白いランドマークの 1 つに「パンダ」がいるのですが、これはデザイナーの川島さん(*1)が描いてくれて、世界中パンダのいる動物園すべてに置きました。UFO やネッシーなどもそれを描いてくれた方のアイディアで、楽しんでくれた方も多いかと思います。
(*1 ウェブマスターの川島優志)



Q: ランドマークは 120 個もあったんですね。モンスター探しに夢中になった方も多いと思いますが、あれは全部でいくつぐらいあったのですか?

A: ドラクエ 1 のモンスターが全種類いますので、40 種類ですね。竜王とスライム以外は複数箇所にいるので、数ではもっと多いです。公開してから 1 時間ほどでほとんどのモンスターが見つけられたのにはびっくりしました。もう少しわかりにくくしても良かったかもしれないですね。また、気づいた方も沢山いると思うのですが、ドラクエ 1 のラスボス「竜王」は緯度・経度が 0 度のアフリカ西部の大西洋上に置いいて、ズームすると変身するように特別の仕掛けをしました。

ランドマークやモンスター以外にも、コントローラーやペグマン、街の印など、たくさんのドラクエ風のグラフィックを作りました。





ドラクエ風の Doodle も作っています。




   
Q: 技術的に工夫したところを教えてください。

A: いっぱいあるんですが、機密事項が多いので残念ながらあまりお話できません。強いて言えば、プロモーションビデオの中に登場するファミコンの回路図を見て、わかる方は「おっ」と思ってくれると思います。「*Google Disc System」みたいな技術ネタも随所に散りばめました。

*ファミコンのディスクシステムにかけたネタ

Q: 最後のフィーチャーはローンチ 30 分前に思いついて、速攻で作ってローンチしたとの噂ですが。。。

A: 最初は竜王も普通のモンスターと同じように置いていたのですが、最後の 1 か 2 時間にそれはいかんと急に思いたって竜王だけ特別にしました。今思うと、王様やローラ姫も登場させればよかったかなと少し心残りです。

Q: 大変だったことはなんですか?

A: 公開まで時間が限られていたので、かなり忙しくてすべてが大変だったと思います。中でも、プロモーションビデオの撮影が大変でした。実際に僕が登場するのはそんなに長くはないのですが、慣れない撮影とナレーションには苦労しました。また社内に公開した直後に自分にバグが 100 個以上アサインされたりとそれを直すのにも苦労しました。大変ではありましたが、とても楽しかったです。協力してくれた方もみんな楽しんでくれたと思います。そして一番大事なのは世界中のユーザーの皆さんが喜んでくれたことです。僕は去年新卒で入社したばかりなので、Google のプロダクトはこれだけ世界にインパクトを与えることができることを実感しました。

ありがとうございました。