進研ゼミ「チャレンジタッチ」が10年ぶりのリニューアル初日につながらない。何が起きているのか
進研ゼミ小学講座が10年ぶりの大規模リニューアルを開始した3月25日朝、アクセス集中でチャレンジタッチがつながらない障害が発生。エラーの内容、リニューアルで何が変わったか、インフラ構造を整理する。
ニュース
kkm
Backend Engineer / AWS / Django
チャレンジタッチが朝からつながらない
2026年3月25日の朝7時ごろから、進研ゼミ小学講座のタブレット学習サービス「チャレンジタッチ」でエラーが発生しています。ダウンロードができない、ログインできない、アプリが白い画面のまま止まるといった報告が相次いでいます。
表示されるエラーコードは「EF-SH-C9999-0005」。「ただいま混み合っています」というメッセージとともに、時間をおいて再度試すよう案内されます。ベネッセのヘルプデスクにも8時20分付けで「小学講座のアクセス集中によるエラー」として障害情報が掲載されました。
今日は春休み初日。多くの子どもが朝からタブレットを開いて新しい学年の教材をダウンロードしようとしたタイミングで、サーバーがアクセスに耐えられなくなった格好です。
10年ぶりのリニューアルで何が変わったのか
今日3月25日は、進研ゼミ小学講座の10年ぶりの大規模リニューアルの開始日でもあります。つまり、障害はただの「アクセス集中」ではなく、新システムへの切り替え初日に起きています。
リニューアルの目玉は3つあります。
まず「AI赤ペン先生」。ベネッセが45年間蓄積してきた約4.2億枚の添削答案データを分析し、子どもの学力・学習状況・性格タイプに応じて365日声かけと指導を行うアバターです。ただし月末の「赤ペン先生のまとめテスト」は、従来どおり人間の赤ペン先生が対応します。
次にゲーミフィケーション。東京大学の藤本徹教授の監修で、学習するとゲーム的な報酬が得られる仕組みを導入しました。ホーム画面にはヒャダイン氏作曲のテーマソング「ベンキョーアドベンチャー!」が流れます。
3つ目は保護者向けアプリの強化。子どもの学習進捗や理解度をリアルタイムで報告し、「今日はここを頑張ったので褒めてあげてください」といった具体的なアドバイスをプッシュ通知で送る仕組みです。
月額料金は1年生で月3,300円(12カ月一括払い)。対象は小学1年〜6年生です。
なぜリニューアル初日にダウンするのか
これは進研ゼミに限った話ではありません。大規模サービスのリニューアルや新学期の開始日は、アクセスが特定の時間帯に極端に集中します。全ユーザーが同じ日に新しいコンテンツをダウンロードしようとするためです。
思い出されるのは2026年1月のハローワークです。サイトの全面リニューアル初日に大規模障害が発生し、3日間サービスが停止しました。全銀システムも2023年の更新時に障害を起こしています。
共通しているのは「普段の何倍ものアクセスが、特定の日の特定の時間帯に集中する」構造です。進研ゼミの場合、春休み初日の朝という最もアクセスが集中しやすいタイミングと、新システムへの切り替えが重なりました。
これが予測できなかったとは考えにくい。全ユーザーが同じ日に新年度のコンテンツをダウンロードすることは明らかです。それでもダウンするということは、想定を超えるアクセスがあったか、新システムが想定通りにスケールしなかったかのどちらかです。
そもそも、春休み初日に大規模デプロイを行うという判断自体に疑問が残ります。春休みは子どもが自宅でタブレットを開く時間が増えるタイミングです。宿題や復習でアクセスが普段より多くなることは容易に予測できる。そこに10年ぶりの全面刷新をぶつければ、新システムへの切り替え負荷と春休みのアクセス増が同時に来ます。技術的にスケーリングが間に合わなかったという話以前に、なぜこのタイミングを選んだのかという意思決定の問題です。
外から見えるベネッセのインフラ構造
障害の中心はタブレットアプリ側のサーバーなので、外部からの調査には限界があります。ただ、ベネッセの公開Webサイトのインフラ構造を見ると、いくつかのことがわかります。
| サイト | CDN | サーバー | 応答速度 (TTFB) |
|---|---|---|---|
| sho.benesse.co.jp (小学講座) | Imperva | Azure App Gateway + Apache | 0.17〜0.30秒 |
| faq.benesse.co.jp (ヘルプデスク) | なし | nginx (NTT PC直収容) | 1.1〜2.0秒 |
| czemi.benesse.ne.jp (会員ページ) | Imperva | Azure App Gateway + Apache | 0.32〜0.39秒 |
小学講座のWebサイト自体はImperva(旧Incapsula)のCDNとAzure Application Gatewayの組み合わせで、外部からのアクセスには問題なく応答しています。ところが、障害情報を掲載しているヘルプデスク(faq.benesse.co.jp)はCDNを通さずnginxサーバーに直接つながっており、応答に1〜2秒かかります。障害発生時にユーザーが殺到する場所がCDNなしというのは、やや気になる構成です。
ただし、今回の障害の本丸はWebサイトではなくタブレットアプリのバックエンドです。ここが重要なのですが、ログインや教材ダウンロードといったAPIは、CDNでは守れません。CDNが効くのはトップページの画像やCSSのような「誰がアクセスしても同じ中身を返すもの」だけです。ログイン認証はユーザーごとに結果が違いますし、教材ダウンロードも学年や受講内容によって返すデータが変わります。こうしたAPI処理はキャッシュが本質的に効かないので、リクエストの1つ1つがバックエンドのサーバーまで到達します。
つまり、100万人が同時にタブレットを開けば、100万件のAPI呼び出しがそのままサーバーに降ってくる。これに耐えるには、アプリケーションサーバーを瞬時に増やせる仕組み(たとえばKubernetesのようなコンテナオーケストレーション基盤でPodを自動的にスケールアウトする)や、データベースのリードレプリカ(読み取り専用の複製)を用意して負荷を分散する構成が求められます。
今回の障害パターン、つまり「特定の日の特定の時間帯に全ユーザーが一斉になだれ込む」負荷は、年間を通じて見れば数日しか発生しません。普段のアクセス量に合わせたサーバー構成では耐えられないし、かといってピークに合わせて常時サーバーを用意するのはコストの無駄です。だからこそ、必要なときだけスケールアウトしてピークが過ぎたら縮退する、クラウドネイティブな設計が重要になります。ベネッセの既存のWebサイトがAzure上で動いていることを考えると、バックエンドのAPI基盤もAzure上にある可能性が高い。技術的にはスケールアウトの手段はあるはずで、問題は新システムの負荷試験が十分だったのか、あるいはオートスケールの設定が間に合っていなかったのか、という点になります。
保護者の反応と今後の見通し
SNS上では保護者の不満が広がっています。「春休み初日の朝から張り切ってタブレットを開いた子どもが号泣している」「やる気が完全に萎えた」という声が目立ちます。「スマイルゼミに乗り換える」「解約を検討する」という投稿も出ています。
子ども向けサービスの障害は、一般的なWebサービスの障害よりもダメージが大きい面があります。大人なら「あとで試そう」で済みますが、子どもは「楽しみにしていたものが使えない」という体験がそのまま学習意欲の低下につながりかねません。10年ぶりのリニューアルで「ゲーミフィケーション」を売りにしているだけに、初日のつまずきは厄介です。
ベネッセはヘルプデスクで「時間をおいてお試しください」と案内しています。過去の障害事例(3月4日〜5日のQRコード障害)では翌日の昼過ぎまでに復旧しており、今回もアクセスが分散する夕方以降には改善に向かう可能性があります。ただし、新年度コンテンツのダウンロードは今後数日にわたって続くため、断続的に混雑が発生する可能性は残ります。
ベネッセにとっての本当の問題は、障害が直ることではないでしょう。進研ゼミの会員数は減少傾向にあり、ベネッセはMBOによる上場廃止を経て立て直しの最中です。10年ぶりの勝負をかけたリニューアルの初日が「つながらない」で始まるのは、サービスへの信頼という意味で痛手です。
そしてSNSに出ている「スマイルゼミに乗り換える」「解約する」という声は、単なる不満の表明ではなく実際のビジネス損失につながります。子ども向け通信教育は「やる気になったタイミング」を逃すと戻ってきません。春休み初日に「よし、新しい学年の勉強を始めよう」と思ってタブレットを開いた子どもが、エラー画面を見て泣いた。その体験は保護者の解約判断に直結します。障害は数時間で直っても、失った信頼と乗り換えた顧客は戻ってこない可能性があります。
他の業界はどう捌いているのか
「100万人が同時にでかいファイルを落としに来る」という問題は、進研ゼミだけの話ではありません。ゲーム業界やOS配信では日常的に発生しており、すでに確立された対処法があります。
前日の夜に配っておく
Windows Updateは、更新ファイルをユーザーが寝ている間にバックグラウンドでダウンロードしておき、朝起きたら「準備完了」の状態にします。帯域の45%だけを使い、ユーザーの操作を邪魔しません。チャレンジタッチも前日夜のうちにWi-Fi経由で教材データを落としておけば、朝は差分同期だけで済んだはずです。
全員に同時配信しない
Windows Updateは「低学年から」「地域ごとに」のように対象を絞って波状的に展開します。Microsoftは最小100台のグループに分けて、数日かけて全体に届ける仕組みを持っています。100万人のチャレンジタッチに同じ朝、同じ瞬間にコンテンツを配り始める必要はなかったはずです。
隣の端末からもらう
Windows Updateには「配信の最適化」という仕組みがあり、同じネットワーク内の端末同士でファイルを融通し合います。大企業の環境ではサーバーへのリクエストを30〜70%削減できるとされています。きょうだいで使っている家庭なら、1台目がダウンロードした教材を2台目はLAN内で受け取る。サーバーに取りに行く必要がなくなります。
ダウンロードをキューに入れる
「ただいま混み合っています」と表示してユーザーを弾くのではなく、リクエストをキューに入れて順番に処理する方法もあります。ユーザーには「あと3分で準備できます」と表示して、裏では同時接続数を制御しながら配信を進める。Akamaiのダウンロード配信はこの考え方で、大型ファイルをチャンク単位でキャッシュし、途中で切れても途中から再開できる仕組みを提供しています。
いずれもサーバーを力技で増やす話ではなく、「いつ、誰に、どう届けるか」の設計の話です。今回のチャレンジタッチの障害は、春休み初日の朝という最もアクセスが集中するタイミングで、100万人に一斉配信を始めたことが直接の原因です。サーバーの性能が足りなかったのではなく、配信の設計がピークを想定していなかった。そこが一番の問題だったのではないかと思います。