投稿者: 林 向達

なんとなく教育データ標準のことをぼんやり考える日々の記録です。（#教育データ）

教育データ標準の世界は，長らく続く国際標準規格の積み重ねがありますから，素人考えで語るのはやめて，そろそろあなたも標準規格ベースでしゃべりなさいよと，虎ノ門あたりに集っている人達からお叱りが飛んできそうです。

—

これまで「主体情報」「内容情報」についていくらか成果が公表され，今年度は「活動情報」について何かしらかたちを示しなさいというのが文部科学省の宿題。

私は駄文で「教育データコンテナ」といった呼び方で各種の情報を盛りつけるお皿を考える必要があるとお説ぶっていたわけですが，それにあたる標準規格はすでに存在しているわけです。

「Experience API」と呼ばれる学習経験の記録と共有のための規格です。

経験（experience）のためのインターフェイス規格という正式名称は「名は体を表わす」になっていて分かりやすいのですが，一方，略称表記は「xAPI」とされているため，こちらは補足説明されなければ何の規格だか推測が難しいです。私も長いこと「x」が何なのか知らないままでした。

Experience API（xAPI）は，「誰が／何を／どうした」という要素情報の組合せ（ステートメントと呼びます）をJSONというWebの世界でもお馴染みのデータ形式でひたすら記録していく枠組みを定めた汎用的な規格です。

要するに，活動情報の記録は「xAPI」を使いなさいということです。

確かに教育データ標準が始まった当初から，そういうつもりであったことは明記されています。

ちにみに「xAPI」とともに「IMS Caliper Analytics」という規格名も併記されていますが，こちらも学習履歴を記録・共有するために作成された規格の一つであり，両者は重複部分を持っているとされています。

どちらがよいのかは議論が残るところですが，個人的にはxAPIの方がオープンでよいかなと考えています。一方のCaliper Analyticsは規格管理団体のIMSが他の規格とともに推していることもあるので，兼ね合いを考える人々はCaliper推しかも知れません。両者歩み寄りの動きもあるとかないとかで，しばらくは併存すると思われます。

それで，日本はどうするのか？ですが，これはわりと明解で，デジタル庁で閲覧できる「教育データ利活用ロードマップ（令和4年1月7日デジタル庁、総務省、文部科学省、経済産業省）」にはっきりと記されています。

スライドの反対側にはまた別の「学習履歴」の情報も視野に入れられているので，IMS Caliper Analyticsやら何やらの規格はそちらで活躍することも想定されているのだと思います。

—

さて，こうやって「初めからそうだった」と書いている私にしてみても，あれこれ掘り起こしてみたら「そうだったんだ…」という感じで見返しているところ。

確かに書いてはあるし，初めから関わっている人達には自明な話だったんでしょうけれど，活動情報の教育データ標準作業が，xAPI規格を扱えるようにしたい話なんだよとは，誰もはっきり教えてくれたり解説してくれたことはなかったように思います。

最近「教育データ利活用に関する有識者会議」で文部科学省 教育DX推進室・桐生室長の発言によって，素人の私にもこの辺がようやく明確になりました。

教育データ利活用に関する有識者会議（第13回） 47'25''あたりから
https://youtu.be/Mstu2V2sFMM?t=2845

桐生室長「教育データ標準の方の話がありましたので，ちょっと現状をお話したいと思います。教育データ標準第3版を今年中に出すという話が進められております。中でも活動情報をきちんと検討して，その枠組みと具体的な姿というものをお示しできるよう，いま文科省の委託事業の中で検討を始めております。この中で学習ログも，eポータルからxAPIで書き出す際にどういった考え方で，どういう風にやっていくのか，といったような議論を今進めております。 これまた近々，こちらの会議でも諮らせていただいてご議論進めさせていただければと思います。」

教育データ利活用に関する有識者会議（第13回）より［読みやすく文末改変］

というわけで，学習eポータルやMEXCBTなどのシステムで，学習履歴や学習経験を記録するためにxAPIを使えるようにして欲しいというのが現在目指していること。

そして，その作業を，委託事業の作業チームの皆さんが頑張ってるっぽいです。

けれども，xAPIを使えるようにするっていうのは，学習eポータルを開発している各社の開発者が頑張る話じゃないのでしょうか？なぜ，文部科学省から委託されている事業で取り組んでいるのか？

標準規格があるなら，そのルールに合わせればよいだけの話で，何故あらためて検討する必要性があるのでしょうか？

もしもあなたが，そんな疑問に気がついたとしたら，いよいよ国際標準規格の沼の世界へと誘われる準備が出来たということかも知れません。

