1.事務所について

Q.依頼するのに、紹介者は必要ですか?
IT紛争/IT法務に十分対応できる弁護士へのアクセスは、まだまだ限られているのが実情です。そのため、当事務所では、IT関連の案件については紹介がなくても受任させて頂いています。ただ、事案の内容その他によっては、お引き受けできない場合もありますので、ご了承下さい。
Q.当社はシステムユーザ企業なのですが、受任してもらえますか?
当事務所は、依頼者を限定していませんので、もちろんお受けできます。ユーザ企業の場合、ベンダ企業に比べてITの内容に踏み込んだ交渉力に欠ける場合があり、ご依頼頂くメリットはより大きいものと考えています。実際、ユーザ企業様から、より多くの依頼を頂いています。
Q.当社はシステムベンダ企業なのですが、受任してもらえますか?
当事務所は、依頼者を限定していませんので、もちろんお受けできます。ベンダ企業の場合、自社内にトラブル解決の仕組みや経験があるために、かえって弁護士に相談するタイミングが遅れ、解決の糸口を逃してしまう場合がありますので、早めのご相談をお勧めしています。
Q.依頼することのできない案件はありますか?
当事務所の側からお断りすることは通常はありませんが、利益相反に当たるケース(例えば、紛争の相手方から既に相談を受けている場合)など、法令上お受けすることができない場合があります。また、特殊な知見を要する案件や、受任業務が集中している時期の案件については、やむを得ずお受けできないことがあります。
Q.料金はどのくらいですか?
所定の報酬規程によりますが、大雑把に言えば、訴訟や調停の場合は、経済的利益に応じた着手金(事件への着手時に必要となる費用)と報酬金(事件の結果による成功報酬)の形、それ以外の場合は、タイムチャージ(目安時間を設けておくこともできます)を基本としています。実際の金額は、事案の類型や難易度等によっても変わってきますので、まずはお問い合わせ下さい。

2.取扱い業務について

Q.相談だけでも良いのですか?
もちろん、相談だけでも構いません。むしろ、トラブルが初期のうちであれば、1~2回の相談だけで解決の目途がつく場合も少なくありません。何か問題が生じたら、早めに相談においで頂くことをお勧め致します。また、相談した結果によって、本格的に依頼するかどうかを判断して頂くこともできます。相談料は、初回に限り、割安のチャージレートを設定しています。
Q. いま抱えている事案は、「取扱業務」に載っているメニューにはピッタリ当てはまらないように思うのですが?
「取扱業務」のメニューは、どのようなものか分かりにくいと言われる弁護士のサービスを、説明のために類型化したものですが、実際の紛争解決や紛争防止は、一件一件が「カスタムメイド」のサービスと考えています。当事務所では他にも、IT紛争/IT法務の全般に対応していますので、事案の内容を良く伺ったうえで、最善の解決に向かえるよう提案させて頂きます。
Q.通常の契約書類のチェックのようなこともお願いできますか?
契約書をはじめ、RFPや個人情報保護規程、プライバシーポリシーなどの文書のチェックや作成も行っています。IT系の契約に特化した、契約書のひな形も用意してありますので、短期間でご要望にお応えすることができます。また、継続的なご依頼がある場合は、顧問契約をさせて頂くこともできます。
Q.スポットで依頼するのと顧問契約するのとでは、どういう違いがありますか?
どちらでも案件の進め方そのものに違いはありませんが、顧問契約をいただいている場合は料金に割引があるほか、一般の案件より優先して対応に当たります。また、顧問契約には、継続的な関係の中で組織や業務の状況が分かるほか、トラブル等に至る経緯も把握しやすくなるため、電話やメール一つですぐに初動に入れるというメリットもあります。

3.紛争/トラブル時の対応について

