業務システムは買うか作るか｜SaaS・パッケージ・ローコード・専用のWebアプリを、5年の総額と「直せる人」で比べる

業務システムを既製品で買うか、業務に合わせて作るか。パッケージとスクラッチ開発の比較では初期費用の差が目に入りますが、それだけでは決められません。比べるのは、5年間に払う総額と、使い始めてから直せる人がいるかの二つです。SaaSやkintoneのようなローコードの基盤の多くは、1人あたりの月額に人数と月数を掛けて費用が積み上がります。パッケージの導入やスクラッチ開発（業務に合わせて一から作る専用のWebアプリ）は、最初に払う額が大きくなりやすく、そのあとも保守と変更の費用が続きます。どちらが安いかは、使う人数、使う年数、変更の回数で入れ替わるので、自社の数字を入れて比べます。

「直せる人」とは、項目を一つ足す、帳票の形を変える、取引先を増やすといった変更を、誰が、どれだけの時間と費用で引き受けられるかです。東京商工会議所が2024年10〜11月に主に東京23区の中小企業を対象に行った調査では、情報システムの専任の担当者がいる企業は11.7%でした（「中小企業のデジタルシフト・DX実態調査」集計結果（詳細版））。多くの会社では変更を兼任の担当者か社外に頼むことになり、そのたびの費用と待ち時間が、5年の総額を左右します。

この記事では、5年の総額に足す費用、人数で決まる料金の足し方、作った後に続く費用、パッケージに合わせて直す開発の単価、作り方ごとの直す人、生成AIで変わったこと、自社の数字で試算する表を順に説明します。Aurant Technologiesは、既製のツールを業務に合うかで比べて選ぶ支援と、生成AIを使った専用のWebアプリの開発の両方を行っており、どちらかに寄せずに書きました。金額の相場は載せていません。人数と年数と変更の回数で順位が入れ替わるため、自社の数字で出した結果のほうが判断に使えるからです。

既製品が業務に合わないと、足りない所はExcelで補われる

業務に合う既製品が見つからない、という悩みは珍しくありません。東京商工会議所が2026年3〜4月に主に東京23区の中小企業を対象に行った調査（回答1,272社）では、デジタル化の課題として「業務内容に合ったデジタルツール・サービスが見つからない」を挙げた企業が21.4%ありました。「コストが負担できない」（28.3%）、「従業員がITを使いこなせない」（26.5%）、「旗振り役が務まるような人材がいない」（26.0%）に次ぐ4番目の多さです（東京商工会議所「中小企業のデジタルシフト・DX実態調査」集計結果、2026年6月17日）。

合わない既製品を入れると、その差は既製品の外で埋められます。項目が足りない、取引先ごとの単価や締め日を表せない、帳票の形が違う。そうした部分を担当者がExcelや紙で補うと、入力が二か所に分かれ、どちらが正しいかを確かめる手間が増えます。やがてExcelのほうが業務の本体に戻り、既製品が使われなくなることもあります。既製品の良し悪しとは別に、合わない部分を誰がどう埋めるかを決めないまま入れると、こうなりやすくなります。

反対に、一から作ったのに使いにくい、という失敗もあります。作った後に項目や画面を直せる人がいなければ、使いにくさはそのまま残り、同じようにExcelが横に増えていきます。どちらも、比べる段階で「5年でいくら払うか」と「誰が直すか」を並べておけば、入れる前に気づきやすくなる失敗です。

5年の総額には、見積書に書かれない費用も足す

比べる期間は5年にそろえます。税法上、自社で使うソフトウェアの耐用年数は5年とされていて（国税庁 タックスアンサー No.5461）、パッケージを買う場合も作る場合も、その費用を5年かけて償却していくのが基本になるからです。比べる年数を5年にそろえておくと、社内で説明するときの区切りとも合います。6年目以降も使うつもりなら、年数を延ばした計算も並べておきます。会計や税務の扱いは、顧問の税理士に確かめてください。

足す費用は、作り方にかかわらず次の五つの欄に分けられます。欄ごとに、どの作り方で大きくなりやすいかが違います。

見積書や料金表に金額が出てくるのは、始めるときの費用と、毎月・毎年の費用の一部だけです。変えるたびの費用と社内の人の時間は、使っているあいだ毎年のようにかかるのに、どこにも金額が書かれていません。やめる・移るときの費用は、乗り換えるときにまとめてかかります。

