データサイエンス、あなた(御社)はどのレベル?

最近、またまたAIって言葉が頻繁に登場してきているけど、それは何回目のブーム?かご存じだろうか?1990年ころは、一定のアルゴリズムに従って挙動する仕掛けがあればAIと呼んでいました。その後、繰り返しAIのブームがありました。そして現在のAIブームはディープラーニングをベースにしたものです。ディープラーニングは単機能として成功した仕掛けといってもよいでしょう。なぜそうなるのかわからずに使うのは厳しいので、なぜそうなるのかを解析して理解し使いこなしていこうとしているのが現在のフェーズです。将来のAIは多数のディープラーニングの仕掛けを多数のディープラーニングの仕掛けで最適に組み換えながら使っていくものになるでしょう。その仕掛け自体が自己学習を始めたらいわゆる技術的特異点=シンギュラリティーとなるにときがくるでしょう。今の時点で、シンギュラリティーを迎えるためのハードウェア環境はすでに整っていてあとは組み合わせる仕掛けを整えるだけでよいくらいのレベルになっているように思います。もちろん特定のマシンというわけではなくインターネットのネットワークにつながっているリソースを考えればということです。
 さて、現在のAIの利用状況を見ると業種ごと、企業ごと、人ごとにレベルに違いがあり格差が生じていて、この格差は”AI格差”といわれています。そしてここでいうAIは、前述のディープラーニング以降のAIです。
 ということで、あなた(御社)はどのレベルなのかを振り返ってみてください。みてください。AI活用といっても、ディープラーニングを活用した自動機械化から、ビックデータ解析により新たなビジネスを掘り起こすことまで様々です。AI格差はこのAI活用をうまくできたものがいわゆる勝ち組?になれると言っているようなものでしょう。
 ディープラーニングの活用をすでにしているなら、さらに活用範囲を広げるときに次のようなことも考えればよいでしょう。今時点でディープラーニングの活用ができているところはあまりありません。これからディープラーニングを活用するとして、どのように導入していけばよいのか考えてみましょう。ディープラーニングには入力と出力があります。まず”出力”を何にするのかを考えましょう。普通は利益が出るとか都合がよくなる何かです。例えばある自販機を考えたとき、売上金とか、利益などを指標にするのがよいでしょう。つぎに”入力”つまり”出力”を説明するための情報です。ある売上を説明するための情報です。自販機を設置した場所の条件とか時期とか商品の種類とか商品の配置とかさまざまな情報を入力とします。この ”入力”と”出力”の データのセットを用意します。一昔前のデータマイニングでは各入力と出力の相関関係を出したり、推測の関係式を立てたりして推測していました。ディープラーニングでは、このデータのセットを投入して売り上げを予測する仕掛け”学習済みデータ”を用意します。また、この ”学習済みデータ” をつかって、別途用意したデータを投入して予測精度の確認や予測利用します。このように ディープラーニング にはデータが必要です。そしてこのデータを用意することが第一歩です。データがないならデータを取るところから始める必要があります。ただ今どきはすでに多量のデータがあって、そのデータを人手で処理しているところもあるでしょう。そういう場合はどのようにディープラーニングを導入するかを検討するだけでよいでしょう。ディープラーニング活用の一歩手前の状態にあるといってよいでしょう。データをこれから収集するという状態であれば、何の情報を収集するのかから考えることになりますが、思いつくままに必要と思われる情報を順次追加していく方法だとスピーディーな対応が困難です。その方法を選択する何か理由があるのならそれでも良いでしょうが、効率的に進めるなら情報収集してそれを活用する仕掛けに拡張性を持たせつつ、”今後使うかもしれない”というあまり必要ではないかもしれない情報まで含めて収集してしまうのが良いでしょう。本当にゴミの情報は不要なので、仕分けることは必要です。つまり情報を収集し始めるときに何を収集するのかデータの保存領域のサイズを気にしながらデータを集めるのはストレージの価格が安くなってきた2019年時点では無駄です。取捨選択に時間をかけるのをやめて、収集したデータをどこに保存してどう使うかに時間を使ったほうが良いです。逆にビッグデータサイズのデータで保存しているかどうかを気にしたほうが良いかもしれません。兎に角”出力”をどうするか決めて”入力”となりそうな情報を使える形で収集していき、どのように使うかに注力すればよいでしょう。

 このようなディープラーニング活用のようなところを一括りにして、「シンギュラリティー 一歩手前の技術」の活用として、”Pre Singularity Technology (PST)”と定義します。PostSTに何があるか楽しみですが、まずはPSTを使い倒しましょう。
 ちなみにわたしは長年Singularity で思い起こすのは、”magnetic singularity”か”gravity singularity” です。

将来的には、完全自動運転でとかと思いましたが、免許証を認証するとかすぐ対処しないといけませんね