Q.裁判所から訴状が届きましたが、どう対応すればよいのでしょうか?
相手方から訴訟を提起されており、訴訟そのものを回避することはできません。対応せずに放置してしまうと、いわゆる「欠席判決」となり、相手方の言い分が全て認められてしまいますので、注意が必要です。特に、提訴された直後は、呼出状で指定されている第一回口頭弁論期日までに一定の対応を取る必要があり、迅速な対応が求められます。訴訟対応は、本人自らが行うことも可能ですが、法人の場合は代表者か支配人に限られますので、弁護士を代理人に選任するのが通常です。
Q.訴訟をする場合の段取りはどうなりますか?
以下、原告側(訴える側)に立った場合の、中規模のIT訴訟のイメージです。
・ヒアリングや資料の収集・整理と訴状の作成(1か月少々)
・第1回口頭弁論期日(提訴後1か月少々)
・その後の期日(1か月~1か月半に1回程度)
・証人尋問や検証などの証拠調べ
・証拠調べと前後して和解期日
・判決言渡し(最後の期日から2か月程度)
判決まで行くとすると、少なくとも数回以上の期日を重ねますので、1年半から2年、場合によってはそれ以上かかることもあります。その間、証拠調べや和解を除けば、期日に出席頂く必要はありませんが、文書の確認や証拠の調査などをお願いすることになります。ご依頼頂いた場合は、タイムチャートを用いた詳しい説明を差し上げています。
Q.トラブルの相手方から内容証明郵便が届きましたが、どう対応すればよいのでしょうか?
まずは書面に書かれている相手方の主張を十分に理解することです。そして、事実関係の整理、関連するエビデンスの収集、関係者からの聞き取りなどを行ったうえ、相手方の主張の当否を評価し、争っていくか、融和の方向でいくかなど、対応方針を定めます。内容証明郵便が用いられるのは、本来は通知内容(例えば、契約解除の意思を示したこと)を証拠化するためですが、トラブルのレベルが一段階上がったこと、(書面の名義によらず)相手方に弁護士が関与していることを示している場合も多く、慎重な対応が望まれます。
Q.できれば「裁判沙汰」にはしたくないのですが、可能でしょうか?
IT関係の紛争は、訴訟になってしまうと、費用・期間・労力の点で負担も大きく、たとえ勝訴したとしても十分な救済にはならない面があります。そのため、交渉その他での解決や立て直し、あるいは未然防止を指向することが賢明で、当事務所でも、そうした意識で取り組んでいます。もっとも、対立が厳しい状況で訴訟の選択肢を初めから除外してしまうと、そのこと自体が交渉力を下げてしまうことがありますので、状況に応じた解決方法を選択することが必要です。

4.その他

Q.まだ話し合いの最中で決裂したわけではないのですが、弁護士に依頼する意味はありますか?
むしろ、まだ交渉の余地がある早期に相談頂く方が、選択肢が多く効果も上がります。弁護士が前面に出ると対立感が強くなり過ぎるという場合は、「IT顧問」として話し合いに同席したり、バックヤードから助言したりといったこともお勧めしています。
Q.既に顧問弁護士に頼んでいるのですが、重ねて依頼するメリットはありますか?
IT紛争には、考慮しなければならないITの専門的論点が多々あるため、通常のように顧問弁護士に「お任せ」するだけでは難しい場合があります。そのような場合、セカンドオピニオンの形でのサポートが有効と考えています。関与の内容・程度については、柔軟に対応させて頂きます。
Q.地方なのですが支障はないでしょうか?
当事務所は東京所在ですが、地方からのご依頼も多く頂いています。紛争解決にはコミュニケーションが重要ですので、できるだけ直接の面談をお願いしていますが、それほど複雑でない相談対応や契約書類のチェック等であれば、電話やメールのみでの対応も可能です。こちらからの地方出張が必要な場合は、旅費、日当が別途かかります。
Q.弁護士に依頼するのは初めてなので、どうすれば良いのか全く分からないのですが?
取扱業務」に掲載されている紛争事例をご覧になったうえで、早めに法律相談をお受け頂くことをお勧め致します。トラブルの状況を伺ったうえ、法的アドバイスはもちろんのこと、相手方との交渉の可能性、提訴した(された)場合の見込み、今後の進行のバリエーション、必要となる費用まで、詳しくまた分かりやすく説明致します。
Q.IT訴訟なら必ず勝てますか?
残念ですが、必ず勝つことはできません。しかし、より良い結果に向けて最大限の努力を致します。また、勝ち負け以外にも、将来の紛争の未然防止やリスク対策など、何かが残るような取組みを心がけています。

 契約は、契約の申込みとこれに対する承諾によって成立します。保証など一部の類型の契約を除けば、申込みや承諾は口頭でも構いません。
 逆に言えば、契約書がなくても契約は成立するということですが、契約の成否や内容についてのトラブルを避けるために、契約書は必ず取り交わすべきです。万一訴訟となった場合は、重要な証拠となります。
 契約が成立すると、契約当事者(例えば、買手であるユーザと売手であるベンダ)は、契約の内容どおりの権利を取得し、義務を負うことになります。契約に基づく義務は任意に履行するのが基本であり、多少のトラブルが生じても、多くは話し合いで解決されるのが通常です。
 それでも、関係がこじれてしまい、一方が完全に履行を拒むといった事態に陥ることもあります。このような場面でこそ契約の効力が期待されるわけですが、そのままでは契約に強制力はありません。訴訟を提起し、債務名義となる勝訴判決を得て初めて、強制執行することができるようになります。

契約と契約書 TOPICS (6)

契約条項と法律上のデフォルト

 契約書に条項が記載されていれば、法令に違反しない限りはその内容が有効となりますが、記載のない事項については、商法や民法に定められている法律上のデフォルトで補充されます。その意味で、契約書上の各条項は、法律上のデフォルトに対する特約という位置付けとなります。対象となる取引の性質に応じた条項を記載しておくことが望ましいですが、それらの記載がないからといって直ちに問題を生ずるわけではありません。
 他方で、契約の目的物や代金などについては、当然のことながら、法律上のデフフォルトは定められていません。そのため、契約書上の記載が不十分であると、契約内容が不明確となるばかりでなく、それ自体がトラブルの種となります。「営業システム一式」といった契約は、絶対に避けなければなりません。

