# [C14] 国際的な画像共有の枠組み IIIF の課題と展望

○永崎研宣 ${ }^{11}$

1) 一般財団法人人文情報学研究所，〒 113-0033 東京都文京区本郷 5-26-4

E-mail:nagasaki@dhii.jp
## Issues and Prospects of the International Image Interoperability Framework from a viewpoint of a Japanese Practitioner

Kiyonori Nagasaki1)

1) International Institute for Digital Humanities, 5-26-4, Hongo, Bunkyo-ku, Tokyo, Japan

## 【発表概要】

国際的な画像共有の枠組み IIIF は世界的に大きな広まりをみせつつ、日本でも徐々に普及が進みつつある。IIIF にはいくつかの課題があるものの、コミュニティによって解決へと進められつつある。一方、IIIF に限らず、高精細画像の公開・共有につきものの課題もあるが、これが IIIF の課題と混同される例もある。そこで、本発表では、高精細画像の公開・共有における課題と IIIF における技術面・運用面での課題とを切り分けてそれぞれに提示するとともに、その解決方法について検討する。

## 0. はじめに

IIIF（トリプル・アイ・エフ International Image Interoperability Framework) は、 Web 上のデジタルコンテンツを効果的効率的に公開・共有するための仕組みとしてデジタルコンテンツ公開機関の間で国際的に急速に広まってきている。IIIF の技術的な内容やメリットについてはすでに論じてきているが、 ここでは特に、IIIF の導入にあたって留意すべきいくつかの課題について検討してみたい。

## 1. 画像配信にまつわる課題

IIIF は Web コンテンツ全般を対象とするものだが、現在のところでは、その名が示すとおり、画像配信が中心となっている。この画像配信に際しては、いくつかの留意すべき課題がある。これらは、IIIF の課題というよりはむしろ高精細画像の公開における一般的な課題として捉えた方がよい事柄がほとんどであるように思われるが、それを踏まえつつ以下に検討してみたい。

## 1. 1. タイル画像のサイズ

IIIF では、高精細画像を配信する際に、複数種類のサイズを用意しておき、クライアントである Web ブラウザからの要求に応じて適切なサイズの画像を配信し、さらに、一定程度以上に大きな画像については分割（タイル画像化）して必要なタイルのみを配信するという仕組みが用意されている。

この仕組みに対応するには、IIIF の画像配信ルール IIIF Image API に対応してアクセス毎に画像サイズを変更したり必要に応じてタイル画像を生成したりするタイプの IIIF 対応画像サーバソフトが必要となる。すでにフリーソフトで様々なタイプのものが公開されているため、ソフトウェアの導入にかかるコストは最小限で済む。通常の Jpeg 画像をそのまま IIIF 配信用に利用することも可能である。ただし、サーバ・ネットワークの環境にもよるが、筆者の経験からすると、 1 枚あたり $3 \mathrm{MB}$ 以上の容量の画像を配信しようとする場合、事前にタイル化した画像を配信するタイプのサーバソフトの方が利用者のストレスを高めずに済みそうである。ただし、このタイプのサーバソフトの場合、事前にタイル化された複数サイズの画像を用意することになるため、ストレージの容量を多く必要とすることになる点には留意しておく必要がある。画像をタイル化して保持しておく場合には、 Pyramid Tiled Tiff 形式か、Jpeg2000 形式、 あるいは、タイル画像化した個々のファイルをファイルとして保存する Deep Zoom 形式

などが用いられることになる。ただし、IIIF にフル対応しようとすると、今のところ前 2 者が一般的である。さらに言えば、Pyramid Tiled Tiff の場合には、一般的な画像処理用のフリーソフトウェアを用いて十分な速度で処理できるため、IIIF 用の高精細画像フォーマットとしては、IIP Image Server を画像配信サーバとしつつ比較的広く用いられている。

画像のタイル化に際して問題となることの一つは、タイル画像のサイズである。画像を含めたあらゆる Web コンテンツは、Web サ一バから配信すると、1 ファイルを配信するごとにサーバとクライアントの間で色々なやりとりがオーバーヘッドとして発生する。夕イルが小さければ小さいほど、1 タイルあたりの配信は確かに速くなるが、やりとりされるタイルの数が増える分だけ、オーバーヘッドも大きくなってしまうので、結果的に遅くなってしまう上に、オーバーヘッドの大きさは、単にクライアントに対して負担を大きくするだけでなく、ネットワーク経路への負荷もそれなりに大きくなってしまうことになる。一度に大勢が利用するような場合には特に配慮が必要となる。したがって、タイルを小さくしすぎないことにも留意する必要がある。筆者の場合にはとりあえず 256x256 のタイルサイズで作成しているが、たとえば以下のように、512x512 のタイルで配信しているサイトもある。

