尾上洋介 on Data Visualization Japan

尾上洋介／ネットワーク可視化の世界

Sat, 28 Dec 2024 00:00:00 +0000

Data Visualization Japan Meetup 2024（2024年12月28日開催）における、尾上洋介さん（日本大学文理学部情報科学科教授）の講演です。ネットワークデータから知見を見出すために欠かせない、グラフ描画アルゴリズムの原理を体系的に紹介します。

「ネットワーク可視化の世界」というタイトルでお話しさせていただきます。尾上と申します。よろしくお願いします。

自己紹介

今、日本大学の文理学部というところで教育と研究をやっています。専門が情報可視化で、情報可視化の分野で研究をしたり、半分趣味で Web 関係の技術を追いかけて、可視化の技術も交えて Webサイトを作ったりといったことをずっとやっています。

これまでで最も世の中に見てもらった Webサービスとしては、中央省庁がやっている年間5000本ほどの行政事業を検索できる Webサイトがあります。これは矢崎さんとご一緒させてもらった仕事です。

情報可視化を専門にしていると、いろいろな共同研究のご相談をいただきますが、その中でも自分が最も得意としているのがネットワークの可視化です。今日はその辺りの話を中心にしていこうと思います。

ネットワークデータを可視化するということ

ネットワークデータは世の中にさまざまなものがあり、可視化することでネットワークの全体的な構造や局所的な構造を読み取る助けになります。また、ネットワークのデータは視覚的に興味を引きやすい――見慣れない、変わった図が出てくるので――という側面もあります。

たとえば、先ほどお話しした中央省庁の例。省庁の中の部局と、そこから事業によって支出している会社や他の法人との関係をネットワークで表したものです。色がついているものが省庁ごとの色分けで、周りにあるグレーの点が会社などを表しています。

これを見ると、全体的な構造として色が固まって見える。「同じ省庁だから近くに寄せる」といった処理はしていないのに、自然と同じ省庁で集まってくる。つまり省庁ごとにクラスターを形成していて、ある種、省庁ごとに得意先になっている会社が存在することを意味しています。

もう少し細かく見ると、たとえばオレンジ（文部科学省）が左の塊と右の塊の2箇所に分かれています。詳しく見てみると、片方は文部科学省の中でも研究・大学の方をやっている部局が集まっていて、もう片方は小中校の教育をやっているところ。社会福祉寄りの部局と研究寄りの部局とで、離れた政策領域を持つことが読み取れます。

このように、ネットワークを図にすることで、どういう構造があるのかを視覚的に読み取りやすくできるわけです。

ネットワークデータをどう作るか

可視化のためには、まずネットワークデータを作らなければなりません。ネットワーク可視化は意外といろいろなところで使えて、元々ネットワークになっているデータもあれば、ネットワークでないデータもネットワークとして構成すれば可視化できるようになります。

元々ネットワークになっているデータとは、基本的にはデータの集合の中に要素があって、2つの要素の間に何らかの関係があるものです。典型的には SNS のフォロー／フォロワー関係、EC サイトで誰がどの商品を買ったか。ほかにもさまざまな分野で、2つの間の関係性が表されていれば、それはネットワークの形になります。

一方、元々はネットワークでない表形式のデータでも、要素間の関係性を定義することでネットワークデータに変換できます。テキストデータは元々ネットワーク構造を持ちませんが、ある文書と文書のつながりや、文書の中に現れる単語と単語のつながりをうまく定義すれば、ネットワークデータとして扱えます。表形式のベクトルデータであっても、ベクトル同士がどれだけ近いかという距離や類似度を用いてネットワークに変換できます。

ただし、先ほどの行政事業のネットワークのように全データが膨大な場合は、1画面に表すことができません。そうしたときは、元の構造を失わないようにサンプリングや粗視化と呼ばれる処理をしてあげる必要が出てきます。

2つの表現 ― ノードリンク図と行列

作ったネットワークデータの表現方法は、大きく言うとノードリンク図と、それ以外（主に行列）の表現に分かれます。「ネットワーク図」と言うと、多くの人は左側のようなノードリンク図をイメージすると思いますが、実は右のような行列の形（ヒートマップ）で表す方法もあります。

こちらは『レ・ミゼラブル』という小説の登場人物を点で表し、同じ話の中で関わりがある人物を線で結んだデータです。ノードリンク表現では点がそれぞれの登場人物を表し、行列表現ではそれぞれの列や行が1人1人の登場人物を表しています。同一のネットワークデータであっても、まったく異なる表現ができるわけです。

今日は主にノードリンク図の方の話をしていきます。

視覚的属性と、その決め方

ネットワークデータの視覚的表現には、ノードの大きさ・色・ラベルの表示・画像の埋め込みなど、さまざまな属性があります。ノードだけでなくリンクにもいろいろな属性を持たせられます。

そこに何を反映させるか。データが元々持っている属性のほか、ネットワークの構造から計算できるもの――ネットワーク分析の分野で盛んに研究されています――たとえばノードの中心性（どのノードがネットワークの中で中心的な役割を果たしているか）や、ネットワークの中から塊を見つけるコミュニティ検出などの計算結果を、視覚的属性に反映できます。また、ネットワークではエッジを読み取るのが大変になりますが、それをまとめて分かりやすく表示するエッジバンドリングという方法もあります。

ツールとライブラリ

ネットワーク可視化を行うためのソフトウェアやライブラリを、主要なものだけ挙げておきます。

ソフトウェアでは、Gephi、（冒頭でご挨拶されていた大野さんが開発に携わられている）Cytoscape、そして少しマイナーかもしれませんが Tulip。この3つは GUI で画面を操作していくと、ネットワークの図を作ったり視覚的表現を加えたりできます。もう1つ有名なものとして Graphviz があり、こちらは主にコマンドラインで操作し、ネットワークデータを与えると図を作ってくれます。

