物流センターの事務担当から出る「この荷主の保管料・荷役料はどう計算するか」の質問に、荷主ごとの寄託契約・料金表・覚書を根拠にチャットで答える

処理の起点を決める

起点は、事務担当が社内のチャット画面で荷主を選び、質問を送ったことです。 画面は社内の ID でログインした業務管理課と物流センターの主任だけが使い、荷主は使いません。 荷主と対象の期間を選ばないと送信できない作りにします。

荷主は、取引中の荷主の一覧から選ばせます。 質問の文に荷主の名前を書かせて推定させると、グループ会社どうしの似た名前の荷主を取り違える余地が残ります。荷主のコードを画面の側で確定させます。

対象の期間は、既定を「今日」にし、請求の締めのときは月を選べるようにします。 1件の質問は1つのセッションで続け、「その作業はパレット単位か」と聞き足すと同じセッションで絞り直します。別の荷主の質問は、新しいセッションで始めます。

入力データを集める

質を決めるのは、文書ごとのメタデータです。 文書ごとに、荷主のコード、文書の種類（契約／料金表／覚書／約款）、適用開始日、適用終了日、締結日を付けます。締結日と適用開始日は別の項目にします。 第3章の（b）は、この2つを1つの日付で持っていることから起きます。

約款は、荷主ごとの文書として扱います。 自社の約款の旧の版と新しい版を、同意を得た日を境に、その荷主のコードを付けて取り込みます。同意を得ていない荷主には旧の版だけが付きます。

データの取得方法を決める

文書は Cloud Storage に置き、メタデータ付きでデータストアへ取り込みます。 料金表は Excel で持っていることが多いので、表のまま取り込める形式で入れます。 レイアウトの解析は PDF・HTML・DOCX・PPTX・XLSX・XLSM の配置を検出し、表と見出しを見分けます。

絞り込みの式は、荷主と対象の期間で書きます。 項目を索引可能にしておけば、shipper_id: ANY("S0217") AND valid_from <= "2026-09-30" AND valid_to >= "2026-09-01" のように、その荷主の、対象の月に一日でも効いていた版を引けます。月の途中で改定があった月は、改定の前と後の両方が引かれ、答えに両方の規則が日付付きで並びます。

荷主のコードと期間は、画面で選んだ値を中継プログラムが式に入れます。 モデルにも事務担当にも書かせません。

AIへ渡す前に整形する

1. 荷主ごとに文書を集める … 契約書、別表の料金表、覚書、見積書のうち合意したものを、荷主のコードの付いた場所に置きます
2. 料金表の版を分ける … 改定のたびに上書きされた料金表は、版ごとに別のファイルにして期間を付けます
3. 覚書の適用日を書き出す … 本文の「○年○月○日出庫分から」「○月の期から」を読み、valid_from に入れます
4. 料金表の注記を表から切り離さない … 「※検品は入庫料に含む」の注記は、表の同じ文書に残します
5. 約款を荷主に付ける … 同意の記録を見て、旧の版か新しい版かをその荷主のコードで取り込みます
6. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします
7. 単価以外の取引条件を消さない … 最低料金、端数の扱い、割増しの条件は料金表の一部として残します

3番目は、営業の担当者に確かめながら入れます。 覚書の適用日は、本文の書き方が荷主ごとにばらばらで、「次回の期から」としか書かれていないこともあります。 読み取れないものは空にせず、営業に聞いて埋めます。

6番目は、データストアを作る前に決めます。 分割はデータストアの作成後に有効にも無効にもできず、見出しを含める設定は既定では無効です。 「1パレット当たり」の断片は、見出しが無いと保管料の行か荷役料の行か分かりません。 分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、その荷主の文書から質問に当たる取り決めを見つけ、計算の規則を決まった項目に分けて、根拠と適用日付きで並べることです。 金額の計算と、請求するかどうかの判断はさせません。

新しい約款の第4条は、この最後の区分に関わります。 搬出入車両内での手荷役、仕分、全数検品・開梱検品、ラベル貼りその他の通常の倉庫業務（保管、庫入庫出）に附帯する業務を委託されたときは、倉庫業者が別途定める料金又は実際に要した費用を請求できるとし、十分な時間的余裕のない入出庫の指図や指図の取消しには別途費用を請求できるとしています。旧の約款のままの荷主では、この条を根拠にできません。

answer メソッドの設定は次のようにします。

2行目がいちばん起きやすい失敗です。 全数検品の料金が料金表に無いと、モデルは新しい約款の第4条を引いて「別途請求できます」と書きます。約款が請求できるとしていても、いくらで請求するかは決まっていません。 標準約款の改正の資料は、附帯業務の料金を定めたときは定めた日から30日以内に料金の設定を届け出る必要があるとしています。取り決めが見つからない作業は「取り決めが見つからない」で止め、営業へ回します。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは倉庫会社の業務管理課で、荷主への請求を担当する事務職員を手伝う立場です。
選ばれた1社の荷主の寄託契約、料金表、覚書、適用する約款から、
質問された作業や料金の計算の規則を探します。読むのは社内の事務担当です。

【答え方】
1. 料金の種類ごとに、次の項目を分けて書いてください。
   単位／期の数え方／単価／含む作業／別料金の作業／適用期間
2. 単価と数字は、料金表と覚書の文のまま写してください。
3. 根拠にした文書の種類（契約／料金表／覚書／約款）、条または表の行、
   覚書の締結日と適用開始日を書いてください。
