AI エージェントに開発をやらせたら、開発工程は95.5%削減・案件全体では60〜70%削減と予測

はじめに

自作の銀行系システムの開発を進める中で、WBS（作業分解構成図。工程を個々のタスクまで分解した進行管理表）の見積り列に、もう1列足した。名前は「AI実績」。タスクを実際にAIエージェントへ実行させたあと、かかった時間をそのタスクの行に書き込む専用列である。

見積りを立てるだけの表を、実測値と突き合わせられる表に変えた。この記事は、その表からどんな数字が出たか、その数字は何を意味していて何を意味していないか、そして数字を出す途中で自分が何を間違えたかを書く。

見積り表に、実測を書き込む列を1つ足した

このWBSにはもともと2つの見積り列があった。「人間実施予想」（人間のSEが専従で行った場合の、伝統的な人日見積り）と「AI実施予想」。ここに3列目の「AI実績」を足した。WBSに書いた記入規律はこうなっている。

AI実績: 実際にタスクを実行した後に追記する専用列。先に埋めない・実施前の予想値を書き換えない（予想と実績を混同しないための規律）。本 WBS は「予想→実施→実績記録」の追記専用ログとして機能する。

担当列も人名ではない。実装を担う rag-coder、検証を担う rag-reviewer / test-reviewer、テストコードを書く test-coder といったカスタムサブエージェント名が入る。誰にどう役割を分けているかは、この記事では説明し直さず、以下の記事に委譲する。

総合配信プラットフォームと銀行を、並行で作る — AIエージェントの「編成」に実機能を実装させ、実測で分業をチューニングした記録

WBS原文にはこうも書いてある。「人間（本人）が行うのは最終承認・環境構築・実走確認のみ」。つまりAI実績列に入る時間は、タスクをエージェントが実行していた時間そのものであって、私がその結果を見て判断する時間は含まれない（この点は後段の§で数字の読み方として改めて書く）。

実績は1タスク終えるごとに、独立したコミットで追記している。あとからまとめて埋めた行は無い。それはコミット履歴を見れば分かる。

bed0c8b docs: WBSに口座詳細画面向けBFF API+取引履歴フィルタのAI実績を追記
f3ac5d3 docs: WBSにBFF-4(accounts-service部分)のAI実績を記録
2f4f5d6 docs: WBSにBFF-1のAI実績を記録
0206dda docs: WBSにAUTH-4のAI実績を記録
4cc2182 docs: WBSにNOTIF-4のAI実績を記録
04da765 docs: WBSにACC-8/PAY-7/AUTH-7/NOTIF-6のAI実績を記録
a738c4b docs: WBSにACC-7のAI実績を記録
3c8dcce docs: WBSにACC-6のAI実績を記録
3434ddc docs: WBSにACC-5のAI実績を記録
b0d82f9 docs: WBSにPAY-5のAI実績を記録
df89606 docs: WBSにPAY-4のAI実績を記録
3ef1172 docs: WBSにPAY-3のAI実績を記録
2b88b45 docs: WBSにPAY-6のAI実績を記録
3290475 docs: WBSにACC-4のAI実績を記録
cc289cb docs: WBSに人間実施予想/AI実施予想/AI実績の3軸を追加
27399ea docs: 全体WBS・マスタスケジュールを新規作成

メッセージに出てくる BFF-4 AUTH-4 のような英数字は、WBS上の成果物番号である。接頭辞がサービスを表し（AUTH＝認証サービス、ACC＝口座サービス、PAY＝決済サービス、NOTIF＝通知サービス、BFF＝画面向けAPI集約層、WEB＝Webフロント、INF＝インフラ）、数字がその中のタスク番号にあたる。上のコミットに出てくるものを日本語にすると次のとおり。

下から2行目に注目してほしい。最初にWBSを作った時点では、3列の軸そのものが無かった。あとから「測ろう」と決めて列を足している。測ろうと決めた時点自体が、履歴として残っている形になった。

1タスクが1行として閉じるまでの流れを図にすると、次のようになる。実装→検証で終わりではなく、差し戻しの戻りエッジと、実績が次の見積りへ戻るもう1本の戻りエッジがある。

