昇降機の保守会社が点検の記録と部品の交換履歴を Claude に渡し、次の点検で見る箇所と部品の更新の提案書の下書きを作る

処理の起点を決める

毎月1日の定時実行を起点にします。 対象は、その月に契約の更新月を迎える建物と、臨時の提案の依頼の表に入っている建物です。臨時の依頼は、営業や技術の責任者が「故障が続いている」「定期検査で指摘があった」「管理会社から相談があった」と思った時点で表に1行足します。

点検の記録が入るたびに動かす形にはしません。 提案書は年に1回の契約の節目と、臨時の相談に合わせて出すもので、点検のたびに下書きが届いても営業は使えません。下書きが積み上がって誰も読まない状態のほうが危険です。

月の途中で急ぎの依頼が入ったときは、建物の番号を指定して同じ処理を手で動かせるようにしておきます。定時の処理と手で動かす処理は、同じスクリプトの入口を2つにするだけで、中身を分けません。分けると、片方だけ直し忘れます。

入力データを集める

質を決めるのは、点検員の所見の文と、前回の提案と回答です。 判定の記号だけでは「要観察」の中身が分かりません。所見に「ロープに素線切れ1本」「戸の閉まりが遅い」と書かれているかどうかで、提案の理由の具体さが決まります。前回の提案に所有者が「来年度に検討」と答えていれば、今年の提案はその続きとして書く必要があります。

部品の供給の状況は、AIに調べさせません。 製造業者からの通知を受け取った時点で、担当が一覧に登録しておきます。AIが「この機種は部品の供給が終わっています」と書くと、根拠のない一文が所有者の判断を動かします。

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

保守管理システムから、建物ごとに直近12か月分の記録を CSV で書き出します。システムに API が無ければ、画面の書き出しの機能で作ったファイルを決まったフォルダに置く運用にして、スクリプトはそのフォルダを読みます。保守管理システムの製品ごとに書き出し方が違うので、ここは利用環境に応じた個別の作業になります。

記録には、スクリプトが番号を振ります。 点検の記録は INS-、交換履歴は PRT-、呼出の記録は CALL- に続けて通し番号を付け、AIにはこの番号で引用させます。保守管理システムの内部の番号をそのまま使わないのは、桁が長く、AIが写し間違えやすいからです。 振った番号と元の記録の対応は、スクリプトが表で持ちます。

AIへ渡す前に整形する

1. 号機・部位ごとのまとめ … 点検項目を「巻上機・ブレーキ」「主ロープ」「ドア装置」「制御盤」「かご室」「乗場」などの部位にまとめ、判定ごとの回数を数えます
2. 続いた回数の計算 … 同じ部位で「要観察」以上が何回続いたか、最初と最後の点検日はいつかを、スクリプトが数えます
3. 交換からの経過の計算 … 部品ごとに最後の交換日からの月数を出します
4. 呼出のくり返しの検出 … 同じ号機で同じ症状の呼出が12か月に2回以上あれば印を付けます
5. 所見の文の整理 … 点検員の所見から、作業員の氏名や携帯の番号など、提案に要らない個人の情報を取り除きます
6. 建物を特定する情報の置き換え … 建物名と所在地は建物の番号に置き換え、提案書に流し込むときに戻します
7. 分量の確認 … 号機の多い建物は記録が長くなるので、号機ごとに分けて呼び、最後にまとめます

2番目と3番目が、この構成でいちばん大事な前処理です。 回数と経過月数をAIに数えさせると、36回分の記録から「要観察が4回」を数え間違えても、文章は自然に読めてしまいます。 数字はスクリプトが出し、AIにはその数字を文章に入れることだけをさせます。

6番目は、外部に渡す情報を減らすためです。 提案の文章を作るのに、建物の名前と住所は要りません。

AIに処理させる

させるのは、まとめた記録を読んで、次の3つを記録の番号付きで書き出すことだけです。

