💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「ノートブック」という言葉が指すものは多すぎる

2026 年、データ分析者・ML エンジニア・学生・研究者がそろって「ノートブック」と呼ぶものは、実は 4 種類の異なるツールだ。

- **クラシックノートブック** — Jupyter Lab 5 / Notebook 7、VSCode Notebooks。セルを上から順に実行し、状態はカーネルが保持する。

- **リアクティブノートブック** — Marimo、Observable Framework、Pluto.jl。セル間の依存関係をグラフとして追跡し、1 つのセルを変更すれば下流セルが自動で再実行される。

- **出版システム** — Quarto、R Markdown、Curvenote。ノートブックを PDF・HTML・論文・書籍にレンダリングする。

- **協業型 SaaS** — Deepnote、Hex。クラウドホスティング、チームでの同時編集・共有・スケジュール実行。

これら 4 つは「.ipynb」拡張子を共有することもあるが、解こうとしている問題が異なる。そして 2026 年現在、どれも他を吸収していない — むしろ各カテゴリ内での競争が激化している。

本稿はその地図を描く。Jupyter 陣営の安定化、Marimo の挑戦、Quarto が築いた出版パイプライン、Observable Framework の静的サイト戦略、そして 2 つの SaaS 軸(Deepnote / Hex)。最後にカカオ・トス・Mercari・ZOZO が実際にどう使っているかまで。

1. 2026 年のノートブック地図 — 4 分類

| --- | --- | --- | --- | --- |

要点: **「ノートブック」という一語で異なるカテゴリ同士を比較すると、必ず誤った結論になる。** 「Marimo は Jupyter より優れている」はリアクティブ vs クラシックの文脈でだけ意味があり、「Hex は Quarto より優れている」はカテゴリ自体が異なる。

もうひとつ: **言語生態系が選択の半分を決める。** R ユーザーは自然と RStudio → Positron / Quarto に流れる。Julia ユーザーは Pluto.jl。JS・D3 ユーザーは Observable。Python は全カテゴリに存在する — だからこそ Python ユーザーは選択肢が一番多く、一番混乱する。

2. Jupyter Lab 5 + Notebook 7 — 標準の定着

2024 年に JupyterLab 5 が正式リリースされ、Lab 4 時代の遺物(旧拡張機構、jupyter-server の競合)は綺麗に片付いた。2026 年現在 Lab 5 は以下を安定して提供する。

- **連合型拡張機構(Federated extensions)** — npm ビルドなしで pip install のみで導入。

- **JupyterLab Desktop** — Electron ベースの単独デスクトップアプリ、Anaconda 依存なし。

- **リアルタイム協業(RTC)** — y-py ベースの同時編集、Lab 4 で実験段階だった機能が安定化。

- **AI アシスタント統合** — jupyter-ai 4.x でセル単位の LLM 呼び出しが一級市民。

Notebook 7 は「クラシック Notebook の UI を Lab の上に載せたもの」。UI は昔ながらの Jupyter だが、バックエンドは Lab と同じ jupyter-server。教育市場が今も「Lab UI は複雑だ」と感じるため残っている。

それでも残る問題 — 隠れた状態

Jupyter の本質的な弱点はセル実行順だ。次のパターンを見たことがあるだろう。

セル 1

x = 10

セル 2

y = x * 2

セル 3

x = 100 # 後から追加

セル 1 → 2 → 3 の順に実行すれば y = 20 になる。保存して開き直し、セル 3 → 2 → 1 の順に実行すれば y = 200 になる。**同じノートブック、異なる結果。** これが隠れた状態だ。

さらに、セル 3 を削除しても x = 100 はカーネルメモリに残る。「Restart kernel and run all」を押すまで真実はわからない。データ分析レポートがこの罠に落ちると、「再現できない分析」になる。

2018 年から問題は指摘されており、いくつもの解決案が出てきた(papermill、nbdev、jupytext)。2024 年、Marimo が正面から答えを出した — 「ならばランタイムをリアクティブに作り直そう」。

3. Marimo(2024 年 6 月公開) — リアクティブ + .py ファイル形式

