コードを書かずに開発は成立するのか？2日間の完全AI実験で見えた限界と可能性「Selectable Anywhere」第1回

Last updated at 2026-03-02Posted at 2026-03-02

はじめに

こんにちは！学生エンジョイプログラマーのﾋﾟｰﾗｯﾌﾟ(Prrapp)です！

「AIに全部任せれば、アプリは完成するのでは？」

生成AIの進化で、そんな言葉をよく目にするようになりました。
そこで今回は、本当に“完全AI開発”は可能なのかを検証してみました。

開発したのは、コピーできないテキストをコピー可能にするUserScript
Selectable Anywhere。

条件はシンプルです。

開発期間：2日間
実装：完全AI
仕様書：AIに作らせる
AIエージェントに送るプロンプト：これもAIに作らせる
人間は「指示と判断と実装方針の提示(ごく一部)のみ」

つまり、コードは一切手書きしません。

今回は、仕様書もプロンプトもAI任せにした場合、UserScriptは本当に完成するのかを検証しました。
そしてその過程で見えた「完全AI開発における人間の役割」についてまとめます。

なお、本記事は個人開発のリアルな記録です。
成功談だけでなく、詰まった点や失敗も含めて共有します。

環境(本記事に必要そうなことのみ)

ChatGPT 無料版
Codex(基本的にモデルはGPT-5.3-Codex、無料版)
ブラウザ：Vivaldi 7.8.3925.74 (公式ビルド) (64-bit)
カスタムバージョン: 144.0.7559.230
チャンネル: 公式ビルド
プラットフォーム / OS: Windows 11 Version 25H2 (Build 26200.7840)
UserScriptマネージャー：Tampermonkey
Tampermonkeyのバージョン：5.4.1
テストしたサイト1：うたてん
テストしたサイト2：自作ページ(Live Server, Github Pages)

背景：なぜこの検証をしたのか

正直に言うと、最初から「完全AI開発を検証しよう」と思っていたわけではありません。

私は単純に、コピーできないテキストをコピーできるようにするUserScriptを作りたかっただけです。
個人用に「Selectable Anywhere」というスクリプトを作ろうと思いました。

ただ作った後で、
「どこまでAIに任せられるのか？」を考える機会になると思い始めました。

さらに私は気づかないうちに、

仕様書をAIに作らせる
AIエージェントに送るプロンプトもAIに作らせる
自分ではコードを書かない

という縛りを勝手に自分に設けていました。

結果的にこれは、
完全AI開発は成立するのか？ という実験になりました。

まずは仕様書をAIに書かせてみた

実際に私が自分で考えて打ち込んだプロンプトは、突き詰めるとほぼ以下の内容だけです。
これは、私がSelectable Anywhereを開発するようになったきっかけとなる一番最初のプロンプトです。

バイブコーディングでUserScriptを作りたいので、仕様書を作ってください
UserScriptはこのような構想です
"""
## 背景
ブラウザ拡張機能「スーパーコピー」が使えなくなった
## 作りたいもの
コピー(選択)できないテキストをコピー(選択)できるようにするUserScript
"""

(「使えなくなった」は嘘です。ブラウザに使うと良くないと警告されたから「使わなくなった」が本当です。)

出てきた仕様書

出力と改善を繰り返した結果、このような仕様書が出力されました。

仕様書

# 🎯 1️⃣ 目的

Webサイトの

* テキスト選択禁止
* コピー禁止
* 右クリック禁止

を、安全性を保ちながら解除する。

さらに：

* 現在状態を可視化
* ワンクリックで切替可能

---

# 🌐 2️⃣ 対象範囲

## ✅ 対応

* CSS `user-select: none`
* `copy / cut / contextmenu / selectstart`
* 軽度のJS妨害
* 動的style変更（限定監視）

## ❌ 非対応

* Shadow DOM内部
* iframe内部
* DRM保護
* canvas描画文字

---

# ⚙ 3️⃣ 実行仕様

| 項目      | 内容                          |
| ------- | --------------------------- |
| 実行環境    | Tampermonkey                |
| 実行タイミング | `@run-at document-start`    |
| 対象      | `@match` 指定                 |
| 状態保存    | `GM_setValue / GM_getValue` |
| 切替UI    | 常時表示フローティングボタン              |
| デバッグ    | `DEBUG` フラグ制御               |

---

# 🧠 4️⃣ コア機能仕様（v1.2継承）

---