この最後の欄は、始める前には見えにくいものです。先の東京商工会議所の2026年の調査では、「既存のシステムが稼働しており、最新のシステムに移行できない」を課題に挙げた企業が12.9%ありました。データをどの形で取り出せるか（すべての項目をCSVで出せるか、添付ファイルや変更の履歴も出せるか）と、そのとき誰が作業するかを、選ぶ段階で確かめておきます。

人数で決まる料金は、人数×月数で5年分を足す

Excelの顧客台帳を顧客管理の仕組みに移す場合に、SaaSのCRM・kintone・自社開発で、利用料の払い方と移行の費用がどう違うかは「Excelの顧客台帳を顧客管理システムに移すと、いくらかかるか」で解説しています。

SaaSやローコードの基盤の多くは、使う人1人あたりの月額で料金が決まります。5年分は「1人あたりの月額×使う人数×60か月」で出せますが、料金表を読むときには次の四つを確かめます。例として、kintoneの公式の料金ページ（kintone 料金、2026年9月25日確認）での書かれ方を添えます。

• 最小の契約人数：使う人が少なくても、最小の人数分を払います。kintoneのライトコースとスタンダードコースは、最小10ユーザーからの契約です。
• 必要な機能で決まる料金の段：kintoneでは、外部のサービスとの連携、プラグイン、JavaScriptやCSSによるカスタマイズといった拡張機能を使えるのはスタンダードコース以上で、ライトコースでは使えません。使い始めてから拡張が要るとわかったら、上のコースの単価で5年分を計算し直します。
• 社外の人の分：取引先や協力会社にも入力してもらうなら、その人たちの分もかかることがあります。kintoneでは、社外の人を招く「ゲストユーザー」が、1ユーザーごとの月額のオプションです。
• 料金の改定：単価は提供元の判断で変わります。東京商工会議所は2025年1月の集計で、コストの負担を課題に挙げる企業が増えた背景の一つに、ライセンスやサブスクリプションの価格の上昇を挙げています（「中小企業のデジタルシフト・DX実態調査」集計結果（詳細版）、2025年1月10日）。

人数で決まる料金とは別に、プラグインや連携サービスの月額もかかります。サイボウズのカスタマーサポートは、プラグインや連携サービスについての問い合わせを受け付けておらず、それぞれの提供元に問い合わせるよう案内しています（kintone ヘルプ）。料金も、それぞれの提供元の料金表で確かめます。構築を外部に頼むなら、その費用は「始めるとき」の欄に入ります。

作る場合は、作った後の費用が長く続く

パッケージの導入やスクラッチ開発は、最初に払う額が大きく見えます。けれども5年の総額では、作った後の欄も同じ重さで見ます。保守（不具合の調査と修正、問い合わせへの対応）、サーバーやクラウドの費用、OSや部品の更新、そして変更のたびの開発が、使っているかぎり毎年かかるからです。

入れた後の費用がかかり続けるのは、多くの会社に共通しています。先の東京商工会議所の2026年の調査で、直近1年間のデジタル化の予算額を尋ねた設問では、既存のシステムの維持・運営（機器を含む）に予算を使った企業が86.9%で、新しいシステムの導入（機器を含む）に予算を使った企業の81.2%より多くなっています（口頭・電話・帳簿での業務が多いと答えた企業を除く集計）。

作る場合に5年の総額を大きく動かすのは、変更のたびの費用です。1回の変更にいくらかかり、5年で何回頼むことになりそうか。受発注や在庫の仕組みは、取引先や品目が増えるたびに手を入れることになるので、変更の回数が多い会社ほど、この欄が大きくなります。保守の月額に変更が含まれるのか、そのつど別に頼むのかによって、同じ回数でも欄の大きさは変わります。

一方で、作る場合は、人数分の利用料がかからない作り方にできます。使う人が多い業務や、取引先にも入力してもらう業務では、毎月・毎年の欄が人数で増えない分、5年の総額で既製品と順位が入れ替わることがあります。どちらになるかは、人数と変更の回数を入れて計算してみるまで分かりません。

パッケージに合わせて直す開発の単価は、規模が大きいとスクラッチ開発を上回る

既製品を土台にして、合わない所を直して使う方法もあります。パッケージを買って自社向けに手を入れる、SaaSの上に追加の開発をする、といった形です。直す量が少なければ早く始められますが、直す作業の単価は、一から作る開発より高くなることがあります。

