Media > AI活用ユースケース > 研究開発 > 学芸員が作家の別号や和暦の年代のまま収蔵品データベースを OpenSearch で引き、貸出の依頼や展示の企画に合う資料の候補を並べる

学芸員が作家の別号や和暦の年代のまま収蔵品データベースを OpenSearch で引き、貸出の依頼や展示の企画に合う資料の候補を並べる

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

他館からの借用の依頼や自館の展示の企画に合う収蔵品を、作家の別号や旧字、和暦の年代といったあいまいな表記のまま探します。依頼文から条件を取り出して索引を引き、資料番号と根拠の記録付きで候補を並べます。

サマリー
生成AI
Azure OpenAI Service/Claude/Gemini
AIサービス
Azure AI/Google Vertex AI/OpenSearch
対象業界
その他/教育/自治体
対象部門
研究開発
対象業務
情報検索/比較検討
主な課題
判断に時間がかかる/属人化している/情報が見つからない
AIで行う処理
検索(RAG)
主な効果
対応スピード向上/属人化解消/検索時間短縮
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
RAG・個別開発(大)
人間の確認
条件付き
現在工数
80h/月
AI導入後
20h/月
想定削減
75%
年間削減
720h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 依頼状や照会のメールを読み、作家・年代・技法・主題・点数の条件を書き出す
  2. 収蔵品管理システムで作家名を引く。ヒットしなければ別号、旧字、読みで引き直す
  3. 年代は「文化」「文政」「江戸後期」「19世紀」とそれぞれ引き、結果を手でまとめる
  4. 技法は「墨画」「水墨」「墨絵」と言い換えて引く。主題(鶴、山水、花鳥)は名称と解説文を目で読む
  5. 候補について、紙の台帳とカード、前任者のメモで年代と作者の帰属を確かめる
  6. 状態の記録、これまでの展示日数、前回の貸出の時期を確かめ、貸し出せそうかを見当付ける
  7. 候補を一覧にして、照会への返事か展示の企画の資料にする
導入後(After)
  1. 自動毎晩、収蔵品管理システムの書き出しを取り込み、作家を典拠の番号に寄せ、年代を西暦の幅に直して索引を更新する
  2. 人学芸員が依頼状・照会のメールの本文を検索の画面に貼る
  3. 自動生成AIが依頼文から作家・年代・技法・主題・点数・除く条件を取り出す
  4. 自動作家名を典拠の一覧で番号に、年代の言葉を元号の表で西暦の幅に直す。直せなかった言葉は印を付けて残す
  5. 自動言葉の検索と意味の近さの検索を合わせて索引を引き、作家・年代・貸出の可否で絞る
  6. 自動生成AIが上位の記録を読み、条件ごとにどの欄に何が書かれていたかを写して候補の一覧にする
  7. 自動状態の記録、年間の展示日数、前回の貸出の時期を候補に添える
  8. 人学芸員が候補を確かめ、台帳とカードで帰属を見直し、照会への返事か展示の企画の資料にする
各工程の詳しい説明を読む
  1. 依頼状や照会のメールを読み、作家・年代・技法・主題・点数の条件を書き出す
  2. 収蔵品管理システムで作家名を引く。ヒットしなければ別号、旧字、読みで引き直す
  3. 年代は「文化」「文政」「江戸後期」「19世紀」とそれぞれ引き、結果を手でまとめる
  4. 技法は「墨画」「水墨」「墨絵」と言い換えて引く。主題(鶴、山水、花鳥)は名称と解説文を目で読む
  5. 候補について、紙の台帳とカード、前任者のメモで年代と作者の帰属を確かめる
  6. 状態の記録、これまでの展示日数、前回の貸出の時期を確かめ、貸し出せそうかを見当付ける
  7. 候補を一覧にして、照会への返事か展示の企画の資料にする

(a)別号と旧字で引けない。 「文晁」で引いて出ない資料が「文晁画」や「写山楼」で入っています。旧字の「澤」と新字の「沢」、「邊」と「辺」のように、同じ作家が字体の違いで別人になっています。 どの別号があるかを知っている人しか、全部を引き当てられません。

(b)年代の書き方がばらばら。 「文化年間」「1810年代」「19世紀前半」「江戸後期」は重なる時期を指していますが、システムの上ではただの文字列です。「文化・文政のころ」という依頼に対して、何通りも引いて手でまとめています。

