バイブコーディングとエージェンティック・エンジニアリングの違い｜同じAI活用でも公開後の扱いが変わる理由
この記事の結論
どちらが優れているかではなく、作ったあとにどうするかで選び方が変わります。
試して形にすること自体が目的なら、バイブコーディングは十分に有力です。一方、公開して人が使い続けるサイトなら、生成されたコードを人間が検証する進め方——エージェンティック・エンジニアリングの考え方が必要になります。
判断の分かれ目は、AIを使うかどうかではありません。公開後に不具合が出たとき、誰が原因を追い、直せる状態にあるかです。
それぞれの定義
バイブコーディング
バイブコーディングは、AIに自然言語で指示し、生成されたコードの中身を細かく確認せずに、やり取りを重ねながら開発を進めるスタイルです。2025年2月にAndrej Karpathy氏が提唱しました。
エージェンティック・エンジニアリング
エージェンティック・エンジニアリングは、AIエージェントにコードの生成やテスト、修正などを任せながら、人間が仕様、設計、権限、テスト方法を定め、過程と成果物を監督・検証する開発の進め方です。同じくKarpathy氏が、2026年2月の投稿でバイブコーディングと区別する呼び方として挙げました。
Karpathy氏は2026年4月の対談をまとめた記事で、バイブコーディングは「床」を上げるもの、エージェンティック・エンジニアリングは「天井」を上げるものだと整理しています。前者は誰でも作れるようにし、後者は誤りうるエージェントを統率しながら正しさを保つ、という違いです。
「AIで作れば安く早い」とは限りません
発注や内製の検討でよく聞くのが、AIを使えば費用も期間も大きく縮むのではないか、という期待です。
形になるまでの速さについては、そのとおりの面があります。ただし、Webサイトの費用と期間は、コードを書く時間だけで決まるわけではありません。何を載せるかを決める、原稿と写真を用意する、デザインを判断する、公開後に直す。これらは、AIを使っても大きくは減りにくい部分です。
さらに、確認を省いた分の作業は、あとから戻ってくることがあります。IBMの解説でも、十分な専門知識や検証なしに生成されたコードは、既存のコードを壊したり、理解、デバッグ、修正にかかる負担を増やしたりして、技術的負債につながる可能性があると指摘されています。
作る側の受け止め方も、参考になります。Stack Overflowの2025年開発者調査では、回答した開発者の84%が、AIツールを開発で利用している、または今後利用する予定だと答えています。一方、AIの出力の正確さについては、「信頼している」が33%だったのに対し、「信頼していない」は46%でした。AIの利用が広がっていることと、出力をそのまま信用できることは、別の話だと分かります。
費用を見るときは、作るまでの金額と、その後にかかる手間を分けて考えると判断しやすくなります。作る段階が速く安く済んでも、公開後に直せる人がいなければ、そこで別の費用が発生します。逆に、最初に設計と確認へ時間をかけたサイトは、更新のたびの確認が軽くなる傾向があります。
比較表で整理すると
両者の違いを、発注する側の視点で並べると次のようになります。
| 観点 | バイブコーディング | エージェンティック・エンジニアリング |
|---|---|---|
| コードの確認 | 細部を確認せず進める | 人間が成果物を検証する |
| 作り始めるための知識 | 専門知識が少なくても始めやすい | 設計と検証の専門性が必要 |
| 形になるまでの速さ | 速い | 仕様策定や確認の工程が入る |
| 向いているもの | 試作・個人用ツール・影響の小さい短期利用 | 公開後も運用するサイトやシステム |
| 不具合が出たとき | 原因を追いにくくなりやすい | 検証した人が原因を追いやすい |
| 引き継ぎ | 設計意図が残らないことがある | 仕様や記録を残せば引き継ぎやすい |
| 品質への責任 | 作成者・運営者自身が判断する | 専門知識のある人が品質基準を判断する |
なお、両者は必ずしも完全な二者択一ではありません。最初の試作はバイブコーディングに近い形で素早く作り、公開する段階でコードや設計を検証し直す進め方もあります。重要なのは、作り始めた方法ではなく、公開時点で必要な確認が終わっているかです。
バイブコーディングで十分なケース
先に、制作会社に頼まなくてよい場合から挙げます。次のようなものは、バイブコーディングの速さを生かしやすいと考えられます。ただし、社外へ公開する場合は、用途に応じた動作確認が必要です。
- 社内だけで使うツールや、業務の下書きに使うもの
- 期間限定で使う、フォームや決済を含まない簡易ページ
- URLを限定して共有する検証用ページ
- 企画を通すための試作や、見た目の検証
- 問題が起きても業務や顧客に大きな影響がなく、廃棄を前提にしたもの
この範囲であれば、細部まで作り込むことよりも、素早く形にして試せる利点のほうが大きい場面があります。
公開して運用するサイトで注意したい点
一方、会社のサイトとして公開し、問い合わせを受け、長く使い続ける場合は、見方が変わります。
- フォームと個人情報：入力内容がどこへ送られ、どう保存されるかを把握していないと、確認のしようがありません
- 不具合の切り分け：表示が崩れたとき、どこを直せばよいかを判断できる人が必要になります
- 引き継ぎ：仕様や設計意図が残っておらず、作った本人もコードの全体像を把握していない場合、社内でも他社でも手を入れにくくなります
- 公開後の更新：小さな修正が別の場所を壊していないか、確認する工程が要ります
いずれも、AIを使ったから起きる問題ではありません。中身を確認する人がいないまま公開したときに起きる問題です。
AIで作ったサイトを引き継ぐときに確認すること
すでにAIで作ったサイトがあり、これから人に見てもらう、あるいは社内で運用を続ける場合に、先に確認しておくと判断しやすい項目を挙げます。
- フォームの送信先：問い合わせが実際に届くか、どのアドレスに届くかを、テスト送信で確かめる
- 個人情報の保存場所：入力内容が外部サービスに保存されていないか、保存されている場合はどこかを確認する
- ソースコードの所在：コードやデータがどこにあり、誰がアクセスできるかを把握する
- バックアップと復元方法：元に戻せる状態があるか、いつ時点まで戻せるか、誰がどの手順で復元できるかを確認する
- 更新の手順：文言や画像を差し替えるとき、どこを触ればよいかを書き出しておく
- 外部サービスと契約者：サーバー、ドメイン、フォーム、データベース、アクセス解析など、利用しているサービスと契約名義を確認する
この6項目が分かっていれば、あとから相談するときにも話が早くなります。逆に、ここが不明なまま運用が続いているサイトは、不具合が起きたときの対応に時間がかかりやすいと考えられます。
確認の工程が必要かどうか——判断のための5つの質問
1. そのサイトは、いつまで使いますか？
数週間で役目を終えるなら、素早く作ることを優先しても構いません。数年使うなら、あとから直せる状態かどうかが効いてきます。サイトは公開したときが完成ではなく、情報の追加や修正が続くためです。
2. 個人情報を扱いますか？
問い合わせフォーム、資料請求、採用応募など、個人情報を受け取る仕組みがあるなら、動作と送信先の確認は省けません。届かない、あるいは意図しない場所に保存されている、という状態は、外から見て気づきにくい種類の不具合です。
3. 不具合が起きたとき、誰が原因を追いますか？
社内に確認できる人がいない場合は、公開前に専門知識のある人へ、コードの構造、フォームの動作、外部サービスとの接続、更新方法などを確認してもらうと、公開後の対応がしやすくなります。原因の切り分けができないと、直せる不具合なのか、作り直しが必要なのかの判断もつきません。
4. 公開後、どのくらいの頻度で更新しますか？
更新のたびに壊れていないか確認する必要があるため、頻度が高いほど、構造を把握している人の存在が重要になります。更新が月に何度もあるなら、確認の手順を決めておくほうが結果的に速くなります。
5. そのサイトは、会社の信用に関わりますか？
表示崩れやフォームの不達が、そのまま会社の印象につながる場合は、確認の工程を省かない前提で考えることをおすすめします。特にBtoBでは、サイトを見た人が発注先として比較している場面が多く、細部の不具合が判断材料になることがあります。
5つの質問に対して、「長く使う」「個人情報を扱う」「社内に原因を追える人がいない」「更新頻度が高い」「会社の信用に関わる」という回答が多いほど、人間が検証する進め方が必要になります。
ENVY DESIGNの立場
私たち自身も、バイブコーディングを試しました。確認用のものや社内で使うものを作る分には、素早く形になって便利だと感じています。
一方で、細部の再現には時間がかかりました。思ったとおりの見た目や動きに近づけるまで、指示を出し直す回数が増えていき、結局そこに時間を使うことになります。公開するサイトの品質まで仕上げるには、どこをどう直せばよいかを判断できる目が必要だ、というのが試してみた実感です。あくまで一例で、使うツールや作るものによって変わる部分もあると思います。
そのうえで、私たちは、新規制作とリニューアルにおいて、生成されたコードの中身を確認せずに納品することはありません。公開後も私たちが保守するサイトである以上、中身を把握していない状態では、不具合が起きたときに責任を持てないためです。
一方で、AIを道具として使うこと自体を避けているわけではありません。重要なのは、AIを使ったかどうかではなく、誰が成果物を検証し、公開後の品質に責任を持つのかだと考えています。
また、自分で作ること自体を止めるつもりもありません。作れる範囲が広がったのは良い変化です。そのうえで、AIで作られたサイトについても、現在の状態を確認したうえで、不具合の修正、改修、デザインの見直し、コーディングなどに対応しています。今後は、AIで作られたサイトを、制作会社がAIも活用しながら改善するサービスの提供も予定しています。
まとめ
バイブコーディングは、作り始めるハードルを下げます。エージェンティック・エンジニアリングは、必要な品質を保ちながらAIエージェントを開発へ組み込むための進め方です。
試作や、問題が起きた場合の影響が小さい社内ツールなら、バイブコーディングの速さを生かせます。会社のサイトとして公開し、問い合わせを受け、長く運用するなら、誰かが中身を確認し続ける体制が要ります。その役割を社内で持つのか、制作会社に預けるのかを決めるところが、実際の判断になります。
よくある質問
バイブコーディングで作ったサイトを、そのまま公開しても大丈夫ですか？
作るもの次第です。社内向けの試作や、フォーム・決済を含まず、問題が起きた場合の影響が小さい期間限定ページであれば、現実的な選択肢になります。一方、問い合わせフォームや会員機能など、個人情報を扱う仕組みが入る場合は、公開前に専門知識のある人による確認をおすすめします。
エージェンティック・エンジニアリングなら、制作費は安くなりますか？
必ずしも安くなるとは限りません。作業の一部が速くなる可能性はありますが、確認と検証の工程は残ります。制作費は、AIを使うかどうかよりも、ページ数、機能の複雑さ、設計にかける時間で決まる部分が大きいと考えられます。
自分でAIを使って作ったサイトを、あとから制作会社に見てもらえますか？
対応している会社であれば可能です。ENVY DESIGNでも、AIで作られたサイトについて、現在の状態を確認したうえで、不具合の修正、改修、デザインの見直し、コーディングなどを承っています。
どちらを選んでも、AIが書いたコードであることに変わりはないのでは？
コードを誰が書いたかは同じでも、誰が確認したかが変わります。エージェンティック・エンジニアリングでは、生成されたコードを人間が検証し、必要な品質基準を満たしているか判断することが前提になります。この違いは、不具合の予防や、問題が起きたときの原因究明のしやすさに表れます。
制作会社に頼まず、自分で作り続ける選択はありですか？
あります。予算や体制によっては、自分で作って運用するほうが現実的な場合もあります。その場合でも、公開前に動作を確認し、バックアップと復元方法、更新手順、利用している外部サービスの契約名義を把握しておくと安心です。
出典
- Andrej Karpathy氏のX投稿（2026年2月）
- Andrej Karpathy「Sequoia Ascent 2026 summary」
- IBM「What is agentic engineering?」（2026年2月27日）
- Stack Overflow「2025 Developer Survey」
関連記事
お問い合わせ
AIで作ったサイトをこのまま使い続けてよいか、直すべきか迷っている段階でも構いません。現在の状態を確認したうえで、直せる部分と作り直したほうが早い部分を切り分けるところから始めます。