AI時代の保守で cc-sdd をどう使うか（考え方編）
はじめに
前回の記事では、
GitHub Copilot に cc-sdd を導入し、
「要件 → 設計 → タスク → 実装」 という基本フローを体験しました。
しかし、実際の保守現場では、
常に「新機能を作る」わけではありません。
- 「バグ修正依頼が来た」
- 「このログが出る原因を調査してほしい」
- 「ちょっとした文言変更」
こうした日常的なタスクを前にしたとき、
「これ全部、あのフローを通さないといけないの？」
と迷うはずです。
この記事では、ツールの使い方から一歩離れ、
AI時代の保守において、現場では「どの順番」で考えればよいのか
その思考プロセスを整理します。
ここで扱うのは、コマンドではありません。
**「判断の交通整理」**です。
この記事の前提
cc-sddは、
すべての作業で厳密に適用しなければならない
ルールではありません。
重要なのは、
- 判断をどこで行うか
- 判断をいつ確定させるか
という思考の順番です。
シーン①：保守案件の調査依頼が来たとき、最初にやること
多くの現場では、
調査依頼が来るとすぐにコードを開きがちです。
AI時代の保守では、
ここで一度ブレーキを踏みます。
最初に確認する問い
- これは「仕様変更」か？
- それとも「既存仕様の不具合」か？
この切り分けが曖昧なまま実装に入ると、
AIにも曖昧な指示しか渡せません。
まずは、
判断が必要なポイントを言語化することが最優先です。
シーン②：軽微な改修・調整案件ではどう考えるか
すべての変更で、
大きな仕様整理が必要なわけではありません。
重要なのは「判断の数」
- 判断が1つなら、1つだけ書けばいい
- 判断がないなら、書かなくてもいい
cc-sddは、
ドキュメントを増やすための手法ではありません。
判断が発生したかどうかを基準に、
やる・やらないを決めます。
シーン③：バグ修正時の考え方
「バグ修正」と呼ばれる作業の中には、
実は仕様が未確定なまま放置されていたケースが多く含まれます。
よくある状況
- 現象は再現する
- でも、それが正しい挙動か分からない
この状態で実装を修正すると、
判断が後出しになります。
AI時代の対応
- その挙動は仕様として正しいのか？
- 正しいなら、仕様として明文化する
- 間違っているなら、仕様変更として扱う
仕様を先に確定させてから直す。
これが、
AI時代のバグ修正における基本姿勢です。
シーン④：cc-sddを無理に使わない判断
cc-sddは万能ではありません。
向いていないケース
- 影響範囲が極端に小さい修正
- 一時対応・捨て修正
- 判断が一切発生しない作業
こうしたケースでは、
無理に形式を整える必要はありません。
やらない判断も、立派な判断です。
シーン⑤：既存システムへの追加開発が発生したときの考え方
保守案件では、
調査や実装を進める中で、
当初の想定になかった機能追加が必要になることがあります。
これは単なる修正ではなく、
新しい判断を伴う追加開発です。
ここで立ち止まるポイント
既存システムへの追加開発が発生したときは、
次の問いを必ず立てます。
- これは新しい仕様判断か？
- それとも既存仕様の延長か？
この切り分けをせずに進めると、
判断が実装に埋もれてしまいます。
考え方の原則
cc-sddでは、
- 作業が増えたか
ではなく、 - 判断が増えたか
を基準に考えます。
判断が増えた場合は、
一度立ち止まり、
仕様として確定させてから進める。
それだけで、
思考の軸は崩れません。
思考の結果を「どのファイル」に残すべきか
ここまで「思考の順番」を見てきましたが、
最後に、その判断結果を 「具体的にどこに書くか（マッピング）」 を整理します。
判断した内容は、
その性質によって書き込むべきファイルが異なります。
| 判断の種類 | 書き込む場所 | 理由 |
|---|---|---|
| 今回の機能変更・修正 | .kiro/specs/ |
その変更限りの判断履歴だから |
| プロジェクト全体のルール | .kiro/steering/ |
今後ずっとAIに守らせたい前提だから |
| 組織・チーム共通の思想 | .kiro/settings/steering-custom/ |
どのPJでも守るべき憲法だから |
- 「今回のバグを直す」判断なら、specs。
- 「今後このライブラリは禁止する」という判断なら、steering。
思考した結果を適切な場所に置くことで、
その判断は 「使い捨て」ではなく「資産」 になります。
うまく回っている現場の共通点
cc-sddが形骸化しない現場には、
いくつか共通点があります。
- 仕様を書く人が固定されていない
- 書かれた仕様が「正」になる
- 後から読まれる前提で書かれている
仕様は、
記録ではなく判断の参照点として扱われています。
まとめ
AI時代の保守で重要なのは、
- 何を書くか
- どのツールを使うか
ではありません。
どの順番で考えるか です。
思考の順番が整っていれば、
あとはそれを適切なファイルに落とし込むだけです。
次の記事では、先ほど少し触れた
「steering」「specs」「steering-custom」 といったファイル群を、
実運用でどのように使い分けるのか、その詳細なガイドラインを解説します。
Discussion