壊さないバイブコーディング入門 ― 非エンジニアがAIに開発を任せて事故らないための「4つの安全網」

最初に立場を明かしておきます。私はタイパ（タイムパフォーマンス）至上主義の人間です。
「品質のために、丁寧に時間をかけましょう」という綺麗な話には、正直あまり心が動きません。

そんな人間が、この記事では最後まで「テストを書け」と言い続けます。
道徳的に正しいからではありません。その方が明らかに速いからです。

AIに任せれば、作るのは一瞬です。ところが壊したときは、取り戻すのに数日かかります。
つまりタイパを最大化したいなら、丁寧にやるのではなく、壊れたら即バレる仕組みだけ先に置いて、あとは思い切りやるのが正解になります。

その具体的な型を、社内ツールを堅牢に、安全に作りたいすべての人に向けてまとめました。

この記事の対象読者

社内ツールは「まず自分たちが使うだけ」なので、レビューもテストも真っ先に省略されがちな領域です。
そして省略のツケは、業務が止まる・数字が狂う・見えてはいけない情報が見えるという形で、後からまとめて返ってきます。

ここで書く型は顧客向けプロダクトにもそのまま使えますが、最初の一歩を踏むなら社内ツールが一番安全です。
壊しても影響範囲が社内に収まるうちに、安全網の張り方を体に入れてしまうのがおすすめです。

具体的には、次のような方を想定しています。

エンジニアではないが、AIを使って自分で社内ツールやプロダクトを触り始めた人（PdM / Biz / デザイナー / CS / 経営企画）
「AIに任せたらコードは書けたけど、これ本当にリリースして大丈夫？」と不安になっている人
非エンジニアのメンバーにバイブコーディングを解禁したいが、壊されるのが怖い エンジニア
Claude Code を使い始めたが、どこまでAIに任せていいか決めきれていない人

この記事のゴール

「怖いから触らない」でも「怖いもの知らずで触る」でもなく、
壊れても即座に気づける状態を作ってから、思い切り攻める という進め方を身につけることです。

読み方ガイド ― 5分 / 10分 / 全部

タイパ至上主義者として、全部読まなくても価値が出る読み方を先に置いておきます。

コース	読む章	目安
⚡ 結論だけ知りたい	3 → 4 → まとめ	約5分
🔧 明日から手を動かしたい	3 → 4 → 5 → 9 → まとめ	約10分
📖 全部読む	1 〜 15 ＋まとめ	約35分

10分コースに上乗せされるのは、主に次の5つです。時間がある人だけどうぞ。

2節（約3分）― 何がどう怖いのかの解像度。バイブコーディングとソフトウェアエンジニアリングの差を一枚の絵で
6・7・8節（約5分）― 残り3つの網の具体的な運用。Slack ⇄ チケットの双方向起票もここ
10節（約3分）― Claude Codeでの仕様駆動開発。Skillsでの仕様確定と、コミット履歴からの「文化の点検」
11・12節（約5分）― 正直な話。テストの限界と、AIに任せない方がいいこと
14・15節（約4分）― この記事のオチ。AIが奪わない「起点力」と、全員がオーナーとして動く組織の姿

※ 目安時間は日本語500字/分、図とコードは1つ30秒で換算しています。

1. バイブコーディングとは何か

バイブコーディング（Vibe Coding） とは、ロジックを1行ずつ自分で組み立てるのではなく、
「こういうものが欲しい」という感覚（vibe）とノリをAIに投げて、勢いよくコードを生み出していくスタイルのことです。

（従来）  仕様を理解する → 設計する → 1行ずつ書く → 動かす
（VIBE）  やりたいことを喋る → AIが書く → 動かす → 気に入らなければまた喋る

重要なのは、これが**「プログラミングができない人でもプロダクトを改修できる」時代**を本当に到来させた、という点です。
実際、私の職場でも非エンジニアのメンバーがAIと一緒にIssueを起票し、DB設計まで踏み込んだバックエンドの改修を出せるようになっています。

なお本記事は、私が実際に Claude Code で運用している型をそのまま前提に書いています。
考え方自体は他のAIコーディングツールでも成立しますが、具体例（Skills・チケット連携・履歴の点検）はすべてClaude Codeのものです。

そして、だからこそ次の問題が起きます。

