アイランドアーキテクチャとは？仕組み・Astroの実装・PPRとの違い

アイランドアーキテクチャ（Islands Architecture）は、ページの大半を静的HTMLで配信し、対話性が必要な部分だけを「島（island）」として個別にJavaScriptで動かす設計パターンだ。SPAのようにページ全体を一括でハイドレートしないため、初期表示に不要なJavaScriptを送らずに済む。本記事では島の考え方と仕組み（部分ハイドレーション）、Astroのclient:*ディレクティブによる実装、採用すべきでない場面、そして混同されやすいPPR（Partial Prerendering）との違いまでを、実装目線で整理する。

まとめ：アイランドアーキテクチャの要点

• 定義：静的HTMLの中に、対話性が必要な部分だけを独立してハイドレートする「島」を置く設計。ページ全体ではなく島単位でJavaScriptを配信する。
• 仕組み：部分ハイドレーション（選択的ハイドレーション）。島の外側は素のHTMLのままJavaScriptゼロで動く。
• 代表実装：Astro（client:load／client:visible等）、Deno製のFresh、eBayのMarko。Astroはserver:deferによるサーバーアイランドも持つ。
• 向くケース：ブログ・LP・ドキュメント・ECの商品ページなど、コンテンツ主体で対話性が局所的なサイト。
• PPRとの違い：PPRはサーバー側の静的／動的境界を最適化する技術で、クライアントのJS量を削る島とは最適化する層が異なる。PPRはNext.js 16（2025年10月）で安定化した。

アイランドアーキテクチャとは（基本概念と設計思想）

アイランドアーキテクチャは、ページを「静的HTMLの海」と、その中に点在する「対話的な島」に分けて捉える設計思想だ。ヘッダー・本文・フッターといった動かない部分は素のHTMLとして配信し、検索ボックス・カルーセル・いいねボタンのようにJavaScriptが要る部分だけを島として切り出す。島ごとに独立して動くため、片方の島の描画が遅れても他の島やページ全体はブロックされない。

用語としての「Islands Architecture」は、PreactのJason Millerが2020年の記事で、Etsyのカティ・シラー＝ミラー（Katie Sylor-Miller）が使っていた「component islands」の考えを整理して広めたものとされる。パターン自体はサーバーが返したHTMLに部分的にJSを足す古い手法の再解釈でもあり、新しい発明というより「振り子の揺り戻し」に近い。

従来のSPAで起きていた問題

ReactやVueによる典型的なSPAは、サーバーがほぼ空のHTMLを返し、クライアントでJavaScriptを実行してページ全体を構築する。あるいはSSRでHTMLを返した後、そのHTML全体を再度JavaScriptで「ハイドレート（イベントを紐付けて対話可能にする処理）」する。どちらもページ全体分のJavaScriptをダウンロード・実行し終えるまで操作できないため、コンテンツ主体のサイトほど無駄が大きい。記事本文のように一度描画したら動かない部分にまでハイドレーションのコストを払う点が根本の非効率だった。この前提を理解するには、レンダリング方式そのものの違いを押さえておくとよい（CSRとSSRの違いと使い分け）。

アイランドアーキテクチャの仕組み（部分ハイドレーション）

島を成立させる中核が部分ハイドレーション（partial hydration／選択的ハイドレーション）だ。サーバーで生成した初期HTMLをそのまま使い、対話性が必要な島だけを個別にハイドレートする。島の外側は再レンダリングもハイドレーションもされず、素のHTMLとして残る。結果として、初期ロードで実行されるJavaScriptは全ページ分ではなく島の合計分だけに縮む。

クライアントアイランドとサーバーアイランド

島は動く「場所」で2種類に分けられる。クライアントアイランドは、静的HTMLに埋め込まれた対話的UIをブラウザ側でハイドレートするもので、いわゆる島の基本形だ。サーバーアイランド（Astroのserver:defer）は、パーソナライズや重い問い合わせなど時間のかかる部分をメインのページ描画から切り離し、サーバー側で並列にレンダリングして後追いで差し込む。静的な骨格を即座に返しつつ、動的な部分だけ遅延して埋める使い分けができる。

実装フレームワークと使い方

アイランドを標準機能として提供する代表がAstro、Deno製のFresh、eBay発のMarkoだ。いずれも「デフォルトはJavaScriptゼロ、必要な島にだけJSを送る」という点で共通する。

Astroのクライアントディレクティブ

Astroでは、フレームワークコンポーネント（React／Vue／Svelte等）を島にする際、client:*ディレクティブでいつハイドレートするかを明示する。指定しなければコンポーネントは静的HTMLとして描画され、JavaScriptは一切送られない。

後ろ倒しになるのはidle・visible・mediaで、loadとonlyは即時ハイドレート（onlyはSSRを省く点だけが異なる）だ。

記述はコンポーネントに属性を付けるだけで済む。

<!-- ビューポートに入るまでJSを送らない島 -->
<Chart client:visible />

