個人開発の定石に「大手と正面からぶつかるな、ニッチを狙え」がある。自分もそう信じて1年やった。

信じたまま68案を検証して、68案とも自分で殺した。その途中で、この定石を直接検証できるデータに行き当たったので書く。

結論から言うと、少なくともApp Storeでは逆だった。題材を絞るほど、レビュー数は桁で落ちる。

数字は全部 iTunes Search API で自分で取った。取得日は2026-08-09。叩き方も書くので、読んだ人が自分で再現できる。

なぜ普通の比較では答えが出ないのか

「ニッチは儲かるか」を比べるのは本来かなり難しい。アプリAとアプリBのレビュー数を比べても、差の原因が題材なのか、UIの出来なのか、ASOなのか、リリース時期なのか、開発者の実力なのか分離できない。他の要因が混ざって分からなくなる。

だから、こう考えた。

同じ開発者が、同じ時期に、同じ作りで、同じ価格で出した複数のアプリを比べれば、題材以外の条件がほぼ揃う。

条件をそろえた比較になる。そしてApp Storeには、これを満たす開発者が実在する。数十本のカタログを持つ量産型の開発者だ。

iTunes Search API で開発者のカタログを丸ごと引く

Apple は認証不要の公開APIを出している。キーもトークンも要らない。

まず、気になるアプリを検索して artistId を取る。

import json, urllib.request, urllib.parse

def api(path, **params):
    url = f"https://itunes.apple.com/{path}?{urllib.parse.urlencode(params)}"
    with urllib.request.urlopen(url) as r:
        return json.load(r)

# キーワードで検索
res = api("search", term="生徒管理 メモ", country="jp", entity="software", limit=10)
for a in res["results"]:
    print(a.get("userRatingCount", 0), a.get("artistId"), a["trackName"])

ここで見るべきは userRatingCount（レビュー件数）と artistId（開発者ID）の両方だ。DL数は公開されていないが、レビュー数は公開されている。実際に使われた量の代理指標として使える。

次に、その artistId で同じ開発者のアプリを全部引く。

res = api("lookup", id=ARTIST_ID, country="jp", entity="software", limit=200)  # 上で取れた artistId
apps = [r for r in res["results"] if r.get("wrapperType") == "software"]

for a in sorted(apps, key=lambda x: -x.get("userRatingCount", 0)):
    print(f'{a.get("userRatingCount",0):>7}件 | {a.get("formattedPrice","-"):>6} | {a["trackName"]}')

lookup に entity=software を付けると、その開発者の公開アプリが一覧で返ってくる。これが名寄せになる。1本だけ見ていると分からないことが、カタログ全体を見ると見えてくる。

同一開発者44本の分布

ある開発者のカタログを引いたら、44本あった。全部無料で、全部同じ系統のシンプルな記録アプリだった。UIの作りも価格も揃っている。

レビュー件数の分布はこうなった（アプリ名は伏せて、題材の性質だけ書く）。

題材の性質	レビュー件数
ダイエット記録（消費者・巨大テーマ）	18,402
貯金箱・目標貯金	7,729
ギャンブル収支メモ	7,141
タイムシート	4,626
体重管理	2,064
筋トレ日記	1,277
顧客管理帳（汎用）	1,100
FX / 投資の収支記録	1,059 / 944
ペット日記	755
副業の収支管理	696
フリマ収支メモ	584
勉強の計画・復習管理	88
生徒管理メモ（業種を指名）	40
御朱印帳	9
パーソナルトレーナー向け管理（職種を指名）	3
履歴書作成・管理	0

44本の合計は70,301件。うち0件は2本だけだった。

中盤の3行を見てほしい。どれも「顧客を管理する」という同じジョブだ。

汎用の「顧客管理帳」→ 1,100件
業種を指名した「生徒管理」→ 40件（27分の1）
職種を指名した「パーソナルトレーナー向け」→ 3件（さらに13分の1）

絞るごとに桁が落ちる。開発者も実装力もUIも価格も同じ。変えたのは題材の粒度だけだ。

別の開発者でも同じ形になる

再現性を確かめるため、まったく別の開発者（21本のカタログ、こちらも全部無料）も引いた。

