代金を払っても、著作権が移るとは限らない。開発したシステムの権利は誰のもの？

たとえば、数年後に「別の会社へ改修を頼みたい」「データを別のサービスへ移したい」「自社で運用したい」となったとき、必要なものは少しずつ違います。

• 他社へ改修を頼むなら、コードに加え、保守先へ渡して変更してよい条件と、使う部品の許可を確かめます。
• データを取り出すなら、表のデータだけでなく、添付原本や項目・番号の対応を受け取れるかを見ます。
• 自社で運用するなら、動かす手順、管理権限、クラウドや外部サービスの契約・請求を引き継げるかを見ます。

たとえば、開発会社からコードを受け取れても、帳票を作る有料部品がその会社の開発者枠でしか使えなければ、次の保守先はそのまま帳票を直せません。後で示す例では、追加の利用許諾と費用が分かるまで、その部品の採用を保留にします。

代金の支払い、コードの受領、著作権の移転は別の問題です。まず何をしたいかを決め、それに必要な引渡物と許可を契約で合わせます。

個別の権利帰属や契約解釈は、契約書と実際の開発内容に照らして判断します。

次の保守先が、請求書を一枚直せる状態で受け取る

「コード一式」を受け取る場面を、請求書の会社住所を直して出力する一件まで具体化します。これは引渡し確認の課題例です。実際に他社へ情報を渡す前に、契約上の開示・変更の許可を確かめます。

次の担当者が行うこと	足りなければ確認するもの
合意した版を取得し、試用環境で起動する	版番号、依存部品、設定の説明、試用データ
架空の会社住所を直し、請求書を出す	帳票部品の利用権、字体、ひな形、出力手順
注文と添付を取り込み、同じ番号で開く	項目の意味、番号の対応、添付原本、取込手順
変更を取り消して前の版へ戻す	変更履歴と戻す手順。前の会社の個人アカウントを使わずに行えるか

起動できないときは、著作権の問題、必要なファイルの不足、有料部品の契約、管理権限の不足を別々に記録します。全部を「権利をもらっていない」でまとめると、解決先が分からなくなります。

MITライセンスの原文は、許諾と著作権表示等の条件を一緒に示しています（2026年10月26日確認）。OSS名の一覧だけで済ませず、使う版と表示・配布条件を引き継ぎます。有料部品の条件や、納品したコード全体の権利までMITから判断することはできません。

コード、権利、データ、管理権限を別々に確かめる

著作者は原則として実際に創作した人です。ただし、従業員による開発には職務著作の要件も関わります。発注や納品の名義だけで権利者を決めず、創作関係と契約を確認します。著作者、利用許諾、譲渡の制度は文化庁の著作権テキスト（出典：文化庁「著作権テキスト 令和8年度版」（PDF））で確認できます。

ソースコードは、人が読み、修正できるプログラムの記述です。ファイルを受け取っても、著作権が移転するかは契約条件によります。著作権の譲渡を合意した場合も、保守を始めるには対象のコードや設定の受領が必要です。

利用許諾は、権利者から一定の範囲で使うことを認めてもらう方法です。目的が社内利用と他社による保守なら、その行為を継続して許可する契約案も比較できます。著作権を譲り受ける案でも、外部部品や納品対象まで自動的にそろうわけではありません。利用する人や目的を限定する場合があります。自社で動かす許可に加え、他社へコードを開示して修正を頼めるかを確かめます。

表1　発注前に分けて決める六つの対象

対象	問い	合意・記録する内容
ソースコード	何を受け取るか	対象の版、保管先、取得形式、依存部品、引渡時期
著作権	権利は誰に帰属するか	新規部分と既存部分、譲渡の対象・除外・時期
利用許諾	誰が何をできるか	使用・複製・改変・第三者への開示、期間と範囲
データ	何を取り出して使えるか	対象項目、添付ファイル、出力形式、利用目的と制限
管理アカウント	誰が管理操作をできるか	契約名義、管理者、請求先、権限付与と解除の方法
外部サービス・部品	第三者の何に依存するか	契約主体、ライセンス、変更・再配布・終了時の条件

たとえば「成果物の権利はすべて発注者に帰属する」とだけ書いても、成果物の範囲が曖昧なら、既存部品や運用データまで対象なのか判断できません。契約本文と対応する納品一覧に、含めるものと除外するものを具体的に書きます。

納品物は「動くもの」から一段具体的にする

