久しぶりに夢を見た。
夢の中では、一冊の本があり、たまたま開いたページではプログラミング言語の一種であるSmalltalkとAIが奇妙なブロック図で繋がれていた。

そういえば、奇しくもSmalltalkという言語はその名の通り「Talk」つまりコンピュータに話しかけるように書く言語で、Apple Scriptにも大きな影響を与えている。

このApple Scriptが地獄のようにわかりにくいのだが、それはプログラミング言語でありながらプログラミング言語ではなく自然言語に表現を似せていった結果、通常のプログラミング言語の常識がほとんど使えない言語になってしまったからだ。Apple Scriptはプログラミング言語としては驚くほど人気がない。それが持つ機能は極めて強力であるにも関わらず、だ。

数週間前、AppleScriptでのプログラミングをする必要に迫られて(人工知能の研究者は常に信じられないような"必要性"に迫られることがある)、久しぶりにAppleScriptを書こうとして非常に苦労した。まさにこれは、コンピュータに語りかけなければならないが、Siriに音声でプログラミングをするくらい難易度が高いのだ。

夢の中で見たのは、Smalltalkが外部モジュールとしてAI機能を持ち、SmalltalkからAIに「語りかける」ことによってAIを使おうというダイアグラムだった。

もちろんこれは記憶の一時的な混乱がもたらした、奇妙な図であったのかもしれない。
僕はときおり、こういう夢を見ることがある。たいてい、その夢のなかでは、本棚の前に居て、「こんな本を待っていた」と胸をときめかせ、レジで会計を済ませてからワクワクして自宅に帰り、本を開こうとしたところで目が覚めてガッカリするのだ。結局、そのとき読み語った本を自分で書くことになることが何度かあった。

その中では、最初に図、つまり本の内容が記憶に残っているのは珍しい。これを単なる戯言と捉えることは簡単だが、悪くない視点ではないかと起きて2秒くらいで思い、ベッドから飛び出してこの原稿を書いている。

人工知能の世界では、日々いろいろなことが起きている。あまりにも色々なことが起きているので、論文が多すぎて追いかけられない。
そこで論文の中から図だけを抜き出して一覧するサービスを自分で作った。手前味噌だが、これが非常に効率的で重宝している。

その結果、僕はそれまでよりも3倍以上の論文を一瞥することができるようになり、論文の中から抜き出された図を眺めることはモーニングルーティーンになった。

一瞥できるようになると、逆に論文が足りなくて物足りない、と感じるようになることもしばしばで、当初はコーネル大学の論文アーカイブの人工知能分野の論文だけを抜き出して読んでいたが、今は論文アーカイブの全体の中からDeep Learningに関するものすべてを抜き出して読むことにした。そうすると、意外にも分子生物学の分野でDeep Learingが盛んに使われていることがわかるようになった。

こうして毎日のように論文の図を見る習慣ができたせいか、頭の中で図のようなものが常にぐるぐると強迫観念のように回っているのだろう。

ところで、人工知能とプログラミング言語というテーマでものごとを考えようとすると、まず言及すべき言語はSmalltalkではなくPrologとLISPである。
なぜなら、どちらも人工知能研究の一貫で開発された言語だからだ。

さらに言うならば、今現在、いわゆるDeep Learningと呼ばれる世界ではこの２つの言語は全く出番がない。
世の中に無数に発生した「人工知能エンジニア」のような人々の中で、PrologやLISPを実用レベルで使える人はほとんどいないだろう。こうした言語を使いこなせる人は、それ以前の世界の人に限られる。

いま、Deep Learningをする人たちが専ら使っているのはPythonという言語で、この上に人工ニューラルネットワーク(人工神経網)を構築するためのモジュールをインポートして使うのが普通だ。TensorFlowやPyTorchなどだ。

ところが面白いことに、TensorFlowにしろPyTorchにしろ、ニューラルネットワークを構築するためのモジュールが実現するニューラルネットワークの構造は、PrologやLISPで書くプログラムの構造と極端な類似性があるのである。

人工神経網を記述するということは、各人工神経層の関係性を記述することであり、Prologが記述するのは知識の関係性であり、LISPが記述するのはリスト構造のデータの関係性なので、どの言語パラダイムも、「事物の関係性」を定義するという点において類似しているのは当然といえば当然だ。

