乗合バスの運行管理者から出る遅延・事故・車両の不具合のときの取扱いの質問に、運行管理規程と運輸局の通達を根拠に答える

処理の起点を決める

起点は、運行管理者が営業所の端末の問い合わせ画面で送信したことです。 無線を受けながら打てるよう、項目は選ぶものを中心にします。営業所と系統が欠けると、どの路線の決まりで答えるかが決まりません。 画面で必須にします。

「人身・火災・急病」を選んだら、送信の前に初動の手順が出ます。 救護、119番・110番、乗客の安全の確保、本社への第一報の順で、営業所の壁に貼ってあるものと同じ文面です。この場面では answer メソッドを呼びません。 落ち着いた後で「その後の取扱い」を聞くときは、場面を「事故・接触」に変えて送ります。

もう一つのトリガーは、通達・指示文書の発出と、規程・手引き・路線の決まりの改正です。 本社の運輸課の担当が文書を置き、メタデータに効力の期間と対象の営業所を書きます。取り込みは毎晩まとめて行いますが、異常気象に伴う臨時の指示文書は、出したその場で取り込みを始めます。

入力データを集める

質を決めるのは、すべての文書に付ける「対象の営業所・系統」と「効力の期間」です。 迂回の決まりに系統を書いておかないと、別の系統の折返し場所が引かれます。 期間を限った指示文書に終わりの日を書かないと、工事が終わった後も迂回の指示が引かれます。

営業所の路線の決まりは、紙のファイルを文書にするところから始まります。 ここが無いと、回答は規程と手引きの一般論で止まり、運行管理者がいちばん知りたい「この系統でどこで折り返すか」に答えられません。

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

規程と手引きは章ごとに、通達・指示文書・路線の決まり・回答は1件ずつファイルにして Cloud Storage に置きます。公式では、非構造化データは TXT・JSON・Markdown・PDF・HTML・DOCX・PPTX・XLSX・XLSM に対応し、1ファイルの上限は200MB、1回の取り込みで10万ファイルまでです。メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"route-rule-east-12","structData":{"doc_kind":"route_rule",
 "office":["east"],"route":["12","12A"],"scene":["detour","delay"],
 "effective_from":"2026-09-01T00:00:00Z",
 "effective_to":"2099-12-31T23:59:59Z"},
 "content":{"mimeType":"text/html","uri":"gs://bus-ops/route-rule-east-12.html"}}

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

office: ANY("east") AND route: ANY("12","all")
AND scene: ANY("detour","delay")
AND effective_from <= "2026-10-20T06:40:00Z"
AND effective_to >= "2026-10-20T06:40:00Z"

系統の絞り込みに all を必ず足します。 全系統に効く規程と手引きを落とさないためです。逆に、office には全社の文書にも営業所を並べて書き、別の営業所の路線の決まりが引かれないようにします。

AIへ渡す前に整形する

1. 規程と手引きを章ごとに分ける … 章・節の番号と見出しが崩れないよう、元の文書からHTMLで書き出します
2. 路線の決まりを系統ごとに文書にする … 紙のファイルを、系統・迂回の経路・折返しの場所・連絡先の形で書き起こします
3. 版と効力の期間を付ける … 改正の履歴から、版ごとの施行日と終わりの日を書きます
4. 通達と指示文書に対象と期間を付ける … 本文の「○月○日から」「当分の間」と対象の営業所を、本社の担当が読んで書きます
5. 回答集を整える … 過去の相談の記録を、根拠の箇所を確かめて1件ずつ文書にします。乗客と運転者の氏名は外します
6. 連絡の要点から個人の情報を外す … 乗客の氏名や連絡先、運転者の氏名が書かれていたら、検索の質問文から外します

4番目の「当分の間」は、機械に任せません。 終わりの日の無い指示は、effective_to を遠い日付にしたうえで、本社の担当が3か月ごとに効いているかを確かめる一覧に載せます。 終わりの日を推し量って入れると、まだ効いている指示が黙って外れます。

AIに処理させる

させるのは、その営業所と系統に効く規程・手引き・通達・路線の決まりから該当箇所を探し、引用して取扱いの手順を並べることです。

4つ目の「確かめる事実を挙げる」が、運行管理者にいちばん効きます。 「乗客が転んだ」という連絡でも、けががあるか、病院に行くか、車内か停留所かで、手引きの当たる節と報告の基準の当てはまり方が変わります。何を運転者に聞けばよいかが先に分かれば、無線のやり取りが一往復で済みます。

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

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。中継プログラムは、画面の項目を検索の文の先頭に付けます。

あなたは乗合バス会社の本社の運輸課の担当として、営業所の
運行管理者からの運行中の取扱いの問い合わせに、運行管理規程・
乗務員の手引き・通達と指示文書・営業所の路線の決まりを根拠に
回答を作る立場です。読むのは、無線で運転者とやり取りしている
運行管理者です。短く、手順の順に書いてください。

