１．事務所について

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

２．取扱い業務について

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

３．紛争／トラブル時の対応について

Ｑ．裁判所から訴状が届きましたが、どう対応すればよいのでしょうか？
相手方から訴訟を提起されており、訴訟そのものを回避することはできません。対応せずに放置してしまうと、いわゆる「欠席判決」となり、相手方の言い分が全て認められてしまいますので、注意が必要です。特に、提訴された直後は、呼出状で指定されている第一回口頭弁論期日までに一定の対応を取る必要があり、迅速な対応が求められます。訴訟対応は、本人自らが行うことも可能ですが、法人の場合は代表者か支配人に限られますので、弁護士を代理人に選任するのが通常です。
Ｑ．訴訟をする場合の段取りはどうなりますか？

以下、原告側（訴える側）に立った場合の、中規模のＩＴ訴訟のイメージです。

  • ヒアリングや資料の収集・整理と訴状の作成（１か月少々）
  • 第１回口頭弁論期日（提訴後１か月少々）
  • その後の期日（１か月～１か月半に１回程度）
  • 証人尋問や検証などの証拠調べ
  • 証拠調べと前後して和解期日
  • 判決言渡し（最後の期日から２か月程度）

判決まで行くとすると、少なくとも数回以上の期日を重ねますので、１年半から２年、場合によってはそれ以上かかることもあります。その間、証拠調べや和解を除けば、期日に出席頂く必要はありませんが、文書の確認や証拠の調査などをお願いすることになります。ご依頼頂いた場合は、タイムチャートを用いた詳しい説明を差し上げています。

Ｑ．トラブルの相手方から内容証明郵便が届きましたが、どう対応すればよいのでしょうか？
まずは書面に書かれている相手方の主張を十分に理解することです。そして、事実関係の整理、関連するエビデンスの収集、関係者からの聞き取りなどを行ったうえ、相手方の主張の当否を評価し、争っていくか、融和の方向でいくかなど、対応方針を定めます。内容証明郵便が用いられるのは、本来は通知内容（例えば、契約解除の意思を示したこと）を証拠化するためですが、トラブルのレベルが一段階上がったこと、（書面の名義によらず）相手方に弁護士が関与していることを示している場合も多く、慎重な対応が望まれます。
Ｑ．できれば「裁判沙汰」にはしたくないのですが、可能でしょうか？
ＩＴ関係の紛争は、訴訟になってしまうと、費用・期間・労力の点で負担も大きく、たとえ勝訴したとしても十分な救済にはならない面があります。そのため、交渉その他での解決や立て直し、あるいは未然防止を指向することが賢明で、当事務所でも、そうした意識で取り組んでいます。もっとも、対立が厳しい状況で訴訟の選択肢を初めから除外してしまうと、そのこと自体が交渉力を下げてしまうことがありますので、状況に応じた解決方法を選択することが必要です。

４．その他

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

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

契約と契約書　ＴＯＰＩＣＳ (7)

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

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

基本契約書と個別契約書

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

注文書による契約

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

見積書を引き継ぐ契約

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

約款による契約

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

電子契約

　クリックオン方式や電子メールのやり取りによる契約も、電子契約の一種と言えますが、電子証明書による電子署名を付して行うものを指すのが一般的です。事業者がサービスとして提供する電子契約の仕組みには「当事者型」と「立会人型」があり、通常、交渉時のドラフトのやり取りや締結後の契約書管理などの機能と併せて提供されています。
　「当事者型」は、契約当事者（企業の場合は代表者）の電子証明書を用いるもので、電子署名により改ざん防止と本人確認のほか、二段の推定（契約書の成立の真正まで推定される）が働きます。当事者が自前で電子署名するのと、原理的には同じです。「立会人型」は、第三者であるサービス事業者が立会人の立場で電子証明書を用いるものです。改ざん防止は図れますが、本人確認は別途電子メール等によって行うのが通常で、推定が働く保証はありません。証拠力の点では「当事者型」が勝りますが、現状では運用の容易な「立会人型」が普及しています。 smart_display電子契約の法的効力と課題

契約関係の解消

