フィットネスアプリの運動DBにexercises-datasetが選ばれる理由

フィットネスアプリの開発で最初に立ち止まるのが、エクササイズデータをどこから調達するかという問題です。自作するには数百〜数千件の運動を分類・翻訳・撮影する必要があり、既存 API を使えば継続費用と依存が発生します。

そこで候補に上がる OSS の一つが、Hasan Emir Yıldırım 氏が公開する hasaneyldrm/exercises-dataset（GitHub スター 19,506・フォーク 2,409、archived=false / fork=false）です。1,324 件のエクササイズを 10 言語で提供し、180×180 のアニメーション GIF まで同梱しています。

ただし、フィットネス系のエクササイズ OSS は複数系統があり、提供形態（データのみ / アプリ丸ごと / API サーバー）・件数・ライセンス・メディア権利の扱いが大きく異なります。とくに exercises-dataset のライセンスは、GitHub 上では NOASSERTION と表示され、実体は「MIT + 媒体別条件」の二層構造になっています。ここを見誤ると商用配信の段階で法務リスクを抱えるため、採否判断の前に整理しておく必要があります。

本記事では、exercises-dataset の中身と付属ツール、二層ライセンスの実務的意味、そして類似 OSS（yuhonas/free-exercise-db、wger、ExerciseDB API）との比較を通じて、「フィットネスアプリの運動 DB としてこのリポジトリを採用すべきか」を判断できる材料を整理します。実行や環境構築は行わず、リポジトリの README・LICENSE・NOTICE.md および各リポジトリの公開ドキュメントに基づく分析です。

exercises-dataset とは：フィットネスアプリ向け OSS の位置づけ

exercises-dataset は、フィットネスアプリ・ワークアウト管理アプリの「運動データ層」を担うことを想定した OSS プロジェクトです。1,324 件のエクササイズをカテゴリ・器具・対象筋別に構造化し、10 言語の説明文と 180×180 の GIF/画像を同梱した JSON データセットとして配布されています。加えて、データを閲覧するための対話型ブラウザ（index.html）と、DB インポートや API 生成を支援するセットアップウィザード（setup.html）が付属します。

リポジトリ属性は次のとおりです（hasaneyldrm/exercises-dataset の GitHub API 応答より）。

GitHub 上の言語判定が「HTML」となっているのは、index.html と setup.html を同梱しているためです。実体は「JSON データ + HTML ツール」であり、通常の意味でのプログラミング言語というよりは、データ + それを扱う静的 Web ツールという構成です。GitHub の言語ラベルだけを見て「HTML プロジェクト」と誤読しやすい点は、選定時に念頭に置くと迷いが減ります。

何を提供するリポジトリか

README（リポジトリトップ）で示されている提供物は以下です。

• 1,324 件のフィットネスエクササイズデータ（data/exercises.json）
• 各エクササイズのカテゴリ / 部位 / 器具 / 対象筋 / 二次筋の分類
• 10 言語の step-by-step 説明文（英語・スペイン語・イタリア語・トルコ語・ロシア語・中国語・ヒンディー語・ポーランド語・韓国語・フランス語）
• 180×180 のサムネイル画像（images/）
• 180×180 のアニメーション GIF（videos/）
• 対話型ブラウザ index.html（クライアントサイド完結・サーバー不要）
• 開発者向けセットアップガイド setup.html（DB インポート + API 統合 + LLM プロンプト生成）

なお、GitHub のリポジトリ description には「6 languages」と記載されていますが、README の記述および data/exercises.json のフィールド構造では 10 言語対応となっています。本記事では詳細度の高い README を正として 10 言語で統一しています。

姉妹プロジェクト LogPress との関係

exercises-dataset は、同じ作者による hasaneyldrm/logpress-public（AI 支援型のワークアウトトラッカー、React Native、iOS/Android）の「データ層」として位置づけられています。LogPress 側は本格的なモバイルアプリで、exercises-dataset は運動データの供給元です。この関係は「他プロジェクトへ組み込むことを前提にデータ層を切り出した OSS」という設計意図の裏づけになります。README でも「Building your own fitness app? Drop it straight into your backend.」と、自プロジェクトへの組込みが明示的に推奨されています。

