疏水分線

ソガ/疏水太郎のブログです。

対話についてのアンカー (6)

このところ条件分岐のことを考えていましたが、条件が記述されること、選ぶ人がいること、分岐すること、この3つはそれぞれ独立していると言ってよいのかもしれません。このそれぞれについて、または幾つかを組み合わせた様子のなかに対話的な出来事を探してみたいと思います。

 

はじめに「分岐」について。なんらかの条件で動作の分岐する機械について考えてみると、ししおどしはこうした機械だと言えるでしょう。竹筒の先に水が注ぎこまれ、もしも水が一定量たまったならば、水を放出して音を鳴らします*1。ほかに良い例は思いつかなかったのですが、遅くとも14世紀にはこうした仕組みがみられたので*2、条件に基づいた動作をする機械はそこそこ古くから日常の暮らしのなかにあったと思われます。

 

では、ししおどしに対話はあるでしょうか。ある・・気がします。流れる水と竹筒の間には対話があるように思われます。これは、英語で言い直すならばインタラクションということになるでしょう。

 

プログラム内蔵方式の(つまり現代のほとんどの)デジタルコンピュータは必ず処理の途中で条件分岐できる仕組みを備えています。コンピュータは命令を与えられた順に処理して、分岐命令にたどり着くと条件を満たしていれば次に実行する命令を変化させます。ここに対話はあるでしょうか?ししおどしにあるのならばあるといって良いかもしれません。コンピュータは流れてくるプログラムと対話をしています。ただし面白いことにこのプログラムはコンピュータに内蔵されていますので、コンピュータは自分が自分と対話しているような形を取ることになります。

 

ここまでの話に人間は登場しません。機械はただ与えられた条件に従って、水や処理すべき次の命令の尽きない限り動き続けます。

 

人間にとっての条件分岐は日常の意思決定としてまず登場します。左の道が工事中であれば右の道を通る、といった。ですけどここでコンピュータプログラムに繋がる話題としては、分岐が形式的な表現で書かれていて、人間がそれを読み取って選ぶ必要がある、という場面を想定したいと思います。本件で繰り返し採り上げているのはバロック音楽の時代で、遅くともこの頃には楽譜上にあるダ・カーポとフィーネのような標準的な記法に沿ってプレイヤーが演奏していたとされています。加えていうと、奏者は反復記号と出会ったときに何度くりかえすのかを任意に選んでいたようです*3

 

反復記号は条件分岐を含意しています。プレイヤーはいま何度目の繰り返しであるのかを意識する必要があり、「もしも」規定の回数に達していれば、繰り返しを止めることを検討する必要があるためです。ここでは、プレイヤーと楽譜との対話を見ることができると思います。

 

これと近い場面では、条件分岐を含意しない反復も見られるので触れておきます。シリンダー型オルゴールもディスク型オルゴールも、終わりのない円周状の楽譜を備えています。また、最初の電気機械式自動計算機であるHarvard Mark I(1944年)では穿孔された紙テープがプログラムであり、紙テープの両端を接着して輪にすることで繰り返し処理を実行することができました。そして、Harvard Mark I は条件分岐の機構を持っていません*4

 

19世紀におけるチャールズ・バベッジの解析機関では、反復機構を持つことが構想されていました。ルイジ・メナブレアの解説によると、例えばある方程式を解く際に、乗算が4回連続して必要とされます。解析機関では1つの演算操作は1つのOperationカードで実装されますので、これは同じ乗算カードを4回繰り返し用いることで実現されます*5。続いて、いわゆるカウンタ変数nを導入して、nが0の値になるまで繰り返す手法も述べられています。つまり、反復機構を実現するために条件分岐が必須となることは、解析機関の時点で既に検討されていたと言えます*6。また、1枚のカードでなく複数のカードシークエンスの反復利用については、エイダ・ラブレスが主にNote C, Note Fで言及しています。それはカード送りの回転運動においては、巻き戻しによって実現されます*7

 

バベッジの構想はのちのコンピュータ開発においてほとんど参照されなかったことが知られています。先のHarvard Mark Iを開発したハワード・エイケンはバベッジの自伝に背中を押されましたが、設計と技術の観点ではほとんど影響を受けておらず、とくに分岐機構を備えていない点ではメナブレアとエイダの記述もよく読んでなかったのでは、と考えられます*8

 

1945年のこと、フォン・ノイマンはプログラム内蔵方式のデジタルコンピュータの命令セットが条件分岐を備えているというアイデアと仕組みを草稿で示しました*9。この草稿のコピーはコンピュータ開発者の間で広く共有されました。

