システム開発でソースコードが納品されない見積もりのリスク｜権利と引き継ぎ

システム開発の見積書に「ソースコード納品」と書かれていれば安心、書かれていなければ危険——実務では、この区別だけでは判断が付きません。コードのファイルは受け取ったのに、別の会社に見せたら「これでは動かせません」と言われる状態が普通に起きるからです。この記事は、発注前の見積書と契約条項の段階で、別の会社が再ビルドして保守できる状態になるかを確認するための手順書です。

この記事の結論｜確認するのは「もらえるか」ではなく「動かせるか」

先に結論を書きます。

ソースコード納品の条件で確認すべきことは3つあり、どれか1つでも欠けると「持っているのに使えない」状態になります。

1. 納入物 — コードだけでなく、それを動く状態に組み立てるための資料と設定が納品対象になっているか
2. 権利 — 受け取ったコードを、自社や別のベンダーが改変して使える範囲まで権利が及んでいるか
3. 再現性 — 手元のコードが本番と一致し、第三者の環境でビルドして動くことを確認する手順があるか

見積書の納品物欄に「ソースコード一式」と1行だけ書かれている状態は、この3つのうち納入物の一部だけを約束しています。権利と再現性は、その1行からは何も読み取れません。

そして、しばしば誤解されている点を先に置きます。権利をすべて発注側へ移すことが常に正解ではありません。 後述するとおり、公的なモデル契約書は「原則としてベンダー側に著作権を帰属させる」案を第一案として置いており、その理由も明示しています。発注側が判断すべきなのは「権利を全部こちらへ移せるか」ではなく、①自社固有の部分か（どこにでもある汎用品ではないか）、②このシステムを今後も変えていく予定があるかの2点です。2つが揃うなら、そのための権利と資料を、契約前に金額とセットで決める。これが本記事の主張です。

「ソースコード納品」は納入物・権利・再現性の3層に分かれている

まず言葉を整理します。日常会話の「ソースコードをもらう」は、実務では性質の違う3層が混ざっています。

①と③で同じ資料（設計書、設定値一覧）が出てくることがあります。これは重複ではなく、契約で約束されているか（①）と、その中身が本番と一致しているか（③）が別の問いだからです。①は納品物欄で、③は検収条件で確認します。

この3層のうち、見積書に金額として現れやすいのは①だけです。 ②は契約書の条項、③は納品作業の手順の中にあり、どちらも金額欄からは見えません。だから「ソースコード納品あり」と書かれた安い見積書と、「納品あり」に加えて環境構築手順書の作成とビルド検証が計上された高い見積書が並んだとき、金額だけを比べると前者が良く見えます。これは過小見積もりを選んでしまう典型的な形です。テスト・移行・セキュリティ・PM費の欠落と同じ構造で、消えているのは作業であって、必要性ではありません。

見積書1枚を工程・成果物・工数へ分解する手順そのものは、見積書の「一式」を工程・成果物・工数へ分ける方法で扱っています。本記事は、その分解のうち納品物欄と権利条項だけを深掘りする位置づけです。

見積書ではどう書かれているか｜納品物欄の5つの型

実際の見積書や提案書で、納品条件は次のどれかの形で現れます。どれも「よくある書き方」であって、それ自体が不誠実なわけではありません。 ただし、読み取れる情報量が大きく違います。

AとBは「聞けばすぐ出てくる」ことが多い型です。 見積書は要約なので、提案書や契約書の別紙に詳細があるだけ、というケースは珍しくありません。まず別紙の有無を聞いてください。それでも出てこない場合に初めて、契約前の確認事項になります。

注意して読むべきはDです。 「動く状態で引き渡す」と「作り直せる状態で引き渡す」は別のことです。Dの型は前者だけを約束しており、後者は「別途協議」に送られています。別途協議は、稼働後には交渉材料が減った状態で行われます。

法律の初期設定｜契約に書かなければ、権利は動かない

ここからが本記事の中心です。②の権利について、契約書に何も書かなかったときにどうなるかを先に押さえておくと、見積書の読み方が変わります。以下は日本の著作権法（昭和45年法律第48号）の条文に基づく整理です。個別の契約の解釈は弁護士の確認が必要であり、この記事は法律上の助言ではありません。