(c)主題は解説文の中にしかない。 「鶴が描かれた屏風」の「鶴」は、名称に入っていないことが多く、解説文に書かれています。解説文を1件ずつ読むのが、いちばん時間のかかる作業です。

(d)貸し出せるかの見当に、記録をまたいで見る必要がある。 光に弱い資料は年間の展示日数に上限を設けていて、前回の展示と貸出から間を空けています。状態と展示の履歴が別の画面にあり、候補ごとに開いて確かめています。

  1. 【自動】 毎晩、収蔵品管理システムの書き出しを取り込み、作家を典拠の番号に寄せ、年代を西暦の幅に直して索引を更新する
  2. 【人】 学芸員が依頼状・照会のメールの本文を検索の画面に貼る
  3. 【自動】 生成AIが依頼文から作家・年代・技法・主題・点数・除く条件を取り出す
  4. 【自動】 作家名を典拠の一覧で番号に、年代の言葉を元号の表で西暦の幅に直す。直せなかった言葉は印を付けて残す
  5. 【自動】 言葉の検索と意味の近さの検索を合わせて索引を引き、作家・年代・貸出の可否で絞る
  6. 【自動】 生成AIが上位の記録を読み、条件ごとにどの欄に何が書かれていたかを写して候補の一覧にする
  7. 【自動】 状態の記録、年間の展示日数、前回の貸出の時期を候補に添える
  8. 【人】 学芸員が候補を確かめ、台帳とカードで帰属を見直し、照会への返事か展示の企画の資料にする

4番目が、この設計の分かれ目です。 作家と年代をAIに決めさせず、典拠の一覧と元号の表という人が作った表で決めます。 表に無い言葉は「直せなかった」と画面に出し、検索の条件から黙って外しません。

8番目を残すのは、帰属と保存の判断が学芸員の仕事だからです。 記録に「伝 谷文晁」とあるか「谷文晁」とあるかで意味が違い、その違いを依頼元にどう伝えるかは、記録を読める人が決めます。

02今回想定するシステム構成

構成図
収蔵品管理システム ── 毎晩CSVを書き出す
   ▼
AWS Lambda(取り込み)
   ├──▶ 作家を典拠の一覧で番号に寄せる(別号・旧字・読み)
   ├──▶ 年代の言葉を元号の表で西暦の幅に直す
   └──▶ 保管場所・評価額・寄贈者の連絡先の列を落とす
   ▼
Amazon OpenSearch Service
   │  kuromoji の分かち書き+旧字を新字に寄せる文字の置き換え
   │  技法・主題の言い換え辞書(検索のときに広げる)
   │  制作年の幅(integer_range)、解説文のベクトル
   ▼
【学芸員が依頼文を貼る】
   ▼
Claude(Amazon Bedrock)── 依頼文から条件を取り出す(JSON)
   ▼
AWS Lambda ── 作家を番号に、年代を西暦の幅に直す
   ▼
OpenSearch の hybrid クエリ(言葉の検索+意味の近さの検索、作家・年代・貸出の可否で絞る)
   ▼
Claude(Amazon Bedrock)── 記録を読み、条件ごとの根拠を写して候補にする
   ▼
【学芸員が候補を確かめ、返事か企画の資料にする】
役割想定する製品代替候補
検索基盤Amazon OpenSearch Service(kuromoji、synonym_graph、integer_range、hybrid クエリ)Azure AI Search、Vertex AI Search(Agent Search)
埋め込みAmazon Titan Text Embeddings V2(Amazon Bedrock)Cohere Embed(Amazon Bedrock)
生成AIClaude(Amazon Bedrock の Converse API、構造化出力)Azure OpenAI(Microsoft Foundry)、Gemini API
連携AWS Lambda(取り込み、表記の正規化、検索の画面からの呼び出し)AWS Step Functions
保管Amazon S3(書き出したCSVの原本、典拠の一覧、元号の表)館内のファイルサーバー

収蔵品管理システムは置き換えません。 記録の正本はこれまでどおり収蔵品管理システムにあり、この構成は毎晩の書き出しから検索のための写しを作るだけです。書き戻しはしません。

