kintoneアプリが100個超えたら危険？ノーコードの落とし穴と対策

「ITの民主化」という言葉が、ここ数年で企業現場に定着した。kintone、Power Apps、Bubble——プログラミング知識がなくても、現場担当者が自分でアプリを作れる時代になった。市場規模は2025年度に4,085億円に達する見込みであり（出典：デロイト トーマツ ミック経済研究所「ローコード/ノーコードプラットフォームソリューション市場動向 2025年度版」）、勢いは衰えていない。

しかし、現場を回ってみると別の景色が見える。「kintoneで作ったアプリが100個以上あるが、誰も全体を把握していない」「担当者が退職したら誰も触れないシステムが残った」「Power Automateのフローが複雑になりすぎて、もはや改修できない」。こうした声は、規模の大小を問わず増えている。

本記事では、ノーコード・ローコードの限界と課題を正直に整理する。導入を止めろという話ではない。使い方を誤ると、解決のつもりが問題の種になるという現実を、具体的なリスクとともに解説する。

市場の急拡大が生み出す「管理の空白」

現場主導が加速する構造的理由

ノーコード・ローコード市場の拡大は、IT部門のリソース不足という構造問題と表裏一体だ。IPA「DX動向2024」では、DX推進の最大課題として「人材確保」が57.5%と断トツで挙げられている。IT部門に依頼しても半年待ち、という状況が多くの企業で常態化している。

その空白を埋めたのが、現場担当者によるノーコード・ローコード活用だ。業務を一番わかっている人間が、自分でツールを作る。スピードが上がり、コストも下がる。初期段階では確かに機能する。

問題は、この動きが組織横断的に、かつ管理なしで進んだときに起きる。

「野良アプリ」の乱立という現実

シャドウITとは、IT部門の関与・承認なしに現場が導入・運用するITツールやシステムを指す。ノーコード・ローコードはこのシャドウITを大量生産する構造を持っている。

問題の本質は数ではない。「誰が何のために作ったか、IT部門が把握していない」という事実にある。NECソリューションイノベータの指摘によれば、統制されていない野良アプリの乱立は「業務プロセスの標準化を妨げ、ガバナンス上の重大なリスク」になる（出典：NECソリューションイノベータ「ノーコード・ローコード開発の前に」）。

典型的な被害パターンを挙げる。

• 複数部門が類似の目的でそれぞれkintoneアプリを作り、同じデータが3か所に分散している
• Power Automateのフローが誰かの個人アカウントに紐づいており、その人が退職したらフローが止まった
• Bubbleで作った受発注管理ツールが本番稼働しているが、どの部門の管轄か不明確

これらはいずれも「便利なツールを使った」結果であり、悪意のある行動ではない。しかし組織としての実害は同等だ。

ノーコード・ローコードの技術的限界

複雑な業務ロジックへの対応

ノーコードツールが得意とするのは、定型業務の効率化だ。承認フロー、データ入力、通知自動化。これらは確かに速く作れる。

問題は業務が複雑化したときだ。

Bubbleを例に取ると、要素（エレメント）が増えるほどページ読み込み時間が増加する。リレーション構造が深くなると表示速度が低下し、実務に耐えられないケースが報告されている（出典：ノーコード総合研究所「Bubbleの制限事項：開発者が知っておくべき落とし穴と対策」）。大量データ処理、複雑な条件分岐、外部API連携が複数絡む要件では、フルスクラッチ開発に劣ることが多い。

kintoneも同様だ。Qiitaの実務報告では「複雑な分岐が必要な業務ではkintoneの限界を感じた」という声が複数記録されている。複数アプリ間のデータ参照が増えると、カスタマイズJavaScriptに依存せざるを得なくなり、もはやノーコードとは言えない状態になる。

非機能要件への対応不足

業務ツールとして使い始めると、必ず問われるのが非機能要件だ。可用性（システム停止時間の許容範囲）、拡張性（ユーザー数・データ量の増加への対応）、セキュリティ（アクセス制御・暗号化）。

ノーコードプラットフォームは、これらのコントロールをプラットフォーム側に委ねる設計だ。裏を返せば、利用者はインフラを制御できない。SLAの保証内容がプラットフォームの利用規約に依存し、障害時の対応手段が限られる。