「免許自主返納後に運転して事故」とか、何年も先の話をしている場合ではないですね。2020年以降販売する車は免許証を差し込んで、運転を許可されている車かどうか認証して、確認できないとエンジンがかからないようにするとかすぐに対策しないとしないとけませんね。

 自動運転をすぐに実現するのは厳しいでしょうが、運転免許証を認証するのはすぐにできるはずです。

まず、ICチップを組み込んだ免許証ですが、一番遅い時期に導入された鳥取県でも2010年に導入されています。このため全国で導入されてから8年以上経過しています。運転免許証の有効期間は長い人でも5年ですので、すでにすべての人の免許証はICチップが入ったものに切り替わっています。

また、免許証のICチップには 「氏名」「生年月日」「免許証交付年月日」「有効期間」「免許の種類」「免許証番号」「顔写真」 の情報が入っています。ICチップを読み取る機器はすでにありこれをベースに開発すれば、有効期限内の運転免許があるか、この免許証で運転可能な車かどうか、をチェック可能です。ETC機器と同額程度で実現できるのではないでしょうか。 また、画面に氏名や顔写真を表示することも簡単にできそうで、免許のまた貸しにもある程度の抑止力があるでしょう。さらに、半年くらい開発期間は長くなるかもしれませんが今どきのディープラーニング技術を使って、「顔写真」と運転者が同一人物か顔認証でチェックすることもできるでしょう。

いろんな方面からの対策がありますが、役所関係が本気になれば免許ベースの対策はすぐに現実できそうな感じがします。

最近、多い自動車事故についての統計解析

最近、多い自動車事故について統計データを分析、解析してみようかとデータを探してみました。”交通事故総合分析センター”のサイトから入手できそうですが無料で入手できるのは統計解析後の情報だけでした。有料ならどこまで生データを入手できるのかよくわかりませんでした。無料で入手した統計データでは確認したい情報はありませんでした。以下に、何を確認したかったのかなどを書きます。

 事故件数は報道されている件数よりも遥に多いはず。ということは、報道は一部を報道しているだけなので、そこには報道関係者などのベクトルがかかっている。そのベクトルは妥当なのか、報道されている統計後の情報は、意図的に元データを操作するなどデータ自体にもベクトルがかかっていたりしないかを確認したかったのです。

まず、ぱっと思いつく疑問を挙げてみました。

・高齢者の事故が多いとされているが、何か傾向はあるのか?

・報道写真を見ていると、特定車種をよく見る。車依存の事故が多いのでは?

・今どきの分析での成果はなにかあるか?
とりあえずこの辺についてコメントします。

■”高齢者”に関する分析
・ 「運転者年齢層別の事故件数」や「 高齢者の事故 」の統計データがありました。 計数データはほかの年齢と比較しないと、あまり意味がないでしょう。事故を起こしたのが高齢者かどうか、資料での記述”第1当事者”の年齢別のデータについては、人口統計の補正はしているようですが、運転者人口とか運転時間(人・時)を母数とした情報にはなっていません。この辺の考慮や、運転時間別の比率つまり普段運転していない人のほうが多いとか、自動車を乗り換えてからの期間が短いつまり操作性が異なる車に慣れないうちに起こす事後が多いとか、組み合わせてみるとより顕著な結果が得られるように思います。

■”車種別”の分析
車の台数が多いから、よく報道に登場するのかどうかとか車種別のデータがありません。気が付いている人も多いので、統計データを公開しないのは何か意図的に隠ぺいしているように見えますよね。明らかに何かあるのなら情報を公開して、みんなで議論しつつ対策を進めるべきでしょう。逆に何もないなら公表しない理由は何のでしょうが、少なくとも何かる車種があるので公開できない状態なのでしょうか?よくあるパターンは、気にしているところは何もないが、思わぬ車種に特異なデータがあったりしますね。

■” 今どき”の分析
今どきの分析ならもっと面白い結果が出てきてもよさそうですが、その辺が何もない感じです。これだけ大量のデータがあるのだからちょっと何かすれば改善できるネタは出てくるはずなのですが。

↑感覚的にはそうかもしれないが、分析的なアプローチがない感じです。また、プリウスをじっくり乗りこなしたうえでも感じる違和感には到達していないと思われ、深堀りした内容にはなっていない感じがします。

↑ 最近のブレーキとアクセルの踏み間違いとみられている件に触れているが、その件についての原因周りの話はなく、 ギア周りの話に終始していて分析不足の感がある。

↑ギア周りの話は、同感です。 最近のブレーキとアクセルの踏み間違いとみられている件には触れていない。

↑全体的に同感ですが、身振り手振り付きの喋りながらの運転は危険運転とまではいかないが、いまいちです。さて、直近の事故は、事故ごとに特性は違うので、それぞれの事故ごとに分析が必要でしょう。

最近の車には、一昔前のフライトレコーダと同レベルの情報は残っているのでしょうからデータ解析すれば何かわかるでしょう。入力信号の混線や人為的なデータ破壊とかまで考えるとデータ矛盾のチェックなど大変な作業かも知れません。

