図書館管理システム開発の発注/外注/依頼/委託方法について

図書館管理システムの発注・外注は、館種と規模に合うパッケージやクラウドを軸に要件を整理し、5年総額とデータ移行・保守まで比較して委託先を決める進め方が基本です。

図書館システムの更改では、貸出や返却の画面だけを比べても適切な発注先は決まりません。公共図書館、学校図書館、大学・専門図書館では必要な機能が異なり、蔵書データの移行、館間連携、OPAC、IC機器、電子図書館、個人情報保護、契約終了後のデータ返却まで含めて判断する必要があります。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定方法、見積書の比較ポイントを、実際の調達事例とともに解説します。

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

図書館管理システムを発注・外注する前に知る全体像

図書館管理システムは、資料を登録して貸し出すだけの仕組みではありません。資料、利用者、職員の業務、複数の館、自治体や大学の外部サービスをつなぎ、利用者が必要な資料へ到達するまでを支える業務基盤です。発注時には「何を作るか」だけでなく、「誰がどの業務を担い、どのデータをどの期間保有し、障害時にどうサービスを続けるか」まで決めます。

基本機能は、書誌・所蔵・除籍などの資料管理、利用者登録、貸出・返却・延滞・更新・予約、蔵書点検、選書・発注・受入、統計と帳票です。利用者向けにはOPAC、マイページ、予約通知、スマートフォン対応があり、公共図書館では複数館の横断検索、予約本の搬送、受取館の指定も重要になります。学校図書館では児童生徒と教職員の管理、大学・専門図書館では雑誌、ILL、研究資料、機関リポジトリとの連携が優先されやすいです。

公共図書館は、自治体の情報セキュリティポリシー、複数館の運用、住民向けWebサービス、LGWAN系ネットワークとの分離・連携を確認します。学校図書館は、学校間の連携や児童生徒の個人情報、限られた職員時間で運用できる操作性がポイントです。大学・専門図書館は、学術情報検索、電子ジャーナル、ILL、認証基盤、研究者向けサービスとの接続が評価軸になります。館種を明確にしないRFPは、ベンダーが想定する標準仕様と現場の期待がずれやすくなります。

図書館システムは、導入して終わる製品ではありません。OSやブラウザ、認証方式、外部API、法令、利用者端末が変わるため、保守とアップデートを何年続けられるかが重要です。初期見積が安くても、データ移行が別料金、機器更新が別契約、障害時の現地対応が有償、契約終了時のデータ抽出が高額という場合は、長期的な負担が増えます。初期費用、運用費、追加開発費、機器費、保守費を5年程度の総額で並べて比較します。

発注形態はどれを選ぶ？パッケージ・クラウド・スクラッチの違い

結論として、図書館管理システムでは標準パッケージまたはクラウドを先に検討し、業務上どうしても必要な部分だけを追加開発する形が現実的です。スクラッチ開発は独自の業務や既存システムとの密接な連携が必要な場合に限り、標準機能の再実装や将来保守の責任まで含めて判断します。オンプレミスかクラウドかも、セキュリティの印象だけで決めず、自治体のネットワーク、障害対応、データ所在、費用の構造を比べます。

標準パッケージは、資料管理、貸出・返却、予約、OPAC、帳票など、図書館に共通する機能が検証済みである点が強みです。導入館が多い製品なら、法改正やブラウザ更新への対応、現場で起きやすい例外処理のノウハウも蓄積されています。公共図書館向けでは、NECネクサソリューションズのLiCS-Re for SaaSや富士通JapanのiLisシリーズのように、デジタル庁の導入事例ページに掲載されている製品もあります。掲載実績は候補を絞る材料になりますが、自館と同じ館種・規模で同じ運用ができるかは別途確認します。

クラウド型は、サーバーやバックアップを館内で保有しないため、機器の老朽化や災害時の復旧を考えやすくなります。複数館を同じ環境で運用しやすく、機能更新を保守契約内で受けられる場合もあります。一方で、月額・年額の利用料、利用者数やデータ容量に応じた従量費、外部連携オプションが継続します。クラウドを選ぶ場合は、データセンターの所在地、通信暗号化、バックアップ頻度、目標復旧時間、障害通知、契約終了時の返却形式をRFPに明記します。