ライブラリでは、Python なら NetworkX。ネットワークデータを扱うためのライブラリで、その中に可視化の機能も備えています。igraph は Python 版もあり、中身は C言語で実装されていて R 用の機能も提供されています。研究者ぐらいしか使っているのを見ないかもしれませんが、C++ で実装された OGDF というライブラリもあります。JavaScript（主に Web 上）なら、D3.js の1機能として提供されている d3-force があります。

ちなみに、React などのフロントエンド技術で可視化をするライブラリはたくさんあり、その中にネットワーク可視化の機能を持つものも結構ありますが、中身の多くはこの d3-force を使っていたりします。d3-force 以外で、いわばオリジナルのアルゴリズムを実装しているものとしては、cola.js や sigma.js が挙げられます。

なぜ「毛玉」になってしまうのか

とはいえ、いろいろなツールがあって、ネットワークデータが作れたから可視化してみよう――そこまでは簡単なのですが、意外と苦労されるのではないかと思います。経験のある方なら分かると思いますが、結構うまくいかないんですよ。

ネットワークの構造にもよりますが、うまくいかない可視化結果が出てきてしまうことがあります。ネットワーク可視化の研究ではヘアボール問題と呼ばれ、髪の毛の毛玉のようなものができてしまう。そうなると、そこから情報を読み取るのは難しく、有意な分析が困難になってしまいます。

ネットワーク可視化を活かして有意な分析をするには、さまざまな工夫が必要です。データ作成の方法、ノードやエッジにどういう情報を載せるかという視覚的表現に加えて、実はノードの配置をどう決めるかという配置アルゴリズム――専門的にはグラフ描画と言います――を、うまく選ぶ必要があります。そのためには知っている必要がある。ここから先は、そのグラフ描画アルゴリズムにどういうものがあるのかをざっと見ていきます。

グラフ描画とは

「グラフ」と言っても棒グラフや円グラフのことではなく、数学的な構造としてのグラフ、つまり頂点（ノード）の集合と、リンク・エッジと呼ばれる辺の集合の組を指してグラフと言います。

グラフ描画とは、このグラフを入力として、頂点の空間への埋め込みを出力するものです。画像として出力するなら2次元平面に埋め込む必要があるので、ここで言う「空間」は2次元平面などになります。一言で言えば、グラフを入力として座標を出力するもの。ネットワークの中のどういう構造を強調したいか、という用途に応じてさまざまなアルゴリズムが存在します。

非常にお世話になっている専門書として Handbook of Graph Drawing and Visualization があります。2013年刊なので10年以上前の本ですが、とてもいい本です。定価で買うと結構高いのですが、オンラインでプレプリント版の PDF が無料公開されています。すごくディープな内容で、私が博士論文を書いたときは、この本の1つのチャプターを半分も理解できたかどうか、というくらいでした。研究的にも実務的にもネタの宝庫のような本です。

実際、同じデータでも異なるアルゴリズムを適用すると、まったく別の結果になります。上の方は比較的似た結果でも、下の方はまったく違うアプローチになる。同じネットワークからでも、アルゴリズムの選び方によってまったく異なる可視化が得られるわけです。

力指向アルゴリズム（Force-directed）

先ほど紹介した主要なソフトウェアやライブラリの多くに取り入れられているのが、フォースダイレクト（力指向）アルゴリズムで、今では主流の1つです。

これはネットワークのノード間に働く力学的な力から、エネルギーの停留点を求めるもの。力学的にバランスの取れた点が、ネットワーク的に綺麗な配置だとみなして計算を行います。

そこで主に使われるのがバネの力です。バネの力はフックの法則として知られ、K(x − d) のように表されます。バネをイメージすると、引っ張ったり縮めたりしなければ自然な長さをしている。これを自然長と言います。そこから縮めると反発する力が働き、伸ばすと縮もうとする力が働く。力の大きさは自然長からの伸び縮みで決まり、自然長を d、実際の2点の距離を x とすると、x − d にバネ定数 K をかけたものが力の強さになります。

バネを使った力指向アルゴリズムは、大きく2つのモデルに分類されます。

1つがスプリング・エレクトリック・モデル。リンクで結ばれた頂点のペアをバネで結び、さらに結ばれているところも結ばれていないところも、ちょうどいい間隔を取るように電気の力（斥力）をかけて反発させ合ってシミュレーションを行います。

もう1つがスプリング・モデル。すべての頂点のペアをバネで結ぶ――リンクで結ばれているところもいないところも全部バネがあると想定して力の計算を行います。

スプリング・エレクトリック・モデルの特徴

多くのアルゴリズム（d3-force など）でスプリング・エレクトリック・モデルが採用されているのは、速いからです。計算量が小さい。元々はすべての頂点ペアの斥力の計算が必要で頂点数の2乗ほどかかりますが、Barnes-Hut 近似――物理学で天体のシミュレーションに使われる技術――を使うと、これが頂点数 V に対して V log V ほどに落ちます。相当する配列の処理と比べてもそれほど変わらず、実用的に高速に動きます。

歴史的には、1991年の Fruchterman-Reingold のアルゴリズムでは頂点数の2乗の計算量がかかっていたものが、2000年前後になって V log V で済むアルゴリズムの研究が盛んに行われました。代表的なものが **FM³（Fast Multipole Multilevel Method）**です。

また、Gephi で使われていることで有名なものとして ForceAtlas2 があります。論文が出たのは Gephi が普及したかなり後ですが、技術的な詳細が論文で説明されています。ちなみに ForceAtlas2 は厳密にバネと電気の力をシミュレーションしているわけではなく、グラフ描画に適した力を自分たちで作っていて、その結果として見やすい配置ができています。

デモ：バネだけでは重なってしまう

自分で作った資料ですが、Processing（の JavaScript 版）を使ってブラウザ上で力学シミュレーションを見せているものがあります。初歩的ですが、スプリング・エレクトリック・モデルでネットワーク可視化をする原理が分かるようになっています。

