地図・地誌類データを中心としたデータ/AI駆動型人文学研究のガイドライン(仮称)

第1版 候補1(候補版・非規範)

書誌情報

タイトル
地図・地誌類データを中心としたデータ/AI駆動型人文学研究のガイドライン(仮称)
著者
DHコンソーシアム(DiHuCo)
出版者
DiHuCo研究実践ハブ
版
第1版 候補1
状態
候補版(非規範)。引用には承認版を使ってください。
公開日
2026-10-28
URL
https://codh.rois.ac.jp/dihuco/dgs/guideline/candidates/1-1/

本版は候補版であり、規範性を持たず、内容は予告なく変更されます。引用には承認版(DOI付き)をお使いください。

本版も承認版と同じく CC BY-NC 4.0 で提供されます。版の状態(作業版・候補版・承認版)によって、利用条件が変わることはありません。

はじめに

本ガイドラインは、デジタル・ヒューマニティーズ・コンソーシアム(DiHuCo)の研究実践ハブが作成する。焦点は実践知にある —— 研究においてどのようにデータを作り、どのように扱い、何を問うたか。

扱う範囲

地理情報と空間、地域を記した地誌資料、そして画像と視覚資料を主な対象とする。それらをデータとして扱うための作法、AI との協働、データを公開する実務、そして研究が社会と接する場面を収める。

扱わない範囲

テキストそのものの符号化は、DiHuCo 研究基盤ハブが公開する東アジア/日本のテキストデータ構造化のためのガイドラインが扱う。本ガイドラインはその分担の外側を担うため、TEI による符号化と学術編集版には立ち入らない。ただし画像に写った文字を読むこと —— 認識、字形の分析、判読して活字に起こす翻刻 —— は本ガイドラインが扱う。同ガイドラインの範囲と一部重なるが、画像から文字を起こすことは本ガイドラインの中核にあるため、重複を許容する。

テキストの計量的な分析 —— テキストマイニング、トピックモデル、文体分析 —— も範囲外である。本ガイドラインの対象が図像的・空間的な資料であり、素材とした講演にこの領域の実践知がないためである。ただし規模を変えて見るという見方、すなわち遠読は、画像と空間に適用する形で扱う。

このほか、ネットワーク分析、画面の設計と利用者試験、音声と映像、そして自分で機材を飛ばして行う撮影と測量は扱わない。衛星画像や過去の空中写真のように、すでにアーカイブとして存在するデータを使うことは扱う。

外に良い規範があるので参照で足りるもの

扱わない理由がもう一種類ある —— 本ガイドラインが書くより、既にある文書を指した方がよいものである。

資料の撮影とデジタル化(解像度・色管理・照明・撮影記録)は、国文学研究資料館の日本語の歴史的典籍のデジタル化に関するマニュアルが、撮影方法を詳細に示している。本ガイドラインは節を設けず、そちらを参照する。

FAIR 原則と研究データ管理の一般論は、ALLEA のSustainable and FAIR Data Sharing in the Humanitiesと DARIAH の資料がある。本ガイドラインは、地理・画像・三次元のデータに固有の判断に絞る。

保存の理論的枠組み(OAIS 参照モデル、InterPARES)も概念の紹介にとどめる。

扱うべき範囲のうち、まだ書けていない領域については付録に一覧を置いた。

この文書の作り方

本ガイドラインの本文は、実践知に関する講演や記事を素材とし、研究実践ハブが指定した構造にしたがって AI が生成したものである。本文には根拠となる記事へのリンクを置き、記事からはその出典となる講演資料やリンク先をたどることができる。このようにテキストの由来を検証できる仕組みを用意することで、AI の柔軟性と専門家の信頼性とを統合することを目的とする。

1 地理情報と空間

地図・地誌・地名をはじめとする地理情報を、研究のためのデータとしてどう作り、どう扱うかをまとめる。

1.1 空間の表し方

位置を数値で表すとは、地球上の場所に座標という識別子を割り当てることである。球面を平面へ写す投影法と、座標値の意味を定める測地系は、どちらも取り決めであり、何を優先し何を捨てるかの選択を含む。

緯度経度と見かけの桁数

位置を表す最も標準的な方式は緯度経度である。スマートフォンの地図が現在地を示すときにも使われている [UC-009 §地理情報とは何か]。高さを加えれば3次元になるが、地図は平面で表示されるため、基本的には2次元の座標として扱われる [UC-009 §地理情報とは何か]。

緯度経度の扱いにくさは、座標値が二つ必要なことに加え、何桁まで精度の裏づけがあるかが見た目から分からない点にある。プログラムが返す数値は小数点以下15桁ほどになることもあるが、実際に意味を持つのは6桁程度で、これがおよそ1メートルの精度に相当する [UC-009 §座標を指定するその他の方式]。有効桁数を確認せずに使うと、見かけの精度と実際の精度のあいだに齟齬が生じる。

グリッドと単語による位置の指定

緯度経度の限界を補うため、地球を区画に分割して識別子を与える方式が考案されている。Uberが用いるH3は地球を六角形に分割し、各セルにIDを付ける。分割には三角形・四角形・六角形があるが、四角形では縦横と斜めで隣接セルまでの距離が異なる。H3の六角形では隣り合うセルへの距離がすべて等しい [UC-009 §座標を指定するその他の方式]。ズームインするほどIDが長くなり、ID自体が解像度の情報を含む点も特徴である。同じく六角形を用いる方式にGeoHexがある [UC-009 §座標を指定するその他の方式]。

3つの単語の組み合わせで位置を表すwhat3wordsは、覚えにくいIDの代わりに覚えやすい言葉を使うという発想に立つ。ただし、実際にはあまり普及していないとの見方が示されている [UC-009 §座標を指定するその他の方式]。

球面を平面に写す決断——地図投影法

地球全体を表示するには、3次元の球面を2次元の平面に写す必要がある。球面を平面に押し込めるとどこかが必ず歪み、長さ・面積・角度・形のすべてを同時には保存できない。投影法とは何を保存し何を捨てるかの選択であり、目的に応じて100種類以上が提案されてきた [UC-009 §地図投影法]。

保存の対象によって性格が分かれる。正角図法は角度を、正積図法は面積を、正距図法は中心から各点への距離を保存する。正距図法は、ある都市から各地までの距離を正しく示す航空路線図などに使われる [UC-009 §地図投影法]。

広く知られるメルカトル図法は、緯度と経度が直交する格子を作るが、極に近づくほど面積が拡大し、極域を描けない。これを改良したUTM(ユニバーサル横メルカトル図法)は、地球を経度6度ずつ60のゾーンに分け、各ゾーンの中央子午線からの距離をx座標、赤道からの距離をy座標とすることで、全体の歪みを最小化する [UC-009 §地図投影法]。このほか、データ処理に便利な正距円筒図法や、視点を無限遠に置いて地球を眺める正射図法がある [UC-009 §地図投影法]。

投影法を一つ選ぶことは、何かを優先する決定であると同時に、他の幾何学的性質を犠牲にする決定でもある。

測地系——座標値の意味を決める基準

投影法と並ぶもう一つの取り決めが測地系で、地球の中心と形を定義する枠組みである。緯度経度や高さの値はこの定義に依存し、同じ場所でも基準の取り方によって座標値が変わる [UC-009 §測地系と高さの基準]。

地球は完全な球ではなく、自転によって赤道方向にわずかに潰れた楕円体として近似される。かつて測地系は国ごとに異なり、日本も2000年ごろまで独自の測地系を用いていた。GPSの普及に伴い世界測地系WGS84が標準となり、日本も2000年に移行した。このとき全国の緯度経度値が変わり、古い地図を使ったカーナビゲーションで位置がずれる事例も生じた [UC-009 §測地系と地球の形]。地球の中心を重力の中心として定めたことで、ニュートン力学に従って運動するGPS衛星との親和性が高まり、複数の衛星の信号から高精度の測位ができるようになった [UC-009 §測地系と地球の形]。異なる時期のデータを統合するときは、どの測地系に基づくかの確認が欠かせない。

高さの基準はさらに複雑である。GPSが与える高度は、基準楕円体の表面からの高さである。一方、日本で伝統的に使われてきた高さは、東京湾の平均海水面を基準とする。これは重力が釣り合う水面であるジオイド面に対応するが、山や深い海、地下の岩石密度によって重力の強さが場所ごとに異なるため、ジオイド面は不規則な形になる [UC-009 §高さは何を基準に測るか]。そのためGPSが示す高さと海抜による高さは食い違う可能性がある。水面基準の高さは過去に積み上げたデータとの連続性のために使われ続け、GPSだけから高さを推定するときには楕円体基準が用いられる [UC-009 §高さは何を基準に測るか]。

空間を索引する——R木と空間検索

座標・投影法・測地系が決まれば、空間オブジェクトを格納して検索する仕組みが問題になる。点・線・ポリゴンといった図形のあいだには、交わる・接する・含む・内側にある・重なる・等しいといった関係が定義され、和・距離・交差といった図形操作も提供されている。こうした関係の表現と図形操作を備えることが、地理情報システムの特徴の一つである。これらの計算幾何の処理を担うライブラリとして、C/C++で書かれたGEOSがある [UC-009 §空間検索を高速化する仕組み]。

検索の対象が少なければ、一件ずつ調べるリニアスキャンでも現実的な時間で解ける。しかし100万、1000万件になると時間がかかり、オブジェクトをインデックス化するアルゴリズムが必要になる [UC-009 §空間検索を高速化する仕組み]。代表的な構造が1984年に提案されたR木(R-tree)で、大きな矩形から順に内側の小さな矩形へとたどることで、すべてを調べずに検索できる [UC-009 §空間検索を高速化する仕組み]。

典型的な検索には二種類ある。ある領域に含まれるオブジェクトを探すcontainsは、たとえば東京都に住む人(点)、東京都を通る道路(線)、東京都内の公園(ポリゴン)を探す処理にあたる。ある地点から一定距離以内のオブジェクトを探すwithinは、距離を一つずつ測る代わりに、バッファリングで範囲を領域に変換し、contains検索と組み合わせて実現する。領域を拡張してインデックス構造を使うことで高速化できる [UC-009 §空間検索を高速化する仕組み]。Google Mapsのような地理情報サービスの機能も、こうしたアルゴリズムが支えている [UC-009 §空間検索を高速化する仕組み]。

地名による位置の指定については「地名という接点」を、空間境界の時間的変化については「時間をもつ空間」を参照されたい。

この節へのコメント

  • まだコメントはありません。

1.2 地名という接点

地名は、史料のなかの記述と地図上の位置を結ぶ接点になる。本節では、その接点がどう成り立つか、地名を辞書としてどう構造化するか、住所や地名を位置に変換する処理、そして歴史地名に特有の同定の難しさを述べる。

三つの空間と地名

地理に関わる資源は、情報空間・地理空間・つなぐ空間の三つに分けて整理できる。情報空間は、テキストや画像など、地理に関わるメディアのデータの空間である。地理空間は、点・ポリゴン・ピクセルなど、現実世界を表す幾何データの空間である。両者を結ぶのがつなぐ空間であり、座標と識別子を併せ持つ地名(トポニム)がここに位置する [UC-010 §情報・地理・つなぐ──三つの空間のモデル, UC-011 §3. 「どこ」を特定する——情報空間・地理空間・つなぐ空間]。

この定式化の要点は、地名が二つの付与によって両方の空間につながることにある。地名に識別子(ID)を与えれば情報空間へ、座標を与えれば地理空間へつながる。史料の記述中の地名を地名辞書のエントリと結びつければ、そのエントリが示す実体の座標を通じて、地図上の位置が得られる [UC-010 §情報・地理・つなぐ──三つの空間のモデル]。

位置を指定する手段は座標だけではない。人どうしの会話では地名で位置を伝えるのが普通だが、地名は計算機では扱いにくく、計算処理には緯度経度が使われる [UC-009 §地理情報とは何か]。地名に座標が対応づけられて初めて、人の使う位置の言い方と計算機が扱う位置の表現が往復できる。座標そのものの表し方は『空間の表し方』を参照。

地名辞書と識別子の付与

地名辞書(ガゼッティア)は、地名のエントリを集めた情報空間側の資源である。各エントリは名称・位置・読みなどの属性と識別子を持つ。属性のうち位置は、地図に表示したいという目標があるため特に重要になるが、どこを代表点として選ぶかという難しさを伴う。名称の表記揺れや粒度の違いの吸収、よみや基本統計の付与も必要になる [UC-033 §地図・地誌・地名の枠組みと識別子付与の方針]。

識別子の付与では、何を同じ実体(エンティティ)とみなすかという基準が問われる。たとえば東京が指す範囲は、東京市15区から35区を経て現在の23区へと変わり、東京府と東京都でも異なる。これらを同じ東京とみなすかはどちらの立場も取りうるため、基準をあらかじめ決めておく必要がある [UC-033 §地図・地誌・地名の枠組みと識別子付与の方針]。識別子と属性の組をデータセット化すれば、実世界との紐づけとデータ統合に使える。

