Webシステム

ローコード開発会社の選び方|内製と外注の判断基準と発注前の確認項目

ローコード開発を頼む会社を探し始めると、比較サイトに並ぶのは「おすすめ10社」の一覧ばかりで、自社の条件でどう絞ればよいかは書かれていません。実務で候補が減る決め手になるのは、会社の知名度ではなく、扱える製品の裏付けと、ライセンスを誰の名義で契約するかという2点でした。この記事では、ローコードを請け負う会社の3類型と契約形態の違いから始め、実績・認定資格・契約主体・内製化支援・保守体制という5つの選定軸、見積書で抜けやすい費用項目、内製と外注を分ける4条件、発注すべきでない3場面、契約書に入れる成果物の範囲までを、発注する側の判断材料としてまとめました。

まとめ:ローコード開発の会社選びは対応ツールの裏付けと契約主体で決まる

会社の規模や事例数は、候補を3社に絞る段階ではほとんど効きません。効いたのは、その会社が扱う製品を業務として何件回してきたか、そしてライセンス契約を自社名義にできるかどうかでした。

結論は3つあります。まず順序として、要件を整理して製品を2〜3個に絞ってから、その製品を扱える会社を探す。会社を先に決めると、その会社の得意な製品に要件のほうが寄せられます。次に、対応ツールの裏付けは自己申告ではなく客観指標で見る。kintoneなら認定資格が3段階5種類あり、開発スキルを示すカスタマイズスペシャリストの在籍有無で、JavaScriptカスタマイズを社内で持てるかが分かります。Power PlatformならPL系の試験がありますが、PL-200が2026年8月31日午後11時59分(中央標準時)に廃止予定と告知されているとおり資格自体が改廃されるため、取得年と現行制度かをあわせて確認してください。

3つ目が契約主体です。ライセンスを開発会社の名義で契約すると、会社を替えるときに環境ごと引き継ぐ手続きが増えます。テナントは自社名義で契約し、開発会社には管理者権限を付与する形にしておくと、退場条件の交渉が短く済みました。そのうえで、社内に専任者を0.5人月も置けないなら外注、現場が月1回以上仕様を変える業務なら内製と、判断を条件で切り分けます。

ローコード開発を請け負う会社の3類型と、対応範囲・契約形態の違い

「ローコード開発会社」と一括りにされていますが、実際に見積書を出してくる会社は担当範囲がまったく違います。同じ要件を3社に投げると、金額差より前に、提案の前提そのものがずれていることに気づきます。

基盤ベンダー系・SIer系・内製化支援系という3類型の守備範囲

1つ目が基盤ベンダーとその販売パートナーです。kintoneやPower Platformといった特定製品に密着し、ライセンスの再販まで担います。製品の制約を熟知している反面、その製品で解けない要件が出たときに代替案が出てきません。

2つ目がSIerや受託開発会社で、既存の基幹システムとの連携やスクラッチ併用まで含めて設計します。3つ目が内製化支援・伴走型で、作るのは自社の担当者、支援側は設計レビューと教育を担います。どの類型に頼むかで、成果物として何が納品されるかも変わりました。

類型 守備範囲 典型的な契約 向く案件
基盤ベンダー・販売パートナー 製品設定とライセンス提供 再販+準委任 製品を絞り込み済みの案件
SIer・受託開発会社 既存システム連携と併用開発 請負が中心 基幹連携を含む案件
内製化支援・伴走型 教育と設計レビュー 準委任 現場が作り続ける案件

提案を比べるときは、この類型を先に相手に確認しておくと、比較の土俵が揃います。

請負と準委任で変わる成果責任と、ローコード案件での使い分け方

請負契約は仕事の完成に対して責任を負い、準委任契約は善良な管理者の注意をもって業務を遂行する義務を負います。ローコード案件は画面を見せながら仕様を詰める進め方が多く、要件の変動を前提にすると準委任のほうが噛み合います。

ただし準委任には完成義務がないため、受入基準を別途決めておかないと「どこで終わりか」が曖昧なまま工数だけ積み上がります。実務では、要件定義と初期構築を請負、公開後の改修と教育を準委任という分け方が扱いやすい形でした。契約形態そのものの違いは準委任契約と請負・派遣の違いで整理しています。

ツール選定が先か会社選定が先かという順序と、先に固定する弊害

