システム開発の納品物一覧と著作権｜ソースコードは誰のもの？AI開発で増える引き継ぎ資料も【2026年10月】

システム開発の納品物は「プログラム一式」「資料」「権利」「アカウント」の4つに分けて、見積を依頼する時点で一覧にしておくものです。そして、代金を払ってもソースコードの著作権は自動では発注側に移りません。契約書に譲渡を書かなければ、原則として作った開発会社側に残ります。

必要なものが抜けたまま保守会社を替えると、開発会社の公開情報では移管だけで30万〜100万円、期間は2〜4か月（資料が足りなければ3〜6か月）かかります。AIを組み込むシステムでは、さらに「AIへの指示文」「使っているAIの版と提供終了日」「何をもって合格としたかの記録」といった、一般的な納品物の一覧には載っていないものが増えます。

この記事でわかること

• システム開発で受け取るべき納品物の一覧と、それぞれが無いと何が起きるか
• ソースコードの著作権は誰のものか、契約書にどう書けば発注側に移るか
• AI開発で追加になる6つの納品物と、AIが書いたコードの著作権の扱い
• 検収の注意点、抜けていたときの費用、見積依頼に貼れるチェックリスト

こんな方に向けて書いています：これからシステム開発やAI開発を発注する経営者・事業責任者・情報システム担当の方、今のシステムのソースコードや設計書が手元になく保守会社を替えられずに困っている方。

システム開発の納品物と権利の早見表

「受け取るもの」と「その権利が誰のものになるか」は、別々に契約で決める必要があります。

システム開発の納品物が足りないと、どこで困るか

出典: Anthropic Claude Platform Docs 公式

納品物の不足は、納品された直後にはまず表に出ません。システムが動いている間は誰も困らないからです。問題になるのは、次の3つの場面です。

場面1：保守会社を替えたい、社内の担当者が辞めた

「保守費が高いので別の会社に頼みたい」「作った会社の担当者がいなくなった」というときに、ソースコード、設計書、サーバーやクラウドのアカウントが手元にないと、新しい会社は現状の調査から始めることになります。移管の初期費用だけで30万〜100万円、期間は資料が整っていれば1〜2か月、資料が足りなければ3〜6か月が目安です。

場面2：使っているAIが提供終了になった

AIを組み込んだシステムの多くは、外部のAIサービスを呼び出して動いています。提供元は古い版のAIを順に提供終了にしていきます。たとえばAnthropic社は、公開しているモデルの提供終了を少なくとも60日前に通知し、終了後の呼び出しは失敗すると明記しています。

2026年だけでも、Claude Sonnet 4とClaude Opus 4が6月15日に、Claude Opus 4.1が8月5日に提供を終えました。さらに2026年9月30日にはClaude Sonnet 4.5（2025年9月29日版）が非推奨となり、2026年11月30日に提供終了予定と公表されています。1年前に作ったシステムが、すでに乗り換えの対象になっているということです。なお、Amazon BedrockやGoogle Cloud経由で使っている場合は、それぞれの提供元が別の日程を定めています。

このとき、AIに渡している指示文、どの版のAIを使っていたか、どんな質問でどの水準の答えが出れば合格としたか、の記録が手元にないと、新しい版に切り替えたあとに「前と同じ品質か」を誰も確かめられません。乗り換えの作業には、動作確認・指示文の調整・再テストで延べ5〜15人日（1人が1日働く量を1人日とする）、1回あたり約15万〜75万円かかります（1人日3〜5万円と置いた当社試算）。記録がなければ、その前に「以前はどう動いていたか」を調べ直す手間が加わります。

出典：Anthropic「Model deprecations」

場面3：PoCの後、本開発を別の会社に頼みたい

試作と検証（PoC）を頼んだ会社とは別の会社に、本開発を任せたいケースです。PoCの契約で「試作のプログラムや検証の記録を誰が持ち、どこまで渡すか」を決めていないと、次の会社はPoCの結果をそのまま使えません。

かといって、PoCが終わってから「成果物を無償で全部渡してほしい」と求めることは、2026年6月に公正取引委員会などが公表した指針で、問題となり得る行為として例示されています。PoCで何を受け取るかは、PoCを発注する時点で決めるしかありません。

システム開発の納品物一覧｜まず受け取るもの

出典: 情報処理推進機構（IPA）公式サイト

成果物と納品物の違い

開発の途中では、設計書、テストの記録、議事録など多くのものが作られます。一般にこれらをまとめて「成果物」と呼び、そのうち契約に基づいて発注側へ正式に引き渡すものを「納品物」と呼びます。法律上の定義ではなく業界での使い分けですが、要点は1つです。作られた成果物がすべて手元に届くわけではなく、何を受け取れるかは契約で決まります。

情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書（第二版）」は、発注側の企業・開発会社・業界団体・法律の専門家が参加して作った、どちらにも偏らない契約書のひな形です。2020年12月に公開された第二版が、2026年9月時点でも最新版です（2026年9月のページ更新は問い合わせ先の変更のみ）。ここでは納品物を「納入物」と呼び、個別の契約でその中身を定める建て付けになっています。以下、この記事では「IPAのひな型」と呼びます。

出典：IPA「情報システム・モデル取引・契約書」

一般的なシステム開発の納品物

この一覧を見るときに、発注側が誤解しやすい点が3つあります。

1つ目は、要件定義書と、画面や帳票など外から見える部分の設計書は、IPAのひな型では「発注側が作り、開発会社はそれを支援する」建て付けになっていることです。見積の作業範囲に、これらの資料の「作成」と書かれているのか「作成支援」と書かれているのかで、誰が作って誰の手元に残るのかが変わります。見積書の該当行を確認してください。

2つ目は、検収で何を試すかを書いた「検査仕様書」も、発注側が開発会社と相談しながら作る建て付けだということです。

3つ目は、テスト結果の報告書は「書いておかないと出てこない」ことがある点です。公正取引委員会の取適法（旧・下請法）のよくある質問では、単体テストの結果報告書などを納品物に含めるなら、給付の内容として明示し、その作成費用を代金に含めるべきだと説明されています。裏を返せば、テスト記録が欲しいなら見積に入れてもらうのが筋です。

日経BPの記事で、永井昭弘氏は「ベンダーとして何を納品する予定なのか、無償か有償かを聞くことが重要」と指摘しています。一覧は発注側が用意し、各社に「このうちどれを納品し、どれが有償か」を答えてもらうのが、比べやすく漏れも出ない方法です。各社の見積を並べて比べる手順はAI開発の見積もり比較で解説しています。

出典：日経BP「システム開発の『納品物』とは一体何か？」（2023年11月13日）／公正取引委員会「よくある質問（取適法）」

AI開発で追加で受け取るべき6つの納品物

出典: Anthropic Claude Platform Docs 公式

AIを組み込んだシステムでは、プログラムと設計書だけを受け取っても、別の会社が同じ品質で動かし続けることはできません。AIの動きは、プログラムの外側にある指示文やデータ、評価の記録で決まる部分が大きいからです。

1〜3は、AI開発の検収と保守の物差しになる

経済産業省の「AI・データの利用に関する契約ガイドライン」は、AIの性能は学習や評価に使ったデータに左右されるため、完成や性能をあらかじめ保証することが容易でないと整理しています（2018年策定・2019年改訂で、生成AI普及前の文書ですが、この考え方は今も変わりません）。そのためAI開発では、「何をもって合格としたか」の記録が、検収のときにも、保守でAIの版を替えるときにも、ほぼ唯一の物差しになります。

経済産業省の「AIの利用・開発に関する契約チェックリスト」（2025年2月）は、AIに渡す指示文（プロンプト）を、発注側が提供する「インプット」の1つに分類し、契約で特定して利用条件を定める対象に挙げています。同じチェックリストは、開発を目的とする契約であっても、成果物を提供する義務が課されない場合があると注意し、成果物が提供されない場合に保守や運用を十分に行えるかを事前に検討するよう求めています。

出典：経済産業省「AI・データの利用に関する契約ガイドライン」／経済産業省「AIの利用・開発に関する契約チェックリスト」（令和7年2月）

5は「誰のものか」より「どう使えるか」を書く

経済産業省のガイドラインは、AI開発で扱うものを「データ」「プログラム」「ノウハウ」の3つに分けています。このうちデータとノウハウは知的財産権の対象にならず、法律上の決まったルールもない場合が多いとされています。所有権の対象でもないため、契約に書かなければ「実際にアクセスできる人が使える」状態になります。

そこで、学習用データやノウハウについては「権利が誰にあるか」を争うより、次のような利用条件を契約に書くほうが実利があります。

• 使ってよい目的（本件のシステム以外には使わない、など）
• 使ってよい期間
• 複製や改変、中身の解析を認めるか
• 第三者への提供（同業他社向けへの転用を禁止する、など）
• 利益が出た場合の分け方

プログラムのように著作権の対象になり得るものは、「権利が誰にあるか」と「利用条件」の両方を書きます。

6は、開発会社との関係が終わる日に効いてくる

