MediaNet No.27（2020.10）

特集

早慶図書館システム共同運用

早慶図書館共同運用システム導入プロジェクトの記録– 導入プロジェクトと KOSMOSⅣ の概説 –い が ら し けんいち

五十嵐健一
（メディアセンター本部課長）

1

はじめに早慶図書館共同運用システムは，2019年 9 月に運用を開始した。このシステムは，慶應義塾大学メディPrimoVEシステムを導入する契約を結んだ。2018年 4 月から 1 年と 5 か月間の導入準備作業に入り，2019年 9 月に運用開始となった。

アセンター（以下「慶應」とする）と早稲田大学図書

この期間において，2015年 3 月から2018年 2 月ま館（以下「早稲田」とする）からなるコンソーシアムで，つまりExL社と契約に至るまでの経緯について（以下「早慶コンソーシアム」とする）として共同では，既に本間・入江 1 ） により報告がなされている導入し運用する初めてのシステムである。そのシステ

ため，ここでは，そのあとを引き継ぐ形で2018年 4

ム構成は， 1 つの箱としてのシステムを早稲田と慶應

月から2019年 9 月までのシステム導入プロジェクト（以下「早慶」とする）で共同運用するものではなく，について，その推進体制および実際にどのように進慶應側のシステム（以下「KOSMOSⅣ」とする）と，捗していったかの経緯を，慶應側の取り組みを中心早稲田側のシステムはそれぞれ独立しており，その間としてまとめる。に早慶コンソーシアムとして運用するための機構を持たせることで融合を果たす複雑な構成となっている。

（1）プロジェクト推進体制

本稿では，その契約から導入に至るプロジェクト

早慶の勉強会は同じ業務の担当者間における情報について，また実際に導入したKOSMOS Ⅳシステ共有を目的として開催された。システムの共同導入

ムについての解説を行う。

が決まり，その覚書を交わすタイミングで，その各担当スタッフの集まりを発展させた“チーム制”か2システム導入プロジェクトについてらなる「早慶図書館システム共同運用検討会議」（略

KOSMOS Ⅳの導入についての検討は，2015年 3

称：早慶システム会議）を発足し，システム選定月に始められた。そこから運用開始となる2019年 9（RFP作成および提案書の採点）およびシステム導月までの 4 年と 6 か月の概略を以下にまとめておく。

入プロジェクト推進のための体制を整えた。

2015年 3 月，早稲田の深澤館長と慶應の田村所長

1 つのチームはリーダーおよびサブリーダーと数（当時）の懇談において方向性が確認され，早慶実務名のメンバーから成る。各チームはそれぞれの業務担当者間による勉強会を行うこととなった。勉強会

領域とする機能を担当し，そのリーダーは，その業は両機関の図書館システムの運用状況と業務フロー

務機能に関する権限と責任を持ってプロジェクトにを共有することを目的として月に 1 度程度開催した。

あたった。メンバーはチーム間で兼任もあったが，この勉強会の結果を受ける形で，2016年 7 月，深澤以下の業務担当毎に表 1 の通り早稲田，慶應でそれ館長と慶應の赤木所長（当時）との懇談により，シぞれ 8 つずつ組まれ，合計16チームとなった。

ステム共同運用という形で具体的に検討に入ること
表1になった。2017年 5 月には覚書を交わし，本格的に早慶で共同運用するシステムの選定作業に入ることとなる。2017年 8 月に早慶としてシステムの提案依頼書（Request For Proposal，以下「RFP」とする）を作成して広く国内外のシステムベンダーから提案を募集して選定を行い，その結果2018年 2 月にEx Libris社（以下「ExL社」とする）のAlma/8

呼 称
SYSチーム
総務チーム
FULチームREMチーム
ACQチームSERチームERSチームDSCチーム早慶システム会議チーム一覧

業 務
SYSTEM，システム担当
総務担当
Fulfillment，閲覧担当
Resource Management，目録担当
Acquisition，受入/支払い担当
Serials，雑誌担当
Electric Resources Service，電子資源担当
Discovery，レファレンス担当

担当する業務領域
全体調整とシステム等
会議体の運営など
利用者/貸出/返却/予約等
書誌の作成・管理維持等
資料の購入/受入/支払い等
雑誌関連
電子資源関連ディスカバリーシステム関連

MediaNet No.27（2020.10）

