情報システム部が社員から毎月集める貸与端末の自己点検フォームを Apps Script で集め、AI で資産台帳との食い違いと更新の遅れを拾う

処理の起点を決める

トリガーは3本です。 毎月1日の案内（トリガー①）、回答の送信のたびの突き合わせ（トリガー②）、毎月11日の未回答と更新の遅れの一覧（トリガー③）です。

トリガー②は、スプレッドシートの側のフォーム送信のトリガーです。 公式のページでは、そのイベントには質問の名前と値の組（namedValues）と、書き込まれた範囲（range）が入ります。資産番号は namedValues から取り、結果は範囲の行の位置を使って回答の行の横にも印を付けます。

回答のたびに動かすのは、急ぐずれがあるからです。 「手元に無い」「どこに置いたか分からない」という回答は、月の締め切りを待たずに、その日のうちに担当者が本人に連絡すべきものです。 10日にまとめて見ると、紛失の疑いに気づくのが最大で9日遅れます。

トリガー③は、「更新の遅れ」を拾うためのものです。 締め切りの翌日に、回答の無い社員と、台帳の最後の確認日が3か月以上前の端末、OS の版が基準より古いまま先月から変わっていない端末を一覧にします。回答のたびの突き合わせでは、答えなかった人のずれは見えません。 月に一度、答えの無いところを数える段を別に置きます。

入力データを集める

シリアル番号は、社員に本体のラベルから書き写してもらいます。 資産番号のシールは貼り替えられることがありますが、本体のシリアル番号は変わりません。 資産番号とシリアル番号の組が台帳と合わなければ、シールの貼り違いか、端末そのものが入れ替わっています。

OS の版は、選択肢にせず、設定の画面の表示を書き写してもらいます。 選択肢にすると、分からない社員が一番上を選びます。書き写した文字列を、スクリプトが版の番号として読み、基準の表と比べます。 読めない書き方のものだけを、AI に回します。

入れないもの： 端末の中のファイルや閲覧の記録。自己点検は所在と状態を確かめるもので、使い方を調べるものではありません。

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

案内のメールは、1人に1通にまとめます。 3台を持つ社員には、3つの URL を1通に並べて送ります。 公式のページでは、Google Workspace のアカウントで1日に送れるメールの宛先は1,500までです。750名なら1日で送り終えますが、台数ごとに送ると宛先の数が台数分に増え、上限に近づきます。

台帳の行は、資産番号で1行に決まる形にしておきます。 同じ資産番号が2行あると、どちらと比べるかが決まりません。突き合わせの前に、台帳の資産番号の重複をスクリプトで数え、あれば担当者に知らせて止めます。

AIへ渡す前に整形する

1. 回答者の確かめ … フォームが集めたメールアドレスが社員の名簿にあるかを見ます
2. 資産番号の確かめ … 台帳にその資産番号が無ければ、「台帳に無い」の差分にします
3. 値で比べる … 使用者（回答者と台帳の使用者）、シリアル番号、使う場所、OS の版を比べ、項目ごとに 一致／不一致／読めない を付けます
4. OS の版を番号として読む … 書き写した文字列から版の番号を取り出し、基準の表と比べます。取り出せなければ 読めない にします
5. 一致で終える … 4項目がすべて 一致、手元に「はい」、備考が空なら、台帳の最後の確認日を更新して終わります
6. 在籍の状態を添える … 社員の名簿で退職の予定・休職の印があれば、AI に渡す情報に加えます

3番目と4番目を、AI に渡す前にスクリプトで済ませます。 シリアル番号が1文字違うかどうかは、値を比べれば決まり、読む力は要りません。 AI に台帳の行と回答の両方を渡して「違いを探して」と頼むと、ときどき違いを見落とし、ときどき無い違いを作ります。

6番目の在籍の状態は、leaving の区分を正しく選ばせるために渡します。 退職の予定の社員が「手元にある」と答えた端末は、台帳の上ではずれていませんが、返却の段取りが要ります。 名簿の印が無いと、AI はこの回答を「一致」と同じに扱います。

5番目で、AI を呼ぶ回答は1割ほどに減ります。 呼ばない回答は、確認の一覧にも載りません。担当者の一覧が、確かめるべきものだけになります。

AIに処理させる

区分は次の8つです。

high にするのは possible_loss だけです。 急ぎ度を AI の読みに広く任せると、「至急」と書いた社員の回答が上に来ます。区分ごとに急ぎ度を固定し、AI には区分を選ばせるだけにします。

指示内容を固定する

あなたは情報システム部で、貸与端末の自己点検の回答を確かめる係です。
スクリプトが比べた差分と、社員が書いた備考だけを使ってください。
差分を比べ直さないでください。

【discrepancy_type】
次の8つから1つ選んでください。迷ったら other にしてください。
possible_loss / handed_over / repair / swapped_label /
location_change / os_outdated / leaving / other
「手元にあるか」が「いいえ」で、場所が分からない、置き忘れた、
と読める場合は possible_loss にしてください。

【ledger_update】
台帳のどの項目を直すべきかと、新しい値を返してください。
- 新しい値は、備考に書かれている場合だけ入れてください。
  書かれていなければ空にしてください。推測で埋めないでください。
