執筆・文責：弁理士　中村幸雄

AI開発では、成果物が一つのファイルにまとまるとは限りません。

仕様書、ソースコード、プロンプト、設定値、RAG用文書、評価ログ、API連携、管理画面、運用ルール。開発の過程で生まれる資料は、さまざまな場所に分散します。

後から問題になるのは、「何を作ったか」だけではありません。

この記事では、後から知財・成果物・データ・ノウハウの扱いが問題になったときに、どのような事実を説明できるようにしておくべきかを、公証制度や電子的な証拠手段との関係から整理します。

公証制度は、知財トラブルを自動的に解決する制度ではない

公証制度を使っても、成果物の権利帰属が自動的に決まるわけではありません。

これらは、契約内容、開発経緯、資料の内容、実際のやり取りなどを踏まえて整理する必要があります。

公証制度の役割は、将来争点になり得る文書や事実について、「存在した時期」や「成立の信用性」を高めることにあります。

たとえば、次のような事実の説明に役立ちます。

重要なのは、何が後で問題になりそうかを考え、その事実を説明できる資料を残しておくことです。

AI開発では、なぜ知財証拠が重要になるのか

AI開発では、従来のソフトウェア開発以上に、成果物や情報の境界が見えにくくなることがあります。

たとえば、AI SaaSやAIエージェント開発では、次のようなものが関係します。

これらは、特許、著作権、営業秘密、商標、成果物の範囲、ノウハウ、データ利用など、複数の知財・事業リスクと関係します。

問題になりやすいのは、次のような場面です。

契約書は重要ですが、AI開発では、日々の開発資料や記録を、後からたどれる形で残しておくことも大切です。

知財分野で、証拠を残すべき5つの場面

AI開発やAIサービス運営では、次のような場面で「いつ、何が、誰によって、どの条件で扱われていたか」が問題になります。

場面 後で問題になること 残すべき証拠
成果物の範囲 何が納品物・成果物だったのか 仕様書、成果物一覧、納品書、検収記録、画面、リポジトリ
データ提供 誰が、どのデータを、どの目的で提供したか データ一覧、提供記録、アップロード記録、利用条件、削除記録
ノウハウ・秘密情報 何を秘密情報として扱っていたか NDA、秘密情報一覧、管理台帳、アクセス権限、開示記録
OSS・API・外部サービス 成果物に何が組み込まれていたか OSS一覧、ライセンス表、API利用規約、構成表、依存関係
開発経緯・仕様変更 誰がどの提案・修正・判断をしたか 議事録、メール、チャット、チケット履歴、変更履歴、提案資料

これらすべてを公証することは現実的ではありません。まず、通常の業務資料として、後からたどれる状態を作ることです。そのうえで、特に重要通常の業務資料として、後からたどれる状態を作ることです。そのうえで、特に重要な資料、後で消えやすい画面、争点になりやすい事実について、公証制度や電子的な証拠手段の利用を検討します。

公証制度では何ができるのか

公証制度とは、法務大臣が任命する公証人が、公正証書の作成、私署証書の認証、確定日付の付与などの公証事務を行う制度です。知財証拠の整理で大切なのは、「何を証明したいのか」を明確にすることです。目的によって、残すべき資料も、使うべき公証事務も変わります。

公証事務 一般的な役割 注意点
確定日付 私文書に確定した日付を付与し、その日にその文書が存在していたことを示す。 仕様書、成果物一覧、データ一覧、説明書などの存在時期を示す手段になる。ただし、内容の正しさまでは当然に証明しない。
私署証書の認証 私文書の署名・記名押印が本人のものであることを公証人が証明する。 成果物説明書、提供経緯説明書、資料一覧などについて、誰が作成した文書かを明確にする手段になる。
宣誓認証 作成者が、公証人の面前で文書の記載内容が真実であることを宣誓し、その署名等について認証を受ける。 開発経緯、データ提供、ノウハウ管理状況などについて、作成者の宣誓を残す手段になる。虚偽の宣誓には制裁がある。
事実実験公正証書 公証人が、実際に見聞きし、確認した事実を公正証書として記録する。 Web画面、管理画面、リポジトリ、ファイル構成、アクセス権限などの状態を客観的に残す手段になる。
契約公正証書 契約などの法律行為の内容を、公正証書として作成する。 契約内容を明確にする手段になり得るが、成果物、権利帰属、利用範囲、秘密保持などの整理は事前に必要。

デジタル成果物では、電子的な証拠手段も組み合わせる

AI開発の成果物は、多くの場合、紙の書類ではありません。

ソースコード、プロンプト、設定ファイル、RAG用文書、評価ログ、学習用データ、API連携仕様、Gitのコミット履歴など、ほとんどがデジタルデータとして存在します。

そのため、公証制度だけで考えるのではなく、電子的な証拠手段もあわせて検討する必要があります。

