MIRAI Archive
京都⼤学未来創成学国際研究ユニット

International Research Unit of Advanced Future Studies(IRU-AFS)

No.2015-011＜講演録＞

京都大学基礎物理学研究所

研究会

京都大学未来創成学国際研究ユニット設置記念シンポジウム
日時2015 年 8 月 7 日（金）13：40－14：20

場所

コープイン京都

司会

三輪敬之（早稲田大学創造理工学研究科

教授）

講演

小林泰三（帝京大学福岡医療技術学部

准教授）

201

動的過程の計算論
三輪●続きまして、小林泰三さん。お願いいたします。
小林●ご紹介にあずかりました、小林と申します。私の題は「動的過程の計算論」です。
かたい題をつけてしまって失敗したなあと思うのですが。
私の所属は、今年からできた帝京大学の医療技術学部医療技術学科というところです。
ここではおもに授業をしておりまして、研究はあいかわらず九州大学の情報基盤研究開発センターで進めております。
私以外の講演者の方はみなさん名前の知られた大御所ばかりでして、私がいちばん若いと思います。ちょっと自己紹介させてください。

◇ ス ラ イ ド 2「 自 己 紹 介 」
私は立命館大学の池田研介先生の研究室の出身です。池田研究室にいるときには、金属微粒
子のモレキュラー・ダイナミクス（Molecular
Dynamics）をしていました。そこから九州大学に移りまして、九州工業大学の高橋公也さんといっしょに、なにか楽器を研究しましょうとい
うと、フルートだったら動く部品がないので、ぜんぶ流体音の範囲で話ができるのではないかということで、フルートの音がどうして出るのかという研究をしていました。
情報基盤研究開発センターにいるので、いろいろ計算機のこともしてきました。ご存じの方もいるかもしれませんが、ヴァイン・リヌックス（Vine Linux）という、大学でよくつ1

MIRAI Archive

No.2015-011

かわれているリヌックスがあります。むかしは、これの PPC カーネル（Power PC Kernel）
を担当していました。あるいは、Mac で eMacs か TeX（テフ）をつかって研究する人のためのディストリビューション（distribution）を 10 年以上、主としてやっています。
スライドには、計算関連で NAREGI や HPCI-AE と書いてあります。NAREGI（National
Research Grid Initiative）は 10 年くらい前に行なわれた国家プロジェクトで、グリッド・コンピューティング（Grid Computing）というものがありました。日本の各大学にある大きなスーパーコンピュータを連携して使えたら、もっと研究効果があがるだろうと。では、それをつなぎましょうということでした。
グリッドということばは、パワー・グリッド（電力送電網）に由来します。ふつうの電源のことです。どこでもプラグがあるので、電化製品はそこに差し込めばつかえる。
同じように、計算機もどこでもつかえるようにしましょうという触れ込みでした。しかし、いまそうなっていないことからわかるように、うまくいっていないのです。この講演は収録されているので、このへんの裏話も用意してきたのですが、割愛いたします。
これを引き継いだ HPCI というものがあります。ハイ・パフォーマンス・コンピュー
ティング・インフラストラクチャ（High Performance Computing Infrastructure）という名前です。これは神戸の理化学研究所にある京（けい）コンピュータを中心に、旧七帝大、筑波大学、東京工業大学をつないで有機的に使いましょうというものです。いまはやりのクラウドを使おうという話が出て、その担当をやれといわれて、ちょっと関わりました。今日お話しするのは、スライド 1 の青字のところにかかわることです。
そのほか、学部教育関連のことがらにも携わりました。あとで池田さんが話されるよ
うなお話です。また、坂東昌子さんや佐藤文隆さんが運営している NPO 法人、知的人材
ネットワーク・あいんしゅたいんにも所属しています。あとは、ちょっと前のことです
が、科学的なことについて法廷の現場に証人としてよばれたりすると、とんでもないことを証言させられそうになるという話がありました。弁護士、科学技術社会論の研究者、
東北大学の本堂毅さんといっしょに、法と科学に関係する研究プロジェクトにも在籍していました（JST-RISTEX プロジェクト

法と科学）。

◇ ス ラ イ ド 3「 『 動 的 な 』 話 題 の 対 象 」
2 日間、大御所たちのお話で内容の濃い議論をしてきてお疲れだろうと思いますので、素朴な話題になるようにスライドをつくりなおしてみました。
最初は計算科学の話です。流体音、フルート
からなぜ音が出るのかということです。楽器な2

