© GO Inc. 継続的な負荷検証を目指して クラウドネイティブ会議 2026 P山 

© GO Inc. 2 @pyama86 GO株式会社 バックエンド開発部 / pyama86 2014年よりGMOペパボ株式会社でホスティング事業や 技術部で主にプラットフォームエンジニアリングに従事。 2025年よりGO株式会社においてバックエンド開発。 趣味は旅行、キャンプ、ハードワーク 

© GO Inc. 3 某日 未明 

© GO Inc. DBコネクションがスタックし、接続不可になり、 連鎖してAPIがダウン DB対応後、トラフィック・シェーピングすることで復旧 メインAPIが応答不可状態になった タクシー需要のピークに発生 

© GO Inc. 1. プライマリサーバに SELECTしてるものが かなりあった 2. トランザクションの中で外部 APIをコールしているものがあった 障害の原因 DBの基礎を我々は何もわかっていなかった トランザクションが長期化し、 Wait系のメトリクスが上昇し、 DBが破滅 

© GO Inc. 1. クエリチューニング &DBリファクタリング 2. パフォーマンスの悪いコードのリライト 3. 負荷検証 年末に向けて備えていたこと 自信を持って望んだ年末、 失った自信 

© GO Inc. 1. 基本形の配車シナリオを実装 2. 並列度もコントロール可能で、本番以上に負荷をかけられる 3. 障害発生時以上の負荷をかけて確認していた 負荷検証 Goで実装されたスクラッチの負荷ソフトウェア 

© GO Inc. 『GO』アプリでは、周囲のタクシーが少ない場合にのみ発生する エンドポイントがあり、そのエンドポイントが特に負荷が高かった しかし、負荷シナリオにそのエンドポイントは 含まれていなかった 何が不足していたのか？ 負荷検証の網羅性 「やっていた」 と「必要なパターンをカバーしていた」 の間には 大きな差がある 

© GO Inc. 1. 可観測性の向上 2. レプリカDBを利用するようアプリを書き換え 3. トランザクション実行時間の削減 4. 縮退モードの開発 5. 継続的な負荷検証の実現 再発防止のためにやったこと 必要なことは全部やる 

© GO Inc. 10 継続的な負荷検証を 目指して 

© GO Inc. 1. 新しいエンドポイントは日々増え続ける 2. 本番リリース後、特定ユーザーだけ負荷が高いということがある 3. 新規開発でそれどころではない 継続的な負荷検証の何が難しいか 常にサービスは 成長する 

© GO Inc. 12 そうだ、 AIにしよう 

© GO Inc. 1. 負荷シナリオの妥当性をレビューする必要がある 2. AIが生成したものを何かしらの手段で動作確認する必要がある 3. そもそも精度高くテストデータを作り込むのが難しい AIで自動生成する場合の課題 厳密には人の課題でもある 

© GO Inc. YAMLでテストシナリオを定義できるシナリオワークフローエンジン シナリオの可視化 k1LoW/runn 1. YAMLで宣言的にテストの内容を定義 AIとの協業がやりやすい 2. 負荷検証以外に、 E2Eテストとしても流用できる 3. Goからライブラリ的に実行できる 4. 作者とメンテナ (@katzchum)が知人 

© GO Inc. k1LoW/runn desc: 検索→詳細取得フロー steps: login: include: setup_user.yml # 認証などの共通処理をinclude search: req: /v1/items/search: get: headers: Authorization: "Bearer {{ steps.login.token }}" params: query: "{{ vars.keyword }}" test: current.res.status == 200 wait_for_ready: loop: count: 5 interval: 3s until: current.res.body.status == "ready" req: /v1/items/{{ steps.search.res.body.id }}: Goのテンプレート埋め込みに対応 includeで共有資産化 debugもしやすい仕組み 

© GO Inc. AIが生成したものを何かしらの手段で動作確認する必要がある runnをAIにコールさせる 「3回連続でパスするまで直し続けてください」 しかし、普通にやると 難しい 

© GO Inc. シナリオの作成から実行まで さも人であるかの様に振る舞うために claude code dev api server runn production dev 1.ログを分析し、シナリオ作成 2. シナリオ実行 3.ログ出力 4.ログを閲覧、デバッグ YAML 

© GO Inc. 開発？した Agent Skills extract-scenariosスキル - ログを読んでシナリオを書く run-stressスキル - dev環境で実際に実行して確認する 

© GO Inc. extract-scenariosスキル AIにGrafana LokiへのアクセスをMCP経由で与えている。 AIは本番環境のLokiに直接クエリを投げて実際のアクセスログを取 得し、ユーザーやドライバーがどのAPIをどんな順番 で 呼んでいるかを分析する。 発見したパターンをもとにrunbook YAMLを生成し、既存 シナリオとの重複チェックも行って、新規性のあるシナリオ 候補のみを人間に提案する。 

© GO Inc. run-stressスキル このスキルでは、AIがdev環境で実際にシナリオを動かす 。 内部的にはrunnをGoライブラリとして組み込んだ CLIを使い、実行す る。 さらに、dev環境のLokiにもクエリを投げて 、リクエストがAPIサーバ に実際に届いているか、想定したルートを通っているか、うまく行かな い時の調査を行う。 

© GO Inc. この仕組みの面白いところ 1. 人がシナリオを作る時のサイクルそのもの をAIに移植した 2. ピークタイムのログをAIに解析させたり、特定の時間にしか起きな いパターンなどを検知できる様になった 3. runnがドキュメントとしての側面 があることの発見 

© GO Inc. 他に工夫しているところ 1. 負荷検証用のDBのデータは大量の本番相当の レコードを使う 2. 外部通信は全てMockする 3. テストに使うユーザーやドライバーは紐づくレコードの 多いものを自動決定する 4. runnのhttpクライアントの取り回し 5. 負荷クライアントのワーカー化 6. Grafana MCPの認証・認可 

© GO Inc. いまは人がやっていること 1. この仕組みの実行、負荷検証の実施 主にコスト面から自動実行はしていない 2. AIが作ったシナリオの妥当性の検証 3. 負荷検証の結果の評価 

© GO Inc. 今日話したこと 1. 負荷検証のシナリオを継続的に開発するための手段 2. AIに人が扱っている様な情報を与えることで、 サイクルを回す 3. 人間とAIが協業するために、既存の手段を組み合わせる 

© GO Inc. オンラインイベントを来週やります !!1 

文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.