2. 何が怖いのか ― バイブコーディング3大事故

バイブコーディングとソフトウェアエンジニアリングの違いを、この絵以上にうまく表現したものを私は知りません。

出典：Instagram @blueviper.ai「Vibe Coding vs. Software Engineering」（2026年7月16日投稿）

地上の建物は、どちらも同じくらい立派に見えます。
違うのは地下です。片方は鉄筋コンクリートの基礎に支えられ、もう片方は瓦礫と廃材の上に建っています。

そして残酷なのは、地上しか見ていない人には、この差が一切見えないことです。
非エンジニアがバイブコーディングで作ったものは、たいてい「ちゃんと動く」し「立派に見える」。
だから本人も周囲も、地下がどうなっているかを確認しないままリリースしてしまいます。

原典の投稿は、地下で何が起きているかをこう表現しています（要約）。

誰もそのシステムがなぜ動くのか分からなくなる

たった1つのプロンプト修正が、無関係な3つの機能を壊す

エッジケースがテストより速く増えていく

最初に作った本人以外、誰も安全に触れなくなる

「とりあえずの修正」のたびに、次の変更コストが上がっていく

問題は「バイブコーディングでは動くものが作れない」ことではありません。むしろ、たいてい動くのです。
問題は、地下に何を積み上げてしまったかが、後になるまで分からないことです。

そして、この地下の事故は書いている最中には起きません。
たいてい「動いたので満足した数日後」に、まったく別の場所からやってきます。

① デグレーション（意図しない巻き添え）

「ここを少し直して」と頼んだだけなのに、関係ないはずの別の場所が壊れる現象です。
AIは頼まれた箇所を直すために、周辺のコードを"良かれと思って"書き換えることがあります。
そして非エンジニアは、壊れた側の機能を触っていないので、壊れたことに気づけません。

② ハルシネーション（嘘の実装）

AIは平気で、存在しないライブラリの関数を呼んだり、空文字やnullを入れた瞬間にエラーになるコードを出力します。
コードは「もっともらしく」見えるので、レビューで見た目だけ追っていると通ってしまいます。

③ ブラックボックス化（未来の自分が読めない）

自分で1行ずつロジックを組んでいないため、数ヶ月後に見返したとき
「なぜこれで動いているのか分からない」 状態になりがちです。
これは障害ではありませんが、そのコードが二度と改修できなくなるという点で最も長期的な損失です。

3. 結論：4つの安全網を張れば、思い切りやっていい

対策は「慎重にやる」ではありません。慎重さは持続しないし、バイブ（勢い）を殺します。
必要なのは、機械が代わりに見張ってくれる仕組みです。

「網」なので、直列に並べるのではなく入れ子で重ねるイメージを持ってください。
内側をすり抜けたミスは、外側のどこかで必ず引っかかります。

この4つのうち、非エンジニアにとって費用対効果が圧倒的に高いのは第2の網＝ユニットテストです。
そこから詳しく見ていきます。

4. 第2の網（本命）：ユニットテストは「命綱」である

ユニットテストとは、「この入力を渡したら、この結果になるはず」という確認をコードとして書いておくものです。
一度書けば、コマンド1つで何百回でも自動で検証されます。

// 例：消費税を計算する関数のユニットテスト
import { describe, it, expect } from 'vitest';
import { calcTaxIncluded } from './price';

describe('calcTaxIncluded', () => {
  it('通常の税率10%を正しく加算する', () => {
    expect(calcTaxIncluded(1000, 0.1)).toBe(1100);
  });

  it('端数は切り捨てる', () => {
    expect(calcTaxIncluded(999, 0.1)).toBe(1098);
  });

  // ↓ ここが非エンジニアにとって一番大事。異常系を必ず入れる
  it('金額が0でもエラーにならない', () => {
    expect(calcTaxIncluded(0, 0.1)).toBe(0);
  });

  it('金額がマイナスなら例外を投げる', () => {
    expect(() => calcTaxIncluded(-1, 0.1)).toThrow();
  });
});

テストがある世界と、ない世界の差

「壊れていることに気づくまでの時間」が決定的に違います。

テストが解決する4つのこと