—

データ交換に支障が出ないように共通ルールを定めることが標準規格の目的です。

共通ルールと一口に言っても，何を共通化するのかは様々です。データの形式，通信の手順，項目の定義など概念的な構造から技術的な規則まで目的に応じて非常に多様です。

だから，標準規格というのは，かなり時間をかけて育てていくように構築されます。

多様なものに対応するためには，共通の土台となる大枠の規格を構築しておいて，目的や領域に応じた個別具体的なルールをその土台の上に組み上げていくといった形をとることもあります。

xAPIは「あらゆる学習履歴を記録する」というかなり大きな目標を掲げた規格で，個別具体的な履歴情報の詳細な記録方法については「プロファイル」という別ルールをみんなで決めるという仕組みを採用しています。

先ほどデジタル庁のスライドで見た吹き出しをもう一度見てください。

「内容」「verb」「object」「context」「result」「timestamp」「scored」「authority」という単語が並んでいるわけですが，これらはxAPIの記録（ステートメント）に含める項目です。

そして，実際に含める項目は，必須項目を除いて，実は増えたり減ったり，項目の構成は自由になっています。xAPI自体は，項目をいろいろ含んで記録できるよぉ，それを規格に従うことで柔軟に交換・共有できるよぉ，という大枠だけ規格化しているのです。

しかし，項目を自由にできると，そもそも交換するときに困るって話じゃなかったっけ？

という指摘が出るのは当然のこと。もちろん，自由にできるからといって，自由にやってよいとはされてないわけです。

上図の黄色い吹き出し「学習履歴xAPI」は，紫色の角丸四角「学習履歴（学校）」から出ていることはお分かりいただけると思いますが，実は，この「学習履歴（学校）」というものを記録するために「学習履歴xAPI」の吹き出しの中の項目は，本当に「内容」「verb」「object」「context」「result」「timestamp」「scored」「authority」でよいのか？は，まだ答えが出ていないのです。

デジタル庁も文部科学省も，まだ「学習履歴（学校）」に相応しい「学習履歴xAPI」の中身が何なのかを決めておらず，その項目構成を委託事業の作業チームに整理して欲しいと考えているわけです。

たぶんですが。

—

どうも話がまるで見えない…という方もいると思います。

そもそも「学習履歴（学校）」って何なのよ，という素朴な疑問は残っているでしょう。

子どもたちの学校での学習活動を記録する場合に，何でもかんでも記録するのか？それって監視環境じゃないか？という疑問や不安もおのずと出てくると思います。この話は，どうしても実際の運用範囲の問題に関心が向かってしまいがちです。

疑問に対しては，先の文部科学省の室長発言にもあったように，現時点で想定しているのは「学習eポータル」で扱う学習活動が記録の対象だといえます。つまり学習に利用したWebサービスの利用記録や成績情報といったものです。

xAPI規格誕生の経緯的にも，そうした運用が真っ先に想定されています。

そもそもxAPI規格は，それまでeラーニングの世界で拡張され続けてきたSCORM規格を置き換えるものとして登場しました。そんなこともあってか，xAPI規格はWebベースドな学習活動を記録する用途に用いられることが多いのです。

xAPI規格に組み合わせる個別具体的な目的のためのルールとして「cmi5」というプロファイルがあります。このcmi5というのがeラーニングシステム（Webサービス）における学習記録管理を目的とした詳細なルールを規定して，xAPI規格を補っているというわけです。

文部科学省が今回の教育データ標準の作業の目標として考えているのは，学習eポータルにおけるxAPI規格の詳細なルールの規定をどうするかであることは，ご理解いただけると思います。そして，少し目的が違っていることもあって「cmi5」ではなさそうだ，ということも何となく分かっています。

—

xAPI規格を作成したのは，米国国防総省のAdvanced Distributed Learning（ADL）という団体です。しかし，組み合わせるプロファイルは必ずしもADLがすべてつくるわけではありません。

加えて，xAPI規格は，国際的な技術標準化機関であるIEEEのもとで新たなバージョンや，様々なプロファイルが取り組まれており，国際標準規格としてもステップアップしているようです。

また，日本学術会議の提言「教育のデジタル化を踏まえた学習データの利活用に関する提言 −エビデンスに基づく教育に向けて−」にも記載されている米国のCommon Education Data Standard（CEDS）の取り組みは，項目定義の規定はもちろんのこと，各州で異なる項目定義を調整するツールを提供して，できるだけスムーズなデータ交換に役立てられるような取り組みを続けています。

