海外の装置メーカーのフィールドエンジニアが残す英文のサービス報告書を読み取り、作業内容・交換部品・停止時間を設備保全台帳に転記して、保守契約に照らした有償・保証の区分と請求の確認点を出す

処理の起点を決める

メーカーごとの受け取りの場所（S3 のフォルダ）にファイルが保存されたことを起点にします。 フォルダは fsr/<メーカーの記号>/<工場の記号>/ の形にし、どのメーカーの書式かを、保存した場所で決めます。 メーカーが分かれば、どの欄にどの情報があるかの設定を選べます。

PDFでメールされてくる報告書は、メールの受信から自動で保存することもできます。紙の控えは、現場の担当者が複合機でスキャンして同じフォルダに入れます。 経路が違っても、フォルダから先は同じ処理です。

読み取りを始めるとき、ClientRequestToken にファイルのハッシュを入れます。 同じ報告書がメールとスキャンの両方で入っても、読み取りは一度で済みます。完了は Amazon SNS の通知で受け、JobId が有効なあいだに結果を S3 に保存します。

入力データを集める

質を決めるのは、契約台帳です。 英文の契約には「Consumables are excluded from coverage」「Two (2) preventive maintenance visits per year」のように書かれています。これを台帳の列にしておけば、照合はプログラムで行えます。 原本を毎回読ませると、条項の解釈がその都度ぶれます。

故障の連絡の記録は、停止時間のために使います。 報告書の時刻だけでは、エンジニアが到着する前の停止が数えられません。停止の始まりは自社の記録、終わりは報告書の作業終了か、自社の復旧の記録と決めておきます。

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

欄はキーと値の組で返ります。 公式のページでは、KEY のブロックは VALUE のブロックとの関係を持ち、それぞれ文字のブロックを子に持つとされ、キーと値には同じ信頼度が付くとされています。「Serial No.」の値が何かは、この関係をたどって取ります。

質問は、欄の見出しがメーカーごとに違う項目に使います。 製造番号が「S/N」「Serial」「Tool ID」とばらばらなら、「What is the machine serial number?」と1つの質問で聞けます。公式のページでは、質問は英語の文書だけで使え、非同期の処理では1ページあたり30件までとされています。質問には別名（Alias）を付けられるので、serial_no のような台帳の項目名を付けておきます。

署名は、位置と信頼度だけが返ります。 公式のページでは、SIGNATURE のブロックは署名の位置の情報を持つとされています。誰の署名かは分かりません。 「署名欄に署名がある」ことを確かめるのに使い、署名が無い報告書は人に回します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFとパスワード付きのPDFは扱えません
2. スキャンの確認 … 紙のスキャンは、文字の高さが15ピクセル（150DPIで8ポイント相当）以上になる解像度で取ります。複写式の紙の2枚目は薄いので、1枚目の控えをもらうか、解像度を上げます
3. メーカーの設定の選択 … 保存した場所からメーカーを決め、欄の見出しの対応と質問の文を選びます
4. 装置の特定 … 製造番号で装置の台帳を引きます。見つからなければ、型式と設置場所の候補を出して人に回します
5. 日付と時刻の読み替え … 月・日の順か日・月の順かを、メーカーの設定で決めます。推し量りません
6. 時間の計算 … 開始と終了の時刻から作業時間を、自社の故障の連絡の記録と合わせて停止時間を計算します
7. 型番の照合 … 交換部品の型番を部品表と照らします。完全に一致しないものは、近い型番の候補を並べて人に回します

5番目を軽く見ないでください。 欧州のメーカーの報告書は日・月・年、米国のメーカーは月・日・年で書きます。「03/04」を3月4日と読むか4月3日と読むかで、保証期間の中か外かが変わることがあります。

7番目で近い型番に寄せないのは、手配の誤りにつながるからです。 「0190-47321」と「0190-47312」は別の部品です。読み取りの信頼度が低い型番は、原本の画像を見て人が決めます。

AIに処理させる

させるのは、作業の記述を区分することと、契約台帳のどの取り決めに当たりそうかを根拠付きで示すことの2つです。 数と日付は Textract とプログラムが扱います。

2行目が、請求の確認で効きます。 保守契約の多くは、操作の誤りや外部の要因による故障を範囲の外にしています。報告書に「Damage caused by improper handling」と書かれていれば、その作業は有償の候補になります。 AIにはその記述を写させ、範囲の外かどうかは契約台帳と人が決めます。

4行目を外すのは、AIに契約の原本を読ませると、条項の解釈が報告書ごとにぶれるからです。 台帳に無い論点が出たら、それは契約台帳を足す合図です。

指示内容を固定する

あなたは工場の設備保全課で、海外の装置メーカーのフィールドエンジニアが残した
英文のサービス報告書を読み、作業を区分して、保守契約の台帳のどの取り決めに
当たりそうかを示す担当者を手伝います。渡された読み取り結果と契約台帳だけを見てください。

【やること】
1. 作業内容の記述を、作業ごとに分け、work_type を次から選ぶ。
   preventive ／ repair ／ part_replacement ／ modification ／ other
2. 不具合の原因として書かれた記述があれば、cause_text にそのまま写す。
3. 作業ごとに、契約台帳の条項の番号から当たりそうなものを clause_candidates に挙げ、
   根拠にした報告書の記述を quote に写す。当たるものが無ければ none とする。
