ゆれくるコール開発日誌

ゆれくるコール、あめふるコール、つながるコールや緊急地震速報のことなど

2017.11.1の通知訓練アンケート結果公開!

はじめまして、営業企画部の鈴木です。
今月1日に、ゆれくるコールで緊急地震速報の通知訓練を実施しました!
その際にFacebookTwitterでアンケートを取り、ようやく集計ができたので公開します。

今回、アンケート回答総数は395となりました!
たくさんの回答のご協力、ありがとうございました。

では早速結果をご紹介します。

あなたは緊急地震速報の訓練通知を受け取りましたか?

f:id:ken447:20171120163401p:plain
受け取った方が約7割を占めました。
アンケート回答者で見ると7割ですが、ゆれくるユーザー全体で見るともっと少なくなると思われます。
アンケートまで回答してくれる方は、やはり緊急地震速報の注目度も高いのですね。

訓練通知を受け取った際の行動についてお教えください。

f:id:ken447:20171120154029p:plain

続いて、訓練通知を受け取った方に、受け取った際に何をしたかを聞きました。
特に何もしなかった方が46%と、全体の半分近くを占めていました。
その他の意見には「びっくりして何もできなかった」というものもありました。
せっかくの機会なので、通知を受けるだけではなく身を守るための訓練にも繋げていきたいです。

実際に身を守る行動を取った方は4%と少ないですが、身を守るイメージをした方は40%くらいを占めています。
その他の意見の中にも、「家族に呼びかけた」という方もいました。

参加しなかった理由をお教えください。(複数選択可)

f:id:ken447:20171120154400p:plain

「受け取らなかった」と回答された方には、その理由を聞きました。
訓練のことを知らなかったという回答が多く、もっと周知をしなければ・・・と感じます。
ゆれくるコールは訓練前にFacebookTwitter、アプリのお知らせ通知を出しているのですが、他に方法があれば教えてもらえるとありがたいです。どうすればみんなが気づくのだろう・・・。

訓練通知を受信するにしていたのに通知が来なかったという方も50人近くいるようでした。
「最近通知が来ない・・・」という方は、端末を再起動のうえアプリの再インストールをお願いします。
その際、通知震度を低めに設定して、通知が来るかどうか確認してくださいね。
それでも来ない場合は、問い合わせフォームよりお問い合わせください。。。

訓練の必要性を感じないから受け取らないという選択肢もあったのですが、こちらは0票で安心しました。

学校や仕事で訓練に参加できないという方もいるので、訓練のタイミングや回数については検討しています。

ご利用端末のOSをお教えください。

f:id:ken447:20171120161205p:plain

やはりiOSのシェアが大きいですね。
iOS版は通知をタップしてアプリを開かないと、ゆれが到達するカウントダウンなどが見れないので、その画面を見たことがない人も多いのかも・・・?

あなたの性別をお教えください。

f:id:ken447:20171120161604p:plain

ゆれくるコール利用者の男女比は男性が多めなのですが、アンケート回答も同様の結果になりました。

あなたの年代をお教えください。

f:id:ken447:20171120152756p:plain

40代、50代の方が半分以上を占めています。
災害を経験して、防災意識の高い人が多いのでしょうか。
20歳未満と20代の方も思ったより回答してくれていたのですが、もっと若い人たちにも広めていきたいです・・・!

通知訓練やアプリについて、ご意見・ご感想がありましたらご自由にご記入ください。

自由に意見を書いてもらいました。
いくつかピックアップして紹介します。
・震度4と速報が出て一瞬ヒヤリとしたが、訓練で安心した。これからも備えていきたい。
・音声もあったので、実際のものとは区別できてよかった。
 タイマー機能などを使って個別に訓練できればもっといいと思った。
 有事の時にどの様な通知があるのかわかるので訓練は非常に良いものと思った。
