社内ダッシュボード向けのSvelte vs Vue 3：実践的な比較

社内ダッシュボードが厄介になる理由

社内ダッシュボードは一見シンプルに見えますが、実際に作ると難しいのは最初の画面ではなく10個目の画面です。パターンを一貫させ、変更を安全に保つ必要が出てくるからです。

典型的なダッシュボードは繰り返し使うパーツの集合体です：ソートとページングがあるデータ表、検索とフィルタ、多段階フォーム、バリデーション、そしてユーザーが欠けていると気づく細かいUX（トースト、読み込み状態、空状態）。さらに、ロールベースの権限、監査ログ、小さな管理アクション（これが誤って繋がると実害が出ます）も必要になります。

CRUD中心のアプリはマーケティングサイトとは挙動が異なります。多くのページが静的で読み取り専用というより、状態で満ちています：部分編集のフォーム、楽観更新、ドラフト行、依存するドロップダウン、「保存」ボタンの明確なルールなど。パフォーマンスはしばしば完璧なLighthouseスコアを追うことではなく、操作が速く予測可能であることに関わっています。

チームの現実も機能と同じくらい重要です。個人で作るなら、スピードとシンプルさを報いるフレームワークを受け入れるかもしれません。回転するメンバーで保守するなら、最も良い選択は明確な規約、レビューのしやすさ、トリッキーなパターンが少ないものです。

この比較は年間を通して繰り返す作業に焦点を当てています：テーブル／フォーム／モーダルのコンポーネントの使いやすさ、社内ツールでの実際のバンドルサイズの意味、新しい貢献者のオンボーディング速度、数か月後の保守性など。各エコシステムのすべてのライブラリやバックエンドの選択肢は扱いません。

コンポーネントの使いやすさ：日常的に触る基本要素

CRUDが多いダッシュボードでの「コンポーネントの使いやすさ」は要するに、フォーム、テーブル、フィルター、詳細ページを一日中作るときにどれだけ摩擦を感じるかです。

Vue 3はよくラベル付けされた工具箱のように感じられます。テンプレートでUIを記述し、ローカル状態はrefやreactiveに置き、派生データや副作用にはcomputedやwatcherを使います。何が何を変えるかを明示しやすく、大きくなったときに助けになります。

Svelteはセレモニーが少ないプレーンなUIコードを書くような感覚です。リアクティビティは代入で発動するので、多くのコンポーネントが単純なスクリプトのように読めます。その速さは本物ですが、チームとして「この更新はどこから来た？」が繰り返しの疑問にならないよう習慣や規約が必要です。

社内ツールでは繰り返し使う形がいくつかあります：バリデーションと“dirty”トラッキングを備えたフォーム、ソート／フィルタ／ページングのあるテーブル、クイック編集用のモーダルやドロワー、再利用可能な入力群（日付ピッカー、セレクト、通貨フィールド）。どちらでもUIを多画面で共有するのは比較的簡単です。

Vueではpropsとemitされたイベントがコンポーネント間の予測可能な契約を促します。Svelteではコンポーネントのpropsやstoresが非常に簡潔になりえますが、どの状態をストアに置きどれをpropsで渡すかを早期に合意しておかないと、状態が“デフォルトでグローバル”に傾きがちです。

実務的なテストは、10画面で使われる1つのフィールド（例えば「アカウントステータス」）を取り、名前変更、バリデーション調整、テーブル列の更新をするのに何箇所触る必要があるかを確かめることです。小さく明確なコンポーネントインターフェースは変更をより安全にします。

バンドルサイズとパフォーマンス：CRUDアプリで重要なこと

バンドルサイズとは、ブラウザがダッシュボードを表示するためにダウンロードするJavaScriptやその他のアセット量です。社内ツールでは初回読み込みが重要（特にVPNや遅いラップトップでは）ですが、日常の使用感のほうがより重要です：ユーザーがタブを切り替え、モーダルを開き、テーブルを1日に50回フィルタするときに画面がどれだけ速く感じるか。

ほとんどのCRUDダッシュボードが重くなるのはフォームやボタンのせいではありません。時間とともに追加されるものが原因です：フル機能のデータグリッド、チャートライブラリ、日付ピッカー、リッチテキストエディタ、ファイルアップロードウィジェット、大きなアイコンセット、ユーティリティライブラリなどが静かに積み上がります。

SvelteとVue 3は基礎部分を異なる形で扱います。SvelteはコンポーネントをプレーンなJavaScriptにコンパイルするため、ブラウザに送るフレームワークランタイムが少なくなりがちです。Vue 3は小さなランタイムを送り、ツリーシェイクも効きます。どちらもCRUD画面には通常十分速いです。実際にはフレームワーク自体がバンドルの最大部分になることはまれで、コンポーネントライブラリや一発物のウィジェットが支配的です。

