図書館管理システム開発の完全ガイド

図書館管理システムは、資料・利用者・貸出・返却・予約・蔵書点検を一元管理し、司書の業務と住民・学生の利用体験をつなぐ業務基盤です。

図書館のシステム更改では、機能の多さだけでなく、公共・学校・大学など館種の違い、既存データの移行、IC機器や電子図書館との連携、個人情報の扱い、障害時の業務継続まで考える必要があります。本記事では、図書館管理システムの全体像、種類、主な機能、開発・導入の進め方、2026年時点の費用相場、開発会社・サービスの選び方、セキュリティ、FAQまでをまとめて解説します。

▼関連記事一覧
・図書館管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・図書館管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・図書館管理システム開発の見積相場や費用/コスト/値段について
・図書館管理システム開発の発注/外注/依頼/委託方法について

図書館管理システムとは何ですか？全体像を解説します

図書館管理システムとは、図書・雑誌・視聴覚資料・電子資料などの情報と、利用者の登録、貸出、返却、予約、統計をまとめて扱うシステムです。単に蔵書を検索する仕組みではなく、選書や購入、受入、配架、蔵書点検、除籍、レファレンス、館間搬送までを支える業務基盤です。利用者向けのOPACやマイページと職員向けの業務画面を同じデータ基盤につなぐことで、窓口とWebの情報を一致させられます。

資料側では、ISBN、書誌、著者、分類、所蔵館、請求記号、配置場所、状態、購入日、除籍日などを管理します。MARC形式の書誌データや外部の書誌情報を取り込む場合も、既存の書誌と重複しないルールを決めます。利用者側では、氏名、連絡先、利用者区分、登録期限、利用停止、予約受取館などを扱いますが、貸出履歴や検索履歴をいつまで個人と結びつけるかは別途定義する必要があります。

公共図書館では、複数館の所蔵を横断検索し、予約した資料を別の館で受け取る運用が重要です。学校図書館では児童生徒・教職員の区分や学年更新、大学・専門図書館では雑誌、ILL、機関リポジトリ、研究者向け検索が重視されます。同じ「図書館管理システム」でも、扱う資料と利用者、業務の例外が異なるため、館種を明確にして要件を整理します。

基本構成は、職員向け業務画面、利用者向けOPACやマイページ、資料・利用者データベース、認証・権限管理、帳票・統計、外部連携APIで成り立ちます。窓口端末やハンディターミナル、バーコードリーダー、ICタグ、自動貸出機、返却ポストなどの機器もシステムの一部として動きます。スマートフォンの利用者バーコード、予約本受取ロッカー、電子図書館、メールや自治体サイトとの連携を追加すると、ネットワークと認証の設計も広がります。

公共系では、館内の業務ネットワーク、自治体のネットワーク、住民向けインターネット公開領域をどのように分離・連携するかが重要です。最初に、館数、蔵書数、利用者数、年間貸出件数、同時アクセス数、機器台数、既存データの品質、外部連携先を一覧にします。これがないまま製品の機能表だけを比較すると、導入後に必要な連携費用や機器費用が追加されやすくなります。

図書館管理システムの種類と導入方式を比較します

図書館管理システムの導入方式は、標準パッケージ、クラウド型サービス、オンプレミス、既存製品を基盤にした追加開発、フルスクラッチ開発に分けて考えられます。優れた方式を一つに決めるのではなく、館種、規模、既存機器、独自運用、情報セキュリティ方針、将来の更新体制を基準に選びます。標準機能に業務を合わせられる部分が多いほど、導入期間と保守負担を抑えやすくなります。

標準パッケージには、書誌・所蔵管理、利用者登録、貸出・返却、予約、延滞、蔵書点検、統計、OPACなど、図書館で頻繁に使う機能が組み込まれています。導入実績のある業務フローを使えるため、ゼロから仕様を作るよりも要件定義を短くしやすく、制度変更やOS更新への対応も計画しやすい方式です。複数館を同じルールで運用したい公共図書館にも向いています。

