ID:81219さん

## プロジェクト概要 アドリブ演奏やジャズギターを志す学習者が、実機のエレキギターをコントローラーとして使用し、ゲーム感覚で指板（フレットボード）の音名/度数/コード・トーン/スケールを習得できるWebアプリケーション。 「知識としての音名」を「楽器上の位置」に直結させることを目的とし、既存の座学中心の学習効率を改善するために開発。当初はElectronで着手したが、マルチプラットフォーム展開とパフォーマンスを考慮し、Next.js + Phaser 3の構成へ移行。また、個人開発の制約を突破するためマルチモーダルAIをフル活用。nano banana pro（画像）、Kling AI（動画）、Suno AI（BGM）を組み合わせた独自のストーリーラインを構築し、単なる学習ツールに留まらない「没入型ゲーム体験」を実現。 リンク：[Guitar Trek](https://guitartrek.pages.dev/ja) ゲーム選択：[ゲーム選択画面](https://guitartrek.pages.dev/ja/game) プレイグラウンド：[Playground](https://guitartrek.pages.dev/ja/playground) ## 開発・実装内容A：機械学習を用いた弦の判定 【どのような機能の開発・実装か】 - リアルタイム・ピッチ解析機能: Web Audio APIを活用し、マイク入力からギターの周波数を解析。特定したピッチをゲーム内座標や正解データと照合する判定ロジックの実装。 - インタラクティブな学習ステージ: 指板をタイピングゲームのように攻略する仕組み。音名（単一/複数弦）、度数、トライアド、コードトーン、スケールといった音楽理論に基づいた段階的なステージ構成。 - ゲームエンジンによるUX構築: Phaser 3を採用し、複雑な指板の描画と高速な描画更新を両立。 - 生成AIによる世界観演出: ユーザーのモチベーション維持のため、Image Generation（画像）やVideo Generation（BGM/動画）を活用したストーリー性と独自の世界観を構築。 - サーバーレスな基盤構築: Supabase（Auth / Functions）を用いた認証基盤およびロジックの実装。 【課題・問題点】 - 異弦同音の判定精度: ギターの構造上、異なる弦で同じ音高（ピッチ）が存在するため、単なる周波数解析だけでは「どの弦を弾いたか」を一意に特定できず、ゲームとしての判定ロジックが成立しなかった。 - 機械学習によるアプローチの限界: 弦ごとの倍音構成（h2/h1比）やスペクトル中心（Mel Centroid）等の特徴量に着目し、自らフロント/リア・指/ピック弾きなど膨大な学習データを作成。ONNX形式でのフロントエンド実装を試みたが、個体差や環境ノイズの影響を排除しきれず、実用レベルの判定精度（100%に近い精度）に到達することが困難であった。 - 開発リソースの配分: 個人開発において、判定モデルの精度向上にリソースを集中しすぎることで、本来の目的である「学習体験の提供」というプロダクト全体の完成が遅延するリスクが生じた。 【打ち手・使用した技術】 - 技術的負債の回避と仕様による解決: 機械学習による弦判定の不確実性を排除するため、学習範囲を「CAGEDシステム」等に基づく特定のポジション（ボックス）に限定。これにより、ピッチから弦が一意に定まるロジックへと転換し、判定精度100%を担保した。 - フロントエンド・パフォーマンスの最適化: 重い推論モデル（ONNX）の使用を止め、Web Audio APIによる軽量な周波数解析へシフト。Next.js と Phaser 3 を組み合わせることで、低レイテンシかつ滑らかなゲーム体験を実現した。 - 生成AIを活用した資産制作の効率化: 個人開発の限られたリソースをロジック開発に集中させるため、nano banana や suno AI を活用。高品質な画像・BGMを短期間で生成し、プロダクトの世界観とユーザーの継続率（UX）を向上させた。 - サーバーレスアーキテクチャの採用: Supabase（Auth / Functions）を採用し、認証やバックエンドロジックをマネージドサービスへ寄せることで、フロントエンド開発とゲームロジックのブラッシュアップに注力できる環境を構築した。 ## 開発・実装内容B：Web Audioの低レイヤー実装による低遅延解析基盤 【概要】 ブラウザ上で楽器の音を遅延なく解析し、ユーザーが「弾いた瞬間に判定される」ストレスフリーなゲーム体験を実現するための音声処理基盤の構築。 【どのような機能の開発・実装か】 - AudioWorkletによるスレッド分離: 音声解析ロジックをメインスレッドから分離し、描画負荷（Phaser 3）の影響を受けない解析パイプラインを構築。 - Ring Bufferを用いたデータ転送: SharedArrayBuffer と Ring Buffer を実装し、スレッド間でのデータ競合を避けつつ最小限のオーバーヘッドで解析データを転送。 【課題・問題点】 - 音響工学的な専門知識の不足: 窓関数（Hann window等）の適用や、ノイズによる誤検知の抑制など、Webフロントエンドの知識だけでは解決できない低レイヤーかつ数学的な実装が求められた。 - AudioWorkletの複雑なデバッグ: ブラウザ固有の挙動や、ライフサイクルの理解、音声処理特有のデバッグの難しさがあった。 - 低音域の判定には時間がかかる: ギターの低い音を正確に判別するには、一定時間の音データを溜めてから解析する必要がある。しかし、これを愚直に行うと「弾いてから画面が反応するまで」に約0.1秒（93ms）以上のズレが生じ、リズムゲームとして致命的な違和感となってしまう。 【打ち手・使用した技術】 - 生成AIを技術パートナーとした爆速開発: AudioWorkletの仕様理解や窓関数の実装において、生成AIを高度な壁打ち相手・コード生成パートナーとして徹底活用。AIとの対話を通じて難解な音響工学の概念を短期間でプロダクトに落とし込み、低レイテンシな解析基盤を独力で構築した。 - 2つの解析ライン（長窓・短窓）の並列実行: ギターの低域を正確に捉えるための「長窓（4096サンプル）」と、発音の瞬間を捉える「短窓（1024サンプル）」を、AudioWorklet内で同時に走らせる仕組みを構築。 - 役割分担によるレイテンシ解消: 短窓で音量変化（RMS）を監視して「弾いた瞬間」をミリ秒単位で即座に検知しつつ、長窓で確定させた「正確な音程」を後から紐付けるロジックを実装。 - デジタル信号処理（DSP）の最適化: AIのサポートを得ながら特定の周波数帯域外をカットするフィルタリングを実装し、実用的な精度でのリアルタイム・ピッチ判定を実現した。 ## 開発・実装内容C：グローバル展開を見据えた多言語化と決済基盤の実装 【概要】 世界中のギタリストをターゲットとするため、リリース初期から多言語対応（日本語・英語）を設計。また、サービスの持続的な運用を目的としたStripeによる収益化基盤を構築。 【どのような機能の開発・実装か】 - i18nextによる多言語対応: Next.jsとi18nextを組み合わせ、言語切り替え機能およびSEOを考慮した言語別ディレクトリ構成を実装。 - Stripeによる決済・サブスクリプション: Stripe Checkoutを用いたセキュアな決済フローと、顧客ポータルによるプラン管理機能を導入。 - 課金状態のリアルタイム同期: StripeのWebhookをSupabase Edge Functionsで処理し、ユーザーの権限（Proプラン等）をDBへ即時反映させるバックエンドロジックを構築。 【課題・問題点】 - 運用の持続可能性: 個人開発において、サーバー代やAPI利用料を賄うための収益化モデルが不可欠であったが、同時に決済情報の取り扱いにおける高いセキュリティレベルの維持が求められた。 - 開発リソースと市場性の両立: 複雑な決済仕様や言語別のコンテンツ管理に時間を取られ、メインの学習ロジックの開発が停滞するリスクがあった。 【打ち手・使用した技術】 - ビジネス視点での技術選定: 自前での課金管理や翻訳基盤の構築を避け、Stripeやi18nextといったデファクトスタンダードを採用。セキュリティリスクを外部へ委ねつつ、コア機能の開発にリソースを集中させた。 - 生成AIと自身の語学力を組み合わせたローカライズ: 音楽用語特有のニュアンスを含んだ英語翻訳において、生成AIと自身の英語力を生かした。専門用語の不一致を防ぎつつ、短期間で高品質なグローバル対応を実現した。 - マネージドサービスの活用による低コスト運用: StripeのホスティングUI（Checkout/Portal）をフル活用し、決済画面の実装コストを最小化。これにより、個人開発ながらもエンタープライズレベルの堅牢な決済体験を提供した。

