2013年12月16日月曜日

TwilioとGoogle Speech APIを使った音声変換について

Twilioを使うと、通話中に相手の会話を録音することができます。もちろん、録音されたデータはダウンロードが可能であり、留守番電話のような音声ファイルを使った様々なサービスを実装することができます。
Twilioには音声変換エンジンによる文字変換機能(transcribe)も用意されていますが、残念ながら日本語による変換はサポートされていません。

 そこで、日本語の音声ファイルをテキスト変換する方法として、GoogleのSpeech APIを用いる方法を調査してみましたので、今回はその方法をご紹介します。

 Twilioから音声変換するまでの流れ

  1. Twilio上での録音機能について
  2. 録音データの変換
  3. Google Speech APIの呼び出し



 Twilio上での録音機能について

※すでにTwilioについて詳しい方は、読み飛ばして構いません。
Twilio上で会話を録音するには、TwiMLの<Record>動詞を使います。次の例は、シンプルな留守番電話を実現します。

<?xml version="1.0" encoding="UTF-8"?>
<!-- page located at http://example.com/voicemail_record.xml -->
<Response>
  <Say>
    発信おんの後に、メッセージをどうぞ。
    終わりましたら何かキーを押してください。
  </Say>
  <Record
    action="http://foo.edu/handleRecording.php"
    method="GET"
    maxLength="20"
    finishOnKey="0123456789*#"
  />
  <Say>メッセージはお預かりできませんでした。</Say>
</Response>

この例では、ガイダンス(ちなみに「発信音」と指定すると「はっしんおと」と発声してしまうので、「発信おん」と指定するのがポイントですw)が流れた後に最大20秒の録音が開始されます(maxLengthパラメータで録音時間を指定でき、デフォルトは1時間となります)。録音を終了するキーに0〜9と#、*が設定されているため、何かキーを押すと録音を終了します。
発信音の後に無音が5秒続くと、録音はされずに最後の<Say>が実行されます。
正常に録音がされると、最後の<Say>は実行されずに、actionパラメータで指定されたURLに対してGETリクエストを送信します。

リクエストには以下のパラメータが付与されています。

RecordingUrl
 録音された音声ファイルのURL。
RecordingDuration
 録音された音声ファイルの長さ(秒)。
Digits
 ユーザによって押されたキー。

<Record>動詞のリファレンスは以下にあります。
https://jp.twilio.com/docs/api/twiml/record


 録音データの変換

録音されたデータは、明示的な削除を行わない限りTwilioサーバ側で保存されます。
なお、サーバー側の録音データについては、10,000分までは無料ですが、それ以降は1分につき0.1円が月額費用として請求されるので、不要になった録音データはREST APIを使って削除するようにしましょう。
録音データの削除に関するREST APIは以下にあります。
https://jp.twilio.com/docs/api/rest/recording

 Twilioサーバーに保存された録音データを抜き出すには、上記REST APIを利用することもできますが、もっとも一般的でかつ簡単な方法は<Record>動詞内で設定したactionパラメータを使うことです。
actionパラメータで指定したURLに対して、Twilio側から戻ってくるリクエストに含まれるRecordingUrlが録音データへのURLとなります。
なお、RecordingUrlの接続先オーディオファイルはWAV形式となります。RecordingUrlの最後に「.mp3」を指定すると、mp3形式でダウンロードすることもできます。

 Twilioで録音されたそれぞれのデータ形式は以下のとおりです。

WAV形式

チャンネル数:1
サンプリングレート:8000
量子化ビット:16
ビットレート:128k

mp3形式

チャンネル数:1
サンプリングレート:22050
量子化ビット:16
ビットレート:32.0k

 なお、音声ファイルのサイズは、WAV形式の方がmp3形式より3倍以上大きくなります。

 さて、ここからが音声変換のための準備となります。

 Speech APIを利用するためには、音声ファイルをFLAC形式に変換する必要があります。変換にはオープンソースのFLACを利用しますので、あらかじめ準備をしておく必要があります。CentOSではyumでインストールが可能ですし、MacやWindows版のFLACもここに公開されています。今回はCentOS上にインストールしたflacコマンドを利用します。
FLACはmp3からの変換に対応していないため、変換にはWAV形式の音声ファイルを利用します。WAVファイルのFLAC変換は以下のコマンドで行います。

 flac -n ソースファイル.wav
(-n:nは0〜8までの数値となり、圧縮率を指定します。8がもっとも圧縮率が高く、0は無圧縮です)

 このコマンドによって、拡張子がflacになった音声ファイルが作成されます。
他にもオプションが用意されていますが、詳しくはFLACのリファレンスを参照してください。
なお、FLACによる変換では、元データのサンプリングレートなどは変更されませんので、例えばTwilioの録音データ(WAV形式)であれば、サンプリングレートは8000のままとなります。


 Google Speech APIの呼出し

Googleは、Chromeブラウザ(バージョン25以降)において、JavaScriptから利用可能なWeb Speech APIを提供しています。なお、Web Speech APIについては、W3Cにて標準化が検討されている状況です。
今回は、GoogleがWeb Speech API向けに独自に用意している「Speech API」という機能を使って、REST形式で音声変換を行う方法を紹介します。
従来、このAPIは非公開APIとして存在していたものなのですが、最近になって正式に公開されました。また、今までの単純なREST方式ではなく、双方向の送受信にも対応しているため、より効率よく音声変換が可能になっています。

ただし、現在のところ以下の利用制限が設けられています(制限を解除することもできなくはなさそうなのですが、これ以上の調査はしていません)。

  • 開発用で、かつ個人利用であること
  • 1日のリクエスト数は50まで


 Speech APIを利用するためには、事前に以下のサイトにてAPIキーを取得する必要があります(別途、Google Cloud Consoleへのアカウント取得とサインインが必要です)。
https://cloud.google.com
ただし、Speech APIはUSもしくはCanadaユーザしか一覧には出てこないので、日本のユーザは、別途以下のChromium-devグループに加入することで表示されるようになります。
https://groups.google.com/a/chromium.org/

 私の場合は、Speech APIをONにしても、2日間はSpeech APIが認証エラーになり、3日目あたりから成功するようになりました(謎)。
なお、今回音声変換を行うためのAPIキーについては、WebApplicationのServer Keyを利用します(たぶん、Browser Keyでもいけると思います)。

 Google Speech APIについては、以下のブログが大変役に立ちます。
http://mikepultz.com/2013/07/google-speech-api-full-duplex-php-version/

上記サイト内には、PHPのプラグインも公開されているので、もしPHPを利用しているのであれば、APIキーさえ用意すればそのまま利用することもできるでしょう。

 PHPではなく、curlを使って変換をするコマンド例も以下に紹介します。この例では、ローカルフォルダにある、test.flacという音声ファイルを変換しています。

 curl -v "https://www.google.com/speech-api/full-duplex/v1/down?pair=3456123487654321" & curl -v -X POST "https://www.google.com/speech-api/full-duplex/v1/up?lang=ja-JP&lm=dictation&client=chromium&pair=3456123487654321&key=[SpeechAPIKey]" --header "Transfer-Encoding: chunked" --header "Content-Type: audio/x-flac; rate=8000"  --data-binary @test.flac

 コマンドを見てもらうとわかるように、送信用のURLと受信用のURLを同時に実行しています。それぞれのURLに含まれるpairパラメータについては、送信と受信で同じ16バイトのランダムな文字列を指定すれば良いようです。SpeechAPIKeyは、皆さんが取得したSpeech APIのServer Keyを指定します。
Twilioの録音データのサンプリングレートは8000ですので、rateパラメータには8000を指定しないといけません。また、日本語変換をするためには、langパラメータにja-JPを指定します。

 変換結果はJSON形式で戻ってきます。以下にサンプル音声データを変換した結果を示します(見やすいように整形しています)。