基本契約書と個別契約書

 同じ相手方と継続的に取引を行う場合、契約書を基本契約書と個別契約書に分けることがあります。基本契約書は、支払条件や解除事由など、全ての取引に共通の条項を規定し、取引の最初に1回だけ(又は取引の類型ごとに1回だけ)締結しておきます。個別契約書は、数量や納期など、取引ごとに異なる条項を規定し、取引の都度締結します。
 基本契約書を用いると、取引条件の標準化が図られるほか、取引の都度条件交渉を行う必要がなくなって省力化を図れるなどのメリットがあります。反面で、基本契約書の条件にはそぐわない取引でも、条件の見直しを行わないまま契約してしまいがちであり、注意が必要です。

注文書による契約

 基本契約書を用いる場合、個別契約書は比較的単純なものになることが多いため、その代わりに注文書を用いることがあります。基本契約書を用いない場合でも、契約そのものが単純な場合には注文書を用いることがあります。注文書(申込み)に対して注文請書(承諾)が発行されて契約成立となるのが本来ですが、承諾は電子メールのような簡易な方法で済まされることも少なくありません。
 いずれにしても、紙(注文書)1枚に納まるくらいに記載事項が少ないことが前提ですが、簡素を求めるあまり、必要な記載事項まで漏らしてしまうことがあります。特に、基本契約書を前提とした注文書の書式を基本契約書なしで用いる場合は、注意を要します。

見積書を引き継ぐ契約

 見積書は契約書ではありませんが、見積金額のほか、一定の契約条件(厳密に言えば見積条件)の記載があるのが通常です。そこで、契約条件については見積書の記載を当てにして、後は条件らしい条件が書かれてない注文書(と請書)だけで契約を締結する場合があります。このような契約方法も有効ではありますが、見積書に記載された条件が契約に引き継がれるのかどうかが不明確なケースが散見されます。少なくとも、注文書に、特定の見積書に記載された条件で注文する、などと明記しておく程度の考慮は必要です。
 提案書やRFPといった文書の場合も、記載されている条件を確実に契約に引き継ぐためには同様の考慮が必要です。

約款による契約

 IT系の契約では、特殊な締結方法が採られることがあります。例えば、媒体のラップを破って開封することで契約成立とするシュリンクラップ契約、ダウンロードやサービス開始のためのボタンをクリックすることで契約成立とするクリックオン契約などです。このような方法による契約も、開封やクリックにより契約が成立する旨と約款(契約条件)があらかじめ示されていれば、有効であると考えられています。
 債権法の改正により、こうした契約の約款の多くは、「定型約款」に該当することになると考えられます。その場合、締結時に現実に約款を示す必要がなくなる(約款による旨が示されていれば、請求があった場合に示せば足りる)一方で、不当条項や不意打ち条項が効力を否定されるといった規律に服することになります。

契約関係の解消

 いったん契約が成立した後は、契約当事者は契約に拘束されますので、たとえ契約から不利益を受ける場合であっても、契約を一方的に破棄することはできません。一方的に破棄してしまうと、そのこと自体が契約違反となり、損害賠償等の責任を問われます。契約の成立後に契約関係を解消することができるのは、当事者双方の合意で解約する場合のほか、契約や法律で定められている解除の要件を満たす場合(例えば、相手方に一定の契約違反がある場合)に限られます。
 もちろん、契約の解消や変更を求めて協議することはできますが、相手方が応じなければ叶いません。契約関係に入る前の段階で、慎重な判断が求められます。

 システム開発の委託契約は、多くの場合、請負契約となります。この場合、ベンダは(システム開発という)仕事の完成義務を負い、これに対してユーザは報酬の支払義務を負います。報酬の支払は、システムの納品と引換えでの後払が原則ですが、開発資金に充てるなどの目的で、約定により、前払や中間金が支払われる場合もあります。
 システム開発契約におけるトラブルとしては、まず、契約書などによる明確な合意がないまま、開発の先行着手がなされたものの、結局は折り合わずに開発中止となる、というケースが挙げられます。中止までの作業の費用負担やその前提としての契約の成否が問題となります。
 開発の進行段階で多く見られるトラブルは、ユーザからの要求が契約の範囲内にあるかどうかが問題となるケースです。範囲内であれば仮にどれほど工数がかかってもベンダはこれに応じなければなりませんが、範囲外であれユーザは別途の追加発注として費用や納期の変更を受け入れなければなりません。このような場合、契約書に添付された仕様書や、開発過程でのドキュメントが重要な判断資料となります。
 システム開発が途中で頓挫し、あるいは品質不良が判明する、というのが最も深刻なトラブルです。このような場合、ユーザはなお開発の続行を求めることもできますが、契約を解除した上で前払報酬の返還や損害賠償を請求することも選択肢となります。もっとも、こうした状況では逆にベンダから、責任原因はユーザ側にあるなどとして、未払報酬や損害賠償の請求がなされることも少なくありません。 

