spec 駆動のエディタ（Claude xxxx とか Codex とか Kiro とか）流行りなのですが、それ vscode + copilot でやることもできます、って話です。夜間にぐるぐる回すようなヘビーな使い方をする業務型プログラマならば別ですが、それほど AI に任せきりではなく AI ペアプロぐらいな形で廻している場合には、課金的にはこっちのほうで十分です。まあ、開発のスタイルにもよるんでしょうけど、React とか Node.js を使った Web 開発のほうは Codex 系でぶん回したほうがいいのでしょうが、Android 実機で BLE 通信を確かめるとか（ってのを今やっている）のは、どうしても実機まわりのテストを手動でこなさなくてはいけないので、AI でぶん回すことは無理なのです。
あと、当然のことながら、
- 趣味でプログラミングをやる
- 在宅プログラマで、いくつかの案件を廻している
- 新人教育で AI を使ってプログラミング学習も兼ねる
というパターンも、vscode + copilot で十分です。GitHub Copilot のほうは pro で十分で月額は $10 で…という宣伝はどこかに書いたような気がするのでさておき、ここでは「設計」と「実装（コーディング）」を分離させていきましょう、という話です。
Windows Copilot がやたらに実装を勧める
プロトタイプを作って動きから確認したい場合には、要件や設計を煮詰める前に実装を始めてしまうほうが楽です。というのも、具体的に UI が決まっていないのに、長々と要件/設計を煮詰めてしまうと、余計な設計をしてしまいがちです。そのあたりは、スパイラル開発あたりを参考にしてください。
昨今の spec 駆動型エディタは、要件/設計を先に煮詰める形になっていますが、これはいわゆる「ワンパス」方式になります。いわゆる、コンパイラ設計でコードからアセンブラに落とすときの「ワンパス」つまり一回しか読み込まない方式です。要件/設計 → 実装の一手順だけを考えれば、要件/設計をしっかり作る＝夜間に AI にコード生成を頼む、ということになるので AI の時間一杯を使うだけの設計の盛り込みが必要になりますが、先のように設計→実装→UI 確認→設計→実装 のサイクルとなると、それほど設計の作り込みは必要ありません。と言いますか、余分なところが多く出てしまいます。
ただし、ここのサイクルが廻る開発/実装環境と、そうではない環境（先の Android 実機でのテストなど）では、プロトタイプサイクルの時間が異なるので、設計と実装の時間比とバッチ（いわゆる実装する機能の大きさ）を調節する必要があります。
で、Windows Copilot などで、コード開発をしようとすると、やたらにコード例を示してきます。どうも、React + Fagma の組み合わせや Python 開発が最初に出てくるので、この開発スタイルに引きずられてしまいます。一般的な AI 驚き屋の対象も Web 開発になるので、確かに UI から考えていったほうが検討上早いというのもあるでしょう。実際 Web サイトの自動開発はとてつもなく早いです。Windows Copilot や、その他の AI エージェントも Web 開発を前提としているものが多いのでしょう。
ですが、非 Web 開発の場合には、機器などをそろえたり環境を揃える必要があるので、そう簡単に実験環境が揃えるわけでもありません。特に AWS や Azure の環境にないものを使う場合は、環境構築も含めて検討をする必要があります。そういう点で、「設計」に力点を置いたほうが、ソフトウェア開発において無駄が少なくなる、というバランスになるのです。
設計と実装をプロンプトで分離する
ちょっと前までは（それも数か月前ですね）、spec 駆動は別の AI エージェントの IDE を使っおいて、コーディングは Claude xxxxx や Codex に任せる、というスタイルが多かったのですが、現状だと vscode + copilot ひとつで済みます。これ、vscode + copilot に agent モードが追加された（それまでは ask モードとして質問だけだった）ことが大きくて、これによって、
- 要件や設計を煮詰めたいときは ask モードでやる
- 実装やバグ直しをしたいときは agent モードでやる
という使い分けをします。ask モードの場合は、最初の頃はコードをばらばらと出してくるのですが「コードをの提案をしないで」とか「設計に集中して」というような、プロンプトを入れるとコードの提案をしなくなります。おそらく model の内部的に、コードの部分は codex で、それ以外は chatgpt で、という使い分けがなされているからと思われます。
さらに、再設計時には AI にコードを触れてほしくないので、敢えて ask モードを使います。ask モード自体は、従来のプロンプトで質問して、その解答をテキストだけで表示するモードでコードに反映するのが手間だったりするのですが、敢えてこれを利用します。思考したいだけですので、AI 壁打ち状態とするわけです。
実例
以前、ためしに作ってみた「見積もり依頼作成ツール」 https://omitt-chan.vercel.app/ を変更してみましょう。これも AI エージェントを使ったもので、基本的に次のような readme.md を使って、初期型を作っています。
# omitt-chan
見積もり依頼作成ツール
- 発注者が、みずから希望する機能を入れて見積もり依頼書を作る
- 見積もり依頼書のテンプレートを提供
- 作成した見積依頼書をもとに3パターンの見積もりを作成する（相見積に使う）
# 画面構成
- 左ペインに、発注者が対話的に入力するチャットフォーム
- 中央ペインに、発注者が入力した要件や機能を構造化して表示する
- 右ペインに、見積もり依頼書のテンプレートを表示する
## 要件チャット（左ペイン）
- 発注者は、チャット形式で要件や機能などを入力する。
- 発注者は非IT技術者のため、自然言語で要件を入力する。
- 希望、要件、設計、制約などは混在して入力されるため、入力内容を解析して構造化する必要がある。
- 発注者の入力を解析して、要件や機能を抽出し、中央ペインに表示する。
## 要件整理（中央ペイン）
- 中央ペインでは、発注者が入力した要件や機能を整理して表示する。
- 要件と機能を区別して表示する。
- 機能は、機能要件と非機能要件を区別して表示する。
このときは、readme.md に書いていたのですが、design.md とか設計.md とかでも構いません。ファイル名は、プロンプトから「design.md をもとにして Web サイトを作成して」で指示ができます。
ここでは、機能追加をする上で、どのような設計がよいかを readme.md に手作業で追加していくことを考えます。
こうやって、見積もり依頼書ができた後に、おおまかな予算を顧客側で把握したい、と考えます。
設計に適していると思われる CPT-5 に変更して、Ask モードに切り替えておきます。
追加機能を書きたい場所を、readme.md 等に作っておきます。
ここでは「概算予算の計算」という項目を作りました。
プロンプトで、追加機能を設計していきます。
初期状態だと、コードが大量にでてくるので、これをプロンプトで抑制します。
プロンプトで抑制すると AI の回答にコードが含まれなくなります。安全のために Ask モードのままで会話します。
以降は、コード無しで会話ができます。機能追加の検討でも、やたらにコードを出すことはありません。この分、トークンの消費も少ないし、レスポンスも早くなります。まあ、Agent/Ask の切り替えが面倒というのもありますが、そこまで開発スピードを求めるならば別途 SPEC 用の AI エージェントを使えばよいわけで、私のような使い方だとこれぐらいで十分かな、という感じですね。
あとは、Chat での検討に従って、readme.md に追記していけば ok です。このときに Agent モードに切り替えてもよいし、markdown 形式への補完をつかってもよいでしょう。
その後に、あらためて「概算予算の計算を Web サイトに追加して」というプロンプトを Agent モードで Copilot に頼めばよいのです。
もちろん、一手順ずつうごくので夜間で バイブコーディングとして動かすことはできません。ですが、要件や設計を試行錯誤しながらスパイラル開発っぽいものをやる場合には、このスタイルのほうが良いです。