## 🎨 4-1️⃣ CSS解除（安全型）

```css id="a1x9fk"
html, body {
  user-select: text !important;
  -webkit-user-select: text !important;
}

body *:not(input):not(textarea):not(button) {
  user-select: text !important;
  -webkit-user-select: text !important;
}
```

### 設計意図

* フォーム要素保護
* pointer-events未変更
* UI副作用最小化

---

## 🧩 4-2️⃣ イベント妨害対策

### 対象

* copy
* cut
* contextmenu
* selectstart

### 手法

* captureフェーズで先回り登録
* `stopImmediatePropagation()`のみ使用
* preventDefaultは使用しない

### 禁止事項（安全優先）

* prototype改変
* addEventListenerラップ
* preventDefault上書き

---

## 👀 4-3️⃣ MutationObserver（軽量）

```javascript id="d2z7gh"
{
  attributes: true,
  attributeFilter: ["style"],
  subtree: true
}
```

### 目的

* style属性変更のみ検知
* 再適用は最小限

---

# 🎛 5️⃣ UI仕様（v1.3追加）

---

## 📐 5-1️⃣ UI構造

| 要素      | 内容            |
| ------- | ------------- |
| 追加DOM   | body直下に1divのみ |
| 位置      | 右下固定          |
| サイズ     | 40px × 40px   |
| 形状      | 円形            |
| z-index | 2147483647    |

---

## 🎨 5-2️⃣ 状態表示

| 状態  | 表示 | 色       |
| --- | -- | ------- |
| ON  | S  | #2ecc71 |
| OFF | ×  | #e74c3c |

ツールチップ：

* ON → "Selectable Anywhere: ON"
* OFF → "Selectable Anywhere: OFF"

---

## 🖱 5-3️⃣ 動作仕様

クリック時：

1. `GM_setValue("enabled", !state)`
2. consoleログ出力（DEBUG時）
3. `location.reload()`（確実反映）

---

## 🛡 5-4️⃣ UI安全設計

* サイトCSSに依存しないインラインstyle
* class名衝突回避（`sa-toggle-ui` 固定）
* イベントはUI内部のみ
* Shadow DOM不使用

---

# 🪵 6️⃣ 状態管理

```javascript id="e4m8bn"
GM_getValue("enabled", true);
GM_setValue("enabled", value);
```

* デフォルトON
* サイト別保存

---

# 🧪 7️⃣ テスト設計

## 基本テスト

* CSSのみ制限サイト
* JSのみ制限サイト
* SPAサイト
* ON/OFF保持確認

## UIテスト

* クリック切替
* 状態色反映
* reload後保持
* UIがサイトと衝突しない

---

# 📊 8️⃣ 成功率予測

| サイト種別    | 成功率 |
| -------- | --- |
| ニュース     | ◎   |
| ブログ      | ◎   |
| 一般メディア   | ◎   |
| 軽量Webアプリ | ○   |
| 強制制限サイト  | △   |

---

# 🔐 9️⃣ 安全性評価

| 観点    | 評価    |
| ----- | ----- |
| 副作用耐性 | ★★★★★ |
| 安全性   | ★★★★★ |
| 実用性   | ★★★★☆ |
| 拡張性   | ★★★★☆ |
| 実装難易度 | ★★☆☆☆ |

---

# 🚀 🔟 将来拡張余地

* UIドラッグ移動
* Forceモード（別ブランチ）
* Shadow DOM対応版
* iframe対応版

---

# 📌 最終確定構成（v1.3）

* 安全優先制限解除
* GM保存
* 軽量Mutation監視
* 常時表示トグルUI
* デバッグ制御

ですが、重大な欠陥が上記の仕様書にはあります。
これは次章で述べるので割愛します。~~暇な人は探してみてください。~~

プロンプト設計もAIに任せた結果

もちろんAIエージェント用のプロンプトもAIに作らせます。
プロンプトはこんな感じです。

ありがとうございます。
次にバイブコーディングのプロンプトを、
先程の仕様書を*{仕様書}*と省略して作成してください

ここでプロンプトを作らせているAIはこのような事を言いました。

仕様書をそのまま入力として与え、段階的に実装させる構造化プロンプトにするのが最も安定します。
一括生成ではなく「設計→骨組み→実装→レビュー」の順に生成させる形式が安全です。

概ね妥当な指摘です。
そして、実際に私がAIエージェントにコピペしたプロンプトは下の折りたたみにあります。

段階的生成プロンプト

