第3回 スピード重視の開発と事業判断を両立したガイドライン - AI編

経済産業省は2018年6月15日に「AI・データの利用に関する契約ガイドライン」を公表しました。同ガイドラインは、民間事業者等がデータの利用等に関する契約や、AI技術を利用するソフトウェアの開発・利用に関する契約を締結する際の参考となるものです。

データやAI技術の分野では、契約実務の蓄積が乏しく、当事者間の認識・理解にギャップがあること等により、契約の締結が進んでいません。その課題を解決する方法として、同ガイドラインの活用が期待されています。ではこれから、より実務に沿ったガイドラインとしていくためには、どのような取り組みが求められるのでしょうか。

そこで、AI・データ契約ガイドラインの作成に関わった弁護士と、それを実際に利用される事業者の方々とで座談会を開催しました。今回は、AIの利活用が広がる中、同ガイドラインの「AI編」をテーマに語っていただきました。

揉めた「AI」の定義

AI・データ契約ガイドラインの「AI編」は、どういった視点から作られましたか。

松下弁護士
AIに関する契約で現場が苦労している理由は、ユーザとベンダとの間の技術的な知識・経験の違いによる認識の差によるところが大きいと思っています。両者に技術的事項に共通認識がないと、そもそも議論がかみ合わず、プロジェクトを前に進めることは難しいでしょう。そのため、議論の土台を作るため、技術論については「機械学習」¹ や「学習済みモデル」² といった基礎的な概念の定義等、一つ一つ非常に時間をかけて議論し確定していきました。

中林氏
機械学習で母集団から離れた外れ値が出てきた時に、予想外の動きをするのは当たり前なのですが、世間一般の常識ではないのかもしれません。そういう意味でも、「AI」と一括りに呼ぶのをそろそろ脱却する時かもしれないですね。

佐藤氏
最先端の技術は当初「AI」と呼ばれますが、その内容が明確になってくると、たとえば画像認識や文字認識といった別の言葉を与えられて、「AI」とは呼ばれなくなります。本ガイドラインは、その技術を定義したことが素晴らしいと思います。

松下弁護士
AIの定義 ³ は、検討会作業部会でもすごく揉めましたが、実用的な観点からは、帰納的なアプローチを採用して作られたソフトウェアとして捉えるのが良いのでは、というところに落ち着きました。また、対比として、従来型のソフトウェアを演繹的なアプローチを採用するものと整理できました ⁴。その結果、AIは作ってみるまで何ができるかわからない、技術的には、未知のデータについて、完成・性能保証が難しい等の相異点について、議論がクリアになったと思います。

とは言っても、当事者間のリスク分配を行うという契約の基本的な機能が変わるわけではありません。実務上、学習済みモデルだから性能保証はできないという発想に接することは少なくないですが、結局は当事者間の決めの問題であるため、技術論と契約論を直結させるとの発想はしないように心掛けました。

八木氏
従来はズレがあった「学習済みモデル」等の技術的な定義や、学習用データセットの生成段階、学習済みモデルの生成段階、利用段階というAIの実用化の過程について、この機会にきちんと定められた点も良かったです。

松下弁護士
そうですね。この実用化の過程の整理は個人的には重要だと考えています。法的に整理をする上で「学習済みモデル」と言った場合は、おそらくプログラムとして落とし込むことが適切な場面は少なくないと思います。一方、一般的な技術者は、「学習済みモデル」と聞いた時、学習の結果得られた関数・数値・行列等のパラメータを思い浮かべることが多いでしょう。すなわち、本ガイドラインでいう「学習済みパラメータ」 ⁵ を学習済みモデルと呼ぶのが、実態に近いところもありますので、きちんと定義をしないと議論すらままならないであろうとの問題意識は強くありました。

八木氏
ガイドラインの概念図は良くできていますよね。勿論、厳密に考えれば、ズレが出てくる場面はあるでしょうし、完璧ではないと思いますが、定義を調整すれば、多くのケースに当てはめることができますね。

松下弁護士
このガイドラインは、機械学習の手法として、ディープラーニング ⁶ を典型例と想定しているものの、限定していません。あくまでも対象は、統計的な機械学習ですので、たとえば、学習用データセット ⁷ の定義や、パラメータの定義を調整すれば、教師なし学習 ⁸ にも流用できると思います。

佐藤氏
AIはまさに最先端で、基本的な概念すら揺らぐ分野です。そのガイドラインを作って技術解説をするのは、ものすごく勇気の要ることですよね。

スピード重視の探索的段階型アプローチと性能保証

「AI編」では開発の進め方についても取り上げられていますよね。

松下弁護士
そうですね。AIの開発については、契約以前に、開発の進め方についても、プラクティスが確立しておらず、困っているとの声もあがっており、考え方のフレームワークの整理が必要であろうという問題意識がありました。そこで技術的な特性を前提に提案しているのが、「探索的段階型」の開発アプローチです。

