holaOS｜AIエージェントと人が同居するOpen Agent Computer、Workspace中心設計を解読

「AIエージェントが自分の代わりにブラウザを開いてリサーチし、ファイルを書き、Slackに投稿し、終わったら状態をきれいに保存する」——この絵を本気で実現しようとすると、毎回必ず同じ壁にぶつかる。タスク終了と同時にメモリも文脈も消し飛び、次回はゼロからやり直しになる、という壁だ。

ChatGPTのCustom GPTsもAutoGPT系も、結局はステートレスなプロンプトの寄せ集めの上で動いている。継続性はベクトルDBや外部メモリのレイヤを自分で組み合わせて確保するしかなく、ハーネスごとに作り直しになる。

holaboss-ai/holaOS（★5463、2026年5月10日最終push）はその構図を根本から逆転させようとするOSSである。「ハーネスが環境を呼び出す」のではなく「環境がハーネスをプラグインとして受け入れる」設計で、Workspace・Runtime・Memory・Agent Harnessの4層をElectronデスクトップに常駐させた。

AIエージェント基盤の全体像と他フレームワーク比較は AIエージェントフレームワーク比較ガイド2026 をご覧ください。

1. holaOSとは何か：Open Agent Computerという定義

holaOSは公式READMEで「An Open Agent Computer for ANY digital work」と定義されている。日本語に訳すと「あらゆるデジタル作業向けのオープンなエージェント・コンピュータ」で、key conceptはAgent Computerという名詞だ。

従来のAIエージェントは「人間がアプリを操作するときの代理」として設計されてきた。Browser UseもManusも、人間用のUIにエージェントを擬人化させて差し込む方向だ。

holaOSはそこから一歩引いて、「人間とエージェントの両方が同等の市民として住むコンピュータそのもの」を定義し直す。同じブラウザ・同じファイル・同じアプリにエージェントが直接アクセスし、人間と並行して作業する。

GitHubトピックにはagent-os・agent-harness・agentic・runtime・workspace・mcp・memory・proactive-aiが並んでおり、これらが設計の柱になっている。

公式サイト（holaos.ai）のサブタイトルは「The Computer for You and Your Agent」で、人間とエージェントが2人称関係で同居するという思想が一貫している。

holaOSのプロジェクト基本情報

最終pushが2026年5月10日と非常に新しく、Open Issuesも8件と少ない。プロジェクトはアクティブ開発段階で、APIや構造は今後も変動し得る前提で評価したい。

2. Environment Engineeringという思想

holaOSの設計を読み解く鍵は、開発元であるHolabossが掲げるEnvironment Engineeringという言葉だ。

公式ドキュメントのEnvironment Engineeringセクションで、「長期的なAI作業はハーネス単独ではなく、エージェントを取り巻く環境によって定義されるべきだ」と明示されている。

明確に定義された環境はエージェントに安定したWorkspace・メモリ・継続性モデル・能力面を与え、サンプル効率の高い学習と自己改善の条件を作る、という主張である。

2.1 ハーネス中心設計の限界

AutoGPT・BabyAGI以降のエージェント研究は、「エージェントループ（観察→計画→行動→記憶）」というハーネスを洗練させる方向で進んできた。

しかしハーネスを精緻化しても、毎回新しい環境が用意される限り、エージェントは経験を蓄積できない。CLIサンドボックスで起動するエージェントは、ファイルもブラウザのセッションも毎回まっさらだ。

「人間が同じデスクトップで何年も働き続けてスキルを蓄積できるのは、デスクトップという環境が持続するからだ」という観察から、holaboss-aiは環境を先に固める方向へ舵を切った。

2.2 Environment-firstへの転換

holaOSではエージェントエグゼキュータ（プロンプト・ツール呼び出しロジック）は差し替え可能なプラグインで、Workspace・Runtime・Memoryのほうが固定資産になる。

これは大企業の業務システム設計に近い。アプリは入れ替わっても、データベース・ファイルサーバ・アイデンティティ管理は変えない。エージェントの世界では珍しい順序の優先付けだ。