スクラッチ開発なら、独自の検索、館内ルール、認証、研究データ連携などに合わせた設計ができます。しかし、書誌管理や貸出処理のような標準機能から作ると、要件定義、テスト、法令・ブラウザ対応、障害対応が長期的に必要になります。開発会社の担当者が変わっても保守できる設計書とソースコードの管理、第三者が引き継げるデータ仕様、脆弱性対応の責任分界を契約に入れます。独自要件が一部だけなら、パッケージのAPIや追加画面で解決できないかを先に確認します。

図書館管理システムの発注・外注の進め方

発注は、製品を探してすぐに見積を依頼するより、現状把握、目的設定、要件整理、RFI・RFP、提案比較、契約、移行・テストの順で進めると失敗を減らせます。現場の司書、情報政策部門、調達担当、施設管理担当、必要に応じて利用者代表が参加し、製品選定だけでなく運用変更を合意しておくことが大切です。

最初に、館数、蔵書数、年間貸出点数、利用者数、同時アクセス数、端末台数、ICタグや自動貸出機の有無を整理します。次に、登録、選書、発注、受入、貸出、返却、延滞、予約、搬送、蔵書点検、除籍、統計作成を業務フローにします。帳票やCSVを一覧化し、毎日使うもの、月次で必要なもの、廃止できるものに分けると、不要なカスタマイズを防げます。現行データは書誌、所蔵、利用者、予約、履歴、権限に分け、欠損・重複・文字コード・旧コードの問題も確認します。

「古いから新しくする」だけでは、提案の比較軸が価格と画面の印象に偏ります。「予約受付から受取通知までの職員作業を減らす」「蔵書点検の時間を短くする」「スマートフォンから予約できる利用者を増やす」「障害時でも貸出を止めない」など、目的を業務指標にします。たとえば、予約処理の所要時間、手入力の件数、月間の問い合わせ数、点検にかかる日数、復旧目標時間を現状値として記録します。導入後に測れる指標なら、提案内容と効果を結び付けられます。

候補が多く、製品の違いが分からない場合は、先にRFI（情報提供依頼）を出します。対応する館種、導入規模、クラウド方式、データ移行の実績、連携可能な機器、保守体制を聞き、候補を絞ります。その後のRFP（提案依頼書）では、目的、対象範囲、機能要件、非機能要件、現行データ、希望スケジュール、予算枠、提出様式、評価基準を同じ条件で提示します。松茂町の2026年の調達でも、機能要件一覧、機器仕様、ホームページ機能仕様、見積書作成要領などを分けて公開しています。要求を文書化することが、提案の比較可能性を高めます。

提案書だけでは、現場が毎日使う操作の差が分かりません。候補各社に、利用者登録、資料検索、貸出、返却、延滞、予約、受取館変更、蔵書点検、帳票出力、障害発生時の代替運用を同じ順番で実演してもらいます。できれば司書が実際の業務データに近いサンプルを使い、操作回数、入力項目、権限による表示差、エラー時の案内を確認します。画面の見栄えより、例外処理とデータの追跡性を見ておくと、導入後の手戻りを減らせます。

RFPと要件整理で必ず確認する項目

RFPでは、機能一覧を並べるだけでは不十分です。機能が「標準」「設定で対応」「追加開発」「対象外」のどれに当たるか、費用と納期にどう影響するかを回答させます。また、可用性、性能、バックアップ、監査ログ、権限、暗号化、脆弱性対応、障害通知、運用時間などの非機能要件を別章で整理します。図書館では、データの正しさと利用者の秘密を守ることが機能要件と同じくらい重要です。

移行対象は、書誌、所蔵、状態、利用者、貸出中資料、予約、購入・受入、雑誌の継続情報、権限などに分けて確定します。過去の貸出履歴や検索履歴は、サービス上必要か、個人情報保護上保持すべきかを別途判断します。日本図書館協会のガイドラインは、必要最小限の情報を必要最短期間保持する原則を示し、貸出履歴や検索履歴を活用するサービスはオプトインと、利用停止時の情報破棄を求めています（出典: 公益社団法人日本図書館協会「デジタルネットワーク環境における図書館利用のプライバシー保護ガイドライン」、2025年更新）。