リポジトリ属性の要約

archived=false / fork=false から、本記事執筆時点でアーカイブ済みでもフォーク由来でもない、能動的にメンテナンスされているオリジナルリポジトリです。ただしタグ/リリース運用はなく（gh api /repos/hasaneyldrm/exercises-dataset/tags の返り値は空配列）、バージョン固定が必要な場合はコミット SHA で参照する必要があります。プロダクション組込みでは、依存する時点の SHA を記録しておくと後で挙動差分を追いやすくなります。

データセットの中身：1,324 件・10 言語のフィールド設計

このデータセットの価値は、単に件数が多いことではなく、フィールドが構造化されており多言語対応まで含めて整合していることにあります。ここでは data/exercises.json のスキーマと部位別・器具別の内訳を整理します。

エクササイズレコードのフィールド構造

README によると、各エクササイズは概ね以下のフィールドで構成されています（詳細な JSON Schema は data/exercises.schema.json（Draft 2020-12）に定義されています）。

instructions と instruction_steps の 2 系統を持つ点が実装上重要です。前者は 1 段落での説明、後者は箇条書き向けの配列で、UI 側の表現に合わせて使い分けられます。

部位別・器具別の内訳

README の統計テーブル（リポジトリトップ の Statistics セクション）から、部位・器具別の内訳を要約します。

部位別のエクササイズ数:

器具別の主なエクササイズ数:

自重（Body Weight）が 325 件と、全体の約 25% を占めます。器具を持たないユーザーやホームワークアウト系アプリでも、単体で成立するボリュームがあると言えます。一方で Cardio が 29 件、Neck が 2 件と少なめのため、有酸素系・首まわりに強みが必要なアプリでは追加のデータソースを検討する必要があります。

10 言語対応の範囲と限界

10 言語の内訳は以下です（README）。

英語、スペイン語、イタリア語、トルコ語、ロシア語、中国語、ヒンディー語、ポーランド語、韓国語、フランス語。

主要な多言語アプリを構築する用途では十分な広がりですが、日本語は含まれていません。日本語対応が必須の場合、instructions.<lang> / instruction_steps.<lang> を翻訳して追加する必要があります。この翻訳作業自体は、後述するライセンス構造上、MIT で許容される範囲（データ構造・翻訳文）に含まれるため、独自翻訳の派生を作ることは可能です。

付属ツール：index.html と setup.html の役割

exercises-dataset は「データセットだけ」ではなく、導入までの支援ツールを同梱しています。この 2 つの HTML ファイルが、GitHub 上の language 判定を「HTML」にしている実質的な要因でもあります。

対話型ブラウザ index.html

index.html は、サーバー不要のクライアントサイド完結型ブラウザです。README によれば以下が可能です。

• 1,324 件のライブ検索
• カテゴリ / 器具 / 対象筋によるフィルタ
• 無限スクロールのグリッド表示
• 10 言語の説明の切替表示

インポート先や外部依存を持たず、リポジトリを clone してブラウザで開くだけで挙動を確認できる構成のため、データ選定の判断材料を集めやすい設計です。

開発者向けセットアップウィザード setup.html

setup.html は、README の Usage Examples セクション（リポジトリトップ の該当箇所）で解説されている 3 つの機能を提供します。

1. DB Setup: SQL Server / PostgreSQL / MySQL / SQLite 向けの CREATE TABLE DDL と、1,324 件分の INSERT 文を含む .sql ファイルをブラウザ内で生成します。
2. API Integration: JavaScript / Python / C# / Java / PHP / Go / cURL のクライアントコード例を提供します。ベース URL を入力するとサンプルコードが更新される作りになっています。
3. Ask Your LLM: 使用したいバックエンドフレームワーク（Express.js / FastAPI / ASP.NET Core / Spring Boot / Laravel / Gin）と DB を選ぶと、ChatGPT / Claude / Gemini に貼り付けて REST API の実装を得るためのプロンプトが自動生成されます。

3 つ目の「LLM 用プロンプト生成」は、類似の OSS ではあまり見られない差別化要素です。DB 定義から API までの実装コストを LLM に肩代わりさせる前提の導線が用意されている、と読み替えると設計意図が理解しやすくなります。

