ローコード・kintoneで基幹システムは作れるか｜向いている範囲と限界

ローコードやkintoneで基幹システムを作ることは、案件管理・受注の入口・現場の記録など「周辺の業務」なら十分に現実的です。一方で、在庫の引当、締め請求、原価計算、会計仕訳のように、数字が他の業務に連鎖する「芯の業務」まで作り込むと、作る費用より守る手間が重くなりがちです。この記事では、ローコードで基幹システムを作れる範囲と限界の見極め方を、公式の制限値と調査データをもとに、大手コンサルティングファーム出身の専門家の知見を交えて解説します。

ローコード・kintoneで基幹システムは作れるか：結論は「範囲を決めれば作れる」

ローコードとは、プログラムをほとんど書かずに、画面の操作や設定でアプリを作れる開発の方法です。ノーコードは、プログラムを一切書かない前提のものを指すことが多い言葉です。kintone（キントーン）はサイボウズが提供するクラウドサービスで、項目を並べてデータベース型のアプリを作り、一覧・集計・承認の流れ（プロセス管理）を設定できます。

「ローコードで基幹システムは作れるか」への答えは、どこまでを基幹システムと呼ぶかで変わります。基幹システムには、販売・購買・在庫・生産・会計のように、ある業務で入力した数字が別の業務の数字を自動で動かす仕組みが含まれます。受注を登録すれば在庫が引き当てられ、出荷すれば売上と売掛金が立ち、締めで請求書が出て、仕訳が会計に渡る。この連鎖の部分をローコードで一から組むのは、作れなくはないものの、相応の設計と作り込みが必要です。

反対に、案件の進み具合、見積の履歴、現場の作業記録、設備の点検、クレームの対応履歴といった業務は、項目と流れが会社ごとに違い、パッケージでは合わないことが多い領域です。ここはローコードの得意分野です。基幹系と情報系・周辺業務の分け方は基幹システムと業務システムの違いで整理しています。

ローコードが選ばれている背景：JUASの調査から

日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」では、新しい技術の導入状況を聞いた質問で、「ノーコード・ローコード」の「導入済み」が34.0%、「試験導入中・導入準備中」を合わせると47.8%でした（25年度、n=952）。合計値ではRPA、言語系生成AIに次ぐ3位です。調査対象は東証上場企業とそれに準じる企業ですが、ローコードが社内でアプリを作る手段として定着してきたことが分かります。

一方で同じ報告書は、ノーコード・ローコードについて「アプリケーション作成の自由度に制約がある」と書き、コード系生成AIなど新しい道具の登場で導入に「一服感」が出てきているとも考察しています。ローコードは万能ではなく、向いている範囲で使う道具だという見方が広がっています。

JUASの「ソフトウェア・メトリクス調査2026」には、大手運輸サービス業が、販売価格を承認する社内ワークフローシステムの保守終了を機に、ローコード（PaaS）基盤で再構築した事例が載っています。開発コストを約7割に削減し、開発期間9か月で進めた一方、報告書は課題として「採用したソリューションベンダーのロックイン」と「ユーザー単位の課金」によるスケーラビリティの壁を挙げ、全社展開には慎重な姿勢を取ったと記しています。学びとして「ユーザー数が限定された比較的小規模な非基幹システムに有効」「大規模システムや外部連携を伴うシステムへの適用は慎重な評価が必要」とまとめています。

中小企業にとっての意味は、「ローコードを使うかどうか」より、「どの業務に使うか」を先に決めることにあります。大企業でも非基幹のシステムに有効と整理している道具を、在庫や請求の芯に使うなら、それなりの理由と体制が必要です。

業務ごとの判定表：ローコードで作る範囲と、専用の製品に任せる範囲

中小企業がローコードを検討するときは、システム全体を「ローコードにするか、しないか」で考えるより、業務ごとに分けて判定するほうが現実的です。次の表は、判定の目安です。

※判定は一般的な目安です。取引の件数、例外の多さ、社内で改修を担える人の有無で変わります。

判定に迷ったときの3つの質問

表のどこに当てはまるか迷う業務は、次の3つの質問で判断します。2つ以上が「はい」なら、ローコードで一から作るより、専用の製品の標準機能を使うほうが安全です。

1. その数字が間違うと、請求額や支払額が変わるか：変わるなら、計算のルールを製品の標準機能に任せたほうが検証の手間が減ります。
2. 同じ数字を、2つ以上の部署が同時に動かすか：営業が受注で在庫を押さえ、倉庫が出荷で減らす、といった業務です。同時に動く数字は、整合を保つ仕組みが必要です。
3. 法令や制度の変更に合わせて、ルールを直す必要があるか：税率、帳簿の保存、請求書の記載事項などです。製品なら改修が提供されますが、自作なら自社で直します。

