GitHub Copilotでテストコードを自動生成する方法｜/testsの使い方と生成テストの確かめ方【2026年10月】

GitHub Copilotでテストコードを自動生成する最短の方法は、テストしたい関数を選択し、Copilot Chatで /tests と入力することです。ユニットテストのひな型を生成できますが、所要時間は対象コードやモデルによって異なり、その中身が本当にバグを捕まえられるかも別途確認が必要です。この記事では、/tests・エージェント・cloud agentの使い分けと、JestとpytestのサンプルやCI設定に加えて、掲載サンプルのテストの強さをミューテーションテストで測った実測結果を、2026年10月時点の公式情報とあわせて解説します。

まとめ：GitHub Copilotでテストを自動生成する手順と確かめ方の要点

• 入口は4つ：関数単位なら Chat の /tests か右クリックの Generate Tests、複数ファイルの追加と実行・修正まで任せるならエージェント、Issue から PR まで任せるなら cloud agent。
• 精度は指示と文脈で決まる：観点（境界値・例外）とフレームワークを指示文に書き、既存のテストを文脈に入れる。2024年の実証研究では、既存のテストスイートがある状態で生成テストの45.28%が合格し、無い状態では92.45%が失敗・破損・空だった。
• 行カバレッジ100%は合格の証拠にならない：本記事の実測では、行・分岐カバレッジ100%のテストでも20個の変異のうち2個を見逃した。境界を2件足すと全部捕まえた。
• 期待値は仕様から書く：実装の出力を写したテストは、バグごと「正解」として固定される。
• 無料枠：Copilot Free は補完が月2,000回、チャットとエージェントはAIクレジットの枠内。cloud agent と Visual Studio の @Test は有料プランのみ。

GitHub Copilotのテスト自動生成の入口とIDE別の対応

GitHub Copilotは、GitHubが提供するAIコーディング支援ツールです。テストの自動生成は、作業の大きさに応じて入口を選びます。製品全体の機能と対応モデルはGitHub Copilotの対応モデル・機能・料金の解説で整理しています。

/tests・Generate Tests・エージェント・cloud agentの使い分け

VS Code の Generate Tests は、ファイルを開いて右クリックし、Generate Code から Generate Tests を選ぶと、既存のテストファイルに追記し、無ければ新しく作ります（VS Code公式のスマートアクション）。実務では /tests か Generate Tests で土台を作り、レビューで気づいた抜けをインライン補完で1件ずつ足す進め方を勧めます。

VS Code・Visual Studio・JetBrains・Eclipse・Xcodeでの対応

GitHub公式のCopilot Chatチートシートは、/tests を VS Code・Visual Studio・JetBrains・Xcode の各節に「選択したコードのユニットテストを生成する」コマンドとして載せています。Eclipse でも、IDE別の公式ガイドが /tests でアクティブなファイルか選択範囲のテストを依頼できると説明しています。失敗したテストを探して直す /fixTestFailure はチートシートでは VS Code の節だけに載っており、テストフレームワークの選定と設定を手伝う /setupTests は VS Code の機能一覧で Experimental 扱いです。

C# の場合は、Visual Studio 2026 の GitHub Copilot testing for .NET が別にあります。Copilot Chat で @Test に続けて対象を指定すると、MSTest・NUnit・xUnit のテストを生成し、Test Explorer で実行して失敗を直すところまで進めます。既存テストが無いソリューションでは MSTest で作ります。前提は version 18.3 以降と有料の Copilot 契約で、Microsoft Learn の概要は Free を対象外と明記しています。

言語は Python・JavaScript・TypeScript・Java・C#・Go・Ruby など主要言語で使え、pytest・Jest・JUnit・RSpec のような各言語の一般的なフレームワークで書きます。フレームワークは既存のテストから推測されるため、テストがまだ無いプロジェクトでは指示文に明記してください。

VS Codeの/testsでユニットテストを自動生成する手順

