海外法人の口座開設で届く英文の設立証明書・役員名簿・株主名簿を読み取り、役員と実質的支配者の記載を申込内容と照合する

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 口座開設の申込は毎日ばらばらに届くため、1日1回の定時実行にはしません。 受け取った日のうちに不足を返せば、照会の往復を1回で済ませられます。

ファイル名の先頭に申込番号を付けるところまでを営業担当が行います。申込番号の無いファイルは、照合の相手を決められないので、処理を始める前に止めて営業担当に戻します。 1件の申込に書類が複数あるため、申込番号ごとに「書類がそろった」合図を受付の仕組みから出し、それを待ってまとめて動かします。

S3 への保存を AWS Lambda が受け、書類ごとに StartDocumentAnalysis を呼びます。ClientRequestToken に申込番号とファイルのハッシュから作った値を入れると、同じトークンで呼び直しても同じ JobId が返り、同じ書類を二度読みません。 JobTag には申込番号を入れ、完了の通知（Amazon SNS）からどの申込の書類かを引けるようにします。通知の状態が SUCCEEDED であることを確かめてから結果を取り、すぐ S3 に保存します。 JobId は7日間しか有効ではありません。

入力データを集める

質を決めるのは、下の3つです。 前回の確認記録が無ければ、継続取引先の「何が変わったか」を言えません。国ごとの書類の対応表が無ければ、足りない書類を挙げられません。 シンガポールの法人で役員を示すのが何という書類かを知らないと、「役員名簿が無い」とも「別の書類で足りる」とも言えないからです。

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

読み取りは StartDocumentAnalysis に FeatureTypes として FORMS、TABLES、QUERIES、LAYOUT を指定して行います。全文の行と単語は、指定した機能にかかわらず返ります。 結果は GetDocumentAnalysis で取ります。1回に返るブロックは既定で最大1,000件なので、NextToken が返る限り続けて取ります。 JobStatus が PARTIAL_SUCCESS のときは Warnings に出たページを記録し、そのページを含む書類は unreadable として人に回します。

質問は QueriesConfig に並べ、別名（Alias）を付けます。非同期の処理では1ページあたり30問までです。公式の手引きは、文書の中の言葉を使って質問を作ること、日付が複数ある文書では何の日付かを特定して聞くことを勧めています。

質問は既定で1ページ目しか見ません。 ページの指定が無いと ["1"] になるため、**Pages に ["*"] を入れて全ページを対象にします。**

役員と株主は、質問で取りません。 手引きは、表全体や行・列をまとめて質問で取り出すことには対応していないとしています。役員名簿と株主名簿は TABLES の結果から、行ごとに読みます。質問は、設立日のように答えが1つに決まる項目にだけ使います。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFは扱えないため、印刷し直してPDFにします
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。保護されたものは、営業担当から解除したものを取り寄せます
3. ページ数とサイズの確認 … 非同期の処理でPDFとTIFFは500MB・3,000ページが上限です。定款の全文と名簿がまとめて1ファイルになっているものは、名簿の部分に分けます
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。公証の印影の近くの小さな文字は、300 DPIでスキャンし直してもらいます
5. 言語の確認 … 全文の行に英語以外の文字が多ければ、その書類は読み取りの対象から外し、翻訳文の提出を求めます
6. 申込書の申告の取り出し … 受付の仕組みから、申告された役員と実質的支配者を氏名・生年月日・持株比率の形で取り出します

4番目を軽く見ないでください。 読めないだけの記載は、「書かれていない」と区別がつきません。

AIに処理させる

させるのは、書類の種類を見分け、法人・役員・株主の項目を原文のまま切り分け、根拠の位置を添えることだけです。

4行目がいちばん起きやすい失敗です。 組織図に「Holding Co. 60%」と描かれていて、その会社の株主名簿が出ていないとき、AIは組織図から株主を書き足しがちです。組織図は申告の一種で、名簿の代わりにはなりません。 名簿が無ければ「無い」と返させ、足りない書類の一覧に載せます。

指示内容を固定する

あなたは銀行の取引時確認の担当として、外国法人の英文の会社書類を読みます。
OCRが返した読み取り結果（全文、キーと値、表とセル、質問への答え）だけを見て、
項目を切り分けてください。推測で埋めないでください。

【やること】
1. 書類の種類を次から1つ選ぶ:
   certificate_of_incorporation / register_of_directors / register_of_members /
   certificate_of_good_standing / ownership_chart / other
2. 法人名・登録番号・設立日・設立地・登録上の住所を、原文の綴りのまま写す
3. 役員を1人1行で書き出す（氏名、役職、就任日、退任日）
4. 株主を表の1行ごとに書き出す（株主名、個人か法人か、株式の種類、株数、行番号）