Marimo は Akshay Agrawal と Myles Scolnick による。2024 年 6 月一般公開、同年シードラウンド完了。中核アイデアは 2 つ。

1. **リアクティブな実行グラフ** — セル間の変数依存を追跡し、1 つのセルを変更すれば影響を受ける全セルが自動で再実行される。スプレッドシートのように。

2. **.py ファイル形式** — ノートブックが純粋な Python ファイル。JSON ではない。git diff が綺麗に出て、IDE からそのまま import 可能。

my_notebook.py — Marimo ノートブック

__generated_with = "0.10.0"

app = marimo.App()

@app.cell

def __():

return pd,

@app.cell

def __(pd):

df = pd.read_csv("data.csv")

return df,

@app.cell

def __(df):

df.describe()

return

ノートブック全体が 1 つの .py ファイルになっている。セル間の変数が関数の引数・戻り値として明示されるので、依存グラフが静的に追跡できる。

隠れた状態が消える

- セル 3 で `x = 100` を作ると、x を使うセル 2 が自動再実行 → y = 200。

- セル 3 を削除すると x はなくなる。他のセルで x を参照していればすぐエラー表示。

- 「Restart and run all」は不要。あらゆる時点で「画面の状態 = コードを最初から実行した結果」が保証される。

その他の機能

- `marimo run` — ノートブックをそのままインタラクティブな Web アプリとして実行。Streamlit のような別コード不要。

- `marimo edit` — 編集モード。Lab とほぼ同じ UI。

- WASM ランタイム — ブラウザで Pyodide により実行。サーバーなしでノートブック共有。

- AI アシスタント — Claude・OpenAI モデル統合、セル単位呼び出し。

弱点

- Jupyter に比べ生態系が小さい。ipywidgets 互換性は部分的。

- 「1 セル = 1 関数」の構造のため、グローバル変数に慣れた人は窮屈に感じる。

- 同じ変数名を 2 つのセルで再定義するとエラー — Jupyter のような「最後のセルが勝つ」挙動ではない。

2026 年の Marimo の位置付け: **Jupyter を置き換えてはいないが、新規 ML / データプロジェクトでは徐々にデフォルト化している** — 特に再現性を重視する研究室・MLOps チームで。

4. Quarto(Posit) — R / Python / Julia 統合出版

Quarto は、RStudio が 2022 年に会社名を Posit に変更した際に発表した次世代出版システムだ。R Markdown の後継として始まり、2026 年現在は R・Python・Julia・Observable JS をひとつの文書に混在させられる出版パイプラインになっている。

.qmd — すべてのソース

title: "月次売上分析"

format:

html:

toc: true

pdf:

pdf-engine: xelatex

docx: default

データの読み込み

df = pd.read_csv("sales.csv")

df.head()

可視化

library(ggplot2)

ggplot(df, aes(month, revenue)) + geom_line()

同じ .qmd 内で Python と R のセルを混在させ、`quarto render` で HTML / PDF / Word / EPUB を出力。学術論文(quarto-academic)、書籍(Quarto Book)、ウェブサイト(Quarto Website)も同じツールで生成。

Pandoc + Jupyter の上のレイヤー

内部的に Quarto は Jupyter カーネルでセルを実行し、結果を Pandoc Markdown にシリアライズしてから、Pandoc が最終形式を生成する。つまり **Quarto は新しいノートブックランタイムではなく、出版オーケストレーター**である。

2026 年の位置付け

- 大学の統計講義の新標準 — R Markdown をほぼ完全に吸収。

- データサイエンティストの成果共有 — Jupyter notebook を PDF にする手段として最も使われる。

- 政府・金融レポート — PDF 出力が一級市民であるため。

弱点

- ビルドが遅い。Pandoc + LaTeX チェーンが重い。

- インタラクティブ要素は Observable JS または Shiny に依存 — 自前の UI ウィジェットは弱い。

- 初期セットアップが面倒 — quarto CLI + TinyTeX + 言語ランタイム。

5. Observable Framework — Mike Bostock の静的サイトジェネレーター

