1.　はじめに

近年，国際的に注目が高まっているオープンサイエンスでは，研究成果を広く一般に公開し再利用を促進することで，共同研究やイノベーションの創出につながることが期待されている[1]．論文のオープンアクセス化は，オープンサイエンスの中でも主要な課題に位置づけられている[2]．オープンアクセスを推進するためのサービスとして，機関リポジトリと呼ばれるものがある[3]．機関リポジトリのための汎用的なシステムの開発は，2000年頃に欧米の大学図書館を中心に始められた．代表的なソフトウェアとしては，米国のマサチューセッツ工科大学で開発が始まったDSpace [4]と，英国のサウサンプトン大学が開発するEPrints [5]がある．これらのソフトウェアはオープンソースとして公開されたため，世界的に利用者が広まっていった[6]．

我が国では，2005年に始まった国立大学を中心とした機関リポジトリの実装実験プロジェクトをきっかけに，機関リポジトリの普及が始まった[7]．プロジェクトではDSpaceやEPrintsを利用した機関リポジトリの構築が進められた[7]．単に既存の機能を使うだけではなく，大学業務の中で効率的にサービスを運用するための機能拡張も積極的に行われた[8], [9], [10], [11]．同時に，サービスの運用に関する情報を共有するための大学間コミュニティも形成されていった[12]．これにより，機関リポジトリの構築の障壁は比較的軽減され，2010年5月の時点で，国内の機関リポジトリ数は200に達した．しかしながら，機関リポジトリの普及が進むにつれて，持続的な運用にかかわる課題が明らかになってきた．ソフトウェアのメンテナンス費用の捻出が難しく，メジャーバージョンアップができないという課題は，その典型例である[10]．特に，機能拡張を行っている場合は，バージョンアップのたびの修正が必要となり，更に対応を難しくしていた[13]．

こうした状況が続く中，2013年に改正された学位規則では，博士論文をオープンアクセス化することが義務化された[14]．その手段としては，機関リポジトリを利用することが原則とされたことから，機関リポジトリの更なる普及が必要となった．規則改正の議論が進められていた2012年の段階で，152校が新たに機関リポジトリを構築する必要性が生じていた．比較的大規模な大学でも課題を抱える中，小規模な私立大学が独自に機関リポジトリを導入して運用してくことは，困難であることが予想された．国内におけるオープンアクセス活動に全国の機関が積極的に関与していくために，安定かつ持続的な機関リポジトリサービスの確立が喫緊の課題となっていた．

以上のような背景のもと，国立情報学研究所（NII）では，2012年から機関リポジトリのクラウドサービスであるJAIRO Cloudの運用を開始した[15]．サービス開始後の2012年4月末の利用機関数は16であったが，2020年7月末時点の利用機関数は625であり，世界でも類をみない機関リポジトリサービスに成長した．現状のJAIRO Cloudは学術論文，紀要論文，博士論文を中心とした文献リポジトリとして活用されている．本稿では，JAIRO Cloudに至る歴史（表1）を振り返りながら，JAIRO Cloudの提供において，どのような問題設定をし，それをどのように解決してきたか，その取り組みについて紹介する．

2.　汎用リポジトリソフトウェアの開発

JAIRO Cloudを提供する以前は，国内の機関リポジトリの多くが，海外で開発されたオープンソースソフトウェアを利用して構築されていた．一部の先進的な大学では，NIIの委託を受けて，ソフトウェアの拡張開発が進められていた[16], [17], [18]．開発は，一般的に開発業者に委託して進められていた[13]．基盤として利用していたDSpaceやEPrintsは，オープンソースコミュニティ主導の開発体制が整えられていたが[5], [19]，そことの接点は希薄であった．図書館員や開発業者が国際的な開発コミュニティに積極的に参加することはなく，国内での開発成果がオリジナルのソースコードに還元されることはほとんどなかった．そのため，拡張箇所に影響があるバージョンアップが行われるたびに，後追いの対応が必要となるなどの弊害が生じてきた．当時は，両ソフトウェアともに積極的なバージョンアップが繰り返されていたことが[20]，状況をさらに悪化させていた．