flowchart TD
    subgraph WBS["WBS（グループの入れ子：auth / accounts / payments / notifications / bff / web）"]
        T["1タスク<br/>例：PAY-3 = Saga本体の実装"]
    end
    T --> IMPL["実装<br/>rag-coder"]
    T --> TC["テスト観点表 → テストコード<br/>test-coder"]
    IMPL --> REV{"レビュー<br/>rag-reviewer / test-reviewer"}
    TC --> REV
    REV -->|"must-fix 0件"| REC
    REV -->|"must-fix N件<br/>例：所有権チェック欠落"| FIX["是正"]
    FIX -->|"差し戻し"| REV
    REC["AI実績列に所要を m で記入<br/>例：75m = 初回50m + 是正25m"] --> CM["1タスク = 1コミットで追記"]
    CM -->|"実測が溜まる"| EST["AI実施予想列の精度が上がる"]
    EST -->|"次タスクの見積りに反映"| T

    style REC fill:#e8f4ea,stroke:#4a7c59
    style FIX fill:#fbeee6,stroke:#c17f4a

私が引いた人間SE見積り 490.8h を、実測 21.9h で書いた — 95.5%削減

WBSのAI対象189行のうち、人間実施予想とAI実績の両方に数値が入っていて、対比できたのは49行である（残りが何なのかは後段でそのまま書く）。

490.8hというのは、伝統的な人日見積りで61.4人日ぶん、フルタイムのSEが専従で3か月近くかかる分量にあたる。それを実測21.90hで書いた。同じ縦軸に並べると、こうなる。

xychart-beta
    title "同じ49タスクにかかった時間（単位：h）"
    x-axis ["人間SE見積り 490.8h", "AIエージェント実測 21.9h"]
    y-axis "h" 0 --> 500
    bar [490.8, 21.9]

h(時間)のままだと分量が掴みにくいので、同じ数字を単位を変えて書き直しておく（1人日=8h、1か月=20営業日で換算）。

• 490.8h ⇒ 21.90hに短縮、95.5%削減
• 61.4人日（1人専従で約3か月）⇒ 2.7人日（約3日）に短縮
• 20営業日（1か月）ぶんの作業 ⇒ 約7h（1営業日）に短縮

比率は同じなので、小さい単位に落としても同じことが言える。1人のSEが1か月かけて書く分量が、1営業日に収まる計算になる。

役割別に割ると、実装だけが速かったわけではないことが見える。

ここが記事の芯になる部分だ。レビューの行数（23）は、実装の行数（22）とほぼ同数ある。21.90hの使われ方を割ると、次のようになる。

pie showData
    title AI実績 21.90h の内訳（役割別）
    "実装 rag-coder" : 13.64
    "レビュー rag-reviewer / test-reviewer" : 6.11
    "テストコード test-coder" : 2.15

全体の28%が検証に使われている。速さの正体は「1体に全部やらせて済ませた」ではなく、作成と検証を別のエージェントに分けたうえで、なお21.90hだった、ということだ。レビューを省いて出した数字ではない。

担当エージェント別に削減率を出すと、作る側と検証する側で差が出る。

xychart-beta
    title "担当エージェント別の倍率（人間SE見積り ÷ AI実績）"
    x-axis ["rag-coder 実装", "rag-reviewer 検証", "test-coder テスト", "test-reviewer 検証"]
    y-axis "倍" 0 --> 30
    bar [26.4, 17.7, 14.9, 13.3]

実装が96.2%削減（26.4倍）なのに対し、検証側は92.5〜94.4%削減（13〜18倍）にとどまる。検証は、実装ほどには圧縮されない。レビューの中身は「差分を読んで、設計書と突き合わせて、直すべきか判断する」作業であり、書く作業ほど機械的に速くならない、というのが49行から出た実測の形だった。

ここで表記の性質に触れておく。この記事は削減率を主に書いているが、削減率だけでは見えなくなるものがある。実装96.2%とレビュー92.5%はほとんど同じに見える。倍率では26.4倍と13.3倍で2倍の開きがあるのに、である。90%を超えた領域では、削減率は差を潰す。図を倍率のまま残し、本文で倍率を併記しているのはそのためで、%だけを見せると「どの工程も同じくらい速くなる」という誤った像を渡すことになる。

サービス単位で切っても、削減率は一様ではない。

xychart-beta
    title "サービス別の倍率（人間SE見積り ÷ AI実績）"
    x-axis ["web", "payments", "bff", "auth", "accounts", "notifications", "infra"]
    y-axis "倍" 0 --> 40
    bar [34.8, 23.7, 23.6, 22.0, 20.2, 17.8, 15.0]

