案件を受けて開発を進めるとき、外部のライブラリやオープンソースをどこまで自由に組み込んでよいのか、判断に迷う場面があります。契約書に何が書かれているかを確かめないまま作業を続けると、責任の所在があいまいなまま案件が進むことになります。IPAが公開した資料は、システム開発の契約でどこに知的財産権侵害の論点が置かれているかを整理しています¹。この記事では、その整理をもとに、責任の分け方がどのような基準で決まっているのかを確認していきます。

1. 侵害の話は役割分担から始まる

役割分担があいまいなまま進めるとどうなるか

案件を受けて開発を進めるとき、誰がどの部分を担当するのかを最初に決めておくかどうかで、後から起きる話の重さが変わってきます。担当の線引きを曖昧にしたまま作業を始めると、途中で問題が見つかったときに、まず責任の所在を探す作業から始めることになります。

IPAが公開した資料は、責任関係や作業分担等が明確になっていないと、損害賠償請求の訴訟などのトラブルに発展するケースもあるとしています¹。これは特定の案件を指した話ではなく、システム開発全般に向けた注意点として整理されたものです。

個人で案件を受ける場合も、この整理は無関係ではありません。自分がどの範囲を担当し、どの部分を外部の部品に頼るのかを最初に言葉にしておくことが、後から起きるやり取りの手間を減らします。

確認から始める理由

開発の途中で問題が見つかると、まず「誰の担当だったか」を確かめる作業から始まります。担当の範囲が打ち合わせの記録に残っていれば、この確認は短い時間で済みます。

反対に、口頭でのやり取りだけで進めてきた案件では、確認そのものに時間がかかります。契約書や打ち合わせの記録に、担当する範囲を残しておくことが、最初にできる備えになります。

次の章では、外部の部品に関わる論点が、契約の検討の中でどのように整理されているかを見ていきます。

図の作成：Remogu編集部。契約が進む段階と論点が集まりやすい場所を整理したもので、統計データではありません

2. 外部の部品が論点として整理されている

整理されている論点

IPAの資料では、契約書のひな型を検討する中で、いくつかの論点が整理されています。その中に、外部の部品に関わる話が独立した項目として含まれています。

主要論点として、第三者ソフトウェアに関わる瑕疵が整理されているとされています²。ここでいう第三者ソフトウェアとは、自分たちで作った部分ではなく、外から取り入れた部分を指します。

論点として名前が付けられているということは、それだけ実務で確認が求められる場面が多いことの表れでもあります。契約書を読むときに、見落としやすい箇所の一つです。

論点として扱われる意味

ある事柄が論点として整理されるのは、判断が割れやすく、あらかじめ言葉にしておく価値がある場合です。第三者ソフトウェアの扱いも、その一つとして位置づけられています。

個人で案件を受ける立場からすると、この論点の存在を知っているかどうかで、契約の文面を読むときの着眼点が変わります。読み飛ばしやすい条ほど、確認する価値があります。

表1は、ここまでに触れた資料の整理を短くまとめたものです。

整理されている点	内容	出典
責任関係・作業分担	明確でないと損害賠償請求の訴訟などのトラブルに発展するケースがある	IPA1
第三者ソフトウェアに関わる瑕疵	主要論点として整理されている	IPA2

3. 利用の際に共有される情報がある

契約プロセスガイドの位置づけ

契約書のひな型とあわせて、IPAは契約を結ぶまでの進め方を示したガイドも整理しています。この中に、外部の部品を利用する場面についての記載があります。

契約プロセスガイドには、第三者ソフトウェアの利用の際に共有されるべきリスク情報が挙げられているとされています³。誰が何を伝えるかという、手続きの段階の話として整理されています。

この整理は、情報を伝える側と受け取る側がいることを前提にしています。個人で案件を受ける場合、自分がどちらの立場で関わっているのかを確かめておくと、確認する項目がはっきりします。

共有される情報の中身

リスク情報として共有される対象は、外部の部品そのものだけでなく、その部品を使うことで生じ得る論点も含まれます。ガイドはこの共有を、契約を結ぶ前の段階に位置づけています。

