作業者の力量管理表を教育記録から更新して、期限切れと配置の穴を出す

処理の起点を決める

起点は2つあります。 フォームの送信と、毎朝7時の時間主導型です。役割が違います。

フォーム送信は、記録が発生したその日のうちに下書きを作るためのものです。月90件はまとめても回る量ですが、まとめると「提出したのに表に無い」期間ができます。 その期間に配置を決めると、表に無い力量は無いものとして扱われます。

毎朝7時の時間主導型は、件数と関係なく動かすためのものです。期限の切れた力量も、1人しかできない作業も、提出が0件の日でも数えます。Before で誰の仕事にもなっていなかった④が、ここに入ります。 配置の穴の一覧は月初の朝に出します。なお、実行の時刻はぴったりになりません。

入力データを集める

質を決めるのは、上から2つ目です。 対応表が無ければ、読み取った「フォークリフト運転技能講習修了証」という文字列を、どの列に入れるかが決まりません。AIに選ばせると、似た名前の列に入ります。 入った1件は、できないはずの人ができる人として表に残ります。

対応表には、更新の周期と、手配に必要な日数を持たせます。 周期は有効期限の計算に、日数は「いつ一覧に出すか」に使います。年に2回しか開かれない更新研修は、期限の3か月前に出しても間に合いません。

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

シートは getDataRange().getValues() で受け取り、下書きの行は appendRow() で足します。対応表と社員名簿は、AIに渡す前にスクリプトの側で読みます。 AIへ渡すのは、力量コードの一覧と、氏名の近い上位5件だけです。

読み取りは UrlFetchApp.fetch で Gemini API を呼びます。 muteHttpExceptions を有効にすると、エラーの応答も本文として受け取れるので、何が返ったかを下書きに残せます。 画像をインラインで送る場合はリクエスト全体で20MBまでとされ、大きいものは Files API を使うとされています。

AIへ渡す前に整形する

1. 形式の確認 … 画像は PNG、JPEG、WEBP、HEIC、HEIF が対応するとされています。それ以外はPDFに変換します
2. 向きの確認 … 公式の推奨に「画像が正しく回転しているかを確かめる」とあります。現場から出たものは横倒しや逆さまが混じります
3. 鮮明さの確認 … 同じく「ぼやけていない鮮明な画像を使う」とあります。判定できない写りのものは撮り直します
4. 大きさの確認 … PDFは最大50MBまたは1,000ページ、画像のインライン送信は合計20MBまでです
5. 複数人分の分割 … 集合教育の受講者名簿は1枚に何十人分も載ります。人ごとの行に分けてから渡します
6. 社員の特定 … 社員番号があれば使い、無ければ氏名と所属で名簿を引きます。旧姓の列も見ます

2番目と3番目を軽く見ないでください。 修了証はその場で撮られるので、斜め・影・反射が入ります。写りが悪いだけのものを「書かれていない」と扱うと、受けたはずの教育が記録から消えます。 読み取れないものは人に回す分岐を、ここで作ります。

AIに処理させる

させるのは、証明書から4つを読み取り、力量コードを1つ選ぶことだけです。

いちばん下の行が、この構成の要です。 unmapped は失敗ではなく、対応表がまだその力量を持っていないという事実の記録です。寄せさせると、この事実が消えます。

1行目がいちばん起きやすい失敗です。 証明書に有効期限が印刷されていることもあり、何も言わなければ読み取って返します。印刷された期限と、周期から計算した期限が食い違ったとき、どちらを信じるかを決める場所がありません。

指示内容を固定する

あなたは製造現場の教育記録を整理する担当者です。
提出された証明書の画像またはPDFを見て、書かれていることだけを書き出して
ください。推測で埋めないでください。

【読み取る4つ】
1. 受けた人の氏名（書かれていれば社員番号も）
2. 受けた教育・取得した資格の名称（書かれているとおりの文字列）
3. 受けた日・交付された日
4. 交付した機関・事業者の名称

【力量コードの割り当て】
- 下の一覧から、2で読み取った名称に対応する code を1つ選んでください。
- どれにも当てはまらないときは match を unmapped にし、code を空にして
  ください。新しい code を作らないでください。
- 名前が似ているという理由で選ばないでください。迷ったら unmapped です。

【status の選び方】
- ok ......... 値が読み取れ、その項目として解釈できる
- missing .... 書かれていない
- unreadable . 文字はあるが、かすれ・手書き・写りで確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 有効期限を書かないでください。印刷されていても読み取らないでください。
  期限は対応表の規則で計算します。
