はじめに

前回の記事では、娘向けの学習支援アプリに英語のフレーズ練習を追加した話を書きました。

今回は、後回しにしていた UI のリニューアル を進めました。

第4回では次に英会話レッスン評価を書くつもりでしたが、毎日使うアプリなので、先に見た目と手ざわりを整えることにしました。
そして、本日復活した Fable 5 を使いたかったので、利用枠を意識しながら使ってみます。

この記事の主題は、完成した UI そのものより、AI にどう分担させて作ったか です。

自分の利用環境では、Fable 5 を設計・方向づけ役、Opus 4.8 を実装役として使いました。

いかにもTailwind と AI って感じですが、まあ良しとします

UI を後回しにしていた

第1回でも「UI はこれから整えていく前提」と書いていました。動くことを優先して、見た目は暫定のまま運用に乗せていました。

暫定 UI には、こんな状態が残っていました。

Tailwind のデフォルト色をそのまま使ったパステルのカードが並ぶだけ
絵文字をそのまま画面に置いている
日本語フォントの指定がうまく効いておらず、実質システムフォント表示になっていた
ごほうびであるステッカー獲得の瞬間に、演出がほとんどない

特に最後が気になっていました。娘にとっての一番の山場は「なんのモンスターが出るか」の瞬間なのに、そこが静かなカード表示で終わっていました。

子どもが夢中になれるかどうかは、この山場の作り込みで大きく左右される と思っていたので、UI をちゃんとやることにしました。

なぜモデルを分けたのか

今回は、全部を同じモデルに任せるのではなく、作業の性質で2つに分けて考えました。

工程	中身	失敗したときの痛み	向いていそうなモデル
設計	仕様理解・デザインの方向づけ・実装指示書づくり	方向を間違えると全部やり直し	最上位（Fable 5）
実装	指示書どおりにコードを書く	局所的で、直しやすい	一段下（Opus 4.8）

考え方はシンプルです。

方向を決める工程は、間違えると後工程が丸ごと無駄になります。ここは多少コストをかけても賢いモデルに投資する価値が高いと思いました。

一方で、方向が固まったあとの実装は、量が出る作業です。ファイルをいくつも書き換えるのでトークンをたくさん使います。ここは単価を抑えたいところです。

「どのモデルを使うか」ではなく「どの工程に、どのモデルを当てるか」で考える、という整理です。

Fable 5 に「指示書」を作らせた

まず Fable 5 に、既存のコードと仕様書を読ませたうえで、UI リデザインの指示書を1枚のドキュメントとして書かせました。

ポイントは、頭の中や会話の流れではなく、ファイルとして残る指示書にした ことです。これがそのまま、実装役のモデルへの受け渡し資料になります。

指示書に入れた主な項目はこんな感じです。

- 変更してはいけない範囲（API・型・保存処理・状態遷移）
- デザイントークン（色・フォント・角丸・影の具体値）
- 共通UI部品の仕様（ボタン、カード、評価スタンプ など）
- 画面ごとの指示（簡単なレイアウト図つき）
- ごほうびのステッカー開封演出の流れ
- 子ども向けテキストの言い換え表
- 実装フェーズと、各フェーズの受け入れ基準

特に効いたのが、最初に 「変更してはいけない範囲」 を明示させたことです。評価や画像生成の処理、データ保存まわりは今回さわってほしくなかったので、そこを先に線引きしておきました。

実際の指示書では、こんな粒度で「触ってはいけないもの」を並べています（抜粋）。

### 変更してはいけないもの
- app/api/** の全ルート、リクエスト/レスポンス契約
- lib/**（storage / sticker / pokemon / ai / supabase）
- types/** の型定義
- supabase/migrations/**
- 各画面のステートマシンと API 呼び出しロジック
  （演出用の状態を足すのは可、既存の遷移を変えるのは不可）

ここまで具体的に書いておくと、実装役が「よかれと思って」評価ロジックやデータ構造に手を入れてしまう事故を防げます。逆に、変更してよい範囲（components/ への UI 部品追加、globals.css、表示テキストなど）も同じ粒度で書いておきました。

副産物として、設計の段階で 日本語フォントの指定が実質効いていないバグ を見つけてくれました。暫定 UI のときから気づいていなかった不具合です。手を動かす前に既存コードを読ませたことで拾えたと思っています。

指示書の中では、色などを具体的な値まで書かせています（抜粋・イメージ）。

背景        クリーム系のやさしい色
本文の文字  真っ黒ではなく、少し柔らかい濃色
科目カラー  ひらがな / えいご / ピアノ で色を分ける
ボタン      押すと沈む立体感を持たせる

ここまで決めておくと、実装役が色やスタイルで迷わなくなります。

Opus 4.8 に実装させた

方向が固まったので、指示書を渡して Opus 4.8 に実装させました（Sonnet 5 でも良かったかも）。

指示書にフェーズ分けを書いておいたので、その順番どおりに進めてもらいました。

フェーズ1  土台（フォント修正・デザイントークン・共通部品）
フェーズ2  全画面へ適用（ホーム・各学習ページ・一覧・詳細）
フェーズ3  ごほうびの開封演出などの仕上げ

制約と方向が明確だったので、実装役は「ここはどうする？」と迷う場面が少なく、淡々と進められました。最後は、npm run lint と npm run build が通ること、開発サーバーを立てて 375px 幅（スマホ想定）で全画面が崩れないことまで確認させています。

暫定だった画面が、こう変わりました。

一番こだわったステッカー獲得の演出は、プレゼントが揺れて、光って、カードが跳ねて出てくる、という流れにしました。評価が高いほど派手になります。

なお、ステッカー画像はキャラクター要素を含むため、掲載しているキャプチャでは該当部分にモザイクをかけています。第1回で書いたとおり、生成画像はあくまで家庭内だけで使う前提です。

やってみて思ったこと

役割分担の効果は、体感としては良かったです。方向性の質は上位モデルで担保しつつ、量の出る実装は単価の低いモデルに回せました。

ただし、正直に書いておくと、今回はトークン消費を実測して比較したわけではありません。「上位モデルは単価が高く消費が速い」という一般的な傾向をもとにした、方針レベルの判断です。ここは今後ちゃんと測りたいところです。

そのうえで、指示書をファイルにしておく利点は、いくつか実感しました。

後から見返せる
実装役のモデルが変わっても、そのまま引き継げる
途中で「ここは方向が違う」と気づいたとき、指示書を直してから作り直せる

一方で、注意も要ると思いました。

これは「上位モデルはいらない」という話ではありません。設計を軽視して実装だけ下位モデルに丸投げすると、方向がぶれて、結局やり直しになりがちだと思っています。どこを設計とみなして上位モデルに任せ、どこからを実装として切り出すか、その線引きのほうが肝でした。

※毎回この分け方がベストとは限らないと見ています。引き続き検証です。

まとめ

今回は、後回しにしていた UI のリニューアルを、設計は Fable 5、実装は Opus 4.8、という分担で進めました。

学びを一般化すると、AI コーディングでは 「どのモデルを使うか」だけでなく「どの工程に、どのモデルを当てるか」で効率が変わる ということだと思っています。

Fable 5 をどこに当てるといちばん効くのか、という検証は他のプロジェクトでも続けている最中です。今回の UI 改修は、そのなかで「設計・方向づけに使うと効きがいい」と感じた一例でした。ここは引き続き試していきたいところです。というか、Fable 5 に出力させると利用枠一瞬で溶けます😢

次回は、この演出が実機で娘にどう響いたか、あるいは後回しにしている英会話レッスン評価の実装あたりを書ければと思っています。

関連記事