システム開発契約 TOPICS (6)

請負契約

 請負契約は、準委任契約と異なり、受託したベンダは仕事の完成(システム開発の業務を予定された工程まで終えること)が求められます。また、完成後も納品後1年間は、瑕疵(バグ等の欠陥)担保責任として、瑕疵の修補、損害賠償、状況によっては契約の解除を受ける責任を負います。
 なお、請負契約では、仕事の完成が必要であることから、原則として出来高報酬は認められません。もっとも、成果の一部だけでもユーザに利益となる場合は、出来高的な報酬が認められることがありますが(債権法改正で明文化されます)、成果の引継ぎが困難なシステム開発では、分割検収などの場合を除けばかなり例外的と考えられます。

多段階契約と再見積

 中小規模の開発の場合は、開発全体を一個の契約で行う「一括請負」の契約もありますが、比較的大規模の開発の場合は、工程ごとの見積と契約を繰り返す多段階契約とすることが推奨されています。
 多段階契約には、開発の進行を踏まえた精度の高い見積を行える利点がある反面で、開発総額や最終納期に歯止めがないこと、履行や責任の単位が細かく区切られること、開発が完了するまで契約が継続する法的な保証がないことなど、ユーザにとって注意が必要な点があります。

開発基本合意書

 多段階契約を採用する場合、主にユーザ側のリスクを軽減するために、開発総額や最終納期の目処を置くなど、開発プロジェクト全体に関する基本合意をしておくことがあります。法的な拘束力はあくまで個別契約によって生じるため、額面どおりの効力があるわけではありませんが、契約の解釈上一定の意味があると考えられています。
 多段階契約とする場合でも、最終的にはシステムの完成を目指している以上、開発プロジェクト全体の目標について内々の握りはしているものですが、開発基本合意書は、それを紳士協定から一歩進めたものと位置付けることができます。

発注内示書

 システム開発契約は高額の契約となることが多く、契約の交渉や締結も慎重となりますが、ユーザの都合で稼働時期が既に決まっており、正式の契約締結を待っていたのでは開発が間に合わないことがあります。そのような場合、やむを得ず、ベンダが開発に先行着手するに当たり、リスク軽減のためにユーザに求めるのが発注内示書です。
 ただ、正式契約の締結前であることから、結果的に開発が取り止めとなる不確実性は残っており、そのような場合、中止までの作業の費用精算を巡ってトラブルとなることが少なくありません。発注内示書は、契約書に代わる確実なものとまでは言えませんが、先行着手がユーザの求めによるものである(したがってベンダの営業行為ではない)ことを示す根拠となり得ます。

検収と報酬支払

 検収(検査合格)は法的な概念ではありませんが、契約上あるいは実務慣習上、支払の前提手続とされているもので、完成に代わる(あるいは完成を推認させる)報酬発生の条件と位置付けられます。
 検査によって完成を確認するという意味があるため、検収未了のうちは報酬が支払われないのが原則ですが、既にシステムが納品されているにもかかわらずユーザの都合で検査が行われないような場合は、報酬が認められることがあります。契約書にあらかじめ、納品後一定期間内に検査結果の通知がなければ検収とみなす「みなし検収」条項を入れておくこともあります。

プロジェクトマネジメント義務と協力義務

 システム開発プロジェクトの成功には、ベンダとユーザの協働が不可欠です。そのため、ベンダには所定の開発手法や作業工程の遵守、進捗管理や阻害要因への対処といったプロジェクトマネジメント義務が、ユーザには必要な資料や情報の提供、要件や仕様の決定といった協力義務が、裁判例でも認められています。
 これらはプロジェクトの確実な遂行のために認められているものですので、契約書に記載がある場合ばかりでなく、プロジェクト遂行の必要な場面場面で、ベンダとユーザのそれぞれの立場や役割にふさわしい義務が生じるものと考えられています。

 IT系の業務委託契約としては、システム開発やインフラの敷設といった請負類型のものも重要ですが、実数として(圧倒的に)多いのは、準委任類型のサービス系の契約です。多くの場合、期間に応じた報酬体系となっており、サービス業務が提供される限りはそれに応じた報酬の支払義務が発生します。
 サービス契約の場合、システム開発契約のように、合意が不明確なままに着手されることは通常はありません。ただ、新規開発のシステムの開発ベンダが稼働後に保守を担当する場合、稼働当初は不具合の対応に追われるなどして、開発契約から保守契約への切替の時期が不明確となるといったことはあります。
 サービス遂行中のトラブルの場合、その内容や程度によっては契約を解除することができますが、あくまで将来分を解除するにとどまり、遂行済みの部分を解除して報酬の返還を請求することはできないのが原則です。ただし、遂行結果に問題があり、それに起因して損害が生じている場合は、損害賠償請求することができます。

