ローコード・ノーコードとは

ローコード・ノーコードとは

画面の構成要素を並べる操作や項目の設定を中心に、プログラムをほとんど書かずに業務アプリを開発する手法と、そのための開発基盤を指します。
開発したアプリは基盤の上で稼働し、多くはクラウドのサービスとして提供されます。

現場の社員が自ら開発する使い方

部署ごとの申請や台帳は開発会社に依頼するほどの規模ではなく、情シスに依頼しても優先順位が上がらないので、表計算ファイルとメールで運用されてきました。
その結果ファイルの版が分かれ、集計に毎月何時間もかかります。
業務を熟知した現場の社員が、こうした業務を数日から数週間でアプリにします。
この取り組みは市民開発と呼ばれます。
kintoneやPower Appsがこの使い方の代表的な製品です。

技術者が生産性を高めるために利用する使い方

開発会社や社内の技術者が企業向けの基盤を利用します。
顧客向けの画面や基幹システムも対象になります。
デンソーはOutSystemsを社内の開発標準にし、顧客管理システムの再構築で設計と製造の工数を半分にしました。
開発するのは技術者なので、比較の対象はスクラッチ開発になります。

ノーコードとローコードの違い

違いはプログラムを書く余地があるかどうかです。
ノーコードは設定だけで開発する前提で業務担当者でも利用できるが、製品が用意した機能の範囲でしか開発できません。
ローコードは設定だけでは実現できない処理を少しのプログラムで補える代わりに、補った部分の保守に技術者が必要になります。
製品によって境目はあいまいで、意思決定の場では同じ枠で検討すればよいです。

SaaS・ローコード・開発会社のどれを選択するか

業務アプリの作り方はSaaS（Software as a Service）の利用、ローコード・ノーコードでの開発、開発会社による一からの開発の3つです。
ローコードは作り手が現場の社員か技術者かで性格が変化するので、表では2行に区分しました。
違いは誰が変更を担い、費用が何に比例して増加するかです。

作り方	業務の合わせ方	変更の担い手	費用の伸び方	乗り換えの制約
SaaS	業務を製品に適合させる	提供元。自社は設定の範囲で変更する	利用者数に比例	データは出力できるが、業務のやり方を製品に適合させた分だけ移行しにくい
現場の社員が開発するローコード・ノーコード	製品の機能の範囲で業務に適合させる	開発した現場の社員	利用者数に比例	画面と業務のルールは製品の外へ持ち出せない
技術者がローコードの基盤で開発する	ほぼ業務に適合させられる	開発会社か社内の技術者	利用者数か基盤の規模に比例	基盤の上でしか稼働せず、基盤を変更するなら再構築
開発会社に一から開発してもらう	業務に適合させる	開発会社か社内の技術者	保守費とインフラ費。利用者数にはほぼ比例しない	ソースコードの権利と引き渡しを契約で確保していれば、保守の担い手を変更できる

上の行ほど短期間かつ安価に開始できます。
下の行ほど自社の業務に適合させられます。

現場の社員が開発するときの管理

現場の社員がアプリを開発し始めたら、情シスは禁止せずに、開発してよい範囲とアプリの管理台帳を決定します。
禁止しても表計算ファイルや個人契約のツールに移行し、情シスが把握しないシャドーITになるだけです。

決定する内容は製品や会社の規模で変化します。
たとえば顧客の個人情報や会計データを対象とするアプリは申請を必須にし、アプリごとに開発した人と引き継ぐ人を台帳に記録します。
部署内で数人が利用するアプリまで1件ずつ審査すると現場の社員が利用しなくなるので、管理の手間は対象とするデータと利用者の範囲が広いアプリに集中させます。

管理を決定せずに利用を拡大すると次の障害が発生しやすいです。

• 開発した人個人のアカウントで他のシステムに接続したアプリでは、利用者全員がその人の権限でデータを閲覧できる。
  市民開発のセキュリティ上の主要なリスクの1つに挙げられている
• 本番で利用しているアプリを直接修正すると、項目の削除で入力済みの値が消失し、計算式の変更で過去のデータまで再計算される
• 設計の文書がなく、開発した本人しか中身を理解できないアプリは、誰も修正や廃止を決められず放置される

開発する社員の時間が本来の業務から割かれ、費用として把握しにくい点も考慮しておきます。

料金の伸び方

多くの製品は利用者1人あたりの月額で課金されます。
2026年10月時点で、kintoneのスタンダードコースは1人月額1,800円で、10人から契約します。
アプリを閲覧するだけの人にも利用者の契約を求める製品があり、Power Appsも本番でアプリを利用する人ごとに有料の契約が必要になります。
部署で試行した段階では安価でも、全社に拡大すると費用が人数分増加します。

開発会社が開発したシステムの保守費とインフラ費は、利用者が増加してもほぼ比例しません。
ローコード・ノーコードは利用者数に比例する費用が使い続ける限りかかります。

利用料のほかに、次の点が費用と継続性に影響します。

• 呼び出し回数の上限: 他のシステムとの連携や自動処理の回数に1日あたりの上限がある。
  2026年10月時点でkintoneのスタンダードコースは1アプリ1日1万回、Power Platformは有料の利用者1人あたり24時間で4万回です。
  連携が増加すると上位の契約や追加の枠が必要になる
• 料金体系の変更: 提供元の判断で変更される。
  MicrosoftはPower Appsのアプリ単位の契約を、2026年1月2日から新規の顧客には販売しなくなった。
  安価な契約形態を前提に全社へ拡大すると、見直しの影響範囲が大きい
• 提供元の撤退: 製品そのものが終了することもある。
  Googleは自社のローコード製品App Makerを2021年1月に終了した。
  データは出力できても、画面や業務のルールは別の製品か開発で再構築することになる

よくある誤解

ローコード・ノーコードを導入すればエンジニアがいなくても内製できる

画面や項目の作成は現場の社員でもできます。
ただし権限の設計、他システムとの連携、データの構造を決定する作業には技術の判断が必要になります。
現場の作り手を支える技術者か、相談できる窓口がないまま広げると、権限の設計や連携の不備が修正されないまま蓄積し、数年後に誰も修正できないアプリが残存します。

開発会社にローコードで開発してもらえばスクラッチ開発より必ず安価になる

最初の開発費は減少しやすいが、基盤の利用料は使い続ける限りかかり、製品の制約に業務を適合させる手間も発生します。
数年分の利用料と保守費を合計した総額で比較する必要があります。

生成AIでプログラムを書けるようになったのでローコード・ノーコードは不要になる

生成AIで開発する手段が増加しても、開発したものの保守、権限の管理、稼働させる環境の用意は残存します。
ローコード・ノーコードではこれらを提供元が引き受けます。
現場の社員が自ら開発するなら管理の仕組みを備えた製品のほうがシャドーITを抑制しやすいです。