はじめに

最近、Jupyter notebookの課題を解決するためのPython notebookとしてmarimoが注目されています。

docs.marimo.io

2024年12月頃からXでちらほらmarimoの話題を目にするようになりました（執筆時点ではSNSにおける話題性は少し薄れてきた印象です）。GitHubスター数の増加からもmarimoの人気が伺えます。

Jupyter notebookとmarimoのGitHubスター数の比較（リンク）

本記事では、次世代notebookであるmarimoに入門しつつ、Jupyter notebookとの比較を通してmarimoのメリットや使用感を簡単に紹介します。

はじめに
1. marimoの概要
2. marimoとJupyter notebookの比較
3. marimoのデプロイ戦略
まとめ

1. marimoの概要

github.com

百聞は一見に如かず。

手元で以下のコマンドを実行するか、提供されているオンラインのplaygroundでまずは試してみましょう。

$ python -m venv venv && . ./venv/bin/activate && pip install marimo && marimo tutorial intro

チュートリアルを一通りやってみると、おおよその感覚が掴めます。

上図では、ドロップダウンやスライダーの変更によって別のセルにある表示も変更されていることが分かります。marimoではセルの順序や実行順序は関係なく変数を参照しているセルがあれば自動的に再実行されるため、再現性が担保されています。

公式ドキュメントでreactive Python notebookと表現されている通り、marimoではセルを1つ1つ実行するという概念すらも忘れてしまいそうです。私たちが手動で実行する必要があるのは、変更を加えようとしているまさにそのセルのみということになります。

marimoの特長は他にもありますが、そのうちいくつかを簡単に紹介します。

Python スクリプトとして実行可能で、argparseなどでコマンドライン引数も取れる
CLIからWebアプリとしてデプロイでき、セル出力のみを結合したVerticalレイアウト、編集可能なGridレイアウト、スライドショーのようなSlidesレイアウトを切り替え可能
WASM notebooksとしてPythonのインストールを必要とせずにデプロイ・共有が可能
接続したデータベースに対して直接セルにSQLを書いてDataFrameを取得したり、その出力のDataFrameに対してSQLを書いたりできる
Python スクリプトとして保存されるため、Gitフレンドリー
GitHub Copilotなどによるコード補完やAIアシスタント（ただしOpenAIやAnthropic、Google AIのAPIキーが必要）が利用可能

GitHub Copilotについては、Jupyter notebookでもVSCodeで.ipynbファイルを開く場合は利用できますが、jupyter notebookコマンドで起動したWeb UIからは利用できません*1。

アイデアの迅速なプロトタイピングを可能にするという観点では、Python notebookもVibe Codingも共通のニーズに応えられるので、コード補完やAIアシスタントをサポートしていることはmarimoの大きな武器になっていると考えました。

2. marimoとJupyter notebookの比較

marimoの公式ドキュメントのFAQに「marimoはJupyterとどう違いますか？」という項目があります。

docs.marimo.io

公式ドキュメントと同じことは述べませんが、文章を読むのが億劫だと感じる方のために簡単な表にまとめました（適宜文脈を補っています）。

	marimo	Jupyter	備考
再現性	○	×	marimoは状態一貫性を担保。Jupyterは削除されたセルの変数の参照や実行順序の自由さが再現性を損ねる要因。
インタラクティブ性	○	△	marimoは標準搭載。Jupyterは`ipywidgets`等で実現可能だが設定が必要。
Gitとの相性	○ (`.py`)	△ (`.ipynb`)	marimoはPython スクリプトとして保存。JupyterはJSON形式でGit差分が見づらい。
再利用性	○	△	marimoはそのままPython スクリプトとして実行可能。Jupyterはスクリプト実行に追加処理が必要。
パッケージ管理	○	△	marimoはパッケージ要件をnotebookに含めるためコマンド1つで仮想環境として再現可能。Jupyterは外部管理が一般的で再現性がない傾向。
共有可能性	○	△	marimoはコマンド1つでインタラクティブなWebアプリとして公開可能。Jupyterは`voila`などの利用が必要。

marimoのドキュメントなので必然的にmarimoの短所は取り扱っていませんでした。とは言え、marimoが「Python notebookの課題を解決するための再開発」である点からもJupyter notebookの多くの課題が解決されていると言えるでしょう。

強いてmarimoがJupyter notebookに劣っている点を挙げるとするならば知名度が挙げられます。Jupyter notebookは大学の講義や研究機関でも広く採用されています。marimoはCLIやWeb UI上でJupyter notebookとの相互変換もサポートしていますが、今後どれだけ普及するかがカギになりそうです。

3. marimoのデプロイ戦略

今後、研究室内または社内で「marimoをデプロイしたい」というニーズが高まるかもしれません。

この章では、以下の公式ドキュメントを参考にmarimoのデプロイ方法を簡単に紹介します。

docs.marimo.io

代表的なデプロイ方法は以下の3種類です。

edit server（編集可能なnotebook）：marimo editコマンドで起動
run server（read-onlyなWebアプリ）：marimo runコマンドで起動
programmatic（read-onlyなWebアプリ）：FastAPIを利用してASGIサーバーとして起動

read-onlyなWebアプリを公開したい場合、基本的には2.の方法で十分だと考えました。ミドルウェアや認証などを含めたい場合は3.の方法でカスタマイズする必要がありそうです。

編集可能なnotebookのデプロイとしては、大きく以下の4種類が紹介されていました。

With ssh-port forwarding, using marimo edit --headless.

Via docker and our prebuilt containers.

Via a deployment service such as Railway.

Behind JupyterHub.

1.はSSH接続さえできればリモートからアクセスできるということで、例えばScience TokyoのTSUBAME4.0でもSSHポートフォワーディングを使えばJupyter notebook同様にmarimoを利用できることになります。

2.については研究室や会社でセルフサービス形式でデプロイする時に活用できそうです。Prebuiltコンテナイメージはありがたいですが、ベースイメージのPythonは固定されているので多様なニーズに応えるためには結局イメージをカスタムする必要があります。

4.については、おそらく新規というよりも既にJupyterHubを運用しているチーム向けです。jupyter-marimo-proxyというパッケージを利用してJupyter上でmarimoを起動できるようですが、公式がメンテナンスしているものではないので本番運用は難しいでしょう。