Hillaとは?Spring BootとReactで作るフルスタックフレームワークの仕組みと導入を解説
Hilla(ヒッラ)は、Spring BootのバックエンドとReactのフロントエンドを型安全につなぐフルスタックWebフレームワークです。開発元はフィンランドのVaadin社で、2024年6月のVaadin 24.4以降はVaadinプラットフォームの一部として提供されています。本記事はこのソフトウェア開発フレームワークとしてのHillaを解説します(北欧生地ブランド「Studio Hilla」など同名の製品とは別物です)。Java資産を活かしながら、REST APIを手書きせずReact画面をつくりたいチームに向いた選択肢で、その仕組み・Vaadinとの関係・対応バージョン・導入手順・向き不向きを一次情報にもとづいて整理します。
まとめ:Hillaはどんなフレームワークか
- 正体:Vaadin社製のフルスタックフレームワーク。Spring Boot(Java)+React(TypeScript)を1プロジェクトで扱う。UIはReactが既定で、Litも選べる。
- 中核の仕組み:Springのサービスクラスに
@BrowserCallableを付けるだけで、型付きのTypeScriptクライアントが自動生成され、RESTエンドポイントやfetch処理を手書きせずに呼び出せる。 - 状態とリアルタイム:Signalsで状態を管理し、フルスタックSignalsでサーバーとクライアントの状態をWebSocketの手実装なしに同期できる。
- Vaadinとの関係:Vaadin 24.4でプラットフォームに統合され、バージョンが2.5→24.4に切り替わった。Java中心で完結させたい場合はサーバー側UIのFlow、フロントをReactで作りたい場合はHilla、と使い分ける。
- 採否の目安:Spring Boot+Reactを型安全に速く作りたいチームに有効。バックエンドがJava以外、または任意のREST APIと素のReactで組みたい場合は不向き。
Hillaとは何か:Spring BootとReactを1つにするフルスタック構成
Hillaは、バックエンドにSpring Boot、フロントエンドにReactを採用し、両者を1つのMavenプロジェクトとして開発・ビルド・配布できるフレームワークです。従来この構成では、サーバー側でREST APIを定義し、フロント側で型を再定義してfetchを書く、という二重作業とズレのリスクがありました。Hillaはこの境界を「Javaの型を正」として自動生成でつなぐことで、その手間と型ズレをなくします。役割分担そのものの考え方はSpring BootとReactを連携する方法で整理していますが、Hillaはその連携部分をフレームワークが肩代わりする点が特徴です。
UIライブラリはReactが既定で、好みに応じてGoogleのLitも選べます。公式は現在Reactを主軸に案内しており、コンポーネントにはVaadinのUIコンポーネント群をそのまま利用できます。
Hillaの仕組み:@BrowserCallableで型安全につなぐ
型付きTypeScriptクライアントによるサーバーメソッドの公開
Spring管理下のクラスに@BrowserCallable(Hilla 2.2以降。従来の@Endpointの別名)を付けると、そのpublicメソッドがブラウザから呼べるエンドポイントになります。ビルド時にメソッドと引数・戻り値の型を写したTypeScriptクライアントが生成され、フロントからは通常の非同期関数のように呼び出せます。アノテーションでSpringの振る舞いを制御する発想はSpring Bootの主要なアノテーション一覧と同じで、Hilla固有のものが1つ増えると捉えると分かりやすいです。
// サーバー側(Java)
@BrowserCallable
@AnonymousAllowed
public class GreetService {
public String greet(String name) {
return "Hello, " + name;
}
}
// フロント側(React・TypeScript)— 生成物を呼ぶだけ
import { GreetService } from "Frontend/generated/endpoints";
const message = await GreetService.greet("Hilla"); // 戻り値は string 型
引数や戻り値の型を変えると再生成でフロント側の型も更新され、齟齬があればコンパイル時に検出できます。認可は@AnonymousAllowedや@RolesAllowedなどSpring Securityの仕組みで制御します。
ファイルベースルーティングによる画面追加
src/main/frontend/views にReactコンポーネントのファイルを置くと、Hillaがそのパスをルートとして自動登録します。ルート定義ファイルを個別に書く必要がなく、ファイル配置がそのまま画面のURL構造になります。
Signalsによる状態管理とリアルタイム同期
Hillaは状態管理にSignalsを採用し、Reactでは@vaadin/hilla-react-signalsを通じてコンポーネント間で状態変化を共有します。さらにフルスタックSignalsを使うと、サーバーとすべてのクライアントの間で状態をリアルタイムに同期できます。@BrowserCallableなサービスからフルスタックSignal型を返すだけで、共同編集やライブ更新のような画面を、WebSocketの接続管理を手実装せずに構築できます。ストリーミングはProject Reactorのリアクティブストリームに対応しています。
VaadinプラットフォームとHillaの関係
Vaadin 24.4での統合とバージョンの切り替わり
Hillaはもともと単独の製品(Hilla 2.x系)でしたが、2024年6月12日リリースのVaadin 24.4でVaadinプラットフォームに再統合されました。このときバージョン番号が2.5から24.4へ飛び、以降はVaadinのバージョン体系に揃います。Mavenアーティファクトはcom.vaadin、npmモジュールは@vaadinスコープで配布され、旧ドキュメントサイトhilla.devはvaadin.com/hillaへ順次集約されています。単独製品としてのHillaは提供終了しており、現在は「Vaadin Hilla」として探すのが確実です。
HillaとFlowの使い分け
Vaadinには2つのUIの作り方があります。FlowはサーバーサイドでJavaだけでUIを記述する方式、HillaはフロントをReact(TypeScript)で記述する方式です。Vaadin 24.4以降は同一プロジェクトでFlowのビュー(Java)とHillaのビュー(React)を混在させられます。フロントエンドをReactで作りたい・フロント担当がいるならHilla、Javaだけで画面まで完結させたいならFlow、というのが基本の判断軸です。
Hillaのバージョンと動作環境
Hillaのバージョンは統合先のVaadinに一致します。バージョンごとに前提となるJava・Spring Bootが異なるため、新規採用時は次の対応関係を確認してください(変動するため最新は公式リリースノートで確認してください)。
| 系列 | 位置づけ | Java | Spring Boot |
|---|---|---|---|
| Vaadin 25 系 | 最新 | 21以上 | 4 系 |
| Vaadin 24 系(LTS) | 長期サポート | 17以上 | 3 系 |
| Hilla 2.x(旧・単独) | 統合前 | 17以上 | 3 系 |
2026年時点ではVaadin 25系(Java 21・Spring Boot 4・Jakarta EE 11ベース)が最新で、Vaadin 24系がLTSとして併存します。既存アプリのSpring Bootを4へ上げる際の注意点はSpring Boot 4の変更点、サポート期限の考え方はSpring Bootバージョン一覧とサポート期限を参照してください。新規プロジェクトは最新のVaadin 25系が公式の推奨です。既存のJava 17・Spring Boot 3資産をそのまま延命したい場合はLTSの24系が選択肢になりますが、無償メンテナンスの提供期限は縮小傾向のため、採用前に公式のリリース・サポートポリシーで確認してください。
Hillaの導入手順
最短はプロジェクト生成サービスを使う方法です。
- 雛形を作る:start.vaadin.com でHilla(React)を選んでプロジェクトを生成し、ダウンロードする。Java 17以上(Vaadin 25なら21以上)とNode.jsが必要。
- 起動する:
mvn spring-boot:runで開発サーバーが立ち上がり、フロントのビルドとライブリロードが有効になる。 - 機能を足す:Springのサービスに
@BrowserCallableを付けてエンドポイントを公開し、src/main/frontend/viewsにReactの画面を追加する。ビルド時にTypeScriptクライアントが再生成される。
ディレクトリはJavaがsrc/main/java、フロントがsrc/main/frontendに分かれ、1つのMavenビルドでJARにまとまります。
Hillaを採用すべきケースと避けるべきケース
Hillaが効くのは、Spring Bootのバックエンド資産があり、フロントはReactで型安全に速く作りたいケースです。API定義とフロントの型を二重管理する手間が消え、社内ツールや管理画面のように「Javaのドメインロジックをそのまま画面に出したい」用途と相性が良好です。
一方で、次の場合は避けるか慎重に検討すべきです。バックエンドがJava(Spring Boot)以外なら、Hillaの型連携の恩恵は受けられません。既に確立したREST/GraphQL APIがあり素のReactやNext.jsで組みたい場合、Hillaのエンドポイント方式はかえって制約になります。また純粋な公開向けSPAやSSR最重視のサイトは、Next.jsなど専用フレームワークの方が適します。UIをJavaだけで完結させたいなら、同じVaadinのFlowを選ぶべきです。
よくある質問(FAQ)
HillaとVaadinは違うものですか?
現在のHillaはVaadinプラットフォームの一部です。Vaadin 24.4で統合され、Vaadinの中でReactによるフロント開発を担う枠組みがHillaにあたります。Javaだけで画面を書くFlowと対になる存在です。
HillaはReactとLitのどちらを使いますか?
既定はReactです。公式はReactを主軸に案内しており、必要に応じてGoogleのLitも選べます。新規開発では特別な理由がなければReactが無難です。
Hilla 2.5から24.4に上がったのはなぜですか?
単独製品だったHillaがVaadinプラットフォームへ再統合され、Vaadinのバージョン体系に合わせたためです。番号が飛んだだけで、2.5の次の世代が24.4にあたります。
@Endpointと@BrowserCallableはどう違いますか?
ほぼ同じで、@BrowserCallableはHilla 2.2以降に追加された@Endpointの別名です。違いは、@BrowserCallableがvalue属性を持たずエンドポイント名がクラス名に固定される点だけです。現在の公式ドキュメントは@BrowserCallableを使う例が中心です。
Hillaは日本語の情報だけで導入できますか?
一次情報は英語の公式ドキュメント(vaadin.com/hilla)が中心です。基本構成はSpring Boot+Reactなので、両者の日本語知識があれば公式サンプルを追う形で導入できます。