はじめに
Astro と Quarto は、どちらも Markdown を出発点にコンテンツを公開できます。しかし、最適化している成果物は大きく異なります。Astro は高速なWeb体験を構成するためのWebフレームワークであり、Quarto は計算を伴う文書、分析、書籍、プレゼンテーションを再現可能に公開するシステムです。
2026年8月時点で、Astro の最新安定リリースは 7.2.4 です。7.2系では、変更のない静的ページを再利用する実験的な増分静的ビルドが導入されました。1 2 Quarto は 2026年8月に 1.10 を公開し、HTMLアクセシビリティ検査、ローカライズ済みテンプレート変数、Pandoc・Typst・Deno・Dart Sass・esbuildの更新を含めています。3
本記事では「どちらが優れているか」ではなく、誰が、どのような成果物を、どの程度の対話性・再現性・配布形式で届けたいかを基準に選びます。最後には、両者を競合させずに併用する構成も示します。
まず結論: 選ぶ基準は「主成果物」である
| 主に届けたいもの | 第一候補 | 理由 |
|---|---|---|
| 技術ブログ、プロダクトサイト、採用サイト、ドキュメントポータル | Astro | 画面設計、コンポーネント、必要箇所だけのクライアントJavaScript、SSR/APIへの拡張を一つのWebアプリ基盤で扱える。 |
| 分析レポート、再現可能な研究成果、講義資料、論文、書籍 | Quarto | コード実行、図表・数式・引用・クロスリファレンス、PDF/DOCX/EPUBを含む複数形式への出力を文書中心に扱える。 |
| 分析結果を読者向けのWeb体験として配信したい | Astro + Quarto | Quartoで分析成果物を生成し、Astroで閲覧導線、検索、補足記事、対話的UIを提供できる。 |
Astro は「Webページをどう組み立て、どこに対話性や動的処理を加えるか」に強みがあります。Quarto は「文章・コード・実行結果・図表・参考文献を、再実行可能な単位としてどう束ね、複数形式へ出力するか」に強みがあります。この違いを見失わなければ、選定は明確になります。
2026年8月時点の技術スタック
Astro 7.2 では、静的サイトの再ビルドで変更のないページを再利用する incremental static builds が実験的に追加されました。getStaticPaths() で cacheKey を返すルートだけが対象となり、Content Collections では entry.digest をキーに使えます。これは記事数が増えるブログやドキュメントサイトの継続的デプロイに関係する更新です。1
Quarto 1.10 は大規模な機能追加よりも保守性と品質を重視したリリースです。HTML出力での axe-core 検査をオフラインでも実行でき、WCAG適合レベルを指定できます。また、基盤コンポーネントとして Pandoc 3.10、Typst 0.15.1、Deno 2.7.14、Dart Sass 1.101.0、esbuild 0.28.1 が更新されています。3
| 観点 | Astro | Quarto |
|---|---|---|
| 基本モデル | JavaScript/TypeScriptを中心に、コンポーネントでWebを構成するフレームワーク。 | Pandocを基盤に、文書をレンダリングする出版・分析システム。 |
| 現行リリース基準 | astro@7.2.4。7.2の増分静的ビルドは実験的機能。 1 2 | Quarto 1.10。アクセシビリティ検査やテンプレートのローカライズが改善。 3 |
| 主な入力 | .astro、Markdown、MDX、JSON/YAML/TOMLなどをContent Collectionsで扱える。 4 | .qmd、.ipynb、.md、.Rmdなどをプロジェクトとしてレンダリングできる。 5 |
| 主な出力 | 既定では静的HTML。アダプタを加えればリクエスト時レンダリングとAPIエンドポイントも扱える。 6 | HTML、PDF、MS Word、EPUBなどの標準形式。Webサイト、書籍、文書、プレゼンテーション、ダッシュボードを生成できる。 7 8 |
| 中心となる強み | Web UI、コンポーネント、選択的ハイドレーション、サーバー機能への拡張。 | 再現可能な計算、図表・数式・参照、複数形式への文書出版。 |
比較軸 1: コンテンツのモデルと品質保証
Astro の Content Collections は、ローカルファイルだけでなく、CMS・データベース・APIから取得するデータもローダーを通じて扱えます。ビルド時コレクションは静的ブログやドキュメントに適し、頻繁に変わるデータにはライブコレクションを選べます。Zodスキーマを定義すれば、フロントマターやエントリーデータの形を検証し、TypeScriptの補完と型検査を得られます。4
Quarto では、文書の YAML フロントマター、Pandoc Markdown、プロジェクト設定の _quarto.yml がコンテンツの構造を担います。Markdownの表現力に加え、数式、図、表、コードリスト、節、定理といった対象へ番号付きのクロスリファレンスを付けられます。特に、図表番号と本文中の参照を保ちたいレポートや論文では、この文書モデルが有効です。9
判断: コンテンツのメタデータをアプリケーションの型として厳密に扱い、ページ・コンポーネント・外部データと結びたいならAstroが自然です。図表・数式・節を出版物として相互参照し、文章構造の一貫性を保ちたいならQuartoが自然です。
比較軸 2: 実行可能コードと再現性
Quarto の大きな特徴は、文書と計算を同じソースに置けることです。.qmd は、実行可能なコードブロックの内容に応じて Jupyter または Knitr を利用でき、OJSもサポートします。セルごとに実行、ソース表示、出力、警告、エラーを制御でき、Python・R・Julia等で生成した図表を文書へ含められます。5
たとえば、分析の前提、データ処理、可視化、結論を1つの文書としてレビューしたい場合、Quartoはコードと結果の対応を保ちやすくします。図や表にもラベルを付け、生成された出力を本文から参照できます。9
Astro は、コードを実行して分析結果を文書へ埋め込むためのノートブック環境ではありません。AstroのビルドではコンポーネントとコンテンツをHTMLへ変換します。その代わり、分析済みのJSON、API、CMS、静的ファイルを表示層へ組み込み、読者にとって使いやすいページや対話的な探索UIを作ることに向いています。分析そのものの実行履歴を成果物に残すことが第一目的なら、Quartoを選ぶ方が明快です。
比較軸 3: Web UIとインタラクティブ性
Astro は、ページの大部分を静的HTMLとして出力し、必要なコンポーネントだけにJavaScriptを送るアイランドアーキテクチャを採用しています。client:load、client:idle、client:visible といったディレクティブで、いつ対話的コンポーネントをハイドレートするかを選べます。10 React、Preact、Svelte、Vue、SolidJS、AlpineJSなどの公式連携も用意されています。11
このため、検索、フィルタ、ログイン状態に応じたUI、入力フォーム、データを探索するウィジェットなど、読者操作を中心に設計するページではAstroが適しています。さらに、アダプタを加えると、必要なルートだけをリクエスト時にレンダリングし、APIエンドポイントを実装できます。6
Quarto もダッシュボードやインタラクティブな出力を扱えますが、中心にあるのは「実行してレンダリングする文書」です。個別ユーザー向けの状態管理、複雑なフロントエンドコンポーネント、認証後の画面、独自APIを主要要件とする場合は、Astroや別のWebアプリ基盤を主軸にする方が設計を単純にできます。
比較軸 4: 出版形式と配布先
Quartoは、標準形式として出力されるHTML、PDF、MS Wordなどを任意の場所へ公開できます。quarto publish による公開に加え、GitHub Pages、Netlify、Posit Connect、Quarto Pub、CIを使った公開を案内しています。7 Webサイトプロジェクトでは、ナビゲーション、サイドバー、検索、テーマを共通設定で管理し、quarto render で既定の _site ディレクトリに出力します。8
Astroも静的HTMLを既定とし、GitHub Pagesなどの静的ホスティングへ適しています。一方で、動的なページが必要になった段階ではNode.js、Netlify、Vercel、Cloudflare向けのアダプタを追加し、静的ページとSSRを同じプロジェクトで併用できます。6
| 配布要件 | 適した選択 |
|---|---|
| 同じ原稿をHTML、PDF、DOCX、EPUBへ出したい | Quarto。文書の形式横断的な出力を中心に設計されている。 7 |
| 検索・フォーム・カード・ウィジェットを備えたWebサイトとして成長させたい | Astro。コンポーネントとアイランドを中心にUIを組み立てられる。 10 11 |
| レポートをGitHub Pagesで公開したい | どちらも可能。Quartoは文書を生成して公開し、AstroはWebサイトを生成して公開する。 7 8 |
ユースケース別の選び方
技術ブログ・製品ドキュメント・広報サイト
記事を中心にしつつ、検索、タグ、関連記事、フォーム、料金表、計測、軽いインタラクションなどを足す可能性があるなら Astro が適しています。Content Collectionsで記事のメタデータを型安全に扱い、必要になった箇所だけフレームワークコンポーネントを導入できます。4 10
データ分析レポート・研究論文・研修教材
RやPythonの分析を実行し、そのグラフ、表、数式、参考文献を本文とともに再生成したいなら Quarto が適しています。HTMLに限定せず、査読・提出・配布で必要になるPDFやDOCXへ出力できることも重要です。5 7 9
データプロダクト・インタラクティブな公開ダッシュボード
読者がデータを探索し、条件を入力し、状態に応じて画面が変化するならAstroを中心に検討します。分析処理は別のパイプライン、API、またはQuartoで生成した静的成果物として分けると、閲覧用Web UIと計算処理の責務を分離できます。
併用する: Quartoで生成し、Astroで届ける
選択肢は二者択一ではありません。たとえば、分析チームがQuartoでPythonまたはRのレポートを生成し、そのHTML・PDF・画像をビルド成果物として保存します。WebチームはAstroで概要ページ、カテゴリ、検索、関連する技術解説、ダウンロード導線を提供します。
データ / ノートブック
│
▼
Quarto render
├── 詳細なHTMLレポート
├── PDF・DOCXなどの配布版
└── 図表・データ成果物
│
▼
Astro Content Collections / public
├── レポートへの導線と解説記事
├── 検索・タグ・関連コンテンツ
└── 必要箇所だけの対話的UI
この分担では、Quarto が「計算と出版の再現性」を担い、Astro が「発見性と読者体験」を担います。両方のビルドをCIで実行する場合は、Quartoの実行環境、データ更新の契機、生成物の保存先、Astroのリンク切れ検査を明示し、分析と配信の境界を文書化してください。
Astro Outputにとっての判断
このリポジトリは、ローカルMarkdownを glob() ローダーで収集し、Zodスキーマで検証してから静的な記事ページへ生成する構成です。そのため、現在の目的である 技術記事を読みやすいWebサイトとして継続的に公開すること には Astro が適しています。
一方、将来「コード実行で再生成される分析」「番号付きの図表・数式を含む長いレポート」「PDFやDOCXでの配布」が主要要件になった場合は、Quartoを分析・出版レイヤーとして追加する価値があります。その場合でも、既存のAstroサイトを置き換える必要はありません。Quartoで生成した成果物への入口と解説をAstroで提供する、段階的な併用から始められます。
導入前の確認事項
| 確認する問い | Astroを選びやすい条件 | Quartoを選びやすい条件 |
|---|---|---|
| 誰が主に執筆するか | TypeScript/JavaScriptとWeb UIに慣れた開発者。 | R/Python/Juliaで分析や研究を行う執筆者。 |
| 成果物の正しさを何で担保するか | 型、スキーマ、コンポーネントテスト、WebのCIビルド。 | ソースコードの実行、図表・表の再生成、文書の参照整合性。 |
| 何を配布するか | Webページを中心に、必要ならAPIやSSRを追加する。 | Web・PDF・DOCX・EPUBなど、同じ原稿から複数形式を出力する。 |
| 読者は何をするか | 探索、検索、入力、フォーム送信、状態に応じたUI操作。 | 分析結果を読み、図表・数式・引用を追い、成果物を参照・ダウンロードする。 |
まとめ
AstroとQuartoは、Markdownを公開するという共通点がありながら、設計の中心が異なります。Astroは Web体験を設計するためのコンポーネント・アイランド・SSR基盤、Quartoは 計算と文章を結び、複数形式で再現可能に出版する基盤 です。
技術ブログやプロダクトサイトとして読者体験を育てるならAstro、分析・研究・教材を再実行可能な文書として届けるならQuartoを選びます。分析の信頼性とWebでの発見性を同時に求める場合は、Quartoで生成しAstroで届ける構成が有効です。自分たちの主成果物を最初に定義し、その成果物を更新・検証・配布する流れが最も短くなるツールを選びましょう。