月次リリースを控えた業務システムで、保守担当者がテスト不足を調べている場面を考えます。手元にあるのは、既存のソースコード、テストスイート、カバレッジレポート、障害票、仕様書です。担当者の目的はカバレッジ率を上げること自体ではなく、入力値の境界や外部処理の失敗時に、意図しない挙動が残っていないかを確かめることにあります。

AIを使わない場合、担当者は既存のテストコマンドを実行し、カバレッジレポートから未実行行を探します。その後、対象関数をIDEで開き、条件式、早期リターン、例外処理、呼び出し先をたどります。仕様書や過去の障害票と照合して期待動作を決め、既存テストの書式に合わせてテストケースを実装します。最後に対象テストと回帰テストを実行し、差分をレビューに回す流れです。

この方法は堅実ですが、未実行行が見つかっても、どの入力でその経路に入るのかは別途読み解かなければなりません。条件が複数組み合わさるコードでは、行カバレッジが付いていても、真偽の片側しか通っていない場合があります。例外を捕捉する分岐では、依存処理をどのように失敗させるかも設計が必要です。調査、分類、テストデータ作成が別々の作業になり、似た確認を何度も繰り返しがちでしょう。

この記事では、Claude Codeに対象範囲、既存の検証コマンド、期待動作、変更禁止範囲を渡し、未テスト分岐の調査とテスト案の作成を補助させます。Claude Codeの公式資料では、既存テストのスタイルやフレームワーク、アサーションの傾向を調べたうえでテストを生成でき、エラー条件、境界値、想定外の入力について候補を挙げられると案内されています（出典: Claude Code Docs）。ただし、仕様の確定、テストの妥当性判断、既存動作を変更してよいかという承認は、引き続き人が担当します。

未テスト分岐への対応は、「カバレッジレポートを見る」という一作業ではありません。負担が集中する工程は、対象の絞り込み、経路の追跡、期待動作の確定、既存形式への実装という四つに分けられます。ここを分けて観察すると、Claude Codeに補助させる部分と、人が判断すべき部分を整理しやすくなります。

対象の絞り込みでは、未実行行を機械的に拾うだけでなく、変更頻度、障害時の影響、外部入力との接点を考慮します。自動生成コードや到達不能と確認済みの防御処理まで同じ優先度で扱うと、テスト件数だけが増えてしまいます。対象モジュールを限定し、今回扱わないディレクトリや依存先を明示することが必要です。

経路の追跡では、条件式を成立させる入力を逆算します。たとえば下限値未満、下限値ちょうど、通常値、上限値ちょうど、上限値超過という区分があっても、前処理で値が丸められていれば、表面的な入力と分岐直前の値は一致しません。例外処理についても、単にモックを失敗させればよいとは限らず、タイムアウト、戻り値の欠落、型の不一致など、実際の契約に沿った失敗を選ぶ必要があります。

期待動作の確定には、コードだけでなく仕様書、公開インターフェース、既存テスト、障害票が関わります。実装と仕様が食い違っているとき、Claude Codeに現在の実装を正解としてテストを書かせると、不具合を固定する恐れがあります。根拠が見つからない挙動は推測で埋めず、「仕様確認が必要な未解決事項」として分離しなければなりません。

実装工程では、フィクスチャ、モック、命名規則、非同期処理の待機方法などを既存テストに合わせます。テストが通っても、共有状態への依存や実行順序依存があれば保守性を損ねます。AIに任せたいのは反復的な探索と下書きであり、どの振る舞いを契約として固定するかという設計判断ではありません。

比較条件をそろえるため、入力は同じリポジトリ、同じカバレッジ結果、同じ仕様資料とします。成果物も、既存のテスト規約に従ったテストコード、実行結果、判断根拠の一覧で統一します。AI利用後だけ対象範囲を狭くしたり、回帰確認を省いたりすると、効率化ではなく品質条件の変更になってしまいます。

| 工程 | AIを使わない場合 | Claude Codeで補助する部分 | 人が残す判断 |
| --- | --- | --- | --- |
| 対象選定 | レポートとコードを往復して候補を列挙 | 指定範囲の未実行分岐と関連テストを整理 | 優先度と今回の対象外を決定 |
| 経路調査 | 条件式と呼び出し関係を手作業で追跡 | 分岐へ到達する入力候補と依存処理を提示 | 実際に到達可能かを確認 |
| テスト設計 | 境界値と異常系を一件ずつ設計 | ケース表、前提、期待結果の下書きを作成 | 期待結果の仕様根拠を承認 |
| テスト実装 | 既存テストを参照しながら記述 | 既存パターンに合わせた変更案を作成 | 過剰なモックや実装依存を排除 |
| 検証 | テスト実行、差分確認、原因調査 | 指定した検証の実行と結果整理を補助 | 失敗の意味と採用可否を判断 |

