システム開発の契約書｜発注者が確認すべき7条項と交渉アクション

ベンダーから契約書ドラフトが送られてきて、「ご確認のうえご署名ください」とメールが添えられている。社内に IT 法務に詳しい人はおらず、自分が押印判断の責任者になっている。一通り読んでみたものの、どこが標準的でどこが危険なのか、自信を持って判断できない——システム開発を発注する事業会社の担当者の方からよく聞かれる悩みです。

困るのは、契約書のチェックリスト記事を読んでも、「項目の存在は確認したが、自社にとって危ないのかどうかが分からない」という不安が残ることです。多くの記事は発注者・受注者の双方に向けた一般解説か、ベンダーに何を要求するかという視点に偏っています。発注者として「自分が何を判断すべきか」「自分が何を守るべきか」「問題があったときどう動くべきか」を一気通貫で扱った記事は、意外なほど見当たりません。

本記事では、発注者の判断軸に焦点を絞り、契約書を確認するときの全体像を 4 つの視点で整理します。具体的には、（1）契約形態の見極め方、（2）必ず確認すべき 7 つの条項、（3）競合記事がほぼ触れない「発注者側の協力義務」、（4）アジャイル契約の実務運用、そして問題条項を発見した後の交渉アクションまでをカバーします。経済産業省・IPA が公開している「情報システム・モデル取引・契約書（第二版）」と「アジャイル開発外部委託モデル契約」を基準値として参照しながら、現場で使える形で解説します。

なお、より広範な条項チェックの一覧については、姉妹記事のシステム開発の契約書チェックポイント10選も合わせてご覧ください。本記事は「発注者の判断軸と交渉アクション」に振り切った内容ですので、両記事を補完的にお使いいただけます。

—Free Download / 資料ダウンロード

システム開発における基本契約書の雛形

この資料でわかること

システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。

こんな方におすすめです

• システム開発を発注する際にどのような基本契約を結ぶのか興味がある
• システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
• システム開発を発注する側にどのような義務が生ずるのか気になる

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

発注者がシステム開発契約書を確認するときに直面する3つの判断不安

最初に、発注者の方がシステム開発契約書を前にしたときに抱える典型的な不安を 3 つ整理しておきます。読者ご自身がどの不安を抱えているかを言語化することで、本記事のどこを重点的に読むべきかが見えてきます。

「標準的な条項」と「危険な条項」の見分けがつかない

最大の不安は、目の前の契約書ドラフトの記述が、業界として標準的なのか、それとも自社にとって不利なのかを判断する基準を持っていないことです。たとえば「契約不適合責任の期間は引渡し後 1 年とする」と書かれていたとき、これが妥当なのか短いのかを瞬時に判断するには、何かしらの基準点が必要です。

判断軸を持つための最も確実な方法は、経済産業省・IPA が公開している「情報システム・モデル取引・契約書（第二版）」を基準値として参照することです。第二版は 2020 年 12 月 22 日に公開され、2020 年 4 月施行の改正民法に対応しています。ユーザ企業（発注者）と IT ベンダ（受注者）のどちらにもメリットが偏らないよう、専門家・業界団体・法律家の議論を経て中立的な立場で作成された雛形であり、「業界標準の参照点」として使える数少ない公的資料です（IPA: 情報システム・モデル取引・契約書（第二版））。

法務担当者がいない、いても IT に詳しくない

中小〜中堅企業ではそもそも法務担当者がいない、あるいは法務がいても契約書のレビュー業務が多岐にわたり、システム開発契約特有の論点（検収基準、知的財産権の帰属、再委託の可否など）に深く踏み込めないケースが少なくありません。

この状況下で重要なのは、「すべての条項を完璧にレビューする」ことではなく、「発注者として最低限押さえるべき優先順位の高い条項に絞って深く確認する」アプローチです。本記事の H2-3 で解説する 7 条項は、まさにこの優先順位に沿って絞り込んだものです。

問題があってもベンダーに気を使って指摘しづらい

3 つ目の不安は、問題のある条項を見つけても、それを切り出すこと自体に心理的な抵抗があることです。「これからお世話になるベンダーさんに、いきなり契約書の修正を依頼してよいのか」「指摘したことで関係が悪くなったらどうしよう」といった葛藤です。

ここで知っておきたいのは、業界の慣行として、契約書ドラフトはベンダー側が用意し、発注者側が確認・指摘して修正していくキャッチボールが標準的な進め方であるということです。指摘自体は失礼な行為ではなく、むしろ「事前の合意形成」という双方にメリットのあるプロセスです。本記事の H2-6 では、具体的な切り出し方と代替提案の作り方を解説します。

