Jupyterの「あるある」を根本解決する。次世代Pythonノートブック marimoを実務目線で解説

導入

PythonノートブックといえばJupyter Notebook。
ただ、現場で使っていると次のような「あるある」に遭遇しがちです。

• どの順でセルを実行したか分からなくなり、結果がズレる
• いったん動いてたのに、別の人が開いたら動かない（再現できない）
• .ipynb がGitで差分地獄（レビューしづらい／コンフリクトする）
• ウィジェットやダッシュボード化が「できるけど面倒」

marimo は、こうした問題を「運用の工夫」ではなく 仕組みで潰す ことを目標に作られた、オープンソースのリアクティブPythonノートブックです。
ノートブックを “その場の実験メモ”ではなく、再現可能なPythonプログラム として扱えるのが最大の特徴です。

この記事では、marimoの利点をかなり深掘りしつつ、Jupyter Notebookと比較して何がどう嬉しいのか を実務目線で整理します。

marimoとは何か（要点）

marimoは、次のような性質を持つノートブック環境です。

• ノートブックが 純粋なPythonファイル（.py） として保存される（Gitに強い）
• コードの依存関係を解析して データフロー（DAG） を作り、変更に応じて 必要なセルだけを自動再実行（リアクティブ実行）
• セル削除時に変数をメモリから掃除して 隠れ状態（hidden state） を抑制
• ノートブックを スクリプトとして実行 でき、アプリとして配信 もできる

一言でいうと、「ノートブックの手軽さ」＋「ソフトウェアとしての再現性・運用性」 を両取りしにいっているツールです。

なぜJupyter運用は破綻しやすいのか

marimoの価値を理解するには、Jupyterの“構造的な弱点”を押さえるのが早いです。

実行順が自由すぎて「状態」が壊れやすい

Jupyterは基本的にREPL的で、セルを好きな順で実行できます。
探索には便利ですが、順番が変わると結果が変わる／どこで定義された変数か不明といった問題の温床になります。

• 上流セルを変更したのに下流セルを再実行し忘れる
• 一度定義した変数が残ってしまい、コード上は消したのに動いてしまう
• ノートブックを開き直すと同じ状態を再現できない

この「状態の不透明さ」が、チーム開発や長期運用で効いてきます。

.ipynb（JSON）がGitレビューに向かない

.ipynb はJSONで、出力・メタデータも一緒に入るため、ちょっとした変更でも差分が巨大になりがちです。

• PRで差分が追いにくい
• マージコンフリクトが起きやすい
• 結果として「レビューしない」「バイナリ扱い」になってしまう

もちろん対処法（出力を消す、Jupytextで同期するなど）はありますが、運用コストが増えます。

marimoのコア：ノートブックを「データフロー（DAG）」として扱う

marimoは、セル間の変数参照を解析して DAG（有向非巡回グラフ） を作ります。
結果として「セルの位置」ではなく「依存関係」に基づいて実行順序が決まります。

イメージはこんな感じです。

• df を作るセルAを変えたら、下流（B,C,D,E）が必要に応じて更新される
• 実行順序は依存関係で決まるので、セルを説明の都合で並べ替えても壊れにくい
• 高コストなセルは「自動で毎回走らない」ように調整できる

この設計が、Jupyterの「とりあえずRun All」「順番ミス」「隠れ状態」に対する、marimo流の解決です。

まず触る：インストールと起動

pip install marimo

新規ノートブックを編集起動するなら：

marimo edit notebook.py

読み取り専用アプリとして配信するなら：

marimo run notebook.py

• edit は「編集モード」（ノートブックを作る）
• run は「実行モード」（成果物として配る）

この「同じファイルで編集と配布を切り替える」思想が、実務ではかなり便利です。

marimoノートブックは「Pythonファイル」そのもの（ここがデカい）

marimoのノートブックは .py です。概念としては、次のような構造になります。

import marimo

app = marimo.App()

@app.cell
def _():
    import marimo as mo
    return mo

@app.cell
def _(mo):
    x = 10
    y = x * 2
    mo.md(f"y = **{y}**")
    return x, y

if __name__ == "__main__":
    app.run()

ポイントは

• Pythonとして構文的に正しい（普通の.py）
• つまり ruff/black/mypy/pytest など既存のPythonツール群と相性が良い
• IDEの補完やリファクタも効かせやすい
• 「ノートブック→スクリプト化」の摩擦が小さい

Jupyterだと、ノートブックをプロダクトコードに寄せたくなった瞬間に壁が出がちですが、marimoは最初から“寄せやすい”設計です。

marimoの利点

ここからは「何が嬉しいのか」を深掘りします。
Jupyterとの比較を前提に読むと理解しやすいはずです。

利点1：リアクティブ実行で「出力と状態がズレない」

marimoは、セルを変更すると依存する下流セルが更新されます。
さらに、セルを削除した場合は、そのセルが定義した変数をメモリから取り除きやすい設計になっています。

Jupyterで起きがちなこと

• 変数が残り続けて“動いてしまう”
• 表示結果が古いまま残っている
• 実行順序の履歴で結果が変わる

marimoで嬉しいこと

• 「今のコード」に整合した状態を保ちやすい
• 下流だけ更新できるので、全実行の頻度が下がる
• ノートブックが壊れにくくなる（チーム運用で効く）

利点2：決定的な実行順序（セルの“位置”から解放）

