正しいVibe Coding:AIツールは操作する人間次第で決まる
「Vibe Coding」は Collins 辞書の 2025 年の言葉。同時に「AI Slop」も選ばれた。この 2 つの違いは、キーボードの向こうにいる人間で決まる。
AI がコードの書き方を変えた年
2025 年初頭、Andrej Karpathy は新しいプログラミングの形を描写した。「完全にバイブスに身を任せ、指数関数的な成長を受け入れ、コードの存在を忘れる」
彼はこれを「Vibe Coding」と呼んだ。
数ヶ月のうちに、この言葉は爆発的に広まった。Collins 辞書は 2025 年の「今年の言葉」に選出。Y Combinator は、2025 年冬のバッチの 25%が、コードベースの 95%を AI で生成していると報告した。大手テック企業は、新規コードの 30〜50%が AI アシスタント由来だと発表している。
しかし、ここで見過ごされがちな不都合な真実がある。Merriam-Webster と Macquarie 辞書が 2025 年に選んだ言葉は別だった——AI Slop。「AI が生成した低品質なコンテンツで、しばしばエラーを含む」という意味だ。
この 2 つの言葉は矛盾していない。同じコインの裏表なのだ。

問題は AI ではない。使い方だ。
2025 年の Veracode の調査によると、AI 生成コードの 45%にセキュリティ脆弱性が含まれている。AI モデルは存在しないパッケージを 5〜21%の確率でハルシネーション(幻覚)する。攻撃者はこれを「スロップスクワッティング」として悪用し始めている。
一方、METR の厳密な調査では、経験豊富な開発者を追跡し、直感に反する結果を見出した。AI ツールを使用した開発者は、AI なしで作業した場合と比較して生産性が 19%低下していた。しかし、同じ開発者たちは、AI が生産性を 20%向上させたと見積もっていた。
認識と現実の間に 39 ポイントの乖離。
これは AI コーディングツールの否定ではない。使い方への警鐘だ。
AI Slop を生み出しているチームと、プロダクション品質のソフトウェアを出荷しているチームは、しばしば全く同じツールを使っている。違いは技術ではなく、方法論にある。
AI コーディングツールは「ただのツール」
Vibe Coding と呼ぼうが、AI コーディングと呼ぼうが、AI 支援開発と呼ぼうが、根本的な真実は変わらない。これらはツールであり、ツールには熟練した操作者が必要だ。
熟練した職人の手にあるチェーンソーは家具を生み出す。素人の手では災害を生む。
AI コーディングツールは、あなたが持ち込むアプローチを増幅する:
- 明確な問題定義 → 的を射た、有用なコード
- 曖昧なプロンプト → 汎用的で、しばしば壊れた実装
- 強いアーキテクチャビジョン → 一貫したシステム
- 技術的判断なし → たまたまコンパイルが通るスパゲッティ
重要な資質は変わっていない:
- 解決しようとしている明確な課題
- 「良い」がどういうものか知っているプロダクト開発の専門性
- 妥協しない品質基準
- レビュー、テスト、反復を行う規律
これらがなければ、製品を作っているのではない。スロップを生成しているだけだ。
本番環境で AI コーディングを使って学んだこと
JidouAI の私たちのチームは、AI コーディングツールを本格的に活用してきた。様々なツールを比較し、ワークフローを実験し、多くの失敗も経験した。
以下が私たちの発見だ。
コードレビューがボトルネックに
開発者が AI 支援でより速くコードを出荷し始めると、新たな問題が浮上した。コードレビューがボトルネックになったのだ。
レビューすべきコードの量が劇的に増加した。レビュアーが追いつけない。そして AI 生成コードには特有の課題がある——しばしば正しく見えるが、注意深く確認しないと見逃す微妙な問題を含んでいる。
私たちの進化
いくつかのフェーズを経験した:
フェーズ 1:興奮 全員が個別に AI ツールを使用。高速な出力。増大する技術的負債。
フェーズ 2:問題の表面化 コードレビューの滞留。一貫性のないパターン。レビューでは正しく見えた本番環境でのバグ。
フェーズ 3:プロセスの改善 AI 支援のコードレビューツールを導入。Spec 駆動開発のプラクティスを確立。ワークフローに合ったツールを標準化。
フェーズ 4:持続可能な速度 AI コーディングがプロセスに不可欠になった——ただし、品質を維持する構造化されたフレームワークの中で。
重要な洞察
ブレークスルーは「最高の」AI ツールを見つけることではなかった。Spec 駆動開発を基盤として確立することだった。
AI が一行のコードを書く前に、私たちは以下を用意する:
- 完全な仕様書
- 明確な受け入れ基準
- 定義されたアーキテクチャ制約
- テスト要件
人間が何をとなぜをコントロールする。AI はどうやって——実装、ユニットテスト、定型コード——をより多く担当する。しかし、人間がすべてをレビューする。
結果:Heimin をコンセプトから内部 POC まで2 日で、本番環境まで30 日で出荷した——コード品質を犠牲にすることなく。

