バイブコーディングとは？原義とのズレ・危険性・業務でどこまで任せてよいかの判断基準

「バイブコーディングでやりました」と報告を受けたとき、あなたは何が起きたのかを判断できるでしょうか。

AIがコードを書いたことは分かります。しかし、そのコードを人間が読んだのか、テストを通したのか、誰が壊れたときに直せるのかは、この言葉からは何も分かりません。同じ「バイブコーディングで作った」でも、レビューと自動テスト（CI＝変更のたびに自動でテストを回す仕組み）を通した成果物と、生成された差分を一度も開いていない成果物が、同じ名前で呼ばれています。ここでいう差分とは、AIが今回どのファイルのどこを書き換えたかを、行単位で示した変更内容のことです。

原因は、この言葉の定義が約1年7か月のあいだに静かに広がったことにあります。提唱者が最初に書いた定義には、本記事が確認した日本語5媒体の定義文がいずれも含んでいない条件がありました。

本記事は、その原典を一次ソースで確認するところから始めます。そのうえで、業務でどこまでAIに任せてよいのかを、成果物のクラス別に判断できる形に落とし込みます。

この記事の役割と、他記事との分担

本記事は「バイブコーディングという言葉の定義」と「業務適用の判断」を扱うピラーです。次の3点は扱いません。

• どのツールを選ぶか → AIコーディングツール徹底比較（補完型・エージェント型・自律型のパラダイム理解）、AIコーディングエージェント比較2026（12ツールの網羅比較）
• 仕様駆動開発の実装手順とテンプレート → 仕様駆動開発（SDD）×Claude Code完全ガイド
• 並列AI開発による速度改善の仕組み → AIコーディングで開発速度6倍｜並列AI開発の仕組みと実践ガイド

本記事は「そもそもどこまで任せてよいか」を決め、決まったあとの実務は上記へ送ります。

この記事の要点（Key Takeaways）

• 原典が挙げた条件は「速い」ではなく「差分を読まない」。2025年2月2日（UTC）の投稿でAndrej Karpathy氏が書いたのは、常に「Accept All」を押し、差分をもう読まず、コードが自分の理解を超えていく、という状態です
• 原典が挙げた適用先は「使い捨ての週末プロジェクト」だけでした。業務システムや顧客提供プロダクトについて、原典は推奨も禁止もしていません
• 辞書とベンダー解説を並べると、「理解しない」という条件は定義文からほぼ消えている。本記事が確認した9出典のうち、定義文にこの条件が残っているのは3つ。しかも必須条件として扱っているのは、Karpathy氏の原典とMerriam-Websterの2つだけです
• その結果、この言葉は業務判断に使えなくなった。判断すべきは「バイブコーディングかどうか」ではなく、まず差分を誰が読んだかです
• Stack Overflow開発者調査2025では、当該設問への回答29,163件のうち72%が「業務では使っていない」と回答しています。しかもこの設問が採用した定義は原義より広いものでした
• セキュリティ指示を与えず出力をそのまま受け取ると、45%に既知の脆弱性が入る（Veracode、2026年3月）。この条件は、バイブコーディングが差分を読まずに受け取る状態と重なります
• どこまで許容できるかは成果物のクラスで決まる（本記事の整理）。使い捨てプロトタイプ・社内ツール・顧客提供・基幹という4クラスのどこにあるかで、任せてよい範囲が変わります

バイブコーディングとは — 提唱者が書いたことをそのまま読む

バイブコーディング（vibe coding、日本語では「雰囲気コーディング」と訳されることもあります）という言葉は、2025年2月2日23時17分（UTC）＝日本時間2月3日8時17分に、Andrej Karpathy氏がX（旧Twitter）へ投稿した一件の文章から始まりました。Karpathy氏は本人の経歴紹介によれば、2015年から2017年までOpenAIの創設メンバー（founding member）兼リサーチサイエンティストを務め、2017年から2022年までTeslaのDirector of AIとしてAutopilotのコンピュータビジョンチームを率いた研究者です（本人サイト、2026年9月3日確認）。

この投稿は長文ポストのため、標準的なメタデータやAPIでは先頭280文字までしか取得できません。本記事では、先頭280文字をWeb Archiveに保存されたXのメタデータで、全文を2つの公開ミラーAPIと英語版Wikipediaの引用脚注で突き合わせ、逐語一致を確認したうえで引用しています（原投稿、2026年9月3日確認）。

原文で押さえるべき定義の一文と、実際の手つき

まず、名前を与えている一文です。

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