土台は Amazon OpenSearch Service です。 日本語の分かち書きをする kuromoji のプラグインはすべてのドメインに入っており、日本語向けに勧められている Sudachi は任意で追加するプラグインです。どちらを使うかで辞書の更新のしかたが変わるので、第7章で扱います。

最初の準備は、作家の典拠の一覧を作ることです。 同じ作家の本名・号・別号・旧字の表記・読みを1行にまとめ、作家番号を振ります。これは学芸員の知識を表にする作業で、AIの有無にかかわらず館の財産になります。

03どうやって実装するのか

Step1

処理の起点を決める

取り込みは毎晩の定時、検索は学芸員が依頼文を貼ったときに動きます。 2つを分けるのは、収蔵品の記録の更新は日中にまとめて行われ、照会への返事は依頼が届いたときに必要になるからです。

取り込みは、収蔵品管理システムが夜間にCSVを書き出し、S3 に置かれたことをきっかけに Lambda を動かします。書き出しは差分ではなく全件にします。 記録の削除や資料番号の付け替えを差分で追うと、索引に古い記録が残ります。3万2千件の全件でも夜間に収まる量です。

検索は、学芸員が館内の検索の画面に依頼状やメールの本文を貼り、「候補を探す」を押したときに動きます。依頼状がPDFや紙で届いたときは、学芸員が本文を書き写すか、PDFの文字を貼ります。 画像のままの依頼状を読むところまではこの構成に入れません。

Step2

入力データを集める

データ中身取得元
収蔵品の記録資料番号、名称、作家名、制作年代、技法・材質、寸法、員数、解説文、分類収蔵品管理システムの書き出し
状態と履歴状態の記録と最後の点検日、年間の展示日数、前回の展示と貸出の時期、貸出の可否の区分収蔵品管理システムの書き出し
作家の典拠の一覧作家番号、本名・号・別号・旧字の表記・読み、生没年学芸課が作って S3 に置く
元号の表元号ごとの西暦の始まりと終わり、時代区分(「江戸後期」など)の館の取り決めの幅学芸課が作って S3 に置く
依頼文依頼状・照会のメールの本文学芸員が画面に貼る

質を決めるのは、3行目と4行目です。 典拠の一覧に別号が入っていなければ、その別号で入っている資料は作家番号に寄りません。「江戸後期」を何年から何年とするかは、館の取り決めとして元号の表に書きます。 決まった定義が無い言葉なので、AIや担当者ごとに幅が変わると、同じ依頼で結果が変わります。

保管場所・評価額・寄贈者の連絡先は入力に入れません。 検索に要らないうえ、収蔵品の所在と価値がまとまった情報は館の外に出してはいけないものです。取り込みのときに列ごと落とします。

Step3

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

取るものどこから何に使うか
記録の全件S3 に置かれたCSV索引の作り直し
作家の典拠の一覧S3 の表作家名を作家番号に寄せる。別号の展開
元号の表S3 の表年代の言葉を西暦の幅に直す
技法・主題の言い換え辞書OpenSearch Service のパッケージ検索のときに言い換えを広げる
解説文のベクトル取り込みのときに Titan Text Embeddings V2 で作る意味の近さの検索

言い換え辞書は、OpenSearch Service のパッケージとして登録します。 テキストの辞書を S3 に置いて取り込み、ドメインに関連付けると、analyzers/<パッケージID> の形で synonyms_path に指定できます。検索用の分析器だけに使い、updateable を true にしておくと、辞書を更新したときに索引を作り直さずに反映されます。

解説文のベクトルは、OpenSearch の取り込みパイプラインの text_embedding で作ります。OpenSearch Service から Bedrock のモデルを呼ぶコネクタを作り、そのモデルの番号をパイプラインと検索に指定します。Titan Text Embeddings V2 は英語に最適化されたモデルで、日本語は多言語対応の一覧に含まれます。 館の解説文で、意味の近さの検索が役に立つかを先に試します(第8章)。

Step4

