海外のカストディアンから毎月届く英文の保管残高報告書を読み取り、銘柄ごとの数量・評価額・配当と利息の入金を自社の有価証券台帳と照らして、差異を理由の候補付きで一覧にする

処理の起点を決める

口座ごとの受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 フォルダは custody/<カストディアンの記号>/<口座の記号>/<対象月>/<報告書の種類>/ の形にし、どの口座のどの月のどの報告書かを、保存した場所で決めます。 報告書の中の口座番号を読み取って決めると、似た番号の口座と取り違えます。

読み取りを始めるとき、ClientRequestToken に「口座の記号＋対象月＋報告書の種類＋版」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。

完了は Amazon SNS の通知で受けます。 通知の状態が SUCCEEDED であることを確かめてから GetDocumentAnalysis を呼ぶ、と公式のページにあります。JobTag に口座の記号を入れておくと、通知だけでどの口座の報告かが分かります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存します。

照合は、同じ口座の報告書と明細の両方がそろってから始めます。 片方だけで照合すると、入金の確認が抜けたまま結果が出ます。

入力データを集める

質を決めるのは、銘柄の情報の「適用される源泉税の率」の列です。 これがあれば、明細の源泉税を総額で割った率と比べて、取られすぎの候補を機械で拾えます。 列が無いと、手取り額が入ったかどうかしか確かめられません。

数の書き方は、カストディアンごとに設定します。 桁区切りがコンマか点か、小数点がどちらかを、カストディアンごとに1行で決めます。 報告書を見て推し量らせると、「1.250.000,00」を1.25と読む誤りが出ます。

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

表は、CELL のブロックの RowIndex と ColumnIndex で組み立てます。 公式のページでは、表は TABLE のブロックとして返り、各セルは CELL のブロックで、表の中の位置の情報を持つとされています。結合されたセルは MERGED_CELL として別に示され、表の種類は STRUCTURED_TABLE か SEMI_STRUCTURED_TABLE で示されます。通貨ごとに小見出しの行が入る報告書は、TABLE_SECTION_TITLE のセルで通貨の区切りを知ります。

結果は MaxResults の1,000ブロックずつ返ります。 NextToken が返る限り呼び続け、全ページ分のブロックをそろえてから表を組み立てます。 途中で組み立てると、ページの境目で銘柄の行が落ちます。

基準日と口座番号は、QUERIES で取ります。 公式のページでは、問い合わせ（クエリ）は英語の文書でだけ使え、非同期の処理では1ページあたり30件までとされています。表の外にある基準日と口座番号を、保存した場所の情報と照らすのに使います。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFは扱えないとされています
2. パスワードの確認 … パスワードで保護されたPDFは扱えません。 カストディアンがパスワード付きで送ってくる場合は、受け取った担当者が解除して保存する手順にします
3. ページをまたぐ表の連結 … 各ページの表の見出しが同じなら1つの表として続け、ページごとに繰り返される見出しの行は落とします
4. 通貨の区切りの付与 … 通貨ごとの小見出しの行から、各銘柄の行に通貨を付けます
5. 数の読み替え … カストディアンごとの設定で、桁区切りと小数点を読み替えます
6. ISIN の確かめ … ISIN は12文字で、最後の1文字が検査用の数字です。検査の計算が合わない ISIN は読み取りの誤りとして人に回します
7. 合計の確かめ … 銘柄の行の評価額を通貨ごとに足し、報告書の合計と比べます

6番目は、読み取りの誤りを照合の前で止めるためのものです。 ISIN の1文字を読み違えると、台帳に無い銘柄が1つ増え、台帳の銘柄が1つ消えたように見えます。検査用の数字の計算で、その多くを照合の前に見つけられます。

AIに処理させる

させるのは、言葉を扱う3つの仕事だけです。 数の読み取りは Textract、数の計算と照合はプログラムが行います。

2行目が、入金の確認の要です。 摘要は「CASH DIV」「INT PMT」「COUPON」「PARTIAL REDEMPTION」「WHT RECLAIM」のように、カストディアンごとに書き方が違います。区分が付けば、配当と利息の入金を、台帳の保有から見込んだ入金と1行ずつ比べられます。

3行目を外すのは、源泉税の率が国と投資家の種類と手続きの有無で変わるからです。 AIに「この配当の源泉税率は正しいか」と聞くと、もっともらしい率を答えます。率は銘柄の情報の列から引き、比べるのはプログラムです。

指示内容を固定する

入金の摘要の区分の指示です。

あなたは銀行の有価証券の事務を担当する部署で、海外のカストディアンから届いた
入金の明細の摘要を種類に分ける担当者を手伝います。渡された摘要の一覧だけを見てください。

【種類】
dividend（配当）／coupon（利息）／redemption（償還）／tax_reclaim（源泉税の還付）／
fee（手数料）／other（その他）

【厳守事項】
- 摘要の言葉だけで判断してください。金額の大きさから推し量らないでください。
- 摘要の原文を、種類と一緒にそのまま raw に残してください。
- 「PARTIAL」「FINAL」「REVERSAL」「CANCEL」などの語が付いていれば、
  種類に加えて、その語をそのまま qualifier に写してください。