https://open.library.ubc.ca/collections/toku gawa/items/1.0227946

https://iiif.library.ubc.ca/presentation/cdm .tokugawa.1-0227946/manife (IIIF manifest) https://iif.library.ubc.ca/image/cdm.tokug awa.1-0227946.0000/info.json (info.json)

さらに、大きな地図を公開している例では 2147x1434 とか 2142x1756 のようなかなり大きなサイズのタイルにしているところもある。

2147x1434 の例 : https://searchworks.stanford.edu/view/112 98997

https://purl.stanford.edu/hs631zg4177/iiif/ manifest (IIIF manifest)

https://stacks.stanford.edu/image/iiif/hs63 1zg4177\%252Fhs631zg4177_00_0001/info.js on (info.json)

特に、現在ほとんどの Web サイトで使われている HTTP1.1 では、一度に配信する数が多い場合、オーバーへッドがかなり大きくなってしまう。大きな画像を閲覧している際にはじからはじまでさっと移動させると、それだけで膨大な数のタイル画像の転送をサーバ側に要求することになってしまい、画像配信がものすごく遅くなってしまうことがある。 そのような場合には、タイル画像のサイズを大きめにして、転送数を減らすという方向も有力な選択肢となり得るだろう。

## 1. 2. タイル画像の大量同時配信

詳しい技術的な解説には踏み込まないが、基本的に、Web のコンテンツ配信で用いられているプロトコル HTTP/HTTPS は、大量のファイルを一度にサーバから送出するという使い方に適したものであるとは言いがたい。特に、現在広く使われている Web サーバソフ卜環境では、HTTP1.1が使われていることが多いが、これは、KeepAlive の設定を On にしておかないと、たくさんのファイルを配信したときに転送数制限に引っかかってしまい、 たとえば IIIF 画像を閲覧しているとタイル画像やサムネイル画像の読み込みが途中で止まってしまうことになる。最近の Linux OS に同梱されている Web サーバソフトではこの点は問題ないが、Redhat6 やentOS6 の Apache では、KeepAlive がデフォルトでは On になっていないため、最新版のサーバ OS でない場合には注意が必要だろう。

また、KeepAlive の設定を On にしていたとしても、やはりどうしても、配信ファイル数が多くなる場合のオーバーヘッドの大きさという問題は残る。それをよりうまく解決

する方法として、従来広く使われてきた HTTP1.1 ではなく HTTP/2 を採用するという選択肢がある。たとえば、筆者がシステム構築を行った万暦版大蔵経デジタル版1では、画像配信に $\mathrm{HTTP} / 2$ を採用しており、タイル画像配信における問題がかなり解消されている。サーバ用途でよく用いられる CentOS でもバージョン 7.4 から HTTP/2 に対応しており、ユーザビリティを高めるための選択肢として検討すべき事項の一つである。

## 1. 3. 画像配信サーバソフトの導入

画像配信サーバソフトのインストールや設定に関しては、作業自体はそれほど難しいわけではない。いくつかの解説サイトを見て手順通りに作業すれば十分である。ただし、

(1) Python か ruby の CGI を動してよいか、

（2）C++のソフトを CGI として動かしてよいか、（3）Tomcat サーバを動かしてよいか、といった点について、サーバ運用に関する組織のポリシー、特にネットワーク運用ポリシー やセキュリティポリシーとのすりあわせを行う必要がある。いずれもダメということになった場合には、IIIF Image API をフル機能で導入することはやや難しくなる。この点は、 たとえば、同じ高精細画像配信であっても Open Seadragon の Deep Zoom 形式であれば、画像配信用サーバソフトがなくてもタイル化された Jpeg 画像を所定の Web ディレクトリに置いておくだけで利用可能であることに比べると、状況によっては割と大きな障壁となる場合がある。また、費用面に関しても、導入費用だけでなく保守費用も高くなる可能性があることは念頭に入れておく必要がある。 また、言い方を変えると、画像配信サーバソフトのインストールがネットワーク・サーバの運用ポリシーに抵触しないのであれば、導入自体は容易であると言うこともできる。

## 1. 4. タイル画像化する場合の留意点

上述のように、タイル画像化することで大容量の高精細画像を比較的高速に配信するこ
^{1}$ https://dzkimgs.l.u-tokyo.ac.jp/kkz/
}

とができるが、ストレージの容量を多く必要とすることになる。さらにもう一つの問題として、画像を Pyramid Tiled Tiff に事前変換する場合に、フリーソフトウェアで簡単に一括変換をすることは可能だが、処理にそれなりの時間がかかってしまうという点も留意しておきたい。たとえば、万暦版大蔵経デジタル版では、画像処理専用マシンではないにせよ、 4 台のサーバマシンの余力をそれぞれ利用し、 8000 万画素で撮影した 19 万枚の TIFF 画像（1 枚女たり 250MB）からの変換には、あわせて 1 ケ月ほどを要した。IIIF での高精細画像の公開を準備する際にはこれにかかる時間も見積もって計画を立てる必要がある。

