契約管理システムの開発会社選び｜SaaSで足りる境界と相見積りの揃え方

契約管理システムを外注しようと開発会社を探し始めると、見積りが数百万円から数千万円まで開きます。原因の大半は会社の値付けではなく、発注側が渡した要件の粒度にあるのが実情です。市販サービスで足りるのか作る側に回るのかを分ける四条件、見積りを同じ土俵に載せる五項目、契約管理という題材でこそ差が出る技術要件の見極め方、工程ごとの契約形態と2026年1月1日に施行された取適法の義務を、発注の順番どおりに並べました。開発会社と話す前に自分で決めておく材料に絞っています。

まとめ：SaaSで足りる境界を先に引いてから開発会社を当たる順序

開発会社を探す前に決めるのは予算でも候補でもなく、市販の契約管理サービスで足りないのはどこかを四条件で判定することです。既存の基幹システムや電子契約サービスと双方向で同期させる必要があるか、権限分離と監査ログの粒度が標準機能を超えるか、稟議から締結までの流れが製品の設定で吸収できないか、契約書以外の文書まで一本化してデータ量が跳ねるか。三つ以上に当てはまるときだけ、スクラッチ開発が費用に見合います。公共分野では入札システム・財務会計システム・文書管理システム・電子契約サービスが連携先の候補になり、その数え方は自治体の契約管理システム導入判断｜契約事務の要件と民間SaaSが合わない条件で示しています。

二つ以下ならSaaSを選び、足りない部分は運用でしのぐほうが総額は下がります。製品側の機能一覧と選定基準は契約書管理システムとは？機能・選び方と比較のポイント・導入判断を解説にまとめました。作る側に回る場合も、締結は電子契約サービスに残し、締結後の管理と検索だけを作るとスコープは大きく縮みます。

開発会社を並べる段では、見積り依頼書に連携先の本数・移行対象の件数・権限の階層・保存要件・稼働環境の五項目を書き込んでから配ります。この五項目が揃わない依頼で集めた相見積りは、金額の大小を比べる意味がありません。要件整理から相談したい場合は文書管理システム開発へ声をかけてください。

契約管理をスクラッチ開発へ振る四条件と、SaaSのままで足りる場面

市販サービスの機能が厚くなり、台帳と期日通知だけなら開発する理由はほぼ消えました。それでも作る案件が残るのは、次の四つのどれかが製品側の設計思想と衝突するからです。

既存の基幹システムと電子契約サービスを双方向同期させる要件の線引き

片方向で足りるのか、双方向が要るのか。ここが第一の分岐です。締結済みPDFを電子契約サービスから取り込むだけなら、多くの製品が標準の連携機能を持っています。難しくなるのは逆向き、つまり基幹システムの取引先マスタを正として契約管理側の相手方を更新し、契約の有効期限を基幹側の与信や発注可否へ返す構成です。

この構成では、どちらを正とするかの決定、更新衝突の解決順序、冪等性の担保が必要になります。市販サービスのAPIは自分のデータを外へ出すことは得意でも、外から来る更新を既存レコードへ突き合わせる部分は薄い。名寄せまで含めて双方向で回す要件が出た時点で、条件一つ目に該当します。

権限分離と監査ログの粒度が市販サービスの標準を超えてしまう条件

市販サービスの権限は「部署」と「役割」の二軸で組まれたものが大半です。足りなくなるのは、同じ部署でも案件単位で見える人を分けるとき、特定の契約種別だけ経営層と法務しか閲覧できない構成にするとき。M&Aや業務提携の契約書を同じ基盤へ載せる会社は、ほぼ確実にここで引っかかります。

監査ログも粒度が問題になります。誰がいつログインしたかは標準で残っても、どの契約のどの項目をどの値からどの値へ変えたかを項目単位で追える製品は限られます。内部統制報告制度の評価対象に契約管理を含めるなら、ここが監査法人からの指摘事項になりやすい。要件を先に書き出し、候補製品の仕様書と突き合わせてください。

稟議から締結までの独自フローを製品側の設定で吸収できない分岐点

承認フローの作り込みは境界がはっきりしています。段数が固定で、金額の分岐が一段だけなら設定で組めます。吸収できなくなるのは、条件の掛け合わせが増えたときです。

