LLMの生成先としてのMFGの課題と可能性（その2）

前回： LLMの生成先としてのMFGの課題と可能性（その1） - なーんだ、ただの水たまりじゃないか

「ほら、こんなの出来た、凄いでしょ？」と言うところまでは行っても、そのあとをこれまでと同じやり方ではうまく受け入れる事が出来ず、デモだけで終わってしまう。

けれどそれは勿体無いので、受け入れ側を変えてどうにか出来ないか？という話をしたいのだけれど、現時点では「こうすれば良い」というのはまだ分かっていません。

今回は受け入れ側について思おう事を色々書いていきたい。

デモとプロダクトのギャップ

「デモでとりあえず動くものが二日くらいで出来るが、実際のプロダクトにすると3ヶ月くらい掛かる」という分野は、割と昔からある。 LLMのコード生成には似た問題があるように思うので、このデモと実際のギャップについて少し過去の事なども踏まえて書いてみたい。

かつて携帯電話のブラウザを移植する仕事をしていた時、とりあえずビルドを通して動かすのはそんなに時間がかからないのだが、そこからちゃんと製品にしようとすると結構なコストが掛かる、というのは、良くある事だった。大体移植は一人で2〜3日でとりあえず動く。でも製品にするにはチームで3ヶ月とか掛かる。

デモでそれっぽいのが動くのと実際のプロダクトのギャップを理解するのはプロフェッショナルとして大事な事だ。それが分かっていないのは素人である。

デモのように作れないのか？

ただ一方で、デモでそれっぽく動くのに、なんでプロダクトにはそんなに時間が掛かるのか？という感覚も、プロフェッショナルとしては持ち続けるべきものだ。それっぽく動く所には本質的な何かがあり、究極的にはそれだけでうまく行くのがあるべき姿にも思う。そもそも本来はデモのようにすぐに出来てもいいはずじゃないか？と言う感性もやはり必要なものだ。

その直感は皆が持つもののようで、だからこそGUIのプログラムの技術というのは、昔からこのギャップを無くそうと取り組んできた部分がある。 RADツールとかVBのポトペタみたいなのはまさにそういう話で、「ボタンを置いてハンドラを書いてほら出来た！」という風にやれないか、というのは長い長い歴史がある。 Avalon厨の過去を持つ自分としてはこの問題には人生のかなりの時間を捧げてきた。 ACCESSもVBもかなりの程度成功したプロダクトだし、そのクラサバはwebの時代が来るまで一時かなり広い範囲に普及してきたものでもある。

また、webでもかつてのJ2EEやstrutsやASP.NETからRailsになった時にそうした話があって、デモのように本番も作れないか？と言うのはかなりの程度実現された部分もある。デモとは違うけれど、かつてデモだからと言われていた部分のかなりの部分はプロダクト開発の初期にそのまま使えるようになり、最後までそのままである部分もそれなりにあるようになった。

モバイルになってこのギャップは再び大きく開く事になったので、時代とともにいつも狭まってきた、とは言えないけれど、このギャップを狭めるのは方向性としては正しい方向性だし、努力するに値するものでもある。

「デモと実際のプロダクトの間にはギャップはあるけれどデモはすぐに出来る」なら、プロダクトもすぐに出来る可能性はある。そういったギャップは、大きなイノベーションのヒントでもある。

デモとプロダクトのギャップは分野によって違う

デモとプロダクトのギャップがある時に、望ましい姿はデモのように作れる方、つまり理想的には直したいのはプロダクトの作り方の方ではある。だが、これはいつも可能では無い。もっと言うと、多くの分野では可能では無かった。大体のこの手の試みは失敗してきた。

だがたまにうまく行った分野もあり、それが出来た分野はその後に栄えて、可能でなかった分野に取ってかわる、と言う事は割と起こった。これはイノベーションのジレンマと同じような話だ。ただ出来なかった部分がいつも取って代わられるか、というとそうでも無い。うまく出来た分野は大体流行るのは間違いないけれど、うまく行かなかった部分も別にそのまま存続し続けるがパッとしない、と言うのは良くある事だ。

