契約書に書いていないことが起きたら

契約書を丁寧に作り込んでも、実際の仕事が始まると必ず「書いていなかったこと」が出てくる。

Webサイト制作の案件で、納品後のアクセス解析レポートを「ついでに」求められた。システム開発の途中で、クライアント企業の親会社から突然仕様変更の指示が入った。撮影案件で、当初想定していなかった悪天候が重なって納期が揺らいだ。いずれも契約書には一言も書かれていない事態だ。

こうした場面で「契約書に書いていないから断れる」と思い込むフリーランスがいる一方、「書いていないから断れない」と諦めてしまうフリーランスもいる。どちらも正確ではない。契約書の空白をどう解釈し、どう交渉するかが問われる。

契約書に記載のない事態が生じたとき、法律は「書いていないから何も決まっていない」とは扱わない。

民法は契約書の文言だけでなく、契約の目的・交渉経緯・業界慣習・信義誠実の原則を総合的に考慮して当事者の意思を補充する仕組みを持っている（民法第1条第2項、第90条以下）。この「補充的解釈」により、契約書の空白は埋められる。

契約目的による解釈

契約書全体が目指している目的から、個別の事項に対する当事者の意思を推定できる。例えば「Webサイト完成までを支援する」という目的で締結した業務委託契約であれば、最低限の動作確認や軽微な修正は当然に含まれると解釈される可能性が高い。逆に、契約の目的範囲を大きく超える作業については、明記がなくても追加費用の合意が必要と判断される。

業界慣習の適用

その業界で一般的に行われている慣行は、契約書への明記がなくても拘束力を持つ場合がある。デザイン業界では「修正2回まで無料」が一般的な商慣習として認識されているならば、契約書に修正回数の記載がなくても、その慣習が基準として機能しうる。

過去の取引経緯の参照

同じクライアントとの継続取引であれば、過去の取引での慣例が現在の契約解釈にも影響する。以前の案件でアフターサポートを無償提供していた実績があれば、今回も同様の期待が発生していると解釈される可能性がある。

重要なのは、「書いていないから自由に断れる」でも「書いていないから全て受けなければならない」でもなく、「書いていないことの意味を文脈から解釈して判断する」という立場に立つことである。この解釈の余地があるからこそ、交渉の余地も生まれる。

契約書に書かれていない事態は、大きく4つの類型に分類できる。類型ごとに発生構造と対処の方向性が異なる。

類型1: 追加作業要求

納品後や作業途中に、当初の契約範囲を超える作業を求められるケース。「ついでにこれも」「もう一画面追加して」という形で持ち込まれることが多い。

発生構造の特徴は、クライアント側が「追加」という認識を持っていないことにある。仕様の自然な延長として捉えているため、追加費用の発生を想定していない。フリーランス側が明確に線引きをしない限り、要求はエスカレートしやすい。

類型2: 仕様変更

作業途中でクライアントの要求内容が変化するケース。「やはりターゲットを変えたい」「競合を見て方針を変えた」という形で、当初の合意内容そのものが書き換えられようとする。

仕様変更の難しさは、クライアントが変更を「修正」や「調整」と表現し、追加費用なしで対応できると思い込んでいる点にある。初期の要件定義が不完全だったために発生するケースも多く、どこからが「変更」なのかの境界が曖昧になりやすい。

類型3: 第三者の介入

クライアントの上司、関連会社、外部コンサルタントなど、当初の契約関係になかった第三者が意見を述べてくるケース。「上から言われた」「顧問に確認したら変えろと言われた」という形で持ち込まれる。

この類型の特徴は、クライアント本人も困惑していることが多い点にある。担当者は合意内容を守りたいが、組織内の上位指示には逆らえないという板挟みに陥る。フリーランス側が冷静に対応しないと、担当者との信頼関係まで損なわれる。

類型4: 不可抗力・外部要因

自然災害、感染症の流行、発注者企業の経営変化、法規制の変更など、当事者の意思に関係なく発生する外部要因によって契約の履行が困難になるケース。

典型的な争点は「誰がリスクを負担するか」である。不可抗力による納期延長は費用追加なしに認められるのか、一部履行不能が生じた場合の報酬はどう扱うかなど、契約書に書いていないことが多い。

想定外事態が発生した瞬間の行動が、その後の展開を大きく左右する。最初の数日間に何をするかが重要である。

発生直後の記録化（24時間以内）

相手から想定外の要求や状況の変化を伝えられたら、その日のうちにメールで事実確認を送る。口頭で伝えられた内容をそのまま文字化して相手に送り、認識を合わせることが目的である。

件名：【確認】○○案件での追加要求について

○○様

本日ご連絡いただいた件について、認識を確認させてください。

ご要望の内容：[受けた要求・変化を具体的に記載]
当初契約の内容：[元の合意内容を記載]
ご要望を受けた日時：[日付・時刻]

以上の理解で相違ないでしょうか。
内容を確認した上で、対応の可否と条件について改めてご連絡いたします。

このメールへの返信が来れば、それ自体が事実確認の証拠となる。返信がなければ「先ほどお電話でご確認いただいた通り」という形で再送する。

初動における絶対に避けるべき行動

想定外事態の発生直後に最もやってはいけないことは、即座に「はい、対応します」と口頭で承諾してしまうことである。一度承諾してしまうと、その後に費用交渉をすることが難しくなる。

