バイブコーディングで個人開発｜5つ作って分かった品質の確かめ方

kessan-trackerの開発記録によると、初回コミットから本番構成と管理APIまでは約22時間でした。Chore Pointsは初回コミットに約8,100行が入り、翌日だけで37コミットが積まれました。Time Logも、初回実装から約10日でGoogle Playの内部テスト再提出までたどり着いています。

ただ、正直に言うと、この数字は速さの証拠にはなっても、品質の証拠にはなりません。行数もコミット数も開発時間も、正しく動いているかどうかまでは教えてくれないからです。それでも、使った技術はFlutter、React、Python、PostgreSQL、AWS、PHPとばらばらです。その5つの個人開発を一人で公開やテスト配布まで進められた速度は、1年前なら考えにくいものでした。

バイブコーディングと呼ばれる進め方で個人開発を続けるうちに、時間の使い方が変わりました。コードを一行ずつ読む時間が減り、代わりにDB全体、実際の画面、テストの中身、バックアップ、反映後の状態を見るようになったんです。AIに実装を任せても、人の仕事が消えたわけではありません。確認する単位が、コードからシステム全体へ移っただけでした。

速く作れた分を全体の確認に使う

調査、実装、テスト、デプロイはAIに任せられる。それでも、目的と制約、データの正本、テストの観点、復旧方法、公開の判断は人が決める。実装が速くなった分の時間は、後回しにしがちだった異常系と運用の確認に回す。

バイブコーディングという言葉と、私の使い方のずれ

「バイブコーディング」は、Andrej Karpathyが2025年2月の投稿で広めた言葉です。AIが生成した差分をほとんど読まず、動きを見ながら会話で直していく方法で、Karpathy自身は、使い捨ての週末プロジェクトには悪くない、という温度で紹介していました。それが2025年には、CollinsのWord of the Yearに選ばれるところまで広がっています。

で、私の進め方はこの定義と少しずれているんです。コードをほとんど読まずに進めること自体はよくあります。ただ、対象は使い捨てではなく、継続して運用するサービスです。バックアップ、Git、テスト、本番確認までAIに頼みますが、その結果は最後に自分で確かめます。Karpathyがあとから区別した「agentic engineering」のほうに近い進め方だと思います。

ここで「コードを読まないほうが良い」という話に聞こえたなら、それは違います。読まないこと自体は目的ではなく、限られた時間のなかで、どの確認が品質にいちばん効くかを選んだ結果です。認証、権限、課金、削除のようにコードレベルの確認が欠かせない領域は別で、静的解析や第三者のレビューもあわせて使います。

5つの個人開発と、それぞれの到達点

2026年7月12日に、各リポジトリのGit履歴と公開状態を調べました。冒頭の数字も、このとき確かめたものです。

開発したもの	主な内容	確認できた到達点
Time Log	Flutterの時間記録、端末DB、サーバー同期、課金	Google Play内部テスト再提出
Chore Points	グループ、招待、権限、ポイント、アプリ内購入	Google Play用ビルドとテストの準備
Study AI	学習記録、教材、11形式の問題表示、手書き解答	Web公開
kessan-tracker	EDINET取得、XBRL解析、PostgreSQL、Next.js、AWS	本番公開
Journal	WordPressテーマ、SEO、目次、装飾、自動更新	このブログで稼働中

使っている技術も公開の形もばらばらです。それでも、進め方はどれも同じでした。目的を言葉にして、AIにリポジトリを読ませて実装とテストを進めてもらい、最後に公開状態を自分で確かめる、という流れです。

kessan-trackerの約22時間や、Chore Pointsの37コミットが示すのは、AIが広い範囲を短時間で変更できるという事実です。これ、裏を返すと、間違った前提も同じ速さで広がるということなんです。変更が大きいほど、確かめる範囲も一緒に広げないと釣り合いません。

1年前の私は、差分を読んで直していた

