ローコード開発のデメリット7つ｜スクラッチとの使い分けと導入判断

50人が5年使うと、kintoneのスタンダードコースだけで540万円。ローコード開発は初期費用の安さで語られますが、支払いはライセンス費として人数と年数に比例して続きます。デメリットはコストだけではありません。プラットフォーム側には24時間あたりの要求回数という上限があり、部品の組み合わせで作る方式には対応できない要件の型があり、乗り換えようとすれば設定資産はほぼ引き継げません。この記事では、実務で効いてくる7つの制約を影響度の順に並べ、公開価格から算出した損益の逆転点、採用を見送るべき条件、契約前に確認しておく項目までを発注側の判断材料として整理しました。

まとめ：ローコードの限界はライセンス費の累積と拡張の天井で決まる

ローコード開発を見送るかどうかは、2つの数字で大方決まります。ひとつは利用人数×契約年数で積み上がるライセンス費の総額。もうひとつは、作ろうとしている処理がプラットフォームの上限と表現力の内側に収まるかどうかです。

ライセンス費は、少人数のうちは圧倒的に有利に働きます。20人で5年ならkintoneスタンダードで216万円、Power Apps Premiumでも約360万円。この規模でスクラッチ開発を選ぶ理由はほとんどありません。ところが200人規模になると同じ計算で2,160万円と約3,598万円になり、初期に一括で払うスクラッチ開発の見積もりと肩を並べます。人数が増える見込みがあるほど、ローコードのコスト優位は薄れていきます。

もうひとつの天井は技術側です。Power Platformの有料ライセンスユーザーは24時間あたり40,000要求、アプリ単位ライセンスや従量課金では6,000要求で頭打ちになります。夜間バッチで数万件を回すような処理は、この枠の中に設計を押し込む前提で考える必要があります。

結論として、社内の限られた人数が使う業務アプリで、処理件数が読めていて、5年以内に人数が数倍にならない。この3条件が揃うならローコードのデメリットは許容範囲に収まります。外部の顧客に提供する、トラフィックが読めない、業界固有の複雑な計算が中核にある。いずれかに当てはまるなら、無理に寄せずスクラッチ開発を選ぶほうが総額でも納期でも有利です。

部品の組み合わせという方式が構造的に生む制約とスクラッチとの差

デメリットの多くは、個々の製品の出来不出来ではなく、ローコードという方式そのものから出てきます。何が原因で何が制約になるのかを先に押さえておくと、製品を比べる段階での判断が速くなります。

用意された部品を組む方式が抱える対応不能な要件の3類型の整理

ローコード開発は、画面部品・データ項目・処理フローをGUIで組み立て、足りない部分だけコードを書く方式です。裏を返せば、部品として用意されていないものは原則として作れません。

対応できない要件はおおむね3つの型に分かれます。第一に、画面の描画を細部まで制御する要件。ピクセル単位のブランド指定や、独自のインタラクションを持つUIは、テンプレートの枠から出た瞬間に工数が跳ね上がります。第二に、大量データを跨いで走る重い処理。数十万行の集計や、複数テーブルを結合した再計算はプラットフォームの実行基盤の性格に左右されます。第三に、外部システムとの非標準な連携。標準コネクタがある相手なら数分ですが、無い相手には結局APIを自前で書くことになります。

方式の違い自体を先に整理したい場合は、スクラッチ開発とパッケージ・ローコードの違いをまとめた記事に開発方式ごとの前提条件を並べてあります。

ノーコードとの境界＝コード拡張の可否とそれが生む管理コストを見極める

ノーコードとの差は「コードを書けるかどうか」の一点です。そしてこの差が、ローコード固有のデメリットを生みます。

コードを書ける以上、書かれます。JavaScriptカスタマイズ、プラグイン、独自コネクタといった拡張が積み重なると、GUIの画面だけを見てもシステムの挙動が分からない状態になる。GUIで見える部分とコードで書かれた部分が分離し、担当者が変わったときの引き継ぎコストが両方に発生します。ノーコードなら「できないことはできない」で終わる話が、ローコードでは「できるが後で誰も読めない」に化けます。

この境界の考え方はノーコードでできることと限界を整理した記事で扱っています。本記事では、拡張を許した後に発生する保守側の負担をデメリットとして数えます。

実務で効くローコード開発のデメリット7項目と影響度の順位付け

以下の7項目は、影響が大きい順に並べてあります。案件の8割で最初に効いてくるのは上位3つです。下位の項目は、上位をクリアしたうえで詰める話だと考えてください。

人数と年数に比例して積み上がるライセンス費というコスト構造の見方