# 🪜 段階的生成プロンプト（推奨）

## Step1: 設計レビュー

```
以下の仕様をもとに、実装前レビューを行ってください。

======================
{仕様書}
======================

レビュー観点：
- 安全性
- パフォーマンス
- 破壊的変更リスク
- Webアプリ互換性
- 想定外副作用

問題点と改善提案のみ出力してください。
コードは出力しないでください。
```

---

## Step2: 骨組み生成

```
以下仕様に基づき、Tampermonkeyスクリプトの骨組みだけ生成してください。

======================
{仕様書}
======================

条件：
- メタデータブロックを含める
- UIトグルのみ実装
- ロジック部分は空関数でよい
- コメントで処理位置を明示する

フルコードのみ出力してください。
```

---

## Step3: ロジック実装

```
以下仕様に基づき、骨組みにロジックを実装してください。

======================
{仕様書}
======================

制約：
- user-selectのみ上書き
- style属性のみMutationObserver監視
- キャプチャフェーズでイベント抑止
- preventDefault + stopPropagation 使用可
- 安全性最優先

最終コードのみ出力してください。
```

---

## Step4: セキュリティ監査

```
以下コードを監査してください。

観点：
- prototype汚染がないか
- メモリリーク可能性
- MutationObserver過剰監視
- UIのz-index競合
- GM API誤用

問題点のみ箇条書きで出力してください。
```

---

全4ステップ、設計レビュー→骨組み生成→ロジック実装→セキュリティ監査からなるプロンプトです。

良いところ

段階生成であるところ
丁寧で網羅的であるところ
条件や制約、観点などをまとめているところ

気になるところ

このプロンプト自体の気になるところは特になし。

細かいことですが、Step4の「以下コードを監査してください」という文言は不正確でした。実際には直前の出力を指しているため、「先程のコード」に修正して送信しました。

Step4の時も問題点が見つかったので、その都度プロンプトを作らせているAIに送信します。これはプロンプトでは悪くないところ出力してほしかったです。横柄かもしれませんが……

小まとめ

段階生成で丁寧かつ網羅的なプロンプトではありましたが、
実際に設計レビューをさせると後述の「設計レベルの重要欠陥」が見つかりました。

つまり、プロンプト自体は整っていても、
元となる仕様が曖昧だったり、矛盾をはらんでいれば問題はそのまま表面化します。

AIにプロンプトを作らせることはできますが、
「設計の妥当性を保証する存在」にはなりませんでした。

実装フェーズで起きた問題

「設計レベルの重要欠陥」

CodexにStep1を送信して設計レビューさせたのですが、やはり色々と問題点が見つかりました。
この問題点は「設計レベルの重要欠陥」とプロンプトを作らせているAIは表現しています。
その時はわざわざ仕様書を書き直させました。
(見出し6の「サイト別保存」とGM_setValue()の引数が整合性に欠けています)

初めの不具合

まず最初は動いたのです。
でもその後はOFFにするとそれ以降はONにしても動かなくなりました。
その後はON/OFFを変更しても動かず、リロード、ブラウザの再起動を試しても動かなくなりました。
このことをプロンプトを作らせているAIに相談したらプロンプト(段階生成)を提示されたので(一部改変して)送信しました。

原版

以下のUserScriptが一部サイトで動作しません。

原因を論理的に推測してください。
可能性を確率付きで列挙してください。

禁止事項：
- 憶測断定禁止
- prototype改変提案禁止

私の改変版

以下のUserScriptが一部サイトで{不具合}のように動作しません。

原因を論理的に推測してください。
可能性を確率付きで列挙してください。

禁止事項：
- 憶測断定禁止
- prototype改変提案禁止
## 不具合
{ここに不具合を書く}

(上のプロンプト以降の段階はありますが、省略しています)
実際のブラウザで検証を行いました。
これはAIが言うには、

AIの確率 = 推論
あなたのブラウザ = 事実
事実で推論を潰すのが正解ルートです。

らしいからです。(確率と推論逆じゃないかな……)
概ね間違いではないことを言っていますね。

実は、これを何回も(おそらく10回以上)繰り返しても改善せず、私は就寝しました。

起床後、気分でチャットを作り直してデバッグし直しました。
その時、私は下の新たな実装を提案しました。

style属性はインラインスタイルが優先的に適用されるので、
ONにすると、選択不可のHTMLの要素を集合型に記録して、
インラインでuser-select: textまたはuser-select: autoにし、OFFにすると集合型に記録された要素のuser-selectをnoneにする。

