修繕の造船所が、船級協会の検査員から届く英文の検査の指摘事項を読み取り、船ごと・区画ごとの是正の一覧と完了の確認表を作る

処理の起点を決める

受付フォルダ（Amazon S3 のバケット）にファイルが保存されたことを起点にします。 指摘の書面は立会いの当日か翌日に届き、工事の段取りは翌朝から組まれます。 夕方に届いた書面を翌朝の工程会議までに一覧にしておくことで、指摘が工事の段取りに間に合います。

ファイル名の先頭に、船の番号（自社の入渠の番号）を付けます。 書面の中に船名は書かれていますが、同じ船名の船が入れ替わりで入渠することがあり、 書面の船名だけで船を決めると、前の入渠の一覧に混ざります。

出渠前の残りの一覧は、毎朝の定時に作ります。 出渠の予定日から数えて、完了の記載の無い指摘を区画ごとに並べます。 予定日の5日前からは、残りが1件でもあれば担当者に知らせます。

終わったファイルは処理済みの場所へ移します。 移すのは成功したときだけで、受付フォルダに残っている数が、そのまま未処理の数になります。 非同期の解析には ClientRequestToken を付け、同じ書面を二度読まないようにします。

入力データを集める

質を決めるのは、区画の表の別名の列です。 別名が無ければ「3P W.B.TK」は区画に寄らず、工事番号の候補も出ません。 別名は、過去の入渠の書面と工事の管理表を並べて、同じ区画の書き方を拾い集めて作ります。

船の型が同じなら、区画の表は使い回せます。 同じ造船所で建造された姉妹船は区画の配置が同じことが多く、1隻分の別名を作れば、次の入渠からはその船の型の表として使えます。

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

書面は、非同期の StartDocumentAnalysis に S3 の場所を渡して読みます。FeatureTypes に LAYOUT・TABLES・FORMS を指定します。 完了は Amazon SNS に通知させ、GetDocumentAnalysis で結果を取ります。JobId は7日間しか有効でないため、結果はその日に S3 へ写します。

指摘の文は、レイアウトの読む順のまま Claude に渡します。 行をばらばらに渡すと、2行にまたがった指摘が2件に割れたり、隣の指摘の区画を取り違えたりします。 箇条書き（LAYOUT_LIST）は、その下の段落ごとにまとめて渡します。

TextType が手書き（HANDWRITING）の文字は、印を付けて渡します。 手書きの数字は、フレームの番号の読み違いが起きやすいところです。手書きで信頼度の低い数字を含む指摘は、取り出しの後に needs_review にします。

AIへ渡す前に整形する

1. 形式の確認 … JPEG・PNG・PDF・TIFF のいずれかであることを確かめます。XFA 形式の PDF は扱えません
2. パスワードの確認 … パスワードで保護された PDF は読めません。解除した版を検査員の事務所に頼みます
3. 写真の大きさ … 各辺10,000ピクセル以下、文字の高さは15ピクセル（150 DPI で8ポイント相当）が下限です。手書きの用紙を斜めから撮った写真は、奥の行が下限を割ります
4. 写真の撮り方をそろえる … 用紙を正面から、1枚に1ページで撮ってもらいます。傾きは読めますが、手ぶれと影は読めません
5. 重複の確認 … 同じ船・同じ立会いの日・同じページ数の書面は重複の候補として印を付けます
6. 書面の種類の見分け … 題の文字で、指摘の書面、完了の報告、それ以外（立会いの依頼、証書の写し）に分けます

4番目を省かないでください。 現場の写真は、狭い区画の中で撮られることがあります。読めない数字を Claude が前後の文から補うと、フレームの番号が実際と違う指摘が一覧に入ります。 撮り方をそろえるほうが、後で直すより早く済みます。

AIに処理させる

させるのは、読み取った文字を指摘ごとに分け、決まった項目に書面の文言を写すことだけです。 区画を寄せる、工事番号を探す、完了を結び付ける処理は、取り出しの後に Python の規則が行います。

3行目と5行目が、この構成でいちばん大事な線です。 期限を Claude に日付で書かせると、工程が延びたときに一覧の期限が古いまま残ります。 完了を推し量らせると、工事が終わっただけの指摘が「片付いた」として出渠の確認から抜けます。

指示内容を固定する

あなたは造船所の品質管理部で、船級協会の検査員から受け取った
指摘の書面を、指摘ごとの項目に分ける担当です。
渡すのは OCR の結果で、読む順に並んでいます。書面に書かれた
語だけを使ってください。

【分け方】
- 1件の指摘は、区画の文言から始まり、処置の文言で終わることが多い。
  項目番号があれば、番号ごとに1件とする。
- 2行以上にまたがる文は1件にまとめる。1つの文に2つの区画が
  書かれていれば、区画ごとに分け、同じ処置の文言を両方に写す。

【厳守事項】
- 区画・フレーム・舷・不具合・処置・区分・期限は、書面の語の
  とおりに写す。言い換え・略語の展開・綴りの訂正をしない。