1947年のレポートでは、ノイマンは反復処理が条件分岐を含意していることをフローダイアグラム(流れ図)を用いて解説しました。まず彼らは、帰納法、逐次近似法、合計の計算など、さまざまな数学的な問題を解く際には反復作業が現れることを述べました。ここまではバベッジの話にも似ていますが、ノイマンはコンピュータでそれを処理する場合の流れを図解しました*10。ここで反復から抜け出すための条件分岐を担当するノードとしてAlternative Boxが明記されました。このフローチャートの元祖を用いて、ノイマンはプログラム内蔵方式のデジタルコンピュータの命令セットには分岐命令が必須であることを紹介しました。

 

分岐命令によって自己との対話を繰り返していたコンピュータと、人間との対話が始まったのはいつだったでしょう。教科書的にはTSSの登場からであって、その背景としては例えばジョン・マッカーシーの1959年の所感としてあったように、コンピュータの利用は混みあっており、まずコンピュータオペレータにプログラムを渡して、順番待ちのため結果が返ってくるまでに3時間から36時間くらいかかってました。手紙のやりとりを対話と呼べるならばこれも対話かもしれませんが、TSSによって瞬間的な応答が得られるようになると、速度面における対話感は飛躍的に高まりました。それに伴って、じっさいコンピュータ側から人間に対して質問を表示し、その場で人間が答えを入力するという様式も生まれました*11

 

この「対話」らしさについて私が今日知ったこととして、どうもその36時間待たされるようになるまでには過渡的な時期もあったようでして。1957年に世界初の高級言語FORTRANがIBM 704で動作するようになりました。このFORTRANの条件文では、704の操作盤にあるスイッチi番がUp状態かDown状態かを判定して、n1またはn2という別の結果を返すこともできました。 *12

IF (SENSE SWITCH i) n1 n2

つまりこのIF文と、プログラムを一時停止させるPAUSE文と合わせて使えば、いったん特定の箇所でプログラムを止めて、途中までの処理結果を人間が確認して(これはランプで表示させることもできました)、必要に応じてスイッチを切り替えることで分岐先を変更してからプログラムを再開する、という作業が可能となっていました。当時はまだプログラマ本人がオペレータも兼ねていたため、プログラマはこうやって直接コンピュータと対話することも可能だったのでした。

 

以上では、条件が記述されること、選ぶ人がいること、分岐すること、の3つについて見てきました。とくに条件の記述についてはまだ話したいことがあります。たとえばそれは、選択肢の記述というのはいつ生まれたのかということ、そしてブール代数のことです。

*1:くきゅくきゅ

*2:日本国語大辞典「添水」(そうず)

*3:橋本 英二「バロックから初期古典派までの音楽の奏法―当時の演奏習慣を知り、正しい解釈をするために」。本書、実家に置いてきたので具体的に本書が取り上げているバロックの時期が17世紀から18世紀のどこを指すか、いまは正しく言えないでいます。

*4:Martin Campbell-Kellyら「コンピューティング史: 人間は情報をいかに取り扱ってきたか」

*5:“Sketch of the Analytical Engine” by L. F. Menabrea, translated and with extensive commentary by Ada Augusta, Countess of Lovelace. https://www.fourmilab.ch/babbage/sketch.html "In the preceding table it will be remarked that the column for operations indicates four successive multiplications, two subtractions, and one division. Therefore, if desired, we need only use three operation-cards; to manage which, it is sufficient to introduce into the machine an apparatus which shall, after the first multiplication, for instance, retain the card which relates to this operation, and not allow it to advance so as to be replaced by another one, until after this same operation shall have been four times repeated. "

*6:同書:"But when n is given for the particular case to be calculated, it will be further requisite that the machine limit the number of its multiplications according to the given values."..

*7:同書:"Those who understand the mechanism of this loom will perceive that the above improvement is easily effected in practice, by causing the prism over which the train of pattern-cards is suspended to revolve backwards instead of forwards, at pleasure, under the requisite circumstances; until, by so doing, any particular card, or set of cards, that has done duty once, and passed on in the ordinary regular succession, is brought back to the position it occupied just before it was used the preceding time. The prism then resumes its forward rotation, and thus brings the card or set of cards in question into play a second time. This process may obviously be repeated any number of times."

*8:このようにエイケンがバベッジから受けた影響が限定的である、という話は前記「コンピューティング史」より。

*9:John von Neuman, "First Draft of a Report on the EDVAC".  

