Contents
導入（目的と本文の範囲）
Classi 学校 ポータル 機能 比較を実務視点でまとめます。
Classi 学校 ポータル 機能 比較では、保護者連携、認証、SIS連携、端末対応、データ保護、コストに重点を置きます。
導入検討で即使える確認項目と、RFPやKPI設計の実務テンプレートを提示します。
Classiの公式情報と導入実績の扱い方
Classiの機能や導入実績は製品ページや導入事例で公開されています。ここでは公式情報の確認方法と、公開数値を扱う際の注意を示します。
Classiの概要（公式に確認すべき要点）
Classiは中学校／高等学校向けの学習支援・学校運営支援プラットフォームです。
学校向けの出欠、課題、教材配信、学習ログ可視化、保護者連携機能が中心に提供されます。
機能の有無や仕様、追加モジュールの一覧は必ずベンダーの製品仕様書で確認してください。
公式資料と確認手順（どの資料を、どう確認するか）
公式の製品ページ、導入事例ページ、SLA／セキュリティ資料（PDF）、DPA（データ処理契約）案を入手してください。
確認手順の例は次のとおりです。
- 製品一覧で「出欠」「課題」「成績」「保護者向け機能」の記載を照合する。
- 導入事例で同規模の学校数・効果指標（提出率や工数削減）を確認する。
- セキュリティ資料で暗号化方式、データ保存場所、認証方式（SAML等）を検証する。
導入実績の取り扱い（数値の検証方法）
ベンダーの「導入校数」「利用者数」「成功事例の数値」は説明の根拠として提示を求めてください。
検証方法は次のとおりです。
- 導入事例のPDFまたは事例ページの日付・対象校規模を確認する。
- 可能なら事例校の担当者に直接ヒアリングする許可を求める。
- 公表数値に地域偏りや「教育委員会単位」「学校単位」の差がないか把握する。
未確認の数値は「要確認」と明示して比較表に記載してください。
機能別チェックポイントと比較テンプレート
主要機能ごとに、機能概要、実務的な利点、運用上の注意点、比較時のチェック項目を整理します。比較表テンプレートも掲載します。
出欠管理
出欠管理は日常業務への影響が大きい機能です。運用ルールを明確にする必要があります。
- 機能概要：授業単位・時間割単位での出欠入力・集計。
- 実務利点：事務作業削減と保護者への通知が自動化される点。
- 運用上の注意：SISとの学籍同期ルール、遡及修正権限の管理、エラー時の復旧手順。
- 比較チェック：同期頻度、手入力負荷（教員画面の操作数）、保護者通知の設定可否。
宿題・課題配信（提出・採点）
課題機能は評価運用と連動するため設計が重要です。出題→提出→評価の流れを想定してください。
- 機能概要：課題作成、提出受領、ファイル添付、採点、フィードバック。
- 実務利点：提出状況の可視化と履歴保持。
- 運用上の注意：成績との連携ルール、ファイルサイズ制限、締切延長の運用。
- 比較チェック：API/LTI経由でのデータ連携、採点書き戻し可否、動画課題の扱い。
教材配信・ライブラリ管理
教材の管理は授業準備と再利用性に直結します。権限設計が重要です。
- 機能概要：教材ファイル、外部リンク、フォルダ管理、検索・タグ付け。
- 実務利点：教材の標準化と共有。
- 運用上の注意：著作権管理、外部ストレージ連携、バージョン管理ルール。
- 比較チェック：Drive/OneDrive連携、ストレージ容量、フォルダ一括配布。
成績管理
成績管理はSISとの一次管理設計によって運用が変わります。整合ルールを決めてください。
- 機能概要：成績入力、評価体系、CSVエクスポート、SIS連携。
- 実務利点：履歴保存とレポート作成。
- 運用上の注意：どちらを一次管理とするか、計算式の差異、公開ルール。
- 比較チェック：書き戻し可否、複数評価尺度の対応、CSVフォーマット互換性。
メッセージ・掲示板
コミュニケーション機能は運用ルールの整備が鍵です。ログ保存ポリシーを定めてください。
- 機能概要：個別メッセージ、クラス掲示板、配信通知。
- 実務利点：連絡の一元化と履歴管理。
- 運用上の注意：双方向の可否、ログ保持期間、既読管理。
- 比較チェック：メッセージのエクスポート、保護者との双方向可否。
カレンダー連携
行事や試験の管理は外部カレンダー連携で利便性が上がります。
- 機能概要：授業・試験・行事の表示、iCal/Google Calendar等との連携。
- 実務利点：学校行事と個人スケジュールの一元化。
- 運用上の注意：双方向同期の可否と権限設定。
- 比較チェック：iCal/Google/Outlook連携、同期方向。
ファイル共有（容量・権限）
ストレージ制限と権限設計はコストと運用負荷に直結します。
- 機能概要：教材・提出物の保存とアクセス制御。
- 実務利点：教材の一元管理。
- 運用上の注意：保存期間、ウイルススキャン、追加購入の条件。
- 比較チェック：初期容量、追加オプション、外部ストレージ連携。
学習ログ・分析
学習ログは早期介入や指導改善に使えます。収集項目と匿名化を設計してください。
- 機能概要：ログイン頻度、閲覧履歴、学習時間、提出率等の集計。
- 実務利点：支援が必要な生徒の早期発見。
- 運用上の注意：個人識別情報の取り扱いと保存期間、ダッシュボードのカスタマイズ性。
- 比較チェック：ログ粒度、保存期間、エクスポート可否。
比較表テンプレート（検証区分を必ず入れる）
比較時は検証済み／未検証を明示してください。Classiの項目は公式確認を前提に評価します。
| 機能 | Classi（要公式確認） | Google Classroom / GWS | Microsoft Teams for Education | Moodle（OSS） | 運用負荷 |
|---|---|---|---|---|---|
| 出欠管理 | 要仕様確認 | Google環境で簡易実装可 | 学校設定で拡張可 | プラグインで対応 | 中〜高 |
| 課題配信 | 要仕様確認 | 標準機能あり | Assignmentsで対応 | 高カスタマイズ可 | 中 |
| 教材配信 | 要仕様確認 | Drive連携強み | OneDrive連携強み | 自由度高 | 低〜中 |
| 成績管理 | 要仕様確認 | CSV等で運用 | 学校次第で連携可 | プラグイン依存 | 中 |
| 保護者連携 | 要確認 | 限定的 | 学校連携で対応可 | プラグインで対応 | 中 |
| 学習ログ分析 | 要仕様確認 | 限定的 | 限定的 | 構築次第で高機能 | 高 |
上表ではClassiの個別仕様を「要公式確認」としています。比較時は必ず製品仕様書・DPA・導入事例で裏取りしてください。
認証・端末対応・外部連携の運用設計
認証方式や端末差分は運用負荷に直結します。SSOやプロビジョニングの要件を事前に確定してください。
SSOとプロビジョニング（管理者の事前設定）
SSOや自動プロビジョニングの可否は導入難易度を左右します。事前に技術要件を揃えてください。
- 確認項目：SAML／OIDC（OpenID Connect）対応の有無。
- プロビジョニング：SCIMによる自動ユーザー作成の可否。
- 管理準備：ドメイン検証、証明書交換、APIキーの管理、テストアカウント準備。
- セキュリティ：管理者には多要素認証（MFA）を必須化することを推奨します。
対応端末・ブラウザとネイティブアプリの差分
端末による機能差はユーザー体験に直結します。教職員・保護者の利用端末を把握してください。
- 確認事項：推奨ブラウザとOSバージョン、iPadでのフル機能利用可否。
- ネイティブの利点：プッシュ通知、カメラ連携、オフライン機能。
- 共有端末運用：MDMによる端末管理と端末単位認証の要否。
用語集（主要略語の短い説明）
主要な技術用語を簡潔に定義します。非技術担当者向けの理解確認に使ってください。
- SAML：認証連携のための標準プロトコルの一つ。
- OIDC：OAuth2を基盤としたWeb認証の仕様。
- SCIM：ユーザー情報の自動同期仕様（プロビジョニング）。
- LTI：学習ツール間の連携仕様（課題や成績交換）。
- SIS：学籍管理システムの総称。
- GWS：Google Workspaceの略称。
- DPA：データ処理契約（Data Processing Agreement）を指す。
データ保護・法令準拠・契約条項
個人情報の取り扱いは導入可否に直結します。国内法令と契約で押さえるべきポイントを示します。
データ保存場所・暗号化・鍵管理
データの所在と暗号化方式は必須確認事項です。契約で明確化してください。
- 確認項目：国内保存か海外クラウドか、リージョン指定の可否。
- 通信・保存の暗号化：TLS、保存時暗号化（at-rest）方式の確認。
- 鍵管理：ベンダー管理か校側管理かの区分。鍵管理責任を明記すること。
同意文言と保存期間の例（実務例）
保護者同意や利用規約で使える短い文言例と保存期間の参考値を示します。法務と合意して調整してください。
- 同意文言（例）：「当校は学習支援のためにClassi等のサービスを利用し、必要な個人情報を提供します。詳細はプライバシーポリシーを参照してください。」
- 保存期間の例：学籍情報＝在学期間＋卒業後5年、成績データ＝在学期間＋5年、学習ログ＝1〜3年（運用要件により長短を決定）。
これらは例示です。法務と教育委員会の指導に従って確定してください。
契約条項で押さえるべき項目（DPA等）
契約では以下を必ず明確にしてください。監査や通知義務は重要です。
- データ処理の目的と範囲。
- サブプロセッサーの一覧と変更通知のルール。
- データ削除・返却の手順と期限。
- 監査権（第三者監査レポートの提出要求）。
- インシデント通知の期限（報告窓口とタイムライン）。
- RTO（復旧時間目標）/RPO（復旧ポイント目標）の定義とSLAs。
- 管轄裁判所・適用法の明確化。
法令・ガイドラインの要点
国内では個人情報保護法が基盤です。教育分野の公的ガイドラインも確認してください。
- 個人情報保護法：取扱いの基本原則と第三者提供の制限。
- 教育分野の指針：文部科学省や地方自治体の運用指針の存在を確認する。
- 国際処理：海外へのデータ転送がある場合は追加の法的対応が必要です。
RFP・KPI設計・導入手順（次のアクション）
導入判断に直結するRFPの主要項目と、測定可能なKPIの定義・計測方法を提示します。デモ申込の実務手順も示します。
RFPに必須の主要項目（チェックリスト）
RFPには次の項目を必ず含めてください。受け入れ基準を明確化します。
- 機能要件：出欠、課題、成績、保護者連携の詳細要件。
- 非機能要件：可用性、レスポンス、スケーラビリティ。
- セキュリティ要件：データ保存場所、暗号化、認証方式。
- 統合要件：SIS、Google/Microsoft、LTI、APIの仕様。
- サポート要件：対応時間、オンサイト研修、エスカレーション。
- 契約条件：SLA、DPA、監査権、RTO/RPO。
- 価格体系：ライセンス形態、導入費、保守費、追加ストレージ費。
KPIの定義と計測式（測定方法・期間・目標例）
KPIは測定方法と期間を明確にしてください。以下は実務で使える例です。
- 課題提出率
- 計測式：提出数 ÷ 対象者数 × 100%。
- 測定期間：パイロット期間（4〜8週間）。
- 目標例：パイロットで提出率が現行より10〜20ポイント改善。
- 出欠処理時間（教職員）
- 計測式：1授業あたりの出欠入力平均時間（秒）。
- 測定方法：システムの操作ログまたはタイムスタンプで計測。
- 目標例：平均処理時間を30%短縮。
- 保護者既読率（通知）
- 計測式：既読数 ÷ 配信数 × 100%。
- 測定期間：1ヶ月〜3ヶ月。
- 目標例：既読率50%以上（初期目標、学校により調整）。
- 学習ログ活用件数（早期介入）
- 計測式：ログ検知→支援開始の件数。
- 測定期間：学期単位。
- 目標例：パイロットで検知から介入までのリードタイムを短縮。
数値目標は校ごとの基準で調整してください。KPIは必ず事前に計測方法をRFPに明記します。
導入手順（推奨フローとスケジュール感）
導入は段階的に行うことを推奨します。概略フローは次のとおりです。
- 要件定義と責任者の明確化（2〜4週間程度）。
- SSO/SIS設定とSandboxでの同期検証（2〜6週間）。
- パイロット実施（1〜3学年または数クラス、4〜8週間）。
- KPI測定と運用改善。
- 全校展開と運用マニュアル配布、定期的なレビュー。
デモ申込とRFP雛形の入手（実務的な手順）
デモや雛形入手は幅広く準備することで検証が効率化します。実務手順は次のとおりです。
- デモ申込（ベンダー例）
- 公式サイトの「製品紹介」または「デモ申込」フォームから申請。
- 希望する機能（出欠、保護者連携、SIS連携等）とパイロット規模を明記。
- セキュリティ資料とSLA案の事前提出を依頼する。
- RFP雛形の入手・作成
- 自校用のRFP雛形が無い場合は、上記の主要項目をテンプレート化して配布準備してください。
- 受け入れ試験（UAT）項目とKPIの計測方法を明記したチェックリストを添付します。
ベンダーからの回答は「機能の可否」「実装方式」「見積り（初期／月額）」「導入支援見積り」を明示させてください。
まとめ（学校タイプ別の判断軸と次のステップ）
導入判断は既存環境（Google/Microsoft等）、重視機能、運用体制、予算の4軸で行います。
Google Workspaceが中心の学校はまず現行の運用を検証し、保護者連携や学習ログが必須なら専用製品を比較してください。
次の実務ステップは要件を固めてRFPを出し、候補のデモを比較、パイロットでKPIを計測する流れです。
- まずやること：主要機能とSIS/SSO要件を確定し、RFPで受け入れ基準を明文化する。
- 次にやること：ベンダーにデモを要請し、パイロットで提出率・出欠処理時間等のKPIを計測する。
- 最終判断：仕様書・DPA・SLAを確認し、教育委員会や法務と合意した上で本展開を決定する。