MIRAI Archive

No.2015-011

ので音を変えますね。吹きながらフィンガリングをする。これは、まだきちんと計算できていない問題なのです。こんなこともまだできていないのが、われわれです。
計算は、計算機がきちんとつくられているからできるのであって、計算機を対象とした科学があります。フィンガリングなどをしようとすると、フルートのパッドを閉じているときと開いているときとでは、トポロジー（topology）が変わるのです。流体の計算をするときは、空間をこまかく切って計算する（メッシュ図）のですが、閉じたときは管と指のパッドがあるところがつながっているわけです。開けた瞬間に、前になかったものがメッシュに入りこむ。そういうところは微妙な問題がたくさんあって、そう簡単にできるものではない。
次に、計算機科学です。われわれがユーザとしてきちんと計算機を使えるようにする
ために、資源管理をします。プロセスは、動いているプログラムのことです。ストレー
ジは、ハードディスクや USB メモリのようにデータを溜めるところです。あとはネットワーク。ユーザも管理対象になっています。
ち ょ っ と 前 ま で は こ の へ ん で 話 を 閉 じ て い ま し た が 、 昨 今 は ビ ッ グ デ ー タ （ Big Data）やクラウドが情報インフラとして出てきて、計算機科学だけでは話が収まらないところにきています。
資源管理をするのですが、どちらかというとメタな感じです。たとえば、HPCI でしたら、各大学が計算機をたくさんもっています。それらがどういう状態になっているのかということの把握と管理と、スライドに書いています。
あとは、ビッグデータなどのサイバー・フィジカル・システム（Cyber Physical System、CPS）というものがあります。どういうものかというと、遠隔地にいろいろ置いてあるセンサからどんどんデータが集まってくる。これらを利用して、リアルタイムをまたほかのところで使いましょうと。
いま研究プロジェクトとしてあがっているのは、やはり医療系が多いです。患者さんに、いろいろと状態をモニタリングする機器をつけています。ふだんはふつうに生活していただく。なにか変動が起こったら、移動クラウドにデータがあがって、主治医のところに情報がゆく。そういうシステムをつくろうというプロジェクトがいくつかあります。交通量に関するものも多いです。このへんが盛んになって、予算がとりやすいこともあって、雨後の竹の子のようにボコボコと出てきています。
「これ、大丈夫かなあ」とぼくがいつも思うのは、こういうインフラは止められないということです。インフラとして深く日常生活に入りこんだら、止められないのです。
しかし、いまのコンピュータのシステムは、止めずにずっと連続運転してゆけます かと。
いちばん困るのは、OS のアップデートなどをするときです。ソフトウェアは、どんどんバグを修正して、機能を強化して、どんどん更新してゆく。そのときはプログラムを
3

MIRAI Archive

No.2015-011

止めますね。OS を入れ替えるときは、パソコンを落とします。そういうことができない状況のことを考えないといけないのに、不思議と議論されていない。大丈夫かなと思っています。
具体的で素朴な話をしていますが、けっきょくどうなのかというと、動的な話──ユーザがどのように計算機を使うのかというのを予測するのは不可能ですね。不確定なものに、どのように対応してゆくのか。そういうことをお話しし、議論するということです。では、具体的な話に入ります。

◇ ス ラ イ ド 4「 計 算 科 学 」
フルートの音がどうして出るのかという話です。ここからしばらくは、気軽に楽しんでいただけるかと思います。フルートそのものは唇が入るためにむずかし
いので、リコーダーをモデルにして計算します。リコーダーは、たんにフッと吹けば音が出るので、そうむ
ずかしいことは起こっていないとは思うのですが。

◇ ス ラ イ ド 5「 エ ア リ ー ド 楽 器 の 発 音 」
最初は、フッと吹きます。吹くと、歌口にジェット（jet）が出ます。ジェットが出て、反対側のエッジのところにぶつかる。すると、それだけでパタパタと振動するようになります。そこ か ら 出 て く る 音 を エ ッ ジ ト ー ン （ Edge Tone）とよびます。
ここで、最初に音らしきものが出るわけです。
いったん音が出たら、楽器には管体がついているので、そこで共鳴して、周波数選択が行なわれる。肝になるのはここです。音が戻ってきて、なにかしらジェットに影響を与えないと安定した楽器にはならないのです。なにかしらのフィードバックがある。
フィードバックがあったら、また 1、2、3 と戻るのです。図のようにグルグル回っている。これのおこぼれのようなもので楽音が出る。だいたい五つの動的状態の組みあわ
せ・重なりあいでリコーダーから音が出る。
ひとつ言っておきたいのは、ふだんわれわれが聞いている楽音は、音の強さとしては
だいたい 60dB くらいの音です。フルのオーケストラで 120dB くらいです。共鳴管体内の音圧線は 140dB くらいなので、ここに耳をおいたらすぐに鼓膜が破れるくらいの音で4