Claude Codeを使うことで、未実行箇所、関連する条件式、既存テストの形式を一つの調査文脈にまとめやすくなります。担当者が個別に行っていた検索と転記を、候補一覧やケース表の作成まで連続した作業として依頼できるためです。公式資料でも、テストしてほしい振る舞いを具体的に伝えること、見落とした境界値やエラー条件の調査を求めることが案内されています（出典: Claude Code Docs）。

ただし、AIが挙げた分岐は調査候補であり、仕様上の必須テストと同義ではありません。逆に、カバレッジに現れない状態遷移や複数回呼び出し時の挙動が重要な場合もあります。AI利用後の工程では、探索結果をそのまま採用するのではなく、根拠付きの候補へ変換し、人が選別する位置付けが適切です。省略できるのは検索や下書きの反復であり、仕様判断と最終承認ではありません。

Claude Codeを開く前に、対象と品質条件を短い作業メモへまとめます。必要なのは、対象モジュール、既存テストの場所、通常利用しているテストコマンド、カバレッジ取得方法、参照できる仕様、変更禁止範囲です。コマンド名を一般例から推測せず、そのリポジトリで開発者やCIが実際に使っているものを記録してください。

基準状態も残します。変更前のコミットまたは作業ツリーの状態、対象テストの成否、カバレッジレポート、既知の失敗を保存します。既に落ちているテストがあるなら、今回の変更による失敗と混同しないよう一覧化が必要です。秘密情報、本番データ、顧客情報をテスト入力へ転用せず、匿名化したフィクスチャや合成データを用意します。

期待動作は、境界ごとに「入力」「前提状態」「期待する戻り値または例外」「根拠」を記載します。根拠には仕様書の節、公開インターフェースの説明、承認済みの障害対応方針などを使います。既存実装しか根拠がない場合は、その事実を明示します。実装が返している値を無条件に期待値へ写すと、欠陥を検出するテストではなく、現状を固定するテストになりかねません。

変更境界も具体化します。「テストだけを変更する」だけでは不十分です。製品コード、依存関係、スナップショット、共有フィクスチャ、CI設定を変更対象外とするのかを個別に決めます。テスト追加の途中で製品コードの不整合が見つかった場合は、同じ作業内で直さず、根拠と再現条件を別の課題として報告させる方がレビューしやすいでしょう。

編集前に調査結果と計画を確認したい場合は、Claude Codeのplan modeを利用できます。公式資料では、このモードではファイルを読み、変更案を提示しますが、承認するまで編集しないと説明されています（出典: Claude Code Docs）。計画の段階で対象ファイル、追加ケース、実行予定の検証、未解決事項を確認すれば、広すぎる変更をコードへ反映する前に止められます。

作業は、読み取り調査、テスト案の承認、限定的な実装、検証という四段階に分けます。一度の依頼で調査から修正まで進めるより、分岐の理解と期待動作を人が確認してから編集へ移る方が、誤った仕様をテストとして固定する危険を抑えられます。

第1段階では、対象リポジトリを開いたClaude Codeに、読み取りだけで未テスト候補を調べるよう依頼します。次のお願い文は架空のひな型です。角括弧の部分を自分のリポジトリに合わせて置き換えます。

コピーして使うお願い文:

対象は [対象モジュールまたはディレクトリ] です。
この段階ではファイルを変更しないでください。

次の資料を確認してください。
- 実装: [パス]
- 既存テスト: [パス]
- カバレッジ結果: [パス]
- 仕様または契約: [パス]

未実行または片側しか確認されていない条件分岐を候補として列挙し、
各候補について次を表にしてください。
1. 対象ファイルと条件
2. 分岐へ到達する入力と前提状態
3. 期待結果と根拠
4. 既存テストで確認済みの範囲
5. 境界値・異常系として追加する価値
6. 仕様が曖昧で人の判断が必要な点

コードだけから期待動作を推測した箇所は、推測と明記してください。
製品コード、依存関係、設定ファイルは変更対象外です。

第2段階では、提示された候補を担当者が絞り込みます。到達不能な防御分岐、外部ライブラリ内部の挙動、今回の変更目的と無関係な箇所は除外します。境界値については直前、ちょうど、直後の三点がすべて必要とは限りません。比較演算子、型変換、丸め処理を見て、異なる結果になる代表値を選びます。異常系も、実際のインターフェース契約で発生し得る失敗に限定します。

第3段階で、承認したケースだけを実装させます。ここでも許可するファイルを列挙し、製品コードへ問題を見つけた場合の扱いを指定します。

コピーして使う追加のお願い文:

