在留資格の申請に添付する外国語の証明書を読み取り、日本語の訳文の下書きと、申請書へ写す項目の一覧を作る

処理の起点を決める

案件フォルダの「受領」に証明書が保存されたことを起点にします。 1通ごとに動かし、処理が終わったものだけを「処理済み」へ移します。 「受領」に残っている数が、そのまま未処理の数になります。

依頼者からの受け取りは、メールの添付、チャットの写真、郵送の原本と経路がばらばらです。 どの経路でも、補助者が案件フォルダに保存するところでそろえます。ファイル名は「案件番号_書類の種類_連番」と決めておきます。 書類の種類は補助者が付けますが、AIが読んだ種類と違えば、食い違いとして一覧に出します。

入力データを集める

旅券の記載は、補助者が人の目で入力します。 照合の基準を自動で作ると、基準の側の読み取り誤りと、証明書の側の読み取り誤りが重なったときに、食い違いとして出てきません。 基準は人が作り、照合は機械で行います。

用語集は、事務所の訳文をそろえるために持ちます。 「Bachelor of Business Administration」を「経営学士」とするか「経営管理学士」とするかが担当者で違うと、同じ大学の卒業生の訳文が案件ごとに変わります。 一度決めた訳語を表にして、指示文と一緒に渡します。

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

読み取りは、ワークフローから Enterprise Document OCR を呼ぶだけです。証明書の言語が分かっていれば、言語のヒントを渡します。 依頼者の国籍から見当をつけ、外れていればページごとの言語の結果で確かめます。

オンラインの処理には上限があります。 制限のページでは、オンライン処理のファイルサイズが40MBまで、Enterprise Document OCR のオンライン処理は15ページまで、画像の解像度は1ページあたり40メガピクセルまで（PDFには適用されない）とされています。証明書は数ページなので、通常はオンライン処理で足ります。

AIへ渡す前に整形する

1. 形式の確認 … PDF、TIFF、JPEG、PNG などの対応形式かを確かめ、それ以外はPDFにします
2. 向きと傾き … スマートフォンの写真は傾いています。傾きの補正は OCR の側で行えますが、上下が逆の写真は回してから入れます
3. 品質スコアを見る … 0.5を下回ったページは、返ってきた原因（ぼやけ、照り返しなど）を添えて、依頼者に撮り直しを頼む文面の下書きを作ります
4. 表裏と別紙をそろえる … 裏面の追記、アポスティーユや認証の別紙を、同じ証明書の続きのページとして1つにします
5. 番号を振る … 段落と行の単位で S-01 から番号を振り、ページ番号と位置を持たせます
6. 旅券番号を落とす … 生成AIに渡す依頼者の基本情報は、氏名・生年月日・国籍だけにします

3番目を軽く見ないでください。 照り返しで1行が飛んだ証明書を訳すと、その行は訳文から黙って抜けます。 読み取りの段階で撮り直しを頼むほうが、訳文を直すより早く終わります。

AIに処理させる

させるのは、次の3つです。

氏名は訳しません。 原文の綴りをそのまま書かせ、カタカナの表記は書かせません。申請書にどう書くかは、旅券と依頼者の意向で決まることで、AIが決めることではありません。

日付は、原文の文字列と、日月年か月日年かの見立てを分けて書かせます。 05/04/2019 のようにどちらとも読めるものは ambiguous とし、見立てを1つに決めさせません。発行国の慣習は人が確かめます。

暦の換算もさせません。 仏暦や民国暦で書かれた年は、原文の年と暦の名前だけを書かせ、西暦への換算は Python の規則で行います。 換算は足し算で決まるので、AIに任せる理由がありません。

1行目がいちばん起きやすい失敗です。 スタンプで半分隠れた行を渡すと、前後の文脈からそれらしい文を作り、その瞬間、読めなかったという事実が消えます。

指示内容を固定する

あなたは行政書士事務所で、在留資格の申請に添付する証明書の訳文の下書きを作ります。
OCRの読み取り結果だけを見てください。推測で埋めないでください。
この下書きは、職員が原文と照らして直し、翻訳者として署名します。

【訳し方】
- S- の番号ごとに、1つずつ日本語に訳してください。番号をまとめたり、省いたりしないでください。
- 原文に書かれていることだけを訳してください。説明や補足を足さないでください。
- 印章は〔印〕、手書きの署名は〔署名〕、透かしは〔透かし〕と書いてください。
- 読めない箇所は〔判読不能〕と書き、status を unreadable にしてください。
  前後の文から補わないでください。
- 用語集にある語は、用語集の訳語を使ってください。
- 証明書の番号や登録の番号は、原文の文字列をそのまま写してください。

【氏名と日付】
- 氏名は訳さず、原文の綴りのまま書いてください。カタカナにしないでください。
- 日付は、原文の文字列をそのまま original に写してください。
- 日月年か月日年か、どちらとも読める日付は ambiguous にしてください。1つに決めないでください。
- 仏暦・民国暦などの年は、年の数字と暦の名前だけを書いてください。西暦に換算しないでください。

【転記項目】
次の項目を、証明書に書かれている場合だけ書き出してください。
氏名／生年月日／出生地／国籍／父母の氏名／婚姻の年月日／配偶者の氏名／
学校名／学位・課程／卒業の年月日／勤務先／役職／在職期間／発行機関／発行日
書かれていない項目は value を空にし、status を missing にしてください。
それぞれに、根拠にした S- の番号を書いてください。