特早慶図書館システム共同運用

また，チーム間の連携をスムーズに行うために表2 の通り 2 つの会議体を発足させた。

で，旧システムからのデータ移行作業が 2 回（テスト 1 回，本番 1 回）というものであった。これは英語圏の導入プロジェクトとしては標準的という説明

表2

早慶システム会議

会議体名
総務システム会議（Project ManagementOffice，PMO）
リーダー会議会議体一覧

目 的
プロジェクト全体の統括及び早慶コンソーシアムの事務局としての役割を目的とした会議体。総務チームとシステムチームのリーダー及びその指定するメンバーより構成。
早慶システム会議全体方針の確認，チーム間の情報共有を目的とした会議体。各チームのリーダーから構成。

であったが，そもそも日本での導入は初めてで，開発を入念に進めていく必要があり， 6 か月では短く，またデータ移行作業もこの回数では不安であると伝え，交渉を重ねた。厳しい交渉ではあったが，最終的には， 6 か月間の準備期間を含む，17か月間のプロジェクト期間として，週に 1 度Project Meeting

慶應内においては，全塾閲覧担当者会議（FULとして打合せを持つこと，データ移行作業は 3 回チーム），全塾レファレンス担当者会議（DSCチー（テスト 2 回，本番 1 回）とすること，という内容

ム），全塾図書雑誌担当者会議（ACQチーム，REMで合意することができた。

チーム，SERチーム），全塾e事務連絡会（ERSチー
ム），メディアセンター本部システム担当（SYSチーａ

プロジェクト準備期間（2018. 04 - 09）ム），メディアセンター総務担当（総務チーム）より，ExL社と契約後，最初のこの期間は，プロジェクその主査（主任）がリーダーとしてチームを構成し，トに入る前の準備期間として，各チームでAlmaの各担当間の情報共有および案件調整は，図書館シスマニュアルを読み込み，評価用に提供された環境

テム調整WGにて行うこととした。全塾での情報共を利用して，まずは早稲田，慶應それぞれでAlma

有は，必要に応じて図書館システム調整WG，またを導入することにより，業務フローをどのようには各会議体の主査よりメディアセンター事務長会議最適化していくかの検証を進めていった。Projectまたはメディアセンター政策委員会に報告を行う体

Meetingでは，システムの仕様を確認し，Almaの制とした。

日本での利用に必要な機能について開発要望を出し

また，ExL社からは担当別に 3 つのチームが参加た。また，この時点で早慶コンソーシアムとして，してプロジェクト全体を支え，導入支援を行って全書誌データを完全に共有することが決まっていた

くれた。そのチーム構成は，プロジェクト推進のため，この期間の後半にかけては，それぞれに移行

主担当であり日本に常駐するProfessional Service

前のシステム上で書誌データを抽出して同定処理をteam，イスラエルに拠点があり開発を担当する

行い，Alma上でマージするための準備作業を進め

Development team，世界中の利用機関の運用サポーていった。

トを担当するSupport teamから成る。
ｂ
Ex Libris
・Professional Service team・Development team・Support team

プロジェクトの推進のための検討会
・Project Meeting
・Workshop

早慶図書館システム共同運用検討会議（略称：早慶システム会議）
早稲田

慶應

・SYSチーム
・総務チーム・FULチーム・REMチーム・ACQチーム・SERチーム・ERSチーム
・DSCチーム・SYSチーム
・総務チーム・FULチーム・REMチーム・ACQチーム

図1

プロジェクト期間 1 （2018. 10 - 2019. 01）
この期間には，初回のデータ移行作業（テスト移行 1 回目，2018年12月実施）に取り組んだ。これは早慶それぞれに実施する作業であり，ProjectMeetingにおいても，早慶別々に時間を設けること

総務システム会議(PMO)

リーダー会議（SERを兼ねる）

・ERSチーム
・DSCチーム

プロジェクト推進体制全体図になった。慶應ではAlephとAlma Eという 2 つのシステムからのデータ移行作業となった。両システ
ムともAlma同様にExL社の製品であったことから，スムーズに進むだろうと予想していたが，実際に作業する段になってみると，Alma EはAlmaの機能制限版であり，実質的にAlmaからAlmaへの移行であ（2）プロジェクトの進捗ること，そこにAlephのデータを移行するという複ExL社との契約時にプロジェクトプランとして提雑な作業となることが判明した。この時点では世界案されたのは，プロジェクト期間は 6 か月，その中中でも実績のない手探り状態での移行作業となり，

