ハイヤー会社が法人の契約先から届く乗務への意見・苦情の記録を毎月要約し、乗務員の指導と運行の改善の論点を作る

処理の起点を決める

毎月の第1営業日の朝に、前月の分をまとめて動かします。 記録が付くたびに動かすことはしません。1件ずつの要約は、営業所や契約先をまたいで並べて初めて意味を持つからです。

対象は、前月の1日から末日までに申出を受け付けた記録です。 月末に受け付けて、原因究明の結果が翌月に書き足される記録があります。原因究明の結果の欄が空の記録は、investigation_pending として今月の要約に入れ、翌月にも結果を書き足したものを入れ直します。 空のまま区分すると、申出の内容だけで原因の所在が決まってしまうからです。

月次の満足度の調査は、締切の翌営業日に回答を書き出します。 調査の締切が月末と違う場合は、締切に合わせて第1営業日のあとにもう一度動かします。

入力データを集める

質を決めるのは、運行の番号でひも付くかどうかです。 記録に運行の番号が書かれていれば、乗務員と指定の時刻が配車の記録から引けます。書かれていない記録は、契約先と受付の日時から近い運行を探すことになり、ひも付けの確からしさが下がります。

指定の場所と時刻を持たせるのは、原因の所在を確かめるためです。 「遅れた」という申出に対し、配車の記録の指定の時刻と実際の到着の時刻を並べると、乗務員の側の遅れか、指定そのものの行き違いかが分かります。 この比較は Python が行い、結果をAIに渡します。

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

営業所ごとの記録の列の名前は、読み込むときにそろえます。 営業所によって「原因」「調査結果」「確認結果」のように列の名前が違うことがあるため、5つの法定の項目への対応表を Python に持たせます。 対応の取れない列は、読み込みの段で止めて担当に知らせます。

満足度の調査の自由記述は、運行にはひも付けません。 月の全体についての声だからです。契約先と月だけを付けて、記録とは別の束として扱います。

AIへ渡す前に整形する

1. 列の名前の統一 … 営業所ごとの記録の列を、5つの法定の項目と受付の日時・手段・営業所にそろえます
2. 運行へのひも付け … 運行の番号で引き、無ければ契約先と受付の日時で候補を探し、確からしさを付けます
3. 時刻の差の計算 … 指定の時刻と実際の到着の時刻の差を、分で出します
4. 記号への置き換え … 乗務員の氏名を乗務員の番号に、契約先の担当者と乗客の氏名を 担当A・乗客B のような記号に置き換えます
5. 空の欄の印付け … 原因究明の結果・改善措置の欄が空のものに印を付けます
6. 事故・けがの申出の分離 … 事故やけが、物の破損に関わる申出は、要約の流れから外します
7. 区分の一覧の版の固定 … その月に使う区分の一覧の版を記録します

4番目を省かないでください。 役員の送迎の記録には、乗客である役員の名前と行き先が書かれていることがあります。誰がいつどこへ行ったかは、契約先にとって外に出せない情報です。 論点を作るのに、乗客の名前は要りません。

6番目は、要約の流れに乗せないでください。 事故やけがの申出は、保険と事故の報告の手順で1件ずつ扱うものです。

AIに処理させる

AIの仕事は2回に分けます。 1回目は記録1件ずつの要約と区分、2回目は営業所ごとと営業所をまたぐ論点の下書きです。

1回目（1件ずつ）

原因の所在は、調べた結果の欄からだけ決めさせます。 申出の内容だけで driver を付けると、乗務員に原因の無い指摘まで乗務員の指導に回ります。調べた結果の欄が空なら unclear です。 時刻の差の計算の結果は、その判断の材料として渡します。

2回目（まとめ）

Python が数えた件数と前月との差、1回目の要約と引用を渡し、営業所ごとに指導の論点を3つまで、営業所をまたいで運行の改善の論点を3つまで書かせます。論点には根拠の件数の記号と引用の記号を付けさせます。

3行目がいちばん起きやすい失敗です。 「約束の時刻に車が来なかった」という申出と、「契約先の秘書から指定された場所が本社の正面玄関で、実際の待ち合わせは別館だった」という調べた結果を渡すと、何も言わなければ区分を「時刻」、原因を「乗務員」にしてきます。申出の言葉のほうが強いからです。

指示内容を固定する

1回目の指示の例です。

あなたはハイヤー会社の本社で、法人の契約先から届いた意見・苦情の
記録を読み、翌月の指導と運行の見直しのために整理する立場です。
渡された記録と運行の情報だけをもとに答えてください。推測で補わ
ないでください。

【区分の一覧（版 {category_version}）】{categories}

【答えること】
1. complaint_summary ..... 苦情の内容の欄を1〜2文で
2. finding_summary ....... 原因究明の結果の欄を1〜2文で
3. category .............. 区分の一覧から1つ
4. cause ................. driver／dispatch／vehicle／customer_side／unclear
5. quotes ................ category と cause の根拠にした文をそのまま
6. measure_recorded ...... 改善措置の欄に記載があるか（true／false）

【厳守事項】
- cause は、原因究明の結果の欄と、渡した時刻の差の値だけをもとに
  決めてください。苦情の内容の欄だけで driver にしないでください。
- 原因究明の結果の欄が空なら、finding_summary を
  investigation_pending とし、cause を unclear にしてください。
- 時刻の差は渡した値をそのまま使ってください。計算し直さないで
  ください。