画面まわり（web、2タスク）が97.1%削減（34.8倍）で最も高く、通知（notifications、2タスク）が94.4%削減（17.8倍）で低い。ただしこの2つはどちらも母数が2タスクしかないので、傾向として読むには足りない。母数が多いのは accounts（7タスク・95.0%削減）と payments / auth（各5タスク・95.8%削減 / 95.5%削減）で、この3つは95%前後に固まっている。

削減率は90.4%から97.8%まで散る — 平均だけを見せると誤読される

平均だけを書くと実態を見誤る。個々のタスク（26件、複数の行にまたがる作業を1タスク単位でまとめたもの）で見ると、削減率には幅がある。

以下、成果物番号には日本語のタスク名を併記する。

26タスクを帯ごとに数えると、幅の広さがそのまま見える。ここは倍率で数えている。削減率の帯にすると90.4%〜97.8%の中に8本の柱が詰まり、どれも「ほぼ100%」に見えて分布が読めなくなるからだ。

xychart-beta
    title "26タスクの倍率分布（中央値 21.8倍 ＝ 95.4%削減）"
    x-axis ["10-15倍", "15-20倍", "20-25倍", "25-30倍", "30-35倍", "35-40倍", "40-45倍", "45-50倍"]
    y-axis "タスク数" 0 --> 9
    bar [4, 6, 8, 4, 1, 1, 1, 1]

18タスク（69%）が93.3〜96.7%削減（15〜30倍）の帯に入る一方、97.8%削減（45倍超）に届くものも1件ある。

削減率で書くと最小90.4%・最大97.8%で7.4ポイントしか違わないように見えるが、残った時間で見れば最小と最大では4.4倍の開きがある。全体の平均値である95.5%削減（22.4倍）は、この幅の真ん中を通っているだけで、個々のタスクがその値で終わるという意味ではない。案件でこの数字を出すとき、平均だけを示して「どのタスクも95%削減で終わる」と読まれると誤りになる。

削減率が低い側（人間見積りとの差が小さかったタスク）:

削減率が高い側:

「依存方向テスト整備」は、レイヤー間の依存が設計どおりの向き（api → application → domain → infrastructure の一方向）になっているかを、テストコードとして機械的に検査する仕組みを入れる作業を指す。

レビューで差し戻しが起きたタスクは6件あるが、その削減率は90.4%・93.4%・95.0%・95.8%・95.9%・96.6%と、中央値95.4%を挟んで両側に散っている。差し戻しが起きたから遅い、という関係は数字の上では出ていない。速さの内訳に検証と是正がそのまま入っていることの実例として、WBSの実績欄を引用する。

PAY-3（Saga本体の実装。Sagaは、複数サービスにまたがる一連の処理を一気に確定させず、1手ずつ確定させて、途中で失敗したら逆操作＝補償で戻す定番の設計パターン）はAI実績「75m（初回50m+must-fix是正25m）」、レビュー「25m（初回検出15m+是正後再確認10m）」。レビュー欄の原文はこうだ。

must-fix 2件検出（①fromAccountId所有権チェック欠落=IDOR、②transfer-inタイムアウト時の即時補償による二重資金増加リスク）。是正後再レビューで解消確認。副次的にjwt.secretが3サービスで不一致という既存ギャップも発覚・是正

IDOR（Insecure Direct Object Reference。IDを指定するだけで他人の口座やデータに触れてしまう、定番の脆弱性）は、レビューが無ければ本番に入っていた欠陥だった。PAY-6（サービス間連携クライアント）も同型で、AI実績「50m（初回実装35m＋是正15m）」に対し、レビュー原文は次のとおり。

must-fix 1件検出（0402§1.6 NEVERルールとの矛盾、JWT自己発行を本番コードに実装していた）。rag-coderが安全側（テスト専用ヘルパーへの復帰）で是正、再検証済み

AUTH-4（生体認証の実装。66m+是正16m）、ACC-7（休眠判定バッチ。19m+是正10m）、NOTIF-6（通知サービスの依存方向テスト整備。36m+是正10m）、BFF-1（画面向けAPI集約層の雛形。11m+是正16m）にも同種の差し戻しが記録されている。must-fixは「レビューで検出された、リリース前に必ず直す欠陥」を指す表記としてWBS内で使っている言葉で、これが0件で通ったタスクと、差し戻しを経たタスクが混在した状態で、全体の21.90hになっている。

対比に使った49行と、使わなかった行

「実施したか」と「工数を計測したか」は別の軸である。WBSのAI対象189行を、その2軸で分けるとこうなる。

