EN
ホーム 記事一覧 ブック DH週間トピックス 検索 このサイトについて
English
ホーム » Tags

デジタル・ヒューマニティーズ

デジタル人文学の研究と実践

ジャパンサーチAPIを活用した文化資源探索アプリの開発とApp Store公開

ジャパンサーチAPIを活用した文化資源探索アプリの開発とApp Store公開

ジャパンサーチ（ https://jpsearch.go.jp ）のWeb APIを使い、日本の文化資源を探索するiOS/Androidアプリ「JPS Explorer」を開発しました。API調査からアプリ実装、App Storeリリースの自動化までの過程を記録します。 ジャパンサーチのAPI ジャパンサーチは国立国会図書館が運営する、3,200万件以上のデジタル文化資源のメタデータを横断検索できるサービスです。簡易Web APIが公開されており、以下のような検索が可能です。 パラメータ 機能 keyword キーワード検索 text2image テキストでモチーフを指定して画像検索 image 既存アイテムIDで類似画像検索 g-coordinates 緯度・経度・半径で場所検索 r-tempo 年代範囲で時代検索 API調査で気づいた点 座標フィールドのキー名 位置情報検索（g-coordinates）のレスポンスで座標データは common.coordinates に格納されています。経度のキーは lon で、lng や longitude ではありません。 "coordinates": { "lat": 35.669, "lon": 139.764 } ギャラリーAPIの多言語フィールド ギャラリー検索（/api/curation/search）のレスポンスでは、title と summary が文字列ではなくオブジェクトになっています。 "title": {"ja": "耳鳥斎", "en": "Jichosai"}, "image": {"url": "https://...", "thumbnailUrl": "https://..."} 単純に .toString() すると {ja: 耳鳥斎, en: Jichosai} のような文字列がUIに表示されてしまうため、言語キーでアクセスする必要があります。 ギャラリー詳細のアイテム構造 ギャラリー詳細（/api/curation/{id}）のアイテムは contents ではなく parts 配列にネストされています。type: "jps-curation-list-item" を再帰的に探索してIDを収集する必要がありました。一部のギャラリーでは subPages にもアイテムが含まれているようです。 画像アップロードによる類似検索 公式APIガイドには記載されていませんが、Web UIのネットワーク通信を調査したところ、画像アップロードによる類似検索が3段階のAPIで実現されていることがわかりました。 POST /dl/api/imagefeatures/ で画像のBase64データから64次元の特徴量ベクトルを取得 POST /api/item/create-image-feature で特徴量から一時的な検索IDを生成 GET /api/item/search/jps-cross?image={ID} で通常の類似検索を実行 Step 2では X-Requested-With: XmlHttpRequest ヘッダーが必要で、レスポンスはプレーンテキストでIDが返ります。 ...

2026年3月24日 · 3 分 · Nakamura
DH（デジタル人文学）ツール情報の自動収集・記事生成システムの構築

DH（デジタル人文学）ツール情報の自動収集・記事生成システムの構築

DH分野のツール情報を追いかける デジタル人文学（DH）の分野では、OCR、IIIF、テキスト翻刻といった領域で新しいツールが継続的に開発されています。NDL（国立国会図書館）の ndl-lab や CODH（人文学オープンデータ共同利用センター）などの機関がGitHub上でツールを公開しており、研究者個人による開発も活発です。 こうした情報を体系的に収集し、カレントアウェアネスのように定期的にまとめる仕組みが欲しいと考え、自動収集・記事生成のシステムを構築しました。 収集対象 情報源は3種類です。 X (Twitter) では、DH分野で活発にツールを開発・公開している研究者や機関のアカウントを対象にしています。 RSSフィードでは、カレントアウェアネス・ポータル（国立国会図書館）の https://current.ndl.go.jp/rss.xml を取得しています。 GitHub では、DH関連のツールを公開している組織・個人の公開リポジトリの更新情報を GitHub API 経由で取得しています。 方法の検討 X投稿の取得 X の投稿取得にはいくつかの方法を検討しました。 方法 費用 結果 X API (Basic) $100/月 確実だが高コストのため不採用 Web検索（site:x.com/xxx） 無料 インデックスされたごく一部しか取れず不採用 RSSHub（セルフホスト） 無料 Xの内部API経由で全ツイート取得可能。Docker運用が必要で、GitHub Actions内での一時起動も検討したが、Playwright案のほうがシンプルなため不採用 Playwright（ログインなし） 無料 一部アカウントで0件。ログインウォールに阻まれ不採用 Playwright（Cookie認証） 無料 全アカウントで取得成功。毎日の取得であれば取りこぼしも少ない。採用 最終的に、Playwright で Cookie 認証を使う方法を採用しました。DevTools から auth_token と ct0 を手動で取得し、.x_cookies.json に保存する形です。GitHub Actions 上では Secret TWITTER_COOKIE から環境変数として渡しています。 Playwright による自動ログインも試みましたが、X のボット検出で失敗したため、手動取得に落ち着きました。Cookie は数ヶ月で期限切れになるため、定期的な更新が必要です。 AI要約・記事生成 方法 費用 結果 Claude Code 内で手動実行 プラン内 自動化できないためテスト用のみ Claude API (Anthropic直接) 従量課金 動作するが独自のAPI Key管理が必要で不採用 OpenRouter 従量課金 複数モデル選択可能、1回$0.05程度で採用 RSSフィード カレントアウェアネス・ポータルでは /feed エンドポイントがアイテム0件で、/rss.xml に30件のアイテムがあることを確認し、後者を使用しています。CODH のサイトはメンテナンス中でRSS取得ができなかったため、X 投稿で代替しています。 ...

