バイブコーディングとは：非エンジニア開発の許可範囲と社内ルール

バイブコーディングとは、AIが書いたコードを読まずに受け入れ、動くかどうかだけを見て開発を進めるやり方である。組織が決めるべきは、これを使わせるかどうかではない。コードを読まない開発をどこまでの範囲で許し、その範囲を越える前に誰が何を確かめるかである。動いたことは安全の証拠にならず、作った本人はそれを見分けられないことが多いからだ。

本稿が調べた範囲では、「バイブコーディング とは」で検索上位に出るのは、言葉の意味の解説、使えるツールの紹介、AIが書いたコードのセキュリティリスクを一般論として並べる記事である。非エンジニアが実際に何を作り、どこで踏み外し、そのあと何をルールにしたかという記録から、組織の線引きまで降りてくるものは少ない。本稿はそこを扱う。

バイブコーディングとはどういう開発のやり方なのか

まず言葉の出どころを確かめる。広めたのは、AI研究者Andrej Karpathyの2025年2月のX投稿である。開発者のSimon Willisonが2025年3月19日のブログ記事に投稿の全文を引用しており、それによれば、彼はこれを、雰囲気（vibes）に完全に身を任せ、指数関数的な進歩を受け入れ、コードが存在することすら忘れるような新しいコーディングだと書いた。CursorのComposerに音声で話しかけ、変更はいつも「Accept All」で受け入れて差分はもう読まない、エラーが出たらそのまま貼り付ける、という手順である。そして「It’s not too bad for throwaway weekend projects」（使い捨ての週末プロジェクトなら悪くない）と添えている（2026-11-07 にWillisonの記事で確認）。

つまり元の定義には、2つの要素が入っている。AIの出したコードを人が読まないことと、失っても困らない用途に限ることである。

この区別は、言葉が広まるにつれて薄れた。Willisonは同じ記事で、AIの助けを借りてコードを書くことすべてがバイブコーディングなのではなく、AIが書いたコードをレビューせずにソフトウェアを作ることを指すのだと書き、適しているのは失敗しても影響の小さいプロジェクトだとしている。辞書のCollinsは2025年11月6日、「vibe coding」を2025年の今年の言葉に選び、自然言語で指示したAIにコードを書かせることと定義した（2026-11-07 に同社の公式ブログで確認）。辞書の定義は「AIに書かせる」まで広がっていて、「読まない」という要素は落ちている。

組織にとってこの違いは小さくない。「AIにコードを書かせること」をバイブコーディングと呼ぶなら、開発組織の大半はすでにやっていて、社内ルールで扱う対象にならない。ルールで扱うべきなのは、誰もコードを読まないまま、それが他人の使うものになる場面である。エンジニアがAIに書かせたコードを読んでから出すなら、問題はレビュー体制の設計になる。AIの書いたコードを読む側がどこで詰まるかは、AI生成コードのレビューで、自動チェックに渡していない情報を誰が供給するかで扱った。本稿が扱うのは、読む人がいない側である。

非エンジニアのバイブコーディングでは何が起きたのか

具体的な記録から入る。メディア企業EveryのライターKatie Parrottは、自分を「駆け出しのバイブコーダー」と呼んでいる。彼女は好きな文章の断片を集め、その特徴からスタイルガイドを作るアプリTastemakerを作り、ドメインを取って公開した。少数だが実際に使う人も出た。

彼女はそこにもう1つ機能を足した。利用者がClaude CodeやCodexなどのエージェントから、自分のスタイルガイドを直接取り出せるようにするMCPコネクタ（AIエージェントを外部のサービスにつなぐ仕組み）である。経験のあるソフトウェアエンジニアの友人に危険がないかを尋ね、認証つきのAPIはエージェントが使うからといって危険になるわけではない、という説明を受けた。友人は続けて、利用者のアクセスを管理するバックエンドのエージェントは別の話で、誰を入れるかを決める以上、判断を誤ったり操作されたりすれば開けてはいけない扉を開けうると警告している。彼女自身、良い助言だったが、自分が作ったもののセキュリティレビューではなかったと書く。彼女はその説明をClaudeに渡し、安全な版で作るよう頼んだ。Claudeはコネクタを作り、チェックを走らせ、完成だと説明した。彼女は試し、動いたので、デプロイを指示した。

