図書館管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

図書館管理システム開発は、蔵書を管理する機能を入れるだけではなく、要件整理から選定、設計開発、テスト、稼働、定着までを一つの業務改善プロジェクトとして進めることが成功の近道です。

公共・学校・大学など館種によって必要な機能は異なり、既存データの品質、複数館の連携、IC機器、電子図書館、個人情報の扱いも費用と期間を左右します。本記事では、図書館管理システムの導入・更改を6つのフェーズに分け、各段階で決めること、ベンダーへ確認すること、2026年時点の費用の見方、見積書のチェックリストまで実務目線で解説します。

▼全体ガイドの記事
・図書館管理システム開発の完全ガイド

図書館管理システム開発の全体像を把握します

図書館管理システムは、資料情報、利用者情報、貸出・返却、予約、蔵書点検、統計を一元管理し、職員向け画面と利用者向けOPACをつなぐ業務基盤です。開発や更改では、画面の使いやすさだけでなく、図書館のルールを正しくデータ化し、障害時にも貸出・返却を止めない運用まで設計します。最初に「何を作るか」ではなく、「どの業務を、誰が、どの情報を使って、どの状態まで改善するか」を決めることが重要です。

資料側では、ISBNや書誌、著者、分類、所蔵館、配置場所、状態、購入・受入・除籍を管理します。利用者側では、登録、貸出、返却、延滞、更新、予約、リクエスト、通知、利用者区分を扱います。公共図書館では、複数館の所蔵を横断検索して別の館で受け取る運用が中心になり、学校図書館では児童生徒の学年更新や教職員区分、大学・専門図書館では雑誌、ILL、機関リポジトリとの連携が重視されます。

利用者向けには、OPAC、マイページ、スマートフォンの利用者バーコード、メール通知、電子図書館、座席予約などが候補になります。ただし、機能を増やすほど認証、アクセシビリティ、個人情報、問い合わせ対応が複雑になります。導入目的を「予約件数を増やす」「窓口の登録時間を短縮する」「蔵書点検の負担を下げる」のように測れる言葉へ置き換えてから、必要な機能を選びます。

導入方式は、標準パッケージ、クラウド型サービス、オンプレミス、既存パッケージを基盤にした追加開発、フルスクラッチの順に比較すると判断しやすくなります。図書館には資料登録、貸出、予約、帳票、権限など共通業務が多いため、標準機能を使える範囲が広いほど、開発費と将来の保守負担を抑えやすいです。独自の予約ルールや自治体固有の連携がある場合は、パッケージのAPIや追加画面で対応できるかを先に確認します。

クラウドはサーバーの更新、バックアップ、災害対策を任せやすい一方、利用者数、データ容量、連携オプション、通信回線で月額が変わります。オンプレミスは既存ネットワークや機器と合わせやすい一方、機器更新、冗長化、復旧手順を自分たちで維持します。フルスクラッチは独自業務に合わせやすい反面、標準機能の再実装と担当者退職後の保守がリスクになります。選定会議では、初期費用ではなく5年から10年の総保有コストで比較します。

図書館管理システム開発の進め方を6フェーズで解説します

図書館管理システムの進め方は、(1)要件整理、(2)製品・開発会社の選定、(3)設計・開発、(4)テスト、(5)稼働、(6)定着の6フェーズに分けると、抜け漏れを見つけやすいです。実際には前のフェーズへ戻ることもありますが、各段階の成果物と意思決定者を決めておくことで、現場の要望が際限なく膨らむことを防げます。

最初に、館数、蔵書数、利用者数、年間貸出件数、予約件数、職員数、窓口数、端末台数、ICタグや自動貸出機の有無を整理します。次に、選書、発注、受入、装備、配架、貸出、返却、延滞、予約、搬送、蔵書点検、除籍、統計の各業務を、担当者と例外処理まで含めて図にします。司書、窓口職員、情報政策担当、管理者、利用者から別々にヒアリングし、同じ業務でも認識が違う部分を見える化します。

要件は「必須」「できれば欲しい」「運用で代替できる」に分けます。貸出・返却、予約、利用者登録、資料検索、権限、帳票、バックアップ、障害時の手作業は必須になりやすいです。一方、AIレコメンド、読書通帳、ロッカー、座席予約などは目的と効果を確認して優先順位を付けます。この段階のチェックリストは、現行機能一覧、廃止したい作業、継続したい帳票、移行対象データ、連携先、セキュリティ制約、切替希望日、予算上限の8項目です。