2026年3月21日 · 2 分 · Nakamura
DH週間トピックス — 2026年3月第4週

DH週間トピックス — 2026年3月第4週

デジタル人文学（DH）関連の新規ツール開発・公開情報を週次でまとめています。 NDL OCR-Lite のモバイル対応・段組み認識対応 国立国会図書館が開発した古典籍OCRエンジン「NDL OCR-Lite」のWebアプリケーション版がモバイル対応および段組み認識機能に対応しました。iPhone、iPad、Android端末でカメラや写真ライブラリから画像を選択してOCR処理が可能になったとのことです。また、段組みレイアウトの認識にも対応し、複雑な文書構造の処理精度が向上したようです。 NDL OCR-Lite Web版 @blue0620の投稿およびGitHub更新情報より 軽量AIモデルQwen 3.5 9Bの数学問題解答性能 @blue0620による投稿で、軽量AIモデル「Qwen 3.5 9B」をローカルサーバで動作させたところ、東京大学の数学問題を解答できたとの報告がありました。軽量モデルでありながら高い性能を示しており、今後の自治体等での活用可能性が示唆されています。 @blue0620の投稿より 筑摩書房版芥川龍之介全集専用OCRスクリプト NDL OCR-Liteを活用した、筑摩書房版芥川龍之介全集の特殊なレイアウト（本文2段・脚注1段）に対応した専用OCRスクリプトが開発されました。本文と脚注を分離して作品ごとに整理する機能を持つとのことです。 @tolle_et_legeの投稿より 本記事は X投稿・GitHub更新・カレントアウェアネス・ポータルから自動収集した情報を基に生成しています。

2026年3月21日 · 1 分 · Nakamura
ジャパンサーチの類似画像検索APIの内部構造

ジャパンサーチの類似画像検索APIの内部構造

ジャパンサーチ（https://jpsearch.go.jp）の「画像AI検索」機能は、テキストによるモチーフ検索と、画像をアップロードしての類似画像検索を提供しています。公式の簡易Web APIガイドにはテキスト検索（text2image）と既存アイテムIDによる類似検索（imageパラメータ）の説明がありますが、画像アップロードによる検索については記載がありません。 Web UIのネットワーク通信を調査したところ、画像アップロード検索は3段階のAPIで実現されているようです。 APIの3段階フロー Step 1: 画像から特徴量ベクトルを抽出 エンドポイント: POST https://jpsearch.go.jp/dl/api/imagefeatures/ 画像をBase64エンコードして送信すると、64次元の特徴量ベクトルが返ります。 リクエスト: { "img_b64": "data:image/jpeg;base64,/9j/4AAQ..." } レスポンス: { "body": [-0.0879, -0.0091, -0.0712, ...(64次元)] } Step 2: 特徴量ベクトルから一時的な検索IDを生成 エンドポイント: POST https://jpsearch.go.jp/api/item/create-image-feature Step 1で取得した特徴量ベクトル（配列）をそのままPOSTすると、一時的なIDが文字列で返ります。 リクエスト: [-0.0879, -0.0091, -0.0712, ...] レスポンス（プレーンテキスト）: jpsxt-Wnl3p6dJJ8b このリクエストには X-Requested-With: XmlHttpRequest ヘッダーが必要です。 Step 3: IDで類似画像検索を実行 エンドポイント: GET https://jpsearch.go.jp/api/item/search/jps-cross?image={ID}&size=20 Step 2で取得したIDを、通常の類似画像検索と同じ image パラメータに渡します。このIDはJPSの既存アイテムIDと同じ形式で扱われるため、通常の検索APIがそのまま使えます。 レスポンスは通常のアイテム検索と同じJSON形式です。 検証結果 アプリのアイコン画像（虫眼鏡のイラスト）で検索したところ、1,932件がヒットし、民博の「肩掛袋」「上衣」「腰帯」などテキスタイル系の資料が上位に返りました。色味や形状の特徴で類似度が計算されていると考えられます。 ヘッダーの要件 調査の過程で、いくつかのヘッダーが必要であることがわかりました。 ヘッダー Step 1 Step 2 Step 3 Content-Type: application/json 必要 必要 不要 Origin: https://jpsearch.go.jp 必要 必要 不要 X-Requested-With: XmlHttpRequest 不要 必要 不要 Step 1とStep 2はPOST、Step 3はGETです。 ...

