概要
英ガーディアン社は、ウェブ版の記事に寄せられた大量のコメントを計算機により解析し、コメントによるハラスメントの傾向を分析した。同社はそれに用いた技術的側面も公開したため、その詳細について検討した。このようなデータ分析は報道の現場でも今後重要度を増し、プロセスの透明性や解析の再現性といった、科学論文執筆関わる諸問題に類似した課題に直面すると予想される。それらの解決に利用可能な技術についても検討した。
はじめに
CMSの普及以後、個人ブログに限らず、コメント欄を開放している大手メディアのウェブサイトもよく見かけます。大手の場合、管理者があまりにひどい罵詈雑言などは各社の規定に基づきブロックしますが、そうでないものは基本的には掲載されます。大手になればなるほどサイトを訪れる人も増え、このモデレーションの作業が大変になるため、労力に対して吊り合わないと言う理由でコメント欄を閉じてしまうサイトも多いです。しかしイギリスの老舗メディアの一つであるガーディアン紙は、それでもなお読者からのフィードバックはジャーナリストにとっても重要だと信じ、今でもコメント欄を開放しています。90年代末から書き込まれてきたコメントの総数は、今では7,000万件を超える膨大なものとなっています。
このコメント欄の価値に関して一石を投じる分析が、ガーディアン紙自身によって行われました。この分析がなかなか興味深かったのでここで背景も含めて紹介します。
記事の背景
殆どの方が体感的におわかりだと思いますが、利用者の多いサイトのあらゆるコメント欄というものはいずれ荒れるものです。これは世界共通の現象です。そこで一定の秩序を保つためには、ある程度のモデレーションが必要です。分かりやすい罵詈雑言などは機械的なフィルタリング（正規表現によるNGワードのマッチング）で可能ですが、ヘイトスピーチなどをこの手法だけで取り除くのは困難です。なぜならば、言葉遣いは非常に丁寧でも相手を罵倒したり差別したりすることは可能だからです。例えば、
「人種Xに属する人々は大変知能が低く、現代的な文明というものを持っていないのです。彼らを力で支配し、正しく導くのは我々の責務だと思われます」
と言う文は完全にヘイトスピーチですが、いわゆる放送禁止用語や分かりやすい罵倒語、わいせつな言葉などを含まないため、シンプルな機械的フィルタリングで取り除くのは困難です。そういった理由もあって、コメントのブロックや削除は未だに人間のモデレータによって行われています。
しかしこのうんざりするような長年の手作業の副産物として、彼らは一つの巨大なデータセットを生み出しました。すなわち、人の手によって分類された膨大な数のコメントです。ガーディアン紙では、モデレータにより不適切なコメントを、ガイドラインに沿ってブロック、もしくは削除しています。
このように人がコメントの内容に沿って掲載するかブロックするかを決めているのですが、ブロックされたコメントもデータベースには記録として残っています。7,000万のコメントのうち、およそ2%に当たる140万件のコメントが不適切なものとして分類されたそうです。多くは攻撃的で不適切な内容だったそうですが、これには脱線しすぎたコメント、いわゆるオフ・トピックなものも含まれています。つまり、彼らは人の手で分類された膨大な量の「攻撃的なもの/そうで無いもの」と仕分けされたコメントのデータベースを持っているのです。
この記事からはブロックされたコメントのリアルタイム表示が見られる (上のスクリーンショットは4/13/2016 7:05PM PSTに取られたもの)
ガーディアン紙の解析チームは一つの仮説を立て、それをこの長年蓄積されたデータを使って定量的に検証してみることにしました。その仮説は以下のものです:
Articles written by women attract more abuse and dismissive trolling than those written by men, regardless of what the article is about.
女性によって書かれた記事は、その内容に関わらず、嫌がらせや軽蔑的な煽りの対象になりやすい
つまり女性によって書かれた記事は、女性が書いたという理由だけで軽んじられたり、おかしな人をひきつけやすいと言う仮説です。これはしばしば言われてきたことですが、定量的に大規模なデータから分析した例はあまりないと思います。そこで彼らは実際にやってみることにしました。
なぜジェンダーに関する仮説なのか？
これは割とシンプルな理由で、仮説としてわかりやすいのと、データの分類時に真偽の二値で扱えるために解析が行いやすかったからだと思います。他の性的マイノリティーや人種に関する属性をメインにすると、よりデータの自動分類が難しいという理由もあったと思います（後述）。
解析の結果
はたして、その結果はうんざりするものでした:
The 10 regular writers who got the most abuse were eight women (four white and four non-white) and two black men. Two of the women and one of the men were gay. And of the eight women in the "top 10", one was Muslim and one Jewish.
And the 10 regular writers who got the least abuse? All men.
定期的に記事を執筆している記者のうち、最も多くの嫌がらせを受けた10人の内訳は、8人が女性で2人が黒人男性だった。そのうち2人の女性と1人の男性はゲイだった。その「トップテン」の８人の女性うち、1人はムスリムで、1人はユダヤ人だった。
そして最も嫌がらせを受けた回数が少なかった10人は、全員男性だった。
この結果を導き出したのは、計算機によるデータ解析でした。解析結果についても思うところはあるのですが、ここでは技術的な部分についてのみ注目してみます。実はこの記事に合わせて、解析チームの方がこの解析に使った手法についてかなり詳細に書いています:
対象とする読者
本稿ではこの記事に書いてある手法を、技術者ではない方に向けて解説してみます。ですからプログラマの方などが読まれると冗長に感じられるかと思いますが、そこはご勘弁を。専門家向けの記事と、「データ解析」という言葉が事実上「魔法」と同義語で使われている全く技術に触れない記事はたくさんあるのですが、その中間が埋まっていないように感じていたというのが執筆の動機の一つです。実例の解説は、その「魔法」にかかった靄を取り除き、実際の作業がどのくらい地味なものかを明らかにすることができると思います。
元の記事では、結果を可視化したものが見られる (© The Guardian)
なお結果の詳細は、D3.jsを使ったインタラクティブなチャートとして元記事に掲載されていますので是非ご覧になってみてください。「ジャズや競馬[注]の話題に関しては穏やかなコメントが比較的多いが、フェミニズムやパレスチナ問題のコメント欄はかなり荒れる」と言う、どこかで聞いたような話だな...と思わず苦笑してしまうような事実がデータに基づき図表で解説されています。実際の嫌がらせの内容にも触れていますので、読んでいてあまり気持ちのいいものではない部分もありますが、「誰でも自由に発信できる世界」に対して記者の方々が払っているコストの生々しい実態が読めます。
[注]: イギリスの記事ですから、日本の競馬とは雰囲気や意味合いがかなり異なるので、そこは注意して読んでください 。
仮説検証のための技術
今回の分析では、複雑な統計解析は行われていません。最終的に得られたデータを可視化して、それを使って仮説が正しいかどうかざっと眺めるような作業になっています。基本的な流れとしては、手元にあるデータに欠けている情報を追加し、複数のデータセットを統合し、フィルタリングし、ブラウザ上で可視化するというものです。これは可視化を伴う分析を行う場合の最も基本的な作業です。ただし今回は比較的大きなデータを使っていますので、一部は商用クラウドサービス上でSpark（後述）を利用しています。ここからは実際に使われたデータやツール、手法について詳しくみていきます。
可視化を目的にする場合の典型的な作業の流れ。基本的に、大量のデータを人間が把握できる大きさまで「濃縮」する作業と言い換えることができる。
使われた技術
今回使われたツールは、データ分析を業務として行っている方々にはおなじみのものばかりです。例を挙げると:
・テキスト処理のためのPerlスクリプト
・Amazon Web Service (S3, Redshift, EMR)
・Apache Spark
・PostgreSQL
・D3.js
・HTML5
などです。これらのツールは以下のように分類できます。
・データを蓄積して検索可能にする技術: PostgreSQL, S3, Redshift
・データを加工するプログラム: Perlスクリプト
・大規模なデータを複数の計算機で処理する技術: Spark
・それらを実行するための環境を提供する技術: AWS全般, EMR
・最終的なユーザー（今回のケースでは読者）がデータをわかりやすく見られるようにする技術: D3.js, HTML5
これらが実際にはどう使われたのかは後ほど見ていきます。
データセット
今回解析の対象となったコメントデータは以下のような特徴を持ちます:
コメントデータベース
・1/4/1999 ~ 3/2/2016の間にガーディアン紙のサイトにて書き込まれたコメント。ソーシャルメディアなどでの記事への言及は含まない
・コメント総数7,000万件
・うち22,000件が2006年以前に書き込まれた。つまりほとんどがそれ以降のもの
・コメント欄は通常三日間オープンとなり、その間に読者が書き込める。それ以後は読むことのみ可能。したがって、ニュースに対する比較的初期のレスポンスがコメントとして集まる
・コメントは、モデレータにより「ブロックされたもの」と「通常のコメント」に分類されている
・実際のデータはPostgreSQLデータベースに格納
・解析にあたり、実際に新聞社のサイトで使われているデータベースをコピーしてAWS上にアップロード
ブロックと削除の違い
記事がサイトに表示されない場合、それはガイドラインに沿ってブロックされたか、削除されたのかどちらかとなります。今回の解析では、データとしては残っているが、内容がガイドライン違反なので非表示とされたコメント、すなわちブロックされたコメントをその記事に対する煽り・嫌がらせとしてカウントしています。
逆にデータに残っていない（したがって今回利用されていない）削除の対象となったコメントは「ブロックされたコメントへの返信」「単純なスパム」となっています。
記事のデータベース
コメントは記事に対して書き込まれます。したがって、記事が誰によって書かれたのか、どのような内容だったのかということを合わせて解析するためには記事のデータベースが必要です。ガーディアン社の記事データベースは以下のようなものです:
・オンライン版の記事総数はおよそ200万
・Amazon Web ServiceのRedshiftに格納
・このデータベースは公開APIに接続されていて、外部の人もプログラムから検索をかけることが可能
Amazon Web Serviceとは何か？
またここでもAmazonが出てきました。最近のプログラマは空気のように使っている技術ですが、それ以外の人にとっては「なんで通販会社が新聞社のデータ解析に関係あるの？」ということになりかねないので、ここで簡単に説明しておきます。
Amazonは本の通信販売の会社として始まりましたが、成長の過程で、その大量のオーダーを裁くために無数のサーバーを含む巨大なシステムを構築しました。そこを維持するためには、ハードウェア・ソフトウェア両面の様々なノウハウが必要なのですが、先見の明のあったAmazon社の社長は、そのノウハウをベースに構築された高度な計算機システムを、外部の人に時間貸しという形で提供するビジネスを思いつきました。それがAmazon Web Service (AWS)と呼ばれるサービスです。これを解説し始めると本1冊以上の分量になってしまうので詳細は割愛しますが、企業はこれを利用することにより、自社内にサーバーを持って、データベースを構築して、バックアップを取って、電源を適切に管理して...という作業を外部化することができます。しかもありとあらゆるものが仮想化という技術をベースに抽象化されていますので、まるでソフトウェアを実行するように新しいサーバーを構築し、それをいらなくなったらコマンド一つで捨てる、ということが行えます。いわゆるビッグデータ（私はこの言葉の定義が非常に曖昧であるため、あまり好きではありませんが...）を解析するような場合、必要な量だけのストレージ、つまりデータの置き場を用意し、必要な数だけの計算機を時間単位で借りて一気に解析する、ということが可能です。
このような「時間貸し計算機」のサービスは、現在の大量のデータを生み出す社会の中で重要な役割を果たしています。AWSやその他の大手クラウドコンピューティングサービスは世界中のあらゆる企業によって使われています。また企業ばかりではなく、私の職場のような非営利の研究機関でもこのサービスは利用されています。大量の塩基配列情報を処理するのに、安い時間帯（AWSは、時間によって値段の変動するオークション形式も採用しています）に一気に多数の計算機を借りて解析を実行する、というようなことも始まっています。
ガーディアン社でのAWSの利用
ここでガーディアン社の使っているAmazon Redshiftと呼ばれるサービスは、いわゆるデータウェアハウスを外部に構築する際に使われるものです。新聞社にとって命とも言える記事のデータを全てここに格納し、解析や検索が行える状態になっています。社内の解析チームが直接使っているものとは異なると思いますが、この記事データベースは一般の方にも開放されています。英語ですが使い方も書いてありますので、興味のある方は遊んでみてはどうでしょう。ちょっと試すだけなら、ブラウザからもアクセスできます。
このデータベースに対して適切な検索条件を送信することにより、著者のデータも得ることができます。今回は「最低2回はガーディアン紙上に記事を書いたことのある人」という条件で著者名のリストを得ました。その総計はおよそ12,000人でした。しかしここで問題が一つあります。今回の仮説は男女の差に関わるものなのに、著者の性別はデータベースには存在しないのです。この問題を彼らはどう解決したのでしょうか？
著者の性別の判定
今回、最終的に検証したい仮説が性別に基づくバイアスなので、著者の性別がわかっていないとどうにもなりません。この問題を解決するために彼らが行ったのは、ある意味とても原始的な作業でした。しかし技術的には高度でないにもかかわらず、この類の作業というのがデータ解析を行うときに最も面倒で時間のかかる作業であるケースも非常に多いです。つまり、一定のエラーを含みながらも必要な結果を得られる程度には正確な、形成されたデータを作るという作業です。
名前から性別を判定するワークフロー （Cytoscape 3.3にて作成）
今回の具体的な作業は上の図のようになります。まず12,000人の著者名を、無償で公開されている男女別の人名リストと比較するスクリプトを実行します。おそらくここではファーストネームの完全一致による単純な判別を行っていると思われます。これにより、11,098人分のデータが男女別に分類され、1,268人が性別不明として残りました。性別不明になる原因は色々と考えられるのですが、そもそも名前がリストにない場合はわかりませんし、名前の英語表記の揺れなども原因になります。例えば、下のスクリーンショットは今回使われた名前のリストからの抜粋ですが、日本人名の「ケンイチ」という名前は、正しく男性名に分類されていますが、表記がKEN'ICHIであるため、KENICHIという表記との単純一致だと取りこぼしてしまいます。このような名前や住所といったものの表記ゆれは厄介な問題で、バラバラにデータベース化された情報を統合する時に様々な問題を引き起こします。
names.csv. KENという語で検索をかけた例
さて、この時点で不明の1,268人分のデータの性別を判定するために、今度は以下の人名判定サービスにPerlスクリプト（この場合は、Perlというプログラミング言語で作業工程を記述した小さなプログラムのことです）で送信します:
・genderize.io: Determine the gender of a first name
このサービスを利用した後の時点で何名ぐらいが性別不明だったかはわかりませんが、なんとか人力で判定、つまり人名辞典やネット検索で人間が一つ一つ判定するのも不可能ではない程度の量にまで不明の数が減っていたので、残りは実際にそういう作業で仕分けされています。「データサイエンス」という言葉の響きとは対極にあるような作業ですが、現実はこんなものです。
ともあれ、この作業で一定のエラーは含まれているが、それなりに大きい数の男女別著者リストが得られたので、そのファイル(CSV)をAWSのS3というストレージサービスにアップロードしました。ここからはAWS上の計算機での作業になります。
Sparkでの分析
ガーディアン社はかねてより、こういった比較的大きなデータを分析することによる調査報道をやりたかったらしく、大規模な分散処理ではスタンダードな地位にあるApache Sparkを実際に使うプロジェクトを探していました。今回の解析はテストケースとして丁度良いものだったため、実際に利用しています。
Sparkとは何か？
Apache Sparkとはオープンソースで開発が続いている「並列分散処理のためのフレームワーク」です。これだけでは一体なんなのか分かりにくいと思いますが、要するに複数の計算機を利用して、巨大なデータを効率よく同時に処理するためのソフトウェアのことです。今日のデータ分析で巨大なデータを扱う時に高性能な計算機が必要な場合、一台の高性能なマシンに大きな投資をして使うことは稀で、基本的には比較的安価な計算機をたくさん集めて処理を分散させて行います。この作業を行う時には、一台の計算機で処理を行う際に比べてはるかに高度な技術が必要になります。この複雑な部分の面倒を見てくれるソフトウェアと考えてもらって概ね問題ないです。
若干技術寄りの話になりますが、かつてこのソフトウェアを使う時にはScalaという言語でRDDと呼ばれる比較的抽象度の低いデータ構造を使う必要があったのですが、最近ではRとDataFrame（スプレッドシートのシートのような感覚で各種データを扱えるデータ構造）という、データ解析を行う人々には馴染み深い、かなり抽象度の高いものを利用できるようになってきました。現時点でもScalaを使える人がもっともこのソフトウェアを効率よく使いこなすことができますが、そうでない人にも今後は門戸を開いていくという方針のようなので、大規模データ分析の世界ではSparkのさらなる普及が予想されます。
クラウド上での実行
このSpark、素晴らしいソフトウェアなのですが、実際に複数の計算機を利用して解析したい場合は、そのセットアップにそれなりの時間がかかります。また、Sparkのノード（分散させた作業を実行させる計算機）として使える大量の計算機を自前で用意するのは、（規模にもよりますが）コストも膨大なものになります。こういった時に便利なのがAWSのような商用クラウドサービスです。AWSにはAmazon Elastic MapReduceという、Sparkのようなソフトウェアを実行できるように設定された計算機群（クラスタと呼ばれます）を時間貸ししてくれるサービスがあります。ガーディアン社は今回このサービスを利用し、Sparkを使った解析をEMR上で実行しました。まるでAmazonの回し者のようですが、現実的な問題として、ここまでバラエティに富んだクラウドサービスをワンストップで提供している企業はAmazonをおいて他に無く、それが企業からマスコミ、研究機関まで幅広いユーザーを獲得するのに成功した理由だと思います。
さて、実際のタスクですが、今回は、AWS上にアップロードされたコメントデータベース、記事データベース、著者のデータに対し、ひたすらクエリを投げて必要な情報を切り出し、どの著者がもっとも多くの誹謗抽象・煽りコメントを受け取っているのかを集計していきました。このような大量のデータに対する比較的単純な作業の繰り返しはSparkの得意とするところで、テストプロジェクトとしては良い選択なのではないかと思います。実際に今回の作業は、パイロットプロジェクトというか、まだ彼らに取っても初の実験だったため、ソースコードにも試行錯誤のなごりが見て取れます。こうして得られた結果は、同じくAWSのS3上に書き出されていきました。この最終的な結果は、スプレッドシートなどで集計・図表化可能な程度の大きさのものだと考えて良さそうです。
また現在ガーディアン社のデータ解析チームは、将来的にこのような解析がより行いやすくなるようにPrestoと呼ばれるFacebook社を中心に開発されているオープンソース・ソフトウェアを使い、いわゆるデータレイク（これもバズワードに属するものだとは思いますが...）を構築しているようです。ここからも、彼らが自社で蓄積してきたデータに対する計算機による解析を、今後も進めていこうという姿勢が読み取れます。
データの可視化
これで必要なデータは出揃いました。今回は最終的には新聞記事として使うものですから、このデータを読者が分かりやすい形で提示する必要があります。最近はウェブ版の記事を念頭に作られることも多く、今回の記事も文章に加えて、実際に嫌がらせコメントを多く書き込まれた記者へのインタビュービデオなど、様々なメディアを組み合わせたものとなっています。そして最近の傾向として、こういったデータを見せるときに、ブラウザベースの可視化を用いることが多くなってきました。つまり、最新のウェブ・ブラウザに備わった高度な描画機能を用いて、複雑な図表の作成や、アニメーション、双方向性のある表現などが可能となり、これらを報道の場面で使おうという動きです。
このトピックに関しては、私も仕事として関わっていますので、何か面白そうな記事に出会ったときに、改めて独立した文章として書いてみたいと思います。少々技術的になりますが、実際の可視化の作業などに興味がある方は、こちらの記事もどうぞ。
今回の場合、こういった表現を行う場合に使うツールとしてスタンダードなD3.jsを利用し、最終的な集計結果をプロットし、アニメーション表現を使ってスライドのように繋ぐということをしています。比較的控えめな使い方ですが、今回の結果を見せるためには十分だと思います。ぜひ元の記事のプロットをご覧になってみてください。
考察
今回の解説記事を読んでいて既視感を覚えたのですが、その原因は、要するにこれは学術論文における実験プロトコルの簡易版のようなものだからです。査読付きのジャーナルに掲載されるようなものに比べればはるかに簡易的なもので、これを読んだからといって必ずしも同じ手法で同じ解析ができるわけではありません。しかし、このようなものが調査報道の記事と共に掲載されるようになったのは大きな進歩だと思います。特に計算機を使った解析の場合、その対象が公開データセットの時は、ソースコードと解析に使った環境を公開しておけば、ほぼ同じ解析が技術さえあれば誰でも行えます。事実、先進的な取り組みをしている海外の一部マスコミでは、記事執筆に使ったコードをGitHubにて公開する動きも出てきています。
欧米メディアのGitHubレポジトリ
・The Guardian
・The New York Times
・ProPublica
・ICIJ
・Los Angeles Times
調査報道と再現性
科学の世界では当たり前なのですが、ジャーナリズムの世界でも、このようなデータ解析を使った報道というものの出現に伴い、そのプロセスの透明性と再現性といった点が話題になっています。英語ですが、興味のある方はこのあたりの記事を読んでみてください。
・The Need for Openness in Data Journalism
・The Rise of Transparent Data Journalism
解析の再現性には幾つかのレベルがあります:
１．機械可読な形でのデータの公開
２．解析に使った手法とそのソースコードの公開
３．解析に使った環境の公開
1はともかく、2と3はかつては技術的になかなか難しい面もありました。しかし、現在では公開されたソースコードの事実上の標準レポジトリであるGitHubがありますし、解析の規模にもよりますが、解析環境をコンテナ技術（Dockerというソフトウェアがもっとも普及しています）を用いて第三者が再現可能な形で残すこともできます。このように、技術的に解決出来る面も増えてきていますので、調査報道の分野を中心に、今後はこういった方向を目指すメディアも増えるのではないかと思います。
また、こういった話題で必ずと言っていいほど出てくるJupyter Notebookというツールですが、これは人間のための文章や図表と、計算機で実行できるコードを混在させて、実際にそれを実行しながら動作を確認できるという非常に強力なツールです。報道では、解析に使ったコードを読者に実際に手元のマシンで実行させながら読んでもらうということが可能になります。これについてもいずれ最近の傾向をまとめたいと思いますが、使うこと自体は決して難しくないので、少しでもプログラミングのできる方はぜひ試してみてください。
余談: 日本のメディアの方へのささやかな要望
GitHubにウェブ版の紙面で使ったコードを公開することで問題が発生するケースはまず無いと思います。報道機関のパフォーマンスはあくまでその内容で競われるべきものなので、ソースコードの質ではないはずです。したがって、こういった競う必要性が低い部分での横の協力が進めば、日本の報道機関全体の技術的な面での底上げにつながるのではないでしょうか。第一歩として、まずはGitHubのレポジトリをプライベートからパブリックに移行するところから始めてはどうでしょう？
報道への機械学習と自然言語処理の応用
今回の解説記事の最後にこんな一文があります。
In the future, we would like to explore the words used in the comments, using standard and bespoke natural language processing algorithms.
将来的には、我々は標準的なものからカスタムのものまで、各種自然言語処理アルゴリズムを用いて、コメントの内容そのものを調査してみたい。
コメント欄というのは自然言語（英語）で書かれています。つまり今回見たような単純な手法ではその傾向を分析するのは困難です。ここをさらに深く掘り下げるには、自然言語処理、もっと言えば人工知能関連の技術の応用が必要になります。人工知能に関しては驚くほどのハイプが出回っていますが、少なくとも現時点での人工知能関連技術というのは非常に便利な道具に過ぎません。しかし適切に使えばデータ分析に大変な力を発揮します。
簡単な例ですと、今回の記事では男女の差に着目して解析を行っていましたが、これがもし人種だったらどうでしょう？ プロフィールにいちいち人種を書くということはまずありえないので、何らかの推測に基づいた判別が必要になります。仮に元のデータに著者の近影が存在した場合、適切にトレーニングした分類器を用いれば、東アジア系、中東系、アフリカ系、ヨーロッパ系などに大雑把な分類するのは、今の機械には決して不可能ではありません。
今後そういった技術を持った人々が報道の世界で働くということも十分に考えられるシナリオだと思います。
まとめ
このように、実際のデータ解析作業というのは、かなり地道な作業が多く、メディアを賑わす数々のバズワードのイメージとは若干ズレがあると思いませんか？ 一方、様々な技術が導入されている今日の報道ですが、まだまだ改善の余地があります。特にデータの高度な分析には統計解析の専門家の力が欠かせませんし、ソーシャルメディアでの言論などを大規模に解析するには、自然言語処理の専門家などが必要です。他の多くの分野と同じく、ジャーナリズムの世界にも最新技術による革新を起こせる可能性が広がっています。道具は揃ってきました。あとはやるかやらないかだけです。
私はジャーナリズムとは全く関係のない完全なアウトサイダーですが、科学分野に関わる仕事をしておりますので、データの分析やそのプロセスの透明性といった部分で、新たなスタイルの報道と科学の類似性を感じています。すなわち、最新技術を特定分野に応用するための分野を超えた協力関係です。これらに関連する諸問題は、技術的な面と人的な面の両面からアプローチしないとなかなか解決できません。このような複雑な問題に向かい合う場合、分野を超えた交流が重要だと考えており、少しでもこういった分野に目を向ける人が多くなり、新たなコラボレーションが生まれてくれれば、と願っております。
Keiichiro Ono (大野圭一朗)
4/17/2016
CC BY 4.0
質問などはkono at ucsd eduまでお願いいたします。
※当記事は大野圭一朗氏のMediumのブログ記事を転載したものです。
大野圭一朗
英ガーディアン社は、ウェブ版の記事に寄せられた大量のコメントを計算機により解析し、コメントによるハラスメントの傾向を分析した。同社はそれに用いた技術的側面も公開したため、その詳細について検討した。このようなデータ分析は報道の現場でも今後重要度を増し、プロセスの透明性や解析の再現性といった、科学論文執筆関わる諸問題に類似した課題に直面すると予想される。それらの解決に利用可能な技術についても検討した。
はじめに
CMSの普及以後、個人ブログに限らず、コメント欄を開放している大手メディアのウェブサイトもよく見かけます。大手の場合、管理者があまりにひどい罵詈雑言などは各社の規定に基づきブロックしますが、そうでないものは基本的には掲載されます。大手になればなるほどサイトを訪れる人も増え、このモデレーションの作業が大変になるため、労力に対して吊り合わないと言う理由でコメント欄を閉じてしまうサイトも多いです。しかしイギリスの老舗メディアの一つであるガーディアン紙は、それでもなお読者からのフィードバックはジャーナリストにとっても重要だと信じ、今でもコメント欄を開放しています。90年代末から書き込まれてきたコメントの総数は、今では7,000万件を超える膨大なものとなっています。
このコメント欄の価値に関して一石を投じる分析が、ガーディアン紙自身によって行われました。この分析がなかなか興味深かったのでここで背景も含めて紹介します。
記事の背景
殆どの方が体感的におわかりだと思いますが、利用者の多いサイトのあらゆるコメント欄というものはいずれ荒れるものです。これは世界共通の現象です。そこで一定の秩序を保つためには、ある程度のモデレーションが必要です。分かりやすい罵詈雑言などは機械的なフィルタリング（正規表現によるNGワードのマッチング）で可能ですが、ヘイトスピーチなどをこの手法だけで取り除くのは困難です。なぜならば、言葉遣いは非常に丁寧でも相手を罵倒したり差別したりすることは可能だからです。例えば、
「人種Xに属する人々は大変知能が低く、現代的な文明というものを持っていないのです。彼らを力で支配し、正しく導くのは我々の責務だと思われます」
と言う文は完全にヘイトスピーチですが、いわゆる放送禁止用語や分かりやすい罵倒語、わいせつな言葉などを含まないため、シンプルな機械的フィルタリングで取り除くのは困難です。そういった理由もあって、コメントのブロックや削除は未だに人間のモデレータによって行われています。
しかしこのうんざりするような長年の手作業の副産物として、彼らは一つの巨大なデータセットを生み出しました。すなわち、人の手によって分類された膨大な数のコメントです。ガーディアン紙では、モデレータにより不適切なコメントを、ガイドラインに沿ってブロック、もしくは削除しています。
このように人がコメントの内容に沿って掲載するかブロックするかを決めているのですが、ブロックされたコメントもデータベースには記録として残っています。7,000万のコメントのうち、およそ2%に当たる140万件のコメントが不適切なものとして分類されたそうです。多くは攻撃的で不適切な内容だったそうですが、これには脱線しすぎたコメント、いわゆるオフ・トピックなものも含まれています。つまり、彼らは人の手で分類された膨大な量の「攻撃的なもの/そうで無いもの」と仕分けされたコメントのデータベースを持っているのです。
この記事からはブロックされたコメントのリアルタイム表示が見られる (上のスクリーンショットは4/13/2016 7:05PM PSTに取られたもの)
ガーディアン紙の解析チームは一つの仮説を立て、それをこの長年蓄積されたデータを使って定量的に検証してみることにしました。その仮説は以下のものです:
Articles written by women attract more abuse and dismissive trolling than those written by men, regardless of what the article is about.
女性によって書かれた記事は、その内容に関わらず、嫌がらせや軽蔑的な煽りの対象になりやすい
つまり女性によって書かれた記事は、女性が書いたという理由だけで軽んじられたり、おかしな人をひきつけやすいと言う仮説です。これはしばしば言われてきたことですが、定量的に大規模なデータから分析した例はあまりないと思います。そこで彼らは実際にやってみることにしました。
なぜジェンダーに関する仮説なのか？
これは割とシンプルな理由で、仮説としてわかりやすいのと、データの分類時に真偽の二値で扱えるために解析が行いやすかったからだと思います。他の性的マイノリティーや人種に関する属性をメインにすると、よりデータの自動分類が難しいという理由もあったと思います（後述）。
解析の結果
はたして、その結果はうんざりするものでした:
The 10 regular writers who got the most abuse were eight women (four white and four non-white) and two black men. Two of the women and one of the men were gay. And of the eight women in the "top 10", one was Muslim and one Jewish.
And the 10 regular writers who got the least abuse? All men.
定期的に記事を執筆している記者のうち、最も多くの嫌がらせを受けた10人の内訳は、8人が女性で2人が黒人男性だった。そのうち2人の女性と1人の男性はゲイだった。その「トップテン」の８人の女性うち、1人はムスリムで、1人はユダヤ人だった。
そして最も嫌がらせを受けた回数が少なかった10人は、全員男性だった。
この結果を導き出したのは、計算機によるデータ解析でした。解析結果についても思うところはあるのですが、ここでは技術的な部分についてのみ注目してみます。実はこの記事に合わせて、解析チームの方がこの解析に使った手法についてかなり詳細に書いています:
対象とする読者
本稿ではこの記事に書いてある手法を、技術者ではない方に向けて解説してみます。ですからプログラマの方などが読まれると冗長に感じられるかと思いますが、そこはご勘弁を。専門家向けの記事と、「データ解析」という言葉が事実上「魔法」と同義語で使われている全く技術に触れない記事はたくさんあるのですが、その中間が埋まっていないように感じていたというのが執筆の動機の一つです。実例の解説は、その「魔法」にかかった靄を取り除き、実際の作業がどのくらい地味なものかを明らかにすることができると思います。
元の記事では、結果を可視化したものが見られる (© The Guardian)
なお結果の詳細は、D3.jsを使ったインタラクティブなチャートとして元記事に掲載されていますので是非ご覧になってみてください。「ジャズや競馬[注]の話題に関しては穏やかなコメントが比較的多いが、フェミニズムやパレスチナ問題のコメント欄はかなり荒れる」と言う、どこかで聞いたような話だな...と思わず苦笑してしまうような事実がデータに基づき図表で解説されています。実際の嫌がらせの内容にも触れていますので、読んでいてあまり気持ちのいいものではない部分もありますが、「誰でも自由に発信できる世界」に対して記者の方々が払っているコストの生々しい実態が読めます。
[注]: イギリスの記事ですから、日本の競馬とは雰囲気や意味合いがかなり異なるので、そこは注意して読んでください 。
仮説検証のための技術
今回の分析では、複雑な統計解析は行われていません。最終的に得られたデータを可視化して、それを使って仮説が正しいかどうかざっと眺めるような作業になっています。基本的な流れとしては、手元にあるデータに欠けている情報を追加し、複数のデータセットを統合し、フィルタリングし、ブラウザ上で可視化するというものです。これは可視化を伴う分析を行う場合の最も基本的な作業です。ただし今回は比較的大きなデータを使っていますので、一部は商用クラウドサービス上でSpark（後述）を利用しています。ここからは実際に使われたデータやツール、手法について詳しくみていきます。
可視化を目的にする場合の典型的な作業の流れ。基本的に、大量のデータを人間が把握できる大きさまで「濃縮」する作業と言い換えることができる。
使われた技術
今回使われたツールは、データ分析を業務として行っている方々にはおなじみのものばかりです。例を挙げると:
・テキスト処理のためのPerlスクリプト
・Amazon Web Service (S3, Redshift, EMR)
・Apache Spark
・PostgreSQL
・D3.js
・HTML5
などです。これらのツールは以下のように分類できます。
・データを蓄積して検索可能にする技術: PostgreSQL, S3, Redshift
・データを加工するプログラム: Perlスクリプト
・大規模なデータを複数の計算機で処理する技術: Spark
・それらを実行するための環境を提供する技術: AWS全般, EMR
・最終的なユーザー（今回のケースでは読者）がデータをわかりやすく見られるようにする技術: D3.js, HTML5
これらが実際にはどう使われたのかは後ほど見ていきます。
データセット
今回解析の対象となったコメントデータは以下のような特徴を持ちます:
コメントデータベース
・1/4/1999 ~ 3/2/2016の間にガーディアン紙のサイトにて書き込まれたコメント。ソーシャルメディアなどでの記事への言及は含まない
・コメント総数7,000万件
・うち22,000件が2006年以前に書き込まれた。つまりほとんどがそれ以降のもの
・コメント欄は通常三日間オープンとなり、その間に読者が書き込める。それ以後は読むことのみ可能。したがって、ニュースに対する比較的初期のレスポンスがコメントとして集まる
・コメントは、モデレータにより「ブロックされたもの」と「通常のコメント」に分類されている
・実際のデータはPostgreSQLデータベースに格納
・解析にあたり、実際に新聞社のサイトで使われているデータベースをコピーしてAWS上にアップロード
ブロックと削除の違い
記事がサイトに表示されない場合、それはガイドラインに沿ってブロックされたか、削除されたのかどちらかとなります。今回の解析では、データとしては残っているが、内容がガイドライン違反なので非表示とされたコメント、すなわちブロックされたコメントをその記事に対する煽り・嫌がらせとしてカウントしています。
逆にデータに残っていない（したがって今回利用されていない）削除の対象となったコメントは「ブロックされたコメントへの返信」「単純なスパム」となっています。
記事のデータベース
コメントは記事に対して書き込まれます。したがって、記事が誰によって書かれたのか、どのような内容だったのかということを合わせて解析するためには記事のデータベースが必要です。ガーディアン社の記事データベースは以下のようなものです:
・オンライン版の記事総数はおよそ200万
・Amazon Web ServiceのRedshiftに格納
・このデータベースは公開APIに接続されていて、外部の人もプログラムから検索をかけることが可能
Amazon Web Serviceとは何か？
またここでもAmazonが出てきました。最近のプログラマは空気のように使っている技術ですが、それ以外の人にとっては「なんで通販会社が新聞社のデータ解析に関係あるの？」ということになりかねないので、ここで簡単に説明しておきます。
Amazonは本の通信販売の会社として始まりましたが、成長の過程で、その大量のオーダーを裁くために無数のサーバーを含む巨大なシステムを構築しました。そこを維持するためには、ハードウェア・ソフトウェア両面の様々なノウハウが必要なのですが、先見の明のあったAmazon社の社長は、そのノウハウをベースに構築された高度な計算機システムを、外部の人に時間貸しという形で提供するビジネスを思いつきました。それがAmazon Web Service (AWS)と呼ばれるサービスです。これを解説し始めると本1冊以上の分量になってしまうので詳細は割愛しますが、企業はこれを利用することにより、自社内にサーバーを持って、データベースを構築して、バックアップを取って、電源を適切に管理して...という作業を外部化することができます。しかもありとあらゆるものが仮想化という技術をベースに抽象化されていますので、まるでソフトウェアを実行するように新しいサーバーを構築し、それをいらなくなったらコマンド一つで捨てる、ということが行えます。いわゆるビッグデータ（私はこの言葉の定義が非常に曖昧であるため、あまり好きではありませんが...）を解析するような場合、必要な量だけのストレージ、つまりデータの置き場を用意し、必要な数だけの計算機を時間単位で借りて一気に解析する、ということが可能です。
このような「時間貸し計算機」のサービスは、現在の大量のデータを生み出す社会の中で重要な役割を果たしています。AWSやその他の大手クラウドコンピューティングサービスは世界中のあらゆる企業によって使われています。また企業ばかりではなく、私の職場のような非営利の研究機関でもこのサービスは利用されています。大量の塩基配列情報を処理するのに、安い時間帯（AWSは、時間によって値段の変動するオークション形式も採用しています）に一気に多数の計算機を借りて解析を実行する、というようなことも始まっています。
ガーディアン社でのAWSの利用
ここでガーディアン社の使っているAmazon Redshiftと呼ばれるサービスは、いわゆるデータウェアハウスを外部に構築する際に使われるものです。新聞社にとって命とも言える記事のデータを全てここに格納し、解析や検索が行える状態になっています。社内の解析チームが直接使っているものとは異なると思いますが、この記事データベースは一般の方にも開放されています。英語ですが使い方も書いてありますので、興味のある方は遊んでみてはどうでしょう。ちょっと試すだけなら、ブラウザからもアクセスできます。
このデータベースに対して適切な検索条件を送信することにより、著者のデータも得ることができます。今回は「最低2回はガーディアン紙上に記事を書いたことのある人」という条件で著者名のリストを得ました。その総計はおよそ12,000人でした。しかしここで問題が一つあります。今回の仮説は男女の差に関わるものなのに、著者の性別はデータベースには存在しないのです。この問題を彼らはどう解決したのでしょうか？
著者の性別の判定
今回、最終的に検証したい仮説が性別に基づくバイアスなので、著者の性別がわかっていないとどうにもなりません。この問題を解決するために彼らが行ったのは、ある意味とても原始的な作業でした。しかし技術的には高度でないにもかかわらず、この類の作業というのがデータ解析を行うときに最も面倒で時間のかかる作業であるケースも非常に多いです。つまり、一定のエラーを含みながらも必要な結果を得られる程度には正確な、形成されたデータを作るという作業です。
名前から性別を判定するワークフロー （Cytoscape 3.3にて作成）
今回の具体的な作業は上の図のようになります。まず12,000人の著者名を、無償で公開されている男女別の人名リストと比較するスクリプトを実行します。おそらくここではファーストネームの完全一致による単純な判別を行っていると思われます。これにより、11,098人分のデータが男女別に分類され、1,268人が性別不明として残りました。性別不明になる原因は色々と考えられるのですが、そもそも名前がリストにない場合はわかりませんし、名前の英語表記の揺れなども原因になります。例えば、下のスクリーンショットは今回使われた名前のリストからの抜粋ですが、日本人名の「ケンイチ」という名前は、正しく男性名に分類されていますが、表記がKEN'ICHIであるため、KENICHIという表記との単純一致だと取りこぼしてしまいます。このような名前や住所といったものの表記ゆれは厄介な問題で、バラバラにデータベース化された情報を統合する時に様々な問題を引き起こします。
names.csv. KENという語で検索をかけた例
さて、この時点で不明の1,268人分のデータの性別を判定するために、今度は以下の人名判定サービスにPerlスクリプト（この場合は、Perlというプログラミング言語で作業工程を記述した小さなプログラムのことです）で送信します:
・genderize.io: Determine the gender of a first name
このサービスを利用した後の時点で何名ぐらいが性別不明だったかはわかりませんが、なんとか人力で判定、つまり人名辞典やネット検索で人間が一つ一つ判定するのも不可能ではない程度の量にまで不明の数が減っていたので、残りは実際にそういう作業で仕分けされています。「データサイエンス」という言葉の響きとは対極にあるような作業ですが、現実はこんなものです。
ともあれ、この作業で一定のエラーは含まれているが、それなりに大きい数の男女別著者リストが得られたので、そのファイル(CSV)をAWSのS3というストレージサービスにアップロードしました。ここからはAWS上の計算機での作業になります。
Sparkでの分析
ガーディアン社はかねてより、こういった比較的大きなデータを分析することによる調査報道をやりたかったらしく、大規模な分散処理ではスタンダードな地位にあるApache Sparkを実際に使うプロジェクトを探していました。今回の解析はテストケースとして丁度良いものだったため、実際に利用しています。
Sparkとは何か？
Apache Sparkとはオープンソースで開発が続いている「並列分散処理のためのフレームワーク」です。これだけでは一体なんなのか分かりにくいと思いますが、要するに複数の計算機を利用して、巨大なデータを効率よく同時に処理するためのソフトウェアのことです。今日のデータ分析で巨大なデータを扱う時に高性能な計算機が必要な場合、一台の高性能なマシンに大きな投資をして使うことは稀で、基本的には比較的安価な計算機をたくさん集めて処理を分散させて行います。この作業を行う時には、一台の計算機で処理を行う際に比べてはるかに高度な技術が必要になります。この複雑な部分の面倒を見てくれるソフトウェアと考えてもらって概ね問題ないです。
若干技術寄りの話になりますが、かつてこのソフトウェアを使う時にはScalaという言語でRDDと呼ばれる比較的抽象度の低いデータ構造を使う必要があったのですが、最近ではRとDataFrame（スプレッドシートのシートのような感覚で各種データを扱えるデータ構造）という、データ解析を行う人々には馴染み深い、かなり抽象度の高いものを利用できるようになってきました。現時点でもScalaを使える人がもっともこのソフトウェアを効率よく使いこなすことができますが、そうでない人にも今後は門戸を開いていくという方針のようなので、大規模データ分析の世界ではSparkのさらなる普及が予想されます。
クラウド上での実行
このSpark、素晴らしいソフトウェアなのですが、実際に複数の計算機を利用して解析したい場合は、そのセットアップにそれなりの時間がかかります。また、Sparkのノード（分散させた作業を実行させる計算機）として使える大量の計算機を自前で用意するのは、（規模にもよりますが）コストも膨大なものになります。こういった時に便利なのがAWSのような商用クラウドサービスです。AWSにはAmazon Elastic MapReduceという、Sparkのようなソフトウェアを実行できるように設定された計算機群（クラスタと呼ばれます）を時間貸ししてくれるサービスがあります。ガーディアン社は今回このサービスを利用し、Sparkを使った解析をEMR上で実行しました。まるでAmazonの回し者のようですが、現実的な問題として、ここまでバラエティに富んだクラウドサービスをワンストップで提供している企業はAmazonをおいて他に無く、それが企業からマスコミ、研究機関まで幅広いユーザーを獲得するのに成功した理由だと思います。
さて、実際のタスクですが、今回は、AWS上にアップロードされたコメントデータベース、記事データベース、著者のデータに対し、ひたすらクエリを投げて必要な情報を切り出し、どの著者がもっとも多くの誹謗抽象・煽りコメントを受け取っているのかを集計していきました。このような大量のデータに対する比較的単純な作業の繰り返しはSparkの得意とするところで、テストプロジェクトとしては良い選択なのではないかと思います。実際に今回の作業は、パイロットプロジェクトというか、まだ彼らに取っても初の実験だったため、ソースコードにも試行錯誤のなごりが見て取れます。こうして得られた結果は、同じくAWSのS3上に書き出されていきました。この最終的な結果は、スプレッドシートなどで集計・図表化可能な程度の大きさのものだと考えて良さそうです。
また現在ガーディアン社のデータ解析チームは、将来的にこのような解析がより行いやすくなるようにPrestoと呼ばれるFacebook社を中心に開発されているオープンソース・ソフトウェアを使い、いわゆるデータレイク（これもバズワードに属するものだとは思いますが...）を構築しているようです。ここからも、彼らが自社で蓄積してきたデータに対する計算機による解析を、今後も進めていこうという姿勢が読み取れます。
データの可視化
これで必要なデータは出揃いました。今回は最終的には新聞記事として使うものですから、このデータを読者が分かりやすい形で提示する必要があります。最近はウェブ版の記事を念頭に作られることも多く、今回の記事も文章に加えて、実際に嫌がらせコメントを多く書き込まれた記者へのインタビュービデオなど、様々なメディアを組み合わせたものとなっています。そして最近の傾向として、こういったデータを見せるときに、ブラウザベースの可視化を用いることが多くなってきました。つまり、最新のウェブ・ブラウザに備わった高度な描画機能を用いて、複雑な図表の作成や、アニメーション、双方向性のある表現などが可能となり、これらを報道の場面で使おうという動きです。
このトピックに関しては、私も仕事として関わっていますので、何か面白そうな記事に出会ったときに、改めて独立した文章として書いてみたいと思います。少々技術的になりますが、実際の可視化の作業などに興味がある方は、こちらの記事もどうぞ。
今回の場合、こういった表現を行う場合に使うツールとしてスタンダードなD3.jsを利用し、最終的な集計結果をプロットし、アニメーション表現を使ってスライドのように繋ぐということをしています。比較的控えめな使い方ですが、今回の結果を見せるためには十分だと思います。ぜひ元の記事のプロットをご覧になってみてください。
考察
今回の解説記事を読んでいて既視感を覚えたのですが、その原因は、要するにこれは学術論文における実験プロトコルの簡易版のようなものだからです。査読付きのジャーナルに掲載されるようなものに比べればはるかに簡易的なもので、これを読んだからといって必ずしも同じ手法で同じ解析ができるわけではありません。しかし、このようなものが調査報道の記事と共に掲載されるようになったのは大きな進歩だと思います。特に計算機を使った解析の場合、その対象が公開データセットの時は、ソースコードと解析に使った環境を公開しておけば、ほぼ同じ解析が技術さえあれば誰でも行えます。事実、先進的な取り組みをしている海外の一部マスコミでは、記事執筆に使ったコードをGitHubにて公開する動きも出てきています。
欧米メディアのGitHubレポジトリ
・The Guardian
・The New York Times
・ProPublica
・ICIJ
・Los Angeles Times
調査報道と再現性
科学の世界では当たり前なのですが、ジャーナリズムの世界でも、このようなデータ解析を使った報道というものの出現に伴い、そのプロセスの透明性と再現性といった点が話題になっています。英語ですが、興味のある方はこのあたりの記事を読んでみてください。
・The Need for Openness in Data Journalism
・The Rise of Transparent Data Journalism
解析の再現性には幾つかのレベルがあります:
１．機械可読な形でのデータの公開
２．解析に使った手法とそのソースコードの公開
３．解析に使った環境の公開
1はともかく、2と3はかつては技術的になかなか難しい面もありました。しかし、現在では公開されたソースコードの事実上の標準レポジトリであるGitHubがありますし、解析の規模にもよりますが、解析環境をコンテナ技術（Dockerというソフトウェアがもっとも普及しています）を用いて第三者が再現可能な形で残すこともできます。このように、技術的に解決出来る面も増えてきていますので、調査報道の分野を中心に、今後はこういった方向を目指すメディアも増えるのではないかと思います。
また、こういった話題で必ずと言っていいほど出てくるJupyter Notebookというツールですが、これは人間のための文章や図表と、計算機で実行できるコードを混在させて、実際にそれを実行しながら動作を確認できるという非常に強力なツールです。報道では、解析に使ったコードを読者に実際に手元のマシンで実行させながら読んでもらうということが可能になります。これについてもいずれ最近の傾向をまとめたいと思いますが、使うこと自体は決して難しくないので、少しでもプログラミングのできる方はぜひ試してみてください。
余談: 日本のメディアの方へのささやかな要望
GitHubにウェブ版の紙面で使ったコードを公開することで問題が発生するケースはまず無いと思います。報道機関のパフォーマンスはあくまでその内容で競われるべきものなので、ソースコードの質ではないはずです。したがって、こういった競う必要性が低い部分での横の協力が進めば、日本の報道機関全体の技術的な面での底上げにつながるのではないでしょうか。第一歩として、まずはGitHubのレポジトリをプライベートからパブリックに移行するところから始めてはどうでしょう？
報道への機械学習と自然言語処理の応用
今回の解説記事の最後にこんな一文があります。
In the future, we would like to explore the words used in the comments, using standard and bespoke natural language processing algorithms.
将来的には、我々は標準的なものからカスタムのものまで、各種自然言語処理アルゴリズムを用いて、コメントの内容そのものを調査してみたい。
コメント欄というのは自然言語（英語）で書かれています。つまり今回見たような単純な手法ではその傾向を分析するのは困難です。ここをさらに深く掘り下げるには、自然言語処理、もっと言えば人工知能関連の技術の応用が必要になります。人工知能に関しては驚くほどのハイプが出回っていますが、少なくとも現時点での人工知能関連技術というのは非常に便利な道具に過ぎません。しかし適切に使えばデータ分析に大変な力を発揮します。
簡単な例ですと、今回の記事では男女の差に着目して解析を行っていましたが、これがもし人種だったらどうでしょう？ プロフィールにいちいち人種を書くということはまずありえないので、何らかの推測に基づいた判別が必要になります。仮に元のデータに著者の近影が存在した場合、適切にトレーニングした分類器を用いれば、東アジア系、中東系、アフリカ系、ヨーロッパ系などに大雑把な分類するのは、今の機械には決して不可能ではありません。
今後そういった技術を持った人々が報道の世界で働くということも十分に考えられるシナリオだと思います。
まとめ
このように、実際のデータ解析作業というのは、かなり地道な作業が多く、メディアを賑わす数々のバズワードのイメージとは若干ズレがあると思いませんか？ 一方、様々な技術が導入されている今日の報道ですが、まだまだ改善の余地があります。特にデータの高度な分析には統計解析の専門家の力が欠かせませんし、ソーシャルメディアでの言論などを大規模に解析するには、自然言語処理の専門家などが必要です。他の多くの分野と同じく、ジャーナリズムの世界にも最新技術による革新を起こせる可能性が広がっています。道具は揃ってきました。あとはやるかやらないかだけです。
私はジャーナリズムとは全く関係のない完全なアウトサイダーですが、科学分野に関わる仕事をしておりますので、データの分析やそのプロセスの透明性といった部分で、新たなスタイルの報道と科学の類似性を感じています。すなわち、最新技術を特定分野に応用するための分野を超えた協力関係です。これらに関連する諸問題は、技術的な面と人的な面の両面からアプローチしないとなかなか解決できません。このような複雑な問題に向かい合う場合、分野を超えた交流が重要だと考えており、少しでもこういった分野に目を向ける人が多くなり、新たなコラボレーションが生まれてくれれば、と願っております。
Keiichiro Ono (大野圭一朗)
4/17/2016
CC BY 4.0
質問などはkono at ucsd eduまでお願いいたします。
※当記事は大野圭一朗氏のMediumのブログ記事を転載したものです。
大野圭一朗