実装的には、Runtime層にstable harness boundaryが定義され、その境界の外側に複数のエグゼキュータ（Claude実装・OpenAI実装・ローカルLLM実装など）をプラグインする。

3. 4層アーキテクチャの全体像

holaOSのRuntime構造は、ドキュメントのConceptsページに沿うと4つのレイヤに整理できる。

各層は上から順に「何のために」「誰として」「どんな記憶で」「どう実行するか」をモデル化している。

3.1 Workspace層

Workspaceは1人のエージェントの作業領域に相当する自己完結ユニットで、以下を1セットで束ねる。

・エージェントの目標・指示・役割定義
・アクセスできるツールとアプリ（ブラウザ・ファイルシステム・APIs・カスタムツール）
・セッションをまたいで永続するメモリ面とステート

「リサーチアシスタント」「コードレビューア」「ニュースキュレーター」のように役割ごとに別のWorkspaceを作る運用が想定されている。

3.2 Memory and Continuity層

Memory層は単なる短いプロンプト履歴ではなく、長期的なコンテキストを書き込み・読み出しできるメモリ面を提供する。

継続性アーティファクト（continuity artifacts）として、ログ・状態スナップショット・Workspaceテンプレートが定義されている。これらにより、機械をまたいだ再開や、別エージェントへの引き継ぎが成立する。

3.3 Runtime層

Runtimeはエージェントワークフローを実際に実行し、ツールとアプリを協調させるレイヤだ。

ここにstable harness boundary（安定ハーネス境界）が置かれており、その境界の内側はAPI契約として安定、外側のエグゼキュータは入れ替え可能、という分割になっている。

3.4 Agent Harness境界

エージェントエグゼキュータ（プロンプト戦略・ループ実装・モデル選定など）はこの境界面を介してRuntimeに接続する。

公式ドキュメントでは「Runtimeがworkspaceを主要なアーティファクトとして扱い、エージェントエグゼキュータはそこにプラグインされる」と説明されている。

4. Workspace Modelを掘り下げる

WorkspaceはholaOSのいちばん外側の単位で、ディスク上にもプロジェクトディレクトリとして実体を持つ。

Workspace Modelではauthored surfaces（人間が書く面）とruntime-owned state（Runtimeが管理する面）を明確に分離する設計が説明されている。

4.1 authored surfaces

人間がコミット可能な部分。

・instructions.md / role.md：エージェントへの指示と役割定義
・skills/：再利用可能なスキルセット
・tools.yaml：使えるツールとMCPサーバーの宣言
・templates/：他Workspaceへ複製可能なテンプレート

Gitで管理し、チームで共有できるレイヤだ。

4.2 runtime-owned state

Runtimeが書き換える部分。

・memory/：長期記憶ストア
・runs/：過去の実行ログとアーティファクト
・snapshots/：状態スナップショット
・session/：現在進行中のセッションステート

ここはユーザーが直接触らず、Runtime APIまたはデスクトップUI経由で操作する。

4.3 Workspaceテンプレート

templates/の中身を別Workspaceとしてスポーンできるため、「リサーチWorkspaceの雛形を全社で配布する」「個別案件ごとにテンプレートからフォークする」という運用が可能になる。

人間のチームでオンボーディング資料をテンプレ化するのと同じ感覚で、エージェントの起動設定をテンプレ化できる。

5. Memory and Continuityの実体

メモリと継続性はholaOSの最大の差別化ポイントなので、もう一段掘る。

5.1 メモリの3層

公式のMemory and Continuityでは、以下のメモリ階層が定義されている。

・短期メモリ：現在のセッション内のコンテキスト（短期プロンプト）
・中期メモリ：直近の実行ログから抽出した要約と判断
・長期メモリ：永続化された知識・好み・プロジェクト固有情報

長期メモリには「ユーザーの好み」「過去の意思決定」「ドメイン固有の用語集」などが蓄積され、エージェントが再起動しても保持される。

5.2 継続性アーティファクト

長期作業を成立させるための、Runtimeが自動生成する成果物だ。