製品を1つに決め打ちしてから会社を探すと、候補が国内で数社まで減り、価格交渉の余地がなくなります。逆に会社を先に決めると、その会社が扱える製品の範囲に要件のほうが合わせられます。

順序としては、要件を業務単位で書き出す、製品を2〜3個に絞る、その製品を扱える会社を各2社ずつ当たる、の3段階が扱いやすい形です。製品ごとの向き不向きはローコードツールの用途別比較と選定基準に、そもそもローコードで作るかスクラッチで作るかの分岐はスクラッチ開発とパッケージ・ローコードの違いにまとめてあります。この2つを先に通してから会社に当たると、初回打ち合わせの精度が上がります。

発注先候補を5つの軸で絞り込む手順と、実績・認定資格の見極め方

提案依頼を出す前に候補を5社程度まで減らす作業は、公開情報だけでもかなりできます。見るべき順に5つの軸を並べます。

同業種・同規模の構築実績と、公開事例だけでは判断できない範囲

公開されている導入事例は、顧客から掲載許諾が取れた案件だけです。件数が多い会社ほど実力があるとは限らず、事例ページの更新が3年前で止まっている会社もあります。

同業種であることより、同じ連携先を扱った経験があるかのほうが精度が高い指標でした。会計システム、販売管理、SFAのどれと繋いだのか。聞き方は「直近1年で、この製品の案件を何件、平均何人月で担当しましたか」が具体的です。担当者の在籍年数まで踏み込むと、提案する人と作る人が同じかも見えてきます。

対応ツールの裏付けになるkintone認定資格とPower Platform資格

自己申告の「対応可能製品一覧」は当てになりません。客観指標として使えるのが製品ベンダーの認定資格です。

kintoneの認定資格は3段階5種類で構成されています。第1段階が基礎スキルのアソシエイト、第2段階がビジネススキルのアプリデザインスペシャリストと開発スキルのカスタマイズスペシャリスト、第3段階がカイゼンマネジメントエキスパートとシステムデザインエキスパートです。JavaScriptによるカスタマイズを社内で完結できるかは、カスタマイズスペシャリストの在籍で判断できます。

Power Platform側はマイクロソフトの試験があり、機能コンサルタントのPL-200、開発者向けのPL-400、ソリューションアーキテクトのPL-600という構成です。PL-200は合格スコア700で、Microsoft Learnの試験ページに「2026年8月31日午後11時59分(中央標準時)に廃止されます」と告知が出ています。資格は改廃されるため、保有者の人数だけでなく取得年と現行制度での認定かを確認してください。

ライセンスの契約主体が直接契約かパートナー再販かで変わる移管性

見落とされやすいのが、ライセンスを誰の名義で契約するかです。開発会社経由の再販だと請求も管理画面の一次窓口も会社を通るため、会社を替えるときにテナントの移管手続きが発生します。

kintoneは初期費用無料で1か月から契約でき、ライトコースが1ユーザー月1,000円(最低10ユーザー・アプリ200個)、スタンダードコースが1,800円(アプリ1,000個)、ワイドコースが3,000円(最低1,000ユーザー・アプリ3,000個)という体系です。Power Apps Premiumは1ユーザー月2,998円(年払い・消費税別)で、大量購入の1,799円は最小2,000シートが条件のため、数十人規模では効きません。

推奨は、テナント契約を自社名義で結び、開発会社には管理者権限を付与する形です。単価が数十円安くなる再販より、退場時に環境が自社に残ることのほうが金額換算で大きくなります。

内製化支援の中身を見分ける3つの質問と、伴走型で成果が出る条件

「内製化支援」を掲げる会社は増えましたが、中身は代行に近いものから教育中心のものまで幅があります。見分けるには3つ聞けば足ります。

  • 設計の意思決定は誰が行うか(支援側が決めるなら実質は代行です)
  • 納品物にアプリ設定書と運用手順書が含まれるか
  • 伴走を終える条件は何か(期間か、自社担当者が何本作れたらか)

3つ目に明確な答えが返る会社は、終了後の状態まで設計しています。成果が出た案件に共通していたのは、業務側のキーパーソンが週に4時間以上を確保できていたことでした。時間を出せないなら伴走型は選ばず、受託で作り切ってもらうほうが結果的に安く済みます。

保守運用の担当範囲と、基盤の仕様変更へ追随する体制の確認方法

