執筆者：DigKnow株式会社　CTO　桑原　脩

　

Claude Codeにタスクを投げるとき、自分が「コードを書いている」という感覚が薄れてきました。「この機能を追加して」と伝えるだけで、複数のファイルにまたがる変更が返ってきます。便利だと思います。でも同時に、「自分はいま何をしているのだろう」という問いが、頭の隅にひっかかるようになってきました。そのモヤを言語化してくれた言葉が「Vibe Coding」です。

　

Vibe Codingという言葉が生まれた背景

2025年2月、元TeslaのAI責任者でありOpenAIの創業メンバーでもあるAndrej Karpathyが、ひとつの投稿をしました。そこに書かれていたのは「Vibe Coding」という造語でした。
彼が表現したのは、こういうことです。コードの細部を自分で書くのではなく、作りたいもののイメージ——”バイブ（感覚・空気感）”——をAIに自然言語で伝え、生成されたコードをほぼそのまま使う。エラーが出たらそのメッセージごとAIに貼り付け、「これを直して」と頼む。どんなコードが生成されているかは、あまり気にしません。
「そこまで極端な話か」と思う方もいるかもしれません。でも実際、Claude CodeやGitHub Copilotを使っていると、それに近い体験は日常的に起きています。Vibe Codingは、Karpathyの個人的な遊び方の話ではなく、AIコーディングツールが成熟してきた今、開発スタイルそのものが分岐点を迎えていることを示す言葉です。

　

“感覚で書く”とはどういうことか——Claude Codeを例に

Vibe Codingの本質は、抽象度の高い指示からコードを得ることにあります。
従来のプログラミングは、実装の細部まで自分で設計・記述する行為でした。「このAPIから取得したデータをこういうデータ構造に変換して、ここに表示する」——そういった具体的な操作の連鎖を、人間がひとつずつコントロールしていました。
Claude Codeでは、その粒度が大きく上がります。ターミナルから「ユーザーが検索したキーワードで商品一覧を絞り込める機能を追加して」と伝えるだけで、コードベース全体を読んだうえで複数ファイルにまたがる変更を提案してきます。開発者は、その出力が”だいたい思ったとおりか”を感覚的に判断し、違和感があれば言葉で補正します。
コードを書くというより、コードを”誘導する”という感覚に近いです。
Claude Codeがとりわけ興味深いのは、エディタではなくターミナルで動くという点です。自分のコードベースを丸ごと理解した状態で、「次にやりたいこと」を自然言語で話しかける。その会話のなかで、ファイルが生まれ、関数が変わり、テストが走る。このフローが一番Vibe Codingの本質に近いと感じています。

　

AIコーディングツールの恩恵を受けているのは誰か

Vibe Codingが可能性を広げている層は、大きく二つあります。
ひとつは、ノンエンジニア・非技術職の方々です。「プログラミングができなくても、アイデアをプロトタイプに変えられる」という体験が、参入ハードルを劇的に下げました。サービスの企画担当者が自分でダッシュボードを作り、デザイナーがアニメーションのロジックを書く——そういったことが、ある程度現実になっています。
もうひとつは、熟練エンジニアのスピード最大化です。自分でゼロから書くよりも、AIが出した叩き台を修正・選別するほうが速い。Vibe Codingの感覚でまず動くものを作り、そこから精緻化していく。設計力があるエンジニアほど、AIの提案の”良し悪し”を素早く判断できるため、この恩恵を大きく受けます。
一方で、経験が浅いエンジニアがVibe Codingに完全に依存した場合の問題は、前回の記事（[AIがコードを書く時代が来た](記事#1へのリンク)）でも触れたとおりです。動くコードが速く手に入る一方、そのコードが「なぜそう動くのか」を理解しないまま積み上がっていきます。

　

Vibe Codingが変えるのは「何を書くか」ではなく「何を考えるか」

Vibe Codingが広がるほど、エンジニアに求められる能力の重心が変わります。「どう書くか（実装）」よりも「何を作るか（設計・意図）」の言語化能力が、より重要になります。
AIに正確に意図を伝えられる人は、速く良いものを作れます。逆に、自分が何を作りたいのかを整理できていないまま「なんかいい感じにして」とAIに丸投げすると、それなりの出力は来ますが、意図と微妙にずれたコードが積み上がります。
自分がClaude Codeを使っていて気になるのもここです。タスクを自然言語で渡して、変更が返ってきて、動く。そのプロセスは確かに速いです。でも後から「なぜこの設計になったのか」を振り返ろうとすると、会話のログはあっても、判断の文脈はどこにも残っていません。コードは増えた。意図は揮発した——という状態が、静かに積み重なっています。
これは単に自分の話ではなく、今の開発現場でじわじわと起きていることの正体だと思っています。

　

なぜ今この言葉が広がっているのか

Vibe Codingという概念が2025年にこれだけ広がった背景には、ツールの成熟だけでなく、エンジニアの心理的な変化もあります。
「ちゃんとコードを理解して書かないといけない」という規範意識が、じわじわと薄れてきている——そんな感覚を持つエンジニアは少なくないはずです。AIが補完してくれることが当たり前になると、”全部理解している状態”でコードを書く機会が、構造的に減っていきます。
Vibe Codingはその延長線上にあります。悪いことだとは思いません。開発の抽象度が上がるのは技術の進化として自然ですし、そのおかげで作れるものの幅は確実に広がりました。
ただ、この流れが加速するほど、「誰がどこまでコードを理解しているか」「その設計の意図はどこに記録されているか」という問いは、開発チームにとってより切実なテーマになってきます。

　

まとめ

Vibe Codingとは、AIと対話しながら感覚的にコードを生成するプログラミングスタイルです。Andrej Karpathyが言語化したこの概念は、2025年の開発現場が迎えている変化を端的に示しています。実装の速度は上がり、ノンエンジニアにも開発の入り口が開かれました。一方で「コードは速く増えるが、意図はどこにも残らない」という問題の輪郭が、この言葉によってより鮮明になってきました。スピードを手に入れた現場が次に問われるのは、「誰がそのコードの意味を理解し続けるか」です。

Claude Codeやその他のAIツールで書いたコードの「設計の意図」は、チームのどこに残っていますか？

次回は、AIコーディングが日常になった現場で「とりあえず動いた」の次に何が起きているかを掘り下げます。スピードを手に入れた後に待ち受けるもの——その正体を見ていきます。

• « AIがコードを書く時代が来た——開発現場のリアル
• 「とりあえず動いた」が積み重なると何になるか——AIコーディング時代の技術的負債 »