※本記事は一般的な情報提供を目的としています。法的助言ではありません。個別事情は専門家にご確認ください。
フリーランス案件で、地味に悩ましいのがここです。
小さな仕様変更・追加要望が積み上がって、無料サービス化する問題。
「これくらい軽微だから」
「ついでにやっておいて」
「今週中に反映できる？」
この言葉が出た瞬間、フリーランス側は“断るか、受けるか”の二択に追い込まれます。
しかし、現場を見ていると、揉め事の多くは悪意があるわけではなく、「合意がない」「記録がない」といった曖昧な状態のまま進むことが原因です。
“脱おふたりさま”の文脈では、地雷は単価ではなく単一依存。
案件元の言い分に合わせるしかない状態（比較対象がない／更新が怖い）になると、仕様変更を飲み続けて自分が消耗します。
だからこそ、仕様変更は「気合で乗り越える」ではなく、「合意ログ（証拠になる記録）で守る」のが現実解です。
この記事では、仕様変更・追加工数を無料化させないための、合意ログの作り方（テンプレ）を、メール文例と議事録ひな形でまとめます。
1. なぜ「合意ログ」が必要なのか：揉める論点はいつも同じ
仕様変更トラブルは、最終的に次の争点に収束します。
- そもそも「追加」だったのか（当初範囲内だったのか）
- 追加だとして、誰がいつ承認したのか（決裁者の合意）
- 工数と納期の調整があったのか（無料か有料か）
- 完成（検収）の基準は何だったのか
このうち、フリーランス側が弱くなりやすいのは「承認」「合意」「記録」です。
だから、合意ログは「戦うため」ではなく、「戦わないため（揉めないため）」に作ります。
2. 合意ログの基本ルール（これだけで事故率が下がる）
仕様変更で揉めないためにやることは、ほぼこの3点です。
- 変更は「内容・工数・納期・費用」までセットで確定
- 決裁者（GOを出す人）を押さえる
- 合意→着手の順に固定する（先に着手しない）
ポイントは、文章を長くすることではありません。
“後で読み返して誰が見ても分かる”粒度で、明確に・簡潔に残すことです。
3. 【コピペ可】仕様変更・追加工数の合意ログ（メールテンプレ3種）
テンプレ①：仕様変更を「追加」として切り出す（初動）
件名：仕様変更（追加要望）について確認（工数・納期・費用）
本文：
お疲れさまです。◯◯の件、追加要望として認識しています。
【追加要望の内容】
・（例）ログイン後の画面に◯◯機能を追加
・（例）APIレスポンスに◯◯項目を追加
【当初合意との差分】
・当初：◯◯まで
・追加：◯◯が増える
対応可否と、以下を確定したく存じます。
1) 追加工数見込み：（例）+◯人日（◯時間）
2) 影響範囲：（例）DB／API／フロント
3) 納期影響：（例）現行納期＋◯営業日
4) 費用影響：（例）追加費用あり／単価調整／別見積
決裁者（最終OKの方）がどなたかも併せてご教示ください。
本メールへのご返信をもって、追加対応の合意（GO）とさせてください。
使いどころ：
「軽微だから」系の要望が来た時。ここで“差分”を文章化すると、無料化の歯止めになります。
テンプレ②：見積提示→承認依頼（合意を取りに行く）
件名：追加要望対応の見積（工数・納期・費用）承認のお願い
本文：
お疲れさまです。追加要望の件、見積をご連絡します。
【対応内容（確定案）】
・（箇条書きで3～5行）
【工数】
・合計：+◯時間（内訳：設計◯h／実装◯h／テスト◯h）
【納期】
・現行：YYYY/MM/DD
・変更後：YYYY/MM/DD（+◯営業日）
【費用】
・（例）追加：◯円（または、月額単価の調整／別途請求）
上記条件で進めてよろしければ、
「承認します（GO）」とご返信ください。
ご返信後に着手します。
使いどころ：
合意の“最終一押し”。「返信＝合意」にするのが肝です。
テンプレ③：口頭合意を“文章に落とし込む”（議事録メール）
件名：本日の打合せメモ（仕様変更／追加要望の確認）
本文：
本日の打合せ内容をメモとして共有します。相違あれば本日中にご指摘ください。
【決定事項】
1) 追加要望：◯◯（当初範囲外）
2) 工数：+◯時間
3) 納期：YYYY/MM/DDへ変更
4) 費用：◯◯（追加請求／単価調整／別見積）
【未決事項（宿題）】
・◯◯の判断（担当：◯◯、期限：YYYY/MM/DD）
※相違がなければ、本メモの内容で確定として進めます。
使いどころ：
「言った／言わない」のいざこざを潰す万能文。短いけど確実です。
4. 【ひな形】仕様変更ログ（議事録／チケット）テンプレ
メールだけでなく、チケット管理や議事録にも流用できる形です。
【変更ID】CHG-YYYYMMDD-XX
【起案日】YYYY/MM/DD
【起案者】（誰が言い出したか）
【変更内容】
・何を、どう変えるか（箇条書き）
【背景／目的】
・なぜ必要か（1～2行）
【当初範囲との差分】
・当初：◯◯
・追加：◯◯
【影響範囲】
・機能：◯◯
・画面：◯◯
・DB/API：◯◯
・テスト：◯◯
【工数見積】
・合計：◯時間（内訳：設計／実装／テスト）
【納期影響】
・現行：YYYY/MM/DD
・変更後：YYYY/MM/DD（+◯営業日）
【費用影響】
・追加費用：有／無（内容：◯◯）
【承認】
・承認者：◯◯（役職／立場）
・承認日時：YYYY/MM/DD
・承認手段：メール／チャット／チケット
【備考】
・検収条件／優先度／リスクなど
これを“埋める”だけで、変更管理の粒度が整います。
5. よくある失敗パターン（これだけは避ける）
失敗1：着手してから合意を取りに行く
「先にやっておいて」は、後から最も揉めます。
合意がない時点で着手すると、交渉カードを自分で捨てることになります。
失敗2：決裁者が誰か分からないまま進める
現場担当がOKでも、支払いを決める人が別だと止まります。
合意ログには「承認者」を必ず入れる。
失敗3：差分が“感覚”のまま
「ちょっとだけ」「軽微」は事故の温床。
差分は箇条書きでいいので、文章化して残すのが鉄則。
6. まとめ：合意ログは“単一依存”から自分を守る道具
仕様変更や追加要望は、どんな現場でも起きます。
問題は、起きたときにフリーランス側が「飲むしかない」状態（単一依存）になっていることです。
合意ログは、相手を責めるためのものではなく、
合意を早い段階で可視化し、揉める芽を先手先手で潰すための道具です。
- 内容・工数・納期・費用をセットで確定
- 決裁者を押さえる
- 合意→着手の順で進める
- 口頭合意は議事録メールで固定する
この4点だけで、「無料でやらされる徒労感」は大きく減ります。