Opsfield
バイブコーディングとは、コードをほとんど読まずに、自然言語の指示だけで動くものを作る新しい開発の進め方です。2025年に生まれた言葉ですが、いまではエンジニア以外の企画職や情報システム部門が、自分の手で社内ツールを形にする手段として使い始めています。
開発部門に依頼しても順番待ちで数週間。そうした小さな不便を抱えている方ほど、この進め方の恩恵は大きくなります。ただし、手軽に作れることと、業務で使い続けられることは別の話です。作ったはずの機能が後から壊れる、セキュリティの穴に気づかないといった問題は、使い始めてから表れます。
本記事では、バイブコーディングの定義と進め方の5ステップ、おすすめツール8選だけでなく、メリットとデメリット、どこまでAIに任せてよいかを決める4つの判断軸なども解説します。
目次
バイブコーディングとは？AIとの対話だけで動くものを作る進め方
バイブコーディングは、コードをほとんど読まずに、自然言語の指示だけで動くものを作る開発手法です。人は出てきた画面を動かして確かめ、思いどおりでなければ言葉で指示を出し直します。つまり、プログラムを書く役はAIに渡し、人は作りたいものを伝えて結果を見極める側に回るわけです。
そもそもこの言葉は、2025年2月にAndrej Karpathy氏が自身の投稿で使った造語です。Karpathy氏はOpenAIの創業メンバーの一人で、TeslaでAI部門を率いた研究者でもあります。投稿で語られていたのは、週末に遊びで何かを作るときの話でした。エラーが出たらメッセージをそのまま貼り付けて直してもらい、中身は読まずに先へ進む。その気軽さを、雰囲気（バイブ）に身を任せる作り方として言い表したのです。
ところが言葉が広まるにつれて、業務で使う道具の作り方としても語られるようになりました。社内の集計画面や申請フォームのように、これまで開発部門に頼んでいた小さなツールを、担当者が自分で作る場面が増えています。ただし、もともとは遊びの文脈で生まれた作り方のため、業務で使う場合は、安全面や引き継ぎを人の側で補わなければなりません。
バイブコーディングとAIのコード補完・ノーコード開発の違い
AIのコード補完やノーコード開発も、プログラミングの手間を減らす方法として並べて語られますが、この3つを分けるのは、人がどこまでコードに触るかです。
| AIのコード補完 | ノーコード開発 | バイブコーディング | |
|---|---|---|---|
| 人がAIに渡すもの | 書きかけのコードとコメント | 画面上の操作（部品の配置・設定） | やりたいことの短い指示 |
| 人とコードの距離 | 提案された候補を読んで採否を決める | 利用者がコードを目にすることはない | ほとんど読まずに動作だけを見る |
| 作れる範囲 | 書き手の技量まで | 用意された部品の範囲まで | 指示を言語化できる範囲まで |
| 主な使い手 | エンジニア | 業務部門の担当者 | エンジニアと業務部門の双方 |
| つまずきやすい点 | 使う人の技量で効果の差が大きい | やりたいことが部品から外れると詰まる | 中身が見えず、不具合の原因を追いにくい |
バイブコーディングでは人はコードをほぼ読まず、動いた結果だけを見て次の指示を決めます。一方、AIのコード補完は書きかけのコードの続きを予測する使い方です。数行から関数1つ分まで提案されることもありますが、最後まで実装者は人であり、出てきた候補を読んで採るか捨てるかを判断していきます。速くはなっても、コードを読む前提は変わりません。
なお、最近のAIエディタには、補完とは別に、作業をまとめて任せるエージェント機能を備えたものも増えています。AIエディタとは、プログラムを書いて編集するソフトにAIを組み込んだもののことです。こちらを使って指示だけで作るなら、同じツールでもバイブコーディングの分類に入ります。
次に、ノーコード開発との違いは、作れる範囲の決まり方に表れます。ノーコードで組めるのは、サービスが用意した部品の組み合わせまで。対してバイブコーディングで出てくるのは実際のコードなので、部品の制約を受けない代わりに、中身の安全性や保守の責任が手元に残ります。
バイブコーディングとAI駆動開発の違いと使い分け
バイブコーディングとAI駆動開発も、よく並べて語られる組み合わせですが、2つは対立する手法ではありません。違いは、仕様をどこまで固めてからAIに渡すかにあります。
| バイブコーディング | AI駆動開発 | |
|---|---|---|
| 仕様の固め方 | 固めずに、対話しながら形にする | 工程ごとに固める度合いを変える |
| AIに渡すもの | やりたいことの短い指示 | 工程に応じた入力（要求メモ・仕様・既存コード） |
| 人の関わり方 | 出てきた画面を見て指示を出し直す | 渡す工程と権限を決め、成果物を検証して承認する |
| 向く場面 | 試作・社内の小さなツール | 既存の開発プロセス全体への組み込み |
まず、AI駆動開発は、要件定義から設計、実装、テスト、レビューまでの開発工程そのものをAIに実行させ、人は仕様の定義と成果物の承認を担う進め方です。工程ごとに仕様を固める度合いを変えていくのに対し、バイブコーディングは仕様を固めずに対話しながら形にします。そのため試作の手軽さでは勝る一方、決めた内容が仕様として手元に残りません。
そこで現実的なのが、2つをつなげて使う形です。例えば、現場の担当者がバイブコーディングで試作を作り、画面の流れや必要な項目を関係者と確かめたうえで、要件が固まった段階から本番をAI駆動開発の進め方に移し、開発部門が工程と権限を決めて作ります。こうすれば、試作は使い捨てで終わりません。関係者が触って洗い出した項目や画面の流れが、そのまま本番の要件を固める材料になります。
なお、AI駆動開発の全体像と工程別の進め方は、AI駆動開発とは？メリットと工程別の進め方で詳しく解説しています。
バイブコーディングが注目される背景
注目が集まった直接のきっかけは、AIに任せられる作業の単位が大きくなったことです。以前のAIは、書きかけのコードの続きを数行ずつ提案するのが中心でしたが、いまでは複数のファイルをまたいで書き換え、動かして、エラーを見て直すところまでAIが自分で進められるようになっています。
また、作り始めるまでの壁も低くなりました。以前は手元のパソコンに開発環境を整える段階で、エンジニア以外の多くが挫折していましたが、いまではブラウザを開いて要望を書くだけで画面が生成され、その場で動かせるサービスが増えています。
一方で、需要側の変化も見逃せません。業務のデジタル化が進むほど、集計の自動化や入力フォームの改善といった現場の細かな要望は増えていきます。ところが開発部門の人手は限られ、全社システムの案件が優先されるため、小さな依頼ほど後回しになりがちです。
そこで、順番待ちの列に並ぶ代わりに、困っている本人が自分で作ってしまう。バイブコーディングは、こうして取り残されてきた要望の受け皿として広がりました。使い手の中心も、エンジニアから業務部門の担当者へと広がりつつあります。
バイブコーディングを進める5つのステップ
最初に決めるのは、使うツールより作るものです。何を楽にしたいかが曖昧なままだと、どのツールを使っても手戻りは避けられません。題材の選び方から人に渡す前の確認まで、5つのステップを順に解説します。
手作業の多い題材を選び、1画面・1機能に絞る
1つ目は、作る題材を選び、その範囲を1つの画面と1つの機能に絞ることです。
まず、題材は、毎週いちばん手作業に時間を取られている作業から選びます。成果を削減時間で測れるので、続けるか止めるかの判断もしやすくなるでしょう。例えば、週2時間かかっていた集計が10分で済めば、効果は誰の目にも明らかです。
そのうえで、作るものの範囲を絞ります。範囲が広いほどAIは足りない部分を推測で補い、どこが意図どおりでどこが勝手に足されたのか、見分けがつかなくなるためです。例えば、営業管理ツールを作ってと頼むと、顧客一覧に商談履歴、売上グラフ、ログイン機能までが一度に出てきます。そこで、受注一覧から担当者別の件数と金額を出す画面だけ、と区切っておくのです。
やりたいことと使う場面を自然言語で伝える
2つ目は、やりたいことを、使う場面ごと言葉にして伝えることです。
これは見た目の希望から書き始めるより、誰がいつ何を入れて、何が出てくれば完了なのかを先に示すほうが、狙いに近いものが出てくるからです。例えば、毎週月曜に営業事務が受注一覧のCSVファイル（表計算ソフトで開ける形式のデータ）を貼り付けると、担当者別の件数と金額が表で出る、という伝え方をするとよいでしょう。ここに、社内の数人しか使わないのでログイン機能は不要、といった作らないものを添えておけば、AIが余計な機能を足す余地も減らせます。
なお、専門用語を使う必要はありません。受注一覧や担当者別といった、業務で普段使っている言葉のままで十分に伝わりますし、むしろ社内の呼び方のままのほうが、後から見返したときに意図を追えます。
動かして直す、を短い間隔で繰り返す
3つ目は、動かして1か所直す、という往復を小刻みに繰り返すことです。1回の指示で直してほしい点を5つも6つも並べると、どの修正で何が変わったのかを追えなくなります。
とりわけ差が出るのが、エラーが出たときの対応です。原因を自分で推測して説明するより、画面に出たエラーメッセージをそのまま貼り付けて渡します。直前にどの操作をしたかを一言添えれば十分です。的外れな推測を混ぜると、AIがその推測に引っ張られて、関係のない箇所を書き換え始めます。
また、うまく動いた時点の状態は、区切りごとに保存しておいてください。多くのツールには変更を巻き戻す機能があり、次の修正で壊れても、動いていた地点まですぐに戻れます。
継ぎはぎになったら、経緯を渡して作り直させる
4つ目は、直すたびに別の場所が壊れ始めたら、修正を重ねるのをやめて作り直しに切り替えることです。同じエラーが3往復しても消えない、ある機能を直すと以前直した箇所が元に戻る。こうした状態が、切り替えの合図です。
というのも、会話が長くなるほど、AIは序盤に決めた条件を取りこぼしやすくなります。例えば、日付は年月日の順で表示する、と最初に伝えた条件が途中から抜け落ちるといった具合です。場当たりの修正が積み重なり、中身は継ぎはぎになっていきます。
そこで、いまのツールが何をするものか、これまでに決めた条件は何かを、AIに文章でまとめさせます。そのまとめを新しい会話の最初に渡し、ゼロから作り直させてください。作り直しは遠回りに見えますが、継ぎはぎを直し続けるより早く安定します。
人に渡す前に、動作と権限を自分で確かめる
5つ目は、同僚に使ってもらう前に、動作と権限を自分の手で確かめることです。作った本人が想定どおりに操作すれば、たいていは動きます。問題が出るのは、想定していない使われ方をしたときです。
まず動作は、わざと崩した入力で試します。空欄のまま送る、全角で数字を入れる、数千行のファイルを貼り付けるといった操作で、止まり方や表示を見てください。
次に権限です。誰がその画面を開けるのか、URLを知っていれば社外の人でも見られる状態になっていないか、どのデータに接続しているかを確認します。とりわけブラウザ上で作るタイプのツールには、作ったものをワンクリックで公開できるものが多く、意図せず外部から見える状態になりがちです。
バイブコーディングツールおすすめ8選
バイブコーディングのツールは、大きく3タイプに分かれます。指示を受けて作業まで自分で進めるエージェント型、手元でコードを見ながら使うAIエディタ型、そしてブラウザで完結するアプリ生成型です。代表的なツールを8つ紹介します。
以下の一覧は2026年9月時点の内容です。
| ツール名 | タイプ | 提供元 | 向く用途 | 無料で試せるか |
|---|---|---|---|---|
| Claude Code | エージェント型 | Anthropic | 手元の複数ファイルにまたがる作業 | 無料プランでは使えない |
| OpenAI Codex | エージェント型 | OpenAI | 手元とクラウドで作業を分ける | ChatGPTの無料プランから使える |
| GitHub Copilot | エージェント型 | GitHub | 普段のエディタのまま作業を任せる | 無料のFreeプランあり |
| Cursor | AIエディタ型 | Anysphere | コードを見ながら少しずつ直す開発 | 無料のHobbyプランあり |
| Google Antigravity | AIエディタ型 | 費用をかけずにAIエディタを試す | 個人向けは無料 | |
| Lovable | アプリ生成型 | Lovable | データを保存して複数人で使う業務アプリ | 無料で始められる |
| Bolt.new | アプリ生成型 | StackBlitz | インストール不要ですぐ見せる試作 | 無料で始められる |
| Replit | アプリ生成型 | Replit | 作ったものの公開と運用 | 無料のStarterプランあり |
なお、このほかにも、v0（Vercel）、Windsurf、Clineなどのツールがあります。
Claude Code｜手元のファイルを横断して作業まで任せるエージェント型
Claude Codeは、Anthropicが提供するエージェント型のツールで、手元のフォルダにある複数のファイルを読み書きし、コマンドの実行まで任せられます。既存のファイル群を横断して整理し直す作業にも使えるのが強みです。
また、使える場所は幅広く、文字で操作するターミナルのほか、デスクトップアプリ、Visual Studio CodeやJetBrainsのエディタ拡張、Web、モバイルにも対応しています。
利用には、有料のProプランやMaxプラン、Team・Enterpriseプランのプレミアムシート、または開発者向けのConsoleアカウントが必要です。公式ページではProプランが月20ドルと示されています。手元での具体的な進め方は、Claude Codeを活用した開発の進め方をご覧ください。
OpenAI Codex｜CLIからクラウドまで環境を選ばないエージェント型
OpenAI Codexは、作業する環境を目的に合わせて選べるエージェント型のツールです。手元のパソコンで文字で操作するCLI（コマンドラインインターフェース）、エディタの拡張機能、クラウド上で動くCodex cloud、ChatGPTのアプリから使えます。
特に、クラウドで動かす場合は、パソコンを閉じていても作業が進みます。例えば、手元では画面の調整を対話しながら進め、時間のかかる修正はクラウドに任せておく、という分け方も可能です。
料金は公式の料金ページで、ChatGPTの無料プランから使え、Plusプランは月20ドル、Proプランは月100ドルからと案内されています。すでに社内でChatGPTを契約しているなら、追加の契約なしで試せるかもしれません。
GitHub Copilot｜エージェント機能で普段のエディタのまま作れる
GitHub Copilotは、使い慣れたエディタにAIを足せるGitHubのツールです。バイブコーディングで使うのは、コード補完ではなく、目標を伝えて作業ごと任せるエージェント機能のほうになります。
なお、エージェント機能は、目標を伝えるとコード一式を調べて計画を立て、ファイルの編集やツールの実行まで進めると、GitHubの公式ドキュメントで説明されています。指示を出す相手が、候補を出す補完から、手を動かす担当へ変わるわけです。
料金は無料のFreeプランと月10ドルのProプランなどで、エージェント機能の利用量はプランごとに上限があります。Visual Studio Codeなどで補完を使っているなら、環境を変えずにそのまま試せるはずです。
Cursor｜コードを見ながら対話で直せるAIエディタ型
Cursorは、コードの画面とAIとの対話欄が並んだ、AIエディタ型のツールです。パソコンにインストールして使い、手元のフォルダにあるファイルをAIに読ませながら作業でき、対話欄に指示を書けば、AIが該当する箇所を探して書き換えてくれます。
一方、ブラウザで完結するツールとの違いは、コードが常に目の前にある点です。AIが書き換えた箇所は差分として表示されるので、何が変わったかを確かめてから取り込めます。コードをまったく読まない進め方から一歩進み、少しずつ中身を理解したい人に合うのはこのためです。
料金は公式の料金ページで、無料のHobbyプランと、月20ドルのProプランなどが示されています。提供元は米Anysphere社です。
Google Antigravity｜無料で始められるGoogle製のAIエディタ型
Google Antigravityは、Googleが提供するAIエディタです。公式の料金ページでは個人向けプランが月0ドルと案内されており、個人であれば無料で使い始められます。
特徴は、複数のAIエージェントを並行して走らせ、それぞれの進み具合を1つの画面で管理できる点です。例えば、1つには画面を作らせ、もう1つには入力チェックの処理を書かせる、といった分担ができます。対応するOSは、Windows、macOS、Linuxの3つです。
そのため、費用をかけずにAIエディタ型を試したいなら、最初の候補になるでしょう。ただし無料プランには利用量の上限があり、上限を広げたい場合はGoogle AI ProやGoogle AI Ultraといった上位プランの契約が前提となります。
Lovable｜自然言語の指示だけでデータベースや認証まで作るアプリ生成型
Lovableは、画面だけでなく、データベースや認証（利用者ごとにログインさせて本人を確かめる仕組み）まで含めたWebアプリを、自然言語の指示から生成するツールです。公式ドキュメントでは、フロントエンドからバックエンド、外部サービスとの連携までを、編集できる実際のコードとして生成すると説明されています。
そのため向いているのは、データを保存して複数人で使う小さな業務アプリです。例えば、社内イベントの参加申込を受け付けて一覧で管理する、といった用途が当てはまります。無料で始められるうえ、料金は席数ではなくクレジットの消費量で決まる仕組みです。
ただし、データベースが手軽に付く分、どのデータがどこに保存されているかは、作った本人が把握しておく必要があります。
Bolt.new｜ブラウザ上で作って、その場で動かせるアプリ生成型
Bolt.newは、ブラウザを開くだけで作り始められ、生成したものをその場で動かせるツールです。提供元は、ブラウザ上で動く開発環境を手がけてきたStackBlitz社が担っています。
最大の特徴は、パソコンに何もインストールしなくてよい点です。開発環境そのものがブラウザの中で動くので、会社のパソコンにソフトを入れる申請が通りにくい環境でも試せます。無料で作り始められることは、公式サイトにも案内されているとおりです。
こうした手軽さから、会議で見せる画面の試作や社内向けページのたたき台づくりに向いており、思いついたその場で画面を出して、会議中に出た修正をすぐ反映させるといった使い方ができます。一方、無料で作れる量には限りがあるため、作り込む段階に入ったらプランを確認してください。
Replit｜作ったものを公開・運用まで持っていけるアプリ生成型
Replitの強みは、作ったものを公開して動かし続けるところまで、同じ場所で完結できることです。AIエージェントに指示してアプリを作らせ、そのまま公開用のURLを発行して使い始められます。
また、ブラウザ上でコードそのものも開けるため、バイブコーディングで作った試作を後からエンジニアに引き継ぐ場面でも中身を共有しやすく、試作から運用へ移る流れを1つのサービス内で追えます。
料金は公式のプラン説明ページで、無料のStarterプランと、月20ドルのCoreプランなどが案内されています。ただ、公開したアプリを動かし続ければ、利用量に応じた費用も別に発生する点に注意が必要です。月額の料金だけで予算を見積もらないようにしてください。
バイブコーディングで得られる4つのメリット
バイブコーディングの価値は、専門の技術や予算を持たない人でも、業務に合った道具を自分の手にできる点です。作り手の広がりや費用、直しやすさの面から4つ整理します。
プログラミングを学ばなくても、非エンジニアが自分で作れる
1つ目は、プログラミングを学ばなくても、エンジニアではない人が自分でツールを作れることです。
そもそも求められるのは、コードの書き方ではなく、何をしたいかを言葉にする力です。そのため、企画や営業、マーケティングの担当者、さらには経営者自身が、手元の困りごとを形にできます。例えば、営業担当が商談メモから次回の訪問予定を一覧にする画面を作る、といった使い方です。
しかも、作り手が業務をいちばん知る本人なので、要望を人に伝える過程で細かな条件が抜け落ちません。月末だけ処理が変わるといった現場の事情も、そのまま盛り込めます。ただし、学ばずに作れることと、中身を理解していることは別です。業務で使うなら、出てきた結果を人が確かめる前提は残ります。
外注やエンジニアの工数をかけずに、開発コストを抑えられる
2つ目は、外注や社内エンジニアの工数をかけずに済み、開発にかかるコストを抑えられることです。
というのも、小さな社内ツールでも、外部に頼むとなれば要件をまとめ、見積もりを取り、発注の手続きを踏むことになりますし、社内のエンジニアに頼む場合も、その人の工数を別の案件から割いてもらう必要が出てきます。その点、担当者が自分で作れば、こうした費用と調整の手間がかかりません。
また、ツールの多くは無料プランから試せます。まず無料の範囲で作れるかを確かめ、使い続けると決めてから有料プランに移る、という進め方も可能です。ただし、Claude Codeのように無料プランでは使えないツールもあり、無料枠には利用量の上限があります。浮くのは開発を依頼する費用であって、ツールの利用料までなくなるわけではありません。
修正をチャットで伝えるだけで、柔軟に作り直せる
3つ目は、直したい点をチャットで伝えるだけで、柔軟に作り直せることです。
外注や開発部門に頼んだツールは、一度できあがると、項目を1つ足すだけでも改めて依頼が必要になります。費用と順番待ちを考えると、多少使いにくくても我慢して使い続けることになりがちです。一方でバイブコーディングなら、ボタンの位置を変えたい、集計の区切りを月別にしたいと伝えれば、その場で反映されます。
そのため、試しながら形を決めていく進め方と相性がよく、使ってみて初めて分かる不便も気づいた時点で直せます。業務のやり方が変わったときに、道具の側を合わせて変えやすい点も見逃せません。例えば、月別だった集計を週別に直したい、といった変更もその日のうちに反映できます。
試作品をすぐ形にして、関係者と認識を合わせられる
4つ目は、試作品を形にして、動くもので関係者と認識を合わせられることです。
例えば、備品の申請フォームを文章だけで決めようとすると、承認者の欄は必須か、差し戻したときに申請者へどう見えるかといった点が抜け落ちます。会議で合意したつもりでも、完成品を見て初めて食い違いに気づくのです。特に、差し戻しや取り消しといった例外の流れは、文章の段階ではほとんど話題に上がりません。
その点、動く画面があれば、触った人がその場で違和感を口にできます。戻るボタンがない、この項目は選択式にしてほしいといった指摘も具体的になり、仕様の解釈が後からずれて作り直す、という手戻りも防げるはずです。認識合わせが実物で進む分、説明の手間も、伝言による行き違いも減らせます。
作る前に知っておきたい5つのデメリットとリスク
バイブコーディングの弱点は、作った直後ではなく、使われ始めてから表に出てくるものです。業務で使ったときに何が起きるのかを、5つ挙げます。
機能を足すうちに以前の機能が壊れ、原因を自力で追えなくなる
1つ目は、機能を足すうちに以前の機能が壊れ、その原因を自力で追えなくなることです。
そもそもAIは新しい指示に応えるとき、すでに動いている部分まで書き換えることがあります。例えば、集計画面に絞り込み機能を足したら、それまで正しく出ていた合計金額が合わなくなる、といった具合です。こうした後退はデグレと呼ばれ、見た目は変わらないまま数字だけがずれることもあります。
しかも、コードを読まずに作ってきたため、どこで何が変わったのかを確かめる手段がありません。仕様も会話の履歴に散らばり、何を前提に作ったのかは文書として残らないのが普通です。結果として、中身は作った本人にも説明できないブラックボックスになり、その人が異動すれば誰も直せないツールだけが残ります。
動いて見えても、セキュリティの穴や無駄な処理が残りやすい
2つ目は、動いているように見えても、セキュリティ上の穴や無駄な処理が残りやすいことです。
AIは、まず動かすことを優先してコードを書く傾向があります。典型的なのがAPIキーの扱いです。APIキーとは、外部のサービスを呼び出すための鍵にあたる文字列のこと。これをコードに直接書き込んだまま公開すれば、第三者に読まれてしまいます。ほかにも、入力内容の確認が甘い、誰でもデータを開ける設定のままになっている、といった穴が紛れ込みかねません。
また、同じ処理を何度も繰り返すなど、動作は正しくても無駄の多い作りになることも少なくありません。データの少ない試作の段階では気づかず、件数が増えてから急に遅くなるのです。いずれもコードを読めなければ確かめようがなく、問題を見過ごしたまま公開してしまうおそれがあります。
規模が大きく複雑になるほど、指示だけでは制御しきれなくなる
3つ目は、作るものの規模が大きく複雑になるほど、言葉の指示だけでは制御しきれなくなることです。
もちろん、1つの画面で完結する小さなツールなら、AIは全体を踏まえたうえで修正できますが、画面や機能が増え、ファイルが何十にも分かれてくると、AIが一度に把握できる範囲を超え始めます。そうなると、ある不具合を直したはずが別の箇所に不具合が生まれ、それを直すとまた別の箇所が崩れる、という堂々巡りに陥りがちです。
人がコードを読めれば原因の見当をつけて修正の範囲を指定できますが、バイブコーディングで打てる手は、指示の言い換えに限られます。そのため、会話を重ねても出口が見えません。同じ指示を言い換えては試すうちに、かけた時間だけが膨らんでいくのです。
ツールの利用料がかかり続け、仕様変更や終了に左右される
4つ目は、ツールの利用料がかかり続けるうえ、提供元の都合に左右されることです。
まず、作ったツールに手を入れ続ける限り、作成に使ったサービスの月額料金は発生します。ブラウザ上で作って公開したツールなら、動かし続けるための費用も別に必要です。さらに、AIを呼び出す機能を組み込めば使った分だけ課金される従量課金も加わるため、数人で試した時期の請求額から全社の費用を見積もると、利用者やデータ量が増えた分だけ実際の額から離れます。
加えて、料金体系や無料枠の変更、機能の廃止、サービスそのものの終了は、いずれも提供元が決めることです。とりわけブラウザ上で作って公開まで済ませたツールは、そのサービスの上でしか動かない場合があり、ほかへ移す手段がなければ、提供元の方針が変わるたびに作り直しを迫られます。
情シスが把握しない社内ツールが増え、シャドーAI化する
5つ目は、情報システム部門が把握しないところで、AIを使って作った社内ツールが増えていくことです。
シャドーAIとは、情報システム部門が承認していないAIを、従業員が業務で無断利用することを指しますが、バイブコーディングでは、この問題が一段重くなります。管理の外に出るのは使ったAIにとどまらず、そのAIが作った、業務で使われる仕組みまで増えていくためです。どのデータを扱い、誰が開けるのか。中身を知るのが作った本人だけという状態が、部署ごとに生まれます。
とはいえ、全面的に禁止しても、使う人は隠れて使うだけで、かえって実態が見えなくなってしまうのです。リスクの全体像と対策は、シャドーAIの放置リスクと禁止しない対策で解説しています。
向く業務・向かない業務の見分け方
向き不向きを分けるのは、ツールの性能よりも、扱うデータと使う人の範囲です。誤りに気づけるか、止まったときに業務が続くかという観点も欠かせません。向く業務と向かない業務を、2つに分けて解説します。
| 比較軸 | 向く業務 | 向かない業務 |
|---|---|---|
| 扱うデータ | 社内の集計値・公開済みの情報・文面の下書き | 顧客の個人情報・請求や決済の金額 |
| 利用者 | 作った本人とチームの数人 | 社外の顧客や全社の多数の社員 |
| 止まったときの影響 | 手作業に戻せば業務は続く | 取引や顧客対応が止まる |
| 誤りに気づくタイミング | 使う本人がその場で気づける | 顧客からの指摘で初めて発覚する |
| 具体例 | 会議資料の集計、定型メールの下書き、申請書の入力漏れ確認 | 顧客向けの会員サイト、請求書の発行、給与計算 |
向く｜社内向けの集計・下書き・確認ツール
バイブコーディングが向いているのは、社内で使い、出てきた結果を人が確かめてから使う道具です。
具体的には、大きく分けて3つの系統があります。部署別の残業時間やキャンペーンの申込数をまとめる集計、定型メールの文面や議事録の体裁を整える下書き、そして申請書の入力漏れや表記ゆれを洗い出す確認です。
つまり、これらに共通するのは、結果を使う本人がその場で見て判断する点です。数字が明らかにおかしければすぐ気づけますし、止まっても手作業に戻せば業務は続きます。そのため、中身がブラックボックスになりやすいという弱点を抱えていても、業務への致命傷にはなりにくいのです。最初の題材は、出力を人の確認なしにそのまま社外へ出さない業務から選んでください。
向かない｜顧客データや金銭を扱う仕組み
反対に、顧客データや金銭を扱う仕組みを、バイブコーディングで作ったまま本番で使うのは避けるべきです。誤りの影響が社外に及び、しかも後から取り消せません。
例えば、請求額の計算にわずかな誤りがあればそのまま顧客への誤請求になり、会員情報の閲覧権限を設定し損ねれば、他人の情報が見える状態が生まれます。個人情報が漏えいした場合は、法令にもとづく報告が必要になるかもしれません。しかもこうした誤りは使う本人には見えず、顧客からの指摘で初めて発覚するのが厄介な点です。
ただし、まったく使えないわけではありません。画面の流れを確かめる試作までをバイブコーディングで作り、本番はレビューを経て作り直す。この分担なら十分に活かせます。
どこまでAIに任せるかを決める4つの判断軸
向く業務だと分かったら、次はその中でどこまでAIに任せるかを決めます。同じ集計ツールでも、任せてよい範囲は作業ごとに変わるからです。判断に使う4つの軸を紹介します。
型が決まっている作業か
1つ目は、定型度です。判断のパターンが決まっていて、手順に落とせる作業かどうかを見ます。
例えば、毎月同じ形式のCSVファイルを、同じ条件で集計する作業は手順が一定です。AIへの指示も一度書けば使い回せるので、バイブコーディングで任せやすい部類に入ります。反対に、取引先ごとに細かな例外があり、担当者がその都度判断している作業は、条件を言葉にしきれません。書かれていない部分を、AIは推測で埋めてしまいます。
そのため、見分けるには、配属されたばかりの新人に、手順書だけで任せられるかを考えてみてください。手順書に書き出せる作業なら、AIにも同じように渡せます。書き出せないなら、ツールを作る前に業務そのものの整理が必要です。
間違えたときの損失が小さいか
2つ目は、失敗コストです。間違ったまま進んだときに、誰にどれだけの影響が出るかで測ります。
特に注意したいのは、同じツールでも出力の行き先によって損失が変わることです。例えば、社内の定例会議の資料に載せた集計の誤りは会議で指摘されて直せば済みますが、同じ数字を取引先への報告書に使えば、信用に関わる問題に発展します。作業としてはまったく同じ集計でも、損失の大きさは桁違いです。
つまり損失の大きさを決めるのは、作業の中身よりも、その出力がどこへ流れるかです。流れる先が社外、金額、人事評価のいずれかなら、AIに任せるのは下書きまでにとどめます。数字の確定と、それを外に出してよいかの判断は、人が受け持ってください。
出てきたものを自分で検証できるか
3つ目は、検証のしやすさです。AIが出してきた結果が正しいかを、自分で確かめる方法があるかどうかを見ます。
ただ、バイブコーディングではコードを読まないため、確かめる手段は出力の側にしかありません。集計ツールなら、元データのうち10件ほどを電卓で計算し、ツールの結果と突き合わせてみてください。地味な作業ですが、これだけでも計算条件の取り違えの多くは見つかります。
一方で、確かめ方を思いつかない作業もあります。条件が何段階にも分岐する料金計算や、法令の解釈を含む判定がその例です。こうした作業では、正しそうに見える結果と本当に正しい結果の区別がつきません。コードを読めない人が単独でAIに任せる対象からは、最初から外しておきます。
おかしくなったら元に戻せるか
4つ目は、可逆性です。つまり、間違いに気づいた後で元の状態に戻せるかどうかを見ます。
例えば、画面の表示や集計結果の出力であれば直して実行し直せば済みますが、元データを上書きしたり削除したりする処理、メールの一斉送信、外部サービスへの登録は、実行した瞬間に取り消せなくなります。特にメールの誤送信は、一度相手に届けば回収できません。
そのため、取り消せない処理を含むツールでは、試し方を変えます。元データは必ず複製してから試す、送信は自分宛ての1件で確かめる、といった手順です。そして本番の実行ボタンは、AIに任せず人が押してください。4つの軸のすべてで安全側に入る作業から任せ始めれば、取り返しのつかない事故は避けられます。
試作で終わらせないための4つの線引き
任せる範囲が決まっても、作ったものが1人の手元で止まれば、効果はその人の分だけで終わりかねません。業務の資産として残すために引いておきたい線を、4つ挙げます。
使い捨てにするか、資産として残すかを先に決める
1つ目は、作り始める前に、そのツールを使い捨てにするか、資産として残すかを決めることです。
例えば、今週の会議資料のためだけの集計や、一度きりのデータ移行なら使い捨てで構いません。仕様を残す手間はかけず、使い終わったら消すだけです。一方で、毎月使うものや自分以外も使うものは資産と位置づけ、仕様を残し、人の確認を通す前提で作ります。分かれ目は、同じ作業を来月も繰り返すかどうかです。
厄介なのは、決めないまま始めた場合です。使い捨てのつもりで作ったものが、気づけば毎月の業務に組み込まれ、中身の分からない仕組みとして居座ります。途中で資産に格上げするなら、その時点で作り直すと割り切ってください。区分は、ツール名の頭に試作と付けるなど、見て分かる形にしておきます。
仕様と決めごとをAIが読めるファイルに残す
2つ目は、資産として残すと決めたツールの仕様と決めごとを、チャットの履歴ではなくファイルとして残すことです。
まず、書く内容は、何をするツールか、入力と出力、計算の条件、作らないと決めたこと、そして変更の履歴です。形式は、どのツールでも開ける普通のテキストファイルで十分で、作ったツールと同じ場所に置いておきます。
そして、このファイルが効くのは、次に直すときです。最初にAIへ渡せば、前提を説明し直さずに続きから作業を再開できます。担当者が替わった場合も同じです。なお、Claude CodeのCLAUDE.mdのように、決まった名前のファイルを自動で読み込むツールもあります。ただし、特定ツール専用の書き方に寄せすぎず、別のツールに移っても読める形で残すと安心です。
本番に載せる前に人のレビューを1回挟む
3つ目は、本番で使い始める前に、作った本人以外の目で一度だけ確認してもらうことです。
まず、頼む相手は、社内のエンジニアか情報システム部門の担当者が理想です。ただし、コード全体の出来を見てもらう必要はありません。確認の観点は、事故につながる点に絞ります。APIキーがコードに書き込まれていないか、誰が開けるのか、どのデータに接続して何を保存するのか、取り消せない処理が含まれていないか、の4点です。
なお、修正のたびにレビューを求めると、依頼の順番待ちに逆戻りして手軽さが失われます。レビューを挟むのは、本番に載せるときと、扱うデータや利用者が変わるときに限ってください。作るのはAIでも、使ってよいかを最後に判断するのは人です。
社内に広げるなら、使ってよい範囲と責任の持ち主を先に決める
4つ目は、部署の外にまで広げる前に、使ってよい範囲と責任の持ち主を決めておくことです。
具体的に、範囲とは、扱ってよいデータの区分と、使ってよいツールのことです。例えば、社内の集計値は扱ってよいが顧客の個人情報は扱わない、といった線を引きます。責任の持ち主については、止まったときに誰へ連絡するのか、仕様を変える判断を誰がするのかを、1つのツールにつき1人決めてください。作った人が異動した場合の引き継ぎ先も、あわせて決めておくと安心です。
手始めとしては、作ったツールの名前と担当者、扱うデータを一覧に登録するだけでも十分な効果があります。これだけで情報システム部門は禁止という手段に頼らずに全体を把握でき、現場の担当者も作ることをやめずに済むのです。
まとめ
バイブコーディングは、コードをほとんど読まずに、自然言語の指示だけで動くものを作る進め方です。プログラミングを学ばなくても現場の担当者が自分で作れ、外注やエンジニアの工数をかけずに、直したい点をチャットで伝えるだけで作り替えられます。その反面、機能を足すうちに以前の部分が壊れる、セキュリティの穴を見過ごす、管理の外にツールが増えるといったリスクは、使い始めてから表れるものです。
そこで実務で使いこなす鍵になるのが、任せる工程を絞ることです。社内向けで結果を人が確かめられる作業から始め、定型度、失敗コスト、検証のしやすさ、可逆性の4つの軸で任せる範囲を決めます。資産として残すなら仕様をファイルに残し、本番の前に一度だけ人のレビューを挟んでください。ツール選びは、その後で十分です。組織として広げる段階に入れば、AI駆動開発研修（Claude Code）のように外部の手を借りる選択もあるでしょう。最初の1本は、毎週いちばん時間を取られている手作業から選ぶことをおすすめします。