サービス契約 TOPICS (5)

準委任契約

 準委任契約は、請負契約と異なり、仕事の完成ではなく、業務の遂行に対して報酬が支払われます。また、受託者は、瑕疵担保(契約不適合)責任のような、業務の結果(あるいは品質)に対する責任は負いません。
 もっとも、債権法改正により、準委任であっても成果に対して報酬が支払われる類型が明文化されました。仕事の完成を要しない点ではあくまで準委任ですが、請負に接近するものと位置付けられます。要件定義や現状調査のような無定形の成果のある業務の委託に用いられることになると考えられます。

SLA(Service Level Agreement)

 あるサービスを提供する事業者(ベンダ)とその利用者(ユーザ)との間で、サービス契約に付随して結ばれるサービスレベルに関する合意をいいます。サービス契約におけるサービスレベルの保証水準を表したものと言え、多くの場合、この保障水準を達成できない場合の(段階的な)ペナルティが定められていることが特徴です。
 準委任のように品質に対する担保責任のない契約類型において、サービスの品質についての契約上の穴を補充する意味があります。逆に、請負のような担保責任のある契約類型のサービスに設定されることもありますが、この場合は品質基準を明確化することに意味があると言えます。

情報システムの運用・保守契約

 情報システムの開発契約と並んで、大半の企業が経験するIT契約の代表と言えます。基幹システムであれば、オンサイトで情報システム部員と協働することが多く、業務委託ではなく派遣労働に頼ることも少なくありません。
 通常は準委任契約ですが、保守の中にはプログラムの改修など、請負の性質を持つ業務も含まれるため、約定に注意を要します。また、業務に当たる要員数、日数、時間数にどのような制約を置くのか(置かないのか)、それらと報酬はどのように連動させるのか(させないのか)、運用・保守業務の内容をどのように範囲付けるのか(付けないのか)も、重要です。

SES(System Engineering Service)

 IT業界で古くからあるサービス業務で、多くの場合、企業やプロジェクトの現場に常駐して技術系のサービス業務に従事します。サービス内容としては、情報システムの開発や保守、コンサルティング、技術支援等、多岐に渡ります。
 一般に準委任形態の業務委託と位置付けられていますが、実態として、受託者が委託者から直接の指揮命令を受けているのではないかと疑われる場合もあります。そのような場合は、派遣法の厳しい規制を潜脱する、いわゆる偽装請負の問題となります。

SEO(Search Engine Optimization)

 検索エンジンの検索結果において、ウェブサイトがより多く露出されるようにするために行う最適化の取組みを言います。ターゲットとするキーワードの選定、当該キーワードでのランキングの上昇、クリック率の向上等を通して、サイトへの流入やサイト経由の売上といった目的達成を図るものです。
 SEOは自社でもできますが、一定の知見や手間を要することもあり、多くのベンダがサービスとして提供しています。本来は成果を保証しない準委任契約ですが、成果に目が行きがちなユーザとトラブルになるケースが少なくないため、成果と連動した報酬とすることもあります。

 IT関連の知的財産権は多岐に渡るため、ここでは主に情報システムに係る著作権を扱います。
 著作権は、著作者の下で原始的に発生します。業務委託の場合であれば、受託したベンダの側です。ただ、ユーザの側も、納入された著作物を単に使用するだけなら著作権に触れませんし、プログラムであれば自ら実行するために必要な限度での複製や翻案(ベースとなる著作物との同一性を維持しながら新たな著作物を作成すること)をすることができます。例えば、バックアップや通常の保守が該当します。
 もっとも、これだけでは大規模な改修等に不自由を来たすおそれがありますので、契約により別途、使用許諾がなされるのが通常です。さらに、ユーザとしては、著作権自体の譲渡を受けておく方が、第三者への権利譲渡やベンダの倒産等の際に有利です。もっとも、ベンダが再委託先を使っていた場合、著作権は再委託先に発生しますので、ユーザへの譲渡の前提として、まずベンダ自身が譲渡を受けておくことが必要です。
 狭義の著作権とは別に、公表、氏名表示、同一性保持についての著作者人格権があり、前者が譲渡等で解決されても、後者がベンダに残っていると著作物利用の妨げになります。ただ、著作者人格権は原著作者に一身専属の権利であり、譲渡ができないため、不行使の合意をすることが通常です。
 著作権を侵害した場合、民事責任のみならず、刑事責任が問われることもあります。民事責任については、差止めや損害賠償があり、しばしば立証が困難となる損害額についての推定規定が置かれています。