3つのノードがあって、その間にバネが働いていて、だんだん三角形に落ち着いていく。ではバネの力だけで斥力がないとどうなるかというと、力が釣り合う点でノードが重なってしまうんですね。だからノード間で反発させ合う必要がある。斥力を加えると、ノードが重ならずにうまい位置に配置されます。

これは特別なライブラリを使っておらず（描画に Processing のライブラリは使っていますが）、計算としては100行ちょっとくらいのコードで、簡単なネットワーク可視化のプログラムを実現できます。さらにノードが増えると1箇所に落ち着かないことがあるので、空気抵抗をかけて早く収まるようにする、といった工夫も説明しています。

ストレスモデル（スプリング・モデル）

自分がここしばらく研究として行っているのが、スプリング・モデル、あるいはストレスモデルと呼ばれるグラフ描画のアルゴリズムです。

バネの自然長としてノード間の理想距離を設定し、そのバネですべての頂点のペアを結びます。理想距離として一般的に採用されるのは、グラフ理論的な最短経路問題を解いた最短経路。それと、2次元に描画したときの距離がなるべく一致するように計算します。

このとき、すべてのバネの弾性エネルギーが最小化されるような配置を式で表せます。式の中の |Xi − Xj| が実際に描画した距離、d_ij が理想の距離です。つまり、実際の距離と理想の距離の2乗誤差を最小化する問題として、ネットワーク可視化を考えることができます。

ただ、この最適化問題は簡単ではなく、非線形最適化問題に分類されます。これを最小にする座標を得るのは理論的に非常に難しい。もう1つの欠点として、スプリング・エレクトリック・モデルと比べて計算量がかかります。どこでかかるかというと、グラフ理論的最短経路を求めるところで、頂点数の3乗、あるいは頂点数の2乗×log V ほどの計算量がかかってしまいます。

主要なアルゴリズムは大きく4つあるので、順番に見ていきます。

① Kamada-Kawai 法

ストレスモデルとともに最初に登場したのが Kamada-Kawai のアルゴリズムです。他のアルゴリズムと比べたときのアプローチの特徴は、ノードを1つずつ動かすという点にあります。

デモで動きを見てみましょう。最初にごちゃっと適当にノードを配置してしまい、そこからノードを1個ずつ、そのノードにとってストレスが最も小さくなる位置を計算で見つけて動かしていきます。アニメーションのため1個ずつ動かしているので時間がかかって見えますが、だんだん進んでいくとネットワークの形が出てきて、緑色のノードがこの辺りに固まってきます。

（大野さんが補足してくださっていますが、頂点数の3乗はコンピューターで計算するには結構大変で、ノード数にもよりますが、数百ノードなら問題なく動きます。それが数千を超えるようなネットワークになると、数分では下らない、下手をすると数時間待つような場合もあり得ます。）

1個ずつ動かすのは、結構まどろっこしいですよね。実際に計算するときは最終結果だけ出ればいいので、こんなに1個ずつ動かすことはありません。それに、1つずつ動かしていくので、「全部を一度に動かせたらもっといい配置ができるのに」という場合も生じてしまいます。

② ストレス・マジョライゼーション

そこで後に登場したのがストレス・マジョライゼーションです。マジョライゼーションはあまり馴染みがないと思いますが、最適化の方法で、優関数法（マジョライゼーション・テクニック）を用いてストレス関数を最小化する方法です。Kamada-Kawai から15年ほど経ってから登場しました。

デモを見ると、先ほどと比べて全体が一気に動いて、綺麗な位置に落ち着いていきます。だんだんいい位置に落ち着いて動かなくなる。エネルギーが最小になる点を数学的に計算しながらノードを配置していく方法です。

これについては自分の記事で理論的な解説も書いているので、興味のある方はぜひご覧ください。Python で実装するとどうなるか、というのも書いていて、これも意外と100行いかないくらいで実装できます。

③ 確率的勾配降下法（SGD）

そこからまた十数年経って、画期的なグラフ描画アルゴリズムが登場しました。

最近の機械学習ブーム、特にニューラルネットワークで、うまく学習するために行列のパラメーターを決める最適化の方法として**確率的勾配降下法（Stochastic Gradient Descent, SGD）**が用いられています。実は2018年の論文で、これがグラフ描画に対しても非常に有効だということが示されました。

動きを見てみると、見た目としては最初すごくガチャガチャと動いていて綺麗とは言いがたいのですが、だんだん動きを小さくしていって、落ち着いたところがすごくバランスのいい配置になります。

何をしているかというと、ネットワーク中のノードのペアをランダムに取ってきて、その2つのノードが理想距離になるように動かす。それをランダムな順番で繰り返していくと、先ほどのような動きになります。

「そんな適当でいいのか」と思うかもしれませんが、これが非常に有効なんです。マジョライゼーションの方法では、最初にどうノードを配置するかによって最後に落ち着く形が決まってしまう。だから初期配置が悪いと、綺麗な結果にならないことがあります。それに対して SGD を使った方法では、ランダムに動かす分、局所最適解に落ちにくく、いいレイアウトが得やすいことが明らかになりました。

実装が簡単なこと、そして後で紹介する2次元平面以外への描画といった拡張が簡単なことも、この方法の特徴です。

④ MDS（多次元尺度構成法）

もう1つ典型的な方法として MDS があります。

説明し損ねましたが、ストレスモデルではノードペアの違反がどれだけ重要かという重みをかけています。この重みがないバージョンを解くための方法が MDS です。

動かしてみると、他の方法と比べて見た目があまりよろしくありません。なぜかというと、単純にノード間の理想距離だけで配置を決めてしまうので、距離関係が同じノードが同じ座標に行ってしまう、といった問題が生じるためです。

なので MDS を使ったグラフ描画は単体ではあまり有効ではないのですが、この配置は初期配置によらず一定に決まります。したがって、初期配置を MDS で決めてしまって、他のグラフ描画アルゴリズムに用いる、ということが可能になります。

グラフ描画と次元削減の関係

