LMS RFPのページとLMS比較チェックリストは何が違いますか?

同じ60項目を使いますが、表の向きが逆です。RFPのページは候補に要求する仕様(要求レベル・提出証跡・検証方法)であり、LMS比較チェックリストは候補を評価する比較表(確認方法・主管部署・判定尺度)です。提案依頼書を出す前ならRFPのページを、提案書を受け取って審査している最中なら比較チェックリストをご覧ください。項目番号が同じなので、RFPの回答を比較表のマスにそのまま書き写せます。比較チェックリスト: https://www.touchclass.com/ja/lms-comparison-checklist

LMS RFP · 提案依頼書

LMSのRFPはどう書くか

Q: LMSのRFPはどう書きますか?

調達範囲を一文で確定し、現行のインベントリを添付したうえで、要求事項を必須・推奨・任意に分けます。次に要求事項ごとに提出証跡を文書名まで指定し、検証方法(デモ・文書・PoC・パイロット・契約)を発注者が先に固定します。最後に評価配点と失格ルールをRFPに公開し、費用は3年TCOの様式で受け取り、契約終了条件を提案段階で要求します。この8ステップを守れば、3社の提案書が同じ軸で比較できます。

Q: LMS RFPの要求レベル(必須・推奨・任意)はどう分けますか?

必須は、なければ運用が成立しない項目で、未充足なら失格と明記して初めて効力が生まれます。60項目中32件で、法定研修の自動管理、修了条件の自動判定、権限分離、セキュリティ8項目すべて、3年TCO、契約終了条件が含まれます。推奨は配点に反映する27項目、任意は加点1項目です。参加・LXP・AIのカテゴリに必須が1件もないのは意図した設計です。法定研修とセキュリティが埋まる前にAIを必須にすると、RFPが新技術ありきの文書になります。

Q: 提案者の「対応しています」という回答をどう防ぎますか?

要求事項ごとに、何を提出すれば対応と認めるのかを発注者が先に書くしかありません。認証書の原本と認証範囲、負荷テストの結果値とテスト条件、直近3年の障害履歴、持ち出しファイルの実物のように文書名で書きます。そしてRFPの案内文に、「充足」とだけ書かれ添付がない場合は未回答として扱うと明記してください。証跡のない要求事項は、要求事項ではなく希望です。

Q: LMSベンダーの運用規模はどう検証しますか?

「大企業に多数導入」は検証できる文ではありません。単一顧客あたりの最大学習者数を求め、導入顧客数の合計は認めないとRFPに書きます。負荷テストは数値だけでなくテスト条件(ツール・シナリオ・測定時点・インフラ構成)も併せて受け取り、その値が保証された常時収容量ではないことを要求文に明記します。タッチクラスは単一顧客あたり最大39,000名、同時接続18,000名の負荷テスト値(保証された常時収容量ではない)を公開文書として提出します。出典: https://www.touchclass.com/ja/lms-benchmark#operating-scale

Q: AI要求事項はLMSのRFPにどう入れますか?

一般の機能要求の中に混ぜず、別章として分離してください。「AI機能があるか」を1行で書くと、統制・証跡・費用構造がすべて抜けたまま「対応」という回答が返ってきます。AIはデータ、統制、検証という別の軸を持ちます。公開提案依頼書で繰り返し確認されるAI統制要求8種(データ学習からの除外・外部送信の遮断・呼び出し範囲の制限・入出力の検証・出典表示・監査ログ・持ち出しと削除の証跡・権限別の出力統制)とAI RFP作成8ステップを https://www.touchclass.com/ja/ai-lms からそのまま引用してください。

Q: タッチクラスはこの60の要求事項をすべて充足しますか?

いいえ。3項目に条件付きで回答します。35番のスキルグラフは、関心キーワードのキュレーションには対応しますが、職務-力量のスキルグラフは別途設計が必要です。43番のAI高リスクHR判断の分離は、AI機能はありますが、昇進・評価・報酬との分離には顧客側のポリシー・承認・監査体制が揃う必要があります。53番のキャプチャ防止は、キャプチャログとマスキングには対応しますが、iOSはOSの特性上、完全遮断とは主張しません。3件ともページにそのまま公開しています。条件付き回答が1件もない提案書のほうが、むしろ確認すべき回答です。

2026年7月時点 · 要求仕様60項目

提案依頼書は機能一覧ではなく要求仕様です。要求レベル(必須 · 推奨 · 任意)、提出証跡、検証方法を1行ごとに固定して初めて、提案書が同じ軸で返ってきます。9カテゴリ60の要求事項、作成8ステップ、ベンダーに求める証跡5種を、フォームなしで公開します。

60項目

要求仕様
9カテゴリ

32項目

必須(Must)
未充足なら失格

8ステップ

RFP作成手順
範囲 → 終了条件

要求仕様60項目を見る CSVをダウンロード(フォーム不要)

RFPが失敗するのは、候補ごとに違う問いを投げているからです

提案依頼書を出した組織は、たいてい同じところで詰まります。3社の提案書が、互いに比較できない状態で届くのです。A社は機能のスクリーンショットを80枚、B社は導入事例、C社は価格表だけ。原因は候補側ではなくRFPにあります。要求事項が「優れた学習管理機能」と書かれていれば、各社は自社の得意なものをその一文に当てはめて答えます。

直す方法は一つです。同じ要求事項、同じ確認方法、同じ評価尺度。要求事項の1行ごとに ① 要求レベル(必須 · 推奨 · 任意)、② 提案者が提出する証跡(文書名まで)、③ 発注者が確認する方法(デモ · 文書 · PoC · パイロット · 契約条項)を先に固定します。この3つの欄が埋まった瞬間、「対応しています」という回答は自動的に無効になります。

このページは9カテゴリ60の要求事項をその形式で公開します。表をそのまま複製して提案依頼書の要求仕様として使い、右側に候補社の回答欄を足して配布してください。このページのどこにも候補社の名前はありません — 誰を比較対象にするかは発注組織が決めることであって、ベンダーが決めることではないからです。

比較表を作る段階であれば、この文書ではなくLMS比較チェックリスト60項目のほうが適しています。2つの文書は同じ60項目を使いますが、目的が違います — チェックリストは候補を評価するための表、このページは候補に要求するための仕様です。違いは下の表に整理しました。

LMS RFP 作成8ステップ

