図書館システムとは？OPAC・貸出返却・蔵書目録の機能構成と、パッケージか受託開発かの判断基準

図書館システムは、館が持つ資料の目録と、誰にいつ何を貸しているかという記録を一つの台帳にまとめ、その一部を利用者向けの検索画面として外へ出す仕組みです。機能の名前を並べた説明は各社の製品ページに揃っていますが、実際に導入判断で詰まるのは機能表ではなく、データの持ち方と外部接続の条件のほうです。この記事では、図書館システムが引き受ける五つの業務領域と、その裏側にある三層のデータ構造、公共・大学・学校・企業内図書室で変わる要件、そしてパッケージ導入と受託開発のどちらへ寄せるかの判断条件までを、受託開発会社の視点で整理します。

まとめ：図書館システムの機能構成と、パッケージか開発かを分ける三条件

先に結論を示します。図書館システムが引き受ける業務は、資料管理（受入・目録・除籍）、閲覧管理（貸出・返却・予約・督促）、利用者管理（登録・利用者カード・履歴の扱い）、相互貸借、統計と帳票という五つの領域です。これに加えて、利用者が館外から蔵書を探す画面がOPAC（Online Public Access Catalog）と呼ばれ、業務側の目録データを読み取って公開します。館の職員が触る業務系と、利用者が触るOPACという二層構造で捉えると、機能の重複や責任範囲の切れ目が見えやすくなります。

調達方式を分ける条件は三つあります。第一に、目録と分類の規則が既成の枠に収まるか。日本十進分類法と外部から供給される書誌データで足りるなら、パッケージの想定内です。第二に、外部接続の要否。大学の相互貸借、自動貸出機やICタグ、電子書籍サービスとの併走が絡むほど、実績のあるパッケージが有利になります。第三に、利用者データを社内や自治体の既存基盤と統合したいか。ここが要件に入ると、パッケージの利用者マスタでは受け止めきれず、開発側に寄る判断が出てきます。

判断としては、公共図書館と大学図書館の標準的な業務だけを回すならパッケージを選び、受託開発は見送ってかまいません。この領域は製品が成熟しており、独自に作る費用に見合う差は出ないためです。受託開発を選ぶ意味があるのは、企業内の図書室や専門資料室のように分類体系が館独自で、なおかつ社内の認証基盤や会員基盤と利用者情報をつなぎたい場合に絞られます。

図書館システムとは何か｜業務系とOPACの二層構造で捉える設計の基本

図書館システムという語は、館内の業務ソフト全般を指す広い意味でも、利用者が見る蔵書検索だけを指す狭い意味でも使われます。話がかみ合わない原因はここにあるため、最初に範囲を分けておきます。

職員が使う業務系と、利用者が見るOPACで責任範囲を切り分ける

業務系が扱うのは、資料を買って登録し、貸して返してもらい、傷んだものを外すという資産の一生です。OPACが扱うのは、その台帳のうち公開してよい部分を検索させ、予約を受け付け、利用者に自分の貸出状況を見せることに限られます。二つは同じデータベースを共有する構成が一般的ですが、公開範囲と応答速度の要件がまるで違うため、設計上は別の層として切り分けます。OPACだけを刷新して館内の業務系は据え置く、という段階的な進め方が成立するのもこの構造があるからです。

学校の校務システムや大学の学務システムとは扱う資産と記録の単位が違う

同じ教育機関で使われるシステムでも、対象が資料か人かで設計は分かれます。校務支援システムは小中高の出欠・成績・指導要録を扱い、学務システムは大学の履修と学籍を扱います。どちらも中心にあるのは児童生徒や学生の記録です。図書館システムの中心にあるのは資料という物であり、人の情報は貸出という行為を成立させるために最小限だけ持ちます。この違いは後述する履歴の保存方針にも効いてくるため、業務システム全体の中での位置づけは業務システムとはで整理した枠組みと合わせて押さえておくと迷いません。

機能構成を五領域に分解する｜貸出返却と目録の裏側にあるデータ構造

機能の名前だけを覚えても、移行や連携でつまずく箇所は見えません。ここでは五領域を押さえたうえで、その下にあるデータの持ち方まで降ります。

資料管理と閲覧管理｜受入から除籍までを一本の記録として継続して追う