（新しい種類のコーディングがある。私はそれを「バイブコーディング」と呼んでいる。雰囲気に完全に身を任せ、指数関数的な進歩を受け入れ、コードが存在することすら忘れる、というものだ）

続く部分に、実際に何をしているかが書かれています。原文を添えます。

• 「私はいつも『Accept All』を押す。差分（diff）はもう読まない」（I "Accept All" always, I don't read the diffs anymore.）
• 「コードは私のいつもの理解の範囲を超えて育っていく。本気で読み通そうとしたら、しばらくかかるだろう」（The code grows beyond my usual comprehension, I'd have to really read through it for a while.）
• 「エラーメッセージが出たら、何のコメントもつけずにそのまま貼り付ける。たいていそれで直る」（When I get error messages I just copy paste them in with no comment, usually that fixes it.）
• 「ときどきLLMがバグを直せないことがあり、そのときは回避するか、消えるまでランダムな変更を頼む」（Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away.）
• 「（プロジェクトやWebアプリを作ってはいるが）これは本当のところコーディングではない。ただ何かを見て、何かを言って、何かを走らせて、何かをコピペしているだけで、だいたい動く」（I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.）

原典が語っているのは、LLMの性能向上（"getting too good"）と、キーボードにほとんど触れないという作業の様態です。一方で、「短納期で仕上がる」「開発コストが下がる」といった成果側の効能は、一言も書かれていません。 書かれているのは一貫して「読まない」「理解しない」「直せなくても気にしない」という、人間側の関与の仕方です。

原典が挙げた適用先は1つだけ

そして、この言葉を業務で扱ううえで最も重要な一文があります。

It's not too bad for throwaway weekend projects, but still quite amusing.

（使い捨ての週末プロジェクトなら悪くないし、それでもかなり面白い）

提唱者が挙げた適用先は「使い捨ての週末プロジェクト」だけです。 業務システムや顧客に提供するプロダクトへの適用について、原典は何も書いていません。推奨もしていないし、禁止もしていない、というのが正確な状態です。この記事の残りは、実質的にこの空白を業務の言葉で埋める作業です。

定義はどこでズレたか — 出典を並べて確認する

原典が2025年2月。本記事が確認した日本語5媒体のうち、日付が表示されている4媒体はいずれも2026年の日付でした（残る1媒体は日付表示がありません）。この間に定義がどう変わったかを、出典と日付を明示して並べます。

判定の軸はひとつだけ、「コードを理解しない・読まない」という条件が定義文に含まれているかです。定義文とは、辞書なら見出し語義とそれに続く説明、ベンダー記事なら「〜とは」に相当する冒頭の定義段落、原典なら名前を与えた一文とそれに続く「実際の手つき」の記述を指します。無条件で含まれていれば「必須」、「〜する場合がある（may）」のような限定つきなら「任意」、該当する記述が見当たらなければ「なし」として扱いました。定義段落より後の本文で原典の適用範囲に触れているかどうかは、次の節で別に集計します。

※この表は時系列順ではありません。 日付の性質が行ごとに違うためです。原典はX投稿のUTCタイムスタンプ、Merriam-Websterは初出掲載時期、Collinsは「今年の言葉」発表ブログの日付、英語版Wikipediaは本記事の閲覧日（継続的に編集される二次資料のため）、日本語4媒体（Google Cloud / NTTドコモビジネス / IBM / JAPAN AI ラボ）は検索結果に表示された日付で、公開日か最終更新日かはページ上で明示されていません。Cloudflareは日付表示がないため末尾に置いています。並び順は「原義から広い定義へ」という定義の幅の変化を示すもので、公開順ではありません。

出典URL: Karpathy氏の原投稿 / Merriam-Webster / Collins公式ブログ / 英語版Wikipedia / Google Cloud / NTTドコモビジネス / IBM / JAPAN AI ラボ / Cloudflare。いずれも2026年9月3日に内容を確認しています。ただしMerriam-WebsterとCloudflareはライブページを取得できなかったため、Web Archiveのスナップショットで確認しました。

Merriam-Webster は原義を残している

Merriam-Websterはむしろ厳しい書き方をしています。見出し語義を「AIの助けを借りて、やや無頓着にコードを書くこと」とし、本文でも「バイブコーディングにおいて、書き手はコードがどう動くのか、なぜ動くのかを理解する必要がない。そして一定数のバグや不具合が存在することを受け入れざるを得ないことが多い」と説明しています。2025年時点のスナップショットと2026年8月のスナップショットで、定義文が同一であることをアーカイブで確認しました（確認日は2026年9月3日）。

