スマホでバイブコーディングする技術
先月、東京AI祭 ハッカソンで、スマホでバイブコーディングして、賞金20万円を獲得しました。
何をどんな仕組みで作ったのか実践知を共有したいなと思います。
東京AI祭 ハッカソンは、CoreWeaveさんが公式サポーターで、GMOさんのサポートもあったようでした。Weights & Biasesについて気軽に質問したり、H100などのGPUを自由に使い倒すことができる環境でファインチューニングしたり、とても楽しい時間でした。
ハッカソンのファイナリストでは、普段から刺激をもらっている npakaさん や 元木さんを目の前にピッチできることは特別な経験でした。
改めて運営・スポンサーの皆様に感謝したいと思います。
現場検証から生まれたバイブコーディングの発想
現場の声から始まった
「JR新宿駅は工事に伴い、凹凸のマットが敷かれ、白杖で点字ブロックを探しても感触がわかりにくい」
「時間帯次第で点字ブロックの上に人が多く移動が困難」
「ホームドアがない場所だと、落ちないか不安になる」
そんな視覚障がい者の声から、取り組みは始まりました。
私は実際に白杖による移動を体験したり、点字ブロックの配置や階段での移動方法を教えてもらいました。
一緒に歩きながら、不安や不満の声を多く聞きました。
中でも印象に残ったのはこの言葉です。
「でもやっぱり一番は、ホームに降り立った時にどちらに何があるのか分からなくて、改札を抜け出すまでが大変！」
その一言に、日常の中で感じている本音があったように感じました。
話しながら、動きながらつくる
「じゃあとりあえず、たくさん話して色々試してみよう」
そんな感じで活動してきました。
当事者の方を含め、5人でチームを組み、課題のある駅ホームを実際に歩き回りました。
現場で会話しながら、スマホでバイブコーディングを始め、即デプロイ、即検証。フィードバックをもらって、また直して、アイデアを出して。
このサイクルを30分で1回転、1日10回以上デプロイして検証を重ねました。
ずっと立ちっぱなしなので、自然と足腰も鍛えられますw
共感と改善のサイクル
「冗長な案内が入ってしまうね」
「スクリーンリーダーでボタンを押すのが面倒だから、スマホを振ったらカメラ起動しない？」
そんなリアルな声をその場で反映。
気づいたことを即座に改善し、再び試す。
課題を共に感じ、解決の瞬間を一緒に喜べるこのプロセスは、開発というより共創の体験に近いものでした。
スマホだけで開発が完結するという発見
仕事でもクライアントと対面で会話しながらプロトタイプを作ることはあります。ただし基本的にはPCを使い、ローカル環境で画面を共有する感じです。
しかし今回、気づきました。PCがなくても開発はできる。
デプロイもできる。検証までスマホだけで完結する。
その手軽さと即時性に、身をもって体感し、驚きました。やっぱり想像しているだけなのと、実際にやってみるのは違うなと。
現場発のAIアプリができた
点字ブロックやホームの端を検知し、定位音や警告音で知らせたり、駅ホーム内の情報を読み取り、どちらに何があるのかを把握し、迷いなく行動ができるようになるためのアプリを作りました。
カメラのストリームをヒューリスティックに解析したり、OpenAIの Responses API, Audio API, Realtime API を活用しました。
画像解析とTTSを組み合わせることで、AIに道案内をしてもらう感じになります。
スマホでバイブコーディングする開発環境と開発サイクル
初速を出す
初速を出すために Firebase Studio を使っていました。
Geminiと対話しながら実装し、公開までボタン一つ。
v0、Bolt.new、Replit、Lovableなどと同様、無料でも十分試せる範囲が広いのが魅力です。
スマホでの開発体験も意外と快適でした。
1画面でチャット、エディタ、動作確認を切り替えられるので、その場で修正→検証の流れがスムーズでした。
強みはチーム開発の始めやすさ
一番良かったのは、チーム開発の始めやすさです。
Google Workspaceのようにメールアドレスで招待するだけで、誰でも同じプロジェクトにすぐ参加できます。
環境構築に時間をかけずに、すぐ開発を始められるのは強みでした。
見えてきた限界
ただ、開発を続けていくうちに課題も見えてきました。
デグレが頻発し、UI調整や改修バグの修正に時間がかかるようになりました。
感覚的に言えば、何も考えずに作り込めるのは5,000行程度。コードを覗いてみると1ページや1ルートのファイルが肥大化したり、デッドコードやフォールバックだらけになってたりしました。
ビルドすら通せなくなったり、カメラが起動しなくなったり、ヒューリスティック解析のロジックも頻繁にデグレし、動作確認自体がつらくなってきました。
弱みはチーム開発のスケール
切り戻しが容易なのは良いのですが、チャット履歴が1本しかないため、長期開発では経緯が追えず、議論が流れがちでした。どの変更がどこから始まったのか分かりにくいです。
持続開発へシフトする
Firebase Studioで得たスピード感は素晴らしかった一方で、チームで長期的に開発を回すには構造的な限界がありました。また持続的に開発をスケールさせていくには、より賢いモデルを使ったコーディングが必要でした。
そこでVercel + GitHub + Codex + Supabase + Weights & Biases の構成に移行しました。
Codex Cloud中心の開発スタイルへ
この環境で最も効果を発揮したのが Codex Cloudでした。
既に使用している方も多いと思うので、詳細は省きますが、強力なモデルにより多くの課題を解決しました。
コードを生成することはもちろん、以前の議論や設計を踏まえて最適化された修正を自走できる点が圧倒的です。
履歴と状態の可視化
GitHubで変更履歴を管理し、誰が・いつ・どのロジックを変更したかを、差分単位で追跡できます。PR作成時にVercelのプレビュー機能で、デプロイ前に動作確認もできるようにしました。
wandbを組み合わせて推論のトレースを可視化しました。
プロンプトチューニングを爆速で何度も繰り返すので、推論の入出力を記録し、振り返りができることは重要です。
結果として、開発のスピードを落とさずに一貫性と再現性を維持できるようになりました。
スマホでバイブコーディングするため工夫
Codexの使いこなし方
並列実行でアイデアを一気に試す
1プロンプトで最大4並列の生成ができるので、いくつか案がある場合は一気に走らせて比較します。
UI案やAPI設計など、複数パターンを短時間で検討できるのが強みです。
UI変更はスクリーンショットでPR作成前に確認する
UIやアクセシビリティの改修は詰まりやすいです。
Codexにスクリーンショットを生成させることで、
PR作成前にイメージを事前に確認することができます。
PR作成で自動でCICD組むことが多いと思うので、
無駄なリソースを削減し、高速に修正もできます。
実行環境のキャッシュを活用
コンテナのキャッシュを有効化し、実行環境の起動時間を最小化します。スマホでの開発では、1分の遅延が集中を削ぐため、小さな最適化でも大きく効いてきます。
インターネットアクセスを有効にして最新情報を反映
Codexのインターネットアクセス機能をONにし、
openai や wandb など、必要なライブラリのドメインを許可リストに登録します。
常に最新の仕様やAPIを参照しながら開発できるようにしています。
これでドキュメント参照の手戻りがなくなり、知識の陳腐化リスクをほぼゼロにできました。
plan.mdで実行計画を明示
OpenAI DevDay 2025でも紹介されていたように、大規模な改修にはplan.md をCodexに生成させてから実行します。
ステップを明文化しておくことで、曖昧な指示が減り、プロンプトの一貫性が保たれます。
“how”ではなく“goal”から書く
「どう作るか」よりも「どんなユーザー体験を達成したいか」を最初に描く。
UI変更や音声フィードバック、振動などの設計を目的ドリブンで考えるようにすることで、Codexの出力もブレなくなり、全体の開発速度が安定します。
カスタムインストラクションを設定する
UI変更時のスクリーンショット撮影、Web検索による最新情報取得、CIの実行など、Codexにカスタムインストラクションを設定しています。
人間の確認作業を自動化し「スマホだけで完結する開発体験」が実現しました。
特にVercelのプレビュー環境でビルド時にエラーに気付くと効率が悪いので、CI周りは作り込んだ方がよいです。
今回、初速を大事にしていたのでGHAで作り込みはせず、仕組みを作らせてローカルで作業完了時に確認させるようにしていました。
コンフリクトの解消
スマホで作業していると、コンフリクトした時に面倒です。
ただやはりスマホでバイブコーディングで、高速に検証していると、次から次へとアイデアが沸いて、同時並行で修正を入れる機会が多いため、コンフリクトは避けて通れません。
PR上でコンフリクトを確認した場合を、コメントでCodexをメンションし、記録を残しながら修正させたりしました。
簡易的な修正は、GitHubのエディタ上でスマホから直してしまいます。
定期的なリファクタリング
スピード優先で進めると、1ファイルが肥大化します。
同時並行で改善を入れると、コンフリクトも増えがちです。
私の方針は「どかっと作って、どかっとリファクタする」です。小刻みに直すより、一気に整理した方が安定します。そのために、一定サイクルでCodexにリファクタリング専用プロンプトを投げています。
とにかく捨てる姿勢
スマホでバイブコーディングの開発は、とにかく捨てることが重要です。PCならちょろっと中身見て自分で直すかとなるところですが、スマホでは無理。
余計なファイルや枝分かれを抱えるほど遅くなります。
動かないもの、迷ったコードはとにかく捨てる。残すより、書き直した方が早い。
バイブコーディングを成立させる最大のコツです。
LLMOps Weights & Biasesでのトレース管理
LLMを活用したプロダクトでは、生成結果や推論プロセスをトレース（追跡）できる仕組みが重要です。
私はWeights & Biases（wandb）でログを自動記録し、各実行ステップのプロンプト、レスポンス、実行時間、API呼び出し数などを可視化しています。
これにより、「なぜこの出力になったのか」「どのプロンプトが効果的か」を後から振り返ることができ、開発の再現性が格段に上がりました。
Copy Page活用と検索最適化
最近のライブラリ（OpenAI、wandb、Vercel など）は公式ドキュメントに “Copy Page” ボタンがあるのが当たり前になりました。
私はWeb検索で無駄にコンテキストを浪費させるよりも、イメージできている範囲はCopy Pageで抜き出してCodexに突っ込むようにしています。
これで、文脈の再解釈ミスや冗長な検索を避け、一発で精度の高い実装を出させます。
wandb weaveの実装や8月末にアップデートされたRealtime APIの活用のために、Response APIから切り替えを行いましたが、案外スムーズにいけました。
技術選定
ツール選びは、今いちばん難しくて、同時にいちばん楽しい領域だと思います。特にLLMOpsまわりは、OSSもSaaS選択肢がたくさんあります。
Claude Code、Gemini CLI、Codex といった開発者よりのツールにも注目しがちですが、バイブコーディング環境そのものの進化も侮れません。
たとえば Firebase Studio はまだ情報が少なく、あまり注目されていませんが、スマホで即デプロイできる軽量な開発環境としてはかなり優秀です。
同様に、Vercel のプレビュー機能 や Supabase のブランチ機能 はその場で動かすという思想と相性が抜群。Neon や Turso のようなモダンDBを組み合わせれば、スマホでバイブコーディングでも、プロダクションとして十分スケールさせていく仕組みを実現できるなと自信になりました。
というか今後やっていきたいと思います。
ツールにはそれぞれ得意分野があります。
だからこそ「プロジェクトの性質 × チームの開発スタイル」に合わせて、柔軟に組み合わせを変えることが、今の開発ではいちばん重要だなと強く感じました。
スマホでバイブコーディングの価値を考える
スマホで開発するという制約は、単なる不便ではなく、
創造性を引き出すフィルターのようなものだと感じます。
制約があるからこそ、優先順位が明確になり、
目の前の課題と向き合う密度が上がる。
その場で対面しながら話して、手を動かして、
「今ここで動くもの」を一緒に見ることができる。
PCと違って、スマホを持って近い距離で会話できるので楽しいし、運動しながら開発にもなるので、健康になりたい人にもオススメできます。
スマホという最小の環境で、最大の体験を設計する。
それが、この開発スタイルの価値だと思います。
Discussion