プログラムの著作権は、書いた側の会社に発生する

著作権法は、プログラムを「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」と定義し（第2条第1項第10号の2）、プログラムの著作物を著作物の例示に挙げています（第10条第1項第9号）。そして権利の発生に手続きは要りません。「著作者人格権及び著作権の享有には、いかなる方式の履行をも要しない」（第17条第2項）と定められているため、書いた瞬間に権利が発生します。

では誰のものになるか。第15条第2項は、法人等の発意に基づき、その法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、作成の時における契約・勤務規則その他に別段の定めがない限り、その法人等とすると定めています。開発会社の従業員が業務として書いたコードの著作権は、開発会社に帰属するのが出発点です。

経営判断への影響はここです。開発費を全額支払っても、それだけでは権利は移りません。 文化庁著作権課が発行している「誰でもできる著作権契約マニュアル」（令和5年3月）も、著作権と所有権は異なる権利であり、制作を依頼した側が著作権を取得するには契約で合意しておく必要があると説明しています。見積書の金額が大きいことと、権利が手元に来ることは、まったく別の話です。

「著作権を譲渡する」の一行では、改修の権利が残ることがある

著作権は全部でも一部でも譲渡できます（第61条第1項）。ただし、この条文には続きがあります。

著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。（著作権法第61条第2項）

第27条は翻訳権・翻案権等、第28条は二次的著作物の利用に関する原著作者の権利です。ソフトウェアの文脈でいえば、既存のコードに手を入れて別のものにする行為が第27条の射程に入ります。つまり「著作権を甲に譲渡する」とだけ書かれた契約は、条文の推定に従えば改造する権利は開発会社に残ったままになり得ます。

前掲の文化庁のマニュアルも、二次的著作物に関する権利を含めて著作権の全部を譲渡する場合には「著作権法第27条及び第28条に規定する権利を含む」と明記する必要があり、明記しない場合はそれらの権利が譲渡の対象ではないと推定される、と規定例つきで説明しています。

これが、見積書や契約書で最初に探すべき文字列です。 「（著作権法第27条及び第28条の権利を含む）」という括弧書きがあるかどうか。無ければ、その一行を入れてもらえるかを聞く。ここは交渉というより、書式の確認に近い作業です。

譲渡しても、ベンダー側に残る権利がある

第59条は「著作者人格権は、著作者の一身に専属し、譲渡することができない」と定めています。著作権をすべて譲り受けても、著作者人格権は移りません。その一部である同一性保持権（第20条第1項）は、著作者が意に反する改変を受けないとする権利です。

第20条第2項は例外を4つ挙げており、そのうち第3号は「特定の電子計算機においては実行し得ないプログラムの著作物を当該電子計算機において実行し得るようにするため、又はプログラムの著作物を電子計算機においてより効果的に実行し得るようにするために必要な改変」です。移植と効率化のための改変は例外に含まれますが、機能追加を一般的に認める規定ではありません。

そのため実務では、契約書に著作者人格権を行使しない旨を書きます。実際、内閣府が委託者となる「先端的サービスの開発・構築及び規制・制度改革に関する調査事業」で公開されている仕様書（案）は、本業務の遂行により生じた著作権を「原則として」内閣府に譲渡させるとしたうえで「内閣府に対し、一切の著作者人格権を行使しないこととし、また、第三者をして行使させないものとする」と定めています（同事業の著作権に関するQ&A、令和6年8月23日）。同Q&Aは、譲渡される著作物にプログラム・ソースコードが含まれることも明記しています。

コードを手元に持っているだけで、何ができるのか

権利が移らなかった場合でも、コードの複製物を持っていること自体に意味はあります。第47条の3第1項は、プログラムの著作物の複製物の所有者は「自ら当該著作物を電子計算機において実行するために必要と認められる限度において」複製できると定めており、同法第47条の6第1項はこの場合の翻案も認めています。

ただし、条文が認めている限度は「自ら実行するために必要と認められる」範囲です。機能追加のための改修を一般的に許すものではありません。 どこまでできるかを条文の解釈に委ねるのではなく、契約で定めておくのが実務の作法です。