{
  "result":[
    {"alternative":[
      {"transcript":"長寿庵さんですか ざるそば 二つ島 おかめそばひとつ 大至急お願いします","confidence":0.51536459},
      {"transcript":"長寿庵さんですか ざるそば二つ島 おかめそばひとつ 大至急お願いします"},
      {"transcript":"長寿庵さんですか ざるそば 二傳 おかめそばひとつ 大至急お願いします"},
      {"transcript":"長寿庵さんですか ざるそばスタートおかめそばひとつ 大至急お願いします"},
      {"transcript":"長寿庵さんですか ざるそば 二ツ島おかめそばひとつ 大至急お願いします"}
    ],"final":true}
  ],"result_index":0
}

データを見るとわかるように、いくつか変換候補が戻ります。先頭の結果にconfidenceパラメータが戻っていますが、これが変換結果の信頼性を表しており、値が1に近ければ近いほど正確な変換ができたことを表すようです。

 Google Speech APIについては、ネット上でもあまり情報がなく、現時点では手探りの状態で参考になるかどうか判りませんが、変換精度はかなり良いようなので、今後に期待したいところです。

2013年9月9日月曜日

Evernote Businessでサーバー同期エラー

Evernoteのビジネスバージョンで、管理者がWeb上の管理コンソールのノートブックの管理からビジネスノートブックを強制的に削除すると、そのノートブックに参加していたユーザのクライアントアプリ(今回はWindows版を利用中)で同期に失敗します。
エラーメッセージは「サーバー側で予期しない問題が発生しました」。
このメッセージの解決方法は、ゴミ箱を削除するとか、プロキシーの設定を確認するなどなのですが、今回はいずれの方法でも解決しませんでした。

で、見つけた解決策は以下のとおりです。

  1. 同期に失敗する各ユーザアカウントでWebのEvernoteにサインインします。
  2. 参加中のノートブックに、管理者によって削除されたノートブックが出てくるので、それをクリックします。
  3. 以下のダイアログが表示されるので、OKを押します。


アプリを再インストールしたり、色々試したけどすべて駄目だったので途方に暮れていましたが、なんとか解決して良かったです。

2013年3月22日金曜日

AWSのVPCにおけるMTUとMSS設定について

Amazon Web ServicesのVPCを、YAMAHA RTX1100で構築していますが、以下の現象が発生して困っておりました。

viコマンドやls -lコマンドなどを利用した場合に、sshがフリーズしてしまう(再現性あり)


  • VPC内の端末間では現象がおきないことから、VPC(AWSと自社側)の間で何か問題が発生しているっぽい。
  • 特定のコマンドや、特定のディレクトリをリストした場合に現象が出ることから、送受信データに問題があるっぽい。


ということで、疑わしいところはパケットサイズではないかと睨み、MTUのサイズをpingコマンドで探し出してみた。
ping -f -l 1362 -n 1 サーバアドレス ←これはOK
ping -f -l 1363 -n 1 サーバアドレス ←これはNG
ということで、MTUサイズは1362+20(IPヘッダ)+8(ICMPヘッダ)=1390
MSSサイズは、MTU-20(IPヘッダ)-20(TCPヘッダ)となるので、1390-40=1350が正しいサイズになる。

そこで、tunnel select 1とtunnel select 2に
ip tunnel mtu 1390
ip tunnel tcp mss limit 1350
を記載したところ、現象が改善された!

VPCを設定する際に、AWSがルータのコンフィグを自動生成してくれるのだが、このコンフィグではMSSが1387になっているので修正する必要がある(MTUについてはコンフィグには記載なし)。

2013年2月13日水曜日

AWSのDNSフェイルオーバーについて

Amazon Web Services(AWS)のDNSサービスである「Route53」にて、フェイルオーバー機能がサポートされたとのことでしたので、早速調査を行いました。

【AWS発表】Route53にDNSフェイルオーバー機能が追加。S3のウェブホスティング機能と連携したバックアップサイトを作成可能に。


詳しい設定手順などは上記ブログに任せるとして、ここではこの機能の概要と、設定する際の注意点についてまとめます。
図1 Route53によるDNSフェイルオーバー
まずはこの機能の概念図を見てください(クリックして拡大)。
この図では、架空のドメイン(hoge.com)をRoute53(DNS)で管理しています。通常のDNS運用では、たとえば「www.hoge.com」というウェブサイトに対して、Aレコードを定義しています。

DNSフェイルオーバーでは、この通常のAレコードをプライマリとし、プライマリのAレコードに新設された「Health Check」という機能を紐付けます。「Health Check」とは、その名のとおり死活監視をする機能で、世界中のAmazonロケーションから定期的にターゲットサイトを監視します。
監視方法は、HTTPかTCPによるもので、HTTPを使った場合は400番より小さいレスポンスを2秒以内に返さないとエラーと判断します(TCPの場合は4秒以内にバーチャルサーキットが開設できないとエラーとなるようです)。
実際に構築してみたところ、約16箇所から60秒/箇所間隔でパケットが届きました。なので、すくなくとも16アクセス/分となります。上記の公式サイトでは30秒間隔とあるので、実際はもっと増える可能性もあります。

エラーになった場合に利用されるのが、フェイルオーバー機能により新設されたセカンダリのAレコードです。これは、プライマリのAレコードのエイリアスとして定義するもので、通常は存在していないので、フェイルオーバーを設定する際に追加する必要があります。
セカンダリのAレコードでは、飛び先としてS3の静的ウェブサイトの他、EC2なども選択が可能です(エイリアスターゲットと呼びます)。S3の静的ウェブサイトでは、運用コストを非常に安くすることができるので、ここにお詫びのコンテンツをいれておくことで、Health Checkにてエラーと判断された場合に、自動的にそのコンテンツが表示されるという仕組みです。
S3で静的なウェブサイトを作成する方法については、下記のリンクが役に立ちます。

なお、Health Checkは前述のとおり、かなり細かい間隔で行われるため、DNSの返答先の切り替え自体は早いのですが、プライマリのAレコードに指定したTTL(情報の生存時間)が有効なため、フェイルオーバーを設定する際は、プライマリAレコードのTTLを60秒にする(通常は300秒など)ことを推奨しているようです。

最後に注意点です。
  1. エイリアスターゲットにS3を利用する場合、SSLが使えません。
    これはS3側の静的ウェブサイトに起因しますが、S3の静的ウェブサイトでは現在SSLに非対応なため、DNSがS3に切り替えたとしても接続ができず、接続エラー(サーバーが見つからない)になります。
  2. 同じくエイリアスターゲットにS3を利用する場合、バケット名はターゲットサイトと同じ名前にしておくこと。
    上の図でいうと、www.hoge.comという名前のバケットを作成しておく必要があります。これは、セカンダリAレコードのエイリアスターゲットの指定画面では、バケット名までは指定することができず、暗黙的にターゲットサイトの名前のバケットが利用されるからです。
    この制限によって、たとえば、複数のサイトを管理している場合に、同じエラー画面を1つのS3バケットで使い回しすることができないことを意味します。
サーバが何らかの理由によって(たとえば正規のメンテナンスも含む)停止する場合、DNSでフェイルオーバーができるのはかなり強力な機能といえます。今回紹介したようなお詫びコンテンツをS3で運用するだけでなく、たとえばバックアップサイトをEC2で構築しておき、そちらに切り替える(LBでやればいいじゃんって話もありますが)などの利用方法が考えられます。

2012年6月4日月曜日

ダライ・ラマのお言葉

Facebookからの転載になりますが、とても心に響いたので忘れないようにブログに書いておこうと思う。

ダライ・ラマに「人間に関して、最も驚くことは何ですか」と聞いたところ、こう答えた。

「お金を稼ぐために健康を犠牲にして、健康を取り戻すためにお金を犠牲にすることです。
未来のことを心配しすぎて、現在を楽しめてないことです。結果どうなるかというと、未来も現在も生きていないことになる。
そして、まるで自分は死なないかのように生きて、まるで実際に生きていなかったのように死ぬことです」

2012年3月22日木曜日

スマホ版iコンシェル始まる