日本情報システム・ユーザー協会（JUAS）の「ソフトウェア・メトリクス調査2025」ガイドブックは、外注コストの記録があるプロジェクトについて、1人月（1人が1か月働く量）あたりの加重平均単価を、開発の方法別に出しています。パッケージ利用開発（39件）の単価は、スクラッチ開発（99件）の1.5倍でした。SaaSを使った開発（15件）もパッケージ利用開発と同じ水準で、こちらは件数が少ないため参考として扱うよう注記されています。JUASは理由として、パッケージを使いこなす技能やノウハウが要ることと、パッケージに詳しい技術者が需要に対して足りていないことを挙げています。

ただし、工数の規模の区分ごとに見ると、差の出方は一様ではありません。10〜50人月の区分では、パッケージ利用開発の単価はスクラッチ開発とほぼ同じ（1.0倍）で、差が開いているのは50人月以上の区分です（10人月未満の区分は、パッケージ利用開発が1件だけです）。10〜50人月ほどの規模なら、単価の差はほとんど無いと読んでおきます。

既製品の側の更新にも注意が要ります。kintoneを提供するサイボウズは、開発者向けのサイトで、kintoneでは定期的に機能の改善やアップデートが行われ、APIの説明書（APIドキュメント）に無い方法で作ったカスタマイズは動かなくなるおそれがあると説明しています（cybozu developer network「アップデートの影響を受けにくいカスタマイズTips」）。既製品を土台に直した部分は、提供元が更新するたびに、動くかを確かめる作業が続くと見ておきます。

公開後に項目を足すのは誰か

販売管理を kintone で組む案と Webアプリで構築する案に分け、直せる人や費用の形を並べて比べた例は、導入事例「販売管理システムを、Webアプリで構築するか kintone で組むか」で紹介しています。

5年の総額のうち、変えるたびの欄をどれだけ小さくできるかは、直す人がどこにいるかで決まります。東京商工会議所が2024年10〜11月に行った調査で、情報システムの担当者を置いているかを尋ねた設問では、専任の担当者がいる企業は11.7%、兼任の担当者がいる企業は43.9%、外部に委託している企業は15.0%、担当者はいない企業は28.9%でした（主に東京23区の中小企業。口頭・電話・帳簿での業務が多いと答えた企業を除く1,002社の集計。集計結果（詳細版）p.15）。

従業員の規模別に見ると、5人以下では「担当者はいない」が44.3%で、専任の担当者がいる企業が半数を超えるのは101人以上（56.7%）だけです。51〜100人でも、専任の担当者がいる企業は25.0%でした。

専任の担当者がいない会社では、直す人は兼任の担当者か、社外の人になります。そうであれば、作り方を選ぶときに、直す人も一緒に決めておきます。作り方ごとに、社内で直せる範囲と、頼む先は次のように分かれます。

SaaS：直せるのは設定の範囲まで

画面や機能を変えられるのは提供元だけで、自社で変えられるのは設定の範囲までです。欲しい機能が無ければ、提供元が機能を足すのを待つか、既製品の外で補うことになります。設定を触る人を決め、その人が異動しても分かるように、設定の中身を書き残しておきます。

ローコード：項目は社内で、プログラムでの拡張は技術者に頼む

kintoneのような基盤では、項目や一覧、集計の変更は、プログラムを書かずに社内で行えます。一方、JavaScriptやAPIを使ったカスタマイズについて、サイボウズのカスタマーサポートは問い合わせを受け付けていません。プログラミングの知識が要るため、自社で開発するか、パートナーに頼むよう案内しています（kintone ヘルプ「API、カスタマイズ、プラグインや連携サービスに関するお問い合わせ」）。社内で直す範囲（プログラムを書かない設定）と、技術者に頼む範囲（カスタマイズ、プラグイン、連携）を分け、後者の頼み先を先に決めておきます。

パッケージ：その製品に詳しい技術者が直す

直す人は、製品の提供元か、その製品を扱う導入・保守の会社の技術者です。保守の契約で、項目の追加や帳票の変更をどこまで頼めるか、製品の版が上がるときの確認を誰が受け持つかを確かめます。前の節のとおり、パッケージに詳しい技術者は需要に対して足りていない、というのがJUASの見立てです。

専用のWebアプリ：作った会社か、資料を受け取った人が直す

業務に合わせてどこでも直せる代わりに、直せるのは中身を知っている人だけです。作った会社が保守を続けるなら、その会社が直す人になります。別の会社や社内の人に移せるようにしておくには、ソースコード、データの定義（項目・マスタ・つなぐ先と受け渡すデータの一覧）、動かし方と更新の手順を受け取れる契約にしておきます。