- 書かれていない項目は空にする。前後の指摘や区画から補わない。
- フレームの番号が読めない（[?] の印がある）ときは、数字を推し量らず
  frame_text に印のまま写し、uncertain を true にする。
- 期限は "prior to departure" などの文言のまま写す。日付に直さない。
- 区分の文言が無い指摘に、区分を付けない。
- "examined and found satisfactory" "dealt with" "cleared" などの
  完了の記載は、closure_statements に分けて写し、対象の項目番号か
  区画の文言を一緒に写す。完了したかどうかを判断しない。
- 指摘の当否、重さ、是正の方法を書かない。
- quote に、その指摘の元の文をそのまま写す。

【OCR の結果（読む順）】{layout_text}
【この書面の見出し】{header_kv}

「略語の展開・綴りの訂正をしない」を明記しないと、「WBT」を「Water Ballast Tank」に展開します。 展開された語は区画の表の別名に当たらず、照合で unknown_area に落ちます。 別名の表は書面の語のまま作るので、Claude にも書面の語のまま返させます。

quote を必ず写させるのは、確認を速くするためです。 Bedrock の構造化出力は、Anthropic のモデルでは引用の機能（citations）と併用できず、併用すると400のエラーになります。そのため引用の位置は使わず、元の文を写させて、プログラムの側で OCR の文字と照らします。 照らして一致しない quote は、Claude が文を作り変えた合図なので needs_review にします。

出力形式を固定する

Converse の outputConfig.textFormat に JSON スキーマを渡し、次の形で受け取ります。

{
  "vessel_ref": "D-2611",
  "class_society_text": "",
  "visit_date_text": "",
  "findings": [
    {
      "item_no": "3",
      "area_text": "No.3 WBT (P)",
      "frame_text": "Fr.45-48",
      "side_text": "P",
      "defect_text": "side shell longitudinals wasted beyond allowable",
      "action_text": "to be cropped and renewed",
      "category_text": "Condition of Class",
      "due_text": "prior to departure",
      "uncertain": false,
      "quote": ""
    }
  ],
  "closure_statements": [
    { "ref_item_no": "5", "ref_area_text": "", "statement_text": "examined and found satisfactory", "quote": "" }
  ]
}

Lambda の側で、この結果に区画の表の area_id、工事番号の候補、状態を足して一覧に書きます。状態は matched ／ unknown_area ／ no_work_order ／ awaiting_surveyor ／ closed ／ needs_review です。

1つ目の理由は、書面の語と自社の区画を別の欄に持てることです。 area_text は書面のまま、area_id は区画の表で寄せた結果です。寄せ方が誤っていても、書面の語が残っていれば一覧を作り直せます。

2つ目は、完了の記載を指摘と別に持てることです。 closure_statements を前の指摘に結び付けるのは規則で、結び付かない記載は人に回ります。 完了を指摘の欄に混ぜると、どの立会いで認められたかが分からなくなります。

スキーマの書き方には制約があります。 すべての object に additionalProperties: false を付ける必要があり、数値の最小・最大や文字の長さの制約は使えません。 必須でない項目は全体で12個までなので、項目は必須にして、書かれていなければ空の文字を返させます。 新しいスキーマの最初の呼び出しは、組み立てに最大90秒ほどかかります。

システムへ連携する

工事の管理表には書き込みません。 工事番号を切るのは工事の担当で、指摘から自動で工事番号を作ると、船主が発注していない工事が始まります。 候補が無い指摘は no_work_order として、工事の担当への依頼の一覧に出すだけです。

人が確認する

人が開くのは matched 以外の指摘だけです。 全件を開く設計にすると、第10章の8.0時間には収まりません。

1. needs_review を先に見る … 手書きの数字、quote の不一致。書面の画像で、フレームの番号と区画を確かめます
2. unknown_area を見る … 区画の表に別名を1行足すか、本当に表に無い区画かを分けます
3. no_work_order を工事の担当に回す … 追加の工事にするかは、船主の監督が決めます
4. awaiting_surveyor を立会いの段取りに入れる … 工事が終わった指摘を、次の立会いで見てもらいます
5. 完了の記載の結び付けを確かめる … 前の項目番号が無い記載は、区画と不具合で人が結び付けます

目標は、40件をならして1件12分です。 それを超える月は、区画の表の別名か、写真の撮り方が足りていません。

例外に対処する

大半は AI の精度ではなく、写真の撮り方と区画の表の整い方の問題です。

記録を残す

• 元の書面と、受け取った日時・入渠の番号
• AWS Textract が返した JSON の全文と、Claude が返した JSON
• 指摘ごとの判定と、そのとき参照した区画の表・工事の管理表の行
• 人が判定を覆した記録 … どの指摘を、どの区画・工事に結び付けたか
• 完了の記載と、それが書かれた書面と立会いの日
• 船の型ごとの unknown_area の件数

5つ目は、船主や船級協会から「いつ認められたか」を問われたときの答えになります。