MIRAI Archive

No.2015-011

す。
こういう状況でも、ジェットがもっている流体としてのエネルギーと音場のエネルギーをくらべてみると、5 ケタくらいの差があるのです。流体の計算をしている人だった
らわかると思うのですが、5 ケタも小さいものは、ゴミみたいなものでふつうはまともに相手にしないのですが、そういうものが効いてくる。こういう単純な話でも、動的状
態の積み重ねであり動的過程として捉えないと、なんで音が出ているのかということは「たしかにそうだ」と納得できるところまではいかない。

◇ ス ラ イ ド 6「 モ デ ル 」

ここから先は、このように計算できたというものを楽しんでいただこうと思います。
このようにモデルを切って、もともとこのあたりの構造が微細なことと、音波をあつか
わなくてはいけないので、メッシュの幅は 0.1mm です。すると、音が 340m/s でゆくの
で 、 ク ー ラ ン 条 件 か ら 、 時 間 刻 み も 10 の 7 乗 、 8 乗 で 進 め な い と い け な い 。 た と え ば 、ピーという音を 1 秒間出そうとすると、すごいステップスになる。

◇ ス ラ イ ド 7「 メ ッ シ ュ 図 」
このようにメッシュを切ります。まわりが透過壁で、下が壁で、左下に楽器を置くというようなものでします。なぜこんなにまわりの空間が広いのかというと、かなり音がでるのですが、10 の 8 乗セットくらいの長い計算をすると、こういうところでどうしても反射するのです。積もり積もって、いろいろとお
5

MIRAI Archive

No.2015-011

かしなことを起こすので、ここをある程度広くとって計算せざるをえない。やってみると、こんな感じです。三次元の計算をまん中でスパッと切ったかたちです。

◇ ス ラ イ ド 8「 エ ア リ ー ド 楽 器 の シ ミ ュ レ ー シ ョ ン 」
左側が流速です。このようにジェットが出ている。右のほうが圧力分布で、赤くなった
り青くなったりしているところから、きちんと発振していることがわかると思います。いちおう、ここまでは基本的な条件をそろえれば出てくるのです。ここから研究開始ということです。

◇ ス ラ イ ド 9「 エ ッ ジ ト ー ン と 管 体 共 鳴 」
エッジトーンと管体から戻ってきた
音との相互作用で楽音が決まるという話をしましたが、それを出したのがこの図です。横軸はジェットの速度で、縦軸が周波数です。管体をつけずにエッジトーンだけにすると、ずっと線形に上がってゆきます。ですが、楽器で管体がついていると、管体の共鳴周波数がどんどんと来ます。
楽器でジェットを入れてゆくと、きちんとこれに沿ったところに管体の共鳴周波数にロックしてゆく。ロックするということは、たんにエッジトーンのまま振動しているのではなく、なにかしらエッジトーンに制御がフィードバックされているということです。

◇ ス ラ イ ド 10「 移 動 境 界 ： ピ ッ チ 変 更 」
楽器なので、ピッチを変えたいと。端のところをちょっと短くして、ピッチが上がるかどうかが計算できるかを試してみます。同じようにメッシュを組んで、この部分をギュッと動かすということをしています。

6

MIRAI Archive

No.2015-011◇ ス ラ イ ド 11「 移 動 境 界：メ ッ シ ュ 」、ス ラ イ ド 12「 移 動 境 界：数 値 結 果（ 図 ）」計算しながら、途中でだんだん短くなっている。この壁がぶあつくなっているのをご覧いただいていますが、このようにして計算してみました。これは時間発展で、縦軸部分も圧力をとっています。このように音が出ている。管長を変えた部分がこの部分です。

◇ ス ラ イ ド 13「 移 動 境 界 ： 数 値 結 果 （ ス ペ ク ト ル グ ラ フ 1） 」 、 ス ラ イ ド 14「 移動 境 界 ： 数 値 結 果 （ ス ペ ク ト ル グ ラ フ 2） 」

