この記事は約 5 分で読めます。

筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ

個人開発の SaaS で 「テストコードの追加・修正を伴わないソースコード変更はコミットしない」 を明文化した話を整理します。運用中のAI業務管理秘書 SaaS 「たすきば Knowledge Relay」 で、半年間 CI red を 1 件も持ち越さなかった運用ルールです。

サービスの機能紹介・画面イメージ・コンセプトは公式プロダクトページをご覧ください。
👉 たすきば Knowledge Relay — 公式プロダクトページ

こんな日、ありませんか？

「今日は機能を急ぎたい、テストは後で書く」
「小さな変更だから、テストはいらない」
「E2E が落ちなければ大丈夫だろう」

こうした判断を許すと、テストのない領域がじわじわ広がります。

最初のうちは平気
3 ヶ月後にバグが出る
6 ヶ月後にリグレッションが頻発する
1 年後に「この機能、テストないからリファクタできない」と動けなくなる

これを防ぐため、たすきばは 「テストコードを伴わないコミットを禁止」 をルール化しました。

1. ルールの文言 — CLAUDE.md に明記

CLAUDE.md (Claude Code 運用ガイド) に書いている文言:

## コミットルール

- **テストコードの追加・修正を伴わないソースコード変更はコミットしない**
- コミットメッセージは変更内容を端的に記述する
- コミットは Claude Code が勝手にやらず、必ずユーザに確認してから実施する
- `main` / `master` / `develop` / `release/*` / `hotfix/*` への直接コミットは禁止

1 行目が肝。ソースコード変更 = テストコード変更が常にペア、というルールです。

2. テスト不要な変更の例外

ルールには例外があります。

変更の種類	テスト要否
機能追加 (新規 page / route / Service 関数)	✅ 必須
バグ修正	✅ バグ再現テストを必須
リファクタリング (挙動変更なし)	△ 既存テストで十分なら追加不要
型定義のみの変更	❌ 不要
コメント / docs のみの変更	❌ 不要
環境変数 / 設定ファイルのみ	❌ 不要

「ソースコードのロジックを変更する場合」は必須。ロジックに影響しない変更 (リネーム / 型 / docs) は例外。

3. バグ修正には再現テストを必須

バグ修正 PR では、バグを再現するテストケース を必ず追加します。

describe('billing invariant', () => {
  it('counter と ApiCallLog SUM が乖離したとき drift audit に記録される (PR #xxx の再現)', async () => {
    // バグを再現するセットアップ
    // アサーション
  });
});

これにより:

バグの存在が code で明示される (将来の自分への docs)
再発防止 (同じバグでテストが落ちる)
KDD / changelog に紐付けられる

バグ修正の品質を上げる最小限の習慣です。

4. テストカバレッジは KPI にしない

ただし、テストカバレッジ % を KPI にはしていません。

カバレッジ 100% を目指すと:

意味のないテストが量産される (テストのためのテスト)
重要なロジックに 5 件テスト書くより、雑なロジックに 1 件で 100% を取りに行く
mock が複雑化する

数字を追うと 本末転倒 になります。

たすきばは「テストコードと一緒にコミットする」をルールにする一方、カバレッジは 目安として参照するだけ です。

5. テストを書きやすい設計が自然と育つ

テストを必須にすると、自然と 「テストを書きやすい設計」 になります。

例:

関数の引数に必要な context をすべて渡す (グローバル変数に依存しない)
副作用 (DB 書き込み / API 呼び出し) を最外周に閉じ込める
引数と返り値で振る舞いが決まる pure な関数を増やす

これが Clean Architecture や Hexagonal Architecture と相性が良いです。

たすきばの Service 層は、context 引数で viewerTenantId / viewerUserId をすべて受け取る設計です。これにより、テストで context を簡単に差し替えられます。

test('listProjects は viewerTenantId のプロジェクトだけ返す', async () => {
  await createProject({ tenantId: 'A', name: 'P1' });
  await createProject({ tenantId: 'B', name: 'P2' });

  const result = await listProjects({
    viewerTenantId: 'A',
    viewerUserId: 'any',
  });

  expect(result).toHaveLength(1);
  expect(result[0].name).toBe('P1');
});

context をオブジェクトで渡すパターンにしておくと、テストでも本番でも同じ形で呼べる。設計がテストに引っ張られる のはむしろ望ましい副作用です。

6. テストを書く時間の目安

個人開発で「テストを書く時間がない」のは、テストを書かない理由になりません。

目安として:

作業	テスト時間
1 機能の実装に 1 時間	テストに 30 分
バグ修正に 30 分	再現テストに 15 分

「実装時間の 30〜50% をテストに使う」 のが目安です。

最初は遅く感じますが、3 ヶ月後にはリグレッションが減り、開発が加速します。

7. AI 駆動開発でも同じルール

たすきばは Claude Code に開発を委ねる時期があります。そのとき、Claude Code に対しても 同じルール を適用します。

CLAUDE.md に明記しているため、Claude Code は機能変更時に必ずテストも追加します。

ユーザ: 「createProject 関数で、空文字 purpose を許可するように変更してください」
Claude: 「実装を変更しました。同時に、空文字 purpose で create できることを verify する
   テストを追加しました。」

ルールを文書化しておくと、AI も含めて全員が守れる のがポイントです。

8. ルール違反時の対処

万一、テストを伴わないコミットが入ってしまったら:

1. 即座に気づいたら、別 commit でテストを追加して push
2. PR に test 不足を明示
3. KDD / 再発防止ノートに記録

「未来の自分が見るための docs」 として、ルール違反の事例を残します。これにより、再発時の対処がスムーズになります。

おわりに — 品質を守るのは技術ではなく運用ルール

「品質を守る」のは技術ではなく、運用ルールである。

CI / lint / test framework は道具に過ぎません。
それを 「毎回使う」運用ルール があって初めて、品質が守られます。

ルール	効果
テストを伴わないコミットを禁止	テストのない領域がじわじわ増えない
バグ修正には再現テストを必須	再発防止
カバレッジを KPI にしない	テストのためのテストを避ける
AI 駆動でも同じルール	全員が守る

個人開発で品質を維持する最大のコツは、ルールを明文化し、例外を作らず、AI を含めて全員が守る こと。

たすきばが半年間、CI red を 1 件も持ち越さなかったのは、このルールのおかげです。

本記事のルールは、運用中のAI業務管理秘書 SaaS 「たすきば Knowledge Relay」 で実際に運用しているものです。
👉 たすきば Knowledge Relay — 公式プロダクトページ