AIに負荷試験のシナリオを考えさせる｜本番の山を見積もる型

「来週リリースだから、負荷試験もやっておいて」

そう言われて、とりあえずAIに「ECサイトの負荷試験シナリオを作って」と頼んだことはありませんか。返ってきたのは、同時接続1,000ユーザー、ランプアップ10分、目標応答2秒以内……それらしい数字が並んだ立派な計画です。

でも、ふと手が止まる。この1,000という数字は、どこから来たんだろう。

ここで立ち止まれたなら、それはもう半分うまくいっています。負荷試験でいちばん大事なのは、ツールの使い方より「本番の山がどのくらいか」を自分たちの数字で決めることだからです。この記事では、その見積もりを人が持ち、AIには得意なところを任せる分担で、性能テストのシナリオを組み立てる手順を一緒に整理します。

結論：AIに負荷試験のシナリオを頼むときは、①本番の山（ピーク）の数字はアクセスログから自分で出す → ②AIには「ユーザーの操作の流れ」と「操作の比率」の案を出させる → ③どんな負荷のかけ方をするか（ピーク・長時間・急増）の観点を洗わせる → ④合格ラインと観察する指標を先に決める → ⑤小さく流して、結果の読み方をAIと一緒に確かめる、の順で進めると、数字に根拠のある試験になります。AIが出す数字は「例」であって、あなたのシステムの値ではありません。

AIに丸投げした負荷試験シナリオで、何が起きやすいか

AIは負荷試験の「形」を作るのがとても上手です。ツールのスクリプトの書き方も、シナリオの構成も、一般的な観点も、さっと出してくれます。

ただ、AIはあなたのサービスのアクセスログを見ていません。だから、丸投げすると次のようなことが起きやすくなります。

• 数字が一般論のまま：「同時1,000ユーザー」「応答2秒以内」など、どこかで見たような値がそのまま入る。実際の山より大きすぎても小さすぎても、試験の意味が薄れます。
• 操作の流れが教科書どおり：トップページ→商品一覧→詳細→カート→購入、のような綺麗な流れ。実際には検索ばかりで買わない人が大半、ということもあります。
• 重い処理が抜ける：CSV出力、集計画面、画像アップロード、外部APIとの連携など、そのシステム固有の重い処理は、言わないと入りません。
• 「何をもって合格か」が曖昧：試験は流したけれど、結果を見て「で、大丈夫なの？」に答えられない。

どれも、AIが悪いわけでも、頼んだ人が悪いわけでもありません。AIに渡していない情報は、AIには分からない。それだけのことです。だから、渡す情報と自分で決めることを分ければ、ちゃんと役に立つ相棒になります。

ステップ1：本番の山は、アクセスログから自分で見積もる

最初にやるのは、AIへの依頼ではなく、自分たちのアクセスの山を知ることです。

見る場所は、すでに手元にあるもので十分です。

• Webサーバーやロードバランサーのアクセスログ
• アクセス解析ツールの時間帯別グラフ
• APMや監視ツールのリクエスト数のグラフ

ここから、いちばん混む時間帯の1時間あたりのリクエスト数を拾います。新規サービスでログが無いときは、「想定利用者数×1人あたりの操作回数×混む時間帯への集中度」で仮置きし、仮置きであることをメモに残しておきます。

計算の例を置いておきます（数字は説明用の例です）。

「平均の3倍」「2倍の余裕」といった倍率は、チームやサービスによって考え方が違います。大事なのは倍率の正解ではなく、どの数字をどこから取って、何倍にしたのかを書き残すこと。これがあれば、試験後に「なぜこの負荷で試したの？」と聞かれても、落ち着いて説明できます。

セールやキャンペーン、月末の締め処理など、ふだんと違う山が来る予定があれば、それも一緒に書き出しておきましょう。性能の要件そのものに抜けがないか気になるときは、非機能要件の抜け漏れをAIに洗わせるもあわせてどうぞ。

ステップ2：AIには「操作の流れ」と「比率」の案を出させる

山の高さが決まったら、ここからがAIの出番です。負荷試験のシナリオで手間がかかるのは、ユーザーが実際にどう動くかを組み立てるところ。ここはAIがたたき台を作るのが得意です。