https://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-8-pdf/k-8-u2593-Draft-EDVAC.pdf

 中央演算部(CA: Central Arithmetical part)の解説が11章にあり、とくに11.3節では条件分岐のための操作sが紹介されています。CAでは、IcaとJcaに格納された値に対する演算結果がOcaに格納されます。操作sでは、IcaとJcaにそれぞれ新たな値を格納したのち、このOcaに格納された値に基づいてIcaかJcaの「どちらか」を新たにOcaへ格納します。

*10:Goldstine and Neumann, "Planning and Coding of Problems for an Electronic Computing Instrument" https://www.ias.edu/sites/default/files/library/pdfs/ecp/planningcodingof0103inst.pdf ページ4のFirst: 以降、FIGURE 7.1や7.2を参照。

*11:対話についてのアンカー (3) - 疏水分線 (hatenablog.com)

*12:高橋 延匡「OSと命令セットアーキテクチャ」 http://id.nii.ac.jp/1001/00005138/

IBM 704用FORTRANマニュアル(マニュアルは1956年に執筆) https://archive.computerhistory.org/resources/text/Fortran/102649787.05.01.acc.pdf

ゲームブックの記法について(4)行番号とパラグラフ

前回、構造化プログラミングという話が出てきたので、プログラミングとの比較でゲームブックの記法を際立たせてゆくこともできると思いました。

 

さて、ある時期、BASIC言語のプログラムとゲームブックのパラグラフ文に類似性を見ることはできたのですが、その後、プログラミングの世界では条件分岐の結果として「番号」の割り当てられた任意の項目へジャンプする方式は廃れています。このことは、ゲームブックがいまも同方式を積極的に採用しているわけを照らし出してくれます。

 

プログラムというものは一般に、どこで何が起こって今どういうデータが保持されているのかという状態の変化を、人間が追いかけやすいつくりになっていることが良いとされています。これは、正確に動作するプログラムを作ることが重要視されているためですね。そうすると、プログラム中のどの「番号」にでもジャンプできてしまう作りかたは不都合なものでした。何度も遠い番号へジャンプしてしまうようだと追いかけるのは手間になります。

 

構造化プログラミングという考え方が浸透するにつれて、このジャンプは廃れてゆきました。構造化プログラミングでは、たとえジャンプがあるにせよ、それを人間がぱっと見渡せる程度の小さい範囲に収めます。ジャンプ先がすぐ近くであれば、追いかけるのにそう苦労はありませんよね。大きなアプリケーションを小さなモジュールに分けて、参照関係を局所化してゆく。これは論理的なアウトラインを持つ文章の書き方にも通じるところがあると思います。

 

正確な動作を目的とするプログラミングの世界では、構造化プログラミングが提案され、ジャンプの局所化が行われました。では、ゲームブックではなぜ同じことが行われてないのでしょう。え?当たり前?そんなことないですよ。ゲームブックを自分で作ってみるとすぐに判るのは、3番から121番へ、75番から13番へジャンプするような細切れのパラグラフを正確に動作するように組み上げるのはとても難しいということです(じっさいバグのあるゲームブックも存在します)。ですので、より正確な動作を実現したいなら、3番からジャンプする先は4番や5番に、75番からジャンプする先は74番や76番にしておいたほうが、より間違いなく作りやすいはずですね。

 

ゲームブックは正確に作られているに越したことはないと思います。そのうえで、あらためてゲームブックの主な目的のことを考えたとき、それはプログラミングと同じではないのだよ、と導きたい。ゲームブックにおいて近い番号へのジャンプが避けられる傾向にあるのは、近くに置いた場合、ジャンプ先の展開が予めプレイヤーの目に入ってしまうことがあるためです。そのことがゲームブックの体験にどう影響するのか、制作者が制御できないという点ではどちらかというと悪いほうへ働きそうですが、独特の味わいをもたらしている部分でもあります。こうした動作のしくみがすべて見えていることは紙のゲームブックの特性で、良くも悪くも制作者を悩ませてきたところだと思います。

 

プログラムとパラグラフ文に類似性を見るならば、その後の構造化プログラミングによってゲームブックのパラグラフ構成が照射されます。ゲームブックではジャンプ先は局所化されず、むしろやや追いかけにくい位置におかれます。それと同時に、物語上あとから登場するパラグラフはなるべく後ろに置くといった塩梅も見られるように思います。こうしたことはプログラミングの世界では普通は見られない姿といえます。

ゲームブックの記法について(3)もしも明日が

もしも明日が晴れであれば、遠くへ狩りにでかけよう。太古の人がそんな風に考えたかどうか知るすべはないのですが、もしも~だったら、という条件を想定することは、人にとってそこそこ昔から自然のことであったと想像されます。

 

