ギフティグループは2026年10月26日、子会社のギフティが運用するシステムの一部に第三者が不正アクセスし、eギフトが不正に発行されたと適時開示しました。損失は約5.5億円の見込みです。利用者が持っているeギフトが勝手に使われたわけではなく、個人情報の漏えいも確認されていません。前半では開示文とお知らせをもとに、手元のeギフトが使えるか、交換の不具合の窓口、同じ時期に出たブラストメール経由の別事案との違いを整理しました。後半は、金銭価値を発行するAPIを認可・発行上限・冪等キー・監視で守る設計を、Pythonで動かして確かめます。
まとめ：ギフティのeギフト不正発行で利用者に起きたことと起きていないこと
ギフティグループの適時開示によると、10月25日にシステムの脆弱性を悪用した不正アクセスが起き、そのシステムを経由してeギフトが新たに発行されていたことが分かりました。ギフティは同じ日にそのシステムを止め、今後も使わない方針です。
利用者の側で言えば、手元のeギフトはそのまま使えます。開示文は、お客様が保有するeギフトが不正に使われたものではなく、保有資産の減少も確認されていないとしています。損失はギフティグループに発生するもので、利用者が何かを負担する話ではありません。気をつけたいのは、事件に便乗してギフティを名乗る不審なメールです。
| 項目 | 公表内容（2026年10月26日・27日時点） |
|---|---|
| 発生・判明 | 2026年10月25日（日） |
| 起きたこと | 第三者がシステム経由でeギフトを新たに不正発行 |
| 手元のeギフト | 不正利用・残高の減少は確認されず、使える |
| 個人情報 | 漏えいは確認されていない |
| 当該システム | 10月25日に停止、今後も再開しない |
| 損失見込み | 約5.5億円、12月期第4四半期に特別損失 |
| 未公表 | 脆弱性の内容・発行件数・発行先 |
eギフトの利用者が確かめること：手元のギフト、交換の不具合、不審なメール
手元のeギフトは使える、不正発行は新規の発行で保有分の不正利用ではない
「不正アクセス」と聞くと、自分のギフトが盗まれたのではと心配になります。今回の開示文は、この点をはっきり書き分けています。第三者がギフティのシステムを介してeギフトを「新たに不正発行した」もので、利用者が持っているeギフトなどが「不正に使用されたものではありません」という書き方です。
10月27日のeギフトを使う人向けのお知らせも、受け取ったeギフトはこれまでどおり使えるとしています。友人やキャンペーンで受け取ったeギフト、会社の福利厚生で配られたeギフトも、今回の事案を理由に使えなくなることはありません。利用者が何か手続きをする必要もないとされています。
交換しづらい不具合が出たときの窓口と、手続きが要らない場合の線引き
ギフティは対応の過程で一部のeギフト交換サービスに一時的な支障が出ていたことを認めています。10月27日時点では、この支障は順次解消しているという説明です。eギフトのURLを開けない、店頭で交換できないといった症状が続く場合は、お知らせに載っている問い合わせ窓口を使ってください。
線引きは単純です。これまでどおり開けて使えているなら、何もしなくてかまいません。開けない、交換できないという不具合があるときだけ、お知らせのページから窓口へ進みます。メールやSNSで届いた「確認はこちら」というリンクから窓口に入るのは避け、ギフティの公式サイトから自分でたどってください。
ブラストメール経由の漏えいのおそれは別事案、旅先納税IDなど3つのサービス
同じ週にギフティは、もう1つ別の事案を公表しています。メール配信サービス「ブラストメール」を提供するラクスライトクラウドで不正アクセスが起き、ギフティがこのサービスに登録していた配信先の情報が漏えいした可能性がある、というものです。10月26日の第3報で対象に挙がっているのは、旅先納税ID、e街プラットフォーム、giftee Benefitの3つです。
項目は、旅先納税IDとメールアドレス、自治体名や企業名と担当者名・所属部署・メールアドレス、giftee Benefit IDと企業ログインURLなどです。第3報の時点で、運営会社が確認した漏えい344件にギフティの契約は含まれていないとされ、ギフティは定期的なお知らせを終えました。今後は漏えいが確認された場合にだけ知らせる方針です。eギフトの不正発行とは原因も対象も異なり、こちらは個人情報の漏えいのおそれに関わる話です。漏えいが確認された事業者が負う報告の流れは個人情報保護委員会への報告義務の実務で解説しています。
ギフティを名乗る不審メールとeギフトのURLを見分けるときの確認手順
大きく報道された事案のあとには、「お詫びのeギフトを受け取ってください」「eギフトの再発行手続きが必要です」といった便乗のメールが出やすくなります。ギフティは第3報で、当社や当社グループを装った不審なメールに注意し、心当たりのないメールのURLを開かず、添付ファイルやID・パスワードの入力を控えるよう呼びかけています。
確認の手順は2つで足ります。まず、今回の2つの事案についてギフティは利用者に手続きを求めていないので、手続きを急がせる連絡はそれだけで疑ってかまいません。次に、気になる連絡はリンクから開かず、検索やブックマークからギフティのニュース一覧を開いて、同じ内容が載っているか照らし合わせます。偽の連絡が通ってしまう仕組みはフィッシング詐欺の成立の仕組みと技術的対策にまとめました。
適時開示から読む事案の構造：脆弱性を突いた新規発行と約5.5億円の特別損失
10月25日の判明と停止から26日の適時開示まで、時系列と未公表の事柄
開示文から読み取れる経過は短く、10月25日の不正アクセスの発生と判明、脆弱性の特定、同じ日のシステム停止、10月26日の適時開示という順です。発生と停止が同じ日付で並んでいるので、発覚から遮断までは1日のうちに済んだことになります。ギフティは警察への相談と届出も進めるとしています。
書かれていないことも多くあります。どのシステムで、どんな脆弱性だったのか。何件のeギフトが、どの商品で、誰に向けて発行されたのか。開示文はそこに触れていません。10月30日時点で、ギフティのニュース一覧に10月27日のお知らせ以降の続報は出ていません。報道では「最大で約5億5000万円分」と伝えたものもありますが、開示文の表現は「現時点で約5.5億円と見込んで」いる、です。確定額は今後の開示を待つ必要があります。
損失を負うのはギフティグループ側、利用者の保有分が減らない仕組み
開示文は、不正発行に起因する金銭的な損失は当社グループに発生すると書いています。eギフトは、発行されたあと店舗やブランドの商品と引き換えられます。不正に発行されたeギフトが引き換えられれば、その商品の代金を誰かが負担しなければなりません。正規の注文主がいない発行なので、その負担がギフティ側に残るという構造です。
利用者の持つeギフトは、それぞれ別に発行されたものです。不正発行は新しいeギフトを作り出す行為なので、既存のeギフトの残高を書き換えるわけではありません。開示文が保有資産の減少は確認されていないと書けるのは、このためです。業績面では、2026年12月期第4四半期に特別損失を計上する見込みで、主要サービスの売上高と営業利益への重大な影響は見込んでいないとしています。
infoQのポイント交換とは逆向き、価値を奪う攻撃でなく作り出す攻撃
ポイントやギフトをめぐる不正は、10月にも起きています。infoQの事案では、サイトのソフトウェアの脆弱性を突いた不正アクセスのあと、会員が貯めたポイントの不正な交換が611件見つかりました。こちらは利用者がすでに持っている価値を奪う攻撃です。経緯はinfoQの不正アクセスとポイント交換を止める設計で整理しました。
ギフティの事案は向きが逆です。誰かの持ち物を奪うのではなく、発行する側の仕組みを使って、もともと無かった価値を作り出すという構造です。奪う攻撃は利用者ごとに被害が積み上がり、作り出す攻撃は発行の仕組みが止まるまで被害が積み上がります。守り方も変わり、前者は交換の停止と不正な交換の検知が、後者は発行の権限と量の管理が中心になります。
開発側の教訓：金銭価値を発行するAPIを認可・上限・冪等キー・監視で守る設計
発行の窓口が抜かれると被害額は際限なく積み上がる、OWASP API5とAPI6
ここから先は、ギフティのシステムがどう作られていたかを推測するものではありません。eギフト、ポイント、クーポン、プリペイド残高のように、発行した瞬間に金銭価値が生まれるシステム全般の話です。こうしたシステムでは、発行の処理を呼べる人と回数が、そのまま損失の上限になります。発行の窓口に誰でも、何回でも届く状態なら、上限はありません。
OWASP API Security Top 10のAPI5:2023は、一般の利用者が管理用の機能に届いてしまう「機能レベルの認可の不備」を挙げ、既定ですべてのアクセスを拒否し、役割ごとに明示的に許可する設計を求めています。API6:2023は、購入や予約のような業務上の流れを自動化された過度な利用から守らないことをリスクに挙げています。発行APIはこの2つが重なる場所です。リスク全体の見取り図はAPIセキュリティとOWASP API Top 10の実装対策にまとめました。
認可・発行上限・冪等キーを1つの発行処理に入れるPythonとSQLiteの再現
次のコードは標準ライブラリだけで動きます。データベースにはPythonのsqlite3を使い、対策の無い発行処理と、4つの守りを入れた発行処理を比べました。上限の判定と加算は、SQLiteのRETURNING句（3.35.0から対応）を付けたUPDATE文1つで行っています。判定と加算を別の文に分けると、同時に届いた発行要求が両方とも上限内と判定されてしまうからです。
# eギフトの「発行」APIを、認可・発行上限・冪等キー・発行数の監視で守る再現（Python 3.8以上・標準ライブラリのみ・SQLite 3.35以上）
# 使い方: python issue_guard.py
import secrets
import sqlite3
from collections import Counter
db = sqlite3.connect(":memory:", isolation_level=None)
db.executescript("""
CREATE TABLE api_key (key TEXT PRIMARY KEY, client TEXT, role TEXT);
CREATE TABLE campaign (id TEXT PRIMARY KEY, client TEXT, cap INTEGER, issued INTEGER DEFAULT 0);
CREATE TABLE issue (idem TEXT PRIMARY KEY, campaign TEXT, code TEXT, minute INTEGER);
INSERT INTO api_key VALUES ('k-shop', 'shop-a', 'issuer'), ('k-view', 'shop-b', 'viewer');
INSERT INTO campaign VALUES ('cp-1', 'shop-a', 300, 0);
""")
def naive(key, cp, idem, minute):
# 対策なし：鍵の権限も上限も見ずに発行する
db.execute("INSERT OR IGNORE INTO issue VALUES (?, ?, ?, ?)", (idem, cp, secrets.token_urlsafe(9), minute))
return "201"
def guarded(key, cp, idem, minute):
# 1. 既定で拒否し、発行権限があり、かつ自社のキャンペーンだけ許す
row = db.execute("SELECT a.role, c.client = a.client FROM api_key a, campaign c "
"WHERE a.key = ? AND c.id = ?", (key, cp)).fetchone()
if row is None or row[0] != "issuer" or not row[1]:
return "403"
# 2. 同じ冪等キーの再送は、前回のコードを返して新たに発行しない
if db.execute("SELECT 1 FROM issue WHERE idem = ?", (idem,)).fetchone():
return "200 replay"
# 3. 上限の判定と加算を1文で行う（同時に来ても上限を超えない）
db.execute("BEGIN IMMEDIATE")
ok = db.execute("UPDATE campaign SET issued = issued + 1 WHERE id = ? AND issued + 1 <= cap "
"RETURNING issued", (cp,)).fetchone()
if ok is None:
db.execute("ROLLBACK")
return "409 cap"
db.execute("INSERT INTO issue VALUES (?, ?, ?, ?)", (idem, cp, secrets.token_urlsafe(9), minute))
db.execute("COMMIT")
return "201"
def reset():
db.execute("DELETE FROM issue")
db.execute("UPDATE campaign SET issued = 0")
def attack(handler, key, n):
# 盗んだ鍵や権限の無い鍵で、毎回違う冪等キーを付けて n 回発行を試す（1分に100件）
reset()
res = [handler(key, "cp-1", f"atk-{i}", 600 + i // 100) for i in range(n)]
return dict(Counter(res)), db.execute("SELECT COUNT(*) FROM issue").fetchone()[0]
print("[naive viewer key ]", attack(naive, "k-view", 1000))
print("[guard viewer key ]", attack(guarded, "k-view", 1000))
print("[guard leaked key ]", attack(guarded, "k-shop", 1000))
reset()
print("[guard retry x3 ]", [guarded("k-shop", "cp-1", "order-777", 0) for _ in range(3)])
# 4. 発行数を分単位で数え、平常時の中央値の10倍を超えた分を警告する
reset()
db.execute("UPDATE campaign SET cap = 10000")
for m in range(600): # 平常時：10時間、毎分2件
for j in range(2):
guarded("k-shop", "cp-1", f"n-{m}-{j}", m)
spike = [guarded("k-shop", "cp-1", f"x-{i}", 600 + i // 100) for i in range(300)]
per_min = dict(db.execute("SELECT minute, COUNT(*) FROM issue GROUP BY minute").fetchall())
base = sorted(per_min[m] for m in range(600))[300]
print("[monitor baseline ]", base, "per min")
print("[monitor alert ]", [(m, c) for m, c in sorted(per_min.items()) if c > base * 10])Python 3.14.7（SQLite 3.50.4・Windows）で実行した結果です。
$ python issue_guard.py
[naive viewer key ] ({'201': 1000}, 1000)
[guard viewer key ] ({'403': 1000}, 0)
[guard leaked key ] ({'201': 300, '409 cap': 700}, 300)
[guard retry x3 ] ['201', '200 replay', '200 replay']
[monitor baseline ] 2 per min
[monitor alert ] [(600, 100), (601, 100), (602, 100)]実行結果の読み方、漏れた鍵でも上限300件で止まり再送は二重発行しない
1行目は、閲覧用の権限しかない別会社の鍵で1000回発行を試すと、対策の無い処理では1000件すべてが発行されることを示します。2行目は同じ攻撃を守った処理に向けたもので、権限と所属の確認で1000回とも403になり、1件も発行されません。
3行目が実務でいちばん効く部分です。発行権限を持つ正規の鍵が漏れた場合、認可の確認は通ってしまいます。それでもキャンペーンごとの上限300件で止まり、残りの700回は409で拒否されました。被害は「上限まで」に収まります。上限を実際の配布予定数に合わせておけば、鍵が漏れたときの損失額を前もって計算できます。4行目は、正規の注文主がネットワークの不調で同じ要求を3回送った場合です。同じ冪等キーなので発行は1件だけで、2回目と3回目は前回の結果を返しました。冪等キーの考え方は冪等性の意味とAPIでの担保方法で詳しく扱っています。
発行数を分単位で数えて平常時の10倍で警告する監視、止める権限まで決める
5行目と6行目は監視です。平常時の毎分2件に対し、600分目から毎分100件の発行が3分続くと、その3分がそのまま警告として出ました。上限が大きいキャンペーンや、上限を設けにくい常設の発行窓口では、この監視が最後の歯止めになります。発行数の推移をメトリクスとして集める方法とアラートのしきい値の決め方はメトリクス監視の型と閾値の設計にまとめました。
見落としやすいのは、警告のあとの動きです。休日の夜に警告が鳴っても、発行を止める判断を誰がするのか決まっていなければ、朝まで発行が続きます。発行数がしきい値を超えたら、そのキャンペーンや鍵を自動で止める仕組みにしておくと、止まりすぎたときに正規の配布が遅れる不便と引き換えに、損失の拡大は確実に防げます。金銭価値を発行する窓口では、自動停止を選ぶべきです。APIの入口でトークンの失効やレート制限まで組む手順はAPI不正アクセス対策の実装手順で扱っています。
事業者の判断：ポイントやギフトを発行するシステムに外部診断を入れる条件
発行権限の確認と上限が無いなら、外部診断で発行の窓口を優先して見る
ポイントの付与、クーポンの配布、ギフトの発行、プリペイド残高のチャージ。どれも、処理が1回走るたびに金銭価値が生まれます。こうした処理は社内の管理画面や取引先向けのAPIから呼ばれることが多く、外部に公開しているつもりがないぶん、点検の対象から漏れがちです。
次のどれかに当てはまるなら、外部の脆弱性診断で発行の窓口を優先して見てもらってください。発行APIの鍵や管理画面の権限が、閲覧と発行で分かれていないこと。キャンペーンや取引先ごとの発行上限が、データベースの側で強制されていないこと。発行数の推移を誰も見ておらず、急増しても止める手順が無いことです。逆に、権限が分かれ、上限がデータベースで強制され、急増時に自動で止まる作りなら、診断は定期点検の範囲で足ります。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準で解説しています。
自社の発行や付与の仕組みに同じ弱点が残っていないかを第三者に確かめてもらいたいなら、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
ギフティの不正アクセスについて、eギフトの利用者から出やすい質問をまとめました。
もらったeギフトは今も使えますか？
使えます。ギフティの10月27日のお知らせは、受け取ったeギフトはこれまでどおり使えるとしています。今回の事案は第三者がeギフトを新たに不正発行したもので、利用者が持っているeギフトが不正に使われたり、残高が減ったりしたことは確認されていません。開けない、交換できないといった不具合があるときだけ、お知らせのページにある窓口を使ってください。
ギフティの不正アクセスで個人情報は漏れましたか？
eギフトの不正発行の件では、個人情報の漏えいは確認されていないと開示文に書かれています。これとは別に、メール配信サービス「ブラストメール」への不正アクセスで、旅先納税ID、e街プラットフォーム、giftee Benefitの登録情報が漏えいした可能性が公表されました。こちらも第3報の時点で、ギフティの情報の漏えいは確認されていません。
何か手続きをする必要はありますか？
これまでどおりeギフトを開けて使えているなら、手続きは要りません。ギフティは今回の2つの事案で、利用者に手続きを求めていません。「再発行の手続きが必要です」「お詫びのギフトを受け取ってください」といった連絡が届いたら、リンクを開かず、ギフティの公式サイトのニュース一覧で同じ内容が載っているかを確かめてください。
不正に発行されたeギフトの5.5億円は誰が負担するのですか？
開示文は、不正発行に起因する金銭的な損失はギフティグループに発生するとしています。利用者や、eギフトを贈った人が負担するものではありません。約5.5億円は10月26日時点の見込み額で、2026年12月期第4四半期に特別損失として計上する見込みです。確定額は今後の開示で示されます。
ギフティのeギフトはこれからも安全に使えますか？
不正発行に使われたシステムは10月25日に止められ、今後も再開しない方針です。ギフティのそのほかの主要サービスは通常どおり動いています。ギフティは、eギフトの発行に関する管理体制と監視体制を強めて再発を防ぐとしています。利用者の側では、公式の画面やアプリから使い、メールやSNSのリンクから個人情報を入れないことを続けてください。
関連記事
- infoQの不正アクセスで89万件持ち出し｜ログインできない理由・退会・補填とポイント交換を止める設計：利用者のポイントが交換された、向きが逆の事案
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：APIの入口で認可と制限を組む手順
- APIセキュリティとは？OWASP API Top 10の主要リスクと実装対策を解説：機能レベルの認可と業務フローの保護を含むリスクの全体像
- 冪等性とは？読み方・意味からAPI・IaCでの担保方法まで実装者向けに解説：再送で二重に発行しないための冪等キーの設計
- メトリクス監視とは｜4種のメトリック型・収集方式・アラート閾値の設計と導入判断を実装目線で解説：発行数の急増を捉えるしきい値の決め方
