サイトロゴ まいの雑記帳
DXごっこの新たな玩具、Vibe Codingは無能を糊塗する行為に過ぎない

DXごっこの新たな玩具、Vibe Codingは無能を糊塗する行為に過ぎない

投稿した日
2025/08/18
読了まで
7.70分で読み終われます (4,621文字)

DXごっこの新たな玩具、Vibe Codingは無能を糊塗する行為に過ぎない

はじめに

タイトルは少し、過激すぎたかもしれません。
巷ではこういう扇情的な見出しで読者の気を惹き、中身のない文章を読ませるのが流行りの手法らしいので、少しだけ真似をしてみました。

先日、Twitter(自称X)このような投稿を見かけ、少し思うところがありました。

プログラミング、AIエージェントが必須ツールになってきてお金かかる趣味になってきちゃって最近学生が大変という話を聞いたことある
https://x.com/kotomin_m/status/1957057306686058496🔗

「LLMが必須だから、プログラミングはお金がかかる」。
一見すると、現代の学生さんを心配しているようにも読めます。
ですが、わたしはこのLLMが必須という部分に、強い違和感を覚えてしまうのです。

言葉を聞くだけで不快になるレベルで、わたしは「Vibe Coding」という、この種の思考停止を心の底から嫌っています。
必須と言えてしまうほどLLMに依存しなければまともなロジックを書けないのなら、もはやプログラミングそのものに適性がないのではないでしょうか。

LLMは必須なのか

そもそも、プログラミングの文脈における必須のツールとは何でしょう。
プログラミングで言うなら、コードを書くためのエディタや、それを動かすための実行環境がそれに当たります。
これがないと、何も始まりません。

では、LLMも同じレベルで必須なのでしょうか。
少なくとも私はそう思いません。

LLMは、確かに便利なアシスタントです。
例えば、書いていてあまり楽しくない退屈なロジックの実装を手伝わせたり、あるいは厳密な仕様が定まっているマイクロサービスの定型的なコードを生成させたりする場面では、非常に役立ちます。

ですが、ソフトウェア開発で本当に頭を使う核心的な部分はそこではありません。
何を作るべきかを考える要件定義や、どういう構造で作るかを決める設計、そしてなぜか動かない原因を根気強く探るデバッグといった、答えのない問題に対して自分の頭で論理を組み立てていく作業にあります。
これらこそが、プログラミングの本質だとわたしは思うのです。
LLMは、この思考のプロセスそのものを肩代わりしてくれるわけではありません。

LLMがなければ何も出来ないレベルなら、それはもうプログラミングとは呼べない別の何かです。

Vibe Codingのツケ

LLMの出力した任意のコードを、よく理解しないままコピペして「なんとなく動いたからヨシ」とする。
この雰囲気(Vibe)で進めるコーディングは、将来、必ず大きな問題を引き起こします。
所謂、技術的負債というものです。

この光景、どこかで見たことがあると思いませんか?
そう、数年前からDX推進という大義名分のもと、オフィスに蔓延したあの光景です。

引き継ぎ資料もなく、書いた本人にしか解読不能な野良VBAマクロ。
あるいは、複雑に絡み合った矢印と条件分岐で、もはや誰も全容を把握できない秘伝のタレ化したPower Automateフロー。

これらは、目の前の手作業を短絡的に自動化しただけで、長期的な保守性という視点が絶望的に欠けていました。

Vibe Codingは、この構造と全く同じです。
ツールがExcelからLLMに変わっただけで、やっていることは思考停止による負債の自動生成に他なりません。
ツールが新しくなったからといって、使う側の人間が何も学んでいなければ、生まれてくるものが良くなるはずもないのです。

結局のところ、このやり方は、中途半端な知識でDXを謳いながら、質の低いVBAマクロやPower Automateのフローを量産していた層にウケているだけではないでしょうか。

例えば、危険なコードを無自覚に埋め込んでしまうことがあります。
多くのLLMにおいて、特筆すべき指定がない場合はセキュリティを全く考慮せず、外部からの攻撃に非常に弱いコードを平気で提案してくることがあります。

// 巷でよく観測しているもの
func GetUser(w http.ResponseWriter, r *http.Request) {
    // パスワードをハードコード
    db, err := sql.Open("postgres", "user=admin password=password123 dbname=mydb sslmode=disable")
    if err != nil {
        // ...
    }

    // サニタイジングしてね
    userID := r.URL.Query().Get("id")
    query := fmt.Sprintf("SELECT name FROM users WHERE id = %s", userID)
   
    row := db.QueryRow(query)
    // ...
}

これをそのまま使えば、簡単に不正アクセスされてしまいます。
なぜ危険なのかを知らなければ、LLMのサジェストを疑うことすらできません。

あるいは、誰も触れないブラックボックスが完成してしまうことも少なくありません。
複雑な計算ロジックなどをAIに丸投げすると、どうしてその答えになるのか誰にも説明できないコードが出来上がることがあります。
これでは、後からバグが見つかったりしても、誰も修正できませんよね。