対応 DB とフレームワーク

setup.html が対応する組合せの範囲は次のとおりです。

• RDBMS: SQL Server / PostgreSQL / MySQL / SQLite
• バックエンドフレームワーク: Express.js（Node.js） / FastAPI（Python） / ASP.NET Core（.NET） / Spring Boot（Java） / Laravel（PHP） / Gin（Go）

代表的なスタックはほぼカバーされているため、既存プロジェクトのバックエンド選定に大きく合わせられます。逆に、NoSQL（MongoDB / DynamoDB 等）を第一選択にする場合は、生成される DDL/INSERT はそのままでは使えず、JSON を直接読み込む導入パターン（後述）を選ぶことになります。

ライセンス構造：MIT + Gym visual 媒体条件の二層を理解する

exercises-dataset の GitHub リポジトリページでは、ライセンスが NOASSERTION と表示されます。これは「ライセンスがない」わけではなく、コード/データと媒体（画像・GIF）で異なる条件が併記されており、SPDX が単一の識別子を割り当てられないためです。実体は MIT ライセンス + Gym visual の媒体別条件、という二層構造になっています。フィットネスアプリを商用配信する場合、このライセンス構造は採否判断の最重要ポイントの一つです。

コード・データ・翻訳文の MIT ライセンス

LICENSE の前半では、次の範囲が MIT ライセンス（Copyright 2026 Hasan Emir Yıldırım）で提供されています。

• コード（index.html / setup.html などのツール類）
• データセット構造（exercises.schema.json などのスキーマ）
• 説明文本体および 10 言語の翻訳文（instructions.* / instruction_steps.*）

MIT のため、著作権表示とライセンス条項の保持を条件に、商用利用・改変・再配布が可能です。

画像・GIF の Gym visual 媒体条件

同じ LICENSE の後半および NOTICE.md で示されているとおり、images/ と videos/ 配下の 180×180 サムネイル・GIF は独立した扱いです。

• 画像・GIF は © Gym visual の所有物
• Gym visual の書面許諾に基づき、180×180 解像度でのみ 再配布
• 属性表示（© Gym visual — https://gymvisual.com/）の保持が必須
• 各レコードに attribution フィールドで属性が含まれている
• 再利用は Gym visual の Terms & Conditions に従う
• リポジトリをクローンしても媒体の利用ライセンスは付与されない。独自プロジェクトで媒体を使いたい場合は Gym visual から個別ライセンスを取得する必要がある

つまり、リポジトリを取得しただけで自社アプリの画面に GIF/画像を配信することは想定されていない、と読むのが安全です。README の「Drop it straight into your backend」は、コード・データ・翻訳文レベルの取り込みを主に指していると解釈するのが実務的です。

商用アプリ組込時に確認すべきチェックリスト

商用配信を前提にする場合、少なくとも次を確認しておくと後戻りが減ります。

• 使うのはデータとスキーマだけか、画像・GIF までか
• 画像・GIF を使う場合、Gym visual と個別ライセンス契約を締結できるか（Terms & Conditions の該当条項を確認）
• attribution フィールドを UI 上に表示するフローが確保できるか
• 独自の 180×180 を超える解像度で配信したい場合、Gym visual と個別解像度の契約が可能か
• 派生翻訳（例: 日本語）を追加する場合、instructions.* の追加はライセンス上問題ないか（MIT 範囲内であることの確認）

法務的な最終判断は自社の法務担当・弁護士による確認を推奨しますが、上のチェックリストで論点を先出ししておくと、事前見積りの精度が上がります。

類似リポジトリとの比較：free-exercise-db・wger・ExerciseDB API との違い

フィットネス系エクササイズ OSS には、大きく分けて「データセット系」「自ホストアプリ系」「API サーバー系」の 3 系統があります。exercises-dataset を採用するかどうかは、これら他系統との違いを踏まえて判断するのが実務的です。ここでは、系統別に代表的な OSS と比較します。

データセット系: yuhonas/free-exercise-db との比較

yuhonas/free-exercise-db は、Open Public Domain として公開されている JSON 形式のエクササイズデータセットです。