## 2. 他の機関に画像を持って行かれるよう にみえる／公開機関の存在感がなくなる

この問題については、「デジタル文化資料の国際化に向けて」という論考 2 の p. 65 の 「IIIF の導入に伴う公開の在り方の変化」という節で述べているが、これもう少し付け加えるなら、「デジタルアーカイブ」の利活用を広げ、デジタル時代の知識流通基盤を確かなものにしていくためには IIIF のような利用のされ方が必要にならざるを得ず、しかもそのためには、各「デジタルアーカイブ」で共通のルールが用いられる必要があることから、現時点では、デジタル化文化資料の高精細画像を共有する機能に関しては IIIF の仕様を採用するより他に良い選択肢はないだろう。あるいは、その選択肢を採らないとしたら、そうした世界から敢えて距離を置くことになるのであり、それについての整合的な説明をできるようにしておく必要があるだろう。

なお、IIIF manifest ではライセンス情報の記述が必須となっているが、Image API 単独での利用においても、画像毎にライセンス情報を付与できる仕様が Image API には用意されている。状況によっては、これを活用することも考慮するとよいかもしれない。
^{2}$ https://doi.org/10.18919/jkg.67.2_61
}

## 3. IIIF Manifest ファイルのサイズ

IIIF Manifestファイルは、JSON-LD 形式で資料の情報を記述するものだが、状況によっては数 MB になってしまうこともある。ビユーワによっては、これをすべて読み込んでからでなければ画像アクセスが始まらない場合もあり、IIIF Manifestファイルを速く読み込むことは利便性を高めるための重要なポイントである。対策としては、Web サーバ側で JSON ファイル配信時に gzip 圧縮を行う設定をするという方法がある。たとえば Apache の場合には、mod_deflate で.json に圧縮がかかるようにすることになる。テキストデータである IIIF Manifest の場合、 gzip 圧縮の効果は大きく、筆者のケースでは体感的にも十分な効果があった。

## 4. HTTPS 問題

近年、認証を必要とするシステムでは、

HTTPS に対応することが求められるようになってきている。そして、IIIF が依拠する仕組みでは、HTTPS のサイトに IIIF コンテンツを読み込ませようとすると、IIIF コンテンツも HTTPS 対応していなければならない。 これは、Web ブラウザの仕様による制限であって、IIIF の問題ではないが、とにかく、 HTTP で公開しているコンテンツは、HTTPS で運用されることの多い一般的な Web コラボレーションシステムのようなものでは取り込めなくなってしまうことが多い。したがって、 IIIF コンテンツを HTTPS で公開することは必須になりつつあります。そのためには SSL の証明書が必要になります。最近は、Let' s encrypt というフリーの SSL 証明書取得サー ビスが広まっているので、これを利用して HTTPS 対応するという選択肢が出てきてい
る。とりあえずはこれを利用しておくという手もあるだろう。

## 5. 仕様のアップデート

IIIF の API の仕様は他の仕様と同様に、情報技術やその周辺環境の発展にあわせてそれなりの頻度でアップデートされる。HTML の例に見られるように、デザインやビューワなど、進歩とともにそれにあわせた改良の必要も出てくるだろう。仕様がアップデートされた後、ソフトウェア環境や周辺環境がそれに対応していくには若干のタイムラグがあり、最新を追い求めなければならないわけではない。むしろ、最新を追い求めるとソフトウェア環境や周辺環境が対応できないため、周囲の状況を確認しながら対応していくことになる。とは言え、しかし、日本の多くの機関の発注の手続きでは、導入の計画を立てた後に実際に使えるようになるまでにかなりのタイムラグが生じるため、状況の安定を見届けてからアップデート版の計画を始めるとなるとやや遅きに失する感もある。なるべく適切なタイミングを見極められるようにするために、何らかの情報共有の枠組みなども今後整備していく必要があるだろう。

## 6. 終わりに

IIIF の導入には、少なくとも技術的にはそれほど大きな課題はなく、ここまで見てきた課題の中には、IIIF の課題というよりはむしろ、高精細画像を Web 上で公開する際の一般的な課題として捉えるべきものも少なくない。広がりつつある国際的な大きな潮流にうまく対応することで、日本のデジタルアーカイブがその利活用の幅をより大きく広げていくことを筆者としては願っている。

この記事の著作権は著者に属します。この記事は Creative Commons 4.0 に基づきライセンスされます(http://creativecommons.org/licenses/by/4.0/)。出典を表示することを主な条件とし、複製、改変はもちろん、営利目的での二次利用も許可されています。