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つのアルゴリズムを試してダメだったときは、他のツールを試してみる。それだけでも有意な分析につながるのではないかと思います。
自分はネットワーク可視化まわりでいろいろな道具や理論を試しているので、もしお困り事があればご相談ください。共同研究や受託研究、あるいはお仕事としての開発など、さまざまなアプローチでご協力できると思います。興味のある方はぜひご連絡ください。
以上で話を終わりにさせていただきます。ありがとうございました。