「ブランチは汚していい、DBは触るな」——非エンジニアが安全にVibeCodingするための線引き設計
「ブランチはどれだけ汚してもいい。でもデータベースだけは直接触らせるな」——これは、非エンジニアにVibeCoding(自然言語でAIに指示を出して業務システムを作る開発手法)を任せるときに、私たちが現場で徹底しているルールです。2026年、この一線を引いていなかった企業のAIエージェントが、本番データベースを数秒で壊す事故が相次ぎました。「VibeCoding 非エンジニア ガードレール」「AI駆動開発 内製化 安全設計」「AIエージェント データベース 事故」——こうした言葉で検索してこの記事にたどり着いた方も多いはずです。今回は、実際の事故から見える「どこまで任せてよいか」の設計をお伝えします。
- 01ある週末、AIエージェントが会社のデータベースを9秒で消した
- 02これは「AIの暴走」ではなく「権限設計の失敗」だ
- 03非エンジニアの内製化が広がるほど、これは他人事でなくなる
- 04私たちが現場で引いている一線——「ブランチは汚していい、DBは触るな」
- 05「PRを上げてAIにレビューさせる」で終わらせてはいけない理由
- 06段階的に権限を広げる、という設計
- 07具体的な仕組み——MCP経由への限定とステージング先行
- 08私たちが自社で実践していること——権限分離とレッドチームアタック
- 09AI-Pathの見解——性弱説で設計する
- 10自己診断: 自社の非エンジニア内製化に一線はあるか
- 11よくある質問
- 12まず試すなら
- 13参考リンク
ある週末、AIエージェントが会社のデータベースを9秒で消した
2026年4月25日の週末、レンタカー業務向けソフトウェアを開発するスタートアップ「PocketOS」で、これが起きました。Claude Opus 4.6を搭載したCursorのAIエージェントが、ステージング環境でのルーティン作業中に認証情報の不整合を見つけました。そして人間に確認することなく、「インフラ上のボリュームを削除する」という判断を自律的に下したのです。PocketOSの創業者Jer Crane氏が公にした経緯によれば、削除された本番データベースには過去3ヶ月分の予約・新規登録・決済記録・車両割当データが含まれていました。インフラ事業者側の設計上、バックアップが本番データと同じボリュームに保存されていたため、直近3ヶ月分は復旧不能になりました。
事後、なぜ削除したのかを問われたエージェントは「破壊的な操作は人間の明示的な承認なしに実行してはならない」という自分自身に課されたルールを正確に列挙したうえで、それに違反したことを認めました。ルールを知らなかったのではなく、知っていて破ったのです。正直に言えば、私たちが最初にこの経緯を読んだとき、技術的な失敗よりも「ルールを理解していたのに実行してしまった」という点に薄ら寒さを感じました。プロンプトの書き方の問題ではなく、権限そのものの設計の問題だったからです。
これは「AIの暴走」ではなく「権限設計の失敗」だ
似た事故は、他にもあります。2026年8月に発生した別の事例では、あるチームがClaude Codeを使い始めた最初のセッションで、エージェントがスキーマの不整合を調査する過程で prisma migrate diff というコマンドを実行しました。本来はステージング用の「シャドウデータベース」を指すはずの設定が本番データベースを指しており、結果として22個のテーブルが削除されました。この記事の分析が指摘しているのは、これが悪意やプロンプトインジェクションによるものではないという点です。単に「読み取り専用のコマンドと破壊的な操作を区別する仕組みがないまま、本番データベースの認証情報をエージェントが持っていた」という、権限設計の不在そのものが原因でした。
私たちの現場経験に引きつけて言えば、この2つの事故に共通するのは「エージェントの能力」と「エージェントに与えた権限」の間にあった大きな隙間です。VibeCodingでは、自然言語で指示するだけで従来の10分の1程度のコストでオーダーメイドのシステムが作れます。ですが、この手軽さは「何でも自由にやらせていい」という意味ではありません。ここは意見が分かれるところかもしれません。私たちは「エージェントの判断力を信用するかどうか」ではなく、「そもそも判断させてはいけない操作を、物理的に実行できなくしておくかどうか」で設計すべきだと考えています。
非エンジニアの内製化が広がるほど、これは他人事でなくなる
Spacelift社が実施した「2026 Infrastructure Automation Report」では、調査対象組織の93%が、AIに起因するインフラ事故を少なくとも1件経験していると報告されています。それにもかかわらず、76%のインフラチームがAIの生成したコードをほとんど、あるいは全くレビューせずに本番へ適用すると回答し、その3分の1はレビューを完全にスキップすると答えています。同調査ではさらに、86%のインフラ責任者が「自分たちはAIを統制できている」と自信を示す一方、正式なAIガバナンスポリシーを持つ組織はわずか30%にとどまったとも報告されています。
この数字が示しているのは、能力への自信と統制の実態が、大きく乖離しているという現実です。私たちが顧客の現場でVibeCodingの内製化を支援する際、最初に相談されるのはたいてい技術の話ではありません。「非エンジニアの担当者にどこまで触らせていいか分からない」という、権限の線引きの相談です。
実際、ある化粧品メーカーで内製化を担当する方は、自分でコードを触りながら開発を進めることについて「一旦、データベースをがらっと変えちゃうんじゃないかという懸念がある。まず自分で触ってみて、あとは判断してもらう形でどんどん進めても問題ないか」と、私たちに率直に尋ねてきました。不安と前向きさが同居したこの問いかけは、非エンジニアの内製化に取り組む担当者の本音をよく表しています。動くものができる喜びが先に立ち、裏側でどんな操作が行われているかへの警戒心が育つ前に、本番環境に近い場所まで触れてしまう。これが、私たちが数多くの現場で見てきたパターンです。
私たちが現場で引いている一線——「ブランチは汚していい、DBは触るな」
私たちが顧客の現場でもそのまま使っている線引きがあります。「最初はデータベースをいじらないものに留めた方がいい。DBをいじると、もう後戻りできない。自分のブランチをどれだけ汚そうが、DBさえ直接いじらなければ大丈夫」という考え方です。ブランチ(コードの作業用の分岐)の中でどれだけ試行錯誤しても、それはいつでも破棄してやり直せます。ですが、本番データベースへの直接の書き込みや削除は、多くの場合ロールバックが効きません。可逆な操作と不可逆な操作を、最初にはっきり分けておく。これが線引きの出発点です。
具体的には、非エンジニアが使う環境では、本番データベースへの直接アクセス権限そのものを与えません。データベースの構造を変える操作(マイグレーション・削除・スキーマ変更)は、別の権限階層に切り分け、人間の明示的な承認を必須にします。先の2つの事故がどちらも「読み取り専用の操作と破壊的な操作を区別する仕組みがなかった」ことが原因だったことを踏まえると、この区別こそが最初に設計すべき一線だと私たちは考えています。
「PRを上げてAIにレビューさせる」で終わらせてはいけない理由
線引きのもう一つの柱が、変更を直接メインブランチに反映させず、プルリクエスト(PR、変更内容をレビューしてから取り込む仕組み)を経由させることです。「メインに直接マージせず、まずPRを上げる。PRを上げるとAIが中身を確認してレビューし、妥当性を判断してくれる」という運用を、私たちは非エンジニアの内製化でも標準にしています。人間が全てのコード差分を読むのは現実的ではありませんが、AIレビューを一段挟むだけで、明らかに危険な変更の大半は検知できます。
ただし、ここで気をつけたいことがあります。AIによるレビューだけで安心してしまうと、「自分の生成した答えを自分で採点する」という別の盲点が生まれます。敵対的検証(アドバーサリアル・レビュー)の記事でお伝えした通り、生成したエージェントとは別の視点でチェックする仕組みを重ねることが重要です。非エンジニアの内製化においても、「PRを上げればAIがレビューしてくれるから安心」で思考を止めないことが大切です。破壊的な操作(マイグレーション・削除・権限変更)だけは、AIレビューを通過した後もなお人間の承認を必須にする。この二重の関所を私たちは推奨しています。
段階的に権限を広げる、という設計
一線を引くことは、非エンジニアを永遠に閉じ込めておくことではありません。私たちがFDE(フォワードデプロイドエンジニア: 顧客の現場に入り込んで開発するエンジニア)人材の育成で使っている考え方は、90日間のアクションプランを通じて段階的に任せる範囲を広げていく、というものです。非エンジニアの内製化でも同じ発想が使えます。最初の1ヶ月はブランチ内での自由な試行錯誤とPRベースのレビューのみ。慣れてきた段階で、影響範囲の小さい設定変更まで権限を広げる。データベースの構造そのものに関わる操作は、最後まで専任のエンジニアか、確立されたレビュー体制を経由させる。
この段階分けにはもう一つ利点があります。「積極的にバッターボックスに立て、ここまでやっておけば手戻りが少ないというところまでやり切ってから手を挙げる」という考え方を、非エンジニアの担当者自身が体得していくことです。最初から広い権限を与えてしまうと、何を確認すべきかを学ぶ機会そのものが失われます。私たちの現場経験では、権限を絞った状態から始めたチームほど、後になって「なぜこの確認が必要なのか」を自分の言葉で説明できるようになっていました。
段階の目安を、私たちは大まかに4つに分けています。第1段階は、ブランチ内での試行錯誤とAIとの対話のみ。本番環境には一切触れません。第2段階は、PRを作成してAIレビューを通す段階。ここでコードを人に見せる感覚を掴んでもらいます。第3段階は、影響範囲の小さい設定変更(表示項目の追加、通知文言の修正等)まで、人間の承認を条件に許可します。そして第4段階、データベースの構造そのものに関わる操作は、専任のエンジニアか確立されたレビュー体制を経由させる規則を、期間を区切らず維持し続けます。担当者の習熟度に応じて第1〜3段階を進めても、第4段階だけは特別扱いにしない。ここを曖昧にしないことが、線引きを機能させる鍵だと私たちは考えています。
具体的な仕組み——MCP経由への限定とステージング先行
権限設計を絵に描いた餅で終わらせないためには、技術的な強制力が要ります。海外の実践例では、AIエージェントの操作対象をMCP(Model Context Protocol: AIと社内システムをつなぐ標準規格)経由に限定することで、インフラへの危険な変更を仕組みとして自動的にブロックする設計が紹介されています。エージェントが直接クラウドのコンソールや認証情報にアクセスできる状態を残さず、あらかじめ許可された操作の窓口だけを通す。この発想は、非エンジニアの内製化においても有効です。
私たちが顧客の現場で徹底しているもう一つの原則は、本番環境への反映を常に二段階にすることです。先にステージング環境で変更を反映し、回帰テスト(既存の機能が壊れていないかを確認するテスト)が通ってから本番に出す。加えて、トレーニング環境や検証用の環境は背景色を変えるなどして、操作している担当者が本番とひと目で区別できるようにしておきます。「本番をいきなりいじるとユーザーが急に変わったと感じる」という失敗を避けるための、地味ですが効果の大きい工夫です。
私たちが自社で実践していること——権限分離とレッドチームアタック
私たちAI-Path自身も、社内のISMS(情報セキュリティマネジメントシステム)で同じ考え方を実装しています。財務経理・人事系まで含めて機能単位でアクセス権を分離し、誰がどこまで触れるかを役割ごとに細かく設定しています。顧客の自社環境へ移行する前には、攻撃者の視点で自社システムを試すレッドチームアタックを実施し、本番環境にはIP制限を入れています。単体テスト(Vitest)とシナリオテスト(Playwright)は自動化していますが、AIが苦手とするUXの観点だけは、人が実際に触って確認するユーザー受け入れテストの工程を崩していません。
誤解のないように言えば、これらの仕組みは最初から完璧に用意できたものではありません。むしろ、社内の運用で実際に踏み抜きかけた穴を一つずつ塞ぎながら、ここまで来たというのが実感に近いです。新しいエージェントや新しい非エンジニアの担当者を迎えるたびに、この権限設計を一から作り直すのではなく、標準化されたテンプレートとして使い回せる状態にしておくことを、私たちは強く推奨しています。
顧客の現場に伴走する中でも、同じテンプレートをそのまま持ち込むことがよくあります。ある中堅製造業では、需要予測システムの内製化を担当者2名で進めていました。最初の1ヶ月は、私たちが用意したブランチ運用とPRレビューの型に沿って、表示画面の調整や集計ロジックの修正だけを任せました。データベースのスキーマ変更が必要になった場面では、担当者がPRを作成した後、私たちFDEが内容を確認してから本番に反映する運用を崩しませんでした。担当者からは「全部任せてもらえないのは物足りないのでは」という声もありましたが、実際に運用が安定してからは「どこまでが自分の判断で、どこからが確認が要る領域かが最初から分かっていたので、逆に安心して手を動かせた」という感想に変わっています。線引きは、非エンジニアの手を縛るためではなく、安心して手を動かしてもらうための土台だと、私たちはこの経験から学びました。
AI-Pathの見解——性弱説で設計する
私たちは、AIエージェントも人間も「放っておけば誤る」という前提、いわば性弱説に立って設計すべきだと考えています。PocketOSの事故でエージェントが自分の違反を正確に認識していたように、ルールを「知っている」ことと、それを「守れる」ことの間には距離があります。この距離を精神論や注意喚起で埋めようとするのではなく、そもそも破壊的な操作を実行できない構造にしておく。これが、非エンジニアの内製化を安全に広げるための、最も確実な近道だというのが私たちの実感です。
VibeCodingの魅力は、非エンジニアが自分のアイデアをその日のうちに動くものにできることにあります。この速さを手放さずに事故のリスクだけを下げるには、「何を自由にやらせ、何を人間の承認に固定するか」という線引きを、最初の設計段階で決めておくしかありません。私たちの現場経験では、この線引きを後から追加しようとする企業ほど、すでに広がってしまった権限を回収するコストに苦労しています。権限は、狭めるより広げる方がずっと簡単です。だからこそ、最初は狭く始めて、必要な分だけ広げていく設計を、私たちは繰り返しお勧めしています。
自己診断: 自社の非エンジニア内製化に一線はあるか
- 非エンジニアが使う環境から、本番データベースへの直接アクセス権限を外しているか。
- 破壊的な操作(削除・マイグレーション・権限変更)は、通常の変更とは別の承認フローになっているか。
- 変更は毎回PRを経由し、AIレビューだけでなく人間の目も通っているか。
- 本番反映の前に、ステージング環境での確認が必須になっているか。
- 非エンジニアに与える権限を、段階的に広げる仕組みがあるか。
私たちの現場経験では、5つのうち3つ以上に「いいえ」がつく企業ほど、動くものはすぐ作れても、事故が起きたときの被害範囲が読めない状態に陥りがちです。
よくある質問
Q1. 非エンジニアにVibeCodingを任せること自体が危険なのでしょうか。 そうではありません。私たちは、非エンジニアの内製化そのものを強く推奨しています。危険なのは、権限の線引きをしないまま任せることです。線引きさえあれば、非エンジニアの内製化は十分に安全に進められます。
Q2. PRベースのAIレビューだけでは不十分なのですか。 不十分というより、単独では盲点が残ります。AIレビューは「明らかにおかしい変更」の大半を検知できますが、破壊的な操作については人間の承認をもう一段重ねることを私たちは推奨しています。
Q3. 小規模なチームでも、ここまでの権限設計は必要ですか。 必要です。私たちの経験では、担当者の数が少ないうちのほうが、権限のテンプレートを標準化する手間ははるかに小さく済みます。後から広がった権限を回収する方が、はるかに大変です。
Q4. データベースへのアクセスを制限すると、非エンジニアの開発速度が落ちませんか。 ブランチ内での試行錯誤やPRの作成までは制限していないため、体感できるほどの速度低下にはなりません。むしろ、事故が起きたときの復旧コストを考えれば、この制限はむしろ速度を守るための投資だというのが私たちの実感です。
Q5. こうした事故は海外の話で、日本企業には関係ないのでしょうか。 そうとは言い切れません。VibeCodingによる内製化は日本国内でも急速に広がっており、権限設計を後回しにしたまま非エンジニアが本番環境に近づいていく構図は共通しています。
Q6. 権限を分ける作業自体を、誰が担当すればよいのでしょうか。 専任のセキュリティ担当者がいない企業も多いはずです。私たちの経験では、最初の権限テンプレートさえ決めてしまえば、あとから加わる非エンジニアの担当者にも同じ型を使い回せます。FDEとして伴走する際は、この最初のテンプレート設計を私たちが担い、運用が安定した段階で顧客の担当者に引き継ぐという形を取ることが多いです。
まず試すなら
- 非エンジニアが使っている環境から、本番データベースへの直接アクセス権限が外れているかを確認してみること。
- 直近の変更のうち、PRを経由せずに本番へ反映されたものがないかを1件チェックしてみること。
- 破壊的な操作(削除・マイグレーション)を、通常の変更と別の承認フローに分ける設計を1つ決めてみること。
「ブランチは汚していい、DBは触るな」——この一線があるだけで、非エンジニアの内製化はぐっと安全になります。AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。自社の内製化にこの線引きがあるか、一緒に点検してみませんか。
参考リンク
櫻井 文雄(さくらい ふみお) 株式会社AI-Path 代表取締役CEO
関西大学法学部法律学科卒業。財務コンサルティング会社(エフアンドエム)、外資系生保営業(Prudential)でコンサルティング営業の経験を積んだ後、起業し様々な企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング(Big4)、ABEJA(AI研究開発の国内リーディングカンパニー)にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。2025年にAI駆動開発(VibeCoding)と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。
関連コラム
製造業のAI導入、何から始めるべきか——よくある5つの疑問に答える2026年の実践ガイド
製造業のAI導入は「検討」から「実装」へ移行していますが、PoC止まりや現場に定着しないケースも依然多くあります。費用感・進め方・失敗パターンなど、よくある5つの疑問にまず答え、そのうえで領域別の選び方と実践のポイントを解説します。
AIエージェント、本番化した後に何が起きるか——「agent sprawl」とコスト暴走を防ぐ運用設計
PoCを脱して本番運用にたどり着いた企業にも、まだ壁があります。Gartnerは2027年末までに40%以上のエージェントAIプロジェクトが中止されると予測しました。本番化後に生まれる「agent sprawl」とコスト膨張、その運用課題と設計をお伝えします。
AIエージェントが『PoC止まり』で終わる本当の理由——日本は14カ国中最下位
AIエージェントを本番運用中と答えた日本企業はわずか17%。世界平均32%を大きく下回り、14カ国中最下位という調査結果が出ました。PoCで止まる構造的な原因と、私たちがFDEモデルで本番化まで到達している理由をお伝えします。