flowchart LR
    A["WBS の AI 対象<br/>189 行"] --> B["設計判断・運用変更で<br/>発生しなかった<br/>47 行"]
    A --> C["発生したタスク<br/>142 行"]
    C --> D["実施済み<br/>124 行 = 87.3%"]
    C --> E["未着手 18 行<br/>Phase 3 以降のスコープ"]
    D --> F["工数を分単位で計測した<br/>49 行<br/>この記事の数字はここから"]
    D --> G["工数は計測していない<br/>75 行"]

    style D fill:#e8f4ea,stroke:#4a7c59
    style F fill:#e8f4ea,stroke:#4a7c59
    style G fill:#fbeee6,stroke:#c17f4a

発生したタスク142行のうち、実施済みは124行（87.3%）である。 一方、そのうち分単位で工数を取ったのは49行にとどまる。2026年7月中旬に測り始め、途中で実装を優先して計測を止めた区間があるためだ。490.8h → 21.90h という数字は、この計測した49行だけから出ている。

計測していない75行に、あとから推定値を書き込むことはしない。WBSの記法にもそう書いた（引用中の「凡例2」は実施済み・工数未計測の行、「凡例1」は実測値が入っている行を指す）。

⚠️ 凡例 2 の行に、後から推定の工数を書き込んではならない。計測していないものは計測していない。対比可能な母集合は凡例 1 の行だけである。

「発生しなかった47行」も内訳を書く。45行は、当初 test-writer がテスト観点表を作り、test-coder がそれに対してテストを実装し、test-reviewer がレビューする三段構えを想定していた行である。実際に運用すると、rag-coder が実装と一体でテストを書き、rag-reviewer が実装とテストをまとめてレビューする形に収束した。観点表という中間成果物を挟まないほうが、実装とテストの往復が速かったためだ。残る2行（AUTH-6 / BFF-3）は、ADR 0016（Keycloak を IdP として使う構成をやめ、auth-service が JWT を自己発行する方式へ変更）でスコープ外になった行である。

どちらも「終わっていない」のではなく、やらなくてよくなった。工数削減の分母から外してある。

未着手の18行は、モバイルの業務画面、内部システム（operator / backoffice / admin）の雛形、および任意項目である観測性整備と k8s マニフェストで、いずれも Phase 3 以降のスコープに置いてある。

なお、測れなかった行を消して見かけの網羅率を上げることもできたが、それをやると台帳ではなく宣伝物になる。「計測データなし（要約圧縮前の区間のため正確な分数が復元不可、参考: コミット 467f594/a6e6057）」と書いた行はそのまま残してある。

予想では94.7%削減、実測では95.5%削減

WBSにはもう1つ別の数字がある。集計節に書かれた「約18.7倍」＝94.7%削減（AI対象の210.35人日＝1,682.8h ÷ AI実施予想の合計 約90.2h）で、これは予想 ÷ 予想であって実測ではない。WBS自身が「AI実施予想の大半が推定値であることに起因する暫定値」と断っている数字だ。

今回49行で実測できた削減率は95.5%（490.8h → 21.90h）。分母が違う2つの数字なので単純比較はできないが、対比としては書ける。予想の段階で見ていた94.7%削減より、実測できた範囲の95.5%削減のほうが大きかった。予想のほうが控えめだった、ということになる。

この95.5%削減（22.4倍）と担当別の内訳は、記事のために計算したものではない。WBS本体の集計節に「実績集計」として書き込んである。台帳が正で、この記事はそこから派生した読み物である。

2つの数字がどこから来ているかを並べておく。左は分母も分子も見積り、右は分母だけが実測である。図は倍率で描いてある（94.7%と95.5%を並べても、出どころの違いが見えないからだ）。

flowchart LR
    subgraph A["WBS集計節の 約18.7倍 ＝ 94.7%削減 ＝ 予想 ÷ 予想"]
        A1["AI対象 210.35人日<br/>＝ 1,682.8h<br/>人間実施予想"] --> A3["18.7倍"]
        A2["AI実施予想の合計<br/>約90.2h<br/>大半が推定値"] --> A3
    end
    subgraph B["この記事の 22.4倍 ＝ 95.5%削減 ＝ 予想 ÷ 実測"]
        B1["49行ぶん 490.8h<br/>人間実施予想"] --> B3["22.4倍"]
        B2["49行ぶん 21.90h<br/>AI実績＝実測"] --> B3
    end
    A3 -.->|"母数が違う<br/>単純比較はできない"| B3

    style A2 fill:#fbeee6,stroke:#c17f4a
    style B2 fill:#e8f4ea,stroke:#4a7c59

