結論から言う。「速く書ける」と「速く終わる」は別の話だ

AIを使えばコードは100倍速く書ける。これは誇張ではない。GitHub Copilotの調査では、開発者のタスク完了速度が最大55%向上したと報告されている。Google DeepMindのAlphaCodeは、競技プログラミングで上位54%に入る。コードを「生成する」速度だけ見れば、人間が太刀打ちできる領域はどんどん狭くなっている。

では問いたい。あなたの会社の開発は、速くなっただろうか？

YCombinator（米国の著名アクセラレーター）のCEO、Garry Tanは最近こう指摘した。「AIで書かれたコードの量は爆発的に増えたが、出荷されるプロダクトの質は比例して上がっていない」と。GitClearの調査はさらに厳しい。2023年、AIアシスト導入後のリポジトリでは「コードの変更量」が増加した一方、「コードの移動・削除」——つまり手直しの割合も急増している。書いては直し、直しては書く。これでは速くなったのか遅くなったのか分からない。

100倍速く書けるのに、成果が100倍にならない。この構造的な溝の正体を、中小企業の現場目線で掘り下げる。

—

「Tokenmaxxing」——大量生成が生む逆効果

最近、開発者の間で「Tokenmaxxing」という言葉が広がっている。AIに大量のトークン（コードの単位）を吐かせて、とにかく量で押す開発スタイルのことだ。

これが何を引き起こすか。具体的に見てみよう。

ある受託開発の現場で、AIにAPIの接続コードを書かせた。10秒で200行のコードが出てきた。人間が書けば2〜3時間かかる量だ。しかし、そのコードにはエラーハンドリングの抜け、不要なライブラリの呼び出し、セキュリティ上の問題が含まれていた。結果、レビューと修正に4時間かかった。手で書いた方が速かったかもしれない。

GitClearのデータによれば、AI導入後のプロジェクトでは「追加されたコード行数」が前年比で大幅に増えた一方、「リファクタリング（書き直し）の比率」も増加傾向にある。つまり、生成は速いが、手直しが増えた分だけ相殺されている。

これは中小企業にとって特に痛い。大企業なら専任のコードレビューチームがいる。しかし5人、10人の開発チームでは、AIが吐き出したコードを精査する人的リソースがそもそもない。結果として「AIが書いたコードをそのまま使う」か「AIを使わず手で書く」の二択に陥る。どちらも最適解ではない。

—

コードの速度とプロダクトの速度は違う

もう一つ、根本的な話をしたい。

ソフトウェア開発において「コードを書く時間」が全体に占める割合は、実はそれほど大きくない。Microsoft Researchの調査では、開発者がコードを書いている時間は業務時間の約30〜40%に過ぎない。残りは何か。要件定義、設計、レビュー、テスト、デバッグ、コミュニケーション。つまり「何を作るか決める」と「作ったものが正しいか確認する」に大半の時間が使われている。

AIが100倍速くしたのは、この30〜40%の中のさらに一部だ。全体のボトルネックはそこではなかったりする。

例えるなら、こういうことだ。料理で一番時間がかかるのは「何を作るか決める」「材料を買いに行く」「盛り付ける」であって、「包丁で切る」速度が100倍になっても、夕食が100倍速く出てくるわけがない。

中小企業の開発現場で本当にボトルネックになっているのは何か。多くの場合、こうだ。

• 「何を作ればいいか」が決まらない（要件の曖昧さ）
• 作ったものの良し悪しを判断できる人がいない（レビュー体制の不在）
• 仕様変更が頻発する（意思決定の遅さ）

ここにAIコード生成を突っ込んでも、速くなるのは「書く」だけ。前後の工程が詰まっていれば、全体のスループットは変わらない。これがTOC（制約理論）でいう「ボトルネック以外を改善しても全体は速くならない」という原則そのものだ。

—

デザインと設計——AIが踏み込めない領域

もう一つ見落とされがちな問題がある。AIが生成するのは「コード」であって「設計」ではないということだ。

