留学生・海外からの出願で届く英文の推薦状を読み取り、推薦者の立場・評価の根拠・具体的なエピソードを審査用の要約票にそろえ、記載の薄いものを示す

処理の起点を決める

起点は2つあります。毎晩の書き出しと、出願の締切の翌日です。

1つ目は、毎晩、出願システムから新しく上がった推薦状のPDFが受付フォルダ（Amazon S3）に書き出されることです。ファイル名に出願番号と推薦者の番号を付けます。保存の通知で AWS Lambda が動き、読み取りから要約票の下書きまでを済ませます。翌朝には、前日に届いた推薦状の要約票がそろっています。

2つ目は、出願の締切の翌日です。締切までに出願した出願者のうち、推薦状が規定の通数に届いていない出願者、要約票の確定が済んでいない推薦状を一覧にし、入試課の担当者に送ります。審査の日程から逆算して、確定の遅れを先に見つけます。

推薦者が推薦状を差し替えた場合も、同じ経路で入れます。 出願番号と推薦者の番号が同じものは、新しい版で要約票を作り直し、古い版の要約票を残します。

入力データを集める

質を決めるのは、要約票の項目と規則の表です。 何を「具体的なエピソード」とするか、何通の推薦状のうち何通が薄ければ追加の資料を求めるか。ここが決まっていないと、AIがそろえた要約票も担当者ごとに違う読み方をされます。

出願の情報から生成AIに渡すのは、出願者の氏名と推薦者として登録された名前だけです。 推薦状が別の出願者のものでないか、登録された推薦者が書いたものかを照らすために使います。成績や他の書類は渡しません。 推薦状の要約が、他の書類の印象で引っ張られないためです。

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

読み取りは StartDocumentAnalysis にS3の場所と FeatureTypes を渡して始めます。完了は NotificationChannel に指定した Amazon SNS のトピックに通知され、状態が SUCCEEDED なら GetDocumentAnalysis で結果を取ります。

質問の答えが見つからなければ空のまま返ります。 空の項目は、生成AIに全文から探させますが、全文にも無ければ空のまま残します。 推薦者との関係が書かれていないこと自体が、記載の薄さの材料になるためです。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。推薦状は1〜3ページですが、同期の処理はPDF1ページまでなので、そろえて非同期で読みます。

レターヘッドと署名は、レイアウトの要素から決めます。 1ページ目の LAYOUT_HEADER に所属の名前があればレターヘッドありとし、最後のページの結びの段落（Sincerely など）の近くに SIGNATURE のブロックがあれば署名ありとします。結びの段落から離れた位置の署名のブロックは数えず、位置で絞ります。 結果は letterhead と signature の有無と信頼度として要約票に載せます。

手書きの行は TextType が HANDWRITING で返ります。 手書きの推薦状は、行ごとの信頼度を見て、低い行が多いものは要約に回さず、担当者が原文で読む一覧に入れます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。推薦者がWordの形式で上げたものは、出願システムの側でPDFにします
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは推薦者に解除したものを頼みます
3. 言語の確認 … 英語以外の推薦状は、英訳が添えられていても原文と訳の対応を人が確かめる必要があるため、要約に回さず担当者の一覧に入れます
4. 出願者の名前の確認 … 本文に出願者の氏名（綴りの揺れを含む）があるかを確かめます。無ければ取り違えを疑います
5. 文の区切り … 読み取った本文を文ごとに番号を付けて分けます。引用の照合をこの番号で行います

AIに処理させる

させるのは、決まった項目ごとに推薦状の要点をまとめ、それぞれに根拠の文の番号と原文を付けることです。 出願者の評価と、薄いかどうかの判断はさせません。

評価と根拠を組で記録させるのは、推薦状の多くが評価だけを並べるためです。 「勤勉で、独創的で、協調性がある」と書かれていても、その根拠となる出来事が書かれているかどうかで、審査の材料としての重さが変わります。

3行目がいちばん起きやすい失敗です。 「彼女は私の授業で最も優れた学生の1人でした」から、「学業成績が優秀」「研究への意欲が高い」と要約し、後者は推薦状のどこにも書かれていません。 引用の照合は、この失敗を見つけるためにあります。

指示内容を固定する

あなたは大学の入試課で、留学生の出願に付いた英文の推薦状を、
審査担当の教員のために整理する担当です。
OCRの読み取り結果だけを使ってください。推測で補わないでください。

【まとめる項目】
recommender（name、title、institution）、
relationship（capacity、duration、context）、
evaluations（評価と、その根拠として書かれた事実の組）、
episodes（いつ、何をして、どうなったかが書かれた出来事）、
comparisons（他の学生との比較の記載）、
concerns（弱みや留保の記載）、
strength_phrases（推薦の強さを表す言い回しを原文のまま）