なお、著作権の移転は「登録しなければ、第三者に対抗することができない」とされています（第77条第1号）。ベンダーの倒産や事業譲渡といった場面まで想定する場合、契約書に譲渡と書いてあることと、第三者に対して主張できることは別問題になります。ここは自社だけで判断せず、専門家に確認する領域です。

公的なモデル契約書は「原則ベンダー帰属」で書かれている

ここで、発注側にとって都合の悪い事実を先に置きます。経済産業省の依頼によりIPAが策定した公的なモデル契約書は、ベンダー側に著作権を帰属させる案を第一案にしています。

IPA（独立行政法人情報処理推進機構）が公開している「情報システム・モデル取引・契約書（第二版）」は、経済産業省の依頼を受けてIPAが見直しを行い2020年12月22日に公表されたものです（第一版は経済産業省が公開）。その第45条「納入物の著作権」には3つの案が用意されています。

そして第45条の解説はこう書いています。「本モデル契約では、ソフトウェアの再利用を促進するため、原則としてベンダに著作権を帰属させる規定をA案としている」。

なぜそうなったのかは、同じ文書の「主要条項の論点整理」に両論併記で残されています。ベンダ帰属を支持する意見として挙がったのは、ベンダの横展開（パッケージ化、共通モジュールの再利用）による「社会的な生産効率の向上」と、部品化・標準化による情報システムの信頼性向上でした。あわせて、ノウハウの流出防止はベンダに秘密保持義務を課すことで図れるのであって「ノウハウ流出防止＝著作権のユーザ帰属」ではない、という意見も記録されています。

一方で、ユーザが著作権の譲渡を受ける理由として挙がった意見も同じ整理に並んでいます。成果物にユーザのノウハウが含まれており、競合他社への流出を防ぐ必要があることと、開発費用をユーザが負担していることです。つまりこの資料は、どちらの立場にも言い分があると認めたうえで、第一案をA案に置いています。

さらに、A案を選んだ場合でも発注側が困らないようにする手当てが、同じ議論の中で示されています。ひとつは、プログラムの著作物についての一定の改変・複製・翻案は複製物の所有者にも著作権法により許容されているため、著作権を持たないユーザでも情報システム子会社やアウトソーシング先へ保守運用を委託することは可能だという整理です。もうひとつは倒産時の手当てで、ソースコードや付帯するドキュメントの開示・交付を受けることは、納入物にソースコードを明記するか、エスクロウ制度の活用により対応可能だとされています。

ここで出てくるエスクロウとは、ソースコードや設計書を第三者機関に預けておき、ベンダーの倒産や事業撤退など契約で定めた事由が起きたときに発注側へ開示される仕組みです。経営判断の言葉に直すと、権利は相手に残したまま、事業継続に必要な最低限の保険だけを買う選択肢にあたります。モデル契約書がA案の手当てとして挙げている選択肢のひとつですが、預託の費用や開示事由は預託先の機関と契約条件によって異なるため、提案を受ける段階で確認してください。

つまりモデル契約書は、権利の帰属と、コードが手元に来るかどうかを、別々の問題として設計しています。 本記事が冒頭で3層に分けた理由もここにあります。

中小・中堅向けの追補版も、原則はベンダー帰属

同じく公開されている第二版追補版は、対象範囲を「ITの専門知識を有しないユーザ」（例として民間中小・中堅企業、地方自治体、独立行政法人等）とし、パッケージ＋カスタマイズ型・パッケージ＋オプション型の開発を想定した別冊です。財務会計システム、販売管理システム、電子メール、グループウェア、Webシステム等の導入、構築・設定、カスタマイズ開発、移行、教育、保守、運用支援が対象に挙げられています。

この追補版も、カスタマイズ等により新たに作成されたソフトウェアの権利は原則ベンダに帰属させるとしています。理由として書かれているのは、ベンダが他のビジネスでも再利用できる環境を整えたほうが「総体としては価格を低く抑えることができ、中小企業等が利用するシステムとして比較的合理的な価格で広く普及することに資する」という点です。もちろん、当事者の合意によりユーザ帰属案・共有案を採用することも可能である、とも明記されています。

ベンダー側が「著作権は当社帰属です」と提示すること自体は、公的なモデル契約書の第一案と同じ立場です。 これを不当だと決めつけるのは、事実に反します。確認すべきは帰属そのものではなく、帰属をA案にしたうえで、納入物と改変可能性がどう手当てされているかです。