権利の扱いも契約で決まります。IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」第二版は、納入物の著作権について、すべて開発会社に残す案、汎用的に使えるプログラムを除いて発注側に移す案、汎用的に使えるプログラムを除いて共有にする案の三つを示しています。どの案にするかで、あとから自社や別の会社が手を入れるときにできることが変わるので、直す人の見込みを決めてから選びます。

生成AIで変わったのは「作る」のどの部分か

生成AIを使った開発で縮むのは、決まった仕様を画面や定型の処理にする部分です。当社も専用のWebアプリは生成AI（Claude Code）を使って作り、先にできた画面を触っていただきながら直していく進め方をとっています。縮む幅は作業の中身や条件で大きく変わり、研究の結果と、生成AIを使う前提の見積もりの確かめ方は「システム開発の見積もりは妥当か」で紹介しました。ここでは、この変化が5年の総額のどの欄に効くかを見ます。

変わったことの一つは、既製品に合わない一部分だけを専用に作る、という範囲の小さい開発が検討しやすくなったことです。画面や定型の処理を作る時間が縮めば、業務の全部を作り直さなくても、合わない部分だけを足せます。次の節の、既製品と一から作るのあいだの作り方は、この変化を前提にしています。

変わらないこともあります。業務の聞き取り、取引先ごとの例外の整理、実際のデータでのテスト、使う人への説明は、生成AIを使っても業務を知る人の時間が要ります。そして直せる人の問題は、生成AIを使っても消えません。コードを読んで直す作業を生成AIに手伝わせるにも、ソースコードとデータの定義が手元にあり、直した結果を確かめる手順があることが前提です。SaaSやパッケージの中身は、生成AIを使っても自社では直せません。

当社の受発注・在庫の仕組みづくりでは、操作の手順と、データの定義（項目・マスタ・つなぐ先と受け渡すデータの一覧）を、引き渡すものに含めています（範囲は見積もりの段階で決めます）。直す人を社内や別の会社に移せるかは、作る前の取り決めで決まるからです。

既製品と、一から作るのあいだにある作り方

買うか作るかは、業務全体で一つに決める必要はありません。会計や勤怠のように、どの会社でも流れが近い業務は既製品を使い、取引先ごとの条件や現場の入力画面のように、既製品に合わない部分だけを専用に作ってAPIでつなぐ組み合わせ方があります。

当社も自社の業務でこの形をとっています。勤怠の打刻はkintoneのアプリで受け、工数のデータをAPIで自社開発のプロジェクト管理のWebアプリに渡し、CRMにある受注金額と突き合わせています。プロジェクト管理を既製のサービスにしなかったのは、操作が合わない、ほかの仕組みとつながらない、人数分のアカウントの費用がかさむ、という理由からです（SaaSとWebアプリの自社での組み合わせ方）。

この形では、5年の総額も直す人も、既製品の側と作った部分とに分けて考えます。つなぐ部分（API）の手入れは作った部分の保守に含めて見積もり、止まったときにどこを誰に見てもらうかまで決めておくと、兼任の担当者が一人で抱え込まずに済みます。

当社が生成AI（Claude Code）で専用のWebアプリを作る場合も、今の会計や販売管理を残したまま、足りない部分だけを足す進め方ができます。既製品で足りる業務は、既製品のまま残します。

自社の数字で5年の総額を出す表

最後に、作り方の候補ごとに5年の総額を出す表です。候補ごとに1枚ずつ作り、使う人数と年数はすべての候補でそろえます。分からない欄は空けておき、料金表を見るときや見積もりを頼むときに埋めます。

変えるたびの回数は、過去1〜2年に業務で起きた変更（取引先の追加、単価の改定、帳票の変更、制度の変更への対応）を数えると見当がつきます。表が埋まったら、人数と変更の回数を少し動かして、候補の順位が入れ替わる点を確かめます。人数が増えると人数で決まる料金の候補が重くなり、変更が多いと直す人が社外にいる候補が重くなる、という入れ替わりが、自社の数字で見えてきます。

受発注の仕組みであれば、始めるときの欄を左右する画面・帳票・つなぐ先の数え方を「受発注システムの開発費は、取引先と例外の数で決まる」にまとめました。見積もりを頼む前に数えておくと、各社の見積もりを同じ前提で並べられます。

Aurant Technologiesでは、kintoneなどの既製のツールを業務に合うかで比べて選び、社内で直せる状態まで整える支援を業務ツール導入・活用支援で、取引先ごとの例外が多い受発注・在庫を専用のWebアプリで作る開発を受発注・在庫管理システムの開発で承っています。この記事の表が途中まででも、どの作り方を候補に残すかの整理からご相談いただけます。