改定日をまたぐ案件は、AIに新旧を推測させず、判定に使う日付と迷ったときの戻し先を決めておく

料金表や取引条件、社内の規程が新しくなる日（以下、改定日）の前後には、改定前に見積を出し、改定後に注文が届く、という案件が出ます。返信の下書きなどをAIに作らせている業務では、その案件をAIが旧い基準と新しい基準のどちらで扱うのかを、誰も決めていないことがあります。この記事は、AI化した業務の運用を任されている業務責任者の方に向けて、架空の案件を時系列に並べ、決めておくことと、改定直後の点検を分解して示します。

この記事に出てくるD社と案件は架空です。実在の会社や出来事ではなく、実績や事例の紹介でもありません。金額や日付の具体的な数字は書かず、「改定日」「前」「後」で示します。

扱うのは、社内の料金・規程・取引条件の話に限ります。契約にもとづく経過の扱いなど、法的な判断には入りません。資料を最新に保つことや旧版を整理することは、AIの運用を扱う解説記事でも取り上げられているため、ここでは主題にしません。AIに読ませる前の文書そのものの点検は、AIに社内文書を読ませる前の点検：どれが正か、判断の根拠、例外の扱い、更新の持ち主を文書ごとに確かめるにあります。

先に、この記事の結論を四つ挙げます。

• 改定日をまたぐ案件には、見積・注文・納品のどの日付で新旧を決めるかによって、扱いが分かれるものがあります。その日付を決めるのは、料金表と取引条件を持つ人であり、AIに推測させる事項ではありません。
• 決めた日付は、AIに渡る入力に載っている必要があります。載っていないときは、AIが料金を書かずに担当者へ戻す扱いにしておきます。
• 改定日の前後は、担当者の確認を厚くする期間を置きます。
• 改定の直後に、案件の日付の組み合わせごとに入力を用意し、旧基準のまま答えていないかを、同じ入力で確かめます。

料金表を差し替えても、改定前の案件の扱いは決まらない

D社（架空）は、保守サービスの見積と注文の問い合わせを受け付ける会社です。顧客からのメールを読んで、AIが料金表を参照しながら返信の下書きを作り、担当者が確認して送ります。見積書は営業担当が作って顧客へ送り、見積を出した日、注文を受けた日、納品する日は、担当者が使う案件管理表に記録されています。AIに渡るのは、メール本文と、料金表と、取り決めを書いた資料です。案件管理表はAIに渡っていません。

D社は改定日の前の週に新しい料金表を承認し、AIに参照させる料金表を新版に差し替える段取りを組みました。この差し替えは、これから届く案件には届きます。決まらないのは、改定前に見積を出した案件が、改定後に注文されたときの扱いです。

新版だけを渡した場合、AIが手がかりにできるのは新版の記載だけです。旧版も残した場合は、AIが両方を根拠にできてしまい、どちらを使うかを決める取り決めが別に要ります。そこで、旧版の置き方を、次のどちらかに決めます。

• 旧版を「改定前の案件にだけ使う」と明記して残す。この場合は、どの案件が改定前なのかをAIが知る手段が必要です。
• 旧料金で扱う案件は人が受け持ち、AIには渡さない。この場合は、改定前の案件を見分けて人へ回す役を、誰がいつ担うのかが必要です。

どちらの場合も、「どの案件が改定前なのか」を決める日付が要ります。

見積の日、注文の日、納品の日：どの日付で決めるかで答えが分かれる案件

この記事では、案件が改定日の前か後かを見て、新旧どちらの基準で扱うかを決めるときに使う日付を、判定日と呼びます。判定日とは、見積を出した日、注文を受けた日、納品する日のうち、新旧を分ける物差しとして選んだ一つの日付のことです。

D社に届きうる案件を、四つ並べます。改定日との前後だけを書いています。

案件（架空）	三つの日付（改定日との前後）	見積日で決めると	注文日で決めると	納品日で決めると
案件P	見積は前、注文は後、納品は後	旧料金	新料金	新料金
案件Q	見積は前、注文は前、納品は後	旧料金	旧料金	新料金
案件R	見積も注文も納品も前	旧料金	旧料金	旧料金
案件S	見積も注文も納品も後	新料金	新料金	新料金