手段 使いやすい場面 注意点
電子確定日付 PDF化した仕様書、成果物一覧、技術説明書、データ提供一覧などについて、ある時点で電子文書が存在していたことを残す。 内容の正しさや権利帰属まで当然に証明するものではない。
認定タイムスタンプ ソースコード、プロンプト、設定ファイル、評価ログ、データ一覧などについて、存在時刻と非改ざん性を補強する。 どのファイルに、どの時点で、どの方式で付与したかを管理する必要がある。
Git・チケット管理履歴 開発経緯、修正履歴、担当者、レビュー、仕様変更の流れを連続的に残す。 社内システム上の記録だけでは、管理権限や改変可能性が問題になることがある。
電子署名 説明書、確認書、成果物一覧などについて、誰が作成・承認したかを明確にする。 文書の内容そのものが正しいことまで当然に保証するものではない。
プログラム著作物登録 プログラムの創作年月日や第一発行年月日を公的に登録する選択肢になる。 対象はプログラム著作物であり、AIシステム全体、アイデア、仕様、ノウハウをまとめて保護する制度ではない。

AI開発では、日々の開発履歴をすべて公証することは現実的ではありません。

通常は、Git、チケット管理、クラウドストレージ、議事録、メール、チャットなどの日常的な記録を残し、重要な節目だけを電子確定日付、認定タイムスタンプ、事実実験公正証書、プログラム著作物登録などで補強する、という考え方が現実的です。

また、登録後には、手元の記録媒体に記録されたプログラムが登録されたプログラム著作物であることについて、プログラム登録に関する証明の請求ができる場合があります。

1. 成果物の範囲を残す

AI受託開発やPoCでは、後から「何が成果物だったのか」が問題になることがあります。納品物はソースコードだけとは限りません。プロンプト、設定ファイル、RAG用文書、評価結果、API連携仕様、管理画面、運用マニュアル、検証レポートなどが成果物に含まれることもあります。

残しておきたい資料としては、次のようなものがあります。

たとえば、成果物一覧、納品資料、仕様書、検証レポートについて、ある時点でその資料が存在していたことを残したい場合には、確定日付や電子確定日付が候補になります。

プロダクト責任者や開発責任者が、「どの資料が納品対象で、どのファイルが成果物に対応するのか」を整理した成果物説明書を作成し、署名者を明確にしたい場合には、私署証書の認証が候補になります。

納品時点の管理画面、デモ環境、リポジトリのファイル構成、モデル設定画面、API接続画面などを第三者の立場で残したい場合には、事実実験公正証書が候補になります。

2. データ提供・利用条件を残す

AI開発では、データの扱いが大きな問題になります。顧客が提供したデータなのか、開発会社が用意したデータなのか、公開データなのか、学習に使ってよいのか、RAGの検索対象に限って使うのか、検証後に削除するのか、他案件で再利用してよいのか、など。

これらが曖昧なまま進むと、後から「そのデータを使ってよかったのか」「別案件に流用していないか」「削除したのか」といった問題が生じることがあります。

残しておきたい資料としては、次のようなものがあります。

この場面では、まずデータ提供一覧、利用条件メモ、削除記録、データ加工手順書などを整理します。そのうえで、重要な資料には確定日付、電子確定日付、認定タイムスタンプなどを検討します。

3. ノウハウ・秘密情報の提供経緯を残す

AI開発では、技術資料そのものよりも、運用上のノウハウが価値を持つことがあります。

たとえば、次のようなものです。

これらを外部に開示する場合、後から「何を秘密情報として渡したのか」「どの範囲で使ってよい前提だったのか」「相手方にどこまで共有したのか」が問題になることがあります。

残しておきたい資料としては、次のようなものがあります。

たとえば、ノウハウ管理台帳、秘密情報一覧、開示資料一覧について、ある時点で存在していたことを残したい場合には、確定日付や電子確定日付が候補になります。

情報管理責任者が、「どの資料を秘密情報として管理していたのか」「誰に、どの範囲で開示したのか」「どのようなアクセス制限を設けていたのか」を整理した説明書を作成し、署名者を明確にしたい場合には、私署証書の認証が候補になります。

秘密情報の管理状況や開示経緯について、本人の供述として明確に残したい場合には、宣誓認証も考えられます。

実際の管理状態を第三者の立場で残したい場合には、事実実験公正証書が候補になります。たとえば、資料に秘密表示が付されていること、共有フォルダにアクセス権限が設定されていること、社内ナレッジベースの閲覧範囲が限定されていること、リポジトリやクラウドストレージの権限設定がされていることなどです。

ただし、公証制度を使ったからといって、直ちに営業秘密として保護されるわけではありません。営業秘密として保護されるためには、情報が有用であること、秘密として管理されていること、公然と知られていないことが問題になります。

4. OSS・API・外部サービス利用の記録を残す

AI開発では、OSS、外部API、クラウドサービス、生成AIツールなどを組み合わせて成果物を作ることがあります。

この場合、後から問題になるのは、成果物の中に何が含まれていたかです。

どのOSSを使っていたのか。
どのライセンスだったのか。
どのAPIを利用していたのか。
どの外部サービスの利用規約が関係していたのか。
どのバージョンを使っていたのか。
成果物のどの部分が自社開発で、どの部分が外部要素なのか。