条件と行動の組について、自然言語とは別の記号、または特定の型にはまった指示を用いて書き示すようになったのはいつからなのでしょう。そうしたことも念頭に、ゲームブックの記法についての話を書きかけてから2年が経ちました。このところ別途コンピュータの話を書いていたら、いつのまにかまたゲームブックのほうの話の続きのようにもなっていたので、いったんこちらに戻ります。

 

前回は、18世紀の声明の記録(声明譜)に繰り返し構文が見られるという話をしました(ゲームブックの記法について(2)声明の記法)。ここでは、行末に繰り返し回数が書かれている場合、その回数だけ行頭へ戻って同じ声明を読み上げることが指示されています。また、同時代のバロック音楽の楽譜にも、繰り返しの記号が登場します。

 

さて、条件と行動の組はどのように記述されてきたのでしょう。私はまだ古い例に出会えていません。しかし、繰り返しを指示することは暗黙的に条件と行動の組も含んでいます。つまり、読み手(プレイヤー)はいま何度目の繰り返しであるのかを意識する必要があり、「もしも」規定の回数に達していれば、繰り返しを止めなければならないためです。

 

あとは、コンピュータと楽譜の関係をもう少し確認しておきたいとおもいます。五線記譜法の演奏記号について、個々の記号の歴史を押さえられてはいないのですが、現在みられる反復記号としては「1番カッコ、2番カッコ」「ダ・カーポとフィーネ」「ダル・セーニョとセーニョ」「ヴィーデとコーダ」といったものを挙げることができます。いずれも、小節で区切られた楽譜の特定の位置で、特定の条件のもとに、別の指定位置へジャンプすることを示す記法です。

 

このような反復記号とコンピュータの仕組みとの類似性を示すのは、一見、簡単なようです。初めにみたよう、コンピュータのメモリ空間は小節のように区切りがあって、アドレス(番号)によって位置を特定することができ、分岐命令によってジャンプが行われます(ゲームブックの記法について)。1949年に生まれた最初の実用的なデジタルコンピュータ、EDSACの時点で、すでに分岐命令は搭載されていました。計算機の世界で分岐命令がいつ生まれたのか、デジタルコンピュータの開発が進められた1940年代なのか、もっと前のことなのか、私はまだ確認できていません。この演奏記号とデジタルコンピュータの分岐命令との間にある空白のことは知りたく思っています*1

 

さておき、コンピュータにおいて特定条件による指定の番号へのジャンプは重宝されてきましたが、今日まで利用され続けている場面と、一度は広く使われて今はもう廃れた場面のふたつに分かれることになります。今日でもCPUの命令セットには条件による指定番号へのジャンプが含まれます。一方、多くの開発者が触れる高級言語のレベルでは、番号を用いたジャンプを用いることは避けられています。80年代までのBASIC言語は初心者向け・教育用に広く使われおり、そこでは行番号よるプログラムの位置の特定と、IF THEN文による条件と動作の指示、そしてGOTO文による指定番号へのジャンプが用いられていました。この方法は構造化プログラミングの概念の普及とともに、今では使われなくなって久しいです。よっていま、条件に基づく番号へのジャンプという考え方は、ハードウェアに近いレベルで仕事をするエンジニアにとって日常である一方、それ以外のシニアエンジニアにとってはBASICの懐かしい思い出とともにあります。

 

IF THEN GOTO は、ソフトウェア開発には適した方法でないために廃れました。だからといって楽譜からダル・セーニョとセーニョが失われることにはなっていません(少なくともポピュラー音楽では)。ソフトウェア開発には例えば構造化プログラミングがあり、音楽にはまた音楽の最適な方法がとられるのだと思います。

 

さて、ゲームブックでは、パラグラフ番号によって文章の区切り位置を特定可能にし、条件に従って指定番号のパラグラフへジャンプする形式を取ることが多いです。こちらにもコンピュータの面影を確認することはできますが、楽譜と同様、昔と今のプログラミングが異なっている程度には、違ったものとなっています。一般に、コンピュータプログラムとゲームブックの目的は同じではないため、一度どこかで交差するところがあったとして、その後はそれぞれに適した独自の方法が追求されてゆくことに、不思議はありません。

 

対話についてのアンカー (5)

別の話を1つはさむつもりだったのですが、たまたま機会が巡ったので。機会というのは、ゲームブックにおけるコンピュータ以前・以後、とは?という吉田先生の話題で、最初の取り掛かりとしては《「フローチャートやパラグラフ選択」という形式自体がコンピュータプログラムから着想されたもの》ということでした*1

 