ローコード基盤は事業者側の都合で更新されます。コネクタの仕様変更や管理機能の追加が入ったとき、自社のアプリを直す作業は誰の担当になるのか。ここを契約前に決めていない案件で、後から追加費用の話がこじれます。

確認するのは、障害時の一次受けが開発会社か基盤事業者か、基盤の仕様変更に伴う改修が保守範囲に入るか、年間の改修工数枠が何時間分かの3点です。権限設計や公開範囲の点検を保守に含めるかも決めておくと安全で、この領域の具体的な確認項目はローコード開発のセキュリティリスクと対策にまとめています。

見積書の比較でローコード特有に抜けやすい費用項目と単価の見方

複数社の見積書を並べると総額に倍近い差が出ることがありますが、その多くは何を見積もりに含めたかの差です。ローコード案件で抜けやすい項目は決まっています。

ライセンス費・環境費・外部連携費が見積書のどこに計上されるか

まずライセンス費です。自社で直接契約する前提の見積書には計上されないため、初期構築費だけを比べると安く見えます。次に環境費で、開発・検証・本番の3環境を分けるとテナントやライセンスが追加で必要になる製品があります。

3つ目が外部連携です。kintoneのAPIリクエスト上限は1アプリあたり1日10,000(スタンダードコース)で、ライトコースにはAPI連携そのものがありません。基幹システムと日次同期する設計だと、この上限がコース選択と設計を縛ります。データ容量も1ユーザーあたり5GBという単位で決まるため、添付ファイルの多い業務は人数分の積み上げで計算してください。費用の内訳と5年総額の比較はローコード開発の費用相場と見積もり内訳で試算しています。

人月単価の目安と、ローコードでも工数が減らない要件定義・移行

ローコード案件の人月単価は、国内の受託でおおむね60万〜100万円のレンジに収まります。スクラッチより単価が下がるわけではなく、下がるのは総工数のほうです。

減るのは画面実装とテストの一部。減らないのが要件定義、データ移行、既存システムとの連携仕様の調整です。この3工程は作り方に関係なく同じ量が必要で、見積書で極端に薄い会社は後から追加を出してきます。逆に、要件定義に全体の3割を割いている見積書は、進め方を理解している会社の書き方でした。

内製と外注のどちらを選ぶかを分ける4条件と、判断すべき優先順位

ローコードは「自社で作れる」ことを売りにしているため、そもそも発注すべきかから迷います。ここは条件による切り分けが可能です。玉虫色に両論併記せず、優先順位を付けて言い切ります。

開発会社への外注が有利になる条件と、期待できる立ち上がり速度

次の4条件のうち2つ以上に当てはまるなら外注を選びます。専任者を0.5人月も社内から出せない。3か月以内に本番稼働させる期限がある。既存の基幹システムとの双方向連携がある。作れる担当者が1人しかおらず、退職すると止まる。

この状態で内製に踏み切ると、初期構築より運用開始後に詰まります。外注した場合、業務が単純な申請・集計系なら初回リリースまで1〜2か月、基幹連携を含むと3〜6か月が実務上の目安です。製品選定から運用移管まで含めた相談先を探している段階であれば、ノーコード・ローコードアプリ開発で対応範囲を確認してください。

内製が有利になる条件と、社内に確保すべき人員体制の最低ライン

逆に内製が勝つのは、現場主導の申請・集計・照会業務で、仕様が月1回以上変わるケースです。変更のたびに見積もりと稟議を通していては業務のほうが待てません。

最低ラインは、専任0.5人月の担当者1名と、業務を決められるキーパーソン1名。この2名を確保できないなら内製は成立しないと考えてください。体制づくりの進め方は内製化と外注の違い・進め方で整理しています。

ローコード開発会社に発注すべきでない3つの場面と、その代替案

発注しないほうがよい場面もはっきりしています。1つ目は、要件が固まっていて10年以上使う基幹領域。ライセンスを人数分払い続けるより、スクラッチで作って資産として持つほうが総額で下回ります。判断材料はローコード開発のデメリットと採用可否にまとめました。

2つ目は、利用人数が数百人規模で、ライセンス総額が初期開発費を数年で超える見込みがある場合。3つ目は、社内で製品だけが先に決まっており、その理由が「他社が使っているから」しかない場合です。この状態で会社を探すと、製品の制約に合わない要件が後から噴き出し、選定からやり直しになります。まず要件から製品を選び直してください。

提案依頼と契約で確認する項目と、成果物の引き渡し範囲の決め方

