弁護士　石田　優一

目次

第１章　はじめに
第２章　ＡＩ開発契約を締結する際の留意点
１　従来のシステム開発契約とは大きく違う
２　ＡＩ開発契約書はどうやって用意するか
３　請負契約か準委任契約か
４　成果物に対するベンダーの責任はどのように定めるべきか
５　業務内容はどのように定めるべきか
６　委託料はどのように定めるべきか
７　契約変更のルールについてどのように定めるべきか
８　ユーザーが提供するデータについて何を定めるべきか
９　成果物の知的財産権の取扱いや利用条件をどうするか
１０　契約条項について困ったときは
第３章　プロジェクトマネジメント義務
１　プロジェクトマネジメント義務とは
２　ＡＩの開発の進め方
３　ＡＩの開発におけるプロジェクトマネジメント義務
４　プロジェクトマネジメント義務を主張されたら
第４章　おわりに

第１章　はじめに

第１回のコラムでは、ＡＩ開発プロジェクトの企画段階に関する法律問題を取り上げました。具体的には、ＡＩの企画段階におけるプロジェクトマネジメント義務や、個人情報の取扱い、知的財産をめぐるユーザーの交渉、秘密保持契約について取り上げました。

第２回のコラムでは、ＡＩを開発するために必要なＰｏＣに関する法律問題を取り上げました。具体的には、ＰｏＣにおけるプロジェクトマネジメント義務や、知的財産をめぐるユーザーの交渉について取り上げました。

今回は、いよいよ、ＡＩの開発をスタートする際に知っておかなければならない法律問題を取り上げます。このコラムでは、主に、ＡＩ開発契約を締結するために留意すべき点や、ＡＩ独自のプロジェクトマネジメント義務について取り上げます。ＡＩの開発においては、この他に、ＡＩ成果物の知的財産権や利用条件をめぐる交渉が大きな問題となりますが、これについては、ＡＩベンダーがユーザーと知的財産の交渉をうまく進めるためのノウハウを弁護士が解説のコラムにて詳しく取り上げています。

 

第２章　ＡＩ開発契約を締結する際の留意点

１　従来のシステム開発契約とは大きく違う

ＡＩ開発契約は、従来のシステム開発契約とは異なる点が多々あります。ですから、従来のシステム開発契約書を流用するようなことは、絶対に避けなければなりません。

第１に、ＡＩの開発には、ユーザーの積極的な貢献が不可欠であることが多い点です。これは、主に、成果物の利用条件や知的財産権の帰属をめぐる交渉の中で問題になります。

第２に、ＡＩの学習によってどのような成果が得られるかについて、ブラックボックスの面が多い点です。これは、主に、成果物に対するユーザーの責任や、ベンダーに対する報酬の決め方において問題になります。

第３に、ユーザーが提供するデータの質などによって、成果物に大きな影響が生じる点です。これは、ユーザーの提供するデータの質などが原因でプロジェクトに支障が生じた場合における責任の所在を決めるうえで問題になります。

２　ＡＩ開発契約書はどうやって用意するか

ＡＩ開発契約の条項を検討する際に参考になるのが、「ＡＩ・データの利用に関する契約ガイドライン－ＡＩ編－」（平成３０年６月経済産業省）の第７－６「開発段階のソフトウェア開発契約書（モデル契約書）」です。このガイドラインは、経済産業省のサイトにおいて公表されています。ここからは、このモデル契約書を活用する際に、あらかじめ意識しておきたいポイントを説明します。

３　請負契約か準委任契約か

契約条項を検討する出発点として、そもそも、ＡＩ開発契約は請負契約なのか、それとも、準委任契約なのかという視点を持つことが重要です。

請負契約では、受注者は、発注者から任された仕事を完成させることによって、はじめて義務を達成することができます。仕事の完成に向けてどれほど努力したとしても、仕事を完成させることができなければ、契約違反となってしまいます。

一方、準委任契約では、受託者は、「契約の本旨」に従って、「善良な管理者の注意」をもって委託を受けた業務をしていれば、結果的に目的を達成することができなくても、契約違反とはなりません。簡単にいえば、準委任契約における受託者の義務は、契約上求められるレベルできちんと任された業務をこなすことであって、その成果のいかんは問わないということです。

要するに、請負契約か準委任契約かというのは、成果物が予定どおりに完成しなかった場合に、ベンダーがどこまで責任を負うべきかという視点です。

