ノードタイプ

Busabase は信頼済みの知識をノードとして整理します。すべてのノードはダッシュボードのナビゲーションに表示されます。作成とライフサイクル操作は変更リクエストを使い、コンテンツの保存方法はノードタイプごとに異なります。

現在のタイプ

Whiteboard

Whiteboard は Excalidraw を使った自由形式のワークスペースです。シーンはバージョン付き JSON として metadata.whiteboardDocument に保存されます。バイナリアセットをオブジェクトストレージへ移すまでは画像挿入を無効にしています。

Workflow

Workflow は繰り返し使うプロセスをバージョン付きグラフとして標準化します。Event、Webhook、Webhook のサンドボックス Function 参照、Condition、Wait、Approval、Action、End を利用でき、接続には表示ラベルと機械可読な分岐結果を保存します。実行モード、同時実行数、タイムアウト、エラーポリシーはグラフと分離されています。P0 は定義を保存・検証しますが、まだ実行しません。

HTML

HTML はソースエディターと即時プレビューを組み合わせます。フォーム、メールやランディングページのプロトタイプ、小さなインタラクティブ案に適しています。プレビューコードは sandbox iframe 内で実行され、Busabase の親画面にはアクセスできません。

Drive

Drive は純粋なファイルツリーノードです。Skill と同じファイル一覧、読み取り、変更リクエスト、マージの仕組みを使いますが、初期ファイルは最小限の README.md だけです。

Skill

