工場装置の音データから異常を検知するには
山中遼太氏（以下、山中）：このアーキテクチャで作ってみたものをご紹介したいと思います。1つ目は、工場装置の音データから異常を検知してみましょうというものです。
これは1つの仮定なんですが、工場装置が「ウーン」と鳴っているときに、もしかしたら壊れる前に少し音が変わったりするんじゃないかなと。
熟年の技師の方はそれがわかるかもしれないけれども、人不足で若い人になってくるとそれがわからなかったりする。「そういうことってもしかして学習でできるんじゃないの？」という話を少し考えてみました。
これなんですけれども、工場装置、タービンみたいなものがあって、こんな感じの音ですね。ずっと変わらない音。
（通常時の音が流れる）
これが異常になると、こんな音になります。
（異常時の音が流れる）
明らかに違う音です。これが運用時に音が変わるというパターンなんですが、確か15秒ぐらいのところで変わるので、ちょっと耳を澄ませてみてください。
（通常音から異常音に変わる様子が流れる）
ここで変わる。これぐらいはっきり変わっていればわかるだろうということで、なにかしら末端のデバイスでそれを収集します。でも、音のデータってこういう感じですよね。「ウーン」というのがあって。
これを1秒おきにバラバラに分割して、それで音データを周波数解析みたいなことをします。これは末端のデバイスで十分できる話ですので、基本周波数が287.7でエネルギーが56.2。人間の聞こえない音域も含めて音量みたいなものを出してきます。
こういった特徴量が出てきたら、これを1回データベースに入れておきましょう。構造化できたデータですので、データベースに入れておきます。過去データとしてどんどんたまりますので、それをおそらくは一度分析用サーバにコピーして、機械学習して予測モデルを作ろうという話になります。
“教師なし学習”で異常を検知
機械学習する過去データというものがこれですが、これが毎秒バーっと出てきます。
「FF」というのはFundamental Frequencyといって、先ほどの周波数ですね。音量みたいなものも出ています。もしかしたら、その時に気温などのデータも一緒にとっているかもしれません。
そのデータをコピーして、この機械学習に渡します。例えばこれを、Support Vector Machineと言われるアルゴリズムですけれども、こちら（左側）が正常データでこちら（右側）が異常データです。
人間が見てもわかるとおり……これはいろいろな軸ですね。音量と周波数と、もしかしたらもっと高次元な軸があるかもしれませんが、その多次元空間のなかでこれらとこれらを分けるような境界面を考える。これは関数が1つそこで生まれるわけなんですけれども、それ自体がモデルです。
モデルが1つできれば、先ほど音が「ウーン」と言って15秒ぐらいで変わったものに当てはめてあげると、ピッと「ここからここの時に音が正常から異常になった」ということがわかるということになります。
先ほどのツールで見てみたところ、こういう感じで音がウォーって出ていたのが途中から赤になって、「これは異常です」とちゃんと判定してくれています。
とはいえ、実はこれはぜんぜん間違っていて。普通はこの異常音というものはわからないわけですね。どう異常になるかということはおそらく機械の壊れ方によるでしょうし、わからない。
そうなると正常時の音しか手に入らない状態でやらなければいけなくなりますので、実際にはこんな感じです。正常の音だけはこういうふうにあって。
教師なし学習と言われるものになりますが、この正常の音のうち、おそらくはたまにちょっと外れ値もあるだろうから、95パーセントぐらい重心から近いところのデータポイントを全部含むような、最も体積が小さい境界面を考えてあげましょう、みたいなことをやります。
この境界面ができたら、先ほどの音がウーンと変わっていったものに対して当てはめます。ちょっと外れたりするけれども、5パーセントぐらいを許してあげることにして、「ここからは異常ということにしましょう」という感じでやれば、先ほどと同じように、教師がなかった時と教師がある時、異常データがある時もなかった時も、一応はこんな感じの機械学習ができるのではないかと。
とくにIoTのようなところで機械学習が期待されているのは、この教師なしのデータになるのかなと思います。
データベースのエンジンの中で機械学習をやってみる
このようなデータは、音だけではなくて、例えば電力や電圧、温度、それから粘性、pHなど、いろいろなデータが出てくると思います。振動などもあるかもしれないですね。こういったデータがどんどん出てくると、そのデータはどういうデータになってくるかというと、こんな感じですね。
1秒おきや30秒おきの場合もありますが、そこにたくさんのセンサーが、右のほうに400ぐらいバーッと並んでいるんですね。なんのセンサーかもわかりませんが、これをとりあえず学習してみることになります。
400カラムで2年間分とか渡されて、データが増えてくると、もうこれを分析用サーバにコピーするのが鬱陶しくなってくる。「せっかくデータベースの中に入ってるんだから、データベースのエンジンの中で機械学習をやってしまおう」という話になってきます。
一度、機械学習をデータベースのほうでできるようになると、アプリケーションから使えるというのが、先ほどから見てきたところかと思います。
SQLアプリケーションで先ほどのように予測結果を取ってくる。すると、例えばこういう感じで、1ヶ月機械学習していて、その次の日とかにだんだんこの予測値、正常である信頼度というものが下がってくるんですね。
それはおそらく、工場の中でのいろいろなセンサーが徐々に違う値を出してくる。季節が変わればおそらく温度も変わるし。そういったことですね。
それだとしょうがないので、毎晩過去1週間だけ学習させるようにして、「その次の日になにかガクッと落ちるようなことがあったら、なにかおかしいぞ」とやってみたら、ガクッと落ちた時がありました。
バーンと異常が実際にあったんですけれども、その異常の前、1時間おきにバーっと見ていると、ぴょこぴょことなにか起きているところがあるので、「これってなんなんだろうな？」と。「どのセンサーがそういう異常に寄与していたんだろう？」ということを見たりしています。
これって、やっていることはBIでやっていることと変わらないんですね。ただ、予測という軸を新しく持ってきたことによって、こういう分析ができるようになってきました。
リアルタイムでアプリケーションを監視していくには
先ほどHadoopのお話をしましたが、これである程度「いい結果が出るね」となってくると、たくさんある装置の全部でやってみようという話になってきます。
たくさんの装置でどんどん特徴量を抽出してバーっと（データが）出てくると、オラクルのデータベースでもぜんぜん耐えきれないということになってきますので、Hadoopを入れようということになります。
「B」と書いてあるのは弊社のHadoopのマシンなんですけれども、どんなマシンでもいいと思います。Hadoopにとりあえずドーンと入れておく。
そして、あとから必要なもの、例えば先ほど過去1週間だけを学習すると言いましたが、過去1週間の同じモデルの機器すべては一緒に学習しましょうとか、そういったことを考えるわけですね。それをアプリケーションのほうからいろいろ指定してデータを取ってくる。
先ほど申し上げているとおり、機械学習において精度に寄与してくるのは、アルゴリズムもさることながら、どういったデータを取ってきているかということも非常に重要です。ですので、その両方をここで考える必要があります。
「どういったコンポーネントがあって……」という話がデータベースとしては管理されていますので、そういったデータを取ってきて、一度こういうふうにモデルを作ります。
モデルを作ったら、確かにアプリケーションで見て、「いいモデルが作れたね」とか、「このアプリケーションを毎日監視していくことって大事だね」となるわけなんですけれども。工場とかになってしまうと、やはりこれをリアルタイムで見ていきたいということになりますので、この関数の部分、予測モデルをこちら側（Stream Analytics）に移してあげる。
この小さい子（Stream Analytics）がストリーミング処理をどんどんして、なにかあったらアラートをあげてくれるとか。そういったことを今後やっていくことになると思います。
こういう仕組みがオラクルの場合クラウドで提供されますが、これからはおそらくどこでもクラウドで提供されていくことでしょう。
工場の場合は、おそらくクラウドを使うメリットというのはあまりないかなと思います。おそらくクラウドに行って帰ってくるだけで100ミリsecかかるというレスポンスを期待していないでしょう。
ただ、やはり工場のデータもそうなんですけれども、クラウドにのせるということはインターネット上にのせるというメリットがありますから、例えば日本全国のたくさんの工場から集めてきたデータを一緒に解析したいということになってくると、こういうクラウドみたいなものを使うのは必然になるかなと思います。
これは1つ、工場の装置の音データから考えてみた事例です。
テロ対策に使えるアプリケーション
もう1つ、少し時間が押してきましたが、これは去年の9月か10月に「テロ対策特殊装備展」をビッグサイトでやっていた時に出展させていただいたものです。これもやはり「アプリケーションを作るのが必要だね」という話なので、ご紹介させていただきます。
今は過激な思想やテロの手法みたいなものがインターネットでどんどん拡散しやすくなってしまっています。そうすると、インターネットでいい思想、「こういうことは危険だから気をつけたほうがいいよ」みたいなものもある一方で、危険な思想のほうが広まるのが早くて。今はどちらかというと、そういう危険な思想のほうが勢力拡大しやすい。
これに対抗するために、「危険なことを言っている人たちはどういう人たちで、本当に危険なのかどうかを予測できたらいいね」というのがこのシナリオです。
おもしろいですね。今はもっと多いかもしれないですけど、1秒間で生み出されるソーシャルデータのコンテンツが2万。例えば過激派組織IS、これは縮小したと思いますけれども、関連のソーシャルデータだけで1日に9万ある。
なので、これをちゃんと絞り込みをして予測しないと、そもそも全部を見るなんてことはできないので、予測をして優先順位をつけてあげる。これは先ほどの保険の営業マンが「どの人から先に営業に行ったらいい」というのと基本的には発想は同じということになります。
ビデオがありますので、お見せしたいと思います。
（映像が流れる）
これは各種メディアのデータと言っているんですが、今回、Twitterなどでいくらかニュースのデータを集めました。もちろんオラクルに限らずいくつかのサービスでソーシャルデータを集めてきてくれるようなクラウドサービスがあるかと思います。
だいたいそういう時、全部集めると大変なので、ある程度フィルタリングして、例えば「爆弾」「テロが〇〇」と言っている人を集めてこよう、といったことをやりました。
それでもやはりすごい量のデータが出てきます。ツイートのデータなどは（量が）すごいので、一度Hadoopに入れています。これは、コンソールがいきなり出てきてしまって恐縮なんですけれども、左側がHadoopで、右側がデータベースを見ています。
HadoopでTwitterで「テロ」と言っている発言を全部見ようとすると、「爆弾」や「テロ」と言った人のツイートがわーっと出てきますね。
これを1回こちらでフィルタリングしてあげて、そのフィルタ条件をデータベースのほうから与えてあげて、フィルタリング自体はデータベースでやってあげる。データベースに全部持ってきてしまうと大変なので、ここでフィルタしてあげるということですね。
それをデータベースのSQLで書くと、そのSQLのWHERE句の条件がプッシュダウンされて、Hadoopのほうでフィルタされて、データベースのほうにデータが入ってきます。それをこれから分析に使ってみましょう。
要注意人物かどうかを判定
危険単語群をデータベースで管理していて、その危険単語がつぶやかれているツイートをデータベースに全部集めてきました。
どういうことかというと、「この人はこういう危険単語を何回つぶやいた」という感じで、集計するというところまでをHadoopでやっているという感じです。
見てみますと、さすがにアカウント名は全部消したんですけれども。例えばこの人はロシアの人でフォロワーがどれぐらいいて、みたいな話があります。
最後に要注意人物かどうかが「0」「1」で書いてあります。これはなにをしたかというと、僕らが1回1回見て、例えば「これは『爆弾、爆弾』と言っているけど、テレビゲームの話をしてるね」みたいなものは0にするということを手動でやります。結局、それをやらないとなかなか精度が上がらない。その人間のdecisionを今回は学習させてあげるというシナリオです。
今度、こちらはまだ見られていない人たちのアカウントなので、まだこの人たちは危険なことを言っているかどうかはわかりません。ただし、ここに予測確度90何パーセントというのが出てきているんですね。
これはなにかというと、こういう単語を何回言っている、こういう国の人は危険だ・危険じゃないということを1回学習して、分析官である私は、おそらくこの人を92パーセントの確率で危険人物とするだろうとシステム側からのサジェストをしてくれる。
このアプリケーションの上では、この人物を監視対象にするというボタンがあって。実際こういうふうにサジェストされたけれども、ツイート内容を見てみて、「危ないことを言ってるのかな？」というのを判断して「これはやっぱり監視しておきたいな」と。もしくはストーカーということもあるのかもしれないですけど。そうすると「監視対象にする」をクリックしておきます。
すると、先ほど営業マンが「契約」というところにチェックしたのと同じで、「この人は危険人物です」となる。なので、この人と同じような発言をしていたら、また学習して、同じような発言をしてる人がいたら危険人物だとサジェストしてくださいとやるわけですね。
つまり、たくさんずらずらと出ていた判定用データから、学習用データのところに移るということになります。そうやって「契約しました」とか「この人は危険人物だ」と言って、今日は100人分危険人物かどうかを判断したら仕事を終えて帰ろう、みたいな感じになるわけですね。
新しいデータにモデルを適用
そうすると、それを学習しなきゃいけないので、学習する先ほどのフローというのは、システムの上でバッチ処理みたいな感じで、夜間に学習させておいてあげるということになります。
ですので、お見せしますと、例えばこれですね。スケジュール機能みたいなものがこういうところにありますので、これでこのワークフロー自体を毎晩走るようにしておきます。
アプリで組み込むことを考えるとどうするかというと、先ほど作られたモデルがありましたが、モデルを新しいデータに対して適用してあげるということになります。
ですから、これは先ほどの保険のデータになってしまっていますけれども、このお客さんたちに対してもう1回保険のデータを持ってきたんですが、適用します。
この適用しますと言っているのは、ずっと戻りますが、（「作成されるモデルのイメージ」のスライドを指して）これをやるということですね。そのためには、このモデルをデータに対して適用します。これで実行することになります。
そうすると、今はまだ契約するかしないかわからない人たちに対して予測が与えられるわけですね。
予測したものは、「データの表示」で中身を見てみます。これも少し見にくいんですが、一番上の行は「結婚している人で、給料がいくらで」と書いてあります。ダーッと見ていくと、一番後ろのほうに、Support Vector Machineによると「この人は買わない確率が79パーセント」と書いてあるんですね。これが適用された結果です。
これは表で返ってきています。表で返ってきているのはなぜかというと、アプリケーションにしやすいからですね。表で返ってきたものを新しくデータベースの表として、ここに出力してあげます。これで実行すると、新しい表にこの結果が書き込まれることになります。このワークフローの処理をバッチ処理で毎晩やっておきます。
では、先ほどのようなタブレットのアプリケーションは、どこを見にいけばいいかというと、今書きこまれた表を見ればいい。毎朝それが更新されていて、アプリケーションがその確度も更新しているということになります。
例えばこれはSQLを1つ取ってきていますが、今、「YOSOKU_KEKKA」という表に吐き出しました。そこでCUSTOMER_ID「CU5511」の人のファーストネーム、ラストネーム、銀行預金、それから決定木とSupport Vector Machineでどういう予測をされたか、確率付きで出してくださいというのがこのSQLになります。非常に簡単なSQLです。
これを実行すると、アプリケーションはこの答えを得るということになります。GUNTER ORLANDOさんが2,900ドルの銀行預金があり、決定木によれば、「この人はまだ顧客になってくれていないけれども、69パーセントの確率でおそらく契約してくれるでしょう」と。Support Vector Machineで見てみても77パーセントです。
おそらくこの顧客を見るときに、自分の顧客かどうかをWHERE句に入れるかもしれませんし、そのWHERE句の中には、もうすでに買ってくれている人は除外したほうがいいので、Buy_Insurance、買ってくれているかどうかというところで「買ってくれていない人」と除外するかもしれません。そんな感じでアプリケーションを構築することになります。
予測アプリケーションを作ってみることでわかることは多い
（残りの講演時間が）3分ありますね。最後に1分だけ、グラフデータベースの話をしたかったんですが、時間がないので諦めます。このスライドは公開しますので、どこかで見ていただけたらと思います。
どういうことをやりたいかというと、機械学習で「この人は危険かもしれない」とか、一人ひとりの属性を見ながらその人の危険性を判断すること。それだけではなくて、インターネット上でこの人は危険な人と付き合っているか危険じゃないかとか。
例えば、私の娘が小学校で先生に「最近どうですか？」と言ったときに、「テストの点数を全部合計すると何点で、友達が何人だからどうです」という話ではないわけですよね。そうではなくて、どういう友達のグループにいるかとか、どういうテストで点を取っているかとかいうことが知りたい。
そういうことって、グラフ分析をしないとわからないですよね。ということを見ているところです。
それで、情報をすごく拡散させていて、しかも危ないことを言っている奴もいれば、危ないことを言っているけれどもぜんぜん周りが見向きもしなくてリツイートもしていないという人もいるわけですね。
では、「情報を拡散させていて危ないことを言っている人って本当にいるのかな」ということを、指標を持ってきて「この人って本当に情報を拡散させているのかな？」「どういう人がいるのかな？」ということをグラフィカルに見て分析するというものを、今作っています。
この人（黄色い円）が情報を拡散している人で、危ない発言をした人の情報をリツイートするんですよ。
こんなものをこの人の指標として持ってこようとすると、機械学習以上のものが必要になってしまいます。なので、機械学習とグラフ分析みたいなものを合わせてアプリケーションを作っていくということに私たちは今取り組んでいます。
ということで、最後にまとめに入りますが、機械学習を活用するために、今すぐ予測アプリケーションを作ってみましょう、というのが私の提案です。
というのは、アプリケーションを作ってみることでわかることは多いからです。しかもアプリケーションが作られれば、それを使う人によって、より多くの学習データやフィードバックが集まってきます。
もう1点、データが大きかったとき。この場合は、データを持ち出さないで予測モデルをシステムに組み込みましょう、と。「データ分析できます。データサイエンティストです」という方がデータ・サイエンティスト・アイランドに行ってしまわないように、ちゃんとシステムに組み込むということをやっていけたらなと思います。
それから、少しHadoopの話をさせていただきましたが、今後データが増えるのは確実ですから、このHadoopとデータベースを効果的に組み合わせて使っていくということを検討いただければと思います。私たちもやっていきたいと思っているところです。
最後に補足情報なんですが、私のTwitterでもこのリンクを貼り付けましたので、ここから見ていただくのが早いかもしれません。もしくはGitHubで「oracle4engineer」というところに行っていただくと、「機械学習やグラフ分析、Oracleだったら超高速ですよ」ということをいろいろ書かせていただきました。
このグラフ分析の勉強会は、Oracleのカフェで無料でやっていますので、ぜひこちらにもお越しいただければと思います。以上になります。どうもありがとうございました。
（会場拍手）
