PatchMemo GXの開発手法──vibe codingで個人アプリを作るまでの全工程
はじめに
BOSS GX-1というエレキギター用の機材があります。私はギタリストで、その機材のユーザーなのですが、そのBOSS GX-1に特化したファンアプリ「PatchMemo GX」を制作しました。
YouTubeでこの機材の解説動画を撮影する中で、自分自身のペインポイントに気づいたのがきっかけです。
パッチの管理に不便を感じていたこと、そして既存のアプリが存在しなかったこと──この2つが揃ったとき、ここにビジネスチャンスがあると感じました。
開発にはいわゆるvibe codingを全面的に活用しています。AIツールを組み合わせながら個人で一本のアプリを完成させるまでの流れを、今回はそのまま紹介します。
個人開発者の方の参考になれば幸いです。
ステップ1：仕様書をAIに読み込ませる
最初にやることは、対象機材の仕様を正確に把握することです。ただし、自分で読み込むのではありません。
BOSS GX-1の公式説明書（PDF）とHTMLサイトの情報を、GoogleのNotebookLMに渡します。
NotebookLMに仕様を完全に理解させた上で、自分がやりたいことと仕様の間にズレがないかをすり合わせていきます。
この段階では、必要な要件やアイデアを軽く壁打ちする程度で十分です。細かく詰めすぎず、方向性を簡単にまとめておきます。
ステップ2：Claude Codeでアプリ設計
NotebookLMで整理した内容を一度テキストベースに起こし、MDファイルとして保存します。
そのMDファイルをClaude Codeに読み込ませた上で、自分が考えているアプリの詳細やユーザー体験を伝えていきます。ここからが本格的な設計フェーズです。
どんなアプリにするべきか、じっくり相談して詰めていきます。まずはUX──ユーザーのどんな課題を解決するのか。次に見た目の方針、そして技術要件。
この段階での認識のすり合わせは非常に重要で、ここを雑にすると後工程で必ずツケが回ってきます。
ステップ3：モックで「自分が作ろうとしているもの」を固める
設計が固まったら、モックを作る段階に入ります。ここではUIとUXを別々のツールで検証します。
UIデザイン：Stitchで作る
StitchにはMCPがあるため、Claude Codeから直接デザインを生成させることができます。
生成されたデザインをClaude Codeにも確認させながら、UIの方向性を詰めていきます。この工程ではUIとデザインに専念します。
UX確認：Manusで動くモックを作る
UXの確認にはManusを使います。デザインは最終的にStitch側のものを採用するため、Manusではあくまで操作感の検証に専念できます。
Claude Codeに、Manusへ渡すプロンプトを作成させます。Manusが生成したモックをExpo Go経由で自分のiPhoneにダウンロードし、実際に触ってみます。
画面上では気づかなかった違和感や、仕様の認識ズレがここで見つかることも少なくありません。
なお、StitchとManusの使い分けについては「Google Stitchを活用したアプリのUIデザイン──Manus・Claude Codeとの使い分け」でも詳しく書いていますので、そちらもご参照ください。
ステップ4：UI・UXの認識をすり合わせる
モックを触った結果、認識がズレていた部分があればClaude Codeにプロンプトを修正させます。必要に応じてManusにも再度プロンプトを投げて修正を回し、Expo Goで納得がいくまで確認します。
納得がいったら、開発の本格スタートです。
ここまでの工程をしっかりやっておくことが大切で、後の開発スピードに大きく影響します。
ステップ5：本格開発
Manusの生成物を取り込む
まずManusの生成物を解凍し、Claude Codeを動かしていたディレクトリ内にフォルダごと配置します。
plan modeで解析させ（私はSuper Claudeを導入しているので、sc/analyzeコマンドを使っています）、概ね意図通りの実装になっているか軽く確認します。
Manus依存の部分を除去する
Manusが生成したコードには、不要なサーバー設定など使わない部分が含まれていることがあります。これらを取り除きます。
ここで絶対に忘れたくないのが、バンドルIDの変更です。
以前これを忘れた結果、ストア上で自分だけが目につく範囲ではありますが、バンドルIDにManusという名前が入ったまま公開してしまいました。機能には直接関係ないものの、気持ちの問題として見逃せません。
この失敗については「Manus作のアプリをApp Storeに出して学んだこと」でも触れています。
リファクタリングと機能の完成
Manusベースのコードを、Claude CodeやGeminiの知見をもとにリファクタリングしていきます。私自身は使っていませんが、GPT Codexなどを持っている方はここで併用するとさらに効率が上がるかもしれません。
Stitchで作ったデザインを反映し、細かい調整を加えながらExpo Goで確認を繰り返します。
課金機能を入れるとシミュレータの挙動がややこしくなるため、課金実装の前に機能面を完成させておくのがポイントです。
i18n（国際化）対応
i18nとは「internationalization」の略で、先頭の「i」と末尾の「n」の間に18文字あることからこう呼ばれます。Claude Codeであれば難なく実装できました。
一番面倒だったのは、各言語ごとのスクリーンショットと説明文をApp Store Connectに貼り付ける作業です。
やっていること自体はコピペなのですが、言語の数だけ繰り返す単純作業は地味に体力を削られます。
RevenueCatの課金設定
今回は課金機能を実装したため、RevenueCatの設定が必要でした。GUIのダッシュボードから自分で操作するのですが、どこで何をすればいいのかはすべてClaudeに聞いています。
ただし注意点として、Claudeは画面表示に関して予想で適当なことを言うことがあります。
あらかじめContext7などを使って正確な情報を調べさせ、ちゃんと動くコードを書かせることが重要です。ついでにApp Store Connectの設定手順もまとめて聞いておくと、後の作業がスムーズになります。
完成：PatchMemo GX
こうして出来上がったのがPatchMemo GXです。
5カ国語に対応し、課金モデルは月額制と買い切り制の両方を用意しました。さらに、20ほどの国に対して個別の価格設定を行っています。
ここで参考にしたのが、PPP（購買力平価）とビッグマック指数です。
PPPとは、各国の通貨の実質的な購買力を比較するための指標で、同じ商品を買うのに各国でいくらかかるかを示します。ビッグマック指数はその簡易版で、世界中で売られているビッグマックの価格を基準に各国の物価水準を比較するものです。
たとえば日本では月額200円に設定しましたが、アメリカでは単純な為替換算だと2ドルを割る計算になります。
しかしPPPやビッグマック指数を考慮すると、アメリカの物価水準ではそれでは安すぎるため、強気に2.49ドルとしました。日本円に換算すると割高に見えますが、現地の購買力を考えれば妥当な水準です。
当然、この価格算出もClaude Codeに行わせました。
なお、EUは国ごとに個別入力が必要で、すべて手動での登録でした。正直なところ、途中で心が折れかけました。App Store Connectでは今後ここを改善してほしいと思っています。
おわりに
このようにして、私はvibe codingを最大限に活用しながらアプリ開発を進めています。個人開発者の皆様の何らかの参考になれば幸いです。