　いったん契約が成立した後は、契約当事者は契約に拘束されますので、たとえ契約から不利益を受ける場合であっても、契約を一方的に破棄することはできません。一方的に破棄してしまうと、そのこと自体が契約違反となり、損害賠償等の責任を問われます。契約の成立後に契約関係を解消することができるのは、当事者双方の合意で解約する場合のほか、契約や法律で定められている解除の要件を満たす場合（例えば、相手方に一定の契約違反がある場合）に限られます。もちろん、契約の解消や変更を求めて協議することはできますが、相手方が応じなければ叶いません。契約関係に入る前の段階で、慎重な判断が求められます。
　なお、一定の継続的契約においては、一定の負担のもとに将来に向けて契約関係を解消することが法律上認められています。例えば、準委任契約においては当事者双方から解消が可能ですが、相手方に不利な時期に行えばその不利益に応じた損害賠償を要し、請負契約においては仕事の完成まで注文者から解消が可能ですが、それまでの費用と利益の損害賠償を要します。

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

システム開発契約　ＴＯＰＩＣＳ (7)

請負契約

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

多段階契約と再見積

　中小規模の開発の場合は、開発全体を一個の契約で行う「一括請負」の契約もありますが、比較的大規模の開発の場合は、契約時に予見できなかった開発規模や開発期間等の変動が起こりやすく、トラブルを招くことがあります。そのため、工程ごとの見積と契約を繰り返す多段階契約とすることが推奨されています。
　多段階契約には、開発の進行状況を踏まえた精度の高い見積を行える利点がある反面で、開発総額や最終納期に歯止めがないこと、履行や責任の単位が細かく区切られること、開発が完了するまで契約が継続する法的な保証がないことなど、ユーザにとって注意が必要な点があります。なお、一個の契約の中で、工程ごとに分割検収を行う場合、履行と責任の単位が区切られるほかは、これらの特質を持つことはありません。 smart_displayシステム開発の多段階契約と再見積

開発基本合意書

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

発注内示書（仮発注書）

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

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

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

仕様確定と仕様凍結

　「仕様確定」とは、ユーザとベンダとの合意の下で開発対象のシステムの外部仕様を確定することをいいます。「仕様凍結」を同じ意味で使うこともありますが、こちらの方は、なお追加変更の要望があり得る状況で、開発プロジェクトの進行上、いったん確定したものと扱う、というニュアンスがあります。ユーザの望む最終仕様に至っていない以上、追加変更の圧力は強いわけですが、スケジュールやコストの都合であえて「凍結」させるということです。
　仕様確定ないし仕様凍結後の追加変更要望については、変更管理の対象とされ、実際に追加変更となった場合は「仕様変更」として追加報酬が認められるのが通常です。仕様確定や変更管理が明示的に行われなかった場合でも、事後的に本来の契約内容との差異を明らかにできれば追加報酬が認められることがあります。 smart_display大規模システム開発訴訟にみる「仕様凍結」

検収と報酬支払

　検収（検査合格）は法的な概念ではありませんが、契約上あるいは実務慣習上、支払の前提手続とされているものです。多くの場合、完成に代わる（あるいは完成を推認させる）報酬発生の条件と位置付けられます。納品後に数週間程度でユーザ側の検査を兼ねた受入テストを行い、これに合格すると検収、あるいは納品までに受入テストを行っておき、合格すれば短期間の形式検査を経て検収、というパタンが通常です。
　検査によって完成を確認するという意味があるため、検収未了のうちは報酬が支払われないのが原則ですが、既にシステムが納品されているにもかかわらずユーザの都合で検査が行われないような場合は、報酬が認められることがあります。契約書にあらかじめ、納品後一定期間内に検査結果の通知がなければ検収とみなす「みなし検収」条項を入れておくこともあります。逆に、完成前であるにもかかわらず、ベンダへの資金融通の趣旨で支払を行うような場合は当然、検収の扱いとすべきではありません。 smart_display「検収」と「本稼働」の微妙な関係

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

サービス契約　ＴＯＰＩＣＳ (7)

準委任契約

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

ＳＬＡ（Service Level Agreement）

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

業務委託契約

　業務委託契約でいう「委託」は「委任」と似ていますが、一定の役務提供を依頼することを表すものですので、法的には請負とも準委任とも結びつきます。業務の性質や契約条件から区別できる場合もありますが、いずれの契約類型を想定しているのか、当事者間でしっかり認識合わせをしておくことが必要です。
　多くは請負となるシステム開発契約のほか、後述する、運用・保守契約、コンサルティング契約、ＳＥＳ、ＳＥＯ契約なども、業務委託契約の一種と言えます。このように、業務委託契約は多様な契約を包含するもので、それだけでは契約条件が定まらない（法律上のデフォルトや実務上の取引慣習で補えない）ため、契約類型のほか、業務内容、契約期間、更新や解約の扱い、報酬とその支払条件等について、契約で明確化することが不可欠です。

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

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