案件RとSは、どの日付で決めても同じ結果になります。扱いが分かれるのは、案件PとQです。案件Pは見積日なら旧料金、注文日と納品日なら新料金になり、案件Qは納品日だけが新料金になります。AIが旧新を取り違えやすいのも、この二つの案件です。

料金の種類によって判定日が違うこともあります。たとえば、基本料金は注文日、出張にかかる費用は納品日、という分け方です。その場合は、料金の種類ごとに、判定日を一行ずつ書き出します。

判定日を決めるのは、AIではなく、料金表と取引条件を持つ人

どの日付を判定日にするかは、顧客への案内の文面、見積書に書いた内容、契約や取引条件の定めと関わります。この記事は、どの日付が適切かも、契約上の効力も判断しません。契約書や取引条件に定めがある場合は、まずそれを確認し、必要に応じて法務や専門家に相談してください。

決まったあとの作業は、AIに渡る取り決めの資料に、次の三行を書くことです。

• 改定日（料金の種類ごとに違うときは、種類ごとに）
• 判定日（見積日、注文日、納品日のどれか。料金の種類ごとに違うときは、種類ごとに）
• 判定日が入力にないとき、または複数あって決まらないときは、料金を書かずに担当者へ戻すこと

資料の側に、版や適用が始まった時期が書かれているかといった点検は、先に挙げた文書の点検の記事で扱っています。ここで書くのは、文書の書き方ではなく、案件の扱いの取り決めです。

改定日の朝、注文メールが届く：判定日がAIに渡っているか

改定日の朝、顧客E（架空）から、「先日いただいた見積のとおりで注文します」というメールが届きます。見積書は、改定日の前に営業担当が顧客Eへ送ったものです。案件Pにあたります。

この入力に対して、AIの下書きは、取り決めの置き方によって三つに分かれます。

• 入力に日付がなく、取り決めの資料にも戻す旨の記載がない場合：AIが手がかりにできるのは新版の料金表です。下書きは新料金で書かれます。見積書との食い違いに気づけるのは、担当者が見積書を開いて見比べたときだけです。
• 入力に見積日が載っていて、資料に「判定日は見積日。改定前に見積を出した案件は旧版で扱う」と書かれている場合：下書きは旧料金で書かれます。ただし、旧版がAIの参照先に残っていることが前提です。
• 入力に日付がなく、資料に「判定日が入力にないときは、料金を書かずに担当者へ戻す」と書かれている場合：下書きは料金を書かず、戻す旨の文面になります。

戻す文面の例を、架空の例として通常の段落に置きます。「この案件は、見積を出した日が入力に含まれていません。見積日が確認できるまで料金は記載せず、担当者へ戻します。」

日付を入力に載せる方法は、案件管理表から渡す、担当者が一行足す、など、使っている道具によって変わります。この記事では決めません。担当者が手で足す場合は、足し忘れた案件が「日付なし」として戻る取り決めにしておくと、新料金のまま下書きが出てしまう場面を避けやすくなります。取り決めどおりにAIが動くかどうかは、後の節の点検で確かめます。

改定日の前後は、確認を厚くする期間を置く

改定日の前後は、担当者が下書きを確認するときに、普段は見ない二点を足します。

• 案件の三つの日付と、下書きに書かれた料金が、旧版と新版のどちらのものか
• 料金を書かずに戻された案件について、戻された理由が取り決めに沿っているか

全件にこの確認を足すと、担当者の時間を使います。確認を厚くするのは、見積日が改定日より前の案件と、日付なしで戻った案件に絞る、という置き方もあります。どちらにするかは、担当者の人数と問い合わせの量で決めます。

期間の長さは、ここでは数字で示しません。改定前に見積を出して、まだ注文や納品に至っていない案件が案件管理表に残っている間を、一つの目安にします。終える日は先に決めておき、その日に、残りの案件を見て、延ばすか終えるかを判断します。

改定の直後に、同じ入力で、旧基準のままになっていないかを確かめる

資料を差し替えたら、実際の案件が届く前に、用意した入力で確かめます。