事故	テストがどう効くか
① デグレ	AIに直させた直後にテストを回すだけで、壊れた箇所が瞬時に分かる
② ハルシネーション	実際に実行するので、嘘の実装はその場で落ちる
③ ブラックボックス化	テストが「動く仕様書」になる。数ヶ月後の自分がテストを読めば意図が分かる
心理的ブレーキ	「最悪壊れてもテストが教えてくれる」という安心感が、大胆なリファクタリングを可能にする

④ が最も見落とされがちですが、実は本質です。
「壊れるのが怖い」と思い始めた瞬間に、バイブ（勢い）は落ちます。
テストという安全網（セーフティネット）は、慎重にさせる道具ではなく、大胆になるための道具です。

5. タイパ至上主義でいい ―「テストが面倒」はAI丸投げで消える

冒頭で書いたとおり、私はタイパ至上主義の人間です。
そんな人間がテストを勧める理由を、綺麗な言葉ではなく時間の数字で並べてみます。

	かかる時間
AIにテストを書かせる	1〜2分
テスト無しで壊し、数日後に原因を探す	半日〜数日
テスト無しで壊し、顧客に謝りに行く	数日〜（信用は戻らない）

つまり、タイパが悪いのは「テストを書くこと」ではなく 「テストを書かないこと」 です。

とはいえ、ここで多くの人が止まります。「そもそもテスト、書けません」と。
書かなくていいです。テストもAIに書かせてください。 テストコードは、AIが最も得意とする領域のひとつです。
以下が、タイパ至上主義者が使っているバイブス（勢い）を落とさない丸投げの型です。

使えるプロンプト①：テストを全パターン作らせる

このコードのユニットテストを、正常系・境界値・異常系（空文字、null、0、マイナス、
巨大な値）を含めて全パターン書いてください。
テストフレームワークは既存のテストファイルと同じものを使い、
テスト名は日本語で「何を保証しているか」が分かるように書いてください。

使えるプロンプト②：落ちたらログを丸ごと投げる

テストが落ちました。以下がログです。
実装とテストのどちらが間違っているかを判断し、理由を説明してから修正してください。

（ここにエラーログを全文コピペ）

ログは要約せず、全文そのまま貼るのがコツです。人間が親切に要約すると、AIが原因を特定する手がかりが消えます。

使えるプロンプト③：既存コードを壊していないか確認させる

今回の変更で影響を受ける可能性のある箇所を洗い出してください。
そのうえで、影響範囲に既存テストが無いものがあれば、先にテストを追加してください。

優先順位：全部にテストを書かなくていい

いきなり全体にテストを書こうとすると挫折します。次の順で、触るところだけ書けば十分です。

判断軸は2つだけです。「壊れたときの影響」×「これから触る頻度」 でマッピングしてください。

右上（赤）から順に潰すだけです。左下は放置してかまいません。
特に「これから自分が触る所」は、触る前にテストを書くだけで最強のコスパになります。
自分の変更が既存の挙動を壊した瞬間に、テストが赤くなって教えてくれるからです。

私自身、既存コードへのテスト追加は優先度を低めにして順次進めています。
大事なのは「全部やる」ことではなく、これから新規実装する部分には必ずテストを書くという習慣です。

6. 第1の網：変更を小さく保つ

AIは、大きく曖昧な依頼をすると大きく曖昧に壊します。
非エンジニアが守るべき最重要ルールは、「1回のブランチで1つの目的だけ」 です。

やること

Issueを立てる（何を・なぜ・完了条件は何か。これもAIに書かせてよい）
ブランチを切る（main / develop で直接作業しない。ここが最大の防波堤）
その中で好きなだけバイブコーディングする
テストを通す
PR（プルリクエスト）を出す

「ついでにあれも直しちゃおう」を我慢するだけで、事故率は劇的に下がります。
ついで作業は、別のブランチで別のPRに。

Claude Code活用：起票を人力でやらない

1番目の「Issueを立てる」は正しいのですが、正しいがゆえに面倒で、真っ先に省略されます。
そしてIssueが無いと目的が曖昧になり、変更が勝手に膨らみます。ここは丸ごとAIに寄せてしまうのが正解です。

Claude Code にSlackとGitHub / Backlogを繋いでおくと（MCP連携）、こうなります。

