毎日ダウンロードを失うスクリーンショットの間違い

iOSとmacOSのアプリをしばらく作ってきたけれど、公開したあとにいつも間違えていたことがある。スクリーンショットだ。

私はスクリーンショットをデザインの作業だと思っていた。良さそうな画面を5つ選び、機能を説明する文字を重ね、必要なサイズで書き出す。これで完了。ところがダウンロードは横ばいだった（例：Super Easy Slides）。

Theodoraから学んだのは、スクリーンショットの効果の70%はUIではなく文字の見出しで決まるということだ。あるアプリは、既存スクリーンショットのコピーを書き直しただけで成約率が80%上がった。

デザインは変わっていない。変わったのは言葉だけだ。

これが、ほとんどの開発者が直さないポイントだ。

フルの手順が欲しい？　App Storeスクリーンショット最適化プレイブックをダウンロードしてほしい。スクリーンショットを1,000枚以上手がけた専門家DesignerAntsの知見から、100のベストプラクティスをまとめた。ClaudeやCodexに入れて、今日の午後に掲載内容を直せる。

彼女に全部やってもらいたい？　Theodoraを雇う →

この間違いは起きやすい。作り込みの最中はアプリを隅々まで理解している。だからスクリーンショットの文字を書くときも、自然と「アプリが何をするか」を説明してしまう。

「ダークモード対応」「iCloud同期」「カスタマイズ可能なウィジェット」——どれも本当だ。でも、そのアプリがなぜ必要なのかを知らない人にとっては、まったく役に立たない。

機能説明は、間違った問いに答えている。App Storeページを流し見している人が知りたいのは「このアプリは何をするの？」ではなく、「これは自分のためのもの？」だ。機能の羅列では答えにならない。

あなたのスクリーンショットは、まだ買う気になっていない人からすると、更新履歴のように読めてしまう。

実際に効くのはこれだ。考え方を変える。機能を説明するのをやめて、ユーザーに起きる変化を見せる。

「カスタマイズ可能なダッシュボード」ではなく、「大事なことが一目でわかる」。

別の例。「ワークアウト記録」ではなく、「次に何を持ち上げたか、もう忘れない」。

同じアプリ。同じ画面。ダウンロード率だけが変わる。

なぜ効くのか。具体性が、約束を現実にするからだ。「生産性アプリ」は目に入らない。「会議のメモを二度と失くさない」は、ダウンロードする理由になる。アプリを使ったあとの生活をより正確に描くほど、ユーザーは自分が使う姿を想像できる。

UIを手で隠して、文字だけを読んでみてほしい。物語になっているか？ それとも機能のリストか？

多くのアプリはこのテストにすぐ落ちる。私のもそうだった。

成約する並びがある。スクリーンショットは順番に読んで初めて意味が通るべきだ。どの順番でも成立するなら、それは物語ではなくカタログだ。

DesignerAntsが勧める並びはこうだ。

スクリーンショット1：痛みを言語化する。見つける前の苛立ちを描く（例：「二度と見つからないメモに埋もれてない？」）。

スクリーンショット2：変化を宣言する。使うと何が変わるのか（例：「記録したものが自動で整理される」）。

スクリーンショット3：証拠を見せる。数字、利用者、具体的な結果（例：「毎日1万人の開発者が使用」）。

スクリーンショット4〜5：機能で届ける。2枚目の約束を実現する、1〜2個の能力だけを見せる。

各スクリーンショットは1つの仕事だけをする。1つのメッセージだけ。2文必要なら、2枚に分ける。

もう1つのルール：文字が商品だ。

UIは証拠で、文字は主張だ。

デザインを始める前に、各スクリーンショットの見出しを書く。8語で変化が言えないなら、まだ理解できていない。次に、その見出しの視覚的な証拠としてUIを置く。

言葉を商品として扱う。その他はすべて補助材料だ。

私が出したものと、今なら出すもの。私はこのアプリを公開するつもりはなかった。自分用に作っただけだ。

でも友人に聞かれて、スクリーンショットの戦術を知る前に、急いでApp Storeの販売ページを作った。

Super Easy Slidesが最初に出したコピーはこうだ。

Notes → Slides. Instantly. Full Screen Always Readable. Slides Over Any App. Auto-Numbering that Works.

当時はこれで良いと思っていた。意図はこうだ。

・アプリが何をするかを明確に説明する ・主要機能を強調する ・シンプルで直接的にする

紙の上では筋が通っている。

何が悪いのか。今見ると問題は明白だ。

・商品は説明しているが、売っていない ・見出しではなく機能ラベルに見える ・痛みや動機がない ・注意を引いてスクロールを止められない ・なぜ重要かをユーザーが既に理解している前提になっている

私の間違いはこれだ。アプリが何をするかに集中して、なぜ欲しいのかを描かなかった。

見落としていたルール。Theodoraのやり方では、各スクリーンショットは広告のように機能するべきだ。

つまり、痛みや欲求を先に置き、結果を見せ、機能で裏付ける。逆ではない。

私ならこう書き換える。

Before：Notes → Slides. Instantly. After：Stop Designing Slides Write notes. Start presenting.

Before：Full Screen Always Readable After：Stay Focused While You Present Clean slides. No distractions.

Before：Slides Over Any App After：Stay In Your Flow Present without breaking your momentum.

Before：Auto-Numbering that Works After：Never Fix Slides Manually Again Your structure stays clean automatically.

なぜこちらの方が良いのか。新しい版は、実装ではなく結果から始める。非開発者にも一瞬で伝わる。時間、集中、明瞭さといった現実の痛みに接続する。機能は見出しではなく裏付けになる。

今週やること。デザイナーはいらない。必要なのは午後の数時間だ。スクリーンショットを開き、UIを隠し、見出しだけを声に出して読む。機能リストのように聞こえるものは書き直す。それから30日間新しい版を回し、App Analyticsで成約率を確認する。

1回の書き換えセッションは、何カ月ものキーワード調整より多くを教えてくれる。

100のベストプラクティス。これらはDesignerAntsの知見から来ている。彼女は1,000枚以上のスクリーンショットを最適化し、あるアプリでは成約率を80%引き上げた。

私はそれを無料PDF「100 App Store Screenshot Best Practices」にまとめた。ClaudeやCodexに入れて、今日中に掲載内容を書き換えてほしい。

AIツールでiOS/macOSアプリを作っている？ CodexとXcodeで使っている作業手順を書いている。@PaulSolt をフォローしてほしい。