一方で、自館独自の貸出ルールや特殊な資料区分をすべて個別改修すると、バージョンアップのたびに追加費用が発生します。標準機能で対応できること、設定変更で対応できること、業務を変えられないため追加開発が必要なことを分けます。デモでは通常の貸出だけでなく、予約取消、紛失、弁償、館間搬送、除籍、利用停止の解除まで確認します。

クラウド型は、提供者の環境にあるサーバーへインターネット経由で接続して利用する方式です。サーバーの保守、バックアップ、監視、更新作業を自館で抱えずに済み、複数館や在宅の管理拠点から同じデータを利用しやすい点がメリットです。2026年に公開された松茂町の更新仕様書でも、図書館システムをクラウド形式で構築することが要件に含まれています（出典: 松茂町立図書館システム等更新業務仕様書、2026年）。

ただし、クラウドだから安全と決めつけてはいけません。データの保管場所、通信の暗号化、管理者権限、多要素認証、バックアップの世代数、障害時の復旧時間、契約終了時の返却形式を確認します。自治体のネットワーク制約や館内機器との接続がある場合は、平常時だけでなく回線断時の貸出・返却が可能かも検証します。

既存パッケージを基盤にした追加開発は、標準機能を活かしながら独自の帳票、予約ルール、自治体サイト連携、学校や大学の認証連携を補う方法です。標準機能を再実装しないため、フルスクラッチよりも初期のリスクを抑えやすい一方、追加部分がアップデートの妨げにならない設計が必要です。APIや設定項目で拡張できる範囲を先に確認します。

フルスクラッチ開発は、既存製品では扱えない業務や複雑な連携を自由に設計できる方式です。しかし、書誌、貸出、予約、統計、権限、帳票、障害対応などの標準機能を一から作ることになり、法令・OS・ブラウザ・機器仕様の変化にも継続対応しなければなりません。独自性が本当に必要な領域だけを個別開発し、一般的な機能は標準化する判断が現実的です。

図書館管理システムの主な機能を整理します

機能一覧を比較するときは、機能名が存在するかではなく、実際の業務シナリオを最初から最後まで処理できるかを確認します。利用者登録から貸出、返却、予約、通知、統計までを同じ利用者IDで追えるか、資料の受入から配架、点検、除籍までの履歴が残るかをデモで確認します。館種ごとの例外処理と権限の違いも評価対象にします。

資料管理では、書誌情報、所蔵館、配置場所、請求記号、資料区分、状態、利用制限を登録します。選書、購入依頼、発注、納品、検収、装備、配架、移管、除籍までの進捗を記録できると、紙台帳や表計算への転記を減らせます。雑誌や継続刊行物は号単位の受入、欠号、合冊、寄贈資料の扱いがあるため、単行本だけを前提にしないことが重要です。

書誌データの取り込みでは、ISBNの重複、版違い、同一タイトルの表記ゆれ、視聴覚資料の媒体差を確認します。国立国会図書館などの書誌データを利用する場合も、取り込み後の確認者と修正権限を決めます。蔵書点検では、ハンディターミナルやICタグで読み取った結果を所蔵データと照合し、不明本、別置、貸出中、読み取り漏れを一覧化できるかを確認します。

閲覧管理では、利用者登録、利用者カード、貸出、返却、更新、延滞、利用停止、予約、リクエスト、予約本の受取館、メール通知を扱います。公共図書館では、所蔵館と受取館が異なる予約、複数館をまたぐ搬送、予約順位の変更、休館日を考慮した取り置き期限があるため、標準的な貸出テストだけでは不十分です。

OPACやマイページでは、キーワード検索、著者・分類・出版年による絞り込み、書影表示、所蔵状況、予約、貸出状況、延長、通知設定を提供します。スマートフォンで利用者バーコードを表示できる場合は、端末紛失時の停止や本人確認も要件に含めます。電子図書館や音声資料を扱う場合は、紙の所蔵情報と電子資料の利用権を同じ検索画面でどう見せるかを設計します。

