ITエンジニアがトラブルを避けるための法律・契約入門

公開日：2026-09-18　最終更新日：2026-09-18

ITエンジニアがトラブルを避けるための法律・契約入門

ITエンジニアの仕事では、プログラムが正しく動けば、それですべてが解決するわけではありません。

仕様通りに作ったのに「完成していない」と言われる。
追加機能を頼まれて対応したのに、追加料金を払ってもらえない。
自分で書いたプログラムを副業で流用したら問題になった。
顧客から預かった仕様書を生成AIに入力してしまった。
納品したシステムの障害を理由に、多額の損害賠償を請求された。

さらにITの現場では、

VBAプロジェクトにパスワードを掛けて納品したら、顧客から「解除してほしい」と言われた。
「このVBAのパスワードを解除してほしい」と依頼された。
GitHubで見つけたコードを、そのまま製品に組み込んでよいのか。
顧客の仕様書やエラーログを生成AIに入力してよいのか。

といった、技術だけでは判断できない問題もあります。
重要なのは、「技術的にできること」と「法律・契約上やってよいこと」は別だということです。

本稿では、ITエンジニアが最低限知っておきたい法律・契約の基礎から、副業・フリーランスで注意すべきこと、著作権・個人情報・OSS・生成AI・アクセス権限など、実際のIT現場で起こり得るトラブルまで、具体例を交えながら解説します。
法律の条文を暗記することが目的ではありません。
個々の事例について「違法か合法か」を暗記することでもありません。

「これは法律や契約を確認した方がよさそうだ」と気付けること。

そのための、ITエンジニアに必要な法律・契約の「護身術」を身につけていきましょう。

    本稿は、ITエンジニアが業務上遭遇しやすい法律・契約上の論点について、一般的な考え方を解説したものです。
 法律相談・法的助言を行うものではなく、個別の契約・紛争について結論を示すものではありません。
 契約書の文言、権利関係、当事者の立場、取引形態、利用目的・方法、実際の運用状況等によって、適用される法律や結論が変わる場合があります。

 本稿では生成AIも活用して情報の整理や文章作成を行い、人による確認・修正を行っていますが、記載内容の完全な正確性・最新性を保証するものではありません。
 本稿の記載内容を利用したことによって生じた損害・トラブル等について、筆者は責任を負いかねます。
 本稿の内容だけで法律判断を行わず、実際の契約締結、権利関係の判断、損害賠償請求、紛争対応等については、契約書その他の資料を確認したうえで、必要に応じて弁護士等の専門家にご確認ください。

 記載内容は2026年9月の執筆時点で確認した情報に基づいています。最終制度確認日：2026年9月18日
 ※2026年7月17日に改正個人情報保護法が公布されていますが、一部を除き今後施行予定です。本稿の個人情報に関する説明は、上記確認日現在で施行されている法令・ガイドラインを基準としています。
 法律・ガイドライン・行政機関の運用・各種サービスの利用規約等は変更される場合があります。
 最新の法令はe-Gov法令検索、フリーランス取引は公正取引委員会、労働関係は厚生労働省、著作権は文化庁、個人情報は個人情報保護委員会等の公的情報をご参照ください。

ページ内目次

第1章：ITエンジニアが知っておきたい法律・契約の基礎
├─ 1-1　なぜITエンジニアに法律・契約の知識が必要なのか
├─ 1-2　契約とは何か ―― 口頭・メール・チャットでも成立する
├─ 1-3　請負・準委任・派遣の違い
├─ 1-4　契約書で最低限確認しておきたいこと
├─ 1-5　著作権・知的財産権と職務著作
├─ 1-6　NDA・秘密情報・営業秘密・個人情報の違い
├─ 1-7　OSS・外部サービス・ライセンスの注意点
├─ 1-8　損害賠償と契約解除の考え方
└─ 1-9　「契約書に書いてあれば絶対」とは限らない

第2章：副業するITエンジニアが注意したいこと
├─ 2-1　会社員でも副業は自由なのか
├─ 2-2　本業で作ったコードやノウハウを副業で使ってよいのか
├─ 2-3　会社のPC・アカウント・AIサービスを副業に使うリスク
├─ 2-4　本業の取引先から個人的に仕事を受けてよいのか
├─ 2-5　副業では自分自身が「契約担当者」になる
└─ 2-6　ココナラ・クラウドソーシング等を利用するときの注意点

第3章：フリーランスITエンジニアが注意したいこと
├─ 3-1　フリーランスになると何が変わるのか
├─ 3-2　仕事を受ける前に決めておくべき条件
├─ 3-3　見積書・発注書・契約書は何が違うのか
├─ 3-4　「ついでにこれも」という追加作業をどう扱うか
├─ 3-5　「納品」「完成」「検収」の違い
├─ 3-6　報酬が支払われないとき ―― フリーランス法・取適法
├─ 3-7　著作権の「譲渡」と「利用許諾」は何が違うのか
├─ 3-8　納品後のバグ修正・保守はどこまで無料なのか
└─ 3-9　契約も仕様も「ログ」を残す

第4章：こんなときどうする？ ITエンジニアの法律・契約トラブル事例集
├─ 4-1　Excel・VBA案件で起こりやすいトラブル
├─ 4-2　契約・発注・仕様変更
├─ 4-3　報酬・支払い・損害賠償
├─ 4-4　著作権・ソースコード・再利用
├─ 4-5　秘密情報・個人情報・SNS
├─ 4-6　生成AI・クラウド・外部サービス
├─ 4-7　OSS・ライセンス
├─ 4-8　再委託・外注・チーム開発
├─ 4-9　アカウント・クラウド・アクセス権
├─ 4-10　保守・運用・納品後
└─ 4-11 【主な法令・公的資料・相談窓口】

まとめ：法律を知る目的は、トラブルになる前に気付くこと

第1章：ITエンジニアが知っておきたい法律・契約の基礎

法律・契約の話は、それだけで一冊の本になるほど広い分野です。
本稿では、法律を体系的に学ぶのではなく、後半の具体的なトラブル事例を理解するために必要な「共通言語」に絞って整理します。

特に、契約・請負と準委任・著作権・秘密保持・個人情報・OSS・損害賠償は、ITエンジニアが実務で遭遇しやすい基本項目です。

【第1章の構成】

第1章　ITエンジニアが知っておきたい法律・契約の基礎
├─ 1-1　なぜITエンジニアに法律・契約の知識が必要なのか
├─ 1-2　契約とは何か
├─ 1-3　請負・準委任・派遣の違い
├─ 1-4　契約書で最低限確認しておきたいこと
├─ 1-5　著作権・知的財産権と職務著作
├─ 1-6　NDA・秘密情報・営業秘密・個人情報の違い
├─ 1-7　OSS・外部サービス・ライセンスの注意点
├─ 1-8　損害賠償と契約解除の考え方
└─ 1-9　「契約書に書いてあれば絶対」とは限らない

1-1 なぜITエンジニアに法律・契約の知識が必要なのか

ITエンジニアに、弁護士のような法律知識が必要なわけではありません。
しかし仕事をしていると、

「このコードは流用してよいのか」
「この情報を外部サービスへ送ってよいのか」
「この追加作業は契約の範囲なのか」
「納品後、どこまで無料で修正する必要があるのか」

といった、技術だけでは判断できない場面に出会います。

会社員であれば、契約書は営業や法務が確認し、顧客との交渉も会社として対応できます。
ところが、副業やフリーランスとして個人で仕事を受けると事情は変わります。

仕事を探すのも自分。見積もるのも自分。契約するのも自分。納品するのも自分。請求するのも自分。そして、トラブルに対応するのも自分です。

つまりITエンジニアであると同時に、営業担当、経理担当、そして簡単な法務担当まで兼ねることになります。
必要なのは法律を詳しく暗記することではなく、どんな場面に法律や契約の問題が潜んでいるのかを知っておくことです。
知らなければ、問題があること自体に気付けません。

1-2 契約とは何か ―― 口頭・メール・チャットでも成立する

「契約書に署名していないから、まだ契約は成立していない」とは限りません。
民法では原則として、申込みに対して相手方が承諾したときに契約が成立します。一般的な業務委託であれば、紙の契約書や押印がなければ成立しないというものではありません。

たとえば、

「Excelで在庫管理ツールを5万円で作ってください」
「分かりました。来月末までに作ります」

というメールやDMのやり取りでも、その内容によっては契約が成立します。

では、なぜ契約書を作るのでしょうか。
大きな理由の一つは、「何を約束したのかを後から確認できるようにするため」です。
金額、納期、仕様、修正範囲について「そんな話は聞いていない」「最初から含まれていると思っていた」という争いを減らすためです。

ITエンジニアから見れば、契約書はある意味、「仕事そのものの仕様書」と考えると分かりやすいでしょう。

なお、フリーランス法の対象となる業務委託では、発注事業者には業務内容、報酬額、支払期日等を、書面またはメール・SNSのDM等の電磁的方法で明示する義務があります。口頭だけの明示では足りません。

公正取引委員会：フリーランス法特設サイト

1-3 請負・準委任・派遣の違い

IT業界では「業務委託」という言葉がよく使われます。契約内容は、主に請負や準委任として整理されます。
一方、労働者派遣は請負・準委任とは別の法的な仕組みですが、ITの現場では区別が非常に重要です。契約書のタイトルだけでなく、実際に誰が誰へ指揮命令しているか等の実態も確認する必要があります。

請負は、仕事を完成させることを目的とする契約です。
「この仕様の販売管理システムを完成させて納品する」といった仕事が典型です。

準委任は、一定の業務を適切に遂行することを目的とします。
「3か月間、要件定義を支援する」「システム運用業務を行う」などです。
ただし、成果物があれば必ず請負というわけではありません。契約全体として何を義務としているのかを見る必要があります。

見るところ	請負寄り	準委任寄り
契約目的	システム等の完成	開発支援・調査・運用等の遂行
報酬	完成・検収と結び付くことが多い	月額・時間・期間等と結び付くことが多い
成果物	完成品が中心	作業報告書等の場合もある
主な責任	契約した仕事を完成させる	善管注意義務をもって業務を遂行する

※この表は契約を読むときの着眼点です。「この文言があれば必ず請負」などと一文だけで決める判定表ではありません。

労働者派遣では、派遣先が労働者に指揮命令を行います。請負等の契約になっていても、実態として発注者が受託会社の労働者へ直接指揮命令していれば、いわゆる偽装請負が問題になる可能性があります。

厚生労働省：労働者派遣・請負を適正に行うためのガイド

1-4 契約書で最低限確認しておきたいこと

ITエンジニアが契約書を法律家のように読む必要はありません。
しかし、最低限、次の項目は確認しておきましょう。

項目	確認すること
業務範囲	何をするのか。逆に、何はしないのか。
成果物	プログラムだけか。ソースコード、設計書、マニュアルも含むか。
報酬・支払期日	いくらか。いつ支払われるか。
納期	いつまでに何を渡すか。
検収条件	何をもって完成・合格とするか。
仕様変更	追加作業が出た場合、金額・納期をどう変更するか。
知的財産権	プログラムの著作権は誰が持つか。
秘密保持・個人情報	どの情報をどのように扱うか。
再委託	他のエンジニアへ仕事を手伝わせてよいか。
損害賠償	問題が起きた場合、どこまで責任を負うか。
契約終了	途中終了や、終了後のデータ返却・削除をどうするか。