資料管理は、発注と受入、目録作成、装備、そして除籍までを記録します。目録作成では、書名や著者名に加えて分類記号と件名を与え、資料を探せる状態にします。閲覧管理は貸出と返却が中心ですが、実務で負荷が高いのは予約と督促のほうです。予約は「どの資料でもよいから順番待ち」という指定になるため、書名単位の待ち行列と、実際に確保できた一冊とを結びつける処理が要ります。督促は期限超過の抽出と通知手段の選択で、ここは自治体の運用方針によって差が出ます。

書誌・所蔵・個体という三層を分けて持つ理由と移行時の数え方を理解する

図書館システムのデータは、同じ本に見えるものを三つの層に分けて持ちます。書誌は「この本という作品と版」を表す情報、所蔵は「どの館のどの排架場所に持っているか」を表す情報、個体は「バーコードやICタグで識別できる一点一点」を表す情報です。同じタイトルを三館が二冊ずつ持てば、書誌は一件、所蔵は三件、個体は六件という内訳になります。貸出は必ず個体に対して行われ、検索の対象は書誌です。移行で件数が合わなくなる事故の大半は、この三層のどれを数えているかがベンダー間でずれることから起きます。見積りを依頼する段階で、蔵書冊数ではなく三層それぞれの件数を出しておくと、後から金額が動きにくくなります。

利用者管理と貸出履歴｜返却時に記録を消す前提と保存条件を設計する

利用者管理では、登録情報、利用者カードの番号、貸出中の資料、延滞や弁償の状態を持ちます。ここで踏まえておきたいのが、日本の図書館では利用者が何を読んだかという事実を外に出さない運用が広く共有されている点です。多くの公共図書館は、返却が済んだ時点で貸出記録を利用者と結びつけない設計を取っています。読書履歴を見せる機能や貸出傾向からのおすすめ表示を求められた場合は、利用者本人が明示的に選んだときだけ履歴を残す形にして、既定は保存しない側が妥当です。統計を取りたい要望とは、個人と結びつかない形へ丸めた集計で両立させます。この方針を要件定義の初期に決めておかないと、設計の後半でデータ保持期間を丸ごと見直す羽目になります。

相互貸借と統計｜館をまたぐ貸し借りと年次報告に残る作業負荷を見る

相互貸借は、自館にない資料を他館から取り寄せる仕組みで、依頼と受付の双方が記録対象です。公共図書館では都道府県立を中心とした県内の物流網に乗り、大学図書館では後述する全国規模の仕組みを使います。統計と帳票は地味に見えますが、年次の報告書式が決まっているため、必要な集計軸が製品側に用意されていないと手作業が残ります。要件定義では、提出している報告書の実物を持ち寄って、どの数字が自動で出るかを一つずつ突き合わせるのが確実です。

館種で要件はどう変わるか｜公共・大学・学校・企業内図書室の違い

同じ図書館システムという名前でも、館種が変わると必須になる接続先と目録の作り方が変わります。製品の得意分野もここで分かれるため、候補を絞る前に自館がどの列に当たるかを確認します。

公共図書館は電子書籍サービスが別システムで並走する前提になる

電子出版制作・流通協議会の集計では、電子図書館サービスの実施は2026年7月1日現在で613自治体・493電子図書館に達しており、前回集計の2026年4月1日からも増えています。ここで押さえたいのは、電子書籍の貸出は多くの場合、紙の資料を扱う図書館システムとは別のサービスとして提供され、利用者から見て入口が二つに分かれる点です。利用者IDを共通化するのか、検索結果を横断で見せるのかは、それぞれ別の連携作業になります。導入時に「電子図書館も入れる」と決めただけでは、この二重化の手当ては終わりません。

自治体の標準化20業務に図書館が入っていない意味と調達上の裁量を押さえる

地方公共団体の情報システムは、デジタル庁が所管する標準化の枠組みで統一仕様への移行が進んでいます。ただし政令で指定された対象事務は住民基本台帳や戸籍、個人住民税、介護保険といった20業務で、図書館業務はこの中に含まれていません。移行の目標時期も2025年度までとされ、困難な団体は概ね5年以内という扱いですが、図書館はそもそもこの対象外です。つまり図書館システムには国が示す標準仕様が存在せず、自治体は独自の判断で製品を選び、更新の時期も自前で決められます。裁量が広い一方、他自治体との共同利用や仕様の共通化を進めたいなら、その枠組みは自分たちで設計する必要があります。

