公立図書館のレファレンスの質問に、所蔵の検索結果と過去のレファレンス記録から調べ方と資料の候補を返すチャットを作り、司書の確認に回す

処理の起点を決める

利用者がチャットを開いて質問を書いたときに始まります。 チャットの最初の画面で、AIが応答していること、聞き取った内容は司書が確かめてから回答すること、氏名や連絡先をチャットに書かないことを表示します。

Microsoft の AI サービスの行動規範では、出力が AI によるものであることを、利用者が人とやり取りしていると誤解しないよう開示することが求められています。図書館のチャットでは、最初の表示と、案内の文の中の両方で示します。

回答の連絡先は、チャットの外で受けます。 質問票がそろったところで、回答の受け取り方（メール・来館して受け取る）を選んでもらい、メールアドレスは受付の一覧の側に入れて、AIとのやり取りには入れません。

開館時間外もチャットは動きますが、司書の確認は開館日に行います。 回答の目安は「何開館日以内」で伝えます。

入力データを集める

質を決めるのは、自館の過去の記録の整え方です。 (b)のように書き方がばらばらなままだと、検索しても似た記録が上に来ません。質問の要旨・調べ方・使った資料を分けた形に書き直し、利用者が分かる情報を消してから索引に入れます。

館で作った調べ方の手引きも入れます。 「古い地図の探し方」「新聞記事の探し方」のような手引きは、過去の記録よりも整理されていて、経験の浅い司書でも同じ調べ方を案内できる根拠になります。

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

チャットで質問票がそろったら、Azure Functions が3か所を検索します。生成AIの関数呼び出しで、どの検索をどの言葉で呼ぶかを決めさせ、実行は Azure Functions が行います。

関数呼び出しには構造化出力を使います。 公式の説明では、関数の定義に strict: true を指定して構造化出力を有効にでき、構造化出力では並列の関数呼び出しがサポートされないため parallel_tool_calls を false にするとされています。3か所の検索は、1つずつ順に呼ばせます。

レファレンス協同データベースの API 2.0 は、CQL 形式のクエリで質問・回答・解決の状況などを指定できるとされ、既定では1件目から200件目までを返すとされています。 渡すのは上位の数件だけにします。継続的に使う場合は事務局に連絡先と利用内容を知らせるよう求められているので、運用を始める前に連絡します。

検索の言葉は、質問票の項目から作ります。 時代と地域を別の項目で持っているので、「明治」「大正」のような時代の言葉と、町名・旧村名のような地域の言葉を組み合わせて引けます。

生成AIに渡す関数の定義は、次のように3つに分けます（説明は要点だけ）。

[
  { "type": "function", "function": {
      "name": "search_holdings", "strict": true,
      "description": "所蔵の書誌を検索する。書名・件名・時代・地域の語を受け取る",
      "parameters": { "type": "object", "additionalProperties": false,
        "required": ["keywords", "period", "area"],
        "properties": { "keywords": { "type": "string" },
          "period": { "type": "string" }, "area": { "type": "string" } } } } },
  { "type": "function", "function": {
      "name": "search_past_records", "strict": true,
      "description": "自館の過去のレファレンス記録と手引きを検索する",
      "parameters": { "type": "object", "additionalProperties": false,
        "required": ["query"], "properties": { "query": { "type": "string" } } } } },
  { "type": "function", "function": {
      "name": "search_crd", "strict": true,
      "description": "レファレンス協同データベースの公開事例を検索する",
      "parameters": { "type": "object", "additionalProperties": false,
        "required": ["question_terms"], "properties": { "question_terms": { "type": "string" } } } } }
]

関数の引数を、利用者の書いた文そのものにしないのが要点です。 質問票の項目から作った語だけを渡すので、伏せ損ねた個人情報が検索の窓口や外部の API に流れる経路を狭められます。

AIへ渡す前に整形する

1. 氏名・連絡先を外す … チャットに氏名・電話番号・メールアドレス・利用者の番号らしい並びが書かれたら、［個人情報］ に置き換えてからAIに渡します
2. 過去の記録の書き直し … 自館の記録から、利用者の氏名・学校名・勤め先など人が分かる情報を消し、質問の要旨・調べ方・使った資料に分けます
3. 書誌の正規化 … 所蔵の書誌の書名・著者名の表記をそろえ、資料の番号を必ず持たせます
4. 協同データベースの事例の整形 … 質問・回答・参考資料・提供館名を分け、提供館名を落とさないようにします
5. 質問の長さの確認 … 極端に長い書き込みや、レファレンスでない書き込み（苦情・貸出の延長の依頼）を見分けて、別の窓口へ案内します

1番目は、利用者が書いてしまう前提で作ります。 最初の表示で書かないよう伝えても、「○○小学校の5年生です」「電話番号は」と書く人はいます。書かれたものをAIに渡さないのが、この前処理の役目です。

2番目は、索引を作る前に一度だけ大きな作業になります。 ここを省いて記録をそのまま入れると、ほかの利用者の質問の中身が、別の利用者への案に混ざる経路ができます。

AIに処理させる

させるのは2つです。 1つ目は聞き取りの対話、2つ目は検索結果からの案の作成です。

4行目は、図書館の考え方に関わります。 用途を聞くのは、統計の数字が欲しいのか、背景を知りたいのかで案内する資料が変わるからです。利用者が答えたくないときは、聞かずに進めるよう指示します。

指示内容を固定する