ここからは手を動かす手順です。下のコードは 2026年10月18日に Node.js 26.5.0 と Jest 30.5.2、Python 3.13 と pytest 9.1.1 で実行し、全件が通ることを確かめています。Copilot Chat の基本操作はGitHub Copilot Chatの使い方とマルチモデル対応、VS Code への導入はVS CodeでGitHub Copilotを使う導入手順を参照してください。

関数を選んで/testsを実行する4ステップとJestの例

1. テスト対象のファイルを開き、関数全体を選択する
2. Chat ビューを開くか、エディタ内で Ctrl+I（macOS は Cmd+I）を押してインラインチャットを開く
3. /tests と入力し、続けて観点とフレームワークを書く（例：境界値と例外系も Jest で）
4. 提案を確認し、新しいテストファイルとして保存するか既存のファイルに挿入する

次の割引計算関数を例にします。

// discount.js
function calculateDiscount(price, rate) {
  if (price < 0 || rate < 0 || rate > 1) {
    throw new Error('invalid');
  }
  return Math.round(price * (1 - rate));
}

module.exports = { calculateDiscount };

正常系・境界値・例外系を含むテストのサンプルが次です。後の実測では、このサンプルが見逃す境界条件を確認します。

// discount.test.js
const { calculateDiscount } = require('./discount');

test('割引が正しく計算される', () => {
  expect(calculateDiscount(1000, 0.2)).toBe(800);
  expect(calculateDiscount(999, 0.15)).toBe(849);
});

test('割引率0と1の境界', () => {
  expect(calculateDiscount(1000, 0)).toBe(1000);
  expect(calculateDiscount(1000, 1)).toBe(0);
});

test('不正な入力で例外を投げる', () => {
  expect(() => calculateDiscount(1000, 1.5)).toThrow('invalid');
  expect(() => calculateDiscount(-1, 0.1)).toThrow('invalid');
});

npm install --save-dev jest のあと npx jest で3件が通ります（Jest公式のGetting Started）。999 × 0.85 = 849.15 を Math.round で丸めた 849 のように、丸めが絡む期待値は手計算で確かめてから確定させます。このテストは行カバレッジ100%ですが、後の章で示すとおり、まだ見逃している誤りがあります。

pytestで観点を指示文に書いて生成する例

観点を書かずに /tests だけを送ると、正常系に偏ったテストになりやすくなります。GitHub公式のテスト作成チュートリアルも、エッジケース・例外処理・データ検証といった範囲をプロンプトで具体的に指定するよう勧めています。郵便番号を整形する関数に対しては、指示文を次のように書きます。

# zipcode.py
def normalize_zip(code: str) -> str:
    digits = code.replace("-", "").strip()
    if len(digits) != 7 or not digits.isdigit():
        raise ValueError("invalid zip")
    return f"{digits[:3]}-{digits[3:]}"

/tests normalize_zip のテストを pytest で書いてください。
ハイフンあり・なし、前後の空白、桁数不足、桁数超過、英字混入を
@pytest.mark.parametrize でまとめ、期待値は仕様から直接書き、
normalize_zip を呼んで期待値を計算しないでください。

# test_zipcode.py
import pytest
from zipcode import normalize_zip

@pytest.mark.parametrize("raw, expected", [
    ("1000001", "100-0001"),
    ("100-0001", "100-0001"),
    (" 1000001 ", "100-0001"),
])
def test_normalize_zip_ok(raw, expected):
    assert normalize_zip(raw) == expected

@pytest.mark.parametrize("raw", ["", "123456", "12345678", "abc-defg"])
def test_normalize_zip_invalid(raw):
    with pytest.raises(ValueError):
        normalize_zip(raw)

pip install pytest のあと pytest -q で7ケースが通ります。pytest 9 系は Python 3.10 以上が必要で、3.9 の環境では 8.4 系が入ります。最後の一文（期待値をテスト対象に計算させない）は、実装のバグを正解として固定しないための指示です。fixture や parametrize の書き方はpytestの使い方と書き方で詳しく扱っています。

インライン補完で抜けたケースを1件ずつ足す方法