一般的には，こうした事態を避けるために，開発コミュニティと連携し，適切なタイミングでソースコードを還元したり，開発の状況を見据えたうえで，それに同調した拡張機能の開発を進めていくのが通常である．オープンソースソフトウェアは，コードを改変しやすいというメリットがあるが，その改変したソースコードを持続的に管理できる体制が構築できていなければ，サービスの安定的な運用につながらない．ソフトウェアの利用者と開発者が，相互作用できる関係を構築しなければ，利用者のニーズに基づいた機能拡張を持続的かつ安定的に開発していくことは難しい．

2007年に開発が始まったWEKOは，NIIと大学との密接な関係を生かし，開発者と利用者が双方に近い立場にあるという構造を維持しながら開発が進められた．WEKOは，当時学術機関での導入実績が進んでいたコンテンツ管理システム（CMS）NetCommons2（NC2）をベースに開発が進められた[21]．図1に，WEKOのソフトウェア構成図を示す．WEKOはNC2のモジュールとして開発されており，NC2が利用するMySQLとファイルシステムにコンテンツやそのメタデータを保存する．WEKOはNC2のモジュールを利用して，比較的自由にサイトデザインを変更することが可能であった．WEKOがそのベースシステムとしてNC2を選択した理由はこの点にある．

利用者に寄り添った開発が成功の鍵だった

WEKOは，当時DSpaceが開発した新しいユーザインタフェース（UI）であるManakinを意識していた[21]．ManakinはDSpaceの利用者コミュニティの中で要望が高かったUIのカスタマイズ能力を向上させるためのものであった[22]．こうしたUIに対する要望は，国内においても同様であることは容易に想像された．WEKOはDSpaceの対応をさらに進化させ，テンプレートファイル等の編集を必要としない，Webブラウザ上からUIをカスタマイズできる機能を実現させた．

表2は，代表的な汎用リポジトリソフトウェアにおけるカスタマイズ可能な項目とその手法についてまとめたものである．Fedoraはコーネル大学が開発したデータモデルの柔軟性の高さを特徴としたリポジトリソフトウェアである[23]．Israndoraは2013年，プリンス・エドワード・アイランド大学ロバートソン図書館で開発されたリポジトリソフトウェアである[24]．FedoraとCMSの一種であるDrupalを組み合わせたWEKOに近いアーキテクチャを採用している．カスタマイズの手法は多様であり，設定ファイルやテンプレートファイルといったサーバ側での修正作業が必要なもの，REST APIのようにUI自体の開発が必要なもの，そしてWebブラウザ経由でのカスタマイズが可能なWeb UI経由により実現するものと，ソフトウェアごとに異なっている．WEKOでは，カスタマイズがWeb UI経由で実現できる．図2に，WEKOの機能を利用した機関リポジトリごとのカスタマイズ例を示す．Webブラウザ経由でのカスタマイズ機能を備えることで，環境構築後にサービスを機関に提供してからは，システムに明るくない大学関係者のみの作業で，UIのカスタマイズが可能となった．

WEKOの機能は，利用者からの要望に対応する形でNIIが基本設計を行い，開発業者による実装が行われた．実装された機能は，利用者からの評価をもとに機能改善が行われた．WEKOの新機能については，NIIが提案する機能候補に対して，利用者が投票を行うことで，実装する機能を決定した．WEKOは利用者の声を機能に反映しながら，機能改善を進めることで，豊富な機能と，利便性の高さを両立させた汎用リポジトリソフトウェアとしての立場を確立した．

3.　JAIRO Cloudの開発

図書館員による機関リポジトリの運用において障壁となっていた管理の容易さに焦点をあて，WEKOの開発は進められた．しかしながら，中小の大学では，機関リポジトリを構築するための人的あるいは予算的なリソースを十分に持ち合わせていない場合が多かった．こうしたスタートアップの障壁を軽減するために，WEKOのクラウドサービスであるJAIRO Cloudの提供が始まった．本章では，JAIRO Cloudのサービス提供以来，大学図書館が機関リポジトリを構築することに対する不安や課題がどのように変化していったかを数値的に示すとともに，NIIがJAIRO Cloudを通して機関リポジトリサービスの運用コストを軽減するために，どのような工夫を実践したかについて述べる．

3.1　機関リポジトリの構築と運用に関する課題と意識の変化