一方、2025年11月6日にCollins英語辞典が「今年の言葉（Word of the Year）」に選んだときの説明文には、この条件が含まれていません。Collins自身も「技術の専門家のあいだでは、革命的なのか無謀なのか議論が続いている」と書き添えており、賛否が割れたまま言葉だけが一般化したことを示しています。

原典の限定に触れている解説と、触れていない解説

定義文とは別に、本文で原典の「使い捨ての週末プロジェクト」という適用範囲に触れているかどうかも確認しました。本記事が取得した日本語5媒体の本文全文に対し、「週末」「使い捨て」「throwaway」「weekend」などで機械検索した結果は次のとおりです（2026年9月3日確認）。

とくにGoogle Cloudは、原典の限定に触れているだけでなく、実践のされ方を2つに分けています。ひとつは「純粋なバイブコーディング」で、AIの出力が意図どおり動くと完全に信頼する探索的な形式。もうひとつは「責任あるAIを活用した開発」で、こちらは「ユーザーは AI をガイドしますが、AI が生成したコードをレビュー、テスト、理解し、最終的な製品の完全な所有権を持ちます」と説明されています。

つまり、同じ言葉が2つの異なる実践を指していることを、Google Cloud自身が認識して書き分けているわけです。本記事はこの書き分けを、後述の4層（L0〜L3）でもう少し細かくします。

「理解しない」が定義から外れると、言葉が業務判断に使えなくなる

条件がひとつ抜けただけに見えますが、実務上の影響は小さくありません。

広い定義のもとでは、次の2つが同じ言葉で呼ばれます。

• 生成されたコードを人間が読み、テストを書き、CIに通し、レビューを経て本番へ入れた
• 生成された差分を一度も開かず、画面上で動いたのでそのまま本番へ入れた

このふたつは、事故が起きたときの復旧可能性も、引き継ぎ可能性も、責任の所在も、まったく違います。にもかかわらず、稟議書にも見積書にも報告書にも「バイブコーディングで開発しました」と書くだけで通ってしまう余地があります。

経営判断への影響はここに出ます。 承認する側が「AIを使ったかどうか」を聞いても、返ってくる答えは判断材料になりません。リスクの大きさがまるで違う2つが、同じ答えになるからです。結論だけ先に書けば、まず聞くべきは「差分を誰が読んだか」です。

バイブコーディングとAIコーディングは同じではない — 4つの層に分ける

「AIコーディング」と「バイブコーディング」が同義に使われる場面が見られますが、業務判断のためには分けたほうが実用的です。本記事では、人間の関与の仕方で4層に整理します。

本記事の整理では、「AIコーディング」はL1〜L3を含む総称であり、バイブコーディングの原義はそのうちL3にあたります。 L2とL3の見た目はよく似ています。どちらもエージェントに任せ、どちらも自然言語で指示します。違いは成果物の側ではなく、人間が差分を開いたかどうかという手続きの側にしかありません。

だからこそ、外から見て判別できないのです。動いているアプリケーションのスクリーンショットを見せられても、L2とL3は区別がつきません。

なお、導入時の費用対効果を数字で検討したい場合はAIコーディングエージェント業務導入ROI試算にまとめてあります。

業務で使えるのか — 開発者調査が示す実態

「バイブコーディングは業務で使えるのか」という問いには、大規模な調査データがあります。

Stack Overflowの開発者調査2025は、177カ国から49,009件の有効回答を集め、2025年5月29日から6月23日にかけて実施されました（調査方法）。ここにバイブコーディングの設問があります。

広い定義でさえ、72%が「業務では使っていない」

設問は「あなた自身の言葉で答えてください。『バイブコーディング』はあなたの職業上の開発業務の一部ですか？」というものでした。この設問への回答数は29,163件（調査全体の59.5%）です。

集計結果は次のとおりです（AIセクション、2026年9月3日確認）。

大半の回答者はバイブコーディングをしておらず（72%）、さらに5%は自分の開発ワークフローの一部ではないと強く否定している。

ここで重要な注意があります。この設問でStack Overflowが採用した定義は、英語版Wikipediaの広い定義（LLMへのプロンプトからソフトウェアを生成するプロセス）であって、Karpathy氏の原義ではありません。 つまり「差分を読んでいてもプロンプトで生成していれば該当する」という緩い基準です。それでも72%が「業務ではない」と答えました。原義に限定すれば「業務でやっている」と答える割合はさらに下がる（＝72%側がさらに上がる）はずですが、その数値は存在しません。

なお、この調査の回答者はStack Overflowの自社チャネル（サイト内告知、ブログ、メール等）を通じて募集されており、同サイトの利用頻度が高い層に偏る点は調査側も明記しています。母集団は「世界の開発者一般」ではなく「Stack Overflowに関与している開発者」です。

