はじめに
社内向けのAIサービスを、最初はPython+Gradioで開発していました。
当初、新しい生成AIの仕組みやアーキテクチャを試したいとき、Webフロントエンドにそれほど時間を掛けたくないという考えがあったためフロントエンドにはGradioを採用しました。
Gradioの採用背景や、利便性については弊社メンバーが詳細記事を書いていますので、ぜひご覧ください。
Gradioは非常に便利で、最小限の手間でWebUIが作れ、初期開発を爆速で進められたので非常に助かっていました。
しかし、機能追加や画面追加が進むにつれて、徐々にGradio利用の限界が見え始めました。
例えば以下のような部分です。
- 細かなUI制御はライブラリの想定外となり、独自実装が増えていった
- 画面をまたいだ状態管理が複雑化したり、スケーリングがしづらかった
- 画面数や機能追加に伴い、動作が徐々に重くなっていった
そこで今回、フロントエンドをReactへ移行することにしました。
本記事では
- 移行前にやって良かったこと
- 実際の移行中どうだったか
- 地味だけど効果が高かった工夫
以上の3点について書いていきます。
なぜReactへ移行したのか
フロントエンド移行にあたり、Vue、Svelte、Angularを含む複数のフレームワークを比較検討しました。
移行するなら、長期的に運用することを考え
- 何か困ったときに情報がすぐ見つかる
- ライブラリが充実していて、やりたいことが大体できる
そういう「安定性」と「柔軟性」が必要だと判断しました。
エコシステムの成熟度、採用市場の広さで実績のあるReactを選択しました。
移行前にやったこと
Figmaで画面作成
Figmaとは
ブラウザ上で動作するデザインツールで、リアルタイムに共同編集しながら画面デザインやプロトタイプを作成できます。
実装に入る前、Figmaなどで画面イメージや画面遷移を先に整理しました。
- 画面イメージ作成
- 画面遷移整理
- 必要画面の洗い出し
- 共通UIの確認
この整理は大きな効果がありました。
実装前にチームでイメージ共有できたので
- 「この画面は本当に必要か」
- 「この操作導線は分かりづらくないか」
- 「これって共通化できるのでは？」
という話を事前に進められました。
結果的に、実装途中の大きな認識ズレを大幅に減らせたと思います。
共通コンポーネントの整理
共通化できそうなものを洗い出し、最初の段階で共通コンポーネント群を整理しました。
何も考えずに進めると各画面で似たようなコンポーネントが大量発生しそうだと感じました。
それを防ぐため、事前に共通化できる要素を整理することにしました。
具体的には、以下のような標準コンポーネントを定義しました
- Button（ボタン系）
- InputField / SelectField（フォーム入力）
- ConfirmModal / Alert（ダイアログ・通知）
- LoadingScreen / EmptyState（状態表示）
- Card（データ表示）
特に意識したのは
- UIを体系的に管理
- コンポーネント命名を統一
- 修正が必要な箇所を限定化
- 長期的な保守性の確保
という点でした。
コンポーネント一覧ページの作成
コンポーネントやカラー定義を一覧で確認できるページを作成しました。
- 使用可能コンポーネント一覧
- カラー一覧
- コンポーネントの状態別表示（通常・ホバー・無効など）
- props違いによる見た目の比較（サイズ・バリアントなど）
- UIの崩れや不整合の早期発見（余白・文字サイズ・配色）
- 共通コンポーネント再利用の判断材料
こうした内容を確認できるページを作成したことで
- フロント修正のハードルが下がる
- 「どの色を使うんだっけ？」が減る
- メンバーが理解しやすい
- UI崩れに気づきやすい
特に 「人に説明しなくても見れば分かる」状態 にできたのは大きかったです。
実際の移行中はどうだったか
移行中はフロントだけでなくバックエンドやクラウド構成も同時に修正・変更が行われていました。
- 事前の画面共有
- 共通コンポーネント化
- 一覧ページ作成
上記を行っていたおかげで、大きな問題にはなりませんでした。
もちろん細かい変更はありましたが、修正箇所をある程度限定できたのは特に効果を感じました。
やって良かったこと
今回の移行方法が一般的に良いやり方なのかは正直わかりません。
少なくとも今回のプロジェクトでは
- イメージ共有
- 共通コンポーネント整理
- 一覧ページ作成
この3つはかなり効果がありました。
特に、「一覧で確認できる状態にしておく」のは想像以上に効果がありました。
実装する側だけでなく、あとから修正・変更する人にとっても分かりやすい状態を作れたと思っています。
おわりに
Gradioは本当便利で、初期開発の際に非常にお世話になりました。
一方で、機能追加や長期運用を考えると、フロントの主軸をReactに移した判断は良かったと感じています。
今回の移行を通じて感じたのは、
「とりあえず実装する」のではなく「あとから変更しやすい基盤を先に作る」
ことの大切さです。
特にフレームワーク移行のようなプロジェクトでは、この準備期間が後々の工数削減に直結すると思います。
GradioからReact移行を考えている方の参考になれば嬉しいです。