管の長さを変える前と後で周波数スペクトルをとってみると、きちんと半音ぶん変わっていた。これは、理論予測どおりに条件を変えてみて、ほんとうにそうなるかどうかの確認なので、そのとおりになっています。最後に、ちゃんと音孔の開け閉めまでしなけ
ればいけない。どのようにメッシュを動かすのかをいろいろとやっています。

7

MIRAI Archive

No.2015-011◇ ス ラ イ ド 15「 移 動 境 界 ： メ ッ シ ュ 」 、 ス ラ イ ド 16「 移 動 境 界 ： 数 値 結 果 （ メ ッシュの一部）」

音場の強いところでもちゃんと計算できるスキームかどうかということのチェックが、いま終わったところです。120dB の音波を出すというメッシュの切り方、移動のしかたが目についた。

◇ ス ラ イ ド 17「 ト ポ ロ ジ ー 変 化 を 伴 う 移 動 境 界 」
図のようなかたちになっていて、薄緑色の部分を上げ下げします。まずは、これを連続的に上げ下げするのではなくて、ある
決まった位置に置いて、それぞれ計算をしてみて、きちんと発振するかどうか。メッ
シュ移動は計算しないときはよいのですが、計算するとこのあたりにいろいろと流体の運動が出ます。渦も出ます。そういうものをきちんと考慮してメッシュを移動しないと、不自然なことが簡単に起こります。
とくに、閉じたり開けたりする瞬間は、どんなにがんばっても衝撃波が待っています。
そういうところをきちんと処理しようとすると、一つのこういうソルバ（solver）だけではなくて、そういうものを処理する別のプログラムを同時に走らせて連携させることをしなければいけません。連成計算というのですが、まだ標準的な方法というか、「こうすればいい」というようなものがない対象です。

8

MIRAI Archive

No.2015-011◇ ス ラ イ ド 18「 音 圧 変 化 」 、 ス ラ イ ド 19「 Pad distance vs. frequency」
音圧変化を出してみると、横軸が楽器とパッドのあいだの距離です。閉じている場合、
1mm、2mm、3mm、4mm、5mm となっている。だいたい 3mm くらい開ければ、音孔は開いているとみなせるところまで動いています。

◇ ス ラ イ ド 20「 フ ル ー ト の 音 源 は ど こ ？ 」、ス ラ イ ド 21「 Howe’s Energy Corollary」

ご覧いただくものの最後として、フルートの音源はどこかというところまできました。
これはハウズ・エナジー・コロラリー（Howe’s Energy Corollary、HEC）というものです。
どういうものかというと、式はここだけでよいです。渦度と流速との外積をとって、音響的流出速度（音波）の内積をとると、これが負のときは流体から音にエネルギーが移っています。逆に正の場合は、音から流体にエネルギーが移っています。そういうことを、マイケル・ハウ（Michael Howe）という人が 1984 年に唱えました。これはまだ確かめていないので、ほんとうかどうか検証も兼ねてじっさいにやってみました。

9

MIRAI Archive

No.2015-011◇ ス ラ イ ド 22「 HEC: 計 算 結 果 」

これはリコーダーの歌口の部分を大きくとったものです。領域を 1、2、3、4 の部分に分けて、おのおの HEC の積分をしたものです。
グラフをみるとおわかりいただけるのですが、流体から音のほうにエネルギーが移っているのは 2 の部分でした。逆に、1 の部分で音から流体にエネルギーが流れてゆく。
音のエネルギーは 2 のところから注入されていて、管体で共鳴した周波数がジェットにフィードバックするところが 1 です。それ以外の場所があるかといわれたらないので、それはそうだという結果なのです。

◇ ス ラ イ ド 23「 ま と め ： 動 的 状 態 の 階 層 構 造 」
まとめです。リコーダーから音を出すというだけの簡単なことでも、最初にジェットをつくって、それからエッジトーンが出て、その音が管体共鳴して、周波数選択されて、それがまたエッジトーンを制御する。
そのおこぼれで楽音が出る。これだけの動的状態の重ねあわせで音が出ているということがおわかりいただければよろしいかと思います。
これだけいろいろな動的なものがあると、不確定要素が各所にいろいろと入りこんでくるのです。これをどう制御するのかというのが、けっきょくは演奏者の技量である。
素人が吹いた音とプロが吹いた音で、なぜあんなに音が違うのか。こういうことを知ろうと思ったら、動的なものがどういうものかをきちんと押さえないと議論ができないでしょう。
10

