契約書審査の修正コメントの書き方―相手方への説明，社内確認及び最終版のチェック（AI作成）

第１　修正コメントは何を伝えるものか

契約書審査の修正コメントは，条文を書き換えた理由と，次に判断すべき事項を相手に伝えるためのものである。修正履歴だけを送っても，何を守ろうとしているのか，どこまで譲歩できるのか，事実確認が必要なのかが伝わらなければ，交渉は進みにくい。

契約書本文，相手方に送る説明，社内だけで共有する判断資料を使い分ける。社内の予算上限，交渉上の最低条件，未解決の法的懸念，顧客や担当者の個人情報を，相手方へのコメントにそのまま残してはならない。

本稿は企業間の日本語契約を中心に，審査結果を交渉と締結の作業につなぐ方法を整理する。契約書審査全体の順序は，契約書審査の進め方とチェックポイントを参照されたい。

第２　修正理由を書く前に確認すること

１　前提事実と問題点を分ける

例えば，「納期が短すぎる」という評価だけでは，相手方は必要な日数を判断できない。部品調達に何日を要するのか，仕様の確定日がいつか，発注者の資料提供がいつまでに必要かを確認し，条文がその工程に合っていないことを説明する。

未確認の前提は断定しない。「営業担当者に確認したところ」などの情報源と，確認が必要な事項を社内資料に残す。相手方への説明では，合意に必要な範囲で事実と確認事項を示す。

２　変更の必要性と交渉の優先順位を決める

同じ修正履歴でも，適用法令との整合を確保する変更，取引の前提を明確にする変更，事業上受け入れられないリスクを下げる変更，単なる表現整理では重要度が違う。社内で優先順位を決め，全部の修正を同じ強さで要求しない。

法令違反を理由にする場合は，具体的な条文と適用条件を確認する。「不利だから違法」「当社のひな型と違うから無効」といった説明は避ける。修正に応じてもらえない場合の判断は，契約書を修正できないと言われたらで整理している。

第３　相手方へのコメントの基本形

１　事実，支障，提案及び確認事項をつなぐ

相手方へのコメントは，取引上の前提，現行条文では生じる具体的な支障，修正案が支障をどう解消するか，必要な回答という順に組み立てる。すべてを長文にする必要はなく，争点に応じて必要な要素を残す。

２　仕様変更のコメント例

以下は書き方を示す架空の例であり，個別案件にそのまま使用する条項ではない。

「追加機能の実装には，既存の仕様とは別の作業が必要になります。現案では追加作業も当初代金に含まれるように読めるため，追加費用と納期への影響を評価し，双方の書面合意後に着手する形に修正しました。緊急変更の場合の承認者と回答期限について，御社の運用を御確認ください。」

このコメントは，追加作業の存在，代金との関係，合意前の着手を避ける理由，運用上の確認事項を区別している。ただし，具体的な変更手続は契約書本文又は合意した別紙に定める。コメントだけに条件を残したまま，本文を整えずに締結しない。

変更管理の具体的な項目は，システム開発の仕様変更と追加費用を参照されたい。

３　損害賠償上限のコメント例

「本件の対価と当社の保険による対応範囲を踏まえ，損害賠償の上限を設ける案を提示しています。他方，故意・重過失など，上限の対象から除外する事由は別に協議したいと考えています。秘密保持違反も除外対象とする御提案については，対象情報，想定する損害及び保険の対象範囲を確認した上で回答します。」

これは上限額や除外事由が常に適切だという意味ではない。損害の範囲，責任主体，請求の根拠，上限の単位，例外及び保険の支払条件を確認する。交渉のために実在しない保険加入や社内決裁の事実を記載しない。

第４　社内コメントと相手方コメントを混ぜない

１　社内では選択に必要な情報を残す

社内向けには，修正できない場合の具体的な損失，起こり得る条件，回避策，実行責任者，判断期限を残す。法務が契約にコメントした事実と，事業部や決裁者が残るリスクを理解して引き受けた事実は異なる。

２　送信前にコメントの読者を確認する

社内だけのコメントを削除した相手方送付用ファイルを別に作り，本文，変更履歴，コメント，添付資料を確認する。単に画面上でコメントを非表示にしただけでは，ファイル内から削除されたとは限らない。使う編集ソフトの機能に応じて，実際に送信するファイルを開き直して確認する。

相手方から戻ったファイルにも，こちらが想定していない修正やコメントが含まれ得る。こちらの修正箇所だけを確認して，最終版全体の比較を省略しない。

第５　コメントのやり取りを交渉記録につなぐ

１　論点ごとに採否と残る条件を整理する

コメントの削除は，論点の解決と同じではない。採用，不採用，代案採用，事実確認待ちを区別し，最終条文又は別紙のどこに合意が反映されたかを記録する。

覚書や別紙で調整する場合は，本体契約と対象取引を特定し，矛盾した場合の適用関係を明らかにする。権限のある当事者が合意したかも確認する。担当者のメールだけで，本体契約の責任制限や変更手続が当然に変更されたと考えない。

２　版を特定し，合意した条件を回収する

ファイル名，作成日，又は管理番号で各版を特定し，送付した版と戻った版を比較する。修正コメントに「別紙で定める」と書いたなら，別紙が完成していることまで確認する。締結予定の版について，未回答のコメントと空欄を一覧にする。

AIで比較や説明案の作成を補助する場合も，入力できる情報の範囲と契約上の許可を先に確認する。AIの出力を採用した理由，前提事実との一致及び最終条文の整合性は人が確認する。AI契約書レビューの実機テストも参照されたい。

第６　締結前に行う最終チェック

最終チェックでは，交渉中に解決したはずの条件が，締結用の本文と添付資料に反映されているかを確認する。文字の修正だけでなく，その変更が他の条項に与える影響を追う。

締結後は，更新や通知の期限，検収担当者，変更の承認者などを実行担当者に引き継ぐ。審査担当者の手元だけに確認表を残すと，契約上の権利を使う時期を逃し得る。

第７　参考資料

松尾剛行『実務の落とし穴がわかる！契約書審査のゴールデンルール３０』（学陽書房，２０２４年）１２～４１頁，１８２～１８９頁。取引の目的とリスクを踏まえた審査，事業部との対話，交渉及び最終チェックの考え方を参照した。上記のコメント例と表は，その考え方を踏まえた本稿の整理である。

契約の成立と方式，契約の自由については，民法５２１条・５２２条を参照されたい。個別の修正が必要かどうかは，その取引に適用される法令と前提事実に即して判断する。