<!-- 即時ハイドレートするナビ -->
<Menu client:load />

「上から下へスクロールするほどload→idle→visibleと後ろ倒しにする」のが基本方針だ。ファーストビューの外にある島をclient:loadにしないだけで、初期JSは大きく減る。AstroはReactを島として取り込めるため、両者の役割分担はAstroとReactの違いと使い分けも合わせて確認したい。

Fresh・Markoなど他の実装

Deno製のFreshは、ビルドステップなし・JITコンパイル・Preactベースで島を実現する。islands/ディレクトリに置いたコンポーネントだけがクライアントに送られる、という規約ベースの分割が特徴だ。MarkoはeBayが自社の大規模ECで使うフレームワークで、対話的な部分の自動的な部分ハイドレーションを早くから実装していた。いずれも「島の外はJSゼロ」という原則は同じで、島をどう指定するか（属性／ディレクトリ規約）が違う。

メリット・デメリットと採用を避けるべき場面

最大の利点は初期JavaScript量の削減で、これがLCPやTBTといったCore Web Vitalsの改善に直結する。SEOでも、静的HTMLがそのまま配信されるためクロール・インデックスが素直だ。一方で、島が相互に状態を共有しづらいという構造的な弱点がある。島はそれぞれ独立して動くため、島をまたいだグローバルな状態管理（例：どのページでも同期するカートの中身）を素直に書きづらく、状態共有の設計に手間がかかる。

採用を避けるべきなのは、アプリ全体が高い対話性を持つ「島だらけ」のケースだ。管理画面ダッシュボードやSaaSの操作画面のように、画面のほぼ全域がリアルタイムに更新され相互に連動するUIでは、島の数が増えて分割の利点が消え、むしろ島間連携のコストだけが残る。この種のアプリは従来型のSPA（あるいはPPRやReact Server Components）の方が素直だ。逆に、ブログ・LP・ドキュメント・ECの商品ページのように「静的な地の中に対話が局所的に散る」サイトが最も適する。

PPR（Partial Prerendering）との違い

アイランドアーキテクチャと混同されやすいのがNext.jsのPPRだが、両者は最適化する層が違う。PPRは1つのルートの中で静的部分と動的部分の境界を引き、ビルド時に静的なHTMLシェルを生成しておき、リクエスト時にシェルを即返しつつ動的部分だけをストリーミングで差し込む。狙いはサーバー側の初期HTML配信（TTFB）の最適化だ。

対してアイランドは、クライアントに送るJavaScriptの量を島単位に絞ることが狙いで、最適化の主戦場はブラウザ側にある。つまりPPR＝サーバー描画の境界、島＝クライアント対話の境界を扱う。「PPRはアイランドアーキテクチャの一種か」という問いは、Next.jsコミュニティの技術議論でも別技術として整理されている。島に近い発想はむしろReact Server ComponentsとClient Componentsの二層構造の方で、Client Componentsが静的HTMLに埋め込まれた島のように振る舞う。

なお、PPRはNext.js 14で実験的機能として登場し、Next.js 16（2025年10月）でCache Componentsの一部として安定化した。旧来のexperimental.pprフラグやexperimental_pprエクスポートは廃止され、現在はcacheComponents: trueで有効化する。「PPRは実験的」という古い記述は最新版では当てはまらない点に注意したい。

よくある質問

アイランドアーキテクチャとは何ですか？

ページの大半を静的HTMLで配信し、対話性が必要な部分だけを独立した「島」としてJavaScriptで動かす設計パターンです。ページ全体ではなく島単位でハイドレートするため、初期ロードのJavaScriptを最小化できます。

AstroとReactの違いは何ですか？

Astroは島を前提に「デフォルトJSゼロ」で静的HTMLを配信するフレームワーク、Reactは対話的UIを構築するライブラリで、AstroはReactを島として内部に取り込めます。用途と役割の詳細はAstroとReactの違いを参照してください。

アイランドアーキテクチャとSSR/CSRはどう違いますか？

SSR/CSRは「HTMLをどこで生成するか」の分類で、アイランドは「生成したHTMLのどこをどれだけハイドレートするか」の分類です。島はSSRで返したHTMLに対し、島だけを部分的にハイドレートする点でCSR的な全体ハイドレーションと異なります。

PPRとアイランドアーキテクチャは同じものですか？

別物です。PPRはサーバー側で静的・動的の境界をストリーミングする技術、アイランドはクライアントに送るJSを島単位に絞る技術で、最適化する層が異なります。

アイランドアーキテクチャのデメリットは何ですか？

島どうしがそれぞれ独立して動くため、島をまたいだグローバルな状態共有を書きづらい点です。画面全域が高い対話性を持つアプリでは島の利点が薄れ、SPAの方が適します。

関連記事

• AstroとReactの違いと使い分け
• CSRとSSRの違いと使い分け
• Deno製フレームワークFreshの概要