ゴルフ場のコンペで回収する手書きのスコアカードを読み取り、ホールごとの打数を集計表に転記して、合計の計算違いを拾い、順位表の下書きを作る

処理の起点を決める

コンペ番号のフォルダにファイルが保存されたことを起点にします。 コンペ番号は予約の時点で決まっており、組み合わせ表と集計表もこの番号で作られています。カードの中身からコンペを推定させることはしません。 同じ日に複数のコンペがあると、取り違えます。

スクリプトは1分おきにフォルダを見て、新しいファイルを1枚ずつ流します。上がった組から順にスキャンする運用と組み合わせて、最終組の前に大半を終わらせます。

処理が終わったファイルは処理済みのフォルダへ移します。移すのは成功したときだけです。 コンペのフォルダに残っている数と、組み合わせ表の組数の差が、まだスキャンしていない組の数になります。表彰式の前に、この差が0になったかを見ます。

入力データを集める

質を決めるのは、カードの書式の対応表です。 「表の2行目の3列目は、1人目の3番ホール」という対応が決まっていれば、読み取った数字を人×ホールに並べ直すのは機械的な作業になります。 パット数の欄がある書式は、打数の行とパット数の行を分けて対応づけます。

組の番号は、カードに印刷しておきます。 組み合わせ表から、組の番号とプレーヤーの名前をカードに印刷して配る運用にすると、名前の照合がほとんど要らなくなります。 当日の入れ替えで手書きになった名前だけが、照合の対象に残ります。

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

読み取りは、スクリプトから Form Parser のプロセッサを呼ぶだけです。画像を送ると、document の形で結果が返ります。

セルの文字は、セルの中に直接入っていません。 textAnchor.textSegments が文書全体の文字列 document.text の範囲を指しているので、スクリプトで切り出して数字に直します。 1つのセルの値が複数の区間に分かれることがあるので、順につなぎます。

1枚のカードは1ページで、同期の処理（15ページまで）で十分に収まります。 組ごとに1枚ずつ送るので、ページ数の上限を気にする必要はありません。

AIへ渡す前に整形する

1. 形式の確認 … PDF、JPEG、PNG、TIFF などであることを確かめます
2. 解像度の確認 … 公式のページでは、スキャンは最低200dpi、300dpi以上で最もよい結果になるとされています。手書きの小さな数字を読むので、300dpiにそろえます
3. 向きの確認 … カードは横長で、裏返しや上下逆でスキャンされることがあります。印刷された見出しの位置で向きを確かめ、直します
4. 書式の確認 … 印刷された見出しの文字で、どの書式のカードかを確かめ、対応表を選びます
5. 組の番号の確認 … 印刷された組の番号を読み、組み合わせ表にあるかを確かめます。同じ組のカードが2枚あれば、後のものを差し替えとして扱います
6. カードの裏の除外 … ローカルルールなどが印刷された裏面のページは、読み取りに回しません

3番目は、地味ですが効きます。 回収したカードの向きはそろっていません。上下逆のまま読むと、表の行と列の対応がすべてずれます。 複合機に向きをそろえる設定があれば、それも使います。

AIに処理させる

OCRの後は、ほとんどがスクリプトの仕事です。 打数を人×ホールに並べ、ホールの合計を計算し、記入された合計と比べるのは、規則で書けます。

3行目は、紙のスコアカードならではの落とし穴です。 プレーヤーによっては、打数ではなくパーに対する差（「0」「+1」「−1」）を書きます。そのまま集計すると、その人だけ極端に少ない打数になり、優勝してしまいます。

パット数の欄がある書式では、打数とパット数の行の取り違えも見ます。 同じ人の2行のうち、打数の行の値がパット数の行の値より小さいホールがあれば、行を取り違えて書いたか、読み取りの行がずれた疑いがあります。どちらの行が打数かは、書式の対応表で決まっているので、規則で見分けられます。 パット数そのものは順位に使わないコンペが多く、集計表には打数だけを書き込みます。

生成AIにさせるのは、名前の対応の候補を出すことだけです。 手書きの名前が組み合わせ表と一致しないときに、同じ組の4人の名前と見比べて、どれに当たるかの候補を返させます。

指示内容を固定する

あなたはゴルフ場のコンペ担当で、スコアカードに手書きされた
プレーヤーの名前を、組み合わせ表の名前と対応づける補助をします。
以下の情報だけを使い、推測で補わないでください。

【やること】
カードの各欄に書かれた名前が、同じ組の組み合わせ表の4人のうち
誰に当たるかの候補を答えてください。

【厳守事項】
- 候補は、下に示した同じ組の名前の中からだけ選んでください。
  それ以外の名前を作らないでください。
- 名字だけ、名前だけ、愛称、ひらがな書きなどで一致が確定できない場合は、
  confidence を low にし、理由を reason に短く書いてください。
- 同じ名字の人が組に2人以上いて区別できない場合は、
  match を null にしてください。
