Copilotが期待外れな本当の理由とAIコーディングの前提条件
「Copilotを入れたけど、正直そこまで変わらなかった」
この感想を、AI導入を進めているチームから何度も聞いた。ツールの使い方を変えたり、設定を調整したりしてみたが、劇的な変化はなかった、と。
では問題はどこにあるのか。ツールの質が低いのか。使い方が悪いのか。
どちらでもない。AIコーディングツールが活きるための「前提条件」が整っていないのが原因だ。
AIコーディングツールが"期待外れ"になるメカニズム
GitHub CopilotやCursor、そのほかのAIコーディングアシスタントは、基本的に「補完」をする。次の関数名、次の引数、次のロジック。コンテキストを読んで、それらしいコードを生成する。
ここに落とし穴がある。
AIが補完できるのは「コード」だ。「意図」ではない。
たとえば、次のような状況を想像してほしい。
def process_order(order_id):
# ここで何をすればいい？AIは「それらしい処理」を提案する。データベースを参照し、注文を取得し、ステータスを更新するコードを書く。でも、そのコードが本当にほしいものかどうか、AIには分からない。
- キャンセル後の注文も処理するべきか？
- 在庫チェックはここでやるのか、別の場所でやるのか？
- エラーが起きたときに通知を飛ばすべきか？
これらは「仕様」の問題だ。AIはコードを補完できるが、仕様を決めることはできない。
ツールを比較しても解決しない理由
「CopilotよりCursorの方がいい」「いや最近はWindsurfが優秀だ」という議論をよく見かける。実際に使い比べると差はある。文脈の取り込み方、エディタとの統合具合、モデルの質。
だが、この 比較をしている間は本質に近づかない。
ツールを変えても、仕様があいまいなまま書くコードの質は大して変わらない。
実際に調べてみると、「Copilot 効果なし」「Cursor 期待外れ」という声を持つ人たちのプロジェクトには共通点がある。
- 要件が口頭で共有されている
- 設計ドキュメントが存在しない、または古い
- タスクの粒度が大きい（「ユーザー管理機能を作る」レベル）
逆に「AIコーディングで生産性が3倍になった」という人のプロジェクトはどうか。
- 機能単位で仕様書がある
- 関数レベルでやることが決まっている
- テストケースが先に定義されている
ツールの違いより、この「前提条件」の差の方がずっと大きい。
AIコーディングが活きる3つの前提条件
実際にチームで試してきた経験から、AIコーディングが機能する前提条件を3つに絞れた。
1. タスクが「1画面で理解できる」粒度になっている
「認証機能を実装する」というタスクをそのままAIに渡しても、期待するコードは出てこない。せいぜいサンプルコードのコピーになる。
「メールアドレスとパスワードでログインするAPIエンドポイントを作る。成功時はJWTトークンを返す。失敗時は401を返す」まで分解すると話が変わる。
AIは具体的な指示に対して強い。曖昧な指示に対しては弱い。
2. 「なぜそうするか」がコンテキストとして渡せる
コードを生成するだけなら、指示を出せばいい。だが、チームの文脈に合ったコードを生成するには、コンテキストが必要だ。
- このプロジェクトではどんなアーキテクチャを採用しているか
- この関数は将来どう拡張される予定か
- このコードを読む人は誰か（ジュニア？シニア？）
これを毎回プロンプトで渡すのは現実的ではない。仕様書やREADMEにこの情報が書かれていれば、AIがそれを参照してコードを生成できる。
Cursorの「@docs」機能や、Copilotのワークスペースコンテキスト機能が便利なのはここだ。だが、そもそもドキュメントがなければ意味がない。
3. テストケースが先に書かれている
「テスト駆動開発（TDD）は知っているけど現場ではやりにくい」という声をよく聞く。ところが、AIコーディングとTDDの相性は非常 に良い。
テストケースをまず書くと、AIは「このテストをパスするコードを書く」というタスクを受け取れる。これは具体的だ。
def test_process_order_cancelled():
# キャンセル済みの注文を処理しようとした場合、
# OrderCancelledExceptionを投げること
with pytest.raises(OrderCancelledException):
process_order("cancelled-order-123")このテストがあれば、AIが生成するコードの品質は格段に上がる。「それらしい処理」ではなく「このテストをパスする処理」を目指すからだ。
仕様駆動開発（SDD）との接続
上の3条件を整理すると、共通するキーワードが見えてくる。「仕様」だ。
- タスクが小さい → 仕様が細かく定義されている
- コンテキストが渡せる → 仕様書が存在する
- テストが先にある → 仕様が検証可能な形で書かれている
これはまさに仕様駆動開発（Specification-Driven Development, SDD）の考え方だ。
SDDは「コードを書く前に仕様を書く」というシンプルな原則を持つ。その仕様をAIが読める形で書いておくことで、AIコーディングの精度が飛躍的に上がる。
「仕様書を書く → AIがコードを生成する → レビューして修正する」
このサイクルが回ると、AIはコードの補完者ではなく、仕様を実装する実行者になる。役割が変わる。
詳しくは「仕様駆動開発（SDD）完全ガイド」にまとめているが、エッセンスを一言で言えば「AIに渡す前に、人間が仕様を整理する」だ。
実際に導入するとどう変わるか
あるチームで試した話をする。
GitHub Copilotを導入していたが、「コードが速く書けるようになった感じはするが、バグが減った感じはしない」という声が多かった。
試しに、新機能の開発前に仕様書を1枚書くルールにした。Markdownで、以下を記載する。
- この機能は何のために存在するか（目的）
- どんな入力を受け取り、どんな出力を返すか（I/O仕様）
- エッジケースと例外処理（境界条件）
- 既存機能との関係（依存関係）
これをプロンプトに含めてコード生成すると、「それらしいコード」ではなく「仕様通りのコード」が出てくるようになった。
レビューも変わった 。「コードが読めない」から「仕様と比べて正しいか」という視点になる。これは圧倒的に速い。
ツール選びより先にやること
GitHub CopilotとCursor、どちらが優れているかという議論に結論はない。両方試して自分たちに合う方を選べばいい。
だが、そのどちらを選ぶにせよ、先にやるべきことがある。
仕様の書き方を決める。
タスクをどこまで分割するか。何を仕様書に書くか。誰がレビューするか。このプロセスを整備すれば、AIコーディングツールはその次の話になる。
逆に言えば、これを整備しないままどんなに良いツールを入れても、「期待ほど生産性が上がらない」感覚は変わらない。
AIはコードを補完する。仕様は人間が書く。その役割分担を明確にすることが、AI時代の開発プロセスの核心だ。
もし「うちのチームでどこから始めるか」を一緒に考えたい場合は、お問い合わせからご連絡ください。私たちは要件定義から設計・開発まで、AIネイティブな形で伴走します。