・runs/[runId]/log.jsonl：1実行あたりの完全イベントログ
・runs/[runId]/result.md：実行結果サマリ
・snapshots/[ts]/state.json：その時点のWorkspaceスナップショット
・templates/exported.zip：他環境へエクスポート可能なバンドル

これらが「明日の自分」「別マシンの自分」「別エージェントへの引き継ぎ先」に対するインターフェースになる。

5.3 inspectability

公式表現で繰り返し強調されるのがfully inspectableという性質だ。

エージェントが何を考え、どのツールを呼び、どの結果を得たかを、人間がすべて事後確認できる。ブラックボックス化を避けつつ、長期作業の自律性を高める設計である。

6. Electronデスクトップ版のセットアップ

holaOSはElectronで配布されるデスクトップアプリで、内部にRuntimeをバンドルしている。

実機検証はmacOS / Linux / WSLで可能、Node.js 24.14.1とnpmが前提だ。

6.1 ワンライナーインストール

新しいマシンに最短で入れるなら、公式のscripts/install.shを直接実行する。

curl -fsSL https://raw.githubusercontent.com/holaboss-ai/holaOS/refs/heads/main/scripts/install.sh | bash -s -- --launch

このスクリプトは以下を自動でやる。

・git・Node.js 24.14.1・npmの未インストール時の導入
・リポジトリの~/holaboss-ai配下へのクローンまたは更新
・npm run desktop:install
・desktop/.env.exampleからdesktop/.envの生成
・desktop:prepare-runtime:localとdesktop:typecheck
・--launch指定時のみdesktop:dev実行

Electronが起動しない場合は検証段階で停止し、手動次ステップを案内する設計だ。

6.2 手動インストール

中身を1ステップずつ確認したい場合はこちら。

# 1) リポジトリのクローン
git clone https://github.com/holaboss-ai/holaOS.git
cd holaOS

# 2) Electron依存のインストール
npm run desktop:install

# 3) ローカル環境ファイルの作成
cp desktop/.env.example desktop/.env

# 4) ローカルRuntimeバンドルの準備
npm run desktop:prepare-runtime:local

# 5) 型チェック（任意だが推奨）
npm run desktop:typecheck

# 6) Electron開発モード起動
npm run desktop:dev

predevフックが環境検証・ネイティブモジュール再ビルド・staged runtime bundleの存在確認を行うため、desktop:devの起動時間は初回でも数十秒程度に収まる。

6.3 Runtime単独デプロイ

デスクトップアプリを使わず、Runtimeをサーバーやコンテナで独立稼働させたい場合は、Independent Deployに手順がある。

CI/CDからエージェントを呼び出すヘッドレス運用、複数ユーザーが同じWorkspaceを共有するチーム運用などに向く。

7. MCPとの統合：ツール提供レイヤとの役割分担

holaOSのGitHubトピックにはmcpとmodel-context-protocolが含まれており、Anthropicが2024年に提唱したModel Context Protocolをネイティブにサポートする。

7.1 MCPサーバーの位置づけ

MCPサーバーは「LLMにツールを提供する側」の標準プロトコルで、ファイルシステム・GitHub・Slack・社内DBなど多数の実装が出回っている。

holaOSはこれらのMCPサーバーをWorkspaceのtools.yamlから宣言してマウントできる。

# desktop/workspaces/research/tools.yaml の例
mcp_servers:
  - name: github
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_TOKEN: ${GITHUB_TOKEN}
  - name: filesystem
    command: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/research"]
  - name: web-search
    command: npx
    args: ["-y", "@modelcontextprotocol/server-brave-search"]

この宣言だけで、Workspace内のエージェントは3つのMCPサーバーが提供するツールを横断利用できる。

7.2 holaOS自身は『MCPクライアントOS』ではない

混同を避けたいのは、holaOSはMCPサーバーを並べるためのクライアント単独製品ではなく、その上にWorkspace・Memory・Runtimeを重ねたエージェント環境である点だ。

MCPだけが目的ならClaude DesktopやCursorで十分だが、長期作業・継続性・複数エージェント運用を求めるとholaOSの守備範囲に入る。

自前MCPサーバーの作り方は MCPサーバー構築ガイド：自前ツール接続から実運用まで を参照。