機関リポジトリの構築・運用にはシステムに関する知識が不可欠である．表3は，JAIRO Cloudのサービスを開始した2012年度の大学あたりの図書館職員数および情報処理職員数を示したものである．国立大学を含む中小規模（B，C，D）の大学では，図書館に所属する情報処理担当職員は1人以下であり，機関リポジトリを構築・運用するための技術者が不足していることが分かる．さらに，公立・私立のC・D規模の大学では，図書館職員数も少なく，情報処理担当職員もほとんどいないため，図書館職員が通常の図書館業務の傍らで，機関リポジトリの構築・運用を担当しなければならない状況にあった．

図3は，学術情報基盤実態調査結果を元に，機関リポジトリ構築に関する課題を，大学種別ごとにまとめたものである．実態調査では，機関が抱える課題について，機関あたり複数の回答ができるようになっている．機関リポジトリを構築している機関に対しては「運営資金の確保」「実施体制の維持」「コンテンツの確保（著作権処理を含む）」「大学全体におけるリポジトリ事業の位置付けの明確化」「その他」「特になし」の中から，機関リポジトリを構築する方向で検討している機関に対しては「学内合意形成」「運用指針の策定」「システム構築」「コンテンツの確保（著作権処理を含む）」「運営資金の確保」「実施体制の整備」「その他」「特になし」の中から，機関リポジトリの構築予定がない機関に対しては「運営資金の確保が困難」「専門知識のある人材が不足」「その他」「特になし」の中から該当する課題を選択させている．図3では，それら複数の課題の中から特に資金面と体制を含む人材面の課題に絞って図示している．

特に図3の課題「システム構築」「専門知識がある人材が不足」の減少は，従来機関が抱えていたシステムに関する知識不足がJAIRO Cloudの導入により一定数の解決につながったことが影響しているものと推察される．JAIRO Cloudの導入により，機関はシステム構築や管理といったシステム的な課題から，機関リポジトリの維持管理といった，機関にとってより本質的な課題に注力できるようになったといえる．

3.2　効率的な運用のためのシステム設計

JAIRO Cloudでは運用コストの削減を目標にシステム設計を行った．WEKOの効率的なデプロイを実現するため，サーバ専有型，バーチャルホスト型，マルチテナント型の比較検討を行った（図4）．サーバ専有型はサーバ1台に一つのWEKOをデプロイする手法である．ただし，サーバ台数がそのままリポジトリ数となるため，将来的なサーバ管理コストの増大が予想された．バーチャルホスト型はWebサーバのバーチャルホスト機能を用いてサーバ1台に複数のWEKOをデプロイする手法である．バーチャルホスト型はCPUやメモリだけでなく，オペレーティングシステム（OS）領域を含むハードディスク領域の共有を行うため，サーバ専有型と比較して費用を抑えることができる．一方で，複数のリポジトリでサーバを共有することから，一部のリポジトリに負荷が集中した場合に，サーバを共有する他のリポジトリにも影響がでたり，サーバ障害時は当該サーバで動作しているすべてのリポジトリに影響が発生する．マルチテナント型は，アプリケーションレベルでの多重化を実現することで，サーバ1台で複数リポジトリの提供を可能にする．マルチテナント型はアプリケーションレベルでの実装となることから，ライブラリレベルの共有も可能となり，バーチャルホスト型と比較してさらに費用を圧縮できる．しかしながら，アプリケーションの改修が必要であり，開発が複雑化することから，最終的にJAIRO Cloudでは，バーチャルホスト型を採用した．

JAIRO Cloudで採用したサーバ仕様は，CPU6コア，メモリ16 GBのサーバで，OS領域として20 GBのSSD（Solid State Drive）と備える．データ領域として250 GBおよび500 GBの2種類のハードディスクを用意した．250 GBのハードディスクを備えたサーバは高密度サーバと称し，規模の小さいリポジトリをデプロイするのに用いた．500 GBのハードディスクを備えたサーバは低密度サーバと称し，規模の大きいリポジトリをデプロイするのに用いた．表4にサーバ1台あたりのリポジトリ集約数を示す．規模の大小については，機関リポジトリに登録されているアイテム数が5万を超える場合は大規模リポジトリ，アイテム数が5万を下回る場合は小規模リポジトリとした．JAIRO Cloudが対象とする機関リポジトリは文献リポジトリであり，アイテムあたりのコンテンツ容量は700 KB程度であることが多いため，アイテム数の大小が高密度，低密度サーバへの振り分け判断基準となっている．

