はじめに
この記事の要点
- CSP認定はAPIの適合試験ではなく、ワークフローとUXの適合審査に近い
- 認定は無料で、ORCIDのメンバー組織でなくても申請できる
- 提出物はデモ動画と自己点検チェックリスト。ソースコードは求められない
- 当社は初回提出から認定まで約3か月。その大半は指摘を受けての改修期間だった
ORCID（Open Researcher and Contributor ID）は、研究者を一意に識別するための国際的な永続識別子です。研究者の氏名は、同姓同名・改姓・表記ゆれによって一意になりません。当社は大学・研究機関向けに業績管理システムを提供しており、ORCIDとの双方向連携ツールが2026年7月20日付でORCIDの認定サービスプロバイダー（Certified Service Provider、以下CSP）に認定されました。
本記事では、CSP認定がどのような制度で、審査で何が問われ、どのような設計判断をしたのかを、申請した立場から整理します。ORCID連携を実装する開発者、またはCSP認定の取得を検討している事業者が想定読者です。なお、独自の実装やアルゴリズムの詳細には触れず、設計思想と技術選定の観点を中心にまとめます。個別の審査で交わしたやり取りの内容そのものも対象としていません。
従来手法の問題点
氏名による名寄せの限界
業績データベースを氏名で運用すると、次の問題が同時に起きます。
- 同姓同名の研究者を区別できない
- 改姓によって同一人物の業績が分断される
- 漢字・かな・ローマ字の表記ゆれで別人として扱われる
- 所属異動をまたいだ業績の追跡が切れる
これらは運用ルールや名寄せロジックの改善だけでは解消しきれません。識別子そのものを持たない限り、突合の精度には上限が残ります。
片方向連携では解決しきれない
ORCIDから読み取るだけの片方向構成にも、次の限界があります。
- 研究者のORCIDレコードが未入力であれば、取得できる情報がない
- 所属情報をもっとも正確に把握しているのは所属機関自身だが、その情報がORCID側に還元されない
- 結果として、レコードの充実を研究者個人の入力努力に依存してしまう
ORCIDが公開している研究情報システム向けの認定基準（CSP Criteria: Research Information Systems、以下「認定基準」。URLは末尾の関連情報に掲載）でも、所属機関のみが権威をもって主張できるaffiliationをレコードに追加することが、基準4の必須要件とされています。以下、制度要件への言及はすべてこの文書を出所とします。
解決の考え方
データ種別ごとに正本の所在を決める
双方向にすると、同じ項目が機関側とORCID側の両方に存在することになります。ここで「システム全体の正本はどちらか」を一つに決めようとすると、設計が立ち行かなくなります。当社では、データ種別ごとに正本の所在を定義するほうが実態に合うと判断しました。
| データ種別 | 正本とする側 | 連携の向き |
|---|---|---|
| 所属・在籍情報 | 所属機関 | 機関 → ORCID（書き込み） |
| 機関が検証済みの業績 | 所属機関 | 機関 → ORCID（書き込み） |
| 機関をまたぐ経歴・他機関での業績 | ORCID | ORCID → 機関（読み取り） |
| 研究者本人のアイデンティティ | 研究者本人 | ORCID → 機関（読み取り） |
書き込みには研究者本人の同意が必要
ORCIDレコードへの書き込みは、研究者本人がOAuth 2.0の認可フローでスコープを承認して初めて可能になります。認定基準の基準5「Add works to researchers ORCID records」は、研究者が許可を与えるのは一度だけでよく、その後はシステムが自動的にレコードを最新に保たなければならないとしています。当社はこの要求に沿い、読み取りと更新のスコープ（/read-limited と /activities/update）を初回にまとめて取得し、以降は自動で更新する設計を採りました。更新のたびに同意を求める実装は、この要求を満たさず、研究者の負担も増やします。
CSP認定とは何か
制度の概要
CSPは、ORCID連携機能を組み込んだ製品・サービスが、ORCIDのベストプラクティスに適合していることをORCID自身が認定する制度です。2020年に開始され、2023年にワークフロー別の基準へ刷新されました。区分は、研究情報システム、論文投稿システム、リポジトリ、研究費・施設利用申請、ディスカバリの5つです。当社はResearch Information Systemsの区分で認定を受けています。認定は無料で、ORCIDのメンバー組織である必要もありません（出典：Become an ORCID Certified Service Provider）。
メンバーシップとCSPは別の制度です。メンバーシップは有料で、ORCIDを利用する機関がMember APIの利用資格を得るためのもの。CSPは無料で、連携機能を提供する事業者がその品質について第三者認定を受けるものです。
Research Information Systemsの認定基準
認定基準の本体は9項目で、要件の強さが MUST／SHOULD／MAY で書き分けられています（RFC 2119に従う旨が文書中に明記）。読むときはこの区別が重要です。必須は基準1〜8で、認証済みiDの取得と表示、取得したデータの活用、所属・学歴の書き込み、業績と研究費の書き込み（該当する場合）、導入機関自身の資格情報の利用、研修・紹介資料への記載が含まれます。基準9（管理者によるiDの紐付け）は任意です。別枠で、研究者プロフィールへのリンク追加（SHOULD）と訪問研究者の所属追加（MAY）が挙げられています（出典：認定基準）。
認定に使われるチェックリストは、ORCIDがGoogleスプレッドシートのテンプレートとして公開しています。当社では実装の設計段階で目を通しておいたことが手戻りの防止に有効でした。
Public APIとMember APIの区別
当社の審査では、この区別が確認の対象になりました。実装が正しくても、設定画面の文言がどちらのAPIを指しているか曖昧だと指摘されます。
| Public API | Member API | |
|---|---|---|
| 利用資格 | 誰でも取得可能 | ORCIDメンバー組織のみ |
| 読み取り | 公開データのみ | 本人が許可した非公開データも可 |
| 書き込み | 不可 | 所属・業績などの追加・更新が可能 |
| 資格情報の発行 | 各レコード保有者がDeveloper Toolsで発行 | 組織単位で発行を申請 |
（出典：ORCID公式「Member API」「Public API」。URLは末尾の関連情報に掲載）
製品側の設計として重要なのは、導入する機関が自分自身の資格情報を使えることです。誰がレコードの更新を要求しているかを明示する必要があるため、基準7の必須要件とされています。マルチテナント型のシステムでは、機関が自身の資格情報をシステム内で管理できるようにするか、安全に受け渡す手段を備えることが求められます。
認定プロセスの実際
申請から認定までの流れは、当社の場合、図1のとおりでした。
図1：CSP認定までの流れ（株式会社メディアフュージョン作成）
当社の事例では、初回提出から認定までは約3か月でした。そのうち大半は指摘を受けての改修期間です。打診から数えると半年程度かかっています。実装が完成した後にも改修が必要になった、というのが当社の実情でした。
提出物は動画とチェックリスト
審査はソースコードの提出ではなく、画面操作のデモ動画で行われました。あわせて、認定基準に対する自己点検結果を記入したチェックリストを提出しています。改修後の2回目の提出では、実装した変更点を説明する文書と、新しく追加した機能のデモ動画をあらためて用意しました。
動画を作るときのポイントは、要件ごとに該当箇所が特定できる構成にすることです。当社の場合、実装していても動画に映っていない機能について「確認できなかった」として追加確認を受けました。管理者向け機能のように、通常のユーザー操作と動線が異なるものは映し漏れやすいところです。
当社では追加確認のラウンドが発生した
初回の提出では通らず、確認事項への対応が必要になりました。確認事項には文書で回答するか、オンラインのレビュー会で直接説明するかを選べます。ただし当社では、指摘を受けて社内で検討した結果、回答を書くだけでなく実装側に手を入れる判断になりました。結果として、回答期間ではなく改修期間としてスケジュールに余裕を見ておいたことが有効でした。
審査で問われる観点
公開されている認定基準と、実際に確認を受けた経験を踏まえると、審査の論点は次のように整理できます。出所を区別するため、〔基準〕は認定基準の条文に明記された事項、〔当社〕は条文には書かれておらず当社が審査で実際に確認を受けた点を示します。
- 〔基準〕導入機関が自分自身のORCID資格情報を使えるか（基準7）。誰がレコードの更新を要求しているかを明示するために必須とされ、ORCIDのメンバーシップ契約上も求められる事項です。
- 〔当社〕設定画面の文言がPublic APIとMember APIを正しく区別しているか。当社の場合、実装ではなく表示の問題として確認を受けました。
- 〔基準〕〔当社〕必須要件と任意要件を取り違えていないか。管理者が未認証のORCID iDを紐付ける機能は任意（基準9）であって必須ではありません。当社は同意の原則を理由にこの機能を持たない設計としており、審査でもその判断が問題ないことを確認しました。実装する場合は、未認証であることを明示したうえで、研究者に認証を促して認証済みに切り替える動線が期待されます。
- 〔基準〕研究者に対して、なぜORCID iDを求めるのか、本人にとって何の利益があるのかを説明しているか（基準1）。あわせてORCIDブランドのボタンを用いることも求められます。〔当社〕説明をボタンの近くに置くという配置の具体は、審査で提示を受けた内容です。
- 〔当社〕連携解除の導線の文言が誤解を招かないか。ORCIDレコード自体は削除されないため、「アカウント削除」と読める表現を避けるよう当社は指摘を受けました。
- 〔当社〕データ間の関係が保持されるか。業績と研究費の関係のように、関連を表す情報を維持できるかを当社は確認されました。
- 〔基準〕公開ドキュメントと研修・紹介資料が整備されているか（基準8）。製品の設定ガイドにORCIDへの言及と、連携の利点が記載されていることが必須です。
全体を通してみると、APIの呼び出し方そのものよりも、研究者にとって分かりやすく、誤解を生まないかに重心があります。当社が受けたレビューでは、連携ボタンのラベルや解除操作の表現といったUI文言レベルの確認が相応の割合を占めました。API適合試験というよりはワークフローとUXの審査に近い、というのが当社の所見です。
運用上の工夫
連携部分を製品から切り離す
ORCIDとのデータ受け渡しを担う部分を、業績管理システム本体から独立したコンポーネントとして切り出しました。認定の対象を汎用的な連携部品として定義できるため、業績管理以外の研究情報システムにも接続先を広げられます。Microsoft 365版とオンプレミス版で同じ連携部品を使えることも、この分離によって成立しています。なお、資格情報の保管方法や内部の構成の詳細については、セキュリティ上の理由から本記事では割愛します。
書き込みの頻度と承認の所在を機関側に委ねる
在籍情報の更新サイクルは機関によって異なります。人事情報の反映が月次であれば、短周期でポーリングしても意味がなく負荷だけが増えるため、書き込みの実行タイミングを機関側で設定できるようにしました。
誰が登録し誰が確認するかも機関ごとに変わります。研究者本人が登録して管理者が確認する形と、管理者のみが登録する形の双方を選べるようにしています。ORCIDレコードに書き込まれる情報は機関の主張として外部に出ていくため、承認の所在を明確にできることが重要です。
得られた効果
確定しているのは2点です。ORCIDが公開するCSP一覧に掲載されたことで、導入を検討する機関が連携品質を事前に判断できるようになりました。また連携部品を本体から分離したことで、業績管理以外の研究情報システムにも接続先を広げられる構成になりました。
一方、研究者の入力の手間がどの程度減るか、所属の帰属精度がどの程度上がるかは、導入機関での運用を通じて今後確認していく段階です。現時点で定量的な検証は行っていません。
まとめ
- 指摘を受けて実装を直す期間が発生する前提でスケジュールを引くほうがよい
- 必須要件と任意要件を切り分ける。任意要件を必須と誤解して急いで作る必要はない
- 公開されている基準とチェックリストを先に読んで自己点検しておくと近道になる
CSPの基準は、認定を取るかどうかにかかわらず設計時のチェックリストとしても使えます。基準1の「なぜ識別子を求めるのかを利用者に説明する」、基準2の「連携できたことを利用者に見える形で示す」、基準9の「未認証の識別子は未認証と分かるように扱う」は、ORCIDに限らず外部の識別子を扱うシステム全般に当てはまる考え方です。
関連情報
元プレスリリース：
株式会社メディアフュージョン、ORCID公式の認定サービスプロバイダーに認定—研究者情報をORCIDと双方向連携
製品ページ：
参考資料：
- CSP Criteria: Research Information Systems（ORCID公式）
- Become an ORCID Certified Service Provider（ORCID公式）
- ORCID Certified Service Providers List（ORCID公式）
- Member API／Public API（ORCID公式）
Media Fusionについて
株式会社メディアフュージョン（本社：大阪市北区）は、大学・研究機関向けのパッケージシステムを中心に、データ管理・分析システムの企画・開発を行っています。