MIRAI Archive

No.2015-011

いま研究しているのがエッジトーンとの相互作用です。音は流体にとってのゴミみた
いなものですが、音がどのように流体に影響をおよぼしているのか。これはまだわかっていません。これをいまずっとしています。

◇ ス ラ イ ド 24「 不 確 定 性 を ど う 扱 う か 」
いちばん最初にお話したとおり、計算科学があって、計算機科学があって、情報インフラがある。三つくらい階層があるのですが、これらにずっと携わっています。なにが問題になるかというと、不定性がどうしても出てくるのです。動的なものは不定性のかたまりですが、これをどうあつかうのかという問題がつねにあります。これに対して仕事をするのですが、ほとんど対症療法ばかりのような気がするのです。そもそも論をしてみようと思います。

◇ ス ラ イ ド 30「 Uncertainty Matrix」
不定性というものをどのように捉えたらよいのでしょうか。科学技術社会論という分野で、
アンドリュー・スターリング（Andrew Stirling）という人がいます。もともとは物理学者です。
この人が、不確定性をどう分類するのかという考えを 2010 年に出してくれています。これであれこれといじっていたのですが、この枠組みで使ってみてみましょう。

◇ ス ラ イ ド 31「 不 確 定 性 の 分 類 」
先ほどのスライドは英語で書いてあったので、わかりやすく捕捉します。二つの軸があります
が、横軸が結果の可能性についての知識がある
かないか、行（縦軸）が発生確率についての知識で、マトリクスをつくっています。どちらもない場合を無知としております。
次の段です。多義性というのは、なかなかよい例がないのですが、たとえば、みなさんも計算機をお使いだと思います。ある設定ファイルがどこか一箇所壊れているとしましょう。
11

MIRAI Archive

No.2015-011

どこか設定ファイルが壊れたということはわかるが、この結果どのように計算機が変な動きをするのかは、どうなるのかわからない。こういうものを多義性というわけです。
不確定性というのは、これが起こればこういう結果になるということはわかるが、これがどのように起こるのかがわからない。動的過程は、こういう不確定性の遷移であるということもできるだろうと思っています。

◇ ス ラ イ ド 32「 不 確 定 性 と 研 究 の 営 み 」
じっさいに自分自身をふり返ってみると、研究自身も最初はなんだかわからないから始めるのですね。最初は方向性もない。右下から始めます。たとえば、流体の計算をするのだ
ったら、シミュレーションの設計を最初にします。流体だからナビエ-ストークス方程式を解けばよいでしょうというところまではよいのです
が、それを解いてなにが出てくるのかということが、この段階ではわからないのです。
計算を始めると、いろいろと現象が出てきます。出てきても、どういうものなのかという分類はできないうちは左下です。ローカルなモデルをつくったりして理解が進んでゆくと、ぜんぶわかりますよという左上にゆく。
こんな一筋でゆくわけではなく、結果が出始めると、思ってもいなかったようなもの
がゾロゾロと出てくるのです。「なんじゃこりゃ」というように出てきます。すると、これはなんなのだろうということをみるために、振り出しに戻ったりして、グルグルと回る。だいたい研究を進めてゆくと、わからないことが次つぎと出てくるので、ずっとこういう環のなかにいるという見方もできそうです。

◇ ス ラ イ ド 33「 ト ラ ン ス サ イ エ ン ス 1」
ここまでは、個々人の研究者の話で済むのでよいのですが、情報インフラなどに話がゆ
くと、ちょっと困るのです。プロジェクトが大規模になってくると──これも科学技術社会論の分野の話ですが、トランスサイエンス（Trans-Science）ということばがあります。1972年にアルヴィン・
ワ イ ン バ ー グ （ Alvin Weinberg） が 述 べ た 話 で す 。
そのなかから抜粋すると、「巨大なもの、たとえばアスワンハイダムや100MWのプルトニウム増
殖炉、大きな橋などでは、フルスケールの試作品
12

MIRAI Archive

No.2015-011を作るようなことは問題外である。さらに、そのような巨大装置が稼動するのは100年のス
ケールであり、たとえ試作品がつくられたとしても、試作品に弱点が無いかが確かめられるまで実際の建設を待つことはナンセンスである」と。

