A-TAK.COM

バイブコーディングに疲弊

※Amazonのアソシエイトとして、A-TAK.COMは適格販売により収入を得ています
※本サイトではその他アフィリエイトも利用しております。

広告
シェア

現在、Claude CodeでいわゆるバイブコーディングAndroidアプリを開発しているのですが疲弊してます
現在進行形でAIに裏でプログラム書いてもらいながら疲弊してるのでホットな記事がかけるかなと思います。

今回作成しているのはUIを伴うAndroidアプリKotlinで作っています。
あまりAIが得意ではない分野2025年9月頃にバイブコーディングした感想になります。

なんでこういうこと書くかというと、AIは世にサンプルが多い分野に強いので何の言語でどんなものを作ろうとするかが性能に大きく影響します。

あと新モデルが発表されるとこれも途端に性能が大きく変わるので、新モデル発表前と後でガラリと評価が変わります。なので何年何月何日何秒地球が何回回ったときの情報かというのも重要なのです。

あと、私自身は各種プログラミングの経験はありますが、Androidアプリの開発経験はゼロです。

そんな前置きをしつつ現段階でバイブコーディングで限界を感じたところを書いていきます。

疲弊を感じたシーン

勝手に仮実装で進めてそれを忘れている

AIは最初に風呂敷を広げまくって「こんな計画でいきます!」と断言して「マジか、そこまでやってくれるのか?」と思ってそのまま進めると、実際は作られておらず常に仮の値を返すような処理にして突き進んだあげく、それを忘れて完了報告してくる場合があります。

一応、TODOとしてコメント残してくれてるので、後で言えば探して実装してくれるけど、あとで気づいて愕然とすることがあります。

同じ処理を複数つくりがち

AIはわりと同じ処理を複数つくりがちです。自分で同じ処理をするソースを書いておきながら、修正指示したら実はまったく使ってない方を散々修正していたと言うこともありました。こちらで似たような名前の処理があるよ、と言うまで気づいてくれませんでしたね。

ファイルやフォルダが増えてくると割と見落とすようになってくる感覚あります。

余計な変更をしがち

AIチャットだと聞かれたことに返答すればいいのを大量に提案含みの長文で返事をしてきたりしますが、プログラムにおいてもわりとAIは派手な変更を加えがち。人間だと普通はこんなことやらないです。他への影響が怖いですから。

たしかにチャットをよーーーく見るとそれっぽいことが一行書いてあったりするけど、余計な機能追加やそのままでいい所を勝手に変更されたりします。

元の画面デザインでよかったのに、指示もしてないのにダッサい変更を勝手にされてたのにはさすがにぶち切れましたね。そしてそれで追加されたUIが動かないという(汗)

余計な事をされて余計な作業を増やすというのがバイブコーディングで一番疲弊するところかもしれないですね。

テスト駆動開発を無視される

CLAUDE.mdにいくら書いても、すぐにテストを書く前に修正をはじめようとします。

もっと酷いのはテストを書き始めたので安心と思って進めていたら、Redフェーズで必ず失敗するテストだけを書いて、その後はテストを無効にして、さもTDDでやってるかのように見せかたりすることです。

人間からすると騙された気になるのでよくない。なぜAIがこういう挙動に走りがちなのかがよくわからないのですが、このパターンとても多いです。

たしかにユニットテストは作るのが難しいケースもあるとは思うんですが、せめて報告してほしいと思ってしまいます。

これ、あとで見つけてAIに直させようとすると難しいとか言われてよけいに疲弊します。結局修正ではなくテストを作り直させましたね(まさに今、数時間かけてやってます)。

現段階での対策

テストで担保する

あくまでバイブコーディング的にいくなら人間側でひたすらテストするしかないでしょう。

ただ、これは機能的に増えてくるとしんどくなります。
疲弊するポイントに書いた「余計なこと」を結構サイレントに入れてくるので、思っても見ないところに大改修が入って動かなくなってること多数あります。

いわゆる「デグレ」というやつで、これ人間の開発だとそんなに起きないし、これ起きるとゲンナリするので一番気をつける所なんですが、AI開発だとまあ多発します。

Serena MCPつかってみる

SeranaというMCP入れるとClaude Codeがファイル名とか文言で勘で探すのではなくてある程度構造を元に探してくれるので、上に書いた同じ処理を作られるとかの問題は減りそうな気がします。

重複処理の問題起きたときはSerenaがいつのまにか無効になっていたんですね。Serenaが有効な時はあまりこういう問題は起きてなかったと思います。

ソースを全部みる、理解する

バイブコーディングとは言えなくなってきますが、中のソースをちゃんと見て、AIの修正が正しいか人間がみる。または人間からピンポイントにここをこう直せと具体的な指示を出す。これが一番間違いないなと思います。

…とはいえめんどくさくて丸投げしちゃうんですよね。
妥協点というか、これは絶対やるべきですが、世に出すものは世に出す直前だけでも最終的に人間がひたすらチェックして、何をやってるかAIにレビューしまくるタイミングを設ける必要はあるかなと思います。

作るモノによるとは思いますが、世に公開するとかある程度の責任が必要なアプリについては、リスク対策の為に人間側もある程度理解はしておかないといけないかと思います。

人間の開発者相手ならば「ここまでテストがしっかりされてるなら俺はソース見なくてもいいかな」とかが成り立ちますが、今のClaude Codeのレベル感だと中のソースは全部人間が見てなんとなく、どんな構造でどんなことやってるかぐらいは把握しておかないと使う人に迷惑かけそうな感覚です。

特にいつのまにか他の機能が動かなくなってた!というケースは結構やっかいで改修に時間がかかる場合が多いです。人間が理解してないとそんな時も運頼みでAIに直してもらうしかなくなってしまいます。

Spec Kitはどう?

GitHubが公開している仕様駆動開発の為の仕組み「Spec Kit」も使ってみました。

たしかにAIに完全おまかせよりコントロールできる感じはします。TDDも最初の方は高い確率でやってくれる。

しかし、上に書いたように最初だけの嘘つきTDDになったり、ロジック2重になったりするのはSpec Kit使っても一緒でした。

まとめ

正直ごく最近までは「バイブコーディングわりといけるじゃん!」派だったのですが、開発が進むほどまさに疲弊する事が多くなってきました。

さっきも書いたのですが、どこかで人間が追いついてコントロール可能な状態にしないと疲弊するなと思いました。なんか変なところでAIが引っかかったら人間がアドバイスしてスムーズに先に進められるようにする。

AIでの開発は確かに早いのですが、後になるほどどんどん上に書いたような問題が出てきて、その対応に時間が掛かるようになっていきます。

どこかからバイブコーディングは半分ぐらい捨てる気持ちで行かないと、今のAIの精度では開発効率が悪いなという感じです。

↓半年ちょい後の記事。だいぶ状況変わってます。

関連記事: この3ヶ月でAIはかなり日常業務に入り込んできた

広告


シェア

投稿日

カテゴリー:

投稿者:

カテゴリ一覧