全面刷新か、1区間の並行運用か。この一文が決まらないと、提案の規模が候補ごとに変わり、価格が比較できません。対象人数、運用期間、既存システムの扱い、予算帯をRFPの1ページ目に書きます。全面刷新を前提にすると意思決定の単位が大きくなり、結論が先送りされ、結局は現行LMSが維持されることが多くなります。
推奨する初回範囲: 50~100名 · 4週間 · 教育課題1件 · 既存LMSは維持
発注者が自社の現況を表にして出さなければ、そもそも見積が出ません。学習者数、年間の運用コース数、法定研修の種類、連携中のシステム(HRIS · グループウェア · ポータル)、保有コンテンツの形式と容量、現在のデータを持ち出せる形式を書きます。この表がないと、連携工数とコンテンツ移行の費用がすべて「別途協議」で返ってきます。
「別途協議」で返ってきた項目は、契約後に追加請求される項目です
すべての要求事項を同じ重さで書くのは、何も要求していないのと同じです。必須(Must)は未充足なら失格、推奨(Should)は配点に反映、任意(May)は加点です。下の60の要求事項は必須32 · 推奨27 · 任意1に分かれ、セキュリティ8項目はすべて必須です。
必須32 · 推奨27 · 任意1 — セキュリティ8項目はすべて必須
「対応しています」という回答を防ぐには、何を提出すれば対応と認めるのかを発注者が先に書くしかありません。認証書の原本と認証範囲、負荷テストの結果値とテスト条件、直近3年の障害履歴、持ち出しファイルの実物サンプルのように文書名で書きます。証跡のない要求事項は、要求事項ではなく希望です。
チェックボックス ✓ は証跡ではありません — 文書 · 画面 · ファイルの実物を指定してください
デモのシナリオを候補が決めると、候補が得意な場面しか見られません。項目ごとにデモ · 文書レビュー · PoC · 4週間パイロット · 契約条項の照合のいずれかを発注者が指定します。コンテンツ制作力は「機能があるか」ではなく、発注者が当日渡したPDF 1件から担当者1名がコンテンツ1件を作るまでの実測時間で測ります。
デモのシナリオ · 検証データ · 測定指標は発注者が用意します
配点を隠すと、候補は価格だけで勝負します。技術と価格の配点比率、必須項目が未充足の場合に失格とするか、条件付き回答(一部対応 · ポリシー前提 · 別途開発)の扱いをRFPに書きます。条件付き回答を0点とするか、減点とするか、導入前の別課題として切り出すかは発注者が決めます。決めなければ、審査当日に揉めることになります。
条件付き回答が1件もない提案書は、それ自体が判断材料です
1年分のライセンスだけを比較すると、3年目に順位がひっくり返ります。ライセンス、1人あたりの増分単価、最低契約金額、コンテンツ購読、連携開発の工数、運用支援、値上げ率の上限、終了時の移行費用まで同じ様式で受け取ります。見積書の空欄は0円ではなく「未提示」として扱い、未提示の項目は審査で減点します。この様式に入れる項目と規模別の金額帯はLMS導入にいくらかかるのかで計算根拠とあわせて確認してください。
空欄は0円ではなく未提示 — 後から請求される項目です
終了条件は契約書を書くときに交渉する項目ではなく、RFPに入れて提案段階で回答を受け取るべき項目です。データの持ち出し形式(ファイル形式 · スキーマ · 所要期間)、顧客が制作したコンテンツの所有権、学習履歴の持ち出し範囲、移行支援期間、解約通知期限を要求事項60番に入れています。持ち出しのサンプルファイルを実際に開いて確認するところまでが検証です。
入る条件より、出る条件を先に確認します

1. 調達範囲 — RFP 1ページ目に書く一文

対象人数 · 組織

全社か、1事業部か

既存LMSの扱い

刷新 / 並行 / 段階的移行

契約期間 · 予算帯

1年 / 3年 — TCOの算定基準

「全社LMSの高度化」 → 「1事業部800名 · 3年 · 既存LMSは並行」

範囲が曖昧だと価格が比較できません

2. As-Is インベントリ — RFP添付の様式

学習者数 · 管理者数 · 年間運用コース数

法定研修の種類と対象者の範囲

連携システム — HRIS · グループウェア · ポータル · SSO

保有コンテンツ — 形式 · 数量 · 容量

現行LMSから持ち出せるデータ形式

最後の行が空欄なら、まず今使っているLMSから確認します

3. 要求レベル — 60項目の分布

必須

32項目

推奨

27項目

任意

1項目

必須 — 未充足なら失格

推奨 — 配点に反映

任意 — 加点のみ

セキュリティ · 個人情報の8項目はすべて必須

4. 提出証跡 — 回答を文書に変える

「セキュリティ認証を保有」 → 認証書の原本 · 認証範囲 · 有効期限 · 事後審査の履歴

「大規模運用が可能」 → 単一顧客あたりの最大学習者数 · 負荷テストの条件

「安定した運用」 → 直近3年の障害履歴 · 復旧時間 · SLA

証跡のない要求事項は希望です

5. 検証方法 — 5種から項目ごとに指定

デモ

発注者が渡した
データで実演

文書

提出証跡の
原本を確認

PoC

実環境で
連携試験

4週間パイロット · 契約条項の照合

シナリオを候補が決めると、得意な場面しか見られません

6. 配点 · 失格ルール — RFPに公開

必須項目の未充足

32項目のうち1件でも ×

失格

条件付き回答

一部対応 · 別途開発が前提

減点

証跡の未提出

「契約時に提供」という回答

減点

ルールを決めなければ審査当日に揉めます

7. 3年TCO — 同じ様式で受け取る

ライセンス · 1人あたり増分単価 · 最低契約金額

コンテンツ購読 · 連携開発の工数 · 運用支援

年度ごとの値上げ率の上限

終了時の移行 · 持ち出し費用

見積書の空欄 → 0円ではなく「未提示」 — 減点として扱う

1年分だけ比較すると3年目に順位が変わります

8. 終了条件 — 出口を先に見る

解約通知 → データ持ち出し → 移行支援

持ち出し形式 — ファイル形式 · スキーマ · 所要期間

顧客が制作したコンテンツの所有権

学習履歴の持ち出し範囲 · 個人情報の破棄手順

持ち出しサンプルを実際に開くところまでが検証です