AIサービスやクラウドのアカウントを開発会社の名義で作ると、契約を終えたときに、請求・停止・権限の移し替えを自社で行えません。APIキーが開発会社の担当者の手元にあり続けることは、情報管理の面でも好ましくありません。アカウントは最初から自社名義で作り、開発会社には作業に必要な権限だけを渡すのが安全です。ソースコードの保管場所も同じで、GitHubには保管場所の持ち主を移す公式の手順がありますが、最初から自社名義で作っておけば移す必要自体がありません。開発会社に任せる範囲と自社に残す範囲の分け方は開発会社への丸投げはどこまで可能か、依頼先を選ぶ段階で確認したい項目はAI開発会社の選び方で整理しています。

PoC（試作と検証）の段階で受け取るもの

経済産業省のガイドラインは、AI開発を段階に分けて進める方式を示し、段階ごとに想定される成果物を挙げています。

生成AIを業務に組み込むPoCなら、「動く試作」「評価レポート」「本開発の概算見積と工程表」「移行判断資料」の4点を納品物にするのが標準的です。詳しくはAIのPoC費用の相場で解説しています。2026年6月の公正取引委員会などの指針でも、技術検証（PoC）は基本的に費用を受け取って行う実践例が紹介されており、PoCは有償で、その代わり試作のプログラムと評価の記録を受け取る条件にしておくのが、本開発を別の会社に頼む選択肢を残す方法です。

ソースコードの著作権は誰のものか

出典: 文化庁 公式サイト

契約に定めがなければ、ソースコードの著作権は作った開発会社に残ります。「お金を払って作ってもらったのだから当然自社のもの」という理解は成り立たず、ここは誤解が最も多いところです。

契約に書かなければ、著作権は作った開発会社側にある

プログラムは著作物です。開発会社の従業員が仕事として作ったプログラムの著作権は、原則としてその開発会社に帰属します（職務著作）。代金の支払いと著作権の移転は別の話で、発注側が著作権を持ちたいなら、契約で譲渡を明記する必要があります。

IPAのひな型は、この点について3つの選択肢を用意しています（第45条）。

IPAのひな型が開発会社側に置く案を用意しているのは、ソフトウェアの再利用を促すためと解説されています。どの案を選ぶかは、自社がそのシステムを将来どう扱いたいか（自社で改修を続けたいのか、別の会社に保守を移す可能性があるのか）で決まります。

「著作権をすべて譲渡する」と書くだけでは足りない

著作権を譲り受ける場合も、書き方に注意が必要です。著作権法61条2項により、翻案権など（27条）と、改変してできたものを利用する権利（28条）が契約書に明記されていないと、それらは譲渡した側、つまり開発会社に残っていると推定されます。システムの改修や機能追加は、この「翻案」に当たり得ます。

IPAのひな型も、次のような書き方をしています。

著作権（著作権法第27条及び第28条の権利を含む。）

この一文がないと、「著作権は譲り受けたが、改修に関わる権利は開発会社に残っている」と主張される余地が残ります。なお、著作権の移転を第三者に対しても主張できるようにするには、ソフトウェア情報センター（SOFTIC）での登録が必要です。IPAの解説には、開発会社が登録に協力する旨の条文例があります。

出典：文部科学省 文化審議会 著作権分科会資料（著作権法61条2項）

特許やノウハウは、発明した側のもの

IPAのひな型では、開発の過程で生まれた発明やノウハウ（著作権を除く）は、発明した人が属する会社のものになり、共同で生んだものは共有になる建て付けです。開発会社が持つ場合でも、発注側にはシステムを使うのに必要な範囲で使う権利が認められ、その対価は委託料に含まれる、という整理になっています。

権利を受け取りたいなら、見積依頼の時点で対価込みで伝える

ここは2026年に大きく変わった点です。

IPAの解説は、著作権の移転には価値に見合った対価が支払われる必要があるとし、委託料に含める場合も、あらかじめ見積金額にその対価が含まれ、合意していることを前提にしています。そのうえで、発注側が著作権の譲受を希望する場合は、事前に見積依頼書（RFP）でその旨を明らかにするよう求めています。

さらに、公正取引委員会・中小企業庁・特許庁は2026年6月24日、「知的財産権・ノウハウ・データの適切な取引のための優越的地位の濫用等に関する指針」を公表しました。全業種を対象に約70の事例を示した初の包括的な指針で、取引上強い立場にある発注者が、正当な理由なく、受注者側にある著作権を無償で自社のものにする契約を結ばせることは、独占禁止法上の問題（優越的地位の濫用）となり得るとしています。システム開発に関わる事例には、次のものがあります。

