業務システム 受託開発の比較 (2026 年版)｜SIer・SES との違いと候補を 3〜5 社に絞る手順

比較サイトやマッチングサービス、「おすすめ◯社」の記事で候補を探すと、業務システムの開発会社の名前はすぐに集まります。一方で、10 社を超える候補から何を基準に絞るのか、「一式 ◯◯ 万円」と「月額 ◯◯ 万円 × 人数」のように形の違う見積をどう並べるのか、稟議に選定理由をどう書くのかは、会社の一覧を見ても分かりません。

本記事では、比較サイトなどで集めた候補を 3〜5 社に絞る手順を扱います。会社名の一覧は載せません。SIer・SES・受託開発という言葉の違いから、発注先 4 タイプの向き不向き、8 つの評価軸、形の違う見積の揃え方、業種別の論点までを順に扱います。AI を組み込む開発を発注する場合は、AI 開発の発注前に確認する 10 項目 もあわせて確認してください。

結論: 会社名より先に「契約の形」と「発注先のタイプ」を決め、8 つの評価軸で 3〜5 社に絞る

候補は 2 段階で絞ります。

1 段階目は、案件の性質から契約の形と発注先のタイプを決めることです。規模、要件の固さ、社内に PM がいるか、業務を止められない度合いを見て、請負で完成まで任せるのか、準委任 (SES を含む) で作業の遂行を委ねるのかを決めます。そのうえで、大手 SIer・中堅 SI・AI 駆動スタジオ・フリーランス集団の 4 タイプのうち、どれが案件に合うかを選びます。

2 段階目は、タイプの中で個社を比べることです。実装体制、品質保証、セキュリティ、データ移行実績、業種経験、保守体制と引き継ぎ、稼働率・対応時間の保証、AI 活用度の 8 つの評価軸に、案件の性質に応じた重みを付けて並べ、3〜5 社に絞ります。

候補の会社はどこで集めるか

候補の集め方は、大きく 4 つの経路に分かれます。どれも使えますが、それぞれに偏りがあります。

集め方	向いている場面	気をつける点
マッチングサービス	候補がゼロで、要件をまだ言葉にしきれていない	紹介されるのは登録している会社に限られる。運営側の収益の仕組みも知っておく
比較・おすすめ記事	業界の顔ぶれを短時間でつかみたい	掲載順は中立のランキングとは限らない。掲載料や資料請求で収益を得るメディアもある
知人・取引先からの紹介	信頼できる相手を少数に絞りたい	比較が甘くなりやすい。紹介された会社も同じ評価軸で見る
既存の取引先	現行システムのリプレイスや機能追加	現行を知っている強みがある。比べる相手を別に用意しないと価格の妥当性が見えない

経路を 1 つに限らず、2〜3 の経路から、目安として 10 社前後を集めると、候補の偏りを抑えられます。集めた段階では会社の良し悪しを判断せず、この後の 2 つの節で扱う契約の形とタイプで振り分けてから、8 つの評価軸で比べます。

SIer・SES・受託開発の違い

候補を振り分ける前に、SIer・SES・受託開発という言葉を整理しておきます。3 つは同じ軸の言葉ではないため、「SIer と SES と受託開発のどれがよいか」という比べ方をすると混乱します。

システム受託開発とは

システム受託開発は、発注側の要件をもとに、開発会社が業務に合わせたシステムを設計・開発して納める取引です。既製のパッケージや SaaS を契約して使うのではなく、自社の業務に合わせてゼロから作るか、パッケージを土台に作り足します。契約は完成物に対して報酬を払う請負で結ぶことが多く、要件定義のように先を読みにくい工程だけを準委任で切り出す形もあります。

業務がパッケージの標準機能に収まるなら、作らずに SaaS を使うほうが安く済むことがあります。その分かれ目は 業務システム (社内システム) 開発の見積相場と考え方 で扱っています。

SIer と受託開発の違い

SIer (システムインテグレーター) は、システムの企画から設計・開発・運用までを取りまとめる事業者、またはその役割を指す業界用語で、法令上の定義はありません。受託開発は、完成物を納めてもらうという発注の形を指します。

つまり、SIer は「誰が何を担うか」、受託開発は「どういう形で頼むか」の言葉です。大手 SIer も受託開発を請けますし、開発の一部を協力会社に委ねて、全体の取りまとめに回ることもあります。発注先を比べるときは、全体の取りまとめや多社との調整まで任せたいのか、開発そのものを任せたいのかで考えると、候補のタイプを決めやすくなります。

