ソースコード譲渡の費用と契約｜改変できる条件

ソースコードの譲渡費用とは？まず何に対して払うのか

ソースコードの譲渡費用とは、納品物を動かす権利への対価ではなく、著作権という財産権を開発会社から自社へ移すことへの対価です。開発費を全額払ったのだからコードは自社のものになる、という理解で見積書を読むと、この行の意味がわかりません。

納品されること、使えること、改変できることは別の話です

発注したシステムについて、御社が手にするものは3つの層に分かれます。

層	内容	根拠になるもの
納品	ソースコードのファイルを受け取る	納品物の定義 (契約書の別紙等)
利用	受け取ったコードを業務で動かす	著作権の譲渡または利用許諾
改変	コードに手を入れて機能を変える	翻案等の権利の扱い (後述)

ファイルを受け取っただけでは、改変まで自由にできるとは限りません。著作権法第15条第2項は、法人等の発意に基づきその業務に従事する者が職務上作成するプログラムの著作物の著作者は、別段の定めがない限りその法人等とすると定めています (出典: 著作権法、e-Gov法令検索)。つまり開発会社の従業員が書いたコードの著作者は、原則として開発会社です。

費用を払って発注したという事実だけでは、権利は自動的に移りません。移すには契約で取り決める必要があり、その取り決めの対価が譲渡費用です。

さらに、譲渡の書き方によって結果が変わります。著作権法第61条第2項は、著作権を譲渡する契約において第27条または第28条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は譲渡した者に留保されたものと推定すると定めています (出典: 著作権法、e-Gov法令検索)。改変に関わる権利が残る場合があるということです。この特掲の確認方法は後述します。

あわせて、対価を払っても移らない権利もあります。著作者人格権は著作者の一身に専属し、譲渡することができません (出典: 著作権情報センター「著作者にはどんな権利がある？」)。

2026年10月時点の前提と、この記事で扱う範囲

本記事の内容は2026年10月時点の法令とIPAの公開資料に基づきます。扱う範囲は、業務システムの受託開発で納品されるソースコードです。

扱うもの	扱わないもの
受託開発したソースコードの譲渡と利用許諾	パッケージやSaaSの利用料
譲渡の対価が見積書に現れる形	開発費本体の工数単価の算定
改変の可否を決める契約上の記載	著作権侵害が起きた後の紛争対応

開発費本体の相場や工数単価の見方は別記事で扱っています。ここでは開発費とは別に積まれる、権利についての対価だけを見ていきます。

譲渡の対価は見積書のどこに現れるか

譲渡の対価は開発費とは別の行として積まれるのが通常で、権利譲渡費、著作権譲渡料、二次利用許諾料といった名目で記載されます。開発費の中に溶け込ませて書かれることもあり、その場合は内訳を聞かないと有無が判別できません。

金額そのものは、案件の規模と要件により大きく変動します。流用するコードの割合や保守を継続するかどうかで変わるため、相場という形では示せません。変動の要因は後述します。

初期費用、月額、オプション、従量課金に分けた内訳の見方

見積書を次の4つに分けて並べ直すと、権利についての対価がどこにあるかが見えます。

区分	典型的な項目	権利に関わる行の例
初期費用	要件定義、設計、実装、テスト、移行	著作権譲渡費、権利譲渡一時金
月額	保守、監視、障害対応、ホスティング	継続利用許諾料
オプション	追加開発、帳票追加、他システム連携	二次利用許諾料、再委託許諾料
従量課金	API呼び出し、ストレージ、通数	該当なし

確認の軸は3つです。

1. 初期費用に権利の行があるか。無い場合、譲渡が含まれているのか、利用許諾だけなのかを確かめます。
2. 月額に利用許諾料が入っていないか。入っていれば、保守を解約した後も使い続けられるかが論点になります。
3. オプションに再委託や二次利用の許諾料があるか。あれば、別の会社に保守を移す時点で費用が発生する設計です。

名目が書かれていないときに確認する2つの質問

権利に関する行が見積書に見当たらないときは、次の2点を書面で尋ねます。口頭の回答ではなく、見積書か契約書の文言として残すことが重要です。

1. 納品後の著作権は、どちらに帰属する想定ですか。譲渡であれば、その対価はどの行に含まれていますか。
2. 著作権法第27条と第28条の権利は、譲渡の対象に含まれていますか。

