Shuhei
バイブコーディングとエージェンティックコーディングの違いと未来のスキル
2026年10月06日
見出しはありません
要約を生成中...
AIを使った開発が当たり前になり、「バイブコーディング」「エージェンティックコーディング」という言葉をよく耳にするようになりました。どちらも「AIにコードを書かせる」話に聞こえますが、実は比べている軸がまったく違う言葉です。この記事では両者の違いを整理したうえで、これからのエンジニアに求められるスキルについて考えます。
バイブコーディング（Vibe Coding）は、2025年初頭に Andrej Karpathy 氏が使い始めた言葉です。AIに自然言語で頼み、生成されたコードの中身はほとんど読まず、「動けばOK」という雰囲気（vibe）で開発を進めるスタイルを指します。
つまりバイブコーディングは、「人間がコードとどう関わるか（関わらないか）」を表す言葉です。
エージェンティックコーディング（Agentic Coding）は、AIが自律的にタスクを遂行するループを回す開発スタイルです。Claude Code や Cursor のエージェントモードなどが代表例です。
こちらは「AIがどう動くか」を表す言葉です。
軸が違うので、両者は対立概念ではなく組み合わせられます。
| 人がコードをレビューする | 人がコードを読まない | |
|---|---|---|
| AIが自律的に動く（エージェント） | エージェンティックコーディング（実務向き） | エージェント×バイブコーディング |
| チャットで都度やりとり | AI支援コーディング（従来型） | チャット型バイブコーディング |
界隈で議論になりやすいのは、「バイブコーディング」という言葉が広まりすぎて、きちんとレビューしながらAIを使っているエンジニアまで同じ括りにされてしまう、という呼び名の問題です。本質は呼び方ではなく、生成物に誰が責任を持ち、どこで検証しているかにあります。
AIがコードを書く速度は人間をはるかに上回るようになりました。では、エンジニアの価値はどこに移ったのでしょうか。ポイントは「書く力」から「決める力」「確かめる力」「任せる力」へのシフトです。
エージェントは、指示が曖昧だと「それっぽいけど違うもの」を高速に作ります。何を作るのか、何を作らないのか、制約は何か、完了条件は何か。これらを文章で明確に渡せることが、アウトプットの質を最も大きく左右します。仕様書やチケットを書く力は、そのままプロンプトを書く力になりました。
書く量が減る代わりに、読む量は確実に増えます。AIの出した差分を見て、意図通りか、副作用はないか、無駄に複雑になっていないかを素早く判断できること。言語やフレームワークの基礎理解は、むしろこれまで以上に重要です。基礎がないと「動いているように見える間違い」に気づけません。
エージェンティックコーディングの品質は、ガードレールの質で決まります。
「AIが正しく書くこと」を期待するのではなく、「間違えたら自動で気づける環境」を作るのがエンジニアの仕事になります。
認証・認可、DBのアクセス制御（たとえば Supabase の RLS）、秘密情報の扱い、外部入力のバリデーションなどは、AIが「動くけど危ない」コードを書きやすい領域です。ここは人間が最終責任を持つ前提で、重点的にレビューする必要があります。
大きな仕事をそのまま投げると、エージェントは途中で迷子になります。適切な粒度に分解し、順番を決め、各ステップで確認する。これは人間のチームにタスクを振るマネジメントスキルとほぼ同じです。AIを「優秀だけど文脈を知らない新メンバー」と捉えると、渡すべき情報が見えてきます。
コードを書くコストが下がるほど、「何を作るべきか」の価値が上がります。業務の流れ、ユーザーが本当に困っていること、ビジネス上の優先度。これらはAIが勝手には知り得ない情報で、エンジニアの差別化ポイントとして残り続けます。
バイブコーディングが悪いわけではありません。検証用のプロトタイプや社内向けの小さなツールなら、スピード重視で割り切るのは合理的です。大事なのは、「今回はどこまで品質責任を持つべきか」を案件ごとに判断できることです。
バイブコーディングで作ったものを、そのまま本番運用や顧客納品に流用するのは要注意です。プロトタイプから本番に移すタイミングで、レビュー・テスト・セキュリティチェックの工程を必ず挟みましょう。
最近は、書くだけでなくコードレビューもAIに任せるチームが増えてきました。そうなると「人間の役割は外部結合テスト以降の確認だけになるのでは？」という疑問が出てきます。
半分はその通りですが、「テスト工程の後ろのほうだけが人間の仕事」と考えるより、人間が見るレイヤーが一段上がると捉えたほうが実態に近いと考えています。
AIレビューが強いのは、差分の中で完結する問題です。
こうした行単位のチェックは、人間より速く、網羅的に拾ってくれます。ここはもう積極的に任せてよい領域です。
一方で苦手なのは、差分の外にある文脈です。
つまり人間の役割は、時系列でいう「後工程」に押し出されるというより、開発の両端に寄っていきます。
外部結合テストや受け入れ確認は「最後」の代表例ですが、設計レビューや受け入れ条件の定義といった「最初」側も同じくらい重要です。最初がブレていると、AIがどれだけ正確にレビューしても「正しく間違ったもの」ができあがります。
AIレビューを導入するなら、AIが見落とす前提で、どこを人間が必ず確認するかを決めておくのが実務的です。
「AIのレビューでOKが出ても、上記に触れる変更は人間の承認を必須にする」というルールをCIやPRテンプレートに組み込んでおくと、事故をかなり減らせます。
AIによって「コードを書く」作業は誰にでも開かれました。だからこそ、何を作り、どう確かめ、どこに責任を持つかを決められる人の価値は、これからさらに高まっていくはずです。
要約
コメント
まだコメントはありません。
