PF-005

AIに自由にやらせないほど、開発は速くなった — SaaSを1年回した実測

上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。

結論

• AIに「制約」を増やすほど、開発は速くなりました。手数は増えたのに、です。
• 理由はひとつ。やり直しが減ったからです。速さを食っていたのは手数ではなく、バグの出戻りでした。
• そして、やり直しが減るということは、そのまま私の時間が増えるということです。
• 直近4か月の月別コミットは 349 → 256 → 482 → 898。制約を一番増やした月が、一番コミットの多い月でした。
• 効いた制約は5つ。仕様を先に固定する / 作業場所をタスクごとに分ける / AIに「完了」を自己申告させない / 別系統のAIでレビューする / 失敗を仕組みに落とす。
• 数字はすべて、2026年7月30日 00:48 のスナップショット時点のものです。ここから先は「なぜそうなるのか」の話です。

本文(読了 約3分)

私がClaude Codeを本格的に使い始めたのは、2025年7月です。今は、20を超えるプロダクトを1人で同時に開発・運用しています。この記事で例に使うのは、その中で一番コミットも記録も多いPrompt Flow Studioです。複数のAIを1つのワークフローにまとめるSaaSで、この1年、数字をこのプロダクトにそろえて計測してきました。私の役割も、実装を自分の手で書く役から、仕様を決め、判断し、レビューし、リリースの可否を決め、失敗を仕組みに落とす役へ変わりました。

手数を増やしたのに速くなった理由

制約を増やすと、レビューや確認の手数は確実に増えます。それでもコミットは減らず、むしろ増えました。

実際に時間を食っていたのは、手数ではなくやり直しでした。AIに任せきりにすると、「できました」→動かない→直させる→「直しました」→まだ違う、という往復が起きます。この往復が、1つのコミットにたどり着くまでの時間を一番食っていました。

制約を増やすことは、この往復を先回りで潰す作業です。仕様を先に固定すれば方向違いのやり直しが減り、「完了」を自己申告させなければ、動かないものを完了扱いにして後で戻る事故が減ります。手数は増えても、やり直しを1回止めるたびに前へ進む。手数の増加より出戻りの減少のほうが大きく、差し引きで速くなりました。

数字の前提

数字はすべて、2026年7月30日 00:48 のスナップショット(コミット a59ddf0a)時点の値です。この時点で、設計判断の記録(ADR)は0001から0080までの80本、マージされたプルリクエストは307件でした。

コミット数は author-date で月ごとに集計しています。記録ツールの観測開始は2026年4月16日で、それ以前のコミット履歴とは分母が異なるため、直近4か月分のみ載せます。

月	コミット(author-date)	セッション
2026-04	349	27
2026-05	256	10
2026-06	482	84
2026-07	898	244

増やした5つの制約

7月に効いた制約は、5つあります。

1. 仕様を先に固定する。 技術判断はADR、基本設計と詳細設計はそれぞれの文書へ分けました。判断の置き場を決めることで、同じ迷いを二度計算しないようにしました。

2. 作業場所をタスクごとに分ける。 タスクごとに場所を分けると、失敗した試行はまるごと捨てられ、別のタスクの成果を巻き戻さずに済みます。

3. AIに「完了」を自己申告させない。 作業をタスクID・PR・仕様・検証ログにつなげ、完了の条件を人間が追える形にしました。

4. 別系統のAIでレビューする。 CodeRabbitの指摘を0件まで回し、必要ならCodexやClaude Codeで観点を変えて突き合わせました。同じAIでは見逃す穴も、別系統に通すと見つかります。

5. 失敗を仕組みに落とす。 事故が起きたら反省文では終わらせず、skill・hook・検証ルール・台帳のどれかに落とし、次のAIセッションが同じ失敗をしにくい形にしました。

一番効いた失敗:「162件グリーン」の誤完了

制約を一番増やすきっかけは、2026年6月29日のモバイルの誤完了事件です。モバイルアプリが「テスト162件グリーン」と報告してきましたが、実機に入れると主要な動線が壊れていました。原因は、全部モックした単体テストのグリーンを「動くアプリ」の証拠として扱っていたことです。

この事件から、完了の条件を「テスト数」ではなく「境界を通した証拠」に置き換えました。実機で動かすまで完了とは呼びません。1タスク単体では遅くなる変更ですが、誤完了の修正・再調査・再発を減らした結果、月全体では速くなりました。

導入する前と、した後

制約を入れる前は、AIの出力を後から読んで怪しいところを直す流れで、何を根拠に「完了」としたかが曖昧になりがちでした。入れた後は、ADRがなければ判断を増やさない、根拠がなければ数字を書かない、実機で通っていなければ完了にしない、というように作業の入口と出口を先に決めるようになりました。

この考え方は、仕様の先固定・作業場所の分離・レビュー0件ゲート・失敗のskill化として、他のプロダクトにも一部そのまま移せました。一方、マルチLLMやクレジット課金のような、このSaaS固有の設計もあり、そこまで一般化はしません。

この数字が証明しないこと

サンプルは1プロダクト、開発者は私ひとりで、AI開発の一般法則を証明する数字ではありません。7月に加速した理由も、制約だけに帰すことはできず、プロダクト理解の深化や作業時間の増加なども影響しています。

私の観測した範囲で言えるのは、制約を増やすことと速度が落ちることは同時には起きなかった、ということです。むしろ誤完了と手戻りを減らしたことで、1か月あたりの前進量は増えました。

まとめ

速度の敵は制約ではなく、証拠のない完了宣言、分母のない数字、再利用できない反省、作業の境界が曖昧なことです。制約を増やすのは、AIを縛るためではなく、任せきりにして出戻るより先に条件を決めておくほうが、結局は速く、時間も残るためでした。

筆者について

上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。