従来のシステム開発契約のひな型は、請負契約であるという前提でできています。通常のシステムであれば、完成したシステムが仕様どおりであるかどうかは容易に判断できますし、ベンダーが手順どおり正確に仕事をこなせば仕様どおりのシステムが完成するはずだからです。

しかし、ＡＩ開発契約は、請負契約にはなじまない場合が多いです。なぜなら、ＡＩの開発は、「やってみないと分からない」ところがあるからです。たしかに、ＰｏＣによってある程度はＡＩの精度を予想することができます。ただ、ＰｏＣは、あくまでも「ＡＩの開発を進めてよいかどうか」を検証するものであって、ＡＩの精度を正確に予想するためのものではありません。ＰｏＣの意味については、第２回のコラムで取り上げました。また、たとえＰｏＣ段階において全データをもとに綿密な検証を行っても、実際の運用にＡＩがどこまでなじむかというのは、やってみなければ分かりません。つまり、ＡＩ開発契約の多くは、請負契約ではなく、準委任契約であることを前提にすべきです。

このことからも、ＡＩ開発契約書として従来のシステム開発契約書のひな型を流用してはならないことが分かります。

ＡＩ開発契約は準委任契約であるとすれば、契約条項は、(1)仕様どおりのＡＩの完成をベンダーが保証するものではなく、(2)仕様どおりのＡＩの完成に向けてベンダーが専門家として十分に努力することを本質とするものにしなければなりません。

４　成果物に対するベンダーの責任はどのように定めるべきか

※モデル契約書第７条・第２０条

ＡＩ開発契約において、ベンダーは、ＡＩの完成に向けて努力しなければならないものの、ＡＩを必ず完成させなければならない義務を負うわけではありません。ベンダーが負うのは、成果物完成義務ではなく、プロジェクトマネジメント義務です。モデル契約書に記載のとおり、ベンダーが成果物の仕様を保証するものではないことを明示することが理想的です。

ただ、モデル契約書のように「・・・保証しない」と明示すると、ユーザーから「責任逃れ」という誤解を受けるおそれもあります。ベンダーは、このような条項を入れる前提として、(1)ＡＩの特性から成果物の仕様を保証することはできないが、その代わりにベンダーがプロジェクトマネジメント義務を負っていること、(2)モデル契約書のひな型どおりの条項であることを、きちんと説明しておく必要があります。

それでもユーザーが納得しない場合には、ベンダーがプロジェクトマネジメント義務を負う旨の条項を追加する提案をすることが考えられます。どうしても「・・・保証しない」条項を削除せざるを得ない場合は、その代わりに準委任契約である旨を明示する方向性も考えられます。

５　業務内容はどのように定めるべきか

※モデル契約書第３条・【別紙】業務内容の詳細

業務内容として定めておくべき事項は、モデル契約書の別紙が参考になります。ただし、モデル契約書を活用するうえでは、次のような視点を持っておかなければなりません。

ベンダー側としては、予定どおりに進められるかどうかが未知数なＡＩのプロジェクトについて、具体的な業務プロセスやスケジュールを決めることには抵抗があります。一方で、ユーザー側としては、ベンダーの業務プロセスやスケジュールは具体的に決めておきたいと考えることが一般的です。そのため、業務内容の特定方法について、ユーザーとの間で意見の食い違いが生じる可能性があります。

ここからは、特にユーザーと対立が生じやすい具体例を取り上げます。

(1) ＡＩ成果物の具体的な仕様や性能について

まず、ＡＩ成果物の具体的な仕様や性能については、できる限り抽象的な記載にとどめて、特定しない方向で交渉すべきです。

仮に、ユーザーの意向により具体的な仕様や性能を特定し、かつ、その仕様や性能を保証しなければならないのであれば（そのような契約は極力避けるべきです）、ＰｏＣの結果として確実に保証しうる範囲に限定すべきです。

単に、ユーザーから具体的な仕様や性能を特定することを求められているのみであれば、あくまでも別紙記載の仕様や性能は「目標」であって、プロジェクトの状況に応じて変更を余儀なくされる場合があることを示しておくことが考えられます。この場合、ベンダーは、別紙記載の仕様や性能を備えたＡＩの完成に向けたプロジェクトマネジメント義務のみを負い、プロジェクトマネジメント義務違反に対する責任のみを負うことになると考えられます。

(2) スケジュールについて

スケジュールについては、少なくとも要件定義やデータ分析、設計などの業務プロセスの流れを特定することが必要です。特に、プロジェクトの進捗に応じて委託料を支払う旨を定める場合には、予定している業務プロセスについてできる限り詳細に定めておくことが必要です。ただし、各プロセスに必要な期間は、あくまでも目標であって、プロジェクトの状況に応じて変更を余儀なくされる場合があることを示しておくべきです。

