平成 24～28 年度
文部科学省私立大学戦略的研究基盤形成支援事業

オペラ資料のアーカイヴ化を通じた情報センター機能の構築
研究成果報告書

平成 29（2017）年 5 月
学校法人東成学園・昭和音楽大学オペラ研究所
Opera Research Center, Showa University of Music

目次

はじめに

……

003

第1章

研究の概要

……

005

第2章

調査・研究の記録

……

009

第3章

ウェブデータベース『オペラ情報センター』

……

023

第4章

公開講座、会議等の記録

……

029

第5章

『オペラ情報センター』の展開と課題

……

037

資料篇

Ⅰ オペラ情報センターのウェブサービスについて

……

041

Ⅱ 『オペラ情報センター』入力項目

……

065

昭和音楽大学『オペラ情報センター』
http://opera.tosei-showa-music.ac.jp/search/

はじめに
昭和音楽大学オペラ研究所では、文部科学省による「私立大学戦略的研究基盤形成支援事業」による補助を受け、「オペラ資料のアーカイヴ化を通じた情報センター機能の構築」をテーマとした研究事業を、平成 24 年度から平成 28 年度の 5 ヵ年にわたり実施してまいりました。
本研究を立ち上げた背景には以下のようなことがあります。
オペラ研究所は、『日本のオペラ年鑑』編纂事業を通じて、我が国で開催されているオペラ公演を記録する作業を 20 年以上にわたり行ってきました。これまでに各地に整備されてきた複数の本格的なオペラ公演が可能な劇場、およびその他にも多くの会場で行われているオペラの全幕公演は毎年 1,000 回以上もあります。その中には、新たに創作された作品や日本初演の作品のほか、海外の歌劇場との共同制作や国内の会館同士の共同制作等の事業も多く行われ、さらに各地域のオペラ団体が行う公演、市民オペラ等の形態もある等、様々な作品が、多様な主催者により多彩な形で上演されています。
今回は、これまでに行ってきた様々な研究成果により、オペラ研究所が蓄積してきたオペラ
公演記録を精査してインターネット上で公開する作業に加え、当研究所で所蔵している数々のプログラム、チラシ、音源等をアーカイヴ化する作業を行ってきました。これらを可能なところから、幅広い方々に活用していただこうという発想のもと、本研究を実施したのです。さらに、国内だけではなく、国外からのアクセスしていただくことも可能にするため、日本語に加えて英語でのデータ化も行いました。これらは、国内外の研究者等によるデータ活用につながるのみ
ならず、過去の上演記録を通じて、新たな舞台をつくる制作者の方々にも今後の活動に役立てて頂けると考えています。結果として、国内海外を問わず、新たな舞台のキャスティングや創造のヒントへと、具体的な成果につながることを願っています。
本研究では、複数の公開シンポジウム、公開講座、公開研究会を実施し、それらの成果を広くオペラ関係者、学生、研究者、一般の方々とも共有しながら、5 ヵ年の研究期間を終えることができました。この報告書は、今回の研究成果を一層多くの方々と確実に共有するためにまとめたもので、他ジャンルのアーカイヴ事業等にも参照していただければ幸いです。そして、本研究が国内外のオペラ発展への一助となることを願ってやみません。

2017 年 5 月
昭和音楽大学 オペラ研究所所長

石田 麻子
3

第1章

研究の概要

5

1. 研究の背景と目的
1900 年代初頭に日本人の手で最初の公演がなされて以降、日本のオペラの歴史は最初の一世紀を過ぎたところである。昭和音楽大学オペラ研究所（以下「当研究所」と略記）は、『日本のオペラ年鑑』の編纂に 1995 年度版より携わってきたほか、『日本オペラ史』の刊行（上巻・2003 年および下巻・2011 年）や、「日本オペラ」の情報・資料およびその活用についての調査『オペラを中心とした音楽情報・資料の収集および活用に関する調査研究』（2009 年）を行
うなど、日本国内の劇場、団体との繋がりを持ちながら、日本におけるオペラ公演資料の収集、蓄積を進めてきた。また、過去に開催した多くの公開講座などを通して、海外の歌劇場や団体とのネットワークも有している。
本プロジェクトは、当研究所がいままで蓄積してきた歴史的意義のある資料の整理、および更なる収集をおこない、それらをアーカイヴ化することにより、オペラに関する情報の集積・活用拠点として、オペラ情報センターを構築することを目的とする。
アーカイヴには、蓄積した「過去」に関する資料の整理と保存という意味合いのみならず、あらゆる資料が体系化された情報となることによって、それが研究や考察へと繋がり、未来のより優れた創造の礎となる意義がある。
本プロジェクトによって組織の枠組みを超えて、国内初のオペラ情報の集積・活用の拠点が形成されれば、新しく公演を企画するために多くの情報が必要となる制作者や、オペラ公演について幅広く情報を得たい鑑賞者にとって有益であるだけでなく、研究者による統計、分析のための資料を提供することができ、また国内外への情報提供の窓口になるなど、日本におけるオペラ文化の振興と普及、さらには海外への発信に大きく寄与することが期待される。
また、オペラは演劇、オーケストラ、合唱、バレエなど、多分野の芸術の要素を併せ持つ総合芸術であることから、オペラにおけるアーカイヴ手法を構築し提示することは、他の芸術分野のアーカイヴ構築を促進するモデルとなりうる。

2. 事業実施体制
本プロジェクトの研究員は、オペラ公演の制作やオペラ作品の研究を専門とする本学の教員の他、日本オペラ振興会（藤原歌劇団・日本オペラ協会）、東京二期会、新国立劇場、日本放送協会など、国内の主要なオペラ関連組織の代表者、責任者、制作者（元職を含む）、およびアーカイヴ化や公開手法に精通している研究者により構成されている。
プロジェクトには次の①～③の 3 つの研究グループを設置する。各研究員はそれぞれの専門により、ひとつあるいは複数の研究グループに所属し、プロジェクトを推進する。また、当研
6究所内に事務局を置く。

（1）プロジェクト研究員（所属・役職等は 2017 年 3 月末現在）
石田 麻子

昭和音楽大学 教授

大仁田 雅彦

昭和音楽大学 教授

岡山 廣幸

元昭和音楽大学 教授 （2015 年逝去）

小畑 恒夫

昭和音楽大学 教授

岸田 生郎

昭和音楽大学 教授

酒井 健太郎

昭和音楽大学 准教授

下八川 共祐（公財）日本オペラ振興会 常務理事

杉 理一

ニュー・オペラ・プロダクション 代表（元 NHK プロデューサー）鈴木 とも恵昭和音楽大学 准教授

富永 直人（公財）日本オペラ振興会オペラ歌手育成部 講師、イタリア語通訳・翻訳

中山 欽吾（公財）東京二期会 常務理事、大分県立芸術文化短期大学 学長

仁科 岡彦（公財）日本オペラ振興会事業部 部長

根木 昭

元昭和音楽大学 教授 （2016 年逝去）

溝上 智恵子筑波大学大学院図書館情報メディア研究科 教授

山口 毅（公財）東京二期会 事務局長、同制作部 部長、同マーケティング部 部長（2）研究グループの構成
・研究統括（研究代表者）： 根木（2016 年 3 月まで）
石田（2016 年 4 月から）

・

統括補佐：

石田

①オペラ情報・資料の整理・収集グループ（*は責任者、以下同）構成員

根木*、大仁田、岡山、小畑、石田、岸田、酒井、下八川、杉、鈴木、富永、中山、
仁科、山口

役割

i. 資料整理方法についての検討
ii. デジタル化する資料の選別
iii. 資料の種類、状態に適したデジタル化手法の検討および実行

7

iv. 資料の収集対象や、寄贈を受け入れる資料の判別と選定
v. アーカイヴ化における優先順位の決定②オペラ情報・資料のアーカイヴ化グループ
構成員

小畑*、石田、岸田、酒井、杉、仁科、根木、溝上役割

i. 物理資料およびデジタルデータの蓄積方法の検討
ii. ウェブデータベースの設計および構築
iii. 資料情報の入力体制の構築③オペラ情報・資料の公開グループ
構成員

石田*、大仁田、下八川、鈴木、富永、中山、根木、溝上、山口役割

i. 陳列・公開方法の検討
ii. ウェブデータベース公開における著作権処理等の調査、検討
iii. 外部連携等の模索

8

第2章

調査・研究の記録

91. アーカイヴの目的
日本人の手で初めてオペラ上演の試みが行われたのは、1903 年に東京音楽学校奏楽堂
で上演されたグルックの《オルフォイス》（オルフェオとエウリディーチェ）である。以来、日本でのオペラの歴史は一世紀と少しが過ぎたところであり、日本では比較的若い芸術分野と言える。
そうした事情があって、オペラの上演自体が盛んにおこなわれてきた一方、その記録や資料の保存・整理が重視される段階に至っておらず、結果として、日本におけるオペラ上演記録を情報として蓄積し、俯瞰・分析する視点は十分に定着していない。しかし、日本のオペラ上演の歴史がそれほど長くないということは、今ならまだその多くの資料を収集、整理、保管できる可能性があるということである。
当研究所は、プロやアマチュア、劇場や制作団体の種別を問わず、オペラ上演に関する資料の収集を継続的におこなっている唯一の機関である。このプロジェクトを足がかりに、今後ともオペラの上演に関する資料を収集、整理、アーカイヴ化を継続していく予定である。これを通じて資料の散逸を防ぐとともに、オペラの上演に関する情報基盤となることで、日本におけるオペラ上演の指針を与え、今後の日本オペラのより豊かな発展へと寄与しうるものと考えられる。加えて近年、急速にオペラ公演事業に傾注する中国や、すでに公演実績のある韓国に対しても、本プロジェクトをリーディングケースとして参考に供することも可能である。

10

2. アーカイヴ対象の種類と性質（1）「オペラ関連資料」
当研究所の所蔵資料は、『日本のオペラ年鑑』や『日本オペラ史～1952』『日本オペラ史
1953～』の編纂にあたり収集した資料、及び団体・個人から寄贈を受けたオペラ公演関連資料から成る。これらは概ね以下のように分類できる。

①オペラ公演に際して発行されたもの
a. チラシb. パンフレット

整理前の資料の架蔵状況②オペラ公演を記録したもの
a. 写真

整理前の写真の所蔵状況

11

b. 映像（ビデオテープ等）

所蔵する U マチックテープの一部

c. 音声（オープンリールテープ等）

所蔵するオープンリールテープの一部③オペラに関する資料で寄贈を受けたもの
a. 書籍
b. スコア（楽譜）c. オペラ制作団体の資料

大賀寛氏より寄贈の資料

12

（2）「オペラ上演情報」
当研究所が編纂・刊行してきた『日本のオペラ年鑑』及び『日本オペラ史～1952』『日本オペラ史 1953～』は、日本におけるオペラ上演の記録を辿ることを主眼としている。それゆえ当研究所には資料だけでなく、その資料を元にしたオペラ上演「情報」が作成されている。それらが整備されれば、日本におけるオペラ上演史を一望できるものとなる。

3. アーカイヴ方法の検討（1）資料保存方法
プロジェクトが開始されるまで、当研究所の資料保管には一貫した指針がなかった。たとえば『日本のオペラ年鑑』編纂の為に収集した資料については、公演団体別にまとめてあったり、あるいは時系列に並べてあったりなど、収集・活用・整理した時期によって異なる整理方法が採られていた。そのうえ、他の事業のためにそこから抜かれて、別にまとめられている資料群があった。さらに、寄贈資料については、寄贈を受けた当時の状態のまま保管している場合が多く、そのおよそ半分は目録が作成されていなかった。
このような現状把握から、まず必要なのは、資料を何らかの秩序に従って整理することと考えられる。そこで、このプロジェクトはこれらの資料の整理手法の検討から着手することとなった。

（2）アーカイヴとライブラリ
資料の整理手法の検討するにあたり、当プロジェクトの研究員である溝上智恵子氏（筑波大
学 図書館情報メディア系 教授）のご紹介により、二人の専門家に話を伺った（所属・役職等
は当時）。
白井哲哉氏（筑波大学 図書館情報メディア系 准教授）
宇陀則彦氏（筑波大学 図書館情報メディア系 准教授）

白井氏はアーカイヴズ学がご専門で、埼玉県立文書館等において古文書等の目録編纂に長く携わり、歴史資料の調査・整理・保存方法について精通されている。
当研究所の資料は古文書ほどの歴史を持つものではないが、より慎重に扱われるべき資料
群の整理の方法論を知ることは、当プロジェクトを進めるうえで大きな指針を与えてくれた。
資料群には、現状がどんな形態であれ、それを形作った人の何らかの思想が介在している。
そこで、まずはそのまとまりをひとつの単位とし捉えて秩序を保存する（原秩序の尊重）のがアーカイヴ構築の原則であるという。そのほかにも、出所の違う資料を混合しないことや、保存の13

