『
ニューズウイーク 2016年4月12日（火）18時25分 大野圭一朗
http://www.newsweekjapan.jp/stories/world/2016/04/post-4887.php
「パナマ文書」解析の技術的側面
How to analyze the "Panama papers"
2.6テラバイトのリークデータを調査報道機関はどうやって分析したのか？
●プーチン大統領の資産隠しに関わっていると思われる会社と関係者のネットワーク (Generated with Linkurious)
世界中で話題になっているパナマ文書。
各国で政権を揺るがすような事態にもなっていますが、純粋にデータとしてみた場合、これは計算機やデータ解析に関わる人々にも面白いものだと思います。
データの中身や背景などについてはさんざん報道されていますのでここでは触れません。
一方、現場でどのような作業が行われているのかはあまり報道されていません。
現実的な問題として、人力ではどうしようもない量のリークデータを手に入れた場合、調査報道機関はどんなことを行っているのでしょうか？
私も以前から疑問に思っていたのですが、先日あるデータベース企業と、データ分析アプリケーションを作成する会社のブログにて、その実際の一端を窺うことができる投稿がありました:
・Panama Papers: How Linkurious enables ICIJ to investigate the massive Mossack Fonseca leaks
・The Panama Papers: Why It Couldn't Have Happened Ten Years Ago
・Inside the Panama Papers: How Cloud Analytics Made It All Possible
これらは普段からグラフ（後述）を扱う仕事をしている自分にとっても興味深いものでしたので、ここで紹介します。
こう言った現代の調査報道のテクニカルな部分は日本のマスコミで報道されることはほとんどないので、読んでいて純粋に面白かったです。
ここでは世界の調査報道機関はどんなテクノロジーを使い何をやっているのかを、技術に明るくない人にもできるだけわかりやすいように書いてみようと思います。
■データの形式
まず今回のデータの計算機的な性質です。
公開されている情報によれば、それは以下の様なものです
●出典: Süddeutsche Zeitung "About the Panama Papers"
★．・容量: 2.6TB。
大きさとしては一万円程度のハードディスクにすべて納まります。
★．・ファイル数: およそ1,150万
★．・データ形式: 電子メール、RDBなどのデータベース、PDF文書、画像（おそらく多くは書類のスキャン）、テキストファイル。
ファイル数の分布は上のチャートを参照
「2.6TB」というデータは、現在の計算機にとっては決して大きなものではありません。
貴方がテレビ録画用のHDレコーダをお持ちでしたら、おそらくこれより大きなデータをそこに格納できるでしょう。
しかし、その大きさのデータを
人間が解析しようと思った時、それはあまりにも膨大な量で、とても人力でどうにかなるものではありません。
本質的にこのデータセットに対しては、プリントアウトしてひとつひとつ見るというようなアナクロな手法は通用しません。
パナマ文書は何らかの検索や可視化の技術が利用できなければ、人間には歯が立たないものなのです。
しかし幸運なことに、今回のデータは画像ファイルを除けば（これも最近「インテリジェントな」解析技術が飛躍的に向上していますがここでは触れません）、ほぼすべてが機械で比較的低コストで処理できる形式のファイルです。
ここで計算機の出番になります。
ここから先は、先の記事から読み取れる技術的な背景について解説していきたいと思います。
■データの前処理
このような膨大な数のファイルを解析する場合、必ずデータの前処理が必要になります。
今回のデータセットは大きく二つのタイプに分けることができます:
１：. RDB形式（いわゆるデータベース）の機械で容易にアクセスできるファイル
２：. 人が読むことを前提にした文書ファイル。
テキストと画像、PDFを含む
今回解析に当たったICIJのデータ解析班は、まず比較的ハードルの低いひとつ目のデータに取り組みました。
要するに、データベースを容易に検索できる形に再構築することです。
これは専門家の手により数ヶ月で終えることができたそうです。
しかし二つ目のデータはそうはいきません。
■テキストデータへの変換
この記事によれば、画像の多くは紙の書類をスキャンしたものだったようで、そこから文字情報を引き出そうとする場合、OCRという技術が必要になります。
「OCR」とは要するに画像から文字を認識して切り出す技術です。
日本でもユーザーの多いEvernoteなどでも利用されている技術です。
写真に写った飲み物のラベルの文字が文字列検索で引っかかることがあると思いますが、あの技術のことです。
最近はラップトップと家庭用スキャナの組み合わせでも行うことができる、広く普及した技術です。
ただし今回は画像の数が膨大なため、時間を短縮するために、
商用クラウドコンピューティングサービス（要するに計算機の時間貸し屋さんです）であるAmazon Web ServiceのEC2
を使ったようです。
どのインスタンスタイプかまでは確認できませんでしたが、
30台から40台のEC2インスタンスを用いて、ひたすら画像データを文字情報に変換する作業をまず行いました。
■データのグラフ化
OCRによるテキスト化を行うと、ひとまず計算機上での扱いは容易になります。
極端な事を言えば、テキストで保存してある限り、それをエディタで開いて文字列検索することでも、ある程度は何が書いてあるかを読めるようになります。
しかし詳細な調査には最終的にはスキャンされた書類や会計報告などを専門家が読み込む必要があり、人や企業のネットワークから、キーワード検索でさらに詳細を調べられるようにしなくてはなりません。
それを構築するために用いられるのが全文検索エンジンと呼ばれるものです。
実際に使われたものはApache Solrで、メタデータやテキストの切り出しにはTikaが使われました。
これらを利用し、彼らはまずファイルの集合からメタデータを切り出しました。
ここでいうメタデータとは、ファイルタイプやタイムスタンプなどで、これをインデックス化することにより大量のファイルがより検索しやすくなります。
しかし、今回のデータにはおよそ215,000もの会社（おそらく多くがペーパーカンパニー）が含まれており、そこを流れるカネを分析するためにはもう一工夫が必要です。
ある会社の会計報告や登記簿を読んでいる場合、その会社の関係者、そしてその会社に関連する他の企業などのつながりを見られるようになれば、カネの流れを把握するのに大いに役立ちます。
もちろんこれは文章でも表現できます。
例えば専門家は今回の文書を実際に読むことにより以下のような情報を得たとします:
・：A社の現在の社長はx氏
・：A社はB社の取締役であるY氏によって設立された
・：Y氏は『A社』というキーワードが大量にヒットするメールをZ氏に頻繁に送っている
・：αという住所にA社があり、B社の所在地はβである
・：αとβはグランドケイマン島の、γビル内の同じフロアに存在する
・：Z氏はγビルのオーナーである
このレベルのつながりならば、ここから
X氏とY氏にはA社の創業者とその後継者という繋がりがあり、B社はA社と何らかの繋がりがある。
そして会社の登記には名前がないが、Z氏とA社にはY氏を介しておそらく何らかの関係性が存在する。
そして両社の所在地から、これらは同一ブローカーが関与して設立されたペーパーカンパニーの可能性がある。
そのブローカーはZ氏の可能性がある。
というような推論が人間にも可能です。
ところがこのような繋がりが数十万、数百万というレベルで存在するとどうでしょう。
もはやその全体像を人間がこのように文章に書き下して一つづつ把握するのは不可能です。
そのために彼らはデータのグラフ化を選択しました。
■グラフとは何か?
「グラフ」という言葉を聞くと、折れ線グラフや棒グラフといった、いわゆる「ダイアグラム」とか「チャート」と英語で呼ばれる図表を思い浮かべる方が多いと思います。
しかしここで言うグラフは、数学用語のグラフです。
厳密には、以下のような定義になります
★：グラフGは、接点の集合Vと辺の集合Eからなる順序対であり、
G = (V, E)とあらわせる。
小難しいですが、何て事はない、ただの「繋がり」、もしくは「ネットワーク」の数学の世界での呼び名にすぎません。
百聞は一見に如かずで、以下の図を見ていただければ一目瞭然だと思います。
●panamapapers03.jpeg
Protein-Protein interactions of yeast. Generated with R, igraph, and Cytoscape. By K. Ono. CC BY 4.0
このようなネットワーク構造の事を「グラフ」と呼びます。
上の例では各頂点（ノード）はパンを焼くときに使う酵母の中に存在するたんぱく質、辺（エッジ）はそれらが直接的に相互作用を起こす事を意味しています。
私の関わる生物学の分野でも、このように物質間の関係性を表したり、極めて複雑な体内での生化学的な反応を人が理解しやすくするために、それらの反応経路をグラフで表現すると言った手法が頻繁に用いられます。
つまり、あらゆる経路や、人と人との関連性、相互作用といったものを解析する場合、そのデータを計算機が咀嚼できる形のグラフとして表現することは非常に重要で、それを行うことにより人間にはできないレベルの解析を行うことができるようになります。
グラフ構造というものは、文字通りあらゆるところに現れます:
・：ソーシャルネットワーク
・：たんぱく質間相互作用
・：感染症の拡大経路
・：地図
・：犯罪組織の組織内構造
・：恋愛関係
●panamapapers04.jpeg
visual complexity: あらゆるタイプのグラフ可視化を収集しているサイトの老舗
そしてこのようなグラフを人の目に見えるようにする事をグラフ描画と呼びます。
グラフ構造は様々な分野に現れるため、この構造を解析したり描画する事そのものが研究分野になっています。
特に近年、ソーシャルネットワークサービス等の普及に伴い、大規模で複雑なネットワークのデータを得やすくなったため、社会科学の分野でも様々な研究が行われています。
このような研究の広がりにより、オープンソースで誰でも利用できるグラフ解析や可視化、データの蓄積に使えるソフトウェアが急速に普及しました。
代表的なものでは、
★：古い歴史を持つグラフ描画ソフトのgraphviz、
★：Rという統計の専門家が好んで利用する統計解析用プログラミング言語実行環境の上で動くigraph、
★：今回のケースでも利用されたソフトウェアを開発していた人が関わっていたGephi、
★：大規模なグラフのデータを蓄積し検索できるようにするためのデータベースであるNeo4j、
★：この記事に出てくる幾つかの私が作った図の作成にも用いられている、
我々のチームが開発したCytoscape
などがあります。
ほぼすべてのものが無料で使えるため、高度なグラフ解析や可視化の技術が一般的になりつつあるというのが現在の状況です。
●panamapapers05.jpeg
GitHub内に存在するDatavizコミュニティの可視化 By K. Ono. CC BY 4.0
■実際のグラフ構築
「機械可読なグラフデータを構築する」と書くと大変仰々しいのですが、実はそれほど複雑なことではありません。
基本的に、ありとあらゆるエッジは以下の形式で表現可能です:
Node A, Edge Type, Node B
つまりこのような形のテキストで関係性を記述できれば、あらゆるグラフはデータベースや可視化ソフトで使うデータとして利用できます。
具体的には、こういったグラフは単なるCSV形式のテキストテーブルとして公開されることも多いです。
実際、パナマ文書より前の流出事件であるオフショア・リークス事件の時のものは、この形式でグラフデータが出回っています。
どのくらい単純なものかを知っていただくために実際に作ってみましょう。
データとしては前章で例として使った架空のデータである「ケイマン諸島の怪しい紳士たち」の例を使います。
あの文章をグラフとして表現すると以下のような感じになります:
X ceo_of A
Y founder_of A
Y board_member_of B
Y sending_emails_to Z
α address_of A
β address_of B
α sub_address_of γ
β sub_address_of γ
Z owner_of γ
これをテキストファイルとして保存し、Cytoscapeに読み込み可視化するとこのようなものが見られます。
●panamapapers06.gif
複雑なプロットのミステリー小説などでこのようなものを手書きで作ってあるのを目にした方も多いと思います。
本質的には同じなのですが、大きな違いは、機械的にこのようなデータを作り出す仕組みを整えれば、凄まじい量のデータであってもキーワードで検索したり関係性を機械に描かせて人間が理解しやすい形にできる、という点です。
今回の目的とは外れますので手法の詳細は述べませんが、このような可視化を試してみるには、テキストエディタとCytoscapeのようなオープンソースソフトウェアで簡単に行えます。
今回使ったデータはここに置いておきます：
・Sample Cytoscape Session File
では、今回のデータのグラフ化はどのような作業だったのでしょうか。
実際のデータが公開されていませんので、この部分の詳細は予想も混じりますが、幾つかヒントはあります。
非常に小さな部分グラフですが、この記事にインタラクティブに操作できるLinkuriousの埋め込みビューアが掲載されています。
●panamapapers07.gif
"How Gunnlaugsson hides his secret assets" （辞任したアイスランドの首相周辺の相関図）
これを見る限り、ノードは以下のタイプに分類してあります
・役員名
・住所
・会社
・コンサルティング企業
そしてそれを「会社の役員である」「登録先の住所」などといった比較的単純な関係性に分類してエッジを構築しています。
ここから、おそらく以下のようなことを行ったのではないかと想像しています:
★・登記などからまず会社をノードとし、付随する役員、住所、担当しているコンサル会社を関連ノードとして接続
★・ノードの名寄せを行い、類似の会社名、人物名などの間にも関連性ありとしてエッジを付与
★・これをひたすら繰り返し、グラフをどんどん接続していく
もし公開されているサブグラフが元のデータベースのものと大差ないものであれば、比較的シンプルなデータとしてまとめた感じです。
この場合、まだまだ眠っている関係性を今後掘り起こせる可能性もあります。
例えば、今回はメールデータも含まれていますので、それらの差出人（From）と宛先（To）からコミュニケーションの方向性と頻度を測定し、そこからエッジのスコアに換算。
これにより重み付きのエッジが大量に発生するので、より「解像度の高い」グラフデータに仕上げることも可能ではないかと思います。
もちろんその先には、自然言語処理の技術を使った様々な解析もあるでしょうが、今回は触れません。
なお、メールデータ等から関連人物のネットワーク構造を推定するという手法はいろいろな場面で用いられており、
米国の諜報機関もテロリストのネットワークを可視化したり解析するために、類似の手法を使っていると言われています。
余談ですが、過去の巨大なスキャンダルであるエンロン事件での証拠として公開されているメールのアーカイブから、関係者のネットワークを可視化すると言うプロジェクトもあります。
この作者はその後スタンフォード、ワシントン大学と渡って教授となり、彼のラボからはD3.jsという非常に有名な可視化のためのライブラリが生まれました。
・exploring enron: visual data mining of e-mail by Jeffrey Heer
さて、グラフを作る方針を決めた後は、ひたすらデータの掃除と加工、データベースへの流し込みです。
データ解析の世界で働いていらっしゃる方はお分かりだと思いますが、これは非常に苦痛な作業でもあります。
いわゆる「データサイエンス」が実はとても泥臭い仕事だと言われる所以もこのあたりにあります。
今回のデータの場合、215,000の会社組織に対し、最低３人の関係者がおり、これらのつながりをグラフ化するとおよそ100万ノードのグラフが出来上がりました。
実際にNeo4jのデータベースを構築するときには、このソフトウェアを利用したようです。
http://www.talend.com/download/talend-open-studio
詳細はさらに担当者の方にインタビューをしないとわかりませんが、概ねこのような作業で、まず調査のバックボーンとなるグラフデータベースが構築されたようです。
ここまで読んで、RDBの経験者の方は
「そもそもRDBのファイルでデータが流出したのならば、なんでこんなまどろっこしいことをやるのか？
そのまま統合したデータベースにSQLクエリを投げれば良いのではないか？」
と疑問を持たれるかもしれません。
彼らがわざわざグラフ化した一番大きな理由は、経路検索などといったグラフ構造に対する特有の検索を大量に行う場合、RDBで構築したものだと使い物にならないくらいパフォーマンスが低下する場合があるからだと思います。
今回の調査では、金の流れと関連人物の繋がりを見ながら資料を読み込むというユースケースだったため、グラフDBを使うのがもっとも適していると判断したのでしょう。
■人海戦術のためのLinkurious
ここからは少し泥臭くなります。
「データベース化したものを人工知能に自動的に解析させる」
というような時代は少なくともまだ当分は来ません。
ですから、ここからは人間の出番です。
そもそも彼らがグラフデータベースを利用した大きな理由には、関係者のつながりを文字通り人間が見られるようにする、というグラフ可視化の機能を使いたかったという部分が大きいようです。
複雑なグラフ構造を理解する場合、関係性を文章で読んでいても、とても人間の脳は大規模なものを短時間で把握することはできません。
そこで彼らは構築したNeo4jデータベースをLinkuriousというグラフ可視化・解析サービスに接続しました。
今回の分析には370人の世界中に散らばったジャーナリストが関わっています。
これらの人々が同時に同じデータにアクセスして分散して解析作業を行って行く場合、グラフデータベースの上にそういった作業を可能とする何らかのアプリケーションを構築する必要があります。
もちろんカスタムアプリケーションを自ら作ることもできるのですが、そこまでやる必要はないし、それはあまりにも負担が大きいので、Linkurious社の提供するLinkurious Enterpriseというサービスを利用したそうです。
今回参加したジャーナリストの大半は、Linkurious社が提供するアプリケーションのGUIを使って、グラフデータベースから人物と会社の関係を引き出し、それを目で確認しながら関連書類や資料を読み込んだようです。
中にはNeo4jに標準搭載されているグラフクエリ用言語のCypherでより高度な検索を行いながら解析を行った高度な技術を持つユーザーもいたようです。
グラフクエリ言語というのは、あるグラフに対して、特定の条件にマッチする経路やノードを検索させるためのDSL（ドメイン固有言語）の一種です。
グラフを検索するための単純なプログラミング言語のようなものだと考えてもらっても概ね正しいです。
単純な例で言えば、
「企業Aに２ホップ以内でつながっている人物と会社を列挙せよ」
「某国大統領とかかわりのある企業とX氏の間に経路があるか調べよ。
ある場合はそれを全て列挙せよ」
といった感じの検索条件を、計算機が理解できる形の検索条件に置き換えるための言語です。
こういった調査でグラフデータベースを利用する利点の一つには、構造に対するかなり複雑なクエリを実行することができる点です。
経路検索はもとより、特定の小構造（ネットワークモチーフとも呼ばれます）を持った部分を探し出したりと、RDBでは難しい解析を現実的な時間で行うことができます。
おそらくまだ今後も様々な解析を行っていくはずなので、続報を待ちたいところです。
■技術的なポイントのまとめ
・RDBに対してリバースエンジニアリングを行い、統合された形のスキーマを抽出し検索可能にした
・AWS上に用意したOCR用のインスタンスを使い、大量のファイルをテキスト化した
・ファイルのメタデータをTikaで切り出し、テキスト化された各種書類を全文検索エンジンのApache Solrに流し込んだ。
それによりキーワード検索できるようにした
・データをTalendを使い加工し、グラフ化し、Neo4jデータベースに格納した
・Neo4jのフロントエンドとしてLinkurious Enterpriseを採用した。
これにより、世界中に分散したユーザーが同時に複雑なデータセットにGUIからアクセスできるようになった
■今後の予想
まだ（生）データが出ていないので想像でしか物が言えないのが心苦しいですが、これらの記事を読んだ印象では、いわゆるデータサイエンティストと呼ばれる人々を迎える事により、まだまだ多面的な解析が行えそうな気がしています。
現在公開されているLinkuriousのサブグラフに出ているエッジの種類はかなり限られていますし、スコアリングや時系列の資金の流れのマッピングなどといった高度な事は行っていないようにも見えます。
私は統計屋さんではないので、あくまでプログラマとしての立場の意見ですが。
秘密裏にデータをシェアして共同作業を行う、という点でフロントエンドとして大きな役割を果たしたLinkuriousですが、バックエンドのNeo4jは独立して存在するので、今後グラフ構造そのものの解析や、エッジ/プロパティ追加によるデータのさらなる多面的な解析を行う場合は、直接Cypher経由で複雑なシナリオを検討する事が考えられます。
また、非構造化データから抽出したキーワードや、一定のルールに基づいて行うエッジのスコアリングなどでグラフデータベースの厚みを増し、高度な解析能力を有する専門家がJupyter Notebookなどを利用したオープンで再現性のある解析を行い、ノートとデータ、できれば環境をDockerfileにまとめて、それをそのまま公開してしまう、という道もあるのではないかと思います。
そうなれば解析の環境から手法、データまで含めたある意味究極の情報公開になります。
担当者の方が述べておられるように、比較的簡単で面白そうなのはスイス・リークスのデータセットとの統合です。
彼らがグラフデータベースを利用し始めたのはスイス・リークスの一件の時からなので、すでにグラフデータベース化されているものがあれば、マージは比較的容易だと思われます。
それによりさらに大きな俯瞰図ができれば興味深いと思います。
彼女もこう言っていますし、続報を待ちましょう。
「
I think that we have just scratched the surface on how we can analyze the graph data.
私たちはグラフをどう解析できるのかという点について、まだ問題の表面をかすった程度の段階です。
Mar Cabra, ICIJ Data and Research Unit Editor
」
また、全データ公開は無理でも、ある程度加工された二次利用しやすいデータとして部分的にでも公開されれば、新聞社などのインフォグラフィックやデータビジュアライゼーションのチームが、各種公開データセット（地図など）とのマージを行って、さらに分かりやすい全体像を提示することも可能かもしれません。
■おわりに
いかがでしたでしょうか。
ちなみにここに列挙したツールは、Linkuriousを除き、私が可視化のサンプルを作ったCytoscapeもNeo4jも含めて全て無料で利用できます。
グラフというデータ構造はこの世界のあらゆるところに現れますので、それを機械で読める形にして格納すれば、このように様々な場面で使えるとわかっていただければ幸いです。
驚くべきことに、今回の作業は全てジャーナリストの団体が行っています。
彼らは内部にデータ解析班を持ち、その人々はデータの前処理のためのパイプライン作成から、商用クラウドサービスを利用した自前で計算機を持たない形でのデータ処理（おそらく多くはAWS上でのスポットインスタンス利用によるバッチ処理)、分散作業のためのシステム構築、データベースの構築、UIの選択など、ソフトウェア系の企業で行うようなことを自前でやっています。
世界の調査報道の先端はここまで来ているのかと感心しました。
同時に、ソフトウェアエンジニアのキャリアパスとしてこういうものも面白いのではないかとも感じました。
ビッグデータだの何だの雲をつかむようなキーワードが飛び交う昨今ですが、ここはひとつじっくりとJupyter Notebookに貴方のお気に入りのツールを組み合わせるデータ解析パイプラインを書き下し、何か社会にインパクトを与える解析・可視化作業でもしてみませんか？
今は技術と知識を身につければ昔では考えられなかったレベルの作業が、オープンソースソフトウェアやクラウドサービスを利用して、個人や小さな団体でも行える時代です。これをテクノロジーの民主化と呼ぶ人もいます。
最後にNeo4j社のCEOの言葉を引用しておきます。
The democratization of technologies to make sense of data at scale is an important part of a free and open society, and I'm proud of the role we play in that evolving landscape -- not only in the case of Swiss Leaks and the Panama Papers, but in solving future problems we can't even yet imagine.
大規模データを理解するためのテクノロジーの民主化は、自由で開かれた社会の重要な一部分である。そして私はその発展を続ける情景の中で我々が担えた役割を誇りに思っている。パナマ文書やスイス・リークスに限らず、我々がまだ想像すらできない未来の問題解決のために。
Emil Eifrem, CEO, Neo Technology
CC BY 4.0
4/9/2016 Keiichiro Ono
■4/10/2016 追記
この後、Neo4j社のブログに、更にテクニカルな部分について言及した記事が掲載されていました。
実際にCypherを使ってグラフの構築や修正を行うとどのような感じになるのか、コードと共に書いてありますので、更にグラフデータベースの詳細に興味にある方は是非どうぞ。
・Analyzing the Panama Papers with Neo4j: Data Models, Queries & More
質問や問題点などはkono at ucsd eduまでメールでお願いします。
Some rights reserved by the author.
※当記事は大野圭一朗氏のMediumのブログ記事を転載したものです。
』
【2016 異態の国家：明日への展望】
_