コンピュータプログラムとして制御構造を記述することについては、またいつもの話からはじめてしまいます。バロック音楽の頃から、音楽というストーリーを記述する楽譜はDa CapoとFineのような制御構造を持っていて、奏者(プレイヤー)がそれを解釈して、反復回数を任意にアレンジしながら音楽を演奏していたそうです。ある条件では繰り返して(Da Capo)、ある条件に達するとそれは終わりの分岐(Fine)へ進む。人間の記号的な思考様式にこういう制御構造がどうして紛れ込んできたのかずっと興味をもっています。

 

真か偽か、条件分岐に関わるブール代数が生まれたのは19世紀のことですが、それより昔のバロックの時代から、こうした条件分岐の記述は見られたといってよいと思います。

 

こちらもデジタルコンピュータが生まれるよりも前、1921年に提案されたProcess Chartでは、生産プロセスのフローを記述するためのノードと線を用いた記法が生まれていました*2。Process Chartはプロセスマネジメントにおける図解化の元祖であり、生産や業務のプロセスを図にすることで問題の発見と改善を促すことが狙いとなります。1921年の論文ではまだ明示的な分岐の概念は見られず、同時並行で進むプロセスの線が分かれて書かれることがあるだけでした。その後、1947年にアメリカ機械学会によってFlow Process Chartとして標準化されたときには、同時並行で進むプロセスの線が「Inspection」(検査)のアクティビティを伴うことによって、チェック項目別の処理が記述できるようになっています*3。これは一種の分岐といえるでしょうが、そもそも機械制御を目的とした設計図ではなくプロセスにおける人間と機械の活動(アクティビティ)を分析することが目的なので、いわゆるコンピュータ分野におけるフローチャートと同一視はできないところがあります*4

 

コンピュータ分野では、1947年にフォン・ノイマンらはプログラム内蔵方式のデジタルコンピュータにおけるプログラムの流れをノードと矢印を用いたFlow Diagramで記述しました。特に、コンピュータが数学的問題を解く際に必要とする反復処理を実現するためには条件分岐が必須であるとして、図の中に条件分岐を示すAlternative Boxを導入しました*5。コンピュータの分岐命令とコンピュータのプログラム設計のためのフローチャートの元祖は同時に生まれたといって差支えないでしょう。ただしこれは計算機の動作だけを記述するチャートであって、人間が選択肢を選んで分岐してゆくゲームブックの姿とはまだ異なっているといえます。誕生当初のデジタルコンピュータは対話的でなかったため、人間が処理の途中で分岐を選ぶ余地はほとんどありませんでした。

 

人間とコンピュータが対話しながら処理を進められるようになったのは前々回述べたようにタイムシェアリングシステムの登場からで、1961年以降、遅くとも1964年のProject MACではコンピュータ側から「○○を入力してください」とプロンプトを出すプログラムがあったことを確認できます。そして1966年には人と対話するプログラムであるELIZAが広く世に知られることになりました(前回登場したあのイライザにちなんだ名前です)。

 

コンピュータから人間に質問できる時代になったのがいつであるかは定めておきたいと思います。そうすると、1964年のProject MAC、1966年に知られるようになったELIZA、という流れの上に、1967年にレーモン・クノーが「あなたまかせのお話」でやったことはすっと繋がってきて思えます。

1 三つの元気なお豆さんの話を聞きたいかい? 「はい」なら,4へ 「いいえ」なら,2へ

クノーはブール代数のことも意識していたようですが、ここでは形式として「対話」が用いられていることに注目したいと思います。

 

人間が行為者として参与するフローまたはプロセスにおける制御構造の記述は、楽譜のなかにもフローチャートのなかにも、つまりコンピュータ以前の文化的社会的生活のなかにわりとみられたわけです。そうすると、コンピュータがゲームブックにもたらしたものとは、まず、言語を用いた人工物(書籍)との対話だった、としてみたく思えます。

 

文章をパラグラフによって切り刻むことは、実際、書籍というものを、メモリ空間にアドレスの刻まれたコンピュータと同じような人工物へ、変えてしまうことでした。

*1:《ゲームブックという形式(形態)はコンピュータ以前にはありませんでした。原理的にはそれ以前にもありえたはずですが、実際に存在していませんでした。理由は「フローチャートやパラグラフ選択」という形式自体がコンピュータプログラムから着想されたものだからです。コンピュータから書物への影響。》— YOSHIDA Hiroshi 吉田寛『デジタルゲーム研究』発売中 (@H_YOSHIDA_1973) 2024年5月12日