コンサルティング契約

　一般には専門的事項について指導・助言等を行う契約をいいます。ＩＴ系の場合、情報システムの企画・立案や運用改善のための調査・評価等に関与する場合が典型です。通常は準委任とされますが、一定の知的成果を生み出す場合は請負となり得ます。システム開発契約の超上流工程に関与する場合、実質は開発契約の一部（請負）であると評価されることもあります。
　稼働後でないと品質が明らかにならない特質があるため、短期契約の更新制とする、対象業務を詳細に定義する、何らかの成果と連動した契約とする、といった対応が取られたりします。情報システム部門の専門性に不安のある中小企業では、外部のコンサルタントを顧問のような位置づけで意思決定に関与させることがありますが、企業側での十分なコントロールが効かない例が散見され、注意を要します。

ＳＥＳ（System Engineering Service）

　ＩＴ業界で古くからあるサービス業務で、多くの場合、企業やプロジェクトの現場に常駐して技術系のサービス業務に従事します。サービス内容としては、情報システムの開発や保守、運用オペレーション、技術支援等、多岐に渡ります。
　一般に準委任形態の業務委託と位置付けられていますが、実態として、受託者が委託者から直接の指揮命令を受けているのではないかと疑われる場合もあります。そのような場合は、派遣法や労働関係法規の厳しい規制を潜脱する、いわゆる偽装請負の問題となります。受託者側に裁量の余地のある業務内容とすること、受託者側の管理者を明確にしておくことが最低限必要です。

ＳＥＯ（Search Engine Optimization）

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

　企業が利用可能なソフトウェア・プロダクトには、さまざまな種類があります。主に開発主体やそれに伴う権利関係による違いですが、導入コスト、導入の容易さ、自社業務への適合性、保守の容易さ、利用の継続性、などの特性に（時に大きな）差があります。
　しばしば、プロダクト導入の当初は十分な見極めができず、検討や作業の過程で方針変更を余儀なくされる場合があります。例えば、パッケージ・ソフトウェア導入の前提で進めていたものが、カスタマイズを要することになる、スクラッチ開発の前提であったのが、ＯＳＳを組み込む必要が生じる、といった場合です。こうした方針変更は一概に否定すべきではありませんが、上記の特性に大きな変化が生じますので、慎重な判断を要します。
　また、どのプロダクトを利用するのかについては、当然のことながらユーザが把握している必要があります。もちろん、パッケージとスクラッチを取り違えることなどあり得ませんが、スクラッチ開発中のソフトウェアにベンダのひな型やＯＳＳが、ベンダの独断で（ユーザの了解を得ることなく）組み込まれることがあり、注意を要します。

ソフトウェア・プロダクト　ＴＯＰＩＣＳ (6)

パッケージ・ソフトウェア

　独立した製品として販売されている汎用性のあるソフトウェアです。文字どおりパッケージとして流通している場合のほか、同じ内容のものが企業向けにバルク販売されたり、サービスとしてクラウド（ＳａａＳ）提供されたりすることもあります。利用許諾により、利用目的、利用期間、利用場所、利用マシン（サーバ／クライアント）、（同時）利用数、などに制約がかかります。利用料のほか、あるいはこれに代えて保守料がかかります。
　そのまま利用できればコスト・パフォーマンスが高いと言えますが、自社の業務要件への適合性については一定の限界があります。また、ベンダ・ロックインの問題が生じます。特に問題なのは、ベンダの倒産、販売や保守の終了、第三者との権利問題、契約上のトラブルなどにより、利用の継続性が保証されないことです。個人データについてのデータ・コンパチビリティのような議論は乏しく、システム／データ移行への対策が求められます。

スクラッチ開発ソフトウェア

　自社向けに開発するオリジナルのソフトウェアです。自社開発する場合が典型ですが、多くの場合は開発力や人員の都合から外部ベンダに開発委託されます。業務適合性は最も高くなりますが、これは自社内での業務要件の取りまとめ次第という面があります。この点はあくまでユーザ自身が責任をもって行うべきことであり、外部委託しても変わりません。
　外部委託された場合、ベンダとの間で適切に権利処理しておく必要がありますが、権利移転ではなく利用許諾にとどまる場合は、パッケージと同様の制約を受けることがあります。また、スクラッチ開発であっても、部品として第三者のソフトウェアが用いられることがあります。この場合、出来上がったソフトウェア全体としては、次のカスタマイズ・ソフトウェアと同様に、部品の権利関係に引っ張られますので、注意を要します。