NRIセキュアの分析では、ローコード・ノーコード開発基盤における主要なセキュリティリスクとして、権限昇格・データ漏洩・不十分な暗号化の3点が挙げられている（出典：NRIセキュア「ローコード／ノーコード開発基盤のセキュリティの落とし穴」）。GUIで簡単にアクセス制御を設定できる分、設定ミスによる意図しない情報公開のリスクも高い。

プラットフォーム依存が生む中長期リスク

ベンダーロックインの構造

ノーコード・ローコードで構築したシステムは、特定プラットフォームに強く依存する。kintoneならサイボウズ、Power AppsならMicrosoft、BubbleならBubble社のサービスが存続し、かつ料金体系が許容範囲である前提でのみ動く。

これはベンダーロックインの典型だ。kintoneの場合、ユーザー数が増えるにつれてライセンスコストが線形に上がる。中堅企業が全社展開すると、年間コストが数百万円規模になることも珍しくない。「作り直したいが、kintoneの仕様に合わせた業務フローになってしまっていて、移行コストが見えない」という状況になると、プラットフォームへの依存度はさらに高まる。

プラットフォームのAPIや機能が変更・廃止された場合、対応コストを利用者側が負う。2024年にPower Platform周辺で発生したコネクタ変更への対応は、多くの企業の現場担当者を混乱させた事例として記憶されている。

「2025年の崖」と同じ構造が再生産される

2026年のシステム刷新トレンドを論じた記事でも触れたように、「2025年の崖」の本質は保守できないシステムの蓄積だ。ノーコード・ローコードは、その問題を高速で再生産しうる。

スピードが上がる分、問題が積み重なるスピードも上がる。

引き継ぎ問題とブラックボックス化

ノーコード・ローコード開発が生む最も深刻な中長期問題が、引き継ぎとブラックボックス化だ。

従来のシステム開発には、設計書・コード・テスト仕様書というドキュメント群が伴う。煩雑ではあるが、後任者がシステムを理解するための痕跡が残る。

ノーコード・ローコードでは、この痕跡が残りにくい。GUIの画面設定とワークフロー定義だけで業務システムが動いており、「なぜこの設計にしたのか」という判断根拠がどこにも記録されていない。

ダイヤモンド社の分析では「ドキュメントが無いので担当がいなくなった瞬間に継承が出来なくなり負の遺産になる問題が現場の社会問題になっている」と指摘されている（出典：Diamond「失敗しないノーコード・ローコード活用、属人化やロックインの功罪」）。

現場では「あのアプリはAさんが作ったから、Aさんがいないと誰も直せない」という状況が当たり前になっている企業も多い。これは属人化の問題であるが、本質的にはドキュメントレスな開発プロセスに起因する。

部門最適と全体最適のトレードオフ

ノーコード・ローコードが加速させる問題のひとつが、部門最適の断片化だ。

各部門が自分のKPIを追求してアプリを作るため、組織全体では類似した目的のアプリが乱立する。コスト面では、複数部門が類似ツールを個別契約し、全社で無駄なコストが発生する。データ面では、同じ情報が複数システムに分散し、どれが正が不明になる。

「ノーコード/ローコードを無法地帯として放置するのではなく、管理されたイノベーションの場として位置づける」ことが重要だとXIMIXの分析は指摘する（出典：XIMIX「なぜノーコード/ローコードツールの導入で管理負担を増やしてしまうのか」）。その具体策として、利用ルール、アクセスしてよいデータの範囲、品質担保の基準、問題発生時の責任分界点を「最低限のガードレール」として設けることが挙げられている。

ノーコード・ローコードを正しく使うための判断基準

これらの限界を踏まえたうえで、ノーコード・ローコードが適合するケースと、適合しないケースを整理する。

向いているケース

• スモールスタートの業務改善：承認フロー、在庫確認、日報管理など、業務スコープが明確で変化が少ないもの
• プロトタイプ検証：本格開発の前に要件を固めるための試作
• データ収集・可視化：Power BIやkintoneのグラフ機能で現場データを見える化する

向いていないケース

• 基幹業務システム：販売管理・生産管理・会計など、全社データが連携し可用性が求められるもの
• 複雑な業務ロジックを含む処理：例外条件が多く、フローが複雑に分岐するもの
• 長期運用・引き継ぎが前提のシステム：担当者交代を経ても安定稼働が必要なもの