テストファイルでテスト関数を書き始めると、Copilot がインライン補完で続きを提案します。Tab で採用、Esc で却下です。「価格0のケース」のようなコメントを書くと、それを手がかりに1ケース分を提案します。一式を作るのは /tests、レビューで気づいた1件を足すのは補完、と分けるとチャットのやり取りが減り、Free プランでもAIクレジットを使わずに済みます（補完はクレジットを消費しません）。

エージェントとcloud agentにテスト追加から実行まで任せる手順

複数ファイルにまたがるテストの追加や、テストを実行して失敗を直すところまで任せるならエージェントを使います。Ask・Edit・Agent の違いと有効化はGitHub Copilotエージェントモードの使い方で解説しています。

VS Code公式ガイドの5段階の進め方

VS Code公式のテスト追加ガイド（2026年10月14日承認版）は、次の順で進めるよう勧めています。

1. Chat ビューで Agent を選び、ファイルを編集させずにテストフレームワーク・置き場所・実行コマンド・既存テストの規約を調べさせる。既存のテストを一度実行し、元から落ちているものを記録しておく
2. 対象を1関数か1モジュールに絞り、要件を書いて「まだファイルを編集せずに」テストケースを提案させる
3. 合意したケースだけを、実装コードを変えずに追加させる
4. 新しいテストだけを実行させ、失敗の原因を「テストの設定」「期待値の誤り」「実装のバグ」に切り分けさせる
5. 差分と実行結果を人が確認する。アサーションの削除やテストのスキップで通した変更は受け入れない

ガイドの例では、3〜20文字のユーザー名を検証する関数に対して、境界の 2・3・20・21 文字をテストするよう示しています。Test Explorer で失敗したテストにカーソルを合わせ、Fix Test Failure（スパークルアイコン）を選んで修正を頼むこともできます。

cloud agentにIssueを割り当ててテストを追加させる方法

GitHub 上で Issue を Copilot に割り当てると、cloud agent が GitHub Actions 上の一時的な環境でコードを変更し、テストを実行して PR を作ります。「不足しているテストを計画して追加する」は公式が挙げる用途の一つです。有料プラン（Pro・Pro+・Max・Business・Enterprise）が対象で、Free では使えません。

運用で詰まりやすい点が2つあります。1つ目は、依存パッケージを入れないとエージェントがテストを実行できないことです。.github/workflows/copilot-setup-steps.yml に copilot-setup-steps という名前のジョブを1つだけ置き、npm ci などのセットアップを書きます。このファイルはデフォルトブランチに無いと動きません。2つ目は、GitHub Docsにあるとおり、Copilot が PR に push しても GitHub Actions のワークフローは既定では自動で走らないことです。PR のマージボックスで Approve and run workflows を押すまで CI の結果が出ません。

生成テストの規約をカスタム指示とプロンプトファイルで揃える設定

生成のたびに命名やフレームワークがぶれると、レビューの手間が増えます。リポジトリの .github/copilot-instructions.md にテストの規約を書くと、Chat とエージェントがそれを前提に生成します。VS Code公式ガイドも、実行コマンド・フレームワーク・モックの規約に加えて「失敗を通すためにアサーションを弱めない」といった歯止めをカスタム指示に保存するよう勧めています。

# テストの書き方
- JavaScript は Jest、Python は pytest を使う。新しいテストランナーは追加しない
- テスト名は日本語で「条件_期待結果」の形にする
- 期待値は仕様から直接書き、テスト対象の関数を呼んで計算しない
- ユニットテストでは外部 API とデータベースをモックし、ネットワークに接続しない。結合テストの接続先と実行条件は別途定める
- 正常系に加えて、境界値と例外系を各1件以上書く
- 失敗したテストを通すためにアサーションの削除、スキップ、期待値の変更をしない
- テストの実行コマンドは npx jest と pytest -q