ユーザーからは、成果物の完成までに要する期間を保証するように求められる可能性がありますが、ベンダーの立場からは、確実にプロジェクトを予定どおりに進行することができることを保証することはできません。このようなユーザーの求めに対しては、(1)プロジェクトマネジメント義務に基づいて目標スケジュールの達成に向けた努力をすることや、(2)スケジュールの変更が必要な場合には速やかにユーザーに報告することを伝えて、ユーザーの理解を得なければなりません。

６　委託料はどのように定めるべきか

※モデル契約書第４条・【別紙】業務内容の詳細

まず、ベンダーの立場からは、成果物の納入時に委託料を一括払するような契約条件は望ましくありません。プロジェクトが中途で頓挫した場合にユーザーが委託料の支払を拒絶したり、プロジェクトの進行中にユーザーが倒産して委託料を回収しえない状態に至ったりするリスクがあるからです。ＡＩ開発プロジェクトについては、一般に必要な期間も人件費も大きくなる傾向にあるうえに、プロジェクトがユーザーの協力に左右される面が大きいことから、このようなリスクを回避すべき必要があります。

そこで、ベンダーとしては、「スケジュールの進捗状況に応じて委託料を支払う時点を設定する方法」をユーザーに対して提案することが適切であると思われます。その前提として、業務内容としてスケジュールをある程度詳細に定めておく必要があります。

ユーザーから、「ＡＩが成果物として完成した程度に応じて委託料を支払う条件」にするように求められることが想定されます。しかし、ＡＩは、実際に運用を開始してみなければ仕様や性能がどの程度のレベルに達しているかが不明瞭なことが多く、成果物の完成の程度をプロジェクトの進行中や終了直後に判断することは困難です。ベンダーとしては、このような事情をユーザーに説明したうえで、「スケジュールの進捗状況に応じて委託料を支払う条件にせざるを得ない」ことに対する理解を求めるべきです。

なお、ベンダーの立場からは、人月や工数に応じた委託料が加算されるような契約条件が理想的ではあります。ただ、このような条件は、ユーザーにとって受け入れがたいことが一般的ですし、このような契約条件に固執すれば、ユーザーとの契約交渉が平行線になってしまう可能性が大きいものと思われます。

以上の理由から、委託料の設定については、「スケジュールの進捗状況に応じて委託料を支払う時点を設定する方法」がもっとも現実的であり、かつ、ベンダーにとってもリスクが小さいものと思われます。

７　契約変更のルールについてどのように定めるべきか

※モデル契約書第１０条

ＡＩの開発は、「やってみないと分からない」ところがある以上、途中で契約内容を変更しなければならない場合も想定しておかなければなりません。少なくとも、ベンダーがユーザーに対して契約内容の変更のための協議を求めた場合には、ユーザーがそれに応じなければならない義務を定めておくべきです。また、重要なプロジェクトにおいては、協議によって合意した内容を文書にすべきことを定めておくことが望ましいです。

なお、ベンダーとしては、ユーザーに対して変更提案に応じるべき義務まで定めたいと考えるかもしれませんが、このような義務まで定めるように求めることは、ユーザーからの反発につながるため、不適切ではありません。むしろ、ベンダーとしては、プロジェクトの進行中に当初の予定どおりにいかない問題が生じた場合には、ユーザーに対して「契約内容を変更しなければプロジェクトを進められないこと」を丁寧に説明して、理解を求めるべきです。

８　ユーザーが提供するデータについて何を定めるべきか

※モデル契約書第１２条・第１３条・【別紙】ユーザ提供データの利用条件

ベンダーの立場からは、基本的に、モデル契約書第１２条・第１３条を参考にユーザー提供データについての条項を定めることで問題はないものと考えられます。

ただし、第１３条第５項の廃棄証明書・削除証明書については、対応の可否やコストについて検討すべきです。

また、ユーザー提供データをベンダーが他のプロジェクトに転用することができるかどうかや、その範囲に問題については、次回のコラムにて詳しく取り上げる予定です。今回のコラムでは、説明を省略します。

なお、ユーザーからは、ベンダーに対してデータの適法性を保証すること（モデル契約書第１２条第３項）や、ユーザーが提供したデータの誤りやデータ提供の遅延によって生じた結果に対してベンダーが責任を負わないこと（モデル契約書第１２条第５項）を契約で定めないように求められることが考えられます。ただ、これらの条項を削除することは、ベンダーにとってリスクを負う結果になりますので、このような求めに応じるかどうかは慎重に検討すべきです。