経験10年以上の開発者ほど、AIの正確性を信頼していない

同じ調査から、周辺の2つの数字も引いておきます。

AIツールの正確性への信頼については、「信頼していない」が46%で、「信頼している」の33%を上回りました。「強く信頼している」はわずか3%です。さらに、実務経験10年以上の開発者に限ると「強く信頼している」は2.6%まで下がり、「強く信頼していない」は20%と最も高くなります。調査側はこれを「説明責任を負う立場では、人間による検証の必要性が広く存在することを示している」と解釈しています。

AIツールを使ううえでの不満では、最大の項目が「ほぼ正しいが、少しだけ違うというAIの解答への対処」で66%。これが2番目の不満「AI生成コードのデバッグのほうが時間がかかる」（45%）にしばしばつながる、と調査側は分析しています（回答数25,332件、全体の51.7%）。

問題は「書けない」ことではなく「読まずに受け取れない」こと

これらを合わせると、現場の判断はかなり一貫しています。問題は「AIがコードを書けない」ことではありません。 構文的に正しいコードは高い確率で出てきます。問題は「読まずに受け取れない」ことです。

「ほぼ正しいが少しだけ違う」は、完全に間違っているより厄介です。動いてしまうので、テストが薄ければ通ってしまいます。そして少しだけ違う部分がどこに出やすいかについては、後述の「コスト2: セキュリティ」で見る調査が手がかりになります。

成果物クラス別の判断表 — どこまで任せてよいか

ここからが本題です。「バイブコーディングは是か非か」という問いは答えが出ません。成果物がどのクラスに属するかで、許容できる範囲が変わるからです。

表を読む前に、この記事で使う「受け皿」という語を定義しておきます。受け皿とは、壊れたときに気づき・戻し・直せる仕組みのことです。具体的にはテスト、バックアップと復旧手順、レビュー体制、変更の記録、そして直せたかどうかを判定する基準となる受け入れ基準・仕様書が含まれます。

なお以下は出典のある業界基準ではなく、本記事が実務向けに提案する整理です。

壊れたときの影響は、この順に大きくなります。Aは本番データを入れていない限り、影響は作った本人にとどまります。Bは業務が止まり、データが壊れれば復旧できないことがあります。Cは顧客に損害が及び、信用と売上に直結します。Dは法令対応や監査対応の問題になります。受け皿の重さは、この影響の重さに合わせて決まると考えてください。

表の使い方はひとつです。「AIを使うか」を先に決めてはいけません。「これは何クラスか」を先に決めてください。 クラスが決まれば、許容範囲は自動的に決まります。

クラスは「作った時点」ではなく「使われ方」で決まる

本記事が実務で繰り返し見てきたのは、クラスAとして作ったものが、いつのまにかクラスBやCとして使われている状態です。典型的な経路が3つあります。

経路1: 個人ツールの部内展開。 担当者が自分の作業を楽にするために作った小さなツールが、便利なので部内に共有され、いつの間にか月次の集計がそれに依存します。半年後にその担当者が異動し、誰も中身を説明できないまま業務だけが残ります。

経路2: 検証用の成果物がそのまま居座る。 PoC（概念実証）として作ったものが、「動いているのだから作り直すのはもったいない」という判断で本番運用に転用されます。PoCは検証が目的のため、認証・ログ・エラー処理が意図的に省略されていることが多く、その省略が引き継がれます。

経路3: デモが受注してしまう。 商談用に短時間で作ったデモに顧客が反応し、そのコードベースを起点に開発が始まります。捨てる前提で組んだ構造が、そのまま製品の土台になります。

この3経路は、本記事の見るかぎり悪意も手抜きもなくても起きます。クラスが昇格したことを誰も宣言しなかっただけで成立してしまいます。

昇格を検知する5つのチェック

四半期に一度、社内のAI生成ツールについて次の5点を確認してください。ひとつでも該当したら、そのツールはクラスAではありません。

• 作った本人以外が使い始めたか（クラスB以上へ）
• 本番の実データが入っているか（クラスB以上へ）
• 止まると業務が止まるか（クラスB以上へ）
• 社外の人が触れる場所に置かれているか（クラスC以上へ）
• 作った本人以外が直す必要が生じたか（クラスB以上へ）

昇格が判明したあとに具体的に何をするかは、本記事後半の「途中で切り替えるときの現実的な手順」で扱います。

受け皿がないまま回すと何が起きるか — 3つのコスト

クラスの取り違えが起きたとき、具体的に何が発生するのかを3つに分けます。

コスト1: 技術的負債 —「動くが、誰も説明できない」

