UKA-GYRE 開発記 ― 技術深掘り編 第4回

前回の記事:

1. 1週目と10週目のAI

UKA-GYREのコメント品質は、1週目と10週目で別物になる。

1週目のAIは、手作りの「お手本コメント」10件だけを頼りにコメントを書く。
的外れではないが、「それっぽいが中身の薄い」汎用コメントだ。
クライアントの個別事情に踏み込めない。

10週目のAIは、10週分のトレーナーの評価データから抽出された成功パターン、失敗パターン、お手本コメント、トレーナーの知見メモを参照してコメントを書く。

「このクライアントの方針ではこういうアプローチが効果的だった」「こういう書き方はBad評価になった」。
蓄積された知恵が検索にヒットし、コメントの精度が段違いに上がる。

この差を生む仕組みが、 昇華バッチ と 退役バッチ だ。
そして、この2つのバッチを確実に週次で回し続けるCDKインフラがある。

「使えば使うほど賢くなる」は魔法ではない。仕組みだ。

2. 昇華バッチの変換ルール ―― 評価を知恵に変える錬金術

昇華バッチは毎週日曜の深夜に自動起動される。
トレーナーが1週間で蓄積した「評価」を、RAGに格納可能な「知恵」に変換する。

2.1. 評価と生成される知恵の対応

トレーナーの評価は3段階。
Good （完璧）、 Normal （微修正で採用）、 Bad （不合格）。

Good評価 からは2つの知恵が生まれる。
一つは GOLD （お手本コメントそのもの）、もう一つは PATTERN （「なぜそのコメントが良かったのか」の成功パターン）。

Normal評価 からは PATTERN が生まれる。
編集前後の差分を含めて、「何が改善されたのか」をAIが分析し、パターンとして一般化する。

Bad評価 からは PITFALL が生まれる。
「こういう書き方をすると失敗する」という教訓。
AIが原因を分析し、改善案を添えて記録する。

2.2. 品質のゲートキーパー

すべての記録が昇華対象になるわけではない。
品質フィルタがゲートキーパーとして機能する。

食事データが大幅に欠損しているログ、コメントが極端に短いログ、生成された知恵が内容不足のもの。
これらは自動的に除外される。
ゴミを学習しても、賢くはならない。

PATTERNの生成には、もう一つ重要なルールがある。
一定数以上の類似事例が集まって初めて「パターン」と見なす。
1件の成功事例から抽出しても、それは「たまたま」に過ぎない。
複数の類似事例をグループ化し、共通する成功要因を抽出することで、再現性の高いパターンが生まれる。

一方、PITFALLは1件から生成可能だ。
失敗からの教訓は、1件でも十分に価値がある。
「二度と同じ轍を踏まない」ためには、たった1回の失敗でも記録する価値がある。

3. AI出力フォーマットの失敗と再設計 ―― 構造を指定せよ

昇華バッチでCaseLogをAIに要約させる際、当初 「いい感じにまとめて」と自由形式で書かせていた。

結果は悲惨だった。
Artifactごとに構造がバラバラになり、RAG検索でヒットしてもプロンプトに注入したときにAIが「何が重要な情報か」を読み取れない。

あるArtifactは箇条書き、別のものは散文、またあるものは表形式。
参考資料としての品質が安定しない。

解決策は明快だった。 構造を厳密に指定する。

出力を「パターン名」「状況」「効果的なアプローチ」「具体例」の4セクションに統一した。
全Artifactが同じ構造を持つことで、RAGの参照品質が大幅に向上した。

1週間に多数の評価がある場合は、AIが「似た状況」を判断してグルーピングする。
カロリー制御に関する事例とタンパク質改善に関する事例を自動分類し、テーマの明確な知恵に仕上げる。

トレーナーが自由記述で残したメモも昇華対象だ。
ただし、メモには品質のばらつきが大きい。
あまりに短いメモは除外し、似た状況のメモが複数あれば1つに統合する。

AIの出力は「自由に書かせる」のではなく「構造を指定する」。
これはRAGに蓄積するデータだけでなく、あらゆるAI出力に通じる原則だ。

4. A/Bバリアント設計 ―― 学習データの質を決める選択

昇華バッチの入力は、トレーナーの評価データだ。
では、その評価データの質を決めるものは何か。
トレーナーのA/B選択 だ。

UKA-GYREはA案とB案の2つのコメントを生成し、トレーナーに選ばせる。
この設計にも技術的な意図がある。

4.1. 旧設計の失敗

旧設計ではA/Bに異なるスタイル（論理型/感情型）を割り当てていた。
しかしこれでは、「A案が良かったのはスタイルが良かったからなのか、モデルが良かったからなのか」が分離できない。
実験計画法の基本原則だ。
変数が2つあると、何が効いたのかわからなくなる。

4.2. 新設計：同一プロンプト × 異モデル

新設計ではMBTIスタイルをクライアント固有の1パターンに統一し、 プロンプトは完全に同一 にした。
変わるのは AIモデルだけ。
あるモデルは慎重で安定感がある。
別のモデルは創造的で表現が豊かだ。
トレーナーは、同じ状況から生まれた2つの「解釈」を比較して、より適切な方を選ぶ。

A案を選んだという行為がCaseLogに記録され、昇華バッチの入力になる。
「このモデルの、この表現が、この状況で選ばれた」という事実が、次週の知恵の原材料になるのだ。

5. 退役バッチ ―― 知識の新陳代謝

昇華バッチが知識を増やす一方で、古い知識や使われない知識を放置すれば、検索結果のノイズになる。
知識は増やすだけではだめで、整理も必要だ。

