はじめに
「技術的負債を解消する時間が欲しいと経営層に言っても、『動いてるなら問題ないでしょ』と言われる」
EMをやっていると、一度はこの壁にぶつかる。バグは見えるから直される。新機能は見えるから評価される。しかし技術的負債は動いているうちは誰にも見えない。だから放置される。
フィリップ・クルーシュテンが整理した可視性マトリクスは、この問題を端的に表している。
| プラスの価値 | マイナスの価値 | |
|---|---|---|
| 見える | 機能（Feature） | 欠陥（Defect） |
| 見えない | アーキテクチャ | 技術的負債 |
技術的負債は「見えない×マイナス」の象限にある。Claude Codeを使うと、この「見えない」部分を数字と言語に変換できる。経営層との会話で一番詰まるのはそこだったので、これはかなり助かった。
AI時代の第4の負債：理解負債（Comprehension Debt）
技術的負債の古典的な3分類はWard Cunninghamが整理している。意図的な負債（後でキレイにしようで来ない）、変化による負債（技術の陳腐化）、学びによる負債（新しい知識でより良い方法を知った）の3つだ。
2026年のAIコーディング時代に、これに加えて第4の負債が登場している。理解負債（Comprehension Debt）だ。
技術的負債：コード品質が低く将来の修正コストが高い（「物」の問題）
理解負債：コードは動くが誰も説明できない（「人」の問題）
AIが1分で数百行を生成できるようになったことで、PRのサイズが大幅に増加したという報告がある。修正は数日かかるが、生成は数秒だ。その速度差が理解を置き去りにする。AI生成コードに一定の割合で脆弱性が含まれるという報告もあり、「テストが通っているから」で見逃されるリスクが高い。
以下の4つに3つ以上該当するチームは、理解負債のリスクが高い。
- PRレビューで「なぜこの実装？」という質問が減っている
- 「生成AIが書いたから大丈夫」というコメントを聞く
- 実装者が数ヶ月後に自分のコードを説明できない
- コードの説明を求められて答えられないことがある
Claude Codeによる技術的負債の可視化：3つのアプローチ
/refactor-suggest スキルによる自動検出
`/refactor-suggest`はコードベース全体を静的解析し、リファクタリング優先度付きで問題を洗い出すカスタムスキルだ。リンターがスタイル違反を検出するのとは異なり、「技術的には正しいが将来メンテナンス負債になるパターン」を推論して特定する。
出力例はこうなる。
## リファクタリング候補（優先度順）
[CRITICAL] 認証モジュール（src/auth/authService.ts）
- 問題: 複雑度スコア 42（推奨: 10以下）
- 影響: バグ発生の主要ホットスポット
- ビジネス影響: 認証バグがサポートチケットの30%を占める
- 推奨: 単一責任原則でサービスを分割
[HIGH] 決済フロー（src/payment/*.ts）
- 問題: テストカバレッジ 12%（推奨: 80%以上）
- ビジネス影響: バグ修正1件あたり平均2日→feature velocityに影響
「認証バグがサポートチケットの30%を占める」という表現は、経営層に提示できる言語だ。
/techdebt コマンドによる継続的な予防
# ~/.claude/commands/techdebt.md
コードベース全体から重複コードを検出して削除してください：
1. 重複するコードブロックを列挙（ファイルパス・行数付き）
2. 削除・統合の安全性を確認（テストの有無を確認）
3. リファクタリング後にテストを実行して動作確認
4. 実施した変更のサマリーをtechdebt-log.mdに記録
このセッションで作成したコードの重複も含めて確認すること。
推奨運用は開発セッション終了時に毎回実行することだ。AIコーディングの普及に伴い重複コードが約8倍に増加したという調査がある（Faros AI・参考値）。このコマンドによる継続的な重複除去が、AI時代の理解負債を防ぐ実践的な対策になる。
API Endpoint Reviewerサブエージェントによる品質負債の自動登録
コード品質負債を継続的に検出してGitHub Issueに自動登録する構成も実現できる。
.claude/
├─ agents/
│ └─ api-endpoint-reviewer.md # レビュー役割のサブエージェント定義
└─ skills/
├─ reviewing-api-endpoint/
│ ├─ SKILL.md # レビュー観点（セキュリティ・複雑度・テスト）
│ └─ checklist.md # チェックリスト
└─ creating-issues/
└─ SKILL.md # Issue作成ルール（重要度フィルタリング付き）
「品質に関する議論が感覚論ではなくなった」「どこが不安かを言語化できるようになった」という実践報告がある。
DMM事例：CIで組織横断の技術的負債を定期可視化
2026年4月、DMMのプラットフォーム開発本部コード品質チームが、Claude Codeを使って組織全体の技術的負債を定期的に可視化するCIを構築した事例が公開されている。
構成はGitHub Actions上でClaude Code Base Actionを実行し、複数リポジトリに対して横断的にコード分析を行うものだ。AI実行の不安定さを考慮して、分析ステップを2回実行してリトライ処理を入れている。
重要な設計原則として「完璧な分析」を目指すのではなく「定期的に可視化し続けること」に目的を置いている点が参考になる。組織全体で同じ基準で測定することで、相対的な改善を追跡できる。
ビジネス言語への翻訳：EMが最初にやるべきこと
「複雑度が高い」と言っても経営層には響かない。筆者が実際に使って効果があったのは、数字をビジネスの言葉に置き換えることだった。
Before（伝わらない）:
「認証モジュールの複雑度が高く、凝集度が低い状態です」
After（伝わる）:
「認証モジュールは現在、バグ発生件数のトップ3に入っています。
リファクタリングにより、サポートチケットを月30件→月10件に削減でき、
エンジニアの障害対応時間を週4時間節約できます」
Claude Codeへの依頼プロンプトはこうなる。
このコードベースの技術的負債を分析して、経営層向けのサマリーを作って：
1. 問題の場所（ファイル・モジュール）
2. ビジネスインパクト（バグ頻度・開発遅延・サポートコスト）
3. 修正コスト（エンジニアの工数見積もり）
4. 放置した場合のリスク（利息）
5. 優先順位（ROIが高い順）
技術的な説明ではなく、ビジネス価値で語ること。
専門用語を使う場合は括弧内に平易な説明を添えること。
解消プロジェクトの組織的な管理にはEID（Engineering Initiative Document）が有効だ。「What（何をしたいか）」「Why（なぜやりたいか）」「期待するアウトカム（計測方法付き）」「スコープ外」の4セクションで構成し、ROIが明確になれば経営層の承認を得やすい。
Technical Debt Analyzerスキルの活用
mcpmarket.comをはじめとする各スキルマーケットで「Technical Debt Analyzer」スキルが公開されており、導入することでClaude Codeが専門的な負債分析モードで動作する。分析観点はコードの複雑度・重複コード率・テストカバレッジのギャップ・非推奨APIの使用状況・セキュリティ脆弱性パターンだ。skills.restの`tech-debt-reducer`も同様に、コードベース横断で負債を体系的に解消するスキルとして公開されている。
まとめ
「動いてるなら大丈夫」という会話が止まったのは、数字を出してからだった。可視化さえできれば、議論の土台が変わる。
今すぐ（15分）：Claude Codeに「このコードベースの技術的負債を経営層向けにビジネスインパクトで説明して」と依頼する。出力を見れば、どこから手をつけるべきかが見えてくる。
今日中：CLAUDE.mdに「新規コードは説明できること（理解負債防止）」のルールを追加する。これだけでAI生成コードの理解負債を構造的に防ぐ入り口になる。
今月：最も重要な技術的負債1つに対してEIDを作成し、「ビジネス言語での説明」「修正コスト」「ROI」を定量化してスプリントに組み込む。1件でも経営層に通れば、次からの議論が変わる。
コメント