聞き取りの段の指示です。

あなたは市立図書館のレファレンス係の聞き取りを手伝うAIです。
利用者には、AIが応答していることと、回答は司書が確かめてから送ることを伝えてあります。

【聞き取る項目】
- 知りたいこと（何について）
- 時代・時期
- 地域・場所
- 用途（例：調べ学習、仕事、家の手続き、趣味）
- すでに調べたこと・見た資料

【聞き方】
- 1回に1つだけ聞いてください。
- 利用者が答えたくない様子なら、その項目は聞かずに進めてください。
- 用途を聞くのは、案内する資料を選ぶためだと伝えてください。
- 氏名、学校名、勤め先、電話番号、メールアドレスを聞かないでください。
  書かれても繰り返さないでください。
- 質問の答え（年号、地名、数値、出来事の内容）を書かないでください。
  知っていても書かないでください。
- 法律、医療、税の個別の相談は、資料の案内はできるが
  個別の判断はできないと伝え、専門の窓口があることを伝えてください。
- 3往復でそろわなければ、そろった分で質問票をまとめてください。
- 最後に質問票を見せ、合っているかを確かめてください。

案の作成の段では、さらに次を加えます。

- 【検索結果】に資料の番号がある資料だけを候補に書いてください。
- 資料ごとに、その資料で何が分かりそうかを、書誌と記録の範囲で書いてください。
- 協同データベースの事例を使うときは、提供館名を必ず書いてください。
- 調べ方は手順の形で書き、どの資料のどこを見るかを示してください。
- 根拠になる資料が無ければ、status を no_source にしてください。

「知っていても書かない」を明記しないと、モデルは答えを書きます。 郷土の歴史のような質問ほど、それらしい年号や地名を知っているように書くからです。レファレンスの回答で誤った事実を示すと、利用者はそれを図書館の答えとして使います。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "inquiry_id": "",
  "question_sheet": {
    "topic": "", "period": "", "area": "", "purpose": "", "already_checked": ""
  },
  "status": "drafted | no_source | out_of_scope",
  "steps": [
    { "order": 1, "how_to": "", "item_ids": [] }
  ],
  "holdings": [
    { "item_id": "", "title": "", "call_number": "", "location": "", "what_to_look_for": "" }
  ],
  "external_cases": [
    { "crd_id": "", "provider_library": "", "hint": "" }
  ],
  "referral": ""
}

1つ目の理由は、資料の照合を規則で書けることです。 holdings の item_id を所蔵の検索結果と照らし、検索結果に無い番号の資料は案から外して印を付けます。 存在しない本を案内する誤りを、出力の側で止めます。

2つ目は、external_cases に提供館名を必須で持てることです。 構造化出力では、すべてのフィールドを必須にし、オブジェクトに additionalProperties: false を設定する必要があるとされています。提供館名の欄を必須にしておくと、書き漏れが起きにくくなります。 空で返ってきた事例は使いません。

システムへ連携する

チャットの会話の履歴は、自前で持ちます。 公式の説明では、Responses API はメッセージ履歴を保存し、保存されたデータはリソースと同じ地域に置かれ、いつでも削除できるとされています。利用事実を扱うので、どこに何日残すかを館で決められる形を選びます。 自前で持つなら、質問票ができたところで会話を伏せた形に置き換えます。

人が確認する

全件を司書が確かめます。 チャットが作るのは案までで、利用者への回答は司書が書きます。

1. 質問票を読む … 利用者が確かめた質問票と、AIの案の質問の取り方がずれていないかを見ます
2. 資料を書架で確かめる … 案に出た資料を実際に開き、その資料で本当に分かるかを見ます
3. 案に足す … 郷土資料、新聞、雑誌の記事など、検索で拾えなかった資料を足します
4. 答えが書かれていないかを見る … 年号や地名を断定している文があれば、資料の案内に書き直します
5. 回答する … 司書の名前で回答を送り、記録に残します

2番目を省かないでください。 書誌からは中身が分からない資料は多く、題名が合っていても、知りたいことが載っていないことがあります。

目標は、1件8分です。 聞き返しと3か所の検索が済んだ状態で受け取るので、司書の時間は書架で資料を確かめることと、足すことに使えます。

経験の浅い司書には、過去の記録の調べ方を手本として見せます。 確認画面で、案の根拠になった自館の記録と手引きを並べて表示すると、ベテランが前に使った調べ方を、そのまま追いかけられます。 (c)の回答の厚みの差を縮めるのは、AIの案よりも、この並べた表示のほうかもしれません。

例外に対処する

3行目は、図書館に毎日来る型の質問です。 「この病気の治療法」「この契約は無効か」という質問に、AIが答えの形で返すと、利用者はそれを図書館の判断と受け取ります。 資料の案内と専門の窓口の案内にとどめます。

記録を残す

• 受付番号、受けた日時、経路（チャット／フォーム／分館）
• 伏せた後の質問票と、聞き取りのやり取りの要旨
• 検索した言葉と、3か所の検索結果の資料の番号
• AIの案（JSONの全文）と照合の結果
• 司書が足した資料と直した箇所
• 回答した日と回答した司書

伏せる前の会話は残しません。 利用事実を必要以上に持たないためです。残す期間も、レファレンス記録の扱いとあわせて館で決めます。

司書が足した資料の記録が、いちばん役に立ちます。 検索で拾えなかった資料が分かるので、手引きと過去の記録に足す候補になります。