こんにちは。 CTO室/Platform開発チームでSREを担当している富田( @Cooking_ENG )です。 ファインディでは、サービスがどれほどの負荷に耐えられるかを把握し、性能の問題を表面化・改善することで、ユーザーに安定したサービスを提供できる状態を目指しています。 そこで、Grafana Labsが提供するGrafana Cloud k6を採用し、 負荷試験環境をゼロから構築 しました。今回は、 Findy Conference を対象に負荷試験を実施しています。 Findy Conferenceは、テックカンファレンスに特化したプラットフォームサービスです。 conference.findy-code.io この記事では、負荷試験ツールの選定から、本番トラフィックを再現するシナリオの作成、Grafana Cloud k6とDatadogを組み合わせた負荷試験の実施までの取り組みを、初めて負荷試験を担当するエンジニアの方々や、これから導入を考えているチームに向けて紹介します。 負荷試験環境を作ることになった背景 負荷試験ツールの選定 ファインディで重視した判断軸 候補ツールの比較 負荷シナリオの作成 har-to-k6を使ったスクリプトの作成 負荷のかけ方を調整するOptionsブロックの話 想定する負荷がかけられているかをDatadogを使って確認する方法 作成でつまずいたポイント Options内の値はリテラル必須 認証付きエンドポイントの扱い 負荷試験の実施と結果 負荷規模と必要コンテナ数 Datadogで取ったメトリクス まとめ 負荷試験環境を作ることになった背景 Findy Conferenceでは、セッションの開始や終了のタイミングで、参加者の方々が一斉にアクセスする 瞬間的なスパイク が発生する特徴があります。 過去のBlogにまとめているので、気になる方はぜひ こちらの記事 もご覧ください。 tech.findy.co.jp こうしたスパイクに備えるため、カンファレンス開催前にコンテナ数を増やす運用をしてきました。コンテナ数を決める際の判断はチームの経験値に基づいていたため、本当にその数で十分なのか、過剰になっていないかを根拠を持って判断できない状態でした。 そこで、想定するスパイクに対して 実際の計測値に基づいた最適なコンテナ数を設置できる 状態を目指し、負荷試験環境の整備に取り組むことにしました。 負荷試験ツールの選定 ファインディで重視した判断軸 ツール選定にあたり、ファインディの状況に合わせて次の判断軸を置きました。 インフラ管理が不要であること（環境の構築・運用コストを抑えたい） シナリオ作成の自由度（本番に近いユーザー導線を再現できる） サービスの継続性（SaaSとして長く使えるか） コスト（従量課金で、使わないときに費用が膨らまないこと） 候補ツールの比較 候補として、次のツールを比較しました。 サービス シナリオ記述 提供形態 運営元 特徴・得意領域 Grafana Cloud k6 JavaScript SaaS（OSS版あり） Grafana Labs モダンな開発体験、Grafana統合、専用ダッシュボードが標準。OSS版でローカル実行も可能 BlazeMeter JMeter／GUI SaaS Perforce JMeter資産を活かしやすい。詳細なレポートとGUI操作に強み Gatling Enterprise Scala／Java SaaS Gatling Corp 大規模負荷試験に強み。Javaエコシステムとの親和性が高い Locust Python OSS Locustコミュニティ Pythonでシナリオを柔軟に記述できる。軽量で分散実行にも対応 JMeter GUI／XML OSS Apache Software Foundation 長年の実績と豊富なプラグイン。対応プロトコルが幅広い それぞれのツールには得意な用途があります。今回はファインディの判断軸を基準に評価しました。 評価の結果、Grafana Cloud k6を採用しました。 先に挙げた4つの判断軸それぞれに対する評価は次のとおりです。 判断軸 Grafana Cloud k6での評価 インフラ管理 マネージドサービスのため、負荷試験用の環境を自前で構築・運用する必要がない シナリオ作成の自由度 JavaScriptベースでシナリオを記述するため、フロントエンド／バックエンド双方のエンジニアが読み書きしやすい サービスの継続性 運営元のGrafana Labsが監視・可視化領域のサービスを長く提供している実績があり、長期利用の見通しを立てやすい コスト Proプランの月額が$19、500 VUh/月までは無料枠、超過分も$0.15/VUhの従量課金で、使わないときに費用が膨らまない（2026年6月時点。最新は 公式料金ページ を参照） なお、負荷をかける対象である アプリケーション側のCPUやメモリ といったサーバーリソースは、Grafana Cloud k6では取得せず、すでにアプリケーション側に導入していたDatadogで観測する構成にしました。 Grafana Cloud k6でHTTPメトリクスを、Datadogで負荷をかけられる側のリソースメトリクスを観測する役割分担 です。 負荷シナリオの作成 ここからは、実際に負荷シナリオをどう作っていったかを紹介します。 har-to-k6を使ったスクリプトの作成 本番に近いユーザー導線を再現するには、ユーザーがどのエンドポイントにどの順でアクセスするかをシナリオとして書き起こす必要があります。当初は手作業でシナリオを書こうとしましたが、ステージング環境ではCognitoに加えてファインディ独自の認証基盤「Findy ID」など複数の認証を突破する必要があり、認証の流れをスクリプトで再現するのは簡単ではありませんでした。 そこで、 har-to-k6 を使い、ブラウザの操作ログからk6のシナリオを生成する方法に切り替えました。har-to-k6は、ブラウザの開発者ツールで書き出せる HAR（HTTP Archive）ファイル を入力として、k6用のJavaScriptシナリオを生成してくれる公式ツールです。ブラウザで一度認証を通したあとの操作をHARとして記録すれば、認証後のリクエストをそのまま再現できるため、手作業で書くよりも本番に近いシナリオを効率よく用意できました。 おおまかな流れは次のとおりです。 ブラウザの開発者ツールで、再現したい操作を実行し、HARファイルを書き出す har-to-k6 input.har -o script.js でk6用のJavaScriptに変換する 生成されたスクリプトを、シナリオに不要なリクエストの除去や認証情報の環境変数化などに合わせて整える HARから変換した直後のスクリプトには、画像・CSS・JavaScriptファイルなどの静的アセット取得のリクエストや、HARに含まれていた認証情報（パスワードなど）がそのまま残っています。これらの整理にはClaude CodeなどのAIコーディング支援ツールが便利でした。 ただし、平文のパスワードをそのままAIに渡すのはセキュリティ上避けたいので、先に認証情報を __ENV.TEST_PASSWORD のような形で環境変数化し、それから不要なリクエストの除去をAIに任せました。AIを活用することで、手作業で1つずつ削るよりも短い時間で本番に近いシナリオを用意できました。 負荷のかけ方を調整するOptionsブロックの話 k6のシナリオでは、 options というブロックで負荷のかけ方を細かく制御できます。今回のシナリオでは、 ramping-arrival-rate というexecutorを使って、 スパイクの立ち上がり・ピーク・収束を1本のシナリオで再現する 構造を採用しました。 なお、k6では負荷シナリオの関数が1回実行されることを「イテレーション」と呼びます。今回のシナリオは1イテレーションのなかで複数のHTTPリクエストを送る構成です。 実際のOptionsブロックは次のような形です（数値は記事用のダミー値であり、対象サービスや想定するスパイク規模に応じて調整します）。 export const options = { scenarios: { spike: { executor: 'ramping-arrival-rate', startRate: 0, timeUnit: '1m', preAllocatedVUs: 50, stages: [ { duration: '10s', target: 100 }, { duration: '10s', target: 200 }, { duration: '50s', target: 200 }, { duration: '10s', target: 0 }, ], }, }, cloud: { distribution: { tokyo: { loadZone: 'amazon:jp:tokyo', percent: 100 }, }, }, }; 主な設定項目は次のとおりです。 設定項目 説明 executor 負荷のかけ方のパターン。 ramping-arrival-rate は、各ステージのtargetに向けてイテレーション数をなめらかに増減させ、山型の負荷曲線を表現できる startRate 開始時点のレート。今回は0から立ち上げる timeUnit targetの単位時間。 '1m' にすると目標値を「1分あたりのイテレーション数」で指定できる preAllocatedVUs 目標レートを捌くために事前に確保しておく仮想ユーザー（VU）数 target 各ステージで到達させたい目標イテレーション数/ timeUnit 。 timeUnit: '1m' なら target: 100 は「1分あたり100イテレーション」を意味し、durationをかけてその値までなめらかに増減する timeUnit を '1m' にしているのは、過去のカンファレンスの実測値を「1分あたりのリクエスト数」で把握していたためです。この実測リクエスト数を1イテレーションあたりのリクエスト本数で割ることで、必要なイテレーション数（target）を算出し、シナリオの単位もこれに揃えました。 stagesを4段に分けているのは、本番のスパイクを次のような流れで再現するためです。 1段目（10秒）：本番想定の半分まで急速に立ち上げ、アクセス急増の前兆を再現 2段目（10秒）：本番想定まで一気に到達させる 3段目（50秒）：本番想定の負荷を維持して、システムが安定して捌けるかを観察する 4段目（10秒）：目標値を0に戻し、収束させる cloud.distribution では、Grafana Cloud k6上で負荷を発生させるAWSのリージョンを指定しています。今回は実際のユーザーアクセスに近づけるため、東京リージョン（ amazon:jp:tokyo ）を100%としました。 想定する負荷がかけられているかをDatadogを使って確認する方法 ここがいちばん試行錯誤したところでした。 k6側のレポートで「目標としていたイテレーション数を発行した」と表示されていても、それが アプリケーションのコンテナに実際に届いたリクエスト数 と直接一致するわけではありません。今回のシナリオは1イテレーションで複数のリクエストを送るためです。 そこで、まず「イテレーション数 × 1イテレーションあたりのリクエスト本数」で、アプリケーションに届くはずのリクエスト数（期待リクエスト数）を見積もりました。そのうえで、k6側のtargetを微調整しながら、期待リクエスト数どおりの負荷がかかるように調整していきます。 調整したリクエストが実際に届いているかは、Datadogで確認します。ファインディではもともとDatadogでオブザーバビリティに取り組んでおり、各サービスのダッシュボードを運用しています。負荷試験のメトリクスも普段の監視と同じダッシュボードで確認できるため、状態を把握しやすい環境がすでに整っていました。 ただし、どのメトリクスを見るかで数字の意味が変わります。観測候補をいくつか比較した結果、 ALBのレスポンス数 を見ることにしました。今回はレスポンス数を、アプリケーションが実際に処理した負荷の指標として扱っています。 観測対象 負荷確認の用途として 理由 ALBのレスポンス数 適している アプリケーションが実際に返したレスポンス数。見積もった期待リクエスト数と突き合わせやすい CloudFrontのリクエスト数 向かない CDNキャッシュや静的アセット分が水増しされ、k6の発行数とずれる APMのリクエスト数 やや向かない サンプリングで一部を間引いて記録するため、実際より低めに見えることがある ALBのレスポンス数の推移を見て、見積もった期待リクエスト数どおりの負荷が処理されているかを判断します。値が想定より少ない場合は、CloudFront側で弾かれているリクエストがあるか、シナリオ側で意図しないエンドポイントを叩いていないかを見直すサインになります。 次の図は、ある負荷試験でのALBのレスポンス数の推移です。シナリオで設計したとおり、短時間で立ち上がってピークに達し、収束していく山型になっていることが確認できます。 作成でつまずいたポイント シナリオを書く過程でつまずきがあったので、これから取り組む方向けに共有します。 Options内の値はリテラル必須 Grafana Cloud k6のプレビュー画面では、Optionsブロックの値を静的解析してVUh（仮想ユーザー時間）を試算します。このとき、 Math.round() のような関数呼び出しや、外部の定数を参照する書き方は評価できず、 VUhが正しく計算されません 。 // NG（VUh が計算されない） const MaxTarget = 200; export const options = { scenarios: { spike: { stages: [ { duration: '50s', target: MaxTarget }, // 変数参照は評価されない ], }, }, }; // OK（リテラル数値で書く） export const options = { scenarios: { spike: { stages: [ { duration: '50s', target: 200 }, ], }, }, }; DRYに書きたくなる気持ちはありますが、Optionsブロックに限ってはリテラルで書くことを徹底すると安全です。 認証付きエンドポイントの扱い ステージング環境を本番相当にスケールアップして試験する場合、認証が挟まる導線では CloudFront → Cognito → アプリケーション のようにリダイレクトが連鎖します。最初から本番想定のシナリオを流すと、認証で弾かれてうまく負荷がかからないことがあります。 そこで、まずは /health のような疎通確認用エンドポイントに redirects: 0 を付けてリクエストを送り、想定どおりに200や302が返ってくるかを確認してからシナリオを組み立てるのがおすすめです。 負荷試験の実施と結果 ここまでで作ったシナリオを使い、ステージング環境を本番相当にスケールアップしたうえで負荷試験を実施しました。ここでは、ファインディがどのように 「想定スパイクごとに必要なコンテナ数」を割り出した のかを紹介します。 次の図は、Grafana Cloud k6で負荷試験を実行したときの結果サマリです。設計したとおりに負荷がかかってピークに達し、その間エラーを出さずに処理できていることが確認できます。 ※画像はイメージです。 負荷規模と必要コンテナ数 過去のカンファレンスでの参加者数と実測リクエスト数から、想定する負荷規模（1分あたりのリクエスト数）を複数段階用意し、負荷規模ごとに試験しました。 コンテナ数を判定する指標は、次のように定めました。 項目 内容 判定指標 ecs.fargate.cpu.percent （Datadog） 観測対象 Findy Conferenceのなかで最もリクエストが集中するバックエンドサービス 閾値 50% ボトルネックになりやすいバックエンドサービスのCPU使用率を直接観測することで、コンテナ数の過不足を判断します。 閾値を50%にした背景 オートスケールはより低いCPU使用率で発動するように運用していますが、スパイク時は追いつく前にアクセスが集中してしまいます。 そのため、発動を待つよりも、CPU使用率が50%を超えた時点でコンテナを増やす判断をしたほうが、カンファレンス運営では安全だと考えました。 試験は次のサイクルで進めました。 想定する負荷規模のシナリオをGrafana Cloud k6から実行する DatadogでバックエンドサービスのCPU使用率とSLOに関わるメトリクスを観測する CPU使用率が閾値（50%）を超えた場合はコンテナ数を増やし、同じシナリオを再実行する SLOの範囲内に収まる最小のコンテナ数を、その負荷規模での必要数として記録する この流れを負荷規模ごとに繰り返した結果、想定するカンファレンスの規模ごとに必要なコンテナ数を割り出すことができました。これにより、開催前のコンテナ調整を経験頼みではなく計測値に基づいて行えるようになっています。 Datadogで取ったメトリクス 試験中はCPU使用率のほかにも、次のメトリクスをDatadogで観測しました。 メトリクス 観測する目的 ECSのCPU・メモリ使用率 コンテナのリソースに余裕があるか（コンテナ数判定の主指標） APMのレイテンシ（p95） 遅いリクエストがSLOの範囲に収まっているか DBのコネクション数 データベース側がボトルネックになっていないか エラー発生率 負荷によってエラーが増えていないか また、試験結果の分析にはDatadogのBitsAIも活用しました。試験中のメトリクスからサマリを生成してNotionに集約し、開発チームへの共有や改善提案につなげています。 まとめ 今回は、Grafana Cloud k6とDatadogを組み合わせて、Findy Conferenceの負荷試験環境をゼロから構築した取り組みを紹介しました。コンテナ数の判断を、チームの経験値から計測値に基づくものへ変えられたことが大きな成果です。 ここで整理した手順は他のサービスにも応用できると考えており、今後はファインディで提供している各サービスでも横断的に負荷試験を実施できる体制へ広げていきたいです。 この記事が、これから負荷試験に取り組むエンジニアの方々やチームの参考になれば嬉しいです。最後までお読みいただきありがとうございました！ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

