バイブコーディングとエージェンティックコーディングの違いと未来のスキル

AIを使った開発が当たり前になり、「バイブコーディング」「エージェンティックコーディング」という言葉をよく耳にするようになりました。どちらも「AIにコードを書かせる」話に聞こえますが、実は比べている軸がまったく違う言葉です。この記事では両者の違いを整理したうえで、これからのエンジニアに求められるスキルについて考えます。

バイブコーディングとは

バイブコーディング（Vibe Coding）は、2025年初頭に Andrej Karpathy 氏が使い始めた言葉です。AIに自然言語で頼み、生成されたコードの中身はほとんど読まず、「動けばOK」という雰囲気（vibe）で開発を進めるスタイルを指します。

• コードをレビュー・理解しないのが本来の意味
• エラーが出たらエラーメッセージをそのままAIに貼って直してもらう
• プロトタイプ、個人用ツール、使い捨てのスクリプトには非常に強い
• 一方で、保守性・セキュリティ・パフォーマンスは誰も保証していない状態になりやすい

つまりバイブコーディングは、「人間がコードとどう関わるか（関わらないか）」を表す言葉です。

エージェンティックコーディングとは

エージェンティックコーディング（Agentic Coding）は、AIが自律的にタスクを遂行するループを回す開発スタイルです。Claude Code や Cursor のエージェントモードなどが代表例です。

• AIがリポジトリを読み、ファイルを編集し、コマンドを実行する
• テストを回し、失敗したら原因を調べて修正する、を繰り返す
• 人間は設計・指示・レビュー・承認を担う「監督役」になる
• テスト・CI・型チェック・Lintなどのガードレールとセットで運用されることが多い

こちらは「AIがどう動くか」を表す言葉です。

ふたつの関係を整理する

軸が違うので、両者は対立概念ではなく組み合わせられます。

	人がコードをレビューする	人がコードを読まない
AIが自律的に動く（エージェント）	エージェンティックコーディング（実務向き）	エージェント×バイブコーディング
チャットで都度やりとり	AI支援コーディング（従来型）	チャット型バイブコーディング

現代のエンジニアに求められる素養

AIがコードを書く速度は人間をはるかに上回るようになりました。では、エンジニアの価値はどこに移ったのでしょうか。ポイントは「書く力」から「決める力」「確かめる力」「任せる力」へのシフトです。

1. 要件と設計を言語化する力

エージェントは、指示が曖昧だと「それっぽいけど違うもの」を高速に作ります。何を作るのか、何を作らないのか、制約は何か、完了条件は何か。これらを文章で明確に渡せることが、アウトプットの質を最も大きく左右します。仕様書やチケットを書く力は、そのままプロンプトを書く力になりました。

2. コードを読んで判断する力

書く量が減る代わりに、読む量は確実に増えます。AIの出した差分を見て、意図通りか、副作用はないか、無駄に複雑になっていないかを素早く判断できること。言語やフレームワークの基礎理解は、むしろこれまで以上に重要です。基礎がないと「動いているように見える間違い」に気づけません。

3. 検証の仕組みを作る力

エージェンティックコーディングの品質は、ガードレールの質で決まります。

• テスト（ユニット・E2E）を用意し、AI自身に回させる
• 型（TypeScriptの strict モードなど）で間違いを機械的に弾く
• Lint・フォーマッタ・CIで一定の品質を自動担保する

「AIが正しく書くこと」を期待するのではなく、「間違えたら自動で気づける環境」を作るのがエンジニアの仕事になります。

4. セキュリティとデータの感覚

認証・認可、DBのアクセス制御（たとえば Supabase の RLS）、秘密情報の扱い、外部入力のバリデーションなどは、AIが「動くけど危ない」コードを書きやすい領域です。ここは人間が最終責任を持つ前提で、重点的にレビューする必要があります。

5. タスクを分解して委任する力

