OpenMakeOpenMakeとは何か
データとモデルとエージェントを自ら統制する必要のある組織のための、オープンウェイトAIインフラです。企業が自社モデルを選び、自社データをつなぎ、社員がAIを使い、Agentに実際の業務を任せながら、権限・外部通信・コスト・実行・監査を企業自身が統制します。
オンプレミスは製品ではありません。顧客VPC、プライベートクラウド、社内GPUクラスター、閉域網と並ぶ配置オプションの一つです。製品はそのすべてで同一のまま残るプラットフォームであり、だからこそ売り方も「サーバーを構築します」ではなく「御社のセキュリティ境界の内側に、御社専用のAI Platformを構築します」になります。
- Open-weight — Qwen、EXAONE、Llama、Mistral、OpenAI互換エンドポイントをいつでも交換でき、特定の商用プロバイダーが企業のAIを所有しない
- Private — どの環境で動いても、データ境界は企業が所有する
- Agentic — 質問と回答で終わらず、文書検索、分析、社内DB照会、Web調査、ファイル作成、検証、承認、結果保存まで行う
- オープンソース — ランタイムをMITライセンスで公開し、運用者が実行されるコードを検証し、変更し、私有フォークとして運用できる
OpenMakeが取るべき位置
セルフホストの企業市場はすでに存在し、すでに支払いが発生しています。Dify EnterpriseはVPC・オンプレミス・閉域網配置を前面に出し、SSO、RBAC、監査ログ、データ主権を販売しています。Open WebUIもセルフホスト・オンプレミス・エアギャップ構成でSSO、LDAP、RBAC、Audit、Data Residencyをエンタープライズの価値として提示します。OpenHandsは2026年のエンタープライズ製品をAgent Control Planeとして定義し直しました。価値の中心は「AIにうまく答えさせること」から「企業がAIを安全に運用し統制すること」へ移っています。
良い兆候ですが、そのまま追随する計画ではありません。プライベートChatGPTはOpen WebUIと、エージェントワークフロービルダーはDifyと、コーディングエージェントはOpenHands・Claude Code・Codexと正面から衝突します。OpenMakeは軸を変えます。企業が所有するオープンウェイトモデルの上で動く、一般企業の知識業務です。
Open WebUI
セルフホスト型AIインターフェース。
Dify
AIアプリ・ワークフロービルダー。
OpenHands
ソフトウェア開発に集中したエージェントControl Plane。
Ollama / vLLM
モデルランタイム。
OpenMake
オープンウェイト基盤のPrivate AIと汎用Agent Runtime。普通の組織が実際に行う知識業務が対象です。
5つの運用レイヤー
このレイヤーがなければ、製品は企業が運用できるプラットフォームというより、マルチエージェントフレームワークに近いものになります。ロードマップは専門家の数ではなく、運用上の責任で整理します。
Agent Runtime
永続状態機械としてAgent Taskを実行、一時停止、再開、キャンセル、再試行、復旧する。
Control Plane
ID、RBAC、ポリシー、承認、予算、秘密情報、組織設定、監査ルールを管理する。
Execution Plane
モデル、ツール、ブラウザ、コード、ファイル、API、MCP、サンドボックスを実行する。
State & Memory
タスク状態、チェックポイント、セッション、アーティファクト、RAG、範囲付きMemoryを扱う。
Observability
実行タイムライン、ログ、トレース、コスト、失敗理由、評価、監査レポートを残す。
Work Intelligence: 業務記録を再利用可能なWorkflowへ
Work Intelligenceは、Chatやクリック再生の別名ではありません。ユーザーが許可した業務記録をレビュー可能なWorkflow定義にし、承認済みの実行と根拠につなげ、結果を再利用できる業務資産にする方向です。
この順序は現在のAgent Runtimeの上に置くロードマップです。以下の「計画」は出荷済み機能の説明ではありません。現在のCompanionはローカルフォルダのAgent作業と承認を認識したローカル実行を支援しますが、業務イベントを集めるObserverではなく、OpenMakeにはまだ組織向けControl Planeもありません。
01 — ユーザーが始める業務記録: 計画
明示的に許可された時間範囲とアプリまたはフォルダだけを収集し、記録中の状態と即時停止手段を示します。一回の記録は下書きの根拠であり、人の仕事を自動化する許可ではありません。
02 — レビュー可能なWorkflow定義: 計画
記録を、入力、出力、ツール、権限、承認点、例外、完了確認を持つバージョン付き定義に変えます。可能なら壊れやすいブラウザ再生より、許可済みAPIや構造化されたファイル操作を優先します。
03 — 永続実行と根拠: 一部実装
永続タスク、ターン終了チェックポイント、承認ゲート、アーティファクト、手続き的Skillはすでに使える土台です。次のExecution Graphは、各ノードに依存関係、担当、出力、再試行方針、完了条件を結び付けます。
04 — デバイスと組織の統制: 計画
将来のEdgeクライアントは、承認された操作でも実行前に範囲付きのローカル権限を再確認しなければならず、任意のリモートShellになってはいけません。組織、テナント、ポリシー、保持、予算、egress、監査の統制はControl Planeの仕事です。
この方向が正しい理由
この方向は、OpenMakeがすでに持つオープンソース、ローカル、運用者所有、オープンウェイト対応、ツール実行、透明な実行記録という強みを伸ばします。エージェント数の競争ではなく、他社の境界の内側で信頼でき統制された実行で差別化します。
新しいモデルの登場も脅威ではなく機会になります。企業が支払う理由はQwenそのものではなく、Qwenを企業システムに変える管理・実行層であるべきです。より良いオープンウェイトモデルが出るほど、その層の価値は下がるのではなく上がります。
ローカルの強みを守る
ローカルモデル経路、ローカルワークスペースブリッジ、Dockerサンドボックス、運用者が管理する外部プロバイダーを信頼境界にできます。
本当のボトルネックを解く
難しいのはモデルを呼ぶことではなく、状態を保ち、権限を守り、安全に再試行し、何が起きたかを証明することです。
Skillsをエコシステム単位にする
外部の貢献者はワークフロー、ツール、プロンプト、ポリシー、評価、スキーマ、テストをパッケージできます。この貢献の循環を成り立たせている前提がMITライセンスです。
A2Aの役割を明確にする
マルチエージェント議論を、すべてのリクエストの負担ではなく、高リスクな計画や検証の層として使います。
openmake_llm はどこまで来たか
ChatとローカルLLMプラットフォームとしては十分に大きく、統制されたエージェントランタイムとしても永続実行の基盤はすでに空白ではありません。1.62.3時点で、Agent Taskは7状態の状態機械上の永続行であり、ターン終了ごとにチェックポイントを残し、承認待ちで停止し、プロセス再起動後は自動再開し、自身のトークン量を記録します。
ただし2つの但し書きが付きます。このランタイムの大半は既定でオフのフラグの裏にあります。タスクサンドボックス、同時実行キュー、ローカル実行、自動振り分けはすべてopt-inで、新規インストールは私たちの運用配置と同じではありません。そして永続性の粒度はターン単位です。ターンの途中で落ちると、そのターンはツールの副作用も含めて再実行されます。ツール呼び出し単位のジャーナルがまだないためです。
残る空白はより狭く具体的です。ターン以下の永続性、実行グラフ、範囲付きMemory、組織制御プレーンです。
モデルゲートウェイとローカルルーティング: 高い
ローカルゲートウェイ、役割ごとのモデルルーティング、外部プロバイダー、トークン計測、フォールバックが動いています。ユーザー別クォータは取得失敗時に通過(fail-open)するため、現状は強制点ではなく計測に近いです。
Durable Task Runtime: 高い
タスク行、queuedとpausedを含む7状態の状態機械、ターン終了時のチェックポイント、チェックポイントが有効なタスクを自動再開する起動時復旧、ステップ単位のイベントログ、スケジュール、サンドボックスまたはローカル実行の選択が動いています。同時実行キューはopt-inで、単一APIインスタンスのプロセスメモリ上にあり、永続するのはqueued状態だけです。
ローカル実行面: 高い
ユーザーのマシンでツールを実行するブリッジはpackages/local-bridge-coreという単一実装になり、その上にデスクトップコンパニオン、openmake-code CLI、SwiftUIメニューバーアプリの3クライアントが載ります。パススコープ、実行denylist、回避不可のユーザー確認、OSサンドボックスプロファイルはすべてこのコアにあり、ローカル作業の作成は監査ログに残ります。
ツール、サンドボックス、承認: 中程度
MCP、Docker分離、ファイルとブラウザ実行、承認ゲート、ブラウザコンテナのネットワークレベルegress許可リストがありますが、完全なポリシー制御ランタイムではありません。承認待ちはメモリ上のPromiseで、再起動を越えて残るのはpaused状態だけです。
実行グラフ: 初期
保存される計画は状態とメモを持つ平坦なステップ列で、実行ステップはインデックスでそこに紐づきます。依存関係、権限、コスト上限、再試行方針、出力、完了条件をノード自身が持つ永続DAGはこれからです。
Memory: 一部実装
Procedural Memoryは実際に動きます。成功した作業のブラウザ・スクリプト手順を手順スキルとして保存し、類似の目標でモデルに問い直さず再生します。Episodicは保存ではなく派生で、過去の類似作業をタスク・ステップ行から再構成して圧縮ブロックとして注入します。本当の空白はSemantic Memoryで、ベクトルストアがなく、ユーザーMemoryはtrigram照合で検索します。
可観測性: 中程度
OpenTelemetryトレース、ステップ単位のイベントログ、監査ログ、メトリクス、そしてmeasure-firstゲートの判定根拠を描く週次ゲートレポートがあります。ゴールデンデータセットによるルーティング・応答評価はCIゲートとして動き、測定が支持しなかったルーティングゲートは1つすでに取り下げました。まだないのは、組織が監査者にそのまま渡せる一級の監査レポートです。
組織制御プレーン: 初期
JWT、3種のロール、bridge・chatスコープを持つAPIキー、使用量、管理画面、運用設定はあります。マルチテナントは未着手で、スキーマにtenant・project・workspace列自体がなく、予算ポリシー、データ出口統制、配置承認も今後の課題です。
開発リソースをどこに置くか
開発能力の約70%はエンタープライズ基盤に属します。ソフトウェアプロジェクトと販売できる製品の差は、機能一つではなく、前節で「初期」と記したControl Planeです。次の4区分がその差を埋める順序です。
P0 — 必須
Organization/Tenant、RBAC、Project、Model Policy、Data Egress Policy、Audit、Secret Management、Usage/Budget。
P1
Execution Graph、Agent Policy、Sandbox Policy、Approval Workflow、Observability、範囲付きMemory。
P2
SSO(OIDC・SAML)、LDAP、SIEM連携、Backup/Restore、HA、Kubernetes配置。
P3
閉域網インストール、オフラインモデルレジストリ、オフラインSkillレジストリ、エンタープライズ更新チャネル。
一つのコードベースからCommunityとEnterpriseへ
OpenMakeはオープンコア構造を取ります。強いコミュニティ版はエンタープライズ事業と競合するものではなく、それを成り立たせる条件だからです。エコシステムの単位はSkillです。貢献者がランタイム全体を理解しなくても、ワークフロー一つをパッケージにできる必要があります。
OpenMake Community — MIT、無料
単一組織、ローカルモデル、Agent Runtime、MCP、Skills、基本RAG、基本サンドボックス。人々が入れて使い続けるだけの強さが必要です。
OpenMake Enterprise — 有料
Organizations、高度なRBAC、SSO・LDAP、Policy Engine、Model Governance、Data Egress Control、Audit、Budget、エンタープライズ配置、HA、閉域網、サポート。ただしこの一覧はまだ一つも実装されていません。スキーマにtenant・project列自体がなく、現在はすべてのインストールが単一組織です。
実行ノードとしてのOpenMake Code
別プロジェクトではなく、同じControl Planeの下で社内PCのローカルファイル・ソース・ターミナル・内部ネットワーク作業を担うExecution Nodeになります。この整理はすでに始まっています。ブリッジが共有コアへ移った後にElectronシェルはリポジトリから外れ、実行ノードはネイティブコンパニオンとCLI、そしてそれらを動かすWebになりました。
引き継ぐもの
OpenMake 1.62.3には、ローカル優先ルーティング、役割ごとのモデル割り当て、Agent Tasks、Skills、22個の組み込みMCPツール、エビデンス付きDeep Research、NotebookLM、アーティファクト、運用者制御、そしてデスクトップコンパニオン・openmake-code CLI・ネイティブメニューバーアプリが共有する単一のローカル作業ブリッジがあります。これらを捨てず、Control Planeの下の実行層へ再配置します。
- LLM Gatewayは認証、ストリーミング、トークン、タイムアウト、フォールバック、パラメーター正規化を担当する
- message pipelineはリクエスト処理を担い続け、計画は再利用可能な実行グラフ、必要権限、承認点、コスト見積り、完了条件を持つ保存型プランナーへ分離する
- A2Aは高リスクな計画、コードレビュー、事実照合、結果検証へ移す
- RAGは検索層として残し、作業、エピソード、意味、手続き、アーティファクトのMemoryを分ける
コアとして作るもの
不足しているのは新しいエージェントプロフィールではありません。プロセス再起動後も残り、ターン終了ごとにチェックポイントし、承認を待ち、既知の状態から再開する永続実行基盤は、すでに製品に入っています。まだ無いのはその上の層です。ランタイムが実行できるグラフ、プロンプト以外の場所に置かれたポリシー層、範囲を持つMemoryです。
Durable Task Runtime — 実装済み
タスクモデル、状態機械、ワーカー、イベントログ、チェックポイント、キャンセル、再開、再試行。他の層が立つ土台です。まだ開いているのは2つ、冪等な再実行（ターンの途中で落ちるとそのターンのツール呼び出しが再実行される）と、プロセスより長く生きるキューです。現在のキューはopt-inで単一プロセスのメモリ上にあります。
Execution Graph — 計画
入力、出力、エージェント、モデル、ツール、権限、タイムアウト、再試行、成功条件、コスト上限、承認を持つDAGノード。現在保存される計画は平坦なステップ列です。
Policy and Approval — 一部実装
読み取り専用から外部影響、配置、支払い、セキュリティ、法務、財務までの権限レベル。現在は承認ゲートがその一部を担い、背後にあるべき宣言的ポリシーエンジンはまだありません。
Tool Runtime — 一部実装
スキーマ、権限メタデータ、実行方式、タイムアウト、再試行、テレメトリー、標準結果を持つレジストリ。ツール自体はすでに動きます（内蔵22種と外部MCP）が、このようなレジストリの背後で動いてはいません。
Workspace Sandbox — 実装済み
タスクごとのワークスペース、接続フォルダ、プロセスまたはコンテナ分離、リソース制限、ネットワーク許可リスト。これはすでに動いています。ここに挙げたのは、上の層がポリシーではなく個別呼び出しでここへ届いているからです。
Memory and Audit — 一部実装
出所、確度、機密度、有効期限を持つMemoryと、計画、モデル、ツール、コスト、承認、失敗、成果物のトレース。手続きMemoryとトレースはすでにあり、範囲メタデータと意味的ストアがありません。
構築順序
最初の2段階はおおむね実装済みです。次に証明すべきはExecution Graphです。タスク状態はすでに信頼できます。足りないのは、線形のターン列ではなく、ノードごとに依存関係、権限、完了条件を明示する計画です。
- 01
Durable Task Runtime — 実装済み
タスクモデル、状態機械、キュー、ワーカー、計画、チェックポイント、キャンセル、停止、再開、イベントログが製品に入っており、タスクごとのトークン量は終了遷移時に集計されます。残るのはターン以下の永続性です。落ちたターンが副作用を再実行しないためのツール呼び出し単位のジャーナルと、プロセスより長く生きるキューです。
- 02
ツール、承認、サンドボックス — ほぼ実装済み
Tool Registry、MCPゲートウェイ、承認受信箱、ワークスペース分離、Dockerサンドボックス、秘密情報、ファイル差分、ブラウザegress許可リストがあります。残るのは、サーバー側で権限レベルを強制する宣言的ポリシーエンジンと、プロセスメモリだけに存在せず再起動を越えて残る承認待ちです。
- 03
Execution Graph — 次の段階
依存関係、必要権限、コスト上限、再試行方針、出力、完了条件をノード自身が持つDAG。線形のターンループに代わる計画単位です。
- 04
AgentとSkillマニフェスト — 進行中
Supervisor、Planner、Worker、Researcher、Reviewer、Recoveryの役割と、Skillsのパッケージ単位を標準化。マニフェストによるSkill注入と手続きSkillの抽出はすでに始まっています。
- 05
範囲付きMemoryと組織制御プレーン
出所と期限を持つ作業・エピソード・意味・手続き・アーティファクトMemory。続いてマルチテナント、組織、プロジェクト、RBAC、予算、外部モデルポリシー、配置承認、運用ダッシュボード。
これからの12か月
以下の日程は機能を増やす計画ではなく、実際の組織で製品を証明する計画です。OpenMakeを業務ネットワークに入れて毎日使う企業が一社あることは、GitHubスターの数千個より価値があります。
起点となる0か月は、このロードマップを確定した2026年8月です。したがって最初の区間はこれからではなく、いま通過している区間であり、その中ですでに終わったものは下に示しました。
- 0〜3か月
製品アイデンティティの確定 — 通過中
済み: Private AIのポジショニングとエンタープライズアーキテクチャはこのページがいま述べている内容で、代表的なUse Case 3つは直前の節に書かれ、Auditログはかなり前から動いています。未了: OrganizationとProjectはスキーマに概念自体がなく、RBACはtenant・projectの範囲を持たない3種のロールで止まり、Model Policyは未着手です。ただし、その根拠となるモデル計測はOpenMake Benchで先に始めています。
- 3〜6か月
実際の企業への適用
Design Partner 3社、プライベートVPC配置、オンプレミス配置、SSO、Data Policy、Skillのパッケージ化。
- 6〜9か月
構築ではなく製品に
エンタープライズインストーラー、アップグレードとバックアップ、監視、管理ダッシュボード、Kubernetes、エンタープライズ価格。
- 9〜12か月
反復販売の検証
実運用の顧客、ケーススタディ、パートナー、SI連携、エンタープライズサポート。
最初のUse Caseは意図的に狭く
最初の企業向けデモは社内リサーチ・文書エージェント一つです。対象は、外部の生成AIに社内資料を入れにくい30〜500人規模の知識集約型組織です。協会・団体、研究機関、公共関連機関、製造業のR&D部門、中堅企業、コンサルティング会社、会計・法務の組織が先で、大手金融や防衛は後です。そちらは製品より先に認証・調達・セキュリティ・SIの能力を求められるからです。
社員が「過去3年の契約書と関連規程を分析して、問題になりうる条項を探しレポートにしてほしい」と依頼します。実行は社内文書検索、RAG、オープンウェイトLLMでの応答、外部検索の可否に関するPolicy確認、追加調査、根拠の検証、レポート作成、担当者の承認、PDF・DOCX・表計算の出力、Audit Logの保存と続きます。社内文書は会社の統制領域の外に出ません。
- 文書分析 — アップロード、構造分析、抽出、照合、レポート、保存されたアーティファクト
- 調査作業 — 検索計画、ソース収集、ソース評価、矛盾する根拠の確認、レポート
- 反復作業の自動化 — 定期実行、データ収集、しきい値比較、異常検知、レポート、承認後の後続処理
- 開発作業は引き続き支えますが入口にはしません。専用のコーディングエージェントがすでに競っている市場だからです
- 専門エージェントを増やすこと、すべてのリクエストをA2Aにすること、権限をプロンプトで制御すること、ChatServiceを肥大化させること、制御された半自動が動く前に完全な自律を約束することから始めない