9集

MediaNet No.27（2020.10）

特集

早慶図書館システム共同運用

結局Alma Eからのデータ抽出はできないことが判

ｄプロジェクト期間 3 （2019. 05 - 09）

明したため，Alma Eの環境にAlephのデータを上

2 回目のデータ移行後は，その作業中に計測した書きし，そのAlma Eの環境を元に本番環境となる

各工程の処理時間を元に，最終的な作業手順の確認Almaを仕立て上げるという大変複雑な方式を取るを進め，本番移行のスケジュールを綿密に組み上げこととなった。ともあれ，早慶とも移行作業後に，て行った。ExL社に任せる工程，早慶として別々に移行データが格納された状態でAlmaとPrimoVEの進める工程，早慶一緒に進める工程を破綻なく組み本番環境が提供された。

合わせ，さらに利用者に対する貸出・返却などはでスケジュール的におおよそ予定通りデータ移行作きる限り短時間の停止で済むように配慮したため，業が完了すると，その結果の評価作業を進めた。し最終的なスケジュールは時差も勘案した24時間対応

かし，早慶ともに，旧システムからのデータ抽出やという大変複雑なスケジュールとなった。

移行方法において部分的に問題が発見され，またこの時期に入るとProject Meetingでの開発作業

データ移行後の検索索引作成（Indexing）の処理ににおいても，移行前に完了する機能だけではなく，不具合が発生していることが発覚した。そのため，移行後に実装となる機能も出始めていた。この時点

早慶コンソーシアムとしての機能やPrimoVEの検でもまだ多くの機能が開発中であったが，早慶とし索機能など，いくつかの機能検証は一旦先送りするて開発項目に優先順位をつけ，ギリギリまでExL社こととなった。と検討を重ね，必要なものは移行前に実装するように調整して行った。

ｃ

本番データ移行作業（2019年 8 月最終週実施）は，プロジェクト期間 2 （2019. 01 - 05）
初回のデータ移行作業後は，移行されたデータの各工程で多少の遅延や問題は発生したものの，これ検証と並行して，発見された問題の解決を進めた。

までのテスト移行時の経験を生かして解決し，どうまた，初回のテスト移行を経て，ようやく本番デーにか予定通りに進めることができた。

タ移行時の詳細なスケジュールの立案を開始するこ

全作業工程の最後に早慶からExL社に検証完了をとができるようになったため，各担当から可能な範連絡することで，最終的な移行完了となりサービス囲でシステムリプレースに関する利用者向けの広報開始が判断されることとなっていた。慶應内で，各を始めた。また，この期間Project Meetingではデーチームと各機能が問題なく機能していることの検タ移行作業と並行して，早慶コンソーシアムとして証を済ませ，早稲田と共にExL社に移行完了の連絡の機能とPrimoVEの日本語検索機能についての開を入れた際には，サービス開始への不安混じりでは発が佳境を迎えることとなった。特にPrimoVEにあったが，まずは無事に移行作業の工程を完了する

ついては，移行したデータでの検索結果の不具合をことができてほっとしたことを覚えている。

ExL社に伝え，その改修作業を進めるという一連の流れを短いサイクルで何回も回し，さらにProfessional

103

KOSMOSⅣシステム解説

Service team 経 由 で は な く， 実 際 に 開 発 を 行 う

次に実際に導入したシステムについて解説する。

Development teamとも直接連携して，開発を重ね，慶應では図書館システムをKOSMOSという呼称で改善を進めていった。

ⅠからⅢまで単独で運用してきたが，今回のⅣで初2 回目のデータ移行作業（テスト移行 2 回目，めて早慶での共同運用となった。共同運用という時

2019年 5 月実施）は，本番データ移行作業のシミュ点で，歴史的に大きな変革点であり，そのためのシレーションを兼ね，各工程にかかる時間を計測しつステムの構成も，これまでとは大きく異なるものとつ本番のつもりで臨んだ。移行後のデータを検証しなっている。ここでは，KOSMOS ⅢからKOSMOSてみると， 1 回目のデータ移行で発生した問題の多Ⅳへのシステムリプレースにおいて慶應のシステムくを解消することができていた。ここでもなお積みがどのように変わったのか，そしてKOSMOS Ⅳシ残しとなった問題については，本番データ移行までステムがどのようなシステム構成になっていて，早に修正するか，移行した後で対応するか，などの切慶コンソーシアムとして運用するためにどのようなり分けを進めていった。