AI コーディングツールの比較:本当に重要なこと
市場は混雑している:Cursor、Claude Code、GitHub Copilot、Windsurf、Google の Antigravity、OpenAI Codex。毎週新しい比較とベンチマークが登場する。
広範な評価の結果、本当に重要なことについての私たちの見解を述べる。
主要プレイヤー
| ツール | アプローチ | 最適な用途 |
|---|---|---|
| Cursor | 深い AI 統合を持つ VS Code フォーク | GUI +マルチファイル編集を求める開発者 |
| Claude Code | ターミナル、VS Code、Web すべて対応 | 柔軟な開発者、複雑なコードベース |
| GitHub Copilot | 拡張機能ベース、広い IDE サポート | GitHub エコシステム内のチーム |
| Windsurf | VS Code フォーク、エージェント重視 | 初心者、クリーンな UI 好み |
| Antigravity | VS Code フォーク、Gemini + Anthropic モデル対応、エージェント重視 | Google エコシステムユーザー、マルチモデルの柔軟性 |
| Codex | API 重視、エンタープライズ | 大規模自動化 |
私たちの選択:Claude Code + カスタムプラグイン
これらのツールを比較した結果、私たちのチームは一貫して、Claude Codeと専門プラグインの組み合わせが、ワークフローにおける速度と品質の最適なバランスを提供することを発見した。
違いを生む主要プラグイン:
- feature-dev:構造化された機能開発ワークフロー
- frontend-design:デザインシステムを意識した UI/コンポーネント生成
- code-refactor(自社開発プラグイン):品質チェック付きの体系的リファクタリング
なぜ Claude Code なのか?
ターミナルファーストのアプローチが意図的さを強制する。オートコンプリートの提案を無意識に受け入れることができない——何を構築したいかについての対話が行われる。チームのベストプラクティスを符号化するプラグインと組み合わせることで、技術的負債の源ではなく、真の力の倍増器になる。
ただし、「最高の」ツールは完全にチームのワークフロー、コードベース、好みに依存する。ツールよりも、その周りに構築する方法論の方がはるかに重要だ。
Spec 駆動開発の台頭
Vibe Coding が 2024 年の興奮だったとすれば、Spec 駆動開発は 2025 年の修正だ。
GitHub が Spec Kit をリリースした。AWS が明示的な「Spec モード」を持つ Kiro を発表した。JetBrains、Anthropic なども同じ洞察を強調している:仕様は、人間を助けるのと同様に AI を助ける。
業界全体で現れているパターン:
- 迅速なプロトタイピングと探索には Vibe Coding
- 本番コードには Spec 駆動開発
OpenAI の Sean Grove が言ったように:「最もうまくコミュニケーションできる人が、将来最も価値のあるプログラマーになる。新しい希少スキルは、意図を完全に捉える仕様を書くことだ。」
皮肉なことに、これは新しいことではない。ソフトウェアエンジニアリングの基本——実装前の設計——への回帰だ。ただし、エージェント型 AI 時代に適応した形で。

