Open Flow は、AI Agent と人が同じ Flow を共同で構築できる、オープンソースのワークフロー自動化プラットフォームです。Codex、Claude Code、または他のターミナル Agent に
oo flow を通じて型付きワークフローを作成、検査、実行、公開させ、その同じ Flow を Workbench で視覚的に確認し、編集できます。
型付きノードで構造を定義し、カスタムロジックは JavaScript として保ち、OOMOL Hosted または自分で管理するインフラストラクチャ上で自動化を実行できます。 グラフは理解しやすいまま、コードはコードのまま、そしてデプロイメントは自分の管理下に残ります。
Important
Open Flow は現在 Beta 段階です。公開されている契約（contract）はバージョン管理されていますが、プロダクトとしての最初の安定版はまだリリースされていません。
oo flow は、作成ライフサイクルをバージョン管理された機械可読コマンドとして公開します。ターミナルを使用できる Agent は次の操作ができます。
- 正確な Connector Action と Provider Trigger を探索する。
- 型付き Node、Edge、Code Task、Trigger binding を作成および編集する。
- Draft を検査して実行し、結果を確認する。
- 明示的に依頼された場合に Live へ公開するか、同じ Flow を Workbench で開く。
依頼の例：「未読の Gmail メッセージを読み、整形して Feishu に送信するワークフローを構築して。」
Agent が作成するのは、使い捨てのローカル設定ではなく、選択した Open Flow デプロイメント内の実際の Draft です。CLI と Workbench は同じ Control API を使用するため、AI が作成した変更は同じビジュアルグラフに表示され、人と Agent のどちらも編集を続けられます。
Codex、Claude Code、または他のターミナル Agent から Open Flow を作成するために oo CLI をインストールします。
自分で動かしている Open Flow を使う場合は、Agent を実行するシェルで OO_OPEN_FLOW_URL と OO_OPEN_FLOW_TOKEN を設定してください。
詳細は OpenConnector と oo CLI で Open Flow を使う を参照してください。
どの対応パスでも、同じ Open Flow プロダクトと Workbench を利用できます。
| ☁️ OOMOL Hosted | 🐳 Docker Self-hosted | Fly.io Self-hosted |
| サーバーの準備、更新、監視なしですぐに利用できます。OOMOL がデプロイメントを運用し、対応する連携にはマネージド OAuth App を提供するため、固定のサーバー費用や個別の OAuth App 設定が不要です。 | 同梱の Docker イメージを使って自分のインフラストラクチャで実行します。デプロイ、ストレージ、バックアップ、アップグレード、ネットワーク、Connector または OAuth App の設定を自分で管理します。 | 同じ Docker イメージを Fly.io で実行でき、サーバーを自分で運用する必要はありません。Fly がイメージのビルド、TLS 終端、永続 volume 上の SQLite を担当し、secret、バックアップ、アップグレード、Connector または OAuth App の設定は自分で管理します。 |
| 🚀 OOMOL Hosted を使う | Docker でセルフホストする | Fly.io にデプロイする |
- AI Agent で構築する。 Codex、Claude Code、または他のターミナル Agent から
oo flowを使用して、Workbench に表示される同じ Flow を作成、検査、実行、公開できます。 - データ依存関係を明示する。 すべての Task は、名前と型を持つ入力と出力を宣言します。各エッジは特定の出力値を特定の入力に結び付けるため、グラフがランタイムで使用されるデータ依存モデルになります。
- ビジュアルで設計し、必要なときにコードを追加する。 キャンバス上で型付きノードを組み合わせ、カスタム JavaScript には Code Task を使います。コードはフォーム項目に隠されず、常に見える状態に保たれます。
- 実行とデバッグを一か所で。 実行前に入力と Flow の構造を検証し、各ノードの進行状況と出力を確認し、すべての Run の完全なイベント履歴を追跡できます。
- 長時間動作する自動化を公開する。 Flow は手動で開始できるほか、Cron スケジュール、Webhook、ポーリングソース、Provider のイベントから起動できます。
- 運用状態をまとめて管理する。 Project、不変の Revision、Publication、Live バージョン、Run、Trigger の状態は、ローカルファイルと隠れたサービスに 分散することなく、選択された一つのデプロイメントに属します。
- 信頼できないコードを安全に実行する。 Server は、長時間稼働する Executor プロセス内で、コードの Task ごとに新しい V8 isolate を作成し、 その Task が宣言した Capability だけを公開します。
- 実行場所を選べる。 OOMOL Hosted を利用するか、同梱の Server を Docker で自分のインフラストラクチャ上に実行できます。
Open Flow は、ノーコードのプロトタイプでは収まらなくなったものの、不透明なスクリプトとインフラの寄せ集めにはしたくないワークフローのために作られています。
すべての Task は、名前と型を持つ入力と出力を宣言します。エッジは特定の出力から特定の入力へ値を運び、入力の準備が整うとランタイムがノードを起動します。
グラフには、ランタイムが実際に使用するデータ依存関係がそのまま現れます。通常の Flow データを、隠れたランタイムストア経由で任意のノードから取得することはできません。独立したブランチは並行して実行でき、キャンバス上の位置が実行動作を変えることもありません。
詳細ビューでは、各入力、出力、型、nullable 制約、接続がキャンバス上に明示されます。
Code Task では、カスタム JavaScript をグラフ内に直接配置し、型付きの入力と出力を維持できます。
flowchart LR
Workbench["Workbench"] -->|"Control API"| Server["Open Flow"]
CLI["oo flow CLI"] -->|"Control API"| Server
Server -. "任意" .-> Connector["Connector ランタイム"]
Connector --> Providers["サードパーティ Provider"]
Server --> Store["SQLite：Project、Revision、Publication、Run"]
Server --> Triggers["Trigger スケジューラ：Cron、Webhook、Poll、Integration"]
Server --> Runtime["分離された JavaScript ランタイム"]
Workbench と CLI は、バージョン管理された Control API を通じて、選択された一つのデプロイメントとだけ通信します。デプロイメント側が検証、実行、永続化、 Trigger の受け入れを担当します。Provider の認証情報が Open Flow に入ることはありません。Connector を利用する Action、Provider Trigger、proxy は OpenConnector のような Connector ランタイムを経由し、Open Flow は不透明な Connection の識別子だけを保存します。
Docker と OpenSSL が必要です。リポジトリをクローンし、オペレーター Token を作成して、セルフホストの Server を起動します。
git clone https://github.com/oomol-lab/open-flow.git
cd open-flow
export OPEN_FLOW_TOKEN="$(openssl rand -hex 32)"
docker build --file apps/server/Dockerfile --tag open-flow-server:dev .
docker run --rm \
--publish 3000:3000 \
--env OPEN_FLOW_TOKEN="$OPEN_FLOW_TOKEN" \
--volume open-flow-data:/data/open-flow \
open-flow-server:devhttp://127.0.0.1:3000 を開き、OPEN_FLOW_TOKEN の値でサインインします。同じ値は、Control API を利用するマシンクライアントの
Bearer Token としても使えます。Project と Run の履歴は open-flow-data Docker volume に永続化されます。
ビルドを省略するには、ビルド済みのマルチアーキテクチャイメージ ghcr.io/oomol-lab/open-flow を pull するか、リポジトリルートの
docker-compose.yml で起動してください。Tag (latest、Release バージョン、tip、コミットハッシュ) とアップグレード手順は
Docker イメージガイド を参照してください。
Server は外部サービスなしでも利用できます。Connector を利用する Action、Provider Trigger、LLM Task は、対応するホストの Capability が設定されるまで フェイルクローズで動作し、非公開のサービスにフォールバックすることはありません。
本番環境の設定、TLS、ヘルスチェック、永続化、バックアップ、リソース制限については、Server デプロイガイド と SECURITY.md の強化チェックリストを参照してください。
同じイメージは Fly.io でも動作します。リポジトリに含まれる fly.toml は apps/server/Dockerfile でイメージをビルドし、Cron と Poll Trigger
を動かすために 1 台の machine を常時起動し、SQLite を Fly volume に永続化します。Fly app の作成、volume、secret、デプロイ、custom
domain、スケーリングの制限については Fly.io へのデプロイ を参照してください。
GitHub、Gmail、Slack、Notion などのサービスに対して Action や Provider Trigger を実行するには、Server を Connector ランタイムに向けます。 セルフホストの OpenConnector と OOMOL がホストする Connector のどちらも、必要なランタイム API を提供しています。
OPEN_FLOW_CONNECTOR_ORIGIN=http://open-connector:3000
OPEN_FLOW_CONNECTOR_TOKEN=replace-with-a-scoped-runtime-token
OPEN_FLOW_CONNECTOR_CONSOLE_ORIGIN=https://connector.example.comruntime origin は Server が Connector に到達するためのアドレスで、console origin はユーザーのブラウザがアカウント認可のために Connector Console を開く アドレスです。Provider Trigger の定義は Open Flow に同梱されており、登録は不要です。Integration callback の設定と各 origin の制約については 設定リファレンス を参照してください。
OpenConnector と Open Flow を一緒に起動し、runtime token を作成し、アカウントを認可して、oo flow で最初の Flow を作る手順は
OpenConnector と oo CLI で Open Flow を使う を参照してください。
Workbench と CLI は、特定のデータベースやクラウドランタイムに依存するのではなく、バージョン管理された Control API で通信します。デプロイメントが実行と 永続化を所有し、クライアントは第二のローカル Project 形式を作ったり、暗黙のうちに別のバックエンドへ切り替えたりしません。
このリポジトリには次が含まれます。
packages/open-flow：公開 npm パッケージ@oomol-lab/open-flow。Authoring、Execution、Trigger、Control API、Conformance、 Workbench Runtime の各エントリを提供します。packages/command：oo flowコマンドのランタイムと、oo CLI が利用する不変の Command Artifact。apps/server：セルフホスト可能な Workbench、Control API、SQLite 永続化、Trigger スケジューラ、分離された JavaScript ランタイム。
永続的なモデルについてはプロダクトとアーキテクチャの境界を、HTTP の契約については Control API リファレンスを参照してください。
Open Flow はワークスペースに Bun を、Server に Node.js を使用します。.bun-version と .node-version で固定されたバージョンを使ってください。
bun install --frozen-lockfile
bun run dev開発用の Workbench は http://127.0.0.1:5173 で開きます。その API リクエストは http://127.0.0.1:3000 の Server にプロキシされます。
初回の開発実行時に、オペレーター Token が apps/server/.open-flow-dev/operator-token に作成されます。以降の実行ではこの Token が再利用されるため、
開発サーバーを再起動しても現在の Workbench セッションは無効になりません。明示的な Token を使いたい場合は OPEN_FLOW_TOKEN を設定してください。
変更を提出する前に、次を実行してください。
bun run check
bun run test
bun run build公開パッケージや CLI に触れる場合は bun run test:package を追加し、Docker が利用できる場合は bun run test:docker を実行して、リリースイメージ、
分離ランタイム、Workbench、graceful shutdown、SQLite volume の復旧を検証してください。リポジトリのルートで bun test を直接実行しないでください。
ワークスペースのテストスクリプトを迂回してしまいます。開発ルールの全文は CONTRIBUTING.md を参照してください。
ドキュメント索引から始めてください。特によく参照されるものは次のとおりです。
- プロダクトとアーキテクチャの境界
- Control API
- Command Artifact の配布契約
- Workbench と Designer のフロントエンドに関する注意
- Server のデプロイ
- Docker イメージ (GHCR)
- Fly.io へのデプロイ
- OpenConnector と oo CLI で Open Flow を使う
- コントリビューション
- 行動規範
- セキュリティ
- OpenConnector：Connector を利用するノードの背後で Provider カタログ、認証情報、Action の実行を提供する オープンソースの Connector ゲートウェイ。
- oo CLI：このリポジトリからビルドされる
oo flowコマンドをホストするローカル Agent ツールキット。
Issue と Pull Request を歓迎します。開発環境のセットアップ、リポジトリのルール、Pull Request を作成する前に実行すべきチェックについては CONTRIBUTING.md を参照してください。このプロジェクトへの参加は CODE_OF_CONDUCT.md に従います。
脆弱性は公開 Issue ではなく、GitHub のプライベート脆弱性報告を通じて非公開で報告してください。 SECURITY.md には、サポート対象のバージョン、開示プロセス、報告の範囲、セルフホストデプロイメントの強化方法が記載されています。
Apache-2.0。同梱アセットに関するサードパーティの通知は NOTICE に記載されています。
Open Flow の開発にご協力いただいたすべての皆さまに感謝します。参加方法については コントリビューションガイド をご覧ください。
