Vibeコーディングは低品質な作業の言い訳にはならない
(addyo.substack.com)- AIベースのVibeコーディングは革新的だが、品質のないスピードは危険だと警告する文章
"もっと速く動き、もっと多く壊せ"
"vibe coding、2人のエンジニアが50人分の技術的負債を生み出せるやり方"
- このシリコンバレーの古いスローガンをひねった表現は、最近エンジニアリングコミュニティで「vibe coding」という概念として話題になっている
- AIベースの開発がソフトウェアの作り方を革新しているのは事実だが、だからといって厳密さ、レビュー、職人技を捨ててよいという免許にはならない
- "vibe coding"は低品質な作業を正当化する言い訳にはなりえない
- 長所を認めるなら、AI支援コーディングはゲームチェンジャーになりうる
- 新しいプログラマーや非専門家の参入障壁を下げ、必要を説明するだけで動くソフトウェアを作れるようにする
- これは創造性を解放し、より多くの人が自分の問題をカスタムソフトウェアで直接解決できるようにする
- こうした流れはパーソナルソフトウェアのアンバンドリング（既製アプリの代わりに小規模なAIベースのツールを使うこと）というトレンドの一部と見なされている
- 熟練したエンジニアも恩恵を受けられる
- しかし経験豊富なエンジニアなら誰でも言うように、最後に車輪が外れるならスピードには何の意味もない
- そしてまさにここで亀裂が見え始める — vibeと実際の現実の間のギャップ、つまり保守可能で堅牢なソフトウェアを構築する際に伴う現実との違いだ
不都合な真実: 品質は自動ではついてこない
- hypeは大きいが、vibe codingに対するベテラン開発者たちの懐疑も決して小さくない
- 核心的な批判はこうだ: AIが素早くコードを吐き出すからといって、そのコードが良いとは限らない
- 実際、AIが生成したコードをそのまま信じて使うのはかなり危険になりうる
- 「2人のエンジニアが50人分の技術的負債を作る」という冗談は完全な冗談ではない
- レビューされていないAIコードは技術的負債を大規模に増幅させうる
→ この負債はコードを脆くし、保守しにくくし、長期的に大きなコストを招く
- vibe codingで作られたプロジェクトは、しばしば見た目は素晴らしく見える（"ちゃんと動くね、デプロイしよう!"）
- しかし実際には、次のようなリスク要因を隠している:
- エラー処理がない
- パフォーマンスが低い
- セキュリティの実装が不安定
- ロジック構造が弱く壊れやすい
- こうしたプロジェクトは砂の上に建てられた構造物のようなもので、
- 私がそう呼んでいる表現では**「カードでできた家(house of cards code)」**だ —
見た目は完成しているようでも、現実的な圧力には簡単に崩れる - ジュニア開発者の最初の大きな機能がほぼ動いているのに、予想外の入力ひとつですぐ壊れる場面を見たことがあるなら、その感覚はわかるはずだ
- AIは大量のコードを素早く作れるが、量は質を意味しない
- "AIはチームに加わった非常に熱意のあるジュニア開発者のような存在だ"
- → この概念はForrest Brazealのイラストでうまく説明されている
- このリスクは単なる仮説ではなく、実際の保守の面でも問題は現実的だ
- AIが作ったモジュールが過度に複雑だったり理解しにくかったりする場合、誰が保守を担当するのか?
- しかも最初に書いた開発者ですらAIが作ったコードを完全に理解していないなら、
そのコードは今後の修正や拡張において悪夢になりうる
- セキュリティはもう一つの大きな問題だ
- AIは見た目にはよく動くコードを作れるが、その中にはSQLインジェクションのような致命的な脆弱性が潜んでいることがある
- あるいは、エラー処理が不十分である可能性もある
- こうした問題が徹底したレビューなしにプロダクションへ反映されれば、実際の事故につながりかねない
- もう一つの問題はプロンプトへの過剰適合(overfitting to the prompt)だ
→ AIはあなたが依頼したとおり正確に実行するが、それが本当に必要なものとは限らない - 人間の開発者は実装しながら設計の誤りや誤解を見つけ、それを修正する
- 一方でAIはこうした誤解をまったく認識できず、人が見つけて直さなければ問題は放置される
- もちろん、これらすべてがAIが良いコードを絶対に書けないという意味ではない —
- AIはときに素晴らしいコードを生み出す
- ただし、そのコードを実際に使ってよいか判断するには、次の3つが必ず必要だ:
- 文脈(context)
- 批判的レビュー(scrutiny)
- 経験と専門性(expertise)
- 2025年時点で、私たちが使っているAIは熱意はあるが経験不足のアシスタントのようなものだ
- 1年目の新人開発者に何の監督もなくシステム全体の設計を任せないのと同じように、
AIのコードもレビューなしで受け入れてはならない - 「AIマジック」への期待は、いまやソフトウェアエンジニアリングの現実と調和しなければならない
- では、どうやってバランスを取るべきか?
- 重要なのは、vibe codingを完全に排斥する必要はないということだ
- vibe codingはときに非常に有用になりうる
- ただし重要なのは、訓練されたやり方で統合すること — つまり、AIを制約が明確なツールとして見る視点だ
- これはすなわち、人間がループの中にいるべきであり、私たちの品質基準とエンジニアリング原則を守る形でAIを使うことを意味する
AIは代替者ではなくインターンです（人間がループの中にいるべき）
- vibe codingを効果的に活用するには、AIを「非常に速いが未熟なチームのインターン開発者」として扱うというマインドセットへの転換が必要だ
- つまり、あなた — シニアエンジニアやチームリード — が依然として成果物に対する最終責任者である
- AIはドラフトを素早く出せるかもしれないが、批判的な視点でレビューし、修正し、品質基準を満たしているか確認しなければならない
- 熟練した開発者たちはこのプロセスを直感的に実践している
- AIがコードを提案したとき、「Accept」を押してそのまま進むのではなく、次のように対応する:
- AIが書いたコードをまず読んで理解する — まるでジュニア開発者が書いたコードのように扱う
- コードが単一ブロックだったり雑然としていたりする場合はモジュール化・リファクタリングする — より小さく明確な単位に分割する作業を行う
- 不足している例外処理やエッジケースを自分で追加する — nullチェック、入力検証などはAIがよく見落とす
- 緩い型や不完全な抽象化を強化する — 暗黙の前提を明示的な契約へ変える
- AIが選んだアーキテクチャや手法が非効率でないか評価する — 例: ブルートフォース処理、グローバル状態の導入など
- テストを書く、または手動テストを行う — AIがユニットテストを生成したとしても、そのテストが有効か必ずレビューする
-
これらすべてのプロセスを通じて、AIが作ったコードに**エンジニアリングの知恵(wisdom)**を注ぎ込むことになる
-
この組み合わせは非常に強力になりうる — AIはスピードを提供し、人間は信頼性を保証する
-
実際、研究や現場の経験によれば、シニア開発者はジュニアよりもAIコーディングツールから大きな価値を得ている
-
その理由は、シニアにはAIの出力を正しく導き、誤りを修正できる知識と経験があるからだ
-
一方で、ジュニアはAIを絶対的な権威のように誤って信じてしまう危険が大きい
- したがって重要なルールが一つ生まれる:
→ AIが書いたコードは必ずレビューしたうえで取り込むこと - 新人開発者のPRをレビューするように、1行1行読んで完全に理解してからでなければマージしてはならない
- AIのほうが賢いと前提してはならない — ほとんどの場合そうではない
- 理解できない部分があるなら:
- プロンプトを再調整して明確に依頼するか
- 自分でそのコードを書き直すのが望ましい
- AIの出力はあくまで「下書き」であり、必ずレビューを経るべきだ
- チーム開発の環境であれば:
- 誰かがAIを使ってコードを作ったなら、
- そのコードについてレビューで自ら説明し、正当化できなければならない
- 「とにかく動くので」は通用しない — 人間が理解し保守できてこそ本当のコードだ
- もう1つのベストプラクティスは、設計は人間、実装はAIという分担です。
- つまり、AIはCRUD APIのようなすでに定義された作業を素早く実装するために活用します。
- 一方で、「スケーラブルなマイクロサービスアーキテクチャを設計して」といった依頼は人間が担うべきです。
- 高レベルの設計と中核となる意思決定は、人間の役割として残すべきです。
- 要するに、AIには単純な反復作業（grunt work）を、人間には思考と判断（brain work）を任せようということです。
- コミュニケーションと文書化も非常に重要になる
- 複雑なアルゴリズムや不慣れなライブラリをAIに依頼したなら、
- その選択の理由と意図を必ず文書化すべきです。
- 将来の保守担当者、あるいは未来の自分自身が、そのコードをなぜそのように作ったのか理解できる必要があります。
- 重要なAIコード生成で使ったプロンプトそのものを記録しているチームもあります。
→ デバッグ時にAIとの「会話履歴」を参照できるため有用です。
- 結論として、人間の関与は選択肢ではなく必須事項です。
- 人間を介さずAIコードだけを使うのは、ソフトウェア品質をサイコロ任せにするようなものです。
- AIがシニアエンジニアの全体的な理解力を代替できる時代は、まだ来ていません。
- vibe codingはパートナーシップであるべきです —
→ AIはスピードを出せるが、人間はそのスピードにシートベルトを締める役割を果たす
高品質なvibe codingのための実践ルール
- ここまでの議論を、実行可能なルールとベストプラクティスとして整理してみましょう。
- これは新しい時代の_「素早く動きつつ、すべてを壊さないための」_ハンドブックだと言えます。
- vibe codingを行いながらも品質を守るためのガードレールとなるルールです。
- Rule 1: Always Review AI-Generated Code / AIコードは必ずレビューする
- 例外はありません。AIが書いたすべてのコードは、ジュニア開発者が書いたコードのようにレビューすべきです。
- 個人レビューであれ同僚レビューであれ、必ず実施します。
- Copilot、ChatGPT、Cursorなど、どのAIでも同じです。
- レビューする時間がないなら、そのコードを使う時間もないということです。
- レビューなしでAIコードをマージするのは、リスクをそのまま抱え込むのと同じです。
- Rule 2: Establish Coding Standards and Follow Them / コーディングスタイルと基準を定めて守ること
- AIは学習したコードスタイルをそのまま反映するため、一貫したチーム基準がなければ品質にばらつきが出ます。
- チームのスタイルガイド、アーキテクチャパターン、コーディング規約を明確に定義する必要があります。
- 例: 「すべての関数にはJSDocとユニットテストが必要」→ AIが生成したコードにも同様に適用します。
- 階層構造やレイヤードアーキテクチャを採用しているプロジェクトでは、
AIがUIコードの中にDB呼び出しを入れないよう、リファクタリングが必須です。 - AIによくあるミス（例: 複雑すぎる関数、deprecated APIの使用など）を検出するlintや静的解析ルールの導入を推奨します。
- Rule 3: Use AI for Acceleration, Not Autopilot / AIは加速装置であって自動操縦ではない
- vibe codingは、よく理解している作業を素早く処理する用途に使うべきです。
- 良い活用例:
- ボイラープレートの生成
- コンポーネントのスキャフォールディング
- 言語変換
- シンプルなアルゴリズムの骨組み作成
- 危険な使い方の例:
- 曖昧な説明でモジュール全体を設計させる
- よく知らないドメインでコード生成を試みる
- そのコードが恒久的に残る予定なら、必ずvibeモードからengineeringモードへ切り替える必要があります。
- Rule 4: Test, Test, Test / テストは必ず行う
- AIがコードを生成したからといって、自動的に正解になるわけではありません。
- すべての主要経路についてテストを書くことが必須です。
- AIがテストも作ってくれた場合は、そのテストが本当に有効かどうかも確認が必要です。
- 特にUI機能やユーザー入力が多い部分では、実際にクリックする確認や異常入力のテストが必須です。
- vibe-codedなアプリは、ハッピーパスだけはうまく動く一方で、例外的な入力に弱いことが多いです。
- Rule 5: Iterate and Refine / 繰り返し改善し、磨き込む
- AIが最初に出した成果物に満足できないなら、そのままにせず再試行するかリファクタリングしましょう。
- vibe codingは対話ベースの反復的なプロセスです。
- 例:
- 「このコードをもっと簡潔にして」
- 「小さな関数に分けて」など、プロンプトを調整する
- あるいは自分でリファクタリング → 修正ポイントを整理 → 再度プロンプト → 反復
- AIとのサイクルを活用する戦略が効果的です。
- Rule 6: Know When to Say No / 断るべきときを知る
- vibe codingが常に最善とは限りません。
- 重要な設計やセキュリティが求められる場面では、自分で書くほうがよいです。
- 例:
- セキュリティ関連モジュールは自分で設計し、一部だけAIを使う
- 単純な問題に対してAIが複雑に答えるなら、自分で書いたほうが速い
- AIが問題を適切に解決できないときは、意地を張らず手動モードへ切り替えるべきです。
- 「AIがやってくれたから」は、自分のコードを理解していなくてもいいという言い訳にはなりません。
- Rule 7: Document and Share Knowledge / 文書化し、知識を共有する
- AIが生成したコードも、自分で書いたコードと同じくらい文書化されるべきです（場合によってはそれ以上に）。
- 直感的でない判断や特殊な実装があるなら、コメントを残すべきです。
- どの部分がAI生成なのかをチームに明確に共有します。
- 主要なAIコードで使ったプロンプトをそのまま保存しているチームもあります → デバッグに役立ちます。
- これらのルールに従うことで、チームはvibe codingの生産性を最大限に活かしながら、リスクを最小限に抑えることができます。
- 重要なのは、AIが人間を置き換えるのではなく、補完することです。
- AIは反復作業を素早くこなし、人間は批判的思考と創造性を担います。
- 私たちはAIと**一緒にコードを作る（co-create）**時代に生きています。
vibe codingがうまく機能する場合 vs 崩れる場合
- vibe codingがどこで力を発揮し、どこではそうならないのかを明確に知ることも重要です。
- すべてのプロジェクトや作業が、AIベースのワークフローに同じように適しているわけではありません。
- 以下は、業界での経験や事例をもとに整理した活用の区分です。
- 👍 うまく機能する場面 (Great Use Cases)
- Rapid prototyping (迅速なプロトタイプ作成)
→ vibe codingのスイートスポット。小さなアプリや機能のアイデアがあるとき
→ AIアシスタントを使って、素早く概念実証やプロトタイプを作成できる
→ コードが多少粗くても問題ない — 重要なのは アイデアの検証
→ 週末プロジェクトなどで、AIだけでアプリを作り、コンセプトを試す事例が多数ある - One-off scripts / Internal tools (使い切りスクリプト、内部ツール)
→ ログファイルの解析、個人作業の自動化、社内ダッシュボードなど
→ 失敗してもリスクが大きくない環境では、vibe codingは時間節約に効果的
→ プロダクション級の品質が必要ない場面では、「今すぐ動くもの」を素早く作れる - Learning and exploration (学習と実験)
→ 新しい言語やAPIを学ぶ際に、AIにサンプル生成を依頼する
→ 完璧なコードでなくても、学習素材としては十分
→ まるで 仮想のTA(ティーチングアシスタント) がさまざまな試行を見せ、それを人が整える感覚 - Boilerplate-heavy tasks (ボイラープレート中心の作業)
→ 例: 似たようなデータクラスを10個生成、CRUDを実装
→ 構造さえ明確なら、AIは反復的なパターンを正確になぞってくれる
→ 機械的な作業を素早く片付けて、人は重要な部分に集中できる
- Rapid prototyping (迅速なプロトタイプ作成)
- 👎 問題が起きやすい場面 (Not-So-Great Use Cases)
- Enterprise software / Complex systems (エンタープライズ級ソフトウェア、複雑なシステム)
→ 複雑なビジネスロジック、並行性、セキュリティ、コンプライアンス要件があるシステム
→ AIは明示的に伝えなければそうした条件を理解できず、理解していても反映が不十分なことがある
→ 例: フィンテック決済システム、航空宇宙制御ソフトウェアなどは 絶対にAI単独に任せてはいけない
→ こうした環境では一部の補助しかできず、最終的な品質には 人間のQAと専門性 が不可欠 - Long-term maintainability (長期的な保守性)
→ 数年にわたって続くコードベースは 最初から構造が重要
→ AIで継ぎはぎしながら作ったコードは 一貫性に欠け、後続の保守に大きな負担を生む
→ むしろ初期に時間をかけて 明確なフレームワークと設計 を定める方がよい
→ 多くの初期ユーザーが、vibe codingで節約した時間は
後になって リファクタリングや整理作業で結局消えてしまう と共有している - Critical algorithms / Optimizations (高性能アルゴリズムや最適化作業)
→ 例: カスタムメモリ管理、超高速ソートアルゴリズムなど
→ AIは小規模な入力に対してはそれなりでも、スケールへの考慮が不足しがち
→ 警告なしに遅くなったり、誤動作したりする可能性がある
→ こうした部分には依然として 人間の創造性と深い理解 が必要 - Explainability and clarity (明確性と説明可能性)
→ コードが 他の開発者や監査担当者にとって明確に読めなければならない場面
→ AIが過度に抽象化したり複雑な方法でアプローチしたりすると、可読性と保守性が深刻に低下
→ 現在のAIは「短く簡潔なコード」を常に志向するわけではない → ときに過度に冗長だったり、不必要に抽象化されたりする
→ こうした場合、人間によるリファクタリングと明快なコード記述が必要
- Enterprise software / Complex systems (エンタープライズ級ソフトウェア、複雑なシステム)
- 要するに、vibe codingは強力な加速ツールだが万能の解決策ではない
- 速度が重要で、結果を何度か手直ししてもよい作業には非常に効果的
- 一方で、ミッションクリティカルなソフトウェアを一度にAIへ任せるのは危険な試み
- たとえるなら: レーシングドライバーにスクールバスを任せるようなもの — 良い道具でも用途を誤っている
- いつかAIがあらゆる開発の基本ツールになるかもしれないが、今日はまだそうではない
- 今日私たちがすべきなのは、AIを正しい問題に、正しい方法で、正しい責任のもとで使うこと
結論: 慎重にvibeせよ – スピードを楽しみつつ、職人精神を失わない
- vibe codingとAIベースのソフトウェア開発は 道具の進化における巨大な飛躍 を意味する
- この流れは 一時的な流行ではなく、すでに定着した現実 であり、今後さらに洗練されていく
- 未来を見据えるエンジニアリングチームなら、これを無視してはならない
- 以前の自動化ツールや高度なフレームワークが従来の開発手法を追い越したように、
AIをうまく活用するチームがそうでないチームを上回る可能性は高い - この記事のメッセージはvibe codingを拒否せよというものではない —
→ 目を開いたまま、エンジニアリングの基本を守って向き合えということ
- 最も重要な教訓: スピードは品質なしでは無意味
- バグが多く保守不能なコードを素早くデプロイするのは、スピードを出して崖に向かうだけ
- 最高の開発者とは、AIでスピードを上げつつシステムを壊さない人たち
- AIが重い荷物を持ち、それが正しく立っているかを人間が確認する構図
- その バランスポイント(sweet spot) を見つけることが重要
- 技術リーダーとマネージャーのための実践ポイント:
→ AIは 責任を持って使う道具 だという文化をチームに根付かせる必要がある- vibe codingを奨励しつつ、コードベースを守るための明確な期待値とルール も同時に定めるべき
- AI生成コードも必ずコードレビューの対象とし、
- 「このコード、理解できる？」という問いが自然な文化を作る
- チーム全体が AIと効果的に協働できるよう能力強化に投資 する
- 良いプロンプトの書き方、AI提案の評価方法など新しいスキルセットを導入
- これは過去の高級言語への移行やGit導入時と同様のパラダイムシフトである
→ 早く適応するチームが利益を得るだろう
- ソフトウェアエンジニアリングで私たちが本当に重要視すべきものは、依然として次のとおり:
- ユーザーの問題を解決すること
- 信頼できるシステムを作ること
- 学び続けること
- vibe codingは 手段であって、目的ではない
- ユーザーにより速く、より良い価値を提供できるなら素晴らしいツール
- しかしその過程で、私たちが信頼すべき品質やセキュリティを 犠牲にさせる なら、使用は控えるべき
- 本質は今も有効だ:
→ 明確な思考、要件理解、変化に備えた設計、徹底したテスト
- 最後にこの精神を刻もう:
→ 「速く動け、だが壊すな – たとえ壊しても必ず直せるように。」 - スピード感を持ってコードを書いても、その土台には 堅牢なエンジニアリング基盤 が必要だ
- AIは職人の手に握られた強力なノミ になり得る
→ だが、そのノミを扱うのは依然として人間の手である
- だから開発者たちよ、vibeせよ – ただし慎重にvibeせよ
- 未来を受け入れつつ、私たちをここまで導いてきた 基本原則を手放さないようにしよう
- vibe codingは 低品質を正当化する言い訳ではなく、
→ 人間の判断力と機械の生成能力が結びつくとき、私たちがどれほど大きなものを作れるかを示す機会 である
- この原則を内面化したチームは、単に速くなるだけでなく、
→ 長く生き残る価値のあるソフトウェアを作ることになる
> Happy coding — そして vibeは高く、品質はもっと高く。
3件のコメント
+1
同感です。
長文注意
Hacker Newsの意見
「vibe coding」の意味が再定義された
AIコーディングの誇大宣伝が大きすぎて、現実的には満たせないと感じた
2000年代初頭に大企業が低所得国へ開発作業をアウトソーシングしようとしていた時期を思い出させる
AIをチームのジュニア開発者として扱うと、かえって時間がかかることがある
ユースケース次第で異なる
ソフトウェア品質にはさまざまな観点がある
AI支援コーディングが開発者の成長に悪影響を及ぼすかどうかという問いがある
vibe codingを通じて作業の難易度を把握する
人はエネルギーを節約しようとする傾向があり、vibe codingは省力的な開発を可能にする
記事全体は「vibe codeを本番環境にデプロイする前に人間がレビューすべきだ」という一文を膨らませたもののように見える