まず契約形態を見極める：請負・準委任・アジャイル契約の違いと発注者の判断軸

契約書の確認に入る前に、まず確認すべきは「自分が今、どの契約形態の契約書を見ているか」です。形態が違えば確認すべき条項も、想定すべきリスクも異なります。

請負契約：完成義務とその対価

請負契約は、ベンダーが「成果物の完成」を義務として負う契約形態です。納期までに約束した仕様を満たすシステムを完成させ、引き渡すことで、契約上の対価を受け取れます。納期遅延や品質不足があれば、ベンダーは契約不適合責任を負います。

発注者の視点では、「成果物を最終的に手にする確約」が得やすい形態です。一方で、仕様が固まっていない段階で請負を結ぶと、開発途中で「これは仕様書に書いていない、追加費用です」というやり取りが頻発しやすくなります。仕様が明確に決まっている案件・追加開発の波が少ない案件には適していますが、新規事業や DX のように仕様変更が前提となる案件では摩擦が起きやすい形態です。

準委任契約：プロセスへの対価

準委任契約は、ベンダーが「業務の遂行」そのものを義務として負う契約形態です。完成責任ではなく、善管注意義務（専門家として注意を尽くして業務を遂行する義務）が中心となります。

発注者の視点では、仕様変更を柔軟に受け入れやすい形態である一方、「成果物の完成」が契約上保証されないため、発注者自身が要件を主体的に定め、ベンダーの作業内容と進捗をコントロールする責任が大きくなります。準委任の典型例は、要件定義フェーズや、後述するアジャイル開発、運用保守業務などです。

請負と準委任の違い・選び方をより詳しく確認したい方は、システム開発の請負契約と準委任契約の違いと選び方を参照してください。SES や派遣との関係を整理したい場合は、SESとは？派遣・請負・準委任との違いもあわせてどうぞ。

アジャイル開発契約：IPAモデルが推奨する準委任ベース

アジャイル開発を採用する場合、IPA は「準委任契約」を推奨しています。これは、アジャイル開発の本質が「仕様を固めずに進めながら価値を最大化する」ことにあり、請負契約の「成果物を事前に確定する」前提と相性が悪いためです。

2025 年 4 月 8 日にアップデートされた IPA「アジャイル開発外部委託モデル契約」では、ユーザ企業がプロダクトオーナー（PO）を選任し、開発チームに必要な情報や意思決定を適時に提供することが明確化されています。発注者には主体的な参画が求められる前提で契約が組まれている点が、請負との大きな違いです（IPA: 情報システム・モデル取引・契約書（アジャイル開発版））。

フェーズで契約を分ける「多段階契約」の考え方

システム開発の現場でよく採用されるのが、フェーズごとに契約形態を変える「多段階契約」です。たとえば次のような分け方が代表的です。

• 要件定義フェーズ → 準委任契約（仕様未確定のため、完成責任を負わせるのが不合理）
• 設計・実装フェーズ → 請負契約（仕様が固まったので、完成責任を持たせる）
• 運用・保守フェーズ → 準委任契約（継続的な業務支援のため）

契約書ドラフトを受け取ったら、まず「これは多段階のどこに該当する契約か」「他のフェーズはどう契約する想定か」を確認しましょう。一括請負で見積もりが提示されている場合、要件定義段階のリスクをベンダーが上乗せしていることも多く、結果として割高になりやすい傾向があります。

発注者が必ず確認すべき7つの条項

ここからは、発注者として優先順位高く確認すべき 7 つの条項を、それぞれ「危険な記述パターン」「標準的な記述パターン」「判断軸」の 3 点でまとめます。

1. 成果物の範囲と仕様の特定

最も重要な条項です。「成果物の範囲が曖昧」だと、開発中の「これは仕様に含まれる／含まれない」論争の温床になります。

• 危険な記述パターン: 「別途定める仕様書に基づき、システムを開発するものとする」とだけ書かれ、仕様書が契約書に添付されていない、または曖昧
• 標準的な記述パターン: 仕様書（要件定義書）が契約書の別紙として添付され、「本契約における成果物は、別紙○○に記載の仕様を満たすシステムとする」と明示
• 判断軸: 仕様書が別紙として綴じ込まれているか、その仕様書のバージョン・日付が明示されているか、「仕様変更があった場合の手続き」が定められているかを確認します

