← ガイド一覧

著作権・知的財産の帰属— 発注条件との整合

公開: 2026年9月2日

Web制作・ソフトウェア・デザイン委託では、成果物の著作権が誰に帰属するかが契約の中心になります。
取適法の発注書面に書く「業務内容・報酬」と、著作権譲渡・利用許諾条項が矛盾していると、検収後のトラブルや支払争いにつながります。
本記事では、著作権・知的財産の帰属条項と発注条件の整合の取り方を整理します。

1. 発注書面と著作権条項

1-1. 業務内容に成果物を書く

「サイト制作」だけでは不十分です。
納品物(ソースコード、デザインデータ、ドキュメント)を列挙し、検収の対象を具体化します。
検収基準の決め方は検収基準の決め方を参照してください。

1-2. 著作権の帰属・譲渡のタイミング

著作権が発注者に移転するのはいつか(検収完了時・全額支払時など)を条項で固定します。
支払期日(60日以内)と移転タイミングがずれると、権利未確定のまま利用するリスクがあります。

2. 基本契約と個別発注の整合

2-1. マスタ契約のIP条項

基本契約で「成果物の著作権は発注者に帰属」と書き、個別発注で「素材の権利は受託者に残る」と書くと矛盾します。
個別発注書で例外を列挙するか、マスタを更新します。
基本と個別の関係は基本契約と個別発注を参照してください。

2-2. 第三者素材・ライセンス

フォント・画像・OSSの利用条件は、納品物に含まれる場合、発注側が遵守する義務が生じます。
委託契約で「権利クリアな素材のみ使用」「OSSは一覧を添付」と義務づけ、検収時に確認します。

3. 台帳と検収記録

3-1. 権利移転確認欄

台帳に「著作権移転確認済み」チェックと日付を持たせ、検収承認と同時に更新する運用にします。
部分納品の場合は、モジュールごとに権利範囲をメモします。

3-2. 支払と権利の順序

全額支払までソースを渡さない・支払後に譲渡するなど、取引慣行に合わせつつ書面と一致させます。
60日以内の支払義務と、権利移転条件が両立するよう条項を設計します。
支払期日は60日の起算もあわせて確認してください。

よくある質問

Q. 著作権は支払いと同時に移転させるべきですか?

契約で定めます。移転タイミングと検収・支払の順序を一文で揃えます。

Q. 利用許諾だけで十分な場合は?

独占利用か非独占か、期間・地域を発注条件に明記し、帰属と混同しないようにします。

Q. 受託者のポートフォリオ利用は?

発注書または別条項で許諾範囲を書き、秘密情報との境界を定めます。

Q. 職務著作の扱いは?

雇用と委託で異なります。委託では契約による譲渡・利用許諾が中心です。個別に専門家へ確認を。

Q. 知的財産の記載は3条4条に含まれますか?

業務内容・成果物の定義として発注書面に含め、詳細は別条項で補足する形が一般的です。

4. トラブル回避の具体策

4-1. 部分納品と権利の段階移転

モジュール単位で納品する開発案件では、モジュールごとに検収・著作権移転・支払をセットにします。
「全体が終わるまで権利は移転しない」条項と、60日以内の支払義務が両立するよう、 モジュール検収ごとに支払対象を分割する設計が現実的です。

4-2. 素材の権利クリア

検収チェックリストに「ストックフォトのライセンス証跡」「OSS一覧とライセンス種別」を追加します。
納品後に第三者から権利主張があった場合の報告義務・損害負担を契約に書き、 発注条件との整合を取ります。

4-3. 台帳の権利確認欄

  • 検収日・検収担当者
  • 著作権移転/利用許諾の確認日
  • ソースコード受領の有無
  • OSS・素材リストの受領の有無

5. 契約条項の書き方のヒント

5-1. 譲渡と利用許諾の使い分け

著作権を譲渡する場合と、利用許諾のみ付与する場合で、発注側ができること(改変・再配布・サブライセンス)が変わります。
SaaS開発では、ソースの譲渡とホスティング環境の利用許諾を分けて記載することがあります。

5-2. 支払条件とのリンク

