AI時代の開発には結局、何が必要なのか——浮かれている場合ですか？
What AI Actually Changes in Development — Notes from Two Small Builds
著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info)
1. コードを書く時間は、開発時間ではない
Claude Codeを入れて、日常の小さな不便を潰すためのJavaScriptアプリを2本作った。
どちらもシングルファイルで完結する規模で、大規模システムの話ではない。
せっかくなので、開発開始から実装完了まで、どの工程に何分かかったかを記録してみた。Claude Codeの性能を測るためではなく、自分が開発工程のどこで時間を使っているかを見るためである。
一番はっきりしたのは、コードを書いている時間は驚くほど(いや驚かないか)短かったこと。
そして、開発全体の時間は、同じ割合では短くならなかったことだった。
2. 1本目：ブログ管理画面のUserScript
作ったもの
ブログの管理画面に、予約投稿の埋まり具合と次の推奨投稿日を表示するUserScript。自分のブログ運用の都合だけで必要になった、ごく小さいものである。
工程の記録
11:06 開発開始
11:09 仕様調査
11:16 仕様まとめ
11:17 Claude Code向けプロンプトまとめ
11:23 選択肢確認終了
11:27 Plan出力完了
11:29 Plan修正・Approve
11:39 Claude Code実装完了
11:43 Tampermonkey導入・動作確認
総時間37分。うち実装は10分。
何に時間を使ったか
実装前に決めていたのは、こういうことだった。
- ブログのDOMを読むか、APIを叩くか
- scheduled状態の投稿だけを対象にしてよいか
- 推奨日は月水金でよいか
- 今日を候補日に含めるか
- タイムゾーンをどう扱うか
- 月表示のフォーマット
- スクリプトを動かす対象ドメイン
どれも技術的な難所ではない。ただ、決めないと一行も書けない。「どう書くか」ではなく、この「何を作るか」の側に時間が寄っていた。
3. 2本目：小さなJSアプリ
比較のために、同じ規模のシングルファイルJSアプリをもう1本作った。機能の中身は本題ではないので省く。
9:25 要件定義・仕様調査
9:29 要件・仕様まとめ
9:34 Claudeからの仕様フィードバック対応
9:42 Plan完了
9:46 修正・レビュー完了
9:49 実装完了
総時間24分。うち実装は3分。
24分の開発のうち、コードが生成されていたのは3分である。
4. 工程別に並べてみる
1分を1ブロックとして、工程別に並べるとこうなる。
1本目（37分）
仕様調査・整理 ███████████ 11分
選択肢の確認 ██████ 6分
Plan作成・レビュー ██████ 6分
実装 ██████████ 10分
動作確認 ████ 4分
2本目（24分）
要件・仕様 ████ 4分
仕様フィードバック █████ 5分
Plan作成 ████████ 8分
Plan修正・レビュー ████ 4分
実装 ███ 3分
2つ目のアプリは、慣れていたこともあってか、24分の開発でコードを書いていた(=実装)のは3分だった。
5. 実装時間は「平準化」しやすい
この規模のアプリに限れば、コードを書く時間そのものはかなり圧縮された。
従来なら、実装速度、ライブラリの知識、細かい文法の記憶といったところで人による差が出ていた。DOM APIの引数を思い出せるか、正規表現を一発で書けるか、そういう差である。この層はAIがかなり埋める。
少なくとも今回の自分の作業では、従来なら実装に使っていたはずの時間が大幅に圧縮された。一般にどこまで実装速度の個人差が縮むかは別途検証が必要だが、AIがこの層を強く補助することは実感できる。
ただし、そこから「エンジニアの差が消える」まで進むのは早すぎるだろう。
6. 時間を使っていたのは「判断の側」
記録を見返すと、時間を食っていたのはこちらである。
- 何を作るか決める
- 何を作らないか決める
- 現状を調査する
- DOMかAPIかを判断する
- 仕様の曖昧さを潰す
- AIからの質問に答える
- Planをレビューする
- 不自然な設計に気づく
- 動かして確認する
- 必要なら直す
これらはAIに投げても消えない。仕様の曖昧さを潰すには、何が曖昧かを自分で認識している必要がある。Planをレビューするには、その設計でよいかを判断できる必要がある。AIからの確認質問に答えるにも、答えを持っていなければならない。
実装が速くなるほど、この前後工程の質が、そのまま開発全体の質になる。
7. 能力差の出る場所が移る
AIによって「書けるかどうか」の差は縮む。一方で、「何を書くべきか」「その設計でよいか」「出てきた結果を信用してよいか」の差は残る。
AIが能力差を消しているというより、能力差が現れる場所が「実装」から「判断」へ移った、という整理のほうが実測に合う。
同じツールを渡されて、同じ時間で同じ品質のものが出てくるわけではない。出てくるものの差は、プロンプトの巧拙よりも、その前に何をどこまで決められたかで決まっていた。
8. 「間違い」も同じ速度で実装される
AIは、正しいものだけを速く作るわけではない。
曖昧な要件、間違った前提、要らない機能、筋の悪い設計。これらも同じ速度で実装される。しかも、それなりに動く形で出てくるので、間違っていることに気づきにくい。
1本目でDOMを読むかAPIを叩くかを最初に決めたのは、ここを間違えたまま10分で実装が終わってしまうと、その10分がそのまま無駄になるからである。そして悲しいかな、実装が速いほど、誤った前提が形になるまでの時間も短い。
実装速度が上がったから要件定義とレビューが軽くなる、という順番にはならない。むしろ、前工程で間違えたときの取り返しが早くなる分だけ、前工程を雑にやる余地が減るのである。
9. 小規模開発で速く作れることと、大規模開発が回ることは別問題
今回の2例は、どちらもシングルファイルで完結するものだ。この規模なら、仕様の大半を一人で把握できるし、依存関係も少ない。変更範囲は狭く、動作確認も一人で終わる。AIに渡すコンテキストも小さい。Claude Codeの強みが出やすい条件が、最初から揃っている。
人数と規模が増えると、時間の配分は別のところへ移る。
- どこで機能境界を切るか
- 誰がどの範囲を担当するか
- チーム間のAPI・データ契約をどう定義するか
- どこまで変更してよいか
- 仕様変更をどう同期するか
- 複数のAI生成物を誰が統合判断するか
- どのコンテキストを、どの担当AIに渡すか
このあたりは、コードが書けるかどうかとは関係がない。責任分界と設計の問題である。
前の章で書いたことは、人数が増えるとそのまま拡大する。前提が間違ったまま各担当の実装速度だけが上がれば、その誤りは複数のチームで同時に具体化されるのである。境界の切り方を間違えた場合、気づくのは統合の段階で、そのときには各チームが誤った前提の上に何日分かを積み上げている。
Claude Codeの実装の速さだけを見てはしゃいでいると、この辺りを簡単に見落とす。小規模開発でうまくいったという体感を、そのまま大規模開発へ持っていかないほうがいい。
今回の実測で見えたのは、一人分の実装が速くなることまでである。小さな開発を速く作れることと、大きな開発を正しく分割できることは、別の能力なのである。
10. AI時代に必要になるもの
今回の2本から言えることに限れば、必要なのはこのあたりだと思う。
- 問題を小さく切る力
- 仕様を言語化する力
- 責任範囲を分ける力
- AIに必要な文脈だけを渡す力
- Planをレビューする力
- 動作結果を疑う力
- 使えるかどうかを判断する力
小規模なアプリでもこれだけ必要になる。規模が大きくなれば、実装範囲とコンテキストをどう分割するかの比重がさらに上がるはずだ。
巨大なタスクを丸ごと渡すより、責任境界を切って渡したほうが、結局は速い。
これは新しい能力ではない。設計とレビューという、前からある仕事である。それが工程全体に占める割合が上がった。
11. 今回わかったこと
少なくとも今回の実測では、コードを書く時間は開発時間のごく一部になった。そして仕様調査、要件定義、Planのレビュー、動作確認は、そのまま残った。
コードを書く速度は平準化される。だが、考える速度まで平準化されるわけではない。浮かれている場合ではないのである。
☕️よかったらコーヒー一杯。 https://buymeacoffee.com/mink_obs
著：霧星礼知(min.k) / リサーチ・構造支援：Claude Sonnet 4.6、ChatGPT / AI-assisted / Structure observation
For international readers
I built two small single-file JavaScript apps with Claude Code and logged how long each phase took. The first took 37 minutes, with 10 minutes of actual implementation. The second took 24 minutes, with 3 minutes of implementation — 12.5% of the total. Everything else went into deciding what to build: DOM versus API, scope, time zones, answering the model's clarifying questions, reviewing the plan, and verifying the result. Coding speed, the skill that used to separate developers, is the part AI levels most easily. What it does not level is knowing what should be built, whether the design holds, and whether the output can be trusted. AI also implements wrong requirements at the same speed as right ones, which raises the cost of a sloppy specification rather than lowering it. And none of this generalizes cleanly to large team projects: when everyone's implementation gets faster, a badly drawn boundary or a wrong shared assumption gets built out by several teams at once. Building something small quickly and splitting something large correctly are different skills. Implementation speed converges. Thinking speed does not.
Keywords
AI-assisted development, Claude Code, software engineering skills, requirements definition, design review, boundary design, large-scale development, developer productivity, time measurement, engineering judgment
AI開発, Claude Code, 実測, 要件定義, 設計レビュー, 責任分界, 大規模開発, 開発生産性, エンジニアの技量, 工程分析