ハッカーの遺言状──竹内郁雄の徒然苔
第35回：プログラミング画法

私が初めてコンピュータに触れたのは大学院に入ってからである。数学の才能がないことが身に沁みて分かり、数学科の人たちが触れたがらないコンピュータに走ったのだ。そこで最初に作った大きな（といってもタカが知れている）プログラムは、いまでいうオセロを競技するプログラムである。

当時はオセロという名前のゲームはなく、リバーシ（reversi）という名前のものが市販されていた。名前はまさに駒を反転させることを表わしている。ハナヤマという玩具メーカから発売されていたものは、碁石と同じ形だけれども、それより小さい直径1センチほどの、両面が紅白に色付けされた石を使うもので、大人の手でひっくり返すのにちょっと苦労した記憶がある。

初期配置と、相手の石を挟めばひっくり返すと説明には書いてあるものの、斜めに挟んでいいのかどうかの記述がない。そこで、試しにやってみることにした。付き合ってくれたのは数学科同期の柏原正樹君。彼は後に京都大学数理解析研究所所長、国際数学連合副総裁まで勤めた天才だが、そんなことは知るよしもなく、斜め挟みありのルールで試験対戦したのであった。すると、なんと3回連続32対32で引き分け。これじゃぁ、斜め挟みはなしだなと結論づけた。数学者にはあるまじき帰納的推論である。

縦横挟みしかないおかげで、当時のコンピュータの能力（加減算200μ秒、メモリ24ビット8K語）にちょうど見合ったプログラムを書くことができた。入出力はフレクソライタという鉄の塊のようなタイプライタ（遺言状第6回に写真が載っている）。黒赤の2色のインクリボンだったので、石の表裏を色で区別することができた。それにしても、1手打つたびにギチャガチャバチャガチャガシャンと盛大なノイズを立てて盤面を印刷するので、人間には妙なプレッシャがかかったかもしれない。で、そこそこ強かった。

当時はゲームを競技するプログラムに関する文献はあまりなく、図書館で真面目に探す必要があったが、局面の評価関数やα-β枝刈りは勉強することができた。いろいろ探していたら、以下の本が見つかった。

Botvinnik, M.M. Computers, Chess and Long-Range Planning. Springer Verlag, 1970（M.M. ボトヴィニク「コンピュータ、チェス、長期プラニング」）。

薄いペーパーバックだったが、私はこの本を読んで目からウロコが落ちた。著者のボトヴィニク（※1）は、1997年にIBMのディープ・ブルーというチェスプログラムに負けたことで有名になった偉大なチェスチャンピオン、カスパロフの師匠である。本人自身、3度もチェス世界チャンピオンになった名人であると同時に、ちゃんとした電子工学者なのでテクニカルな物書きができる人である。

チェス名人が自分を内観しつつ書いた本なので、非常に説得力がある。もちろん、私がチェス名人の内観をすべて理解できたわけはない。目から落ちたウロコは、自分が指して、相手がこう指す、そしたら自分が……、というゲーム木の探索のやり方である。つまり、ゲーム木の探索に代わって、ゲーム局面の理解を深めなければという方針の表明に私は心酔してしまったのである。

何を言っているかまったく分からないかもしれないので、もう少し詳しく説明しよう。与えられた局面、つまり自分が手を打つべき局面が与えられたとき、候補手はたくさんある。純粋に機械的にやるなら、候補手をそれぞれ指してみて、次の手番である相手に局面を渡す。そこで相手の手の候補手をまたそれぞれ指してみて、その次の自分の手番の局面に進む。それぞれの手を指すのは1回に1手しかできないから、話は簡単ではない。こうして頭の中にできるのがゲーム木だ。単純化したものを図1に示す。

図1：単純化したゲーム木

最初の自分の局面で候補手が30手あり、それぞれの手から生ずる相手の局面それぞれにまた30手の候補手があれば、相手の手番から生じる局面の数は30×30=900となる。同様にもうひとつ進むと30×30×30=27,000とどんどん大きくなる。チェスのプログラムについて最初に本格的な考察をした、情報理論の創始者シャノンは、チェスの勝敗が決まる統計的平均手数と、この論法を用いてチェスの可能な手順の総数は10の120乗と計算した。