口頭で「検討します」と伝え、必ず書面で回答するという習慣を徹底する。急かされる場面でも「確認して改めてご連絡します」という返答で時間を確保することが重要だ。

状況の可視化と費用試算

記録化と並行して、要求された内容が「どれだけの追加工数・費用を必要とするか」を試算する。感覚的な判断ではなく、具体的な時間数と単価で計算することで、交渉時の根拠が明確になる。

試算の結果、当初契約の1〜2割増し程度の工数であれば善意で吸収する選択肢もある。しかし3割を超えるようであれば、追加契約または変更合意書の締結を求める段階に進む。

4つの類型それぞれに対応した実務的な対処方針を示す。

追加作業要求への対応

まず、要求が「契約範囲内の作業か、それとも新規作業か」を判断する。契約書の成果物定義を再読し、要求された内容が含まれうるかを確認する。明らかに範囲外であれば、追加見積もりを提示する。

範囲が曖昧な場合は、要求の内容を文書で整理し「こちらの理解では今回の要求は当初契約の範囲外と認識しています。追加費用として○○円を見込んでいますが、ご確認いただけますか」という形で問い合わせる。相手がこの認識に異議を唱えてきた場合、初めて契約書の文言と当初の合意内容に立ち返って議論できる。

仕様変更への対応

仕様変更は「変更合意書」によって明文化することが最善の対処である。変更内容・変更による追加費用・変更後のスケジュールを1枚の文書にまとめ、双方の署名を得る。

変更合意書を嫌がるクライアントには「経理上の処理のために必要です」という説明が有効なことがある。書面を求めることがビジネス上の自然な慣行として理解される環境を作ることが大切だ。

変更合意書の雛形：

業務変更合意書

（変更前の業務内容）
[当初合意した内容]

（変更後の業務内容）
[変更後の内容]

（変更による追加費用）
金額：○○円（税別）
支払い期日：○月○日

（変更後のスケジュール）
新たな納期：○月○日

上記の内容に合意します。
受託者：[署名・日付]　　発注者：[署名・日付]

第三者介入への対応

第三者の意見によって当初合意が覆されそうになった場合、「担当者との合意内容」を出発点として議論を整理することが重要である。第三者の意見を完全に無視するのではなく、「当初の合意内容を変更するには新たな合意が必要」という立場を明確にする。

担当者を責めるのではなく、「社内で調整していただいた上で、変更内容と費用について書面で確認させてください」という姿勢を取る。担当者が内部調整できるよう、フリーランス側は待つ時間を提供することも必要な場合がある。

不可抗力への対応

不可抗力事由が発生した場合、まず「どの程度の影響が出ているか」を事実として整理し、相手に報告する。その上で「どのような対応が双方にとって合理的か」を協議する。

不可抗力による遅延であっても、フリーランス側から積極的に状況報告と代替案の提示を行うことが重要である。「何もできなかったので待ってほしい」ではなく、「現時点での状況と、〇〇という代替案を検討しています」という姿勢が信頼維持につながる。

費用負担については、発生した不可抗力によって実際に追加費用が生じた場合（宿泊費の増加、追加機材のレンタルなど）は、その費用の明細を提示した上で協議する。明細のない請求は拒否される可能性が高いため、実費証明の書類を揃えることが前提となる。

想定外事態への対処を繰り返すうちに、次の契約書に反映すべき事項が見えてくる。対処の経験を記録し、契約書を継続的にアップデートしていくことが、長期的なリスク低減につながる。

「想定外」を記録するログの整備

案件ごとに「この案件で契約書になかったこと」を記録するシンプルなログを作成する。Notionやスプレッドシートなど何でも良い。案件名・発生した事態・対応内容・結果・次回の改善案という5項目を残すだけでよい。

このログが10件程度蓄積されると、自分がよく直面する想定外事態のパターンが見えてくる。それを次の契約書に反映させる作業が、自分の業務に特化した契約書の完成度を上げていく。

優先的に追記すべき条項

追加作業要求が多い場合：作業範囲を詳細に定義した「スコープ定義書」を契約書の別紙として添付し、別紙の範囲外は追加費用とする旨を明記する。

仕様変更が多い場合：「仕様変更の手続き」条項を設け、変更要求は書面で行い、受託者の見積もり提示と発注者の承認をもって効力を生じると定める。

第三者介入が多い場合：「意思決定権者の特定」条項を設け、契約上の承認権者を氏名・役職で特定し、それ以外の者による指示には従わない旨を明記する。

不可抗力が多い場合：「不可抗力条項」を設け、不可抗力事由の例示、通知義務の期限、費用負担の原則を定める。

契約書のバージョン管理

更新した契約書にはバージョン番号と更新日を記録し、過去のバージョンを保管する習慣をつける。「2026年版」「Webデザイン用v3」といった形で管理することで、どの案件でどのバージョンを使ったかが追跡できるようになる。

---

契約書は「問題が起きないための書類」ではなく、「問題が起きたときに解決の手がかりとなる書類」である。どれだけ丁寧に作っても、現実の仕事は必ず契約書を超えてくる。

大切なのは、書いていないことが起きたときに慌てず、記録化・解釈・交渉という3つのステップを落ち着いて踏めるかどうかである。経験を積むごとに対処の精度は上がり、それが次の契約書の品質を高めていく。想定外事態への対処力そのものが、フリーランスとしての実務力の核心になる。