2026年3月21日 · 1 分 · Nakamura
Claude Codeで6件のGitHub Issueを並行対応：worktreeとagentの活用

Claude Codeで6件のGitHub Issueを並行対応：worktreeとagentの活用

はじめに TEI/XMLで構造化された歴史史料をWeb上で閲覧できるビューアを、Nuxt 2 + Vue 2 + Vuetifyで開発しています。このプロジェクトに報告された6件のGitHub Issueに対して、Claude Codeのworktree機能とagentを活用して並行対応した記録を紹介します。 対応したIssue一覧 グループ Issue数 内容 優先度 A 3件 テキストビューワの入れ子要素の表示不具合 高 B 1件 凡例ページのインデント未反映 中 C 1件 分析ページのリンク切れ 高 D 1件 キーワード検索のクラッシュ 高 アプローチ：worktree × 並行agent Claude Codeには、git worktreeを使って独立した作業環境で複数のagentを並行実行する機能があります。今回は上記4グループに対して、4つのagentを同時に起動しました。 各agentがworktreeで独立して作業するため、互いに干渉せず並行して修正を進められます。 Agent 1: fix/nested-tags → グループA（3件、同一の根本原因） Agent 2: fix/legend-indent → グループB Agent 3: fix/analytics-links → グループC Agent 4: fix/keyword-search → グループD 各Issueの修正内容 グループD：検索プラグインのクラッシュ 原因: 検索プラグイン内で、環境変数から読み込む設定値がundefinedのため、検索実行時にTypeErrorでクラッシュしていました。 修正: 1行のnullガード追加で解決しました。最もシンプルな修正でしたが、agentが原因を正確に特定してくれました。 グループA：入れ子要素の表示不具合 3件のIssueは一見別々の問題に見えましたが、すべて共通の根本原因を持っていました。 原因: TEI XMLの前処理スクリプトが、入れ子構造の要素を正しく変換していませんでした。具体的には、テキスト範囲を示すアンカーペアを要素に変換する処理で、入れ子になった内側の要素がフィルタリングで除外されていたため、テキストやクリック可能な注釈が失われていました。 修正: 前処理スクリプトに3つの変更を加えました。 ...

2026年3月17日 · 1 分 · Nakamura
schema.org 構造化データで Google Search Console のインデックス問題を改善する

schema.org 構造化データで Google Search Console のインデックス問題を改善する

はじめに Digital Literary Map of Japan（日本のデジタル文学地図）の開発において、Google Search Console で「クロール済み - インデックス未登録」のページが391件報告されていました。Google がページをクロールしているにもかかわらず、インデックスに登録しないのはなぜでしょうか。 その対策の一つとして、schema.org 構造化データの導入を行いました。本記事では、構造化データとは何か、どのように実装したか、そしてどのような効果が期待できるかを解説します。 構造化データとは Web ページには通常、HTML で書かれたコンテンツがあります。人間はそれを見て「これは場所の情報だ」「これは住所だ」と理解できますが、検索エンジンのクローラーにとっては、すべてが単なるテキストの羅列にすぎません。 構造化データは、ページのコンテンツが何を意味するのかを、機械可読な形式で検索エンジンに伝える仕組みです。schema.org という標準的な語彙を用い、JSON-LD（JSON for Linking Data）形式で HTML に埋め込みます。 たとえば、「明石」という文学名所のページを考えてみましょう。HTML だけでは、Google は「明石」が場所なのか、人名なのか、作品名なのかを確実に判断できません。構造化データを追加すると、「これは日本の兵庫県にある緯度34.64、経度134.99の場所で、歌枕として知られている」という情報を明示的に伝えられます。 JSON-LD の基本構造 構造化データは HTML の <script type="application/ld+json"> タグ内に記述します。 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Place", "name": "明石", "alternateName": "Akashi", "geo": { "@type": "GeoCoordinates", "latitude": 34.649312, "longitude": 134.992637 } } </script> 各プロパティの意味は以下のとおりです。 @context : 語彙の定義元です。常に https://schema.org を指定します @type : データの種類です。Place、WebSite、Dataset など、schema.org で定義された型を指定します その他のプロパティ : 型に応じた具体的な情報を記述します 実際に導入した構造化データの種類 1. Place（場所）- 文学名所の詳細ページ 文学名所の各ページ（約300件 × 日英2言語）に、Place 型の構造化データを追加しました。 ...

2026年3月17日 · 3 分 · Nakamura
TEI/XMLサイトをVercelで高速デプロイ：XSLT変換をsaxon-jsで自動化する