方法を変更しないこと、またもしそのままの保存が叶わず、修復、移動などを行う場合でも、初期状態から処置後までの写真・記録を残すなど、保存方法自体を資料に付帯する貴重な情報として保管するという、アーカイヴ構築の思想があるという。

宇陀氏は、博物館等が備えるデータベースを相互利用するためのメタデータを策定するプロ
ジェクトに関わるなど、よりよい図書館システム利用についての研究者である。宇陀氏には、アーカイヴ構築の思想を大切にしつつも、それをどのようにデータベースに格納して、利用しやすくするかという視点から、ご教示いただいた。昨今、メタデータ（情報をコンピューターに理解しやすくするために着けるタグ項目）の標準化が世界で進められている。それに準拠することによって、他のデータベース等から参照してもらいやすくなるという。
また、「アーカイヴズ」と「図書館（ライブラリ）」は、一見、似ているが、実は根底に流れる思想がまったく違うという。アーカイヴズは、「いま、ここ」にあるものをそのままの状態で保存することを重視するが、図書館は情報を利用（しやすく）することを重視する。そのため、前者は資料をもとあったまとまりのままに保管するのに対し、後者はある体系にもとづいて資料を再構成し、整理することになる。

次に、白井・宇陀両氏よりご教示いただいた事項を当研究所にどう適用させるか検討した。
当研究所が所蔵する資料は、古文書と言えるほどの古さを持つものではないが、ほとんどが１回のオペラ上演のために作成された資料であり、書籍より発行部数が少なく、また再生産されることはない。現状ではこれらはひとつの体系に基づいて分類されてはいないが、資料の個々のまとまりを見ると、それぞれに収集当時の意図や思想が伺える。ついては、これらのまとまりのあり方をも情報として保管するため、現状の資料についてはアーカイヴの思想を適用し、「原秩序」を尊重することとした。

（3）目録のデータベース化
しかし、そのままだと検索性に劣る。目録を作成することで検索性を増す必要がある。その際には、資料にメタデータを付加し、年代や種類、名称などで検索できるようにすれば、実資料へのアクセスがより容易になる。そこで、資料自体の保存の方法を変更することなく、目録の仕組みをデータベース化することで、つまり、資料の保管は現状あるがままに沿い、時系列などの新しい体系で再構成することはせず、分類や検索は目録上で行うことで、現秩序の尊重と検索性の向上を実現することとした。

14

データベース作成にあたっては、図書館・博物館などの先行データベースで使われているメ
タデータ項目など、既に標準化されているものがあれば、それを可能な限り採用することで、他データベースとの連繋をしやすくすることにした。目録は、時流に沿い、ウェブデータベース
によって作成することにした。

（4）「資料」と「データベース」の紐づけ① ID の付与
資料とデータベースを対応させるためには、すべての資料にそれぞれ固有の識別番号（ID）を付与する必要がある。まず、すべての資料を、元の秩序を保ったまま、フォルダ、ファイルボ
ックス、ダンボールなどのケースに格納した。それを保管場所（棚など）に並べ、何枚目の棚板の何番目のケースか、そのケース内で左から何番目に入っている資料か、また、その資料が封筒などの場合はその封筒内で何番目の資料か、という規則で各資料に ID を付与した。

（例） 資料 ID「A23456_789」は、A の棚の 2 枚目の棚板に収められた、34 番目のケース（フォルダ等）中の 56 番目の封筒に入った 789 番目の資料であることを示す

このようにして、各資料に固有の ID を付与した。

実際の資料整理にあたっては、白井氏と、冨善一敏氏（東京大学経済学部 図書館資料室／所属・役職等は当時）に実際に当研究所にお越しいただき、アドバイスをいただきながら行った。

②目録を超えたデータベースへ
資料目録をウェブデータベースとして作成する際に、資料に関するデータ（資料の形態、内容、著者等の書誌情報）と、オペラ上演そのものに関する情報（公演の記録、日時、会場、出
演者、作品等）を関連付ける（紐づける）ことができれば、資料から上演の記録、逆に上演の記録から資料を検索でき、有用性が増すだろう。そこで、当プロジェクトは、オペラに関連する資料のアーカイヴ化だけでなく、同時にオペラ関連の「情報」をアーカイヴすることも目論んでいる。

15

（5）ウェブデータベースの検討①構築体制の検討
ウェブデータベースを作成したいという希望に至ったが、この分野についても、我々の専門外であった。前述の宇陀氏より、永崎研宣氏（一般財団法人人文情報学研究所 主席研究員・所長、東京大学大学院情報学環 特任准教授／所属・役職等は当時）をご紹介いただいた。永崎氏は、デジタルヒューマニティーズという、人文科学分野とコンピューティングを結びつける分野の専門家で、ローカル情報（言語）に特化しがちな人文資源を、世界的に相互利用・有効活用するための様々な方法論を研究されている。
永崎氏には、人文科学分野でのメタデータの世界的な活用の動きをご教示いただいた。メタ
データに配慮され設計されたデータベースは、他のデータベースや海外から参照されることが容易になり、より有用性が高まる。

プロジェクト開始時点で、世界中で先行して作られているウェブデータベースを調査した。中にはオペラ上演に特化したデータベースも存在するが、それらは主に、観客が参考にするための上演記録の基本情報を載せているのみで、プログラムなどから情報を拾い上げるレベルのものは存在しなかった*。
* 例えば Operabase（http://operabase.com/）は、一般向けの無料コンテンツでは得られる情報は限られるが、劇場関係者、アーティスト向けの有料部分ではより詳細な情報が得られるようになっている。

そこで、当研究所は一からウェブデータベースを作成することにした。ウェブデータベース自体は、業者を選定し発注すれば何らかの完成はみられる。しかし、オペラの書誌情報とオペラ上演情報を一体化させ、また、メタデータを揃えたデータベースの作成を希望するとなると、当研究所と開発業者との間で、相当の意思疎通の必要性があると判断した。
そこで永崎氏に、我々と開発業者の橋渡しをしてくれる人物をご紹介いただき、岩崎陽一氏（ナクソス・ジャパン株式会社 技術顧問、東京大学大学院人文社会系研究科インド哲学仏教学研究室 特任研究員／所属・役職等は当時）にお願いすることとした。
岩崎氏はクラシック音楽配信サービス NML（ナクソス・ミュージック・ライブラリー）の開発に携わっており、クラシック音楽に関わるウェブデータベース作りに多くの知見と経験をお持ちであった。そこで、岩崎氏にウェブデータベース開発ディレクターをお願いし、我々と開発業者双方の窓口となっていただき、全体進行を委託することとした。
また、開発は初期開発を株式会社ウィザード、リファクタリング（再構築）以降の追加開発を株

16

式会社アクセライトに委託した。

②データベース構成の検討
データベースを構築するにあたり、我々が希望する要件を挙げると下記のようになった。


物理資料の目録となること



物理資料が検索できること



物理資料の書誌情報が格納されていること



物理資料に対応した公演記録が格納されていること



物理資料・上演記録の双方から双方が検索できること「メタデータ」が付与されたデータベースであること

また、物理資料・上演記録の検索方法としては、日時や会場、団体名などの他に、「上演作品」で検索することが考えられる。検索の際は作品名の他に、作曲者名、役名などが使われる
場合があり、一通りの情報を揃えておく必要がある。従って、上記に加え、オペラ作品情報もデータベースに格納することとした。

以上の検討を踏まえ、ウェブデータベースは下記三つのデータベースの複合体とすることにした。

a. 公演記録*
b. オペラ作品情報
c. 所蔵資料*「上演記録」ではなく「公演記録」としたのは、複数回の上演がまとめられて「一公演」とされ、プロ
グラム・チラシ、チラシが作られている場合に対応するため。所蔵資料に対応する単位としては「公演記録」を採用した。

こうして作成が始まったウェブデータベースは本プロジェクトの基幹事業となり、最終的に『オペラ情報センター』という名称でインターネット上に公開された。特徴などは次章を参照のこと。

17

（5）データ入力体制の構築①入力項目の策定『オペラ情報センター』の管理サイト（情報登録サイト）では、「公演記録」「オペラ作品情報」「所蔵資料」のそれぞれが、数多くの入力項目により構成されている（全項目については資料
篇Ⅱを参照）。パンフレットやチラシから公演等に関する情報をどう拾い、どの項目に入力するのかの判断や、入力時の方式の統一など、実際の入力を繰り返しながら、ルールを作成した。
入力項目は、当初設定した段階では、多くの例外が発生した。一年程度をかけて何度もテス
ト入力を繰り返し、複数人によるチームで検討しながら、現在の入力項目に収束させた。

②入力体制
入力には間違いが発生しないよう、システムで制御できる部分は工夫をしたが、多くは入力者の経験に頼ることとなる。入力者は必ずしもオペラに精通している必要はないが、数多くの項目の対応を覚え、正確に入力する必要がある。
新規入力担当者は、当初一か月ほどは、マンツーマンでの入力作業を行う。また、すべてのデータは入力者以外によるダブルチェックが行われてから公開の承認がなされる体制とした。
また、研究所内の人員では入力件数に限界があるため、外部業者に入力委託を行うこととした。入力業者は、カスタマイズされたデータベースに柔軟に対応し、学習し、入力の正確性が担保される人員を有していることが必要とされる。各社を検討した結果、図書の書誌情報の入力経験が豊富な人員を揃えた（株）図書館流通センターに依頼した。

③入力委託
入力業者は、オペラの知識に専門性を有しているわけではないが、入力に関してはプロフェッショナルである。細かな表記の揺れに対する感覚や、例外の発見などは、むしろ示唆を受ける部分が多く、単なる委託ではなく、当研究所と互いに協力し、入力体制を構築する関係となった。

④入力情報の濃淡『オペラ情報センター』の三つのデータベースの中では「公演記録」の入力項目が最も多い。
「公演記録」は、プログラムに記載されているスタッフ・キャストのすべての人名と仕事（役名・職名など）が転記されていることが最も理想的である。しかし、オペラ公演に関わる人員のバリエーションと人数の多さから、プログラム一冊の入力（日英両語／複数の上演記録が掲載されて18いる場合）には、慣れている入力者でも一日かかることがある。
これではウェブデータベースとして十分な件数を備えるには相当の時間を要してしまう。そこで検討の結果、オペラ研究所が把握している公演記録の網羅を優先することとした。先に日時、公演団体、演目などの基本情報だけをすべて入力し、キャストなどの詳細情報については、主要な団体の公演を中心に、データの追加入力を行った。
現時点で、当研究所が編纂に関わってきた『日本のオペラ年鑑』1995 年度版～2015 年度版に記載されている公演の基本情報はすべて掲載している。先に「公演記録」の基本情報を入力しておくことは、公演インデックスともなるため、資料登録をする際の紐付けにも大変有用であった。

「公演記録」登録件数（2017 年 5 月 31 日現在）
全公開数：7,359 件 （1 公演（1 プロダクション）単位）
内キャストなど詳細情報入力数：1,580 件（7）資料保存の検討①劣化対策
当研究所の保有する資料は、古文書ほどの古さを持つものではないが、紙資料、写真、オープンリールテープなど、肉眼で劣化が確認されるものも多い。本プロジェクトでは、保有する資料の劣化をできるだけ食い止めると共に、今後の効果的な保存方法についても検討した。

i. 中性紙保存資材の購入
現状の資料保管方法は、通常の事務用品として販売されているファイルボックス、そのほか
はプラスチックケース、段ボールなどであった。基本的に市販のファイルボックスや段ボールは酸性紙で作られているため、資料の劣化を促進する。また、写真や書類を固定する糊、セロファンテープ、ステープラーの針なども、同じく資料劣化を進めてしまう。資料の原秩序を尊重しながらも、これ以上の資料劣化を遅らせるため、できるだけそういったものを取り除き、また、ファイルボックスや段ボールはすべて中性紙の保存資材に移し替えた。

19

中性紙製のファイルボックス

中性紙製に移し替えた様子

ii. 紙資料のデジタル化
資料は保管すべきものであると同時に、検索・閲覧ができるだけ容易であることが求められる。
また、『オペラ情報センター』に入力する際には、資料それぞれとの紐づけが必要となる。しかし、資料すべてに物理的に ID を付与し、一件ずつ参照し入力していく作業は、時間を取り、また、資料に対しても負荷がかかる。
よって、入力作業前に、すべての紙資料（プログラム、チラシ、書類、写真等）をデジタルスキ
ャンした（スキャン総数：約 436,000 ショット）。
デジタルデータには、最小単位（チラシの裏表、プログラムのページ単位）まで ID が振られ、入力時は実物ではなく画像データを参照して入力した。この方法を取ることにより、資料が手元になくとも入力することが可能となった。

iii. 音声・映像資料のデジタル化
音声・映像資料の中でもオープンリールテープは、劣化の進行度合いが高い。すでに酢酸臭を放っているものについては、保存資材の交換により劣化を多少食い止めることはできても、20

音源として聴取可能かどうかは担保できない。
オープンリールテープのデジタル化は、ただのダビングではなく音源の再現が求められるた
め、黴などの除去、たわみの調整などをしながら、エンジニアが耳で聴きながら行う専門作業である。従って、高額となるため、保有音源のすべてをデジタル化することはできなかった。劣化の度合いや収録内容を確認し、優先する約 30 本のテープを選定し、デジタル化した。
また、デジタル化の精度についても、数年前であれば CD の音質が最高であると考えられていたが、今はそれよりも高音質のハイレゾルーション音源が採用されることが多くなった。次世
代に、より高音質のデジタル規格が登場することも考えられるため、現時点で最高音質である、
ハイレゾルーションでのデジタル化を行った。

②デジタル化と著作権デジタル化は著作物の複製にあたり、本来は全著作者に許諾を得る必要がある。著作権法第三十条の三*では、この検討の過程においての利用が許容されており、今回は法律家と相談の上、資料劣化の度合いに鑑み、その限度内で先行してデジタル処理を行った。もちろん、著作者の許諾なしにデジタルデータを外部公開することはできない。今後、著作者の判明しているものについては許諾を得て、公開可能になるものがあれば、公開していきたいと考えている。

*「著作権者の許諾を得て、又は第六十七条第一項、第六十八条第一項若しくは第六十九条の規定による裁定を受けて著作物を利用しようとする者は、これらの利用についての検討の過程（当該許諾を得、又は当該裁定を受ける過程を含む。）における利用に供することを目的とする場合には、その必要と認められる限度において、当該著作物を利用することができる。ただし、当該著作物の種類及び用途並びに当該利用の態様に照らし著作権者の利益を不当に害することとなる場合は、この限りでな
い。」

③協力業者
資料のデジタル化にあたり、下記の業者の協力を得た。
・株式会社廣済堂（紙資料）
・株式会社堀内カラー（紙資料、写真）
・ナクソス・ジャパン株式会社（音声資料）

21

第3章

ウェブデータベース『オペラ情報センター』

23データベース構築の経緯は、岩崎氏によって詳しくまとめられているので資料篇を参照のこと。ここでは本データベースの主な特徴を列挙する。

1. データベース概要（1）名称
昭和音楽大学オペラ研究所『オペラ情報センター』（2）URLhttp://opera.tosei-showa-music.ac.jp/search/（3）現在の公開データ数（2017 年 5 月 31 日現在）
公演登録数 7,359 件 ※1 公演（1 プロダクション）単位
内、キャストなど詳細情報入力数：1,580 件
作品登録数 1,550 件
資料登録数 1,686 件

2. 3 つのデータベースの連携
当研究所が保有する公演プログラム・チラシなどの「資料情報」、情報収集を続けてきた「公演情報」及び「オペラ作品情報」が有機的に連携されており、「資料情報」から「作品情報」を検索したり、「オペラ作品情報」から公演記録を表示したり、「公演情報」から「資料情報」を参照できる。

3. 詳細な検索項目
オペラは総合芸術と呼ばれるように、歌手、オーケストラ、合唱、バレエなど、ステージ（及びオーケストラピット）上に多くの出演者が立つのみならず、指揮者、演出家、合唱指揮者、照明、衣装、字幕など、スタッフの数も膨大である。『オペラ情報センター』はこれから開催されるオペ
ラ公演の情報ではなく、過去の公演の記録であるため、宣伝の掲載や鑑賞公演の検討には役立たない。そのかわり、既に行われており変更のない情報をできるだけ詳しく掲載し、オペラ愛好家のみならず、オペラ制作者、劇場関係者、また研究者など、オペラに関わる多くの方に利用されるウェブデータベースであることを目指した。
公演団体や作品名、公演日などの基本情報より深い情報、たとえば公演記録であれば、キ24ャスト、スタッフの人名、資料情報であれば目次や作品解説の著者なども検索できるようにした。
詳細については資料篇参照のこと。

4. 二言語対応
日本のオペラ情報は、インターネット上であっても日本語のみで掲載されていることが多いため、日本での公演情報は海外からは参照されにくい。日本でも多くの素晴らしい公演が行われてきたことをアピールするため、『オペラ情報センター』は日本語と英語の二言語に対応するものとした。オペラ作品は原作タイトルのほかに、英文タイトルでも検索が可能となっている。

日本語版のトップページ

英語版のトップページ

5. マスターの作成
多くの公演記録データベースは、情報をテキストで入力し、検索はそのテキストに対し文字列で全文検索を行うものが多い。この場合、作品名の呼び方の違いや、人物や団体の改名、同姓同名などには対応できず、正確な情報を得るためには検索者のテクニックが必要となる。
『オペラ情報センター』では、特に検索のキーとなる項目を、「マスター化」した。マスター化とは、ひとつの項目（役名、人名など）に対して、重複のない辞典を作ることである。入力時にその都度人物名や作品名を入力するのではなく、そのマスターから選択することで、そのマスターと各情報が確実に結びつく。そのため、マスター化された項目であれば、それをクリックする25

ことにより、紐づけられた情報が一覧で見ることができる。また、同姓同名や、作品名の呼び方、
表記の揺らぎなども名寄せが可能となり、検索性も高まる。
どの項目がマスター化されているかについては、資料篇参照のこと。

6. メタデータの設定『オペラ情報センター』の項目名は、利用者用に見えている項目名の他に、コンピューターが解釈できる「メタデータ」が付与されている。今後、国内外の他のデータベースなどから参照される場合に有用となる。また、システムの基盤としてオープンソースの OPAC を利用しているた
め、図書館データベースなどからも参照が可能である。

※『オペラ情報センター』の実際の入力項目については、資料篇参照のこと。

26

公演情報の詳細ページ（部分）

27

第4章

公開講座、会議等の記録

29

本プロジェクトで実施した「研究会、公開講座、特別講演会」、「研究員会議」、「外部評価委
員会」は以下の通りである（所属・役職等は当時）。

1. 研究会、公開講座、特別講演会（1）研究会「韓国のオペラについて」
日時：2013 年 2 月 5 日（火）会場：昭和音楽大学 北校舎会議室
講師：李建鏞（イ・ゴニョン／作曲家、ソウル市オペラ団団長、韓国国立芸術学校 教授・
前校長）
通訳：戸田志香
概要：韓国におけるオペラ上演、創作の状況、および同国の文化政策について、韓国を代表する作曲家であり、ソウル市オペラ団団長の李建鏞氏と意見交換を行った。

（2）公開講座「韓国におけるオペラをめぐる状況と芸術文化振興のあり方」
日時：2013 年 6 月 8 日（土）会場：昭和音楽大学南校舎 5 階 C511 階段教室
ゲスト：李建鏞（作曲家、ソウル市オペラ団団長、元 国立韓国芸術総合学校総長）
朴宗澤（パク・ジョンテク／2015 光州夏季ユニバーシアード大会組織委員会 競技本部長、元 韓国大統領秘書室 観光振興秘書官室 局長補、元 国立韓国芸術総合学校 教務課長、元 韓国文化体育観光部文化政策局 国際文化協力課 課
長代理、元 韓国文化体育観光部文化産業局 文化産業政策課 課長代理）
通訳：戸田志香（昭和音楽大学歌曲研究所 アドヴァイザー）総合司会：石田麻子（昭和音楽大学 教授）
主催：昭和音楽大学オペラ研究所
協力：昭和音楽大学演奏センター
後援：「音楽のまち・かわさき」推進協議会、「しんゆり・芸術のまちづくり」フォーラム
概要：作曲家であり、ソウル市オペラ団団長で元韓国国立芸術総合学校総長の李建鏞
氏と、韓国文化体育観光部や韓国国立芸術総合学校にて芸術文化振興を担った経験をもつ朴宗澤氏を迎えて、韓国のオペラと芸術文化の振興の現状に関する公開講座を開催した。講座では、李氏からは自作のオペラ《春 春》、《王子とクリスマス》の紹介を交えて、韓国におけるオペラの創作や公演の現状について、朴氏から30

は韓国における芸術文化振興のあり方、国立芸術総合学校での人材育成についてお話しいただいた。
来場者数：約 100 名（3）特別講演会「新しい韓国オペラの胎動“世宗カメラータ”の試み」
日時：2015 年 6 月 7 日（日）会場：昭和音楽大学北校舎 ラ・サーラ・スカラ
ゲスト：李建鏞（イ・ゴニョン／作曲家、ソウル市オペラ団団長）
通訳：戸田志香（昭和音楽大学歌曲研究所 アドヴァイザー）総合司会：石田 麻子（昭和音楽大学 教授）
主催：昭和音楽大学オペラ研究所
協力：昭和音楽大学演奏センター
後援：「音楽のまち・かわさき」推進協議会、「しんゆり・芸術のまちづくり」フォーラム
概要：韓国のソウル市オペラ団は 2012 年に"世宗（セジョン）カメラータ"プロジェクトをスタートさせた。このプロジェクトでは、作曲家と台本作家とがペアを組み、2 年をかけてオペラを創作し、上演に至るという先駆的プロセスがとられている。プロジェクトを主催するソウル市オペラ団の団長であり、企画の発案者でもある李建鏞氏の来日にあわせ、このプロジェクトについて実際の映像を交えながらお話しいただいた。
来場者数：約 70 名

2. 研究員会議
研究進捗状況の確認、公開講座等の内容の決定などを行うために研究員会議を開催し、プロジェクト全体の決定機関とした。研究員は多様な組織に属していることから、情報・意見の交換に関しては、電子メール等を積極的に利用した。
第 1 回：2012 年 7 月 6 日（金）第 2 回：2013 年 3 月 12 日（火）第 3 回：2013 年 10 月 29 日（火）第 4 回：2014 年 9 月 19 日（金）第 5 回：2017 年 2 月 17 日（金）31

3. 外部評価委員会
第 1 回：2014 年 9 月 2 日（火）第 2 回：2017 年 2 月 10 日（金）※詳細は本章 5. 参照

4. 研究成果の公開状況
本プロジェクトの最大の研究成果は、ウェブデータベース『オペラ情報センター』の構築および、その公開であるが、構築の過程で得られた知見に基づく研究やデータベースを活用した関連研究を、論文あるいは学会発表という形で公開した。

（1）論文①「「オペラ情報ウェブデータベース」の概要と、その構築の意義について」
執筆者：根木昭・石田麻子・吉原潤
掲載誌：『音楽芸術マネジメント』第 7 号（2015 年 11 月）
概要：近年の文化庁をはじめとする国におけるアーカイヴに関する取組や、芸術系を中心に先行するアーカイヴの具体的な紹介を行いながら、昭和音楽大学オペラ情報センターのウェブデータベースの概要およびその意義をまとめた。

②「VuFind を利用した異種情報統合検索システムの構築―昭和音楽大学オペラ研究所デジタル・アーカイヴの事例―」
執筆者：岩崎陽一・吉原潤・根木昭
概要：当研究所では所蔵資料のデジタル・アーカイヴを作成するにあたり、資料への到達可能性を重視した。そのために資料と公演データベース、作品データベースを関連づけたデータを作成し、それら性質の異なる情報を包括的に検索できるシステム
として、多様な情報の包括的管理に長けたオープンソースのディスカバリー・システ
ムである VuFind を利用している。本事例を紹介しつつ、この試みを通して見出された課題を報告した。
※情報処理学会 第 110 回人文科学とコンピューター研究会発表会（2016 年 5 月）にて配付③「クラウス・プリングスハイムの日本での音楽活動について―昭和音楽大学オペラ研究所「オペラ情報センター」を利用して」
掲載誌：昭和音楽大学『研究紀要』第 36 号（2017 年 3 月）
32

執筆者：酒井健太郎
概要：昭和音楽大学オペラ研究所「オペラ情報センター」の、日本近現代の音楽史研究における活用の一事例として、日本で 40 年近くにわたって音楽にかかわる活動をしたクラウス・プリングスハイム（1883-1972）を対象とした研究を行った。

（2）学会発表①「オペラ情報ウェブデータベースの構築の意義とその概要について」
年月日：2014 年 12 月 7 日（日）学会等名称：日本音楽芸術マネジメント学会 第 7 回冬の研究大会
報告者：根木昭・石田麻子・吉原潤
概要：上記 2014 年の『音楽芸術マネジメント』第 7 号掲載の論文の元になったもので、実際にデモンストレーションを交えて発表した。

②「VuFind を利用した異種情報統合検索システムの構築―昭和音楽大学オペラ研究所デ
ジタル・アーカイヴの事例―」
年月日：2016 年 5 月 14 日（土）学会等名称：情報処理学会 第 110 回人文科学とコンピューター研究会発表会
報告者：岩崎陽一・吉原潤・根木昭
概要：当研究所では、所蔵資料のデジタル・アーカイヴを作成するにあたり、資料への到達可能性を重視した。そのために資料と公演データベース、作品データベースを関連づけたデータを作成し、それら性質の異なる情報を包括的に検索できるシステ
ムとして、多様な情報の包括的管理に長けたオープンソースのディスカバリー・シス
テムである VuFind を利用している。本事例を紹介しつつ、この試みを通して見出された課題を報告した。