この判断を現場担当者が単独で行うのは難しい。ITアーキテクチャ全体の視点と、現行システムの依存関係の把握が必要になるからだ。

既存システムとの統合で起きる問題

ノーコード・ローコードで作ったアプリが本格稼働すると、既存の基幹システムとの連携が必要になるケースが出てくる。ここで生じる問題は、単純ではない。

kintoneとERPシステムを連携しようとした場合、kintone側のAPIと既存ERPのインターフェース仕様を合わせる作業が発生する。これはノーコードの範疇を超えており、エンジニアリングが必要になる。さらに、既存システム側のデータ構造が不明確・不整合な場合、連携作業は予想外に複雑化する。

NECソリューションイノベータが指摘するように、ノーコード・ローコード開発の前段として「データモデルの確立」が不可欠だ。データモデルが確立されていない状態でアプリを量産すると、「開発途上で倒壊するか、まともに使えないシロモノとして完成する」（出典：NECソリューションイノベータ「ノーコード・ローコード開発の前にデータモデルを確立せよ」）。

既存システムの構造が把握できていないと、ノーコード・ローコードによる内製化は機能しない。

対策の方向性：ガバナンスと構造把握が鍵

では、どう対処すればよいか。現実的な対策は3層で考える。

第1層：ガバナンスルールの整備

まず「何を作ってよいか」のルールを決める。対象データ、利用できるプラットフォーム、責任者の設定、ドキュメントの最低基準。これを情シスが主導して設定する。ルールがなければ現場は空白を埋めようとして動くが、その動きにブレーキをかける仕組みがない。

第2層：既存システムとの依存関係の可視化

ノーコード・ローコードで新しいアプリを追加する前に、既存システムの全体像を把握する。どのシステムがどのデータを持ち、どのシステムと連携しているか。この地図なしに動くと、連携設計が後から破綻する。

システム棚卸しと構造把握の方法論を詳しく解説した記事では、この可視化プロセスを具体的に整理している。

第3層：判断基準の確立

ノーコード・ローコードで作るか、エンジニアリングが必要か。この判断を都度できる基準を整備する。業務の複雑度、データの重要度、運用年数の想定、引き継ぎ想定人数——これらを評価するシンプルな判断フレームがあれば、現場担当者が誤った方向に進むリスクを下げられる。

まとめ：「速く作れる」と「安定して動く」は別の話

ノーコード・ローコードは確かに生産性を上げる。現場担当者が自律的に業務改善できる環境を作るという意味では、意義のある流れだ。

しかし「速く作れる」と「安定して長く動く」は別の話だ。この二つを混同したまま展開すると、3年後に「誰が作ったかわからないアプリが100個」「基幹データが3か所に分散」「担当者が退職して動かせない自動化フロー」という状況になる。

問題の根本は、現行システムの構造が把握できていないことにある。既存の基幹システムがどう動いているかを理解していない状態で、その周辺にノーコード・ローコードのアプリを追加していくのは、地図なしに建て増しを繰り返すようなものだ。

既存システムの構造を正確に把握したうえで、ノーコード・ローコードをどこに位置づけるかを決める。この順番が逆になっているケースが、現場では多すぎる。

自社のシステム全体像が今どうなっているか、まず現状を把握することから始めたい方は、SysDockの無料ヒアリングをご活用ください。AIマルチエージェントによるレガシーシステム構造解析で、既存システムの依存関係と課題を可視化します。まずは現状把握から。sysdock.genbacompass.com

関連ツール比較

参考文献

• デロイト トーマツ ミック経済研究所「ローコード/ノーコードプラットフォームソリューション市場動向 2025年度版」
• NECソリューションイノベータ「ノーコード・ローコード開発の前に 情シスは「データモデル」を確立せよ」
• NRIセキュア「ローコード／ノーコード開発基盤のセキュリティの落とし穴」
• XIMIX「なぜノーコード/ローコードツールの導入で管理負担を増やしてしまうのか」
• XIMIX「シャドーIT・野良アプリとは？DX推進を阻むリスクと対策」
• Diamond「失敗しないノーコード・ローコード活用、属人化やロックインの功罪」
• ノーコード総合研究所「Bubbleの制限事項：開発者が知っておくべき落とし穴と対策」
• イノベトピア「ノーコード/ローコード開発の落とし穴：民主化されたアプリ開発がもたらすセキュリティリスク」