こうした先行する取り組みやプロファイルを参考に，日本の学習eポータルで利用できるxAPI規格の独自プロファイルの作成が進められている…んじゃないかと，何となく思ったりしている今日この頃です。

「教育データ標準」について考える駄文の続きです。（前回）

文部科学省が取り組んでいる「教育データ標準」という取り組みは，サービス提供者や使用者が「相互に交換，蓄積，分析が可能となるように収集するデータの意味を揃えること」を目的としています。

「データの意味を揃える」というのは，たとえば，アンケート質問に対する選択肢を統一するような試みのことです。

「職業」の選択肢を用意するとき，「学生／社会人／…」とするか，「小・中学生／高校生／大学生／サラリーマン／自営業／…」とするか。これがバラバラだと調査結果の比較が面倒になるのと同じで，教育データも記録するデータの意味を揃えないと交換，蓄積，分析で面倒が生ずるというわけです。こういうのを「データの桁を揃える」みたいに表現することもあります。

ちなみに，心理学における心理測定（心理アンケート調査）の世界では「尺度集」というものが蓄積されており，これを共有することで，別々に実施された測定結果を比較検討できるような文化があります。いろんなジャンルのものがありますが，子どもの発達に関係するものを集めた『心理測定尺度集IV　子どもの発達を支える〈対人関係・適応〉』（サイエンス社）は有名です。

—

さて，教育データ標準のお話。この取り組みはいま３年目を迎えています。

これまで「学習指導要領コード」と「学校コード」を公表し，さらに児童生徒と教職員と学校と教育委員会という「主体情報」に関するデータ項目の定義を公表しました。下のリンクが文部科学省「教育データ標準」のWebサイトになります。

前回も見ましたが再度，そこで公開されている「主体情報」のデータ項目の一覧を覗いてみましょう。

図の文字が小さくて読めないとは思いますが，児童生徒の主体情報についてずら〜っと項目が羅列されていることが分かります。

「こんなにたくさんのデータ項目をつくって個人の情報を記録するのか！！」と抵抗感を抱きたくなりますが，こういうものはあらかじめ用意しておくことに意味があります。

つまり，データをしまう場所は確保しておくけど，実際にデータをしまうかどうかは別の話。

たとえば「ミドルネーム」という項目は，日本ではミドルネームもっている人がまだ少ないので，実際には使わない空っぽな項目になりがちです。だからといって，この項目定義をけずってしまったら，ミドルネームを持っている人達が自分の名前を記録できなくなってしまいます。

文部科学省の説明では…

（留意点）
・標準化の対象はデータの全てを教育データ項目を網羅しているものではなく、データの相互運用性を図る観点から全国的な定義の統一が必要なものを中心に優先的に整備している。
・ここで定義している情報を各学校等で集めなければならないものではない。（法令等で規定されている情報等は当該規定に従う必要がある。）
・標準項目以外に各学校設置者、学校で必要と考えるデータがあれば独自に定義して活用することは可能。

という留意点が付されています。「これが全部じゃないよ」「全部集めるわけじゃないよ」「新たに項目作っていいよ」というわけです。

児童生徒の名前は「fullName」という定義名にして，一方，教職員の名前は「staffFullName」という定義名にすれば区別がつくでしょ…といった約束事が項目ごとにずら〜っと決められている。そのことがとても大事だということです。

—

教育データ標準とは，たとえて言えば，種類の豊富なバイキングメニューです

私たちは食べたいだけのメニューをバイキングから選んでトレイ皿の上に盛りつけていくことになりますが，とはいえ栄養バランスにも気をつけたいので定番メニューは押さえつつ選ぶといった調子になるわけです。

教育データの場合，好き勝手な組合せでは具合が悪いこともあります。そこで，おすすめの組合せ「推奨データセット」なるものを用意して，どれを選んだらよいか迷う人達に提示しようというアイデアも出ています。

とはいえ，このおすすめセットの選定は，言うほど簡単ではありません。

「主体情報」（個人情報）といった，特定対象物を表現するためのデータセットを決めることは，ある程度分かりやすい作業です。

しかし，教育データは「主体情報」×「活動情報」×「内容情報」という異なる区分を掛け合わせることが前提となります。これは「個人データ」＋「成績データ」といったシンプルな話に留まり得ないということです。

いや，どうも周りの皆さんは，そのシンプルな話にしたがっているようです。

〈教育データセット〉＝「個人データ」＋「成績データ」という構成で利用されると想定できれば，〈教育データセット〉−「個人データ」によって匿名化された成績データの集合をビッグデータ分析が可能であるともっていけるからです。