知的財産権 TOPICS (6)

法人等における職務著作

 企業その他の法人等で著作物が作成された場合、本来はその作成を行った担当者個人が著作者ということになります。しかし、もっぱら職務により作成された成果に対して法人等が権利を取得できない(別途譲渡等の手続を要する)のは不都合ですので、職務著作の制度があります。
 すなわち、法人等の発意に基づいてその従業者が職務上作成する著作物(プログラム以外では公表名義が法人等であることも必要)の著作権は、契約や勤務規則等に別段の定めがないのであれば、法人等に発生します。なお、特許権等と異なり、担当者個人への補償金は必要とされていません。

著作権の共有

 著作権は、複数の個人や法人の間で共有となることがあります。一つは、複数の著作者による共同著作の場合です。ただ、法人内での複数の担当者による場合は、要件を満たせば職務著作となりますので、共有とはなりません。もう一つは、著作権の持分譲渡の場合です。例えば、業務委託の成果物について、ベンダからユーザに著作権の持分50%が譲渡されれば、持分均等の共有となります。
 著作権が共有となる場合でも、持分の譲渡や利用については、他の共有者の同意・合意が必要です。プログラムや設計書の共有の場合、少なくとも利用(社内利用も含みます)については強すぎる制約ですので、あらかじめ合意しておくことが通常です。

著作権の権利制限

 著作権については、政策的にさまざまな権利制限が認められています。例えば、(「自炊代行」で問題となった)私的使用のための複製、他の著作物の写り込みが避けられないの場合の利用、許諾を受けるかどうかの検討の過程における利用、正当な範囲内で引用しての利用などが重要ですが、IT関連でも、上述のプログラムの利用のほか、電子計算機による情報検索や情報解析における利用などがあります。
 また、包括的な例外として規定された「著作物に表現された思想又は感情の享受を目的としない利用」は、米国法のフェアユースとは意味合いが異なりますが、AI開発におけるデータ利用など幅広い場面での適用が想定されます。

著作権と秘密保持

 著作権は、著作物が公開されていても保護されますので、秘密保持とは次元を異にします。とはいえ、著作物の秘密性を確保するための手段として、著作権が用いられることが多いことも事実です。例えば、企業が他社の著作物を複製して第三者に譲渡すれば、複製権の侵害となって民事・刑事の責任を負いますから、秘密保持に一役買うことになります。
 業務委託の成果物における著作権と秘密保持の関係は、やや複雑です。著作権の帰属は法律の原則や契約により決まりますが、秘密とすべき情報(不正競争防止法上の営業秘密やNDA上の秘密情報)は、双方当事者のものが混在しています。したがって、著作権を有していても、相手方の秘密情報にはなお配慮が必要ということになります。

情報システムと営業秘密

 情報システムは著作権で保護されるのが原則ですが、不正競争防止法上の営業秘密として保護されることもあります。ただ、そのためのハードルは高く、秘密管理性、有用性、非公知性が必要です。また、情報システムの場合、そこに含まれる業務上のノウハウ、処理方法やアルゴリズム、ソースコードのような具体的な記述、といった多様なものが営業秘密となり得、それに応じて侵害が認められる範囲や使用態様も異なってきます。
 営業秘密に対する侵害があると、民事のみならず刑事の責任も発生すること、民事の責任について差止めが認められ損害賠償額の推定規定があることも、著作権の場合と同様です。

ソフトウェア特許

 情報システムの保護として最も強力なのが、ソフトウェア特許です。ただしその分、発明であること、新規性があること、進歩性があること、とハードルは高くなります。例えば資産運用方法のように、ソフトウェアの対象自体が発明(自然法則を利用した技術)でなくとも、これをソフトウェアで実現したものは特許の対象となり得ます。
 同様に、いわゆるビジネスモデルもそれ自体では特許の対象とはなりませんが、これを情報システム化したものはソフトウェア特許となり得ます。その意味で、ビジネスモデル特許はソフトウェア特許の一種と言えます。

 インターネットは、通信そのもの、取引やサービス、プラットフォームなど、様々な(しばしば従前に見られなかった新たな)活動の舞台となっています。また、そこに関与するプレイヤーとしても、地域や国境を超えて広がる各種の事業者、そして消費者がいます。
 そのため、法律関係も複雑となり、各種の法令やガイドラインへの目配せが欠かせません。
 まず、事業規制関連として、不正競争防止法、独占禁止法、景品表示法、商標法などがあります。取扱分野によっては、著作権法など知財関連の法令も重要です。
 次に、対消費者関連として、特定商取引法、消費者契約法、電子消費者契約法などがあります。改正債権法の姿勢にも見られるように、消費者保護は一段と厳しくなってきています。
 また、消費者保護とも密接に関わる個人情報関連として、個人情報保護法のほか、EUのGDPRがあります。個人データを扱うインターネット関連の活動においては、侵害のリスクも高く、特段の配慮が必要です。