だから「こうしたギャップはすぐに無くなるか、無くせなかったら滅ぶ」と考えるのは間違いに思う。多くの冴えない分野ではこうしたギャップは残るし、冴えない分野は多い。

ギャップが大きいせいでデモがうまく受けいられない時に、それはそのプログラマが無能だとか新しい事に拒否反応を示しているとか時代についていけないロートルだとかいう事では無く、そういうのが向いてない分野、と言う事の方が普通だ。 LLMの凄さを全然分かってないのではなく、単にそういうのに向いてない仕事をしているのかもしれない。

一方でギャップが少ない分野、または「少なくなった」分野もある。だから「デモとプロダクトのギャップの大きさが小さいかのように言っている人はみんながみんな分かってない素人で現実はそんな甘くない」とも限らない。分野によってはそのギャップを少なくすることに成功しているのかもしれず、特にそれが新しい分野である時は、次の時代の中心的な何かになるかもしれない。

以上を踏まえると、例えば偉い社長が従業員にこのギャップをなくせ、と言ったら、大体は失敗する、と言う事は理解しておく必要がある。次の時代はLLMなのでこれを活かせない会社は生き残れない！と思ったとしても、デモとプロダクトのギャップが多い所で働いている社員には、LLMをうまく活かすのは難しいかもしれない。それは頑張って埋められる問題ではなくて、むしろその分野が衰退する兆候と捉えるべき類の話だ。もし社員が皆そういう仕事をやっているのなら、会社が危険な分野にいるのであって、社員の働き方を変えてどうこうなる問題では無い。

一方で1プログラマとして、このギャップが広くて問題になる事が増えてきているなら、それはその分野が何かにとって変わられる予兆かもしれない、と思って先の事を考える必要はあるかもしれない。そして自分がそのギャップをなくせると思うなら、何か大きな事をなすチャンスなのかもしれない。

機械学習は人間が挟まらない方がうまく行く事が多い

LLM以前から、機械学習のソフトウェアというのは、人間を補佐するのがなかなか上手く行かない事は多かった。思い通りに動かすのもなかなかうまく行かない。それよりも全部任せる方がいい。

絵の一部を手伝ってもらうよりも絵を生成する方が得意だし、動画を作るのを手伝ってもらうよりも動画を生成する方が得意だ。そして生成するものを思い通りにするのは苦手で、コントロールを強めれば強めるほどメリットが減っていく。

受け入れのレビューもこれに似ている話に思う。

人間がレビューをすると、作るのと近いコストになってしまう。これは人間が挟まっているせいでうまくいってない、という話に感じる。

だが、制御下に置きたいと思うのは、十分な理由があってそう思うのであって、単に無くせば良いという問題ではない。少なくともそのままでは大体は無くすだけでは上手く行かない。

ただ、制御下に置く試みは大体上手く行かなかった。だからきっと、レビューをするという方向もきっと上手く行かない。

今のやり方でレビューを無くしたら多分ダメだ。だけどレビューをしたら上手く行かない。多分やり方自体がダメなんだと思う。

LLMに指示したらフィルタが出来ました、からどうするべきか？

LLMにこんな指示をしたらこんなフィルタが出来ました、となった時に、ではその後どうしたらいいか？という事を考えてみたい。どうにかしたい。でもしたらいいんだろう？

現状の公式ストアに、誰も見ずにそのまま登録するのは難しい

現状MFGのフィルタは、PGN社が管理しているMFGのストアからダウンロードする事が出来ます。これはFireAlpaca SE 3.0のフィルタメニューから行うものです。

現時点ではここに登録されているフィルタは、私が書いたフィルタで、私が理解していて、テストもされていて、一番重要な事として、バグがあった時には私が責任を持って直します。

LLMがフィルタを生成しました、となった時に、これをそのままストアに登録して行っていいのか？と言うのは、良く無い気がしています。ユーザーが最初にアプリから普通にその延長としてストアを見て、何かを試す時に、このストアに並んでいるものはある程度「ちゃんとしたもの」である事を期待すると思います。この期待は作る側からすると、かなり高いものになる。 LLMの生成したフィルタをそのまま大量に登録していくと、平均的には現時点ではこの期待は満たせないと思います。

