最近、AIにコードを書いてもらいながら、いくつかWebアプリやツールを個人開発しています。
AIに頼むと、動くものがあっという間にできあがります。
そこはすごくありがたいのですが、作っているうちに「AIが書いたコードを、あとから自分で直すのが意外と大変だ」と感じる場面が増えてきました。
ゼロから書くのとは違う、AI任せならではのつまずきです。
今回は、私が実際にぶつかった大変さと、それに対してした工夫を正直に書いておきます。
同じようにAIで開発している方の役に立ったらうれしいです。
大変だったこと1：文字の大きさがバラバラに指定されている
最初に困ったのが、文字サイズの直し方でした。
「見出しの文字、全体的にもう少し大きくしたいな」と思って直そうとしたのですが、これが思ったよりずっと手間でした。
私はなんとなく「見出しの大きさは h1 h2 h3 でまとめて決まっているもの」だと思っていました。
ところが実際は、そうではありませんでした。
AIが書いたコードでは、セクションごと・パーツごとに文字サイズが個別に指定されていることが多かったんです。
同じ「見出し」でも、この画面ではこのサイズ、別の画面ではまた別のサイズ、という感じで、あちこちに散らばっていました。
なので1か所直しても全体には反映されず、似たような指定を1つずつ探して直すことになって、けっこう疲れました。
最初にサイズの基準を決めておけばよかった
これは、あとから「先に決めておけばよかったな」と思った点です。
最初の段階で「見出しはこのサイズ」という基準をAIに指定しておけば、あとからの一括修正がだいぶ楽になったはずだと思いました。
できあがってから直すより、作り始める前にルールを渡しておくほうが、結果的に手間が少ないという学びでした。
次に何か作るときは、ここを最初にお願いしようと思っています。
大変だったこと2：ファイルが何のファイルかわかりにくい
2つめは、ファイルの中身がぱっと見でわからないことでした。
自分で1から作っていれば、ファイルに自分で名前を付けるので「これは何の処理か」がなんとなく頭に残ります。
でもAIに任せていると、ファイルの命名も構成もAIがやってくれるぶん、自分がそのファイルに愛着というか土地勘がない状態になります。
いざ直したいときに「あれ、この機能ってどのファイルだっけ」と、毎回さがすことになりました。
READMEに説明を書いてもらってはいるのですが、直すたびにわざわざREADMEを開いて確認するのも、地味に手間でした。
ファイルの一番上にコメントで説明を書いてもらった
そこで私がしたのは、各ファイルの一番上に、コメントアウトでわかりやすい説明を入れてもらうことでした。
ファイルを開いた瞬間に「このファイルは何をするものか」が目に入るので、READMEまで戻らなくてよくなります。
イメージとしてはこんな感じです。
// ==============================
// カウントダウン画面の表示
// 服薬の間隔を計算して残り時間を出す
// ==============================ちょっとしたことなのですが、ファイルを行き来する回数がぐっと減って、直すときの心理的なハードルが下がりました。
READMEは全体の説明、ファイル上部のコメントはその場での道しるべ、という役割分担にすると私には合っていました。
大変だったこと3：色の名前がわかりにくい
3つめは、色の指定の名前がわからないことでした。
AIが書いたコードには text-ink-soft のような色の指定が出てくるのですが、これが結局どんな色なのか、名前を見ただけではわかりません。
カラーコードを探そうとしても見つからず、しばらくモヤモヤしていました。
これについては別の記事にくわしく書いたのですが、実は色は index.css の中に名前付きで定義されていて、VSCodeの拡張機能を使うと色が見えるようになるとわかって、だいぶ楽になりました。
色まわりのつまずきと対処は、この記事にまとめてあります。
共通して感じたこと
3つを振り返って共通しているのは、「AIが書いたコードは、動くけれど、自分にとっての読みやすさ・直しやすさは別の話」ということでした。
AIはとても速く正確に書いてくれますが、そのコードを何か月も付き合って育てていくのは自分です。
だから、あとで自分が困らないように、最初にルールを渡したり、目印を足してもらったりする工夫がいるんだなと感じました。
丸投げして終わりではなく、自分が後で直せる形に整えてもらうところまでお願いすると、ずいぶん楽になりました。
まとめ
AIにコードを書いてもらう開発は、動くものが早くできる一方で、あとから自分で直そうとすると別の大変さがありました。
文字サイズがパーツごとに散らばっていて一括で直しにくかったこと、ファイルの中身がぱっと見でわからなかったこと、色の名前が何色かわからなかったこと。
それぞれ、最初にサイズの基準を決めておく、ファイル上部にコメントで説明を入れてもらう、色の定義と確認方法を知る、という工夫で少しずつ楽になりました。
私はまだAIに助けてもらいながら手探りで開発している段階です。
それでも「できてから直す」より「あとで直しやすい形で作ってもらう」ほうが結局ラクだと気づけたのは、今回の大きな収穫でした。
一番書き方でつまずいたTailwind CSSで学んだことを別の記事にしています。
Tailwind を使ったアプリ開発ログ
Tailwind v4の余白がわからない！mb-6の中身「calc(var(–spacing) * 6)」を調べた話
Tailwindの色「–color-ink-soft」って何色？VScodeの拡張機能「Color Highlight」が便利！
Tailwind CSS｜–color-〇〇 の「〇〇」がそのままクラス名になる
Tailwindの hover: や md: って何？状態プレフィックスのしくみを調べた