• 金額・契約種別・相手方の与信区分の三軸で承認者が変わる
• 差戻し後の再申請で、承認済みの段だけスキップする挙動が要る
• 子会社ごとに規程が違い、同じ基盤で別のフローを併存させる
• 反社チェックや与信照会の結果を待って自動で次段へ進める

このうち二つ以上が同時に必要なら、製品の設定画面では組めません。ただし三軸のうち一軸を運用で潰せないか先に検討してください。与信区分をマスタへ持たせフロー側では見ないと決めるだけで一軸減ります。フローを作り込むより規程を単純化するほうが安いという判断は、ためらわず取ってよい。

保存要件と契約書以外の文書まで一本化するときに出るデータ量の壁

電子帳簿保存法のスキャナ保存で求められる検索項目は、取引等の年月日・取引金額・取引先の三つに限定されています。この三項目なら、どの製品でも標準機能で足りるはずです。壁になるのは保存年限で、法人の帳簿書類は原則七年、欠損金が生じた事業年度は十年のため、基盤は十年分を抱えたまま検索速度を保つ必要があります。

ここに議事録・稟議書・図面まで載せると件数が一桁変わります。文書数課金の製品では費用が跳ね、定額型でもストレージ上限に当たる。契約書だけに絞れば市販サービスで収まり、全社の文書基盤まで広げるなら別の設計が要ります。線の引き方は契約管理台帳のシステム化｜項目設計とExcelが限界になる条件・移行の手順で扱う項目設計と一緒に決めてください。

四条件のうち二つ以下であればSaaSのままで足りると言い切る根拠

該当が二つ以下なら、スクラッチ開発は見送ってください。理由は初期費用ではなく更新の負担にあります。電子帳簿保存法の要件変更やAPI仕様変更のたびに手を入れる領域で、市販サービスならベンダーが吸収する部分を自社の保守費として持ち続けるからです。

足りない機能は運用で吸収できる範囲に収まっているはずで、承認の一部を既存のワークフロー製品で回す、権限は台帳を二つに分けるといった逃げ方があります。スクラッチとパッケージの違いはスクラッチ開発とは？パッケージ・ローコードとの違いと発注判断を解説、SaaS側の三年総額は契約書管理システムの費用は課金軸で決まる｜件数課金と定額型の三年総額を比較で確認できます。

相見積りを比較できる形に揃える要件整理の手順と、RFPへの落とし方

三社に声をかけて三様の金額が返るとき、比べているのは会社の実力ではなく各社が置いた前提です。前提を発注側で固定してから配る。それだけで比較は成立します。

見積りが桁で割れる原因は契約件数ではなく連携先の本数にある点

「契約が何件ありますか」と最初に聞く会社は、見積りの精度が上がりません。件数は移行の工数にしか効かず、開発工数はほとんど動かないからです。金額を桁で動かすのは連携先の本数になります。

基幹システム一本との片方向連携なら追加工数は数人日に収まります。ここに電子契約サービス、人事システムの組織情報、シングルサインオンが加わると、認証方式の実装・再送設計・テスト環境の確保がそれぞれ必要になり、一本あたり十数人日から数十人日が積み上がる。連携ごとの工数が分けて書かれていない見積りは、後から必ず追加見積りになります。

発注前に確定させる五項目と、決めずに出してよい項目との切り分け

要件を全部固めてから声をかける必要はありません。固めるべきなのは、各社の前提がずれると金額が動く項目だけです。

画面のレイアウトや通知メールの文面、帳票の書式は決めずに出して構いません。工数への影響が小さく、提案を受けてから詰めたほうが良い案が出ます。決めきれない項目は空欄にせず「未定・提案を求める」と明記してください。

同じ土俵で並べるための見積り依頼書の書式と、工数内訳の指定方法

依頼書には回答形式を指定します。指定がないと、一式いくらの見積りと工程別の見積りが混在して比較できません。

1. 工程を要件定義・設計・実装・テスト・移行・インフラ構築の六つに分け、人月と単価を分けて書いてもらう
2. 連携は一本ごとに行を分け、対象システム名を書いてもらう
3. 保守運用は初年度と次年度以降を分け、年額と対応範囲を書いてもらう
4. 前提条件と除外事項を記載してもらい、空欄なら「前提なし」と明記してもらう

