[Sponsored]

AI駆動開発の時代にローコードツールを再定義――「Wagby 11」が挑む、揺らがない業務アプリ開発

2026年10月29日(木)

リスト

生成AIによるコード開発が広がる中、ローコードツールの役割が改めて問われている。ローコードツール「Wagby」を提供するジャスミンソフトは、約20年にわたり培ってきた開発基盤の知見と生成AIを融合し、「AIとの対話だけでアプリケーションを作る」ことを目指してWagbyを全面刷新した。AIの柔軟性を生かしながら、いかにして企業システムに不可欠な一貫性、品質、保守性を確保するのか。生まれ変わった「Wagby 11」の開発思想と仕組みに迫る。
提供：株式会社ジャスミンソフト

株式会社ジャスミンソフト代表取締役贄良則氏

生成AIは脅威か好機か――20年を経た今、Wagbyを再構築

　生成AIによるコード作成、いわゆるバイブコーディングが広がる一方で、ローコードツールは存在感を失いつつある。「Wagby」を提供するジャスミンソフトも、この状況に強い危機感を抱いていた。

　同社代表取締役の贄良則氏は、「従来のローコードツールは、『仕様駆動開発』に近い考え方を持った仕組みです。生成AIが仕様から直接コードを作れるようになれば、ローコードツールの役割がなくなる可能性もあると考えました」と振り返る。

　しかし、自らさまざまなコード生成AIを試す中、むしろ生成AIは、ローコードツールが長年目指してきた理想を実現する技術になり得ると認識を改めたという。

　「ローコードツールはスクラッチ開発より扱いやすい一方、固有の仕様記述やプログラミングの知識が必要で、依然としてエンジニア向けの側面が強く残っていました。そこに生成AIを活用すれば、業務に詳しい現場担当者が、普段使う業務用語で要望を伝えるだけで、システムを構築できる可能性が広がります」と贄氏は語る。

　背景には、約20年にわたりWagbyを提供してきた中で培った知見に加え、既存仕様への反省もあった。改良を重ねるうち、製品側のさまざまな「都合」が蓄積されていたのだ。生成AIの登場を、過去のしがらみを断ち切り、再生へと向かう絶好の機会と捉えた。

　こうして同社は、「AIとの対話だけでアプリケーションを作る」という目標を掲げ、Wagbyそのものを土台から作り直すべく舵を切った。

　「Wagbyを超えるツールを他社に作られるくらいなら、先に自分たちで作ろうと考えました」と贄氏は強調する。既存のローコードツールベンダーというより、AI時代のスタートアップのような意気込みで開発に臨んだという。

コード生成AIの「揺らぎ」が企業システムにもたらす課題

　贄氏自身がコード生成AIを試す中で問題視したのは、出力結果の「揺らぎ」である。

　同じ内容の詳細なプロンプトを与えても、AIが生成するコードは毎回異なる。動作に支障はなくても、企業が長期間にわたって利用するエンタープライズシステムでは、この不安定さが大きな問題になる（図1）。

図1：AI駆動開発に残された課題「安定したコードの出力が困難」
拡大画像表示

　例えば、ある時期に作成した画面と、別の時期に追加した画面で構造や操作感が異なったり、同じ処理であってもコードの書き方が変わったりすれば、保守や品質管理が難しくなる。数年後に機能改修を行った際、AIが以前とはまったく異なるコードを生成してしまうと、周辺機能へ及ぼす影響を、人間が改めて全面的に確認しなければならない。

　また、業務システムには、ユーザーが明示的に指定しなくても、経験のあるエンジニアであれば当然考慮する「暗黙の要件」が数多く存在する。同時更新を防ぐデータロック、作成者・更新者・更新日時などの監査項目、操作履歴や障害解析のためのログ、権限管理、データ削除の制御、長期運用を前提とした保守性、仕様書やコードの記述ルール、テスト方法や品質保証の基準といった非機能要件だ。

　これらをすべてプロンプトに記述すると、膨大な指示が必要になる。どれほど細かく書いても漏れを完全には防げず、生成結果の妥当性を人間が確認する負担も残る。

　結果として、コードを書く代わりに長大なプロンプトを書き、さらに、生成されたコードを全面的に検証することになり、「AIで楽になるはずが、かえって負担が増える」という事態になりかねない。

　仕様書も同様だ。記載項目や書き方が人によって異なれば、保守が困難になる。「AIとの対話で毎回仕様を決めるのではなく、企業システム開発の知見をあらかじめAIが利用できる枠組みとして提供する必要があると判断しました」と贄氏は語る。

AIの柔軟性とローコードの安定性を融合するハイブリッド設計

　生まれ変わった「Wagby 11」の最も重要なポイントは、AIの利便性を生かしながら、企業システムに必要な一貫性と安定性を確保することにある。そのために同社が取り入れたのが、AIの挙動を制御するための「ハーネスエンジニアリング」だ。

　贄氏は、Wagbyが追求してきたハーネスエンジニアリングの本質は「一貫性」にあると説明し、「同じ指示を与えた場合に、細部まで含めて安定した構造とコードを生成できることを、製品としてどこまで保証できるかにこだわりました」と語る。