AIへ渡す前に整形する

  1. 作家を典拠の番号に寄せる … 作家名の欄を典拠の一覧と照らし、作家番号を付けます。「伝」「筆」「画」「款」の付いた書き方は、付いた語を別の欄(帰属の区分)に分けて残します
  2. 年代を西暦の幅に直す … 「文化年間」は元号の表で1804から1818、「19世紀前半」は1801から1850のように、integer_range の欄に gte と lte で持たせます
  3. 直せなかった年代に印を付ける … 「江戸時代か」「近世」のように表で直せないものは、幅を付けずに「年代未正規化」の印を付けます
  4. 旧字を新字に寄せる … 「澤→沢」「邊→辺」「髙→高」の表を文字の置き換え(mapping)に入れます。分かち書きの前に置き換えるので、索引と検索の両方で同じ字になります
  5. 落とす列を落とす … 保管場所、評価額、寄贈者の連絡先
  6. 解説文の長さを確かめる … 数行の解説文が大半ですが、長い調査の記録が入っているものは段落で分けます

1番目で「伝」を消さないでください。 「伝 谷文晁」は「谷文晁の作と伝わる」で、谷文晁の作と確かめられたものではありません。作家番号は同じでも、帰属の区分が違うことを候補の一覧に出します。

2番目は、AIではなく表で行います。 元号から西暦への直しは決まった対応なので、表で引くほうが確実です。表で直せないものを、それらしい幅でAIに埋めさせないでください。 「近世」を1603年から1867年とするかどうかは、館が決めることです。

Step5

AIに処理させる

させるのは2つです。依頼文から探す条件を取り出すことと、見つかった記録を読んで条件ごとの根拠を写すことです。

段させることさせないこと
条件の取り出し作家名・年代の言葉・技法・主題・点数・除く条件・期限を、依頼文に書かれた言葉のまま取り出す作家名を正しい表記に直す、年代を西暦に直す
根拠の写し候補の記録のどの欄に、条件に当たる言葉がどう書かれていたかを写す記録に無い作家・年代・主題を補う
並べ替え条件にいくつ当たったかで並べる貸し出せるかの判断

作家名と年代を「書かれた言葉のまま」取り出させるのが要です。 直すのは Lambda が典拠の一覧と元号の表で行います。AIが直すと、表に無い別号でも、それらしい作家に寄せてしまいます。

根拠の写しでは、記録の欄の名前と、その欄の文字列を写させます。 「鶴」が解説文にあったのか、名称にあったのかで、候補としての確からしさが違います。写した文字列は Lambda で記録の原文と照らし、見つからなければその候補を外します。

Step6

指示内容を固定する

条件の取り出しの指示:

あなたは博物館の学芸課で、他館や研究者から届いた依頼文を読み、
収蔵品を探すための条件を取り出す担当です。

【取り出す項目】
- artists:依頼文に書かれた作家名を、書かれた表記のまま並べる
- period_phrases:年代を表す言葉を、書かれた表記のまま並べる
  (「文化・文政のころ」「19世紀前半」「江戸後期」など)
- techniques:技法・材質を表す言葉
- motifs:主題・描かれているもの
- object_types:掛軸・屏風・巻子・陶磁など、資料の形
- count:希望する点数。書かれていなければ null
- exclusions:除く条件(「重要文化財は除く」「寄託品は除く」など)
- deadline:返事の期限。書かれていなければ null

【厳守事項】
- 作家名を正しい表記や本名に直さないでください。
  「文晁」と書かれていれば「文晁」のまま入れてください。
- 年代を西暦に直さないでください。言葉のまま入れてください。
- 依頼文に書かれていない作家・年代・主題を足さないでください。
  「〇〇派」とあっても、その派の作家を並べないでください。
- 依頼文が収蔵品の照会でない場合は、request_type を other にして、
  他の項目は空にしてください。

【依頼文】{request_text}

候補の根拠の写しの指示:

あなたは学芸課で、検索で見つかった収蔵品の記録を読み、
依頼の条件に当たる根拠を写す担当です。

【依頼の条件】{conditions_json}
【検索で見つかった記録】{hits_json}

【やること】
1. 記録ごとに、条件(作家・年代・技法・主題・形)のどれに当たるかを見る
2. 当たった条件ごとに、記録のどの欄(name / artist_raw / period_raw /
   technique / description)に何と書かれていたかを、記録の文字列のまま写す
3. 当たらなかった条件は not_found とする

【厳守事項】
- 記録に書かれていない内容を書かないでください。
  解説文に「鶴」が無ければ、motif は not_found です。