情報が共有されないまま作業が進むと、後になって「聞いていなかった」という状態が生まれやすくなります。共有の有無を、打ち合わせの記録として残しておくことが備えになります。

次の章では、外部の部品の中でも特に確認が求められるオープンソースについて見ていきます。

4. オープンソースはリスク評価の対象

OSSが評価の対象になる理由

オープンソースは、誰でも取り入れやすい分、利用条件の確認が省かれやすい部分でもあります。契約プロセスガイドは、この点についても言及しています。

契約プロセスガイドには、オープンソースを利用する場合のリスク評価が挙げられているとされています⁴。無償で使えることと、確認が求められないことは別の話として扱われています。

個人で開発を担う場合、どのオープンソースを、どの条件で取り入れたかを記録しておくことが、後から確認を求められたときの備えになります。

確認しておきたい流れ

リスク評価という言葉は、判定を一度で終える作業を指すものではありません。取り入れる部品が変わるたびに、条件を確かめ直す継続した作業として位置づけられています。

案件によって、確認の主体がベンダ側にある場合と、ユーザ側にある場合があります。自分の案件でどちらに当たるのかを、契約の文面から確かめておくと迷いが減ります。

図2は、ここまでの2つの論点を並べたものです。

図の作成：Remogu編集部。契約プロセスガイドが挙げている2つの点を整理したもので、統計データではありません

5. 責任の条と、外部の部品の条

知的財産権侵害の責任の条

契約書のひな型には、知的財産権侵害の責任の条が置かれているとされています⁵。これは、外部の部品に限らず、開発した成果物全体に関わる条として位置づけられています。

条が置かれているということは、この論点が個別の案件ごとの取り決めに任されているのではなく、あらかじめ検討された型があることを意味します。

個人で案件を受ける場合も、契約書にこの条があるかどうかを確かめることが、確認の出発点になります。名称が分かれば、契約書の中で探しやすくなります。

第三者ソフトウェアの利用の条とFOSSの利用の条

契約書のひな型には、第三者ソフトウェアの利用の条と、FOSSの利用の条が置かれているとされています⁶。FOSSとは、自由に使える公開されたソフトウェアを指す言葉です。

2つの条が別々に置かれているのは、有償で調達する部品と、公開されている部品とで、確認する内容が異なるためです。呼び名が違えば、探す条も変わります。

表2は、契約書のひな型に置かれているこれらの条を整理したものです。

条の呼び名	内容	出典
知的財産権侵害の責任の条	開発した成果物全体に関わる責任を扱う	IPA5
第三者ソフトウェアの利用の条	有償で調達する外部の部品の扱いを定める	IPA6
FOSSの利用の条	公開されているソフトウェアの扱いを定める	IPA6

6. アジャイル型の契約にも責任の条がある

アジャイル型モデル契約の位置づけ

ここまでの条は、開発の進め方をあらかじめ決めてから作業に入る、従来型の契約を念頭に置いたものです。案件の中には、区切りを短くして進めるアジャイル型で契約するものもあります。

アジャイル型の開発用モデル契約にも、知的財産権侵害の責任の条が置かれているとされています⁷。進め方の型が変わっても、この論点自体はなくならないことを示しています。

短い区切りで進める案件に関わるときも、契約の類型だけを見て確認を省く理由にはなりません。

契約類型が変わっても条は置かれている

アジャイル型は、要件を都度確定させながら進める性質上、外部の部品を追加する場面が途中で増えることもあります。条があることは、その都度の確認を求める根拠にもなります。

契約の型が違っても、確認する項目そのものは大きく変わりません。図4は、契約の類型によらず確かめておきたい項目を並べたものです。

次の章では、責任の分け方について、資料に示されている案を見ていきます。

図の作成：Remogu編集部。契約の類型によらず確かめておきたい項目を整理したもので、統計データではありません

7. 責任の分け方の案と、選定の主体

損害賠償額の負担の案

知的財産権侵害の責任について、IPAの資料はいくつかの案を示しています。まず、費用の負担の仕方についての案です。