特に副業・フリーランスでは、業務範囲、検収、著作権、損害賠償は読み飛ばさないようにしましょう。

1-5 著作権・知的財産権と職務著作

プログラムも、創作性が認められれば著作権法上の著作物として保護されます。
ここでよくある誤解が、「自分が書いたコードだから、自分のもの」という考えです。

会社等の発意に基づき、その業務に従事する者が職務上作成したプログラムについては、一定の要件を満たせば会社等が著作者となる「職務著作」が成立します。
ただし、会社で作成したプログラムが常に職務著作になるわけではありません。法人等の発意、職務上の作成といった要件に加え、作成時の契約・勤務規則等に別段の定めがないことなども確認する必要があります。
なお、一般の職務著作では「法人等の名義で公表されること」も要件の一つですが、プログラムの著作物については、この公表名義の要件は不要です。

もう一つ重要なのが、「納品したこと」と「著作権を譲渡したこと」は別という点です。
制作を依頼されて報酬を受け取り、成果物を納品しただけで、当然に著作権まで発注者へ移るわけではありません。
著作権を制作者に残して利用を認める「利用許諾」と、著作権そのものを移す「著作権譲渡」は別です。
また、著作権を譲渡しても、著作者人格権は原則として著作者に残ります。ただし、プログラムについては、電子計算機で利用できるようにするため、またはより効果的に利用するために必要な改変など、同一性保持権が及ばない場合もあります。改変の可否は、契約内容や具体的な利用方法によって結論が変わります。

フリーランスの場合は、顧客専用部分と以前から自分が持っている汎用ライブラリや共通部品を分けておくことも重要です。

文化庁：著作権契約書作成支援システム・著作権の譲渡と利用許諾

1-6 NDA・秘密情報・営業秘密・個人情報の違い

似た言葉ですが、同じものではありません。

NDA（秘密保持契約）は、相手から受け取った秘密情報を第三者へ漏らしたり、目的外に利用したりしないこと等を約束する契約です。
秘密情報は、NDAや業務委託契約等で秘密情報として定められた情報や、その性質・開示された状況等から秘密として取り扱うべき情報です。
営業秘密は不正競争防止法上の概念で、秘密管理性・有用性・非公知性の要件を満たす情報を指します。
個人情報は、特定の個人を識別できる情報等です。
※個人情報保護法では「個人情報」「個人データ」「保有個人データ」を区別しており、第三者提供や委託先管理等では、どの概念に該当するかによって適用されるルールが異なります。本稿では読みやすさのため「個人情報」と総称する場合があります。

したがって、秘密情報＝個人情報ではありません。
ソースコードや未公開仕様書は秘密情報になり得ますが、必ずしも個人情報ではありません。逆に、アクセスログやテストデータ等にも個人情報が含まれる場合があります。

ITエンジニアは「データ」という一言でまとめず、その情報が何のルールによって守られているのかを意識する必要があります。

経済産業省：営業秘密を守り活用する
個人情報保護委員会

1-7 OSS・外部サービス・ライセンスの注意点

GitHubで公開されている。無料でダウンロードできる。だから自由に使ってよい。
これは危険です。

OSSは一般に、著作権を放棄したプログラムではありません。ライセンスの条件に従うことで、利用・改変・再配布等が認められます。

ライセンス	大まかな特徴
MIT / BSD	比較的制約は少ないが、著作権表示等が必要。
Apache 2.0	比較的緩やか。特許条項やNOTICEにも注意。
LGPL	ライブラリとの結合方法や、ライブラリ自体の改変・再配布条件等を確認する。
MPL	MPLの対象となるファイルの改変・配布等に条件がある。具体的な範囲はライセンス本文を確認する。
GPL	強いコピーレフト。結合・配布形態を確認する。
AGPL	ネットワーク経由で提供するサービスでも、ソースコード提供等の条件が関係する場合がある。

「GPLだから商用利用できない」という意味ではありません。
重要なのは、無料か有料かではなく、どの条件で利用できるのかです。
LICENSEがないからといって「何も書いていない＝自由に使える」とも限りません。

IPA：OSSの権利・ライセンスに関する解説

1-8 損害賠償と契約解除の考え方

副業で50万円のシステムを作った。そのシステムが停止して、顧客から「1000万円の売上を失った」と言われた。

実際にどこまで責任を負うかは、契約内容、原因、過失、損害との因果関係等によって変わります。
そこでIT契約では、損害賠償責任の上限を定める場合があります。

たとえば考え方として、

「故意又は重大な過失による場合を除き、本契約に基づく損害賠償責任の総額は、当該個別契約に基づき支払われた報酬総額を上限とする」

といった責任制限条項が考えられます。
ただし、これは条項の考え方を示す例であり、そのまま使用できる契約条項ではありません。BtoBかBtoCか、業務内容、損害の種類、故意・重過失の扱い等によって検討が必要です。特にBtoCでは、消費者契約法等により責任制限・免責条項がそのまま有効とは限りません。

契約解除についても、途中で終了できる条件、通知期間、途中までの作業への報酬、データ返却等を確認しておきましょう。

1-9 「契約書に書いてあれば絶対」とは限らない

法律・契約について学び始めると、「契約書に書いてあるなら絶対だ」と思いがちです。
しかし、強行法規に反する条項等、契約書に書いたからといって常にそのまま効力が認められるとは限りません。
また、契約書の一文だけでなく、契約全体の内容や実際の取引状況が重要になることもあります。

契約書は非常に重要。しかし万能ではない。

判断に迷う契約条項がある場合は、自己判断せず専門家に確認しましょう。

第2章：副業するITエンジニアが注意したいこと

会社員として働きながら、Excel・VBA・Webサイト・プログラム等を副業で制作することは珍しくなくなりました。
しかし、会社員としての仕事と個人の副業は、権利・情報・契約・設備を明確に分けて考える必要があります。

特にITエンジニアは、本業と副業で同じ技術・同じ業界・似たプログラムを扱いやすいため、境界が曖昧になりやすい点に注意が必要です。

【第2章の構成】

第2章　副業するITエンジニアが注意したいこと
├─ 2-1　会社員でも副業は自由なのか
├─ 2-2　本業で作ったコードやノウハウを副業で使ってよいのか
├─ 2-3　会社のPC・アカウント・AIサービスを副業に使うリスク
├─ 2-4　本業の取引先から個人的に仕事を受けてよいのか
├─ 2-5　副業では自分自身が「契約担当者」になる
└─ 2-6　ココナラ・クラウドソーシング等を利用するときの注意点

2-1 会社員でも副業は自由なのか

まず勤務先の就業規則・副業規程を確認しましょう。
厚生労働省は副業・兼業について環境整備を進めていますが、本業への支障、秘密保持、競業、企業の信用等の観点から一定の制限が問題となる場合があります。

特にITエンジニアは、本業と同じ技術を使い、同じ業界の顧客を相手にし、似たシステムを開発することが多いため、一般的な副業以上に本業との境界を意識する必要があります。

また、副業先でも雇用される場合と、個人事業として業務委託を受ける場合では適用されるルールが異なる部分があります。「副業」という言葉だけでなく、自分がどの立場で働くのかを確認しましょう。

厚生労働省：副業・兼業

2-2 本業で作ったコードやノウハウを副業で使ってよいのか

副業でプログラムを書いていて、「会社で作ったあの関数をコピーすれば早い」と思うことがあります。
しかし、自分が書いたコード＝自由に持ち出してよいコードではありません。

職務著作によって会社側が著作者となっている場合があります。
また、著作権とは別に、会社の秘密情報や営業秘密が含まれている可能性もあります。

VBAモジュール、SQL、API接続処理、設計書、テンプレート、テストデータ、業務マニュアル等も同様です。
副業では、本業の成果物と副業の成果物を明確に分離するのが基本です。

「自分で書いたものだから大丈夫」ではなく、誰の業務として作ったのかを考えましょう。

2-3 会社のPC・アカウント・AIサービスを副業に使うリスク

会社支給PCで副業する。会社契約のMicrosoft 365を使う。会社のGitHubアカウントに副業コードを保存する。会社が契約する生成AIを副業でも利用する。

技術的にはできても、会社の利用規程やセキュリティポリシーに反する可能性があります。
また、本業と副業のデータが混ざることで「このコードは誰のものか」「このファイルは誰の顧客情報なのか」が分からなくなる危険もあります。

可能な限り、副業用PC、アカウント、クラウド環境を分離しましょう。

2-4 本業の取引先から個人的に仕事を受けてよいのか

本業の顧客から、「会社を通すと高いから、休日に個人的に作ってくれない？」と言われた。

これは特に慎重に判断すべきケースです。
会社と顧客との契約、顧客情報の利用、競業、利益相反、会社の信用等、複数の問題が関係します。

「勤務時間外にやるから会社とは関係ない」とは限りません。
本業を通じて知り得た顧客や案件を、そのまま個人の商売へ移す行為は特に注意が必要です。

2-5 副業では自分自身が「契約担当者」になる

会社員として開発していると、「営業が取ってきた案件を作る」だけで済むことがあります。
しかし副業では、「いくらでできますか」「来週までにできますか」「この修正も料金内ですよね」「バグだから無料ですよね」といった交渉も自分で行います。

開発を始める前に条件を決めること自体が仕事です。
特に重要なのは、何をやるのかだけでなく、何をやらないのかを明確にすることです。

「Excelツール一式」ではなく、「CSV取込、集計、帳票1種類。データ移行、マニュアル作成、将来のExcel更新への対応は含まない」など、範囲を具体化するとトラブルを減らせます。

2-6 ココナラ・クラウドソーシング等を利用するときの注意点

プラットフォームを利用すれば、自分で一から契約書を作らなくても仕事を始められる場合があります。
しかし、契約を意識しなくてよくなるわけではありません。

依頼者との合意に加えて、納品、検収、追加料金、キャンセル、返金、手数料等について、プラットフォーム独自の利用規約・取引フローが関係します。

特に追加作業については、正式な追加購入・追加決済を確認する前に作業を始めると、後から「その料金は払わない」となる可能性があります。

サービスの規約は変更されるため、利用時点の最新ルールを確認しましょう。

第3章：フリーランスITエンジニアが注意したいこと

フリーランスになるということは、単に会社を辞めて自由に働くというだけではありません。
自分自身が一つの事業者となり、営業・見積・契約・開発・納品・請求・代金回収・トラブル対応まで管理することになります。

この章では、個人でITの仕事を受けるときに、特にトラブルになりやすい契約・報酬・検収・著作権・保守・記録について整理します。

【第3章の構成】

第3章　フリーランスITエンジニアが注意したいこと
├─ 3-1　フリーランスになると何が変わるのか
├─ 3-2　仕事を受ける前に決めておくべき条件
├─ 3-3　見積書・発注書・契約書は何が違うのか
├─ 3-4　「ついでにこれも」という追加作業をどう扱うか
├─ 3-5　「納品」「完成」「検収」の違い
├─ 3-6　報酬が支払われないとき ―― フリーランス法・取適法
├─ 3-7　著作権の「譲渡」と「利用許諾」は何が違うのか
├─ 3-8　納品後のバグ修正・保守はどこまで無料なのか
└─ 3-9　契約も仕様も「ログ」を残す

