<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>jsonl on デジタルアーカイブシステムの技術ブログ</title><link>https://tech.ldas.jp/ja/tags/jsonl/</link><description>Recent content in jsonl on デジタルアーカイブシステムの技術ブログ</description><generator>Hugo</generator><language>ja</language><lastBuildDate>Mon, 04 May 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://tech.ldas.jp/ja/tags/jsonl/index.xml" rel="self" type="application/rss+xml"/><item><title>researchmap業績登録の選択肢整理と、個人ユーザー向けPlaywright実装</title><link>https://tech.ldas.jp/ja/posts/researchmap-playwright-register/</link><pubDate>Mon, 04 May 2026 00:00:00 +0900</pubDate><guid>https://tech.ldas.jp/ja/posts/researchmap-playwright-register/</guid><description>&lt;blockquote>
&lt;p>本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。&lt;/p>&lt;/blockquote>
&lt;p>以前 &lt;a href="https://tech.ldas.jp/ja/posts/researchmap-playwright-kakenhi/">researchmapの科研費と業績の紐付けをPlaywrightで自動化した&lt;/a> という記事を書きました。今回はその続編として、業績そのものの登録を自動化した話をまとめます。&lt;/p>
&lt;p>執筆途中でファクトチェックを行い、当初想定していた前提（「公式の書き込み手段はWeb UIに限られる」）が誤っていることが分かりました。この記事ではその過程も含めて、現時点の選択肢を整理した上で、なお自前のPlaywrightスクリプトに利点が残る部分を示します。&lt;/p>
&lt;h2 id="researchmap-への書き込み手段の現状">researchmap への書き込み手段の現状&lt;/h2>
&lt;h3 id="1-書き込みapiresearchmapv2-api">1. 書き込みAPI（researchmap.v2 API）&lt;/h3>
&lt;p>公式仕様書: &lt;a href="https://researchmap.jp/outline/v2api/v2API.pdf">researchmap.v2 API設計書（V4.7）&lt;/a>&lt;/p>
&lt;p>19の業績種別すべてに対して、追加・更新・削除が可能なAPIが公開されています。認証はOAuth 2.0（JWT Bearer Flow）で、&lt;code>https://api.researchmap.jp/oauth2/token&lt;/code> でアクセストークンを取得します。&lt;/p>
&lt;p>利用には申請が必要で、現時点で公開されている運用は次のような形です。&lt;/p>
&lt;ul>
&lt;li>申請書フォーマットは &lt;a href="https://researchmap.jp/outline/v2app/rmapV2_appAPI.pdf">大学等研究機関用&lt;/a> が用意されている&lt;/li>
&lt;li>WebAPI利用規約 第2条第3項(4) では「大学・研究機関等の機関としての申請でなく、個人としての申請と認められる場合（ただし、合理的な理由がある場合を除く。）」は承認しないことがあるとされている&lt;/li>
&lt;li>IPアドレスの固定指定が必要、利用は年度単位で継続申請&lt;/li>
&lt;/ul>
&lt;p>文言上は「合理的な理由がある場合」の例外条項があり、機関単位での運用が中心であることが想定されています。個人研究者として手元の業績だけを登録したい用途では、後述のCSV/JSONインポートやWeb UI操作が現実的な選択肢になります。&lt;/p>
&lt;h3 id="2-公式csv--json--jsonlインポート個人ユーザー対象">2. 公式CSV / JSON / JSONLインポート（個人ユーザー対象）&lt;/h3>
&lt;p>設定 &amp;gt; 「研究者・業績インポート」画面から、ログイン中の研究者本人の業績を一括登録できます。&lt;/p>
&lt;ul>
&lt;li>対応フォーマット: JSON / CSV / JSONL / ZIP&lt;/li>
&lt;li>全19業績種別に対応&lt;/li>
&lt;li>1ファイル10MBまで&lt;/li>
&lt;li>仕様書: &lt;a href="https://researchmap.jp/outline/v2api/v2CSV.pdf">v2CSV項目定義書&lt;/a>、&lt;a href="https://researchmap.jp/outline/v2api/v2API.pdf">API設計書&lt;/a> に内部フォーマットとして記載&lt;/li>
&lt;/ul>
&lt;p>つまり個人ユーザーでも、JSONLを書ければ事実上の一括書き込みは可能です。&lt;/p>
&lt;p>いくつか補足しておきたい点があります：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>添付ファイル（PDF等）はインポートの対象外&lt;/strong>です。API設計書で &lt;code>dataset&lt;/code> 配下のフィールドは全業績種別で「更新不可」と明記されています（presentations, published_papers, misc, works など全タイプ）。&lt;code>access_url&lt;/code> 等は読み取り専用の出力フィールドです&lt;/li>
&lt;li>ZIPアップロードは「JSON/CSVファイルを複数同梱する」用途で定義されており、PDFを同梱する仕様ではありません&lt;/li>
&lt;li>インポート画面でのファイルアップロード操作はユーザー側で行う必要があります&lt;/li>
&lt;/ul>
&lt;h3 id="3-web-ui-手動操作">3. Web UI 手動操作&lt;/h3>
&lt;p>1件単位の追加・修正なら最速です。ただし数十件規模になるとつらく、Git等での履歴管理もできません。&lt;/p>
&lt;h3 id="4-playwrightによるブラウザ自動化本記事">4. Playwrightによるブラウザ自動化（本記事）&lt;/h3>
&lt;p>公式CSVインポートで対応できる範囲はそちらを使えばよく、私が手元で自動化したかったのは次のような場面でした。&lt;/p>
&lt;ul>
&lt;li>&lt;strong>JSONLを書いたら、ファイルアップロード操作も含めて自動で完了させたい&lt;/strong>&lt;/li>
&lt;li>&lt;strong>PDFを発表資料として添付したい&lt;/strong>：これは公式インポートのスコープ外&lt;/li>
&lt;li>&lt;strong>既存エントリをピンポイントで更新したい&lt;/strong>：「現在まで」を具体的な終了年月に置き換える等の単発編集をJSONL化して残しておきたい&lt;/li>
&lt;/ul>
&lt;p>これらに対応するために自作したスクリプトを以下で紹介します。&lt;/p></description></item></channel></rss>