RFPには入れるが、このページには書き直さないもの

以下の5つは、すでに別の文書に要求文と証跡まで整理されています。同じ内容を二重に書けば、いつか2つの文書が食い違います。
ここではどこを参照して何を持ってくるかだけを指定します。

AI要求事項

AI統制要求8種

データ学習からの除外 · 外部送信の遮断 · 呼び出し範囲の制限 · 入出力の検証 · 出典表示 · 監査ログ · 持ち出し · 削除の証跡 · 権限別の出力統制。項目ごとに受け取るべき証跡まで表になっています。セキュリティ要求の節にそのまま引用してください。

/ja/ai-lms#ailms-controls → AI RFPの手順

AI LMS RFP 作成8ステップ

このページの8ステップはLMS調達全般の軸(範囲 → インベントリ → 要求レベル → 証跡 → 検証 → 配点 → TCO → 終了)です。AIはデータ → 統制 → 検証という別の軸を持ちます。2つの手順は混ぜず、RFPの別章として分離してください。

/ja/ai-lms#ailms-rfp → 公共調達の実例

実際の提案依頼書は何を求めたか

韓国の公開提案依頼書の事例 — 内部保有資料約230GBと問題バンク718件の構造化、要求事項33件(機能 · 性能 · インターフェース · セキュリティ · テスト · 管理 · 支援)、技術80点 : 価格20点の配点。配点設計の参考事例です。

/ja/ai-lms → 相互運用標準

xAPI · LTI · Open Badges 3.0 · CLR 2.0

学習データがベンダー固有のフォーマットにしか蓄積されないと、プラットフォームを変えた瞬間に数年分の学習履歴が失われます。標準ごとに何をRFPで要求し、何を確認するかが表に整理されています。要求事項54~55番と60番に併せて入れてください。

/ja/lms-vs-lxp#lxp-standards → 運用データの要求

107社・35か月のMAU実測

非必須研修のMAU中央値は23%、第1四分位9%、第3四分位52%(n=75)。ベンダーにこの水準の運用データを求めてください — 導入社数ではなく、導入後に実際どれだけ使われたかの分布です。期待値を立てる基準線になります。

/ja/lms-benchmark → 規模の検証

選定基準8 — 運用規模の実績

「大企業に多数導入」は検証できる文ではありません。単一顧客あたりの最大学習者数(導入社数の合計ではなく)と、負荷テストの測定条件を求める方法が整理されています。要求事項56番の根拠です。

/ja/lms-selection#criterion-operating-scale →

分離の原則

AI要求事項を一般の機能要求の中に混ぜないでください。「AI機能があるか」を機能要求の1行で書くと、統制 · 証跡 · 費用構造がすべて抜けたまま「対応」という回答が返ってきます。AIはRFPの別章に置き、統制要求8種と証跡を該当文書からそのまま引用してください。

要求レベル3段階と回答ルール

評価尺度(◎ ○ △ ×)は候補を比較するときの目盛りで、要求レベル(必須 · 推奨 · 任意)は候補に要求するときの目盛りです。
同じ60項目ですが、向きが逆です。

要求レベル3段階

LMS RFPの要求レベル3段階 — 必須・推奨・任意の定義と審査での扱い
要求レベル	意味	項目数	未充足の場合	比較チェックリストの重要度
必須	なければ運用が成立しない — 提案者は必ず充足しなければならない	32項目	失格。減点ではなく失格と明記して初めて効力が生まれます	P1
推奨	運用品質と参加率を左右する — 充足の可否を配点に反映する	27項目	減点。未充足の理由と代替案を記述させます	P2
任意	あれば加点 — 選定判断の決定要因には使わない	1項目	加点のみ。この項目で順位をひっくり返しません	P3

要求レベルはLMS比較チェックリストの重要度(P1 · P2 · P3)と1対1で対応します。同じ60項目を調達視点で書き直したものなので、項目番号も同じです。

提案者の回答ルール — RFPの案内文にそのまま使える文

回答形式を指定しないと、提案書が記述式の自己PRで返ってきます。以下の4つの回答類型と、それぞれの必須添付をRFPの案内文に明記してください。

提案者の回答類型4種と、各類型に要求する添付文書
回答類型	提案者が意味していること	併せて要求する添付	発注者の扱い
充足	現行の製品機能だけで要求を満たす	証跡文書または画面。「充足」とだけ書かれ添付がない場合は未回答として扱うと案内文に明記	デモ · 文書で検証
条件付き充足	一部対応 — ポリシー · 別途設定 · 追加開発が前提	前提条件、追加費用、所要期間、責任の所在	必須項目であれば、公開した失格ルールを適用
未充足	現在は対応していない	代替案とロードマップ(時期 · 拘束力の有無)	必須項目であれば失格
該当なし	発注範囲上、適用されないと判断する	そう判断した根拠	発注者が判断 — 提案者が決めることではありません

回答欄

下の仕様表にベンダーの列はありません。候補社を優劣で並べる表ではないからです。配布するときは右側に回答類型 · 証跡文書名 · 検証日程 · 担当者の4列を足し、「検討中の候補」の列は空欄のまま各候補に記入させてください。CSVもその形で提供しています。

LMS RFP 要求仕様60項目

9カテゴリ · 60の要求事項の全文です。各行は要求レベル · 要求文 · 提出証跡 · 検証方法で構成され、提案依頼書の要求仕様としてそのまま転記できます。
検証方法のタグはデモ · 文書 · PoC · パイロット · 契約です。

A学習戦略 · 成果1~6 B学習者体験7~14 C管理者運用15~22 Dコンテンツ · 評価23~30 E参加 · LXP · AI31~38 Fデータ · 分析39~45 Gセキュリティ46~53 H連携 · 拡張性54~57 I構築 · 費用 · 契約58~60

表が画面より広い場合は左右にスクロールします。列の順序: 番号 · 要求レベル · 要求事項 · 提出証跡 · 検証方法

A. 学習戦略 · 成果適合性 (1~6)

教育の目的がシステムの構造に収まるか。必須3項目 — 法定研修の自動管理、職務別の学習経路、入れ替えなしの4週間パイロット検証。