権利をユーザーへ移すと、見積金額は上がりうる

もう1点、金額に直結する話です。モデル契約書のB案の解説には、著作権の移転については著作権の価値に見合った対価が支払われる必要があり、本モデル契約では開発の委託料に含める方法をとった、と書かれています。そのうえで、委託料に著作権移転の対価が含まれるという建て付けは、あらかじめ委託料の見積金額に著作権移転の対価が構成要素として含まれ、合意によって決定されていることが前提である、と続きます。ユーザが著作権の譲受を希望する場合は、事前にRFPでその旨を明らかにし、委託料の構成要素として開発費のほかに著作権移転の対価をベンダに見積依頼することになる、という手順まで示されています。

したがって、相見積もりの途中で「やはり著作権はこちらに」と言い出すと、比較条件が崩れます。 権利の要求は、RFPまたは見積依頼の時点で条件として出すのが正しい順番です。安いほうの見積書がA案（ベンダ帰属）、高いほうがB案（ユーザ帰属＋対価込み）だったなら、その差額の少なくとも一部は仕様差として説明できるはずです。差額の全部が権利の対価だとは限らないので、内訳を聞いてください。

国の調達ルールが権利を発注側へ寄せる2つの条件

もう1つ、判断の基準になる公開文書があります。デジタル庁のデジタル社会推進標準ガイドライン DS-100「デジタル・ガバメント推進標準ガイドライン」（2026年6月12日 デジタル社会推進会議幹事会決定）です。国の情報システム調達のルールなので民間企業にそのまま適用されるものではありませんが、どういう条件のときに権利を発注側へ寄せるべきかの考え方が明示されており、社内で説明するときの土台として使えます。

同ガイドラインは調達仕様書の「成果物の取扱いに関する事項」について、まず一般論として、産業技術力強化法（平成12年法律第44号）に基づき受注者側に知的財産権が帰属するものであることに留意するとしています。ここも出発点はベンダー帰属です。

そのうえで、設計・開発により構築したアプリケーションプログラム等の成果物のうち、国の業務に特化した汎用性のないもの及び継続的な機能改修が見込まれるものについては、原則として次のとおりとする、として4項目を挙げています。

注目してほしいのは、例外を適用する対象の絞り方です。ガイドラインが挙げているのは「国の業務に特化した汎用性のないもの」と「継続的な機能改修が見込まれるもの」であり、成果物すべてではありません。そして[4]は、発注者側に帰属する成果物の範囲を明確にする理由として「継続的な機能改修や次期更改等に対する公正性及び競争性を担保する観点」を挙げています。

つまり、権利を発注側へ寄せる話が出てくるのは「汎用品ではない」「これからも直す」という2条件が揃ったときであり、そのときに気にしているのは次の発注で競争が成立するかどうかだ、という構造です。 逆に言えば、一度作って以後ほとんど変更しないシステムであれば、権利をベンダー帰属のままにしておく判断も、この考え方と矛盾しません。

同ガイドラインは引き継ぎについても定めており、設計・開発事業者に対して、運用事業者および保守事業者へ設計・開発の設計書、作業経緯、残存課題等を確実に引き継ぐよう求めるものとする、としています。要件定義の記載事項にも「引継ぎに関する事項」として、他の関係事業者への引継ぎに関する要件を記載することが挙げられています。引き継ぎは納品時の善意ではなく、要件定義の項目として扱われているということです。

実際に費用を生む作業は何か｜納品条件が金額に変わる場所

ここまでが権利の話です。次に、①納入物と③再現性がどこで費用に変わるかを見ます。「ソースコード納品」を1行から実際の作業へ展開すると、次のようになります。

上の6つは、どれも「ソースコード一式」という言葉には含まれません。 そして、含めるかどうかで金額が変わります。これは値引きの余地ではなく、買う範囲の違いです。3社から見積もりを取ったときに1社だけ高い、という状況では、この欄の差である可能性を先に確認してください。相場レンジそのものの考え方はシステム開発費用の相場と見積もりの妥当性にまとめています。

③再現性｜「渡した」と「動く」の間にある4つのギャップ

