公立図書館が利用者の手書きの購入リクエストカードを読み取り、書名・著者・出版社を選書の候補一覧に転記して、所蔵済みのものを拾う

処理の起点を決める

各館でスキャンしたカードがフォルダに保存されたことを起点にします。 分館のカードを連絡便で中央館に送るのをやめ、受け付けた館でその日のうちにスキャンします。 紙の移動を待たないので、利用者への連絡が連絡便の分だけ早くなります。

保存先は館ごとに分け、ファイル名にスキャンした日時と館のコードを入れます。 1日分を1つのPDFにまとめる運用でも、後段でカード1枚ずつに分けます。カードの紙は、スキャンしたあとも受付館で一定期間保管します。

処理が終わったファイルは処理済みのフォルダへ移し、移すのは成功したときだけにします。 残っているファイルが、そのまま未処理の数です。

入力データを集める

質を決めるのは、下の2つです。 所蔵の一覧に ISBN が無い古い資料は、書名でしか照らせません。選書の候補一覧を引かないと、先週すでに候補に入れた本が、また新しい行として入ります。

利用者の欄は、この表のうち書誌の処理には使いません。 読み取った利用者番号・氏名・連絡先は、カードの ID と結び付けて別の保管先に置き、予約への切り替えと連絡のときにだけ司書が開きます。

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

読み取りは、Azure Functions からカスタム モデルを呼ぶだけです。モデルはカードの欄ごとにラベルを付けて学習します。 公式ページでは、テンプレート モデルは様式が変わると精度が下がり、様式ごとに最低5枚のサンプルで学習し、複数の様式のモデルを1つのエンドポイントに合成できるとされています。古い様式のカードが残っている館があれば、その版も5枚以上で学習して合成します。

書誌の照会は、OpenSearch に書名と著者を付けて呼びます。 仕様の概要のリクエスト例では、title に書名を、cnt に件数を付け、dpid=iss-ndl-opac で国立国会図書館の蔵書に絞る例が示されています。ISBN が書かれていれば、ISBN から先に引きます。

返ってくる候補には、同じ書名の別の形態が混ざります。 書名で引くと、図書のほかに録音資料や点字資料などが並ぶことがあるので、資料の種別で図書に絞ってから、出版年の新しい順に並べます。 絞り込んでも複数残るものは、そのまま司書に見せます。

API にはまとめて投げません。 利用のページは、同時リクエスト数に制限があり、継続して大量にアクセスすると遮断することがあるとしています。カード1枚ずつ、順番に呼びます。 1日数十枚なら、それで足ります。

AIへ渡す前に整形する

1. 1枚ずつに分ける … まとめてスキャンしたPDFを、カードの外枠で区切ります。A4に4枚並べてスキャンする館があれば、その並べ方を決めておきます
2. 向きを確かめる … 読み取り結果のページの角度を見て、逆さのものは回して読み直します
3. 画像の寸法と文字の大きさを確かめる … 寸法は50×50から10,000×10,000ピクセルの間、文字の最小の高さは1024×768の画像で12ピクセルです。小さなカードの細い字のために300dpiでスキャンします
4. 書名の表記をそろえる … 全角と半角、長音、括弧の中の補足（「黄色い表紙」など）を分けて持ちます
5. ISBN の形を確かめる … 書かれていれば、桁数とチェックの数字を確かめます。合わないものは書かれたまま残し、引かない
6. 二重のスキャンを見つける … 同じ受付館・受付日・利用者番号・書名のカードは、二重に処理しません
7. 利用者の欄を切り離す … 書誌の処理に回すデータから、利用者番号・氏名・連絡先を外します

4番目で括弧の中を分けるのは、検索を当てるためです。 「料理の本（黄色い表紙）」を丸ごと書名として引くと何も当たりません。補足は検索語に入れず、司書が候補を選ぶときの手がかりとして一覧に残します。

7番目を最初の段で行うのは、後の段に利用者の情報を流さないためです。 生成AIに渡すデータにも、書誌の照会に送るデータにも、利用者の欄が入る経路を作りません。

AIに処理させる

OCRにさせるのは、カードに書かれた文字をそのまま値にすることです。 生成AIにさせるのは、書かれた書名・著者・出版社から、書誌の検索に投げる検索語の組み合わせを作ることだけです。

4行目の区別が、所蔵済みの見落としを防ぐ要です。 ISBN で当たったものは同じ本ですが、書名だけで当たったものは、版や文庫化で別の本のことがあります。 所蔵の可能性 として司書に見せ、同じ本かを決めてもらいます。

2行目と3行目は、選書の公平さのためです。 理由を要約させると、生成AIの言い回しで希望の強さが変わって見えます。理由は書かれたまま一覧に置きます。

指示内容を固定する

あなたは公立図書館の資料係で、利用者が手で書いた購入リクエストカードの
書誌の欄から、書誌のデータベースで本を探すための検索語を作る担当です。
OCRが返した書名・著者・出版社・出版年の文字だけを見てください。

【やること】
1. 書誌の検索に投げる検索語の組み合わせを、可能性の高い順に最大3つ作る
   各組み合わせは title（書名の語）、creator（著者の語）、publisher（出版社の語）からなる
2. 書名の欄のうち、書名そのものでない補足（表紙の色、紹介された番組など）を
   notes に分けて書く
3. 書かれた文字に読み違いの可能性がある箇所を、ocr_doubt に書く

【厳守事項】
- 書かれていない書名、著者、出版社を作らないでください。
  「〇〇の新しい料理の本」から、具体的な書名を作らないでください。
  書名の語は、カードに書かれた語の中から選んでください。