原典にある「コードは私のいつもの理解の範囲を超えて育っていく」という一文は、技術的負債と呼ばれる状態と重なります。動作はしているが、変更するときのコストが見積もれない状態です。

この負債が表面化しやすいのは、本記事の経験では最初の仕様変更のときです。Stack Overflow調査の「ほぼ正しいが少しだけ違う」（66%）と「AI生成コードのデバッグのほうが時間がかかる」（45%）は、この局面で効いてくる項目だと本記事は見ています。生成の手数が減るぶん、読む量は増えます。そのコードを、担当者が一度も読んでいない。この2つが重なると、変更のたびに読解からやり直すことになります。

つまりバイブコーディングは、読む時間を将来へ先送りしている構造を持ちます。使い捨てなら、先送りした未来は来ないので問題になりません。使い捨てでないなら、いずれ来ます。

負債の測り方と、溜まってしまったあとの解消戦略は技術的負債とは？診断チェックリスト・ROI計算・4つの解消戦略で扱っています。

コスト2: セキュリティ — 「動く」と「安全」は別の指標

AI生成コードのセキュリティについては、継続的な計測データがあります。

アプリケーションセキュリティ企業のVeracodeが2026年3月24日に公開（同年7月9日更新）した「Spring 2026 GenAI Code Security Update」は、4言語（Java、JavaScript、C#、Python）× 4種類の脆弱性 × 各5パターンの合計80タスクでモデルを評価したものです。Veracodeが継続している調査で、これまでに評価されたLLMは累計150を超えます。2026年春の更新で取り上げられているのはGPT-5.1／5.2、Gemini 3、Claude 4.5／4.6です（原典、2026年9月3日確認）。

まず、この調査の条件を正確に押さえてください。 報告書には次のように書かれています。

we want to know what these models do "out of the box," without any security-specific prompting or guidance.

（これらのモデルが「箱から出したまま」の状態で何をするのかを知りたい。セキュリティに特化したプロンプトも指示も与えずに）

つまり測定されているのは、セキュリティ上の指示を一切与えず、生成された出力をそのまま評価した場合の数値です。

この条件は、バイブコーディングが差分を読まずに出力を受け取る状態と重なります。ただし、Veracodeが測ったのは生成直後の出力の性質であり、人間のレビュー有無を変数にした調査ではない点に注意が要ります。バイブコーディングそのものを測った数値ではありません。

数値を読む前に、もう一点。Veracodeはアプリケーションセキュリティ製品を販売する企業であり、AI生成コードの検査需要を示す立場にあります。 数値を読む際にはこの利害関係を差し引いて考える必要があります。ただし、公開されているテスト設計（対象言語、CWE、タスク数、条件）は明示されており、条件つきの数値として扱う分には有用です。

この表から読み取るべき点は4つあります。

第一に、「構文的に正しい」と「安全」の乖離です。 構文的な正しさは95%を超えているため、コンパイルの段階では問題が見えません。脆弱性は構文の正しさとは独立した性質であり、動作確認で確かめられるのは動く／動かないの側だけです。

第二に、脆弱性の種類による極端な差です。 SQLインジェクションや暗号アルゴリズムは8割以上が安全でした。報告書はこれを「パラメータ化されたSQLクエリや標準的な暗号ライブラリのような、明白で表層的なパターンの認識は得意」と説明しています。一方、クロスサイトスクリプティングとログインジェクションは1割台です。こちらは「複数行・複数ファイルにまたがるデータフローの理解が必要」で、パターン照合を超えた文脈把握が要る、と分析されています。本記事はこの分析を、開発者調査の「ほぼ正しいが少しだけ違う」がどこに出やすいかの手がかりと見ています。

この2つが何を招くかを言い換えると、クロスサイトスクリプティングは利用者のブラウザ上で不正なスクリプトを実行されること、ログインジェクションは記録そのものを偽造されることです（いずれもCWE-80・CWE-117の一般的な説明）。前者は外部に公開する画面に、後者は監査証跡を残す仕組みに直結します。前掲の判断表のクラスC（顧客提供プロダクト）とクラスD（基幹・規制領域）で、この2点はとくに重くなります。

第三に、言語による差です。 Javaの29%は、次に低いJavaScript（57%）のほぼ半分にとどまります。Javaで書かれた基幹系・業務系の資産にAI生成コードを入れるなら、検査を厚くする根拠になります。

