レッスン 19: 技術的負債と保守性

GitHub Copilot を使用した Vibe コーディング: 基本から高度まで

パート 6: プロフェッショナルな Vibe コーディング — 品質、セキュリティ、プロダクション

xdev.asia

1. Vibe コーディングと技術的負債

Vibe コーディングを使用するとコードの作成が高速化されますが、注意しないと 技術的負債 これまでよりも速く。

GitClear からのデータ (2025):

メトリック	AI以前（2022年）	次のAI（2025年）	変更
コードチャーン	3.3%	7.1%	+115%
追加された行数/開発数/月	1,100	1,800	+64%
削除された行数/開発者/月	200	550	+175%
コードを移動/コピーしました	5%	11%	+120%

コードチャーン = コードを書き留めてから 2 週間以内に編集または削除してください。倍増の数字は次のことを示しています AIは最初から間違ったコードを作成しました。

2. Vibeコーディングによる技術的負債の原因

2.1.重複 — 重複したコード

AI は以下のコードを再利用する代わりに新しいコードを生成します。

// AI tạo helper function mới
function formatDate(date: Date): string {
  return date.toLocaleDateString('vi-VN');
}
// Mặc dù project đã có:
// src/utils/date.ts → formatDate()

2.2.不一致 — 不一致

// File A: AI dùng async/await
const data = await fetchUsers();
// File B: AI dùng .then()
fetchUsers().then(data => { ... });
// File C: AI dùng callback
fetchUsers((err, data) => { ... });

2.3.過度の抽象化 - 複雑化

// AI hay tạo Factory + Strategy + Builder cho task đơn giản:
class TaskBuilderFactory {
  createBuilder(type: string): TaskBuilder {
    // 50 lines of over-engineering
  }
}
// Thực tế chỉ cần:
function createTask(data: CreateTaskInput): Task {
return prisma.task.create({ data });
}

3. 技術的負債の検出

3.1.デッドコード検出

// Dùng knip để tìm dead code:
npx knip
// Output:
Unused files: src/utils/old-helper.ts
Unused exports: TaskBuilderFactory (src/builders/task.ts)
Unused dependencies: moment, lodash

3.2.重複検出

// Dùng jscpd:
npx jscpd src/
// Output:
Found 12 clones across 8 files
Total duplicated lines: 156 (8.3% of total)

3.3.複雑さの分析

// Dùng Copilot để phân tích:
@workspace Analyze cyclomatic complexity of all functions.
List functions with complexity > 10 and suggest refactoring.

4. AIによるリファクタリング

4.1.重複を抽出する

// Prompt:
I have similar date formatting logic in 5 files.
Extract into a shared utility module.
Show me which files to update and what to extract.

4.2.複雑な機能を簡素化する

// Prompt:
This function has 15 if-else branches.
Refactor using:
- Strategy pattern for different task types
- Early returns to reduce nesting
- Extract validation into separate function
Keep the same behavior, add tests to verify.

4.3.パターンの標準化

// Prompt:
Our codebase has inconsistent error handling:
- Some files use try/catch
- Some use .catch()
- Some don't handle errors at all
Standardize all API calls to use async/await with
a shared error handler middleware. Show me the changes
needed file by file.

5. AIによるドキュメント生成

// Prompt cho API documentation:
Generate OpenAPI 3.0 spec for all endpoints in src/routes/.
Include request/response schemas, auth requirements,
and example values.

// Prompt cho code documentation:
Add JSDoc comments to all exported functions in src/services/.
Include parameter descriptions, return types, and usage examples.
Explain the business logic, not just the code.

アーキテクチャ決定記録 (ADR)

// Prompt:
Create an ADR for our decision to use Prisma ORM with PostgreSQL.
Include:
- Context: why we needed an ORM
- Options considered: Prisma, TypeORM, Knex, Drizzle
- Decision and rationale
- Consequences and trade-offs
Follow the format in docs/adr/template.md

6. 技術的負債の防止

6.1.一貫性を保つためのカスタム指示

## Code Consistency Rules

Use async/await for all asynchronous operations
Import from @/utils for shared utilities
Follow barrel export pattern (index.ts)
Error handling: use AppError class with status codes
Date formatting: use dayjs, never native Date methods
API responses: use { data, error, meta } format
Check existing utilities before creating new ones

6.2.建築用ガードレール

// eslint-plugin-boundaries — enforce architecture:
{
  "rules": {
    "boundaries/element-types": [2, {
      "default": "disallow",
      "rules": [
        // Controllers can import services, not other controllers
        { "from": "controllers", "allow": ["services", "types"] },
        // Services can import repositories, not controllers
        { "from": "services", "allow": ["repositories", "types"] },
      ]
    }]
  }
}

6.3.定期的なデットスプリント

// Dùng AI để plan refactoring sprint:
@workspace Analyze the codebase and identify:
1. Top 5 files with highest complexity
2. Most duplicated code patterns
3. Unused dependencies and dead exports
4. Files that violate our architecture boundaries
Prioritize by impact and create a refactoring plan.

7. 技術的負債を追跡する指標

メトリック	ツール	ターゲット
コードチャーン	GitClear、git ログ分析	2週間で5%未満
重複	jscpd、SonarQube	コードベースの合計が 3% 未満
デッドコード	クニップ、TSプルーン	0 未使用のエクスポート
複雑さ	ESLint の複雑さのルール	機能ごとに最大 15 個
依存関係の鮮度	npm が古い、改修する	後ろにメジャーはいない
テストカバレッジ	冗談の報道	全体で 80% 以上

8. まとめ

黄金律: できるときは Vibe コーディングが最適です 読解力と維持力 生成された AI コードの各行。 AI が書くコードを理解していなければ、それは技術的負債になります。

戦略	ツール
予防	カスタム命令、アーキテクチャルール
検出	knip、jscpd、SonarQube、AI レビュー
解像度	AI 支援リファクタリング、デット スプリント
モニタリング	メトリクス ダッシュボード、CI/CD ゲート

最後の投稿: チームとプロダクションでのバイブコーディング — 企業での導入、CI/CD、コラボレーション、Vibe コーディングの将来。