後日、彼女はより新しいモデルのGPT-5.6 Solにアプリを点検させた。見つかったのは、本番のコネクタに、公開されるべきでない登録用の経路が開いていたことである。利用者のデータに誰かがアクセスした形跡はなかったが、Solは調査のあいだコネクタを止めて有効なセッションを無効にする許可を求め、彼女はすぐに承認した（非エンジニアの AI 開発をどこまで許可すべきか — vibe coding が本番に持ち込んだ脆弱性の教訓）。

彼女はここに至った理由として想像力と無知、慢心、そしてAIを挙げているが、自分の慢心だけの話ではないとも書く。Claudeの推論を目で追えて、言葉の意味が通じたので、作業を理解していると思い込んだ。心理学でいう「説明の深さの錯覚」である。そして彼女は、意図どおりにつながるかは試したが、つないではいけない人がつなげてしまうかは試していなかった、それを問うべきだと知らなかった、と書く。動いたことが、確かめていないことの証拠として扱われた。 本稿はここに、バイブコーディングを組織で扱うときの中心の問題を見る。作った本人が素人であることより、本人には確認の抜けが見えないことのほうが問題なのである。

これは一部の人の話でもない。Parrottが引くOpenAIの研究者の分析では、業務に関するChatGPTのメッセージ80万件超のうち16.8%が、従来は別の職種が担ってきた仕事をAIでこなす「タスクの越境」だった。

同じ会社には、うまく通った記録もある。上級編集者のJack Chengは有料記事を非会員に共有できるギフトリンク機能をCodexで実装したが、ウェブのエンジニアリードが設計を見て記事プレビューの扱いを確かめるよう指摘し、ドラフトのプルリクエストを自分のCodexにレビューさせた。公開までにはステージングへの配備と社内での試用が入っている（非エンジニアはAIでどこまで機能開発できるか——編集者が空き時間でギフトリンク機能をリリースした実例）。コードを書かない運用責任者と成長責任者の2人が、互いのCodexに引き継ぎ資料を渡し合って、週次の指標を見る社内向けのサイトを4〜5日で立ち上げた例もある（複数AIモデルの使い分けをどう設計するか——「Fable=CEO」の組織図とエージェント出力が人間に読めなくなる問題）。2つの違いは本人の技能より、作ったものが誰に届くかと、届く前にどんな確認が入ったかにある。顧客に出る機能を非エンジニアが通したときにエンジニアに何が残ったかは、非エンジニアがAI開発で機能を出した社内で、エンジニアに残った2つの行為で詳しく読んだ。

非エンジニアのバイブコーディングを、社内でどこまで許すのか

線は「使ってよいか」では引けない。Parrottの件も、Tastemakerを作ったこと自体は問題ではなかった。問題が出たのは、それを他人がつなぐ本番に出し、権限に関わる機能を足したときである。

彼女が事故のあとにAGENTS.md（Codexが動く前に最初に読むファイル）へ書き足した指示は、線引きの材料としてそのまま使える。要点は、社外に出す・共有する・本番に出す前に、確かめたことと確かめていないことを分け、想定どおりに動く経路では試されない失敗を探させることにある。そのうえで、次のどれかに当たるときは人のレビューを必須にしている。

1. 他人に影響する
2. 機微なデータや権限を扱う
3. お金を動かす
4. 壊れたときに戻しにくい、または気づきにくい
5. 法務・医療・金融・セキュリティに触れる

指示の最後の1文はこうなっている。

“Never certify work as safe or ready to ship merely because AI built it, tested it, or agrees with itself.”

（AIが作った、AIが試した、AIが自分の出力に同意した、というだけで、安全だとも出荷してよいとも認めてはならない。出典: Every (Working Overtime) by Katie Parrott、2026-08-11）

ここから本稿は、社内の範囲を3つに分けることを勧める。第一は本人の手元で、作った本人しか使わず、本人のデータしか触らないもの。ここはバイブコーディングの元の定義どおり、読まずに作ってよい。第二は社内の共有で、同僚が使うが社外には出ず、上の5条件に当たらないもの。週次の指標を見る社内サイトは、本稿の分類ではここに入りうる（元記事は扱うデータの機微さには触れていない）。ここでは誰がそれを保守するかを決めてから共有する。第三は5条件のどれかに当たるもので、顧客に届く、認証や権限に触る、課金に関わる。ここはコードを読む人の確認なしに出さない。