候補を選ぶときは、館種、館数、蔵書規模、データ移行の経験、外部連携、保守体制を軸に比較します。公共図書館と大学図書館では、同じ導入館数でも必要な機能が違います。デジタル庁が2026年7月に更新した導入事例では、図書館向けサービスとしてNECネクサソリューションズのLiCS-Re for SaaSは約350団体、富士通JapanのiLisシリーズは約640団体が導入自治体として掲載されています。数字は候補を知る材料であり、自館と同規模の実績や担当体制まで確認することが大切です（出典: デジタル庁、2026年）。

RFIやRFPでは、すべての会社へ同じ業務シナリオを渡します。例えば、資料を登録して予約を受け、別館から搬送し、返却後に予約者へ通知する流れ、利用停止者の貸出を止める流れ、蔵書点検で不明資料を特定する流れをデモしてもらいます。画面の見栄えだけでなく、例外処理、操作ログ、権限、API、MARC、IC機器、契約終了時のデータ返却、障害時の復旧時間を質問します。価格評価、機能評価、移行評価、運用評価、提案体制をあらかじめ配点化すると、知名度だけで決まりにくくなります。

契約後は、要件定義書をもとに画面、権限、データ項目、帳票、API、機器、ネットワークを詳細化します。ここで「パッケージ標準」「設定変更」「追加開発」「運用変更」の区分を決め、追加開発を安易に増やさないことが重要です。例えば、独自の帳票を残すために複雑な画面改修を行うより、出力データをBIや表計算で加工する方が、将来のバージョンアップに影響しない場合があります。

データ移行は、書誌、所蔵、利用者、予約、権限、通知設定を項目単位で対応付けます。重複書誌、欠損した請求記号、旧字体、無効な利用者、過去の予約、文字コードの違いを抽出し、移行前にクレンジング方針を決めます。移行リハーサルを少なくとも一度は行い、件数だけでなく、検索結果、貸出可否、予約状態、帳票、権限が業務上正しいかを確認します。移行の責任範囲を「発注者」「現行ベンダー」「新ベンダー」の3者で文書にすることも欠かせません。

テストは、機能、連携、データ、権限、性能、セキュリティ、運用の順に観点を分けます。貸出・返却・予約の正常系だけでなく、同じ資料へ予約が集中した場合、延滞中の更新、休館日、複数館の受取館変更、ICタグの読み取り失敗、回線断、停電、職員アカウントの権限違いも試験します。利用者向けOPACでは、スマートフォン、キーボード操作、文字サイズ変更、読み上げ、検索語の揺れも確認します。

個人情報を扱うため、テストデータには本番の氏名や貸出履歴をそのまま使いません。バックアップからの復元、ログの閲覧権限、退職者アカウントの停止、委託先のアクセス、データ暗号化、脆弱性対応の手順を確認します。日本図書館協会は2025年6月更新のプライバシー保護ガイドラインで、デジタル環境での図書館利用の秘密を守る具体的な取り組みを示しています。テスト計画には、法令や一般的な個人情報対策だけでなく、読書・調査の秘密を守る図書館固有の観点を入れます（出典: 公益社団法人日本図書館協会、2025年）。

稼働日は、データ移行の最終締切、旧システムの参照期限、新システムの利用開始、機器の設置、職員の立会い、問い合わせ窓口を時刻単位で決めます。休館日に切り替える場合でも、開館直後に貸出・返却や予約が集中する可能性があります。障害が起きた場合に、紙の貸出記録や仮受付で業務を継続し、後から正しいデータへ反映する手順を準備します。

公開調達の例では、札幌市が2025年に41図書施設の図書館システム用機器・ソフトウェアを5年間借り受ける契約を実施し、落札金額は月額6,456,868円でした。単純計算で60か月分は約3億8,741万円ですが、これは機器・ソフトウェアの賃貸借や保守条件を含む大規模案件で、開発費だけの相場ではありません。施設数が多いほど、切替順序、機器の動作確認、技術員の派遣条件を契約と計画へ落とし込む必要があります（出典: 札幌市、2025年）。