提案の強さは3段階に分けて書かせます。 「次回の点検で確認」「1年以内の更新を検討」「早めの更新を検討」です。どの段階にするかの目安は自社で決めて指示に書き、AIはその目安に当てはめて書くだけにします。目安が無いと、同じ記録でも呼ぶたびに強さが変わります。

5行目がいちばん起きやすい失敗です。 製造から25年の機種を渡すと、記録に何も書かれていなくても「経年により巻上機の劣化が進んでいると考えられます」と書きます。年数だけを根拠にした提案は、所有者から見て営業の売り込みと区別がつきません。 記録に無いことは書かない、と明記します。

指示内容を固定する

あなたは昇降機の保守会社で、契約先の建物の所有者に出す提案書の下書きを作る担当です。
渡された記録だけを根拠に書いてください。記録に無いことを推測で書かないでください。

【書くもの】
1. focus_points：次回の点検で重点的に見る箇所（部位、見る点、理由）
2. renewal_proposals：部品の更新の提案（部品、提案の強さ、理由）
3. summary_text：この建物の昇降機の1年の状態の説明（所有者向け、400字以内）

【提案の強さ（level）の選び方】
- check_next ...... 次回の点検で確認する。要観察が1〜2回
- consider_1y ..... 1年以内の更新を検討。要観察以上が3回以上続く、
                    または同じ症状の呼出が2回以上
- consider_soon ... 早めの更新を検討。要是正・要修理の判定が続く、
                    または同じ部品の交換が12か月に2回以上
回数は「集計」に書かれた数字をそのまま使ってください。自分で数え直さないでください。

【厳守事項】
- すべての理由の文に、根拠にした記録の番号（INS-／PRT-／CALL-）を
  evidence_ids に入れてください。番号の無い理由は書かないでください。
- 製造年・設置年からの年数だけを理由にしないでください。
  年数に触れるときは、必ず記録の番号のある所見と組み合わせてください。
- 金額、部品の供給終了の時期、製造業者の対応は書かないでください。
  後で別の表から差し込みます。
- 安全に運行できるか、使用を止めるべきかは書かないでください。
- 法令に適合しているか、定期検査の結果をどう評価するかは書かないでください。
- 点検員の所見の文を引用するときは、quote にそのまま写してください。
  言い換えたり、程度を強めたりしないでください。
- 前回の提案への回答が「検討中」「来年度」なら、その続きとして書いてください。
- 記録が少なく提案できる箇所が無ければ、配列を空にしてください。
  無理に提案を作らないでください。

【建物の情報】{building}
【号機の情報】{units}
【集計（部位ごとの判定の回数、交換からの月数、呼出のくり返し）】{aggregates}
【点検の記録（番号付き）】{inspections}
【部品の交換履歴（番号付き）】{parts}
【故障の呼出の記録（番号付き）】{calls}
【前回の提案と回答】{last_proposal}

「自分で数え直さない」を書かないと、AIは記録を読んで回数を数え直し、集計と違う数字を書きます。 どちらが正しいかを人が確かめる手間が増えるだけなので、数字の出どころを1つに決めます。

「無理に提案を作らない」も大事な一文です。 提案書の下書きを頼まれると、AIは何かしら提案を書こうとします。記録に問題の無い建物に更新の提案が並ぶと、提案書全体の信用が落ちます。

出力形式を固定する

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

{
  "building_id": "B-0412",
  "focus_points": [
    { "unit": "1号機", "part": "ドア装置",
      "check": "かごの戸の閉まりの速さと、ドアスイッチの接点の状態",
      "reason": "直近6回の点検のうち4回で戸の閉まりの遅れの所見があり、同じ症状の呼出が2回ある",
      "evidence_ids": ["INS-031", "INS-037", "CALL-004", "CALL-009"],
      "quote": "かご戸閉まり遅れ。調整実施" }
  ],
  "renewal_proposals": [
    { "unit": "1号機", "part": "ドアスイッチ", "level": "consider_1y",
      "reason": "調整で一時的に改善するが、閉まりの遅れの所見と呼出がくり返されている",
      "evidence_ids": ["INS-031", "INS-037", "CALL-004", "CALL-009"] }
  ],
  "summary_text": "",
  "no_proposal_reason": ""
}

