1年前の私は、Claudeにコードを書いてもらいながら、変更箇所を読み、必要なら手で直していました。それでも十分便利でしたが、感覚としては「作業を手伝ってくれる相手」です。
それがここ数カ月で変わりました。いまは作りたいものを説明し、AIに調査・実装・テスト・デプロイを頼み、コードをほぼ読まないまま本番公開やテスト配布まで進めています。一方で、確認をやめたわけではありません。確認する対象が、コードの一行一行から、DB全体、実際の画面、テスト内容へ移りました。
「バイブコーディング」は、Andrej Karpathyが2025年2月の投稿で広めた言葉です。本人は、AIが生成した差分をほとんど読まず、動作を見ながら会話で直す方法を紹介し、使い捨ての週末プロジェクトには悪くないと述べました。現在は自然言語でAIにコードを作らせる開発全般にも使われ、Collinsの2025年Word of the Yearにも選ばれています。バックアップ、Git、テストまで監督する私の進め方は、Karpathyが後に「agentic engineering」と呼んだ形に近いと思います。
1年前の「便利な補助」から、いまは実装チームへ
| 比較 | 1年前 | いま |
|---|---|---|
| AIへ頼む範囲 | 関数や画面単位の実装 | 調査からリリース確認まで |
| 自分の中心作業 | コードを読み、手で修正 | 目的、制約、検収条件を決める |
| 確認対象 | 差分と個別機能 | DB、画面、テスト、運用全体 |
| 立ち位置 | AIを使うコーダー | AIチームを率いるプロジェクトマネージャー兼テックリード |
WordPressテーマJournalを作った時点でも、要件と優先順位は自分、実装のたたき台はAI、本番反映の判断は自分という分担でした。いまはAIへ任せる範囲が、実装からテストや運用まで広がっています。
目的を決め、作業を分け、危険を予測し、結果を検収する流れ自体は変わりません。違うのは、一人でも実装、調査、テスト、運用を分担できることです。感覚としては、開発手法が変わったというより、超優秀な部下が何人も増えたことに近いです。
5つの実例で、任せる範囲が広がった
最近AIと進めたものを並べると、扱った技術も公開方法もばらばらです。到達した開発段階とGit履歴は、2026年7月12日に確認した内容です。
| 開発したもの | 主な内容 | 確認できた到達点 |
|---|---|---|
| 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、目次、装飾、自動更新 | このブログで稼働中 |
Gitの履歴で見ると、Time Logは初回実装から約10日で内部テスト再提出まで進みました。Chore Pointsは初回コミットで約8,100行が追加され、その翌日だけで37コミットあります。最も極端だったkessan-trackerは、初回コミットから本番構成と管理APIまで約22時間でした。
もちろん、行数やコミット数は品質を示す数字ではありません。ただ、Flutter、React、Python、PostgreSQL、AWS、PHPと違う技術を、一人が短期間で本番や配布環境まで運べた速度は、1年前には考えにくいものでした。WordPressテーマJournalも、有料テーマから置き換えたあと実サイトで使い続けています。
コードレビュー中心から、システムレビュー中心へ
「コードを読まずにリリースする」と聞くと、AIの出力をそのまま信用しているように見えます。実際にしているのは逆です。局所的なコードではなく、利用者から見える結果とシステム全体を確認しています。
- DB全体：件数、合計、重複、欠損、外れ値、更新前後の差を確認する
- 実際の画面：状態遷移が多い操作、戻る、削除、再実行、通信失敗を重点的に触る
- テスト内容：境界値、異常系、期待結果が目的に沿っているかを精査する
- リリース手順：バックアップ、Git差分、戻し方、反映後の確認を揃える
テストコード自体はAIへ発注できます。でも、AIは自分が実装した前提に沿ってテストを作るため、実装とテストが同じ思い込みを共有することがあります。「何を試すべきか」まで自動生成に任せず、壊れやすい場所と期待する結果は人間側で確認します。
DBと画面の確認だけで、コードレベルの安全性を完全に代替できるわけではありません。認証、権限、外部入力、依存関係などは、静的解析やセキュリティ向けテストも別に発注します。扱うデータや影響が大きいサービスでは、経験者によるコード確認や第三者レビューも必要です。
経験が生きたのは「正本が二つある」と気づく場面
私は職業エンジニアではなく、本業は経理です。ただ、趣味でプログラミングをしてきた経験があります。その経験が役立ったのは、コードを書く場面より、AIの提案へ違和感を持つ場面でした。
たとえばWeb APIを作る話なのに、AIがローカルへSQLiteを入れ始めたことがあります。SQLite自体が悪いわけではありません。複数の利用者や環境から使うデータを、どこへ保存し、何を正本にするかが要件と合っていませんでした。
時刻でも似たことがありました。UnixタイムスタンプとJSTへ変換済みの日時が混在したり、DB側とフロント側が別々に現在時刻を取得し、数秒の差が出たりします。個別の処理だけを見れば、それぞれ正しく動いています。でも期限判定、並び順、日付境界で組み合わせると矛盾します。
共通するのは、データの正本、時計の正本、判断の正本が複数あることです。AIは局所的に正しいコードを高速で書けます。一方、コード同士をつないだときに生まれる矛盾は、目的と全体像を知る側が見つける必要があります。
少なくとも今回の5つでは、AIから未知の知識を教えてもらう場面だけでなく、AI側の見逃しをこちらから指摘する場面が何度もありました。そのとき役立ったのは、構文の記憶ではなく、「この設計だと別の場所で困る」という過去の経験です。
時間、権限、同期、削除、外部API、課金、複数の状態が絡むところを見ると、「ここは複雑になる」と警戒します。この勘は、過去に自分や他人が同じような失敗をした経験から来ています。プログラミング経験は不要になったのではなく、書く力から、危険な場所を選ぶ力へ使い道が変わりました。
超優秀な部下にも、バックアップと戻る道が要る
AIがする間違いは、未知の難問ばかりではありません。時刻の扱い、開発環境と本番環境の混同、削除範囲、ビルド対象、ランキングの昇順・降順など、人間もよく間違えることです。違うのは、AIが非常に速く、広い範囲を一度に変更できることです。
そのため、削除を伴う作業ではDBのバックアップを先に取らせます。コードと設定はGitで履歴を残し、いつでも前の状態へ戻せるようにします。Gitで戻せるのは主に管理対象のファイルで、DBのデータや未追跡の素材まで自動的に守られるわけではありません。復旧手段を分けて用意します。
バックアップもGit操作もAIに頼めます。人間がするのは、「この作業では必ずバックアップを取る」「この確認結果が出るまで完了にしない」とルールを決めることです。AIが実行担当になっても、作業の優先順位と完了条件を決める役割は残ります。
実装時間が減り、テストへ人手を回せるようになった
以前の一人開発では、動くところまで作るだけで時間を使い切り、テストケースを十分に増やせないことがありました。いまは実装をAIへ渡し、浮いた時間をDBの確認、複雑な画面操作、テスト観点の追加へ回せます。
つまり、AIを使ってテストを省略したのではありません。AIが実装を担うことで、一人でもテストへ割けるリソースが生まれました。テストコードを書かせること以上に、以前なら後回しにした異常系まで考えられることが、生産性向上の大きな部分です。
Anthropicが約40万件のClaude Code対話セッションを分析した2026年の調査でも、人間が計画し、AIが実行する分担と、タスク固有の専門性が高いほど成功しやすい傾向が報告されています。実社会での採用結果まで測った調査ではありませんが、今回の実感と重なります。
未経験者にも入口が開き、経験者にはレバレッジがかかる
ここまで経験の話を書きましたが、プログラミング経験を参加資格にする必要はありません。「この操作をしたあとに戻ったらどうなる」「二人が同時に押したらどうなる」「値が入っているけれど間違っていたらどう直す」と考える力は、エンジニアだけのものではないからです。
技術的な解決方法を知らなくても、AIへ選択肢と失敗例を説明させ、テストを作らせられます。業務を知る人のほうが、現場特有の例外に早く気づくこともあります。作りたいものがあり、完成まで対話を続ける熱意があれば、非エンジニアでも自分用の道具を形にできる時代になりました。
ただし、入口が広がったことと、本番品質が無条件に保証されることは別です。まずは失敗しても影響が小さい道具から始め、個人情報、課金、削除、外部公開を含む場合は、必要に応じて経験者や第三者の確認を入れるべきです。
経験者の優位が消えたわけでもありません。コードを書く速度の差は縮まりましたが、AIの前提違いに気づき、危険な箇所へテストを集中する速度には経験が生きます。経験は入場券ではなく、完成度と到達速度を上げるブースターになりました。
一人で開発チームを持つ時代になった
バイブコーディングを始めて、人間の仕事がなくなったとは感じません。要件、優先順位、バックアップ、テスト、リリース判断、責任は残っています。ただし、それを実行する手が一人分ではなくなりました。
AIによって一人で何でもできるようになったのではありません。一人でも、開発チームを持てるようになりました。
AIへ実装だけでなく、WordPressの更新、バックアップ、反映確認まで頼んでいる流れは、XserverのWordPress運営をAIに手伝わせる方法にまとめています。コードを読む時間が減ったあと、人間が何を確認するのかまで含めて設計することが、これからの一人開発だと思います。