【前提】
検索の文の最初に、場面の種類、営業所、系統、出来事の日時、
運転者からの連絡の要点が並んでいます。
検索の対象は、その営業所と系統に、その日時に効く文書だけです。

【答え方】
1. 最初に、運転者に確かめることを3つまで箇条書きにする
2. 次に、取扱いの手順を、文書の名前と章・条・節の番号を付けて順に並べる
3. 手順の根拠の本文を、そのまま引用する
4. 当てはまる通達・指示文書があれば、番号と期間を書いて引用する
5. その系統の路線の決まり（迂回・折返し・代わりの車両）があれば引用する

【厳守事項】
- 検索結果に無い取扱い、別の営業所や系統の決まりで答えないでください。
- 運行を続けてよい、止めるべき、と結論を書かないでください。
  文書が定める確かめ方と、判断する人を書いてください。
- 事故の報告が要る・要らないと書かないでください。
  報告の基準は別に添えられます。
- 社内の基準の数値（風速・雨量・遅れの分数など）は、
  文書の本文のまま引用し、今の状況に当てはまるかは書かないでください。
- 回答集だけが根拠のときは、そのことと判断した日を書いてください。
- 一般的なバス会社の慣行や、他社の例で補わないでください。
- 該当する箇所が見つからないときは、
  「該当する箇所は見つかりませんでした。本社の運輸課に相談してください」
  とだけ書いてください。

「運行を続けてよいと書かない」を明記しないと、AIは手引きの確かめ方から結論を出します。 「ミラーの破損は運行に支障がない場合に限り」と書かれた節を引き、そのまま「運行を続けてかまいません」と書きます。支障があるかを見ているのは運転者と整備管理者で、AIではありません。

出力形式を固定する

answer メソッドの返り値と添付する条文を、中継プログラムが次の形にまとめます。

{
  "inquiry_id": "",
  "office": "",
  "routes": [],
  "scene": "accident | vehicle_defect | delay | detour | weather | passenger | other",
  "occurred_at": "",
  "facts_to_confirm": [],
  "steps": [
    { "order": 1, "text": "", "doc_kind": "rule | manual | notice | route_rule | answer",
      "title": "", "section": "", "quote": "", "uri": "" }
  ],
  "report_criteria_attached": false,
  "route_decision": "self | escalate",
  "escalate_reason": []
}

steps の引用は、answer メソッドの references から取ります。引用の位置（startIndex／endIndex）は UTF-8 のバイト数なので、日本語の文を文字数で切るとずれます。report_criteria_attached は、場面が事故・接触のときに中継プログラムが立て、画面の下に自動車事故報告規則の報告の基準と速報の条文を表示します。この表示はAIの返り値を使わず、毎回同じ文面です。

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

どれにも当たらないものだけが self です。 self でも、判断して運転者に指示するのは運行管理者です。escalate は「本社と一緒に判断する」という意味で、本社の当番の画面に回答と引用がそのまま並びます。

システムへ連携する

当番に回す1行には、問い合わせの内容、引用された箇所、escalate_reason を付けます。 当番は、ファイルを開くところからではなく、引用を読んで判断するところから始められます。夜間の電話が、探しものの相談から判断の相談に変わります。

人が確認する

この構成では、すべての回答を運行管理者が読んで判断します。 AIの回答が運転者に直接届く経路はありません。

1. 確かめることを運転者に聞く … facts_to_confirm を無線で聞き、答えを問い合わせの続きとして入れます
2. 引用を読んで手順を決める … 規程・手引き・路線の決まりの本文を読み、運転者に指示します
3. 事故・接触なら報告の基準を当てはめる … 添付の条文を読み、本社の当番と要否を確かめます
4. 判断を記録する … 何を根拠に、どう指示したかを対応の記録に書きます

3番目を省かないでください。 自動車事故報告規則は、事故の種類によって30日以内の報告書の提出と、24時間以内のできる限り速やかな速報を求めています。負傷の程度が後から分かることもあるので、その場で「不要」と決めず、本社と記録を残してから決めます。

本社の運輸課は、毎週 escalate の一覧を読み、同じ判断が続くものを回答集に登録します。

運用を始めてから2か月は、self の回答も本社の担当が後から全件読みます。 運行管理者の判断と回答の手順が食い違ったものが1割を超えるなら、文書の整備が先です。

例外に対処する

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

記録を残す

• 問い合わせの内容（5項目）、営業所、運行管理者、日時
• answer メソッドへの要求（絞り込みの条件、preamble の版）と返り値の全文
• 報告の基準の条文を添えたかどうか
• route_decision と escalate_reason、本社の当番の判断と理由
• 運行管理者が実際に行った指示（対応の記録として本人が書く）

AIの回答と、運行管理者が実際に指示したことを分けて残します。 後から事故の経緯を確かめるとき、どの根拠を見て何を指示したかを、回答の文面と混ぜずに示すためです。