図書館管理システムの導入は、要件整理から定着までの6つのフェーズを順に進めると、業務改善につながります。
システムの全体像は、図書館管理システム開発の完全ガイドにもまとめています。
▼全体ガイドの記事
・図書館管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
図書館管理システム開発の全体像
図書館管理システムは、資料情報と利用者情報を管理する仕組みです。貸出・返却、予約、蔵書点検、統計も、同じシステムでまとめて扱います。職員向けの画面と利用者向けのOPACをつなぐ、業務の土台にあたります。
開発や更改では、画面を使いやすくするだけでなく、図書館のルールを正しくデータとして表せるかが問われます。さらに、障害が起きても貸出・返却を止めない運用まで設計に含めます。
最初の段階では、「何を作るか」に加えて、どの業務を誰がどの情報で改善するかを決めます。改善後の状態も具体的に描いておくと、後の工程で比べやすくなります。
資料管理と利用者サービスの一体的な検討
資料管理では、ISBNや書誌、著者、分類を扱います。所蔵館、配置場所、状態も管理対象です。さらに、購入、受入、除籍の情報も管理します。
利用者管理では、登録、貸出、返却、延滞、更新を扱います。予約、リクエスト、通知、利用者区分も対象です。
館種ごとに重視する業務は異なります。公共図書館では複数館の横断検索と別館受け取りが中心です。一方で、学校図書館では児童生徒の学年更新や教職員区分が重視されます。大学・専門図書館では、雑誌、ILL、機関リポジトリとの連携が求められます。
利用者向け機能は、OPAC、マイページ、スマートフォン用の利用者バーコード、メール通知が候補です。電子図書館や座席予約も検討できます。
機能を増やすほど、認証、アクセシビリティ、個人情報、問い合わせ対応が複雑になります。導入目的を測れる言葉に置き換えてから、機能を選びます。
- 予約件数：予約の受付を増やす。
- 登録時間：窓口での登録にかかる時間の短縮。
- 点検負担：蔵書点検の手間の軽減。
パッケージ・クラウド・スクラッチの比較
導入方式は、標準パッケージ、クラウド型サービス、オンプレミス、既存パッケージを基盤にした追加開発、フルスクラッチの順に比べると、違いが見えてきます。
図書館には資料登録、貸出、予約、帳票、権限などの共通業務があります。標準機能で対応できる範囲が広いほど、開発費と将来の保守負担を抑えられます。
独自の予約ルールや自治体固有の連携がある場合は、パッケージのAPIや追加画面で対応できるかを先に確認します。
- クラウド：サーバー更新、バックアップ、災害対策を任せやすい方式。
- オンプレミス：既存のネットワークや機器と組み合わせやすい方式。
- フルスクラッチ：独自業務に合わせやすい一方で、保守の負担に注意が必要。
クラウドの月額は、利用者数、データ容量、連携オプション、通信回線で変わります。一方、オンプレミスでは、機器の更新、冗長化、復旧手順を自分たちで維持します。
フルスクラッチでは、標準機能も作り直す必要があります。担当者が退職したあとも保守を続けられるかが、リスクになります。
選定会議では、初期費用だけで決めず、5年から10年の総保有コストで比べます。
図書館管理システム開発の進め方（6フェーズ）
図書館管理システムの開発は、6つのフェーズに分けると抜け漏れに気づきやすくなります。ただし、前のフェーズへ戻る場合もあります。
- 要件の整理
- 製品と開発会社の選定
- 設計・開発
- テスト
- 新システムの稼働
- 運用の定着
各段階で、何を完成させるかと誰が決めるかを先に定めておくと、現場の要望が際限なく膨らむのを防げます。
フェーズ1：要件整理による業務とデータの現状の洗い出し
まず、館数、蔵書数、利用者数の規模を把握します。年間貸出件数や予約件数、職員数などの数字も、あわせて確認します。窓口数や端末台数も含め、ICタグや自動貸出機の有無も確かめます。
業務の流れは、選書から配架までと、貸出から搬送までを図にします。蔵書点検、除籍、統計も図に含め、担当者と例外処理も書き込みます。
司書、窓口職員、情報政策担当、管理者、利用者から、別々に話を聞きます。同じ業務でも立場によって認識が違うことがあるため、その差を早い段階で洗い出します。
要件は、「必須」「できれば欲しい」「運用で代替できる」の3つに分けます。貸出・返却、予約、利用者登録は、必須になりやすい機能です。資料検索、権限、帳票も、必須候補になりやすい機能です。
バックアップや障害時の手作業も、必須要件に含めます。一方で、AIレコメンド、読書通帳、ロッカー、座席予約は、目的と効果を見て優先順位を付けます。
要件整理では、現行の機能から移行データまでを、次のとおり確認します。
- 現行機能：現在使っている機能の一覧
- 廃止作業：廃止したい作業の決定
- 継続帳票：継続したい帳票の選定
- 移行データ：移行対象データの範囲
移行範囲を決めたら、連携やセキュリティ、切替計画、予算の条件も続けて確かめます。
- 連携先：接続する相手先の一覧
- セキュリティ制約：求められる制約の把握
- 切替希望日：稼働を希望する日
- 予算上限：使える金額の上限
フェーズ2：同じシナリオによる製品と会社の比較
RFIやRFPでは、画面の見栄えだけで比べず、各社に同じ業務シナリオを渡します。公共図書館と大学図書館では、同じ導入館数でも必要な機能が異なります。
- 候補の条件：館種、館数、蔵書規模、移行経験、外部連携、保守体制。
- 実務シナリオ：資料登録、予約、別館搬送、返却後の通知を各社にデモしてもらう。
- 例外処理：利用停止者の貸出停止、蔵書点検での不明資料の特定。
- 技術・運用：操作ログや権限、API、MARC、IC機器への対応、データ返却と復旧時間の質問。
- 評価方法：価格、機能、移行、運用、提案体制に配点し、知名度だけで選ばない。
デジタル庁が2026年7月に更新した導入事例では、NECネクサソリューションズのLiCS-Re for SaaSの導入数は約350団体です。富士通JapanのiLisシリーズは、約640団体が導入自治体として掲載されています。
ただし、この数字は候補を知る材料にすぎません。自館と同規模の実績や担当体制まで確認します（出典: デジタル庁、2026年）。
フェーズ3：設計・開発での標準機能と追加開発の切り分け
設計・開発では、標準機能と追加対応を分け、移行の品質と責任の範囲をはっきりさせます。特に、追加開発は安易に増やさないことが大切です。
- 設計項目：画面や権限、データ、帳票、API、機器、ネットワークの詳細化。
- 追加開発：標準機能、設定、個別開発、運用変更の区分。
- 移行準備：書誌、所蔵、利用者、予約、権限、通知設定の対応付け。
- 移行検証：少なくとも一度リハーサルして、件数や検索、貸出可否、予約、帳票、権限を確かめる。
- 責任分担：発注者、現行ベンダー、新ベンダーの役割を文書にまとめる。
移行前には、重複書誌、欠損した請求記号、旧字体、無効な利用者、過去の予約、文字コードの違いを確認します。そのうえで、データを整える方針を決めます。
独自帳票は、開発で作り込まず、出力データをBIや表計算で加工する方法もあります。将来のバージョンアップの影響を受けにくい場合があります。
フェーズ4：通常操作と異常時の両方のテスト
テストは、機能、連携、データ、権限の4つに分けて進めます。性能、セキュリティ、運用も対象です。
通常の貸出・返却・予約に加えて、次のような異常時も試します。
- 予約・休館：同じ資料への予約の集中、延滞中の更新、休館日の扱い
- 複数館・機器：受取館の変更、ICタグの読み取り失敗
- 障害・権限：回線断、停電、職員アカウントの権限違い
利用者向けのOPACは、スマートフォンやキーボード操作、文字サイズの変更、読み上げに対応できるかを確かめます。検索語の揺れも試験します。
テストデータに、本番の氏名や貸出履歴をそのまま使うことは避けます。バックアップの復元、ログの閲覧権限、退職者アカウントの停止も確認します。
委託先のアクセス、データの暗号化、脆弱性対応の手順も確認します。日本図書館協会は2025年6月に更新したガイドラインを公表しています。
同ガイドラインは、デジタル環境で図書館利用の秘密を守る取り組みを示しています。そのため、テスト計画にも図書館固有の観点を含めます（出典: 公益社団法人日本図書館協会、2025年）。
フェーズ5：稼働での切替計画と手作業の代替手段
稼働日には、切替時刻と障害時の代替運用を決めておきます。休館日に切り替えても、開館直後は貸出・返却や予約が集中することがあります。そのため、切替前後の段取りは次のとおり決めます。
- 切替時刻：移行締切、旧システムの参照期限、新システムの開始、機器の設置
- 担当体制：時刻単位で決める職員の立会いと問い合わせ窓口
- 障害時：紙の貸出記録や仮受付で業務を続け、後から正しいデータに反映する方法
札幌市は2025年、41図書施設のシステム用機器とソフトウェアを5年間借り受けました。落札金額は月額6,456,868円で、60か月分を単純計算すると約3億8,741万円になります（出典: 札幌市、2025年）。
この案件は機器・ソフトウェアの賃貸借や保守条件を含むため、開発費だけの相場とは言えません。
施設数が多い場合は、切替の順序、機器の動作確認、技術員派遣の条件を、契約と計画に反映します。
フェーズ6：定着のための利用状況の把握と改善
稼働後の1か月から3か月は、ベンダー任せにせず、問い合わせを自分たちで分類します。分類すると、再研修と改修の優先順位が見えてきます。
- 問い合わせ：操作方法、仕様の誤解、移行の不備、未決定の運用、性能・連携の障害
- 利用指標：職員ごとの操作時間、予約の滞留、点検時間、問い合わせ数（導入前との比較）
- 運用定着：役割別マニュアル、実機研修、問い合わせ窓口、月次会議、更新確認
- 継続管理：権限の見直し、復元訓練、契約更新前のTCO確認
- AI機能：正確性、根拠表示、人の確認、履歴利用への同意と削除の決め方
KCCSは2025年5月、久喜市立図書館で生成AI蔵書検索の実証実験を開始したと公表しています（出典: 京セラコミュニケーションシステム、2026年確認）。
先端機能は、導入そのものを目的にせず、利用率や検索成功率の改善を検証してから広げます。
図書館管理システムの費用相場と期間
価格は、館数や蔵書数、利用者数などの規模によって変わります。加えて、機器、移行データ、連携、保守の範囲も価格を左右します。
製品の公開定価は少ないため、ここに示す金額は、公開調達の実績と業務システムの価格構造をもとにした記事用の推定レンジです。予算化では、同じ要件書で複数社から見積もりを取り、初期費用と5年分の運用費を分けて比べます。
規模別の初期費用の目安（推定100万円台から数億円）
初期費用の推定レンジは、館の規模と導入範囲によって異なります。規模ごとの目安は次のとおりで、学校・単館の目安は、標準パッケージやクラウドを導入する場合のものです。
- 学校・単館：初期推定100万〜500万円、年額推定50万〜300万円程度。
- 小規模自治体：推定1,000万〜3,000万円程度。
- 複数館・中規模：推定3,000万〜8,000万円程度。
- 大規模刷新：大規模自治体・大学や複数施設で、推定8,000万円から数億円。
小規模自治体の公共図書館の更改では、移行、OPAC、複数カウンター、周辺機器、研修、保守を含めた推定です。
複数館・中規模の場合は、館間搬送、ICタグ、セルフ貸出、自治体サイトや電子図書館との連携が含まれることがあります。
松茂町の2026年更新業務の履行期間は、契約締結日の翌日から2027年1月31日までです。提案上限額は税込3,850万円です（出典: 松茂町、2026年）。
単館や小規模自治体でも、移行、機器、導入支援、保守を含めると、数千万円規模になることがあります。
見積金額の開発費・機器費・移行費・保守費への分解
見積もりでは、費用を次の区分に分けて読みます。「一式」とある項目は、対象範囲や数量、作業回数、納品物、前提条件を確かめます。
- 開発・利用：要件定義、設計、ライセンス、SaaS利用料
- 機器・連携：サーバーやネットワーク、端末などの機器と、バーコード、ICタグ、自動貸出機、外部API
- 移行・導入：データのクレンジング、移行、テスト、研修
- 運用・保守：監視、バックアップ、保守
データ移行費が安く見えても、旧システムからの抽出、変換、検証、移行リハーサルが別料金の場合があります。
クラウドは初期のサーバー購入費を抑えやすい一方で、利用者数やデータ容量、電子書籍などのオプションが月額に加わります。SMS・メール、API、監視、サポートも、月額の対象になります。
オンプレミスでは、初期の機器費と更新費を負担します。電源や設置、バックアップ、災害対策も必要です。
初年度の費用だけでなく、契約期間中の利用料、機器更新、法令対応、追加開発、データ返却、契約終了時の消去証明まで含めて、5年TCOを計算します。
図書館管理システムの見積もりを取るポイント
見積もりの精度は、発注者が用意する情報の粒度で変わります。機能一覧だけでは各社の前提がそろわず、移行や研修を含まない見積もりも出てきます。
RFPには、業務フローや館種、規模、データ、連携の条件を記載します。機器やセキュリティ、稼働条件、保守、契約終了条件も、同じ資料に含めます。価格と前提は、同じ形式で回答してもらいます。
要件書に記載する業務・データ・性能・運用の前提
要件書には、対象館と対象外の館、資料種別、書誌・所蔵・利用者の件数を記載します。同時アクセスや年間の貸出・予約ピークも明記します。
接続する自治体サービス、MARCや外部書誌の形式、IC機器の台数も記載します。「予約できる」だけでなく、業務ルールを例として示します。
- 予約条件：予約上限、取り置き期限、受取館の変更を示す。
- 例外処理：休館日、通知の失敗、延滞中の扱いを示す。
- 性能条件：通常時と、新刊発売や予約開始時の集中を想定した条件。
セキュリティ要件では、認証、権限、管理者操作のログ、バックアップ頻度、復旧目標時間、データの保管場所を確認します。さらに、委託先のアクセスや脆弱性対応、返却形式、消去方法も決めます。
図書館の個人情報は、読書や調査の秘密に関わるもので、一般の顧客データとは性質が違います。そのため、履歴を分析する場合は、個人と結び付けて保持する期間と、切り離す時期を定めます。また、本人への説明や同意の有無、削除依頼の受付方法も定めます。
複数社の同条件での比較と安さの理由の確認
少なくとも複数社に同じ資料を渡し、次の点を比べます。
- 価格・機能：標準機能、追加開発、移行、導入期間、保守、障害対応の比較
- 導入実績：同規模・同館種の実績と、司書資格者や専門SEの有無
- 対応体制：受付時間、重大障害の連絡経路、担当者の専門性
- デモ内容：一本道の操作だけでなく、例外処理と管理者操作の実演
- 価格の前提：移行リハーサル、機器、保守時間、追加開発の単価
極端に安い見積もりは、標準機能だけを含む場合があります。移行リハーサルなし、機器の別調達、保守時間の限定といった条件も考えられます。追加開発の単価が高い場合もあります。
見積もりが高くても、データ整備や教育、冗長化、24時間365日の受付、復旧訓練を含んでいるなら、5年TCOでは妥当な場合があります。
そのため、価格差の理由を項目ごとに説明できる会社を選びます。高額機能の「対応可能」は、仕様書か見積条件に残しておきます。
見積もり段階での契約と移行のリスク対策
移行と契約終了時の条件を発注前にそろえ、後の追加費用や引き継ぎリスクを抑えます。
- 移行責任：抽出形式と費用、旧ベンダーの協力、新ベンダーの変換責任、失敗時の再実施条件
- 契約条件：納品物、検収、遅延、追加変更の承認、重要度別のSLA
- 情報管理：委託先と再委託、監査、データ返却、消去証明の扱い
- 引き継ぎ資料：対応機能の記録に加えて、標準データ、API、画面・帳票定義、アカウントの保管
- クラウド運用：復元方法、保管場所、世代、復旧テスト、終了時の移行支援費の確認
運用開始後にベンダーが変わることもあるため、情報は発注者側でも保管しておきます。将来の更改に備えて情報を残すことは、ベンダーロックインを下げる現実的な対策です。
図書館管理システム開発でよくある質問
費用や期間は規模と要件によって変わります。そのため、一般論ではなく、自館の業務とデータを前提にベンダーへ確認します。
図書館管理システムの開発・導入期間はどのくらいですか？
導入方式や規模によって、開発・導入期間の推定は異なります。
- 標準クラウド：設定と移行で推定3〜6か月。
- パッケージ更改：推定6〜12か月。
- 複数館・大規模連携：推定12〜24か月。
- フルスクラッチ：推定18〜36か月。
いずれも、公開された一律の標準期間ではありません。要件整理、データ移行、機器、テスト、研修を含めた、記事執筆用の推定です。
切替希望日から逆算する前に、移行リハーサルと利用者・職員テストの期間を先に確保します。
クラウド型の図書館管理システムでも安全ですか？
安全性は、クラウドかオンプレミスかという区分よりも、次の対策の中身で判断します。
- 基本対策：認証、権限、通信と保存時の暗号化、バックアップ、復旧時間の比較
- 運用管理：脆弱性対応、監査ログ、データ保管場所、委託先管理の確認
- 利用履歴：個人と結び付けて保持する期間と、目的終了後の匿名化・削除の方法
対策の中身が、自館の情報セキュリティポリシーに合っているかを確かめます。
Excelで管理している蔵書や利用者データも移行できますか？
Excelの蔵書や利用者のデータは、中身を点検し、新しいシステムの項目に対応させれば移行できる可能性があります。そのために行う作業は次の4つです。
- データ確認：列名、コード体系、重複・欠損、文字コード、有効期限、個人情報の点検
- 項目対応：一覧をそのまま取り込まず、資料、所蔵、利用者、権限を対応付ける
- 動作検証：テスト環境での検索、貸出、予約までの確認
- 履歴整理：目的のわからない古い履歴や不要な個人情報について、移行前の削除・匿名化の判断
生成AI検索やAI蔵書点検は最初から導入すべきですか？
最初から必須にしなくても構いません。まず、資料データの品質、検索ログの扱い、蔵書点検の現在の所要時間、職員が確認できる運用を整えます。
目的は、「自然な質問で検索できる」や「点検候補を絞る」などに限ります。誤った案内や不適切なレコメンドに備えて、人による確認と根拠表示を決めます。
利用履歴の利用目的と削除方法も定めます。実証で効果とリスクを測ってから、本番に広げます。
図書館管理システム開発の進め方まとめ
図書館管理システム開発は、要件整理から定着までの6つのフェーズで進めます。館種と規模に合う標準機能を見極めたうえで、既存データや機器、外部サービスとの連携を早い段階で確かめます。さらに、通常の操作だけでなく、障害時や個人情報の扱いも要件に含めます。
着手前の業務・データ・費用・体制の整理
最初に館数や蔵書数だけでなく、現場の業務フロー、移行対象、連携先、必須機能を整理します。予算、稼働希望日、意思決定者、運用担当者も、一枚にまとめます。
この資料をもとに複数社へ同じ質問をすれば、見積もりの前提と提案の違いを比べられます。
導入後まで責任を持てる体制の選定と段階的な改善
初期費用の安さだけでなく、移行、テスト、障害対応、研修、契約終了時のデータ返却を確認します。
稼働後は問い合わせと利用指標を見ながら、標準機能を活かして改善します。こうした改善が、職員と利用者の双方にとって使いやすいシステムにつながります。
- 費用：単館の標準導入から複数館・大規模刷新まで、推定100万円台から数億円まで幅があります。
- TCO：公開調達の案件範囲を確かめ、開発、機器、移行、研修、保守、データ返却を含む5年TCOで比べます。
- 着手：業務とデータの洗い出し、同じシナリオでの複数社への相談、実現可能な予算と導入計画の作成。
▼全体ガイドの記事
・図書館管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。