TEI/XMLサイトをVercelで高速デプロイ：XSLT変換をsaxon-jsで自動化する

はじめに TEI (Text Encoding Initiative) に準拠したXMLデータをXSLTでHTMLに変換し、Webで公開する構成は、デジタルヒューマニティーズの分野で広く使われています。 従来、ブラウザのクライアントサイドXSLT変換（<?xml-stylesheet?>やJavaScriptによるXSLTProcessor）でXMLを表示するケースが多いですが、この方式にはいくつかの課題があります。 ページを開くたびにブラウザがXSLT変換を実行するため、表示が遅い SEO・クローラー対応が難しい ブラウザごとのXSLT実装差異 本記事では、Vercelのビルド時にXML→HTML変換を自動実行し、生成済みHTMLを静的配信する方法を紹介します。 構成 project/ ├── docs/ # Vercelの出力ディレクトリ │ ├── index.html # トップページ │ └── data/ │ ├── *.xsl # XSLTスタイルシート │ ├── *.sef.json # コンパイル済みスタイルシート │ ├── *.xml # TEI/XMLソース │ └── *.html # 生成されるHTML（ビルド時生成） ├── build.js # ビルドスクリプト ├── package.json └── vercel.json Node.jsでのXSLT処理ライブラリ比較 Vercelのビルド環境ではネイティブツール（xsltproc等）が使えないため、Node.jsのXSLTライブラリを使う必要があります。以下の3つを検証しました。 xsltproc（参考：ローカル環境） macOSに標準搭載されているC言語実装のXSLTプロセッサです。 xsltproc docs/data/main.xsl docs/data/劉興我本巻一.xml > docs/data/劉興我本巻一.html 一瞬で完了しますが、Vercelのビルド環境では利用できません（apt-getが使えない）。 xslt-processor（純JavaScript実装） npm install xslt-processor GoogleのAJAXSLT（2005年）をベースにES2015+に更新したライブラリです。ブラウザにXSLTサポートがなかった時代のpolyfillが起源であり、1400行程度のXMLファイルの変換でも数分以上かかり、実用に堪えませんでした。 遅い理由は以下の通りです。 XPath式を実行時に毎回パース・評価する（キャッシュや事前コンパイルの仕組みがない） 最適化戦略がない設計のため、XPath評価が累積的に重くなる 純JavaScriptのDOM実装による木構造走査のオーバーヘッド saxon-js（Saxonica社製） npm install saxon-js xslt3 XSLT 3.0仕様の編集者であるMichael Kayが率いるSaxonica社が開発した高性能XSLTプロセッサです。最大の特徴は事前コンパイル方式にあります。 ...

2026年3月15日 · 2 分 · Nakamura
DH週間トピックス — 2026年3月第3週

DH週間トピックス — 2026年3月第3週

デジタル人文学（DH）関連の新規ツール開発・公開情報を週次でまとめています。 今週は該当するトピックはありませんでした。 本記事は X投稿・GitHub更新・カレントアウェアネス・ポータルから自動収集した情報を基に生成しています。

2026年3月15日 · 1 分 · Nakamura
TEI/XMLサイトをVercelで高速デプロイ：XSLT変換をsaxon-jsで自動化する

TEI/XMLサイトをVercelで高速デプロイ：XSLT変換をsaxon-jsで自動化する

はじめに TEI (Text Encoding Initiative) に準拠したXMLデータをXSLTでHTMLに変換し、Webで公開する構成は、デジタルヒューマニティーズの分野で広く使われています。 従来、ブラウザのクライアントサイドXSLT変換（<?xml-stylesheet?>やJavaScriptによるXSLTProcessor）でXMLを表示するケースが多いですが、この方式にはいくつかの課題があります。 ページを開くたびにブラウザがXSLT変換を実行するため、表示が遅い SEO・クローラー対応が難しい ブラウザごとのXSLT実装差異 本記事では、Vercelのビルド時にXML→HTML変換を自動実行し、生成済みHTMLを静的配信する方法を紹介します。 構成 project/ ├── docs/ # Vercelの出力ディレクトリ │ ├── index.html # トップページ │ └── data/ │ ├── main.xsl # XSLTスタイルシート │ ├── main.sef.json # コンパイル済みスタイルシート │ ├── source.xml # TEI/XMLソース │ └── source.html # 生成されるHTML（ビルド時生成） ├── build.js # ビルドスクリプト ├── package.json └── vercel.json Node.jsでのXSLT処理ライブラリ比較 Vercelのビルド環境ではネイティブツール（xsltproc等）が使えないため、Node.jsのXSLTライブラリを使う必要があります。以下の3つを検証しました。 xsltproc（参考：ローカル環境） macOSに標準搭載されているC言語実装のXSLTプロセッサです。 xsltproc docs/data/main.xsl docs/data/source.xml > docs/data/source.html 一瞬で完了しますが、Vercelのビルド環境では利用できません（apt-getが使えない）。 xslt-processor（純JavaScript実装） npm install xslt-processor GoogleのAJAXSLT（2005年）をベースにES2015+に更新したライブラリです。ブラウザにXSLTサポートがなかった時代のpolyfillが起源であり、1400行程度のXMLファイルの変換でも数分以上かかり、実用に堪えませんでした。 遅い理由は以下の通りです。 XPath式を実行時に毎回パース・評価する（キャッシュや事前コンパイルの仕組みがない） 最適化戦略がない設計のため、XPath評価が累積的に重くなる 純JavaScriptのDOM実装による木構造走査のオーバーヘッド saxon-js（Saxonica社製） npm install saxon-js xslt3 XSLT 3.0仕様の編集者であるMichael Kayが率いるSaxonica社が開発した高性能XSLTプロセッサです。最大の特徴は事前コンパイル方式にあります。 ...

