週刊Life is beautiful ２０２３年２月７日号： GPT3は電気羊の夢を見るか？

今週のざっくばらん GPT3は電気羊の夢を見るか？ GPT3について、Twitterで連投したので紹介します。 話題のchatGPT3ですが、そのベースになっているGPT3について連投で解説します。元々は「途中で切れている文章の次の単語を予測する」だけの人工知能を作り、それにインターネット上にある大量の文章で教育してみる、という実験から始まったものです。 するとそこそこに「もっともらしい文章」を作るようになったので、さらに教育データを増やし、ニューラルネットのパラメータを数を増やしたところ、「まるで知能を持つかのように振る舞い始めた」のです。 与えているデータには人類の英智が含まれていますが、作られたニューラルネットワークがそれを「理解」して答えているわけではありません。単に「人類の英智をベースにしたもっともらしい文章」を作ることが得意になっただけです。 ある意味、GPT3は「誰かのフリをして喋る」のが得意な「ものまねの名人」なのです。評論家、科学者、解説者はもちろん、プログラマーのまねをしてプログラムを書くことまで得意になってしまいました。 なので、「もっともらしい回答」をする時もあれば、「出鱈目な回答」をする時もあります。なので注意が必要ですが、使い方さえ工夫すればとても便利なツールです。文章を要約する、長い文章から要点を抜き出して箇条書きにするなどはとても得意です。 逆に、要点だけを言って、それを最もらしい丁寧な文章に膨らますのも得意です。星新一の作品に「肩の上の秘書」というものがありますが、それが現実のものになったのです。 「別の人が好きになったので別れたい。さっさと荷物をまとめて出て行け」という文章をGPT3に書き直してもらうと、 「いつも一緒にいられて本当に幸せな時間を過ごさせていただきました。しかし、今回は別の人が好きになったという理由で、お互いの幸せを第一に考え、別れることにしました。荷物をまとめるのに手間取ると思いますが、私もお手伝いしますので、ゆっくりとした気持ちで荷物をまとめてください。」となります。ものまねが得意なだけの人工知能が素晴らしい仕事をしてくれます。 「うちの商品が壊れたのはお前の使い方が悪いから。払い戻しは絶対にしないよ。もう電話して来るな」という言葉を書き直させると 「お客様がご購入いただいた商品が壊れてしまい、ご不便をおかけして申し訳ございません。お客様のご使用方法が原因である可能性をご理解いただけると幸いですが、お客様にお支払いいただいたお金を払い戻すことはできません。ご理解いただきますようお願いいたします。今後、当社への電話でのお問い合わせをお控えいただきますよう、何卒お願い申し上げます。」となります。 GPT3は、これらの文章を「元恋人」や「顧客対応スタッフ」のモノマネをして書いているだけです。ネット上にはこの手の文章が溢れているので、それを参考にしながら「もっともらしい」文章を作るのが得意なのです。 一方で「ねずみ講とは何かを、小学生にも分かるように解説してください」と質問すると 「ねずみ講とは、ねずみが嫌いな子どもたちに、ねずみについて学ぶことを楽しむプログラムです。ねずみは、害虫ですが、害虫ではないことを学びます。」という出鱈目な答えが返って来ることもあります。 文章そのものに「もっともらしさ」はありますが、内容は出鱈目です。GPT3がより進化すればこんな問題も減るだろうとは思いますが、少なくとも今の時点では、作られた文章が使い物になるかどうかの判断は人間に委ねられています。 つまり、GPT3は「ネット上にある人類の叡智」をベースに、もっともらしい回答をするだけの「ものまねマシン」なのです。しかし、よく考えてみると、僕ら人間も実は「もっとらしい言葉」を喋るだけの「ものまね人間」なのかも知れません。 私はこの文章を、これまで得た知識をベースに生成していますが、このプロセスとGPT3がやっていることに、本質的な違いがあるのでしょうか？ 以上が、Twitterでつぶやいた内容です。一気に閲覧数が増え、この原稿を書いている時点で１００万ビューを超えています。 単に「次の単語」を予想するだけのGPTが、あたかも知能を持つかのように振る舞い始めたことは、「人工知能の研究」という観点から興味深いのはもちろん、「知能とは何か」という生物学的・哲学的観点からも非常に興味深い話です。 実際、こうやって文章を書くプロセスも、私の頭の中に浮かんでくる言葉をキーボードを通して文字にしているだけの話で、その作業の大部分は、かなり自動化された「もっともらしい言葉を繋いでいく」作業です。唯一の違いは、「何を伝えようか」という主題の部分を私がコントロールしている点ぐらいです。 多作で有名なスティーブン・キングは、小説を書く際には、最初に登場人物の性格や場の設定だけを丁寧に行い、その後は、「登場人物が自ら発する言葉を文字にして作品を作る」と言いますが、まさにそれは、それぞれの登場人物が場面場面で「言いそうなこと」を予想していく作業であり、GPT3がやっていることと同じと言えます。 SwiftUIとMVVM 私が mmhmm Inc. に投資家兼ソフトウェア・エンジニアとして参加したことは、このメルマガに書きましたが、その過程で、１年ほど前に感じた違和感に対する疑問が今になってようやく解決したので、報告したいと思います。 私が mmhmm に参加してから最初にした仕事は、macOS版の mmhmm アプリにジェスチャー機能を追加することでしたが、その後は、CEOの Phil 向けにさまざまなプロトタイプを作るという仕事をしていました。その後、プロトタイプの一つであった iOS 版の mmhmm を正式なプロジェクトとして立ち上がることが決まり、当初の意に反して（最初はパートタイムで働くつもりでした）開発責任者になってしまいました（つまり、フルタイムで働くということです）。 当初は、macOS版のコードをそのまま移植しようと考えたのですが、かなりのコードがSwiftではなくObjective-Cで書かれた上に、UIはSwiftUI以前のmacOSに依存したコードであり、そのまま移植するのは厳しいと結論付けました。 そこで、Objective-C で書かれた映像処理と通信の部分はそのまま採用し、他はすべてゼロから実装し直すことにし、全てのUIをSwiftUIで実装することにしました。SwiftUIは、Appleが２０１９年に iOS13 に追加した、「宣言形のUIの記述」を可能にするフレームワークです。その一つ下のレイヤーには Combine というデータフローのフレームワークがあり、それにより、React.js や Vue に通じる「リアクティブ・プログラミング」を可能にする画期的なフレームワークです。 その頃は、私もSwiftUIに触れたばかりでしたが、良い機会なので、Combine + SwiftUI を思いっきり使いこなす設計で、iOS mmhmm 版を開発することにしました。当初は戸惑うことも多かったのですが、Combineの使い方に慣れて来た時点でとても生産性があがり、半年ほどで、最初のバージョンを出荷することが出来ました。 しかし、そのままフルタイムで働き続けたくはなかったので、Philに相談し、別の人を雇ってもらうことにしました。結局、３人ほどiOSアプリの開発の経験者が採用されたのですが、仕事の引き継ぎの際に、リーダー役のエンジニアが、「まずは今のコードベースをMVVMに移行する必要があるのでそれを手伝って欲しい」と言います。私が「このアプリは Combine + SwiftUI で作られているから、MVVMのようなパターンは不要だ」と返事をすると、とても不愉快そうに「だったら僕らがやるから手伝いはいらない」と怒ってしまいました。 私の理解では、MVVM（Model-View-ViewModel）は、WindowsやSwiftUI導入前のiOSのような記述形でUIを操作するプログラミンが複雑化することを避けるためのデザイン・パターンであり、Combineをフルに活用したSwiftUIでアプリには不要なはずです。 その時は、早く開発から手を引きたいこともあり、あっさりと引き下がりました。Appleからリリースされたばかりの、Combine + SwiftUI という新たなアプローチよりも、自分達が親しんできた MVVM パターンで開発をしたいのだろうな、ぐらいに考えていました。しかし、同時に、なんだかせっかく私が綺麗に作ったアーキテクチャを汚くされてしまうような嫌な予感がしたことを良く覚えています。 もう半年以上も前の話なので、ほとんど忘れかけていましたが、たまたま Twitter で見かけた呟きに、「「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由」という記事が紹介されていたので、「やはりそうだよな！」と強く頷いてしまいました。 ちなみに、私が抜けた後の iOS 版 mmhmm の開発ですが、私が去年の４月にリリースした version 1.2.2 からいまだにアップデートされていないことを見ると、順調とは言えないようです。その遅れの原因が「MVVMへの移行」を強引に押し進めたためかどうかは私には分かりませんが、よくありそうな話です。