【AI時代の個人開発】4.「UI修正→即反映」の環境を作ったら、開発速度が一気に変わった話

油川流樹🥝個人開発🍇

2026年5月25日 07:13

AIを使う側から、使いこなす側へ。

※2026年7月1日更新
シリーズを書き進める中で得た気づきを反映し、リード文・構成・文章表現を見直しました。

AIがコードを書く速度よりも、私の開発を大きく変えたものがありました。

UIの違和感に気づき、AIへ伝え、数秒後には画面で確かめる。この往復が短くなると、作業時間だけでなく、AIへ出す指示の具体性と、試せる回数まで変わります。

前回は、Firebase Authenticationを使ってログイン認証機能を実装した過程を書きました。

ログインできる。専用画面へ入り、メイン機能を操作できる。サービスの骨格が見え始めた頃、今度は画面の細部が気になり始めました。

ボタンの位置
カード同士の余白
説明文のわかりやすさ
スマートフォンで見たときの表示
初めて画面を開いたとき、次の操作が伝わるか

ひとつひとつは小さな要素です。

それでも、画面を触るたびに感じる違和感は、積み重なるほどサービス全体の印象に影響します。

今回は、UIを修正してすぐ確認できる環境を整えたことで、個人開発の進め方が変わった話です。

機能が動作することと、自然に使えることは別だった

個人開発を始めた頃は、まず機能を成立させることに意識が向いていました。

ログインできるか
データを保存できるか
画面を正しく遷移できるか
必要な処理を最後まで完了できるか

いずれも、サービスを動かすために欠かせない確認です。

一方、実際に画面を操作してみると、機能が正しく動くことと、自然に使えることは同じではないとわかります。

ボタンが少し目立ちすぎている。説明文の意味が一度では伝わりにくい。スマートフォンでは余白が狭く、窮屈に見える。

仕様書やコードだけを見ている段階では気づかなかった問題が、画面に触れることで初めて見えてきました。

小さな修正ほど、確認までの手間が響く

当時の開発環境では、UIを少し変更するだけでも複数の作業が必要でした。

コードを修正する
手動でビルドする
サーバーを再起動する
ブラウザを更新する
画面を確認する
違和感が残っていれば、もう一度修正する

内容自体は複雑ではありません。

ただ、1回の確認に5分から10分かかる状態では、小さな調整を何度も試す気持ちが薄れていきます。1日に5回繰り返せば、確認作業だけで30分から50分ほど使う計算です。

個人開発では、設計、実装、確認、修正、判断を自分で行います。ひとつの工程に摩擦があると、開発全体のテンポにも影響します。

「この修正は後でまとめよう」
「今は機能実装を優先しよう」
「細かな見た目は最後に整えればいい」

そう判断する場面が増えていきました。

機能実装を優先したほうがよい状況はあります。ただ、画面上の違和感は、気づいた瞬間が最も鮮明です。

修正内容そのものより、確認までの手間が、UI改善の回数を減らしていました。

「UI修正→画面確認」を数秒に縮めた

そこで、Viteを使ったローカル開発環境を構築しました。

ファイルを変更すると、その内容が自動的に処理され、開発中の画面へ素早く反映されます。毎回、手動でビルドや再起動を繰り返す工程を省けるようになりました。

開発時に実行するコマンドも、ひとつにまとめました。

npm run dev:local

このコマンドでローカル開発環境を起動しておけば、コードを変更してから画面で確認するまでが数秒で完了します。

以前は、次のような流れでした。

UIの違和感に気づく
　　↓
コードを修正する
　　↓
手動でビルド・再起動する
　　↓
ブラウザを更新する
　　↓
画面で確認する

環境を整えた後は、こう変わりました。

UIの違和感に気づく
　　↓
AIへ修正を依頼する
　　↓
変更が画面へ反映される
　　↓
その場で確認し、必要なら追加調整する

数分間の待ち時間が減ったこと以上に、「少し変えて比べてみる」「一度試してから判断する」という進め方がしやすくなりました。

画面を見ながら、AIへの指示を具体化する

確認が速くなったことで、AIへの依頼方法も変わりました。

画面を見ずにUI修正を頼むと、指示は抽象的になりがちです。

