Claude Codeのテスト機能、どこまで使いこなせてますか？
室谷今回はClaude Codeを使ったテスト、QA、ハーネスの話をしましょう。「テスト書いてもらえる」くらいは知ってる人も多いと思うんですが、実はここ、もっと深い使い方があるんですよね。
テキトー教師ですよね。.AI（ドットエーアイ）のコミュニティのメンバーさんでも「Claude Codeでコードは書けるけど、テストはどうすればいいの？」って声が結構あります。
テスト自動化まで話が及ぶと途端にハードルが上がる感じで。
テスト自動化まで話が及ぶと途端にハードルが上がる感じで。
室谷海外では2026年に入ってから「ハーネスの重要性」がかなり注目されてきてるんですよね。Cursorの中の人がA/Bテスト体制を公開して、「モデルよりハーネスが重要」という話がデータで実証されて話題になったりして・・・
テキトー教師それ、私も追ってました。同じClaude Opusを使っても、ターミナルで直接実行すると77%、Cursor内で実行すると93%って、+16ポイントの差が出るって結果でしたよね。
モデルのスペックよりも「どういう環境で動かすか」の方が大事だと。
モデルのスペックよりも「どういう環境で動かすか」の方が大事だと。
室谷まさにそこなんですよね。で、この「ハーネス」という概念がClaude Code自体にも深く関係してくる。
Claude Codeのテスト機能を最大限に使うには、テストを「書いてもらう」だけじゃなくて、テストを「回す仕組み」を整えることが重要なんです。
Claude Codeのテスト機能を最大限に使うには、テストを「書いてもらう」だけじゃなくて、テストを「回す仕組み」を整えることが重要なんです。
テキトー教師今日はその全体像を整理しましょう。「テスト生成」「QAワークフロー」「テストハーネスとしてのClaude Code」の3つの軸で話していきます。
前回はClaude Codeのワークフロー全般を解説しましたが、今回はテストに絞って深掘りします。
前回はClaude Codeのワークフロー全般を解説しましたが、今回はテストに絞って深掘りします。
Claude Codeで「テストを書く」：基本から始めよう
テキトー教師まず一番シンプルな使い方から。既存のコードにテストを追加してもらうパターンです。
コミュニティのメンバーさんがよく「どんなプロンプトを書けばいいの？」って聞いてくるので、ここから話すのが一番わかりやすいと思います。
コミュニティのメンバーさんがよく「どんなプロンプトを書けばいいの？」って聞いてくるので、ここから話すのが一番わかりやすいと思います。
室谷公式ドキュメントで推奨されてるワークフローが実はかなり実践的で。まず「テストされていないコードを見つける」、次に「テストの土台を生成する」、最後に「エッジケースのテストを追加する」という3ステップです。
テキトー教師この順序が大事ですよね。いきなり「全部テストして」ってやると、Claude Codeが重複したテストを量産したり、プロジェクトのテストスタイルと合わないコードを書いたりすることがある。
プロジェクトのコンテキストを読み込んでから進める方が精度が上がります。
プロジェクトのコンテキストを読み込んでから進める方が精度が上がります。
室谷具体的には、既存のテストファイルがあればClaude Codeはそれを参考にしてスタイルを合わせてくれます。フレームワーク、assertionのパターン、命名規則、全部既存コードから学習してくれるので、「新しく書いたコードだけ浮く」という事態が起きにくいんですよね。
テキトー教師海外のテスト自動化エンジニア（Bas Dijkstraさん）が検証した実験が興味深くて。Spring Boot製のAPIにClaude Codeでテストを書かせたところ、約2分で23件のテストが生成されて、ラインカバレッジ95%、ミューテーションカバレッジ91%を達成したって。
室谷それ、人間が書くより圧倒的に速いですよね。MYUUUでも実際に体験してますが、「テストの土台を作る」という作業に関しては本当に時間が変わります。
ただ・・・
ただ・・・
テキトー教師ただ、「完璧」ではないですよね。その検証でも、23件中4件は「デッドウェイト」（他のテストと重複して意味のないテスト）だったし、いくつかのエッジケースが抜けてたと報告されてます。
室谷そこがポイントで、Claude Codeのテスト生成は「スタートダッシュ」として使うのが正解なんですよね。人間がゼロから書くより遥かに速く土台ができる。
でもそこからのレビューと改善は人間がやる必要がある。
でもそこからのレビューと改善は人間がやる必要がある。
テスト生成の実践的なプロンプト例
テキトー教師整理すると、実際に使えるプロンプトパターンはこんな感じです。
# 未テストコードの特定
find functions in NotificationsService.swift that are not covered by tests
# テスト土台の生成
add tests for the notification service
# エッジケースの追加
add test cases for edge conditions in the notification service
# テスト実行と修正
run the new tests and fix any failures
最後の「run the new tests and fix any failures」がかなり強力で。テストを書くだけじゃなくて、実際に動かして失敗したら直してもらう、というループを回せるんですよね。
テキトー教師それ、最初に触った時は結構衝撃でした。テスト書いて、実行して、エラー見て、直して、また実行する・・・という繰り返しをClaude Codeが自律的にやってくれる。
人間がやると1時間かかる作業が20分くらいで終わることがあります。
人間がやると1時間かかる作業が20分くらいで終わることがあります。
室谷ただ注意点として、Claude Codeは「書き慣れてる」テストフレームワークと「そうじゃない」フレームワークで精度がかなり変わります。JUnit、pytest、Jest、RSpecあたりは精度が高い。
マイナーなフレームワークや独自のテストスイートだと、事前にCLAUDE.mdで規約を書いておく必要があります。
マイナーなフレームワークや独自のテストスイートだと、事前にCLAUDE.mdで規約を書いておく必要があります。
テキトー教師CLAUDE.mdにテストの書き方を定義しておくことで、毎回ブリーフィングしなくても一貫したスタイルのテストを書いてくれるようになりますよね。講座でもここは強調してます。
「CLAUDE.mdは設定ファイルじゃなくてコーチへの指示書だと思え」って。
「CLAUDE.mdは設定ファイルじゃなくてコーチへの指示書だと思え」って。
テストハーネスとしてのClaude Code：「動かす仕組み」を設計する
室谷ここからが本題というか、エンジニアが一番差をつけられる部分なんですよね。「テストを書かせる」から「テストを回す仕組みに組み込む」への進化です。
テキトー教師Claude Code自体を「テストハーネス」として使う、という発想ですね。単体のテストを書いてもらうんじゃなくて、CI/CDパイプラインや開発フロー全体にClaude Codeを組み込む。
室谷最近海外でかなり話題になったのが「モデルよりハーネスが重要」という話で。簡単に説明すると、同じAIモデルを使っても、どういう「ハーネス（実行環境・制御ロジック）」で動かすかで成果物の品質がガラッと変わるという話なんですよね。
テキトー教師このデータ、結構衝撃ですよね。Claude Opusで+16ポイント、GPT-5.4で+6ポイント、Gemini 3.1 Proで+5ポイント、全モデル平均で+11ポイント。
ハーネスの差でこれだけ変わる。
ハーネスの差でこれだけ変わる。
室谷だから「どのモデルを使うか」の議論ばかりしてるより、「どういう仕組みで動かすか」を考える方が実は費用対効果が高いんですよね。これはテストだけじゃなくて開発全体に言えることで・・・
テキトー教師テスト文脈で具体的に言うと、「Claude Codeに直接テスト書かせる」のと「テスト戦略を設計してからClaude Codeを使う」のでは、結果の質が全然違うということですね。CLAUDE.mdやhooksを使って「どういうテストを書くべきか」の文脈をしっかり渡してあげる。
Claude Code Hooksを使ったテスト自動化
室谷Claude Code Hooksがここでかなり活きてくるんですよね。コードを変更したタイミングで自動的にテストを実行する、みたいな仕組みを作れます。
テキトー教師Hooksの設定例を見てみましょう。PostToolUseフックを使うと、Claude Codeがファイルを変更した後に自動でテストを走らせるできます。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npm test -- --passWithNoTests"
}
]
}
]
}
}
ただこれ、そのまま使うと「ファイルを1つ変えるたびにテスト全部走る」という状況になるので、変更したファイルに関連するテストだけを走らせる設定にした方がいいですね。MYUUUでは変更箇所に関係するテストファイルだけをターゲットする形にしてます。
テキトー教師コミュニティのメンバーさんから「Hooksでテスト自動化したら逆に遅くなった」という声を聞くことがあるんですが、大抵の場合はスコープが広すぎるんですよね。全テストじゃなくて「smoke test」か「変更ファイルに関連するテスト」に絞る。
室谷Verification processへの組み込みという観点だと、公式でも「Claude Codeをverificationプロセスに追加する」という使い方が推奨されてます。具体的には、コードレビューの前に自動でテストを走らせて、失敗したらClaude Codeに修正させる、というループです。
テキトー教師CI/CDへの統合パターンとして整理するとこうなります。
| 段階 | Claude Codeの役割 | 自動化の方法 |
|---|---|---|
| コーディング中 | テスト生成・補完 | hooksでコード変更後にテスト実行 |
| PR作成前 | テスト網羅率確認・追加 | Pre-commit hookでカバレッジチェック |
| CI/CD実行中 | 失敗テストの自動修正 | GitHub ActionsでClaude Code実行 |
| デプロイ後 | 本番環境のスモークテスト | Playwright CLIで自動動作確認 |
室谷このテーブル、かなりよくまとまってますね。特に「デプロイ後のスモークテスト」まで含めてるのが実践的で。
自動デプロイした後に「本当に動いてる？」を確認するフローにClaude Codeを組み込んでいる会社が海外では増えてきてます。
自動デプロイした後に「本当に動いてる？」を確認するフローにClaude Codeを組み込んでいる会社が海外では増えてきてます。
Claude Code QA活用：テスト戦略はどう変わるか
テキトー教師ここで少し視点を変えましょう。QAエンジニア視点でClaude Codeをどう使うか、という話です。
「テストコードを書く」という作業から「テスト戦略を設計してAIを動かす」という仕事への変化ですね。
「テストコードを書く」という作業から「テスト戦略を設計してAIを動かす」という仕事への変化ですね。
室谷これ、海外でもかなり議論されてます。「QAエンジニアは不要になる？」という問いに対して、答えは「QAエンジニアの仕事が変わる」という方向に収束してきてる感じで。
テキトー教師実際、Claude Codeが得意なのは「繰り返し性の高いテスト生成」と「既知のパターンの網羅」なんですよね。ログイン・フォーム送信・ファイルアップロードみたいな、パターンが明確なテストは爆速で作れる。
室谷一方で、「このユーザーストーリーのエッジケースって何だろう？」「このビジネスロジック、本当にこの動作が正しいの？」みたいな判断は、まだ人間の方が強い部分が多いんですよね・・・
テキトー教師QAエンジニアが持つドメイン知識が、Claude Codeの文脈として機能するわけですよね。「どういうテストを書くべきか」を人間が設計して、「どうテストコードに落とすか」をClaude Codeが担当する。
室谷MYUUUでも実際にそういう分業になってきてます。テストアーキテクチャを考えるのは人間、実装はClaude Code。
で、実装されたものをレビューするのも人間、という感じで。
で、実装されたものをレビューするのも人間、という感じで。
テスト生成の精度を上げるCLAUDE.mdの書き方
テキトー教師QAエンジニア視点での一番のTipsが「CLAUDE.mdにテスト規約を書く」ことなんですよね。これを整備してる会社と整備してない会社で、生成されるテストの品質が全然違います。
室谷具体的にどういうことを書くべきか、整理するとこうなります。
## テスト規約
### フレームワーク
- 単体テスト: Jest（TypeScriptプロジェクト）
- E2Eテスト: Playwright
- APIテスト: supertest
### 命名規則
- describe: テスト対象のクラス・関数名
- it/test: 「〇〇のとき、〇〇する」形式
- ファイル: {対象ファイル名}.test.ts
### テストの原則
- AAA（Arrange-Act-Assert）パターンを使う
- モックは最小限に。実際の実装を優先
- 1テスト1アサーション（複数assertは別テストに分ける）
- ハッピーパスとエラーケースを両方テストする
### カバレッジ基準
- ラインカバレッジ: 80%以上
- ブランチカバレッジ: 70%以上
- 新規ファイルは90%以上を目指す
これを書いておくだけで、毎回「JestでAAA形式で書いて」とか説明しなくて済む。Claude Codeが初見のファイルでも同じ規約でテストを書いてくれます。
室谷CLAUDE.mdを「設定ファイル」じゃなくて「チームのコーディング標準書」として捉える、という感覚ですね。テスト以外のコーディング規約も同じファイルに書いておくと、全体的にチームの標準が守られやすくなります。
Claude Code + Playwright：E2Eテストの自動化
室谷E2Eテスト（エンドツーエンドテスト）の自動化も、Claude Codeと組み合わせるとかなり変わるんですよね。特に「探索的テスト（Exploratory Testing）」との組み合わせが面白くて・・・
テキトー教師PlaywrightとClaude Codeの組み合わせですよね。「このフォームのバリデーション、全パターン試して」って言うだけで、空欄・特殊文字・最大文字数超えなど、手動でやると面倒なケースを全部試してくれる。
室谷室谷のiOSシミュレーターの話もあったじゃないですか。「Claude Codeにシミュレーターを向けて『全部テストして』って言うだけで、アプリの全画面・全機能を自律的にテストするツール」・・・これウェブのE2Eテストでも近いことが起き始めてます。
テキトー教師Playwright CLIが特に効率的なのは、MCPベースのブラウザツールより「トークン効率が高い」点ですね。スクリーンショットを送るんじゃなくて構造化コマンドを送るので、長いテストセッションでもコンテキスト制限に引っかかりにくい。
室谷実際のQAワークフローで使える具体的なアプローチをまとめると・・・
テキトー教師整理するとこうなります。
| テストの種類 | Claude Codeの活用方法 | 効果 |
|---|---|---|
| ログイン・認証 | 「正常・エラー・境界値を全パターンテスト」 | 手動20分 → 自動3分 |
| フォームバリデーション | 「空欄・特殊文字・最大文字数を試す」 | 見落とし防止 |
| 画面遷移 | 「全ユーザーフローをPlaywrightで実行」 | 回帰テストの自動化 |
| レスポンシブ | 「モバイル・タブレット・PCで動作確認」 | マルチデバイス対応 |
| アクセシビリティ | 「タブ順序・ARIAラベルを確認」 | a11y対応の確認 |
室谷このうち「画面遷移」と「レスポンシブ」の自動化が、中小規模のプロダクトだと特に効果が高いですね。毎リリースで人間が手動確認してた部分をClaude Codeに任せられる。
テキトー教師ただ、重要な注意点があって。「Claude Codeの探索的テストは、AIによる補助テストであり、人間が方向性を決める」という大前提があります。
AIが操作してレポートを返してくれるけど、そのレポートを読んで判断するのは人間、ということですね。
AIが操作してレポートを返してくれるけど、そのレポートを読んで判断するのは人間、ということですね。
室谷「AIが見つけたバグ候補」を人間が確認してから「本当にバグか」を判断する、という流れが大事で。Claude Codeが「これ挙動おかしくないですか？」と報告してきたことを、プロダクトの仕様を知っている人間が判断する。
Playwright MCPとPlaywright CLIの使い分け
テキトー教師ここ、コミュニティのメンバーさんがよく迷う点なんですよね。「Playwright MCP」と「Playwright CLI」、どっちを使えばいいか、という話です。
室谷シンプルに整理すると、「短時間の確認作業」はMCP、「長い自動化セッション」はCLIが向いてます。MCPはスクリーンショットベースなのでトークンを多く消費する。
CLIは構造化コマンドなので効率的。
CLIは構造化コマンドなので効率的。
テキトー教師実際の使い分けイメージとしては：
- Playwright MCP：「このボタン押したら何が起きる？」「このページのレイアウト確認して」などのインタラクティブな確認
- Playwright CLI：「ログインから購入完了までの全フローをテストして」などの長いシナリオの自動実行
室谷MYUUUでは、開発中の「ちょっと確認したい」系はMCP、リリース前の「全フロー確認」系はCLIという使い分けをしてます。
テスト品質を担保する：レビューのポイント
室谷Claude Codeがテストを書いてくれても、そのまま使って大丈夫か？という話をしましょう。答えは「レビューが必要」で、レビューの観点を知っておくことが重要です。
テキトー教師ontestautomationのBas Dijkstraさんの検証が参考になるんですが、Claude Codeが生成したテストで「Dead weight（死荷重）」が発生することがある。同じコードパスを2つのテストがカバーしていて、片方は実質意味がない、という状態です。
室谷でも本当に問題なのはその逆で。「テストはある、通っている、でもカバーされていないパスがある」という状態。
95%ラインカバレッジでも、ビジネスロジックの重要な分岐が抜けてる、みたいなことが起きうる。
95%ラインカバレッジでも、ビジネスロジックの重要な分岐が抜けてる、みたいなことが起きうる。
テキトー教師ミューテーションテストが有効な理由がここですよね。「テストが通る＝テストが良い」は必ずしも成立しない。
コードを少し変えてもテストが通ってしまう（＝テストが実は意味のない検証をしている）という問題を検出するのがミューテーションテスト。
コードを少し変えてもテストが通ってしまう（＝テストが実は意味のない検証をしている）という問題を検出するのがミューテーションテスト。
室谷Claude Codeにミューテーションテストを組み込む、という使い方ができるんですよ。「このテストスイートに対してPITestでミューテーションテストを実行して、殺しきれてないミュータントのカバレッジを改善して」みたいな指示で。
テキトー教師これ実際にやると相当強くて。Claude Codeが「ここのブランチテストが不足してます」と自己診断して、対応するテストを追加してくれる。
テスト品質の自動改善ループができる感じですね。
テスト品質の自動改善ループができる感じですね。
AIが生成したテストのレビューチェックリスト
テキトー教師整理すると、Claude Codeが生成したテストをレビューするときの観点はこんな感じです。
- 命名が適切か：テスト名を読んだだけで「何をテストしているか」がわかるか
- 重複がないか：同じコードパスを複数のテストがカバーしていないか
- エッジケースが含まれるか：境界値・空入力・異常系が網羅されているか
- アサーションが意味を持つか：
expect(true).toBe(true)のような意味のないassertがないか - テストが独立しているか：他のテストの実行順序に依存していないか
- セキュリティリスクがないか：認証情報・機密データがハードコードされていないか
室谷最後の「セキュリティリスク」は地味に重要で。Claude Codeがテスト用のダミー認証情報として実際に使えそうな値を生成することがあるんですよ。
そのままコミットすると情報流出リスクになる。
そのままコミットすると情報流出リスクになる。
テキトー教師foxboxのQAエンジニアも「Common pitfalls: Security risks（Claude sometimes proposes hard-coded values）」って明記してましたよね。これはちゃんと頭に入れておく必要があります。
Claude Codeをテストハーネスとして使う：上級者向け設計
室谷ここまでの話を「テスト生成の効率化」とすると、さらに上の「Claude Codeそのものをハーネスとして設計する」という使い方があります。いわゆる「Claude Code ハーネス」設計という概念ですね。
テキトー教師つまり、Claude Code QAの観点で言うと、Claude CodeをAIエージェントとして「テストプロセス全体を自律的に回す」設計ですよね。テストの設計から、実行、結果分析、失敗したテストの修正、レポーティングまでを一連のフローとして。
室谷これが実現できてる会社は、海外ではかなり少ないんですが、少しずつ事例が出てきてます。testcollabがMCPを使ったテスト管理ワークフローを紹介してて、かなり実践的な内容で・・・
テキトー教師具体的な設計フローはこうですね。
- Claude Codeがコードベースをスキャンしてテストされていないモジュールをリストアップ
- 優先度の高い順にテストを生成（影響範囲が大きいモジュールから）
- 生成したテストを実行、失敗したら自己修正
- カバレッジレポートを生成し、まだ不足している部分を特定
- 追加テストを生成して同じサイクルを繰り返す
室谷これをhooksとslash commandsを組み合わせて実現するわけですね。
/run-qa-cycleみたいなカスタムコマンドを定義して、そのコマンドひとつでサイクル全体が回るようにする。テキトー教師講座でこういう設計を教えると、受講生さんがよく言うのが「それって、Claude Codeが自分でClaude Codeのテストを書くってこと？」って。そうじゃなくて、プロダクトのテストをClaude Codeが自律的に管理する設計ですね（笑）
室谷でも将来的には「AIがAI自身のハーネスを設計する」という世界に向かってる感はあって。清華大学とハルビン工大の論文で「エージェントが自然言語で書いたハーネスをAI自身が実行・改善する」という概念が提案されてたりして・・・
テキトー教師まだ実用段階ではないですが、「モデルよりハーネスが重要」という話と合わせると、AI開発者が次に注目すべき領域ですよね。
実践：Claude Codeテストセットアップガイド
テキトー教師最後に実践的なセットアップの話をしましょう。「今日からClaude Codeのテスト機能を最大限使うために何をすればいいか」という観点で。
室谷まず最低限やっておくべきことを整理すると・・・
テキトー教師3ステップでまとめます。
室谷ステップ1がCLAUDE.mdのテスト規約整備。使用するテストフレームワーク、命名規則、カバレッジ基準を書く。
これだけで生成されるテストの質が変わります。
これだけで生成されるテストの質が変わります。
テキトー教師ステップ2が既存テストの「サンプル」を整備すること。Claude Codeは既存のテストスタイルを参考にするので、「理想のテストの書き方」を示す1〜2ファイルをしっかり書いておくと、それ以降の生成精度が上がります。
室谷ステップ3がhooksの設定。少なくとも「コード変更後に関連テストを自動実行する」hooksを入れておくと、テストを忘れるという事態が防げます。
テスト実行を自動化するのがハーネス設計の第一歩です。
テスト実行を自動化するのがハーネス設計の第一歩です。
テキトー教師この3ステップ、今日やれる話なので。特にCLAUDE.mdのテスト規約は30分あれば書けます。
室谷あと言っておきたいのが、「テストを書いてもらう」じゃなくて「テストを一緒に設計する」という感覚の転換ですね。Claude Codeに「このモジュール、どういうテストが必要だと思う？」と聞くと、意外と見落としてたテストケースを提案してくれることがある。
テキトー教師これ、ペアプログラミングの「テスト版」ですよね。コードの設計を一緒に考えてもらうのと同じで、テストの設計もClaude Codeと一緒に考える。
その過程で「あ、このエッジケース考えてなかった」という発見が結構あります。
その過程で「あ、このエッジケース考えてなかった」という発見が結構あります。
室谷MYUUUでも「テストレビューをClaude Codeに頼む」という使い方が増えてきてます。「このテストスイート見て、カバーできてないパスがあったら指摘して」という形で。
人間のコードレビュアーが見落とすポイントを補完してくれる感じで。
人間のコードレビュアーが見落とすポイントを補完してくれる感じで。
FAQ
Q. Claude Codeはどのテストフレームワークに対応していますか？
室谷主要なフレームワークはほぼ対応しています。JavaScript/TypeScriptならJest・Vitest・Playwright・Cypress、PythonならpytestやunittestとMagicMock、JavaはJUnit・Mockitoあたりが精度高いです。
Goのtesting・RubyのRSpec・PHPのPHPUnitも問題なく使えます。
Goのtesting・RubyのRSpec・PHPのPHPUnitも問題なく使えます。
テキトー教師ただ、プロジェクト固有のカスタムフレームワークや、古いフレームワーク（今更Jasmine単体でやってるプロジェクトとか）は、CLAUDE.mdに詳細な説明を書いておく必要があります。「このフレームワークはこう使う」というサンプルを貼っておくのが最も確実ですね。
Q. テスト生成の精度を上げるにはどうすればいいですか？
テキトー教師一番効果的なのは「既存の良いテストを参照させる」こと。
@参照したいテストファイル.test.tsで既存テストを参照しながら「同じスタイルで新しいモジュールのテストを書いて」という指示が最も精度が出ます。室谷もう一つは「どのバグをテストしたいか」を具体的に伝えること。「このAPIのエラーハンドリングをテストして」より「このAPIで認証トークンが期限切れの場合に401が返るかテストして」の方が、意図通りのテストが出てきます。
Q. Claude Code自体のハーネスとしての使い方は難しいですか？
室谷最初は難しく感じますが、段階的に始めれば大丈夫です。まず「コード変更後に自動テスト実行するhook」を1つ設定するところから始めて、それが動いたら次のステップへ、という形で。
テキトー教師講座でも「hooksを1つ設定する」という課題を最初に出すんですが、これを設定した人とそうでない人では、3ヶ月後のClaude Code活用レベルが全然違うんですよ。テスト自動化の第一歩として、hook設定は本当におすすめです。
まとめ：Claude Codeのテスト機能を最大化する
テキトー教師今日の話をまとめると、Claude Codeのテスト活用は「3つのレベル」で考えると整理しやすいですね。
室谷レベル1が「テスト生成の効率化」。テストを書いてもらう、という基本的な使い方です。
CLAUDE.mdで規約を定義しておけば、すぐに使える精度のテストが出てきます。
CLAUDE.mdで規約を定義しておけば、すぐに使える精度のテストが出てきます。
テキトー教師レベル2が「テストフローの自動化」。hooksを使ってコード変更後の自動テスト実行、失敗したら自動修正、というループを作る。
CI/CDへの組み込みもここです。
CI/CDへの組み込みもここです。
室谷レベル3が「ハーネスとしての設計」。テスト全体の戦略をClaude Codeと設計し、自律的なQAサイクルを実現する。
これは上級者向けですが、差が一番つく部分でもあります。
これは上級者向けですが、差が一番つく部分でもあります。
テキトー教師「モデルよりハーネスが重要」という話を最初にしましたが、まさにこのレベル3が「ハーネスの設計」なんですよね。Claude Codeをどういう仕組みで動かすか、という設計力がQAエンジニアの新しいコアスキルになっていく感じがします。
室谷.AI（ドットエーアイ）のコミュニティでも「AIエージェントを使った開発効率化」を継続的に扱ってますが、テスト自動化はその中でも特に実用的な領域なんですよね。ぜひ今日話した内容を参考に、まずCLAUDE.mdのテスト規約整備から始めてみてください。
