.images-row {width: 100% !important;} Developer Engagementブロックの @ikkou です。2026年5月22・23日の2日間にわたりベルサール羽田空港で「TSKaigi 2026」が開催されました。 ZOZOはGold Sponsorとして協賛し、スポンサーブースを出展しました。ZOZOがTSKaigiに協賛するのは今回が初めてです。 technote.zozo.com 本記事では、前半はZOZOのWebフロントエンドエンジニアが気になったセッションを紹介します。後半では、ZOZOのスポンサーブースの様子と各社のブースにおけるコーディネートを写真中心に報告します。 ZOZOのWebフロントエンドエンジニアが気になったセッション 開発体験を左右するライブラリの API 設計 ― GraphQL スキーマ構築ライブラリから考える 「関数型プログラミング」を分解する.ts 純粋性について 型でエフェクトを表す いつテストを書くか？―ソフトウェア開発における安心と不安について考える LLM時代のリファクタリング戦略：AIエージェントによる段階的・安全なTS移行方法 TypeScript の型で副作用の実行順序を制御する ZOZOのスポンサーブースの紹介 協賛企業ブースのコーディネートまとめ おわりに ZOZOのWebフロントエンドエンジニアが気になったセッション 開発体験を左右するライブラリの API 設計 ― GraphQL スキーマ構築ライブラリから考える ssssota です。izumin5210さんの「 開発体験を左右するライブラリの API 設計 ― GraphQL スキーマ構築ライブラリから考える 」を紹介します。 speakerdeck.com このセッションでは、スキーマや型情報をいかにTypeScriptの実装に接続するかという観点で、既存ライブラリのアプローチやその長短を深ぼる内容でした。弊社ではOpenAPIを使っているケースが非常に多く、いかにOpenAPIスキーマを実装に接続するかは往々にして発生する問題の1つです。 セッションではGraphQLに焦点が当てられていましたが、スキーマから実装を生成するスキーマファースト、コードからスキーマを生成するコードファースト、コードファーストのうちDecoratorsを使うパターン、DSL的な独自のbuilderパターン、計3パターンについて評価していました。比較・評価軸として、1.スキーマと実装の分離、2.型整合性、3.DBモデルとの接続、の3軸を用いています。 スキーマと実装の分離については、スキーマファーストが優れているのは言うまでもありませんが分離する強いモチベーションがなければ優先度は低くなります。型整合性は採用するライブラリのtype ergonomicに依りますが、コードファーストなDSL builderパターンが強い傾向にあります。DBモデルとの接続においてはGraphQL特有と見ることができますが、コードファーストなDSL builderパターンで型整合問題と合わせて解決できることを示唆しています。 セッションの最後には、自作のライブラリでこのギャップを埋める取り組みとAIを用いた評価結果を紹介していました。気になる方はスライドも合わせて確認してみてはいかがでしょうか。 私自身、OpenAPIスキーマと実装の接続に関して関心があり、ライブラリ（ openapi-ts-hono ）を作った経験から非常に共感できるところがありました。もちろんGraphQLとはギャップがありますが、スキーマと実装の分離、型整合性などは感覚としてもっていながらも、改めて言語化されることで気付きのあるセッションでした。 「関数型プログラミング」を分解する.ts www_REM_zzz です。おーみーさんの『 「関数型プログラミング」を分解する.ts 』を紹介します。 tsk-2026-aumy.vercel.app 自分の話ですが、TypeScriptに入門する前はScalaを書いていた経験があります。当時はコップ本と呼ばれる本とHaskellの公式ドキュメントが日本語で関数型プログラミングに入門する入口でした。Object指向プログラミングとは全く別の世界からやってきたような考え方で、面白くもあり、苦労もした過去があります。 このセッションでは、そもそも関数型プログラミングとは何なのかの考え方に触れながら、TypeScriptで真の関数型はできないのかに触れられています。僕もTypeScriptで真の関数型が書けたらいいのにと思った一人です（OCaml書けよというのは一旦置いといて）。スライドの中で語られた関数型プログラミングは「いい感じのソフトウェアを作るため」というのは本質的だなと思いました。ついつい手段に引っ張られてしまうところがあるのですが、心に留めておきたいです。 純粋性について 特に純粋性についてのところはReactでも他のライブラリでも語られる部分であり、意味の純粋性の部分は悩ましいと感じたことがあるので共感しました。 // 「副作用を表す値」を返すだけ（純粋関数） function pureAlert ( msg : string ) { return [ "alert" , msg ] as const ; } // 副作用の実行は別の関数に委ねる function executeAction ( action : readonly [ "alert" | "confirm" , string ] ) { switch (action[ 0 ]) { case "alert" : alert (action[ 1 ]); break ; case "confirm" : confirm (action[ 1 ]); break ; } } const actions = [ pureAlert( "hey" ), pureAlert( "bye" ) ] ; actions. forEach (( a ) => executeAction(a)); 引用： https://tsk-2026-aumy.vercel.app/29 このような「何をするかの宣言」と「実行」が分離されている書き方は普段からできるし、メンテナンスを考えると普段から実践していきたいと思いました。 return は「この関数の呼び出し元（= 継続）に値を渡して戻る」という考え方はTSを書いていてなんとなく感じていたものがはっきりと言語化されてスッキリした気持ちになりました。 型でエフェクトを表す () => T // 特に何も起きない純粋な処理 () => Option< T > // 失敗しうる処理 () => Promise < T > // 非同期処理 これを徹底すると 関数の型を見るだけで「何が起きるか・何が起きないか」がわかる 純粋な部分と副作用のある部分が型レベルで分離される 「支払い処理を起こしうる部分」だけを特定して二重実行を防げる これはTypeScriptを堅牢に書くうえで実践したいと思います。ちょうど業務でも似たシチュエーションがあることを思い出して、まず「この関数は副作用を持つか？」を命名（ execute , get , ! 記法）で示すのが現実的な入口かなと思いました。 いつテストを書くか？―ソフトウェア開発における安心と不安について考える ジン（ @Jin_pro_01 ）です。自分の気になったセッションとして、 lacolacoさん の「 いつテストを書くか？―ソフトウェア開発における安心と不安について考える 」を紹介します。 docs.google.com このセッションでは、テストをどのような時に書くべきなのかを「開発者の安心と不安」を起点に問い直したlacolacoさんの気づきの共有、問いの提示、視点の提案をするというセッションでした。 セッションの中ではソフトウェアの保守性の本質は「変更容易性」であり、それは予期的変更容易性（変更する前に感じる不安）と経験的変更容易性（変更をする中で実際に感じる手応え）の二層モデルとして見ることができるとしていました。その上でテストはその両方にフィードバックを返すセンサーであるとし、変更前に感じる不安があるならそれを取り除く安心のために書き、変更のしやすさを試したり構造に問題が見つかったりするなら設計を見直すために書くという体系的な整理がされており、とても興味深いセッションでした。 自分が従事しているZOZOTOWNでは、新規機能の実装や既存機能の改修と並行で、フロントエンドリプレイスも各チームで進行しています。ZOZOTOWNの発展を止めずに開発を進める体制である一方、考慮すべきことが多く、自分にとっては比較的「予期的変更容易性」が低い状態だと表現できることに気づきました。そして、まさにこの「予期的変更容易性」を高めるためのテストへの投資価値が高いと感じました。 さらにAIを使ってコーディングをしていく時代に入り、開発の生産量が増える一方で、自分が直接書いていないコードや構造との距離は広がっていきます。その距離は新たな不安、つまり予期的変更容易性の低下にもつながると感じています。だからこそ変更の前後で「振る舞いが変わっていないこと」を担保し、その不安を取り除くセンサーとしてのテストの価値は、AI時代にこそますます高まっていくのだと考えました。 最大の収穫は、テストを書く目的を「ソフトウェアがソフトであり続けるための、変更容易性のセンサー」と説明できるようになったことです。テストはあくまで手段の1つと捉えつつ、ZOZOTOWNがソフトであり続けるために、他に何ができるかも考えていきたいと思いました。 LLM時代のリファクタリング戦略：AIエージェントによる段階的・安全なTS移行方法 いもけん（ @iimokeenpi ）です。「 LLM時代のリファクタリング戦略：AIエージェントによる段階的・安全なTS移行方法 」について紹介します。 speakerdeck.com このセッションは、JSのコードをAIエージェントを使い安全にTSに移行するというものでした。しかし、JSからTSへの移行のみならず日常的なリファクタリングにおいても活用できそうなノウハウが詰まっていました。 特に自分が興味を持った部分としては”test-firstフロー”と”役割ごとにサブエージェントを切り出す”の2つがあります。AIエージェントの使用有無にかかわらずリファクタリングの際にデグレには細心の注意を払って行っていきたいところです。そこで”test-firstフロー”というのは、デグレの防止策としても効果が高くAIエージェントとの相性もかなり良いなと感じました。 そして“役割ごとにサブエージェントを切り出す”という点に関してです。自分は基本的に全てOpusで乗り切ろうとしていたのですが、消費トークンの効率や時間的な効率の面でも損をすることが多々あります。なので役割ごとにサブエージェントを切り出し、モデルを使い分けることはすぐにでも実践したいと感じました。 TypeScript の型で副作用の実行順序を制御する 佐藤です。私が印象に残ったセッションは「 TypeScript の型で副作用の実行順序を制御する 」です。 speakerdeck.com Branded Typeは「 UserId と ProductId を区別するためのタグ付け」くらいにしか使えないと思っていましたが、Type-State Patternを使えばそれが実行順序の制御に転用できます。TypeScriptの型システムでここまで表現できるのかと、型に対する認識が更新されました。 加えて魅力的なのが、ライブラリ依存ゼロで既存コードに薄く入れられる点です。Effect-TSやXStateは強力ですが導入コストは高いです。Type-Stateパターンなら守りたい箇所だけにピンポイントで適用できます。 実際、 getServerSideProps 内に「バリデーション→取得→加工」のような実行順序を守らなければならない処理があり、これまではAIのルールや運用上の規約に頼らざるを得ませんでした。型で制御できるようになれば、コードレビューや属人的な注意に依存せず、エディタ上でミスを即座に検出できます。自分のチームに導入できないか実践したいと思えるトークでした。 サンプルコードは GitHubで公開されています 。既存ライブラリとの比較実装も含まれているので、ぜひ手元で動かしてみてください。 ZOZOのスポンサーブースの紹介 ZOZOのスポンサーブースとWebフロントエンドエンジニアたち ZOZOのスポンサーブースでは「 Google I/O 2026から帰国したばかりのZOZOフロントエンドエンジニア テックリード ssssota に挑戦！ 」と題したTypeScript & JavaScript Quizをメインコンテンツとして提供しました。日替わりで全10問、ブースにはその日のクイズから1問だけ掲示しました。 TypeScript & JavaScript Quiz Day 1 & Day 2 ZOZOブースでは #GoogleIO から帰国したばかりの Web フロントエンド テックリード @ssssotaro が考えた JavaScript & TypeScript Quiz を実施中です！難易度は高め！ぜひ挑戦してください！ #TSKaigi pic.twitter.com/7K9ZTt22Qq — ZOZO Developers (@zozotech) 2026年5月22日 ＼TSKaigi 2026 最終日／ 今日もクイズ企画を開催しています！昨日とは異なる問題で、今日は特典をゲットしやすくなっています！ オリジナル洗濯ネットをご用意していますので、ぜひご参加ください！ #TSKaigi pic.twitter.com/QwR6v2F96t — ZOZO Developers (@zozotech) 2026年5月23日 難しい！　ということが話題になり、とても多くの方に挑戦してもらいました。難しいのは作問者の意図通りですが、この「難しい」ということが反響を呼び、楽しんでもらえたのではないでしょうか。 No Bugs, Just Clean. というメッセージの込められた特製ノベルティの洗濯ネット クイズに挑戦し、7問以上正解した方には特製ノベルティの「洗濯ネット」をお渡ししました（Day 2は3問以上正解した方に変更）。 Day 1、Day 2の7問以上正解者 また、上位正解者の皆さんにはリーダーボードにもハンドルネームなどを書いてもらいました。2日間を通しての全問正解者は、Day 1が @uhyo_ さんと @vaaaaanquish さんの2名、Day 2が @U3Qc9 さんの1名だけでした。改めて全問正解おめでとうございます！ このTypeScript & JavaScript Quizに関する解説記事を別記事として公開しています。あのクイズの答えが気になるという方はもちろん、もう一度あのクイズに挑戦したい、当日できなかったので挑戦したい！　という方もぜひご覧ください。 techblog.zozo.com 10分セッションに登壇中のテックリード ssssota この難問揃いのクイズを作問したテックリードのssssotaはDay 2に「 ReactとSvelteのその先、Ripple-TS 」というタイトルで10分セッションにも登壇しています。こちらもあわせてご覧ください。 speakerdeck.com 協賛企業ブースのコーディネートまとめ ジン（ @Jin_pro_01 ）です。セッションを見たり、自社ブースに立ったりしている合間にTSKaigi 2026の全協賛企業ブースを回ってきました。当日の会場の様子を思い出しながら、各社の個性や雰囲気の出るデザイン・着こなしをぜひご覧ください。 ウェルスナビさん。 / @WealthNavi_Tech AVITAさん。 Dress Codeさん。 / @dresscode_com Hacobuさん。 / @MHacobu sattoさん。 / @satto_ai_agent アサインさん。 / @ASSIGN_dev レバレジーズさん。 PLAINERさん。 / @plainer_inc ビットキーさん。 / @bitkey_dev UPSIDERさん。 / @upsider_inc ニーリーさん。 / @nealle_pr LayerXさん。 / @LayerX_tech エブリーさん。 / @every_engineer スリーシェイクさん。 / @3shake_Inc ミツモアさん。 / @meetsmore Ubieさん。 / @UbieCorp_JP Nstockさん。 / @Nstock_jp プレイドさん。 / @PLAID_Tech ギークプラスさん。 / @GeekJapan1 ウォンテッドリーさん。 / @wantedly_dev サイボウズさん。 / @cybozuinsideout ドワンゴさん。 / @dwango_tech CodeRabbitさん。 / @Coderabbitaija シェルパ・アンド・カンパニーさん。 ファインディさん。 / @findy_code ディップさん。 / @dip_developers RightTouchさん。 / @righttouch_dev Gaji-Laboさん。 / @gaji_labo スタメンさん。 / @stmn_eng TOKIUMさん。 / @TOKIUM_Dev カオナビさん。 / @kaonavi_jp テイラーさん。 / @TailorERP_JP KINTOテクノロジーズさん。 / @KintoTech_Dev MOSHさん。 / @MOSHinc_jp 皆さん照れていたりウキウキしていたりしてよかったです！　ご協力いただいた皆さん本当にありがとうございました！ おわりに TSKaigi 2026 協賛企業一覧 TSKaigiへの初協賛を通して、ZOZOのことが少しでも来場者の皆さまに伝わっていれば嬉しいです。みなさま、ありがとうございました！ TSKaigi 2026をきっかけとしてZOZOのWebフロントエンドエンジニアに興味を持たれた方は、技術スタックなどがまとまったページをぜひご覧ください。 techblog.zozo.com ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに こんにちは！芝浦工業大学理工学研究科 修士1年の只野陽生と申します。2026年2月の3週間 ...