最も見落とされるのがここです。kintoneはライトコースが1人月額1,000円、スタンダードコースが1,800円、ワイドコースが3,000円（いずれも税抜）。Power Apps Premiumは年払いでユーザーあたり月額相当2,998円、最小2,000シートを契約する条件でようやく1,799円まで下がります。

単価だけ見れば安価に映ります。しかし支払いは使い続ける限り止まりません。スクラッチ開発の見積もりは初期に山があり、その後は保守費だけが残るのに対し、ローコードは平坦な支払いが人数分だけ横に伸びていく形です。しかも最低契約ユーザー数があり、kintoneのライト／スタンダードは10ユーザーから、ワイドコースに至っては1,000ユーザーからしか契約できません。5人で使いたくても10人分を払います。

API要求上限とデータ容量というプラットフォーム側に置かれた天井

技術的な上限は、契約前に必ず確認する数値です。Microsoft Learnの「要求の制限と割り当て」によれば、Power Platformの有料ライセンスユーザーは24時間あたり40,000要求。アプリごとのPower Apps有料ユーザー、従量課金制プラン、Power Platformアクセス権を持つMicrosoft 365の有料ライセンスユーザーはいずれも6,000要求です。ポータルの有料ログインは200。

この枠は繰り越せません。使い切らなかった分が翌日に回ることも、月内に貯まることもない仕様です。超過分はキャパシティアドオンで買い足せますが、1つあたり増えるのは24時間で50,000要求という単位になります。

容量側にも同じ構造があります。kintoneのディスク容量は1ユーザーあたり5GB、アプリ数はライト200・スタンダード1,000・ワイド3,000という上限つき。Dataverseの容量アドオンは年払いで1GBあたり月額相当5,997円です。添付ファイルを多用する業務では、この単価が効いてきます。

ベンダーロックインが移行時に強いる実質的な作り直しの範囲を確認する

ローコードで作った資産は、他社製品へそのままは移せません。移せるのはデータだけで、画面定義・入力チェック・承認フロー・権限設定といった、実際に工数を投じた部分は各社独自の形式に格納されています。乗り換え＝要件定義からの再構築、と考えて差し支えありません。

価格の交渉余地も限られます。OutSystemsは公式の価格ページで具体的な金額を公開しておらず、アプリの規模とエンドユーザー数に応じた個別見積もりです（無償のPersonal Editionは本番利用不可・社内ユーザー100名まで・開発環境のみ）。金額が非公開であること自体は珍しくありませんが、更新時に横並びで比較しづらい状態を作ります。契約更新のたびに「移行コストのほうが高い」という理由で条件を飲む構図になりやすい。

市民開発の前提となる学習コストと属人化・離職で止まるリスクへの備え

「プログラミング不要」は「学習不要」ではありません。データベース設計、正規化、権限モデル、業務フローの整理といった前提知識が無いまま作られたアプリは、項目を1つ足すたびに整合が崩れます。GUIで作れることと、後から直せる構造で作れることは別の能力です。

そして作った本人がいなくなると止まります。情報システム部門ではなく事業部門の1人が趣味的に育てたアプリほど、この形で機能不全に陥ります。ドキュメントが残らないのは、書かなくても作れてしまう方式の副作用です。

ガバナンス不在で増える野良アプリと権限設定の穴が生む事故への備え

誰でも作れる状態を放置すると、部門ごとに似たアプリが並立します。同じ取引先マスタが3つあり、それぞれ更新のタイミングが違う。集計が合わない原因を追う工数が、削ったはずの開発工数を上回ります。

権限も穴になりやすい部分です。作成者が管理者権限を持ったまま異動する、テスト用に緩めた共有設定が本番のまま残る、外部連携用のコネクタに強い権限が紐づいたままになる。ローコード基盤は個々の設定画面が分散しているため、棚卸しの手間が想像以上にかかります。この領域の対策はローコード開発のセキュリティリスクと対策で、権限設計と棚卸しの手順まで分けてまとめました。

UI・帳票・外部連携で繰り返し出る細部の作り込み不能パターン

実案件で「あと一歩」が届かない箇所は、驚くほど決まっています。

• 日本の商習慣に沿った複雑な帳票レイアウト（罫線の結合、繰り返し行の改ページ制御、押印欄）
• 入力途中で条件によって項目の出し分けが多段に変わるフォーム
• スマートフォンでのオフライン入力と後からの同期
• 既存の基幹システムが持つ独自形式ファイルとの双方向連携
• 1画面に大量の明細を表示しつつ即時に再計算する画面

これらは「できない」わけではなく、「無理に寄せると工数がスクラッチを超える」領域です。要件定義の段階でこの5つに該当する項目がいくつあるかを数えておくと、判断の精度が上がります。