また、ユーザーとして、PGN社が公式にやっているストアには、PGN社が何かわかっていないものが大量に登録されているなんて事は無いはずだ、と当然期待しているだろうし、その期待は正しいとも思います。

端的に言って、ユーザーが期待するものとLLMの生成したものは少し違っています。

現状の公式ストアに、私がレビューして加えていくのは（少なくともたくさんは）難しい

ここまでの話の通り、生成まで行っていて動いているものも、レビューをすると結構なコストがかかってしまいます。作って動くところまでは中を理解してない人も頑張れば出来ることが元のブログ記事で実証されていますが、これをレビューしてちゃんと内容を理解するのはかなりの専門性が必要になってしまう。

せっかくいろんな人がどんどん作れるのに、レビューがボトルネックになって大して増えないのは、やる前からわかっています。これはいかにもうまくいかない。

多分現状のストアに、これまでのフィルタと同じように追加していく、というのはダメな気がします。

品質が分かっていれば、玉石混交でたくさんの中から選ぶのは正しい

この手の話はパッケージマネージャやGoogle Playなどのアプリのストア、電子書籍などいろんな所でも似たような話が過去にもたくさんありました。そして大体は、品質が低いものが混ざっているがたくさんあるものの方が、最終的にはユーザーに望まれていると思います。

大切なのは、ユーザーが期待しているものがそういうものであるというところに、そういうものを置く事だと思う。そして現状のMFGのストアは、ユーザーがLLMのフィルタを置く場所として期待するようにはデザインされていません。ユーザーが当然そういうものを期待するような何かを提供出来れば、「ほら、LLMが生成した、凄いでしょ？」の先に行けると思うのですが…

どういう形の何があればそういう期待を抱いて使ってもらえる何かになるのか、良く分からない。

例えば現状のストアにLLMで生成したものを見えるようにするopt-inの仕組みがあってユーザーのフィードバックでどのくらいのユーザーが満足しているかとかが分かれば選べるのか？とか考えはするけれど、そうした事を一つ試すのもコストがかかり、現状そうした事を色々試すほどの余力は無い、という状況です（というか小さい会社はみんなそうでしょう）。

この辺はユーザーの期待という話なので、色々なユーザーの話を聞く、とかがいいのかもしれない。

ユーザーが自分で作るのは現時点でも有力

現状はユーザーが期待するものとLLMが生成したものを一致させるのが難しい、というのが一番の問題なので、ユーザーが自分の欲しいものを自分で作って使う分には何も問題はありません。というのは、生成させる過程で大体どういうものかという期待値は固まっていくし、欲しいものを作ろうとした試行錯誤の果てにたどり着くものなので、それがどういう事を期待して作られたものかはユーザーは分かっているので、他人に説明する難しさをバイパス出来ます。

だから現時点でも、ユーザーが自分が欲しいフィルタをMFGStudioで作ってFireALpaca SE 3.0で使う、というのは、何の問題も無くできるし、凄く可能性のある事でもあると思います。やってくれたらMFGの作者としてはこんなに嬉しい事は無いです。

ただ、どうせ作るなら、出来たら作ったものを他の人にも使ってもらえるようなエコシステムがあった方がいいですよねぇ。

あと現状はMFGStudioで作ってFireAlpaca SE 3.0で使う、という役割分担になっているので、 FireAlpaca SE 3.0で絵を描きながら新しいフィルタを作っていく、というのは想定していません。ですが、LLMでエンドユーザーが作るという前提だとそのシナリオの優先度が上がりそうです。ユーザーがどんどんフィルタを作っていくようになったらそういう対応は必要とは思っています。

人間がMFGのフィルタを書くのはまだまだ意義があると思う

LLMがフィルタを生成出来た、となると、「もう人間が書く時代じゃない！」と言いたくなる人もいると思う。そしてMFGを作っている側の自分としては当然そんな事は無いとしか答えなさそうな話ではある。

ただ、それなりに客観的にも人がMFGのスクリプトを書く方が、ずっと使いやすいという現実はあると思う。