- 写す文字列は、記録の文字列をそのまま写してください。言い換えないでください。
- 「伝」「筆」「款」の付いた書き方は、付いたまま写してください。
- 貸し出せるか、展示できるかは書かないでください。
- 状態・展示日数・貸出の履歴は、こちらで添えるので書かないでください。

1つ目の「派の作家を並べない」を書かないと、「四条派」から作家の名前を補って検索の条件を広げます。 広げた条件で見つかった資料は、依頼元の意図と違うことがあり、しかも広げたことが画面に残りません。 広げたいときは、学芸員が作家名を足して引き直します。

2つ目の「状態・展示日数は書かない」は、ずれを防ぐためです。 数字は Lambda が記録から添えます。AIが写すと、桁や年を取り違えたときに見分けがつきません。

Step7

出力形式を固定する

条件の取り出しは、次の形のJSONで受け取ります。Bedrock の Converse API の outputConfig.textFormat に JSON スキーマを渡し、形をそろえます。

{
  "request_type": "loan_request | exhibition_plan | inquiry | other",
  "artists": ["文晁"],
  "period_phrases": ["文化・文政のころ"],
  "techniques": ["水墨"],
  "motifs": ["山水"],
  "object_types": ["掛軸"],
  "count": 3,
  "exclusions": ["寄託品は除く"],
  "deadline": null
}

候補の一覧は、次の形で受け取ります。

{
  "candidates": [
    {
      "object_no": "",
      "matches": [
        { "condition": "artist | period | technique | motif | object_type",
          "status": "matched | not_found",
          "field": "name | artist_raw | period_raw | technique | description",
          "quote": "" }
      ]
    }
  ]
}

1つ目の理由は、作家と年代の直しを後段に分けられることです。 artists と period_phrases は言葉のまま来るので、Lambda が典拠の一覧と元号の表で直し、直せなかった言葉を画面に「未解決」として出せます。

2つ目は、根拠を照らせることです。 quote を記録の原文と突き合わせ、見つからない候補は外します。Bedrock の構造化出力は数値の範囲や文字列の長さの制約に対応していないので、点数の上限などは Lambda の側で見ます。

検索は hybrid クエリで行います。

部分中身
言葉の検索名称・作家名の原文・技法・解説文に対する multi_match(言い換え辞書を検索のときに広げる)
意味の近さの検索解説文のベクトルに対する neural(依頼文の主題を渡す)
絞り込み(filter)作家番号、制作年の幅(integer_range に対する range の intersects)、貸出の可否の区分、除く条件
合わせ方検索パイプラインの normalization-processor(min_max と arithmetic_mean、重み)

hybrid クエリは検索の最上位に置きます。 function_score などの中に入れることはできず、入れるとエラーになるか正規化が飛びます。 句は5つまでです。展示日数の少ないものを上に出したいときは、hybrid の中ではなく、検索のあとに Lambda で並べ替えます。

年代は intersects で絞ります。 「文化・文政のころ」を1804から1830とし、記録の幅がそこに重なるものを拾います。within にすると「19世紀前半」と書かれた資料が落ちます。

Step8

システムへ連携する

つなぎ先方式内容
収蔵品管理システム夜間のCSVの書き出し記録の全件を S3 に置く
Amazon OpenSearch ServiceLambda から索引の作成と検索索引の作り直し、hybrid クエリ
Amazon Bedrock(Titan)OpenSearch のコネクタ解説文と依頼文のベクトル
Amazon Bedrock(Claude)Lambda から Converse API条件の取り出し、根拠の写し
検索の画面館内のネットワークからのみ開ける画面依頼文を貼り、候補の一覧を見る

収蔵品管理システムへは書き戻しません。 典拠の一覧で作家番号が付いても、それを正本の記録に入れるかは、学芸課が記録の見直しとして別に決めます。

索引は2つ持ち、別名で切り替えます。毎晩新しい索引を作り、件数を確かめてから別名を付け替えます。 取り込みに失敗した夜は、前の索引のまま検索できます。

Step9

人が確認する

候補の一覧をそのまま依頼元に送ることはしません。 学芸員が次の順で確かめます。

  1. 未解決の言葉を見る … 典拠の一覧に無かった作家名、元号の表で直せなかった年代。ここが残っていれば、検索が漏れている可能性があります
  2. 帰属の区分を見る … 「伝」「款」の付いたものを、依頼元にどう伝えるかを決めます
  3. 台帳とカードで見直す … 候補に選んだものだけ、紙の記録と照らします
  4. 状態と履歴を見る … 展示日数、前回の貸出から空いた期間、点検の記録を見て、貸し出せるかを保存の担当と相談します
  5. 返事か企画の資料にする

