• スクレイピングはどこまで許されるのか　生成AIの学習データ収集も踏まえて事業者が確認したい法的ポイント

  スクレイピングとは何か、なぜ法的検討が必要なのか スクレイピングとは、Webサイト上に掲載されている情報を、プログラムを用いて自動的に取得し、整理又は保存することをいいます。業務の効率化、情報収集、データ分析、生成AIの学習用データ整備など、さまざまな場面で利用が検討される手法です。 ところで、インターネット上で公開されている情報であれば自由に取得し、利用できると考えられることもありますが、実際にはそのように単純ではありません。スクレイピングの適法性は、一律に決まるものではなく、対象となる情報、取得の方法、取得先の利用条件、取得後の利用目的などによって判断が分かれます。 スクレイピングを… 2026.04.02 続きを見る »

• IT業の債権回収はなぜ難しい？ 未払いトラブルを5類型で整理して対策を解説

  はじめに  IT業の債権回収は、一般的に難しいといわれることがあります。 もっとも、IT業といっても、システム開発、SES、保守運用、SaaS、Web制作、AI導入支援、デジタルマーケティング支援など、業態はさまざまです。そのため、未払いが生じる原因や、回収が難しくなる理由も一律ではありません。 IT業の債権回収を適切に理解するためには、まず、IT業に共通する特徴を押さえた上で、さらに業態ごとの違いを整理することが重要です。 この記事では、IT業全般に共通する回収上の難しさを確認した上で、業態ごとにどのような点が争点となりやすいのかを整理します。 ■この記事で解説している内容 … 2026.03.26 続きを見る »

• AIが生成したプログラム・コードは自由に使えるのか～著作権、利用規約、OSS、営業秘密まで弁護士が解説

  AI生成プログラム/コードは自由に使えるのか  生成AIを使えば、プログラムやソースコードを短時間で作成できるようになりました。社内ツールの開発、既存コードの修正、顧客向けシステムへの実装など、すでに多くの場面でAI生成コードが利用されています。もっとも、AIがコードを出力したからといって、そのコードを当然に自由に使えるとは限りません。 問題となるのは、単に「AIを使った」という事実ではありません。実際には、そのプログラム/コードにどのような法的性質があるのか、そして、そのプログラム/コードをどのような場面で利用するのかを分けて考える必要があります。たとえば、社内で試験的に利用する場合と、… 2026.03.16 続きを見る »

• データ漏えい等の事故が起こったら～中小ベンダのための「初動・証拠・説明」実務チェック

  データ漏えい、不正アクセス、誤送信、データ消失などのトラブルが発生したとき、早期に「誰に責任があるか」を確定しようとすると、かえって状況を悪化させることがあります。 初動対応で重要なのは、原因や過失の断定ではなく、被害拡大の防止、事実関係の整理、そして証拠の保全です。例えば、ログの上書きや関係者の発言の不統一は、後日の説明や交渉を困難にし、行政対応や取引先対応でも不利に働きます。適切な初動は、被害の範囲を正確に把握し、社外への説明を整合的に行い、損害賠償や契約上の責任が問題となる局面で判断材料を確保するための前提になります。 本記事では、トラブル発生後の初動で実施すべき事項と避けるべき対応… 2026.03.16 続きを見る »

• パッケージ開発の紛争予防～F&Gから検収・保守まで、契約書に落とす要点

  なぜパッケージ開発は揉めやすいのか（成果の内容の不一致とF&Gの未固定） パッケージ開発が紛争化しやすい主因は、当事者間で「成果の内容」を一致させにくい点にあります。 スクラッチ開発では、仕様として「何を作るか」を定め、その仕様どおりかを基準に確認できます。一方、パッケージ開発では、既存の標準機能を前提に導入するため、ユーザーが期待する業務の実現方法が「標準で満たせるのか」「設定や運用で代替するのか」「追加開発が必要か」といった形で分岐します。この分岐が契約前後で十分に整理されないまま進行すると、後日、追加費用・納期・未対応範囲をめぐる対立が生じやすくなります。 また、パッケージ… 2026.02.08 続きを見る »