4. 対象の期間の途中で改定がある場合は、改定の前と後を分けて並べてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  他の荷主の料金や、一般的な倉庫料金の相場で補わないでください。
- 金額の計算をしないでください。件数や期の数を掛けた結果を書かないでください。
- 「請求できます」「請求して問題ありません」と書かないでください。
- 料金表と覚書に当たる取り決めが無い作業は「取り決めが見つからない」とし、
  約款の条だけを根拠に料金があるように書かないでください。
- 文書どうしで食い違うときは、どれが優先するかを決めず、
  食い違う箇所を並べて「営業の確認が要る」と書いてください。
- 覚書の締結日を、適用開始日として扱わないでください。

「金額を計算しない」を書くのは、計算が正しくても困るからです。 請求の機能は最低料金と端数の扱いを持っています。画面にもう1つの金額が出ると、どちらが正しいかを毎回確かめる作業が増えます。 規則までで止め、金額は1か所で出します。

「締結日を適用開始日として扱わない」も、明記しないと崩れます。 覚書の冒頭には締結日が大きく書かれ、適用日は本文の途中にあります。何も言わなければ、目立つほうの日付を使います。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、画面と記録に渡します。

{
  "query_id": "",
  "session_id": "",
  "staff_id": "",
  "shipper_id": "S0217",
  "period": { "from": "2026-09-01", "to": "2026-09-30" },
  "question": "",
  "rules": [
    { "fee_type": "storage | handling_in | handling_out | ancillary | surcharge",
      "unit": "", "period_rule": "", "unit_price_text": "",
      "included": [""], "separately_charged": [""],
      "valid_from": "", "valid_to": "",
      "refs": [ { "doc_type": "contract | rate_table | memorandum | terms",
                  "location": "", "signed_on": "", "uri": "", "grounding_score": 0 } ] }
  ],
  "terms_version": "old | new",
  "not_found": [""],
  "conflicts": [ { "summary": "", "refs": [""] } ],
  "status": "answered | routed | skipped",
  "staff_feedback": { "setting_changed": false, "corrected": "", "note": "" }
}

1つ目の理由は、rules を料金の種類ごとに持てることです。 事務担当は、画面の規則と請求の機能の設定を同じ項目の並びで見比べられます。 単位が違う、含む作業が違う、が行ごとに分かります。

2つ目は、unit_price_text を文字列で持つことです。 単価を数値の項目にすると、「1パレット1期当たり」「最低1,000円」のような条件が落ちます。料金表の文のまま持たせ、数値にするのは請求の機能の側です。

3つ目は、terms_version と not_found で回し先を機械的に決められることです。 not_found に作業が1つでも入れば、画面は営業への確認のボタンだけを出します。 terms_version が old の荷主で新しい約款の条が根拠に出ていれば、その答えを止めます。

システムへ連携する

倉庫管理の仕組みの請求の機能には、つなぎません。 設定を直すのは事務担当で、画面の答えから設定が書き換わる経路を作りません。 誤った答えが、そのまま45社の請求に流れるのを防ぎます。

営業への確認の待ち行列には、荷主の営業担当を宛先にして載せます。 回答が来たら、営業が覚書を作るか、料金表の注記を足し、その文書を取り込むところまでを1件の完了とします。

人が確認する

事務担当は、毎回、根拠の料金表の行と覚書の条を開いて確かめます。 画面の答えだけで請求の設定を直さない運用にします。

1. 荷主と期間を確かめる … 画面の上に出る荷主のコードと期間が、問い合わせと合っているかを見ます
2. 根拠の版を見る … 覚書が根拠に出ていれば、適用開始日が対象の期間に入っているかを読みます
3. 単価を写す … 請求の設定に入れる単価は、画面の文ではなく根拠の料金表から写します
4. not_found と conflicts は営業へ回す … 事務担当の判断で料金を決めません

4番目を、事務担当の判断で済ませないでください。 取り決めの無い作業は、荷主と料金を決めるきっかけです。営業が荷主と話し、覚書か料金表に書いたところで請求できるようになります。

目標は、180件をならして1件8分です。 根拠を確かめて回答し、必要なら請求の設定と見比べるまでで、営業へ回るものは1割強という想定です。

例外に対処する

2行目と4行目は、運用の最初の数か月に集中します。 文書のそろえ方の穴が、そのまま答えの穴として出てきます。落ちた答えを数えると、どの荷主の文書から直すべきかが分かります。

記録を残す

• 質問の文、荷主のコード、対象の期間、担当者、日時、セッションの ID
• 絞り込みの式と、answer メソッドの応答の全文（出典と根拠のスコアを含む）
• 整えた答え（rules、terms_version、not_found、conflicts）
• そのとき参照した文書の版（文書の ID と valid_from・valid_to）
• 事務担当の評価と、請求の設定を直したかどうか
• 営業へ回した質問と、営業の回答、作った覚書

4つ目で「そのときの版」を残すのは、請求の後で荷主から問い合わせが来るためです。 「この月の検品料はどの取り決めで請求したのか」と聞かれたとき、当時効いていた料金表と覚書を、検索の記録から示せます。

5つ目の「設定を直したかどうか」は、請求の機能の設定のずれを見つける材料になります。 同じ荷主で何度も設定を直しているなら、契約の開始時の入れ方に問題があります。