次に，JAIRO Cloudの統合認証機能について説明する．本機能は，複数のサービスをまたいだサービスの提供など，JAIRO Cloudの将来的な機能拡張を想定して実装された機能である．たとえば，名古屋大学が実施した「クラウド環境における電子出版・リポジトリ連携実証実験」[18]で実施された汎用リポジトリソフトウェアとOpen Journal Systems（OJS）との連携を行う際，JAIRO Cloudの統合認証機能経由でOJSへのログインを実現することができる．この統合認証により，JAIRO Cloudとのシームレスなシステム連携を実現できる．

また，JAIRO Cloudの統合認証機能では，機関の担当者が自機関のユーザ管理を行うことができる仕組みとなっている（図5）．すなわち，JAIRO Cloud側でのユーザアカウント発行は機関担当者一つだけでよく，他のユーザアカウントについては，機関担当者のユーザアカウントで発行可能である（図6）．この統合認証機能により，JAIRO Cloudとしてのユーザ管理工数を減らし，システム全体の運用コストを削減した．

3.3　JPCOARとの共同運営による効率化

JAIRO Cloudの特徴の一つは，利用者コミュニティとの互恵的な関係のもとで，サービスとして成長してきた点である．JAIRO Cloudという全国レベルのサービスを，どのようにサポートしていくかは，大きな課題の一つであった．たとえば，システムの利用方法についての問い合わせがあった場合，NII単独でのサポートを考えた場合，NII対利用機関という一対多の関係となり，NIIの処理能力以上のサポートはできない．サポートを増員した場合には，直接的に運用コストが高くなるという問題がある．

JAIRO Cloudでは，利用機関同士の相互のサポート体制を採用することにより，こうした問題に対処することとした．サービス開始当初は，比較的緩やかなコミュニティにおいてサポート体制を構築していき，2016年7月に設立したオープンアクセスリポジトリ推進協会（JPCOAR）の設立に伴い，より組織的な体制構築へと移行した．JPCOARは大学図書館を中心とした機関リポジトリの普及とコミュニティ強化を目的とした任意団体である．

JPCOARの参加機関数は2020年3月時点で638機関であり，そのうちJAIRO Cloud利用機関は575機関である（図7）．JPCOARの事業はオープンアクセスを推進するための四つの戦略，1）研究データの公開および流通に関する先導的な取り組み，2）学術情報流通基盤整備によるコンテンツ流通および活用の促進，3）参加機関全体の底上げを図るコミュニティの機能強化，4）新しい時代を担う中核的な人材育成，に賛同し日本の機関リポジトリの在り方を改革したいと考えている参加機関の有志によって実施されている．実際の運営は運営委員会，作業部会および事務局で実施されており，運営委員会は主に国公私立大学図書館管理職から構成される15名，作業部会は主に国立大学図書館関係者から構成される約70名，事務局は3名で活動している．作業部会に参加する動機であるが，機関リポジトリ等の学術情報流通に関する最新動向にアクセスしやすくなる，関連する知識や技術を深めることができる，JAIRO Cloudや関連システムへの関与ができるといった点が挙げられる．

図8は現在のJAIRO Cloudの運用体制を示したものである．JAIRO Cloudは，NIIとJPCOARとの共同運営と位置付け，運用に関する役割分担を明確にした．現状では，コミュニティサイトやユーザ窓口等の運用はJPCOARが担当し，JAIRO Cloudの開発はNIIが担当している．JAIRO Cloudへの移行相談会や機関リポジトリ新任担当者研修の実施といったサービス支援を，利用者間で実現することで，NIIにおける運用コストを軽減することに成功した．JAIRO Cloudの利用費は，利用する機関の構成員数により異なる．構成員数が100名以下の場合は，JAIRO Cloudの利用料は年額4万円でJPCOARの基本会費と含めても年額6万円で機関リポジトリを構築することができる（表5）．その一方で，利用機関のサポートや利用者講習などの教育をJPCOARがコミュニティとして担当することで，NIIはこのための費用を計上せずに，システムに関する費用のみに集中することができる．JAIRO Cloudが安価な利用料を設定できた背景には，こうしたJPCOARとの役割分担に依拠するところが大きい．

4.　JAIRO Cloudとコミュニティ

利用者コミュニティとの協業こそがJAIRO Cloud成長の鍵