SES と受託開発の違い (請負と準委任)

SES (システムエンジニアリングサービス) は、エンジニアの作業に対して費用を払う形で、多くは準委任契約で結ばれます。受託開発は多くが請負契約です。違いは契約の性質にあります。民法 では、請負は仕事の完成に対して報酬を払う契約です (632 条)。準委任は法律行為でない事務の処理を委ねる契約で、委任の規定が準用されます (656 条)。準委任を受けた側は、善良な管理者の注意をもって処理する義務を負います (644 条)。成果に対して報酬を払う形の準委任もあります (648 条の 2)。

観点	請負 (受託開発で多い)	準委任 (SES で多い)
報酬の対象	仕事の完成	作業の遂行 (成果に対して払う型もある)
完成の責任	受注側が負う	受注側は完成義務を負わない (善管注意義務は負う)
作業者への指示	受注側の責任者が出す	受注側の責任者が出す
要件の変更	追加見積と契約変更になりやすい	優先度を入れ替えやすいが、期間が延びた分だけ費用が増える
向く場面	要件が固まっていて、進行管理も任せたい	社内で要件を判断でき、範囲が動きやすい

実務では、準委任の場合、完成に向けた判断は発注側に残ります。業務システムで SES が合うのは、社内に PM と要件の判断者がいて、実装の担い手が足りない場面です。社内の PM が決めるのは何を作るかと優先順位までで、日々の作業の指示は受注側の責任者を通します。社内に判断者がいないまま SES で人を入れると、完成に向けた判断を担う人がいない体制になりやすくなります。チーム単位で準委任を組むラボ型は ラボ型開発・チーム貸しの見積構造と使いどころ、海外の開発会社に出す場合は オフショア開発の見積 で扱っています。

本節は比較の前提をそろえるための要約です。発注側の社員がしてよい指示とそうでない指示の線引きや、受託開発と SES をどう選ぶかは 受託開発と SES の違い で詳しく扱っています。

業務システム開発の発注先 4 タイプと費用の目安

契約の形の次は、発注先のタイプです。業務システムの発注先は、次の 4 タイプに整理できます。どのタイプも請負と準委任の両方を請けることがあるため、タイプと契約の形は別々に確かめます。

タイプ	得意な案件	強み	弱み
大手 SIer	全社基幹・勘定系・多社連携の大規模案件	大規模の取りまとめ・監査対応・長期運用	小規模では体制が過剰になり、見積が高くなりやすい
中堅 SI	部門〜全社の中規模案件、特定業種の案件	業種知識と体制のバランスが取れている	AI 活用の度合いは個社差が大きい
AI 駆動スタジオ	コアが明確な中規模の新規開発・リプレイス	期間の短縮を狙える	大規模基幹・多社連携の取りまとめは不得手。長期運用の実績と認証は会社ごとの差が大きい
フリーランス集団	小規模案件、社内でマネジメントできる案件	費用を抑えやすい・小回りが利く	継続保守・品質保証・SLA が弱くなりやすい

表の強みと弱みは、面談で次のように確かめます。

大手 SIer を選ぶ理由になりやすいのは監査対応です。止められないシステムを、監査の要件に沿って運用してきた実績があるかを具体的に聞いてください。

中堅 SI には、金融・製造・医療・自治体・小売など、特定の業種に特化した会社もあります。AI コーディングツールの活用度は会社によって大きく異なるため、実プロジェクトでの使い方を面談で確かめてください。

AI 駆動スタジオは、Claude Code や Cursor などの AI コーディングツールを開発の中心に据えるタイプです。長期運用の実績と、取引の条件になる認証を持っているかは会社ごとに違うため、提案の段階で確認します。

フリーランス集団は、契約の相手が個人事業主の集まりになります。担当者が抜けたときの代わりや、保守を誰が引き継ぐかを契約前に決めておくと、小規模な案件では有力な選択肢になります。詳しくは フリーランスに開発を発注する場合の見積の考え方 を参照してください。

費用の目安は、タイプ別ではなく公的な調査から見る

発注先のタイプごとの人月単価は、根拠を確かめられる公的な調査が見当たらないため、本記事では載せていません。公的な目安としては、日本情報システム・ユーザー協会 (JUAS) のソフトウェア・メトリクス調査 2025 ガイドブック があり、ユーザー企業から集めた開発プロジェクトの実績値から次の値を示しています。