Slackで相談していたスレッドのURLを渡して「これをIssueにして」 → 背景・目的・完了条件まで整形されたチケットが立つ
逆にチケットのURLを渡して「Slackで共有できる文面にして」 → 報告文が返ってくる
チャットから直接「この不具合をBacklogに登録して」も可能

つまり、議論した場所とチケットの間を双方向に流せるようになります。
転記のために画面を行き来する時間がゼロになるので、「1目的1ブランチ」が本当に守られるようになりました。

守れないルールは、意志の問題ではなく手間の問題です。 手間はAIに寄せてください。

7. 第3の網：AIレビュー → 人レビューの二段構え

レビューを人間だけに頼ると、レビュワーの時間を奪い、心理的にも依頼しづらくなります。
先にAIに叩かせて、人には「AIが拾えないもの」だけ見てもらうのが現実的です。

セルフレビュー用プロンプト

このPRの差分を、厳しめのシニアエンジニアとして批判的にレビューしてください。
観点：
- 既存機能を壊す可能性（デグレのリスク）
- null / 空 / 境界値での例外
- 命名と責務の置き場所が適切か
- テストが無い分岐が残っていないか
指摘は「重大 / 中 / 軽微」に分類して、修正案も添えてください。

人に見てもらうべきは「AIが知り得ないこと」

AIはコードの整合性は見られますが、「そもそもこの設計でいいのか」 は判断できません。
たとえば「このテーブルは組織IDを外部キーに持つべきか、それとも独立させるべきか」といった、
将来の運用やライフサイクルを踏まえた判断は、必ず人間に相談してください。
非エンジニアにとって、ここが最も遠慮せず質問すべき領域です。

8. 第4の網：いつでも戻せる状態を保つ

最後の保険です。「戻せる」と分かっていれば、恐怖はほぼ消えます。

やること	理由
こまめにコミットする	「AIが暴走する前の状態」に一瞬で戻れる
作業前に必ず最新化する（`git pull`）	古い状態から作業すると、マージ時に事故る
`main` / `develop` で直接作業しない	ここを壊すと、全員が止まる
本番DBに直接触らせない	AIが生成したSQLをそのまま本番に流すのは論外
環境変数・秘密情報をコードに書かない	AIは平気でAPIキーをコードに直書きしてくる

特に注意：認証情報のハードコード

AIは「動くコード」を優先するため、APIキーやパスワードをソースコードに直接書き込むことがよくあります。
これは一度コミットしてしまうと履歴から消すのが非常に面倒で、セキュリティ事故そのものです。

（AIへの指示に必ず入れる一文）
APIキー・パスワード・トークンなどの認証情報は、コードに直接書かず、
必ず環境変数（.env や設定サービス）から読み込む実装にしてください。

9. 実践：これが全体の流れです

ここまでの4つの網を1つのフローにまとめます。非エンジニアはこの通りに回すだけでいいです。

この中で勢いよくやっていいのは「AI実装」だけです。
「テスト作成 / テスト実行」が安全網、「セルフAIレビュー / 人レビュー」が関門にあたります。

注目してほしいのは、「AI実装」に戻る矢印が3本あることです。
バイブコーディングは一発で当てるものではなく、この短いループを高速に何周も回すものです。
テストがあれば、この1周が数分で回ります。テストがなければ、1周に数日かかり、しかも本番で回ることになります。

10. Claude Codeでどう回しているか ―「仕様駆動開発」という前提

ここまでの4つの網を、私は Claude Code で回しています。
前提として私のスタイルは 仕様駆動開発（Spec-Driven Development） です。
バイブコーディングと矛盾するように聞こえますが、むしろ逆で、両立させるための工夫です。

勢いよく書くのは「実装」だけ。「仕様」は先に文章で固める。

仕様が曖昧なままバイブすると、AIは曖昧な部分を勝手に埋めます。
そして埋めた部分が、そのまま地下の瓦礫になります。

セクション9のループに対して、この図で足しているのは両端の2つだけです。
入口に「仕様の確定」、出口に「履歴の点検」。この2つをClaude Codeに任せています。

① Skills で「仕様を確定させる手順」を固定する

Claude Code の Skills（繰り返す作業の手順をMarkdownで定義して、必要なときに呼び出せる仕組み）に、
仕様を確定させるまでの手順を書いて置いています。埋めるべき項目は毎回同じです。

