教育ICTの「失敗しないRFP」作成術：よくある失敗パターンから考える、仕様書に含めるべき5つの防衛線

2026年8月19日2026年8月20日

GIGAスクール構想第2期（NEXT GIGA）に向けた調達において、最も気をつけなければならないのが「不十分な仕様による不要な混乱」です。これらを未然に防ぎ、導入から5年間の学校現場における安定稼働を担保するためには、より精緻で具体的なRFP（提案依頼書）および仕様書の策定が不可欠です。

本稿では、学校現場で起こりやすい失敗のパターンを整理し、RFPに盛り込んでおきたい具体的な「防衛線」を解説します。

よくある失敗パターン：RFPの抜けが現場の負担になる場面

仕様書の曖昧さが、結果として学校現場の負担や授業の停止につながる場面があります。ここに挙げるのは、調達の現場で起こりやすいパターンを整理したものです（自治体名・学校名は伏せています）。このうちパターン2については、筆者が実際に対応した際の所要時間を記載しています。

パターン1：ネットワークのボトルネック未解消による授業の停止

起こりうること: 新しい端末を全校に配布した直後、特定の学年が全クラス一斉にMeetやZoomを用いてオンライン学年集会・合同授業を試みたところ、通信が途絶・フリーズし授業が成立しなくなった。
抜けやすい要件: RFPにおいて「端末の基本スペック」は詳細に指定していたものの、「全校一斉アクセス時のネットワーク性能」や「校内LANのボトルネック解消要件」をシステムベンダーの責任範囲として明確に定義していなかったため。
対策: 仕様書に「全校児童生徒が一斉に動的なページ（動画視聴やWeb会議等）を閲覧・通信した際のレスポンスを検証・保証すること」というパフォーマンス要件を必須とする。

パターン2：管理番号シールの不備による人手の発生

起こりうること: 納品時、端末のキッティング自体は完了していたが、「教育委員会が管理するシリアル番号」と「端末表面に貼られたテプラ等（学校独自の管理番号）」が紐付いていなかった（あるいは正しく貼られていなかった）。これにより、故障時等に誰の持ち物か即座に判別できなくなった。
現場に及ぶ影響: この状態になると、端末裏の小さなシリアル番号と表面のテプラを1台ずつ突き合わせる全数チェックが必要になります。しかもこれは「ズレていた分だけ直す」作業ではなく、全台を確認すること自体がルールとして義務づけられているため、毎回すべての端末が対象です。実際に対応した際は、1台あたり約30秒。1クラス30台で約15分、1学年3クラス × 6学年＝18クラス（540台）で 約4.5時間 かかりました。これを年2回実施すると 年約9時間、加えて情報担当者による一覧表の再作成が1回約2時間 × 2回で 年約4時間。あわせて 年およそ13時間 です（※1）。納品前に仕様で決めておけば、いずれも発生しなかった作業です。
なお、テプラの新規作成・貼り直しが必要になった場合は、1台あたりさらに30秒〜1分かかります。必要な台数は学校によって大きく異なるため、上の時間には含めていません。
対策: 「シリアル番号・MDM上の識別番号・テプラ（管理番号シール）の3者を完全に紐付けた一覧表（CSV/Excel）を納品時に提出すること」をキッティング仕様に明記する。

パターン3：キッティングと「OSアップデートルール」の欠落

起こりうること: 新しく納品された端末で、学校が指定した既存の学習アプリケーションが正常に動作しなかった。旧端末では動いていたが、新規端末のみ動作不可となった。
抜けやすい要件: キッティングの要件として、OSアップデート適用のルールが明確化されていなかった。そのため、新規端末が出荷時点で「仕様指定よりも新しい（最新すぎる）バージョンのOS」にアップデートされた状態で納品され、学習アプリ側がまだそのOSバージョンに対応していなかった。
対策: 「納品時のOSバージョンは、教育委員会が事前に指定した（アプリの動作確認が取れている）バージョンに統一して出荷すること」を明記する。

パターン4：ストレージ容量やクラウド運用の設計ミス