見積りや仕様書の「システム一式」を、作業できる単位に分けます。ソースの対象版と保管先、依存ライブラリの版、設定ファイルの見本、構築・起動手順、データの構造、設計資料、テスト結果まで、何を含めるかを先に相談します。開発会社の環境にしかない道具が必要かも確認します。

受取時の試し方も決めます。合意した環境でソースを取り出し、必要な部品をそろえ、構築・起動できるかを試す方法があります。試す担当、別会社の参加、作業費を見積りに含めるかまで決めると、受取条件が具体的になります。

記入例：必要な利用と保守の許可を確保する

発注者A社が開発会社B社へ社内受注システムを依頼し、将来は保守会社C社に変更を頼む例です（想定例）。新規部分もB社に著作権を残し、A社と指定保守先による利用・改変を許諾する案を採っています。目的は社内利用と保守で、製品として販売する予定はありません。

新規コードと既存共通部品は、B社が権利と利用を許可する権限を持つと仮定しています。実案件では、AI利用や第三者コードの混入を調べたうえで許諾条件を確定します。

表2　納品一覧の記入例：誰が使い、変更し、渡せるか

新規コードとB社の既存部品は条件付きで保守できる設定です。MIT部品は元の条件に従い、商用部品と外部サービスの不明な条件は別に調べます。

表2の許諾は、保守契約が終わっても利用を続けられる前提です。実際の契約では期間、解除時の扱い、対価を決めます。自社で販売する場合や他社へ事業ごと移す場合は、用途に合わせて必要な権利の範囲を見直します。

新規部分、既存部品、AI生成部分を分ける

今回作ったコード、B社が以前から持つ共通部品、第三者のライブラリでは、権利者と条件が異なり得ます。部品ごとの名称・版・出所・ライセンス・対象ファイルを一覧にし、新規部分の合意がどこまで適用されるかを確かめます。

OSSも商用部品も、許される行為を条件で読む

OSSもライセンスの条件に従って使います。Open Source Initiativeに掲載されたMITライセンスは利用・改変等を認める一方、コピー等に著作権表示と許諾表示を含める条件があります（出典：Open Source Initiative「The MIT License」）。表2の部品MはMIT適用を仮定した例です。実案件では部品のLICENSEと依存先を確認し、その条件が適用される範囲を確かめます。

商用部品では、購入した会社、利用人数、開発と実行の区別、保守委託先への提供範囲を提供元の契約資料で調べます。B社が購入した利用枠をA社やC社でも使えるかは、提供元の条件によります。契約情報が得られない箇所は「不明」とし、B社経由で回答を得る担当と期限を決めます。

AIを使ったかどうかと、利用してよいかは別の問題

AI生成部分も、利用規約や既存著作物との関係を調べます。文化庁のガイダンス（出典：文化庁「AIと著作権に関するチェックリスト＆ガイダンス」（PDF））は、業務利用者に規約や生成物の確認、生成過程の記録を参照できる状態にすることなどを示しています。生成物に著作権が生じるかという問題と、既存著作物の権利を侵害するかという問題は別です。

納品一覧にはAI利用の有無を「あり・なし・不明」で記録し、該当箇所、利用サービス・プラン、読んだ規約の版、調べた担当を残します。入力内容や生成過程の記録に秘密情報が含まれる場合は、一覧には保管場所と管理担当を記し、必要な記録をアクセス制限した保管先で管理します。

別会社への保守委託と、再配布を区別する

将来の引き継ぎは、作業に分けて質問します。C社がソースを取得できるか、検証用にコピーできるか、修正できるか、必要な開発ツールを使えるか、クラウドへ反映できるかを、表2の対象ごとに確かめます。それぞれの作業に必要な許可をそろえます。

表2の商用帳票部品では、B社だけに開発者向けの利用枠がある条件を仮定しています。C社が帳票を改修するには、提供元の契約本文や書面回答を読み、C社の追加契約、A社名義の利用許諾、代替部品への変更を検討します。追加費用と許可条件は、引き継ぎの可否を判断する前に確認します。

A社の社内業務を保守するための開示と、グループ会社への配布、外部向け販売は別の用途です。表2の01・02は社内利用と保守に限る許諾例です。用途を広げる場合は、権利者との追加合意と外部ライセンスの確認を進めます。