3層のうち、見積書からも契約書からも読み取れないのが再現性です。ここだけは、書面ではなく引き渡しの手順を指定しないと確認できません。 確認すべきギャップは4つあります。

1. 手元のコードは本番と同じか

納品を受けたのが稼働開始時点のコードで、その後の改修が入っていない、という状態は珍しくありません。判定材料は「いつ時点のものか」がバージョンや日付で特定できるかどうかです。引き渡しのたびに版を記録し、本番稼働版と一致することをベンダーに確認させる手順を、検収条件に入れておきます。

2. 第三者の環境でビルドが通るか

開発者の端末には、何年もかけて積み上がった設定が入っています。まっさらな環境で組み立て直すと、そこで初めて足りないものが分かります。確認方法はひとつで、貴社の開発機ではない環境でビルドして動かしてもらうことです。 立ち会って画面を見せてもらう形でも構いません。これを検収の一項目にするかどうかで、あとで発生する調査費用が変わります。

3. 鍵・証明書・外部サービスの名義が誰のものか

APIキー、SSL証明書、決済サービスやメール配信サービスのアカウント。これらがベンダー名義のままだと、契約を切った瞬間にサービスが止まります。 コードの権利とはまったく別の話で、しかも移管作業そのものは小さいことが多い領域です。要求されないから移されていないだけ、というケースが大半なので、発注前に一覧を出させて名義を決めておきます。

4. 設定値が資料に残っているか

コードと同じくらい重要なのに、納品物一覧から漏れやすいのが設定値です。環境変数、バッチの実行時刻、外部連携先のエンドポイント、権限やロールの定義。同じコードでも設定が違えば別物として動きます。 ここは①納入物と重なる領域で、「設定値一覧」または「パラメータシート」という名前で納品対象に入っているか（①）と、その中身が本番の値と一致しているか（③）を、別々に確認します。

国の調達ルールが引継ぎとして「設計書、作業経緯、残存課題等」の確実な引き継ぎを求めているのは、資料を渡すこと自体を目的にしているのではなく、次の事業者が動ける状態にするためです。同じ発想を民間の検収へ持ち込むと、この4点になります。書面の約束ではなく、引き渡し当日にやることの約束として決めておくのが、この層の扱い方です。

ベンダー側の説明が正当と言えるケース

判定で気になる項目が出ても、それがそのままベンダーの落ち度とは限りません。次の説明は、条件が揃っていれば正当です。 見積書を見る側が持っておくべき「反証条件」として、先に置いておきます。

説明が出てくること自体は問題ではありません。 確認すべきは、説明があるかどうかと、その説明に根拠（契約条項・部品の特定・代替手段）が付いているかどうかです。根拠の無い「できません」だけが、次の表の高リスクに当たります。

見積書の判定表｜説明済み／要確認／高リスク／判断不能

受け取った見積書と提案書を、次の4状態へ仕分けます。「高い・安い」ではなく「読み取れる・読み取れない」で分けるのがポイントです。

表の読み方｜4つの状態にはそれぞれ次の一手がある

• 3層すべてが「説明済み」なら、追加の質問は不要です。次にやるのは、その明細を契約書の別紙として添付し、本文から参照させる作業です。IPAのモデル契約書は、本契約と個別契約が当該個別業務の取引に関する合意のすべてである（完全合意）とし、RFPの内容であっても契約書に規定がなければ契約内容とはならない、と解説しています。見積書の記載を確実に効かせるには、別紙として契約書へ取り込むのが確実です
• 「要確認」が混じるなら、次章の質問文をそのまま送ります。多くは1〜2往復で片づきます。この段階では金額の話をしないほうが早く進みます
• 「高リスク」があるなら、値引き交渉より先に、前節の表で代替手段の有無を確認します。根拠のある「できません」なら条件を詰める、根拠の無い「できません」なら発注判断そのものを見直す、という分岐になります
• 「判断不能」が1つでもあるなら、金額の比較はまだできません。条件が揃っていないものを並べているだけになるからです。まず契約書と別紙を出してもらうところに戻ります

ベンダーへそのまま送れる確認質問8問