特徴を持っているのかをまとめる。

MediaNet No.27（2020.10）

早慶図書館システム共同運用（1）KOSMOSⅢからKOSMOSⅣへ

ａ特Ex Libris社のクラウドサービスシステム

KOSMOS Ⅲ は，ExL社 の 提 供 し て い るAleph，AlmaとPrimoVEは，ExL社により開発され，提Primo，SFXとVerdeというパッケージ製品群を基幹供されるSaaS形式のクラウドサービスシステムでとして，そこに独自開発した外付けシステムを追加ある。機関内にサーバを持つ必要がなく，利用にも2）して構成されており，2010年から稼働してきた 。

専用のアプリケーションは不要で，Webブラウザ

しかし，機関内にサーバ機器を設置して利用するオを用いる。ExL社は製品のクラウドサービス化を進

ンプレミス形式での運用であったため，メンテナンめており，世界中で提供しているクラウドサービス

ス作業や停電の影響により， 1 年に数回，長時間のに関する情報公開を積極的に行っており，ドキュメ停止が必要であり，サーバ機器の保守やリプレースントや障害履歴などを全て公開すると共に，その高にコストがかかるシステムであった。さらに運用開い可用性や堅牢性をアピールしている 4 ）。

始後数年でVerdeが製品として終息しサポートが停各システムは，毎月自動的に更新されるため，世止したため急遽Alma Eという後継システムに移行

界中の利用機関は，一緒に最新の機能を手にするこした。すると，導入時に組み上げていたシステム間とができる。また，ExL社は利用機関から機能追加の連携が統合的でなくなり，利用者へのサービスや改善の要望を受け付けており，それら要望の実現はどうにか支障なく提供できていたものの，業務面は不具合の修正などと共に毎月の更新時に行われる。

ではスタッフに大きな負担がかかるようになっていた。また，この頃には，海外を中心に図書館システｂ

Almaムがオンプレミス形式からクラウドサービスに移行

Almaは，資料の書誌データを作成 / 管理する目しつつあり，図書館コンソーシアムでのシステム共録機能，資料の発注 / 支払い / 予算を管理する支払3）

い・受入機能，複雑な雑誌データを管理する雑誌機

基本的にシステムをリプレースする際には，複合能，電子的な資料を管理する電子資源機能，貸出 /的な要因があり，必ずしも毎度同じ理由から実施さ

返却 / 利用者管理といった閲覧機能という，主に図れるとは限らないが，常に，書館スタッフの利用する機能とデータを制御する

同運用が進み始めていた 。

1 ）現行システムの機能面での改善，LSP（Library Services Platform）と呼ばれる形式

2 ）現行システムの運用コスト面の改善，の業務用基幹システムである。LSPと呼ばれる製品

3 ）システムリプレースを機とした業務フロー面も増えてきているが，Almaは，コンソーシアムでの改善，を目的として実施される。
上述の通り，KOSMOS Ⅲにおいても 1 ） 2 ）のの運用に特化した機能を持つことが特徴である。その根幹を成すのが，Zoneと呼ばれるデータ格納領域の構成である。

点からリプレースの必要性が出ており，並行してまず，Almaは世界中の利用機関でデータを共有3 ）の点においても改善できないか考え始めていするためのCommunity Zone（以下「CZ」とする）た。結果として，状況やタイミングなどが重なり，を持つ。このZoneには，書誌データや電子資源に早慶コンソーシアムとして，早稲田大学との共同運関するデータが格納されており，各機関は自由に用という形でシステムリプレースを実施することとそれらを利用することができる。CZの運用責任はなった。

ExL社にあり，出版社などデータ作成元から提供される最新のデータが常に利用可能である。

（2）KOSMOSⅣの構成と特徴

次に各機関内に留めるべき契約情報や利用者の個KOSMOS Ⅳの構成は，ExL社によるパッケージ人情報等といったデータを格納するのがInstitutionシステムであるAlmaとPrimoVEと，それらに接続Zone（以下「IZ」とする）である。基本的に各機して利用する外付けシステム群から成る。基幹とな関のすべてのデータはIZに格納されており，通常るAlmaとPrimoVEがクラウドサービスシステムでの業務で利用されるのはIZ内のデータとなる。IZあること，また早慶コンソーシアムとしての共同運の運用責任は各機関となるが，IZには，CZとリン用であることがその大きな特徴である。