*2:Frank B. Gilbreth, "PROCESS CHARTS" https://www.thegilbreths.com/resources/Gilbreth-Process-Charts-1921.pdf

プロセスマネジメントにおける図解化の歴史については、BOURNE and WEAVER, "The origins of schedule management: the concepts used in planning, allocating, visualizing and managing time in a project" https://journal.hep.com.cn/fem/EN/10.15302/J-FEM-2018012

プロセスの図解はギブリスのProcess Chart以前にもたくさん存在していることが、次のページで紹介されています。User:Mdd/History of flowcharting - Wikipedia ギブリスのチャートはのちのアメリカ機械学会(ASME)による標準化につながるものとして価値があると思われます。

*3:https://babel.hathitrust.org/cgi/pt?id=mdp.39015039876274&seq=1

*4:フローチャートとUMLにおけるアクティビティ図との違いのようなものです

*5:Goldstine and Neumann, "Planning and Coding of Problems for an Electronic Computing Instrument" https://www.ias.edu/sites/default/files/library/pdfs/ecp/planningcodingof0103inst.pdf

対話についてのアンカー (4)

これは会話型インタフェースにまつわるメモですが、同時に「対話」という言葉も採らなくてはならない状況について、そろそろ触れてゆく必要があります。論点が広く、それぞれに深められてもいないので、今はただアンカーを打っておくだけの部分が多くなります。しかし、この記事のシリーズはそのためにあるものです。

 

対話をdialogueのことだとするならば、対話(dialogue)と会話(conversation)の違いについて、二人で話をすることを指すか、それ以外も含めるかという表層的な違いは大切に思えます。なぜならば、人とコンピュータのやりとりについて言えば、そのほとんどがまだ二人で話をするdialogueの域を超えられていないためです。

 

コンピュータが三名以上の会話に参与することがあまり見られない理由は幾つもあります。一つには、複数人とスムーズに話を進めるために必要な身体をまだ十分に持ち得てない点があります。(この話題は一旦アンカーを打って、またいつか戻って来ることにします。)

 

コンピュータからはまだ遠い場所にある会話にまで射程をとりたいが、一方、現在のコンピュータについて考えるときには対話という言葉が向いているというのが冒頭に述べた状況なのかなと思えます。加えて、対話的(interactive)という訳語もよく現れるのです。この2つの言葉を自分がコンピュータの文脈においてどう使い分けてるのかは、いまようやく考え始めたところです。

 

もう一つアンカーを打っておくと、コンピュータの画面上の絵として複数の人物がいて、動いて会話する様子をわたしは見て、聞いている。そうした形での会話的な状況は少なからず見られます。いまあえて会話型インタフェースという呼び名を採用するのは、この場面を意識してのことです。

 

このシリーズの冒頭、「人工物と会話するという観点」について「鍛冶師は鉄を叩くことで鉄器と会話するという気持ち」というたとえがすっと出てきたのは、いま「クプルムの花嫁」がお気に入り漫画であるからに違いないです。それにしても、interactionについて再び取り上げると、人工物との対話(interaction)について考えることと、会話する(conversational)人工物について考えることはだいぶ違っていて、後者も古くから想像や伝説のなかにありました。人間の命令を聞くゴーレム、あるいは、きちんと確認はしてないのだけどギリシャ神話の動く彫像たちも言葉を発するものが居たのではないでしょうか。これらは本来静物であるものが人のように動くという怪異の物語であって、彫像が人間の女性として命を得るピグマリオンの伝説はその究極的なものと言えそうです。しかし、人工物の会話能力に対して人間のような知性を見つける物語は、もっと時代を下るといえるでしょうか?

 

フランケンシュタインの怪物は、その言語獲得能力が知性の証として描かれていたようです(未読)。ギリシア神話のピグマリオンは幾つかの戯曲に翻案され、「マイ・フェア・レディ」として今よく知られる形では、音声学者が(上流階級の)「人間のような」言葉を教えることで下町の娘さんを(上流階級の)「人間」に仕立てあげようとする筋へと変わりました。

 

ヒギンズ教授がイライザを「テスト」の場に出した様子は、どこか聞き覚えがあるようです。上流階級のパーティーで、イライザの「会話」ははたして参加者をだまし通せるのか。そう、チューリング・テストとはそういうものであったように思えます。

 

チューリングの思考実験は、機械の知性を会話のみで測る点が画期でした。このことで、コンピュータとの会話という文脈において、動く彫像のイメージはいったん保留され、そのままいまに至っているところがあります。ただ、人間らしさ?を会話だけで測れるのかどうか。マイ・フェア・レディにおいてヒギンズ教授の知性観が敗北で終わるという筋は知られているところです。

 

チューリングはなぜ、動く彫像(ロボット)相手の会話ではなくテレタイプ越しの会話で知性を測る考えに至ったのでしょう。西垣通がそのへんのことを話してそうだったのでいま「デジタル・ナルシス」を読んでいて、西垣の観点を借りるなら、チューリングは《自然》の対立物としての《人工》にエロス(怪異)を見出しておらず、自然イコール機械という思想を持っていたからということになりそうです。人間の思考から肉体にいたるまで機械と同一とみなせるため、会話を採り上げたのは単にその普遍性の一部を切り取ったに過ぎないということかもしれません。

 

テレタイプ越しの会話で知性を測るという、この制約の大きな思考実験がその後ひろく支持されたのは、なぜだったのでしょう。実際に実施可能な手続きを示したということはあると思います。あとはどうも、顔が見えないメディア越しの会話に人がロマンチックを抱きがちだというのもありそうです。

 

対話についてのアンカー (3)

「対話」という言葉について確認しておくと、それはデジタルコンピュータの歴史において「ユーザとコンピュータのインタラクティブなやりとり全般」を指す比喩としても使われましたし、人間同士の対話に近いことを人間とコンピュータの間に実現する意味でも使われてきました。

 

1960年の「Man-Computer Symbiosis」(ヒトとコンピュータの共生)で、リックライダーは人間とコンピュータが緊密に連携しながら知的な活動を行うための条件を幾つか挙げました。一つは処理速度の課題であり、これは Time Sharing System (TSS)による解決が期待されていました。ここで最後に挙げられていたのが入出力装置の課題で、そこでは「対話」という言葉の幅を窺うことができます。

まずは、現代でいうタブレットとペンのような入出力装置がほしい。これは「effective man-computer interaction」のための課題としています。

次に、複数の人が共同作業する場にコンピュータが参加するための壁面ディスプレイがほしい。これは「cooperation between a computer and a team of men」のための課題としています。

最後に、自動的な音声合成と音声認識によるコンピュータとの意思疎通に触れています。これは「speech communication between human operators and computing machines」のための課題としています。

以上では、interaction、cooperation、communicationという言葉が登場しています。いずれも日本語では対話と関わりのある語といえますが、特にコンピュータの世界ではinteractionにあてられる日本語訳として「対話」がよく採用されています(これは誰が最初に訳したのでしょうね?)その一方で、タブレットとペンのような入出力装置を用いたやりとりを対話と呼ぶことは、この3つの言葉の中でもっとも比喩的であるように感じられます。音声で意思疎通することのほうがより直截に対話と呼べないでしょうか。

 

interactionに対して日本語の「対話」という言葉をあてるとき、わたしたちが「対話」として感じ取れることの幅は少し広がっているのではないかという気がしています。

 

リックライダーが旗を振ったその後の人とコンピュータの対話の様子について、Project MAC(1963年~)で確認しておきたいと思います。Project MACはリックライダーの資金提供によってMITのロバート・ファノが開発を進めたTSSで、最初期のTSSであるCTSSの後継とされています。Project MACは文献や実機デモの様子が残っているため、当時の様子がある程度わかります。

こちらの動画の5:15あたりから、ファノ本人がデモをしてくれます。端末はテレタイプで、タイプライターのようなキーボードから入力した内容は電話回線で繋がったリモートのコンピュータへ送信され、コンピュータからの応答が印字で返ってきます。

Robert Fano explains scientific computing (youtube.com)

1964年のプロジェクト進捗報告書では、このデモの内容を文字で確認できます。動画では何が印字されているのか判らないため有り難いです。

THE MAC SYSTEM: A PROGRESS REPORT (dtic.mil)

進捗報告書では、まずABSTRACTにおいて人間とコンピュータの共同作業のありかを「dialogue」と呼んでいることには注目しておきたいですね。

The notion of machine-aided cognition implies an intimate collaboration between a human user and a computer in a real-time dialogue on the solution of a problem,

Fig.2dにあるのは、素数を求めるプログラムをユーザが実行したときの様子です。下では判りやすいよう太字がユーザの入力、緑のItalicコンピュータの印字した応答としました。

resume prime
W 1112.0
# EXECUTION.

TYPE RANGE N1. TO N2. ON 2 LINES
1000000.
1001000.
PRIMES ARE
1000003
1000033
1000037
1000039
1000081
1000099
1000117

(以下略)

resume primeは、prime(素数を求めるプログラム)の実行を指示しています。

Wはコンピュータが指示を了解したことを示す応答で、その時刻が後ろに続いています。

その後、コンピュータは「TYPE RANGE N1. TO N2. ON 2 LINES」つまり、求める素数の範囲を2つの数字で2行に分けて入力するようにユーザに要求します。ここは原文では次のように説明されています。

The PRIME program asked for the numbers N1 and N2 defining the desired range of prime numbers;

コンピュータがユーザに対して ask していますね!

ユーザが1000000と1001000を入力すると、コンピュータは「PRIMES ARE」から始めて1000000と1001000の間にある素数を全て応答します。

 

コンピュータがその場で質問を返してくるこの体験は、マッカーシーが述べていたような1回の入力から応答まで3時間から36時間はかかるコンピュータとのやりとりとは大きく異なっていますね。

 

もともとチューリングによる思考実験の水準では、テレタイプ越しにコンピュータと対話することが語られてはいました。その後、実際にテレタイプ越しでリアルタイム利用できるTSSが生まれたとき、これこそが人間とコンピュータが言葉で「対話」している様子なのだということを、ようやく実機の存在をもって論じることが可能になったようです。これが、アンカー(1)で触れたJohn Walkerの整理によるTSS世代のユーザインタラクションなのでしょう。

 

対話についてのアンカー (2)

Time Sharing System(TSS)についてアンカーした点を埋めてゆきたいと思います。

 

TSS前夜としては、そのアイデアを記したジョン・マッカーシーのメモ(1959年)が広く知られています。当時のデジタルコンピュータが実際どう使われていて、今後どう使えたらもっと嬉しいのかということが背景として綴られています。

Memorandum to P. M. Morse Proposing Time-Sharing (stanford.edu)

*1

こちらのメモから注目したいことを数点挙げておきます。

Computers were originally developed with the idea that programs would be written to solve general classes of problems and that after an initial period most of the computer time would be spent in running these standard programs with new sets of data.

デジタルコンピュータが生まれた当初の想定として、まずは汎用的な問題を解決できるプログラムが開発されて、完成後はそのプログラムを用いて新しいデータセットを解くことにコンピュータの時間は費やされると考えられていた、ということでしょうか。

1950年前後の初期のデジタルコンピュータがこの想定だったとすると、それは現代の私にとってピンとはこないのですが、どうだったのでしょうか。しかし、その後間もない1956年にマッカーシーが人工知能という名前を示したこと、1957年にはサイモンとニューウェルが汎用の問題解決プログラムの一種(GPS)を開発したこともあって、デジタルコンピュータの最初の10年は汎用的な問題解決能力を持つ人工知能の検討とも切り離せない揺籃期だったようには思えます。

This view completely underestimated the variety of uses to which computers would be put. The actual situation is much closer to the opposite extreme, wherein each user of the machine has to write his own program and that once this program is debugged, one run solves the problem. This means that the time required to solve the problem consists mainly of time required to debug the program. 

しかし、現実はそうでなかった、というのが論旨となっています。実際には、ユーザごとに自分が解きたい問題のためのプログラムを書く必要がありました。完成したプログラムが存在しない場合、ユーザは自分のプログラムをデバッグしながら完成させる必要があります。つまり、ここで問題解決にかかる時間とは主に、このデバッグのための試行錯誤に掛かる時間になっているということです。

ここでは、当時のユーザとコンピュータの間で発生しているやりとりが、ほとんどデバッグであったという様子を窺えます。マッカーシーのTime Sharingはこのデバッグのために必要なやりとりの速度を改善するアイデアで、従来は入力から応答まで3時間から36時間までかかっていた人的・機械的手続きを数秒程度に短縮することを目指しています。

 

この Time Sharing の実現のために必要な装置は次のものです。

a. Interrogation and display devices (flexowriters are possible but there may be better and cheaper).

デバッグのためにコンピュータを操作し、素早い応答を得て、試行錯誤できること。この操作をマッカーシーは「Interrogation」と呼んでいることに注目したいと思います。Interrogationとは、質問をする、特に系統だった質問をすることを言います。マッカーシーの感覚では、コンピュータに対して人間に行うよう「Interrogation」の語をあてるのは、自然なことだったわけです。

マッカーシーとしては、コンピュータがいずれ知的な相手になるものと考えていたから出てきた言葉だったのかもしれません。

*1:宛先のP.M.Morseは当時のMIT計算センターの所長であり、このメモはセンターに次年度導入予定のIBM 709の用途に関する提言となっています。 Project MAC (archive.org)