ところで、先日、国立公文書館から、
というものが公開されたようで、「調査・報告書等」のページから閲覧できるようになっています。前の記事にてご紹介したブログを公開しているインフォコム株式会社さんの名前が最初のページに書いてあるので、インフォコムさんが作成されたのでしょうか？この調査報告の発注した文書などを確認すればわかるのだと思いますが、それは、どなたか、識者の方にご教示いただけますとたいへんありがたく存じます。
内容的には頑張って色々まとめておられて、「最新のIT技術（情報技術技術？）を活用した」というにはそんなに最新な感じはしませんが、現状を把握するにはよい文書なのではないかと思います。細部には色々気になる点もありますが、そういうところには突っ込みを入れつつ、これを使って読書会などをしてみるのもよいのではないかと思います。
ただ、拝読していて、ここは誤解を招きかねないのでちょっと書き換えていただいた方がよいのではないか、というところがあったので、念のため、ちょっと以下にメモしておきます。特に気になったのは、70ページの以下の記述です。
IIIF に対応したビューアである OpenSeadragonは、JavaScript で実装されたオープンソースの画像ビ ューアである。様々な解像度の画像を、解像度ごとにタイル画像に分割しておくことで、スムーズな拡大・ 縮小と移動を行える操作性が特徴である。ただし、この機能を構築するには、タイル画像を事前に用意 する必要があり、元の画像データの数倍から数十倍のディスク容量が必要となる。
先にまとめておくと以下の2点です。
（1）IIIF対応ビューアとしてOpenSeadragonを挙げるのは不適切
（2）「元の画像データの数倍から数十倍のディスク容量」を必要としないどころかJpeg画像そのままでもIIIF対応は十分可能。
まず、（1）ですが、
OpenSeadragonは、IIIF Image APIにしか対応していないので、「対応したビューアである」という例として挙げるのはよくないと思います。IIIFに対応したビューアを挙げるなら、Mirador, Universal Viewerなど、IIIF Presentation APIにも対応しているビューアを挙げないと、ミスリードになると思います。もし、OpenSeadragonを紹介したければ、別項を立てればよいと思います。
なお、OpenSeadragon自体はとても良い画像ビューワで、私もよく使っていますが、通常のIIIFビューアに比べると利用者に直接提供する機能はかなり少なめです。APIが充実しているので、開発者がユーザ向けにいろいろな機能を追加して提供することがかなり容易にできます。そこで、IIIF対応ビューアの中でもMiradorやUniversal ViewerはこのOpenSeadragonを内部で利用しています。
次に、（2）ですが、
OpenSeadragonが標準的に対応している画像配信（？）形式であるDeepZoom形式では、確かに、分割タイル画像を用意しておく必要があります。しかし、OpenSeadragonが対応している画像配信形式にはIIIF Image APIもあります。（ここではこの話のはずです）。IIIF Image APIの場合は、画像をどういう風に用意するか、というのは画像配信サーバに依存する形になります。そこで、画像配信サーバがどういう画像を配信できるか、タイル画像を事前に用意しなければならないのか、という話になるのですが、このブログでも以前にご紹介した digilibというIIIF対応画像配信サーバソフトでは、画像をJpeg画像のままで配信できます。そうすると、元画像の数倍のディスク容量、どころか、まったくディスク容量を増やす必要はありません。たとえばこちらのサイトではdigilibで400万枚ほどの画像を配信していますが、特に問題なく配信できていると思います。あるいは、Loris IIIF Image ServerというIIIF対応画像配信サーバソフト（これはUbuntuへの導入の仕方を2SC1815Jさんが紹介しておられます）では、ディスクにキャッシングをするようですので、キャッシュ用ディレクトリに多少ディスク容量を多めにとる必要があると思いますが、それでも元画像の数倍～数十倍、ということはないのではないかと思います。
まとめますと、この報告書を信頼して読んだ人は、OpenSeadragonを使ってみて「うーん、IIIF画像を読み込ませるのにこんなに手間がかかる上に、この程度のことしかIIIFではできないのか」と思ってしまうでしょうし、「数倍から数十倍のディスクを用意しないとIIIFには対応できないのか」と思ってしまうでしょう。もちろん、IIIFの本家のサイトを読んだりこのブログを見たりして自力で情報収集できる（時間のある）人には問題ないと思うのですが、この報告書は、そういう人向けではないと思いますので、なるべく、適切な情報を提示しておく必要があると思うのです。
そして、これを踏まえた上で気になるのは、85ページの、「コスト IIIF への対応にはコストがかかる。 」という記述です。確かに、0円ではできません。が、IIIF Image APIへの対応は、digilibでよければ、ソフトウェアを一つ入れるだけで済みますし、Lorisでいいなら、ソフトウェアを入れることと、キャッシュ用に多少のディスク容量を用意しておくだけでもなんとかなるはずです。（ただしLorisに関する私の知識は2年前なので現在は変わっているかもしれません）。「ディスク容量を数倍から数十倍に」というのと、「サーバソフトを入れるだけでも大丈夫」というのとでは、コストがかかると言ってもまったく印象が違ってくると思います。
それから、ついでに、数日前に、「資料が増えると対応の手間がその分増えて時間もかかるのではないか」という質問をいただいたので、そういうコストを想定することもあるのかと思って念のため書いておきますと、IIIF Presentation APIのファイルは、メタデータセットがあって、画像全体のディレクトリへのアクセス権限を持っているプログラムを作ることができれば、あとはそこから自動的にJSONファイルを出力するだけです。たとえば、こちらの約400万枚／1万9000点の古典籍資料と、こちらの12冊の本とでは、Presentation APIへの対応にかかる手間はほぼ同じです。プログラム作って、それを動かして自動的にファイルを生成するだけです。ファイル生成作業も、そもそも、動的にmanifestファイルを生成するようなシステムにすれば、不要になってしまいます。
IIIFへの対応には、確かにコストがかかります。ただ、そのコストを大きく見積もりすぎた結果、我が国がまたしても国際的な流れから大きく遅れをとるようなことになってしまいますと、さすがに今回はちょっと取り返しのつかないことになってしまうのではないかと心配しております。
今のところ、IIIFに対応してくれている「デジタルアーカイブシステム」提供企業としては、私が把握している限りでは、内閣府知的戦略本部のワーキンググループでも報告した話ですが、以下のようになっています。
• ㈱NTTデータ
• ヴァティカン図書館
• インフォコム㈱
• 東日本大震災アーカイブFukushima／国立歴史民俗博物館（総合資料学の創成プロジェクト）／岡山県立記録資料館
• ㈱メノックス
• 慶應大学メディアセンター（福沢諭吉コレクション・グーテンベルク聖書・奈良絵本・解体新書等）（公開予定）
• ㈱寿限無
• 秋田県立図書館オープンライブラリ／高知県立図書館デジタルアーカイブ（試行版）（但し、IIIFでの運用方法が未定のため、来期以降運用等を検討予定）
基本的に、IIIFは、画像をうまく共有するための基盤の提供のための枠組みであり、そこはなるべく低コストに安価に提供していただいて、画像配信に関するビジネスとしては、配信した画像の上に何をどうのせていくか、というところで勝負をしていただけるとありがたいと思っております。IIIFが広まれば広まるほど、「その上に何かをのせる仕組み／サービス／ビジネス」の有用性は高まっていきます。また、みなさまがそれぞれに蓄積しておられる技術も、そこで改めて色々再展開できるものがあろうかと思います。Webが広まったことでいろいろなビジネスが開花していることと、規模の違いはあるにせよ、相似の関係にあると思います。そのような観点から、企業のみなさまには、ぜひとも、日本のデジタル文化資料を生かし、世界に貢献していけるような基盤を作り、ご提供していっていただけたらと思っております。
（なお、企業のみなさまにおかれましては、IIIF対応サービスや対応機関などの情報がありましたら、当方までお知らせいただけますとたいへんありがたく存じます。）