・訓練は心臓に悪いからやらなくていい
・訓練は大切なものと考えております。今後も定期的にお願い致します!
・訓練があることを知らなかったので戸惑った。職場で自分だけ音が鳴ったため、止めるのに慌てました。
避難訓練のように、身を守る行動をとりたいと思いました。
・防災担当をやっていましたので多くの皆さんが参加して災害に備えて欲しいです、自助で
・仕事柄現場作業が多いので凄く助かってます。今後にも大いに期待してます。命、守れそうです。

集計したところ、「訓練通知を受け取った方」で身を守るイメージをした方は訓練に肯定的な意見が多かったです。
訓練の重要性を理解している方も多いということが分かったので、もっと多くの方に参加していただけるように取り組んでまいります。

C#でAWS SNS

こんにちは、商品開発部の池端です。

 

C#AWS SNSを使って、iOSAndroidにプッシュ通知を送る。

C#のサンプルがあんまりなかったのでメモメモ。

コードは以下のような感じ。

var sns = new AmazonSimpleNotificationServiceClient();
var message = "{\"default\": \"メッセージ\", \"GCM\":\"{\\\"priority\\\":\\\"high\\\", \\\"notification\\\":{ \\\"text\\\": \\\"メッセージ\\\"}}\", \"APNS\":\"{\\\"aps\\\":{\\\"alert\\\":\\\"メッセージ\\\",\\\"sound\\\":\\\"default\\\"}}\", \"APNS_SANDBOX\":\"{\\\"aps\\\":{\\\"alert\\\":\\\"メッセージ\\\",\\\"sound\\\":\\\"default\\\"}}\"}";
var req = new PublishRequest("arn:aws:sns:xxxxx:xxxxx:xxxxx", message);
req.MessageStructure = "json";
await sns.PublishAsync(req);

 メッセージには、FCM(GCM)とAPNSのproduction、sandboxの指定をしています。

各環境毎のオプションの指定はお好きなものを指定してください。

ポイントは、defaultの指定は必須、json内のjsonエスケープ、PublishRequest.MessageStructureに"json"を設定することあたりですかね。

単純にメッセージを表示するだけで音を鳴らしたりの環境毎のオプション指定をしないのであれば、defaultのみの指定でもよいかとおもいます。

 

誰かの参考になれば幸いです。

それではまた!

 

AWS Lambda C#でDynamoDBアクセス時のハマりポイント

こんにちは、商品開発部の池端です。

 

AWS API Gatewayでリクエストを受け、DynamoDBを検索して結果を返すような処理をAWS Lambdaでやりたい。

昨年12月よりLambdaでC#が使えるようになったので、C#でやってみましたが、ハマってしまったポイントがあったのでメモメモ。

 

AWS Lambda C#に関しては、下記の記事を参考にさせて頂きました。

qiita.com

ohke.hateblo.jp

 

1.Lambdaプロジェクト新規作成時、パッケージの復元に失敗

Lambdaプロジェクト新規作成時に、ソリューションエクスプローラに「パッケージの復元に失敗しました」とエラーが表示されました。

こちらは、ツール→NuGetパッケージマネージャ→ソリューションのNuGetパッケージの管理の更新プログラムタブよりMicrosoft.NETCore.Appを更新することで解消されました。

 

2.AWS LambdaへのPublish時やテストプロジェクトのビルドでエラー

AWS LambdaへのPublish時やテストプロジェクトをビルドする際に、下記のようなエラーが表示されました。

f:id:ken447:20170307153814p:plain

上記はAWS LambdaへのPublish時のエラー表示ですが、テストプロジェクトビルドエラーの際はVisual Studioの出力、エラー一覧タブに同様のメッセージが表示されます。

こちらはproject.jsonにruntimesを指定することで解決しました。

"runtimes": {
    "win7-x64": {}
} 

指定するランタイムID(win7-x64の部分)はそれぞれの環境に合わせてください。

ランタイムIDの種類はコチラ

 

3.DynamoDBのScanでエラー

これが一番ハマった。。