識別子を付与し共有する基盤として、地名情報処理基盤GeoLODがある。多数の地名をアップロードしてGeoLOD IDを割り当てれば、そのIDを複数のアプリから利用でき、異なるアプリ間のデータ統合も容易になる [UC-010 §歴史的ジオコーダーとGeoLOD──地名をつなぐ基盤]。属性表示や検索はウェブとAPIから利用でき、オンラインで地名辞書を構築・共有する機能も備える [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。識別子の設計や引用の仕組み一般は『識別子とデータ引用』に譲る。

地名辞書は典拠データとしても働く。歴史的行政区域データセットは、複数のデータセットを統合して1889年以降の市区町村に一意のIDを付与したものである。公式の市区町村IDは1968年以降にしか存在せず、それ以前の期間をこのデータセットが補っている [UC-010 §歴史的行政区域データセット]。地震史料集のデータベースでは、書名や有感地点の地名にこのデータセットの地名IDを付与し、索引地図から「宇治」に関連する史料を検索できるようにしている。ただし地図上の点は市区町村レベルの代表位置であり、被害の発生地点や地震を感じた地点とは必ずしも一致しない [UC-047 §地名へのIDの付与]。

代表例:『日本歴史地名大系』地名項目データセット

歴史地名の辞書として代表的なものが『日本歴史地名大系』地名項目データセットである。平凡社刊行の『日本歴史地名大系』(全50巻、1979〜2004年)の地名項目に位置情報を加えて機械可読にしたもので、江戸時代の村までさかのぼる80,502件を、名称・位置・読みと識別子の部分についてCC BYのオープンデータとして公開している [UC-010 §6.1 『日本歴史地名大系』地名項目データセット, UC-033 §地名のデータセット:行政区域から近世村へ]。

公開されるのは事実に関する書き手に依存しない情報で、解釈に関わる記述部分は購読制のジャパンナレッジに残る。地名ページから記述へリンクが張られ、オープンからクローズドへたどれる構造である。出版社と協力した学術情報のオープン・クローズ戦略として設計されている [UC-012 §江戸近世村データセット]。同じ資料の施設・地点項目も32,038件がCC BYで公開されている [UC-033 §地名のデータセット:行政区域から近世村へ]。

典拠データとしての価値は、他のデータとの突き合わせに現れる。このデータセットと幕末期近世村領域データセット(66,581村)を名称の一致で突き合わせ、約56,000件を統合した例がある。ただし、一方では一つの村が他方では東西に分かれて粒度が異なる場合や、表記が異なって対応づけられない場合など、統合できない例も見つかっている。粒度の相違や表記揺れ、どちらを正解とするかという問題は、歴史データでは一般的だとされる [UC-012 §江戸近世村データセット]。郷帳の村との対応づけでも、同名の候補が複数あるとき、直前に記載された村の座標から半径10km以内で検索するルールにより、地名全体の約68.6%を1件に絞り込めた。残りの約3割は人手での突き合わせになり、3年経っても終わっていない [UC-049 §ルールベースによる絞り込み]。

ジオコーディング

住所や地名を座標に変換する処理がジオコーディングである。住所は地名の一種だが、行政区分に対応した階層構造を持ち、番号によって位置を指定する点に特徴がある [UC-031 §住所とジオコーディングとは]。日本の住所は、地番住所と住居表示住所が併存するうえ、パターン化が難しい。「長野県長野市南長野県町」のようにひとつの住所に都道府県名を表す文字列が2回現れる例があり、単純な処理は破綻する。表記揺れ、異体字、複数の表記法、部分的な省略への対応も欠かせない [UC-031 §日本の住所が抱える課題]。

歴史資料の住所を扱うジオコーダーは、現代の住所向けジオコーダーのデータベースを過去の住所のデータベースに差し替えて作る。jageocoderは住所データベースを目的に合わせて変更できるため、旧東京市15区住所データセット(56,089件)を組み込むと、1907年の東京市の住所を解析できるようになる [UC-031 §jageocoder——現代日本の住所ジオコーダー]。

実際の資料を変換すると、表記揺れ・異体字への対応が精度を左右することがわかる。関東大震災の死亡者調査表(38,332件)の住所を変換した事例では、そのままでは「本所区三笠11」が「本所區」までしか変換されなかった(正式には「本所區本所三笠町」)。表記揺れのパターンを辞書に登録すると、約84%が地番レベルで変換できるようになった。続けて、一意に決まらない町名の判定(単に「横川町」とあれば「本所横川町」とみなす)、誤字の修正(常磐→常盤、蛎売→蛎殻など)、区の誤記の補正、残りの個別確認を重ね、地番レベルの変換率は87%に達した [UC-032 §住所データ修正のワークフロー]。辞書を拡張するか元データを修正するかは、どれだけ例外的かで判断する。Unicodeとして適当でない書き間違いに近い文字は、無理に異体字として登録せず、住所データ側を修正して対応する [UC-031 §異体字への対応]。

変換できない住所も残る。調査表の事例では、対象データセットの範囲外である15区外の郡部や他府県の住所、住所の記載がないもの、データセットが1907年時点であるため含まれない1913年成立の町などがあった [UC-032 §変換の限界と今後の課題]。『日本歴史地名大系』の地名の位置推定でも、平成の大合併以前の住所に対応する現代住所の候補をjageocoderで探してジオコーディングする方法が使えた。ただし自動化できるのは一部で、手動の対応が多く残ると報告されている [UC-031 §『日本歴史地名大系』地名項目データセット]。

テキストを地図につなぐ処理は、地名の認識とその特定の二段階からなる。史料の文章から地名を認識したあと、その地名がどこを指すかを特定する(曖昧性解消)。たとえば「宇田川丁」が江戸マップIDの宇田川町だとわかれば、IDから緯度経度が得られ、地図に可視化できる [UC-013 §史料と実世界の紐づけ——固有表現認識と被害可視化]。テキストからの地名抽出そのものは『テキストから実体を取り出す』を参照。

同じ名が違う場所を指し、違う名が同じ場所を指す

歴史地名の同定が難しいのは、名前と場所が一対一に対応しないからである。

同じ名が違う場所を指す場合。 「横川町」は本所横川町・中ノ郷横川町・柳島横川町のいずれかを指しうる。区別の表記があるものを除き、単に「横川町」とあれば「本所横川町」とみなす、といった判断が要る [UC-032 §住所データ修正のワークフロー]。『天保郷帳』の村でも、GeoLOD上で同名の地名が複数あるとき、隣接する村が並べて記載される性質を使って候補を絞っている [UC-049 §ルールベースによる絞り込み]。

違う名が同じ場所を指す場合。 「神田區一ツ橋通」がデータベース中の「一ッ橋通町」に対応するように、表記の異なる名を同じエントリに寄せる対応が要る。省略も同様で、「東京府東京市小石川區大塚辻町」は実際には「小石川大塚辻町」を指すため、省略された地域名を補うルールを個別に記述した [UC-031 §表記揺れ・異表記辞書]。異表記は、データセットの異名フィールドと文字レベルの自動変換を組み合わせて対応するが、すべての変種の網羅は困難だと述べられている [UC-010 §得られた知見と今後の展望]。

位置を一つに決められない場合。 ある藩の陣屋は候補が複数あり、一つに決められない。この例ではUber H3インデックスを使い、六角形で位置の範囲を指定した。このIDは場所と六角形の大きさを一つの文字列で同時に指定できるため、ID自体に曖昧さのレベルが含まれる [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。

名称と場所の対応を取るために、古地図から地名を抽出し一点ずつ現在位置に対応づける作業も行われている。江戸切絵図は距離と方位が歪んでいるため、座標変換だけでは合わず、約8,000か所のマーカーを一点ずつ動かした [UC-044 §江戸マップ:江戸切絵図の地名を現代の地図に重ねる]。この手順は『地図資料の処理』で扱う。

この節へのコメント

  • まだコメントはありません。

1.3 時間をもつ空間

旧国・旧郡、近世村、藩、市区町村といった空間の単位は、時代とともに範囲も名称も変わる。ここで扱うのは、その変化をデータとしてどう表すかと、時代をまたいで同じ場所を指すことの難しさである。座標や投影法の選択は節「空間の表し方」(geo-coordinates)に、地名と識別子・典拠の関係は節「地名という接点」(geo-toponym)に委ねる。

過去へ遡るほど断片的になる空間情報

現代の空間情報基盤には地図など整備済みのものが多いが、過去に遡るほど未整備になり、データは時期や地域ごとに断片的になる。これを接続して統合することが、歴史的空間情報基盤の課題として位置づけられている [UC-013 §地図・地名・地誌——空間情報を扱う三つの単位]。この整理は、時間を扱うモデルそのものを述べたものではなく、以下の個別の事例が置かれる背景である。

時期の異なる単位を「同じもの」として束ねる

通時的なデータセットを作るときの出発点は、時期の異なる単位を同一のものとみなす基準を決めることである。国土数値情報のような時点ごとのデータをそのまま並べるだけでは、合併で範囲が変わった市区町村を一続きの存在として追えない。歴史的行政区域データセットは、時期の異なる市区町村どうしを「同じもの」として統合するために、概念としての市区町村に ID を付与している。八王子市には ID「13201A1968」が与えられ、合併で範囲が広がっても一つの市として扱われる。江戸から「東京府東京市(15区)」「同(35区)」「東京都特別区部(23区)」へと変遷する例でも、同じものは同じ、違うものは違うと区別して ID を付けている [UC-013 §歴史的行政区域データセット——市区町村IDの付与]。範囲が変わっても同じ ID を使うので、資料に現れた八王子市をこの ID に結びつけたうえで、資料の年代によって範囲が異なることを確かめられる [UC-033 §地名のデータセット:行政区域から近世村へ]。

この系列を過去へ延ばす作業は難航している。現状の網羅的な ID 付与は 1920 年以降の市区町村 16,729 件で、1919 年から 1889 年(市制及び町村制の成立年)への遡及と、明治から江戸への遡及が課題として残る。1889〜2006 年には行政界変遷データベースが使えるが、誤りが多く、部分的な利用が想定されている [UC-013 §歴史的行政区域データセット——市区町村IDの付与]。江戸時代に遡る際の主な情報源は『日本歴史地名大系』であり、その地名項目 80,502 件を機械可読化したデータセットが、通時的な統合 ID の足がかりになっている [UC-033 §地名のデータセット:行政区域から近世村へ]。

公式のリストがない単位を数える——藩

江戸時代の藩のように、そもそも「何を一つと数えるか」が決まっていない単位がある。藩は江戸時代に正式に定義された語ではなく、明治以降に使われた語である。公式のリストがないため総数の確定は難しく、厳密な定義は歴史研究そのものになるので、藩 ID データセットではそこに踏み込んでいない。複数の藩史事典を比較して統合と分離を検討し、寛文 4 年(1664)から明治 4 年(1871)に存在した藩として 408 藩を定めた。これも唯一の正解ではない [UC-013 §藩IDデータセット——識別子の付与と研究動向の可視化, UC-012 §藩IDデータセット]。

呼称にも公式の定義がなく、文献によってばらつく。「薩摩藩」と「鹿児島藩」のように地名と家名のどちらを使うかが分かれ、松山藩は出羽・伊予・備中に三つ存在する。代表名は、J-STAGE の論文での使われ方や Wikipedia の用例も参照して決められている [UC-013 §藩IDデータセット——識別子の付与と研究動向の可視化]。

藩の範囲そのものも単純ではない。位置は居城・陣屋を代表点として付与できるが、小さな藩の陣屋は痕跡が消えやすく、所在が分からない場合がある [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。領域は幕末期近世村データの領分から可視化できる。加賀藩・尾張藩の領分は大まかには二つの地域に分かれ、熊本藩には飛び地が多く、居城の周りにひとまとまりに広がる形ではない [UC-013 §藩IDデータセット——識別子の付与と研究動向の可視化, UC-012 §藩IDデータセット]。村は基本的に一つの領主に属するが、複数の領主を持つ村もあり、村と藩は多対多の関係にある [UC-010 §藩IDデータセットと村・藩の統合的な可視化]。

藩と大名家も一対一ではない。江戸時代に主だったのは藩ではなく大名家であり、大名家が移動する場合もある。そのため藩 ID とは別に大名家 ID が必要になる。当主交代などのイベントを ID で扱うには、さらに複雑な ID 体系が要る [UC-013 §藩IDデータセット——識別子の付与と研究動向の可視化, UC-012 §藩IDデータセット]。

粒度と表記の食い違いを突き合わせる——近世村

江戸時代の村では、二つの出典を名称の一致で突き合わせたときに、粒度と表記の食い違いが具体的に現れる。『日本歴史地名大系』地名項目データセット 80,502 件と、幕末期近世村領域データセット 66,581 件を照合すると、約 56,000 件が同じ村を指すと分かった [UC-013 §江戸時代の村のデータセット——統合の試みと課題]。残りには、一方では 1 村が他方では東西 2 村に分かれる粒度の相違や、表記揺れとは思えないほど村名が異なるものがある。表記揺れの一因には OCR 誤りも含まれ、どちらが正しいかを一件ずつ確かめる作業は大きな負担になると見込まれている [UC-013 §江戸時代の村のデータセット——統合の試みと課題, UC-012 §江戸近世村データセット]。

領域の側にも限界がある。幕末期近世村領域データセットの境界は、現代の農業集落境界データに由来する。現代の農業集落と江戸時代の村にはそれなりの連続性があるだろうという前提に立った代用であり、当時の境界そのものではなく近似にとどまる [UC-033 §地名のデータセット:行政区域から近世村へ, UC-010 §地名・村のデータセット]。

名称の異なる街道を同じものとして扱う

街道のように線で表される江戸期の対象にも、番号による識別が試みられている。文献によって街道の名称が異なっても、ID で管理すれば同じものとして扱えるので、人や物資の移動経路を ID 間のリンクで表現しやすくなる [UC-044 §地名・街道・宿場のデータセット, UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。番号の体系そのものは節「識別子とデータ引用」(open-identifier)に委ねる。ただし、宿場 ID の付与は進行中で、すべては済んでいない [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。街道にも時期による移設や経路の違いがあり、複数経路がありうる。そのため、ID を与えつつ、説や時期に応じて複数の経路を割り当てられる柔軟な枠組みが望ましいという指摘が、質疑で出ている [UC-012 §江戸期地理データセット]。

位置が定まらないときの曖昧さの表し方

歴史的な単位では、位置が一点に決まらない場合も多い。藩の陣屋のように候補地が複数あるとき、GeoLOD は Uber の H3 インデックスを使い、六角形で範囲を指定する。この ID は場所と六角形の大きさを一つの文字列で同時に指定するため、ID 自体が曖昧さのレベルを含む。おおよその位置しか分からない歴史地名に向いた表し方である [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD, UC-013 §地名情報処理のサービス群——GeoNLP・ジオコーダー・GeoLOD]。

時代による住所の変化と照合の難しさ

通時的な単位の同定は、小規模な時間差でも困難になる。1923 年の関東大震災の死亡者調査票の住所を位置情報に変換する事例では、震災後の区画整理で町名が大きく変わったため、現代の住所表記との対応づけが難しく、現代の住所はあまり参考にならなかった。原票の表記にも揺れがあり、「本所区三笠11」が正式には「本所區本所三笠町」である例、「常磐」と「常盤」のような誤字、記載の区と実際の区が異なる例がある。「横川町」が本所・中ノ郷・柳島のどれか区別がつかない、一意に決まらない町名もあった [UC-032 §大正時代の住所をジオコーディングする課題]。参照するデータセットの基準年にも限界がある。1907 年基準のデータセットには、大正 2 年(1913)に成立した芝区日出町が含まれず、1907 年と 1923 年のあいだで街区や住所が変化した地域への考慮も手つかずになっている [UC-032 §変換の限界と今後の課題]。

既存の通時的データセットを再利用するときの障壁

過去に作られた通時的データセットは、そのままでは再利用しにくい場合がある。講演者は旧国・旧郡境界データセットなどの再利用に関連して、次の四点を挙げている。

  • 技術的制約のある時代に作られたため、現代の基準では精度や統合に問題がある場合がある
  • データセットが公開されても、サービス展開やプラットフォーム化に至らなかった
  • 修正手順が確立されておらず、誤りの指摘に対応しにくい
  • 紙資料のデジタル化・翻刻(OCR)で誤りが混入する

[UC-013 §既存データセットの活用と過去データの課題]

行政界変遷データベースは精度の問題でそのままでは使えない例である [UC-013 §歴史的空間情報基盤の課題と今後の展望]。同じ場所の ID 化では、明治期と江戸期で国・郡の分け方が異なるため、旧国・旧郡境界データセットに対して CODH 側で新たに ID を付与し直している [UC-013 §既存データセットの活用と過去データの課題]。一方、別プロジェクトで埋もれていた旧東京市 15 区住所データセットは、利用許諾を得て再整備された例として挙げられている [UC-013 §歴史的空間情報基盤の課題と今後の展望]。

この節へのコメント

  • まだコメントはありません。

1.4 地図資料の処理

古地図や絵図を現代の地図に合わせるとは、画像上の点を地球上の位置に対応づけることである。測量にもとづく地図なら、幾何学的な変換でかなりの範囲を合わせられる。測量にもとづかない絵図は、位置関係をどこまで信じるかを決めたうえで、一点ずつ扱うことになる。

基準点を打って重ねる

古地図の位置合わせの基本はジオレファレンスである。古地図と現代地図のあいだに GCP(Ground Control Point、基準点)と呼ばれる対応点を打ち、対応点どうしができるだけ近づくように幾何学的な変換を求める [UC-011 §4. 江戸切絵図を現代地図に重ねる——地名抽出とジオレファレンス]。

基準点には、桜田門のような特徴的な地物や堀が曲がる地点が選ばれた。対応物が変化している場合は、現在残っている地物を探して合わせる。かつての堀が現在は外堀通りになっている例である [UC-011 §4. 江戸切絵図を現代地図に重ねる——地名抽出とジオレファレンス]。変換が済めば、古地図を現代地図や Google Earth に重ねられる。江戸切絵図では、東京駅周辺がかつて大名屋敷の区域であったことや、運河の名残が道路に変わった様子が読み取れた [UC-010 §江戸マップ──古地図からの地名抽出とジオリファレンス]。

江戸マップの作成では、位置合わせに先立つ作業がある。地図に描かれた地名の画像座標と翻刻を IIIF Curation Viewer で収集し、続いて切絵図と現代地図の間に基準点を設定して座標変換パラメータを得て、地名の画像座標から緯度経度を推定した [UC-044 §江戸マップ:江戸切絵図の地名を現代の地図に重ねる]。ジオレファレンスは、地名の翻刻という作業の上に載っている。

歪みの大きさをどう扱うか

変換だけでは合わない地図

江戸切絵図は全 29 枚で東京全体を覆うが、後ろの図ほど位置合わせが難しくなる。観光名所を一枚の枠に収めるために、距離も方向も大きく崩れているためである [UC-011 §4. 江戸切絵図を現代地図に重ねる——地名抽出とジオレファレンス]。巣鴨付近では、実際には遠い場所が近くに詰めて描かれていた。この地図は「この道を行けばここにたどり着く」というトポロジカルな関係としては正しく、距離と方位を歪めた地図として解釈すべきだという見方が示されている [UC-044 §江戸マップ:江戸切絵図の地名を現代の地図に重ねる]。

全体を一括で合わせると周辺ほど誤差が増える [UC-012 §江戸マップデータセット]。対処は二段階で行われた。まずジオレファレンスで地名の点をおおよその位置に合わせ、そのうえで一点ずつを現代地図と見比べながら正確な位置へ動かす。寺院が多く描かれた領域では、OpenStreetMap のほうが使いやすかった [UC-010 §江戸マップ──古地図からの地名抽出とジオリファレンス; #UC-044 §江戸マップ:江戸切絵図の地名を現代の地図に重ねる]。この作業を 29 枚すべてで行い、複数の図に現れる同一地名を統合した結果が江戸マップである [UC-044 §江戸マップ:江戸切絵図の地名を現代の地図に重ねる]。

測量地図でも誤差は残る

測量にもとづく地図にも誤差はある。伊能図は実測にもとづくが、測量は海沿いが中心で、測量した部分にもずれが見られる。そのため、岬の地点や村と街道の屈曲といった特徴を現代地図と対応づけて位置を合わせ、江戸時代の海岸線の推定に用いている [UC-011 §5. 江戸の地理空間データとその活用]。

スタインのシルクロードの地図では、描かれた緯度経度の線そのものがずれていた。誤差は場所によって数十 km に及び、特に経度方向で大きかった。経度はグリニッジとの時差から求めるため、砂漠で時計が狂いやすく、都市から離れるほど誤差が蓄積したのである。緯度経度の位置に GPS を頼りに行っても遺跡が見当たらなかったのは、遺跡が失われたからではなく、地図がずれていたからだった [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。

地図の誤りが、画像の取り違えに由来することもある。乾隆京城全図は、基準点が合わない箇所を寺院の位置などから調べると、5 枚のシートで配置が入れ替わっており、一枚の中で左右が逆転しているものもあった。撮影時のミスか、傷んだ地図の修復時の取り違えと考えられる [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。北京の城内は碁盤目状の道であるため、基準点だけでなく、線を線に対応づけて直線が直線として保たれる変換も開発された [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。ただつなげればよいのではなく、正しくつながるかを確認する必要があるというのが、この事例から引き出された教訓である。

幾何補正と一点合わせ

古地図を現代地図に重ねる方法は二つの方向に分かれる。

  • 幾何補正(GCP を使うジオレファレンス): 複数の対応点から変換式のパラメータを推定し、対応点以外の点も式で写す。多くの点の位置は合うが、形が歪むため、地図上の文字が読めなくなる。
  • インタラクティブ・ジオレファレンシング: 見たい一点だけを合わせ、地図の形は歪めない。その一点の周辺以外はずれるが、形が保たれるので文字も読める。スマートフォンで自分のいる場所を中心に合わせて見るような用途に向く [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。

使い分けは精度の見極めで決まる。ある程度の精度のある測量地図には GCP のジオレファレンスが有効であり、歪みの大きい地図は、幾何変換すると可読性が大きく下がるため、歪めずに一点だけ合わせる方法が有効である。点データにとって、ジオレファレンスは出発点にすぎない [UC-011 §8. まとめ——不確かさと向き合う歴史GIS]。

誤差そのものを見せる道具として、一点だけ合わせるソフトウェア「マッピニング」が開発された。地点を選ぶと背景地図が動いてそこだけが合い、「この地点は約 5.6 km ずれている」といった誤差が表示される。ずれの向きへずらして合わせると、遺跡が見つかった [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。

測量に基づかない地図の扱い

絵図は、測量していないために合わせにくく、一点ずつ合わせる必要がある [UC-011 §8. まとめ——不確かさと向き合う歴史GIS]。江戸切絵図の後半の図は、座標を信じず、トポロジカルマップ(位相的な地図)として読む対象になる。ロンドン地下鉄路線図のように、距離や方位が正しくなくても、駅の順序や乗り換え場所といった接続関係が保たれていればよい地図である [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。

不正確な地図が貴重な情報を持つこともある。シルクロードでスタインと同じ地域を調査したグリュンヴェーデルの地図は、位置や方位がずれている。しかし、調査した遺跡と、そこから出土した壁画・壺などの遺物が結びつけて記されている。この地図では、位置や方位を直接は信じず、描かれた道や壁の位置関係を正しいものとして読み、写真の位置関係も併用しながら、もっともらしい解釈を組み立てた。こうして、ほとんどの遺跡を同定できた [UC-011 §7. ディジタル・シルクロードの古地図を読み直す]。

道具とサービス

古地図の位置合わせには、次のような道具とサービスが使われている [UC-011 §6. 古地図の位置合わせ手法とソフトウェア]。

道具 特徴
日本版 Map Warper 立命館大学が公開するサービス。画像をアップロードして対応点を打つと位置合わせができる。OpenStreetMap を土台に、多くの人が地図を持ち寄って合わせられる。江戸切絵図でも使用
Georeferencer 地図収集家デイビッド・ラムジーのコレクションに付随する仕組み。ブラウザ上で点を打って合わせるほか、三次元的な重ね合わせもできる
Allmaps IIIF に対応し、IIIF で公開された地図を取り込んで位置合わせする。複雑な GIS の基盤や XYZ 形式のタイル生成を必要とせず、IIIF サーバーさえあれば動く。複数ページの紙をつないで一枚の地図にすることもできる
Maplat 一点合わせに近く、イラストマップや路線図のように絵のように描かれた空間表現を扱う。位置関係が逆転しないよう同相変換を行い、三角形に分割したり線を線に変換したりして、もとの線が保たれるようにする

IIIF は位置合わせの前段にも使われる。江戸切絵図は国立国会図書館デジタルコレクションで IIIF 形式で公開されており、IIIF Curation Viewer を使うと、地図上の各地点にマーカーを立てて地名を記録できる [UC-011 §4. 江戸切絵図を現代地図に重ねる——地名抽出とジオレファレンス]。大きな一枚画像に大量のアノテーションを付ける場合も、IIIF Curation API に対応したデータであれば、表示と検索のツールを共通に使える。東洋文庫『大明地理之図』では、IIIF Curation Viewer で作成したデータを、アノテーションの表示と検索を行うツールに読み込ませる構成が取られている [UC-003 §東洋文庫『大明地理之図』]。

公開されている成果物

位置合わせの成果は、データセットや地図サービスとして公開されている。

この節へのコメント

  • まだコメントはありません。

1.5 地誌という資料

地誌とは、ある地域に何があり、何が営まれているかを記した資料の総称である。ここでは、どんな資料が地誌として使えるのか、そこに何が記されているのか、そこから何を取り出せるのか、そして地理情報とどう結びつくのかを順に述べる。

地図と地誌——幾何のデータとメディアのデータ

地理に関係する情報は、地図・地誌・地名の三つに分けて整理されている。地図は点やポリゴンなどの幾何的なデータであり、地誌はテキストや画像などのメディアデータである [UC-033 §地図・地誌・地名の枠組みと識別子付与の方針]。地誌では地理情報が地名として言及されることが多く、地名は地図上に表示でき、文章中でも言及できる [UC-033 §地図・地誌・地名の枠組みと識別子付与の方針]。地図は座標で場所を示し、地誌は名前で場所を指す。この二つをつなぐのが地名である。地名がどう両者を接続するかの定式化は「地名という接点」(geo-toponym)を参照。

どんな資料が地誌として使えるのか

地誌の類型としては、名所図会・地域誌・案内記・買物案内・武鑑などが挙げられる。この節に紐づく記事で具体的に確認できるのは、次の二種類にとどまる。

一つは名所図会である。名所図会は江戸時代のガイドブックで、『江戸名所図会』には飯田町の中坂や九段坂(現在の千代田区)が描かれている [UC-045 §POIを選び]。もう一つは辞書型の地名資料である。平凡社の『日本歴史地名大系』は、現在は失われた地名も含み、地名の名称・位置・読みと、辞書独自の詳細な解説とからなる [UC-010 §地名・村のデータセット]。前者は図と文で場所を紹介する資料、後者は地名を項目として並べる資料であり、地誌の中にも性格の異なる資料があることがわかる。

そこに何が記されているのか

名所図会のような資料には、場所の名前と姿が記される。れきちずのPOI(地点)は、国絵図や名所図会などに記載されているものを中心に選定されている。選定の恣意性をできるだけ避けるためで、関所、宿場、城、神社、寺、橋、茶屋など、江戸時代のさまざまな地物が収録されている [UC-045 §POIを選び]。

地誌に記されていることには偏りがある。当時人気だった場所と現在有名な場所は必ずしも一致せず、浮世絵や講の記録などから当時の賑わいを読み取って、当時の観光地にあたる場所も採っている。例として、大山に参詣する大山詣りの人々を描いた浮世絵が挙げられている [UC-045 §POIを選び]。

資料のカバー範囲にも偏りがある。江戸や東海道のように名所図会などの資料が充実している地域がある一方、そうした資料がない地域もある。この地域ごとの偏りは課題として挙げられている [UC-045 §POIを選び]。地誌から集めた地点の分布は、当時の実態そのものではなく、資料が残した範囲を反映するものとして読む必要がある。

そこから何を取り出せるのか

地誌からは、地点の名前と分類を取り出せる。分類には判断を要する場面がある。神社か寺か、城か陣屋かといった区別に悩むことがあり、神社か寺かについては、当時は両者がそれほどはっきり分かれていなかったことが理由として挙げられている [UC-045 §POIを選び]。現代の分類を過去の資料に当てはめるときの注意点である。

資料にもとづいて取り出した地点は、表示の優先度を付けて地図に載せられる。表示順を制御するランクを付け、低いズームでは成田山や関所など重要度の高いPOIを、高いズームでは継立場や村名なども表示する [UC-045 §POIを選び]。

街道や宿場は、地名辞書型の資料から取り出されている。『日本歴史地名大系』の宿場の記述を街道IDごとにリスト化して宿場IDを付与したのが江戸宿場データセットで、東海道の品川宿はR001-002となる [UC-044 §地名・街道・宿場のデータセット]。文献によって街道の名称が異なっても、IDで管理すれば同じ街道として扱えるので、移動のデータを扱うときに便利である [UC-044 §地名・街道・宿場のデータセット]。地誌の記述から、IDを備えたデータ項目が取り出されている例である。

地理情報とどう結びつくか

地誌と地理情報は、地名に識別子を与えることで結びつく。江戸宿場データセットでは、宿場の記述に宿場IDが、街道に街道IDが与えられ、地誌の記述がIDを介して地図上の街道や宿場に対応づけられる [UC-044 §地名・街道・宿場のデータセット]。江戸切絵図に描かれた地名も、江戸マップ地名IDや汎用的なGeoLOD IDを付けた地名データとして切り出され、それによって切絵図上の記述を現代の位置に対応づけられる [UC-044 §江戸マップ:江戸切絵図の地名を現代の地図に重ねる]。位置合わせの手順は「地図資料の処理」(geo-oldmap)を参照。地名に識別子を与えて一元管理することは、地誌と地理情報を結ぶ手段である [UC-033 §地図・地誌・地名の枠組みと識別子付与の方針]。何を同じエンティティとみなすかといった識別子付与の判断は、「地名という接点」(geo-toponym)を参照。

こうして地誌から取り出した地点は、現代の地図に重ねて使える。重ね合わせの実例は「地図資料の処理」(geo-oldmap)を参照。

この節へのコメント

  • まだコメントはありません。

1.6 地理データの形式と公開基盤

地理データを扱うときの出発点は、ラスタとベクタという二つのデータモデルのどちらを主に用いるかである。この選択は、デスクトップ GIS での扱い方や、配信に使うタイル形式へと波及していく。

ラスタとベクタ——データモデルの選択

ラスタデータは、四角形のグリッドのすべてに情報が埋まった構造をとり、衛星画像が典型例である。ベクタデータは、点・線・ポリゴンという図形で位置情報を表す。点は店や学校などの特定の場所(POI)、線は道路、ポリゴンは千代田区のような行政区画の境界に対応する。ポリゴンは始点と終点が一致する閉じた図形で、内部に穴を持つ場合はポリゴンの配列として表せる [UC-009 §地理情報システム(GIS)とデータ構造]。

面を表すもう一つの構造が TIN(Triangulated Irregular Network)である。点どうしをドロネー三角形分割で結んで三角形の網を作り、各頂点に標高などの値を与えて三次元の表面を表す。センサーのある地点の値から、センサーのない場所の値を補間したい場面で用いられ、IoT のようにセンサーを配置して計測する場合によく現れる [UC-009 §地理情報システム(GIS)とデータ構造]。

扱う対象が面的に連続する値なのか、個別の地物なのかによって、どちらのモデルを主に用いるかが決まる。座標系や投影法がこの選択にどう関わるかは、「空間の表し方」を参照。

デスクトップ GIS とレイヤー管理

GIS は地図を表示するだけでなく、地図の作成、情報の付加、データの処理といった機能を持ち、地理情報を管理・可視化・分析するソフトウェアである。特徴的な機能がレイヤーで、道路や建物などの情報をレイヤー単位でオン・オフし、表示する情報を組み合わせられる。道路レイヤーをオフにすれば道路が消え、建物レイヤーをオフにすれば建物が消える。オープンソースの実装としては QGIS が広く使われている [UC-009 §地理情報システム(GIS)とデータ構造]。

バイナリベクタタイルによる大量地点の配信

多数の地点をウェブ地図上で扱う場合、配信形式の選択が表示のしやすさを左右する。歴史地名マップでは、人間文化研究機構・H-GIS 研究会が公開する歴史地名データ 298,914 件をバイナリベクタタイルに変換し、多数の地点を 1 枚のウェブ地図に表示している。このデータは、うち明治〜昭和期の地図から抽出した地名が全体の 8 割以上を占める [UC-013 §既存データセットの活用と過去データの課題]。この事例は、大量の点データをタイルに変換するという方法が実際に成立することを示している。

旧国・旧郡境界のような既存の通時的データセットが再利用しにくい理由——精度、サービス展開、修正手順、翻刻の誤り——は、形式の側の問題ではなく、データの中身に由来する。その内容は「時間をもつ空間」を参照。格納先の選択や API 配信の一般論は「データの格納と情報基盤」を参照。

この節へのコメント

  • まだコメントはありません。

2 画像と視覚資料

画像・写真・三次元といった視覚資料を、研究のためのデータとしてどう作り、どう流通させ、どう分析するかをまとめる。

2.1 資料をさがす・集める

画像資料の研究は、どこで資料を見つけ、どこまでを集めるかを決めるところから始まる。本節は、機関の枠を越えて資料と資料の部分を探す横断検索とその索引化(IIIF Curation Finder・Canvas Indexer)、そして何を集めるかという判断を担う。画像が機関をまたいで同じ方式で公開されていること自体の仕組みは節「画像の流通基盤」の担当であり、本節は収集の前提として使うにとどめる。

機関をまたいで集める

IIIF で公開された画像であれば、公開元の機関を問わず同じ仕組みに読み込める。顔貌コレクションは、国文学研究資料館の資料をもとにした日本古典籍データセットのほか、慶應義塾大学メディアセンターデジタルコレクション、京都大学貴重資料デジタルアーカイブなど、さまざまな組織が公開する作品から顔を切り抜いて一覧化している [UC-041 §顔貌コレクション(顔コレ)とは]。収集の中心は近世の絵巻・絵入本で、江戸初期から中期の作品が多い [UC-041 §顔貌コレクション(顔コレ)とは]。集めた顔貌には統一的なメタデータが付与されており、横断検索が成り立つのはこの統一があるからである [UC-041 §顔貌コレクション(顔コレ)とは]。付与のしかたは節「部分を切り出す」を参照されたい。

部分まで探す——検索と索引化

横断検索の単位は、作品や冊子とは限らない。検索の入口は IIIF Curation Finder で、メタデータの値を選ぶと、表示単位をキャンバス(個々の顔貌)とキュレーション(作品単位)で切り替えながら閲覧できる。たとえばラベル「身分」の値「化身」を選ぶと、仏・鬼・怪物などの顔貌を作品を越えて横断的に見られる [UC-002 §メタデータ検索と派生キュレーションの作成]。

この検索は二層で成り立っている。表側が IIIF Curation Finder、裏側で索引を作るのが Canvas Indexer である [UC-002 §メタデータ検索と派生キュレーションの作成]。裏側の searchEndpointUrl からはキュレーションに含まれる画像とメタデータの一覧が、facetsEndpointUrl からは付与されたメタデータの一覧と各値の付与数が取得できる [UC-002 §メタデータ検索と派生キュレーションの作成]。部分まで探せるかどうかは、画像を公開することとは別に、索引を整えることで決まる。

検索結果は、そのまま次の収集の材料になる。派生キュレーションの作り方と意義は節「部分を切り出す」を参照されたい。

何を集めるか——悉皆か標本か

何を、どこまで集めるかは、研究の結論に直結する。集めた範囲が結論を規定するからである。

収集の方針は、数が示す傾向に反映される。顔コレでは男性が圧倒的に多いが、テーマを選ばずに各機関の公開作品を網羅的に取り込んでいけば男性がさらに増えていくのではないか、というのが講演者の見立てである [UC-041 §顔コレの活用]。これは件数の紹介ではなく、何を取り込んだかによって傾向が変わりうるという論点である。収集の対象が近世の絵巻・絵入本に偏っていること [UC-041 §顔貌コレクション(顔コレ)とは] も、その一例である。講演者は、日本中の作品から顔を集められるようになれば、作品の一般的な傾向がより明らかになるのではないかとも述べている [UC-041 §顔コレの活用]。

一方、網羅の単位を領域全体から一作品へ置き換える選び方もある。『遊行上人縁起絵巻 清浄光寺甲本』の分析では、10巻本で多人数の場面が何度も現れる一作品に絞り、2,000を超える顔貌を対象にした。複数の絵師または工房の手によると言われる作品であり、顔だけを切り抜けば作品内部の分担が分かるのではないかという見通しがあったためである [UC-041 §『遊行上人縁起絵巻 清浄光寺甲本』への手法の適用]。広い領域の標本を取る代わりに、一つの作品の悉皆を目指すことで、その作品の中の比較が成り立つようにしている。研究コミュニティ全体のために長いスパンで作品を足し続ける顔コレと、期間のなかで結論を出す具体的な分析との違いが、網羅の単位の選び方に表れている [UC-041 §『遊行上人縁起絵巻 清浄光寺甲本』への手法の適用]。

集める対象も、資料の種類と問いに応じて選ばれている。『捃拾帖』では、各ページにさまざまな資料が貼り込まれたスクラップブック群を、貼り込み資料の単位まで切り出して管理した [UC-003 §『捃拾帖』内容検索システムと貼り込み資料の自動抽出]。『ヒエラティック古書体学』データベースは、字典の3巻から行単位で2,000件強を抽出している [UC-003 §『ヒエラティック古書体学』データベース]。『デジタル源氏物語』は、東京大学総合図書館所蔵本に限らず、九州大学をはじめ複数の機関で公開されている写本・版本を集約して諸本対照を行えるようにした [UC-003 §「デジタル源氏物語」と諸本比較支援]。何を単位に、どの機関の範囲まで集めるかは、資料の構造と比べたい対象から決まっている。

集める行為を支える知識と体制

集めた範囲の質は、集める人の知識に左右される [UC-041 §顔コレの構築過程]。付与・切り抜きの作業体制は節「部分を切り出す」を参照されたい。地域の資料を集める場合は、地域の知識と組織の連携が、収集の可否を決める。「京都の鉄道・バス写真データベース」は、立命館大学アート・リサーチセンターが所蔵する約9,200点の鉄道・バス写真を対象に構築された [UC-005 §京都の鉄道・バス写真データベースの構築]。市電写真を素材とした理由として、車両を撮った写真の背景に当時は被写体になりにくかった日常の町並みが映り込んでいること、まとまったコレクションとして残されていることが多いこと、肖像権の問題が起きにくいことなどが挙げられている [UC-005 §京都の鉄道・バス写真データベースの構築]。何を集めるかの判断が、資料の性質から導かれている例である。

集める作業が残すもの

収集は資料を見つけて終わりではない。歴史地震のデータセットの事例では、紙のままで機械可読でないこと、紙でしかないデータを勝手にデジタル化してオープンにしてよいか分からないこと、利用条件が中途半端なまま公開されたデータが多いことが課題として挙げられ、これから作るデータは最初から利用条件を明示しておくと後の人が困るとされている [UC-047 §課題と展望]。収集は、利用条件と形式を定めながら進める作業である。また、玉石混交の史料を完全に入れ替えるのではなく、未校訂と校訂済のデータをひもづけて両方が見えるようにするという方針もある [UC-047 §史料集データベースの今後]。集めた範囲に何が含まれ、何が含まれないのかを残すことが、後の結論を読むうえでの前提になる。

この節へのコメント

  • まだコメントはありません。

2.2 画像の流通基盤

IIIF(International Image Interoperability Framework)は、質の高い画像などのデジタル資料を、出典を明示したままオンラインで大規模に届けるための公開標準群であり、その開発・実装を担う国際コミュニティの名でもある。主要な文化機関のコンソーシアムがこれを支えている 1。この節では、その構成と、機関をまたいで資料を並べて見ることが何を変えるか、そしてその前提として何を揃える必要があるかを述べる。

提供する側の標準としての IIIF

様々なサイトの HTML ページを同じブラウザで見られるのと同じように、世界各地の IIIF サービスの画像を同じビューアで閲覧できる。この相互運用性が、画像の世界で IIIF の注目される理由とされている [UC-001 §IIIF Curation Platformとは何か]。ビューアには Mirador や Universal Viewer などがあり、CODH が開発する IIIF Curation Viewer もその一つである [UC-040 §IIIFとは]。

IIIF が世界中で急速に普及したのは、ミュージアムやライブラリといった画像提供者の共通のニーズに応えたからだ、という見方がある。共通形式でデータを公開して相互運用性を担保することで、同じツールで世界中の画像にアクセスできるようになった。各種ツールが IIIF を前提とするにつれ、IIIF に対応していないアーカイブのほうが「不便」とみなされる状況が近づいているとも語られている [UC-001 §IIIFの相互運用性とICPの独自性]。

Image API と Presentation API

中心となるのは二つの API である。Image API は、画像の領域・サイズ・回転・品質・形式を URI で指定し、標準的な HTTP(S) リクエストに対して画像を返す配信 API として定義されている。画像の技術的な情報を返す要求も URI で組み立てられる。この API は、文化遺産機関が管理する画像リポジトリで画像資源を体系的に再利用できるようにするために構想された 1。

Presentation API は、複数の画像や時間的範囲からなる資料を、人が閲覧できる環境で提示するために必要な情報を与える。画像のほか動画・音声などを含む対象について、複数の表示面や時間範囲を順序や階層をたどって見られるようにすること、資料の記述情報を示すこと、出版者と利用者が付加情報を注釈できる共通の場を持つことが目的である。この API が与える記述情報は人が読むためのもので、検索エンジンによる索引付けを意図したメタデータの提供は対象に含まれない 2。

資料の構造を記述するのがマニフェストである。各機関の Web サイトに置かれたマニフェストをビューアへドラッグ&ドロップすれば、その作品が読み込まれる [UC-002 §顔コレ構築のワークフロー]。そのため、IIIF で公開されている画像であれば、どの機関のものでも同じ手順で読み込める [UC-041 §顔コレの構築過程]。

公開側の記述が閲覧の挙動を決める

公開側の指定は、そのまま閲覧の挙動に表れる。和書と洋書ではページをめくる方向が逆になるが、IIIF には「どちら側にめくるか」(viewingDirection)を指定する機能があり、同じビューアで両方を閲覧できる [UC-001 §IIIF画像の閲覧]。

標準の枠組みで扱いにくい資料もある。高解像度の気象衛星画像のような時系列資料では、「前」「次」がページ送りではなく時間の移動になる。この資料は Timeline API と Cursor API を独自に拡張して公開されており、その拡張に対応したビューアでしか表示できない [UC-001 §IIIF画像の閲覧]。標準の枠組みに収まる資料と独自拡張に依存する資料とでは、使えるビューアが分かれる。相互運用性は、公開側が標準の範囲で記述しているかどうかに左右される。

機関をまたいで資料を並べて見る

IIIF の相互運用性は、機関の枠を越えて資料を並べて見ることを可能にする。

一つは、画像を複製せずに参照する構成である。江戸マップでは、もとの江戸切絵図は国立国会図書館デジタルコレクションの IIIF 画像で、CODH はその画像をコピーせず国立国会図書館から取得し、町名や施設名を重ねるオーバーレイ情報だけを作成している [UC-001 §地図へのアノテーション]。利用者が付加情報を作って公開し、もとのデータは提供元から取得する使い方である。

もう一つは、異なる機関の資料を同じビューアで読み込める点である。どの機関のマニフェストでも、ドラッグ&ドロップという同じ手順で読み込めるので、機関ごとに別の閲覧環境を用意する必要がない [UC-041 §顔コレの構築過程]。

こうした大規模なデータ収集が可能になった背景には、多くのミュージアムやライブラリによる高解像度画像の公開がある。IIIF の相互運用性は、日本でも他の国でも同じ技術でデータを集められる形で、組織横断的かつ全球的な大規模データ収集を可能にした [UC-040 §知見と今後の展望]。切り出した部分を集め直す使い方については、「部分を切り出す」を参照。

相互運用の前提として揃えるもの

資料を機関横断で並べるには、公開側が IIIF で資料を公開していること自体が前提になる。そのうえで、揃えるべき事柄は記事から次のように読み取れる。

  • データの持ち方:画像を手元に置かず、提供機関が公開する画像を参照し、自分のデータとしては付加情報だけを持つ構成である [BP-001 §画像は複製せず領域とメタデータを持つ]。
  • 公開側の記述の範囲:標準の範囲で記述された資料は同じビューアで扱えるが、独自拡張に依存する資料は対応するビューアでしか表示できない [UC-001 §IIIF画像の閲覧]。

メタデータの記述水準にも手がかりがある。メタデータは、誰が使うかによって求められる水準が変わる。自分や自組織のためだけの利用なら相互運用性はあまり重要ではないが、一般的・専門的な利用者による「流通」を想定するなら、相互運用性を考慮した形式や、分野ごとの詳細なメタデータが必要になる [UC-021 §メタデータをめぐる論点:利用者・項目・専門性]。機関をまたいで資料を並べて見る使い方は、まさにこの流通にあたる。なお、Presentation API が与える記述情報は人が読むためのもので、検索エンジンによる索引付けを意図した記述は対象に含まれない 2。マニフェストの記述だけで機械的な発見や検索が成り立つわけではない。

IIIF の公式仕様は画像の提供者側の視点で書かれており、集める・並べる・付加情報を重ねるといった利用者側の視点は、独自に拡張した仕組みで補われている [UC-001 §キュレーションプラットフォームとキュレーションAPIの区別]。

参考資料

[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

この節へのコメント

  • まだコメントはありません。

2.3 部分を切り出す

画像資料の一部を切り出して集め直すと、一点の資料の内側に分け入った比較が、機関をまたいで可能になる。顔のように特定の部分を多くの作品から集めれば、描き方の違いを一覧で確かめられる。本節では、何を単位に切るか、何を記述するか、集め直した部分をどう扱うかを順に述べる。IIIF の仕組みそのものは節「画像の流通基盤」を参照。機関をまたぐ横断検索と索引化は探す側の担当なので、節「資料をさがす・集める」を参照。

何を単位に切り、何を記述するか

切り出しの単位は、研究の問いが決める。顔コレ(顔貌コレクション)は、近世の絵巻・絵入本を中心に、さまざまな機関が IIIF で公開する作品から顔の部分を切り抜いて集めた事例である [UC-041 §顔貌コレクション(顔コレ)とは]。対象は顔に限られない。江戸時代の商人の広告や版面を切り取った江戸買物案内、名所案内から名所の画像を切り取った江戸観光案内も、統一的なメタデータを付与して整理した同様の試みとして公開されている [UC-041 §ICPを活用した展開]。一つの作品の内側から同じ人物の部分だけを集めたキュレーションや、肖像部分を集めたキュレーションの例も挙げられている [UC-001 §IIIF Curation Platformとは何か]。

IIIF の枠組みでは、切り出した部分はキュレーションリストとして記述される。キュレーションとは、あるテーマに沿ってコンテンツを集め、適切な順番に並べ、新たなコンテンツとして提示・共有する活動である [UC-001 §IIIF Curation Platformとは何か]。リストは、複数の資料(マニフェスト)からそれぞれ切り出した画像領域を、メタデータとともに1ファイルで管理できる。データ管理が容易になり、長期保存にもつながる点が利点として述べられている [UC-003 §まとめ:相互運用性と管理の容易さ]。

キュレーションの作成と保存

作成の手順は単純である。画面上の切り取りボタンで矩形領域を指定し、お気に入りに入れると、欲しい画像がキュレーションリストに溜まっていく。領域を切り取ってお気に入りに入れるだけで集められる点は、IIIF Curation Viewer の独自機能とされる [UC-001 §IIIF画像のキュレーション]。集めたキュレーションは JSONkeeper に保存でき、上書き更新も選べる。ログインしていれば他人による上書きを防げる。保存した内容は URL を共有すれば他者も閲覧でき、再び IIIF Curation Viewer で開ける。ただし保存はできても検索はできず、検索には IIIF Curation Finder の設定が別途必要になる [UC-001 §IIIF画像のキュレーション]。

保存したあとの管理には役割の異なるツールが使われる。ログイン状態でエクスポートしたキュレーションは IIIF Curation Manager で一覧・編集・削除でき、個別のメタデータの追加や変更は IIIF Curation Editor が担う。展示には IIIF Curation Player があり、画像に付けたメタデータを重ねて表示でき、スライドショーでコマを自動再生することもできる [UC-001 §IIIF画像のキュレーション]。切り出し・編集・管理・展示を役割の異なるツールに分担させ、同じキュレーションのデータ形式でつなぐ構成が、複数の実践に共通している。ただし IIIF Curation Editor は大規模な編集には向かないことが注意点として挙げられている [BP-001 §工程ごとにツールを使い分ける]。

アノテーションの付け方

切り出しただけでは、集めた部分は並べて見る材料にとどまる。顔コレの特徴は、すべての顔貌に統一的なメタデータを付与した点にある。性別・身分・向き・原典・所蔵機関といった項目を揃えることで、横断的な検索と数の確認が可能になる [UC-002 §顔コレ構築のワークフロー, UC-041 §顔貌コレクション(顔コレ)とは]。

メタデータの付与には、対象についての専門知識が欠かせない。予備知識のない人には単なる男性の顔に見えるものが、美術史の観点から見れば、鬼の正体を現す前の酒呑童子と分かる場合がある。それを分かる人がキーワードを付すことで、複数の絵巻を横断して酒呑童子の顔貌を確認できる [UC-041 §顔コレの構築過程]。

8,000を超える顔貌に項目を一つずつ入力すると作業量が膨大になる。そのため、キュレーションの JSON を表示して空のメタデータ項目を一括置換で挿入する工夫が採られている。複雑な置換には外部エディタを経由することもある [UC-002 §顔コレ構築のワークフロー]。

機械と人手を組み合わせた切り抜き

切り抜く対象が大量にある場合は、検出を機械に任せ、人が補う方法がある。『遊行上人縁起絵巻 清浄光寺甲本』は10巻本で、多人数が登場する場面が何度も現れ、2,000を超える顔貌が存在する。具体的な分析を目的とした研究では、ある程度の期間で結論を出すことが求められるため、切り抜きの速度を上げる必要があった [UC-041 §『遊行上人縁起絵巻 清浄光寺甲本』への手法の適用]。

そこで、顔コレデータセットを訓練データとして画像検出器に学習させ、甲本の版面のどこに顔があるかを調べた。顔コレの中心は江戸初期から中期の作品であり、14世紀の作品とされる甲本とは様式も顔の描き方も異なるため、難しいと見込まれていた。それでも約70%の顔貌を自動検出でき、人が囲むのは残りの30%で済んだ。人が密集している箇所でも、数人に1人を取りこぼす程度で、ほぼ正確に位置を検出したという [UC-041 §『遊行上人縁起絵巻 清浄光寺甲本』への手法の適用]。検出精度は、顔コレデータセット自体を対象にした場合で約80%、時代の異なる作品に適用した場合で約70%と報告されている。3分の2の検出を機械に任せられれば、人が顔を切り取る作業量は3分の1に縮む [UC-040 §機械学習による顔検出]。

手順としては、検出は機械、メタデータの付与は人という分担になる。切り抜いた顔貌へのメタデータ付与は、美術史的な姿やアトリビューションを確かめながら、人の目で一つずつ行われた [UC-041 §『遊行上人縁起絵巻 清浄光寺甲本』への手法の適用]。機械による検出の扱いは、節「特徴抽出と様式分析」を参照。

マイクロコンテンツ化とは何をすることか

デジタル化された人文学資料の一部を、特定の目的と粒度で整理し直して研究に使える形にすることを、報告者の研究チームはマイクロコンテンツ化と名付けている。IIIF に則ってデジタル化された資料から部分を抽出・収集し、メタデータを付与したうえで、横断検索・一覧化・研究活用につなげる流れである [UC-002 §人文学資料のマイクロコンテンツ化]。

これを手法として一般化したのが GM 法である。顔貌を切り抜き、メタデータを付与し、一覧化した部分を平面上で整理するという一連の作業に付けた名称で、様式研究者 Giovanni Morelli の名と、切り取った部分をよく見ることを意味する Gazing Microcontents を重ねている [UC-041 §手法の一般化としてのGM法]。従来、様式分析のために写真カードを並べ直したり分類し直したりしてきた作業を、デジタル環境で大規模化・効率化し、情報を付加できるようにしたものと位置づけられている [UC-041 §手法の一般化としてのGM法]。

集め直した部分を整理する道具として、IIIF Curation Board がある。画像を平面上に自由に移動させ、KJ 法のように分類できる。範囲選択した画像の自動整列、グループを囲む枠線、色つきのシール、付箋といった補助機能もあり、色分けの意図を凡例として示すこともできる [UC-002 §IIIF Curation Boardによる画像整理]。700を超える僧侶・尼僧、あるいは500を超える顔貌を平面上で整理する作業は紙の上では物理的に難しく、こうしたデジタル上の整理機能が実現を支えている [UC-002 §『遊行上人縁起絵巻』の様式分析への応用]。

多人数で集合的に集める

切り出しは多人数で分担できる。顔コレは複数の作業者が分担して構築しており、各作業者がメールアドレスと任意のパスワードでログインし、管理者が各アカウントのキュレーションを横断的に確認する形で進められた [UC-002 §顔コレ構築のワークフロー]。Google や Facebook のアカウントでのログインは、作業者の個人アカウントを管理側が把握することになるため、共同作業ではメールでのログインが推奨されている [UC-002 §顔コレ構築のワークフロー]。切り抜き作業では、大学院生が非常に多くの顔貌を切り取ったとされる [UC-041 §顔コレの構築過程]。

参加者が集まってキュレーションの視点を出し合うイベント「キュレーソン」も実施されている。基本操作をレクチャーしたうえで各自が自由にキュレーションを行い、互いに解説し合う。ある研究室での実施では、髷に注目したもの、背景の植物に注目したものなど、同じ研究室の中でも視点の異なる成果が生まれた [UC-002 §キュレーソン:ICPを使ったグループワーク]。大人数で実施して後日まとめる場合は、運営側が共通のアカウントを用意して全員にそれでログインしてもらうと、すべてのキュレーションが一つのアカウントに集まり、公開やアーカイブがしやすくなる。これは、上の共同作業での個別アカウントとは逆向きの運用である [UC-002 §キュレーソン:ICPを使ったグループワーク]。

集め直した部分を数え、比べる

統一的なメタデータが付いていれば、集めた部分を検索するだけでなく数えることもできる。顔コレでは、講演時点で顔貌が全部で8,845件あり、男性が圧倒的に多いことが数として確認できる。テーマを選ばずに各機関の公開作品を網羅的に取り込めば男性が増えていくのではないか、というのが講演者の見立てである。顔の向きでは、斜めを向いた顔が圧倒的に多く、正面は描きにくいといったことも確かめられる。美術に携わる人間が直感的に感じていることを、数量的に再確認する助けになるとされる [UC-041 §顔コレの活用]。メタデータと画像座標は、検索用の API から一括して取得することもでき、男女の比率のような統計的な検討に使える [UC-002 §メタデータ検索と派生キュレーションの作成]。

比べる作業は、切り出した顔に標識を付けて並べることで成り立つ。たとえば男女の標識を付けて IIIF Curation Board に並べれば、僧侶と尼僧の顔の描き分けを確かめる比較ができる [UC-041 §デモで示した僧侶と尼僧の描き分け]。この比較の結果と、そこから導かれる様式や分担についての解釈は、節「特徴抽出と様式分析」を参照。

既存のキュレーションから派生キュレーションを作る

既存のキュレーションから、新しいキュレーションを派生させることができる。検索結果から気になる顔貌をリストに登録し、エクスポートして派生キュレーションを作る機能があり、複数の作品から似た顔貌を集めて比較するという、美術史の古典的な様式分析の手法に対応する [UC-002 §メタデータ検索と派生キュレーションの作成]。

教育の場面では、この派生が追体験の手段になる。ある絵巻専用の顔コレを構築して検索用のメタデータを付与し、学生が先行研究で比較対象とされた顔貌を手がかりに、絵巻の中から典型として近い顔貌を探す。考察の結果は派生キュレーションとして作成し、グループごとに共有する。研究の第一線で行われている様式分析の手続きを、ツールに置き換えて学ぶ構成である [UC-002 §『石山寺縁起絵巻』を用いた美術史教育プログラム]。

派生キュレーションを作る意義は、一度集めた部分が使い捨てにならない点にある。他の人が作ったキュレーションを出発点に、別の問いに合わせて集め直せる。集めた部分に文章を添えて展示として提示することも可能で、description 項目に記述した文章は、キュレーションを読み込んだ IIIF Curation Player で画像とともに表示できる [UC-002 §キュレーソン:ICPを使ったグループワーク]。

この節へのコメント

  • まだコメントはありません。

2.4 文字を読む

画像に写った文字を読む作業は、くずし字の認識、版面の解析、字形の比較、翻刻へと連なる。どの段階にも精度の限界があるため、結果をどう測り、誤りが残る前提でどう扱うかが全体を貫く問いになる。

認識と版面解析の実際——嵯峨本の古活字分析

くずし字認識モデルを版面の解析に使った例が、嵯峨本の古活字分析である。AIくずし字認識モデルRURIで文字の矩形を認識し、その矩形から版面の傾きを推定して補正する。続いて行を検出してグリッドを推定し、最後に筆線とグリッドの交差を確認して、そこで分割できるかを判定する三段階の構成をとる [UC-043 §活字ブロックの自動分割]。前提は、ブロックの高さが1ユニットの整数倍であること、ブロックの間に空きがないベタ組みであることの二条件である。この条件が崩れる資料には別の設計が要る [UC-043 §活字ブロックの自動分割]。

この事例は、精度の数値がどの条件で出たかを添えて報告する例にもなっている。分割の正確さはF1スコアで示される。これは、機械が引いた分割位置のうち、正解の位置と合うものがどれだけあるかを測る指標である。人手で書いたコードでは0.8599で、結果としては良いものの、筆線を切る誤りや空白を切る誤りが残っていた。マルチエージェントシステムSakana Fuguに分割処理の仕様と、人手で注釈した20ページの正解データを与え、AIがコードを書き、20ページで確認し、誤りをフィードバックするループを回した。こうして得たコードを、正解データに使っていない残り303画像に適用した結果が0.9902である [UC-043 §活字ブロックの自動分割]。数値は、正解データの枚数と評価に使った画像の範囲を添えて初めて意味をもつ。ただしこの精度は嵯峨本に特化した条件で得られたもので、他の資料への一般化は課題として残る [UC-043 §知見と展望]。

囲った領域内のくずし字をすべて読む多文字認識サービスとしてKuroNetがあり、1枚の認識は1〜3秒程度で終わる。結果はIIIF Curation Viewerの文字マーカーで表示され、原画像と比べながら読める [UC-001 §くずし字認識とアノテーション]。ビューアの仕組みは「画像の流通基盤」を参照。認識モデルの選択は読解工程の設計の一部であり、「AI で問う・読む」が扱う。

字形の比較——同じ活字による刷りをまとめる

文字を認識するだけでなく、字形そのものを比べて物理的な活字へさかのぼる試みがある。同じ文字の二つの刷りは文字として常に似ているため、手がかりはインクが一致しない部分の形になる。同一の活字による刷りでは輪郭に沿った細い縁だけが異なり、別の活字なら筆画そのものの位置が違う [UC-043 §活字ブロックの同定]。

比較にはssim_ink(筆線の一致度)とdiff_blobs(余ったインクの形)の二測度を使い、ロジスティック回帰で一つの数値にまとめる。その数値をもとに制約付き平均連結の凝集型クラスタリングを行い、平均類似度が0.85を超える組み合わせがなくなるまで併合する。「手」の字では37の刷りが4本の活字にまとまった [UC-043 §活字ブロックの同定]。

検証には刷られた紙の構造を独立した手がかりとして使った。1枚の紙(丁)は一つの版から一度に刷られ、1本の活字はそこに一度しか置かれない。クラスタリングにはページ(半丁)の情報を与えるが丁の情報は与えない設計のもとで、同じ見開きの向かい合うページでは11,411ペア中227件が同じ活字にまとまり、同一丁では11,034ペア中1件にとどまった [UC-043 §活字ブロックの同定]。この差は、クラスタリングが丁の構造と整合していることを示す。同定した活字ごとに刷りを重ねて平均すると変動するインキングや圧力の効果が消え、この本からは1,601の印刷面が復元された [UC-043 §活字面の復元と組版の復元]。

同定の暫定結果では、シングルトンが3,467(40.8%)残っているが、多めに見積もられている可能性があり、改良は続いている [UC-043 §活字ブロックの同定]。

組版の構造を読み取る

活字の同定は組版の分析につながる。嵯峨本では1行の高さが17ユニットに固定され、短い行を詰め物で埋めることはしない。調整はテキスト側で行われ、背の高い活字に載せて1ユニットを稼いだり、連綿の活字で節約したりする [UC-043 §活字面の復元と組版の復元]。全書で88.3%の行が17ユニットちょうどに収まり、超える行はない。ブロックのユニット数と彫られた文字数は93.5%で一致し、少ないものが3.6%、多いものが2.9%という内訳も、こうした工夫から説明できる [UC-043 §古活字データセットV2]。

認識結果には誤りが残る

機械の認識結果をそのまま成果とせず、ビューア上で原資料に重ねて人が確認・修正できる状態に戻す構成を、くずし字認識の実践事例は組み込んでいる [BP-001 §機械の認識結果を人手の確認に戻す]。KuroNet Text Editorで読み順を行内・行間で手動指定してテキスト化する例がある。もう一つの例では、くずし字OCRと自動読み順推定で得た行単位テキストと、人手で起こした『校異源氏物語』各ページの先頭行との編集距離を計算し、概ね90%程度の精度で出る対応箇所候補をマーカー表示で人手確認している [BP-001 §機械の認識結果を人手の確認に戻す]。

ここで精度の目安に使われているのは編集距離にもとづく一致で、機械の行テキストと人手翻刻という二つの文字列を比べた値である。先に見たF1が分割位置と正解の位置の一致を測るのとは、何と何を比べたかが異なる。どちらの数値も、機械が出した結果のどこまでを信頼し、どこから人が確認するかを決める材料として使われている。人手の作業と機械処理は一方向ではなく、互いの入力になっている。

マルチモーダルLLMを使うHumanitext OCRは、資料の特徴と抽出したい内容をプロンプトに書くだけで動き、資料ごとの事前学習やテンプレート設定を要しない。テキストは行単位で座標とともに取り出されるため、原本画像と行テキストが一対一で結びつき、校正ビューアで行ごとの目視校正と共同校正ができる [UC-038 §三つの公開サービス]。著名な校訂版を忠実に転写するとコピー防止機能(Recitation)に検知されて出力がブロックされることがあるが、各行に使い捨てトークン付きの行番号を付けて出力させ、後段で取り除くという実装で対処している [UC-038 §三つの公開サービス]。誤りが残る前提での工程設計そのものは「AI でデータを作る」が扱う。

翻刻と字体——どこまで原文を残すか

翻刻とは判読して活字に起こすことだが、原文の字体や誤字をどこまで残すかは目的によって変わる。読解の工程には、字を読むことに続いて、誤りの向こうにある正しいテクストを読む段階がある。誤字をそのまま記録するか、読みを補って正しいテクストを想定するかによって、翻刻テキストが後の読解の段階へ何を渡すかが変わる。翻刻の判断は、この段階との最初の接点になる [UC-039 §文献を「読む」とはどういうことか]。読解の段階の整理は「AI で問う・読む」を参照。

どちらを選んでも、判断を後から確かめる手がかりは要る。Humanitext OCRのように原本画像と行テキストを一対一で結びつけて目視校正できる仕組みでは、誤りを原本に戻して確認でき、残すか補うかの判断を検証できる [UC-038 §三つの公開サービス]。

認識と同定の成果を再利用する——そあん(soan)

古活字の分析で得た画像を、現代日本語のテキストをくずし字の版面に組む仕組みに転用した例がそあん(soan)である。形態素解析でテキストをトークン列に分けて候補となる古活字画像の組み合わせを作り、続いて1行の文字数と行間からレイアウトを確定する。語の境界で改行するためトークン情報が要る点に、組版の構造への理解が反映されている [UC-043 §そあん(soan)による古活字の再生]。

くずし字学習への応用では、好きなテキストから学べるので文字だけに集中できる。そあんで組んだ教材を1年生の授業で使い、有名な台詞で学生の関心を引いた報告がある [UC-043 §そあん(soan)による古活字の再生]。講演者はこの取り組みを、過去の本をできるだけ忠実に作り直す「復元」と、現代の人が使える形で遺産を作り直す「再生」に分けて説明する。そあんが目指すのは再生であり、嵯峨本にない英語のアルファベットを追加したのもそのためである [UC-043 §そあん(soan)による古活字の再生]。字形の分析結果をどう使うかは、どちらを目指すかで変わる。

この節へのコメント

  • まだコメントはありません。

2.5 写真という資料

写真を資料として扱うとき、問題は二つに分かれる。写っているものをどう読み解くか、そして、読み解いた結果を撮影によってどう確かめ、積み上げるかである。ここでは、古写真の同定、共時的な写真と通時的な写真の違い、同一構図撮影と参照写真の役割、撮影を支援する仕組みの設計、写真を撮影者のまなざしの記録とみる見方を順に述べる。

古写真の同定:何が写り、どこで撮られたか

古写真を資料として使うには、まず何が写っていて、どこで撮られたかを確定する作業が前提になる。この作業に用いられる手がかりは、事例によって異なる。

撮影場所の同定は、地図との対応づけで進む。北京の古写真の事例では、巨大な古地図の上に写真を置き、写真に写る建物や対象物を地図上の地点と一つずつ対応づけて撮影地点を特定している。建物に見えたものが通りの上に建てられた仮設の建物だったと判明した例もある [UC-016 §地図と組み合わせた過去の景観の再現]。京都の市電写真では、撮影地点を地図上のピンとリンクさせ、現在のストリートビューと並べることで、過去と現在を簡易的に比較できる [UC-005 §京都の鉄道・バス写真データベースの構築]。

シルクロードのトルファンでは、探検隊の古写真と現在の景観を照合して遺跡を同定している。その方法は、古写真・地図・衛星写真・遺構平面図を組み合わせることにある [UC-008 §古写真を用いた遺跡同定の方法論]。古写真は第1次から第4次までの探検で記録として撮られたが、整理メモやキャプション、日記が残っておらず、撮影対象も撮影地も不明で、写真自体も不完全にしか残っていない。出版された書籍に載る写真だけでは数も解像度も足りず、収蔵されている原資料にあたって全体像を調べる必要があった [UC-008 §古写真を用いた遺跡同定の方法論]。国際協力の体制は、別の節「文化遺産と国際協力」が扱う。

同定の個々の場面でも、手がかりの置き方が異なる。勝金口の寺院は写真が多く残っていたため、おおよその場所を予想して近くまで案内してもらってから自分たちで探した。現地は地域の人口が約10倍に増えて一帯がぶどう畑に変わっており、手前では高速道路の工事も進んでいた。次に訪れたときには同じ写真を撮れなくなる可能性が高い状況である。環境が変わった地点でも位置を確定する情報は価値を持つ。所在がわからないために発掘できない遺跡があるからである [UC-008 §遺跡同定の事例]。高昌故城では、ロシア隊の写真がより広い範囲を写していたため、方角の異なるドイツ隊の古写真と照合した。どことどこが対応するかの特定は容易ではなかったが、拡大して壁面の崩れた箇所のような細部を突き合わせれば対応点を見いだせた。そうして得た点を基点に、建物の構造や壁画の位置、建物の所在地を整理できる [UC-008 §遺跡同定の事例]。

現地で構図を合わせる作業そのものが、同定の証拠になることもある。ドイツ隊の書籍では仏教寺院とされた地点が、現在の現地の記録では19世紀の建物とされていた事例では、食い違いを言葉で説明しても理解を得にくく、証拠となる写真を突き合わせて示すしかなかった。現地の人に「もう何も残っていない」と言われた遺跡も、同一構図の写真で対応関係を確かめると残っていた [UC-008 §遺跡同定の事例]。

地域の知識が鍵を握る場合もある。京都の市電写真のデータベースでは、専門の異なる研究者に市電の専門家と市役所の職員が加わり、議論しながら撮影場所を同定した。たとえば北野線沿いのバス車庫がもとは市電車庫だったという知識が、場所を突き止める手がかりになる。この同定作業は、写真情報を知らない人にとっては、その場所への理解と歴史的認識を深め、地域の価値を再評価する機会にもなる [UC-005 §京都の鉄道・バス写真データベースの構築]。

共時的な写真と通時的な写真

写真を並べる方向は二通りある。ある一時点の複数の写真を地図の上に集めて、その時点の都市景観を再現する方向(共時的な写真)と、同じ場所の異なる時点の写真を比べて変化を読む方向(通時的な写真)である [UC-016 §地図と組み合わせた過去の景観の再現]。

共時的な写真の例は、先の北京の事例である。古地図に古写真を対応づけ、一時点の景観を再現した [UC-016 §地図と組み合わせた過去の景観の再現]。ここでの写真は、空間的な文脈に置かれて初めて読めるようになる。視覚資料それ自体にも情報はあるが、空間情報を結びつけることでより深い解釈が可能になる [UC-016 §視覚的・空間的な歴史資料という視点]。

同じ主題の写真群でも、共時的に扱うには限界がある。華北交通の写真アーカイブは3万5千点を超えるが、写真は都市の一部を切り取るにとどまり、街並みを連続的に記録したものではない。しかも場所への対応づけが、元資料のメタデータに基づく駅単位にとどまり、地点レベルには至っていない。そのため過去の景観の再現には十分に有効とはいえない、と講演者は述べている [UC-016 §North China Railwayの写真アーカイブとAIタグによる検索]。

通時的な写真は、同一構図撮影によって作られる。古写真と同じ構図で現在を撮ると、東京のある地点では建物が大きく変わった一方で堀はほとんど変わっていない、といった対比が見える [UC-016 §Memorygraphアプリによる景観の変化の把握]。同一構図の写真を画素レベルで比べると、人が気づかないような微細な変化が明らかになることもある。この営みを講演者は、変化する景観の中に不変なものを見いだすこととして、景観を「読む」と呼んでいる。ただし、読み取りの巧拙は、その場所や景観についての知識に依存する [UC-016 §景観を「読む」ための新しい技術]。

通時的な写真には、変化の性質に応じた使い分けがある。長い時間の経過による景観変化には今昔写真、災害のように非連続的な変化には前後の比較(ビフォーアフター写真)、緩やかに進む変化には定点観測写真が向く、という整理が示されている。ビフォーアフター写真は、阪神・淡路大震災のように大きな変化があった場合に、被害の規模や復旧・復興の過程を可視化できる。定点観測写真は、植物の開花や成長、建設工事の進捗、季節による風景の変化の記録に向く [UC-004 §同一構図撮影の6つの種類]。

同一構図撮影と参照写真の役割

同一構図撮影では、古写真などの基準画像が参照写真の役割を担う。この写真は、撮影者が現在の景観を合わせる目標であると同時に、撮られた結果と対にして残る比較の片方でもある。

参照写真を使わない撮影は負荷が高い。古写真を短期記憶に保持し、ファインダー越しの像と見比べ、ずれていれば自分が移動して合わせなければならない。3次元のシーンが自分の移動でどう回転して見えるかを頭の中で予測する作業(メンタルローテーション)は、人間にとって得意ではない [UC-004 §開発の背景:手動による今昔写真撮影の困難]。紙焼き写真を手に持って再撮影する方法でも、写真の裏側の景観が隠れてしまい、2枚を別々のデータとして扱えない [UC-004 §拡張ファインダーとしての設計:ARや写真再撮影との比較]。

参照写真をファインダーに半透明で重ねると、この作業が大幅に楽になる [UC-016 §Memorygraphアプリによる景観の変化の把握]。重ねるのが参照写真であれば、撮影の目的が変わっても同じ仕組みで対応できる。ファインダーに重ねる画像を入れ替えるだけで、古写真による今昔写真のほか、聖地巡礼写真(作品中の場面との比較)、位置証明写真(その場所に行った証明)、撮影シミュレーション(有名な写真の撮影位置・カメラ・画角の再現による意図の分析)などに使える [UC-004 §同一構図撮影の6つの種類]。

照合の難しさへの対処は、事例ごとに異なる。同一構図に合わせるには景観を読む力が要り、古写真と現在のあいだで何が変わり何が変わっていないかを判断できれば、変わらない要素に合わせて構図を決められる。地形のような変わりにくい要素や、文化的景観の知識が手がかりになる [UC-004 §利用上の留意点:難易度のギャップと景観を読む力]。

撮影を支援する仕組みの設計

撮影を支援する仕組みの代表が、同一構図撮影のカメラアプリ「メモリーグラフ」である。設計上の要点は三つに分けられる。過去の写真をファインダーに重ねること、撮影地点へ導くこと、撮れた写真を束ねることである。

ファインダーに過去を重ねる

メモリーグラフは、カメラのファインダーを拡張する仕組みとして設計されている。通常のファインダーに出る構図グリッドの代わりに、古写真などのガイド画像を半透明で表示し、それに合わせて現実世界を撮影させる。ガイドを入れ替えれば、前節に挙げた複数種類の撮影を同じアプリで行える。撮影時のセンサーデータ(位置情報、方位など)も併せて保存できるので、ガイド写真の撮影位置や方向を推定する材料にもなる [UC-004 §拡張ファインダーとしての設計:ARや写真再撮影との比較]。

拡張現実(AR)とは設計上の立場が異なる。ARでは過去の写真は向こう側の世界の場所に固定され、カメラを動かすと写真の見え方が変わる。用意されたコンテンツを受動的に鑑賞する道具である。これに対しメモリーグラフでは、カメラを動かしてもファインダー上の写真は変わらず、撮影者が写真と実世界の座標系の一致を能動的に探索する参加のための道具になる。重ねた2枚は、それぞれ独立したデータとして扱える [UC-004 §拡張ファインダーとしての設計:ARや写真再撮影との比較]。

撮影地点へ導く

写真を合わせる以前に、どの地点へ行けばよいかという問題がある。メモリーグラフには、撮影地点へ導く仕組みがアプリの機能として加えられている。古写真上のどこにポイントを置けばよいかを示す撮影時の目印、初めての利用者に向けた道順表示、透過調整の案内がその例である [UC-030]。長崎での導入の経緯と参加者の反応は、節「地域とともに進める」を参照。

撮れた写真を束ねる

メモリーグラフは、基準となる画像(シーン画像)とそれに合わせて撮った写真の集合を「シーン」とし、シーンを順序つきで束ねたものを「プロジェクト」とする。個人で完結するマイプロジェクトと、複数人で共有する共有プロジェクトがあり、同じシーン画像に対して複数の人が撮った結果を集めると、誰がどこから撮影したかを比べられる。共有プロジェクトの作成ツールと閲覧ツールが別に用意されており、閲覧側では地図上に各シーンの撮影地点を表示し、シーンごとに撮影された写真を一覧できる [UC-004 §アプリの基本要素とプラットフォーム]。

束ねたデータは、それ自体が分析の材料になる。多くの人が同じ場所を訪れて最適な一致を探すと、撮影地点の報告が集まり、その平均から古写真の撮影地点を特定できる。現在の写真と古写真を比べれば、現在の建物のどの部分に過去の姿が保存されているかを推測する手がかりも得られる [UC-016 §Memorygraphアプリによる景観の変化の把握]。

束ねる設計には運用上の論点も伴う。写真の共有をめぐる感覚には個人差があり、一律の共有設定では対応しきれない。そのため、個人単位で閲覧範囲を制限できる「非表示」モードが設計に加えられた [UC-030 §写真共有機能をめぐる課題と対応]。

撮影者のまなざしの記録としての写真

同一構図撮影を重ねると、写真という資料の見方が変わる。講演者は、写真をカメラが世界を記録したものとしてだけ捉える見方に対し、カメラの後ろに撮影者がいるという視点を前景に置く。写真は撮影者による世界の記録であり、どこから、どんな姿勢で、どんなカメラで、どんな意図で撮られたかを抜きには考えられない、という立場である [UC-004 §メモリーグラフが投げかける問い:写真の再考と身体性]。

この見方に立つと、同一構図撮影は景観変化の記録を超える。曾祖父が撮った写真を題材に同一構図撮影を行えば、現在の景観を記録するだけでなく、かつての撮影者と場所と姿勢を共有する行為になる。植生や煙の量といった細部の違いから、撮ったのは別の時代の別の人物だと感じ取れるとき、写真が景観のコピーではなく撮影者のまなざしを記録したメディアであることが浮かび上がる [UC-004 §メモリーグラフが投げかける問い:写真の再考と身体性]。

資料の読みとしても具体的な発見がある。トルファンの遺跡調査では、同一構図の写真を撮る過程で、ドイツ隊のメンバーが高い場所に登って撮影するのを好んでいたことがわかった [UC-008 §遺跡同定の事例]。古写真の撮影位置を現地で追体験すると、撮影者の行動の癖が資料から読み出される。

この節へのコメント

  • まだコメントはありません。

2.6 三次元の計測と復元

実測に基づくモデルと推定に基づくモデル

三次元記録で最も重要な区別は、実測に基づくモデルと推定に基づくモデルのあいだにある。この区別は精度の高低ではなく、モデルが何を根拠に成り立っているかを問う。

実測に基づくモデルは、レーザー計測や測量で現存する対象を直接計測して作る。現存する遺跡については正確に作れる [UC-020 §実測と推定:2種類の3次元モデル]。ただし実測は、計測できる対象にしか適用できない。推定に基づくモデルは、計測できない対象を三次元化するときに用いる。2003年の地震でほぼ全壊したイラン・バム遺跡(アルゲ・バム)の復元は、その極端な事例である。現代の遺跡でありながら崩壊して計測できないため、衛星画像・写真・平面図・地形データ・記録・遺物・人々の記憶という種類の異なるデータを統合して、失われた形状を推定するほかなかった。それでも統合したデータには、どうしても欠ける情報が出てくる [UC-020 §実測と推定:2種類の3次元モデル]。

利用する側にとって、この区別は判断に欠かせない情報でもある。どこが実測に基づき、どこが推定で補われているかが記録されていなければ、モデルの信頼性を判断する手がかりがない。

近年の手法と、それが使える条件

レーザースキャニングと、複数の画像から三次元形状を復元するフォトグラメトリ・Structure from Motion(SfM)は、いずれも新しいデータを現地で取得できることを前提とする。バム遺跡の事例では、レーザースキャンや SfM のような全自動の手法は、新しいデータを取得できない以上、遺跡が現存しないバムでは使えなかったと記されている [UC-020 §レンダリングと自動化の試み]。この条件は、近年の手法を実測と推定の区別のどちらに位置づけるかを決める。現地で計測できる対象には実測の手法が使え、計測できない対象には推定に頼るほかない。

後年の実践として、ドローンを活用した記録や、観光客の写真から焼損した首里城を復元した例が挙げられている。記事はこれらを、当時のバム遺跡が直面した壁(解像度の低さ、カメラの種類の違い、修復による形の変化)とは別の、後年の成果として位置づけている [UC-020 §レンダリングと自動化の試み]。バム遺跡にも、NHK が1981年に撮影した7分間の空撮映像が残されていた。しかし解像度が低く、カメラの種類が違い、修復で形が変わっていたため、精度の高い復元は難しいと判断された [UC-020 §レンダリングと自動化の試み]。

点群を取得し、扱う

レーザースキャナーで取得した点群は、データが非常に重い。すぐに1ギガバイトから数ギガバイトのサイズになる。視点を対話的に変えながら見せるには、点群をかなり間引いて粗くする必要がある。フリーの点群ビューワーであるポットリーは、プログレッシブレンダリングによって、待たされることなく詳細な部分を後から表示する [UC-019 §Linked Data・360度VR・点群の取り組み]。

点群を取得してポリゴンに起こす取り組みもあり、レーザースキャナーを所有する大学の事例では、風洞実験室などの点群を、学生が実験の前に機材や手順を見ておく事前学習に使っている。目的は工学的に重要なもののアーカイブではない、と明記されている [UC-019 §Linked Data・360度VR・点群の取り組み]。点群は、何を目的に取り、どの粗さまで落とすかで扱い方が変わる。

参照データの質が復元の限界を決める

推定モデルの質は、利用できる参照データの質と量に直接左右される。バム遺跡では、外部機関(CNRS および ICHHTO)から写真測量学的な地図の提供を受け、建物の形状と位置についての大まかな参照データを得た。遺跡に思い入れの強い人々が観光で訪れる場所だったため、写真の提供も広く得られた [UC-020 §参照データと写真の収集]。

しかし2003年はスマートフォン登場前でデジタルカメラも主流ではなく、写真の多くはフィルム写真をスキャンしたもので、高解像度にならなかった [UC-020 §参照データと写真の収集]。標高データに写真を重ねて構造とテクスチャを得ようとする半自動モデリングも、位置合わせの難しさから成果に至らなかった。内部空間は写真がとくに乏しく、天井の形などは建築学的な推定で補うしかなかった [UC-020 §レンダリングと自動化の試み]。

推定を担う専門知識と作業分担

推定に基づく復元では、欠けた情報を専門知識で補う判断が随所に求められる。バム遺跡では、突起物・窓・門の形などをペルシャ建築として妥当かという観点から決める必要があった。当初はコンピューターの専門家がモデリング(遺跡の構造の構築)とレンダリング(モデルをもとにした画像・映像の生成)の両方を担い、遺跡の専門家は指示を出すだけだったが、うまくいかなかった。欠落部分を補う建築上の判断は、専門知識なしには下せないからである [UC-020 §モデリングとレンダリングの分担と精度・コストの調整]。

遺跡の専門家がモデリングを、コンピューターの専門家がレンダリングを担う分担に改めると、正確で、かつ表現として成立する出力が得られるようになった。誰が何を担当するかが、推定モデルの精度と妥当性に直接影響することを示す教訓である [UC-020 §モデリングとレンダリングの分担と精度・コストの調整]。

精度とコストのバランスも、推定モデルに固有の問題である。精度を上げると手作業が増えてコストが上がり、自動化するとコストは下がるが精度が落ちる。バム遺跡では、重要な部分は手作業で正確に、重要度の低い部分はできるだけ自動で、と使い分けた。都市的な規模のこの遺跡では、とくにコスト管理が重要だった [UC-020 §モデリングとレンダリングの分担と精度・コストの調整]。

どこを補ったかを記録するという未解決の課題

推定に基づくモデルでどこを補ったかの記録は、復元の透明性に直結する。バム遺跡のプロジェクトは三次元モデルへの注釈を試みたが、当時はうまくいかず、この領域は発展の余地が大きいとされている [UC-020 §プロジェクトの教訓と今後の問い]。補った箇所を明示的に記録することは、技術と実践の両面で未解決の課題として残る。メタデータの設計と管理については「メタデータ」を参照。

加えて、記録の対象そのものが固定していないという難題がある。修復で絶えず姿を変えてきた遺跡を、どの時点のモデルとして作るべきかという問いが残されている [UC-020 §プロジェクトの教訓と今後の問い]。三次元復元では、どこを補ったかに加えて、どの時点の姿を復元したかも記録の対象になる。完成したモデルをどう体験させるかについては「拡張現実と没入」を参照。

この節へのコメント

  • まだコメントはありません。

2.7 拡張現実と没入

三次元や画像を見る人の身体と結びつける試みは、ここで参照できる記事の範囲では、現地で古写真を現在の風景に重ねる体験、ブラウザ上で動かす三次元教材、360度VRカメラによる館内の追体験、物語に介入するVR演劇、過去の景観写真を現在の地図と並べる表示、遺跡のウォークスルー映像に分かれる。いずれも見せる内容は研究者や制作者が決めており、その見せ方を、現地で重ねる、視点を動かす、場所を移る、問いに答えるといった身体の動きを伴う体験として組んでいる。

古写真を現在の風景に重ねる体験の三つの局面

現地で古写真を現在の風景に重ねる体験は、「記憶」の働きの観点から三つの局面に整理されている。過去の古写真の当時の撮影場所を現在の場所で探す記憶探索(MH)、古写真と現在の撮影場所を重ねて仮想的に過去の記憶を現実化する記憶現実(MR)、古写真に重なる現在の写真を記録する記憶記録(MG)である [UC-006 §「記憶」概念の整理:MH・MR・MGと「像覚」]。

このうち身体と結びつく度合いが最も高いのは記憶現実である。見る人が現地に立ち、過去を現在の風景に重ねて体験するからである。体験の例としては、長崎バージョンの「長崎古写真ハンティング」(アンドロイド仕様)があり、のちに iPhone 仕様の汎用版として「メモリーグラフ」が登場している [UC-006 §「記憶」概念の整理:MH・MR・MGと「像覚」]。ファインダー上に基準画像を重ねる撮影支援の仕組みと設計については、詳細は「写真という資料」を参照。

古写真を重ねる体験について、姫野研究室は、既存の感覚語彙では捉えきれない認識の局面を含むとして、影像の記憶を扱う認識概念に「像覚」という用語を提案している。視覚・触覚・知覚など認識用語の体系に並べる試みとして、研究室のブレインストーミングから出された [UC-006 §「記憶」概念の整理:MH・MR・MGと「像覚」]。

ブラウザの中で儀式の進行を自分で進める

平安時代の宮中儀式(除目)を扱う教材は、WebGL(JavaScript の三次元CGライブラリ)と Three.js を使ったウェブコンテンツで、任意のブラウザで閲覧できる。タブレット端末やスマートフォンがあれば時間や場所に制限されずに学べる作りで、建物や登場人物の振る舞いに、静止画・説明文の表示、動画・音声の再生が組み合わされている [UC-019 §教材の機能と画面]。

操作は、マウスで視点を動かす、紫宸殿・陣座・清涼殿や鳥瞰図などあらかじめ設定されたカメラ位置へ移る、「前半」ボタンで陣座に大臣や大弁を登場させ、「次へ」ボタンで儀式を進める、というものである [UC-019 §教材の機能と画面]。見る人が視点を選び、儀式の進行を自分で進めるので、文章の記述を順に追う読み方とは理解の経路が異なる。学生からは、三次元CGアニメーションで建物や登場人物の振る舞いを見たことで、テキストを読むだけの場合よりも宮中の儀式の様子を深く理解できたという感想が寄せられている [UC-019 §教材の機能と画面]。

体験として成り立たせるには費用も要る。建物のデータが重く、初回のアクセスでは建物がすべて表示されるまで時間がかかる。一度アクセスするとキャッシュされるため、2回目以降はそれほど待たずに済む [UC-019 §教材の機能と画面]。ブラウザで動くことが「どこでも見られる」ことの条件であり、同時に初回の待ち時間という制約でもある。

360度VRカメラで館内を歩く

同じ部門が作成しているコンテンツには、360度VRカメラを使ったウォークスルーと、動画によるナビゲーションがある。中央図書館のナビゲーション版では、学生に360度VRカメラを頭に付けて館内を歩いてもらって収録し、視点を360度自由に変えられるようにしている [UC-019 §Linked Data・360度VR・点群の取り組み]。

画面左上のマップで経路をクリックすると、その地点に移動できる。館内に表示されているパネル画像とビデオ動画は、360度VR画像が表示される球体の中でも表示できる [UC-019 §Linked Data・360度VR・点群の取り組み]。見る人は歩く順序に縛られず、地点を選んで移り、見回し、その場の掲示物や動画に触れる。

物語に介入するVR演劇

もう一つの体験は、見る人が筋に介入するものである。立命館大学アート・リサーチセンター(ARC)のデータベース資源を二次活用し、『東海道四谷怪談』第二幕の世界を、ユーザー介入型のVR演劇として構築した事例がある。あんま宅悦になりきって「雑司ヶ谷四ツ谷町の場」で何が起こったのかを探るミステリー型のVRアドベンチャーで、小道具の調査とお岩AIとの会話から謎を追い、ユーザーの回答によって結末が分岐する [UC-036 §AX時代のDH:ARCアーカイブを活用したVR展示]。

構想は三つの柱からなる。登場人物との自由会話で物語が変化する演劇体験、キャラクターアバターの着用による認知・行動の変化を利用するプロテウス効果、ARC のデータベース資源の二次活用である [UC-036 §AX時代のDH:ARCアーカイブを活用したVR展示]。見る人が演目の外から眺めるのではなく、登場人物の位置に自分を置いて動く設計になっている。

素材には資料が使われている。3Dモデルは、浮世絵ポータルDBと催事型写真ポータルDBに蓄積された第二幕のお岩・伊右衛門の資料を参考にし、「四谷怪談図録」で着物の色味や髪形を確認したうえで、画像生成AIでTポーズを制作し、3Dに特化したAIでモデリングとリギングを行った。音声は、1923年(大正12年)5月に市村座で上演された公演の役者の声を大西SPレコードコレクションから取得して生成した [UC-036 §AX時代のDH:ARCアーカイブを活用したVR展示]。

この事例の語り手は、VRコンテンツは費用をかければ従来も作れたが、いまは一人でできて、日本文学を学ぶ学生が作品の中身を勉強したうえで作る時代になったと指摘する。筋の分岐は、四世鶴屋南北がこうした筋を作った可能性を示し、いま伝わる筋の価値を逆に検証できるのではないか、ともいう [UC-036 §AX時代のDH:ARCアーカイブを活用したVR展示]。

過去と現在の景観を画面で並べる

現地で重ねる体験とは別に、過去の景観資料を画面の上で現在の街並みと並べて見るやり方もある。「バーチャル京都」は、GIS と VR の技術で異なる時点の三次元 GIS を重ね、時間の次元を加えた四次元 GIS として構築されている [UC-015 §バーチャル京都と4D-GIS]。たとえば市電の写真は撮影地点を特定して路線沿いに地図化され、Google マップや Google ストリートビューと並べて過去と現在を比較できる [UC-015 §寄贈写真・市電写真・街路景観写真・絵葉書の地図化]。同じ場所の過去と現在を見比べられることは、没入が足すものの一つである。写真の同定の方法については、詳細は「写真という資料」を参照。

美しい映像が継続利用につながらなかった遺跡の例

体験として見せる仕組みが、継続して使われるとは限らない。バム遺跡の事例は、その費用と継続利用の課題を具体的に示している。ウォークスルー映像は美しい出来であったにもかかわらず、継続的な利用につながらなかった。データのオープン化は諸事情で難しく、対話型のVRサービスは提供の負担が大きすぎて、映像で見る形しか提供できなかった [UC-020 §プロジェクトの教訓と今後の問い]。

ここから残る問いは二つある。インタラクティブな利用に耐える品質を、外部・内部の空間ともに現実的なコストで提供できるか。オンラインでの情報の注釈や共有を、現実的なコストで実現できるか [UC-020 §プロジェクトの教訓と今後の問い]。映像の美しさと、見る人が操作して使える体験の提供とは別の問題であり、後者には制作側の負担がかかる。ブラウザ教材の初回の待ち時間と同じ種類の制約が、遺跡の事例ではサービス提供そのものを左右している。

没入が理解に足すもの、隠すもの

足すものとして読み取れるのは五点ある。現地で過去を現在の風景に重ねられること(記憶現実)、空間の中で出来事の進行を追えること(除目教材)、見る人が地点と視線を選べること(館内のウォークスルー)、登場人物の位置から筋に介入して結末を変えられること(VR演劇)、同じ場所の過去と現在を見比べられること(画面上の並置)である。儀式の様子についての学生の感想はその一例で、文章だけでは得にくい理解が得られたと報告されている [UC-019 §教材の機能と画面]。

隠すもの、あるいは体験に課される制約として、記事から導けるのは費用と継続利用の面である。美しい映像があっても、対話的な利用に耐える形で提供し続けるには負担が大きく、利用が続かない場合がある [UC-020 §プロジェクトの教訓と今後の問い]。

体験を組む側の責任については、AIによる処理で量が増えると誤りも増え、結果を確かめる責任は人間に残るという報告がある [UC-048 §限界と人間に残る責任]。AIで3Dモデルや音声を作るVR演劇のような制作でも、任せた部分を製作者が確認する必要があるという点で、同じ判断が働くと考えられる。

実測に基づく復元と推定に基づく復元の区別については、詳細は「三次元の計測と復元」を参照。

この節へのコメント

  • まだコメントはありません。

2.8 特徴抽出と様式分析

画像の様式分析は、美術史が写真カードを並べ替えて行ってきた比較を、切り抜いた部分を大量に並べる形に広げたものである。顔のような部分を取り出して並べると、一枚の画面を眺めるだけでは気づきにくい違いが、全巻にわたる傾向として現れる。部分の切り出しや集計の仕組みは「部分を切り出す」、横断検索は「資料をさがす・集める」に譲る。本節は、それらを様式分析に適用して何が言えるかに絞る。

部分を並べて様式を比べるという方法

顔貌コレクション(顔コレ)は、美術作品に登場する顔の部分を切り取って集め、様式研究に活用する実験的なプロジェクトである。収集には IIIF で公開された画像を用い、切り取った顔には統一的なメタデータを付与している [UC-041 §顔貌コレクション(顔コレ)とは]。この一連の作業を、研究チームは GM 法と名付けた。写真カードを並べ直し、分類し直してきた従来の様式分析を、デジタル環境で大規模化・効率化し、情報を付加できるようにしたものである。名称は、様式研究の泰斗 Giovanni Morelli と、切り取った部分をよく見ることを意味する Gazing Microcontents のダブルミーニングになっている [UC-041 §手法の一般化としてのGM法]。

対象の検出を機械に任せる範囲

顔の切り抜きという作業は機械学習で支援できる。顔コレの顔貌画像とメタデータは機械学習用のデータセットとして構築されており、未知の絵巻物から画面上の顔の座標を自動認識させる実験も行われている [UC-002 §顔コレデータセットと機械学習との連携]。検出の手順や精度は「部分を切り出す」に譲る。様式分析の側から見て重要なのは、機械が担える範囲に限りがあることである。

機械が担うのは検出までで、何を付与するかの判断は人が行う。予備知識のない人には男性の顔にしか見えないものでも、美術史の観点から酒呑童子だと分かる人が、キーワードを付与する [BP-005 §解釈の手がかりとしてのデータ]。また AI は学習したことを出力しているにすぎず、学習していないタイプの画像はまったく認識できない [UC-040 §機械学習とは何か]。何を学習し、何を正解できるようになっているかを常に考えながら使う必要がある。

したがって、機械の検出結果は結論ではなく、解釈のための手がかりとして位置づけられる。機械学習の価値は顔の切り抜きという労力の軽減にあり、データの解釈は専門家の精読に基づく、という整理が示されている [BP-005 §解釈の手がかりとしてのデータ]。

全数を並べて見えるもの——印象を確かめる

場面ごとの印象として捉えられてきたことを、資料全体で確かめられる形にする点が、この方法の中心的な価値である。顔を全数そろえれば、美術に携わる人が直感的に感じていることを数で再確認できる。件数や偏りの具体的な結果は「部分を切り出す」に譲る [BP-005 §網羅的なデータによる検証]。ここで述べたいのは、数では捉えにくい質的な違いも、全数を並べることで確かめられるという点である。

その例が、清浄光寺甲本における僧侶と尼僧の描き分けである。この時代の時宗教団は、男性の僧侶と女性の僧侶(尼僧)が一緒に旅をしながら布教する、定住しない教団だった。男女の区別が緩く風紀に問題があると、時の権力者から指弾される可能性があった。絵巻の制作者はそのことに留意し、同じ場所にいても男女が接近していないことを画面で強調している [UC-042 §顔貌の切り抜きによる僧侶と尼僧の比較]。

そこで顔をどう描くかが問題になる。原本のある絵巻を転写するときの原本に対する姿勢の問題であり、同時に、男性と女性をどう表象するかという絵師の技術の問題でもある。男性の僧侶に髭の表現を残すような記号的な表現が図像の解釈にあたるとすれば、表現のレベルでは、女性の顔の輪郭が卵型でつるっとしているのに対し、男性の輪郭はごつごつしているという違いが見られる [UC-042 §顔貌の切り抜きによる僧侶と尼僧の比較]。

こうした違いは、場面を見ればその場で分かる。しかし、全巻のすべての僧侶と尼僧を取り出し、絵師ごとにシールを貼っていけば、網羅的に分かるようになる。この作業は、絵師の様式、図像の解釈、原本に対する理解という複雑な問題を見ていく手がかりになる [UC-042 §顔貌の切り抜きによる僧侶と尼僧の比較]。僧侶と尼僧をすべて平面上に並べて整理することで、男女の描き分けに加え、絵師ごとの傾向の違いまで明らかになったとされる [BP-005 §網羅的なデータによる検証]。

様式の比較から制作の分担を推定する

10巻を超える絵巻を一人の絵師がすべて描くことはなく、親方クラスの絵師が率いる絵所が、助手を擁して制作した [UC-042 §絵師の工房と共同制作]。様式の違いは、そうした分担を推定する手がかりになる。

清浄光寺甲本は、先行研究によって全10巻が三つの類に分けられている。彩色・描線ともに標準的な一類、濃彩で装飾的な二類、淡彩による三類である [UC-042 §清浄光寺甲本の三つの画風と絵師の格]。この分担は、絵師の格式と結びついているという指摘がある。絵巻では、第1巻を最も格の高い絵師が、最後を二番目の絵師が担当するのが一般的である。この絵巻でも、前半の一遍伝は格式の順に担当されている。後半の他阿伝でも、最初と最後は二類の絵師が描いている。ただし、同じ工房に三人の絵師がいたのか、三つ別々の工房があったのかは、現状では判断が難しい [UC-042 §清浄光寺甲本の三つの画風と絵師の格]。

顔だけを切り抜くと、様式の違いの見え方が変わる。二類は樹木や草花が装飾的で近世絵画を思わせるが、顔を切り抜くと意外に古典的で、人物や景観の描写には一類と共通する基盤がある。三類は顔だけなら一類によく似ているが、衣は淡い彩色でコントラストが弱い [UC-042 §作品調査と高精細画像による三分類の再検討]。ここから、一類には14世紀初頭の画趣を再現し回帰する指向、二類には対象を明確化・意匠化する指向、三類には原本をやや簡略に転写する傾向が読み取られている。傾向は異なるが、共通するのは14世紀初頭の正統やまと絵への強い意識であり、三類はこれを解釈する三者三様の方向とされる [UC-042 §作品調査と高精細画像による三分類の再検討]。一方、詞書の筆跡分析は14世紀半ばから後半の書風を示した [UC-042 §「遊行上人縁起絵巻」諸本をめぐる研究状況]。これとあわせると、三類を隔たった時代に振り分けるのではなく、同時代の解釈の違いとして捉え直す見通しが開ける。

この比較は二つの水準に広げられる。工房間比較は、異なる類の絵師・工房の細部を比べるもので、顔のほか、樹木、岩や土坡、水景、建築物にも広げられる。工房内比較は、同じ類の中の微妙な画風の違いを見るもので、たとえば主要な部分と添景といった分担が対象になる [UC-042 §工房間比較と工房内比較]。「玄奘三蔵絵」は第1巻から第6巻までと第7巻から第12巻で画風が変わり、一見して分かる例である。「一遍聖絵」と「春日権現験記絵巻」は絹に描かれており、画絹の織成密度が同じ作品の中で一定である。そのため、顔や部分をスケールを揃えて等倍で比較すれば、作品内の微妙な差異を見つけられるのではないかとされる [UC-042 §工房間比較と工房内比較]。

遠読は精読の範囲を広げる

テキスト研究から借りた精読と遠読の対を画像に当てはめても、遠読は精読を置き換えるものではない。機械学習でデータセットの規模を拡大することは、従来より広い範囲での精読を可能にすると位置づけられている [BP-005 §解釈の手がかりとしてのデータ]。全数を並べることで確かめられる対象は、男女の比率や顔の向きの偏りのような数として表れる傾向から、僧侶と尼僧の描き分けや絵師ごとの傾向といった質的な違いまで幅がある [BP-005 §網羅的なデータによる検証]。

他方、データの解釈も機械が支援する遠読には、新たな可能性が広がる反面、方法論の危うさも共存している。リスクを認識しながら進める必要があると述べられている [BP-005 §解釈の手がかりとしてのデータ]。規模を変えて見るという立場そのものは、「遠読と精読」で扱う。

限界と可能性

得られた結果は結論ではなく、解釈の手がかりとして扱われる。何を付与し、結果が何を意味するかの判断は、対象を知る人が担う [BP-005 §解釈の手がかりとしてのデータ]。集める範囲についても、日本中の作品から集められるようになれば、作品の一般的な傾向がより明らかになっていくという見通しが示されている段階にある [BP-005 §網羅的なデータによる検証]。可能性としては、浮世絵の役者顔を「芸能」カテゴリに並べるといった構想もあり [UC-040 §顔画像データセットの展開とedomi]、顔コレのような枠組みを他の対象へ広げる方向が示されている。

この節へのコメント

  • まだコメントはありません。

3 データモデリングと可視化

データをどう捉え、どう構造にし、どう扱うかをまとめる。規模を変えて見るという立場から入り、そのための道具を順に見る。

3.1 遠読と精読

一点の資料を深く読む精読は、その資料に何が書かれているかを明らかにする。遠読は、大量の資料を同じ型の部分に分けて並べ、個々の資料からは見えない配列や分布を読み取る。両者は優劣の関係にあるのではない。規模を変えることで、見えるものと見えなくなるものを交換していると捉えるのがこの節の立場である。

部分を並べると、様式の比較の足場ができる

規模を上げるときの最初の操作は、資料を同じ型の部分に切り出し、大量に集めることである。顔貌コレクションは、絵本や絵巻のデジタル画像から顔の部分だけを切り抜き、「山伏」といったメタデータを付与して網羅的なデータセットにしたものである [UC-040 §顔貌コレクションとデータ駆動型人文学]。一度作れば、顔の様式を比較する美術史研究にも、顔の自動認識にも使える [UC-040 §顔貌コレクションとデータ駆動型人文学]。一冊の絵巻を精読しても得られない比較の足場が、切り出した部分を横に並べることで生まれる。切り出しの手順は節「部分を切り出す」を、並べた部分から様式について何が言えるかは節「特徴抽出と様式分析」を参照。

同じ作業は紙と糊でも行える。違いは、デジタルの利点を活用する方向に研究手法そのものを進化させる点にあると報告されている [UC-040 §顔貌コレクションとデータ駆動型人文学]。データを基盤に人文学の研究手法を革新し、データの共有やエビデンスに基づく検証という文化を持ち込む立場が、データ駆動型人文学と呼ばれる [UC-040 §顔貌コレクションとデータ駆動型人文学]。

全数をそろえ、数え、並べる

部分を並べる操作は、対象の全数をそろえる操作に拡張できる。歴史ビッグデータという語は、書物や記録に書き残されたものからデータを取り出して使うというこの立場を指す [UC-011 §2. 「歴史ビッグデータ」という課題]。日本には江戸時代のものだけで数十億点規模ともいわれる書物が残り、日記からは過去の天気、被害の記録からは地震や噴火の様子、感染症の記録からは広がり方、経済では米相場、社会では村ごとの人口が取り出せる [UC-011 §2. 「歴史ビッグデータ」という課題]。村ごとの人口であれば、一つの村の記録を読むだけでは分からない分布や偏りが、全村をそろえて初めて見える。

全数化の前提は、記録を機械可読データにすること、すなわち表形式やXML・JSONといった形式に構造化することである [UC-011 §2. 「歴史ビッグデータ」という課題]。過去の資料では、崩し字を読むところから出発しなければならない点が現代のデータと異なる [UC-011 §2. 「歴史ビッグデータ」という課題]。

海外でも同じ発想の研究が進められている。Time Machine Europeは「Big Data of the Past」を掲げ、機械可読データを作ってAIやシミュレーションで過去を復元しようとしている。Living with Machinesは、古地図から鉄道などの地図記号を機械学習で認識して路線を復元したり、OCRで地名を取り出したりして、人手では追いつかない量の分析を行っている [UC-011 §2. 「歴史ビッグデータ」という課題]。

住所や地名を集計して地理を描く操作も、同じ型に属する。歴史地震の史料では、長文のテキストから地点を抜き出して地点ごとの表を作り、それぞれの震度を判定する処理が試みられた。約2万文字の史料1点からは約160地点が抽出されている [UC-048 §第1実験:史料を一括処理するアプリとその課題]。記事が述べるのは抽出・表化・判定の処理までである。地点ごとの表が揃えば揺れの地理的な広がりを描けるというのは、ここでの読みにすぎない。地名を辞書に結びつける手順は、節「地名という接点」を参照。

時間にも規模を広げられる

規模を上げる方向は空間の全数だけではなく、時間にもある。同じ場所の写真を時間軸に並べることは、部分を並べ、全数をそろえるのと同じ型の操作を、時間の方向へ広げたものである [UC-016 §景観を「読む」ための新しい技術]。規模を時間の方向に上げることで、何が変わり、何が変わっていないかという変化の配列が見える。写真の読み方そのものは、節「写真という資料」を参照。

規模を上げることで失うもの

集約は、個々の資料の読み取りを代替しない。第一に、集約の質は読む側の知識に依存する。写真を通時的に並べる場合も、場所をよく知っていればどこから撮ればよいかを容易に判断できるが、知らなければ理解に時間がかかる [UC-016 §景観を「読む」ための新しい技術]。大量に並べた結果を解釈する段階では、結局、対象についての精読的な知識が要る。

第二に、規模を上げると取りこぼしや精度の低下が起きうる。歴史地震の震度判定では、約2万文字の史料1点では約160地点を抽出できたが、790件の史料を同じプロンプトで大量に処理すると、同じ史料から20か所しか判定されなかった。使用した判定基準の「適切」も66%から45%に下がり、「不適切」は5%から15%に増えた [UC-048 §第1実験:史料を一括処理するアプリとその課題]。量が増えると取りこぼしが生じ、精度も落ちたため、処理は取得・タグ付け・表化と構造分析の段階に分割して再設計された [UC-048 §第1実験:史料を一括処理するアプリとその課題, UC-048 §再設計:処理を分割する(取得・タグ付け・表化・構造分析)]。

第三に、一本の線や一件の行に落とすとき、元の資料にあった精度の差が見えなくなる。街道データでは、資料から確実に読める区間も、地形などから推定した区間も、データ上は同じ一本の線であり、精度は記録されていない。資料が残っているかどうかで精度がまちまちであることは今後の課題だと報告されている [UC-045 §線を引く:地理院地図の上での手作業]。精読では資料ごとに疑わしさを確かめながら進められるが、集約のあとには均質な点や線が並ぶだけになりやすい。精度を記録しておくこと自体が、課題として残る。

規模の選び方

遠読は精読の代用でも、精読を不要にする手続きでもない。部分を並べることで様式が比較でき、全数をそろえることで分布が見え、時間を並べることで変化が見える。その一方で、解釈には対象についての知識が要り、量を扱う処理には取りこぼしがあり、集約された点や線は元の資料の精度の差を覆い隠す。規模を変えることは、これらの得失を引き受けて、問いに合った水準を選ぶことである。

この節へのコメント

  • まだコメントはありません。

3.2 データモデリングと構造化

資料をデータにするとき、何を実体とし、何を属性とし、何を関係とするかの選択は、後でどんな問いを立てられるかを決めてしまう。この選択は技術上の選択である以前に、解釈上の選択である。

資料がそのままではデータにならないこと

歴史資料の画像は、くずし字を読む必要があるなどのハードルがあり、そのままでは使えない。歴史ビッグデータは作らないと使えないものであり、AI を使える部分は多いものの、手作りでないと無理な作業が多いという整理がある [UC-044 §歴史ビッグデータの作り方と使い方]。何を同じ実体とみなすかの判断基準が難しいことも、同じ整理の中で指摘されている [UC-044 §歴史ビッグデータの作り方と使い方]。同じものを指す別の記載を一つの実体にまとめるかどうかは、あらかじめ決まっているのではなく、資料を読む側の判断で定まる。実体の切り出しは、すでに解釈上の選択である。

何を実体とするかという選択

力士を実体とするか、番付上の出現を実体とするか。公演を実体とするか、演目を実体とするか。この区別によって、後でどんな集計ができ、どんな比較が可能になるかが決まる。相撲番付のアーカイブでは、宝暦7年(1757年)から慶応4年(1868年)までの110年210場所の番付を翻刻し、登場するすべての力士の名前をリスト化した。その結果は延べ48,300行を超えるデータリストとなり、「相撲番付 力士検索データベース」として公開されている [UC-036 §従来型の人文学型DH:相撲番付と祇園のアーカイブ]。名前が索引可能なエントリとして立てられたことが、力士を軸とする検索の形を決めている。祇園のアーカイブでは絵画資料420件と花街舞踊公演の上演記録456件がそれぞれ登録されており [UC-036 §従来型の人文学型DH:相撲番付と祇園のアーカイブ]、資料の種別ごとに実体の単位を決めることが設計の軸になっている。

構造が問いを先取りするということ

資料を画像にするだけでは研究基盤にならない。デジタル化は抽出の技術であり、資料が持つ情報の多くは欠落する。そのため、いつ・どこで・誰によって作られたのか、他の資料とどのような関係にあるのかを示すメタデータを付与し、研究上の問いと結びつける必要があるという整理がある [UC-036 §デジタル・アーカイブからDHへ:ARCが積み重ねてきたもの]。どの属性を記録し、どの関係を明示するかが、その資料に向けられる問いの射程を規定する。

バム遺跡の事例では、資源をクラスとして体系化して記述するオントロジー的なメタデータの付け方が採用された [UC-020 §メタデータの管理と公開]。オントロジーは実体の種類とそれらの関係をあらかじめ定義する枠組みであり、その定義が「何と何が関係しうるか」についての解釈を固定する。クラスの体系化にダブリンコアなどの標準語彙と国際標準の Object ID が併用されたことは [UC-020 §メタデータの管理と公開]、他のデータセットとの接続可能性を設計の段階から確保する選択として読める。語彙とスキーマの選び方そのものは「メタデータ」を参照されたい。

本文から切り離して注釈を持つやり方

バム遺跡の復元では、遺跡の正確な構造(ジオメトリ)を作る作業と、それを記述するメタデータの作成とが別の工程になっていた。メタデータはオントロジーエディターの Protégé で作成され、公開には RDF ストアに PostgreSQL、RDF の API に Apache Jena が用いられた [UC-020 §メタデータの管理と公開]。モデルそのものと、そのモデルについての記述とを別個に持つ設計は、資料本体と注釈を切り離して扱う考え方の一例といえる。こうした分離は記述を後から追加・修正しやすくする利点をもつと考えられる。一方で、本体と記述の対応関係を維持する管理が別に必要になる。ただし、この利点と負担の両面は、紐づく記事が直接論じたものではない。

同じ資料から複数の見せ方を用意するという問題もある。祇園のアーカイブでは、研究者向けのデータベースと、解説付きのカタログ型で幅広い層を想定したバーチャル・インスティテュートとが分けて提供されている [UC-036 §従来型の人文学型DH:相撲番付と祇園のアーカイブ]。構造を設計する段階で、想定する利用者と問いの種類を意識することが、後の公開形態に影響する。

構造設計が解釈である、ということ

3次元復元では、欠けている部分を補う際にペルシャ建築として妥当な構造かという観点が求められ、突起物や窓、門の形などを適当に決めるわけにはいかない [UC-020 §モデリングとレンダリングの分担と精度・コストの調整]。この事例では当初、コンピューターの専門家がモデリングも担い、遺跡の専門家は指示を出すだけだったが、うまくいかなかった。そこで遺跡の専門家がモデリングを担い、コンピューターの専門家がレンダリングを担う形に改めたところ、正確な画像が作れるようになった [UC-020 §モデリングとレンダリングの分担と精度・コストの調整]。欠損のある資料を構造として表現するとき、何を補いどう補うかは、対象についての専門的な解釈を前提とする。構造を決める作業は、中立な記録行為ではない。

この節へのコメント

  • まだコメントはありません。

3.3 データの格納と情報基盤

構造をどこにどう格納し、何を API として配信するか。この選択は、プロジェクトの規模と用途、将来の拡張の余地を左右する。

格納先の選択肢と用途の対応

小規模なプロジェクトや、機械処理の前段として画像領域とメタデータを紐づける作業では、CSV や Excel などの表計算形式が出発点になりうる。画像の部分領域を切り出してメタデータを付与し、切り取り画像の URL を Excel でリスト化したうえで、後からプログラムで外部システム向けの形式に変換する運用が報告されている [UC-001 §ICPの高度な利用]。表計算形式は可搬性が高く初期コストも低いが、クエリの表現力や同時編集の堅牢性には限りがある。

より複雑なクエリや多ユーザーでの運用には関係データベースが向き、地理情報を含む場合は PostGIS などの空間データベースを組み合わせる。小規模なら表計算、複雑なクエリや多ユーザーなら関係データベース、地理情報を含むなら空間データベース、という対応が選び方の骨格になる。この整理は一般的なものであり、紐づく記事で関係データベースを運用した事例は、後述するテキストレポジトリの一例にとどまる。地理データに固有のファイル形式と配信は「地理データの形式と公開基盤」を、実体・属性・関係の切り分けは「データモデリングと構造化」を参照。

記事が具体的に示すのは、用途と規模に応じて格納先や構成を分ける例である。

  • 共有の要否で分ける: 同一構図撮影を支援するカメラアプリでは、サーバ側に保存されるのは複数人で共有するプロジェクトのデータのみで、個人で完結するマイプロジェクトのデータはサーバに保存されない [UC-004 §アプリの基本要素とプラットフォーム]。共有が要るデータだけを集中管理し、個人用のデータは手元に置く切り分けである。
  • 利用環境の段階で分ける: IIIF Curation Platform(ICP)の利用環境には、デモ環境を使う方法、クライアントだけを設置する方法、サーバも自前で立てる方法がある。プロジェクト専用環境を構築する Docker 版では、ポートやプロキシの設定が分かる程度のサーバー管理知識と Docker の基本知識が要るが、それほど高度な知識がなくても十分に対応できる範囲だと述べられている [BP-001 §工程ごとにツールを使い分ける]。構成の複雑さは、利用側が負える運用負担に合わせて選べる。
  • 作業の規模で分ける: IIIF Curation Editor は個別のメタデータの追加や変更に使われるが、大規模な編集作業には向かないことが注意点として挙げられている [BP-001 §工程ごとにツールを使い分ける]。

いずれも当該のアプリやツール群についての記述であり、ここから格納先の一般的な選択基準を導くことはしない。実体間の関係をグラフとして表現し識別子で接続する考え方は「知識グラフとリンクトデータ」が扱う。グラフストアを実際に運用した実践知は、紐づく記事に見当たらない(本節末尾の「現時点で薄い領域」の項を参照)。

正本をデータベースに置き、API 越しに使う構成

関係データベースを正本とし、アプリケーションをすべて API 越しに使う構成の実例が、テキストレポジトリのシステムで報告されている。本文・注釈・同定をレポジトリ本体に保存し、アプリケーションは API を介してのみ使う [UC-049 §テキストレポジトリのシステム構成]。

  • 正本: PostgreSQL 16 に、資料・版・本文(Canonical Text)、注釈、言及・実体・同定リンク、注釈どうしの関係、監査ログを保存する。
  • 確定と推測の分離: AI の推測である候補は、確定データとは別の表に置く。
  • API 層: REST と OpenAPI を用い、型付きクライアントを生成する。
  • 連携するアプリケーション: 注釈・エンティティリンキング、分析・可視化、取り込み(翻刻・TEI・PDF・IIIF を変換し、確認してから版を確定する)、閲覧・検索が API で連携する。

[UC-049 §テキストレポジトリのシステム構成]

確定データと AI の候補を別の表に分けておくことで、機械が出した推測が確認前のまま確定データに混ざることを避けられる。この分離は、正本として何を持つかという格納上の判断であり、配信の設計とも結びつく。

JSON を中間層として置く構成

格納形式と配信形式のあいだに JSON を中間層として挟む構成が、IIIF を使うプロジェクトで報告されている。JSONkeeper は JSON 形式のデータを保存・提供するサービス、Canvas Indexer は JSONkeeper のデータをクロールしてキャンバス単位に分解し検索可能にするサービスで、ビューアやファインダーの背後でデータベース的な層を担う [UC-001 §ICPの高度な利用]。この層に機械学習によるタグ付けサービスを連携させ、顔にタグを付けて検索する使い方もある。キュレーション単位で集めたデータをキャンバス単位に分解し、メタデータ単位で組み替える仕組みも、この層の上で動いている [UC-001 §ICPの高度な利用]。

中間層を置くと、前段のデータ作成と後段の検索・閲覧が切り離される。切り取り画像の URL をリスト化しておけば、後から JSONkeeper を読み出して別のデジタルアーカイブ向けの形式へ変換することもできる [UC-001 §ICPの高度な利用]。ここでの「組み替えがしやすい」という性質は、報告された運用から読み取れる範囲での整理であり、他の格納構成との比較に基づくものではない。

何を API として配信するか

格納したデータを外部に公開するとき、何を標準の API に載せ、何を独自の要件として残すかが、再利用可能性を左右する。標準の仕様に沿って配信すれば、利用者は既存のビューアでそのまま閲覧できる。一方、標準が想定しない要件を独自拡張で満たすと、その拡張に対応したビューアが要る。IIIF の API の構成と、独自拡張を伴う配信の事例は「画像の流通基盤」を参照。

もう一つの配信の考え方が、先のテキストレポジトリに見られる。OpenAPI を公開して、外部の研究システムも同じ API を使えるようにし、将来アプリケーションを追加しても本体の構造は変えない [UC-049 §テキストレポジトリのシステム構成]。何を正本として持ち、何を API を通して見せるかを分けることで、利用側のアプリケーションを増やしても、格納の構造を変えずに済む。

ここで述べたのは、紐づく記事が報告している構成の範囲である。エンドポイントの切り方、認証、バージョニングについての推奨は、記事から導けない。

後から変えることの難しさ

格納形式と API は、一度決めると後から変えるコストが高い。表計算形式から関係データベースへ移すにはスキーマ設計の見直しが要り、グラフ構造への再モデリングは構造の決め直しに及ぶ。独自 API 拡張に依存した下流のシステムは、拡張を変えるたびに修正を迫られる。この見立ては一般的な整理であり、移行の失敗や成功を扱った記事に基づくものではない。

このため、格納先の選択は、データモデリングの段階で見込まれるクエリの種類、データの規模、配信の要件と合わせて検討するのが望ましい。構造の決定が後から問えることを制約する側面は、「データモデリングと構造化」を参照。

この節へのコメント

  • まだコメントはありません。

3.4 データを整える

資料をデータにする工程のうち、整える作業は実務で最も時間を食う。表記の揺れや異体字、同じものを指す別の書き方を整理し、揺れのある記録を同一の対象にまとめる。基本になるのは名寄せで、実際の資料に現れる記載を、整えた先の標準的な対象(辞書のエントリ)へ一件ずつ対応づけていく。そこで問われるのは、どこまでを同一とみなすか、どこまで整えるか、整えることで何を失うか、整えた過程をどう残すか、という四つの判断である。

名寄せの考え方:ばらつきをどこまで同一とみなすか

揺れのある記録を一つにまとめる作業は、どの違いを揺れとして許し、どの違いを別物の印として区別するかという基準を決める作業でもある。

辞書を使う場合、実データから典型的な表記揺れを集めて辞書を強化していく。辞書を使う優先順位を決められるので、表記揺れの辞書を優先して引けば、実データに含まれる不正確な記載にも対応できる。頻出する異体字は共通の異体字辞書に登録し、利用例の少ないものは個別の対応表で処理する。異体字のなかでも書き間違いに近いものは、無理に異体字として登録せず、元のデータ側を直して対応する [UC-031 §旧東京市15区住所データセットの構築]。住所や地名の具体的な対応は「地名という接点」を参照されたい。

基準を数値で決めた例が、活字の同定である。同じ文字の複数の刷りを比べると、同一の活字による刷りでは輪郭に沿った細い縁だけが違い、別の活字では筆画そのものの位置が違う。縁のずれは同じ活字による揺れとして許し、筆画の位置のずれは別の活字の印として区別する。平均類似度が0.85を超える組み合わせがなくなるまで併合を繰り返し、物理的な活字へさかのぼる [UC-043 §活字ブロックの同定]。手法と検証の詳細は「画像・テキスト認識」の「字形の比較」に譲る。

どこまで整えるか

整える作業は、手間に見合う効果が薄れる地点で打ち切る必要がある。関東大震災の住所データの修正では、変換率を見ながら、費用のかかる作業へ段階的に進めている。

  • 表記揺れのパターンを収集して辞書に登録する。機械的に解ける範囲が広がり、全体の約84%が地番レベルで変換できるようになった。
  • 文脈から一意に決まらない町名を同定する。
  • 誤字・入力ミスを元データで手修正する。約1,000件が改善され、地番レベルで変換できる割合は86%に達した。
  • 残りを1件ずつ確認する。この段階で87%となった [UC-032 §住所データ修正のワークフロー]。

順を追うごとに改善幅は小さくなり、残りは一件ずつの確認という最も手のかかる作業に絞られる。どこで打ち切るかは、この改善幅と手間の対応を見て決めることになる。住所の変換そのものの手順(辞書を拡張するか元データを修正するかの判断など)は「地名という接点」を参照されたい。

整えることで失うもの

整える作業は、元の記載とは異なる値への置き換えを含む。先の住所データでは、単に「横川町」とだけ書かれているものを、「中ノ郷横川町」「柳島横川町」のような区別の表記がないという理由で「本所横川町」とみなしている。地図上に存在しない地番も、近接する番地に代表させて処理している [UC-032 §住所データ修正のワークフロー]。

どちらの場合も、置き換えた分だけ元の記載の曖昧さや元の精度が、データから消える。したがって元の値を別に残しておかなければ、後から置き換えの当否を確かめることも、別の判断でやり直すこともできない。

整えた過程を残す

成果物だけでなく、そこへ至る中間の資料を残すことも、後から辿るための手段になる。『新収日本地震史料』の編纂では、調査先でコピーや写真撮影をした史料を紙焼きにして冊子に綴じた写真帳と、カード目録およびその Excel ファイルが残っている。これらから、いつどこでどの史料を集めたかがおおよそわかる。調査先ではすでに所在がわからなくなっている史料もあると聞いており、その意味でもコピーが残っていることには重要な面があると述べられている [UC-047 §『新収日本地震史料』の編纂資料]。

この事例は編纂の中間生成物の保存の話であり、クリーニングの履歴や変換の記録をどう書き残すかを述べたものではない。

この節へのコメント

  • まだコメントはありません。

3.5 メタデータ

データを記述する語彙の選び方は、誰に渡すか、どの項目を書くか、誰が付けるか、流通と発見のどちらを重んじるかによって変わる。標準に従うかたいメタデータと、対象に即して自由に作るやわらかいメタデータという二つの極のあいだで、どこまで標準に寄せるかを、記事に見える実践から整理する。

誰に渡すかで、標準への寄せ方が決まる

スキーマを選ぶ第一の基準は、データを誰に渡すかである。自分や自組織のためだけに使うなら、相互運用性の重要度は下がる。一般的・専門的な利用者へ流通させるなら、相互運用性を考慮した形式や、分野ごとの詳細な項目が要る [UC-021 §メタデータをめぐる論点:利用者・項目・専門性]。標準語彙をどこまで厳密に採るかは、この分岐でまず決まる。

第二の観点は項目の類型で、基本・内容・来歴・管理・利用の五種類に整理されている。どの項目を書くかによって、必要な語彙は異なる [UC-021 §メタデータをめぐる論点:利用者・項目・専門性]。第三の観点は付与する側の専門性である。基本メタデータや識別子を付与するデータライブラリアン的、利用者視点で潜在的価値を引き出すデータキュレーター的、長期的価値を保存するデータアーキビスト的の三種があり、メタデータの付け方はこれに応じて変わる [UC-021 §メタデータをめぐる論点:利用者・項目・専門性]。

さらに、メタデータを学術的説明として専門知を詰めたものとみなす立場(目的)と、検索できればよい補助情報とみなす立場(手段)とでは、自動生成への評価が分かれる [UC-021 §メタデータ付与の自動化と「目的か手段か」]。どちらに立つかも、スキーマの選び方に影響する。

かたいメタデータとやわらかいメタデータ

かたいメタデータは標準的な共通スキーマに基づいて作成し、標準化によって相互運用性を担保する。ただし合意形成には多大なコストがかかり、標準化できない情報は脱落する [UC-021 §かたいメタデータとやわらかいメタデータ]。やわらかいメタデータは、目的に応じてスキーマを柔軟に使い分け、相互運用性は生成AI の橋渡しで確保するという発想に立つ。事前の合意が不要になり、利用者が目的に最適化して作成でき、多様な情報を取り込める [UC-021 §かたいメタデータとやわらかいメタデータ]。

どこまで標準に寄せ、どこから自由に書くか

標準に寄せるかどうかの基準は、流通を重視するか、発見(ファインダビリティ)を重視するかにある。流通を重視する場面(DOI など)では固定的なスキーマによる標準化が引き続き重要であり、発見を重視する場面ではやわらかいメタデータと生成AI が多様化を進める [UC-021 §AI時代におけるメタデータの再考と今後の展望]。

生成AI が橋渡しできる範囲には限りがある。同義語や表記の揺れといった浅い意味のギャップは橋渡しできるが、深い意味のギャップは橋渡しできない [UC-021 §AI時代におけるメタデータの再考と今後の展望]。したがって、深い意味の違いを越えて共有したい項目は標準の側に置く必要がある。

質疑応答では、かたいメタデータは最低限必要なものに絞り、それ以外は無理に標準へ収めず自由に書いてよいという見方が示された。コンテキスト作成の準備は人間に残るが、きれいに整理する労力や使い回しの面で人間の負担は大きく減る可能性があるとも述べられている [UC-021 §AI時代におけるメタデータの再考と今後の展望]。標準に収まらない情報を事前に切り捨てるのではなく、多様なデータをそのまま保存し、構造化をオンデマンドで行うという役割分担への移行が提案されている。この移行にはメタデータの再定義が必要だとされ、現在の方式はなお標準に収まらない情報が脱落しやすい形に近い [UC-021 §AI時代におけるメタデータの再考と今後の展望]。

標準を土台に、対象に即した体系を組む

標準と対象に固有の体系は、択一ではない。イランのバム遺跡の3次元復元では、資源をクラスとして体系化して記述するオントロジー的なメタデータを採り、語彙にはダブリンコア(Dublin Core)などの標準を組み合わせた。国際標準のメタデータとして Object ID も併用し、作成にはオントロジーエディターの Protégé を用いている [UC-020 §メタデータの管理と公開]。標準語彙と国際標準を土台に、対象に即した体系をその上に組んだ組み合わせの一例である。オントロジー的な付け方を採った背景には、共同研究者がオントロジーの研究をしていたことがあるという [UC-020 §メタデータの管理と公開]。この選択は、対象だけでなく担い手の事情にも左右されている。

標準では届かない項目を、生成AI で補う

標準に従った書誌情報は、それだけでは利用者に届きにくいことがある。つくし堂は、標準に従って記述された書誌情報のメタデータと、くずし字認識によるOCRテキスト(OCR誤りを含む古文)の二つを入力とし、プロンプトを与えて要約やタグを生成する [UC-021 §つくし堂:AIによる古典籍メタデータの生成]。現代文で書かれるため読みやすくなる点が利点で、3,000点以上の古典籍にキャッチフレーズを付ける作業は人間の専門家には現実的でない。この事例は、正解がなく多様な解があり得るメタデータにこそ生成が有効だと位置づけている [UC-021 §つくし堂:AIによる古典籍メタデータの生成]。

ただし、生成された記述はもっともらしく見えるため、ハルシネーション(幻覚)かどうかの確認が難しく、専門家から見れば細部に疑問が残る可能性があるとも述べられている [UC-021 §つくし堂:AIによる古典籍メタデータの生成]。やわらかいメタデータは、標準化された記述の代わりではなく、その補いとして置かれている。

利用事例と使い方という、通常は書かれない項目

メタデータには、作成者自身が把握しきれず書かれにくい項目がある。データセットの公開メタデータには、どう作ったかは書かれても、どう使えるかは書かれにくい。Mahalo Research は、Mahalo Button で蓄積した利用事例を加えることで、データセット要約の応用分野の記述を充実させている [UC-021 §Mahalo Research:やわらかいメタデータによるデータセット発見支援]。この設計では、利用事例の生テキストをそのまま保持し、利用の時点で構造化や形式変換を行う。最初に情報をまとめて落とさず、リッチな情報を持っておく方針である [UC-021 §Mahalo Button:データ利用事例の蓄積と活用]。

さらに、データをどう使うか(HOW)を記述する Operational Metadata という整理が試みられている。ファイル形式と読み込み方法、列定義(名前・型・単位・値の意味)、ファイル名パターン、API使用例、注意点・制約などを含む。データを読み込むソフトウェアがあれば、それを生成AI に入力して自動的に分析させ、この形式で生成できるという。この分類は暫定的なものとされている [UC-021 §生成AIのための「HOWメタデータ」]。Descriptive Metadata(WHAT)と Operational Metadata を併せて与えると、台風経路を描くプログラムが自動生成される例が示されている。メタデータの語彙を広げることは、AI が読み手になる場面への備えにもなる [UC-021 §生成AIのための「HOWメタデータ」]。

この節へのコメント

  • まだコメントはありません。

3.6 テキストから実体を取り出す

テキストの中の地名・人名・被害記述といった実体を取り出して他のデータにつなぐと、文章が検索・集計・地図化できる構造化データになる。資料を翻刻してプレーンテキストにしたあとの課題は、そこから研究に有用な構造化データをどう取り出すかにある、と指摘されている [UC-049 §歴史資料の大規模テキスト化と構造化の課題]。

翻刻から構造化データへ至る段階

歴史資料の大多数は構造化されていない自然言語で書かれており、機械処理に適した形にするには段階的な加工が要る。画像を翻刻してプレーンテキストにし、テキスト中の地名や人名にアノテーションを付けるか固有表現抽出で抜き出し、その部分を外部のデータソースに対応付ける(エンティティリンキング)、という流れである [UC-049 §歴史資料の構造化プロセスと「みんなで注釈」]。取り出した実体が外部のデータにつながってはじめて、地図やデータベースの上で他の資料と並べられる。

人手による取り出しの一例が「みんなで注釈」である。安政江戸地震の関連資料約100点を対象に、ユーザーが人名・地名・地震による被害にマーク付けし、地名は GeoLOD の API で歴史地名のデータに結びつけた。これにより、地震の被害がいつ、どこで、どの規模で起きたかを構造化データとして取り出せた [UC-049 §歴史資料の構造化プロセスと「みんなで注釈」]。

ただし、この仕組みは安政江戸地震史料に特化しており、任意のテキストを追加できず、アノテーションやエンティティリンキングの種別も固定されていた。そこで要件として挙がったのが、テキストと注釈・エンティティリンキングの結果を版管理つきで保存し、外部のアプリケーションと API で連携させるテキストレポジトリである。翻刻は修正されて変わっていくため、版管理が要るという理由も添えられている [UC-049 §テキストレポジトリが必要になった理由と要件]。取り出した実体は、一度抜き出して終わりではなく、保存して他のシステムに渡せる基盤があってはじめて使い回せる。

自動で抽出して地名辞書に結びつける

地名や住所の抽出と辞書への結びつけを自動化したものに GeoNLP がある。テキスト中の地名と住所を自動的に抽出し、辞書中の地名とリンクするソフトウェアで、住所部分のエンジンには jageocoder が使われている。地名辞書を拡張すれば適用範囲も広げられる [UC-031 §現代の住所を対象とした応用事例]。辞書の側の作り方と、抽出結果を突き合わせるときの表記の問題は、「地名という接点」を参照。

大規模言語モデルによる抽出と構造化

大規模言語モデル(LLM)は、この取り出しの方法を変えつつある。生成AI がデータ構造化の作業に非常に有用であることが経験的に分かりつつあり、構造化の方法を変えつつあるという見方が示されている [UC-049 §歴史資料の大規模テキスト化と構造化の課題]。

その実践例が、歴史地震の史料から震度を判定するツールの設計である。処理を一括で行う設計から、段階に分ける設計へ改められた。判定の前段は、史料の一括取得、タグ付け、表化と構造分析から成る [UC-048 §再設計:処理を分割する(取得・タグ付け・表化・構造分析)]。

  • 取得:API で史料テキストをメタデータとともに JSON で取得する。条件は日付、期間、地理範囲(中心の緯度・経度と半径)から選べる。
  • タグ付け:取得したテキストの中の地名と、震度判定の対象になる物(構造物など)に、2種類のタグを付ける。
  • 表化と構造分析:地点・対象物ごとに、内包史料、大地名、小地名、被害記述、タグの種類、注記を表にして JSON で出力する。タグ付けの段階で漏れたものを拾えるよう設計されている。同じアプリで、本文に書状の写しが何通含まれるかといった構造も調べる。〔文政雑記〕の例では、3件の内包史料について差出人とその所在地を整理し、過去の地震への言及など判定から除外する対象も挙げている。

この設計では、取り出す対象を地名と対象物に絞って段階ごとに分け、各段階の出力を JSON で次の段階に渡す。実体の取り出しを一度の問い合わせに押し込まず、取得・タグ付け・表化に分けることで、各段階で何が漏れたかを確かめられる形になっている [UC-048 §再設計:処理を分割する(取得・タグ付け・表化・構造分析)]。

長い文書を切って扱うとき、文脈を保つ

長い文書を LLM などに渡すには、参照の単位に区切る必要がある。ところが区切ると、文脈が途切れる。Humanitext はこの問題に取り組んでいる。保存・配信・推論の三層のうち配信の層では、TEI/XML のままでは AI に渡すにはタグが多いため、JSON に変換し、参照箇所を特定できる ID(CTS URN 規格に基づく)と箇所マーカーに絞って最適化している [UC-038 §保存・配信・推論の三層アーキテクチャ]。

文脈の切れ目に対応するのが文脈指向翻訳である。チャンクを単独で訳すと代名詞・省略・照応の指示先が失われるため、直前までのチャンクの訳を文脈として与え、参照の解決にのみ用いて現在のチャンクだけを訳させる。各チャンクは単独で検索可能でありながら、文脈上の指示先を保つ。チャンク化と文脈保持は本来トレードオフだが、生成時に文脈を参照させることで、ある程度まで両立させている [UC-038 §保存・配信・推論の三層アーキテクチャ]。

チャンクごとの安定した ID は、保存・配信・推論の三層を貫き、どの層でも同じ一節を指す参照のアンカーになる [UC-038 §保存・配信・推論の三層アーキテクチャ]。実体の取り出しの面から見れば、抽出した実体や注釈を、本文のどの箇所に由来するかを失わずに結びつけられる、ということである。

取り出した実体が辞書や識別子に流れ込む

断片的な過去の空間情報を統合する基本方針は、エンティティに識別子(ID)を付与し、属性を紐づけることである。表記の揺れがあるため、何を同じエンティティとみなすかの基準が重要になる [UC-013 §識別子と属性によるデータ構築の基本方針]。取り出した実体も、この方針に沿って識別子を介し、他のデータに接続される。

地震史料集テキストデータベース(35冊・約27,700頁、約6.7万件)では、史料集に現れる地名のうち、〇印の有感地点と書名の地名に、ROIS-CODH の歴史的行政区域データセットβ版の地名 ID を付与した。たとえば〔石川県中島町史 資料篇〕の書名からは、石川県鹿島郡中島町(17403A1968)の ID が付く。これで索引地図から宇治などの地点に関連する史料を検索できるようになった [UC-047 §地名へのIDの付与]。

流れ込ませた結果の位置づけには、限界がある。地図上の地点は〇印の有感地点や出典の所蔵機関の所在地などを市区町村レベルで落としたもので、被害の発生地点や地震を感じた地点とは必ずしも一致せず、地名が付いたのも一部の史料に限られる。本文の地名は読まないと分からないため、人力や AI などで付与する予定とされている [UC-047 §地名へのIDの付与]。

この節へのコメント

  • まだコメントはありません。

3.8 可視化の技法

可視化は中立な表示ではない。データのどの側面を実体として扱い、どの側面を背景に退けるかについて、図は立場を取る。どの図を選ぶかが、何を主張するかを決める。

地図は何を選び、何を省くか

地図は現実世界のコピーではなく、地上の特徴から必要なものを選び、抽象化・シンボル化して表現したものである [UC-009 §地図とは何か]。衛星画像が解像度の許す限り地上を網羅的に記録するのに対し、地図は利用者にとって重要な部分を取り出し、それ以外を省略・加工する。道路を実際より太く描いたり、重要度に応じて色を変えたりする強調もこの操作に含まれる。日本の地図には駅が必ず描かれるが、鉄道を重視しない国の地図では駅が省略されることもある [UC-009 §地図とは何か]。

何を残して何を消すかは、縮尺の問題を超えて、その地図の主張を決める。1933年に Harry Beck が作成したロンドン地下鉄路線図は、路線を縦・横・斜めの直線だけで描き、実際の経路の形も駅間の距離も正確には反映しない。それでも駅の順序、乗り換え位置、テムズ川の位置は正しく保たれており、「地下鉄に乗って移動し乗り換える」という目的には最も使いやすい [UC-009 §地図とは何か]。距離の正確さを捨てて、目的に必要な情報の構造を可視化している。地図の本質は、目的に応じて必要な情報を可視化することにある。

絵図のように位置関係の描き方そのものが測量と異なる地図の扱いは、節「地図資料の処理」を参照。

何を重ね、何を点で描くか

何を重ねて見せるかを選べること自体が、地図を作ることを選択の行為にしている。同じ地域でも、どの情報を重ね、どれを下げるかで、図が語る内容は変わる。レイヤーという機能の仕組みは節「地理データの形式と公開基盤」を参照。

描く図形の種類にも主張が入る。あるものを点で描くか面で描くかは、それを「場所」として扱うか「領域」として扱うかの選択でもある。ベクタとラスタの形式としての違いも、同節を参照。

補間を伴う図では、この選択性がいっそう強まる。センサーのない場所の値を、置かれた地点のデータから補う場合、補間した値を地図に描けば、観測していない場所の「ありそうな値」が観測値と同じ見た目で並ぶ [UC-009 §地理情報システム(GIS)とデータ構造]。どの手法で補うかが、描かれる分布の形を決める。

地図に描ける粒度、描けない粒度

歴史資料から住所を取り出して地図に描く作業は、可視化が何を主張でき、何を主張できないかを具体的に示す。関東大震災の死亡者住所の事例では、東京都慰霊協会が所蔵する「震災死亡者調査表」約3万8千名分の住所をジオコーディングし、空間分布として地図化して被害の地理的パターンを探った [UC-032 §はじめに]。

地図に描けたことと描けなかったことは分けて読む必要がある。本所区では、死亡場所の記載が「本所区」という区止まりのものが95%を占め、深川区でも「深川区」のみが88%を占める。この二区では区内のどこで亡くなったかを点として定められず、空間分布の粒度に限界がある。他の区では居住地での死亡割合が相対的に高く(神田区67%、下谷区43%、浅草区24%など)、地点として描きやすい [UC-032 §死亡場所・人口密度からみた本所区・深川区の特殊性]。同じ地図の上でも、区によって描ける精度が違い、その差が分布の見え方に入り込む。

区別の死亡率(死亡者数÷大正9年国勢調査人口)を並べると、本所区が10.7%で突出し、深川区1.9%、浅草区0.9%と続く。人口密度が同等以上の浅草区が0.9%にとどまり、密度の低い深川区が1.9%を示すため、人口密度は高い死亡率の背景ではあっても直接の原因ではなく、地域や場所ごとの別の要因が作用したと考えられる [UC-032 §死亡場所・人口密度からみた本所区・深川区の特殊性]。分布を並べることで人口密度との単純な対応が崩れることは見えるが、その先の要因は地図が答えるものではなく、地図をきっかけに問いを立て直す段階に移る。

この節へのコメント

  • まだコメントはありません。

4 AI との協働

AI を研究に使うときの作法をまとめる。まず AI の時代に研究の方法がどう変わるかを述べ、続いてデータを作る場面、問う場面、エージェントを使う場面の作法を述べる。

4.1 AI 時代の研究方法

AI が研究の手順を担えるようになると、問われるのは「AI で何ができるか」より先に、「研究者はどこで何に責任を負うのか」である。本節は、研究者の関与の深さを三つの類型で定義し、そこから導かれる研究者像、著者性と評価、人の育ち方、人文学の教え方を順に述べる。AI で何を作り、何を問い、どう実装するかは、各節(「AI でデータを作る」「AI で問う・読む」「AI エージェントの活用」)を参照されたい。

関与の深さを三つに分ける

AI との関わり方は、人がどこまで手順に入り込むかで三つに分けられる。この三類型は、本ガイドラインにおける定義である。

  • Human-in-the-loop:一つ一つの作業を研究者が指示し、結果を確認する。マイクロマネジメントにあたる。
  • Human-on-the-loop:研究者が方向を示して作業を委ね、結果を確認する。権限移譲にあたる。
  • Human-out-of-the-loop:結果をそのまま使う。丸投げにあたる。

この順に人の関与は減る。AI にできることが増えるにつれ、in-the-loop から on-the-loop へ移っていくとされる [UC-035 §人間とAIの関わり方の三つの類型と「指揮者」という研究者像, UC-043 §Agentic DHという視点]。

類型が変わると、責任の置き場所も変わる。in-the-loop では、各作業を指示し確認した研究者が、その作業の責任を直接負う。on-the-loop では、個々の作業は AI に委ねられ、研究者は結果の確認を通じて全体に責任を負う。out-of-the-loop では、確認という責任の経路そのものがなくなる。人文学では、この丸投げにあたる out-of-the-loop はあまり成立しないのではないかという見方が示されている [UC-035 §人間とAIの関わり方の三つの類型と「指揮者」という研究者像]。

指揮者であるということ

この構造を研究者像として言い表したのが「指揮者」である。指揮者は個々の楽器を弾けないかもしれないが、全体の音がどうあるべきかを理解し、全体として良い音楽を作る責任を負う。研究者も、個別の工程は AI に委譲しつつ、研究の全体を成功させ説明する責任を負う [UC-035 §人間とAIの関わり方の三つの類型と「指揮者」という研究者像, UC-043 §Agentic DHという視点]。

指揮者であるための条件は二つに整理できる。一つは、権限を委ねても研究責任は手放さないこと。もう一つは、出力を批判的に評価する能力を保つことである。人文学の主体性を保つには、AI への丸投げではなく、的確な指示と対話のコントロールが不可欠であり、自分たちの研究に適した AI を開発する能力や、AI の出力を批判的に評価する能力を育成できるかが問われるという [UC-035 §AI for Humanitiesに向けて]。

この能力を支えるのは、道具ではなく研究者の専門性である。数学の事例では、AI が見つけた反例を人間が理解するために、AI との対話を使いながらも、その対話の成立に深い専門性が必要だと指摘されている [UC-035 §数学研究で進むAI for Science]。歴史地震の震度判定の事例では、コードを書けない研究者が AI の提案を判断し指示することでツールを作った。そのうえで、何を変えないかを決めること、結果を史料で確かめること、AI の提案の採否を決めることは、人間に残る責任だとされている [UC-048 §限界と人間に残る責任, UC-048 §開発の進め方:設計と実装の分業]。

著者性と責任、評価と査読の揺らぎ

AI の関与が深まると、成果が誰のものかという問いが生じる。研究者のプロンプトには独自性があり検証も行うが、それが著者性の根拠になるのかには疑問が残る。数学者の Gowers は、AI が生成し人間が検証した成果を、著者のいない論文として投稿できないかと考えた。しかし、プレプリントサーバーの arXiv は条件を満たさないという [UC-035 §学術システムにかかるストレスと著者性の問い]。人文学では人手による丹念な作業を著者性の根拠としてきたため、AI 支援による成果の評価がとくに難しくなる可能性が指摘されている [UC-035 §学術システムにかかるストレスと著者性の問い]。

評価や査読の側にも負荷がかかる。論文の「生産性」が上がって大量投稿が可能になり、質の低下も重なって、人間が査読するシステムが危機的な状況にあるとされる。機械学習の学会 NeurIPS では、AI を査読に使う実験も始まった [UC-035 §学術システムにかかるストレスと著者性の問い]。

現場の研究者からも、似た戸惑いが寄せられている。DiHuCoハブシンポジウムの参加者アンケートでは、論文や学会報告で AI のリファレンスをどこまでとし、オリジナルをどの部分とするかの判断に困る、という声があった。研究や業務の過程でどこまでが AI の提案や分析で、どこからが人間の判断なのかが見えにくくなることを懸念し、AI の出力をなぜ採用し何を採用しなかったかを記録・検証する仕組みが必要だと感じた、という回答もある。論文作成には使えるが論文査読には利用できないことを問題とする回答や、論文レビューなどで AI に頼りすぎて研究の主導権を握られそうになるという回答もあった [Issues-002 §論点3:人間が担う範囲の見極め]。ただしこのアンケートの回答者は、AI の利用に肯定的な層に偏っている [Issues-002 §調査の方法と回答者の構成]。

学生と研究者の育ち方

技術の習得が入場条件でなくなった

AI は、学生が研究に入る順序を変えている。以前は、プログラミング言語やデータベース、統計処理、画像処理をある程度習得してから研究課題に取りかかる必要があり、問いに到達する前に挫折する学生もいた。現在は、生成 AI との対話を通じてコードを作り、エラーを説明させ、必要なツールを組み合わせられる。技術は研究への入場資格ではなく、研究の途中で獲得し組み替える資源になった、と説明されている [UC-036 §生成AIによる教育現場の変化]。

このことは、資料批判や文脈理解といった人文学の強みを持つ研究者が、データや計算の能力を効率的に駆使できるようになるという意味で、人文学系の研究者にとっての大きな開放だと捉えられている [UC-036 §生成AIによる教育現場の変化]。

取り組みやすい問題を解ける AI と博士課程の指導

一方で、AI が比較的取り組みやすい問題を解ける段階にあるなら、研究を始めたばかりの博士課程の学生に取り組みやすい問題を与えるという、指導の常道が選べなくなる。数学者のブログはそう指摘している [UC-043 §Agentic DHという視点]。同じブログは、自分の名前が定理や定義に永く結びつく喜びを味わえる時代は終わりに近いかもしれない、とも述べる。数学研究にこれから入ろうとする人への影響がとくに大きく、従来のやり方ではキャリアを築けないとも論じられている [UC-035 §数学研究で進むAI for Science]。数学についての議論であり、人文学にそのまま当てはまるとは限らないが、学術システムの変化は人材育成やキャリアパス、教育に大きく影響するため、いまから対応を考えるべきだとされる [UC-035 §AI for Humanitiesに向けて]。

デジタル化からの転回を必要としない世代

世代による違いも指摘されている。これまでの DH は、アナログからデジタルへ、計算可能性とアクセシビリティを高める一方向の変化を議論してきた。いま起きているのは、人間と AI のあいだで主体性をどう分担するかという、配分の問題である。Agentic DH に至るにはデジタル化から AI 化への転回が必要であり、デジタル化の延長では AI 化に進めない、異なるベクトルではないかと述べられる。デジタル化をやめるわけではなく、方向を変えるという意味である。最初からデジタル環境で研究を始めた人は、アナログからデジタルへの変化を経験していない。そのため転回しなくても自然に AI 化に進める可能性があり、デジタル化を経由せずに AI 化を進める研究の道も開かれる [UC-035 §デジタル化からAI化への転回, UC-043 §Agentic DHという視点]。

人文学の何を教えるか

DiHuCoハブシンポジウムの参加者アンケートには、教育の現場への懸念が複数並んでいた。学生が生成 AI を利用すること自体は問題ないが、一部の学生は専門知識を習得する労力を省くために使いたがる、という回答がある。学生のレポートの劣化が甚だしいという回答や、教育の現場にどう取り組むべきかが気になるという回答もあった。AI を使うことで回り道をする面白さに気づく機会が失われかねないという指摘は、これは程度問題で、自分の先輩たちも自分たちを見て同じことを思っただろう、と相対化されている。身につけた技術が意味をなくし、問いを立てることだけが残るので、真の研究者しか生き残れないと感じる、という回答もあった [Issues-002 §論点3:人間が担う範囲の見極め]。

これらの声と、ここまでの構造を合わせると、学生が AI を使うときに身につけるべきことは、次のように整理できる。

教える側の役割も変わる。調査、整理、比較、仮説、生成、表現といった研究行為の一部が AI との協業のなかに再配置されるなら、教員は、技術そのものを教える人から、問いの立て方、資料批判、文脈理解といった人文学の力をどう AI の使い方に結びつけるかを指導する人へ、重心を移すことになる [UC-036 §Agentic DHにおける研究行為の再配置]。具体的には、ツールの操作を教えるだけでなく方法を助言し、検証の仕方を問い、何をもって成果とするかを学生と議論する役割を担う。学生の研究は、AI が答えを出した結果としてではなく、学生が AI を指揮しながら問いと方法と成果を結びつけたプロセスとして評価されるべきだ、という考え方が示されている [UC-036 §学生の研究の評価と教員の役割]。

この節へのコメント

  • まだコメントはありません。

4.2 AI でデータを作る

AI に作らせたものをデータとして使うには、人がどこで関わるかを決め、誤りが残る前提で扱い、AI が作ったことを記録して伝える、という三つの作法が要ります。何を作らせるかは対象ごとの節に委ね、研究者の関与の深さは節「AI 時代の研究方法」を参照します。

検査の最後に当事者を置く

AI の出力をそのまま成果として受け取らず、工程の最後に内容の当事者を置く進め方があります。DiHuCo ガイドラインシステムでは、記事を次のように作っています。

  1. 録音の文字起こしと講演資料のテキストを素材として用意する。両者が食い違うときは講演資料を優先する
  2. 生成 AI が素材から記事を書く
  3. 別に AI がレビューする
  4. 講演者本人が内容を確認する
  5. 知識ベースに登録する

[UC-034 §記事生成のワークフロー]

確認を後ろの二段に置くのは、素材との照合は AI にもできる一方、記事が講演者の意図に合っているかは本人にしか判断できないからです。ガイドライン本文を組み立てる工程も同じ考え方で、生成結果は校閲役のエージェントが重複・食い違い・根拠の不足といった観点から検査し、修正は別のエージェントが提案し、採否は人が裁定します。正本である構造を書き換えられるのも人だけです [UC-034 §Agentic Publishingとは何か]。

AI による検査は工程に組み込めますが、人の確認の代わりにはなりません。検査の層を増やしても、見つかる誤りの種類が変わるだけで、誤りがゼロになるわけではないからです。評価の仕組みの詳細は節「AI で問う・読む」を参照してください。

誤りが残る前提で使う

検査を通しても誤りは残ります。この仕組みでも、記事生成と AI レビューに共通する課題として、素材にない情報を書き加えてしまう問題が挙げられています [UC-034 §記事生成のワークフロー]。素材を与えて書かせても、AI は素材の外から補うことがあります。誤りが残る前提で使うときの作法は、事例に依存しない形で次のように言えます。

  • 誤りの出方は、あらかじめ人手で作った正解データと突き合わせて測れます。正解を測る手段がない部分は、出力を信頼する根拠も弱くなります。人手の正解データを用いた事例は節「AI エージェントの活用」を参照してください。
  • 大量に処理できることは、誤りも大量に生みうることを意味します。件数を増やしたときは、質が保たれているかを改めて調べます。
  • モデルは更新されるので、同じ入力でも結果が変わりえます。いつ、どのモデルで作ったかを残しておくと、後から結果を読み直せます。
  • 理解できないまま採用しません。AI の説明が分かりにくいときは、分かるまで聞き直します。

候補と確定を混ぜない

AI が提案したものと、人が確認して確定したものを、データのうえで区別しておくことも作法の一つです。歴史資料のテキストレポジトリでは、AI や辞書が出した候補は未確定の推測として、確定データとは別の表に置いています。人が選んで初めて、確定したリンクになります [UC-049 §テキストレポジトリのシステム構成]。アノテーション用の画面でも、AI が出した候補の一覧を人が目視でレビューします [UC-049 §安政江戸地震史料への試験適用]。

こうしておけば、どのデータが人に確かめられたもので、どれが AI の推測のままかを後から読み取れます。両者が同じ表に混じると、推測が事実として流通してしまいます。

問題を工程の設計に戻す

AI が作ったものに誤りが見つかったとき、その誤りだけを直して終わらせない進め方があります。ガイドラインシステムでは、生成物に手を加えるのではなく、生成の手順を定めた編集レシピを変えて作り直します。出来上がった料理を直すのではなく、レシピを直して作り直す、という考え方です。検査で見つかった問題点はレシピに反映し、以後の生成に活かします [UC-034 §編集レシピとAI生成構造]。

レシピには、章節構造や各節に書く内容・書かない内容を定める構造、制作と校閲それぞれのエージェントへの指示、表記揺れに対して使うべき表記を定める用語ファイルが含まれます。節ごとに「扱わない範囲」を指定できるので、節どうしの重複も指示で抑えられます [UC-034 §編集レシピとAI生成構造]。誤りを見つけたら、次の生成が同じ誤りをしにくくなるよう工程を直すところまでが、検査の仕事です。

作ったのが AI であることを記録し、伝える

記録の動機は、AI が作ったものを後から読み直し、検証できるようにすることにあります。AI の提案と人の判断の境目の整理は節「AI 時代の研究方法」を参照し、ここでは実践で報告されている記録の仕方を挙げます。

権利の扱いはまだ定まっていません。AI が記事を再構成して書いた部分に著作権が生じるのか、人が指定した構造の編集部分に著作性があるのか、著者は誰か、といった問いが未解決の論点として挙げられています [UC-034 §ガイドラインの版と権利]。

この節へのコメント

  • まだコメントはありません。

4.3 AI で問う・読む

AI で資料を読むには、資料に問いを投げる使い方と、資料を AI が読める形に整える使い方とがある。どちらも、返ってきたものを専門家が評価する工程を前提とする。事例に沿って、共通する設計を述べる。

典拠をたどれる問いかけ

西洋古典の基盤 Humanitext の対話環境 Antiqua は、典拠つきで AI に問う仕組みの一例である。検索は密ベクトルと疎ベクトルを併用するハイブリッド構成で、固有名や術語の一致と、意味的な言い換えの両方を拾う [UC-038 §三つの公開サービス]。回答の記述には引用チップが付き、底本と実際に用いた検索クエリを示す典拠パネルへつながる。何を検索した結果なのかが分からなければ出典の妥当性を判断できないためである [UC-038 §三つの公開サービス]。

答えから原典へ戻れる設計の要は、チャンクの ID を共通にしたことにある。典拠パネルから精読用の Humanitext Reader の同じ箇所を開くことができ、対応はずれない [UC-038 §三つの公開サービス]。答えは参照箇所の ID つきで返り、人間が原典に立ち返って検証できる。もっともらしい答えでも、何に基づく回答なのかが分からなければ使えないからである [UC-038 §デジタル化とAI-Ready化の違い]。問いかけの設計としては、この戻り道が答えの信頼性を支える。検索のためのデータ整備の技術面は、節「テキストから実体を取り出す」「データの格納と情報基盤」を参照されたい。

一方で、柔軟な対話だけでは「線」が通らないという指摘もある。キーワード検索と RAG による AI チャットは、データセットについて尋ねれば記事から取り出して紹介してくれる反面、固定的な出力が得られず、全体として何をやるべきかには答えられない [UC-034 §Agentic Publishingとは何か]。問いに答える使い方と、構造に沿って成果物を構成する使い方とでは、役割が異なる。

読解の工程を部品に分ける

読むことを一つの質問と応答に閉じ込めず、工程に分けて AI を当てはめる設計もある。ヴェーダ文献を対象とする VEDA AI の背後には、読解を五つに整理する見方がある。字を読む、誤りの向こうにある正しいテクストを読む、語形・構文を分析して読む、文脈・背景を調べて読む、関連する別の文献を参照して読む、の五つである [UC-039 §文献を「読む」とはどういうことか]。

VEDA AI はこの見方を工程に写し、読解を取り込み(OCR・誤りの自動修正)、語形を読み(品詞付与・文の分析)、意味を調べ(辞書検索・コーパス検索)、翻訳・註釈を生成する、という部品に分ける [UC-039 §VEDA AI:読解の工程を部品に分ける]。意味を調べる工程は、モデル内部の知識に頼らず辞書に委ねる。サンスクリット語の辞書には 1800 年代にさかのぼるものもあり、100 年以上の積み重ねの知識を取ってくることになるからである。ただし辞書も批判的に読む必要があり、同義語の扱いや語義の取捨は文脈から決めなければならない [UC-039 §VEDA AI:読解の工程を部品に分ける]。

この枠組みは一直線のパイプラインではなく、工程のあいだを行き来しながら翻訳に至る。最終的に見えるのは翻訳だが、途中の形態素解析や辞書検索の結果もそれぞれが出力である。各工程で人が誤りを修正して次へ渡すので、その記録はそのまま将来の学習データにもなる [UC-039 §VEDA AI:読解の工程を部品に分ける]。

部品に分ける利点は、言語や文献に合わせてモデルと資料を差し替えられることにある。ヴェーダ語では OCR に専用の TrOCR-Vedic、形態素解析に ByT5-Sanskrit、辞書検索に CDSL を用いる。日本語の古文に置き換えるなら、OCR は NDLOCR-Lite、形態素解析は MeCab と UniDic、辞書は JMdict という組み合わせが考えられるという。各工程で最適なものを選べば、最初の結果が粗くても読みながら育てていける、というのが目指す姿である。ただし辞書の選定には、専門家のほうがよい辞書を知っているかもしれないという留保が付いている [UC-039 §言語ごとにモデルと資料を差し替える]。画像から文字を読む工程そのものは節「文字を読む」で扱う。

VEDA AI のデモでは、テキストまたは画像の入力から簡易訳・註釈付き訳の比較までを一括で流すことも、人が一つずつ承認・修正することもできる。単語の分割や語形、辞書上の意味は一つずつ表示され、似たテキストの検索も並べて見ながら読み進められる [UC-039 §デモ:一つのテキストを段階的に読む]。AI に任せる範囲と人が確認する範囲を、利用者が工程ごとに決められる設計である。

註釈を伴う翻訳

翻訳や註釈の生成では、訳そのものより、根拠を備えた訳が目指されている。古典研究における翻訳は言語間の置換ではなく、テキストの背景や文化的文脈に基づく解釈の表明であり、註釈はその解釈の過程を読み手に開示するものと位置づけられる [UC-039 §註釈を生成する翻訳モデルという目標]。BOOST 課題では、語釈・文法・儀礼的背景を説明する文献学的註釈を外部知識として与え、周辺知識で翻訳の精度が上がるかを調べている [UC-039 §ワークフローを支える個別の研究]。実験としては、訳してから翻訳判断を説明する順序、訳文と註釈を同時に生成する順序、先に語釈・文法・文献的根拠を整理して訳に反映する順序の三つを予定し、どれが翻訳の妥当性、註釈の根拠性、専門家の評価しやすさを高めるかを比べる [UC-039 §註釈を生成する翻訳モデルという目標]。

Humanitext Reader は、これとは異なる位置づけで翻訳を用いる。AI による文アライメントで 4 言語の対訳を提供し、訳・注が AI による初稿であることを明示する。疑わしい訳は文単位のコメントで議論でき、投稿は自動翻訳されて一つのスレッドに集まる。明らかな誤りは同じパネルから報告でき、キュレーターの確認を経て TEI/XML と訳文に反映される。既存の学術翻訳を置き換えるのではなく、その手前で原典に触れる機会を広げる基盤という位置づけである [UC-038 §三つの公開サービス]。

返ってきたものを専門家が評価する

AI の返答は、確かめる手順を設計に組み込んで初めて使える。Antiqua は典拠パネルを経由して人が原典に戻れるようにしている [UC-038 §三つの公開サービス]。VEDA AI は、BLEU や COMET に加えて、註釈の正確性・有用性・根拠性を専門家に評価してもらう。共有プラットフォームでは、複数モデルの翻訳・註釈を並べて選択・採点し、専門家が註釈を書き換えて根拠資料と判断の履歴を残す。人の修正は、将来の再学習や few-shot 用のデータとして使う [UC-039 §評価・解釈共有プラットフォームと公開したい成果]。

評価をより複雑な設計に組み込む試みもある。SPReAD 1000 の採択研究には、歴史的文書から LLM が生成した知識グラフを、構文・スキーマ準拠性、オントロジー的整合性、原文との事実一致の三つの軸で、生成に使ったものとは別の LLM に評価させ、大学院生による人手評価との一致を測る研究がある。生成したモデルが自分の出力を甘く評価する偏りを避けるのが狙いである。ただし、評価に用いる LLM にも系統的な誤判定のパターンが生じうることが限界として挙げられている [Issues-004 §論点3:AIの出力の検証]。

アンケートからは、評価が必要な理由が具体的に見えてくる。虚偽の回答を出してくること、専門外の情報の妥当性判断が難しいこと、尋ねる事項に知識がなければそのまま信じてしまいうることが挙がり、AI の出力の量に対して読める分量が限られることも指摘された [Issues-002 §論点2:出力の確からしさの確認]。

問いの立て方と再現性

問いの立て方は、まだ型として固まっていない。アンケートには、希望どおりの出力を得るプロンプトが書けない、技術進化が速く再現性を得にくい、プログラミング作業が容易になった反面エラーが起きたときの対応が難しくなった、といった困りごとが並ぶ。知りたいこととしては、プロンプトと結果の実例や、他の人が実際にどのように協働環境を構築しているのかが挙がっている [Issues-002 §論点1:AIの使い方]。

この節へのコメント

  • まだコメントはありません。

4.4 AI エージェントの活用

AI エージェントを研究に使った例は、どの作業を任せ、研究者がどこで確かめたかによって性格が分かれる。ここでは、コードの作成、評価の仕組みを与えたうえでの自律的な改善、史料の震度判定における経過と限界、研究チームとの協働、研究環境の整備、利用者の実感という順に、報告された事例を述べる。三類型や指揮者の概念は節「AI 時代の研究方法」で定義されており、本節はそれを参照するにとどめる。

コードの作成を任せる

最も多く報告されているのは、コードの作成をエージェントに任せる使い方である。参加者アンケートでは、AI の利用目的として「プログラムの作成(コーディング)」を挙げた回答者が有効回答 38 名中 14 名で、文章の作成・要約・翻訳(29 名)や質問・相談・アイデア出し(27 名)より少ない [Issues-002 §調査の方法と回答者の構成]。役立つことの設問には、プログラムが生成 AI でほぼ正確に書けるようになり、書いていた時間をアイデアの検証など他の作業に使えるようになったという記述がある [Issues-002 §論点1:AIの使い方]。

SPReAD 採択研究の発表では、Python でコードを書けない発表者が Gemini にコードを生成させて画像認識システムの実装を進め、非常に有用だと述べている [Issues-004 §論点1:AIを使う研究環境の整え方]。

確認の側には課題が残る。同じ発表では、プロンプトや指示が不十分だと意図と異なるコードが生成されることがあり、生成されたコードを評価・修正するための知識が求められると述べている [Issues-004 §論点1:AIを使う研究環境の整え方]。アンケートでも、プログラミング作業が容易になった反面、希望どおりの出力を得るためのプロンプトが複雑になり、エラーが起きたときの対応が困難だという声がある [Issues-002 §論点1:AIの使い方]。

評価の仕組みを与えて改善を任せる

コードを書かせるだけでなく、改善の試行錯誤そのものを任せた例もある。対象は、『天保郷帳』の約 6 万の村名と他の資料の村との対応づけである。同名が 2 件以上ある村名は行数にして全体の 56.8%(34,394 行)を占め、たとえば田中村は全国に 104 村あり、14 郡では同じ郡の中に複数ある。「駒方新田」と「駒形新田」のような表記の揺れもあり、単純な文字列の一致では対応づけにならず、全件の人手確認も膨大な手間がかかった [UC-049 §対応付け作業の問題:同名地名と表記揺れ]。

この絞り込み方法の改善を Claude に頼んだところ、AI がスコアリング制を提案した。候補を辞書から広く集め、表記・別名・距離・県・石高などの手がかりで加点・減点し、郡ごとに全体で最高点の組み合わせを選び、1 位と 2 位の点差で人手確認の要否を振り分ける方法である [UC-049 §AIエージェントが発案したスコアリング制]。人手確認なしで確定できたのは 60,601 村のうち 47,126 村(77.8%)で、すでに人手で対応づけた村を検証データにして確かめたところ、2,129 行のうち不正解の確定は 16 件(0.75%)だった。人手で確認が必要な件数は 1.9 万件から 1.3 万件に減り、100 万円以上の経費減になった [UC-049 §AIエージェントが発案したスコアリング制]。研究者がしたのは、絞り込み方法の改善を AI に頼むことだけだった [UC-049 §AIによる改善が機能した理由とループエンジニアリング]。

この例を支えた条件は二つ報告されている。一つは、人手による検証データがあったため、人間が具体的に指示しなくても AI がさまざまな方法を試せたこと。もう一つは、施策の効果を即座に検証できたため、AI が高速に PDCA サイクルを回せたことである [UC-049 §AIによる改善が機能した理由とループエンジニアリング]。この手法はループエンジニアリングと呼ばれ、人間は AI がタスクをどれだけうまくこなしたかを評価する仕組みを用意し、AI はその評価結果が良くなるように自律的にサイクルを回す方式として説明されている [UC-049 §AIによる改善が機能した理由とループエンジニアリング]。この例で研究者が確かめる場所は、個々の出力ではなく、評価に使う検証データと評価の仕組みに置かれていた。

史料の震度判定で見えた限界と、人に残る責任

大量に処理できることの裏側を示すのが、歴史地震の被害記述から震度を判定する事例である。この事例では、コードを書けない研究者がエージェントに実装を任せている。

最初の実験では、史料の URL から本文を取得し、長文から地点を抜き出して震度を判定するアプリを自作した。安政江戸地震の史料である別本「藤岡屋日記」上の約 2 万文字から約 160 地点を抽出し、そのうち 140 件の震度を判定した(残る 20 件は火災などによる被害で判定不能)。報告者の確認では、160 地点中の 8 割で「適切」「概ね適切」な基準を使っていた。ところが、同じプロンプトで史料 790 件を大量に処理すると、判定したのは 20 か所にとどまり、適切な基準の使用は 66% から 45% に下がって、不適切は 5% から 15% に増えた。量が増えると取りこぼしと精度の低下が起きたため、構造化されていないテキストからいきなり地点の抽出と震度判定の両方を行わせる方式には限界があると考え、処理を再設計した [UC-048 §第1実験:史料を一括処理するアプリとその課題]。

再設計したツールで同じ史料の約 2 万文字を処理すると、抽出した被害記述は 160 件から 461 件へと約 3 倍に増えた。タグ付けで地名だけでなく、震度判定の対象になる構造物まで対象に入れたことが大きいと見られている。461 件のうち 315 件(68%)で震度を判定し、146 件は判定不能とした。適切な基準を使っているかの AI による自己判定は、妥当 264 件(84%)、注意 4 件(1%)、警告 47 件(15%)で、注意と警告の行は人が再判定に回す。人による確認はこれからである [UC-048 §第2実験の結果]。

この経過を踏まえて、報告された限界は次の五点である [UC-048 §限界と人間に残る責任]。

  • 読めないコードは、壊れたときに自力では直せない。
  • モデルは日々更新され、同じ入力でも結果が変わりうるため、モデル名と日時を記録している。
  • API の利用料がかかり、誰でも同じ条件で使えるわけではない。
  • 件数を増やすと誤りも増えた。大量に処理できることは、誤りも大量に生むことでもある。
  • AI の説明が冗長・難解で理解が追いつかないことがあり、分かったつもりで採用せず、分かるまで聞き直している。

そのうえで、人間に残る責任として、何を変えないかを決めること、結果を史料で確かめること、AI の提案の採否を決めることの三つが示されている。報告者はこのあり方を「Historian in the Loop」ではないかと述べている [UC-048 §限界と人間に残る責任]。この事例で確かめる場所は、件数の増加で基準の使い方がどう変わるかという処理全体の傾向と、個々の判定を史料に照らす点の双方にある。

設計は人が決め、実装はエージェントが担う

西洋古典テクスト基盤 Humanitext では、3 人の研究者の共同研究として、設計や方針をチームが相談して決め、実装を AI エージェントが担う分担をとっている。AI の側がより適切な設計案を示してくることも多く、協働の実感はチームの一員に近い。ただし、何を採用するかという最終的な意思決定は常に人間のチームが行う [UC-038 §研究チームとAIの協働]。

この分担を支えたのは、判断を文書として残すことだった。決定した事項、採用しなかった案とその理由、生じた不具合を各リポジトリの AGENTS.md に記録し、以後のセッションで最初にエージェントへ読ませている [UC-038 §研究チームとAIの協働]。報告によれば、3 つのサービスを一から構築して維持できているのは AI の支援によるところが大きく、外部委託や大規模な開発体制なしには実現できなかったシステムを、研究上の判断と直結した形で作れるようになりつつある [UC-038 §研究チームとAIの協働]。

研究環境の中にエージェントを組み込む

研究の進め方そのものにコーディング支援エージェントを組み込む計画も、複数の発表で示されている。ある発表では、プログラマではない研究者が実験の設計と判断を担い、Claude Code 上に作成とレビューを分けたエージェントの組織を置いた。さらに別のモデルを外部のレビュワーとし、コードと統計の最終確認は人間の補助者が行う体制をとっている [Issues-004 §論点1:AIを使う研究環境の整え方]。ここでは、確かめる役割が、別のエージェント、別のモデル、人間の補助者へと段階的に分けられている。

動かす場所の選択も、確かめ方の設計の一部である。未公開の学術調査写真の解析や、機微情報・著作権で保護された資料を扱う研究では、外部に送り出さずに解析するために、ローカル環境で LLM を動かす計画が複数の発表に見られる [Issues-004 §論点1:AIを使う研究環境の整え方]。

日常の作業への手応え

利用者の実感としては、時間の短縮が最も多く挙げられている。体裁の調整にかけていた時間が大幅に短縮され、本質的な作業に向き合う時間を長く取れるようになったという回答や、自分の書いた文章のレビューを何度も簡単に行えるようになったという回答がある [Issues-002 §論点1:AIの使い方]。

一方、どう使うかの実例を求める声は強い。アンケートでは、AI を使って達成できたプロジェクトや研究、プロンプトと結果の実例を知りたいという回答がある [Issues-002 §論点1:AIの使い方]。エージェントを協調させる方法についても、プログラマやエンジニア向けの情報は手に入りやすいが、もっと一般的なタスクでの使い方の勘どころが知りたいという回答がある [Issues-002 §論点1:AIの使い方]。ただし、回答者の構成は偏っている。有効回答 38 名のうち、ほぼ毎日使っている人が 17 名で、満足度の設問も肯定的な層に偏っている [Issues-002 §調査の方法と回答者の構成]。

文書の生成と検査の具体例としては、DiHuCo ガイドラインシステムの工程がある。その流れは節「AI でデータを作る」で扱う。

この節へのコメント

  • まだコメントはありません。

4.5 AI と社会

AI を研究に使うことは、研究室の内側にとどまらず、権利、費用、言語、地域といった社会の側の条件に結びついている。この節は、2026年8月のDiHuCoハブシンポジウムの参加者アンケートと、SPReAD 1000の採択研究の報告、および講演の記録をおもな手がかりに、その結びつきを整理する。

入力と学習をめぐる懸念

アンケートには、機密情報を含まないファイルでも、そのドキュメントを入力してよいか躊躇するという記述があった。組織内でAI利用への理解度に差があると、個人情報や機密情報が漏れる危険が高まるのではないかという指摘もある [Issues-002 §論点4:入力したデータの行方]。

学習をめぐる気がかりも並ぶ。入力内容が学習されること、誰かの文章がそのまま表示されること、「学習されない」権利を守る仕組みが分からないことが、問題だと思うこと・気がかりなことの設問に書かれていた。ある回答は、AI の性能向上には人文学の資料を学習させる必要があるとしつつ、その学習が権利をないがしろにせず、労働力や環境資源を搾取しない、持続的で協働的な学習の仕組みが求められると述べている [Issues-002 §論点4:入力したデータの行方]。

この懸念への一つの対応が、AI をローカル環境で動かす選択である。SPReAD 1000の発表では、未公開の学術調査写真を解析する研究、機微情報や著作権で保護された資料を扱う国際法の研究、個人情報をローカルのLLMで扱う歴史地理の研究が、手元の環境でLLMを動かす計画を示している。目指されているのは、未公開の画像や機密性の高いデータを外部に送り出さずに解析できる環境である [Issues-004 §論点1:AIを使う研究環境の整え方]。一方、ローカルで動かせるLLMにどんな選択肢があるのかが分からないことも、同じ発表群で課題に挙がっている [Issues-004 §論点1:AIを使う研究環境の整え方]。

公開した学術データの行方

データを公開する側にも気がかりがある。アンケートには、日本の研究が海外企業に収集されていくことへの懸念があり、日本の学術界全体で使える信頼性の高いクラウドや、閉じた空間で日本独自の学術データを蓄積できる場があるとよいという意見も出ていた。生成AIサービスによるリポジトリへの大量アクセスを取り上げた回答は、学術データの公開とそのコストの工面を検討する必要があるとしている [Issues-002 §論点4:入力したデータの行方]。公開を促す動きがある一方で、その公開が誰に、どの規模で利用されるかを見通しにくいという事情がここにある。公開の権利処理そのものは、節「ライセンスの選び方と権利処理」を参照。

SPReAD 1000の発表でも、データ公開に必要な許可・寄託先・費用といった手続きの複雑さが挙げられている [Issues-004 §まとめ]。

基準の動きと、学習データによる偏りと不在

アンケートには、AI によってスタンダードが変わり、誤った答えが正当化されてしまうのではないかという気がかりが寄せられた [Issues-002 §論点2:出力の確からしさの確認]。出力の確かめ方は節「AI で問う・読む」の扱いである。ここで問題になるのは、確かめる手順ではなく、基準が社会の側で動いていくことであり、その動きの一因が、学習データに何が入っているかにある。

出力の偏りは、学習データに何が入っているかに由来する。アンケートのある回答は、年代と地域によって回答や成果に偏りが出ると述べ、特に年代は戦後から1960年代、地域は非英語圏で偏りを感じるとしている。同じ回答は、複数の AI モデルを使うことが批判的な回答を生み出せるのかを問い、普及している生成AIモデルの多くが英語圏で開発され、学習されていることへの懸念を添えている [Issues-002 §論点2:出力の確からしさの確認]。

学習データに入っていないものは、AI の出力にそもそも現れない。顔コレの事例では、AI は学習したことを出力しているにすぎず、学習していないタイプの画像を与えるとまったく認識できないため、何を学習し、何を正解できるようになっているかを常に考えながら使うことが大切だとされている。データの解釈も機械が支援する「遠読」には新たな可能性が広がる反面、方法論の危うさも共存するため、リスクを認識しながら進める必要があるという [BP-005 §解釈の手がかりとしてのデータ]。出力の誤りは検証で見つけられても、現れなかったものの不在は、出力を読むだけでは気づきにくい。

偏りは一人ひとりの出力にとどまらない。アンケートには、個々人としての恩恵は大きいけれども、社会全体が似たような方向に進んでしまわないかという心配も寄せられている [Issues-002 §論点3:人間が担う範囲の見極め]。

SPReAD 1000には、この不在を埋めようとする構想がある。既存の翻訳資料を学習データとして生かす構想や、動物種が判明している資料を学習に加えて正答率が向上した試行である。評価手法を歴史学以外のDH分野へ、コーパス構築の手法をチベット語や梵語などの他の低資源言語へ広げる構想も示されている [Issues-004 §まとめ]。

費用と環境の非対称

AI の利用には費用がかかる。アンケートでは、無料枠では一日の利用可能枠がすぐに尽きること、月払いのプランが多く研究費で利用料を執行しにくいこと、研究費のない人が私費で有料アカウントを持つかどうか悩むこと(格差の拡大)が挙がった。気がかりとして、将来の使用料金の引き上げ、学術ジャーナルの高額な購読料と同様の問題がAIでも起きるのではないかということ、海外に経済的利益が流れていくこと、課金が正義となること、経済力のない者は滅ぶことが並んでいる。いろいろな AI を試したいが、課金しないと本当のところは分からず、無制限に課金する経済力がないという回答もあった [Issues-002 §論点5:利用料の負担]。

研究環境の非対称は、費用だけにとどまらない。SPReAD 1000の事業ページは、AI導入の伴走支援を設ける背景として、データの形式や量、適切なモデルの選択、計算資源の確保、データ管理への対応といった課題と、研究者等の間のAIに関する知識や経験の差を挙げている [Issues-004 §まとめ]。

AI が見つけさせるもの、見つけさせないもの

見つけさせる側については、嵯峨本の研究に具体的な記述がある。古活字の分割と同定は、AI との協働で大きく前進した。ただし、分割は他の本への一般化が課題として残り、同定は性能の改善を続けていて最終的な結果には至っていない [UC-043 §知見と展望]。見つかったものがその対象の範囲にとどまることは、この例からも読み取れる。

見つけさせない側については、学習データの偏りと不在に加え、社会との接続の面も論じられている。ある講演は、研究活動の主体は人間であり、AI が研究する時代に入ったわけではないと述べる。AI を一切使わずに研究を続ける人がいても、その研究者が自身の研究に意義を失うことはないだろうという。ただし、そうした研究は社会との接続ができていないかもしれず、現在の人文学研究の多くは社会とのつながりを条件としないからこそ成立しているのかもしれないという留保が重ねられている。そのうえで、AI は社会とのつながりをつくる手法を支援するところに意義があり、人文学のイノベーションはそこにあるのではないかという見立てが示されている [UC-036 §Agentic DHにおける研究行為の再配置]。研究者像や教育への影響は、節「AI 時代の研究方法」を参照。

この節へのコメント

  • まだコメントはありません。

5 オープンサイエンス

作ったデータを研究者が自分で公開し、使われ続ける状態にするための実務をまとめる。

5.1 識別子とデータ引用

識別子を振るとは、対象となるまとまり(エンティティ)を列挙して番号や文字列を割り当て、同じ識別子を持つものは同じもの、違う識別子を持つものは違うものとみなすことである [UC-044 §歴史ビッグデータの作り方と使い方]。識別子と属性の組をデータセットにして、実世界との紐づけとデータ統合に使うという考え方の土台でもある [UC-013 §識別子と属性によるデータ構築の基本方針]。ここでは、何に識別子を振るか、どう設計するか、永続的な参照をどう担保するかを、記事に現れた事例から整理する。

何に識別子を振るか

事例では、識別子は資料そのものではなく、資料の中に繰り返し現れる単位に与えられている。江戸・明治時代の藩には識別子と別名が定義され [UC-012 §藩IDデータセット]、市区町村には、公式のコードがない1889年から1968年の期間を含めて、複数のデータセットを統合した一意の識別子が付与された。各識別子は代表点と時期ごとの境界を属性に持つ [UC-010 §歴史的行政区域データセット]。

道と点にも識別子が振られている。人や物資の移動を「あるIDから別のIDへ」という識別子間の経路で表せれば、構造化を効率化できるという発想である [UC-012 §江戸期地理データセット]。

識別子を振る利点として、複数の資料で表記が揺れていた名称を識別子で結合・統合でき、他データとの連携が大幅に容易になったことが報告されている [UC-012 §藩IDデータセット]。別名をひとまとめにしておけば、別名をOR検索でつないで対象ごとの研究の多さを調べるといった使い方もできる [UC-044 §藩IDデータセット:何を同じ藩とみなし]。

識別子設計の論点

識別子の設計で最も難しいのは、何を同じエンティティとみなすかの基準である。表記揺れがあるため、この基準が重要になる [UC-013 §識別子と属性によるデータ構築の基本方針]。判断基準は非常に難しいという認識も示されている [UC-044 §歴史ビッグデータの作り方と使い方]。同一性の基準を決めたうえで、代表となる名前と別名も決める必要がある。

識別子の対象どうしが一対一にならない場合は、対応する識別子を別に立てる必要がある [UC-013 §藩IDデータセット——識別子の付与と研究動向の可視化]。対象の状態が変わるイベントを識別子の変更として扱うなら、体系はさらに複雑になる [UC-012 §藩IDデータセット]。

歴史的な単位に固有の同定の難しさと、藩を例にした具体的な決め方は、『時間をもつ空間』を参照されたい。

番号体系を設計する

道や点の識別子では、既存の体系に倣う設計が採られている。道(線)は高速道路ナンバリングに、点は駅ナンバリングに倣う [UC-012 §江戸期地理データセット]。五街道にはR001〜R005を特例として与え、地域ごとの主要街道にはR1XXからR9XXを与える [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。

番号には規則を持たせることもできる。百の位に地方を割り当て(1が北海道、2が東北、3が関東など)、下二桁を基幹街道かどうかで分ける [UC-045 §街道ナンバリング]。たとえば日光御成道はR302で、関東の基幹街道にあたる。基幹街道の基準は地方ごとに異なり、関東は公的な格、東北などは広域の幹線を基準とする [UC-045 §街道ナンバリング]。

宿場は、街道との組み合わせで番号が付く。東海道の品川宿はR001-002で、移動を宿場ID間の経路として表現できる [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。街道を一本ずつ識別できるようにすることは、データを再利用可能にする前提でもある [UC-045 §街道ナンバリング]。街道の同定そのものの難しさは『時間をもつ空間』を参照されたい。

一意に定まらないものの扱い

位置が一意に定まらない場合には、曖昧さを識別子自体に含める方法が試みられている。石川藩の陣屋は候補が複数あり一つに決められないため、Uber H3インデックスの六角形で位置の範囲を指定している。この識別子は場所と六角形の大きさを一つの文字列で同時に指定できるので、識別子自体に曖昧さのレベルが含まれる [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。

識別子を貼り合わせる

識別子はそれだけで完結せず、他のデータセットとの貼り合わせの軸になる。藩の識別子は多くが『日本歴史地名大系』とリンクされ、居城などの情報をたどれる [UC-012 §藩IDデータセット]。代表点や領域の可視化、他のデータとの連携も、識別子を介して進められる [UC-012 §藩IDデータセット]。

永続的な参照をどう担保するか

付与した識別子を登録して共有する基盤として、GeoLODが整備されている。GeoLODは地名データセットに地名IDを付与するシステムで、属性表示や検索をウェブとAPIから利用でき、オンラインで地名辞書を構築・共有する機能も提供する。藩・街道・宿場に付与した識別子はここに登録される [UC-033 §地名のデータセット:藩・街道・宿場とGeoLOD]。識別子を登録する場があれば、それぞれの識別子を、データの出自を離れて指し示せるようになる。

データを業績として引用してもらうこと

データセットを公開するとき、そのデータ自体が参照されるためには、CC-BYのような引用を前提とするライセンスで公開する方法がある。江戸主要街道データセットは、CODHとの共同で作成され、CC-BYで公開されている [UC-045 §CODHとの共同によるオープンデータ化]。ライセンスの選び方そのものは『ライセンスの選び方と権利処理』が扱う。

データの作成側の継続に関しては、オープンデータの作成、サービスの運用、専門家の参加のいずれにも継続的な資金が必要だという指摘がある [UC-033 §ユースケースの共有と今後の課題]。識別子を振って共有することは、データを共同で利用し、更新する仕組みの前提でもある。誤りの混入しやすい大規模な歴史データを相互に比較して修正するためには、共通の識別子が手がかりになる [UC-033 §ユースケースの共有と今後の課題]。ただし、この文脈で識別子の役割が明示的に論じられているわけではなく、ここは本節の読み取りである。

この節へのコメント

  • まだコメントはありません。

5.2 ライセンスの選び方と権利処理

ライセンスと権利処理をめぐる材料は限られている。以下は、成果物の権利をめぐる問い、何を開き何を閉じるかの戦略、利用条件の表示の三つの面から、記事が述べている範囲を整理したものである。なお、ライセンスの選択を担う節ではあるが、主なライセンスの条件の違いやその帰結を述べた材料は今回の記事群になく、特定の事例で採られた方針や表示の紹介にとどまる。

素材の権利と成果物の権利は別に問われる

素材の権利と成果物の権利は別の層にある。ガイドライン自体の公開が、その具体例になっている。ガイドラインは三つの版で管理される。作業版は常に更新され、AI によって内容も書き換えられるため引用には向かない。候補版は作業版を凍結した版で、以後はコミュニティからの提案に基づいて修正される。承認版はコミュニティの承認を得た版で、以後は更新されず、安定した引用ができる。この状態遷移は、インターネットの執筆プロセスである IETF RFC を参照している [UC-034 §ガイドラインの版と権利]。

素材にあたる記事の権利は、この枠組みのなかでは整理されている。ガイドラインが参照する記事は、講演者と DiHuCo の共同著者として CC BY ライセンスで公開される [UC-034 §ガイドラインの版と権利]。権利の所在が不明確になるのは成果物の側である。

  • 記事を元に AI が再構成して執筆した部分には、著作権が生じないのではないかという問いが示されている。
  • 他方で、構造は人間が指定したものであり、その編集部分には著作性があるとも考えられる。
  • 全体は CC BY-NC 相当のライセンスで公開する方針だが、著者は誰か、権利はどこに宿るかは今後の議論が必要とされている。

この論点に結論は出ておらず、問いとして残っている [UC-034 §ガイドラインの版と権利]。素材を CC BY で公開し、成果物の全体に別の条件を付す方針を採る場合でも、AI が再構成した部分と人間が構造を与えた部分とで権利の及び方が異なりうる点は、公開の設計に含めて考える必要がある。

何を開き、何を閉じるかを共同の相手と決める

公開の条件は、単独で決めるだけでなく、データを持つ企業との共同のなかで決める場合がある。江戸時代の空間的エンティティを扱う取り組みでは、地理情報を扱う企業と共同してオープンデータが作られている。

  • 平凡社地図出版による『日本歴史地名大系』地名データのオープン化
  • 株式会社 MIERUNE による「れきちず」地図データのオープン化

これらの事例では、何をオープンにし何をクローズドにするか、ライセンスをどう設定するかを工夫し、双方にメリットのある形を目指している。広く共有したうえで別のプラットフォームに統合して利用する流れが想定されている [UC-012 §今後の展望と課題]。

開く範囲を一律に決めず、共同する側の事情に合わせて開く部分と閉じる部分を切り分ける、という戦略である。公開してよいかどうかの判断そのものは「公開できるもの・できないもの」で扱うため、ここではライセンスの設定が共同の条件づくりの一部になっていることだけを指摘しておく。

利用条件の表示としてのライセンスと PDM

デジタルアーカイブを提供する側の話題には、持続可能性や OSS、DOI などと並んで、利用条件・ライセンスが挙がる。具体的には CC License や PDM(Public Domain Mark)が示される [UC-003 §デジタルアーカイブの情報学的利活用と IIIF Curation Platform]。提供側が利用条件を明示するという枠組みは、ここで確認できる。パブリックドメインの資料をどう使うか、あるいは各ライセンスを選んだときに何が帰結するかについては、この記事は述べていない。

この節へのコメント

  • まだコメントはありません。

5.3 公開できるもの・できないもの

公開の可否は、データ全体にひとつの答えを出すのではなく、データの中の属性ごとに考える。個人を特定しうる記述、人が写った画像、位置の精度、権利の状態は、それぞれ別の理由で公開を制限し、別の方法で緩和できる。全部を開けないときも、何を開き、どこまで粗くするかを選べる。

公開の可否を左右する情報の類型

個人を特定できる情報は、もっとも慎重に扱う類型である。住所や氏名のように、単独または組み合わせで個人を指せる属性は、歴史的資料として集められたものであっても、現存する人物や遺族に影響しうる。

人が写った写真や映像では、写り込んだ人物の同意の有無が問題になる。街頭や地域のフィールドワークで撮った記録は、研究目的であっても、写った人の意図と切り離せない。

位置情報は、精度によって公開の可否が変わる。正確な座標が特定の個人の居住地や行動と結びつくと、精度そのものがリスクになる。関東大震災の死亡者住所をジオコーディングした事例では、変換結果を1点1人の死者として約3万8千件プロットしたうえで、点の重なりを解消するために100メートル四方のメッシュで集計し直した。このとき、区(レベル4)止まりにしか特定できない地点は集計から除外している [UC-032 §死亡者住所分布の可視化と全体傾向]。個別の点を示さなくても、本所区・深川区を中心とする被害の偏りは集計から読み取れる [UC-032 §死亡者住所分布の可視化と全体傾向]。精度の段階を意図して選ぶという考え方は、位置情報に限らず、属性情報一般に応用できる。

権利が処理できていない資料は、この節では開けない部分として切り分けて扱う。公開できる範囲を決める側の判断として、その資料を除いて残りを開くか、記述だけを示すか、範囲を粗くするかを選ぶ。ライセンスの選択と権利処理の詳細は節「ライセンスの選び方と権利処理」の担当である。

全部を開けないときに何を開くか

公開できない情報が混じるとき、選択肢は全公開か非公開かの二つに限られない。

記述だけを公開する方法では、資料の存在と性格をメタデータとして示し、個別の記録の中身は閉じる。どのような資料がどこにあるかが伝わり、中身は問い合わせへの個別対応に回せる。

精度を落として公開する方法では、粒度を粗くしたうえで開く。上の震災死亡者の事例は、点を面(メッシュ)に集計し直すことでこの対応をとった。年齢を十年刻みに丸めるのも同じ考え方である。

範囲を粗くして公開する方法では、地理的範囲・期間・属性のうち識別リスクの高い部分を切り出して閉じ、残りを開く。

三つの方法は排他的ではなく、組み合わせて使える。たとえば、範囲を絞ったうえで、残りの範囲の位置を粗いメッシュにする。

判断の理由を残す

何を公開し何を閉じたかに加えて、その理由を記録しておく。理由が残っていれば、問い合わせに答えるときや状況が変わって方針を見直すときに、担当者が同じ論点を一から組み直さずに済む。公開後に撤回や更新を検討する場面でも、当初の意図が見直しの出発点になる。精度を落とした場合は、どの基準で何を除外したか(上の例なら、区止まりの地点を除外したこと)もあわせて記すと、公開したデータの限界が利用者に伝わる。

この節へのコメント

  • まだコメントはありません。

5.4 公開したあと

公開はゴールではなく、長い後半戦の始まりである。更新と版の管理、撤回、リンクの維持、形式の陳腐化への対処、誰が何をしたかの記録が要る。地理・画像・三次元のデータは、ファイルが大きい、形式が変わる、配信に専用の仕組みを要するといった事情で、これらがとくに切迫した形で現れるはずである。ただし、この節に紐づく記事は三次元データの事例一件のみで、その事例が直接示すのはメタデータの設計と配信基盤、配信先の消失にとどまる。

更新・版管理・撤回

データセットは公開後も修正や拡張が続く。どの版がいつ公開され、何が変わったかの記録がなければ、引用した研究者は後から同じデータを参照できない。撤回も記録の問題である。データを非公開に戻した場合、その事実と理由を残さなければ、リンクが単に切れたのか、意図的に下げられたのかが判別できない。

ここまでは一般的な論の組み立てであり、記事の裏づけはない。版の命名や撤回通知の出し方といった具体的な運用は、記事から導けない。

リンクが切れること、形式が読めなくなること

公開したデータへの参照は、二つの経路で壊れていく。URL が無効になることと、形式が将来のソフトウェアで読めなくなることである。

形式の陳腐化への備えとして、標準に沿ったメタデータ記述が働きうるという読みを、バム遺跡の三次元復元の事例から引き出せる。この事例では公開にあたり、資源をクラスとして体系化して記述するオントロジー的な方法を採り、語彙には Dublin Core などの標準を組み合わせ、国際標準のメタデータとして Object ID も利用した。メタデータの作成にはオントロジーエディターの Protégé を用い、公開には RDF ストアに PostgreSQL、RDF の API に Apache Jena を用いている [UC-020 §メタデータの管理と公開]。標準ベースの記述なら、データの形式が変わってもメタデータの意味を保ちやすいはずだというのは、この節の読みであって記事の主張ではない。記事が述べるのはメタデータの設計と使った道具までで、三次元データそのものの形式の移行には踏み込んでいない。

標準に沿った記述をしていても、配信先の維持は別の問題として残る。同プロジェクトは Bam3DCG というサイトでデータの一部を公開していた [UC-020 §メタデータの管理と公開]。記事の改訂記録によれば、このサイトへのリンクは切れていること(404)が確認され、関連リンクから削除された [UC-020 §関連リンク]。標準的なメタデータを備えていても、配信先そのものの消失は防げなかった。

誰が何をしたかの記録

データの来歴と処理の記録は、再利用と検証の前提になる。バム遺跡の事例では、オントロジー的な記述を採った背景に共同研究者のオントロジー研究があったこと、メタデータの作成にオントロジーエディターの Protégé を使ったことが記されている [UC-020 §メタデータの管理と公開]。誰がどの処理をどの道具で行ったかが残っていれば、後からデータを使う研究者は、その処理の信頼性を自分で評価できる。ただし、この事例が示すのは作成者の背景と使った道具の記録にとどまり、処理の履歴を体系的に残す仕組みまでは述べていない。

地理・画像・三次元のデータに固有の難しさ

ファイルが大きい、形式が変わる、配信に仕組みが要る、という三点が、地理・画像・三次元のデータに固有の難しさだと考えられる。このうち記事から裏づけられるのは、配信の仕組みの側だけである。

配信の側では、メタデータの標準化に加えて、RDF ストアや API のような技術基盤が伴うことを、バム遺跡の事例から読み取れる [UC-020 §メタデータの管理と公開]。こうした基盤は、データを一度置くだけでなく、機械的に参照できる状態で維持するために要る。ただしその運用コストや担い手をどう確保するかは、この事例からは分からない。

この節へのコメント

  • まだコメントはありません。

6 社会のなかの実践

研究が社会と接する場面をまとめる。まず研究を開くとはどういうことかを述べ、そのうえで分野ごとの実践を見る。

6.1 パブリック・ヒューマニティーズ

研究を専門家の外へ開くとは、成果を公開することにとどまらず、問いを立てる人、方法を組み立てる人、成果を検証する人を専門家の外にも広げることを含みます。以下では、開いたときに研究の側が何に変わるかを、問い・著者・専門性の三点から整理します。

市民が問いを立てる側に回る

公開された資料を市民が受け取るだけの関係と、市民が自ら問いを立てる関係とでは、研究の構図が異なります。デジタル・パブリック・ヒューマニティーズは、パブリック・ヒューマニティーズに単にデジタルを追加したものではありません。AI による変革によって、市民研究者が専門家の成果を受け取るだけでなく、自ら問いを立て、独自の知的活動を行い、成果を社会に返すことを可能にする構想として提唱されています [UC-036 §市民に開かれる人文学とその条件]。この構想では、AI は専門家の代替ではなく、市民が知の生産に参加するための足場と位置づけられています [UC-036 §市民に開かれる人文学とその条件]。

この構想の前提は、技術の習得が研究に入る条件でなくなったことです。教育現場で学生に起きたその変化は、一般市民にも起こり得ると考えられています [UC-036 §市民に開かれる人文学とその条件]。変化そのものの詳細は「AI 時代の研究方法」を参照してください。本節の関心は、入場資格が外れたことで人文学の素養を持つ人が専門家の外にも現れ得て、誰が問いを立てられるかが広がるという波及にあります。

参加が理解を変える

専門家の外へ開く形は、成果の受け手を増やすことだけではありません。研究の手順の一部に市民が加わる形もあります。同一構図の写真を画素レベルで比較すると、人が気づかないような微細な変化が明らかになることがあります。これは写真を研究する人だけでなく、撮影に参加する人にとってもユニークな体験で、何が変わり、何が変わっていないかを実感を伴って理解できるとされています [UC-016 §景観を「読む」ための新しい技術]。この活動は、多くの人が自分のスマートフォンで気軽に参加できるコミュニティアーカイブの一環として進められています。「スマホで三条 まちなみの変遷発見ラリー」のような市民による活動として、写真が活用されています [UC-016 §景観を「読む」ための新しい技術]。ここでの参加者は、研究資料を眺めるのではなく、資料を生み出す側に立ち、その過程で景観の見え方を学びます。

ただし、景観をうまく読み取る技術は、その場所や景観についての知識に依存します。場所をよく知っていれば、どこから撮ればよいかを容易に判断できますが、知らなければ理解に時間がかかります [UC-016 §景観を「読む」ための新しい技術]。参加の入口が広がっても、読み取りの深さは土地についての知識に左右されます。専門家の外に開くことは、知識の差をなくすのではなく、その差が成果に現れる場を増やすことでもあります。

誰が著者になるか

開いた研究では、成果の著者が誰かという問いが避けられません。市民が知の生産に参加できるようになっても、大学や博物館の役割が小さくなるわけではないとされています [UC-036 §市民に開かれる人文学とその条件]。市民が研究の主体になる場合、成果は専門家に帰属するものとして固定されません。市民自身が問いを立て、成果を社会に返す側に回ります [UC-036 §市民に開かれる人文学とその条件]。AI を使った研究での著者性・責任・評価の揺らぎは、「AI 時代の研究方法」を参照してください。参加者のクレジットの配分といった運営上の取り決めは、本節の範囲を超えます。

専門性はどこに残るか

開くことで専門性が不要になるわけではなく、専門性の置き場所が変わります。大学や博物館に求められるのは、信頼できるデータとメタデータを整備し、学び方を提供し、成果を検証し、権利やプライバシーを守り、専門家と市民が対話する場を作ることだとされています [UC-036 §市民に開かれる人文学とその条件]。専門家は成果を一方的に届ける立場から、市民の研究が成り立つ条件を整える立場へ移ります。

これは、アクセスの開放だけではなく研究する能力と責任を社会に開くことであり、Agentic DH 時代の公共性だと表現されています [UC-036 §市民に開かれる人文学とその条件]。同様に、Agentic DH の時代は人文学が弱くなる時代ではなく、人文学の関わりが社会の中で再び広がる時代だという期待も述べられています [UC-036 §デザイン・アート学部と文化創成学]。

開くことが研究の質に返ってくる筋道

開くことは、研究の側にも変化をもたらします。現在の人文学研究の多くは社会とのつながりを条件としないからこそ成立しているのかもしれず、その意味で人文学者は社会とつながるという手段を拒絶してきた、あるいは煩わしいと考えてきたのではないかという問いが立てられています [UC-036 §Agentic DHにおける研究行為の再配置]。その手段が簡単に獲得できるようになれば何かが始まり、人文学のイノベーションは社会とのつながりをつくる手法を支援するところにあるのではないかという見立てが示されています [UC-036 §Agentic DHにおける研究行為の再配置]。

具体例として、ARC が収蔵した『酒呑童子絵巻』は、修復とデジタル化から展覧会、コンテンツ化、学生の指導へと展開しました。これは、研究素材と研究活動と社会を結びつける実例として挙げられています [UC-036 §研究成果を社会につなぐ:酒呑童子絵巻とARCの展開]。絵巻の首が飛ぶ場面を AI で動かしたプロモーション映像は、研究活動ではないと断られたうえで、社会との接点を作る着想として意外に評判が良かったと紹介されています [UC-036 §研究成果を社会につなぐ:酒呑童子絵巻とARCの展開]。

筋道としては、開くことで資料の読み方や成果の使われ方が増え、その応答が研究の素材と方法を組み替えます。写真の例では、参加者が同一構図の写真を撮ることで、微細な変化を実感を伴って理解でき、場所の知識の有無が読み取りの深さを左右することが見えてきます [UC-016 §景観を「読む」ための新しい技術]。視覚資料を空間的な文脈の中で解釈する営みは、新しい技術やスキルを要するもので、資料の価値や意味を批判的に読み解く「digitally-enabled criticism」と呼ばれています [UC-016 §景観を「読む」ための新しい技術]。開かれた場での読みが、批判的な読解の技術を鍛え直す契機になるとも言えます。

この節へのコメント

  • まだコメントはありません。

6.2 地域とともに進める

研究者が地域の人と現地を歩き、写真を手がかりに語り合う。この営みは、研究として成り立つことと、催しや授業として成り立つことを同時に満たす設計を要する。以下では、参加の設計、現地で起きること、参加者が主体になる構造、連携先との関係、記憶収集の形式の選び方、研究が地域から受け取るものの順に述べる。

参加の設計:誰を誘い、何を持ち込むか

同じ手法でも、誰を対象にするかで企画は大きく変わる。大阪大学D3センターの実践は、2017年頃の展示会・トークイベント中心の段階から、特定地域のまちづくり団体を対象にした実証実験、大学生による企画、中学生との授業へと、対象を替えながら重心を移してきた [UC-005 §活動のフレームワークと展開]。

観光施設の事例では、応募の入口そのものが設計の一部になっている。グラバー園の「スマホで古写真ハンティング」は応募をGoogleフォームに限定し、フォームを操作できる程度のスマホ利用力を応募段階で確認した。告知は新聞、公式HP、公式SNS、市の公式LINEを使い分けた [UC-030 §イベントの企画と参加者募集]。事前メールでは、自分のスマホの持参、位置情報のオン、通信費の自己負担、小学生以下は保護者同伴、公共交通機関の利用を伝えた。位置情報のオンに抵抗がある人が混ざると当日の運営が成り立たないため、この点は応募段階で合意を取っている [UC-030 §事前案内・配布冊子と街歩きの運営]。当日は散策冊子を配り、アプリで紹介しきれない見どころを持ち帰れる形にした。スマホに含まれない建物情報は、ガイドが紙のファイルで補っている [UC-030 §事前案内・配布冊子と街歩きの運営]。

この事例の参加者は、最大30名の想定に対して11名にとどまった [UC-030 §イベントの企画と参加者募集]。前提とする操作力を応募段階で確かめる設計は、運営を安定させる一方で、誰にでも開く形とは緊張関係にある。

誘導の厚みも設計の要点になる。長崎の実証実験の参加者アンケートは、学習・影像重複・物語・場所誘導・空間認識の五つの観点を挙げ、地域の古写真への関心は世代を超えて高いものの、面白く感じてもらうには解説など発見の手がかりが重要であると整理している。ある程度のところまではマニュアルやガイドで撮影ポイントへ誘導して模範解答を示し、被写体と古写真が重なる最後の場面では細部まで誘導する必要があるという [UC-006 §参加者アンケートから得られた知見]。アプリ単体では機能を活かしきれず、解説、誘導、物語といった付加価値が欠かせないという見解も、同じ報告に示されている [BP-002 §解説と誘導を組み込んだ体験の設計]。

現地で起きること

教え合い、引き出される記憶

写真を手に現地へ出ると、参加者のあいだでやり取りが始まる。グラバー園の街歩きでは、初めて使うアプリの操作に時間がかかる参加者を周囲が自然に教え、撮影の位置取りを共有し、よく撮れた写真を見せ合った。スマホは本来個人的な道具だが、それをめぐって学び合う空間が成立している [UC-030 §ツアー形式の実施で得られた手応えと相互作用]。

世代をまたぐ関係は、まちづくり団体の体験にも現れた。スマホの扱いは若者が得意で、地域の知識は高齢者が豊富という交差する関係があり、世代間のコミュニケーションのきっかけになりうる、という意見が出ている [UC-005 §メモリーグラフの4つの意義]。飛騨古川では、大学生が撮影場所を特定できなかった写真を「SOS」として中学生に託し、生徒が地域の人に聞き取りをして場所を見つけてきた [UC-005 §飛騨古川での中学生との景観学習プロジェクト]。

その場で記憶が引き出される場面もある。グラバー園の参加者には、以前この地域で暮らしていた人や、親戚が暮らしていて通っていた人がいて、書籍や資料にはない記憶に基づく話で盛り上がった。70代の男性参加者の活き活きとした表情からは、アプリが回想法のように昔の記憶をたどる手がかりとして働く可能性が見えたという [UC-030 §ツアー形式の実施で得られた手応えと相互作用]。まちづくり団体からも、高齢者福祉施設や同窓会・法事など人の集まる場で昔話のツールになりうるという意見が出ている [UC-005 §メモリーグラフの4つの意義]。

身体を運ぶことでしか得られない理解

現地で撮ることには、画面の上の比較とは別の理解がある。まちづくり団体の参加者は、Googleストリートビューでも今昔の比較はできるが、車で走りながら流して撮るのと、自ら構図を決めて撮るのとでは写真の持つ価値が異なると述べ、現地でこそ土地の質感や細かな変化を感じ取れると語った。重要伝統的建造物群保存地区の祇園新橋では、全体の印象は変わらないものの細部には多くの変化があり、所有者の努力によって全体の美しさが保たれているという気づきも報告されている [UC-005 §課題と気づき]。

古写真との比較は「良かった過去」を懐かしむだけに終わらない。アスファルト舗装が石畳に変わるなど、質を高める工事の成果としての「良くなった今」にも気づける点が、まちづくり団体から指摘された [UC-005 §メモリーグラフの4つの意義]。

受け手から主体へ

景観学習は、参加者が受け手にとどまらず主体になる構造として設計できる。大阪大学の実践は、廣瀬隆人による「地域を学ぶ」営みの3つの側面を足場にしている。暮らしの場としての地域を科学的・体系的に捉えること、地域を知って再発見・再評価し、暮らしやすく変えていくエネルギーを育てること、そして自分の住む町を学ぶことでその地に生きる意味を見出す主体形成である。景観写真から景観を読み解く体験は、自らの立脚地としての地域と自らを結び直すことにつながると位置づけられる [UC-005 §景観と地域学習の捉え方]。

主体になる度合いは、企画の段階で測れる。大学生による景観学習イベントは、NPO法人京都景観フォーラムの講座を受講した4回生が、対象を学生、目的を景観や町並みへの興味の喚起と仲間探しに設定して企画した。現地下見で候補地を絞り、観光客の多い清水エリアは不適と判断して岡崎エリアに決め、チラシ、申込フォーム、会場予約、当日用のプロジェクト作成まで担っている。参加者からは新しい視点でまち歩きができたという声が、企画した学生からは、自分たちでルートや写真を考えることで地域をより深く考えるきっかけになったという声が出た [UC-005 §大学生による景観学習イベントの企画・実践]。

飛騨古川の中学生との授業は、この構造を段階化している。第1回は撮影場所を探す宿題、第2回は今昔写真を集めるゲーム、第3回は自分たちが良いと感じた場所を10カ所ほど撮影して「マイタウントレイル」を描く作業、第4回は地域の人を実際に案内するまち歩きである。受け取る側から、地域を編集して案内する側へと進んでいく。報告者は、中学生だからできないことはなく、むしろ教えてもらうことも多かったと振り返っている [UC-005 §飛騨古川での中学生との景観学習プロジェクト]。

連携先との関係と摩擦

連携先は、事業者、観光組織、学校、まちづくり団体と多岐にわたる。飛騨の授業は、飛騨市役所まちづくり観光課と古川中学校のマイプロジェクト(地域貢献の課外授業)が主催し、大学や研究機関が協力する形をとった [UC-005 §飛騨古川での中学生との景観学習プロジェクト]。デジタルアーカイブの専門組織との連携は、継続的な公開と管理、技術的な支援、既存のアーカイブシステムの流用による経費と時間の削減をもたらした [UC-005 §京都の鉄道・バス写真データベースの構築]。

摩擦は、連携を通じて次々に表面化する。第一は、地域の側が古写真を整理し続ける負担である。まちづくり団体からは、写真を誰でも引き出せるよう整理する手間、サーバー管理を含む費用や人手、責任の所在が課題として挙がった。被写体によっては周囲の風景が写らず、観光客にはより古いものが期待されるといった素材選定の難しさもある [UC-005 §課題と気づき]。一方で、収集や整理の過程そのものをまちづくり活動の一部として位置づけられるのではないか、写真にストーリーを添えればまち歩きの切り口が増えるのではないか、という提案も同じ場から出た [UC-005 §課題と気づき]。

第二は、地域の側が写真を使う目的の違いである。古くから住む人は地域の成り立ちをよく知る一方で新鮮さを感じにくく、むしろ新しく移り住んだ人、商売を始める人、観光客に魅力を伝えるツールとして使いたいという意見が寄せられた [UC-005 §メモリーグラフの4つの意義]。研究側の関心と、地域側が使いたい場面とは、必ずしも一致しない。

第三は、不特定多数が参加する場での写真共有である。グラバー園では、イベント終了後に参加者の一人から、他の人がアップロードした写真が自分の画面に表示されるのを消せないかという相談が届いた。写真を共有したいか、他人の写真を見たいかには個人差があり、一律の設定では対応しきれない。個人単位で閲覧範囲を制限できる設定が必要だと開発側に伝えたところ、「非表示」モードが追加された [UC-030 §写真共有機能をめぐる課題と対応]。

研究としても催しとしても成り立たせる

研究と催しの両立は、運営側が参加者の戸惑いを先回りして取り除くことでも支えられている。グラバー園の街歩きでは、運営側がイベント前にアプリを操作する中で、初めての参加者にとって分かりにくい点が見つかり、開発者に依頼して三つの更新を加えた。現在地から目的地までのルートと所要時間を示す道順表示、古写真を重ねる操作を指のジェスチャーで案内する透過調整のガイダンス、古写真と構図を合わせる目印を示す撮影時のポイント表示である。いずれも運営側の事前準備で見つかった点であり、初めて訪れる土地で、初めてアプリを使う参加者が戸惑わないようにするためのものだった [UC-030 §イベント運営に向けたアプリ機能の改善]。

イベントの形式は、記憶の収集とも噛み合わせなければならない。大阪大学の実践は、展示会、トークイベント、聞き取りを重ねるなかで、記憶を収集する手法ごとの長所と短所を整理した。写真展は不特定多数から記憶の断片を集められるが、双方向のやり取りがないため情報の深度が浅くなりがちである。インタビューは双方向で深く集められるが、対象にできる人数は限られる。トークイベントは会場とのやり取りのなかで思い出を引き出し、参加者の一体感を得られるが、情報発信の性格が強く、アーカイブの価値や意義を伝えるのに向く一方、収集にはあまり向かない。いずれの形式でも参加者の記憶や体験を集められ、集めた記憶は写真資料のメタデータの充実に活用できる可能性が示されている [UC-005 §デジタルアーカイブを活用したイベントの開催]。

つまり、一つの形式で深さと広がりと発信を同時に満たすことはできず、形式を組み合わせて設計する必要がある。たとえば写真展で広く断片を集め、まち歩きやトークの場で記憶を引き出し、深く聞き取りたい相手にはインタビューを重ねる、といった役割分担が考えられる(この組み合わせ方は、各形式の特徴を踏まえた編集上の整理である)。

研究が地域から受け取るもの

研究の側が地域から受け取るものは、まず資料そのものである。市電の写真で撮影場所を同定する作業では、北野線沿いのバス車庫がもとは市電車庫だったことを知っているといった地域の知識が手がかりになる [UC-005 §京都の鉄道・バス写真データベースの構築]。同定作業は、写真情報を知らない人にとって単なる事実確認にとどまらず、場所への理解や歴史的認識を深め、地域の価値を再発見・再評価する機会にもなる [UC-005 §京都の鉄道・バス写真データベースの構築]。

次に、記憶である。会場や現地で語られる記憶は、書籍や資料にはない内容を含み [UC-030 §ツアー形式の実施で得られた手応えと相互作用]、集めた記憶は写真資料のメタデータの充実に活用できる可能性がある [UC-005 §デジタルアーカイブを活用したイベントの開催]。

三つ目は、地域の側の問いと視点である。古写真の素材選定で挙がった論点や、世代を横断した使い方の提案は、研究の側が想定していなかった使い道として返ってきた [UC-005 §課題と気づき]。授業では、企画した大学生や中学生から、研究者が教えられる場面もあった [UC-005 §飛騨古川での中学生との景観学習プロジェクト]。参加者の声が道具の更新につながった一例が、グラバー園で相談を受けて加わった写真の非表示機能である(前述の摩擦の項を参照) [UC-030 §写真共有機能をめぐる課題と対応]。

最後に、活動そのものが、地域の資料・記憶・視点として研究に返ってくる [UC-005 §知見と展望]。この循環の全体像は節「防災と災害の記憶」を参照。

この節へのコメント

  • まだコメントはありません。

6.3 防災と災害の記憶

官と学の連携がつくる歴史地震の震度分布図

災害の記録に研究が関わる形として、歴史地震の震度分布図づくりを共同で進める事例がある。地震研究所と史料編纂所は共同研究のためのバーチャルな部局を設け、史料の電子化や震度分布データの整備に取り組んでいる [UC-047 §はじめに]。これは官と学の連携の事例であり、住民が参加するアーカイブとは性格が異なる。「民」が加わる災害固有の連携は、紐づく記事に記述がない。

目指されているのは、現代の地震であれば気象庁がすぐに公表する震度分布図の歴史地震版を数多く作ることである [UC-047 §歴史地震の震度分布図をつくる]。江戸時代以前の地震では、当時の人々が体験して書き残した文書の記述から推定する。家が倒れた、強く揺れた、弱く揺れたといった記述を震度の尺度に変換して地図にすると、強く揺れた範囲の中心付近に震央があると推測でき、その広がりから規模もある程度推定できる [UC-047 §歴史地震の震度分布図をつくる]。そのために、くずし字史料を翻刻してテキストデータにし、現代語訳しながら被害や揺れの記述を抜き出す。「夜四ツ時過ゟ大地震にはかにゆり出し」を「夜四ツ時(午後十時頃)過ぎから大地震で急に揺れはじめた」と読み替える作業がその一例である [UC-047 §歴史地震の震度分布図をつくる]。

史料から知りたいのは、いつ・どこで起きたか、被害や揺れの分布、そして何が起きたかである。何が起きたかには、被害の程度・様相や、港の水深変化・井戸水の変化といった揺れ以外の情報、人々や社会の対応が含まれる。こうした情報は、将来起こりそうなことを考える防災の観点からも大事だとされている [UC-047 §歴史地震の震度分布図をつくる]。

被災の記録を地図にする研究

1923年の関東大震災については、東京都慰霊協会が所蔵する「震災死亡者調査表」約3万8千名分の住所をジオコーディングし、空間分布を地図化して、被害の要因や社会的背景を探ろうとする研究がある [UC-032 §はじめに]。現地を訪ねる行為そのものではなく、被災の記録を扱う研究の例である。被災地を訪ねるときの倫理や現地での振る舞いへの配慮は、紐づく記事に記述がない。

活動のサイクルとしてアーカイブを育てる

住民が参加するアーカイブをどう育てるかについて、景観写真の活動から出てきた構想がある。景観写真を地域社会の課題や未来を考えるための資料と位置づけ、問いの中心は、デジタルアーカイブされた資料を実世界である地域社会にどうつなぐかにある [UC-005 §知見と展望]。そのヒントは「活動」の共有にある。活動の結果としてアーカイブが整理されたり、新しいアーカイブが生み出されたりする流れが重要で、この流れがまちづくりへ広がり、景観学習の活動からコミュニティアーカイブへつながることが期待されている。展望として示されたのは、楽しむ・集める・考える・伝えるという要素を循環させるサイクルである [UC-005 §知見と展望]。

この循環の骨組みは、地域資料を出発点とする。そこから展示会・まち歩き・セミナーなどの催し、メモリーグラフによる今昔比較の企画、成果のアーカイブ化へと順に巡らせ、地域課題の発見から発信、アーカイブへとつなぐ [UC-005 §活動のフレームワークと展開]。位置づけとなる問いは、歴史的町並みの継承や地域の社会的インフラの変化について「なにを伝えていけるか」である [UC-005 §活動のフレームワークと展開]。催しで人が集まり、今昔の比較で何が変わったかを考え、その成果がアーカイブとして残ると、そのアーカイブが次の催しの出発点になる。この巡りがアーカイブを整理されたものへ育てていく。

活動の結果としてアーカイブが整っていく筋道は、別の記事でも、景観学習からコミュニティアーカイブへのつながりの展望として示されている [BP-002 §写真を介した対話と記憶の共有]。活動がまちづくり団体・大学・学校へ広がった経過は、節「地域とともに進める」を参照。なおこれは景観写真の活動に基づく構想であり、災害の実践で検証された成果ではない。

防災教育への接続

防災教育への接続は、今後の展開として語られた段階にある。被爆80年を迎える長崎で、原爆被災のビフォー・アフターを扱う教育啓発ツールや、被爆地観光のフィールドツールとしての活用を探る方向が示されている [UC-006 §今後の展開]。実践の成果として報告されたものではなく、学校教育での位置づけや効果の検証は紐づく記事に記述がない。

記憶を次の世代へ渡す

古写真と現在の風景を重ねる体験を、記憶の働きから三つの局面に整理した例がある。過去の撮影場所を現在の場所で探す記憶探索(MH)、古写真と現在の撮影場所を重ねて過去の記憶を仮想的に現実化する記憶現実(MR)、重なった現在の写真を記録する記憶記録(MG)である [UC-006 §「記憶」概念の整理:MH・MR・MGと「像覚」]。過去の風景の記憶を現在の場所に重ねて残していく営みと言える。影像の記憶を扱う認識概念として「像覚」という用語も提案されている [UC-006 §「記憶」概念の整理:MH・MR・MGと「像覚」]。この三局面は長崎の古写真を扱う研究室の整理であり、災害の記憶継承の実践に固有のものではない。

多くの人が同じ場所で古写真に重ねて撮影すると、何が保存され何が変化したかを同一構図撮影によって発見できる [UC-016 §Memorygraphアプリによる景観の変化の把握]。写真を通時的に扱う一般的な論点は節「写真という資料」が述べており、災害に固有の撮影手順は紐づく記事から導けないため、本節では書かない。

現地に身体を運ぶこと自体に価値を見る立場もある。災害のビフォーアフター写真では、現場に実際に行って想像を巡らせること自体に意義があり、オンラインでは完結しない [UC-004 §フィールドワークへの活用:メモリーハンティングと災害アーカイブ]。阪神・淡路大震災20周年の2015年には、震災直後の記録写真を使って現在の同じ場所を撮影する活動が行われた。震災を直接知らない子ども世代もアプリにすんなり馴染み、文章の説明を読むより実際に使う方が直感的に理解できることが確認されている [UC-004 §フィールドワークへの活用:メモリーハンティングと災害アーカイブ]。

時間の経過と記録の難しさ

過去の記録には曖昧さがあり、現代のようにコード化・標準化・数値化されていない。存在しない記録を補うには慎重な判断が要り、曖昧さは複数のデータを突き合わせたり比べたりすることで解消できる場合もある [UC-044 §歴史ビッグデータの夢と]。これは歴史ビッグデータ全般の品質をめぐる議論であり、災害の記憶継承が時間とともにどう難しくなるかを直接論じたものではない。

この節へのコメント

  • まだコメントはありません。

6.4 文化遺産と国際協力

文化遺産をめぐる研究は、資料の所在地と研究者の所在地と遺跡の所在地が一致しない状態から出発することが多い。ドイツ=トルファン探検隊(1902〜1914年)が撮影した約1500枚のガラス乾板はベルリン州立アジア美術館に保存されているが、遺跡そのものは中国・新疆のトルファン盆地にあり、研究者は日本・中国・ヨーロッパに散らばっている [UC-008 §ドイツ=トルファン探検隊の古写真と遺跡同定の課題]。何が、どこに、いつあったのかを再構成することが、国際協力の実質的な内容になる。

分散した資料を前提とした協力体制の組み方

ドイツ=トルファン探検隊の写真は、何をどこで撮影したかという探検隊側の記録がほぼ失われている。報告書にも地図がなく、手書きの平面図のみで項目分けも不十分なため、個々の写真がどの遺跡に対応するのかを特定することがきわめて難しい [UC-008 §ドイツ=トルファン探検隊の古写真と遺跡同定の課題]。

この状況に対して組まれた体制は、日本・中国・ヨーロッパの研究者がそれぞれ異なる資料と文脈を持ち寄る構造だった。ベルリン州立アジア美術館は2009年以降に古写真の整理を始め、2010年前後からデジタル化を進めて、大英図書館のIDP(国際敦煌項目)やベルリン州立博物館のアーカイブにもアップロードした [UC-008 §古写真を用いた遺跡同定の方法論]。現地ではトルファン地区文物局が協力し、2017年からドイツ隊の調査地の捜索と同定が始まっている [UC-008 §古写真を用いた遺跡同定の方法論]。その手前には、地図・遺構平面図・衛星写真・一部の古写真を組み合わせて高昌故城の大部分の遺構を同定した先行研究があり、この成果がベルリンとの協力へつながった [UC-008 §古写真を用いた遺跡同定の方法論]。

国際協力が目的ではなく方法として必要になる場面もある。Tempel T'の壁画の位置の特定では、ドイツ隊の写真だけでは撮影範囲が足りなかった。より広い範囲を撮影していたロシアの探検隊の写真と照合し、壁面の崩れた箇所など細部を突き合わせて対応点を見いだしている [UC-008 §遺跡同定の事例]。同じ遺跡を別の探検隊が別の角度から記録していたという事実が、単独の資料群では解けない問いを解く鍵になった。

災害による喪失に対しては、国境を越えた資料の召集が事後的な復元の前提になる。イラン・バム遺跡では2003年12月の地震の5日後にウェブサイトを開設し、世界に地震前の写真の提供を呼びかけた [UC-020 §地震で全壊したバム遺跡と復元プロジェクト]。取り組みは、ディジタル・シルクロード・プロジェクトの中でテヘラン大学の研究者を中心に、イランの共同研究者や国立情報学研究所の関係者とともに進められている [UC-020 §地震で全壊したバム遺跡と復元プロジェクト]。復元には衛星画像・写真・平面図・地形データ・記録・遺物・人々の記憶といった種類の異なるデータの統合が必要で、それでも欠ける情報は残る [UC-020 §実測と推定:2種類の3次元モデル]。現存しない対象を記録するには、どの単一の機関も持ちえない資料の集合が要る。復元モデルの技術的詳細については「三次元の計測と復元」を参照されたい。

現地調査が直面する多層の障壁

現地調査は研究上の問題だけでなく、政治的・環境的・運用上の制約を同時に抱える。

ゼロコロナ政策の直後という時期には、表向きは受け入れ可能とされながら外国人の調査が実質的に難しい状況が続いた。最終的には北京大学の支援を得て調査が実現している [UC-008 §メモリーグラフを用いた現地調査]。現地政府・現地大学・海外機関の関係が、調査の可否そのものを左右する構造がここに表れている。

環境面では、昼間の気温がおよそ50度に達するため、調査できるのは夕方6時から夜10時の時間帯に限られた [UC-008 §メモリーグラフを用いた現地調査]。ツールの運用でも、アプリのログイン認証に用いるGoogleのサインインが中国の環境では使いにくく、位置情報については中国版の地図サービスを併用した [UC-008 §メモリーグラフを用いた現地調査]。これらは「現地調査」という言葉の陰に隠れた多層の障壁であり、ツールの機能設計だけでは解消できない。

「すでに失われた」という前提の誤り

ヨーロッパのシルクロード探検隊が調査した遺跡は、大規模で現在もよく知られているものを除けば、すでに失われた、あるいは破壊されたと長らく説明されてきた。そのため、調査された遺跡が今も残っているとは、ほとんど誰も考えていなかった [UC-008 §ドイツ=トルファン探検隊の古写真と遺跡同定の課題]。著名な大きな遺跡でも、現地の人から「もう何も残っていない」と言われながら、実際には残っていたという場面があった [UC-008 §遺跡同定の事例]。

遺跡が残っていても、景観が激変している場合には別の問題が生じる。勝金口(Sengim)では、一帯がぶどう畑になっていた。100年前と比べて地域の人口が約10倍に増え、食料生産のための土地転換が進んだ結果であり、手前では高速道路の工事も進んでいる。次に訪れたときには同じ写真を撮れなくなる可能性が高い状況だった [UC-008 §遺跡同定の事例]。所在地が分からないために発掘ができない遺跡もあり、写真による位置の確定は、景観が消える前に手がかりを押さえる作業になる [UC-008 §遺跡同定の事例]。

現地の記録との食い違いは、写真を突き合わせて初めて議論の俎上に載る。ドイツ隊の書籍で仏教寺院(5〜7世紀とされるが、年代の記述には揺れがある)とされた地点が、現在の現地の記録では19世紀の建物とされていた。違うと言葉で説明しても理解を得るのは難しく、証拠となる写真を示すしかない [UC-008 §遺跡同定の事例]。古写真による遺跡同定の方法論は「写真という資料」を参照されたい。

記録を誰に返すか

資料が持ち出されて100年以上が経つ。その記録を現代の現地調査に使うとき、調査者は現地の文物局に行きたい場所を依頼し、案内を受け、撮影した写真をデータとして持ち帰る。一方、プリントアウトして持っていった古写真は、現地の人が喜んで持ち帰ってしまうため、写真はスマートフォンの中でしか見られない状態で運用されたという [UC-008 §メモリーグラフを用いた現地調査]。この小さな出来事は、記録への関心と、それを手元に置きたいという感覚が現地の人々にもあることを示している。

調査の成果としては、各地の文物局・文管処・研究所との協力で、ドイツ隊が具体的にどこを調査したのかが判明した。ベルリン州立アジア美術館との協力で、調査の基礎的データを整備する取り組みも始まっている [UC-008 §調査の成果と今後]。ただし、この事例から読み取れるのは協力体制の形までである。記録の返還をどう判断するか、その権原をどう考えるかという議論は、この事例からは読み取れない。

この節へのコメント

  • まだコメントはありません。

用語集

校訂

critical editing

複数の伝本や校異を突き合わせ、本文の異同を判断して整えること。翻刻が原文の忠実な 再現であるのに対し、校訂は編者の判断による本文の確定を含む。

関連: 翻刻

jageocoder

jageocoder

Python版ジオコーダー。日本の住所を緯度経度に変換する機能など、多様な機能を提供する。情報試作室の相良毅氏が開発するオープンソースのソフトウェア。

別名: Jageocoder

IIIF

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)を拾って、それらをマッピングするための幾何学的変換を計算する方法がよく用いられる。

別名: ジオリファレンス

付録

まだ書けていない領域

本ガイドラインは、あるべき構造を先に定め、そこに実践知を当てて書いている。当たらなかった場所を空白として残し、隠さずここに挙げる。いずれも本ガイドラインが扱うべき範囲の内側にあり、素材となる講演や記事が集まれば節として加わる。

上空からの観測 —— 衛星画像、過去の空中写真、合成開口レーダー。入手とジオレファレンス、時系列での変化の読み取り。古地図の処理と景観の変化を扱う節に隣接するが、観測されたデータを使う実践がまだ収められていない。

空間の分析 —— 分布の読み方、集計の単位、空間統計。空間的な問いをどう立てるか。関東大震災の死亡者分布のような例はあるが、方法として述べるには足りない。

移動・経路・軌跡 —— 街道や宿場、踏査の経路、まち歩きのコース。点や面ではなく線として空間を扱うこと。

空間の物語 —— 地図に語りを載せること。地図が示せるものと、示せないもの。

資料を画像にする —— 撮影、色の管理、解像度の選択、撮影記録の残し方。デジタル化の入口にあたる判断が、本ガイドラインにはまだない。

画像の検索と生成 —— 似た画像を探すこと。生成については AI の章が扱うが、探す側が空である。

AI を検証する —— 出力の根拠をどうたどるか、誤りをどう見つけるか、再現性をどう担保するか、何をもって良いとするか。AI を使う実践が増える一方で、検証の作法がまだ言語化されていない。

データをどこに置くか —— リポジトリの選び方、日本の研究データ基盤、置いたことになる条件。研究の現場で最も多く問われることのひとつでありながら、実践知として記録されていない。

プロジェクトの設計と協働 —— 範囲の決め方、工程、費用、データ管理計画、引き継ぎ。参加者を募り、教え、品質を保ち、貢献をどう記録するか。

上に挙げたのは、節として立てるだけの素材がまだ集まっていない領域である。これとは別に、節としては置いたものの、素材が足りないために本文中で「現時点で薄い領域」と自ら述べている節がいくつかある。そちらは該当箇所で直接確認できる。

これらの空白は、知識が存在しないことを意味しない。本ガイドラインは講演を素材としているため、まだ語られていないことは記事にならず、記事にならないことは書かれない。一覧は、次に何を聞くべきかの見取り図でもある。

ガイドライン作成のためのAgentic Publishing

ガイドラインは、Agentic Publishingシステムにより作成されたものである。Agentic Publishingとは、人間が指定した構造に沿って、AIエージェントが知識ベースから記事を選び、成果物を構成するプロセスである。

ガイドライン編集者は、章節の構成(見出しなど)をマークダウン形式で指定し、各章節の内容をYAML Front Matter Block形式で指定する。これは、各章節が何を記述し、何を記述しないかを指定するものである。

Agentic Publishingシステムは、以下のような特徴を備える。

  • AIエージェントが生成結果を多観点で検査し、その結果を人間が裁定する品質保証プロセス
  • 検査で発見された問題点を編集レシピに反映させ、以後の生成に活用する品質改善ループ
  • 知識ベースの成長を反映して再生成するLiving Documentとして運用可能
  • 成果物を版として凍結し、参照可能・追跡可能な出版物として公開可能

また、編集レシピとして、以下のようなファイルを管理している。

  • 構造:成果物としての文書が備える構造として、章節構造や各節に書く・書かない内容などを指定
  • エージェント指示(制作):知識ベースから選んだ記事を基にどのように書くかを指定
  • エージェント指示(校閲):書かれた文書をどのような観点で検査し、指摘を出すかを指定
  • 用語ファイル:表記揺れに対して使うべき表記やその意味などを指定

これは、素材(知識ベース)から料理(出版物)を作るノウハウを蓄積するようなものであり、生成ごとに品質が向上していくことが期待できる。

利用記事一覧(帰属表示)

ライセンス:CC BY 4.0 / 権利者:各記事の著者、DiHuCo