• 「検収が終わらない」地獄から抜ける～受注者が取るべき手順（請負・準委任対応）

  「不合格」「未検収」と言われた瞬間、プロジェクトは「技術」ではなく「契約と証拠」の勝負に切り替わります。検収が止まると、支払の停滞、無償対応の拡大、追加要望の混入が連鎖し、現場は疲弊しがちです。ここで判断を誤ると、修補を続けても検収が動かず、支払だけが止まり続けることがあります。 その原因になりやすいのが、契約類型（請負／準委任）によって争点の置き場が変わる点です。請負では「完成・引渡し」と「契約不適合」が中心争点になる一方、準委任（アジャイル等）では「合意したプロセスに沿った遂行（善管注意）」が軸になります。 本記事では、検収拒否が起きる典型パターン、請負／準委任それぞれの争点、受注者が… 2026.01.22 続きを見る »

• システム開発における「準委任契約」とは？ 請負契約との使い分けポイントを徹底解説

  「請負か、準委任か？」 AIやシステム開発をめぐる契約実務において、成果物の定義や責任範囲を誤ると、プロジェクトの進行に深刻な支障が生じかねません。 本記事では、民法上の整理をふまえつつ、開発フェーズや実務慣行に応じた最適な契約類型の選び方と、よくある誤解・落とし穴の回避ポイントを弁護士の視点で解説します。 1.準委任と請負の区別・選択基準  システム開発取引における「準委任契約」と「請負契約」の使い分けは、成果物の完成を重視するか、作業の遂行自体を重視するかという視点が基本になります。 (1)法的性質の違い  準委任と請負の法律上の相違点をまとめると次の通りとなります。 … 2026.01.08 続きを見る »

• システム開発の再委託は可能なのか？リスクを最小化するためのポイントを解説

  システム開発において「再委託」は可能か 再委託の可否は、システム開発取引契約の法的性質によって相違が生じます。 (1)請負契約の場合（成果物の完成が目的） 請負契約の場合、民法は再委託を禁止していません。システム開発取引における請負契約とは、例えば、新規システムの受託開発や特定機能（追加モジュール、画面、APIなど）の追加開発などです。 再委託が可能なのは、請負契約は「仕事の完成」を約する契約であり、完成さえすれば誰が作業したかは法律上問題にならないからです。 但し、再委託した場合、次の点に注意を要します。 ①再委託を実施したことで、受託者（再委託元）が現実に作業を実施しない場合で… 2025.12.25 続きを見る »

• 「完成していないから払わない」と言われたら？　システムベンダのための完成・検収トラブル徹底解説

  なぜ「完成トラブル」がベンダを苦しめるのか  例えば、次のような場面でお困りになったことはないでしょうか。 ・仕様どおりに作ったつもりだが「思っていたのと違う」と言われ検収してもらえない ・App Store の審査が通らず「公開できていないから支払わない」と言われている ・要件が増え続け、いつまでも「完成」と言ってもらえない システム開発の現場では、「システムが完成したかどうか」という点をめぐる対立が後を絶ちません。ベンダとしては仕様どおりに作ったつもりでも、ユーザ（注文者）から「思っていたものと違う」「まだ使えるレベルではない」と言われ、検収が行われず報酬の支払いも進まないことが… 2025.12.11 続きを見る »

• システム開発のRFP実務～作成の要点、誤解、紛争予防のコツ

  RFPとは RFP（Request for Proposal／提案依頼書）とは、発注者が「こういう成果を得たい」、「この条件で提案してほしい」と伝えるための文書です。 複数の候補先（ベンダ）から提案と見積もりを集め、内容を比べて選ぶために使います。 あらかじめ目的や評価の基準を書いておくことで、誤解を減らし、選定の過程をわかりやすくできます。 (1)RFPを使う主な場面 次のような場面でRFPがよく使われます。 ・新しいシステムやサービスの導入を外部に依頼したいときに、複数社の提案を公正に比べたいとき。 ・既存システムの入れ替えや機能追加を行うときに、条件を整理… 2025.11.06 続きを見る »