marimoはノートブックをPythonプログラムとして扱う

セルの順番ではなく依存関係で動く

marimoの中心は、セルを独立したメモ欄として並べる考え方ではありません。あるセルを実行すると、その値を参照するセルをmarimoが見つけ、依存する部分を自動で実行します。入力を変えた後に関係するセルを手で探して実行し直す作業を減らし、コードと出力、プログラムの状態をそろえる設計です。実行の根拠は画面上の配置ではなく、変数の参照関係にあります。

セルを削除したときは、そこで定義されていた変数もメモリから取り除かれます。前に実行したセルの値だけが残る隠れた状態を減らせるため、上から順に実行したときだけ動くノートブックを見つけやすくなります。ただし、依存関係を自動で解決する仕組みがあるからといって、外部ファイルやネットワークの状態まで自動で固定されるわけではありません。READMEが説明する再現性の範囲と、各データ源の条件は分けて考えるべきです。

高コストの計算には遅延実行を選べる

依存セルを自動で動かす方式は、軽い変換や可視化では扱いやすい一方、数時間かかる学習や大規模な集計には負担になり得ます。marimoはランタイムをlazyに設定でき、影響を受けるセルを直ちに実行せずstaleとして印を付けるモードを用意しています。状態の関係を保ちながら、入力を触っただけで高価な処理が走る事態を避けるための選択肢です。

ここでの判断は、常に自動実行するか、常に手動実行するかの二択ではありません。探索初期は反応的に結果を確認し、計算量が見えた段階で遅延モードへ切り替えるという使い分けができます。staleの意味や再実行のタイミングは、チーム内で共有しておく必要があります。READMEはこの設定の存在を示していますが、特定の処理がどれだけ高速になるかというベンチマークは掲載していません。

純粋なPythonファイルがGitの単位になる

marimoのノートブックは.pyファイルとして保存されます。専用形式のJSONにコード、出力、実行状態を閉じ込めるのではなく、通常のPythonソースとして扱えることがGitとの相性を作っています。ノートブックはpython your_notebook.pyでスクリプトとして実行でき、CLI引数を受ける形にもできます。レビュー、差分確認、モジュール化の入口を、既存のPython開発の習慣に近づけられます。

JupyterのipynbをmarimoのPythonへ変換する例もREADMEにあります。移行の初手は自動変換で作り、セルの依存関係、表示処理、マジックコマンドなどを確認する流れになるでしょう。変換できることと、元のノートブックが同じ結果になることは別です。特に実行順、暗黙の変数、外部カーネルに依存する処理は、変換後に手動確認が要ります。SQLを含むノートブックも保存形式としてはPythonのままだと説明されています。

SQLとデータフレームを同じ流れで扱う

marimoはPythonの値をSQLクエリへ渡し、データフレーム、データベース、データレイクハウス、CSV、Google Sheetsなどを問い合わせる流れを示しています。組み込みのSQLエンジンが結果をPythonのデータフレームとして返すため、SQLで絞り込んだ結果をそのままPythonの可視化や後処理へつなげられます。SQLとPythonを別のノートブックへ分割する必要を減らすことが狙いです。

データフレームの表示では、コードを書かずにページ送り、検索、フィルター、並べ替えができ、READMEは数百万行を対象にした操作も紹介しています。この表現はプロジェクト側の説明であり、利用環境でのメモリ使用量や応答時間を保証する測定値ではありません。大きなデータを扱うときは、読み込み方式、接続先の性能、フィルターが実際にどこで実行されるかを検証したほうがよいでしょう。SQLの接続情報や権限管理の詳細も、提示されたREADMEだけでは分かりません。

UI部品が変数とセルをつなぐ

スライダー、ドロップダウン、データフレーム変換部品、チャットインターフェースなどをPythonの値へ結び付けられます。利用者が部品を操作すると、その値を使うセルが最新の状態で再実行されるため、コールバックを手書きして画面と計算を同期させる構成を避けられます。分析パラメーターをスライダーで変えながら図を更新するような探索に、仕組みが合っています。