A. 学習戦略・成果適合性 — LMS RFP 要求事項 1~6番
No.	要求レベル	要求事項	提出証跡	検証方法
1	必須	法定研修、倫理 · コンプライアンス、社内必須研修をコース単位で割り当て、修了可否を自動管理できること。	必須コースの設定画面、対象者一括割当の手順書、未修了者レポートのサンプル	デモコース登録 → 対象者割当 → 未修了者レポート出力までを止めずに実演
2	必須	職務 · 部署 · 役割別に研修コースを分類し、段階型の学習経路として運用できること。	学習経路の設定画面、部署別カリキュラムのサンプル構成案	デモ発注者が指定した部署1つのカリキュラムを即席で構成
3	推奨	従業員、新入社員、パートナー、キャンペーン運営人員など、学習者群を分離して運用できること。	グループ · 権限 · コース割当のマトリクス	デモ3つの学習者群のシナリオ
4	推奨	教育が修了確認にとどまらず、知識共有 · 事例共有 · 質疑応答まで拡張できること。	掲示板 · コメント · 添付 · 秘密投稿の機能仕様	デモトピック作成 → 権限設定 → 匿名 · 秘密投稿を実演
5	必須	既存LMSを入れ替えずに、4週間のパイロットで1区間だけ検証できること。	50~100名のパイロット定義書 — 範囲 · 期間 · KPI · 費用 · 終了条件	パイロット契約前に実測。パイロット費用を本契約に相殺するかまで明示
6	推奨	学習参加率、修了率、運用工数、問い合わせ減少などの成果指標を事前に合意し、測定できること。	KPIの算出定義書、パイロット前後のレポートサンプル	パイロットBefore / After レポートの対照

B. 学習者体験 · アクセシビリティ (7~14)

学習者が実際にログインするか。必須4項目 — マルチプラットフォームの進捗同期、ネイティブアプリ、プッシュ督促、Webアクセシビリティ。

B. 学習者体験・アクセシビリティ — LMS RFP 要求事項 7~14番
No.	要求レベル	要求事項	提出証跡	検証方法
7	必須	Web、iOS、Androidをすべて対応し、学習進捗を端末間で同期すること。	対応OS · ブラウザのバージョン表、進捗同期の設計書	デモPCで開始 → モバイルで続きを再生
8	必須	モバイルアプリがWebViewのラッピングではなく、プッシュ、オフライン保存、生体認証など端末機能を活用すること。	アプリのアーキテクチャ説明書(ネイティブとWebViewの区分を明記)、ストア登録情報	デモ実機でプッシュ受信 · オフライン再生を確認
9	推奨	顧客ブランドの独立アプリ、またはカスタマイズされた学習体験を提供できること。	ホワイトラベルの範囲表、ストア登録の方式と所要期間、追加費用	文書既存の独立アプリ事例のストアリンクを確認
10	必須	学習期限、新規コース、未修了の督促をアプリプッシュ · メッセージで送信できること。	対象者のセグメント基準、予約送信の設定画面、送信結果レポートの様式	デモ対象者別のプッシュ予約送信 → 受信 → 結果レポート
11	推奨	学習中の検索、ブックマーク、メモ、ハイライト、TTSなど自己主導の学習ツールを提供すること。	学習者画面の機能一覧	デモ学習者アカウントで直接操作
12	推奨	多言語UIとコンテンツ翻訳機能が、グローバル · パートナー教育に十分であること。	対応言語の一覧(UIとコンテンツ翻訳を区分)、翻訳品質のサンプル	デモ発注者が渡したコンテンツ1件を実際に翻訳
13	必須	Webアクセシビリティ基準(WCAG 2.2)を考慮した画面 · コンテンツ · モバイル操作性を検証できること。	アクセシビリティの自己点検表、キーボード · スクリーンリーダーの対応結果、公式証跡の有無	文書デモスクリーンリーダーで学習1件を完走
14	推奨	短時間で消費できるマイクロラーニング · ショート学習の体験を提供すること。	ショート制作の手順、コース転換率レポートの様式	デモ動画1件 → ショート → 転換統計

C. 管理者運用 · 業務効率 (15~22)

必須の比率が最も高いカテゴリです(8項目中6件)。運用工数は人数に比例して増えるため、残った手作業の1ステップが3年の総費用を決めます。

C. 管理者運用・業務効率 — LMS RFP 要求事項 15~22番
No.	要求レベル	要求事項	提出証跡	検証方法
15	必須	学習者を個別登録、CSV一括登録、招待リンク、SSO方式で登録できること。	登録方式ごとの手順書、CSVの様式とフィールド定義	デモ10名のCSVアップロード — エラー行の処理方式まで確認
16	必須	部署、職務、プロジェクト、パートナー単位のグループを作り、コース割当 · 統計 · メッセージの対象として再利用できること。	グループの設計書、グループ単位の統計項目一覧	デモグループ作成 → コース割当 → グループ統計の確認
17	必須	必須 · 選択コース、受講期間、進捗基準、試験 · アンケート条件をコース別に設定できること。	コース設定項目の全一覧	デモコースを1件登録した後、条件をその場で変更
18	必須	修了条件を自動判定し、修了証を発行できること。	修了条件の項目表(進捗率 · 学習時間 · 試験点数 · アンケート · 動画再生)、修了証の様式	デモ条件を満たすアカウントと満たさないアカウントを同時に判定
19	必須	管理者と副管理者のメニュー権限を分離し、運用責任を分けられること。	権限マトリクス(役割 × メニュー × 操作)	デモ副管理者アカウントでログインし、画面の差を確認
20	推奨	オフライン教育 · イベントのQR出席、手動認定、出席取消を管理できること。	出席管理画面の仕様、出席データが修了判定に反映される方式	デモQR出席 → 手動認定 → 取消まで実演
21	必須	リアルタイム接続者、最近の活動、受講ログ、一括処理の状態を管理画面で確認できること。	運用ダッシュボードの項目一覧、一括処理の待ちリスト画面	デモ運用ダッシュボードの実画面
22	推奨	管理者研修、コンテンツ移行、オープン支援、運用レビューの範囲と担当(R&R)を提示すること。	オンボーディング日程表、R&R、支援範囲の含む · 含まない一覧	契約支援範囲を契約の附属文書に編入

D. コンテンツ · オーサリング · 評価 (23~30)

「制作機能があるか」は要求事項になりません。担当者1名が1件を作るのにかかる時間を検証方法として固定します。30番は契約条項で確認します。