発注時に変更の窓口と承認者も決めます。IPAの講演資料（出典：IPA「システム開発の健全化に向けて」（PDF））は、アジャイル開発モデルで変更を段階分けし、別紙に役割やスケジュール等を置く例を示しています。この資料はアジャイルモデルの説明です。個々の案件でも、部品の変更が費用・納品物・権利条件に影響する際には、契約担当者に確認を戻して記録する方法が考えられます。

すでに開発が終わり、引き継ぎ先を探している場合は、他社開発システムの保守引き継ぎで調べることで、環境・権限・資料の棚卸しと再現確認へ進んでください。

引渡時期・支払い・終了時の扱いを照合する

著作権を譲り受ける場合は、納品の条件も合わせる

著作権の譲渡を選ぶなら、対象部分、除外する既存資産、移転の条件と時点を決めます。文化庁のテキスト（出典：文化庁「著作権テキスト 令和8年度版」（PDF））は、著作権法第61条第2項について、第27条・第28条の権利が譲渡契約で特掲されていない場合、譲渡した側に留保されたと推定される旨を説明しています。著作者人格権は譲渡できないため、著作権の譲渡とは分け、将来の改修で必要な同意や適用される例外を契約担当者と確かめます。個別の契約では実際の文言と事情を確認して判断します。

譲渡や引渡しの範囲によって、見積りや契約の条件が変わることがあります。必要な権利と引渡物を先に書き出し、各社に同じ条件で尋ねると比べやすくなります（システム開発の相見積り｜条件をそろえる比較表）。

「最終代金の支払い時に移転・引渡し」とする案なら、支払い前の検収で何を受け取り、どの範囲で試用できるかも合わせます。中途終了時には、どこまで完成したものを、どの清算条件で渡すか、利用許諾が続くかを決めます。IPAのモデル契約案内（出典：IPA「情報システム・モデル取引・契約書（第二版）」）でも、契約不適合、報酬、協力義務などは分けて整理されています。契約の呼び名に加え、納品物と権利の具体的な条件を読みます。

表3　表2の納品物をいつ、誰が引き渡すか

成果物ごとに引渡内容、時期、受取担当を指定します。データの「終了通知後10営業日以内」は、この例で合意した期限です。

実際の出力期限、費用、保存・削除時期は、データ量とサービスの契約条件に合わせて合意します。添付ファイルや項目の対応が必要なら、それらも出力の対象とし、受領後に件数と内容を照合します。

アカウントとデータも、引き継ぎの条件に含める

クラウドや外部APIは、A社を契約・請求・管理の主体とし、B社には必要な操作権限を付ける案から検討できます。提供元がその契約形態を認めるかを問い合わせ、納品時の管理者追加、保守終了時のB社の権限解除、復旧担当を決めます。担当者ごとに権限を付与・解除できる方法を使います。

データを出力できる場合も、持ち出しや再利用には対象・目的・受領者に応じた許可が必要です。個人情報保護委員会のガイドライン（出典：個人情報保護委員会「通則編」）は、個人データの取扱いを委託する場合の安全管理や委託先の監督を定めています。営業秘密や第三者から提供されたデータの条件も確認し、移行に必要な範囲を限定します。

納品一覧の各行を契約本文・仕様書・見積りと突き合わせ、対象、できる行為、引渡時期、除外、費用、担当、未確定の事項をそろえます。空欄は推測で埋めず、開発会社、外部提供元、自社の契約・情報管理担当へ確認を割り振ります。

納品条件の判断表・記入例・空欄版をExcelでダウンロードして、自社の記入票に使えます。10シートに、掲載3表、6対象の記入例、空欄版、条件変更例、出典、入力候補を収録しています。

外部サービスを使うシステムでは、契約終了時に持ち出せるデータと代替先も確かめておきます（SaaS・AI APIの終了に備えるデータ移行計画）。

納品条件と将来の保守を開発担当者に相談

参考出典

• IPA「情報システム・モデル取引・契約書（第二版）」
• 文化庁「AIと著作権に関するチェックリスト＆ガイダンス」2024年7月31日・本文18〜21ページ（PDF）
• IPA「システム開発の健全化に向けて」2025年4月24日・PDF44〜48ページ
• 文化庁「著作権テキスト 令和8年度版」本文8〜9・11・13・49・51ページ（PDF）
• 個人情報保護委員会「通則編」2026年6月一部改正・3-4-2／3-4-4
• Open Source Initiative「The MIT License」

情報確認日：2026年9月15日。