はじめに
本番でCPUがスパイクした後の分析（app-performance-profiling）でも、機能が正しく動くかのE2Eテスト（e2e-playwright）でもない。「1000人が同時にアクセスしたとき、P95レスポンスタイムが500ms以内か」を自動で検証し、SLAを守り続ける仕組みを作る話だ。
「動く」と「スケールする」は別の問題だ。機能テストが全て通っても、本番で同時アクセスが増えるとレスポンスタイムが悪化し、最終的にはサービスダウンに至る。負荷テストはこの「スケールの壁」を本番前に発見するための手段だが、スクリプト作成の複雑さ・シナリオ設計の難しさ・CIへの組み込みコストから後回しになりやすい。
CLAUDE.mdにSLA目標と4種のテストプロファイルを定義し、Claude Codeがスクリプトを生成する——この設計で「誰でも負荷テストを書ける」状態が実現する。
CLAUDE.mdでSLAとテストプロファイルを定義する——「一度書けば一貫して生成される」設計
合格基準のないテストを生成しても意味がない。最初のステップはSLA数値の定義だ。
# CLAUDE.md（パフォーマンステスト設定）
## Performance Testing Strategy
### SLAターゲット
- P95レスポンスタイム: 500ms以下
- P99レスポンスタイム: 1000ms以下
- エラー率: 0.1%以下
- スループット（目標QPS）: 200req/s
### テストプロファイル
| タイプ | 説明 | 目的 |
|-------|------|------|
| **Smoke Test** | 仮想ユーザー1名、1分間 | スクリプトの動作確認・最小負荷での正常動作確認 |
| **Load Test** | 目標QPS、5〜30分間 | ベースラインメトリクスの収集 |
| **Stress Test** | 段階的に増加し限界まで | システムの上限（breaking point）の特定 |
| **Spike Test** | 突然の10倍バーストアクセス | 急激な負荷増への耐性確認 |
### 対象エンドポイント
- GET /api/products: 読み取り主体（高頻度）
- POST /api/orders: 決済処理（高重要度・低頻度）
- GET /api/search: 検索（高コスト・中頻度）このCLAUDE.mdを定義すると、以降はClaude Codeが一貫した構造のスクリプトを生成する。
k6スクリプトの中核は以下のように構成される。
import { Trend, Counter, Rate } from 'k6/metrics';
// ビジネス観点のカスタムメトリクスを定義
const orderCreationLatency = new Trend('order_creation_latency');
const errorCount = new Counter('error_count');
const successRate = new Rate('success_rate');
export const options = {
stages: [
{ duration: '2m', target: 10 }, // ウォームアップ
{ duration: '5m', target: 50 }, // メイン負荷
{ duration: '3m', target: 50 }, // 維持
{ duration: '2m', target: 0 }, // クールダウン
],
thresholds: {
'http_req_duration': ['p(95)<500', 'p(99)<1000'], // CLAUDE.mdのSLAをそのまま反映
'http_req_failed': ['rate<0.001'], // エラー率0.1%以下
},
};Staged Ramp-upがコールドスタートの歪みを防ぐ。thresholdsにCLAUDE.mdのSLA値をそのまま反映することで、スクリプトが「合格基準を知っている」状態になる。
最初のステップはSmokeテスト（1ユーザー・1分間）から始めることを推奨する。Claude Codeが生成したスクリプトが正しく動くことを確認してから、本格的な負荷をかける順序だ。
GitHub Actions × k6——週次CIでSLAリグレッションを自動検知する
CIへの組み込み
# .github/workflows/performance-test.yml
name: Performance Test
on:
workflow_dispatch: # 手動トリガー
schedule:
- cron: '0 2 * * 1' # 毎週月曜2AM自動実行
jobs:
load-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run k6 load test
uses: grafana/k6-action@v0.3.0
with:
filename: tests/load/api-load-test.js
env:
TARGET_URL: ${{ secrets.STAGING_URL }}
K6_OUTPUT: json=results/k6-output.json
- name: Upload results
uses: actions/upload-artifact@v4
with:
name: k6-results
path: results/トリガー戦略
全PRで負荷テストを実行するとパイプラインがボトルネックになる。実践的な使い分けはこうなる。
- 週次定期実行: 全体的なパフォーマンスリグレッション検知（コスト・時間の現実解）
- 手動トリガー: リリース前・大規模変更後の確認
- 特定PRの変更検知: APIエンドポイントやデータベースクエリ変更時のみ実行
thresholdsを超えた場合、k6がexit code 1を返してCIパイプラインを停止させる。デプロイが自動的にブロックされる設計だ。
k6出力JSONによるRoot Cause Analysis
テスト失敗後、k6の出力JSONをClaude Codeに渡すことで分析が進む。どのエンドポイントがしきい値を超えたか、P95/P99のどの時点で劣化したか、スタックトレースやDBクエリとの相関はどうか——これらをまとめて提示してくれる。
「反応的な消火活動」から「予防的なパフォーマンス検証」への転換だ。
なお、負荷テストは必ずステージング環境で実施すること。本番での実行はサービス障害に直結する。負荷テスト中に外部APIやSaaSに大量リクエストを送ると、費用増加・レート制限・サービス規約違反につながる。外部依存はモックまたはスタブに置き換えること。Claude Codeが生成したk6スクリプトには、認証フローや状態依存のシナリオで誤りが入ることがある。テスト実行前のスクリプトレビューは必須だ。
既存QA資産との共存——JMeter（Feather Wand）× Claude Code
k6はJavaScriptベースで新規開発者が入りやすいが、QAチームにJMeterの知識とテスト資産が蓄積されているチームも多い。Claude Codeはどちらのスクリプトも生成できる。
| k6 | JMeter | |
|---|---|---|
| 記述形式 | JavaScript（コードベース） | XML + GUIベース |
| チームの既存スキル | Node.js/JS開発者 | QAチームの既存資産 |
| CI統合 | 容易（Docker/GitHub Actions） | 可能だが設定が複雑 |
「Feather Wand」（github.com/QAInsights/jmeter-ai、GitHubで実在確認済み）はJMeterにClaude Codeターミナルを組み込むプラグインだ。JMeterのテストプランの全体構造をClaude Codeが把握した状態でインタラクティブに操作できる。既存のJMeterスクリプト資産を活かしながら、Claude Codeの支援を受ける使い方が可能になる。
MCPMarket上にk6とJMeter両対応の負荷テストSkillが存在するという情報もあるが、まずはCLAUDE.mdの定義 → GitHub Actions組み込みの基本フローを確立してから追加ツールの導入を検討するのが現実的だ。
本番相当のデータ量がないステージングでは、テスト結果の信頼性が下がる点も覚えておきたい。DBシードの設計も含めてテスト計画を立てることが、信頼できる負荷テスト結果への道だ。
まとめ
CLAUDE.mdにP95・P99・エラー率の目標値を書くことが起点だ。その数値なしでは、Claude Codeが生成するテストは「合格基準を知らないテスト」になる。
SLAを数値で定義し、週次CIでリグレッションを検知し、失敗時はClaude Codeで根本原因を分析する——この三段構えが揃えば、「動くかどうか」の次の問いに答えられるチームになる。「スケールの壁」を本番前に発見できる体制を、今のスプリントで作り始めてほしい。
コメント