1年前の私は、Claudeに関数や画面のコードを書いてもらい、変更箇所を読んで、気になるところは手で直していました。AIはあくまで、便利な実装補助でした。その頃といまを並べると、変わったのは頼む範囲だけではありません。

比較	1年前	いま
AIへ頼む範囲	関数や画面単位の実装	調査からリリース確認まで
自分の中心作業	コードを読み、手で修正	目的、制約、検収条件を決める
確認対象	差分と個別機能	DB、画面、テスト、運用全体
立ち位置	AIを使うコーダー	プロジェクトマネージャー兼テックリード

WordPressテーマのJournalを作ったときも、要件と優先順位は自分で決め、実装のたたき台はAIに作らせ、本番へ出すかどうかは自分で判断していました。いまはそこからさらに進んで、テスト、バックアップ、デプロイ、公開後の確認までAIに任せています。

それでも、目的を決めて、作業を分けて、危ない場所を予測して、結果を確かめるという流れ自体は、1年前から変わっていません。変わったのは、一人でも複数の実行役に仕事を渡せるようになったことでした。

いま見ているのは、DBと画面とテストと戻し方

AIが出したものを、そのまま信じて公開しているわけではありません。私が確かめているのは、利用者から見える結果が、システム全体の動きとつじつまが合っているかどうかです。具体的にはこの4つを見ています。

DB全体：件数、合計、重複、欠損、外れ値、更新前後の差
実際の画面：状態遷移、戻る、削除、再実行、通信失敗
テスト内容：境界値、異常系、期待結果が目的に沿っているか
リリース手順：バックアップ、Git差分、戻し方、反映後の確認

並べてみると、どれもコードの中身ではなく、動いた結果を確かめる項目です。テストコード自体はAIに書いてもらえますが、それだけでは確認が終わりません。AIは自分が実装したときの前提に沿ってテストを書くので、実装とテストが同じ思い込みを引きずることがあるからです。どこが壊れやすいか、利用者から見てどんな結果になるべきかは、人が決めて確かめるしかありません。

ついでに言うと、DBと画面を見るだけで、コードレベルの安全性まで確認できるとも思っていません。認証、権限、外部入力、依存関係については、静的解析やセキュリティテスト、必要に応じて経験者によるコードの確認を重ねます。

Web APIの話なのに、SQLiteが入ってきた

趣味で続けてきたプログラミング経験がいちばん役立ったのは、実はコードを書く場面ではありませんでした。AIの提案に違和感を持った場面です。

あるとき、Web APIを作る話をしていたのに、AIがローカルにSQLiteを入れ始めました。SQLiteが悪いという話ではないんです。複数の利用者や環境から使うという要件に対して、データの保存先と正本の決め方が合っていませんでした。

時刻でも似たことが起きています。UnixタイムスタンプとJSTに変換済みの日時が混ざったり、DB側とフロント側が別々に現在時刻を取って数秒の差が出たりしていました。一つひとつの処理は動いているのに、期限判定や並び順、日付の境界で組み合わせると矛盾が出ます。

あとから見れば、どちらも正本を複数作ってしまった失敗です。データでも時刻でも判断でも、正本が複数あると、処理同士のつじつまはどこかで合わなくなります。AIはその場では正しいコードをすばやく書いてくれます。でも、コード同士をつないだときに出る矛盾は、目的と全体像を踏まえて見ないと見つかりませんでした。

経験の使いどころは、書く場面から警戒する場面へ

時間、権限、同期、削除、外部API、課金。複数の状態が絡む処理を見ると、「ここは複雑になりそうだ」と身構えます。この勘の出どころははっきりしていて、過去に自分で似た失敗をしてきた経験です。

2026年6月にAnthropicが公表した約40万件のClaude Codeセッション分析にも、近い話が出てきます。典型的なセッションでは、人が計画上の判断を多く行い、Claudeが実行上の判断を多く担っていたそうです。対象業務に詳しい利用者ほど、結果を検証できる形で成功しやすい傾向も報告されていました。