8. 他のエージェントOS／フレームワークとの比較

「Agent OS」というカテゴリは2025〜2026年に急速に広がっており、似た位置取りの製品が複数存在する。代表どころと比較しよう。

数字はあくまで2026年5月時点の参考値で、後発のholaOSが既にスター5,463まで伸びている点に注目してほしい。

8.1 ハーネス系との違い

OpenHandsやAutoGPTは「エージェントループそのものをどう設計するか」が研究テーマだ。

holaOSはハーネス境界を抽象化し、ループ実装は外部プラグインに委ねる。「OpenHandsをholaOS Workspaceの中で実行する」という組み合わせ方も理論上可能になる。

8.2 ブラウザ自動化系との違い

Browser UseやPlaywright系エージェントは「ブラウザを操作する手段」を提供する。

holaOSはブラウザを含む環境全体を提供するため、ブラウザ操作機能はその一部に過ぎない。MCPサーバーや別ツールと組み合わせて「ブラウザ + ファイル + API + メモリ」を1つの作業として扱える。

8.3 マネージドサービスとの違い

ManusやReplit Agentのようなクラウド型は「すぐ使える代わりに環境がブラックボックス」だ。

holaOSはセルフホスト前提で、Workspaceがディスク上に実体を持つ。inspectabilityとデータ主権を重視するユースケースに合う。

9. 想定ユースケース

公式READMEの抽象的な説明から、具体的にどんな用途で使うべきかを引き出してみる。

9.1 個人のリサーチアシスタント

24時間ブラウザ・RSS・arXiv・GitHubトレンドを巡回し、要約と判断をMemoryに蓄積する常駐エージェント。

人間が朝起きてWorkspaceを開くと、夜間のリサーチログがダイジェスト化されて待っている、という非同期コラボレーション。

9.2 コードレビュー継続エージェント

GitHub MCPサーバー + ファイルシステムMCPサーバーをマウントしたWorkspaceで、PRが立つたびにレビューを継続的に実施する役割を持たせる。

過去レビューの判断基準がMemoryに残るので、レビューの一貫性が時間とともに向上する。

9.3 ナレッジワーカーのデジタル双子

Workspaceテンプレートをチームに配布し、各メンバーが自分のドキュメント・チャットログを読ませる。

「自分の思考スタイルを学んだエージェント」がメール下書きや日次レポートを準備する、という双子的な使い方。

9.4 業務オペレーションの自動化

Salesforce/Notion/Jira系のMCPサーバーを束ねたWorkspaceで、定型業務（請求書発行・契約書チェック・顧客対応）を継続実行する。

ステートが永続するため、複数日にまたがるワークフロー（請求→確認→消込）をエージェント側で追跡できる。

10. 開発参加・コントリビューションの入り口

Contributingセクションには、ローカルデスクトップ + Runtimeループの起動方法、検証・コミット・レビュー期待値が明記されている。

Build on holaOSはデスクトップ・Runtime・アプリ・テンプレート・検証パスをマッピングしたディベロッパー向け地図で、初参加でも全体像を把握しやすい。

Build Your First AppはWorkspace内アプリの作り方チュートリアル。Slackや独自CRMをWorkspaceに統合したい開発者はここから入る。

セキュリティ報告は[email protected]への私信が指定されている（SECURITY.md参照）。

「エージェントが毎回ゼロからやり直す」状態に疲れているなら、holaOSは試す価値がある。逆に「単発のタスク自動化」が目的ならOpenHandsやClaude Code直叩きのほうが軽量だ。長期作業の継続性を本気で扱う段階に来たプロジェクト向けの選択肢として、Environment Engineeringという思想ごと評価したい。

参照ソース

• holaboss-ai/holaOS — GitHub
• holaOS Documentation — getting-started
• holaOS Documentation — concepts
• holaOS Documentation — Environment Engineering
• holaOS Documentation — Workspace Model
• holaOS Documentation — Memory and Continuity
• holaOS Documentation — Agent Harness
• holaOS INSTALL.md
• holaOS Releases
• holaOS — Openflows currents