3-1 フリーランスになると何が変わるのか

フリーランスになるとは、自分自身が一つの事業者になるということです。

案件を探す。見積もる。条件を交渉する。契約する。開発する。納品する。請求する。代金を回収する。
会社員なら複数部署が分担していた仕事を、自分で行うことになります。

つまり、技術力だけでは仕事は完結しません。
契約・報酬・権利・情報管理まで含めて、自分の仕事として管理する必要があります。

3-2 仕事を受ける前に決めておくべき条件

「Excelで在庫管理システムを作ってください」だけでは、仕様として不十分です。

対応Excelバージョン。WindowsだけかMacも含むか。機能範囲。データ移行の有無。マニュアルの有無。無料修正回数。納品後の対応期間。

小さな案件ほど「そこまで決めなくても大丈夫」と思いがちですが、決めなかったところほど後で揉めます。

仕事を受ける前に、何をやるのかだけでなく、何をやらないのかも明確にしておきましょう。

3-3 見積書・発注書・契約書は何が違うのか

見積書は単なる金額表ではありません。
何をその金額に含めているのかを書く重要な資料です。

たとえば「Excel VBA開発 100,000円」だけよりも、CSV取込、月次集計、帳票1種類、修正2回まで、納品後30日間の不具合修正などと書いてあった方が、後のトラブルを減らせます。

発注書は、発注者が正式に仕事を依頼したことを示すために使われます。
契約書では、権利関係、秘密保持、損害賠償、解除等、より広い条件を定めることができます。

小さな仕事でも、何も残さないのが一番危険です。

3-4 「ついでにこれも」という追加作業をどう扱うか

IT案件では追加作業が頻繁に発生します。

「ボタンを一個増やすだけ」
「帳票をもう一種類」
「CSVだけでなくPDFでも出したい」

一つ一つは小さくても、積み重なれば大きな作業です。
重要なのは追加依頼を断ることではなく、追加作業を追加作業として扱うことです。

「対応可能です。ただし当初見積の範囲外となるため、追加○万円、納期を○日変更します」と確認してから着手するだけでも状況は大きく変わります。

3-5 「納品」「完成」「検収」の違い

プログラムファイルを顧客へ送った。これは「納品」です。
しかし、それだけで契約上「仕事が完成した」と扱われるかは契約内容によります。
さらに、顧客が内容を確認して受け入れる手続きが「検収」です。

ここが曖昧だと、

制作者：「納品しました」
顧客：「まだ完成ではありません」
制作者：「仕様通りです」
顧客：「想像していたものと違います」

という状態になります。
何をもって検収合格とするのか、何日以内に確認するのか、修正が必要な場合にどう通知するのかを、できるだけ事前に決めておきましょう。

3-6 報酬が支払われないとき ―― フリーランス法・取適法

2024年11月1日に施行されたフリーランス法では、義務ごとに適用される発注者や取引期間等の要件が異なります。
フリーランスへ業務委託をした場合の取引条件の明示義務は広く適用されます。一方、給付を受領した日（役務提供委託では役務の提供を受けた日）から原則60日以内のできる限り短い期間に支払期日を設定し、定めた期日までに支払う義務等は、従業員を使用する事業者など「特定業務委託事業者」に課されます。

また、特定業務委託事業者が1か月以上の業務委託を行う場合には、受領拒否、報酬の減額、不当なやり直し等の7つの禁止行為が適用されます。さらに6か月以上の業務委託では、中途解除・不更新について原則30日前までの予告や、求められた場合の理由開示が必要となる場合があります。

さらに2026年1月1日から、従来の下請法は改正され、法律名は「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」となりました（略称：中小受託取引適正化法、通称：取適法）。対象となる取引では、価格協議や支払方法等についてもルールがあります。
改正では、従来の資本金基準に加えて従業員数基準が追加され、対象となる取引では、受注者からの価格協議の求めに応じず一方的に代金を決定する行為や、手形払等が禁止されています。

ただし、フリーランス法も取適法も、すべてのフリーランス・すべての取引に一律に適用されるわけではありません。どの義務・禁止行為が適用されるかは、発注者の属性、取引期間、取引内容等によって確認する必要があり、単純に「会社だから適用される」「個人事業主だから適用されない」と判断できるものではありません。

公正取引委員会：フリーランス法特設サイト
公正取引委員会：取適法

3-7 著作権の「譲渡」と「利用許諾」は何が違うのか

利用許諾なら、著作権を自分に残したまま「この範囲なら使ってよい」と顧客に認めることができます。
著作権譲渡は、著作権そのものを相手へ移します。

著作権を譲渡すると、元の著作者でも、その後自由に利用できなくなる場合があります。
なお、著作権を譲渡する契約で、著作権法27条（翻訳権・翻案権等）または28条（二次的著作物の利用に関する原著作者の権利）が譲渡の対象として特に明記されていない場合、これらの権利は譲渡者に留保されたものと推定されます。どこまで権利を移すのかは、契約書で明確にしておくことが重要です。

たとえば、顧客専用の画面・業務ロジックは顧客へ譲渡する一方、自分が以前から保有している共通ライブラリや汎用関数は自分に権利を残す、といった整理も考えられます。

プログラム設計上の「共通部品化」は、契約上の権利整理にもつながります。

3-8 納品後のバグ修正・保守はどこまで無料なのか

顧客から「動かなくなったから直してください」と言われた。
しかし原因によって意味は違います。

納品時から仕様を満たしていなかった。
新しい機能が欲しくなった。
顧客がファイル構成を変更した。
WindowsやExcelが更新された。
外部APIの仕様が変更された。

これらをすべて「バグだから無料」と扱えば、仕事はいつまでも終わりません。
不具合修正の期間、保守対応の有無、環境変更への対応、追加機能の扱いを、できるだけ最初に決めておきましょう。

3-9 契約も仕様も「ログ」を残す

エンジニアはシステム障害が起きればログを確認します。
契約トラブルでも同じです。
誰が、いつ、何を決めたのかを後から追えるようにしておきます。

オンライン会議で仕様変更が決まったなら、終了後に、

「本日の打合せでは、CSV出力機能を追加し、追加費用○万円、納期○月○日とする認識です。問題なければご返信ください」

と送る。

メール、Slack、Teams、Issue、チケット、Gitのコミット、仕様書の変更履歴、見積書の版管理等は、経緯を説明する材料になります。
ただし、Gitのコミット履歴があるだけで、顧客が仕様変更を承認したことになるわけではありません。重要な条件変更は、相手から明示的な確認を取る方が安全です。

契約も仕様もログを残す。
ITエンジニアにとって覚えやすい原則です。

第4章：こんなときどうする？ ITエンジニアの法律・契約トラブル事例集

ここからは、ITエンジニアが実際に遭遇しそうな法律・契約トラブルを、50のケースに分けて見ていきます。

本サイトはExcel・VBAを中心に扱っているため、まずExcel・VBA案件で起こりやすいトラブルから取り上げます。その後、契約、報酬、著作権、秘密情報、生成AI、OSS、再委託、クラウド、保守へと範囲を広げます。

個々のケースは、少し条件が変わるだけで結論が変わる場合があります。ここで重要なのは「このケースなら絶対にこうなる」と暗記することではなく、どの論点を確認する必要があるのかを知ることです。
同じように見える事例でも、契約内容、権利関係、当事者の立場、対象となる情報、利用目的・方法、実際の運用状況等によって、適用される法律や結論が異なる場合があります。本章は個別事例の法的結論を断定する「結論集」ではなく、何を確認すべきかを知るための事例集として読んでください。

【第4章の構成】

4-1 Excel・VBA案件で起こりやすいトラブル

Excel・VBAは、ファイルをそのまま配布・コピーでき、利用者自身がシートやVBAを変更できるため、一般的なシステム開発とは少し違うトラブルが起こります。
特に、VBAプロジェクトのパスワード、32bit／64bit・Windows／Macといった実行環境、Windows・Officeの更新、利用者によるシートやVBAの改変、ファイルの社内コピー、機密情報の埋め込みなどは、Excel案件で実際に起こりやすい問題です。

これらは単なる技術トラブルに見えても、納品物は何か、誰が改変できるのか、どの環境まで保証するのか、どこまで無償保守するのかという契約問題につながります。Excel・VBA専門サイトとして、本節は他の分類より少し詳しく取り上げます。

なお、マクロのセキュリティ設定によって実行がブロックされる問題は、法律・契約問題というより導入・運用上の問題であることが多いため、本事例集では独立ケースとはせず、納品時に必要な実行環境や利用方法を説明しておくべき事項として扱います。

※この節の注意
VBAのパスワード、解除、改変、第三者保守の可否は、著作権だけで決まるものではありません。契約、利用許諾、成果物・ソースコードの納品範囲、作成経緯、具体的な目的・方法等によって結論が変わる場合があります。

【ケース01】VBAプロジェクトにパスワードを掛けて納品したら、解除を求められた

状況
VBAコードの誤操作防止やソースコード保護のため、VBAプロジェクトにパスワードを設定してExcelツールを顧客へ納品した。しばらくして顧客から「社内で修正したい」「別の業者へ保守を引き継ぎたいので、パスワードを教えてほしい」と求められた。
何が問題か
Excel・VBAでは非常によく起こる問題です。まず、Excelファイルを納品したこと、ソースコードを納品したこと、著作権を譲渡したこと、顧客に自由な改変を認めたことは、それぞれ別の話です。パスワードを設定しただけで開発者の権利が強くなるわけでも、逆に顧客がファイルを所有しているだけでVBAを自由に改変できるわけでもありません。
ただし、プログラムの複製物を適法に所有する者には、著作権法上、自己利用に必要な範囲で複製・翻案が認められる場合もあります。ファイルの所有、著作権、契約上の改変可否は、それぞれ分けて確認する必要があります。
一方、契約書や見積書で「VBAソースを含めて納品する」「顧客が自社で改変できる」「第三者へ保守を引き継げる」等を約束していたのであれば、パスワードを開示しないことで、合意した利用や保守移行を事実上妨げることが問題になる場合があります。また、契約に何も書かれていないと、開発者は「実行できれば納品完了」、顧客は「代金を払ったのだから中身も自由に触れる」と考え、認識が食い違いやすくなります。
関係する法律・契約
著作権、利用許諾、著作権譲渡、改変の可否、成果物・納品物の範囲、保守契約、契約終了時の引継ぎ。
どう考えるか
パスワードを設定するかどうかより、契約上の権利と納品範囲を先に決めることが重要です。少なくとも、(1) VBAソースは納品対象か、(2) パスワードを顧客へ開示するか、(3) 顧客自身の改変を認めるか、(4) 別の開発者・会社へ保守を依頼してよいか、(5) 顧客側で改変した後の不具合を誰が負担するか、を事前に決めておくとよいでしょう。
例えば「VBAの閲覧・改変は可。ただし顧客または第三者による改変後の動作保証はしない」「パスワードは納品時に顧客へ通知する」「ソースコードは納品対象外」といった整理が考えられます。
VBAプロジェクトのパスワードそのものが、著作権や利用権の範囲を決めるわけではありません。技術上の保護と、法律・契約上の権利を分けて考える必要があります。

【ケース02】「このVBAパスワードを解除して」と依頼された