③「日本近現代音楽史研究におけるデジタル・アーカイヴの活用事例と課題―昭和音楽大学
オペラ研究所「オペラ情報センター」を中心に」
年月日：2016 年 12 月 18 日（日）学会等名称：日本音楽芸術マネジメント学会 第 9 回冬の研究大会
報告者：酒井健太郎・吉原潤
概要：人文科学系分野の、特に文献・資料を参照して行う研究において、デジタル・アー

33

カイヴの整備により、これまで参照することが難しかった文献・資料へのアクセスが容易となり、研究の進展に大きく貢献することが期待されている。日本近現代の音楽史の研究を進めるにあたって、「オペラ情報センター」を中心とした各種のデジタ
ル・アーカイヴを活用した事例を報告し、人文科学系の研究にとって、デジタル情報化技術が有益であることを論じ、またそれにともなって生じる課題を発表した。

5. 外部評価
有識者からなる外部評価委員会を設置し、中間年度（平成 26 年度）と最終年度（平成 28 年度）に各 1 回、合計 2 回の外部評価委員会を開催し、第三者による評価を受けた。

外部評価委員（所属・役職等は 2017 年 3 月末現在／敬称略）
大西珠枝

玉川大学教育博物 館長、芸術学部芸術教育学科 教授

永崎研宣（一財）人文情報学研究所 主席研究員・所長

韮澤弘志

元（公財）新国立劇場運営財団 常務理事

外部評価委員会においては、以下のような評価を得た（抜粋）。

（1）中間年度（平成 26 年度）
・

様々な資料を網羅的にデータベース化しオペラ資料のアーカイヴをつくろうとする事業は大変時宜にかなった試みであり、多くの制作者、研究者、鑑賞者あるいは行政の担当者から求められていたものである。このデータベースができることにより日本のオペラ公演がさらに発展することが期待される。

・

このプロジェクトは、オペラ研究者だけでなく、オペラ制作の現場にいる者も加わり、さらに情報資料の専門家の意見も十分に吸収し、よく練られたコンセプトになっていると思う。また、5 年計画とのことであるが、順調に推移しており、計画通り進むと考えられる。

・

データベースは完成後のフォローアップが大切である。この事業は文化政策的にも意義のある事業であり、人的財政的手当を講じて常にデータをアップツーデートなものにする方策を研究してほしい。

・

ウェブデータベースはインターフェイスが先端的な使いやすさを備えており、「提供者側が想定できない利用者の発想」を支援するという意味での検索支援としてうまく機能しそうで
ある。

34

・

英語による情報提供は、非英語圏からのグローバル化への手本となり得る。

・

より多くの関係機関、データベースとの連携が望まれる。

（2）最終年度（平成 28 年度）
・本プロジェクトは、オペラの分野で初めてのきっちりした検索機能を加えた体系的なアーカイヴ事業であり、事業の構築の過程において様々な改善が加えられ、研究者はもとよりオペラ公演の関係者、オペラの観客など関連する様々なタイプの利用者にとって有意義か
つ使いやすいデータベースになっていると考えられる。

・

今後オペラ公演の企画・制作をより合理的なものにするためには、過去にどのような公演がどのような形態で行われているか、出演者やスタッフはどのような者か、などについての詳しい情報を踏まえて行うことが必要である。オペラの制作・営業など実務に関わる者にとって、このデータベースは大変参考になるものであり、我が国のオペラ公演の充実発展に貢献するものと思われる。

・

データベースは、常にこれを更新し強化していくことが不可欠である。本事業が我が国のオペラ界全体に与える影響や我が国の文化政策の上からも大変重要であることにかんがみ、また、事業の安定的発展を確保するためにも、文化行政当局の経費負担ができないか研究する必要がある。

・

データベースを充実強化し使い勝手を良くするとともに関係者や一般の理解を促進する
ためには、著作権の問題が重要である。今後ともいろいろな考え方を持つ専門家に相談しながら研究を進めるとともに、この分野は頻繁に法令改正も行われるのでその動きにも注意し、この問題のネックが少しでも解決されるよう努力してほしい。

・

今後、データベースの作成体制、資料の保存環境整備について、人員、予算上の制約は大きいと思われるが、アーカイヴは継続することにより、その資産としての価値が高まるので、引き続き取り組みを継続し、できればさらなる充実を期待したい。

・

中間報告時以降、使い勝手が格段に向上した。特に、英文による検索が可能になったことは、日本のオペラ界の歴史、現状に関する素材を海外へ情報発信することに役立つであろう。

・

チラシ、プログラム、写真等の実物資料については、中性紙保存箱に収納し、博物館資料としての適切な保存環境の整備に努めている。

・「オペラ情報センター」については、オペラ関係者への周知を図ることはもとより、広く一般の人の利用してもらえるような工夫が必要である。これは利用促進だけでなく、情報の収集
35

にも役立つと考えられる。
・

データベース構築にあたっての入力支援機能が充実している。

・

総じて、当データベースは、メディア芸術に関わるデータベースの構築にあたっては、技
術的にも体制的にもひとつの模範となり得るものであり、その観点からも、今後のより広範な展開を期待したい。

6. 協力者一覧（1）ヒアリング先一覧（所属・役職等は当時／敬称略）
 独立行政法人日本芸術文化振興会（2016 年 2 月アンケートへの回答のみ）
対象：文化デジタルライブラリー
参考 URL：http://www2.ntj.jac.go.jp/dglib/
 東京都交響楽団（2016 年 3 月 9 日）
対象：「東京都交響楽団創立 50 周年コンサートアーカイブ」
参考 URL：https://www.tmso.or.jp/j/archive/
 東京藝術大学アーカイブセンター（2016 年 6 月 30 日）
対象：東京藝術大学総合芸術アーカイブセンタープロジェクト（2011 年-2015 年）
参考 URL：http://archive.geidai.ac.jp/
 日本音楽学会（久保田慶一・日本音楽学会『日本の音楽資料』調査委員長）（2016 年 8 月
22 日）
対象：平成 21 年度「音楽情報・資料の収集及び活用に関する調査研究」、平成 23～26
年度「文化関係資料のアーカイヴの構築に関する調査研究」、国立国会図書館「近代日本刊行楽譜総合目録 洋楽編」データベース
参考 URL： http://www.musicology-japan.org/ndl_score/ndl_score_main.html
http://rnavi.ndl.go.jp/score/（2）資料寄贈者一覧（寄贈順、敬称略）
斉藤昇（ご遺族より）、桂直久、野村三郎、大賀寛、杉理一、木下智雄、関根礼子、
大島正博、公益財団法人東京二期会、吉田昇（ご遺族より）、武石英夫（ご遺族より）

36

第5章

『オペラ情報センター』の
展開と課題

37

1. 他の機関・データベースとの連携、広報、利用促進『オペラ情報センター』は OPAC のシステムを基盤に作られているため、各図書館等のデー
タベースとの連携が可能である。また、策定したメタデータにより、国内外の多くのデータベースと連携が比較的容易である。外部との連携を目指す。
また『オペラ情報センター』をより広く活用してもらうため、オペラに関連する団体や劇場等と連携し、それぞれのウェブページへのリンクを依頼するとともに、当該団体・劇場等の過去の公演の紹介などでの活用のしやすさを広報する。

2. 資料公開の可能性――著作権をめぐる制度改正への期待
本プロジェクトの当初に検討していた、紙資料をデジタル化し、そのデジタルデータを閲覧者に供することについては、専門家の意見を求めたが、残念ながら著作権法的に難しいという結論となった。近年、日本においてデジタル・アーカイヴ事業は各所で展開されつつあるが、現行の著作権法となじまない部分が出てきていることは、多く指摘されているところであり、今後の著作権をめぐる法律および制度の改正をにらみつつ、所蔵資料の公開を積極的に進めたい。

3. データの追加入力、システムの維持管理
ウェブデータベースが存在価値を維持するには、継続的に情報が追加、更新されることが必要不可欠である。プロジェクトでは、システムの改修を重ね、入力支援機能を充実させ、入力作業の省力化に努めてきた。プロジェクト終了後は、予算の関係でアーカイヴむけの人員雇用および入力委託等が難しくなることが予想されるが、データの入力、公開は継続する予定である。
ウェブデータベースの運営には、サーバー維持費とシステムのメンテナンスのコストがかかる。
本データベースの重要性に鑑み、当研究所の予算で事業を継続する。

4. 行政への期待
アーカイヴを巡っては、国内でその重要性を訴えるシンポジウムなども多数行われ、また、今回のプロジェクトのように行政から補助が出るなど、文化資源の保存・記録について、その重要性が浸透してきているものと思われる。
しかし、重要性が認識されていても、民間でその価値に投資し、運営の費用を生み出し続ける仕組み作りは未だ大変に難しい。舞台芸術系のアーカイヴを先行で構築している団体への38

ヒアリングの結果でも、アーカイヴ制作時は何らかの予算がつくものの、プロジェクト終了後の継続には最低限の維持予算で運営しており、他の目的がない限りデータの新たな追加を行うのは難しい場合が多かった。アーカイヴが最低限の運営維持を脱し、継続的なデータ更新が行われるに至るには、アーカイヴを制作した団体による継続努力の上に、今後とも、行政からの支援が不可欠となる。
文化資源のアーカイヴは日本の財産であると共に、世界への重要な文化発信材料である。
多くのアーカイヴが今後とも制作され、維持され、データが蓄積されていくよう、官民力を合わせて取り組んでいきたい。

39

資料篇Ⅰ

オペラ情報センターのウェブサービスについて『オペラ情報センター』のディレクションを委託した岩崎陽一氏に、
ウェブデータベースの構築過程および設計・仕組みについて解説していただいた。

41

オペラ情報センターのウェブサービスについて
岩崎陽一

本文書では、昭和音楽大学オペラ情報センターのウェブサービスの設計思想と技術的な設計概要とを記述する。今後、学術データベースやオンライン・アーカイブといった、オペラ情報センターと同種のサービスの開発を試みる研究者の参考となるべく、オペラ情報センターの開発において工夫したこと、苦労したことなどを詳細に述べる。本文書の読者としては、芸術や人文学の研究者を想定しており、ソフトウェア開発に関わる技術的な内容はいくらか簡略化してある。技術的により詳しい情報は、岩崎陽一・吉原潤・根木昭「VuFind を利用した異種情報統合検索システムの構築――昭和音楽大学オペラ研究所デジタル・アーカイブの事例――」（『情報処理学会研究報告 人文科学とコンピュータ研究会報告』2016-CH-110(4): 1-8,
2016）を参照していただきたい。

1. システム開発の組織と流れ
1.1. 開発ディレクターの仕事
オペラ研が所蔵するオペラ公演のチラシやプログラム、音声・映像など、あらゆる資料を電子化し、オンラインで検索・閲覧するサービスをつくりたい――これが、オペラ研の方々から私が最初に伺った要望である。私は、開発ディレクターとして、オペラ研のこの目標を実現するために立ち回った。本稿を始めるにあたって、まず、この「開発ディレクター」という役回りについて説明したい。
シ ス テ ム 開 発 と は 、 簡 単 に い う と 、 発 注 者 の 「 要 求 （ requirements ） 」 を 「 仕 様（specifications）」として定義し、その仕様をプログラム等により実装する作業である。要求は漠然としていてもよいが、仕様は具体的でなければならない。たとえば、「チラシの画像を鮮明に見られるようにしたい」という要求を電子システムで実現するには、解像度がいくつ、色深度がいくつで、ファイル・フォーマットは何、ということを具体的に決めなければならない。さらに、画像を見るためのボタンはどこにあって、それを押したとき、画像は同じタブ内で開くのか、それとも新しいタブが開いてそこで見られるのか、といったことも仕様に含まれなければならない。
仕様は、いわゆる「仕様書」として文書化される。プログラム開発者が必要とする指示は、要求ではなく、それを具体的に定義した仕様である。

42

仕様を定義する者は、技術および周辺事情に明るくなければならない。先の例でいうと、解像度がいくつで、色深度がいくつならば鮮明な画像とみなされるのか、それを知っていなければならない。また、たとえば「学術データベースの標準ルールに従いたい」、あるいは「著作権の問題がない範囲で画像を公開したい」といった専門的な要求についても、その可否を判断し、可能とみなされれば、その実現方法を仕様に含めて文書化しなければならない。さらには、発注者が明確に意識していない要求を明らかにし、仕様に含めることも大切な作業である。ス
マートフォンに対応する必要はないのか。アクセス数を増やすために検索エンジン対策をする必要はないのか。技術の専門化以外にはなかなか考えが及ばない、こういった点について発注者に提案し、要求を引き出す。仕様の策定は、このように、発注者と仕様定義者の双方向コ
ミュニケーションを通して行われる。