大きな仕事をそのまま投げると、エージェントは途中で迷子になります。適切な粒度に分解し、順番を決め、各ステップで確認する。これは人間のチームにタスクを振るマネジメントスキルとほぼ同じです。AIを「優秀だけど文脈を知らない新メンバー」と捉えると、渡すべき情報が見えてきます。

6. ドメインとユーザーを理解する力

コードを書くコストが下がるほど、「何を作るべきか」の価値が上がります。業務の流れ、ユーザーが本当に困っていること、ビジネス上の優先度。これらはAIが勝手には知り得ない情報で、エンジニアの差別化ポイントとして残り続けます。

7. 使い分けの判断力

バイブコーディングが悪いわけではありません。検証用のプロトタイプや社内向けの小さなツールなら、スピード重視で割り切るのは合理的です。大事なのは、「今回はどこまで品質責任を持つべきか」を案件ごとに判断できることです。

コードレビューもAIに任せる時代、人間は何を見るのか

最近は、書くだけでなくコードレビューもAIに任せるチームが増えてきました。そうなると「人間の役割は外部結合テスト以降の確認だけになるのでは？」という疑問が出てきます。

半分はその通りですが、「テスト工程の後ろのほうだけが人間の仕事」と考えるより、人間が見るレイヤーが一段上がると捉えたほうが実態に近いと考えています。

AIレビューが得意なこと

AIレビューが強いのは、差分の中で完結する問題です。

• バグになりそうなロジック、境界値の扱い
• 命名や可読性、コーディング規約違反
• 型の不整合や未処理のエラー
• よくある脆弱性パターン（SQLインジェクション、XSSなど）

こうした行単位のチェックは、人間より速く、網羅的に拾ってくれます。ここはもう積極的に任せてよい領域です。

AIレビューが苦手なこと

一方で苦手なのは、差分の外にある文脈です。

• 要件として正しいか：仕様の解釈ミスは、コードがきれいでもそのまま通ってしまう
• 他システムや運用への影響：データ移行、既存ユーザーへの影響、外部連携先の挙動
• 設計判断の妥当性：今この抽象化を入れるべきか、技術的負債をどこまで許容するか
• 何をテストすべきか：AIはテストを書けても、受け入れ条件を決めるのは人

人間の役割は「両端」に寄っていく

つまり人間の役割は、時系列でいう「後工程」に押し出されるというより、開発の両端に寄っていきます。

• 最初：何を作り、何をもって完成とするかを決める（要件定義、設計レビュー、受け入れ条件の定義）
• 最後：本当に意図通りか、リリースしてよいかを判断し、責任を持つ（外部結合・受け入れの確認、リリース判断）

外部結合テストや受け入れ確認は「最後」の代表例ですが、設計レビューや受け入れ条件の定義といった「最初」側も同じくらい重要です。最初がブレていると、AIがどれだけ正確にレビューしても「正しく間違ったもの」ができあがります。

「人が必ず見る場所」をルール化する

AIレビューを導入するなら、AIが見落とす前提で、どこを人間が必ず確認するかを決めておくのが実務的です。

• 認証・認可、権限まわり
• 課金・決済に関わる処理
• データの削除・マイグレーション
• 外部APIとの契約（レスポンス形式、レート制限、エラー時の挙動）

まとめ

• バイブコーディングは「人がコードを読まずに任せる」スタイル。速いが責任の所在が曖昧になりやすい
• エージェンティックコーディングは「AIが自律的に作業ループを回す」スタイル。人は監督・レビュー役
• 両者は軸が違い、組み合わせ可能。本質は誰が責任を持ち、どこで検証するか
• これからのエンジニアには、言語化・読解・検証設計・セキュリティ・タスク分解・ドメイン理解・使い分けの判断力が求められる
• コードレビューもAIに任せられる時代、人間の役割は「何を作るか決める最初」と「出してよいか判断する最後」の両端に寄っていく

AIによって「コードを書く」作業は誰にでも開かれました。だからこそ、何を作り、どう確かめ、どこに責任を持つかを決められる人の価値は、これからさらに高まっていくはずです。