バイブコーディングの光と影 ― 非エンジニアがアプリを作る時代に、開発者は何をすべきか ―

AIに自然言語で意図を伝え、コードや画面、テストのたたき台まで生成する「バイブコーディング」が広がり始めています。これにより、これまでエンジニア中心だった開発は、非エンジニアや新人エンジニアにも開かれつつあります。現場の課題をすばやく形にできる一方で、品質やセキュリティ、保守性が自動で担保されるわけではありません。本記事では、その光と影を整理し、アプリを作れる人が増える時代に、開発者が果たすべき役割を考えます。

バイブコーディングとは、自然言語で意図を伝え、AIと対話しながら実装を進める開発スタイルです。従来のように、細かい設計を先に固めてから実装するのではなく、まず言葉で方向性を伝え、AIの出力を見ながら形にしていくのが特徴です。

この呼び方は新しいものですが、考え方自体は急速に広がっています。ACM（計算機協会）も、バイブコーディングを「人が作りたいものを自然言語で伝え、AIコーディングアシスタントがコードを書き、デバッグする」開発スタイルとして説明しています（出典：ACM「TechBrief: Vibe Coding」）。

このスタイルの新しさは、実装の初速が非常に速いことにあります。画面のたたき台やCSV整形のような小さな自動化であれば、かなり短時間で形にでき、非エンジニアでも触りやすいのが魅力です。ただし、これは本格開発の代替ではありません。むしろ、開発の入口を広げる手段として捉えるのが適切です。

バイブコーディングの大きな価値は、まず動くものをすぐに作れることです。PoCや試作では、文章だけで要件を詰めるより、実際に動くものを見ながら認識を合わせた方が早いことが多いです。関係者の頭の中にあるイメージを、コードという形で素早く可視化できるのは大きな強みです。たとえば、問い合わせ一覧をCSVから整形する社内ツール、申請フォームのたたき台、日報や議事録の要約ツール、小さな管理画面の試作などは、最初から完璧に作るより、まず動くものを出して改善する方が向いています。

また、課題を最もよく知る現場の担当者が自分で試作できるようになると、開発依頼の往復が減り、小さな改善が積み上がりやすくなります。新人エンジニアにとっても、小さな機能から作って成功体験を積みやすいことは、学習の初期段階で大きな意味があります。

非エンジニアがアプリを作る時代という話は、新人エンジニアがAIを使って作り始める状況にも重なります。どちらにも共通しているのは、入口が低くなることに価値があるという点です。ACMも、バイブコーディングが開発を速め、ソフトウェア制作をより多くの人がアクセスできるものにする一方で、相応のリスクも伴うと整理しています（出典：ACM「TechBrief: Vibe Coding」）。

一方で、この「入口の低さ」は、理解を飛ばしやすいという裏返しでもあります。特に新人エンジニアの場合、AIが出したコードをそのまま使うことで、なぜその実装なのか、なぜその設計なのかを考えないまま進んでしまう危険があります。非エンジニアでも同様に、作れたことに満足してしまい、保守や運用の視点が抜け落ちることがあります。だからこそ開発者に求められるのは、単に「作れるようにする」ことではなく、なぜその実装なのかを理解できるように支えること、そしてAIの出力をそのまま採用せず、説明可能な形に整えることです。

一方で、バイブコーディングには明確なリスクもあります。最も分かりやすいのは品質です。AIが生成したコードは一見動いても、エラーハンドリングや境界条件、テストが不十分なことがあります。つまり、「動く」ことと「壊れにくい」ことは別です。実際にACMも、バイブコーディングが、システムを安全・信頼性高く・保守可能にするための基本的なエンジニアリング実践を飛ばしやすいと警告しています（出典：ACM「TechBrief: Vibe Coding」）。

セキュリティの観点でも注意が必要です。認証・認可の設計が甘くなったり、入力検証が弱かったり、秘密情報の扱いが不適切になったりすることがあります。OWASPは、AIエージェントが推論・記憶・ツール・権限・人間の監督といった要素を含み、従来より広い攻撃面を持つと整理し、AI支援・エージェント型のコーディングには専用のセキュリティ対策が必要だとしています。（出典：OWASP「AI Agent Security Cheat Sheet」）

保守性も大きな課題です。生成されたコードは、命名や構造、設計方針が一貫せず、なぜその実装になったのかという意図も残りにくいため、後から誰かが直そうとしたときに苦労しやすいです。特に重要なのは、AIだけが理解できる実装になっていないかという点です。人間が見ても意図を追えず、AIとのやり取りを再現しないと修正できない状態は、従来の属人化とは別の意味で危険です。説明できない実装は、保守できない実装でもあります。

図1：バイブコーディングの「光」と「影」

