---
title: "アイランドアーキテクチャとは？仕組み・Astroの実装・PPRとの違い"
url: "https://www.issoh.co.jp/tech/details/2423/"
published: 2024-06-11
updated: 2026-09-27
categories: ["Astro"]
publisher: "株式会社一創"
---

# アイランドアーキテクチャとは？仕組み・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の違いと使い分け](https://www.issoh.co.jp/tech/details/5895/)）。

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

島を成立させる中核が**部分ハイドレーション（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は一切送られない。

| ディレクティブ          | ハイドレートの契機           | 主な用途                 |
| ---------------- | ------------------- | -------------------- |
| `client:load`    | ページ読み込み直後に即時        | ヘッダーメニューなど最優先UI      |
| `client:idle`    | ブラウザがアイドルになった時      | ニュースレター登録など二次的ウィジェット |
| `client:visible` | 要素がビューポートに入った時      | 下スクロールで現れるチャート等      |
| `client:media`   | 指定メディアクエリが成立した時     | モバイル専用トグルなど条件付きUI    |
| `client:only`    | SSRせず即時にクライアントのみで描画 | SSRで壊れる外部埋め込み        |

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

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

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

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

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

### Fresh・Markoなど他の実装

Deno製の[Fresh](https://www.issoh.co.jp/tech/details/3619/)は、ビルドステップなし・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の違い](https://www.issoh.co.jp/tech/details/2697/)を参照してください。

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

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

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

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

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

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

## 関連記事

- [AstroとReactの違いと使い分け](https://www.issoh.co.jp/tech/details/2697/)
- [CSRとSSRの違いと使い分け](https://www.issoh.co.jp/tech/details/5895/)
- [Deno製フレームワークFreshの概要](https://www.issoh.co.jp/tech/details/3619/)

---

出典: [アイランドアーキテクチャとは？仕組み・Astroの実装・PPRとの違い](<https://www.issoh.co.jp/tech/details/2423/>)（株式会社一創）