自治体サイト、認証基盤、LINE、電子図書館、デジタルアーカイブ、国立国会図書館書誌データ、MARC、ICタグ、自動貸出機、返却ポストなど、連携先を一覧にします。そのうえで、送受信する項目、頻度、認証方法、個人情報の有無、再送方法、重複防止、連携停止時の手作業を決めます。「API連携可能」という説明だけでは、必要な項目が送れるとは限りません。サンプルデータを使った接続試験と、回線断・相手サービス停止時の運用を契約前に確認します。

クラウドを外注しても、利用者情報の管理責任まで委託先に移るわけではありません。管理者・職員・委託先の権限を分け、強固な認証、通信と保存データの暗号化、操作ログ、脆弱性診断、バックアップ、復元テスト、インシデント報告の期限を要求します。日本図書館協会は、クラウド導入時に図書館がデータの所有者であること、適切な暗号化、第三者提供の制限、日本法・国内裁判所への留意などを示しています（出典: 公益社団法人日本図書館協会、2025年更新）。RFPには、読書履歴をAIやレコメンドに使う場合の同意、目的外利用の禁止、削除方法も入れます。

契約形態と責任分界をどう決めるか

図書館管理システムの外注では、要件定義・開発・導入支援・保守・機器賃貸借・クラウド利用が一つの契約に見えても、実際には性質が異なります。成果物を完成させる部分、専門家の作業時間を提供する部分、継続的にサービスを使う部分を切り分け、契約方式と検収条件を合わせます。契約書の名称より、どこまでが納品責任で、どこからが運用上の協力責任かを明確にすることが重要です。

画面、帳票、連携、移行仕様などの成果物と完成条件が定義できる部分は、請負型で発注しやすい領域です。納品物、検収期間、瑕疵対応、遅延時の扱い、仕様変更の手続き、再委託の可否を記載します。ただし、現場の業務が整理されていない段階で開発全体を固定すると、後から変更が連続して追加費用や納期遅延につながります。要件定義を先行契約に分け、結果を見て本開発を発注する段階方式も選択肢になります。

現状調査、要件整理、データクレンジング支援、PMO、職員研修、運用改善のように、発注者と受託者が協力して進め、作業時間や役務の提供を評価する部分は準委任型が適する場合があります。成果物の完成を一方的に委託先へ求めるのではなく、発注者側の意思決定、資料提供、レビュー期限も計画に入れます。準委任型では、誰が何時間働いたかだけでなく、会議体、課題管理、成果の確認方法を決めておくと、支援の効果を評価しやすくなります。

クラウド利用料やSaaS利用料は月額・年額、保守は受付時間・対応時間・現地派遣、機器賃貸借は端末・サーバー・IC機器など、費用と責任の対象が違います。札幌市が2025年に公開した図書館システム機器借受では、落札金額が税込月額6,456,868円でした。これは41施設規模の機器・ソフトウェア賃貸借と保守条件を含む調達で、ソフトウェア開発費だけの相場ではありませんが、複数施設のTCOが大きくなり得ることを示す公開事例です（出典: 札幌市「札幌市図書館システム機器借受の一般競争入札について」、2025年）。

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

図書館管理システムは、製品の定価が一律に公開されていないことが多く、正確な相場は館数、蔵書数、利用者数、機器、移行、連携、保守の条件で変わります。以下の金額は公開調達の実績と業務システムの構成から整理した記事執筆上の推定レンジです。特定の製品が同じ金額で導入できるという意味ではなく、RFPで予算の抜け漏れを確認するための目安として扱います。

小規模な学校・単館が標準パッケージやクラウドを導入する場合は、初期費用100万〜500万円、年額50万〜300万円程度が一つの推定目安です。小規模自治体の公共図書館システム更改は、データ移行、OPAC、周辺機器、研修、保守を含めて1,000万〜3,000万円程度、複数館・中規模自治体では3,000万〜8,000万円程度を見込むケースがあります。大規模自治体や大学の刷新では、機器、複数施設、電子資料、冗長化、長期保守を含めて8,000万円〜数億円になる可能性があります。いずれも公開定価ではなく、要件による推定です。