• エクササイズ数: 800+
• ライセンス: Unlicense（パブリックドメイン相当）
• 対応言語: 英語のみ
• メディア: JPG 画像のみ（GIF なし）
• 付属フロント: Vue.js の検索フロントエンドあり
• データフィールド: id / name / force / level / mechanic / equipment / primaryMuscles / secondaryMuscles / instructions / category / images 等（一部フィールドは null 許容）

対 exercises-dataset の差分:

• ライセンスは最も自由（Unlicense）。商用配信・改変・再配布の障壁が実質ゼロ
• 多言語なし・GIF なし。英語圏 or 単言語アプリで、画像で十分な場合に向く
• フィールドが一部 null 許容であり、データ整合性は exercises-dataset より緩い

自ホストアプリ系: wger との比較

wger-project/wger は、Django ベースの自ホスト型フィットネス/ワークアウト/栄養/体重管理アプリです。

• 提供形態: アプリケーション（Web UI + REST API）
• ライセンス: AGPL-3.0
• エクササイズ数: 500+（アプリ内蔵）
• 特徴: 栄養・体重管理まで含む多機能・自ホスト前提

対 exercises-dataset の差分:

• アプリを丸ごと自ホストする方向性。「データレイヤーとして組み込む」用途には過剰
• AGPL-3.0 のため、Web サービスとして提供する場合はネットワーク越しの利用者にもソースコード開示義務が発生する。商用クローズドソースへの組込みは注意が必要
• 完成品を運用したい・自社で運動データを整備・保守したくない場合には強力

API サーバー系: ExerciseDB API との比較

exercisedb/exercisedb-api は、11,000+ 件のエクササイズを提供する API サーバーです。

• 提供形態: API サーバー（RapidAPI 経由 or 自ホスト）
• ライセンス: AGPL-3.0
• メディア: 20,000+ 画像 / 15,000+ 動画 / 5,000+ GIF

対 exercises-dataset の差分:

• 件数は最大級。運動バリエーションの網羅性を最優先する場合には有力
• AGPL-3.0 のため、自ホストして商用配信する際は wger と同じ検討が必要
• API 経由の利用が前提のため、ネットワーク依存と運用コストが発生する

4 リポジトリ一括比較

以上を項目別にまとめると次のようになります。

exercises-dataset が向くケース・向かないケース

上の比較を踏まえると、exercises-dataset は次のようなケースに向きます。

• 多言語対応が必要なアプリで、翻訳の初期セットを短時間で整えたい
• 部位別・器具別に構造化された 1,300 件規模のデータが欲しく、フィールドの整合性を重視する
• DB 定義・API 実装のたたき台をセットアップウィザードで作りたい
• 画像・GIF は Gym visual と個別契約する前提で商用配信できる
• クローズドソースの商用アプリに組み込みたい（MIT で許容される範囲）

一方、次のようなケースでは他の選択肢を検討する価値があります。

• ライセンスの自由度を最優先し、媒体まで含めて完全に自由に使いたい → free-exercise-db
• ワークアウト管理アプリを自作せず、完成品を自ホストして運用したい → wger
• 件数の網羅性を最優先し、AGPL-3.0 も許容できる → ExerciseDB API
• 日本語がプロダクトの主要言語で、そのまま流用したい → 日本語は含まれないため、翻訳工程を別途計画する必要がある

導入のはじめ方（ドキュメントベースの整理）

README の Usage Examples セクション（リポジトリトップ 参照）で示されている導入パターンは、大きく分けて 3 通りです。ここではドキュメントに基づく導入パターンの整理までを扱います。本記事では実行や環境構築の検証は行いません。

パターンA: JSON を直接読み込む

data/exercises.json をそのままアプリケーションで読み込むパターンです。README では Python / JavaScript / TypeScript でのシンプルなサンプルが提示されています。実際のコード例は README の該当セクションを参照してください。

このパターンが向くのは、以下のような場合です。

• 既存スタックが JSON 直読みで完結する（NoSQL DB や静的サイト、SSR フロントエンドでの直接消費）
• 件数が 1,324 件と限定されているため、全件メモリ展開で問題ない
• DB スキーマ設計を自社側で最適化したい