カスタマイズ開発ソフトウェア

　パッケージ・ソフトウェアにカスタマイズを加えて開発するソフトウェアで、開発コストの低減と自社の業務要件への適合の両立を図るものです。ただ、ベースとなるパッケージ・ソフトウェアの業務適合性が十分でなく、過度のカスタマイズが必要になると、その利点が失われるばかりか、開発が著しく困難・長期化して深刻な開発トラブルを招くことがあります。しかも、業務適合性は、開発をある程度進めないと見通せないところがあります。
　また、パッケージ本体部分もカスタマイズ部分も（本体部分に準じた権利関係となる場合が多いため）、利用許諾による制約や、利用の継続性が保証されない点をそのまま引き継いでしまいます。カスタマイズが入ったことで、開発後にバージョンアップがあっても、適用が困難となることがあります。

ＯＳＳ（非コピーレフト型）

　厳密な定義をひとまず措けば、少なくともソフトウェアの配布と改変の自由が保証されたソフトウェアをいいます。利用条件はライセンスによって示されますが、ライセンスの表記義務や無保証など、常識的なものが殆どで、大きな負担になることはありません。ＢＳＤやＡｐａｃｈｅなど、標準的なライセンスが用いられることが通常です。
　ＯＳＳ自体は無償であっても、完全に無保証です。もっとも、活動的なコミュティが維持されている場合、かなり迅速にアップデートが行われているのが実際です。いずれにしても、利用に伴う負担は全面的に利用者が負います。これを緩和するため、有力ＯＳＳについては、ディストリビュータによる有償の保守サービスが提供されています。

ＯＳＳ（コピーレフト型）

　こちらが本来のＯＳＳとも言え、ＧＰＬが代表的なものです。ＯＳＳの派生ソフトウェアを配布する場合は、そのソースコードを開示することが求められます。派生ソフトウェアとしては、ＯＳＳのカスタマイズすなわち著作権法上の二次的著作物に相当するもののほか、ＯＳＳと静的リンク（実行可能ファイル生成時に呼び出しを解決）するもの、動的リンク（呼び出し時に初めてロードする）するものまで含まれる場合があります。
　派生ソフトウェアの配布を伴う場合は、改変部分に含まれる自社の営業秘密が守れなくなるおそれがあるため、利用に慎重とならざるをえません。しかし、それ以外の場合は非コピーレフト型と大差ありません。

ＦＯＳＳとフリーウェア

　ＦＯＳＳは上述のＯＳＳやフリーソフトウェアなど、何らかの意味で自由な利用、オープンな利用が認められているソフトウェアの総称です。これらは自由な利用が認められますが、自由やオープンといった一定の「理念」を実現するために、開発者が著作権は留保したうえでライセンスを用いることに特徴があります。同じような自由な利用を、開発者が著作権自体を放棄することで実現するのが、パブリックドメイン・ソフトウェアです。
　他方、フリーウェアは、無償のソフトウェアを意味します。ただ、利用には制限がかかることがあり、また、必ずしもオープンではないため、自家保守やコミュニティによる保守は困難で、開発者による保守だけが頼みということがあります。

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

知的財産権　ＴＯＰＩＣＳ (6)

法人等における職務著作

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

著作権の共有

　著作権は、複数の個人や法人の間で共有となることがあります。一つは、複数の著作者による共同著作の場合です。ただ、法人内での複数の担当者による場合は、要件を満たせば職務著作となりますので、共有とはなりません。もう一つは、著作権の持分譲渡の場合です。例えば、業務委託の成果物について、ベンダからユーザに著作権の持分５０％が譲渡されれば、持分均等の共有となります。
　情報成果物の場合、共有であっても物理的な利用には支障を来たさないことから、共有は権利帰属の調整が難しい場合の有力な選択肢となり得ます。ただ、著作権が共有となる場合でも、持分の譲渡や利用については、他の共有者の同意・合意が必要です。プログラムや設計書の共有の場合、少なくとも利用（社内利用も含みます）については強すぎる制約ですので、あらかじめ合意しておくことが通常です。

著作権の権利制限

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

