1. ～軽い気持ちでダイエット指導AIを作り始めたら、商用運用のフルスタックシステムになっていた～
この記事は「UKA-GYRE 開発記」シリーズの 第1回（共通プロローグ）です。
読み物編・技術深掘り編、どちらにも進める入口になっています。
2. 「2週間で作れる」と思ったのが、全ての始まりだった
知り合いのパーソナルトレーナーの仕事を横で見ていたとき、あることに気づいた。
コメント業務が、異常に大変だ。とんでもない時間がかかっている。
トレーナーは毎日、クライアントの食事記録を確認して、一人ひとりにコメントを返す。
食事データを確認して4-6分。
体重や栄養素の傾向を分析して4-6分。
その人の状況に合ったコメントを考えて書いて5-7分。
1人あたり15分。数十人を抱えていたら、毎日数時間がコメントだけで消える。
しかも厄介なのが、同じ内容でも 伝え方次第でクライアントの反応が全く変わる ということだ。
たとえば、タンパク質が目標に届いていないクライアントがいたとする。
「本日のタンパク質は目標の72%です。鶏むね肉やプロテインで補いましょう」――
データ重視の人にはこれが刺さる。具体的な数字と改善策がセットで提示されていて、すぐ行動に移せる。
だが同じコメントを読んで「また指摘か」と感じる人もいる。
「タンパク質、もう一品足すだけで目標に届きますよ。昨日より確実に良くなっています」――
こちらの方が響く人には、前者は冷たく聞こえる。
内容はほぼ同じなのに、届く人と届かない人がいる。
正しさだけではコメントは機能しない。
誰に、どう届けるか まで考えてコメントしないと意味がない。
これを聞いたとき、頭の中で何かがつながった。
「Amazon Bedrock使ってコメント生成できるのでは、、、？」と。
正直に言うと、最初は「2週間くらいで作れるだろう」と思っていた。
結果、 3ヶ月以上 かかった。
3. ChatGPTに聞けばいいじゃん
「それ、ChatGPTに食事データを貼り付けて『コメント書いて』って言えば済むのでは？」
こう思った方は鋭い。実際、最初は自分もそう思った。試してみた。
ChatGPTに「体重72kg、今日の摂取カロリー2,100kcal、タンパク質65g。
ダイエット中のクライアントにコメントを書いて」と投げる。
返ってきたのは、こんなコメントだった。
「本日の摂取カロリーは2,100kcalですね。タンパク質の摂取量がやや不足しているようです。バランスの良い食事を心がけ、タンパク質を意識的に摂取しましょう。」
悪くない。間違ってもいない。
しかし、 誰に対しても同じことを言っている。
計画通りに進めたい人には数字で語った方が響く。
感情で動く人には「頑張ってますね」の一言が先に必要だ。
行動派の人には「プロテインを1杯足せばOK」と端的に言った方が動く。
人によって「響く言葉」は全く違う。
しかしChatGPTは、誰に聞いても同じ教科書みたいな答えを返す。
もう一つ、決定的に足りないものがあった。 「学習」しない ということだ。
トレーナーが「このコメントは良かった」と判断した結果を、次回に活かす仕組みがない。
毎回ゼロから考える。
先週うまくいった言い回しも、先月失敗したアプローチも、何も覚えていない。
100回使っても1回目と同じ品質。これでは「仕事の道具」にはならない。
パーソナルトレーナーの価値は、 その人のことを知っている ところにある。
性格、生活リズム、過去の成功と失敗、今の心理状態。
それを踏まえて「あなたに」向けた言葉を選ぶ。
汎用チャットボットには、この「あなたのことを知っている」が原理的にできない。
必要だったのは、こういうAIだった。
-
相手の性格に合わせて「伝え方」を変える。
同じ内容でも、数字で納得する人と、共感の言葉で動く人がいる。
届け方まで設計できるAI。 -
今日の数字だけでなく、「文脈」を読む。
1日の結果だけ見ても意味がない。
数週間の流れの中で、今日が「つまずき」なのか「想定内」なのかを判断できるAI。 -
人間のフィードバックから学び続ける。
使えば使うほど、現場の判断基準を吸収して、出力の品質が上がっていくAI。 -
成功も失敗も記憶する。
うまくいったアプローチは再利用し、失敗したやり方は二度と繰り返さないAI。
これらを全て備えたシステム。それが UKA-GYRE（ウカ・ジャイア）だ。
個人開発として始めたものが、今はトレーナーが実際のクライアントに向けて日々使っている本番システムになっている。
この連載は、そのシステムがどうやって生まれ、何を乗り越え、どこに向かっているのかを語る物語だ。
4. システムの全体像
UKA-GYREには大きく 3つのメイン機能 と 管理機能、 週次バッチ がある。
メイン機能それぞれが「ログ」を生み出し、週次バッチで「知識」に変換され、次の生成で自動参照される仕組みだ。
順に見ていこう。
4.1. 機能1：コメント生成
メインの機能だ。トレーナーのクライアントに対しての食事コメントを、AIが生成する。
まず、コメントを作成する対象クライアントを選ぶ。
クライアントごとに方針・戦略・MBTIタイプなどのプロフィールが設定されていて、選択するだけでAIがそのクライアントに最適化された生成準備を行う。
次に、そのクライアントの食事記録が入ったExcelファイルをドラッグ＆ドロップでアップロードする。
アップロードされたデータに対して、トレーナーが「長期方針」「現在の戦略」「フェーズ」などのラベルを選択・確認する。
これらのラベルはRAG検索のフィルタとして使われる。
本当に状況が近い過去事例だけ を引き当てるための重要な仕掛けだ。
ここで、システムがExcelから読み取ったカロリー・PFC（タンパク質・脂質・炭水化物）・体重推移などの分析結果が表示される。
数値は 内部ラベルに自動変換 されていて、AIの判断が毎回ブレない一貫した分析基盤になっている。
生成ボタンを押すと、いよいよAIの出番だ。
過去の成功・失敗パターンをRAGで自動参照 しながら、 2つの異なるモデル が同時にコメントを生成する。
ChatGPTのように毎回ゼロから考えるのではない。
蓄積された知識に基づいた生成だ。
生成中
生成後
トレーナーはA案かB案を選び、内容を評価する。
- Good（そのまま使える）
- Normal（少し手直しした）
- Bad（大幅にダメだった）
の3段階。必要に応じて手直しもできる。
AIはあくまで下書き、最終責任はトレーナーが持つ。
Human-in-the-Loop ―― 人間がループの中に入って判断する設計だ。
最終コメントを送信して完了。
ここで大事なのは、トレーナーの選択結果・評価・編集内容が全て CaseLog（生成ログ） として記録されることだ。
「選んだ」「直した」という行為そのものが、次のAIの糧になる。
4.2. 機能2：Gold（お手本コメント）登録
トレーナーが「これは特に良いコメントだった」と判断したものを、 Goldコメント として登録できる機能だ。
Goldに登録されたコメントは、そのクライアントの状況・方針・戦略と紐づけて Amazon Bedrock Knowledge Bases（以下、ナレッジベース）に蓄積される。
次回以降、似た状況のクライアントのコメント生成時に、RAGが 「お手本」として自動参照 する。
つまり、トレーナーが「これだ」と認めた最高品質のコメントが、AIの出力の品質基準になっていく。
4.3. 機能3：Thought（トレーナーの知見メモ）登録
トレーナーが日々の指導で気づいたことを、テキストメモとして登録できる機能だ。
「停滞期のクライアントにはカロリーを削るより切り口を変えた方がいい――」
「初心者にはPFCバランスより記録の継続を優先すべき――」
こうした判断は、経験を積んだトレーナーだからこそ持っている感覚だ。
しかし、この 暗黙知 は通常であれば頭の中にだけ残って消えてしまう。
Thought機能はこれをテキスト化してナレッジベースに蓄積し、RAGでAIが自動参照できるようにする。
トレーナーの「勘」が、システムの「知識」になる。
4.4. 管理機能：裏側を覗く
3つのメイン機能に加えて、システムの「裏側」を確認・操作するための管理機能も備えている。
プロンプト・設定のリアルタイム編集。
プロンプトの文言やMBTIの定義、推論パラメータなどの設定をブラウザ上で即座に書き換えられる。
変更は再デプロイなしで反映される。
「この一文を変えたらどうなるか」を数分で試せる。
実験サイクルの速さが、プロンプトの品質を決める。
CaseLogの検索・確認。
生成されたコメントの履歴を、ベクトル検索の結果やスコアとともに確認できる。
「AIがどの知識を参照して、どんなスコアでヒットさせたか」まで追跡できる。検索精度のチューニングや品質改善の判断材料になる。
RAGナレッジベースの閲覧。
昇華バッチが生成したArtifact（成功パターン、失敗の教訓、お手本コメントなど）を一覧で確認できる。
どんな知識が蓄積されているか、どの知識が実際に検索でヒットしているかを把握する。ナレッジベースの健全性を管理するための機能だ。
4.5. 3つのログが「知識」に変わる ― 昇華バッチと退役バッチ
ここまでの3つの機能が生み出す CaseLog・GoldCaseLog・ThoughtLog。
これらはそのままでは「個別の記録」に過ぎない。
週次で実行される 昇華バッチ が、これらのログを 再利用可能な知識（Artifact）に自動変換 する。
評価の良し悪しに応じて、AIが異なる種類の知恵を自動生成するのだ。
成功パターン、失敗の教訓、お手本コメント、トレーナーの暗黙知。
AIが自動生成する 4種類のArtifact に加え、人間が管理する SSOT（基本ルール集） の計 5種類 がベクトルデータベースにインデックスされ、次回以降のコメント生成でRAGが自動参照する。
この「ログが知恵に変わる」仕組みの詳細は、読み物編第2回で語る。
一方、 退役バッチ が古くなった知識や使われない知識を自動的に引退させる。
増やす仕組みと減らす仕組みをペアで動かすことで、常に「今使える知識」だけが検索対象になる。
5. 技術スタック
全てAWSで構築した。 EC2ゼロ、VPCなし の完全サーバーレス構成だ。
| レイヤー | 技術 | 役割 |
|---|---|---|
| CDN / 配信 | CloudFront + S3 + Next.js | 静的エクスポートしたフロントエンドを配信 |
| API / 認証 | API Gateway HTTP API v2 + Cognito | JWT認証付きのAPIエントリーポイント |
| Compute | Lambda（TypeScript） | コメント生成・API処理・昇華バッチ・退役バッチの4関数 |
| DataStore | DynamoDB（8テーブル）+ S3（4バケット） | クライアントデータ・ログ・設定・監査アーカイブ |
| AI / KB | Amazon Bedrock（Claude）+ Knowledge Bases + Titan Embeddings v2 | コメント生成（A/B並列）+ RAG検索（1024次元） |
| 監視 / スケジュール | CloudWatch + EventBridge | ログ・アラーム監視 + 週次バッチのcron実行 |
| IaC | AWS CDK（TypeScript） | 8スタック構成、全リソースをコードで管理 |
表に登場する主なAWSサービスを補足しておく。
5.1. CDN / 配信 / 認証
- CloudFront ―― CDN（コンテンツ配信ネットワーク）。S3に置いた静的ファイルを世界中のエッジサーバーから高速配信する
- API Gateway ―― APIのエントリーポイント。
- Cognito ―― ユーザー認証サービス。JWTトークンでAPIを保護する
5.2. Compute / DataStore
- Lambda ―― サーバーを持たずにコードを実行できるサービス。リクエストが来たときだけ起動し、終わったら消える。常時稼働のサーバー費用がゼロ
- DynamoDB ―― NoSQLデータベース。クライアントデータ、CaseLog、GoldCaseLog、Artifact管理など8テーブルで使用。On-Demandモード（使った分だけ課金）で運用
- S3 ―― オブジェクトストレージ。ナレッジベースのファイル保管、フロントエンドの静的ファイル配信、監査ログのアーカイブなど用途は幅広い
5.3. AI / 監視 / IaC
- Amazon Bedrock ―― AWSのフルマネージド生成AIサービス。Claude等のLLM（大規模言語モデル）をAPI経由で呼び出せる。Knowledge Bases機能でRAG検索基盤も提供する
- Titan Embeddings v2 ―― Amazon独自のテキスト埋め込みモデル。テキストを数値ベクトルに変換し、意味的な類似度で検索できるようにする
- CloudWatch ―― ログ収集・メトリクス・アラームの統合監視基盤。異常検知と運用監視の中核
- EventBridge ―― スケジューラー。「毎週日曜3時に昇華バッチを起動」といったcron的なスケジュール実行を担う
- AWS CDK ―― Cloud Development Kit。インフラをTypeScriptのコードで定義し、デプロイできるツール
この構成で 月間運用費は推定$40〜150。全て従量課金で、使わなければほぼ課金されない。店舗展開していない個人パーソナルトレーナーでも導入しやすい構成だ。
AWSリソースの全体構成や各コンポーネントの設計判断は、技術深掘り編で詳しく解説している。
6. 開発を振り返って
6.1. 想定の3倍かかった話
最初は「Amazon Bedrockでテキスト生成して、DynamoDBに保存すれば終わり」と思っていた。
甘かった。
LLMは毎回違うことを言う。品質の「下限」を保証するのが、想像以上に難しい。
良いコメントとは何か。の定義が曖昧すぎて、評価基準の設計だけで何日も費やした。
CDKで8スタックを依存関係付きで管理する苦労。
そしてRAGの検索チューニング ―― これが最も時間を食った。
ベクトル検索は「意味が近い」は得意だが、「状況が同じ」かどうかは判断できない。
検索結果を1件ずつ確認して「なぜこれが上位なのか」を追いかける日々。
100%の精度はあり得ない。
しかし 妥協点を設計することはできる。
この泥臭い戦いの詳細は、技術深掘り編で語る。
6.2. なぜ「UKA-GYRE」なのか
GYRE（ジャイア）。
英語で「螺旋」「還流」を意味する。
このシステムには、終わりがない。
- トレーナーがコメントを選ぶ。
- その選択がログになる。
- ログが知識に変わる。
- 知識が次の生成を賢くする。
- 賢くなったAIが、より良いコメントを生む。
- より良いコメントが、より質の高い選択データを生む。
終わらない螺旋
この螺旋構造そのものが設計思想であり、汎用チャットボットとの決定的な違いだ。
そして UKA ―― このシステムを日々使ってくれているパーソナルトレーナーの名前だ。
開発者が一人で作った技術ではない。
トレーナーが毎日の業務で使い、フィードバックをくれたからこそ、螺旋は回り続けている。
その敬意を込めて、トレーナーの名前を冠した。
7. この連載について
この開発記は、 2つのシリーズ に分かれている。
7.1. 読み物編 ― 開発の物語、AIの不思議な挙動
エンジニアでなくても読める。難しい専門知識は出てこない。
| 回 | テーマ |
|---|---|
| 1 | ISTJには数字を、ENFPには共感を ― AIに「性格」を与えた日 |
| 2 | 深夜3時はAIの経験値稼ぎタイム ― 「昇華」のメカニズム |
| 3 | カロリーの数字の裏にある物語 ― AIが「今日のあなた」を理解するまで |
| 4 | 「何を書くか」より「どう伝えるか」 ― AIを使った大人の実験科学 |
| 5 | 「AIが書いた」ではなく「AIと一緒に書いた」 ― Human-in-the-Loopという思想（完結） |
| 番外 | 自分が作ったAIに食べ過ぎを怒られ続けた話 ― 開発者の裏側 |
7.2. 技術深掘り編 ― 実装の詳細、設計哲学
AWS、TypeScript、RAG、CDKの実践知を書く。
| 回 | テーマ |
|---|---|
| 1 | RAG設計とベクトル化戦略 ― AIに数値の解釈をさせてはいけない |
| 2 | ベクトル検索の品質最適化 ― 100%の検索精度は存在しない |
| 3 | 7層プロンプトエンジニアリング ― たった1行がAIの人格を決める |
| 4 | 自己改善ループとサーバーレス基盤 ― 「勝手に賢くなるAI」は存在しない |
| 5 | システムアーキテクチャ総覧（完結） |
読み物編だけで完結できる。
技術深掘り編だけでも読めるが、背景を知りたければ読み物編から読んでもらえると嬉しい。
読み物編 はAIに興味がある人、ダイエット中の人、非エンジニアの方向け。
技術深掘り編 はエンジニア、AWS学習中の方、RAGに興味のある方、ポートフォリオを作りたい方向けだ。
8. おわりに ― 螺旋の入口へ
「2週間で作れる」と軽い気持ちで始めたシステムに、3ヶ月以上かけた。
途中で何度も「ここまでやる必要あるのか」と思った。
でも、「トレーナーが毎日の仕事で本当に使えるもの」を妥協しなかった結果、汎用チャットボットでは実現できない仕組みにたどり着けた。
そして実際に、本番環境で日々使われている。
それが何より嬉しい。
次回からは、この螺旋の中身を覗いていこう。
次回の記事:
「UKA-GYRE」開発記 シリーズ目次
読み物編 --- エンジニアでなくても楽しめる！
- プロローグ ― UKA-GYRE 開発記（この記事）
- 読み物 第1回 ― ISTJには数字を、ENFPには共感を ― AIに「性格」を与えた日
- 読み物 第2回 ― 深夜3時はAIの経験値稼ぎタイム ― 「昇華」のメカニズム
- 読み物 第3回 ― カロリーの数字の裏にある物語 ― AIが「今日のあなた」を理解するまで
- 読み物 第4回 ― 「何を書くか」より「どう伝えるか」 ― AIを使った大人の実験科学
- 読み物 第5回 ― 「AIが書いた」ではなく「AIと一緒に書いた」 ― Human-in-the-Loopという思想（完結）
- 読み物 番外 ― 自分が作ったAIに食べ過ぎを怒られ続けた話 ― 開発者の裏側
技術深掘り編 --- 設計判断と実装の詳細