Python変数を埋め込んだMarkdownも使えます。説明文、数値、表を同じデータから組み立てられるため、計算結果だけでなく解釈の文章も入力に応じて変えられます。これは自由なWebアプリ開発の代わりになるという意味ではありません。READMEは部品の種類と連携の方向を説明していますが、複雑な状態管理、認証、長時間処理の画面設計については詳しく述べていません。必要なUIが単純な入力と再計算で表現できるかを先に切り分けるのがよいでしょう。

パッケージ管理と隠れた状態への対処

再現性を支える要素として、marimoは隠れた状態を持ちにくい実行、決定的な依存関係、組み込みのパッケージ管理を挙げています。主要なパッケージマネージャーに対応し、インポート時のインストールや、ノートブック内へのパッケージ要件の保存、分離されたvenvサンドボックスへの自動導入もREADMEに記載されています。ノートブックを開いた人が手作業で環境を作る量を減らす方向です。

一方、依存パッケージを自動導入できることは、依存先の安全性や長期的な再現を無条件に保証しません。バージョン、OS、ネイティブライブラリ、外部データの更新を別に管理する必要があります。READMEはテスト用にpytestでノートブックを実行できるとも説明していますが、この文章では実際のテスト構成までは確認できません。共有用の環境を作るなら、保存された要件とロック戦略をリポジトリの運用規則へ組み込むのが現実的です。

スクリプト、Webアプリ、WASMへの展開

同じノートブックを用途に合わせて複数の形で動かせます。python your_notebook.pyなら通常のPythonスクリプトとして、marimo run your_notebook.pyならPythonコードを隠し、編集できないインタラクティブなWebアプリとして実行できます。スライドレイアウトも用意され、ブラウザー上ではWASMを使った実行が案内されています。分析の途中経過をコード付きで保存し、必要な部分だけを他者へ見せる道筋が一つの形式から生まれます。

mo.labはブラウザーで使う無料のオンラインノートブックとして紹介され、例、ギャラリー、公式ドキュメントも提供されています。AI連携では、marimo pairを使ってClaude Code、Codex、OpenCodeなどのエージェントと協働でき、エディタ内のAI補完では独自のシステムプロンプト、利用者のAPIキー、ローカルモデルを選べるとREADMEは説明します。AI機能へ渡すデータやキーの境界、WASMで利用できるPythonパッケージの範囲は記載だけでは確定しないため、組織の情報管理規則に照らして試験する必要があります。

エディタの選択肢とプロジェクトの位置付け

marimoのエディタには、GitHub Copilot、AIアシスタント、Ruffによる整形、HTMLエクスポート、高速な補完、変数エクスプローラー、vimキーバインドなどが挙げられています。専用エディタだけに閉じず、VS CodeとCursorの拡張、PyCharmのプラグイン、neovimやZedを含むテキストエディタでの編集にも触れています。チームが既に使っているエディタを捨てずに導入できるかを検討しやすい構成です。

リポジトリはApache-2.0で公開され、READMEはNumFOCUSの関連プロジェクトであること、Pluto.jl、ObservableHQ、Bret Victorの文章から影響を受けたことを記しています。米国DOEの支援への言及もあります。これらはプロジェクトの背景であって、セキュリティ保証、サポート期間、性能ベンチマークを意味しません。掲載された事実と利用者側で必要な評価を分け、社内データを扱う前に認証、実行権限、依存パッケージ、公開方法を確認するのが適切です。

編集部の結論

marimoは、分析結果だけでなく実行順序と環境もリポジトリで管理したいPython利用者に向きます。セルの依存関係を自動追跡するため、手動実行に慣れた人は動作の変化を理解する必要があります。データの規模、外部サービスへの接続、AI機能へ渡す情報、WASMで使えるライブラリの範囲は個別に確認し、まず小さな既存ノートブックを移して再現性を確かめるのが現実的です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes