本文へ移動

ガイドAIにより執筆

ノーコード・ローコードとは 違い・向き不向き・セキュリティの注意点

ノーコードとローコードの違いを、IPAの用語集とセキュリティガイドにそって整理する。スクラッチ開発との使い分け、自治体の導入例、運用で気をつける点、選ぶ手順まで。

プログラミングの専門知識がなくても、業務のアプリやウェブサイトを作れるツールが広がっている。こうしたツールは「ノーコード」「ローコード」と呼ばれ、現場の担当者が自分で業務を改善する手段として、会社だけでなく自治体でも使われている。ここでは二つの言葉の違い、スクラッチ開発との使い分け、運用で気をつけることを整理する。

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

IPA(情報処理推進機構)の用語集は、次のように説明している。

  • ノーコード開発: プログラムコードを書くことなくソフトウェア開発をすること。プログラムのコード部品を組み合わせて開発する
  • ローコード開発: 最小限のプログラムコードを書くことでソフトウェア開発をすること。既存のコード部品の組み合わせと、作成した最小限のコードで開発する

IPAの産業サイバーセキュリティセンター(ICSCoE)の第8期卒業プロジェクトとして公開されたセキュリティガイド(2025年)も、ローコード・ノーコードツールを、プログラミングの専門知識がなくても業務アプリケーションを構築できる開発ツールとしている。ローコードは最小限のプログラミング知識で、視覚的な操作を中心に開発でき、コードを書く余地があるためカスタマイズでき、一定の拡張性が保たれる。ノーコードは一切コードを書かずに開発でき、多くはテンプレートやUI部品を配置するだけで作れるため、ITのスキルのない業務担当者でも比較的容易に使える、と書かれている。

違いを比べる

比べる点 ノーコード ローコード スクラッチ開発
コードの記述 書かない 最小限 全面的に書く
作る人 業務の担当者 業務の担当者と、プログラミングの知識がある人 開発者
拡張性 ツールの機能の範囲 コードで拡張できる 制限が少ない
向く規模 小さな業務、部門内の業務 中規模の業務、他システムとの連携 大規模、独自性が高い業務
保守 ツールの提供者が基盤を保守し、アプリは作った人が管理 同左(コード部分は作った人が保守) 全て自社または開発会社

スクラッチ開発とはと並べて検討する場面が多い。画面で組み立てられる範囲で足りるなら、ノーコードやローコードのほうが短い期間で始められる。

大全の掲載サービスにも、この種のツールがある。kintoneは、プログラミングなしで顧客・案件管理、日報、申請などの業務アプリを作れるクラウドサービスである。ウェブサイトでは、STUDIOがコードを書かずにデザインから公開、運用までを行えるプラットフォーム、WixがAIによる自動生成とドラッグ操作の編集に対応している。業務の自動化では、Zapierが画面上の設定でアプリをつなぎ、n8nはビジュアルなエディタで流れを組み、必要ならコードも書ける。Difyはワークフローやエージェントを画面で組み立てて生成AIアプリを作る基盤である。最近は文章で指示するだけでアプリを作るmonday vibeやFigma Makeも出ている。

メリットと注意点

メリット

  • 業務を知っている人が、自分で作って直せる。開発会社に依頼する時間とやり取りが減る
  • 小さな業務から始めて、使いながら直せる
  • 総務省の自治体DX事例集で、愛知県は、職員に専門的な知識がない場合に開発を依頼すると膨大な費用と時間がかかっていたことを課題とし、ノーコード・ローコードツールを2022年度に20業務で試行導入した。試行した20業務で、年間換算の削減時間は1,230時間という結果を示している。2023年度から本格導入している

注意点

IPAのセキュリティガイドは、ツール利用で気をつける点を「8か条」にまとめている。

  1. ログイン情報の管理(共有アカウントを避け、多要素認証にする)
  2. アプリへのアクセス権の設定
  3. データベースへのアクセス権(CSV出力を誰でもできる設定にしない)
  4. 追加プラグインの安全性
  5. 外部連携(API)の認証と暗号化
  6. ブラックボックス化(作った人しか分からないアプリが増えることを防ぐ)
  7. ログの取得
  8. ツール独自の仕様の理解

特に6番は運用の問題である。ガイドは、作成者しか設計が分からないアプリが乱立すると、内部処理や脆弱性の把握が難しくなり、放置されたアプリに外部から不正にアクセスされる危険があると指摘している。機能や処理の内容をドキュメントにし、会社のルールやIT部門と連携してアクセス権や保存先を管理することが対策として挙げられている。

そのほかの点として、ツールの機能を超える要望には応えにくい。別のツールに移るときには、作ったアプリをそのまま持ち出せないことが多いため、データの書き出し方法を先に確認する。

向いている場面・向いていない場面

  • 向いている: 申請・日報・案件管理のように、入力と一覧と承認が中心の業務。部門ごとに違う細かな業務。まず試して改善したい場面
  • 向いていない: 大量のデータの高速な処理、独自の計算や複雑な画面、厳しい法令や基準に沿った基幹業務。長い期間の保守を前提とした大規模なシステム

選ぶとき・進めるときの手順

  1. 対象の業務を決める。最初は、関係者が少なく、失敗の影響が小さい業務にする
  2. 作る人と、管理する人(アクセス権やアカウントを見る人)を分ける
  3. 候補のツールで、料金の形、対応する端末、データの書き出し、連携できるサービスを確認する(大全の各サービスのページ)
  4. 試作して、現場の担当者に使ってもらう
  5. IPAのセキュリティガイドのチェックリストで、公開範囲、権限、ログを点検する
  6. アプリの一覧と作成者を記録し、年に1回程度、使われていないアプリとアクセス権を見直す

よくある質問

ノーコードとローコードのどちらを選ぶか

画面の操作だけで足りるならノーコード、他のシステムとの連携や独自の処理があり、コードを書ける人がいるならローコードが候補になる。同じ製品が両方の使い方に対応している場合もある。

市民開発とは何か

現場の業務担当者が、ノーコードやローコードのツールで自分たちの業務アプリを作ることを指す言葉として使われる。公的な定義文は確認できなかったため、ここでは一般的な使い方として説明している。

作ったアプリの責任は誰にあるか

作った部門と、ツールを管理するIT部門で分担を決めておく。IPAのガイドは、IT部門やセキュリティ部門と連携することを勧めている。

スクラッチ開発に移ることはあるか

ある。業務が大きくなり、ツールの範囲を超えたときである。その場合に備えて、データの構造と処理の内容を記録しておく。

次にやること

  • 手作業で表計算ソフトに入力している業務から、一つを選ぶ
  • 候補のツールを大全で絞り、無料の試用で試作する
  • 作る前に、アクセス権とアカウントの管理のルールを決める

出典

この記事は公式の発表をもとに AI が執筆し、サービス・システム大全 編集部が確認しています。誤りに気づいたときは 訂正の窓口 からお知らせください。