• 外注コストが記載されたスクラッチ開発 99 件について、外注コストと工数から求めた加重平均単価は 96 万円で、10 人月を超える規模では規模による単価の差が小さい (図表 2-9-1)
• 費用・工数などが明確なプロジェクトのうち、単価が 50 万〜400 万円の 195 件について、全体工数と開発総費用の関係から求めた人月単価は 127 万円 (図表 2-8-19)

2 つの値が違うのは、対象と費用の範囲が違うためです。前者はスクラッチ開発に限った外注コストの単価で、後者はスクラッチ開発に限らず、単価 50 万〜400 万円の範囲に絞ったうえでの開発総費用の単価です。どちらも発注先のタイプ別の値ではありません。「大手 SIer ならいくら、AI 駆動スタジオならいくら」という比較には使えない点に注意してください。

規模別の費用感は 業務システム (社内システム) 開発の見積相場と考え方、見積の内訳と読み方は システム開発の見積もり (見積書サンプルと妥当性チェックリスト) で詳しく扱っています。

候補を 3〜5 社に絞る 8 つの評価軸

契約の形とタイプで候補を振り分けたら、次の 8 つの評価軸で個社を並べます。金額の絶対値だけを見るより、判断の根拠を説明しやすくなります。

1. 実装体制の厚さ。投入されるエンジニアの人数、シニアの割合、プロジェクトマネージャの経験を確かめます。大規模案件では厚さが求められ、中規模では少人数のほうが意思決定が速い場合もあります。
2. 品質保証の仕組み。自動テストの範囲、コードレビューの流れ、リリース前の確認の手順を聞きます。仕組みとして決まっている会社ほど、リリース後の不具合を抑えやすくなります。
3. セキュリティと監査対応。ISMS・SOC2・PCI DSS などの認証、脆弱性診断の頻度、監査ログの設計を見ます。金融・保険・医療では最も重い軸です。
4. データ移行実績。既存システムのリプレイスでは、移行リハーサルの経験、大量データの移行実績、切り替え時の停止時間を短くする手順を確かめます。
5. 業種経験。同じ業種での実績の数と規模。金融の勘定系、製造の工程管理、医療の電子カルテなど、業種特有の論点への理解が表れます。
6. 体制と、担当者が替わったときの引き継ぎ。リリース後の運用保守を担う体制と、担当者が異動・退職したときに業務知識をどう引き継ぐか (文書・並走期間) を確かめます。長く使う業務システムほど効いてくる軸です。
7. 稼働率・対応時間の保証と解除条件。稼働率の保証 (99% と 99.9% など)、障害時の初動の時間、24 時間 365 日か営業時間内か、契約解除の条件を見ます。ここが曖昧だと、トラブルのときに責任の所在で揉めます。
8. AI 活用度。AI コーディングツールを実プロジェクトの中心で使っているか、テストを先に書かせるなどの運用が決まっているか。期間とコストに関わります。詳しい見分け方は AI 受託開発の会社を選ぶときの 5 つのチェックポイント にまとめています。

8 軸の重みは、案件の性質で変えます。金融の勘定系リプレイスなら、セキュリティ・業種経験・保守体制と引き継ぎの 3 軸を重み 3、ほかを重み 1 にします。中堅企業の業務システムの新規開発なら、実装体制・品質保証・AI 活用度を重み 2、ほかを重み 1 にする、といった配点です。

FIXIT

大手 SIer と AI 駆動スタジオって、そもそも競合するの？

Hinata

中規模の業務システムでは競合しますよ。大規模基幹だと、大手 SIer の体制のほうが向いています。

稟議に貼る比較表は、次の列で作ると選定理由を説明しやすくなります。評点だけでなく、重みの根拠と懸念点まで書いておくと、後から「なぜこの会社にしたのか」を問われたときに答えられます。

列	書く内容
タイプ	大手 SIer・中堅 SI・AI 駆動スタジオ・フリーランス集団
契約の形	請負・準委任・工程ごとの混在
見積の範囲	含まれる工程と、含まれない工程
3 年総額	次の節の手順で揃えた総額
8 軸の評点	重み付け後の合計点と、重みを決めた理由
選定理由	評点のほかに決め手になった点と、残る懸念およびその対策

形の違う見積を揃えて比べる

候補を 3〜5 社に絞って見積を取ると、見積の形がそろわないことがあります。請負で提案する会社は「一式」で、SES やラボ型で提案する会社は「月額 × 人数」で見積を出すためです。形が違うまま金額を並べても、比べたことになりません。