これを〈教育データセット〉＝「個人データ」＋「活動データ」＋「成績データ」としても同じような論法で分析の対象に出来るということかも知れません。

確かに，現実的にはそういう教育データの推奨セットを提示することになるのかも知れない。

けれども，それは前回の駄文で書いたように，管理者や開発者には意味があるとしても，利用者にとっての教育データセットとしての意味は生み出せるんだろうか？と疑問符が浮かぶわけです。

—

もう一度，教育データ標準が描いている情報の区分を見てみましょう。

教育データ標準というバイキングメニューから，データセットを盛りつけるだけの準備は整っていません。用意できたメニューは〈主体情報〉のデータ項目と学校コード，〈内容情報〉の学習指導要領コードだけです。

大きな区分の残りひとつ〈活動情報〉を記録するためのデータ項目も早く定義しなければなりません。

文部科学省としては〈活動情報〉を児童生徒の「生活活動」と「学習活動」，教職員の「指導活動」に区分して検討することを考えているようです。これはこれで検討をしてもよいでしょう。

けれども，いよいよ〈主体情報〉×〈内容情報〉×〈活動情報〉のデータセットを考えるとなると，実はこれらを盛りつけるための「トレイ皿」に注目しなければなりません。

仮に呼ぶなら「教育データコンテナ」という捉え方で教育データを組み合わせる必要があります。

コンテナといっても，別にそれほど大そうなものではありません。

たとえば校務や学習系アプリケーションで利用されている名簿交換の技術標準であるOneRoster（ワンロースター）では，複数のCSVファイルを束ねる形も採用していて，「manifest.csv」というコントロールファイルで複数のCSVファイルの管理情報を記録するように定めています。これも言ってみればコンテナのようなものです。

〈主体情報〉〈内容情報〉〈活動情報〉を束ねるコントロール情報を含んだ「教育データコンテナ」として扱うようにすれば，今後新たな情報区分が増えたとしても教育データコンテナに加えるだけで対応ができます。

—

〈主体情報〉〈内容情報〉〈活動情報〉を「〈主体情報〉＋〈内容情報〉＋〈活動情報〉」して，これを教育データコンテナとして扱うことも可能ですが，繰り返すように「〈主体情報〉×〈内容情報〉×〈活動情報〉」する形で扱うことを考えたいのです。

さっきから，足し算と掛け算で何が表わしたいのか，読者には意味不明かも知れません。

端的には，教育データコンテナ自体にデータ本体を保持するかしないかの違い，といってもよいかも知れません。

たとえば，教育データコンテナに〈主体情報〉そのものは保持されない，あるいは識別子のみ保持されるといった構成です。識別子がある場合も，識別子からAPI等で主体情報にさかのぼれる場合と，主体から一方方向に認証できるだけの場合が考えられます。設定次第で教育データコンテナを分析研究用のビッグデータセットとして直接利用できるかも知れません。

個人的に，教育データコンテナは〈活動情報〉を土台としたものになると考えていて，そこに〈内容情報〉が内包される形をとるのが自然ではないかと考えています。活動を単位とした教育データコンテナが無数に生成されるというイメージです。そして，無数にある教育データコンテナの中から関係するものが〈主体情報〉によって領有されるというわけです。（逆に言えば，手放すこともできる理屈です。）

そうなると，当然のことながら教育データコンテナを格納していく場所が必要になることが見えてきます。

この場合の「格納」は技術的にデータを記録保持する場所という意味もあり得ますが，もう少し抽象的なデザインレベルの議論を続けさせてもらうと，私たちが教育データコンテナ（活動単位）を把握するための枠組みが必要だということです。

それは，もうシンプルに「タイムライン」を考えればよいのではないかと考えています。

この部分は，教育データコンテナを格納するアイデア次第で，いろんな広がりが生まれる部分と考えていて，うまくいけば学習eポートフォリオに再び光が当たるかも知れない領域ですが，技術的な設計をちゃんと組み立てて，それを一般の皆さんにも理解してもらわないと，また個人データが私企業に流れるとかなんとかで誤解を受けてしまいかねないところだと思います。

ただ，少なくとも「学校タイムライン」は教育データ標準の範疇で扱えるのではないかなと考えています。

—

ここで視点を変えて，学校の教育活動をデータとして整えていくことを考えてみたいのです。

今後，学習者一人ひとりの学習活動のパスウェイ（道筋）はますます多様化していきます。それを学習者タイムラインとして記録していくというアプローチも当然あってよく，自分の学習履歴が教育データコンテナの集積として時系列的に記録されるというのはイメージしやすいと思います。