2. 検収基準とみなし承認条項

検収基準は、システム開発契約に固有の論点です。動作はするが「思っていたものと違う」という場面は珍しくなく、何をもって「合格」とするかが曖昧だと深刻なトラブルになります。

• 危険な記述パターン: 「成果物の納入後 ◯ 日以内に異議を申し立てない場合は、検収を完了したものとみなす」と短い期限（3 日・5 日など）が設定されている
• 標準的な記述パターン: 「検収期間は 14 日間（または 2 週間）」とし、検収基準（テストケースに合格すること等）が別紙で明示されている
• 判断軸: 検収期間が社内の承認プロセスに見合った長さか、検収基準が客観的な指標（受け入れテストの合格基準）で定義されているかを確認します。みなし承認条項がある場合は、期間を延長交渉する余地があります

3. 契約不適合責任（旧瑕疵担保）の期間と範囲

2020 年 4 月の改正民法施行に伴い、従来の「瑕疵担保責任」は「契約不適合責任」という概念に整理されました。経産省・IPA のモデル契約書（第二版）も契約不適合責任の規定に修正されています（イノベンティア: 情報システム・モデル取引・契約書 民法改正対応版の公開について）。

• 危険な記述パターン: 「引渡し後 3 ヶ月以内に発見した契約不適合についてのみ、ベンダーは無償補修の責任を負う」と、極端に短い期間設定
• 標準的な記述パターン: 「引渡し後 1 年間（または 6 ヶ月）」とし、無償補修・代替物の引渡し・代金減額・損害賠償・契約解除のうち、どの請求が可能かが整理されている
• 判断軸: 期間は最低 1 年が一つの目安です。短い場合は交渉余地があります。範囲については「責任を限定する条項」（請求できる対応の種類を狭める記述）が含まれていないかを確認します

4. 知的財産権・著作権の帰属

意外と見落とされがちですが、ソースコード・データベース設計書・UI デザインなどの成果物の著作権は、原則として「制作した側（ベンダー）」に発生します。これを発注者に移転するには、契約書での明確な合意が必要です。

• 危険な記述パターン: 「成果物の著作権はベンダーに帰属し、発注者には使用権のみが許諾される」と、利用範囲が制限される条項
• 標準的な記述パターン: 「成果物の著作権（著作権法 27 条・28 条の権利を含む）は、最終代金の支払いと同時に発注者に移転する」と明確に移転を規定
• 判断軸: 自社で改修・再開発する可能性があるか、システムを他社に売却・利用許諾する可能性があるかを考えると、著作権の帰属方針が判断できます。ただし汎用的なライブラリやフレームワーク部分については、ベンダー側が再利用できるよう、特定の部分のみベンダー帰属とする折衷案も実務上は珍しくありません

知的財産権の帰属についてより詳しく知りたい方は、システム開発の著作権は誰のもの？発注者が知っておきたい権利帰属と契約のポイントを参照してください。

5. 損害賠償の上限と範囲

損害賠償条項は、契約書で発注者が最も注目すべき条項の一つです。万一トラブルが発生した場合に、いくらまで請求できるかが決まる条項です。

• 危険な記述パターン: 「損害賠償の上限は、本契約に基づきベンダーが受領した報酬額の 30% を上限とする」と低い上限設定
• 標準的な記述パターン: 「損害賠償の上限は、本契約に基づきベンダーが受領した報酬額を上限とする」（受領金額相当が業界の一般的な水準）
• 判断軸: 上限金額がベンダー受領報酬額相当か、それより低いかを確認します。間接損害（逸失利益・営業損害）が除外されている場合、自社の事業上の影響規模によっては上限の引き上げ交渉を検討します

損害賠償条項のリスク管理について詳細は、システム開発の損害賠償・リスク管理ガイドを参照してください。

6. 再委託の可否と条件

ベンダーが受注した業務を、さらに別の会社に再委託する（外注の外注）ことを許容するか、または事前承認制にするかを定める条項です。

• 危険な記述パターン: 「ベンダーは事前の通知なく業務の全部または一部を第三者に再委託できる」と、無制限の再委託を認める記述
• 標準的な記述パターン: 「ベンダーが業務を第三者に再委託する場合、事前に発注者の書面承諾を得るものとする」と事前承認制
• 判断軸: 機密情報・個人情報を扱うシステムでは、再委託先の管理が情報漏洩リスクに直結します。事前承認制に変更し、再委託先にも本契約と同等の機密保持義務を課す条項を追加することを検討します