最近の論文でようやく実用的な応用法が見えてきたグラフ畳み込みニューラルネットワーク(GCNと呼ばれる)は、Prolog的な知識の関係性(関係グラフ)をニューラルネットワークで解釈するというもので、Prologがかなり厳密な関係性を記述しなければならなかったことに比べると、ニューラルネットワークらしい曖昧さを許容するという点が新しくて面白い。

LISPがMITの人工知能研究所で題材にされていた理由は、記号を処理できれば汎用的な知識情報処理が可能になるという一種の仮説があったからだ。
それはほとんど正しかった。LISPはすべてのプログラミング言語の中でもっとも美しい構造を持っていると僕は思う。その構造が美しすぎるがゆえに、凡人が使いこなすことは極めて難しい。僕は使いこなせない。LISPハッカーは本当に最も尊敬に値するハッカーだと思う。

あるいは、美しさに拘らなければ使うことは辛うじてできるが、それがLISPを使っていることになるのかどうかは疑問だ。

LISPの構造というのは、極めてシンプルだ。カッコで囲まれたものが「リスト」であり、リストが入れ子構造になることによってプログラムの構造が決定する。

たとえば、1+2をLISPプログラムで書くと(+ 1 2)となる。リストの先頭が命令または関数(プログラムの処理の本体)であり、リストの二番目以降の要素がパラメータである。これ以上ないくらい簡単だ。そしてLISPの関数はリストを返すことができる。リストが返されるということは、リストの中にさらに関数を含めることもできる。今の言語では当たり前の機能だが、LISPが生まれた瞬間はこの構造は革命的過ぎた。

このような構造であるため、通常のプログラミング言語で培われる勘があまり通用しない。

たとえばどんなプログラミング言語にもある、ループ(繰り返し)の処理を、LISPの作法では再帰処理で呼び出す。これは直感に激しく反する上に、メモリを無駄遣いしないために余計な気配りまで必要になり、構造の美しさと引き換えに大事なものを失っている気がしてしまう。

とあるLISPハッカーに「ループが嫌にならないのか」と聞いたら、「マクロを使えばいい」とこともなげに答えた。マクロとは、LISPに備わっている、典型的なプログラムの類型を省略表記するもので、ループマクロを使うと、普通のプログラミング言語のように書けるのだそうだ。

LISPは非LISP系プログラマーの直感には反するが、そのシンプルな構造から、自動生成と相性がいいことがわかっている。

一時期、LISPで流行ったのは、遺伝的プログラミングというパラダイムで、プログラムを一種の生物と見做し、プログラムコードを遺伝子に見立ててプログラムを自動生成しつつ遺伝子であるプログラムコードを「交配」したり「突然変異」させたりして「進化」させることで効率的なプログラムを生み出せるのではないかという手法である。

結論として遺伝的プログラミングは一定の成果を上げはしたが、メモリや電力に成約のある環境では人間が頭を使ったほうが「なんとなく良さそう」ということで実用的に使われるフェーズでは普及しなかった。

人工ニューラルネットワークの世界では、ニューラルネットワークを遺伝的アルゴリズムによって学習させるNuroevolutionという手法が古くから研究されている。この手法の利点は、通常のニューラルネットワークに比べてパラメータ更新がシンプルにでき、ニューラルネットワークの規模を小さくできることにある。

一般にニューラルネットワークは規模が大きいほど性能が高くなり、学習させるのが難しくなるが、規模が大きくなりすぎると普通に入手可能なコンピュータで動作できなくなるという問題がある。特殊な部品やサーバーが必要なニューラルネットワークは、単純に活躍できる範囲が狭まってしまう。

目的にあわせて適切な規模のニューラルネットワークを得ることが実用段階では重要で、現在はアルゴリズムの単純な性能差を一概に計ることが難しくなってきている。今年6月にGoogle Brainの発表した論文によれば、今現在広く使われている画像認識アルゴリズムの評価用データセットImageNetは教師データ(ラペル)が雑なため、近年発表された「より効果的な」アルゴリズムとされているものはImageNetに対して過学習しているという指摘がなされている。

この論文の中では、より良い教師データを与えることでImageNetがまだベンチマークに耐えるという主張がされているが、この件で人類が学び取るべきことは、「画像認識の一般的な精度で競う時代は終わった」ということだろう。少なくとも実用レベルではImageNetにいくら適合していようが意味がない。

ニューラルネットワークの推論にかかる電力や設備について考えれば、ニューラルネットワークは目的に応じて十分なほど小規模で十分な精度があればそれが最も理想的で、規模と精度のトレードオフをいかに折り合いをつけるかということが最大の関心事であるべきだ。