インターネット TOPICS (6)

申込画面の規制

 BtoCの電子契約では、契約の申込画面について消費者保護が図られています。まず、電子契約法では、消費者の申込内容等の意思を確認する措置が設けられていない場合は、操作ミスによる契約は原則として無効となります。確認措置としては、最終的な申込みとなることが明らかに認識できる画面を設定する、最終的な申込みの前に申込内容を表示して訂正の機会を与える画面を設定する、といったことが考えられます。このような確認措置を欠く場合、特定商取引法の「顧客の意に反して契約の申込みをさせようとする行為」として行政処分の対象となることもあります。
 これらの確認措置は、EC取引画面でのスタンダードとなっている感がありますが、単なるサイト内のフローなのではなく、法令の規制が背景にあることに注意が必要です。

規約と定型約款

 インターネット上のサービスなどでは、「サービス規約」といった形で取引関係を画一的に規律するのが通常です。このような規約は、個別の交渉や修正が予定されていないため、改正債権法の「定型約款」と扱わわれる可能性が高いと考えられます。
 定型約款となると、約款の事前開示や個別の合意がなくとも、一定の要件を満たせばその内容が契約に取り込まれることになりますが、不要条項や不意打ち条項は除外されます(これは対消費者の場合に限られません)。他方で、個別の同意なしに約款の改訂を行うことができるようになります。従前は、良くも悪くも合意によって処理されてきた(合意がなければならない/合意さえあればよい)契約関係に対する一大変化と言えます。

渉外取引

 海外の当事者との取引となる場合、準拠法(どの国の法令が適用されるか)に留意する必要があります。国内で提訴する(される)限り、日本法を準拠法とする合意をしておけば足りますが、消費者契約等では例外的に外国法の適用を受けることがあります。国外で提訴する(される)場合を考えると更に見通しが悪くなります。
 また、日本の事業者でもEU域内の個人に商品やサービスを提供する場合は、GDPR(EUの個人データ保護の規制)の域外適用を受ける可能性があります。たまたま欧州から注文が入ったというような場合はともかく、欧州をターゲットとするウェブページを構えているなどの場合は、あらかじめGDPR対策が必要となります。

クラウドサービス

 クラウドサービスには、SaaS、PaaS、IaaSといった類型がありますが、法的には、一定のサービスの委受託関係になると考えられます。そして、そのサービスの内容・性質により、準委任(一般のサービス)、寄託(データ保管等)、賃貸借(データセンター等)、あるいはそれらの複合として規律を受けることになります。
 クラウドは、データなどの重要な経営資源が外部(しばしば場所が不明な)に置かれることから、広い意味でのセキュリティが重要です。技術的な面でのセキュリティは大半のオンプレミスのシステムより上とも言えますが、そもそもの事業や事業者の継続性に不安があるケースもあること、また、通信事業者のような特別の法的規制を受けていないことから、サービス以前に事業者の選別も重要であると指摘されています。

通信事業者の責任

 掲示板やブログサービスの運営者といった通信事業者(特定電気通信役務提供者)は、自ら情報を発信する者ではありませんが、その管理者として、他者の権利を侵害する(名誉棄損や著作権侵害など)情報を放置すれば被害者から、実際には権利を侵害していない情報を誤って削除すれば発信者から、責任を追及されるおそれがあります。
 このように、通信事業者は、被害者救済と表現の自由の板挟みになってしまうことから、プロバイダ責任制限法により、それぞれ一定の免責が認められ、一定のバランス(幅)で行動する限り、責任を負わない仕組みが作られました。これと併せて、被害者が発信者に直接責任を追及する途を開くべく、通信事業者に対して発信者情報の開示を請求できるようになっています。

プラットフォーマーの責任

 プラットフォーマーとは、検索、モール、SNSなど、商品・サービスや情報が流通する基盤ないし環境を提供する事業者です。一般にプラットフォーマーは、自らは「場」の提供者にすぎず、「場」で活動する他者の行為については責任を負わないと宣言しているケースが殆どです。
 しかし、実際には、「場」のユーザー(事業者あるいは消費者)に対しても、第三者(権利侵害を受ける者など)に対しても、プラットフォームの性質や状況、権限に応じて一定の責任を負うことがあります。例えば、オークションサイトについて、欠陥のないシステムを提供する、注意喚起をする、といった責任が認められています。また、プラットフォーマーは、しばしば「場」における強い交渉力を有することから、優越的地位の濫用といった独占禁止法上の問題も指摘されています。

 ビッグデータ/AIは、実社会における利用が一気に進んできましたが、法制面での対応は遅れています。以前から、従来型のデータの利活用(データベース)やプログラムによる自動化(自動発注)は行われていたものの、前者については法的客体を有体物中心に考える、後者については法的主体を人に限る、という伝統的な枠組みのため、新技術と法律との距離を大きくしてきたと言えます。そのため、現状の法律の解釈や工夫により対応できる(せざるを得ない)部分もありますが、自動運転のように新たな立法が不可欠と考えられる分野も多くあります。
 また、技術の更なる進展により、これまで考えられていなかった法律問題や倫理問題にまで発展する可能性があります。