10の120乗はどんなに高速なコンピュータをもってしても扱える規模ではない。そこで、良さそうな手に候補手を絞る、最後まで読み切るのではなく数手先とか10数手先の（緊急の取る・取られるのない）「落ち着いた局面」まで先読みを行い、局面の評価をし、自分にとって良い評価の局面に進む手を選ぶという手法で、手に負える規模の問題に縮小する。上に出てきたα-β法は、機械的でありながら、劇的に探すべき手順を減らせる画期的な方法である。

私がボトヴィニクの薄い本から啓発を受けたのは、ある意味でこの機械的で「野蛮」な方法ではなく、チェス名人の直観をデータ構造にする方法論であった。それは膨大な計算を要する先読みの木探索ではなく、名人が盤面（局面）を見たときの直観をコンピュータにさせ、その後で先読みを補助的に使うという方法論だった。

なぜ名人は盤面をチラリと見ただけで、いい手が打てるのか？　それはパターン認識の能力だと言ってしまえばおしまいのようだが、いろいろな種類の猫でも猫だと認識できるのとは違う種類のパターン認識のように思える。要するに、先読みして得られる戦術的な情報がその盤面に「焼き付いていて」、名人にはそれが一瞬のうちに見えるのだ。ボトヴィニクはこの「焼き付いた」情報の表現法を議論していたのである。私が、大昔に書いた手書きスライドを示しておく（図2）。

図2：名人の盤面理解はこうなのだろう。

先読みという時間軸方向の展開を、目に見える空間に射影しているのだ。実はこの「時間軸を空間へ射影すること」が私のその後の研究全般にわたる基本原理になった（※2）。

時間軸の空間への射影の典型例は絵巻物だろう。絵巻物では、1枚の絵の中に時間経過が右から左へと、巧みに表現されている。絵巻物は長いので右から順に見ていくのにちょっと時間がかかるが、西洋絵画には一目で見れるのに時間の経過が感じられるものがある。このあたり、いろんな議論がWeb上でなされている。

プログラミング技術の進歩にも、時間軸を空間へ射影あるいは転換する原理が関わっている。その最初の例が、1968年の米国計算機科学会（ACM）に投稿されたダイクストラの「Goto有害論（Go To Statement Considered Harmful）」という短いレターである。

昔のプログラミング言語には、機械語のジャンプ命令に対応したgoto文があった。これを使って、条件分岐や繰り返しを表現できたわけである。しかし、goto文を多用したプログラムは指で追わないと読めない。まるで、「あなたと相性のいい友達のタイプは？」クイズのように、枝分かれをたどっていかなければならない。こういうクイズは一目で結果が分からないようにわざと迷路のように描かれる。しかし、プログラムの場合、わざとじゃないのに同じ分かりにくさが生じてしまう。

ダイクストラの提案は、時系列でgoto文を追っていくのをやめ、条件分岐はif then else、繰り返しはwhile doといった構文構造で表わそうというものであった。プログラムにおける逐次実行、条件分岐、繰り返し、手続き呼出しを基本構造にすれば、パッと見た目での了解性が高まる（ことが多い）。指で時系列を追う必要がないからだ。これに始まる一連の技術潮流は「構造化プログラミング」と呼ばれる。

プログラムの動作を「動的」に記述するのではなく、「静的」に記述しようという一連の技術潮流も、時間軸を意識しないといけないプログラミングをなるべく排除しようということである。変数の値が時々刻々と変化していくのではなく、一旦変数の値を決めたらそれ以降は変化しないという「単一代入」の原則を貫く言語はその一例である。このような潮流、つまり時系列にしたがって動くHow to doの手続き型プログラミングではなく、時間軸をなるべく捨象したWhat to doの宣言型プログラミングへの運動がある。

もっとも、私個人の趣味としては、このあたりはあまり深追いしたくない。アルゴリズム的思考はこれからもずっと必要ということもあり、むしろ、プログラムが扱うデータ構造をプログラムの中で目に見えるようにするほうが趣味だ。現実世界をモデル化しようとすると、現実世界の動きを反映してデータ構造の内部は変化するし、データ構造自体も変化しないといけないかもしれない。この「可視化」のための最も強力な武器が「オブジェクト指向」の概念だろう。時間に沿って、コンピュータ内部の状態が変化していくことは無視できない現実である。だからそれを認めた上で、時間軸思考の負荷を下げる方法を考えたいというのが私の考えである。

