弁護士 石田 優一
目次
第１章 はじめに
第２章 ＰｏＣとは
第３章 契約締結までのステップ
１ ユーザーに対してＰｏＣがなぜ必要かを説明する
２ 提案書を提示する
３ 導入検証契約書を用意する
第４章 知的財産をめぐる交渉
１ ＰｏＣによる成果物の著作権
２ ＰｏＣの過程で生じた発明の特許権
３ こちらのコラムもお読みください
第５章 プロジェクトマネジメント義務
１ プロジェクトマネジメント義務とは
２ ＰｏＣにおいてベンダーが実施すべき作業
３ ＰｏＣ段階におけるプロジェクトマネジメント義務
４ ＰｏＣの作業別に見たプロジェクトマネジメント義務
５ プロジェクトマネジメント義務違反に問われないために
第６章 おわりに
第１章 はじめに
第１回のコラムでは、ＡＩ開発プロジェクトの企画段階に関する法律問題を取り上げました。具体的には、ＡＩの企画段階におけるプロジェクトマネジメント義務や、個人情報の取扱い、知的財産をめぐるユーザーの交渉、秘密保持契約について取り上げました。今回のコラムでは、ＡＩ開発の前段階であるＰｏＣについて取り上げます。この段階においては、ベンダーに課せられるプロジェクトマネジメント義務はより具体的なものとなり、知的財産の権利帰属や取扱いをめぐる交渉も具体化します。
第２章 ＰｏＣとは
ＰｏＣ（Proof of Concept）は、企画段階におけるアイデアやコンセプトを本当に実現することができるかどうかや、目標にどこまで到達することができるかなどについて、検証することです。ＡＩ開発におけるＰｏＣでは、実際のデータを利用して試行的な学習を実施し、必要に応じて複数のアルゴリズムを試行します。
ディープラーニングをはじめとするＡＩは、実際にデータを用いて学習を試みなければ、本当に構想しているものを開発しうるかどうかが未知数です。ＰｏＣは、ＡＩの開発においては不可欠なプロセスです。
第３章 契約締結までのステップ
１ ユーザーに対してＰｏＣがなぜ必要かを説明する
ベンダーにとって、ＡＩの開発にＰｏＣが必要であることは常識的なことですが、多くのユーザーにとっては、なぜそのような手間を（多くの場合はユーザーが費用を負担して）かけなければならないのか、理解することができません。企画段階から、ユーザーに対して、「ＰｏＣがなぜ必要か」を説明しておくべきです。
２ 提案書を提示する
ＰｏＣをスタートする前には、提案書を作成し、ユーザーに提示することで、「ＰｏＣで何をするか」の理解を共有しておくべきです。なぜなら、ユーザーにこの点の理解がないと、ＰｏＣの結果としてプロジェクトの中止や変更を余儀なくされた場合に、トラブルになってしまうおそれがあるからです。ユーザーには、ＰｏＣが「予定どおりに開発を進められるかどうかを見極めるためのプロセス」であることについて、理解を求める必要があります。
３ 導入検証契約書を用意する
ＰｏＣをスタートする前には、ユーザーとの間で導入検証契約を締結することが一般的です。導入検証契約の条項を検討する際に参考になるのが、「ＡＩ・データの利用に関する契約ガイドライン－ＡＩ編－」（平成３０年６月経済産業省）の第７－５「ＰｏＣ段階の導入検証契約書（モデル契約書）」です。このガイドラインは、経済産業省のサイトにおいて公表されています。導入検証契約の条項についてユーザーと交渉するうえで特に重要になるのが、知的財産の取扱いです。これについては、次章で詳しく説明します。
ガイドラインに示されるモデル契約書は、あくまでも最低限必要な条項を列挙したものであることに留意が必要です。より本格的な契約書を締結したい場合には、ＡＩ法務に詳しい弁護士に相談したり、契約書の作成を依頼したりされることをおすすめします。
第４章 知的財産をめぐる交渉
１ ＰｏＣによる成果物の著作権
後述するように、ＰｏＣにおいては、学習結果に対する評価や、それを踏まえた開発計画について詳細な資料を作成し、ユーザーに提示することが一般的です。また、その前段階においても、ベンダーにおいて、提案書や中間報告資料が作成されることが一般的です。
これらのＰｏＣの段階で生じた成果物について、ユーザーに著作権を移転するかどうかは、ベンダーにとって重要なことです。なぜなら、ユーザーに著作権を移転させると、ベンダーが作成した成果物を利用して、ユーザーが他社にＡＩの開発を委託する（乗り換える）ことが容易になるからです。
前述した「ＰｏＣ段階の導入検証契約書（モデル契約書）」では、ＰｏＣの段階で生じた成果物の著作権はベンダーに帰属し、かつ、ユーザーが成果物を利用することができる範囲をＰｏＣの結果の検証に必要な範囲に限定する旨の条項が定められています。
ベンダーは、ユーザーが成果物の著作権を移転するように求めてきた場合においても、まずは、モデル契約書よりもユーザーに不利な条件ではないことを根拠に、応じない方向で交渉することが望ましいです。とはいえ、実際の交渉においては、ユーザーがそのような説得を踏まえても意向を変えず、ベンダーがそれ以上に頑なな姿勢を見せることで交渉が決裂してしまうこともありえます。そのような場合、ベンダーは、たとえユーザーが他社に乗り換えても損失が生じないように、適切な委託料を提示することが重要です。
２ ＰｏＣの過程で生じた発明の特許権
ＰｏＣにおいては、開発段階で学習に利用することが予定されているプログラムを利用したり、データを加工したりすることが一般的です。そうすると、ＰｏＣの過程において、ベンダーがプログラムやデータ構造などについて発明を創作することがありえます。
ＰｏＣの過程において生じた発明の特許権をユーザーに帰属させるか、ベンダーに帰属させるか、あるいはユーザーとベンダーとの共有とするかは、ベンダーにとって重要なことです。
第１に、特許権をユーザーに帰属させる場合、（ユーザーの許諾がない限り）ベンダーが今後の案件において同様のプログラムやデータ構造を利用することができなくなります。
第２に、特許権をユーザーとベンダーの共有とする場合、契約で別段の定めをしない限り、ユーザーの同意なくベンダーが今後の案件において同様のプログラムやデータ構造を利用することができなくなります。
以上の点を踏まえ、ベンダーは、まずは、ＰｏＣの過程において生じた発明の特許権は発明者側に帰属することをユーザーに対して求めるべきです。交渉にあたっては、特許制度の原則どおりの条件であることや、「ＰｏＣ段階の導入検証契約書（モデル契約書）」の第１７条Ａ案にも適合していることを根拠として説明することが考えられます。
とはいえ、実際の交渉においては、ユーザーがそのような説得を踏まえても意向を変えず、ベンダーがそれ以上に頑なな姿勢を見せることで交渉が決裂してしまうこともありえます。このような場合、ベンダーは、第２案として、特許権をユーザーとベンダーの共有とする条件をユーザーに提示すべきです。この場合は、発明を「相手方の同意なしに、かつ、相手方に対する対価の支払の義務を負うことなく、自ら実施することができる」旨を条項に含めるように交渉すべきです。そうしなければ、ベンダーは、（ユーザーの許諾がない限り）今後の案件において同様のプログラムやデータ構造を利用することができなくなります。
そして、これらの交渉によってもユーザーと折り合いがつかず、やむなく、ＰｏＣの過程において生じた発明の特許権をユーザーに帰属させることとするのであれば、自ら発明をしたプログラムやデータ構造を他の案件に転用することができなくなることを考慮した適切な委託料を提示することが重要です。
３ こちらのコラムもお読みください
第５章 プロジェクトマネジメント義務
１ プロジェクトマネジメント義務とは
前回のコラムで説明したように、ベンダーは、ユーザーに対して、プロジェクトマネジメント義務を負っています。
システムの企画段階・開発段階におけるベンダーのプロジェクトマネジメント義務に関して、スルガ銀行事件判決（東京高判平成２５年９月２６日）が参考になります。
まず、前回のコラムにおいて詳しく説明したように、企画段階のプロジェクトマネジメント義務として、ベンダーは、自ら提案するシステムの機能、ユーザーのニーズに対する充足度、システムの開発手法、受注後の開発体制等を検討・検証し、そこから想定されるリスクについて、ユーザーに説明する義務を負います。
また、開発段階のプロジェクトマネジメント義務として、ベンダーは、システムの開発過程で得た情報を集約・分析しながら専門的知見を用いてシステム構築を進め、ユーザーに必要な説明を行い、その了解を得ながら、必要な修正や調整などを行い、システムの完成に向けた作業を適切に行うべき義務を負います。そして、システムの開発過程で、当初想定していた開発費用、開発スコープ、開発期間のとおりにシステムの開発を進められない場合には、開発状況の分析、開発計画の変更の要否・内容、開発計画の中止の要否・影響などをユーザーに説明する義務を負います。
ＡＩの開発におけるＰｏＣ段階は、通常のシステムにおける企画段階と開発段階との中間に位置づけられます。ＰｏＣ段階に求められるプロジェクトマネジメント義務については、通常のシステムにおける企画段階と開発段階の双方の考え方をもとに検討する必要があります。
２ ＰｏＣにおいてベンダーが実施すべき作業
ＰｏＣ段階におけるプロジェクトマネジメント義務の内容を検討する前提として、ＰｏＣにおいて学習前にベンダーが実施すべき作業について確認しておきます。
ＰｏＣにおいては、ユーザーからデータの提供を受けて、データの観察、試行的なデータセットの作成や学習を実施し、企画段階で検討した仕様を実現することの可否や、実現することができる場合における目標の達成度予測などの検証を行います。
ＰｏＣにおいて学習前にベンダーが実施すべき作業を概観すると、次のとおりです。
(1) 分析の対象にするデータの範囲の決定
まずは、ＰｏＣにおいて分析の対象とする具体的なデータの範囲を決定しなければなりません。データの範囲は、実際の運用を想定して決定しなければなりませんから、ユーザーとのすり合わせで、実際に開発したＡＩを業務において運用する場面を想定しながら決定しなければなりません。
(2) データの分析
ユーザーから提供を受けたデータについて、学習に適しているか否かをあらかじめ分析します。データの分布に一定の相関性が見られるか、異常値や欠損が多くないか、あらかじめカテゴライズが必要か、その他の学習上の支障がないかといったことを、専門的知見から分析することが必要になります。
(3) モデル設計
試行的な学習を始める前提として、データをどのようなアルゴリズムで学習するかを検討します。
アルゴリズムの選定においては、データの量や性質のほか、ユーザーの意向も考慮することが必要です。例えば、ユーザーがＡＩの運用を通じて業務上のボトルネックを分析したいと考えている場合には、ＡＩが入力されたデータからどのようなプロセスで結果を出力しているかが分からないディープラーニングをアルゴリズムとして選択することは不適当です。一方で、人間の思考では代替が難しい複雑な分析を目指している場合には、ディープラーニングが他のアルゴリズムよりも有効であることが多々あります。さらに、複数のアルゴリズムを組み合わせた学習が、最適な効果を発揮する場合もあります。
ユーザーが想定する目標を実現しうるアルゴリズムの候補が複数あり、それぞれに長所・短所があって明確に甲乙をつけることができない場合には、複数のアルゴリズムを候補として選定しておくことが適切な場合もあります。ただし、複数のアルゴリズムについてＰｏＣを実施することで、ＰｏＣのコストが増大するリスクがあります。
(4) データの加工
まず、ＡＩの出力結果、つまり目的変数について、グループ化（複数の目的変数について一定の基準に基づいてグループとして統合する処理）やラベル化（目的変数ごとに一定の基準に基づいてラベルづけをする処理）が必要であるか否かを検討します。グループ化やラベル化は、ＡＩの出力結果をよりユーザーの利用目的に即したものにするための処理ですので、このような加工方法の検討に当たっては、ユーザーの意向も考慮する必要があります。
次に、ＡＩでの学習を始める前には、あらかじめ入力するデータを加工しなければなりません。具体的には、平滑化（データのノイズを除去するための処理）、データのグループ化（複数のデータについて一定の基準に基づいてグループとして統合する処理）、複数の種別のデータの統合による次元圧縮、異常値の削除・編集、画像データにおけるデータオーグメンテーション（既存の画像データの色彩や縮尺の変更、回転、反転、合成、抽出といった処理によってデータ数を増やし、学習精度を向上させる処理）などがあります。また、データをそのまま学習に利用したのでは意図した出力結果を期待することができない場合に、学習に適するようにデータのサンプリングを行うこともあります。これらの加工処理は、あらかじめ実施した(2)データの分析や、(3)モデル設計において選択したアルゴリズムに基づいて、専門的知見に基づいて実施する必要があります。
また、データに個人情報が含まれる場合には、個人情報保護法の規制により、個人情報を非個人情報や匿名加工情報などにするための加工処理が必要になるケースもあります。これについては、「ＡＩの開発を受託する前に学びたい法律知識１－企画編」で取り上げましたので、詳しくはそちらをご参照ください。このような加工については、あらかじめユーザーに必要性を確認しておく必要があります。ユーザーにその点の知識がない場合には、ベンダーが適宜アドバイスすることが望ましい対応です。
(5) 学習結果に対する評価指標の決定
ＰｏＣにおいて実施した試行的な学習の結果は、適切に評価し、その後の開発段階に活かさなければなりません。評価の指標となるのは、学習済みモデルの精度や解釈性、過学習の程度などです。
第１に、出力結果の精度とは、学習済みモデルに基づく予測結果があらかじめ用意した実績データとどの程度適合しているかという指標です。データをあらかじめ学習データと評価データに分けて検証します。学習データと評価データの選別方法や、実績データとの誤差の程度を検証する方法は、専門的知見に基づいて決定する必要があります。
第２に、モデルの解釈性とは、モデルの挙動について人の目でどこまで意味を理解することができるかどうかという指標です。もっとも、このような解釈性が重視されるのは、(3)モデル設計において、モデルの挙動を分析することが可能なアルゴリズムを選択した場合に限られます。
第３に、過学習の程度とは、学習済みモデルが学習データに過度に適合していないかどうかという指標です。学習済みモデルが学習データの傾向をあまりにつかみすぎると、学習データでは高い精度を発揮しているにもかかわらず、それ以外のデータでは精度が下がってしまう現象が起きてしまいます。これを過学習といいます。過学習が起きてしまった場合には、分析の対象にするデータの範囲やデータの加工方法、アルゴリズムなどを見直さなければなりません。
学習前には、このような学習結果の評価指標について、あらかじめ決定しておかなければなりません。
３ ＰｏＣ段階におけるプロジェクトマネジメント義務
まず、ＰｏＣ段階が企画段階の延長上にあることを踏まえれば、ベンダーは、専門的知見に基づいて、データの分析、試行的なデータセットの作成や学習といった一連の作業を適切に実施し、企画段階で検討したＡＩ自体や個々の仕様の実現の可否や、想定される精度、開発に先立って検討すべき課題などをユーザーに説明すべき義務を負うと考えられます。
また、ＰｏＣ段階が開発段階の前提にあることを踏まえれば、ベンダーは、試行的なデータセットの作成や学習によって得られた情報を専門的知見に基づいて分析して、その結果をユーザーに対して説明するとともに、必要に応じて、学習に用いるデータの種別やアルゴリズムの変更を行い、企画段階で検討したＡＩ自体や個々の仕様の実現に向けて適切な試行を実施すべき義務を負うと考えられます。そして、ベンダーは、ＰｏＣの結果を踏まえて、適切な開発費用、開発スコープ、開発期間その他の開発計画を適切に策定し、ユーザーに説明する義務を負うと考えられます。
４ ＰｏＣの作業別に見たプロジェクトマネジメント義務
(1) 分析の対象にするデータの範囲の決定
ベンダーは、企画段階で検討したＡＩの実現に向けて、分析の対象とする具体的なデータの範囲を専門的知見に基づいて決定する義務を負います。その際には、ユーザーからの聴き取りによって、ユーザーがどのようなデータを保有しているかや、ＡＩをどのような業務プロセスの中で利用することを予定しているかを把握すべき義務も負うものと考えられます。
(2) データの分析
ベンダーは、専門的知見に基づいて、ユーザーから提供を受けたデータを観察し、分析する義務を負います。この点は、ユーザーの意見にとらわれず、データを客観的に観察する姿勢が求められると考えられます。
(3) モデル設計
ベンダーは、専門的知見に基づいて、学習に用いるアルゴリズムを適切に選定する義務を負います。アルゴリズムの選定においては、ＡＩの技術的な知見からデータの量や性質に適したアルゴリズムを検討するほか、ユーザーからの意向を聴き取り、それにかなうアルゴリズム（複数のアルゴリズムの組合せを含みます）を検討する必要があると考えられます。また、最適なアルゴリズムを選択する際に複数のアルゴリズムでの試行が望ましい場合には、ユーザーにその必要性やコストを説明したうえで、ユーザーの了解を得て複数のアルゴリズムでの試行も検討すべきであると考えられます。
(4) データの加工
ベンダーは、専門的知見に基づいて、データの分析の結果や選定したアルゴリズムに即したデータの加工を適切に実施する義務を負います。データの加工は、ＡＩに関する専門的な知識やノウハウが問われる作業であり、その進め方について、ベンダーに一定の裁量が認められると考えられます。ただ、通常の専門的な知識があれば当然に実施すべきことが分かる加工処理を実施しなかったり、そのような知識があれば不適切であることが明らかであると判断することのできる加工処理を実施したりした場合には、プロジェクトマネジメント義務違反に問われうると考えられます。
データの加工が適切かどうかを判断するにあたっては、ＡＩをどのような業務プロセスの中で利用することを予定しているかも考慮すべきであり、そのような考慮を怠った場合にも、プロジェクトマネジメント義務違反が問題になると考えられます。また、ユーザーから、個人情報保護法の観点から個人情報が含まれるデータを非個人情報や匿名加工情報などに加工するように指示を受けているにもかかわらず、そのような加工処理を怠った場合にも、プロジェクトマネジメント義務違反に問われうると考えられます。
(5) 学習結果に対する評価指標の決定
ベンダーは、専門的知見に基づいて、学習済みモデルの精度や解釈性、過学習の程度といった学習結果に対する評価指標を決定する義務を負います。
評価指標の決定にあたっては、ユーザーがＡＩをどのような業務プロセスの中で利用することを予定しており、どの程度の精度や解釈性をＡＩに対して求めているのかについて、あらかじめ意向を確認しておく必要があります。そして、ユーザーの意向どおりに評価指標を設定することが難しい場合には、その理由をユーザーに説明して、理解を得ておくことが求められます。
このようなプロセスを経て適切な評価指標を決定しなければ、プロジェクトマネジメント義務違反に問われうると考えられます。
(6) 学習の実施及びその結果に対する評価
ベンダーは、学習前にプロセスに従って決定したことに従って学習を実施し、その結果を、あらかじめ定めた評価指標に従って、かつ、専門的知見に基づいて、適切に評価する義務を負います。そして、評価結果をユーザーに対して説明するとともに、必要に応じて、学習に用いるデータの種別やアルゴリズムの変更を提案する義務を負います。
さらに、ベンダーは、評価結果を踏まえて、適切な開発費用、開発スコープ、開発期間その他の開発計画を適切に策定し、ユーザーに説明する義務を負います。
ユーザーに説明する際には、エビデンスを残すために、詳細な資料を作成し、連絡協議会などの会議の機会を設定して議事録を残しておくことが適切です。
５ プロジェクトマネジメント義務違反に問われないために
ＡＩは、実際に運用を開始するまでユーザーの期待する仕様を備えた水準に達しているかどうかが不明瞭であることが多く、仮にその水準に達していないとしても、原因を追究することが困難な場合が多々あります。そのため、ＡＩの仕様に問題があるとしてユーザーがベンダーに責任追及をする場合に、ＰｏＣ段階のプロジェクトマネジメント義務違反を根拠にすることが１つの戦略になっていくことが予想されます。ベンダーは、ＰｏＣを軽視することがないように留意しなければなりません。
万一、ユーザーからプロジェクトマネジメント義務違反の主張を受けた際には、法的観点からＰｏＣの過程を検証し、反論すべきか、折り合うべきかを検討しなければなりません。その際には、早期にＡＩ法務に詳しい弁護士に相談されることをおすすめします。
第６章 おわりに
このコラムでは、ＡＩの開発に先立つＰｏＣのプロセスにおいて留意しなければならない法律トラブルや知的財産の問題を中心に解説しました。ＰｏＣは、従来型のシステム開発においては積極的に採り入れられないプロセスですが、ＡＩの開発においては不可欠なものです。今回のコラムで取り上げた法的観点を理解して実践していただくことで、その後のプロセスでユーザーと法律トラブルが生じるリスクを大きく減らすことができます。
ＰｏＣのプロセスでは、ベンダーがプロジェクトマネジメント義務を積極的に負うようになり、企画段階よりも一層、法的リスクが高まります。ですから、遅くとも、ＰｏＣを受託する段階においては、ＡＩ法務に詳しい弁護士に気軽に相談することのできる体制を構築しておくことをおすすめします。
次回は、いよいよ、ＰｏＣを終えて、本格的にＡＩの開発をスタートする段階の法律問題を取り上げます。この段階では、ベンダーに対して厳しいプロジェクトマネジメント義務が課せられるようになり、知的財産の問題もより複雑になります。ぜひご期待ください。