考え方の一例として：Svelteはしばしば小さめのベースラインを与え、Vue 3は予測可能なパターンと成熟したツールチェーンで勝ることが多いです。どちらでも、重いグリッドやチャートを至る所でインポートすれば遅く感じます。

サイズと速度を抑えるには理論より習慣に集中してください：

• 高コストな画面は遅延読み込みする（ルートベースのロード）。
• 使うものだけをインポートする（“ライブラリ丸ごと”インポートを避ける）。
• チャートやエディタはクリティカルパスから外す（テーブルが使えるようになった後でレンダリングする）。
• 複数のコンポーネントシステムを混ぜず、1つのUIキットを再利用する。
• 定期的に計測する：各リリース後にバンドルサイズとTime-to-Interactiveを測る。

例：ある運用ダッシュボードは「注文」「顧客」画面が瞬時に感じられても、重いグリッドとチャートをすべてのページに追加した瞬間に重くなります。チャートを「Analytics」を開いたときだけ読み込めば、総バンドルが小さくなくても操作感はサクサク保てます。

学習曲線：オンボーディングと日常のスピード

社内ダッシュボードにおける本当の学習曲線は最初のチュートリアルではありません。既存の画面を開いてフォーム、テーブル、権限を安全に変更できるまでの速さです。

SvelteはコンポーネントがHTMLに少しのJavaScriptを足したように読めるので、初速は取りつきやすい傾向があります。新しいメンバーは多くの場合、ページで何が起きているかを大きなフレームワーク固有の概念を学ぶ前に追えるでしょう。トレードオフは、ファイル構成、共有ロジック、ストアの使い方などのパターンを早めに合意しておかないと、画面ごとに見た目が微妙に違ってしまう点です。

Vue 3は最初は少し時間がかかるかもしれませんが、コードベースでより多くの規約を見ることになるため、チームがコンポーネント、フォーム、データ取得の一貫したスタイルに合わせれば長期的に恩恵があります。

生産性が出るのは、繰り返しの作業が本当に繰り返し可能になったときです：フォームの構築とバリデーション、一覧／作成／編集／詳細ビュー間のルーティング、読み込み／エラー／空状態の一貫した扱い、テーブルとフィルターコンポーネントの画面横断の共有。どちらのフレームワークでも可能ですが、ルーティング、状態管理、UIコンポーネント、バリデーションといった補助部分を早期に標準化する必要があります。

具体例：新入社員が「Vendors」の編集ページに2つフィールドを追加し、「Vendor type = Contractor」のときは必須にする必要があるとします。コードベースに明確なフォームパターンと予測可能なデータフローがあれば1時間の作業です。各ページが独自方式を採っているなら、やり方を理解するだけで1日かかることもあります。

状態とデータフロー：CRUD画面を予測可能に保つ

CRUDダッシュボードは簡単に見えますが、同じ基本（フィルタ、ページング、権限、ドラフト、読み込み状態）を30画面で必要とするとき、本当に差が出るのは生の速度ではなく、状態ルールがアプリの成長に伴って一貫しているかです。

Vue 3では、多くのチームが再利用可能なデータ取得やフォームロジックをcomposablesにし、共有ストア（多くはPinia）にワークスペースや機能フラグ、キャッシュされた参照データなどの画面横断の状態を置く明確な分割に落ち着きます。Composition APIはロジックをコンポーネントに近づけつつ、繰り返すようになったら抽出するのを容易にします。

Svelteではstoresが重心になります。writableやderivedのstoresで画面は整理できますが、購読の中に副作用を隠してしまわないよう厳密さが必要です。SvelteKitを使う場合はルートレベルのロードがデータがページに入る標準化された場所になりやすく、そこからpropsで下に渡すのが自然です。

どちらでも予測可能なアプリは退屈なルールに従います：API呼び出しは1か所にまとめる（小さなクライアントモジュール）、読み込み／エラー状態の命名を一貫させる（例：listLoading vs saveLoading）、共有するものだけをキャッシュしログアウトやテナント切替でリセットする、派生値は派生にしておく（Vueではcomputed、Svelteではderived store）、副作用は明示的なアクションの背後に隠す（saveUser()、deleteInvoice()）などです。

テストではフレームワークの内部より振る舞いに注目してください。ダッシュボードで痛い失敗はバリデーションとマッピング（UIモデル→APIペイロード）、一覧操作（フィルタ／ソート／ページング）と空状態、作成／更新／削除フロー（再試行含む）、権限チェック（隠すのかブロックするのか）です。

長期的な保守性：時間とともに遅くならないために

社内ダッシュボードの保守性はエレガントなコードよりも一つのことに尽きます：51番目の画面を追加しても、すべての変更が1週間の大掃除にならないか。

50以上の画面で読みやすさを保つ