起こりうること: 稼働開始から2年目以降、端末の動作が極端に遅くなり、ついにはOSのアップデート自体が容量不足を理由に実行できなくなった。
抜けやすい要件: RFP作成時、端末の「ローカルストレージ要件」を予算圧縮の目的で甘く（例：32GB等）見積もってしまった。また、「クラウドストレージ（Google Workspace等）を前提とする」方針だったにも関わらず、実際には不要なローカルアプリやキャッシュが蓄積されるMDM設定となっていた。
対策: 最低でも64GB以上のローカルストレージを必須要件とし、かつ「生徒が個人ローカル領域にデータを安易に保存できない構成設定」をキッティング時点で施す。

パターン5：バッテリー劣化に対する対応要件の欠如

起こりうること: 導入から3年目、満充電にしても1時間程度しか持たない（ACアダプタを繋ぎながらでないと授業ができない）端末が続出。しかしベンダーに問い合わせても「自然消耗は仕様通り。故障ではないので無償交換の対象外」と突き返された。
抜けやすい要件: 契約上の「故障要件・保守適用範囲」に、バッテリー劣化率の明確な基準が存在していなかった。
対策: 「契約から5年の間に、バッテリーの最大充電容量が新品時の◯◯%（例: 70%）を下回った場合は、無償での修理・交換対応の対象とする」旨を保守要件として記載する。

失敗しないRFPに盛り込むべき「5つの防衛線」

上記を避けるため、仕様書に盛り込んでおきたい防衛線を整理しました。

1. 「運用保守」のリードタイムを「時間単位」で明文化

修理や代替機の提供について「適切に」「速やかに」といった曖昧な記述は避けます。

明確化すべき書き方: 「故障の報告を受理してから、24時間以内（あるいは1営業日以内）に代替機を対象校へ発送すること」等、日付ではなく時間単位や営業日単位で、ベンダーが逃げられない基準を設けます。

2. ICT支援員・研修のセット提案

端末の購入・リースにとどまらず、「教員向け校務効率化研修を年間◯回実施すること」「常駐または巡回型のICT支援員による現場サポートを仕様に含むこと」を必須要件とします。

3. 「継続的な設定変更」の具体化（柔軟な機能拡張）

「継続的な設定変更のサポートを含む」という抽象的な要件では、ベンダーに追加の作業費を請求される恐れがあります。

明確化すべき書き方: 「契約期間中に新たなデジタル教科書やWeb上の学習ドリルが導入された際、アプリのホワイトリスト追加、通信フィルタリング設定の変更、アプリアップデートの配信設定等のMDM設定作業について、教育委員会からの依頼後3営業日以内に追加費用なしで対応すること」等と具体的に明記します。

4. セキュリティポリシーへの準拠証明

文科省の最新ガイドラインや自治体独自のセキュリティポリシーに対し、ベンダーのシステムが安全であるか自己評価と誓約をさせます。これはRFP本文とは別に、入札の必須提出書類として設けるのが効果的です。

5. 「出口（リサイクル・廃棄）」とデータ消去の要件

使い終わったリースアップ端末の処理手順を明確に定めます。特に、SDGsの観点と情報漏洩の防止の観点から以下のプロセスを要件化します。

【リサイクルと消去の手順】

対象端末の回収: 契約終了時に学校または指定場所からの確実な回収。
データ論理消去・物理破壊: 復元不可能な水準（米国防総省基準等に準拠）での確実なデータワイプ、またはSSD等の物理破壊。
証明書の発行: 各端末のシリアル番号と紐付いた「データ消去完了証明書」および「リサイクル完了証明書」の教育委員会への提出。
適正な再資源化: 法令に基づいた環境負荷の少ないリサイクル処理。

見落とされやすい点：ログイン情報が残ったまま端末を手放してしまう

端末を廃棄処分・回収に出す際、児童生徒や教員のログインIDが端末内に保存されたままになっていることがあります。
ワイプ（消去）のルールが明文化されていないと、簡単なパスワードを設定している端末では、画面を開いただけでクラウド上の学習履歴や教員の共有ドライブにアクセスできてしまう恐れがあります。データ消去はベンダーの作業だけでなく、「学校側で手放す前に必ずリモートワイプをかける」ルールと、「物理的に回収した後にベンダー側で再度確実な消去を行う」二段構えで要件化しておくことが重要です。