Islands Architecture（アイランズアーキテクチャ）は、ページ全体は静的HTMLとして配信し、対話が必要な部分だけを「島（Island）」と呼ばれる独立コンポーネントに切り出して、それぞれが個別にJavaScriptで動くよう設計するフロントエンド構成です。命名は2019年にKaty Decorah氏が言及し、その後Preactチームのジェイソン・ミラー氏が広め、Astro（2021年Fred K. Schott氏ら）が「ファイル単位での島宣言」として実装に落とし込んだことで一般化しました。
この記事の目次
- Islandsの基本構造
- Astroが定着させた実装
- Islands採用の判断基準
- Server ComponentsやPartial Hydrationとの違い
- まとめ
Islandsの基本構造
Islands Architectureを直感的に理解する比喩は「海に浮かぶ島々」です。ページの大部分（記事本文、画像、ナビゲーション、フッタなど）は完全な静的HTMLとして配信される「海」で、ここはJavaScriptを必要としません。その中に検索ボックス、コメントフォーム、価格計算機、ライブチャットといった対話領域を「島」として配置し、それぞれの島が独立したJSバンドルでHydrateされます。
従来のSPA/SSRが「ページ全体をひとつのJSアプリ」として扱うのに対し、Islandsでは「海部分にはJSを配らない」「島ごとにJSを完結させる」という発想が肝です。ある島で例外が起きても他の島には影響せず、ユーザーから見ると壊れたコンポーネントだけが動かないだけで済みます。海と島をつなぐ「橋」は、Astroならclient:load・client:idle・client:visibleといったディレクティブで宣言され、「いつJSを評価し始めるか」をコンポーネント単位で細かく制御できる点が特徴です。
Astroが定着させた実装
Islands Architectureという言葉は2019年にKaty Decorah氏が個人ブログで使い始め、2020年にPreactチームのJason Miller氏（developit）が記事「Islands Architecture」で詳しく解説したことで界隈に浸透しました。実装として最初に注目を集めたのは2021年6月に公開されたAstroで、Fred K. Schott氏らが設計しました。AstroはMarkdownやReact/Vue/Svelteを混在させ、明示的にclient:*ディレクティブを付けた要素だけJSを送る設計を貫いています。
その後、Eleventy・Fresh（Deno発、2022年）・Marko 6・SolidStartなどもIslandsの考え方を取り込み、Next.jsもServer Componentsを使うことで部分的に同等の効果を得られるようになりました。Hugo・JekyllといったクラシックSSGの世界も、Astroの登場でモダンフレームワークと張り合えるようになり、「重いSPAの代わりにIslandsで作る」というアプローチがメディアやドキュメントサイトに広がっています。Islandsという用語が示すのは技術というよりは設計哲学で、目的は「JSの量を最小化して必要な対話だけ動かす」ことに尽きます。
Islands採用の判断基準
Islands Architectureが力を発揮するのは、コンテンツ閲覧が主目的で、対話要素が局所的に存在するサイトです。ニュース、ブログ、企業のオウンドメディア、ドキュメントサイト、ランディングページなどが典型例で、本文の中にだけ価格シミュレーターやコメント欄を埋め込むようなケースに向いています。逆に画面全体が連携して動くSaaSの管理画面や、状態が画面間で密に結びついたエディタには不向きです。
もう一つの強みは複数フレームワークの混在です。AstroはReact・Vue・Svelte・Solidを同じページで島として並べることが可能で、既存のVue製ウィジェットを残しつつ新規はReactで書くといった移行戦略にも使えます。ローエンド端末向けに「JSを最小化したい」要件が強い場合や、Core Web Vitalsが事業KPIに直結する案件では、Islandsの「必要分しか配らない」設計が体感速度に大きな差を生みます。ただし設計の自由度が低く、画面間の状態共有や複雑なルーティングが必要な案件では制約を感じやすい点に注意が必要です。
Server ComponentsやPartial Hydrationとの違い
Islands ArchitectureとReact Server Components（RSC）は目標が近く、しばしば混同されます。Islandsはファイル単位・コンポーネント単位で「これは島だ」と明示し、島の外には一切JSを配りません。RSCはツリー単位で「サーバ専用」「クライアント」をマーカー（'use client'）で切り分け、サーバ部分はそもそもクライアントに送られない設計です。両者ともJS配信量を減らす狙いは共通しており、表現の差はあれど同じ問題意識から生まれた解です。
Partial Hydrationは島やServer Componentsの実装手段の一つで、「ページ全体ではなく一部だけHydrateする」テクニックの総称として用いられます。つまりIslandsは設計哲学、Server Componentsは特定フレームワークの実装、Partial Hydrationは技法、という関係に整理できます。「コンテンツ中心のサイトを高速化したい」という共通課題に対し、AstroとNext.jsがそれぞれの流派で答えを出していると見ると、Webフロントエンドの2020年代以降の進化の方向性がよく見えてきます。
まとめ
Islands Architectureは「静的な海に対話の島を点在させる」フロントエンド設計で、2021年のAstroによって実装が普及しました。JS配信量を最小化しつつ必要なインタラクションだけ後付けする発想は、Server ComponentsやPartial Hydrationと並ぶモダンWebの中核トピックとなり、メディアやドキュメントの定番選択肢になっています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント