また，voiscape においてもとめてきたのは 「みとおし (ききどおし?) のよいコミュニケーション」 でした． 電話や会議システムのような従来のコミュニケーション・メディアにおいては，それをつかっておこなわれる会話はみとおしのわるいものになってしまいます． 電話であれば基本的には 1 対 1 でつながるだけなので，第 3 者にとってはその会話はまったく認知できないか，または，会話しているふたりのうちのひとりに物理的にちかい場所にいればそのひとりの話がきこえるだけなので，いずれにしても，それがそのひとにとって関係のある会話であっても，みとおしのわるいものになってしまいます． また，会議システムも閉じた会話のためのメディアなので，立ち話やカクテルパーティのように第 3 者がはいりこめる余地はありません． 第 3 者にとっては，会話の内容はおろか，会話がおこなわれていることを知るのも困難です． こういうみとおしのわるさを (なくすとまではいえませんが) へらすため，voiscape においてはひとつの部屋のなかで複数の会話が同時進行できるしかけをつくっています．
また，軸づけ検索や voiscape におけるのとはかなり意味はちがいますが， CCM においては通常の論理にもとづく計算のみとおしのわるさを解決するために，エネルギーが最小化する方向に計算がすすむようなしかけをとりいれています (CCM では 「エネルギー」 ではなく 「秩序度」 ということばをつかっていました)． 論理にもとづく計算ではちょっとしたバグのために計算がとんでもない方向にすすんでしまう (暴走する) ことが容易におこりますが，最小化のしかけをいれることによってこういう事態をふせぐ意図がありました． ただし，このような最小化のしくみをとりいれた計算モデルとしては，ニューラルネットや遺伝的アルゴリズムが有名であり，ほかにもおおくの計算モデルがあります．
CCM における 「みとおしのよい計算」 はべつとして，軸づけ検索や voiscape における 「みとおしのよさ」 はユーザからみえるものであり，デジタル・コンピュータをつかったコミュニケーションや計算が本質的にかかえている問題点を部分的ながらも解決しようとしています (この問題点は，いまはうまく説明できませんが，おそらく私が 「ライフワーク」 と呼んだ“デジタルとアナログの融合” や “記号と記号下のものの融合” と関係しているものとおもいます)． Web や携帯電話やその他のデジタル・メディアからおこっている問題のおおくがここに起因していると私はかんがえています． したがって，それを解決することは現代社会がかかえる問題への解決策を模索することだとかんがえています．
こう書くといささかおおげさにひびくかもしれませんが，技術的な問題解決なしにデジタル・メディアがうみだす社会問題の解決はできないようにおもいます． つまり，現在の携帯電話は集中制御型のシステムなので，規制することによって問題がおこらないようにすることはできるかもしれませんし実際に日本政府による規制がはじまっていますが，インターネットのような分散制御型のシステムにおいてはうまく規制することができないとおもえます． みとおしのよさをのぞまないひとをこういうしかけのなかにとりこむのは困難ですが，それでも，みとおしをよくすることによって，ある程度は解決できるものとおもいます．
]]>2006 年度の成果はすでに研究会論文などに書きましたが，それらについてはブログの 「デジタル音声再生は，ひとすじなわではいかない」 という項目にも書きました． 来年 1 月には ICOIN 2008 という，釜山でひらかれる国際学会でも発表することになっています． しかし，個々の論文に書いたことはこの 1 年間にやったことの一部でしかありません． 1 年間でいったい，なにをやろうとしたのかという，それらの論文にまたがることは，論文には書く場所がありません． それは国プロの報告書には書いてよいはずのことですが，3 月ぎりぎりまで実験をしていたので，ゆっくりふりかえって書く時間もなくて，書かずじまいになってしまいました． また，もし仮に国プロの報告書に書いてあったしていも，それにふれるひとはすくないので，もっとひとの目にふれるこの場所で書いてみようというわけです．
プロジェクトは 2005 年度からスタートしていますが，この年には私は担当していませんでした． したがって，私にとっては 2006 年度が初年度でした． このプロジェクトではポリシーにもとづく NGN 的な意味でのネットワーク QoS の制御 (資源とアドミッションの制御) がテーマになっていました．
QoS に関しては多数の論文が出版されていますが，そのなかには理論的な論文やコンピュータ上でのシミュレーションにもとづく論文がおおく，実際にバックボーンでつかえるような機器をつかったネットワークに実際にトラフィックをながして測定・評価した論文はすくないのです． また，実際に測定をおこなっている場合でも，比較的小型のルータやスイッチを使用して，トラフィック量も 100 Mbps 以下のことがおおいのです．
精密なシミュレーションをおこなえば実際に測定しなくてもわかるということかもしれませんが，現実のネットワーク機器やサーバが理論どおりに動作するとはかぎりません． バグがあればもちろんですが，そうでなくても理論からずれてくる可能性はいろいろかんがえられます． したがって，この仕事をはじめるにあたって，私は実際の機器とプログラムとを使用して実測にもとづいて評価したいと，つよくおもいました．
また，QoS というのは最終的には通信をおこなうユーザがその品質に満足するかどうかで評価するべきものなので (そういうときには QoS というよりは QoE (Quality of Experience) ということばがつかわれますが)，上記のような客観的な評価だけでなく，被験者をつかっての主観的な評価までやりたいとおもいました． 会社の仕事ではなかなか主観評価にまで予算を用意することがむずかしいのですが，国家プロジェクトの利点はそこまで予算がかけられることです． その利点をぜひ，いかしたいとおもいました． 主観評価のためによくやる方法は社員をかきあつめてきて自分で実験するというやりかたですが，そうしなかったのは第 1 には私自身は経験がないのでそういうやりかたではうまくやれる自信がなかったし，ひとりで実験できるともおもえなかったからです． また第 2 には社員をあつめればみかけ上はコストがかからないのですが，実は時間給を計算すれば非常にたかくつくからです．
そういうわけで，今年 2 月までにプログラムを開発して実験用のネットワークを組み，3 月には客観評価と主観評価とをおこないました． 先端的なルータをまとまった期間借りるということはなかなかできなかったので，GS4000 というハイエンドの L3 スイッチを借りました． それも 1 台だけしか借りられなかったので，くふうして実験用ネットワークを組みました (そのために結果の透明性が低下して，国際学会への投稿でも評価がさげられる原因になってしまったのですが…)．
また，バックボーンでつかえる技術をめざした開発なのでほんとうは 10 Gbps のリンク (10 ギガビットのイーサネット) をつかって実験したかったのですが，断念しました． というのは，のぞみの性質をもった 10 Gbps のトラフィックをうまく発生させられる自信がありませんでした． そのため，1 ギガビットのイーサネットを使用し，3 台の PC を使用して MMPP (Markov-Modulated Poisson Process) というモデルにしたがう 1 Gbps 程度のトラフィックを発生させて実験しました． この MMPP というモデルはシミュレーションにおいてはよくつかわれているのですが，それにもとづいて実トラフィックを発生させた例はすくないようです． それにどれだけの意味があるのかは検討が必要ですが，やってみる価値はあるとおもいます．
そうやって評価した結果の一部を研究会などで発表してきたわけです． 期間がかぎられていたので，かならずしも目標どおりにはいきませんでしたが，それでも一応，QoS 保証法の設計からプログラム開発，客観評価・主観評価という一連のプロセスを 1 年間でなんとか，まわしました． もちろん，それができたのは，おおくのひとの協力があったからにほかなりません (論文には謝辞にそれらのひとの名前が書いてありますが，ここでは省略させてもらいます)． そして，客観評価と主観評価のそれぞれにおいて，ある程度の成果をえることができました． このうちとくに主観評価については書いておきたいエピソードもあるのですが，それについてはべつの項目，あるいは別の機会にゆずることにします．
]]>こういう，研究テーマ選択における，あまいかんがえかたは，その後しだいにあらためていきましたが，まだ十分ではなかったようにおもいます． 1990 年代に私は軸づけ検索を研究しましたが，これはもともと百科事典のために開発したものであり，その線にそって製品化されました． しかし，これも利益をうみませんでした． つぎに手がけた研究はポリシーにもとづくネットワーキングと QoS 保証でした． これは私が提案したものではありません． 製品化されましたが，予想どおりにはいかず，やはり利益をうみませんでした．
結局，これまで私がてがけた研究で会社に利益をもたらしたものはほとんどありません． その出発点がバブル時代だったとおもっています． しかし，こうやって，しだいに (おそすぎたかもしれませんが) テーマのえらびかたに関しても訓練されてきたようにおもいます． もう会社で仕事ができる年月はあまりながくないのですが，社会と会社に貢献できる研究ができる可能性はたかまっているようにおもいます．
]]>これらのかんがえかたのうちのどちらをとったほうがよいかは，ときとばあいによります． しかし，私自身は基本的なかんがえかたとして，コンピュータには人間ができないことをやらせるべきだとかんがえています． これに対して，私がこれまで話をしてきたおおくのロボット研究者はロボットに人間とおなじように仕事をさせた，あるいは人間ができる仕事をよりよくやらせたいとかんがえていました． 人工知能や認知心理学のおおきな目標として人間の知的な能力を解明することがあるので，その実現のためにはこのようなアプローチがよいでしょう． しかし，工学者である私にとっては人間が不得意な部分をコンピュータやロボットにやらせることによって，全体としてよりよく仕事ができるようにすることが目標でした．
こうしたかんがえかたが軸づけ検索や voiscape の研究にどのように反映されたかについては 「ユビキタス・コンピューティングとエージェント指向コンピューティング」 に書いたので，ここではくりかえしません．
2007-10-11 追記:
「人間にできない部分をおぎなうコンピュータ」 は，同時に 「人間の能力をひきだすコンピュータ」 であるべきです．
つまり，人間ができる部分は人間がやるようにするわけなので，そこを人間がうまくやれるようにしないと，ボトルネックになってしまいます．
人間がやる部分についてもできるだけ人間をたすけることによって，パフォーマンスを最大化することができます．
エージェント指向コンピューティングの思想は現在でもコンピュータ科学・技術の世界におけるひとつの主要な思想です． このかんがえかたにおいては，ひとがエージェントに仕事をたのんで楽をすることをかんがえます． 「エージェント」 ということばは 「代理者」 つまり仕事をかわってやってくれるひとということですが，秘書のようなものだとかんがえればよいでしょう． 自分ではできない仕事を秘書にかわってやってもらう． やってもらうことによって秘書の能力はさらにたかまるでしょうが，依頼者は学習しない，したがってバカになってしまうかもしれません． これに対してユビキタス・コンピューティングは個人のパワーを道具によってたかめることをめざしていました． パワーがたかまれば，むずかしい仕事が自分でできるようになります． つまり，人間の能力をよりよく発揮できるようにします． 仕事をやる過程で学習して，そのひとの能力がたかめられます．
仕事の種類や，ときとばあいによってエージェント指向とユビキタスのうちどちらがよいかはかわるでしょう． しかし，抽象的にかんがえるかぎりは，(誇張的な表現ですが) 私には人間をバカにするエージェント指向より人間の能力をたかめるユビキタスのアプローチのほうが魅力的におもえます． そのため，私はこれまで研究テーマのうえで 「知的なエージェント」 をあつかったことは一度もありません． なにか判断したり選択したりする必要があるとき，エージェントがそれをやるのでなく，人間が判断や選択をしやすい状況をつくることをめざしてきました．
軸づけ検索においては 検索結果を整理してユーザにみせることによって，ユーザがよりおおくの情報から選択したり，情報どうしの関係をみつけたりすることができるようにすることをめざしました． また，voiscape においてはさまざまな音源のなかからほしいものを，自動的にすなわち知的エージェントがえらびだすのではなく，おおくの音源のなかからユーザが選択できるようにすることをめざしました． これらの研究はまだ十分な成果をあげているとはいえませんが，これらの 「ユビキタス」 にもとづくかんがえかたは，これからも追究していく価値があるものだとおもっています．
* ワイザーがユビキタス・コンピューティングとエージェント指向コンピューティングとを対立的にかんがえていたといういいかたは，もしかすると誇張かもしれません． Weiser [Wei 93] にはつぎのような表現があります．
Unlike the intimate agent computer that responds to your voice and is a personal assistant, ubiquitous computing takes place primarily in the background. Whereas the intimate computer does your bidding, the ubuquitous computer leaves you feeling as though you did it yourself.
しかし，ワイザーがこれ以上の対比的な表現をつかっていたかどうかについては私はしりません．
[Wei 93] Weiser, M., "Hot Topics: Ubiquitous Computing", IEEE Computer, Vol. 26, No. 10, pp. 71-72, October 1993.
]]>製品を開発する技術者は設計・製造に必要な知識を獲得して，実際にそれを設計します． 企業研究者もそれにちかい作業をおこないますが，現在の製品の開発に埋没することなく，より応用のきく技術を開発する必要があります． そのためには，製品開発のなかでぶつかる課題を分析して，より普遍的な問題をみつけだす必要があります． そのためには，ぶつかった課題を数理的にモデル化 (抽象化) することが有効です． 適切なモデルをみつけて，それにあった手法を適用する必要があります． 適切なモデルをみつけるためには，さまざまな数理モデルを知っている必要があります． 重要なモデルは大学で学習しますが，さらに学習をかさねることによって，よりさまざまな状況に対応することができるようになります． 研究にかぎらず企業での仕事の際に問題をモデル化しなさいということを，私も東大在学中に講義をきいたことがある，すでになくなられた米田信夫先生がプログラミング・シンポジウムでおっしゃっていたのをおもいだします．
たとえば，私は入社してまもなくベクトル計算機のための Fortran コンパイラの開発 (ベクトル / 並列計算機のためのプログラミング言語処理) に従事しましたが，ここでプログラムのベクトル化 (並列化) が可能かどうかを判定するアルゴリズムを開発して，実際にコンパイラにくみこみました (Compiling Algorithms and Techniques for the S-810 Vector Processor)． この課題は入社したての私にとって適切なものでした． モデルとしてはコンパイラの本によく書いてあるデータフロー解析のためのプログラムのモデル (基本ブロックを単位とするグラフ) をつかうことができました． 既存のコンパイラにおいてすでに基本ブロックへの分割がなされていて，かつ手順としては通常のデータフロー解析の手順をあてはめればよかったので，私の仕事はほとんど各基本ブロックにわりあてるべき変数をみつけることだけでした． さいわい，データフロー解析の手順を適用することによってベクトル化可否がこたえとしてえられるような変数をみつけることができました．
つぎの Fortran コンパイラの開発 (スカラー計算機のためのプログラミング言語処理) においても，データフロー解析のモデルがやくにたちました (大域配列データフロー解析法) が，詳細はここでは省略します． この開発ではまた，整数論やそれをとくためのディオファンタス方程式をモデルとしてつかいました． これらもまた，まえのコンパイラをてがけていたときにしいれた知識です．
最近ではこれほど数学との関係が明確なモデルがつかえなくなって，やや，みとおしのわるい仕事をするはめにおちいっています． もしかすると，もっとちがったモデルを学習するべきなのかもしれません．
]]>非決定論は自由意志や時間論とも関係しています．決定論的な世界には意志によってかえられるものがありませんし，時間の矢つまり一方向にすすむという性質がありません． 私は高校生のころから時間というものに興味があって，時間論の本をいろいろ読んでいました． それよりずっとあとになってからですが，プリゴジンの理論，あるいは自己組織の理論やベルクソンの哲学に興味をもちました． 非決定論という意味ではもちろん量子力学とおおいに関係があります． 理論的な関係は把握していませんが，インフレーション宇宙論などとも関係しているようにおもいます． 上記のような哲学的な問題はやはり非決定論的 / 確率的な動作とむすびついています．
なお，上記のような考察の一部は「コンピュータによる自己組織系のモデルをめざして」のなかでもっとくわしく展開しています．
]]>このころはまだ現在の GUI の技術が確立されていたとはいえないとおもいますが，それでも，現在おおくの GUI ライブラリがそなえている機能が Macintosh Common Lisp にはありました． テキストボックスや各種のリスト，メニュー，ウィンドウ等々です． しかし，私自身はそれらの静的なしかけだけでは満足せずに，もっと動的に変化するインタフェースを実現しようと悪戦苦闘し，その結果たいした成果もだせずにおわってしまいました．
この不毛な経験のため，もうユーザインタフェースに手をだすのはやめようといったんはおもいました． そのためしばらくはそこからはなれていましたが，百科事典の検索をデモするために，ついにふたたびそこに手をだしてしまいました． このとき (1997 年) にはすでに Web インタフェースのための基本的なしかけ，すなわち CGI の技術が確立していて，それをつかえば VIPS を開発したころよりずっと容易に GUI をつくることができるようになっていました． スタイルシートがまだなかったので，みばえをよくしようとおもうと容易でなかったのですが，そこまでやろうとはおもいませんでした． CGI のためには Perl をつかうのがよいときいたので，そのために Perl をおぼえました．
こうしておぼえた Perl + CGI による Web インタフェース作成術は，その後たびたびつかっています． DEPS というポリシーサーバのインタフェースにもつかっていますし，発表はしていませんが voiscape の管理インタフェースや実験用インタフェースにもつかっています．
Java をつかって GUI をつくろうとしたこともありましたが，なかなかおもうようにプログラミングできないので，やめてしまいました．
最近では Perl + CGI というしかけはだいぶ，ふるびてきたので，そろそろもっとあたらしい技術にのりかえようとかんがえていますが，それでもチョロッと GUI をつくるには便利なので，あいかわらずつかっています．
]]>軸づけ検索のひとつの技術的要素は全文検索ですが，高速性を要求される全文検索のプログラムも Perl で書きました．CPU 時間よりはディスク・アクセスの時間のほうが問題なので，インタプリタで実行される Perl であっても，プロトタイプとしてはなんとかたえられるレベルにありました． むしろ，インデクスを格納するのにつかった GNU DBM がおそくて，検索にけっこう時間がかかるばあいがありました．
検索・組織化のプログラムだけでなく，検索に使用するインデクスをあらかじめ生成するのにも Perl をつかいました． ここでは，百科事典のテキストから年代表記や地名などを抽出するのにパターンマッチ機能が威力を発揮しました． 「テーマ検索」の製品における検索ではより高速性がもとめられるので Delphi をつかいましたが，そこでもインデクスの生成には Perl をつかっていました．
その後すっかり仕事がかわってルータにコマンドをたたきこむ QoS ポリシーサーバなどを開発するようになりました (ポリシーにもとづくネットワーキングと QoS 保証) が，このときも，プロトタイピングには Perl をつかうのが便利でした．理由は軸づけ検索のときとおなじでした．つまり，ルータの CLI (コマンドライン・インタフェース) がはきだす文字列を解析するには Perl のパターンマッチ機能が便利であり，また GUI (ユーザインタフェース) には CGI をつかうのが便利だったということです． このころには Python とか Ruby とか，Perl よりよくできた部分があるスクリプト言語がつくられていましたが，なれた言語をてばなすことができず，いまだに Perl をつかっています．
その後，voiscape についてはおもに Java や C++ をつかいましたが，voiscape サーバのための管理インタフェースなどには Perl をつかっています．最近はまたポリシーサーバなどをあつかっているので，Perl が中心になっています． QoS の主観評価をするときも被験者やオペレータのための GUI を Perl で書いています． 最近はカッチリと Web インタフェースをつくるには Struts や ASP.NET といった Web アプリケーション・フレームワークをつかうことがふえてきています．私も製品にちかいプログラムの開発ではそれらをこころみてはいます．しかし，プロトタイピングや短期間だけつかう GUI を開発するには Perl のほうが便利です．
]]>私が入社して最初にとりくんだ仕事はスーパーコンピュータ (ベクトル計算機) で Fortran プログラムが実行できるように変換し最適化する方法を開発すること (ベクトルのためのプログラミング言語処理) でした． この仕事は会社が開発していた S-810 というスーパーコンピュータ製品に直結するものでした． 当時，私はまだ論文の書きかたも十分にマスターしていなかったので，研究成果を十分なかたちで世におくりだすことはできませんでした． しかし，この研究は研究リーダーだった安村さん (現慶応大教授) 中心の ICPP の論文 につながり，また情報処理学会全国大会で発表しているので，(事業収支はともかくとして) ビジネスと研究を両立させることができたということができます．
論理 / 記号 ベクトル処理の研究は，Fortran のために開発した技術を非数値処理 (記号処理) にいかそうという意図をもって，私が会社に提案してはじめた研究です． ビジネス上の目的としては，Fortran コンパイラと同様にベクトル計算機の適用範囲をひろげることにありました． Fortran とはちがってベクトル計算機に適用することがむずかしい論理型言語や記号処理があつかえるようにする必要があったので，たかい成算があったわけではありません． また，目標が達せられたとしても，それほどおおきな利益がえられるともかんがえてはいませんでした． つまり，会社の技術力をたかめることが間接的にビジネスの拡大につながることを期待していました． しかし，結果的にはそういう意味においてもビジネス的に成果をあげたとはいえませんでした．
化学的計算のモデル (CCM) も私が会社に提案してはじめた研究です． 私の研究テーマのなかでももっともビジネスからとおいテーマでした (つまり，ビジネスとの関係を説明できなかった) が，提案時はまだバブルがはじけるまえであり，時代的にこのようなテーマでもみとめられたのだとおもわれます． このテーマはその後，私が国家プロジェクトの RWCP (Real-World Computing Partnership) に出向して，そこに場をうつして継続しました． これは，私が提案したわけではなく，あるいきさつがあってそうなったのですが，バブルがはじけたあとの先物研究のあつかいとして妥当だったとかんがえられます．
ランダムな非同期セル・オートマトン (RACA) は CCM の副産物だったのですが，CCM が実用的な計算をめざしたモデルだったのに対して，これは複雑系的な興味による研究であり，実用はまったくかんがえていませんでした． RWCP にいたので，会社のビジネスについてかんがえる必要はありませんでした．
RWCP から会社に復帰したときには，もはやビジネスにつながりにくい研究をすることはかんがえにくくなっていました． 電子商取引や，AltaVista のような Web の検索エンジンが注目されるようになっていて，Web 上の検索やデータマイニングというような方向の研究を模索しましたが，結局はちょうど社内でもちあがっていた百科事典の仕事をすることにおちつきました． 百科事典の検索は Web の検索とはちがいますが，共通する部分もあります． 単純な項目・索引検索や全文検索の技術はすでにあったので，もっとおもしろい検索法を開発することが目的であり，研究とビジネスの目的がかさなりあっていました． そこでかんがえだしたのが軸づけ検索 (テーマ検索) でした． しかし，結局は単純な検索より人気のたかい検索法に発展させることはできず，ビジネスとして成立はしたものの，会社の利益に貢献することはできませんでした．
その後，ネットワークの仕事をあたえられて，おもわぬ方向転換をすることになりました． ポリシーにもとづくネットワーキングと QoS 保証というテーマは IPA (当時の名称は情報処理振興事業協会) の仕事としてはじまりましたが，やがて HP 社との協業 (collaboration) による PolicyXpert というポリシーサーバ製品の開発につながっていきました． QoS ポリシーの研究をはじめて以来，私のおもな興味は「ポリシーのくみあわせ」というところにありましたが，それがこの製品において重要だとかんがえたため，研究とビジネスの目的をあわせて達成しようとしました． HP 社側は研究所がからまなかったので，私と仕事をしなければたぶん一生，論文の著者になることはなかったであろう HP 社のプログラマと連名でジャーナル論文まで書くことになりました．
仮想の "音の部屋" にもとづくコミュニケーション・メディア voiscape も私が会社に提案してはじめた研究開発ですが，このときには研究とビジネスとの両立をめざし，かつ私としてはビジネスのほうに力点をおいていました． 他の予算がとれなかったということもありますが，いわゆるインキュベーション的なやりかたをとりました． いまのところビジネスとしてはうまくいっているとはいえず，かなりの赤字をだしてはいますが，ゼロではない実績があります．
]]>大学 2 年になるまで，私にはソフトウェアというものにはほとんど縁がありませんでした． 一方で小学生のころからハードウェアには興味があり，ラジオやその他の電子工作をしていました． 中学・高校のころにはオーディオファンになって，いまもある 「無線と実験」，「ラジオ技術」 などの雑誌をみて，ステレオアンプをつくりました． そういう私にとって，秋葉原で Intel 8080 が売られるようになると，それをつかって マイクロコンピュータをつくるというのは，むしろ自然なことでした． このマイコン製作についてはブログのエントリーに書いています． ここにも書いているように，デジタル回路の実装をよく しらなかったために，おそろしく複雑な配線をすることになり，もうハードウェアは やめようとおもうにいたりました． そしてソフトウェアの世界にはいってきたわけです．
]]> 就職してまもなく，ベクトル型のスーパーコンピュータ S-810 のコンパイラの仕事にたずさわりました． コンパイラはハードウェアとソフトウェアとの境界のプログラムであり，またとくに あたらしく開発されたコンピュータのためのコンパイラなので， ハードウェアをつよく意識しました． 当時の汎用コンピュータのコンパイラ開発に おいてはハードウェアの特性をそれほど意識しなかったのではないかと おもうのですが (いまでは RISC のためのコンパイラ開発ではハードウェアをつよく意識するのは当然のことだとおもいますが)， スーパーコンピュータはハードウェアをうまくつかうかどうかで 性能がおおきくかわってくるため，ハードウェアの設計者からもしばしば話を きいていました．コンパイラ屋をやめてからはハードウェアを意識することもすくなくなりましたが， DOS/V パソコンの部品が秋葉原で売られるようになってからは，ふたたび 自分でパソコンをくみたてています． 自宅でつかう DOS/V パソコンは， 家族のものもふくめて，すべて私がくみたてたものです． 自宅でやるひとはたくさんいますが，私は会社でつかっているパソコンも たいてい，くみたてています． 会社ではなかなか道具がそろわないので， 机のなかにドライバーやラジオペンチをもっています． しかし，単なるくみたて以上のことは，ひさしくやっていません． 近年は FPGA がひろくつかわれるようになって，半田ごてなしでハードウェアを 開発することができるようになっているので，やってみたいとはおもっていますが， いまのところ，なかなか手がだせないでいます． もう，いい年になっているので，定年後のたのしみとしてとっておくということに なるかもしれません．
]]>軸づけ検索 においては，キーワードにくわえて 「検索の軸」 を指定することによって， 百科事典などの検索において，その軸にそって整理された検索結果をうけとることができます． ここではキーワードによる検索はデジタルなものですが，それを軸というアナログなものとくみあわせています． たとえば軸として時間をとれば，時間によってソートされた結果をえる (つまり年表をつくる) ことができます． また，軸として空間をとれば，地図上に結果を表示させることも可能になります．
voiscape (仮想の “音の部屋” にもとづくコミュニケーション・メディア) をつかえば，2 人以上のひとが立体音響技術 (3 次元オーディオ技術) にもとづく仮想の音空間をつかってたがいに話をすることができますが， 立体音響をつかうことによって声の方向感と距離感を表現して，より自然な 会話ができるようにすることをめざしています． 従来の電話のようなメディアにおいては 相手と接続されているか，接続されていないか という 2 状態しかない (デジタルだった) ものが，とおくにいるかちかくにいるか，どの方向にいるか，というようにアナログな状態が実現されます． (この点については 「“プレゼンス” におけるデジタルとアナログ」 というブログ・エントリーでもうすこし説明しています.)
このように私はデジタル時代のなかでもアナログへのこだわりをもってきましたが，ブログのエントリー 「FM/AM チューナーのスタイル ― アナログ・チューニング」 に書いたようなオーディオにおける経験がここに反映されているようにおもいます．
]]>N クイーン問題 (下記を参照) は他のおおくの制約充足問題 (これについても下記を参照) と同様に，とくのに時間がかかります． そのため，それを高速にとくためのさまざまなくふうがかんがえられてきました． 金田の研究のなかでも，この問題をしばしば例題としてとりあげてきました．
]]> 最初は論理 / 記号 ベクトル処理 においてでした． Prolog のような論理型言語をつかうと， バックトラック という技法をつかった全解探索 (しらみつぶしの探索) をかんたんにプログラムすることができます． このようなプログラムをいかにして スーパーコンピュータのための高速なプログラムに変換するかが，この研究の課題でした． しかし，いくら高速化しても定数倍されるだけであり，指数的な計算時間がかかることにかわりはありません．つぎにこの問題をとりあげたのは CCM (化学的計算のモデル)においてでした． CCM においては計算に最初からランダムさが導入されていて，従来の計算法におけるようにつねに完全に解をもとめることはめざしていません． このような確率的な計算をするばあいには指数的な計算時間は必要ありません． CCM をつかえばパソコンでも，スーパーコンピュータをつかったバックトラック解法より高速に解をもとめることができます． N クイーン問題とならべかえ (ソート) のページには Java をつかった CCM による N クイーン問題のプログラムがあり，この計算をためすことができます． このページではパラメタをかえていろいろなときかたをためすことができますが，それについてはべつの機会に書くことにします (上記のページにはだいたいのことが書いてあります)． 確率的な解法としてはほかにニューラルネットや遺伝的アルゴリズムをつかった方法などもありますが，CCM による解法もそれらと似た性質をもっています．
金田の研究からははずれますが， N クイーン問題は N. ヴィルト の 「アルゴリズムとデータ構造」 という本でも プログラミングの例題としてとりあげられていますし，のちに Prolog などにつながっていった R. W. Floyd の "Nondeterministic Algorithms" という論文 (Journal of the ACM, Vol. 14, No. 4 (1967), pp. 636-644) でもとりあげられています． 後者については金田が 「情報処理」 の 2003 年 2 月号 (Vol. 44, No. 2, p. 198) に 解説を書いています． この解説のなかにも書きましたが，量子計算の例題としてもつかわれています．
チェス盤に，たがいにとりあわないように 8 個のクイーンをおくおきかたをもとめるのがエイト・クイーン問題です． これを N × N の盤面に拡張したのが N クイーン問題です． N クイーン問題のようにある条件をみたす解をもとめる問題を 制約充足問題といいます． たとえば地図を 4 色でぬりわけるのも制約充足問題です． おおくの制約充足問題はしらみつぶしにしないと解をもとめることができない NP (Non-Polynomial) とよばれる，むずかしい問題のクラスに属しています． N クイーン問題もそういう問題のひとつです． Non-polynomial とよばれるのは，N に関する多項式であらわされる時間ではとけない (指数的な時間がかかる) からです．
[関連するページ: The N Queens Page]
]]>