Nimbus

24時間働く従業員。

あなたが眠っている間もアプリにログインし、メールを送り、CRM を更新し、業務を処理する AI。一度設定すれば、ずっと無料。

1 つのコマンドで CLI、ゲートウェイ、すべてのバンドル済み MCP サーバーがインストールされます。動画では Docker の前提条件、OpenRouter API キーの手順、オプションの Agent Dashboard、ワークフローのインポートを順を追って紹介しています。

Nimbus を使う 2 つの方法

Self-host

ずっと無料

ノートパソコン、サーバー、CI どこでも動作
macOS・Linux・Windows に 1 コマンドでインストール
ソースコード完全公開、BUSL-1.1 ライセンス
SHA256 検証と SLSA 署名付きのリリース

インストーラーを入手

Nimbus Cloud

マネージド・Yoodule が運用

プロビジョニング・パッチ適用・監視を 24/7 実施
本番レベルの可用性とインシデント対応
準備ができたら self-host からの移行を支援
同じ Nimbus、同じ MCP サーバー、運用負担ゼロ

Yoodule に相談

Nimbus の self-host はこれからもずっと無料です。Cloud は自分たちで運用する代わりに、私たちに運用を任せたいチーム向けです。

なぜ Nimbus なのか

もう 1 つツールはいらない。あなたに必要なのは従業員です ― 繰り返し業務をこなし、あなたの仕事のやり方を学び、深夜 2 時に顧客からメールが届いても対応する従業員。Nimbus がその従業員です。 すでに使っているアプリに接続し、あなたが手作業で行う手順をそのまま踏み、実行するたびに賢くなっていきます。


眠っている間も働きます	いつでもタスクをスケジュール ― 日次フォローアップ、週次レポート、時間ごとのチェック。Nimbus が実行し、終わったら通知します。
すでに支払っているアプリを活用	Notion、Gmail、CRM、カレンダー。Nimbus がログインして操作 ― コピー＆ペーストも、エクスポートも不要です。
危険な操作は実行前に確認	メール送信ではなく下書きを作成し、行を削除する前に計画を表示します。常にあなたが決定権を持ちます。
障害時は自分で回復	パスワードのローテーション、サービスの再起動、アプリの更新 ― Nimbus が検知して修復します。あなたは呼び出されません。

できること

📨 フォローアップメールを送信

「先週ホワイトペーパーをダウンロードしたけど通話予約をしていない全員にメールを送って」と Nimbus に伝えてください。下書きを作成し、承認を待ち、送信します。

📊 データからレポートを作成

「先月クローズした取引を業種別にまとめて、共有 Notion ページにチャートを載せて」。朝までに完了。スプレッドシートとの格闘は不要です。

🗓️ 受信箱をトリアージ

毎朝、Nimbus が新しいメールにラベルを付け、明らかなものには返信の下書きを作成し、残りは確認用にフラグします。あなたが見るのは対応が必要なものだけです。

🔁 ワークフローをスケジュール実行

「毎週金曜 16 時に今週の主な成果を #team-channel に投稿して、私に要約メールを送って」。Nimbus がずっと実行し続け、メンテナンスは不要です。

🧠 あなたの仕事のやり方を記憶

Nimbus を長く使うほど学習します。いつもアーカイブするメール、重要なレポート、省略してよいステップを覚えます。

🛡️ 承認していないものは送信しない

Nimbus がまず下書きを作成し、あなたが承認します。メール送信、行の削除、メッセージ投稿はあなたのクリックなしには実行できません。すべてのアクションに監査ログが残ります。

ビジネスでの活用シーン

何でも 1 人でこなす創業者向け

日曜をフォローアップメールと CRM の更新に費やすのはやめましょう。繰り返し業務は Nimbus に任せて、あなたにしかできないことに時間を使ってください。

nimbus start ― ノートパソコンに一度設定すれば、ずっと無料。

小規模チーム向け

チーム全員にそれぞれの Nimbus 従業員を。コンテキストを共有し、各メンバーの好みを記憶し、顧客メモを失いません。

すべてのアクションが署名・監査され、巻き戻し可能です。

統制が必要な企業向け

自社のインフラ内で、自社の鍵と監査ログで Nimbus を運用するか、私たちに任せて私たちが運用するか。どちらでも同じ従業員です。

self-host vs. Cloud を比較 →

セマンティックゲートウェイ (mcp.json)

ご関心のある方へ：Nimbus は、従業員が使うすべてのアプリの一覧を記した小さな設定ファイルで動作します。触る必要はほとんどないでしょう ― Nimbus には妥当なデフォルトが付属しています。

Nimbus は stdio ベースおよび HTTP ベースの MCP サーバーをすべて単一のインターフェースに集約します。AI モデルが機能を要求すると、Nimbus は Qdrant に保存されたベクトル埋め込みを使って適切なツールを動的に発見し実行します。

Nimbus ホームディレクトリの mcp.json を変更して有効なサーバーを設定します：

{
  "mcpServers": {
    "playwright-mcp": {
      "url": "http://localhost:3100/mcp",
      "transport": "streamable-http"
    },
    "notion-mcp": {
      "url": "https://mcp.notion.com/mcp",
      "transport": "streamable-http",
      "auth": "oauth"
    },
    "linkedin-mcp": {
      "command": "uv",
      "args": ["run", "-m", "linkedin_mcp_server", "--transport", "stdio"]
    }
  }
}