• プログラム開発で、成果物の著作権を無償で譲渡する内容の請負契約書を、一方的に結ぶよう求められた（事例2-13）
• 開発に必要な自社ソフトのライセンス料を払ってもらえず、無償で使わせることに応じざるを得なかった（事例2-15）
• 製品に搭載するプログラムの著作権を、作った時点から発注者のものとする条件を一方的に設定された（事例2-18）
• システム開発のPoCの成果物を、一方的に無償で提供するよう求められた（事例2-29）

2026年1月1日に施行された中小受託取引適正化法（取適法。旧・下請法）の対象となる取引であれば、不当な経済上の利益の提供要請、買いたたき、協議に応じない一方的な代金の決定として問題となるおそれもあります。公正取引委員会の取適法に関するよくある質問では、知的財産権を譲渡・許諾させるなら発注内容に含めて範囲を明示し、譲渡の対価を含めた代金を十分に協議して決める必要があると説明されています。また、情報成果物を受け取ってから60日以内に定めた支払期日までに支払う必要があります。

発注する側の実務に落とすと、次の3点になります。

1. 見積依頼書に、納品物の一覧と「著作権を移してほしい部分」を書く
2. 著作権を移す対価を、見積の中で別の行として出してもらう
3. 発注したあとで「ついでに全部ください」とは求めない

取適法が適用されるかどうかは、発注側と受注側の資本金や取引の内容で決まり、すべての開発委託に当てはまるわけではありません。自社の取引が対象になるかは、公正取引委員会の資料で確認してください。

出典：公正取引委員会「知的財産権・ノウハウ・データの適切な取引のための優越的地位の濫用等に関する指針」の公表について（2026年6月24日）／同 指針本文（PDF）／同「よくある質問（取適法）」

開発会社が以前から持っている部品は、渡されないことがある

開発会社は、過去に作った部品や自社製品の一部を組み合わせてシステムを作ることがあります。経済産業省のチェックリストは、その開発で新しく生まれた知的財産と、開発と関係なく各社が以前から持っている知的財産を分けて考え、納品物がどちらに当たるかが後で争点になるため、開発の初期に認識を擦り合わせることが重要だとしています。

2026年6月の公正取引委員会などの指針にも、自社独自の検索エンジンのソースコードを社外に出さない情報サービス業者が、見積書や取引基本契約書に「ソースコードを開示しない」旨を書いている例が、望ましい実践例として紹介されています。つまり、一部のソースコードが渡されないこと自体は、正当にあり得ます。IPAのひな型のB案でも、開発会社が以前から持つ部品や汎用的なプログラムは譲渡の対象から外されています。

発注側がすべきなのは、見積の段階で「渡されない部分」を一覧にしてもらい、その部分を自社が使い続ける条件（期間、範囲、保守を別の会社に移したときの扱い）を契約に書くことです。

開発会社がAIを使って書いたコードの著作権

開発の現場では、AIにプログラムを書かせることが当たり前になりつつあります。この場合の扱いは、次のように整理されています。

• 文化庁の「AIと著作権に関する考え方について」（2024年3月15日）は、AIが生成したものに著作権が生じるかは個別に判断され、人がどれだけ創作的に関わったかが基準になるとしています
• AIサービスの法人向け規約では、出力は利用者のものとされています。Anthropic社の商用規約（2025年6月発効）は利用者が出力を所有するとし、OpenAI社の法人向け規約（2026年1月発効の版）は出力を利用者のものとし、提供元に権利があれば（if any）利用者に譲渡する、という書き方です

つまり、開発会社がAIを使って書いたコードも規約上は開発会社のものとして扱えますが、そもそも著作権が生じない部分があり得ます。「著作権を譲渡する」という条文だけでは、その部分を押さえきれない可能性があります。確実なのは、著作権の条文とは別に、「ソースコード一式を引き渡す義務」と「発注側が自由に使い、改変し、第三者に見せてよいという利用条件」を契約に書くことです。

出典：文化庁「AIと著作権について」／Anthropic Commercial Terms of Service／OpenAI Services Agreement

※この章は、公開されている資料をもとに発注側が押さえるべき点を整理したもので、個別の契約についての法的助言ではありません。契約書の最終的な判断は弁護士にご確認ください。

検収で確認することと、検収後に不具合が見つかったとき

出典: GitHub Docs 公式

納品物を受け取ったら、検収（受け入れの検査）です。検収で見落としやすいのは、「期限内に異議を出さないと合格扱いになる」点と、「動作だけでなく納品物が揃っているかも確かめる」点の2つです。

期間内に書面で異議を出さないと、合格とみなされる

IPAのひな型では、発注側は契約で決めた検査期間内に、検査仕様書に沿って検査します。検査合格の書面を出さなくても、期間内に具体的な理由を書面で示して異議を出さなければ、合格したものとみなされます。そして検査の合格が、検収の完了です。