ドコモのiコンシェルサービスが3月22日にスマートフォンにも対応できるようになりました。
早速申込をしてみたので、取り急ぎレポートします。

概要

スマートフォン版のiコンシェルは、従来のフィーチャーフォン向けサービスを大きく変更はなく、機能としては以下の2つです。

  • インフォメーション配信機能
  • コンテンツ自動更新機能


インフォメーション配信機能

ドコモや公式CP(コンテンツプロバイダ)が配信する各種情報を受け取る機能です。マチキャラを設定している人は、待ち受け画面上でインフォメーション受信を通知してくれます。
配信される情報には、地震や天候、電車遅延情報、道路混雑情報、終電アラーム、イベント情報など、従来のフィーチャーフォンで提供されていたものと同じです(CPの配信情報につては、CPのスマートフォン対応状況に依存します)。
配信には「オートGPS配信」も利用されます。オートGPS配信とは、あらかじめ設定された場所に来たときに自動的に配信される機能です。この機能を使うことによって、たとえばリアル店舗の近くにお客さんが来たときに、自動的にクーポン情報をインフォメーションで配信することなどが可能となります。
オートGPS配信を利用するためには、あらかじめ端末側でオートGPS機能を有効にしておく必要があります(デフォルトではオートGPSは無効になっています)。

コンテンツ自動更新機能

ここでいうコンテンツとは、「トルカ」と「iスケジュール」の2つがあります。
実はどちらもiコンシェルサービス開始前からスマートフォンでは使えた機能ですが、iコンシェルの自動更新機能によって、コンテンツを遠隔から自動的に更新することができるようになりました。
たとえば、クーポン情報が記載されたトルカをあるタイミングで自動更新したり、サッカーチームやタレントのイベント情報などをiスケジュールとして自動的に更新することができるわけです。

申込

これらiコンシェルサービスを利用したいというユーザは、別途iコンシェル契約が必要となります。フィーチャーフォンでは、月額210円(税込)でしたが、スマートフォンでは月額105円(税込)で利用することができます(2012年4月30日までに契約した方は、最大60日間は無料です)。
契約に関して重要なことは以下のとおりです。

  • iコンシェル対応スマートフォンであること(2011-12冬春モデル、一部の機種を除く)
  • spモード契約必須(iモードとの重畳契約では利用できません)
  • メモリに空きがあること(iコンシェル絡みで必要なアプリには、iコンシェルアプリ、スケジュール&メモ、マチキャラ、ドコモバックアップ、トルカ、オートGPSがあります)


実際の申込は、ドコモショップ以外に端末やPCからも可能です。僕は法人契約の端末でしたが、PC(My docomo)から申込が可能でした。
注意が必要なのは、前述したようにiモードと重畳していないspモード契約が必要であること。iモードと重畳契約している人は、spモードに契約しなおしが必要です。
また、iコンシェルサービスを契約すると、自動的に「電話帳お預かりサービス」にも加入させられます(スマートフォンでの利用料は無料です)。
※「電話帳お預かりサービス」は、通常一日1回端末の電話帳やトルカ、iスケジュールなどのコンテンツをドコモのサーバと同期してくれるサービスで、iコンシェルサービス開始日である本日(3月22日)から始まりました。

契約が完了すると、自動的にiコンシェルアプリのダウンロードが始まります。
このアプリがiコンシェルサービスの中心となります。この時点でメモリに空き容量がないと以下のメッセージがでちゃいます。
その場合は仕方ないので、容量の大きなアプリケーションをいくつか削除する必要があります。先ほどインストールされているiコンシェル関連のアプリサイズを計算してみたところ、ざっと30MBくらいありました(データも含む)。

iコンシェルアプリはこんな感じです。
初期起動時は、オートGPSが未設定になっているので、まずはオートGPS設定から始めるとよいと思います。
「トルカ」や「スケジュール」はこのアプリからも起動できますが、それぞれトルカアプリやスケジュール&メモアプリを開いても同じです。
iコンシェルを使っていると、徐々にウザくなっていく(笑)インフォメーションについてはこのアプリの「設定」から配信情報を変更することができます。
iコンシェルアプリがインストールできたら、同じく「設定」から「プロフィール」についても設定をしておきましょう。設定項目はニックネーム、生年月日、性別、居住地です。これらの情報の登録は任意ですが、設定しておくとインフォメーション配信時にフィルタとして利用されるので、関係の無い情報を受けとりたくない場合は設定しておくと良いかと思います。

取り急ぎ、ユーザ側からみたスマートフォン版iコンシェルはこんな感じです。
iコンシェルサービスを使って、情報を配信したい側の説明についてはそのうち(ご要望があれば)ご紹介したいと思います。



2012年2月23日木曜日

CIAJ/MCPC共催 特別セミナーを受講してきました

2/21(火)以下のセミナーを受講してきたので、そのまとめ。

CIAJ/MCPC共催 特別セミナー 
「災害時に関する安心・安全について(非常時の携帯電話は)」 

本セミナーは以下の3部構成となっており、最初の2講演が通信キャリアとしての視点、最後の1講演は災害時のITボランティアとしての視点で講演が行われました。

講演①「東日本大震災に対するドコモの取り組みとこれからの対策」
NTTドコモ 福島弘典氏

講演②「東日本大震災におけるKDDIの対応と今後の取り組み」
KDDI 米倉和則氏

講演③「東日本大震災の復興に向けて〜復興支援に必要なコミュニケーションとトラスト〜」
岩手県立大学ソフトウェア情報学部教授 村上優子氏


講演①「東日本大震災に対するドコモの取り組みとこれからの対策」
NTTドコモ 福島弘典氏 

東日本大震災における被災状況
被災地域では、約4,900局が通信できない状態に陥ったが、このうち85%が停電によるもので、残りが通信設備の損壊(光ファイバーの断線が大きい)。
85%が停電によるものであったことから、電力対策が大きな課題であることがわかった。

発災時の通信トラフィックの状況
・東北におけるトラフィック量
音声トラフィック:発信は通常時の60倍、着信は40倍→最大90%規制
パケットトラフィック:発着信とも通常の3〜4倍程度
※お見舞いメールが集中し、翌日もパケット着信が減らなかった
・東京におけるトラフィック量
音声トラフィック:発信が50倍、着信は20倍→最大90%規制
パケットトラフィック:2から3倍程度
※メールは通常、送信直後に90%以上が届くが、震災時は80%届くのに30分、90%届くためには80分かかった。 

災害復旧方法
・マイクロ伝送路による設備復旧
  光ファイバーが切断してしまったところを移動基地局を使ってマイクロ波による伝送を行った。ただし、この方式は受信局まで見通しできる場所で伝送を行うことが条件である。
・応急的に光ファイバーを引き直して復旧
あくまで応急的な復旧ではあるが、光ファイバーを引き直して対応も行った。
・大ゾーン化による設備復旧
1基地局で複数基地局をカバーする方式を利用してサービスを復旧させた。
※ただし、大ゾーン化することで通常時に比べて通信できる呼数や端末台数は減るが、対策としてはまったく繋がらないよりは良い。
・衛星回線による設備復旧
移動基地局から衛星を利用して応急な対策を行った。

ちなみに、NTTドコモでは福島第一、第二避難区域内の復旧作業については、約25Km離れた基地局から原発付近に向けて指向性の高いアンテナを使って電波を吹いている。また、一部は伝送路を復旧もさせている。

ドコモグループの復旧体制
合計で4,000名体制で支援をおこなった。

被災地への支援
無料衛星電話:900台
無料携帯電話:2,100台
タブレットの貸し出し:670台
無料充電コーナー:410箇所

復旧エリアマップ
3/20から運用開始したが、利用者からは遅いとの指摘もあった。
利用状況については、初期10日間で約20万アクセスがあった。

災害伝言板の利用
情報登録は160万件あり、情報の確認は287万件あった。
しかし内容をみてみると、災害伝言板のトップページから被災状況の登録をしたのは、わずか8%、情報の確認を行ったのも8%しかいないことが判明した。
特に60歳以上はトップページへのアクセスが4%、登録・確認とも1%しかない。

