ノーコードという言葉が日本で語られ始めて数年が経ちました。当初の「誰でもアプリが作れる」という期待は、いまや現場の実感として二極化しています。「小さな業務が劇的に楽になった」という企業と、「作ったものが放置されて負債になった」という企業——この差は、ツールの選定ではなく導入の設計から生まれています。
加えて2025年以降、自然言語からアプリを生成するAI型のツールが実用域に入り、「ノーコード」という言葉が指す範囲そのものが広がりました。従来のノーコード基盤とAI生成型ツールは、できることも制約もまったく異なります。同じ言葉で議論すると、選定を誤ります。
本記事は、ノーコード開発の全体像を1本で把握できるように設計した総論です。定義の整理、できること・できないことの境界、ツールの分類、費用の構造、情シス審査で問われる論点、導入の進め方までを扱います。
目次
両者はしばしば並べて語られますが、境界は製品カタログ上の定義ほど明確ではありません。ノーコードを謳う製品にも計算式やスクリプトの機能があり、ローコード製品にもGUIだけで完結する範囲があります。それでも企業導入の判断には整理が必要なので、代表的な差を並べます。最後の行が実務上いちばん効いてくる違いです。
| ノーコード | ローコード | |
|---|---|---|
| コード記述 | 原則不要 | 一部必要(拡張・複雑な処理) |
| 主な担い手 | 業務部門(非エンジニア) | 情シス・エンジニア |
| 自由度 | プラットフォームの範囲内 | 高い |
| 典型用途 | 定型業務アプリ、フォーム、簡易DB | 基幹連携、複雑な業務ロジック |
| 詰まる場所 | 制約を超える要件が出たとき | エンジニアの確保 |
実務上の違いは「詰まったときにどうなるか」です。ノーコードはプラットフォームの制約を超える要件が出た瞬間に手が止まります。ローコードはコードを書ける人がいれば越えられます。この一点が、長期運用での分岐点になります。
ここが2026年時点で最も混乱している論点です。Lovable、Bolt、v0のようなツールは、ユーザーがコードを書かない点ではノーコードですが、成果物は実際のコードです。
| 従来型ノーコード | AI生成型 | |
|---|---|---|
| 成果物 | プラットフォーム上の設定・構成 | ソースコード |
| 持ち出し | 基本的に不可(ロックイン) | GitHub等へ同期可能 |
| 自由度 | プラットフォームの範囲内 | 制約が少ない |
| 品質の安定 | 高い(画一的) | 指示の質に依存 |
| エンジニアへの引き継ぎ | 困難 | 可能 |
トレードオフは明確です。従来型は「制約と引き換えに品質と保守性が安定する」、AI生成型は「自由度と引き換えに品質が作り手の指示に依存する」。どちらが優れているかではなく、何を重視するかで選びます。
背景は人材の需給です。経済産業省の「IT人材需給に関する調査」(2019年)は2030年時点で最大約79万人のIT人材不足を推計し、「DXレポート」(2018年)は既存システムのブラックボックス化を警告しました。「外注すれば解決する」という前提が成り立ちにくくなったことが、内製手段への注目を押し上げています。
なお、ノーコード/ローコード市場の成長率や利用率については各種の予測が引用されていますが、出典によって数値に幅があります。稟議に使う場合は、引用元の一次資料を確認したうえで用いてください。
ノーコードが力を発揮するのは、業務のかたちがある程度決まっていて、要件を自社で決められる領域です。逆に言えば、他社と同じでよい標準的な処理や、要件が外部要因で決まる領域では、既製品を買ったほうが速く安くなります。具体的には次のような業務が該当します。
共通するのは「業務が定型的で、要件を自社で決められて、扱うデータ量が中程度まで」という条件です。
一方、次の領域では無理に適用しないほうが賢明です。作れないわけではありませんが、作った後の運用で破綻します。とくに可用性の要件は後から設計で足すのが最も高くつくため、着手前に見極める必要があります。
機能一覧を比べても境界は見えません。実務的な判断基準は次の3問です。
個別の製品名で比較を始めると、比較軸が製品ごとにばらついて収拾がつかなくなります。まず系統で分けてから、系統内で製品を比べるほうが速く結論に到達できます。2026年時点では、次の3系統に整理するのが実務的です。
| 系統 | 代表例 | 強み | 制約 |
|---|---|---|---|
| 業務アプリ基盤型 | kintone、Power Apps、Airtable | 定型業務に最適化、権限管理が標準装備、情シス審査を通しやすい | プラットフォームの範囲を超えられない |
| Webアプリ構築型 | Bubble など | 画面と処理の自由度が高い | 学習コストが高い、持ち出しが難しい(Notion等の汎用ツールとの組み合わせ運用も検討余地あり) |
| AI生成型 | Lovable、Bolt、v0 | 自然言語で作れる、コードを保有できる | 品質が指示に依存、権限設計は自社責任 |
比較検討でよくある誤りは、この3系統を同じ土俵で価格比較することです。「kintoneとLovableはどちらが安いか」という問いは、行き先を決めずに移動手段の価格を比べるようなものです。
まず既存基盤で作れないかを検証するのが原則です。Microsoft 365やkintoneをすでに全社導入しているなら、追加コストはほぼゼロで、情シスの審査も通っています。
それでも別のツールを検討する価値があるのは、①既存基盤の制約で作れない画面がある、②非エンジニアが自力で完成まで到達できない、③外部公開が必要——のいずれかに該当するときです。「新しいから使う」ではなく「既存で詰まったから使う」という順序を守ってください。この順序が守れる企業は、情シスとの関係も良好に保てます。
ノーコードツールの費用を比較するとき、月額料金の数字だけを並べても意味がありません。何に対して課金されるかが製品ごとに違うため、利用規模が変わると順位が入れ替わるからです。自社が将来どの方向に拡大するのかを踏まえて、課金の軸を確認してください。
| 課金モデル | 費用が増える要因 | 注意点 |
|---|---|---|
| ユーザー課金 | 使う人数 | 全社展開でコストが線形に増える |
| 従量課金 | 使った量(実行回数・クレジット) | 成功するほど費用が増える |
| 容量・アプリ数課金 | データ量・作成数 | 放置アプリが費用を圧迫する |
全社への横展開を想定するなら、ユーザー課金モデルは人数×単価で総額が決まる点を最初に試算してください。100名規模になると、月額単価の小さな差が年間で大きな金額差になります。
ライセンス費用は見積もりやすいため、比較検討では必ず計上されます。問題は、それ以外の費用が請求書として届かないことです。社内工数として発生するため予算に現れず、結果として「安く導入したはずが担当者の負担が増えた」という状態を生みます。次の3つは必ず金額に換算してください。
3番目は導入時にはゼロに見えるため、ほぼ確実に検討から漏れます。「このツールをやめるとき、何が残るか」を選定時に確認してください。
審査の論点は概ね4つです。
| 問われること | 準備すべき回答 |
|---|---|
| ベンダーの信頼性 | 認証(SOC 2、ISO 27001等)、データの保存先リージョン、学習利用の有無 |
| アカウント管理 | SSO対応、退職者アカウントの失効手順 |
| 公開範囲の制御 | 誰がアプリを外部公開できるか、社内限定公開の可否 |
| 作ったアプリ自体の安全性 | 権限設計とアクセス制御の点検記録 |
審査が止まるのは常に4つ目です。とくにAI生成型では、データベースのアクセス制御(行レベルセキュリティ)の設定漏れが最頻出のリスクで、設定していなくてもアプリは正常に動くため通常のテストでは発見できません。点検手順は公開前チェックリストにまとめています。OWASP Top 10、IPA「安全なウェブサイトの作り方」、個人データを扱う場合は個人情報保護委員会のガイドラインもあわせて確認してください。
ノーコード導入で失敗する企業の多くは、ツールの選定に時間をかけ、導入後の運用設計を後回しにします。しかし実際に効いてくるのは順序です。以下の5ステップは、いずれも当たり前に見えますが、1番と3番を飛ばす企業が非常に多いのが実情です。この2つを飛ばすと、後から取り返すのに数倍の労力がかかります。
順序が重要です。ツールを配ってから統制しようとすると、必ず遅れます。市民開発を推進する企業の失敗は、ほぼこの順序ミスから生じています。
推進部門の報告資料で最も多い指標が「作成アプリ数」です。しかしこれは活動量であって成果ではありません。作った数が増えるほど棚卸しの対象が増えるだけ、という状態は珍しくありません。
成果として測るべきは次の3つです。
| 指標 | 測り方 | なぜ有効か |
|---|---|---|
| 旧手段の廃止率 | 置き換え対象だったExcel・紙・メール運用が実際に止まった割合 | 行動が変わった証拠。二重運用のままなら効果はゼロ |
| 作業時間の削減 | 導入前の実測値と比較(推定ではなく計測) | 金額換算でき、稟議に使える |
| 継続利用率 | 導入2週間後・3か月後の自発的な利用 | 導入直後は指示されて使うため、初期の利用率は当てにならない |
とくに「旧手段の廃止率」を推奨します。新しいツールを導入しつつ従来のExcelも残す二重運用は、現場の負担がむしろ増えており、効果がマイナスになっている状態です。ここを直視できるかどうかで、次の投資判断の質が変わります。
1件目の小さなアプリで実測値を取ることが、2件目以降の予算を取る唯一の方法です。「月80時間の作業が15時間になった」という実数があれば、横展開の議論は金額の話になります。逆に、感覚的な「便利になった」で終わらせると、翌年度の予算計上時に説明できません。
導入前の測定を忘れる企業が非常に多い領域です。作り始める前に、現状の作業時間を計測してください。後から遡って測ることはできません。
ここまでの内容を、実際に起きている失敗の形で整理します。技術的な難しさが原因のものは一つもありません。すべて導入の設計と運用ルールに起因する失敗です。ツールを選ぶ前に、この一覧に自社が当てはまらないかを確認してください。
| 失敗 | 兆候 | 対処 |
|---|---|---|
| 既存ライセンスの検討漏れ | Microsoft 365があるのに新規契約している | ステップ1を必須工程にする |
| 属人業務をそのままアプリ化 | 担当者以外が使えないアプリができる | 先に業務手順を標準化する |
| 統制なしの横展開 | 誰が作ったか不明なアプリが増殖 | 棚卸しルールを配布前に決める |
| 現場を巻き込まない | 完成後に「使いにくい」と言われ放置 | 企画段階で現場の1人を巻き込む |
| 運用費を予算化していない | 翌年度に予算がなく停止 | 恒久予算として計上する |
| 移行できないツールへの依存 | 乗り換え時に全面作り直し | 選定時に「やめるとき何が残るか」を確認 |
4番目は数字に現れないため軽視されますが、実際には最も投資を無駄にします。IPA「DX白書」や総務省「情報通信白書」でも、推進部門と現場の乖離は繰り返し課題として挙げられています。企画段階で現場の1人を当事者にできているかが、定着率をほぼ決めます。
最後に、選定時に確認すべき項目をまとめます。機能比較表は各社が用意していますが、機能の有無より重要なのは、費用の増え方と撤退可能性です。とくに8番は、導入時にはゼロに見えて後から最も高くつく項目であり、ベンダーの提案書には決して書かれていません。
| # | 確認項目 |
|---|---|
| 1 | 既存の全社ライセンスで代替できないか検証したか |
| 2 | 課金モデルは何か(ユーザー課金/従量/容量)。全社展開時の総額を試算したか |
| 3 | SSOに対応しているか。どのプランからか |
| 4 | 社内限定公開ができるか |
| 5 | データの保存先リージョンはどこか |
| 6 | 入力データが学習に使われない設定・契約か |
| 7 | 権限管理の粒度は要件を満たすか |
| 8 | やめるとき、データとロジックを持ち出せるか |
| 9 | 運用費(月額)の内訳を把握しているか |
| 10 | 誰が保守し、いつ棚卸しするかを決めたか |
株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして100社以上の支援実績を持ち、Lovableの日本公式パートナーとしてノーコード/AI生成型ツールによる内製化をご支援しています。「どのツールを選ぶか」より先に「何を内製し、何を作らないか」からご相談ください。CRMとの連携設計や、契約形態の考え方も含めて伴走します。
ユーザーがコードを書かない点ではノーコードですが、成果物は実際のソースコードである点が従来型と決定的に違います。GitHub等へ持ち出せるためロックインが小さい一方、品質が指示の質に依存し、権限設計は自社責任になります。
まず既存基盤で作れないか検証してください。追加コストがほぼゼロで、情シス審査も通っています。「既存で詰まったから使う」という順序を守ると、社内調整もスムーズです。
社内向けの定型業務アプリなら可能です。ただし外部公開や機密データを扱う場合は、権限設計とセキュリティ点検を検証できる人のレビューが必須です。
ベンダーの認証状況より、「誰が作って、誰が保守し、いつ止めるのか」が説明できていないケースが大半です。公開フロー・棚卸しルール・権限管理の3点を先に文書化すると審査が速く進みます。
従来型ノーコードは設定や構成がプラットフォーム内に閉じるため、移行は実質的な作り直しになります。AI生成型はコードを持ち出せるため移行コストが低くなります。選定時に必ず確認してください。
棚卸しルールを配布前に決めてください。誰が保守し、何か月使われなければ停止するか。配ってから統制しようとすると必ず遅れます。
社内限定・読み取り中心の小さなアプリです。外部公開を伴わずリスクが低く、作業時間の削減という形で効果が数値化できるため、次の投資の根拠になります。
企画段階で現場の1人を当事者として巻き込むことです。完成後に説明会を開くより効果があります。また成功指標を「導入したか」ではなく「旧手段(Excel等)を廃止できたか」に置いてください。
しません。属人的な業務をそのままアプリ化すると、属人性がシステムに固定化されます。先に業務手順を標準化し、担当者が変わっても回る形にしてからアプリ化してください。