著作権と秘密保持

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

情報システムと営業秘密

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

ソフトウェア特許

　情報システムの保護として最も強力なのが、ソフトウェア特許です。ただしその分、発明であること、新規性があること、進歩性があること、とハードルは高くなりますし、出願等の費用や特許料もかかってきます。例えば資産運用方法のように、ソフトウェアの対象自体が発明（自然法則を利用した技術）でなくとも、これをソフトウェアで実現したものは特許の対象となり得ます。
　同様に、いわゆるビジネスモデルもそれ自体では特許の対象とはなりませんが、これを情報システム化したものはソフトウェア特許となり得ます。その意味で、ビジネスモデル特許はソフトウェア特許の一種と言えます。アマゾンの「1-Click」が有名ですが、保険の自動設計やバーチャルハウジングセンターなど、国内の事例も少なくありません。

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

インターネット　ＴＯＰＩＣＳ (7)

申込画面の規制

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

規約と定型約款

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

特定商取引法に基づく表示

　ＥＣサイトにおいては、「利用規約」と「プライバシーポリシー」のほか、「特定商取引法に基づく表示」が必要となります。この表示は、通信販売における広告全般に求められるものですが、販売・サービス用のサイトは当然に広告の要素を有しているため、必要となるものです。表示すべき事項として十数項目が法定されており、サイトによっては無関係のものもある反面、「ソフトウェアの動作環境」や「販売数量の制限等の条件」など漏れやすいものもあり、注意を要します。
　なお、特定継続的役務提供（一定の条件を満たすエステティック、語学教室、結婚相手紹介など）における契約締結前の「概要書面」及び締結後の「契約書面」は、必要項目で重なるものがありますが上記表示とは別物です。こちらは、通信販売であるかどうかに関わらず交付することが必要となります。

渉外取引

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

クラウドサービス

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

通信事業者の責任

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

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

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

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

ビッグデータ／ＡＩ　ＴＯＰＩＣＳ (6)

データの権利関係

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

個人データの保護

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

ＡＩの権利関係

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

ＡＩソフトウェアの開発契約

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

ＡＩによる行為・取引の責任

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

ＡＩスコアリング

　ＥＣサイトやグルメサイトでの星数の評価もスコアリングの一種ですが、信用情報サービスや自動車保険でのテレマティックスにおいて、ＡＩを利用して利用者の情報や活動をスコアリングする動きが進んでいます。従来は困難であった無担保での融資が可能になるなど、サービスの幅が広がるといったメリットがあります。
　他方で、スコアリングのために個人情報が包括的に利用されることの問題点（改正個人情報保護法で一定の個人関連情報の移転について制限が設けられます）や、データから造られた人物像が独り歩きしかねないというプロファイリングと同様の危惧も指摘されています。スコアリングの基となった情報や評価手法を事業者が十分に開示・説明できるのかという、ＡＩ利用に共通する透明性の問題もあります。

　ＩＴ事故／事件が起きた場合、その加害者の立場にある者は、一定の要件の下に法的責任を負います。一口に法的責任と言っても、複数の種類があり、要件に当てはまる限り、それらの責任を重ねて負う可能性があります。
　まず、私人間の責任として民事責任があります。契約関係にある当事者間であれば、債務不履行や契約不適合を理由として、損害賠償、契約解除、差止めといった責任を負います。契約における特約に基づき、別段の責任（報告義務等）を負ったり、逆に制限（賠償制限等）されたりすることがあります。また、契約関係にない当事者間においても、不法行為責任を負います。被害者側に過失の立証責任があるため、ややハードルは高くなりますが、損害賠償や名誉回復の処分が認められます。不正競争防止法等、個別法令違反の場合の民事責任は、不法行為責任の特則と位置付けられます。
　次に、刑法又は個別法令の罰則に触れる場合、刑事責任を負います。法律に規定されている法定刑の範囲内で、懲役刑や罰金刑が科されることになりますが、執行猶予がつく場合は猶予期間中に更に罪を犯すこと等がなければ刑の言渡しは効力を失います。原則として、故意犯のみが処罰の対象で、過失犯は特に規定がある場合や一定の行政犯のみ処罰対象となります。法人における犯罪については、刑罰法規に触れた個人に加え、法人にも刑罰が科されることがあります。
　さらに、個別法令に基づく立入検査、行政命令、許可の取消、といった行政上の責任を負う場合もあります。通常の裁判なしに支払を命じられる過料もその一つです。

