SDDで⾒える、AIコーディングの"内訳" -*/&Ϡϑʔ
%FWFMPQNFOU
XJUI
"HFOUT
.FFUVQ
 

˜
-:
$PSQPSBUJPO *OUFSOBM
6TF
0OMZ િా ஌໵ 4PEB
5PNPZB -*/&Ϡϑʔגࣜձࣾ ϩʔΧϧɾ6($
4#6
։ൃϢχοτ
։ൃσΟϏδϣϯ  ۀ຿಺༰  ϚοϓΞϓϦͷ#&։ൃ  0SDIFTUSBUJPO
(VJMEϝϯόʔ ˜
-:
$PSQPSBUJPO 

01 "*ίʔσΟϯάͷ଎͞ͷ಺༁͕ݟ͑ͳ͍ 02 4%%πʔϧΛ࢖ͬͨ։ൃ͸ΰϧϑʹࣅ͍ͯΔ 03 4%%πʔϧΛ࢖ͬͨ։ൃΛϲ݄΍ͬͯΈͯݟ͑ͨ΋ͷ Agenda 

01. AIコーディングの速さの"内訳"が⾒えない 

体感として、明らかに変わった $MBVEF
$PEFΛ࢖͏Α͏ʹͳͬͯɺ࣮૷εϐʔυ্͕͕ͬͨ εϓϦϯτͰ͜ͳͤΔλεΫ΋ɺࣗવͱ૿͑ͨ 少なくとも、「遅くなった」とは感じない AIで、開発は確かに速くなった 

⾒えていないコストがある ࣮૷தͷ⼿戻り ࣮૷લͷAIとの相談時間（プランモード） ˠ
ίϛοτʹ΋޻਺ʹ΋ݱΕͳ͍ 開発スピードは上がっている WT ⾒えないコストも増えている ⇒ 「速くなった気がする」状態 本当に速くなっているのか？ 

Claudeのセッション履歴を手掛かりにできる しかし ਓ΍13͝ͱʹਐΊํ͕ҧ͏ͱɺ⽐較も集計もできない ·ͣ͸プロセスを揃える͜ͱ͕ඞཁ SDDツールなら、プロセスを揃えることが可能 "⾒える化"するための"構造化" 

「要件 → 設計 → 実装」をフェーズで明⽰的に進める開発スタイル 実装に⼊る前に要件・設計をしっかり固める Spec-Driven Development（仕様駆動開発） 

同じ思想のツールが、いくつも出てきている spec-kit cc-sdd OpenSpec 世の中のSDDツール 

SDDツールを使ったワークフロー(スキルを使う順番)の例 
/requirements ཁ݅ɾड͚ೖΕ৚݅࡞੒ 
/design طଘίʔυΛࢀরͯ͠ઃܭ࡞੒ 
/tasks ઃܭΛλεΫʹ෼ղ 
/impl λεΫ͝ͱʹ࣮૷ ⽣成物が、ドキュメントとして残る SDDツールの典型的なフロー 各フェーズで使うスキルが定められている 

本来の狙い ཁ݅ɾઃܭɾ࣮૷͕ɺ明⽰的に積み上がる ࢓༷ΛઌʹݻΊΔ͔Βɺ"*ͷ࣮૷͕意図通りになりやすい υΩϡϝϯτ͕࢒Δ͔Βɺチームで共有・検証しやすい 副産物として、こんなメリットも SDDツールΛ࢖͑͹ɺεΩϧ͕౷Ұ͞ΕΔͷͰプロセスの計測が可能になる 今⽇は、この副産物の話 SDDで、何が変わるか 

どのツールも、各フェーズのスキルが⽤意されている ツール 計画（要件・設計・タスク） 実装 spec-kit /specify ˠ /plan ˠ /tasks /implement cc-sdd /requirements ˠ /design ˠ /tasks /impl OpenSpec /openspec:proposal ʢҰׅੜ੒ʣ /openspec:apply チームで導⼊すれば、全員が同じスキルで同じフェーズを踏む ˠ
ϓϩηε͕ଗ͏͔Βɺログとして集計・⽐較できるΑ͏ʹͳΔ なぜSDDツールならプロセスの計測ができるのか 

SDDツールでスキルを揃えた結果、以下が計測になる 要件作成 
設計作成 
実装開始 ˠ
଎͞ͷ಺༁͕ɺ13͝ͱʹ時刻として並ぶ セッションログから、このような表が作れる 

02. SDDは ゴルフに似ている 

⾵を読む Ͳ͜ʹɺͲ͏ଧ͔ͭ ˠཁ݅ɾ࢓༷ΛݻΊΔ ショット ଧͭ ˠ"*͕࣮૷͢Δ カップイン ΧοϓʹೖΔ ˠ׬੒ɾϚʔδ SDDのプロセスは、ゴルフの3ステップに似ている 

⾵を読む ཁ݅֬ೝ Ϣʔεέʔε੔ཧͳͲ ઃܭ֬ೝ Τϥʔϋϯυϧํ਑ σʔλϞσϧઃܭ طଘίʔυௐࠪͳͲ ςετํ਑ ショット ࣮૷मਖ਼ カップイン Ϛʔδ ⾵読みのほうが、やることが多い 各ステップで何をしているか 

AIが実装したコードが、⼿直しなしで⼀発マージOK ͜Ε͕ى͖Δͷ͸ɺ⾵読み（要件・仕様）が正確だった証拠 ホールインワンを打てる頻度こそ、「開発速度の向上」を示す1つの指標 理想は、ホールインワン 

Կ౓΋ඍमਖ਼͕ඞཁ 🏌🏌🏌 ख௚͠ͷటপԽ 🐪 ॏཁͳલఏ΍੍໿Λݟམͱͯ͠ഁ୼ 💦 ઃܭҙਤͱҧ͏ํ޲ʹਐΉ 🌲🌲 どれも、⾵読みの精度が原因かもしれない ࢓༷ͷᐆດ͞͸ɺͦͷ··ίʔυͷᐆດ͞ʹͳΔ 起きがちな失敗パターン 

今の⼿戻りには、2つの要因が混ざっている --.ࣗମͷγϯϓϧͳ࣮૷ϛε ཁ݅ɾ࢓༷Λɺਖ਼͘͠఻͑ΒΕ͍ͯͳ͍ લऀ͸ɺਐԽͰݮΔՄೳੑ͕͋Δɻ ͕ࠩͭ͘ͷ͸ɺޙऀͷʮཁ݅ɾ࢓༷Λ఻͑Δྗʯ

෩ΛಡΉྗ LLMが進化したら、何が残る？ 

03. 2ヶ⽉やってみて⾒えたもの 

チームメンバー全員のセッションログを解析して、可視化するツール ֤ϝϯόʔͷηογϣϯϩάΛղੳͯ͠
1箇所に集約 13͝ͱʹʮどのスキルが・どの順で・何回ʯݺ͹Ε͔ͨ 4QSJOU୯ҐͰɺチーム全体ͷ܏޲͕ݟ͑Δ 4%%πʔϧͰεΩϧ͕౷Ұ͞Ε͍ͯΕ͹ɺ͜͏ͨ͠ूܭͷ࢓૊Έ͕؆୯ʹ࡞ΕΔ 各メンバーのプロセスを可視化するためのツールを作った 

෩ΛಡΜͩ࣌ؒ 
ଧͪ௚࣌ؒ͠ 
ฏۉଧͪ௚͠ճ਺ Λ4QSJOU͝ͱൺֱ 「Sprint毎に上がったか・減ったか」を計測している ① サマリ ― Sprint推移のKPI 

PRごとに、フェーズの時刻が表で並ぶ First commit / 要件作成 / 設計作成 / 実装開始 / Merge / 風読み / 打ち直し 13୯ҐͰʮいつ・何を・どれだけʯ΍͔͕ͬͨݟ͑Δ ② 時間計測 ― PRごとのマイルストーン 

PRごとに、スキル発⽕・コミット・チャットをタイムラインで並べる εϜʔζʹਐΜͩ13ɺటপԽͨ͠13͕Ұ໨ྎવ ③ スキル履歴 ― 時系列で⾒える 

指標 SPRINT 1 SPRINT 2 SPRINT 3 ⾵を読んだ時間 ¹ 
I 
I 
I 打ち直し時間 ² 
I 
I 
I 打ち直し回数 ³ 
ճ 
ճ 
ճ
pSTU
DPNNJU
ˠ
࣮૷ணख
ʗ

࠷ޙͷJNQMൃಈ
ˠ
NFSHF
ʗ
ž
JNQMεΩϧݺͼग़͠ͷฏۉճ਺ 4QSJOU
ɿ
4%%
ಋೖ௚ޙʢֶशظؒʣ 4QSJOU
ɿ
ճ਺
11.0ʢଟΊʣʗ
࣌ؒ
11.2 hʢ୹͍ʣ 4QSJOU
ɿ
ճ਺
9.5ʢগͳΊʣʗ
࣌ؒ
13.0 hʢ௕͍ʣ ˠ
4QSJOU͸ଧͪ௚͕͠ଟ͍͕ɺ͔͔ͬͨ࣌ؒ͸গͳ͍ɻドキュメントよりコードで詰 める΄͏͕ૣ͍ՄೳੑΛ͍ࣔࠦͯ͠Δ ⾒える指標 ― 3つの数字を並べて⾒る 

打ち直し回数の推移 = 要件・仕様決めの精度がそのまま出る ݮΒ͚ͨ͠Ε͹ɺ⾵の読み⽅Λຏ͘ でも、打ち直しは悪じゃない ΤϯδχΞ͸ドキュメントよりコードで詰める΄͏͕ૣ͍͜ͱ΋ 学び① ― 打ち直しの回数に「⾵読みの精度」が映る 

結局大事なのはPR全体の時間（ first commit → merge ） ͜Εࣗମ͸ɺ(JU)VCͰ؆୯ʹܭଌͰ͖Δ਺ࣈ SDDツールの副産物の価値は、その時間の内訳が⾒えること ෩ΛಡΜͩ࣌ؒ ଧͪ௚࣌ؒ͠ ଧͪ௚͠ճ਺ 内訳が⾒えるから、「どこに時間がかかっているか」を数字で語れる 学び② ― ゴールはPR時間。その"内訳"が⾒えるのがSDDツール 

جຊ͸ɺ⾵読みの精度を⾼める Ͱ΋ɺコードで詰めるほうが早い৔໘΋͋Δ ⾵読みの時間を場⾯に応じて調整して、ベストルートを選ぶ 結論 ― ⾵読みの時間を、場⾯で調整する 

今⽇お伝えしたかったこと 
SDDツールͰɺϓϩηεͷ内訳͕ݟ͑Δ 
SDDをゴルフに例えることで、共通イメージを持って振り返りやすくなる 
෩ಡΈͷ時間Λ৔໘Ͱௐ੔ͯ͠ɺベストルートΛબͿ まとめ 

Thank You