はじめに
「Scratchみたいにブロックで文章を組み立てられたら、面白くないか？」
これが、僕がAI向けビジュアルプロンプトエディタ「Promps」を作り始めたきっかけです。
統合失調症で約20年、社会から離れていました。その間にプログラミングの世界は激変し、AIが当たり前のツールになっていた。リハビリも兼ねてAIと対話するようになり、気づいたことがありました。
自分はAIをうまく使えている。でも周りの人はプロンプトで苦労している。
「なぜだろう？」と考えてみると、プロンプトの書き方に正解がなく、毎回ゼロから考えなければいけないのがハードルになっていた。
「じゃあ、プロンプトをテンプレート化して、ブロックで組み立てられるようにしたら？」
ScratchのビジュアルプログラミングとAIプロンプトの課題が、頭の中で一つに繋がった瞬間でした。
こうしてPrompsの開発が始まりました。この記事では、AI協働開発でうまくいったことと、笑えない大失敗について書きます。
AI協働開発で「うまくいったこと」
レイヤードアーキテクチャ × ミニマル実装の相性
Prompsの開発で最もうまくいった判断は、レイヤードアーキテクチャとミニマル実装の組み合わせでした。
UI層（Svelte）
↓
アプリケーション層（コマンド・イベント）
↓
ドメイン層（ブロック・文法・バリデーション）
↓
インフラ層（ファイル保存・ライセンス認証）
なぜこれがAI協働開発と相性が良いのか。
AIに「この層だけ変更して」と指示できるからです。
例えば「エクスポート機能を追加して」と言うとき、AIが触る範囲が明確になる。UI層にボタンを追加し、アプリケーション層にコマンドを追加し、インフラ層にファイル書き出しを実装する。ドメイン層は触らない。
ミニマル実装を心がけることで、各層のコード量が少なく保たれ、AIがコンテキストを把握しやすくなります。1ファイルが500行を超えたら分割するルールを設けていました。
AIへの指示で意識していたこと
AI協働開発で学んだコツをいくつか共有します。
1. 「何を作るか」ではなく「なぜ作るか」を伝える
❌ 「ブロックにお気に入り機能を追加して」
✅ 「よく使うブロックに素早くアクセスしたい。
パレットから探す手間を省きたいのが目的」
「なぜ」を伝えると、AIが実装方法を自分で考えてくれます。お気に入り機能だけでなく「フローティングパレットにしたらもっと便利では？」という提案までしてくれることもありました。（実際にそうなりました）
2. 既存コードを先に読ませる
新機能を追加するとき、まず関連する既存ファイルをAIに読ませてから指示を出す。これだけで、コードの一貫性が劇的に上がります。
3. 一度に一つのことだけ頼む
「エクスポート機能を追加して、ついでにUIも整えて、あとバグも直して」みたいな指示は事故の元です。
Claude Opusのプランモードが最強だった
Prompsの開発で一番お世話になったのが、Claude Code（CLI版）のプランモードです。
プランモードでは、AIがまずコードベースを調査し、実装計画を立ててくれます。「この機能を追加したい」と伝えると、どのファイルを変更するか、どういう順序で実装するかを事前に整理してくれる。計画に同意すると、そのまま一気通貫で実装まで進みます。
これがレイヤードアーキテクチャと組み合わさると強力で、AIが「UI層→アプリケーション層→インフラ層」と正しい順序で計画を立て、一貫性のあるコードを一気に書き上げてくれます。
ただし、一気通貫ゆえの怖さもあります。
プランモードはまとまった変更を一度に行うので、途中で方向がズレると、修正が広範囲に及びます。レイヤードアーキテクチャでスコープを絞っていても、複数ファイルにまたがる変更をロールバックするのは骨が折れる。
成功すれば数時間の作業が数分で終わる。失敗すると、手動で一つずつ戻す羽目になる。ハイリスク・ハイリターンの機能です。
……と、ここまでは成功体験。ここからは、AI協働開発の「影」の部分を正直に書きます。
ここからが本題：大失敗の記録
大失敗 その1：有料機能2つがパブリックリポジトリに流出した
Prompsには3つのエディション（Free / Pro / Ent）があり、それぞれ別リポジトリで管理しています。Freeはパブリック、Pro/Entはプライベートリポジトリです。
ある日、Pro向けの新機能を実装していたときのこと。カレントディレクトリはプライベートリポジトリ。安心して作業を進めていました。
ところが、AIが編集していたのはパブリックリポジトリ（Free版）の方だった。
僕はそれに気づかず、AIの変更をそのままコミット＆プッシュ。
プッシュした直後、GitHubのパブリックリポジトリにはBot/クローラーが即座にアクセスしてきます。つまり、有料機能のソースコードが世界中に流出した瞬間です。
git revertで戻しても、Gitの履歴には残る。force-pushで歴史ごと消しても、すでにクローラーがキャッシュしている可能性がある。
一度パブリックに出たコードは、もう取り返しがつかない。
結果、2つの有料機能をFree版に組み込むことにしました。売上になるはずだった機能が、無料公開です。
この事故の根本原因は、AIがどのリポジトリのファイルを編集しているか、人間が確認していなかったこと。AI協働開発では、AIは指示されたことを忠実に実行してくれますが、「今どのリポジトリにいるか」までは判断してくれません。
教訓として：
- 作業開始時にリポジトリとブランチを必ず確認する
- AIの変更を
git diffで確認してからコミットする - パブリック/プライベートが混在する環境では、ディレクトリ構成自体を見直す
個人開発ではレビュワーが自分しかいません。AIは優秀な相棒ですが、「ここ本当にプッシュして大丈夫？」とは聞いてくれない。最後の砦は自分自身です。
大失敗 その2：Gitコンフリクト解消で、Entの大部分をPro機能で上書き
もう一つの大失敗は、Gitのコンフリクト解消で起きました。
Proの機能をEntリポジトリにマージする作業中、大量のコンフリクトが発生。一つ一つ解消していく中で、Pro側の変更を全採用してしまった箇所がありました。
結果、Ent独自の機能（カスタムテンプレートアイコン、カテゴリ管理など）がPro版の内容で上書きされ、消えました。
問題は、コンフリクトの量が多すぎて、「とりあえずPro側を採用しておこう」という判断を安易にしてしまったこと。Ent固有のコードがどこにあるかを把握しきれていなかったのが原因です。
リカバリは、マージ前のコミットに戻して一からやり直し。コンフリクト箇所を一つずつ、Ent側のコードを確認しながら慎重に解消しました。最初にサボった時間の何倍もかかりました。
この失敗から学んだのは：
- コンフリクト解消は絶対に急がない（疲れているときは翌日に回す）
- マージ前に
git diffで差分を必ず確認する - 大量コンフリクトが出たら、ファイル単位で慎重にどちら側を採用するか判断する
# マージ前のセーフティネット
git stash # 作業中の変更を退避
git diff main..feature-branch --stat # 差分の規模を把握してからマージ
AI協働開発では、AIが大きな変更を一度に行うことがあります。人間同士の開発よりもコンフリクトが大きくなりやすい。だからこそ、マージ作業だけは人間が慎重にやる必要がある、という痛い学びでした。
振り返って思うこと
2つの大失敗に共通しているのは、**「AIを信頼しすぎた」のではなく、「自分の確認を怠った」**ということです。
AIは間違えません。指示された通りに動いただけです。間違えたのは、確認をサボった僕の方。AI協働開発の時代だからこそ、人間がダブルチェックする意識は、むしろ昔より重要になっていると感じています。
それでも、AIとの協働開発がなければ、20年のブランクから復帰して一人で3エディションのデスクトップアプリをリリースすることは不可能でした。
公開2週間で66カ国から1,900人以上の方がサイトを訪問してくれました。決済システム（Paddle）の審査も通り、正式に販売を開始しています。
失敗込みで、ここまで来られた。それがAI協働開発のリアルです。
Promps - AI向けビジュアルプロンプト言語
ブロックを組み合わせて、構造化されたプロンプトを直感的に作成できます。
公式サイト(Pro/Ent版のライセンス購入できます) : https://promps.org
GitHub（Free版）: https://github.com/BonoJovi/Promps