Skill は後方互換性を保っています。既存の /skills/* API ルート、SkillVO、contract schema、core handler の export 名と形は変わりません。実装は共有 file-tree kind に委譲されました。

AirApp

AirApp は Busabase の **Instant App（インスタントアプリ）**形式です。Agent が作成し、個別にデプロイすることなくワークスペース内で直接開けるライブインターフェースです。固定されたリリースサイクルを持つ従来のアプリというより、ワークスペースのデータ上に構築される「生きたプレゼンテーション」に近いものです。ダッシュボード、ブリーフィング、データストーリー、レビュー画面など、文書よりインターフェースで表現した方が分かりやすい専用ビューに利用できます。

Instant App の違い

• デプロイが不要です。 Agent が提案したファイルを承認してマージすると、Busabase で AirApp を開くだけで現在のバージョンが自動的に起動します。別途ホスティングを設定したり、ローカルの pnpm dev ターミナルを起動し続けたりする必要はありません。
• ビューは Busabase とつながり続けます。 AirApp は Busabase の同一オリジン API を通じて、ワークスペースの現在のデータを読み取れます。Base を静的に書き出す代わりに、実行するたびに最新の承認済みレコードを表示できます。
• 会話が編集インターフェースになります。 Codex、Claude Code、または接続済みの別の Agent に、セクションの移動、指標の追加、データの見せ方の変更を依頼できます。Agent は通常の Change Request フローで変更を提案し、承認後は同じ AirApp が新しいバージョンを実行します。
• 実行は即時でも、アプリは持続します。 ファイル、履歴、ワークスペースデータとの関係は Busabase に残ります。一度きりの localhost プロトタイプのように失われることなく、いつでも開き直して改善し、再利用できます。

AirApp は、固定された操作をクリックするだけでなく、Agent の現在の仕事を人が見て理解する必要がある場面で特に役立ちます。インタラクティブにもできますが、価値を生み始めるために、まず別の製品としてデプロイする必要はありません。

AirApp も Skill や Drive と同じファイルツリーノードです — ファイル一覧、読み取り、変更リクエスト、マージの仕組みを共有します。エージェントは Skill や Drive を編集するのと同じ変更リクエストフローでアプリのファイルを作成・編集します。人がノードを開くと 3 つのタブが表示されます: App（デフォルト — 実行ボタンとライブプレビューの iframe）、Files（読み取り専用のファイルブラウザ + コードビューア）、Logs（インストール/起動の出力をリアルタイムで表示）。

「実行」をクリックすると、アプリはサーバー上ではなくレビュー担当者自身のブラウザ内で実行されます。Nodepod（@scelar/nodepod）は Web Worker + Service Worker ベースの Node.js ランタイムで、アプリが宣言した依存関係をインストールし、サーバーを起動して、その出力を Logs タブへリアルタイムでストリーミングします。サーバーが起動完了を報告すると、App タブのプレビュー iframe は実行中のアプリを配信する同一オリジンの仮想 URL（/__virtual__/...）を指します。

実行が完了すると、App タブのツールバーにさらに 2 つのボタンが表示されます — プレビューを大きな画面で確認できるフルスクリーン切り替えボタンと、実行中のプレビューを右側の常駐サイドパネルに固定する「サイドパネルに固定」ボタンです。固定すると、ワークスペース内の他のどのノードに移動してもそのまま実行され続け、複数の AirApp を同時に固定して、それぞれ別々のタブとして表示することもできます。実行状態自体も通常のナビゲーションに耐えます — 別のノードに切り替えてから戻ってきても（同じ AirApp を開き直しても)、再起動はされません。実行中のままで、プレビューも中断したところから続きます。レビュー担当者は他のものを見ただけの理由で「実行」をもう一度クリックする必要はありません。

Nodepod の中で実際に動くもの — AirApp を書くエージェントへのガイド

Nodepod は完全な Node.js ではありません — ブラウザの Web Worker 内で動くように Node の API サーフェスを再実装したものです。この一点がすべてを説明します: 実際の OS プロセス、実際のネイティブバイナリ、実際のヘッドレスブラウザを必要とするものは、どう設定しても動きません。 純粋な JavaScript（と WASM にコンパイルされたフォールバック）であれば、たいてい動きます。

動作確認済み — 新しい AirApp の安全なデフォルト:

• 素の Node HTTP サーバー。初期テンプレートは Hono + @hono/node-server — バンドラーもビルドステップもなく、npm install && node server.js だけで配信を開始できます。バックエンド寄りの何かを作るなら、これが最も安全な出発点です。
• node:sqlite（Node 組み込みの SQLite モジュール）で実際にクエリ可能な状態を持たせる — 外部データベース依存がなく、ネイティブバイナリでもありません（Node 本体にコンパイルされています）。
• vite@7.3.1 に固定した Vite — バンドラーベースのフロントエンド開発サーバー用。古い Vite（^5.4.10/4.5.5）は Nodepod 内で起動時にクラッシュします（Cannot destructure property 'createServer'）。これは esbuild/ネイティブバイナリ解決のバグで、Vite 7 が同梱する esbuild のバージョンに対しては Nodepod 側で修正済みです。@vitejs/plugin-react は使わないでください（詳細は後述） — 代わりに Vite 組み込みの esbuild トランスフォームで JSX を処理します:

  // vite.config.js
  export default defineConfig({
    esbuild: { jsx: 'automatic' },
    server: { host: '0.0.0.0', port: 5173, strictPort: true },
  });

  トレードオフとして React Fast Refresh は使えません — 編集するとコンポーネントの状態を保持せずページ全体がリロードされます。Hono を Vite のミドルウェアとして直接マウントする（configureServer 経由）ワンプロセスのフルスタック構成も、同じ vite@7.3.1 固定下で動作確認済みです。
• @vitejs/plugin-react（Babel ベースの React Fast Refresh — 実際にコンポーネントの状態を保持する編集）— Nodepod 1.9.5 以前では動作不良でした（[BABEL] .length is not a valid Plugin property、Nodepod が Babel プラグインを読み込む際の実際のバグ）。1.9.6 で上流により修正済み — 1.9.9 で実際に検証: フルクリックスルーテストに成功（デモのカウンターボタンが動作し、編集で状態が保持される）。上記のフルリロード方式ではなく本物の Fast Refresh が欲しい場合はこちらを使ってください。

動作確認済みの不具合 — 見分けられる失敗パターン。再試行しないこと:

• @vitejs/plugin-react-swc（Babel を避けた SWC ベースの Fast Refresh）— Failed to load native binding で失敗します。@swc/core はプラットフォームネイティブのバイナリを同梱していますが、Nodepod にはそれを読み込む OS がありません。Nodepod 1.9.9 でも依然として動作不良です（同一のエラー）。
• インストールや開発サーバー起動時にプラットフォームネイティブバイナリを必要とするツール全般 — 上記の SWC の失敗はこの一般的な法則の一例です。パッケージの postinstall がネイティブの成果物（ネイティブ ML ランタイム、ネイティブビルドを持つ画像処理ライブラリなど）をダウンロードまたはビルドする場合、たとえ npm install 自体は成功しても、動かないものと想定してください。
• 実際のヘッドレスブラウザや実際の OS サブプロセスを起動する必要があるツール — 例えば HeyGen の HyperFrames CLI。その完全な HTML から MP4 へのレンダリングパイプラインは Puppeteer（実際のヘッドレス Chrome）と FFmpeg（ネイティブバイナリ）に依存しており、設定に関わらず Web Worker サンドボックスとはアーキテクチャ上両立しません。より軽量な hyperframes preview コマンド（Puppeteer/FFmpeg 不要）は実際に検証しました: npm install 自体は成功しますが、実行すると TypeError: require is not a function でクラッシュします — これは Nodepod ランタイム自体の実際の制限であり、AirApp 側のコードで直せる問題ではありません。Nodepod 1.9.9 でも依然として動作不良です（同一のエラー）。
• Next.js は直接テストしていません（改造の参考にできる公式の Nodepod サンプルが存在しないため）。デフォルトコンパイラの SWC は上記と同じ理由で依然として動作不良ですが、フォールバックの Babel はもう「動作不良確認済み」ではありません（上記の Fast Refresh の項目を参照） — ゼロから Babel を使う Next.js の AirApp を試す価値はあるかもしれませんが、まだ試していません。

シードギャラリーはドキュメントだけでなく、実際に動くリファレンスです。 新規インストールした Busabase には、動作するデモ（Hono API サーバー、Vite + React の 2 バリエーション、Vite にマウントされた Hono、node:sqlite）がシードされると同時に、依然として壊れている上記の例（SWC、HyperFrames）も削除されずに実際に実行できるノードとして残されます — どれで「実行」をクリックしても実際の失敗が再現されます。Nodepod 側でこれらも上流で修正されれば、Busabase 側で何も変更しなくても、そのデモはエラーではなく成功するようになります — 上記の Babel のデモがまさにそうでした。

実行は常にノードの現在の（マージ済み/HEAD の）ファイルツリーを反映します — まだマージされていない変更リクエストのファイルスナップショットをプレビューする機能は、Busabase のどのノードタイプでもまだサポートされていません。

実行にはセキュアコンテキストが必要です。 Nodepod がプレビュー/仮想サーバーのリクエストを横取りするために使う Service Worker は、ブラウザの「セキュアコンテキスト」（https:、または文字通りのホスト名 localhost/127.0.0.1/[::1]）でのみ登録されます。それ以外のホスト名（LAN の IP、自分のマシンにマッピングしたカスタム DNS 名、トンネルドメインなど）で平文の HTTP 経由でダッシュボードにアクセスすると、同じサーバーに解決されていても、セキュアコンテキストにはなりません。そのため Service Worker はサイレントに登録に失敗し、「実行」をクリックすると 404 になります。https:// または http://localhost:<ポート> を使ってください。

File

File は最もシンプルなノードです。重複排除された Asset ライブラリ内の 1 つの Asset（名前、MIME タイプ、サイズ、ダウンロード URL）を指すだけです。ファイルツリーは持ちません — 複数ファイルをまとめたい場合は Drive を使ってください。

ノードの並べ替えと移動

サイドバーでノードにカーソルを合わせると、小さなドラッグハンドルが表示されます。それをつかんで、兄弟ノードの間で上下にドラッグして並べ替えたり、フォルダにドロップして移動させたりできます。

サイドバーでノードにカーソルを合わせると、ドラッグハンドルが表示される。

ドロップ先は理にかなっている必要があります — フォルダを自分自身のサブフォルダの中にドロップすることはできませんし、フォルダではないものにノードをドロップすることもできません。それ以外はすべて自由に行えます。

知っておきたいこと： 並べ替えと移動は即座に反映されます — このページで説明している他の編集とは違い、変更リクエストのレビューを経由しません。これはコンテンツの変更ではなく、ナビゲーションの整理として扱われるため、承認するものは何もありません。

レビューフロー

ノード作成とライフサイクル操作、レビュー対象のファイル変更、対応済みのドキュメント編集は Inbox に届きます。リッチノードの保存も権限確認と監査ログ記録を行いますが、P0 の Whiteboard、Workflow、HTML の metadata 更新は直接保存され、まだ Inbox 項目を作成しません。

関連: コアコンセプト · 変更リクエスト