毎回同じ手順で生成させたいときは、プロンプトファイルにまとめます。GitHub Docs の例では .github/prompts/generate-unit-tests.prompt.md に生成方針を書いて保存し、Chat で /generate-unit-tests と入力して呼び出します。プロンプトファイルはパブリックプレビューで、VS Code・Visual Studio・JetBrains IDE で使えます。どちらの仕組みも強制力は無いため、差分と実行結果の確認は省けません。配置場所や .instructions.md との違いはcopilot-instructions.mdの書き方と配置場所にまとめています。

掲載サンプルのミューテーションスコアと見逃した境界条件（実測）

「レビューする」だけでは、テストが誤りを捕まえられるかは分かりません。ミューテーションテストは、実装に小さな誤り（ミュータント）を自動で埋め込み、テストが落ちるかを数える方法です。落ちれば「検出」、通ってしまえば「見逃し」で、検出した割合がミューテーションスコアです。仕組みの詳細はミューテーションテストの仕組みとスコアの読み方で解説しています。

行カバレッジ100%でも2つの誤りを見逃した結果

前章の calculateDiscount に対して、テストの厚みを3段階に変え、Stryker 10.0.0 でミューテーションスコアを測りました（2026年10月18日・ミュータント20個・各回約7秒）。

前章のテストが見逃したのは、price < 0 を price <= 0 に変えた誤りと、rate < 0 の判定を消した誤りです。価格0と負の割引率のケースが無かったため、どちらの誤りが入ってもテストは通りました。カバレッジは「その行を通ったか」しか見ないので、100%でもこの差は見えません。追加した2件は次のとおりです。

test('価格0は受け付ける', () => {
  expect(calculateDiscount(0, 0.5)).toBe(0);
});

// 「不正な入力で例外を投げる」に1行追加
expect(() => calculateDiscount(1000, -0.1)).toThrow('invalid');

Stryker が残した見逃しの一覧は、そのまま Copilot への指示に使えます。「price <= 0 に変えても落ちないので、価格0のケースを足して」と書けば、足りないテストを狙って生成させられます。カバレッジの基準と目標の決め方はテストカバレッジのC0/C1/C2と目標設定を参照してください。

Strykerの導入と実行コマンド

Jest のプロジェクトなら、次の設定ファイルを置いて npx stryker run で動きます。

npm install --save-dev @stryker-mutator/core @stryker-mutator/jest-runner

続いて、プロジェクト直下に stryker.config.json を作成し、次のJSONを保存します。

{
  "testRunner": "jest",
  "mutate": ["discount.js"],
  "coverageAnalysis": "perTest",
  "reporters": ["clear-text", "html"]
}

ミュータントの数だけテストを走らせるため、大きなコードベース全体に毎回かけると時間がかかります。Copilot で生成したテストを受け入れる前に、変更した関数のファイルだけを mutate に指定して確かめる使い方が現実的です。Python には mutmut など同じ目的のツールがあります。

生成テストのレビュー観点：バグの固定・名前の食い違い・モック

ミューテーションスコアが高くても、期待値そのものが仕様と違えば意味がありません。人が見るべき点を、影響の大きい順に挙げます。

期待値を実装から写すとバグが正解になる例

Copilot はコードの見た目から意図を推測します。実装にバグがあると、そのバグの出力を期待値にしたテストが作られます。VS Code公式ガイドも、期待値を実装から推測させると既存のバグを正しい動作として残すおそれがあると注意しています。次は、四捨五入のつもりで Math.floor と書いた実装に対し、2種類のテストを実行した結果です。

// 実装の出力をスナップショットで保存したテスト
test('990円の15%引き', () => {
  expect(calculateDiscount(990, 0.15)).toMatchSnapshot();
});
// 結果：1 passed（スナップショットに 841 が書き込まれる）

// 仕様（四捨五入）から期待値を書いたテスト
test('990円の15%引き', () => {
  expect(calculateDiscount(990, 0.15)).toBe(842);
});
// 結果：1 failed（Expected: 842 / Received: 841）

990 × 0.85 = 841.5 なので仕様どおりなら 842 です。スナップショットは初回実行時に今の出力を正解として書き込むため、841 のまま通ります。Jest は CI 環境（--ci）ではスナップショットを新規に書き込まず失敗させるので、ローカルで生成したスナップショットをそのままコミットする流れが危険です。スナップショットの更新運用はスナップショットテストの実装と更新運用で扱っています。