状況
顧客から「以前の担当者が作ったExcelがあるが、VBAプロジェクトにパスワードが掛かっていて修正できない。解除して中身を直してほしい」と依頼された。顧客は「当社で使っているファイルだから問題ない」と説明しているが、誰が開発したものか、どのような契約だったかははっきりしない。
何が問題か
これもExcel・VBAではよくある依頼ですが、技術的に解除できるかどうかより先に、依頼者がそのVBAを閲覧・解析・改変する権限を持っているかを確認する必要があります。会社で使っているファイルでも、外部業者から利用許諾だけを受けている場合、ソースコードの改変や第三者への解析依頼が契約で制限されている場合があります。逆に、社内の従業員が職務上作成したプログラムで職務著作の要件を満たす場合や、著作権・改変権を会社が取得している場合もあります。
つまり「ファイルを持っている」「代金を払った」「社内で長年使っている」という事実だけでは、解除・改変してよいかまでは判断できません。
関係する法律・契約
著作権、職務著作、利用許諾、著作権譲渡、改変権限、業務委託契約、秘密保持、第三者への保守委託。
どう考えるか
依頼を受ける前に、誰が作成したのか、元の開発会社との契約書・見積書・発注書等が残っていないか、ソースコードの改変や第三者保守が認められているかを確認します。可能であれば、依頼者から「当該プログラムを解析・改変する権限を有している」ことを書面やメールで確認しておく方法もあります。
権利関係が分からないまま「解除できるから解除する」のは避け、必要なら元の開発者・権利者への確認や、弁護士等の専門家への相談を依頼します。権限がない可能性が高い、著作権や契約上の権利を侵害するおそれがあると分かっているのに解除を求められている等、疑問が解消しない場合は受注しない判断も必要です。
なお、著作権法では、プログラムの著作物の複製物の所有者について、自らそのプログラムを電子計算機で実行するために必要と認められる限度で複製・翻案が認められる場合があります。また、プログラムの調査解析（リバースエンジニアリング）が、一定の条件の下で著作権侵害とならない場合もあります。そのため、「著作権を譲り受けていない＝解析・改変は常に不可」と一律には判断できません。
ただし、これらの規定があるからといって、第三者によるVBAパスワードの解除や改変が一般的に許されるわけではありません。依頼者の権限、元の契約内容、改変・調査解析に関する特約、第三者への保守委託の可否、具体的な目的・方法等を確認する必要があります。
なお、本稿ではVBAパスワードを解除する具体的な技術手順ではなく、その作業を依頼されたときに確認すべき権利関係を問題にしています。

【ケース03】前任者が作ったExcelマクロを改造した

状況
社内で長年使われているExcelマクロについて、「前任者が作ったものだから自由に直してよい」と説明され、機能追加を行った。ところが後から、実際には外部の開発会社へ依頼して作成したものだったことが分かった。
何が問題か
Excelファイルは社内共有フォルダー等に残り続けるため、作成者や契約の経緯が分からなくなりやすい特徴があります。社内で使っていることと、会社が著作権や自由な改変権限を持っていることは同じではありません。また、前任者が従業員として職務上作成したものなのか、個人的に作ったものなのか、外注品なのかによっても扱いが変わります。
関係する法律・契約
職務著作、著作権譲渡、利用許諾、業務委託契約、第三者ソフトウェアのライセンス。
どう考えるか
改造前に、作成者、契約書・見積書・請求書、過去のメール、納品資料等を確認します。外注品なら、ソースコードの納品や改変、第三者保守が許されているかを確認します。
また、Excelファイルの中に外部ライブラリや第三者コードが含まれている場合もあるため、「社内にある古いファイルだから自由に直してよい」と決めつけないことが大切です。プログラムの来歴を管理しておくこと自体が、将来の保守リスクを減らします。

【ケース04】副業で本業のVBAコードを流用した

状況
副業案件で必要な処理が、本業で作成したVBAとほぼ同じだった。自分が書いたコードなので問題ないと思い、会社のExcelからVBAモジュールをコピーして副業案件へ組み込んだ。
何が問題か
「自分が書いたコード」と「自分が自由に持ち出して再利用できるコード」は同じではありません。会社等の発意に基づき職務上作成したプログラムは、職務著作の要件を満たせば会社等が著作者となる場合があります。また、コードそのものだけでなく、業務ロジック、顧客固有の処理、設計ノウハウ等が秘密情報・営業秘密に当たる可能性もあります。
関係する法律・契約
職務著作、著作権、秘密保持義務、営業秘密、就業規則、副業規程、競業に関するルール。
どう考えるか
本業のソースコードやファイルを副業環境へコピーしないことを基本にします。同じ一般的な処理が必要なら、本業のコードを見ながら複製するのではなく、副業案件として独立して設計・実装します。
ただし、単に書き直せば必ず問題がなくなるわけではありません。本業で知った顧客固有情報や非公開の業務ロジックを利用していないかも確認します。一方、一般的なExcel/VBAの知識・経験まで使えなくなるわけではないため、一般的な技能と会社固有の成果物・秘密情報を切り分けることが重要です。

【ケース05】納品したExcelが顧客環境（32bit／64bit・Windows／Mac）では動かなかった

状況
開発者のWindows版・64bit Excelでは正常に動作していたが、納品先では32bit Excelを使用していた、またはMac版Excelで使用しようとしたため、一部機能やVBAが動かなかった。顧客から「Excelで動くと聞いていたのに使えない」と修正を求められた。
何が問題か
32bit／64bit、Windows／Mac、Excel・Officeのバージョンによって、Windows API、ActiveX、外部DLL、参照設定等の利用可否が異なる場合があります。対応環境は単なる技術情報ではなく、成果物の仕様・検収条件の一部です。顧客環境を確認せずに「Excelなら動く」と受注した場合には、開発者側の確認不足が問題になりやすくなります。
関係する法律・契約
仕様書、見積条件、対応環境、検収条件、契約不適合、追加作業・保守条件。
どう考えるか
受注前に、OS、Excelの種類・バージョン、32bit／64bit、Mac対応の要否、利用する外部ライブラリ等を確認し、見積書や仕様書へ記載します。可能なら顧客の実環境または同等環境で検収前に確認します。
「Windows 11＋Microsoft 365 64bitのみ対応。Mac版Excelは対象外」のように書いておけば、責任範囲が明確になります。逆に対応環境を何も確認せず納品した場合には、「顧客環境の問題」と一方的に片付けるのは難しいでしょう。

【ケース06】納品したExcelがWindowsやOfficeのアップデート後に動かなくなった

状況
納品時には正常に動作していたExcel・VBAツールが、後日のWindows UpdateやMicrosoft 365・Officeの更新後に動かなくなった。顧客から「納品したプログラムなのだから無料で直してほしい」と連絡が来た。
何が問題か
納品時から存在していた不具合なのか、納品後の環境変更によって新たに発生した問題なのかで意味が異なります。納品時に合意した環境で正常に動作することと、将来のWindows・Office更新にも永久に追随することは別です。
ただし、一般的な更新で容易に壊れる実装、既に非推奨となっていた機能への過度な依存等が原因であれば、設計・検証の妥当性も確認する必要があります。
関係する法律・契約
対応環境、保証期間、検収条件、保守契約、契約不適合、追加作業。
どう考えるか
納品時に検証したWindows・Excel環境を記録し、保証期間と保守範囲を決めます。「将来のOS・Office更新に伴う改修は保守契約または別途見積り」と整理する方法があります。
問題発生時は、まず更新前の環境でも再現するかを確認し、元からあった不具合なのか、環境変更によるものなのかを切り分けます。技術原因の切り分けと契約上の責任範囲の確認を同時に行うことが重要です。

【ケース07】顧客がシート名を変更・途中列に列を挿入したら動かなくなった

状況
納品後、顧客が「売上」シートの名前を変更したり、データ表の途中へ新しい列を挿入したところVBAが動かなくなり、「壊れたので無料で直してほしい」と連絡が来た。
何が問題か
利用者が仕様上の前提を変更した場合の責任範囲が問題になります。一方、固定の列番号やシート名へ必要以上に依存する実装だったなど、通常予想できる利用者の変更に耐えられない設計が原因の場合には、開発側の設計品質も問題になります。Excelは利用者が簡単に表構造を変更できるため、一般のシステムより境界が曖昧になりやすいところです。
関係する法律・契約
仕様書、利用条件、操作マニュアル、検収条件、保証範囲、保守契約。
どう考えるか
変更してはいけないシート名・列構成・セル範囲等があるなら、仕様書や操作説明で明示し、必要に応じてシート保護等で誤操作を防ぎます。一方で、名前定義やテーブル、見出し名を使う等、変更に強い設計が合理的に可能だったかも検討します。
「顧客が触ったから全部顧客責任」「Excelだから自由に変更できて当然」という二択ではなく、どこまでを変更可能な仕様としていたかで考えます。

【ケース08】顧客がVBAを改造した後に無償修正を求められた

状況
納品後、顧客の担当者や別の開発者がVBAコードを独自に変更した。その後エラーが発生し、元の開発者へ「元々あなたが作ったプログラムだから無料で直してほしい」と依頼された。
何が問題か
顧客に改変権限があることと、改変後のプログラムまで元の開発者が無条件に保証することは別です。誰の変更によって不具合が発生したのか分からない場合、原因調査だけでも相応の作業が必要になります。一方、顧客による改変を認めながら保証条件を何も決めていなければ、後から認識が食い違いやすくなります。
関係する法律・契約
利用許諾・改変権限、保証条件、保守契約、追加作業、責任分界。
どう考えるか
契約や保守条件に「顧客または第三者による改変後は動作保証の対象外」「改変後の調査・復旧は別途見積り」等を定めておく方法があります。開発者側でも納品時点の最終版を保管し、問題が発生したときに納品版で再現するか確認できるようにしておくと切り分けが容易です。
なお、顧客に改変を認める場合は、ケース01のパスワード開示や第三者保守の扱いとも一緒に決めておくと整合が取れます。

【ケース09】納品したExcelファイルが別部署へコピーされ、利用範囲が拡大した

状況
総務部だけで使用する前提で作成したExcel・VBAツールが、便利だからという理由で営業部、経理部、支店等へ次々コピーされた。その後、それぞれの部署から個別の問い合わせや機能追加を求められるようになった。
何が問題か
Excelはファイルをコピーするだけで簡単に展開できるため、当初想定した利用者・利用部署が知らないうちに広がりやすい特徴があります。ここでは、プログラムを利用できる範囲と、開発者が無償で保守・サポートする範囲は別であることが重要です。また、契約によっては利用許諾そのものを特定部署・端末・拠点等に限定している場合もあります。
関係する法律・契約
著作権、利用許諾、利用範囲、保守契約、追加業務、ライセンス条件。
どう考えるか
「顧客企業内なら自由にコピー可」「特定部署のみ」「端末数○台まで」等、必要に応じて利用範囲を決めます。それとは別に、問い合わせ窓口、サポート対象部署、追加機能の料金を明確にします。
社内利用を広く許可する契約でも、全社からの問い合わせまで当初報酬に含まれるとは限りません。利用許諾と保守サービスを分けて考えることがポイントです。

【ケース10】納品したExcelファイルが社外流出し、VBA等に埋め込んだ機密情報・個人情報まで漏れた

