--- title: "エコめがねの不正アクセス：スマイルeポイント約1.4万件の不正交換と交換用URLを守る設計" url: "https://www.issoh.co.jp/tech/details/19461/" published: 2026-11-07 updated: 2026-11-07 categories: ["セキュリティ"] publisher: "株式会社一創" --- # エコめがねの不正アクセス：スマイルeポイント約1.4万件の不正交換と交換用URLを守る設計 NTTスマイルエナジーの太陽光発電の遠隔監視サービス「エコめがね」が2026年10月28日に不正アクセスを受け、11月6日の第2報で、同社が運営するポイント還元サービス「スマイルeポイント」の不正交換が明らかになりました。約14,000件・800万ポイント分が10月30日と31日の2日間でデジタルギフトコードに交換されています。前半では利用者が確かめること（補償・漏えいの可能性がある情報・パスワード・止まっている異常通知）を、後半では交換用URLが読まれると換金される理由と、トークンをハッシュだけで保存する実装を整理します。 ## まとめ：エコめがねの不正アクセスで起きた2つの被害と利用者・事業者が先にやること 被害は2つに分かれます。1つはエコめがねの顧客情報で、[10月30日の第1報](https://nttse.com/news/pressrelease/2026/10-30/3288/)は氏名または企業名、住所、電話番号、メールアドレス、ログインIDとパスワードが漏れた可能性があるとしました。もう1つは、利用者が保有していたスマイルeポイントの不正交換による被害です。[11月6日の第2報](https://nttse.com/news/pressrelease/2026/11-06/3292/)で、管理番号・交換用URL・ポイント数が第三者に読み取られ、大量に交換されたと分かりました。 | 区分 | 公表日 | 内容 | 11/6時点の状況 | | ---- | ----- | ----------------------- | --------- | | 顧客情報 | 10/30 | 氏名・住所・電話・メール・ID・パスワード | 流出の事実は未確認 | | ポイント | 11/6 | 約14,000件・800万ポイント分の不正交換 | 保有者に全額補償 | 利用者が先にやることは2つです。エコめがねと同じパスワードを使っている他のサービスで、パスワードを変える。発電の異常を知らせるメールが止まっているので、発電量を自分で見る。補償の手続きは個別のメールで届く予定なので、それを待ちます。 ポイントやギフトの交換機能を持つ事業者は、交換用URLやコードをデータベースにそのまま保存していないかを確かめます。読まれた時点で使える値を平文で置く設計だと、今回のようにDBへ届いた攻撃者がそのまま換金できます。 ## エコめがねとスマイルeポイントの利用者が確かめることと補償・問い合わせ窓口 ### 全額補償の対象は10月28日時点の保有者、手続きは個別メールで案内される予定 第2報によると、補償の対象は2026年10月28日の時点でスマイルeポイントを持っていた人で、ポイントを全額補償します。具体的な手続きは対象者へ個別のメールなどで知らせるとしており、11月6日時点で方法は示されていません。自分のポイントが不正交換の対象だったかを調べる必要はなく、28日時点で残高があれば対象です。 問い合わせは[第2報のPR TIMES版](https://prtimes.jp/main/html/rd/p/000000143.000005498.html)に載っている専用フォームで受け付けています。コールセンターなどの窓口は準備中です。開設日は決まり次第メールで知らせるとしています。 ### ログインIDとパスワードが漏れた可能性、同じパスワードの他サービスを先に変える 第1報は、サービスにログインするIDとパスワードも漏えいの可能性がある情報に挙げています。第2報では、氏名・住所・電話番号・メールアドレスなどの個人情報が外部へ漏れた事実は、調査中ではあるものの確認されていないとしました。ただ、可能性が消えたわけではありません。 エコめがね自体は全システムの通信を止めているため、ログインもパスワードの変更もできません。手を打てるのは他のサービスです。同じメールアドレスとパスワードの組み合わせで登録している通販サイトやクラウドサービスがあれば、そちらを今変えます。漏れた組み合わせを別のサイトで試すリスト型攻撃に備えるためです。パスワードを使わない認証に切り替えられるサービスなら、[パスキー認証の仕組みと導入判断](https://www.issoh.co.jp/column/details/15368/)も参考になります。 ### 発電と売電は続くが異常通知メールが止まる、停止中に発電量を自分で見る方法 太陽光発電設備の発電と売電は止まっていません。止まっているのは、発電設備の異常や停止を知らせるアラートのメールです。新しく設置した設備の開通登録や設定の作業も見合わせています。再開の時期は未定で、安全を確かめたサービスから順に再開する方針です。 通知が来ない間に設備が止まると、気付くのが遅れます。パワーコンディショナや屋内のモニターに出る発電量を晴れた日の昼に見る、電力会社から届く売電量のお知らせを前月と比べる、といった確かめ方で補います。販売・施工の会社と保守契約を結んでいる場合は、停止中の点検の方法をそちらに聞くのが確実です。 ### NTTスマイルエナジーを装う連絡への注意と、メールやSMSで求められない情報 第1報は、同社を装った不審なメール、SMS、電話に注意するよう呼びかけています。心当たりのない送信元なら、URLを押したり添付ファイルを開いたりせず、そのまま削除する対応が安全です。同社がメールやSMSでクレジットカード情報、口座番号、パスワードの入力を求めることはないとしています。 今回は「補償の手続き」を名目にした偽の連絡が考えられます。本物の案内が個別メールで届く予定なので、偽物と見分けにくくなります。届いたメールのリンクから入力せず、同社の公式サイトのお知らせから辿ると安全です。正規に見える連絡で入力させる手口は[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)で解説しました。 ## 公表資料で追う経緯：10月28日の検知からポイント不正交換の判明までの時系列 ### 初報・第1報・第2報から抜き出した日時と、交換の急増を検知した提携会社 NTTスマイルエナジーは3回公表しています。[10月29日の初報](https://nttse.com/news/2026/10-29/3284/)は「緊急メンテナンス」として出され、28日未明に一部のWebサーバーで不正アクセスを確かめたこと、その時点で流出は確認されていないことを伝えました。翌日の第1報で時刻と漏えいの可能性がある項目が示され、第2報でポイントの被害が加わっています。 | 日時 | 出来事（出典） | | ----------- | ------------------------- | | 10/28 20:20 | Webサーバーで不審アクセスの形跡を検知（第1報） | | 10/28 22:30 | Webサイトのサービス画面を緊急停止（第1報） | | 10/29 02:50 | クラウド全サーバー通信遮断・顧客DB停止（第1報） | | 10/30（第2報） | 不正交換約1,500件・100万ポイント分 | | 10/31（第2報） | 不正交換約12,500件・700万ポイント分 | | 11/4 | 提携会社から不正交換件数・ポイント数受領（第2報） | | 11/6 | 第2報で不正交換と全額補償を公表 | エコめがねの通信を29日未明に遮断した後の30日と31日に、交換が行われています。読み取られた交換用URLは、エコめがねの外にある提携会社の交換窓口で使えたためです。止めたのは同社ではなく、異常な交換の急増に気付いた提携会社でした。第2報によると、提携会社が交換の急増を検知して交換を停止したのは10月31日です。 ### 読み取られたのは管理番号・交換用URL・ポイント数、個人情報の流出は未確認 第2報は、第三者に不正に読み取られた形跡があるのは「管理番号」「交換用URL」「ポイント数」などの交換に関するデータだとしています。読み取った情報を使い、短い時間に換金を目的とした大量の交換が行われました。10月28日0時の時点で交換されていなかった約29,000件が、閲覧された可能性のある件数の参考値として示されています。 侵入の経路と技術的な原因は、外部の専門機関によるフォレンジック調査とログの解析を続けている段階で、11月6日時点で公表されていません。脆弱性の名称、提携会社の名称、交換先のギフトの種類も示されていません。 ### オムロンの「みんなでつくるエコ活サークル」の利用者が主な対象になる理由 不正交換の主な対象は、オムロン ソーシアルソリューションズ（OSS）製の蓄電システムを入れ、OSSの「みんなでつくるエコ活サークル」に加入した人です。[OSSの2022年6月29日の発表](https://kyodonewsprwire.jp/release/202206273066)では、サークルで付いたポイントをPayPayポイントやAmazonギフト券に交換でき、Amazonギフト券への交換はNTTスマイルエナジーが提供するとしていました。 ポイントの管理と還元の運営は、契約に基づきNTTスマイルエナジーが担っています。OSSの「オムロンポイント」では不正アクセスは起きていません。OSS製のシステムを使っている人からの問い合わせも、NTTスマイルエナジーがまとめて受けます。利用者から見ると申し込んだのはオムロンのサービスでも、ポイントの交換は別会社のシステムを通っていた、という構造です。 ## 交換用URLが読まれると換金される理由と、トークンをハッシュで保存する実装 ### URLを知っていれば使える持参人型リンクと、DBを読まれた時点で被害が決まる構造 ポイントの交換用URLは、URLの中のランダムな文字列そのものが「交換してよい」という証明になっている作りが多く見られます。メールで送ったURLを開くだけで交換画面に進めるので、利用者には手間がありません。その反面、URLを知っている人なら誰でも使えます。紙の商品券と同じ持参人型です。 この作りで、交換用URLをデータベースに平文で保存していると、DBを読まれた時点で全件が使える状態で漏れます。今回、エコめがねの通信を止めた後に提携会社の窓口で交換が続いたのは、この性質と矛盾しません。守る側が決められるのは、DBに何を置くかです。 ### 交換トークンをHMACで保存し本人と1回限りに縛るPythonとSQLiteの例 次のコードは、交換用URLに入れるトークンを[Pythonのsecretsモジュール](https://docs.python.org/ja/3/library/secrets.html)で作り、DBにはトークンのHMAC値だけを保存します。HMACの鍵（ペッパー）はDBとは別の場所に置き、環境変数を通じてコードに渡す構成です。交換のときは、届いたトークンから同じHMAC値を計算し、会員番号・未使用・期限内の3条件を1つのUPDATE文で確かめます。 ``` # 交換用URLのトークンをハッシュだけで保存する（Python 3.9以上・標準ライブラリのみ） import hashlib, hmac, os, secrets, sqlite3, time PEPPER = os.environ["EXCHANGE_PEPPER"].encode() # DBとは別の場所（秘密管理）に置く鍵 TTL_SEC = 14 * 24 * 3600 # 交換用URLの有効期間 db = sqlite3.connect(":memory:") db.execute("""CREATE TABLE exchange_link( id INTEGER PRIMARY KEY, member_id TEXT, points INTEGER, token_hash TEXT UNIQUE, expires_at INTEGER, used_at INTEGER)""") def digest(token): return hmac.new(PEPPER, token.encode(), hashlib.sha256).hexdigest() def issue(member_id, points): token = secrets.token_urlsafe(32) # 256ビットの乱数。連番や管理番号から作らない db.execute("INSERT INTO exchange_link(member_id, points, token_hash, expires_at)" " VALUES (?, ?, ?, ?)", (member_id, points, digest(token), int(time.time()) + TTL_SEC)) return "https://example.jp/exchange/" + token # 利用者へ送るだけで、DBには残さない def redeem(token, member_id): now = int(time.time()) cur = db.execute( "UPDATE exchange_link SET used_at = ? WHERE token_hash = ? AND member_id = ?" " AND used_at IS NULL AND expires_at > ?", (now, digest(token), member_id, now)) return "ok" if cur.rowcount == 1 else "rejected" url = issue("M-0001", 500) token = url.rsplit("/", 1)[1] print("issued :", url[:40] + "...") print("db row :", db.execute("SELECT member_id, points, token_hash FROM exchange_link").fetchone()) leaked_hash = db.execute("SELECT token_hash FROM exchange_link").fetchone()[0] print("attack1 (DBの値をそのまま使う):", redeem(leaked_hash, "M-0001")) print("attack2 (別会員で正しいトークン):", redeem(token, "M-9999")) print("owner (本人・1回目):", redeem(token, "M-0001")) print("replay (本人・2回目):", redeem(token, "M-0001")) ``` トークンの長さは、secretsモジュールの解説が2015年時点の目安として挙げる32バイト（256ビット）にしています。HMACの計算には[標準ライブラリのhmac](https://docs.python.org/ja/3/library/hmac.html)を使い、比較はDBの一致検索に任せています。使用済みの記録と照合を1つのUPDATE文で行うので、同じURLを同時に2回開かれても成功するのは1回だけです。 ### 実行結果の読み方、DBの値を盗まれても交換できず再利用と他人の利用も拒否 Python 3.14.10（Windows）で2026年11月7日に、試験用のペッパーを環境変数に入れて実行した結果です。NTTスマイルエナジーや提携会社の実装を再現したものではありません。 ``` issued : https://example.jp/exchange/rBeTsWCgtvTv... db row : ('M-0001', 500, '0ca1d23f6adb8946acabe55a770af8cb5a8fd6372e440937d50db4992850e2e4') attack1 (DBの値をそのまま使う): rejected attack2 (別会員で正しいトークン): rejected owner (本人・1回目): ok replay (本人・2回目): rejected ``` attack1は、DBを読んだ攻撃者がtoken\_hashの値をURLに入れて試した場合です。届いた値をもう一度HMACにかけて照合するため、DBに入っている値そのものでは一致しません。ペッパーがDBと一緒に盗まれていなければ、HMAC値から元のトークンを戻すこともできません。attack2は、URLだけを手に入れた別の会員が使った場合で、会員番号の条件で止まります。 この設計でも防げないものはあります。ペッパーを置いたアプリケーションサーバーまで乗っ取られた場合と、利用者のメールボックスからURLが盗まれた場合です。前者には交換件数の監視（後述）が、後者には有効期限の短さが効きます。ハッシュと暗号化の違いそのものは[ハッシュ化と暗号化の違いとパスワード保管の仕組み](https://www.issoh.co.jp/column/details/13487/)で整理しています。 ### ログイン用パスワードはscryptやArgon2idで保存、OWASPが示す最小の設定値 第1報が漏えいの可能性に挙げたログイン用パスワードも、保存の仕方で被害の大きさが変わります。[OWASPのPassword Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)は、総当たりに時間がかかる専用の関数で保存するよう求め、最小の設定値を次のように示しています。 | 方式 | OWASPの最小設定（2026-11-07確認） | | ----------------------- | ------------------------ | | Argon2id（第一候補） | メモリ19MiB・反復2回・並列度1 | | scrypt（Argon2idが使えない場合） | N=2^17・r=8・p=1 | | bcrypt（既存システム） | work factor≧10・入力≦72バイト | SHA-256を1回かけただけの保存は、上の表のどれにも当たりません。Pythonの標準ライブラリなら `hashlib.scrypt` が使えます。エコめがねのパスワードがどの形式で保存されていたかは公表されていないので、ここで言えるのは自社のシステムが表のどこにいるかを確かめることまでです。 ## 事業者の判断：ポイント交換を外部に開く前に確かめる設定と診断を入れる範囲 ### ギフティの発行APIとの違い、価値を作る攻撃と既存の価値を奪う攻撃の守り分け 10月には[ギフティのeギフト不正発行](https://www.issoh.co.jp/tech/details/19090/)も公表されました。こちらは発行の仕組みの弱点を突いて、存在しなかったギフトを新しく作らせた攻撃です。守る場所は発行APIの認可と発行数の上限でした。 エコめがねの件は逆で、すでに利用者が持っていたポイントの交換用URLが読まれ、他人の価値が引き出されました。守る場所は保存の仕方と、交換の窓口が本人を確かめているかです。自社のポイントの仕組みがどちらの攻撃に弱いかで、先に直す箇所が変わります。ポイントの付与・利用・失効の基本設計は[ポイント管理システムの仕組みと自社開発の判断基準](https://www.issoh.co.jp/column/details/15899/)にまとめました。 ### 交換の急増を提携先より先に自社で検知する、件数の監視と止める権限 今回、異常に気付いたのは交換を受け付けた提携会社でした。10月31日の1日だけで約12,500件と、前日の8倍を超える交換が起きています。交換用URLを発行する側でも、1時間あたりの交換件数を数え、平常時の数倍を超えたら交換の窓口を止める仕組みを持てます。 数えるだけでは足りません。夜間や休日に閾値を超えたとき、誰が窓口を止めてよいかを先に決めておきます。提携会社との契約に、異常時にどちらが止めるか、止めた後の連絡の順番を書いておくのも同じ理由です。API全体のレート制限やトークン失効の実装は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で解説しました。 ### Webサーバーを起点にDBまで届いた構成を、診断で確かめる範囲と依頼する条件 第1報によると、攻撃の形跡は最初にWebサーバーで見つかり、その後の調査で顧客情報を管理するDBサーバーへの攻撃の形跡も確かめられました。外から届くWebサーバーと顧客DBの間が、どこまで通信できる構成だったかは公表されていません。自社のシステムでは、Webサーバーが持っているDBの権限で交換用のデータまで読めるか、を確かめる価値があります。 外部診断を入れるべきなのは、ポイントやギフトのように換金できる値をシステムが持っていて、その値が平文で保存されているか分からない場合です。逆に、交換機能を持たず、会員情報も外部のSaaSに預けている構成なら、まずはパスワードの保存形式の確認だけで足ります。交換や決済の値を扱うWebシステムを第三者に確かめてもらう場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 エコめがねの不正アクセスについて、利用者と事業者から出やすい質問をまとめました。 ### エコめがねで漏れた個人情報は何ですか？ 10月30日の第1報は、漏えいの可能性がある情報として、施主とパートナー企業の氏名または企業名、住所、電話番号、メールアドレス、サービスのログインIDとパスワードを挙げました。11月6日の第2報では、これらの個人情報が外部へ漏れた事実は現時点で確認されていないとしています。調査は続いており、確定した件数も公表されていません。 ### スマイルeポイントの補償はいつ、どうやって受けられますか？ 10月28日時点でスマイルeポイントを持っていた人が対象で、ポイントは全額補償されます。手続きの方法と時期は、対象者に個別のメールなどで案内される予定で、11月6日時点では示されていません。問い合わせは第2報に載っている専用フォームで受け付けています。補償を名目にした偽のメールに注意し、公式サイトのお知らせと照らし合わせてから手続きします。 ### エコめがねのパスワードはいつ変更できますか？ エコめがねは全システムの通信を遮断しているため、11月6日時点でログインもパスワードの変更もできません。変更の手順は、サービスの再開時に個別の連絡とホームページで案内するとしています。先にできるのは、エコめがねと同じパスワードを使っている他のサービスのパスワードを変えることです。 ### エコめがねが止まっている間、太陽光発電は止まりますか？ 発電と売電は止まりません。止まっているのは、発電設備の異常や停止を知らせるアラートのメールと、新規設置の開通登録・設定の作業です。通知が届かない間は、パワーコンディショナや屋内のモニターの表示、電力会社からの売電量のお知らせで、発電が続いているかを自分で確かめます。再開の時期は未定です。 ### オムロンのエコ活サークルやオムロンポイントも被害を受けましたか？ 不正交換の主な対象は、オムロン ソーシアルソリューションズ製の蓄電システムを入れて「みんなでつくるエコ活サークル」に加入した人です。サークルのポイントの管理と交換を運営するのは、NTTスマイルエナジーです。一方、オムロンの「オムロンポイント」では不正アクセスは起きていないとされています。問い合わせはNTTスマイルエナジーがまとめて受けます。 ## 関連記事 - [ギフティの不正アクセス：eギフト不正発行5.5億円の経緯と発行APIの守り方](https://www.issoh.co.jp/tech/details/19090/)：ギフトを新しく作らせる、逆向きの攻撃 - [アララの不正アクセス：メール約8,100万件の持ち出しと契約企業が行うAPIキー再設定・代替送信・連名報告](https://www.issoh.co.jp/tech/details/19213/)：同じ時期に起きた、外部サービス起点の大規模事案 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：交換の窓口に入れるレート制限と失効 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：同社が実施した速報の位置づけ - [ハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説](https://www.issoh.co.jp/column/details/13487/)：トークンとパスワードをハッシュで保存する考え方 --- 出典: [エコめがねの不正アクセス：スマイルeポイント約1.4万件の不正交換と交換用URLを守る設計]()（株式会社一創）