1. はじめに
こんにちは。テクノロジー戦略室TQCチームの原田です。
僕達のチームはTotal Quality Control、つまり全社の全システム品質管理・システム品質向上を目的に活動しています。
この目的を効果的に達成するため、データ分析に深い知識を持つ社員や、複雑な課題を整理し新たな概念を構築する社員など、それぞれの専門性や強みを共有し、協力し合いながら活動する面白いチームです。
その中で僕達が注目しているのがAI技術です。
皆さんは「この業務は人にしかできない」と言う考えを持ったことはないでしょうか？
人の判断が必要だから、機械的には処理できない——そのような業務も自動化すべく、僕達はAI技術を活用しています。
本記事では僕達が活用しているAI技術の中から、特に注目しているMCPという技術に焦点を当て、システム品質としてシステムの安定性や性能を保証する上で不可欠な試験である負荷試験を「どのように自動化したか？」をお伝えします。
2. 負荷試験自動化の現状と課題
近年負荷試験の自動化は部分的に進んでいますが、依然として経験や知識に依存する作業が多く存在します。
例えば適切な負荷量を知るために閾値を探す作業は、様々な負荷量で負荷試験を実行し、その結果を分析しながら段階的に負荷を調整していく必要があります。負荷量の調整ー負荷試験の実行ー結果の分析ー次の負荷量の決定という一連の反復的なプロセスは、今までの経験や対象システムのシステム特性を深く理解する必要があり、機械的な自動化を困難にしてきました。
例えばWebサーバーの負荷試験において、システムが安定して処理できる秒間リクエスト数の上限、つまり閾値を探す場合を考えてみます。
あるWebサーバーでは秒間リクエスト数を増やしていくにつれてCPU使用率が上昇し、その結果としてレスポンスタイムが徐々に悪化し始めるかもしれません。しかし別のWebサーバーではメモリ使用量が特定量を超えた時に、特定の処理でメモリリークが発生し、リクエスト数とは直接的な関係なしに突発的なエラーが発生するかもしれません。
このようにWebサーバーの種類や構成、アプリケーションの特性によって、負荷に対する反応は大きく異なります。このため全システム共通の負荷量で閾値を確認することができず、それぞれシステム固有の挙動を理解する必要があります。
そしてシステム固有の挙動を把握して適切な閾値を判断するためには、類似システムでの負荷試験経験や、対象Webサーバーに対する様々な負荷パターンの検証、さらに結果を分析する推論能力が必要となります。
また他にも、負荷試験結果の分析といった経験に基づく推論作業が多く存在します。
今回TQCチームでは、機械的な自動化が特に困難であった負荷量の閾値探しに着目し、AI技術であるMCPを使用して自動化を行いました。
さらにその前後の業務である負荷試験実行用スクリプトの作成と、負荷試験結果の保存についてもAIによる自動化を実現しました。
3. MCPとは？
負荷の閾値探し作業の自動化に活用した主要なAI技術であるMCP（Model Context Protocol）について、その概要を説明します。
MCP（Model Context Protocol）とは、AIが外部の様々なデータソースやツールにアクセスするためのプロトコルです。負荷の閾値探しにおいては、MCP経由で過去の負荷試験データ、現在のサーバーリソース情報、システム構成情報、負荷試験ツール（k6など）の状態といった情報にアクセスさせることができます。
4. どうやって負荷の閾値探し作業を自動化したのか？
ではどのようにして負荷の閾値探し作業を自動化したかについてお伝えします。
そのためにはまず、簡単な図ですが現在のシステム構成図を紹介します。
（システム構成図にはGeminiとPlaywright、k6に関して記載があると思いますが、そちらの説明も行うと長くなってしまうので割愛します）
特筆すべきは図の2~3と5~6です。
図の2~3で負荷試験実行用スクリプトの作成を行うのですが、ユーザーが「〇〇Webサイトにおいて、トップページへアクセス後、ログインページへ遷移してログインを実行してください。その後ユーザー登録を行うというシナリオで負荷試験を行ってください」と負荷シナリオをAIエージェントに指示すると、AIエージェントはPlaywright-MCPで指示された通りに〇〇Webサイトへアクセスした後、Playwrightから送信されたHTTPリクエストを再現する負荷試験実行用スクリプトを作成します。
そして図の5で負荷の閾値探しを行います。AIエージェントがk6を利用し、様々な負荷パターンを試しながら閾値を探します。例えば負荷シナリオを秒間20回実行した時に負荷がかからなかった場合、秒間30回で実行するといった動作を行います。
この時AIエージェントがレスポンスタイムやエラー率を確認し、負荷がかかっているかどうか判断します。
最後に図の6で負荷試験結果の保存を行い、AIエージェントは処理を終了します。
AIエージェントがMCP経由でファイルシステムにアクセスし、負荷試験結果を指定したディレクトリ配下に保存します。
例えば、送信に成功した合計HTTPリクエスト数、秒間HTTPリクエスト数、エラー率、レスポンスタイムといった負荷試験結果を指定したディレクトリ配下に保存します。
これだけでもすごく助かっているのですが、見て分かる通り今回は単一のAIエージェントで動作する構成になっています。
実は執筆前の技術検証時点では複数のAIエージェントを使用して、以下の構成で動作させていました。
- 統括AIエージェント：以下AIエージェントの取りまとめ役。それぞれのAIエージェントと対話し、対話結果をユーザーに伝える役割
- クローリングAIエージェント：クローリング専用AIエージェント。どんなWebページがあるか知る役割
- 負荷試験実行AIエージェント：負荷試験を実行するAIエージェント。統括エージェントから渡された負荷試験実行用スクリプトを実行して、負荷試験を行う役割
- ファイルシステムAIエージェント：負荷試験実行AIエージェントから負荷試験結果を受け取り、結果をファイルに保存する役割
今後は複数のAIエージェント構成による運用を行うべく再設計中になるのですが、なぜ今は複数のAIエージェント構成をやめて単一のAIエージェント構成にしているかには理由があります。
複数のAIエージェント構成を採用する場合、AIエージェント同士が対話を行い協力してタスクを進める過程において、予期しない問題が発生したのです。それはAIエージェント間での認識のずれや、意図しないAIエージェントへの間違った指示が発生し、結果として期待通りの動作が得られにくいという問題でした。
MCPの真価は、複数のAIエージェントがMCPツールを使った自律的な連携によって発揮されると僕は考えています。
例えば複数のAIエージェント構成を設計することで、以下の1~2と3を並行して処理することが可能になります。
1: 負荷試験の指示を行う統括AIエージェントはMCP経由でシステム情報を取得し、負荷シナリオ設計AIエージェントに負荷試験実行用スクリプトの生成を指示する。
2: 負荷シナリオ設計AIエージェントと負荷試験実行AIエージェントを協力させて負荷試験の実行を指示する。
3: Webサーバー監視AIエージェントがWebサーバーのリソースやWebページへアクセスして、負荷によってシステム異常が発生していないかユーザーに状況を報告する。
なお複数のAIエージェント構成を構築するにはA2Aという技術を使います。
A2A（Agent2Agent）とは複数のAIエージェント同士が対話し、互いに協力して目標を達成するためのプロトコルです。
このプロトコルを使用することで、AIエージェントがより複雑なタスクを処理できるようになります。
また、独自プログラムを実装せずにMCP同士を連携することが可能になります。
※ A2Aに則ったプログラムは必要です。
こういったこれらの結果を踏まえ、今後は自動化の業務範囲をさらに広げてより高度な負荷試験の実現を目指すべく、複数のAIエージェント構成を採用した上で以下の活用も予定しています。
- ユーザーとの認識のすり合わせ：ユーザーが「〇〇機能にピーク時の80%の負荷をかけたい」と曖昧な要求を出した場合、MCP経由でシステムの運用データやシステム構成情報を参照し、「ピーク時」や「80%の負荷」を具体的な同時接続数やトランザクション数に落とし込むといった、要求の具体化とユーザーとの共通認識の構築に活用します。
- テストシナリオの設計：複雑な業務フローの負荷シナリオを設計する際、各APIの依存関係やデータ連携の流れをMCP経由でAIに提供することで、網羅的かつ効率的なテストシナリオ設計に活用します。
- 負荷試験結果の分析：試験結果やサーバーリソース情報をMCP経由で参照し、AIエージェントが異常の兆候やボトルネック箇所を推論します。
例えば「特定APIのレスポンスタイムが平均値の3倍になっている」といった異常を認知し、対象APIにボトルネックがあるのではないかとユーザーに助言するよう活用します。
5. さいごに
最後まで読んでいただきありがとうございます。
TQCチームでは一緒に全システムの品質向上を行うメンバーを募集しています。
もっとTQCチームやレバレジーズについて知りたい方は会社説明資料をご覧いただき、ぜひこちらからご応募ください。