尾脇氏
こういう難しい概念を明文化しようという姿勢はたいへん素晴らしいと思います。ただ、性能保証の責任のあり方について、何らかの方向性が示されるところまではいかず、結局のところ「性能保証が難しい」という指摘に落ち着いているように見えます。

松下弁護士
性能保証は、最後まで書くか、最も議論があったポイントの1つです。統計的な機械学習を用いる以上、原理的に性能保証が難しい場面があると考えています。ただし、技術的な性質論と、リスクの分配は別の問題であるため、当事者間で合意できるのであれば、性能保証に問題があるわけではありません。
たとえば、事情は、既存のソフトウェアでも変わりはなく、実環境によって性能は左右されるので、100％保証できるわけではありません。その保証の限界は、当事者が決めた性能評価条件で決まってくるわけで、AIに関してもまったく同じことがいえます。結局、ユーザがどういう条件であれば、十分な性能が発揮されていると評価するか、に帰着せざるを得ません。

ただし、性能評価条件の設定には機械学習特有の難しさも残ります。たとえば、評価条件を設定しても、それに対する過学習があれば、評価の指標としては必ずしても実用的ではない、ということになりそうです。実務的には、ユーザ自らが、満足できると考える性能評価条件を決めざるを得ないでしょうが、コストもかかりますし、経験も必要です。このように、ビジネス上、本当に性能保証が必要かは個別具体的に検討せざるを得ません。そのため、これ以上、ガイドラインとしては踏み込み難いところがあります。

尾城弁護士
技術的に変化が激しい分野ですし、ガイドラインとして踏み込んだ議論がしにくいというのは、理解できます。ただ、今までの因果関係論でも、条件関係が複雑な中で判断をしている例もありますし、そういったものを参考にしながら、責任分配のルールを明確化していくことはあり得るのではないでしょうか。いずれにしても、ケースごとに性能保証の方法を徐々に確立していくという方法論になるのだろうと思います。

中林氏
帰納的なアプローチだと、契約時に性能保証をするのは難しそうです。私は、利用シーンにもよりますが性能保証は要らない代わりに、スピードをもってアウトプットが出せれば良いと思っています。

松下弁護士
スピードはかなり重要ですよね。今回ガイドラインで提案した「探索的段階型」というアプローチも、まさにスピードを重視した、学習済みモデルの開発の考え方です。特徴としては、開発プロセスを多段階に分け、かつ、全体を管理する基本契約を締結しない点にあります。ただし、具体的事案によっては、基本契約を締結して当事者間の権利義務を開発初期にしっかりと確定させることが重要な場合もあると思いますので、この点を否定するものではありません。

探索的段階型アプローチについて、事業者側からの意見があれば教えてください。

尾脇氏
システムを作っていくという実務的な作業量としては「開発段階」が中心となるので、そこでの契約が大事だと思います。一方、その準備段階に当たる「アセスメント段階」と「PoC ⁹ 段階」は、ビジネスモデルを確立するプロセスという意味では非常に重要です。ただ、先の性能保証の議論もそうですが、契約という点では、この段階でははっきりと約束できることがまだあまりないでしょうから、「アセスメント段階」と「PoC段階」を細かく分ける必要まではないように思うのですが。

佐藤氏
我々は逆に「アセスメント段階」と「PoC 段階」に多く取り組んでおり、「開発段階」はそれほど重視していません。「実務にこの手法が使えるのか？」という、まさにビジネスモデルの発想部分を非常に重視しています。

中林氏
すべてのフェーズに関与し、費用がどのくらいかかるかを考えている身からすると、「開発段階」ではなく、やはり「アセスメント段階」のウエイトが大きいと感じています。「PoC 段階」で3、4つ並行して走らせ、そこから成功しそうなものをブラッシュアップし、モデルが固まれば、「開発段階」においてSIerなら誰でも実装できるはずだからです。

八木氏
探索的段階型の議論は、いかにスピード感と両立できるかに尽きると思います。「アセスメント段階」では性能保証は当然できませんが、「PoC段階」を経て、次の開発のアクションまで行けば、元の性能指標があるわけです。ただ、SIerの観点から言うと、エンドユーザとビジネスをする時に、段階ごとに契約を分けるプロセスは、なかなか難しい。だから我々もエンドユーザに対して、「この段階では性能保証できません。見える化するために、スピード重視でやるためのものです」と説明するしかありませんが、自分で予算をとれと言われる立場だったら、きついと思います。

松下弁護士
性能保証や評価条件については、難しいところがありますが、本ガイドラインでは、探索的段階型の開発に沿ったモデル契約書も提示しているので、より開発のプロセスはイメージしやすくなったのではないかと思います。

八木氏
予算化と事業化とスピード感、この3つのバランスを、このガイドラインでどうやって担保するのかというところについては、うまくいったユースケースをどんどん増やしていく必要がありますね。