この四点を指定するだけで、各社の見積書が同じ列に並びます。あわせて「要件定義の完了時点で工数を再算定し、増減分は事前に合意した単価で精算する」と依頼書へ書けば、提案後に要件が増えても揉めません。見積書の読み方と単価の妥当性はシステム開発の見積もりとは？見積書の見方・依頼方法・相見積もりの比較を発注者視点で解説、提案依頼書の形式へ整えるならRFPとは？提案依頼書の意味・目的・記載項目を発注者視点で解説の記載項目に沿うと漏れが減ります。

契約管理という題材で開発会社の力量が出る技術要件と、実績の確かめ方

会社案内に並んだ実績の業種は、契約管理システムの発注ではあまり参考になりません。見るべきは題材の近さです。契約という文書は版が変わり、親子関係を持ち、期限で状態が変わる。この三つを扱った経験の有無が提案書に出ます。

電子契約サービスのAPIとWebhookを扱った実績の確かめ方

締結完了を契約管理側へ自動で取り込む構成は、Webhookで組みます。クラウドサインのヘルプセンターによれば、Web APIを利用できるのはスタンダード、コーポレート、ビジネス、エンタープライズの各プランで、利用する設定にするとWebhookとCORS Origin URL設定も使えるようになり、利用しない設定に戻すと双方が止まります。Webhookの通知先設定数は最大二十個です。

この仕様を知っている会社かは、質問一つで分かります。「締結完了の通知を取りこぼしたとき、どう復旧しますか」と聞いてください。Webhookは到達を保証しないため、定期的に一覧を取得して差分を埋める仕組みを併走させる答えが返れば実装経験があります。「再送されるので問題ない」と答える会社は作ったことがない。締結側の選定基準は電子契約システムの比較と選び方とは？認証方式・連携・費用の判断軸を解説にまとめました。

全文検索と項目検索のどちらを軸に据えたのかで判別できる設計の深さ

契約書の検索は二つの経路を持ちます。台帳の項目から絞り込む経路と、PDF本文から語句を探す経路です。提案書でこの二つが分けて書かれているか見てください。

全文検索だけを推す提案は実務を外しています。頻度が高いのは「今期に満了する自動更新条項付きの契約」といった項目の掛け合わせで、本文検索では出せません。逆に項目検索だけでは、この条項が入っている契約を全部出すという法務からの依頼に答えられない。両方を用意し、初期は項目検索を先に作って全文検索はテキスト化が済んだ範囲から広げる、という順序を示す提案が実装を分かっている側の答えです。

保存要件と論理削除の設計まで提案書に書ける会社かどうかの見分け方

契約データは消せません。保存年限が残るあいだは、担当者が削除操作をしても物理的には残す必要があります。削除フラグを立てたレコードを検索対象から外しつつ監査時には取り出せる構成が提案書にあるかどうかで、経験値が測れます。

あわせて保存年限の起点を確認してください。法人税法上の保存期間は事業年度の確定申告書の提出期限の翌日から起算するため、契約の満了日からは計算できません。台帳の期日項目だけで削除可能と判定する設計は、この時点で誤りです。データモデル図に保存年限の項目が独立して置かれているかを見てください。

業種の実績より重い、契約という文書を扱った経験を測る確認質問

面談で聞く質問は三つで足ります。経験がなければ答えが抽象的になります。

• 覚書や変更契約を、原契約とどう紐づけて画面に出しますか
• 自動更新の契約で、更新のたびに履歴をどう残しますか
• 相手方の商号が変わったとき、過去の契約の表示はどうしますか

三つ目に「マスタを更新するので過去分も新しい商号で表示されます」と答える会社には発注しないでください。締結時点の商号は契約書の記載そのもので、書き換えてはならない情報です。マスタの現在値と契約時点の値を分けて持つ、という答えが返るかどうか。ここが業種実績より確実な判別点になります。

工程で分ける契約形態と、取適法が発注側へ課す四つの義務の実務対応