- その人がその作業をしてよいかを書かないでください。
- 日付は読み取った文字列を value に写し、西暦を date に入れてください。
  読み取れない桁を推測で埋めないでください。
- 氏名は書かれた文字をそのまま写し、旧字体を新字体に直さないでください。
- evidence には、判定の根拠にした文字列をそのまま写してください。
- 証明書でない書類は、document_type に種類を書いてください。

【力量コードの一覧】{skill_codes}
【社員名簿の候補（氏名の近い上位5件）】{person_candidates}

「名前が似ているという理由で選ばない」を明記しないと、必ず寄せます。 「有機溶剤業務従事者」と「特定化学物質作業主任者」は文字の並びが近く、何も言わなければどちらかに入ります。 入った1件は「できる人」として数えられ、配置の穴の一覧から消えます。「有効期限を書かない」を2か所に書いているのも同じ理由で、外すだけでは evidence の欄に書いて返してきます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "document_type": "training_record | certificate | license_copy | other",
  "person": { "name_on_document": "", "employee_no": "",
              "match": "matched | not_found | ambiguous" },
  "skill":  { "name_on_document": "", "code": "",
              "match": "matched | unmapped" },
  "acquired": { "value": "", "date": "" },
  "issuer": "",
  "fields": [
    { "item": "person_name", "status": "ok | missing | unreadable | ambiguous",
      "evidence": "" }
  ]
}

fields にはこの形の要素を4つ並べます。item は person_name ／ skill_name ／ acquired_date ／ issuer です。

Gemini API の構造化出力で、この形を指定します。 公式の説明では JSON Schema の一部に対応し、properties ／ required ／ enum ／ format などが使えるとされています。match と status は enum で固定します。 自由記述にすると、unmapped のつもりで「該当なし」と返ってくるためです。ただし公式には「非常に大きい、または入れ子の深いスキーマは拒否されることがある」ともあり、1枚につき、この程度の浅い形で1回呼ぶのが安全です。

期限の列がこのJSONに無いのは、意図してのことです。 有効期限は acquired.date に周期を足してスクリプトが計算します。下書きに入れてよいかの判定も、AIには返させません。

この表を規則の側に置けば、基準が変わっても直すのは規則だけです。 AIが返すのは事実の記録までです。

システムへ連携する

力量管理表の本体のセルには書き込みません。 書くのは「下書き」のシートまでです。確定を人に残しておけば、間違えた1件が、その日の配置の判断に使われません。

人事システムへも書き込みません。 異動・退職の予定は読むだけで、出すのは「その作業ができる人がいなくなる」という一覧だけです。

人が確認する

人が開くのは、unmapped と、人へ回されたものだけです。 すべて読み取れて力量コードにも当たったものは、一覧を流し見て一括で確定します。全件を原本と見比べると、第10章の6.0時間に収まりません。

1. unmapped を先に見る … 対応表にその力量がまだ無いということです。直すのは対応表であって、力量管理表ではありません
2. 読み取れなかったものを見る … unreadable の多くは写りの問題です。原本が手元にあれば見て入れ、無ければ撮り直しを依頼します
3. 同姓同名・旧姓を確かめる … ambiguous と not_found はここです。社員番号を書いてもらう運用に変えるのが、いちばん早い対策です

期限切れの一覧は、確定とは別に人が見ます。 一覧が出ることと、その人を作業から外すことは別です。誰がその判断をするのかを、運用を始める前に決めてください。

目標は、90件をならして1件4分です。 開くのは2割前後という想定で、多い月は、写りの問題か対応表の不足です。

例外に対処する

上から3行が件数の大半を占めます。 どれもAIの問題ではなく、提出のしかたの問題です。 フォームの案内文を直すほうが早く効きます。

記録を残す

• 提出された証明書のファイルと、提出日時・提出者
• Gemini API が返したJSONの全文（status と evidence を含む）
• 計算した有効期限と、そのとき参照した対応表の版
• 確定した人と日時、確定の前後で値が変わった項目
• unmapped になった名称の一覧と、力量ごとの unreadable の発生率
• 期限切れが一覧に出てから、対応されるまでの日数

3つ目で「そのときの対応表の版」を残すのは、更新の周期が後から変わるためです。 周期を直すと過去の期限の意味が変わり、当時の版が無いと、どこまで計算し直せばよいかが決まりません。 そしていちばん下の行が、この構成が効いているかの物差しです。 期限切れが出るようになっても、対応までの日数が縮まなければ、出すだけで終わっています。