【ブルベ用アプリ開発#2】見積もり20人日が4人日に。品質にこだわることと開発スピードは両立できるか？AIでアプリを作った話

僕が自転車競技に参加した経験から、「こんなのがあったら便利だろうな」というブルベ専用アプリ「BREVET PACER PRO」の構想があった。

AIを使えばコードが書けるのは、もはや当たり前の時代だ。

「AIで作れる今の時代なら、ひとりでどこまで品質にこだわって形にできるだろうか？」 と考えて、業界経験がそこそこある自分で手を動かして試してみることにした。

要件定義の記事も書いてるので、興味がある方は一読を。

アプリの概要

事前にコースデータ（GPXファイル※中身はxml形式でひたすら座標が列挙されている）を読み込んでおくことで、走行中のタイムマネジメントを自動化するアプリだ。
競技中の信号待ちや休憩時にボタンをワンタップすると、GPSで現在地を特定。
残りの距離と制限時間から「完走に必要な平均速度」や「休める時間」を一発で割り出す。

疲労困憊の状態でも直感的に状況が把握できるUIにこだわり、タップ時の位置情報と時間はログとして保存されるため、事後のペース分析にも活用できるマニアックな仕様となっている。

どうせやるなら定量的に測れる結果もほしい。そう思い、工数を見積もり、実際の開発工数と比較してみることにした。

この記事は、エンジニアやデザイナーのいない個人開発で「UIUXにこだわったアプリの品質」と「開発スピード」は両立できるのか、というリアルな検証としての側面もある。

チーム開発（PM、エンジニア、デザイナー、テスター）なら20人日ほど見積もる規模のアプリだが、今回はだいたい4人日でこだわり抜いたアプリを作ることができた。

工数見積もりと実際の差

20人日の見積もり内訳

• 企画・要件定義 　5人日

• デザイン 2人日

• 設計・開発・インフラ構築  6人日

• テスト・ブラッシュアップ 6人日

• リリース（計画・実行） 1人日

AI開発4人日の内訳

• 企画・要件定義 　1人日

• 設計・開発・インフラ構築  0.5人日

• テスト・ブラッシュアップ 2.5人日

• リリース（計画・実行） 0.1人日

CodexやClaudeのようなAIエージェントにGCPの権限を渡して、インフラ構築まで全部お任せにするアプローチもある。

ただ今回は、中身がブラックボックスになるのを避けたかったのと、まずは無料で試したかったからというのも大きな理由で一歩ずつ自分で挙動を確かめながら進められる「Gemini」を対話パートナーに選んでいる。

4人日での開発を支えた環境

開発環境は身軽に、MacBook Air、VS Code、VS Code内のTerminal、Figmaのみ。

コードの実装と思考のパートナーとしてGemini「 3.1 Pro」&「強化版思考モード」を活用した。

チーム開発では「仕様の共有」のためのドキュメント作成や「修正依頼」といったコミュニケーションが必要になるが、AIと対話しながら進めるとそれらを大幅に削減できる。

さらに工数を大きく圧縮できた最大の理由は、意思決定者である僕自身がデザインを指示してブラッシュアップしたことと、AIが数秒でコードを出力してくれたことだ。

エンジニア不在で組むインフラ基盤（GCP/Firebase）

アプリを実用レベルで公開するには、インフラの安定性が欠かせない。

「まずは無料で試したい」という点でも、無料枠が充実しているGCP/Firebaseは最適な選択肢だった。

「どの技術を使うべきか」というアーキテクチャの基本知識さえあれば、あとはAIがしっかりした構成を組んでくれる。

今回採用したGCP/Firebaseの構成

1) Webサーバ (フロントエンドのデプロイサーバ)

• Firebase Hosting (10GBまで無料): PWAとしてのフロントエンドを配信するホスティング環境。

• デプロイ方法: Terminalから "% firebase deploy" コマンド一発で、ファイルと画像をサーバにアップロードする。

2) DB (データベース)

• Cloud Firestore (NoSQL DB): 位置情報（緯度・経度）、タイムスタンプ、残り距離などのログを保存するデータベース。

  • 無料範囲（まずこの範囲を超えることはない）

    • ドキュメントの読み取り: 50,000回 / 日

    • ドキュメントの書き込み: 20,000回 / 日

3) 認証基盤

• Firebase Authentication: GoogleアカウントによるOAuth認証。トラブル時のデータ復旧や本人確認のためのセキュアなログイン管理。

• Google Cloud (GCP) OAuth 同意画面: Googleログイン時に表示するアプリのブランディング設定。

4) オフライン処理