状況
納品したExcelファイルがメールの誤送信や共有設定のミス等で社外へ流出した。ファイル内のVBAコード、非表示シート、セル等には、DB接続文字列、ユーザーID、パスワード、APIキー、顧客情報等が直接保存されていた。
何が問題か
Excelファイルは容易に複製・転送できます。VBAプロジェクトのパスワード、シートの非表示、シート保護等だけを機密情報を安全に保存する仕組みとして考えるのは危険です。流出した情報によっては、顧客とのNDAや情報セキュリティ条件に加え、個人情報保護上の対応が必要になる場合があります。
また、ファイルを流出させたのが顧客側であっても、そもそも秘密情報を平文で埋め込む設計が妥当だったかという開発側の問題が残ることがあります。
関係する法律・契約
NDA・秘密保持、個人情報保護、情報セキュリティ条項、委託契約、損害賠償、インシデント対応。
どう考えるか
パスワード、APIキー、接続情報等をVBAへ安易にベタ書きしないことを基本にし、必要に応じて適切な認証・秘密情報管理の仕組みを利用します。テスト用データを残したまま納品しないことも重要です。
納品時には「ファイル自体が社外へ出た場合、内部情報も見られる可能性がある」という前提で設計します。実際に個人情報等の漏えいが発生した場合には、情報の種類・件数・影響等によって必要な対応が異なるため、顧客の情報管理部門や弁護士等の専門家、個人情報保護委員会等の最新情報を確認します。

4-2 契約・発注・仕様変更

契約の入口での認識違いは、その後の開発全体に影響します。
「誰と契約したのか」「何を作るのか」「どこまでが追加なのか」を曖昧にしないことが基本です。

【ケース11】契約書を作らず、チャットだけで開発を始めた

状況
「簡単なツールだから」とDMだけで作業を開始。後になって、金額・納期・修正回数について認識が食い違った。
何が問題か
契約書がないことより、何に合意したのかを後から確認しにくいことが問題です。
関係する法律・契約
契約成立、取引条件、証拠・記録。
どう考えるか
小規模案件でも、業務内容、金額、納期、修正範囲、支払期日等を文章で残します。フリーランス法の対象取引では、発注者側に取引条件の明示義務があることにも注意します。

【ケース12】誰と契約しているのか分からない

状況
A社から紹介されたB社の案件で仕事をしていた。報酬が支払われずA社へ連絡すると、「契約相手は当社ではない」と言われた。
何が問題か
多重委託の中で、誰が発注者で、誰に報酬支払義務があるのかが曖昧です。
関係する法律・契約
契約当事者、業務委託契約、発注書。
どう考えるか
作業開始前に、契約相手の正式名称、支払者、連絡窓口を確認します。IT業界の多重下請構造では特に重要です。

【ケース13】法律・利用規約上問題がありそうな依頼を受けた

状況
顧客から、「他人のIDで自動ログインしたい」「アクセス制限を回避してデータを取りたい」「他社の画像や文章を大量に取り込んで使いたい」など、法律や利用規約上問題がありそうな機能を作ってほしいと依頼された。顧客からは「責任はこちらで持つから、言われた通り作ってくれればよい」と言われた。
何が問題か
発注者から依頼されたことだけを理由に、開発者側が何も確認せず実装してよいとは限りません。依頼内容によっては、著作権、個人情報、不正アクセス、サービス利用規約、秘密保持等の問題が関係します。「顧客が責任を持つ」と言われたことだけで、開発者側の問題が当然になくなるわけではありません。
また、「何となく怪しい」段階と、明らかに権限のないアクセスや権利侵害を目的としている場合では対応も異なります。他人のID・パスワードを権限なく利用することや、アクセス制御を回避する方法によっては、不正アクセス禁止法上の問題が生じる場合があります。
関係する法律・契約
依頼内容に応じて、著作権法、不正アクセス禁止法、個人情報保護法、秘密保持契約、対象サービスの利用規約等。
どう考えるか
まず、何を・誰の権限で・どのデータに対して行う仕組みなのかを具体的に確認します。顧客に権限・許諾の有無を確認し、必要なら対象サービスの規約やライセンスを確認します。判断が難しい場合は、顧客側の法務部門や弁護士等の専門家による確認を求めます。
問題が解消しない場合や、権限のないアクセス・権利侵害等を目的とする可能性が高い場合には、受注しない、または問題のある機能を実装しないという判断も必要です。
警察庁：不正アクセス対策

【ケース14】「この機能もちょっと追加して」と言われた

状況
簡単そうだったので無料で対応したところ、その後も追加依頼が続いた。
何が問題か
当初の業務範囲と追加作業の境界が曖昧になっています。
関係する法律・契約
業務範囲、追加契約、報酬、納期。
どう考えるか
追加依頼が来た時点で当初の範囲内かを確認し、範囲外なら金額・納期について合意してから着手します。

【ケース15】完成後に「イメージと違う」と全部やり直しになった

状況
仕様に沿って完成させたが、顧客から「思っていたものと違う」と全面的な作り直しを要求された。
何が問題か
書面上の仕様と、顧客が頭の中で想定していた完成像に差があります。
関係する法律・契約
仕様書、検収条件、追加変更、不当なやり直しの問題。
どう考えるか
要件定義・画面イメージ・プロトタイプ等を途中で確認してもらい、変更点は記録します。フリーランス法上の7つの禁止行為が適用される取引（一定の発注事業者による1か月以上の業務委託）では、不当なやり直しが禁止行為となる場合もあります。

【ケース16】納品したのに「まだ完成していない」と言われた

状況
制作者は「仕様通り完成」と考えているが、顧客は「欲しかったものと違う」と検収しない。
何が問題か
完成・検収の基準が共有されていません。
関係する法律・契約
請負契約、仕様書、成果物、検収条件。
どう考えるか
何をもって完成とするか、どの仕様書を基準とするか、検収期間を何日とするかを契約時に定めます。

【ケース17】客先から直接細かく作業指示を受けている

状況
契約は業務委託だが、客先担当者から毎日「今日はこれをして」「明日は9時に来て」と直接指示されている。
何が問題か
契約名と実態が食い違っている可能性があります。受託会社の社員に対して発注者が直接指揮命令している場合は、請負と派遣の区分や、いわゆる偽装請負が問題となることがあります。一方、個人フリーランス本人が強い指揮命令を受けている場合は、契約名が業務委託でも、働き方の実態から労働者性が問題となる場合があります。
関係する法律・契約
労働者派遣法、請負と派遣の区分、労働者性、業務委託契約。
どう考えるか
契約名称だけでなく実態が重要です。受託会社の社員であれば自社の管理者に相談し、適正な指揮命令系統を確認します。個人フリーランスの場合も、業務の進め方、時間・場所の拘束、指揮命令の程度、報酬の性質等の実態によって判断が変わるため、一律に「業務委託だから問題ない」とは考えません。

4-3 報酬・支払い・損害賠償

フリーランスにとって、報酬の回収は生活そのものに直結します。
支払期日、途中終了、減額、損害賠償は、仕事を始める前に確認しておきたい重要項目です。

※この節の注意
フリーランス法・取適法の適用は、発注者の属性、取引内容、取引期間等によって異なります。各ケースでは代表的な論点を示していますが、実際にどの義務・禁止行為が適用されるかは個別に確認する必要があります。

【ケース18】仕事をしたのに報酬が支払われない

状況
納品済みなのに「経理処理が遅れている」「請求書が届いていない」と支払いが延び続ける。
何が問題か
支払期日が守られていません。
関係する法律・契約
契約上の支払義務、フリーランス法等。
どう考えるか
契約、納品、検収、請求、督促の記録を残します。フリーランス法上の報酬支払義務が適用される取引では、請求書提出の有無にかかわらず、定めた支払期日までの支払いが求められます。

【ケース19】「元請から入金されていないから、あなたにも払えない」と言われた

状況
自分は契約通り作業したが、委託元から「上位会社からまだ入金されていない」と支払いを止められた。
何が問題か
自分と契約相手との支払関係と、契約相手が上位会社から入金を受けたかは通常別の関係です。
関係する法律・契約
契約上の支払期日、再委託、フリーランス法。
どう考えるか
自分の契約相手と支払期日を確認します。フリーランス法では、再委託である旨、元委託者の名称、元委託業務の対価の支払期日等を明示した場合に、元委託業務の支払期日から30日以内のできる限り短い期間を支払期日とできる例外があります。これは「元請から実際に入金された日」を基準に無期限に支払いを延ばせる仕組みではありません。

【ケース20】契約途中で辞めたら「報酬はゼロ」と言われた

状況
3か月の開発支援を1か月半行った後、事情により契約を終了したところ「最後までやっていないから一円も払わない」と言われた。
何が問題か
途中終了時に、それまでの業務に対する報酬をどう扱うかが問題です。請負か準委任かによっても論点が異なります。
関係する法律・契約
準委任・請負、解除、途中報酬。
どう考えるか
契約締結時に、中途解約、通知期間、途中までの報酬の計算方法を確認します。紛争になった場合は個別事情が重要なため専門家へ相談します。

【ケース21】報酬から勝手に「損害分」を引かれた

状況
報酬30万円のはずが、「先月のミスで損害が出たので10万円引いた」と20万円だけ振り込まれた。
何が問題か
損害賠償の有無・金額の問題と、合意済み報酬を一方的に減額する問題は分けて考える必要があります。
関係する法律・契約
損害賠償、相殺、報酬減額、フリーランス法・取適法が適用される場合の禁止行為。
どう考えるか
減額理由と法的根拠を確認し、契約・作業記録を保存します。フリーランス法や取適法が適用される取引では、発注後の一方的な報酬・代金の減額が禁止行為となる場合があります。ただし、損害賠償請求や相殺の可否は別の論点であり、契約内容や具体的事情によって判断が変わります。金額が大きい場合は早い段階で専門家に相談します。

【ケース22】仕事開始直前に案件をキャンセルされた

状況
「来月から3か月空けてください」と言われて他案件を断ったが、開始直前に「案件がなくなりました」と言われた。
何が問題か
中途解除・キャンセルによって、フリーランス側に予定していた収入や機会の損失が生じます。
関係する法律・契約
契約解除、キャンセル条件、フリーランス法の中途解除等の事前予告・理由開示。
どう考えるか
開始前キャンセルを含む解除条件を契約で確認します。この例のような3か月の業務委託では、フリーランス法の「6か月以上の業務委託」に対する30日前予告義務が当然に適用されるわけではありません。まず、契約が成立していたか、キャンセル・解除についてどのように定めていたか、それまでに生じた損害等を確認します。
なお、6か月以上の継続的な業務委託では、フリーランス法上、中途解除や不更新について原則30日前までの予告や、求められた場合の理由開示が必要となる場合があります。

【ケース23】50万円の仕事で1000万円の損害賠償を請求された

状況
副業で50万円のシステムを作ったところ、障害が発生し、顧客から「1000万円の損害が出た」と請求された。
何が問題か
契約金額と損害賠償額が自動的に同じになるわけではありません。一方、請求された額をそのまま支払う義務が当然に生じるわけでもありません。
関係する法律・契約
損害賠償、責任制限、因果関係、過失、損害の範囲。
どう考えるか
その場で責任を認めず、契約書と事実関係を確認します。高額な請求では弁護士へ相談します。契約時に責任上限・損害の範囲を確認しておくことも重要です。