MDS は実は次元削減手法の1つで、グラフ描画と次元削減には密接な関わりがあります。MDS によるグラフ描画は古典的 MDS とまったく同じですし、非古典的な MDS（代表的にはメトリック MDS）の実装にはマジョライゼーション・テクニックが使われていて、実はそれをグラフ描画の方に持ってきた、という位置付けになっています。

逆に、次元削減の方法にグラフ描画やバネを用いたアプローチが用いられることもあります。グラフ描画は、高次元のネットワークデータを低次元へ埋め込んでいる、と解釈することができるわけです。

ストレスモデルの拡張

ここからは、スプリング・モデルの拡張についていくつか触れます。

SGD が登場する以前は「どうやってストレスが最小の点を見つけるか」という最適化問題としての研究が盛んでしたが、ストレス関数を最小化するという課題は、ある意味 SGD の登場で決着がつきました。したがって、これから進んでいくストレスモデルの研究は、それをどううまく拡張するかというところになります。

パラメーターで見た目が変わる

単純にストレスモデルと言っても、パラメーターの決め方で描画結果が変わります。たとえば同じネットワークデータでも、辺の長さに緩急をつける――大事な辺は短く、クラスター同士をつなぐ辺は長く――としたものが左（重み付きエッジ）、すべて一様に同じ長さにしたものが右です。左の方が、グラフの全体的な構造と局所的な構造が強調されて見えます。

制約付きレイアウト

ネットワークを可視化するとき、さまざまな制約を加えたいことがあります。ノードを階層的に配置したい、ノードが重ならないように配置したい、など。これを得意としているのが cola.js です。

たとえば、向きのある辺がなるべく上から下向きになるように配置する制約を入れながらストレスモデルを解く。あるいはノードのグループがあって、グループ同士が重ならないように箱で囲い、その箱同士が重ならないように配置する。ほかにも、ノード同士が近すぎるとラベルを表示している場合に見えなくなってしまうので、重ならないような配置にする、といった制約を入れてレイアウトすることが可能になります。

計算量への対処 ― ピボット

ストレスモデルの大きな欠点の1つが計算量の問題です。

デモとして、SGD を用いて1000ノードほどのネットワークを描画しています。ただ1000ノードで頂点数の3乗となると相当な時間がかかってしまうので、すべての頂点ペアの座標を計算するのではなく、ピボットと呼ばれるいくつかの頂点からだけ最短経路を求めます。

ピボットの数を少なめに設定して動かしてみます。1000頂点中50の頂点だけを選んで動かすと、まだごちゃごちゃしています。100にしても、まだ少しごちゃっとしていますね。200にすると、なんとなくこの辺りに輪のある構造が見えてきて、300にするともう少し綺麗になり、いくつかの輪が見えてネットワークの全体的な形が見えてきます。

つまり、どれくらい近似をするかによりますが、描画品質を多少犠牲にしてでも実行時間を削減することが可能になります。

2次元平面以外への描画

最後の話題として、2次元平面以外での描画も紹介します。代表的なものとして球面・双曲面・トーラスがあります。

球面では、球そのものは表示していませんが、球面上にネットワークを配置します。

双曲面は情報可視化で時々用いられるもので、外側に行くほど広がっている空間を、外側を縮めることで描いています。インタラクションによって、たとえば右の方にあるノードを中心に持ってくると、その辺りがズームして拡大されるように見える。全体像を保ちながら注目しているところだけ拡大表示する、魚眼レンズのような効果が得られます。

トーラス空間はドーナツ型の空間で、それを平面に切り開いたものです。ドラクエ3などの世界地図をイメージしてもらうといいと思いますが、平面の右端と左端、上端と下端がそれぞれつながっていて、上に突き抜けると下から出てくるという空間でグラフ描画をします。1個分の領域が上下左右に繰り返されていて、注目したいところに移動していくことが可能になります。

球面やトーラスのようにループする空間になっていると、1箇所にノードが固まってしまうことを避けて、全体的にバランスの取れたレイアウトができる場合があります。

どこで使えるか

ここまで紹介したアルゴリズムがどこで実装されているかを簡単にまとめておきます。

Fruchterman-Reingold（スプリング・エレクトリック・モデルの最初のもの）… NetworkX、Graphviz
ForceAtlas2 … 元々 Gephi で実装され、現在は NetworkX や sigma.js でも利用可能
Kamada-Kawai … NetworkX
ストレス・マジョライゼーション … Graphviz（レイアウトを選択すると利用できます）

先ほどデモで紹介したものは、私が片手間に作っているライブラリです。人に使ってもらえるようなドキュメントの整備はまだ不十分ですが、いろいろ実験して実装しているので、利用されたいという方がいればお声かけください。

まとめ

今回は「ネットワーク可視化の世界」ということで、特にグラフ描画アルゴリズムについて紹介しました。

グラフ描画のアルゴリズムには本当にいろいろなものがあり、アルゴリズムの選び方によって可視化結果はまったく異なってきます。ネットワーク可視化を試してみたけれどうまくいかない、という場合でも、アルゴリズムの選び方によって綺麗な結果が出ることがあります。目的に応じて適切なアルゴリズムを選ぶこと、そしてアルゴリズムだけでなくパラメーターをどう設定するかによっても、ネットワーク可視化の出来は変わります。

代表的なものはさまざまなツールに実装されているので、1つのアルゴリズムを試してダメだったときは、他のツールを試してみる。それだけでも有意な分析につながるのではないかと思います。

自分はネットワーク可視化まわりでいろいろな道具や理論を試しているので、もしお困り事があればご相談ください。共同研究や受託研究、あるいはお仕事としての開発など、さまざまなアプローチでご協力できると思います。興味のある方はぜひご連絡ください。

以上で話を終わりにさせていただきます。ありがとうございました。

尾上洋介／ビジュアライゼーションとモダンWeb開発

Wed, 29 Dec 2021 00:00:00 +0000

Data Visualization Japan Meetup 2021（2021年12月29・30日開催）における、尾上洋介さん（日本大学文理学部情報科学科准教授）の講演です。行政事業データベース JUDGIT! の開発経験をもとに、可視化アプリケーションを支える Web 技術の現在地を紹介します。