第四に、モデルの進歩では解決していないことです。 報告書は「2年間の『革命的な』モデルリリースは、セキュリティの針を約55%から……約55%へ動かした」と書いています。ただし例外があり、GPT-5系の拡張推論モデルは70〜72%と、報告書のなかで最も成績の良い区分でした。報告書はこれについても「本番環境のセキュリティとして受け入れられる水準には程遠い」とし、3つに1つは欠陥を含む計算になると付け加えています。モデル選定で改善する余地はあるものの、全体の平均を押し上げるには至っていない、というのが本記事の読み方です。

AIを組み込んだシステム側のセキュリティ設計についてはプロンプトインジェクション対策｜AIシステムの5層防御と組織セキュリティ、開発ツール導入時の情シス・法務観点はClaude Codeのセキュリティと社内導入時の注意点で扱っています。

コスト3: ライセンスと著作権の混入

AIが生成したコードが、既存の公開コードと一致してしまう可能性については、ツール側に対応機構があります。ただしその機構の性質を正確に知らないと、対策したつもりになります。

GitHub Copilotの公式ドキュメントには次のように書かれています（コード提案の仕様、ポリシー設定、いずれも2026年9月3日確認）。

• GitHub Copilotは各提案について、公開されているコードとの一致を検査する。一致したものは破棄されるか、参照情報つきで提案される。どちらになるかは「公開コードと一致する提案（Suggestions matching public code）」ポリシーの設定による
• ブロックを選んだ場合、多くのCopilot製品では「周辺のおよそ150文字のコードと合わせて」GitHub上の公開コードと照合する
• GitHub Enterprise Cloudの組織からCopilotのシートを割り当てられている場合、個人のアカウント設定でこの項目は変更できず、組織またはEnterpriseの設定を継承する

実務上のポイントは3つです。

1. 一致検査そのものは常時行われますが、一致した提案をブロックするかどうかは設定項目です。 「許可」に設定されていれば、一致する提案も参照情報つきで出てきます
2. ブロックを選んだ場合の照合の窓は「周辺約150文字」という有限の範囲です。この範囲で「一致、または近い一致」があれば、提案は表示されません。より大きな単位での類似がどう扱われるかについては、本記事が確認した公式2ページには記載がありませんでした（2026年9月3日確認）
3. GitHub Enterprise Cloudの組織配布シートでは個人が設定を触れないため、確認先は開発者本人ではなく組織の管理者です

したがって、発注側や情シスが確認すべきは「AIを使いましたか」ではなく、「その設定はどうなっていましたか」「ログは残っていますか」です。この質問は後述のチェックリストに含めています。

なお、AI生成コードの著作権・ライセンス上の扱いは、契約条件や利用したツール、生成物の性質によって評価が分かれる領域です。本記事は法的助言ではありません。 著作権・ライセンスに限らず、法令適用、監査対応、社内規程の整備についても同様です。実際の契約や紛争リスクの判断は、必ず弁護士など専門家に確認してください。

「バイブコーディングは危険ですか？」への回答

この問いは検索でもよく見かけます。短く答えます。

本記事の整理では、危険なのは手法そのものではなく、クラスの取り違えだと考えています。（クラスAで守るべき条件は、前掲の判断表のとおりです）

そのうえで押さえておきたいのは、「AIが書いたから危険」という言い方が正確ではないことです。「コスト2: セキュリティ」で見たデータが示しているのは「セキュリティ指示を与えず、出力をそのまま受け取ると45%に脆弱性が入る」ことであって、「AIが書いたコードは検査を通せない」ことではありません。レビューと検査を挟んだ場合の数値は、この調査には存在しません。挟むかどうかで結果が変わりうる、というのがここでの論点です。

だとすれば、問うべきはクラスに見合う受け皿を置けるかどうかであって、AIを使ったかどうかではありません。ここを取り違えると、対策が「AI利用の禁止」という方向に向かいがちです。しかし禁止された側が報告しなくなれば、受け皿は依然として存在しないままになります。

仕様から始めるべき分岐点 — 仕様駆動開発への切り替え

バイブコーディングは「仕様を書かずにAIへ任せる」やり方です。仕様駆動開発（SDD）は「仕様書を第一級の成果物として扱い、コードをそこから派生させる」やり方です。言葉の上では正反対に見えます。

しかし対立する2つの流派ではありません。適用範囲が違うだけです。 提唱者が原典で挙げた適用先が「使い捨ての週末プロジェクト」だけである以上、業務コードを仕様から始めるべきだという主張と、原義のバイブコーディングは衝突しません。衝突が生まれるのは主に、使い捨てでないものに、使い捨て向けのやり方を適用したときです。

したがって実務で必要なのは「どちらが正しいか」の議論ではなく、どこで切り替えるかの分岐条件です。

分岐チェックリスト — どこまで先に書くか

