はじめに
OneRosterには、様々なバリエーションがあります。この記事でちょっとでもOneRosterの解像度が上がれば幸いです。
なお、OneRoster1.1と1.2を主な説明範囲として1.0についての説明はしません。
参考にした主なドキュメントは以下のリンク中ほどのにあります。
https://www.1edtech.org/standards/oneroster
目次
- 全体像について
- サービス Gradebook, Rostering, Resources
- バージョン 1.1, 1.2
- プロトコル CSV, REST
- モード Bulk, Delta
- それぞれの使いどころについて
全体像について
OneRosterは、教育機関で使われるSIS(学生情報システム)とLMS(学習管理システム)などの間で名簿情報や授業情報、成績データを標準的に交換するための1EdTechによる仕様の1つです。日本の小中学校においては、SISは校務システム、LMSは学習eポータルがその役割を担っている面があるかと思います。教育機関で扱う様々な情報をやり取りするためのフォーマットやAPIのふるまいが標準化されています。
サービス Gradebook, Rostering, Resources
OneRoster 1.1以降では3つのサービスに分類されており、それぞれが持つスコープや用途の概要は次の通りになります。
Rosteringサービス
ユーザーの属性情報、組織情報、所属関係の名簿情報を交換するサービスです。それぞれの代表的な情報は次の通りになります。
- 属性情報：名前、ID
- 組織情報：学校、学級
- 所属関係：登録情報(学級やコースへの)
Rosteringサービスのデータモデルはこちらの図の通りとなります。組織(Org)や学期(AcademicSession)を軸に、クラスや登録情報で降りていき、ユーザー自身の情報などを結び付けていきます。
Gradebookサービス
成績情報の交換に関するサービスです。評価項目(課題やテスト)としてLineItemというコンセプトでまとめ、その集合分類(カテゴリー)に、成績結果(Result)や尺度をいれ、成績表データとしてやり取りします。OneRosterのREST APIでは成績情報についてLMSから取り込む(Pull)だけではなく書き込む(Push)ことも可能です。Gradebookサービスにおいて成績情報がどのようにLineItemとして乗っかるかの概略図ついてはこちら、データモデルはこちらになります。
この記事の目的からはそれますが、似た情報を扱う1EdTech標準の中にLTI AGSがあります。LTI AGSはリアルタイムでの成績情報(LineItem)のやり取りを行います。Gradebookサービスは成績表の同期を目的にしています。ユースケースにあったデータのやり取りを用途が異なる標準でカバーしています。
Resourcesサービス
コースや学級、ユーザーに関連付けられる学習教材リソースのメタ情報を交換するサービスです。OneRosterにおける「リソース」とは教科書やデジタル教材、アプリのライセンス等を指し、その実体そのものではなく教材への参照情報(メタデータ) になっています。OneRosterの枠組みの中で、セキュアにライセンス情報などをやり取りできる点がメリットと思われます。
また、似た1EdTech標準にCommon Cartridgeがありますが、こちらは教材コンテンツそのものをパッケージとして配信するための仕様で、内部にリソースメタデータを含む場合もあります。
バージョン 1.1, 1.2
最新のバージョンは1.2である、現在広く使われるのは1.1および1.2です。1.0は旧バージョンでセキュリティ要件や相互運用性の観点から1.1/1.2の利用が推奨されています。
OneRoster 1.1は、名簿情報(Roastering)に加えて成績(Gradebook)の機能が導入されたバージョンです。続く1.2は1.1からのメジャーアップグレードに位置づけられており、様々な改善が行われています。主な変更は以下です。
-
サービスの分離
ワークフローを簡素化することと、必要な機能のみ選択してサポートすることを可能にするために、Rostering・Gradebook・Resourcesの3つのサービス領域に分割された -
リクエストのオプション追加
ソートやフィルター、フィールド選択が可能になりました。
OneRoster1.2と1.1は基本コンセプトやデータモデルの多くを共有していますが、非互換な変更もあります。
プロトコル CSV, REST
OneRosterでは各種データを交換する手段としてCSV(複数CSVファイルをZipファイルで交換)による方法と、REST API(JSONをHTTPで交換)による方法が規定されています。どちらもこれまでに紹介したサービスやバージョンでのデータモデルに基づいており、同じ情報を交換できます。それぞれの概要や特徴は以下の通りになります。
CSV
こちらに記載のある最大22ファイルを各サービスのデータモデルに基づき記載して、Zipファイルにまとめてやり取りすることができます。具体的な転送手段(プロトコル)は規定されておらず、SFTPサーバー経由で受け渡ししたり、手動アップロードするなどベンダーやシステムごとに運用方法が異なります。(実際にSFTPが使われている事例1,事例2)
REST API
1.2のRESTのエンドポイントはこちら、1.1はこちらに記載されています。具体的なエンドポイントのイメージはClassLinkのOpenAPIが参考になるかもしれません。CSVとは異なり、エンドポイントを利用する側(Consumer)から、クエリパラメータなどによって柔軟でリアルタイムの名簿情報の取得ができます。
モード Bulk, Delta
データのやり取りをする際の、更新方式としてBulk(一括)とDelta(差分)があります。これらは、CSVでのやり取りの際に考慮されるものです。Bulkモードの場合は一括してその時点の全データのスナップショットを転送し、受信側はこの全データをすべて真のデータとして反映します。この時、含まれないレコードは削除されます。一方、Deltaモードの場合はdataLastModifiedとstatusを含め変更があったレコードのみ転送が行われます。
それぞれのモードのふるまいはこちらに規定されています。
※REST APIにはモードの概念は明確に規定されていません。RESTの場合は常に最新のデータを取得し、利用するエンドポイントやパラメータによってある更新日時からの差分を取得することも可能です(クエリパラメータのFilterによってdataLastModifiedとstatusを指定できる)。
それぞれの使いどころについて
バージョンについて
バージョンは1.2が最新であり、1EdTechも相互運用性の観点から最新への準拠を推奨していますが、2025年3月時点の対応状況は以下のようになっています。(1EdTechの認証を得たプロダクトは、こちらで確認できます。)
- OneRoster 1.1：126プロダクト
- OneRoster 1.2：42プロダクト
日本では日本1EdTech協会が1.2に準拠しローカライゼーションしたCSV仕様を、こちらで公開しています。これらの状況から、一概に1.2に準拠することがベストとは言えず、状況に応じてどちらを搭載するか検討する必要があるかと思います。例えば、Microsoftは1.1に対応していますが、日本の文部科学省やデジタル庁での実証は1.2をベースにしています。
サービスについて
こちらは、連携したい情報から逆算して自然と決まる部分かと思います。年次更新という作業の軽減のためには、RoastringとResourcesが有効活用できると考えらます。他方、データ利活用を行う観点ではGradebookが有効活用できると考えらます。
プロトコルについて
こちらも議論が分かれるところかと思います。個人見解を記載したいと思います。運用上のコストはREST APIのほうが低いと思われます。CSVをSFTPでやり取りする方法や人手でエクスポートインポートする手間などを考えると、RESTで名簿情報の利用者が必要なタイミングで必要な分だけ(オンデマンドで)やり取りすることがランニングコストは低いと考えられます。一方、個人情報保護やセキュリティポリシーの兼ね合いから、システムのダイレクトなHTTP通信が難しくZipファイルにする方法も考えられます。これら以外にも、様々なステークホルダーごとに望ましいプロトコルが異なることが考えられるため一意な判断をするのが難しいかと思います。ただし、柔軟性やセキュリティ面を考えるとREST APIでOAuth2.0で認可を受けてやり取りすることが今後のあるべき姿と考えます。
CSVについては、アーカイブやバックアップという利用場面には適しているためRESTのみになることもないと考えます。
モードについて
モードについては、CSVとする場合の検討事項と考えると基本はBulkかと思われます。Deltaによって日時更新をするようなユースケースの場合、RESTでやり取りすることが技術観点ではベターな選択肢と考えられます。名簿データのバックアップの際は、フルバックアップと差分バックアップの考え方に合わせてBulkとDeltaを選択することになるかと思います。
日本の小中学校での取り込みかたについて
長文を書いてしまったのですが、この記事でまとめるには適していないので、各省庁や業界団体(文部科学省やデジタル庁、業界団体、ICT CONNECT 21, 日本1EdTech協会、こども未来教育協会など)での取り組みに預けたいと思います。といいつつ1つだけ。AAA(AuthN, AuthZ, Accounting)のうち、AccountingはSIS(校務システム)が担うべきと考えています。トータルコストを下げられる効果的な方法は校務システムがAccounthingを担い、学習教材にデータを連携していくことが必要と考えます。そのため、校務システムがOneRosterのRESTもCSVも各種サービスも対応し、学習eポータルやデジタル教科書ビューアやEdTechアプリがそれぞれ1EdTechの標準に則りデータのやり取りをしていくことが1つの理想的な”エコ”システムと考えます。