エンジニアの側にも同じ考え方がある。EveryでSlackのエージェントの開発に携わるエンジニアLoren Stewartは、エージェントが42ファイルに触れて約3,000行を足した機能を見直したとき、エージェントが途中で決めた設計判断の意味を自分で説明できなかったと書く。そのうえで彼は、任せ方を「完全な自律」「密な監督」「手作業」の3つに分けた。何度も書いてきた定型の作業は任せきり、理解しておきたい複雑な系は重要な判断の前に確認点を置く、という分け方である（AIコーディングエージェントにどこまで任せるか——自律・監督・手動を分ける3モード設計）。作業の性質で任せ方を分ける点は非エンジニアの3つの範囲と似ているが、Stewartはコードを読んだうえで説明できなかったのであり、分ける基準も自分が理解し学びたいかどうかで、成果物が誰に届くかではない。範囲の線は届く先で引き、任せ方の線は本人の学びで引く、という2本の線が別々にあると本稿は読む。

第三の範囲を通すとき、誰に出す権限を持たせるかは、プロダクト組織の設計と切り離せない。リリース権限をどこに付けるかはAI時代のプロダクト組織を少人数にする前に、誰にリリース権限を渡すかで扱った。

バイブコーディングの社内ルールに、最初に書くことは何か

ここまでの記録から、本稿が最初の版に入れるべきだと考えるのは次の4つである。いずれも記録された事例をもとにした本稿の整理である。

第一に、AIの確認だけを出す根拠にしないこと。 Parrottの件では、Claudeが作り、Claudeがチェックし、Claudeが完成だと言い、本人が動作を確かめた。それでも穴は残った。見つけたのは、作ったときとは別のモデルだった。彼女は次にMCPの接続を作るときは、系列の違う複数のモデルに見させたうえで、ソフトウェアエンジニアに穴を探してもらうと書いている。作ったものと同じ仕組みに安全を確認させない、という1行は、どの組織でもそのまま書ける。

第二に、境界の5条件を書き、当たるかどうかを本人に判定させること。 本人は抜けを見つけられないが、「お金を動かすか」「他人のデータを扱うか」は判定できる。判定できる問いに置き換えておくことが、説明の深さの錯覚への備えになる。

第三に、保守を引き受ける人を決めてから共有すること。 Parrottは記事の最後に、次の機能を作る前に、それを午後に作るだけでなく何か月も保守する気があるかを確かめたいと書いている。社内の共有範囲で動いているものは、作った人の異動や退職で持ち主を失う。共有する前に持ち主の名前を書く欄を置く。

第四に、第三の範囲で止める人と見る人を名指しすること。 ギフトリンクの件では、エンジニアリードが記事プレビューの扱いを確かめるよう指摘し、プルリクエストのレビューを自分のCodexに回した。元記事が書くエンジニアの関与はこの2つだけで、これが関門として置かれていたかは書かれていない。それでも本稿は、止める人と見る人を先に決めておけば、同じ関与を偶然ではなく意図して置けると考える。

レビューの手当てを自動チェックとどう分けるかはAI生成コードのレビューで、自動チェックに渡していない情報を誰が供給するかに、非エンジニアの変更に対してエンジニアが持つべき役割は非エンジニアがAI開発で機能を出した社内で、エンジニアに残った2つの行為に続く。

まとめ: 使わせるかどうかではなく、読まない開発の届く先を決める

バイブコーディングとは、AIが書いたコードを読まずに受け入れ、動くかどうかで開発を進めるやり方であり、言葉を広めた本人は使い捨ての週末プロジェクト向けだと書いていた。組織で問題になるのは、そのやり方で作ったものが、読まれないまま他人に届く場面である。Everyのライターが本番に残した認証の穴は、本人が意図どおりの動作を確かめ、AIが完成だと言ったあとで、別のモデルが見つけた。だから社内ルールで決めるのは可否ではなく、届く先の3つの範囲と、人のレビューなしに越えてはいけない5つの条件、そして越える変更を見る人の名前である。今期のうちに、自分の組織でいま社内に共有されている自作ツールを洗い出し、5条件に当たるものに持ち主とレビュアの名前が付いているかを確かめるところから始められる。