開発作業を外注するプロジェクトの多くにおいて、仕様を定義する者は、通常、開発会社の側に置かれる。開発会社に「御社に開発を依頼したい」と連絡をすれば、営業担当者が技術者と一緒に来て、発注者の要求をヒアリングし、簡単な仕様をまとめて提案してくれるだろう。
彼らはさまざまな電子システムについて広い知見を有し、発注者の要求についても熟知している。彼らの経験が豊かな領域での案件であれば、彼らに仕様決定の大部分を任せることができる。しかし、学術システムを始めとする、専門性が高く、ときに外国語の資料を用いる必要があるシステムの場合は、そうはいかない。そして、専門的な要求を理解できる担当者がいないと、発注者の要求はうまく理解されず、とんちんかんなシステムができあがる。誰しも、余りに使い勝手の悪い学術システムのひとつやふたつ、目にしたことがあるだろう。その類のシステムに43

おける質の悪さの原因には、発注者側にやる気がないといったこともあるかもしれないが、発注者の要求をうまく仕様化できていない、或いは潜在的要求をうまく引き出せていないと思わせるものも少なくない。そうなると、関係者の皆がよかれと思って奮闘しても、良い結果を出せない。要求をよく理解しない開発者が適当な仕様書を書いてきて、それを見た発注者もまた、仕様書の内容をよく理解しないまま「それでいいです」と言って発注する。そうしてできあがるのが、世に蔓延する使えない学術システムの数々である。
もちろん、発注者の明示的・非明示的な要求をすべて叶える仕様書を書いてくれる担当者を擁する開発会社を見つけられれば、それでよい。しかし、もうひとつ問題があり、技術に詳しい人間が発注者側のチームに居ない場合、提示された仕様書が良いものかどうか見きわめること自体が難しい。それはちょうど、建築の専門知識をもたない者が、家屋の材質や工法を詳細に記した建築計画書を見せられても、自分が満足する家が建つのかどうか、それだけでは判断できないのに似ている。結局のところ、発注者の側に、少なくとも仕様書を読むことのできる人間がいなければ、開発会社の選定すら難しいということになる。そのような人材をチームで雇用できるとよいのだが、実際のところ、それは難しい場合が多いだろう。
以上のような問題に対処するため、オペラ情報センターの開発に関して、筆者はオペラ研の側に立ち、技術的な面から開発プロジェクトの運営を補助する、開発ディレクターとして参加させていただくことになった。筆者はこれまで、音楽データベースを中心に、いくつもの専門的なシステムの開発に携わってきた技術者である。それと同時に、人文学の研究者でもある。音楽の専門家、および研究者の要求について深い理解を有し、それを仕様書にまとめ、必要に応じてプログラムを書くところまでできるので、その技能を評価していただいたのだろう。主な役割
は、オペラ研の要求を、技術的な仕様に落とし込むことにあり、かなり具体的な仕様書を書くところまで行う。この役割を先述の建築物の例でいうならば、発注者であるオペラ研を施主とすると、ディレクターの仕事は建築士兼現場監督のような役割にあたる。ディレクターは、仕事の内容を決め、それをプログラム開発業者やデザイナー、データベース開発者、データ入力者等に具体的に指示する。ただし、ディレクターが開発業務を請け負って、それを下請けに出すのではなく、開発業務の受発注はオペラ研と開発会社との間で直接に行われる。ディレクターの仕事は、あくまで、その契約内容の決定を手伝うだけである。

44

ディレクターの仕事は、仕様書ができたら終わりではない。実際にエンジニアやデザイナーによる開発が始まると、発注者は、さまざまな質問を受けることになる。「ボタンは丸と四角のどちらがよいですか」という簡単なものもあれば、「認証は SSL でやった方がよいですか」「データ更新時はトランザクションを切りますか」といった専門的な質問もある。こういった質問を、その都度、かみ砕いて発注者に説明し、判断を促すのもディレクターの仕事である。そして最後に、納品されたシステムが仕様書のとおりに動作することを確認する、検収の作業を手伝うことも、技術に詳しい者でなければできない仕事である。こういった多様な仕事があるので、ディレクタ
ーはプロジェクトの開始から完了まで、発注者との関係を維持することになる。できることなら、プロジェクトの開始前、公的資金の応募書類を作成する段階から仲間に引き入れることが望ましい。そのような能力をもつ人材の重要性は、総務省の提言書「知のデジタルアーカイブ―社
会の知識インフラの拡充に向けて―」でも強く説かれている。

1.2. システム開発の流れ
ディレクターないし開発会社の担当者は、発注者の要求をヒアリングして分析し、まず、「要求定義書」という文書を作成する。この文書で、システムで満たすべき要求が網羅されていることを発注者に確認してもらったら、次に、この要求を実現するための技術的な仕組みについて、
画面遷移図等も含めて詳細に記述した「外部設計書」を作成する。これが、いわゆる「仕様書」

45

に相当するものであることが多い。外部設計書もまた、発注者の承認を得て決定される。外部
設計書が確定したら、技術者はそれをプログラムでどのように実現するか、さらに具体的な設計を行い、「内部設計書」を作成する。内部設計書は技術者向きの文書であり、発注者にこれの承認を求めることは稀だろう。内部設計書ができあがったら、それに従ってプログラマーがプ
ログラムを書いて実装し、開発会社のテスターがそれをテストし、納品、検収、そしてリリースとなる。

さて、開発の途中で、「やっぱりチラシの画像は別タブではなく別ウィンドウで表示したい」という要望が出てきたとしよう。それが外部設計書を作成した後であれば、この要望を踏まえて設計書を書き直さなければならない。さらに、もし工程がもっと先に進んでいたら、プログラムを書き直さなければならないかもしれない。これが、悪名の高い「仕様変更」である。仕様変更には当然、費用が掛かる。予算が足りなければ、要望は受け容れられず、問題点を含んだままで完成品としなければならない。
上記の伝統的なプログラム開発の流れは、後戻りができず、一方通行で進んでいくので、「ウ46ォーターフォール型」と呼ばれている。これは融通が利かないばかりでなく、最後の最後まで成果物が見えないという点や、「できるかどうか、やってみなければ分からない」という案件を扱いづらいという点など、問題点が多い。それを克服する新たな手法として、要求分析から設計、実装、テストに至るまでの流れを短期間で何度も繰り返す、スパイラル型と呼ばれる開発手法
が近年は普及してきている。

この手法を採ることにより、たとえば 1 周目でできあがったシステムをプロジェクト関係者全員に使用してもらい、そのフィードバックを 2 周目の要求分析に取り込むことができる。また、できるかどうか分からない機能については、1 周目でトライしてみて、ダメなら２周目の設計にときに別の機能で代替させるといったこともできる。オペラ情報センターの開発でもまた、このようなス
パイラル方式を採ることにした。プロジェクトの期間は、トータルで 5 年。この中で、スパイラルを
2 周、廻すことにした。最初の 1 年はチーム内で要求の洗い出しを行い、2 年目と 3 年目で 1周目を廻してテスト版を公開する。その反響を踏まえて仕様を改訂し、4 年目と 5 年目で 2 周目を廻す。このような計画を立て、そして実行することができた。
一般的なことではないが、オペラ情報センターの開発にあたっては、1 周目と 2 周目を異なる
開発会社に委託した。周回ごとに目標が異なるため、ひとつの開発会社が両方に適している
47

とは限らないからである。1 周目は、やってみるまで実現可能かどうか分からない要求が多かったので、実験的開発に長け、かつ学術システムに造詣の深い企業から見積を取り、委託先を決定した。この委託先には、ソースコードの一貫性などは強くは要請せず、とにかくオペラ研が考えるサービスを実現するよう、機能作りに邁進してもらった。一方、2 周目においては、外面的にはインターフェイスの改善、内部的にはリファクタリング（保守管理と安定性向上等を目的とした、ソースコードの整理）が重要な目標となるため、それに適した企業に見積を依頼した。2
周目の委託先には、5 年間のプロジェクト終了後、つまり大きな予算が使えなくなったあとも、
サービスの保守を依頼しなければならないため、安価での保守契約が可能な企業を選ぶことも大切である。周回ごとに委託先を替えることにより、リレーのバトンとなる引き継ぎ用技術文書の作成にエクストラの費用がかかってしまうが、結果として優れたシステムを作れたと考えている。

2. やりたいこと（要求分析）
2.1. 誰のため、何のためのサービスか
話の時間軸を始めに戻そう。「オペラ研が所蔵するオペラ公演のチラシやプログラム、音声・映像など、あらゆる資料を電子化し、オンラインで検索・閲覧するサービスをつくりたい」――こ
れが、オペラ研システムにおける基本的な要求であった。われわれ技術者の言葉で言い換えるならば、デジタル・アーカイブを作り、それをウェブに載せたい、ということになる。そういったオンライン・アーカイブの事例は数限りなく見られ、手法も確立している。一般的には、資料のメタデータ（名称や形態、著作権者等の属性）をデータベース化し、それを検索できるようにしたうえで、データファイルを著作権に留意しつつウェブに載せれば、オンライン・アーカイブのできあがりである。メタデータの項目や書式については、「ダブリンコア」と呼ばれる国際標準が存在しており、それを踏襲すれば他のデータベースとの相互運用も可能になる。これは楽勝のプロジェクトだ･･･、と思ったら大間違いである。オペラ研の方々と打ち合わせを重ねるうち、
事はそう単純でないことが明らかになった。
たとえば、オペラ研の所蔵資料のひとつに、1990 年に藤原歌劇団が北九州で《カヴァレリ
ア・ルスティカーナ》と《道化師》を上演した際のプログラムがある。この資料について、ダブリン
コアに従ってごく一般的なメタデータを付けるならば、以下のようになるだろう。
タイトル：藤原歌劇団北九州公演《カヴァレリア・ルスティカーナ》《道化師》プログラム
クリエーター：藤原歌劇団
パブリッシャー：藤原歌劇団

48

さて、これをデータベースに登録すれば、この資料を必要とする人は、この資料に到達できるだろうか。この公演では、《道化師》のネッダ役を渡辺葉子氏が演じているが、渡辺葉子氏の名前で検索しても、この資料は見つからない。つまり、渡辺葉子氏の講演記録を作ろうとしている
ひとには容易には到達できない。また、プログラムの冊子には、佐川吉男氏による、これらの作
品の上演史を概観した小稿が収録されている。しかし、それを発見することも困難である。データベースで検索し、この資料に辿り着けるのは、この資料がこのデータベースに存在し、どのようなメタデータで登録されているかを知っているひとだけであろう。そして、そのような利用者は、おそらくデータベース利用者の多数派ではない。
システムの設計において、決して忘れてならないのは、誰のために、なんのためにシステムを作るのかということである。オペラ研がつくろうとしているオンライン・アーカイブは、誰のために、何のためにつくるのか――それをまず問わなければならない。アーカイブというものは、およそすべて、資料の蓄積・保存を目的としている。しかし、蓄積・保存は、それ自体で目的となるものではない。なぜ資料を集め、保存しなければならないのか。それについてもさまざまな議論があり、「歴史を伝える」ことや「将来の利用に備える」ことが目的であるという見解が知られている1。では、オペラ研のデジタル・アーカイブは、いったい誰に歴史を伝え、誰の、どんな利用に備えるべきなのか。それにより、サービスの設計が変わってくる。
オペラ研のオンライン・アーカイブは、オペラの上演、教育、研究に携わるすべての専門家を利用者として想定している。それには大学の学生や教員、上演団体の事務局や実演家、オペラ愛好家などが含まれる。彼らの検索要求を分析すれば、上記のような簡素なメタデータでは不充分であることは容易に理解できる。

2.2. 既知のデータと未知のデータ
筆者は、データ検索を、既知のデータの検索と未知のデータの検索とに分けて考えている。
たとえば、山の中に埋蔵金が存在することが分かっていて探索する行動と、何が出てくるか分
からず、何も出てこないかもしれないが、とりあえず山を掘ってみる行動とは、本質的に異なる。
それと同様に、何か具体的で明確な資料を求めて検索する行動と、どんな資料があるか分からないけれど検索してみる行動とは、互いに異なる。求める資料のタイトルや著者が分かって

1

詳しくは前掲の岩崎陽一・吉原潤・根木昭「VuFind を利用した異種情報統合検索システムの構築――昭和音楽大学オペラ研究所デジタル・アーカイブの事例――」を参照。

49

いる利用者に対しては、それらのメタデータを正確にデータベースに入れておけば、資料に到達することができる。しかし、たとえば「○○さんの出演した公演の資料が欲しい」「○○年代のプッ
チーニのオペラの公演資料が欲しい」といった要望もあるだろう。むしろ、研究者や音楽関係者の需要を想定すると、このような未知の資料の検索の方が一般的であると推定される。オペ
ラ情報センターは、これらの要求に応えられるサービスを提供しなければならない。