Mike Bostock(D3.js 作者、Observable 創業者)が 2024 年に発表した Observable Framework は、「ノートブック = 静的サイトジェネレーター」というモデルだ。既存の Observable Cloud(observablehq.com 上でホストされるインタラクティブノートブック)とは別の OSS プロジェクト。

中核アイデア — データローダー

- Markdown ファイルに JavaScript コードセルを混在。

- ビルド時に「データローダー」(Python・R・shell — どの言語でも)を実行し、結果を静的 JSON・Parquet として保存。

- クライアントは静的データを D3・Plot で可視化。サーバーランタイム不要。

title: 売上ダッシュボード

const sales = FileAttachment("data/sales.parquet").parquet();

月次売上

Plot.plot({

marks: [

Plot.line(sales, {x: "month", y: "revenue"})

]

})

別ファイル `data/sales.parquet.py` がビルド時に実行されデータを生成。

誰のためのツールか

- データジャーナリスト — NYT・FT のグラフィックスチームが実際に使う。

- 社内ダッシュボード — 静的サイトなのでホスティングが安く高速。

- BI ツールを作るのは嫌だが可視化品質は妥協できないチーム。

弱点

- 「ノートブック」というより「静的サイトビルダー」。インタラクティブ分析ツールではない。

- Python・R はデータローダー内のみ。本流は JS。

- D3・Plot の学習コストが急。

2026 年現在、Observable Framework は **可視化が中心となるプロジェクトの新標準** になりつつある。一般的な分析には使わない。

6. Deepnote — 協業型クラウドノートブック

Deepnote はチェコ・米国を拠点とする SaaS、2019 年創業。2024-2025 年に OpenAI が後続シリーズ B に参加。中核価値は協業。

特徴

- ブラウザでの同時編集 — Google Docs のように。

- Snowflake・BigQuery・Postgres などのデータソースに直接接続、セルから SQL 実行。

- チャートセル — コードなしでドラッグ&ドロップ可視化。

- スケジュールノートブック — ノートブックを cron のように定期実行。

- 権限モデル — ワークスペース・プロジェクト・セル単位の権限。

誰が使うか

- データサイエンティストが PM・分析者と共有する必要がある場合。

- Notion + Slack 文化の会社 — Deepnote がその流れに合う。

- 「Snowflake のクエリ結果を毎週自動で受け取りたい」要件。

弱点

- ロックイン — .ipynb への export はできるが、チャートセル・variables explorer 等は Deepnote 専用。

- 価格 — チームプランが 1 名月額 30 ドル超。

- 重いコンピュートは別途 — 大規模 GPU ジョブは Modal・Beam で実行し、結果のみ Deepnote に取り込むパターン。

7. Hex — データサイエンティスト向け SaaS

Hex(サンフランシスコ、2019 年創業)は Deepnote の直接の競合だ。2024 年に Snowflake が一部出資したと報じられた。ポジショニングは似ているが、強調点が異なる。

| 観点 | Deepnote | Hex |

| --- | --- | --- |

| 中核ユーザー | データサイエンティスト + 分析者 | データサイエンティスト + BI |

| 協業 | 強い | 強い |

| SQL · Python 統合 | 良い | 非常に良い — SQL 結果が Python df に自動連携 |

| Magic AI | あり(基本) | 非常に強い(Hex Magic) |

| アプリ化 | Notebook → app 変換 | Notebook → app 変換(アプリが一級市民) |

| 価格 | 中 | 高 |

| 韓国・日本市場 | 中 | 低 |

Hex の差別化要素

- **Hex Magic** — セル単位 AI アシスタントが最もスムーズ。SQL → Python 変換、チャート生成、デバッグまで。

- **App mode** — ノートブックをそのままインタラクティブアプリとしてデプロイ。Streamlit 代替。

- **Magic SQL** — 自然言語から SQL、dbt モデル認識。

弱点

- 価格が高め — エンタープライズ向け。

- 韓国・日本での営業力が弱い — 英語圏の会社中心。

8. Curvenote / Polars Notebook / Pluto.jl — その他注目

Curvenote