再委託に関連して、契約締結前の段階では NDA（秘密保持契約）の締結も重要です。詳しくはNDA（秘密保持契約）とシステム開発委託｜発注前に確認すべき締結ポイントをご覧ください。

7. 契約解除条件と中途解約時の費用精算

最後に、トラブルや方針変更で契約を途中で終わらせる場合のルールを定める条項です。

• 危険な記述パターン: 「発注者の都合による中途解約の場合、未完成分も含めた契約金額の 100% を支払うものとする」と、ベンダー側に有利すぎる精算ルール
• 標準的な記述パターン: 「発注者の都合による中途解約の場合、解約日までの履行済み業務に対する報酬を、発注者は支払うものとする」（履行済み相当額の精算）
• 判断軸: 中途解約時に「何に対して」「いくら払うか」のルールが具体的に定められているかを確認します。アジャイル開発・準委任契約では、スプリント単位での精算ルールが望ましく、後述の H2-5 で詳しく解説します

競合記事が触れない「発注者側の義務」 — 協力義務・対応期限・意思決定責任

ここからが本記事の最大の差別化ポイントです。多くの契約書解説記事は「ベンダーへの要求事項」中心に書かれていますが、実は発注者自身も契約書上で果たすべき義務（協力義務）を負っており、この義務を怠ると損害賠償を請求されるケースさえ存在します。

なぜ発注者の協力義務が契約書で重要なのか（判例ベース）

システム開発の裁判例では、プロジェクトの失敗が「ベンダーのプロジェクトマネジメント義務違反」だけでなく、「発注者の協力義務違反」によるものと判断された事例が複数あります。

代表的な判例が、札幌高裁平成 29 年 8 月 31 日判決（旭川医大対 NTT 東日本事件）です。仕様確定後も大量の追加要望を出し続けた発注者（旭川医大）に協力義務違反があったとして、ベンダー（NTT 東日本）への 14 億 9,744 万 8,554 円の支払いを命じる判決が下されました（イノベンティア: 旭川医大対 NTT 東日本事件）。

東京地裁平成 9 年 9 月 24 日判決でも、ユーザー側にも信義則上の協力義務があることが明示されています（弁護士法人クラフトマン: システム開発のプロジェクトマネジメント義務と協力義務）。発注者の協力義務とは、具体的には次のような内容を指します。

• 要望する機能を適時に明確に伝えること
• ベンダーからの質問・確認への適時の回答
• 要件定義や設計に必要な資料・データの提供
• テストを実行するための環境の準備
• 仕様・機能・画面・帳票等の最終決定を遅滞なく行うこと

つまり、発注者にも「ベンダーが業務を遂行できる環境を整える」責任があり、これを怠るとプロジェクト失敗の責任を負う可能性があるのです。契約書ではこの協力義務を、具体的な行動レベルで合意しておくことが重要です。

仕様確定の期限と回答遅延のリスク

開発中、ベンダーから「この画面の仕様について、A 案 / B 案のどちらにしますか」「この項目のデータ型は何にしますか」といった確認が繰り返し届きます。発注者の回答が遅れると、ベンダーは作業を止めるか、仮の判断で進めるしかなくなり、結果として手戻り・納期遅延が発生します。

契約書で確認したいのは、「発注者の回答期限」が定められているかです。たとえば「ベンダーからの確認事項に対し、発注者は ○ 営業日以内に回答する」「回答が ○ 営業日を超える場合、納期はその超過日数分延長される」といった条項があれば、発注者・ベンダー双方の責任範囲が明確になります。

テスト対応・検収判断のリードタイム

検収フェーズでは、発注者側で受け入れテストを実施する必要があります。このテスト実施期間と、検収判断（合格・差し戻し）に必要な日数を、契約書または別紙で具体的に取り決めておくと、後の摩擦を防げます。

注意したいのは、検収期間の長さは社内の承認プロセス（誰が確認し、誰が承認するか）と整合させる必要があることです。社内のテスト体制が整わない状態で短い検収期間を設定すると、結果として「みなし承認」されてしまい、後から不具合を見つけても対応が困難になります。

意思決定の責任者と決裁スピードの取り決め

発注者の社内体制も契約書に反映できます。誰が意思決定の責任者で、どの範囲の決裁権を持つか、そして意思決定にかかる標準的なリードタイムを契約書または別紙の運用ルールで明示しておくことで、ベンダーは発注者の意思決定スピードを前提に計画を組めます。