D. コンテンツ・オーサリング・評価 — LMS RFP 要求事項 23~30番
No.	要求レベル	要求事項	提出証跡	検証方法
23	必須	コーディングなしでテキスト、画像、動画、音声、PDF、クイズ、試験、アンケートを組み合わせてコンテンツを制作できること。	対応するコンテンツ要素の一覧、エディタの操作マニュアル	デモ発注者が渡したPDF · PPT 1件で即席制作 — 所要時間を測定
24	推奨	Desktop、Tablet、Mobileの画面をプレビューし、レスポンシブに調整できること。	プレビューの基準解像度	デモ3つの解像度でプレビュー
25	推奨	動画、音声、PDF、外部動画の埋め込み、内部リンクなど多様な資料形式を運用できること。	対応ファイル形式 · 容量制限の表、ストリーミング方式	デモアップロードとリンク埋め込みのテスト
26	必須	クイズ · 試験 · アンケートを作成し、自動採点、結果公開の方式、管理者採点を設定できること。	問題タイプの一覧、採点 · 結果公開ポリシーの設定画面、不正対策	デモクイズ1件 · 試験1件を実際に作成して受験
27	推奨	AIで文書 · URLをもとにコンテンツの下書き、画像、翻訳、要約を生成できること。AI統制の証跡を併せて提出すること。	AI機能の仕様 + AI統制要求8種の証跡	デモ文書機能の実演と統制文書を同時に要求
28	推奨	長尺動画をショート学習に変換し、元のコースへ誘導できること。	変換の手順、転換率の算出定義	デモ動画1件を変換した後、転換統計を確認
29	推奨	自社コンテンツ以外に、eラーニング · ショートのコンテンツライブラリを選べること。	コンテンツカタログ、購読単価と更新条件	文書カタログの実物と単価表を照合
30	必須	顧客が制作したコンテンツの所有権と終了後の持ち出し形式を契約で保証すること。	契約条項の草案、実際の持ち出しファイルのサンプル(HTML等)	契約デモ持ち出しファイルをダウンロードして実際に開く

E. 参加 · LXP · AIパーソナライズ (31~38)

このカテゴリに必須が1件もないのは意図した設計です。必須研修 · 修了 · 権限 · セキュリティが埋まる前に参加機能を必須にすると、RFPが新技術ありきの文書になります。35番はタッチクラスが条件付きで回答する項目です。

E. 参加・LXP・AIパーソナライズ — LMS RFP 要求事項 31~38番
No.	要求レベル	要求事項	提出証跡	検証方法
31	推奨	掲示板、コメント、いいね、スクラップ、秘密投稿、匿名トピックなどソーシャルラーニングを運用できること。	トピック権限の設計、匿名 · 秘密投稿のポリシー、通報 · ブロックの手段	デモ匿名トピックの開設 → 秘密投稿 → 統計
32	推奨	ポイント、バッジ、フレーム、ランキングで自発的な参加を設計できること。	ポイント付与条件の一覧、ランキングの算出方式	デモキャンペーンを1件その場で構成
33	推奨	プラットフォーム内でライブ教育、チャット、出席、見逃し配信、参加者名簿の持ち出しを処理できること。	ライブの最大時間 · 同時視聴の上限、参加者名簿の持ち出し様式	デモライブ配信のテスト後に名簿をダウンロード
34	推奨	アンケート、イベント、VOC、現場事例の共有など、教育以外の参加型運用に対応すること。	キャンペーン型トピックとアンケートの構成事例	文書運用事例の一覧を確認
35	推奨	職務 · 力量 · スキルグラフを基準に、キャリアパスと学習推薦を精緻に連結できること。タッチクラス条件付き	役割-スキルのマッピング構造、HRISデータ連携の設計、追加開発の範囲と費用	文書PoC既存構築事例のスキル体系の原本を要求
36	推奨	人気検索語、行動履歴、関心キーワードに基づくパーソナライズ推薦を提供すること。	推薦の根拠を説明する文書 — 何を見て何を推薦するのか	デモ推薦結果に推薦理由を説明させる
37	推奨	コース別FAQと学習資料に基づく質疑応答のAIアシスタントを運用できること。	出典表示の画面、利用統計、AI統制の証跡を併せて	デモ発注者のPDFを連結して質問 — 出典が表示されるか確認
38	任意	モバイルホーム、推薦コース、人気コース、ランキング、保管箱を組み合わせて学習者ホームを構成できること。	ホーム構成項目の一覧	デモ学習者ホームの構成画面

F. データ · 分析 · 成果測定 (39~45)

「統計画面があるか」ではなく、監査と報告にそのまま使える形でダウンロードできるかを要求します。43番はタッチクラスが条件付きで回答する項目です。

F. データ・分析・成果測定 — LMS RFP 要求事項 39~45番
No.	要求レベル	要求事項	提出証跡	検証方法
39	必須	接続、コース、コンテンツ、意見、ショート、チャットボット、グループ比較の統計を提供すること。	統計メニュー別の項目表、ダウンロード形式、集計周期	デモ統計メニューを全数確認
40	必須	未接続者、未修了者、会員別のレポートをダウンロードし、監査 · 報告資料として使用できること。	CSVのサンプルファイル実物、個人情報のマスキングポリシー	デモ実際のダウンロードファイルを開いて列構成を確認
41	推奨	部署 · グループ間で学習量、活動量、参加度を比較できること。	グループ比較レポートのサンプル(2~10グループ)	デモグループ比較レポートの出力
42	推奨	ショート学習が実際のコース学習につながったか、転換指標を提供すること。	転換率の算出定義(分母 · 分子 · 集計期間)	文書算出定義を文書で要求
43	必須	AI推薦 · 分析の結果が、昇進 · 評価 · 報酬といった高リスクのHR判断と分離して管理されること。タッチクラス条件付き	データ利用ポリシー、人間によるレビュー手順、監査ログの設計	文書契約学習データの利用範囲を契約に明記
44	推奨	パイロット前後で参加率、制作時間、問い合わせ減少、運用工数削減のKPIを比較できること。	Before / After レポートの様式	パイロット4週間のパイロット前後で対照
45	推奨	管理者の自然言語クエリ、またはレポート自動化により、運用分析の時間を削減できること。	クエリ可能なデータの範囲、回答の根拠の表示方式	デモ発注者が作った質問3件をその場でクエリ

G. セキュリティ · 個人情報 · コンプライアンス (46~53)