たとえば「工事ごとの収支の見える化」は、表示するだけなら1つ目が「いいえ」です。しかし原価の確定まで担わせると1つ目と3つ目が「はい」になります。同じ業務でも、どこまで担わせるかで判定が変わる点に注意します。

表の下の行ほど、入力のミスや仕組みの不具合が、お金の数字に直接響く業務です。ここをローコードで作る場合は、テストの量も、稼働後の保守の手間も、パッケージを使う場合より大きくなると考えておきます。パッケージとスクラッチの違いはERPパッケージとはで、一から作る場合の条件はスクラッチ開発とはで解説しています。

kintoneの制限値と料金を、基幹システムの用途に当てはめる

kintoneで基幹に近い業務を作るかどうかは、公式に公開されている制限値と料金で、ある程度は事前に判断できます。次の表は、サイボウズの公式ヘルプ「制限値一覧」と料金ページに記載された内容から、基幹システムの用途で影響の大きいものを抜き出したものです（2026年11月時点で確認）。

※制限値と料金はサイボウズの公式サイトの記載によります。変更されることがあるため、検討時に最新の内容を確認してください。

移行の場面でも制限値は効きます。現行システムから受注明細を5年分移すとき、年間15万件あれば1ファイル10万行の上限を超えるため、年や半期で分けて読み込む段取りが必要です。過去の明細をどこまで移すかは、件数と使い道から決めます。参照するだけの古い明細は、現行システムから書き出したファイルを保管し、kintoneには直近の分だけ入れる選択もあります。

この表から読み取れるのは、kintoneは件数の面では中小企業の業務量にも十分に耐える一方、明細の多い伝票や外部連携を前提にすると、設計とコースの選び方に条件がつくということです。特に「明細は100行が目安」という点は、受注や出荷の伝票をそのまま1レコードで持とうとすると問題になりやすい部分です。

組み合わせの具体例：パッケージ＋kintoneの役割分担

中小企業でよく現実的になるのは、お金と在庫の芯はパッケージ、周辺はkintoneという組み合わせです。次は、従業員60名・1工場の食品加工業を例にした役割分担です。

この会社でkintoneを使う人が、営業10名、製造の班長と品質管理で15名、管理部門5名の合計30名だとします。スタンダードコースなら、1,800円×30名×12か月で年額64万8,000円（税抜）です。全社員60名に配ると年額129万6,000円になります。閲覧が中心の人でも、ログインして使うなら契約ユーザー数に含めて考えるため、誰に配るかで年額が倍になる計算です。

※説明用の例です。料金はkintoneの公式料金ページに記載の税抜価格をもとに計算しています。パッケージ側の費用や連携の開発費は含みません。

周辺の業務を何で作るかにも、ローコード以外の選択肢があります。3つの作り方の違いを、周辺業務に使う前提で整理すると次のとおりです。

※一般的な傾向をまとめたもので、製品や開発の規模によって異なります。

ポイントは、連携を「受注の確定」と「出荷実績」の2本に絞っていることです。連携の本数が少ないほど、どちらかの仕組みを入れ替えるときの影響も小さく済みます。

販売管理の製品の選び方は販売管理システムとはで、在庫の持ち方と連携の注意点は在庫管理システムの選び方で解説しています。

ローコードで基幹システムを作るときの6つの限界と対策

ローコードで基幹に近い業務を作ると決めた場合でも、事前に知っておけば手を打てる限界があります。どれも「作れない」という限界ではなく、「作ったあとに手間が増える」種類の限界です。稼働から3年、5年たったときの姿を想像しながら読んでください。

1. 作り込みが増えるほど「ローコード」でなくなる

標準機能で足りない部分をJavaScriptやプラグインで補うと、その部分は普通のプログラムと同じ保守が必要になります。作った人が退職すると、誰も直せないアプリが残ります。カスタマイズの一覧と、誰が直せるかを台帳にして管理します。

2. 利用者の人数で年額が増える

ユーザー単位の課金は、少人数で使ううちは安く、全社に広げると年額が積み上がります。JUASの事例でも、この課金体系が全社展開の壁として挙げられていました。5年後の利用人数で年額を計算し、パッケージの費用と比べます。

3. 同じ数字を複数のアプリで持つとずれる

