[ITmedia Mobile] Suicaのコード決済「teppay」にまつわる5つの疑問 なぜ本人確認がマイナカードのみ？ なぜ起動の遅いSuicaアプリ経由？

　東日本旅客鉄道（JR東日本）のコード決済サービス「teppay」が10月20日にスタートした。同社の商業施設やNewDaysなどをはじめとして、全国のコンビニエンスストアや大手チェーンなどで利用可能なため、既に利用している人も多いだろう。

　モバイルSuicaアプリをアップデートするとボタンが出現してteppay利用画面へと切り替えられ、本人確認を済ませることで銀行口座のひも付け（口座振替）やコンビニATMでの現金チャージ、またVIEWカードを持っていれば登録後にクレジットカード経由でのチャージが可能になる。

　チャージ後は残高を使ってのコード決済の他、別のユーザーへの残高転送が行えるようになり、他にJCBプリカをアプリ上から発行してカード番号入力によるオンライン決済も行える。

　基本的にはPayPayなどをはじめとする先行するコード決済サービスの後追いという位置付けだ。一方、AndroidのみならずiPhoneも含めてアプリ内の残高から直接Suicaへチャージできることから「（交通系ICの）Suicaの利便性を高める“モバイルSuica”の延長線上にあるサービス」であり、鉄道会社としての差別化ポイントだと同社では説明している。

　とはいえ、今なぜこのタイミングでの市場参入なのか、勝算はあるのかといった疑問が当然浮かぶ。また、実際にサービスに触れて判明した疑問もある。今回は、このteppayに関するさまざまな疑問を整理したい。

JR東日本系列のコンビニエンスストア「NewDays」ではSuica決済ボタンの隣に「teppay」ボタンも出現している

疑問1：なぜこのタイミングでの参入だったのか

　teppayが最初に発表された約1年前の記事でも触れたが、筆者の情報源によれば、teppayの元となるプロジェクトはもともとは「JREポイントを中心とした経済圏を活発化させる仕組みの構築」にあったという。

　時期的には2022～2023年ごろとみられるが、この頃はちょうどコード決済が取り扱い金額でSuicaなどの電子マネーを抜き始めたタイミングであり、携帯キャリア4社を中心にポイント経済圏での囲い込み戦略が顕著になった時期でもあった。そのため、JR東日本の経営陣からのトップダウンで「コード決済市場への参入」が指示され、前出のJREポイントを絡めた市場の可能性が模索され始めたようだ。

　ただ、後から分かった情報でteppayの開発期間は実質的にほぼ1年未満だったことが判明している。2025年11月にteppayが正式発表され、サービスインは翌2026年10月だったが、以前のレポートでも触れたように最初の発表時点ではまだ中身が何もできておらず、報道公開された動作デモも画面遷移のみを再現した“モックアップ”と呼べる状態だった。実際のサービスインが1年後とされたのも、このデモ公開時点では何もできていなかったことが理由で、実質的な開発期間は10カ月未満だったと推定される。

　では、実際の開発がスタートするまでの2023～2025年には何が起きていたのだろうか？　同社は2024年12月に「Suica Renaissance」と題してSuica刷新計画の第1弾を発表している。その際、「2026年秋頃にモバイルSuicaアプリを大幅にリニューアルし、上限額（2万円）を超える買い物にも利用できるコード決済機能、バリューを送る＆受け取る機能」の提供計画に言及していることから、この時点で基本機能がまとまったと考えられる。

　2025年前半は実際の提供に向けた金融庁を含む関係各所との調整や、開発にあたっての体制作りに充てられ、最終的にPASMOの取り込みに成功したことで「モバイルSuica」「モバイルPASMO」へのアドオン機能での実装という形がまとまり、teppay機能の先行発表にこぎつけたという流れだ。コード決済の伸張に経営陣が危機感を覚えてから、足かけ3～4年でサービス提供に至ったというわけだ。