8項目がすべて必須です。LMSには従業員の個人情報と社内の教育資料が同じ場所に蓄積されるため、個人情報の委託という観点から委託先そのものが審査対象になります。53番はタッチクラスが条件付きで回答する項目です。

G. セキュリティ・個人情報・コンプライアンス — LMS RFP 要求事項 46~53番
No.	要求レベル	要求事項	提出証跡	検証方法
46	必須	情報保護 · 個人情報保護の管理体系認証と、国際情報セキュリティ認証を提示すること。	認証書の原本、認証範囲、有効期限、直近の事後審査の履歴	文書認証機関のサイトで発注者が直接照会 — 提出された写しだけを信用しない
47	必須	大企業 · 金融機関の委託先セキュリティ監査を通過した実績と、個人情報の最小収集、委託処理、損害賠償責任保険の根拠を提出すること。	監査の実施機関 · 年度 · 点数(または合否)を記載した文書、セキュリティ質問票の回答、保険証券	文書提出文書と個人情報の委託契約書を照合
48	必須	保存 · 転送区間の暗号化、データの保管場所、アクセス統制の原則を説明すること。	セキュリティアーキテクチャの説明書、保管リージョンの明示、暗号化方式	文書アーキテクチャ文書のレビュー
49	必須	管理者 · 副管理者 · 学習者の権限を分離し、最小権限の原則で運用できること。	権限マトリクス、管理者の活動ログのポリシー	デモ権限別のアカウント3種で画面の差を確認
50	必須	SSO、SAML 2.0、OAuth 2.0、LDAP/AD、MFAまたは生体認証の連携に対応すること。	連携ドキュメント、同一プロトコルでの構築レファレンス	PoC発注者のIdPと実際に連携試験 — 文書だけでは認めない
51	必須	管理者の活動ログ、接続IP、メニュー活動、キャプチャログなど、監査追跡が可能であること。	ログ項目の表、保管期間、照会権限と持ち出し方式	デモ特定の管理者の過去の活動をその場で照会
52	必須	無停止運用の期間、障害履歴、バックアップ · 高可用性の対応手順を文書で提出すること。	連続運用の期間、直近3年の障害履歴(発生日 · 影響範囲 · 復旧時間)、SLA、障害対応手順	文書「障害0件」という回答には測定方式と集計範囲を要求
53	必須	キャプチャ防止、ウォーターマーク、ダウンロード統制など、コンテンツ漏洩防止の手段を提示すること。タッチクラス条件付き	OS別の対応範囲表(iOSとAndroidを区分)、キャプチャログ · マスキングのポリシー	デモ実機でキャプチャを試行。「完全遮断」の主張にはOSポリシー上の根拠を要求

参照基準: https://isms-p.or.kr/sysm/intro/selectSysmCertDetail.do · https://www.iso.org/standard/27001 · https://www.nist.gov/itl/applied-cybersecurity/special-publication-800-63 · https://www.w3.org/TR/WCAG22/

H. 連携 · 拡張性 · 相互運用 (54~57)

相互運用標準(xAPI · LTI · Open Badges 3.0 · CLR 2.0)の要求文は別の文書に表としてあります。54~55番に併せて入れてください。

H. 連携・拡張性・相互運用 — LMS RFP 要求事項 54~57番
No.	要求レベル	要求事項	提出証跡	検証方法
54	必須	HRIS、ERP、CRM、グループウェア、ポータルとアカウント · 組織 · 学習データを連携できること。	連携対象システムの一覧、データ項目のマッピング表、同期の周期と失敗時の処理	文書PoC発注者のシステム1件と実際にマッピングを設計
55	推奨	API、Webhook、CSVなど段階別の連携方式を選択でき、費用 · 日程を分離して算定すること。学習データの標準形式への対応可否も明らかにすること。	APIドキュメント、連携見積(工数 · 期間を分離)、xAPI · LTI等の標準対応範囲	文書APIドキュメントの実物と見積項目を照合
56	必須	数千~数万名規模の実際の運用実績と、最大同時接続の負荷テスト結果を文書で提出すること。	単一顧客あたりの最大学習者数(導入社数の合計ではない)、負荷テストの結果値とテスト条件(ツール · シナリオ · 測定時点)	文書下のベンダー証跡5種の要求文をそのまま使用
57	推奨	独立ドメイン、ホワイトラベル、顧客専用のブランド体験を拡張できること。	ドメイン · アプリのブランディング範囲と追加費用	文書既存の構築事例を確認

I. 構築 · 支援 · 費用 · 契約 (58~60)

3項目すべてが必須です。見積書で空欄になっている項目は、後から請求される項目です。

I. 構築・支援・費用・契約 — LMS RFP 要求事項 58~60番
No.	要求レベル	要求事項	提出証跡	検証方法
58	必須	サイト設定、コンテンツ移行、管理者研修、パイロット運用までの導入支援の範囲とR&Rを提示すること。	オンボーディング日程表、R&R、含む · 含まないの一覧	契約支援範囲を契約の附属文書に編入
59	必須	ライセンス、ユーザー課金、コンテンツ購読、連携、運用支援を含む3年の総所有コスト(TCO)を同一の様式で提出すること。	3年間の費用表、1人あたりの増分単価、最低契約金額、年度ごとの値上げ率の上限、終了時の移行費用	文書空欄は0円ではなく「未提示」として扱う — 減点
60	必須	契約終了、データの持ち出し、コンテンツの所有権、解約通知の条件を明示すること。	契約書の草案、終了プロセス、持ち出しのサンプルファイル、移行支援期間、個人情報の破棄手順	契約デモ持ち出しサンプルをダウンロードして実際に開く

候補の列

「検討中の候補」の列は空欄にしてあります。誰を候補にするかは発注組織が決めることであり、この文書が決めることではないからです。表を複製して候補の数だけ列を足し、各候補に回答類型 · 証跡文書名 · 検証日程を直接記入させてください。

ベンダーに求める証跡5種

以下の5つは言葉では答えられない項目です。要求文をそのままRFPに転記してください。
右端の列には、タッチクラスが提出する値を出典リンクとともにそのまま記載しました — 同じ形式で候補全社に求めてください。