「ビジュアライゼーションとモダンWeb開発」ということで、普段やっていることを振り返って喋ってみようと思います。

自己紹介

日本大学文理学部情報科学科で准教授として教育・研究をしています。実データを触る関係で企業からも声をかけていただくことが多く、現在は株式会社帝国データバンクの客員研究員として、可視化のデザインやシステムのデザインを行っています。

可視化と Web が好きです。私が可視化を始めたのは2013年ごろ、D3.js が流行りだしたタイミングでした。もともとオペレーションズ・リサーチ（最適化） の研究をやっていて、いろいろあってドクターから可視化の分野に踏み込むことになったのですが、教授の下にいる若い先生に「これからは可視化も Web だよ」と唆されて、可視化と Web はその時期からセットで取り組んできました。

アカデミックな研究とエンジニアリングの両立を目指していて——新しいアルゴリズムや視覚的表現を作る基礎研究、可視化技術を各分野に適用する応用研究、可視化というキーワードで分野横断的な問題解決に取り組む研究、といったことをしています。

私は、**可視化とは「人とデータが向き合う場のデザイン」**だと考えています。アプリを作るのか、デバイスを用意するのか——どういう環境を整えたら、データに向き合っている人がそれを行動に結びつけられるのかを考えて取り組んでいます。

**デザイン方面は全然明るくなく、完全にエンジニアの方面から可視化に取り組んでいます。**ソフトウェア開発、データベース、システム設計を勉強したり、学生時代に Web 開発のアルバイトをして実務的なシステムの作り方を学んできました。

NHKスペシャル「検証コロナ予算 77兆円」

昨日放送された番組に協力させていただきました。データを分析して提供したり、一緒に議論したり、専門家として意見を出すということをやりました。

番組は NHK プラスで見逃し配信されています。また番組と併設してコロナ予算をいろんな角度から見る Web サイトも公開されていて、こちらは矢崎さんがかなり気合いを入れて関わっているのでぜひご覧ください。

JUDGIT! ― 行政事業のデータベース化

なぜコロナ予算の分析に携わることになったかというと、2018年末ごろから行政事業をデータベース化して可視化することに取り組んでいたからです。

現在、中央省庁は小さい委員会なども含めると21いくつかありますが、そこで行われる事業は年間約5000件あります。

**省庁の縦割りで、別の組織が何をやっているのか見えない。**予算的な観点で全体を管轄する財務省ですら、担当外はあまり詳しくなかったりする。行政事業の全体像の把握は非常に困難でした。もはや年間約5000件の事業の全体像を把握できている人間はいなかったのではないかと思います。

行政事業レビューシート

情報自体は「行政事業レビューシート」という、各事業の自己点検のための書類として毎年出されていました。Excel で書かれていて、担当の人が埋めていくという形です。

これをコンピュータで扱いやすいように、記述が曖昧な部分を整理してデータベース化し、閲覧できる Web サイト JUDGIT! を公開しました。

レビューシートは実に多種多様な情報を含んでいます。

数値情報：予算額、どれだけのお金がついてどれだけ使ったか
定量評価：どういうアウトカム・アウトプットを設定してどれだけ実現できたか
定性的なテキスト：事業の概要、有識者からのコメント
関連情報：他の事業との関連、どういう会社や民間団体に仕事を依頼していくら出しているか

データベース化したことで、もともと一つの事業の自己点検に使われていたものを、全事業横断で調べられるようになりました。

予算宇宙 ― 事業の関連ネットワーク

番組で「予算宇宙」という形で取り上げていただいたもののベースになっているのが、このネットワーク図です。

事業の文章をニューラルネットワークで処理して文章同士の近さを計算し、近いものをつなぐとネットワークが出てきます。

そうすると——経済産業省、厚生労働省といったそれぞれの省庁が事業を展開しているわけですが、文章の書きぶりから、結構似たことを違う省庁でやっているものがあったりします。

それはある意味「重複した無駄」かもしれないし、あるいはそれらを連携することでより効果的な事業を展開できるのではないかという示唆にもつながります。

左の方に大きな島があって、このあたりは経産省・農水省・国交省などの事業がつながっています。いわゆる社会課題系のものは多面的で、いろんな見方から問題解決に取り組まないといけないので、他省庁でも同じような課題への対策が行われている。それを見て「もっとどうやったらよくできるのか」を考える材料にできます。

個人的に面白かったのはICT 関係の島が孤立してあったこと。**ICT は本来、社会課題解決の根幹に来なければならないものだと思うのですが、大きな島から離れて出てきてしまっているのは、正直なところ「日本らしいな」と。**ある意味、日本の ICT が抱える課題でもあるのかなと感じました。

きっかけはプロトタイプだった

最初からこういうものを作ろうと思っていたわけではありません。

共同運営している団体から「東京オリンピック予算の検証がしたい」と持ちかけられたのが2018年ごろでした。「レビューシートという Excel のシートがあるんだけど、これから何とかできないか」と。

行政の事業データや政策には明るくなかったので、**まずは自分がデータの理解を深めるためのビューアを作り始めた。**いくつか検索や簡単な可視化ができるようにしたら、それがプロジェクトメンバーに思いのほか受けが良く、「東京オリンピック予算の検証は抜きにしても、これ自体を世に出そう」ということになって本格的に仕上げて公開しました。

これをやって感じたのが、プロトタイピングをして、ドメインの専門家と相互理解をして、それを世に出すことの重要性です。

**私が可視化の専門家として、行政事業というドメインの知識を獲得する。同時に、データを使って何かをしたいドメインの専門家が、可視化やデータ分析の技術に触れる。**プロトタイプを作って開発していくのは非常に良い体験でした。

こだわったこと

軽快に、簡単に——Web サイト自体の質を高めようと工夫しました。

最近は国も力を入れて行政系からもいいウェブサイトが出るようになっていますが、古いイメージだと行政系のサイトは重くて硬い雰囲気がある。それを払拭して行政事業を身近にしたいという気持ちがありました。