判定は2段階です。まず前掲の昇格チェック5項目（他人が使う／実データが入る／止まると業務が止まる／社外から触れる／本人以外が直す）を確認してください。ひとつでも該当すればクラスB以上であり、受け入れ基準を先に書く必要があります。

そのうえで、次のいずれかに該当する場合はクラスC以上とみなし、受け入れ基準だけでなく仕様書から始めてください。

• 社外から触れる（昇格チェックの4つ目の再掲）
• 金銭の計算、または法令・社内規程に関わる判断を含む
• 外部ベンダーに発注する
• 既存システムと連携する
• 3ヶ月以上使い続け、途中で担当者が変わる可能性がある

これで判断の軸はクラスひとつに揃います。クラスAなら受け入れ基準も仕様書も要らない、クラスBなら受け入れ基準、クラスC以上なら仕様書から、という対応です。

昇格チェックにも上記にも該当しないなら、原義どおりのバイブコーディングで構いません。ただしその場合も、前掲の「捨てる期限」を決めることと、本番データと認証情報を入れないこと（こちらは例外を認めません）は守ってください。

具体的な進め方（requirements.md / design.md / tasks.md の書き方、業種別テンプレート、失敗パターン）は仕様駆動開発（SDD）×Claude Code完全ガイドにまとめています。

途中で切り替えるときの現実的な手順

すでにバイブコーディングで作ったものがあり、後からクラスが上がった場合、いきなり全面的な作り直しに入るのは得策ではありません。動いているものには、書かれていない仕様（実際の運用でそう使われている、という事実）が埋まっていることが多いためです。

1. 動いているものから仕様を起こす。 入力・出力・使われている画面・依存している外部サービスを1枚に書き出します。この段階でAIに読ませて要約させるのは有効ですが、出てきた内容を人間が確認することが条件です
2. 受け入れ基準を先に書く。 「いまの動作のうち、絶対に変えてはいけないもの」を数個特定します。これが作り直しの安全網になります
3. 作り直す範囲を決める。 全面書き換え、危険箇所の差し替え、当面凍結して手動運用に戻すの3択から選びます。本記事の経験では、いちばん現実的なのは2番目です

PoCや検証段階のものを本番運用へ移す際の全体的な流れはAI PoCの進め方完全ガイド｜5ステップ×5つの壁で本番化を実現する方法、そもそも自前開発が要るのかを判断したい場合はノーコードの限界とは？6つの構造的制約と「カスタム開発に切り替えるべき」判断基準を参照してください。

発注者・情シス向け —「AIで作ったので安い」見積もりをどう評価するか

外部ベンダーから「AIを活用しているので従来より安く・速くできます」という提案を受ける場面があります。この提案をどう評価すべきかを整理します。

安さの出所は、おおむね3つに分かれる

3つのどれなのかを特定することが、評価の実体です。

要件定義、設計、テスト、受け入れ、リリース、運用という工程は、AIの使用によって消えません。したがって実装工程の短縮だけで総額がどこまで下がるかは、工程別の内訳を見なければ判断できません。 大幅な減額が提示されている場合は、差額の出所が2か3でないかを内訳で確認してください。

見積書が「システム開発一式」のような形でまとめられていると、2と3は構造的に見えなくなります。項目の分け方についてはシステム開発の見積書「一式」は何が問題？工程・成果物・工数へ分ける確認方法で扱っています。契約後に追加費用が発生しやすい条件はシステム開発の追加費用が増える7つの条件にまとめました。

ベンダーへそのまま送れる確認質問10

技術的な知識がなくても送れる形にしています。本記事では、回答の内容そのものだけでなく、即答できるかどうかも判断材料になると考えています。

1. 今回の開発で、AIが生成したコードの差分を人がレビューする工程は見積もりに含まれていますか。含まれている場合、どの項目のどの工数ですか
2. レビューは誰が行いますか（実装した本人か、別の担当者か）
3. 自動テストは作成されますか。カバレッジの目標値はありますか
4. 脆弱性検査（静的解析・依存ライブラリの検査）は実施されますか。実施される場合、報告書は納品物に含まれますか
5. 使用するAIコーディングツールの名称と、公開コードとの一致検査に関する設定を教えてください。また、その設定の適用状況が確認できるログや、生成の記録が残っているかも教えてください
6. 生成されたコードの著作権・利用許諾について、契約上どのような取り決めになりますか
7. 納品後に不具合が見つかった場合の対応範囲と期間を教えてください。AIが生成した箇所とそれ以外で扱いが変わる場合は、その違いも教えてください
8. 本システムを、御社以外の会社が引き継いで保守することは可能ですか。可能にするための資料は納品物に含まれますか
9. 設計書・仕様書は納品されますか。それはコードから自動生成したものですか、人が書いたものですか
10. 初期構築費と、年間の運用・保守費を分けて提示してください。AI活用による削減が初期構築費のどの項目に効いているかも示してください