職員向けには、レファレンス記録、選書、発注、統計、帳票、蔵書点検、利用者対応履歴、休館日設定、マスタ管理などが必要です。統計では、貸出冊数や予約件数だけでなく、館別、資料区分、利用者区分、時間帯、電子資料の利用状況を集計できると、サービス改善に使いやすくなります。帳票の項目や出力形式が自治体・学校・大学の報告要件に合うかを確認します。

権限は、館長、司書、窓口担当、選書担当、システム管理者などの役割に加えて、館、部署、資料区分、操作種別で分けます。閲覧と編集、CSV出力と削除、設定変更と承認を同じ人に集中させないことが基本です。誰がいつ利用者情報を閲覧・変更・出力したかを操作ログで追跡できるようにし、ログの保存期間と確認担当も決めておきます。

図書館管理システム開発・導入の進め方

導入は、製品や開発会社を先に決めるのではなく、現状調査、要件定義、提案比較、設計、データ移行、テスト、教育、切替、運用評価の順に進めます。公共図書館では自治体の予算・調達スケジュール、学校では年度更新、大学では学期や研究活動を考慮して、稼働時期から逆算します。旧システムの契約終了日と新システムの稼働日を別々に考えないことが大切です。

最初に、資料の登録から購入、受入、配架、貸出、返却、予約、搬送、点検、除籍までを業務フローにします。利用者登録、利用停止、延滞、弁償、予約取消、電子資料の利用、レファレンスなど、例外処理も書き出します。各工程の担当者、入力項目、承認者、期限、帳票、連携先、手作業を整理すると、導入効果を測る基準値も作れます。

データの棚卸しでは、書誌、所蔵、利用者、貸出、予約、権限、通知設定、統計のうち何を移すかを決めます。既存データの重複、表記ゆれ、欠損、古い利用者情報、不要な貸出履歴を確認し、移行前に削除・匿名化のルールを合意します。端末、バーコード、ICタグ、ハンディターミナル、プリンター、ネットワーク、メール配信の構成も図にします。

提案依頼書では、館種、館数、蔵書数、利用者数、現行機器、希望稼働日、必須機能、連携先、予算の考え方、保守条件を明記します。候補先には同じシナリオでデモを依頼し、通常の貸出だけでなく、データ移行、複数館予約、障害時のオフライン処理、権限変更、バックアップ復元まで説明してもらいます。価格だけでなく、提案に含まれる作業と含まれない作業を比較します。

移行設計では、旧システムからの抽出、データ変換、検証、再移行、本番切替の責任者を決めます。2026年の松茂町の仕様書では、蔵書・書誌・利用者・貸出・予約を移行対象とし、テスト用と本番用に2回以上データを抽出すること、移行管理者を置くこと、移行不備が判明した場合の再対応を求めています（出典: 松茂町立図書館システム等更新業務仕様書、2026年）。このように、移行を「発注者が用意するデータ」とだけ書かず、作業範囲と検収条件まで明文化します。

テストでは、機能、連携、データ、権限、負荷、セキュリティ、バックアップ復元を確認します。利用者登録から貸出、返却、予約、通知、統計までを実データに近い条件で通し、複数館の搬送や休館日、延滞、利用停止、資料紛失も加えます。移行後の件数、書誌と所蔵の紐付け、予約の状態、利用者区分を旧システムの抽出データと照合します。

本稼働直後に回線やサーバーが止まっても、窓口業務を継続できるようにします。2026年の更新仕様書には、障害時にローカル端末やハンディターミナルで貸出・返却を継続し、復旧後にデータを反映できる要件が示されています（出典: 松茂町立図書館システム等更新業務仕様書、2026年）。切替当日の連絡網、手作業の記録用紙、復旧後の二重登録防止、職員研修まで含めてリリース判定を行います。