LMS RFPでベンダーに求める主要な証跡5種と、タッチクラスが提出する値
証跡	RFPに書く要求文	なぜこの形式でなければならないか	タッチクラスが提出する値
1. 負荷テストの結果文書	「最大同時接続の負荷テストの結果値とテスト条件(ツール · シナリオ · 測定時点 · インフラ構成)を文書で提出すること。」	数値だけを受け取っても、どの条件で出た値かが分かりません。負荷テストの値は保証された常時収容量ではありません — この区別を要求文に入れておけば、契約後に揉めることがありません。	同時接続 18,000名の負荷テスト値(保証された常時収容量ではない) 出典: https://www.touchclass.com/ja/lms-benchmark#operating-scale
2. 単一顧客あたりの最大学習者数	「単一顧客あたりの最大学習者数を提出すること。導入顧客数の合計は認めない。」	「大企業に多数導入」は検証できる文ではありません。100社 × 300名と、1社 × 30,000名は運用の難易度がまったく違います。発注規模と比較できる値は単一顧客あたりの最大値だけです。	単一顧客あたり最大 39,000名 · 金融17機関・累計約135,800名出典: https://www.touchclass.com/ja/lms-benchmark#operating-scale
3. 無停止運用の期間 · 障害履歴	「連続運用の期間と直近3年の障害履歴(発生日 · 影響範囲 · 復旧時間)、SLAと障害対応手順を文書で提出すること。」	「障害0件」という回答が来たら、測定方式と集計範囲を聞き返す必要があります。障害を記録していないことと、障害がないことは違います。履歴のあるベンダーのほうが、むしろ対応手順を持っています。	AWS基盤 · 金融分野で5年間の無停止運用。SLAと障害履歴の文書は契約段階で提供出典: https://www.touchclass.com/ja/lms-benchmark#operating-scale
4. 委託先セキュリティ監査の通過実績	「大企業 · 金融機関の委託先セキュリティ監査の実施機関 · 年度 · 点数(または合否)を文書で提出し、セキュリティ質問票の回答と証跡資料を添付すること。」	認証の保有と顧客側の実地監査の通過は別の事柄です。金融機関の委託先監査は認証より項目が細かく、通過実績があるということは、すでに一度分解されたということです。	委託先セキュリティ監査 99.1点(2023年) · 個人情報の最小収集 · 損害賠償責任保険出典: https://www.touchclass.com/ja/lms-benchmark#operating-scale
5. 認証機関での直接確認	「セキュリティ認証の認証書の原本 · 認証範囲 · 有効期限 · 事後審査の履歴を提出すること。発注者は認証機関のサイトで直接照会し、照合する。」	提出されたPDFだけでは、認証範囲がサービス全体なのか一部なのかが分かりません。範囲が狭く取られた認証は、自社のデータがその範囲に含まれることを保証しません。照会は発注者が自ら行います。	ISMS-P · ISO/IEC 27001 を保有。照会先: https://isms-p.or.kr · https://www.iso.org/standard/27001 詳細: https://www.touchclass.com/ja/security

運用データも併せて求めてください。3年後の結果を分けるのは、導入実績(何社が買ったか)ではなく導入後の実使用率(どれだけ使われたか)です。韓国107社・35か月のログでは、非必須研修のMAU中央値は23%、第1四分位9%、第3四分位52%でした(n=75)。この水準の分布をベンダーが提出できるか聞いてみてください — 原典はhttps://www.touchclass.com/ja/lms-benchmarkにフォームなしで公開しています。

タッチクラスが条件付きで回答する3項目

60の要求事項のうち、タッチクラスが「充足」と答えない項目が3件あります。消さずにそのまま掲載します。
RFPを受け取る側から見れば、条件付き回答が1件もない提案書のほうが、確認すべき回答です。

要求事項35 · 推奨

職務-力量スキルグラフに基づくキャリアパス連結

関心キーワードに基づくキュレーションと推薦には対応します。しかし職務-力量を構造化したスキルグラフは別途設計が必要です。製品に内蔵された既製のスキル体系では回答しません。

候補全社に同じことを聞いてください。スキル体系は製品に内蔵されているのか、顧客が自ら作るのか。内蔵であれば、その体系の出典と更新周期を求めてください。

要求事項43 · 必須

AI分析結果と高リスクHR判断の分離

AI推薦 · 分析の機能はあります。しかしその結果を昇進 · 評価 · 報酬と分離することは、製品機能だけでは完結しません。顧客側のデータ利用ポリシー · 承認手順 · 監査体制が揃って初めて成立します。

製品機能で答えるベンダーには注意してください。この項目の正しい回答は機能一覧ではなく、データの利用範囲を契約に明記するという一文です。

要求事項53 · 必須

キャプチャ防止 — iOSのOS制約

キャプチャログとマスキングには対応します。しかしiOSではOSの特性上、完全遮断とは主張しません。これは特定の製品の限界ではなく、プラットフォームのポリシーによる結果です。

「完全遮断」という回答が来たら根拠を求めてください。OS別の対応範囲表(iOSとAndroidを区分)を提出させ、実機で自らキャプチャを試してください。

この3項目は、LMS比較チェックリストで△(一部対応)と判定した項目と同一です。2つの文書の判定は常に同じ値を指します — 比較表では△、RFPでは「条件付き充足」と、表現が変わるだけです。

要求事項60項目のダウンロード

フォームの提出も、ログインも、メールアドレスの入力も不要です。60項目の全文をCSVで公開します。
「現行LMS」の列は空欄のまま提供されるので、候補の数だけ列を増やしてそのまま配布できます。

LMS要求事項60項目 (CSV · 日本語)

番号 · カテゴリ · 重要度(P1~P3 = 必須 · 推奨 · 任意) · 項目 · 確認方法 · 主管部署 · 現行LMS(空欄) · タッチクラスの判定 · 確認メモ。
LMS比較チェックリストと同じファイルです — 2つの文書は同じ60項目を別の視点で使います。

CSVをダウンロード

CSVの重要度の列(P1 · P2 · P3)は、このページの要求レベル(必須 · 推奨 · 任意)と1対1で対応します。ファイルを2つ作らないのは、同じデータが2つのファイルに分かれると、いつか互いに食い違うからです。

この文書とLMS比較チェックリストは何が違うのか

2つの文書は同じ60項目を使います。しかし使う段階が違い、表の向きが逆です。
今どの段階にいるかによって、読むべき文書が変わります。

