システム開発の契約書チェックポイント｜受け取ったら確認する9項目

システム開発の契約書を受け取ったものの、専門用語が多く「どこを見ればいいのか分からない」という発注者は少なくありません。この記事では、契約形態そのものの解説ではなく、契約書を受け取ってから署名するまでに何を確認するかという実務に絞って、必ずチェックする9項目を一つずつ整理します。危険な条項やあいまい表現の見抜き方、発注側に不利になりがちな点もあわせて紹介します。

※本記事は契約書の一般的な読み方の解説です。制度・法律の記述は一般論であり、実際の契約は個別事情により結論が変わります。重要な契約は弁護士などの専門家にご確認ください。

まず全体像：契約書チェックの9項目

契約書は分量が多く、最初から順に読むと途中で力尽きます。先に「何を確認するのか」の地図を持っておくと、重要な条項を落とさずに読めます。システム開発の契約書で必ず確認したいのは、次の9項目です。

#	確認項目	一言で言うと
1	業務範囲・成果物の定義	何をどこまで作るのか
2	納期・検収条件	いつ完成とみなすのか
3	金額・支払い条件	いくらを、いつ払うのか
4	追加費用が発生する条件	どうなると金額が増えるのか
5	知的財産権・ソースコードの帰属	成果物は誰のものか
6	契約不適合責任・保証期間	不具合を無償で直す範囲
7	保守の範囲	納品後の面倒を誰が見るか
8	中途解約・再委託	途中でやめられるか、誰が作るか
9	秘密保持（NDA）	渡した情報をどう守るか

以下、それぞれ「見るべき点」と「危険なサイン」をセットで解説します。契約書に該当条項が見当たらない場合は、その項目自体が抜けている可能性が高く、追記を求めるべきサインです。

1. 業務範囲・成果物の定義

最初に確認すべきは、「何を、どこまで作るのか」が具体的に書かれているかです。ここがあいまいだと、後続のすべての項目（納期・金額・検収）が定まりません。

チェックの観点は次のとおりです。

• 成果物が「システム一式」ではなく、機能一覧・画面一覧・帳票一覧などで特定されているか
• 要件定義書や仕様書が契約書に別紙として添付・参照されているか
• 対応する動作環境（対応ブラウザ、iOS/Android、既存システムとの連携先）が明記されているか
• データ移行・初期設定・操作マニュアル作成が「含む／含まない」で書かれているか

危険なサインは「一式」「等」「必要な機能」といった包括的な表現です。「顧客管理に必要な機能一式」と書かれていても、開発側と発注側で「必要」の範囲が食い違えば、後から「それは範囲外」と言われます。範囲は文章で握るのではなく、別紙の一覧で特定するのが安全です。

2. 納期・検収条件

納期そのものより重要なのが、**「何をもって完成（検収合格）とするか」**の基準です。検収の定義があいまいだと、支払いのタイミングも、いつまで直してもらえるかも決まりません。

確認したいのは次の点です。

• 検収の期間（例：納品から14日以内など）が定められているか
• 検収の合格基準（要件定義書どおりに動作すること等）が具体的か
• 検収期間内に発注側が何も言わないと「合格とみなす（みなし検収）」条項があるか
• 不合格の場合の修正対応・再検収の手順が書かれているか

「みなし検収」は開発側に有利な条項です。忙しくて確認が遅れただけで自動的に合格扱いになると、後から不具合が見つかっても対応してもらいにくくなります。みなし検収を受け入れる場合でも、期間が短すぎないか（最低でも実務で触れる日数があるか）を確認しましょう。

3. 金額・支払い条件

金額は総額だけでなく、支払いのタイミングと分割の条件まで見ます。開発は数ヶ月かかることが多く、着手金・中間金・検収後の残金といった分割払いが一般的です。

支払い方式	内容	発注側の注意点
検収後一括	完成・検収後にまとめて支払う	発注側に有利だが会社側が敬遠しがち
着手金＋残金	契約時に一部、検収後に残り	一般的。着手金の割合を確認
工程ごとの分割	要件定義・開発・テスト等で分割	各支払い前に何が納品されるか要確認

• 着手金の割合が高すぎないか（総額の大半を前払いする形になっていないか）
• 各支払いが「何の完了」に紐づくのか（前払いなのか、成果物と引き換えなのか）
• 消費税・振込手数料の扱い、支払い期日（月末締め翌月末払い等）が明記されているか
• 遅延損害金の利率が過大でないか

危険なサインは、成果物の引き渡し前に総額の大部分を支払う設計です。前払い比率が高いほど、途中で開発が滞ったときに発注側がリスクを負います。

4. 追加費用が発生する条件

トラブルで最も多いのが「追加費用」をめぐる認識のズレです。契約書に**「どういう場合に、いくら追加になるのか」**の条件が書かれているかを確認します。