もう一点、データが Excel や PDF で公開されていたため、普通の人が調べ物をした時にそういう情報に行き当たりにくいという課題がありました。まず行政事業という情報自体を、検索エンジンのクローラーがしっかり拾ってくれるようにしたい。

検索エンジンフレンドリーにコンテンツを作ることで、身近なところから行政情報につながることを意識しました。

Google Analytics のアクセス状況を見ると、4分の3がオーガニックサーチ——ほとんど検索流入です。「JUDGIT! というサイトを知っていたわけではないけれど、どこからともなくたどり着く」方がほとんどです。

ユーザーを見てみると、**もともと行政に強い関心がある人というより、平日昼間のアクセスが多い。**仕事で調べ物をしていて、たまたま行政の情報にたどり着く、という方が多いことが分かりました。

公開してよかったこと

**「こういうものがあるんだ」と、行政の情報に気軽に触れられるようになった。**その結果として、今回のコロナ予算の NHK スペシャルのように「もっとこういうことできませんか」という問い合わせをいただくようになりました。

**元の Excel ファイルの束だと、そこから何か分析をしようという気は起こらなかったと思う。**それがデータベース化されていることで、もっと次のアイデアが生まれてくる。実際にユーザーにデータに触れてもらうことで、さらに次の良いアイデアに進むことができる——これが作って公開してよかったことです。

可視化とは何か

改めて考えてみます。

「可視化とは」と言った時、普通のビジネスパーソンが思い浮かべるのは「棒グラフとか円グラフとか、いろんな表現があるよね」ということだったり、「Tableau で可視化できるよ」「matplotlib で可視化できるよ」というツールの話だったりします。可視化を専門としないデータサイエンティストもよく言います。

でも、これらを使いこなすことが可視化なのかというと、多分そうではない。

視覚変数とデータの対応づけ

表現可能な視覚変数は一通りあります。位置、大きさ、色、模様、形——特にコンピュータの上で使える視覚変数は、そんなに大した量がない。

コンピュータグラフィックスは結果的に複雑な図形を描けますが、基本は多角形を描く、線分を引く、点を打つ、それくらい。

逆に言うと、可視化はそういった基本的な要素をデータと結びつけることで成り立っています。

折れ線グラフで線の高さが何を表しているのか——「人口」というデータの空間から、「座標」という視覚変数の空間へのマッピング。これが可視化を成り立たせることの根幹にあるわけです。

データを視覚的に表現する限界

実際のデータは行数も列数も無数にあり、大規模化・複雑化しています。

行数（レコード数）の限界は非常に分かりやすい。8Kディスプレイ——実際に使われている最大の解像度でも、約3200万ピクセルです。

仮に一要素を1ピクセルで表せるとしても（そんな可視化をしたら怒られるとは思いますが）、そのピクセル数分の要素しか表現できない。

**3200万要素は、ビッグデータの時代からすると非常に些細な量です。**何億レコードとなると桁がいくつも足りない。せいぜい一要素100ピクセルは使いたいと思うと、表現できる情報の桁はさらに減ります。

列（データのフィールド） で考えても、視覚的表現に割り当てられる変数はごく少数です。一つの円に対して割り当てられるのは、座標、半径、色——たかだかそれくらい。でも何十列とかになってくると、当然すべてを見渡せなくなります。

だから「選ぶ」必要がある

複雑で大規模なデータには——

可視化する対象を行なり列なりで選ぶ
統計的に集計して統計情報を出す
列方向でまとめる次元削減
行をまばらに取り出すサンプリング
データ全体の傾向を失わないように粗く表す粗視化

といったアプローチが必要になります。

それでもなお「見せるものを選ばないといけない」のが課題です。見せられないものを補いたかったら、もうインタラクションくらいしかない。

検索・絞り込みのインターフェースをつける
メインのビューだけでは捉えられない情報をサブのリンクトビューで表す
点をクリックすると詳細が見えるドリルダウン

ただ、そういうインタラクションを実装していくと開発コストが高くなり、開発自体が複雑化していく。それとどう向き合うのかを考えなければなりません。

なぜ Web で作るのか

可視化システムをユーザーにどう提供するか。デスクトップアプリと Web アプリの比較です。

Tableau のようにパッケージをダウンロードしてインストールするものに比べて、Web アプリはインストール不要で、ブラウザさえ動けば利用可能。

**ただし性能面では Web アプリはデスクトップアプリにかないません。**実装言語の性能上の問題も、ハードウェア機能の利用が限られる制約もある。パフォーマンスとデリバリーのしやすさにトレードオフがあるわけです。

Web の利点

第一に、ユーザーに届けることが簡単になる。

私は他の大学や研究所と共同研究することが多いのですが、忙しい研究者に「こういうのを作ったから遊んでみてください」と言う時に、「このソフトをインストールしてこの手順でセットアップしてください」と言うと、なかなかやってくれない。

**Web で提供していれば「このページにアクセスしてください」で済む。**向こうもハードルが低くてすぐ利用してもらえる。すぐ利用してもらえるとフィードバックがもらえて、次の機能改善につながる。

**もう一つは、今のアプリはリッチだということ。**日常的に触れるアプリケーションはそこそこリッチで、そういうリッチな UI を個人や数人のチームで片手間に開発するのは大変。Web の技術に乗っかることで、ユーザーにも馴染みのある UI を、そんなにコストをかけずに提供できます。

補足 ― オフラインで動く Web アプリ

スライドに入れられなかったので補足すると、実はインターネット接続がなくても使用できる Web サイトがあります。

さすがに最初の1回は訪れておく必要がありますが、Service Worker という技術を使えばオフラインで動く Web アプリケーションを作ることができます。

私も一時期そういうものを作っていました。共同研究先がインターネットもないような場所にフィールドワークに行くので、「可視化アプリをネットに繋がらなくても使えるようにならないか」というニーズがあったんです。興味のある方はぜひ調べてみてください。

