Vibe Codingで感じたこと〜AIに全部任せるコーディングの現実〜

Vibe Codingって何？

最近、「Vibe Coding（バイブコーディング）」という言葉をよく耳にするようになりました。これは、AIに自然言語（普通の言葉）で指示を出してコードを書かせる開発スタイルのことです。

OpenAIの共同創業者であるAndrej Karpathy氏が2025年初めに提唱した概念で、英語では「vibing with AI」とも表現されます。要するに、「こんな機能が欲しい」「ここをこう動かしたい」と話しかけるだけでAIがコードを生成・修正してくれる、という開発体験のことです。

私はClaude Codeを普段から使っているので、ある意味ずっとVibe Codingに近いことをやっていたわけですが、改めてこのスタイルを意識して試してみました。今回はその体験を正直にまとめます。

実際にやってみた：指示だけでどこまでできる？

試したのはUnityのC#スクリプトとBlenderのPythonスクリプト。どちらも「こういう動きをするものを作って」と自然言語で指示を出し、コードをほぼコピペするだけで進めてみました。

たとえばUnityでは、こんな指示を出しました。

「プレイヤーがジャンプするとカメラが少し揺れるシェイク効果を追加して。
ジャンプの強さに比例して揺れ幅を変えてほしい。」

するとClaude Codeはほぼ一発で動くC#スクリプトを生成してくれました。コンポーネントのアタッチ先や設定値の説明まで付けてくれて、Unityに貼り付けたらすぐ動きました。

Blenderでも同様に、

「選択中のメッシュの全頂点にランダムなノイズを加えて
少し有機的な形にするPythonスクリプトを書いて。」

と指示したら、bpy を使った完成度の高いスクリプトが出てきました。これは正直かなり感動しました😊

感じたメリット：圧倒的な速度と学習効果

Vibe Codingを試して感じたメリットをまとめます。

特に「新しいAPIやライブラリを初めて使うとき」のコスト削減は圧倒的です。公式ドキュメントを読みながら試行錯誤する時間が大幅に短縮されました。

感じた限界：AIが苦手なこと

一方で、Vibe Codingには明確な限界もありました。正直に書きます。

コンテキストが広がるほど精度が落ちる

単機能のスクリプトは得意ですが、プロジェクト全体の構造を理解した上での変更が必要なケースは苦手です。既存コードとの整合性が取れなかったり、変数名がズレたりすることがありました。

「なぜそう動くか」が分からないと詰む

生成されたコードが動かないとき、自分でデバッグできる知識がないと手詰まりになります。「エラーが出た」と伝えてもAIが同じミスを繰り返すケースもあり、最終的にはエンジニアとしての基礎知識が問われると実感しました。

軸やスケールの違いで意図がズレる

以前にも書きましたが、BlenderとUnityの座標系の違い（Y軸・Z軸の扱いの差）のように、ツール固有の「お作法」をAIが知らない・または混同するケースがあります。動くコードが出てきても、動作が想定と違う、ということが起きます。

# BlenderはZ軸が上、UnityはY軸が上
# この違いを指示に含めないとAIが混乱することがある

# Blenderでのオブジェクト移動（Z軸が上方向）
bpy.context.object.location.z += 1.0

# Unityでの相当する処理（Y軸が上方向）
transform.position += Vector3.up * 1.0f;

完全に任せられる部分と、人間が判断すべき部分

実際に使ってみて、「ここはAIに任せていい」「ここは自分で考えないとダメ」という境界線が見えてきました。

AIは「指示された通りに動くコードを書く」のは得意ですが、「何を作るべきか」「これで本当に正しいか」という判断はまだ人間の領域だと感じています。

エンジニアの仕事はどう変わっていくか

Vibe Codingを通じて感じたのは、「コードを書く量」は確実に減っていくけど、「エンジニアが不要になる」わけではない、ということです。

むしろ仕事の重心が変わっていく感覚があります。今まで「実装力」が求められていたとすれば、これからは「何を作るかを決める力」「AIの出力を正しく評価する力」「全体を見通す設計力」がより重要になっていくと思います。

組み込み系エンジニアとして長く仕事をしてきた立場から言うと、「ハードウェアの制約を理解してコードを書く」という部分はまだしばらくAIには代替されないと感じています。でもその周辺の「ドライバを書く」「プロトコルを実装する」といった部分は、Vibe Codingでかなりカバーできるようになってきました。

AIをうまく使いこなせるエンジニアと、そうでないエンジニアの差は、これからどんどん開いていくかもしれません。だからこそ、使い方を理解しながら自分のスキルとして取り込んでいくことが大事だと、今回の体験で改めて思いました😊

それでは、今回はここまで。ありがとうございました😊

【その後】「動いた」と「意図した経路で動いた」は別だった

本文で「AIが苦手なこと」を挙げましたが、その後いちばん怖いと感じたのは、間違いが「エラー」の形では出てこないケースでした。

ある回で、新しい描画の仕組みが実際に速いのかを確かめようとしました。ベンチマークソフトを動かしたところちゃんと起動して、数字も出ました。そのまま結果を記事にしかけたのですが、念のためログを確認したところ——

• そのソフトは32ビット版だった
• 32ビットと64ビットでは、内部で通る経路がまったく別だった
• つまり確かめたかった仕組みを、1ミリも通っていなかった

画面には数字が出ています。エラーも出ません。ログを見に行かなければ、最後まで気づけませんでした。

【その後】テストが全部通っても、実機では落ちた

もう1つ、はっきりと数字で出た例があります。ゲームエンジンからAIを呼ぶ処理を書き、単体テストを40件用意して、全部通しました。それでも実機では3回目のリクエストから必ず失敗しました。

原因は、通信を終えたあとの後片付けが抜けていたことです。使い終わった接続を閉じずに次を開き続けると、使える本数の上限に達して、それ以降はすべて失敗します。

この不具合には、AIに任せるかどうかに関わらず引っかかりやすい性質があります。

AIが書いたコードは「読んで正しそうに見える」度合いが高いぶん、目で追うだけのレビューをすり抜けます。動くかどうかではなく、続けて動かしたときに壊れないかを見るほうが実際に効きました。

【その後】任せられる／任せられないの線引きを引き直す

本文の表を、その後の経験で書き直すとこうなります。「難しいか簡単か」ではなく、間違えたときに、間違いが表に出るかどうかで分かれていました。

もう1つ、実際にやってみて効いた進め方があります。危ない部分を先に、小さく試すことです。うまくいくか分からない箇所を後回しにすると、そこが崩れたときに全部やり直しになります。先に通しておけば、残りは安心して任せられます。

本文では「速度」と「学習効果」をメリットに挙げました。いま振り返ると、学習効果のほうが大きかったと感じています。ただしそれは、出てきたコードを読んで、動かして、想定と違ったところを追いかけたぶんだけでした。任せきりにした部分は、あとから自分の中に何も残っていません。