はじめに
はじめまして。 プラットフォームサービス本部 データプラットフォームサービス部門の森分です。
もともと私は、NTT Comのクラウドサービスをベースにした法人向けソリューションの個社別運用やインフラ関連のプロジェクトマネージャ業務を担当しておりました。 最近はSmart Data Platform（以下、SDPF）アーキテクトなる、お客様課題の解決やNTT Comのビジネスの中でSDPFの活用を推進する部隊に参画しています。
データ利活用を支えるSDPFのアーキテクトがデータ利活用に詳しくなければ立つ瀬がありません。 そうならないように日々研鑽を積んでいるわけですが、その中で作ったTwitter分析システムっぽいもののご紹介が本稿の趣旨となります。
本来のデータ利活用プロジェクトでは、課題および仮説をまず明確にして、それに応じたデータ解析を進めていくのですが、本稿では堅苦しいものは全部すっとばしたゆるい雰囲気でお送りします。
きっかけ
私の所属するチームは、某自治体のお客様と地域活性化のためデータ利活用するプロジェクトに参画しています。 そのノウハウをもっと広く遍く、特に中小規模の自治体向けにデータ利活用サービスとして提供できないか検討する営みがありました。
その中で、お客様が住民の思っていることをアクティブに汲み取る（更には分析する）手段がないか…と考えたときにTwitterを分析してみてはとのインスタントアイディアがきっかけです。
…というのは後付けで、リアルタイムで情報が追加されているデータを可視化できたらかっこいいんじゃんとの思いで手を動かし始めました。 実際のデータ活用基盤でもデータ更新などの運用が問題になってくることが多いので、リアルタイム更新の事例を作りにいきました。
やりたいこと
自治体の担当者様が使うことを妄想すると以下の要件がまずありそうです。
- 対象の自治体エリア付近で情報を絞り込めること
- 住民がどんなことをつぶやいているかの傾向が手間を掛けずにわかること
まずは1.をかなえるため、位置情報が付属しているツイートを分析の対象としました。
Twitterでは、本文の内容から類推する以外だと、位置情報くらいしか地方自治体に紐づける属性がなさそうだったためです。
全体ツイートから見ると位置情報をもつツイートはかなり限られますが、そこそこあるだろうとのなかば見切り発車しました。
2.については、ワードクラウドを使って、頻出しているワードを可視化し、ツイートの全体傾向をざっくり掴みに行く方針としました。
つくってみた
3分クッキング方式となり恐縮ですが、某自治体のお客様の取り組みの中で、Tableauで参照できるデータベース(PostgreSQL)を構築した検証環境があり、そちらを間借りさせていただきます。
可視化については、BIに特化したデータ視覚化ツールであるTableauのおかげで盤石なので、どれだけちゃんとしたデータを準備できるかが勝負です。 簡単ですが、システム概要図です。
やっていること
- Twitter Developerアカウントは無料アカウントを使用
- プログラム実行環境は踏み台サーバ(CentOS)にPython環境を作って実装
- ツイート取得はTwitterAPIでのTwitter操作を簡単に実装できるPythonライブラリであるtweepyのStreamListenerをベースに改造
- 取得するツイートは緯度経度でフィルター。日本を覆うくらいの
適用に広めで設定。 - ツイートから必要な情報を掻い摘んで、DataFrameに放り込んでいく
- DataFrameをPostgreSQLのtweetテーブルに放り込む
- ツイート取得スクリプトは5分毎にcronで起動させ、エラー耐性を無理やり上げる
- ワードクラウドのためのワードデータはtweetテーブルのデータを形態素解析して、Wordテーブルに放り込む
- 形態素分析はmecabを使って、名詞のみを抽出
- 形態素分析は、1時間に1回、毎時10分に前の1時間分をまとめて処理
- ワードクラウドはTableau内の表現で完結するので、追加で実装する必要なし（すばらしい）
ちゃんとツイート取得できるか
ちゃんとツイート取得できているか可視化してみます。
1時間ごとに1,000件～15,000件くらいの幅でツイート取得ができています。 深夜帯はがっつりツイートが減りますがそれでも1,000件程度あります。 位置情報をもったツイートはほとんどなかったなんてオチにならなくてよかったです。
Tableauの更新ボタン押下は必要ですが、ツイート取得のリアルタイム性も問題なさそうです。
形態素分析できてるか
次に、形態素分析して生成される名詞数を可視化してみます。
1時間当たりに5,000語～85,000語くらいが生成されている感じです。 波形がツイート数とほぼ一致していて、だいたい1ツイートあたり平均7語くらい生成されてます。
ツイートをマッピングしてみる
位置情報をもとに、Tableauに地図マッピングしてもらいましょう。
日本を覆いつくす一面のツイート。
ついでに韓国も覆いつくしてますね。中国や北朝鮮にマッピングがないのはお国柄でしょうか。
たまに、指定エリア外のデータが出現していますが、これはStreaming apiのバグということで異常値扱いとします。
ワードクラウドしてみる
次にワードクラウドを作ってみましょう。さっきのツイートマッピングに重ね合わせて配置してみます。
密度が高く見づらいですが、形にはなってます。 頻出のワードもちゃんと大きく表示されています。
位置フィルターを導入してみる
基本機能的なものは実装できたので、地域ごとにフィルターできる機能を追加します。
「指定位置」と「指定距離」のパラメータを作成して、特定位置から半径〇kmを対象にしたツイートのみをフィルターする機能を実装します。 「指定位置」は手動入力でもいいですが操作性が悪くなるので、ツイートのマークをクリックしたら自動指定されるようにしてみました。 青マークが「指定位置」のツイート、オレンジマークが「指定距離」内のツイートになります。 それに合わせてワードクラウドの対象ツイートも同期させてみました。
また、ワードクラウドの表示密度の調整として、表示させるワードの最低出現数を閾値として設定できるようにしました。 千代田区あたりを「指定位置」にして、半径50kmを対象に絞ってみました。 3月31日夜は地震が発生していたので、その傾向も見えてます。
ついでに、ワードクラウドのワードをクリックすればツイートマッピング側もそのワードを含むものでフィルターできるようにしてみます。 これで具体的なツイートを追いかけるのが楽になりました。
各地方の傾向を見てみる
これまでは例として関東周辺のものを参照してきましたが、各地方の傾向を見ていきます。
札幌近郊
まずは札幌近郊から。
地名が頻出するのはどこにも同じ傾向があるようです。（位置情報ありのツイートのためでしょう）
この日は日ハムがシーズン初勝利したのでその様子も反映されてます。
仙台近郊
次に仙台近郊。 関東と同様に地震の影響をうけたのがほのかに分かります。
東海エリア
愛知や静岡をメインに東海エリアを見てみます。 桜前線的にこのエリアが満開なのかなと想像できます。 この日は関東と関西で地震が起こったので、間に挟まれた東海でも地震ワードが目立ってます。
関西エリア
大阪、兵庫、京都を中心に。
関西でも地震が発生していたため、やはり地震傾向が強いです。
関東と比較すると時事関連ワードが見えるのは地域柄でしょうか。
中四国エリア
広島を中心に中四国を対象に。 かなりエリアを広げたからか地名系が多いです。
カープが開幕戦絶好調でしたので広島近郊でカープの話題が多く、その傾向も少し見えます。
九州エリア
そろそろ見飽きてませんでしょうか。あと少しです。お付き合い願います。
熊本を中心に、九州7県をすっぽり対象にしました。 九州エリアも地名系が多いですが、BTSが見えているのは韓国と近いからでしょうか。
沖縄近郊
一気に傾向が変わります。沖縄近郊です。
軍事機の飛行情報をトラッキングしているMilitary Aircraft Spotterというアカウントが、嘉手納基地の情報を頻繁につぶやいているのが影響を出しているようです。
沖縄エリアのツイート数自体が少ないこともあり、頻繁につぶやいているアカウントの影響が大きくなってしまいます。
日本は笑顔で溢れている
ここまで読んでくれた皆様、どうもありがとうございます。
各地方のワードクラウドを通しで眺めてみると、多くの地方で「笑顔」のワードが出現しています。
これはこの記事を読んで切る皆様、ひいては日本国民が毎日を笑顔で過ごしているいるからに他なりません。
そんな素敵な国、日本に産まれてよかったなぁと感じます。
お付き合い頂きまして、ありがとうございました。
そんなことはない
わかってます。そこまで日常に笑顔があふれていないことは。調べてみましょう。
「笑顔」のワードでツイートをフィルターしてマッピングしてみます。 純粋にツイート本文に「笑顔」が入っているものはこれだけしかないため、何かしら別要因で笑顔が増殖しているはずです。
笑顔はたしかにそこにあった
辿っていくと、笑顔を吐き出しているツイート文は以下のようなものが多い傾向にありました。（下記は創作した例文です）
このツイート文に対するMecabの形態素解析の結果から名詞の出力を見てみましょう。
いました「笑顔」。
笑った絵文字が笑顔を量産していたようです。
あわせて、英語の半角全角やURL情報、具体的な数値など、傾向把握の文脈上必要ない部分を前処理する必要がありそうです。
余談となりますが、"鬼滅の刃"を判断してくれるMecab、 もといmecab-ipadic-neologdは時流をとらえておりとても便利です。
ipadicはIPAが提唱した「IPA品詞体系(THiMCO97)」に基づいて作成されたデータの辞書なのですが、すでに更新が止まっています。
そこでipadicをベースにして、様々なデータベースをクロールして自動更新されているのが今回使用したmecab-ipadic-neologd。ありがたいです。（最近はこちらも更新がとまっているようで、2020年連載開始の"海が走るエンドロール"は判別できていません。）
さよなら笑顔
ということで、文整形の前処理をいれ、この日を境に日本中から架空の笑顔が消えたのでした。 めでたし めでたし。
さいごに
大変長くなってしまいましたが、ご覧いただきましてありがとうございました。
本稿はもともと社内ブログとして公開した内容を、本ブログ用に加筆修正したものとなります。
ソースコード記載が皆無だったり、ストーリーがゆるかったりしておりますが、ご容赦頂けますと幸いです。
SDPFアーキテクトではお客様の課題解決やNTT Comビジネスの中でSDPF活用を推進しています。
ただ、SDPFアーキテクトはSDPF専任の導入コンサルのポジションは取っていません。 SDPF以外の商材でも課題解決に必要なものは導入し、時には自分たちで検証しながら、課題解決のサポートやNTT Comのサービスへのフィードバックするなど幅広い活動をしています。
自由度の高いミッションですし、データ利活用の道をひた走ってきた人材や膨大なSDPFの商材を知り尽くした人材ばかりではありません。 それでもこの大きい会社を次のステージのために変わっていくぞ、変えていくぞと、切磋琢磨しながら前に進めるそんな良き雰囲気がNTT Comにはあると思っています。
【余談】振り返りとSDPF
データ連携がつらい
今回はPoCレベルでしたので、各システムのデータ連携部分は力業で手組みしました。 ところが、データ型の整合性を取ったり、渡し方の設計でもトライアンドエラーがあり、この規模でも結構苦労しました。 （最終的に、細かい部分はPandasに丸め込んでもらっちゃいました）
運用を考えた場合、ある程度の頻度のColumn追加やデータ仕様変更を想定するとELTやデータ仮想化などを入れて管理していかないと、運用稼働が跳ね上がり、開発に支障をきたしてしまうのではと感じました。
そんな要望を叶えるサービスがSDPFにはありますので紹介させてください。
コードを修正、動作確認、DBの中身を確認するサイクルを何度も繰り返しながら進めていた作業が、GUI上でサクっとできてしまいます。
1日かかった作業が30分で終わる感覚になれたので、ROIが高いのではないでしょうか。
データ統合インフォマティカ ソリューション
複数システムにまたがるデータを統合管理
https://www.ntt.com/business/services/data-utilization/dxplatform/sdpf/informatica.html
https://sdpf.ntt.com/services/informatica/
データ仮想化 TIBCO Data Virtualization
複数のデータを複製することなくリアルタイムで統合。一元的なデータアクセスを可能に
https://sdpf.ntt.com/services/tdv/
データ可視化は楽だった
逆にデータ可視化については、Tableauを使用したので地図へのマッピングや、ワードクラウド作成などの作成稼働は本当に短かったです。 これをたとえばエクセルでやれなどとなったら太刀打ちできないでしょう。リアルタイムなんて夢の夢になってしまいそうです。 データ可視化サービスとして、TIBCO SpotfireをSDPFでは提供しています。
BI/BAツール TIBCO Spotfire
直感的な操作でデータを可視化し、探索的な分析を可能にするBI/BAツール
https://www.ntt.com/business/services/data-utilization/dxplatform/sdpf/tibco.html
https://sdpf.ntt.com/services/spotfire/