第1版 候補1(候補版・非規範)
本版は候補版であり、規範性を持たず、内容は予告なく変更されます。引用には承認版(DOI付き)をお使いください。
本版も承認版と同じく CC BY-NC 4.0 と互換の利用条件で提供されます。版の状態(作業版・候補版・承認版)によって、利用条件が変わることはありません。
本ガイドラインは、デジタル・ヒューマニティーズ・コンソーシアム(DiHuCo)の研究実践ハブが作成するものである。大きな柱は、地図・地誌類のユースケース、およびデジタル人文学一般のユースケースである。特に、実践知、すなわち研究においてどのようにデータを作り、どのように処理し、どのような問題を問いたかといった実践的な知識に焦点を合わせる。
以下のガイドラインは、実践知に関する講演や記事を素材とし、研究実践ハブが指定したガイドラインの構造にしたがって、AIが文章を生成したものです。ガイドラインのテキストに対して、記事へのリンクを設置し、記事からはその根拠となる講演資料やリンク先などをたどることができます。このようにテキストの由来を検証できる仕組みを用意することで、AIの柔軟性と専門家の信頼性とを統合することを目的とします。
本ガイドラインの一つの柱である地図・地誌情報についてまとめる。
地図と地誌は、地理空間と情報空間という異なる次元で場所を記述する。地名は、この二つの次元を橋渡しする役割を持つ。
地理情報の扱いにおいて、データは大きく二つの空間に分けられる。 地理空間（Geographic space）は、点・ポリゴン・ピクセルといった幾何学的な構造を持ち、地球上の場所に対応する地図のデータである。 情報空間（Information space）は、ある場所に関する資料・画像・説明文など、その場所がどのような場所かを伝えるメディアのデータである。 [UC-011 §3. 「どこ」を特定する——情報空間・地理空間・つなぐ空間]
地図はこのうち地理空間の側を担い、座標系によって位置を記述する。地誌（ガゼティア）は情報空間の側を担い、地名に紐づく記述・属性・資料群をまとめる。両者はそれぞれ独立した形式で地理的な知識を表現しており、単独では相互の参照が難しい。
地理空間と情報空間を接続するのがつなぐ空間（Connecting space）であり、その核心にあるのが地名（トポニム）である。地名は座標（地図側）と識別子（資料側）の両方を併せ持つことで、二つの空間の対応関係を媒介する [UC-011 §3. 「どこ」を特定する——情報空間・地理空間・つなぐ空間]。
歴史データの分析における「どこ」の特定には二通りの経路がある。一つは文章中に出てくる地名を取り出してその位置を特定する経路、もう一つは地図そのものを分析して画像上の位置から実世界の場所を割り出す経路である [UC-011 §3. 「どこ」を特定する——情報空間・地理空間・つなぐ空間]。前者の経路では、たとえば「東京」という地名を媒介として、資料中の記述を地図上の座標へと変換した上で分析を行う。緯度経度として直接表現されている場合はそのまま対応づくが、そうでない場合はこの変換の過程が必要になる [UC-011 §3. 「どこ」を特定する——情報空間・地理空間・つなぐ空間]。
後者の経路、すなわち地図画像から実世界の座標を求める作業はジオレファレンスと呼ばれ、古地図の処理において重要な技術となる。この点の詳細は「古地図の処理」を参照。
地名が地理空間と情報空間をつなぐ識別子として機能するためには、同一の地名が一意に参照できる必要がある。しかし地名は時代や資料によって表記が揺れ、同一の地点が複数の名称で呼ばれたり、異なる地点が同名を持ったりする。このことは、地名に識別子を与え、属性（座標・時代範囲・別称など）を管理する地名データセットおよび地名サービスの設計を、単純な文字列のマッチング以上の問題にする。地名データセットや地名サービスの具体的な構造と実例については、それぞれ「地名データセット」および「地名サービス」を参照。
テキスト中から地名を抽出し座標へ変換するジオコーディング、および歴史的地名の処理については「テキストとしての地誌」「歴史的ジオコーダー」が扱う。
地図は現実世界の写しではなく、地上の特徴の中から必要なものを選び、抽象化・シンボル化して表現したものである。 この「情報の選択と削減」という性格が、地図を衛星画像などの網羅的な記録媒体と区別する。 [UC-009 §地図とは何か]
衛星画像や航空画像は、地上の状況を解像度の許す限り網羅的に記録したものである。 何が重要かを区別せずすべてを平らに記録するため、正確さという点では地図より優れている。 しかし焦点がないため、必ずしも使いやすいわけではない。 [UC-009 §地図とは何か]
地図はこれとは対照的に、利用者にとって重要な部分を取り出し、それ以外を省略・加工した表現である。 道路を実際より太く描いたり、重要度に応じて色を変えたりといった強調が施される。 日本の地図には駅が必ず描かれる一方、鉄道を重視しない国の地図では駅が省略されることもある。 また、渋滞や温度のように直接は目に見えない情報を重ねて表現することもできる。 現実とまったく同じ解像度の地図は現実と同じ大きさになってしまい意味をなさないため、情報をいかに削減してコンパクトに見せるかが地図の要点である。 [UC-009 §地図とは何か]
地図は距離や方向の点で必ずしも「正しい」必要はなく、目的に応じて必要な情報を可視化することにこそ本質がある。 この点をよく示す例が、1933年にHarry Beckが作成したロンドン地下鉄路線図である。 路線を縦・横・斜めの直線だけで描いており、実際のくねった経路とは形も距離も一致しない。 地理的には正確でないものの、路線内の駅の順番、路線どうしの乗り換え場所、テムズ川の位置については正しく描かれており、地下鉄で移動して乗り換えるという目的に対して最も使いやすい形になっている。 [UC-009 §地図とは何か]
地球全体を表示しようとすると、3次元の球面を平面に変換する必要が生じる。 球面を平面に押し込めるとどこかが必ず歪むため、投影法は何を保存するかによって性格が分かれる。 保存の対象には長さ・面積・角度・形があり、これらすべてを同時に保存することはできない。 [UC-009 §地図投影法]
保存する性質に応じて、投影法は大きく三つに分類される。
目的に応じてこれまでに100種類以上の投影法が提案されてきた。 具体的な投影法としては、データ処理に便利な正距円筒図法（cylindrical equidistant）、視点を地球の中心から無限遠まで離して眺めた正射図法（orthographic）、緯度と経度が直交するものの極に近づくほど面積が拡大し極域を描けないメルカトル図法（Mercator）などがある。 メルカトル図法を改良したUTM（Universal Transverse Mercator、ユニバーサル横メルカトル図法）は、地球を経度6度ずつ60のゾーンに分割し、中央子午線からの距離をx座標、赤道からの距離をy座標として定義することで、全体の歪みを最小化する。 [UC-009 §地図投影法]
地図は現在の空間だけでなく、過去の地理空間を記述・復元する資料としても機能する。 歴史研究において「何がどこで起こったか」を問うには現代の地図ではなく当時の地理情報が不可欠であり、過去の地図を現代地図に重ね合わせることで初めて、ある場所が江戸時代にどの村と呼ばれていたか、現在は陸地となっている地域がかつて海であったかが読み取れる。 [UC-012 §背景：歴史ビッグデータと過去の地理情報の整備]
こうした重ね合わせを実現する古地図処理の手法については「古地図の処理」を参照。
地理情報システム（Geographic Information System、GIS）は、地図を表示するだけでなく、地図の作成、情報の付加、データの管理・可視化・分析までを担うソフトウェアであり、その周辺の学問体系でもある。 [UC-009 §GISの機能とレイヤー]
GISが情報システムとして認識されたのは1964年ごろ、最初のGISはカナダで国土利用を管理する目的から生まれた。 日本ではインフラ分野や政府の地理情報管理への適用が先行し、1970年代は基礎研究と政府利用が中心だった。 1980年代にはパソコンの普及とともにESRIなどの企業による商用パッケージが登場した。 [UC-009 §地理情報システムの60年の歴史]
1990年代にはGPSが軍事用途から民間に開放され、カーナビゲーションが最初の民間応用となった。 2005年に登場したGoogle MapsおよびGoogle Earthが地図の操作性を大きく変えたほか、オープンソースソフトウェアも台頭した。 2010年代はスマートフォンの普及によりモバイル端末上での地図利用が一般化し、2020年代は機械学習やAIが地図の作成と分析の方法そのものを変えつつある。 細かな3次元の地理情報を必要とする自動運転は、この分野に残る大きな課題として挙げられている。 [UC-009 §地理情報システムの60年の歴史]
GISの学問的な周辺には「地理情報システム（Geographic Information System）」「地理情報科学（Geographic Information Science）」「空間情報科学（Spatial Information Science）」という三つの呼称が並存する。 いずれも略称はGISだが、「サイエンス」という語にはシステム開発にとどまらず学問体系を構築するという含意がある。 さらに、地理情報をより数学的・一般的に記述すれば地球上の場所に限らない数学的な空間を扱う空間情報科学へと拡張される。 もとの地理学に、コンピューターサイエンス・デジタル技術・計算幾何学（computational geometry）を組み合わせることでこれらの分野が生まれた。 [UC-009 §地理情報システムから空間情報科学へ]
GISの特徴的な機能の一つがレイヤーだ。 道路や建物などの情報をレイヤー単位でオンオフして、表示する情報を組み合わせられる。 道路レイヤーをオフにすれば道路が消え、建物レイヤーをオフにすれば建物が消えるという具合で、渋滞や温度のように直接は見えない情報を重ねて表現することも可能だ。 [UC-009 §GISの機能とレイヤー]
GISが扱うデータはラスターデータとベクトルデータに大別され、さらにTIN（Triangulated Irregular Network）といった面表現のデータ構造も用いられる。 これらの詳細は「地理データの形式」を参照。
オープンソースのGISとして広く使われているのがQGISで、レイヤー操作を含むGISの主要機能を無償で利用できる。 [UC-009 §GISの機能とレイヤー]
点・線・ポリゴンのあいだには、交わる（intersects）、接する（touches）、含む（contains）、内側にある（within）、重なる（overlaps）、等しい（equals）といった関係が定義される。 図形に対しては、複数を合わせた和（union）、距離を測る（distance）、交わる部分を取り出す交差（intersection）などの操作も定義されている。 こうした関係の表現と図形操作を提供することがGISの特徴の一つであり、これらの計算幾何処理を担うライブラリの例としてC/C++で書かれたGEOSがある。 [UC-009 §空間的な関係と操作]
代表的な検索操作の一つが、ある領域に含まれるオブジェクトを探す「contains」だ。 たとえば東京都に住んでいる人（点）、東京都を通る道路（線）、東京都内の公園（ポリゴン）を探す処理がこれにあたる。 対象が100万や1000万になるとリニアスキャンでは時間がかかるため、インデックス化のアルゴリズムが必要になる。 最も古典的なものの一つが1984年に提案されたR-tree（R木）で、大きな矩形から順に内側の小さな矩形へとたどることですべてを調べずに検索できるツリー構造だ。 [UC-009 §空間検索を高速化する仕組み]
「ある地点から一定距離以内」を探す「within」もよく使われる操作だ。 いったんその範囲の領域を作り（バッファリング）、その中に含まれるものを探すことで実現する。 距離を一つずつ測るのではなく、領域を拡張してインデックス構造を使うことで高速化でき、Google Mapsのような地理情報サービスもこれらのアルゴリズムで機能を支えている。 [UC-009 §空間検索を高速化する仕組み]
GISはDH研究においても、過去の地理情報を機械可読化・統合化するための基盤として活用されている。 代表例が歴史GIS（Historical GIS）で、古地図を対象として歴史的な地理情報をどのように現代の地図上で活用するかが論じられる。 [UC-011 §1. はじめに]
過去の世界は現代まで残された記録から復元するほかなく、不確かさや曖昧さとの戦いになる。 現代ならセンサーで測ればそのまま構造化データになるのに対し、過去のデータは構造化するだけでも多くの段階を要する点が大きく異なる。 それでも構造化データになれば現代のアルゴリズムで分析できる可能性が開け、こうした研究は情報学だけでは成り立たず、人文学との協働によって新しい知識が得られることが期待されている。 [UC-011 §8. まとめ——不確かさと向き合う歴史GIS]
GISを歴史研究に活用する具体的な事例として、江戸時代を対象とした大規模空間データセットの構築がある。 この取り組みは「歴史ビッグデータ」という枠組みに位置づけられ、歴史的資料に含まれる「何がどこで起こったか」の「どこ」、すなわち位置情報を整備することに焦点を当てる。 [UC-012 §背景：歴史ビッグデータと過去の地理情報の整備]
データセット構築の方法論は、識別子（ID）の付与と基本属性の付与の二つを軸とする。 ID付与では「何を同じエンティティとみなすか」の判断が難しく、ここに多くの労力がかかる。 基本属性の付与では、緯度・経度の位置情報を中心に、名称・粒度・読み・石高などの基本統計を結びつける。 藩ID・江戸近世村・江戸マップ・江戸期地理（街道・海岸線など）という複数階層のデータセットが、こうした方針のもとで整備されている。 [UC-012 §大規模空間データセット構築の方針]
古地図を現代の地理空間に位置づけるには、古地図と現代地図のあいだの幾何学的な対応を求める処理が必要になる。 この処理をジオレファレンスと呼び、その手法の選択と適用は、古地図の精度や用途によって大きく異なる。
ジオレファレンスの基本は、GCP（Ground Control Point、基準点）の設定である。 古地図と現代地図のあいだで、桜田門の位置や堀の屈曲点のように、両方で同定できる地物を対応づけ、その対応から数学的な変換式のパラメータを推定する。 対応点以外の点はすべてその変換式によって写されるため、多くの地点で位置が合う一方、地図が歪められるという問題が生じる。 地図上の文字が読めなくなることも、このアプローチの欠点として挙げられている [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。
江戸切絵図29枚のジオレファレンスでは、日本版Map Warper を用いた。 ただし29枚の後半にあたる図は歪みが大きく、売り物として有名観光地を枠内に収めるために距離も方向も大きく崩されており、幾何補正だけでは位置を推定できなかった。 そこで、ジオレファレンスであたりをつけたうえで、抽出した地名の各マーカーをOpenStreetMapを背景として一点ずつ現代の正しい位置へ手作業で移動させ、最終的に全29枚・8,719件の地名の現代位置を推定した [UC-011 §4. 江戸切絵図を現代地図に重ねる——地名抽出とジオレファレンス]。 同様の作業がデジタル江戸の取り組みでも行われており、約8,000箇所すべてに対して一点一点をOpenStreetMapベースで移動させる手作業が実施されている [UC-012 §江戸マップデータセット]。
幾何補正に対し、インタラクティブ・ジオレファレンシングは一点だけを合わせ、地図全体の形は歪めない方式である。 見たい一点の周辺以外はずれるが、文字が読める状態が保たれ、スマートフォンで自分のいる場所を中心に合わせて確認するような用途に向く [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。
Maplat はこの方式に近いソフトウェアで、古地図やイラストマップ・路線図のように絵として描かれた空間表現を扱う。 位置関係が逆転しないよう同相変換を行い、三角形に分割して線を線に変換することで、もとの線が保たれるようにしている [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。
ディジタル・シルクロード・プロジェクトでは、同様の発想からマッピニング（Map＋Pinning）が開発された。 スタインの地図では経度方向を中心に数十kmに及ぶ誤差が存在し、これは1900年頃の砂漠での測量で時計が狂いやすい環境に起因する。 マッピニングは地点を選ぶと背景地図が動いてそこだけが合い、「この地点は約5.6kmずれている」といった誤差を表示する。 幾何補正で全体を歪めるのではなく、誤差の大きさと方向を一点ごとに示す手段として機能している [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。
古地図の精度は均一ではなく、測量していない絵図から、測量済みでも多少のずれがあるものまで幅がある。 ある程度の精度をもつ測量地図であれば、GCPを用いたジオレファレンスでかなり位置合わせができ、どのピクセルが現代のどこに対応するかが分かる。 一方、歪みの大きい地図を幾何変換すると可読性が大きく下がるため、歪めずに一点だけ合わせるインタラクティブな方法が有効となる。 点データについては、ジオレファレンスはあくまで出発点であり、現代地図との比較や現地調査を重ねて精度を高めていく、と整理されている [UC-011 §8. まとめ——不確かさと向き合う歴史GIS]。
乾隆京城全図（清代の北京の地図）の例では、GCPに加えて線を線に対応づける新しい方法が開発された。 北京の城内が碁盤目状の道であることを利用し、直線が直線として保たれるような数学的変換を適用したものである。 作業の過程では、GCPで合わせようとしても合わない箇所から5枚のシートで配置が入れ替わっていること、さらに1枚の中で左右が逆転しているものが発見された。 「ただつなげればよい」のではなく、正しくつながるかを確認しなければならないことがこの事例の教訓とされている [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。
複数のソフトウェア・サービスが実践で用いられており、それぞれ対象や環境に応じた特徴をもつ。
日本版Map Warper は立命館大学が公開するサービスで、画像をアップロードして対応点を打つと位置合わせができ、OpenStreetMapを土台に多くの人が地図を持ち寄って合わせられる。江戸切絵図のジオレファレンスに使われた [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。
Allmaps はIIIFに対応し、IIIFで公開された地図を取り込んで位置合わせする。 複雑なGISの基盤やXYZ形式のタイル生成を必要とせず、IIIFサーバーさえあれば動くため、ミュージアムやライブラリの環境と相性がよい。 複数ページの紙をつないで一枚の地図にすることもできる [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。
Georeferencer は地図収集家デイビッド・ラムジー氏のコレクションに付随し、ブラウザ上での対応点設定に加えて三次元的な重ね合わせにも対応する [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。
Maplat は前述のとおり同相変換による一点合わせに特化し、絵図・イラストマップ・路線図のような非測量的な空間表現を対象とする [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。
精度の低い地図をどう扱うかについて、トポロジカルマップの考え方が示されている。 距離や方位は正しくなくても、接続関係（どの地点がどれと隣接するか）さえ保たれていれば位置関係として読める、という地下鉄路線図に似た発想である。 グリュンヴェーデルの地図はスタインの地図に比べて不正確だが、調査した遺跡や出土遺物が地図に紐づけて記されており情報として貴重である。 位置や方位を直接信じるのではなく、描かれた道や壁などの位置関係を正しいものとして読み、写真の位置関係も併用しながらもっともらしい解釈を組み立てると、結果的にほとんどの遺跡を同定できたという [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。
江戸切絵図の後半の図も同様に、距離や方向より「この道を行けば観光地に着く」という接続情報を優先して描かれたものと解釈されている [UC-011 §4. 江戸切絵図を現代地図に重ねる——地名抽出とジオレファレンス]。
地誌はテキストとして記述された地理情報であり、それを機械可読化するにはテキストから地名を抽出する処理と、地名を位置座標に変換するジオコーディングの二段階がともに必要になる。以下では、それぞれの段階を担うソフトウェアと、両者をつなぐ実践例を整理する。
テキスト中の地名を自動的に抽出して地名辞書とリンクするソフトウェアとして、GeoNLP が開発されている。GeoNLPはPython版のオープンソースソフトウェア（OSS）で、テキスト中に出現する地名と住所を抽出し、辞書中の対応するエントリとリンクする。住所部分のエンジンにはjageocoderが使われており、地名辞書を拡張すれば適用範囲を広げられる設計になっている [UC-031 §現代の住所を対象とした応用事例]。ただし現状は現代日本語にしか対応しておらず、過去の日本語への対応は今後の課題として挙げられている [UC-013 §地名情報処理のサービス群——GeoNLP・ジオコーダー・GeoLOD]。
抽出した地名を地図上に可視化するには、地名が指すエンティティの同定（曖昧性解消）が必要になる。史料の記述「宇田川丁」が江戸マップの特定のエントリ「宇田川町（ID: 4-358）」だと特定されれば、そのIDから緯度経度を得て地図に配置できる。安政江戸地震史料の被害可視化では、地名にマークアップされた史料をAPI経由で取得し、GeoLOD IDを付与したうえでれきちず上に描画することで、複数史料にまたがる建物・火災被害の分布を集約している [UC-013 §史料と実世界の紐づけ——固有表現認識と被害可視化]。
住所を緯度経度に変換するジオコーダーとして、Python版の jageocoder が利用されている。jageocoderは住所を都道府県・市区町村・町丁・番地・字に分割し、住所データベース（DB）から緯度経度を検索する仕組みで、数字の全角・半角の違いや「1丁目1番地／1-1」といった表記揺れ、異体字への対応を備える [UC-032 §ジオコーディングの基盤となるデータセットとツール]。
現代住所を対象とした応用例として、FIT制度に登録された発電所384,138件の地図化（エレクトリカル・ジャパン）がある。地方の発電所には字レベルの細かい住所が多く、一般的な地図サービスでは検索できないため、可能な限り詳細なレベルまで住所を解析できるようjageocoderを改良して対応した。ただし山の中にある水力発電所など「国有林」としか記されていない住所は正確な位置まで特定できないという限界も残る [UC-031 §現代の住所を対象とした応用事例]。
別の応用例として、『日本歴史地名大系』地名項目データセットの位置推定がある。同文献の地名には平成の大合併以前の住所が記録されており、そのまま現代のジオコーダーに入れても位置が特定できない。大合併以前の住所に対応する現代住所の候補をjageocoderで探してジオコーディングし、推定緯度経度を付与した。この作業を通じて、歴史的な住所の変換もjageocoderで限定的には可能であることが示されているが、自動化できる部分がある一方で手動で対応しなければならない部分も多く残る [UC-031 §現代の住所を対象とした応用事例]。
現代住所向けジオコーダーの住所DBを過去のものに差し替えることで、過去の住所を扱えるようになる。この設計上の鍵となるのが「DBの差し替え可能性」で、jageocoderはこの差し替えを前提として設計されている。ただし住所DBの構築には固有の困難がある。
関東大震災死亡者住所の分布可視化プロジェクト（1923年の住所が対象）では、この困難が具体的に現れた。区画整理が激しく行われて町名が著しく変更されたため、現代の住所表記がほとんど参考にならない。原票の表記にも揺れがあり、「本所区三笠11」に対して正式には「本所區本所三笠町」のように「本所」が付く、「常磐」と「常盤」、「蛎売」と「蛎殻」のような誤字、区の誤記、さらに「横川町」が本所横川町・中ノ郷横川町・柳島横川町のいずれか区別がつかないような一意に決まらない町名も存在した [UC-032 §大正時代の住所をジオコーディングする課題]。
このプロジェクトでは、1907年の東京市15区内の住所56,089件を現在の位置座標に変換する『旧東京市15区住所データセット』をジオコーディングの基盤とした。対象の1923年とは16年の差があるが、ぴったり合うデータセットを探すのは無理であるため概ね適用可能と判断し、変化のある地域は後から考慮する方針をとった。jageocoder用に変換する際には、地名の誤りの修正、区画代表点の自動推定、表記揺れ対応辞書の追加が施されている [UC-032 §ジオコーディングの基盤となるデータセットとツール]。歴史的ジオコーダーとして旧東京市15区住所データセットを活用した取り組みの詳細は「歴史的ジオコーダー」を参照。
テキストから地名を抽出し位置に変換するこの一連の処理を支えるのが、地名エンティティへの識別子付与である。GeoLOD は地名データセットを登録すると GeoLOD ID を付与するウェブサービスで、属性表示・検索・オンラインでの地名辞書構築に対応する。複数のアプリが同じIDを介してデータを参照することで、異なるアプリ間のデータ統合が容易になる [UC-010 §歴史的ジオコーダーとGeoLOD──地名をつなぐ基盤]。GeoLODには江戸マップ・歴史地名データ・『日本歴史地名大系』などのデータセットが登録・統合されており、位置が曖昧な歴史地名にはUberのH3インデックスを用いた六角形単位のIDで曖昧さのレベルを指定できる [UC-013 §地名情報処理のサービス群——GeoNLP・ジオコーダー・GeoLOD]。
論文中の地名すべてに識別子を埋め込めば、ある地名に紐づく論文を横断検索でき同名地名の区別も可能になるという展望が示されており [UC-013 §歴史的空間情報基盤の課題と今後の展望]、テキストとしての地誌を地理空間と接続するための識別子基盤は、地名情報処理の今後の方向性を示すものとして位置づけられている。
過去の住所を緯度経度に変換する「歴史的ジオコーダー」は、現代の日本住所ジオコーダーであるjageocoderの住所データベースを差し替える仕組みを土台にして実現されている。 ROIS-DS CODHの北本朝展氏らが開発したこの拡張は、明治期以降の歴史資料に含まれる大量の住所を一括でジオコーディングし、地図上に可視化することを目的とする。[UC-031 §歴史的ジオコーダーへの拡張と近代東京アドレスジオコーディングデータセットの継承]
jageocoderは現代日本の住所を可能な限り網羅的にカバーする設計だが、歴史的ジオコーダーへの拡張にとって決定的な特性は、住所データベースを目的に合わせて差し替えられる点にある。 この設計により、過去の住所データベースを用意して入れ替えれば、同じエンジンで過去の住所のジオコーディングが可能になる。[UC-031 §jageocoder——現代日本の住所ジオコーダー]
過去の住所データベースを構築するためのツールとして、jageocoder-dbtoolが開発された。 このツールはGeoJSON形式の地図データからjageocoder用の住所データベースを作成するもので、GeoJSONからテキスト形式を経て住所データベースへと変換する。 住所の表記揺れや異表記は個別にテキスト形式で作成し、変換時に統合でき、辞書を使う優先順位も設定できる。[UC-031 §旧東京市15区住所データセットの構築]
歴史的ジオコーダーの最初の実装として構築されたのが、旧東京市15区住所データセットである。 出発点は、石川和樹氏・中山大地氏（東京都立大学）による『近代東京アドレスジオコーディングデータセット』で、1907年（明治40年）に東京郵便局が作成した「東京市十五區番地界入地圖」を基にした地番データから成る。[UC-031 §歴史的ジオコーダーへの拡張と近代東京アドレスジオコーディングデータセットの継承]
既存システムには、担当者異動による維持困難、利用者側での独自表記揺れルール追加の困難、ウェブ経由の変換しか提供されておらず数万件規模の一括変換に向かないこと、という課題があった。 中山大地氏から利用許諾を得てシェープファイル形式の元データを取得し、jageocoder向けに新たなデータセットとして再構築した。[UC-031 §歴史的ジオコーダーへの拡張と近代東京アドレスジオコーディングデータセットの継承]
構築作業は大きく三段階に分かれる。 まず地理データについては、シェープファイルをGeoJSON形式に変換し、住所などの誤りを修正したうえで区画の代表点を独自に推定した。 次に住所データについては、GeoJSONの属性に含まれる住所文字列をjageocoder-dbtoolを用いてjageocoderの住所辞書形式に変換した。 さらに実際のデータ（関東大震災死亡者データ）を用いて典型的な表記揺れや異表記を収集し、辞書を強化した。[UC-031 §旧東京市15区住所データセットの構築]
構築作業で最も手間がかかったのが表記揺れと異体字への対応である。 表記揺れ・異表記辞書は、現実に出てくる住所を住所データベース中のエントリにマッピングするための対応を一件ずつ記述したものだ。 たとえば「東京府東京市小石川區大塚辻町」を「東京府東京市小石川區小石川大塚辻町」として扱うよう指定する。 典型的なパターンは、区と町名の間に入る地域名の省略で、小石川区の小日向・小石川・関口のように共通の接頭辞を持つ町名群はしばしば日常の会話では省略されて記録される。[UC-031 §表記揺れ・異表記辞書]
異体字については、jageocoderが標準で地名異体字辞書を持っており、頻出する異体字はそこに登録する。 利用例が多くない異体字は表記揺れ・異表記辞書内で個別に処理する。 異体字のうちUnicodeとして適当でない書き間違いに近い文字は、辞書への登録ではなく住所データ側の修正で対応する。 辞書を拡張するか元データを修正するかは、どれだけ例外的かという観点から判断する微妙なバランスの上に成り立っている。[UC-031 §異体字への対応]
こうして公開された旧東京市15区住所データセットは住所56,089件を収録し、CC BYライセンスのオープンデータとして提供されている。 辞書データはjageocoderにインストールして利用でき、GeoJSONデータは表記揺れを修正し区画代表点を推定したものが含まれる。 旧東京市15区住所マップでは地図上部のボックスに住所を入力するとジオコーディング結果を代表点とポリゴンで表示でき、たとえば「鹿鳴館」の住所が東京府東京市麹町区内山下町であったことを地図上で確認できる。[UC-031 §公開したデータセットとマップ]
歴史的ジオコーダーの具体的な活用事例として、関東大震災の死亡者住所の大量変換と空間分布の可視化がある。 東京大学地震研究所の大邑潤三氏は、東京都慰霊協会が所蔵する「震災死亡者調査表」のテキストデータ3万8,332名分を素材に、旧東京市15区住所データセットとjageocoderの組み合わせでジオコーディングを実施した。[UC-032 §はじめに]
対象は1923年（大正12年）当時の住所であり、震災後の区画整理で町名が著しく変更されたため現代の住所表記はほとんど参考にならない。 加えて、原票が手書きであることに由来する「本所区三笠11」（正式には「本所區本所三笠町」）のような省略、「常磐」と「常盤」のような誤字・入力ミス、区の誤記（浅草区佐賀町と記録されているが実際は深川区）、横川町が本所横川町・中ノ郷横川町・柳島横川町のいずれか一意に決まらない町名、といった多様な表記問題が変換の難しさを生んでいた。[UC-032 §大正時代の住所をジオコーディングする課題]
使用したデータセットは1907年時点のもので、対象の1923年とは16年の差がある。 ぴったり合うデータセットを探すのは無理であるため概ね適用可能と判断し、変化のある地域は後から考慮することにして作業を進めた。[UC-032 §ジオコーディングの基盤となるデータセットとツール]
変換作業は、変換率のレベルを見ながら四つのステップで住所データを修正していく形で進められた。[UC-032 §住所データ修正のワークフロー]
STEP 1ではそのまま変換を試みて表記揺れのパターンを収集しjageocoderの辞書に登録した。 この対応で全体の約84％が地番レベル（レベル7）で変換可能になった。 STEP 2では「横川町」のような一意に決まらない町名を文脈から判断して同定した。 STEP 3では手書き原票やデジタル翻刻に由来する誤字・入力ミスを手作業で修正した。 「堅→竪」「霊厳→霊巌」のようなくずし字の誤読を含む多様な誤りへの対処で約1,000件がレベル7に向上し、レベル7は全体の86％となった。 STEP 4では残りを1件ずつ確認し、地図上に存在しない地番については近接する番地に代表させるなどの処理を行い、最終的にレベル7は全体の87％（3万3,467件）に達した。[UC-032 §住所データ修正のワークフロー]
なお変換できなかった住所には、15区外の郡部（北豊島郡・南葛飾郡など）や他府県、未記載分が含まれており、これらは対象データセットの範囲外で別途の対応が必要とされている。 また、1907年基準のデータセットに含まれない大正2年成立の芝区日出町のように、16年の差からこぼれる地名も存在する。[UC-032 §変換の限界と今後の課題]
変換した住所を100メートル四方のメッシュで集計した結果、本所区・深川区を中心とする被害の偏りが明らかになった。 本所区ではほぼ全域で居住者の死亡が発生し、南西部に最大の集中が見られた。 一方、区別の死亡率（死亡者数÷大正9年国勢調査人口）は本所区が10.7％で突出しているのに対し、同等以上の人口密度であった浅草区は0.9％にとどまる。 人口密度の高さは死亡率が高くなる背景ではあるものの直接の原因ではなく、地域・場所ごとの別の要因が人的被害に作用したと考えられる。[UC-032 §死亡場所・人口密度からみた本所区・深川区の特殊性]
最も面的に広い被害集中地域は本所区南西部の被服廠跡周辺で、分布は扇形に広がりその要に被服廠跡が位置する。 被服廠跡から約1キロメートル圏で被害が大きく、周辺住民が広大な空き地を目指して逃げ込み大規模火災に見舞われたことを示唆する分布だ。 被服廠跡での避難民の大量死は従来から知られているが、死亡した避難民の居住範囲が地図上で可視化された点に意義がある。[UC-032 §被害が集中した地域とその要因]
被服廠跡から約1キロメートル圏内でも被害が相対的に小さい場所があり、大邑氏はそれが橋と対応しているのではないかという仮説を示している。 新大橋・両国橋の東詰付近では周囲に比べて住民の死亡が少なく、近くにある橋を渡って避難し被服廠跡に逃げ込むことなく大規模火災を免れた住民がいた可能性がある。[UC-032 §橋梁付近の被害軽減]
旧東京市15区の事例から、歴史的ジオコーダーを作成する手順は次のように整理される。 まず古地図に記された住所のポイントやポリゴンをGIS上でトレースしてGeoJSON形式のデータを作成する。 測量が正確でない時代の地図ではその前に古地図のジオレファレンスが必要で、特に地図の歪み方への対応が難しくなる（ジオレファレンスの詳細は「古地図の処理」を参照）。 基礎データができたら、実際の住所データを対象に表記揺れや異体字・異表記の辞書追加を行いながら精度を高め、この精度向上のループが限界を迎えたところで完成となる。[UC-031 §歴史的ジオコーダーの作成手順と今後の展開]
北本氏は、同じ手順は他の都市・時代にも適用でき、必要なのは特別な技術というより労力だと見ている。 いったん作成すれば歴史資料を大量に一括処理できるため一件ずつ処理する場合に比べて作業効率は大幅に向上し、表記揺れなど現実データのクリーニング方法を共有化することで担当者による見落としやばらつきも減ると見込まれている。[UC-031 §歴史的ジオコーダーの作成手順と今後の展開]
UC-010では、歴史的ジオコーダーがCODHの地名情報処理サービス群の一つとして位置づけられ、1923年の関東大震災の罹災者地図の可視化などに活用されていることが紹介されている。 GeoNLPは現状では現代日本語にしか対応しておらず、過去の日本語への対応が今後の課題とされていることも付記されている。[UC-013 §地名情報処理のサービス群——GeoNLP・ジオコーダー・GeoLOD]
写真は景観の断片を切り取る視覚資料であると同時に、地理座標を通じて実世界と結びつく空間資料でもある。この二重性を活かして「過去の場所」を再現・解釈するとき、位置合わせの手法と市民参加型の撮影実践が相互補完的に機能する。
写真が都市景観の記録として有効に機能するためには、それがどこで撮られたかが特定されなければならない。North China Railwayが1937年から1945年にかけて撮影した3万5千点を超えるストックフォトのアーカイブでは、写真にAIタグ（GPT-4oによる）が付与され、「cityscape」などのタグで過去の都市景観を検索できる [UC-016 §North China Railwayの写真アーカイブとAIタグによる検索]。しかしKitamoto氏はこのアーカイブの限界として、写真の対応づけが元資料のメタデータに基づく「駅」単位にとどまり、住所のような地点レベルには達していないことを指摘する。写真は都市の一部を切り取るにすぎず、連続的な街並みの記録ではないため、過去の景観を再現する用途には十分でないと評価されている [UC-016 §North China Railwayの写真アーカイブとAIタグによる検索]。
地点レベルの対応づけを実現した事例が、北京を対象とした共時的写真（synchronic photographs）の試みである。古地図として『乾隆京城全図』（Qianlong Map、幅13メートル・高さ14メートル、全203枚、290億画素）をジオレファレンスで北京城壁内全域にマッピングし、その地図を手がかりとして1900年頃刊行の写真アルバムの撮影地点を特定した [UC-016 §地図と組み合わせた過去の景観の再現]。写真に写る複数の対象物（点A、点B）を地図上の対応点に一つずつ合わせることで、一見すると建物に見えるものが実際には通りの上に建てられた仮設構造物であることが判明した例がある。空間情報がなければ困難なこの種の判別が、地図との照合によって迅速に可能になる [UC-016 §地図と組み合わせた過去の景観の再現]。
景観の時間的変化を捉えるには、同じ場所・同じ構図で撮影された複数時点の写真が必要になる。この通時的写真（diachronic photographs）の取得を支援するのが、iOSおよびAndroid向けのカメラアプリ メモリーグラフ（メモグラ）である。カメラのファインダーに古写真を半透明で重ね、現在の景観と一致させながら撮影することで、古写真と現在の景観を対応づける [UC-016 §Memorygraphアプリによる景観の変化の把握]。一般のカメラでも比較は可能だが、古写真を記憶し頭の中で照合する必要があり容易ではない。ファインダー上で直接重ね合わせられるメモリーグラフでは、この認知的負荷が大幅に軽減される [UC-016 §Memorygraphアプリによる景観の変化の把握]。
メモリーグラフの仕組みと機能の詳細については「メモリーグラフの仕組み」を参照。
この撮影を市民参加型で行うと、集まった撮影地点報告の平均から古写真の撮影地点を統計的に特定できる。さらに、現在と過去の写真を比較することで、現在の建物の特定部分に過去の形が保存されている可能性を推測できる場合がある [UC-016 §Memorygraphアプリによる景観の変化の把握]。京都では「スマホで三条 まちなみの変遷発見ラリー」のような市民による活動として写真が活用されており、こうした取り組みはパブリックヒューマニティーズと位置づけられている [UC-016 §景観を「読む」ための新しい技術]。
メモリーグラフを用いた活動の具体的なユースケース（京都での景観学習実践、シルクロードでの遺跡同定など）は、それぞれ専用の節に詳しく記載されている。
IIIFは画像の相互運用を目的として世界各国のミュージアム・ライブラリで採用されている標準だが [UC-001 §IIIF画像の閲覧]、IIIFの一般的な機能については本節では扱わない（「テキストとしての地誌」など関連節を参照）。本節では地理情報との接点に絞って整理する。
江戸切絵図の事例では、IIIFで公開された画像に対してCODHが開発したIIIF Curation Viewerを用い、地図上の各地点にマーカーを立てて地名を翻刻するという方法が採られた [UC-011 §地名の抽出とIIIFによる注釈]。これはIIIFによって提供された画像にアノテーションを付与する実践であり、IIIFが地図資料への地理的注釈付けの基盤として機能している例と見られる。
一方、東洋文庫所蔵の『大明地理之図』では、IIIF Curation Viewer上でアノテーションを作成し、「IIIF Curation Map Search」と呼ばれるツールで地名を検索・表示できる仕組みが構築された。大きな一枚画像に大量の地理的アノテーションを付与する用途であれば、IIIF Curation APIに対応したデータとして同様の構成を再利用できるとされる [UC-003 §東洋文庫『大明地理之図』]。
IIIFのnavPlace拡張は、マニフェストやキャンバスに地理座標（GeoJSON-LD）を直接埋め込み、地図上での資料の発見・ナビゲーションを可能にすることを意図している。ただし、上記の事例（IIIF Curation Viewer・Map Searchによる実践）はnavPlaceを明示的に用いたものとして記述されているわけではなく、navPlaceが実際にどのDHプロジェクトでどの程度採用・評価されているかは、現在紐づいている記事からは確認できない。
写真を空間的な文脈の中で解釈するという営みは、Kitamoto氏が「digitally-enabled criticism」と呼ぶ活動として位置づけられる。景観を「読む」とは、変化し続ける景観の中に不変なもの（invariance）を見出すことであり、同一構図写真を画素レベルで比較することで人が気づかない微細な変化が明らかになる場合がある [UC-016 §景観を「読む」ための新しい技術]。この解釈力はその場所への知識に依存し、場所をよく知っていれば撮影地点の判断が容易になるが、知らなければ理解に時間がかかる [UC-016 §景観を「読む」ための新しい技術]。
何が保存され何が変化したかという問いへの接近には、社会学や建築学の確立した理論が必ずしも前提とされているわけではない。Kitamoto氏は、このプロジェクトは都市景観全体を対象としており、個々の建物の保存を扱う建築とは異なる観点だと述べている [UC-016 §景観を「読む」ための新しい技術]。
地名をデジタル研究に活用するには、地名そのものを収録したデータセットが土台となる。 日本の歴史地名については、複数の組織が異なる情報源・粒度・ライセンス戦略のもとでデータセットを構築しており、その性格はそれぞれ大きく異なる。
歴史地名データセットの中心的な存在が、平凡社『日本歴史地名大系』（全50巻、1979〜2004年刊行）を基にCODHが作成した『日本歴史地名大系』地名項目データセットである。 江戸時代の村まで遡る80,502件の地名データを収録し、各地名に緯度経度をCODHが独自に付与したうえでCC BYライセンスでオープン公開している [UC-013 §『日本歴史地名大系』地名項目データセットとオープン・クローズ戦略]。
ここで採られているのがオープン・クローズ戦略である。 ID・地名・読み・位置情報は「書き手に依存しない事実情報」としてオープン化し、地名の詳細な記述は「書き手に依存する解釈情報」として購読制のジャパンナレッジに残す構成をとる [UC-013 §『日本歴史地名大系』地名項目データセットとオープン・クローズ戦略]。 地名ページからその記述へリンクが張られており、オープンデータからクローズドデータへたどれる構造になっている [UC-012 §江戸近世村データセット]。 現在は失われ現地を歩いても見つからない地名も収録されており、史料の解釈に不可欠な層を補っている点に意義がある [UC-010 §地名・村のデータセット]。
村単位の地理的範囲を表すデータセットとして、本田謙一氏が作成した幕末期近世村領域データセットがある。 幕末期の近世村66,581件を収録し、各村には点データとポリゴンデータの両形式が提供されている [UC-012 §江戸近世村データセット]。 ポリゴンの境界は現代の農業集落境界データに由来するため当時そのものではないが、当時の集落境界を近似的に表すと考えられている [UC-012 §江戸近世村データセット]。 各村には石高が結びつけられており、これは国立歴史民俗博物館が公開する旧高旧領取調帳データベースに基づく——石高は徴収できる年貢の量、すなわち各村の経済力を表す [UC-010 §地名・村のデータセット]。
この二つを名称の一致で突き合わせ統合したのが江戸近世村統合データセットで、約56,000件が統合されている [UC-012 §江戸近世村データセット]。 ただし統合には限界もある。一方では一村として記録されているものが他方では東西に分かれて粒度が異なる場合や、表記の違いで対応づけられない場合など、統合できない例が存在する。 粒度の相違・表記揺れ・どちらを正解とするかという問題は歴史データに広く見られ、丁寧に対処するにはかなりの時間がかかると見込まれている [UC-012 §江戸近世村データセット]。
村や地名の点データ・ポリゴンデータに加え、江戸期の地理空間そのものを表すデータセット群も整備されている。 江戸末期海岸線／水域データセット・江戸主要街道データセット・「江戸切絵図」町家領域マップの三種が代表で、いずれもGeoJSON形式のオープンデータとして複数の資料を参照しながら人手で構築されている [UC-012 §江戸期地理データセット]。 海岸線データは明治以降に埋め立てられた部分を示し、町家領域マップは人が多く住んだ町方の領域を色で可視化することで居住域の把握を可能にする [UC-013 §江戸の地理空間データと街道・宿場のID化]。
こうした線・点のデータにもIDを付与する取り組みが進められている。 高速道路ナンバリング（道＝line）と駅ナンバリング（駅＝point）の発想を援用し、五街道にR001〜R005、地域の主要街道にR1XX〜R9XXを与える街道ナンバリングと、東海道最初の品川宿をR001-001とする宿場ナンバリングが構想されている [UC-013 §江戸の地理空間データと街道・宿場のID化]。 人や物資の移動経路を「あるIDから別のIDへ」というID間のリンクで表現できれば、構造化の効率化に寄与するためである [UC-012 §江戸期地理データセット]。 ただし街道には時期による移設や経路の違いがあり、質疑では「IDを与えつつ説や時期に応じて複数の経路を割り当てられる柔軟な枠組みが望ましい」という指摘がなされた。 公式の定義がなく呼称や経路がぶれる場合が多いため、できるだけ柔軟に対応したい意図が示されている [UC-012 §江戸期地理データセット]。
現代の住所を扱う文脈でも、地名データセットの複層性は明確に現れる。 jageocoder（相良毅氏開発）が参照する住所データベースは、CODHの歴史的行政区域データセットβ版地名辞書・国土交通省の位置参照情報（大字町丁目レベル・街区レベル）・Geoloniaの住所データ・国土地理院の電子国土基本図（地名情報）・日本郵便の郵便番号データ・デジタル庁のアドレス・ベース・レジストリ・法務省の登記所備付地図データなど、複数の省庁・機関のデータから構成されている [UC-031 §jageocoder——現代日本の住所ジオコーダー]。 これだけ多くの機関がそれぞれの目的でデータを作っているために全体は複雑で、これらを扱うだけでも大きな労力がかかると指摘されている [UC-031 §jageocoder——現代日本の住所ジオコーダー]。 jageocoderが定義する住所は都道府県から住居番号・枝番まで8階層に分かれ、各層の地名がつながって住所を構成する構造をとる [UC-031 §jageocoder——現代日本の住所ジオコーダー]。
歴史的ジオコーダーへの応用や、GeoLODによる地名の識別子付与サービスについては、それぞれ「歴史的ジオコーダー」および「地名サービス」を参照。
地名に識別子を付与する仕組みは、史料中の記述と地図上の位置とを結びつけるための基盤となる。GeoLODはその中心的なサービスであり、日本の歴史地理情報整備において独自の位置を占める。
GeoLODは、地名データセットを登録すると地名ID（GeoLOD ID）を付与するウェブサービスである。[UC-013 §地名情報処理のサービス群——GeoNLP・ジオコーダー・GeoLOD] 属性の表示や検索、オンラインでの地名辞書構築に対応し、多数の地名をアップロードしてGeoLOD IDを割り当てることで、さまざまなアプリケーションからその識別子を利用できる。同じIDを介して異なるアプリ間のデータ統合も容易になるという点が、このサービスの中心的な意義である。[UC-010 §歴史的ジオコーダーとGeoLOD──地名をつなぐ基盤]
GeoLODには江戸マップ、歴史地名データ、『日本歴史地名大系』などのデータセットが登録・統合されている。[UC-013 §地名情報処理のサービス群——GeoNLP・ジオコーダー・GeoLOD]
識別子が「名前」としての機能を果たすとき地名は情報空間（ガゼッティア）へ、「座標」としての機能を果たすとき地理空間（地図）へとつながる。GeoLOD IDはこの接続点となる実体に付与されるものであり、史料中の記述と地図上の位置とを相互に結びつける構図の中で位置づけられる（この三空間モデルの詳細は「地図・地誌・地名という概念の関係」を参照）。[UC-010 §情報・地理・つなぐ──三つの空間のモデル]
歴史地名の特徴のひとつは、おおよその位置しか分からないことが多い点である。GeoLODはこれに対応するため、UberのH3インデックスを用いて六角形に対してIDを付与する機能を備えている。ID自体で曖昧さのレベルを指定できるため、正確な座標に帰着させることが困難な歴史地名を扱う際に有用とされている。[UC-013 §地名情報処理のサービス群——GeoNLP・ジオコーダー・GeoLOD]
地名（点・ポリゴン）にとどまらず、移動経路としての街道や宿場にIDを付与する試みも進められている。高速道路ナンバリング（線）や駅ナンバリング（点）に倣い、五街道にR001〜R005、地域の主要街道にR1XX〜R9XXを割り当て、宿場にはたとえば東海道最初の品川宿をR001-001とするナンバリングが行われている。人々や物資の移動経路をID間のリンクで表現できれば構造化の効率化に寄与するという考えに基づく。[UC-013 §江戸の地理空間データと街道・宿場のID化]
IIIFとは何か？IIIFの基本的な定義や、APIの種類などを述べる。
IIIF（International Image Interoperability Framework）は、ウェブ上で高品質なデジタルオブジェクトを大規模に配信・共有するためのオープン標準の集合体である。 1 様々なサイトがHTMLで提供するページを同じブラウザで閲覧できるのと同様に、様々なサイトがIIIFで提供する画像をどのサービスでも同じビューアで閲覧できる。 この相互運用性（インターオペラビリティ）を画像の世界で実現したことが、IIIFが注目される理由だと説明されている [UC-001 §IIIF Curation Platformとは何か]。
デジタルアーカイブを情報学的に利活用するための枠組みにおいて、IIIFは画像分野の規格・技術として位置づけられる。 メタデータにおけるLOD/RDF、テキストにおけるTEIと並んで、IIIFは提供者と利用者をつなぐ情報学的な標準の一翼を担っている [UC-003 §デジタルアーカイブの情報学的利活用と IIIF Curation Platform]。
IIIFが世界中で急速に普及した背景には、ミュージアムやライブラリといった画像提供者の共通のニーズに応えたことがある。 共通形式でデータを公開して相互運用性を担保することで、同じツールで世界中の画像にアクセスできるようになった。 各種ツールがIIIFを前提とするにつれて、IIIFに対応していないアーカイブが逆に「不便」とみなされる時代が近づいており、Fear of missing out（取り残される恐怖）が現実のものになりつつあると語られている [UC-001 §IIIFの相互運用性とICPの独自性]。
IIIFはAPIの集合体として設計されており、目的ごとに役割が分かれている。
Image APIは、画像をHTTP/HTTPSリクエストへの応答として返すウェブサービスの仕様を定める。 URIの中に領域（region）・サイズ・回転・品質・フォーマットを指定でき、画像の切り出しや縮小といった操作をサーバ側で処理して返すことができる。 文化遺産機関が維持するデジタル画像リポジトリでの体系的な再利用を促進するために設計された。 1
Presentation APIは、複合的なデジタルオブジェクトをユーザが豊かなオンライン環境で閲覧できるようにするための情報を提供する。 Image APIと組み合わせて使われることが多く、デジタル化された画像・映像・音声などのコンテンツを表示し、複数のビューや時間的範囲をシーケンシャルまたは階層的にナビゲートし、文脈を与える説明情報を示すといった実装を可能にする。 ハーベスティングや検索エンジンによるインデックス構築のためのメタデータ提供は意図的にスコープ外とされており、あくまで人間が読むための表示に特化している。 2
これらのAPIへの対応により、IIIF形式で公開された画像は、異なる機関が提供するものであっても同一のビューアやツールで扱える。 この相互運用性を基盤として、IIIFのポテンシャルをさらに引き出す利用者向けの機能拡張がIIIF Curation Platformとして開発されている。詳細は「IIIF Curation Platformの基本」を参照。
[1] Image API 3.0 — IIIF | International Image Interoperability Framework. https://iiif.io/api/image/3.0/, 取得日 2026-08-07 [2] Presentation API 3.0 — IIIF | International Image Interoperability Framework. https://iiif.io/api/presentation/3.0/, 取得日 2026-08-07
IIIF Curation Platform（ICP）は、IIIFの画像を利用者の視点から自由に収集・加工・公開するためのオープンソースソフトウェア群である。 IIIFが画像提供者の共通ニーズに応える仕様として普及したのに対し、ICPはその上に「利用者側の視点」を重ねる場として開発された。[UC-001 §IIIFの相互運用性とICPの独自性]
ICPの中心概念はキュレーションである。 もともとミュージアムで資料の収集や展示を指す言葉であり、情報的にはあるテーマに沿ってコンテンツを集め、適切な順番に並べ、新たなコンテンツとして提示・共有する活動を指す。[UC-001 §IIIF Curation Platformとは何か]
IIIFはもともと、様々なサイトが公開する画像を同じビューアで閲覧できるという相互運用性を実現した仕様である（IIIFの仕様・API体系の詳細は「IIIFとは？」を参照）。 ICPはその相互運用性を前提としつつ、公式のIIIF仕様が提供者側の視点であるのに対し、利用者が独自に画像を収集・処理・公開できるワークフロー全体を支援する基盤として設計されている。[UC-001 §キュレーションプラットフォームとキュレーションAPIの区別]
ICPは単一のアプリケーションではなく、ウェブブラウザ上で動作するソフトウェア7点、特定目的のアプリ1点、サーバ側で動作するPythonプログラム3点、導入を支援するDocker設定1点の、合わせて12点ほどのオープンソースで構成される。[UC-001 §IIIF Curation Platformとは何か] MiradorやUniversal Viewerといった著名なIIIFビューアと競合するのではなく、IIIFのポテンシャルを引き出すことに集中する場として開発されているという位置づけが強調されている。[UC-001 §IIIF Curation Platformとは何か]
各ツールの役割は大きく「閲覧」「キュレーション作成・管理」「データ保存・検索」「展示・エクスポート」に分けられる。
閲覧の中心はIIIF Curation Viewerで、書籍閲覧を典型用途とし、viewingDirectionの違いを吸収するため和書と洋書のどちらも同一ビューアで閲覧できる。[UC-001 §IIIF画像の閲覧] ウェブページ内で他の情報と組み合わせて使う用途には埋め込み型IIIF Curation Viewerが用意されており、メタデータを外側に配置したり複数画像を切り替えたりする独自機能と組み合わせて使われる。[UC-001 §IIIF画像の閲覧]
キュレーションの作成は、IIIF Curation Viewer上の「切り取り」ボタンで矩形領域を指定し「お気に入り」に追加するだけで行える。 この操作で集まった画像はCuration Listとして蓄積され、他のビューアにはないICPの独自機能となっている。[UC-001 §IIIF画像のキュレーション] 作成したキュレーションの管理と編集にはIIIF Curation ManagerとIIIF Curation Editorが対応する。前者はログイン状態でエクスポートしたキュレーションの一覧・削除に、後者はCuration形式のJSONデータを見ながらのメタデータ追加・変更に使うが、大規模な編集作業には向かないとされる。[UC-001 §IIIF画像のキュレーション]
展示にはIIIF Curation Playerを用い、メタデータを画像に重ねて表示したりスライドショーで自動再生したりできる。[UC-001 §IIIF画像のキュレーション]
データ保存と検索を担うのがJSONkeeperとCanvas Indexerである。JSONkeeperはJSON形式のデータを保存・提供するサービス、Canvas IndexerはJSONkeeperのデータをクロールしてキャンバス単位に分解し検索可能とするサービスで、ビューアやファインダーの背後にあるデータベース的な役割を果たす。[UC-001 §ICPの高度な利用] Canvas Indexerに機械学習によるタグ付けサービスを連携させ、顔にタグを付けて検索するといった利用も可能である。[UC-001 §ICPの高度な利用] キュレーションに利用されている領域をキャンバス単位・マニフェスト単位で可視化するCuration Tracerもあり、画像のどこに注目が集まっているかを分析できる。[UC-001 §ICPの高度な利用]
ICPを理解するうえで重要なのが、ソフトウェア群であるキュレーションプラットフォームと、仕様であるCuration APIを区別することだと北本朝展氏は述べる。[UC-001 §キュレーションプラットフォームとキュレーションAPIの区別] Curation APIはデータのフォーマットと提供方法を定めた仕様であり、ICPはその一実装にすぎない。キュレーションを行うためにICPを必ず使う必要はなく、APIに対応していれば他のソフトウェアからも利用できる。[UC-001 §キュレーションプラットフォームとキュレーションAPIの区別]
ICPが独自に拡張するAPIは3種類ある。キュレーションを作る仕組みであるCuration API、時間を単位として一次元的に順序を定義できる資料の閲覧に使うTimeline API、長大なキャンバスリストの一部を切り出して提供するCursor APIである。Timeline APIとCursor APIは時系列画像の閲覧にのみ使われており、独自拡張に対応したビューアでしか表示できない。[UC-001 §キュレーションプラットフォームとキュレーションAPIの区別]
この区別は実践的な意義も持つ。東京大学史料編纂所の中村覚氏は、ICPの開発元とは別組織にいる一利用者の立場から、複数のデジタルアーカイブ構築においてCuration APIをデータ管理の形式として採用している。[UC-003 §まとめ：相互運用性と管理の容易さ] 複数マニフェストから切り出した画像領域をメタデータとともに管理する要件に対して、キュレーションリスト1ファイルのみで対応できる点が管理の容易さとして評価されており、長期保存にもつながる利点とされている。[UC-003 §まとめ：相互運用性と管理の容易さ]
ICPのもう一つの特徴が、ビューア内で選択した画像領域を外部サービスに送り外部で処理させるエクスポート機能である。 矩形で囲んだ領域を表すURL（IIIFの画像URI）を外部サービスに送信できる仕組みで、画像を入力として処理結果を返すタイプのサービスであれば、データの渡し方さえ決めれば連携できる。[UC-001 §IIIF画像のエクスポート] エクスポート先の変更はエンドポイント設定（JSONファイル）のドラッグ＆ドロップで行える設計になっており、ICPサービスリポジトリでは5種類のエンドポイント設定が公開されている。[UC-001 §IIIF画像のエクスポート]
また、IIIF Curation Viewerのログイン機能（Google社のFirebase認証を使用）はオプションだが、ログインすることでデータの権限管理が有効になり、JSONkeeperへのエクスポート時に他者による上書きを防ぐことができる。くずし字認識など連携サービスの一部はログインを要求するが、これはデータ管理のためであり有料化のためではないと明示されている。[UC-001 §キュレーションプラットフォームとキュレーションAPIの区別]
個別ツールを実際のプロジェクトでどのように組み合わせて使うかについては、「IIIF Curation Platformを用いたユースケース」を参照。
IIIF Curation Platform（ICP）は、デジタルアーカイブの横断的な活用を可能にする環境として、研究・展示の両面で実践的なサービスに結びついている。ICPの概要やツール構成については「IIIF Curation Platformの基本」を参照。ここでは、ICPを用いて構築・運用されているサービスの具体的な事例を紹介する。
「Cultural Japan」は、世界中の機関が公開する日本文化に関するデータを収集して検索可能にするプロジェクトで、100万件におよぶデジタル資料を扱う [UC-003 §Cultural Japan とセルフミュージアム]。収集したデータを視覚化・活用するアプリの一つに「セルフミュージアム」があり、3次元空間に集めた画像を配置できる [UC-003 §Cultural Japan とセルフミュージアム]。
セルフミュージアムは、IIIF Curation APIに対応したキュレーションリストの読み込みをサポートしており、IIIF Curation Viewerで作成したデータをそのままビューアに読み込ませるだけで、プログラムの知識を問わず利用できる [UC-003 §Cultural Japan とセルフミュージアム]。2020年11月の東京大学総合図書館リニューアルに合わせて構築された「総合図書館バーチャルミュージアム」では、所蔵資料や『百鬼夜行図』から切り出した妖怪の画像をセルフミュージアム上に表示し、各画像のインフォメーションマークから元の絵巻物の該当箇所を参照できる動線を設けている [UC-003 §Cultural Japan とセルフミュージアム]。
また、Cultural Japanの検索システムには、IIIFに対応したアイテムの閲覧ビューアとしてCuration Viewerとくずし字認識ビューアが組み込まれており、検索で見つかった画像からワンクリックでくずし字認識ビューアへ遷移できる [UC-003 §Cultural Japan とセルフミュージアム]。
複数の資料（マニフェスト）からそれぞれ切り出した画像領域をメタデータとともに管理するという要件に対して、ICPではIIIFキュレーションリストの1ファイルのみで対応できる [UC-003 §まとめ：相互運用性と管理の容易さ]。検索・比較などのアプリケーション開発はICP提供のツールに任せられるため、独自に開発すべき範囲をデータ作成に絞り込める点が、実践的なサービス構築の利点として挙げられている [UC-003 §まとめ：相互運用性と管理の容易さ]。データ管理の単純さは長期保存のしやすさにもつながるとされる [UC-003 §まとめ：相互運用性と管理の容易さ]。
メモリーグラフを用いた地誌の分析を取り上げる
メモリーグラフ（略称：メモグラ）は、カメラのファインダー上に基準となる古写真などのガイド画像を半透明で重ねて表示し、同じ地点・同じ構図の写真を撮影できるよう支援するカメラアプリである。 iOS版とAndroid版が無料で公開されている。[UC-004 §メモリーグラフとは：同一構図撮影を支援するカメラアプリ]
アプリの基本的な操作は、ファインダー上に表示されたガイド画像と現実の風景を重ね合わせながら、同一構図になる位置・角度を撮影者自身が探索し、シャッターを切るというものである。 撮影された2枚の写真を重ねて比較すると、景観の細かな変化まで発見できる。[UC-004 §メモリーグラフとは：同一構図撮影を支援するカメラアプリ]
この仕組みが解決しようとしたのは、手動による今昔写真撮影が人間にとって認知的に高負荷な作業だという問題である。 古写真を記憶に保持したまま、ファインダー越しの像と比較し、自分が移動することで3次元のずれを修正していくメンタルローテーション（心的な3次元回転）は、人間にとって得意でない処理とされる。 スマートフォンのカメラ画面にガイド画像を直接重ねることで、この負荷を大幅に減らすという着想が開発の起点にあった。[UC-004 §開発の背景：手動による今昔写真撮影の困難]
同一構図撮影の目的は、ファインダー上に何を表示するかによって変わる。 今昔写真（古写真と現在の景観の比較）・ビフォーアフター写真（災害等の非連続的変化の前後）・定点観測写真（植物の成長や工事進捗など緩やかな変化のタイムラプス的記録）・聖地巡礼写真（作品で描かれたシーンと現実の景観の照合）・位置証明写真（現場訪問の証拠）・撮影シミュレーション（写真家の撮影意図の分析）の6種類が報告されており、ガイド画像を入れ替えるだけで同一アプリがこれらすべてに対応する。[UC-004 §同一構図撮影の6つの種類]
メモリーグラフは「拡張ファインダー」として設計されており、拡張現実（AR）とは設計思想が異なる。 ARでは過去の写真がカメラの向こう側の座標に固定されていてカメラを動かすと写真の見え方が変化するのに対し、メモリーグラフではカメラを動かしてもファインダー上のガイド画像は変化しない。 座標系の一致を撮影者が能動的に探索する「参加」のためのツールとして位置づけられている。[UC-004 §拡張ファインダーとしての設計：ARや写真再撮影との比較]
紙焼き写真を手に持って同一場所で再撮影する方法と比べると、メモリーグラフでは2枚の画像をそれぞれ独立したデータとして扱えるため、紙焼きを重ねた場合に隠れてしまう景観も別途記録できる。[UC-004 §拡張ファインダーとしての設計：ARや写真再撮影との比較]
アプリは3つの基本要素で構成される。 シーンはガイドとなるシーン画像と、それに合わせて撮影されたフォトの集合であり、同じシーン画像に対して複数の人が撮影した結果を集めて比較できる。 プロジェクトはシーンの順序つき集合で、個人で完結する「マイプロジェクト」と複数人で共有する「共有プロジェクト」の2種類がある。 アカウントはGoogle Firebaseで管理される。[UC-004 §アプリの基本要素とプラットフォーム]
プラットフォームは、利用者が現場で使うiOS版・Android版アプリのほか、共有プロジェクトの作成ツール（メモグラ・マネージャ）と閲覧ツール（メモグラ・ビューア）から構成される。 マネージャは現在招待制で運用されており、ビューアはアクセスコードで閲覧できる。 サーバ側に保存されるのは共有プロジェクトのデータのみで、マイプロジェクトのデータはサーバには保存されない。[UC-004 §アプリの基本要素とプラットフォーム]
メモリーグラフはオフラインでの現地活動を前提に設計されており、基準画像をスマートフォンに入れて現場に持ち出し、その場で撮影してデータを集める。[UC-004 §フィールドワークへの活用：メモリーハンティングと災害アーカイブ]
実際の運用では、アプリの仕組みは単純でも同一構図に合わせる作業は想定以上に難しいと報告されている。 古写真と現在の景観の間で何が変わり何が変わっていないかを判断できれば、変わっていない要素に照準を合わせて構図を決めやすくなるため、景観を読む力、すなわち地形のような変わりにくい要素や文化的景観に関する背景知識がアプリを効果的に使ううえで求められるという側面がある。[UC-004 §利用上の留意点：難易度のギャップと景観を読む力]
海外でのフィールドワークにアプリを持ち込んだ事例では、Googleサインインが使いにくい環境でのログイン問題や、共有プロジェクトの作成権限が申請者に限定されていることへの対応（参入コードによる回避）、中国での地図サービスの切り替えといった運用上の課題も生じている [UC-008 §メモリーグラフを用いた現地調査]。 これらはアプリの基本的な撮影機能に関わるものではなく、共有機能やプラットフォーム依存の認証を現地環境に合わせる際の課題である。 活動のユースケースの詳細は「メモリーグラフを用いた活動のユースケース」を参照。
メモリーグラフを使った活動は、デジタルアーカイブの資料を手に街へ出る、という一点で共通しながら、景観学習・まちづくり支援・災害記録・観光と、適用される文脈は幅広い。本節では、これらの活動がどのような形で実践されてきたかを、具体的な事例から整理する。
大阪大学D3センターの髙橋彰氏らは2017年頃から、「京都の鉄道・バス写真データベース」を素材として、展示会・まち歩き・セミナーを組み合わせる活動を京都市内で積み重ねてきた [UC-005 §デジタルアーカイブを活用したイベントの開催]。2021年度以降はその重心を、特定地域のまちづくり団体へのフィールドワーク支援へと移し、京の三条まちづくり協議会・鴨川運河会議・祇園新橋景観づくり協議会の3団体を対象にメモリーグラフの実証実験を行った [UC-005 §まちづくり団体を対象としたメモリーグラフの実証実験]。
体験とヒアリングを通じて、まちづくりにおけるメモリーグラフの意義として4点が浮かび上がった [UC-005 §メモリーグラフの4つの意義]。第1は、同じ場所を複数ユーザーが継続的に撮影することで蓄積される景観のアーカイブとしての機能であり、保全すべき視点場をあらかじめ登録すれば定点観測として活用できる。第2は、古写真との比較によって「まちづくり活動の成果としての良くなった今」にも気づける現状把握と景観分析のツールとしての機能で、「古いものが良い」という一面的な理解を補正する効果が指摘された。第3は、長く住む人が感じにくくなった地域の魅力を、新住民や観光客に伝える普及・啓発ツールとしての役割。第4は、スマートフォン操作が得意な若者と地域知識が豊富な高齢者とが交差する場面を生み出すコミュニケーションツールとしての機能で、高齢者福祉施設や同窓会・法事など人が集まる場での昔話の起点になりうるとも述べられた。
一方、実証実験では課題も整理された。古写真の収集・整理にかかる手間と費用・人手、責任の所在、素材選定の難しさがその主なものである [UC-005 §課題と気づき]。収集や整理の過程そのものをまちづくり活動の一部として位置づけ、写真にストーリーを添えることでまち歩きの切り口を増やす構想も示された。髙橋氏は活動の展望として、楽しむ・集める・考える・伝えるというサイクルを循環させることで、景観学習の活動がコミュニティアーカイブへとつながっていくことを描いている [UC-005 §知見と展望]。
2023年度からは、「メモグラ・マネージャ」と「メモグラ・ビューア」を使い、大学生自身がイベントを企画・運営する段階へと展開した [UC-005 §大学生による景観学習イベントの企画・実践]。NPO法人京都景観フォーラムの講座を受講した大学生（4回生）が、「レトロ⇔モダン 古写真でめぐるまちあるき 平安神宮〜知恩院」と題するイベントを企画し、2024年3月に京都市東山区で実施した。企画段階では、マネージャ上で現地下見用のプロジェクトを作成して候補地を絞り込み、当日用のプロジェクト作成と撮影写真の選定（9枚）まで担った。
参加学生からは「古写真と同じアングルで撮りながら豆知識を聞くことで新しい視点でまち歩きができた」という声が、企画側からは「自分たちでルートや写真を考えることで地域についてより深く考えるきっかけになった」という声が寄せられた。参加・企画のいずれの立場でも、地域への向き合い方が変わる経験になったことが確認されている。
2024年度から飛騨市で始まった「飛騨古川・町並みの未来編集部」は、中学生を主体とした景観学習をコミュニティアーカイブへつなぐ試みである [UC-005 §飛騨古川での中学生との景観学習プロジェクト]。飛騨市役所まちづくり観光課・飛騨市立古川中学校のマイプロジェクト（地域貢献の課外授業）を軸に、大阪大学・新潟大学・CODHが協力する体制で進められた。
全4回のワークショップは段階的に構成されている。第1回は1974年・1986年の町並み調査写真（飛騨市所蔵）を素材に撮影場所を探す活動で、大学生が特定できなかった写真を「SOS」として中学生に託し、生徒が地域の人に聞き取りをして撮影場所を見つけてくる場面もあった。第2回はメモリーグラフを使ったゲームで、構図のずれを減点とするルールのもと中学生がゲーム性を楽しみながら取り組んだ。第3回は自分たちが良いと感じた場所を視点場として10カ所ほど撮影し、一筆書きできるまち歩きルートを地図に落として「マイタウントレイル」としてメモグラ・マネージャに登録した。第4回は地域の人々を実際に案内するまち歩きで、中学生が自分たちの取り組みを発表した。髙橋氏は「中学生だからといってできないことはなく、むしろこちらが教えてもらうことも多々あった」と振り返り、写真とメモリーグラフを介してフィールドに出る体験が地域学習として意味を持つことを述べている。
景観学習とは異なる文脈で、メモリーグラフは災害のビフォーアフター写真を現地で辿る活動にも用いられてきた [UC-004 §フィールドワークへの活用：メモリーハンティングと災害アーカイブ]。阪神・淡路大震災20周年にあたる2015年の取り組みがその例で、震災直後の記録写真がオープンデータとして公開されていることを受け、その写真を使って現在の同じ場所を撮影する活動が実施された。2015年1月17日にはインドネシア・アチェの参加者と、2月1日にはCode for Kobeのメンバーとそれぞれ現地で実験が行われた。この活動で、震災を直接知らない子ども世代もアプリにすんなり馴染み、文章の説明を読むよりも実際に使う方が直感的に理解できることが確認された。
メモリーグラフを使う活動に共通する特性として、身体を現地に移動させること自体に価値があるという点がある [UC-004 §フィールドワークへの活用：メモリーハンティングと災害アーカイブ]。メモリーグラフはオフラインでの現地活動を前提としており、現場でこそ土地の質感や細かな変化を感じ取れるという声は、まちづくり団体との実証実験においても同様に報告されている [UC-005 §課題と気づき]。
critical editing
複数の伝本や校異を突き合わせ、本文の異同を判断して整えること。翻刻が原文の忠実な 再現であるのに対し、校訂は編者の判断による本文の確定を含む。
関連: 翻刻
jageocoder
Python版ジオコーダー。日本の住所を緯度経度に変換する機能など、多様な機能を提供する。情報試作室の相良毅氏が開発するオープンソースのソフトウェア。
別名: Jageocoder
International Image Interoperability Framework
画像やその他のメディアを相互運用可能な形で配信・記述するための国際的な枠組み。 Image API と Presentation API を中心に構成され、機関をまたいだ資料の閲覧・比較・注釈を可能にする。
別名: トリプルアイエフ・アイアイアイエフ ／ 関連: マニフェスト ／ 出典: IIIF 公式サイト
transcription
歴史資料に書かれた文字を判読し、現代の活字に起こすこと。原文の字体・誤字も含めて 忠実に再現する点で、本文を整える「校訂」とは区別する。
別名: テキスト化・字起こし・翻字 ／ 関連: 校訂
manifest
IIIF Presentation API において、1 つの資料(書物・巻物など)の構造とメタデータ、 構成画像(canvas)の並びを記述する JSON 文書。閲覧アプリはこれを読み込んで資料を表示する。
別名: IIIFマニフェスト・Manifest ／ 関連: IIIF
metadata
資料そのものではなく、資料を記述する情報(標題・作者・年代・所蔵者・権利など)。 発見・同定・相互運用の基盤となる。
別名: メタ情報・書誌情報
georeference
現実の地理空間と空間データの位置を合わせる作業。画像単位やポイント単位などで合わせることができるが、特に画像から複数の地上制御点（Ground Control Point, GCP）を拾って、それらをマッピングするための幾何学的変換を計算する方法がよく用いられる。
別名: ジオリファレンス
ガイドラインは、Agentic Publishingシステムにより作成されたものです。Agentic Publishingとは、人間が指定した構造に沿って、AIエージェントが知識ベースから記事を選び、成果物を構成するプロセスです。
ガイドライン編集者は、章節の構成（見出しなど）をマークダウン形式で指定し、各章節の内容をYAML Front Matter Block形式で指定します。これは、各章節が何を記述し、何を記述しないかを指定するものです。
Agent Publishingシステムは、以下のような特徴を備えています。
また、編集レシピとして、以下のようなファイルを管理しています。
これは、素材（知識ベース）から料理（出版物）を作るノウハウを蓄積するようなものであり、生成ごとに品質が向上していくことが期待できます。
ライセンス:CC BY 4.0 / 権利者:各記事の著者、DiHuCo
この節へのコメント