社用車の運転前後のアルコールチェックの記録を毎日点検し、記録漏れ・確認者の欠け・確認方法の書き漏れを安全運転管理者に知らせる

処理の起点を決める

点検は、毎朝7時台に動く時間主導型のトリガーを起点にします。 ScriptApp.newTrigger() に timeBased()・everyDays(1)・atHour(7) を続けて作ります。動くと、前の日の0時から24時までの使用簿と記録を拠点ごとに読みます。

前の日の分を翌朝に見るのは、運転後の確認が夜になるためです。 帰着の遅い運転者の運転後の確認は、夜の9時、10時に記録されます。夕方に点検すると、まだ帰っていない運転者がすべて「運転後の記録なし」になります。 翌朝なら、前の日の運転はすべて終わっています。

1日に何度も運転する運転者でも、記録が運転の回数だけ要るとは限りません。 警察庁の Q&A では、確認は個々の運転の直前・直後にその都度行わなければならないものではなく、運転を含む業務の開始前や出勤時、終了後や退勤時に行うことで足りるとされています。そこで照合は、使用簿の運転者×日ごとに、運転前と運転後の記録が1件ずつあるかで見ます。

夜勤のある拠点は、日をまたぐ運転があります。 使用簿の使用の開始が前の日で、終わりが当日の朝になっている運転は、終わりの日の点検に回します。 使用簿に開始と終わりの日時を持たせ、スクリプトで判定します。

測定値と有無の知らせは、フォーム送信のトリガーで行います。 回答1件ごとに動き、測定値が0より大きいか、有無が「有」なら、その場でメールを送ります。 AI を呼ばないので、数秒で届きます。

入力データを集める

質を決めるのは、使用簿です。 記録漏れは「運転したのに記録が無い」ことなので、運転したことが分かる使用簿が無ければ、漏れを数えられません。 使用簿の書き漏れがあると、その運転は点検から消えます。第12章でも扱います。

確認者の一覧に補助者を入れるのは、警察庁の Q&A の考え方に沿うためです。 Q&A では、酒気帯び確認は安全運転管理者が行うのが原則で、不在のときなどには、副安全運転管理者や、あらかじめ補助者として指定し、確認の方法について指導・教育を行った者に行わせることは差し支えないとされています。一覧に無い人が確認者の欄にいれば、指定の漏れか、書き間違いかのどちらかです。

検知器の台帳は、Q&A の「常時有効に保持」のために持ちます。 Q&A では、検知器は取扱説明書に基づいて使い、管理し、保守するとともに、定期的に故障の有無を確認し、故障がないものを使用しなければならないとされています。最後に確かめた日が社内の決めた間隔を過ぎた検知器での記録を拾います。

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

運転者の名前は、運転者の一覧で社員の番号にそろえてから照らします。 使用簿には姓だけ、フォームにはフルネーム、という違いがよくあります。番号にそろえられない名前は「運転者を特定できない」として拾います。

拠点ごとの処理は、次の順で行います。

1. 前の日の使用簿の運転者×車両の組と、記録の行を取り出す
2. 運転者の名前を社員の番号にそろえる
3. 使用簿の運転者ごとに、その日の運転前・運転後の記録があるかを見る（R1・R2）
4. 記録の行ごとに規則で見る
   R3 確認者が空、または確認者の一覧にいない、または運転者と同じ
   R4 確認の方法が対面以外で、方法の詳細が空
   R5 測定値が0より大きいのに有無が「無」、または測定値が空
   R6 検知器の番号が台帳に無い、または故障の有無の確認の期限を過ぎている
   R7 運転後の記録の時刻が、運転前の記録の時刻より前
5. 方法の詳細・指示事項・備考のどれかに文がある行を、AI に渡す一覧にする
6. Claude API を呼び、JSON を受け取る（失敗したら規則の結果だけで送る）
7. 規則の結果と AI の判定を合わせて、拠点ごとの不備の一覧を作る
8. 点検の一覧のシートに書き、安全運転管理者にメールで送る

6番目で AI が失敗しても、メールは送ります。 記録漏れ（R1・R2）は規則だけで決まり、最も大事な知らせです。 AI の判定は後から足せますが、記録漏れの知らせが止まるのは避けます。

Claude API は UrlFetchApp で呼び、API キーはスクリプトのプロパティに置きます。 公式の割り当てでは、URL Fetch の呼び出しはGoogle Workspace のアカウントで1日10万回、MailApp の宛先は1日1,500で、1日に6拠点分を送るには十分です。

AIへ渡す前に整形する

1. 運転者の名前を番号に置き換える … AI には社員の番号も名前も渡さず、行の番号だけを渡します
2. 規則で決まったものは渡さない … R1〜R7 は AI の判定を待たずに不備として決まります
3. 自由記述の無い行は渡さない … 方法の詳細・指示事項・備考がすべて空の行は、AI を呼びません
4. 欄の値を添える … 確認の方法の選択肢、測定値、有無の値を、自由記述と一緒に渡します
5. 体調や服薬の記述をそのまま扱う … 備考の文は省かずに渡します。この欄の読み取りが AI の役割の中心だからです

1番目で名前を渡さないのは、記録の性質のためです。 酒気帯び確認の記録には、体調や服薬、前の晩の飲酒のような、本人にとって知られたくない内容が書かれることがあります。誰の記録かは、行の番号でスクリプトの側だけが分かる形にします。

AIに処理させる

させるのは、記録の自由記述について、記録として足りているか、欄どうしが食い違っていないかを判定することです。

方法の詳細の判定の基準は、警察庁の Q&A の例に置きます。 Q&A では、対面と同視できる方法の例として、カメラ・モニターで顔色や声の調子とともに測定結果を確認する方法と、電話や業務無線で声の調子を確認するとともに測定結果を報告させる方法が挙げられています。「何で（手段）」「何を（顔色・声の調子）」「測定結果をどう確かめたか」の3つが書かれているかを見させます。