4. 作業内容を、台帳に入れる日本語の短い文にして summary_ja に書く。

【厳守事項】
- 保証の対象か、有償か、請求に応じるべきかを書かないでください。
  「保証対象です」「有償です」という言葉を使わないでください。
- 日付・時刻・時間・数量・型番を、書き換えたり計算したりしないでください。
  読み取り結果の文字をそのまま使ってください。
- quote と cause_text は、報告書の原文を1字も変えずに写してください。
- 報告書に書かれていない作業や原因を、推し量って補わないでください。
- 契約台帳に無い取り決めを、一般的な保守契約の慣行から補わないでください。
  台帳に当たるものが無ければ none とし、note に理由を書いてください。

【メーカーと装置】{maker} {machine}
【読み取り結果（欄・表・質問への答え）】{extracted}
【契約台帳（この装置の行）】{contract_row}

「一般的な保守契約の慣行から補わない」を書くのは、 AIが「消耗品は通常は範囲外です」のように、台帳に無いことを当然のように書き足すからです。この装置の契約で消耗品が範囲内なら、その一言が誤った有償の候補を生みます。

summary_ja は、台帳の読みやすさのためだけに使います。 区分と照合には、英文の原文と work_type を使います。要約の言い回しが判定に入り込まないように、役割を分けます。

出力形式を固定する

AIの出力は、Claude API の構造化出力で形を決めて受けます。 公式のページでは、output_config.format に JSON スキーマを渡すとスキーマに合う JSON が返るとされ、正式提供の機能です。プログラムがこれに日付と時間の計算、契約台帳との照合を足して、台帳への登録の案を作ります。

{
  "report_no": "FSR-24-0917",
  "machine_id": "CVD-03",
  "visit_date": "2026-09-17",
  "downtime_hours": 14.5,
  "labor_hours": 6.5,
  "travel_hours": 2.0,
  "signature_found": true,
  "works": [
    { "work_type": "part_replacement",
      "summary_ja": "真空ポンプの軸受を交換",
      "cause_text": "Bearing worn after normal operation",
      "clause_candidates": ["5.2"],
      "quote": "Replaced vacuum pump bearing",
      "parts": [ { "part_no": "0190-47321", "qty": 1,
                   "part_match": "exact", "min_confidence": 96.1 } ],
      "category_candidate": "warranty | contract | chargeable | unknown",
      "billing_checks": ["移動時間の請求が契約の上限内か"] }
  ],
  "needs_human": [ { "field": "", "reason": "low_confidence | no_machine | part_mismatch | no_signature" } ]
}

1つ目の理由は、作業ごとに区分の候補を持てることです。 1枚の報告書に定期点検と修理が混ざっていても、作業ごとに category_candidate が付くので、請求書の明細と1行ずつ照らせます。

2つ目は、billing_checks を請求書の到着まで残せることです。 「移動時間の請求が契約の上限内か」「消耗品の請求が別に来ないか」を、作業の時点で書き残します。請求書が届いたとき、購買の担当はこの一覧から見始められます。

システムへ連携する

設備保全台帳への登録は、承認の後だけです。 承認の前に登録すると、読み取りの誤った型番が台帳に残り、次の手配の根拠になります。 承認の画面では、読み取った値と原本の該当箇所を並べて見せます。

Claude を Amazon Bedrock から使う場合は、構造化出力の対応を先に確かめます。 公式のページでは、Bedrock では構造化出力が旧来の Bedrock の連携でだけ使え、Claude in Amazon Bedrock では使えないとされています。

人が確認する

設備保全の担当者が全件を承認します。 見る順を決めておきます。

1. needs_human を先に見る … 信頼度の低い欄、装置が特定できないもの、型番が部品表と合わないもの、署名が無いもの
2. 型番を原本で確かめる … 部品の表の該当セルから原本の画像を開き、型番を1文字ずつ見ます
3. 区分の候補を確かめる … chargeable と unknown は、根拠の記述と契約台帳の条項を読みます
4. 停止時間を確かめる … 自社の故障の連絡の時刻と、報告書の終了の時刻が合っているかを見ます
5. 承認して台帳に登録する … 有償の候補と確認点は、購買の担当に回します

3番目で区分を確定させないでください。 担当者が付けるのは「確認済みの候補」で、請求に応じるかは、請求書が届いたときに購買と決めます。 メーカーと話して保証の扱いが変わることもあるからです。

目標は、80件をならして1件9分です。 定期点検だけの報告書は数分、修理と部品交換が混ざったものは20分ほどかかる想定です。

例外に対処する

上から4行目が、最初の数か月は多く起きます。 手書きの型番は読み取りの信頼度が下がりやすく、ここだけは人の目を残す設計にしておきます。

記録を残す

• 報告書の原本と、受け取りの経路（メール／スキャン）
• Textract が返したブロックの全文と、組み立てた欄と表
• 使ったメーカーの設定と契約台帳の、その日の版
• AIの出力の JSON と、プログラムが付けた区分の候補と確認点
• 担当者が直した箇所 … どの欄の値を、どう直したか
• 請求書が届いたときの購買の判断と、メーカーとのやり取り

最後の行が、契約台帳を育てます。 請求書の段で「この作業は保証の扱いになった」と分かったら、その根拠を契約台帳の条項に書き足します。 担当者の記憶にあった判断が、表に移っていきます。