技術負債返却プロセス

生成が速いほど、負債も速くたまります。ピットイン方式は負債を「見なかったことにしない」設計(負債台帳)にしていますが、記録するだけでは残高が増える一方です。このページは返却を定常サイクルとして回すプロセスを定義します。

AIが生みやすい負債の類型

従来の負債に加えて、AI協調に固有の類型を意識して検知します。

類型	症状	検知の手がかり
生成コードの重複	似た処理がコピー的に量産される(AIは既存の再利用より新規生成に流れやすい)	重複検出ツール、レビューでの既視感
テストの形骸化	実装に合わせて自動生成されたテストが、仕様でなく実装を写しているだけ	変異テスト、受入基準との突合
ドキュメントと実装の乖離	生成ドキュメントが更新に追随していない	文脈の陳腐化チェック
理解の空白	動いているが誰も説明できないコード	挙動要約が書けない・レビューが素通し
プロンプト・文脈への依存	特定の指示ファイルや暗黙の文脈がないと保守できない	文脈基盤外の口伝の存在

「理解の空白」は最も危険な負債です。これは事業継続性の毀損であり、通常の返却(リファクタ)でなく**理解の回復(読み解き+判断記録の追記)**として返却します。

台帳駆動の返却サイクル

graph LR
  A["記録<br>(構築中に随時)"] --> B["トリアージ<br>(月次)"]
  B --> C["返却枠へ割り当て<br>(容量の目安20%)"]
  C --> D["返却実行<br>(AI活用+人検証)"]
  D --> E["検証・台帳更新"]
  E --> A

トリアージ(月次)

優先度は「影響 × 金利」で判断します。

• 影響: 放置したとき何が起きるか(障害・開発速度低下・セキュリティ)
• 金利: 時間とともに悪化する速度(触る頻度が高いコードの負債ほど金利が高い)

優先	基準	扱い
即時	セキュリティ・データ破損リスク	次の反復で最優先返却
高	高頻度に触る領域+開発を遅くしている	返却枠の先頭
中	影響はあるが金利が低い	返却枠で順次
低	触らない領域・使い捨て予定	意図的に持ち続ける(理由を台帳に明記)

「低」を明示的に持つことが重要です。全部返すことは目標にしません。返さない判断も、理由つきで台帳に残せば健全な意思決定です。

返却枠の確保

• 反復の容量の20%を返却枠の初期値とし、負債残高のトレンドで調整する(残高が増え続けるようなら枠を広げる)
• 返却枠は価値責任者が確保する。「新機能が忙しいから今月はゼロ」を認めると、返却は永遠に始まらない
• 返却タスクも通常のタスクと同じゲート(仕様承認→CI→独立レビュー)を通す

AIを返却に使う

負債の返却こそAIの得意領域です。

• 重複の検出と統合案の生成、テストの補強、ドキュメントの追随更新はAIに実行させ、人は検証する
• ただし**「理解の空白」の返却だけは人が主体**になる。読み解いて判断記録を書く行為自体が理解の回復であり、AIに代行させると目的が消える

健全性の判断

指標	健全	警戒
負債残高のトレンド	横ばい〜漸減	3か月連続で増加
「即時」「高」の滞留	返却枠で消化されている	2か月以上残留
記録漏れ	レビューで負債が拾われ台帳に載る	台帳に載らない負債がレビューで頻出(記録文化の崩れ)
理由なき「低」の増殖	受容理由が書かれている	理由欄が空の格下げが増える(判断の放棄)