鉄道の駅係員から出る払戻し・振替輸送・乗車券の取扱いの質問に、旅客営業規則と社内の取扱細則の条文を示して答える

処理の起点を決める

起点は、駅係員が業務端末の問い合わせ画面で送信したことです。 電話で受けていた問い合わせを画面に寄せます。発売日と取扱いの日が欠けると、どの版の条文で答えるかが決まりません。 画面で必須にしておけば、聞き返しが減ります。

もう一つのトリガーは、規則の改正と通達の発出です。 改正や通達があったら、営業課の担当が文書を置き、メタデータに効力の期間を書きます。取り込みは毎晩まとめて行いますが、運転の乱れに伴う臨時の通達は、出したその場で取り込みを始めます。

入力データを集める

質を決めるのは、すべての文書に付ける「種類」と「効力の期間」です。 通達に終わりの日を書いておかないと、期間が過ぎた特例がいつまでも引かれます。 規則と細則は改正のたびに版を足し、前の版に終わりの日を書きます。

振替輸送の手配の記録は、検索に入れません。 時々刻々と変わるもので、毎晩の取り込みでは間に合わないうえ、「いま行っているか」は文書の検索ではなく記録の照会で答えるべきことだからです。

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

規則・細則は章ごとに、通達と回答は1件ずつファイルにして Cloud Storage に置きます。公式では、非構造化データは TXT・JSON・Markdown・PDF・HTML・DOCX・PPTX・XLSX・XLSM に対応し、1ファイルの上限は200MBです。メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"notice-2026-118","structData":{"doc_kind":"notice",
 "topic":["refund","suspension"],"ticket_kind":["ordinary","limited_express"],
 "effective_from":"2026-10-01T00:00:00Z",
 "effective_to":"2026-11-30T23:59:59Z","date_basis":"use_date"},
 "content":{"mimeType":"text/html","uri":"gs://rail-rules/notice-2026-118.html"}}

問い合わせのたびに、中継プログラムが絞り込みの条件を作ります。 公式の構文では、文字の項目は ANY() に並べた値のどれかと完全に一致するかを見られ、日時の項目は ISO 8601 の文字列と比べられます。

topic: ANY("refund","suspension") AND ticket_kind: ANY("ordinary")
AND effective_from <= "2026-10-20T00:00:00Z"
AND effective_to >= "2026-10-20T00:00:00Z"

date_basis は、通達ごとに書きます。 「この期間に発売した乗車券」を対象にする通達と、「この期間に乗車する旅客」を対象にする通達があり、同じ問い合わせでも、どちらの日付で見るかで当てはまるかが変わります。 中継プログラムは、date_basis に応じて発売日か取扱いの日を絞り込みに入れます。項目はスキーマで索引可能にしておかないと絞り込みに使えません。

AIへ渡す前に整形する

1. 規則と細則を章ごとに分ける … 条番号と見出しが崩れないよう、文書管理の仕組みからHTMLで書き出します
2. 版と効力の期間を付ける … 改正の履歴から、版ごとの施行日と終わりの日を書きます
3. 通達に期間と日付の基準を付ける … 本文の「○月○日から○月○日まで」と「発売」「乗車」の語から、date_basis を担当が決めて書きます
4. 回答集を整える … 過去の回答を、根拠の条文を確かめて1件ずつ文書にします。旅客の個人の情報は外します
5. 申し出の内容から個人の情報を外す … 旅客の氏名や連絡先が書かれていたら、検索の質問文から外します
6. 運賃表と手数料の額の表は取り込まない … 規則の別表のうち額の表は検索の対象から外し、条文だけを残します

3番目は機械に任せません。 通達の書き方は一定でなく、期間の基準を読み違えると、特例を当てはまらない旅客にまで広げることになります。

6番目で額の表を外すのは、AIに額を書く材料を渡さないためです。 指示で額を禁じても、検索の結果に額の表があれば、回答に数字が混ざりやすくなります。額を出す場所を発券の端末だけにしておけば、窓口で伝わる額は一つに決まります。

AIに処理させる

させるのは、取扱いの日に効く規則・細則・通達から該当する条文を探し、引用して回答案を書くことです。

4つ目の「確かめる事実を挙げる」が、駅にいちばん効きます。 運転が止まったときの取扱いは、旅客がどこまで乗っていたか、旅行をやめるのか続けるのかで変わります。何を聞けばどの条文が当てはまるかが分かれば、営業課に2度電話せずに済みます。

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

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。中継プログラムは、振替輸送の手配の記録を引いた結果を検索の文の先頭に付けます。

あなたは鉄道会社の営業課の担当として、駅係員からの乗車券の
取扱いの問い合わせに、旅客営業規則・取扱細則・通達を根拠に
回答案を作る立場です。読むのは窓口にいる駅係員です。