2番目を尋ねる理由は、著作権法第61条第2項が、譲渡契約でこの2条の権利が特掲されていないときは譲渡した者に留保されたものと推定すると定めているためです (出典: e-Gov法令検索「著作権法」昭和45年法律第48号)。特掲の対象になる条文は第27条と第28条の2条だけですので、確認は短く済みます。条文の中身と確認手順は次のセクションで扱います。

なお、契約書の文言を一から用意する必要はありません。IPAは「情報システム・モデル取引・契約書 (第二版)」を2020年12月22日に公開しており、権利の帰属に関する条項を公的なひな形から確認できます (出典: IPA「情報システム・モデル取引・契約書 (第二版)」)。

契約書に何と書いてあれば改変できるのか

著作権法第61条第2項により、第27条と第28条の権利が譲渡の目的として特掲されていなければ、これらの権利は開発会社に留保されたものと推定されます (出典: e-Gov法令検索「著作権法」昭和45年法律第48号)。条文は「著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する」と定めています。

つまり「本件成果物の著作権は甲に譲渡する」とだけ書かれた契約書では、改変に関わる権利が相手方に残っている前提で読まれます。

第27条と第28条が特掲されているかを確認する

特掲が必要な条文は2条だけです。それぞれの中身は次のとおりです。

条項	内容	ソースコードでの意味
第27条 (翻訳権、翻案権等)	著作者は、その著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案する権利を専有する	コードの改修や機能追加は翻案にあたり得ます
第28条 (二次的著作物の利用に関する原著作者の権利)	二次的著作物の原著作物の著作者は、当該二次的著作物の利用に関し、この款に規定する権利で当該二次的著作物の著作者が有するものと同一の種類の権利を専有する	改修後のコードを使い続ける場面にも元の著作者の権利が及び得ます

出典はいずれもe-Gov法令検索「著作権法」です。確認の手順は次の3段です。

1. 契約書の著作権条項を開き、第27条と第28条の条番号が明記されているかを見ます。
2. 明記されていない場合、「著作権法第27条および第28条に規定する権利を含む」という文言の追加を依頼します。
3. 追加に応じられない場合は、改変と第三者への再委託を認める利用許諾の形で代替できるかを確認します。

実装者の立場から申し上げると、この2条の扱いが決まっていないコードは、数年後の改修で必ず問題になります。改修を別の会社に出す場面や、御社の中で手を入れる場面で、都度許諾を取り直すことになるためです。

著作者人格権と同一性保持権は譲渡では移りません

著作権という財産権を譲り受けても、著作者人格権は移りません。著作権法第59条は、著作者人格権は著作者の一身に専属し、譲渡することができないと定めています (出典: e-Gov法令検索「著作権法」)。

関連するのが第20条第1項の同一性保持権です。著作者は、その著作物及びその題号の同一性を保持する権利を有し、その意に反してこれらの変更、切除その他の改変を受けないものとすると定められています (出典: e-Gov法令検索「著作権法」)。

そのため実務では、著作権の譲渡とあわせて著作者人格権の取り扱いを別に定めるのが通例です。確認するのは次の2点です。

1. 著作者人格権の不行使について、契約書に条項があるか。
2. 不行使の範囲が、改修や第三者への委託を含んでいるか。

IPAのモデル契約書を出発点にする

条項を一から起草する必要はありません。IPA (独立行政法人情報処理推進機構) は「情報システム・モデル取引・契約書 (第二版)」を2020年12月22日に公開しています (出典: IPA「情報システム・モデル取引・契約書 (第二版)」)。受託開発や保守運用に関するモデル契約がWord形式で提供されており、自社向けに編集して使えます。

公的機関が公開しているひな形を基準にすると、開発会社との交渉も「ひな形との差分」の話に整理できます。差分がある箇所だけを説明してもらえば、確認の範囲が狭く済みます。

そもそも著作者は誰になるのか

著作権法第15条第2項により、開発会社の従業員が職務上作成したプログラムの著作者は、別段の定めがない限りその開発会社です (出典: e-Gov法令検索「著作権法」昭和45年法律第48号)。条文は「法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする」と定めています。

ここが譲渡費用の出発点です。相手が権利を持っているからこそ、移すための対価が発生します。

発注して費用を払っても権利は自動では移りません