結局のところ、データの精度がAIの性能を決定するということは最初からわかっていたわけで、そこを高めることにいかに注意を払うかということが大事なのである。

もうひとつ、誤解されているであろうことは、では精度の高いデータを作り出すにはどのくらいの労力がかかるかということだ。

以前、コロナ禍で仕事がなくなった某航空会社の客室乗務員にマスクと医療用ガウンを作らせようとして批判を浴びた例があったが、労働というのはだれがやっても同じということにならない。いくら接遇で世界一の会社といわれていても、それとマスクを作るスキルには大きな隔たりがある。しかも下手をすれば命に関わるものになるはずで、その発想が批判を受けるのはある意味で当然だと思う。同じマスクであっても、品質管理の基準が違えばとんでもないものが出来上がってしまうというのは、この半年で人類が学んだ重要な教訓だと思う。品質管理は一朝一夕には行かないのだ。それはAIが学習に使うデータに関しても全く同じことが言える。

あらゆる製造現場と同じように、データ創成という仕事も、創意工夫が最も重要なスキルであると思う。
早く、正確に、十分な精度を出すためのデータセット作成を実現するためには、独自のノウハウと創意工夫が必要になる。

これから人工知能を実用フェーズにもっていこうという時に必要なのは、人工知能そのもののプログラミングはもちろんだが、それ以上にデータの精度をどう高めるかという製造技術を高めていくことだ。この部分を疎かにしていると結局、どれだけアルゴリズムを磨いても精度が出せないことになる。

少し前にこの業界でよく聞いたのが、「精度を出すためにはデータ量を今の10倍以上に増やさなければならないと開発会社に言われたんですよ」という苦言だ。でもこれは、開発会社の職務放棄に近い。データ量を増やすのは開発会社の仕事ではないからだ。データの量ではなく質を高めれば、簡単に解決する問題であり、実際にそういう顧客が困っていたケースでは非常に簡単な手法で精度が出せる場合がほとんどだった。

かつてはアルゴリズム+データ構造がプログラムだと考えられていた。今でもその考えはほとんど正しいが、実際にはデータ構造はどんどん簡単に、汎用的になっている。プログラムの定義もだいぶ変わってきているだろう。今のWebエンジニアで、「データ構造」をどこまで熟知する必要があるかといえば、たぶんほとんどない。

「データ構造」が重要だったのは、整理すべきデータが十分小さく、コンピュータのメモリや処理能力に大きな制約があったからだ。

今や、ことAI開発においては、「データ構造」よりも、アルゴリズムがどう組み合わされているか、いわば「アルゴリズム構造」のほうが重要である。そしてまた、その組み合わせ自体も、自動生成されたアルゴリズム構造の探索によって必要最小限のサイズまで落とし込められている。反対にデータの品質は益々重要性を増し、データの質を上げる部分にこそ創意工夫を凝らす余地がある。

GAFAがAIでずば抜けて強い(強く見える)ことを嘆くよりも、GAFAが産業構造的に入手できないデータをどのように入手して対抗するかを考えるほうが遥かに建設的であり、創造的だと思う。

GAFAが使えるのは、基本的にはネット上に公開されているデータだけだ。
せいぜい、それプラス、路上と衛星軌道から見える範囲のデータくらいだ。メールに添付されているファイルの内容やSlackの会話の内容などは、実際には見ることができたとしても、「見てる」とは死んでも言えない顧客の秘密だ。ある意味で、ここに彼らのアキレス腱がある。それは彼らの巨大さ故の弱点である。

結局のところ、世の中には、門外不出のデータの方が遥かに多い。特にビジネスの現場はそうだ。

LISPのように、データ構造とアルゴリズムが密接に関係していたり、Prologのように、知識構造そのものが関係性として表現されるプログラミング言語は、人間が操るには難しい部分が多いが、AIが人間とコミュニケートするときにはむしろ積極的な助けになる可能性があると筆者は考えている。

たとえば、Wikipediaを読むAIというのは世の中にいくらでもあるが、いずれWikipediaで得られた知識をPrologの論理構造に翻訳するAIができると、記号論理型のAI(古典的AI)の研究が一気に進むだろう。Wikipediaは公開情報に過ぎないが、社内にある膨大な門外不出の情報をすべて読みこんだAIがあれば、便利な場面は少なくないだろう。