見積の形	よくある書き方	総額に直すために確かめること
一括請負	一式 ◯◯ 万円	どの工程まで含むか、追加費用になる条件、保守は別契約か
準委任・SES	月額 ◯◯ 万円 × ◯ 名	完成までの想定期間、期間が延びたときの扱い、PM を誰が担うか
実装だけの見積	実装費 ◯◯ 万円	要件定義・設計・テスト・データ移行を誰が担うか (社内か別発注か)

揃える手順は次のとおりです。

1. 工程の範囲を 1 枚の表に揃えます。要件定義・設計・実装・テスト・データ移行・受入支援・保守を行に並べ、各社の見積がどの行を含むかを書き込みます。含まれない工程には、社内で担う場合や別に発注する場合の見込み額を置きます。
2. 月額の見積を総額に直します。完成までの想定期間を書面でもらい、月額 × 人数 × 期間で計算します。期間の見込みを出せない提案は、その事実を比較表に残します。
3. 発注側の負担工数を足します。準委任では、要件の判断と進捗の確認を社内が担います。社内の担当者が割く時間を工数に換算して加えます。
4. 保守・運用・機能追加の費用を足し、3 年と 5 年の総額にします。初期の見積では高く見えた会社が 5 年では安くなることも、その逆もあります。
5. 費用が増える条件を列に加えます。請負なら要件変更による追加見積、準委任なら期間の延長が、費用を押し上げる主な要因です。

相見積の進め方と、各社への依頼の揃え方は システム開発の見積もり の「相見積」と「依頼の準備と RFP」の節で詳しく扱っています。

RFP を出す前に握るべき論点

RFP (提案依頼書) を各社に配る前に、発注側で決めておくべき論点が 3 つあります。ここが決まっていないと、各社の提案の粒度がばらばらになり、前の節の揃え方でも比べきれなくなります。

1 つ目はフェーズ分割です。全体を 1 つの契約で発注するのか、ディスカバリー・MVP・拡張のように分けて段階的に発注するのかを決めます。段階的に発注するほうが外れたときの損失は小さくなりますが、契約の手間と総額は増える傾向があります。規模別の費用と期間の考え方は Web システム開発の費用と期間の相場 で扱っています。

2 つ目は検収基準です。「テストがすべて通る」「本番に近い環境で業務が回る」「業務の担当者が受入テストで合格を出す」のうち、どの水準を検収の基準にするかを事前に決めます。基準が曖昧だと、納品後に「業務が回らない」で揉めます。

3 つ目は契約の形です。請負と準委任の違いは「SIer・SES・受託開発の違い」の節で整理したとおりです。業務システムの新規開発では、要件が固い部分を請負、探索の段階を準委任にする混在の契約が現実的な選択肢になります。契約の選び方は AI 開発の契約は準委任と請負どちらが正解? で詳しく扱っています。

RFP のテンプレートと書き方は AI 開発の RFP (提案依頼書) の書き方 にまとめています。AI 開発向けのテンプレートですが、業務システム全般に使える構成です。

業種別に選び方が変わる論点

同じ業務システムでも、業種によって重く見る評価軸が変わります。主な 5 つの業種の論点を整理します。

金融・保険で最も重い軸は、セキュリティと業種経験です。勘定系・契約系のような止められない領域は、大手 SIer や金融特化の中堅 SI が現実的な選択肢になります。AI 駆動スタジオは、顧客管理や内部業務、レポート基盤などの周辺系から入るのが安全です。長期運用の体制と監査対応の経験を持つ会社を選ぶのが基本線です。詳しくは 金融・フィンテックの AI 駆動開発と堅牢な受託開発の選び方 を参照してください。

工程管理・生産管理は、製造業の現場のオペレーターが毎日使うシステムです。机上の設計だけでは、現場で使えるシステムになりません。現場のヒアリングを丁寧にでき、試作を現場で見せながら進められる体制の会社を選びます。製造業に特化した中堅 SI も有力な候補です。詳しくは 製造業の AI 駆動開発・基幹システム刷新の進め方と費用 を参照してください。