もっとも、この調査は実社会で採用された成果物まで測ったものではなく、セッションの分類にもモデルを使っています。その分は割り引いて読む必要があります。それでも、コードの構文を知っていること以上に対象業務への理解が効くという点は、私の実感とよく重なりました。

だから、プログラミング経験がいらなくなったとは思っていません。ただ、使いどころは変わりました。コードを書くためではなく、前提の違いに気づくため、どこを重点的にテストするかを選ぶために使う場面が増えています。

間違いも速いから、戻し方を先に決めておく

AIが間違えるのは、未知の難問とは限りません。時刻の扱い、開発環境と本番環境の取り違え、削除範囲、ビルド対象、昇順と降順といった、人間も間違えやすいところで同じように間違えます。違うのは、その間違いを短時間で広い範囲へ反映できてしまうことです。

なので、削除を伴う作業では先にDBのバックアップを取り、コードと設定はGitに残します。ただ、Gitで戻せるのは管理対象のファイルが中心で、DBのデータや未追跡の素材までは守ってくれません。復旧の手段は分けて用意しています。

バックアップもGit操作も、作業そのものはAIに頼めます。人が決めるのは、「この操作の前に何を保存するか」と「どの確認結果が出るまで完了にしないか」の2つです。

後回しだった異常系に、時間を回せるようになった

以前の一人開発では、ひとまず動くところまで作るだけで時間を使い切り、異常系のテストを後回しにすることがありました。いまは実装をAIに任せた分、浮いた時間をDBの確認、複雑な画面操作、テスト観点の追加に回せています。

AIを使ってテストを省いたのではなく、順序が逆なんです。実装を任せられる相手が増えたから、一人でもテストに余力を割けるようになりました。テストコードの本数よりも、「二人が同時に操作したら」「通信中に戻ったら」「削除後に同期したら」と考える時間が増えたことのほうが、私には大きな変化でした。

作り始めるハードルと、本番へ出すハードルは別

技術的な実現方法を知らなくても、AIに選択肢や失敗例を説明させて、テストを作らせることはできます。むしろ業務をよく知る人のほうが、現場固有の例外に早く気づけることもあるくらいです。

「この操作のあとに戻ったらどうなる」「二人が同時に押したらどうなる」「間違った値をどう直す」。こう考える力は、エンジニアだけのものではありません。非エンジニアでも、自分がよく知る業務の道具なら形にしやすくなりました。

ただし、始めやすくなったことと、本番で使える品質が手に入ることは別です。最初は、失敗しても影響の小さい道具から選ぶのが良いと思います。個人情報、課金、削除、外部公開が絡むなら、必要に応じて経験者や第三者の確認も入れてください。

約22時間の先に残っていた、検収という仕事

kessan-trackerを約22時間で本番構成まで進められたのは、調査と実装をAIが引き受けてくれたからです。ただ、その22時間が終わった時点では、XBRLタグが正しいか、DBに欠けがないか、ランキングが逆順になっていないか、公開後も更新し続けられるかは、まだ分かっていませんでした。そこから先が、私の仕事です。

いまの実感を言葉にすると、一人で何でもできるようになったのではありません。一人でも実装を分担し、結果を確かめることに集中できる開発チームを持てるようになった、ということです。

1年前の私は、差分を読むことでその確認をしていました。いまの判断材料は、コードを読んだ行数ではなく、目的、正本、異常系、復旧、完了条件をどこまで確かめたかです。バイブコーディングで個人開発がどれだけ速くなっても、品質の判断は結局ここへ戻ってくると感じています。

このブログのWordPressも、同じやり方で回しています。下書き、画像設定、バックアップ、反映後の確認までAIに任せて、最後に結果をもう一度取得し、自分が頼んだとおりの状態になっているかを確かめています。