定義──記述量を減らす「ロー」と、書かせない「ノー」

ローコード開発は、プログラムコードの記述を最小限にし、視覚的なモデリングや設定でアプリケーションを構築する開発手法です。ノーコードはさらに進めて、コード記述を前提にせず業務ユーザー自身が構築できることを狙います。両者は連続的で、多くのプラットフォームは「基本はノーコード、複雑な処理は少量のコードで拡張」という中間に位置します。製造業では、作業指示・チェックリスト・実績収集・簡易な品質記録といった現場アプリをこの手法で組む動きが2020年代に急拡大しました。代表格のTulipは2026年1月のシリーズD発表時点で45カ国1,000拠点・43,000アプリ・60,000名の現場作業者という展開実績を公表しています。既存MES側でも、SiemensがローコードのMendixを製品群に組み込むなど、ローコードはMESの周辺機能から中核へと浸透しています。

誤解されやすい点──「開発者不要」にはならない

第一の誤解は「ノーコードなら情報システム部門は不要」というものです。アプリ単体は現場で作れても、マスタ・権限・設備接続・他システム連携といった土台の設計は専門スキルの仕事として残ります。現場主導で数百のアプリが無統制に増えた結果、同じデータを違う定義で集める「Excel地獄のアプリ版」が生まれた事例は珍しくありません。市民開発（citizen development）は、命名規則・マスタ参照・リリース承認のガバナンスとセットで初めて機能します。第二の誤解は「ローコード＝簡易で本番に耐えない」という逆方向の偏見です。ロット追跡や設備接続まで含む本番運用は現実に多数存在します。ただし規制産業では注意が必要で、アプリの変更が容易であることは、変更管理とバリデーションの統制が難しくなることを意味します。GxP環境では「誰でもすぐ直せる」は長所ではなくリスクとして評価されます。

実務でこの用語が出てきたら確認すべきこと

  • 作る人と統制の設計──アプリを作るのは現場か情シスか。命名規則、共通マスタの参照ルール、リリース前レビューの仕組みを先に決めます
  • 土台機能の充足──設備接続、ユーザー管理、監査証跡、多言語対応はプラットフォーム側にあるか。アプリは作れても土台が弱い製品は後で行き詰まります
  • ロックインの評価──作ったアプリは他環境へ持ち出せません。プラットフォーム選定は個別アプリの出来ではなく、ベンダーの継続性と価格体系で判断します
  • 規制対応の変更管理──GxP適用範囲でアプリを使うなら、変更時の影響評価・再検証のフローを運用に組み込めるかを確認します

深く知る

ローコードMESと従来型MESはどちらを選ぶべきですか？

標準プロセスが固まっている量産工場では従来型パッケージ、工程やレイアウトの変化が速い多品種工場・組立工場ではローコード型が向く傾向があります。実際には併用（コアは従来型、現場アプリはローコード）も有力な選択肢です。

内製したアプリの品質は誰が保証するのですか？

自社です。ここがパッケージ購入との最大の違いで、テスト・変更管理・ドキュメントの規律を自社で維持する必要があります。統制の仕組みを作れない組織では、ローコードの俊敏さは負債に変わります。