何を作るのか / 作らないのか（スコープ外の明示）
入力と出力、そして異常系の振る舞い（空だったら？ 0だったら？権限が無かったら？）
完了条件（これが満たされたら終わり）
影響を受ける既存機能

毎回この手順が走るので、人によって・日によって仕様の粒度がブレなくなります。
非エンジニアが書いた依頼でも、抜けている項目はAI側から聞き返してくれます。

そして最大の効果はここです。確定した仕様は、そのままテストの元ネタになります。
「異常系の振る舞い」を仕様として書いておけば、テスト生成は「仕様を渡すだけ」になります。
セクション11で書く落とし穴（実装からテストを書かせると事故る）を、仕組みとして回避できるわけです。

② コミット履歴を読ませて「文化が崩れていないか」を点検する

個人的に一番効いている使い方がこれです。
バイブコーディングの本当の怖さは1回の事故ではなく、コードベースの文化がじわじわ崩れることにあります。

命名の規則が場所によって違う
同じ処理が、別の書き方で3箇所に増えている
テストの無い新規ファイルが積もっている
「とりあえずの修正」が定着してしまっている

これは1つのPRを見ても分かりません。履歴を通してしか見えない種類の劣化です。
なので定期的にこう投げています。

直近50コミットの差分を読んで、このリポジトリの設計方針・命名規則・
テストの書き方から逸脱している変更を挙げてください。
「規約違反です」ではなく「この積み方を続けると将来こう困る」という観点でお願いします。

人間は、ここまで履歴を読み返せません。
「地下の点検」を定期実行できることが、AIを使う側の一番わかりやすい利点だと思っています。

11. 正直な話①：テストは万能ではない

安全網を過信すると、それ自体が新しい事故になります。テストが守ってくれない領域を知っておいてください。

テストには層があり、ユニットテストは一番下の層にすぎません。
下は数を増やしやすく速い（＝AIに丸投げできる）、上に行くほど数は減り遅くなります。

層	何を守るか	AIに任せられるか
① ユニットテスト（最下層）	部品単位のロジックが壊れていないか	ほぼ全部任せられる
② 結合テスト	部品を繋いだときに動くか（DB・API）	任せられるが環境準備は人
③ E2E・手動確認（最上層）	そもそも要求どおりのものか	人が見るしかない

ユニットテストが全部緑でも、「繋いだら壊れている」「そもそも作るものを間違えている」は検出できません。

落とし穴①：AIに書かせたテストは「間違った実装」を正解として固定する

これが最も見落とされる罠です。
実装を書いた後にAIへ「この実装のテストを書いて」と頼むと、AIは実装の挙動をそのまま正解として写し取ります。
実装にバグがあれば、バグを保証するテストが生まれます。テストは緑になり、あなたは安心し、バグは残ります。

対策はシンプルです。

（✕）このコードのテストを書いて
（○）この「仕様」を満たすテストを先に書いて。仕様は以下です：
     ・金額がマイナスなら例外を投げる
     ・端数は切り捨てる
     ・0円は許容する

「実装から」ではなく「仕様から」テストを書かせる。
可能ならテストを先に書き、AIにはそのテストを通す実装を書かせるのが最も安全です。
（先にテストを書く流れは、セクション9のフロー図の通りです）

落とし穴②：カバレッジ100%でも壊れる

テストの網羅率（カバレッジ）が高くても、そもそも想定していないケースは守れません。
「非エンジニアが最後に必ず自分の目で画面を触る」ことは、どんなテストがあっても省略しないでください。

落とし穴③：テストが通ることと、要求を満たすことは別

テストは「作ったものが壊れていないか」を保証するだけで、
「作るべきものだったか」は一切保証しません。
ここを担保するのは、依頼者との会話とIssueの完了条件です。

12. 正直な話②：AIに任せない方がいいこと

活用事例として書いていますが、「全部AIに投げた方が速い」は嘘です。
実際に使い込んでみると、任せた方がいい領域と、自分でやった方がいい領域に、はっきり境界があります。

① 環境構築（ハーネス）は、今でも一番難しい

AIが自走するには、AIが自分で結果を確認できる環境が必要です。
テストがコマンド1つで走る、失敗ログがそのまま読める、PRを出すと自動でテストが回る ―
このAIの足場を ハーネス と呼びますが、体感でここの構築が一番難しいです。
プロンプトの工夫より、この地味な環境整備の方が圧倒的に大変で、しかも効果が大きい。

