貸し出した端末と周辺機器の所在と保証期限を追って、返却漏れを拾う

処理の起点を決める

起点は2つです。フォームの送信と、毎朝1回の時間主導型です。

フォームの送信は、申請と返却の連絡が入った瞬間に動かします。その場で台帳に下書きの行ができることが大事です。 後でまとめて処理する形にすると、口頭で渡した端末が「後で書く」のまま消えます。

毎朝の時間主導型は、期限を見るためのものです。返却予定日を過ぎたもの、最終出社日が近い人の貸出、保証・リース・OSのサポートの期限が近い端末を数えます。毎分から月1回まで選べますが、1日1回で足ります。 期限は日単位でしか動かないので、それ以上細かく見ても一覧の内容は変わりません。

時間主導型のトリガーは、負荷分散のために実行の時刻がばらつくことがあるとされています。 「8時の朝会で一覧を見る」という運用にすると、届いていない日が出ます。一覧はスプレッドシートの1枚に常に置き、通知は補助にしてください。 また、誰のアカウントでトリガーを作ったかを台帳の先頭に書いておきます。

入力データを集める

質を決めるのは、上から2つ目です。 端末マスタに管理番号が無いと、読み取れるのは「ノートPCを1台」までで、どの個体が誰のところにあるかが分かりません。 所在を追う構成なので、ここが無いと成り立ちません。

人事の予定に必要なのは最終出社日だけです。 退職の理由も次の所属も要りません。持たせる情報を最小にしておくと、第13章の扱いが楽になります。

呼び名のゆれをマスタに持つのは、文面が自由に書かれるからです。 「ノートPC」「ノート」「PC」「レンタルPC」は同じものを指します。この一覧をAIへ渡し、そのどれかに寄せさせます。

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

フォームの回答は、回答シートに1行として入ります。フォームそのものを扱うときは FormApp の openById(id) openByUrl(url) で開き、フォームに紐づいたスクリプトなら getActiveForm() を使います。 ふだん読むのは回答シートのほうです。

スプレッドシートは、2次元の配列として扱うのが基本です。 公式のガイドでも、getDataRange().getValues() でシート全体を配列として取り、行を回して処理する書き方が示され、行の追加には appendRow() が使えるとされています。

1行ずつ読み書きしないでください。 公式のガイドは、大きなデータではサービスの呼び出しを最小にすることを勧めています。台帳が900行あるときに1行ずつ getRange を呼ぶと、毎朝の一覧づくりだけで実行時間を使い切ります。 まとめて読み、配列の上で照合し、まとめて書きます。

人事のCSVは、APIでつながっている前提にしません。月1回、受け取ったCSVをシートに貼るところから始めます。

AIへ渡す前に整形する

1. 差出人の特定 … メールアドレスから社員番号を引きます。引けないものは needs_input にします
2. 署名と引用の除去 … 署名、過去のやり取りの引用、定型の免責文を落とします
3. 呼び名の寄せ … 端末マスタの呼び名の一覧をAIへ渡す材料として組み立てます
4. 二重の申請の検知 … 同じ人・同じ品目・同じ日の申請が直近にあれば印を付けます
5. 返却予定日が空のものに印を付ける … 空のまま次へ渡します
6. 口頭のメモの整形 … 担当者が1行のテキストにしてから入れます

5番目を省かないでください。 返却予定日が空のとき、その場で埋めたくなります。 30日後、次の月末、プロジェクトの終わり。どれも本人と約束した日ではありません。空のまま台帳に入れ、確定のときに担当者が本人に聞きます。 埋めてしまうと、督促の根拠が社内の勝手な想定になります。

4番目は、廊下で頼まれた後にチャットでも送ってくる人がいるためです。 同じ申請が2行になると、返ってきていない端末が1台増えたように見えます。

AIに処理させる

させるのは、文面から6つの項目を読み取り、根拠にした文字列を書き出すことだけです。

あわせて、連絡の種類を判定させます。 貸出の申請／返却の連絡／期限を延ばす相談／食い違いが読み取れるものの4つです。最後の1つは、判定ではなく印を付けるだけです。

1行目がこの構成でいちばん大事な線引きです。 「返しました」「返っていません」の食い違いは必ず起きます。どちらの記憶も本人には事実で、台帳にも一方しか書かれていません。 材料が足りないところで判定させれば、それらしい結論が出ます。棚を見に行くほうが確実です。

指示内容を固定する

あなたは情報システム部門で、端末の貸出と返却の連絡を台帳に写す担当者です。
渡された文面に書かれていることだけを読み取ってください。書かれていないことを補わないでください。

【読み取る項目】
誰が（氏名と部署。無ければ差出人の情報を使う）／何を（品目の呼び名と台数）／
いつから（貸出を希望する日）／いつまで（返却の予定日）／
付属品（電源アダプタ、ケースなど）／用途（持ち出し先や目的）

【この連絡の種類】loan_request（貸出の申請）／ return_notice（返却の連絡）／
extension_request（期限を延ばす相談）／ dispute（返した・返していないの食い違い）／ other

【status の選び方】ok（文面にはっきり書かれている）／ missing（書かれていない）／
ambiguous（候補が複数あり、1つに決められない）

【厳守事項】
- 返却の予定日が書かれていないときは missing にしてください。
  「1か月後」「プロジェクトが終わるまで」のような言い方を、日付に直さないでください。
- 品目は、渡した呼び名の一覧のどれかに合わせてください。一覧に無い呼び名は、読み取った
  文字列を device_raw に入れ、device_name は missing にしてください。寄せないでください。