LambdaにPublishし、DynamoDBでScanをすると下記のエラーがLambdaから返却されました。

{
    "errorType": "TypeInitializationException",
    "errorMessage": "The type initializer for 'System.Diagnostics.Stopwatch' threw an exception.",
    "stackTrace":[
        "at xxxxx.Function.FunctionHandler(Param input, ILambdaContext context)",
        "at lambda_method(Closure , Stream , Stream , ContextInfo )"
    ],
    "cause":{
        "errorType": "DllNotFoundException",
        "errorMessage": "Unable to load DLL 'api-ms-win-core-profile-l1-1-0.dll': The specified module could not be found.\n (Exception from HRESULT: 0x8007007E)",
        "stackTrace":[
            "at Interop.mincore.QueryPerformanceFrequency(Int64& value)",
            "at System.Diagnostics.Stopwatch..cctor()"
        ]
    }
}

こちらはstackoverflowのこの記事を参考に、project.jsonの"Microsoft.NETCore.App"にtypeの指定を追加することで解決しました。

"Microsoft.NETCore.App": {
    "type": "platform",
    "version": "1.1.0"
}

"type":"platform"の指定有無で、.NET Coreをアプリに含めるかどうかを指定します。

詳細については下記に解説があります。

docs.microsoft.com

 

だれかの参考になれば幸いです。

それではまた!

 

緊急地震速報の精度改善

こんにちは、商品開発部の池端です。

 

この度、気象庁により緊急地震速報の精度が改善され、昨日12月14日より運用が開始されました。

テレビや新聞、ネットなどのニュースでも取り上げられていましたね。

www3.nhk.or.jp

www3.nhk.or.jp

 

気象庁からの報道発表はコチラ。

www.jma.go.jp

 

今回は2つの技術改善が行われています。

 

1.同時に複数の地震が発生した場合の精度の改善

いままで同時に複数の地震が発生した場合、それぞれの地震の識別や地震の規模の推定が正確に行えず、震度を過大に予測して緊急地震速報が発表される事例がありました。

東日本大震災の直後には地震が頻発したので、こういうことがよくあったかと思います。

こちらの事象については気象庁でもいままで何度かの改善を行い、その都度精度は向上していましたが、今回は「IPF法」とよばれる新たな手法を取り入れることでさらに精度が向上しました。

IPF法とはIntegrated Paticle Filter法の略称で、内閣府の最先端・次世代研究開発支援プログラムに採択された「東南海・南海地震に対応した正確な地震情報を提供する実用的早期警報システムの構築」の成果のひとつです。

詳細は気象庁の報道発表資料に詳しいですが、この手法を取り入れることで、複数地震発生時の震源の決定や同一地震判定の信頼性が向上します。

 

2.平成 28 年8月1日に発生した緊急地震速報の誤情報の発表への技術的対処

本年8月1日に発生した、最大震度7緊急地震速報の誤報に対する対応が行われました。

この誤報ではゆれくるコールからも通知が行われ、ご利用のみなさまには大変ご迷惑をおかけしました。

誤報の原因は、地震観測点の電源部故障により、地震計の出力データに急激な変化が生じたことでした。今回の対応では、地震学的にありえない大きさのデータを除外する、地震学的に考えられるマグニチュードの上限値を設け、過大な予測をしないといった対応が行われています。

 

今回の気象庁の対応で緊急地震速報の精度は改善されますが、すべての地震をカバーするような精度改善ではありません。

緊急地震速報には技術的限界もあり、必ずしも大きな揺れの前に通知されなかったり、予測には誤差が伴う場合があります。

緊急地震速報の特性をよくよくご留意の上、防災・減災にお役立て頂ければと思います。

www.data.jma.go.jp

 

それではまた!

 

C#でAWS Kinesisからデータをひっこぬく

こんにちは、商品開発部の池端です。

久々の開発ブログです、、

 

AWS KinesisからデータをひっこぬくのをC#でやりたい。

 