「忙しくて検査できないうちに期間が過ぎた」は、そのまま合格を意味します。発注する前に、検収期間中に社内で誰がテストするかを決めて、予定を押さえておいてください。 検収期間を何日とするかに公的な基準はなく、個別の契約で決めます。

何を試すかは、発注側が決める建て付け

検収で何をどう試すか（テストの項目、テストに使うデータ、テストの方法、期間）を書いた「検査仕様書」は、IPAのひな型では発注側が開発会社と相談して作り、開発会社が確認する流れです。開発会社が用意したテストを確認するだけでは、自社の業務で本当に困る場面が抜けることがあります。現場の担当者が「月末に処理が重なったとき」「例外的な書類が来たとき」のような業務の場面を持ち寄るのが確実です。合格ラインの決め方は要件定義の進め方（発注側）でも解説しています。

AI開発なら、評価用のデータと合格ラインの記録が、そのまま検査仕様書の中身になります。

納品物そのものも検収で確かめる

動作の確認とあわせて、納品物が揃っているかも検収で確かめます。最低限、次の点を検査仕様書に入れておきましょう。

• 納品物一覧のすべてが揃っているか（資料名と版）
• ソースコードが、自社名義の保管場所に入っているか
• 環境構築手順どおりに作業すれば、同じ環境を作れるか
• サーバー、クラウド、AIサービスの管理者権限が自社にあるか
• AI開発なら、評価用のデータで合格ラインに届くことを、自社の担当者の手元で再現できるか

検収後の不具合は、いつまでに伝えれば直してもらえるか

IPAのひな型では、検収後に仕様との食い違い（不具合を含む）が見つかれば、修正を求められます。ただし開発会社が責任を負うのは「検収完了後〇か月（〇年）以内に通知された場合に限る」という書き方で、期間は空欄になっています。つまり交渉で決める項目です。

法律上の原則（民法637条1項）では、請負契約なら不具合を知ったときから1年以内に通知すれば、修正・減額・損害賠償・解除を求められます。ただし契約で短くも長くもできるため、契約書に何と書かれているかがすべてです。

なお、作業時間に対して払う準委任契約には、請負のような「納品後に不具合を無償で直してもらう権利」（契約不適合責任）の決まりがありません。PoCや保守を準委任で頼む場合は注意してください。契約の種類ごとの違いはAI開発の契約形態で解説しています。

システム開発の納品物の費用｜抜けていたときにかかる金額と当社の価格

納品物の一覧を決めること自体には、費用はかかりません。費用がかかるのは、決めずに進めて、あとから揃えるときです。開発会社の公開情報をもとにした目安は次のとおりです。

※試算は1人日（1人が1日働く作業量）を3〜5万円と置いています。一般的な目安である1人月60万〜100万円を1か月20営業日で割ったものです。作業日数は仮定で、公的な統計はありません。

出典：three dots.「業務システムの保守を別会社に移すには」／秋霜堂「システム引き継ぎガイド」

2社の公開情報で移管費用が30万〜100万円と一致しており、設計書などを後から作る試算とも同じ帯に収まります。必要な納品物が揃っていないと、改修や保守の本題に入る前に、この金額がかかるということです。移管の初期費用とは別に、並行対応の二重払いと解約予告期間の保守費も出ていくので、自社の月額保守費を当てはめて見積もっておいてください。

たとえば月額保守費が10万円なら、移管初期費用30万〜100万円に、二重払い10万〜20万円、解約予告期間の30万〜60万円が加わり、合計70万〜180万円が目安になります。月々の保守費の相場はシステム保守運用費の相場、資料が揃わず直すか作り直すかで迷う場合はシステム改修とリプレイスの比較にまとめています。

利用者向けの操作マニュアルだけを外部に作ってもらう場合は、1ページ5,000〜20,000円を相場とする代行事業者が複数あります。ただし業務マニュアルの相場で、システムの設計書を作り直す費用の相場ではない点に注意してください。

当社の場合（受託開発・税別）

当社の受託開発の価格と、納品物についての進め方は次のとおりです。

クラウドの利用料、外部のAIサービスの利用料、ソフトウェアのライセンスなどの実費は、内容に応じて別途かかります。

当社では、提案・見積の段階で対応範囲、成果物、費用、スケジュール、役割分担をお示ししています。ソースコードと成果物は、契約内容に基づき、ソースコードの保管場所（GitHubのリポジトリ）、ソースコード、設計資料などをお引き渡しします。見積依頼に納品物の一覧を添えていただければ、各項目をどう扱うか、著作権をどうするかを提案・見積の中であわせてご説明します。

