知財トラブル回避の契約レビュー：委託開発で起きがちな著作権・商標リスク

1. まず確認する「成果物」の定義

著作権リスクは、成果物（納品対象）の範囲が曖昧なときに顕在化します。「プログラムのみ」なのか、「ソースコード、設定、設計書、仕様書、テストデータ、管理用ドキュメント」まで含むのか。さらに、開発途中で生まれる成果物（プロトタイプ、検証用コード、成果物の一部）をどう扱うかを契約で固定します。

レビュー観点としては、成果物の一覧化（添付別紙や納品物リスト）と、検収条件・不具合対応の位置づけを、著作権帰属の条項とセットで確認してください。

2. 著作権帰属：譲渡か許諾か、そして「方式」と「範囲」

委託開発の著作権は、契約で「何を、どう」得るのかが鍵です。一般に、成果物の利用を自社で自由に行いたいなら譲渡設計が必要になります。一方で、受託側が保有する汎用ライブラリや既存資産が混在する場合、譲渡できない要素（バックグラウンド）を整理し、利用許諾でカバーします。

• フォアグラウンド（成果物）とバックグラウンド（既存資産）を明確に分ける
• 譲渡（または許諾）の対象範囲を、複製・改変・翻案・翻訳・二次利用まで具体化する
• 許諾の場合、地域・期間・利用形態（オンプレ/クラウド/再販等）を締める
• 再許諾（サブライセンス）や再委託の可否を運用に合わせる

3. ソースコードとドキュメントの扱い

ソースコードの引き渡し、版管理のルール、ビルド手順、設定ファイル、依存関係（ライブラリ名とバージョン）まで含めて契約に落とすと、保守・移管時の摩擦が減ります。特に「後から作って渡す」になっている場合、著作権や契約不適合の問題が長引きます。

レビューでは、納品形式(リポジトリ/アーカイブ)、更新頻度、検収後の修正分（追加成果物）の帰属と利用も一緒に確認してください。

4. 検収・瑕疵対応と「権利の確保」

検収が完了するまでは権利が固まらない、という構造は危険です。検収の条件と、成果物が段階的に引き渡される場合（開発スプリント等）の権利の帰属タイミングを整理します。

不具合修正や改善の成果が追加で生じるとき、その追加成果物も同様の帰属・許諾設計に含めるかをチェックしてください。

5. 商標リスク：提供する表示と事業展開の前提を一致させる

委託開発では、アプリ名、機能名、ロゴ、UI表現など「表示」も成果物に含まれることが多いです。ここで商標のリスクが起きるのは、(1) 表示の権利帰属や使用許諾が契約で固定されていない、(2) 顧客や受託側が独自に用意した表示が混ざり、後から権利者が増える、(3) 出願や権利化の方針が未決、というパターンです。

• 商標として使う可能性がある名称・ロゴ等を「対象リスト化」する
• 第三者権利（既存商標や意匠・著作権等）との関係を事前に確認する
• 出願・維持・異議対応などの役割分担を明確にする
• 表示の利用範囲（サービス種別、国/地域、媒体、期間）を揃える

6. 相手方の保証条項と損害賠償の整合

権利侵害が疑われる場合、どこまでが保証され、どのタイミングで通知し、どの費用を誰が負担するか。さらに、間接損害や逸失利益の扱いが、実務で期待する救済と一致しているかを確認します。

契約レビューでは「知財条項」単体で読むのではなく、損害賠償、解除、検収、不具合対応の各条項と接続させて矛盾を潰すことが重要です。

チェックリスト（短縮版）