ＩＴ事故・事件の責任　ＴＯＰＩＣＳ (6)

システム障害

　対外サービスで利用されていたシステムに障害が発生し、サービス利用者が損害を被る場合が典型です。この場合、サービス事業者がサービス利用契約に基づく債務不履行責任を負う可能性があります。ただ、システム障害により直ちに責任が発生するわけではなく、当該システム障害の内容や障害発生後の善後策などを踏まえ、契約上の不履行や注意義務違反があったかどうかが判断されます。原則として責任ありと判断される場合でも、賠償すべき損害の範囲や免責条項の効力、サービス利用者側の行為による過失相殺が争われることが通常です。
　障害を起こしたシステムが他のベンダが受託開発したものであった場合、障害が運用等によるものでなくシステムの不具合自体を原因とするものであれば、ベンダがサービス事業者に契約不適合責任を負う可能性があります。また、サービス利用者としては、直接にベンダの不法行為責任を問う余地もありますが、ベンダの責任原因が明らかでないことが多い一方で、サービス事業者の責任を問えば足りることから、直接に請求する実益がないのことが殆どです。 smart_displayジェイコム株誤発注事件（東京地判平21.12.4）

情報漏えい

　企業の技術情報や営業情報の漏えいが起きた場合、まず、不正競争防止法への違反が問題となります。ただ、漏えいの態様が限定されているほか、秘密管理性、有用性、非公知性の要件が必要であるため、ハードルは高くなります。これに対し、ＮＤＡは要件等を契約で定めるため、保護の範囲を比較的広くとることができ、補完として機能します。両者は損害賠償や差止めが認められる点は同様ですが、前者は損害の推定規定や刑事罰がある点が異なります。
　個人情報の漏えいが起きた場合、それを顧客情報等として取得・保有していた企業との関係で、営業秘密等の侵害が問題となります。また、本人との関係では、情報を取得・保有していた企業、漏えいさせた企業とも、不法行為責任を負う場合があります。個人情報保護法上は、不正な利益を図る目的での提供・盗用の場合の刑事責任のほか、漏えいを生じさせた安全管理措置義務違反について、報告や立入検査、指導・助言、勧告・命令といった行政責任が生じることになります。

データ消去

　データの保管は、法的には民法上の寄託契約と扱われるのが通常です。有償であれば善管注意義務をもって、無償であっても「自己の財産に対するのと同一の注意」をもってデータを保管する義務が課され、これに違反してデータ消去を招いたのであれば、債務不履行として損害賠償や契約解除の責任を負います。また、情報漏えいなどの場合と同様、社会的影響が大きければ、レピュテーション・リスクも無視できません。
　アップロードしたデータを加工したり、これを利用したサービスを提供するといった、そもそも契約上の義務にデータ保管が含まれているかどうか、あいまいなケースもあります。また、適切にバックアップが取られていれば、損害は大きく軽減（バックアップから漏れたデータの欠損、バックアップによる復旧までのサービスの停止くらい）されますが、これを受託側がどこまで保証していたのか、委託側にもその責任があると考えられる場合は過失相殺もあり得る、など問題は複雑です。 smart_displayホームページのデータ消滅事件（東京地判平13.9.28）

データ改ざん

　データ改ざんは、さまざまな場面で起こり得ます。データ改ざんについて法的責任を広くカバーしているのは、刑法です。文書偽造の一態様である電磁的記録不正作出罪、クレジットカード等についての支払用カード電磁的記録不正作出罪、いわゆるコンピュータ・ウィルス等についての不正指令電磁的記録作成罪（自ら投入すれば電子計算機損壊等業務妨害罪）などがあります。
　その他で法的問題となる場面としては、法令により報告を義務付けられているデータを改ざんし、安全性等の基準を満たしているかの虚偽の報告を行うような場合です。この場合の責任は、関係する法令の規定によります。また、主に企業の内部者が、背任・横領の過程で会計データ等を改ざんする場合もあります。この場合の責任は、データ改ざんの責任に、背任・横領そのものについての刑事責任及び民事責任（損害賠償や解雇など）が加わります。

不正アクセス