1つ目の理由は、evidence_ids をプログラムで確かめられることです。 スクリプトは、すべての番号が渡した記録に実在するか、level が集計の回数と目安に合っているかを確かめます。実在しない番号を含む文と、目安に合わない強さの提案は、提案書に流さず「要確認」に回します。

2つ目は、提案書の雛形に機械的に流し込めることです。 focus_points は「次回の点検の重点」の表へ、renewal_proposals は「更新のご提案」の表へ、そこに単価表の金額と供給の状況の一覧の予定を同じ行に差し込みます。AIが書いた文と、表から差し込んだ数字が、雛形の上で別の列に分かれるので、所有者に出す前に技術の責任者がどこを確かめればよいかがはっきりします。

3つ目は、no_proposal_reason で「提案なし」を正しく扱えることです。 記録に問題の無い建物では、配列を空にし、理由（「1年間の点検で要観察以上の判定なし」など）を書かせます。提案が無いことも、所有者への報告として意味があります。

システムへ連携する

どこにも自動で送りません。 提案書の下書きはファイルサーバーの「今月の下書き」のフォルダに置き、営業と技術の責任者に一覧で知らせるところまでです。所有者への送付は、承認の済んだものを営業が手で行います。

保守管理システムにも書き込みません。提案の結果（所有者の回答、受注したか）は、営業が顧客台帳に入れます。次の年の提案は、この回答を「前回の提案と回答」として読み込んで続きを書きます。

人が確認する

下書きは全件、2人が読みます。 営業が建物の事情に合わせて直し、技術の責任者が中身を確かめます。提案書は所有者の予算に関わるので、確認を件数で間引く設計にはしません。

1. 「要確認」に回った提案を先に見る … 実在しない番号、目安に合わない強さ、引用の食い違いがあったもの。多くは記録の書き方の揺れで、記録を見れば数分で決まります
2. 根拠の記録を開いて確かめる … 提案の一文ごとに付いた番号から、元の点検の記録に飛べるようにしておきます。番号があるので、1年分を最初から読み返す必要がありません
3. 提案の強さを決める … AIの level は目安の当てはめです。現地を知る点検員の意見を聞き、技術の責任者が最終の強さを決めます
4. 建物の事情に合わせて直す … 管理組合の総会の時期、予算の締めに合わせて、提案の順番と書き方を営業が直します
5. 直した内容を記録する … どの提案を消したか、強さをどう変えたかを残します

2番目が、この構成で時間が減る理由です。 これまで30分かけていた読み返しが、番号の付いた記録を開いて確かめる数分に変わります。逆に言えば、番号を確かめずに承認すると、この構成は危険になります。

目標は、120件をならして1件20分です。 号機の多い建物や故障の多い建物は30分を超え、記録に問題の無い建物は10分で終わります。

例外に対処する

最後の行を、提案書の流れに乗せないことが大事です。 提案書は月に1回の流れで、所有者に届くまでに何日もかかります。安全に関わる所見は、提案書を待たずに保守の側で対応します。 この構成が見つけた時点で、別の通知に分けます。

記録を残す

• 建物ごとに、そのとき渡した記録の書き出しファイルと、振った番号との対応表
• Claude API への指示の全文と、返ってきたJSONの全文
• スクリプトの確かめの結果（落とした提案と理由）
• 営業と技術の責任者が直した内容（消した提案、変えた強さ、書き足した文）
• 所有者へ送った提案書の最終版と送付日
• 所有者の回答と、受注したかどうか

1つ目を残すのは、所有者から「いつの点検でそう分かったのか」と聞かれたときに答えるためです。 提案書の番号から、当時の記録にそのまま戻れます。保守管理システムの記録が後で直されても、提案したときに見ていた記録が残ります。

4つ目は、指示を直す材料になります。 技術の責任者が毎回同じ種類の提案を消しているなら、指示の目安が自社の考えと合っていません。3か月分の直しの記録を見て、目安を見直します。