図書館管理システムの進め方を、予算化から本稼働後の定着まで詳しく確認したい場合は、要件定義の進め方、関係者の役割、テスト項目を別の進め方記事で整理する予定です。現時点では、まず本記事の要件整理と移行・障害対応の観点を使って、候補サービスから具体的な提案を引き出します。

図書館管理システムの費用相場とコストの内訳

図書館管理システムの料金は、館数、蔵書数、利用者数、端末・IC機器、データ移行、外部連携、保守の有無で大きく変わります。製品の公開定価だけで比較できる案件は少ないため、以下の金額は公開調達の実績と機能構成から整理した2026年時点の目安です。推定レンジと実際の公募・入札金額を分けて見ることが重要です。

小規模な学校・単館が標準パッケージやクラウドを導入する場合は、初期100万〜500万円、年額50万〜300万円程度が一つの推定目安です。小規模自治体の公共図書館更改は1,000万〜3,000万円程度、複数館を持つ中規模自治体は3,000万〜8,000万円程度を想定します。いずれも製品の定価ではなく、移行、機器、設定、研修、保守を含む範囲によって変わる推定です。

公開調達の実例では、松茂町が2026年に実施した図書館システム等更新業務の提案上限額を、税込3,850万円としています。履行期間は契約締結日の翌日から2027年1月31日までで、システムだけでなく機器、データ移行、ホームページなどの仕様も関係します（出典: 松茂町、2026年）。一方、札幌市の2025年調達は41図書施設の機器・ソフトウェア借受で、落札金額は税込月額6,456,868円でした。60か月単純計算では約3億8,741万円ですが、これは開発費だけでなく、機器・ソフトウェア・保守などを含む大規模調達の例です（出典: 札幌市、2025年）。

見積書では、要件定義・設計、ライセンスまたはSaaS利用料、サーバー・ネットワーク、端末・ICタグ・自動貸出機、データクレンジングと移行、外部API連携、テスト、研修、導入支援、監視・バックアップ・保守を分けて記載してもらいます。移行元からのデータ抽出費、機器の撤去費、メール配信、電子図書館連携、追加帳票、現地作業費が別建てになっていないかを確認します。

追加費用が発生しやすいのは、現行データの欠損や重複が多い場合、館ごとに運用ルールが異なる場合、旧機器との互換性が不足する場合、独自帳票や自治体サイト・認証・電子資料との連携を追加する場合です。見積依頼時に、想定件数、端末台数、連携先、移行対象、研修回数、保守時間帯をそろえると、候補間の比較がしやすくなります。

クラウドは初期費用が低く見えても、利用者数やデータ容量に応じた月額、API利用料、電子資料のライセンス、機器費、現地支援費が積み上がります。オンプレミスは導入時のサーバー費や構築費に加え、更新、冗長化、バックアップ、災害対策、監視の費用を自館側で負担します。パッケージは保守料、バージョンアップ、追加ライセンス、サポート時間を確認します。

5年TCOを試算するときは、初期費用、月額・年額、機器のリース、通信、保守、職員研修、データ移行、契約終了時のデータ返却・消去、次回更改への備えを合計します。故障時の代替機、時間外対応、現地派遣、災害時の復旧費も条件に入れます。安い見積もりを選ぶのではなく、必要な業務水準を維持できる費用かを判断します。

図書館管理システムの開発会社・ベンダーの選び方

選定では、知名度や機能数だけでなく、自館と近い館種・規模での実績、データ移行の責任範囲、司書業務への理解、機器と外部サービスの連携力、障害時の支援体制を確認します。提案書の見た目より、導入後に誰がどの作業を担当し、制度変更や機器故障が起きたときにどの窓口が解決するかを比較することが大切です。

公共、学校、大学、専門図書館では、必要な資料区分、利用者、権限、連携先が異なります。候補先には、同じ館種での導入件数だけでなく、館数、蔵書数、利用者数、年間貸出件数、移行対象、稼働年数を確認します。導入実績が多くても、同規模の複数館運用や大学のILLなど、自館が必要とする業務に対応しているとは限りません。