2026年3月9日 · 2 分 · Nakamura
DH週間トピックス — 2026年3月第2週

DH週間トピックス — 2026年3月第2週

デジタル人文学（DH）関連の新規ツール開発・公開情報を週次でまとめています。 今週は該当するトピックはありませんでした。 本記事は X投稿・GitHub更新・カレントアウェアネス・ポータルから自動収集した情報を基に生成しています。

2026年3月8日 · 1 分 · Nakamura

DTS (Distributed Text Services) 1.0 正式リリースへの対応 ― TEI/XMLテキストAPIの仕様更新記録

はじめに 2026年2月、テキストコレクションへの標準的なアクセス手段を提供するAPI仕様「Distributed Text Services (DTS)」のv1.0が正式にリリースされました。 本記事では、DTS 1-alpha に基づいて構築していた校異源氏物語テキストDB用APIを、DTS 1.0に対応させた際の変更点を整理します。 https://github.com/distributed-text-services/specifications/releases/tag/v1.0 DTS とは DTS は、TEI/XMLなどのテキストコレクションに対する標準的なアクセスAPIを定める仕様です。以下の4つのエンドポイントで構成されます。 エンドポイント 役割 Entry Point APIの各エンドポイントURLを返す Collection テキスト間のナビゲーション（コレクション・リソースの一覧） Navigation テキスト内のナビゲーション（引用構造の探索） Document テキスト本体の取得（TEI/XMLの全体または一部） 対象プロジェクト 校異源氏物語テキストDBのDTS API実装（TypeScript/Express.js）です。 本番: https://dts-typescript.vercel.app/api/v2/dts ソースコード: https://github.com/nakamura196/dts-typescript 1-alpha から 1.0 への主な変更点 1. JSON-LD Context URLの変更 最も基本的な変更は、JSON-LDコンテキストファイルのURLです。 - "@context": "https://distributed-text-services.github.io/specifications/context/1-alpha1.json" + "@context": "https://dtsapi.org/context/v1.0.json" ドメインが distributed-text-services.github.io から dtsapi.org に変わりました。これは仕様の正式公開に伴い、永続的なURLが割り当てられたことを意味します。 2. dtsVersion の更新 - "dtsVersion": "1-alpha" + "dtsVersion": "1.0" 全エンドポイントのレスポンスに含まれる dtsVersion フィールドを更新します。 3. URI Template の全パラメータ記載 1-alphaでは一部のパラメータのみ記載していましたが、1.0ではAPIが受け付ける全パラメータをURI templateに含める必要があります。 Entry Point のレスポンス例: ...

2026年3月8日 · 4 分 · Nakamura
DTS Viewer の改善 ― 複数 Citation Tree 対応・階層ナビゲーション・XML ブラウザ表示

DTS Viewer の改善 ― 複数 Citation Tree 対応・階層ナビゲーション・XML ブラウザ表示

はじめに 前回の記事で、校異源氏物語テキストDB用 DTS API を 1.0 仕様に対応させ、和歌（短歌）の Citation Tree を追加しました。 本記事では、そのAPIを利用するビューアアプリ「DTS Viewer」側で行った改善について紹介します。 主な改善点は以下の3つです。 複数 Citation Tree への対応 ― tree パラメータの正しい受け渡し ナビゲーション結果の階層表示 ― カード形式からテーブル形式への変更 XML のブラウザ内表示 ― mediaType パラメータの活用 1. 複数 Citation Tree への対応 問題 DTS 1.0 では、1つのリソースに複数の Citation Tree を定義できます。校異源氏物語では「ページ/行」と「和歌」の2つのツリーを持っています。 しかし、ビューアのナビゲーションリンクが tree パラメータを付与していなかったため、和歌ツリーのリンクをクリックしてもデフォルト（ページ/行）のナビゲーションが表示される問題がありました。 対応 Citation Tree の identifier を追跡し、ナビゲーション URL に &tree=${identifier} を付与するようにしました。 const getNavigationUrl = (navigation: string, url: string, level: number, tree?: string) => { navigation = decodeURIComponent(navigation); navigation = removeVars(navigation) + `&down=${level}`; if (tree) { navigation += `&tree=${tree}`; } const combined = getDomain(url) + navigation; return encodeURIComponent(combined); }; ツリー構造の視覚化 各 Citation Tree をツリー形式で表示し、description ラベルで区別できるようにしました。 リソース詳細ページ。「ページ・行による引用構造」と「和歌（短歌）による引用構造」が視覚的に分かれて表示されている。 ...

