業務アプリはノーコードか開発か｜判断5軸と3年総額【2026】

業務アプリを用意するとき、最初に決めるべきなのは「どのツールを使うか」ではなく「ノーコードで組むか、開発（スクラッチ）で作るか」です。ここを外すと、あとから乗り換えるコストが本体より高くつきます。

結論から書きます。3か月以内に動かしたい・業務のやり方が世間の標準から大きく外れていない・使う人が数十人規模なら、まずノーコード。その仕組み自体が競争力の源泉である・社外のお客様に提供する・使う人が数百人を超えるなら、開発です。判断が割れるのはこの中間で、そこを5つの軸で機械的に切り分けます。

まず「どちらでも作れる」ことを前提にする

受注管理でも顧客管理でも、いまはノーコードでも開発でも一応は作れます。だから「できるかどうか」で選ぶと決まりません。実務で効くのは「3年後にどちらが安く、どちらが動かしやすいか」という問いです。

ノーコードは初期費用が小さく、月額が人数分かかり続けます。開発は初期費用が大きく、その後は保守費だけになります。つまり使う人数と年数が増えるほど、損益分岐は開発側に傾くという構造があります。まずここを数字で押さえます。

軸1：ユーザー数と課金構造（損益分岐はどこか）

代表的なノーコード基盤の公式価格は次のとおりです（いずれも税抜・2026年8月時点）。

この数字で3年分を試算すると、判断はかなりはっきりします。kintoneスタンダードを50人で使う場合、月90,000円・年108万円・3年で324万円です。100人なら3年で648万円になります。ここに、初期設定や外部支援の費用が乗ります。

一方、同等の範囲を開発で作るなら初期に数百万円かかるものの、その後は保守費が中心です。「人数×年数」がある水準を超えると開発のほうが安くなるため、最初に「3年後、何人がこれを使っているか」を見積もってください。逆に、使うのが5人・2年で見直す前提なら、迷わずノーコードです。

ライセンス費は人数に比例するので、「閲覧しかしない人」を数に入れない設計も効きます。集計結果だけを別の場所に出す、といった逃げ道を最初から考えておくと総額が変わります。費用の考え方は脱エクセルの費用相場と判断軸でも整理しています。

軸2：業務の標準度（世間と同じやり方か）

ノーコードが得意なのは「入力して、承認して、一覧で見る」型の標準的な業務です。日報、経費申請、案件管理、簡易な在庫管理などはここに入ります。

逆に苦手なのは、その会社だけの計算ロジックや、業界特有の帳票が中心にある業務です。ノーコードでも作れはしますが、標準機能から外れた部分をプラグインや外部連携で埋めていくうちに、結果として開発より複雑で壊れやすい構成になることがあります。実務でよく見るのは「9割は標準機能、残り1割の作り込みが全体の工数の7割」という状態です。

判断の目安として、「この業務のやり方は、同業他社とだいたい同じか」と自問してください。同じなら標準機能に寄せられます。「うちは違う」がやり方の細部にまで及ぶなら、その違いが競争力なのか、単に整理されていないだけなのかを先に切り分けます。後者なら、業務側を標準に寄せるほうが安く済みます。

軸3：データの持ち方と外部連携

見落とされやすいのがデータの置き場所です。ノーコード基盤では、データはその基盤の中に入ります。会計・販売管理・自社サイトなど外部と頻繁にデータをやり取りするなら、API連携が使えるプランかどうかが実質的な必須条件になります（kintoneであればスタンダードコース以上）。

ここを軽く見ると、「ライトコースで契約したあとに連携が必要になり、全ユーザー分の単価が上がる」という形で費用が跳ねます。連携要件は最初に洗い出してください。

私たちも、ノーコードで足りる範囲はノーコードで組み、足りない部分だけを開発でつなぐ形をよく取ります。記事の途中で恐縮ですが、この切り分け自体が難しいというご相談も多いので、よろしければ合わせてご覧いただけたら嬉しいです。

軸4：変更頻度と、社内で触れる人がいるか

ノーコード最大の利点は、業務側の人が自分で直せることです。項目を1つ増やすのに見積もりと発注が要らない、という速度は数字に出にくいものの効きます。

ただしこれは「社内に触れる人が実在すること」が前提です。担当者が1人だけで、その人が異動したら誰も分からない、という状態はノーコードでも起こります。実務で多い失敗は、ノーコードを選んだのに結局すべて外部に依頼していて、開発と同じ発注リードタイムを払っているケースです。

判断としては、「月に1回以上、項目や画面を変えたくなるか」を見てください。変更が頻繁なら、社内担当を1人立てたうえでノーコード。年に数回しか変えないなら、この軸は決め手になりません。誰が作り誰が保守するかという論点は、社内AIは内製か外注かの判断軸と同じ構造です。

軸5：出口（乗り換えコストをいくらと見るか）

いちばん軽視されるのがここです。ノーコード基盤は、データを出すことはできても、画面・権限・ワークフローといった「作り込んだもの」は持ち出せません。乗り換えは事実上の作り直しになります。

だからこそ、ノーコードを選ぶときは「これは○年で作り直す前提」と決めて始めるのが健全です。逆に、10年単位で使う基幹に近い仕組みなら、最初から開発を検討する価値があります。

もうひとつ、開発側にも出口の問題があります。作った会社しか触れない状態になると、乗り換えではなく依存が起きます。ソースコードの所有・ドキュメントの納品・第三者が引き継げる技術構成の3点を、契約前に必ず確認してください。

早見表：条件からどちらかを決める

◎が3つ以上ついた側を選ぶ、くらいの単純さで十分です。迷いが残るなら、ノーコードで3か月動かしてから決めるという順序が最も損が小さくなります。実際に使ってみて出てきた要件は、机上で書いた要件より正確だからです。ノーコードでの具体的な進め方はノーコードで業務アプリを作る方法にまとめています。

この判断でよくある失敗

• 人数の伸びを見ていない：導入時10人でも3年後に80人なら、ライセンス費は8倍になります。試算は現在ではなく3年後の人数で行ってください。
• 「安いほう」で決める：初期費用だけを比べると必ずノーコードが勝ちます。比べるのは3年総額です。
• 作り込みすぎる：ノーコードで標準から外れた作り込みを重ねると、乗り換えも保守もできない塊になります。外れそうになったら、そこは業務側を変えられないか検討します。
• 担当者を決めずに始める：ノーコードの速さは社内担当者の存在で決まります。人を決めずにツールだけ決めると利点が消えます。
• 出口を契約書に書かない：開発を選ぶ場合、ソースコードの所有と引き継ぎ可能性を先に決めておかないと、あとから交渉材料がなくなります。同種の観点は顧客管理システムの費用の考え方でも扱っています。

どちらが正解かは会社ごとに違いますが、「3年後の人数」「業務の標準度」「出口」の3つを先に数字と言葉にしておけば、判断はほぼ自動的に決まります。ツールの比較検討はそのあとで十分です。