Hatena::ブログ(Diary)

Footprints このページをアンテナに追加 RSSフィード

2018-06-19

SOFTICセミナー/AI・データの利用に関する契約ガイドラインの解説

| 16:28

AI・データ取引をめぐる法務・知財実務の展望と題して,6月15日に公表されたばかりの「AI・データの利用に関する契約ガイドライン」の解説に関するセミナーを聞いてきた。


はじめに

このガイドラインは,「データに関する取引の推進を目的とした契約ガイドライン」(2015年10月)*1と,「データの利用権限に関する契約ガイドライン ver1.0」(2017年5月)*2をさらに発展させたものであるが,大きく「データ編」「AI編」に分かれ,合わせて350頁もの大部なものである。


先月,パブコメに付されていて,内容はちらほらと見ていたが,全体を把握するのによいということで,セミナーに参加した。講師は,2017年より,このガイドラインの検討会の委員を務められたの岡田淳弁護士(MHM)。


特徴は,事業者からユースケース(具体例)を吸い上げて検討し,それをもとにガイドラインに落とし込まれているので,きちんと実務に根差した「使える」ガイドラインであると期待できる。


ガイドライン全体の構成は,以下の図のとおり(データ契約ガイドライン検討会第3回資料*3 より)。


f:id:redips:20180619162236p:image


データ編

http://www.meti.go.jp/press/2018/06/20180615001/20180615001-2.pdf


具体的な契約条項例が示されているのは「データ提供型」と「データ創出型」である。前者は,一方当事者がすでにもっているデータを他方当事者に提供するという場合のもので,ある意味,典型的な類型である*4。後者は,契約当事者が関与することで新たに創出されるデータの利用権限について定める類型である。共同研究開発契約的な色彩があるという印象だ。


なお,第3の類型として,「データ共用型(プラットフォーム型)」は検討はされているものの,具体的契約条項例の提示までは至っていない。


データそのものが知的財産権法で保護される局面は限られているし*5,所有権というものは観念できないが,利用権限の範囲・内容を定めるうえでは,オーナーシップ(事実上の地位/債権的な地位)を明確にし,そこを出発点に考えていくというのが有用だといえる。


具体的なモデル条項例についても解説があった。


データ提供型契約で一番問題となるのは,派生データの取り扱いだろう。生データの提供を受けて編集・加工・分析した結果を派生データと呼ぶとするならば(その定義・範囲も容易ではないが),通常は,受領者側は派生データについて何らの制約を受けたくないと思うだろうし,他方で,提供者側は一定の権利を留保しておきたい(グラントバック等)と考えるだろうから。


データ創出型契約では,そもそも論である発生データの利用権限の分配だろう。そして,その先の派生データについての利用権限については,前述の派生データと同様の問題が生じる。この点について,モデル条項では,個別のデータ・項目について両当事者それぞれの利用権限を表形式でまとめる案を提示されている(データ編120-123頁。下図は表形式のイメージ。)。


f:id:redips:20180619162239p:image



AI編

http://www.meti.go.jp/press/2018/06/20180615001/20180615001-3.pdf


AI編は,AIを「作る」までの過程についての契約にフォーカスがあてられている。しかし,AIを生成する段階についてまだ幅広い共通理解がなく,開発手法も画一化されていないことから,データ編よりもさらに基礎的なところから整理・分析するということが行われている(技術の解説に関しても一定のボリュームが割かれている。)。従来のソフトウェア開発とも論点が共通する部分もあるが,様々な違いがあることから,その違いを意識すると理解しやすいだろう。


モデル契約は「探索的段階型の開発手法に沿った契約」とされている。これは,従来のソフトウェア開発でよく行われたウォーターフォールモデルをベースとした多段階契約とは異なり,試行的・実験的な要素を有するAI開発の特性を生かしたものとなっている*6


従来のソフトウェア開発の場合,ユーザが仕様を提示し,ベンダがプログラムを開発する。これがAIを開発では,多くの場合,ユーザは仕様だけでなく学習用データを提供しているため,ユーザは,より一層,完成した学習済みモデルに対する権利への意識は強く生じると考えられる。また,単なるデータと違って,AIの成果物は知的財産権の保護対象になるものも多い。したがって,今までは割と「なあなあ」で過ごされていた成果物に関する権利帰属に関する規定は,交渉上重要な論点になると考えられる。