Kinesisのクライアントを作るにはAWS SDKで実現してもいいんだけど、Kinesis Client Libraryというのがあって、それを利用すると楽に開発できる、らしい。

ここにそう書いてある。

docs.aws.amazon.com

 

Kinesis Client Libraryはいろんなプログラミング言語用のものが用意されていて、C#のもある。
GitHubここにライブラリ、サンプルコードひっくるめてあります。

 

これをダウンロードしてきてサンプルコード動かしてみれば、C#でのKinesis Client Libraryの利用方法がなんとなくわかります。
このサンプルコードを動かすのに、プロジェクト丸ごとビルドしてサンプルコードのプロジェクト実行すればよいわけでなく、ちょっとした手間が必要でした。
GitHubのREAdMEに書いてあるのでその通りにすればいいんだけど、日本語での解説記事があんまりないようなので、この記事で手順を書いてみたいと思います。

 

0. Java実行環境の準備
Kinesis Client LibraryはJavaのライブラリなのです。
そのためJavaの実行環境が必要になります。
Javaの実行環境がない場合は、Javaの実行環境をあらかじめ用意しましょう。

 

1. Amazon Kinesis Client Library (.NET)のダウンロード
GitHubここからダウンロードします。

 

2. プロジェクトのビルド
何も考えずに、ソリューションのビルドってするとビルドエラーになっちゃいます。
任意のプロジェクトを選択して、個別にビルドするとNuGetがうまいことやってくれます。
その後ソリューションのビルドをすればおk。

 

3. Kinesisにデータをつっこむ
SampleProducerというプロジェクトがKinesisにデータをつっこむサンプルです。

 

こちらを動かすにはAWS Credencialsの設定が必要です。
AWS Credencialsの設定はAWSSDKが導入されていて、Credencialsの設定がされていれば必要ないんですが、検証を行った2016/12/06現在、なぜか最新のAWS SDK(AWSToolsAndSDKForNet_sdk-3.3.27.0_ps-3.3.27.0_tk-1.11.0.0.msi)がWindowsにインストールできない状況でした。(インストール中に「There is a problem with this Windows Installer package」とかいわれちゃう)
そのためプロジェクトのapp.configのappSettingsに、"AWSAccessKey"と"AWSSecretKey"を追加しました。

 

プロジェクトを実行すると、USEast1(米国東部(バージニア北部))にmyTestStreamという名前でKinesis Streamが作成され、10個のテストデータがつっこまれます。

 

4. Kinesisからデータをひっこぬく
SampleConsumerというプロジェクトがKinesisからデータをひっこぬくサンプルです。

 

まず、SampleConsumerプロジェクト内のkcl.propertiesのexecutableNameの設定を、"bin/Debug/SampleConsumer.exe"とします。
"Debug"の部分はビルドの仕方(Release or Debug)に合わせて変更してください。

 

次に、コマンドプロンプトでSampleConsumerプロジェクトのディレクトリにcdし、下記のコマンドを実行します。

..\Boot strap\bin\Debug\Bootstrap.exe --properties kcl.properties --execute

こちらも"Debug"の部分はビルドの仕方(Release or Debug)に合わせて変更してください。

 

実行が始まると、初回実行時に必要なもの(Javaのライブラリ)をダウンロードし、動作するようになっています。
標準出力にKinesisから取得したデータが表示されると思います。(その他にもいろいろ標準出力されますが、、)
こちらはCtrl+Cで止めるまで動き続け、Kinesisにデータが追加される度に動作します。

 

なおSampleConsumerは処理の際に、USEast1(米国東部(バージニア北部))のDynamoDBにDotNetKinesisSampleという名前でテーブルを作成します。

 

こちらを動かすにもAWS Credencialsの設定が必要です。
上記の理由によりSDKが導入できなかったので、Windowsユーザのホームディレクトリに.awsというディレクトリを作成し、credentialsファイルをおき、その中にaws_access_key_idとaws_secret_access_keyを記載しました。
ちなみにWindowsで"."からはじまるディレクトリの作成は、".aws."とタイプします。

 