そして重要なのは、これが非エンジニアの仕事ではないということです。

非エンジニアが安心してバイブできるかどうかは、エンジニアがどれだけハーネスを整えたかで決まります。

「テストがコマンド1つで回る状態」を先に用意すること。
それが、非エンジニアにバイブコーディングを解禁するための前提条件です。

② Git操作は、自分でやった方が速くて正確

コミット・ブランチ・マージは、自分の手でやった方が速いし確実でした。
AIに任せると意図しないファイルを巻き込んだり、余計なコミットが増えたりします。
第4の網（いつでも戻せる状態）は最後の保険なので、保険の操作くらいは自分の手で握っておく方が安心です。

③ 「自分でやった方が速い」瞬間は本当にある。だから待たない

一番の学びはこれでした。
指示を書いて、出力を待って、直させる時間より、自分で書いた方が速い作業は普通にあります。

ただし結論は「だから使わない」ではありません。**「投げている間に待たない」**です。

上下2段が同じ時間帯で並んでいるのがポイントです。
AIの価値は「1つの作業が速くなること」より、**「自分の手が空く時間ができること」**にあります。
1つ投げたら、その待ち時間は別の作業に使う。ここまで含めて段取りを組むと、体感の速度が変わります。

13. アンチパターン集（これだけは避ける）

❌ やりがちなこと	なぜ危険か	✅ 代わりにやること
「全体をいい感じに直して」と丸投げ	影響範囲が無限になり、レビューも不可能になる	変更対象のファイル・目的を明示する
テストが落ちたのでテストを消す	安全網を自分で切る行為。最悪の選択	落ちた理由をAIに説明させる
動いたのでそのままマージ	「動いた」は「壊していない」ではない	テスト全体を回してからPR
AIの説明を読まずに承認	説明の中に「〜は未対応です」と書かれていることが多い	出力の最後まで読む
エラーログを要約してAIに渡す	原因特定の手がかりが消える	全文コピペ
1つのPRに複数の目的を詰める	問題が起きたとき、どれが原因か切り分けられない	目的ごとにPRを分ける

14. 最後に：AIが奪わないのは「起点力」

安全網の話をここまでしてきましたが、そもそも何のために網を張るのかを最後に書いておきます。

DeNAの南場智子さんが、AI時代に人間に残る能力についてこう話しています。

仕事がどんどん濃くなりますから。薄い仕事は全部コンピュータ任せとなるので、私はこういった意志、「起点力」というものがすごく重要になると思います。

— 南場智子（DeNA南場智子が語る「AI時代の会社経営と成長戦略」全文書き起こし / フルスイング by DeNA）

「物事を起こす意思を持つこと、夢中になる力、欲求を持つこと」が重要になる、という文脈での発言です。

バイブコーディングは、まさにこの「薄い仕事」をAIに移す行為です。
そして移した結果、人間の手元に何が残るのかを整理すると、こうなります。

やること	誰がやるか
何を作るか / なぜ作るか / どうなったら成功かを決める	人間（＝起点力）
仕様を項目に整える	AI（ただし埋める中身は人間）
コードを1行ずつ書く	AI
テストを書く / 落ちた原因を調べる	AI
そもそも作るべきものだったかを判断する	人間

人間に残るのは、いちばん最初（何を作るか）といちばん最後（作るべきだったか）だけです。
そしてこの2つは、非エンジニアがもともと持っている力です。
「プログラミングができないから起案できない」という制約が消えた ― これがバイブコーディングの本質だと思っています。

だからこそ、11節の落とし穴③をもう一度強調させてください。

テストは「作ったものが壊れていないか」を保証しますが、「作るべきものだったか」は保証しません。

そこは網の外側にあり、人間の起点力だけが担保できる領域です。
逆に言えば、網の内側（デグレ・ハルシネーション・ブラックボックス化）は全部機械に任せていい、ということでもあります。

そして、安全網を張る理由もここに繋がります。
壊す不安に脳のリソースを食われている間は、「次に何を作るか」を考える余裕が生まれません。
テストは品質のための作業である以上に、起点力に脳を使うための場所づくりです。

15. 目指す姿：全員が「オーナー」として動く