発注の枠組みも、開発会社選びと同じ時期に決めます。IPAと経済産業省の「情報システム・モデル取引・契約書」第二版は2020年12月22日の公表で、受託開発と保守運用の契約書が準委任契約と請負契約の双方に対応します。2020年4月施行の改正民法による契約不適合責任に対応し、プロジェクトマネジメント義務と協力義務も整理されました。最終更新は2025年4月8日です。

要件定義は準委任、実装は請負と分ける工程ごとの契約形態の基準

一括請負で全工程を丸ごと発注する方式は、契約管理システムでは推奨できません。入口の時点で保存要件と権限の階層が固まっておらず、成果物を先に確定できないからです。工程で切り分けてください。

要件定義を準委任で切ると、その成果物を持って実装だけ別の会社へ出す選択肢も残ります。金額は要件定義で全体の一割から二割、確定した仕様を根拠に実装以降を請負で見積り直すのが基本形です。

取適法の適用を受けるのは資本金と従業員数のどちらかが超えた時点

2026年1月1日、下請法の改正法が施行されました。名称は中小受託取引適正化法、通称は取適法です。親事業者は委託事業者へ、下請事業者は中小受託事業者へ、下請代金は製造委託等代金へと用語が変わりました。

プログラム作成を含む情報成果物作成委託では、資本金三億円超または従業員三百人超の側が委託事業者、資本金三億円以下または従業員三百人以下の側が中小受託事業者になります。改正で従業員基準が加わったため、資本金だけを見て対象外と判断していた会社が対象へ入る場合がある。開発会社より自社のほうが大きい構図なら、発注側が規制を受ける立場です。

発注内容の明示と六十日以内の支払期日、遅延利息の年率という義務

委託事業者には、四つの義務と十一の禁止事項が課されています。

1. 給付の内容・代金の額・支払期日・支払方法を書面または電磁的方法で明示する
2. 取引が完了したら記録を書類または電磁的記録として作成し、二年間保存する
3. 検査の有無を問わず、受領した日から起算して六十日以内で支払期日を定める
4. 支払遅延や減額があった場合、年率14.6%の遅延利息を支払う

改正で実務が軽くなった点が一つあります。発注内容の明示は、中小受託事業者の承諾の有無にかかわらず電子メールなどの電磁的方法で足りるようになりました。承諾取得が不要になり、発注書の電子化を進めやすくなっています。禁止事項には手形払等の禁止と、協議に応じない一方的な代金決定の禁止が加わりました。追加要件が出たときに値引きを一方的に通告する運用は違反にあたります。

契約管理システム開発の概算費用と、スコープを削るための判断軸の置き方

金額の全体像は人月単価と工数の掛け算で決まります。単価の相場と内訳の妥当性はシステム開発の費用相場は？内訳・人月単価と見積もりの妥当性を発注者視点で解説に譲り、ここでは契約管理という題材でスコープがどこで跳ねるかに絞ります。

機能ごとの工数配分から見る、最小構成と全部入りでの費用の開き方

下の工数は相場の断定ではなく、複数社の見積りを並べたときにどの構成で桁が変わるかを読む物差しです。

最小構成と連携込みで五倍以上の開きが出ます。生んでいるのは画面の数ではなく連携の本数で、ここを削れば費用は素直に下がる。見積書はこの三段のどこに載るかをまず確認してください。

電子契約はSaaSに残し、管理と検索だけを作るスコープの削り方

スコープを削る最も効く一手は、締結機能を作らないことです。電子署名とタイムスタンプ、本人確認の実装は法令要件も技術要件も重く、自作すると工数も保守負担も跳ね上がります。締結は電子契約サービスに残し、作るのは締結後の管理と検索に限定する。

この分担なら開発対象は台帳・検索・通知・権限・連携の五つへ収まります。市販サービスと重なる部分は出ますが、四条件に該当して開発へ回した領域は残るため投資の意味は消えません。相談は文書管理システム開発で受け付けています。

発注後に破綻する典型パターンと、契約締結前に潰しておく条件の具体

失敗の原因は技術ではなく、決めなかったことです。二つとも契約前に潰せます。

更新通知を作り込んだのに担当者の不在で止まる運用設計の抜け穴

自動更新の解約通知期限を過ぎる事故は、通知機能がないから起きるのではありません。通知は届いていたのに、宛先の担当者が異動や休職で誰も見ていなかった、という形で起きます。通知先を個人のメールアドレス一つに固定した設計が原因です。