これらを説明できないと、納品後、事業化後、投資・M&A・紛争時に問題になることがあります。

残しておきたい資料としては、次のようなものがあります。

この場面で使いやすいのは、日常的な開発管理記録です。たとえば、依存関係の管理、ライセンス表、利用規約の確認日、外部APIの設定画面、成果物構成表を残しておきます。重要な資料については、確定日付、電子確定日付、認定タイムスタンプが候補になります。

5. 開発経緯・仕様変更の記録を残す

AI開発では、当初の仕様どおりに進まないことが珍しくありません。

こうした変更は、開発の自然な一部です。

しかし、後から「誰がその変更を依頼したのか」「追加開発なのか」「成果物の範囲に含まれるのか」「どの時点で仕様が変わったのか」が問題になることがあります。

残しておきたい資料としては、次のようなものがあります。

この場面では、Git、チケット管理、議事録、メール、チャットの履歴が基本です。

重要な仕様変更メモ、議事録、追加見積り、合意メモなどについては、確定日付、電子確定日付、認定タイムスタンプが候補になります。

開発責任者やプロジェクト責任者が、「どの時点で、どの仕様変更があり、どの資料に反映されたのか」を整理した説明書を作成し、署名者を明確にしたい場合には、私署証書の認証も考えられます。

実務で残しておきたい資料リスト

最初から完璧な証拠ファイルを作る必要はありません。

AI開発では、資料が多くの場所に分散します。仕様書、チャット、Git、Notion、Google Drive、Slack、メール、管理画面、請求書、ログ。

大切なのは、それらを後からたどれるようにしておくことです。

成果物を示す資料

仕様書、成果物一覧、納品書、検収記録、ソースコード、リポジトリ、プロンプト一覧、API連携仕様、モデル設定、管理画面、操作マニュアル、検証レポート

データ提供を示す資料

データ一覧、提供日時、提供者、利用目的、利用条件、アップロード記録、アクセスログ、加工履歴、削除記録、匿名化・マスキング記録

ノウハウ・秘密情報を示す資料

秘密情報一覧、ノウハウ管理台帳、NDA、開示資料一覧、秘密表示、アクセス権限、共有フォルダの記録、返還・削除記録

外部要素を示す資料

OSS一覧、ライセンス表、API利用規約、外部サービス利用条件、バージョン情報、依存関係、成果物構成表、クラウド構成図

開発経緯を示す資料

議事録、メール、チャット、チケット履歴、仕様変更メモ、追加見積り、提案資料、合意メモ、バージョン履歴、リリースノート、顧客確認記録

よくある誤解

Q 公証すれば、成果物の権利帰属が決まりますか？

決まりません。公証制度は、文書や事実の存在時期、成立の信用性などを高める制度です。権利帰属は、契約内容、開発経緯、実際のやり取りなどを踏まえて整理する必要があります。

Q 契約書があれば、証拠を残さなくても大丈夫ですか？

契約書は重要ですが、それだけでは足りないことがあります。実際の開発では、契約後に仕様が変わったり、契約に書かれていない作業が発生したりします。日々の記録が、契約内容と実態の橋渡しになります。

Q AI開発では、毎回公証制度を使うべきですか？

毎回使う必要はありません。日常的な記録を基本としたうえで、重要な節目や、後で争点になりやすい事実について、公証制度や電子的な証拠手段の利用を検討するのが現実的です。

Q ソースコードの創作時期を示したい場合、公証制度以外の方法はありますか？

あります。たとえば、認定タイムスタンプ、Gitのコミット履歴、プログラム著作物登録などが候補になります。それぞれ証明できる内容や手続きが異なるため、何を示したいのかに応じて選ぶことになります。

Q チャットやメールも証拠になりますか？

なり得ます。誰が、いつ、何を伝えたのかを示す資料として役立つことがあります。重要なやり取りは、検索しやすい形で残し、必要に応じて消去されない場所に保管しておくことが望まれます。

Q 公証制度を使えば、データ利用やOSS利用の問題は解決しますか？

解決しません。公証制度は、ある時点でその資料が存在していたことなどを示す手段にすぎません。データやOSSを利用してよいかどうかは、利用条件、ライセンス、契約内容などを踏まえて、別途整理する必要があります。

公証制度を使う前に、整理しておきたいこと

証拠は、問題が起きてから集めるものではありません。

開発が進み、資料が作られ、データが提供され、成果物が形になっていく過程で、自然に残していくものです。

大切なのは、公証制度を使うかどうかの前に、何を後から説明したいのかを明確にすることです。

知財の余白では、AI開発やAIサービス運営において、成果物、データ、ノウハウ、発明、商標などがどのように関係しているかを整理します。

執筆・文責

弁理士　中村幸雄

特許・商標を中心に、著作権、意匠、営業秘密など、事業上の知財論点を整理する弁理士。 「知財の余白」では、権利の種類がまだ分からない段階から、知財・ブランド・事業リスクの入口を整理するための情報を発信しています。