海外拠点が結ぶ英文の事務所・倉庫の賃貸借契約書を読み取り、賃料・改定条項・更新と解約通知の期限をリース台帳に起こして、期限の前に知らせる

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 契約の締結や変更は拠点ごとに不定期に起きるため、1日1回の定時実行にはしません。

入る経路は、拠点の総務が署名済みの契約書をスキャンしたPDFと、家主や仲介会社から電子で届いたPDFの2つです。どちらも同じフォルダに入れ、ファイル名の先頭に拠点コードと契約番号を付けるところまでを人が行います。 契約番号の無いファイルは処理の前に止めます。

S3 への保存を AWS Lambda が受け、StartDocumentAnalysis を呼びます。ClientRequestToken に契約番号とファイルのハッシュから作った値を入れると、同じファイルを二度入れても同じ JobId が返り、二重に読みません。 完了は Amazon SNS に届き、SUCCEEDED を確かめてから結果を取り、すぐ S3 に保存します（JobId は7日間だけ有効です）。期限の通知は別の処理として、毎朝、確定した台帳を見て動かします。

入力データを集める

質を決めるのは、これまでの版と休日の一覧です。 版が無ければ変更契約を重ねられず、休日の一覧が無ければ「20 Business Days」の期限を数えられません。

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

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

質問は QueriesConfig に別名（Alias）を付けて並べます（非同期で1ページ30問まで）。公式の手引きは、文書の言葉で聞くこと、日付が複数ある文書では何の日付かを特定して聞くことを勧めています。例えば EXPIRY に「What is the expiry date of the term?」、RENT_COMM に「What is the rent commencement date?」です。

質問は既定で1ページ目しか見ません。 ページの指定が無いと ["1"] になるため、**Pages に ["*"] を入れて全ページを対象にします。 条項の文章は質問で取りません。手引きは100語未満の答えになる質問を勧めており、数文にわたる更新や解約の条項は途中で切れます。** 段落で区切った原文を生成AIに渡します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFは扱えないため、印刷し直してPDFにします
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。保護されたものは拠点に解除したものを頼みます
3. ページ数とサイズの確認 … 非同期の処理でPDFとTIFFは500MB・3,000ページが上限です
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です。脚注の細かい文字が多いので、300 DPIでスキャンします
5. 言語の確認 … 英語以外の文が含まれていれば質問を外します。現地語だけの契約は別の経路へ回します
6. 章の切り分け … LAYOUT の見出しで章に分け、「Definitions」「Term」「Rent」「Rent Review」「Option to Renew」「Break」「Notices」などの見出しに当たる章を選びます
7. 定義の抜き出し … 「Definitions」の章から、期限の計算に関わる言葉（「Expiry Date」「Business Day」「Term Commencement Date」）の定義を先に取り出し、各章と一緒に渡します
8. 版の確認 … 同じ契約番号・同じ版の結果が既にあれば止めます。変更契約なら、元の契約の確定済みの版があることを確かめます

7番目を省かないでください。 「six months prior to the Expiry Date」の期限は、Expiry Date の定義が分からなければ計算できません。

AIに処理させる

させるのは、7つの区分の条項を原文のまま切り出し、値を所定の形にそろえ、根拠の文字列を添えることだけです。

期限は「書き方」を写させ、日付にはさせません。 「not less than six months prior to the Expiry Date」を、offset（6）、unit（month）、anchor（Expiry Date）、direction（before）の組にそろえます。日付を出すのはプログラムです。

2行目がいちばん起きやすい失敗です。 「indexed to CPI」とだけある条項を渡すと、AIはもっともらしい上昇率で翌年の賃料を書き、根拠の無い金額が台帳に入ります。 改定の方法と時期だけを写させ、金額は空けておきます。

指示内容を固定する

あなたは経理部でグループのリース台帳を管理する担当として、
海外の拠点が結んだ英文の賃貸借契約書または変更契約を読み、
台帳に登録するための項目を取り出します。
渡された読み取り結果と定義の章だけを見てください。推測で埋めないでください。

【取り出す項目】
1. 当事者と物件（家主、借主、住所、面積、用途）
2. 期間と開始日（契約開始日、賃料の発生日、満了日、フリーレント）
3. 賃料と支払（通貨、金額、年額か月額か、頻度、時期）
4. 賃料の改定（時期、方法、上限と下限、指数の名前）
5. 更新の選択権（回数、更新後の期間、行使の期限、条件）
6. 中途解約の選択権（行使できる日、通知の期限、違約金）
7. 通知の方法（書面の要否、送り先、届いたとみなす時点）

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- not_found .. その項目が書かれていない
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- original には、契約書の英文をそのまま写してください。
  言い換え、要約、綴りの修正をしないでください。