JAIRO Cloudは，利用者コミュニティとともに成長してきた機関リポジトリサービスである．2012年のサービス開始から着実に導入機関を増やしていき，2020年7月時点では625もの機関がJAIRO Cloudを利用している（図9）．本章では，より具体的に，コミュニティがどのようなサポートを実践し，コミュニティ活動がサービス運用に機能していったかについて述べる．

4.1　説明会の実施

NIIではJAIRO Cloudの普及に向けて，利用者コミュニティの立ち上げを意識しながら，表6に示すように，2012年から2015年にかけて各地でJAIRO Cloudの説明会を開催した．地方での説明会開催の際は，ホストとなる大学に事例紹介という形でJARIO Cloudを利用したリポジトリの構築や機関リポジトリに関係する話題提供を依頼し，利用者コミュニティ主導という流れを徐々に作り上げていった．こうした事例紹介を依頼しながら，講師の育成を努めていった．

2016年には，JPCOARの前身となる，機関リポジトリ推進委員会による「機関リポジトリ新任担当者研修」の教材としてJAIRO Cloudが取り上げられるようになっていった．ここでの受講生が，次の研修の講師となるように意識して年度ごとの研修を企画した．こうした流れを作ることで，次第に利用者コミュニティ主導の人材育成という観点での説明会や講習会へと展開することに成功した．

2016年7月以降は，JPCOARが新任担当者研修を担当することになり，研修事業が継続された．利用者コミュニティによる研修サイクルを繰り返すことで，人材育成を行いつつ，次世代の指導者を育てていくというプロセスが熟成されていった．

4.2　既存機関リポジトリからの移行

JAIRO Cloudの導入機関数が増加するにつれ，新規に機関リポジトリを構築するといった要望だけでなく，すでに機関リポジトリを導入している機関からの移行に対する要望がでてきた．システム維持の継続性の課題解決や，JAIRO Cloudの新しい機能の利用が，移行を希望する主な理由であった．JAIRO Cloudでは，こうした要望に対応するために，2013年度から2014年度にかけて，他システムからの移行を希望する機関と協力した移行実験を実施した．その際，対象となったシステムは「DSpace（Ver.1.4，Ver.1.5，Ver.1.6）」「NALIS-R」「XooNips」「E-Repository」である．こうした移行実験においても利用者コミュニティ主導で作業が行われるように，表7に示すような手順を整えていった．

データ移行の手法については，WEKOを利用するツールとして開発を進めていた，コンテンツの一括登録アプリケーションを利用した．既存のシステムからTSV形式でデータを抽出し，それをWEKOのメタデータ形式にマッピングすることで，JAIRO Cloudへの移行ができるように作業が進められた．サンプルデータによる登録を試したのち，大量データ移行を行い，その結果を評価した．具体的な評価内容としては，移行元のリポジトリから移行先のリポジトリに正しくレコードが移行できているか，大量のデータ登録の際にシステム的な問題が発生しないか，移行作業に必要な作業工数はどれくらいであったかを評価した．実験に参加した筑波大学，信州大学，核融合科学研究所，旭川医科大学，千葉大学，山形大学の機関リポジトリをJAIRO Cloudに移行することに成功し，WEKO以外の他のリポジトリソフトウェアからの移行にWEKOが対応できること，また規模の大きなリポジトリの移行にも耐えられることを示した．また，移行実験全体としては，JAIRO Cloud移行機関への情報提供やノウハウ提供のために利用されることにつながった．

4.3コミュニティサイト

NIIでは，図10に示すようなJAIRO Cloudではコミュニティサイト^*1を提供することで，利用機関による相互の情報交換の場を提供した．JAIRO Cloud説明会資料等もコミュニティサイトに集約させ，コミュニティサイトとしてのコンテンツ拡充を進めていった．

コミュニティサイトにおいて特に重要な役割を担ったのは，フォーラムの機能である．フォーラムでは，利用機関からの問い合わせに対して，利用機関が回答するといった形で利用者コミュニティの育成が進められていった．必要に応じてNIIのJAIRO Cloud担当者が議論に参加し，議論をリードすることもあったが，それも講習会等の実施が進むにつれて，講習会の講師がフォーラム担当となるといった議論を活発化するための取り組みを行われてきた．図11にフォーラムの活用状況を月ごとに可視化したものを示す．多い月には23のスレッドが立ち上がり，合計107のメッセージがやり取りされていた．月日が経つにつれてフォーラムのメッセージ数は減少しているが，これはJAIRO Cloudの機能が安定化してきたのとコミュニティとしての習熟度が上がってきたことが影響しているものと推察される．