　この方針に基づきWagby 11では、すべてをAIに生成させるのではなく、「業務内容を理解し、設計情報や業務固有の処理を作るAI」と、「定型部分を決められたルールに基づいて生成する従来型ローコード技術」を組み合わせたハイブリッド方式を採用した。

　AIが得意な自然言語理解や柔軟な解釈と、ローコードが得意とする安定したコード生成を組み合わせることで、利便性と品質の両立を図っている。

　これを実現したのが、REST APIを中心に据えた新しいアーキテクチャーだ（図2）。業務ロジックを持つREST APIサーバー上に、Webアプリケーション、スマートフォン向け画面、MCPサーバー、外部システムとの連携機能、今後追加される各種サブシステムといった複数のインターフェースを構築する。

　「OpenAPI規格に準拠したREST APIにより、外部システムとの接続性や技術的な汎用性が高まります。加えて、AIも既存の学習知識を応用しやすくなります」と、贄氏はこのアーキテクチャーの利点を示す。

図2：Wagby 11のアーキテクチャー
拡大画像表示

設計情報を介した二段階生成で、一貫したコード品質を確保

　そのうえでWagby 11は、二段階のコード生成方式を採ることで「揺らぎ」を抑える（図3）。一般的なAI駆動開発では、仕様書や指示文からAIが直接プログラムコードを生成する。これに対しWagby 11では、AIは直接コードを作らず、中間段階としてWagby用の設計情報を作成するのだ。

図3：Wagby 11におけるコード生成プロセス（一般的なAI駆動開発との比較）
拡大画像表示

　具体的な処理の流れは次のようになる。

①ユーザーが業務資料や自然言語の指示をAIへ渡す
②AIが内容を解釈し、Wagby 11用の設計情報をYAML形式で作成する
③Wagby 11のローコードエンジンが、その設計情報から定型コードを生成する
④定型化しにくい業務固有の処理のみをAIが補完する
⑤AIがテストケースとテストコードを作成する
⑥テストを実行し、アプリケーションの動作を確認する

　YAML形式の設計情報では、データベース定義、業務ロジック、権限設定、計算式など、どこに、どのように書くかが厳密に決められている。AIが自由な形式で設計書を作るのではなく、規定された項目を埋めるため、構造的な揺らぎを抑えられるのだ。

　「設計情報からコードを生成する工程にはAIを使わず、従来のローコード技術を利用します。結果として、同じ設計情報からは同じ構造のコードが機械的に生成されるため、定型部分の品質を安定させられます」と贄氏は強調する。

　一方、複雑な業務ルールなど、定型化が難しい部分については、最終的にAIがコードを書くことになる。ただし、AIがアプリケーション全体を自由に変更できるわけではない。Wagby 11では、SPI（Service Provider Interface）という拡張ポイントを設けることで、AIがコードを記述できるクラスやメソッド、場所、形式を限定している。

　「AIは、Wagby側があらかじめ用意したクラスやメソッドの内部だけを埋めます。勝手な場所にSQLを書いたり、別の階層に業務ロジックを追加したり、システム全体の構造を変更したりすることはできません。コード内部の変数名や計算順序などには多少のゆらぎが生じる可能性はありますが、入力に対して同じ出力が得られることをテストで確認できれば、これは許容可能な範囲と考えています」と贄氏は説明する。

　なお、コード行数を基準にすると、Wagby 11が生成するコードのうち、約98％をローコード側が作り、AIが直接記述する業務固有部分は約2％になるという。業務ロジックの重要度を単純に行数だけで判断することはできない。それでも、AIが自由に生成する範囲を最小限に絞ることで、人間が確認すべき対象を大幅に減らせる（図4）。

図4：新たな設計思想「ローコード×AI」
拡大画像表示

現場主導の開発を広げる、AI時代の新たな業務基盤へ

　ここまで述べてきたように、Wagby 11は既存のローコード製品に生成AI機能を追加したものではなく、AIとの対話による業務アプリケーション開発を前提に、製品のアーキテクチャーをゼロベースで作り直した新しい開発基盤である。

　重ねて強調しておきたいのは、AIに直接すべてのコードを書かせないことだ。AIは自然言語や既存資料を読み取り、厳格なフォーマットの設計情報を作成する。定型コードの大部分は、実績のあるローコード技術が機械的に生成し、AIが直接書く業務固有コードは限定された拡張ポイントに絞る。さらに、テストケースやテストコードも作成するため、人間はコード全体ではなく、業務要件とテストの網羅性を中心に確認すればよい。

　Wagby 11が目指すのは、生成AIの柔軟性や開発速度を生かしながら、エンタープライズシステムに求められるコード品質、一貫性、保守性、監査性、長期運用の安定性を確保することだ。

　「従来のローコードが持つ『手堅さ』と、生成AIが持つ『便利さ』を融合します。エンジニアだけでなく、業務を熟知した現場担当者や市民開発者が、積極的に業務アプリケーションを作れる環境を提供することが、Wagby 11の真の狙いです」と贄氏は訴求する。

　Wagby 11は、費用や人材の制約から見送られてきた業務のシステム化を、現場主導で進める可能性を広げる。生成AIの柔軟性とローコードの一貫性を組み合わせる試みは、企業の業務アプリケーション開発を、より身近で持続可能なものへ変えていきそうだ。