備考の判定では、AI に体調の良し悪しを判断させません。 見るのは、備考に運転への影響がありうる記述があるときに、指示事項に何か書かれているかだけです。指示の中身が適切かどうかは、安全運転管理者が決めます。

1行目と2行目が、この構成でいちばん守るべきことです。 AI に記録を読ませると、「測定値が低いので問題ない」のような判断を書き添えがちです。それが不備の一覧に載ると、安全運転管理者の判断の代わりのように読まれてしまいます。スキーマに判断を書く欄を作らないことで、書く場所を無くします。

指示内容を固定する

あなたは会社の総務部で、社用車の酒気帯び確認の「記録」がそろっているかを点検する立場です。
酒気帯びかどうか、運転してよいかは判断しません。記録の書き方だけを見てください。

【見ること】
1. method_detail：確認の方法が対面以外のとき、具体的な方法が書かれているか
   - 足りる（adequate）：手段、運転者の何を確かめたか（顔色・声の調子など）、
     検知器の測定結果をどう確かめたか（画面で見た・報告を受けた）の3つが読み取れる
   - 足りない（insufficient）：3つのうち1つでも読み取れない
   - 判断できない（unclear）：文が途中で切れている、意味が取れない
2. note_vs_instruction：備考に、体調不良・服薬・睡眠不足・前日の飲酒など
   運転に影響しうる記述があるとき、指示事項に何か書かれているか
3. instruction_vs_result：指示事項の内容と、酒気帯びの有無の欄が食い違っていないか

【厳守事項】
- 酒気帯びかどうか、運転してよいか、体調が悪いかを判断しないでください。
- 測定値の大小について評価しないでください。
- 指示事項の中身が適切かどうかを書かないでください。書かれているかだけを見てください。
- 書かれていないことを補わないでください。「たぶん対面だった」と推し量らないでください。
- evidence には、判定の根拠にした文をそのまま写してください。

【記録の行】{records_json}
（各行：row_id、check_type、method、method_detail、measured_value、
  alcohol_detected、instruction、note）

冒頭で「判断しません」を言い切るのは、この題材の性質のためです。 酒気帯び確認の記録を渡すと、AI は安全のために何か言おうとして、「念のため運転を控えるべき」のような助言を足します。 点検の一覧に載る文は、記録の不備の指摘だけにします。

3つの要素を並べて書くのは、判定をそろえるためです。 「足りる」の基準を「具体的に書かれていれば」とだけ書くと、「携帯で確認」を足りると判定する回と足りないと判定する回が出ます。 要素の数で判定させると、安全運転管理者が読んでも理由が分かります。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "results": [
    { "row_id": "",
      "method_detail": "adequate | insufficient | unclear | not_applicable",
      "method_missing": ["means | observed | result_check"],
      "note_vs_instruction": "consistent | missing_instruction | unclear | not_applicable",
      "instruction_vs_result": "consistent | contradiction | not_applicable",
      "evidence": "" }
  ]
}

スキーマでは判定の欄をすべて enum で縛り、オブジェクトに additionalProperties: false を付けます。自由に書ける欄は evidence だけにして、判断や助言を書く欄を作りません。 公式のページでは、minimum などの数値の制約は使えないとされていますが、この形では数値の欄が無いので当たりません。

method_missing で、足りない要素を返させます。 不備の一覧には「方法の詳細に、測定結果をどう確かめたかが書かれていません」のように、何を補えばよいかが一文で出ます。 確認者が記録を補うときに迷いません。

row_id は、渡した行と1対1で突き合わせます。 抜けた行は「AI の判定なし」として、規則の結果だけで一覧に載せます。

拠点ごとのメールは、次の順に並べます。

システムへ連携する

回答のシートには書き込みません。 記録を補うときは、確認者がフォームで「訂正・追記」の区分の回答を新しく送り、元の行を指す番号を書きます。元の記録を書き換えないのは、1年間保存する記録だからです。 いつ、誰が、何を補ったかが残ります。

人が確認する

1. 安全運転管理者が、メールの1番と2番を最初に見る … 記録漏れは、運転者と確認者に当日中に連絡します。数値や指示事項の食い違いは、確認したときの状況を確認者に聞きます
2. 3番から5番は、確認者に補ってもらう … 訂正・追記の区分で、足りない要素を書いてもらいます
3. 6番は、検知器の台帳を直すか、検知器を確かめる
4. 点検の一覧の対応の欄に、何をしたかを書く
5. 本社の担当が、週に1回、拠点ごとの不備の件数を見る

1番目の記録漏れは、記録の問題で終わらないことがあります。 運転後の記録が無いのは、確認を忘れただけかもしれませんし、確認をしないまま帰宅したのかもしれません。 どちらだったかは、安全運転管理者が運転者に聞いて確かめます。

例外に対処する

3行目は、警察庁の Q&A の考え方を反映しています。 Q&A では、出張先の事業所の安全運転管理者が確認することも可能で、その結果を運転者が所属する事業所の安全運転管理者に報告するよう示されています。

記録を残す

• 毎朝の点検の日時、拠点ごとの使用簿の件数と記録の件数
• 規則の判定の結果（R1〜R7）と、AI に渡した行と返ってきた JSON
• 拠点ごとに送ったメールの日時と宛先
• 点検の一覧の対応の欄 … 誰が、いつ、何をしたか
• 訂正・追記の回答と、元の行の対応

記録そのものは、回答のスプレッドシートに1年間以上残します。 点検の一覧も同じ期間残し、閲覧できる人を総務部と各拠点の安全運転管理者に限ります。