医療・ヘルスケアでは、個人情報の保護と安全管理の要件が最も重い軸です。医療機関の情報システムには、厚生労働省の医療情報システムの安全管理に関するガイドライン (2026 年 6 月に第 7.0 版) があり、システムを提供する事業者向けには、総務省・経済産業省の医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドラインがあります。これらの要件を理解している会社を選びます。医療に特化した中堅 SI か、医療案件の実績を持つ大手 SIer が主な選択肢です。詳しくは 医療・ヘルスケアの AI 駆動開発と業務システム開発の進め方 を参照してください。

小売・EC では、更新の頻度と外部連携の多さが特徴です。EC カート、決済、在庫管理、CRM などとの連携が多く、機能追加が頻繁に求められます。機能追加の頻度が高い点は、AI 駆動スタジオの得意な範囲と重なります。中堅 SI と並べて比べてください。詳しくは 小売・EC の AI 駆動開発でつくる売上を伸ばす仕組み を参照してください。

中小企業の DX 全般では、業務の理解と現場への定着が重要です。IT 部門が小さい企業では、システムを作るだけでなく、業務の流れの整理と現場への定着まで伴走できる体制が要ります。中堅 SI や AI 駆動スタジオのうち、中小企業の支援に強い会社を選びます。詳しくは 中小企業の DX 推進と補助金 を参照してください。

AI 駆動スタジオを選ぶタイミングと「まだ早い」ケース

AI 駆動スタジオが合う案件と、大手 SIer や中堅 SI のほうが安全な案件を、FIXIT の提供範囲から整理します。

AI 駆動スタジオが合うケース

• 中規模の業務システムの新規開発またはリプレイス。FIXIT の場合は 1 案件あたり 400 万〜3,000 万円 (税抜) の規模
• 要件のコアが明確で、対象とする業務の範囲を言葉で区切れる
• 期間の短縮を優先したい (社内で早く効果を出したい、競合より先に出したい)
• 継続的な機能追加を、内製と外注の混在体制で回したい
• 外部サービスとの連携や機能追加の頻度が高い領域 (EC、SaaS として提供する業務システムなど)

大手 SIer や中堅 SI のほうが安全なケース

• 全社基幹・勘定系・生産管理の中核のような大規模基幹
• 24 時間 365 日の SLA が必要で、監査対応が厳格
• 多数の外部システムとの連携があり、それぞれのベンダーとの調整を取りまとめる必要がある
• 長期の運用実績や、ISMS・SOC2・PCI DSS などの認証を取引の条件にしている
• 業種特有の法令要件が多い (金融の勘定系、医療の電子カルテ、自治体の住民情報系)

FIXIT は、業務システムのうち中規模の新規開発とリプレイス、SaaS MVP、AI エージェント開発を得意領域としています。大規模基幹や監査要件の厳しい領域は、大手 SIer や業種特化の中堅 SI のほうが適していると考えています。どのタイプが案件に合うかを、案件の性質から一緒に整理するところから相談を受けています。

失敗を避けるチェックリスト

業務システムの発注先を並列で比べる前に、発注担当者が確認しておきたい項目です。

• 候補を 2〜3 の経路から集め、1 つの比較サイトやリスト記事の掲載順に頼っていないか
• 案件の性質 (規模・業種・優先度) を先に整理し、8 つの評価軸の重みを事前に決めているか
• 候補の各社がどの契約の形 (請負・準委任) で提案しているかを揃えたか
• SES や準委任の場合、作業の指示を受注側の責任者を通して出す形を契約前に決めたか
• 一括の見積と月額の見積を、工程の範囲・期間・発注側の負担工数・保守を揃えた 3 年・5 年の総額に直したか
• RFP を出す前に、フェーズ分割・検収基準・契約の形の 3 論点を決めているか
• 並列比較の対象を 3〜5 社に絞り、一次選考を済ませているか
• 選ばなかった会社に判断の理由を返す段取りになっているか
• 業種別の論点 (金融=セキュリティ、製造=現場協働、医療=安全管理の要件) を評価軸の重みに反映しているか
• AI 駆動スタジオを候補に入れる場合、「合うケース」の条件を満たしているか

業務システムの発注先選びのご相談

業務システムの発注先を比べていて、AI 駆動スタジオを候補に入れるか迷っているなら、FIXIT の無料相談を判断材料の 1 つにしてください。案件の性質からどのタイプが合うか、AI 駆動開発を取り入れると期間と費用がどう変わるかを一緒に整理します。

まずは AI 駆動開発 のサービス内容をご覧いただき、お問い合わせ からご相談ください。既存システムの置き換えであれば システム刷新・リプレイス、新規事業の最初の版であれば SaaS MVP 開発 も参考になります。