新たな災害対策について
・重要エリアにおける通信の確保
大ゾーン方式基地局を全国に設置(104箇所)
都道府県毎に概ね2箇所(東京は6,大阪は4)
半径7Kmをカバー
無停電化、バッテリー24時間化
都道府県庁、市町村役場などを重点的に無停電化700局程度、24時間化は1,000局

・被災エリアへの迅速な対応
衛星携帯電話の避難所への即時提供(全国で3,000台を用意する予定だが、震災後ユーザからの需要が大きく、現在数が今足りない状況)
衛星エントランス回線(震災前10台→24台へ、車載型を9台配備)の活用
マイクロエントランス回線基地局(100区間を準備)

・災害時におけるお客様の更なる利便性向上
音声による災害伝言板を開発、3月から提供予定(※音声データをパケットとして送信する方式)
復旧エリアマップの公開時期の短縮、視認性の向上、汎用性の向上(12月23日より)

最後にドコモからのお願いとして、発災時は音声よりパケットの方がつながりやすいので、なるべくメールなどをご利用いただきたいとのことでした。


講演②「東日本大震災におけるKDDIの対応と今後の取り組み」
KDDI 米倉和則氏(au技術企画担当)

1995年の阪神大震災の時は携帯電話の普及台数も現在とは比較にならず、むしろ携帯電話は繋がりやすかった。一方今回は、固定電話の方が繋がりやすかったのではないかと思う。
また、今回についてはソーシャルメディア(Twitter、facebook)による連絡手段が使いやすかったの印象的である。

災害がインフラに与える影響については概ね以下の5つの要因が考えられる。
・局舎や通信設備の損壊
・伝送路の破損
・停電
・通信の輻輳
・保守作業が困難(道路がないなど)

今回の震災では、実際に大量のアラームが発生してしまい、現場の状況の把握ができない状況に陥った。また、回線断などにより現地との連絡ができなかった。さらに、余震が多発し、障害範囲が拡大。輻輳による自動規制発動や社員の安否が確認できないといった様々な要素が重なることで、復旧作業は困難をきわめることになった。

KDDIは海底ケーブルを利用して仙台に陸揚げ局があるが、壊滅的な被害を受けた。さらに、高速道路に伝送路を敷設しているが、こちらもところどころで断線した(伝送ケーブルについては、発災後24時間体制で2日間で復旧させたとのこと)。もちろん基地局やauショップにも直接被害が発生した。

KDDIでは、発災直後の15:10に災害対策本部/現地対策本部を設置し、16:00には被災状況の把握と、車載基地局・移動電源車の出動指示を行った。彼らは12日の夕刻に仙台に入り、翌日13日の午前3:21に車載1台目立ち上げを完了した。その後、のべ70箇所で基地局を立ち上げた。

固定電話は39万回線で障害が発生した(6/30までに99%復旧)。また、国際通信サービスも障害が発生したが、こちらは3/15に仮復旧をした。

ケータイ電話(au)については、1,933局が停止したが、4/5で残り185局、4/22で残り124局、6/2で残り81局となり、6/末で全て復旧させた。
福島県内(立ち入り制限区域)については、残念ながら現在対策はできていない。

暫定対策エリアでは
・大ゾーン化
・衛星エントランス
・無線エントランス

復興後エリアでは
・基地局新設によるエリア整備

また、現地での支援活動としては
・携帯電話の貸し出し:1,290台
・衛星携帯の貸し出し(イリジウム・インマルサット):48台
・無料充電コーナーの設置

通信トラフィックの状況
被災地で最大95%の通信規制が行われた。また、被災地向けへの発信については最大50%の規制を行った。一方、パケット通信については特段発信規制を行わなかった。ただし、EV-DO網についてはパケット専用で構築されているため、音声通話の影響を受けなかったが、ケータイメールについては、着信通知に音声ネットワークを利用してしまっているため、結果的にメールの着信が遅れるという現象が発生した。これについては、今後着信通知をSIPへ移行するなどして対策を取る予定である。
発災時、音声通話のトラフィックは通常時の8倍程度、メールについては5倍程度であった。メールのピークが音声より遅れて発生しているので、音声が使えないのでメールにシフトするユーザが多いように思える。
災害伝言板は約二時間後にピークを迎えた。
固定回線については、地震直後はトラフィックが減少した。国際通信についても、震災後は一度トラフィックが減少した後、徐々に高くなる(108%)といった傾向が見られた。

今後の災害対策の取り組み
まずは全社レベルでのBCPの再点検が必要であると認識している。
・発災時の影響を最小限に(冗長ルート、サイトダイバーシチー、停電対策)
・迅速な復旧(障害箇所の早期把握)
・利用者へのケアを万全に

具体的な数字としては、非常用電源配備基地局を現在の55から130へ、さらに2,000局で24時間バッテリー化。移動基地局を15台から47台にし、無線エントランス区間も60箇所に広げる。

さらに、災害時のメール疎通を強化し、それと併せて緊急速報メール対応機種を拡大する。
また、サービス停止状況などの情報提供を迅速に行い、全国に敷設してあるコアネットワークは最終的には3重化にする予定である。災害伝言板のスマホ対応も行う。

最後にKDDIからのお願いとして、「メールの遅延については、新着メール問い合わせをしてほしい」とのことでした。


 講演③「東日本大震災の復興に向けて〜復興支援に必要なコミュニケーションとトラスト〜」
岩手県立大学ソフトウェア情報学部教授 村上優子氏

村上氏は、実際に岩手県内の自治体と協力を行い、主にIT関連の復興支援を行っている。
その経験を踏まえて、復興支援には「災害コミュニケーション」が必要であると提唱している。


災害時に問題となるのは、「解決したい問題は共通だけど、協調は難しい」という点である。これは以下の要因から発生している。
・関係者の多様性(背景が異なる)
・感情的になりやすい(睡眠不足、不安・不信)
・面識のない人々との連絡や相談(誤解)
・状況が刻々と変わる中、瞬時の決断が求められる(理想や最適化の実現は困難)
・真の需要の認識把握が難しい

村上氏は、このような状況下において必要とされる技術として「トラストの情報処理」を挙げている。


そもそも「トラスト」とは、
・相手の能力
・相手の誠実
・相手の善意
から構成されている。
このうち、誠実と善意には「主要価値類似性」がある。具体的には、「同じ価値基準を持っている人に言われるとよりトラストになる」ということである。

たとえば、相手が困っているときに、すぐに対応をしてあげることで主要価値類似性が生まれ、結果的にトラストが生まれる。例えば、まずは相手が何を必要としているかをしっかりと理解することが災害コミュニケーションでは重要である。
今回、実際の被災現場ではIT機器などよりも、まずは車や燃料、人などのプライオリティが高く、それを提供する作業から始めることになったそうだ。ただし、そのように必要なものを的確に送ることを続けることで、徐々に「トラスト」を得られるようになり、最終的には本来支援するべきIT機器にたどり着くことができたとのこと。

一方で、トラストは非対称性原理(得るのは堅いが、失うのは易い)であることにも注意をしなくてはならないとのこと。残念ながら、この部分は時間切れで解説がなかったが、資料を拝見すると概ね以下のとおりである。
・信頼を崩す出来事は伝えやすい
・否定的な事柄は、肯定的なものより信頼評価への影響が大きい
・否定的な事実は、肯定的なものより一般化されやすく、危険性を主張する場合の論拠に使われやすい
・信頼の欠如がさらに信頼を低下させ、その流れを作ってしまう

すなわち、否定的なことは肯定的なことよりも伝搬しやすいということである。

そこで、災害対策での不信対策として、
・不信は生まれることが前提であると考える
・共同作業をする上では、相手を「安心」をするのではなく、相手を「信頼」をすることが大切である
・目的を共有しながら行動することで、主要価値類似性によるトラストの維持を行う
が有効であるとのこと。