marimoは「見せ方（ドキュメント）」と「実行順序（依存関係）」を分離します。
セルの位置ではなく変数参照で実行順が決まるため、ストーリーの流れに合わせて並べ替えても壊れにくいです。

• 説明を上に移動したら壊れた
• セルの順序に気を配るのがしんどい

こうした負債が減ります。

利点3：Gitに強い（差分が読める）

.py なので、小さな変更が小さなdiffになりやすいです。

• PRレビューで「何が変わったか」追いやすい
• コンフリクトが起きても人間が解決しやすい
• blameが機能する
• ノートブックを「チーム開発の成果物」にできる

Jupyterノートブックをプロジェクト資産として扱うとき、ここが本当に効きます。

利点4：スクリプトとして動く（CI/パイプラインに載せやすい）

marimoは「ノートブックなのにPythonプログラム」なので、

• python notebook.py のように実行できる
• argparse などでCLI引数を扱いやすい
• バッチ処理やCIに載せやすい

分析や実験が「ノートブック内で終わらず」そのまま運用側に寄せられます。

利点5：アプリとして配信できる（共有の摩擦が小さい）

同じファイルを marimo run すると、読み取り専用のWebアプリとして提供できます。

• 社内向けの分析ビューア
• 簡易ダッシュボード
• パラメータを動かして確認するUI

Jupyterだと別ツールに移植する流れになりやすいところを、marimoは「ノートブックの延長」でやれます。

利点6：UIが“リアクティブ前提”で素直（コールバック地獄になりにくい）

marimoはテキスト入力、スライダー、セレクト、テーブルなどを使ってUIを組めます。

（例：テキスト＋スライダーを使うイメージ）

import marimo as mo

name = mo.ui.text(label="名前", value="marimo")
age = mo.ui.slider(0, 100, label="年齢", value=30)

mo.md(f"こんにちは、**{name.value}**さん。年齢は**{age.value}**歳です。")

UIを動かすと、それを参照するセルが自然に更新されます。
Jupyterでもipywidgetsで似たことはできますが、状態管理や再計算の整合を自分でケアしがちです。marimoは最初から「依存関係で更新」なので、UIが素直です。

利点7：重いセルへの配慮（“勝手に学習しない”運用ができる）

リアクティブは便利ですが、学習や巨大クエリが「UI触っただけで毎回走る」と困ります。

marimoは、高コストセルを自動実行から外すなど、運用上の調整が可能です。
その結果、

• 軽い前処理や可視化はリアクティブに更新
• 学習や集計など重い処理は明示的なタイミングで実行

といった「実務で欲しい制御」がしやすくなります。

利点8：SQLとPythonの往復がスムーズ（データ作業が多い人に刺さる）

marimoはSQLセルを扱えるため、

• DuckDBなどでSQLを書いて集計
• Python（pandas等）で整形して可視化
• UIで条件を変えて再集計

といったワークフローを一つのノートブックで組みやすいです。

利点9：ノートブックを“資産化”しやすい（テスト・再利用の導線）

marimoの.pyは、普通のPythonコードとして扱いやすいので、

• 関数化・モジュール化しやすい
• lint/format/typecheckが回しやすい
• pytestを当てやすい

「実験コードが育って、いつの間にか業務ロジックになっていた」ケースでも、無理なく保守の土台に乗せやすいです。

Jupyter Notebookとmarimoの比較表

観点	Jupyter Notebook	marimo
実行モデル	セル順が自由（便利だが壊れやすい）	依存関係ベース（壊れにくい）
隠れ状態（hidden state）	起きやすい	起きにくい設計
ファイル形式	.ipynb（JSON）	.py（テキスト）
Git運用	diff/レビューがしんどい	diffが読める、レビューしやすい
共有・配布	HTML化 or 別ツール移植になりがち	runでそのままアプリ配布しやすい
CI/バッチ	可能だが運用工夫が必要	Pythonスクリプトとして載せやすい
エコシステム	圧倒的に成熟	成長中だが勢いがある

どんな人にmarimoが刺さるか

marimoがハマる人

• ノートブックを Git管理してチームで回したい
• 「セル順で壊れる」「隠れ状態」の事故を減らしたい
• 分析結果を そのまま社内向けアプリにしたい
• ノートブックを スクリプト化／CI化 したい
• SQL↔Pythonを日常的に往復する

まずはJupyterのままでも良い人

• 単独探索が中心で、成果物として残す比率が低い
• 既存のJupyter拡張・運用資産が強い
• 組織の文化やツールチェーンがJupyter前提で固まっている

移行・併用の現実解（全部置き換えない）

現実的には「全移行」よりも 併用 が強いです。

• 新規の分析・共有はmarimoで始める
• 既存のJupyter資産は無理に変えず、必要に応じて変換
• 成果物の共有は marimo run で配布する

この方針だと、導入がスムーズで失敗しにくいです。

まとめ

marimoは、Jupyter Notebookで起きがちな

• 実行順依存による再現性の低さ
• hidden state（消したはずの変数が残る等）
• .ipynb のGit相性の悪さ
• 共有やアプリ化の摩擦

を、リアクティブ実行（DAG）＋純Pythonファイル という設計で根本から改善しにいくノートブックです。

そして実務的に一番大きいのは、「ノートブックを成果物として育てられる」 こと。
探索で終わらず、レビューされ、CIに乗り、共有され、アプリにもなる。そういう“資産化”の導線が見えてきます。

まずはここから始めましょう。

pip install marimo
marimo edit notebook.py