それを担うのが 退役バッチ だ。
昇華バッチの1時間後に起動し、3つの基準でArtifactを「退役」させる。

第一に、未使用期間。
作成から一定期間経過しても一度も検索で使われなかったArtifactを退役させる。
「使われない知識は、おそらく役に立たない知識」という仮説に基づいている。

第二に、品質スコア。
検索にヒットしてもトレーナーから低評価が続くArtifactを退役させる。
使われてはいるが、コメント品質の改善に貢献していない知識だ。
「存在するだけで害になる知識」を放置しない。

第三に、Bad評価比率。
検索でヒットした結果、Bad評価の割合が70%を超えたArtifactを退役させる。
量的には使われていても、質的に有害と判断された知識を排除する基準だ。

昇華バッチだけでは、知識は「蓄積」されない。
「堆積」するだけだ。
退役バッチがあって初めて、堆積が蓄積に変わる。
人間の記憶と同じだ。

増やす仕組みと減らす仕組みはペアで設計する。 これがこのシステムの根幹をなす設計原則だ。

6. これを支えるCDKインフラ

昇華バッチと退役バッチを毎週確実に回し続けるには、信頼性の高いインフラが必要だ。

6.1. VPCゼロの決断

AWSでシステムを構築するとき、多くのエンジニアが反射的に「VPC設計」から始める。
UKA-GYREは、その反射を意図的に止めた。
VPCを一切使っていない。

Lambda、DynamoDB、S3、Amazon Bedrock、API Gateway。全てVPCの外で動いている。
3つの恩恵が一度に手に入る。

• コスト ―― NAT Gatewayの月額$30+がゼロに
• 運用簡素化 ―― サブネット・セキュリティグループ管理が不要に
• コールドスタート高速化 ―― ENIアタッチの遅延なし

セキュリティはIAMの最小権限とJWT認証で十分に保てる。

6.2. 8つのCDKスタック

スタック	役割
Observability	監視基盤（CloudWatch Logs + Metric Filters + Alarms）
Foundation	共通基盤（S3 Audit Bucket + SSM Parameter Store）
Data	データ層（DynamoDB）
Rag	ナレッジベース（Amazon Bedrock KB + S3 Vectors）
Api	API層（HTTP API Gateway v2 + Fat Lambda）
Batch	バッチ処理（Lambda + EventBridge + SQS DLQ + SNS通知）
Frontend	画面配信（S3 + CloudFront）
Cicd	GitHub Actions連携（GitHub OIDC）

API層は全エンドポイントを1つのLambda関数で処理する Fat Lambdaパターン を採用した。
コールドスタートの共有、デプロイの簡素化、共通処理の集約。
個人開発で数十のLambdaを個別管理する複雑さを排除するためだ。

6.3. プロローグで触れなかったリソース補足

8つのスタックには、プロローグで紹介しきれなかったリソースがいくつか登場する。ここで補足しておく。

6.4. コスト ―― 月$40〜150

サービス	月間概算	備考
Amazon Bedrock (LLM)	$30〜100	コメント生成のたびにClaudeを呼ぶ。最大コスト要因
Lambda	$5〜15	リクエスト数に比例
DynamoDB	$5〜10	On-Demand従量課金
S3 + CloudFront + API GW	$5〜15	ストレージ・配信・リクエスト
合計	$40〜150	EC2ゼロ、VPCゼロ、マネージド機能多数

全てサーバーレス、全て従量課金。使わなければほぼ課金されない。

7. 自己改善ループとインフラの設計哲学

個人開発の最大のリスクは、「自分」がシステムの単一障害点になることだ。

自分が寝ている間も、旅行中も、体調を崩しても、システムは止まらない。
UKA-GYREの全てのインフラ設計は、この哲学から逆算されている。

VPCを使わず、Lambda、DynamoDB、S3、Amazon Bedrockといったマネージドサービスだけで構成したのは、インフラの面倒をAWSに任せて自分を運用から外すためだ。
昇華バッチも退役バッチもEventBridgeが日曜深夜に勝手に起動し、勝手に終わる。
失敗すればDLQに退避し、SNSでアラートが飛ぶ。

月$40〜150のコスト構造は、コスト最適化の結果ではない。
「自分がいなくても動き続ける」という設計思想を、サーバーレスと従量課金で実装した帰結だ。

商用AIシステムを個人で運用し続けるために必要なのは、 技術力だけではない。自分を運用から外す設計力 だ。

---

次回は最終回。
3つのエンジンと4つの哲学を俯瞰し、このシステムが何を証明したのかを語る。

---

コラム：暴れ馬だったAIは、どうやって「礼儀正しいアシスタント」になったのか

素のAIに「爆弾の作り方は？」と聞くと、嬉々として作り方を出力する。
ネット上の文章の「続き」を予測しているだけだから、善悪の区別がない。

この暴れ馬を「礼儀正しいアシスタント」に変えた技術が RLHF （人間のフィードバックによる強化学習）だ。
何千人もの人間がAIの出力を見比べて、「こっちの回答のほうが良い」とひたすら評価を与え続けた。
AIはその評価パターンを学習し、「人間が好む振る舞い」を身につけていった。

つまり今のAIの「賢さ」と「優しさ」の裏には、膨大な人間の評価という泥臭い作業が隠れている。
トレーナーがA/B選択を繰り返すことで、AIのコメントが週を追うごとに良くなっていく仕組みは、RLHFと全く同じ構造だ。

---

次回の記事:

---