トレンド① 宣言的UI

2010年前後から HTML5 が言われ出し、HTML を単純にコンテンツを表示させる土台から、アプリケーションのプラットフォームとして成熟させていこうという動きがありました。2010年代はなかなかカオスでしたが、その中で発展してきたのが Web フロントエンドのフレームワークです。

**Web の表現力が高まった一方で、それは開発コストを高めることでもある。**従来 PHP や Ruby on Rails でバックエンドでやってきた処理を、リッチな Web 体験のために前（ブラウザ側）に持っていく動きがあったので、フロントエンドの開発コストが大きくなりました。

10年ほど前は jQuery が流行っていて「プラグインを入れると簡単におしゃれな機能を加えられます」という感じでしたが、それでは到底太刀打ちできない規模のアプリケーションがブラウザ上で動かされるようになってきた。

そこで React、Vue、Angular、Svelte といったフレームワークが使われるようになります。

今回紹介するのは React ですが、そこが取り入れているトレンドが「宣言的UI」です。

UI = f(state) と表されます。UI があってユーザーが操作すると、アプリケーション内部が持っている「状態（state）」が変化し、その結果 UI が更新されてユーザーが見る——UI 構築と状態管理を分離してアプリケーションを構築していく流れです。

React は Facebook 社が開発するライブラリで、JavaScript の拡張構文 JSX を利用します。JavaScript の関数の中にタグが出てくるので、慣れないうちはちょっと気持ち悪い気がするかもしれません。

Facebook には意外と関数型言語や凝ったプログラミング言語が好きな人が昔からいて、関数型言語を利用した開発効率の向上に研究的に取り組んできた流れがあります。

大雑把に言うと——データがあって、それを UI のどこに埋め込むかを宣言的に書くことで、データと UI の関係を分かりやすくする、というのが一つのアプローチです。

React と可視化

可視化は結局、元のデータと、それに対するユーザーの興味関心が操作に反映されて出てくるものです。React はそのまま SVG のタグを書くこともできます。

上の方にデータがあって、それを SVG のタグの中にどうやって埋め込むかを考えればいい。

可視化ライブラリは古くは D3.js、最近は関数を一つ呼び出せば綺麗なチャートを描いてくれるものもたくさんあります。でも「有り物のチャートでは満足できない」という人は、D3.js のような低レイヤーの API を使って可視化を組み立てていく。そういう時にこのアプローチが有効になります。

**私は D3.js で UI を構築するということはもうやっていません。**D3.js 自体はしょっちゅう使いますが、UI の構築・可視化の構築には React を使うというアプローチをずっと取ってきました。

D3.js を「可視化のオールインワンのパッケージ」として使うのではなく、「データ変換のためのツール」として使うアプローチです。

先ほどの「データと視覚要素をどう結びつけるか」でやっていたのは、実は線形変換です。d3.scaleLinear はよく使われるのではないでしょうか。そういうものでデータと視覚変数の対応関係を作り、必要なコンポーネントに渡してマッピングをする。

**新しく始める際のポイントは d3.select を使わずにやってみること。**おそらく d3.select から勉強された方が多いと思いますが、宣言的UIで可視化コンテンツを作ろうと思ったら、まず d3.select を使わないという縛りプレイから始めるといいかもしれません。

もちろん完成された D3 のコンポーネントを持っていたり既存ライブラリを使いたい場合は直接使った方が効率的ですし、必要になれば React の中に d3.select を組み込むこともできるので、そんなに怖がらずに。「まだ d3.select で UI 構築しているよ」という人は、結構違った世界が見えるかもしれません。

トレンド② パフォーマンスと Next.js

本当は昨日のリリースに間に合わせたかったのですが、パフォーマンスを意識した新しい技術スタックで作るアプリケーションにチャレンジしていました。

新型コロナウイルス感染症対応地方創生臨時交付金——内閣府が地方自治体に向けてコロナ対策の補助金を出すので提案を出してください、というものです。全国約1800の自治体から集められた6万件ほどの事業情報が Excel で公開されていたので、データベース化しました。

自治体の数が多いので事業数が多く、地域性も見たいということで、地図を含むいろんな観点から検索できるダッシュボードを開発しました。

「緊急経済対策との関係」が19個ほどのカテゴリーから選択されていたり、「地域未来構想20」との関係が書かれていたりします。医療関係、中小企業対策、環境、地域経済の活性化——カテゴリーごとにいくら使われているかを表示し、絞り込むと「どの自治体がどれくらいの金額の事業を行っているか」の地図表示もリアルタイムに連動するようにしました。

パフォーマンスの原則

データ容量が大きくなると Web サイトの中身がなかなか表示されず、ユーザーは見るのを諦めて離脱すると言われています（これは可視化に限らず Web 一般の話です）。

パフォーマンス、結局「時間」というのは「距離 ÷ 速さ」なんですよね。

地球上は光ファイバーで通信されていますが、残念ながら「速さ」の方の光は速くならない。なので「距離」をいかに縮めるかが、どんなレベルのパフォーマンスでも問題になる。

CPU の高速化でも、**レジスタからメモリまでの距離が遠いので近くにキャッシュメモリを置く。**Web でも、海外だけにサーバーを置くのではなく日本にもサーバーを置いてコンテンツを早く届ける。

メインのアプリケーションサーバーとデータベースがあって、そこまでの距離が遠いのが問題なので、ユーザーのより近くにエッジのサーバーを置く必要がある。

でも、可視化のデザイナーがここまでフルスタックにエンジニアリングして可視化アプリを作るのはなかなか大変じゃないですか。

そこで CDN（コンテンツデリバリーネットワーク）の利用で Web サイトの体験を良くすることが、より身近に手が届くようになっています。

React ベースの Next.js は、**Web サイトのローディングパフォーマンスを向上させる仕組みにかなり力を入れています。**これを作っている Vercel という会社がホスティングサービスを提供していて、そこに Next.js のアプリを載せるだけで勝手にこうした恩恵が受けられる。