科学出版に特化したノートブック + 協業ツール。MyST Markdown(Markdown の科学拡張)をベースに、引用・数式・figure ラベルを一級サポート。arXiv・ジャーナルへの PDF 投稿用ワークフロー。

Polars Notebook

Polars(高速 DataFrame ライブラリ)チームが 2025 年に発表した新ノートブックプロジェクト。Rust バックエンドでインメモリ DataFrame 操作が高速、SQL・Python・Polars expression が 1 ノートブックでスムーズに混在。まだベータ。

Pluto.jl

Julia 生態系のリアクティブノートブック。Marimo と同じ哲学(セル依存グラフ、.jl ファイル形式)を 2019 年から Julia 世界で実装してきた先輩格。Julia ユーザーならほぼデフォルト。

Jupytext

Jupyter .ipynb と .py / .md / .Rmd の双方向変換。「Jupyter を使いつつ git diff は綺麗にしたい」チームの解。Marimo 登場前は最も一般的な解決策で、現在も広く使われる。

9. VSCode Notebooks + Positron(Posit、2024 年 5 月) — IDE ノートブック

VSCode Notebooks

VSCode は 2020 年から .ipynb を一級サポート、2026 年現在は JupyterLab とほぼ同等の機能。Python 拡張 + Jupyter 拡張の組み合わせでセル実行・デバッグ・変数インスペクタ・プロットビューアが揃う。**AI アシスタント統合(Copilot、Cursor、Cline など)が最も自然** — これが VSCode をノートブック環境として選ぶ最大の理由。

Positron — RStudio の後継

Posit が 2024 年 5 月に公開した次世代 IDE。RStudio が R 中心だったのに対し、Positron は R と Python を対等に扱う。VSCode の OSS ベース(Code OSS)を fork したもの。

特徴:

- R と Python のコンソールが別パネルで常設。

- データビューア — DataFrame をスプレッドシートのように検査。

- プロットビューア — 左サイドパネルでチャート履歴管理。

- IDE 内で Jupyter カーネル直接実行。

- 2025 年に 1.0 GA、2026 年現在は安定版。

誰がどこへ向かうか

| ユーザー | 推奨 |

| --- | --- |

| R ユーザー(統計・疫学・金融) | Positron — RStudio の流れそのまま |

| Python + AI 統合重視 | VSCode(+ Cursor / Cline) |

| Python + RTC 協業重視 | JupyterLab 5(RTC) |

| R + Python の両方を日常的に | Positron |

10. 「隠れた状態」問題とリアクティブの答え

隠れた状態はノートブックの最大の罠だ。整理すると。

問題の本質

1. セルが任意の順序で実行されうる。

2. カーネルメモリはコードより長く生きる — セルを削除しても変数は残る。

3. 同じ変数名を複数セルで再定義すると、どの定義がアクティブかコードからわからない。

これらが組み合わさると、**「このノートブックを最初から実行し直したら同じ結果になるか?」に自信を持って答えられない** 状態になる。

解決策 1 — 規律(Jupyter 陣営)

- ノートブック commit 前に必ず「Restart kernel and run all」。

- 1 セルに 1 関数だけ定義、グローバル変数は最小限。

- nbQA で ruff・black 検査、nbdev でノートブック → ライブラリ変換。

- 弱点: 人間の意志に依存。実際にはよく破られる。

解決策 2 — リアクティブランタイム(Marimo · Observable · Pluto.jl)

- セル依存グラフを静的追跡。

- 1 セル変更で下流セルを自動再実行。

- 変数再定義はエラーで遮断 — 曖昧さを排除。

- 結果: **「今見ているセルの状態 = コードを最初から実行した結果」が常に保証される**。

解決策 3 — 永続成果物を分離(Quarto · Papermill)

- ノートブックは入力、レンダリング後の HTML / PDF が成果物。

- 「最終成果物はレンダラーが最初から最後まで実行した結果である」という契約。

- 弱点: インタラクティブな探索には合わない。

2026 年の合意: **研究・分析コードはリアクティブで、出版は Quarto で、学習と実験は Jupyter で。** 1 つのツールがすべてをカバーするわけではない。