ここでいう設計とは、データベースの構造、APIの設計思想、画面遷移のロジック、エラー時のユーザー体験など、「ユーザーにとってどう動くべきか」を決める部分だ。

AIは「こう書いて」と言えばコードを出す。しかし「この業務フローにとって最適なデータ構造は何か」「このユーザーは次に何をしたいか」という問いには、まだ十分に答えられない。

ある地方の製造業向けSaaSを開発している会社の話が象徴的だ。AIを使って管理画面を高速に構築した。見た目はそれなりに整っている。しかし、現場の作業者がタブレットで使うことを想定していなかった。ボタンが小さすぎる、入力ステップが多すぎる、エラーメッセージが技術者向け。結果、現場から「使いにくい」と突き返された。作り直しに2週間。AIで3日で作ったものを、2週間かけて直す。これが現実だ。

速く作れることと、正しいものを作れることは、まったく別の能力だ。

—

では、中小企業はどうすればいいのか

抽象的な「AIと人間の協力が大事です」では何も変わらない。具体的に3つ、今日からできることを提案する。

1. AIを使う工程を絞る

全部をAIに任せようとするから破綻する。AIが得意なのは「パターンが決まっている定型コード」だ。CRUD（データの作成・読み取り・更新・削除）処理、バリデーション、テストコードの雛形。ここにAIを集中投下する。

逆に、ビジネスロジックの核心部分、セキュリティに関わる部分、データ設計は人間がやる。この切り分けを明確にするだけで、手直しの工数は激減する。

ある受託開発会社では、この切り分けを導入した結果、AI生成コードの手直し率が約60%から15%に下がったという。AIに任せる範囲を狭めた方が、結果的に全体は速くなる。逆説的だが、これが現場のリアルだ。

2. 「レビューできる人」を育てる

中小企業で最も不足しているのは「AIが出したコードの良し悪しを判断できる人材」だ。コードを書く能力より、コードを読んで判断する能力の方が、AI時代には価値が上がる。

これは高度なスキルに聞こえるが、実はそうでもない。チェックリスト化できる。「セキュリティホールがないか」「不要な依存ライブラリがないか」「エラーハンドリングは適切か」「命名規則は統一されているか」。この4項目だけでも、レビューの質は大幅に上がる。

月額数千円のAIコードレビューツール（CodeRabbit等）を併用すれば、人間のレビュー負荷もさらに下がる。5人のチームなら、月1〜2万円の投資で手直し工数が半減する可能性がある。

3. 「何を作るか」に時間を使う

AIがコードを書く時間を圧縮してくれた分、浮いた時間をどこに使うか。答えは「要件定義」と「ユーザーヒアリング」だ。

中小企業の強みは、顧客との距離が近いことだ。大企業のように何層もの組織を通さず、直接ユーザーの声を聞ける。この強みを活かして「何を作るべきか」の精度を上げれば、手戻りが減る。手戻りが減れば、AIの速度がそのまま成果に変換される。

AIで浮いた時間を「もっとコードを書く」に使うのではなく、「正しいものを定義する」に使う。これが、速さを成果に変える唯一の方法だ。

—

構造を理解すれば、中小企業にこそチャンスがある

最後に、一つ希望のある話をしたい。

この「速さと成果のギャップ」は、大企業ほど深刻になる。なぜか。組織が大きいほど、コードを書く以外の工程——承認、調整、会議——が肥大化しているからだ。AIでコード生成が速くなっても、承認に2週間かかるなら意味がない。

一方、中小企業は意思決定が速い。社長が「これでいこう」と言えば、翌日には動ける。AIの速度を活かせる組織構造を、すでに持っている。

つまり、AIの恩恵を最大化できるのは、実は中小企業の方だ。ただし、条件がある。「何を作るか」を正しく決められること。そして、AIの出力を判断できる目を持つこと。この2つさえ揃えば、大企業が会議をしている間に、中小企業はプロダクトを出荷できる。

AIは「書く」コストを限りなくゼロに近づけた。だからこそ、「何を書くか」の価値が爆上がりしている。この構造変化に気づいた中小企業から、勝ち始める。

—