1. はじめに こんにちは、ソリューションアーキテクトの戸塚と中本と宇加治です。 AWS Summit Japan 2026 の AWS Builders’ Fair にて、パデルフォーム分析アプリを展示します。パデルを知らない方向けに簡単に説明すると、テニスとスカッシュを合わせたような、壁に囲まれた小さめコートで 2 対 2 のダブルスだけで行うラケットスポーツです。この展示は、テクノロジーでスポーツ体験を拡張し、競技者の感覚や経験だけでは捉えにくいフォームの違いを可視化する取り組みとして、多くの方に触っていただきたい内容となっています。 このブログでは、展示の概要、使用している技術スタック、AI 駆動の開発手法、そしてこのシステムが解決する課題と他インダストリーへの応用可能性についてご紹介します。エンジニアの方もたくさん参加されていると思うので、ぜひ技術的な観点からも楽しんでいただければ嬉しいです。 2. AWS Summit Japan 2026 について AWS Summit Japan 2026 は、2026年6月25日から26日まで幕張メッセで開催される、クラウドと AI イノベーションの最前線を体験できる 2 日間の無料イベントです。260 以上のセッションに加え、AWS Village、ワークショップ、Partner Solution Expo など多彩なコンテンツが用意されています。AWS Builders’ Fair エリアは、AWS エンジニアが自作した “遊べる” デモを体験しながら、AI・IoT・サーバーレスなどの活用事例を学べるハンズオン型の展示ゾーンとなっています。来場者は自由にブースを回り、生成AI・IoT・サーバーレスなどを組み合わせたインタラクティブなデモを、実際に触ったり遊んだりしながら体験できます。 3. パデフォーム分析アプリ展示概要 このアプリは、 Meta Quest （VR ヘッドセット）、 HaritoraX （モーションキャプチャデバイス）、カメラによる骨格推定技術（ MoveNet ）を組み合わせ、バーチャル空間でパデルの球出しを受けた際の動作を計測・分析する仕組みです。 単にスイングを記録するだけではなく、身体の各部位の動きやタイミングの差分をとらえ、トッププレーヤーのフォームと比較評価できるように設計しています。 3.1 体験の流れ VR 空間で球出しを受ける — Godot で構築された 3D 空間内でプレー リアルタイムモーションキャプチャ — HaritoraX + カメラで動作データを取得 フォーム分析 — DTW(Dynamic Time Wrapping) アルゴリズムでトッププレーヤーのフォームと比較　※ 結果表示 — 5 指標のスコアカード + 生成 AI によるアドバイス VR、Haritora、カメラの３つのソースを統合して、最終的に 5 つの指標として評価するように実装しています。 写真: VR 空間でプレーする体験者の様子 図: 5つの評価指標を算出するための各データソースの役割 ※骨格推定には OpenPose や MoveNet といったスポーツ動作分析の標準手法を使っています。時系列比較の DTW は、 Ba č i ćらが 2022 年の VISAPP でストローク分類に使用しています。プロとの比較は Stanford の Liu が 2025 年に DTW によるプロ対アマ比較 を行っています。フェーズ分割はバイオメカニクスの標準的なアプローチとなっています。 写真: リアルタイムモーションキャプチャのデータ確認画面 ゲームとして楽しめるだけでなく、トレーニングにもなる設計を目指しています。プレイヤーは VR 空間の中でさまざまなボール（レボテやコントラパレットを含む）に対応することになり、楽しみながらフォームの改善ポイントを発見できます。 3.3 トッププレーヤーの教師データ 事前計測には、パデルトッププレーヤーとして久留広平選手、内海信仁選手、瀧田瑞月選手、内海和心選手に AWS オフィスへお越しいただきました。計測で取得したデータは、すでにアプリ内の教師データとして実装されており、体験者は彼らのフォームとの差異を比較できるようになっています。 この仕組みの面白さは、単に「上手い・下手」を判定することではありません。トッププレーヤーの動作を基準にすることで、打点の入り方、身体の回旋、重心移動、準備動作の速さなど、普段は言語化しにくい技術要素を、比較可能な形で捉えられる点にあります。 また、コーチングや自己改善の文脈でも活用しやすいのが特徴です。感覚に頼りがちなフォーム指導に対して、再現性のある比較軸を持ち込めるため、競技経験者はもちろん、これから上達したいプレーヤーにとっても新しい学習体験になり得ます。 写真: 計測結果のスコアカード画面（数値化 + 生成 AI アドバイス） 3.4 トッププレーヤーからのコメント 教師データ計測に協力いただいた選手から、本システムを実際に使用した感想をいただきました。システムの可能性を評価する前向きなコメントに加え、今後の活用方法に関するアイデアも頂戴しました。 ■ 久留 広平選手(日本代表) コーチの視点では、フォームや身体の使い方を指導する際に選手がイメージしている動作と実際の動作に乖離が見られるケースがあり、そのような場面でデータに基づくフォーム分析を活用することで、効果的な指導につなげられると感じました。 ■ 内海 信仁選手(ベテラン日本代表) 日本は世界から30年のビハインドがあり、中東、東南アジアは英語が話せるアドバンテージでどんどん差を埋めていますが、日本はそれが出来ていません。それをテクノロジーで埋めていくというのは日本らしさがあってとても素晴らしいと感じました。 ■ 瀧田 瑞月選手(2018〜2023 日本代表 2025年 Jr 日本代表サブコーチ) 率直に、これからの可能性にとてもワクワクしました。パデルに限らず、エンターテインメントやコーチング、競技力向上など、さまざまなカテゴリーで活用できる可能性を感じました。今後どのように発展していくのか、とても楽しみです。 ■ 内海 和心選手(日本代表) 自分の足りないところやいいところを見つけてくれるところが面白いと感じました。プロと比べて何が劣っているかとか見つかるところが今後の成長に繋がりそうだと思いました。 4. システムアーキテクチャ 4.1 全体構成 この展示は、スポーツテック、XR、センシング、コンピュータビジョンを横断する実験でもあります。Meta Quest による没入的な体験、HaritoraX によるモーションキャプチャ、カメラベースの骨格推定による姿勢解析を組み合わせることで、単一センサーだけでは捉えきれないフォーム情報を多面的に扱えるようにしています。VR アプリ構築には、Unity や Unreal Engine なども候補にあがりましたが、今回は費用も極力抑えることを考え、完全無料でオープンソースの Godot を採用しました。Godot は、Python に似た独自の言語「GDScript」を使います。文法がシンプルで読みやすいため初心者でも学習しやすい設計になっています。もちろん C# や C++ も使うことができます。今回はこの GDScript 等を Kiro の力を活用することで、自然言語でのやりとりでこのような VR アプリのオブジェクトや VR 空間での挙動までもプログラミングしているので、GDScript の学習コストはかかりませんでした。 本システムは以下のコンポーネントで構成されています: 図: システム全体概要 レイヤー 技術 用途 VR / 3D 空間 Godot Engine VR空間内でのパデル球出しシミュレーション。自然言語（Kiro）で開発 VR デバイス Meta Quest VR ヘッドセットによる没入体験 モーションキャプチャ HaritoraX 身体トラッキング（全身の動きを取得） 骨格推定 MoveNet (TensorFlow Hub) カメラ映像からリアルタイム骨格推定（17 キーポイント） フロントエンド Tauri v2 + React + TypeScript + Vite デスクトップアプリ（結果表示・操作 UI） バックエンド バックエンド Python FastAPI + Uvicorn リアルタイム分析 API（WebSocket 対応） フォーム比較 DTW (Dynamic Time Warping) 時系列データの非線形マッチングによるフォーム比較 クラウド AWS CDK (ECS Fargate + ALB + S3 + DynamoDB) 評価処理のオフロード、スコア永続化、ランキング AI フィードバック Amazon Bedrock スコアに基づくパーソナライズされた改善アドバイス エッジ側で動くアプリケーションは AWS IoT Greengrass の OTA (Over the Air)アップデート を使ってアプリ配信をする仕組みをとっており、複数拠点にあるアプリを遠隔で更新できる様にしています。また計測後のフィードバックは骨格推定を含んだ動画も見れるようになっており、動画配信は Amazon CloudFront を活用してレイテンシーが抑えられる形にしています。 図: エッジ側を含めた AWS 構成 4.2 AI 駆動の 3D 開発: Kiro × Godot 今後、3D や VR の需要はさらに高まっていくと見られます。一方で、3D プログラミングは従来、空間座標やベクトル演算、物理エンジンの理解など専門性が高く、参入障壁が高い領域でした。 今回のプロジェクトでは、Godot Engine を使った 3D 空間のプログラミングを、Kiro（AI コーディングアシスタント）を用いた自然言語プログラミングで実施しています。たとえば「ボールを放物線で飛ばしてラケットの当たり判定を追加して」「壁に当たったらレボテ（跳ね返り）する物理を実装して」といった指示で、3D 空間の挙動や空間認識のロジックを実装できました。 これにより、3D/VR 開発の経験が浅いエンジニアでも、アイデアを素早くプロトタイピングし、スポーツシミュレーションのような複雑な 3D アプリケーションを構築できることを示しています。AI 駆動の開発が、従来は専門家の領域だった 3D プログラミングの民主化を進める一例と言えます。 4.3 モーションキャプチャデータ連携の技術的課題 本システムの開発で最も技術的に挑戦的だったのは、異なるモーションキャプチャソースからのデータ統合です。 具体的には以下の課題がありました: 座標系の統一: HaritoraX（慣性式）、Meta Quest（光学式）、MoveNet（画像ベース）はそれぞれ異なる座標系・スケールで動作データを出力します。これらを統一的な骨格表現に変換する必要がありました。 データ同期: デバイスごとにサンプリングレートが異なり（カメラ 30fps、HaritoraX 100Hz 等）、時刻同期とリサンプリングの仕組みが必要でした。 欠損補間: オクルージョン（身体の一部が隠れる）時のデータ欠損を、他デバイスのデータで補間する戦略を設計しました。 リアルタイム性: 分析結果を体験者にすぐフィードバックするため、WebSocket 経由でのストリーミング処理パイプラインを構築しました。 これらの課題に対して、Kinesis 経由でデータを送りつつ UNIX タイムの時間同期、骨格情報との相対位置によるキャリブレーションにより統合し、クラウドと連携して分析する — これはまさに AWS が得意とする領域です。 5. 今後の可能性 5.1 このアプリが解決する課題 スポーツの世界では、トップ選手の技術は見えているようで、細部まではなかなか共有されません。コーチングの現場でも、「もっと腰を回して」「タイミングが遅い」といったフィードバックは、指導者の主観に依存し、再現性に乏しいものでした。 本システムは以下の課題を解決します: フォーム指導の属人化: 感覚的な指導を定量データに置き換え、再現性のある比較軸を提供 上達実感の欠如: スコアの時系列推移を記録し、小さな改善も可視化 トップ選手の技術の暗黙知化: 動作データとして記録し、比較可能な形でアクセス可能に フィードバックの即時性: リアルタイム計測 → 即座にスコア表示、改善ポイントを AI が提示 エンゲージメントの低下: VR ゲームとして楽しみながらトレーニングできる体験設計 5.2 他インダストリーへの応用可能性 本システムのコアである「モーションキャプチャ × AI 比較分析 × リアルタイムフィードバック」は、パデルに限らず幅広い分野に応用可能だと考えています。以下にユースケースを示します。 インダストリー 応用例 期待効果 スポーツ全般 テニス、ゴルフ、野球のスイング分析、サッカーのキック分析 定量的なフォーム改善、怪我予防 リハビリ・ヘルスケア 理学療法での動作評価、リハビリ進捗の定量モニタリング 回復度の客観的評価、遠隔リハビリ 製造業 作業員の動作分析、熟練工の技能伝承 品質向上、教育期間短縮 エンターテインメント ダンスや演技のフォーム評価、モーションキャプチャ活用 パフォーマンス向上、ゲーミフィケーション フィットネス パーソナルトレーニングのフォームチェック、ヨガのポーズ評価 トレーナー不在時の自己改善 介護・高齢者支援 歩行分析、転倒リスク評価 早期異常検知、予防介護 技術的には、DTW による時系列比較は人間の動作全般に適用可能であり、教師データ（基準動作）を差し替えるだけで異なるドメインに展開できます。AWS のクラウドインフラ（AWS Lambda, Amazon S3, Amazon DynamoDB,Amazon Bedrock, AWS IoT Greengrass等）を活用することで、スケーラブルかつ低コストな運用が可能です。 5.3 今後の展望 今回の展示はデモでありながら、今後の展開余地が大きい取り組みでもあります。 プレーヤーごとの癖や成長過程の可視化 ショット別の比較分析（フォアハンド / バックハンド / ボレー / バンデッハ） レベル別の推奨フィードバック コーチとの振り返り支援（セッション動画 + スコアの共有） 「どのトッププレーヤーのフォームに近いか」のパーソナライズ分析 マルチスポーツ対応（テニス、バドミントン、ゴルフ等） 写真: 教師データとして協力いただいたパデルトッププレイヤーの皆様 6. ぜひ会場で体験してください AWS Summit Japan 2026 の AWS Builders’ Fair は、遊び心あふれるテクノロジー展示を実際に見て、触って、開発者と会話できる場です。パデルフォーム分析アプリも、スポーツとテクノロジーが交わる体験を、できるだけ直感的に楽しんでいただけるよう準備しています。 ブースでアプリを体験いただいた方には、Amazon Padel ステッカーを配布予定です。AWS Summit Japan 2026 に参加される方は、ぜひ Builders’ Fair に立ち寄って、トッププレーヤーとのフォーム比較を体験してみてください。 AWS Summit Japan 2026 公式サイト: https://aws.amazon.com/jp/summits/japan/ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 中本 翔太(Shota Nakamoto) ネットワークチームに所属するソリューションアーキテクトで、サービス業界のお客様を中心にご支援をしています。 宇加治 邦生(Housei Ukaji) サービス業界のお客様を中心にご支援をしています。好きな AWS サービスは Kiro CLI です。

おはようございます。カケハシのPE事業に関する開発チームでソフトウェアエンジニアをやっているogijunです。 PE（Patient Engagement）事業は、患者さん自身が自分の治療や健康維持に前向きに関わっていけるよう支援する事業で、電子薬歴『Musubi』や服薬フォローアプリ『Pocket Musubi』に新たな機能を届けています。 今回は、私たちが事業を通じて開発中に実際に遭遇した課題を題材に、ふだん設計時にどういう判断をしながら実装を進めているのか？というのを紹介します。 具体的にはこういう要件でした。とあるサービスで、サービス横断でアンケート等に使われているフォーム送信基盤があ…