4-4 著作権・ソースコード・再利用

プログラムを「作った人」「お金を払った人」「著作権を持つ人」は、必ずしも同じではありません。
再利用や改変の可否は、著作権の帰属と契約内容を確認して判断します。

※この節の注意
著作権の帰属や改変・再利用の可否は、職務著作、契約、利用許諾、既存資産の扱い、具体的な利用態様等によって結論が変わる場合があります。「著作権が誰にあるか」だけで一律に判断しないことが重要です。

【ケース24】ある顧客用に作ったプログラムを、ほぼそのまま別顧客へ販売した

状況
A社の依頼で作ったプログラムが汎用的だったので、少しだけ変更してB社にも販売したところ、A社から「当社のために作らせたものを勝手に他社へ売るな」と抗議された。
何が問題か
「誰が著作権を持つか」だけでは結論が出ません。A社に独占的な利用権を与えていないか、A社固有の秘密情報・業務ロジックが含まれていないか、汎用部品とA社専用部分を分けていたかも確認する必要があります。
関係する法律・契約
著作権譲渡、利用許諾、秘密保持、独占利用に関する契約。
どう考えるか
再利用する可能性がある汎用ライブラリ・共通部品は、契約時に権利を制作者側へ留保することを検討します。顧客固有情報は別顧客へ持ち込まないことが重要です。

【ケース25】汎用ライブラリまで顧客へ著作権譲渡してしまった

状況
契約書に「本業務で作成した一切のプログラムの著作権を顧客へ譲渡する」とあり、以前から自分が使っていた共通ライブラリまで含まれるような内容だった。
何が問題か
著作権譲渡の対象範囲が広すぎると、今後別案件で使いたい自分の資産まで自由に使えなくなる可能性があります。
関係する法律・契約
著作権譲渡、既存著作物・既存資産の扱い。
どう考えるか
契約締結前に、従前から保有するライブラリ・テンプレート・共通部品等を譲渡対象から除外する整理を検討します。

【ケース26】著作権を譲渡していないのに、顧客が別会社へ改造を依頼した

状況
自分が開発して納品したプログラムについて、著作権は自分に残す契約だった。ところが顧客は「お金を払って作ってもらったのだから自由に改造できる」と考え、別会社へソースコードを渡して改修を依頼した。
何が問題か
顧客が成果物を受領したことと、著作権そのものを取得したことは同じではありません。ただし、顧客にどの範囲の利用・改変を認めていたかは契約内容によって異なります。
関係する法律・契約
著作権譲渡、利用許諾、改変権限、再委託。
どう考えるか
発注時に、著作権の帰属、ソースコードの納品、自社・第三者による改変が認められるかを明確にします。なお、プログラムの著作物の複製物の所有者には、自らそのプログラムを電子計算機で実行するために必要と認められる限度で複製・翻案が認められる場合があり、一定の調査解析が著作権侵害とならない場合もあります。そのため、著作権が制作者に残っていることだけで、顧客による改変の可否を一律に判断することはできません。
一方、第三者へ改修を依頼できるか、改変・調査解析に関する特約があるか等は別に確認する必要があり、具体的な契約内容・目的・方法によって結論が変わります。

【ケース27】「既存ソフトやイラストと同じようなものを作って」と依頼された

状況
顧客から、「この既存ソフトとほぼ同じ画面・操作で作ってほしい」「このイラストと同じようなものを使いたい」と依頼された。要望どおり、見た目や構成をかなり似せて納品した。
何が問題か
顧客から依頼された仕事であっても、第三者の著作権その他の権利を侵害してよいことにはなりません。一方で、単なるアイデア・機能・ありふれた表現そのものは著作権で保護されない場合もあり、「似ている」というだけで直ちに著作権侵害になるわけでもありません。

ソースコード、イラスト、文章、特徴的な画面表現など、既存作品の創作的な表現をそのまま、または実質的に似せて利用していないかを確認する必要があります。また、内容によっては著作権だけでなく、商標権・意匠権・特許権・不正競争防止法などが関係することもあります。
関係する法律・契約
著作権、商標権、意匠権、特許権、不正競争防止法、第三者権利の非侵害条項。
どう考えるか
「顧客から言われたから大丈夫」と考えず、既存製品の機能や考え方を参考にすることと、保護される具体的な表現をコピーすることを分けて考えます。顧客から画像・フォント・テンプレート・ソースコード等を支給された場合でも、顧客自身が利用・改変・再配布する権限を持っているとは限りません。既存作品にかなり似せる依頼や第三者素材の利用を求められた場合は、権利関係や利用許諾の有無を顧客にも確認し、判断が難しければ専門家へ相談します。

4-5 秘密情報・個人情報・SNS

秘密情報は、ソースコードや顧客データだけとは限りません。
案件の存在、業務内容、画面、ログ、SNSへの何気ない投稿も問題になることがあります。

※この節の注意
個人情報保護法では「個人情報」「個人データ」等が区別され、委託、第三者提供、国外での取扱い、漏えい時の対応等によって適用されるルールが異なる場合があります。本節では読みやすさのため一般的な表現にまとめている箇所があります。

【ケース28】顧客データを自宅PCへコピーした

状況
仕事を早く終わらせるため、本番データを自宅PCへコピーして作業した。
何が問題か
データを扱う権限があることと、好きな場所・端末へコピーしてよいことは別です。
関係する法律・契約
NDA、個人情報、情報セキュリティ規程、委託契約。
どう考えるか
作業場所、利用端末、クラウドへの保存可否等を事前に確認します。「どこで作業するか」も契約・セキュリティの一部です。

【ケース29】顧客名を伏せてSNSで案件について投稿したら、顧客を特定された

状況
「某メーカー向けに在庫管理システムを作った。かなり大変だった」などと、会社名を伏せてSNSへ投稿した。さらに業種、地域、導入時期、規模などを書いたため、複数の情報を組み合わせると顧客を推測できる状態になり、顧客から「当社の案件を勝手に公開した」と抗議された。
何が問題か
会社名を書かなければ安全とは限りません。業種、時期、地域、システム内容などを組み合わせることで顧客が特定される場合があります。また、契約によっては取引の事実自体が秘密情報になっていることもあります。
関係する法律・契約
NDA、秘密保持条項、営業秘密、個人情報を含む場合の識別可能性、場合によっては損害賠償。
どう考えるか
SNSへ案件情報を書く前に、個々の情報だけでなく、公開済みの他の情報と組み合わせたときに顧客や個人を特定できないかも確認します。「差しさわりのない程度」は自分の感覚ではなく、契約と顧客の認識で判断し、迷う場合は公開しないか、事前に許可を取ります。

【ケース30】ポートフォリオに顧客名と画面を掲載した

状況
フリーランスとして実績を示すため、「○○株式会社向け販売管理システム開発」と画面キャプチャをWebサイトへ掲載した。
何が問題か
顧客名、開発内容、システム画面そのものが秘密情報である可能性があります。画面内に個人情報等が表示されている場合はさらに問題が広がります。
関係する法律・契約
NDA、秘密保持、著作権、個人情報、商標等。
どう考えるか
実績として公開したい場合は、社名・概要・画面等のどこまで公開してよいか事前に確認します。

【ケース31】案件終了後も顧客データをPCに残していた

状況
「将来また保守依頼が来るかもしれない」と、ソースコード、CSV、本番データを個人PCへ残したままにしていた。
何が問題か
契約終了後の返却・削除義務がある場合があります。必要のない個人データを保有し続けること自体もリスクになります。
関係する法律・契約
NDA、データ返却・削除条項、個人情報。
どう考えるか
案件終了時に、何を残してよく、何を返却・削除するのか確認します。自分の汎用ライブラリと顧客情報を普段から分けて管理することも重要です。

4-6 生成AI・クラウド・外部サービス

生成AIや無料Webサービスは便利ですが、外部サービスへ情報を送信するという点では同じです。
「技術的に送れる」ことと「送ってよい」ことを分けて考えます。

※この節の注意
生成AI・クラウド・外部サービスの利用可否は、法律だけでなく、顧客との契約、NDA、社内規程、サービスごとの利用規約・データ取扱条件等によっても変わります。サービス条件は変更されることがあるため、実際に利用する時点の条件を確認してください。

【ケース32】顧客の仕様書を生成AIへ丸ごと入力した

状況
顧客から受け取った仕様書を生成AIへ貼り付け、「この仕様でプログラムを書いて」と依頼した。仕様書には顧客名、社内業務、システム構成等が含まれていた。
何が問題か
AIへ入力できることと、入力してよいことは別です。「学習に使われない設定」だけで判断するのも不十分です。
関係する法律・契約
NDA、営業秘密、顧客との契約、社内AI利用規程、AIサービスのデータ取扱条件。
どう考えるか
利用するAIサービスの保存・学習利用・アクセス条件を確認し、顧客契約・社内規程も確認します。必要なら秘密情報を除去し、抽象化した質問へ変えます。

【ケース33】エラーログをAIへ貼ったら個人情報が入っていた

状況
エラー原因を調べるためログを丸ごと生成AIへ入力したところ、氏名、メールアドレス、ユーザーID等が含まれていた。
何が問題か
ソースコードだけに注意しても不十分です。ログ、CSV、SQLダンプ、画面キャプチャ等にも秘密情報・個人情報は入り込みます。
関係する法律・契約
個人情報保護法、NDA、顧客とのデータ取扱契約。
どう考えるか
AIへ送信する前に、まずそのログを外部AIへ入力してよいか、組織のルール、顧客との契約、利用目的、利用サービスのデータ取扱条件を確認します。
マスキングする場合も、氏名やメールアドレスだけを削除すれば十分とは限りません。ユーザーID、所属、日時、ログ内容等の組合せによって個人を識別できないか、認証情報や顧客固有情報が残っていないかも確認します。

【ケース34】AI生成コードをほとんど確認せず納品した

状況
生成AIが出したコードが動いたため、十分なレビューをせず顧客へ納品した。
何が問題か
AIを使ったこと自体が、顧客に対する品質責任を自動的に免除する理由になるわけではありません。
関係する法律・契約
開発契約、品質・検収条件、セキュリティ、第三者権利。
どう考えるか
AI生成コードも、自分で書いたコードと同じようにレビュー・テストします。理解できないコードをそのまま納品しないことが基本です。

【ケース35】生成AIで簡単に作ったことを理由に、顧客から支払いを拒まれた

状況
顧客から依頼されたプログラムを生成AIも利用して作成し、仕様どおり納品した。ところが顧客から、「これはAIを使えば簡単に作れるものだ。そんなに手間がかかっていないなら、この金額は払えない」と言われた。
何が問題か
固定額で成果物を納品する契約では、一般に報酬は開発者が実際に何時間キーボードを打ったかだけで決まるものではありません。あらかじめ合意した成果物・仕様・報酬額があり、その内容を満たしているのであれば、「AIを使ったから簡単だった」という理由だけで、当然に合意済みの報酬がなくなるとは限りません。