特にアジャイル開発の場合、IPA モデル契約書ではプロダクトオーナー（PO）の選任がユーザ企業の責務として明記されており、PO の権限範囲・決裁スピードが開発スピードを直接左右します（IPA: アジャイル開発外部委託モデル契約）。

アジャイル契約で押さえる実務運用 — IPAモデル契約書（2025年版）ベース

ベンダーから「アジャイル開発で進めましょう」と提案されたものの、契約書は読んでみたが何が変わるのか実感が持てない、という相談はよく受けます。アジャイル開発を準委任契約で進める場合に押さえておきたい実務ポイントを、2025 年 4 月にアップデートされた IPA「アジャイル開発外部委託モデル契約」に沿って解説します。

IPAモデル契約書が前提とする「PO はユーザ企業」の意味

IPA モデル契約書では、ユーザ企業がプロダクトオーナー（PO）を選任し、開発チームに必要な情報や意思決定を適時に提供することがユーザ企業の役割として明確化されています（IPA: 情報システム・モデル取引・契約書（アジャイル開発版））。

これは発注者にとって極めて重要な意味を持ちます。PO は単なる「窓口担当」ではなく、開発の優先順位を決め、ステークホルダーとの調整を行い、プロダクトの方向性を決定する責任者です。「とりあえず社員 A さんを窓口にして、何かあれば相談しましょう」というレベルでは、IPA モデル契約書が想定する PO の役割を果たせません。契約書の別紙で PO の役割・権限・決裁範囲を明示しておきましょう。

スプリント単位の成果確認をどう契約に落とすか

アジャイル開発は通常、1〜4 週間のスプリント単位で開発を進めます。各スプリントの終了時点で「成果物のレビュー（スプリントレビュー）」と「振り返り（レトロスペクティブ）」を行うのが一般的です。

契約書または別紙で確認したいのは、次のポイントです。

• スプリントの長さ（例: 2 週間）
• 各スプリント終了時のレビュー対象（動くソフトウェアの一部・ドキュメント等）
• スプリントごとの請求・支払いタイミング（月次集約で請求するなど）
• スプリントの成果が想定と異なった場合の調整プロセス

これらを契約段階で明示しておくと、発注者として「今のスプリントで何を確認すべきか」「どこで NG を出して方針修正できるか」が明確になります。

バックログ変更と追加費用の線引き

アジャイル開発では、開発を進めながら要望（バックログ）を追加・変更していきます。準委任契約のため「契約書記載の仕様」が固定的に決まっていないという特徴がある一方、「いくらでも変更できる」と発注者が誤解すると、見込みより費用が膨らむ事態になります。

契約書または別紙で、次のルールを取り決めておくことを推奨します。

• バックログの追加は誰の判断で行えるか（PO の権限範囲）
• ストーリーポイント（作業ボリュームの単位）と、1 ストーリーポイントあたりの工数の目安
• スプリントの開発キャパシティ（1 スプリントで対応できる総ストーリーポイント数の目安）
• キャパシティを超える追加要望が出た場合の対応（次スプリントへの繰り延べ／契約期間の延長／追加契約の締結）

このルールを発注前に握っておけば、「想定より大きな機能が必要だと分かった」「優先順位を入れ替えたい」といった変更を、追加費用との関係を含めて柔軟に判断できます。

中途解約時の精算ルール

アジャイル開発の魅力の一つは、開発の途中で「思ったより事業性が見込めない」「方針を大きく転換したい」と判断したとき、柔軟に止められる点です。ただし契約書で精算ルールを定めていないと、解約時のトラブルになります。

IPA モデル契約書に沿った標準的な精算ルールは、「解約日までの履行済みスプリントに対する報酬を支払う」というものです。月額報酬制の場合は「解約月の月額報酬を日割り精算する」形式も実務上は採用されます。発注者として、契約書のどこに中途解約条項があり、精算がどう計算されるかを確認しておきましょう。

問題条項を見つけたらどう動くか — ベンダーとの交渉アクション

ここまで読んでいただいた方は、契約書を確認する判断軸を一通り手にされたはずです。しかし、実際に問題のある条項を見つけたとき、どうベンダーに伝えるか、どんな代替案を提示するか、という次のステップで止まってしまう方が少なくありません。最後の差別化章として、交渉アクションを具体的に解説します。

切り出しの基本：「リスクに対する懸念」として伝える