11. R Markdown → Quarto への移行

Posit が 2022 年に Quarto をリリースして以来、R Markdown は「メンテナンスのみで新機能は Quarto」という方針になった。2026 年現在、R ユーザーの Quarto 移行はほぼ完了している。

移行対応表

| R Markdown | Quarto 対応 |

| --- | --- |

| .Rmd | .qmd |

| YAML output: html_document | format: html |

| knitr::opts_chunk\$set() | execute: オプション |

| bookdown | Quarto Book |

| blogdown | Quarto Website |

| pkgdown | quartodoc(Python) — パッケージサイトは別ツールと併用可 |

| flexdashboard | quarto-dashboard(2024 リリース) |

変換ツール

- `quarto convert input.Rmd` — 自動変換。単純な .Rmd はほぼそのまま動く。

- 複雑なケース(独自 output format、child documents)は手作業必要。

なぜ移行するか

- 新機能(quarto-dashboard、Observable JS 統合など)が Quarto のみ。

- Python・Julia ユーザーが R ユーザーと同じツールを使える — 社内に両者がいる場合に有利。

- PDF 出力品質の向上 — Typst バックエンド対応が追加された。

12. 韓国 / 日本での実際の使われ方

カカオ — データノートブック環境

カカオのデータ組織は社内 Kubernetes 上で JupyterHub を運用している。ユーザー別コンテナ、GPU 要求・返却自動化、S3 互換オブジェクトストレージ統合。2024-2025 年に jupyter-ai 統合でセル単位 LLM 呼び出しが追加され、2026 年から一部チームが Marimo をパイロット。

特徴的なのは、社内データワークフロー(Airflow + DataHub)とノートブックが分離されており、ノートブックで作った分析は別途 Airflow DAG に移植しないと運用に乗らない点。これが韓国大企業の一般的なパターン。

トス — 分析環境

トス(韓国の金融アプリ)では、データ分析者は SQL 中心で働き、ノートブックはもう一段深く入る場面(コホート・異常値検知・ML 実験)で使う。JupyterHub + 社内 BI(Querypie 系)の組み合わせが標準。2025 年の求人公告に Hex 導入検討の痕跡があった。Magic SQL と協業機能が SQL 中心の分析者にとって魅力的。

Mercari — データチーム

東京本社のデータチームは GCP ベースで、BigQuery + Vertex AI Workbench(GCP がホストする Jupyter Lab)を長く使っている。2024 年から一部チームが Deepnote 導入 — 協業とスケジュールノートブックが必要な BI チームで。Quarto は社内リサーチレポートの標準フォーマットとして採用された旨のエンジニアリングブログがある。

ZOZO — データ・MLOps

ZOZO Research(ZOZO の R&D 組織)は Jupyter Lab + Kubeflow Notebooks の組み合わせで ML 実験を行う。社内 GPU クラスター上。論文発表用の結果は Quarto で整理 — 学会の PDF 投稿まで 1 パイプライン。2026 年に発表された推薦システム論文の一部はノートブック原本まで OSS 公開された。

APAC 企業の共通パターン

- 大規模運用は JupyterHub on Kubernetes — 社内インフラチームが管理。

- 協業重視の分析は Deepnote / Hex — ただし英語圏の会社が導入は早い。

- 出版・論文は Quarto — 特に R ユーザー比率が高い日本のアカデミアで強い。

- Marimo は 2026 年現在アーリーアダプター段階 — グリーンフィールドの新規プロジェクトで採用率上昇中。

13. 誰が何を選ぶべきか

状況別に整理。

学生 / 講義

- **初めての Python データ分析授業**: Jupyter Lab 5(または Google Colab)。

- **統計・R の授業**: RStudio または Positron、課題提出は Quarto。

- **再現性重視の授業**: Marimo — 隠れた状態問題に最初から遭遇しない。

個人のデータ分析

- **1 日に 1-2 回ざっと見て終わり**: Jupyter Lab 5 + jupytext(git diff が綺麗)。

- **結果を PDF・ブログに出版**: Quarto。

- **可視化が主成果物**: Observable Framework。