• 仕様変更・追加要望が発生したときの単価や算定方法（人日単価など）が明記されているか
• 「軽微な変更は無償、それを超えると別途見積り」といった線引きがあるか
• 追加作業に着手する前に、書面（見積書・変更合意書）で合意する手順が定められているか

追加費用の条件があいまいなまま進むと、開発の途中で「その修正は追加です」と言われても、妥当な金額か判断できません。事前に単価と手順が決まっていれば、追加が発生しても金額を予測・コントロールできます。総額を確定させたい発注者にとっては、この条項の精度が予算管理の要になります。関連する読み方は「システム開発の見積もりの見方」でも解説しています。

5. 知的財産権・ソースコードの帰属

納品後に自社でシステムを育てていけるかを左右するのが、成果物の権利が誰に帰属するかです。ここを見落とすと、費用を払って作ったのに自由に改修できない事態が起こります。

• 成果物の著作権が発注側に譲渡されると明記されているか
• 著作権法27条（翻案権）・28条（二次的著作物の利用に関する権利）を含めて譲渡すると書かれているか
• 開発会社の著作者人格権を「行使しない」旨の条項があるか
• 開発会社が元から持つ汎用部品（既存ライブラリ等）の扱いが整理されているか

著作権の譲渡は「移転する」と一言あるだけでは不十分な場合があります。27条・28条を明示的に含めないと、改変や派生開発の権利が開発会社に残ることがあるためです。譲渡がないと他社への乗り換えや自社改修が難しくなり、ベンダーロックインにつながります。この論点は「ベンダーロックインとは」で詳しく扱っています。

6. 契約不適合責任・保証期間

契約不適合責任（旧・瑕疵担保責任）は、納品物が契約内容に適合しない（不具合・仕様漏れ）場合に、無償で直してもらえる範囲と期間を定める条項です。2020年の民法改正で名称が変わりました。

確認する点は次のとおりです。

• 対応期間（例：検収後6ヶ月・1年など）が定められているか
• 対応の内容（修補・代金減額・損害賠償・解除のどこまで請求できるか）が書かれているか
• 「発注側の責めに帰すべき事由」による不具合が除外される範囲が過大でないか
• 期間の起算点が「納品時」か「検収完了時」か

危険なサインは、保証期間が極端に短い、あるいは責任を全面的に免除する条項です。逆に、契約不適合責任の条項自体が抜けている契約書も要注意です。改正民法では期間の定めがない場合、不適合を知った時から1年以内の通知が原則ですが、契約で明確に定めておくほうがトラブルを避けられます（具体的な扱いは個別事情によります）。

7. 保守の範囲

システムは納品して終わりではなく、納品後の不具合対応・軽微な修正・問い合わせ対応をどうするかを決めておく必要があります。開発契約と保守契約を分けるのが一般的です。

区分	含まれることが多い	別料金になりやすい
契約不適合対応	契約内容に反する不具合の無償修正	―
保守（月額等）	障害監視・軽微な修正・問い合わせ対応	大きな機能追加
追加開発	―	新機能・大幅な仕様変更

• 保守契約の有無、月額費用、対応時間帯・対応範囲が明記されているか
• 「契約不適合責任で無償になる不具合」と「有償保守で対応する不具合」の線引きがあるか
• 保守を契約しない場合、納品後の問い合わせがどう扱われるか

保守条件を確認しないまま契約すると、納品直後の小さな修正でも都度見積りになり、想定外のコストがかかることがあります。

8. 中途解約・再委託

途中で開発が思うように進まないときに、契約を解約できるか、その場合の費用精算はどうなるかは重要です。あわせて、実際の開発を誰が行うのか（再委託）も確認します。

• 中途解約ができる条件と、解約時の出来高（着手済み分）の精算方法が定められているか
• 一方的に不利な違約金・解約金が設定されていないか
• 契約解除の条件（債務不履行時など）が双方公平か
• 開発の再委託（下請けへの外注）が可能か、可能な場合に発注側の承諾が必要か

再委託が無制限に認められていると、誰が作っているのか把握できず、品質や秘密情報の管理が見えにくくなります。再委託には事前承諾を求める、または再委託先にも同等の秘密保持義務を課す条項があると安心です。

9. 秘密保持（NDA）

システム開発では、発注側の顧客情報・売上データ・業務ノウハウを開発会社に渡します。これらを守るのが秘密保持条項、または別途締結する**NDA（秘密保持契約）**です。

• 秘密情報の定義と、保持義務の**期間（契約終了後も一定期間続くか）**が明記されているか
• 個人情報を渡す場合、その取り扱い・管理方法が定められているか
• 契約終了時に、渡したデータの返却・破棄の手順があるか
• 再委託先にも同等の義務が及ぶか

秘密保持は契約書内の一条項として入っている場合と、独立したNDAとして結ぶ場合があります。渡す情報の機微度が高いなら、開発契約前の商談段階でNDAを結ぶのが安全です。詳しくは「NDA（秘密保持契約）とは」を参照してください。