2026年3月8日 · 3 分 · Nakamura
DOCX → TEI/XML 変換ツールに CETEIcean を使ったプレビュー機能を追加した

DOCX → TEI/XML 変換ツールに CETEIcean を使ったプレビュー機能を追加した

はじめに 以前の記事で、DOCX → TEI/XML 変換ツールを紹介しました。TEI Garage API を使ってブラウザだけで Word 文書を TEI/XML に変換できるツールです。 公開後、利用者の方から「変換されたタグが想定どおりに機能するかを視覚的に確認したい」というフィードバックをいただきました。XML のシンタックスハイライト表示だけでは、見出し・注釈・リスト・テーブルなどが実際にどのようにレンダリングされるか確認が難しいためです。 そこで、CETEIcean を使った TEI プレビュー機能を追加しました。 デモサイト: https://tei-converter.pages.dev/ CETEIcean とは CETEIcean は、TEI Consortium が開発している JavaScript ライブラリです。TEI/XML を HTML5 カスタム要素（Custom Elements） に変換し、ブラウザ上でそのまま表示できます。 通常、TEI/XML をブラウザで表示するには XSLT で HTML に変換する必要がありますが、CETEIcean は Web Components の仕組みを利用して、TEI の要素名をそのままカスタム要素として登録します。例えば <p> は <tei-p> に、<head> は <tei-head> に変換されます。 これにより、CSS だけで TEI 要素のスタイルを定義でき、サーバサイドの変換処理が不要になります。 追加した機能 XML / プレビュー タブ切り替え 変換結果の表示エリアに 「XML」と「プレビュー」の2つのタブを追加しました。 XML タブ: 従来どおりのシンタックスハイライト付き XML 表示 プレビュータブ: CETEIcean によるレンダリング結果 タブをクリックするだけで切り替えられます。 ...

2026年3月5日 · 2 分 · Nakamura

XSLT処理を5倍高速化：Saxon-JSからSaxon-HEへの移行

まとめ TEI XML → HTML変換において、npx xslt3（Saxon-JS）からJava Saxon-HEへ切り替えたところ、ビルド時間が1分48秒から23秒に短縮された（約5倍の高速化）。 背景 校異源氏物語テキストDBは、源氏物語のデジタルエディションで、54巻分のTEI XMLファイルを持つ。ビルドスクリプト（Python）が各XMLをHTMLに変換するため、npx xslt3を54回呼び出していた。 python3 scripts/prebuild.py xsl # 全54巻のXSLT処理 この処理がビルドパイプライン全体で最も時間のかかるステップだった。 ベンチマーク ファイルごとの比較 巻 文字数 npx xslt3 (JS) saxon (Java) 高速化率 01 桐壺 11,240 1.8秒 1.1秒 1.6倍 34 若菜上 46,230 4.9秒 0.4秒 12倍 ファイルが大きいほど改善幅が大きい。JVM起動コスト（約1秒）を差し引くと、実際の変換処理は桁違いに速い。 合計（全54巻） npx xslt3 (Saxon-JS): 1分48秒 saxon (Saxon-HE): 23秒 移行手順 ローカル環境（macOS） brew install saxon ビルドスクリプト SAXON_JAR環境変数 → saxonコマンド → npx xslt3の順にフォールバックするヘルパーを追加した。 def xslt_cmd(xsl, src, dst): """Return XSLT command, preferring Saxon-HE over npx xslt3.""" saxon_jar = os.environ.get('SAXON_JAR') if saxon_jar: return ['java', '-jar', saxon_jar, f'-xsl:{xsl}', f'-s:{src}', f'-o:{dst}'] if shutil.which('saxon'): return ['saxon', f'-xsl:{xsl}', f'-s:{src}', f'-o:{dst}'] return ['npx', 'xslt3', f'-xsl:{xsl}', f'-s:{src}', f'-o:{dst}'] GitHub Actions Node.js + xslt3をJava + Saxon-HE jarに置き換えた。 ...

2026年3月4日 · 1 分 · Nakamura
DH週間トピックス — 2026年3月第1週

DH週間トピックス — 2026年3月第1週

