要点
- 支払い設定は、個人アカウントではなく組織の「Asset Store Publisher」にあった。（出典: 自社の実測・2026-09-07）
- 案内リンクは404になり、個人アカウントの4画面にも支払い項目はなかった。（出典: 自社の実測・2026-09-07）
- 画面の案内では、銀行振込の最低残高は$250以上、PayPalには残高の下限がなかった。（出典: 自社の実測・2026-09-07）
- 支払いプロフィールの追加・編集には、二段階認証の有効化が必要だった。（出典: 自社の実測・2026-09-07）
売上の受け取りを設定するために、案内リンクを開いた
Unity Asset Storeとは、Unity社が運営する、ゲーム開発用アセットの販売プラットフォームのことだ。今回確認したかったのは、そこで発生する売上の支払い設定だった。
確認の出発点は、Unity Publisher Portalのプロフィール画面だった。そこには、支払い設定の管理先を示す次の案内があった。
Payout preferences — Manage payout preferences in Unity ID settings
このリンクを開くと、404エラーになった。そこで、個人アカウントの設定画面に移り、Security、Settings、Privacy、My Seatsの4か所を確認した。しかし、いずれにも支払いに関する項目は見つからなかった。
ここで「リンク切れか、売上が発生してから解放される機能だろう」と結論しかけた。実際に確認できたのは、案内リンクが開けないことと、探した画面に項目がないことだった。売上の発生が機能の利用条件になっていることまで、確かめられたわけではなかった。
出典: 自社の実測（2026-09-07）
設定の所在は、個人アカウントではなく組織だった
支払い設定があったのは、Unity IDの左ナビゲーションにある「Organizations」から該当の組織を開き、その中の「Asset Store Publisher」タブへ進んだ先だった。
今回の記録では、出品用のアカウントを作ると同名の組織（Organization）が自動生成され、支払い設定はその組織側にのみ存在していた。個人アカウントの設定画面を探し続けても、目的の項目には到達できない構造だった。
探した画面の数だけを見ると、確認を重ねたように見える。しかし、SecurityからMy Seatsまで確認範囲を広げても、個人アカウント側を見ている点は変わっていなかった。今回の盲点は、確認した場所の数ではなく、設定が属する階層にあった。
組織側に項目が見つかったことで、「機能がない、あるいはまだ使えない」という判断は修正できた。一方で、この発見は案内リンクが404になった原因を説明するものではない。リンクの状態と、設定そのものの所在は分けて扱う必要があった。
出典: 自社の実測（2026-09-07）
支払い方法は、最低残高の条件まで比較した
設定の場所が分かった後は、受け取り方法の条件を確認した。画面上の案内では、銀行振込（wire transfer）には最低残高$250以上が必要で、PayPalでの受け取りには残高の下限がないと明記されていた。
| 支払い方法 | 画面上で確認した最低残高の条件 |
|---|---|
| 銀行振込（wire transfer） | $250以上 |
| PayPal | 残高の下限が無い |
単価の低い商品を売る場合、売上が発生していることと、受け取り条件を満たしていることは同じではない。銀行振込では最低残高に達する必要があるため、商品が売れても、その残高条件を満たすまでは入金につながらない。
今回の比較では、PayPalにはその残高の下限がない点が判断材料になった。最初の1本の売上から受け取りを考える場合にも、最低残高の条件を理由に待つ必要がないという違いがある。
ただし、ここで確認したのは画面に示された残高条件である。実際に入金された日や、支払いサイクルの具体的な日程を示す記録ではない。受け取り方法を検討する際も、最低残高について分かったことと、入金時期について確認すべきことを分けておきたい。
出典: 自社の実測（2026-09-07）
「追加」を押すと、二段階認証の前提条件が現れた
設定画面に到達しても、そのまま支払いプロフィールを追加できるわけではなかった。「追加」ボタンを押すと、すぐに次の案内が表示された。
二段階認証を有効化しないと、支払いプロフィールの追加・編集はできない
今回確認した画面では、二段階認証を有効化するまでは、支払い設定も税務フォームも操作できない仕組みになっていた。設定の所在が分からない問題に続いて、操作の前提条件を満たす必要があることが分かった。
ここでは、同じ「支払い設定ができない」という状態でも、確認する対象が変わっている。画面が見つからない段階では、個人と組織のどちらに設定が属するかを確認する。画面を開いて操作が止まった段階では、表示された案内から、先に済ませる必要がある設定を確認する。
この記録から言えるのは、操作に必要な条件が判明したところまでだ。二段階認証の有効化や、支払いプロフィールの登録が完了したという結果まで含めて扱うことはできない。
業務に置き換えると
今回の確認を、自分たちが利用するサービスの設定作業に置き換えるなら、点検したい項目は次のとおりだ。
- どの階層を探したか。 個人アカウントだけを見ていないか確認する。支払い・請求・税務系の設定が見つからない場合は、Organization、Team、Workspaceなど、組織側の設定も確認対象にする。
- 見つからないことを、利用できないことと結び付けていないか。 探した画面に項目がないという観察と、機能が存在しない、未解放であるという判断を分ける。
- 操作の直前に前提条件がないか。 ボタンを押した際の案内を確認し、二段階認証のように、先に有効化すべき別の設定が示されていないかを点検する。
- 受け取り方法の条件を比較したか。 単価の低い商品を複数のプラットフォームで売る場合は、最低残高と支払いサイクルを事前の比較項目にする。画面で確認できた条件と、まだ確認していない条件を分けて記録する。
今回、判断を変える根拠になったのは、組織側に実在した設定画面と、操作時に表示された案内だった。設定作業の記録には、探した場所だけでなく、どの表示を根拠に次の確認へ進んだかまで残しておくと、今回のような思い込みを点検する材料になる。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。