その機能は、悪意のある人にとって何の役に立つか――Steamの取引保留と運営ツールの事件から、仕様書に悪用ケースの欄を設ける
フレンドにアイテムを渡せる。問い合わせに答えるため、運営担当者がユーザー情報を調べられる。どちらも、ゲームを遊びやすく、運営しやすくする機能である。同じ機能が、盗んだアイテムの換金や、プレイヤーのアカウントの不正な売買にも使われることがある。
仕様を書くときには、意図どおりに使われる「正常系」と、通信の切断や想定外の入力などに備える「例外系」を考える。そこにもう一つ、 「その機能は、悪意のある人にとって何の役に立つか」 という問いを足してみる。
本稿では、この問いを扱う欄を「悪用ケース」と呼ぶ。Steamの取引保留と、国内の運営ツールをめぐる二つの事件の再発防止策から、仕様書に何を書けるかを考える。これは「情シスとプレイヤーのあいだを走る」第2回である。
正常系・例外系に「悪用系」を足す
仕様書で抜け落ちやすい例外ケースでは、処理が失敗したとき、中断したとき、同時に起きたときを書く重要性を扱った。悪用ケースは、そこから一歩進めて、機能を使う人の目的を変えてみる考え方である。
整理の入口として、 例外は事故、悪用は意図 と捉えると分かりやすい。贈呈中に通信が切れるのは例外系、他人の持ち物を移す目的で贈呈機能を使うのは悪用系である。例外として想定した状態を意図的に起こす悪用もあり、両者は重なることもある。
Webアプリケーションなどの安全性に関する資料を公開するOWASPは、悪用ケースを、実装者が想定していなかった機能の使い方であり、攻撃者が自分の行動や入力によって機能や利用結果を左右できるもの、と説明している。[1]
同資料では、業務側の担当者が各機能を業務の観点から説明し、検討結果を仕様やユーザーストーリーに反映する役割を担う。ユーザーストーリーとは、誰が何のために機能を使うかを短く表したものだ。ゲーム開発で、遊びや運営業務の目的を説明し、仕様へ落とす役割は、プランナーの持ち場と重なる。[1]
このOWASP資料は現在「Historical（過去の資料）」扱いであり、悪用ケースは実務ではほとんど使われていない、というレビュー結果も掲載されている。本稿の提案は、資料にある本格的な検討手法の一式を導入することではなく、 いつもの仕様書に欄を一つ足す という軽い形である。[1]
取引機能が盗品の換金経路になる――Steamの取引保留
2015年12月9日、ValveはSteamの「Security and Trading」で、取引保留を導入する背景と仕様を説明した。当時、毎月およそ77,000件のアカウントが乗っ取られ、アイテムを奪われていたという。Valveは、乗っ取った者が盗品を売りさばくために取引機能を頼っていると説明した。[2]
利用者にとっての取引機能は、アイテムを交換する手段である。盗む側にとっては、盗品を自分の利益へ変えるための経路になる。機能が仕様どおりに動いていても、使う目的によって被害を広げうる。
Valveは取引機能そのものをなくす案も検討したが、正当に取引する利用者に不便を強いるとして退けた。代わりに採用したのが、アイテムの受け渡しに待ち時間を置く仕組みである。以下は、 2015年12月の発表当時の仕様 である。[2]
| アイテムを渡す側の認証などの条件 | 発表された保留の扱い |
|---|---|
| Steam Guard Mobile Authenticatorを7日以上有効にし、取引の確認もオンにしている | 保留なしで取引できる |
| 上記の認証条件を満たさない | 原則として最大3日保留する |
| 認証条件を満たさず、取引相手と1年以上フレンドである | 最大1日保留する |
Steam Guard Mobile Authenticatorは、スマートフォンを使う認証機能である。二要素認証とは、パスワードのような「知っているもの」に、スマートフォンのような「持っているもの」など、異なる種類の確認を組み合わせる方法を指す。
Valveは、保留によってSteamと持ち主が乗っ取りに気づき、アイテムを奪われる前にアカウントを取り戻す時間を確保すると説明した。一方で、スマートフォンでの認証を使えない人も含め、正当な利用者に待ち時間が発生することも認めている。[2]
仕様の判断として読むと、ここには「悪用を止める効果」と「正当な利用者の不便」の両方がある。Valveは機能を残したうえで、所定の認証と確認を行う利用者は待たせず、それ以外には時間を置いた。保留は、盗品をすぐに換金できなくする手当てであると同時に、持ち主が被害を止めるための時間にもなる。
アカウント乗っ取りの手口と復旧の流れは第5回で扱う。ここで仕様書に持ち帰りたいのは、機能の廃止以外にも、条件や待ち時間を変える選択肢があるという点である。
運営ツールも、プランナーが書く「仕様」である
運営ツールは、問い合わせ対応やゲームデータの管理をするために、社内の担当者が使う機能である。画面に何を表示し、誰にどの操作を認めるかを、プランナーが仕様として書くことも多い。
アクセス権とは、誰がどの情報を見たり、変更したりできるかを定めた許可の範囲である。悪用ケースの「誰が」には、外部の不正者に加え、こうした権限を持つ社内の人も入る。
ラグナロクオンライン――権限と操作の範囲を絞る
2006年7月20日のガンホーの発表によると、元社員が在職中に直属の上司のアカウントを盗み見て、ゲームデータを管理するサーバーへ不正にアクセスし、『ラグナロクオンライン』のゲーム内通貨を作り出してRMT業者へ売却していた。RMT（リアルマネートレード）は、ゲーム内の通貨やアイテム、アカウントなどを現実のお金で売買することだ。[3]
発覚のきっかけは、ゲームデータの監視業務で見つかったゲーム内通貨の異常値だった。社内調査によって不正行為を確認したのは、2006年3月24日である。[3]
同社が示した再発防止策のうち、運営ツールの仕様や運用に関わるものを整理すると、次のようになる。[3]
- 業務用ツールによるゲームデータへのアクセス管理を見直し、サービス環境とテスト環境のアクセス権を細分化する。
- プレイヤーが実際に遊ぶサービス環境へアクセスできるPCを最少にし、使用者を限定する。利用許可制にするとともに、操作内容の記録を保存・管理する。
- ゲーム内通貨やアイテムを作成できる権限者を、必要最少人数まで絞る。
- 業務用ツールの利用状況を監視する部門を新設し、監視体制を強化する。
ここから仕様に引き寄せて考えられるのは、「管理者」という一つの大きな括りを、作業や環境ごとに分けることだ。テスト用の操作を許可されていることと、実際のサービス上で通貨を作れることは、別々の許可として書ける。
また、通貨量の異常を見つけるには、何を通常の範囲とみなすかが必要になる。報酬設計やイベントによる増減を知るプランナーは、「この期間なら増える」「この増え方は説明がつかない」という判断の基準を、監視担当へ渡せる。
RMTの規約と法律については、日本におけるRMTの歴史を参照してほしい。
ログレス――権限者の画面にも標的を出さない
Aimingは2017年6月21日、『剣と魔法のログレス いにしえの女神』に関わる従業員の逮捕を発表した。7月12日の続報では、元従業員が運営の管理権限を使い、プレイヤーのアカウント引き継ぎコードを不正に入手して、RMTサイトに出品・販売したと説明した。引き継ぎコードは、ゲームデータを別の端末などへ移すための情報である。[4][5]
続報では、社内調査により、同様の手口でアクセスされたとみなされ、その後の接続状況の変化からRMTが行われたと想定されたアカウントは27件とされた。[5]
同社が発表した対策には、次の三つが含まれる。[5]
- 管理権限を必要最低限に絞る。
- 問い合わせ対応の担当者とユーザー情報を扱う担当者を分け、問い合わせへの対応件数とユーザー情報へのアクセス件数の差を定期的に確かめる。
- 運営管理の権限を持つ人でも引き継ぎコードを直接見られない仕組み（暗号化）を採用し、プレイヤーにはメールなどを通じて間接的に知らせる。
続報によれば、それまでのシステムは「お客様からのお問い合わせに迅速に対応するために、運営管理権限を有する者が直接引き継ぎコードを閲覧できるシステム」だった。[5] 問い合わせに素早く答えるための便利さが、そのまま標的への近道にもなっていたことになる。悪用ケース欄の「正当な利用者への影響」は、対策を入れるときだけでなく、便利さを選ぶときにも考える項目である。
暗号化とは、情報をそのまま読めない形に変え、元に戻すための鍵などを必要とする技術である。この発表を仕様の観点で読むと、中心にあるのは 「画面に何を表示しないか」 という判断だ。権限者に注意を促すことに加え、直接取得できる標的そのものを、担当者の画面から消す方針が示された。
問い合わせ件数とアクセス件数の突き合わせにも、業務を知る人の出番がある。何の問い合わせに、どの情報の参照が必要かを整理すれば、業務量と操作量を結び付けて見られる。ただし、一つの問い合わせで複数回参照する場合もあるため、件数の差は調べるきっかけであり、それだけで不正と決めるものではない。
悪用ケース欄に書く六つの項目
ここまでの事例を、普段の仕様書へ戻してみる。悪用ケース欄は、まず次の六つの項目から始められる。以下は本稿の提案である。
| 項目 | 書くことの例 |
|---|---|
| 誰が | 外部の不正者、乗っ取られた正規ユーザーのアカウントを使う者、社内の権限者 |
| 何を得るか | 換金、ゲーム内での優位、他のプレイヤーへの嫌がらせ |
| どの経路で | 取引、贈呈、問い合わせ対応画面など、目的に使える機能や画面 |
| 仕様での手当て | 権限の限定、表示する情報の制限、受け渡しの保留など |
| 正当な利用者への影響 | 待ち時間、追加の確認、問い合わせ対応の手間など |
| 異常を見つける指標 | 通常と異なる通貨量、業務量と情報参照量の差など |
「誰が」と「何を得るか」が変わると、同じ機能でも別の悪用ケースになる。贈呈を換金の経路として使う場合と、相手を困らせるために使う場合は、分けて書くと手当てを考えやすい。
手当てを、IPAの五つの基本原則で見直す
IPA（情報処理推進機構）の『組織における内部不正防止ガイドライン』第5版は、状況的犯罪予防の考え方を内部不正防止へ応用し、五つの基本原則を示している。 IPAの原則は内部不正を対象とするもの であり、ここでは悪用ケース全般の手当てを考える枠組みとして借りる。以下の事例との対応付けは、本稿による整理である。[6]
| IPAの基本原則 | 仕様や運用で考えられる手当て | 本稿の事例との対応 |
|---|---|---|
| 犯行を難しくする（やりにくくする） | 権限を作業ごとに分け、必要最小限にする | ラグナロクオンラインの環境別の権限細分化、両社の権限者・管理権限の限定 |
| 捕まるリスクを高める（やると見つかる） | 操作記録、異常値の監視、業務件数との突き合わせ。共有アカウントを廃止し、誰の操作かを残す | ラグナロクオンラインの操作記録と監視、ログレスの件数比較。共有アカウント廃止はIPAの対策例 |
| 犯行の見返りを減らす（割に合わない） | 標的を画面から隠す、暗号化する。盗品をすぐに換金できないよう時間を置く | ログレスの引き継ぎコード非表示・暗号化、Steamの取引保留 |
| 犯行の誘因を減らす（その気にさせない） | 公正な評価、働きやすい職場、円滑な意思疎通など、組織の側から手当てする | プランナーの機能仕様だけで扱える範囲を超える。経営・人事などと取り組む領域 |
| 犯罪の弁明をさせない（言い訳させない） | 規則や許可される作業の範囲を明示し、教育や誓約書で共有する | ガンホーの規定の社内掲示、Aimingの研修見直し。誓約書はIPAの対策例 |
一つの対策が複数の原則にまたがることもある。Steamの保留なら、換金を遅らせることと、被害に気づく時間を作ることの両方がある。表の分類に当てはめる目的は、手当ての偏りや、他部署と決める必要がある点を見つけることにある。
架空の記入例：フレンドへのアイテム贈呈
次は、架空のゲームに「フレンドへのアイテム贈呈機能」を作る場合の記入例である。実在のゲームの仕様や、Steamの対策一式を表したものではない。
| 項目 | 架空の記入内容 |
|---|---|
| 誰が | 乗っ取られた正規ユーザーのアカウントを使う者 |
| 何を得るか | 持ち主のアイテムを換金する利益 |
| どの経路で | フレンドへの贈呈機能を通じた、持ち物の移転 |
| 仕様での手当て | 重要な認証設定を変更した直後の贈呈は保留する。保留中は受け手が使用・再贈呈できない。持ち主へ通知し、心当たりがない場合の申告先を示す |
| 正当な利用者への影響 | 設定変更直後は、予定していた贈り物をすぐに渡せない。実行前に待ち時間を表示し、受け渡し予定を判断できるようにする |
| 異常を見つける指標 | 贈呈件数や移転したアイテム量の、通常の利用傾向からの変化。持ち主からの身に覚えのない贈呈の申告 |
この段階で、保留期間や「通常」の基準を、見栄えのよい数字で埋める必要はない。贈呈の利用実態、被害の発見に要する時間、イベント中の増減などを踏まえ、担当者と決める。その決定を担当・期限付きの検討事項として残し、仕様の確定前に埋める。
また、保留を置くなら、保留中のアイテムが使えるか、通知はいつ届くかといった周辺の仕様も必要になる。悪用ケースの欄は、機能の説明に戻って必要な動作を足すための入口である。
権限を持つのは、読者自身でもある
運営ツールの権限を持つのは、この記事を読む新人プランナー自身でもありうる。テスト、問い合わせ調査、補填などのためにデータを扱うとき、機能を設計する側の問いは、自分の操作を判断する問いにもなる。
ここで取り上げた国内の二つの事件は、いずれも逮捕と懲戒解雇に至った。ガンホーは元社員を2006年7月19日付で、Aimingは元従業員を2017年6月29日付で懲戒解雇したと発表している。[3][5]
ガンホーでは、社長と担当取締役の役員報酬を3か月間10分の1減額、直属の上長3名の給与を1〜2か月間10分の1減額、システム管理者1名の給与を2か月間10分の1減額する処分も発表された。Aimingでは、社長と最高執行責任者を務める取締役の月額報酬を、それぞれ1か月間10％減額した。不正の影響は、行った本人と被害を受けたプレイヤーに加え、一緒に働く人にも及ぶ。[3][4][5]
IPAの五つ目の原則「犯罪の弁明をさせない」は、自らの行為を正当化する理由をなくすことを指す。[6] 運営業務に引き寄せると、「テストのつもりだった」「あとで戻すつもりだった」「少しなら影響はない」という、自分への言い訳が生まれやすい場面を考えられる。
そこで役立つのが、テストを行う環境、操作の承認、作業目的の記録といった境界を、先に明示しておくことである。操作できる権限と、その目的で操作してよいという許可を分けておけば、自分一人の判断で越えてしまいやすい線が見える。
操作記録には、不正を疑って調べるための役割と、正しく働いた人の潔白を示す役割の両方がある。誰が、何の承認を受け、どの作業をしたかが残っていれば、後から通貨やアイテムの変化が見つかったときに、自分の作業を説明する手がかりになる。
自分が権限を使う場面で迷ったときは、一人で抱えず、上長に相談し、定められたルールに照らして確かめる。
書く範囲と、仕様書を読める範囲を決める
悪用ケース欄には、「何が起こりうるか」と「どう手当てするか」を書く。具体的な不正の操作手順まで広く共有する必要はない。仕様書を誰が読めるかも含めて、記載範囲を決める。
IPAのガイドラインも、付録Ⅵの「模倣犯を阻止する」の対策例として、インシデントの手口の公表を慎重にすることを挙げている。社内の検証で詳しい情報が必要な場合は、閲覧者を絞った資料で扱うなど、共有方法を担当者と決められる。[6]
プランナーが仕様として示すのは、何を守るか、誰に何を見せないか、正当な利用者にどんな待ち時間や確認を求めるかである。アクセスを制限する技術や監視の仕組みは、エンジニアや情シスと詰める。第1回で扱ったように、担当ごとの知識をつなぐことが、プランナーの役割になる。
チートを検知する技術については、オンラインゲームのアンチチート技術を参照してほしい。
仕様の段階で、一つ問いを増やす
取引の保留、権限の細分化、画面に表示しない情報、業務量と操作量の突き合わせ。いずれも、便利な機能が別の目的で使われることを考えると、仕様の検討項目になる。
「その機能は、悪意のある人にとって何の役に立つか」 を仕様の段階で問い、対策と正当な利用者への影響を一緒に書く。それがプランナーにできる備えである。
次回、第3回は「外部依存の棚卸し――取引先や社内システムが止まったら」を扱う。
References
1. OWASP「Abuse Case Cheat Sheet (Historical)」 — OWASP Cheat Sheet Series、2026年10月30日参照。定義、業務側の役割、検討後の仕様更新、Archive Statementを参照。英語資料の説明は本稿による要約。
2. Valve「Security and Trading」 — Steam、2015年12月9日。保留の条件は発表当時のもの。英語資料の説明は本稿による要約。
3. Kazuhisa「ガンホー，社員が不正アクセス禁止法違反の容疑で逮捕」 — 4Gamer.net、2006年7月20日。記事中に転載されたガンホーの発表「事件の経緯について」「関係者の処分について」「今後の対応について」「再発防止策の具体案」を中心に参照。
4. Aiming「不正アクセスおよび従業員の逮捕並びに役員報酬の減額に関するお知らせ」 — Aiming、2017年6月21日。添付のAiming「弊社従業員の逮捕に関するお知らせ」、Aiming・マーベラス「『剣と魔法のログレス いにしえの女神』の不正アクセスの件」を含む。
5. Aiming「不正アクセスおよび従業員の逮捕並びに役員報酬の減額に関するお知らせ（続報）」 — Aiming、2017年7月12日。「事件の概要と社内調査結果について」「その他責任者の処分について」「再発防止策について」を参照。
6. 情報処理推進機構「組織における内部不正防止ガイドライン」第5版 — IPA、2022年4月。本文7頁「2-1.内部不正防止の基本原則」、124頁「付録Ⅵ：内部不正防止の基本5原則と25分類」を参照。悪用ケース全般への応用とゲーム事例との対応付けは本稿の整理。
この文書は、Perplexity、Claude、ChatGPT の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。