【厳守事項】
- 書かれていない項目は "not_found" とする。他の書類から補わない。
- 文字は見えるが確定できない値は "unreadable" とし、OCRの信頼度をそのまま写す。
- 表の合計の行（Total など）は株主として書き出さない。
- 株数は書かれた数字をそのまま写す。比率を計算しない。合計を出さない。
- 退任日がある役員は status を "resigned" にし、現任と混ぜない。
- 組織図（ownership_chart）の内容を、株主名簿の株主として書き出さない。
- 株主が法人の場合は holder_type を "entity" とし、その法人の株主を推測しない。
- 法人名・氏名の綴りを直さない。大文字・小文字・敬称もそのまま写す。
- 株式の種類に議決権の有無が書かれていなければ voting は "not_stated" とする。
- 実質的支配者に当たるかどうかを書かない。
- 各値の evidence には、根拠にした原文の文字列とページ番号を入れる。

【読み取り結果】{textract_result}
【書類のファイル名】{file_name}

「比率を計算しない」と「合計を出さない」を分けて書いているのには理由があります。 比率だけを禁じると、AIは「合計1,000,000株」のような数字を作り、それが名簿の数字と食い違っても見分けがつきません。数字を作る余地そのものを閉じます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とスキーマを指定）を使い、形の崩れた応答を後段に流さないようにします。

{
  "application_no": "",
  "file_name": "",
  "document_type": "register_of_members",
  "entity": {
    "name": { "value": "", "status": "found | not_found | unreadable", "evidence": "", "page": 1 },
    "registration_no": { "value": "", "status": "", "evidence": "", "page": 1 },
    "incorporation_date": { "value": "", "status": "", "evidence": "", "page": 1 }
  },
  "officers": [
    { "name": "", "role": "", "appointed": "", "resigned": "", "status": "current | resigned", "evidence": "", "page": 1 }
  ],
  "shareholders": [
    { "name": "", "holder_type": "individual | entity", "share_class": "", "voting": "yes | no | not_stated",
      "shares": "", "table_row": 0, "confidence": 0, "evidence": "", "page": 1 }
  ]
}

理由は、AIの出力とプログラムの計算を別の層に置けることです。 shareholders はAIが原文のまま埋め、比率と照合の結果はプログラムが別の表に書きます。判定の規則が変わっても、直すのはプログラムだけです。

照合の結果は、プログラムが次の形で出します。

比率の計算は、議決権のある株式だけで行います。 voting が not_stated の株式があれば、その法人の比率は確定させず unreadable 扱いで人に回します。25％を超える人と50％を超える人を機械的に並べるのはプログラムの仕事で、その人が実質的支配者に当たるかを決めるのは人の仕事です。

システムへ連携する

顧客管理の仕組みへは書き込みません。 この構成が出すのは照合の結果と確認記録の下書きまでで、確定した内容を登録するのは責任者の承認の後、人が行います。 書き込みを足すと、読み違いがそのまま顧客の情報になります。

照会文の下書きは営業担当の画面に出すだけにします。取引先へ送るのは営業担当です。

人が確認する

担当者が開くのは、match 以外の項目だけです。 match の項目は一覧で流し見ます。全項目を開く設計にすると、第10章の20分には収まりません。

1. unreadable を先に見る … 原本で該当箇所を読み、値を手で入れます。多くはスキャンの取り直しで解決します
2. candidate を決める … 生年月日や住所など、名前以外の項目もあわせて見て、同一人物かを決めます
3. mismatch と not_found の根拠を確かめる … evidence と table_row で原本の該当行を開きます。申告の誤りか、書類が古いかを分けます
4. 持株比率の計算の元を確かめる … 比率が25％や50％の境目に近い株主は、計算に使った株数を原本で確かめます
5. 判定を変えたら記録する … どの項目を、どの判定に変えたか、理由を残します

4番目を省かないでください。 境目のすぐ上か下かで、確認する人が増えるか減るかが変わります。読み取りの1桁の違いが、そのまま結論の違いになる場所です。

例外に対処する

上から5行目が、最も時間を取る例外です。 遡りが途中で止まったことを、止まった段とあわせて一覧に出すのが、照会を1回で済ませる条件です。

記録を残す

• 原本のPDFと、受け取った日時・申込番号・経路
• OCRが返したJSONの全文（GetDocumentAnalysis の全ページ分）
• AIの切り分けの結果（entity、officers、shareholders）
• プログラムが出した持株比率と照合の結果、そのとき使った申込書の申告の内容
• 担当者が判定を変えた記録 … どの項目を、どの判定に、なぜ変えたか
• 責任者の承認の日時と、確定した実質的支配者
• 照会した内容と、取引先からの回答の書類

確認記録とその添付は、7年間の保存が求められています。 犯罪収益移転防止法の概要で、特定事業者の義務として確認記録・取引記録等の作成と7年間の保存が挙げられています。読み取り結果とAIの出力を確認記録の一部として残すか、作業の記録として残すかを、最初に決めておきます。