渡す材料は、次の3つです。

• 画面一覧やAPIの一覧（エンドポイントの名前と役割くらいで十分）
• アクセスログから拾ったよく呼ばれるURLの上位（件数の多い順に10〜20件）
• そのシステム固有の重い処理（CSV出力、集計、ファイルアップロード、外部API連携など）

頼み方の例です。

次のWebシステムの負荷試験シナリオの「操作の流れ」と「比率」の案を作ってください。

## システムの概要
（例：社内向けの受発注システム。取引先が発注を入力し、社内で承認する）

## 画面・APIの一覧
（一覧を貼る）

## アクセスログで多いURL（多い順）
（上位15件程度を件数つきで貼る）

## 重いと分かっている処理
- 月次の発注一覧CSV出力
- 取引先別の集計画面

## お願いしたいこと
- ユーザーの種類ごとに、典型的な操作の流れを3〜5本に分けてください。
- 各流れの比率（全体に占める割合）の案を、ログの件数から根拠を示して出してください。
- 重い処理をどの流れにどの頻度で混ぜるかも提案してください。
- 同時ユーザー数や目標の秒間リクエスト数は、こちらで決めるので提案不要です。

最後の一行がポイントです。山の高さは人が決める、と先に伝えておくと、AIが一般論の数字を混ぜてくるのを防げます。

返ってきた比率は、ログの件数とざっと突き合わせます。「閲覧系が9割と言っているけど、ログを見ると検索APIだけで半分ある」のようなズレが見つかれば、そこを直すだけで試験がぐっと本番に近づきます。

ステップ3：負荷のかけ方の観点をAIに洗わせる

負荷試験は「ピークの負荷を1回かけて終わり」ではありません。どんな問題を見つけたいかによって、かけ方が変わります。ここは観点の洗い出しとして、AIに一覧を出してもらうのが効率的です。

全部を最初からやる必要はありません。リリース前に最低限ならピーク試験、運用中に「夜になると遅くなる」ような話があるなら長時間試験、と目的から選びます。

AIには「このシステムで、上の4つのうちどれを優先すべきか、理由とあわせて提案して」と聞くと、見落としていた観点を拾ってくれることがあります。一方で、外部の決済APIや他社のサービスに負荷をかけてしまわないかは、人が必ず確かめるところです。外部APIはモック（スタブ）に差し替えるか、相手先の試験環境の利用ルールを先に確認しておきましょう。モックの作り方はAIにモック・スタブを書かせるときの確認点も参考になります。

ステップ4：合格ラインと、見る指標を先に決める

試験を流す前に、何が出たら合格かを決めておきます。あとから結果を見て決めると、どうしても「まあ大丈夫そう」に寄ってしまうからです。

決めておきたいのは、だいたい次の3つです。

• 応答時間：平均ではなく、遅い側のパーセンタイル（例：95パーセンタイルで◯秒以内）。平均だと、一部の人だけ極端に遅い状態が隠れてしまいます。
• エラー率：例：全体の◯%未満。タイムアウトも数に入れるかを決めておく。
• サーバー側の余裕：CPU・メモリ・DBの接続数などが、目標負荷のときに上限に張りついていないか。

合格ラインの数字そのものは、業務の要件や画面の性質で変わります。ここはAIに「一般的な目安」を聞くのはよいとして、最終的な値は要件・利用者・上長と合意した数字にします。

あわせて、試験中にサーバー側で何を見るかも決めておきます。負荷ツールの画面だけ見ていると、「遅くなった」ことは分かっても「どこが詰まったか」が分かりません。アプリ・DB・外部連携のどこを観察するかを、AIにログの抜けを洗わせる手順の考え方で事前にそろえておくと、結果の読み解きが楽になります。

ステップ5：小さく流して、結果の読み方をAIと確かめる

いきなり目標の負荷をかけず、まずは目標の1割くらいで流します。スクリプトの書き間違い（ログインに失敗してエラーページばかり叩いている、など）は、ここで見つかることがよくあります。

負荷ツールは、k6・JMeter・Locust・Gatling など、チームで使い慣れたもので構いません。AIにスクリプトを書かせた場合は、ログイン状態やセッションの引き継ぎ、テストデータの使い回しが想定どおりかを、少量で流して確かめてから本番の負荷に進みます。テストデータの作り方はAIにテストデータを作らせる型にまとめています。

