アクセス制御付き IIIF デジタルアーカイブの構築 — Cloudflare Access で守る Cantaloupe + S3 + Elasticsearch + Next.js
未公開 / 限定公開の歴史写真を、IIIF 規格に準拠した形でアクセス制御付きで配信するアーカイブシステムの構築記録。Cantaloupe（IIIF サーバ）+ S3 互換ストレージ + Elasticsearch（検索）+ Next.js（UI）+ Cloudflare Tunnel + Access という構成で、一般公開できない画像であっても IIIF の利点（規格準拠の高解像度ビューア / manifest 配信）を許可されたメンバー範囲内で享受できる仕組みを設計しました。外部システムからの相互運用には IIIF Auth API 2.0 への拡張が必要となる点も整理しています。
iiifcantaloupeelasticsearchnextjscloudflareaccess-controldigital-archives3digital-humanities
台本(フルテキスト)
動画の掛け合いを書き起こしたものです。音声を再生しづらい場合はこちらをお読みください。
オープニング
- 一般公開できない画像を限定公開で IIIF の利便性を活用
- Cantaloupe + S3 + Elasticsearch + Next.js + Cloudflare Tunnel + Access
- はう
- こんにちは。今日はアクセス制御付きの IIIF デジタルアーカイブを構築した記録を紹介します。
- めたん
- IIIF のデジタルアーカイブにアクセス制御が必要になるのはどういう場面ですか？
- はう
- 著作権・肖像権・所蔵者との契約などの理由で一般公開できない歴史写真でも、研究者や編集スタッフなど限定されたメンバーには IIIF ビューアで高解像度閲覧させたいケースです。
- めたん
- どんな技術スタックを使っているのですか？
- はう
- Cantaloupe が IIIF Image API サーバ、S3 互換ストレージが画像置き場、Elasticsearch が検索とメタデータ管理、Next.js が UI と manifest 生成、Cloudflare Tunnel と Access が認証ゲートです。
- めたん
- Cloudflare Access でどのようにアクセスを制限するのですか？
Cloudflare Access による認証ゲート
- Email OTP または SSO で認証 → CF_Authorization cookie 発行
- 同一オリジンで Web も IIIF も 1 つの cookie でカバー
- はう
- Cloudflare Zero Trust の Access を使い、Single-hosted アプリとしてドメインを登録します。Email の OTP か SSO で認証すると CF_Authorization cookie が発行されます。
- めたん
- IIIF ビューアがタイルを取りに行くときも認証が効くのですか？
- はう
- 同一オリジンなので cookie が自動的に乗ります。ブラウザ標準の挙動だけでビューアのタイル要求にも cookie がつくので、追加コードは一切不要です。
- めたん
- なぜサブドメイン分割ではなくパスベースにしたのですか？
- はう
- Cloudflare の Universal SSL は 1 階層のワイルドカードしかカバーしないため、2 階層のサブドメインは TLS が通りません。またパスベースなら CORS 調整も不要で Access ポリシーも 1 つで済みます。
- めたん
- Cloudflare Tunnel を使う利点は何ですか？
- はう
- origin から edge への outbound の永続接続を張る方式なので、public IP が不要で inbound 通信を遮断したまま公開できます。学術クラウドの NAT 環境でも使えます。
Cantaloupe と S3 互換ストレージ
- Cantaloupe の S3Source で S3 互換から直接タイル生成
- path_style_access=true を忘れると S3 互換ストレージで失敗
- めたん
- Cantaloupe を選んだ理由は何ですか？
- はう
- S3Source が内蔵されていて S3 互換ストレージから直接 JPEG タイルを生成できること、設定がプロパティファイル一枚で Docker Compose だけで完結すること、derivative cache がある点が決め手でした。
- めたん
- S3 互換ストレージで設定の注意点はありますか？
- はう
- path_style_access=true を設定しないと virtual-hosted style URL になってしまい、多くの S3 互換ストレージで失敗します。また Cantaloupe 5.x で access key が効かない場合があり、AWS の環境変数も冗長に渡すことで回避できます。
- めたん
- S3 のキーに CJK 文字を使うとどんな問題が起きますか？
- はう
- CJK を含むキーで署名検証が失敗することがあります。安全な対処は ASCII flat のキー、例えば photos/<basename>.jpg のような形に統一することです。
- めたん
- manifest の canvas 寸法はどこから取るのですか？
データパイプラインと Elasticsearch
- raw → normalize → index → sync の段階的パイプライン
- ES を真理ソースにして S3 の LIST 依存を避ける
- はう
- manifest の canvas 寸法は Cantaloupe の info.json から取るのが IIIF の流儀です。Next.js が fetch cache を使って 3 段重ねでキャッシュするので実用上のオーバーヘッドはほぼゼロです。
- めたん
- Elasticsearch のセットアップに制約はありましたか？
- はう
- analysis-kuromoji プラグインを入れられない制約があったため、n-gram bigram analyzer で部分一致を実現しました。match_phrase と組み合わせると substring 検索と同等になります。
- めたん
- データのバッチ処理はどうしているのですか？
- はう
- raw データは read-only のまま保持し、normalize スクリプトが symlink で clean tree を構築します。その後 indexer が ES に upsert し、sync スクリプトが S3 に並列アップロードします。
- めたん
- S3 の LIST に依存しない設計にしているのですか？
- はう
- S3 互換の LIST は 1000 件で頭打ちになる実装があるため、ES に s3_uploaded フィールドを持たせて ES を真理ソースにしています。これで差分 sync や健全性チェックが楽になります。
IIIF Auth API 2.0 との関係とまとめ
- 現構成は HTTP 層のみ — 同一組織ブラウザで完結
- 外部 IIIF クライアントとの相互運用には IIIF Auth API 2.0 を別途実装
- めたん
- 外部の IIIF クライアントからも見られるようにするにはどうすればよいですか？
- はう
- IIIF Auth API 2.0 を実装する必要があります。現構成は同一組織内ブラウザでの cookie 認証に特化した構成で、外部クライアントへの非インタラクティブな相互運用には対応していません。
- めたん
- 今回の構成の主な特徴をまとめてください。
- はう
- 同一オリジンに Access ポリシーを貼るだけで、Web UI も IIIF 配信も 1 つの認証セッションでカバーできます。完全公開と完全非公開の中間的な「メンバー限定公開」を IIIF 規格に沿った形で実現します。
- めたん
- 公開できない資料でも IIIF ビューアの利便性を活かせる点が価値ですね。
- はう
- そうです。校閲や研究作業で高解像度確認が必要な場合に、一般公開は別途検討しながら内部利用だけ IIIF で実現できる点が本構成の主要なメリットです。