バイブコーディングは入口として有効ですが、その先には別の段階があります。それが、コンテキストエンジニアリングとハーネスエンジニアリングです。コンテキストエンジニアリングとは、目的、背景、利用者、制約、禁止事項、扱うデータなど、AIに渡す前提情報をどう設計するかという考え方です。AIは文脈が弱いと、もっともらしいけれどズレた実装を返してきます。Anthropicは、これをプロンプトエンジニアリングの自然な進化として位置づけています（出典：Anthropic「Effective context engineering for AI agents」）。

ハーネスエンジニアリングとは、AIや生成コードを安全に使うための外側の仕組みを整える考え方です。テスト、CI/CD、サンドボックス、権限管理、ログ、静的解析、レビューの流れなどがこれにあたります。OpenAIは、エージェントが信頼性高く働くには、環境設計と信頼できるフィードバックループが必要だと説明しています（出典：OpenAI「Harness engineering」）。 Anthropicも、生成役と評価役を分けるループが、ソフトウェア開発のレビューやQAに対応する構造だと整理しています（出典：Anthropic「Effective harnesses for long-running agents」）。

つまり、バイブコーディングの次に必要なのは、単にプロンプトを上手く書くことではありません。コンテキストを整え、ハーネスを用意し、AIが安全に動ける環境を作ることです。自然言語だけで作る開発スタイルは強力ですが、その周辺をどう設計するかまで含めて初めて実務に耐えます。

バイブコーディングは万能ではありません。向いている場面と向いていない場面を分けて考える必要があります。向いているのは、PoC、認識合わせ、小規模な業務改善、画面のたたき台、単純な自動化、既存機能の軽微な修正などです。こうした場面では、スピードと柔軟性が価値になります。

一方で、基幹システム、個人情報や機密情報を扱う処理、高可用性が必要な本番、複雑な権限管理、長期保守が前提の中核機能には慎重さが必要です。ここでは、速度よりも統制、試作よりも信頼性が優先されます。使いどころを見極めれば、バイブコーディングは非常に強力な手段になります。

図2：バイブコーディングの「適材適所」マップ

この変化の中で、開発者の役割も変わります。これからは、単にコードを書く人ではなく、安全に作れる仕組みを作る人になる必要があります。OpenAIも、エンジニアの主な仕事がコードを書くことではなく、環境を設計し、意図を明確にし、信頼できるフィードバックループを作ることへ移ると述べています（出典：OpenAI「Harness engineering」）。

具体的には、ガードレールを整えることが重要です。何を作ってよいか、どこまで自動化してよいか、どのデータを扱ってよいかを明確にし、レビューや教育の仕組みを用意する。さらに、本番化する際には、運用、監視、引き継ぎまで見据える必要があります。非エンジニアが自由に試作できる時代だからこそ、開発者はその自由を安全に支える役割を担うべきです。

当社でも、実際の開発案件でバイブコーディングを取り入れた例があります。あるエンジニアが入社1年目に担当したのは、システム間で双方向のリアルタイムデータ連携を行う案件でした。片方のシステムで情報を修正すると、もう片方にも即時に反映させる必要があり、その連携を担うバックエンドのREST APIを開発しました。開発支援ツールとしてはGitHub Copilotを用いています。

特徴的なのは、案件アサイン前の事前学習として作ったプロトタイプから、実案件の納品物に至るまで、一貫してバイブコーディングで進めた点です。AIに任せながらも、最終的に機能を問題なく完成させることができました。

うまくいった理由は二つあります。一つは、仕様の理解が十分にできていたこと。何を作るのかが明確で、入力・出力・例外時の挙動まで整理されていたため、AIに任せる部分と人が確認する部分を切り分けやすかったのです。もう一つは、1機能ごとに丁寧に実装とレビューを重ねたことです。大きなものを一気に作ると方向性がぶれやすいため、機能ごとに「本当に正しいか」をレビューしながら進めたことで、実装のズレを早い段階で修正でき、人間が意図を確認しながら品質を担保できました。

この事例は、バイブコーディングがうまくいくかどうかは、AIの性能だけではなく、仕様理解とレビューの設計に大きく左右されることを示しています。前述したコンテキストとハーネスの考え方を、現場レベルで実践した例だと言えます。

バイブコーディングは、非エンジニアがアプリを作る時代を象徴する大きな変化です。実装の初速を上げ、認識合わせを早め、参入障壁を下げる力があります。一方で、品質、セキュリティ、保守性は自動では担保されず、作って終わりではなく、その実装を説明できる責任が残ります。AIだけが理解できる実装になっていれば、それは別の形の属人化です。

だからこそ、次の段階としてコンテキストエンジニアリングとハーネスエンジニアリングが必要になります。そして開発者は、コードを書く人から、安全に作れる仕組みを作る人へ役割を広げていく必要があります。バイブコーディングは万能ではありません。しかし、適材適所で使えば、非常に強い武器になります。