９　成果物の知的財産権の取扱いや利用条件をどうするか

※モデル契約書第１６条から第１９条まで・【別紙】利用条件一覧表

成果物の知的財産権の取扱いや利用条件をめぐる法律問題については、ＡＩベンダーがユーザーと知的財産の交渉をうまく進めるためのノウハウを弁護士が解説のコラムにて詳しく取り上げています。

１０　契約条項について困ったときは

ＡＩ開発契約書は、その後のユーザーとのトラブルを防ぐために重要なものです。また、ＡＩ開発契約に向けた交渉においては、本章で取り上げた様々な視点を意識しながら、「どうすればユーザーからの理解を得られるか」を考えていく必要があります。

もっとも、プロジェクトの進行に向けた様々な準備に追われる中で、契約条項や交渉スタンスの検討に時間を割くことは容易ではありません。そこで、ＡＩ開発契約書の作成や交渉に際してのコンサルティングは、ＡＩ法務に詳しい弁護士に相談することをおすすめします。

第３章　プロジェクトマネジメント義務

１　プロジェクトマネジメント義務とは

前回までのコラムで説明したように、ベンダーは、ユーザーに対して、プロジェクトマネジメント義務を負っています。まずは、第２回のコラムで取り上げたスルガ銀行事件判決（東京高判平成２５年９月２６日）の内容を確認します。

判決によれば、ベンダーは、システムの開発過程で得た情報を集約・分析しながら専門的知見を用いてシステム構築を進め、ユーザーに必要な説明を行い、その了解を得ながら、必要な修正や調整などを行い、システムの完成に向けた作業を適切に行うべき義務を負います。そして、システムの開発過程で、当初想定していた開発費用、開発スコープ、開発期間のとおりにシステムの開発を進められない場合には、開発状況の分析、開発計画の変更の要否・内容、開発計画の中止の要否・影響などをユーザーに説明する義務を負います。

それでは、ＡＩの開発と従来のシステム開発との違いを踏まえながら、ＡＩの開発においてベンダーが負うべきプロジェクトマネジメント義務とは何かについて、考えていきたいと思います。

２　ＡＩの開発の進め方

ＡＩの開発においても、要件定義・設計・プログラミング・テストという工程をたどることは、通常のシステム開発と変わりません。ただ、ＡＩの開発の場合、とりわけ要件定義の段階において、通常のシステム開発とは明確な違いがあります。それは、要件定義の段階において、ユーザーから提供を受けたデータを詳細に分析しなければならない点です。

データの分析は、前回のコラムで取り上げたＰｏＣの段階においてもある程度実施します。しかし、ＰｏＣは、あくまでも「計画どおりにＡＩの開発を進めてよいのかどうか」を見極めるための試行的なものにすぎません。要件定義の段階においては、改めてデータを対象に詳細な分析を実施しなければなりません。

データの詳細な分析においては、ＡＩの精度を高めるためにどのような種別のデータを学習に用いることが最適か、学習の対象にするデータ量をどの程度に設定すべきか、再学習の頻度をどの程度に設定すべきか、異常値を処理・チェックする方法をどうするかといった、学習にかかわる様々な要件を検討しなければなりません。

３　ＡＩの開発におけるプロジェクトマネジメント義務

ＡＩの開発においては、特に、システムの開発過程で得た情報を集約・分析する義務や、ユーザーに必要な説明を行い、その了解を得ながら、必要な修正や調整を行う義務が、従来のシステム開発と比較して一層重視されるものと考えられます。

なぜなら、ＡＩの開発は、データを詳細に分析しなければ期待することのできるＡＩのレベルを予想することが困難であり、また、実際に学習をスタートして初めて問題点が明らかになるケースも多々あるからです。

「あらかじめベンダーが想定していたことが、実際にデータの詳細な分析をしてみると違っていた」「想定どおりであれば学習によって一定の精度が得られるはずであったが、実際に学習をしてみたらうまくいかなかった」ということは、ＡＩの開発においては避けられません。そのような事態が発生して、開発の期間やコストが当初の想定よりも大きくなってしまったとしても、ただちにその責任をベンダーに負わせることは不適切であると考えられます。ただ、そうであるからこそ、ベンダーが、データ分析に力を注いで必要な軌道修正をすることや、その際にユーザーから十分な理解を得られるように努力したりすることは、従来のシステム開発よりも一層重視されるのではないかと思われます。