提案担当と本稼働後の運用担当が同じか、司書業務を理解する担当者がいるか、問い合わせ窓口が一本化されているかも確認します。障害時の一次受付、二次対応、現地派遣、復旧目標、代替運用を体制図で示してもらいます。担当者の経験に依存せず、設計書、操作手順、データ定義、連携仕様が納品されるかも評価します。

デモでは、利用者登録、資料登録、貸出、返却、予約、他館受取、延滞、蔵書点検、統計、権限変更、障害復旧を同じ順番で実演してもらいます。通常ケースだけではなく、利用者がカードを紛失した場合、資料が別館にある場合、予約を取り消す場合、誤登録を訂正する場合、通信が一時的に切れた場合も確認します。画面の操作数、エラー表示、取消方法、履歴の残り方をメモします。

RFPや質問票には、MARCやAPIの対応、IC機器の互換性、スマートフォン利用者証、電子資料、認証、メール、バックアップ、ログ、データ抽出、契約終了時の返却形式を含めます。提案価格は初期、月額、機器、移行、連携、研修、保守、オプションに分け、前提条件と上限を明記します。必須要件、加点要件、将来検討に分類すると、機能数の競争に偏りにくくなります。

契約では、稼働時間、計画停止の通知、障害の重要度、受付時間、復旧目標、バックアップ、セキュリティ事故の報告、再委託、データ保管場所、監査、個人情報の取扱いを確認します。クラウド利用では、データの所有者が図書館であること、契約終了時に標準形式で全データを返却できること、返却後に確実に削除した証明を受けられることを明文化します。

保守費用に含まれる問い合わせ、設定変更、法改正・OS更新、機器交換、現地作業、操作研修の回数も確認します。安価な保守契約でも、休日や夜間の障害対応、複数館の現地対応、電子資料や外部認証の切り分けが対象外なら、実際の運用費が膨らみます。提案内容と契約書、SLA、仕様書の間に相違がないかを最終確認します。

▶ 詳細はこちら：図書館管理システム開発でおすすめの開発会社/ベンダー6選と選び方

図書館管理システムのセキュリティと2026年の最新動向

図書館の個人情報は、住所や連絡先だけでなく、貸出・予約・調査相談などの利用情報を含みます。便利なマイページ、共用カード、スマートフォン認証、レコメンド、生成AI検索を追加するほど、収集する情報と連携先が増えます。機能を導入する前に、何のために必要か、誰が見られるか、いつ削除するか、利用者へどう説明するかを決めます。

貸出や予約が終了した後も個人情報と利用情報を長く保持し続ける必要があるかを検討します。統計やサービス改善に使う場合は、個人を識別できない形にする時期、削除・匿名化の方法、復元できるバックアップの扱いを決めます。日本図書館協会のプライバシー保護ガイドラインは、クラウド利用時の守秘義務、図書館によるデータ所有、通信の暗号化、第三者提供の制限などを確認事項として示しています（出典: 公益社団法人日本図書館協会、2025年更新ページ）。

マイナンバーカードや学生証・職員証を図書館カードとして使う場合は、本人確認の利便性だけでなく情報共有の範囲を確認します。共用カードを希望しない利用者が専用カードを選べるか、本人の同意や説明をどう残すか、認証サービス側にどの情報が渡るかを設計します。権限の最小化、管理者操作の多要素認証、定期監査、職員研修、事故時の報告手順もシステム要件に含めます。

クラウドでは、稼働率だけでなく、障害を検知してから通知する時間、復旧目標、復旧時点、バックアップの保管場所、復元テストの頻度を確認します。館内回線が止まった場合に、貸出・返却・蔵書点検を一時的に継続できるか、復旧後に二重登録や時刻の不整合が起きないかを試験します。停電、災害、ランサムウェア、認証基盤の停止を想定した訓練も必要です。

