Eightpost — Guideline 4.2 (Minimum Functionality) で止まった話
2026-04-05
Eightpost とは
Eightpost(8番投稿) は、SNS風のタイムラインに 混入する「異変」を見つけるパズルゲーム として企画した iOS アプリです。20種類の Anomaly(異変)、3つのゲームモード、5エピソードのストーリーモード。仕様としては最後まで作り切った プロジェクトでした。
しかし、App Store審査で Guideline 4.2 - Design - Minimum Functionality に該当するとしてリジェクトされ、未リリースのまま塩漬け になっています。この記事では、何を作ったのか、なぜリジェクトされたのか、そして次に活かす学びをまとめます。
何を作ったのか
20種類の Anomaly Type
AnomalyType enum に 20種類の異変パターンを定義しました。
- 写真の差し替え/変化
- いいね数の異常な増減
- コメント欄のグリッチ
- 時刻表示のバグ
- 心拍のような脈動表示
- ユーザー名の微妙な変化
- ...
「ぱっと見では分からない」レベルの違和感を、コードで再現可能なパターン として整備したのが設計の核です。
3つのゲームモード
- 通常モード — 8ステージ固定。基本ルールを学ぶ導入
- タイムアタック — 30秒の制限で異変を見つけ続ける
- エンドレス — 連続クリアの記録を競う
ストーリーモード(5エピソード×40ステージ)
主人公の心理が段階的に変化していく構造。「友達の投稿、羨ましいな」→「全部、嘘じゃないか?」→「異変は本当にあるのか、それとも自分の歪みか」と、SNS依存の心の動きを疑似体験させる 設計でした。
なぜリジェクトされたのか
App Storeから返ってきたリジェクト理由は Guideline 4.2 - Design - Minimum Functionality 。Apple のガイドラインを噛み砕くと、こういう指摘です。
アプリは、継続的な娯楽的価値や十分な機能性 を備えている必要があります。ありふれたゲームメカニクスや、コンテンツ量・体験の深さが不十分なアプリはリジェクトの対象となります。
つまり、「間違い探し という遊びの本質が単純すぎて、App Store に並ぶアプリとしては機能・コンテンツが薄い」という判断です。20種の Anomaly、3モード、ストーリー40ステージを盛り込んでも、コアゲームメカニクスが「画面の違いを見つける」一点に収束している ため、Apple のレビュアーから見れば短時間で消費し尽くせるカジュアルゲームの域を出ない と捉えられたのだと考えています。
これは「実装が悪かった」ではなく、企画の骨格そのもの に対する評価です。同じガイドラインで弾かれるアプリの多くは、機能を追加する形では再申請を通せず、コンセプトレベルから組み直す必要 があります。Eightpost の場合も「異変探しを軸にして、その上に何を乗せるか」を再設計する覚悟が必要で、その判断がまだついていない状態です。
学んだこと
1. Minimum Functionality は「機能の量」ではなく「遊びの深さ」を問うている
20種の異変や5エピソードのストーリーがあっても、プレイヤーがやることが本質的に1種類 であれば足りないと判定される。「機能数」ではなく「ゲームとしての厚み」が評価軸でした。
2. 単純なメカニクスは、上に乗せる体験で勝負する
似たメカニクスでもリリースされている作品は数多くあります。それらは ストーリー、世界観、操作の触感、レベルデザイン のどこかで「もう一度プレイしたい」を作っています。Eightpost は、ストーリーは用意したが、ゲームとしてのリプレイ性が弱かった のが本当の弱点でした。
3. 審査リジェクトは、企画レビューを兼ねている
リリースを目指して走り切ると、自分のアイデアの 構造的な弱さ に気付きづらくなります。Apple のレビュー結果は厳しいですが、「外部から客観的にコンセプトをレビューされた」と捉え直すと、未来の企画にとって貴重な指摘 になります。
4. 「出せなかった作品」も、書くことで意味を持つ
リリースされなかったアプリは存在しなかったのと同じ、ではありません。こうして失敗を言語化すれば、次の企画者の参考になる し、自分自身の判断軸も鋭くなります。AnomalyType enum や Episode / StoryPage のデータ構造、SwiftUI Preview ベースの設計手法は、別のゲーム企画にも転用できます。
おわりに
Eightpost は 製品としては失敗 しましたが、個人開発者として次に進むための学び は十分すぎるほど得られました。AI のおかげで実装スピードが上がった今だからこそ、「作る前に、これは Minimum Functionality で弾かれない遊びの厚みがあるか」と自問するクセが、これからのリリース戦略の鍵になると感じています。
同じガイドライン4.2でリジェクトされた個人開発者の方、これから審査に挑む方の参考になれば幸いです。