2.3. 3 種のデータベースの統合
では、どのようにしたら、上に例示したような要望に応え、所蔵資料のファイルを、それを必要とする利用者に届けられるサービスを作成できるのか。それを考えるために、資料の特性と、その用途を分析しなければならない。
オペラ研の保有する資料は、そのほとんどが、過去に行われたオペラの公演と結びついている。資料の検索は、実質的に、公演の検索に等しい。したがって、資料への効率的な到達ルートを用意するには、その資料と関連する公演記録をデータベース化することが望ましい。幸いにも、オペラ研は『日本のオペラ年鑑』の編集を通して、公演記録のデータベース化については豊富なノウハウをもっており、すでに Microsoft Access によるデータベースを運用している。あとは、そのデータベースをパワーアップして、インターネットで公開できるようにすればよい。
さらに、公演記録データベースは、それから独立した、オペラ作品のデータベースと結びついていることが望ましい。というのも、オペラの公演は、すべて、何らかの作品の上演である。そして作品は、作曲者や台本作者といった多数の属性をもつ。作品データベースを設置しなけ
れば、作品の属性を手がかりに公演を特定することはできない。つまり、「○○年代のプッチーニのオペラの公演資料が欲しい」という検索には結果を返せない。したがって、公演記録データ
ベースと結びついた作品データベースを構築しなければならない。
以上のように、オペラ研の所蔵資料は、公演記録データベースと作品データベースを伴ってはじめて、現実的に利用可能なデジタル・アーカイブとして提供できるようになる。それゆえ、オペラ研では、所蔵資料データベース、公演記録データベース、作品データベースという三つのデータベースを組み合わせて、「オペラ情報センター」という単一のサービスを提供するこ
とにした。

50

これら 3 種の情報資産が、オペラ研が長年蓄積してきた 3 種の情報――資料と、公演記録と、作品調査の成果――と一致するのは、偶然ではない。オペラの研究や公演を促進するには、デジタルであれ紙資料であれ、これら 3 種の情報が必要であることを、上記の分析は示しているといえるだろう。

3. どう実現するか（外部設計）
3.1. ディスカバリー・サービスを利用する
以上のようなまったく質の異なる三つのデータベースをウェブで公開しようとするならば、
MySQL 等のデータベース管理システム（RDBMS）によってそれぞれのデータベースを作成し、それらを検索・表示するアプリケーションを何らかのフレームワーク 2を用いて作成する、という方法がはじめに思い浮かぶ。しかし、フレームワークが自動で作ってくれる検索インターフ
ェイスはユーザビリティが低く、かといって全文検索やファセット機能 3を自力で追加していくな
らば工数がみるみる増加していく。フレームワークを元に自前で検索サービスを構築することは、ほぼ不可能と考えられた。
簡単にサービスを完成させる方法として、CMS4を用いるという選択肢もあるだろう。デジタ
ル・アーカイブについては DSpace や Omeka といった CMS の採用実績が多いが、いずれも所蔵資料の管理と提供に特化されており、当然ながら、公演記録やオペラ作品のデータベー

2

データベースを指定すると、それを検索するための最低限の画面やデータ入力する画面を自動で作ってくれるソフトウェアが多数リリースされている。
3 検索結果をグループ化し、絞り込むための機能。たとえばホテル予約サイトでは、画面の脇に、検索結果を地域や価格帯で絞り込むためのコーナーが設定されていることが多い。あのような絞り込み機
能が「ファセット機能」と呼ばれる。
4 コンテンツ管理システム（Content Management System）。日本ではブログを立ち上げるためのシステムとして、2000 年代に急速に普及した。Wordpress や Drupal が知られている。近年は、大学や研究室のウェブサイトを CMS で構築する例も多い。

51

スまでカバーできるものではない。それらのデータベースを別途作成し、CMS を連携して運用するのは、きわめて煩雑である。そもそも、DSpace 等はアーカイブやリポジトリのバックエンドとしては申し分のない機能を有しているが、検索機能は決して充実しているとはいえない。また、
Drupal や WordPress といった汎用的な CMS を用いる方法も知られているが、やはり、満足のいく検索インターフェイスが容易にできるような方法ではない。
何とか楽に、低予算で、リッチなインターフェイスを備えた検索サービスを作れないものか。
筆者らはここで、図書館用の OPAC に注目した。近年の OPAC は、書籍や電子ジャーナル、CD 等、さまざまな質の異なるデータを包括的に扱うことができる。オペラ情報センターの扱うデータの多様性も、OPAC で処理することができるのではないか。オペラ情報センターの扱うデータには、二つのレベルでの質的差異がある。所蔵資料、公演記録、作品という第 1 レベルの差異と、所蔵資料の下位区分として存在する紙資料（静止画ファイル）、録音資料（音声ファイル）、映像資料（動画ファイル）といった第 2 レベルの差違である。このようなデータの質的差
異を抱え込んでいることに、このシステムの難しさがある。しかしどのような差異であれ、OPACが読み込める形式、たとえば OPAC に与える目録のフォーマットとして最も普及している
MARC（Machine-Readable Cataloging, 機械可読目録）形式でデータを記述することさえできれば、OPAC が吸収してくれるはずである。OPAC は、そのようなシステムとして設計されている。そして、MARC というデータ形式は、オペラ情報センターの扱う各種データを記述す
るのに充分な柔軟性を備えた構造をもっている。

また、OPAC は、多くの場合、複数の権限種別を扱える認証機能を有している。この点もオ
ペラ情報センターにとって重要であった。OPAC では、利用者や図書館職員がそれぞれのア
カウントでログインし、返却期限を調べたり、予約をしたり、職員であれば個々の利用者の履歴を調べたりといったことができる。この機能は、オペラ情報センターにも応用できそうだ。オペラ
情報センターのデジタル・アーカイブに含まれるデータには、不特定多数には公開できないものも多い。したがって、未認証ユーザー、学内ユーザー、研究所内ユーザー等の権限区分を

52

扱える認証機能がそのまま利用できるのは魅力である。
筆者は、Koha、Next-L Enju、Blacklight、VuFind といった主要なオープンソースのOPAC、および次世代 OPAC と呼ばれる「ディスカバリー・サービス」をテスト環境にインストー
ルし、データを読ませて試用した。その結果、優れた検索インターフェイスをもち、セットアップ
が容易で、多言語に対応し、カスタマイズに関するドキュメントも充実している VuFind を利用することにした。開発計画を具体化させた 2013 年当時、バージョン 2.0 の正式版がリリースされた直後であり、バグ修正版である 2.0.1 のリリースを待って、それをカスタマイズのベースとすることにした。

3.2. VuFind について
VuFind について簡単に紹介しよう。これは、米ヴィラノヴァ大学が開発するオープンソースのディスカバリー・サービスである。「ディスカバリー・サービス」とは何かという問いについては各人が各様の意見をもっており、いかなる定義を与えても誰かしらから批判されるので、ここで余計なことは言わない。近年、多くの大学図書館で、図書館システムのリプレースが進んでいることに気付いているだろうか。旧来のシステムに取って代わり、検索結果の絞り込みができ、CiNii や Amazon の検索結果も一緒に表示されるシステムに、各大学の図書館は順次切り替えている。この、切り替わった後の新しい図書館システムは、すべてディスカバリー・サービスであるといってよい。これらのシステムは、検索対象を学内に留めず世界中のデータを対象とすることにより、資料の、そして知識のディスカバリーを支援するように作られている。国内で用いられているディスカバリー・サービスのほとんどは大手 IT 企業が開発する商用のものだが、オープンソースで無償のソフトウェアも作られており、海外では利用実績も多い。VuFind は
eXtensible Catalog と並んで普及している、代表的なオープンソースのディスカバリー・サー
ビスである。
VuFind の検索機能は Apache Solr、その他の機能は Zend Framework を用いて実装されている。レコードは MARC または MARCXML で登録する。Solr で MARC を扱う部分は、独立したオープンソースの Solr アドオンである SolrMarc を用いている。VuFind には外部の
ILS（Integrated Library System, 統合図書館システム）と相互運用するための「ドライバー」
が各種用意されており、独自にドライバーを作ることもできる。オペラ情報センターにおいては、
デジタル・アーカイブのファイル管理は別のサービスとして独立させ、それをひとつの ILS とみなし、オリジナルのドライバーを開発して相互運用を可能にした。下図は、オペラ情報センター
全体のシステム構成を示したものである。括弧内は各コンポーネントの実装に使用したソフトウ
53

ェアを示す。

4. データについて
4.1. MARC フォーマットについて
以下の説明には、技術的・歴史的には誤りまたは過度の単純化があるかもしれないが、本文書を理解するのに必要な前提を述べるための説明なので、その目的が果たされる限り、細部についての瑕疵はご容赦いただきたい。MARC は ISO 2709 で定義される構造で書誌データを既述したものであり、すべての書誌属性はフィールド名とサブフィールド名で指示される項目によって記述される。データはバイナリー形式だが、テキストエディタで読める XML で既述した MARCXML という規格も普及している。
MARC の大きな特徴のひとつに、人名や書名の別名を、書誌データとは別に「典拠データ」
として管理できるということがある。原語は authority records といい、「典拠」という訳語が適切かどうか疑問だが、いま述べたような目的に使用できる。これにより、たとえばＪ・Ｓ・バッハと J.S.
Bach と Johann Sebastian Bach が同一人物であり、《椿姫》と《ラ・トラヴィアータ》が同一作品であることを管理できる。
フィールドやサブフィールドの使い方について、世界各国の中央図書館はそれぞれ独自のルールを定義してきたが、米国が主導する MARC21 は他国でも利用され、こんにち国際標準としての地位を得ている。我が国の国会図書館は JAPAN/MARC を定義したが、これも 2012
年以降、MARC21 に準拠した。ただし、我が国で最も利用されている MARC は TRC MARC
54

という別種のものであり、MARC21 がすべてというわけではない。米国で開発されている
VuFind が読み込めるデータは MARC21 またはその XML 表現のみであるため、VuFind を利用するには、データを MARC21 で記述しなければならない。
MARC21 のデータの例を示しておこう。たとえば Field 245 は、資料のタイトルの記述に用いられる。このフィールドには 12 種のサブフィールドが定義されているが、それらをすべて使う必要はない。Field 260 は出版関連の属性を保持するものであり、9 種のサブフィールドをもつ。
これらを用いてひとつの書籍の書誌を記述すると、次のようになる。
Field
245

Subfield
$a
$b
$c

用途
Title
Remainder of title
Statement of responsibility, etc

260

$a
$b
$c

Place of publication, distribution, etc.
Name of publisher, distributor, etc.
Date of publication, distribution, etc.

データ
日本オペラ史〜１９５２ /
増井敬二 著 ; 昭和音楽大学
オペラ研究所 編.
東京 :
水曜社,
2003.

4.2. MARC21 でのデータ記述
所蔵資料の書誌データを MARC21 で記述するのは造作ない。MARC21 がそもそも書誌データの記述を想定して設計されているので、仕様にそのまま従うだけである。書誌データはす
べて邦文漢字表記、読み仮名、そして欧文表記を保持しているが、この多言語対応についても、JAPAN/MARC MARC21 の仕様に従って Field 880 を用いて行った。
他の 2 種のデータについては工夫を要したが、いずれも思いのほか容易に扱うことができた。
そのうち、作品データの取扱いは特に容易だった。タイトルや著作者は、MARC21 の Field
245 に、仕様に従って格納することができる。幕数、キャスト、出版状況、楽譜の所在といった、
MARC21 の仕様でカバーされていない属性については、Field 500 (General Note) に格納して対処した。以下に例を示そう。
Field
041

Subfield
$a

245
490
500

$a
$c
$a
$a

用途
Language code of text/soundtrack or separate title
Title
Statement of responsibility, etc
Series statement
General note

500

$a

General note

500
500

$a
$a

General note
General note

55

データ
Jpn
情あつき女
作曲|別宮貞夫|; 台本|鈴木松子|;
三人の女達の物語 第一話
キャスト| 大名 (ten), 太郎冠者 (bar),
奥方 (sop), 花子 (sop)出版| ヴォーカル・スコア：音楽之友社（ISBN： 9784276525962）
作曲年月日| 1964/../..
初演| 1964/08/..

公演データの取扱いもまた、大部分は MARC21 の仕様に従うことができた。MARC21 には、
映 画 や オ ペ ラ の DVD 資 料 を 扱う た め に 、 出演者 を 格 納す る た め のフ ィ ー ル ド （ 511:
Participant or Performer Note）、会場や日時を格納するフィールド（518: Date/Time andPlace of an Event Note）等が用意されている。これらで扱いきれない属性については、
Field 500 や Field 59X（Local Notes）で記述した。なお、以下の参考データにおいて用途をブラケット内に記しているものは、本来の仕様に従わず、独自ルールにもとづいて利用してい
る。
Field
041

Subfield
$a

245
490
500

$a
$c
$a
$a

500
505

$a
$a
$g
$r

用途
Language code of text/soundtrack or separate title
Title
Statement of responsibility, etc
Series statement
General note
General note
Formatted contents note
（公演日として使用）
Miscellaneous information（会場として使用）
Statement of responsibility（上演作品として使用）

$t

Title
（チケットの価格として使用）

508

$a

509
511

$a
$a

Creation/Production Credits
Note
未定義。主催者データとして使用
Participant or Performer Note

