「Velocity English」は、Phase 2 で AI 連携の要件を形にし、自分にとって一度は「完成形」となった。
音声・テキスト入力をした日本語を英語化し、「Core + Meat」という論理構造を示し、発音も書きだす。保存機能によって学習記録を積み上げることもできる。「独り言を英語にできれば、もっと速く、もっと自由に話せるはずだ」という当初の仮説を証明するには、これで充分なはずだった。
しかし、ある時名作『FF9』の英語版を見て、機能の拡張の可能性に思い至った。
画面の中で軽妙に、そして泥臭く生きるジタンたちの言葉。それはかつてのFFシリーズで見られた「神話的で詩的な堅い英語」ではなく、血の通った、今すぐ誰かに叩きつけたくなるような「生きた英語」だった。「ああ、言語を学ぶということは、単に意味を変換することじゃない。その世界に飛び込むための『リズム』を掴むことなんだ」と直感した。
そして、多言語対応が当たり前のFFシリーズをみて、「英語だけで終わるのは、もったいない」
すぐに一つの野心へと変わった。英語、スペイン語、フランス語……。世界中の言語を、この『Velocity English』というメスで解剖し、その国ごとのリズムを「譜面」として可視化したい。
「前回のVelocity English開発記 Phase 2をベースに、Phase 3 として何を実装するか。プロダクトの再定義から始まる、新たな挑戦の記録を紹介していきます。」
【第1章:UX・設計思想】(案)
「入力前に選ぶ」という常識を疑う。
一般的な翻訳アプリや学習ツールは、まず「何語を話すか」を選ばせる。だが、思考はもっと自由であるべきだと思う。例えば 「今の独り言、スペイン語ならどう言うんだろう? いや、フランス語の響きの方が合うかも」
そんな風に、思考の結果を見てから色を変えるように言語を切り替えられたら、学習はもっと直感的になると思う。
興味は記憶を強固に定着させる最強のスパイスだ。
これを実現するのが、Phase 3 の目玉機能**「多言語トランスミュート・スイッチ」**だ。 日本語で入力し、一度解剖した結果(Core + Meat)を維持したまま、ボタン一つで世界中の言語へと「染め上げる」。この「思考を止ませないUX」を大事にしていきたい。
![個人開発アプリ「Velocity English」の多言語トランスミュート機能のUIモックアップ。日本語「こんにちは」を入力し、[EN] [ES] [FR] [DE]から[ES](スペイン語)を選択した状態を示す。出力結果として「Hola」と、その下の構造分解図(Core: Hello / Meat: none)、そしてカタカナ発音「オラ」が、スペイン語を象徴するオレンジと赤のパッションある色使いで表示されている。](https://ask-asuka-tech.tech/wp-content/uploads/2026/04/velocity-english-ai-multilingual-transmute-ui-1024x558.webp)
「言語のリズムを視覚化」が学習速度を上げる。
さらに、ただ文字を出すだけじゃない。言葉には独特のリズムがあり、それを視覚的に分かりやすくすべきだ。これを 「ビジュアル・リズム・ガイド」とでも名付けよう。強く読むべき単語は大きく、弱くサボるべき音は小さく表示する。 言語を「読む」のではなく、音楽の「譜面」のように視覚的に捉える。 情報の引き算をすることで、口を動かす速度(Velocity)を物理的に引き上げる設計だ。

【第2章:技術の選定考察——理想を形にするための「選定」】
「多言語トランスミュート」を実現するための裏側と、エンジニアとしての選択。
この直感的なUXを支えるバックエンドを設計するにあたり、いくつかの「泥臭い検討」を重ねた。
1. 言語判別の自動化か、手動スイッチか
最初は langdetect などのライブラリを使って「入力言語を自動判別する」仕組みを考えた。だが、あえて「ボタンによる手動切り替え」を主軸に据えた。
- メリット: ユーザーが「今はスペイン語の口になりたい」という意思を明確に持てる。
- デメリット: ボタンを押す手間が増える。
- 結論: 学習において「能動的な選択」は記憶へのフックになる。また、AIへのプロンプトを「今からこの言語を解析するぜ」と明示的に固定することで、出力の精度とリズムガイドの正確性を担保した。
2. 状態管理(State Management)のジレンマ
「ボタン一つで切り替える」には、直前の日本語テキストや解析結果をメモリ上に保持し続ける必要がある。
- 検討: 毎回APIを叩き直すか、それともキャッシュするか。
- リスク: 頻繁な再解析はAPIコストを増大させ、レスポンスの遅延(UXの低下)を招く。
- 解決策:
st.session_stateをフル活用し、一度生成した多言語データは「着せ替え用」として一時保存する設計にした。これにより「売る」ことを想定したコスト管理と、爆速のUXを両立させた。
3. スケーラビリティ vs 実装スピード 「新言語をどう追加するか」も大きな論点だった。
- 泥臭い検討: 言語ごとに個別の関数を作るのは簡単だが、メンテナンス性は最悪だ。
- 選定: 設定ファイルを分離し、
LANG_SETTINGSという抽象化レイヤーを設けた。 あえて最初から「世界中の言語」を視野に入れた汎用的なクラス設計に時間を割いたのは、これが単なる一発ネタのアプリではなく、長く育てていく「プロダクト」だからだ。

【その先にある「Phase 4」への布石】
今回の「Velocity English」の再定義は、単なる機能追加の記録じゃない。自分にとっての理想の学習環境を、AIという相棒と一緒にどこまで突き詰められるか、その現在地を記した地図のようなものだ。
Phase 3 でアプリとしての核を固めたその先の構想も既にある。
例えば厳選したフレーズを「外部脳」として同期させる Notion Connect。デバイスに触れることなく、独り言や配信の生きた言葉をハックし続ける 常時稼働リスニングモード。
まだまだ追加したい機能はあるのだが、自分でデバッグして使用感を確かめつつより質の高いUXを保つ良いアプリにしていきたい。しかし、それでもまだAIエンジニアとして不足しているだろう。
自分がアプリを作る理由は「自分が必要なものは誰かも必要としている」という思想だ。
「せっかく時間をかけるのだから、『それなり』や『自分が良ければそれでいい』では意識が低い」
アプリを『売る』という事まで視野に入れて責任を負わなければプロのエンジニアとは言えないだろう。
まずは Phase 3、多言語の海を渡り切るための「構造の解剖」から始めていこう。 言語のカタチが見えたとき、次はその「音」をどう手なずけるかが見えてくるはずだ。