村上氏の講演を聴いていると、まさに「ソーシャルシフト」へ繋がっているような気がしたが、皆さんはどうだろう。

2011年10月3日月曜日

今日の頂きものとブログインターフェースについて

たけさん、並びに他の方々(?)よりまたまた兼八を頂きました。 このお酒は本当に美味しいので大好きです。 しかも今回は一升瓶! 皆様、どうもありがとうございました。

それで、このブログのデザインを数日前より変更したのですが、モダンブラウザ以外ですとうまく見られません。
たとえばスマートフォンなどですと、以下のような画面になってしまうので、この中にある
「non-dynamic version」というリンクを押していただけると従来のレイアウトで見ることができます。

また、PCのモダンブラウザで見た場合のコメントですが、まずはコメントを入れたい個々の記事を選択(記事のタイトルをクリック)し、ポップアップされたウィンドウの最下部にコメントのリンクがあります。
分かりづらくて申し訳ございません。

2011年9月8日木曜日

Twitterの検索結果をGoogle Docsのスプレッドシートに取り込む

Twitterでは、Web画面の検索ボックスからツイートの検索が簡単にできますが、結果をより詳しく分析したり、保存しておきたい時などがあります(よね?)。
もちろん、検索結果をコピペしたり、別のサービスをつかったりすることで可能ですが、Google Appsを使っている方であれば、非常に簡単に、ツイートをスプレッドシートに取り込むことができます。
手法としては、Excelのマクロのような「Google Apps Script」を利用します。
なんだか難しそうだなぁと思いました?いやいや、全然簡単です。

まずはGoogle Apps のドキュメントから、新しいスプレッドシートを作成してください。
シートが開いたら、上部にあるスプレッドシートの名前欄に名前を入力しましょう。
名前は何でも良いのですが、今回は「Twitter検索」ということにします。
「OK」を押して名前を付けたら、いよいよGoogle Apps Scriptを作成します。
「ツール」メニューの中から「スクリプトエディタ...」を選択します。
新しくスクリプトエディタのウィンドウが開きます。
右側のコードという場所に、デフォルトでfunction myFunction()と書かれていると思います。
今回は、このmyFunctionという関数の中に、Twitterの検索APIを記述していきます。
とはいえ、以下のコードをコピペしてもらえばOKです。
  var query = Browser.inputBox("検索ワードを入力してください");
  query = encodeURIComponent(query);
  if (query != "") {
    var response = UrlFetchApp.fetch(
      "http://search.twitter.com/search.json?q="+query+"&rpp=100");
    var jsonString = response.getContentText();
    var object = Utilities.jsonParse(jsonString);
    var ss = SpreadsheetApp.getActiveSheet();
    var cell = ss.getRange("A1");
    var row = 0;
    for (var i=0; i < object.results.length; i++) {
      var result = object.results[i];
      var col = 0;
      var dd = new Date(result.created_at);
      cell.offset(row, col++).setValue(dd.toLocaleString());
      cell.offset(row, col++).setValue(result.from_user);
      cell.offset(row, col++).setValue(result.text);
      row++;
    }
  }

