航空機整備会社が、海外の修理工場から部品と一緒に届く英文の部品適合証明書（FAA Form 8130-3／EASA Form 1）を読み取り、部品番号・シリアル・作業内容を部品台帳と発注に照らして、食い違いを受入前に拾う

処理の起点を決める

修理の発注ごとの受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 フォルダは crs/<修理の発注番号>/ の形にし、どの発注の証明書かを、保存した場所で決めます。 証明書の部品番号から発注を探すと、同じ部品番号の別のシリアルの発注と取り違えます。

読み取りを始めるとき、ClientRequestToken に「発注番号＋受領日」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。修理工場が同じ証明書を2回送ってきても、読み取りは1回で済みます。

完了は Amazon SNS の通知で受け、JobTag に入れた発注番号でどの発注かを知ります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存します。

部品が着いたときは、紙の証明書をスキャンして同じフォルダに入れます。 PDFと紙の内容が違えば、確認事項に出します。

入力データを集める

質を決めるのは、修理工場の一覧の承認番号です。 承認の欄の承認番号が一覧と合うかを見ることで、別の事業所や承認の無い工場が発行した証明書に気づけます。 一覧が古いと、正しい証明書まで食い違いとして出ます。

修理の発注の「頼んだ作業」は、証明書の作業の区分と同じ言葉にそろえます。 FAA の要領では、整備の後の 8130-3 の作業の区分（11欄）は「OVERHAULED」「REPAIRED」「INSPECTED」または「TESTED」「MODIFIED」とされています。発注の側も同じ区分で持てば、照合は言葉の一致で済みます。

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

問い合わせは、欄の番号を入れて書きます。

公式のページでは、問い合わせの答えは QUERY_RESULT として信頼度付きで返り、答えが見つからなければ空のまま返るとされています。空の答えは「記入が無い」の候補で、読み取りの失敗と区別するために、同じ欄のキーと値の組と照らします。

12欄の備考は、問い合わせで取りません。 備考は数行から十数行に及ぶので、12欄の見出しから13欄の見出しまでの範囲の LINE のブロックをつなげて全文を取ります。 結果は NextToken が返る限り呼び続け、全ページ分をそろえます。

チェックの欄は、SELECTION_ELEMENT の選択の状態で見ます。 公式のページでは、チェックの欄などの選択の要素は、選択されているかの状態とともに返るとされています。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFとパスワードで保護されたPDFは扱えないとされています
2. 様式の判別 … 2欄の様式名と1欄の当局の名前から、FAA Form 8130-3 か EASA Form 1 かを決めます。判別できないものは人に回します
3. 用途の判別 … 新品の出荷で使う13欄が埋まっているか、整備の後の返却で使う14欄が埋まっているかを見ます。FAA の要領では、新品の出荷では14a〜14e欄は整備の用のため塗りつぶすなどして使えないようにするとされています
4. 部品番号とシリアルの整え … 前後の空白、ハイフンの有無、数字の0と英字のOの取り違えの候補を整えます。整えた値と原文の両方を残します
5. 数量の確かめ … FAA の要領では、整備の後の返却では9欄の数量は「1」で、複数の部品を1つの記録で返却することはできないとされています
6. 手書きの訂正の印 … 単語の TextType が手書きのものに印を付けます

4番目を軽く見ないでください。 部品番号の「0」と「O」、「1」と「I」は、読み取りの誤りではなく、そもそも修理工場の印字の書き方の違いであることがあります。整えた値で台帳と照らし、一致しなければ原文のまま人に回します。

AIに処理させる

させるのは、12欄の備考の英文を項目に分けることと、問い合わせの下書きだけです。 欄の読み取りは Textract、照合はプログラムが行います。

FAA の要領では、12欄には「作業の説明（または作業の根拠の資料の参照）とその改訂」「耐空性改善通報やサービスブリテンへの適合」「修理」「改修」「交換部品」「寿命部品の状態」「PMA部品の使用」「添付」などを書く例が挙げられています。取り出す項目は、この例にそろえます。

3行目がいちばん起きやすい失敗です。 「SB 32-1145 incorporated」とあると、AIは部品番号の末尾が「-02」になると書きがちです。どう変わるかはサービスブリテンの本文で決まり、備考欄には書かれていないことがあります。 指示で「書かれていない部品番号を推測しない」と縛ります。

指示内容を固定する

あなたは航空機整備会社の品質保証部で、修理を終えた部品の部品適合証明書を
確かめる受入検査の担当者を手伝います。
渡された「12欄（Remarks）の全文」だけを見て、項目を取り出してください。

【取り出す項目】
- work_description … 実施した作業の説明（原文のまま）
- data_reference … 作業の根拠にした整備の資料の名前と改訂（CMM など）
- ad_sb … 耐空性改善通報（AD）・サービスブリテン（SB）の番号と、実施・適合の記載
- replaced_parts … 交換した部品の部品番号と品名
- llp_status … 寿命部品の使用時間・使用回数の記載
- pma_parts … PMA部品の使用の記載
- attachments … 添付の数と、その名前
- dual_release … EASA の要件での返却の記載があるか、その承認番号