　権限のないサーバに不正アクセスし、データを持ち出した場合、いわゆる（情報）窃盗罪とはなりませんが、不正競争防止法に触れる可能性があります。さらに、一定の場合には、不正にアクセスしたこと自体で不正アクセス禁止法違反となります。要件として、アクセス制御機能を付加されたコンピュータに対するアクセスであること、電気通信回線を通じて行うアクセスであること、他人の識別符号（ＩＤ・パスワード）等を入力して行うアクセスであること、という限定はありますが、違反に対しては懲役又は罰金の刑事罰があります。
　また、コンテンツ保護の観点から、コンテンツに対する無断コピーや無断アクセスを防止するための規制が、不正競争防止法に設けられました。すなわち、影像や音、プログラムのコンテンツにコピー管理技術やアクセス管理技術が施されている場合、これを無効化する装置やプログラムを譲渡、提供するなどの行為が禁じられています。

製造物責任

　システム障害により損害を被ったユーザとしては、障害を起こしたシステムの開発ベンダの不法行為責任を問う余地もありますが、通常は困難です。開発過程に関与していないため、過失の立証が困難であるためです。ただ、引渡しを受けた製造物の「欠陥」（製造物が通常有すべき安全性を欠いていること，設計上の欠陥、製造上の欠陥、指示・警告上の欠陥があります）と損害との因果関係を立証できる場合、開発ベンダの製造物責任を問うことができます。
　製造物責任は、被害者救済の観点からの立法ですが、法人による請求にも適用があります。また、製造者のみならず、輸入者や加工者（バグ取りを超えた改修を行った者）、ＯＥＭ供給者も責任を負います。ただし、製造物責任の対象は「製造又は加工された動産」とされているため、ソフトウェア単体では対象となりません。組込みソフトウェアなどハードウェアと一体化している場合に限り対象となります（単にメディアに化体されているだけの場合は含まれません）。

　トラブルが本格的な紛争となり、話し合いによっても解決できなければ、後は訴訟ということになります。ＩＴ訴訟の場合、専門的かつ複雑となるため、そこにかかる期間、費用、労力とも、通常の訴訟とは比較にならないものになるため、慎重な判断を要します。ただ、請求する立場にある側（原告となる側）としては、初めから訴訟を度外視すると交渉力を大きく損なうこと、実のない交渉を延々と続けるくらいであれば早期に訴訟に打って出た方が結果としてトータルの負担も小さくなることから、訴訟も選択肢として考えておく必要があります。
　裁判所（その他の紛争解決機関）での手続としては、他にも商事仲裁、少額訴訟、支払督促、即決和解、などがありますが、ＩＴ訴訟で用いられることは稀ですので、ここでは割愛します。また、訴訟の手続にはいろいろと例外もあり、進行も事案に応じてさまざまですが、以下では基本的な考え方のみ説明します。

ＩＴ訴訟　ＴＯＰＩＣＳ (6)

裁判所の管轄

　裁判所の管轄には、まず土地についての管轄があります。デフォルトの管轄は、被告の住所地（企業であれば本店所在地）を管轄する裁判所となります。ただし、金銭の請求であれば、（持参払いが原則となることから）原告の住所地を管轄する裁判所、不法行為に基づく請求であれば、不法行為の地を管轄する裁判所、といった例外があります。また、契約書等で管轄の合意があれば、その裁判所が管轄となりますが、それが専属的合意管轄である場合、その裁判所のみに限られます。なお、管轄違いで提訴した場合であっても、被告が争わなければ、応訴管轄として有効となることがあります。
　次に、訴額（金銭であれば請求額）に応じた事物管轄があります。第一審については、訴額が１４０万円未満であれば簡易裁判所、１４０万円を超えれば地方裁判所となります。株主総会決議取消のように、価額を算定することができない請求の場合、常に地方裁判所の管轄となります。

訴訟と調停

　通常の訴訟は、裁判所による判決を求めるものです。訴訟が提起された場合、被告は事実上、訴訟から逃げることはできません。現実に出廷して応訴することを強制されるわけではありませんが、何も対応しなければいわゆる欠席裁判となって原告の言い分が全て認められてしまいます。これに対し、調停は当事者の話し合いにより紛争を解決するもので、裁判所による判決が下されるわけではありません。また、申立てがあっても、相手方が応じなければ不調に終わってしまいます。このように調停は、対立を先鋭化させない話し合いのメリットはあるものの、強制的な紛争解決を図れるわけではなく、ＩＴ事件での利用は限定的です。
　原告が提訴した本訴に対抗して、同じ手続内で関連する請求について被告が反訴を提起することがあります（例えば、代金返還の請求に対して残代金を請求するなど）。対立の激しいＩＴ訴訟では、反訴が提起されることが比較的多いのが特徴です。原告の本訴提起が引き金となって被告の反訴を招き、結果被告が勝訴する、とったやぶ蛇となるケースもあるため、提訴に当たっては慎重な考慮が必要です。　