1. 入力を用意する。案件P、Q、R、Sにあたる想定メールを一通ずつ、さらに日付が入っていないメールと、見積日が二つ出てくるメール（再見積を出した案件を想定）を一通ずつ足します。
2. 期待する答えを、AIの出力を見る前に、人が書く。旧料金で書く、新料金で書く、料金を書かずに戻す、のどれかを、案件ごとに決めておきます。出力を見てから期待を決めると、出力に合わせてしまいます。
3. 同じ入力を、差し替えが終わった直後に流す。同じ入力でも、返ってくる文面は毎回少しずつ違うことがあります。見るのは文面の違いではなく、料金がどの版のものか、戻す扱いになっているかです。流す回数は自社で決めます。
4. 結果を三つに分ける。期待どおり、新旧が逆、戻すべき入力で料金を書いてしまった、の三つです。

この点検で分かるのは、用意した入力の範囲だけです。実際の案件には、用意した入力と違う形のものが届きます。そのため、前の節の確認を厚くする期間が、この点検を補います。

期待と違う結果が出たときは、指示、入力、参照させている資料、業務のルール、モデルのどこに原因があるかを、一か所ずつ確かめます。進め方は、AIの出力が期待と違うときは、症状から疑う場所を決めて、指示・入力・参照文書・業務のルール・モデルを1か所ずつ確かめるにあります。

判断がつかない案件は、料金を書かずに戻し、決まったことを資料に残す

取り決めの三行だけでは決まらない案件が出ることがあります。D社（架空）で出そうな例を挙げます。

• 改定前に出した見積を、改定後に内容を直して出し直した案件。見積日は、最初に出した日か、出し直した日か。
• 注文のメールに「旧料金のままで」と書かれている案件。
• 顧客ごとに個別に決めた料金があり、料金表の記載とは別に扱う案件。

戻し先は、料金表と取引条件の持ち主です。部署ではなく、役職または個人で決めます。部署にすると、誰も判断しない状態になりやすいためです。

AIが戻すときは、料金を書いた下書きを出さず、次の三点を添える取り決めにします。

• 案件を特定する番号
• 入力から分かった日付と、分からなかった日付
• 取り決めのどの行に当てはまらなかったか

持ち主が決めたら、その案件を処理するだけで終わらせず、取り決めの資料に一行足します。決めた人と日付も残します。足した一行によって、同じ種類の案件は、次からは戻されずに済む場合があります。資料や指示を変えた記録の残し方は、AI化した業務を、担当者が替わっても回し続けるために：残しておく記録と、運用の持ち主にあります。

この取り決めが向いている業務、先に別のことを決める業務

向いている業務は、次のような状態です。

• 見積を出した日、注文を受けた日、納品する日が、案件管理表のような、AIの外の記録に残っている
• 料金表の持ち主が決まっていて、改定日が事前に分かる

先に別のことを決めたほうがよい業務は、次のような状態です。

• 日付が顧客とのメールの中にしか残っておらず、記録の場所が決まっていない。判定日を決める前に、日付をどこに残すかを決めます。
• 顧客ごとの個別の料金が多く、料金表だけではAIの根拠として足りない。個別の料金の持ち主と置き場所を、先に決めます。
• 料金の種類ごとに改定日がばらばらで、一覧がない。種類ごとの改定日と判定日の一覧を、先に作ります。

当社の公開ページでの位置づけ

WITHPROJECTSの公開しているサービスページ（AI業務設計・業務AX）では、責任分界（AIの出力を誰が確認し、誰が最終判断するか）と例外処理（想定外のときの動き）を設計の最初に置くことと、稼働後の誤りや例外を見て直す運用改善の工程を案内しています。この記事の見方は、一般的な進め方の提案であり、WITHPROJECTSが提供する支援の内容や納品物を示すものではありません。

工程の全体はAI業務設計・業務AX：ツール導入ではなく、仕事の流れを再設計して実装まで任せるにまとめています。

改定日をまたぐ案件の扱いを、自社の業務で決めたいとき

自社の料金表や規程が変わる日の前後に、どの案件をどちらの基準で扱い、迷ったときにどこへ戻すかを、業務フローに沿って書き出すところから整理できます。

料金や規程が変わる日をまたぐ案件の扱いを、自社の業務フローに当てはめて整理したい方は、個別相談の予約へお進みください。（個別相談会（30分）の予約ページへ移動します）