既存の教材やツールをLTI対応させてLMSと連携する方法を簡単に解説 (Edtech#19)
LTIに準拠していない既存のデジタル教材をLMSと接続するためには、その教材をLTIの「ツールプロバイダー（Tool Provider）」として機能させるための改修または新たなシステム開発が必要になります。
スパイスワークスでは、既存システムのLTI対応についてのコンサルティングおよびシステム開発をサポートしています。
これまでの豊富な経験をもとに、既存のツールや教材をLTI対応させ、LMSと連携する方法を解説します。
【 目次 】
- 1. ツールのLTI対応とは？
- 2. LTIの基本理解とバージョン選定
- 3. ツールプロバイダー機能の実装
- 4. 具体的な実装内容
- 5. 実装における優先順位
- 6. 実装における考慮事項と課題
- 7. LTIの開発アプローチ
- まとめ
1. ツールのLTI対応とは？
まずは「ツール（デジタル教材や教育サービス）をLTI対応する」とはどういうことかを解説します。
【既存ツールのLTI対応についての技術的な解説】
既存のLTIに準拠していないデジタル教材をLMS（各学校の教育管理システム）と接続するためには、その教材をLTIの「ツールプロバイダー（Tool Provider）」として機能させるための改修、または新たなシステム開発が必要になります。
あなたがお持ちのツール（デジタル教材等）をLTI対応するために主に必要となるのは、教材側にLMS（ツールコンシューマー：Tool Consumer）からのLTIリクエストを受け取り、適切に応答するための機能を実装することです。
以下にもう少しわかりやすい例を用いて解説します。
【既存ツールのLTI対応を簡単解説】
既存ツールをLTI対応するということは、お持ちのデジタル教材を、色々な学校のオンライン学習管理システム（LMSと呼ばれます。日本では Moodle, Canvas, Sakai, manaba, Blackboardなどがよく利用されています。）から使えるようにしたい、という意図だと思います。
例えばあなたの会社が持っているデジタル教材や教育サービスをLTI化することで、全国の大学のLMSからシームレスに（再度IDやパスワードでの認証が必要なく）繋げられるようになれば、マーケットは大きく広がる可能性があります。
これは、例えるなら、特定の形式でしか表示できない素晴らしい本（既存の教材や教育サービス）を、どんな本棚（LMS）にも置けて、しかも本棚から直接開けるようにするようなものです。
現在お持ちの教材は、この「LMSと連携するための共通のルール（LTI）」に沿っていません。LMSはそれぞれ独自に作られているため、そのままではスムーズにつなぐことが難しいのです。
そこで必要になるのが、お持ちのデジタル教材と、各学校のLMSの間で「橋渡し」をしてくれる仕組みを作ることです。
これをLTIの世界では「ツールプロバイダー」と呼び、逆にLMS側を「ツールコンシューマー」と呼びます。
2. LTIの基本理解とバージョン選定
開発に入る前に、LMSと教材がどう情報をやり取りするのか、基本的な流れを知る必要があります。現在のLTIの最新ルール（バージョン1.3）は、特に安全に情報をやり取りすることに重点を置いています。
【LTIの仕組みの理解】
LTI (Learning Tools Interoperability) は、学習管理システム（LMS）と外部の学習ツール間の連携を可能にする国際標準規格（策定:1EdTech）です。
先ほどの本棚の例でいう、「LMSと連携するための共通のルール」のことを指します。
今回のお話に関連する具体的な機能としては、お手持ちのツールをLTI対応することで、LMSからシームレスに（あらためてID・パスワードの登録などすることなしに）接続することができます。
それ以外にも、LTI対応することで学習データを統合して収集できるなど、様々なメリットがあります。
LTIについて詳しく知りたい方は、以下の記事をご参照ください。
LTIにはいくつかのバージョンがあり、早く導入された場合は LTI 1.1を利用されているかもしれませんが、2025年現在最新とされているのが LTI 1.3 です。
LTI 2.0というバージョンもありますが、こちらは LTI1.1 を改良したもので、セキュリティは改善されたものの、LTI1.1の延長的な改善でした。 LTI 1.3では認証・認可の仕組みが完全に刷新され、強化されたことで、現在では主に LTI1.3 が利用され、 LTI 2.0 は2022年6月にサポート終了となりました。
【LTI 1.3 について】
LTI1.3 が最新かつ最もセキュアなバージョンです。OAuth 2.0とJWT (JSON Web Tokens) を使用した認証・認可、成績連携（Assignment and Grade Services – AGS）、コンテンツのディープリンク（Deep Linking）、名簿情報の取得（Names and Roles Provisioning Services – NRPS）といった主要なサービス（機能）が含まれます。
【旧バージョンからの移行について】
もし可能であれば、旧バージョンのLTI 1.1ではなく、LTI 1.3での実装をおすすめします。LTI 1.1は非推奨となっており、セキュリティ上の懸念があります。
> LTI1.3へのバージョンアップについての無料相談を申し込む
3. ツールプロバイダー機能の実装
★ツール（教材側）に「橋渡し機能」を追加する。
これが一番重要な部分です。
スパイスワークスでは様々なツールのLTI化について、コンサルティングやシステム開発を行ってきました。
その経験からすると、お持ちのツール（教材）そのものに直接LTIの機能を追加するというのは難しい場合が多いです。
理由としては、教材はすでに別のベンダー様が開発されていて、今後もそのベンダー様が運用するケースが多いためです。
そういった場合は、教材とは別に「LTI連携のための中継システム」のようなものを作ります。
このように既存のデジタル教材や教育サービスを直接改修することが難しい場合、教材の手前に、LTIで送られるリクエストを処理し、教材本体に連携を行う「LTIツールプロバイダー」としてのアプリケーションを新たに構築するアプローチが一般的です。
このアプリケーションがLMSと「LTI」で通信し、既存の教材コンテンツを呼び出すゲートウェイのような役割を果たします。
この中継システムが、LMSからの「教材を開きます」という指示を受け取り、指示が正当なものか、誰が（どの学生が）開こうとしているかを確認します。
これが「LTIエンドポイントの実装」となります。
4. 具体的な実装内容
ここからは具体的に開発が必要な内容をまとめます。
【LTIエンドポイントの実装】
LTIに以下のようなエンドポイントを実装します。
◆OIDC Initiation Endpoint:
LMSからのLTIリクエスト開始を受け付けるエンドポイントです。OIDC (OpenID Connect) 認証を開始します。
◆LTI Launch Endpoint (Redirect URI):
OIDC認証が完了した後に、LMSからLTIリクエストを受け取るエンドポイントです。
このメッセージには、ユーザー情報、コース情報、LTIのバージョンや利用可能なサービスに関する情報が含まれます。
【セキュリティの実装 (LTI 1.3)】
セキュアにデータ通信を行うための機能を実装します。
◆鍵ペアの生成と管理:
LTI 1.3では、LMSとツールプロバイダー間でメッセージの署名検証に使用する公開鍵と秘密鍵のペアが必要です。
ツールプロバイダーは自身の公開鍵をJWKS (JSON Web Key Set) エンドポイントで公開します。
◆JWTの検証:
LMSから送信されるLTIリクエスト（JWT: JSON Web Tokens）の署名を、LMSの公開鍵を使用して検証し、リクエストの信頼性を確認します。
◆OAuth 2.0クライアントクレデンシャルグラント:
AGSやNRPSといったサービスを呼び出す際に、LMSのAPIにアクセスするためのアクセストークンを取得するために使用します。
【ユーザー認証と認可】
LTIによりユーザーの情報（ユーザーIDや、教師・学生といった役割など）を受け取り、ツール側でユーザーを識別（必要に応じて新規作成）し、ログイン状態を確立します。
これによってLMSからツールに移動する際、ログインしなおす必要がなくなります。
ユーザーのロール（学生、教師などの役割情報）に基づいて、教材内の適切なコンテンツへのアクセス権限を制御します。
【既存コンテンツの表示】
ユーザーのロールを確認後、デジタル教材の適切な部分（教材でいうとページ）を表示します。学生のコースによって表示する部分を変更することも可能です。
この際、LMSの画面の中に窓のように表示（iframe）することが多いです。
もし教材の中にテストなどがあって成績が出たら、その成績をこの中継システムが受け取り、LTIのルールに沿ってLMSの成績表に自動で送り返します。
これを AGS (Assignment and Grade Services) といいます。
【Assignment and Grade Services (AGS) の実装】
ツール（教材）内での学習活動（例: テスト完了、課題提出）の結果として得られる成績情報を、LMSの成績表に送信するための機能を実装します。
AGSでは、成績対象となる活動（Line Item）を作成・管理し、特定のユーザーの成績（Score）を送信するAPIを提供します。
既存教材が保持する成績データを、AGSの仕様に沿った形式でLMSに送信する仕組みを構築します。
教員がLMSから教材の特定の章や問題を選んでリンクを貼りたい場合は、ディープリンク (Deep Linking) を実装します。
【Deep Linking の実装】
ディープリンク (Deep Linking) は、教員が、教材内の特定のコンテンツ（特定の章、練習問題など）を選択してLMSのコースにリンクとして配置できるようにするための機能です。
ツールプロバイダー側でコンテンツ選択のためのインターフェースを提供し、選択されたコンテンツの情報をLMSに返す仕組みを実装します。
◆Deep Linking 実装における事例
スパイスワークスがこれまで関わってきた既存ツールのLTI対応のプロジェクトでは、この部分で工夫が必要でした。
既存ツールにはすでに教材のインデックス（例えば本棚のようなインターフェイス）が実装されており、学生はここから個々の教材に進むよう誘導されている場合が多いです。
LMSからLTIの Deep Linking 経由で教材の特定の部分に直接到達する学生と、今までどおりツールに直接ログインする学生の両方に対して成立するインターフェイスの調整が必要となります。
【Names and Roles Provisioning Services (NRPS) の実装】
NRPSは、LMSのコースに参加しているユーザーの名簿情報をツールプロバイダー側で取得するための機能です。
教材側でユーザーリストの管理や表示が必要な場合に実装を検討します。
◆NRPS 実装における事例
スパイスワークスの事例では、既存ツールをLTI対応する場合、ユーザーの取り扱いについても工夫が必要となりました。
これまでLTI対応なしに使われてきたツールに、「これまで通りツールに直接ログインして学習する学生」と、「LMSを経由して学習する学生」が混在するようになります。
LMSからユーザー情報を持ってツールに接続した学生は、既存のツール内に、LMS経由ではなく直接ログインしていた時のユーザーIDも持っている場合があります。
この場合、LMS側からLTI経由でシングルサインオンでログインした学生IDと、ツール側にもともとあった同じ学生のIDをどう扱うか（紐づけるかどうか）などの検討が必要となります。
5. 実装における優先順位
ここまで様々な機能について、実装の具体的な方法について解説しました。
解説してきたLTI1.3の全ての機能を包括すると、既存ツールのLTI化がとてもハードルの高い作業のように見えるかもしれません。
しかし、これらにはもちろん優先順位をつけることが可能です。
優先順位として最も高い、またニーズとしても最も多いのはSSO（シングルサインオン）です。
SSO（シングルサインオン）を実装することによって、多くの教育機関のLMSから、自社のデジタル教材や教育サービスをシームレスに連携させることができるので、マーケットが大きく広がる可能性があります。
次に来るのがディープリンク (Deep Linking) です。Deep Linking を実装することで、教員が指定したツール側の教材のページへ、学生を誘導することができます。
逆にツール内で実施したテストとLMSを連携しない場合はAGSの実装は必要ありませんし、ユーザー名簿をLMSと連携しない場合はNRPSの実装は必要ありません。
もちろん、SSO やディープリンクの構築においてセキュリティ対応が必須となりますが、最初からLTI1.3における全てのサービスを実装する必要がありません。
6. 実装における考慮事項と課題
この「中継システム」を作るには、LTIのルールに詳しく、セキュリティを考慮したプログラムを開発できるエンジニアの存在が不可欠です。
元の教材と中継システムの間でどう情報をやり取りするかの検討においても、経験に基づく技術的な設計能力が必要です。
【既存教材の構造と改修コスト】
既存教材がどのような技術スタックで構築されているかによって、LTIツールプロバイダーとの連携方法や改修コストが大きく変わります。
静的なHTMLコンテンツであれば比較的容易かもしれませんが、動的なアプリケーションや独自のユーザー管理・データストアを持つ場合はより複雑になりますので、個別に対応した設計が必要となります。
【データ連携の方法】
既存教材とLTIツールプロバイダー間でどのようにデータを連携させるかが重要です。
ユーザーの進捗状況、成績、操作ログなどをLTI経由でLMSに返す必要があるかを検討したうえで、連携方法を設計します。
【エラーハンドリングとロギング】
LMSとの通信でエラーが発生した場合のハンドリングや、問題発生時の原因究明のための詳細なロギング（コンピュータシステムやソフトウェアの動作状況、イベント、エラーなどを時系列で記録しておく）が不可欠です。
【セキュリティ】
LTI 1.3のセキュリティ要件（特にJWTによるメッセージ署名検証やOAuth 2.0を利用したAPIアクセス）を正確に実装することが非常に重要です。
【LMSごとの互換性】
LTI規格に準拠していても、利用されているLMSの種類によって細かな差異が存在する場合があります。中には国内に販売代理店があり、そこと連携しなければ実装が実現できない場合もあります。
ターゲットとするLMSでの柔軟な実装スキルと動作確認・テストが必要です。
【ドキュメンテーション】
開発したLTIツールプロバイダーを学校がLMSに導入・設定するための詳細なドキュメンテーション（設定手順、必要な情報、トラブルシューティングなど）を提供する必要がある場合があります。
【保守・運用体制】
LTI規格のアップデートやLMS側の改修、セキュリティ対応などに継続的に対応できる体制が必要です。
スパイスワークスでは様々なLMSの種類をターゲットに既存ツールをLTI対応し、保守・運用してきた実績があります。
開発・実装方法や保守運用方法に迷われる際は無料相談をお申込みください。
7. LTIの開発アプローチ
既存のデジタル教材や教育サービスをLTI対応する際の最適な開発方法は、環境によって異なります。
【自社開発】
LTIの仕様に精通した開発チームがあれば、自社でLTIツールプロバイダーを開発することが可能です。
教材の特性に合わせた柔軟な対応が可能ですが、LTIの専門知識と開発リソースが必要です。
【LTI開発ライブラリ / フレームワークの利用】
オープンソースなどで提供されているLTIの実装を支援するライブラリやフレームワークを利用することで、開発負担を軽減できます。
【外部ベンダーへの委託】
LTI連携の実績を持つ開発ベンダーに、ツールプロバイダーの開発や既存教材の改修を委託することも有効な選択肢です。
スパイスワークスでは、顧客の状況に応じて、コンサルティングとしてのサポートから開発まで柔軟に対応しています。
まとめ
既存のデジタル教材や教育サービスをLTI対応させることは、技術的なハードルを伴いますが、これにより様々な学校のLMSとの連携が可能になり、教材の普及にとって大きなメリットとなることは間違いないでしょう。
特にLTI 1.3への対応は、最新のセキュリティと豊富な連携機能を利用するために重要です。
具体的な実装にあたっては、ツール（お持ちのデジタル教材や教育サービス）の技術的な詳細、必要なLTI機能の実装範囲、開発リソースなどを考慮し、最適なアプローチを選択することが成功の鍵となります。
必要であれば、LTIの専門家や開発ベンダーに相談することをお勧めします。
ご不明な点があれば無料オンライン相談へお申し込みください。