- 日本語の説明は note_ja にだけ書いてください。
- 日付の足し引きをしないでください。期限は offset・unit・anchor・direction の
  組で表し、日付を計算して書かないでください。
- anchor には、定義の章に書かれている言葉をそのまま使ってください。
  定義の章に無い言葉なら、anchor_defined を false にしてください。
- 改定後の賃料を計算しないでください。指数の値や上昇率を補わないでください。
- 書かれていない条件を補わないでください。「通常は」「一般に」で埋めないでください。
- 更新や解約の選択権が書かれていなければ not_found とし、
  一般的な賃貸借の慣行から作らないでください。
- これが変更契約であれば、変更された項目だけを返し、
  どの条項を変えたと書かれているかを amends に写してください。
- 選択権を行使すべきか、会計上どう扱うべきかは書かないでください。
- 英語以外の文があれば language_note に書いてください。

【定義の章】{definitions}
【章ごとに区切った原文】{sections}
【表と質問への答え】{tables_and_queries}
【文書の区分】{job_tag}

「日付の足し引きをしない」は、書かないと必ず破られます。 AIは親切に「2027年3月31日」と答え、満了日を変更契約で延ばしたときに、古い期限が台帳に残ります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に json_schema）で形を守らせます。

{
  "contract_no": "",
  "document_kind": "original | renewal | amendment",
  "version": 0,
  "amends": [""],
  "fields": [
    { "item": "expiry_date", "status": "ok | not_found | unreadable | ambiguous",
      "value": "", "original": "", "page": 0, "confidence": 0, "note_ja": "" }
  ],
  "rent_review": {
    "method": "fixed | index | market | not_found",
    "schedule_original": "", "index_name": "", "cap_floor_original": ""
  },
  "deadlines": [
    { "kind": "renewal_notice | break_notice | rent_review",
      "offset": 0, "unit": "day | business_day | month",
      "anchor": "", "anchor_defined": true,
      "direction": "before | after", "original": "" }
  ],
  "notice_method_original": "",
  "language_note": ""
}

fields には、第7章の「AIに何をさせるのか」の表の項目を1行ずつ並べます。confidence は、その値を拾った行の Textract の信頼度をプログラムが後から書き入れます。

1つ目の理由は、期限を日付ではなく組で受け取れることです。 deadlines の組からプログラムが日付を出すので、満了日が変われば計算し直すだけで済みます。 business_day のときは、拠点の国の休日の一覧を使って数えます。

2つ目は、原文を照合できることです。 プログラムが page のページにその original の文字列があるかを確かめ、見つからなければ needs_human にします。

システムへ連携する

リース台帳へは、人が確定したものだけを書き込みます。 登録案は別のシートに出し、経理が確かめた行だけを本番の台帳へ移します。誤った満了日が台帳に入ると、通知の日付まで連れてずれます。 会計システムへは書き込みません。

人が確認する

人が開くのは、needs_human の印が付いた契約と、期限の計算の根拠だけです。 ok のものは、満了日・賃料・期限の3列を一覧で流し見ます。全文を開く設計にすると、第10章の15.0時間には収まりません。

1. 期限が近いものを先に見る … 通知期限が120日以内の契約は、確定の前に拠点へ知らせます
2. 期限の根拠を確かめる … original の原文と、計算された日付を並べて見ます。「prior to」が送った日か届いた日かは、Notices の章で確かめます
3. 変更契約の重ね方を確かめる … amends の原文と、置き換えられた項目が合っているかを見ます
4. 拠点に聞く … 開始日と賃料の発生日がずれている、通知先が家主の旧住所のままである、といった点を拠点に確かめます
5. 判定を覆したら記録する … どの項目を、どの値に変えたかを残します

2番目を省かないでください。 期限の計算が1日ずれただけで、選択権を失うか、家主に交渉の材料を渡すことになります。 台帳に載った期限は、その後は誰も疑わずに使われます。

例外に対処する

4行目が、この構成でいちばん大事な止め方です。 anchor が定義されていない期限を「たぶん満了日のことだろう」と計算すると、それらしい日付が台帳に入り、誰も疑わなくなります。 計算しないで止めるほうが安全です。

記録を残す

• 元のPDFと、受け取った日時・拠点・区分（新規・更新・変更）
• Textract が返したJSONの全文と、JobId・状態・警告
• 生成AIの出力（fields、deadlines、amends）と、原文の照合の結果
• 計算した期限と、その計算に使った満了日・休日の一覧の版
• 人が確定した台帳の行と、判定を覆した記録
• 期限の通知を送った日時と、拠点の責任者の返答

4つ目で「計算に使った満了日と休日の版」を残すのは、後で期限が争いになったときのためです。 家主から「通知が遅い」と言われたとき、なぜその日を期限としたのかを、当時の材料で説明できます。