• Firestore Persistent Local Cache: 電波の届かない山間部やオフライン環境でもローカルにログをキャッシュし、通信回復時に自動で同期する機能。ここは山の中を走るブルベ現場で使う上で必須の要件だった。

利用シーンは「疲労蓄積の極限状態」、山間部でネットは安定しない状況の技術選定

そもそも、今回なぜiOSやAndroidの「ネイティブアプリ」ではなく、「Webアプリ（PWA）」を選んだのか。

PWA（Progressive Web Apps）とは、簡単に言えば「Webサイトをスマホアプリのように使える技術」のことだ。
わざわざApp StoreやGoogle Playからダウンロードしなくても、URLを開いて「ホーム画面に追加」するだけで、スマホにアイコンが作成され、通常のアプリと同じ感覚で使える。

ネイティブアプリはOSごとの開発が必要になり、アプリストアの審査待ちというタイムロスも発生する。今回は開発スピードと、この「URLひとつですぐにユーザーへ配布できる手軽さ」を優先した。

「山間部の圏外でも使えるのか？」という最大の懸念も、前述のFirestoreのローカルキャッシュなどを活用すれば、Web技術で十分にクリアできると判断したからだ。

ブルベの現場は、直射日光、夜間走行、極度の疲労、冬用の厚手グローブといった過酷な環境だ。

この極限状態の要求仕様を満たすアプリを作るとなると、何か特殊なアーキテクチャが必要に思えるかもしれない。
だが、特別な技術は必要ない。
ごくありふれた標準的なWebの構成でまったく問題ない。
重要なのは、要求仕様に対して「どの技術（ファイル）に、どんな役割を持たせて解決するか」という技術選定と役割定義だ。

• HTML: アプリ全体の骨格づくり。

• CSS: 要求・要望に基づいてUIやトンマナを記述するスタイルシート。

• JavaScript (JS): 現在地の取得、GPXデータとの照合、そして経過時間から「貯金タイム」や「必要Gross速度」を弾き出す計算ロジック。

• JSON: アプリの設定値やパースしたデータの管理。

このように、要求仕様を「標準的な技術スタックの役割」に分解し、設計としてAIに渡す。
こうしたWebの基本知識に基づく技術選定の全体像を描けていれば、AIは瞬時に土台となる構成案やコードを出してくれる。

しかし、AIが土台を作った段階では、まだ要求するクオリティには達していない。最終的なアプリのレベルを引き上げるには、ここからのプロセスが鍵になる。

クオリティを決めるのは、妥協なき「言語化」と「リテイク」

最終的に期待するクオリティまで持っていけた最大の理由は、AIの性能ではない。

「どんなアプリにしたいか」「ユーザーにとってどんな体験がベストか」というこだわりを徹底的に言語化し、納得いくまでAIとラリーを重ねたことにある。

チーム開発において、「情報の優先度はこっちが上だ」「こっちのボタンの方が強度が高い」といった細かなUI/UXのリテイクは日常茶飯事だ。

もちろんチームで対応できることだが、ドキュメントを更新し、意図をすり合わせるコミュニケーションはどうしても発生する。

スケジュールの都合で、PM側が優先度を下げて着地させることもあるだろう。

しかし、相手がAIのみならそのコミュニケーションのタイムラグはない。

ここで重要になるのが、人間側が持つUI/UXや、Web・アプリ開発の「基本知識」だ。  

知識があるからこそ、AIが書いてきた標準的な構成案や選定技術に対して「ここは良いが、現場を想定するとここはこう修正すべき」と的確なフィードバックを返すことができる。
そうやって自分が納得いくまでAIにコードを書き直して仕上げていった。

本来なら意図のすり合わせが発生するところを、どんなアプリにしたいかを一番分かっている自分自身が、直接AIと壁打ちして要件をプロダクトへ注入し続けられる。

これが、品質とスピードを両立できた一番の理由だと思う。

まとめ

今回はWeb開発やアプリ開発など、クリエイティブな現場の経験者向けに、情報共有の一つとしてこの記事をまとめた。

今回の検証を通して、システムの「基本知識」と現場の解像度が高ければ、エンジニアやデザイナーが不在でも、品質とスピードを両立してアプリが作れることがわかった。

さて、iPhoneでの壁打ちから始まった、Macでの開発フェーズはこれで一旦完成だ。

いよいよ次は、実際の現場となる100kmほどのコースに出て「試走」を行う。実地での使い心地を確かめ、少しでも違和感があればさらに手直しを加えていくつもりだ。

次回は、現場でのテストを経た「試走レポート」をお届けする。併せて、興味を持ってくれたサイクリストの方々にも実際に使ってもらえるよう、アプリのURLも公開する予定だ。