契約前に決めるのは、通知先を部署のグループアドレスにすること、一定期間内に対応済みへ変わらなければ上位者へ再通知することの二点です。二段構えを要件へ入れても実装工数はほとんど変わりません。入れ忘れると、後から通知テーブルの設計ごとやり直しです。

保守契約を後回しにして改修が止まる例と、契約前に決める運用範囲

開発費だけを合意して稼働させ、保守契約を後回しにする発注が一定数あります。起きるのは、法令改正や連携先のAPI仕様変更のたびに見積りと稟議が必要になり、対応が数か月遅れる事態です。契約管理は外部要因で手が入る頻度が高く、影響が直に出ます。

開発契約と同時に、年額の保守範囲を障害対応・軽微な改修の年間工数枠・法令改正への追随の三つに分けて合意してください。三つ目を明記しないと、電子帳簿保存法の要件変更が追加開発として毎回見積りに乗ります。工数枠は月あたり一人日程度から始め、翌年に調整すれば足ります。

よくある質問

発注の検討でよく寄せられる質問に、判断できる粒度で答えます。

契約管理システムをスクラッチ開発するといくらかかりますか？

費用は人月単価と工数の掛け算で決まり、工数を動かすのは主に連携先の本数です。台帳・検索・期日通知だけの最小構成なら三から五人月、承認フローと権限を加えて八から十二人月、基幹と電子契約サービスの双方向連携まで含めると十八から二十五人月が、見積りを読む物差しになります。件数は移行費に効くだけなので、依頼時は連携先の一覧を先に渡してください。

開発会社は何社に相見積りを取るのが妥当ですか？

三社が上限です。四社目以降を足しても提案の質は上がらず、比較と面談の時間だけが伸びます。契約管理や文書管理の実績がある会社を二社、既存の基幹システムを構築した会社を一社にすると、技術面と既存資産の両面から提案が揃います。ただし連携先の本数・移行対象の件数・権限の階層・保存要件・稼働環境の五項目を揃えた依頼書が前提で、これがない三社比較は金額の意味を持ちません。

電子契約サービスと契約管理システムは別々に用意すべきですか？

締結は電子契約サービス、締結後の管理は契約管理側という分担が基本形です。電子署名やタイムスタンプ、本人確認の実装は法令要件が重く、自作すると工数と保守負担が跳ねます。締結完了はWebhookで取り込んでください。クラウドサインの場合、Web APIが使えるのはスタンダード、コーポレート、ビジネス、エンタープライズの各プランで、通知先設定数は最大二十個です。

契約管理システムの開発期間はどれくらい見ておくべきですか？

最小構成で三か月から四か月、連携を含む構成で六か月から九か月が目安です。読み違えやすいのは開発期間ではなく、要件定義に入る前の社内調整のほう。台帳の項目と保存年限は法務や総務、連携方式と稼働環境は情報システム部門が持つため、両者の合意に一か月前後かかる例が珍しくありません。決裁の周期が二週間を超える体制だと、要件定義の期間もそのまま伸びます。

開発会社に渡す要件は、どこまで固めてから声をかけるべきですか？

固めるのは、各社の前提がずれると金額が動く五項目だけで足ります。連携先の本数と向き、移行対象の件数と形式、権限の階層、保存要件、稼働環境です。画面のレイアウトや帳票の書式は決めずに出したほうが良い提案が集まります。決めきれない項目は空欄にせず「未定・提案を求める」と明記してください。

関連記事

• 契約書管理システムとは？機能・選び方と比較のポイント・導入判断を解説：市販サービスの機能一覧と選定基準です。
• 契約書管理システムの費用は課金軸で決まる｜件数課金と定額型の三年総額を比較：開発費との損益分岐を出す材料です。
• 契約管理台帳のシステム化｜項目設計とExcelが限界になる条件・移行の手順：台帳の項目と行構造の決め方です。
• システム開発の見積もりとは？見積書の見方・依頼方法・相見積もりの比較を発注者視点で解説：見積書の内訳と単価の判断方法です。
• 電子契約システムの比較と選び方とは？認証方式・連携・費用の判断軸を解説：締結側に残すサービスの選び方です。