◇ ス ラ イ ド 34「 ト ラ ン ス サ イ エ ン ス 2」
そのとおりなのですが、じっさいに大規模なプロジェクトで起こることは、基本的に一発勝負なのです。失敗するかどうかは、やってみるまでわからない。さまざまな不確定要素が相互作用して、状況を切り分けることが困難なことがずっと起こります。「こういうことをするのだったらこういう専門家を集めればよいだろう」と最初に想定して始めても、これだけではいけない問題がなかから出てくる。

◇ ス ラ イ ド 35「 計 算 対 象 と し て の 不 確 定 性 」
これは私自身がじっさいに計算機グリッドのプロジェクトに関わって実感したことです。計算のほうに戻ると、どういうことがいえるか。マト
リクスの左側はアルゴリズム化できるので、プログラムにすることができる。しかし、右側はできないのです。しかし、プロジェクトが始まるときは右側から始まりますね。こういうところで、大規模プロジェクトはシステム設計をしなくてはならないのです。では、どうするか。
これらに対応可能なシステムを考えないといけないわけです。けれども、いまなされているのは──NAREGIのときもそうでしたが、「こういう機能が要りますね、ああいう機能も要りますね、こういうのも要りますね」と機能をダーッと並べてゆく。そして「それをつくりましょう」と。これで機能は列挙されるでしょうが、機能をどう機能させるのか。
集めた機能をどのようにしたらきちんと組みあわさって、サービスとして機能するのか。
どう機能させるのかという話は、まったく出ないのです。それだけでもたいへんなのに、日常に入りこんできている情報インフラの根幹は連続運転性を求められている。こういうことで大問題が起こっているわけです。

13

MIRAI Archive

No.2015-011◇ ス ラ イ ド 36「 動 的 過 程 の 計 算 法 」
では、どうすればよいのか。じっさいにプログ
ラムで計算機を動かすしかないのです。プログラ
ムがあって、生データがあって、動かすためのア
ルゴリズムを考えます。これをどうするかといったら、プログラムのなかに埋めこんで書くのです。
書くとどうなるか。プログラムを動かすと、いろいろと予期しない状況が出てくる。これに対応するために、またアルゴリズムを修正する。修正したアルゴリズムを動かすためになにをしなければいけないかというと、プログラムを止めるしかしようがないのです。止めて、書き換えて、もう一回動かします。
いまは、ほとんどがこのやり方です。だから、じっさいの現場のSE（システム・エンジニア）さんはひじょうな忙しさで過労死寸前の人が数多くいます。これに、さらに連続運
転性という問題が被さろうとしています。現場のSEさんは、ほんとうにたいへんな顔をしています。
結局ここからいえることは、インフラになるような連続運転性を担保しなければならな
いものというのは、アルゴリズムをハードコード（hard-code）してはいけないということです。プログラムのなかにアルゴリズムを書いてはいけない。

◇ ス ラ イ ド 37「 入 れ 子 チ ュ ー リ ン グ マ シ ン （ 仮 ） 」
それで、どうするか。私が3年くらい前から言っていることなのですが、計算機のうえに、もう1回計算機をのせようという話です。仮想化技術があるではないかということにもなりますが、これは計算機を仮想化するというよりも、計算環境そのものをもってくるものなので、ぜんぜん考えが違います。計算環境そのものというのは、要らないものまでいっしょにきてしまう。むだが多い。
どうするかというと、まずエンジンがあって、これになにを食わせるかというと、アキ
ソム（axiom）というたいそうな名前をつけましたが、ルールを書いたものだと思ってください。ルールを規定したものを用意しておく。じっさいに動かすときには、こういう条件
で動かしましょうというコンフィグレーション（configuration、conf）を指定しておく。
14

MIRAI Archive

No.2015-011