【前提】
検索の文の最初に、取扱いの種類、乗車券の種類、区間、発売日、
取扱いの日、振替輸送の手配の照会結果が並んでいます。
検索の対象は、取扱いの日に効力のある規則・細則・通達と回答集だけです。

【答え方】
1. 関係する規則の条文を、規則の名前と条番号を付けて本文のまま引用する
2. 窓口の手続きを、取扱細則の条番号を付けて順に並べる
3. 当てはまる通達があれば、通達の番号と期間を書いて引用する
4. 条文を当てはめるために旅客に確かめることを箇条書きにする
5. 最後に、条文から読める範囲で回答案を2〜3文で書く

【厳守事項】
- 検索結果に無い条文、他社の規則で答えないでください。
- 払戻しの額・手数料・差額を書かないでください。計算もしないでください。
  「額は発券の端末で確かめてください」と書いてください。
- 振替輸送を行っているかは、照会結果だけで書いてください。
  照会結果に手配が無ければ「手配は登録されていません。
  指令に確かめてください」と書いてください。
- 「払い戻せません」「取り扱えません」と断定しないでください。
  条文の書き方のまま書いてください。
- 回答集だけが根拠のときは、そのことと答えた日を書いてください。
- 一般的な鉄道の慣行や他社の例で補わないでください。
- 該当する条文が見つからないときは、
  「該当する条文は見つかりませんでした。営業課が確認します」
  とだけ書いてください。

「額を書かない」を明記しないと、AIは条文の手数料と運賃から額を計算します。 区間の運賃、手数料、既に乗った区間の差し引きを組み合わせる計算で、一つ誤れば、窓口でその額を旅客に伝えることになります。 額は発券の端末にしかない正しい計算に任せます。

出力形式を固定する

answer メソッドの返り値と手配の照会を、中継プログラムが次の形にまとめます。

{
  "inquiry_id": "",
  "station": "",
  "handling_type": "refund | suspension | transfer | excess | lost | pass | other",
  "sale_date": "",
  "handling_date": "",
  "transfer_arrangement": { "found": false, "section": "", "carriers": [], "from": "", "to": "" },
  "citations": [
    { "doc_kind": "rule | detail | notice | answer", "title": "", "article": "",
      "quote": "", "effective_from": "", "effective_to": "", "uri": "" }
  ],
  "procedure": [],
  "facts_to_confirm": [],
  "answer_text": "",
  "route": "answer | refer",
  "refer_reason": []
}

citations は、answer メソッドの references から取ります。引用の位置（startIndex／endIndex）は UTF-8 のバイト数なので、日本語の文を文字数で切るとずれます。transfer_arrangement はAIの返り値を使わず、手配の記録の照会結果をそのまま入れます。

route は次の規則で決めます。

どれにも当たらないものだけが answer です。 revision_between は、改正前に買った乗車券をどちらの版で扱うかを、改正の附則や細則で確かめる必要があるためです。この判断はAIにも中継プログラムにも置かず、営業課に置きます。

システムへ連携する

待ち行列の1行には、問い合わせの内容、引用された条文、refer_reason、手配の照会結果を付けます。 担当は、探すところからではなく判断するところから始められます。

人が確認する

人が確認するのは refer の問い合わせです。 answer の回答は駅の端末へ直接返しますが、運用を始めてから2か月は、全件を営業課の担当が見てから返します。

1. refer_reason を見る … 断る方向か、改正をまたぐか、額が書かれたかを確かめます
2. 条文を当てはめる … 引用された条文と、駅が確かめた事実から取扱いを決めます
3. 駅へ返し、回答集に登録する … 根拠の条文と判断の理由を付けます

駅係員は、answer の回答でも条文を読んでから取り扱います。 額は必ず発券の端末で確かめます。回答の画面には「役に立たなかった」の印を付けられるようにし、印の付いた回答は翌日に営業課が読み、回答集か振り分けの規則を直します。

運転が乱れた日は、営業課の担当のうち1名を待ち行列の専任にします。 同じ区間・同じ種類の refer が続くので、最初の1件を判断したら、その判断を回答集に急ぎで登録し、以降の問い合わせが answer で返るようにします。

2か月の全件確認で、answer の中に担当が見れば refer にしたものが1割を超えるなら、answer の直接の返信を始めません。

例外に対処する

6行目の額の検知は、プロンプトとは別に、中継プログラムの文字列の照合で行います。 最後の門は機械の照合に置きます。

記録を残す

• 問い合わせの内容（6項目）、駅、係員、日時
• answer メソッドへの要求（絞り込みの条件、preamble の版）と返り値の全文
• 振替輸送の手配の照会結果
• route と refer_reason、営業課の担当の判断と理由
• 駅へ返した回答と、返した日時

手配の照会結果を残すのは、後から取扱いを問われたときのためです。 その時刻に手配が登録されていたかを示せないと、駅の取扱いが正しかったかを確かめられません。