以下はコピーして送れる文面です。「金額を疑っている」ではなく「社内稟議と契約書の別紙に必要」という立て付けにしてあります。実際、IPAのモデル契約書は、個別契約で定めるべき事項として「乙が甲の委託に基づき作成し納入すべき物件（以下「納入物」という。）の明細及び納入場所」を挙げており（第4条第9号。柱書は「以下の各号のうち必要となる取引条件を定め」）、納品条件の確認は契約実務の一部です。

1. 納入物の明細をご提示ください。 ソースコード、内部設計書、環境構築手順書、ビルド・デプロイ手順、テスト仕様書、運用手順書、設定値一覧のそれぞれについて、納品対象に含まれるかをお聞かせください。
2. ソースコードの引き渡し形式を教えてください。 リポジトリごと移管いただけるのか、特定時点のアーカイブでの提供か、また変更履歴（コミット履歴）が含まれるかをお聞かせください。
3. 納入物の著作権の扱いについて、貴社の標準はどれに当たりますか。 ①貴社帰属、②当社へ移転（汎用部品を除く）、③共有のいずれかでお答えください。②の場合、契約書に「著作権法第27条及び第28条の権利を含む」旨の記載はありますか。
4. 貴社に留保される「汎用的な利用が可能なプログラム」の範囲を、具体的に特定してください。 どのモジュール・ライブラリが該当し、それらを当社側で改変・再利用できるかを教えてください。
5. 著作者人格権の取扱いについて、契約書にどのような定めがありますか。 当社または当社が委託する第三者が業務上必要な改変を行う場面を想定した記載があるかをお聞かせください。
6. 引き渡し時に、貴社の開発機以外のクリーンな環境でビルドが通ることを確認していただけますか。 確認する場合、その作業は今回の見積金額に含まれていますか。含まれていない場合の追加費用も教えてください。
7. 本システムが利用している第三者製ソフトウェア・OSS・外部SaaSの一覧と、それぞれの利用条件をご提示ください。（②権利の確認です）あわせて、当社名義への契約変更が必要なものがあれば教えてください。（こちらは③再現性の確認です）
8. 将来、保守を当社または当社が選定した別の会社が行う場合に、契約上の制約はありますか。 制約がある場合はその内容を、無い場合は引き継ぎ時に提供いただける資料の範囲を教えてください。

回答をどう読むか

• 1〜2に即答が返ってくるなら、納品条件は整理されています。見積書が要約されていただけです
• 3〜5で「契約書のひな型どおりです」とだけ返る場合は、ひな型そのものの提示を依頼してください。条項を読まずに判断はできません
• 6で「追加費用がかかる」と返るのは、むしろ正常な回答です。作業が実在することを認めているからです。無償で即答された場合、実施しない可能性も含めて確認してください
• 7で名義変更が必要なサービスが挙がってくるなら、それは良い回答です（③再現性の確認）。挙がってこないほうが危険で、契約を切った瞬間に決済やメール配信が止まる、という形で表面化します
• 8で明確に制約があると回答される場合、その制約が権利によるものか、資料の未整備によるものかを分けて聞いてください。前者は契約前にしか動かせません

権利をすべて自社へ寄せることの代償

最後に、逆方向のリスクにも触れます。権利を全面的に発注側へ移すことには、必ずコストが伴います。

• 権利を持つことと、保守できることは別です。改変の権利があっても、資料と環境が無ければ次のベンダーは動けません。3層のうち②だけを取りにいっても、①と③が空のままなら状況は変わりません
• 汎用部品まで含めて権利を要求すると、ベンダーは他案件で使っている共通モジュールを使えなくなります。その分を新規開発するか、案件自体を辞退する、という判断になり得ます
• 見積金額に反映されます（前掲「権利をユーザーへ移すと、見積金額は上がりうる」）

ノウハウの流出防止が目的なら、秘密保持条項で対応できるというのが、IPAモデル契約書が示している整理です。目的から手段を選んでください。「汎用品ではない自社固有の部分がある」「今後も継続的に機能追加していく予定がある」——この2つが揃うときに、権利を寄せる意味が最も大きくなります。DS-100が例外の対象として挙げているのも、この2つの条件を満たす成果物でした。

なお本記事は発注前の契約条項に絞っています。すでに稼働しているシステムで、資料や権限が手元にない状態からどう動くかはベンダーロックインと保守費用の関係を、契約満了に向けて実際に保守会社を替える手順は保守会社を変更するときの進め方を参照してください。稼働後は交渉材料が減るため、同じ内容でも難易度が上がります。