成果物の利用方法・態様を別紙にまとめるという案は,データ編とも似ているが,確かにこのほうがわかりやすい(AI編129頁)*7


f:id:redips:20180619162242p:image


また,従来のソフトウェア開発では,成果物であるソフトウェアは「正しい」振る舞いをすることが当然の前提で,正しくない動作をすれば,ベンダは瑕疵担保責任なり不完全履行の責任を問われることになる。他方で,AIの場合,「正解」がない,あるいは約束できないことが多いため,ベンダからは性能・結果に対する責任の緩和を求められるだろう。さらには,納入後にさらなる学習・発展をしていく場合についての責任の所在はより複雑になっていく。これを単純に「非保証・免責」と書けばベンダとしては安心かもしれないが,うまくバランスとっていくことは容易ではない。


おわりに

経産省が公表したモデル契約として実務に広く定着しているのは,2007年に公表された情報システム開発にかかるモデル契約であるが*8,2008年に増補版が出たものの,その後の改定は行われていない。このAI・データの利用に関する契約ガイドラインは,経産省の説明によれば,今後も継続的に改訂をしていきたいとのことであるが,実務の変化に合わせて拡充していくかどうかが広く実務に定着していくかの鍵になるように思われる*9

*1http://www.meti.go.jp/press/2015/10/20151006004/20151006004.html

*2http://www.meti.go.jp/press/2017/05/20170530003/20170530003.html

*3http://www.meti.go.jp/committee/kenkyukai/data_keiyaku/pdf/003_01_00.pdf

*4:拙著「ITビジネスにおける契約実務」第7章で取り上げた契約類型はこのパターンである。

*5:不正競争防止法の平成30年改正によって「限定提供データ」というものが創設されたが・・

*6:具体的には,アセスメントフェーズでの秘密保持契約,PoCフェーズでの検証契約,実装段階の開発委託契約

*7:モデル契約における「本件成果物」と「本件成果物等」は定義が異なる(当然後者が広い)ので注意。

*8http://www.meti.go.jp/policy/it_policy/keiyaku/index.html

*9:英語版の作成も予定されているとのことなので大いに期待したい。

2018-05-20

個人情報・パーソナルデータに関すること(29)第7回情報法制研究会シンポジウム

| 20:59

昨日(5/19),第7回シンポジウムを聴講してきた。


このシンポジウムは毎回とても有益で,テーマ選定もタイムリーだし,内容もレベルが高い。


過去のシンポジウム一覧は,こちらに載っているが,2015年3月から改正個人情報保護法の制定にあたっての論点解説や,政省令,ガイドラインの解説などなど。資料が公開されて,過去分もみられるところも素晴らしい。

https://www.dekyo.or.jp/kenkyukai/#symposium


今回のテーマもまた最近話題の「通信の秘密(ブロッキング)」と「GDPR」だった(最後のJISQ15001は予定があって聞くことができなかった)。

https://www.dekyo.or.jp/kenkyukai/symposium7.html


GDPR対応は,ほんの一部の専門家以外には手を出せない分野であるが,私のところにもちょこちょこと相談が来ているので,板倉さんの解説は非常に助かる。今後,GDPR対応をするにあたっては,この資料とビジネス法務の特集(2017年8月号)をとっかかりにするのが良いと思われる。


現在パブコメにかかっている「EU域内から十分性認定により移転を受けた個人データの取扱い編)(案)」についてはほとんど負えていなかったので,これも助かった。

http://search.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=240000050&Mode=0


よく知られているとおり,GDPRのもとで日本に個人データ移転を可能にするには,一定の制約条件をクリアする必要があるが,EUから十分性の認定を受けられた場合には,基本は国内法に従えば足りることになる。GDPRが完全適用される5月25日までには十分性認定を受けられないが,近いうちに受けられる見込みなので,十分性認定後の処理について定めたのが前記ガイドラインである。


一言でいえば,国内法に多少の上乗せ規制が設けられているのだが,例えば,「要配慮個人情報」(2条3項)に関して,国内法の定義に加えて

EU域内から十分性認定に基づき提供を受けた個人データに、GDPRにおいて特別な種類の個人データと定義されている性生活、性的指向又は労働組合に関する情報が含まれる場合には、個人情報取扱事業者は、当該情報について法第 2 条第 3 項における要配慮個人情報と同様に取り扱うこととする。

とされている。