テスト名と中身の食い違いとモックの範囲

テスト名と中身が合わない例は、公式チュートリアルの生成例にもあります。GitHub のテスト作成チュートリアルでは、deposit(0) を検証するテストに test_deposit_negative_amount_raises_error（負の金額）という名前が付いていました。名前を信じて読むと見落とすので、アサーションの入力値を1件ずつ確かめます。

データベースや外部 API に依存する関数では、モックが本来検証したい振る舞いまで置き換えていないかを見ます。テスト対象を呼ばずにモックの戻り値だけを確認するテストは、対象の実装を検証していません。対象を経由する場合も、その戻り値だけで要件を検証できているか確認します。テストダブルの使い分けはモックとスタブの違いとテストダブル5分類が参考になります。

既存テストの有無で変わる生成テストの合格率

デルフト工科大学の El Haji らによる実証研究（AST 2024）は、オープンソースの Python プロジェクトで Copilot に290件のテストを生成させました。論文の要旨によると、既存のテストスイートがある状態では約45.28%が合格し、54.72%が失敗・破損・空のテストでした。既存テストが無い状態では92.45%が失敗・破損・空でした。生成は2022年12月〜2023年5月に PyCharm の Copilot プラグインの補完で行われており、現在のエージェントとは条件が違います。それでも「既存テストを文脈に入れると使えるテストが増える」という方向は、公式の推奨と一致します。新規プロジェクトでは、最初の数件を人が書いて規約の見本にしてから生成させると安定します。

GitHub Actionsで生成テストを毎回実行するワークフロー設定

生成したテストは CI に組み込み、push と PR のたびに実行します。.github/workflows/test.yml に次の内容を置きます。2026年10月18日時点で actions/checkout と actions/setup-node の最新メジャーは v7、Node.js の Active LTS は 24 です。

name: test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npx jest --ci --coverage

--ci は新しいスナップショットの自動保存を防ぎます。ただし、誤った出力を保存済みのスナップショットはCIでも通るため、保存・更新時に期待値を仕様と照合する必要があります。ビルドとテストを分ける構成やキャッシュの設定はGitHub Actionsでビルド・自動テストを設定する方法にまとめています。

テストコード自動生成AIの無料枠と料金の比較

「テストコード生成を無料でできるか」という観点でも検索されています。2026年10月時点の主な選択肢を整理します。

Copilot Freeで使える範囲

GitHub公式のプラン一覧では、Copilot Free の補完は月2,000回までです。/tests を含むチャットとエージェントはAIクレジットの枠内で使え、Free の枠の大きさは公表されていません。2026年6月1日に課金がAIクレジット制へ移り、以前の資料にあった「月50回のチャット」という回数の上限は、現行のプラン一覧には載っていません。モデルは自動選択のみで、cloud agent は対象外です。無料枠で足りるかは利用量によって異なります。エージェントでテストの生成・実行・修正を繰り返す場合は、使用量画面で残量を確認してください。

有料プランの価格とAIクレジット

1クレジットは0.01ドルで、消費量は使うモデルとトークン量で変わります。表のflexは変動する追加付与枠で、記載した月間合計が将来も固定されるわけではありません。個人向けの課金説明は、エージェントモードや cloud agent は1つの作業で複数回モデルを呼ぶため、チャットの質問より大きく消費すると書いています。有料プランでは補完と次の編集候補はクレジットを消費せず、無制限です。プランごとの使用量の集計方法はGitHub Copilotの料金とAI Credits移行後のプラン比較で解説しています。

Amazon Q Developer・汎用AIとの違い

AWS のサポート終了の告知によると、Amazon Q Developer の IDE プラグインは2027年4月30日にサポートを終え、同等の機能は Kiro へ移ります。これから選ぶ対象にはなりにくく、Kiro の位置づけはKiroの特徴・料金・使い方で整理しています。