2024年12月に発表された「Suica Renaissance」の第1弾。teppayの基本機能についてはここで既に触れられているが、詳細はまだ何も語られておらず、実際に仕様が固まったのは2025年に入ってからと推察される

疑問2：1年未満の開発期間で品質に問題はないのか

　全てのサービスではないだろうが、「デッドラインがあらかじめ決められ、開発期間の圧縮されたソフトウェア」は品質上の問題を内包している可能性が高い。

　その典型例は「7pay」で、提供のデッドラインがあらかじめ設定されていたにもかかわらず、仕様変更に伴う開発会社の交代や連携先の社内サービスとの調整不足など混乱が続いて開発期間がギリギリまで短縮されたために、不完全な形でサービスを始めてしまった。その結果、不正アクセスによって不正利用されるという事故を生み出す事態になった。そうした心配はteppayにはないのだろうか？

　情報源によれば、経営陣からトップダウンでteppay開発チームに与えられたミッションは「開発スピード優先」だったという。限られた期間で想定する機能を一通り盛り込める方法を何より優先して採用しろということだ。

　その結果、今回はJCBが提供する「金融機能の組み込みパッケージ」をフル活用する方法が採用された。JCBでは金融機関や非金融機関が特定の金融サービスを迅速かつ安全に提供できるよう、API経由でアプリやWebサイトに金融機能を組み込むためのSaaS（Software as a Service）サービスを用意している。

　今回の例でいえば、Smart Codeを経由したコード決済の仕組みに始まり、銀行口座を接続して残高チャージを行う口座振替、（teppay）ポイント関連の仕組み、送金機能やJCBプリカ発行など、teppayの主要機能のほとんどはJCBが提供する金融モジュールを組み合わせたものになっている。

　通常、これら仕組みを1から実装しようとすると2～3年の時間がかかるが、10カ月程度で実装を完了させた理由はこの方式の採用にある。特に口座振替など、利用できる金融機関をほぼ網羅しており、teppayが「既に完成されたモジュール同士の組み合わせ」でできていることを示す。

　いいことづくめのように見えるが、この方式にもデメリットがある。サービスの利用料としてJCBの取り分が増えるため、結果としてJR東日本がteppayの決済利用によって得られる収益が減少する。

　日本でのApple Payがいい例だが、国内参入にあたってはクレジットカードを登録するとQUICPayへのひも付けが行われるカード会社の方が多かった。これは、（三井住友カードとドコモの）iDではなく（JCBの）QUICPayを選んだ方が開発期間が短く、カード会社がこぞって後者を採用したためだ。JCBはSaaS形式でApple Payのカード即時発行を可能にするサービスを提供しており、Apple Payの日本展開の仕様が確定してからサービスインまでの期間が限られている中では、QUICPayを選ぶ方が現実的だった。

　代わりに、iDよりも手数料を多く取られる結果となったが、初期タイミングでのApple Pay参入を逃すよりも手数料の面でのデメリットを受け入れた方がいいと判断したのだろう。つまり、JR東日本がteppayで選んだのは「利益を削ってでもコード決済のスピード投入を優先した」ということだ。

JR東日本の関連施設では、10月20日以降にすぐteppayが利用可能になっている

　サービスとしてはこれで完成したteppayだが、後の複数方面への取材でいろいろ弊害が出てきていることが分かった。今回、teppayの開発を担当したのはSuicaの開発チームのうち、主に外部折衝を担当する部門だったという。

　JCBとの深い連携を見ても分かるが、外部の部隊との共同開発を行うケースが多く、今回のteppayもその経緯で誕生した。だがJR東日本グループ内部の他部門との連携が不十分であり、特にVIEWカードを介してグループ内商業施設を運営する流通部門とはポイント原資や各種キャンペーンとの連動で紛糾しており、不満の声が出ているという。開発陣は板挟みとなった格好だが、これもスピード優先での弊害なのかもしれない。