できるだけ早く、完全自動運転で何とかしてほしいです。そのレベルに辿り着く途中の車のデザインは現状と変えないほうようにするとか、新しいデザインの車は一定基準を満たした人だけ運転できるとか、いろんな角度からの対策も必要そうですね。

バージョンアップ情報、脆弱性情報の自動チェックを正式運用開始

先に書いた「Webページの更新内容自体が、動的更新によるものかどうかを自動チェックして、通知するかどうかを切り分けるように強化」の完了し、うまく機能することが確認できたので、正式に運用を開始しました。また、「日本語でのメール送信」機能も組み込んだので見やすく、作業効率が改善しました。今後、新たなソフトウェアのチェックが必要になったときにチェックルールをメンテナンスしていきます。

雨が降りだしたら自動で排水 

消費電力ほぼゼロのはずの電気代が1か月で5500円とか、9500円に増えていることに気がつきました。調べると排水ポンプが稼働しっぱなしになっており、常に「ジョロジョロ」と排水されていることが原因と判明しました。普通は、「ドバー」っと一気に排水されて水がなくなると自動で止まります。これは排水ポンプのフロースイッチが効かなくなっていることが問題原因なので、本来は排水ポンプを修理もしくは交換するところです。しかし、費用も抑えたいし、コンセント側で電源をON/OFFしてやれば同じ動作ということで、余っていたスマートコンセントを付けてみました。そして指定した時刻に定期的に排水するように設定しました。この変更で、電気代は1か月で390円に激減しました。これは意図した通りなのですが、故障する前の電気代は1か月あたり1100円程度だったので、期待以上の削減です。ポンプの待機電力より、スマートコンセントの消費電力のほうが小さいとは思えないので、以前は現状のポンプの稼働頻度よりも高頻度でポンプが稼働していたと推測されます。

短時間に多量の雨が降った場合、自動では排水されず、水が溢れるかも知れないので、少し工夫してみます。
IFTTTのサービスを使って、雨が降り出したら排水ポンプを動かすAppletの設定をします。まずIFTTTで「New Applet」すると次が表示されます。

「+this」をクリックして実行する条件”トリガー”を設定します。ここでは「Weather Underground」を使っています。検索枠にサービスの名称” Weather Underground ”の頭から数文字を入れると選択肢が表示されます。
” Weather Underground ” をクリックします。

次に実行条件を選択します。雨が降ったら起動したいので、”Current condition change to ….”(現在の天候がxxxに変わったら)を選択します。

”Current condition” は「Rain」(雨)を、Locationをマップで指定します。「Create trigger」をクリックします。

「+that」をクリックして、何を実行するかを指定します。

”実行条件”と同様に、実行する処理をサービスの中から選択します。ここでは、利用するスマートコンセント”Meross”を指定します。

”Turn on”(電源オン)を選択します。

登録した”排水ポンプ”のスマートコンセントを選択し、「Create action」をクリックします。

設定した内容を任意の名前を指定します。 「Finish」をクリックしIFTTT設定を完了し保存します

以上で、「雨が降りだしたら自動で排水」することができます。排水ポンプを止めるほうはスマートコンセントのスケジュール設定で「1分後にオフ」を登録しているので、1分後に自動的に排水ポンプは停止します。

他のサービスやWebRequest、Webhook、独自実装を組み合わせて排水量制御とか、排水の代わりに灌水の制御をするようにして、雨の状況を予測して灌水するかどうかを制御するとかいろいろできますね。

Pythonで日本語メール送信

定期実行タスクの機能を使ってメール送信していましたが、content-typeを次のようにcharsetを指定したいのに、

Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US

つぎのように指定されています。
Content-Type: text/plain; charset=ANSI_X3.4-1968

このcharset指定のメールでは、日本語の文面が文字化けしてしまいます。受信したメーラーで明示的に文字コードを指定することで文字化けは解消しますが、いちいち指定する手間が大変です。そこで定期実行タスクのメール送信機能は使わずに、Pythonから直接送信するように変更します。

Python2.6で使用するので、 Uchida さんのコードを参考にさせていただきました。

参考のための補足情報:

・デバック方法
smtp = smtplib.SMTP(c[‘host’], c[‘port’])
の次の行に 「 smtp.set_debuglevel(True) 」を追加することで、メールサーバとの通信内容を確認できます。

・ユーザー名、パスワードの指定にはダブルクオーテーションでくくるのはNGです。ダブルクオーテーションもユーザー名、パスワードとして送信されます。

user = <アカウント名>
password = <パスワード>

このPython実装でのメールでは、charsetは次のように設定されます。

Content-Type: text/plain; charset="iso-2022-jp"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

以上の設定により 、メールの日本語文面を文字化けせずに参照することができます。 これをベースに、脆弱性情報の通知メールに送信機能を組み込みます。