これの改良版(後述)を先程のStep2~4でコーディングさせました。

小まとめ

設計もレビューもAIに任せていた以上、
問題は「誰のミスか」という話ではありません。

AIは常に前の出力を前提として論理的に振る舞っていました。
しかし、その前提が誤っていれば、誤りもまた論理的に拡大します。

完全AI開発では、
“設計の連鎖”そのものが品質を決めると感じました。

結果：本当に完成したのか？

結果は表で表します。

項目	結果
完成度	95%
完全AI度	90%
修正回数	10回以上
仕様書(構想)修正	あり

完成度(95%)

「新たな実装を提案」してしまったことにより、想定以上にミニマルで最低限な実装になってしまっていますが、まあ使えなくはないから悪くないです。

完全AI度(90%)

先述の「新たな実装を提案」で実装を提案してしまっています。
ですが、この時提案しなかったら完成度95%に持っていくことはできないと確信しています。

デバッグ用プロンプトの改良を「指示」と捉えるなら、完全AI度はさらに上がるかもしれません。
どこまでを人間の介入とみなすかは、解釈次第です。

修正回数(10回以上)

正直言って多いと思います。
構想の修正をより先にできていればもっと減らせたと思っています。

仕様書(構想)修正(あり)

仕様の修正自体は問題ではありません。問題は、それを実装段階まで持ち越したことです。

考察：完全AI開発で見えた“人間にしかできない役割”

私はSelectable Anywhereの開発で生成AIにほぼ全て任せていました。
ですが、私がしたことはたくさんあります。

AIの出力したプロンプトの修正
AIの提示した「次のステップ」の選択

コードはAIが書いていました。
しかし「どの案を採用するか」「どこで妥協するか」を決めたのは私でした。

完全AI開発に見えて、
実際は“判断”が人間の仕事として残っていました。

AIが設計し、AIがレビューし、AIが実装する。
それでも最後に残った、人間がやることは“判断”でした。

(もっとも、AIが提示する選択肢の中から判断している以上、
判断の枠組み自体もAIに影響されている可能性はあります。)

まとめ：バイブコーディングは使えるのか？

YES。ただし条件あり。

バイブコーディングが向いている/向いていない条件

これら全てを満たしている必要はありませんし、1つでも満たさないとやってはいけないというわけでもありません。

観点	向いている条件	向いていない条件
技術構造	入出力が明確、構造が比較的シンプル	状態管理や依存関係が極めて複雑
ゴール定義	成功条件を明確に言語化できる	ゴールが曖昧で後出しが多い
開発プロセス	試行錯誤が許される小規模開発	巻き戻し不可・失敗が許されない環境
知識領域	Webなど情報が豊富な分野	ニッチ・独自仕様・学習データが少ない分野
人間の役割	人間が最終判断・レビューできる	出力の妥当性を判断できない
責任・品質	実験的・個人開発	金銭・個人情報など高い信頼性が必要

バイブコーディングは万能ではありません。
バイブコーディングは、小規模で試行錯誤が可能な環境では強力です。

しかし、
構造が極端に複雑で、
責任が重く、
巻き戻し不可・失敗が許されない環境では、
不安定な手法になります。

今回のSelectable Anywhereは「小規模(個人開発)・試行錯誤可能」だったため成立しました。

自動生成の連鎖の中で、最後に残ったのは「選ぶこと」でした。
バイブコーディングの本質は、生成ではなく判断にあるのかもしれません。

コードを書かずに開発は成立するのか？2日間の完全AI実験で見えた限界と可能性 「Selectable Anywhere」第1回

はじめに

環境(本記事に必要そうなことのみ)

背景：なぜこの検証をしたのか

まずは仕様書をAIに書かせてみた

出てきた仕様書

プロンプト設計もAIに任せた結果

良いところ

気になるところ

小まとめ

実装フェーズで起きた問題

「設計レベルの重要欠陥」

初めの不具合

小まとめ

結果：本当に完成したのか？

完成度(95%)

完全AI度(90%)

修正回数(10回以上)

仕様書(構想)修正(あり)

考察：完全AI開発で見えた“人間にしかできない役割”

まとめ：バイブコーディングは使えるのか？

バイブコーディングが向いている/向いていない条件

関連リンク

コードを書かずに開発は成立するのか？2日間の完全AI実験で見えた限界と可能性「Selectable Anywhere」第1回