【厳守事項】
- すべての項目に、根拠にした文の番号（sentence_ids）と、
  その文の原文（quote）を付けてください。原文は一字も変えずに
  写してください。根拠の文が無い項目は書かないでください。
- 推薦状に書かれていない評価や能力を書き足さないでください。
  一般的な褒め言葉を、具体的な能力に言い換えないでください。
- 評価に根拠の事実が書かれていなければ、根拠を空にしてください。
  他の文から根拠を探して当てはめないでください。
- エピソードは、出来事として書かれているものだけにしてください。
  「いつも熱心だった」のような性質の記述はエピソードにしないでください。
- 要約の日本語は、推薦者の言葉の強さを変えずに訳してください。
  強めたり弱めたりしないでください。
- 出願者を評価しないでください。推薦状の強さ、合否の見込み、
  他の出願者との比較を書かないでください。
- 推薦状でない書類と判断した場合は、要約せず document_type に
  種類を書いてください。

【読み取り結果（文ごとに番号付き）】{numbered_sentences}
【出願者の氏名】{applicant_name}
【登録された推薦者】{registered_recommender}

「言葉の強さを変えずに訳す」を明記しないと、強めます。 英文の推薦状の控えめな言い方は、日本語の要約にすると平板になるか、逆に褒め言葉が重なって強くなります。strength_phrases に原文の言い回しを残すのは、教員が原文の強さで読めるようにするためです。

出力形式を固定する

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

{
  "file": "",
  "document_type": "recommendation_letter",
  "application_id": "GA-2026-10-0417",
  "recommender": { "name": "", "title": "", "institution": "", "sentence_ids": [1, 2] },
  "relationship": {
    "capacity": "研究室の指導教員",
    "duration": "2年",
    "context": "卒業研究の指導",
    "sentence_ids": [4],
    "quote": ""
  },
  "evaluations": [
    { "claim_ja": "", "evidence_ja": "", "sentence_ids": [7, 8], "quote": "" }
  ],
  "episodes": [
    { "summary_ja": "", "sentence_ids": [9], "quote": "" }
  ],
  "comparisons": [],
  "concerns": [],
  "strength_phrases": ["without reservation"]
}

1つ目の理由は、引用の照合をプログラムで行えることです。 Python が sentence_ids の文と quote を照らし、一致しない項目は要約票に出さず、quote_mismatch の印を付けます。

2つ目は、記載の薄さを規則で決められることです。

thin_letter は、出願者に不利な印として扱わない決まりにします。 推薦状の書き方は国や分野の慣行で大きく違い、短く形式的な推薦状が普通の地域もあります。 印は「追加の資料を求めるかを検討する」材料で、評価を下げる理由ではありません。

システムへ連携する

出願システムへの書き込みは行いません。 要約票は審査の共有フォルダに置くだけで、出願の状態や合否に関わるデータには触れません。

要約票は、出願者ごとのフォルダに推薦状の原文と並べて置きます。教員が要約票の引用を読んで気になったら、同じフォルダの原文をすぐに開けるようにするためです。 要約票には文の番号とページを載せ、原文のどこを読めばよいかが分かるようにします。

人が確認する

入試課の担当者が開くのは、ok 以外の印が付いた推薦状です。 ok の要約票は、引用と並べて流し見ます。

1. needs_human を先に見る … 出願者の名前が無い、推薦者が登録と違うものは、取り違えか、推薦者の交代かを確かめてから先に進みます
2. quote_mismatch の項目を原文で確かめる … 引用が一致しなかった項目は、原文を読んで直すか削ります
3. thin_letter と relationship_unclear に理由を書き添える … 印の理由をそのまま要約票に載せ、担当者の感想は書きません
4. 要約票を確定して審査に回す … 確定した人の名前を残します

3番目の決まりを崩さないでください。 担当者が「薄い」の理由に自分の読みを書き足すと、第3章の（c）がそのまま戻ってきます。

例外に対処する

上から3行目が、見落とすと取り返しのつかない失敗です。 別の出願者の推薦状で要約票を作ると、教員は違う人の評価を読んで審査します。

記録を残す

• 元の推薦状と、受け取った日時、出願番号、推薦者の番号
• AWS Textract が返したJSONの全文と、文ごとの番号の対応
• Claude API が返したJSON
• 引用の照合の結果と、そのとき使った要約票の項目と薄さの規則の版
• 担当者が要約票を直した記録 … どの項目を、どう変えたか、誰が確定したか
• 推薦者への問い合わせと、差し替えの記録

保存の期間と閲覧できる人を、入試の書類の扱いの決まりに合わせます。 推薦状と要約票は審査の終了後も問い合わせに備えて残しますが、残す期間を過ぎたら、読み取り結果と要約票もあわせて消します。