あとは、対象となる系をモニタリングします。もしも、想定している状態と違ったら、
なにかアクションを起こしましょう。こういう構造にしておけば、エンジンは軽く済みます。チューリングマシン（Turing Machine）そのもののようなもので充分です。エンジンがするものは、このコンフィグレーションとモニタリングの結果です。系の状態と、そうあってほしいというように書かれたコンフィグレーション・ファイルとのあいだの整合性をチェックするだけです。不整合があれば、ルールからこうしましょうというアクションを引いてくる。そうしてくれるツールは、プログラムにいくつかあるので、そういうもののトリガーを引く。
コンフィグレーションは、これまでも動かしながら書いてこられたのですが、アキソム
も動かし続けながら書き換えることができるのです。ルールに書いていないことに関しては、書いていないというアクションを起せばよい。そうすれば、人があらためて対応する。
これでいろいろとおもちゃのようなものをつくってやっています。おもちゃのようなものと言いましたが、次の5年間で七帝大のあいだを継ぐインタークラウド（intercloud）の管理ツールとしてつくらなくてはならないものなのです。こういうものに向けて、いましています。
目下の問題はなにかというと、アキソムと書いたはよいのですが、まだ絵に描いた餅なのです。どのように書けばきちんとシステムが回るかというところが、むずかしいです。
こういうものをつくっておくとなにがよいか。自己言及的なことができるようになる。動かしながら、自分自身を変えることができるようになる。

◇ ス ラ イ ド 38「 入 れ 子 TMの ご 利 益 」
自分自身の分身のようなものを役割分担して置いておき、階層化することもで
きるし、ほかのところに置いておき、移すこともできる。あとはセンサとロボッ
ト、あるいはクラウドなどで、ビッグデータやクラウドなどのアセンブリもつかいます。連成計算のエンジンにもこういうものがつかえます。状況が刻一刻と変わるところで、対応する。
なぜ、このような研究を数年来していたかというと、こういう構造やエンジンを考える
ことが動的過程の研究とオーバーラップしているところが多いからだろうという気がします。

15

MIRAI Archive

No.2015-011◇ ス ラ イ ド 39「 最 後 に：研 究 と 歴 史 と 社 会 」
最後です。ぼくは理学の出身ですが、情報インフラなどと関わると、また見方が変わってきました。蒸気機関と電磁力学の関係は、われわれが昨日きょうと議論しているところと実社会のインフラに入りこもうとしている
技術とのあいだの関係に似ているように感じます。
プログラムのあたまにありますが、「想定外の問題が次つぎと出現することこそ、創発の本質と捉え、問題を創り出す創発現象を逆説的に利用することによって、問題解決がはかられる可能性についても議論する」と。これが、じっさいに待ったなしの状況になっているように思います。このままゆくと、現場の人間が何人過労死したらよいのだろうというような、ぜんぶ現場に問題を押しつけるよ
うなかたちでドーッと進んでいます。こういう状態で、いろいろなプロジェクトがどんどん進んでいます。
昨日、佐々木節さんが「ゆっくりやって失敗してもいいよ」とおっしゃっていましたが、こういう研究会の成果が切実に待ち望まれている分野があるのだと。これがみなさんの日
常生活に深く関わっているのだと。こういう世界があるのだということをご承知いただけ
れば幸いです。以上です。

三輪●ありがとうございました。
Ａ氏●すごく賛成するのですが。ちょっと気になるのは、このようなことをしているのはグーグル（Google Inc.）だから、言ってもしようがないのではないかというのが正直な話なのですが。
ぼくは、何年か前にグーグルのヘッドクオーターに行きました。まさに、24時間365日止
まらないようにしていました。言うのは勝手だけれども、グーグルがこれをガンガンとしているのです。だから、これは問題にならないということが問題なのではないですか。
小林●なるほど。一つ、だいじな話があって。グーグルならグーグル──どこでもよいのですが、ひと企業でしているということは、つまりイントラなのですね。
Ａ氏●それを問題にするのではなくて、ここで力学的な問題があるとするのならば、ページランク（PageRank）にしてもGSS（Google Site Search）にしても、そういうアプリを開発して、なかを走っているソフトウェアと関係なく、ハードウェアのうえでソフトウェア
を24時間止まらずに走らせることをグーグルがしている。
だから、そういうことはグーグルが解決してまわしてしまっている。そういう意味では、
16

MIRAI Archive

No.2015-011