公開調達の実績として、松茂町は2026年の町立図書館システム等更新業務で、履行期間を契約締結日の翌日から2027年1月31日までとし、税込3,850万円を提案上限額に設定しました（出典: 松茂町「松茂町立図書館システム等更新業務プロポーザルの実施について」、2026年5月）。これは単館の一例ですが、機能、機器、移行、ホームページ、導入支援などを含む調達の上限であり、標準パッケージの価格表として読み替えないことが大切です。

見積書では、要件定義・設計、ライセンスまたはSaaS利用料、サーバー・ネットワーク、端末・ICタグ・自動貸出機、データクレンジングと移行、外部API連携、テスト、研修、保守・監視・バックアップを分けて記載してもらいます。追加開発は画面単位ではなく、要件、工数、テスト、保守への影響まで確認します。データ移行費が「一式」になっている場合は、抽出、変換、検証、リハーサル、本番切替、切戻しのどこまで含むかを質問します。

5年TCOは、初期導入費に、利用料または保守料を5年分、機器更新、通信費、追加開発、研修、データ移行、障害対応、電子図書館などのオプションを足して算出します。SaaSは初期費用が低く見えても、利用者数や館数が増えたときの料金を確認します。オンプレミスは保守費が一定に見えても、サーバー更新やバックアップ装置の更新が数年後に発生します。さらに、契約終了時のデータ抽出、形式変換、媒体提供、移行支援の料金を確認し、ベンダーロックインを避けます。

委託先選定と見積比較のポイント

委託先は、導入社数の多さだけで決めません。自館と同じ館種・規模の経験、データ移行の実績、司書業務への理解、外部連携、保守の地域体制、契約終了時のデータ返却を確認します。デジタル庁の2026年7月更新ページでは、図書館分野の事例としてLiCS-Re for SaaSが約350団体、iLisシリーズが約640団体と紹介されています。数字は候補を知る材料になりますが、導入団体数と自館への適合性は別に評価します（出典: デジタル庁「マイナンバーカードを活用したサービス／システムと導入事例」、2026年7月更新）。

実績を聞くときは「図書館への導入経験がありますか」ではなく、「公共図書館で何館を横断し、どの程度の蔵書数・利用者数で、どのデータを移行し、切替後にどのような課題が出たか」と質問します。可能であれば、同規模の導入先への訪問やオンラインヒアリングを依頼し、職員が使いやすいか、問い合わせが解決するまでの時間、障害時の連絡経路を確認します。大学向けの会社を公共図書館に採用する場合など、得意領域のずれも説明してもらいます。

保守契約は、問い合わせ窓口、受付時間、一次回答、復旧目標、現地派遣、計画停止、セキュリティパッチ、バージョンアップ、バックアップ復元、代替運用を確認します。24時間365日の受付と、実際の復旧時間は別です。重大障害・個人情報事故・連携先障害を想定した訓練や報告書の提出まで聞きます。導入時の研修は一度の操作説明で終わらせず、管理者向け、窓口職員向け、異動者向けの教材と、稼働後の質問対応を見積に含めます。

見積比較では、総額の安い順に並べる前に、対象範囲をそろえます。データ移行、連携、機器、研修、保守、ライセンス、税、交通費、契約終了時の返却費が含まれるかを確認し、含まれない項目は別欄にします。追加開発は「標準との差分」「開発工数」「テスト工数」「将来保守費」「納期影響」を並べます。評価表は、機能適合、移行計画、セキュリティ、保守、操作性、費用、実績に配点を付け、価格だけで結果が決まらないようにします。

発注で失敗しやすいポイントと対策

失敗の多くは、製品選びそのものより、発注者と委託先の認識差から生まれます。要件を一度に決め切ろうとして現場の合意が遅れる、データ移行を後回しにする、便利な機能を増やし過ぎる、契約に書かれていない作業を期待する、といった状況です。リスクを事前に洗い出し、誰がいつ判断するかをプロジェクト計画に入れます。

データ移行は、旧システムからファイルを出して新システムへ入れるだけではありません。書誌の重複、所蔵場所コード、貸出状態、利用者の有効期限、予約の優先順位、文字化け、欠損項目を確認し、移行後の件数と内容を照合します。契約前にサンプル抽出を行い、移行対象外の履歴や削除対象を決めます。少なくともテスト移行、本番前リハーサル、本番切替後の照合を計画し、切替失敗時に旧環境や手作業へ戻す条件も決めておきます。