1番目を省かないでください。 典拠の一覧に無い別号は、そもそも検索の条件に入っていません。見つからなかったのではなく、探していないのです。 未解決の作家名が出たら、典拠の一覧に足してから引き直します。

目標は1件15分です。 候補の一覧と根拠を読み、選んだものだけ紙の記録と照らして、返事にまとめるまでの時間です。

Step10

例外に対処する

起きること対応
作家名が典拠の一覧に無い「未解決」として画面に出し、言葉の検索だけで引く。典拠の一覧に足す候補として記録する
年代の言葉が元号の表で直せない年代の絞り込みをかけずに引き、画面にその旨を出す
「年代未正規化」の資料絞り込みで落ちないよう、年代の条件とは別に拾って末尾に並べる
0件技法・主題の条件を外して引き直し、外した条件を画面に出す
候補が多すぎる作家・年代の条件に当たったものを先に並べ、主題だけで当たったものは別にまとめる
写した文字列が記録の原文に無いその候補を外し、件数を記録する
依頼文が照会でないrequest_type が other。検索せずに学芸員へ戻す
取り込みのCSVが壊れている、件数が前日より大きく減った索引を切り替えず、前の索引のまま検索できるようにして担当へ知らせる
言い換え辞書の更新が反映されないupdateable を付けていない分析器では、索引を閉じて開き直すか作り直す

3行目を忘れやすいです。 年代で絞ると、年代の書かれていない資料は1件も出ません。記録が古い資料ほど年代が書かれておらず、探したい資料ほど落ちます。

Step11

記録を残す

  • 検索ごとの依頼文、取り出した条件、直した作家番号と年代の幅、未解決の言葉
  • 送った hybrid クエリと、返ってきた資料番号と点数
  • 生成AIの出力の全文と、原文と照らして外した候補
  • 学芸員が選んだ候補と、選ばなかった理由の区分
  • 典拠の一覧・元号の表・言い換え辞書の版

未解決の言葉は、毎月まとめて学芸課の会議で見ます。 典拠の一覧と言い換え辞書に足すべき言葉の一覧になり、古参の学芸員の頭の中にあった知識が、表に移っていきます。

表の版を残すのは、同じ依頼でも表を足す前と後で結果が変わるためです。 他館から「前に問い合わせたときは無いと言われた」と言われたときに、当時どの表で引いたかを確かめられます。

04実装レベルの3段階

最小構成:依頼文を生成AIの画面に貼って条件を取り出し、書き出した記録を手で絞る / 条件の書き出し
半自動化:上記+OpenSearch に索引を作り、典拠の一覧と元号の表で正規化して言葉の検索で引く / 表記のゆれを吸収した検索
本格構成:上記+意味の近さの検索を合わせ、根拠の写しと状態・履歴を添えた候補の一覧まで出す / 検索から候補の一覧まで

最小構成では件数がさばけません。 書き出した記録を手で絞るので、確かめるための段階です。 半自動化で、①の引き直しがほぼ無くなります。 典拠の一覧で作家が1つの番号に寄り、年代が西暦の幅で引けるようになるからです。本格構成で、主題の検索と②③の見直しの手間が減り、この段階が本記事の想定です。 段階を飛ばさないでください。 半自動化の1か月でたまる未解決の言葉を表に足してから、意味の近さの検索を足します。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
4 名
月間件数
80 件
1件あたり現在時間
60 分
1件あたり導入後時間
15 分
現在  80件 × 60分 ÷ 60 = 80 時間/月
導入後 80件 × 15分 ÷ 60 = 20 時間/月
月間削減時間
60h
削減率
75%
年間削減時間
720h
年間金額換算(時間単価3,500円)
252万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 美術・歴史資料を数万点規模で収蔵し、他館からの借用の依頼、自館の企画展・常設展の展示替え、研究者や出版社からの所在の照会を合わせて月に数十件以上受けている公立・私立の博物館・美術館・大学博物館。収蔵品管理システムから資料の情報をCSVなどで書き出せるが、作家名の別号や旧字、和暦や「江戸後期」といった年代の書き方がばらばらで、探せるのが長く勤めた学芸員だけになっている場合。AWS を使える担当か委託先がいる場合。
向いていない
  1. 収蔵品が数百点で、学芸員が全点を頭に入れている場合。収蔵品の情報がまだ紙の台帳とカードだけで、データとして書き出せない場合(先にデータ化から始めます)。照会が月に数件の規模。なお、資料を貸し出してよいか、展示してよいかという保存上の判断と、借用の条件の交渉は、この構成では代替できません。収蔵品の記録に書かれた内容を探して示すまでです。