デジタル人文学（DH）関連の新規ツール開発・公開情報を週次でまとめています。 今週は該当するトピックはありませんでした。 本記事は X投稿・GitHub更新・カレントアウェアネス・ポータルから自動収集した情報を基に生成しています。

2026年3月1日 · 1 分 · Nakamura
TEI Garage APIを使って、DOCX → TEI/XML 変換ツールをブラウザだけで作った

TEI Garage APIを使って、DOCX → TEI/XML 変換ツールをブラウザだけで作った

はじめに TEI (Text Encoding Initiative) は、人文学分野のテキストをデジタルで構造化するための国際標準です。図書館・博物館・学術研究などで利用されていますが、TEI/XML を直接書くにはマークアップの知識が必要で、導入のハードルが高いのが実情です。 そこで活用されるのが、Microsoft Word (.docx) から TEI/XML への変換ツールです。代表的なものに TEI Garage（旧 OxGarage）がありますが、多機能ゆえに UI がやや複雑です。今回、DOCX → TEI/XML の変換に特化した、シンプルなブラウザベースのツールを作成しました。 https://github.com/nakamura196/tei-converter デモサイト: https://tei-converter.pages.dev/ 仕組み TEI Garage は REST API を公開しており、以下のエンドポイントに DOCX ファイルを POST するだけで TEI/XML が返ってきます。 POST https://teigarage.tei-c.org/ege-webservice/Conversions/ docx:application:vnd.openxmlformats-officedocument.wordprocessingml.document/ TEI:text:xml/ 本ツールはこの API を呼び出すフロントエンドです。変換処理自体は TEI Consortium が運営するサーバ上で行われます。 主な機能 ドラッグ & ドロップ .docx ファイルをブラウザにドラッグ & ドロップするだけでアップロードできます。クリックしてファイルを選択することも可能です。 整形済み XML プレビュー 変換結果はインデント付きで整形され、シンタックスハイライト付きで表示されます。タグ名、属性名、属性値がそれぞれ色分けされるため、構造を把握しやすくなっています。 コピー & ダウンロード 結果をワンクリックでクリップボードにコピーしたり、.xml ファイルとしてダウンロードしたりできます。 サンプル DOCX 内蔵 「サンプル .docx で試す」をクリックするだけで、内蔵のサンプルファイルで動作を確認できます。サンプルのダウンロードも可能です。 ...

2026年3月1日 · 2 分 · Nakamura
DH週間トピックス — 2026年2月第4週

DH週間トピックス — 2026年2月第4週

デジタル人文学（DH）関連の新規ツール開発・公開情報を週次でまとめています。 NDLOCR-Lite Web版の公開 国立国会図書館のAI-OCRツール「NDLOCR-Lite」のWebブラウザ版「NDLOCR-Lite Web」が公開されました。この新版では、ブラウザ上で手軽に画像やPDFのOCR処理を試すことができ、画像や認識テキストが外部に送信されることなく、ローカルで処理が完結するとのことです。 WebWorkerを使った並列処理化（最大8スレッド）により、1枚あたり数秒での認識が可能で、100ページ程度の文庫本であれば数分で処理が完了すると説明されています。また、AndroidのChromeでの動作確認がされており、モバイル環境での利用も可能なようです。 NDLOCR-Lite Web 開発者によると、読み順推定アルゴリズムに横書きテキストでの不具合が確認されており、修正作業が進められているとのことです。 @yuta1984の投稿およびGitHubリポジトリへの頻繁なコミットから確認されました。 本記事は X投稿・GitHub更新・カレントアウェアネス・ポータルから自動収集した情報を基に生成しています。

2026年2月22日 · 1 分 · Nakamura
DH週間トピックス — 2026年2月第3週

DH週間トピックス — 2026年2月第3週

デジタル人文学（DH）関連の新規ツール開発・公開情報を週次でまとめています。 koten-layout-detector v1.0.0およびv1.1.0がリリース 古典文献のレイアウト検出を行うツール「koten-layout-detector」のバージョン1.0.0が2026年2月20日にリリースされ、同日中にv1.1.0へのアップデートも行われました。このツールは古典文献の画像から文字領域やレイアウト要素を自動検出する機能を提供するものと推測されます。 koten-layout-detectorリポジトリ @yuta1984のGitHub更新情報より。 本記事は X投稿・GitHub更新・カレントアウェアネス・ポータルから自動収集した情報を基に生成しています。

2026年2月15日 · 1 分 · Nakamura
TEI/XMLファイルをGitHubで公開する手順書

TEI/XMLファイルをGitHubで公開する手順書