あいまい表現・危険な条項の見抜き方

契約書のリスクは、難しい専門用語よりもあいまいな言い回しに潜みます。以下のような表現が出てきたら、具体化を求めるサインです。

• 「一式」「等」「その他必要な作業」——範囲が特定されていない
• 「別途協議のうえ定める」——重要事項が先送りされている
• 「甲が指定する期間内に」——期間の数値が入っていない
• 「軽微な」「相当の」「速やかに」——判断基準があいまい
• 「乙は一切の責任を負わない」——責任の全面免除で発注側に不利

これらは必ずしも不当ではありませんが、放置すると解釈が開発側に委ねられ、発注側が不利になりがちです。気になる表現には付箋を貼り、「この場合はどうなりますか」と一つずつ確認しましょう。口頭の回答で納得したら、その内容を契約書か覚書に反映してもらうのが確実です。

例：契約書に「顧客管理に必要な機能一式を開発する」とだけあったケースでは、発注側は検索やCSV出力も当然含まれると考えていた一方、開発側は基本の登録・閲覧のみを想定していた、という食い違いが起こりえます。別紙の機能一覧で「検索」「CSV出力」を明記していれば、この認識差は契約の時点で解消できます。あいまい表現は、後から揉めやすい部分ほど具体化しておくのが原則です。

発注側に不利になりがちなポイント

契約書は開発会社側が用意することが多く、意識しないと開発側に有利な設計になりがちです。とくに次の点は発注側からチェックしておきたい箇所です。

論点	不利になりやすい書き方	望ましい確認
検収	みなし検収の期間が極端に短い	実務で触れられる日数を確保
支払い	前払い比率が高い	成果物の引き渡しと連動
著作権	「移転する」のみで27・28条の記載なし	27・28条を含めて譲渡
保証	契約不適合責任の期間が短い/免除	検収後6ヶ月〜1年を目安に
損害賠償	上限が青天井、または過小	双方に公平な上限設定
解約	出来高精算の定めがない	精算方法を明記

すべてを一度に交渉する必要はありません。優先度の高い「業務範囲・検収・著作権・追加費用」から確認し、疑問点を潰していくのが現実的です。

専門家（弁護士）に見てもらう判断

契約書のすべてを自分で判断する必要はありません。次のようなケースでは、契約前に弁護士へ相談する価値が高くなります。

• 金額が大きい、または長期にわたる契約
• 業務の根幹を担う、止まると事業に影響するシステム
• 独自性が高く、知的財産権の帰属が特に重要な開発
• 損害賠償・解約条項に不安がある、または相手の提示条件を大きく修正したい

一方で、小規模な開発であっても、著作権の譲渡（27・28条を含む）と検収条件だけは自分でも必ず読み、疑問を残さないことをおすすめします。専門家に依頼する場合も、この記事の9項目を事前に整理して渡すと、相談がスムーズに進みます。なお、請負と準委任という契約形態そのものの違いは「システム開発の契約｜請負と準委任の違い」で解説しています。

一律料金だと契約書の不安が減る

契約書チェックの負担が重くなる大きな要因は、「総額がいくらになるか」「追加でいくら請求されるか」が契約段階で読めないことにあります。金額があいまいなほど、支払い条件・追加費用・検収の条項を慎重に読み込まなければなりません。

D-oneApp は料金をスタンダード一律100万円／プロ一律200万円とし、追加費用なし・着手前に総額が確定する形にしています。さらに成果物（ソースコード）の権利は発注側に渡すため、著作権の帰属をめぐる条項の不安も減ります。金額と権利の前提が固定されていれば、契約書で神経を使うべき範囲は「業務範囲」と「検収条件」に絞られ、確認の負担が軽くなります。

もちろん、料金体系にかかわらず、契約書を読んで納得してから署名することは大切です。一律料金は、その確認作業をシンプルにするための一つの選択肢です。

まとめ

システム開発の契約書は、受け取ってから署名するまでに次の9項目を順に確認すると、重要な条項を落とさずに読めます。

• 業務範囲・成果物の定義は「一式」でなく一覧で特定されているか
• 検収条件（合格基準・期間・みなし検収）が明確か
• 金額・支払いのタイミングと前払い比率は妥当か
• 追加費用の条件（単価・合意手順）が定められているか
• 著作権が27・28条を含めて発注側に譲渡されるか
• 契約不適合責任の範囲と期間が適切か
• 保守の範囲と、無償・有償の線引きがあるか
• 中途解約時の精算・再委託の扱いが公平か
• 秘密保持（NDA）で渡した情報とデータの扱いが守られるか

あいまいな表現は必ず具体化を求め、金額が大きい契約や重要なシステムでは弁護士への相談も検討してください。制度・法律の扱いは個別事情で変わるため、最終判断は専門家に確認するのが安全です。契約や進め方に迷ったら、無料相談からお気軽にご相談ください。