他社が作ったシステムで、ソースコードや設計書が揃っているか分からない場合も、現在の構成とソースコードを確認し、改修できる範囲を整理するところからお受けしています。価格と対応範囲の詳細は受託開発サービスのページにまとめています。他社のシステムを引き継いで直す場合の費用はシステム改修の費用も参考にしてください。

実際にやった事例｜納品物と引き継ぎの観点から

守秘義務のため社名は出せませんが、当社が担当した案件のうち2件を、課題、作ったもの、変わったことの順に紹介します。

医療機関のケース｜合格ラインを文書で残したPoC

課題：蓄積されている文書や記録は多いのに、必要な情報を探すのに時間がかかっていました。

作ったもの：手元の資料をAIに読ませ、質問すると根拠となる箇所を示しながら答える仕組みです。対象を1部門・1業務に絞り、開始前に「どの質問に、どの水準で答えられたら合格とするか」を文書で決めました。終了時には、合格ラインに対する実測値、本開発の概算見積、本番移行時の運用体制案を成果物として揃えています。

変わったこと：判定の基準が文書で残っていたため、拡大するかどうかの意思決定が短期間で済みました。

納品物の観点で見ると：この「合格ラインと実測値の記録」は、AI開発ならではの納品物である「評価用のデータと合格ラインの記録」そのものです。PoCの判断に使えるだけでなく、将来AIの版を替えるときに、品質が落ちていないかを確かめる物差しとしてそのまま使えます。医療情報を扱う案件では、取り扱う情報、利用目的、保存場所、使う外部サービス、権限、運用体制を確認したうえで進め方を決め、預かったデータを契約終了後にどう返却・削除するかも最初に取り決めます。

調剤薬局のケース｜システム本体に手を入れず、データの受け渡しをつないだ

課題：あるシステムに入力した内容を、別の管理表へ手で書き写す作業が毎日あり、忙しい時期には書き写し漏れも起きていました。

作ったもの：一方のシステムから出力したデータを整え、もう一方のシステムの形式に変換して取り込む仕組みです。システムを作り直すのではなく、手間がかかっている1か所だけに絞りました。プログラムよりも時間がかかったのは、表記の違う同じ取引先を1つにまとめる、過去データの整理（名寄せ）でした。

変わったこと：書き写す作業がなくなり、書き写しのミスを探して直していた時間もなくなりました。

納品物の観点で見ると：この種の仕組みで中身の大半を占めるのは、プログラムそのものより「どの項目をどう変換するか」「表記の違いをどうまとめるか」というルールです。引き継ぎのときに問われるのは、プログラムだけでなく、このルールが読める形で残っているかです。データを受け渡す仕組みを発注するときは、変換ルールの一覧も納品物に入れてください。また、システム本体に手を入れず外側でデータをつなぐ方法は、ソースコードが手元にないシステムでも取れる方法です。

納品物と著作権の取り決めを急ぐべき会社・後回しでよい会社

すべての会社が、すべての納品物と著作権の譲渡を求める必要はありません。項目を増やせば見積も上がるので、自社の状況に合わせて優先順位をつけます。

今すぐ取り決めるべき会社

• 将来、保守会社を替えたり、社内で改修したりする可能性が少しでもある
• AIを組み込むシステムを発注する（AIの版の提供終了が1〜2年単位で必ず来る）
• 患者情報・顧客情報など、取り扱いに注意が必要なデータを開発会社に預ける
• 作ったシステムを自社サービスとして外販する、グループ会社に展開する予定がある
• PoCの後、本開発の発注先を比べて選びたい

一部の取り決めで足りる会社

• 既製のクラウドサービスの設定変更が中心で、独自のプログラムがほとんどない（著作権より、アカウントの名義と設定内容の記録が重要）
• 数十万円規模の小さな改修で、元のシステムの持ち主が自社か既存の保守会社かがはっきりしている
• 社内だけで使い、改修も同じ開発会社に長く任せる前提で、著作権は開発会社に残して利用条件を広く取れば足りる

迷う場合は、少なくとも「ソースコード一式の引き渡し」「アカウントの自社名義」「第三者に改修を頼めること」の3点だけは契約に入れておくと、後から選択肢を失わずに済みます。

契約前に決める項目チェックリスト｜見積依頼にそのまま貼れる形

見積依頼書に、次の項目を「回答してほしい事項」として貼り付けてください。各社の回答を並べるだけで、納品物と権利の扱いの違いが見えます。見積依頼書全体の作り方はシステム開発の相見積もりとRFPで解説しています。

納品物

