「その画面、バイブコーディングで作りました」。DX推進を預かる立場の方が、若手からこう報告を受けて言葉に詰まる場面が増えています。動いているものは目の前にある。しかし、それが本番で使ってよいものなのか、誰がレビューしたのか、保守は誰が持つのか。判断の基準が社内にないのです。
禁止するのは簡単です。ただ、禁止した瞬間にその手法は見えないところへ潜ります。逆に放任すれば、数か月後に誰も中身を説明できないアプリが部門ごとに散在します。必要なのは是非の表明ではなく、どこまでが安全圏かという線引きです。
この記事では、バイブコーディングという言葉の定義と出自を一次情報で押さえたうえで、企業で使える業務と使ってはいけない業務の境界を整理します。
バイブコーディング（vibe coding）とは、自然言語でAIに意図を伝え、AIが生成したコードを人間が細部まで読まずに受け入れながら、動作を確かめて反復していくソフトウェア開発の進め方を指します。日本語では「雰囲気コーディング」と訳されることもありますが、業界では英語のまま使われるのが一般的です。
重要なのは、これが「コードを書かない」手法ではないという点です。コードは生成されており、リポジトリにも残ります。書いていないのは人間であって、存在していないわけではありません。この区別を曖昧にしたまま議論すると、後述するガバナンスの話が噛み合わなくなります。
提唱者は、TeslaのAI部門を率い、OpenAIの創設メンバーでもあったAndrej Karpathy氏です。2025年2月に自身のSNS投稿で用いたのが起点とされ、そこから急速に普及しました。IBMの解説やGoogle Cloudの解説でも、この出自が共通して示されています。
（出典：Andrej Karpathy, Tesla Alum and OpenAI Co-Founder, Joins Anthropic）
言葉としての定着も速く、Collins Dictionaryは2025年の「Word of the Year」にvibe codingを選定しました。Collinsの発表およびCNNの報道によれば、選定理由は「AIを使って自然言語をコンピュータのコードに変換する新しいソフトウェア開発」という技術的定義そのものにあります。流行語として消費されただけでなく、開発手法の一類型として辞書に載ったという事実は、社内説明の際に有効な参照点になります。
学術的な検討も始まっています。2025年に公開されたarXivの論文は、バイブコーディングを「AIを介してコード生成と操作をオーケストレートし、選択的・戦略的な監督を維持する」実践として位置づけています。ここで鍵になるのは「選択的・戦略的な監督」という条件です。監督を放棄した状態は、定義上バイブコーディングですらないという読み方ができます。
「結局ノーコードでは」という反応は必ず出ます。しかし、両者は操作の主体と客体が逆転している点で構造的に異なります。ここを説明できるかどうかが、社内の理解度を分けます。
ノーコードツールは、あらかじめ用意された部品を人間が画面上で組み立てます。できることはツールが定義した範囲に限られ、その代わり結果は予測可能です。一方バイブコーディングでは、人間は意図を述べるだけで、部品の選定も配置もAIが決めます。出力はコードそのものなので、原理的にはツールの想定範囲に縛られません。
この違いは、実務上ふたつの帰結を生みます。ひとつは、要件が特殊であるほどバイブコーディングのほうが射程が広いこと。もうひとつは、成果物がコードである以上、レビュー・テスト・保守という従来型の責任がそのまま残ることです。ノーコードの感覚で始めて、後者を見落とすのが典型的な失敗です。
手順そのものは単純です。ただし、単純だからこそ、どこで人間が判断を挟むかが品質を決めます。以下の4段階で捉えると、社内の役割分担も設計しやすくなります。
第一段階は意図の言語化です。何を、誰のために、なぜ作るのかを文章にします。Lovableの公式ガイドが「曖昧なアイデアは曖昧な出力を生む」と述べるとおり、この工程の粗さがそのまま成果物の粗さになります。第二段階が生成、第三段階が動作確認、第四段階が修正の反復です。
実務で差がつくのは第四段階です。1回のメッセージに複数の修正を詰め込むと、直したはずの箇所が別の変更で壊れます。1メッセージ1変更に分け、変更してよい範囲を明示する。この規律を守れるかどうかが、数十回の反復のあとに残るものを決めます。具体的な書き方の型はプロンプトライブラリや実践ガイドに整理されており、用語の定義は公式の用語集で確認できます。
「バイブコーディングのツール」とまとめて語られますが、実際には想定する利用者も守備範囲も異なります。選定を誤ると、エンジニア向けのツールを非エンジニアに渡すことになり、定着しません。
注目すべきは機能の多寡ではなく、誰が使う前提で設計されているかです。以下は2026年8月時点の公開情報にもとづく整理で、各社の機能は頻繁に更新されるため、選定時には必ず一次情報を確認してください。
| ツール | 主な想定利用者 | 守備範囲 |
|---|---|---|
| Lovable | 非エンジニアを含む業務部門・チーム | 画面からデータベース・認証・公開までを一気通貫。SSO・監査ログ等の組織統制を持つ |
| Cursor | エンジニア | 既存コードベースへの高度な編集。本番運用中のシステム改修に強い |
| Bolt | プロトタイプ制作者 | ブラウザ内での高速な生成と試行 |
| v0 | フロントエンド担当・デザイナー | UIコンポーネント単位の生成 |
| Replit | 開発者・教育用途 | 実行環境込みのフルスタック開発 |
企業導入で論点になりやすいのは、この表に現れない部分です。すなわち、生成されたコードの所有権、シングルサインオンの可否、監査ログの有無、そして請求の形態です。個人の生産性向上なら機能で選べますが、組織展開では統制機能の有無が選定を決めます。
もっとも実務的な論点です。ここを曖昧にしたまま「試してみよう」と号令をかけるのが、最も危険な進め方です。判断軸は3つあります。扱うデータの機微性、失敗したときの影響範囲、そして保守の担い手が決まっているかです。
この3軸で見ると、多くの企業にとっての安全圏は驚くほど広く取れます。同時に、絶対に踏み込んではいけない領域も明確になります。
| 領域 | 具体例 | 判断 |
|---|---|---|
| 適する | 紙の点検表・申請書の入力アプリ化、部門内のExcel台帳の置き換え、社内向けの集計ダッシュボード、キャンペーン用の一時的なLP | 影響が部門内に収まり、失敗しても業務が止まらない |
| 条件付き | 顧客情報を扱う社内ツール、複数部門が使う業務アプリ、外部公開する申込フォーム | 権限設計のレビューと保守担当の明示を必須にする |
| 適さない | 会計・給与など基幹システムの中核、決済処理そのもの、法令上の保存義務を負う記録の唯一の保管先、人命・安全に関わる制御 | 監査・可用性・責任分界の要求水準が異なる |
「条件付き」の行を空欄のまま運用に入れないことが重要です。とくに権限設計は、生成されたアプリが最も事故を起こしやすい箇所です。ログインを実装したことと、他人のデータが見えないことは別問題であり、この確認は生成AIに任せきりにできません。
バイブコーディングの普及に伴い、シャドーITの新しい形が問題になっています。従来のシャドーITは「情シスが知らないSaaSの利用」でしたが、いまは「情シスが知らない自作アプリの稼働」に変わりました。後者のほうが厄介なのは、責任の所在が組織の外ではなく内側にあるためです。
作った本人が異動すれば、そのアプリは誰も中身を説明できないまま業務に組み込まれて残ります。障害が起きたとき、復旧できる人間が社内にいません。これは技術の問題ではなく、棚卸しの仕組みを用意しなかった運用の問題です。
もうひとつ、生成物の品質に対する社会的な警戒も高まっています。Merriam-Websterは2025年の「Word of the Year」に、AIが大量生成する低品質なコンテンツを指す「slop」を選びました。生成が速いことと、良いものができることは別だという認識が広く共有されつつあるということです。この視点は、社内レビューの必要性を説明する際の後ろ盾になります。
対策の方向は明確です。作ってよい業務の定義、扱ってよいデータの定義、保守担当の明示、そして定期的な棚卸し。この4点をルール化すれば、禁止せずに統制できます。監査ログや公開権限の制限、放置アプリの自動退役といった機能を備えたツールを選ぶことも、運用負荷を下げる現実的な手段です。
先に引用した学術的な定義は、バイブコーディングの成立条件として「選択的・戦略的な監督」を挙げていました。抽象的に聞こえますが、実際のツール上では具体的な操作に落ちています。ここを操作レベルで説明できると、社内ルールが空文化しません。
監督が入る場所は大きく3つあります。作る前の合意、作った後の点検、そして運用中のデータの扱いです。順に見ていきます。
意図をそのまま実装させると、AIの解釈がずれたまま数十ファイルが書き換わります。これを防ぐのが、実装前に計画を提示させる仕組みです。LovableではPlan modeとBuild modeとして分離されており、Plan modeはコードを書かずにプロジェクトを調査し、確認質問を返し、編集可能な計画を提示します。公式ドキュメントによれば、Plan modeはメッセージあたり1クレジット固定で動作します。
実装を担うBuild modeは使用量ベースの従量課金で、変更ファイル数やロジックの複雑さによって消費が変わります。つまり「決める」工程を固定費で回し、合意できた計画だけを従量の実装に流すという分業が、コスト面でも品質面でも合理的です。監督とは、この計画に人間が目を通して承認する行為そのものを指します。
動作確認は監督ではありません。画面が意図どおり表示されることは、権限設計が正しいことを何ら保証しないからです。セキュリティに関する解説や公式のセキュリティページが繰り返し扱っているのも、この見えない層の話です。
公開前に確認すべきは、ログインしていない人に何が見えるか、他人のデータが見えないか、管理者だけが実行できるはずの操作が一般利用者にも開いていないかの3点です。Enterpriseプランでは定期的な深いセキュリティスキャンが提供されており、組織的に点検を仕組み化する手段も用意されています。
見落とされやすいのが、開発中にAIへ渡すデータの扱いです。業務仕様や実データの一部をプロンプトに貼ることは日常的に起こります。
Lovableの公式ドキュメントによれば、2026年9月9日以降、FreeプランとProプランの顧客データはAIモデルの学習に利用される可能性があり、利用者はアカウント設定からオプトアウトできます。一方、BusinessプランとEnterpriseプランのワークスペースデータは契約にもとづき既定で学習対象外です。この違いは、どのプランを法人利用に選ぶかを直接左右します。契約面の詳細はデータ処理契約やトラストセンターで確認できます。
他社ツールを検討する場合も、確認すべき論点は同じです。学習利用の既定値、オプトアウトの可否、そしてそれが契約で担保されているかどうかを、プランごとに確認してください。
流行だから追うべきだ、という話ではありません。日本企業には、この手法を検討せざるを得ない構造的な事情があります。
経済産業省の「IT人材需給に関する調査」では、IT需要の伸びによっては2030年に最大で約79万人のIT人材が不足すると試算されています。関連する経済産業省の資料でも、IT分野の人材需給は継続的な論点として扱われています。外注で埋めようにも、外注先も同じ市場から人を採っています。
一方で、IPAが2026年7月に公表した国内企業のDX・AI活用動向では、AI導入は着実に広がっているものの、業務効率化の段階から新たな価値創出やビジネス変革へ発展させることが課題として示されています。DX動向調査が毎年浮き彫りにしているのは、道具の不足ではなく、道具を成果に変える設計の不足です。前年版の調査でも、システム開発の内製化はレガシー刷新やAI利活用と並ぶ主要論点として扱われています。
バイブコーディングは、この構造に対する部分的な解になりえます。ただし「現場が自分で作れるようになる」ことと「作ったものが業務として回る」ことの間には、依然として設計と運用の仕事が残ります。ここを誰が担うのかを決めずに導入すると、野良アプリの量産で終わります。
導入判断のために、両面を並べます。社内説明で片側だけを示した資料は、必ず反対意見に崩されます。
| 観点 | メリット | デメリット・留意点 |
|---|---|---|
| 速度 | 要件定義と並行して動くものを提示でき、合意形成が速い | 速さゆえに検討不足のまま本番化しやすい |
| コスト | 小規模な社内ツールの外注費と待ち時間を圧縮できる | 従量課金のため、使い方次第で費用が変動する |
| 人材 | 非エンジニアが業務知識を直接形にできる | レビューできる人材は依然として必要 |
| 品質 | 反復が容易で、実物を見ながら改善できる | 権限設計など、見た目に現れない欠陥を見落としやすい |
| 統制 | 統制機能を持つツールなら棚卸しが可能 | ツール選定を誤ると野良アプリが増える |
この表の「品質」の行が、最も過小評価されます。画面が正しく表示されることは確認しやすい一方、他人のデータが見えてしまう設定ミスは、動作確認では発見できません。公開前の権限チェックを工程として組み込んでください。
いきなり全社方針を決めようとすると、議論が抽象化して止まります。実物を1つ作り、それを題材にルールを書くほうが速く、かつ社内の納得も得やすいのが実情です。
対象に選ぶべきは、紙やExcelで回っている部門内の業務で、失敗しても他部門に影響が出ないものです。既存の申請フローや点検記録が典型で、扱うデータの機微性が低く、改善効果を工数で数値化しやすいという条件を満たします。
そのうえで、作る前に「保守は誰が持つか」を決めてください。この一項目を先に決めるだけで、野良アプリ化の大半は防げます。ツールの選定や統制設計を含めた進め方は、Lovableとは？できること・料金・使い方を日本公式パートナーが徹底解説で具体的に解説しています。
流行語としての側面はありますが、それだけではありません。Collins Dictionaryが2025年のWord of the Yearに選定した際の定義は「AIを使って自然言語をコードに変換するソフトウェア開発」であり、手法として記述されています。用語が廃れても、この開発の進め方自体は残ると考えるのが妥当です。
ツールごとに規約が異なるため、一律には言えません。導入前に各ツールの利用規約でコードの帰属と商用利用の条件を確認し、法務のレビューを通してください。ここを未確認のまま本番化すると、後から差し戻される典型的な論点です。
部門内で完結する小規模な業務アプリであれば使えます。ただし、公開範囲や権限の設計を確認できる人が組織内に1人は必要です。作る人と点検する人を分けてください。
まず稼働しているものを棚卸しし、扱っているデータと利用範囲を把握してください。禁止から入ると地下化して見えなくなります。実態を把握したうえで、条件付きで認める領域を定義するほうが統制は効きます。
不要にはなりません。基幹システムや、可用性・監査要件の高い領域は引き続き従来型の開発が適します。変わるのは、すべてを外注していた領域のうち一部が内製に移り、外注の役割が設計・統制・品質保証の側へ寄るという点です。
多くのツールが従量制のクレジットを採用しているため、固定費だけでは見積もれません。作る規模と反復回数によって変動します。予算化する際は、上限設定や利用者ごとの制限を持つプランを選び、想定超過時の挙動を事前に確認してください。Lovableの場合はクレジットの消費と枯渇時の挙動が公式に明記されています。
「作ってよい業務」「扱ってよいデータ」「保守担当の明示」「棚卸しの頻度」の4項目です。ツールの操作ルールから書き始めると、ツールを変えたときに全部書き直しになります。業務とデータの側から定義してください。
バイブコーディングは、自然言語でAIに意図を伝えてソフトウェアを作る手法として、辞書に載るまでに定着しました。速度と裾野の広さは本物です。同時に、生成されるものがコードである以上、レビュー・権限設計・保守という責任は消えません。
したがって企業が決めるべきは、使うか使わないかではなく、どこまでを現場に開放し、どこから統制の対象とするかという境界です。その境界は、扱うデータの機微性・失敗の影響範囲・保守の担い手という3軸で引けます。
最初の1つを部門内の小さな業務で作り、それを題材に4項目のルールを書く。この順番が、禁止にも放任にも陥らない現実的な進め方です。導入設計や統制の具体化についてのご相談は株式会社100の問い合わせ窓口で受け付けています。