結果が出たら、数値とグラフの要点をAIに渡して読み方を相談するのも有効です。

• 「応答時間が途中から急に伸びた。同じ時間帯のDB接続数とCPUはこう。考えられる原因の候補を、確かめ方とセットで挙げて」

ここでもAIが出すのは原因の候補です。「DBのインデックス不足です」と言い切られても、実際に遅いクエリを確かめるまでは仮説として扱います。直し方を検討する段階に進んだら、AIにパフォーマンス改善の候補を出させる手順の流れで、計測しながら一つずつ確かめていきましょう。

負荷試験の根拠があると、何が変わるか

山の見積もりと合格ラインに根拠があると、試験のあとの会話が変わります。

• 「30件/秒で95パーセンタイル1.5秒、エラーなし。ふだんのピークの約6倍までは確認済みです」と、数字で安心を伝えられる
• 目標に届かなかったときも、「どこで・何が・どれくらい足りないか」が言えるので、対策と相談に進みやすい
• 次のリリースで同じ試験を流せば、性能が悪くなっていないかの比較ができる

上への報告の仕方に迷ったら、AI活用の成果を数字で報告するコツの型がそのまま使えます。

明日からやること（小さく始める3つ）

全部を一度に整えなくて大丈夫です。まずはこの3つから。

1. アクセスログから、ピーク1時間のリクエスト数を1つ拾う：それを3,600で割るだけで、試験の目標を考える出発点ができます。
2. よく呼ばれるURLの上位10件を書き出す：これがあれば、AIに頼む操作の流れが一気に本番に近づきます。
3. 合格ラインを3行で書いてみる：応答時間・エラー率・サーバーの余裕。仮の数字でも、書くと議論が始められます。

AIで負荷試験シナリオを作るときのチェックリスト

試験を流す前に。今日は使えるところだけで十分です。

山の見積もり：

• ピークのリクエスト数を、アクセスログや監視ツールから取ったか
• 平均から瞬間の山、目標への倍率の根拠を書き残したか
• セール・締め処理など、ふだんと違う山の予定を確認したか
• ログが無い場合、仮置きであることをメモしたか

シナリオ：

• AIには「数字はこちらで決める」と伝えて、操作の流れと比率だけを頼んだか
• 操作の比率を、ログの件数と突き合わせたか
• CSV出力・集計・アップロードなど、固有の重い処理を入れたか
• 外部APIに負荷をかけないよう、モック化や相手先のルール確認をしたか

合格ラインと観察：

• 応答時間をパーセンタイルで決めたか
• エラー率の上限と、タイムアウトの扱いを決めたか
• サーバー側で何を見るか（アプリ・DB・外部連携）を決めたか

流し方：

• 最初は目標の1割程度で流し、スクリプトの動きを確かめたか
• AIが挙げた原因は、計測で確かめるまで仮説として扱っているか
• 結果と条件を、次回比較できる形で残したか

最後に

「負荷試験もやっておいて」は、さらっと言われるわりに、ひとりで抱えると重たい仕事です。どれだけの負荷をかければいいのか、誰も教えてくれないことも多いですよね。

でも、その答えはたいてい、もう手元のアクセスログの中にあります。山の高さを自分で拾って、AIには操作の流れと観点を手伝ってもらう。それだけで、「なんとなく流した試験」は「根拠を説明できる試験」に変わります。

最初の一歩は、ピーク1時間の数字をひとつ拾うことから。その数字があれば、AIとの相談も、上への説明も、ちゃんと地面に足がついたものになります。

よければ、こちらも

• 性能の要件そのものを見直すなら 非機能要件の抜け漏れをAIに洗わせる｜観点リストと確認の型
• 遅い原因を直す段階なら AIにパフォーマンス改善の候補を出させる｜推測で直さない手順
• 試験用のデータを作るなら AIにテストデータを作らせる｜個人情報と偏りに気をつける型
• 流れ全体を試すなら E2E・結合テストのシナリオをAIに書かせる——観点の渡し方

関連用語

• API
• レート制限
• ハルシネーション