もっと見やすくしてほしい
全体を整えてほしい
スマートフォンでも使いやすくしてほしい

これでもAIは修正案を出せます。ただ、どの状態を完成とするのかまでは共有できていません。

画面を確認しながら進めると、依頼内容は具体的になります。

このカードの上下の余白を広げる
スマートフォン表示のときだけ、ボタンを縦に並べる
説明文を短くし、操作の目的を先に示す
初回案内を画面上部へ移動する
このボタンが確認用であることを文言で伝える

修正後の画面もすぐに見られるため、次の指示へ自然につなげられます。

「配置は自然になったが、説明が少し長い」
「PCでは見やすいが、スマートフォンではまだ窮屈に見える」
「この位置よりも、ひとつ上のほうが操作の流れに合っている」

AIへ完成形を一度に作らせるというより、画面を見ながら少しずつ形を詰めていく。その使い方が、自分には合っていました。

本当に増えたのは、改善できる回数だった

開発速度が上がると聞くと、作業時間の短縮を想像します。

手動のビルドや再起動が減ったことで、実際に時間は短くなりました。ただ、今回の変化でより大きかったのは、同じ時間の中で試せる回数が増えたことです。

1回の修正が重いと、変更する前に慎重になります。

「本当に今直す必要があるか」
「後でまとめたほうが効率的ではないか」
「細部に時間を使いすぎていないか」

変更がすぐ反映される環境では、こうした迷いを抱えたまま考え続けるより、実際の画面で試して比較できます。

「まず変えてみる」
「合わなければ戻す」
「別の配置も見比べる」

使える時間も集中力も限られる中で、ひとつの案に悩み続けるより、複数の案を画面上で確かめられる。その差が、最終的な品質にも表れていきました。

開発速度が上がるとは、早く作り終えることだけではなく、より多く試せる状態を作ることでもある。

今回の環境づくりを通して、そう実感しました。

AIが速く書くほど、確認と判断が重要になる

AIを使うことで、コードを書く速度は大きく上がりました。

その一方で、生成されたものが画面として自然か、操作の流れに合っているかまで、コードだけを見て判断することは困難です。

UIには、別の確認が必要です。

画面全体のバランスは自然か
操作の目的が伝わるか
次に何をすればよいか迷わないか
文言が機能の意図と合っているか
スマートフォンでも無理なく操作できるか

こうした要素は、実際の画面に触れながら確かめます。

AI時代の個人開発では、「AIにどれだけ速く書いてもらえるか」だけでなく、「書かれたものをどれだけ速く確認し、次の指示へつなげられるか」も大切になるのだと思います。

AIへ具体的に依頼する。修正結果をすぐ確認する。画面上の違和感を言葉にして返す。

この流れがつながったことで、AIとのやり取りは一度きりの依頼から、短い改善ループへ変わりました。

今回のことで学んだこと

今回の経験を一言でまとめるなら、次のようになります。

個人開発の品質は、改善ループの速さで変わる。

AIに修正を依頼し、画面で確認する。そこで見つけた違和感を言葉にして返し、もう一度確かめる。

この往復を気軽に繰り返せるようになったことで、開発速度だけでなく、サービスを少しずつ磨いていく感覚もつかみやすくなりました。

最初から完成形を正確に見通すのは難しいものです。

だからこそ、違和感に気づいたとき、すぐ試せる状態を作っておく。その環境が、個人開発を前へ進める支えになりました。

次回予告：
認証は「ログインできた」で終わりではなかった

ログイン認証を実装し、画面を改善しながらサービスを長時間使うようになると、別の課題が見えてきました。

認証の「持続性」です。

利用中に認証トークンの期限が切れた場合、APIからエラーが返ることがあります。そのとき、再ログインを案内するのか、裏側でトークンを更新するのか、どこまで自動的に処理するのか。

さらに、認証処理の回数は運用コストにも関係します。

次回は、長時間利用時の認証トークン更新、getIdToken(true)の扱い、APIエラーへの対応を通して、ログイン状態を安定して維持する仕組みについて整理します。

いいなと思ったら応援しよう！

いただいたお気持ちは執筆用のチョコ代に当てさせていただきます！