さらに、見えないところでパフォーマンスが劣化するというのも典型的なパターンです。
一見正しく動いているように見えても、実は非常に非効率なコードが生成されることもよくあります。

// よくあるN+1問題
func getTimelinePosts(db *sql.DB, currentUserID int) ([]Post, error) {
    // まずフォローしているユーザーの一覧を取得 (1クエリ)
    rows, err := db.Query("SELECT followed_id FROM follows WHERE follower_id = ?", currentUserID)

    // ... 
    var followedUserIDs []int
    for rows.Next() {
        var id int
        rows.Scan(&id)
        followedUserIDs = append(followedUserIDs, id)
    }

    var allPosts []Post
    // ユーザーの数だけループ内でクエリが発生 (nクエリ)
    for _, userID := range followedUserIDs {
        postRows, err := db.Query("SELECT id, content FROM posts WHERE author_id = ?", userID)
        // ...
    }
    return allPosts, nil
}

最初は問題なくても、データが増えるにつれてシステムがどんどん重くなっていく。
そんな時限爆弾が簡単に作れてしまいます。うれしいですね。

エラー読もうね

ところで、エラーメッセージを読まない人が多すぎませんか?

エラーメッセージには、問題解決のヒント、ほとんど答えそのものが書かれています。
それなのに、画面に表示された赤い文字列を、ただの失敗という記号としてしか認識できず、その内容を読み解こうとすらせずに「動きません、助けてください」とスクリーンショットだけを貼り付ける。
これはあまりにも非効率ですし、他者の時間を無駄に奪う行為です。

彼らにとってエラーとは、解決すべき論理的なパズルではなく、ただただ不快な邪魔者でしかないのでしょう。
確かに、メッセージの多くは英語です。でも、現代には優秀な翻訳ツールがいくらでもあります。
それを乗り越えられないのは、もはやスキル以前の問題ではないでしょうか。

LLMにエラーメッセージをそのままコピペして答えを得る行為も、この延長線上にあります。
自分で「読む」「理解する」という最も重要なステップを放棄して、答えだけを求めているのですから。

エラーを読むという基本的なステップを飛ばして、一体何を学ぼうというのでしょうか。
それは学習という行為を、あまりにも侮辱しているように、わたしには思えてなりません。

本当に「お金がかかる」の?

最後に、「プログラミングはお金がかかる」という点についても、少し見方を変える必要があると思います。

プログラミングを学ぶための言語やツール、そして情報のほとんどは、今も昔も無料で手に入ります。
本当に必要なのは、有料のLLMサービスを契約することよりも、自分の頭で考え、試行錯誤するために時間というリソースを投資することではないでしょうか。

その最も大切な投資を惜しんで、安易な答えにお金を払ってしまうことこそが、本当の意味でのコストなのかもしれません。

さいごに

誤解しないでほしいのですが、わたしはLLMという技術そのものを否定しているわけでは全くありません。
あれは本当に素晴らしい道具です。

退屈な作業を驚異的な速度で片付け、私たちの思考を拡張してくれる可能性に満ちています。
賢明な人間が使えば、これほど心強いパートナーはいないでしょう。
そう、賢明な人間が使えば、の話ですが。

結局のところ、どんなに優れた道具も、使う人間を選ぶのです。
そして、Vibe Codingに何の疑問も抱かない人々を見ていると、彼らはその選別に残念ながら漏れてしまったのではないか、と感じずにはいられません。

もしかしたら、彼らのやり方は次世代の働き方であり、思考という最もコストのかかる作業をLLMに外部委託する、究極の効率化なのかもしれません。
面倒なエラーメッセージの読解や、地道な学習プロセスから解放され、もっとクリエイティブな作業、つまりLLMへの指示出しに集中できるのですから、素晴らしいことなのでしょう。
タイパも最高ですよね。

しかし、そのクリエイティブな指示出しですら、いずれはより優秀なモノに最適化されてしまう未来がすぐそこまで来ていることに、彼らは気づいているのでしょうか。
思考を放棄した先に待っているのは、自らが不要になるという、あまりにも当然な結末です。

まあ、わたしがここで何を言っても、彼らの耳には届かないのでしょう。
彼らはこれからも「動けば正義」「効率こそすべて」と信じ、その場しのぎのコードを量産し続けるのだと思います。

彼らが残していくのは、動いているように見えるだけのデジタルな廃墟です。
そして、その瓦礫を片付けるのは、いつだって物事の本質を理解しようと努めてきた人なのです。
彼らは自分たちが楽をすることしか考えておらず、その尻拭いを未来の誰かがすることを全く想像していない。
その想像力の欠如こそが、彼らの行為は害悪以外の何物でもありません。

結局、彼らが何もしないでいてくれることが、社会にとっては一番の貢献なのかもしれません。
だから、お願いだから、静かに布団にでも入って寝ていてほしいと心から思っています。

ブログの更新をお知らせ

RSSで購読すると新しい記事の投稿を知ることができます。