発注者が費用を負担し、仕様も発注者が決めたとしても、それだけでは著作者は変わりません。第15条第2項が見ているのは、誰が発意したかではなく、作成した人がどの法人等の業務に従事していたかです。

なお、デザインや文章には第15条第1項が適用されます。第1項には「その法人等が自己の著作の名義の下に公表するもの」という要件がありますが、プログラムの著作物を定めた第2項にはこの要件がありません (出典: e-Gov法令検索「著作権法」)。ソースコードは公表の名義にかかわらず、開発会社が著作者になり得るということです。

権利を御社に移す方法は2つに整理できます。

方法	内容	費用の現れ方
譲渡	著作権 (財産権) を御社に移す	権利譲渡費として初期費用に積まれます
利用許諾	権利は開発会社に残し、使う範囲を契約で定める	利用許諾料として月額やオプションに現れます

どちらを選ぶかで費用と自由度が変わります。その比較は次のセクションで扱います。

外部の個人や再委託先が書いたコードがある場合の確認点

第15条第2項が適用されるのは、法人等の業務に従事する者が職務上作成した場合です。外部の個人事業主に委託した部分や、再委託先が書いた部分は、この条文の射程が異なります。

確認するのは次の3点です。

1. 再委託の有無。契約書に再委託を認める条項があるか、実際に再委託されているかを尋ねます。
2. 再委託先からの権利の取得。開発会社が再委託先から権利を取得済みであることを、契約書上で表明してもらいます。
3. 外部の個人が書いた部分の扱い。業務委託の場合は職務著作にならないため、個別の譲渡合意が必要になります。

実装の現場では、UIの一部を外部のデザイナが作り、特定の処理を別の会社が作るという分業は珍しくありません。開発会社が全体をまとめて納品していても、権利の取得が途中で抜けていると、御社に移せる範囲も抜けます。

そのため、権利の帰属を定める条項に加えて、開発会社が第三者の権利を適法に取得していることの表明保証を置くかどうかを確認します。表明保証があれば、後から第三者の権利が判明したときの責任の所在が契約書の中で決まります。

あわせて、オープンソースソフトウェアが含まれる場合は、譲渡とは別にライセンス条件が残ります。この点は費用を左右する要因として後述します。

譲渡と利用許諾、どちらを選ぶと費用はどう変わるか

譲渡は対価が上がる代わりに改変や他社への移管が自社判断でできるようになり、利用許諾は対価が下がる代わりに使える範囲が契約で限定されます。どちらが正しいというものではなく、そのシステムを何年どう使うかで決まります。

譲渡、利用許諾、共有の3つの型を表で比べる

実務で提示される型は、おおむね次の3つです。

型	権利の所在	改変の自由度	他社への移管	対価の現れ方
譲渡	御社 (第27条・第28条の特掲が前提)	御社の判断で可能	可能	初期費用に権利譲渡費
利用許諾	開発会社	契約で定めた範囲のみ	原則として要許諾	月額やオプションに許諾料
共有	御社と開発会社の共有	原則として相手方の同意が必要	相手方の同意が必要	譲渡より低めだが制約が残る

共有は折衷案として提案されることがありますが、著作権が共有になると持分の行使に相手方の同意が必要になるため、改変の自由度という点では利用許諾に近い扱いになります。安く見えても、後の改修で毎回同意を取る前提になるかを確認してください。

将来の保守を自社や別の会社に移す予定があるかで選ぶ

判断の基準は、費用の多寡ではなく移管の予定です。次のように整理できます。

1. 保守を同じ開発会社に長く任せる前提であれば、利用許諾で足りる場面が多くなります。権利の対価を払わない分、初期費用は下がります。
2. 数年後に自社の情シスで改修する、または別の会社に保守を移す可能性があるなら、譲渡を選び、第27条と第28条を特掲してもらいます。
3. 社内で判断がつかない場合は、まず利用許諾で始め、譲渡に切り替える際の対価を契約時に定めておく方法があります。切り替えの価格を後から交渉すると、相手に選択権が集まります。

3番目については、契約書に「将来の譲渡を請求できる権利と、その対価の算定方法」を置けるかを尋ねてみてください。金額そのものを今決めなくても、算定方法が決まっていれば交渉の余地が残ります。