LMS RFP文書とLMS比較チェックリストの違い — 目的・使用段階・表の向き
区分	このページ — LMS RFP	LMS比較チェックリスト
目的	候補に要求する — 要求仕様	候補を評価する — 比較表
使う段階	提案依頼書の発送前 — 調達 · 購買のプロセス	提案書の受領後 · デモの実施中 — 審査
目盛り	要求レベル — 必須推奨任意	評価尺度 — ◎3 / ○2 / △1 / ×0
表の列	要求事項 · 提出証跡 · 検証方法	チェック項目 · 確認方法 · 主管部署 · 現行LMS · 判定
判断ルール	必須項目の未充足 → 失格	合計点ではなくP1項目の空白を見る
成果物	提案依頼書の要求仕様 · 評価配点表	候補別の比較表 · 導入前の確認課題リスト
読むべき文書	今このページ	https://www.touchclass.com/ja/lms-comparison-checklist

2つの文書が項目番号を共有しているのは意図した設計です。RFP要求事項43番への候補の回答は、比較チェックリストの43番のマスにそのまま書き写せます。

よくあるご質問

LMSの提案依頼書を書くときに、実際に最も多く受ける8つの質問です。

LMSのRFPはどう書きますか?

調達範囲を一文で確定し、現行のインベントリを添付したうえで、要求事項を必須 · 推奨 · 任意に分けます。次に要求事項ごとに提出証跡を文書名まで指定し、検証方法(デモ · 文書 · PoC · パイロット · 契約)を発注者が先に固定します。最後に評価配点と失格ルールをRFPに公開し、費用は3年TCOの様式で受け取り、契約終了条件を提案段階で要求します。この8ステップを守れば、3社の提案書が同じ軸で比較できます。

要求レベル(必須 · 推奨 · 任意)はどう分けますか?

必須は、なければ運用が成立しない項目で、未充足なら失格と明記して初めて効力が生まれます。60項目中32件で、法定研修の自動管理、修了条件の自動判定、権限分離、セキュリティ8項目すべて、3年TCO、契約終了条件が含まれます。推奨は配点に反映する27項目、任意は加点1項目です。参加 · LXP · AIのカテゴリに必須が1件もないのは意図した設計です — 法定研修とセキュリティが埋まる前にAIを必須にすると、RFPが新技術ありきの文書になります。

「対応しています」という回答をどう防ぎますか?

要求事項ごとに何を提出すれば対応と認めるのかを発注者が先に書くしかありません。認証書の原本と認証範囲、負荷テストの結果値とテスト条件、直近3年の障害履歴、持ち出しファイルの実物のように文書名で書きます。そしてRFPの案内文に、「充足」とだけ書かれ添付がない場合は未回答として扱うと明記してください。証跡のない要求事項は、要求事項ではなく希望です。

ベンダーの運用規模はどう検証しますか?

「大企業に多数導入」は検証できる文ではありません。単一顧客あたりの最大学習者数を求め、導入顧客数の合計は認めないとRFPに書きます。負荷テストは数値だけでなくテスト条件(ツール · シナリオ · 測定時点 · インフラ構成)も併せて受け取り、その値が保証された常時収容量ではないことを要求文に明記します。タッチクラスは単一顧客あたり最大39,000名、同時接続18,000名の負荷テスト値(保証された常時収容量ではない)を公開文書として提出します。

AI要求事項はこのRFPにどう入れますか?

一般の機能要求の中に混ぜず、別章として分離してください。「AI機能があるか」を1行で書くと、統制 · 証跡 · 費用構造がすべて抜けたまま「対応」という回答が返ってきます。AIはデータ → 統制 → 検証という別の軸を持ちます。公開提案依頼書で繰り返し確認されるAI統制要求8種(データ学習からの除外 · 外部送信の遮断 · 呼び出し範囲の制限 · 入出力の検証 · 出典表示 · 監査ログ · 持ち出し · 削除の証跡 · 権限別の出力統制)とAI RFP作成8ステップをそのまま引用してください。

学習データの持ち出しと標準はRFPのどこに書きますか?

連携の要求(54~55番)と契約終了の要求(60番)の両方に書きます。学習データがベンダー固有のフォーマットにしか蓄積されないと、プラットフォームを変えた瞬間に数年分の学習履歴が失われます。持ち出しの形式 · スキーマ · 所要期間を契約項目として扱い、相互運用標準(xAPI · LTI · Open Badges 3.0 · CLR 2.0)への対応範囲も明らかにさせてください。標準ごとの要求文と確認事項は該当文書に表としてあります。

タッチクラスはこの60項目をすべて充足しますか?

いいえ。3項目に条件付きで回答します。35番のスキルグラフは、関心キーワードのキュレーションには対応しますが、職務-力量のスキルグラフは別途設計が必要です。43番のAI高リスクHR判断の分離は、AI機能はありますが、昇進 · 評価 · 報酬との分離には顧客側のポリシー · 承認 · 監査体制が揃う必要があります。53番のキャプチャ防止は、キャプチャログとマスキングには対応しますが、iOSはOSの特性上、完全遮断とは主張しません。そのまま公開しています — 条件付き回答が1件もない提案書のほうが、むしろ確認すべき回答です。

このページとLMS比較チェックリストは何が違いますか?

同じ60項目を使いますが、表の向きが逆です。このページは候補に要求する仕様(要求レベル · 提出証跡 · 検証方法)であり、LMS比較チェックリストは候補を評価する比較表(確認方法 · 主管部署 · 判定尺度)です。提案依頼書を出す前ならこのページを、提案書を受け取って審査している最中ならチェックリストをご覧ください。項目番号が同じなので、RFPの回答を比較表のマスにそのまま書き写せます。

次のステップ

調達 · 比較 · 診断はそれぞれ別の段階です。現在の段階に合った文書へお進みください。

提案書の受領後

受け取った提案書を比較表に移す

同じ60項目を評価尺度(◎ ○ △ ×)で埋める比較表。判定ルールは合計点ではなくP1項目の空白です。

RFP作成前

何を要求するかを先に決める

セキュリティ · 実使用率 · コンテンツ制作 · 法定研修の自動化 · 拡張性 · TCO · 連携 · 運用規模の8つの選定基準。

期待値の設定

ベンダーに求めるデータの基準線

107社・35か月の運用ログ。非必須研修のMAU中央値23%(n=75)。この水準の分布を候補に求めてください。