ベンダーは、このような観点を踏まえて、次の点に対して特に留意すべきです。

(1) 専門的知見に基づいて正確なデータ分析を心がける

ベンダーは、労力を惜しまずに、ユーザーから提供を受けたできる限り多くのデータに対して分析を実施して、ＡＩの精度を高めるためにどのような種別のデータを学習に用いることが最適か、学習の対象にするデータ量をどの程度に設定すべきか、再学習の頻度をどの程度に設定すべきか、異常値を処理・チェックする方法をどうするかといったことを専門家の観点から検討すべきです。このような手間をかけずに要件定義を終わらせてしまった結果、開発プロジェクトが失敗してしまった場合、ユーザーからプロジェクトマネジメント義務違反を問われるおそれがあります。

(2) データ分析の結果を分かりやすくユーザーに説明する

データ分析の結果については、ユーザーが理解しやすいように資料化する工夫をしながら、設計の方向性についてユーザーと活発な意見交換ができるように努力すべきです。ベンダーが、このような労力を惜しんで、ユーザーへの説明や意見の共有の機会を十分に持つことなく開発を進めた結果、開発プロジェクトが失敗してしまった場合、ユーザーからプロジェクトマネジメント義務違反を問われるおそれがあります。

(3) 学習の過程で問題が明らかになった場合にはそのまま進めない

いざ本格的な学習をスタートした結果、想定していたとおりの成果が得られないことが明らかになった場合には、すぐにそのことをユーザーに伝えて、その後のプロジェクトの方針変更や、仕様の見直しなどを実施すべきです。このような対応を怠った結果、想定していたレベルのＡＩを納品することができなかった場合には、ユーザーからプロジェクトマネジメント義務違反を問われるおそれがあります。

必要であれば、開発期間の変更も求めるべきです。ベンダーとしては、開発期間の変更を求めることでユーザーからの苦情につながることをおそれて、できる限り当初の開発期間を遵守しようと考えるかもしれません。しかし、このような判断の結果、開発期間を守ることができなかった場合には、ユーザーからの責任追及を避けられません。ユーザーとしても、開発期間の延期を早く知ることで、ＡＩが納入されるまでの業務体制を検討するなど、業務への支障が生じないように準備を進めることができます。ユーザーの損害を最小限にとどめるためには、不利益な情報をできる限り早期に伝えることが重要です。

４　プロジェクトマネジメント義務を主張されたら

もし、ユーザーからプロジェクトマネジメント義務違反を主張されたら、(1)専門的知見に基づいて正確なデータ分析を心がけたか、(2)データ分析の結果を分かりやすくユーザーに説明して理解を得ながらプロジェクトを進めたか、(3)プロジェクトの進行上の問題が発生した時点で適切に対処したかという３つの視点を軸に、ベンダーに責任があったかどうかを検討することが重要です。そのうえで、ベンダーに非があるのであれば和解に向けて折り合う姿勢、ベンダーに非がないのであれば反論する姿勢で対応すべきです。

もし、以上のような判断プロセスを意識していないと、ベンダーにとって不利益な紛争を招いてしまったり、ユーザーから信頼を失ってしまったりします。とはいえ、実際のところ、ベンダーに非があるか・ないかを見極めるのは容易ではありません。ユーザーからプロジェクトマネジメント義務違反を主張された際には、まずは、ＡＩの法律問題に詳しい弁護士に相談すべきです。

第４章　おわりに

今回は、ＡＩ開発契約を締結するために留意すべき点や、ＡＩ独自のプロジェクトマネジメント義務について取り上げました。

次回は、このコラムで取り上げることのできなかった、成果物の知的財産権の取扱いや利用条件をめぐる交渉がテーマです。第１回のコラムでも説明しましたが、ＡＩの開発プロジェクトは、従来のシステム開発よりも「ベンダーとユーザーとの共同作業」の側面が大きいため、知的財産権の取扱いや利用条件についてお互いに「自分に有利な条件で進めたい」と考えることが一般的です。そのために、交渉をうまく進めることや、契約条件を適切に決めることを意識しておかなければ、ユーザーと対立関係に至って、プロジェクトが頓挫してしまったり、紛争に至ってしまったりするおそれがあります。ぜひご期待ください。

ＡＩベンダーがユーザーと知的財産の交渉をうまく進めるためのノウハウを弁護士が解説のコラムはこちらです。
 

関連サービス