ローコード × AI を併用して分かった“実務上の相性”
こんにちは、DIVXエンジニアの野村です。
私は最近、Appsmith というローコードツールを使って業務用 Web ツールを構築しています。
入力画面・一覧・レポートなどを追加しているうちに、気づけば 100 ページ近い規模になりました。
開発の中では ChatGPT や Cursor などの AI も併用していますが、実務で使ってみると「ローコード × AI」は“万能でもないし、完全に噛み合うわけでもない」
というのが正直な実感でした。
本記事では、
どこが AI と噛み合わなかったか
どこなら AI を活用しやすかったか
どう組み合わせると開発がスムーズになるか
を、実際の開発経験から整理してみます。
Appsmith とは？
Appsmith は、ドラッグ＆ドロップで Web アプリを構築できるローコードツールです。
API やデータベースと連携しながら画面を素早く作れるため幅広い用途に使われています。
画面を早く作れる反面、内部構造は「JSON と JS の組み合わせ」で構成されており、規模が大きくなると “コードとは別の難しさ” が出てきます。
■ ローコード × AI を併用して感じた“相性の差”
① アプリ全体の情報を AI に渡すのは現実的ではない
Appsmith の画面構成はすべて JSON で管理されていますが、1ページだけでもかなりの行数になります。
最初は「全部まとめて AI に読ませれば、構造を理解してくれるのでは？」と期待して試しましたが、すぐ限界にぶつかりました。
JSON が長すぎて AI の入力上限に近づく
レイアウト座標や内部フラグなど“ノイズ”が多すぎる
知りたい部分（条件式・イベント）が JSON に埋もれる
結論： “アプリ全体を理解してもらう”という使い方はほぼ不可能。
そこでやったこと
方針を切り替えて、要素単位で小さく渡す形にしました。
ボタン 1 つの設定
テーブル 1 つの列定義
小さな JS 関数 1 個
など、分割して投げると AI が理解できる量になり、
条件式の整理
書き方の改善
仕様の矛盾チェック
などに活用できました。
② ローコード側にロジックを溜め込むほど、AIも自分も苦しくなる
Appsmith では {{ ... }} 中に JS を書けますが、便利さゆえにロジックを追加しがちです。
その結果、
似た条件分岐が別ページに散らばる
どこを直せば良いか分からなくなる
AI に投げても“全体像”を捉えられない
という状況に。
そこでやったこと：バックエンド側に寄せる
途中から FastAPI を導入し、ロジックの中心を API に移す 形へ変更しました。
特に次のような処理は API 側へ移行：
日付・数値の計算
データのフィルタ・ソート
ビジネスロジックに近い条件判断
DB の挿入・更新・削除
画面用の一覧データ整形
ローコード側は 「パラメータを渡す / 結果を表示する」 に絞り、AI（Cursor）に API の構造化・共通化を相談する流れが安定しました。
③ 共通レイアウトは AI でも解決できない
ページが増えると問題になるのが、次のような“共通パーツ”。
共通メニュー
複数ページにある注意書き
ボタンの配置パターン
Appsmith は 共通コンポーネントとして一元管理する仕組みが弱いため、変更があるとページをまたいで修正が必要になります。
AI で軽減できるのは、
抜き出したメニュー部分の修正案を作る
コードや設定の置換パターンを作る
といった部分的サポートまで。
できなかったこと
「全ページ分の共通レイアウトを一発で直す」といった使い方はできませんでした。
AI に部分的な修正案を作ってもらうことはできますが、 ページをまたいだ一括変更は、ローコードツール側の構造上どうしても手作業が必要になります。
■ 実際に“噛み合った”使い方
● 仕様の整理（AI が活躍）
画面数が増えるほど、まず必要になるのは 仕様の文章化。
ボタン表示条件
ステータス遷移
条件分岐のパターン
例外処理
文章にすると AI が：
抜けパターンを補完
構造を整理
不整合を指摘
してくれるので、ローコードで実装しやすい仕様に変換できるのが便利でした。
● ウィジェット単位で設定を渡してリファクタ
画面全体ではなく、小さな塊で AI に渡すと理解しやすくなり、回答の質が上がります。
ボタンの Visible/Disabled 条件
onClick のロジック
テーブル列の定義
などは、AI が得意に感じました。
● カスタムウィジェット（AI が最も強い）
ローコードでは実現しづらい、
複雑な表
期間・週単位での並び替え
特殊レイアウトの帳票
などは HTML＋JS の領域なので、AI が下書きを作るととても早いです。
■ “相性が良い／悪い”ではなく、「役割が違う」
実務で併用して感じたのは、
ローコードと AI は、どちらが優れているかではなく役割が違う。
ローコード
→ フォーム・一覧・軽いロジック・API 呼び出しが早いAI
→ 仕様整理、コード生成、複雑ロジックの言語化などが得意
この“役割の分担”が見えてから開発が楽になりました。
■ まとめ
ローコードと AI を併用してみて分かったのは、
ローコードだけでも作れる領域は確かにある
規模が大きくなるほど AI が助けてくれる場面も増える
ただし「全部 AI」「全部ローコード」はどちらも無理がある
という、ごく実務的なバランスでした。
結局大事なのは“どこまでを AI に任せ、どこからを人間が判断するか”をプロジェクトごとに見極めることだと思います。
もしこれからローコードと AI を組み合わせるなら、
まずは 1 つの画面・1 つの API・1 つのウィジェットを単位に「任せられる範囲」を試していくところから始めるのが最も安全で確実です。
