執筆・文責：弁理士　中村幸雄（登録番号 第12870号）

／

この記事の結論

AI開発では、コード、データ、プロンプト、設定、評価ログ、変更履歴を作成時点から保存します。日常の記録を基本に、何を示したいかに応じて公証制度や電子的な証拠手段を選びます。

AI開発では、ソースコード、プロンプト、設定ファイル、評価ログなど、複数のファイルが成果物に含まれることがあります。

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

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

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

公証制度は権利帰属や知財トラブルを解決するか

成果物の権利帰属は、契約と開発の実態に基づいて判断します。公証制度は、その判断に使う文書や事実を記録・証明するための手段です。

これらは、契約内容、開発経緯、記録、実際のやり取りを照合して判断します。

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

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

後で争点になり得る事実を想定し、その経緯を示す記録を選びます。

AI開発で証拠を残す必要があるのはなぜか

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

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

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

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

契約書と日々の開発記録を対応させ、仕様変更や提供の経緯を後からたどれるようにします。

いつ、どの場面で証拠を残すべきか

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

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

通常の業務記録を継続して保存し、後から経緯をたどれる状態を作ります。そのうえで、特に重要な記録、消えやすい画面、争点になり得る事実について、公証制度や電子的な証拠手段を選びます。

公証制度で何を証明できるか

公証制度では、法務大臣が任命する公証人が、公正証書の作成、私署証書の認証、確定日付の付与などを行います。利用する際は、まず何を証明したいかを決めます。文書の存在時期、署名の真正、画面の状態など、目的に応じて記録と手続を選びます。（参考：公証事務、相談時に伝える事実と期限）

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

デジタル成果物にどの証拠手段を組み合わせるか

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

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

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

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

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

Git、チケット管理、クラウドストレージ、議事録、メール、チャットで日々の経緯を残します。納品や重要な仕様変更などの節目では、電子確定日付、認定タイムスタンプ、事実実験公正証書等による補強を検討します。プログラムの創作年月日等には、プログラム著作物登録も候補になります。

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

成果物の範囲をどう記録するか

AI受託開発やPoCでは、納品対象をファイルや画面の一覧に対応させます。ソースコードに加え、プロンプト、設定、RAG用文書、評価結果、API仕様、管理画面、マニュアル等が成果物に含まれる場合があります。

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

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

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

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

データの提供・利用条件をどう記録するか

AI開発では、データの提供者と利用目的を記録します。顧客提供、開発会社の保有、公開データを区別し、学習、RAG検索、検証などの利用範囲を示します。検証後の削除や、他案件での再利用の条件も残します。

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

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

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

ノウハウ・秘密情報の提供経緯をどう記録するか

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

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

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

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

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

情報管理責任者は、秘密情報として管理した資料、開示先と範囲、アクセス制限を説明書に記載します。署名が本人のものであることを示すには、私署証書の認証が候補になります。

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

実際の管理状態を公証人が記録する手段として、事実実験公正証書が候補になります。資料の秘密表示、共有フォルダのアクセス権限、社内ナレッジベースの閲覧範囲などを記録します。リポジトリやクラウドストレージの権限設定も対象になり得ます。

営業秘密としての保護には、有用性、秘密管理性、非公知性の3要件を満たす必要があります（不正競争防止法第2条第6項）。公証制度では、それらの判断に使う管理状況や開示の経緯を記録します。（参考：不正競争防止法第2条第6項、情報が有用であること、秘密として管理されていること、公然と知られていないこと）

OSS・API・外部サービス利用をどう記録するか

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

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

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

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

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

開発チームは、依存関係、ライセンス表、利用規約を調べた日、外部APIの設定画面、成果物構成表を保存します。重要な記録の存在時期等を補強するには、確定日付、電子確定日付、認定タイムスタンプが候補になります。

開発経緯・仕様変更をどう記録するか

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

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

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

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

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

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

開発責任者やプロジェクト責任者は、仕様変更の時期、変更内容、反映先の資料を説明書に記載します。署名が本人のものであることを示すには、私署証書の認証が候補になります。

実務でどの資料を残すべきか

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

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

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

成果物を示す資料

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

データ提供を示す資料

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

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

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

外部要素を示す資料

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

開発経緯を示す資料

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

AI開発の知財証拠についてよくある誤解

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

公証だけで権利帰属は決まりません。成果物ごとの契約条件、開発経緯、実際のやり取りを照合して判断します。公証制度は、その判断に使う文書の存在時期や成立、事実を記録・証明する手段です。（参考：成果物ごとの契約内容と利用条件）

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

契約書に加え、仕様変更や追加作業の記録も残します。日々の記録を契約書に対応させると、合意した内容と開発の実態を照合できます。

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

日常的な記録を基本に、納品や重要な仕様変更などの節目と、争点になり得る事実について、公証制度や電子的な証拠手段を検討します。

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

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

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

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

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

利用できるかどうかは、データの利用条件、OSSのライセンス、契約内容から判断します。公証は、文書の存在時期等を示す手段であり、利用許諾を与えるものではありません。

公証制度を使う前に、示したい事実を選ぶ

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

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

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

知財の余白では、AI開発やサービス運営の契約・記録をもとに、成果物、データ、ノウハウ、発明、商標に関係する権利と対応を検討します。

参考資料

  1. 日本公証人連合会「公証事務」（2026年8月2日閲覧）
  2. 日本公証人連合会「電子公証（電磁的記録の認証及び電子確定日付）」（2026年8月2日閲覧）
  3. 一般財団法人日本データ通信協会「認定タイムスタンプを利用する事業者に関する登録制度」（2026年8月2日閲覧）
  4. 一般財団法人ソフトウェア情報センター（SOFTIC）「プログラム著作物登録」（2026年8月2日閲覧）
  5. 一般財団法人ソフトウェア情報センター（SOFTIC）「登録内容の確認」（2026年8月2日閲覧）
  6. 経済産業省「営業秘密～営業秘密を守り活用する～」（2026年8月2日閲覧）
  7. e-Gov法令検索「不正競争防止法（平成5年法律第47号）」（第2条第6項、2026年8月5日閲覧）

執筆・文責

弁理士　中村幸雄

特許・商標を中心に、著作権、意匠、営業秘密など、事業上の知財課題を見極める弁理士。 「知財の余白」では、権利の種類がまだ分からない段階から、関係する権利や事業上のリスクを見極めるための情報を発信しています。