当社の実装経験では、譲渡が必要になる局面は、機能追加よりも先に外部連携の要件で訪れます。会計ソフトや販売管理との連携を後から足す段階で、既存のコードに手を入れる必要が出るためです。導入時点で連携の予定がなくても、3年先に増える可能性があるかどうかは一度検討しておく価値があります。

なお、利用許諾を選ぶ場合は、保守契約を解約した後も使い続けられるかを必ず確認します。月額に利用許諾料が含まれている構成では、解約と同時に使う根拠がなくなる設計もあり得ます。

費用を左右する要因

譲渡の対価を動かすのは、流用部分の割合、開発会社が持つ既存ライブラリの扱い、OSSのライセンス条件、保守の継続前提という4つの要因です。相場表が作れないのはこの4つが案件ごとに違うためで、金額は案件の規模と要件により大きく変動します。

要因	対価が上がる方向	対価が下がる方向
流用部分の割合	自社向けに新規で書いた部分が多い	既存資産の流用が多い
既存ライブラリ	譲渡の対象に含める	使用許諾に留め、譲渡対象から外す
OSSの条件	条件の調査と置き換えが必要	条件が緩く、そのまま使える
保守の継続	保守を他社に移す前提	同じ会社に保守を継続して任せる

開発会社の既存資産やフレームワークが混ざっている場合

受託開発のコードは、御社のために書いた部分と、開発会社が他案件でも使う部分が混ざっているのが通常です。後者まで譲渡すると開発会社は自社の資産を失うため、対価は高くなります。

現実的な落としどころは、範囲を分けることです。確認の順序は次のとおりです。

1. 納品物のうち、御社専用に書いた部分と開発会社の既存資産の境界を、ファイルやモジュール単位で示してもらいます。
2. 御社専用の部分は譲渡、既存資産は改変と再委託を認める永続的な使用許諾とする形を検討します。
3. 使用許諾とする部分について、許諾が保守契約の終了後も続くかを契約書で確かめます。

境界が示せない、または示したがらない場合は、その点自体が後の改修の難易度を表しています。

OSSを含むコードは譲渡しても条件が残ります

オープンソースソフトウェアは、著作権の譲渡を受けてもライセンス条件が消えません。条件は元の権利者が定めたもので、開発会社と御社の契約で変えられるものではありません。

確認するのは次の2点です。

1. 使用しているOSSの一覧と、それぞれのライセンス種別を納品物に含めてもらいます。
2. 自社で改変して配布する予定がある場合、ソースコードの開示義務を伴う条件が含まれていないかを確認します。

社内利用に限るのであれば、多くの条件は問題になりません。問題になるのは、そのシステムを製品として外部に提供する計画がある場合です。将来の構想も含めて、一覧を受け取る段階で開発会社に伝えておくほうが確実です。

保守契約を切る前提かどうかで金額が変わる理由

開発会社にとって、保守の継続は収益の前提です。譲渡を受けて保守も他社に移すのであれば、開発会社は将来の売上を失うため、その分が譲渡の対価に反映されます。

逆に、保守を同じ会社に継続して任せる前提であれば、譲渡の対価は下がる傾向にあります。交渉の材料としては、次の2つを組み合わせる形が現実的です。

1. 保守を一定期間は継続する前提を示し、その上で譲渡を依頼する。
2. 権利の対価を一時金ではなく、保守費に分散して支払う形を相談する。

いずれにしても、見積もりの金額だけを比べると判断を誤ります。同じ金額でも、権利が移る見積もりと移らない見積もりでは、3年後に御社が取れる選択肢が変わります。

発注前に確認する項目と、当社での進め方

見積もりを受け取った段階で、権利の帰属、特掲の有無、人格権の取り扱い、OSSの一覧という4点を書面で確認しておけば、後からの手戻りを避けられます。契約を結んだ後に確認すると、相手に交渉の主導権が移ります。

確認項目のチェックリスト

発注の前に、次の7項目を見積書か契約書の文言として確認してください。

番号	確認項目	確認の形
1	納品後の著作権の帰属	譲渡か利用許諾かを契約書の条項で確認
2	第27条と第28条の特掲	条番号が明記されているか
3	著作者人格権の不行使	不行使条項の有無と、その範囲
4	権利の対価の所在	見積書のどの行に含まれているか
5	再委託先からの権利取得	開発会社による表明保証の有無
6	OSSの一覧とライセンス種別	納品物に含まれるか
7	保守終了後の利用の継続	解約後も使い続けられるか