訴訟における書面

　提訴時に原告が請求内容やその理由を記載し、裁判所に提出するのが訴状です。訴状が裁判所での審査を経て被告に送達されると、訴訟が正式に係属することになります。被告が、第１回の口頭弁論期日までに、訴状に対する認否や自身の主張（反論）を記載して提出するのが答弁書です。もっとも、この時点の答弁書は（時間的な余裕がないため）原告の請求の棄却を求めるだけで、実質的な認否・反論はその後の準備書面に記載されることが通常です。
　その後、口頭弁論（公開法廷で行われる手続）又は弁論準備手続（非公開の別室で行われる手続）を繰り返し、原告と被告がそれぞれ、準備書面によって自身の主張や反論を展開していきます。事実関係についての記載は撤回が許されなくなるおそれがあるため、これらの書面は、事実関係を良く確認したうえで慎重に作成する必要があります。その間、裁判所は、次に述べる証拠調べの状況も勘案しながら、その訴訟の争点（訴訟の勝敗を左右する点）を整理していきます。

書証と検証

　書面による主張・反論と並行して行われるのが証拠調べです。その中で最も重要なのが、書証（文書の意味内容を証拠とするもので、図面、写真、録音テープ、ビデオテープ等もこれに準じます）です。契約書や注文書などの契約関連書類のほか、提案書、作業ドキュメント、報告書、近年では電子メールやビジネスチャット等による連絡文書の重要性も上がってきています。原則として、自身に有利な証拠は自ら提出する必要があるため、証拠の所在が訴訟の鍵を握ることも少なくありません。
　ＩＴ訴訟の場合、情報システムやウェブサイト等の実際の動作を確認するため、検証の手続が行われることもあります。例えば、立証したいシステムの動作（あるいは不具合）が明らかとなるシナリオを作成しておき、裁判官の面前でそれに沿ったオペレーションを行う、といったことです。同様の内容を通常の期日に事実上行ったり、第三者が別途行った結果報告を意見書（書証の位置づけ）の形で証拠化する、といったこともあります。

証人尋問

　書面による主張・反論と書証等による証拠調べにより、争点が明確になると、その争点に関して（だけではありませんが）証人尋問（当事者本人あるいは会社の代表者の場合は本人尋問）が行われます。効率的に行うため、あらかじめ尋問予定者の陳述書を提出しておき、尋問はこれを補完する形で行うのが通常です。
　原告（被告）側の証人が原告（被告）側の代理人の質問に答えるのが主尋問、これは事前の準備どおりに進めるのが通常ですので、滞りなく終えて当然、という評価となります。これに対し、相手方の代理人の質問に対して答えるのが反対尋問です。これは、主尋問での証言の信用性を突き崩す目的で行われるもので、かなり厳しい質問が来ます。これに耐えられれば主尋問での証言の信用性が高まり、十分な対応ができないと主尋問での証言の信用性が揺らぐ、ということで、この反対尋問が証人尋問の鍵となります。裁判官からの質問もありますが、どの程度突っ込んだ質問がなされるかは、裁判官によるようです。

判決と執行

　必要な審理がすべて終わると、判決となります。第一審（通常は地方裁判所）の判決に対して不服がある場合、控訴することができます。控訴提起がなされると、第一審の判決は確定を阻止され、控訴審（通常は高等裁判所）での審理に基づく判決に取って変わられます。なおも不服がある場合は上告（通常は最高裁判所）もできますが、これは事由が限られていることもあり、通常の民事事件がここまで行くことはほとんどありません。
　期間内に控訴等がなされない場合、判決は確定し、勝訴判決は債務名義となります。債務名義により、強制執行が可能となりますが、企業間の訴訟の多くは任意の履行がなされます。他方、個人相手の訴訟では、任意の履行はおろか財産の所在が明らかでなく強制執行も容易でないといった事態もあり得るため、（提訴前からの）注意を要します。なお、いずれの審級でも、判決前のある程度審理が進んだ段階（例えば、証人尋問の前後くらい）で、話し合いによる和解が試みられることがあります。和解が成立すると、その和解調書も債務名義となります。