Manus、薬剤師がAIエージェントでフィットネストラッカーを構築した事例を公開

Manus は 2026年6月4日、薬剤師兼ボディビル栄養コーチが Manus を使ってフィットネストラッカー「Alyak Coach」を構築した事例を公式ブログで公開しました。手作業のスプレッドシート運用から、スマートフォンで使えるアプリへ移行した顧客事例です。

要点

• 韓国の薬剤師兼栄養コーチが、コーディング経験なしで Manus を使い Alyak Coach を構築した事例
• クライアントの食事、体重、運動履歴、歩数、カロリーをアプリ上で管理
• TDEE を毎週再計算し、実際の体重変化や摂取データに合わせて調整する機能が中心
• Strava や HealthSecret と同期し、手入力やメッセージ対応の負担を減らした
• 非エンジニアがAIエージェントで業務アプリを作る場合、要件の具体化、データ品質、保守体制が重要になる

今回のブログ記事で語られていること

公式ブログは、薬剤師として働きながらボディビル向けの栄養コーチングを行っていた Yim Yoon-seok 氏の事例を紹介しています。以前は、クライアントごとにスプレッドシートを開き、体重、体脂肪、食事、写真、体重計のスクリーンショットを手作業で整理し、KakaoTalk で個別にやり取りしていました。クライアント数が増えるほど、コーチングそのものよりもデータ入力と計算に時間を取られる状況だったと説明されています。

そこで同氏は Manus を使い、クライアントがスマートフォンから食事や体重を入力し、カロリー、体重推移、運動履歴を確認できる Alyak Coach を作りました。記事では、Strava や HealthSecret との同期により、歩数、運動、カロリーログが自動で流れ込む構成が紹介されています。中心機能は、AIを使った TDEE の再計算です。一般的なTDEE計算は一度決めた推定値に依存しがちですが、Alyak Coach は実際の体重変化と摂取データに基づき、毎週目標を調整する仕組みとして説明されています。

Manus の事例として重要なのは、同氏がエンジニアではなく、最初はフレームワーク、API、データベース接続の知識もなかった点です。ブログでは、対話型AIでアイデアを整理し、Manus に実装とデプロイを進めさせ、バグが起きたらより具体的な文脈を与えて修正していくワークフローが語られています。AIエージェントは、単にコード片を返す存在ではなく、要求を実装に落とし込み、動くアプリへ近づける役割として描かれています。

一方で、この事例は「誰でも本番アプリを簡単に作れる」とだけ読むと危険です。健康、栄養、運動データは個人性が高く、計算結果が利用者の行動に影響します。ユーザー数が増えれば、認証、データ保護、バックアップ、課金、サポート、誤入力時の修正、計算ロジックの説明責任が必要になります。AIエージェントで初期構築が速くなっても、業務アプリとして継続運用するには、人間側の検証と責任分界が欠かせません。

今回のブログ記事が関係する人

• manus をすでに利用しており、今回の内容が運用、開発、分析、データ連携にどう影響するかを確認したいチーム
• AI・データ基盤の選定や導入計画を進めており、公式ブログの背景や実務上の読み方を整理したい担当者
• セキュリティ、ガバナンス、監査、コスト、サポート体制など、発表内容を本番運用の判断材料に落とし込みたい管理者

実務で確認したいポイント

非エンジニア部門がAIエージェントで業務アプリを作る場合、まず扱うデータの種類を確認する必要があります。個人情報、健康情報、決済情報、顧客とのメッセージ履歴を扱うなら、早い段階で権限設計とデータ保護を見直すべきです。

また、要件を自然文で伝える力が成果に直結します。記事の事例でも、問題が起きたときに「何が壊れているか」だけでなく、「その機能が何をすべきか」「どのデータがどこから来るか」を具体的に伝えることで改善できたとされています。AIエージェントを使うチームには、プロンプトの上手さだけでなく、業務プロセスを言語化する力が必要になります。

結局、今回のブログ記事をどう読むべきか

Alyak Coach の事例は、Manus が非エンジニアの業務アプリ構築に入り込んでいることを示す顧客ストーリーです。導入検討では、開発速度の速さに加えて、データ管理、保守、責任分界、業務知識の言語化をセットで評価したいところです。