- 略記の展開は、カードに書かれた語が明らかに略記であるときだけにし、
  展開した場合は expanded に true を付けてください。
- 本が実在するかどうか、図書館が持っているかどうかを書かないでください。
- 購入すべきかどうか、どんな本かの説明を書かないでください。
- ISBN を書かないでください。書かれていた ISBN は別に扱います。
- 読めない字は「〓」のまま残し、前後から補わないでください。
- 書名の欄が空なら、queries を空にして title_missing を true にしてください。

【書名の欄（OCRの結果のまま）】{title_text}
【著者の欄】{creator_text}
【出版社の欄】{publisher_text}
【出版年の欄】{year_text}

「書名の語はカードに書かれた語の中から選ぶ」が、この指示の芯です。 何も言わなければ、生成AIは知っている本の書名を補ってきます。補った書名で検索が当たると、利用者が希望していない本が候補に入ります。 検索語を作らせても、語の出どころはカードに限ります。

「実在するか、持っているかを書かない」も同じ理由です。 それを確かめるのは書誌の検索と所蔵の照合で、生成AIの記憶ではありません。

出力形式を固定する

カードごとに、次の形のJSONにまとめます。 生成AIが返すのは queries と notes と ocr_doubt の部分だけで、構造化出力でスキーマを固定します。公式ページでは、構造化出力はJSONスキーマへの準拠を保証し、Chat Completions では response_format に、Responses では text.format にスキーマを置き、strict を true にするとされています。

{
  "card_id": "",
  "branch": "",
  "received_on": "",
  "written": { "title": "", "creator": "", "publisher": "", "year": "",
               "isbn": "", "reason": "", "confidence_min": 0 },
  "notes": "",
  "ocr_doubt": [],
  "queries": [ { "title": "", "creator": "", "publisher": "", "expanded": false } ],
  "candidates": [
    { "isbn": "", "title": "", "creator": "", "publisher": "", "year": "",
      "holding": "所蔵済み | 発注中 | 所蔵の可能性 | 未所蔵",
      "matched_by": "isbn | title" }
  ],
  "status": "所蔵済み | 発注中 | 未所蔵 | 特定できず | 判読要確認",
  "same_book_cards": []
}

1つ目の理由は、written と candidates を別の層に置けることです。 written はカードに書かれた文字のまま、candidates は書誌の検索と所蔵の照合の結果です。司書が候補を選び直しても、書かれた文字は変わりません。

2つ目は、matched_by で照合の確からしさが分かることです。 isbn で当たったものと title で当たったものを、一覧で色を分けて見せます。

3つ目は、same_book_cards で同じ本の希望をまとめられることです。 選書会議には、1冊の本について何館から何件の希望があったかを1行で出せます。

システムへ連携する

図書館システムへは書き込みません。 予約への切り替えは、司書が図書館システムの画面で行います。読み取りの結果から予約を自動で作ると、取り違えた本の予約が利用者の名前で入ります。

国立国会図書館サーチの API を使う画面や一覧には、利用のページが求めるとおり、API を用いていることを明記します。 職員だけが見る一覧でも、出どころが分かるように列の見出しに書いておきます。

人が確認する

司書が詳しく見るのは 特定できず と 判読要確認、それに 所蔵の可能性 を含むカードです。 所蔵済み と 発注中 と、候補が1件の 未所蔵 は、一覧で書かれた書名と候補の書名を並べて流し見ます。

1. 所蔵の可能性 を先に見る … 書名だけで当たった所蔵が、同じ本か別の版かを決めます。所蔵済みの見落としは、ここで止めます
2. 特定できず の候補を選ぶ … 複数の候補から選ぶか、蔵書検索で引き直します。分からなければ利用者に問い合わせます
3. 判読要確認 をカードの画像で見る … 書かれた文字を直してから、もう一度書誌を引きます
4. 区分を確定する … 所蔵済み・発注中は予約へ、未所蔵は選書の候補一覧へ
5. 直したら記録する … どの候補を選んだか、区分をどう直したかを残します

1番目を省かないでください。 書名だけで当たった本を未所蔵として流すと、第3章の（b）がそのまま残ります。

目標は、900件をならして1件1.2分です。 詳しく見るのは2割前後の想定で、それより多い月は、スキャンの解像度か、カードの書名の欄の書き方の案内を見直す合図です。

例外に対処する

上の2行は、AIの問題ではありません。 書名の無いカードと、まだ書誌が出ていない本は、どの構成でも人が調べることになります。それを 特定できず として最初から分けておくことが、確認を速くします。

記録を残す

• カードの画像と、受付館・受付日・スキャンした日時
• Document Intelligence が返した結果の全文と信頼度
• 生成AIに渡した書誌の欄と、返ってきた検索語
• 書誌の API に投げた検索語と、返ってきた候補
• そのとき照らした所蔵の一覧の日付
• 司書が選んだ候補と、区分を直した記録
• 利用者の欄（書誌の処理のログとは別の保管先に置き、保管の期限を決める）

5つ目で所蔵の一覧の日付を残すのは、照合の結果が日によって変わるためです。 前日に受け入れた本は、当日の一覧にしか載りません。いつの一覧と照らしたかが無いと、所蔵済みの見落としがどこで起きたかを追えません。

最後の行は、保管の期限を先に決めます。 予約と連絡が済んだあとの利用者の欄は、自館の個人情報の取り扱いの規程に沿って消します。