はじめに

Python をブラウザで動かす WASM (WebAssembly) アプリ開発において、最大の障壁はロジックの複雑さではありません。
それは、「300px〜400px という極小のモバイル Viewport（表示領域）」と「フレームワークの物理的制約」の衝突です。

我々「Marimo App Project」が第11弾プロジェクト『Project Phoenix』で挑んだのは、初期の習作である住宅ローンシミュレーターを、プロ仕様の「高精度比較スイート」へとリマスターすることでした。

しかし、そこで待ち構えていたのは、CSS ハックすら弾き返す Shadow DOM の絶対防壁と、リアクティビティ（連動性）を維持しようとすればレイアウトが崩壊するという、構造的なデッドロックでした。

本記事では、この魔境を突破するために確立した独自の UI アーキテクチャを公開します。

1. 衝突：リアクティビティ vs レイアウト見切れ

marimo v0.23.1 を用いた高度なアプリ開発では、複数の入力コンポーネントを mo.ui.dictionary で束ね、一括して状態（State）を監視するのが定石です。
これにより、Python の DAG（有向非巡回グラフ）に「値の変更」を確実に検知させ、リアルタイムな再計算を実現します。

しかし、ここに WASM環境特有の罠 が潜んでいます。

Shadow DOM の絶対防壁

mo.ui.dictionary をそのまま画面にレンダリングすると、内部でテーブル状の Shadow DOM 構造が生成されます。
この構造は外部からの CSS 干渉をほぼ受け付けず、モバイル端末の 390px 程度の画面幅を無視して、物理的な最小幅（min-content）を維持しようとします。

その結果、入力フォームが Viewport を突き破り、ページ全体を巻き込んで「横見切れ」を誘発するのです。

2. 突破口：「The Reactive Ghost Protocol」

「通信（Reactivity）をとればレイアウトが死に、レイアウトを救えば通信が死ぬ」。
この二者択一に対し、我々が導き出した解が Reactive Ghost Protocol（リアクティブ・ゴースト・プロトコル） です。

このプロトコルの核心は、「状態監視の核」と「描画の皮」を物理的に切断することにあります。

Invisible State Layer (Backend):
mo.ui.dictionary を定義し、全シナリオの入力をバインドします。ただし、この辞書自体は画面に render しません。
Manual Extraction (Frontend):
描画用のパネルでは、辞書内から個別のコンポーネント（mo.ui.number 等）のみを直接取り出し、mo.vstack などでフラットに並べ直します。

これにより、「marimo のリアクティビティ（完全連動）」と「モバイルでの見切れゼロ」 を、一切の CSS ハックを使わずに、ネイティブコンポーネントの力だけで両立させました。

3. 1px の執念：幽霊カラムをパージする「The Zero-Index Protocol」

UI の見切れ問題は、データテーブルにおいても牙を剥きました。
mo.ui.table は強力なデータ探索機能を提供しますが、デフォルトで左端に Pandas のインデックス（行番号）を表示します。

この「空白のカラム」が、モバイル画面では 40〜50px もの無駄な空間を占有し、主要なデータの表示を阻害していました。
しかも、mo.ui.table である限り、このインデックス列は DOM 構造レベルで強固に保持され続けます。

我々はこれを The Zero-Index Protocol で解決しました。

脱!UIコンポーネント: データの選択機能が必要ないサマリー表示においては、あえて mo.ui.table を捨てます。
Pure HTML 変換: to_html(index=False) を用い、インデックスを「文字列レベルで物理的に抹消」した純粋な HTML テーブルを生成し、mo.Html で出力します。

この「引き算」の執念により、テーブル占有幅を極限まで圧縮し、300px 帯の極小ディスプレイでの完全表示を実現しました。

4. 戦略的決断：PC-First へのピボット

開発の最終盤、我々は一つの冷徹な事実（Fact）に直面しました。
現代のスマートフォンの CSS Viewport 幅は、標準モデルで 360px 〜 412px です。
一方、marimo ネイティブの UI コンポーネントが内包する最低限のパディングや、Shadow DOM のカプセル化には、物理的な限界が存在します。

ここで我々は、「スマホ対応の不全」を嘆くのではなく、「PC推奨のプロ仕様」へと戦略をピボット（転換） しました。

弱点を強みに変える: 「スマホで見切れる」という事実は、「スマホの極小画面では扱い切れないほど、高度で情報量が多いツールである」という権威性（USP）に変換可能です。
プロ本気層への訴求: 顧客の前で PC を開き、複数シナリオを瞬時に比較・プレゼンしたい不動産営業や FP、真剣に資金計画を練る住宅購入者へとターゲットを再定義しました。

結論：WASM アプリ開発の「純度」を高める

WASM ＋ marimo という選択肢は、サーバー維持費 0 円と、データが外部に漏れない銀行レベルの安全性（Isolated Sandbox）という究極の自由をユーザーに提供します。

しかし、その自由を使いこなすには、フレームワークの思想を深く理解し、物理的制約とビジネス価値のトレードオフを冷徹に判断するエンジニアリングが必要です。

「Marimo App Project」は、この「引き算の美学」と「物理的防壁の設計（ハーネスエンジニアリング）」を武器に、次なるステージへと進みます。

おまけ

▼ プロダクトのショーケース（index.html）はこちら