8番と9番は特に重要です。 差分を誰も読んでいない成果物は「動くが誰も説明できない」状態になりやすく、その場合は他社への引き継ぎコストが上がります。ベンダーロックインは技術的な仕組みだけでなく、説明可能性の欠如からも起こりえます。

見積もり全体の妥当性を判断する枠組みは開発会社の見積もり比較ガイド｜7つのチェックポイントと比較表テンプレ、費用相場の目安は【2026年版】システム・アプリ開発費用の相場と見積もり妥当性の判断ガイドにまとめてあります。

社内で解禁するときのルール雛形

「禁止」は現実的な選択肢になりにくいと考えています。使えるツールが手元にある以上、明示的に禁止しても報告されなくなりやすいためです。解禁しつつ、クラスをまたぐ瞬間だけを管理するのが実務的です。

そのまま社内規程のたたき台として使える形で7項目を挙げます。

1. クラスAでの利用は自由とする。 使い捨てのプロトタイプ、個人の作業補助、検証用のスクリプトは、承認なしで使ってよい。ただし捨てる期限を決め、期限が来たら捨てるか、クラスを上げて作り直す
2. クラスAには本番データと認証情報を入れない。 テストデータまたはマスキングしたデータを使う。この1点だけは例外を認めない
3. 他人に共有した時点で申告する。 自分以外の人が使い始めたら、所定の場所（台帳・チャンネル等）へ登録する。登録の目的は禁止ではなく、存在の把握である
4. クラスB以上では、差分を読んだ人を1名以上明記する。 「AIが作りました」で終わる成果物を、クラスB以上に置かない。クラスC以上では読む人を実装者とは別の人とし、クラスDでは誰が・いつ・何を承認したかを記録に残す
5. クラスB以上では、受け入れ基準を先に書く。クラスC・Dでは、加えて仕様書も先に書く。 クラスC・Dから先は仕様駆動開発の領域とする
6. 使用ツールと設定を統一する。 特に公開コードとの一致検査の設定は、個人任せにせず組織設定で固定する
7. 四半期ごとに台帳を棚卸しし、昇格チェック5項目を確認する。 昇格していたものは、その場でクラスを上げる

情シス側で追加すべき事項としては、AIコーディングツールの利用に関するデータの取り扱い（コードが学習に使われるか、どこに保存されるか）、認証方式と管理者制御の範囲、監査ログの取得可否があります。ツールごとの違いはAIコーディングエージェント比較2026の法人ライセンス比較の節で扱っています。

よくある質問

まとめ — 今日決める3つのこと

バイブコーディングは、2025年2月に一人の研究者が自分の週末の作業を描写した言葉でした。その描写には「差分を読まない」という条件があり、挙げられた適用先は「使い捨ての週末プロジェクト」だけでした。 言葉が広まる過程で、この2つは定義文から外れていきました。外れた結果、業務の文脈でこの言葉を聞いても、リスクの大きさが判断できなくなっています。

判断を戻すために、今日決められることが3つあります。

1. 社内にあるAI生成ツールを棚卸しし、それぞれをA〜Dのクラスに割り当てる。 割り当てられないものがあれば、それが最初に手を付けるべき対象です
2. クラスB以上のものについて、「差分を読んだ人」を1名以上特定する。 特定できない、または答えが「作った本人しかいない」ものは、レビューを入れるか、クラスAへ戻す（＝業務依存を外す）かを決めます。クラスC以上なら、読む人が実装者と別であることまで確認します
3. 外注の見積もりに「AI活用による削減」が含まれている場合、削減の出所をこの3分類に照らして確認する。 実装時間の短縮なのか、レビュー・テスト工程の削減なのか、保守費の未計上なのかを、契約前に文書で残します

そして、この記事で一貫して言いたかったことをもう一度書きます。判断の分かれ目は「AIを使ったかどうか」ではありません。「差分を誰が読んだか」と「これは何クラスの成果物か」です。 この2つを聞けるようになれば、言葉の定義が今後さらに広がっても、判断はぶれません。

AIを使った開発をどこまで内製化し、どこにレビュー体制を置くべきか、既存のAI生成資産をどう本番品質へ引き上げるかについて具体的に相談したい場合は、お問い合わせからご連絡ください。設計からレビュー体制の構築まで、一気通貫でご相談に応じています。