7項目のうち、2番と7番は見落とされやすい箇所です。2番は条番号という形式の話なので、確認そのものは1分で済みます。7番は利用許諾を選ぶ場合に効いてきます。

当社の実装経験では、他社が作ったシステムの改修を引き継ぐ相談をいただいたとき、作業の前に権利関係の確認で時間を使うことが少なくありません。契約書に第27条と第28条の記載がないと、元の開発会社に許諾を取るところから始めることになります。発注時の1分の確認が、数年後の数週間を節約します。

当社が契約前に提示している範囲

当社では、業務システムの開発をお受けする際に、上記の7項目に相当する内容を見積書の段階で明記しています。権利の帰属と特掲の扱いを先に決めておくほうが、御社にとっても当社にとっても後の話が早いためです。

既存のシステムをお持ちで、その契約書に何が書かれているかを確かめたい段階であれば、無料診断 (/diagnostic) で現状の整理からご相談いただけます。これから新しく発注する段階で、見積書の権利の行についてご質問がある場合は、お問い合わせ (/contact) からお送りください。

なお、当社のDXコンサル・機械学習開発は500,000円から、業務システムに付随するWeb制作は300,000円からお受けしています。権利の譲渡を含める場合の対価は、本記事で挙げた4つの要因によって変わりますので、要件を伺ったうえで内訳としてお示しします。

契約書の条文は、読む前に身構える類の文書ではありません。確認するのは条番号と、いくつかの文言の有無だけです。発注の前に目を通しておけば、そのシステムを何年使えるかが御社の手に残ります。

よくあるご質問

この記事に関して多い質問と回答をまとめます。いずれも2026年10月時点の法令と公開資料に基づく内容です。

ソースコードの譲渡費用はいくらが目安ですか

一般的な相場として示せる金額はありません。政府統計や公的機関の調査に、ソースコードの譲渡の対価を集計した数値は見当たらないためです。金額は案件の規模と要件により大きく変動し、流用部分の割合、既存ライブラリの扱い、OSSの条件、保守の継続前提の4つで動きます。

相場を聞くよりも、受け取った見積書のどの行に権利の対価が含まれているかを確認するほうが実務の役に立ちます。

契約書に「著作権は発注者に帰属する」と書いてあれば、自由に改修できますか

その一文だけでは足りません。著作権法第61条第2項は、著作権を譲渡する契約において第27条または第28条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は譲渡した者に留保されたものと推定すると定めています (出典: e-Gov法令検索「著作権法」昭和45年法律第48号)。

改修は第27条の翻案にあたり得ますので、条番号が明記されているかを確認してください。

ソースコードを納品してもらえば、著作権も一緒に移るのですか

移りません。ファイルの受け取りと権利の移転は別の事柄です。著作権法第15条第2項により、法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、別段の定めがない限りその法人等とされます (出典: e-Gov法令検索「著作権法」)。

開発会社の従業員が書いたコードの著作者は原則として開発会社ですので、御社に移すには契約での取り決めが必要です。

著作権の譲渡を受けなくても、別の会社に保守を任せられますか

利用許諾の範囲によります。改変と第三者への再委託を認める許諾が契約書にあれば、譲渡を受けなくても保守を移せる場合があります。

確認するのは次の2点です。

1. 許諾の範囲に改変と第三者への委託が含まれているか。
2. 保守契約を解約した後も許諾が続くか。

どちらも書かれていない場合、保守の移管時に改めて許諾の交渉が必要になります。

開発会社が使っている既存のライブラリやOSSも譲渡の対象になりますか

通常は対象外です。開発会社が他案件でも使う既存資産は、譲渡ではなく使用許諾に留めるのが一般的で、その代わり譲渡の対価は下がります。

オープンソースソフトウェアは、著作権の譲渡を受けてもライセンス条件が消えません。条件を定めているのは元の権利者で、開発会社と御社の契約では変えられないためです。使用しているOSSの一覧とライセンス種別を納品物に含めてもらい、外部への提供を予定している場合は条件を事前に確認してください。

関連リンク

• ソースコードの譲渡と契約の現状を無料診断で整理する
• 業務システム開発とソースコード譲渡を含む場合の料金
• システム開発の外注と契約に関する記事一覧