根拠資料と適用条件

本記事で参照した資料と、その適用条件です。

適用条件を4点補足します。

• IPAモデル契約書（第二版）が想定しているのは、大きめの取引です。 契約当事者として「対等に交渉力のあるユーザ・ベンダ」（例として委託者＝民間大手企業）、開発モデルとしてウォーターフォールモデル、対象システムとして「重要インフラ・企業基幹システムの受託開発、保守・運用」を前提としています。数百万円規模のWebシステムに条文をそのまま当てるのは過剰です。第二版追補版のほうが、ITの専門知識を有しないユーザ（民間中小・中堅企業、地方自治体、独立行政法人等）とパッケージ活用型を想定しており、規模が近いことが多いはずです。
• DS-100は国の情報システム調達のルールです。 民間企業に適用される規範ではありません。本記事では「どういう条件のときに権利を発注側へ寄せるか」という判断基準としてのみ引用しています。また、産業技術力強化法に関する記述は、同ガイドライン自身の記載を引用したものです。
• モデル契約書もガイドラインも、雛型・ルールであって法令ではありません。 条文番号は本記事執筆時点の版のものです。実際の契約書はベンダーごとに条文構成が異なります。
• 本記事は法律上の助言ではありません。 著作権法の条文の整理は公開されている法令テキストに基づいていますが、個別の契約書の解釈、権利の対抗要件、倒産時の扱いなどは弁護士に確認してください。

見積書の納品条件をレビューする

納品物欄と権利条項の抜けを自分で洗い出すのは手間がかかります。koromoでは、受け取った見積書のテキストから項目を確認できる要件・契約範囲チェック（登録不要）を公開しています。登録不要で、結果を見るまでメールアドレスの入力も必要ありません。テキストの抽出はブラウザ内で行い、送信前に内容を確認できます。

見るのは見積書の側です。 納品物欄が一式で止まっていないか、成果物と工程が対応しているか、受入条件や対象外の記載があるか、環境構築とリリースの範囲が書かれているか——本記事でいう①納入物と、③再現性のうち見積書に現れる部分を確認します。一方、②権利（著作権の帰属、第27条・第28条の特掲、汎用部品の留保範囲）は契約書の条項に書かれるもので、診断の項目には入っていません。 上の判定表と質問リストは、診断と役割を分けて使ってください。

この記事の質問リストで受け取った回答を、見積書とあわせて貼り付ける使い方も想定しています。診断結果は法的・会計的・技術的な最終判断ではなく、ベンダーへ次に何を聞くかを整理するためのものです。現在の提案のまま進めるのが合理的、という結論になることもあります。

よくある質問

まとめ

システム開発でソースコードの納品条件を確認するとき、見るべきは「渡してもらえるか」という一点ではありません。別の会社が受け取って、再ビルドして、保守できる状態になるかです。

手順を整理します。

1. 納品条件を納入物・権利・再現性の3層に分けて読む。見積書の金額に現れるのは①だけ
2. 納品物欄がA〜Eのどの型かを見分ける。AとBは別紙の有無をまず聞く
3. 権利条項に「著作権法第27条及び第28条の権利を含む」の括弧書きがあるかを確認する
4. ベンダー帰属の提示は不当ではない。公的なモデル契約書の第一案と同じ立場である
5. 権利を寄せる判断基準は「自社固有の部分か（汎用品ではないか）」「継続的に改修する予定があるか」の2点
6. 環境構築手順書とクリーンビルド検証が計上されているかを確認する。ここが過小見積もりの温床
7. 回答を説明済み／要確認／高リスク／判断不能の4状態へ仕分ける。判断不能があるうちは金額を比較しない
8. 「できません」には根拠があるかだけを見る。根拠のある「できません」は代替手段の交渉へ、根拠の無い「できません」は発注判断の見直しへ

そして、この記事で最も伝えたいことをもう一度書きます。権利と資料の条件は、契約前にしか安く決められません。 稼働してから同じ条件を要求すると、相手にとっては追加作業であり、こちらにとっては選択肢が減った状態での交渉になります。見積書を受け取った今が、その条件を金額とセットで決められる最後のタイミングです。