大学図書館は共同目録との接続実績と対応範囲が製品選定の制約条件になる

大学図書館は、国立情報学研究所が運営する目録所在情報サービスに参加し、書誌と所蔵を共同で作る運用が基本です。この仕組みは2020年8月3日にCAT2020へ移行し、書誌の重複を許容する、所蔵登録の際に書誌を自動で流用するなど、目録作業の前提が変わりました。相互貸借が回るのも同じ基盤の上です。したがって大学向けの製品を選ぶときは、機能表の比較よりも、この基盤への接続実績があるかどうかが先に来ます。学生の身分情報は学務システム側が持つため、利用者登録をどちらの更新に合わせるかも決めておきます。

外部接続と電子化の勘所｜書誌データ・自動貸出機・API連携を見る

図書館システムは単体で閉じません。書誌をどこから調達するか、館内の機器とどうつなぐか、外部に検索させるかで、必要な作業量が変わります。

書誌データをどこから調達するかで目録作業と移行時の負荷が決まる

目録を一件ずつ手で作る館はほとんどありません。国立国会図書館が作成する書誌データや民間の書誌供給サービスから取り込み、自館の所蔵情報を足すのが通常の流れです。取り込み元が変われば、項目の粒度も分類記号の付き方も変わるため、既存データとの混在が移行時の論点です。加えて国立国会図書館サーチは、検索用にSRUとOpenURL、一括取得用にOAI-PMHというAPIを公開しています。自館のサイトへ検索窓を組み込む設計は取り得ますが、同時リクエスト数の制限があり、利用側にAPI使用の明記が求められ、提供機関の許諾や営利利用の申請条件も定められています。設計前に利用条件を読み込んでおく前提の仕組みだと考えてください。

自動貸出機とICタグ｜接続規格の名前で対応可否を確認できる状態にしておく

自動貸出機や返却仕分け、ゲートでの持ち出し検知を入れる場合、図書館システムと機器の間は標準的な通信プロトコルでつなぎます。自動貸出機との通信にはSIPが、貸出や相互貸借のデータ交換にはNCIPが使われてきた経緯です。ICタグ側では、図書館でのRFID利用を定めた国際規格ISO 28560が2011年3月に出版され、タグに書き込むデータ項目とエンコード方式を三部構成で規定しています。機器を先に決めてからシステムを選ぶと接続の可否で手戻りが出るため、候補選定の段階で必要なのは、どの規格に対応しているかの確認です。館の側がこの規格名で会話できると、ベンダーの回答も具体になります。

導入でつまずく三つの原因｜移行・分類規則・切替時期を設定する手順

製品の良し悪しより、進め方で失敗する例のほうが多いのが実情です。繰り返し起きる原因は三つに整理できます。

データ移行は三層の件数と貸出・予約の紐づけ範囲を先に確定させる

一つ目は移行です。前述した書誌・所蔵・個体の三層は、旧システムごとに持ち方が異なります。個体に紐づく貸出中の状態、予約の待ち行列、弁償や督促の途中経過についても、どこまで運ぶかの決定が必要です。移行の見積りを取る前に、三層それぞれの件数と、現在貸出中の点数、未処理の予約件数を数えておくと、作業量の前提が揃います。数え方を決めずに進めると、検収の段階で「移った」「移っていない」の水掛け論になります。

分類と件名の規則は館内で例外の扱いまで合意してから移行に入る

二つ目は分類規則です。長く運用してきた館ほど、独自の付け方や例外が積み上がっています。新システムへ移す作業は、その例外を洗い出す機会になりますが、移行と並行して規則を直そうとすると作業が終わりません。規則の見直しは移行前に決着させ、移行そのものは現状のまま運ぶ、という順序に分けたほうが工程は安定します。

切替の時期は繁忙期と長期休館の位置から要件定義と移行日程を逆算する

三つ目は時期の設定です。図書館では年度替わりと長期休暇の時期に貸出が集中します。切替のために窓口を止められる期間は限られ、資料の点検作業との重複も想定対象です。館の年間行事から動かせない日を先に押さえ、そこから逆算して要件定義と移行リハーサルの日程を引きます。ここを詰めずに開発側の都合で日程を組むと、現場が受け止めきれずに稼働後の混乱が長引きます。

パッケージ導入と受託開発を分ける判断条件を館種と要件から言い切る