知的財産権侵害の責任には、ユーザが権利者に対して支払うこととなった損害賠償額等をベンダが負担することとした案が示されているとされています⁸。これは示されている案の一つであり、すべての案件に当てはまる決まりではありません。

紛争解決を進める主体

費用の負担とは別に、紛争そのものへの対応を誰が進めるかという論点もあります。

知的財産権侵害の責任には、ユーザ主導で紛争解決の対応をする案も示されているとされています⁹。対応を進める主体があらかじめ定まっていれば、途中での役割の混乱を避けやすくなります。

部品を選ぶ主体の案

外部の部品そのものを、誰が選ぶかという論点にも案が示されています。

第三者ソフトウェアの利用には、ベンダが主体で選定する場合とユーザが主体で選定する場合の案が示されているとされています¹⁰。どちらの案が使われるかは、契約ごとの取り決めによって異なります。

案	内容	出典
費用負担の案	ユーザが権利者に支払った損害賠償額等をベンダが負担する	IPA8
紛争解決の案	ユーザ主導で紛争解決の対応をする	IPA9
選定主体の案（ベンダ主体）	ベンダが主体で第三者ソフトウェアを選定する	IPA10
選定主体の案（ユーザ主体）	ユーザが主体で第三者ソフトウェアを選定する	IPA10

図の作成：Remogu編集部。IPAの資料に示されている案を整理したもので、実際にどの案が使われるかは案件ごとに異なります

案件を受ける立場からすると、これらの案のどれが自分の契約に置かれているかを確かめることが、実務でできる備えになります。Remoguは、案件の90%以上がフルリモート可能な、リモートワーク案件に特化したエンジニアマッチングです。まず登録して、自分が関わる案件の契約でどの条が置かれているかを確かめることから始められます。

初めて受ける案件でも、知的財産権侵害の話は関係ありますか

経験の長さに関わらず、外部の部品を組み込む作業がある案件では、この論点は関係します。契約書に知的財産権侵害の責任の条があるかどうかを確かめることが、最初の案件でもできる備えです。

副業として案件に関わる場合も、責任の考え方は同じですか

稼働する時間の長さではなく、外部の部品を選んだ主体や契約に置かれている条の内容によって整理は変わります。副業として関わる場合も、契約の文面を確かめることが基本になります。

地方在住でオンラインだけで案件を進める場合も、確認する点は変わりませんか

場所によって確認する項目が変わるわけではありません。契約書のひな型に置かれている条は、進め方が対面かオンラインかを問わずに適用される整理です。

経験がまだ少ない場合、外部の部品の扱いをどう確認すればよいですか

自分がどの部分を担当し、どの部品を外部から取り入れたのかを、打ち合わせの記録として残すことから始められます。条の有無を契約書で確かめる作業自体は、経験の長さを問いません。

契約書にどんな内容が整理されているか、先に確認する方法はありますか

契約を結ぶ前の段階で、知的財産権侵害の責任の条と、第三者ソフトウェアやFOSSの利用の条があるかどうかを確認する方法があります。整理された論点を知っておくと、契約書のどこを読めばよいかがわかりやすくなります。

稼働の日数が少ない案件でも、条の内容は変わりませんか

稼働の日数の多さと、契約に置かれている条の内容は別の話です。日数が少ない案件でも、外部の部品を組み込む作業があれば、同じ条が関わってきます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」起点の問題（2025年4月・2026年9月確認）
＊2 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」他人の部品（2025年4月・2026年9月確認）
＊3 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」共有する情報（2025年4月・2026年9月確認）
＊4 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」OSSの評価（2025年4月・2026年9月確認）
＊5 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」侵害の責任（2025年4月・2026年9月確認）
＊6 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」外部の部品の条（2025年4月・2026年9月確認）
＊7 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」アジャイル版の責任（2025年4月・2026年9月確認）
＊8 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」負担の案（2025年4月・2026年9月確認）
＊9 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」もう一つの案（2025年4月・2026年9月確認）
＊10 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」選定の主体（2025年4月・2026年9月確認）