【厳守事項】
- 依頼者の基本情報は照合のための参考です。証明書の記載をそれに合わせて直さないでください。
- 書類として足りるか、どの在留資格に使えるかは書かないでください。
- 最後に、訳した S- の番号をすべて並べてください。

【読み取り結果】{ocr_segments}
【依頼者の基本情報】{applicant}
【用語集】{glossary}

「依頼者の基本情報に合わせて直さない」を明記しないと、綴りが旅券にそろいます。 旅券の NGUYEN THI を渡すと、証明書の Nguyễn Thị も同じ形に書き換えます。照合の材料として渡したものが、照合する前に答えを消してしまいます。

「訳した番号をすべて並べる」は、訳し落としの検査です。 並んだ番号を、前処理で振った番号の一覧と比べ、足りなければどの番号が抜けたかがそのまま分かります。

出力形式を固定する

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

{
  "case_id": "",
  "document": {
    "type": "marriage | birth | graduation | employment | other",
    "issuer": { "original": "", "ja": "" },
    "issue_date": { "original": "", "calendar": "gregorian | buddhist | roc | other", "order": "dmy | mdy | ymd | ambiguous" }
  },
  "segments": [
    { "id": "S-01", "page": 1, "ja": "", "status": "ok | unreadable", "note": "" }
  ],
  "fields": [
    { "name": "date_of_marriage", "original": "", "status": "ok | missing | unreadable | ambiguous", "source": ["S-07"] }
  ],
  "translated_ids": []
}

1つ目の理由は、segments の番号で訳し落としを機械で見つけられることです。 translated_ids と前処理の番号の一覧が合わなければ、ワークフローが様式への差し込みを止めます。

2つ目は、日付を original と calendar と order に分けていることです。 西暦の年月日は、この3つから Python が組み立てます。order が ambiguous のものは組み立てず、食い違いの一覧に回します。

3つ目は、fields の source で申請書の値の出どころを追えることです。 申請書の婚姻の年月日を確かめるとき、S-07 の原文と訳文を並べて見るだけで済みます。

後段の Python は、fields を旅券の記載と突き合わせ、次のように印を付けます。

match_diacritics を一致として扱わないのは、申請書の表記を決めるのが人だからです。 ベトナム語の声調記号や、ドイツ語のウムラウトを外せば一致する綴りは、旅券の側の書き方にそろえて申請書に書くことが多いものの、依頼者ごとに確かめる余地が残ります。印を付けて、確かめる一覧に回します。

システムへ連携する

申請書には書き込みません。 転記項目の一覧は申請書の隣に置く表で、申請書に写すのは補助者です。 下書きから申請書へ直接写す経路を作ると、ambiguous の日付が確かめる前に申請書に入ります。

訳文の様式の署名欄も空のまま出します。 翻訳者の氏名と署名は、確かめた人が入れます。

様式の中身は、事務所で1つに決めておきます。 冒頭に書類の種類と原文の言語、本文に番号つきの訳文、末尾に翻訳の日付と翻訳者の氏名・署名の欄を置きます。番号は確かめるための道具なので、提出用の訳文から外すかどうかも事務所で決めます。 外す場合も、番号つきの版を案件フォルダに残します。

人が確認する

補助者が開くのは、訳文の様式と、食い違いの一覧です。 次の順に見ます。

1. 品質の印と unreadable を先に見る … 撮り直しで直るものか、依頼者に聞くものかを分けます
2. 食い違いの一覧を片づける … ambiguous の日付は発行国の慣習で決め、mismatch と swap_suspected は原文の画像で確かめます
3. 原文と訳文を番号で並べて読む … 読める言語は全番号、読めない言語は手書きの印と転記項目の根拠の番号を重く見ます
4. 用語集にない訳語を拾う … 新しく決めた訳語は用語集に足します

3番目の読めない言語の扱いを決めておきます。 ネパール語の証明書を補助者が全文確かめることはできません。転記項目の根拠になった番号だけは、依頼者に原文を指さしてもらいながら確かめます。 照らす箇所が番号で決まっているので、聞く範囲が絞れます。

最後に行政書士が確かめ、翻訳者が署名します。 署名した人が、その訳文の正確さに責任を持ちます。下書きを作ったのがAIでも、この順番は変わりません。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題ではなく、依頼者からの受け取り方の問題です。 撮り方の案内を依頼者向けに1枚作るほうが、読み取りの設定を変えるより効きます。

記録を残す

• 元の画像と、受け取った日時・経路
• OCRが返した結果の全文（全文、段落・行、信頼度、品質スコア、言語）
• 生成AIが返したJSONと、使った指示文・用語集の版
• 補助者が直した番号と、直した前後の訳文
• 食い違いの一覧と、それぞれをどう決めたか（発行国の慣習、依頼者への確認など）
• 翻訳者として署名した人と日付

4つ目の「直した番号」は、言語ごとの下書きの質を見る材料になります。 直しの多い言語が分かれば、その言語の証明書だけは確かめる時間を多めに見込みます。

5つ目の「どう決めたか」は、同じ国の次の案件で効きます。 ある国の証明書の日付が日月年の順だと一度確かめれば、次からはその国の ambiguous を同じ根拠で片づけられます。 発行国ごとの慣習を一覧にして、補助者のあいだで共有します。