法務担当者に求められる事業判断へのコミット

AI開発において、法務担当者はどのように関わっていけばよいのでしょうか。

中林氏
これまで、ソフトウェア分野では、ウォーターフォールで狙い撃ちするように開発をしてきました。だんだんとアジャイル型の開発へ移行した理由は、その方が勝てるからで、別にわざわざAIを使わなくても良いわけです。

松下弁護士
昨今の風潮だと、AIなら何でもできると誤解されているところがありますが、AIというマジックワードに惑わされることなく、冷静な事業判断が必要ですよね。AIはあくまでも事業上の目的を達成するためのツールにすぎません。本ガイドラインは、AIの開発と利用の促進を目的としているものの、学習済みモデルの開発や利用契約の締結それ自体を目的とはしていません。AI技術を用いることによるリスクを正確に把握した上で、AIを利用しない、ということも当然にあり得ますし、むしろ健全です。

中林氏
そうですよね。AIを使ってできないことができるようになる、もしくは今まで以上にできるようになる、だから使ってみようかという話が出るわけです。どうなるかわからないけれども、利益が出るはずだから、リスクをとってやろうと言うかどうかだと思います。最終的には、経営のジャッジしかない気がします。

松下弁護士
結局、どこまでリスクテイクしていくかという話にならざるを得ません。事業判断が非常に重要になりますから、法務や知財担当者にも、リスクの所在の指摘に留まらず、今まで以上に、より事業にコミットした判断をしていくことが求められると考えられます。その意味でAIの開発は、法務部門の領域拡大の側面もありますよね。

AIは職種にこだわらずに勉強すべき領域

今後「AI編」を活用していくために、現場ではどんな取り組みをしていけばよいでしょうか。

松下弁護士
初めてのガイドラインなので、まず骨格を作らないといけないというところがあり、いったん開発にフォーカスを当てて作成しました。ただ、付加価値のつけ方はビジネスごとにどうしても違いが出てきます。現段階ですべての論点を落とし込むことはやはり難しく、逆に変に落とし込みをしてしまうことで、ビジネスモデルが固定化しても困ります。そういう背景もあって、かなり簡略な形でとどめているところはありますね。
本ガイドラインの反省点としては、内容がやや難しいのではないかという気がしているところです。ソフトウェア開発のリテラシーがある人が読んだらわかるものの、今までソフトウェア開発をあまり取り扱ってこられなかった法務や知財担当者がこれをいきなり読んで、本当に使いこなせるのかと言うとなかなか難しいかもしれません。

尾城弁護士
私も普及が課題だと思います。ガイドラインという形で示す必要があったことから、やむを得ないところではありましたが、合計で300頁を超えるものとなり、読み通すのは難しいというご意見をいただくこともあります。ここが要点だと説明をしていく作業が必要でしょう。

中林氏
事業会社の法務部門では技術的にも理解しづらい部分も多いと思いますので、このあたりの知識を理解している人たちも巻き込んで、新たに一緒に契約書を作っていきたいです。

八木氏
中身が良いかどうかの議論も大事ですが、初めてのガイドラインで、まして「AI」の名がついて、読んだ瞬間に心が折れるものを作ったらだめだと思うんです。社内で勉強会を開いたところ、営業担当者でも普通に読めていました。今度は、与えられた我々がどう育てていくかの議論に終始して良いのかなと考えています。
その一環としてJDLAでは、「G検定（ジェネラリスト検定）」というITのリテラシーを高める活動をしています。当社では約450名が受けて、営業担当者を含めて約200名が資格を取得しました。職種にかかわらず、こうやって勉強していく必要があると思いますね。

松下弁護士
本ガイドラインは「AI編」「データ編」ともに、あくまで基本形で、スタートラインに過ぎません。両編を繋ぎ込み、いかにビジネスに落とし込んでいくのか。そこは使用の際の課題になります。たとえば、本ガイドラインでは、モジュールとしての学習済みモデルの開発を取り扱っていますが、システムに組み込む場合には、マルチベンダの問題が生じると思います。
ガイドラインについては、基本的な概念は変わらないにしても、技術が発達するにつれて、陳腐化する部分や、むしろ、こう考えたほうが良いのではないかという点もいろいろと出てくると予測しています。作成した側としても、何らかの形でアップデートに関与していきたいですね。

尾城弁護士
「データ編」もアップデート作業は必要だと考えています。また、データ契約については、産業分野別のガイドラインを作ろうという動きも進んでおり ¹⁰、本ガイドラインがパイオニア的な存在として、そのようなガイドラインのモデルとしての役割を果たせたら良いですね。行政だけではなく、民間レベルでも自主的なガイドラインを含めた議論が活発化してほしいと願っていますし、そういった動きに寄与していければと思います。

（取材・文・編集・写真撮影：村上 未萌、取材・構成：BUSINESS LAWYERS編集部）