JR東日本グループのオンラインサービスを共通IDで利用できる「JRE ID」。2025年2月の導入以降、モバイルSuicaやえきねっとなど14のサービスが対応し、2028年度には「Suicaアプリ」を軸にした一体型サービス提供を目指している。その認証基盤の刷新を巡り、セキュリティ対策と利用者の利便性をどう両立させたのか。JR東日本情報システムの2人が、Google Cloud Next Tokyoの講演で明らかにした。
「常に攻撃者の標的」となる認証基盤
JRE IDは、JR東日本グループのオンラインサービスを同一のIDとパスワードで利用できるようにする統合ID基盤だ。2025年2月に開始し、モバイルSuicaを皮切りに対応サービスを拡大してきた。2026年8月時点で14サービスがJRE IDに対応している。
グループの中長期ビジネス成長戦略「Beyond the Border」を支える基盤でもあり、2027年度までに各サービスのIDを統合し、2028年度以降は「Suicaアプリ」を軸にした一体型のサービス提供を目指す。
それだけに求められるセキュリティ水準は高い。新規会員登録やログイン、パスワードリセットなど、個人情報や決済に直結する機能を担うためだ。JR東日本情報システムの久保田祐司氏（マーケティングシステム部 JRE IDシステム開発運営PJ マネージャー）は「JR東日本グループのサービスは非常に多くのお客様にご利用いただいており、その規模から常に攻撃者の標的となっている」と述べる。水際対策が不可欠だった。
reCAPTCHA v3を採用、利用者の操作を妨げない対策
JR東日本情報システムは、Webサイトを操作しているのが人間なのかbotなのかを見分ける「CAPTCHA認証」（キャプチャ認証）を導入することにした。同社の高橋由紀氏は、製品選定に当たって「セキュリティ強度」「UI/UXへの影響」「目の不自由な人への対応」という3つの観点を重視した。
「JRE IDは列車の予約やSuicaの利用など、ログインが頻繁に発生するサービスです。毎回の認証操作がストレスになれば、サービス全体の体感価値を下げてしまいかねません」（高橋氏）
同社が採用したのは、Googleのbot対策サービス「reCAPTCHA」（リキャプチャ）だ。チェックボックスや画像パズルで人間かどうか確かめる「v2」と、Webサイト操作時の振る舞いを分析してスコアを返す「v3」があり、JR東日本情報システムが選んだのは後者だ。
特に重視したのは「利用者の負担をいかに減らせるか」という視点だ。reCAPTCHA v3は、Webブラウザの挙動やマウスの動き、タッチ操作のパターンを検知して人間かどうかを判定するため、利用者の操作を妨げずに済む。ユーザーが認証を意識することなく、ログイン後にシームレスに本来のサービスへ遷移できる。
さらに「指示された画像を選ぶ」といった特別な操作を必要としないため、目が不自由な人でも利用できる。さまざまな人が利用する公共交通にひも付くサービスのため「年齢や身体的条件にかかわらず、全てのお客様が等しくサービスを利用できることが重要な要件だった」と高橋氏は振り返る。
こうして、利用者の操作を「IDとパスワードを入力してログインボタンを押す」だけにとどめている。「利用者に意識させない防御」を構築できた。
導入後のトラフィック、95%が「安全」と判定
JRE IDのサービス開始後、認証システムは正しく機能したのか。JR東日本情報システムによると、通信トラフィックの構成は「安全が95%」「警戒が3%」「無効が2%」だった。大半は正規の利用だが、一定量の脅威が確実に検知されている。
検知された主な脅威は4種類——botなどによる自動化された操作、IDやパスワードを総当たり攻撃しているとみられる異常な量のアクセス、通常とは異なる不自然な環境からのアクセス、正常な行動パターンから逸脱した利用形態。これらをブロックすることができた。
高橋氏は「機械的かつ大量にIDとパスワードの組み合わせを試す攻撃や、Webサイトの情報を強引に引き抜くスクレイピングを、システムが過負荷に陥る前にリアルタイムでブロックできている」と説明する。対策がなければ「サーバダウンによるサービス停止や情報漏えいといった事態に発展していた可能性もある」という認識を同社は示した。
「ログインできない」エラーが多発、問い合わせが殺到する事態に
ただし、全てが順調だったわけではない。正規の利用者がログイン操作を行ってもエラーが頻発し、ログインできなくなる「タイムアウトエラー」が発生した。JRE IDは列車関連のサービスが中心で、高速移動中など電波状況が不安定な環境からのアクセスが多い。影響は想定以上に広がり「ログインができない」という問い合わせが多数寄せられたという。
これは、認証基盤の信頼を低下させかねない事態だ。reCAPTCHA提供元のGoogleにレビューを依頼したところ、原因はreCAPTCHAを呼び出すプログラムの実装位置にあると判明。より早い段階でスクリプトを読み込むよう修正すると、エラーが大きく減り、問い合わせも収まった。
不審なアクセスを判定する「しきい値」の設計にも苦労した。reCAPTCHA v3は「安全か危険か」の2値判定ではなく、0.0〜1.0のスコアで判定する。どのスコアを境にアクセスを拒否すべきか、当初は最適な基準が分からなかったという。厳しすぎれば正規の利用者を誤ってブロックし、緩すぎれば攻撃を見逃す。JR東日本情報システムは、実際のスコア分布を継続的に観察しながら、細かなチューニングを繰り返した。
こうした問題を解決するに当たり、Googleの支援を活用した。データ分析の手法を教わったことで、運用チームのモニタリング精度が上がったという。「自社だけでは見えにくい異常パターンについて指摘していただくなど、私たち自身の分析の視点が広がった」（久保田氏）
AIエージェント普及後の脅威にも対応へ
reCAPTCHAは2026年に、全方位型の不正対策プラットフォーム「Google Cloud Fraud Defense」へとリブランディングされた。自律型AIエージェントの利用が広がることを見越した防御機能が盛り込まれるという。
正規の利用者だけでなく、攻撃者もAIを使う。なりすましや不正アクセスがAIによって高度化する中、JR東日本情報システムとしてもこうした脅威に対応する方針だ。認証基盤を固めながら、JRE IDに対応するサービスの拡大や、他のID基盤との連携を進めるという。
久保田氏は「セキュリティ対策は導入して終わりではなく、運用の中で継続的に改善していくものだと改めて感じている」と語る。bot対策に限らず、さまざまなシステムの守りに通じる言葉といえよう。
