AIを使った開発は、かなり速くなりました。
Cursorに要件を渡せば、かなりの速度でコードを書いてくれます。
実装も進むし、エラーも直してくれる。少し前と比べると、開発体験は大きく変わりました。
でも、実際に業務システムを作っていると、別の問題が出てきます。
それは、
AIは、与えられた要件の中ではかなりよく実装するが、「そもそも何が抜けているのか」を十分に見つけてくれない
という問題です。
最近、ある業界向けの請求システムを作っていて、まさにこれを感じました。
「請求機能が完成した」と思っても、少し考えると疑問が次々と出てきます。
- オプション料金はどうするのか
- 食事や物品などの追加費用はどうするのか
- 追加サービスの利用実績は誰が入力するのか
- 利用者がタブレットから入力するのか
- 個人ログイン画面から入力するのか
- その両方がある場合はどう整合させるのか
- そもそもその入力機能を使っていない拠点はどうするのか
- スタッフが代理入力する必要はないのか
- あとから訂正した場合はどう扱うのか
- 請求確定後に修正があった場合はどうするのか
こういうものは、コードのバグではありません。
プロダクト設計上の抜けです。
そして今後のAI開発で重要なのは、単に「コードを書く速度」を上げることではなく、
人間が気づく前に、AI自身がこの抜けを発見すること
だと思っています。
「人間が間違いを指摘してAIが直す」は、そろそろ卒業したい
よくあるAI開発の流れはこうです。
人間 ↓ 要件を伝える ↓ Cursor ↓ 実装 ↓ 人間が抜けに気づく ↓ Cursorに修正させる ↓ また人間が別の抜けに気づく
もちろん、これでも昔よりは圧倒的に速いです。
ただし、この構造では結局、
人間がProduct Manager、QA、Domain Expertを全部兼任しています。
AIはコードを書く役割にはなっていても、開発そのものの責任はまだ人間側に残っています。
これでは本当の意味で「AIに開発を任せた」とは言いにくい。
目指したいのは、こういう状態です。
人間 ↓ 大きな目的を伝える ↓ AIが制度・既存コード・UI・DB・業務運用を調査 ↓ AIが要件を展開 ↓ AIが抜けを自分で探す ↓ AIが実装 ↓ 別のAIが反証 ↓ AIがテスト ↓ 判断が必要なポイントだけ人間に聞く
この形に近づけたい。
Cursorを「AI開発チーム」にする
Cursorを使い続ける前提なら、単一Agentに全部やらせるより、
役割の違うAgentを分ける
のがよさそうです。
まずは4つに分けるのがシンプルです。
あなた
│
│「請求機能を完成させて」
▼
┌──────────────────────┐
│ ① Product Researcher │
│ 何を作る必要があるか調査 │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ ② Devil's Advocate │
│ 抜け・矛盾・例外を探す │
└──────────┬───────────┘
▼
PLAN / SPEC
│
▼
┌──────────────────────┐
│ ③ Builder │
│ 実装・テスト │
└──────────┬───────────┘
▼
┌──────────────────────┐
│ ④ Completion Auditor │
│ 「未完成」を証明する │
└──────────┬───────────┘
▼
あなた
判断事項だけ確認
重要なのは、
同じAIに全部やらせないこと
です。
自分で作った設計を、自分でレビューすると、どうしても前提を引き継いでしまいます。
なので、役割とコンテキストを分ける。
1. Product Researcher
最初のAgentは、コードを書かせません。
役割は、
「この機能を現実の業務で成立させるには、何が必要なのかを調査すること」
です。
例えば請求システムなら、
単に「請求データを作る」ではなく、
制度上必要な情報 ↓ その情報はDBに存在するか ↓ 存在しないなら、誰が入力するか ↓ どのUIから入力するか ↓ どう修正するか ↓ いつ確定するか ↓ 請求データにどう反映するか
まで考える必要があります。
追加サービス料金を例にすると、
利用実績が必要 ↓ 現在DBにある？ ↓ No 誰が入力する？ ├ 利用者 └ スタッフ ↓ 利用者が入力する場合 ├ タブレット └ 個人ログイン ↓ どちらも使っていない拠点は？ ↓ スタッフ入力が必要？
というように掘らせます。
ここで重要なのは、
「現在存在する画面やDBの範囲だけで考えない」
ということです。
必要な情報がなければ、
「新しい入力経路が必要」
という結論まで出してほしい。
2. Devil's Advocate
次は、仕様を壊す役割です。
Product Researcherが作った仕様を見て、
「これは不完全である」と仮定して反証する
Agentです。
例えばこんな問いを投げます。
この仕様のまま本番導入すると何が起きるか？ 以下を重点的に探す。 - 業務上必要だが未考慮のケース - 現場運用で成立しないケース - 入力経路が存在しないデータ - スタッフ運用の抜け - 利用者運用の抜け - 訂正・取消 - 月跨ぎ - 請求確定後の変更 - 権限 - 監査ログ - 差し戻し - 再請求
さらに、
最低10個の反証仮説を出す
くらい強制してもいいと思っています。
例えば、
- 追加サービスを申し込んだが当日キャンセルした場合は？
- 予定と実績は同じデータでよいのか？
- 利用者本人が入力できない場合は？
- スタッフがあとから代理入力した場合、誰が入力したか残るか？
- 請求確定後に実績が変わった場合は？
などです。
ここを人間が考えるのではなく、AIにやらせる。
3. Builder
ここで初めて実装です。
大事なのは、
人間 ↓ Builder
にしないこと。
Research ↓ Critic ↓ SPEC ↓ Builder
にします。
Builderは仕様に従って実装するだけにする。
さらに、
勝手に業務仕様を補完しない
というルールも入れます。
判断不能なものは、
DECISION_REQUIRED
として人間に上げる。
これによって、
AIが勝手に仕様を決めて実装してしまうリスクを減らせます。
4. Completion Auditor
最後がかなり重要です。
普通のレビューは、
「問題がないか確認してください」
と依頼します。
でも、このAgentには逆のことを言います。
「完成していない理由を探してください」
と。
例えば、
この機能は完成したと報告されています。 あなたの役割は完成を確認することではありません。 この機能が未完成であることを証明してください。
くらい強く指定する。
確認するレイヤーは、
業務ルール ↓ 業務フロー ↓ UI ↓ API ↓ DB ↓ 請求データ ↓ テスト
です。
そして逆向きにも確認します。
請求データ ↓ この値はどこから来た？ ↓ 誰が入力した？ ↓ いつ確定した？ ↓ 修正可能？ ↓ 監査可能？
これをやると、単なるコードレビューでは見つからない問題を拾いやすくなります。
「完成」の定義をコードの完成から変える
AI開発で一番危険なのは、
コードが動いた＝完成
と判断することだと思っています。
業務システムではそうではありません。
例えば「請求機能が完成した」というのは、
単に請求データを出力できることではない。
必要なのは、
入力 ↓ 保存 ↓ 確認 ↓ 訂正 ↓ 確定 ↓ 請求 ↓ 差し戻し ↓ 修正 ↓ 再請求
までのライフサイクルです。
なので、Completion Gateを明文化しておくとよいと思っています。
例えばこんな感じです。
## FEATURE COMPLETE - [ ] 業務要件を一次資料・既存仕様と照合済み - [ ] 正常系を網羅 - [ ] 例外系を網羅 - [ ] 必要データの取得経路が存在 - [ ] 利用者入力で成立 - [ ] スタッフ入力で成立 - [ ] 各入力機能を使わない拠点でも成立 - [ ] 訂正・取消が成立 - [ ] 権限確認済み - [ ] 監査可能 - [ ] 請求確定後の変更を処理可能 - [ ] 自動テストあり - [ ] E2Eテストあり - [ ] Product Researcher PASS - [ ] Devil's Advocate PASS - [ ] Completion Auditor PASS
1つでもFAILなら、
「完成」と報告してはいけない
というルールです。
高性能モデルは「コードを書くところ」より「抜けを探すところ」に使う
ここも重要だと思っています。
AI開発では、つい、
「一番高性能なモデルでコードを書かせよう」
と考えがちです。
でも、今の自分のボトルネックはそこではありません。
コードを書く速度ではなく、
何を作るべきかを考える速度
と、
何が抜けているかを発見する能力
です。
なのでモデル配分も変えます。
コードベース探索 → 高速・低コストモデル 通常実装 → コーディングが強いモデル Product Research → 高性能Reasoningモデル Devil's Advocate → 高性能Reasoningモデル Completion Audit → 高性能Reasoningモデル
つまり、
賢いモデルを実装より前後に置く
という考え方です。
今後のAI開発は「コード生成」より「自律的な問題発見」
AIコーディングの初期フェーズは、
どれだけ速くコードを書けるか
が価値でした。
でも、これからは変わっていくと思っています。
人間が、
この追加料金の扱いは？
と指摘して、
AIが、
対応します
と答える。
これは便利ではあるけれど、まだ人間がレビューの中心です。
理想は、
AI側から、
請求機能について調査しました。 現状では以下が未対応です。 1. 追加料金の実績入力経路 2. タブレット未使用拠点の代替入力 3. 個人ログイン未使用拠点の代替入力 4. 請求確定後の訂正 5. スタッフ代理入力時の監査ログ このため、現時点では完成扱いにできません。 仕様判断が必要なのは以下の2点です。
と出てくる状態です。
さらに理想を言えば、
業務要件73件を確認 68件 → 実装済み・テストPASS 3件 → 仕様判断待ち 2件 → 未実装 したがって、本機能は未完成です。
までやってほしい。
ここまでいけば、
AIにコードを書かせているというより、
AI開発チームを管理している
と言える状態に近づきます。
まず既存の請求機能で試してみる
いきなり開発プロセス全体を変えるのではなく、
今作っている請求機能をテストケースにするのがよさそうです。
Cursorに、
.cursor/
agents/
product-researcher.md
devils-advocate.md
completion-auditor.md
rules/
feature-completion.mdc
のような構成を用意する。
そして重要なのは、
いきなり実装修正させない
ことです。
今ある請求機能に対して、
Product Researcher
→ Devil's Advocate
→ Completion Auditor
だけを実行します。
そして、
- 追加料金
- 利用実績の入力
- タブレット利用
- 個人ログイン
- 各入力機能を使わない拠点
といった、自分がすでに気づいている論点を、
こちらから教えずにAIが発見できるか
を評価する。
これをベンチマークにするのがよいと思っています。
AI開発を効率化するというと、
- より速いモデル
- より安いモデル
- よりコード生成が強いモデル
に目が行きがちです。
でも、実務で一番時間を取られるのは、
人間が「何か抜けていないか」と考え続けること
かもしれません。
なので、これからのAI開発で重要なのは、
「実装するAI」だけではなく、「疑うAI」「調査するAI」「完成を否定するAI」を持つこと
だと思っています。
Cursorを単なるコード生成ツールではなく、
Product Researcher / Critic / Builder / AuditorからなるAI開発チームとして使う。
これが、今自分が試してみたい開発スタイルです。