「全額支払をもって著作権を移転する」条項は一般的ですが、60日以内の支払義務と矛盾しないよう、 検収から支払までの社内フローを短く保つ必要があります。
分割支払の場合は、分割ごとの権利移転範囲を明記します。

5-3. 監査用フォルダ

契約書・発注書・検収メール・権利移転確認チェック・支払記録を、案件フォルダにセットで保管します。
IP条項だけ別管理にすると、検収済みなのに権利未移転の状態に気づけません。

6. IPと支払の一体管理

6-1. 実務の勘所

取引先との関係が良好でも、書面・受領日・支払期日の記録は省略しないことが長期的なリスク低減につながります。
担当者個人の記憶やチャットの履歴だけに依存すると、異動・退職・監査のタイミングで説明不能な行が出やすくなります。
月次の短いレビュー(未入力受領日・期日7日以内・書面未交付)をカレンダーに固定し、経理と発注担当が同じリストを見る習慣を作ります。

6-2. トリカク(torikaku) の活用

トリカク(torikaku) は、形式判定・書面チェック・60日起算・期日リマインドを発注側の視点で支援するツールです。
本記事で整理した受領日の習慣化や台帳項目を、システム上の必須フィールドとして設定すると、属人化を防ぎやすくなります。
ツール導入だけで全てが解決するわけではありませんが、「空欄の受領日」を一覧でゼロにする運用と相性が良い領域です。

6-3. 次に読む記事

発注コンプラ全体の入口はチェックリスト記事、支払期日の起算は60日の数え方も参照してください。
個別契約の解釈が必要な場合は、記録を整理したうえで専門家へ相談することをおすすめします。

7. デザイン・コードの混在案件

デザインデータ(Figma等)とソースコードで権利処理が異なる場合、納品物リストごとに帰属・ライセンスを書き分けます。
フォント・画像素材はデザイン側、OSSはコード側のチェックリストで確認し、検収時に両方の確認欄を埋めます。
ポートフォolio利用を許可する場合も、クライアント名・掲載範囲を発注条件または別覚書で限定します。

8. 記録品質の向上

書面・台帳・メールログの三者が食い違わないよう、契約更新や条件変更のたびに「どの文書が最新か」を取引先フォルダの先頭にメモします。
監査や取引先からの問い合わせ時に、5分以内に一式を提出できる状態を目標に、命名規則とフォルダ構成を社内標準化します。
記録の質は、一度に完璧を目指すより、月次で少しずつ穴を埋めるサイクルの方が続きやすいです。

8-1. 二次利用の範囲

納品物を自社の別プロダクトへ流用する場合、利用許諾の範囲(媒体・期間・改変)を契約上確認します。
流用の都度、法務へ確認するのではなく、初回契約時に想定ユースケースを列挙しておきます。
列挙したユースケースは台帳の契約メモ欄にも転記します。

8-2. 定期振り返り

四半期に1回、本テーマに関する台帳の未入力行と協議ログの欠落を洗い出し、改善項目を1つだけ決めて実行します。
小さな改善を積み重ねる方が、年次監査前の突発対応より負担が小さいです。
改善結果は次四半期のレビュー資料に1行でよいので必ず記録し、同じ漏れを繰り返さないようにします。

まとめ

  • 成果物を具体的に列挙し検収基準と著作権移転タイミングを一致させる
  • 基本契約と個別発注でIP条項が矛盾しないよう例外を明示する
  • 台帳に権利移転確認欄を持ち検収・支払と連動させる

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、法的助言ではありません。
個別の契約・適用判断は弁護士等の専門家にご確認ください。

トリカク(torikaku) で試す

適用判定・取引先台帳・明示事項チェック・60日ルールの期日管理・メール通知を一箇所にまとめられます。無料プランは稼働中の取引先1社・発注記録 月3件までです。停止中の取引先は枠を消費しません。形式チェック・記録管理・期日管理のみを行います。メール通知の遅延・未達は保証しません。法令・ガイドライン改正時は判定ロジックを更新し、公開ページに案内します。

適用の形式判定だけ試す場合(ログイン不要): /check

← ガイド一覧