07最小構成で試す方法

  1. 先月までに受けた照会から20件を選ぶ(うち数件は、別号や旧字で引き当てに苦労したものを入れる)
  2. 古参の学芸員に、その20件で最終的に挙げた資料と、引き当てた表記を聞き取る
  3. 収蔵品管理システムから、その作家と年代の周辺の記録を数百件書き出す
  4. 手元の生成AIの画面に依頼文を貼り、「作家名・年代・技法・主題を、書かれた表記のまま取り出してください。直さないでください」と指示する
  5. 取り出した言葉を、学芸員が別号と元号の表に照らして書き換え、書き出した記録を表計算で絞り込む
  6. 当時挙げた資料が出るかを突き合わせる

20件は必ずやってください。 索引を作る前に、「表記をそろえれば引き当てられるのか」を確かめます。

出てきた内容判断
典拠の一覧と元号の表で書き換えると、当時の資料がほぼ出た索引の構築に進む
作家名を勝手に本名に直して取り出した指示の書き方で直る。構成は有効
主題が解説文に書かれておらず、どう引いても出ない記録の側の問題。 解説文の補記が先

3行目が出ても失敗ではありません。 学芸員の記憶を記録に移すべき資料の一覧になります。

08実装時につまずきやすいポイント

問題対策
別号で入っている資料が出ない典拠の一覧に別号が無い。 未解決の言葉の一覧から足す
旧字と新字で別人になる文字の置き換え(mapping)を分かち書きの前に置く。索引と検索の両方に同じ分析器を使う
年代で絞ると古い記録が落ちる「年代未正規化」の資料を別に拾う
「19世紀前半」の資料が落ちるrange の relation を intersects にする。within にしない
言い換え辞書を索引の分析器に入れて、句の検索が外れるsynonym_graph は検索の分析器だけに使う
辞書を更新しても反映されない検索の分析器に updateable を付ける。付けていなければ索引を作り直す
hybrid クエリに展示日数の加点を入れてエラーになるhybrid は最上位に置く。並べ替えは検索のあとに行う
作家名をAIが本名に直す「書かれた表記のまま」を指示に書き、直しは表で行う
「伝」が落ちて断定の帰属に見える取り込みで帰属の区分の欄に分けて残す
解説文の意味の近さの検索が効かないTitan V2 は英語に最適化。館の解説文で試してから重みを決める
Sudachi の辞書の更新がすぐ反映されない次の blue/green の更新まで待つか、新しい索引を作って別名を付け替える

上の2行が、この構成の失敗のほとんどです。 どちらも表記のゆれで、AIを入れても直りません。 典拠の一覧と文字の置き換えの表を、学芸課の仕事として育てていくことが前提です。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 収蔵品の名称・作家・年代・技法・解説文、状態と展示・貸出の履歴、そして取り込みで落とす保管場所・評価額・寄贈者の連絡先です。

  1. 所在と価値の情報を索引に入れない … 保管場所と評価額がまとまった一覧は、盗難の下調べに使えます。検索に要らないので、取り込みの最初に落とします
  2. 寄贈者・寄託者の個人の情報を生成AIに渡さない … 受入れの経緯の欄に個人名と住所が入っている記録があります。生成AIに渡すのは、条件と根拠に要る欄だけに絞ります
  3. 検索の画面を館内に限る … 未公開の資料や寄託品の情報も含みます。画面は館内のネットワークと学芸課の担当者だけが開けるようにします
  4. 帰属の判断を候補の一覧に任せない … 「伝」の資料を作家の作として返事に書くと、館の見解として外に出ます。帰属をどう伝えるかは学芸員が決めます
  5. 貸出の可否を自動で決めない … 状態と展示日数を添えるのは判断の材料で、貸し出すかは保存の担当と学芸課が決めます