はじめに この記事では、TEI（Text Encoding Initiative）形式のXMLファイルをGitHubにアップロードし、誰でも参照できるURLを作成する手順を説明します。 TEI/XMLは、歴史文献や文学作品などのテキストを構造的に記述するための国際標準形式です。GitHubを使うことで、あなたの研究データを世界中の研究者と共有できるようになります。 必要なもの パソコン（Windows、Mac、Linuxのいずれか） インターネット接続 TEI/XMLファイル（すでにお持ちのもの） メールアドレス（GitHubアカウント作成用） サンプルファイルについて TEI/XMLファイルをお持ちでない方は、以下の『校異源氏物語』のTEI/XMLファイルを練習用として使用できます： サンプルファイルURL : https://raw.githubusercontent.com/kouigenjimonogatari/kouigenjimonogatari.github.io/master/tei/01.xml このファイルをダウンロードする方法： 上記URLをブラウザで開く 右クリック→「名前を付けて保存」を選択 ファイル名を「koukin_genji_01.xml」などに設定して保存 ステップ1：GitHubアカウントの作成 1-1. GitHubのウェブサイトにアクセス ブラウザ（Chrome、Firefox、Safari等）を開きます アドレスバーに https://github.com と入力してEnterキーを押します 1-2. アカウント作成 右上の「Sign up」ボタンをクリックします 以下の情報を入力します： メールアドレス ：普段お使いのメールアドレス パスワード ：安全なパスワード（8文字以上、数字と記号を含む） ユーザー名 ：他の人と重複しない名前（例：yamada-taro2024） 「Create account」をクリックします メールに届いた認証コードを入力します 💡 ヒント : ユーザー名は後から変更できないので、慎重に選びましょう。研究者として使う場合は、実名に基づいた名前がおすすめです。 ステップ2：新しいリポジトリの作成 リポジトリとは、ファイルを保管する「プロジェクトフォルダ」のようなものです。 2-1. リポジトリ作成画面へ GitHubにログインした状態で、右上の「+」マークをクリックします 「New repository」を選択します 2-2. リポジトリの設定 以下の項目を入力・選択します： Repository name（リポジトリ名） 英数字とハイフン（-）が使えます 例：tei-xml-collection、medieval-texts-tei Description（説明）※任意 プロジェクトの簡単な説明 例：「中世文献のTEI/XMLファイル集」 Public/Private（公開設定） Public を選択：誰でも閲覧可能（推奨） Private：招待した人のみ閲覧可能 Initialize this repository with:（初期化オプション） ✅ Add a README file にチェックを入れる その他はそのままで大丈夫です 緑色の「Create repository」ボタンをクリックします ステップ3：TEI/XMLファイルのアップロード 3-1. アップロード画面へ リポジトリが作成されると、ファイル一覧画面が表示されます 「Add file」ボタンをクリックします 「Upload files」を選択します 3-2. ファイルのアップロード 方法A：ドラッグ&ドロップ エクスプローラー（Windows）またはFinder（Mac）でTEI/XMLファイルがある場所を開きます アップロードしたいファイルを選択します（複数選択可） ブラウザの点線枠内にドラッグ&ドロップします 方法B：ファイル選択 「choose your files」をクリックします ファイル選択ダイアログでTEI/XMLファイルを選択します 「開く」をクリックします 実例：『校異源氏物語』のTEI/XMLファイルをアップロード サンプルファイルを使った具体例： ...

2025年9月6日 · 更新: 2025年9月6日 · 2 分 · Nakamura
Omeka S Docker の紹介：デジタルコレクションのための最新かつセキュアなソリューション

Omeka S Docker の紹介：デジタルコレクションのための最新かつセキュアなソリューション

! 本記事はAIが作成しました。 Omeka S Docker へようこそ！このプロジェクトは、大学、ギャラリー、図書館、アーカイブ、博物館向けの Web パブリケーションシステムである Omeka S の本番環境対応 Docker セットアップを提供します。 📦 GitHub リポジトリ : https://github.com/nakamura196/omeka-s-docker なぜ Omeka S Docker なのか？ デジタルコレクションの管理は複雑である必要はありません。そのため、Omeka S のデプロイと管理を簡素化する Docker ベースのソリューションを作成しました。 主な機能 🚀 クイックセットアップ : シングルコマンドで数分以内に Omeka S を稼働 🔒 セキュリティファースト : 非 root コンテナとセキュアなデフォルト設定を含むセキュリティベストプラクティスで構築 📦 モジュール管理 : 人気の Omeka S モジュールの自動インストールとアップデート 🔄 簡単なアップグレード : データの永続性を保ちながらシームレスなバージョンアップグレード 🐳 本番環境対応 : 開発環境と本番環境の両方に最適化 🌐 Traefik 統合 : リバースプロキシと SSL 終端のビルトインサポート はじめに 前提条件 Docker と Docker Compose がインストールされていること コマンドラインの基本的な知識 （オプション）SSL 付き本番環境デプロイ用のドメイン名 セットアップオプションの理解 この Docker セットアップは2つのデプロイモードを提供します： ...

2025年7月30日 · 更新: 2025年7月30日 · 2 分 · Nakamura