一方、時間単価で請求しているのに実際と異なる作業時間を申告した場合や、契約・顧客ルールで生成AIの使用が禁止されていた場合、AI利用について虚偽の説明をしていた場合などは別の問題になります。
関係する法律・契約
報酬条件、請負・準委任、成果物・検収条件、生成AI利用条件、説明内容。
どう考えるか
「作業時間」ではなく「成果物」に対していくら支払う契約なのか、それとも実作業時間に応じて支払う契約なのかを最初に明確にします。生成AIの使用可否について顧客ルールがある場合は事前に確認します。
また、見積書や契約で「○人日」「○時間の作業」などが報酬算定の前提として明示されていた場合や、特定の開発方法・要員による作業を約束していた場合には、その合意内容によって判断が変わります。
AIによって短時間で高品質な成果物を作れることと、合意した成果物の価値・報酬は分けて考える必要があります。フリーランス法や取適法が適用される取引では、発注後に合意済みの報酬・代金を一方的に減額することが禁止行為となる場合があります。ただし、成果物に契約不適合がある場合や、契約違反がある場合の扱いは別途確認が必要です。

【ケース36】AI生成コードが既存OSSとよく似ていた

状況
AIが出力した長いコードが、後から特定のOSSコードと非常によく似ていることに気付いた。
何が問題か
既存著作物との類似性等によって、著作権やライセンスの確認が必要になる可能性があります。ただし、コードが似ているというだけで直ちに著作権侵害やライセンス違反になるわけではありません。著作権侵害では、既存著作物との類似性だけでなく依拠性も問題となり、AI生成物については未確定の論点もあります。具体的な一致内容や生成・利用の経緯等によって判断が変わります。
関係する法律・契約
著作権、OSSライセンス、AIサービスの契約条件。
どう考えるか
重要なコードは無条件に「AIが作ったから出典なし」と考えず、特徴的なコードや大きなまとまりについて出典・ライセンスの確認を検討します。

【ケース37】無料のWebサービスへ顧客ファイルをアップロードした

状況
PDF変換、CSV整形、画像圧縮等の無料Webサービスへ顧客資料をそのままアップロードした。
何が問題か
生成AIだけが問題なのではありません。社外サービスへ顧客データを送信するという構造は同じです。
関係する法律・契約
NDA、個人情報、情報セキュリティ規程、サービス利用規約。
どう考えるか
業務データを外部サービスへ送る前に、会社・顧客の利用ルールとサービス側のデータ取扱いを確認します。

【ケース38】「競合サイトの価格を自動取得して」とWebスクレイピングを依頼された

状況
顧客から、「競合会社のWebサイトに掲載されている商品名と価格を毎日自動取得し、Excelへ一覧化してほしい」と依頼された。技術的にはVBA、Power Query、Python等で取得できそうだったが、対象サイトの利用規約を見ると、自動取得やスクレイピングを禁止・制限する記載があった。
何が問題か
Web上で閲覧できる情報だからといって、どの方法・目的でも自由に自動取得してよいとは限りません。スクレイピング自体が一律に違法というわけではありませんが、対象サイトの利用規約、著作権、データベースの利用条件、個人情報、アクセス方法・頻度等を確認する必要があります。
特に、ログイン後の情報を取得する、アクセス制限を回避する、大量アクセスでサービスへ過度な負荷を与える、公式・有料APIが用意されているのにその利用条件を確認せず別の方法で大量取得する、取得した文章・画像をそのまま再配布するといった場合は、単なる公開ページの閲覧とは別の問題が生じます。大量アクセスの態様によっては、民事上の責任だけでなく刑事上の業務妨害等が問題となる場合もあります。
また、価格等の事実情報そのものと、サイト上の文章・画像、データの選択・配列に創作性が認められるデータベース等は分けて考える必要があります。どの情報を、どの方法で、何の目的に利用するかによって結論は変わります。
関係する法律・契約
対象サイトとの契約・利用規約、著作権法、個人情報保護法、不正アクセス禁止法、民法上の不法行為、態様によっては刑法上の業務妨害等。具体的な取得方法・データ・利用目的によって関係するルールは変わります。
どう考えるか
受注前に、対象サイトの利用規約、自動取得に関する方針、公式APIの有無、取得する情報と利用目的、アクセス頻度等を確認します。利用規約で自動取得が禁止・制限されている場合には、顧客へその点を伝え、公式APIやデータ提供サービス等の代替方法を検討します。なお、利用規約に反したという事実だけから直ちに犯罪や不正アクセスに当たると判断できるわけではなく、その規約が契約上どのような効力を持つかも、規約の提示・同意状況等によって異なります。
robots.txtは、クローラに対するサイト側の方針を示す技術的な仕組みであり、アクセス権限を付与・拒否する仕組みそのものではありません。Disallowを無視したことだけで直ちに犯罪や違法行為になると一律に判断することはできませんが、利用規約やアクセス頻度等と併せて確認すべき情報の一つです。
著作権上利用できる情報であっても、それだけで利用規約やアクセス方法、取得後の再利用等の問題まで解消するわけではありません。疑義がある場合は専門家へ確認します。
RFC 9309：Robots Exclusion Protocol

4-7 OSS・ライセンス

OSSは無料で入手できても、無条件で自由に利用できるとは限りません。
利用・改変・再配布等の条件をLICENSEで確認します。

※この節の注意
OSSの条件は、ライセンスの種類・バージョン、改変・結合・配布・ネットワーク経由での提供等の利用形態によって異なります。名称だけで判断せず、実際に適用されるLICENSE本文等を確認してください。

【ケース39】GitHubのコードをLICENSEを確認せず利用した

状況
必要な処理を実装したコードをGitHubで見つけ、LICENSEを確認せず顧客向けプログラムへコピーした。別のリポジトリではLICENSEファイル自体が見当たらなかったが、「禁止と書いていないから大丈夫」と考えて利用した。
何が問題か
GitHubで公開されているだけでは、自由利用の許諾があるとは限りません。また、LICENSEがないことも自由利用の許可を意味しません。
関係する法律・契約
著作権、利用許諾、OSSライセンス。
どう考えるか
まずLICENSE、COPYING、ファイルヘッダ等を確認します。明確な利用条件が確認できない場合は、権利者へ確認するか、明確なライセンスが付された別のコードを利用することを検討します。

【ケース40】GPLライブラリを組み込んで顧客へ納品した

状況
便利なGPLライブラリを製品へ組み込み、そのまま顧客へ配布した。
何が問題か
GPLは強いコピーレフトを持ちます。どのように結合し、どの形で配布するかによって、ソースコード提供等の条件が問題になります。
関係する法律・契約
GPL、著作権、納品契約。
どう考えるか
「GPLを使ったら全部公開」と単純化せず、GPLコードとの結合関係、配布形態、ライセンス条件を確認します。判断が難しい製品では法務・専門家へ確認します。

【ケース41】「MITなら何をしてもよい」と思っていた

状況
MIT Licenseのコードなので「完全に自由」と考え、著作権表示やライセンス文を削除した。
何が問題か
MIT Licenseにも条件があります。制約が少ないことと、条件がないことは同じではありません。
関係する法律・契約
MIT License、著作権表示。
どう考えるか
ライセンス本文を確認し、要求される著作権表示・許諾表示を残します。

4-8 再委託・外注・チーム開発

自分だけでは間に合わないから別の人へ頼む。技術的には簡単でも、顧客との契約や情報管理では別の問題が生じます。

※この節の注意
再委託の可否や必要な手続は、顧客との契約、NDA、個人データの取扱い、成果物の権利帰属等によって異なります。「手伝ってもらうだけ」と考えず、誰が情報やソースコードへアクセスするのかまで確認します。

【ケース42】納期に間に合わず、知人のエンジニアへ手伝わせた

状況
顧客には何も言わず、仕様書とソースコードを知人へ送り、開発を手伝ってもらった。
何が問題か
契約上の再委託禁止・事前承認に違反する可能性があります。また秘密情報を第三者へ開示しています。
関係する法律・契約
再委託条項、NDA、個人情報、秘密情報。
どう考えるか
再委託の可否・承認手続きを契約で確認します。必要なら顧客の承認を得て、手伝う側とも秘密保持等を整備します。再委託先がプログラム等の成果物を作成する場合は、顧客へ約束した著作権譲渡・利用許諾を実現できるよう、再委託先との権利関係も整理します。

【ケース43】自分が再委託した外注先が、さらに別会社へ再委託していた

状況
自分が一部の開発をA社へ再委託したところ、知らないうちにA社からB社、さらにC社へと作業が再委託されていた。
何が問題か
元の受注者である自分が、誰が顧客データやソースコードへアクセスしているか把握できない状態になっています。顧客との契約で再委託先の事前承認が必要な場合には、その点も問題になります。
関係する法律・契約
再委託、秘密保持、個人データの委託先監督。
どう考えるか
再委託の可否、再委託先の管理、責任範囲を契約で定め、重要データを扱う場合は実際の委託体制を把握します。

【ケース44】海外エンジニアへ顧客データを渡した

状況
オンラインで海外の開発者を見つけ、顧客データとソースコードを渡して作業を依頼した。
何が問題か
顧客との契約・再委託条件に加え、秘密情報・個人データの取扱いに追加の確認が必要になる可能性があります。個人データを外国にある第三者へ提供する場合は、個人情報保護法上の特別なルールが関係することがありますが、提供先の国・地域や相手方の体制等によって結論は変わります。
関係する法律・契約
再委託、秘密保持、個人情報保護法、外国にある第三者への個人データ提供、国外での取扱い。
どう考えるか
「インターネットで簡単に渡せる」ことと「渡してよい」ことは別です。契約とデータ取扱いルールを確認し、個人データが含まれる場合は、外国にある第三者への提供に当たるか、本人同意や提供先の体制等についてどの要件を確認する必要があるかを整理します。本人同意を根拠として提供する場合などには、提供先の国の個人情報保護制度等に関する情報提供が必要となる場面もあります。判断が難しい場合は専門家へ確認します。
個人情報保護委員会：外国にある第三者への提供編

4-9 アカウント・クラウド・アクセス権

システム本体だけでなく、AWS、ドメイン、GitHub、管理者ID等も重要な資産です。
「誰の名義で、誰が管理し、契約終了後どうするのか」を決めておきます。

【ケース45】顧客用のクラウド・ドメイン・GitHub等を自分名義で管理した

状況
顧客システムを早く立ち上げるため、自分のAWSアカウントでクラウド環境を作成し、ドメインも自分のアカウントで取得した。ソースコードを置くGitHub Organizationも自分だけがOwnerになっていた。契約終了時、顧客から「すべて当社で管理できる状態に引き継いでほしい」と求められた。
何が問題か
システム本体だけでなく、クラウド契約、ドメイン、DNS、証明書、GitHub Organization、CI/CD等も、運用を継続するための重要な管理資産です。開発者個人だけが契約者・管理者になっていると、契約終了、退職、病気、連絡不能等のときに顧客が運用できなくなるおそれがあります。また、サービスによってはアカウントそのものを第三者へ単純に譲渡できない場合もあるため、後から「渡せばよい」とは限りません。
関係する法律・契約
業務委託契約、成果物・引渡し条件、アカウント管理、各クラウド・ドメイン・GitHub等の利用規約、秘密情報・認証情報の管理。
どう考えるか
顧客が長期利用するサービスは、原則として最終的に誰が契約者・管理者となるかを開始時に決めます。可能なら顧客自身の法人アカウントで契約し、開発者は必要な権限を付与してもらう形が分かりやすいでしょう。
契約終了時には、管理者権限、請求先、ドメイン、DNS、証明書、リポジトリ、CI/CD、APIキー等を一覧化して引き継ぎます。GitHub等では顧客側にも複数の管理者を設定するなど、開発者一人だけが管理権限を持つ状態を避けます。