問題条項を見つけたとき、最もやってはいけないのは「この条項は不公平だ」「この条件は受け入れられない」と感情的・対立的に切り出すことです。これからプロジェクトを共に進める関係性を最初から損ねます。

推奨する切り出し方は、「リスクに対する懸念」として伝えるアプローチです。たとえば次のような形です。

• 「契約不適合責任の期間が 3 ヶ月とありますが、当社のシステム運用負荷を考えると、不具合が発見されるタイミングが半年後になる可能性があります。期間を 1 年に延長していただくことは難しいでしょうか」
• 「損害賠償の上限が報酬額の 30% とありますが、本システムの停止が当社の事業に与える影響を考えると、上限を引き上げる余地はありますか。何か御社側で根拠としている水準があればご共有いただけると助かります」

「自社の状況と懸念」を述べたうえで「相手の事情も尊重して聞く」スタイルを取ると、ベンダー側も冷静に応じやすくなります。

業界慣行で固定的な条項・交渉余地のある条項

ベンダーとの交渉で押さえたいのが、「業界慣行として固定的な条項」と「交渉余地のある条項」を見分ける感覚です。

逆に、ベンダー側が「絶対に譲れない」と主張することが多い条項もあります。たとえば、間接損害（逸失利益・営業損害）の除外や、競合避止義務（同業他社への類似サービス提供の制限）の限定的扱いは、ベンダー側のビジネスモデル維持のため、譲歩を引き出しにくい論点です。

代替提案の作り方（モデル契約書を根拠にする）

問題条項を発見した場合、単に「修正してほしい」と伝えるよりも、「具体的な代替条項案」を提示する方が交渉がスムーズに進みます。代替案の最強の根拠は、経産省・IPA のモデル契約書です。

たとえば、

• 「検収期間が 5 日間となっていますが、IPA モデル契約書では 2 週間を標準としていますので、本契約でも 14 日間に修正いただけないでしょうか」
• 「契約不適合責任の期間が 3 ヶ月となっていますが、改正民法および IPA モデル契約書では 1 年が標準的です。1 年に修正していただくことは可能でしょうか」

このように、根拠を示しながら具体的な数値を提案することで、「発注者がワガママを言っている」のではなく「業界標準に揃えてほしい」という姿勢で交渉できます。

弁護士確認を入れるべきタイミング

社内に法務担当がいない、または IT 法務に詳しくない場合、外部の弁護士に契約書レビューを依頼するタイミングを判断する必要があります。次のいずれかに該当する場合は、IT 専門の弁護士への相談を推奨します。

• 契約金額が自社にとって大きい（目安として 500 万円以上）
• 個人情報・機密情報を大量に扱うシステムである
• 自社事業のコア部分に関わるシステム（停止・不具合時の事業影響が大きい）
• 契約書ドラフトに不利な条項が複数あり、自分では判断しきれない

弁護士へのレビュー依頼費用は、案件規模にもよりますが 5 万円〜30 万円程度が一般的です。契約金額・事業影響を考えれば、十分に投資する価値のある支出になります。

発注前チェックリストと、自社では判断が難しい場合の相談先

最後に、発注前にこれだけは押さえておきたい項目をリスト化します。実際の契約書ドラフトを見直しながら、各項目を確認してみてください。

このチェックリストを通しで確認し、「危険な記述パターン」に該当する条項が複数見つかった場合や、自社にとって特に重要な部分（事業影響が大きい・金額が大きいなど）で判断に迷う場合は、IT 専門の弁護士事務所への相談、または開発実績豊富なベンダーへのヒアリング（セカンドオピニオンの取得）を検討してください。

より広範な条項チェックの一覧については、システム開発の契約書チェックポイント10選もご活用ください。本記事と組み合わせることで、「発注者として何を判断すべきか（本記事）」と「契約書全体で見落としがちな条項は何か（10 選記事）」の両方をカバーできます。

契約書は「サインする前の数日〜数週間で、後の数ヶ月〜数年のリスクが決まる」非常に重要なドキュメントです。ベンダーから渡された契約書ドラフトをそのまま受け入れるのではなく、本記事で解説した発注者視点の判断軸・協力義務・交渉アクションを踏まえて、自分自身が責任を持って意思決定できる状態を目指しましょう。

—Free Download / 資料ダウンロード

システム開発における基本契約書の雛形

この資料でわかること

システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。

こんな方におすすめです

• システム開発を発注する際にどのような基本契約を結ぶのか興味がある
• システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
• システム開発を発注する側にどのような義務が生ずるのか気になる

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。