もう一方で，学校という場はどうなっていくのか。

時間割どおりの授業が展開する昔ながらの風景が続くところもあるでしょうし，チャイムもなく学習活動は個人個人のプランにもとづいて展開していくといった学校も当たり前のように存在するかも知れません。あるいは，もう実空間に集まるといった形ではない遠隔や仮想空間上のコミュニケーションとして学校という場が存在することもあるかも知れない。

いかなる形の学習活動（それを記録する教育データコンテナ）が生成されるとしても，それを学校という場の活動として取り込み位置づけることが必要です。まぁ，そんなに多様な現実になったら，そこまで「学校」という枠組みに固執しなくてよいんじゃないかとは思いますけれど，とにかく学校が存在するというならば，学校として教育データコンテナを格納できるような土台を用意しておきたいわけです。そんな土台が必要ないというならば，逆説的にもはや学校という場もいらないということです。

学校タイムラインは，素朴に表現すれば一番最初に言及した「時間割」をベースにしたものです。

昭和な学校を想定して説明するなら，何年何月何日の月曜日1時間目といった「活動時間枠」毎にどんな集団がどんな活動を行なったのか，時間割の情報をもとに学校タイムラインの土台を整えておくのです。

この学校タイムラインの土台が整うだけで何が可能になるかというと，「このクラスの先週火曜日の３時間目は何の授業だった？」という検索に対して答えられるようになるということです。

たとえば，AlexaとかGoogleアシスタントとかSiriと接続してみたとしましょう。

社会科の先生が，昨日の２時間目に社会科授業をしていて，今日は３時間目に社会科授業の続きをする状況を想像します。いざ授業を始めるときに先生はパソコンにこう呼びかけるのです。

「OK，昨日のスライド表示して」

するとAIアシスタントは，学校タイムラインの情報をもとに，現在が社会科授業であることを察知し，次に昨日の授業から社会科が実施された時間帯を検索し，その時間帯に開かれたスライドファイルをパソコンから呼び出してスクリーンに投影する…なんてことが可能になります。

これは学校タイムラインの情報だけを利用した想像事例ですが，このように学校のカリキュラムを時間割ベースでデータ化した学校タイムラインを土台に，学習集団の名簿データや教育データコンテナとのリレーション（関連）を結んでいくことによって，学習者の学習活動を学校タイムラインに配していくことが可能になります。

もちろん，教育データコンテナを児童生徒の主体情報とセットで学校タイムラインに結びつけていくためには，初めの段階で学習者から学校関係者に対して情報アクセスに関する包括的な許諾を手続きする必要があると思われます。こうした学習者の領有する教育データに対する学校関係者のアクセス権は，在学期間中に限定するなどの時限式であったりもするかも知れません。

いずれにしても，学習者は自身の学習者タイムラインの上に教育データコンテナをプロットすることによって学習履歴をコントロールできるし，学校関係者も許諾にもとづき学校タイムラインのもとで教育データコンテナへのアクセスが可能になるというデザインです。

これとは別に学習eポートフォリオのような形で教育データコンテナをプロットできる仕組みが出来れば，それを転校する際の教育データの受け渡しフォーマットとして利用することができるかも知れません。それはそれで交換用のフォーマットを考える必要があると思いますが…。

—

今回は，図の作成まで手が回っていないので，まさに駄文の羅列でアイデアを書き連ねることとなり，伝わるものも伝わらない感じになっているかも知れません。

途中，考えるために作図はしていましたが，ラフなもので，完成もしていません。

実際の「教育データ標準」的には，活動情報についてはオンラインコースの学習履歴を記録する技術標準を土台に考えたがっているようで，果たして私たちの実際の学校の教育活動にどれだけフィットするものになるかは，正直よく分かりません。

途中にも書いたように，単なる学習成果のみならず，学習活動の道筋（パスウェイ）も重視されるようになるとすれば，単なる学習コースの履歴だけでなく，異なる学習活動が組み合わさった道筋自体を表現できるデータ構造が必要になってくるはずです。

今回の妄想は，そのパスウェイをタイムラインとして表現したわけですが，あるいはそれはマップという表現形式かも知れませんし，それはいろいろあり得ると思われます。

そのいろいろ様々あり得るということを考えると，私たちは教育データ標準を決めるというだけでなく，教育データ標準を定期的あるいは継続的にアップデートするプロセスなり体制なりを確立することの方が重要なのではないかとも思えます。

物事は生み出している間は活発にやれていても，ピークに達すると衰退していくのが常。

そのことが分かっているなら，むしろその対処を真剣に考えることの方が重要に思えます。