在庫数や受注残を複数のアプリで別々に持つと、どれが正しいか分からなくなります。1つの数字は1つのアプリにだけ持たせ、他のアプリは参照するルールを最初に決めます。

4. 帳票の出力は別の仕組みが必要になりやすい

納品書や請求書を自社の様式で印刷するには、帳票用のプラグインや連携サービスを使うのが一般的です。これらのサービスにも別に利用料がかかることが多く、年額の比較に入れておきます。取引先指定の様式が多い会社は、帳票の数と様式を先に洗い出し、追加の費用を見積もります。

5. アクセス権を細かくするほど、動作の条件が変わる

公式の制限値一覧は、レコード数が多いと動作が遅くなる場合があり、速度はアクセス権、絞り込み条件、フィールド数などで異なると説明しています。「営業は自分の担当先だけ」「拠点ごとに見える範囲を分ける」といったレコード単位のアクセス権を多用する設計は、件数が増えたときの動きを試験環境で確かめておきます。

6. サービスへの依存（ロックイン）

アプリの設計やカスタマイズは、そのサービスの上でしか動きません。将来ほかの仕組みに移すときは、データの書き出しと作り直しが必要です。データをCSVで定期的に書き出す運用や、項目の定義書を残しておく運用が保険になります。ロックインの考え方はベンダーロックインとはで解説しています。

内製で作るか、外部に頼むか：体制の決め方

ローコードの利点は、社内で作って社内で直せることです。ただし、基幹に近い業務を作る場合は、作る人と、決める人と、守る人を分けて考えます。

• 決める人：業務の流れと項目、例外の扱いを決める業務部門の責任者。ここが曖昧だと、作る人の判断でアプリが増えていきます。
• 作る人：社内の担当者が作るか、外部の開発会社に頼むか。在庫や請求のように数字が連鎖する部分は、データの設計に慣れた人が担うほうが安全です。
• 守る人：稼働後の問い合わせ、項目の追加、アクセス権の変更を担う人。異動や退職に備えて2人以上に分けます。

作る部分を外部の開発会社に頼む場合は、次の点を契約前に確認します。

• アプリの設計書を残してくれるか：項目の一覧、アプリ間の関係、プロセス管理の流れ、アクセス権の設定を文書で受け取ります。
• カスタマイズのソースを渡してくれるか：JavaScriptやプラグインの設定を、自社の管理下に置けるかを確認します。
• 標準機能でできることを先に提案してくれるか：何でもJavaScriptで作る会社より、標準機能で足りる部分を見極めてくれる会社のほうが、保守の負担は小さくなります。
• 稼働後の改修の窓口と単価：項目の追加や一覧の変更を頼むときの費用と期間を確認します。

社内に情報システムの担当がいない会社なら、最初のアプリの設計とルールづくりだけを外部に頼み、日々の改善は社内で回す分け方もあります。どの業務をローコードにするかの線引きそのものを、構想の段階で決めておくと、アプリが無秩序に増えるのを防げます。

ローコードで作り始める前のチェックリスト

• ローコードで作る業務と、パッケージ・会計ソフトに任せる業務を一覧で分けている
• 在庫数・受注残・売掛金など、お金と在庫の数字をどのシステムに持つか決めている
• 1伝票あたりの明細行数と、月間の伝票件数を把握している
• 外部連携の相手（会計・倉庫・EDIなど）と、連携に必要な契約コースを確認している
• 5年後の利用人数で年額を計算している
• 標準機能で足りない部分と、JavaScript・プラグインで補う部分を分けている
• カスタマイズを誰が直せるか、台帳で管理する方法を決めている
• 帳票の数と様式を洗い出し、出力の方法を決めている
• データの書き出しと、項目の定義書を残す運用を決めている
• 決める人・作る人・守る人を分け、守る人を2人以上にしている

よくある質問

まとめ

ローコード・kintoneで基幹システムを作れるかどうかは、どの業務まで作るかで決まります。案件管理、現場の記録、問い合わせの履歴のような周辺の業務は得意分野です。在庫の引当、締め請求、原価計算、会計仕訳のように数字が連鎖する業務は、専用の製品に任せ、ローコードとは連携で結ぶほうが、5年後の保守まで含めて負担を抑えやすくなります。公式の制限値と料金を自社の件数と人数に当てはめれば、作り始める前に向き不向きの多くは判断できます。

自社の業務のどこまでをローコードにし、どこをパッケージに任せるべきか迷っている方は、無料診断で現状の業務とシステムを整理し、組み合わせ方をご提案します。