- 台数が書かれていなければ、1台としないでください。missing にしてください。
- 管理番号を決めないでください。どの個体を渡すかは人が棚を見て決めます。
- 「返した」「返っていない」のどちらが正しいかを判断しないでください。食い違いが
  読み取れる場合は kind を dispute にし、両方の言い分を evidence に写してください。
- evidence には、判断の根拠にした文面をそのまま写してください。
- 督促や返却の案内の文面は、ここでは作らないでください。

【品目の呼び名の一覧】{device_names}
【差出人の情報】{sender}
【文面】{message_text}

「日付に直さない」を明記しないと直します。 「1か月後に返します」は自然な日本語で、読めば日付が出てきます。禁じるのは計算ではなく、本人と約束していない日を台帳に載せることです。

「寄せない」も同じ型の指示です。 「検証機」と「検証用ノート」は別の棚にあるかもしれず、寄せた結果が正しいかはマスタを作った人にしか分かりません。

督促文の下書きは、別の呼び出しで作ります。 1回にまとめると、読み取りの結果に文面の都合が混ざります。

出力形式を固定する

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

{
  "kind": "loan_request",
  "requester": { "name": "", "dept": "", "employee_no": "", "status": "ok" },
  "items": [
    { "device_name": "", "device_raw": "", "qty": 0, "status": "ok", "evidence": "" }
  ],
  "start_date": { "value": "2026-10-01", "status": "ok" },
  "due_date": { "value": "", "status": "missing" },
  "accessories": [""],
  "purpose": "",
  "evidence": ""
}

kind と各 status は決まった語だけを取ります。Claude API の構造化出力では、output_config.format に json_schema の型でスキーマを渡すと、応答がそのスキーマに沿った形で返り、結果はテキストのコンテンツブロックに入るとされています。

スキーマの書き方には決まりがあります。 オブジェクトでは additionalProperties を false にする必要があり、required と enum が使えます。enum に入るのは文字列・数値・真偽値・null だけで、日付には date という文字列の形式が使えます。一方、数値の制約（minimum maximum）、文字列の長さの制約、パターン、再帰的なスキーマは使えません。 つまり台数が負でないことはスキーマで縛れないので、数の妥当性はスクリプトの側で見ます。

最初の1回だけ遅くなります。 スキーマから文法を組み立てる待ち時間が最初の要求で発生し、組み上がったものは最後に使ってから24時間キャッシュされるとされています。

台帳の「状態」はこのJSONに入れません。 貸出中・返却済み・期限超過・確認中のどれになるかは、返却予定日と今日の日付を比べてスクリプトが決めます。 読み取った事実とそこから導く状態を別の層に置けば、期限の数え方を変えたいときに直すのは規則だけで済みます。

システムへ連携する

下書きの作成には createDraft を使います。 公式の一覧には createDraft(recipient, subject, body) とオプション付きの形があり、どちらも GmailDraft を返します。オプションでは cc bcc htmlBody name replyTo attachments などが指定できます。https://mail.google.com/ の認可スコープが必要です。

同じクラスにある sendEmail は使いません。 督促は相手と時期を見て送るもので、自動で飛ぶ設計にすると、返した人にも届きます。業務システムへも書き込みません。 人事システムも資産管理の製品も、この構成からは読むだけです。

人が確認する

人が手を動かすのは3か所だけです。

1. 台帳の下書きの確定 … 現物を渡すときに、管理番号と付属品を確かめて行を確定します。missing の項目は、その場で本人に聞きます
2. 督促・返却案内の下書きの送信 … 相手と時期を見て、文面を直して送ります。送信は必ず人が行います
3. 食い違いの決着 … dispute の印が付いたものは、棚と現物を見に行きます。記録の突合では決めません

あわせて、退職予定の一覧を送る前に人事へ一声かけます。 最終出社日は変わります。予定が動いているのに返却の案内が飛ぶと、本人にも人事にも角が立ちます。

目標は、120件をならして1件3分です。 大半は下書きを見て確定するだけで終わり、missing が残っているものと dispute の印が付いたものにだけ時間を使います。全件を読み直す運用にすると、第10章の6.0時間には収まりません。

例外に対処する

上から2行目が、この構成でいちばん多い例外です。 運用を始めて半年ほどは、開始前に貸し出した端末の分で必ず食い違います。 起点をそろえる棚卸しを先にやるほど件数は減ります。5行目は、例外というより本来の効果です。 新規購入を止める仕組みではないので、一覧に並べるところまでにします。

記録を残す

• 元の申請・返却の文面と、入ってきた経路（フォーム／メール／チャット／口頭）
• AIが読み取ったJSONの全文と、そのとき渡した呼び名の一覧
• 人が下書きを直した記録 … どの項目を、何から何に変えたか
• 督促・返却案内の下書きを作った日時と、実際に送った日時
• 返却を確認した人と、確認した日
• dispute になった件の経緯と、現物を見た結果

3つ目が、この構成を良くしていく材料です。 どの項目がよく直されているかを月に一度数えると、読み取りの指示を直すべき場所と、フォームに項目を足すべき場所が分かれて見えてきます。

5つ目を残すのは、食い違いを減らすためです。 誰が棚に戻したかが残っていれば、次に「返したはずだ」と言われたときに見る場所があります。

この記録は、所在を追うためのものです。 誰が何回遅れたかを数えられる形になりますが、その使い方をしないことを先に決めます。 理由は第13章に書きます。