バージョン管理とテスト自動化が効きにくい保守運用時の負荷の実態

GUIで作った定義はテキストの差分として読めません。誰が何をいつ変えたかを追う仕組みは製品側の履歴機能に依存し、Gitでレビューしてから本番へ、という流れは組みにくい。テストも同様で、自動テストの記述対象がコードではなく画面操作になるため、保守のたびに手動確認の範囲が広がります。

本番環境で直接編集できてしまう製品では、この問題がさらに深刻になります。検証環境を分けられるか、環境間で定義を移送する仕組みがあるかは、製品比較の初期に確認しておく項目です。製品ごとの違いはローコードツールの用途別比較と選定基準をまとめた記事で扱っています。

ローコードとスクラッチ開発の総額が逆転する利用規模と契約年数

デメリットを金額に換算すると、判断はかなり単純になります。ここでは相場や見積もりの内訳ではなく、「どの規模から不利になるか」という一点だけを見ます。

利用人数×契約年数で見たライセンス総額と初期開発費の逆転点を探る

公開されている単価を、値引きもアドオンも無い前提で5年分に伸ばすと次のようになります。

業務アプリ1本のスクラッチ開発が数百万円台に収まる案件であれば、50人規模で既に射程内に入ります。200人規模ならライセンス費だけで数千万円に達し、専用に作ったほうが安いという結論が普通に成立します。判断の分かれ目は人数そのものではなく、「今の人数×これから使う年数」です。3年で作り直す前提のアプリと、10年使う基幹周辺のアプリでは、同じ50人でも答えが変わります。初期構築費や保守費まで含めた総額の内訳と、償却年数を変えたときの分岐点はローコード開発の費用相場と5年総額比較で試算しています。

デメリットを許容できる案件と致命傷になる案件の判別条件を見極める

許容できるのは、次の条件を満たす案件です。利用者が社内に閉じている。処理件数の上限が読める。要件が半年単位で変わり続け、作り直す前提で回したい。既存の表計算ファイルによる運用を置き換えるのが主目的である。この型では、拡張の天井に当たる前に投資回収が終わります。

致命傷になるのは逆の型です。外部の顧客が使う、アクセス数が予測できない、法令や業界標準に沿った複雑な計算ロジックが中核にある、監査で変更履歴の提出が求められる。ここでローコードを選ぶと、制約を回避するための作り込みが積み上がり、GUIとコードが混在した保守しづらい構造だけが残ります。

デメリットを契約と設計で潰す発注側の具体策と見送りの判断基準

ここからは判断を明示します。ローコードのデメリットは全て回避できるものではなく、発注前に潰せるものと、潰せないから採用しない理由になるものに分かれます。

ロックイン対策として契約前に確認するデータ出力とソースの所有

契約書と製品仕様で先に押さえる項目は4つです。

1. データの全件エクスポートが管理者操作で可能か。添付ファイルと変更履歴を含むか
2. 拡張として書いたコードの著作権と、契約終了後の利用可否がどちら側にあるか
3. アプリ定義（画面・フロー・権限）を機械可読な形式で書き出せるか
4. 解約時のデータ保持期間と、その間の取り出し方法

4つのうち1と4は多くの製品で満たせます。2と3は交渉と確認が要る部分で、ここが曖昧なまま進んだ案件が、数年後に「移行できないので値上げを受け入れる」状態に陥ります。開発を外部に委託する場合は、成果物としてアプリ定義のエクスポートを納品物に含めておく。この一文があるかどうかで、後の選択肢の幅が変わります。

ローコードを採用しない条件＝外販・トラフィック不定・複雑計算

次の3つのいずれかに当てはまる案件では、ローコードを採用しません。玉虫色に濁さず言い切ります。

ひとつ、外部の顧客に有償で提供するプロダクト。ユーザー数の増加がそのままライセンス費の増加になり、粗利が構造的に削られます。ふたつ、トラフィックが読めない、あるいは季節で数十倍に振れるシステム。24時間あたりの要求上限という枠に対して、ピークを吸収する設計余地が乏しい。みっつ、業界固有の複雑な計算や判定が価値の中核にある業務。この部分は結局コードで書くことになり、GUIで組んだ周辺と分離した二重構造が生まれます。

逆に、この3条件のどれにも当たらない社内向け業務アプリであれば、デメリットを承知のうえで採用して問題ありません。失敗パターンとして最も多いのは、3条件に当たっているのに「まずは安く小さく始める」を理由に押し切り、1年後に作り直す判断を迫られる進め方です。

スクラッチと併用するハイブリッド構成における責任分界点の引き方