これはすなわち,法の規制にガイドラインで上乗せの規制をすると言ってるので,理論的には微妙(というか,これを執行することは可能なのか)なのだけれども。


また,逆に我が国から海外への移転について定める法24条に関して,いわゆる「同等性認定」を認める基準について,委員会規則がひっそりと改正されている。こちらの規則は,5月9日に公布・施行されている。


法改正の動向,論点や実務上の悩ましい点などを短時間でキャッチアップするにはすばらしい機会だった。


それにしても,講師の板倉さんは,このシンポでほぼ毎回講師をされている。自分と同期の弁護士なのだけれども,同期で,ここまで特定分野の第一人者を独走している人はいないんじゃないか。

2018-03-04

不正競争防止法改正案について(データの保護)後編

| 22:35

前回の続き。前回は,「限定提供データ」の定義を紹介したが,後編は不正競争となる行為の範囲について。

(前回の記事)

http://d.hatena.ne.jp/redips/20180302/1519917779


限定提供データに関する不正競争行為は,営業秘密に関するもの(4号から9号。ただし10号に対応する規定はない。)と基本的にパラレルになっているので対比して紹介する。


不正取得・使用・開示(4号,11号)

まず,営業秘密に関する4号は,不正に取得する行為,それを使用する行為,開示する行為を不正競争と定めるが,これとほぼそのままパラレルになっている。

f:id:redips:20180304220956p:image


不正取得後の転得・使用・開示(5号,12号)

これも基本的には同様だが,営業秘密の場合,転得者が故意だけでなく,重過失の場合にも対象になっているのに対し,限定提供データの場合には重過失が除かれている。

f:id:redips:20180304220953p:image


善意転得後知情(6号,13号)

この類型は,善意で秘密を転得したが,その後,不正競争行為が介在したことを知った場合に等について定めているが,ここも営業秘密については,知情したことに限らず,重過失により知らないで使用等した行為が対象になっているのに対し,限定提供データの場合には,重過失が除かれている。

また,6号では「使用」も対象になっているが,限定提供データの場合(13号)には,後から不正行為があったとしても使用すること自体は許されている。

f:id:redips:20180304220949p:image


正当取得・図利加害目的使用・開示(7号,14号)

この類型は,情報を取得したことまでは正当行為だが,その後,不正な目的で使用したり開示することを対象とする。ただし,使用行為については限定提供データについてのみ,「その限定提供データの管理に係る任務に違反して行うものに限る。」という限定がついている。

f:id:redips:20180304220945p:image


正当取得・不正転得(8号,15号)

この類型は,7号,14号の行為後の転得者の行為を対象とするものである。ここでも,営業秘密では重過失も対象にしているのに対し,限定提供データの場合には故意のみが対象である。

f:id:redips:20180304220942p:image


取得後知情(9号,16号)

この類型は,9号は,営業秘密を取得した後に,その取得が不正開示行為であること若しくは不正開示行為が介在したことについて悪意・重過失で,その営業秘密を使用または開示する行為を対象とする。これに対し,限定提供データの場合には,重過失が除かれ,また「使用」も対象から除かれる。

f:id:redips:20180304220939p:image


10号

営業秘密の場合は,4号から9号までの行為によって生じた物の譲渡等を対象にしていたが(10号),限定提供データについてはそれに対応する規定はない。これは,物のほか,それによって学習させたAIの学習済みモデルなども対象外になることを意味する。


適用除外

詳細は割愛するが,19条1項8号,イ,ロで適用除外行為が定められている。



この法律による保護の実効性,意味については,また別途。。

2018-03-02

不正競争防止法改正案について(データの保護)前編

| 00:22

平成30年2月27日に,「不正競争防止法等の一部を改正する法律案」が閣議決定され,改正条文案などが公表された。

http://www.meti.go.jp/press/2017/02/20180227001/20180227001.html

不正競争防止法を改正して,データの不正取得行為等を「不正競争」に含めることで,ビッグデータを保護しようという動きがあり,この点については,当ブログでも取り上げたが,昨年7月から立ち上がった産業構造審議会 知的財産分科会 不正競争防止小委員会で検討されていた。今回の改正案は,今年の1月19日に公表された「検討中間報告」(以下「中間報告」という。)の内容を踏まえたものである。改正法の条文の解釈に当たってはこれを参照することは必須だろう。それにしても,異様なスピードでの改正である。


f:id:redips:20180302001731p:image