受け入れの容易さが段違い

人間の作ったものの方が、その後の活用がはるかに容易です。それはここまで話してきた全ての問題が、人間が作った場合には無いからです。そして「旧来のやり方」で全て対応出来る。

現時点ではストアには私が書いた以外のフィルタはありませんが、これに第三者が作ったフィルタを、適切にレビューしつつ加えていくのは容易に想像出来るし、実現も出来ると思います。数が少ないうちは個別に交渉して、数が増えてきたら何か仕組みを作って…と、自然にスケールもさせていけるし、そこに必要なコストも割と明確です。このノウハウは広く知られている過去に散々行われてきたものであるし、社内でもブラシストアという前例があるので、これには不確実な事があまり無い。

一方、LLMで生成したフィルタは現状受け入れが全くできていない状況です。そして新しい仕組みを生み出さずに今のまま受け入れるなら、結局書いた人のコストがレビューする人に転嫁されるだけで、たいして変わっていない。逆に言えば、例え人間が書いたフィルタと全く同じフィルタをLLMで生成したとしても、結局後者を受け入れるのに書くのと同じコストがかかってしまうので前者は全く無駄になっていない。

これは、現状のシステムに問題がある、という話です。本質的に不可能である、という話ではありません。ですが、現在は現状のシステムしか無いので、その上では人間が書く（どこかにそれを理解した人間がいてコンタクトが取れる）方が遥かに価値があります。

一見すると人間と同じものをLLMが生成したのでもうプログラマは不要だ！と感じるかもしれませんが、現状は全くそんな事はなく、それどころかLLMの生成したものは捨てるしか無く、全く価値を生み出せていない状況になっています。

見た目の「もう作る意味ないのでは？」という印象と現実のほとんど生成したものを生かす事は出来ていないという現実のギャップは、デモとプロダクトのギャップと同じ話です。

どうなったら人間が書く意義が無いと言えるか？を考えてみる

逆説的に、ではどうなっていたら人間がフィルタを書くのが不毛な作業になるか？と考えてみると、それが非常に実現が難しい世界である事が分かると思います。そこでそれをここで考えてみます。

まず、ユーザーがLLMでどんどんフィルタを作っていって、自分が手でコードを書くのと同じものをすぐに誰か別の人が作って、それが広く配られるような状況になると、初心者がフィルタを書く意義はだいぶ少ない状態になると思います。

現実としては、実際にLLMでわざわざフィルタを作る、という事をやってくれるユーザーは、現時点では凄く少ないでしょう。そして作ったものも、「ほら凄いでしょ」と単発で言うくらいが精々で、継続的にいろんなフィルタを作ってもらう、という所までは道は遠い。

みんながLLMでバンバンフィルタを作って共有しまくる、という世界。これはMFGがめっちゃみんなに使われているという事です。大成功です。私は第二のMatzを名乗って、「成功するには独自のプログラム言語を作るのです！」とか講演とかしている状況です。 FireAlpaca SE 3.0もめっちゃ使われて、多分シェアもNo.1 のペイントソフトになっています。

これらはやってくる未来かもしれない。けれど、もうほぼ確実にそうなる、と思えるような状況とは程遠いです。どちらかといえば、客観的には多分そうはならない、という方が高い確率と思います。ベンチャーの挑戦というのは大体そういうものです。

これはデモとプロダクトのギャップと似た話でもある。人間が書くのは意味が無い状態まで辿りつくのは、開発サイドからすると相当大変な道のりです。いますぐ達成された前提で行動しなくちゃいけない、というのは、いかにもこのギャップの大きさが分かっていないという感じがします。

LLMのMFGプログラマとしての実力

以上の本題とは関係ない話ですが、単純な興味本位として、どのくらいの能力があると感じているか、という話を軽く書いてみます。この辺はLLMの進歩ですぐ変わる可能性があるし、また学習対象をもっと整備すれば変わる話かもしれません。現時点でのスナップショットの評価、という感じで。