パターンB: setup.html で DB スキーマ + INSERT 文を生成する

setup.html の DB Setup 機能で、SQL Server / PostgreSQL / MySQL / SQLite いずれか向けの DDL + 1,324 件の INSERT 文をブラウザ内で生成し、対象 DB に流し込むパターンです。

このパターンが向くのは、以下のような場合です。

• RDBMS を既に採用しており、外部ライブラリを増やさずに済ませたい
• 部位・器具・対象筋での複雑なフィルタリングを SQL 側で書きたい
• サーバー側で JOIN や集計を伴う分析を将来的に行う想定がある

パターンC: setup.html の LLM プロンプトで REST API を生成する

setup.html の Ask Your LLM 機能で、選択した DB とバックエンドフレームワーク（Express.js / FastAPI / ASP.NET Core / Spring Boot / Laravel / Gin）向けの REST API 実装用プロンプトを生成し、ChatGPT / Claude / Gemini などに貼り付けて実装コードを得るパターンです。

このパターンが向くのは、以下のような場合です。

• REST API 層を自作したいが、初期実装のたたき台コストを圧縮したい
• 生成コードを起点にレビュー・改修する開発体制がある
• 対応バックエンドフレームワークが自社スタックと一致する

選び方の判断軸

3 パターンのどれを選ぶかは、次の 3 点で整理すると迷いにくくなります。

1. 既存スタック依存: 既に RDBMS を使っているか、JSON 直読みで済むか、API 層を分離したいか
2. 多言語要件: 10 言語すべてを配信するのか、必要な言語だけスキーマから抽出するのか
3. メディア利用の有無: 画像・GIF を使うなら Gym visual との契約を先に完了させ、コードとメディアで別導線を組む前提で設計する

まとめ：どんな場面で exercises-dataset を採用するか

最後に、意思決定を進めるためのチェックリストを整理します。

採用チェックリスト

以下に多く該当するほど、exercises-dataset は良い候補になります。

• 部位・器具・対象筋で構造化された 1,000 件超のデータが欲しい
• 主要言語での多言語配信が必要（英語・スペイン語・中国語 など）
• 動画・GIF による動きの説明を提供したい
• 商用配信の場合、Gym visual と個別ライセンス契約を締結できる
• MIT ライセンス（コード・データ・翻訳文）で組み込めるスコープが自社要件に収まる
• 対応バックエンドフレームワーク（Express.js / FastAPI / ASP.NET Core / Spring Boot / Laravel / Gin）のいずれかを採用している
• 初期実装コストを LLM プロンプト生成で圧縮したい

採用しない方が良いケース

以下に該当する場合は、free-exercise-db・wger・ExerciseDB API などの他選択肢を優先して検討する方が適しています。

• 媒体（画像・GIF）まで含めて完全にライセンスフリーで使いたい（→ free-exercise-db）
• 自作せず完成品のフィットネスアプリを自ホスト運用したい（→ wger）
• 件数の網羅性を最優先し、AGPL-3.0 でも問題ない（→ ExerciseDB API）
• プロダクトの主要言語が日本語のみで、翻訳工程を追加する余裕がない
• 有酸素運動（Cardio 29 件）や首まわり（Neck 2 件）が主要ドメインで、種目数が要件を下回る

次のステップ

採用を検討する場合、まず以下の順に確認すると判断がスムーズです。

1. リポジトリトップ を開き、README の Statistics と Usage Examples を確認する
2. data/exercises.schema.json で JSON Schema を確認し、自社要件のフィールドとの過不足を洗い出す
3. LICENSE と NOTICE.md を読み、コード・データ・媒体それぞれの利用範囲を確認する
4. 媒体を使う場合は Gym visual の Terms & Conditions を確認し、必要に応じて個別ライセンスの取得可否を打診する
5. 姉妹プロジェクトの LogPress を参照し、実プロダクトでの利用例を確認する

これらの確認を経てから、パターン A/B/C いずれの導入方針を採るかを決めると、後戻りが最小限で済みます。

関連情報

フィットネスアプリの開発や、運動データ層の設計・実装を外部に相談したい場合は、お問い合わせフォーム からご相談ください。要件整理・技術選定の段階からお手伝いできます。