ビッグデータは,営業秘密としては,通常は秘密管理性・非公知性を満たさず,創作性の要件から著作物性も満たさないため,現行法では十分な保護を受けられないといわれていた。データの流通・利活用*1を促進するために悪質性の高い行為に規律を設けることとなったというのが改正の方針である。


まず,改正条文案を見てみる。


不正競争は,不正競争防止法2条1項各号に列挙されている。これの現行10号と11号の間に,一気に6つの類型を挿入している*2

2条1項11号

窃取、詐欺、強迫その他の不正の手段により限定提供データを取得する行為(以下「限定提供データ不正取得行為」という。)又は限定提供データ不正取得行為により取得した限定提供データを使用し、若しくは開示する行為


営業秘密不正取得行為等を表す現行4号も若干の表現が修正されているが,それとパラレルな規定であって,基本的には4号の「営業秘密」の部分が「限定提供データ」に変わっている点のみが異なる。


客体「限定提供データ」

では,保護の客体である「限定提供データ」とは何か。


営業秘密の定義(2条6項)の隣に7項が挿入され,「限定提供データ」が定義されることになった。


2条7項

この法律において「限定提供データ」とは、業として特定の者に提供する情報として電磁的方法(略)により相当量蓄積され、及び管理されている技術上又は営業上の情報(秘密として管理されているものを除く。)をいう。


要件としては,(A)「業として特定の者に提供する情報」であって,(B)「電磁的方法により相当量蓄積され」ていて,(C)「電磁的方法により管理され」ている,(D)「技術上又は営業上の情報」であるが,(E)「秘密として管理されているもの」は除かれる。


限定的な外部提供性

まず,(A)は,中間報告の「(ii)限定的な外部提供性」を具体化したものと思われる。中間報告によれば「データ提供者が,外部の者からの求めに応じて,特定の者に対し選択的に提供することを予定しているデータ」が対象だとされている。そうすると,完全に公開されているようなものは除かれ,条文で「提供する情報」(中間報告では「予定している」)とあるから,現にサービスとして提供していなくても,その予定があれば客体に含まれると考えられる。典型的には,有償で提供・販売しているデータなどが対象になろう。


相当量蓄積

今回の要件の中で一番問題になりそうなのは(B)「相当量蓄積され」ていることだと思われる。冒頭で述べた小委員会の資料を追っていくと,第1回(2017年7月開催)の資料7「行為規制の前提となるデータの要件に係る検討」*3の論点5「データ量に係る論点」では,

一定の技術的な管理を破ってデータを取得という行為を規制する観点から、取得したデータ量・割合の多寡に関わらず、規制すべきと考えられる。

と,データ量は要件に含めないとされ,その後の中間報告でもデータ量については特に言及されていなかったが,法文案で「相当量蓄積」という要件で限定されている。相当量っていう文言からは何らの基準も見出せず,何万件,何ギガバイトあるいはカバー率どれくらいなのか,というのは事案によるとしかいいようがなく,範囲を限定したのかもしれないが,予測可能性はかえって悪化してしまったような印象を受ける。


技術的管理性

検討段階では,電磁的アクセス制限手段(ID・パスワード管理,データの暗号化等)により管理されているものを対象にするということになっていたが,法文上では(C)のとおり,電磁的方法により管理されているという表現しかなく,アクセス制限手段を要しないような定め方になっている。ただし,改正法の概要の説明資料2頁には下記のように「ID・パスワード等の管理を施した上で提供されるデータ」とはっきり書いているが。


f:id:redips:20180302001728p:image


技術上又は営業上の情報

(D)の「技術上又は営業上の情報」は,現行不競法の営業秘密の定義の中でも出てくるものであるから,特に改正によって解釈が変わることはないだろう。この要件が実務上問題になることはあまりないと思われる。


営業秘密を除く

(E)の秘密として管理されているものは除く,という要件は,営業秘密の保護と重畳的に適用されることを避けるためだと思われる。秘密として管理されているものは,2条6項の営業秘密に該当するからそちらでどうぞ,ということか。


規制対象となる行為

ここは,営業秘密侵害行為との比較をしようかと思ったが(基本的にパラレルになっているが,細かい違いがある。),力尽きたのでまた。


なお,損害の推定規定(現行法5条)の対象には限定提供データに関する行為も含まれるようであるが,営業秘密と異なって,刑事罰はないようである。