ビッグデータ/AI TOPICS (5)

データの権利関係

 データについての権利関係が問題になるのは、ビッグデータに限られません。しばしば、企業の営業・技術データ等について、「所有権」という言葉が使われることがありますが、データは情報の一種であり、排他的な管理支配ができない(許すべきでない)ため、所有権のような包括的な権利は認められません。
 しかし、データにもいくつかの法的保護が与えられます。まず、単なるデータの集積物ではなく、選択や体系的な構成に創作性が認められる場合、著作権法の「データベースの著作物」として保護される可能性があります。また、秘密管理性、有用性、非公知性が認められる場合は、不正競争防止法上の営業秘密として保護されます。さらに、相当の労力と費用が投下されたデータベースがデッドコピーされたような場合は、不法行為法における利益として保護されることがあります。

個人データの保護

 ビッグデータが個人情報を含む場合、個人情報保護法の対象となり、利用目的の範囲内での利用や第三者提供の制限等の規制を受けることになります。しかし、これではデータの利活用が大きく制限されます。そこで、個人情報を匿名化し、特定の個人を識別することができず、個人情報を復元することもできない「匿名加工情報」とすることで、比較的自由に利活用することができるようになっています。
 ただし、匿名化するに当たっては、個人情報保護委員会規則に従い、基準で認められた仮名化や項目削除等の方法により加工すること、安全管理措置を講ずること、等の条件を満たすことが必要です。また、このように匿名化したとしても、例えば流通先の第三者の下で他の情報と照合するなどして匿名化が破れてしまうことがあり得ます。そうした場合、法的責任は免れるとしても、利用企業の信用に傷をつけることになりかねませんので、注意が必要です。

AIの権利関係

 AIは通常、プログラムの形で実装されていますので、プログラムの著作物として著作権が認められる可能性があります。もちろん、プログラムでも技術合理性の裏返しとして、創作性や個性に欠けるものは著作物性が否定されることがありますが、AIと言えるほどの複雑性を備えたものであれば、要件をクリアする可能性が高いと言えます。同様に、要件を満たす限り、ソフトウェア特許の対象となる可能性があります。
 AIを構成する学習済みモデルは、それ自体としてはデータ(パラメータ)の集積にすぎないため、プログラムの著作物とはならないと考えられます。特許権との関係でも同様ですが、「電子計算機による処理の用に供する情報であつてプログラムに準ずるもの」として保護される可能性はあります。学習済みモデルについては、通常は上記のデータの権利関係と同様の形で保護を図っていくことになると思われます。

AIソフトウェアの開発契約

 AIの技術を利用したソフトウェアの開発(典型的には、機械学習により学習済みモデルを生成するもの)では、そもそもの開発対象やその動作原理が事前には明確になっていないことが多くあります。そのため、動作や性能が期待どおりでなかったり、その評価や検証すら困難な場合があります。他方で、開発の過程で中間ノウハウや関連技術についての知見などが、想定外に得られることも少なくありません。成果についての振幅が大きく、開発委託というよりは共同研究のような活動に近い面があります。
 そのため、開発の委託契約に当たっては、従来型のソフトウェア開発の場合とは異なる考慮が必要です。例えば、非ウォーターフォール型を前提にした準委任類型の契約、元データやノウハウの提供に関する役割分担、成果物の検証又は評価の方法及び基準、中間成果物、最終成果物及び想定外の成果物に関する権利帰属(及びそれらの報酬との関連づけ)、成果物の再利用の可否及び条件、といった事項が挙げられます。

AIによる行為・取引の責任

 従来型のソフトウェアの延長にとどまらず、ネットワーク上でのbotや取引システムに組み込まれたものなど、AIが人間と同様に(あるいは人間の補助として)実世界で活動する可能性が広がっており、その行為や取引の責任関係が問題になります。現在の法律では、AI自体(プログラムやデータ)、AIが化体されたモノは法的責任の主体にはなりませんので、当該AIの周辺にいる関係者(自然人か法人)に責任ないし効果が帰属することになります。
 通常は、そのAIの所有者又は管理者が、法的責任の主体となると考えられます。例えば、ネットワークに放ったAIがバグによりシステムを破壊した場合、その放った者が民事・刑事の責任を負い、自動発注システムが所定の商品を注文した場合は、それを設置し利用した者に注文の効果が帰属する(商品を受け取り、代金を支払う)という具合です。もっとも、製造物責任が問題となる場合や取引の相手方にAIを利用させる場合など、AIの開発者あるいは提供者の責任が問われる場合も考えられます。