【厳守事項】
- 書かれていない項目は空にしてください。前後の文から推して埋めないでください。
- 番号や部品番号は、書かれた文字をそのまま写してください。整えたり補ったりしないでください。
- 改修で部品番号がどう変わるかを推測しないでください。
  備考に新しい部品番号が書かれているときだけ、それを new_part_no に写してください。
- 各項目について、根拠にした文を evidence にそのまま写してください。
- 受け入れてよいか、問題があるかを書かないでください。

「新しい部品番号が書かれているときだけ写す」を明記するのは、ここが台帳の修正に直結するからです。 推した部品番号が台帳に入ると、次にその部品を装備する機体の記録が、実際と違う部品番号になります。

問い合わせの下書きの指示は短くします。「理由（pn_mismatch／sn_mismatch／work_mismatch／missing_approval／missing_signature）ごとに、発注番号・部品番号・シリアル・追跡番号を渡された値のまま書き、訂正した証明書の発行か内容の確認をお願いする形にする。部品の受入の可否に触れない」とします。

出力形式を固定する

照合の結果はプログラムがJSONで出し、備考の項目は Claude API の構造化出力で受けます。 公式のページでは、output_config.format に JSON スキーマを渡すと、スキーマに合う JSON が返るとされ、正式提供の機能です。

{
  "order_no": "RO-26-0813",
  "form_type": "FAA 8130-3",
  "use": "return_to_service",
  "tracking_no": "",
  "match": {
    "part_no": "matched | mismatch", "serial_no": "matched | mismatch",
    "qty_is_one": true, "status_vs_order": "matched | different"
  },
  "status_work": "INSPECTED/TESTED", "ordered_work": "OVERHAULED",
  "remarks": {
    "ad_sb": [ { "number": "SB 32-1145", "evidence": "SB 32-1145 incorporated" } ],
    "new_part_no": "", "replaced_parts": [], "llp_status": "",
    "pma_parts": "", "attachments": "", "dual_release": { "stated": false, "easa_approval_no": "" }
  },
  "approval_block": { "box_checked": true, "signature_found": true, "approval_no_in_list": true, "date": "2026-10-02" },
  "actions": [ "work_mismatch", "ledger_update_sb" ],
  "min_confidence": 96.1
}

1つ目の理由は、照合の結果と備考の項目を別の層に置けることです。 match と approval_block はプログラムが決め、remarks はAIが埋めます。照合の規則を変えても、AIの出力は使い回せます。

2つ目は、actions で担当者の次の作業が決まることです。

最後の行は、FAA の要領に沿った確かめです。 要領では、デュアルリリースのときは14a欄の「14 CFR 43.9 Return to Service」と「Other regulation specified in Block 12」の両方にチェックし、12欄に EASA Part-145 の承認番号を含む文を入れ、14c欄に FAA の承認番号を入れるとされています。

システムへ連携する

部品台帳には書き込みません。 改修の反映と部品番号の変更は、受入検査の担当者が確かめたうえで資材部が行います。読み取りの誤りが台帳に入ると、整備の計画が誤った記録で立ちます。

人が確認する

受入検査の担当者が全件の照合の結果を見ます。 見る順を決めておきます。

1. pn_mismatch・sn_mismatch を先に見る … 原本と発注を見比べ、取り違えか修理工場の誤記かを確かめます
2. missing_approval・missing_signature を見る … 原本で記入を確かめ、本当に無ければ修理工場に訂正した証明書を頼みます
3. work_mismatch を見る … 頼んだ作業と違う理由を備考で読み、必要なら修理工場に確かめます
4. **ledger_update_* を見る … 取り出された改修と部品番号を原文と見比べ、資材部に台帳の修正を頼みます**
5. 部品が着いたら現物を照らす … 銘板と紙の証明書を照らし、受入を決めるのは有資格の検査員です

2番目で「記入が無い」と出ても、すぐに不備と決めつけません。 印字が薄い、署名が欄の外にはみ出している、といった読み取りの問題のこともあります。原本で確かめてから問い合わせます。

例外に対処する

5行目は、FAA の要領で訂正の証明書の書き方が決まっているからです。 要領では、事務的な誤りを直すときは、12欄に直した欄と前の証明書の追跡番号を書き、14e欄に訂正した日付を入れるとされています。

記録を残す

• 証明書の原本（PDFと紙のスキャン）と、保存した場所（発注・受領日）
• Textract が返した結果の全文と、組み立てた12欄の全文
• 照合の結果（match、approval_block）と、備考の項目と根拠の文
• 担当者が直した箇所と判断 … どの項目を、どう直したか、問い合わせたか
• 台帳の修正の依頼と、資材部が直した日
• 修理工場への問い合わせと、届いた訂正の証明書

3つ目と4つ目は、監査で受入検査の経過を示す材料になります。 何を照らし、どこで誰が判断したかを後から追えるようにします。