LLMは、現時点の印象では、複数のテンソル（GPU的にはカーネル）に分けることは出来ていない。多分このあたりをちゃんと有効利用して問題を解くのは難しそうに思える。実際人間でも中間テンソルをちゃんと使うのは中級者くらいの慣れが必要な話で、その壁くらいの所にいるのかな、と思っている。

一方で単一のカーネルで解ける問題で、式が複雑になるものには結構強い。これはおそらく中級プログラマくらいの実力がある。

そして数学とか論文を理解する能力はかなり高い。つまりフィルタを作る前準備の所の能力は随分と高いなぁ、という印象です。

複数のカーネルに自分で考えて分けるところまで行くと、一気に作れるものが広がるので、そこまで行ったら本当に新しい世界が広がっているとは思うけれど、まだそこまでは行ってないな、という印象。一方で、いかにも簡単な事だけをやっているという訳でも無く、現時点でもかなり実用的な実力は持っていると思います。

中級プログラマには劣るけれど、初心者よりはすでに上に居るな、という印象です。

結論：デモで終わらせてしまうには惜しいがどうしたらいいかは良くわかってない

という事でこれが現時点での結論、という事になる。

生成させるものは結構すごいものが出来そうで、これは有効活用出来たら凄いんじゃないか？という気はする。そして実際に動かして思うけれど、エンドユーザーが使うくらいなら現時点でも使える。

一方で、生成したものを皆に広く使ってもらう方法が無い。.marを生成してリンクを貼る事は出来るのだけれど、それで十分みんなが作って広めてくれるとも思えない。このポテンシャルに対して、大きく不足を感じる。

そして、そうしたものが特に無い現状で「こんなのLLMで作りました！でも中は何も分かってません！」と社内で言われた後に、出来ることが無い。できる事が無いのだけれど、このまま何もしないで一時のちょっとした試みくらいで終わってしまって捨てられてしまうのもあまりにも勿体無い。何とかならないだろうか？

次回: LLMに向いた環境を作る大切さとMFGのフィルタという切り口の評価

次回はちょっと視点を変えて、LLMに何かをさせる、という「環境を作る」という問題があって、 MFGはかなり壮大なそうした試みの一つに（結果として）なっているようにも思うので、そうした視点からのMFGの評価と、それを通してLLMに作業をさせるために小手先ではなくプログラマが本気でプログラマとしての能力を発揮すべき分野の一例を見てみたい。

余談：絵を生成するのは気に食わないがコードを生成するのはどう感じるか？

ちょっと話は変わりますが。

お絵描きアプリなんてものをこのご時世に作っている事からも分かるように、自分はネットで人が絵を描いて公開する、というような文化が好きです。そして「生成モデルで絵がこんな簡単に生成出来ます」みたいな話はうんざりしている側の人間です。それが嫌でSNSをあまり見なくなってしまった、という部分があります。絵を生成するという話自体があまり好きではなく、人間より上手いかどうか、AIの生成した絵が分かるかどうか、そういった話自体にうんざりしています。

そんな自分ではありますが、絵では無くコードならどうだろう？というと、おそらく自分は絵よりはコードの方が、生成してもらって構わないと思っていそうです。プログラムの能力を頑張って積み重ねてきたのは、絵を描く人たちが頑張って積み重ねてきて身につけたものと、それほど違いは無いような気はする。けれどプログラマとしての自分は、この能力が最初から賞味期限付きのものであって、時代と共に価値を失うものと最初から思っている気がする。最初からそう思っているので、その陳腐化が新しい環境やトレンドによるものかLLMによるものかは大して重要では無く、別段大きな違いは感じていないようです。 iPhoneが登場してからガラケーの仕事が消えるまでの期間の短さからすると、LLMがコードの価値を消す速度はむしろ思ったほど大した事ないという印象でもあります。

この辺はおそらく、プログラムと絵ではだいぶ印象が違いそうなので、分野によってだいぶ当人の感じる印象は違うのだろうなぁ、と思う。同じ分野でも人によっても違うかもしれないけれど。

ただ、コードをLLMが生成して自分がレビューする、という役割分担には絶対になりたくないとは思っていて、なってほしくない未来というのはあるな、とも感じています。