生成AI検索、レコメンド、AI蔵書点検は、利用者体験や職員の負担を改善できる可能性があります。しかし、誤った案内、検索結果の偏り、著作権上の扱い、利用履歴の学習利用、説明できない推薦が課題になります。KCCSは、久喜市立図書館で2025年5月から生成AI蔵書検索の実証実験を開始したと公表し、対話形式の検索やレコメンドを検証しています（出典: 京セラコミュニケーションシステム「公共図書館システム ELCIELO」、確認日2026年8月）。新機能を採用するときは、検索精度、利用率、職員の確認時間、誤案内時の訂正方法、ログの保持と削除を評価項目にします。

ロックインを防ぐには、契約終了時にデータを返却することだけでなく、返却形式、項目定義、文字コード、画像・添付資料、利用者情報の削除証明、API仕様、移行支援の単価まで決めます。独自仕様を追加する場合は、標準機能との差分を台帳で管理し、将来のバージョンアップで影響を受ける範囲を把握します。再委託先や外部サービスの変更時に、図書館へ事前通知する義務も確認します。担当者の経験だけに依存せず、設計書・運用手順・障害履歴を発注者側にも残します。

よくある質問（FAQ）

図書館管理システムの発注では、費用だけでなく、館種、移行、保守、個人情報、契約終了後の扱いに関する質問が多く寄せられます。ここでは、提案依頼や社内検討で確認されやすい内容を、判断の基準とともに回答します。

標準的な資料管理、貸出・返却、予約、OPAC、蔵書点検が中心なら、実績のあるパッケージやクラウドを基盤にする方法が適しています。独自の研究データ連携や複雑な認証など、標準機能で業務を満たせない部分だけを追加開発し、それでも解決できない場合にスクラッチを検討します。費用だけでなく、法令対応や担当者交代後の保守まで比較して決めます。

クラウドだから自動的に安全、またはオンプレミスだから安全とは言えません。通信・保存データの暗号化、権限分離、ログ、バックアップ、脆弱性対応、障害時の復旧、委託先の守秘義務、データ所在、契約終了時の返却を確認し、自館の情報セキュリティポリシーに照らして判断します。図書館利用のプライバシーを守るため、利用履歴を必要最小限・最短期間にし、AIやレコメンド利用は同意と削除の手続きを設計します。

小規模な学校・単館の標準導入なら初期100万〜500万円、年額50万〜300万円程度、小規模自治体の更改なら1,000万〜3,000万円程度などの推定レンジがあります。ただし、公開価格ではなく、機能、館数、データ移行、機器、連携、研修、保守を含めた場合の目安です。公開事例では、松茂町の2026年調達に税込3,850万円の提案上限額が設定されており、札幌市の2025年調達では税込月額6,456,868円の落札額が示されています。対象範囲が違うため、自館の5年TCOに置き換えて比較します。

多くの場合は移行できますが、すべての履歴や項目をそのまま移せるとは限りません。旧システムからの抽出形式、書誌・所蔵・利用者・予約の項目、コード変換、重複・欠損、個人情報の保持期間を確認し、テスト移行と本番前リハーサルを行います。Excelで管理している場合も、列の意味、更新者、重複、文字コード、個人情報の不要な項目を整理してから委託先に渡します。

まとめ

図書館管理システムの発注・外注では、まず公共・学校・大学のどの館種で、どの業務を改善したいのかを明確にします。そのうえで、標準パッケージやクラウドを軸に、必要な追加開発だけを選び、RFIで市場を把握してからRFPで同じ条件を各社へ提示します。デモは同じ業務シナリオで行い、提案書の印象ではなく、移行、連携、セキュリティ、保守、職員教育まで確認します。

候補企業を決めた後も、検収条件、保守の受付時間、障害時の連絡先、データ返却、再委託、利用履歴の削除を契約書と運用手順に落とし込みます。稼働後に効果を測る指標と定例会議を決めておけば、導入後の改善や次回更改の判断にもつながります。

最後に、初期費用だけでなく、利用料・保守・機器・連携・研修・追加開発・データ移行を含む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を創業。