【ケース46】契約終了後、昔のIDで顧客環境へログインした

状況
「自分が作ったサーバが気になった」ため、契約終了後も以前のID・パスワードでログインした。
何が問題か
以前アクセスを許されていたことと、契約終了後もアクセス権限があることは同じではありません。
関係する法律・契約
契約上の権限、不正アクセス禁止法等。
どう考えるか
契約終了時にアクセス権限を終了し、顧客側もID停止・パスワード変更等を行います。「パスワードを知っている」ことと「ログインしてよい」ことは別です。

4-10 保守・運用・納品後

納品した瞬間にすべてが終わるわけではありません。
外部サービスの変更、保守範囲、本番作業等について、どこまで責任を負うかを整理しておきます。

【ケース47】外部APIの仕様変更で突然動かなくなった

状況
Google、Microsoft、決済サービス等のAPI変更で、納品済みシステムが突然動かなくなった。
何が問題か
自分のコードを変更していなくても、依存サービスの変更によって保守が必要になります。
関係する法律・契約
保守契約、外部サービス依存、対応環境。
どう考えるか
外部サービスの将来変更への対応は保守・追加作業とする等、契約上の扱いを整理しておきます。

【ケース48】納品直後に、利用していたサードパーティの会社がなくなった

状況
外部サービスやサードパーティ製ライブラリを利用してシステムを開発し、正常に納品した。ところが約1か月後、そのサービスを提供する会社が事業終了・倒産し、システムの一部が使えなくなった。顧客から「納品したばかりなのだから無料で直してほしい」と言われた。
何が問題か
納品時には正常に動作していても、外部サービスの終了によって後から利用できなくなることがあります。その場合、開発者がどこまで無償で代替対応する義務を負うかは、契約上の保証・保守範囲、外部サービスへの依存を事前に説明していたか、サービス終了リスクをどちらが負担する合意だったかなどによって変わります。
関係する法律・契約
保証・保守契約、外部サービス・第三者製品への依存、契約不適合、免責・責任分担。
どう考えるか
外部API、SaaS、クラウドサービス、ライブラリ等へ依存する場合は、採用時にその事実を顧客へ伝え、サービス終了・仕様変更・料金変更等が起きた場合の対応を契約で整理しておきます。特に業務上重要な機能では、代替手段の有無やベンダーロックインも設計段階で確認します。

【ケース49】保守契約なしで質問が延々と来る

状況
納品から2年たっても、「このボタンは何ですか」「PCを買い替えたので設定してください」「新入社員へ説明してください」と連絡が続く。
何が問題か
納品代金に含まれるサポート範囲と、有償保守・追加支援の境界が曖昧です。
関係する法律・契約
保守契約、サポート範囲、追加業務。
どう考えるか
無料サポート期間・内容を定め、それを超える問い合わせや環境設定・教育等は別料金とする等、ルールを明確にします。

【ケース50】本番障害を直すため、許可なくデータを書き換えた

状況
障害原因が分かったため、顧客へ確認せず本番DBを直接修正した。結果としてシステムは復旧した。
何が問題か
管理者権限を持っていることと、顧客の本番データを自由に変更してよいことは別です。誤操作すれば重大な損害につながります。
関係する法律・契約
業務委託契約、作業権限、変更管理、秘密情報・個人情報。
どう考えるか
緊急作業時の承認手順、バックアップ、作業記録、復旧手順を事前に決めておきます。権限と承認は分けて考える必要があります。

4-11 【主な法令・公的資料・相談窓口】

本章で扱った法律・契約上の論点について、確認に役立つ主な法令、公的資料、相談窓口をまとめます。

法律や制度は改正されることがあります。また、同じように見える事例でも、契約内容、当事者の立場、具体的な利用方法・取引実態等によって結論が変わる場合があります。
実際の案件では、必要に応じて最新の法令・ガイドラインを確認してください。

【主な法令】

e-Gov法令検索：民法
契約の成立、請負、委任・準委任、解除、損害賠償等の基本となる法律です。
e-Gov法令検索：著作権法
プログラムの著作権、職務著作、著作者人格権、翻案権、著作権譲渡、プログラムの調査解析等に関係します。
e-Gov法令検索：個人情報の保護に関する法律（個人情報保護法）
顧客データ、ログ、生成AIへの入力、委託先管理、外国への個人データ提供等に関係します。
e-Gov法令検索：特定受託事業者に係る取引の適正化等に関する法律（フリーランス法）
取引条件の明示、報酬の支払期日、報酬減額、不当なやり直し、中途解除等に関係します。
e-Gov法令検索：製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律（中小受託取引適正化法・取適法）
対象となる事業者間取引における支払期日、代金減額、価格協議、支払方法等に関係します。
e-Gov法令検索：不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）
他人のID・パスワードの利用、アクセス制御されたシステムへのアクセス等に関係します。
e-Gov法令検索：労働者派遣事業の適正な運営の確保及び派遣労働者の保護等に関する法律（労働者派遣法）
請負・準委任と労働者派遣の区別、偽装請負等を考える際に関係します。
e-Gov法令検索：不正競争防止法
営業秘密の不正取得・使用・開示等に関係します。

【官公庁の解説・ガイドライン】

公正取引委員会：フリーランス法特設サイト
フリーランス法の対象、取引条件の明示、支払期日、禁止行為等を確認できます。
公正取引委員会：取適法
2026年1月1日施行の取適法について、対象取引や改正内容を確認できます。
厚生労働省：フリーランスとして業務を行う方・業務を委託する事業者の方へ
フリーランスの就業環境や関係制度について確認できます。
厚生労働省：労働者派遣事業と請負により行われる事業との区分に関する基準
請負と労働者派遣を区別する際の基本的な考え方を確認できます。
厚生労働省：副業・兼業
副業・兼業に関するガイドラインや関連資料を確認できます。
文化庁：著作権
著作権制度、著作権契約、AIと著作権等に関する公的資料を確認できます。
文化庁：著作権契約書作成支援システム・著作権の譲渡と利用許諾
著作権譲渡と利用許諾の違いを確認できます。
経済産業省：営業秘密
営業秘密管理、不正競争防止法上の営業秘密等について確認できます。
個人情報保護委員会：個人情報保護法ガイドライン（通則編）
個人情報・個人データの取扱いに関する基本的なルールを確認できます。
個人情報保護委員会：外国にある第三者への提供編
海外の事業者・エンジニア等へ個人データを提供する場合のルールを確認できます。
個人情報保護委員会：生成AIサービスの利用に関する注意喚起
生成AIへ個人情報・個人データを入力する場合の注意点を確認できます。
IPA：OSSの権利・ライセンス
OSSの著作権やライセンスについて、基本的な考え方を確認できます。
警察庁：基本的なセキュリティ対策
不正アクセスや認証情報の管理等に関する基本的な情報を確認できます。

【主な相談窓口】

フリーランス・トラブル110番
フリーランス・個人事業主が業務委託に関するトラブルについて相談できる窓口です。

※上記は、本記事に関係する代表的な法令・公的資料を掲載したものです。個別の案件では、ここに掲載していない法律・ガイドライン等が関係する場合もあります。

まとめ：法律を知る目的は、トラブルになる前に気付くこと

ITエンジニアが法律を学ぶ目的は、法律家になることではありません。
トラブルが起きてから相手と争うことが目的でもありません。

本当に重要なのは、トラブルになる前に「これは危ない」と気付くことです。

この追加作業は契約範囲なのか。
このソースコードを流用してよいのか。
このデータを生成AIへ入力してよいのか。
このプログラムの著作権は誰が持っているのか。
このコード・データ・外部サービスを、この用途で利用してよいのか。
SNSへこの案件のことを書いてよいのか。
納品後、いつまで無料で修正する必要があるのか。
契約終了後、このアカウントへログインしてよいのか。
もし障害が起きたら、どこまで責任を負うのか。

こうした疑問を持つことができれば、契約書を確認できます。顧客と条件を話し合えます。必要なら、法務担当者や弁護士等の専門家へ相談できます。
しかし、知らなければ疑問すら持てません。

特に、副業やフリーランスとして個人で仕事を受ける場合、技術力だけでは自分を守れません。

仕事の範囲を決める。
条件を記録する。
権利関係を確認する。
秘密情報を適切に扱う。
追加作業は追加作業として管理する。
アカウントやデータを正しく引き継ぐ。

こうしたことも含めて、プロとして仕事をするということです。
法律や契約の問題では、似た事例でも、契約内容、権利関係、当事者の立場、利用目的・方法などが変われば結論も変わります。大切なのは答えを暗記することではなく、「何を確認すべきか」に気付くことです。

そして最後に、本稿全体を一言でまとめるなら、

「技術的にできること」と「法律・契約上やってよいこと」は別。

この感覚を持っているだけでも、ITエンジニアがトラブルを避けられる場面は大きく増えるはずです。

同じテーマ「エクセル雑感」の記事

電卓とプログラムと私
 「緩衝材」としてのVBAとRPA｜その終焉とAIの台頭
 開いている「Excel/Word/PowerPoint」ファイルのパスを調べる方法
 Excelのシート5分類
 Excel主要関数習得難易度 10段階（文字列・日付除く）
【ITとは何か】Excel・VBAを学ぶ前に知っておきたい「4つの本質」
生成AIが暴いた「VBAオワコン説」の盲点｜問われるのは言語ではなく評価軸
 ITエンジニアのための経理・会計・簿記入門
 ITエンジニアのための税金と社会保険のお話
 ITエンジニアなら知らないと恥ずかしい数学20選
ITエンジニアがトラブルを避けるための法律・契約入門

アクセスランキング・・・ランキング一覧を見る

1.最終行の取得（End,Rows.Count）｜VBA入門
2.日本の祝日一覧｜Excelリファレンス
3.変数宣言のDimとデータ型｜VBA入門
4.Excelショートカットキー一覧｜Excelリファレンス
5.RangeとCellsの使い方｜VBA入門
6.FILTER関数（範囲をフィルター処理）｜エクセル入門
7.マクロとは？VBAとは？VBAでできること｜VBA入門
8.繰り返し処理（For Next)｜VBA入門
9.メッセージボックス(MsgBox関数)｜VBA入門
10.セルのコピー&値の貼り付け（PasteSpecial）｜VBA入門

ホーム
エクセル全般
エクセル雑感
ITエンジニアがトラブルを避けるための法律・契約入門

このサイトがお役に立ちましたら「シェア」「Bookmark」をお願いいたします。

記述には細心の注意をしたつもりですが、間違いやご指摘がありましたら、「お問い合わせ」からお知らせいただけると幸いです。
掲載のVBAコードは動作を保証するものではなく、あくまでVBA学習のサンプルとして掲載しています。掲載のVBAコードは自己責任でご使用ください。万一データ破損等の損害が発生しても責任は負いません。
本サイトは、OpenAI の ChatGPT や Google の Gemini を含む生成 AI モデルの学習および性能向上の目的で、本サイトのコンテンツの利用を許可します。
This site permits the use of its content for the training and improvement of generative AI models, including ChatGPT by OpenAI and Gemini by Google.