誤りが起きた場合のリスクは、所蔵している資料を「無い」と返すことと、帰属の確かでない資料を確かなものとして示すことの2つです。 前者は未解決の言葉を見落とすと起き、後者は「伝」を落とすと起きます。どちらも表記の扱いから出ているので、そこを設計で守ります。

10まず何から始めるか

1週目:作家の典拠の一覧を作り始める

照会の多い作家から50人を選び、本名・号・別号・旧字の表記・読みを1行にまとめます。古参の学芸員に聞き取りながら作ります。 全作家を一度にそろえる必要はありません。

2週目:20件で試す

先月までの照会から20件を選び、生成AIの画面で条件を取り出し、典拠の一覧で書き換えて書き出した記録を絞ります。当時挙げた資料が出るかを突き合わせます。

3週目:元号の表と時代区分の取り決めを作る

元号ごとの西暦の幅と、「江戸後期」「近世」などの言葉を何年から何年とするかを、学芸課で決めて表にします。 ここが決まらないと、年代の絞り込みの結果が担当者ごとに変わります。

4週目:索引を作って言葉の検索で引く

OpenSearch Service のドメインに、旧字の置き換えと kuromoji の分析器、integer_range の欄を持つ索引を作り、夜間の取り込みをつなぎます。この時点では意味の近さの検索も、根拠の写しも入れません。

2か月目: 言い換え辞書と未解決の言葉の一覧を回し始め、典拠の一覧を毎月足します。3か月目以降: 解説文のベクトルと hybrid クエリ、根拠の写しを足し、1件60分が何分になったかを実測します。未解決の言葉が毎月ほとんど出なくなった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-15/最終更新:2026-10-23
確認した内容情報源確認日
Japanese(kuromoji)Analysis と ICU Analysis がすべてのドメインに入っていること。Sudachi Analysis が日本語向けに勧められる任意のプラグインであること。Neural Search と ML Commons のプラグインがあることAWS: Plugins by engine version in Amazon OpenSearch Service2026-10-15
言い換えなどの辞書を S3 から取り込んでドメインに関連付け、analyzers/<ID> を synonyms_path に指定できること。updateable が検索の分析器にだけ使え、付けていれば辞書の更新が自動で反映されること。付けていなければ索引を閉じて開くか作り直すこと。Sudachi の辞書の付け替えが次の blue/green の更新まで反映されないことAWS: Importing and managing packages in Amazon OpenSearch Service2026-10-15
kuromoji の分かち書きに normal・search(既定)・extended の区分があり、ユーザー辞書を指定できることOpenSearch: Kuromoji tokenizer2026-10-15
mapping の文字フィルタが分かち書きの前に key => value の対で文字を置き換え、長いほうの一致を取ることOpenSearch: Mapping character filter2026-10-15
synonym_graph を検索の分析器だけに使うよう書かれ、索引のときに使うと句の検索が外れうることOpenSearch: Synonym graph token filter2026-10-15
integer_range などの幅の型があり、gte・lte で幅を持たせ、range の検索で within・intersects・contains を選べることOpenSearch: Range field types2026-10-15
hybrid 検索が normalization-processor(min_max・arithmetic_mean・重み)の検索パイプラインを要すること。取り込みパイプラインの text_embedding と knn_vector の欄、neural の検索の例。最上位の filter で先に絞れることOpenSearch: Hybrid search2026-10-15
hybrid クエリの句が5つまでで、検索の最上位に置くもので、function_score などの中に入れられないことOpenSearch: Hybrid query2026-10-15
Titan Text Embeddings V2 が英語に最適化され、多言語対応の一覧に日本語が含まれること。出力が1,024(既定)・512・256次元であることAWS: Amazon Titan Text Embeddings models2026-10-15
Converse API の outputConfig.textFormat で JSON スキーマに沿った出力が得られること。数値の範囲・文字列の長さの制約に対応せず400になることAWS: Structured outputs(Amazon Bedrock)2026-10-15

資料を貸し出すか、展示するか、帰属をどう伝えるかは、学芸課と保存の担当が決めてください。 本記事は上記の公式ページで確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1718)についてのご相談はこちらから。

AI活用について相談する
目次