クローズドループ:Heimin で Heimin を構築する
ここからが面白いところだ。
Heimin はタスク管理ツールだ。私たちは AI コーディングワークフローを使って Heimin を構築した。そして Heimin の開発タスクを管理しているのは... Heimin だ。
これが私たちがクローズドループ開発サイクルと呼ぶものを生み出す:
- 仕様が Heimin に存在する — 詳細なタスク説明として、人間が Spec 草案を作成
- Claude(チャット)が MCP 統合でタスクを読む — コンテキストを理解し、AI との協業で Spec を最適化
- Claude Code が MCP でタスクを読み取り実行する — 洗練された仕様に基づいた実装
- 進捗更新が Heimin に自動で戻る — 完全なドキュメントが保存される
- レビューと反復が同じシステム内で行われる
構築しているツールが、それを構築するために使うツールなのだ。
これは単なる「ドッグフーディング」ではない。プロダクト管理と開発の間の根本的に異なる関係だ。AI コーディングアシスタントがタスク管理システムに直接アクセスできるとき、「何を構築すべきか」と「何が構築されるか」の間の摩擦はほぼゼロに近づく。
MCP:欠けていたリンク
Model Context Protocol(MCP)がこれを可能にしている。Claude と Claude Code が以下を行えるようになる:
- タスクの詳細と仕様を直接取得
- 手動コピーなしでプロジェクトコンテキストを理解
- 作業の進行に応じてタスクステータスを更新
- 開発セッション間で継続性を維持
結果として、コードを書くだけでなく、完全な開発ワークフローに参加する AI が実現する。

実践的なポイント
AI コーディングツールを導入するなら、実際に効果があることは以下だ:
やるべきこと
✅ プロンプトの前に仕様を確立する。 意図が明確であるほど、出力も良くなる。
✅ コードレビューに投資する。 AI 生成コードはより多くのレビューが必要であり、少なくて良いわけではない。ペースを維持するために AI 支援レビューツールを検討する。
✅ ワークフローに合ったツールを選ぶ。「最高の」ツールは、チームが実際に正しく使うものだ。
✅ AI をジュニア開発者として扱う。 速く、有能だが、明確な方向性と監督が必要。
✅ フィードバックループを構築する。 何が機能するかを追跡する。結果に基づいてプロンプトとプロセスを調整する。
避けるべきこと
❌ 理解できないコードを受け入れない。 説明できなければ、保守もできない。
❌ 「AI が書いたから」とテストを省略しない。 AI 生成コードは人間が書いたコードより脆弱性率が高い。
❌ 速度と生産性を混同しない。 速く出荷して何ヶ月も修正するのは効率的ではない。
❌ ツールにアーキテクチャを決めさせない。 あなたの技術的判断が AI を導くべきであり、その逆ではない。
まとめ
Vibe Coding はなくならない。AI 支援開発は標準的なプラクティスになりつつある——開発者の 76%が AI コーディングアシスタントを使用中または使用予定だ。
しかし、AI Slop を生み出すチームと品質の高いソフトウェアを出荷するチームの差は広がっている。
違いはツールではない。操作する人間だ。
明確な仕様。強固なレビュープロセス。曲げない品質基準。 これらの基本は、AI 時代にはより重要になる。
成功するチームは、最も多くのコードを生成するチームではない。そのコードが生成する価値があることを確保する規律を維持するチームだ。
Heimin は、これらの原則を使って構築したタスク管理ツールであり、それを構築するために使うツールでもある。Spec 駆動開発とクローズドループ実行の融合。シンプルさと品質を重視するチームに、Heimin を無料でお試しください。
参考文献
-
Collins 辞書 2025 年の言葉:「Vibe Coding」— The Conversation
-
Macquarie 辞書 2025 年の言葉:「AI Slop」— Phys.org
-
Veracode 調査:AI 生成コードの 45%にセキュリティ脆弱性 — Medium: The Rise of Vibe Coding
-
METR 調査:AI ツール使用で生産性 19%低下 — FinalRound AI
-
Y Combinator 2025 年冬バッチ:25%が 95%AI 生成コードベース — Medium: The Rise of Vibe Coding
-
Stack Overflow 2024 開発者調査:76%が AI コーディングアシスタント使用中または予定 — SoftwareSeni
-
Sean Grove(OpenAI)仕様が新しいプログラミングスキルについて — The New Stack
-
GitHub Spec Kit と Spec 駆動開発 — GitHub Blog
-
AWS Kiro と Spec モード — Kiro Blog
-
AI コーディングツール比較 — Appwrite Blog、HumAI Blog