現実的な着地は、全部をどちらかに寄せない構成です。マスタ管理・申請承認・簡易な一覧といった定型部分をローコードで持ち、計算エンジンや外部公開する画面をスクラッチで作ってAPIで繋ぐ。この形なら、ライセンス費が効く人数はローコード側の利用者だけに限定でき、要求上限に触れる重い処理はスクラッチ側へ逃がせます。

分界点は「変更頻度」で引くのが実務的です。月単位で項目が変わる部分はローコード、年単位でしか変わらないが正確さが要る部分はスクラッチ。組織の側も、前者は事業部門、後者は情報システム部門と開発会社という担当分けにすると、権限設計と一致します。どちらにどこまで寄せるかの線引きは案件ごとに違うため、要件の一覧を持ち込んでノーコード・ローコードアプリ開発の相談窓口で仕分けから詰めるほうが、製品を先に決めるより手戻りが少なくなります。その仕分けを任せる相手の選び方は、ローコード開発会社の選び方と内製・外注の判断基準で整理しました。

よくある質問

ローコード開発の導入判断でよく挙がる質問を、実務で答えている内容にそって5つまとめました。

ローコード開発のデメリットで最も影響が大きいのはどれですか？

利用人数と契約年数に比例して積み上がるライセンス費です。技術的な制約は要件を削れば回避できますが、費用は使い続ける限り発生し続けます。kintoneスタンダードの1人月額1,800円（税抜）で計算すると、50人5年で540万円、200人5年で2,160万円。導入時点の人数ではなく、5年後に何人が使っているかで見積もってください。次に影響が大きいのがベンダーロックインで、これは移行の選択肢そのものを奪うため、契約前の確認以外に対処法がありません。

ローコード開発はセキュリティ面で不安がありますか？

基盤そのものはISO 27001などの認証を取得した事業者が運用しており、自社で構築する場合より堅い場合もあります。問題になるのは運用側です。誰でもアプリを作れる状態で権限設計のルールが無いと、テスト用に緩めた共有設定が本番に残る、退職者が作成者権限を持ったまま放置される、といった穴が分散して発生します。作成できる人を限定する、外部公開の設定は情報システム部門の承認制にする、四半期ごとに権限を棚卸しする。この3つを運用ルールに組み込めるかどうかで評価が変わります。

ローコード開発とノーコード開発でデメリットに違いはありますか？

あります。ノーコードは「できないことは最初からできない」ため、限界が早期に判明し、判断も早く済みます。ローコードはコードで拡張できるぶん限界が見えにくく、無理に寄せた結果としてGUI部分とコード部分が混在した保守しづらい構造が残りやすい。学習コストもローコードのほうが高く、GUIの操作に加えて拡張言語とデータモデルの知識が要ります。事業部門の担当者だけで完結させたいならノーコード、情報システム部門が保守に関われるならローコードという分け方が現実的です。

ローコードで作ったアプリはスクラッチ開発へ移行できますか？

データは移行できますが、画面定義・入力チェック・承認フロー・権限設定は各製品の独自形式に格納されているため、実質的に作り直しになります。ただし、ローコードで運用した期間に確定した業務要件そのものは資産として残ります。実際に使われた画面と項目、実データの分布、使われなかった機能。これらは要件定義の精度を大きく上げるため、移行時の見積もりはゼロからの新規開発より安定します。プロトタイプとして割り切って使い、本番はスクラッチという進め方は成立します。

ローコード開発の費用はスクラッチ開発より本当に安く済みますか？

利用人数が少なく、使う年数が短いほど安く済みます。20人5年ならkintoneスタンダードで216万円、Power Apps Premiumで約360万円ですから、同等機能をスクラッチで作るより明確に有利です。一方で200人5年では2,160万円と約3,598万円になり、逆転します。加えて、要求上限を超えるためのキャパシティアドオン（1つで24時間あたり50,000要求）やDataverseの容量アドオン（年払いで1GBあたり月額相当5,997円）が積み増されると、当初の試算から乖離します。人数の増加見込みとデータ量の伸びを含めて5年総額で比較してください。

関連記事

• スクラッチ開発とは？パッケージ・ローコードとの違いと発注判断を解説：開発方式ごとの前提条件と、ローコードを外したあとの選択肢を整理しています
• ローコードツールとは？用途別の比較と選定基準・スクラッチ開発との使い分けを解説：本記事の制約を許容できると判断した後の、製品選びの基準をまとめています
• ノーコードとは？ローコードとの違い・できること・限界を実務目線で解説：コード拡張を持たない場合の限界と、判断が早く済む理由を扱っています
• ノーコードツール比較｜業務アプリ・Web・EC用途別の代表製品と選び方：ノーコード側に寄せる判断をした場合の製品比較です