承認するケースは [ケース番号] です。
変更してよいのは [テストファイルのパス] だけです。
既存テストの命名、セットアップ、アサーション、モックの方式に合わせてください。

各テストは、一つの振る舞いが分かる名前にしてください。
テスト間で変更可能な状態を共有しないでください。
製品コードの変更が必要だと判断した場合は編集せず、
理由、再現条件、影響範囲を報告して停止してください。

編集後は、追加したケースと仕様根拠の対応、変更ファイル一覧、
実行すべき検証コマンドを提示してください。

第4段階では、リポジトリで定められた対象テスト、関連テスト、より広い回帰テスト、カバレッジ取得を順に実施します。Claude Codeへ実行を依頼する場合でも、使用した正確なコマンド、終了状態、失敗内容を報告させます。環境や権限の都合で実行されなかった検証は、成功扱いにせず「未実行」として残し、人が同じコマンドを実行します。

Claude Codeから受け取る成果物は、テストコードだけではありません。未テスト分岐の候補表、採用したケース、期待動作の根拠、変更ファイル一覧、検証結果を一組として扱います。コードだけをレビューすると、「なぜこの値を期待するのか」が失われ、後から仕様変更と単なるテスト修正を区別しにくくなります。

架空の関数 `parseRetryLimit` を対象にした回答なら、次のような整理が考えられます。これは実際の製品仕様ではなく、成果物の形式を示す例です。

回答の例:

対象分岐: 再試行上限の入力検証
確認済み: 通常の整数値
追加候補:
- 未指定時に既定値を返すケース
- 許容下限ちょうどのケース
- 許容上限ちょうどのケース
- 上限を超えた値を拒否するケース
- 数値以外の型を拒否するケース

仕様根拠:
- 未指定時の動作: 設定仕様の該当節
- 上限値: 公開インターフェースの制約
- 数値以外の型: 根拠が見つからないため要確認

変更範囲: 対象テストファイルのみ
検証結果: 対象テストは実行済み、全体テストは未実行

レビューでは、各アサーションを仕様根拠まで逆にたどります。「現在の実装がそう返すから」という説明しかない場合は、承認を保留する余地があります。例外の型やメッセージ全文を固定するテストは、それが公開契約なのかを確認してください。内部実装の細部まで固定すると、振る舞いを変えないリファクタリングでもテストが壊れやすくなります。

テストが狙った分岐を本当に検証しているかも確認します。カバレッジが増えていても、アサーションが弱ければ回帰を検出できません。逆に、対象外の副作用や呼び出し回数を細かく検査しすぎると、実装依存が強まります。入力、観測可能な出力、状態変化、外部契約という観点で、必要十分な検証になっているかを人が判断します。

実行結果では、追加テスト単体の成功だけでなく、既存テストへの影響、実行順序を変えた際の安定性、共有フィクスチャの汚染を確認します。差分にはテスト以外の変更が混ざっていないか、スナップショットが大量更新されていないか、依存関係や設定が意図せず変わっていないかも見ます。失敗した検証が残る場合は、その原因と今回の変更との関係を切り分けてから承認します。

効果を確かめるときは、カバレッジ率だけを評価指標にしません。同程度の複雑さを持つ小さな対象を選び、AIを使わない回とClaude Codeを使う回で、調査開始からレビュー可能な成果物がそろうまでの工程を記録します。対象範囲、使用する仕様資料、検証コマンド、要求する品質条件はそろえてください。

記録する項目は、対象選定、経路調査、テスト設計、実装、検証、修正、レビューの各工程に分けます。所要時間に加えて、仕様確認が必要になった件数、最初の案から除外したテスト数、レビューで修正したアサーション数、未実行のまま残った検証も記録すると、単なる入力速度以外の違いが見えてきます。Claude Codeへの説明や結果の確認に要した手間も、利用後の工程へ含めなければなりません。

期待できる変化は、コード検索、既存テスト形式の把握、境界候補の列挙、定型的なテスト記述を一続きで扱えることです。条件分岐が多く、既存テストの規約が整っているリポジトリほど、反復的な探索と下書きをまとめやすいと考えられます。反対に、仕様が存在せず、テストも一貫していない場合は、入力を整える負担や人による修正が増えるでしょう。効果はリポジトリの状態と対象の切り方に左右されます。

最初の試行では、重要な決済処理や大規模な統合テストを選ぶ必要はありません。仕様根拠が確認できる一つの関数と、そのテストファイルだけに範囲を絞り、未テスト分岐を一つか二つ扱います。読み取り調査、候補の承認、テスト限定の編集、既存コマンドによる検証を一巡させてください。その記録から、Claude Codeへ渡す情報が不足していた箇所と、人が判断すべき境界を見直すことが、次の対象を広げるための具体的な一歩になります。

- Common workflows - Claude Code Docs