Zenn で リファクタリング提案が来るたびに判断できない理由 が話題になりました。AI コーディングエージェントは、いまや 無数のリファクタリング提案を即座に出します。しかし現場で起きているのは、**「提案は来るが、受け入れてよいのか、優先すべきか、いま壊れないかを判断できない」という新しい停滞です。問題は「直せるか」ではなく、「どれを・なぜ・いま直すべきかを判断できるか」**に移りました。
受託開発の保守現場では、これは特に深刻です。**「AI の提案を鵜呑みにして動くコードを壊す」か、「判断できず提案を全部見送り、負債が積み上がる」**かの二択に陥りがちです。受託でシステムの保守を支える立場では、これは 「リファクタするか」ではなく、「価値とリスクで判断し、壊さず・説明できる形で改善し、運用に組み込んだ状態で引き渡せるか」を設計に組み込む課題だと捉えています。これまで ソフトデリート / 状態テーブルの DB 再設計受託（GH Media） で扱った 設計改善の判断、テスト自動化定着支援受託（GH Media） で扱った 壊さない安全網、EY の AI ハルシネーション報告に学ぶ成果物 QA 受託（GH Media） で扱った AI 成果物の検証と接続して、本記事では 「リファクタリング判断・技術的負債ガバナンス支援」を 受託パッケージとして整理します。
なぜ「いま」リファクタリングの「判断」なのか
| 観点 | 提案ベース（従来） | 判断ベース（2026） |
|---|---|---|
| きっかけ | 気づいたら直す | AI が大量提案 |
| ボトルネック | 直す手 | 判断する基準 |
| 採否 | 雰囲気で | 価値とリスクで |
| 優先 | 声の大きさ | 影響度で |
| 安全性 | 祈り | テストで担保 |
| 成果 | 場当たり改善 | 説明できる改善 |
つまり 「直せること」と「判断できること」は別物であり、受託でも 「価値とリスクで採否を判断し、壊さず・説明できる形で改善し、運用に組み込んだ状態で引き渡す」ことが品質の前提になりました。これにより 「迷わず・壊さず・根拠を説明できる改善」を成果物として保証できます。
受託案件で活きる 3 つの構造変化
構造 1: 「直す手」から「判断する基準」へ
AI が手を提供する以上、希少なのは判断です。受託では 価値・リスク・コストの判断軸を整え、採否を迷わず決められるようにします。
構造 2: 「雰囲気の採否」から「価値とリスク」へ
好みでの採否は再現しません。受託では 影響度・回帰リスク・保守性の評価で、説明できる採否を提供します。
構造 3: 「祈りの変更」から「テストで担保」へ
テストなき改善は事故です。受託では 安全網となるテストと段階的適用で、壊さない改善を引き渡します。
受託で提供する「リファクタリング判断・負債ガバナンス支援」5 フェーズ
フェーズ 1: 現状診断（1 週間）
- 技術的負債の棚卸しと可視化
- 変更が集中する / 壊れやすい箇所の特定
- 既存テスト・安全網の有無の確認
- AI 提案の運用状況のヒアリング
フェーズ 2: 判断軸の設計（1 週間）
- 価値 / リスク / コストの評価軸の定義
- 採否・優先度のルール化
- 「いま直す / 後で直す / 直さない」の基準
- AI 提案のレビュー運用の設計
フェーズ 3: 安全網の整備（1〜2 週間）
- 高リスク箇所のテスト整備
- 段階的リファクタの手順設計
- レビューでの判断軸の必須化
フェーズ 4: 改善実行（2〜3 週間）
- 優先度の高い負債から段階的に改善
- 各変更を小さく・テスト付きで適用
- 判断の根拠を記録（なぜ直したか）
フェーズ 5: 継続運用（継続）
- 負債の定期棚卸し
- 判断軸の見直し
- 新規提案のレビュー運用の定着
受託向け判断軸の標準セット
| 評価軸 | 見るポイント | 判断への影響 |
|---|---|---|
| 価値 | 不具合 / 開発速度への寄与 | 高いほど優先 |
| 回帰リスク | 影響範囲 / テスト有無 | 高いほど慎重 |
| 頻度 | その箇所の変更頻度 | 高いほど優先 |
| コスト | 改修工数 | 大きいほど分割 |
| 可逆性 | 戻せるか | 低いほど慎重 |
| 説明性 | 根拠を示せるか | 必須 |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| AI 提案が多く判断に迷う | 提案をほぼ使わない |
| 技術的負債が積み上がっている | 新規で負債が少ない |
| 改修で壊す不安が常にある | テストが十分にある |
| 長期保守する基幹システム | 短命な検証用 |
| 改善の根拠を説明したい | 説明責任が薄い |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 改善する領域 | 優先順位の合意 |
| 判断基準 | 採否 / 優先のルール | 評価軸の合意 |
| 安全性 | テスト / 段階適用 | 壊さない前提 |
| 記録 | 判断根拠の残し方 | 説明責任 |
| 引き渡し | 判断軸 / Runbook | 自社で運用する前提 |
| 継続保守 | 定期棚卸し | 運用費用 |
価格モデル — リファクタリング判断・負債ガバナンスパッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 負債診断 | 30 万円〜 | 1 システム | 棚卸し + 判断軸レポート |
| ガバナンス導入 | 110 万円〜 | 中規模 | 判断軸 + 安全網 + レビュー運用 |
| 改善実行込み | 190 万円〜 | 中〜大規模 | + 優先負債の段階改善 |
| Lite 保守 | 8 万円〜 / 月 | 小規模 | 提案レビュー + 軽微改善 |
| Standard 保守 | 20 万円〜 / 月 | 中規模 | + 定期棚卸し + 改善提案 |
顧客側 ROI 試算（業務システム保守想定）
| 項目 | 既存（判断できない） | 判断ガバナンス | 差分 |
|---|---|---|---|
| 提案対応 | 鵜呑み or 全見送り | 価値で取捨 | 無駄な改修の削減 |
| 改修事故 | 壊して障害 | テストで防止 | 障害対応の削減 |
| 負債 | 積み上がる | 計画的に返済 | 開発速度の維持 |
| 説明責任 | 根拠が曖昧 | 記録で説明 | 顧客信頼の向上 |
| 年間効果 | — | — | 無駄改修の削減 + 改修事故の抑制 |
ガバナンス導入（110 万円〜）でも、鵜呑み改修による事故 1 件の回避と、無駄な改修工数の削減で十分に正当化できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: AI 提案を鵜呑みにする
動くコードを壊します。価値とリスクで判断します。
落とし穴 2: 判断できず全部見送る
負債が積み上がります。判断軸で取捨します。
落とし穴 3: テストなしで改善する
事故になります。安全網を先に整備します。
落とし穴 4: 一度に大きく変える
戻せなくなります。小さく段階的に適用します。
落とし穴 5: 判断の根拠を残さない
後で説明できません。なぜ直したかを記録します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | 負債棚卸し + 危険箇所の特定 |
| Week 2 | 判断軸 + 採否ルールの設計 |
| Week 3〜4 | 高リスク箇所の安全網整備 |
| Week 5〜7 | 優先負債の段階的改善 |
| Week 8〜13 | 定期棚卸し + レビュー運用の定着 |
まとめ — 「直せる時代」から「判断して・壊さず・説明して引き渡す」へ
AI が無数の提案を出す時代、希少なのは「直す手」ではなく「判断する基準」です。受託でシステム保守を支える立場では、価値とリスクで採否を判断し、安全網で壊さず、根拠を記録して引き渡す 「リファクタリング判断・負債ガバナンス支援」が、迷わず・壊さず・説明できる改善を成果物として届ける新しい主力サービスです。
弊社では負債診断 / ガバナンス導入 / 改善実行込み / Lite / Standard の各段階で本パッケージを提供しています。「AI 提案の採否に迷う」「負債が積み上がっている」「改修で壊すのが怖い」というご相談は お問い合わせフォーム からお気軽にどうぞ。