コードの中身の説明は今回はしませんが、簡単にいえば、検索したい語句を入力してもらって、それをキーにTwitterの検索APIを呼び出し、結果(今回はmax100件)をシートに貼り付けるというものです。
コピペが完了すると、だいたいこんな感じになります。
クリックすると拡大
画面が小さくて分かりづらいかも知れませんが、コピペをする位置は、function myFunction(){の次の行からです。
では保存します。「ファイル」メニューから「保存」を選択するか、フロッピーディスクのアイコンを押します。

新規保存の場合は、名前をつける必要があります。プロジェクト名は、「twitterSearch」としておきましょう。
「OK」ボタンを押せば完成です!
ほらね、超簡単でしょ?

後は実行してみるだけです。
「Run」メニューから「myFunction」を選択します。
この時、スクリプトエディタが画面の中央に表示されていると、入力ダイアログボックスが隠れてしまうので、スクリプトエディタのウィンドウは最小化しておくと良いです。
このようなダイアログが表示されるので、検索したい語句を入力して「OK」ボタンを押してみましょう。
しばらくすると、シートに検索結果が(あればですがw)表示されます。

今回は、本当に基本的な機能だけに絞っていますが、Google Apps Scriptを使えば、このように外部のWebサービスからデータを取得することが簡単にできます。
また、スクリプトをタイマーで自動起動するようなことも可能ですし、その結果をGoogle Siteのページとして作成したり、メールで送信することもできます。

もしGoogle Apps Scriptなどを使って、こんなことがしてみたいといったご要望があれば、ぜひお気軽にお声がけください。

2011年9月5日月曜日

eFaxを使ってFAXをクラウド化してみました

eFaxというサービスを使って、会社のFAXをクラウド化し、ペーパーレス化を実現したので、その方法をご紹介します。

eFaxというサービスは、月額1,500円(現在は995円/月)で利用できるインターネットFAXサービスです(送受信とも150ページ/月まで。それ以上は10円/ページがかかります)。
インターネットFAXとはいうものの、0AB〜Jの専用FAX番号を1つもらうことができます(0AB〜J番号は、東京03や大阪06など、事業所の場所によって色々な番号を選択することができます)ので、お客様は従来通りFAXを送信してもらえばOKです。

ただ、すでに従来のFAX番号は広く告知されてしまっていますし、FAX番号だけ変更しましたってのも格好がよくありません。
となると選択肢としては、

  1. ボイスワープを使ってNTTに転送してもらう
  2. 既存FAXの転送機能を利用して受信後転送をする
の2つが考えられます。
1は月額料金(自宅用回線で500円/月、事業所用で800円/月)がかかってしまいますし、2は利用しているFAXが転送に対応している必要があります。
今回は社内のFAXが転送機能を持っていたため、2の方式で転送をすることにしました(転送する際にeFax宛の通信料が発生しますが、これは仕方ないですね)。

で、eFaxに転送されたFAXはどうなるかというと、予め設定しておいたメールアドレス宛に添付ファイルとしてメールされます。eFaxでは最大5つのメールアドレスが設定でき、それら全てにメールが送られます。
弊社では主要なメンバーとevernoteのメールアドレスを登録しておきましたので、受信FAXは自動的にevernoteにも蓄積されます(これは便利)。

FAXの送信は以下の2つの方法で可能です。

  1. 従来のFAXで従来通り送信する
  2. eFaxのサーバ経由で添付ファイルとしてメール送信する
従来のFAX回線を残したままであれば、1の方法で従来の方法をそのまま残しておくことができます。もしFAX回線を解約してしまった場合は2の方法でFAX送信ができます。
2の方法で送信するには、相手先電話番号@efaxsend.comに添付ファイルを送信するのですが、この際の送信元アドレスとして予め最大5つのアドレスを登録しておくことができます(受信用のアドレスとは別管理です)。これにより、最大5人がメールを使ってファイルを送信することができます。
送信が完了すると、送信完了メールが送られてくるので、うまく送信できたか心配する必要もありません。なお、送信には送付状を自動的に付加する機能があるので、送付状を予め作る手間は省けます(送信ページは1枚増えますけどね)。

従来のFAX回線を残したままでの運用では、eFaxの利用料分+転送にかかる通信費だけコストアップにはなってしまいますが、従来のように紙で受信したときのその後の処理(コピーしたり、スキャンしたり、ファイルに保存したりしますよね?)を考えるとかなり効率は上がると思います。
事務所を移転するときに電話番号が変更になるようなときは、最初からeFaxだけで運用するのもひとつの手です。

☆2011/10/21 追記
支払い方法は当初クレジットカードになりますが、eFaxからの請求明細はでないそうです。何枚FAXを送ったかは毎回カスタマーセンターに問い合せが必要らしい・・・(これはあんまりだ)。
支払い方法を銀行振込に変更すれば請求書をメールで送ってくれるらしいので、とりあえず銀行振込に変更してみました。

2011年8月27日土曜日

ありがとうございます!

今年はfacebookに書こうか、こっちに書こうか迷ったのですが、fbだとコメントできない方も多いかと、こちらに書くことにしました。

さて、ご存知のように(知らないってw)本日めでたく47歳になりました。
皆さんのi温かいコメント(主にfb)、どうもありがとうございました。

そして、今年もまた、たけさん、しんじさん、りえちゃん、Yからステキなプレゼントを頂きましたので、早速ご紹介します♪

まずは何と言っても、今年はランチのご招待というイベントをプレゼントしていただきました。場所はぎりぎりまで秘密でした。
ローストビーフの店「鎌倉山」赤坂店
前々から行きたいと思っていた「鎌倉山」です。
しかも特別コースを予約してくれていたようで、もう感謝感激雨あられ(フルすぎっ)。
前菜
まずは前菜から。
本日は湯葉とサーモンのお刺身、写真を撮るときはまだ到着していなかったホタテのソテーが供されました。
湯葉はなかなか珍しいですね。サーモンも脂がのっていて美味しかった。
伊勢海老のブイヤベース
そしてこちらが特別にコースに組み入れてもらった「伊勢海老だけで作ったブイヤベース」です。
いやー、これは濃厚で美味しいです。
以前目黒のシンペイさんで頂いたブイヤベース以来の感動ものでした。
ローストビーフ
そしていよいよメインのローストビーフ。
美しい!
そして柔らかく、ジューシーな口溶け。
なるほど、ローストビーフの店というだけありますね。
これは旨いや。
ローストビーフを満喫する俺w

デザートはバースデーなので+1で3品
 デザートは普段は2品選択らしいのですが、今日は特別に3品どうぞとのこと。
砂糖を使わないプリンとババロア、ドラゴンフルーツをチョイスしました。
ねーねー、ドラゴンフルーツの中に入っているのは黒ごまだよね?違う?

ってな感じで、ランチを満喫いたしました。
どうもありがとうございます。ごちそうさまでした。




・・・で、終わるわけがないのです。
会社に戻るとプレゼントの山が・・・。
毎年エスカレートしてないかw
バカラにノリタケ、スワロフスキー。アルファなシャンパンとワインなど。
こりゃすごい。
思わず仰け反りましたよ、ホント。

ノリタケ
 ノリタケのお皿が2枚。しかもこれは僕の愛用するパスタ皿(ホントはスープ皿)と同じシリーズ!
これ、めったに手に入らないので、すごい嬉しいです。
去年も1枚もらったので、これでトータル4枚揃いました。
わーい、わーい。

バカラのワイングラスとシャンパングラス
そしてバカラ。
こちらはワイングラスとシャンパングラス。
Yが世界にひとつっていうから、なんで?とおもったら・・・
うしぇー、名前入りですがな
わかるかな、なんと僕の名前が彫ってあるのですよ。
すごくない?ねー、すごくない?
これはたしかに世界でひとつだね。
ホント、嬉しいっす。

お酒シリーズ
そして、グラスだけじゃないんです。
中身もちゃんと贈ってくれました。
しかもアルファシリーズ全種類ですよ。
いまや中々手に入らないものを、ずいぶんと前(噂では5月)から見つけては買ってくれていたそうです。
なんとも嬉しいじゃないですか。
そして一番右は、「ゴールド兼八」ですよ。
ゴールド!ゴールド!ゴールド!

そして最後にスワロフスキー。
スワロのペンダントが2つ
めちゃ、かっこいい!
ワイルド系ですね。ヤバいっす。
これはオマケらしい
そしてなんと、リニューアルオープン記念の印鑑入れまで付いてきた。
オマケが凄すぎるぞ、スワロフスキー。


早速付けてみたよ。
いいね!似合うね、最高だね。

ということで、ホントにどうもありがとうございました。

ちなみに・・・
僕はたけさんとしんじさんとりえちゃんのことは、名前も顔も知らないのね。
知っているのはニックネームのみ。
かなり特殊な関係ですよね、ホント。

2011年8月22日月曜日

ありがとうございます

以前お客様の役員をされている時から色々とご指導頂いており、現在は某社の社長をなさっている方から、◯◯賞のお祝いを頂戴いたしました。
最近、私がハマっている(といっても、なかなか手に入らないのですが)四ツ谷酒造の「兼八」です。
左側は非常に珍しい原酒です(初めて見ました)。こちらはアルコール度数45度(!)とのことで、冷凍庫で冷やしてストレートかロックがオススメだとか。
まるでウォッカですね。
麦焼酎なのですが、香ばしい香りにはまっています。

いつも気にかけていただき、本当にありがとうございます。

P.S.10月のCEATECでの講演は拝聴させていただく予定です。

2011年8月10日水曜日

ありがとうございます

報告が少し遅くなってしまってすみません。
お世話になっているお客様の部署の部長様より、愛宕神社の金箔御守をいただいてしまいました。
前回に引き続き、わざわざ弊社のために神社までいって(もしやあの階段も登られたのでしょうか!?)買ってきてくださったとのこと。
お客様に愛される会社であることをポリシーにしている弊社にとっては、このうえない幸せでございます。
ありがとうございました。
今後ともよろしくお願いいたします。

2011年8月9日火曜日

UK版XOOM(MZ601)の3.1OTA後のrooted

本日(8月8日)、UK版XOOM(MZ601)にもAndroid3.1がOTAで降ってきました。
ただ、すでにrootedな3.0.1では、バージョンアップの途中でドロイド君withビックリマークが出てしまい、うまくいきません。
まぁ、しかたないですね。
ということで、Motorolaさんのサイトから工場出荷時のイメージをダウンロードし、初期状態に戻します。
戻し方は今のページに書いてあります(ただし、後ほどrootedするので最後のfastboot oem lockはやりません)。
無事に工場出荷状態になったら、後は設定メニューからシステムアップデートを行い、3.1にアップデートしましょう。

さて、問題はこのあとです。
unrootedな状態になったXOOM君を再度rootedにしなくてはいけません。
やり方は以下のとおりです。
参考にしたサイトは、こちらです。



注意:
  • microSDカードが必要です。
  • XOOM 3G UK版(MZ601)の手順ですので、それ以外のXOOMではうまくいきません。
  • この手順で何か問題が起きても責任はとれません(すべて自己責任でお願いします)。

まずは、以下のサイトから「3.1 Root and Recovery Tools.rar」をダウンロードします。
http://www.megaupload.com/?d=S9BTBCC6

ダウンロードしたrarファイルを解凍します。
解凍すると、以下の3つのフォルダができます。

  • Root Files(bootイメージとSU関連が入っています)
  • CWR files(recoveryイメージが入っています)
  • Kernal(カーネルイメージが入っています)

※Android SDKのツールが動作する場所に解凍してください。

XOOMとPCをUSBで接続し、XOOM側はUSBデバッグ状態にしておきます。

1.bootイメージの書き換えとSUツールの送り込み

先ほど作成したRoot Filesフォルダに移動します。
コマンドプロンプトでfastbootを起動します。

>adb reboot bootloader

再起動すると、fastbootモードになりますので、以下のコマンドを入力します。

>fastboot flash boot root31.img

書き換えが終わったら再起動します。

>fastboot reboot

再起動が終わったら、以下のコマンドを入力します。

>adb remount
>adb push su /system/bin
>adb shell ln -s /system/bin/su /system/xbin/su
>adb shell chmod 4755 /system/bin/su
>adb push Superuser.apk /system/app

2.リカバリーイメージの書き換え

先ほどダウンロードしたCWR filesフォルダに移動します。

コマンドプロンプトでfastbootを起動します。

>adb reboot bootloader

再起動すると、fastbootモードになりますので、以下のコマンドを入力します。

>fastboot flash recovery CWR.img

書き換えが終わったら再起動します。

>fastboot reboot

3.カーネルの書き換え

microSDカードを本体に挿入してください。
コマンドプロンプトから以下のコマンドを入力します。

>adb reboot recovery

ClockworkMod Recoveryが起動するので、
「mounts and storage」を選択します。(ボリュームキーで上下、電源で決定)

さらに、「mount USB storage」を選択します。

これで、PCからはEドライブとしてXOOMのmicroSDカードが認識されるので、先ほど解凍したKernalフォルダ内の以下のファイルをEドライブにコピーしてください。
  • 3G_Light_ON_Speed.zip
  • Tiamat_Xoom-1.4.2_1.4Ghz.zip
コピーが終わったら、「Go Back」を2回選択して、
「install zip from sdcard」を選択します。

さらに、「choose zip from sdcard」を選択するとSDカード内のファイルの一覧が表示されます。

最初に「3G_Light_ON_Speed.zip」を適用してください。

その次に「Tiamat_Xoom-1.4.2_1.4Ghz.zip」を同様に適用します。

「Go Back」で戻った後、
「reboot system now」で再起動すれば完了です。

2011年7月26日火曜日

みずほビジネスWEB証明書更新

みずほ銀行の法人向けオンラインバンキング「みずほビジネスWEB」で、証明書を更新したら証明書の選択ダイアログが出るけど、証明書自体がリストされずに先に進まなくなりました。
そもそもこの記事にも書いたように、どうもこのサービスは証明書関係でおかしな現象が出ます。
でもって今回の対応策は、古い証明書を消すことです。証明書が複数あると、通常どれを使うか選択するダイアログが表示されるんですが、このダイアログがバグっているのか、証明書が出てこないんですね。
なので、証明書は1つだけにして前述の記事にある設定にしておけば回避できます。
同じ現象でハマっている方が依然みつからないので、僕だけの問題なのかも知れません。

2011年6月30日木曜日

AZ01MRのここは設定を変えておこう!

さて、モニターキャンペーンでお借りしていたArtiza Design社のWiMAXルータ(AZ01MR)ですが、本日がモニター最終日です。


このルータ自体の設定は特に変更しなくとも、クライアント側さえちゃんと設定してあげれば利用はできます(WiMAX回線のアクティベーションがされていない場合は、別途アクティベーションが必要です)が、やはりセキュリティ上問題もあります。そこで今回は、工場出荷状態の設定内容を確認し、変更したほうが良いと思われる箇所や、知っていると便利な設定などをご紹介します。
ルータの設定を変えるためには、PCもしくはスマートフォン(できれば画面の大きなタブレット)で、まずはAZ01MRに接続しておく必要があります。

ログイン
ブラウザを起動し、アドレス欄に「http://192.168.0.1」と入力します。
ログインダイアログが表示されるので、IDとパスワードを入れます(IDとパスワードについては、製品に同梱されていたQuick Guideを参照)。
正しくログインができると以下の画面が表示されます。
クリックで拡大
この画面はステータスを表示する画面で現在の状態(IPアドレスや利用しているチャネル、接続されている台数など)が表示されます。赤い矢印の所を見ると、どうも初期のセキュリティ設定は「WPA-PSK(TKIP)」を使っているようです。Androidではセキュリティ設定にWPA-PSKとWPA2-PSKが一緒に設定できるようになっているのであまり気になりませんが、機器によってはWPA-PSKとWPA2-PSKが分かれていたり、同じWPA-PSKでも暗号化にTKIPを使うかAESを使うかまで指定が必要なものもありますので注意が必要です。

無線LAN設定(基本設定)
クリックで拡大
ここで変更したほうが良いと思われる項目は以下の2箇所です。

  • 無線LANを有効にする
    AZ01MRは、無線LANルータとしてだけでなくUSBで直接接続してWiMAXモデムとして利用することもできます。当然接続できるのは1台だけですが、このような使い方をすることによって、より高速な通信が可能になりますし、USB経由でバッテリーも供給されるので、AZ01MRの電池が利用されないというメリットがあります。
    そこで、USB接続しか利用する予定がない場合は、このチェックボックスを外して運用することで、電力消費を抑えることができ、かつセキュリティ上も安心です。
  • キーまたはパスフレーズ
    接続する際に利用したセキュリティキー(電池カバーの内側に記載されている値)は、ここに設定がされています。本体に記載されてしまっている以上、ここは変更することをお勧めします。セキュリティ方式がデフォルトでWPA-PSKですので、パスフレーズは8〜63文字までで自由に決めることができます。忘れないようなものを指定しましょう。

IPアドレス設定
クリックして拡大
IPアドレスに関する設定画面です。変更しておいたほうが良さそうな項目は1箇所です。

  • DHCP配布アドレス数
    AZ01MRに接続してくるクライアントにIPアドレスを動的に割り当てる際、ここで設定した数を超えてしまうとアドレスが払い出しできなくなります。通常、一度IPアドレスを払いだされた機器はしばらくの期間(調べたところ、AZ01MRのリース期間は10日でした)は同じIPアドレスを利用できるようになっています。そのため、機器が10個以上になるとアドレスが枯渇してしまい、クライアント側で無線LANの接続エラーとなります。スマートフォンやゲームなど、色々と接続して使っている人は、少し多めに設定しておくと良いでしょう(論理的には253個は配布できるハズ)。

アドバンスト(省電力)
クリックして拡大
アドバンストメニューの中には、ルータに接続したクライアント機を外部(インターネット)に公開する機能などが含まれていますが、通常使うことはないでしょう。ただ、この中に省電力の設定があるので、ここは知っておくと良いと思います。

  • 通信がなければ自動的に電源を切る
    このチェックボックスと、その右側の電源を切るまでの時間(分)をセットで設定します。チェックをつけて、指定した時間内に一度も通信をしなかった場合、AZ01MRは自動的にスタンバイモードになります。スタンバイモードになった場合は、再度電源ボタンを押して起動させる必要がありますが、AZ01MRは起動時間が非常に短い(10秒程度)ですので、外出時などは設定しておいたほうが良いでしょう。
    初期設定状態ではチェックはオフになっています。

Admin(管理者)の設定
クリックして拡大
この設定画面に入るためのIDとパスワードを登録する画面です。IDもパスワードも工場出荷状態ではすべての製品に同じものが登録されてしまっているので、ここは設定を変更しておくことをお勧めします。
ちなみに、万が一設定したIDやパスワードを忘れてしまった場合は、本体を初期化することになります(本体の電源が入っている状態で、電源ボタンとWi-Fiボタンを同時に5秒以上押すことで初期化されます)。

総括
ルーターという製品の位置づけですので、単純にインターネットに接続するだけでなく、内部のサーバを外部に公開することなどもできるなど、機能が豊富であることがわかりました。
また、今後のバージョンアップで、SSIDをもう一つ作成することもできるようになるようです。こうすることで、セキュリティレベルの異なるネットワークを2つ持てるようになるので、一部のゲームのように、高度なセキュリティ対策が施せないものと、パソコンのように高度なセキュリティ対策が設定できる機器を混在させて利用することができるようになります。
今回のモニターでは、実際に外に持ち出して利用することがなかったのですが、他のレビューア様が色々と調査をされているようなので、そちらも参考にされると良いかと思います。
皆さんのレポートはこちらです。

2011年6月29日水曜日

UK版XOOM(3G)のHoneycomb3.1手動アップデート

すでにau版XOOM(MZ604)はバージョンアップしているのに、後発のUK版XOOM(MZ601)は未だOTAが来る気配がない・・・。
んじゃ、手動でアップデートしましょうかってことで、早速やってみました。

2011/7/1追記
下記の方法でアップデートすると、カメラ機能が動作しないことが判明しました。原因は調査中です。よって、こちらの不具合が解決するまでは実施はお控えください。

前提条件

  • XOOMはMZ601であること
  • rootedであること
  • PCにAndroid SDKがセットアップされていて、USBドライバがインストールされていること
  • XOOMにROM Manager(ClockworkMod Recovery)がインストールされていて、現状のROMをバックアップしてあること
  • アプリや設定ファイルをバックアップしてあること(途中ファクトリーリセットが入ります)
当然ですが、手動でのアップデートはご自分の責任のもと行ってください。何があっても僕は責任は持てませんし、質問も受け付けられません。

手順は以下のサイトに書いてあるとおりです。
[GUIDE] 3.1 for rooted EURO XOOM with working 3G in 5 easy steps [Update: 6/14]

5つの簡単なステップ・・とはいえ、それなりの知識が必要なので、手順を整理して分かりやすく書いておきます。

ステップ1.ファイルの準備
PC側に任意の作業フォルダを作成します(作業フォルダからadbコマンドが使えること)。

http://forum.xda-developers.com/showthread.php?t=1074609
から、
HMJ37_HC3.1_Both_Models_BRDizzled.zip(Step 2)
bootloader_patch_3.1.zip(Step 3)
HMJ37_root_sdcard_3G.zip(Step 4)
を作業フォルダにダウンロードします(ちなみに一番最初のファイルはかなり大きいので、ダウンロードに1時間以上かかります)。


http://toshsoft.de/xda/build.prop.frankenrom
を開いて、表示される設定内容を
build.prop.frankenrom
という名前にして作業フォルダに保存します。

ステップ2.入替が必要なファイルのバックアップ
USBケーブルで接続します。
作業フォルダ上で以下のコマンドを使ってファイルをバックアップします。
adb remount
adb pull /data/data/com.android.providers.settings/databases/settings.db settings.db
adb pull /data/data/com.android.providers.settings/databases/settings.db-wal settings.db-wal
adb pull /data/data/com.android.providers.settings/databases/settings.db-shm settings.db-shm
adb pull /data/data/com.android.providers.telephony/databases/telephony.db telephony.db
adb pull /data/data/com.android.providers.telephony/databases/telephony.db-journal telephony.db-journal
ファイルが5個ダウンロードできたことを確認します(サイズが0のファイルもあります)。

ステップ3.アップデートファイルのアップロード
作業フォルダ上で先ほどダウンロードしておいたファイルをアップロードしていきます。
アップロード先はXOOMの仮想SDカード(/sdcard)です。
adb push HMJ37_HC3.1_Both_Models_BRDizzled.zip /sdcard/
adb push bootloader_patch_3.1.zip /sdcard/
adb push HMJ37_root_sdcard_3G.zip /sdcard/
USBケーブルは外します。

ステップ4.アップデート
XOOM上でROM Managerを起動します。
「リカバリへ再起動」を選択して、リカバリーモードに入ります。
再起動後、ClockworkMod Recoveryが起動します。
「install zip from sdcard」を選択し電源ボタンで決定します。
「choose zip from sdcard」を選択し電源ボタンで決定します。
SDカードの一覧が表示されるので、以下の順番で適用していきましょう。
  1. HMJ37_HC3.1_Both_Models_BRDizzled.zip
  2. bootloader_patch_3.1.zip
  3. HMJ37_root_sdcard_3G.zip
3つとも適用したら、ClockworkMod Recoveryのトップまで戻ります。
「wipe data/factory reset」を選択して、ファクトリーリセットをします(仮想SDカードの内容は初期化されません)。
「reboot system now」を選択して再起動します。

ステップ5.バックアップしていたファイルを戻す
再起動後、初期化されているので初期設定画面がでます。
日本語を選択し、WiFiやGoogleアカウントのアクティベーションはせず、とりあえず起動させます。
USBケーブルを接続します。
以下のコマンドでファイルを戻した後再起動します。
adb remount
adb push build.prop.frankenrom /system/build.prop
adb push settings.db /data/data/com.android.providers.settings/databases/settings.db
adb push settings.db-wal /data/data/com.android.providers.settings/databases/settings.db-wal
adb push settings.db-shm /data/data/com.android.providers.settings/databases/settings.db-shm
adb push telephony.db /data/data/com.android.providers.telephony/databases/telephony.db
adb push telephony.db-journal /data/data/com.android.providers.telephony/databases/telephony.db-journal
adb reboot
USBケーブルを外します。

以上でアップデートは完了です。

これでmicroSDカードが利用できるようになりました。
あとはバックアップしておいたアプリなんかを戻して、細かい設定をし直せば完了です。

2011年6月15日水曜日

Androidで使うAZ01MR

Artiza Design社製WiMAXルータ「AZ01MR」のレビュー第2弾です。
同梱されていたクイックガイドによると、サポートOSは以下のとおりです。
    • Windows 7
    • Windows XP
    • Windows Vista
    • Mac OS X
    ただ、もちろん設定さえ間違えない限りほとんどのWi-Fi対応機器で使えるはずなので、今回はAndroid端末(XOOM)を使って接続をしてみたいと思います。

    Wi-Fi設定

    AndroidでのWi-Fi設定は、設定メニューの中にある「無線とネットワーク」の中にある、「Wi-Fi設定」から行います。ちなみにAZ01MRのサポートしているWi-Fiの規格はIEEE802.11b/gとなります。
    予めAZ01MRの電源を入れた状態で「Wi-Fi」のチェックボックスをONにすると、リストにモバイルルータがリストされます。
    クリックで拡大
    該当行をクリックすると次のような画面が表示されるので、電池パックカバーを外したときに印字されていたセキュリティキーの値を「パスワード」欄に間違えずに入力し、最後に接続ボタンを押します。
    クリックで拡大
    セキュリティキーが正しければ、これで接続は完了です。Wi-Fiの欄にモバイルルータのSSIDが表示されていることを確認します。
    クリックで拡大
    工場出荷状態では、セキュリティにWPA-PSK(TKIP)が設定されているようです。

    速度テスト

    無事に接続ができたところで、まずはどのくらいの通信速度になるのかを確認してみました。今回速度テストには、Androidアプリの「SPEEDTEST」を使っています。また、今回のテスト場所は社内(東京都港区虎ノ門2丁目)となります。
    まずはモバイルルータを端末の横においてテストしてみます。
    端末の横(室内)
    下りの平均が1,494kbps、上りの平均が1,802kbpsです。残念ながら、もう少し早いかなと思っていましたが、少し遅いですね。WiMAXは、場所によってかなり速度が違うので、室内だとこのくらいなのかも知れません。
    続いて、XOOMは移動せずルータだけを窓側に移動して計測しました。
    窓際(西向き)
    窓際(北向き)
    西側での下りは少し早くはなりましたが、その分上りが遅いですね。北側の窓際ではあまり変化はないようです。位置的にはXOOMとの距離が近いのが北側だったので、Wi-Fiでの速度劣化は関係ないようです。
    参考までに、本来利用している室内のWi-Fiアクセスポイント(802.11g)経由での計測値と、3G回線(FOMA High-Speed)の計測値を載せておきます。
    室内の既存Wi−Fi経由
    FOMA(High-Speed)経由
    さすがに既存のWi-Fiアクセスポイントは、有線(光100Mbps)に接続されているだけあって、上り下りとも9Mbps程度出ています。FOMAに関しても、今回はWiMAXよりも高速な数値が計測されました。
    ここで注目しておきたいのが、計測中の速度のブレです(赤矢印)。
    FOMA(特に上り)では、比較的計測中の通信速度が安定していることがわかりますが、WiMAXではかなり波があるようです。すなわち、WiMAXは瞬間での速度はかなり高速になることもありますが、電波の安定度があまり良くないようで、速度にムラが出ている感じです。
    今回はUQ WiMAX様のサービスを利用していますので、周波数は2.5GHz帯を使っていると思われます。一般的に、周波数が低いほうが電波は障害物を回り込みやすいので、FOMAの2.1GHzやFOMAプラスエリアの800MHzに比べると、室内やビルが多い都内などではWiMAXはムラがでてしまうのかも知れません。3Gと比較しても遅いようだと、あえてWi-Fiルータを使う意味も薄れてしまうので、回線速度を実際に実機で確認してから購入したほうが良いかも。

    さて、次回はAZ01MRのルータとしての機能や、変更しておいたほうがよさそうな設定内容についてレポートしたいと思います。