最後に、この型を広めたい理由を書いておきます。

一番の理想は、全員が自分の関わるサービスに対してオーナーのように動ける状態です。
「エンジニアに依頼して待つ」のではなく、思いついた人がその場で形にする。ただし 壊さずに。

営業 ― 商談のその場で「こういう画面ですよね」とモックを作って見せる。持ち帰らない
CS・PdM・デザイナー ― 気づいた改善を、要望票ではなく動くものとして出す
社長 ― チャットに投げるだけで、その機能がモックとして安全に立ち上がる
ソフトウェアエンジニア ― それらをレビューして本番化の責任を持ち、全員が安全に触れるようハーネスを整える

注目してほしいのは、入口は複数でも、通る道は1つだということです。
誰が起点になっても同じ4つの安全網を通るなら、起点を増やすことは怖くありません。

ただし、これを「全員が好きに触っていい」とは読まないでください。順番が逆です。

安全網とハーネスを先に用意した組織だけが、起点を全員に開放できます。

用意せずに開放すると、2節の絵のとおり、全員で地下に瓦礫を積むことになります。

そして、役割が消えるわけでもありません。むしろはっきりします。

役割	AI時代に担うこと
非エンジニア	起点になる。「こういうものが欲しい」を、要望ではなく動く形で出す
エンジニア	足場と責任を持つ。ハーネスを整え、設計をレビューし、本番化を引き受ける

エンジニアの仕事は減りません。全員の起点力を安全に受け止める側に移るだけです。
そして、その状態になった組織が、たぶん一番速い。タイパ至上主義者としては、そこを目指したいと思っています。

まとめ

バイブコーディングにおいて、ユニットテストは「品質のための作業」ではなく「勢いを守るための命綱」です。

AIのおかげで、非エンジニアでも本当に開発ができる時代になった
しかし事故は「デグレ」「ハルシネーション」「ブラックボックス化」として、後からやってくる
対策は慎重になることではなく、壊れたら即バレる仕組みを先に置くこと
そのためにユニットテストが最強で、しかもテスト自体をAIに丸投げできる
加えて「変更を小さく」「AI＋人のレビュー」「いつでも戻せる状態」で四重に守る
Claude Codeでは、仕様の確定（Skills）・起票（Slack ⇄ チケット）・履歴の点検をAIに寄せる
逆にハーネス（環境構築）とGit操作は人が握る。そして投げている間は待たずに別の作業をする
最後に人間に残るのは、「何を作るか」を決めて動き出す力＝起点力。安全網はそこに脳を使うための土台
目指す姿は、全員が自分のサービスのオーナーとして動ける組織。起点を全員に開放できるのは、安全網とハーネスを先に用意した組織だけ

冒頭の建物の絵をもう一度思い出してください。
私たちがやるべきは、地上の階数を競うことではなく、地下に鉄筋を入れることです。
そして今の時代、その鉄筋（テスト）は、AIに頼めば1〜2分で入ります。
やらない理由が、もうありません。

安全網を張るのは、慎重になるためではありません。
思い切りアクセルを踏むためです。 テストを書いて、遠慮なくバイブしていきましょう。🎸

（おまけ）コピペ用プロンプト6点セット

① テスト生成
このコードのユニットテストを、正常系・境界値・異常系（空文字・null・0・マイナス・
巨大値）を含めて全パターン書いてください。テスト名は日本語で意図が分かるように。

② 失敗解析
テストが落ちました。以下ログ全文です。実装とテストのどちらが誤りかを判断し、
理由を説明したうえで修正してください。

③ 影響範囲の洗い出し
この変更で影響を受ける可能性のある箇所を列挙し、テストが無い箇所があれば
先にテストを追加してください。

④ セルフレビュー
この差分を厳しめのシニアエンジニアとして批判的にレビューし、指摘を
「重大 / 中 / 軽微」に分類して修正案も添えてください。

⑤ 安全確認
認証情報のハードコード、SQLインジェクション、権限チェック漏れ、
例外の握り潰しが無いか確認してください。

⑥ 文化の点検（定期実行）
直近50コミットの差分を読んで、このリポジトリの設計方針・命名規則・テストの
書き方から逸脱している変更を挙げてください。「この積み方を続けると将来こう
困る」という観点でお願いします。