5. あとかたづけ
USEast1(米国東部(バージニア北部)) に自動的に作成されたKinesis StreamとDynamoDBのテーブルを忘れずに削除しましょう。
つかわなくても、存在するだけでお金かかっちゃいます。。

 

このサンプルを動かし、サンプルプロジェクトのコードを見ればなんとなく使い方がわかるんじゃないかと思います。
動作させるのにJava環境が必要だったりするので、実運用環境ではその辺がネックになったりしそうな気もしますね。

 

だれかのお役に立つと幸いです!

 

キャンセル報について

こんにちは、商品開発部の齋藤です。

先日の震度7の誤報では皆様にご心配をおかけいたしました。

その誤報について、15秒後にキャンセル報と呼ばれる情報が発信されていました。先ほどの地震情報は誤りであったとする情報です。

私どものシステムでは緊急地震速報は自動的に震度計算を行い、お客様の端末に配信する一方で、キャンセル報については自動的には配信せず、事実確認を行ったうえで手動で配信する、という対応を行っております。

緊急地震速報が誤った情報を出すことがあることと同様に、キャンセル報も誤った情報が来る可能性は0ではありません。


震度7地震が来ます(実際には来ない)
震度7地震は来ません(実際には来る)


この2つでは後者の方が甚大な被害を出すことが想定されます。
キャンセル報の方が緊急地震速報よりもデリケートな情報であると私どもは考えており、そのためキャンセル報を自動で出すことはしておりませんでした。


しかしながら今後は、気象庁様やその他の配信事業様などと、キャンセル報の扱いについてご相談させていただいた上で、これからのキャンセル報の扱いについて検討してまいります。


これからも改善を続けてまいりますので、ゆれくるコールを今後ともよろしくお願いいたします。

震度速報の配信に対応しました

こんにちは、商品開発部の池端です。

 

本日ゆれくるコール for Android Ver.3.3.2をリリースしました。

このリリースで震度速報の通知に対応しました。

このタイミングでゆれくるコール for iOSも同様の対応をしました。

iOS版はアプリの更新はありません。)

 

この震度速報とは、震度3以上の地震発生後約1分半後に、気象庁より発表される地震のお知らせです。

 

緊急地震速報ではなく、地震の揺れの後の震度の観測情報ですのでご注意ください!

 

地震発生直後、一番最初にテレビにテロップで流れる情報がありますよね?

あの情報が震度速報です。

 

気象庁が発表する地震の情報には下記のものがあります。

震度速報は、地震の揺れの後の震度の観測情報としては最速の情報です。

f:id:ken447:20160427173939p:plain

地震情報の詳細については下記をご覧ください。

www.data.jma.go.jp

 

ところでゆれくるコールももともと「地震情報」という震度観測情報を通知していました。

設定した地点の都道府県で、最大震度が設定震度に到達した場合に通知し、最大震度5弱の場合は全国一律通知を行います。

 

この地震情報の通知は、上記表中の「各地の震度に関する情報」をもとに通知を行っており、揺れの後約5分後に通知されていました。

 

熊本地震の発生後、「ゆれくるの通知が遅い!」という声も頂いておりますが、原因のひとつはこの地震情報の通知が遅いということもあったのかと考えています。

 

今回の対応で、震度3以上の地震が発生した場合は、震度速報をもとにして地震情報を通知するようになります。

大きな地震発生時は、より早く震度の観測情報が届くことになります。

 

ちなみに、緊急地震速報地震の揺れの後の震度の観測情報に先立って発表される情報になりますので念のため。

緊急地震速報のしくみや詳細については下記をご覧ください。

www.data.jma.go.jp

 

よりいっそう便利になったゆれくるコールを、みなさまの防災・減災にお役立て頂ければと思います。

 

それではまた。

 

がんばろう!熊本・大分