はじめに｜メンテ後に起きている“付与されない”感覚
メンテナンス以降、「以前と同じ行動をしたつもりなのに無料ポイントが付与されない」と感じるケースがあります。 これは端末故障というより、付与条件の判定や制御が強化された可能性が高い、と読むのが自然です。
無料ポイントの仕組み（初見グリーティング等）
IRIAMでは、複数の方法でポイントが提供されます（初見グリーティングキャンペーン、ログインボーナス、チュートリアルミッション等）。 ここでは代表例として、初見グリーティングキャンペーンを軸に説明します。
初見グリーティングキャンペーン（一般的な理解）
- 初見のライバー枠で一定時間（2分）滞在するとポイントが付与される
- 1日に対象となる人数の上限（10人）がある
※具体条件は時期やイベントで変動し得るため、アプリ内表示の条件を優先してください。
公式告知の要点｜「重複して獲得できない」制御
公式告知では、複数アカウントによるポイント獲得行為に対して、 「2つ目以降のアカウントではポイントが受け取れないよう制御する」趣旨が示されています。
ここがポイント
これは「見つけてBANする」というより、“付与そのものを止める（予防型）”の設計です。 そのため、利用者側は「アカウントが凍結された」ではなく、 「ポイントが付与されない」と体感しやすくなります。
規約に明記：IRIAMが取得している情報
ここは推測ではなく、IRIAMメンテナンスで公開された規約（取得項目）に沿って整理します。 重要なのは、「アクセスしたユーザーの特定等」目的で利用され得る情報が明記されている点です。
アプリ本体（自動取得）
「どの端末・どんな回線から来たか」の手がかりになるので、同じ日に複数アカで無料ポイントを取りに来た動きがあると、2回目以降を止める判断材料になり得ます。
| 取得項目 | 接続キャリア名、端末モデル名、言語・地域設定、接続IPアドレス、OS名、OSバージョン、クッキー情報 |
|---|---|
| 利用目的 | アカウント管理、アクセスしたユーザーの特定等 |
AppsFlyer（情報収集モジュール）
同じ端末（または同じ人っぽい環境）から“無料ポイント”を何回も受け取ろうとすると、2回目以降を止めやすくするための「目印」や「記録」を持っている、という意味です。
| 取得項目 | IDFA/ADID（広告ID）、IPアドレス、課金情報、アプリ内行動履歴、アプリバージョン、端末名、言語・地域設定、通信タイプ、通信キャリア、OS名/OSバージョン、Android ID、タイムゾーン など |
|---|---|
| 利用目的 | 広告効果測定（報告・検証・改善） |
Firebase SDK（Crashlytics等）
主目的はアプリを直すための記録ですが、端末やアプリの状態が分かると「同じ端末っぽい」判断材料にもなり得ます。結果として、無料ポイントの重複受け取りを止める助けになる場合があります。
| 取得項目 | 端末名、OS/アプリバージョン、クラッシュログ、画面サイズ/DPI、CPU/GPU情報、デバッグ設定、ルート化有無、空き容量 等 |
|---|---|
| 利用目的 | 動向調査、検証、改善 |
Zendesk（問い合わせ）
問い合わせ対応のための情報が中心です。ポイント制御そのもののためというより、トラブル時に状況を確認できる“控え”がある、くらいの位置づけです。
| 取得項目 | IRIAM上の名前、メールアドレス、ユーザID、端末情報、問い合わせ内容、購入情報のスクショ 等 |
|---|---|
| 利用目的 | CS業務、購入情報調査、アンケート、エラーレポート 等 |
注意
「第三者モジュールの利用目的」は主に分析・改善・広告計測ですが、 取得される項目自体は“判定材料”としても成立し得ることが、技術的には重要です。 ただし、何をどの目的でどう組み合わせるかは非公開です。
IPアドレスの誤解を解く（個人特定は限定的）
結論から言うと、IRIAMが見ているIPは基本的にグローバルIP（GIP）であり、 IP単体で個人（氏名・住所）を特定できるものではありません。
- 自宅Wi-Fi：家のルーターが外へ出るときのIP（家族全員で共有されやすい）
- モバイル回線：キャリア側の仕組み（共有IPになることも多い）
- 端末内のローカルIP（192.168.x.x）：サーバー側からは基本見えない
つまり
「同じWi-Fi＝即アウト」ではありません。IPは確定証拠ではなく相関材料として扱われるのが一般的です。
端末情報・広告IDとは何か（やさしく）
技術用語をいったん“日本語”にします。
| 端末モデル | 「iPhone 14」など、端末の種類。家族で別端末なら別モデルになることが多い。 |
|---|---|
| OS / OSバージョン | iOS / Android など。端末環境の判定に使える。 |
| 広告ID（IDFA/ADID） | 「広告用の匿名な番号札」。ただしiPhoneはATTで拒否すると取得できない/制限される。 |
| 端末スペック系 | 画面サイズ、DPI、CPU/GPUなど。単体では弱いが組み合わせで“環境の一致”を見られる。 |
ATT（トラッキング許可）の誤解
「トラッキングを許可しない」＝何も見えない、ではありません。 広告IDの取得が制限されても、IP・端末モデル・OS・アプリ内行動など“アプリ運営に必要な範囲”は取得され得ます。
なぜ付与制御が可能になるのか（技術的整理）
公式告知の「重複して獲得できないようにする制御」を、公開されている取得情報の範囲で説明すると、 “同一利用者の可能性”を推定する材料が複数あるためです。
（技術的に合理的なモデルの例）
回線情報（IP / キャリア）
＋ 端末環境（端末モデル / OS / アプリバージョン 等）
＋ 利用履歴（アプリ内行動 / 付与イベントの時刻 等）
↓
同一利用者である可能性（スコア）
↓
一定条件を満たした場合、2つ目以降の付与を止める（付与制御）ここでの重要点
- IPだけでは家族・共有回線を巻き込むため、複数要素の組み合わせが合理的
- 広告IDが取れないケースがあるため、広告IDに依存しない設計でも成立する
- 「BAN」より「付与制御」のほうが、誤検知リスクを抑えやすい
家族でIRIAMを利用している場合は？
家族で同じWi-Fi・同じ居住地域になるのは自然です。 そのため、技術的にも運営上も、IPや地域だけで同一人物扱いするのは不合理になりがちです。
家族利用が“それだけで”問題になりにくい理由（技術的）
- 端末モデルやOSが異なる
- 利用時間帯や行動が自然に分散する
- 同一人物と断定できない（誤検知リスクが高い）
注意が必要になり得るのは「行動が同期する」場合
家族でも、同じ時間帯に、同じ目的で、同じ種類のポイント付与行動が連続するなど、 複数要素が重なると“同一利用者の可能性”は上がり得ます。 どの条件で制御されるかは非公開なので、断定はできません。
なぜ停止ではなく“ポイント制御”なのか
技術・運用の観点で見ると、「付与制御」は次のメリットがあります。
- 誤検知のダメージが小さい（凍結より影響範囲を限定できる）
- 運用コストが低い（個別調査より自動制御）
- 公平性を守りやすい（重複取得を止めるのが目的に合う）
安心して利用するための整理（推奨）
基本方針
- 家族がそれぞれの端末で自然に楽しむ：問題になりにくい
- 「同一人物に見えやすい動き（同期・連続・集中）」を避ける：安全側に倒せる
- 付与条件はアプリ内表示を最優先：仕様は変動し得る
この記事が扱わないこと
- 検知回避の方法（抜け道）
- 内部仕様の断定
- 個別ケースの「セーフ/アウト」判定
運営の非開示領域に踏み込むため、ここは線引きします。
IRIAM Labの活動
IRIAMをもっと楽しく、分かりやすくするためのツール・解説記事を公開しています。 技術解説は「不安を煽らず、公開情報を整理する」方針で更新しています。
※本サイトは非公式のファンメイド企画であり、株式会社IRIAMとは関係ありません。