ただし、この95.5%という数字にも留保が要る。同じ49タスクを人間のSEが実際に手を動かしてやった記録は存在しない。人間側は見積りのままで、実測しているのはAI側だけだ。だから「作業時間を95.5%削減した」と言い切ることはできない。正確に言えば、人間SEの見積り490.8hぶんの作業を、実測21.90hで書いた、という一方向の実測である。

もう1つ、AI実績列そのものの範囲も限定的だ。含まれていないのは、最終承認・環境構築・実走確認と、差し戻すかどうかの判断・指示を書く時間である。WBS原文が「人間（本人）が行うのは最終承認・環境構築・実走確認のみ」と定めているとおり、これらは人間側の作業として実績列の外にある。つまりこの記事の数字は「エンジニアが不要になる時間」を示すものではなく、「エージェントが実際に処理していた時間」を示すものにとどまる。

最後に、タスク単位の削減率そのものにも誤差がある。実績欄に「合算」と書かれている行があるからだ。

BFF-2  48m（BFF-7と合算）
WEB-1  29m（WEB-2/WEB-4一部と合算）
AUTH-7 46m（auth-service/bff/web一体実装）
BFF-4  27m（accounts-service部分のみ、AUTH-6未着手のためpayments/notifications/auth向けは別途）
INF-1  11m12s（docker-compose.yml実装作業と合算、内訳分離不可）

この5行に出てくる番号は、それぞれ次のタスクを指す。

（BFF-4 の欄にある「AUTH-6未着手」は記入した当時の表現である。AUTH-6＝IdP（外部の認証基盤）との連携は、その後 ADR 0016 でスコープ外と確定した行で、前段の「発生しなかった47行」に含まれる）

1つの行に複数タスクぶんの実作業が乗っている一方、人間側の見積りは1タスクぶんのまま計算されている。合算された側は削減率が過小に、合算の相手側は過大に出る。全体を足し合わせれば相殺されるが、タスク単位の削減率は誤差を含む、と明記しておく。

24.40hという数字は、正しくなかった

ここまでの数字は21.90hで書いてきたが、集計スクリプトが最初に出した合計は24.40hだった。

原因は正規表現にあった。75m（初回50m+must-fix是正25m）という書き方に対して、75と50と25をすべて拾い、合計150mとして数えていた。括弧の中は内訳であって、本体に足すべき値ではない。同じ書き方が50m（初回実装35m＋是正15m）にもあった。

一方で66m+16m是正のような、括弧の無い書き方もある。こちらは初回と是正の両方が本体なので、82mとして数えるのが正しい。表記が2種類混在していることに気づかないまま、片方の規則だけで全部を読んでいたのが誤りだった。

flowchart TD
    S["WBSの実績欄<br/>2種類の表記が混在している"] --> P1["75m（初回50m+是正25m）<br/>括弧の中は内訳"]
    S --> P2["66m+16m是正<br/>括弧なし＝両方が本体"]
    P1 --> BUG["最初の正規表現<br/>行にある数字を全部拾う"]
    P2 --> BUG
    BUG --> W["75+50+25 ＝ 150m と数える"]
    BUG --> OK["66+16 ＝ 82m と数える"]
    W --> WT["合計 24.40h ／ 95.0%削減"]
    OK --> WT
    WT --> D{"括弧の有無で<br/>説明できない行が残る"}
    D -->|"表記の揺れに気づく"| FIX["括弧内を除去してから解析する"]
    FIX --> R["75m と数える"]
    R --> RT["合計 21.90h ／ 95.5%削減"]

    style WT fill:#fbeee6,stroke:#c17f4a
    style RT fill:#e8f4ea,stroke:#4a7c59

AIの作業効率を測る記事の元になった数字が、自分の測り方のせいで11.4%ずれていた。ずれの向きも書いておく。訂正するとAI側の合計は24.40hから21.90hに減り、削減率は95.0%から95.5%に上がった。つまり最初のバグは、AI側の所要時間を実際より多く見せる方向、自分に不利な方向のバグだった。ここでも削減率の性質が出ている。95.0%と95.5%は0.5ポイントしか違わないように見えるが、残った時間は24.40hと21.90hで2.5hも違う。

ここで「都合の良い方向に間違えていなかったから大丈夫」とは考えていない。向きがどちらであれ、測り方そのものを疑うまで、最初に出た数字をそのまま信じていたことに変わりはない。