• 納品物の一覧（資料名、ファイル形式、納品の時期）
• 各納品物が見積に含まれるか、有償の追加か
• テスト結果報告書を納品物に含めるか、その作成費用
• ソースコードの受け渡し方法（自社名義の保管場所に随時入れるか、納品時にまとめて渡すか）
• 環境構築手順と構成図
• 使っている外部部品（オープンソースなど）の一覧とライセンス

AI開発で追加するもの

• AIへの指示文と設定値
• 使っているAIの名前（版）と提供終了予定日、提供終了時の対応を保守に含めるか
• 評価用のデータと合格ライン
• 社内資料をAIに読ませる仕組みの更新手順
• 学習用データと学習済みのAIの利用条件（目的、期間、他社への転用の禁止）

権利

• 著作権の扱い（開発会社に残して利用を認める／発注側に移す／共有する）
• 移す場合は「著作権法第27条及び第28条の権利を含む」と書く
• 移す場合の対価を、見積の別の行で示す
• 渡されない部品の一覧と、自社が使い続ける条件
• 著作権の条文とは別に、ソースコード一式を引き渡す義務
• 第三者の開発会社に改修を委託し、ソースコードを見せてよいこと

アカウントとデータ

• クラウドとAIサービスのアカウント、ソースコードの保管場所を自社名義で作る
• APIキーの管理者と、契約終了時の権限の外し方
• 預けたデータの保持期間、契約終了時の削除、削除を証明する書面
• 預けたデータをAIの学習に使ってよいか

検収と引き継ぎ

• 検収期間の長さと、検査仕様書を誰が作るか
• 検収後に不具合を無償で直す期間
• 契約終了時や保守会社を替えるときの、引き継ぎ協力の範囲・費用・解約の予告期間

相談から納品・引き継ぎまでの流れ

当社の受託開発の進め方に沿って、各段階で納品物について何を決めるかを並べると、次のようになります。進め方自体は、他社に依頼する場合も大きくは変わりません。

納品物の中身が決まるのは3の「提案・見積」の段階です。ここを過ぎてから一覧を追加すると、見積のやり直しか追加費用になります。

開発そのものの期間は対象範囲と確認の回数で変わりますが、他社が作ったシステムの保守を引き継ぐ場合は、公開情報で中小規模なら2〜4か月、資料が整っていれば1〜2か月が目安です。資料が揃っているかどうかで、引き継ぎの期間が数か月単位で変わります。

要件が固まっていない段階でも、初回のご相談は無料です。「何を納品物に入れればいいか分からない」「他社の見積の納品物欄や著作権の条文が妥当か見てほしい」という段階からお話を伺います。進め方と対応範囲は受託開発サービスの進め方でご確認いただけます。

よくある質問

Q1. 見積書の納品物欄に「ソースコード」が書かれていません。普通ですか。

珍しくはありませんが、そのまま発注しないでください。考えられる理由は、単なる書き漏れ、有償の追加扱い、開発会社が以前から持つ部品を使うため一部を渡さない方針、のいずれかです。どれに当たるかは、次のように聞けばはっきりします。「ソースコードは納品物に含まれますか。含まれる場合は受け渡し方法を、有償の場合は金額を、渡さない部分がある場合はその範囲と、当社が使い続ける条件を書面でお知らせください」。回答は口頭で終わらせず、見積書か契約書に反映してもらいましょう。

Q2. 著作権を譲り受けると、見積はどれくらい上がりますか。

上乗せ額の公的な相場や統計は、確認できる範囲では公開されていません。IPAのひな型は、著作権を移す対価を委託料に含める方式ですが、その前提として見積金額に対価が含まれ、合意していることを置いています。つまり、金額は見積依頼の時点で伝えないと出てきません。実務では、①著作権を発注側に移す場合と、②開発会社に残したうえで自社が自由に使える利用条件を付ける場合、の2通りで見積を出してもらい、差額を見て決めるのが確実です。自社で改修を続けたいだけなら、②で足りることもあります。

Q3. 著作権が開発会社に残る契約でも、別の会社に改修を頼めますか。

頼める余地はありますが、契約の書き方しだいです。IPAのひな型のA案で発注側に認められているのは、自社で使うために必要な範囲での複製や改変です。この「自社で使うため」に、別の開発会社に改修を任せることまで含まれるかは、条文だけでは読み取りにくいところです。保守会社を替える可能性が少しでもあるなら、「発注側が第三者に委託して改修や機能追加を行える」ことと、そのためにソースコードや設計書を委託先に見せてよいことを、利用条件として契約に書いておきましょう。グループ会社での利用や他の拠点への展開を考えている場合も同じです。

Q4. 開発会社と連絡が取れなくなったら、ソースコードはどうなりますか。