候補が3社に絞れたら、同じ条件で提案を依頼します。ローコード案件でだけ必要になる確認事項があり、これを漏らすと比較になりません。

提案依頼の段階でローコード案件に固有の確認事項として渡す項目

提案依頼書に次の6項目を入れておくと、各社の回答が同じ粒度で返ってきます。

  1. ライセンスの契約主体(自社名義か再販か)と月額の内訳
  2. カスタマイズの有無と、使う言語・想定するコード量
  3. 開発・検証・本番の環境構成と、それぞれの費用
  4. 納品物の一覧(設定書・手順書・ソースコード)
  5. 基盤の仕様変更に追随する改修の担当と費用負担
  6. 保守契約に含まれる年間の改修工数枠

回答が揃うと、総額の安さではなく前提の違いで比較できます。6項目のうち3つ以上に「別途お見積り」としか返ってこない会社は、この段階で外して差し支えありません。

契約書に入れる成果物の定義と、ベンダー変更時に残るものの範囲

ローコードで作ったものは、スクラッチのようにソースコード一式が納品されるわけではありません。何が手元に残るかを契約書で定義しておきます。

具体的には、アプリのエクスポートファイル(kintoneならアプリのテンプレート、Power Platformならソリューションのパッケージ)、設定内容を記した設定書、外部連携の仕様書、そしてJavaScriptやプラグインを作った場合はそのソースコードと権利の扱いです。権利は著作権譲渡か、二次利用まで含む利用許諾のどちらかを明記します。

あわせて、契約終了時に管理者権限を自社へ返す期限と、データエクスポートの形式・提供期限を書いておくと、会社を替える判断が取りやすくなります。ここまで決めておけば、発注先の選定を後からやり直す余地が残ります。

よくある質問

ローコード開発の発注先を検討している担当者から実際に寄せられる質問を5つ挙げ、判断の基準になる範囲で答えます。

ローコード開発会社に依頼する費用の相場はどのくらいですか?

初期構築費は、申請・集計といった単機能の業務アプリで50万〜200万円、基幹システムとの連携を含む中規模案件で300万〜1,000万円程度が国内受託のレンジです。人月単価は60万〜100万円に収まります。これとは別にライセンス費が毎月かかり、kintoneはスタンダードコースで1ユーザー月1,800円、Power Apps Premiumは1ユーザー月2,998円(年払い・消費税別)という水準でした。利用人数が多いほど、初期費より月額のほうが総額を左右します。

ノーコード開発の会社とローコード開発の会社は何が違いますか?

ノーコード専門の会社はコードを書かない範囲で完結させるため、既存システムとの連携や複雑な権限制御が要件に入ると対応できないことがあります。ローコードを扱う会社は、標準機能で足りない部分をJavaScriptやプラグイン、APIで補える点が違いです。見分ける指標としては、開発スキルを示す認定資格の保有者がいるか、過去案件でAPI連携を何件担当したかを聞いてください。

開発会社が使うツールは自社で指定したほうがよいですか?

製品を1つに指定するのは早すぎます。要件を書き出したうえで2〜3製品まで絞り、その範囲で提案を受ける形が実務的です。指定を先にすると候補企業が数社まで減り、価格も条件も相手の言い値に近づきます。すでに社内に同じ基盤の契約がある場合はその製品を優先候補に置いて構いませんが、要件が合わないと分かった時点で見直せる余地を残してください。

開発を依頼した後で内製に切り替えることはできますか?

できます。切り替えを見据えるなら、契約時に3つ決めておいてください。ライセンスを自社名義で契約すること、設定書と手順書を納品物に含めること、管理者権限を自社が保持することです。この3つが揃っていれば、保守契約を終えた後も自社で改修を続けられます。逆に開発会社名義のテナントで作った場合は、移管作業そのものに数十万円規模の費用が発生することがあります。

小規模な会社と大手SIerではどちらに依頼すべきですか?

規模ではなく、担当者の顔が見えるかで選んでください。判断材料になるのは、提案した人がそのまま構築を担当するか、その担当者が同じ製品を直近1年で何件扱ったかの2点です。大手は体制の厚さと継続性で有利ですが、ローコード案件は担当者個人の製品習熟度が品質を左右します。年間の改修工数枠と、担当者交代時の引き継ぎ方法を契約で押さえておけば、規模による差は小さくできます。

関連記事

資料請求

RELATED POSTS 関連記事