プラクティカルな問題として考えなくてはいけない。もうなされている問題なので、これをいま問題とするのは、なんとなくアウト・オブ・デートな気がしてしまうのです。その
へんはどうですか。
小林●逆にこういうものが情報のアカデミアのところでまったく出てこない。
Ａ氏●情報のアカデミアというところが気になっているのです。
小林●そうです。私が言ったのはそういうことです。
Ａ氏●そんなものがあるのかということが問題です。もう一つは、最後のお話はバーチャ
ル・マシン（Virtual Machine、仮想機械）でガンガンつかっているではないですか。
基本的に情報のアカデミアという問題は、いま実行されている問題だと思うのです。机上の空論的な問題は、もう…。だからこそグーグルは偉いのですが。ディープラーニング（Deep Learning）もそうです。アカデミアで考える前に走って、論文にする前にブログにあげてしまっている。24時間ノンストップでと考えているあいだにシステムをものすごい量で構築して世界をつくっているというのが現状だと思うのですが、そうは思われませんか。
小林●もちろん、技術はあるなと思います。バーチャル・マシンを止めずにする技術があるということはわかるのですが。同じものを、ほかのところにライブ・マイグレーション（Live Migration）して、動かしながら変えることができるということはわかります。しかし、ウェブでなにかサービスをつかっているとして、サービスを止めずになかをバージョンアップすることは無理ですね。
Ａ氏●たとえば、Gmailなども日常のものではないですか。鉛筆や水道のようなものになっているのです。小林さんのお話は「もっとよい水を」みたいなセカンド・オーダーの話のように聞こえてしまったのです。ファースト・オーダーでつくったグーグルが偉くて、それでもう既に世界が統一されてしまっています。「もうちょっとおいしい水を飲みたいよね」というような話に聞こえるのですよ。
基本的な部分は構築されてしまったのです。情報科学などで、大学で研究するものはなにが残っているのか。あるいはアカデミアとして研究するものは、ほんとうにあるのかということが問題になっているのではないですか。
たとえば、計算パワーが追いつかない。でも、それとは別にグーグルがつくったページ
ランクやグーグルボットから始まって、いまおっしゃったことを実現して、走らせて、つくっているのです。だから、いまお話を聞いた結果は「でも、それはグーグルがやりましたよね」としか答えようがないような気がしてしまうのですが。
小林●いや、そうではないですね。
Ａ氏●そうではない部分というのが、現実がわからないのですよ。
小林●なんと言ったらよいのでしょうね。24時間連続運転などの話はできているのですが、
17

MIRAI Archive

No.2015-011

そのしかたはこれまでの計算機のつかい方の延長線上ですよね。プログラムをどのように書いているのか、アルゴリズムをどのように計算機にのせるのか。みんなプログラムにコードを書いてしますよね。
しかし、これをしているかぎり、アルゴリズムが変わったらプログラム自体を変えなくてはいけない。それでもいいじゃないか、サービスがつかえたらいいじゃないかという話だったら、話はそれで終わります。けれども、こういう計算のしかたではなくて、動的なもの、不確定なものが出てきたときに、これらをどのように除くか。こういうことをする
ときに、プログラムさせておくのは判定するものだけにして、アルゴリズムもプログラムの外に出せばよい。
Ａ氏●そもそも、ぼくがどうしてこの質問をしたかというと、前半の話はすごくおもしろ
くて、基本的な問題とも絡んでくる。ジェットがあって、どうやって求めるのかと。グー
グルは、まさにこれと同じように、プラクティカルにGmailを送るという問題を、後半のお話のとおりに解いているわけです。
前半の問題のときに、すごい流体力学があって、境界線モードを書かなくてはいけない
ねといったら、抽象的でもそういう問題もあると思うが、フルートの問題にしたとたんに、ワーッと立ちあがるではないですか。
同じことをしたのがグーグルです。いまお話された感じは、なんとなくぼんやりしてい
るではないですか。しかし、グーグルがまさにその問題に関して10年前に走らせて構築した構造が既にあるとぼくは思うのです。
小林●ご質問の意図を捉えきれているかどうか自信がないのですが、きょう私がしたような話をなぞったようなところがじっさいにできているかどうかというと、グーグルはかなりのことをしています。これは議論の余地がないです。
たとえば、軽くて高速に動くようなものがないと連成計算ができません。ns（ナノ秒）くらいのところでバーッとやりとりして、計算しないといけないものは、バーチャル・マ
シンのような重たいものではもちろんできない。軽くて小さなものがどうしても要る。
しかも、nsのオーダーで不確定要素に対するものを処理しようと思ったら、自己言及的なものをなにかしら入れないと無理でしょう。旧来のようにアルゴリズムをプログラムにダーッと書くというのはやめ、そろそろパラダイムを変えませんかということが言いたい
ところです。
三輪●まだ続きそうですが、終わります。どうもありがとうございます。
（了）

18