札幌市の2025年調達では、41図書施設で使う機器・ソフトウェアを対象に、既存システムとの連携や導入機器の動作確認が調達条件に含まれていました（出典: 札幌市図書館システム機器借受仕様書、2025年）。このような大規模案件に限らず、既存機器や別ネットワークとの責任分界を図面と試験項目で確認することが、安定稼働につながります。

生成AIによる自然文検索、蔵書点検の支援、レコメンド、読書相談の補助は、業務時間や検索体験を改善する可能性があります。しかし、誤った書誌情報や存在しない資料を案内する、特定の読書傾向を過度に推測する、回答の根拠を説明できないといったリスクもあります。導入前に、対象業務、正解率や再現率などの評価方法、司書による確認、誤回答の訂正、ログの保持、学習利用の可否を決めます。

デジタル庁の2026年7月更新ページでは、図書館分野のマイナンバーカード活用事例として、電子利用申請やWeb利用者登録などが掲載されています（出典: デジタル庁、2026年）。ただし、掲載事例がそのまま自館へ適用できるとは限りません。本人確認が必要な手続き、取得する属性、利用者の選択肢、既存カードとの併用、自治体のセキュリティ方針を整理し、費用対効果を小さな実証で確かめます。

図書館管理システムに関するよくある質問（FAQ）

図書館管理システムの導入前には、費用、既存データ、クラウドの安全性、AI、補助制度などについて質問が集まります。ここでは、提案依頼や庁内・学内説明で確認されやすい質問に、判断のポイントを直接回答します。

クラウドであることだけで安全とは言えませんが、適切な設計と契約を行えば、バックアップや監視を含めて安定した運用を実現しやすくなります。データの保管場所、暗号化、アクセス権限、多要素認証、復旧目標、監査、第三者提供、契約終了時のデータ返却を確認し、回線断やサービス停止時の代替運用も試験します。

移行できますが、すべてのデータをそのまま移せるとは限りません。書誌・所蔵・利用者・貸出・予約などの対象を決め、重複、欠損、表記ゆれ、古い履歴、不要な個人情報を整理してから、サンプル移行と全件移行を行います。移行元からの抽出費、変換、検証、再移行、本番切替の責任を見積書と契約書に明記します。

必須ではありません。検索語の入力支援、蔵書点検、レファレンス補助など、解決したい課題と評価指標が明確な場合に、小さく実証してから導入を判断します。誤案内を司書が確認できること、学習に読書履歴を使うかを選べること、利用者への説明と削除ができることを条件にします。

一律の年数で決めるのではなく、OSやブラウザのサポート期限、機器の保守終了、セキュリティリスク、制度変更、利用者数や館数の変化、データ連携の限界を基準に判断します。一般的には契約期間や機器更新の節目に合わせて5年前後の総額を見直しますが、サポート終了が迫っている場合は早めに移行計画を始めます。契約終了時のデータ返却を前提に、次回更改の選択肢を残すことが重要です。

まとめ

図書館管理システムは、蔵書を検索するだけの仕組みではなく、資料のライフサイクル、利用者サービス、館内業務、館間連携、統計、職員の権限を支える基盤です。公共・学校・大学では必要な機能とデータの扱いが異なるため、館種と規模を起点に、標準パッケージ、クラウド、追加開発、スクラッチの範囲を判断します。

成功のポイントは、現状業務とデータを先に棚卸しし、移行対象・機器・連携・障害時の継続方法まで要件に含めることです。費用は初期価格だけでなく、移行、機器、保守、バックアップ、連携、契約終了時の返却を含む5年TCOで比較します。さらに、読書・貸出・予約に関わるプライバシーを守り、AIやデジタル認証は目的と検証方法を明確にしてから導入します。

▼関連記事一覧
・図書館管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・図書館管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・図書館管理システム開発の見積相場や費用/コスト/値段について
・図書館管理システム開発の発注/外注/依頼/委託方法について