こうしたコミュニティサイトの成長もあり，当初NIIが主導していたサポート体制も次第に利用機関コミュニティに移行し，NII単独では決してなし得なかった，サポート体制の実現につなげることができた．

5.　JAIRO Cloudの現状と課題

5.1　システムの現状

JAIRO Cloudのリソース集約は主にCPUのコア数，メモリ容量を中心に実施され，ディスク容量については，コンテンツ登録数の増加に伴い対応を検討するという場あたり的なものであった．

2020年7月時点のJAIRO Cloudが提供する機関リポジトリのアイテム数，ディスク使用量の分布を図12に示す．これより，全体の約97%がディスク使用量40 GB未満，アイテム数20,000未満であった．JAIRO Cloud全体でのアイテム総数は約174万，ディスク使用量は約3.3 TBであった．サーバ全体でのディスク容量は10 TBあり，現状は全体の約3割程度の使用量であった．ディスク使用量の観点からみると，サーバの集約数はまだ改善の余地がある．

5.2　課題

JAIRO Cloudは利用機関コミュニティとともにサービスを成長させてきた．JAIRO Cloudの利用機関を増やすという観点からは，この利用機関コミュニティが予想以上の機能を果たしたと考えられる．しかしながら，汎用リポジトリソフトウェアの開発そのものを，利用機関と連携して実践する観点については，まだ改善の余地がある．現状でも，機能改善に関する調査を実施しながら開発を進めているが，特に新しい機能や仕様の策定に際し，利用者からの積極的な関与を得るには至っていない．特に，今後のオープンサイエンスの展開を見据えた研究データへの対応については，開発機関と利用機関が世界の先進的な動向を把握したうえで，機能の高度化に取り組んでいく必要がある．

また，これまで文献リポジトリとして活用されてきたJAIRO Cloudにて，利用機関や分野が求める研究データに関する要望，具体的にはデータのバージョン管理や多様な研究データ受け入れワークフローなどに，いかに対応していくかは課題である．特に分野のデータリポジトリに対応していくには，これまでの機関リポジトリの枠に囚われない，分野としてのリポジトリをいかに実現し，提供していくかの検討が必要である．

6.　おわりに

本稿ではJAIRO Cloudの構築の経緯から，設計ノウハウ，コミュニティ主導のサービス普及を，どのように進めてきたのかについて述べた．JAIRO Cloudという625機関が利用するサービスを効率的に提供していくためには，利用機関との密接な連携が不可欠であった．特にコミュニティを育成していく過程では，利用機関主導型の仕組みが重要な役割を果たした．

現在，NIIでは研究データのライフサイクルに沿って，研究データを管理・公開・検索するNII Research Data Cloud（NII RDC）の開発を進めている．NII RDCでは，研究データの公開基盤として汎用リポジトリソフトウェアWEKOの後継ソフトウェアの開発を進めており，次期JAIRO Cloudの基盤ソフトウェアとして採用予定である．後継ソフトウェアでは，これまでの文献リポジトリ機能としてのWEKOの機能性は踏襲しつつ，研究データ対応に向けた機能，バージョン管理機能の強化，ワークフロー機能の強化，ソフトウェア・システムとしての拡張性の課題に取り組んでいる．また，次期JAIRO CloudはNII RDCの研究データ公開基盤として，研究データ管理基盤GakuNin RDMや研究データ検索基盤CiNii Researchと密接に連携しながらサービスを展開予定である．

今後は，これまでのJAIRO Cloudでの利用機関コミュニティとの協働を更に強化しながら，研究者中心のNII RDCの公開基盤として，研究開発と安定運用を両立させたオープンサイエンス時代の新しい機関リポジトリサービスとして発展させていきたい．

謝辞　JAIRO Cloudは国立情報学研究所の歴代の学術コンテンツ課のリポジトリ担当係長である，小林廉直氏，塩崎亮氏，前田朗氏，田口忠祐氏，また基盤運用を担当されていた三浦竜哉氏の多大なる貢献のもと実現されてきた．ここに感謝の意を表する．また，JPCOAR各作業部会関係者，JAIRO Cloud参加機関各位の多大なるご協力に感謝を表する．