518

$a

$p

Date/time and place of anevent note
（地域名称として使用）
Place of event

56

データ
fre
《カルメン》
藤原歌劇団
藤原歌劇団公演
特記事項| 平成 9 年度文化庁芸術創造
特別支援事業
公演期間|1997 年 9 月 5-13 日(1) 1997 年 9 月 5 日 18:30 (2) 9 日
18:30 (3) 11 日 18:30 (4) 13 日 16:00
東京文化会館{カルメン}| 作曲: {ジョルジュ・ビゼー}^原
作: {プロスペル・メリメ}^台本: {アンリ・メイ
ヤック} , {リュドヴィク・アレヴィ}^字幕[作品表現著作者]: {松本重孝} , {秋山理恵}^4
幕^ 上演言語: フランス語（原語） 字幕付
き特別席: 18,000 円; A: 15,000 円; B:
12,000 円; C: 7,000 円; D: 6,000 円; E:
4,000 円
公演|藤原歌劇団
主催|（財）日本オペラ振興会
カルメン|アグネス・バルツァ (1/2/3), イリ
ーナ・ロミシェフスカヤ (4); ドン・ホセ|ルイス・リマ (1/2/3), 水口聡 (4); ミカエラ|
渡辺葉子 (*1/*2/*3), 出口正子 (1/2/3),
大岩千穂 (4); エスカミーリョ|折江忠道(1/2/3), 栗林義信 (4); スニガ|三浦克次; モラリス|長谷川寛 (1/2/3), 立花敏弘
(4); ダンカイロ|櫻井直樹 (1/2/3), 中村靖[バリトン] (4); レメンダード|松浦健(1/2/3), 於保郁夫 (4); フラスキータ|竹村佳子 (1/2/3), 山舘昌代 (4); メルセデス|河野めぐみ (1/2/3), 仲野玲子 (4); リーリャス・パスティア|関貴昭
関東

東京都

592
593

$a
$a

Local note
Local note

594

$a

Local note

597

$a

Local note

助成|（財）三菱信託芸術文化財団
総監督|五十嵐喜芳; 指揮|ウジェコスラ
フ・シュティ; 演出|グリシャ・アサガロフ;
美術|パンテリス・デシラス; 振付|ペトロス・ガリアス; 合唱指揮|及川貢; 照明|（以下省略）
指揮|ウジェコスラフ・シュティ; 演出|グリ
シャ・アサガロフ
合唱|藤原歌劇団合唱部; 児童合唱|多摩ファミリーシンガーズ; バレエ|新井千佳~o 昭和音楽芸術学院バレエ科; バレエ|
伊藤優弥~o 昭和音楽芸術学院バレエ科;（以下省略）

資料や作品と関連づけられた、或いは公演に出演した人名・団体名は、上述の Field 245
や 511 に格納するだけでなく、Field 600/610（Subject Added Entry）や Field 700/710（Added Entry）にも登録した。そしてそれらの人名を、典拠データとして VuFind に登録した。
同様に、作品名については Field 630/730 に登録している。こうすることにより、特定の人物の出演作品・著作作品・関連資料等を高速に検索できる。たとえば、上掲の《情けあつき女》の典拠データは次のように登録されている。
Field
600

Subfield
$a

630

$a

700

$a
$0

700

$a
$0

用途
Subject Added Entry-Personal
Name
Subject Added Entry Uniform Title
Added Entry - Personal Name
Authority record control
numberAdded Entry - Personal Name
Authority record control
number

データ
別宮 貞夫
情あつき女
別宮貞夫
2687（システム内の人物 ID）
鈴木松子
2686

資料と作品の関係、作品と公演の関係、また公演と資料の関係は、これら Field 630/730 のデータで辿ることができる。しかし本データベースでは関連づけをより明確にするため、Filed
787（Other Relationship Entry）に関連データへのリンクを登録している。たとえば、上掲の藤原歌劇団による《カルメン》の関連データを抜粋すると、以下のようになっている。
Field
787

Subfield
$i
$w
$t

用途
Relationship information
Record control number
Title

787

$i
$w
$t

Relationship information
Record control number
Title

57

データ
Related Works
WORK-00037
jpn| カルメン（ジョルジュ・ビゼー）;eng|Carmen (Georges Bizet)
Related Resources
ITEM-I30601_005
jpn|プログラム, 藤原歌劇団公演 《カルメン》;eng|Booklet, The Fujiwara Opera:
Carmen

787

$i
$w
$t

Relationship information
Record control number
Title

Related Resources
ITEM-I30201_124
jpn|ちらし, 藤原歌劇団公演 《カルメン》;eng|Event Flyer, The Fujiwara
Opera: Carmen

オペラ情報センターは日英ふたつの言語に対応している。データの多言語化についても
MARC21 の仕様に従い、Field 880（Alternate Graphic Representation）に英文表記と日本語の読み仮名とを登録して対応した。
ただし、次節に提示するような、公演データの複雑な構造は、MARC21 の仕様の範囲内で表現することができなかった。そのため、XML で表現したデータを Field 887（Non-MARC
Information Field）に格納した。VuFind は（或いは SolrMarc は）その XML を文字列として取得できるため、アプリケーションの側でパースし、画面表示に用いた。この XML は純粋に画面表示に関わるものであり、検索で用いられるデータはすべて通常の MARC21 フィールドに格納されている。表示用と検索用でデータを分けることにより、VuFind の機能を利用しつつ、分かりやすい画面表示が可能となった。
実のところ、オペラ情報センターのデータはそのまま他の OPAC に投入するつもりはないので、無理に MARC の仕様に合わせる必要もない。しかし、あえて仕様を無視する必要もあるまい。なるべく仕様に従うことで、VuFind の標準機能を最大限利用できる。また、「なるべくMARC に準拠」という方針を拡大適用して、読み仮名の表記方法、補記の方法等についても、なるべく日本および世界の MARC に関する標準的手法を踏襲することにした。新たな規則を
その都度創出していくより、準拠できる既存の規則があるならば、それに従う方がよい。その結果として、データの入力は大部分を MARC 作成のエキスパートである株式会社図書館流通センターに委託でき、質の高いデータを作ることができた。

4.3. 演者データベース
オペラ情報センターの開発の第 1 周目が終わり、レビューを募ったときに強く寄せられた要望のひとつに、「過去に《カルメン》でドン・ホセ役をやったことがある歌手を一覧で取得したい」「これまで《カルメン》を指揮したことのある指揮者を知りたい」といった検索に答えられるようにすべき、というものがあった。これは VuFind で対応するのが難しい。図書館の蔵書検索には類似する検索要求がないからである。敢えていうならば「これまで枕草子を訳したことのある翻訳家のリストがほしい」という検索が似ているが、私の知る限り、通常の OPAC にはこの検索に答えることができない。

58しかし、上記の検索はオペラ関係の研究者、事業者のいずれにとっても重要なものであり、
オペラ情報センターはそれに対応しなければならない。この機能を実装するにあたり、
Apache Solr に新たに cast というコア（データを格納する箱）を定義した。MySQL に直接アクセスすることも可能であるが、データは Solr データベースに集約した方が一貫性があり、動作も高速になる。

4.4. RDB におけるデータモデル－RDB と VuFind の関係
なお、所蔵資料書誌、公演記録、作品それぞれのデータは MySQL の RDB（データベース）で保持されている。それを VuFind にロードするに際し、独自ツールで MARCXML 形式のフ
ァイルに出力し、VuFind に附属するデータ登録ツールで登録を行っている。本節では、
MySQL のデータベース、とくに構造が複雑な公演記録データベースの設計について説明する。

－バレエ研究所の公演概念モデル
オペラの公演記録をデータ化する概念モデルを作成するにあたっては、昭和音楽大学バレエ研究所（以下「バレエ研」）のデータベースを参考にした。オペラ研の姉妹機関であるバレエ
研は、オペラ研よりもひと足早く、バレエの公演記録のデータベース化を試みている。そこで用いられている概念モデルは、海野敏・高橋あゆみ・小山久美「舞台芸術のための情報組織化手法の開発〜バレエ情報総合データベースの設計と試作〜」（『情報処理学会シンポジウム
論文集』2011(8): 205-210. 2011）で詳しく提示されている。
バレエ研のデータモデル設計の特徴は、FRBRoo（オブジェクト指向 FRBR）の考え方を利用していることにある。FRBR（Functional Requirements for Bibliographic Records, 書誌レコードの機能要件）とは、国際図書館連盟が提唱する書誌データの概念モデルであり、図59

書館資料に関わる諸々のエンティティ（実体）とそれらの関係を記述することにより書誌を表現しようとするものである。たとえば文学作品と書籍の関係は、以下の四つのエンティティに分析
される。
著作
表現体
体現体
個別資料

表現体から抽象される形而上学的構想物としての創作物。
例：清少納言の枕草子
文章として表れたもの。
例：三巻本写本の枕草子、能因本写本の枕草子、現代語訳、英訳等。
それが出版あるいは他のかたちで物質化されたもの。
例：日本古典文学大系 19 巻『枕草子』
体現体の個々のインスタンスで、図書館に所蔵される。
例：我が家の本棚にある日本古典文学大系 19 巻『枕草子』

舞台芸術作品の上演も、この 4 階層モデルによって分析することができるだろう。一方、
FRBR にもとづいて開発された FRBRoo では、上演に特化したエンティティも与えられてい
る。
実演作品
実演計画
実演

例：バウシュ振付の『春の祭典』
例：バウシュ振付の『春の祭典』の 1975 年の振付指導
例：バウシュ振付の『春の祭典』の 1995 年 7 月 7 日の実演

バレエ研は、バレエ上演の分析方法としては FRBRoo の方が優れているとの考えにもとづき、
FRBRoo のモデルに改善を施して、バレエ上演を「興行—公演—演目」という 3 階層のエンテ
ィティと、「計画—遂行」という 2 階層のエンティティの組み合わせとして分析している。
オペラの公演記録も、同様の概念モデルによって分析できる。おそらく、バレエ研の概念モ
デルは、音楽や演劇、さらには学術大会やシンポジウムの記録に至るまで、若干の拡張または変更を行えば広範に利用できるものであろう。以下、オペラ研がどのような概念モデルを作成したか、バレエ研モデルからの改変点を中心に詳述する。

－オペラ研究所の公演概念モデル
バレエ研が「興行（イベント）」というエンティティに担わせた、複数のステージをまとめる役割
は、オペラの世界では「プロダクション」というエンティティが担っているといえるだろう。プロダク
ションは公演団体と演目等により規定され、例えば「○○歌劇団の××年の《魔笛》のプロダクション」といったように認識される。フライヤーやプログラムといった物理資料は、多くの場合、プロ
ダクションに従属する。それゆえ、プロダクションを基本単位となるエンティティとして設けるのが都合がよい。ひとつのプロダクションは、多くの場合、複数のステージにより構成される。
個々のステージは、通常ひとつの演目、ときには複数の演目のパフォーマンスで構成される。

60

ここまでは、「興行」を「プロダクション」に置きかえただけで、バレエ研の概念モデルと相似形である。両者の大きな違いは、オペラ研においては、ひとつの興行において複数の異なる作
品が日を変えて上演されるとき、それぞれの作品を互いに異なるプロダクションに割り当てているところにある。たとえばメトロポリタン歌劇場は 2006 年の来日興行において、《ワルキューレ》と《椿姫》と《ドン・ジョヴァンニ》の 3 作品を、それぞれ異なる日程で上演した。これらは三つの異なる制作物であり、データベースにおいては三つのプロダクションとして登録した。
また、オペラ研の概念モデルには次のような違いもある。オペラ研のデータベースでは、個々のステージにおいて上演される演目は作品ではなく「作品表現」という別のエンティティであると考える。これは FRBR で「著作」の実現体とされる「表現体」に相当する概念である。オペラの公演を扱う際、この階層化を厳密に行うことが大きな意味をもつ。というのも、オペラの公演においては、同じ作品が、日本語訳で上演されたり、原語で上演されたりする。また、もともとはフルオーケストラ用に書かれた作品が室内楽編曲で上演されたり、長い作品が抜粋で上演されたりもする。これらを、元の作品の「表現体」とみなすことができる。個々の表現体では、原則として著作者が異なる。ひとつの表現体が複数のプロダクションにおいて上演されることもあるため、表現体に関係する諸属性は演目エンティティから切り離し、別個の「作品表現」エン
ティティに従属させた。この概念モデルを用いることにより、たとえば、或る作品がこれまでどのようなかたち（言語、編成等）で上演されたことがあるのかを調べることができるようになる。

61

上演を計画と遂行のふたつのレベルで分析する点は、バレエ研に従った。オペラの公演においては、直前になって、ときには当日、出演者が変更されるということがしばしば起きる。実際に出演しなかった人物については、出演の事実がないのだから記録する必要はない、という考えもあるだろう。しかし、その人物で上演が計画されたということも事実であり、その事実はオペラ研の所蔵資料であるフライヤーやプログラムに記されているので、それら所蔵資料にもとづいてデータをつくるという方針に照らせば、記録しておくべきだと考えられる。また、たとえ
出演がキャンセルになったとしても、出演が予定されていた歌手は、その役柄を演じることができたはずだと推定できる。これから新しいプロダクションを作ろうとする事業者が「○○役をできる
歌手にはどんなひとがいるかな」と検索するとき、それらの歌手も、キャンセルになったという情報を含めて、提示した方が検索者の期待に応えられるだろう。同じ理由で、もしキャンセルが発生した場合に代役で出られるようスタンバイしていた歌手たち（カバーキャスト、アンダースタ
ディ）のデータも記録している。

－キャスト表、スタッフ表
ひとつのプロダクションにおいて、同じ役を日によって異なる歌手が演じることがある。いわゆ
る「ダブルキャスト」である。また、ダブルキャストほど一般的ではないが、日や演目によって音響操作が変わる、衣装担当が変わる、といったことも、少なくとも理論上は起こりうる。したがって、キャストやスタッフとして公演に関与する人物は、プロダクションでもステージでもなく、個々のパフォーマンスに関連づけられることになる。しかし、たとえば 10 人の歌手と 30 人のスタッフが関与するプロダクションが 10 回のパフォーマンスを行う場合、ほぼ毎日同じメンバーで上演しているにもかかわらず、それを表現するために 400 行のデータが必要とされる。

62

これがデータの極端な増大をもたらして処理速度を低下させ、またデータ入力の効率も著しく下げていたので、開発プロセスの第 2 周目において「キャスト表」および「スタッフ表」という実体を新たに定義した。人物はキャスト表やスタッフ表に所属する。こうすることにより、ダブルキ
ャストのプロダクションであってもキャスト表をひとつ追加するだけでよくなる。

－公演データの提示
上述の概念モデルは、公演に関する事実を正確に記述することを目的に考案されたものである。そして、事実がどうであるかということと、それをひとがどう認識しているかということは、別の話である。上述のモデルの作成においては、ひとによる意味づけを極力排除し、客観的に確認可能な属性のみをデータ項目として設定した。しかしそれをウェブサイトにおいて提示する際は、利用者がそれをどう認識するかを想定し、事実の把握を容易にするかたちで提示するのが望ましい。
ひとがオペラの公演を認識するとき、プロダクションに附随するエンティティとして、「プログラム」というものが認識されていると考えられる。資料としてのプログラムではなく、演目のセットとしてのプログラムである。たとえば、或るオペラ公演団体が、東京と大阪では A プログラムを、
名古屋では B プログラムを上演するということがしばしばある。事実としては 3 箇所でそれぞれ
特定の演目が上演され、東京の演目と大阪の演目が一致しているだけなのだが、そのような出来事をひとは「プログラム」という枠組みで認識するだろう。そして、演目はステージに付随するものではなくプログラムに附随し、そのプログラムが複数のステージにおいて具体化され63ていると理解するだろう。オペラ情報センターでは、データをウェブサイトで提示する際、デー
タ項目としては存在しない「プログラム」を仮想的に設けて提示している5。

5. さいごに以上、オペラ情報センターの開発事例を紹介・分析してきた。最後に、この分析から得られた主要な知見を一般化して提示する。

1. システム開発の成功のために、発注者と技術者の仲介をし、サービスに求められる要件を網羅的に記述する能力をもった人材が必要である。
2. デジタル・アーカイブ構築の目的は資料の蓄積・保存にあるが、なぜ資料を蓄積・保存するのか、誰のために、なんのためにアーカイブを作るのか、ということを問い、その答えを明
確にしなければ、ユーザビリティの高いサービスは作れない。
3. デジタル・アーカイブの検索サービスを開発するにあたり、オープンソースのディスカバリ
ー・システムの利用を、選択肢のひとつとして検討できるだろう。本稿では VuFind を用いた開発事例を紹介したが、eXtensible Catalog 等のシステムでも同様のことができるだろう。
4. オペラ公演記録を分析するための概念モデルとして、バレエ研の開発した概念モデルを応用できる。オペラ公演を扱うために必要とされた拡張についても本稿で詳述した。
5. 本稿で述べる機会がなかったが、図書館用のシステムは、検索エンジンでのヒット効率を上げる工夫（SEO）に弱い。これについては、独自に多くの改良を施す必要があった。

5

概念モデルをひとの認識に適合するように構築することもできる。その場合、プログラムを、RDB におけるひとつのテーブルとして定義することになるだろう。筆者も、そのようにして概念モデルを構築した
こともあった。詳しくは拙稿「学術データベースとして,消費者サービスとして―図書館用コンテンツ配信
サービスの二面性」（『情報処理学会研究報告』2014-CH-102(7): 1--6. 2014）を参照していただきたい。今回のシステムにおいては、データが過度に複雑になることを怖れ、またデータへの意味づけを後から変更することができるよう、データの概念モデルは客観的事実に適合させることにした。

64

資料篇Ⅱ

『オペラ情報センター』
入力項目

65

資料篇Ⅱ 『オペラ情報センター』入力項目「公演データベース」「作品データベース」「資料データベース」それぞれの入力項目については、以下の通りである。なお、☑のついているものはチェックボックスによる入力項目を示す。

◆マスター化した主な項目
・

人物・団体 → *が参照

・

仕事 → #が参照

・

仕事タイプ ※プログラムの表記順は団体などにより違うため、データの標準化のため表示場所をある程度コントロール

・

会場 → ♭が参照

・

都道府県

・

言語

1. 公演データベース（1）「基本データ編集」画面・

タイトル（日本語／ヨミ／欧文）
前置き
シリーズ

※シリーズや定期公演などタイトル※作品名。公演によっては作品名の和訳が違うなどの場合がある

付加情報
・

☑招聘公演

・

公演団体*

※助成事業等※招聘団体と国内団体の区別をつけて検索可能とするため

拡張
画面表示（日本語／ヨミ／欧文）
・

主催団体*
拡張
画面表示（日本語／ヨミ／欧文）・

プロダクション関与者*※主催、共催、後援、協賛、制作等のプロダクション全体に関66

与する人物・団体を入力
拡張
画面表示（日本語／ヨミ／欧文）・

演目※公演で上演される演目をすべて登録。2 演目併演であれば 2 演目登録

作品

※作品データベースと連動し選択☑字幕あり／字幕出典（日本語／欧文）☑ハイライト上演 上演パート（日本語／ヨミ／欧文）☑コンサート形式 形式注記（欧文）
上演言語※「原語」「日本語」「歌唱＝原語・台詞＝日本語」等、公演によってバリエーションがある
著作者
・

ステージ

※編曲者、字幕制作者、訳詩者、脚色等※上演毎に追加日付（YYYY/MM/DD）
開演時刻（24 時間表記）
会場♭
価格（日本語／欧文）
演目※チケット料金※前項、演目で登録したものから選択

・

画面表示用備考（日本語／欧文）・編集履歴メモ（日本語／欧文）※作業用：管理サイト内のみ表示

・

内部伝達メモ（日本語／欧文）※作業用：管理サイト内のみ表示

67

68

（2）「スタッフ編集」画面・※複数回上演の場合はスタッフのセットを選択可能

仕事#
拡張
画面表示（日本語／ヨミ／欧文）

・

人物*
拡張
所属団体

※プログラムに記載ある場合

画面表示（日本語／ヨミ／欧文）☑キャンセル※キャンセル情報のソース記録するためのテキストボックスあり☑出演不詳※指揮者等、名前は判明しているが、それぞれどの出演日を担当したか分からない場合にチェック☑オリジナル・スタッフ※招聘オペラの場合の外国人スタッフ

69

（3）「キャスト編集」画面・

役名※複数回上演の場合はキャストのセットを選択可能※作品データベースで設定した役名が自動で表示される。登録されている役名

以外の登録が必要な場合は「その他」を選択し、拡張で画面に表示する役名等を登録
拡張
画面表示（日本語／ヨミ／欧文またはローマ字）
・

人物*
拡張
所属団体
画面表示（日本語／ヨミ／欧文）☑キャンセル☑出演不詳※キャンセル情報のソースを記録するためのテキストボックスあり※ダブル、トリプルキャストであるが、それぞれの出演日が分からない

場合にチェック☑カバー☑アンダー※チェックボックスを入れるとカバーキャストとして表示※チェックボックスを入れるとアンダーキャストとして表示

70

71

2. 作品データベース※項目は、平成 21 年度文化庁委託「オペラを中心とした音楽情報・資料の収集および活用に関する調査研究」の調査項目をベースに、オペラ情報センター用にカスタマイズしている。

（1）「基本データ編集」画面
・

原作オペラ

※作品の版違い、編曲版などは原作オペラを設定する。

例）ヴェルディ作曲《ドン・カルロス》→《ドン・カルロ》のように、版の違いにより、原語、
幕構成、配役などの基本情報に大きく差異が出る作品は別作品として登録する。
・

作品名（言語／タイトル／ヨミ）☑オリジナルタイトル／日本語タイトル／英語タイトル（※英文ページ表記用）
拡張（いずれも日本語の場合はヨミを入力）
シリーズ名※連作ものを想定

シリーズ枝番※連作ものを想定

タイトル前置き副題
版↓シリーズ名《ニーベルングの指環》

※凡例

↓作品名
第 1 夜 《ヴァルキューレ》↑シリーズ枝番

・作品言語※作品の原語にあたる

・

作品番号／カタログ番号（Op.や作品のカタログ番号（K 番号、BWV など）

・

著作者
役割#

※作曲、台本、原作等

人物名*※いずれも拡張機能で表示用の表記を設定することが可能
・

作曲年月日（開始／完成）（YYYY/MM/DD）

・

初演年月日（YYYY/MM/DD）

・

初演場所（日本語／ヨミ／欧文）

・

初演団体*

・

幕数（日本語／欧文）

72

・

標準上演時間・

楽譜所在（日本語／欧文）・出版状況（日本語／欧文）・編成（日本語／欧文）

・

原作品（日本語／欧文）・

画面表示用備考（日本語／欧文）・編集履歴メモ（日本語／欧文）※作業用：管理サイト内のみ表示

・

内部伝達メモ（日本語／欧文）※作業用：管理サイト内のみ表示

73

74

（2）「配役データ編集」画面
・

配役
役名（日本語／ヨミ／欧文またはローマ字）※ローマ字は日本作品で欧文設定がない場合、日本語訳名をローマナイズしたときに使用
声種（日本語／欧文）

75

3. 資料データベース
・関連公演※公演を選択し、資料を公演データベースと紐づけるため

・

資料区分

※通常の OPAC の「雑誌」「書籍」の区分の他に、当研究所の所蔵資料に対応するため「チラシ」「プログラム」等を追加
・資料タイトル（言語／タイトル／ヨミ）※奥付がなく資料タイトルがはっきりしないものは公演データベースの「公演シリーズ」「公演タイトル」を表記☑資料の原語タイトル／日本語タイトル／英語タイトル（※英文ページ表記用）
・

所属シリーズ
シリーズ名巻次（日本語／ヨミ／英文）

・

著者
著者種別

※著者、編者等、資料データベースで使用する種別をマスター化している拡張
画面表示（日本語／ヨミ／欧文）
人物・団体*
拡張
画面表示（日本語／ヨミ／欧文）
・

版

・

版著者
著者種別
拡張
画面表示（日本語／ヨミ／欧文）
人物・団体*
拡張
画面表示（日本語／ヨミ／欧文）

・

本文言語

・

出版者（日本語／ヨミ／英文）・

出版地（日本語／ヨミ／英文）

・

出版国

・

出版年月日

・

価格
76

・

刊行物コード（ISBN／ISSN）

・

権利情報（日本語／英文）・

アクセス情報（日本語／英文）・

MARC21 書誌属性

・

NDL 分類・内容細目※「芸術 - 音楽」で初期設定

ページ
章題
☑原語章題
☑日本語章題として表示☑英語章題として表示
言語☑ローマ字転写
著者
人物
・

関連人物*

・

関連作品

・

備考（日本語／欧文）・編集履歴（日本語／欧文）・

内部伝達メモ（日本語／欧文）※作品データベースと連動※作業用：管理サイト内のみ表示※作業用：管理サイト内のみ表示

77

78

平成 24～28 年度 文部科学省私立大学戦略的研究基盤形成支援事業

オペラ資料のアーカイヴ化を通じた情報センター機能の構築
研究成果報告書

平成 29（2017）年 5 月発行
学校法人東成学園
昭和音楽大学オペラ研究所〒215-0004
神奈川県川崎市麻生区万福寺 1-16-6
TEL
044-953-9858
FAX
044-953-6652
E-MAIL opera@tosei-showa-music.ac.jp
URL
http://www.tosei-showa-music.ac.jp/opera/

本報告書の全部または一部を、著作権法で定められている範囲を超えて、無断で複製・転載・公衆送信等を行うことはできません
非売品

昭和音楽大学オペラ研究所
http://www.tosei-showa-music.ac.jp/opera/