ここまでの整理を踏まえて、どちらを選ぶかの条件を示します。曖昧に併記せず、採用する場面と見送る場面を分けます。

パッケージを選ぶべき館種と、独自開発を見送ってよい要件の条件

公共図書館と大学図書館で、標準的な目録と貸出返却、相互貸借、法定の統計を回すだけなら、パッケージを選びます。これらの館種は業務の型が全国でほぼ共通で、外部接続の実績も製品側に蓄積されています。独自に作っても得られる差は運用画面の細部にとどまり、その差のために接続対応と法改正への追随を自前で背負うのは割に合いません。学校図書館も同様で、校務系の名簿と端末環境に合うことが選定の主眼になります。この三つの館種では、開発による内製は見送ってかまいません。

受託開発が向くのは独自分類と既存の認証・会員基盤の統合が重なるとき

開発を選ぶ意味が出るのは、企業内の図書室や専門資料室のように、扱う資料が社内文書や規格書、技術資料で、一般の分類体系に乗らない場合です。ここに社内の認証基盤との統合、部門ごとの閲覧権限、貸出状況を社内ポータルへ出すといった要件が重なると、パッケージの利用者マスタと権限モデルでは受け止めきれません。利用者の登録と権限、貸出という行為の記録を自社の会員基盤の延長として設計する形になるため、会員管理システム開発の枠組みで検討したほうが、認証や権限の設計を含めて筋が通ります。逆に、この二条件のうち独自分類だけしかない場合は、パッケージの分類マスタを拡張できるかを先に確認してください。それで足りるなら開発する理由は消えます。

よくある質問

図書館システムと蔵書管理システムは何が違いますか？

蔵書管理システムは資料の登録と在庫確認に軸足があり、誰に貸しているかという利用者側の記録は簡易な場合があります。図書館システムは、そこに利用者管理、予約と督促、相互貸借、法定の統計までを含みます。企業内の図書室で貸出が社内の少人数に限られるなら蔵書管理の範囲で足りることもあり、まず自館が予約と督促を運用するかどうかで切り分けてください。蔵書管理の範囲で足りる場合の進め方は図書管理システムとは？無料ツールと表計算の限界で整理しています。

OPACだけを新しくすることはできますか？

できます。業務系とOPACは同じ目録データを共有しつつ層としては分かれているため、検索画面とスマートフォン対応だけを先に刷新する進め方は成立します。条件は、業務系が目録データを外部へ渡す口を持っていることです。旧システムがデータ出力に制約を抱えている場合は、その口を作る改修が先に必要になり、費用の内訳が変わります。

電子図書館は同じシステムで扱えますか？

紙の資料を扱う図書館システムと電子書籍の貸出サービスは、多くの場合それぞれ別の事業者が提供します。同じ画面で完結させたいなら、利用者IDの共通化と検索結果の横断表示という二つの連携をそれぞれ設計します。電子出版制作・流通協議会の集計では2026年7月1日現在で613自治体が実施しており、二つが併走する前提に立った設計が現実的です。

小規模な企業内図書室でも導入する価値はありますか？

蔵書が数千点を超え、貸出の行き先が分からなくなる場面が出ているなら、価値は出ます。判断の目安は冊数そのものより、探す手間と紛失の頻度です。ただし小規模な館ではパッケージの想定利用者数がかみ合わず、ライセンスの下限が過剰になる場合があります。そのときは自社の会員基盤に貸出機能を足す形のほうが、費用と権限設計の両面で収まります。無料ツールや表計算のままで足りるかどうかの線引きは図書管理システムへ切り替える判断基準で示しています。

移行するとき、最初に確認すべきことは何ですか？

旧システムからどの形式でデータを出せるか、そして書誌・所蔵・個体それぞれが何件あるかの二点です。出力形式が限られていると移行の作業量が跳ね上がり、三層の件数が不明だと見積りの前提が置けません。既存ベンダーへの出力依頼には時間がかかることもあるため、候補製品を絞るより先に着手してください。

関連記事

• 業務システムとは：種類・基幹システムとの違いと、開発・導入形態の選び方を整理
• 校務支援システムとは：小中高の機能範囲・共同調達の仕組みと調達方式の判断基準
• 学務システムとは：大学・専門学校の履修・成績・学籍の機能範囲と導入判断
• 塾管理システムとは：民間学習塾の機能・費用と、パッケージか自社開発かの判断基準