AI が昼前に書いても完了は 4 日 — 見積もるのは人の確認の時間

なぜ、昼前に書けた仕事が 4 日かかったの?

川口氏は、YesNoBut の共同創業者で、Agilergo のシニアアジャイルコーチです。アジャイルコーチは、短い周期で作っては確かめる開発の進め方(アジャイル)を、現場に指導する仕事です。

きっかけは、X でのある開発者の問いかけでした。AI で実装すると、作業の見積もりが全部いちばん小さい点数になってしまう。皆はどうしているのか、という声です。川口氏はこれに、英語の記事の要約で応えました。

元の記事は、Sujit Kamthe 氏が 2026 年 8 月 7 日に Towards AI で公開したものです。Kamthe 氏自身の体験と、そこから組み立てた提案が書かれています。

Kamthe 氏のチームは、ある作業の点数を 5 にするか 8 にするかで 20 分議論しました。その後、開発者が AI の Claude に任せると、昼前には動くものができました。

それでも、完了までは 4 日かかりました。変更が 3 つのサービスにまたがり、大きな変更点を 2 人で丁寧に確認する必要があったためです。既存の機能が壊れていないかを確かめるテスト(回帰テスト)と、セキュリティの承認も必要でした。

Kamthe 氏の結論は明快です。見積もりが間違っていたのではなく、もう費用のかからないものを測っていた、というものです。

見積もりは、なぜ大きくも小さくも外れるの?

川口氏の要約は、点数による見積もりが 20 年機能してきた理由を、一文で言い当てています。書く作業が大半を占め、複雑なプログラムほど時間もかかる、という暗黙の前提があったからです。

Kamthe 氏は、これを飛行機の旅にたとえています。AI は超音速のジェット機で、プログラムを書く時間は飛行時間です。点数は飛行時間を見積もりますが、チームが実際に払うのは、空港での手続きを含む旅の全体です。

その結果、見積もりは両方向に外れます。

何を見積もれば、納期が読めるの?

Kamthe 氏の提案の原則は、「AI が消せない仕事を見積もる」です。川口氏は、その中身を 5 つの要素に分けて紹介しています。

• あいまいな作業には点数を付けない。AI が人に追加の質問をせずに始められる状態を、着手の条件にする
• 大きさは小・中・大の 3 段階だけにする。問いは「人の集中を、最初から最後までどれだけ使うか」の 1 つ
• 確認待ち、テスト待ちの件数に上限を置く(WIP 制限)
• 大きな節目は、過去の実績から何通りも試算し、確からしさを添えて伝える(モンテカルロ法)
• プログラム一式を読める AI に、影響の範囲を下調べさせる。人は見積もりを点検する側に回る

Kamthe 氏が、自分の経験でいちばん効いたとするのは 3 つ目の上限です。エリヤフ・ゴールドラット氏の制約理論を、開発の現場に当てはめたものだと説明しています。

節目の伝え方も変わります。「50% の確からしさで 3 月 3 日、85% で 3 月 24 日」のように、幅を持たせて伝えます。この日付は言い方の例です。予測の方法そのものは、10 年にわたって現場で使われてきたものだといいます。

大きな調査でも、同じことが起きているの?

体験談と同じ向きの数字もあります。Kamthe 氏の記事も引いている、Faros AI の調査です。2025 年 7 月 23 日に公開され、1 万人を超える開発者と 1,255 のチームの記録を分析しています。

書く量は増え、確認にかかる時間も増えました。Faros AI は、AI の利用と会社全体の成果とのあいだに、意味のある相関は見られなかったと報告しています。

この見積もり方は、いつまで使えるの?

Kamthe 氏は、この枠組みに期限があることを自分で認めています。確認やテストも AI が引き受けるようになれば、見積もる対象はまた移ります。次はおそらく、要求の整理、設計、事業の判断だとしています。

残る原則は 1 つです。昨日の詰まりではなく、今の詰まりを見積もる、というものです。川口氏の要約は、この但し書きまで拾って締めています。一時の手法としてではなく、考え方として持ち帰れる形になっています。

SYNCON の視点 — 日本の非エンジニア経営層は何を盗むべきか

盗むべきは、「どこが速くなったか」ではなく「どこで待っているか」を聞く習慣です。AI を入れても納期が縮まらないとき、書く速さを疑っても答えは出ません。月曜の会議では、確認待ち、承認待ちの案件がいま何件あるかを尋ねてみます。件数が積み上がっている所が、次に手を入れる場所です。

外注先との会話にも使えます。見積もりを受け取ったら、書く作業と、確認・テスト・承認の内訳を分けて聞きます。納期は 1 つの日付ではなく、確からしさを添えて出してもらいます。AI で縮む部分と縮まない部分が分かれば、発注する側が急ぐべき承認も見えてきます。

要点まとめ

• 20 分議論した作業を Claude が昼前に実装したが、完了まで 4 日かかった
• 時間を使ったのは、3 つのサービスにまたがる確認、テスト、セキュリティの承認
• 点数による見積もりは、「書く部分にいちばん時間がかかる」という前提に立っていた
• Kamthe 氏の提案は「AI が消せない仕事を見積もる」。確認待ちの件数に上限を置くことが柱
• Faros AI の調査では、AI をよく使うチームで変更の確認にかかる時間が 91% 増えた
• 原則は、昨日の詰まりではなく今の詰まりを見積もること