はじめに

「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