- 2つの種類に当たりうる摘要は other とし、note に理由を書いてください。
- 源泉税の率が正しいかを書かないでください。

照会の英文の下書きの指示です。

あなたは銀行の有価証券の事務を担当する部署で、海外のカストディアンへの照会を
英文で下書きする担当者を手伝います。渡された差異の一覧と、根拠の行だけを見てください。

【書き方】
- 銘柄ごとに、ISIN、銘柄名、報告書の数、自社の記録の数、根拠（約定番号・入金の日・報告書のページ）を並べてください。
- 数は渡された値をそのまま書いてください。足したり引いたりしないでください。
- どちらの誤りかを書かないでください。確認をお願いする形にしてください。
- 理由の候補が unknown のものは、事実だけを書き、原因の推測を書かないでください。
- 源泉税の率の違いは、適用された率と、自社が見込んだ率の両方を書き、
  どちらが正しいかは書かないでください。

「REVERSAL」「CANCEL」を写させるのは、入金の取消が同じ明細に並ぶからです。 取消の行を通常の入金として数えると、同じ配当が二度入ったように見えます。 語を写させておけば、プログラムで取消の行を組み合わせて消せます。

照会に「どちらの誤りかを書かない」と入れるのは、カストディアンとの関係のためです。 差異の多くは、自社の約定の登録の遅れやコーポレートアクションの登録漏れから出ます。

出力形式を固定する

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

{
  "account": "USD-BOND-01",
  "statement_date": "2026-09-30",
  "summary_check": "matched | mismatch",
  "positions": [
    { "isin": "US912828XXXX", "security": "",
      "custody_qty": 800000, "ledger_qty": 1000000,
      "variance": { "type": "pending_settlement | corporate_action | unknown",
                    "qty": -200000, "evidence": "Trade T-0927-04 sell 200000, settle 2026-10-01" },
      "min_cell_confidence": 97.8 }
  ],
  "income": [
    { "isin": "", "class": "dividend", "raw": "CASH DIV", "qualifier": "",
      "gross": 0, "tax": 0, "net": 0,
      "applied_tax_rate": 0, "expected_tax_rate": 0, "expected_gross": 0,
      "check": "ok | missing | short | tax_rate_differs" }
  ],
  "needs_human": [ { "isin": "", "reason": "low_confidence | isin_check_failed | no_mapping | summary_mismatch" } ]
}

1つ目の理由は、差異の理由を1列で持てることです。 variance.type が pending_settlement なら翌月の報告書で消えるはずで、翌月に消えなければ、それ自体が確かめる事項になります。 例の銘柄では、9月27日に約定した20万ドルの売却が10月1日の決済で、報告書の基準日の時点では動いていません。

2つ目は、applied_tax_rate と expected_tax_rate を並べられることです。 率が違う行だけを tax_rate_differs として挙げ、還付を請求するかの判断の材料にします。

システムへ連携する

有価証券台帳には書き込みません。 差異の一覧を見て、台帳を直すか、カストディアンに訂正を求めるかを決めるのは担当者です。この構成から台帳を直すと、カストディアンの誤りに自社の台帳を合わせることになります。

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

人が確認する

担当者が全口座の照合の結果を確かめます。 見る順を決めておきます。

1. summary_mismatch の報告書を先に見る … 合計が合わない報告書は照合に進んでいません。多くは表の連結か、通貨の区切りの付け間違いです
2. isin_check_failed と信頼度の低いセルを原本で見る … セルの位置から原本の該当箇所を開きます
3. unknown の差異の根拠を確かめる … 自社の約定の登録漏れや、コーポレートアクションの登録漏れでないかを見ます
4. 入金の不足と源泉税の率の違いを確かめる … tax_rate_differs は、適用の手続きを済ませているかを記録で見ます
5. 照会を直して送る … 下書きの数と根拠を確かめ、送信は担当者が行います

3番目を省かないでください。 差異の原因が自社の登録漏れなのに照会を送ると、カストディアンからの回答を待つあいだ、自社の台帳の誤りが残ります。

pending_settlement で消し込んだ差異も、翌月に確かめます。 翌月の報告書で同じ銘柄の差異が消えていなければ、決済が失敗している可能性があります。

例外に対処する

上から3行目と5行目が、最初の数か月は多く起きます。 3行目は報告書の書式の問題で、カストディアンに合計の行の位置を確かめるだけで減ります。

記録を残す

• 報告書と明細の原本と、保存した場所（口座・対象月・種類・版）
• Textract が返したブロックの全文と、組み立てた表
• カストディアンごとの設定の、その月に使った版
• 照合の結果（positions、income、needs_human）と、消し込みに使った約定とコーポレートアクションの記録
• 担当者が直した箇所 … どのセルの数を、どう直したか
• カストディアンへの照会と回答、差異の解消の記録
• 口座ごとの差異の件数と種類の推移

最後の行は、カストディアンとの定例の材料になります。 同じ種類の差異が続く口座は、決済の連絡かコーポレートアクションの通知の流れに理由があります。