ヒットしたアプリの「次のバージョン」は、新規開発とは違う難しさがあります。すでにいるユーザーを壊せないからです。

題材は、私たちが自社で開発・運用しているギターアプリ 「Sing With Guitar」 です。1.0は「ギターコードの押さえ方を調べて、音で確かめられる」だけのシンプルなアプリでしたが、App Storeの有料・音楽カテゴリで1位を獲得しました。本記事は、その2.0——コード譜を作って、リアルなストロークで伴奏を鳴らせる大型アップデート——で私たちが何を判断したかの記録です。

📝 3行まとめ
① 1.0の勝因は「機能を絞ったこと」。2.0はユーザーの声から「調べる→作って鳴らせる」へ拡張しました。
② 音楽アプリの生命線はリズム。フレーム時間で音を鳴らすと必ずズレるので、オーディオクロック基準の再生エンジンを設計しました。
③ 大型アップデートの鉄則は「セーブデータと操作の互換」。多言語化ですらデータを壊さない設計にしています。

1.0が1位を取れた理由と、その限界

1.0の機能は本当にこれだけでした。ルート音とコードタイプを選ぶと押さえ方(ヴォイシング)が一覧で出て、タップすると音が鳴る。

競合のコードアプリは多機能です。それでも1位を取れたのは、「コードの音を、広告に邪魔されず、すぐ確かめたい」 という1つの用途に絞って、その体験だけを磨いたからだと分析しています。

一方でレビューやお問い合わせで一番多かったのは「調べたコードで、そのまま曲を練習したい」という声でした。コードが分かっても、どんなリズムで弾けばいいかが分からない。ここが弾き語り初心者の本当の壁です。

そこで2.0の核を「音の出るコード譜」に定めました。コードを並べ、ストロークパターンを選ぶだけで、アプリが伴奏を弾いてくれる。ユーザーは歌に集中できる、という設計です。

リズムのズレと戦う ― 音楽アプリのオーディオ設計

2.0開発で最も時間を使ったのがここです。結論から言うと、ゲームのフレーム処理で音を鳴らすと、音楽としては使い物になりません。

問題①：フレーム時間はリズムを刻めない

Unityで「一定間隔で音を鳴らす」を素朴に書くと、毎フレーム時刻を見て発音する実装になります。しかしスマホの描画は30〜60fps、つまり音のタイミングが最大33ミリ秒単位でしか制御できない。テンポ160の16分音符は間隔93ミリ秒ですから、3分の1がズレうる計算です。人間の耳はリズムの揺れに敏感で、これは確実に「ヨレて」聞こえます。

対策は、発音をオーディオハードウェアのクロック（DSPタイム）基準に移すことです。私たちは再生エンジンを二層に分けました。

  • 音：小節の頭で、その小節の全ストロークをオーディオスレッドに予約。発音開始は1/44100秒単位で正確
  • 画面：ハイライトや小節表示はフレーム時間で追従（多少揺れても人間には分からない）

こうすると、画面がカクついても音のグリッドは一切揺れません。逆に言うと、この分離をしていない音楽アプリは、端末の負荷がそのまま演奏の下手さになって聞こえます。

問題②：「本物らしさ」は物理の数字に宿る

ギターのストロークは6本の弦を順番に弾く動作です。この「掃く速さ」を実測に寄せると、リズム弾きは1ストローク15〜45ミリ秒。ここを外すと、速すぎれば機械のように、遅すぎればハープのアルペジオのように聞こえます。

さらに細かい話をすると、実際の奏者はアップストロークで低音弦を弾きません。手首を返す動作では高音側の3〜4本を軽く撫でるだけ。2.0のエンジンはこれも再現していて、ダウンとアップで音色の重さが変わります。アクセント記号のあるストロークは掃く速度も上がります。

💡 発注者の方へ：「音がなんかショボい」という感想の正体は、多くの場合こうした数十ミリ秒単位の物理です。音源の質を上げる前に、タイミングと奏法の再現を疑う。ここはオーディオ系アプリを受託するときに、私たちが最初に確認するポイントです。

壊さないアップデート ― データ互換の設計

2.0では譜面の保存・書き出し・読み込み、カスタムストロークパターン、そして英語対応を追加しました。地味ですが、ここに大型アップデートの本丸があります。

  • 譜面の書き出しはバージョン番号付きの独自形式にしました。将来3.0で形式を変えても、古いファイルを読む道と「新しいバージョンです。更新してください」と案内する道の両方が最初から用意されています
  • 書き出した譜面には、そこで使っている自作ストロークパターンを同梱します。ファイルを1個渡せば、相手の端末でも同じ演奏が鳴る
  • 英語対応は、内部の識別子と保存データを従来のまま固定し、画面に出す瞬間だけ翻訳する方式にしました。言語を切り替えてもセーブデータの移行は不要で、日英のユーザー間で譜面ファイルを交換しても正しく動きます
💡 発注者の方へ：多言語化の見積もりで差が出るのはここです。文字列を置き換えるだけの実装は、保存データに言語が混ざって後から必ず事故になります。「何を翻訳し、何を絶対に翻訳しないか」の線引きが、多言語化設計の実質のすべてです。

Unity 6 × モバイルの落とし穴を3つ

同業の方と、Unityでのアプリ開発を検討中の方向けに、今回踏んだ罠を共有します。

  1. 実行時生成のPanelSettingsは実機で真っ黒になる。UI Toolkitの描画設定をコードで生成すると、エディタでは動くのに実機ではシェーダー参照が空になり何も描画されません。必ずアセットとして保存したものを使う
  2. セーフエリアは自前対応。UI Toolkitはノッチやホームインジケータを避けてくれません。Screen.safeAreaをパネル座標系に変換して適用し、回転時の再計算も自分で書く必要があります
  3. スケーリングの基準解像度は端末クラスで切り替える。デスクトップ基準のままだとiPhoneでボタンが約20ポイント相当まで縮み、タップできません。Appleのガイドラインは44ポイント以上。私たちは縦持ち・横持ちで基準辺を切り替える実装にしました

まとめ ― 「2.0」は信頼の再投資

1.0のヒットは「絞る」判断の成果でした。2.0は、その信頼を壊さずに「広げる」判断の連続です。

  • ユーザーの声から次の1機能を決める（全部やらない）
  • 音楽アプリの生命線であるリズム精度に、工数を惜しまない
  • データ互換と多言語化は、最初から「壊さない」設計にする

Sing With Guitar 2.0は現在App Storeで配信中です。コードを3つ並べてストロークを選ぶだけで伴奏が鳴り出す体験は、ぜひ実物で試してみてください。