システム開発の納品物一覧｜AI開発で受け取るべきソースコード・権利・引き継ぎ資料【2026年9月最新】

システム開発の納品物は「プログラム一式」「資料」「権利」「アカウント」の4つに分けて、見積を依頼する時点で一覧にしておくものです。契約書に書かなければソースコードの著作権は原則として開発会社側に残り、必要なものが抜けたまま保守会社を替えると、開発会社の公開情報では移管だけで30万〜100万円、期間は2〜4か月（資料が足りなければ3〜6か月）かかります。

AIを組み込むシステムでは、さらに「AIへの指示文」「使っているAIの版と提供終了日」「何をもって合格としたかの記録」など、一般的な納品物の一覧には載っていないものが増えます。これらが手元にないと、AIの提供元が古い版の提供を終えたときに、同じ品質で直せる人がいなくなります。

この記事では、困る場面、受け取るべき納品物の一覧、AI開発で増える6つの納品物、著作権の扱い、検収の注意点、抜けていたときの費用、当社の事例を順に説明し、見積依頼にそのまま貼れるチェックリストも載せます。当社の受託開発はPoC 300万円〜、小規模改修 30万円〜、本開発は個別見積（すべて税別）です。

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

出典: Anthropic Claude Platform Docs 公式

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

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

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

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

AIを組み込んだシステムの多くは、外部のAIサービスを呼び出して動いています。提供元は古い版のAIを順に提供終了にしていきます。たとえばAnthropic社は、公開しているモデルの提供終了を少なくとも60日前に通知し、終了後の呼び出しは失敗すると明記しています。2026年も、Claude Sonnet 4（2025年5月14日版）が6月15日に、Claude Opus 4.1（2025年8月5日版）が8月5日に提供を終えました。

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

出典：Anthropic「Model deprecations」

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

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

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

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

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

成果物と納品物の違い

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

情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書（第二版）」は、発注側の企業・開発会社・業界団体・法律の専門家が参加して作った、どちらにも偏らない契約書のひな形です。ここでは納品物を「納入物」と呼び、個別の契約でその中身を定めたうえで、開発会社が検収を依頼する書面とあわせて納めることになっています（第26条）。以下、この記事では「IPAのひな型」と呼びます。

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

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

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

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

2つ目は、検収で何を試すかを書いた「検査仕様書」も、発注側が開発会社と相談しながら作る建て付けだということです（第27条）。詳しくは検収の章で説明します。

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

出典：日経BP「システム開発の『納品物』とは一体何か？」（2023年11月13日）

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

出典: Anthropic Claude Platform Docs 公式

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

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

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

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

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

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

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

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

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

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

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

AIサービスやクラウドのアカウントを開発会社の名義で作ると、契約を終えたときに、請求・停止・権限の移し替えを自社で行えません。アカウントは最初から自社名義で作り、開発会社には作業に必要な権限を渡すのが安全です。開発会社を選ぶ段階で確認したい項目はAI開発会社の選び方で整理しています。

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

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

生成AIを業務に組み込むPoCなら、「動く試作」「評価レポート」「本開発の概算見積と工程表」「移行判断資料」の4点を納品物にするのが標準的です。詳しくはAIのPoC費用の相場で解説しています。PoCの段階から、試作のプログラムと評価の記録を受け取る条件にしておくと、本開発を別の会社に頼む選択肢が残ります。

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

出典: 文化庁 公式サイト

「お金を払って作ってもらったのだから、プログラムは当然自社のもの」という理解は、契約に何も書いていなければ成り立ちません。ここは誤解が最も多いところです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 製品に搭載するプログラムの著作権を、一方的に発注者のものとされ、無償で譲渡させられた（事例2-18）
• 著作者としての権利を行使しないという条項を、一方的に求められた（事例2-19）
• システム開発のPoCの成果物を、一方的に無償で提供するよう求められた（事例2-29）

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

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

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

自社の取引が取適法の対象になるかどうかは、公正取引委員会の資料で確認してください。

出典：公正取引委員会ほか「知的財産権・ノウハウ・データの適切な取引のための優越的地位の濫用等に関する指針」／公正取引委員会「取適法」／同「よくある質問（取適法）」

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

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

前述の2026年6月の指針にも、自社独自の検索エンジンの仕様もソースコードも社外に出さない情報サービス業者が、見積書や取引基本契約書に「ソースコードを開示しない」旨を書いている例が、実践例として紹介されています。つまり、一部のソースコードが渡されないこと自体は、正当にあり得ます。

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

開発会社がAIを使って書いたコードはどうなるか

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

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

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

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

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

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

出典: GitHub Docs 公式

納品物を受け取ったら、検収（受け入れの検査）です。IPAのひな型には、発注側が見落としやすい決まりがあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここまでは特定の会社に寄らない情報です。当社の価格と、納品物についての進め方も同じ見方で示します。

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

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

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

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

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

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

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

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

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

納品物の観点で見ると：この「合格ラインと実測値の記録」は、この記事で挙げたAI開発の納品物の3番目にあたります。PoCの判断に使えるだけでなく、将来AIの版を替えるときに、品質が落ちていないかを確かめる物差しとしてそのまま使えます。医療情報を扱う案件では、取り扱う情報、利用目的、保存場所、使う外部サービス、権限、運用体制を確認したうえで進め方を決めます。預けたデータの扱いを最初に決めておく理由は、よくある質問のQ7で説明します。

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

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

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

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

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

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

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

納品物

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

AI開発で追加するもの

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

権利

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

アカウントとデータ

• クラウドとAIサービスのアカウントを自社名義で作る
• 預けたデータの保持期間、契約終了時の削除、削除を証明する書面

検収と引き継ぎ

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

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

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

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

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

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

よくある質問

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

システム開発の納品物は、プログラム一式・資料・権利・アカウントの4つで、AI開発ではAIへの指示文、使っているAIの版、合格ラインの記録などが加わります。契約に書かなければソースコードの著作権は原則として開発会社側に残り、抜けたまま保守会社を替えると移管だけで30万〜100万円、期間は2〜4か月（資料が足りなければ3〜6か月）かかります。権利を受け取りたいなら、見積依頼の時点で対価込みで伝えるのが、2026年の指針を踏まえた進め方です。

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

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

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

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

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