ゲートウェイは MCP トランスポート面を直接公開します — nimbus-utility-mcp のようなラッパー名前空間は存在しません。モデルが登録済みサーバーを見つけ、実際に操作するために必要なツールは次の 2 つです：

find_tools ― 設定済みの MCP バックエンド全体（および kind ディスクリミネーター経由のバリデーターカタログ）をセマンティック検索します。モデルが「browse linkedin」と要求すると、関連ツールスキーマ（<server>_<tool> の名前空間形式）だけが返され、それを execute_tool でディスパッチできます。読み取り専用。
execute_tool ― 汎用ディスパッチャー。find_tools が返したツール名と引数を受け取り、適切なバックエンドサーバーに呼び出しを転送して結果をストリーミングで返します。読み取り／書き込みのアノテーションは下流ツールに依存しますが、ディスパッチャー自身がユーザーデータを削除することはありません。

エージェント自身の進行管理用に、同じトランスポート上に nimbus_agent、nimbus_todo_write、nimbus_get_task_progress_log も存在しますが、mcp.json に列挙されたアプリと連携するための表面は上記の 2 つに集約されます。

CLI リファレンス

技術ユーザー向け：Nimbus が理解するすべてのコマンド。ほとんどのユーザーは nimbus start と nimbus doctor だけで十分です ― あとは何か問題が発生したときのために。

nimbus CLI はローカルのコンテナ化ワークスペースのライフサイクルを制御します。

コマンド	動作
`nimbus start`	サービスを起動。すべての Docker コンテナー（postgres、redis、qdrant、gateway）をプロビジョニングして起動します。
`nimbus start --build`	再ビルドして起動。現在のソースから Docker イメージを再ビルドし、サービスをきれいに起動します。
`nimbus start --gateway`	ヘッドレスモード。ゲートウェイコンテナーのみを実行 ― CI やリモート MCP のみの使用ではフルスタックをスキップします。
`nimbus start --fresh`	データボリュームを消去。Postgres/Redis の認証情報を再生成し、データディレクトリを再初期化します。
`nimbus stop`	停止。すべてのコンテナーサービスを安全に終了し、システムポートを解放します。
`nimbus upgrade`	コンテナーイメージを更新。最新の gateway/dashboard イメージを取得し、必要に応じて 1 回限りの Qdrant スキーママイグレーションを実行し、`compose up -d --build` を行います。
`nimbus update [--gateway]`	CLI バイナリ自体を自己更新。プラットフォームアーカイブをダウンロードし、SHA256 + minisign 署名を検証して、実行中のバイナリをアトミックに置き換えます。`--gateway` を付けると、同じ実行でゲートウェイコンテナーの pull + 再起動も行います。
`nimbus uninstall`	アンインストール。Nimbus CLI、コンテナー、設定、および `~/.nimbus/` を削除します。
`nimbus doctor`	診断。Docker、バージョン差分、コンテナーの健全性、アップデートの新しさ、認証情報のドリフトを確認します。
`nimbus dashboard install`	オプションの Agent Dashboard コンパニオンをインストールします。
`nimbus dashboard uninstall`	Dashboard コンテナーとサービスブロックを削除します。
`nimbus dashboard status`	Dashboard が有効かどうかとコンテナーの状態を表示します。
`nimbus config <サブコマンド>`	`~/.nimbus/.env` を管理（list、get、set、unset、append、prepend、remove）。
`nimbus mcp <サブコマンド>`	`~/.nimbus/mcp.json` を管理（list、get、set、remove）。
`nimbus agent "<プロンプト>" [--model <id>]`	Dashboard の `nimbus_agent` にプロンプトを送信し、応答をストリーミングします。デフォルトは `openrouter/free` です。
`nimbus activate <key>`	ライセンス / 登録キーを有効化します。
`nimbus env-init`	CLI が管理するシークレットを `~/.nimbus/.env` に書き込みます（冪等）。

完全なリファレンスは nimbus --help、プラットフォーム別のインストール手順はダウンロードページを参照してください。

v1.0.5 で追加 — nimbus config {append, prepend, remove}

カンマ区切り値（例：OPENAI_API_KEYS、OPENROUTER_API_KEYS）を扱うための新しい 3 つのサブコマンドが追加されました。

nimbus config append  OPENAI_API_KEYS sk-newkey    # 末尾に追加（既定で重複除去）
nimbus config prepend OPENAI_API_KEYS sk-priority  # 先頭に追加（既定で重複除去）
nimbus config remove  OPENAI_API_KEYS sk-oldkey    # 1 つまたは複数のトークンを削除（CSV 可）

ゲートウェイ側の CSV パーサー（[a, b, c] / a,b / a\nb\nc のすべてに対応）と完全に一致し、remove でリストが空になった場合はキーごと削除されます（unset と同じ動作）。重複を許可するには --force を指定してください。CLI v1.0.5 以降で利用可能 — 旧バージョンでは認識されません。

エージェントに本物のランタイムを与える準備はできましたか？

ガイド付きセットアップをご希望ですか？1 対 1 のオンボーディングセッションを予約いただければ、ワークスペースを一緒に確認します。

オンボーディングセッションを予約 →