手元にない場合、取り戻すのは難しくなります。そのため対策は平時に行うしかありません。ソースコードは納品時にまとめてではなく、開発中から自社名義の保管場所に随時入れてもらう。クラウドやAIサービスのアカウントを自社名義にしておく。環境構築手順を受け取っておく。この3つがあれば、別の会社が続きを引き受けられます。すでに手元にない場合は、まず過去の契約書でソースコードを引き渡す約束があったかを確認してください。どうしても手に入らない場合は、システム本体には手を入れず、出力されるデータを外側で加工してつなぐ方法か、作り直しを検討することになります。

Q5. 準委任（作業時間に対して払う契約）でも、納品物は受け取れますか。

受け取れます。ただし準委任には「完成させる」約束がないので、何を受け取るかを契約に別に書いておく必要があります。具体的には、作業報告書、途中までのプログラムとソースコード、評価の記録などを、いつ引き渡すかを決めます。見落としやすいのは途中で契約を終えるときです。「終了時点の成果物とソースコードを引き渡す」という条項がないと、それまでに払った費用の成果が手元に残らないことがあります。

Q6. 使っている外部部品（オープンソースなど）の一覧まで、本当に必要ですか。

必要です。IPAのひな型では、オープンソースなど第三者が作った部品について、開発会社は権利の侵害がないことや不具合がないことを原則として保証せず、使うかどうかは発注側が決める建て付けです。つまり、部品に弱点やライセンス違反が見つかったときに確認する責任は、発注側にあります。一覧がなければ、自社がその影響を受けるかどうかも判断できません。この一覧は「ソフトウェアの部品表（SBOM）」とも呼ばれ、経済産業省は2024年8月の手引ver2.0で、受発注の際に部品表について契約で決めておく事項（求める内容、責任、費用負担、権利など）の参考例を示しています（経済産業省「SBOM導入に関する手引 ver2.0」）。

Q7. 預けた患者データや顧客データは、契約が終わったあとどうなりますか。

契約に書いていなければ、開発会社の手元に残る可能性があります。経済産業省のチェックリストは、開発会社が提供データを保持できる期間、期間終了時の削除義務、削除を証明する書類の発行義務を確認するよう挙げています。同じチェックリストには、一度AIの学習に取り込まれた情報を後から取り除くのは一般に難しい、という記載もあります。医療機関や薬局のように患者情報を扱う場合は、AIの学習に使ってよいかどうかも含めて、発注する前に書面で決めてください。

Q8. 納品物の一覧を作ると、開発会社に嫌がられませんか。

むしろ見積の精度が上がるので、まともな開発会社ほど歓迎します。嫌がられやすいのは、一覧を出すことではなく、発注後に「これも無償で」と追加することです。一覧と一緒に「有償になる項目はその金額を示してください」と添えれば、開発会社も見積に正しく反映できます。一覧への回答が曖昧なまま「すべて対応します」とだけ返ってくる場合は、むしろ注意が必要です。

システム開発の納品物と著作権で迷っている方へ

システム開発の納品物は、プログラム一式・資料・権利・アカウントの4つで、AI開発ではAIへの指示文、使っているAIの版、合格ラインの記録などが加わります。代金を払っても著作権は自動では移らず、譲渡する場合も「著作権法第27条及び第28条の権利を含む」と書かないと改修に関わる権利が開発会社に残ると推定されます。抜けたまま保守会社を替えると、移管だけで30万〜100万円、期間は2〜4か月（資料が足りなければ3〜6か月）かかります。権利を受け取りたいなら、見積依頼の時点で対価込みで伝えるのが、2026年6月の指針を踏まえた進め方です。

• 他社から届いた見積書の納品物欄や著作権の条文が妥当か、判断がつかない
• 今のシステムのソースコードや設計書が手元になく、保守会社を替えられない
• AIを組み込むシステムを発注したいが、何を受け取ればいいか決められない

1つでも当てはまれば、まずは無料の初回相談をご利用ください。当社の価格は、PoC 300万円〜、既存システムの改修 100万円〜、本開発は個別見積です（すべて税別）。医療機関・薬局・インフラ企業での開発実績があり、要件が決まっていない段階からご相談いただけます。

ご相談の際に、①作りたい（または直したい）システムの概要、②手元にある契約書・見積書・資料の一覧、③将来、保守会社を替えたり社内で直したりする予定があるか、の3つをお知らせいただくと、納品物に何を入れるべきかをその場で整理できます。

▶ 受託開発の費用・無料相談はこちら

関連記事：AI開発の契約形態／AIのPoC費用の相場／AI開発会社の選び方／AI開発の見積もり比較／システム開発の追加費用／システム開発の相見積もりとRFP／AI開発が失敗する原因／生成AIの内製と外注