バイブコーディングは、仕事につながる場面があります。ただし、求人や企業が見ているのは「AIに指示してコードを出せる」ことよりも、出てきたコードを検証し、本番で責任を持てるかどうかです。
「バイブコーディング」は誰が、いつ言い出した言葉か
この言葉を最初に使ったのは、OpenAIの共同創設者で、元TeslaのAI責任者でもあるアンドレイ・カーパシー氏です。TechCrunchは2025年3月の記事で、同氏が「前の月」にこの言葉を使ったと書いていて、時期は2025年2月です。
同氏の元の発言は、雰囲気に身を任せ、コードの存在すら忘れてしまうような開発を指していました。The Registerの記事が、辞書会社のCollinsによる引用として伝えています。
Collins English Dictionaryは、2025年11月6日に「vibe coding」を同年の「今年の言葉」に選びました。Collinsの定義は、自然言語で指示したAIを使ってコードを書くことです。
ここで注意したいのは、元の意味と、いま広く使われている意味にずれがあることです。
- 元の意味：コードの存在を意識せず、AIに任せ続ける使い方
- 広い意味：AIに指示して、アプリやコードを作る開発全般
- Stack Overflowの調査での説明：プロンプトから、アプリ全体を生成すること
2026年2月には、カーパシー氏自身が新しい言葉を出しました。Business Insider Japanによると、バイブコーディングの誕生から1年にあたる時期に、同氏は「エージェントエンジニアリング」を提唱しています。
バイブコーディングは人がAIに指示してコードを書かせる手法で、エージェントエンジニアリングはAIエージェント自身がコードを書き上げる手法だと説明されています。同氏は、そこには専門的な知見が伴うから、と述べたと報じられています。
求人には書かれているのか：海外の例
求人にこの言葉が出てきたのは、海外が先です。Business Insider（日本版は2025年6月）は、バイブコーディングの経験やCursorなどのAIコードツールへの習熟を明示した求人を、複数見つけたと伝えています。
- Visa：オースティンの生成AIエンジニア3職種で、バイブコーディングツールの知識を「必須」にした
- Reddit：CursorやBoltなどのAIコーディングツールと自社システムの連携を作り、保守できるエンジニアを募集した
- Domu Technology（Y Combinator出身のスタートアップ）：バイブコーディングの経験を必須とし、候補者のコードの少なくとも半分がすでにAIで書かれていることを求めた
求人に共通していた理由は「スピード」でした。一方で、同記事は、Magnificent Seven（米国の大手テック7社）の求人では、バイブコーディングの経験を求める例は見つけられなかったとも書いています。
Forbes JAPAN（2025年11月）は、米ウォルマートがシニア・ソフトウェアエンジニアの求人で「創造的で技術的に鋭いバイブ・コーダー」を求めた例を紹介しています。
一方で、AIでコードを書くこと自体は広がっています。
- レバテックがITエンジニア572名に2026年5月に聞いた調査では、AIを「毎日使用している」が43.4%、「週に数回」が28.3%で、合わせて7割超が日常的に使っています。AIを使う業務は「コーディング・実装」が40.9%でした
- Stack Overflowの2025年の調査（4万9,000人超）では、バイブコーディングについて、約72%が「自分の仕事の一部ではない」と答え、さらに5%は「まったく行わない」と答えています
- 同社の2026年の調査（3万人超）の記事では、AIを使った開発で多いのは「慣れた領域でのコード生成」（67%）と「デバッグ」（61%）で、「本番システムのデプロイ・運用・障害対応」は20%でした
ここから読み取れるのは、「バイブコーディング」という名前の求人はまだ多数派ではなく、AIを使ってコードを書く仕事は、すでに日常になっているということです。
実際に仕事になっているのは、どこか
1つ目は、スタートアップの試作と初期開発です。TechCrunch（2025年3月）によると、Y Combinatorの2025年冬期バッチのうち4分の1のスタートアップで、コードの95%がAIで生成されていました。
Y Combinatorの共同マネージングパートナーのジャレッド・フリードマン氏は、非技術系の創業者に投資したわけではなく、全員が高い技術力を持ち、自分で一から作れる人たちだと説明しています。同じ議論の中で、同社のダイアナ・フー氏は、コードを読んでバグを見つける力が必要だと述べ、CEOのギャリー・タン氏も、長く運用するには従来のコーディングの訓練が必要だという点に同意しています。
仕事にしている人の多くは、AIなしでも作れる人が、AIで速く作っている、という構図です。
2つ目は、大企業の開発基盤です。TechTarget ジャパンによると、Googleは2026年4月のGoogle Cloud Next '26で、AI Studioの担当者が、AIによるアプリ開発は実験段階を越え、本番環境に投入される時代に入ったと説明しました。
同じ記事では、AI Studio自身のプロダクトのコードは、AIが変更を生成したあと、専門のエンジニアがレビューとCIテストを行ってから本番に反映される、と紹介されています。
3つ目は、1人での開発です。Stack Overflowの2026年の調査では、「1人の組織で働いている」と答えた人が4%から10%に増えました。
同社は、AIエージェントを使って1人で事業を成り立たせる動きの表れかもしれない、と書いています。
運営会社も、AIを使って複数のプロダクトを自社で作り、本番で運用しています。その経験からいうと、プロンプトで作ったものが仕事として成り立ちやすいのは、試作、社内ツール、影響範囲が小さい自動化のように、人が結果を確認できる場面です。
扱うデータや権限、お金が増えるほど、「動いた」だけでは足りなくなります。
「作れる」と「任される」は、どこが違うのか
ここが、採用側の見方でいちばん大きく分かれる点です。運営会社は、AIを使って作ったプロダクトを運用してきた中で、「動いた」あとに起きたことを何度も経験しています。
- データベースのAPIが一度に返す件数に上限があり、一覧が途中で黙って切れました。除外リストが不完全になり、同じ相手に二重で送ってしまいました。機能そのものは、書いたとおりに動いていました
- 開発環境では管理者権限で何でも通るため、一般ユーザーの権限で起きる問題が見えませんでした。権限の漏れが2件、本番まで気づけませんでした
- AIで数百件のデータを抽出したところ、取りこぼしと、元にない内容の混入が出ました。原文と機械的に照合する仕組みに変えました
どれも、プロンプトに書いた機能は動いていました。壊れたのは、書かれていなかった前提のほうです。
現場のエンジニアの調査にも、同じ傾向が出ています。キッカケクリエイションがコードレビュー担当のITエンジニア322人に2026年2月に実施した調査では、AI生成コードをレビューした277人のうち、約9割（86.3%）がレビュー側の負担増を感じていました。
問題だと感じた点は、「提出者本人がコードの内容を説明できなかった」が49.5%、「動作するが、なぜ動くのか理解しにくい」が33.6%、「エッジケースで正常に動作しない」が31.8%、「セキュリティ上のリスクがあるコードが含まれていた」が17.0%でした。
レバテックの調査では、「今後も人間によるコードレビューは必要」と答えた人が95.5%でした。必要な理由の1位は「AIの判断だけでは、ビジネス要件やユーザー文脈を十分に担保できないため」（66.4%）、2位は「セキュリティや品質に関する最終責任は人間が負う必要があるため」（43.8%）でした。
セキュリティについては、Veracodeが2025年7月に公表した試験があります。100を超えるLLMに、80のコーディング課題を、安全な書き方と危険な書き方が選べる形で出したところ、45%のケースで危険な書き方が選ばれました。
「作れる」と「任される」の違いは、次のとおりです。
| 観点 | 作れる | 任される |
|---|---|---|
| 完成の基準 | 画面が動いた | 想定外の入力・件数・権限でも壊れないことを確かめた |
| 説明 | 指示の履歴を話せる | コードの意味と、選んだ理由を話せる |
| 失敗したとき | 作り直す | 原因を切り分け、再発しない形にする |
| 扱うもの | 自分だけのデータ | 他人のデータ、お金、個人情報 |
| 周囲との関係 | 1人で完結する | レビューを受け、他の人が保守できる形で残す |
任される人とは、壊れたときに一緒に直せる人です。採用側が見ているのは、AIに指示する力そのものより、その人が責任を持てる範囲がどこまでか、という点です。
現役のエンジニアの方にとっては、この差はレビューする立場の話でもあります。AIが書いたコードを受け取ったとき、本人が説明できるかを確かめる、という役割が増えています。
採用側が確かめること：面接やレビューでの質問
運営会社がAIを使って作った成果物を見るときは、次のような質問をします。
- このコードの、この部分は何をしていますか。別の書き方と比べて、なぜこれにしましたか
- AIの提案を採らなかった例はありますか。理由は何でしたか
- 件数が10倍になったら、どこが壊れそうですか。権限の違うユーザーが使ったらどうなりますか
- 一度壊れたときの原因と、直し方を教えてください
- 本番で多くの人に使われるなら、次に何を直しますか
答えの中身は、AIを使ったかどうかより、自分で判断した跡があるかで見ます。答えに詰まる質問があっても、「そこは確認していません。確認するなら、こうします」と言えれば、任せられる範囲を判断する材料になります。
ポートフォリオと職務経歴書での見せ方
アプリの横に、次の5つを置いてください。READMEなど、見つけやすい場所にまとめます。
- 動いている証拠。公開URL、使った人や場面（個人情報は出さない）、稼働している期間
- 自分で決めたことと、AIに任せたことの線引き
- 壊れた事例と、直した記録。原因、修正、再発防止の順で書きます
- 確かめたこと。テスト、権限、入力の上限や件数、秘密情報の扱い
- 作り直すなら変えること
書き方の例です。
## このアプリでやったこと
- 目的：○○の集計を手作業から自動にする（利用者：自分のチーム3人）
- 自分で決めたこと：データの持ち方、画面を3つに絞ったこと
- AIに任せたこと：画面の実装、集計処理の初稿
- 壊れた事例：データが多いと一覧が途中で切れた
→ 原因は取得件数の上限。ページ分けで取得し、件数を照合するテストを追加
- 確認したこと：空データ、10倍のデータ、権限の違うユーザーで試した
- 次に直すこと：ログの見える化、バックアップの手順
職務経歴書やESでも、書き方は同じです。「Claude Codeを使ってアプリを開発しました」と書くだけでは、AIに任せた範囲しか伝わりません。
次のように、自分が決めたことと確かめたことを足します。
- 変更前：Claude Codeを使って、集計アプリを開発しました
- 変更後：手作業だった月次の集計を自動化するアプリを作りました。実装はAIに任せ、データの持ち方と、入力の上限・権限の確認は自分で行いました。データが増えたときに一覧が切れる不具合が出たため、原因を切り分け、件数を照合するテストを追加しました
AIで作ったことを隠す必要はありません。AIを使ったうえで、何を判断し、何を確かめたかを書くほうが、読み手は質問を作りやすくなります。
今日からできること
- 小さなものを1つ作って公開します。個人情報や決済を扱わないものにします
- 1回、わざと壊します。空のデータ、10倍のデータ、権限の違う利用者で試し、直した記録を残します
- コードを1ファイル選び、各部分が何をしているかを声に出して説明します。説明できない部分は、AIに質問して理解するまで読みます
- 上のREADMEの5項目を、作ったものに足します
- 気になる求人票で、AIの扱いがどう書かれているかを確認します。「バイブコーディング」と書かれていなくても、AIを使った開発を前提にする求人はあります
バイブコーディングは、入口としては十分に使えます。仕事につなげるときは、作れることに加えて、確かめたことを持っているかどうかを見てもらうことになります。
