「パナマ文書」解析の技術的側面

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（ドメイン固有言語）の一種です。グラフを検索するための単純なプログラミング言語のようなものだと考えてもらっても概ね正しいです。単純な例で言えば、