はじめに こんにちは、Checkout Reliabilityチームでバックエンドエンジニアをしているかがの（ @ykagano ）です！ こちらは、「継続的な負荷テスト環境をBASEに構築しました」の第2回の記事です。 先に第1回を読んでいただくのをおすすめします。 継続的な負荷テスト環境をBASEに構築しました 〜 第1回: 負荷テストの全体像 - BASEプロダクトチームブログ こちらは第1回で紹介したBASEの負荷テスト環境の構成図です。 負荷テスト環境の構成図 本記事では、負荷テストツールとして採用したLocustの選定理由から、実際の構築・運用方法までを紹介します。 負荷生成ツールの選定 負荷テストのリクエスト元となる負荷生成ツールの選定を行いました。 選定の際は、まず今回の要件として以下の通りまとめました。 OSSである クラウドはコストとセキュリティの両面でハードルが上がるため 分散実行が可能である 継続的負荷テスト環境としてスケーリングは必要 Web UIがある レポート品質が高い 学習コストが低い メンバーの誰もが利用できるようにしたい 実績が豊富である OSSが今後も保守される可能性が高い こうした観点から参考として整理したOSSの比較表が以下となります。 ツール名 分散実行可能 Web UI レポート品質 学習コスト 実績が豊富 特徴 Locust ◎（Master/Worker が標準） ◎ ○ Web UI 低 ○ OSSで最も簡単にクラスタ構成可能。Pythonでシナリオが柔軟。中規模負荷に強い。 Taurus ○（バックエンドの Locust/JMeter/k6 を分散実行管理） △ ○（バックエンド依存） 低〜中 △ CI/CDで分散テスト統合運用。YAMLでテストランナー統一。チーム利用に最適。 JMeter ○（分散実行あり、構成は複雑） △（要プラグイン） ◎ HTMLレポート 中 ◎ GUI派に最適。歴史が長く安定。大規模負荷にも実績豊富。 k6 OSS △（K8s/CIで水平スケール。自動クラスタなし） ✕ △（外部連携で補完） 低〜中 ○ K8sベースのスケール前提なら実質分散可能。軽量で高性能。 Gatling △（OSS版は限定的。分散は Gatling Enterprise 推奨） ✕ ◎ HTMLレポート 中〜高 ○ Scala/Java DSLで高精度なシナリオ記述。レポートが非常に詳細。高スループット計測に強い。 k6、JMeter、Locustは自身で使ったことがありました。 k6は軽量ですが、Web UIがなく、分散環境で実行した場合、サーバーごとに出力されるレポートの収集が必要なのが懸念でした。 JMeterはテストシナリオを作るための構成が独特で理解に時間がかかるため、学習コストが高いと感じていました。 LocustはWeb UIから容易に実行でき、Pythonでテストシナリオを書く体験が良かったので、今回もLocustを選定することにしました。 Locustの公式ドキュメントはこちらを参照ください。 https://locust.io/ Locustの構築と実行 ECSに構築しました。ECSはAWSのコンテナ管理サービスです。 LocustはMasterとWorkerのタスクに分かれて起動します。 MasterはWeb UIとWorkerの管理を行い、Workerが実際の負荷をリクエストします。 Workerの数を増やすことで、負荷リクエストの上限も増やすことができる構成です。 ECSでのLocustの構成 Classごとに実行が可能で、ProfileでGold環境とBronze環境を切り替えられるようにしています。 Locustの実行画面 実行結果はWeb UIからRPS、Response Times、User数がチャートで見れます。 Locustの実行結果 実際に負荷テストを実行する際は、急激な負荷増加によるスパイクを避けつつ安定状態を観測するため、30秒程度で全てのUserがRamp upするようにして5分間の負荷をかけています。 そして5分の間、応答速度が安定的であるかどうかチャートを見ながら確認しつつ負荷テストを行っています。 Terraformを用いたインフラのコード化 Locustを配置している負荷テスト環境のインフラは Terraform で管理しています。 Terraformはインフラの構成を「設定ファイル」として記述できるOSSです。 AWSコンソールから設定せず、Terraformを用いてコード管理することで以下のメリットがあります。 負荷テスト環境で使用しているリソースをコードから確認できる コードベースでAIに環境構築を依頼できるため、構築が早い 環境の起動と破棄がGitHub Actions（GHA）から実行できる これにより、負荷テスト環境を使用する時だけ起動し、使い終わったら破棄するといったこともできます。 しかし、負荷テスト環境の構築を始めた当初、チーム内にTerraformを使用したことのある知見がなかったため、メンバーから提案をいただき、まずAIにAWSの基礎知識を含めた学習用コンテンツを作ってもらうことから始めました。 AIは主にClaude Codeを使用しています。 こちらが学習コンテンツの一部ですが、このような資料を作っていました。 学習コンテンツ また環境構築自体も、Claude Codeに設計書を書いてもらい、チーム内でレビューをし、何度も修正を繰り返した上で、Claude CodeにTerraformのコードに落とし込んでもらうという形で進めました。 作成されたコードのレビューはチーム全員で行い、全員が負荷テスト環境について知識を揃えるようにしました。 また今回Terraformのフォルダ構成として、以下の通りcoreとruntimeという二つのフォルダに分けています。 core：常設リソースの配置場所で、destroy不可に設定して常設リソースを保護します runtime：一時的なリソースの配置場所で、destroy可能とすることでコストを削減します これにより、インフラの起動時間の短縮とコストの削減を両立させることができます。 今回はTerraformの構成についての知見も得ることができ、良い経験になりました。 負荷テストシナリオの作成 LocustではPythonでテストシナリオを書くことができます。 下記はClaude Codeに書いてもらったサンプルコードからの抜粋ですが、コードの組み立て方は実コードとあまり変わらないため、イメージしやすいかと思います。 """Locust による会員登録フローの負荷テストシナリオ""" import json import os import random import string from locust import HttpUser, between, task DEBUG = os.getenv( "DEBUG" ) == "1" def random_email (): """テスト用のユニークなメールアドレスを生成する""" rand = "" .join(random.choices(string.ascii_lowercase + string.digits, k= 10 )) return f "test_{rand}@example.com" def log_response (label, response): if not DEBUG: return code = response.status_code mark = "✓" if 200 <= code < 300 else "✗" print (f " {mark} [{code}] {label}" ) if code >= 400 : print (f " body: {response.text[:200]}" ) class UserRegistration (HttpUser): """新規会員登録フローのシナリオ""" wait_time = between( 1 , 3 ) @ task def register (self): email = random_email() # 1. 仮登録（メール送信リクエスト） with self.client.post( "/api/v1/signup" , json={ "email" : email}, catch_response= True , ) as r: log_response( "signup" , r) if r.status_code != 200 : r.failure(f "signup: {r.status_code}" ) return token = r.json().get( "confirmation_token" ) if not token: r.failure( "signup: token missing" ) return # この後の処理は省略 今回、テストシナリオを商品や決済方法毎にいくつか作成しました。 作成方法としては過去にk6のJavaScriptで書かれたテストシナリオを流用し、Claude CodeにPythonのコードに変換してもらいました。 変換後のコードが正しいかどうかを検証するために、Playwrightを使用しました。 Playwrightはブラウザを自動操作できるOSSのテストツールです。 Claude CodeをPlaywright MCP（MCPは外部ツールと連携するための共通規格）に接続して、開発環境での購入画面に実際にアクセスしながら、通信しているAPIを確認し、APIコールがテストシナリオのコードと一致しているか検証する形で行いました。 実際に指示したプロンプト Playwright MCPで下記URLにアクセスして、 購入フローをトレースしながらコールされているAPIが scenario/*****.py の シナリオに記載されている内容と一致しているかチェックしてください https://*****/items/12939562 こうしたClaude Codeを用いたテストシナリオの作成により、作業時間を大幅に短縮することができました。 Locustの週次での自動実行 GHAから自動実行する際は、ECSでLocustを起動した後、起動したLocustに対してLambda経由でLocustの負荷テスト実行APIを叩くようにしています。 そして負荷テストの完了結果はログ収集サービスであるCloudWatch Logsをポーリングして、結果ログを取得するようにしています。 以下がそのシーケンス図になります。 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); sequenceDiagram participant GHA as GitHub Actions participant Lambda as Lambda<br/>(locust-control) participant CWL as CloudWatch Logs participant Master as Locust Master<br/>(ECS) participant Worker as Locust Worker<br/>(ECS x N) Note over GHA: Locust Master/Worker の<br/>デプロイ完了後 GHA->>Lambda: Lambda を非同期で呼び出す<br/>（ユーザー数・実行時間等を指定） Lambda-->>GHA: 即時応答（202） Note over GHA: CloudWatch Logs のポーリングを開始<br/>（30秒間隔で結果ログを監視） Lambda->>Master: Worker の接続状況を確認<br/>（10秒間隔・最大120秒） Master-->>Lambda: 接続済み Worker 一覧 Lambda->>Master: テスト開始を指示<br/>（POST /swarm） Master-->>Lambda: 開始成功 Master->>Worker: テストシナリオを配信 Note over Worker: 負荷テスト実行中... Note over Lambda: 指定時間が経過するまで待機 Lambda->>Master: テスト停止を指示<br/>（GET /stop） Master->>Worker: 停止指示 Master-->>Lambda: 停止完了 Lambda->>Master: テスト結果を取得<br/>（GET /stats/requests） Master-->>Lambda: 統計データ（JSON） Note over Lambda: サマリを抽出<br/>（全体集計 + POST /orders） Lambda->>CWL: サマリをログに出力 GHA->>CWL: サマリログを検索 CWL-->>GHA: テスト結果（JSON） GHA->>GHA: Slack に結果を通知 こうしてLocustを毎週、自動実行することで、Locustを継続的に使用できる状態を保てるようにしています。 おわりに LocustはWeb UIからすぐに負荷テストを開始できるのが非常に便利です。 複数のテストシナリオを組み合わせて実行することもできます。 今後、BASEの決済や販売方法のテストシナリオを拡充した上で、テストを並走させることで、本番をよりシミュレーションした負荷テストを実施していければと考えています。 こうした負荷テストの仕組みに興味がありましたら採用情報もぜひご覧ください。 binc.jp