はじめに
この記事では、個人開発におけるバイブコーディングの中で、学びや納得感を置き去りにしないために試している、個人的な向き合い方についてまとめます。
※ 本記事では、特定のAIツールや実装の解説ではなく、個人開発におけるAIとの向き合い方や、学びを定着させるための試行錯誤をまとめています。
背景
現在、個人開発で自分専用の英語学習アプリを制作しています。開発にあたり、以下の2つの目標を掲げました。
- プロダクト： 自分にとって最高に使いやすいツールを作ること
- スキルアップ： AIの補助に依存せず、エンジニアとしての地力を養うこと
結果として、プロダクトは想像以上のスピードで形になりました。しかしその反面、自身の理解やスキルが追いついていない感覚も抱くようになりました。
スピードと成長をいかに両立させるか。試行錯誤の中で見えてきた「課題」と、現在の「向き合い方」を共有します。
「効率」の裏側で起きた思考のスキップ
AIを使っていると、「やりたいこと」を伝えた瞬間に「動くコード」が手に入ります。本来なら悩んで試行錯誤しながら辿り着くはずの答えに、一気にショートカットできてしまう。この圧倒的な速さは大きな魅力ですが、その裏で、コードの細部を自分の手で制御しきれていないような、どこか心もとない感覚がありました。
AIのコードが最初から「正解」に見えてしまい、「なぜこの実装なのか」を掘り下げる思考が停止していました。その結果、数時間前に書いたコードであっても、その設計意図を自分の言葉で説明できない状態に陥っていました。
具体的には、開発プロセスにおいて本来繰り返すべき、以下のような「判断」を無意識にスキップしていました。
- どこに処理を書くかの決断：Server/Client Componentsの使い分けや、コンポーネントを切り出す粒度などの「境界線」の引き方
- その実装を選んだ理由：データの持たせ方や共通化の単位など、複数の選択肢を比較して一つに決める手順
AIのコードをそのまま受け入れ続けることは、エンジニアとして本来やるべき「自分で考え、判断する訓練」を後回しにすることだと感じました。画面上の機能は増えても、自分の中に技術的な裏付けが残っていない。そんな状況に、焦りを覚えるようになったのです。
スキルを定着させるための「意図的な負荷」と3つのアプローチ
AIによる高効率な開発を維持しつつ、自身のスキルとして知識を定着させるためには、効率化の過程で削ぎ落とされた「思考のプロセス」を意図的に再構築する必要があると考えました。そこで私は、現在、以下の3つのアプローチを実践しています。
1. 「点」の解決に終始せず、ドキュメントによる体系的理解を優先する
AIエディタを用いた開発では、エディタ側が常にコードの文脈を把握しているため、具体的な課題に対して即座に解決策が提示されます。この体験は非常に効率的である一方、どうしても目の前のコードを修正するためだけの「断片的な知識」の蓄積に留まりやすい側面もあると感じています。
もちろん、AIに対して体系的な解説を求めれば相応の回答は得られますが、テンポを重視して開発を進めている最中では、どうしても対話が局所的な修正に偏りがちです。その結果、本質的な理解を置き去りにしたまま「パッチを当て続けるような開発」になってしまう危うさがあるのだと思います。
そのため、現在は不明な点が出てきた際、まず公式ドキュメントや技術書に立ち返り、周辺知識を含めて全体像を把握する時間を意識的に作るようにしています。その技術が解決しようとしている本質的な課題や設計思想をあらかじめ理解しておくことで、AIエディタから得られた「点」の回答を、別の場面でも応用できる汎用的な知見として自分の中に位置付け直せるのではないかと考えています。
2. 実プロダクトを「実験と検証」の場として活用する
技術書での学習や、実務を通して触れた汎用的な設計思想などを、自分のプロジェクトへ即座に適用し、その挙動を直接観察することを重視しています。
実務における開発では、既存の設計やスケジュールの制約により、新しい手法の導入が難しい場面も少なくありません。一方で、すべての決定権が自分にある個人開発は、学んだ知見を低リスクで試行し、その有効性を自ら確認できる最適な環境です。
具体例として、データベースに関する技術書で学んだインデックスの設計指針やテーブル構造の最適化をアプリに適用した際は、クエリの実行計画やレスポンスが改善される過程を直接確認できました。このように、外部から得た知識を実際のプロダクトに落とし込み、動作の変化を自分の目で確かめるプロセスを経ることで、情報は「単なる知識」から「実戦で使えるスキル」に昇華されると考えています。
3. AIの役割を「生成」から「設計のレビュー」へ拡大する
効率化のためにAIによるコード生成を活用しつつ、現在は「設計判断の検証」に充てる比重を高めています。具体的には、実装前に自分の案を提示し、可読性の懸念や別案とのトレードオフを指摘させるようにしました。
単にコードを受け取るだけでなく、技術的な判断基準を補強するステップを挟むことで、一つひとつの実装に対して自分なりの根拠を持てるようになっています。
「動けばいい」が生む失敗は最高の予習になる
こうしたアプローチを心がけていても、スピード優先で不適切な設計を選んでしまうことはあります。以前の私なら、こうした状況を単なる「時間のロス」だと感じて落ち込んでいたかもしれません。でも今は、こうした失敗こそが「理論を深く理解するためのステップ」になるのだと考えています。
AIによって図らずも作ってしまった保守性の低いコードなどは、むしろ学びを深めるための「最高の予習」だという捉え方をしています。実際に、拡張しにくいコードの修正に苦労した直後に技術書をめくると、「あ、だからこの設計が必要だったんだ」と、切実な実感を持って理解できるからです。
AIを使って短期間で失敗を経験し、その直後に正解の理論に触れる。このサイクルは、ただ本を眺めるよりもずっと効率的に、自分なりの判断基準を育ててくれる助けになっていると感じています。
おわりに
AIを使って「動くもの」を早く形にできる体験は、モチベーションを維持する上で大きな助けになると感じました。まずは完成させる、というスピード感は個人開発において欠かせないものだと思います。
一方で、効率だけを求めて「なぜ動いているかわからない」状態が続くと、自分のスキルに対する自信が少しずつ削られてしまう気もしています。
結局、試行錯誤の末に納得感を得るプロセスこそが、私にとっての開発の楽しさなのだと思います。AIを、思考を深めるパートナーとして心地よい距離感を探りながら、今後も納得感のある開発を続けていきたいです。