「AIに任せる開発なんて無理」と思っていた頃の自分
少し前まで、私は「AIにコードを書かせる」という発想にどこか冷めていた。
エンジニアの周りでもよく聞こえてきた声がある。「結局、手直しに時間がかかって意味ないよ」「巨大すぎるPRはレビュー不能になる」「AIが書いたコードは既存のアーキテクチャと噛み合わない」。
私自身も、同じ経験を何度かしていた。期待してAIに任せたら、出てきたのは何かが少しずつズレた実装。修正に時間を吸われ、最初から自分で書いた方が早かったのではないかと感じる瞬間が積み重なった。
「AIに任せる開発なんて無理」——そう結論しかけていた時期が、確かにあった。
この記事は、そう思っていた私がなぜ考え方を変えたのか、何を発見したのか、を振り返るものだ。
期待してガッカリした、最初のAIコーディング
最初に強くガッカリしたのは、ちょっとした機能追加をAIに任せた時のことだ。
「ログイン機能を作って」とだけ伝えて投げた結果、戻ってきたコードは見るに堪えないものだった。既存のミドルウェアを無視した独自実装。エラーレスポンスは社内規約と異なる形式。プロジェクト全体のディレクトリ慣習も完全にスルー。
レビューに入ろうとしたものの、変更ファイル数があまりに多く、どこから手を付ければよいか分からない。「なぜここはこう実装したのか」を問いただす相手もいない。一度AIにやり直させても、また別の角度でズレて返ってくる。
このサイクルが2、3度回った時、正直「もう自分で書いた方が速い」と感じた。
ここで私は「AIは信用できない」という結論に進みかけた。多くのエンジニアが同じ場所で立ち止まっていたのだろうと思う。
同じAIが、別人のように動いた瞬間
転機は、別のプロジェクトでスコープの絞り方を変えてみた時に訪れた。
「認証機能を実装して」ではなく、こう書いた。
Issue #42: JWTトークン検証ミドルウェアの実装
受け入れ基準:
- Authorizationヘッダーから Bearer トークンを抽出
- トークンの署名検証と有効期限チェック
- 検証失敗時は 401 を返す
制約:
- 既存の authMiddleware.ts を拡張
- エラーレスポンスは errors/auth.ts の形式に従う
たったこれだけのIssueを書いてAIに渡した。返ってきたコードは、別人のように整っていた。既存ミドルウェアを正しく拡張し、規約通りのエラー形式で 401 を返し、テストまで書かれていた。
同じAIだ。違ったのは「私たちの渡し方」だけだった。
AIが推測する余地を残せば、AIは推測でズレる。推測の余地をなくせば、AIは仕様通りに動く。当たり前の話のはずなのに、最初に体感した時は静かな驚きがあった。
問題はAIの能力ではなく、私たちが渡している入力の解像度だった。
仮説を検証した — 数字で見えた手応え
「仕様の解像度が、AIの精度を決める」という仮説を持って、自社のSaaSプロダクトで本格的に試した。
題材に選んだのは、RAGチャットボットの機能実装フェーズだ。Issue駆動で、AIエージェントに開発を任せる体制を組んだ。
計測結果はこうなった。
- コード生産性: 業界平均（50〜200行/日）の 115〜460倍
- PRマージ率: 98%（321件中315件）
- コードレビュー工数: 97%削減（人間が担当したのは全体の3.3%のみ）
詳しい背景は別途レポート（AI駆動開発レポート）にまとめてある。
ここで強調したいのは「AIが速い」ということではない。私が伝えたいのは、仕様が整っていれば、AIは速く・正確に動ける ということだ。
そして、数字以上に重要だったのは、品質を落とさずにこれを実現したという事実だった。PRの98%がそのままマージされる状態は、書き散らしのコードを大量に生成しているのとは全く意味が違う。
仮説が「数字で見える形」になった時、これは方法論として残せる、と確信した。
個人技から、組織で再現できる手順へ
ここから先は、個人の発見を組織の手順に変えていく仕事だった。
「自分はできる」と「チームができる」は別問題だ。私が直感で書いていたIssueの粒度を、誰もが書ける形に分解する必要があった。
試行錯誤を経て、開発タスクを次の4階層で構造化することに落ち着いた。
- Epic: ビジネス課題の単位
- User Story: ユーザーの視点から見た価値
- Use Case: 具体的な振る舞いの単位
- Scenario: AIが迷わない受け入れ基準
これだけでも、AIに渡せる仕様の解像度は劇的に変わる。
加えて必要だったのは、レビュー指摘をその場で消費させず、ナレッジに変える仕組みだった。「同じ指摘を何度も受ける」状態を放置すると、AIは学習しない。指摘を仕組み化して、次回からは事前に防げる形に落とす——この反復が、出力品質を継続的に押し上げる。
仕様を「生きた成果物」として扱うこと。スコープを絞ること。70%の完成度でPRを出し、レビューで収束させること。指摘をナレッジに変えること。
これらを統合して、自社外のクライアントにも移植できる形にしたものが、いま私たちが「AI仕様駆動開発」と呼んでいるメソドロジーだ。フィールフロウのAI仕様駆動開発ページでは、その全体像と方法論をまとめている。
魔法のプロンプトではなく、仕様というOS
ここまで振り返って、結局のところ核にあるのはひとつの認識だ。
AIに任せるために必要なのは、「魔法のプロンプト」ではなく「仕様というOS」だ。
AIコーディングツールは、入力が曖昧なら曖昧な出力を返す。入力が明確なら、明確な出力を返す。これはAIの限界ではなく、AIが従う原則そのものだ。
「AIに任せる開発なんて無理」と思っていた頃の私と、いまの私の間に起きた変化は、AIに対する期待の方ではない。AIに何を渡しているか、への自覚の方だ。
最後に、この記事を読んでくれた方への問いを残したい。
今あなたがAIに渡している「仕様」は、AIが迷わない解像度になっているか？
もし答えが「No」に近いと感じるなら、次にAIに何かを任せる時、ひとつだけ試してみてほしい。受け入れ基準を3つ、制約を2つ、明文化してから依頼する。それだけで、戻ってくるコードの質は驚くほど変わる。
「AIに任せる開発なんて無理」を、「AIに任せたら、本当に楽になった」に。
そこまでの距離は、思っているより近い。