LLMはきっと、線引ができない

こんばんは。最近ぼんやりと考えていたことを文字に起こそうの回です。

私は技術ブログを読み漁るのが趣味で、ネットサーフィンするほどでも……という節があるので、よく見に行く個人ブログだったり、あとは割とZennを眺めていることが多いです。これはLLMによるslopが見るに堪えなくなったいまでも続けています。多分RSSを取るとか色々効率化できるところもあるのですが、探してタイトルを見て選んで、読むという繰り返しがきっと楽しいのだと思います。内容は時代によって流行り廃りがあって、最近だとLLMに丸投げする話と、逆に行くところまで行ったのか、LLMに丸投げするのをやめてちゃんと理解しようといった内容もチラホラと見かけるようになりました (とはいえ大方skillsをどうこう、という話に落ち着くので、結局のところはLLM方法論が人気という話かもしれません)。

中には、企業の看板で「うちの会社ではLLMに丸投げをしています」という内容を、例えばループエンジニアリングといったそれらしい方法論の名をつけて投稿しているケースもちらほらと見かけるので、文化が違うなあと思うところです。今回はそこに対するお気持ちを書きたいわけではなくて、むしろ「そういう時代に、いわゆる”ITエンジニア”価値ってなんだ？」という話です。残念ながら資本主義というものはお気持ちでは回っていないので、真にLLMへの丸投げが成立するのであればこの職はすでに存在していないはずです。逆に言えば人間が介在することによる価値があるだろ、という話でもあります。

この記事は現段階における先述の問いに対する、私からの逆説的な回答です。LLMには境界線を引くことはおろか認識できなくて、そこに人間の価値が残り続けるだろうという話を書きます。

LLMの書く設計資料は妙に実装に寄っている

LLMにソフトウェアの設計書を書かせると、妙に実装に寄った内容が出力されます。あるいは滲み出ている、と表現したほうが良いかもしれません。例えにしてはやや抽象的ですが、以下のような状況です。

あるマイルストーンで開発する内容をまとめるファイルに、具体的にどのファイルのどの行に変更をするのかを記載する
API定義のバリデーションで、「どうバリデーションするか」の実装をOpenAPIのyamlファイルに直接記載する

これらは、単体の成果物を見ると確かにそれらしいなと感じます。しかし、実際には求められる抽象度と、成果物の抽象度があっておらず、成果物のほうが具体的すぎる事が多いです。先に上げた例でいうと、前者は (もちろん内容自体の見た目によるところはありますが) 現状で解決するべきソフトウェアそのものの課題と、それに対してどうあるべきかというのを書きますが、それがどう解決するのかという方法にすり替わってしまいます。API定義も、何を提供するのかを書くべき場所に、それそのものをどう実現するのかという方法にすり替わっている例です。

念のために書いておくと、LLM側にコンテキストに成果物に求められる抽象度が乗っていない、つまりLLMを運用する問題であるという話ではないです。「こういう抽象度で、こういう例の内容を書いてね」を明示してなお起こります。

こういった挙動を完全に直すのは、LLMには原理的に不可能なのではないかなと思います。そもそもLLMってなんだ、というと、ざっくりとは確率的に尤もらしい文章を生成する機械です。どれだけ様々な創意工夫が凝らされて現代のLLMの性能が上がろうとも、LLMである間はこの事実は変わらないと思います。そして、ソフトウェア設計の言葉とソフトウェア開発は言葉は近しい位置にあるはずです。そう考えるとコードベースのコンテキストを持つLLMが設計の際に開発のテキストを出力するというは、ごく自然な挙動に見えます。

LLMは尤もらしい文章を生成する機械なので、近しい内容の間に線引きができない。あるいは、線引をするという概念が存在しない。それが今回の主張です。

LLMに丸投げすれば関係ない？

ここまでの内容を見返してみると、どこか「中間生成物をLLMに生成させるのは筋が悪い」というような主張のようにも見えて来ました。LLMにこういう機能を作って、と言ったら実装をしてくれる。抽象的な指示で作ってくれるのだから、境界線が引けなくても関係ないよねという言葉が聞こえてくる気がします。

個人開発ならそれで良いと思いますが、おしごとだとそうも行きません。結局のところ最終的なソフトウェアそのものの品質が提供するに足るかという線引きが必要で、やはりその境界線はLLMには引けません。なので人間が担わざるを得ないのですが、結局のところ、やっぱりそこに人間の価値が残るよねという話になっていくように思えます。一切の品質保証を諦めるという超ダイナミックな解決策を取るようなケースを除けば、どこでそのコストを持つんですかという話で、中間生成物があったほうが最終的なコストが下がるだろうという判断は自然に見えます。

ここまで書いてみて、結局のところ「LLMには意思決定ができない」という主張といって良さそうです。想定している”線引き”は例えば開発に取り掛かった結果コストが大きくなることが分かったので (できるけど) やらない、だったり、ビジネス的な要件であえてベストプラクティスから外れる選択をする、などの開発上のものも想定しています。LLMは最後まで走り抜けてやり切ったり、(当たり前にベストプラクティスに従ったほうが良いので) ベストプラクティスをそのまま採用するという選択をするかもしれないですし、そうではないかもしれませんが、そこに意思があるわけではないので。形は多少変わっても、ITエンジニアの価値が消えたわけではないだろうという、ややポジショントークでした。