- quotes は記録の文をそのまま写してください。言い換えないで
  ください。
- 乗務員の人柄・態度・能力を評価する言葉を書かないでください。
  記録に書かれた行いだけを書いてください。
- 記号（乗務員の番号、担当A、乗客B など）を元の名前に戻そうと
  しないでください。
- おほめの言葉は category を praise にし、何がよかったかを
  記録の文のとおりに要約してください。

【運行の情報】{trip_info}（指定と実際の到着の時刻の差: {time_diff} 分）
【記録】
受付: {received} 手段: {channel} 営業所: {office}
苦情の内容: {complaint}
原因究明の結果: {finding}
弁明の内容: {response}
改善措置: {measure}

「苦情の内容の欄だけで driver にしない」を明記しないと、原因の所在は申出の言葉に引きずられます。 原因究明の結果の欄に反対のことが書かれていても、申出の言葉が強いと driver が付きます。欄を分けて渡し、どちらの欄から決めるかを指示で縛ります。

「人柄・態度・能力を評価する言葉を書かない」も外さないでください。 記録に「言葉遣いが冷たかった」と書かれていれば、何も言わなければ「接遇の意識が低い」と書いてきます。書かれているのは行いで、意識ではありません。

出力形式を固定する

1回目は次の形の JSON で受け取ります。

{
  "record_id": "",
  "office": "",
  "trip_id": "",
  "trip_link": "by_trip_id | by_time_match | unlinked",
  "driver_no": "",
  "client_id": "",
  "complaint_summary": "",
  "finding_summary": "",
  "category": "",
  "cause": "driver | dispatch | vehicle | customer_side | unclear",
  "quotes": [ { "field": "complaint | finding", "text": "" } ],
  "measure_recorded": true
}

2回目は、次の形で受け取ります。

{
  "month": "2026-10",
  "office_points": [
    { "office": "", "title": "", "basis_count_ref": "", "record_refs": [], "kind": "coaching | praise_share" }
  ],
  "cross_office_points": [
    { "title": "", "basis_count_ref": "", "record_refs": [], "area": "dispatch | vehicle | waiting | booking" }
  ]
}

1つ目の理由は、cause で論点の行き先を分けられることです。 driver の指摘は営業所の運行管理者へ、dispatch と vehicle は本社の業務の担当へ、customer_side は担当の営業へ回します。同じ「時刻」の区分でも、行き先が違います。

2つ目は、quotes の field で、引用がどの欄から来たかが分かることです。 報告に引用を載せるとき、申出の言葉なのか、営業所が調べた結果なのかを見分けて載せられます。

3つ目は、kind に praise_share を持たせて、おほめの言葉を指導の論点と並べられることです。 よかった乗務を他の乗務員と共有する材料になります。

スキーマの制約は Python で確かめます。 quotes の文が記録に含まれているかを文字列の一致で調べ、含まれていなければその引用を報告に使いません。 office_points が営業所ごとに3つ以内かも、受け取った後に調べます。

システムへ連携する

苦情の記録には書き戻しません。 法令で営業所ごとに付けて保存する記録なので、AIの要約が記録の欄に混ざらないようにします。 要約は別のファイルに持ち、記録の番号で結びます。

乗務員の指導の記録にも書き込みません。 指導を行ったら、運行管理者がこれまでどおり指導の記録を付けます。

人が確認する

人が確かめるのは、論点と、論点に使う引用です。

1. driver の論点を先に見る … 引用の記録を開き、原因究明の結果の欄が本当に乗務の行いを指しているかを確かめます
2. unclear と investigation_pending を営業所に返す … 原因の調べが終わっていない記録は、営業所の担当に書き足しを頼みます
3. unlinked の記録を片付ける … 運行にひも付かなかった記録は、担当が配車の記録で探します
4. 営業所をまたぐ論点を読む … 配車・車両・待機の論点は、本社の業務の担当と読み合わせます
5. 区分を直したら記録する … どの区分・原因の所在から、どれへ変えたかを残します

1番目を省かないでください。 運行管理者は報告をもとに乗務員と話します。原因の無い指摘で指導を受けた乗務員は、次から記録そのものを信じなくなります。

乗務員にも、報告の作り方を伝えておきます。 指摘の要約にAIを使っていること、評価や処遇には使わないこと、指導の内容は運行管理者が決めていることを、営業所の朝礼などで説明します。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、記録の付け方の問題です。 営業所に「運行の番号を書く」「原因の調べを書いてから閉じる」を頼むと、論点の確かさが上がります。

記録を残す

• 読み込んだ記録の版（営業所ごとのファイルと取得日時）
• 列の名前の対応表と、区分の一覧の版
• 1回目の JSON と2回目の JSON
• Python の集計表（営業所・乗務員・契約先・区分・原因の所在ごとの件数）
• 担当が区分・原因の所在を直した記録
• 営業所に書き足しを頼んだ記録と、書き足された結果
• 運行管理者が指導に使った論点と、その後の月の同じ区分の件数

苦情の記録そのものの保存は、これまでどおり営業所で行います。 この構成の保存は、要約と集計の側の記録です。法令で求められる記録と、この構成の記録を混ぜないようにします。

最後の行が、この構成の本当の成果物です。 指導や配車の見直しのあと、同じ区分・同じ契約先の指摘が減ったかを毎月並べると、直したことが効いたかが分かります。