## プロジェクト概要 楽器演奏者や音楽愛好家が、自身の演奏動画や愛用楽器のこだわりをシェアし、音楽仲間と繋がることができる音楽特化型SNS。 約2年前にFlutterで開発した旧バージョンをベースに、ユーザー体験の向上とスケーラビリティを確保するため、モダンな技術スタックを用いてフルリビルドを実施。企画からデザイン、フロントエンド、バックエンド開発まで一貫して担当している。 リンク：[https://apps.apple.com/jp/app/muuuzin/id6744232472](https://apps.apple.com/jp/app/muuuzin/id6744232472) ## 使用技術 【フロントエンド】 Flutter, Provider, TypeScript, YouTube Data API 【バックエンド / インフラ】 - Supabase (Database, Auth, Storage, Edge Functions), Firebase (FCM, Remote Config) - Google Cloud (Google Auth (OAuth 2.0), Vision API, Generative Language API) - Resend (Email Delivery), Squarespace (DNS Management) ## 開発・実装内容A：Flutterによるマルチプラットフォーム展開と機能の大幅拡充 【概要】 ユーザー層の拡大を目指し、iOS専用だった旧アプリをAndroidにも対応。同時に、画像共有のみだったシンプルな構成から、動画投稿やチャットを備えた総合音楽コミュニティへとフルリビルドを実施。 【どのような機能の開発・実装か】 - Android/iOSの同時リリース: Flutterの特性を活かし、両OSで一貫したUI/UXを提供するクロスプラットフォーム開発を完遂。 - YouTube連携による動画共有機能: YouTube Data APIを活用し、自身の演奏動画をシームレスに投稿・閲覧できる機能を新規実装。 - チャット・コミュニティ機能: ユーザー同士の交流を加速させるリアルタイムチャットや、バンドメンバー募集機能をゼロから構築。 【課題・問題点】 - プラットフォーム間の差異と保守性: 異なるOSで同等の体験を提供しつつ、機能拡充に伴うコードの肥大化と複雑性の増大をどう抑えるかが課題となった。 - SNSに不向きな旧基盤: NoSQL（Firebase）では、複雑なリレーションを持つSNS機能（チャット、メンバー募集、フォロー関係等）の実装が煩雑になり、拡張性に限界があった。 【打ち手・使用した技術】 - Supabaseへの基盤移行とRDB活用: 2025年3月、SNS開発に適したリレーショナルデータベースを持つSupabaseへ移行。複雑なデータ構造を整理し、機能拡張が容易な環境を構築。 - 生成AIによる開発加速: 膨大な新機能の実装や基盤移行において、最新の生成AIをコード生成・リファクタリングのパートナーとしてフル活用。開発スピードを極限まで高め、短期間（約1ヶ月）でのフルリビルドを実現した。 - クリーンアーキテクチャによる分離: 機能を大幅に増やしつつ保守性を保つため、リポジトリ層とサービス層を明確に分離。各機能の独立性を高め、Android/iOS両OSでの安定した動作を担保した。 ## 開発・実装内容B：外部API連携によるリッチな機能実装と運用コストの最適化 【概要】 個人開発におけるインフラコストを最小化しつつ、大手SNSに劣らない利便性と安全性を確保するための外部サービス連携。 【課題・問題点】 - ホスティングコストと負荷: 高画質な演奏動画を自前で配信・管理することは、ストレージコストやネットワーク帯域の面で個人開発の範疇を超えていた。 - コミュニティの健全性確保: ユーザー投稿型SNSとして、24時間体制での不適切な画像・動画の監視体制を個人で構築する必要があった。 【打ち手・使用した技術】 - YouTube Data APIによる動画管理の外部化: ユーザーのYouTubeアカウントから動画を選択・表示する仕組みを構築。ホスティングコストをゼロにしつつ、高品質な再生体験を提供。 - Google Vision APIによる自動検閲システム: Supabase Functions（Edge Functions）を介して画像解析APIと連携。投稿時に不適切コンテンツを自動判定・排除するセーフティ機能を実装した。

▼担当業務 ・JAMStack（Contentful + Next.js）を使ったLPサイト開発 ・フロントエンドテスト、パッケージ管理、バグ対応 ▼実績・取り組み LPをContentful＋Next.js（SSG）で構築し、JAMStackによる高速化と運用効率を実現。GitHub Actionsによる自動デプロイを導入し、公開フローを自動化。 UI改善とテスト追加を通じて安定したサイト運用に貢献。