実装より宣伝のほうが止まる
個人開発を続けていて、一番時間が溶けるのは実装ではありませんでした。リリースしたあとの告知です。
コードは書き終わっている。あとは「こういうアプリを作りました」と書くだけ。それが書けないまま数日たって、結局は一言だけ投稿して終わる。作ったものは増えるのに、誰にも知られないまま積み上がっていきます。
原因を分解すると、宣伝そのものが難しいというより、宣伝のたびにアプリの説明をゼロから書き起こしていることが問題でした。
宣伝素材は、どれも同じ情報の言い換え
Xのポスト、noteの紹介記事、App Store提出用のスクリーンショット。媒体はバラバラですが、載せる情報はほぼ同じです。
何ができるアプリか。誰の何が楽になるか。他と何が違うか。長さとトーンが違うだけで、元ネタは共通しています。
そして、その元ネタは最初から手元にあります。READMEです。
READMEを開発ドキュメントから一次情報に格上げする
READMEは普通、開発者向けのドキュメントとして書きます。ただ中身を見ると、宣伝に必要な情報はだいたい入っています。何のアプリか、何ができるか、どう使うか、制限は何か。足りないのは「読者が開発者ではない」という視点だけです。
そこで、READMEをそのアプリについての一次情報として扱うことにしました。運用ルールはひとつです。
リリースする前に、必ずREADMEを最新にする。
Vercelへのデプロイも、TestFlightへのアップロードも、READMEの更新とコミット、pushを済ませてから実行する。順番を逆にしない。「あとで直す」を一度許すと、READMEはすぐに嘘をつき始めます。
AIに渡す前提でREADMEを書く
一次情報として扱うと決めると、READMEの書き方も少し変わります。意識しているのは次の3点です。
冒頭の1〜2行で「何をするアプリか」を言い切ること。ここがそのままキャッチコピーの素になります。機能を並べるときは、実装ではなく「ユーザーが得られること」で書くこと。そして制限や料金は表にしておくこと。ここが曖昧だと、生成された文章もぼやけます。
READMEを人間向けの説明として整えるほど、そこから作れる宣伝素材の質が上がります。ドキュメントを書く手間と宣伝の手間が同じ作業に統合されるのが、この運用のいちばんの効きどころです。
READMEから3種類の素材を作る
いまは、READMEのあるリポジトリのURLを渡すと次の3つが出てくる状態にしています。
ひとつめはX向けのポストで、切り口を変えた複数パターン。ふたつめはnoteに貼れる紹介記事の下書き。みっつめはApp Store提出用スクリーンショットの見出しコピーとレイアウトです。
ゼロから書くと1日仕事ですが、出てきた文章に手を入れるだけなら15分で終わります。「ゼロ→1」を「70→100」に変えたのが、いちばん効きました。
多言語も、翻訳ではなく書き直しにする
同じ考え方は多言語にもそのまま効きます。日本語の告知を機械翻訳にかけると、どうしても不自然な文章になります。元がREADMEなら、翻訳ではなく「その言語で書き直す」ことができます。
XのポストとApp Storeスクショの見出しは、日本語・英語・スペイン語・簡体字中国語・繁体字中国語・フランス語・ドイツ語・韓国語の8言語で生成しています。日本語版を訳したものではなく、同じREADMEからそれぞれの言語で書き起こしたものです。海外向けに出すハードルは、ここでかなり下がりました。
宣伝を「気合い」から「手順」に変える
やっていることをまとめると、こうなります。
リリース前にREADMEを最新にする。READMEを一次情報として媒体ごとの素材を生成する。生成物に手を入れて出す。
気合いでやっていた部分を手順に置き換えただけですが、宣伝が「あとでやる特別なタスク」ではなくリリース作業の一部になりました。作ったものが誰にも知られないまま終わる、という一番もったいない状態はかなり減っています。
使っているツール
この流れを自分用に自動化したのが Code Tweet です。GitHubリポジトリのURLを貼るとREADMEを読み取り、X向けポスト・note記事の下書き・App Store提出用スクリーンショットを生成します。ログイン不要で3回まで試せます。
技術構成は Next.js App Router 16 / React 19 / TypeScript / Tailwind CSS v4 / Supabase / Gemini API / Stripe / Vercel です。
ツールを使わなくても、「リリース前にREADMEを更新する」を手順に入れるだけで宣伝の手間はかなり変わります。まずはそこからおすすめです。