- 新しい使用者の名前は、備考に書かれた名前をそのまま写してください。
  所属や前後の文から推し量らないでください。

【evidence】
判定の根拠にした備考の文を、そのまま写してください。要約しないでください。

【question】
案を確かめるために本人に尋ねる文を、1〜2文で書いてください。
責める言い方をしないでください。possible_loss の場合は、
「最後に使った日と場所を教えてください」を必ず含めてください。

【os_reading】
OS の版の欄の文字列から版の番号を読めたら、その番号を返してください。
読めなければ unreadable にしてください。

【回答】{answer}
【スクリプトの差分】{diff}
【在籍の状態】{employment}

「新しい使用者を推し量らない」は、この構成でいちばん大事な一文です。 「〇〇課の新しい人に渡した」と書かれた回答で、AI が名簿から〇〇課の新しい人を探して名前を入れると、台帳の使用者がもっともらしい誤りで書き換わります。 名前が無ければ空にし、本人に尋ねます。

possible_loss の質問の文を固定するのは、後で要る事実だからです。 紛失の疑いがあれば、情報システム部は端末の利用を止めるかを決め、総務は届出が要るかを考えます。 最後に使った日と場所は、そのどちらにも要ります。

出力形式を固定する

次のスキーマの JSON で受け取ります。 オブジェクトごとに additionalProperties: false にします。

{
  "asset_no": "NB-2023-0418",
  "discrepancy_type": "handed_over",
  "urgency": "normal",
  "ledger_update": [
    { "field": "使用者", "current": "（台帳の使用者）", "proposed": "" }
  ],
  "evidence": "9月の配置換えで、同じ課の後任の方に引き継ぎました",
  "question": "引き継いだ方のお名前を教えてください。あわせて、引き継いだ日も分かれば教えてください。",
  "os_reading": "14.6"
}

1つ目の理由は、ledger_update の proposed が空のまま返ることです。 新しい使用者の名前が備考に無いので、空のまま返り、担当者は本人に尋ねるべきだと一目で分かります。 名前を埋めた形で返させると、確かめずに承認されるおそれがあります。

2つ目は、discrepancy_type で確認の一覧を並べ替えられることです。 possible_loss を一番上に、os_outdated をまとめて下に並べれば、担当者は急ぐものから順に見られます。

3つ目は、os_reading で書き方のばらつきを吸収できることです。 スクリプトで読めなかった文字列だけを AI に読ませ、読めた番号を基準の表と比べ直します。

システムへ連携する

台帳への書き込みは、最後の確認日だけです。 使用者・場所・シリアル番号は、担当者が確認の一覧で承認した後に、担当者の操作で書き換えます。 確認の一覧に「承認」の列を置き、承認された行だけを台帳に反映するボタンを置く作りにもできます。

本人への確認は、担当者が送ります。 question の文を Gmail の下書きにする作りにしても、送るかどうかは担当者が決めます。 紛失の疑いの連絡は、文面よりも先に電話をかけることもあります。

人が確認する

1. possible_loss を最初に見る … 本人に電話かメールで連絡し、最後に使った日と場所を確かめます。見つからなければ、端末の利用の停止と、総務への届出の要否を決めます
2. 台帳の更新の案を確かめる … evidence を読み、案の項目と新しい値が備考と合っているかを見ます
3. 空の値は本人に尋ねる … proposed が空のものは、確認の文を送り、返事を待って台帳を直します
4. 承認して台帳を直す … 承認した案だけを台帳に反映し、更新の履歴の列に日付を書きます
5. 案を退けたら記録する … 退けた理由を確認の一覧に書きます

1番目を、確認の一覧の順番任せにしないでください。 possible_loss が出たら、一覧を開くのを待たずに担当者へ知らせるようにします。スクリプトから担当者あてのメールを1通送るだけで足ります。

目標は、900件をならして1件1分です。 9割の回答は人が開かないので、残る1割に、ならして1件1分の時間を使えます。 1割の回答に1件あたり数分から10分ほどかけられる計算です。

例外に対処する

3行目は、端末の入れ替わりの典型です。 2人が同じ資産番号に答えたなら、どちらかの手元の端末のシールが違っています。 先に答えた側で台帳を直すと、後から答えた側の端末が台帳から消えます。

記録を残す

• 回答の全文と、送信の日時、回答者のメールアドレス
• スクリプトの差分の結果（項目ごとの 一致／不一致／読めない）
• AI の結果の JSON の全文と、使った OS の基準の表の版
• 担当者の承認と退けた記録、台帳を直した日と直した人
• 本人への確認の送信と返事の日付
• 毎月の未回答と OS の更新の遅れの一覧

4つ目の「台帳を直した人」は、監査の前に要ります。 台帳の値が、いつ誰の判断で変わったかが分かれば、監査の前にまとめて直す作業が要らなくなります。

最後の行は、月ごとに残します。 同じ社員が何か月も続けて答えていない、同じ機種の OS の更新が毎月遅れている、といった傾向は、1か月分の一覧では見えません。 機種の入れ替えや、更新の手順の案内を見直す材料になります。