ChatGPT などの汎用AIにコードを貼り付ける方法は無料枠でも使えます。ただしリポジトリの既存テストや設定を自動では読まないので、代表的なテストと規約も一緒に渡してください。先の研究はCopilotの補完を対象としており、汎用AIの性能を直接評価したものではありません。社外サービスにソースを貼ってよいかという社内規程の確認も先に要ります。

Copilotのテスト自動生成を採用する条件と見送る場面

入出力が明確な純粋関数、バリデーション、変換処理が多いコードベースでは採用すべきです。テストの土台づくりの時間が縮み、既存テストと命名規約が決まっているほど結果が安定します。ミューテーションテストを生成テストの受け入れ条件に入れれば、「数は多いが何も捕まえないテスト」を機械的に弾けます。

見送るべきなのは、仕様書が無く「今の動作が正しいか」を誰も答えられないレガシーコードです。Copilot は今の挙動を固定するだけで、品質保証になりません。決済や権限判定のように誤りの影響が大きい箇所も、観点は人が設計し、Copilot には決めた観点の記述を手伝わせる程度にとどめます。テストの件数を目標にしているチームでは、重複したテストが増えるだけです。

テスト自動化を CI/CD まで含めて整えたい、既存システムにテストの土台を後から入れたいといった場合は、一創のDevOps・CI/CD導入支援で、テスト戦略の設計から GitHub Actions への組み込みまでご相談いただけます。

よくある質問

GitHub Copilotでテストコードは自動生成できますか？

できます。テスト対象の関数を選択して Copilot Chat で /tests を実行するか、VS Code で右クリックから Generate Tests を選ぶと、ユニットテストが生成されます。複数ファイルへの追加や実行・修正はエージェント、Issue から PR までは cloud agent が担います。生成されたテストは、期待値を仕様と照らしてから採用します。

GitHub Copilotは無料でテスト生成に使えますか？

使えます。Copilot Free は補完が月2,000回、/tests を含むチャットとエージェントはAIクレジットの枠内で使えます（2026年10月時点）。枠の大きさは公表されておらず、モデルは自動選択のみです。cloud agent と Visual Studio の @Test は有料プランが必要です。

VS Codeで/testsはどう使いますか？

関数を選択し、Chat ビューかインラインチャット（Ctrl+I、macOS は Cmd+I）で /tests と入力します。続けて「境界値と例外系も」「pytest で」のように観点とフレームワークを書くと、正常系に偏らないテストになります。既存のテストファイルを開いておくと、その書き方に合わせて生成します。

生成されたテストの品質はどう確かめればよいですか？

期待値が仕様どおりかを人が読み、加えてミューテーションテストで誤りを捕まえられるかを測ります。行カバレッジは通った行を数えるだけなので、本記事の実測では100%でも20個中2個の誤りを見逃しました。Stryker（JavaScript）や mutmut（Python）で見逃しを洗い出し、その一覧を Copilot への追加指示に使います。

テスト駆動開発（TDD）にも使えますか？

使えます。実装より先に、仕様から期待値を定めてテストを書くことで、実装のバグを期待値として固定するリスクを減らせます。ただし、仕様の読み違いや根拠のない期待値は別途レビューが必要です。VS Code の公式ガイドには、Red・Green・Refactor の各段階をカスタムエージェントに分けて受け渡す構成例もあります。手順の基本はTDD（テスト駆動開発）のRed・Green・Refactorの回し方で解説しています。

関連記事

• GitHub Copilot Chatとは？使い方・料金・マルチモデル対応を2026年版で解説
• GitHub Copilotエージェントモードの使い方｜Ask・Edit・Agentの違いと有効化・料金【2026年版】
• copilot-instructions.mdとは？書き方とサンプル・配置場所、AGENTS.mdとの違い【2026年10月】
• ミューテーションテストとは？ミュータント生成とスコアの読み方を実装者向けに解説
• GitHub Copilotの料金（pricing）｜AI Credits移行後のプラン比較とBilling APIでの使用量集計【2026年10月】