— 実装、レビューからHarnessの整備、そしてHarnessを評価するEvalsへ 1. はじめに こんにちは、開発本部開発1部デリッシュキッチン開発部所属の西本（ @daikon265 ）です。 6月11日に開催されたCode w/ Claude: Extended Tokyoに参加してきました。参加して感じたのは、Claude Codeの活用が「どうコードを書かせるか」から、「Claudeが安全に働ける環境をどう作り、どう改善し続けるか」に移っていることでした。 これまでClaude Codeの活用では、 Harness を使ってClaudeをうまく制御する話が中心だったと思います。 一方で今回のカンファレンスでは、そのHarness自体をどう評価し、どう育てるかという視点も強く出ていました。 Anthropicのエンジニアとの1on1で、私は次のような質問をしました。 モデルが進化するにつれて、 今のHarnessはだんだん形骸化して、 むしろ邪魔になっていくのではないか？ 返ってきた答えは印象的でした。 その直感は正しい。モデルが賢くなるにつれて、Harnessの重要性は下がっていく。Anthropic社内では、新しいモデルを定量評価し、その結果に基づいて、CLAUDE.mdを小さくするか、Skillsがノイズになっていないかを判断している。 Anthropicの中ではすでに、Evalsを使ってHarnessを評価し、必要なものを残し、不要になったものを削る運用が回っているということです。 本稿では、この考え方を抽象論に留めず、実際の開発フローに落とし込んで考えます。 大きくは、次の3つのフェーズで整理します。 1. 実装フェーズ 1-1. Plan：実装前に何を具体化するか 1-2. Implementation：サブエージェントにどう実装を分担させるか 2. レビュー・マージフェーズ 2-1. PRで何を見せるか 2-2. Claudeと人間でレビューをどう分担するか 3. 運用・改善フェーズ 3-1. マージ後に何を観察するか 3-2. 学びをどうHarnessに戻すか それぞれのフェーズで、カンファレンスで語られていた内容を紹介しつつ、自分たちの開発に取り入れるならどういう形になりそうかを整理していきます。 2. 実装フェーズ 実装フェーズは、さらに Plan と Implementation に分けて考えます。 ここでいうPlanは、実装前に仕様判断、実装判断、検証判断を具体化する工程です。自分も以前から、Claudeにいきなり実装させる前に、まず計画を作らせることはしていました。 ただ、その計画の立て方や粒度は曖昧になりがちです。 どこまでClaudeに質問させるのか。 どこまで仕様を固めるのか。 どの時点で検証条件を決めるのか。 どの情報を残しておけば、後続の実装やレビューで使えるのか。 今回のワークショップで分かりやすかったのは、まさにこの「Planをどう具体化するか」でした。 2-1. Plan：実装前に何を具体化するか 2-1-1. まずClaudeに質問させる 「How we Claude Code」ワークショップでは、エージェントが長時間自律稼働できるようになってきたことで、ミスのコストが上がっているという問題意識が語られていました。そこで紹介されていたのが、コードを書かせる前にClaudeへユーザーをインタビューさせ、曖昧さやエッジケースを引き出す方法です。 たとえば、次のような依頼は危険です。 友達用の割り勘アプリを作って この依頼だけでも、Claudeはそれらしいものを作れます。 しかし、保存方法はどうするのか、精算はアプリ内で行うのか、通貨は複数対応するのか、誰が誰にいくら払うべきかをどう最小化するのか、といった判断をClaudeが勝手に埋めることになります。 ワークショップで紹介されていたのは、次のようにClaudeに質問させる進め方です。 いくつか確信が持てない点があります。 まず私にインタビューして、仕様の曖昧なところを整理してください。 質問は一度に多くしすぎず、重要なものから聞いてください。 回答をもとに、実装前に合意すべき仕様をまとめてください。 デモでは、Claudeが用途、分割方法、保存方法、精算方法、通貨、共有方法などを質問し、回答に矛盾があれば追加で確認していました。その結果として、実装に入る前に詳細なspecが生成されていました。 ここで大事なのは、Claudeに質問させることで、実装前に判断が必要なことを表に出すことです。 2-1-2. 検証条件を先に決める Planで特に重要なのが、検証条件を先に決めることです。 検証に関するデモでは、実装前に Fixture、Invariant、Probe を決めることが強調されていました。 項目 意味 Fixture 検証時に再現する状態 Invariant 常に成り立っていてほしい性質 Probe 検証時に観測するポイント たとえばTo Doアプリなら、こうなります。 Fixture Invariant Probe 完了済みのTodoが1件ある 完了状態のデータと画面表示が一致している DOM上の状態属性、取り消し線の表示 非常に長いテキストのTodoがある レイアウトが崩れない 表示領域、折り返し、スクロール Todoが0件 空状態が表示される empty stateの文言、追加ボタンの表示 この考え方があると、Claudeも人間も「何をもって正しいと判断するのか」を共有できます。 2-1-3. Probeを実装上で観測できるようにする Fixture / Invariant / Probe を決めても、実装上でその状態を観測できなければ検証はしづらくなります。 このデモで特徴的だったのが、アプリの状態をDOMにスタンプする方法です。たとえばTodoが完了済みであれば、DOMに次のような属性を出します。 < li class = "todo-item todo-item--done" data -verified-done= "true" > oat milk </ li > 未完了であれば、 data-verified-done="false" になります。 ここで見たいのは、内部状態と画面表示の一致です。 data-verified-done="true" かつ 画面上も完了状態として表示されている Reactの内部状態を直接見に行く方法もありますが、実装依存になりやすく、検証のたびに扱いが面倒になります。そこで、検証したい状態をDOM属性として外に出しておくことで、Claudeや検証スクリプトが確認しやすい観測点を作ります。 つまりDOMスタンプは、Probeを成立させるための仕込みです。 これにより、内部状態としては完了済みなのに、画面上では完了済みに見えない、といったズレを検出しやすくなります。ワークショップでも、Reactのメモリ上ではTodoが完了済みなのに、画面に取り消し線が出ないケースを、この考え方で検出していました。 2-1-4. 自分たちのPlanでは何を残すか ここまでの内容を自分たちの開発に落とすなら、Planでは次の3つを残します。 ファイル 対応する考え方 書くこと spec.md インタビューで固めた仕様 作るもの、作らないもの、制約、未決事項 plan.md 実装の進め方 参照すべき既存実装、変更順序、実装方針 verification.md Fixture / Invariant / Probe / 観測点 再現する状態、守るべきルール、観測するポイント、コード上の観測点 verification.md には、単なる「テストする」で終わらせず、次の形で残します。 Fixture Invariant Probe 実装上の観測点（追加） 完了済みのTodoが1件ある 完了状態のデータと画面表示が一致している DOM上の状態属性、取り消し線の表示 data-verified-done 非常に長いテキストのTodoがある レイアウトが崩れない 表示領域、折り返し、スクロール Storybook / Playwright snapshot Todoが0件 空状態が表示される empty stateの文言、追加ボタンの表示 empty state selector Planのゴールは、Claudeが実装に入る前に、仕様判断・実装判断・検証判断を分離して、後から追える形にすることです。ドキュメントは、その判断を残すための手段として扱います。 2-1-5. Bunの実装ガイドを一般化する 「Rewriting Bun in Rust」では、ClaudeにBunをZigからRustへ書き直させ、約11日で巨大なPRをマージした事例が紹介されていました。 この事例で参考になるのは、実装に入る前に、複数のClaudeが同じ判断基準で動けるように、事前にルールを作っていた点です。 Bunでは、最初にClaudeと約3時間対話し、Zigの書き方をRustではどう表現するかを整理しました。その結果をポーティングガイドとしてまとめ、以後のClaudeインスタンスが必ず参照する資料にしています。さらに、Bunコードベース内の構造体やフィールドを調査し、ライフタイムに関する情報も共通資料として使っていました。 「ZigのパターンをRustにマッピングする」と言うと少し分かりにくいですが、要するにこれは 変換ルール集 です。 Bunの例 - Zigのこの書き方は、Rustではこう書く - メモリ管理はこの方針にする - crate分割はこの考え方にする - ライフタイムが複雑な箇所はこの資料を参照する これを自分たちの開発に置き換えると、次のようになります。 自分たちの例 - 古いAPI呼び出しは、新しいclientに置き換える - 独自UIは、design system componentに寄せる - 古いhooksは、新しいhooksに統一する - DB更新は、このmigration方針に従う - エラーハンドリングは、この形式に揃える 普段の開発では、これを implementation-guide.md として扱えばよさそうです。 変更の種類 作るもの 小さな修正 spec.md / plan.md / verification.md 複数箇所に同じ方針を適用する変更 implementation-guide.md を追加 複数のClaudeを並列に動かす変更 implementation-guide.md をほぼ必須にする 複数のClaudeを並列に動かす場合、全員が同じ判断基準を持っていないと、ファイルごとに実装スタイルがばらつきます。 implementation-guide.md は、そのばらつきを抑えるための共通ルールです。 コラム：HTMLプロトタイプはプロトタイプ開発で使える ワークショップでは、Planができた後にHTMLプロトタイプを作る方法も紹介されていました。 背景にあるのは、Anthropicの “Demos, not memos” という考え方です。Markdownの仕様書はClaudeには読みやすい一方で、人間が直感的に判断するには弱い。人間は、文字だけで仕様を読むより、触れるものを見たほうが「ここが違う」「この方向性は好き」と反応しやすい。そこで、ClaudeにHTMLで軽量なプロトタイプを作らせ、触りながら方向性を固める、という流れです。 自分でこれを取り入れるなら次のような感じがいいと考えています。 初期探索 - エンジニアがClaudeとHTMLプロトタイプを作る - 最低限触れる状態にして公開する - ユーザーや市場の反応を見る ブラッシュアップ - 反応が良ければ、Figmaでデザイナーに詳細を詰めてもらう - デザインシステムに載せる - 本格的に磨く この進め方は、今後増えていくと思います。 2-2. Implementation：サブエージェントに実装を分担し、失敗を再配布する Planができたら、実装に入ります。 ある程度の規模のタスクでは、複数のサブエージェントに分担させて並列に進めることが増えてきていると思います。 ここで参考になるのが、Bunの実装方法です。 Bunの事例では、並列実行時の制御も重要でした。重い操作や競合しやすい操作を各エージェントに任せきりにしないようにしていました。複数のClaudeがそれぞれbuildやtest、git操作を実行すると、同じ確認を重複して行ったり、同じworktree内で互いに干渉したり、全体の進行を遅くしてしまうからです。 そのため、build / test / git操作のような重い処理は、メイン側のワークフローで管理します。サブエージェントは実装や修正に集中し、メインエージェントが結果を集約して、失敗ログを分類し、担当するサブエージェントへ再配布します。 このループでは、役割を大きく3つに分けます。 役割 担うこと Main Agent spec.md / plan.md / verification.md を読み、作業を分割する。実装結果を集約し、build / test / lint / typecheck をまとめて実行する。失敗ログを分類し、必要なサブエージェントへ再配布する。 Sub Agents 割り当てられた範囲を実装する。必要に応じて、実装担当とレビュー担当を分ける。レビュー担当は diff や spec を読み、仕様違反、バグ、テスト不足を探す。 Human 仕様判断、設計判断、本番リスクを確認する。特にクリティカルな変更では、AIの検証結果だけでなくコードや動作も見る。 各サブエージェントに任せる範囲は絞ります。各サブエージェントがそれぞれ build や test を走らせ、個別に判断し始めると、重い処理が重複し、失敗ログの扱いもばらつきます。 そのため、検証と再配布は Main Agent 側に集約します。Main Agent が失敗ログを見て、次に誰へ戻すかを判断します。 失敗の種類 戻し先 build failure backend 担当の Sub Agent UI regression frontend 担当の Sub Agent test failure test 担当、または該当実装担当の Sub Agent migration error DB 担当の Sub Agent spec とのズレ 実装担当の Sub Agent 横断的な設計ミス Main Agent が plan を見直す このループの本質は、 検証結果を次のタスク分配の入力にする ことです。失敗を検出したら、原因ごとに担当へ戻します。さらに同じ失敗が繰り返されるなら、プロンプト、ルール、verification、implementation-guide 側に戻して、生成プロセス自体を直します。 3. レビュー・マージフェーズ レビュー・マージフェーズで重要なのは、検証結果を人間が判断しやすい形で見せることです。 3-1. PRでは検証結果を証拠として見せる PRには、変更概要や影響範囲だけでなく、動作確認や検証結果を載せます。 特にUIやワークフローが関わる変更では、スクリーンショットや動画が有効です。実際にどう動いたか、どの状態で確認したかが見えると、レビュアーは判断しやすくなります。 PRでは、最低限次の情報を揃えます。 PRに載せるもの 目的 変更概要 何を変えたかを短く把握する 影響範囲 どの画面・機能・APIに影響するかを見る 検証結果 どのFixture / Invariant / Probeを確認したかを見る スクリーンショット・動画 実際の動作やUIの崩れがないことを見る レビュアーに見てほしい箇所 判断が必要な点を明確にする 3-2. 検証ダッシュボードで状態と結果を見える化する 検証ダッシュボードのデモで特徴的だったのは、検証用のダッシュボードを作っていた点です。 通常のテストログでは、どのテストが通ったかは分かります。ただ、UIやワークフローの検証では、それだけだと「どの状態で、何を確認したのか」が見えにくい。そこで、検証ダッシュボード上に、どの画面・コンポーネントを、どのfixtureで、どのinvariantに対して検証したのかを表示します。 たとえば、次のような情報が見える状態です。 見えるもの 例 対象 画面、コンポーネント、ワークフロー Fixture 空状態、長いテキスト、大量データ、権限なしユーザー Invariant レイアウトが崩れない、状態と表示が一致する、権限外操作ができない Probe DOM属性、表示テキスト、APIレスポンス、エラー表示 結果 pass / fail、必要に応じてスクリーンショットや録画 これは、テストを増やす話というより、 検証結果をレビューできる形に変換する 話です。Claudeも人間も、同じ証拠を見ながら「何をもって正しいと判断したのか」を確認できます。 3-3. レビューはClaudeと人間で見る観点を分ける レビューでは、Claudeと人間の役割を分けます。 見る人 主に見ること Claude specとのズレ、テスト不足、エッジケース漏れ、権限・セキュリティの問題、既存挙動の破壊 Human 実際の動作、仕様解釈、設計判断、ユーザー影響、本番リスク Anthropicのエンジニアとの1on1では、社内ではすべてのPRに対してClaudeによる自動コードレビューが走り、その後に人間のレビュアーがハイレベルな観点で確認すると聞きました。 チーム内の運用イメージとしては、Claudeが細かいロジックやspecとのズレを拾い、人間が動作、設計、リスクを判断する形です。クリティカルな変更では、人間もコードを読みます。 4. 運用・改善フェーズ マージ後も観察と改善は続きます。 むしろ、マージ後に何を観察し、何をHarnessに戻すかが、Claude Codeをチーム開発に組み込むうえで重要になります。 4-1. マージ後も検証を増やす 「Rewriting Bun in Rust」では、テストスイートを通してマージした後も、品質強化が続いていました。マージ後にも別の角度から壊れ方を探す検証を増やしていたことが印象的でした。 たとえば、次のような検証です。 - セキュリティ上の問題を機械的に探す - ランダムな入力を大量に与えてクラッシュを探す - メモリリークのような実行時の問題を探す - テストでは通らなかったコード経路をさらに踏みに行く 講演で語られていた思想は、「動くことを信用したくない。動くことの実証的な根拠を持ちたい」というものでした。 マージ後に検証を増やすことは、次の開発ループを強くするための投資です。 4-2. EvalsでHarnessを育てる Evalsは、実装・レビュー・運用を回した後に、Harnessを改善するための仕組みとして効いてきます。 「Evals for taste: Hill-climbing a slide-generation agent」では、Evalsは「成功とは何か」を定義し、エージェントが改善しているかを確認するためのものだと説明されていました。最適化対象はプロンプトだけでなく、モデル選択、ツール設計、エージェントのアーキテクチャにも広がる、という話もありました。 「Tool, skill, or subagent? Decomposing an agent that outgrew its prompt」でも、Evalsを改善の絶対的な指針にすることが最大のメッセージとして語られていました。評価結果が上がることを確認できたからこそ、ツール、Skills、サブエージェント構成を改善できたという話です。 冒頭で触れた1on1の話に戻ると、モデルが賢くなれば、以前は必要だった細かい指示が不要になる。場合によっては、古いCLAUDE.mdやSkillsがノイズになる。だからこそ、Anthropic社内では新しいモデルを定量評価し、その結果に基づいて、CLAUDE.mdを小さくするか、Skillsがノイズになっていないかを判断しているそうです。 Harnessは作ったあとも、Evalsによって評価され、必要なら削られる。つまり、EvalsはClaudeの出力を採点しながら、Harnessを育てるための仕組みでもある。 自分たちも、Evalsによって「これはまだ効いているか」「もうノイズになっていないか」を見ていく必要があります。 4-3. 失敗をどこに戻すか マージ後に観察するものは、次のHarness更新の材料として見ます。 観察するもの Harnessに戻す先 本番で出たバグ eval / verification 繰り返し出るレビュー指摘 review skill / checklist 仕様の取り違え specの作り方 テスト漏れ verifier / contract test 不要になった指示 CLAUDE.md / Skill の削除候補 Skillsは、関連するタスクのときだけロードされる手順書として使うのが本質です。「Tool, skill, or subagent? Decomposing an agent that outgrew its prompt」でも、長いプロンプトをオンデマンドのSkillsに分解し、必要なときだけコンテキストをロードする考え方が紹介されていました。 Harnessを育てるほど、余計なものを削る視点も必要になります。 増やすもの 削るもの tests / evals / verifiers / CI / monitoring 古いCLAUDE.mdの指示 / ノイズになったSkill / 自明すぎるルール 「Evals for taste: Hill-climbing a slide-generation agent」では、evalスコアが飽和したらgrader自体を見直すべきだという話もありました。見た目は明らかに改善しているのにスコアが上がらないなら、評価側の解像度が足りない可能性があります。その場合は、graderの評価基準を具体化する価値があります。 Claudeの出力とあわせて、評価そのものも育てる。そのループがあると、Harnessの改善が感覚頼みから評価駆動に変わります。 5. 自分たちの開発に落とすなら ここまでの内容を実務に落とすなら、次の4段階で始めるのがよさそうです。 フェーズ やること 残すもの Plan 仕様、実装方針、検証条件を分けて整理する spec.md / plan.md / verification.md Implementation Main Agent が作業を分割し、Sub Agents が実装する。検証結果は Main Agent が分類して再配布する 失敗ログ、修正タスク Review / Merge PRでは検証結果や動作の証拠を見せる。Claudeは詳細、人間は仕様・設計・リスクを見る 検証ログ、スクリーンショット、レビュー結果 Post-merge 本番やレビューで出た失敗を、その場限りにせずHarnessへ戻す eval、verification、skill、checklist このフローでは、判断基準、検証可能性、レビュー可能な証拠、Harnessへのフィードバックを揃えることが大事です。 anthropic-dev-loop この流れは再利用できるように、Skillとしても整理しました。Claude CodeやCodexで同じ流れを使いたいときは、このSkillを読み込ませることで、Plan、実装分割、検証、レビュー、Harness更新までを一連の手順として扱えます。 https://github.com/nishimoto265/anthropic-dev-loop 6. おわりに 今回は、Code w/ Claude Tokyo / Extended Tokyoで紹介されていたAnthropicの開発手法を、自分たちの開発フローに落とし込むならどうなるのか、私なりの知見を交えながら整理しました。 Code w/ Claude Tokyo / Extended Tokyoの中で特に印象的だったのは、やはり Evals です。 私自身、評価関数があり、それに基づいてエージェントや開発フローが将来的には自動で改善されていくのではないかと考えていました。その考え方が Evals に現れており、Harnessを評価し、必要なものを残し、不要なものを削っていく手法は、今後さらに重要になっていくと感じています。 今後もAnthropicのエンジニアの手法を参考にしながら、Claude Codeを前提にした開発フローを自分たちなりに改善していきたいと考えています。

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 です。

Web未経験MLエンジニアが社内プロダクト開発でAIコーディングにどハマりするまで はじめに こんに ...