資材の値上がりで契約金額を変更するとき、管理の成否を分けるのは「どの時点で起票するか」の設計です。値上がりの検知起点は複数あり、どれを正式なトリガーにするかで残るデータが変わります。本記事では起点の選び方と、後から第三者が差額を再現できる記録構造を示します。
結論：正式な起票トリガーは「発注可能な再見積を取得した時点」に置く
資材高騰を検知する起点は、実務上おおむね3つあります。
- 仕入先からの価格改定通知（「◯月納品分より改定」といったFAX・メール・PDF）
- 見積の再取得（有効期限切れ、または発注直前の単価確認）
- 実績原価と実行予算の乖離（発注伝票や請求書が上がってきて初めて気づく）
このうち変更申請を正式に起票するトリガーは2の再見積に一本化し、1は予兆アラート、3は取りこぼし検知として別の扱いにする設計が管理しやすくなります。理由は、発注者や元請に提示できる差額の根拠が「その単価で実際に調達できること」を示せる資料に限られるためです。価格改定通知は仕入先の一方的な意思表示であり、数量・納期・規格を反映した金額にはなっていません。実績原価の乖離は事後であり、変更協議の前に発注を済ませてしまっている状態です。
| 検知起点 | 気づくタイミング | 正式トリガーにした場合の弱点 | 推奨する扱い |
|---|---|---|---|
| 仕入先の価格改定通知 | 発注前（早い） | 品目コードに紐付かない表記で届く。適用開始日が案件工程と合わず、対象案件を特定できない | 予兆アラート。影響しうる案件を一覧化し、再見積の取得を促す |
| 見積の再取得 | 発注直前 | 取得を忘れた品目は検知できない | 正式な起票トリガー。数量・納期込みで差額が確定する |
| 実績原価と実行予算の乖離 | 発注後・請求時（遅い） | 変更協議より先に発注済みで、増額を飲み込むしかなくなる | 取りこぼし検知。月次で洗い出し、再見積プロセスの漏れとして原因を潰す |
つまり1と3は「2に変換するための入口」であり、変更申請レコードの起票点は1か所に統一します。この整理をしないまま3系統から申請が上がると、同じ品目の増額が別番号で二重に申請される事故が起きます。
差額計算の基準日を案件ごとに固定する
契約金額の変更で最初に揉めるのは、値上がり後の単価ではなく「何と比べた値上がりか」です。同じ鉄筋でも、比較対象を次のどれに置くかで差額は変わります。
- 自社が見積を提出した日の単価
- 契約を締結した日の単価
- 発注者の設計書（積算）に計上された単価
- 実行予算を組んだ日の単価
公共工事では発注者の設計書単価が基準になり、民間工事では自社の見積提出時点の単価が基準になる、といった違いが出ます。案件マスタに「価格基準日」と「基準単価の出所」を必須項目として持たせ、案件登録時に確定させてください。ここを空欄のまま進めると、増額申請の段階で経理・工務・営業がそれぞれ違う数字を出してきます。
基準日を固定したうえで、変更申請に載せる差額は次の式で機械的に算出できる形にします。
増額 ＝ Σ（品目ごとの残数量 × （再見積単価 − 契約前提単価））
残数量を使う点が重要です。すでに旧単価で発注・納品済みの分まで増額対象に含めると、根拠資料と実際の仕入伝票が合わなくなります。
単価は上書きせず、契約前提を凍結する
資材単価マスタを常に最新値で上書きしている会社は、値上がりの説明ができません。契約時点の前提が消えているためです。最低限、次の分離が必要です。
| テーブル | 主な項目 | 役割 |
|---|---|---|
| 品目マスタ | 品目コード、規格、単位、代替品目コード | 表記ゆれを1つのコードに寄せる |
| 単価履歴 | 品目コード、仕入先、単価、適用開始日、出典種別（改定通知／見積／実績伝票）、根拠資料ID | 追記のみ。更新も削除もしない |
| 契約前提単価 | 案件、品目コード、採用単価、価格基準日、根拠見積ID | 案件ごとに凍結。以後変更しない |
| 乖離検知 | 案件、品目、前提単価、最新単価、残数量、差額、検知起点、検知日 | 起票前の候補。承認対象ではない |
| 変更申請 | 申請番号、案件、対象品目群、増額合計、協議相手、提出日、状態 | 承認と対外提出の単位 |
| 承認履歴 | 申請番号、承認者、役割、日時、判定、差戻理由 | 誰がいつ何を見て通したかを残す |
| 根拠資料 | ファイル、発行元、受領日、種別、紐付け先（単価履歴ID／申請番号） | 第三者説明用の原本 |
設計上の要点は3つです。
単価履歴は追記のみ。 「いつからいくらになったか」を時系列で並べられれば、値上がりの経緯そのものが説明資料になります。上書き型だと監査時に再現できません。
根拠資料は単価履歴に紐付ける。 変更申請にファイルを直接添付する運用にすると、同じ改定通知が複数案件でコピーされ、後から差し替えが効かなくなります。資料は単価履歴に1回だけ登録し、申請からは参照します。
乖離検知と変更申請を別テーブルにする。 乖離は毎日大量に出ますが、申請するのはその一部です。同一テーブルに「未申請」ステータスで混ぜると、承認待ち件数が実態と合わなくなります。
関連する平常時の原価の流れは、建設資材の発注・納期管理を仕組み化する設計手順で扱っています。本記事の仕組みは、そこで確定した発注単価の前提が崩れた場合の差分管理にあたります。
承認フローは「社内決裁」と「対外協議」を分ける
1件の変更申請に社内承認と発注者協議を同居させると、状態管理が破綻します。次のように2段構えにします。
- 社内決裁：増額を発注者に請求するか、自社で吸収するかを決める。金額帯で承認権限を分ける（現場代理人 → 工事部長 → 役員）。吸収と決めた場合も申請は残し、「自社負担」として記録する。ここを削除すると、原価の悪化理由が翌年度に追えなくなります。
- 対外協議：発注者・元請への提出、協議、合意、変更契約の締結。状態は「提出済／協議中／一部認容／不認容／変更契約締結」程度に分け、各状態の遷移日を持ちます。
差戻しには必ず理由コードを付けます。実務で繰り返し出るのは「根拠資料の日付が価格基準日より前」「残数量が発注済み分を含む」「対象外品目が混入」あたりです。理由コードを集計すれば、申請テンプレートのどこを直すべきかが分かります。
仕様変更に伴う増額の管理は注文住宅の仕様打合せと変更契約を仕組み化する設計で扱っており、数量・仕様が動く変更と、数量は同じで単価前提だけが動く本記事の高騰対応は、申請を分けて管理してください。
架空の記入例：変更申請1件
以下は架空の記入例です。実在の取引・価格ではありません。項目の粒度を確認する目的で示します。
申請番号 : PC-2026-0034
案件 : ◯◯線道路改良工事
価格基準日 : 2026-02-10（自社見積提出日）
基準単価の出所 : 見積番号 EST-1182
対象品目1
品目コード : STL-D16
規格 : 異形棒鋼 D16 SD295
契約前提単価 : 105,000 円/t（根拠: 見積 EST-1182 / 2026-02-10）
再見積単価 : 118,000 円/t（根拠: 見積 EST-1447 / 2026-06-18 / ◯◯鋼材）
契約数量 : 42.0 t
発注済数量 : 12.0 t（旧単価、伝票 PO-2211）
残数量 : 30.0 t
差額 : 30.0 t ×（118,000 − 105,000）= 390,000 円
先行アラート : 2026-05-22 受領「2026年7月納品分より改定」通知（資料ID DOC-0912）
増額合計 : 390,000 円
社内決裁 : 2026-06-20 工事部長 承認 / 発注者へ請求とする
対外協議 : 2026-06-24 提出 → 2026-07-08 協議中
ポイントは、先行して受領していた価格改定通知（DOC-0912）を申請に添付せず、経緯として参照だけしている点です。差額の根拠はあくまで新旧の見積2通であり、通知は「いつから値上がりを把握していたか」を示す補助資料として位置づけます。
スライド条項を扱うときの前提
公共工事では、発注者が定める約款にいわゆるスライド条項が置かれている場合があります。ただし、条項があれば自動的に契約金額が上がるわけではありません。適用の要件、対象となる資材の範囲、請求できる時期、協議の手続は、適用される約款や特記仕様書の定めによって異なります。呼称や運用も発注者ごとに違うため、案件着手時に該当条文を確認し、案件マスタに「適用条項」「請求可能時期」をメモとして持たせておくのが現実的です。法令・約款の解釈に関わる判断は、発注者および専門家にご確認ください。
システム側が担うのは要件判定ではありません。協議が始まったときに、対象品目・基準日・数量・新旧単価・根拠資料が欠落なく揃っている状態を作ることです。逆に言えば、この5点が揃っていない申請は、どんな条項があっても協議の土俵に乗りません。
民間工事で価格変動に関する条項がない契約では、増額は当事者間の協議によります。この場合こそ、値上がりの時系列（いつ通知を受け、いつ再見積を取り、いつ発注したか）が交渉材料になります。
システムでできないこと
- 増額が認められるかどうかは決められません。 認容・不認容は約款の解釈と協議の結果です。システムは根拠を揃えるところまでです。
- 仕入先からの改定通知の自動仕分けには限界があります。 通知は「異形棒鋼」「鉄筋D16」「SD295 D16」など表記がばらつき、案件で使っている品目コードに機械的に紐付きません。初期は人が品目コードを当てる工程が残ります。代替品目コードの辞書を運用の中で育てる前提で設計してください。
- 相場指数の自動取り込みは、そのまま契約変更の根拠にはなりません。 指数は傾向の説明には使えますが、協議で求められるのは自社が実際に調達する単価の証跡です。
- 発注済みの旧単価分を遡って増額対象にはできません。 残数量の切り出しを人が判断する場面は残ります。
まとめ
- 値上がりの検知起点は3つあるが、変更申請の正式な起票トリガーは「発注可能な再見積を取得した時点」に一本化する。改定通知は予兆、実績乖離は取りこぼし検知として扱う。
- 案件ごとに「価格基準日」と「基準単価の出所」を必須項目として確定させる。ここが空欄だと差額が人によって変わる。
- 単価マスタは上書きせず履歴として追記し、契約前提単価は案件ごとに別レコードで凍結する。
- 差額は残数量ベースで算出する。発注済み分を含めると仕入伝票と合わなくなる。
- 社内決裁と対外協議を別ステータスで管理し、自社吸収と決めた案件も記録として残す。
書類フォーマットが発注者ごとに違う場合の出力側の設計は、帳票テンプレート管理の設計｜様式変更に強い出力も併せてご覧ください。
ご相談について
エクサテックは、不動産・建設の現場に入り込んで業務の流れを把握したうえで、仕組み設計からWebアプリ構築までを同一チームで行っています。価格変動の記録が担当者のメールとExcelに分散していて、協議のたびに根拠を探し直している——そうした状態の整理からご相談いただけます。現状の申請書式と単価の管理方法をお持ちいただければ、どこから手を付けるべきかをお話しできます。