クするデータを作成することが可能であり，CZの11集

MediaNet No.27（2020.10）

特集

早慶図書館システム共同運用

更新があると，IZのデータも更新される。また，具体的に開発したシステムは，Almaで実現するCZに無いデータを直接IZに作成することもできる。

ことのできない帳票を作成するためのシステムや，最 後 に 3 つ目 のZoneが，Network Zone（ 以 下Almaと出版社発注システムとの連携部分における「NZ」とする）である。NZは，Almaで最も特徴的中間処理を行うシステム，独自の集計を必要とするなコンソーシアムとして運用するための機能の根幹統計処理システムなどが挙げられる。となるZoneである。運用責任は，そのコンソーシアムとなる。コンソーシアムに属する各機関は，そ（3）KOSMOSⅣと外部システムとの連携

れぞれ自機関のIZに格納しているデータの一部をデジタルトランスフォーメーションを推進する中，NZに格納することで，コンソーシアム内で共有すシステム間連携はその中間におけるスタッフによるることが可能となる。どのデータをNZで共有して，手作業をなるべく排除し，自動的に処理を進められどのデータをIZのみで独立して運用するかなど，るように構成されるべきである。この点からシステ

NZをどのように構成するかは，コンソーシアム毎ムとして重要になるのが標準化されたインタフェーに自由に設計可能であり，また運用中の変更も自由スを持つ事であると言えよう。にできる。

Almaに お い て は， 資 料 の 発 注・ 納 品 に お け る
EDI（Electronic Data Interchange）機能や財務シ

ｃPrimo VEス テ ム 等 のERP（Enterprise Resource Planning，PrimoVEは，ExL社 が 従 来 か ら 提 供 し て い た

基幹系情報システム）との連携，利用者認証のため

Primoの設計をベースとして，Almaと連携して利のSAML対応機能，自動書庫連携機能など，外部シ用することに特化して再開発されたディスカバリシ

ステムとの連携に実績のある標準的なインタフェーステムである。2018年にリリースされたばかりの新スが備えられている。

しい製品であり，そのベースはPrimoでも，開発はKOSMOS Ⅳにおいても，利用者認証およびEDI独立して行われているため，似て非なるシステムでを利用した発注・納品機能において，Almaが持つある。Alma内で作成されたデータをほぼリアルタ

標準インタフェースを利用する事で，KOSMOS Ⅲイムに検索対象とすることができるというメリット

では必要であったシステム間連携のための外付けシがある反面，Primoの持つ全ての機能が利用できるステムの開発やスタッフの手作業を省くことができ，訳ではない。

業務の効率化を進めることができた。また，将来，学内の財務システムが更新された際には，そのERPｄ

外付けシステム
一般的にパッケージシステムを導入する際に，そ連携部分においてもAlmaとのシステム間連携を行い，処理の自動化を進める予定である。のシステムの持つ業務フローと現場の業務を完全にマッチさせることは難しい。パッケージシステムに接続してそのギャップを埋めるために独自開発のシステムを運用することは一般的であり，ここでの外ここで，今回導入したシステム構成を，最も特徴的であるコンソーシアムの側面から説明したい。

付けシステムとは，KOSMOS Ⅳを構成する，Alma，早慶コンソーシアムとしてのシステムの構成は，PrimoVE以外の独自開発システムのことを指す。

図 2 の通り，Almaの 3 つのZoneを利用して，デー慶應においては，KOSMOS Ⅲにおいても複数の外タを共有する部分と，各機関でのみ保持する部分か付けシステムを運用してきたため，今回もいくつら構成されている。NZでデータを共有することで，かは必要となることがわかっていた。KOSMOS Ⅳ早慶のスタッフは，それぞれのIZ上のデータとNZのコンセプトとして，“現場の業務をなるべくAlma上のデータを合わせてAlmaから利用することがでに標準で用意されている業務フローに合わせ，どうき，また利用者もPrimoVEを通して早慶双方のデーしても合わない場合のみ外付けシステムの開発を行タを検索することができるようになっている。

う”を掲げて慎重に検討を重ね，必要なもののみを開発し組み込むことにした。