- 2つの欄が同じ人に当たるという答えはしないでください。
  その場合は両方を match null にしてください。
- 打数、合計、順位については何も答えないでください。
- written には、カードに書かれた文字列をそのまま写してください。

【組の番号】{group_no}
【組み合わせ表の4人】{pairing_names}
【カードの名前の欄（欄の番号と読み取った文字列、信頼度）】
{written_names}

「同じ組の名前の中からだけ選ぶ」を最初に書くのは、候補を広げさせないためです。 コンペの参加者全員の名簿を渡すと、別の組の似た名前を選ぶことがあります。組の番号で範囲を4人に絞れば、照合はほぼ取り違えようがありません。

打数について答えさせない一文も入れておきます。 名前の欄と一緒に表の内容が見えると、生成AIは合計の誤りを指摘したり、直した値を書いたりしようとします。打数はこの指示の外で扱います。

出力形式を固定する

名前の対応は、構造化出力（JSON スキーマ）で受け取ります。 Claude API では output_config.format に json_schema の形でスキーマを渡します。オブジェクトには additionalProperties: false が必要です。

{
  "group_no": "",
  "names": [
    { "slot": 1, "written": "", "match": "", "confidence": "high | low",
      "reason": "" }
  ]
}

打数の側は、スクリプトが次の形にそろえ、集計表に書き込む元にします。

{
  "competition_no": "",
  "group_no": "",
  "players": [
    {
      "slot": 1,
      "player": "",
      "holes": [ { "hole": 1, "strokes": 5, "confidence": 0.0,
                   "status": "ok | unreadable | suspect" } ],
      "out_written": 0, "out_sum": 0,
      "in_written": 0, "in_sum": 0,
      "total_written": 0, "total_sum": 0,
      "check": "ok | mismatch | relative_suspect | needs_review"
    }
  ]
}

1つ目の理由は、ホールの打数と記入された合計を両方残せることです。 out_sum は読み取った打数から計算した値、out_written はプレーヤーが書いた値です。両方が残っていれば、どちらが誤っているかを紙で確かめるときに迷いません。

2つ目は、check の値をスクリプトの規則で決められることです。

2行目と4行目の区別が、この構成でいちばん大事なところです。 mismatch は、読み取りに不安が無いのに合わないもので、プレーヤーの計算違いの可能性が高く、幹事に伝える候補です。 needs_review は読み取りに不安があるもので、紙を見ればフロントで解決します。 不安のあるセルがあるうちは mismatch にしない、という順番を規則で守ります。

システムへ連携する

集計表に書き込むのは、打数だけです。 ハンディキャップの方式と順位の式には触れません。ok 以外のカードの打数も書き込みますが、行に印を付け、確認が済むまで順位表を印刷しないようにします。

幹事へは、この構成から何も送りません。 mismatch のカードを幹事に伝えるかどうかは、紙を見たコンペ担当が決めます。

人が確認する

1. needs_review のカードを先に見る … 信頼度の低いセルを紙と見比べ、集計表の値を直します。多くは「1」と「7」のような字の癖です
2. relative_suspect のカードを確かめる … パーに対する差で書かれていれば、打数に直して入力します
3. mismatch のカードを確かめる … 紙のホールの打数を足し直し、読み取りが正しくプレーヤーの合計が違うと分かったものだけを幹事に伝えます
4. 名前の対応の low と null を確かめる … 組の4人に聞くか、幹事に確かめます
5. 順位表を印刷する前に、上位の数人のカードを紙と見比べる … 表彰に関わる行は、ok でも念のため確かめます

5番目は、時間を減らす目的に逆らって見えるかもしれません。 しかし、上位の数人の打数の誤りは、表彰の順番そのものを変えます。ここだけは全部の数字を紙で確かめても、数分で終わります。

目標は、300枚をならして1枚2分です。 ok のカードは集計表の行を流し見て数十秒、needs_review と mismatch のカードは紙と見比べて数分かかります。

例外に対処する

最後の行は、運用の取り決めとして先に書いておきます。 表彰式は待ってくれません。読み取りが止まった日に手で打ち込めるよう、集計表は今の形のまま使える状態で残します。

記録を残す

• 元のスキャンの画像と、保存した日時、コンペ番号、組の番号
• OCRが返した JSON の全文（tables、formFields、document.text、信頼度）
• スクリプトがそろえた打数と check の結果、そのとき使った書式の対応表の版
• 名前の対応の出力と、担当者が決めた対応
• 担当者が直したセルと、直す前の値
• 幹事に伝えた mismatch と、幹事の判断

5つ目の「直したセル」が、書式の改善の材料になります。 同じホールの欄で読み違いが多いなら、欄が狭いか、印刷の線が数字に重なっています。読み違えやすい字の組み合わせが分かれば、確認のときにどこを見ればよいかも分かります。

画像と結果の保存期間は、コンペの集計表と同じ扱いにします。 幹事から後日問い合わせがあったときに、元のカードと読み取りの結果を見比べられる期間を決めておきます。