表記の揺れに気づいたきっかけは、括弧の有無で結果が説明できない行が残ったことだった。数字が大きすぎると感じたからではない。自分が置いた規則が全行を説明できていないこと自体を異常とみなした、という順序である。数字の妥当性を勘で判定していたら、この誤りは残ったままだった。

この 95.5%削減 が成り立つ条件

案件の場でこの数字を見せるなら、次の6点も同時に見せる。条件を伏せた削減率は、それ自体が誤りになるからだ。

• 人間実施予想は、実際に手を動かした人間の記録ではない。WBSを作るときに置いた、伝統的な人日見積りの値である
• AI実績は、人間側の最終承認・環境構築・実走確認・判断・指示作成の時間を含まない
• 95.5%という削減率は、AI側だけが実測で人間側は見積りのままという、片側だけを測った比較である
• タスク単位の削減率には、複数タスクを1行に合算した行があるぶんの誤差が乗っている
• 分母は、工数を分単位で計測した49行である。実施済みだが計測していない75行は、推定値を書かず分母にも入れていない
• 49行のうち1行は、担当欄が「rag-coder / 本人代行」となっている。人間見積り4.0hぶんのタスクで、実績列の0.33hは私が代わりに手を動かした時間である。つまり実績列は完全にエージェントだけの時間ではない（全体21.90hに対して0.33h、1.5%）

逆に言えば、この6点を外せば削減率はもっと大きく出せる。レビュー行を分母から抜けば実装だけの96.2%削減になり、是正と差し戻しの時間を落とせばさらに上がる。そうしなかった数字が95.5%削減である。

案件全体なら60〜70%削減 — 95.5%がそのまま出るわけではない

ここまでの95.5%は、WBSの行になる開発タスクだけを測った数字である。実際の案件はこれで終わらない。顧客へ提出する資料の作成、要件の擦り合わせ、仕様の確認、打ち合わせとその準備、関係者間の合意形成。WBSの成果物番号が付かない作業や、AIに投げても結局こちらが書き直すことになる作業が、案件には相当量ある。

そこまで含めた案件全体で削減できるのは、**作業時間の60〜70%**である。

flowchart LR
    A["案件全体の作業時間"] --> B["WBSに載る開発タスク<br/>実装・レビュー・テスト"]
    A --> C["顧客提出資料・要件擦り合わせ<br/>打ち合わせ・合意形成<br/>圧縮しにくい領域"]
    B -->|"実測 95.5% 削減"| D["案件全体では<br/>60〜70% 削減"]
    C -->|"ほとんど削減されない"| D

    style B fill:#e8f4ea,stroke:#4a7c59
    style C fill:#fbeee6,stroke:#c17f4a

この60〜70%は、算術としても整合する。案件の作業時間のうち開発工程が占める割合を6〜7割とし、そこだけが95.5%削減され、残りは削減されないとすると、全体の削減率は60〜70%になる。逆に言えばこの数字は**「開発以外が3〜4割ある」という前提とセット**であり、その比率が違う案件では変わる。

2つの数字は、出どころが違う。95.5%はこのWBSの49行を分単位で測った値で、測り方も間違えた箇所もこの記事に載せてある。60〜70%は、案件のどこに何時間かかるかを実際に見てきたうえで自分で導き出した答えである。案件全体に当てはめるべきなのは後者のほうである。

案件の場でこの数字を出すなら、この順序で出す。開発工程だけを見れば95.5%削減できた、案件全体なら60〜70%になる、と。

同じ列は、どのWBSにも足せる

やったことは単純だ。見積り表に「実際にかかった時間」を書く欄を1つ足し、1タスク終えるごとに1コミットで埋めた。それだけで、見積りの精度も、どの工程が圧縮されてどの工程が圧縮されないかも、数字で言えるようになった。

出てきたのは、人間SE見積り490.8hぶんを実測21.90hで書いた（95.5%削減）という結果と、その内訳である。実装は96.2%削減され、検証は92.5〜94.4%削減にとどまった。速さの正体は「1体に全部やらせて済ませた」ではなく、作成と検証を別のエージェントに分けたうえで、この時間だった、という形をしている。

この95.5%は開発工程の数字であって、案件全体の数字ではない。提出資料も打ち合わせも含めた全体なら60〜70%削減になる。出どころの違う2つの数字を混ぜないために、この記事では節を分けて書いた。

測り方も、途中で自分が間違えた箇所も全部書いた。同じ列は、どのWBSにも足せる。