12（4）早慶コンソーシアムとしてのシステム構成

MediaNet No.27（2020.10）

早慶図書館システム共同運用
グローバル連携ゾーン (CZ)

システムに関する検討は早慶コンソーシアムとしてディスカバリシステムインデックス進めることになるだろう。これまでとは異なった段電子資料メタデータ

特階に突入していることは確かである。
Primo VE 早稲田大学
ディスカバリ

早慶連携ゾーンo メタデータ管理
o …

早稲田大学ゾーン メタデータ管理
 貸出管理 電子資料管理 アクセス管理 …
Alma (IZ)

図2

Alma (NZ)

Primo VE 慶應義塾大学
ディスカバリ慶應義塾大学ゾーン
 メタデータ管理
 貸出管理 電子資料管理 アクセス管理 …
Alma (IZ)

早慶コンソーシアムとしてのシステム構成図

KOSMOSⅣを作り上げる過程で，前回の記録を参照する機会は実際にあった。今回の記録が次回もそのまま参考にできるとは限らないが，多くの記録を参考にすることで，その期間に薄れつつあったノウハウがある程度でも蘇るかもしれない，という期待を込めて今回の記録を残したいと思う。
最後に個人的な感想を少し。心身ともにしんどい

4

終わりに作業であり，眠れない日々が続くこともあったが，本稿では，慶應のシステムチームのリーダーとし新しい取り組みの只中に入るのは恵まれたことだとて全体を推進する視点から，今回のシステムリプ思うし，何よりも優秀なスタッフに支えられてプロレースのプロジェクトの全体を振り返り，また導入ジェクトが着々と進んでいく様子を見ることはとてしたシステムを俯瞰的に紹介した。各機能の詳細はも楽しかった。まだ考えたくないが，次回は必ず，本特集の各チームからの報告を参照してもらうとしより“初めて”が多くタフな作業になると思われる。て，ここでは全体像を掴んでもらえれば幸いである。

しかし，やると決まったら躊躇せず，何よりも是非これまで慶應では，様々な要因から，おおよそ10楽しんで取り組んでほしいと思う。

〜15年に 1 度という間隔でシステムリプレースを実施してきた。今回も同様であったが，システムリプ

注・参考文献

レースは，大きくコストがかかり，また直接携わる

1 ）本間知佐子，入江伸．早稲田大学・慶應義塾大学コンソー

担当者だけでなく，導入後慣れないシステムを利用

シアムによる図書館システム共同運用に向けた取り組み

するスタッフにも大変な労力がかかる面倒の多い作について．カレントアウェアネス．2020，no.343.

業である。しかし，業務フローを見直す良いタイミ

2 ）入江伸．AlephをKOSMOS Ⅲへ，Primoをサービスの前ングであり，全体を成長させることのできる機会で面へ ― システム選定から稼働までの総括 ―．MediaNet.

もある。KOSMOSⅢ，KOSMOSⅣと連続してシス

2010，no.17，p.12-15.

テムリプレースに関わった経験からすると，状況は3 ）Marshall Breeding. Case Study：The Orbis Cascade

毎回異なり，その成功に向けたマニュアルは存在しAlliance：Strategic Collaboration among Diverse

ない，と言える。KOSMOSⅢ導入の際は，システ

Academic Institutions. Library Technology Reports.

ムリプレースを担当するスタッフがある意味現場を2013，vol.49，no.1，p.30-31.

離れプロジェクトに専従したのに対して 2 ），今回https://doi.org/10.5860/ltr.49n1，（accessed 2020-08-09）のKOSMOSⅣではこれまでに述べた通り現場を回4 ）Ex Libris Trust Center（Security Policies, Serviceしつつリプレース作業を行うなど柔軟に，状況に即Availability, etc.）して対応してきた。マニュアルはないが，スムーズ

https://trust.exlibrisgroup.com/，に進めるためには一定のノウハウがあり，あまりに（accessed 2020-08-09）

その間隔が開いてしまうことはその喪失のリスクとなるかもしれない。
今回のシステムリプレースにおいてKOSMOS
Ⅳは，クラウドサービスを採用し，さらに早慶コンソーシアムでの共同運用体制となった。クラウドサービスは，利用料以外のコストがかかりづらく，また自動的に機能が追加されるため，機能の陳腐化が発生しづらい。また，今後のリプレースを含めた13集