バイブコードing

https://github.com/shiomizu0620/vibe-receiver

Python

Flutter

Dart

バイブコードをingするプロダクトです。

しおみず

abe

1rou

推しアイデア

スマホの振動でURLを開けます。QRコードに変わる新たな1次元コード、バイブコードの誕生です。

作った背景

バイブレーションでURLを開くのが面白そうだと思ったからです。

推し技術

送信Flutter・受信Pythonで、振動を信号処理→復調→DB逆引きする自作プロトコルです。短/長で0/1、プリアンブルで同期をしてます。

プロジェクト詳細

プロダクト概要

スマホの「振動」でURLを開くプロダクトです。

ひとことで言うと、「QRコードを、カメラと光の代わりに"振動"でやる」ということです。

推し機能

振動版のQRコード

光で読むQRコードを振動で再現しました。 QRコードが持つ二つの形式を実装しています。

  1. URLの文字列を01に変換して、長短の振動として送信する形式:この形式だと文字列をそのまま変換しているのでサーバー要らずで本来のQRコードの形式に近い。しかし振動を送る回数が非常に多くなってしまい、300回以上振動を送ることもある。
  2. URLをDBに保存し、IDを発行して振動で送る形式:この形式は送信側でURLをDBに送りIDを貰い、その振動を受信側でIDからURLを参照。この形式は圧縮QRコードに近い、これはDBを通す代わりに振動の数は減り約10回程度の振動で済む。

QRコードを振動に翻訳 QRコードを読み取ってそれを上記の1の形式で振動に変換する機能です。一見QRコードを読み取っているので何の意味もない機能ですが、QRコードと「バイブコード」が同じデータを運ぶ証拠になってくれました。

全体構成

[送信側] スマホ(Flutter) 楽譜表示・手動/自動演奏・振動制御 ↓ 振動(短/長) [物理] ピエゾ(接触振動センサー) ↓ 音声入力 [受信側] PC(Python) 録音 → 信号処理 → 復調 → DB逆引き → 演出 ↕ [データ] Supabase(番号↔URL の対応表)

技術構成(詳細)

フロントエンド:スマホアプリ(送信側image バックエンド:受信プログラム(受信側image データ管理 image 通信プロトコル(自作 v1.0) image 開発インフラ image

技術の選定理由

Flutter(送信側)

・ Flutterのvibrationパッケージは、パターン(短150ms/長450ms)を直接ミリ秒指定で出せる。ReactNativeでも振動はできるけど、ライブラリの成熟度や細かい制御という点では Flutterの方が扱いやすい。

・チームの習熟度が一番高かった。今回のチームの3人ともflutterでの開発を半年以上続けており比較的慣れているため、ハッカソンで一番絶望する、「慣れてない技術で詰まる」リスクを避けた。

Python(受信側)

・信号処理ライブラリが圧倒的に充実してるから。受信側がやるのは「音の波形 → バンドパスフィルタ → 包絡線 → ON/OFF検出」という信号処理(DSP)。pythonが圧倒的に向いているから。

・録音・DB・ブラウザ操作まで全部ライブラリで揃うから

工夫した点

短期間・3人開発でも破綻しないよう、最初に開発の仕組みそのものを整えました。

  • 詳細なロードマップ/開発マップ:データの流れや担当ごとの作業順・レーンをまたぐ「待ち合わせ(依存)」を1枚の図にまとめて、GitHub Pages で全員が見られるよう公開した。誰が・どの順で・何を作るかを常に共有できる状態にした。 ↓(URL) https://shiomizu0620.github.io/vibe_code_sender/vibecode_map.html
  • issue を細かく起票:各タスクを「単独で完了判定できる」粒度まで分解し、本文に作業内容・完了条件・依存・触ってよいファイルまで明記した。番号順に1つずつ消化すれば依存が壊れない設計にした。 ↓タスクボードURL https://github.com/users/shiomizu0620/projects/3
  • 担当ファイルの境界を明確化:ロジック担当・UI担当・受信担当で「触ってよいファイル」を分け、並行作業でもコンフリクトが起きにくいアーキテクチャにした。
  • CodeRabbit による自動コードレビュー:PR ごとに AI が自動レビュー。実際に複数の指摘(CIの収集エラー対策、スレッドの後始末、想定外エラーの握り潰し防止など)を受けて修正でき、レビュー負荷を下げつつ品質を保てた。今回初めて導入したけど入れて良かったなと感じた。 image
  • CI/CD・通知の整備:GitHub Actions でテスト自動化、PR を Discord に通知してレビュー待ちのラグを削減

いつもよりも事前開発を早めに行い、タスクの管理や全員での開発のしやすい体制作りなどをいつもよりも重視したため、本番では切羽詰まりすぎづ、スムーズな開発ができたなと感じました。

苦労した点

今回苦労した点は

  • pythonを触るのが初めて
  • 振動も読み取り側も闘値が弱すぎて途中で詰んだ
  • 持っていたandroidの機種が古くてバイブレーションを大きくする機能に対応してなかった

その中でも一番苦労したのは

  • 振動も読み取り側も闘値が弱すぎて途中で詰んだ

です。  これに関してはそもそもの内臓マイクの問題だったりデバイスの問題だったりするので、めちゃくちゃ調べたりAIに聞いたりしても無理でした。 世にも珍しい「技術的に不可能です」という状態です。(もしかしたら調べ足りないだけかも)。

ということでこれに対応するために、ピエゾマイクというデバイスを買いました。 ↓購入したピエゾマイクのamazonURL https://x.gd/nfjFE

一言で言うと、空気の振動ではなく「物体そのものの振動」を拾って電気信号に変換するマイクです。 これを利用することでバイブをより感度高く感知することができるし、音ではなく振動を検知することになり、バイブのイメージに合わせることもできました。

しかし、ピエゾマイクがなぜか全然振動を読み取ってもらえないという問題が発覚し、ほかのものを買いに行く時間もなかったため、死ぬほど困りました。

↓下から二番目が振動の検知なのですが、死んでる様子です。 image が、奇跡が起こりなぜか端子を半刺しすると音声が読み取られるということに気づき一命をとりとめました。これに気づいたときは叫びました。

↓完璧に読み取れてる様子 image

ただピエゾマイクを買うということや、半刺しならいけるという結論に達するまでにかなり時間がかかったし、ピエゾマイクの仕様を知ろうとして、多くの時間を費やしてしまいました。 ただ、試行錯誤ができたため、いい経験にはなったと思います。

しおみず

@shiomizu0620