同じベンダーへの3件目の発注を控え、また同じような契約書ドラフトが手元に届いた。秘密保持、知財帰属、損害賠償の上限、再委託の可否――どの案件でも同じ条文を毎回交渉し直すのに疲弊している。社内に専属法務もおらず、結局は顧問弁護士か総務任せ。そんな悩みを抱えている発注担当の方は少なくありません。
その解決策として知られているのが「IT基本契約（システム開発の基本契約）」です。同一ベンダーとの継続的な取引について共通条項をまとめておけば、案件ごとの契約締結は注文書レベルの個別契約だけで済み、発注リードタイムを大幅に短縮できます。ところが「何を基本側に書き、何を個別側に切り出すか」「両者が矛盾したらどちらが勝つか」「ドラフトのどこに地雷が潜んでいるか」といった実務的な疑問にぶつかります。
本記事では、システム開発の発注実務に携わるマネージャー・担当者向けに、IT基本契約の役割から、個別契約との切り分け早見表、優先順位条項のサンプル文言、ベンダー提示ドラフトに紛れ込みやすい不利な条項のレッドフラグ集、改訂のタイミングまでを実務フローに沿って解説します。読み終えたあと、次回ベンダーから届くドラフトを「これは基本側か、個別側か」「自社にとって不利な改変は必要か」という視点でレビューできる状態を目指します。
システム開発における基本契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような基本契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
IT基本契約とは｜発注者が知っておくべき定義と役割
IT基本契約とは、同一ベンダーとのシステム開発取引が継続的に発生する場合に、共通して適用される条項（秘密保持・知財・損害賠償・再委託・契約期間など）をあらかじめ1本の契約としてまとめておくものです。「業務委託基本契約」「取引基本契約」と呼ばれることもあり、IT/システム開発の領域では「システム開発委託基本契約」という名称が一般的です。
基本契約の定義と継続取引における位置づけ
ポイントは「継続的・反復的な取引を前提にしている」ことです。単発の請負1件で終わるなら、1本の請負契約書にまとめたほうが分かりやすくなります。一方、保守・追加開発・別システムの新規開発と取引が広がると、案件ごとに秘密保持や知財をゼロから交渉するコストが膨らみます。継続取引のIT契約書では、基本契約に共通ルールを集約することでこのコストを構造的に下げる仕組みが選ばれます。
基本契約と個別契約の構造｜屋根と柱の関係
両者の関係は「屋根と柱」に例えると分かりやすくなります。基本契約が屋根を担い、個別契約が案件ごとの柱として下から支える構造です。
- 基本契約（屋根）: すべての個別案件に共通する条件を定める。一度結べば契約期間中はすべての個別契約に自動適用される
- 個別契約（柱）: 案件ごとの業務範囲・成果物・納期・委託料・契約形態などを定める。注文書／請書、または「業務依頼書＋受領確認」といったライトな書面でやりとりするのが一般的
この構造をとると2件目以降の案件では基本契約の再締結が不要になり、契約締結のリードタイムが1か月単位で短縮されることもあります。
名称のバリエーション
IT/システム開発の文脈を明示したい場合は「システム開発委託基本契約」、より広いITサービス全般を対象とする場合は「業務委託基本契約」が選ばれる傾向にあります。経済産業省や一般社団法人電子情報技術産業協会（JEITA）が公開している「ソフトウェア開発モデル契約」も、基本契約＋個別契約の方式を採用しています（JEITA ソフトウェア開発モデル契約）。
IT基本契約と個別契約の違い｜記載内容の切り分け早見表
ここからが本記事の中核です。基本契約に書く条項と、個別契約に切り出す条項を、どのような基準で分けるべきか――発注者が押さえておきたい切り分けの考え方と早見表を提示します。
切り分けの基準は、次の2軸で判断します。
- 共通ルールか／案件固有か: すべての案件に同じ条件が適用されるなら基本側、案件ごとに変わるなら個別側
- 変動しやすいか: 数値や体制など頻繁に変わる項目は個別側、長期にわたって安定する項目は基本側
基本契約に書くべき共通条項
案件ごとに変える必要がなく、ベンダーとの関係全体に共通して適用すべき条項です。
- 秘密保持義務（NDA）: 情報の定義・利用目的・保存期間・返却または廃棄義務
- 知的財産権の帰属: 成果物の著作権の譲渡範囲・既存知財の取扱い・OSS利用時のルール
- 損害賠償: 賠償責任の範囲・上限額・免責事項
- 再委託: 個別承諾か包括承諾か・再委託先の管理責任
- 契約不適合責任（旧瑕疵担保責任）: 責任期間・対応方法（修補・代金減額・解除）
- 反社会的勢力の排除条項: 表明保証・違反時の解除権
- 契約期間と解除: 契約期間・自動更新の有無・中途解除事由
- 準拠法と管轄: 日本法を準拠法とすること、専属的合意管轄裁判所の指定
これらは案件ごとに条件を変えると運用が混乱します。「A案件は損害賠償上限が委託料の1か月分、B案件は12か月分」では社内で管理しきれません。基本契約で標準化するのがセオリーです。
個別契約に書くべき案件固有条項
案件ごとに必ず変わる項目は個別契約に切り出します。
- 業務範囲（スコープ）: 何を開発・運用するか
- 成果物: 納品物の具体的な内容・形式
- 納期・スケジュール: マイルストーン・最終納期
- 検収方法・検収期間: 検収基準・検収NG時の対応
- 委託料・支払条件: 金額・支払時期・分割払いの有無
- 契約形態: 請負か準委任か（成果物責任の有無に直結）
- 体制・要員: プロジェクトマネージャー・主要メンバー
- 作業場所: オンサイトか持ち帰りか、リモート可否
切り分け早見表（3カラム比較）
実務でレビューする際に参照しやすい3カラム早見表です。「どちらでもよい」は自社のガバナンスや取引規模に応じて配置を選ぶ項目です。
項目 | 基本契約に書く | 個別契約に書く | どちらでもよい（運用次第） |
|---|---|---|---|
秘密保持義務 | ◎ | ||
知財帰属 | ◎ | ||
損害賠償の上限・免責 | ◎ | ||
再委託の可否・手続 | ◎ | ||
契約不適合責任 | ◎ | ||
反社条項 | ◎ | ||
契約期間・解除 | ◎ | ||
準拠法・管轄 | ◎ | ||
業務範囲（スコープ） | ◎ | ||
成果物の内容・形式 | ◎ | ||
納期 | ◎ | ||
検収方法 | ◎ | ||
委託料・支払条件 | ◎ | ||
契約形態（請負／準委任） | ◎ | ||
体制・要員 | ◎ | ||
個人情報の取扱い | ◎（覚書として別紙化も可） | ||
セキュリティ要件 | ◎（SLA別紙として切り出すケースも） | ||
知財の共同保有・利用権 | ◎（案件特性が強い場合は個別側に） | ||
検収基準の詳細 | ◎（テンプレートは基本側、案件固有は個別側） |
個人情報を扱う案件が多い企業であれば個人情報取扱条項を基本側に置き、セキュリティ要件はSLA（サービスレベル合意書）として基本契約に紐付ける形が運用しやすくなります。
基本契約と個別契約はどちらが優先されるか
切り分け表に従って設計しても、案件ごとに「個別契約で例外を設けたい」場面が出てきます。たとえば通常は損害賠償上限を委託料の12か月分としているが、ある重要案件だけは上限なしにしたいケースです。両者が矛盾するとき、どちらが優先されるのでしょうか。
民法上の原則と、条項で上書きできること
民法上の原則は「後法優先（後に締結された契約が優先する）」です。基本契約を先に結び、後から個別契約を結んだのであれば、個別契約の内容が基本契約を上書きするというのが一般的な解釈です（基本契約書と個別契約書の優先順位を徹底解説（フラット経営事務所））。ただしこれは一般原則で、契約書内に「優先順位条項」を明記すれば上書き可能です。実務では解釈の余地を残さないために、優先順位条項を必ず置くのが定石です。
「基本契約優先」「個別契約優先」のメリット・デメリット
- 基本契約優先: 基本契約が優先する旨を明記する。共通ルールが崩れず社内管理がシンプルだが、個別案件の特殊事情を反映しづらい
- 個別契約優先: 個別契約で別段の定めをした場合はそちらが優先する旨を明記する。案件ごとの柔軟な調整が可能だが、社内での一元管理が難しくなる
ベンダー側から提示される基本契約には「基本契約優先」のパターンが入っていることが多く、発注者としては自社のガバナンス方針と案件特性を踏まえてどちらを採用するか意識的に選ぶことが大切です。
優先順位条項のサンプル文例
次回の交渉でそのまま叩き台として使える文例を示します。
個別契約優先（発注者の交渉余地を残すパターン）
第○条（個別契約の優先） 本契約と個別契約の内容が矛盾する場合、当該個別契約に別段の定めがあるときは、当該個別契約の定めが優先するものとする。ただし、本契約第○条（秘密保持）、第○条（反社会的勢力の排除）の規定は、個別契約に優先する。
基本契約優先（共通ルールの一貫性を重視するパターン）
第○条（本契約の優先） 本契約と個別契約の内容が矛盾する場合は、本契約の定めが優先する。ただし、個別契約において本契約の規定と異なる定めをすることを明示的に合意した条項については、当該個別契約の定めが優先する。
発注者として実務的に推奨できるのは、原則「個別契約優先」に、秘密保持・反社条項など絶対に崩したくない基本条項だけを優先例外として書き出す構成です。
IT基本契約を締結するメリット（発注者視点）
社内で「マスター契約を結びたい」と稟議を上げるときの説明材料として、発注者目線のメリットを整理します。
- 契約締結のリードタイム短縮: 2件目以降の案件は注文書・業務依頼書レベルで発注でき、契約レビューの数週間〜1か月を圧縮できる
- 同条件の交渉コスト削減: 毎回もめがちな秘密保持・知財・損害賠償を、ベンダー単位で一度合意すればよくなる
- 条件の標準化によるトラブル予防: 案件ごとに条件がバラバラだとトラブル時に都度確認することになる。標準化で対応のばらつきを抑えられる
- 継続関係の構築: 基本契約を結ぶこと自体が、長期的なパートナーシップへのコミットメントを示すシグナルになる
- 個別契約の運用簡素化: 注文書・請書あるいは「業務依頼書＋受領確認メール」だけで成立させる運用が可能になり、押印・郵送コストも削減できる
導入の目安として、年5案件以上を同一ベンダーに発注している、または継続的に取引を広げる見込みがあるなら、基本契約を結ぶ費用対効果が出やすいといえます。継続取引のIT契約書を基本＋個別の二層構造にするかどうかは、発注頻度と取引の安定性で判断するのが現実的です。
システム開発における基本契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような基本契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
基本契約に紛れ込みやすい不利な条項｜発注者向けレッドフラグ集
実務ではベンダー側からドラフトを提示されるケースが多く、不利な条項が自然に紛れ込んでいることが少なくありません。発注者がレビュー時に確認すべき「レッドフラグ」と修正交渉の方向性を紹介します。
損害賠償の上限・免責
最も頻繁に交渉になる論点です。
- 過小な上限設定: 「上限は委託料の1か月分」など被害規模に対して明らかに小さい設定。情報漏えいなど実損が委託料の何倍にも及び得る案件では大きなリスクとなる
- 間接損害・逸失利益の一律免責: 情報漏えい時の取引先対応費用や売上機会損失が含まれない可能性がある
- 故意・重過失も上限の範囲内に含める: 通常は上限の対象外とするのが一般的だが、上限内に含めるドラフトもある
修正の方向性: 上限を「個別契約の委託料の12か月分」など実態に即した水準まで引き上げる。故意・重過失は上限を適用しない旨を明記する。情報漏えいは別途上限を設けるか上限なしとする。
知財・著作権の譲渡範囲
- 著作権法第27条・第28条の明記がない: 「著作権を譲渡する」とだけ書かれていて翻案権（27条）・二次的著作物の利用権（28条）の譲渡が明記されていない場合、これらの権利はベンダー側に留保されると解釈される可能性がある
- 既存知財の取扱いが曖昧: ベンダー保有のライブラリ・フレームワークが成果物に含まれる場合の利用条件が書かれていない
- OSS（オープンソースソフトウェア）の取扱い: GPL等の利用に伴う制約が事前に開示されていない
修正の方向性: 「著作権法第27条および第28条に規定する権利を含むすべての著作権を譲渡する」と明記する。既存知財は「成果物に組み込まれる範囲で発注者が利用するために必要な利用権を許諾する」旨を入れる。OSSは事前報告とライセンス一覧の提出を義務付ける。
再委託に関する条項
- 包括承諾: 「再委託は事前の承諾なく行うことができる」という条項。誰に再委託されているか発注者が把握できなくなる
- 再委託先の管理責任が曖昧: 再委託先の行為についてベンダーが責任を負う旨が明記されていない
修正の方向性: 個別承諾、または少なくとも事前通知を義務付ける。再委託先の行為についてベンダーが発注者に責任を負うことを明記する。
契約不適合責任と請負／準委任の整合
2020年4月の改正民法で「瑕疵担保責任」は「契約不適合責任」に変わりました。
- 責任期間の極端な短さ: 「検収後3か月以内に通知された不適合のみ対応」など、システム開発の実態に合わない短期間
- 準委任契約なのに成果物の品質責任を負わせる: 準委任は本来「業務遂行」に対する責任で完成責任は負わないが、請負と同様の検収・契約不適合責任が課されているケースがある
修正の方向性: 期間は最低でも検収後1年、重要な不具合は発見後一定期間とする。契約形態と責任範囲を整合させる。
発注者の協力義務・検収条件
- 協力義務だけが片務的に課されている: 協力が遅れたときの責任分担が書かれていない
- 検収のみなし合格条項の期間が短すぎる: 検収期間が7営業日以内など、実質的に検証できないまま合格扱いになるケース
- 追加要件・仕様変更の費用負担: 仕様変更時の追加見積もり手続きが書かれていない
修正の方向性: 協力義務の具体的な内容と、協力遅延時の納期延伸・費用調整のルールを定める。検収期間は案件規模に応じて10〜30営業日を確保する。仕様変更は「双方が書面で合意した場合に限り効力を生じる」旨を明記する。
これらのレッドフラグは、ベンダーが意図的に潜ませているわけではなく、業界標準のひな形をそのまま流用した結果というケースも多くあります。発注者側で一次レビューの観点を持つことが、長期的に良好な発注関係を築く前提になります。
基本契約の改訂タイミングと進め方
一度結んだ基本契約は塩漬けになりがちですが、定期的なメンテナンスが必要です。改訂タイミングを社内ルールとして決めておくと、後から慌てずに済みます。
改訂を検討すべき4つのトリガー
- 法改正: 2020年4月の改正民法（瑕疵担保責任→契約不適合責任）、個人情報保護法の改正、フリーランス・事業者間取引適正化等法（2024年11月施行）など、契約に影響する法改正
- 取引規模の拡大: 年間取引額が拡大し、損害賠償上限が実態に合わなくなったとき
- 取引内容の変化: 請負中心から準委任（SES・保守運用）中心へ移行したとき
- セキュリティ要件の強化: 機密情報の取扱い増、顧客からの監査対応要求、業界ガイドラインへの対応が必要になったとき
少なくとも年1回は基本契約の棚卸しを社内ルーチンとして設けると、改訂漏れによるリスクを抑えやすくなります。
改訂方法（覚書 vs 全面改訂）の選び方
- 覚書による一部改訂: 変更箇所が少ない場合に向く。スピードが速い反面、覚書が積み重なると現時点で有効な条項を読み解くのが難しくなる
- 全面改訂: 既存の基本契約を解除し、新しい基本契約を結び直す。変更が多い場合や覚書が3〜4本積み上がってきたタイミングで実施するとよい
実務的には軽微な改訂は覚書、節目（2〜3年ごと、または覚書が3本以上たまったタイミング）で全面改訂、というハイブリッド運用が現実的です。
基本契約と一緒に整備したい関連契約・周辺ドキュメント
基本契約は継続取引における「屋根」ですが、これだけですべて完結するわけではありません。案件特性に応じて以下の関連ドキュメントを併せて整備しておくと、ベンダーとの関係をより安定的に運用できます。
- SLA（Service Level Agreement、サービスレベル合意書）: 保守・運用フェーズで稼働率・障害対応時間・サポート受付窓口などのサービス水準を定める。基本契約の別紙として紐付ける運用が一般的
- 情報セキュリティ覚書: 情報の機密区分・アクセス管理・インシデント発生時の通報義務などを定める。個人情報や機密度の高いデータを扱う場合は必須に近い
- ソフトウェア著作権の取扱い覚書: 既存ライブラリ・OSSの取扱い、共同開発成果物の権利配分など知財に関する特殊な取り決めを別紙化する
- NDA（秘密保持契約）: 契約締結前の打ち合わせ段階で情報をやりとりする場合は、先に単独のNDAを締結することもある
- 個別契約のテンプレート: 社内で標準フォーマットを用意しておくと発注のたびの作成コストがかからない
これらを基本契約と同時に整備しておくと、案件ごとの個別契約は「業務範囲・成果物・納期・委託料・体制」だけを記載するライトな書面で済み、発注実務全体としてのアウトプットも安定します。なお、関連契約のそれぞれの設計ポイント（SLA設計の詳細、情報セキュリティ契約の構造、ソフトウェア著作権の譲渡範囲の論点など）は別記事で個別に取り上げる予定です。
まとめ｜IT基本契約を発注者の武器にする
本記事のキーメッセージを4点に整理します。
- IT基本契約は継続取引の効率化ツール: 同一ベンダーとの取引が反復するなら、共通条項を基本契約に束ねることで案件ごとの契約締結コストを構造的に下げられます
- 切り分けの肝は「共通か／案件固有か」「変動するか」: 秘密保持・知財・損害賠償は基本側、業務範囲・納期・委託料は個別側に切り分けます
- 優先順位条項を必ず入れる: 矛盾時に備えてどちらが優先するかを明文化する。発注者の交渉余地を残すなら「個別契約優先＋一部例外」が現実的な落としどころです
- 結んだら終わりではなく定期的に改訂する: 法改正・取引規模の変化・セキュリティ要件の強化など、改訂トリガーを社内で共有し、年1回の棚卸しと節目の全面改訂を運用ルールに組み込みましょう
継続取引のIT契約書を基本契約＋個別契約の二層構造で設計しなおすだけで、発注のリードタイムは大きく短縮できます。次回ベンダーから基本契約のドラフトが届いたら、本記事の切り分け早見表とレッドフラグ集を片手にレビューしてみてください。これまで「なんとなく」サインしていたドラフトが、自社にとって有利な交渉の材料へと変わっていくはずです。
システム開発における基本契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような基本契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