話が急にジジ臭くなってしまった。ジジ臭いついでに、私が大昔（1976年）の情報処理学会全国大会で発表した「プログラミング画法」を、当時の原稿のまま紹介しよう（図3）。懐しい自筆原稿であり、参考文献にある月本さんは、内容と関係なく、初めて予稿集に顔写真を載せたということで引用させていただいた。私のこの写真は、忘年会で酔っ払って先輩の眼鏡を奪い取ったところを撮られたものである（ちなみに、当時の私は両眼視力1.5〜2.0であった）。節のタイトルなど、常識外れをわざと狙ったことが見え見えである。良い子でなかったことがバレバレだ。

図3：“プログラミング画法”の提案（クリックで拡大します）

IIIの「ひらきなおれば」に書いてあるように、「1枚の図の中に時間経過性を表現」が今回のテーマに関連している。この発表は予想以上に好評で、会場にいらした大先生数名からお褒めの言葉や質問をいただいた。

振り返ってみると、これは1972年、ある言語処理系の実装のドキュメントを書くために思いついただけの画法なのであるが、今日的な視点で見ても、図への（操作）時系列の埋め込み、並行動作の自然な表現、（ある程度制限された）帰納的記法の導入、処理系作成可能性の示唆など、面白いアイデアを含んでいると思う。1972年のこのアイデアは米国でVisual Programmingという言葉が出てきたのと、どちらが先だったかというタイミングだろう。

遺言状第4回にもご登場いただいた原田康徳臨時特殊科学分析班隊員が開発して、いまや日本で広く子供のプログラミング教育に採用されているViscuit（ビスケット）はメガネという仕掛けを利用して、画面上の図・絵の動きや、図・絵同士の空間的な相互作用の時系列を一目で見えるようにしている。かつその効果が子供にもすぐ分かるようなっている優れた「並列ビジュアル言語」である。これで「並列プログラミング」を学んだ子供たちをどのように従来型のプログラミング言語の学習に導いていくかについて原田隊員はいろいろ思索をめぐらせているようだが、「時間軸の空間への射影」がこんなに見事に実現されているのだから、ぜひぜひ先へというか、新しい方向に進んでいっていただきたいと思う。

さて、私は自分のプログラミング画法をときどき講義で使った。たとえば、ゴミ集めアルゴリズムの説明を板書するときなどはとても便利だった。データ構造の動きを表わすのに、書いては消しでは、書き写す学生がお手上げになるからだ。パワーポイントの時代になっても、1枚のスライドで動きを説明するのに役立った。また、人に何か説明するだけでなく、非常に面倒なプログラムを書くときのコーディング補助としても利用した。実際、ポインタの張り替えだらけの、やたらと複雑なメモリ管理のマイクロプログラムを書くときにとても重宝した。

GUIで容易にプログラミングができるようになってから、このアイデアを具体的なシステムにしようと挑戦した博士課程の学生が出てきた。しかし、残念ながら実装には至らなかった。図を理解する、あるいは理解可能な図の文法を作るという相当難しい課題だったようだ。もっとも彼は何ごとも大上段に振りかぶってから考える性格だったので、問題を余計難しくしてしまったようなところがある。

大上段に構えるのはいいが、考えすぎて、可能なもの、あるいは可能かもしれないものを不可能にしてしまってはいけませんね。（つづく）

※1：「The Adventures of Soviet Chess Patriarch Mikhail Botvinnik」にボトヴィニクの写真が掲載されている。
※2：現代のコンピュータの能力は非常に高く、モンテカルロ法という、いわば超高速サイコロ振りで、勝負を最後までランダムにプレイしてしまう方法を採用するプログラムが急に強くなってきた。ボトヴィニク方式ではプログラミングの手間がかかりすぎるのである。また、深層学習も強力な手段となってきた。コンピュータのパワーに任せた「野蛮」な方法が復活したのである。

竹内先生への質問や相談を広く受け付けますので、編集部、または担当編集の風穴まで、お気軽にお寄せください。（編集部）

この記事を、以下のライセンスで提供します：CC BY-SA
これ以外のライセンスをご希望の場合は、お問い合わせください。