*1:個人的にはこの「利活用」という言葉は使いたくない・・

*2:不正競争は,2条1項10号の2のように枝番をつける形式ではないから,毎度類型が増えるたびに番号がずれていく。現行14号,15号あたりは割とよく使うのだけれど,判例検索のときなど,使い勝手が悪い。

*3http://www.meti.go.jp/committee/sankoushin/chitekizaisan/fuseikyousou/pdf/001_07_00.pdf

2018-02-28

IoT時代におけるOSS利用と法的諸問題及び留意点

| 23:19

SOFTICが主催するセミナー「IoT時代におけるOSSの利用と法的諸問題及び留意点」に出席した。


http://www.softic.or.jp/seminar/180228/index.htm


ソフトウェア関連の法務を取り扱っていると,OSS問題は頻出である。しかし,少なくとも日本では裁判例などもないため,法的問題については答えがない課題が多いうえに,法務の立場からは「動的リンク」「ライブラリ」などと言われても,具体的にどういう状態なのかわからず,避けたくなる分野だといえるだろう。


OSSのさまざまな論点は,ずっと前から存在していたが,このセミナーの表題には「IoT時代における」とついていたことから,IoTになると何か固有の新しい問題が起きるのかな?と思って参加することにした。


しかし,内容的には,従来から挙げられていた論点の整理が中心で「IoT時代」固有のトピックについては特になかった。とはいえ,最近,ウェブアプリ,スマホアプリなどをはじめ,多種多様なOSSが大量にソフトウェアに混入しているという状況にあり,かつては利用に消極的だった企業も積極的に使うようになっているので,「IoT時代」かどうかは別としても関心が高まっているのは間違いない。だからこそ,満員御礼となってキャンセル待ちになったほどだ。


このセミナーでは,想定される事例を2つ掲げ,それぞれについて生じた紛争(OSSの不具合によって製品が発火した場合の責任,特許権侵害の警告等)に起きる論点についての解説が行われた。

(下記の図は,想定事例Iの図。上記リンクで公開されているものより抜粋)

f:id:redips:20180228225809p:image


以下はプログラムの抜粋。

2.「組込型OSS」の利用に関する法的諸問題、留意点[想定事例?]      

(1)ソースコード提供義務:OSSライセンスの法的性質、GPLの留意点等

(2)製造物責任:ソフトウェア及びプリンタの製造物責任、OSS利用の品質保証上の留意点等

(3)国際的な著作権侵害係争:OSSライセンス条件違反と著作権侵害、国際裁判管轄、準拠法

3.「SI開発」へのOSS利用に関する法的諸問題、留意点[想定事例?]      

(1)特許侵害訴訟:対応策等

(2)OSSライセンス違反:AGPLv3違反、Apache License2.0違反

(3)個人情報漏洩:損害賠償等

(4)再発防止と管理の改善等:OSSの採用基準、OSSチェックツールの利用、管理体制等

4.過去の係争事例


OSSに関して問題になりそうな論点がかなり幅広く網羅されている上に,個々の論点について丁寧に解説してあるため,4時間という尺がギリギリになってしまうほどの濃度だった。


セミナーでしか聞けない情報として貴重だなと思ったのは,OSSの管理体制,活用状況,社内ポリシーといった法律論以外の具体的な事例である。社内事例を紹介してくれた会社は,いずれも超大手企業であって,「まあ,ここまでやるかなあ」と感じる部分もあったが,実際にOSSを利用する中小のIT企業にとっては,これらの事例を参考にしながら自分たちでやれること,やるべきことを考えることができる材料にはなるので有意義だろう(時間の関係で詳細な説明が聞けなかったのは残念だが)。


国内では,OSSに関する提訴事例はない,という報告があったが,私自身,以前にOSSが関係した訴訟にかかわったことはある。詳しくは書けないが,ある機器の製作を委託し,ソフトウェア込みで納品されたところ,そこにコピーレフト型のOSSが組み込まれていたにも関わらず,ソースコードが開示されなかった(拒否された)という事案だった。委託者側は,ソースコードが開示されていない以上,その機器を販売・頒布できないため債務不履行(あるいは瑕疵)にあたるという主張をした。そのときは,納品されたソフトウェアが,ソースコードの提供義務を負うものであるということ,これに違反すると機器の販売ができないことなどを簡潔に説明するのに苦慮した記憶がある。