見出し画像

ローコードとLLM 〜最適化と自己修復の未来〜

Seiji Takahashi@ベースマキナ

まとめ

プログラミングの未来では、最適化と自己修復がキーワードとなり、エンジニアは検品作業が主な役割になると考えられます。
ローコードツールは、否応なしにLLMとの共存を求められ、対応できなければかえって足かせとなってしまい淘汰されるでしょう。
そして、ローコードやノーコードの概念が意味を持たなくなるでしょう。
しかし、未来はシステムのチューニングに焦点を当てた業務になり、チューニングのための学習データを幅広に獲得できる現在のローコードプラットフォーマーは、きたる未来に備えて強力な武器を持てると考えられます。

ごあいさつ

こんにちは！
ローコードでかんたんに管理画面が立ち上げられるSaaS「ベースマキナ」を運営している、
株式会社ベースマキナの代表取締役社長の髙橋と申します。

サービスページはこちらです。管理画面の開発工数でお困りの方、手前味噌ながら大変便利なサービスに進化してきているので是非一度お話しましょう！

さて、元々私自身ソフトウェアエンジニアなこともあり、昨今のLLM熱には興奮せざるを得ない状況です。
一方で自分はローコードという市場に身を置いており、この市場のプレイヤーはソフトウェアエンジニアの在り方そのものと同じくらい、LLMの自社への影響をシビアに鑑みなくてはなりません。
開発難易度がまあまあ高いこともありプレイヤーが粒ぞろいな市場なのですが、あまりLLMへの言及が見られないため、せっかくなので私見を述べてみようと思い立った次第です。
長くなりますがご一読いただければ幸いです。


プログラミングの未来に関する私見

私がプログラミングの未来について考える際、キーワードとなるのは「最適化」と「自己修復」です。

最適化

最適化とは、企業ごとに適切なシステムが作成されるまでのスピードが大幅に向上することを指します。
これが実現できるのは、要件と成果物の対応関係をナレッジとして蓄積したプラットフォーマーが持つLLMの力によるものです。

自己修復

次に自己修復とは、文字通りLLMが生成したコードをLLMが修復していく未来を意味します。また、自己修復に関する議論になると「エンジニアがすべて消え去る」という話になりがちですが、私はそうはならないと考えています。一方で、「より創造的な仕事に従事することになる」というのは具体性に欠けていてなんとも言えません。

エンジニアの役割

この2つのキーワードを踏まえて私見を述べるなら、エンジニアに最後に残される仕事は「検品作業」ではないかと思います。
つまり、最適化と自己修復が施された結果が、現実の人間の意図に沿っているかどうかを確認する作業です。

事実、私自身は割と「LLMに問いを投げかける」という作業が当たり前になりつつあり、うまいこといったなと感じたやり取りを再現できるプロンプトを会話の最後に生成してもらったり、自分の知識が浅いAPIを利用するときの叩き実装はLLMにお願いしたりしていて、割と検品作業の比率が増してきています。
もちろん現在は叩き実装の粋を出ないのですし、結果もまちまちですが、下記のように自己修復のPoCはもう済んでいるんではないかと思います。

プログラミングの未来とローコード

ここでローコードの話に戻ります。
ローコードとLLMは、ソフトウェアエンジニアの開発体験に影響を与える点で密接に関連しています。

結論ですが、今後はメンテナンス性が低く、エンジニアの開発現場に距離が近いGitHub Copilot XなどのLLMをベースにしたツールのメリットを活かしきれないローコードツールは淘汰されるでしょう。
LLMによってまず恩恵を得るのはエンジニアであり、手元での開発速度の向上だと私は考えています。手元の開発速度が上がったのにローコードのツールがついていけない、というのは逆に不便で使わなくなってしまうでしょう。

ここで言うメンテナンス性が低いとは、設定のフォーマットや保存場所が過度にプラットフォームにロックインされてしまうことを指します。要するに、ローコードを始めとした開発者向けツールのうち、フォーム入力だけで設定することを前提としたものは、開発者の足を逆に引っ張ってしまいうるものになり、次第に市場から消えていくことになります。

前述の議論を考慮すると、ローコードは最適化と自己修復の精度を上げたシステムを提案できるか、そしてエンジニアの検品コストを下げられるかという問いに常に答え続けなければなりません。
つまり、ローコードの未来はエンジニアが手元でLLMを操作することを前提とし、その成果物の動作環境をいかにスピーディかつ個々の企業の要件に合わせてチューニングできるかという、”手早い調整力”にかかっています。

ローコードからノーコード、それらを超えて

最後に、ローコードという呼称も近いうちに無くなると私は考えています。
実際、自然言語を解釈しながら自己修復していくような代物はもはやローコードどころかノーコードですらない（あるいは、真のノーコード？）のではないでしょうか？

また、ローコードやノーコードというのは、エンジニアやそれ以外の職種の方が、いかにコードを書かずにシステムを作成できるか勝負を行っていたわけですが、自然言語入力という最も初期学習コストが低いUI表現を得た今、どのプラットフォームもそれを取り入れた設定画面にならざるを得ません。
完全に自然言語で済むとも思えませんが、少なくともローコードとかノーコードとか、そういうキーワードは特別な意味を持たなくなると思います。

このようなことを書くと、私が悲観しているようにも取れるかもしれませんが、実際はそうではありません。

ほとんどの法人サービス提供者が同じような問いに向き合うことになると思いますし、システムが自動生成したものを微調整した上で提供する進化版SIer的な役割を様々なソフトウェア事業者が担うことになると考えています。
これは「プログラミングは目的を達成する手段」という言葉がより重みを持ち、パソコンを捨てて人間社会で起こる問題に目を向けられる時間が増えることでもあると思っていて、そういう意味ではいい勝負が始まりそうな予感がします。

話を少し戻すと、そんなシステムがシステム自体を産み、その成果物を人間がチューニングしていく未来になる場合、業務要件と成果物のシステムの対応関係を幅広くデータとして蓄積できる私たちローコードのプラットフォーマーは、チューニングするコストを徹底的に抑えられる武器を備えていると言えると私は考えています。
実はこれこそが、今混沌とした状況の先に底堅い未来を手にする最強の手札だと考えていて、比較的いいポジショニングだと自負しています。

そう遠くない未来に、技術の進化によって熱が冷め、LLMでできることとできないことの線引きが見えてくるでしょう。 ただ確実に言えるのは、私たちは技術進化の最前線に立っているということです。

最後に、私たちベースマキナでも、LLMと最前線で共存する未来に向けて地盤を整えようとしています。そしてこうした環境下で、共に愚直に事業を創りつつ未来を考えられる仲間を募集しています。
一緒に事業を築きたい、または同じような考えを持っていたんだよね、いや自分はそうじゃないと思うなど、少し話をしてみたいと思っていただける方がいらっしゃいましたら、ぜひTwitterなどでお気軽にご連絡ください。

Twitterアカウントはこちらです。お読みいただき、ありがとうございました。


この記事が気に入ったらサポートをしてみませんか？