稼働後の1か月から3か月は、ベンダー任せにせず、現場から出た問い合わせを分類します。操作方法の質問、仕様の誤解、データ移行の不備、運用ルールの未決定、性能や連携の障害を分けると、再研修と改修の優先順位が見えます。職員ごとの操作時間、予約処理の滞留、蔵書点検に要した時間、利用者からの問い合わせ数など、導入前に決めた指標と比較します。

定着のチェックリストは、役割別マニュアル、短時間の実機研修、問い合わせの一次窓口、月次の改善会議、バージョンアップの確認、権限棚卸し、バックアップ復元訓練、契約更新前のTCO確認です。生成AI検索やレコメンドを追加する場合は、回答の正確性、根拠表示、人による確認、利用履歴を学習に使う場合の同意と削除を先に決めます。KCCSは2025年5月から久喜市立図書館で生成AI蔵書検索の実証実験を開始したと公表していますが、先端機能は導入すること自体ではなく、利用率や検索成功率の改善を検証してから広げます（出典: 京セラコミュニケーションシステム、2026年確認）。

図書館管理システムの費用相場と期間を確認します

図書館管理システムの価格は、館数、蔵書数、利用者数、機器、移行データ、連携、保守の範囲で大きく変わります。製品の公開定価が少ないため、以下の金額は公開調達実績と業務システムの価格構造から整理した記事用の推定レンジです。実際の予算化では、同じ要件書で複数社から見積もりを取り、初期費用と5年分の運用費を分けて比較します。

小規模な学校・単館が標準パッケージやクラウドを導入する場合、初期費用は推定100万〜500万円、年額は推定50万〜300万円程度が一つの目安です。小規模自治体の公共図書館の更改では、データ移行、OPAC、複数カウンター、周辺機器、研修、保守を含めて推定1,000万〜3,000万円程度です。複数館・中規模自治体では、館間搬送、ICタグ、セルフ貸出、自治体サイトや電子図書館との連携まで含めて推定3,000万〜8,000万円程度に上がる場合があります。

松茂町の2026年の図書館システム等更新業務では、履行期間を契約締結日の翌日から2027年1月31日までとし、提案上限額を税込3,850万円としています。これは単館・小規模自治体にも、システム本体だけでなく移行、機器、導入支援、保守などが含まれれば数千万円規模になり得ることを示す公開事例です。大規模自治体や大学の大規模刷新、複数施設の機器・ソフトウェア賃貸借では、推定8,000万円から数億円まで見込むケースがあります（出典: 松茂町、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の一覧をそのまま取り込むのではなく、資料、所蔵、利用者、権限などの項目を新システムのデータモデルへ対応付け、テスト環境で検索・貸出・予約まで検証します。利用目的が不明な古い履歴や不要な個人情報は、移行前に削除・匿名化の判断をします。

最初から必須にする必要はありません。まずは資料データの品質、検索ログの扱い、蔵書点検の現状時間、職員が確認できる運用を整え、AI導入の目的を「自然な質問で検索できる」「点検候補を絞る」などに限定します。誤った案内や不適切なレコメンドが起きた場合の人による確認、根拠表示、利用履歴の利用目的、削除方法を決め、実証で効果とリスクを測ってから本番展開します。

図書館管理システム開発の進め方まとめ

図書館管理システム開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで進めます。成功のポイントは、館種と規模に合う標準機能を見極め、既存データと機器・外部サービスの連携を早期に確認し、通常操作だけでなく障害時や個人情報の扱いまで要件化することです。

最初の一歩は、館数や蔵書数の確認だけで終わらせず、現場の業務フロー、移行対象、連携先、必須機能、予算、稼働希望日、意思決定者、運用担当者を一枚に整理することです。この資料をもとに複数社へ同じ質問を行うと、見積もりの前提と提案の違いを比較できます。

選定時は初期費用の安さだけでなく、データ移行、テスト、障害対応、研修、契約終了時のデータ返却まで確認します。稼働後は問い合わせと利用指標を見ながら、標準機能を活かして改善を続けることが、図書館職員と利用者の双方にとって使いやすいシステムにつながります。

費用は、単館の標準導入から複数館・大規模刷新まで幅があり、推定100万円台から数億円まで広がります。公開調達の金額は案件の範囲を確認して参考にし、開発、機器、移行、研修、保守、契約終了時のデータ返却を含む5年TCOで比較します。まずは現行業務とデータの棚卸しから始め、同じシナリオで複数社へ相談すると、実現可能な予算と導入計画を作りやすくなります。

▼全体ガイドの記事
・図書館管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。