題材	レビュー件数
家計簿（汎用）	455,967
カレンダー（汎用）	370,582
QRコードリーダー	228,377
メモ帳	179,362
ダイエット・体重記録	129,696
歩数計	48,380
推し活管理	6,320
確定申告（青色）	4,047
白色申告	964
バーコードリーダー	544

こちらも汎用ほど多く、対象を絞るほど落ちる。同じ開発者・同じブランド・同じ無料モデルで、桁が3つ違う。

なぜこうなるのか

ニッチは競合が少ない場所であると同時に、探している人も少ない場所だからだ。

App Storeの主要な発見経路は検索（ASO）で、検索する人がいなければ発見されない。「顧客管理」で検索する人と、「パーソナルトレーナー顧客管理」で検索する人。この2つは桁が違う。競合が少ないのは、単にそこに人がいないからだった。

定石は「競合が少ない＝勝ちやすい」と読む。実測はそうなっていない。競合の少なさは、需要の少なさとほぼ同義だった。

絞ろうとすると、先客がいる

「それでも自分は特定の業種で深く刺す」という戦略はありうる。ただし、そこには先客がいる。

上の2人は、いわば善良な量産型だった。もっと徹底した例がある。ある開発者は45日で169本を投下していた。有料が55本（¥500〜¥5,800）あり、98%がレビュー0件。¥5,800の業務用帳票アプリも0件だった。

つまり「〈業種名〉×〈定型帳票〉」の形で機械的に作れる組み合わせは、既に総当たりで埋められている。空いているのではなく、全部出された上で誰も買っていない。

自分もこれを踏んだ。事業者向けを4方向から掘って、ようやく1つ「難しい計算で法令リスクもあるから残っているはず」という候補を見つけた。App Storeを調べたら、前日に他人が¥300で公開していた。レビューは0件。先を越されたというより、探す前から埋まっていた。

測定の落とし穴（自分が踏んだもの）

実測しているつもりで間違えたことが何度もある。同じ轍を踏まないように書いておく。

片方のストアしか見ていない。 iOSだけを見て「買い切りのアプリが存在しない＝空白だ」と判定したことがある。Google Play を見たら、同種の¥3,800買い切りが2本実在していた。片側だけで市場を測ると空白を誤検出する。

検索語のアーティファクト。 「〇〇互換」で検索して0件だったので空白だと思ったら、「〇〇変換」「〇〇調色」で調べたら既存が多数あった。ヒットしないのは、市場がないからでなく語彙が違うだけのことがある。

ランキング上位＝売れている、という誤読。 有料ビジネスカテゴリの日本1位が、生涯レビュー15件だった。8位は0件、14位（¥800）も0件。順位は相対値なので、買う人が少ない棚では1位でも実売はほぼゼロになる。チャートの順位から市場規模を推定してはいけない。

評価の星より件数の絶対値。 「★4.5で高評価」より「レビューが何件あるか」のほうが情報量が多い。★4.5でレビュー5件は、高品質の証拠というより市場が存在しない証拠であることが多い。

結局この定石をどう読み直したか

同じ開発者・同じ作り・同じ価格で並べると、題材を絞るごとにレビュー数が桁で落ちた。汎用1,100 → 業種40 → 職種3。別の開発者の21本でも同じ形が出て、汎用455,967 に対して職種を指名したものは544だった。

だから「競合が少ない」は「勝ちやすい」ではなく「探している人が少ない」と読むほうが実測に合う。競合の少なさは、多くの場合そのまま需要の少なさだった。しかも「業種 × 定型業務」で書ける設計空間には既に量産開発者がいて、空白に見えたものは撃たれた跡だった。

測るときの注意は3つ。両方のストアを見る。語彙を変えて検索する。順位でなくレビュー件数の絶対値を見る。

artistId での名寄せは10行で書ける。自分の企画がこの表のどのあたりに落ちるのかは、作る前に測れる。自分は68回目でようやくやった。

参考

iTunes Search API — Apple Performance Partners
Searching the iTunes Store — Apple Developer Archive（パラメータの一覧はこちらが読みやすい）
数字はすべて2026-08-09に日本ストアフロント（country=jp）で取得した。レビュー件数は変動するので、再現する場合は自分で取り直してほしい