ML 研究

- **再現性 + 実験管理**: Marimo + Weights & Biases / Aim。

- **クラスター GPU 上**: JupyterHub on Kubernetes(社内)または Vertex AI Workbench / SageMaker Notebooks(クラウド)。

- **論文執筆まで**: Quarto + LaTeX。

チーム協業

- **小規模 + 無料優先**: Jupyter Lab 5 RTC。

- **データサイエンティスト + 分析者の協業**: Hex または Deepnote。

- **分析者 + PM の共有**: Deepnote(UI が非技術者に親しみやすい)。

データジャーナリズム · インタラクティブ可視化

- **Observable Framework** ひとつで完結。

- 次点: Quarto + Observable JS。

出版 · 論文 · 書籍

- **Quarto** — R・Python・Julia のどれでも。

- 科学出版特化: Curvenote。

R ユーザー

- **Positron**(または RStudio)+ Quarto。これが 2026 年の正解。

Julia ユーザー

- **Pluto.jl** + Quarto。

「ひとつだけ選ぶなら」

- Python · 一般分析者: **Jupyter Lab 5 + Quarto**。

- Python · 新規プロジェクト + 再現性: **Marimo**。

- R: **Positron + Quarto**。

- チーム + 会社予算: **Hex** または **Deepnote**。

- D3 好き: **Observable Framework**。

14. 参考 / References

Jupyter

- [JupyterLab Documentation](https://jupyterlab.readthedocs.io/)

- [Jupyter Notebook 7 announcement](https://blog.jupyter.org/notebook-7-0-released-9663b73da722)

- [JupyterLab Desktop](https://github.com/jupyterlab/jupyterlab-desktop)

- [jupyter-ai](https://github.com/jupyterlab/jupyter-ai)

Marimo

- [Marimo official site](https://marimo.io/)

- [Marimo GitHub](https://github.com/marimo-team/marimo)

- [Marimo launch announcement (2024-06)](https://marimo.io/blog/announcing-marimo)

- [Marimo Why blog](https://marimo.io/blog/python-not-json)

Quarto / Posit / Positron

- [Quarto documentation](https://quarto.org/)

- [Quarto Dashboards](https://quarto.org/docs/dashboards/)

- [Positron IDE](https://positron.posit.co/)

- [RStudio rebrands to Posit](https://posit.co/blog/rstudio-is-now-posit/)

- [R Markdown to Quarto migration](https://quarto.org/docs/faq/rmarkdown.html)

Observable

- [Observable Framework](https://observablehq.com/framework/)

- [Observable Plot](https://observablehq.com/plot/)

- [Mike Bostock - Why we built Framework](https://observablehq.com/blog/observable-2-0)

Deepnote / Hex

- [Deepnote](https://deepnote.com/)

- [Hex](https://hex.tech/)

- [Hex Magic AI](https://hex.tech/product/magic-ai/)

その他

- [Curvenote](https://curvenote.com/)

- [Pluto.jl](https://plutojl.org/)

- [Polars Notebook](https://github.com/pola-rs/polars)

- [Jupytext](https://github.com/mwouts/jupytext)

- [Papermill](https://github.com/nteract/papermill)

- [nbdev](https://github.com/AnswerDotAI/nbdev)

比較 / 解説

- [Marimo vs Jupyter (Marimo blog)](https://marimo.io/blog/lessons-learned-rebuilding-jupyter)

- [Joel Grus - I Don't Like Notebooks (2018 JupyterCon talk)](https://www.youtube.com/watch?v=7jiPeIFXb6U)

- [Quarto vs R Markdown (Posit blog)](https://posit.co/blog/announcing-quarto-a-new-scientific-and-technical-publishing-system/)

韓国 · 日本の事例(ブログ · 発表)

- [カカオデータ分析環境 (tech.kakao.com)](https://tech.kakao.com/)

- [トスデータエンジニアリング (toss.tech)](https://toss.tech/)

- [Mercari Engineering Blog](https://engineering.mercari.com/en/blog/)

- [ZOZO Tech Blog](https://techblog.zozo.com/)