ローコード開発はAIによって新たな局面を迎える

11月18日（火）に Wagby Developer Day 2025 を東京・お茶の水で開催します。

https://wagby.com/event/wdd2025/index.html

Wagbyの登場から20年が経過しました。
私たちがこれまで唱えてきた「仕様からアプリケーションを自動生成する = 動く設計書」というメッセージは今、AIの力を活用した「仕様駆動開発」そして「AI駆動開発」の登場によって新たな局面を迎えました。この大きな変化に Wagby はどう対応するのか、をお話ししようと思います。

「ロー」の開発を生成AIに任せるなら

もともとローコード開発と呼ばれる製品群は一般的に次の特徴を備えていました。

基本部分（主にデータベースのCRUD処理と、これに対応した簡単なUI）は設定によって自動生成する。
業務ロジックや複雑なUIは、そのローコードプラットフォームが提供する枠組みの範囲でカスタマイズコードを作成して対応する。

AIの登場によって、まず後者の「ロー」コード開発部分を（AIに）任せたいと考えるのは自然な発想です。しかしそのためには、AIがそのローコードプラットフォームをよく学習している必要があります。マイナーな独自仕様は不利になるということです。

さらに、考えてみると基本部分こそ、今のAIの得意分野ともいえます。その延長で複雑な業務ロジックも生成AIが対応できるなら、そもそも現在のローコード開発プラットフォームそのものがAIに代替できそうに思えます。

ここで「AIが代替」しやすいのは、汎用言語と、よく知られたフレームワーク上で動作するコードでの開発です。Javaでいえば、Spring Boot ベースの Web アプリケーション開発でしょう。つまりコード生成という観点でいえば、AIがやりやすい方向に任せて、すべて生成させてもよいのではないかと思えます。

となると Wagby のようなルールベースの自動生成エンジンは不要になりそうです。これをどのように捉えるべきか、昨年末からいろいろと考えた末、ようやく納得できるロードマップを立案できました。

仕様を理解することが人間の役割

2025年時点で、AIは「ざっくりとした要求」を（会話しながら）要件化し、さらにそこからデータベース定義、業務処理、UIといった仕様の文書を作成することまで可能です。もちろんまったくの未経験者には難しいですが、システムエンジニアの業務経験があれば簡単に使えます。

人間の仕事は、そのような仕様書をAIと競って作成することではありません。仕様そのものの意味を理解することです。自分たちが運用しようとしているシステムの全体像を把握すること、と言い換えることもできます。何か障害が発生したとき、適切に問題点を把握し、改良するためには人間が関わる必要があります。この点を放棄してしまうと、組織として、社会に対する説明責任を果たすことができなくなります。

ロードマップの考え方

これまで Wagby を用いて大規模な自社システムを開発してきたお客様からすると、同じ内容のアプリケーションを現時点のAIが作成できるのか？と思われるでしょう。私自身の判断は、2025年時点ではまだ早い、です。

まずAIに伝える仕様の記述量に一定の限界があります。トークン制限と知られているものです。そのためAI呼び出しを細分化する必要がありますが、これは経験が必要です。かつAIの能力向上も著しいため、そのような経験が通用する期間も短くなります。要はまだ発展途上であり、安定して使える方法は未だ固まっていないということです。これは大規模システム開発という観点からは、実験的に着手するのはよいが本番運用はまだ先になる、といえます。

次にAIが出すコードも安定しないことがあります。だいたい似ているし、合っているように見えるが、この品質を担保するのはテストしかありません。この点、Wagbyのようなルールベースエンジンに一日の長があります。実行のつど課金されることはなく、生成されたコードの品質も安定していることはメリットです。

この二点をふまえ、現実的なロードマップは次のようになるでしょう。