Vue 3は長期の一貫性で強みを持つ傾向があります。Single File Components、共有ロジックのcomposables、明確なコンポーネント階層といった既知のパターンに頼れます。機能ベースのフォルダ構成（例：/users、/invoices、/settings）を使えば、フィールドや列、ダイアログがどこにあるか分かりやすいままです。

Svelteも同様に読みやすく保てますが、よりチームの規律に依存します。Svelteコンポーネントは始めるのが簡単に感じるため、プロジェクトがローカル状態、場当たり的なストア、コピペしたハンドラの混在に成長してしまうことがあります。対処法は明白です：画面は薄く保ち、再利用UIは共有ライブラリに移し、データアクセスと権限はプレーンなモジュールに隔離します。

共通の業務ルール（バリデーション、権限、フォーマット）

最大の落とし穴はビジネスルールをUIコンポーネントに散らばらせることです。SvelteでもVueでも、これらのルールは画面が呼び出す共有レイヤーとして扱ってください。

実務的なアプローチは次の通りです：バリデーションとフォーマットはスキーマかヘルパー関数にまとめる、権限はcanEdit(user, record)のような単純な関数にする、API呼び出しは機能ごとの小さなサービスモジュールに置く、画面テンプレートを標準化する（テーブル＋フィルター＋作成／編集ドロワー）、入力／モーダル／テーブルの共有UIキットを作る。

リファクタはどう進むか

Vueでは後からパターンを見直すときにやりやすいことが多いです。エコシステムが深く、規約がチーム間で共通しているため、propの名前変更、ロジックのcomposables化、状態管理の置き換えが予測しやすいです。

Svelteのリファクタはボイラープレートが少ない分速く進められることが多いですが、初期に画面内で独自のバリデーションを大量に書いた場合、それらを共有レイヤに移すと多くのファイルを触る必要が出ます。

保守しやすい内部ツールは意図的に退屈です：データ取得は一つの方法、バリデーションは一つの方法、エラー表示は一つの方法、権限の適用は一つの方法。

エコシステムとチームワークフロー：一貫性を保つ

社内ダッシュボードでは、最良のフレームワークはしばしば「チームが毎回同じ方法で使えるもの」です。議論は「どちらが優れているか」より、「20画面を超えたときにワークフローが予測可能か」に重心を置くべきです。

Vue 3はエコシステムが大きく成熟しています。UIキット、フォームヘルパー、テーブルコンポーネント、ツール類の選択肢が多い反面、選択肢が多すぎて異なるライブラリが異なる考え方を押してきてパターンが混在するリスクがあります。

Svelteのエコシステムは小さめですがシンプルなことが多く、依存を軽く保ちたいチームには有利です。ただし、複雑なデータテーブルやエンタープライズ向けUI慣習のギャップを埋める必要が出るかもしれません。

コミュニティのサポートを評価するときはトレンドではなく退屈なシグナルを見てください：ここ1年の安定したリリース、Issueに回答が付くか（たとえ答えが"no"でも）、自分の使うバージョンとの互換性情報、実際のCRUD例（フォーム、テーブル、認証）、明確な移行ガイド。放置された依存は「バージョンXでしか動かない」やピア依存の長いスレッドで現れます。

一貫性は主にチームの決定です。小さなパターンセットを選んで文書化してください：フォルダ構造は一つ、フォームのやり方は一つ、テーブルコンポーネントは一つ、データ取得の方法は一つ、エラーと読み込み状態の扱いは一つ。

簡単なテスト：二人の開発者に「承認(Approvals)」画面（一覧、フィルター、詳細、編集）を作らせてみてください。出来上がるコードが違う見た目なら、規約が緩すぎます。

選び方：段階的な評価プロセス

良い選択は意見よりもチームがどれだけ速く画面を出して変更できるかに基づきます。テーブル、フォーム、バリデーション、ロール、ちょっとした修正を繰り返す作業をテストしてください。

まず実際のダッシュボードにある表面をリストアップします。すべてのページタイプ（一覧、詳細、編集、管理設定）と再利用するUIパーツ（データテーブル、フィルタバー、日付ピッカー、確認モーダル、トースト）を含めると採点表になります。

次に日常作業に合った小さなベイクオフを実施します：

1. 同じ小さなアプリを二つ作る：一覧ページ、編集フォーム、認証で保護されたルート。
2. 現実的なデータ形状（ネスト、オプショナルフィールド、列挙型）と同じAPIスタイルを両方で使う。
3. 本番ビルド出力とコールドロードを速いマシンではなく控えめなマシンでチェックする。
4. 3つの変更リクエストを時間計測する：フィールド追加、フィルタ追加、列を隠してアクションをブロックする権限ルール追加。
5. 1週間後にコードをレビューして何が読みやすく残っているかを見る。