もう一点のメリットとして——可視化コンテンツを表示するために毎回データベースを叩いて集計するとコストが小さくない。一方で見られるデータは毎回同じなはず。Next.js や Vercel はキャッシュの仕組みを持っていて、データベースへのアクセス回数を落とせます。

可視化アプリケーションでも、こういう技術トレンドが取り入れられていくのではないかと思います。

トレンド③ WebGPU と WebAssembly

キーワードだけになりますが——

WebGPU

先ほど説明されていた deck.gl は WebGL ベースのライブラリですが、もう一歩先のグラフィックスAPIの策定が進んでいて、それが WebGPU です。

OpenGL はコマンドを発行するコストが大きいという問題があり、それを取り払うために Vulkan や Apple の Metal といった低レベルなグラフィックスAPIが策定され使われるようになりました。Web もそれに準じた API を提供しようと進んでいます。

大きな違いの一つが GPGPU が可能になること——GPU で計算できるようになる。

ブラウザ上で大きなデータと向き合う時、描画だけでなくある程度クライアント側で処理しなければならない。そこそこの量となると複雑な計算をクライアント側で高速にやる必要が出てくるので、有力な選択肢の一つとして上がってくるのではないかと思います。

WebAssembly

Web は文化が独特なので、Web の上で使える可視化ツールが他に持って行っても使いにくいという問題があります。

そこで WebAssembly ——ブラウザ上で動作するバイナリフォーマットです。これを使えば **C++ や Rust など他の言語からコンパイルしてブラウザ上で動くプログラムを生成できる。**すでに多くのブラウザで動作する実用的な技術です。

私もこれを利用していて、グラフのレイアウトを計算するライブラリを、論文を書くためにも作らなければいけないし、アプリを開発するためにも作らなければいけない。それを両立させるために Rust で実装して、研究用のベンチマークと Web アプリ開発の両方に使ったりしています。

可視化は総合格闘技

技術的にもいろんなことを考えなければいけないし、ドメインエキスパートと協業するのも大変です。

可視化という自分の主軸を置きながら、他の技術・他のドメインにチャレンジすることがどうしても必要になる。データを収集して加工して可視化してシステムを構築する——本当にいろんなレベルのスキルが必要です。

でも、これに恐れずチャレンジしてほしい。私は可視化は総合格闘技だと思っていて、情報科学プラスアルファの周辺分野の幅広い知見を学んで実践していく、チャレンジングな分野だと思っています。

ドメインの専門家と協業するという意味では、本当に「壊すことを恐れない」——たくさん作ってたくさん壊していいと思います。

これは企業と一緒に作っていたものの事例ですが、結構何回も作り直しています。「もっと違うものが見たい」「作ってみたけれど見たいものは違った」——作っては見せて意見をもらってまた直す。

**そういうプロトタイピングを通じてドメイン専門家との相互理解が生まれる。**可視化の専門家としてはドメイン知識とユーザーニーズが得られるし、同時にドメインの専門家も「可視化によって何ができるのか」「分析によって何ができるのか」の理解が深まります。

学生の取り組み

うちのゼミでは、ガチガチの理系の学生でもプログラミングや情報科学だけでなく、「デザインをどう考えるか」のワークショップを一緒に勉強したり、データを頑張って取ってきて整形してデータベースにしてシステムを作ることに取り組んでもらっています。

一例として、今の4年生が開発している「世界の音楽トレンドの可視化」。Spotify で各国で再生された曲のランキングと詳細情報を使って、SPA として可視化コンテンツを作ってもらっています。

この1年間、完全にオンラインでやっていたのですが、オンラインのツールをすごく活用してくれていて、ユーザーストーリーマッピングをやってみるなど、議論を重ねてくれました。いろんな観点から音楽トレンドの情報が可視化できるコンテンツになっています。

取り留めのない話でしたが、可視化をちゃんとやっていこうと思うと、どうしても可視化だけにとどまることはできないのが現状だと思うので、技術的にも領域的にも広く考えて取り組んでいけたらと思っています。

以上になります。ありがとうございました。

尾上洋介 on Data Visualization Japan

尾上 洋介／ネットワーク可視化の世界

自己紹介

ネットワークデータを可視化するということ

ネットワークデータをどう作るか

2つの表現 ― ノードリンク図と行列

視覚的属性と、その決め方

ツールとライブラリ

なぜ「毛玉」になってしまうのか

グラフ描画とは

力指向アルゴリズム（Force-directed）

スプリング・エレクトリック・モデルの特徴

デモ：バネだけでは重なってしまう

ストレスモデル（スプリング・モデル）

① Kamada-Kawai 法

② ストレス・マジョライゼーション

③ 確率的勾配降下法（SGD）

④ MDS（多次元尺度構成法）

グラフ描画と次元削減の関係

ストレスモデルの拡張

パラメーターで見た目が変わる

制約付きレイアウト

計算量への対処 ― ピボット

2次元平面以外への描画

どこで使えるか

まとめ

尾上 洋介／ビジュアライゼーションとモダンWeb開発

自己紹介

NHKスペシャル「検証 コロナ予算 77兆円」

JUDGIT! ― 行政事業のデータベース化

行政事業レビューシート

予算宇宙 ― 事業の関連ネットワーク

きっかけはプロトタイプだった

こだわったこと

公開してよかったこと

可視化とは何か

視覚変数とデータの対応づけ

データを視覚的に表現する限界

だから「選ぶ」必要がある

なぜ Web で作るのか

Web の利点

補足 ― オフラインで動く Web アプリ

トレンド① 宣言的UI

React と可視化

トレンド② パフォーマンスと Next.js

パフォーマンスの原則

トレンド③ WebGPU と WebAssembly

WebGPU

WebAssembly

可視化は総合格闘技

学生の取り組み

尾上洋介／ネットワーク可視化の世界

尾上洋介／ビジュアライゼーションとモダンWeb開発

NHKスペシャル「検証コロナ予算 77兆円」