作業中にノートを取ってください。どこでフレームワークと戦ったか？フィールド名を変えたら何が壊れたか？パターンをコピペしたのはどれくらいで、それは一貫したままだったか？

フレームワーク選びでチームが犯しがちなミス

最も一般的な落とし穴は最初のバージョンの早さだけを最適化することです。CRUDダッシュボードはあまり"完成"しません。新しいフィールドが出てきて、権限が変わり、単純なフォームがバリデーションやエッジケースで膨らみます。フレームワーク選びが巧妙なショートカットを促すなら、毎週それを支払うことになります。

チームはテーブル、フィルタ、バリデーションの本当の作業量を過小評価しがちです。ダッシュボードは通常、ソート、ページング、保存されたビュー、インライン編集、エクスポートを備えたグリッドです。おもちゃのカウンターアプリではなく現実の要件で評価してください。

もう一つの静かなミスは各開発者に好きにパターンを作らせてしまうことです。二人が同じCRUD画面をまったく違う手法で作ると、半年後には簡単な変更がリスクを伴うようになります。

長期的な痛みを防ぐガードレール：

• フォームとバリデーション、エラー表示の1つのやり方を合意する。
• 標準的なテーブルパターンを定義する（ソート、ページング、読み込み、空状態）。
• 共有状態のアプローチとイベント／ストアの命名規則を決める。
• コンポーネントは差し替え可能に：大きな“スーパーコンポーネント”より小さく明確な部品を好む。
• 新しい画面に対して軽量なチェックリストを使う（権限、監査フィールド、テスト）。

早期にUIを過度にカスタマイズするのも避けてください。完璧な編集可能テーブルを作ってしまい、後で行レベルの権限やセルごとのサーバー側バリデーションを要求されると差し替えが難しくなります。

コミットする前の簡単チェックリスト

構文の議論に入る前に実務テストをしてください。勝者は本番のCRUD圧力下で退屈に振る舞うものです。

"週初めの開発者"テスト

よく起きる小さな変更（テーブルに列を追加し、編集フォームにフィールドを追加する）を選び、新しい人に渡してどれだけ速く確信を持って出せるかを見ます。

素早い直感チェック：

• 新しい仲間が小さなUI変更を1週間で、フォルダの半分を書き換えずにできるか。
• フォームはバリデーション、サーバーエラー、読み込み状態、成功メッセージについて一つの明確なアプローチに従っているか。
• 実際に使うグリッド、チャート、日付ピッカー、認証ライブラリを追加した後でもロード時間が許容範囲か。
• 状態とデータフローを5分で説明できるか（派生データがどこにあるか、ナビゲーションで状態がどうリセットされるか含む）。
• 例えば「Edit Customer」ページを分割するようなリファクタが他のコンポーネントに触らずにできるか。

現実的な確認シナリオ

「Tickets」ダッシュボード（一覧、フィルタ、詳細ドロワー、編集フォーム、バルクアクション）を想像して、1つのスライスを最初から最後まで作って時間を測ってください。フォームロジックがフォーム内にある、エラーがフィールド近くにある、データ取得が予測可能に行われるフレームワークが長期では勝つことが多いです。

現実的な例と次の一手

小さな物流チーム向けの運用ダッシュボードを想像してください：フィルタ付きの注文テーブル、詳細ドロワー、クイックステータス更新（Packed、Shipped、On Hold）、ロールベースのアクション。担当者は住所を編集し、マネージャーは返金を承認し、管理者はワークフロールールを変更します。

このようなケースでは、Svelteはその瞬間の速さを感じさせることが多いです。単一コンポーネントにUIと少しの状態を持たせ、行クリックでサイドパネルを開くのが簡単にできるからです。

一方でVue 3はチームで触るときに安全に感じられることが多いです。規約とツールチェーンにより多くの画面での一貫性を保ちやすく、共有コンポーネントライブラリとフォーム・バリデーション・API呼び出しの明確なパターンがあれば、コードベースは成長しても予測可能に保たれます。

頻繁にフィールドやワークフローの更新が起きることが予想されるなら、最大のリスクは生の性能ではなく“ドリフト”です：微妙に違うフィルター、微妙に違うフォームルール、そして「この画面だけ特別」という積み重ね。

実務的な次の一手は、まず一覧・編集・権限・監査ログを含むエンドツーエンドのスライスをプロトタイプし、その後いくつかの書面化されたルールにコミットすることです：1つの標準フォームパターン、1つのテーブルパターン、1つのAPIレイヤー手法、1つの権限モデル、1つのフォルダ構成。

もし主な目的が余計な部品を減らして社内ワークフローを素早く提供することなら、AppMasterのようなノーコードプラットフォームを試してみる価値があります。バックエンド、Web UI、ネイティブモバイルアプリを一箇所から生成でき、繰り返しのCRUDコードの負担を軽減できます。